Re: [PHP-DEV] [VOTE][RFC] Safe Casting Functions
On Nov 26, 2014, at 17:24, Andrea Faulds a...@ajf.me wrote: On 26 Nov 2014, at 23:00, Rowan Collins rowan.coll...@gmail.com wrote: So far only 15 people have voted, that’s very low for this kind of RFC. I’m tempted to extend voting for another week. It’s not likely to change the outcome, but it would hopefully mean more people vote. I don't know if it would make a difference here, but I wonder if it would be sensible to add an abstain option in votes? That way, someone who has considered an RFC but not formed a strong opinion either way could register that fact. This could even be paired with the notion of a quorum, i.e. a minimum vote count demonstrating that the outcome of the vote is not the accidental result of missing votes, say because several people happened to be on holiday or busy. That sounds like a very good idea to me, I, for one, would be happy if this was implemented. A very strong +1 here. It would also give a stronger sense of how many people are actually looking at voting on RFCs in general. I would certainly have felt better casting abstain on several RFCs that’ve recently gone by than with the vote I actually cast (though I stand by my votes in all cases regardless), usually because of lack of strong knowledge of the subject matter. -- Gwynne Raskind -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Fix list() behavior inconsistency
On Sep 25, 2014, at 2:42, Dmitry Stogov dmi...@zend.com wrote: Hi, The vote is opened at https://wiki.php.net/rfc/fix_list_behavior_inconsistency Thanks. Dmitry. Voting for always disabling string handling. This behavior is arcane and weird to me, and can be quickly emulated with list($a,$b) = str_split([“ab”][0]); if someone was actually using it. -- Gwynne Raskind -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Fix list() behavior inconsistency
On Sep 25, 2014, at 2:42, Dmitry Stogov dmi...@zend.com wrote: Hi, The vote is opened at https://wiki.php.net/rfc/fix_list_behavior_inconsistency Thanks. Dmitry. Voting for always disabling string handling. This behavior is arcane and weird to me, and can be quickly emulated with list($a,$b) = str_split([“ab”][0]); if someone was actually using it. -- Gwynne Raskind -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Is it fair that people with no karma can vote on RFCs?
On Sep 19, 2014, at 21:32, Kris Craig kris.cr...@gmail.com wrote: On Fri, Sep 19, 2014 at 7:25 PM, Kalle Sommer Nielsen ka...@php.net wrote: 2014-09-20 3:29 GMT+02:00 Andrea Faulds a...@ajf.me: Hi! Perhaps I’m being unfair and overthinking things, but I wonder if it is really fair for people who have no karma, i.e. not contributors to the documentation, extensions, php-src or anything else, to have the ability to vote on RFCs? I’d never suggest people without internals karma can’t vote. I think doc and peck contributors are as valued as any other contributors. However, people with no karma whatsoever (a blank people.php.net page) voting irks me. Thoughts? I'm with you on this one, huge +1 for the separation on who can vote and changing the voting rfc. -- regards, Kalle Sommer Nielsen ka...@php.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php The one problem with this is it doesn't take into account those who contribute to PHP in other ways, such as administering tests, contributing RFCs, etc. I'm not necessarily against this, but if you want to garner wide enough support, you might want to make the language a little more inclusive. Just my two cents. --Kris I would also argue that contributions are not always a measure of the value of a person’s opinion. I haven’t made what would be considered “significant” contributions to PHP itself in a few years now, but I remain a very active user of the language, and I keep an eye on where it’s going. When I vote on language features, I’m casting that vote as someone who 1) has a clear set of reasons in mind for why a feature would or wouldn’t be useful, and 2) is always looking for a reason to be able to devote my time again. I agree that voting should be kept out of the hands of people who’ve never made any effort to show they give a darn about the language and its future. But I would say, be careful about equating “small contributions with “unimportant”, “uninteresting”, or “nonexistent ones. As Kris pointed out, the ways in which someone contributes aren’t always obvious. Leigh speaks of people who contribute “one translation a year” - that’s still more than many ever have done or ever will do. There are many who simply don’t have the time to take away from their lives to do more, but remain invested in the language and its community. That being said, I am absolutely in favor of excluding people who don’t make at least *some* effort. I’m strongly +1 for people explaining their reasons for a vote, or even doing so much as saying “I’d prefer not to explain my reasons”. I’m even more strongly +1 for people having to at least shown some level of interest before being allowed to influence PHP’s future. I would just like to be sure that the bar is not set so high that it excludes opinions from people whose only failing is not being seen by the community. Full disclosure: This is absolutely a self-serving opinion. All of my significant contributions are years old (dating back to 5.3), I’ve been all but invisible in the internals community since, and I am certainly someone who has limited time to spend on contributing to the language. But I like to think my thoughts are still worth something. If the requirement for that is that I explain why I voted how I did on an RFC, I’m glad - even eager - to do so. If the requirement for that is that I contribute at least one nontrivial documentation edit or source code commit per month, or something similar, I think the point has been missed. -- Gwynne Raskind -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Implicit isset() in Shorthand Ternary Operator
On Sep 17, 2014, at 11:40, Matthew Fonda mfo...@php.net wrote: Hi Andrea, This is great -- thanks to you and Nikita for the work here. Syntax wise, I would prefer a function-like syntax, e.g. coalesce($a, $b, 'c') or ifsetor() instead of $a ?? $b ?? 'c'. I find this more readable, and it avoids any possible confusion about precedence within the expressions. Either way, still +1 for this feature. Best regards, --Matthew I’m STRONGLY +1 in favor of this operator, ASAP; I’ve had to write more than a few hacks to keep a large codebase I’m responsible from being a complete mess of isset() checks - 5.6 has saved me a lot of what used to be ugly workarounds (variadic functions anyone?), but this one still haunts me. I would argue for both coalesce() (as a language token) and ?? and ??=, as shorthand forms, giving the user a choice as to which they find more readable. ?? is standard in both .NET and Apple’s Swift language - Apple added it to Swift (including the chaining behavior) early during the beta cycle due to user demand for exactly this kind of logic, and it’s been part of C# for a long time. -- Gwynne Raskind -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Voting on PHP features
On Mar 18, 2013, at 5:57 AM, Florian Anderiasch m...@anderiasch.de wrote: On 03/17/2013 02:12 PM, Clint Priest wrote: Unfortunately my experience with that process has been that many people will vote who had no part in the discussion. I don't see a point repeating points of discussion when being in agreement with people who already stated their opinion, or being persuaded by arguments given. I suppose the majority of voters will read the discussion, not necessarily actively participate. At least that would be sensible, right? :) Greetings, Florian I practically never participate in discussions, but I always read them before voting. As you say, it's just common sense. -- Gwynne Raskind -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [VOTE]Call for voting: support use list in foreach
On Sun, Aug 26, 2012 at 9:22 PM, Rasmus Lerdorf ras...@lerdorf.com wrote: On 08/26/2012 06:18 PM, Kris Craig wrote: Short of killing ourselves rewriting it in C++, I'm not sure there is an ideal solution to this problem. Because you think more people can grok C++ than C? That's not my experience. C is essentially a subset of C++. Any strong C++ developer (I think I have only ever met 2 of those) will know C inside out. -Rasmus That's where it gets ugly, in my experience; there are lots of mediocre C++ developers (and legions of even expert PHP/JavaScript/Python/Ruby/etc. devs) who couldn't so much as use a pointer without insert favorite C++ pointer wrapper here around to check their NULLs and do their deletes for them. LLVM is written in C++, and all that's done is raise the barrier of entry. C++ enables countless idioms that haven't made it into as high-level a language as PHP itself because of the potential for massive abuse (unchecked operator overloads, for one example). Basically, I expect that going to C++ would do nothing but encourage less talented people to do much more of the work, and the result would be a hopeless tangle (what we have now is a tangle, but at least it's not hopeless). My intention isn't to turn this into a language flame war, of course, but if you want to talk about rewriting PHP itself in a language that doesn't require all the dancing around that C does (with zval, for example), C++ is hardly the answer unless it's possible to enforce coding guidelines even more strictly than has already been done. (And a side note on that, the requirement of C89 standard compliance in PHP has less and less advantage these days, and handicaps those few language features in the later flavors of C (C99, gnu99, Clang C, etc.) which -could- lessen the current unreadability of the code.) -- Gwynne -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Adding a simple API for secure password hashing?
On Wed, Jun 13, 2012 at 5:31 PM, Nikita Popov nikita@googlemail.com wrote: Hi internals! Recent incidents have shown that even very large websites still don't get how to do password hashing properly. The sha1 hashes used by Linkedin et al can be easily cracked even by amateurs without special hardware. What could be the reason for this? Why don't people use bcrypt? It is being recommended already for *years*, but still most people don't seem to make use of it. I think the reason is that it is incredibly hard to use crypt() correctly, mainly for the following reasons: * For many people the syntax is hard to grasp. The hashing algorithm is specified as the salt parameter, which is somewhat non-obvious (at least for me). * The fact that you verify a password using $hash == crypt($password, $hash) is equally non-obvious. * Generating correct salts for bcrypt is quite complicated. It is encoded in some strange base64 format, thus requiring an additional function to create it. Additionally it isn't particularly easy to fetch the random bytes for the salt as you have to check several possibilities for a cross-platform solution (mcrypt initialization vector, openssl, /dev/*random, mt_rand etc). Correctly hashing a password with bcrypt thus requires about a hundred lines of code. So one either has to import a library (and strangely it seems that people don't like to do that!) or has to roll your own (usually implementing some part incorrectly...) Obviously it's somewhat tempting to use a one-liner sha1() hash instead of a hundred line bcrypt hash. So, wouldn't it be better if PHP provided an easy to use API for secure password hashes natively? So you just have to call a single function, which magically handles everything for you (like salt generation). A simple sample API could be two functions password_hash($password) and password_hash_verify($password, $hash). But it could just as well be a fancy, extensible OOP API. I think this would greatly improve the hashing situation for PHP. Thanks, Nikita Strong +1 on this. I'd suggest writing an RFC. -- Gwynne -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: restore user opcode handler in PHP
On Mon, Feb 13, 2012 at 04:38, yoram bar haim yora...@zend.com wrote:
Here is a simple test program that reproduce the issue on mac:
[snip]
shell gcc -o lib.so -shared lib.c
shell gcc -o main main.c lib.so
shell ./main
This example is flawed.
The manpage for dlclose(3) on Darwin explicitly states that a library
linked by the executable will never be unloaded. You link directly to
the library here. Also, you use prototypes of the library's functions
rather than calling dlsym(3), forcing you to link to the library,
defeating the entire point of loading it with dlopen(3) in the first
place. I've included a test which does not show the issue at the
bottom of this message.
(As a side note of interest, OS X has historically always had issues
with unloading images from the address space; for example, even in
Lion, if you unload an image containing Objective-C symbols, you stand
a pretty good chance of crashing. Image unloading simply didn't exist
at all in any useful form before Leopard.)
-- Gwynne Raskind
/* dylib.c - clang dylib.c -o dylib.dylib -dynamiclib */
static int var = 0;
extern int getVar(void);
extern void setVar(int value);
int getVar(void) { return var; }
voidsetVar(int value) { var = value; }
/* loader.c - clang loader.c -o loader */
#include stdio.h
#include dlfcn.h
intmain(int argc, char **argv)
{
void*libh = dlopen(dylib.dylib, 0);
int (*getfunc)() = dlsym(libh, getVar);
void(*setfunc)(int) = dlsym(libh, setVar);
printf(First load value: %d\n, getfunc());
setfunc(5);
printf(First load set value: %d\n, getfunc());
dlclose(libh);
libh = dlopen(dylib.dylib, 0);
getfunc = dlsym(libh, getVar);
setfunc = dlsym(libh, setVar);
printf(Second load value: %d\n, getfunc());
return 0;
}
/* output */
$ uname -v ; clang --version ; ./loader
Darwin Kernel Version 11.3.0: Thu Jan 12 18:47:41 PST 2012;
root:xnu-1699.24.23~1/RELEASE_X86_64
clang version 3.0 (tags/RELEASE_30/final)
First load value: 0
First load set value: 5
Second load value: 0
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Static Analysis of PHP_5_4 with CLANG
On Sun, Feb 5, 2012 at 17:08, Stas Malyshev smalys...@sugarcrm.com wrote: Hi! Another thing - is there any way to give CLANG some hints about some functions - such as the fact that zend_error(E_ERROR) does not return or just make some exceptions when we know some situation that it thinks can happen does not in fact happen - such as revtal_ptr_ptr = retval_ptr and then passing retval_ptr_ptr would actually change retval_ptr somewhere on the way, etc. The idea is if we could weed out false positives and somehow mark them we could use this tool in CI for detecting real errors. Clang (and its static analyzer) has a huge number of annotative attributes for everything which can be easily ifdef'd to nothing on non-Clang. http://clang.llvm.org/docs/LanguageExtensions.html gives most of them, and Clang also has the (nearly) full range of GCC's attributes. You can also disable the analyzer for non-annotatable false positives with a #if block (I forget the name of the macro off the top of my head). The most recent versions of clang should be able to trace aliased pointer paths to some extent, so if you're getting false positives there, it's possible there's a subtle issue (I haven't looked at the actual output). -- Gwynne -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Deprecate and remove /e modifier from preg_replace
On Sun, Feb 5, 2012 at 19:32, Adam Harvey ahar...@php.net wrote: On 6 February 2012 04:37, Tom Boutell t...@punkave.com wrote: Deprecate and then remove, or just leave it in. Make it optional forever just generates more nonportable PHP code. Ick. Huge +1 to that. Given the existence of preg_replace_callback() (as Stas noted above), my preference is for deprecation and then removal, but I think the overriding goal should be not introducing any more configuration dependent behaviour — I'd rather be actively trying to kill some of that than ushering more in. Strong +1 from me as well. Deprecate, remove. Do NOT get Suhoshin involved in this. It's not. -- Gwynne -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Change bug tracker bogus to not-bug?
On Wed, Jan 25, 2012 at 04:23, Pierre Joye pierre@gmail.com wrote: hi Justin, I'm totally for that, has been asked it for years. Let see what other nicer status we need as wel :) Cheers, On Wed, Jan 25, 2012 at 12:11 AM, Justin Martin frozenf...@php.net wrote: Hello, With some frequency, I find bugs which are not bogus, so much as they are reported based on a misunderstanding. Usually this happens for documentation problems, where someone has misunderstood what the documentation says, or hasn't read the documentation thoroughly enough. I'd like to propose simply changing the term bogus to not-bug. This would more politely and clearly indicate the nature of the way the bug is being closed, in addition to the comment that one ordinarily leaves. Those I've spoken to in php.doc agree. Any objections? Big +1 from me as well. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.3.9 and is_a changes
2011/10/22 Johannes Schlüter johan...@schlueters.de: There is also a lot to be said for going with what is known to be stable for an LTS release. Please do not begin with this discussion again. It is confusing for the readers and totally unrelated. There is no LTS in the release process RFC but every release has a fixed lifetime. This discussion is about Ubuntu LTS. So 5.4 might be a valid choice for them. If we can get a 5.4 they're reasonably comfortable with out in time, I'd argue very strongly for its inclusion. We've already got 5.4 in beta. I don't think it's crazy to think we'd have a 5.4.0 in plenty of time to let them do plenty of testing. We're talking about locking a major vendor into a major version for -five- years, not Ubuntu's usual three. 5.4 will give them a head start versus what would otherwise be starting already out of date - by the time Ubuntu 12.04 is officially released, they'd be behind with 5.3. My understanding of LTS is not that it's a total freeze, but that they support it for bug fix updates and such. So we could expect 5.4.x releases to get in (or be backported/cherry-picked) if they had important fixes, as long as we don't have another is_a() snafu. -- Gwynne -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Cannot build ext/intl on Fedora 15
On Sun, Aug 28, 2011 at 04:00, Stas Malyshev smalys...@sugarcrm.com wrote: Hi! On 8/27/11 1:49 AM, Sebastian Bergmann wrote: note: '__gxx_personality_v0@@CXXABI_1.3' is defined in DSO Judging from a quick search this is caused by libstdc++ missing from link line, and can be fixed by adding it, but I have no idea what's special with new Fedora (i.e., I think some new gcc stuff, no idea what) or why our autoconf magic didn't do what it was supposed to do. Hope autoconf magicians can shed some light on this :) This issue exists on Darwin (OS X) as well. -- Gwynne -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Choosing a distributed version control system for PHP
On Wed, Aug 24, 2011 at 19:03, David Soria Parra d...@php.net wrote: Those wanting to use git and git workflows have a disadvantage when we stay with SVN. Choosing a VCS happens from time to time and sometimes your favorit is not the winner. I personally would love to see PHP moving to hg, but if more people like git more, the hg people have to deal with it. Agreed on both counts. The RFC points out that there will be modules. We will _not_ copy the current SVN history into one big repo. In fact having everything, pecl, php-src and co in one repository does not make sense. The original plan called for the SVN repo to be split up at some point in the future, but DVCS gained traction and SVN went without any attempts by anyone to put a proper workflow of any kind in place. -- Gwynne -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Choosing a distributed version control system for PHP (or not). Call for Participation.
On Sun, Aug 14, 2011 at 04:18, Lester Caine les...@lsces.co.uk wrote: The only real disadvantage to hg is having to handle python code to maintain it, people might start converting from PHP ;) Although phphgadmin is a start to improving the php interface support and could be a good start at a fully PHP managed interface to a PHP repo? I'm starting to think we should take a cue from Linus and just do as we did with bugsweb, newsweb, and so forth: Build our own (Hg/Git-compatible) DVCS from scratch! (I'm joking... mostly.) -- Gwynne -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Choosing a distributed version control system for PHP (or not). Call for Participation.
On Fri, Aug 12, 2011 at 07:54, Kalle Sommer Nielsen ka...@php.net wrote: 2011/8/12 Sebastian Bergmann sebast...@php.net: I never understood why we chose a legacy technology when we migrated from CVS. Well I'm sure if there were raised bigger concerns or more attention headed towards Git/Mercurial/Bzr/Whatever then we might ended up on one of them today. I don't remember much of the discussion other than it was moved to another list which I didn't subscribe to, I just remember it was long and ongoing with our beloved namespace separator at the same time which floated internals. The short version is that those in charge of the move (mostly me) didn't understand DVCS at the time. In retrospect, it was a bad move. Git and Hg were less mature back in early 2009, but not so immature that we couldn't have used either one. Between the lack of interest in SVN and the ongoing debate over the namespace separator, there weren't enough voices talking about VCS to make a difference - I argued that CVS - SVN was complicated enough and that jumping straight to DVCS would upset too many people, and there was enough agreement that SVN went ahead anyway, with the thought that the Git mirror would be good enough. In my defense, at the time SVN looked a good bit better than it does now. I really did think it'd last, LOL. -- Gwynne -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] [RFC] Line markers in PHP
I've just created a new RFC, https://wiki.php.net/rfc/linecontrol , regarding adding cpp(1)'s linemarkers to PHP. Discussion is invited. -- Gwynne -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] [PATCH] 5.4 doesn't build with Clang 2.9
There's bug in LLVM 2.9's assembler which causes the build to fail on the inline assembly, specifically the fsubp instruction. The bug is LLVM #9164 (http://llvm.org/bugs/show_bug.cgi?id=9164). As I lack Zend karma, I've attached a patch to fix this issue for affected Clang builds. I've tested it on multiple architectures (i386, x86_64), compilers (gcc 4.2, LLVM-GCC, Clang 2.9, Clang SVN), and systems (Darwin, Ubuntu, BSD), and it appears to work cleanly on all of them. The patch is against 5.4. -- Gwynne Index: Zend/zend_operators.h === --- Zend/zend_operators.h (revision 314327) +++ Zend/zend_operators.h (working copy) @@ -615,7 +615,11 @@ 0:\n\t fildl (%2)\n\t fildl (%1)\n\t +#if defined(__clang__) (__clang_major__ 2 || (__clang_major__ == 2 __clang_minor__ 10)) + fsubp %%st(1), %%st\n\t // LLVM bug #9164 +#else fsubp %%st, %%st(1)\n\t +#endif movb $0x2,0xc(%0)\n\t fstpl (%0)\n 1: @@ -635,7 +639,11 @@ 0:\n\t fildq (%2)\n\t fildq (%1)\n\t +#if defined(__clang__) (__clang_major__ 2 || (__clang_major__ == 2 __clang_minor__ 10)) + fsubp %%st(1), %%st\n\t // LLVM bug #9164 +#else fsubp %%st, %%st(1)\n\t +#endif movb $0x2,0x14(%0)\n\t fstpl (%0)\n 1: -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] An implementation of a short syntax for closures
On Thu, Aug 4, 2011 at 09:12, Antony Dovgal t...@daylessday.org wrote:
Btw, am I the only one to whom the proposed syntax seems kinda
hieroglyphic?
No. I don't see at all why we need this, just like I don't see why we
needed an alternative (short) syntax for arrays. This kind of syntax
additions that add *no* functionality, should not be in PHP.
Yes, I believe we should stop this stream of alternative syntax proposals
and concentrate on fixing existing functionality instead of adding less
readable ways to do
the same thing. I would really like to keep PHP code easily readable, not to
turn it into
perl-ish write-only gibberish.
100% agreed, both about the cryptic nature of the proposed syntax and
the need to focus on fixing existing issues. Strong -1 on a new
syntax.
The current PHP syntax for closures is the second-best one I've ever
used, IMHO. Clear, readable, explicit. My all-time favorite syntax is
that favored by Objective-C:
^ [returntype] ([params]) { code; }
The compiler figures out at build time which lexical stuff to capture,
and in most cases can infer the optional return type. I'd kinda love a
^ (params) use (captures) { code; } syntax in PHP, but nothing any
less wordy than that, and I'd hardly consider it any kind of priority.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] new gcov.php.net machine is up
On this subject, I've been looking into what produces the largest
warnings spam with a decent set of warnings turned on, and I'd like to
recommend this patch. I can't commit it myself (I don't have Zend
karma), nor would I care to without getting some opinion on it. The
patch is against 5.4, but should apply equally to trunk. No API is
changed, and no BC issues are created; it only adds a
forward-compatible optional declarator for the end of a
zend_function_entry struct. Obviously, the spammed warning in question
is missing initializer, with respect to every function entry struct
in every extension, all of which simply use the {NULL, NULL, NULL}
from ext_skel. The intention is to provide this constant to protect
against future extensions of the structure. There are some other
structures which could also benefit from such an initializer
(smart_str and zend_fcall_info[_cache] come to mind).
Index: Zend/zend_API.h
===
--- Zend/zend_API.h (revision 313656)
+++ Zend/zend_API.h (working copy)
@@ -96,6 +96,8 @@
#define ZEND_NS_FALIAS(ns, name, alias, arg_info)
ZEND_NS_FENTRY(ns,
name, ZEND_FN(alias), arg_info, 0)
#define ZEND_NS_DEP_FALIAS(ns, name, alias,
arg_info) ZEND_NS_FENTRY(ns, name, ZEND_FN(alias), arg_info,
ZEND_ACC_DEPRECATED)
+#define ZEND_FE_END{ NULL, NULL, NULL, 0, 0 }
+
#define ZEND_ARG_INFO(pass_by_ref, name)
{ #name,
sizeof(#name)-1, NULL, 0, 0, 0, pass_by_ref},
#define ZEND_ARG_PASS_INFO(pass_by_ref)
{ NULL, 0, NULL, 0, 0,
0, pass_by_ref},
#define ZEND_ARG_OBJ_INFO(pass_by_ref, name, classname, allow_null) {
#name, sizeof(#name)-1, #classname, sizeof(#classname)-1, IS_OBJECT,
allow_null, pass_by_ref},
Index: main/php.h
===
--- main/php.h (revision 313656)
+++ main/php.h (working copy)
@@ -359,6 +359,7 @@
#define PHP_MALIAS ZEND_MALIAS
#define PHP_ABSTRACT_ME ZEND_ABSTRACT_ME
#define PHP_ME_MAPPING ZEND_ME_MAPPING
+#define PHP_FE_END ZEND_FE_END
#define PHP_MODULE_STARTUP_N ZEND_MODULE_STARTUP_N
#define PHP_MODULE_SHUTDOWN_N ZEND_MODULE_SHUTDOWN_N
-- Gwynne
On Sat, Jul 23, 2011 at 19:23, Rasmus Lerdorf syst...@php.net wrote:
On 07/23/2011 04:07 PM, Gwynne Raskind wrote:
Here's my question - if I made some smaller commits here and there to
fix warnings in core, would that be accepted? I don't have time to do
sweeping changes, but fixing one file today, a couple the next day,
etc., is within my abilities (including making sure no regressions are
introduced, of course).
That's fine if it is done carefully. Note that the code needs to compile
on many different platforms, on many different compilers and versions of
compilers.
-Rasmus
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] new gcov.php.net machine is up
In my experience, 100% warnings free is only practical in two cases: 1) When the project is built with that policy from day one. 2) When someone takes the (I'd estimate) two weeks solid work necessary to eliminate every existing warning from the current trunk, AND a strict policy of maintaining zero warnings is put in place. (Believe me, the policy doesn't work if there are any warnings in the build; people inevitably get lazy.) Given the variety of warnings that pop up in a PHP build (and don't even start me on the list thrown up by Clang's static analyzer!), it's a major undertaking to eliminate all the warnings, and it'll get ugly. -- Gwynne On Sat, Jul 23, 2011 at 16:06, Richard Quadling rquadl...@gmail.com wrote: On 23 July 2011 17:16, Antony Dovgal t...@daylessday.org wrote: Thanks Nuno, great job! On 07/23/2011 08:03 PM, Nuno Lopes wrote: Hi, Thanks to Nexcess, we have a new wonderful machine for http://gcov.php.net up and running. This new machine is running linux 64 bits, so expect a few differences in the test results. I believe most things are ported from the old machine, including all daemon's configurations. I fired an experimental run of the cron job. Please help me by reporting extensions that are not enabled, daemons that are misconfigured and why (and therefore some tests are failing or skiping), missing valgrind suppressions, and so on. Thanks to Nexcess for offering a new machine to replace the old one. Nuno Excellent work. I see from the recent report that there are a LOT of similar warnings. I'm guessing that those warnings, whilst they are generated on a linux x64 box, would be the same for win32 (and anything else). What sort of policy is needed in addressing casting warnings like this. I get a LOT of warnings about casting of doubles/floats to ints/longs, along with the potential for potential data loss. How feasible is it to aim for a 100% warning free build? I'm not meaning that we should suppress the warnings. -- Richard Quadling Twitter : EE : Zend : PHPDoc @RQuadling : e-e.com/M_248814.html : bit.ly/9O8vFY : bit.ly/lFnVea -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] new gcov.php.net machine is up
Here's my question - if I made some smaller commits here and there to fix warnings in core, would that be accepted? I don't have time to do sweeping changes, but fixing one file today, a couple the next day, etc., is within my abilities (including making sure no regressions are introduced, of course). -- Gwynne On Sat, Jul 23, 2011 at 18:54, Hannes Magnusson hannes.magnus...@gmail.com wrote: On Sun, Jul 24, 2011 at 00:45, Pierre Joye pierre@gmail.com wrote: I would add: 2.1 fix the new ones That's what I try to do using a delta between two revisions. At some point these delta will be available online so anyone can fix them as well, including the author of these new warnings. That is an excellent point. We have a Windows buildbox and I noticed gcov has started notifying about broken builds.. We also have 5+ others servers (various BSD and Linux versions). Is anyone working on a unified buildbot to run on these servers? We also have the `make test` statistics on http://qa.php.net/reports/ by Oivier.. Would it be possible to coordinate all these efforts? -Hannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Magic quotes removal previous patch
+1 to E_CORE.
-- Gwynne
On Thu, Jul 21, 2011 at 06:28, Pierrick Charron pierr...@webstart.fr wrote:
I'm also ok with E_CORE.
Pierrick
On 21 July 2011 05:19, Pierre Joye pierre@gmail.com wrote:
hi Pierrick!
Thanks for the updated patch :)
Now the only question remaining is which level warning we should use
for the setter. I'm happy with E_CORE. Objections?
On Thu, Jul 21, 2011 at 2:18 AM, Pierrick Charron pierr...@webstart.fr
wrote:
I tried to send the patch as a .txt file but it seems my mail was not
send to internals since i don't see it on news.php.net.
Anyway you'll find patch (code + tests) here :
- http://www.adoy.net/php/remove-magic-quotes.txt
- http://www.adoy.net/php/remove-magic-quotes-tests.txt
Pierrick
On 20 July 2011 15:44, Pierre Joye pierre@gmail.com wrote:
hi,
Please find as attachment the previous patch to remove the magic quotes.
The log I was using back then was (5 years ago already, mq resists :):
Log:
- remove magic_quotes_gpc, magic_quotes_runtime, magic_quotes_sybase
(calling ini_set('magic_') returns 0|false
- get_magic_quotes_gpc, get_magic_quotes_runtime are kept but always
return false
- set_magic_quotes_runtime raises an E_CORE_ERROR
Cheers,
--
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: RFC: Short syntax for Arrays (redux)
On Jun 1, 2011, at 7:35 AM, Derick Rethans wrote: But only if you keep it consistent, PHP has always been using = for key/val association, I don't see any reason to suddenly provide key: val, unless what you want is to confuse people. Yes, definitely = vs. : in any case. +1 to this. -- Gwynne -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Short syntax for Arrays (redux)
+1 On May 31, 2011, at 2:42 PM, Brian Moon wrote: https://wiki.php.net/rfc/shortsyntaxforarrays Since this was brought again recently by Rasmus (http://markmail.org/message/fx3brcm4ekh645se) and on Twitter where several people including Andi chimed in on it and Ilia seemed to reverse his thoughts as well (with caveats), I thought I would start a real thread about it. The reason the RFC stalled was stated as: This patch will not be accepted because slight majority of the core developers voted against. Though if you take a accumulated mean between core developers and userland votes seems to show the opposite it would be irresponsible to submit a patch witch is not supported or maintained in the long run. So, the PHP users want it, but too many PHP core devs did not want it or did not see the use of it. From rereading the mailing list archive, most had the tone of I don't see a reason for it. I was in that camp in 2003 when it first came up. However, with the emergence of JSON and systems that use JSON as an interface, this type of syntax would be most welcome in the day to day life of a PHP developer. I would prefer (as Rasmus pointed out) not to start a long discussion about it. Primarily I would be curious if anyone on the lists (from the RFC wiki page) below would like to change your vote or if you are not listed below and would like to be counted, that would be great too. PHP SVN account holder voters = Pro: Andrei Zmievski, Andi Gutmans, Pierre Joye, Rasmus Lerdorf, Stanislav Malyshev, Brian Moon, Kalle Sommer Nielsen, Edin Kadribasic Contra: Antony Dovgal, Derick Rethans, Jani Taskinen, Lokrain, Felipe Pena, Lukas Kahwe Smith, Marcus Boerger, David Soria Parra, Johannes Schlüter, Maciek Sokolewicz, Philip Olson, Ilia Alshanetsky, Daniel Brown, Jochem Maas, Hannes Magnusson, David Coallier Other voters Pro: Sebastian Deutsch, Ryusuke Sekiyama, Stefan Marr, Alexey Zakhlestin, Carl P. Corliss, Darius Jahandarie, Giedrius D, Eric Coleman, Max Antonov, Mike Ford, Larry Garfield, Sam Barrow, Taylor Luk, Hans Ahlin, Karoly Negyesi, Guilherme Blanco, Jonathan-Bond Caron Contra: Geoffrey Sneddon, Tomi Kaistila, David Zühlke -- Brian. http://brian.moonspot.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Gwynne -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Fwd: What's up with Quercus?
On May 29, 2011, at 2:24 AM, Stas Malyshev wrote: - I immediately had to write an extension to give me access to several missing APIs (clock_gettime() and a number of ncurses functions not implemented in the ncurses extension). So the problem with PHP is that it doesn't include support for any possible API out of the box. While all other languages out there of course do ;) More a question of I wish these existed: https://wiki.php.net/rfc/php_native_interface https://wiki.php.net/rfc/remove_zend_api types not in the original API was just a bonus.) - In general, I have to tiptoe all over everything to avoid getting useless notices/warnings for expected error conditions (such as SIGPIPE on This is indeed a serious complaint, PHP tends to be over-verbose and errors are expensive. So far there's no BC-compliant way to fix it has been found. I know, I tried at least 3 times :) We need ideas there. Offhand I'd say there's no BC-compliant way at all short of providing a second set of APIs alongside the old ones. Which, given the naming conventions problem, might not be the worst idea, but would definitely be a nightmare in terms of consistency. - No threading support. Threading in PHP wouldn't work. At least the one like they have in Java. Unless you want to mess with thread synchronization, deadlock resolution and other stuff, which 99.% of PHP users don't. That's fair. No preprocessor. define() makes up for only some of it, closures make up for some more, but still not enough. There are no mature Here it may be interesting to note so does pretty much any other language except for C. True, and I've felt the lack in such languages as well. On the other hand, PHP is a bit more C-like then many; I don't feel the need in, for example, Lua. And yes, it does mean an engine rewrite. That would be too easy. It also means throwing out most of the existing code and rewriting everything that was done in last 10+ years in PHP. Then the question would be - why do it with PHP? If you designing a language from scratch anyway, there are so many opportunities to explore... Don't think I'm not tempted to design an alternative language. If I had the time and understood LLVM better, I probably would :). I don't really expect PHP to be rewritten, but if enough distaste is expressed with the current state of affairs, I imagine at least some things might change. On May 29, 2011, at 2:28 AM, Pascal COURTOIS wrote: why not using a language designed for your needs ? The balance between rapid development, learning curve, and usability. One line in Python or PHP or even C# can equate to thousands in C. Python or Java might be a better match for what I'm doing, but then there's the question of putting in the time to become fluent with them and their libraries, and there is a time constraint. PHP has all of these issues, but 1) I know the language and how to cope with the issues it does have, and 2) once those issues are coped with, it works better than anything else I know well enough to use now. -- Gwynne -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Fwd: What's up with Quercus?
On May 28, 2011, at 10:55 PM, Martin Scotta wrote: I really dont like to move away from PHP, but compared to others... it's just a template language with steroids. and please dont get me wrong, I love PHP, it's is still my favourite but... This has been exactly my experience when trying to use PHP in any meaningful way. For example, trying to use PHP as a network server: - I immediately had to write an extension to give me access to several missing APIs (clock_gettime() and a number of ncurses functions not implemented in the ncurses extension). - In order to use stream_select() with both network sockets and STDIN, I had to merge socket_select() with stream_select() in my extension, as in 5.3 stream_select() doesn't preserve socket array keys (this was fixed in 5.4) - To make use of pack() and unpack() for packet management, I had to reimplement them so as not to throw notices willy-nilly when I got bad packets. (Adding format specifiers that could handle useful data types not in the original API was just a bonus.) - In general, I have to tiptoe all over everything to avoid getting useless notices/warnings for expected error conditions (such as SIGPIPE on dying sockets, passing zero sockets to stream_select(), trying to fopen() a nonexistant file, and so forth). - No threading support. - No preprocessor. define() makes up for only some of it, closures make up for some more, but still not enough. There are no mature opensource preprocessor implementations for PHP that I can find (just betas of various sorts), and both GCC's and Clang's CPPs break on here/nowdocs. More generic preprocessors (like m4) tend to have learning curves or problems of their own. - (Almost) everything here: http://www.phpsadness.com/ - No Unicode. If there is any direction for PHP 6, I'd like to see that direction be dealing with problems like these. PHP has been used more and more as a general-purpose language, when it wasn't designed to be. Addressing that would solve a lot of core problems. And yes, it does mean an engine rewrite. -- Gwynne -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: EBNF
On Dec 31, 2010, at 6:54 AM, Enrico Weigelt wrote:
After enviously looking at pythons grammar
(http://docs.python.org/dev/reference/grammar.html) I keep feeling
that PHP is missing out on a lot of interesting meta projects by not
having an official EBNF.
ACK. PHP also misses a lot of other fundamental specifications
(at least I'm not aware of them). That's probably one of reasons
for the many problems experienced from user and enterprise operator
side: sudden semantic changes.
Building your own PHP parser is _very_ hard and is PhD (Paul Biggar:)
level stuff if you wan't to get all the edge cases right. Having _the_
official EBNF would make this easier.
Hmm, perhaps it really would make a good PhD project to actually
create a clear specification, a full language report (at least for
the language itself and the core library) and write an tiny reference
implementation. Once that specification is finished, it should become
the official one where official PHP is tested against.
If anyone's curious why this hasn't been done...
There has never been a language grammar, so there's been nothing to refer to at
all. As for why no one's made one more recently, for fun I snagged the .l and
.y files from trunk and W3C's version of EBNF from XML. In two hours of hacking
away, I managed to come up with this sort-of beginning to a grammar, which I'm
certain contains several errors, and only hints at a syntax:
/* http://www.w3.org/TR/REC-xml/#sec-notation */
ws ::= [ \n\r\t]+
string ::= [a-zA-Z_#x7f-#xff] [a-zA-Z0-9_#x7f-#xff]*
namespace-name ::= '\\'? string ( '\\' string )*
use-declaration ::= 'use' ws+ namespace-name ( ws+ 'as' ws+ string )? ( ws* ','
ws* namespace-name ( ws+ 'as' ws+ string )? )+ ws* ';'
constant-declaration ::= 'const' ws+ string ws* '=' ws* static-scalar ( ws* ','
ws* string ws* '=' ws* static-scalar )* ws* ';'
inner-statement ::= statement | function-declaration-statement |
class-declaration-statement
statement ::= unticked-statement | string ':'
unticked-statement ::= '{' ws* inner-statement* ws* '}' |
'if' ws* '(' ws* expr ws* ')' ws* statement ws* elseif*
ws* else-single? |
'if' ws* '(' ws* expr ws* ')' ws* ':' inner-statement*
elseif-2* ws* else-single-2?
halt-compiler ::= '__halt_compiler' ws* '(' ws* ')' ws* ';'
top-statement ::= inner-statement |
halt-compiler |
'namespace' ws+ namespace-name ws* ';' |
'namespace' ( ws+ namespace-name )? ws* '{' ws*
top-statement-list ws* '}' |
use-declaration |
constant-declaration
script ::= top-statement*
Considering what it takes JUST to define namespaces, halt_compiler, basic
blocks, and the idea of a conditional statement... well, suffice to say the
expr production alone would be triple the size of this. It doesn't help that
there's no way I'm immediately aware of to check whether a grammar like this is
accurate.
Obviously there's room for optimization. An EBNF doesn't have to jump through
some of the hoops that a re2c parser backed by a flex lexer does; it could be
simplified once all the parser rules were considered. Or it could be written
without referring to the parser at all. Whether that would result in a better
or worse grammar, I don't know.
Nonetheless, it's a significant undertaking to deal with the complexity of the
language. There are dozens of tiny little edge cases in PHP's parsing that
require bunches of extra parser rules. An example from above is the difference
between using statement and inner-statement for the two different forms of
if. Because statement includes basic blocks and labels, the rule disallows
writing if: { xyz; } endif;, since apparently Zend doesn't support arbitrary
basic blocks. All those cases wreak havoc on the grammar. In its present form,
it will never reduce down to something nearly as small as Python's.
-- Gwynne
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC - MACRO
On Dec 22, 2010, at 4:38 PM, Mathias Grimm wrote:
People always will want more, but some features are nice.
for C/C++ programmers, macro is on of the best things to make thing work
every where.
its possible to create a IDE macro, but the native php feature will be good.
template engines can de wrap this functionality too.
is just like a variable:
I've long wished for preprocessing in PHP. It would be semi-trivial to plug in
libcpp from GCC or llvm's preprocessing library, if licensing weren't an issue.
If it is, then a reasonable homegrown implementation of C's preprocessor
semantics, or at least a subset of them, isn't that difficult.
Piping through cpp has two major problems:
1) It's an extra runtime step. Slower, more error-prone, not always an option
(shared hosting anyone?).
2) cpp doesn't understand # comments, single-quoted strings, heredocs, etc.
Many PHP scripts therefore produce annoying/confusing errors.
Some issues with PHP-native preprocessing:
- Are eval() strings subject to it? At what stage, outer script processing or
the eval string?
- #include/#import versus include()/require() - confusing
- Does preprocessing take place outside whatever PHP tags are active?
On Wed, Dec 22, 2010 at 7:08 PM, Scott MacVicar sc...@macvicar.net wrote:
I really dislike this, what about resolving orders, then people will want
undef, then ifdef with conditions.
The language doesn't need to introduce anything that makes it more complex
to use.
- Scott
On 22 Dec 2010, at 11:55, Mathias Grimm mathiasgr...@gmail.com wrote:
I Just want a simple replace-on-the-air to avoid spend time writing more.
On Wed, Dec 22, 2010 at 5:43 PM, Stas Malyshev smalys...@sugarcrm.com
wrote:
Hi!
I want to request a C/C++ feature that i think is good.
MACRO
You know that you could write:
?php
#define PF private function
#define SCOPE_CLASS(x) class MyProject_ ## x
class UseMacro
{
PF preSave($object)
{
//...
}
}
SCOPE_CLASS(Internal)
{
}
And then run it through CPP (gcc -Mcpp -E - - in.php out.php) and
get
all the macros processed?
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
-- Gwynne
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] git anyone?
On Nov 29, 2010, at 4:19 AM, Lester Caine wrote: I've not used git or hg much at all, but bzr has always satisfied my needs for DVCS, and has recently gotten much faster and more space efficient than it was in the past. Sorry, but I think bzr is not a good fit. It's numerous changes to the repository format make it impossible to use. It's either slow if you use an old version, or it's incompatible with old clients, let's say on an old debian box. So I think php.net is better of using mercurial or git, but if we put together an RFC for a migration, I'll make sure bzr is covered as well in an evaluation. Personally I would need a very good reason to add yet another DVCS to the mix here! I've not found bzr as easy to link to from hg as git is. In fact I've not actually got it to play at all as yet ... while hg does work into git with only the problems of managing multiple repo's which is still work in progress on both of them. That said, bzr does seem to handle the multiple repo's in a more user friendly manor? It is just a pity that there is NOT a single target solution for DVCS as everybody is currently scurrying off to their own corners :( The barriers have already been drawn rather then there being concensus on some sort of standard. I think it's high time I tossed in my 1.682¥(JPY) (according to current exchange rates)... I've been out of the PHP dev community for some months now, so anything I say has to be taken with a grain of salt; I simply don't have the time right now to catch up in any detail on the current state of affairs. That in mind, I was already disgusted with SVN by the time the move to it was finished. At the risk of drawing a bit of fire, I have to say I agree with Linus Torvalds' attitude about it, when he said (search Linus Torvalds subversion on Google for the reference) that it was pointless and that CVS couldn't be done right. SVN ditched things CVS had that should've been kept. Sub-repo management (modules) and module merging/aliasing are the two I fought most with during the migration; externals were a BAD patch on the problem! SVN was trying to do CVS right, but that simply doesn't hold together in the modern software development world. Centralized servers by themselves are an old model. Simple, but old. That's why DVCSs exist in the first place! So yes, I think PHP needs to move past Subversion, which is being constantly held back by a model that's just too limited. The branching/merging nightmare seals the coffin, as far as I'm concerned. Which DVCS do I think is best? Git is the massive favorite out there at the moment, according to my Googling. I myself have never been able to fully get my head around it; someone said earlier in the thread that it's a swiss army knife with a boom button, a sentiment I tend to agree with. Still, someone else also correctly said that the huge majority of devs in PHP right now do use it, and that can't be ignored. It is my observation that the Windows issues have been largely solved in more recent times. GitHub itself (while I would prefer something we host ourselves), is pretty easy to use. I don't know much about Mercurial, having never used it, so I can't comment much on it. The fact that it continues to be prevalent at all versus Git says something for it, but it falls down against the ubiquity argument, as a quick glance suggests to me that the learning curve would actually be a bit worse than Git's. Its Web interface makes me cringe. Bazaar is -my- current favorite, as its commands tend to translate almost directly from SVN's and while a minority, it has a passionate following (largely thanks to Ubuntu and MySQL, I think). But it being my personal favorite doesn't mean much. I also find Launchpad a bit incomprehensible, and Bazaar being written in Python feels a little odd to me. Don't we rely enough already on competing languages? :) (Mercurial also suffers from this.) I am not going to attempt any kind of conclusion based on technical merits (branching/merging ability, sub-repo support, etc.), as I don't know what the status of these features is, and even if I did, I no longer have enough knowledge of PHP's current state to apply the knowledge. So, I have to base my thought on what the most people are going to have the least trouble working with, and that's Git, hands down. There are more than enough people around the community with the full knowledge necessary to undertake the migration with minimum fuss; it's been pointed out that the kind of massive manual balancing I had to do for CVS-SVN would be completely absent. I just wish I didn't have to also admit that Trac is a really great project management system. Unless things have changed drastically since I was last active, PHP still needs one. ^^; -- Gwynne -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: RFC: Making T_FUNCTION optional in method declarations
On Nov 30, 2010, at 4:24 AM, Arvids Godjuks wrote:
Personally, as a user-land developer, I'm against it, so -1.
function keyword is the only sane way to quickly find a function
definition in lots of code. Not always IDE's are able to fully
understand the interconnections in frameworks and point by CTRL +
Click me to the function definition, not to say that in many cases you
just don't have that IDE available right now and right here.
Now it's quite easy to make a search on a folder recursively - just
enter function blah and here you go - one entry with the function
definition. Try that with the function/method name without the
function keyword, good luck with going through tons of entries.
I deal with typing the whole public/private function blabla() { by
defining a auto complete shortcut like prfnc = space = private
function |(){ where | is cursor.
Please keep it KISS way. Language should evolve for sure, but some
things are not just worth sacrificing the verbosity even if it means
cuts typing some of the most common keywords in the language and can
be perfectly done keeping the BC.
P.S. Personally I will prohibit my developers to use the short syntax
without the function keyword.
Agreed. -1 here also.
-- Gwynne
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] git anyone?
On Nov 30, 2010, at 5:10 AM, Ferenc Kovacs wrote: I just wish I didn't have to also admit that Trac is a really great project management system. Unless things have changed drastically since I was last active, PHP still needs one. ^^; just a little comment on the last statement: do you know about mtrack? it is a trac clone written in php by Wez *Googles.* *Reads.* Well... dang. Go Wez!! I like it :-). Thanks for the pointer! I'll have to look into that in more detail soon, it could prove very useful. And it looks a good bit better than Trac too ;-). -- Gwynne -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Commit messages and ChangeLog (Re: [PHP-DEV] ChangeLog)
On May 28, 2010, at 7:43 PM, Pierre Joye wrote: Is anybody using this file? If this is thee case could somebody then make sure it's being updated (and maybe take care of ChangeLog-200[6-9].gz being created) else I'd suggest dropping them. An outdated file might be confusing for users expecting content like we have in the NEWS file there. I do, what's about only changing how it is generated to generated changes since last release instead? I'd to add that unless we add everything in the NEWS file, the ChangeLog remains the only way to have a list of all changes (without doing manually). Isn't that what svn log -v now provides? The format is slightly different of course, but it does provide the same info. By without doing it manually, I meant when one fetches a release or a snapshot. The ChangeLog files aren't updated because no one ever ported the ChangeLog crons from CVS to SVN. It wouldn't be very difficult - in fact one of the open-source scripts already out there for the purpose would seem appropos, it just hasn't been done. They seem to be standard fare in FOSS projects, so I'm -1 for removing the functionality, but +1 for removing the useless archives from all active branches. I wish I could volunteer to do the port, but I have too much on my plate right now :( -- Gwynne smime.p7s Description: S/MIME cryptographic signature
Re: [PHP-DEV] trunk is alive and open
On Apr 29, 2010, at 10:05 AM, Lukas Kahwe Smith wrote: -Original Message- From: Johannes Schlüter [mailto:johan...@schlueters.de] Sent: Tuesday, April 27, 2010 9:40 AM To: Pierre Joye Cc: Gwynne Raskind; Ilia Alshanetsky; Kalle Sommer Nielsen; Lukas Kahwe Smith; Andi Gutmans; Derick Rethans; PHP Developers Mailing List Subject: Re: [PHP-DEV] trunk is alive and open On Tue, 2010-04-27 at 17:46 +0200, Pierre Joye wrote: Before even thinking about a planning, we have to define what we want in and how we go further. ACK, I think it makes sense to define some key features we want for the next release (traits seem to be one). An issue with 5.3 was that whenever really defined that but only said let's backport from 6 and add all stuff coming in. I think it makes sense to define a set of key features (traits, what else?) and once these are implemented in an accepted way (not meaning stable but having an accepted design) make a release branch (either by branching of or locking trunk for bigger features or whatever) where stability of this is improved else we end up adding feature after feature and introducing problem after problem. As I've mentioned in the past I think we are better off with shorter release cycles and less features per cycle. Reduces risk and enables us to push out value faster. For example, we have made (and are still making) significant performance enhancements to the runtime. It'd be a shame if that waited until Q4 for alpha. I think with traits, performance enhancements and a few additional changes we already have a pretty substantial version. +1 +1 +1 -- Gwynne -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] trunk is alive and open
+1 for Derick and Kalle, and +1 for alpha by Q4. On Apr 27, 2010, at 8:53 AM, Ilia Alshanetsky wrote: +1 for a co-RM of Derick and Kalle On Tue, Apr 27, 2010 at 12:33 AM, Kalle Sommer Nielsen ka...@php.netwrote: Hi 2010/3/24 Lukas Kahwe Smith m...@pooteeweet.org: Yeah, lets get that clarified. Derick has stepped up and seems quite committed and nobody seemed to oppose him RMing the next release. In case he feels he needs support he can propose a co-RM, after all its important that the two RM's know and trust each other well so that they can speak with a consistent voice. I'll like to propose myself for RM'ing, or co-RM-ing with Derick, now David have said no in the last mail in this thread. I've been around the PHP development for a few years now. I don't have the large technical experince like Derick but I would still stand up for the challenge and responsibility of getting the next major version of PHP out and rolling. I once tried to come up with some suggestions about getting PHP6's old implementation on the track again but it didn't get much response. And I think we should decide on a version number and see if we can get an Alpha release out by Q4 this year if possible, since the current releases of new development branches have been taking forever during the last couple of years. -- regards, Kalle Sommer Nielsen ka...@php.net -- Gwynne -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] trunk is alive and open
On Mar 30, 2010, at 11:41 PM, Philip Olson wrote: It's awesome that PHP has so many great options for the next Release Manager because all of the proposed people would do great. However, I'd like to see Rasmus become RM. Not sure about the co-RM topic but Chris Jones comes to mind. I love the way these two guys handle things, and it feels like a nice balance. And while Rasmus may [or may not] deny his BDFL status, I'd love to see it in high gear especially now that he's funemployed. +1 -- Gwynne smime.p7s Description: S/MIME cryptographic signature
Re: [PHP-DEV] Re: moving forward
On Mar 14, 2010, at 12:58 PM, David Soria Parra wrote: I would also like to bring up another point. Since we are now on SVN (and there are nice bridges to DVCS for those that want to use them), we can now also more easily enable developers to work on complex or risky features in a branch instead of trunk. So for example if we feel like it will take us too long to come up with a unicode plan, then I would suggest to leave it out the next release and simply have the people that have an idea for an approach create a branch and work things out there. This way normal development in trunk can commence. Yes experimental branching shouldn't be a problem. I persoanlly would prefer if we just create php-src/experimental/ or php-src/developer/name/branch for this purpuse to not clutter branches/ with a million names. I'd actually like to bring up the question of going to DVCS for PHP. I know I was a vocal advocate against it before, but I've learned a bit since then. Anyone care to discuss? -- Gwynne smime.p7s Description: S/MIME cryptographic signature
Re: [PHP-DEV] Tests repository (was: Re: [PHP-DEV] PHP 6)
On Mar 12, 2010, at 5:33 AM, Pierre Joye wrote: Having tests in multiple branches is PITA. Hasn't anyone considered that the best way would be to move all tests into their own repository (directory..whatever :) in SVN..? Considering they are supposed to be used for testing against regressions and BC breaks, they should always be runnable using any PHP version? BC tests and easiness are two of the reasons why we have a donwloadable phpt packages on the windows download pages. Some changes / improvements are of course needed for the run-tests.php but IIRC, someone was rewriting it already? Can we use this svn link/external somehow? Having one module for the tests but you get them when checking out a php-src branch. Gwynne can certainly answer this question :) Yes, this is quite possible. It's not quite as clean and smooth as CVS' modules support was, which is a continuing source of annoyance to me about SVN, but it's not too terribly painful either. Just the usual svn:externals properly on the php-src branches pointing to whereever the tests end up will do nicely. For the record, my standing: PHP 5.4: -1 PHP 6: -1 PHP 7 with new Unicode stuff: +1 -- Gwynne -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC - class underloading -or- ancestor overloading
On Mar 12, 2010, at 9:28 PM, Chris Trahey wrote:
The old class is still there, think of it as if the inserted (overloading)
class extends the base (overloaded) class and any classes the were extending
the base now extend the inserted class. So as far as the runtime, it's
run-of-the-meill inheritance. Methods that are not re-implimented in the
inserted class are called in the original class, etc.
It could be implemented either at the time a class is loaded (when we see
'overloads' keyword) or perhaps in a function call:
overload_class('Library_Class', 'My_LibClass_Overload');
As for conflicts where multiple overloads are attempted, they could be in
sequence, such that you'd end up having an inheritance chain like this:
called_class -- second_overload -- first_overload -- Library_Class --
etc.
In Objective-C, one did this in the older days by calling NSObject's
-poseAsClass: method, which would replace the class you sent it to with the
class you specified. Nowadays that approach is strongly discouraged in favor of
method swizzling, a technique by which you replace a specific class'
implementation of a single method with your own (which, with a minor bit of
extra work, can call through to the original). Internally, it's done by
replacing the function pointer in the class' method table with a new one and
returning the old one. Zend's implementation is slightly more twisted than
libobjc's, amusingly enough, but it's still doable. This is the typical way for
a dynamic language to solve the problem you've described. In PHP I believe the
necessary work is already implemented in runkit via the function
runkit_method_redefine(). You need only install that, or refer to it to make an
extension of your own. If you want this functionality in core, file a feature
request. (I'm personally in favor of making a lot of runkit's dynamic class
tweaking abilities core).
As far as I understand your issue, this technique would solve it cleanly.
On Fri, Mar 12, 2010 at 8:11 PM, Etienne Kneuss col...@php.net wrote:
Hi,
On Sat, Mar 13, 2010 at 2:50 AM, Chris Trahey christra...@gmail.com
wrote:
Perhaps a new concept in class-based OO programming, I'm not sure.
Depending on your perspective you could call it ancestor overloading (or
upstream overloading) or class underloading.
We are increasingly developing with the aid of frameworks libraries. In
fact, this idea came from my current project using the Zend Framework.
These libraries, while greatly extensible, are also fairly
self-extending.
That is, they include many classes that extend many classes, which is
great.
As consumers of these libraries, we can extend the classes and consume
the
API however we please, but there is one sticking point.
We cannot change classes that many other classes extend without extending
or
changing each child class and then making sure that our code uses the new
class.
For a concrete example, I was working with the Zend_Form_Element
subclasses,
and I realized that I wanted to change some of the default behavior (in
Zend_Form_Element).
- at this point I will assume the reader understands why I wouldn't want
to
just start changing the Zend library files -
There are many subclasses of Zend_Form_Element. If you want to change the
default behavior for all of them, you have 3 choices currently:
1. Directly edit the Zend_Form_Element file in the library, -bad for
updates
other projects that use the library
2. subclass Zend_Form_Element and change declaration of the descendants
to
extend new class - same problems
3. extend each child class and implement those subclasses in your app
code
-very tedious and TONS of repeated code, breaks consistency of API for
developers.
There could be a better way, if we could insert a class into the family
tree.
And that's the heart of this idea, so I'll repeat it:
* insert a class into the family tree *
Image we do it using an alternative keyword to extends, such as
overloads.
Example:
class Library_Class { }
class Library_Subclass extends Library_Class {}
and then:
class My_LibClass_Overload overloads Library_Class{}
Now new instances of Library_Subclass actually extend
My_LibClass_Overload,
which extends Library_Class. The developer would then code
My_LibClass_Overload as if it were declared like this:
class Library_Class {}
class My_LibClass_Overload extends Library_Class {}
class Library_Subclass extends My_LibClass_Overload {}
But indeed the declaration of Library_Subclass would *not* have to
change.
This way developers could extend default functionality and have
*existing*
library classes pick up the new functionality without redeclaring
anything
in the library.
Downstream classes would still override any methods that they redeclare.
If
you wanted to have end-point classes in the library have different
behavior,
you would overload them
Re: [PHP-DEV] function call chaining
On Jan 19, 2010, at 5:54 PM, Alain Williams wrote: $eep-oop()-ork()-ah()-ah(); the newcomer will have to spend significant time rummaging around the source code to figure out what classes are involved. As opposed to: $oop = $eep-oop(); $ork = $oop-ork(); $ah = $ork-ah(); $ah2 = $ah-ah(); where it instantly becomes crystal clear! Come on, this argument of I could read any code without ever knowing anything about anything but you feature broke it is getting really stale. You couldn't, and the feature changed nothing. +1 At least with $eep-oop()-ork()-ah()-ah() you don't have stray/unwanted variables hanging round to confuse (or be misused) later. +1 It also supports the allocation is not initialization (or anti-RAII) pattern found in languages like Objective-C: Objective-C: String *s = [[String alloc] initWithFormat:@I'm a little teapot, %@ and %@, @short, @stout]; PHP: $s = (new String)-sprintf(I'm a little teapot, %s and %s, short, stout); (Obviously a very, very contrived example, meant only to illustrate the pattern.) -- Gwynne -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Debian PHP patches
On Jan 18, 2010, at 3:51 AM, Jani Taskinen wrote: Can you tell me what exactly we are breaking? divert calls should only be used internally by autoconf and the, apparently useless, usage of them in php makes it fail to build with any other autoconf. If you remove them, things break. I don't remember right now why, but it did, Rasmus tried this already and failed. Search the mailing lists for more. His commit message is a bit weird, I think it should say 2.6x is broken in so many ways rather than 2.13: http://svn.php.net/viewvc?view=revisionrevision=291414 If I remember right, removing the diverts makes the ./configure --help output no longer pretty. And 2.6x and 2.13 are both broken in their own lists of ways. Though I thought the use of high-numbered diversions was actually a supported thing - or was that only in 2.13? -- Gwynne -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Debian PHP patches
On Jan 16, 2010, at 4:18 PM, Jani Taskinen wrote: 115-autoconf_ftbfs.patch Hell no. You're breaking the configure again with this crap. I already reverted the idiocy once, don't even think about doing this shit again. PHP configure works properly only with autoconf-2.13 which was the last working autoconf. Which autoconf was the last working one is a matter of opinion at this point. The Autoconf people would love for us to stop using 2.13 - the only reason it still exists is because we use it. (Or so I'm told, anyway, I don't know this for a fact firsthand.) Personally, I'd rather see PHP go to CMake. CMake does have its own host of problems, but they could be dealt with. And yes, I would volunteer to revive the CMake effort. -- Gwynne -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Backporting bypass_shell and posix_pipe() from trunk to 5.3
Some while ago, I committed a patch to trunk which adds the shell_bypass option to proc_open() on UNIX. I'd like to backport that patch to 5.3.2, along with posix_pipe(), which helps quite a bit in using it. The patch can be found at http://pastebin.ca/raw/1691644. It's been tested and run through valgrind and the Clang analyzer. Any reason I shouldn't commit it? I tried to get it into 5.3.0 but the consensus at the time was let's get this out the door already :). -- Gwynne -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Secure SVN access
On Sep 3, 2009, at 8:56 AM, Richard Quadling wrote: 2009/9/3 techtonik techto...@php.net: Greeetings to php-core developers, Am I right that there is no https:// and svn+ssh:// access to svn.php.net repositories? If that's the case - how do you feel about sniffing developer's passwords? Please, CC. --anatoly t. Was this any different when using cvs? No, it wasn't. We ran into a number of problems attempting to set up https:// access to SVN, not the least of which was an outdated kernel on one of our boxes. Since then I've been waiting for word from Rasmus, who was trying to get the box upgraded, but I never got that word, so we're still http:// only. -- Gwynne -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Fwd: [PATCH] php bugtracker should set Precendence: bulk header
I'm the wrong person to send this email to. Forwarding to internals.
-- Gwynne
Begin forwarded message:
From: Cristian Rodríguez c...@cristianrodriguez.net
Date: August 10, 2009 12:14:08 PM EDT
To: gwy...@php.net
Subject: [PATCH] php bugtracker should set Precendence: bulk header
php bug tracker should set Precedence: bulk email header, otherwise
autoresponders generate replies to this messages..
CHeers.
Index: report.php
===
--- report.php (revisión: 287044)
+++ report.php (copia de trabajo)
@@ -179,7 +179,8 @@
$extra_headers.= X-PHP-Version: . stripslashes($in['php_version']) . \n;
$extra_headers.= X-PHP-Category: . stripslashes($in['bug_type']). \n;
$extra_headers.= X-PHP-OS:. stripslashes($in['php_os']) . \n;
- $extra_headers.= X-PHP-Status: Open\n;
+$extra_headers.= X-PHP-Status: Open\n;
+$extra_headers.= Precedence: bulk\n;
$extra_headers.= Message-ID: bug-$...@bugs.php.net;
if (DEVBOX || $cid === 46928) {
@@ -190,7 +191,7 @@
// mail to appropriate mailing lists
if (mail($mailto, #$cid [NEW]: $sdesc, $ascii_report.1\n-- \n$dev_extra, $extra_headers)) {
// mail to reporter
-@mail($email, Bug #$cid: $sdesc, $ascii_report.2\n, From: PHP Bug Database $mailfrom\nX-PHP-Bug: $cid\nMessage-ID: bug-$...@bugs.php.net);
+@mail($email, Bug #$cid: $sdesc, $ascii_report.2\n, From: PHP Bug Database $mailfrom\nX-PHP-Bug: $cid\nPrecedence: bulk\nMessage-ID: bug-$...@bugs.php.net);
header(Location: bug.php?id=$cidthanks=4);
exit;
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: PHP 5.3.1 RC 1
On Aug 7, 2009, at 11:39 AM, Lewis Wright wrote: http://bugs.php.net/bug.php?id=48880 is reason enough to want a release soon - PHP 5.3 died a very fast death in production here. for me too. this bug makes 5.3.0 unusable for me. svn is not an option for production environment. Thanks, Andre You can do an SVN export to get the code without the .svn files. Irrelevant. SVN code, with or without the .svn metadata, is considered unstable and is almost always unacceptable in a production environment. +1 for a 5.3.1 release ASAP. -- Gwynne -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Alternative mbstring implementation using ICU
On Jul 30, 2009, at 7:12 AM, Alexey Zakhlestin wrote: Implemented functions: - mb_ereg() - mb_ereg_replace() as ereg functions are deprecated in 5.3, are these still needed? these have nothing in common with those ereg functions. these are based on onuguruma regex library http://www.geocities.jp/kosako3/oniguruma/ I find Oniguruma to be, in general, a pared-down and less-useful version of the PCRE we already have. Given that PCRE has full support for UTF-8, and that there's nothing you can do with Oniguruma that you can't also practically do with PCRE (to the best of my knowledge), I think it would be best for PHP to standardize on a single regexp library, rather than offering competing and confusing options. Killing off POSIX syntax was a step in that direction, and I see no reason not to take the rest of the steps. If Oniguruma were offered as a PECL extension, I would think that perfectly reasonable, but I don't think it belongs in core. -- Gwynne -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Alternative mbstring implementation using ICU
On Jul 30, 2009, at 11:27 AM, Stefan Walk wrote: and that there's nothing you can do with Oniguruma that you can't also practically do with PCRE (to the best of my knowledge), http://www.geocities.jp/kosako3/oniguruma/doc/RE.txt - Paragraph 8, example 2 - specifying the nest level for subroutines/back references doesn't work with pcre. That's one example I know from the top of my head ... Granted :). But it would be possible to rewrite that example into a PCRE regexp, just a bit less efficiently. Subroutine calls *are* one thing I like about Oniguruma, but not enough to counter all the other arguments in favor of PCRE. Honestly, that sort of extension to the syntax verges on kicking regexp out of the domain it was intended for; function calls are verging on making regexp trivially Turing-complete. If you need that level of matching, it's probably time to consider more aggressive string parsing methodology, such as tokenization. Regexp is basically a VM (at least as most implementations handle it), and on nontrivial patterns will often be slower than other methods. Certainly that particular example, matching an XML tag, will never deal with all the esoteric cases. You can approach perfect matching as pattern complexity approaches infinite (i.e. lim complexity-inf correctness = inf), but the pattern is only realistically useful in specific cases where you can be guaranteed a valid input stream. And supposing it doesn't match, there's no reasonable way to determine *why*. Also, more to the point, Oniguruma hasn't been updated in two years and counting, which is enough to count it as unmaintained. PCRE is still seeing releases on a regular basis. -- Gwynne -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Bug 42194 Open
On Jul 27, 2009, at 4:22 PM, Kenan Sulayman wrote: Regarding:42194 Open $argc/$argv[] won't work when .php extension is assigned to php.exe Hi Folks! Isn't it supposed to NOT pass the parameters when a script is called passively? For instance, we assume I'd call: | script.php abc def ghi | Whilst no binary given, Windows will map the call as: | %phpdir%\php.exe script.exe | Windows tends, as far as I know, to only pass the first parameter ( script.php ) - which makes PHP unable to find the other parameters. So - am I right, or is that fixable? Have a nice day, Kenan Sulayman If you have something to say about a bug, please post it as a comment on the bug report itself. You can do so using the interface at http://bugs.php.net/bug.php?id=42194edit=3 . -- Gwynne -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: svn: /php/php-src/branches/PHP_5_3/ext/gd/ libgd/gdft.c tests/bug48555.phpt tests/bug48732.phpt tests/bug48801.phpt
On Jul 27, 2009, at 6:31 PM, Takeshi Abe wrote: Just to be sure, is there any consensus on this? I thought I should use svn merge. README.SVN-RULES says 1. All changes should first go to trunk and then get merged from trunk (aka MFH'ed) to all other relevant branches. which I've been following so far. That document is outdated. It's now (strongly) preferred that you use one of the various methods for multi-branch commits available in SVN, using merge or a sparse checkout. -- Gwynne -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Another tiny syntax patch
For the sake of the heck of it, I'm gonna offer up this tiny patch I'm
using in one of my projects. I don't really care if it gets included
in anything or not, just thought it might interest someone.
Effect: Adds a ?php= syntax which behaves identically to ?=, but
works without the use of short_tags.
Caveat: The formation ?php= is not valid XML. Specifically, section
2.6 of [1] defines a PITarget as a Name, which in turn is made up of
NameChars (section 2.3), which do not include the = character.
Advantage: Saves five characters of typing. ?php= $myvar ? versus
?php echo $myvar; ?.
Just thought I'd throw it out there.
Index: Zend/zend_language_scanner.l
===
--- Zend/zend_language_scanner.l(revision 286353)
+++ Zend/zend_language_scanner.l(working copy)
@@ -1537,6 +1588,15 @@
}
+INITIAL?php= {
+ zendlval-value.str.val = yytext; /* no copying - intentional */
+ zendlval-value.str.len = yyleng;
+ zendlval-type = IS_STRING;
+ BEGIN(ST_IN_SCRIPTING);
+ return T_OPEN_TAG_WITH_ECHO;
+}
+
+
INITIAL?php([ \t]|{NEWLINE}) {
zendlval-value.str.val = yytext; /* no copying - intentional */
zendlval-value.str.len = yyleng;
[1] Extensible Markup Language (XML) 1.0 Fifth Edition,
http://www.w3.org/TR/2008/REC-xml-20081126/
-- Gwynne
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Another tiny syntax patch
On Jul 26, 2009, at 5:17 AM, Rasmus Lerdorf wrote:
We have talked about this before, and the conclusion was that if we
are
going to have an invalid PI, we might as well make it ?= since it is
just as invalid as ?php= and just as easy to parse. Now you save 8
chars.
I prefer strong namespacing of all my tags. ? and ?= are highly
generic and could be usurped by any other (admittedly finctional so
far) processing system run on the file.
As I said, it was just for the heck of it :). I know no one's likely
to find it interesting.
I did toy with the idea of something that was actually compliant, but:
?php. - is not visually distinctive
?php- - same
?php.e - saves very little typing and is ugly
?phpe - mucks with the entire idea of being namespaced
?php e - visually confusing and saves little typing
And so forth.
Gwynne Raskind wrote:
For the sake of the heck of it, I'm gonna offer up this tiny patch
I'm
using in one of my projects. I don't really care if it gets
included in
anything or not, just thought it might interest someone.
Effect: Adds a ?php= syntax which behaves identically to ?=,
but
works without the use of short_tags.
Caveat: The formation ?php= is not valid XML. Specifically,
section
2.6 of [1] defines a PITarget as a Name, which in turn is made up of
NameChars (section 2.3), which do not include the = character.
Advantage: Saves five characters of typing. ?php= $myvar ? versus
?php echo $myvar; ?.
Just thought I'd throw it out there.
Index: Zend/zend_language_scanner.l
===
--- Zend/zend_language_scanner.l(revision 286353)
+++ Zend/zend_language_scanner.l(working copy)
@@ -1537,6 +1588,15 @@
}
+INITIAL?php= {
+zendlval-value.str.val = yytext; /* no copying - intentional */
+zendlval-value.str.len = yyleng;
+zendlval-type = IS_STRING;
+BEGIN(ST_IN_SCRIPTING);
+return T_OPEN_TAG_WITH_ECHO;
+}
+
+
INITIAL?php([ \t]|{NEWLINE}) {
zendlval-value.str.val = yytext; /* no copying - intentional */
zendlval-value.str.len = yyleng;
[1] Extensible Markup Language (XML) 1.0 Fifth Edition,
http://www.w3.org/TR/2008/REC-xml-20081126/
-- Gwynne
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [PEAR-DEV] Tagging releases
On Jul 23, 2009, at 9:21 PM, Gwynne Raskind wrote: Today, I just release a new version of the Log package, and I attempted to tag this release in the same way. Unfortunately, I ran into this error: $ svn copy \ http://svn.php.net/repository/pear/packages/Log/trunk \ http://svn.php.net/repository/pear/packages/Log/tags/RELEASE_1_11_5 svn: MERGE request failed on '/repository/pear/packages/Log' svn: MERGE of '/repository/pear/packages/Log': 409 Conflict (http://svn.php.net ) I'm not sure if I've done something wrong or if that's a server-side problem, however. Any advice, or is this something for the svn-migration crew? This is my error; committing to any tags directory is forbidden, but doesn't correctly allow the case of creation of a tag. You should have gotten an error to this effect on your side; apparently, for whatever reason the output made it to the server error log but not back to you. I'll update you when I've fixed the hook to allow tag creation; it shouldn't be too long. And I'm happy to announce that this is now fixed; creation of tags is now allowed. This comes alongside a bit of an overhaul of the entire set of hook scripts. See http://news.php.net/php.cvs/59765 if you're desperately curious :). -- Gwynne -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: svn checkout suggestion
On Jul 20, 2009, at 6:40 AM, Jani Taskinen wrote: Can I suggest you not to suggest any other VCS from now on? If you like some VCS better, just keep that info to yourself, no need to spam the mailing lists about it. More to the point, there was a considerable amount of controversey over whether to use SVN or Git for PHP. We decided on SVN. We also have a Git mirror. In short, you're telling us what we already went over sixteen dozen times and dealt with. -- Gwynne, PHP's SVN maintainer On 07/20/2009 01:38 PM, Arnold Daniels wrote: Hi, Can I suggest having a look at GIT (http://git-scm.com). It has some mayor advantages above SVN. The most important one is that it's a distributed version control system. Let's say Rasmus leads a team working on a new feature in PHP to switch from .ini to .yaml files for configuration. With GIT it's not needed that the whole team has commit access to the main GIT repository. Rasmus can checkout PHP to his own server. The team can checkout and commit to Rasmus' server. Rasmus still update the checkout of his server to get the changes made in the main PHP repo. When Rasmus is satisfied that the feature works, he (and only he) can commit it to the main repo. If you look at the linux kernel, you see that there is a whole hierarchy. There are lieutenants who are responsible for a certain part of the kernel. The lieutenant has got a small team working on that part. Each team member, may have a team of his own working on a specific feature. I would think a structure like this would work very nicely for PHP. - Arnold On Thu, 2009-07-16 at 18:09 -0500, Greg Beaver wrote: Rasmus Lerdorf wrote: One of the benefits of svn is that we can do cross-branch commit pretty easily now and thus avoid multiple similar commits with annoying MFH/MFB commit log messages that are hard to track. Please don't attempt to check out all of php/php-src or pecl. I made the mistake of checking out all of pecl and it was 3.4G because you get copies of the code for every tag and branch and we have a bunch. In order to do this better, I think the best way is to use the sparse directory feature documented here: http://svnbook.red-bean.com/en/1.5/svn.advanced.sparsedirs.html snip Rasmus this is brilliant. You should add this to the manual for posterity in your new shiny checkout of awesomeness. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] A patch for HEAD
Alright, I've implemented pretty much every single suggestion you
made :). Note that _php_array_to_envp() actually suffers the same
modify in place problem, but because it iterates the array twice (is
that REALLY so much better than allocating a few extra pointers or
calling perealloc() a few times?), the fix for it isn't trivial, so I
left it alone. The updated patch is (again) posted at:
http://darkrainfall.org/php-5.3-shellbypass.patch
On Jul 15, 2009, at 4:20 PM, Nuno Lopes wrote:
Hi,
So the patch looks generally good. Here are some minor comments
about it:
- I believe _php_array_to_argv() doesn't need TSRMLS_DC. If that's
the case, please remove it.
- in _php_array_to_argv() you modify the input array destructively
(when calling convert_to_string_ex). You should not modify the input.
- in _php_array_to_argv(), HASH_OF will never return NULL (because
we already know that it's an array).
- apparently the check 'if (cnt 1) {' will never be true, as the
array will always have one element. please verify that this special
case does what you want (maybe change to 'cnt = 1')
- argvs with length==0 are perfectly valid, and so you shouldn't
skip them.
- the api is a little inconsistent, as you use the idx 0 to retrieve
the command name, but then you use the array order to retrieve the
rest of the elements (and thus if the idx 0 doesn't appear in the
beginning your code will fail). I would just stick with the array
order. e.g. array(1='/usr/bin/echo', 0='foo') or similar should
print 'foo'.
- in exit_fail you can remove the check for bypass_shell, as
_php_free_argv() will check the argument against NULL.
- the line 'proc-argv = (bypass_shell ? child_argv : NULL);' can be
simplified to 'proc-argv = child_argv;' since child_argv is already
initialized to NULL
I think that's it :) It's only minor things, I guess.
As soon as you fix these things, please go ahead and commit the
patch, or mail it back to the ML in case you need me to do it.
Nuno
- Original Message - From: Gwynne Raskind gwy...@darkrainfall.org
To: PHP internals internals@lists.php.net
Sent: Friday, June 26, 2009 10:20 PM
Subject: [PHP-DEV] A patch for HEAD
I've just finished making this patch for my own use (diffed
against 5.3 CVS):
http://darkrainfall.org/php-5.3-shellbypass.patch
In short, what it does is make proc_open()'s shell_bypass option
available to UNIX systems. This is accomplished by allowing the
command parameter to proc_open() to be an array of arguments to
pass to execv[e](). I've included a few tests to check the
functionality.
(A few more tests could be devised to, for example, check that the
correct warning is issued if you pass an array without
bypass_shell set, or a string with it set, etc.)
The exact behavior of the argument array is:
1) The array must contain at least one element, at index 0.
2) The element at index 0 is always the exact command path passed
to execv[e]() (after being filtered through any safe_mode
restrictions, as with the normal behavior of proc_open()).
3) Any other elements form the argv array passed to execv[e](). By
convention the first of these arguments (argv[0] in the child
process) is the same as the command path, however my patch does
NOT enforce or assume this; it simply calls execv[e]
($argument_array[0], array_slice($argument_array, 1)).
This patch currently provides the only useful way to fork a process
without running a shell (pcntl_fork() + pcntl_exec() are useless
since there's no pcntl_dup2() to control the descriptors of the
child).
Why would you want to avoid the shell?
- Efficiency. The shell is an extra, often unnecessary process,
which must parse the commandline given to it into individual
arguments according to all its various rules. Not to mention the
overhead of setting up another entire process just to run a third
process.
- Resource control. The shell is an extra process. If you don't
need it, and your system is tight on process space, best to avoid
it.
- Sanity. Correctly quoting arguments to a shell command ranges
from mildly annoying (escapeshellarg() in simple cases) to
nightmarish (manual parsing of a string in some edge cases).
Passing arguments directly completely bypasses this, quite
possibly saving you quite a bit of string parsing time if you were
doing something like $shell_args = implode(' ',
array_map('escapeshellarg', $raw_args));.
- Oddly enough, security. Since there's no shell, it's more
difficult to subvert the child process to do other things than the
coder intended (unless of course, said coder executes a shell this
way).
This patch does nothing on Windows, since the option was already
implemented there. It also does nothing on Netware, since from what
I could see in the code, Netware doesn't have a shell in the first
place.
I'm proposing the inclusion of this patch in HEAD (which I'll port
Re: [PHP-DEV] Renaming php-cvs to php-svn ?
On Jul 16, 2009, at 6:19 PM, Jani Taskinen wrote:
Or just to something more generic like php-commits@ ? The same with
zend-commits?
Only php-commits@ is necessary since there is no separate Zend stuff
anymore..?
Zend commits are still sent separately. From commit-email.php:
'|^php/ZendAPI|' = array('zend-engine-...@lists.php.net', 'doc-...@lists.php.net
'),
'|^php/php-src/Zend|' = array('zend-engine-...@lists.php.net'),
'|^php/php-src/TSRM|' = array('zend-engine-...@lists.php.net'),
I'm personally very much in favor of a rename to php-commits etc.
From commit-email.php (again), the list of lists that could be renamed:
php-gtk-...@lists.php.net
zend-engine-...@lists.php.net
doc-...@lists.php.net
pear-...@lists.php.net
pecl-...@lists.php.net
gd-...@lists.php.net
embed-...@lists.php.net
php-...@lists.php.net
-- Gwynne
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [PHP-CVS] Commit freeze is officially over
On Jul 14, 2009, at 4:36 PM, Knut Urdalen wrote: Any other issues, please bring them to my attention. Preferably via email, not IRC :). Are we going to have a similar page like the one for Anonymous CVS Access [1] for svn.php.net? Please in the future avoid cross-posting to seven lists; use svn- migration@ for this kind of question. To answer the question, anonsvn.php has already been commited to phpweb and should show up as soon as we get rsync back in service. -- Gwynne -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [PHP-CVS] svn: php/php-src/trunk/win32/build/
On Jul 13, 2009, at 12:51 PM, Pierre Joye wrote: pajoye Mon, 13 Jul 2009 16:11:45 + ViewVC URL: http://svn.php.net/viewvc?view=revisionrevision=284019 Changed paths: A php/php-src/trunk/win32/build/svnclean.js Log: - rename to svn Copied: php/php-src/trunk/win32/build/svnclean.js (from rev 284013, php/php-src/trunk/win32/build/cvsclean.js) === (Binary files differ) ..binary? Let me guess: your editor still adds that BOM automatically to all files you open? :D No, it has to be set in the svn repo directly, afaik Gwynne is on it. I've now made five or six attempts to fix this, all of which obviously missed at least some affected files. Everyone who runs accross a file with this problem, please execute: svn propdel svn:mime-type path to affected file Before you commit if possible, or afterwards and re-commit otherwise. -- Gwynne -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Commit freeze is officially over
As of right now, I'm declaring SVN open to full time use. Commit away, everyone! There are still a number of issues to resolve, but development's been held up too long. We'll fix the issues as we go. Some known issues: - Rsync is still down. Derick's working on this. - SVN access over HTTP is slow. We're looking into making svnserve available. - phpdoc is more or less completely broken. Ahem, Philip and Hannes. - gd was imported incorrectly. I'm looking into fixing this, but it may require taking the repo down for a few hours at some point. - There's no svnsync to replace CVSup yet. I'm also looking into that. - Several of the PHP boxes are still seeing cronjob failures. Pierre's working on that. - There's no announcement on the PHP front page about the move. I'll poke someone to do something about that. Any other issues, please bring them to my attention. Preferably via email, not IRC :). -- Gwynne -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] SVN Conversion Complete
The conversion from CVS to SVN is complete. CVS read AND write access has been completely disabled. SVN is now up and running, however *we remain in commit freeze* until Monday. Commits to SVN in order to fix critical problems (such as all those scripts which should have been made ready a long time ago) are accepted. All information on the subject is available at http://wiki.php.net/vcs/svnfaq . The SVN repository URL is http://svn.php.net/repository. The ViewVC (SVN) URL is http://svn.php.net. Once again, ONLY commits that relate to fixing CVS-SVN migration issues are allowed. We remain in commit freeze. Everyone who has issues, please put them on svn- migrat...@lists.php.net. I'll be around all weekend, and all of us will respond to issues as quickly as we can. -- Gwynne -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Type hinting/casting request for vote
On Jul 7, 2009, at 1:17 PM, Andrei Zmievski wrote: I would like to ask all developers to voice their opinions of whether it makes sense to add this to 5.3 or to throw it away (either one is fine btw). To keep the process simple flamewar free, please restrict yourself to +/- (1/0), next week monday I'll run a tally of the votes and based on the result we can determine how to proceed further. +1. Sorry, I should have read better. My +1 was for the feature in general, not for 5.3. I think we should concentrate most of the new feature development on 6.0, now that 5.3 is out to avoid having yet another feature-filled 5.x release. So, once again, completely against this going into 5.3. Same here. +1 for HEAD, -1 for 5.3. -- Gwynne -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Veracity of statement that FastCGI is always enabled cannot be disabled in PHP 5.3
I apologize for the top-quoting, but it seemed appropriate here. It seems the language of the documentation is unclear. It is not that the CGI SAPI (now called the CGI-FCGI SAPI) is always built, in the fashion of CLI. It is, precisely, that the FastCGI support within the CGI SAPI can no longer be turned off. However, the SAPI selection process still procedes as it did before. I'll see what we can do about clarifying the documentation. Sorry for the confusion :). -- Gwynne On Jul 3, 2009, at 11:39 AM, Ryan Schmidt wrote: Hi. I'm the maintainer of PHP in MacPorts and I'm in the process of updating our php5 port to version 5.3.0. I originally posted this message to the php-install list but was asked via private mail from Christopher Jones to re-post it here on the internals list. http://marc.info/?l=php-installm=124654253527650w=2 In PHP 5.2.x and earlier you had to choose which web SAPI you wanted -- Apache 1, Apache 2, or FastCGI. The CLI SAPI was always built in any case, in addition to the web SAPI you selected, but you couldn't have both an Apache SAPI and the FastCGI SAPI built at the same time; you had to run ./configure and make twice each, and this is what my php5 port currently does to allow a user to install both an Apache SAPI and the FastCGI SAPI at the same time if desired. On http://www.php.net/manual/en/migration53.sapi.php it says of PHP 5.3 that FastCGI is now always enabled and can not be disabled. See sapi/cgi/CHANGES for more details. The same text appears in the NEWS file. In sapi/cgi/CHANGES it says Now fastcgi is always enabled. Based on these statements, I assumed the FastCGI SAPI would now always be built, just like the CLI SAPI always gets built. But it appears that if you use --with-apxs2 or --with-apxs, PHP 5.3 does in fact disable the FastCGI SAPI, and only builds the Apache and CLI SAPIs, just like PHP 5.2.x did. sapi/cgi/CHANGES also states In PHP5.3 all additional configure options (except --enable-cgi) are removed and ./configure --help lists the option --disable-cgi Disable building CGI version of PHP. Using --disable-cgi, the FastCGI module does not get built. So I believe the statement FastCGI is now always enabled is false, because FastCGI is not enabled if you request an Apache SAPI. And I believe the statement that it can not be disabled is false, because the --disable-cgi configure argument does disable it. I believe the correct documentation of PHP 5.3's capabilities would be, The FastCGI module is now built by default, but can be disabled by using --disable-cgi. Note: I did the above tests using 5.3.0RC4 not 5.3.0 final. This is my first time posting to a PHP mailing list. I wanted to check here for guidance before filing a bug for these issues. I searched Google and the mailing list archive at marc.info and couldn't find a prior discussion of these issues relating to PHP 5.3, but if there is one and I've missed it I'd of course appreciate a link to it. P.S: There is a typo on the mailing lists page's description of the php-install list. It says How to install PHP with partiucular configurations, and servers. That should be particular not partiucular and the comma should be removed. http://www.php.net/mailing-lists.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Tiny correction to type hinting patch
In Ilia's type hinting patch, on line 255, is the line:
+ST_IN_SCRIPTINGstring|binary|unicode {
This failed for me. I fixed it by changing it to:
+ST_IN_SCRIPTING(string|binary|unicode) {
Which matches all the other lexing rules for type hints. My
understanding of the lexer is insufficient to understand why this
particular set of parenthesis makes any difference at all, but there
you have it.
-- Gwynne
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Type hinting revisited for PHP 5.3
On Jul 1, 2009, at 12:59 PM, Ilia Alshanetsky wrote: There has been quite a bit of discussion on this list, IRC, developer meetings, etc... about introduction of type hinting to PHP. Most people appear to think that this would be a good idea, but there is a reason why it is not in PHP already. The main source of conflict appears to be that in some cases typical type hinting is just too strict for PHP's typeless nature (most people expect that 1 == 1, while int type hint would definitely reject string 1). Personally, I disagree with that opinion, but I can understand people who raise that issue. At work we've been using PHP 5.2 with type hinting for nearly 2 years now with great success, it makes code much easier to read and understand and the security benefit of type hinting is not to be under valued. In many cases type hinting can present a last line of defense against unexpected input for numeric fields, which are typically abused to do SQL injection. [snip] My hope is that the latest changes will allow this to become a standard part of PHP. +1 (+1000, actually :) -- Gwynne -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] CGI and FastCGI SAPI
On Jul 1, 2009, at 2:37 PM, Gelu Kelunden wrote: I think that the official FastCGI implementation will eventually evolve into something like PHP-FPM, if not even more. What I'm saying is that code that handles daemonization (uid/gid/ chroot/log), workers mgmt (spawing/safe-shutdown), daemon config file (not php.ini or php-cgi.ini) should not be present in the pure CGI SAPI implementation, but in a different FastCGI-only SAPI. This seems to me as if it would be a step backwards. For a long time CGI and FastCGI were highly separate setups; you had to use configure flags to enable FastCGI, and so forth. In 5.3 they were unified completely: you can't have one without the other anymore. Why would you need to? -- Gwynne Michael Shadle mike...@gmail.com wrote in message news:bd9320b3090707q4fc2c2c3hbffbf289679e6...@mail.gmail.com ... I think it would be a good idea to also include PHP-FPM in your investigation. On Wed, Jul 1, 2009 at 11:02 AM, Gelu Kelundengelu.k...@gmail.com wrote: Hi, I'm trying to understand how difficult it is to create a new SAPI, so I started to poke my nose inside the cgi SAPI source code. I saw that cgi_main.c implements both the CGI and the FastCGI protocols and I kinda got lost inside all those if-else lines (I tried to take out the FastCGI code and failed miserably). I'm wondering if it's not better to have 2 different SAPIs, one for CGI and for FastCGI. Advantages of this split would be: - the source code will be more readable without all those if-else statements - we would have 2 executables that do 2 different jobs, unlike now where php-cgi does both; each executable could then be further optimized for the exact job they are performing Disadvantages I see: - maintaning 2 SAPI implementaion would require more work (since CGI and FastCGI both share most of the SAPI code, any change would have to be replicated twice) - break backward compatibility (where php-cgi handles both CGI and FastCGI) Thank you for your time, Gelu -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [SVN-MIGRATION] Re: [PHP-DEV] post 5.3.0 development
On Jun 26, 2009, at 2:22 PM, Hannes Magnusson wrote: We would like to up hold the commit freeze until 5.3.0 is announced next Tuesday. And the move to SVN? It'll require a complete cvs.php.net freeze for couple of days, I think? Yes, but it's not ready for that yet; an unfreeze after 5.3's release won't kill anyway. But keep in mind that the SVN freeze will freeze PEAR and PECL and GTK and... well, everyone. Once CVS write access is shut off, it'll never be turned back on (unless there's a problem with SVN). Whereas this freeze is just on PHP itself. -- Gwynne -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] A patch for HEAD
I've just finished making this patch for my own use (diffed against
5.3 CVS):
http://darkrainfall.org/php-5.3-shellbypass.patch
In short, what it does is make proc_open()'s shell_bypass option
available to UNIX systems. This is accomplished by allowing the
command parameter to proc_open() to be an array of arguments to pass
to execv[e](). I've included a few tests to check the functionality.
(A few more tests could be devised to, for example, check that the
correct warning is issued if you pass an array without bypass_shell
set, or a string with it set, etc.)
The exact behavior of the argument array is:
1) The array must contain at least one element, at index 0.
2) The element at index 0 is always the exact command path passed to
execv[e]() (after being filtered through any safe_mode restrictions,
as with the normal behavior of proc_open()).
3) Any other elements form the argv array passed to execv[e](). By
convention the first of these arguments (argv[0] in the child process)
is the same as the command path, however my patch does NOT enforce or
assume this; it simply calls execv[e]($argument_array[0],
array_slice($argument_array, 1)).
This patch currently provides the only useful way to fork a process
without running a shell (pcntl_fork() + pcntl_exec() are useless since
there's no pcntl_dup2() to control the descriptors of the child).
Why would you want to avoid the shell?
- Efficiency. The shell is an extra, often unnecessary process, which
must parse the commandline given to it into individual arguments
according to all its various rules. Not to mention the overhead of
setting up another entire process just to run a third process.
- Resource control. The shell is an extra process. If you don't need
it, and your system is tight on process space, best to avoid it.
- Sanity. Correctly quoting arguments to a shell command ranges from
mildly annoying (escapeshellarg() in simple cases) to nightmarish
(manual parsing of a string in some edge cases). Passing arguments
directly completely bypasses this, quite possibly saving you quite a
bit of string parsing time if you were doing something like
$shell_args = implode(' ', array_map('escapeshellarg', $raw_args));.
- Oddly enough, security. Since there's no shell, it's more difficult
to subvert the child process to do other things than the coder
intended (unless of course, said coder executes a shell this way).
This patch does nothing on Windows, since the option was already
implemented there. It also does nothing on Netware, since from what I
could see in the code, Netware doesn't have a shell in the first place.
I'm proposing the inclusion of this patch in HEAD (which I'll port it
to if I get a thumbs-up here), and possibly 5.3.2. Criticism and angry
flames welcome. Constructive critcism and good-natured comments will
be ignored ;) (just kidding... or am I?).
-- Gwynne
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [PEAR-DEV] Re: Keeping CVS? was - Re: [PEAR-DEV] CVS 2 SVN
On Jun 25, 2009, at 11:41 AM, Joe Stump wrote: Once we're using GitHub, what are the benefits? For me, they are as follows: 1. Built in bug tracking and wiki. 2. Fork Queue. I can't even begin to express the awesomesauce that is the Fork Queue. Ever get a patch to your project as an attachment in a bug and be too lazy to download, apply and commit? No worries, Fork Queue lists the patches from forks of your project and allows you to apply them quickly from a web interface. 3. A byproduct of GitHub is Git. Git was built by the leader of the largest FOSS project on the planet to meet his specific needs for managing a large, distributed, FOSS coding effort. I feel Git fits in SUPER well with PEAR2's notion of having mini-groups managing each category of packages as members can push code upstream to group leaders, etc. 4. Tons and tons of community features, wizbang features, etc. that, quite frankly, we're too busy or lazy to implement ourselves. Signing up is free so I'd sign up and play around with it if I were you. I was skeptical at first as well, but am happily chugging the kool-aid now. :) For those of you who aren't on the svn-migration mailing list, GitHub has been investigated extensively by several people among the core PHP devs. A number of arguments were made both in favor of and against it, and no solid consensus was ever reached. At this point in time, the SVN move is about 98% complete, and despite the constant flow of Git love, we intend to go through with the SVN move as soon as possible after the release of PHP 5.3.0. As Andrei says, the work gap between CVS and SVN is much smaller than between CVS/SVN and git. We're switching to SVN. We may or may not investigate switching to Git sometime in the future, but that time is not now. Everyone, please see http://news.php.net/php.internals/44411 for more info on what you can do to help with the move and what you'll need to do to be ready for it. -- Gwynne -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] header_remove() issues (overly aggressive?)
On Jun 23, 2009, at 3:49 PM, Johannes Schlüter wrote: While documenting header_remove() I was experimenting a little bit.. If an empty argument is passed to the function (empty string, null, false,..) the function doesn't do anything, as it checks for ZEND_NUM_ARGS() rather then the length of string.. thats a doc issue or bug? I'd say it's ok, remove the header with the name ''. That's what it does. A header named '' isn't valid in HTTP 1.0 or 1.1 anyway; this is an error case IMO. Second, it removes even the X-Powered-By header, is that expected? Useful for people who don't have control over their expose_php setting... Third, it removes session and even cookie headers.. Is that really expected? Just add a big fat warning on the doc page? It removes all. Should be ok, too, removing the session cookie might even be considered a good feature by some. Including me! ;) -- Gwynne -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] CVS to Subversion move progress
In the last two days I've made some significant improvements to the migration process for CVS - SVN. I know many have been proponents of Git, but SVN is closer to being viable at this point. Crossposting to internals@ so that more people have a chance to look into it, I'm calling for everyone to slam the hell out of the SVN repository (synchronized to CVS HEAD as of 2009-06-20 10:46:00 GMT, BUT NOT SYNCHRONIZED SINCE). To answer a FAQ, the SVN and CVS repositories will NOT be automatically synchronized, EVER. Throw everything you can at it. See if anything's wrong with it, see whether there are packages missing or mis-converted or needing adjusment or anything at all. If you have an issue, tell me and I'll do my best to deal with it. When I say torture it, I mean go freaking nuts. Commit to things you shouldn't have access to. Muck with the avail files. You get the idea. A short quickdirty guide to using PHP's SVN can be found at http://darkrainfall.org/phpsvn-guide.html . It is STRONGLY recommended, even for those who've helped with testing SVN before. There are some new gotchas to be aware of. This is a good time to start thinking about dealing with converting your scripts to SVN where they depend on CVS. This means cronjobs, revision number processors, changelogs, etc. The result of intval(`svn cat http://svn.php.net/SVNROOT/trunk/svn-switch`) can be used as a runtime switch to choose between CVS and SVN behavior; it will always be zero before the switch and one after it. (Keep in mind that this approach involves network I/O and the availability of the svn command on the server the script runs on.) When the time for the move comes, here's what'll happen (rough outline, subject to change): 1) All CVS write access will be disabled. Read-only access will remain. 2) The SVN conversion script will be run (this takes roughly 18 hours). 3) Any scripts that need to be manually switched will be so switched. 4) The content of svn-switch will be changed to 1. 5) SVN write access will be enabled. 6) ??? 7) Profit P.S. If someone could crosspost this to pear-dev@, I'd be quite grateful; I can't seem to get subscribed to it. -- Gwynne -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Results of running the entire testsuite with valgrind
I ran the entire PHP testsuite (as compiled on my system) under valgrind for Darwin and came up with quite a mess of leaks and a couple of crashes. The results file is quite ginormous, so I uploaded it to my site for the morbidly curious to have a look at: http://darkrainfall.org/php_test_results_valgrind.txt Some caveats about these results: - Darwin's valgrind doesn't support the symlink() syscall, so all tests using symlink() broke. - I didn't provide the proper environment variables for MySQL to connect, so all those tests broke too. - There seem to be several valgrind-caught bugs in OpenSSL 0.9.8k that aren't caught by valgrind's suppression files or OpenSSL's PURIFY flag, so you'll have to wade through those pointless warnings. - Two tests crashed HARD when run (with or without valgrind): ext/standard/tests/strings/str_pad_variation5.phpt (SIGBUS on NULL pointer) tests/output/ob_011.mem (SIGSEGV on unmapped non-NULL pointer) -- Gwynne -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Call for a doc push
On Jun 21, 2009, at 6:23 AM, zoe wrote: Guys and gals, in the old days we had a very close tie between the code and the documentation. As the project has grown the two have drifted apart. I think this is mostly because the phpdoc team has done an amazing job keeping up with the code changes and writing awesome documentation. This has made us a bit lazy and complacent. I would like to encourage everyone on this list to spend a little bit of time looking at the parts of the documentation that cover things you are familiar with. Or even just going through some of the doc bugs and helping out in general. This reminded me that a while ago I made some opcode documentation available in the form of a set of charts written by Andy Wharmby (http://www.zapt.info/PHPOpcodes_Sep2008.odp ) and some opcode samples (http://www.zapt.info/opcodes.html) from the IBM Japan team. I don't think either of these ever made it the PHP docs and as they are still on my personal website and they are somewhat at risk :-/ I heard recently that people were using them (http://tr.im/phpcompilerinternals ) so I'd like to put them somewhere more permanent. My current plan is to move them both to sp1.php.net. Does anyone object? Or better still would anyone be willing to integrate them with the PHP docs? Zoe, have a look at http://news.php.net/php.doc.cvs/4180 :). I don't have anything that can read that ODP file you linked (at least, not in any useful sense), but the opcodes.html file is all there. With any luck, someone else will come along and clean it up a bit, and/or expand on it. -- Gwynne -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Patch for bug #48575
Here is a nice simple patch for #48575 which rips out the mach-o/ dyld.h functionality in Zend (as suggested by the original reporter and the Apple comment). According to my testing this not only doesn't break anything, but actually doesn't change anything either except removing some dead code and removing one configure check. Per Pierre's request, I'm sending it here for review :) -- Gwynne -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Patch for bug #48575
On Jun 18, 2009, at 10:46 AM, Gwynne Raskind wrote:
Here is a nice simple patch for #48575 which rips out the mach-o/
dyld.h functionality in Zend (as suggested by the original reporter
and the Apple comment). According to my testing this not only
doesn't break anything, but actually doesn't change anything either
except removing some dead code and removing one configure check. Per
Pierre's request, I'm sending it here for review :)
And now, the patch itself! I hope. *fanfare*
-- Gwynne
Index: configure.in
===
RCS file: /repository/php-src/configure.in,v
retrieving revision 1.678
diff -u -r1.678 configure.in
--- configure.in18 May 2009 21:28:42 - 1.678
+++ configure.in18 Jun 2009 14:38:47 -
@@ -483,16 +483,6 @@
#endif
])
-dnl Don't use mach-o/dyld.h on Darwin 8+, dl* is recommended by Apple from
there on
-dnl See
http://developer.apple.com/documentation/DeveloperTools/Conceptual/MachOTopics/Articles/loading_code.html
-case $host_alias in
- *darwin[[89]]*)
-;;
- *)
-AC_CHECK_HEADERS([mach-o/dyld.h],[],[],[])
-;;
-esac
-
PHP_FOPENCOOKIE
PHP_BROKEN_GETCWD
PHP_BROKEN_GLIBC_FOPEN_APPEND
Index: Zend/Zend.m4
===
RCS file: /repository/ZendEngine2/Zend.m4,v
retrieving revision 1.70
diff -u -r1.70 Zend.m4
--- Zend/Zend.m44 Jun 2009 18:18:46 - 1.70
+++ Zend/Zend.m418 Jun 2009 14:38:47 -
@@ -62,18 +62,6 @@
stdlib.h \
dlfcn.h)
-dnl Don't use mach-o/dyld.h on Darwin 8+, dl* is recommended by Apple from
there on
-dnl See
http://developer.apple.com/documentation/DeveloperTools/Conceptual/MachOTopics/Articles/loading_code.html
-case $host_alias in
-*darwin[[89]]*)
-;;
-*)
-AC_CHECK_HEADERS([ \
-mach-o/dyld.h
-],[],[][])
-;;
-esac
-
AC_TYPE_SIZE_T
AC_TYPE_SIGNAL
Index: Zend/zend.h
===
RCS file: /repository/ZendEngine2/zend.h,v
retrieving revision 1.373
diff -u -r1.373 zend.h
--- Zend/zend.h 17 Jun 2009 08:57:44 - 1.373
+++ Zend/zend.h 18 Jun 2009 14:38:47 -
@@ -80,18 +80,7 @@
# include dlfcn.h
#endif
-#if HAVE_MACH_O_DYLD_H
-#include mach-o/dyld.h
-
-/* MH_BUNDLE loading functions for Mac OS X / Darwin */
-void *zend_mh_bundle_load (char* bundle_path);
-int zend_mh_bundle_unload (void *bundle_handle);
-void *zend_mh_bundle_symbol(void *bundle_handle, const char *symbol_name);
-const char *zend_mh_bundle_error(void);
-
-#endif /* HAVE_MACH_O_DYLD_H */
-
-#if defined(HAVE_LIBDL) !defined(HAVE_MACH_O_DYLD_H) !defined(ZEND_WIN32)
+#if defined(HAVE_LIBDL) !defined(ZEND_WIN32)
# ifndef RTLD_LAZY
# define RTLD_LAZY 1/* Solaris 1, FreeBSD's (2.1.7.1 and older) */
@@ -117,13 +106,6 @@
# define DL_ERROR dlerror
# define DL_HANDLE void *
# define ZEND_EXTENSIONS_SUPPORT 1
-#elif defined(HAVE_MACH_O_DYLD_H)
-# define DL_LOAD(libname) zend_mh_bundle_load(libname)
-# define DL_UNLOAD zend_mh_bundle_unload
-# define DL_FETCH_SYMBOL(h,s) zend_mh_bundle_symbol(h,s)
-# define DL_ERROR zend_mh_bundle_error
-# define DL_HANDLE void *
-# define ZEND_EXTENSIONS_SUPPORT 1
#elif defined(ZEND_WIN32)
# define DL_LOAD(libname) LoadLibrary(libname)
# define DL_FETCH_SYMBOL GetProcAddress
Index: Zend/zend_API.c
===
RCS file: /repository/ZendEngine2/zend_API.c,v
retrieving revision 1.503
diff -u -r1.503 zend_API.c
--- Zend/zend_API.c 4 Jun 2009 18:18:46 - 1.503
+++ Zend/zend_API.c 18 Jun 2009 14:38:47 -
@@ -2456,7 +2456,7 @@
zend_unregister_functions(module-functions, -1, NULL
TSRMLS_CC);
}
-#if HAVE_LIBDL || defined(HAVE_MACH_O_DYLD_H)
+#if HAVE_LIBDL
#if !(defined(NETWARE) defined(APACHE_1_BUILD))
if (module-handle) {
DL_UNLOAD(module-handle);
Index: Zend/zend_extensions.c
===
RCS file: /repository/ZendEngine2/zend_extensions.c,v
retrieving revision 1.60
diff -u -r1.60 zend_extensions.c
--- Zend/zend_extensions.c 8 Apr 2009 13:26:24 - 1.60
+++ Zend/zend_extensions.c 18 Jun 2009 14:38:47 -
@@ -219,70 +219,6 @@
}
/* }}} */
-/*
- * Support for dynamic loading of MH_BUNDLEs on Darwin / Mac OS X
- *
- */
-
-#if HAVE_MACH_O_DYLD_H
-
-void *zend_mh_bundle_load(char* bundle_path) /* {{{ */
-{
- NSObjectFileImage bundle_image;
- NSModule bundle_handle;
- NSSymbol bundle_init_nssymbol;
- void (*bundle_init)(void);
-
- if (NSCreateObjectFileImageFromFile(bundle_path, bundle_image) !=
NSObjectFileImageSuccess
Re: [PHP-DEV] Patch for bug #48575
On Jun 18, 2009, at 10:55 AM, Scott MacVicar wrote: Here is a nice simple patch for #48575 which rips out the mach-o/dyld.h functionality in Zend (as suggested by the original reporter and the Apple comment). According to my testing this not only doesn't break anything, but actually doesn't change anything either except removing some dead code and removing one configure check. Per Pierre's request, I'm sending it here for review :) Looks good for me, apply to HEAD and document somewhere that we need 10.2 as the minimum version. Correction: 10.3 as the minimum :). -- Gwynne -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] bug #48583 or display_errors saga
On Jun 18, 2009, at 1:09 PM, jvlad wrote: If the bug #48583 can't be accepted through bugs.php.net, I think it makes sense to discuss it here. It's not a bug but chicken'n'egg' issue. Errors are displayed by default (IIRC) so if the ini file does not get parsed an error is outputted which IS --Jani I don't agree, absolutely. Settings are more important and should be parsed/loaded first. If any error happens before this phase is complete, they should be captured and buffered for later processing, unless the error is fatal. After the settings are loaded, all buffered errors should be processed and handled according to the settings. Nothing else. Do you see any problems with this approach? Where is the promissed chickenegg issue? :) really good thing. Just fix that damn ini file. :) Sorry, but seems you do not understand the situation. How would an admin fix that damn ini file if the errors are not appearing in the log? Say, I'm a hosting company admin. I install packages, php in particular, make changes to configs, etc. I do not know what web sites are running and do not want to see if anything related to my work appear in their pages. Never. What steps am I supposed to do to see that php.ini contains bogus #? Take in to account that some of the errors do not appear in the output at all. They are crashing php because passed to the handler too early. I have to say I agree; exposing such errors can be a potential security risk. -- Gwynne -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Live SVN repository
http://svn.php.net/ This URL, accessible both by web browser and Subversion clients, now contains the current revision of the converted CVS repository. At the moment there is NO authorization or authentication scheme in place; the repository is limited to read-only access. I would like to see some discussion and commentary on converting the CVS karma to SVN authz, specifically on the necessary scripting and interface. One important thing to note is that SVN does NOT have an equivelant to CVS's CVSROOT; a checkout of the authz file would have to be maintained, ideally through an interface on master-web. I would also like to see some renewed discussion on structure so that I can make the required changes to the repository layout that you currently see at the above URL. This message is being CC'd to internals@ so everyone can keep up on what's going on. PLEASE, restrict your replies to [EMAIL PROTECTED] -- Gwynne, Daughter of the Code This whole world is an asylum for the incurable. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] CVS to SVN Migration
On Jul 25, 2008, at 6:34 AM, Hannes Magnusson wrote: At this point it's clear that moving from CVS to SVN for PHP has become a more or less official project. Has the phpdoc revision/translation problem been looked into/fixed? No, not yet, but it will have to be. I intend for discussion on svn- [EMAIL PROTECTED] For the record, I will more or less ignore discussion that happens on internals@ on the subject; the idea of making a new list was to keep noise about the situation out of the ears of people who don't care. Especially with the 5.3 release coming, the last thing we need is extra noise without any means of categorizing. -- Gwynne, Daughter of the Code This whole world is an asylum for the incurable. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Volunteers for Subversion 1.5 conversion of cvs.php.net?
On Jul 24, 2008, at 8:05 PM, Rasmus Lerdorf wrote: Now that Subversion 1.5 has been out for a little while and it is at the point where it might actually have some benefit to us, do we have some volunteers who have some time to try converting over the repository and all the post-commit and ACL rules from CVSROOT? Talking to people here at OSCON, the consensus seems to be that moving to Subversion at this point would worthwhile. The Git/Bzr/ Merc folks have better tools to deal with a central svn repository than cvs at this point, and the svn workflow and Windows tools won't leave all our less technical committers floundering. I think the most convenient approach would be to do the conversion directly on the cvs.php.net machine and run the two side-by-side with periodic imports to svn while we test things and then a freeze and a switchover at some point. See my Wiki on it at http://wiki.php.net/svnmigration, I'm planning to get back to it this weekend. -- Gwynne, Daughter of the Code This whole world is an asylum for the incurable. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Volunteers for Subversion 1.5 conversion of cvs.php.net?
On Jul 24, 2008, at 8:23 PM, Rasmus Lerdorf wrote: Now that Subversion 1.5 has been out for a little while and it is at the point where it might actually have some benefit to us, do we have some volunteers who have some time to try converting over the repository and all the post-commit and ACL rules from CVSROOT? Talking to people here at OSCON, the consensus seems to be that moving to Subversion at this point would worthwhile. The Git/Bzr/Merc folks have better tools to deal with a central svn repository than cvs at this point, and the svn workflow and Windows tools won't leave all our less technical committers floundering. I think the most convenient approach would be to do the conversion directly on the cvs.php.net machine and run the two side-by-side with periodic imports to svn while we test things and then a freeze and a switchover at some point. See my Wiki on it at http://wiki.php.net/svnmigration, I'm planning to get back to it this weekend. Yes, I read that. But the conversion of the repository itself is only half the battle. There are a bunch of scripts in CVSROOT that need to be ported over to SVN somehow. My plan was to work on those next. -- Gwynne, Daughter of the Code This whole world is an asylum for the incurable. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] CVS to SVN Migration
At this point it's clear that moving from CVS to SVN for PHP has become a more or less official project. As such, there is a new mailing list [EMAIL PROTECTED] for anyone who wants to help with the move. If you're familiar with what I've already done so far (http://wiki.php.net/svnmigration) and want to help, I beg you on my knees to subscribe (send a mail to [EMAIL PROTECTED] ) and let us know what you want to do :). It's past time for PHP to make this step a just a little bit further into the future and I hope we can work together to make it happen. -- Gwynne, Daughter of the Code This whole world is an asylum for the incurable. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Volunteers for Subversion 1.5 conversion of cvs.php.net?
On Jul 24, 2008, at 10:14 PM, Sean Coates wrote: Do we have a preference of Apache's SVN or svnserve? The former requires Apache 2+, AFAIK. I'd like to kick this discussion over to the svn-migration@ list; there are a lot of points to consider in this question and internals@ has enough threads as it is. -- Gwynne, Daughter of the Code This whole world is an asylum for the incurable. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] E_USER_DEPRECATED
On Jul 19, 2008, at 6:55 AM, Lars Strojny wrote: Hi everbody, regarding my mail from yesterday, I've also created an RFC for the new error level. http://wiki.php.net/rfc/e-user-deprecated-warning cu, Lars A large +1 from me too. -- Gwynne, Daughter of the Code This whole world is an asylum for the incurable. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 6 (and forget 5.4) (Was: Re: [PHP-DEV] [RFC] Closures: updated proposal and patch)
On Jul 3, 2008, at 4:41 AM, Lukas Kahwe Smith wrote: Absolutely agree. I don't see any reason for 5.4. We don't plan any significant new features. You guys are scaring me .. I was hoping to evade such discussions. PHP 5.3 is probably the minor version release with the most major changes ever. Mostly because we waited too long to go into release mode. PHP 6 has of course lingered even longer and it really really needs to get out the door ASAP. Now what I would propose is that we go into release mode on PHP 6 as well. Due to the nature of it being a major version bump it will naturally take longer to get completed. Depending on how quickly we move with PHP 5.3, we will then either release a PHP 5.4 with all of the open items before PHP 6 or more or less at the same time. But if we put the burden of being the last planned PHP 5 release onto 5.3, we will have huge issues getting it out the door. So please let us keep 5.4 on the table, but at the same time do everything we can to get PHP 6 onto some sort of release schedule. I have emailed Andrei about this offlist when I saw Derick's email. But I just wanted to send this email as a sort of damage control :) A loud +1 to this from me. Can we get an RFC into the Wiki on this? -- Gwynne, Daughter of the Code This whole world is an asylum for the incurable. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] [RFC] Closures and lambda functions in PHP
On Jun 26, 2008, at 4:06 AM, Lukas Kahwe Smith wrote: Now, upon execution of the code containing the closure, the new opcode just copies the zend_function structure into a copy, registers that copy as a resource and returns that resource. As soon as the resource is garbage collected (or explicitly unset), the op_array copy is destroyed. No modification of the actual class is done at all - the cache remains happy. So since a reference is stored, it means that the destructor of the enclosing object is only called once not only the variable holding the object, but also all lambda functions that were created inside of the class have been free'ed? I'm not up to date on the operation of the current patches to implement closures, but typically this is how it'd work, retaining references to what's needed as long as the closures exist. -- Gwynne, Daughter of the Code This whole world is an asylum for the incurable. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] [RFC] Closures and lambda functions in PHP
On Jun 18, 2008, at 2:36 AM, Alexey Zakhlestin wrote: 1) I am not sure that the current semantics of the lexical keyword is great in all cases. Is the reason why you don't allow by- value binding so that we don't have to manage more than one lambda instance per declaration? by-reference binding is much closer to other languages symantics. I guess, that was the main reason Christian chose it. by-value may still exist, if people find, that they need it, but only in addition, please. lambda has to reflect changing state of context, to be truly useful In Lua, the language in which I've seen the most of closures and lambda, lexical scoping is handled this way: someVariable1 = asdf; someVariable2 = jkl;; SomeFunction = function() local someVariable2 = 1234; print someVariable1.. ..someVariable2..\n; end print gettype(SomeFunction)..\n; SomeFunction(); someVariable1 = qwer; someVariable2 0987; SomeFunction(); The resulting output of this code fragment would be: function asdf 1234 qwer 1234 The Lua interpreter handles this by resolving variable references as they're made; someVariable1 is looked up in the closure's scope and not found, so the interpreter steps out one scope and looks for it there, repeat as necessary. Once found outside the closure's scope, something similar to the proposed lexical keyword happens. Closures and lexical variables can be nested this way, to the point where a single variable in a sixth-level closure could still have been originally found in the global scope. I'm not sure this would work for PHP, I'm curious what others think. Of course, that fragment does a very poor job of showing off the extreme flexibility of Lua with regards to functions and scoping, but hopefully it illustrates the concept. -- Gwynne, Daughter of the Code This whole world is an asylum for the incurable. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] [RFC] Closures and lambda functions in PHP
On Jun 18, 2008, at 11:01 AM, Stanislav Malyshev wrote: The Lua interpreter handles this by resolving variable references as they're made; someVariable1 is looked up in the closure's scope and not found, so the interpreter steps out one scope and looks for it You may get into a problem here - creator's scope may not exist when you execute the closure, and using caller's scope would be very unexpected - usually closures are intended to capture part of creating environment, not calling environment. It would also impose serious penalty if you just use undefined variable - you'd have to go through whole stack up to the top. This lookup happens at the time the closure is first declared, and the value is stored for later use by the closure; the calling scope doesn't need to exist anymore. The problem with going to the top of the stack is an issue, though; the Lua interpreter's idea of scope is rather different from PHPs, and it's not nearly the same penalty there. -- Gwynne, Daughter of the Code This whole world is an asylum for the incurable. -- 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/session mod_user.c mod_user.h php_session.h session.c
On Apr 24, 2008, at 3:19 AM, Antony Dovgal wrote: On 08.03.2008 02:20, Gwynne Raskind wrote: gwynne Fri Mar 7 23:20:32 2008 UTC Modified files: (Branch: PHP_5_3) /php-src/ext/session mod_user.c mod_user.h php_session.h session.c Log: MFH: fix bug #32330 (session_destroy, Failed to initialize storage module, custom session handler) Gwynne, what about 5_2? It still leaks memory: # cat /local/qa/5_2/ext/session/tests/ session_set_save_handler_error4.diff 012+ [Thu Apr 24 02:05:35 2008] Script: '/local/qa/5_2/ext/session/ tests/session_set_save_handler_error4.php' 013+ /local/qa/5_2/Zend/zend_vm_execute.h(1805) : Freeing 0x0108F0F0 (24 bytes), script=/local/qa/5_2/ext/session/tests/ session_set_save_handler_error4.php 014+ Last leak repeated 5 times 015+ [Thu Apr 24 02:05:35 2008] Script: '/local/qa/5_2/ext/session/ tests/session_set_save_handler_error4.php' 016+ /local/qa/5_2/Zend/zend_variables.h(45) : Freeing 0x01091DA8 (9 bytes), script=/local/qa/5_2/ext/session/tests/ session_set_save_handler_error4.php 017+ /local/qa/5_2/Zend/zend_variables.c(120) : Actual location (location was relayed) 018+ Last leak repeated 5 times 019+ [Thu Apr 24 02:05:35 2008] Script: '/local/qa/5_2/ext/session/ tests/session_set_save_handler_error4.php' 020+ /local/qa/5_2/ext/session/session.c(1512) : Freeing 0x01093A48 (48 bytes), script=/local/qa/5_2/ext/session/tests/ session_set_save_handler_error4.php 021+ === Total 13 memory leaks detected === I was told not to commit this fix to 5.2 as it represented a significant change to the session module. I can't say why 5.2 is leaking memory since I never touched it. -- Gwynne, Daughter of the Code This whole world is an asylum for the incurable. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.2.6RC5 Released
On Apr 11, 2008, at 8:29 AM, Ilia Alshanetsky wrote: Edin, our previous Win32 build master appears to be indisposed at the moment hence lack of win32 binaries. If someone else wants to produce them great, if not, we'll go on without them. I'd be willing to take a bash at it. What's required? I have access to a Windows XP SP2 machine. On 11-Apr-08, at 8:17 AM, Pierre Joye wrote: On Fri, Apr 11, 2008 at 2:14 PM, John Mertic [EMAIL PROTECTED] wrote: What about Windows binaries? I'm not sure if we have had them for any RC thus far... Very good point. As I do test 5.2.x on windows while developing, we really need official RC before we can go stable. As far as I remember, Elisabeth was working on our build box. What's the current status (no hurry, only wondering)? I can try to build a set using my windows boxes and updates some libraries while being at it (thinking of libpng first, or openssl). Cheers, -- Pierre http://blog.thepimp.net | http://www.libgd.org Ilia Alshanetsky -- Gwynne, Daughter of the Code This whole world is an asylum for the incurable. -- 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) / configure.in
On Apr 1, 2008, at 4:45 PM, Johannes Schlüter wrote: -O2 is prepended to CFLAGS; with GCC the *last* -O option specified takes precedence. Anything specified by the user will thus override the default -O2. I admit this isn't the cleanest possible solution, but it works, and I don't understand autoconf well enough to handle it better. If you do --enable-debug you usually get -O0 instead of -O2 so the compiler does no optimizations which make problems with debugging The fix only prepends -O2 in the non-debug case; in the debug case -O0 is prepended explicitly already. -- Gwynne, Daughter of the Code This whole world is an asylum for the incurable. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.3 the slowest PHP of all times ?!?
On Mar 31, 2008, at 5:41 PM, Benjamin Schulz wrote: This commit is responsible for the bad performance: http://cvs.php.net/viewvc.cgi/php-src/configure.in?r1=1.579.2.52.2.77.2.11r2=1.579.2.52.2.77.2.12diff_format=u -gstabs versus -g should have no effect on production performance. Ok, maybe i made a mistake, that's what i compared: Upon investigation I've discovered the problem to be this: When the Darwin hack takes effect, the overwrite of CFLAGS removes the default - O2, thus the slowdown. I'll commit a fix shortly, with apologies for the oversight. -- Gwynne, Daughter of the Code This whole world is an asylum for the incurable. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Double quoted NOWDOC is HEREDOC
On Mar 24, 2008, at 8:59 AM, Marcus Boerger wrote: Hello Lars, to me this makes pretty much sense on a second glance as it perfectly reflects what our string would do. And for someone learning 'NOWDOC', using HEREDOC seems just natural. So I am all +1 Consistency and satisfying expectations rocks! marcus As the original proposer of nowdocs, I also give it a +1 for consistency! -- Gwynne, Daughter of the Code This whole world is an asylum for the incurable. Saturday, March 22, 2008, 9:17:27 PM, you wrote: Hi, as we introduce NOWDOC in 5.3 it would be logical to allow a double quoted syntax sister of NOWDOC which acts as HEREDOC (same as for $var = $var vs $var = '$var'). Currently we have the following options: $var = Hello world; $str = LABEL $var LABEL; $str = 'LABEL' $var LABEL; The first one is HEREDOC and $var would be evaluated. The second one is NOWDOC and $var would be used literally. The following patch adds a third version: $str = LABEL $var LABEL; This acts as HEREDOC, therefore $var would be interpreted. Comments? cu, Lars Best regards, Marcus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Could PHP be used to build PHP?
I'd be in favor of this idea because it sounds cool, but it has some crippling drawbacks: - There isn't really a homogenous way to build PHP without OS- specific checks. There's just too much that even the most minimal build needs to know about its host system. - configure.php wouldn't be any easier to maintain than configure.in. Reinventing the wheel is a truly massive undertaking when it comes to supporting the sheer number of operating system variations that autoconf and CMake have spent years working out. - There really isn't any advantage to it. By the time you've implemented even the most minimal bootstrap, you've already forced yourself to use something like autoconf or CMake anyway. Look at GCC's build system; it's a three-stage bootstrap with extensive error- checking and endless, endless configuration options. That's what we'd end up with, and it's just not worth it. -- Gwynne, Daughter of the Code This whole world is an asylum for the incurable. On Mar 20, 2008, at 6:28 AM, Richard Quadling wrote: With regard to the CMake SoC proposal ... I may be a little naive here but surely it would be better to use PHP to build PHP? I know that outside of PHP, a LOT of tools which I have no knowledge of (I'm a windows user. I use point and click interfaces to build apps when I used Delphi - no need for command line, but it was present). I know that most *nix devs use cli to do the build. But, if the whole build process was PHP orientated, it would be a case of keeping it in-house. No need to learn m4/cscript/etc. when we are using PHP to build PHP. The problem with this (as I see it) is the first build on those systems where a binary isn't available (look - I'm on windows. I download and go). So, a PHP Bootstrap would seem like a sensible tool to have. Something would produce take a truly basic PHP interpreter. No extensions (db, graphics, etc). As I see it it would need file I/O, cli param handling. I think it would be nice to be able to get user input via the console, so you could have something a little more visual (not like the PEAR cli interface, but in that nature - question/answer). Add in the ability to remember the last build config, so no need to re-do all the q/a and off you go (ha ha. If only it was that simple - but shouldn't it be?) Ok. I know I've missed loads of what the build process does. I suspect that PHP code necessary to build PHP would be quite extensive and I suspect the first argument against this is wheel re-invention. I would counter that with this is re-invention, but refactoring. The improvement comes from not relying on anything other than the local C compiler and userland PHP knowledge. Even I could build PHP now without understanding a ton of different tools. I'm no expert here. So I know this isn't a full proposal or anything, but of those that know this better than I... 1 - Could this be done? 2 - Would it be worth it (100% standalone pre-compiler process with no third party tools). 3 - Would you use it if it was available - would something like this be too different to other build systems you use? Richard. -- - Richard Quadling Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498r=213474731 Standing on the shoulders of some very clever giants! -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] CMake SoC Proposal
My two US cents :). On Mar 19, 2008, at 9:17 PM, Jani Taskinen wrote: Here is a quick run down of some of the features of CMake and tools associated with it: • A single configure script that would be used regardless of the OS • A much simpler scripting language m4 is simple. :-p Since when? • Generates native build files (make, XCode, Visual Studio 6, 7.1, 8) err..a simple Makefile isn't native enough? Like we have right now? :) Care to explain what you meant with this? Make is outmoded, outdated, and not up to the task of modern builds. You can't use a Makefile (effectively) with Xcode. • Use a build directory so that all build related files are outside the main source tree, no more pollution of your checkout. You can do that already even with autoconf generated configure: Just call the configure script from wherever you want to build the stuff. (I build PHP always outside the source tree to not pollute my checkout. :) As do I, but I still have to pollute my checkout with buildconf or csript buildconf.js. Bill Hoffman of Kitware who produce CMake and the related tools have offered their assistance in our transition, including adding ports to any unsupported operating systems or features that would prevent us from currently doing the move. phpize is the one and only thing that comes to my mind as an obstacle..but it's propably possible to simulate using this CMake thingie? Everyone has CMake installed, right? :D If automake and autoconf can do it, then as a rule CMake can do it better. -- Gwynne, Daughter of the Code This whole world is an asylum for the incurable. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Deprecating php_dirname() in 5_3, removing in HEAD
On Mar 5, 2008, at 9:52 PM, David Coallier wrote: I'm talking about extension developers. We will all have to add yet another #ifdef for this function, in the implementation or to define php_dirname to keep the implementation clean(er). As it is good to clean up codes, I'm not sure to remove this function is a good thing. That's why I suggest removing it in 6, and deprecating it from now on. As 6 will break everything anyway. I go it but there is no easy to deprecate an internal function. Except to spare two #define php_(u)_dirname in HEAD, I still see no gain :) Perhaps it's time to make a compatibility extension with all those ifdefs everywhere and engine hooks. I'll +1 that. I'll even volunteer to maintain it, if someone who knows the engine better can give me a framework to start from. -- Gwynne, Daughter of the Code This whole world is an asylum for the incurable. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] [PATCH] Fix for bug #32330
I've created a patch, including a new test, for bug #32330 (session_destroy, Failed to initialize storage module, custom session handler). There are three versions of the patch (for PHP_5_2, PHP_5_3, and HEAD): http://www.wanderingknights.org/maryoku/bug32330-PHP_5_2.diff http://www.wanderingknights.org/maryoku/bug32330-PHP_5_3.diff http://www.wanderingknights.org/maryoku/bug32330-HEAD.diff Hope it's useful! -- Gwynne, Daughter of the Code This whole world is an asylum for the incurable. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] why we must get rid of unicode.semantics switch ASAP
On Jan 22, 2008, at 5:29 AM, Pierre wrote: On Jan 21, 2008 3:38 PM, Antony Dovgal [EMAIL PROTECTED] wrote: 6 reasons why we must to get rid of The Switch ASAP I was +1 months ago, I'm still +1 now :) I'll throw in my +1 too. That's right, I'm still alive! :) -- Gwynne, Daughter of the Code This whole world is an asylum for the incurable. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] [PATCH] PDO_sqlite data types
The attached patch adds basic support for storing properly-typed
integer and boolean data in SQLite3 databases. I don't really
understand why this kind of support has been so consistently lacking
in PHP database driver implementations. Similar problems have plagued
the MySQL and MySQLi extensions for a long time, and PDO seems to
struggle for the support at times. This diff is against PHP 5.2.3,
but I've verified that it works in 5.2.4RC3, 5.2.4 CVS, and HEAD.
This by itself disturbs me because it indicates that in all this time
this code hasn't been touched at all. Was it really that hard to add
this very simple code?
-- Gwynne, Daughter of the Code
This whole world is an asylum for the incurable.
Index: ext/pdo_sqlite/sqlite_statement.c
===
RCS file: /repository/php-src/ext/pdo_sqlite/sqlite_statement.c,v
retrieving revision 1.18.2.4.2.2
diff -u -r1.18.2.4.2.2 sqlite_statement.c
--- ext/pdo_sqlite/sqlite_statement.c 1 Jan 2007 09:36:05 -
1.18.2.4.2.2
+++ ext/pdo_sqlite/sqlite_statement.c 27 Aug 2007 10:08:42 -
@@ -96,7 +96,22 @@
switch (PDO_PARAM_TYPE(param-param_type)) {
case PDO_PARAM_STMT:
return 0;
-
+
+ case PDO_PARAM_INT:
+ case PDO_PARAM_BOOL:
+ if (Z_TYPE_P(param-parameter)
== IS_NULL) {
+ if (sqlite3_bind_null(S-stmt, param-paramno + 1) ==
SQLITE_OK) {
+ return 1;
+ }
+ } else {
+
convert_to_long(param-parameter);
+ if (SQLITE_OK == sqlite3_bind_int(S-stmt, param-paramno +
1, Z_LVAL_P(param-parameter))) {
+ return 1;
+ }
+ }
+ pdo_sqlite_error_stmt(stmt);
+ return 0;
+
case PDO_PARAM_NULL:
if (sqlite3_bind_null(S-stmt,
param-paramno + 1) == SQLITE_OK) {
return 1;
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Nowdocs revised
On Aug 15, 2007, at 2:00 PM, Christopher Jones wrote:
Did you get any further with merging this? It would help users of
the XQuery language.
If I understand your intent, I would be able to change the code
fragment
below to use a nowdoc, and not have to escape the XQuery $i variables.
Chris
?php
$c = oci_connect(hr, hrpwd, localhost/orcl);
$xq = END
select column_value
from xmltable('for \$i in ora:view(locations) return \$i')
END;
$s = oci_parse($c, $xq);
oci_execute($s);
while ($row = oci_fetch_row($s))
var_dump($row);
?
I didn't get any further, no :(. The decision of whether to merge the
nowdocs patch is out of my hands now, since I don't have source
karma. However, since the main thing standing in the way of its
implementation was concern over the usefulness, your comment is very
helpful, and I'd like to open the topic for discussion again on the
list, if no one out there has any objection :)
-- Gwynne, Daughter of the Code
This whole world is an asylum for the incurable.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
