Re: [PHP-DEV] Quoting again
> should i draw you a picture for help? Yes, but please make sure that it is on 24# cream paper. And draw in charcoal, because professionals don't use pencils. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Remove variable function and method calls
On 2010-07-22, at 8:49 PM, Karoly Negyesi wrote: > So you do not consider it utterly confusing that No. I know kung-fu. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] dangerous handling of security bugs
On 2010-07-10, at 7:00 PM, Reindl Harald wrote: > I understand this well > Then perhaps you can volunteer to help speed up the release process. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Named Parameters
On 2010-04-02, at 9:02 PM, Stanislav Malyshev wrote: > I think they'd allow to manage complex parameter sets more efficiently than > with those $options arrays. But that'd probably require changing the way how > parameters are passed, since the stack won't work too good anymore for it. FWIW, named parameters would be a great aid in building uncoupled systems—particularly when some of the tiers are not based on PHP. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Next major version must be 7 (Lessons learned from the ECMAScript committee)
Hey Sebastian— On 2010-03-13, at 4:55 PM, Sebastian Bergmann wrote: > Stefan Marr wrote: >> Is that wise and well-considered or something the community might >> regret in the long run? > > The books in question have not been written by community members > (because those know better). I think there are so many PHP 6 books on > the market because greedy publishers want to release old content under > a new title and use a version bump (that has not happened yet) to cover > up this fact. Well said! In all fairness, though, this doesn't change the fact that the books exist—and that their keyword trolling is eventually going to hurt those who look for information on PHP 6, if that's what the final product is going to be called. But, really, who cares about a name while there isn't even a spec? The name should be the last thing that needs to be considered—literally, so that the trolls don't have an opportunity to flood the market with opportunistic titles until the new version is well defined and ready to go. Calling it “trunk” at this point ought to be more than enough, IMO. —Mt.
Re: [PHP-DEV] bug when using foreach with references?
On 2009-10-21, at 10:40 PM, Richard K Miller wrote:
I don't follow. Is this really the intended behavior? It seems quite
unintuitive that the original array would be modified by *empty*
loops.
It is intended behaviour. Consider your code; at the end of this loop:
$items = array('apple', 'banana', 'carrot');
print_r($items);
foreach ($items as &$item) { }
$item will contain a reference to the last item of $items. Therefore,
when you start the next loop:
foreach ($items as $item) { }
$item will receive each of the values stored in $items, in sequence.
But $item is a reference to the last item in $items, so whatever you
write into it will also be written into the last item of the array.
Thus, the loop will cause these values to be written there:
- On the first iteration, "apple"
- On the second iteration, "banana"
- On the third iteration, "banana" (because you are taking the third
item in the array, which you just overwrote)
When would this behavior be desired?
Probably never, but that does not make it counterintuitive—the
interpreter is behaving correctly based on the data it is handling and
the instructions you are giving to it. The correct solution, as
someone has already recommended, is to unset the iterator if you want
to reuse it.
Cheers,
Marco.
Re: [PHP-DEV] shebang skipping in 5.3.0
It would be really nice if everyone could consider that the other do understand what is being discussed but actually disagree. The question was actually: is it worth the effort? Who is seriously using CGI (not meaning fastcgi) with php these days? On shared hosts, CGI is often the only way to have your own custom version of PHP. I don't know if that's relevant to this conversation, though :-) Mt. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP scalability problem
On 26-May-09, at 11:10 PM, tRace DOliveira wrote: What I am trying to achieve is to have the server do less processing. Like I said PHP is a server side scripting language and each time a request is made a process is spawned and processes are heavy weight as compared to a thread which is a light weight process. So I want to take away much processing away from the server and have the client do it instead. Because if many requests are made the server will eventually go down because it will over the server.I am not trying to get away from PHP but I am trying to solve the problem of scalability Unfortunately, the only thing you have achieved is writing on the wrong mailing list :-) Try php-general, where this kind of query is addressed by a larger group of people. Cheers! -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] display_errors = on
On 6-Jan-09, at 11:49 AM, Ilia Alshanetsky wrote: I'm ok with doing for 5.3, most people when upgrade rarely look at the INI file especially if the update is done through a distribution's package management system. Not to barge in, but many people won't consider 5.2 -> 5.3 a "major" upgrade. That's what major version numbers are for. Mt. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] An Idea for PDO 2
Hey Marcus— On 1-Feb-08, at 3:26 PM, Marcus Boerger wrote: * Develop a PECL CLA that can optionally be used for PECL projects. * If necessary, adapt the PHP License, so that it works nicely together with the CLA. IMO (and FWIW), CLAs do not belong in any official php.net project. I have already explained the reason why in the past, so I won't repeat myself, but a CLA violates the basic principle under which everything "officially" PHP is developed, and it should not be allowed to enter the project in any way. Perhaps PDO2 can simply be an external project, maybe hosted at Sourceforge or some other such site? Marco -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] no read-only, no moderation, just a simple self-enforced checklist
On 10-Jan-08, at 10:58 AM, Lukas Kahwe Smith wrote: I know that PHP has so far stayed clear of processes and I am fine with keeping it this way. But I really think that some of these flames should best be taken off list into some work group that provides summaries at semi regular intervals, so that internals knows whats going on and people know if it makes sense for them to join this discussion. Right now people keep posting in threads only because they are afraid that silence means approval or because they missed part of the discussion or because they have time to kill. Not to barge in, but I think the word you're thinking of is "governance," which unfortunately so many people confuse with bureaucracy. A good process streamlines without impeding, and personally I think internals could really use some help in that area. Mt. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Internals read-only (was: Re: [PHP-DEV] namespace improvements to be committed very soon - final review)
On 13-Dec-07, at 8:08 AM, Jani Taskinen wrote: On Thu, 2007-12-13 at 10:00 +0100, Derick Rethans wrote: To to get back to the point of the noise on the lists - it's getting out of hand, and I am afraid that if we don't solve this any time soon, the lists will be useless for any sort of decent discussion and promoting even more secret cults. There's already public list, it's called "php-general". So just unsubscribe all people from this list and subscribe all @php.net addies only. I am just a lurker, so take this with the due grain of salt, but simply making internals@ read-only is just going to drive people to contact the core team members directly (thus likely *increasing* your blood pressure :-)). I think you need to provide people with some way of interacting without unleashing chaos on the development process; php-general, IMHO, is not the place for that kind of discussion, because people there are mostly looking for assistance with the use of PHP, rather than attempting to influence the development process. Mt. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] require_once
On 24-Apr-07, at 7:00 AM, Antony Dovgal wrote: Yes, of course. But I'm using Linux, not windows. Maybe you're even using a machine that is more powerful than his... Mt. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Patch for bug #34565
[Resending with patch inline]
Hi--
Could someone with karma check that this patch is ok for bug #34565 and
commit it to CVS? The patch is against HEAD -- not sure if a separate commit
needs to be made against the 4.x and 5.x branches (and would appreciate some
pointers on this topic).
Cheers!
Marco
Index: ext/mbstring/mbstring.c
===
RCS file: /repository/php-src/ext/mbstring/mbstring.c,v
retrieving revision 1.224
diff -u -b -w -B -r1.224 mbstring.c
--- ext/mbstring/mbstring.c3 Aug 2005 14:07:24 -1.224
+++ ext/mbstring/mbstring.c20 Sep 2005 21:51:25 -
@@ -3007,6 +3007,7 @@
int subject_len;
char *extra_cmd=NULL;
int extra_cmd_len;
+char *force_extra_parameters =
INI_STR("mail.force_extra_parameters");
struct {
int cnt_type:1;
int cnt_trans_enc:1;
@@ -3208,6 +3209,12 @@
mbfl_memory_device_output('\0', &device);
headers = (char *)device.buffer;
+if (force_extra_parameters) {
+extra_cmd = estrdup(force_extra_parameters);
+} else if (extra_cmd) {
+extra_cmd = php_escape_shell_cmd(extra_cmd);
+}
+
if (!err && php_mail(to, subject, message, headers, extra_cmd
TSRMLS_CC)) {
RETVAL_TRUE;
} else {
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Patch for bug #34565
[Resending with patch in text file. I'm planning on getting this right one of these days] Hi-- Could someone with karma check that this patch is ok for bug #34565 and commit it to CVS? The patch is against HEAD -- not sure if a separate commit needs to be made against the 4.x and 5.x branches (and would appreciate some pointers on this topic). Cheers! Marco -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Patch for bug #34565
Hi-- Could someone with karma check that this patch is ok for bug #34565 and commit it to CVS? The patch is against HEAD -- not sure if a separate commit needs to be made against the 4.x and 5.x branches (and would appreciate some pointers on this topic). Cheers! Marco -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 6.0 Wishlist
On 8/13/05 2:25 AM, "Ilia Alshanetsky" <[EMAIL PROTECTED]> wrote: > Why would I need name spaces for basic functions, just so that I need to > rename all my code to use str:replace rather then str_replace and > perform 2 hash table lookups? > Or maybe so that you don't have to look at the manual fifteen times a minute so that you can remember whether the needle goes before the haystack in a particular function or not. I'm not saying it's the perfect solution, but it's a good opportunity to clean things up a bit. Or it can be done in the global namespace and forget about namespaces altogether--I don't care much for them either, but I do think that consistent function naming and parameter ordering is an opportunity worth taking advantage of, that's all. Marco > Ilia > > Marco Tabini wrote: >> Hey Ilia, >> >> On 8/12/05 3:03 PM, "Ilia Alshanetsky" <[EMAIL PROTECTED]> wrote: >> >>> -1 to namespaces. As for modifying functions that would require a fair >>> number of function aliases for BC as untold number of scripts will >>> break. That is something we are trying to eliminate in the first place. >>> >> >> >> >> With namespaces, wouldn't the problem go away altogether? Old function names >> can be deprecated and E_STRICT'ed and a new, uniform naming convention and >> parameter order be enforced for the future. I hate namespaces but this >> sounds like a good solution to me. >> >> >> Mt. >> >> >> >> -- Marco Tabini President & CEO Marco Tabini & Associates, Inc. 28 Bombay Ave. Toronto, ON M3H 1B7 Canada Phone: +1 (416) 630-6202 Fax: +1 (416) 630-5057 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 6.0 Wishlist
Hey Ilia, On 8/12/05 3:03 PM, "Ilia Alshanetsky" <[EMAIL PROTECTED]> wrote: > > -1 to namespaces. As for modifying functions that would require a fair > number of function aliases for BC as untold number of scripts will > break. That is something we are trying to eliminate in the first place. > With namespaces, wouldn't the problem go away altogether? Old function names can be deprecated and E_STRICT'ed and a new, uniform naming convention and parameter order be enforced for the future. I hate namespaces but this sounds like a good solution to me. Mt. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 6.0 Wishlist
On 8/12/05 2:50 PM, "David Zülke" <[EMAIL PROTECTED]> wrote: > I have a #9 to share, too: > Assuming that PHP 6.0 will also have namespaces support (which would be > cool), it might make sense to move all internal functions to use namespaces > (if they support functions sitting in there - doesn't seem like Jessie's > current patch will, but then, maybe there's a chance). That way, we could > clean up naming inconsistencies (think of all the str* functions), and maybe > even some of the common annoyances when it comes to parameter order > (haystack, needle vs. needle, haystack) > I thought about suggesting this (or something like it)... But unlike anything that Rasmus has suggested, doing this will be dramatically destabilizing to *every* single PHP script, unless the platform also maintains a massive alias list--which is of course what Rasmus was trying to get rid of anyway :) Mt. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Assigning to $this
Zeev Suraski wrote: Wez, You're going to see Zeev on the PHP Cruise and me in Manchester at PawsCon :) Yeah, but what about both of you *together*? :-) -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] CVS Account Request: marcot
Working on the POP3 extension -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5 RC1
Sorry to interject, but shouldn't the feature set be frozen before moving to a release candidate? This stage should mean to people that they can start building software on the new system because all the features are fixed and are not going to change, even though the system may still have bugs and is not yet production ready (in fact, that's what beta should mean, but there was no alpha, so...). Cheers, Marco Andi Gutmans wrote: Hey guys, I think the PHP 5 tree has matured a lot and it's time to release an RC. I think end of November or mid-December makes sense. I'd like to aim at the former date. Are there any major (as in "major") issues which in your opinion still need to be dealt with? Thanks, Andi -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Proposal: Array syntax
George Schlossnagle wrote: On Nov 5, 2003, at 1:29 PM, Marco Tabini wrote: $a = [1,2,$b[11]] is semantically inconsistent. How so? Is I think I've already explained why. foo(array(1,2)); semantically inconsistent? On one hand () is used with a language construct (array()), whereas in the other context it indicates arguments to a function. I think that is what he meant by 'grouping' and 'application'. Actually, I think it meant something else. In any case, semantically you can still think of array() as a function (until you throw in key declarations, of course ;) ) Similar tokens have different syntactical meaning all over the language. Compare '<<' and '<<<'. To me that is no diffent that [] and []. Again, that's not a good reason to introduce more. Mt. George (still -1, but because it makes for unmaintainable code, not because it's hard to read) -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Proposal: Array syntax
Michael Walter wrote: $a = [1,2,$b[11]]; Is that confusing enough for you? ;-) What's confusing about it? The fact that $b[11] references an item of an array, while [1,2,$b[11]] assigns values to the array $a. The fact that you (and, probably, most of us) can't tell right off the bat is a clear sign that this is a bad idea, because it's ambiguous and confusing. The same line using the current syntax, btw, would have looked like this: $a = array (1,3,$b[11]); Actually, $a = [1,2,$b[11]] would be amazingly clear and expressive in comparison with the rather verbose array() version (same thing with the swap, btw). I guess we'll have to agree to disagree :) $a = [1,2,$b[11]] is semantically inconsistent. As you can see the ambiguity is gone--square brackets are used for one purpose and nothing else. Actually, do you realize that you use () both for "grouping" and for application? I can't see anything wrong with using square brackets for array element access and array creation, to be honest. Actually, no, I don't. I'm not sure what "grouping" and "application" mean... Mt. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Proposal: Array syntax
Romans Malinovskis wrote: Think backwards.. Will you be able to convince any perl/python/javascript developer to use array(), list(), range() structs? I really don't think this needs to be a concern. You can't be everything to all people. Mt. r $a = [1,2,$b[11]]; Is that confusing enough for you? ;-) Mt. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Proposal: Array syntax
Ford, Mike [LSS] wrote: On 05 November 2003 17:06, Marco Tabini contributed these pearls of wisdom: Christian Schneider wrote: Marco Tabini wrote: $a = [[1,2,3],[1=>[1,3,2,2], "a"=>[[1,2,3,4],4,[1,2]]]; $a = array(array(1,2,3),array(1=>array(1,3,2,2), "a"=>array(array(1,2,3,4),4,array(1,2))); Besides my previous points, something even more abominable: $a = [1,2,$b[11]]; Is that confusing enough for you? ;-) What's confusing about it? The fact that $b[11] references an item of an array, while [1,2,$b[11]] assigns values to the array $a. The fact that you (and, probably, most of us) can't tell right off the bat is a clear sign that this is a bad idea, because it's ambiguous and confusing. The same line using the current syntax, btw, would have looked like this: $a = array (1,3,$b[11]); As you can see the ambiguity is gone--square brackets are used for one purpose and nothing else. Cheers, Marco -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Proposal: Array syntax
Christian Schneider wrote: Marco Tabini wrote: $a = [[1,2,3],[1=>[1,3,2,2], "a"=>[[1,2,3,4],4,[1,2]]]; $a = array(array(1,2,3),array(1=>array(1,3,2,2), "a"=>array(array(1,2,3,4),4,array(1,2))); Besides my previous points, something even more abominable: $a = [1,2,$b[11]]; Is that confusing enough for you? ;-) Mt. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Proposal: Array syntax
George Schlossnagle wrote:
On Nov 5, 2003, at 11:52 AM, Marco Tabini wrote:
But isn't there a big difference between an assignment and a reference?
I, for one, think that language constructs should be as univocal as
possible in order to minimize confusion, lest we end up having to read
something like:
$a = [[1,2,3],[1=>[1,3,2,2], "a"=>[[1,2,3,4],4,[1,2]]];
I don't know about you, but I can't even begin to count the brackets
in there... :-)
is that any less clear than
$a = array(array(1,2,3), array(1 => array(1,3,2,2), array("a" =>
array(array(1,2,3,4), 4, array(1,2)));
Both examples can be made crystal clear with appropriate whitespace.
Except that the word array provides a nice break *and* it does not
create confusion in the use of a language construct (see my previous msgs).
Cheers,
Marco
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Proposal: Array syntax
Rasmus Lerdorf wrote: On Wed, 5 Nov 2003, Ilia Alshanetsky wrote: On November 5, 2003 10:34 am, Christian Schneider wrote: PHP is a mix of C, Perl and other styles anyway, why deny it? It's strength is that it's a pragmatic and simple language but that doesn't mean that nothing should be changed ever. PHP strength (IMHO) is it's simple and clear syntax, which allows people who come from background in other programming languages can quickly recognize and get used to. Creating confusing alternate syntaxes will bring us ever closer to Perl 6 where there are dozens of way to do the same thing. The end results in a confusing and hard to read/write language that all but the most dedicated of users refuse to use. Well, like I said before, I am not sure this is a clear case of that. I'm probably the biggest defender around of the no-magic rule, but [] does imply something array-related to most people, so I think the magic part is much smaller than in other proposals we have seen. But isn't there a big difference between an assignment and a reference? I, for one, think that language constructs should be as univocal as possible in order to minimize confusion, lest we end up having to read something like: $a = [[1,2,3],[1=>[1,3,2,2], "a"=>[[1,2,3,4],4,[1,2]]]; I don't know about you, but I can't even begin to count the brackets in there... :-) Cheers, Marco -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Proposal: Array syntax
Hi Andi, Christian--
From a logical standpoint, I think this could be very confusing. To me,
for one, square brackets imply reference, not assignment. Taking
something that means "take something out of the array" and now using it
to mean "put something in the array" makes the language a bit less
self-consistent... and, as Rasmus mentioned, less readable. Conciveness
is not everything--one also has to be able to understand his own code
after he's written it :-)
Cheers,
Marco
Andi Gutmans wrote:
Hi Christian,
Personally I don't like having two ways of doing things. It makes it
harder for people to read scripts.
However, I think the proposed syntax is significantly more elegant than
today's array() which makes me think twice about the idea and possibly
making an exception to the rule. I think it'll improve the look of PHP
scripts. Also I think people calling methods using
call_user_method([$obj, "method"]); will find it sexier than the array()
syntax.
I guess I think it'd be interesting to see what other's think. Also,
another point to check is if list() can also be converted into []
because having a hybrid wouldn't be too nice.
Andi
At 12:33 AM 11/5/2003 +0100, Christian Schneider wrote:
I propose to add an alternative (backward compatible) short array
creation syntax:
$a = [ 1, 2, 3 ]; and $a = [ 'a' => 42, 'b' => "foo" ];
It can also be used in function calls:
img(['src' => "logo.gif", 'alt' => "Logo"]);
Reason behind this change: Arrays are used a lot and should therefore
have as little syntactic overhead as possible. And I think the short
syntax is also easier to read and write.
A patch for the parser is trivial and is attached for Zend2.
Note: I checked the newsgroup archive but couldn't find a discussion
about this. After not hearing back about my proposed enhancement to
debug_backtrace() and the dangling comma for function call parameters
being rejected I wonder if I'm using the right mailing list for this :-)
- Chris
Index: Zend/zend_language_parser.y
===
RCS file: /repository/ZendEngine2/zend_language_parser.y,v
retrieving revision 1.127
diff -u -r1.127 zend_language_parser.y
--- Zend/zend_language_parser.y 19 Oct 2003 08:38:48 - 1.127
+++ Zend/zend_language_parser.y 4 Nov 2003 23:32:12 -
@@ -581,6 +581,7 @@
| '@' { zend_do_begin_silence(&$1 TSRMLS_CC); } expr {
zend_do_end_silence(&$1 TSRMLS_CC); $$ = $3; }
| scalar { $$ = $1; }
| T_ARRAY '(' array_pair_list ')' { $$ = $3; }
+ | '[' array_pair_list ']' { $$ = $2; }
| '`' encaps_list '`' {
zend_do_shell_exec(&$$, &$2 TSRMLS_CC); }
| T_PRINT expr { zend_do_print(&$$, &$2 TSRMLS_CC); }
;
--
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: var_dump_html()
On Thu, 2003-07-03 at 15:31, Björn Schotte wrote: > If so, then I would suggest the following add-ons: Whatever. :-) The patch is out there. I wrote because I found it useful. If others find it useful as well, so much better. I see no value in this discussion, and no reason to keep cluttering the list with nonsense. And that's all I have to say about that. :) Mt. -- Marco Tabini President Marco Tabini & Associates, Inc. 28 Bombay Avenue Toronto, ON M3H 1B7 Canada Phone: (416) 630-6202 Fax: (416) 630-5057 Web: http://www.tabini.ca -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: var_dump_html()
On Thu, 2003-07-03 at 13:49, Björn Schotte wrote: > * Marco Tabini wrote: > > So, your position is that a developer should bend to the technology. > > No. My position is that a developer should evolve and learn > that there are some more professional ways than just dumping > debug data to the browser instead of a log file. Please, do not imply that what I am suggesting is unprofessional. It is practical. It works just as well, and is applicable to a wider range of platforms than your methodology without requiring any special setup. > > -- > ThinkPHP und Partner auf dem LinuxTag. Seien Sie mit dabei, und > lernen Sie die PHP Profis kennen! 10. - 13. Juli 2003, Karlsruhe. > > * ThinkPHP sponsert "PHP and friends"-Projekt auf dem LinuxTag * -- Marco Tabini President Marco Tabini & Associates, Inc. 28 Bombay Avenue Toronto, ON M3H 1B7 Canada Phone: (416) 630-6202 Fax: (416) 630-5057 Web: http://www.tabini.ca -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: var_dump_html()
On Thu, 2003-07-03 at 13:43, Björn Schotte wrote: > * Marco Tabini wrote: > > (a) Not everybody does it that way > > That's no argument. Well, how can I argue with this? > > (b) Not everybody *can do it* that way--think Windows users. > > Cygwin exists and I'm sure there's a bunch of freeware/shareware > tools that do the same. So, your position is that a developer should bend to the technology. Mine is that the technology should bend to the developer. Both have their merits. I'll use my patch and you can use your error log--nothing wrong in either case. Marco -- Marco Tabini President Marco Tabini & Associates, Inc. 28 Bombay Avenue Toronto, ON M3H 1B7 Canada Phone: (416) 630-6202 Fax: (416) 630-5057 Web: http://www.tabini.ca -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: var_dump_html()
On Thu, 2003-07-03 at 13:33, Björn Schotte wrote: > Normally one would dump to an error_log (and having > a tail -f php_error.log in another shell), not to the browser. > If one has a small web package, he could do "" ... "", > so there shouldn't be any problem. Yes, but-- (a) Not everybody does it that way (b) Not everybody *can do it* that way--think Windows users. Cheers, Marco -- Marco Tabini President Marco Tabini & Associates, Inc. 28 Bombay Avenue Toronto, ON M3H 1B7 Canada Phone: (416) 630-6202 Fax: (416) 630-5057 Web: http://www.tabini.ca -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: var_dump_html()
On Thu, 2003-07-03 at 13:09, Frank Wiegand wrote: > IMHO its not PHP's job to produce HTML output for debugging purposes. Well, then, I guess we'll have to agree to disagree. IMO, PHP's job is to work in a way that is most useful to the developer. Since most developers use PHP in web projects, it makes sense, I think, that PHP's debug output is suitable to that environment. > > I'd prefer the PEAR package, because: > > * You have more control about the output layout (Var_Dump.php uses skins). > * There are (as said) three functions in PHP that do nearly all the same. > * Using the package is not more complicated than using var_dump. > It's a two liner (but you can use auto_prepend_file). A two-liner is twice as many lines as a one-liner :-) . In a debugging situation, you often add and remove var_dump()'s quickly and all over the place while hunting down a bug. Having to worry about an extra step uselessly complicates things, in my view. If using the built-in functions is not any more complicated than using PEAR, then why not get rid of them at all? Because they are useful, of course. Except that in their current form they are less useful than they could be. > Using Var_Dump makes your script slower, but (high-)speed doesn't matter > while debugging PHP scripts. Agreed. But high development speed does matter, and having to use PEAR doesn't help you there. In any case, the discussion is sort of moot, since the patch won't be applied. I'll just use it for my internal purposes, and it's in the archives for anyone who may find it useful. Cheers, Marco -- Marco Tabini President Marco Tabini & Associates, Inc. 28 Bombay Avenue Toronto, ON M3H 1B7 Canada Phone: (416) 630-6202 Fax: (416) 630-5057 Web: http://www.tabini.ca -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: var_dump_html()
On Thu, 2003-07-03 at 11:47, Frank Wiegand wrote: > Marco Tabini wrote: > > > Not sure if this interest anyone, but the attached patch adds a function > > called var_dump_html() that performs the same functionality as > > var_dump(), except that it outputs HTML instead of plain text. > > var_dump() is a bit impractical to use in a web environment, IMO. > > Please have a look at PEAR::PHP::Var_Dump: > > http://pear.php.net/package-info.php?pacid=103 Thanks, Frank, I have. But do I really want to load up a PEAR class to dump my variables to the browser? For me, the answer is no--although, obviously, that is only my opinion. Cheers, Marco > > > Frank -- Marco Tabini President Marco Tabini & Associates, Inc. 28 Bombay Avenue Toronto, ON M3H 1B7 Canada Phone: (416) 630-6202 Fax: (416) 630-5057 Web: http://www.tabini.ca -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] var_dump_html()
My only consideration is that most people use var_dump in a web environment--hence it seems counterintuitive to have to enclose the function in additional HTML tags. Cheers! On Thu, 2003-07-03 at 11:09, Derick Rethans wrote: > On Thu, 3 Jul 2003, Marco Tabini wrote: > > > Not sure if this interest anyone, but the attached patch adds a function > > called var_dump_html() that performs the same functionality as > > var_dump(), except that it outputs HTML instead of plain text. > > var_dump() is a bit impractical to use in a web environment, IMO. > > We already have three functions for dumping debug info (var_dump, > var_export and print_r). The latter two can be used like: > > echo "". var_export($var, TRUE). ""; > > I don't think that we should add another here. > > regards, > Derick -- Marco Tabini President Marco Tabini & Associates, Inc. 28 Bombay Avenue Toronto, ON M3H 1B7 Canada Phone: (416) 630-6202 Fax: (416) 630-5057 Web: http://www.tabini.ca -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] var_dump_html()
Not sure if this interest anyone, but the attached patch adds a function
called var_dump_html() that performs the same functionality as
var_dump(), except that it outputs HTML instead of plain text.
var_dump() is a bit impractical to use in a web environment, IMO.
Cheers,
Marco
--
Marco Tabini
President
Marco Tabini & Associates, Inc.
28 Bombay Avenue
Toronto, ON M3H 1B7
Canada
Phone: (416) 630-6202
Fax: (416) 630-5057
Web: http://www.tabini.ca
Index: basic_functions.c
===
RCS file: /repository/php-src/ext/standard/basic_functions.c,v
retrieving revision 1.616
diff -u -r1.616 basic_functions.c
--- basic_functions.c 28 Jun 2003 05:38:52 - 1.616
+++ basic_functions.c 3 Jul 2003 14:53:08 -
@@ -556,6 +556,7 @@
PHP_FE(unserialize, NULL)
PHP_FE(var_dump, NULL)
+ PHP_FE(var_dump_html, NULL)
PHP_FE(var_export, NULL)
PHP_FE(debug_zval_dump, NULL)
PHP_FE(print_r, NULL)
Index: php_var.h
===
RCS file: /repository/php-src/ext/standard/php_var.h,v
retrieving revision 1.26
diff -u -r1.26 php_var.h
--- php_var.h 10 Jun 2003 20:03:38 - 1.26
+++ php_var.h 3 Jul 2003 14:53:08 -
@@ -24,6 +24,7 @@
#include "ext/standard/php_smart_str_public.h"
PHP_FUNCTION(var_dump);
+PHP_FUNCTION(var_dump_html);
PHP_FUNCTION(var_export);
PHP_FUNCTION(debug_zval_dump);
PHP_FUNCTION(serialize);
@@ -32,7 +33,7 @@
PHP_FUNCTION(memory_get_usage);
#endif
-PHPAPI void php_var_dump(zval **struc, int level TSRMLS_DC);
+PHPAPI void php_var_dump(zval **struc, int level TSRMLS_DC, int output_html);
PHPAPI void php_var_export(zval **struc, int level TSRMLS_DC);
PHPAPI void php_debug_zval_dump(zval **struc, int level TSRMLS_DC);
Index: var.c
===
RCS file: /repository/php-src/ext/standard/var.c,v
retrieving revision 1.167
diff -u -r1.167 var.c
--- var.c 10 Jun 2003 20:03:39 - 1.167
+++ var.c 3 Jul 2003 14:53:09 -
@@ -33,8 +33,10 @@
#include "php_smart_str.h"
#include "basic_functions.h"
#include "php_incomplete_class.h"
+#include "html.h"
#define COMMON ((*struc)->is_ref ? "&" : "")
+#define COMMON_HTML_SAFE ((*struc)->is_ref ? "&" : "")
#define Z_REFCOUNT_PP(a) ((*a)->refcount)
/* }}} */
@@ -42,87 +44,110 @@
static int php_array_element_dump(zval **zv, int num_args, va_list args, zend_hash_key *hash_key)
{
- int level;
+ int level, output_html;
+ char *space, *newline;
TSRMLS_FETCH();
level = va_arg(args, int);
+ newline = va_arg (args, char *);
+ space = va_arg (args, char *);
+ output_html = va_arg (args, int);
if (hash_key->nKeyLength==0) { /* numeric key */
- php_printf("%*c[%ld]=>\n", level + 1, ' ', hash_key->h);
+ php_printf("%*s[%ld]=>%s", level + 1, space, hash_key->h, newline);
} else { /* string key */
- php_printf("%*c[\"%s\"]=>\n", level + 1, ' ', hash_key->arKey);
+ php_printf("%*s[\"%s\"]=>%s", level + 1, space, hash_key->arKey, newline);
}
- php_var_dump(zv, level + 2 TSRMLS_CC);
+ php_var_dump(zv, level + 2 TSRMLS_CC, output_html);
return 0;
}
-PHPAPI void php_var_dump(zval **struc, int level TSRMLS_DC)
+PHPAPI void php_var_dump(zval **struc, int level TSRMLS_DC, int output_html)
{
HashTable *myht = NULL;
- char *class_name;
+ char *class_name, newline[5], space[13], ampersand[6], *html_value;
zend_uint class_name_len;
zend_class_entry *ce;
+ int i, newlen;
+
+ if (output_html) {
+ strcpy (newline, "");
+ strcpy (space, " ");
+ strcpy (ampersand, "&");
+ }
+ else {
+ strcpy (newline, "\n");
+ strcpy (space, " ");
+ strcpy (ampersand, "&");
+ }
if (level > 1) {
- php_printf("%*c", level - 1, ' ');
+ php_printf("%*s", level - 1, space);
}
switch (Z_TYPE_PP(struc)) {
case IS_BOOL:
- php_printf("%sbool(%s)\n", COMMON, Z_LVAL_PP(struc)?"true":"false");
+ php_printf("%sbool(%s)%s", COMMON_HTML_SAFE, Z_LVAL_PP(struc)?"true":"false", newline);
break;
case IS_NULL:
- php_printf("%sNULL\n", COMMON);
+ php_printf("%sNULL%s", COMMON_HTML_SAFE, newline);
break;
case IS_LONG:
- php_printf("%sint(%ld)\n", COMMON, Z_LVAL_PP(struc));
+ php_printf("%sint(%ld)%s", COMMON_HTML_SAFE, Z_LVAL_PP(struc), newline);
break;
case IS_DOUBLE:
- php_printf("%sfloat(%.*G)\n", COMMON, (int) EG(precision), Z_DVAL_PP(struc));
+ php_printf("%sfloat(%.*G)%s", COMMON_HTML_SAFE, (int) EG(precision), Z_DVAL_PP(struc), newline)
Re: [PHP-DEV] enabling sqlite by default
> I don't know a single kernel guy who uses the graphical interfaces. And > like Zeev said, we used to have this fancy configuration tool. It even > had a web interface for a while where you could go and click on checkboxes > and it would generate your configuration. It was actually pretty good, > but nobody cared. I am not sure why people would suddenly want to use > something like this now. Just two thoughts: - How many "kernel people" do we know anyway? The majority of PHP users are not kernel people (or whatever the equivalent for PHP is). I, for one, recompile my kernel rather frequently and enjoy using the menu-based tools; and I know lots of people who, like me, do. If that makes us inexperienced users, then so be it, but what I wonder is which group represents the majority. - I wonder how many people have actually started using PHP since that configuration tool was available. Perhaps the average makeup of the PHP user today is different enough that such a system might turn out to be popular. Regardless, these are not to orthogonal concepts. The configuration tool can well be external to PHP proper--that way, it would be possible to evaluate its effectiveness. There are probably more pressing issues right now, and I'm certainly not the best judge of what they are. Mt. > > -Rasmus -- Marco Tabini President Marco Tabini & Associates, Inc. 28 Bombay Avenue Toronto, ON M3H 1B7 Canada Phone: (416) 630-6202 Fax: (416) 630-5057 Web: http://www.tabini.ca -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] enabling sqlite by default
Even with a menu-driven approach (e.g.: make menuconfig in the kernel)? My thought is that you'd still feed the end result through ./configure, but the app would make it somewhat easier for those who don't have a clue. It would also be possible to distribute "pre-packaged" configurations for common scenarios, thus removing the problem of what to distribute by default. Cheers, Marco On Tue, 2003-06-24 at 10:51, Dan Kalowsky wrote: > I've proposed such solutions in the past, and only recently have come to > dislike the means (but not the idea). Mainly because the mechanism to do > such a configuration could lead to a longer configuration time then > compile time. > > > > On Tue, 24 Jun 2003, Marco Tabini wrote: > > > Why not disable all extensions by default and add a configuration > > utility that is launched before compilation--sort-of like the Linux > > kernel? > > >---< > Dan Kalowsky "I'll walk a thousand miles just > http://www.deadmime.org/~dank to slip this skin." > [EMAIL PROTECTED] - "Streets of Philadelphia", > [EMAIL PROTECTED] Bruce Springsteen -- Marco Tabini President Marco Tabini & Associates, Inc. 28 Bombay Avenue Toronto, ON M3H 1B7 Canada Phone: (416) 630-6202 Fax: (416) 630-5057 Web: http://www.tabini.ca -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] enabling sqlite by default
Why not disable all extensions by default and add a configuration utility that is launched before compilation--sort-of like the Linux kernel? Marco On Tue, 2003-06-24 at 10:56, Ilia A. wrote: > On June 24, 2003 10:40 am, George Schlossnagle wrote: > > I dig including it in ext, and bundling the full sqlite sources as > > well. I just don't think it should be enabled by default. > > Enabling sqlite by default has virtually no performance impact. Your binary is > increased by roughly 100k and you initialize a dosen or so constants on > startup. Comparatively speaking it is much 'nicer' then tokenizer (enabled by > default) which initialized couple hundred constants at start up. > > Ilia -- Marco Tabini President Marco Tabini & Associates, Inc. 28 Bombay Avenue Toronto, ON M3H 1B7 Canada Phone: (416) 630-6202 Fax: (416) 630-5057 Web: http://www.tabini.ca -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Double warnings with session_start
Are these not two different error messages? They are output in two different places in the source. Marco On Sun, 2003-06-22 at 10:41, Zeev Suraski wrote: > Any chance you have both display_errors and log_errors enabled? It would > cause one copy of the error to go to stdout, and another to go to stderr. > > Zeev > > At 16:54 22/06/2003, michel 'ziobudda' morelli wrote: > >Hi, I'm devoloping a book for PHP so I'm writing a chapter about > >session. And I have found this new error with > >/usr/local/php5-17062003/bin/php -v > >PHP 5.0.0-dev (cli) (built: Jun 17 2003 21:40:52) > >Copyright (c) 1997-2003 The PHP Group > >Zend Engine v2.0.0-dev, Copyright (c) 1998-2003 Zend Technologies > > > >The little file.php is > > > > 1 > > 2 > 3 session_start(); > > 4 ?> > > 5 session inizializzata > > > >and this is the output: > > > > > >Warning: session_start(): Cannot send session cookie - headers already > >sent by (output started at /home/httpd/html/LIBRO/sessioni/1.php:2) in > >/home/httpd/html/LIBRO/sessioni/1.php on line 3 > > > >Warning: session_start(): Cannot send session cache limiter - headers > >already sent (output started at /home/httpd/html/LIBRO/sessioni/1.php:2) > >in /home/httpd/html/LIBRO/sessioni/1.php on line 3 > >session inizializzata > > > >Note the double warning. > > > >The other error for session is the not working of session_decode into a > >class for managing session > >(http://www.ziobudda.net/test/session4-3.phps). With PHP4 there is no > >problem with this. > > > >Bye. > >-- > >michel 'ziobudda' morelli <[EMAIL PROTECTED]> > > > > > >-- > >PHP Internals - PHP Runtime Development Mailing List > >To unsubscribe, visit: http://www.php.net/unsub.php -- Marco Tabini President Marco Tabini & Associates, Inc. 28 Bombay Avenue Toronto, ON M3H 1B7 Canada Phone: (416) 630-6202 Fax: (416) 630-5057 Web: http://www.tabini.ca -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Bug #24281
Take two (this time hopefully clearing the variable before resetting it):
Index: string.c
===
RCS file: /repository/php4/ext/standard/string.c,v
retrieving revision 1.391
diff -u -r1.391 string.c
--- string.c20 Jun 2003 15:41:43 - 1.391
+++ string.c22 Jun 2003 13:29:22 -
@@ -3194,7 +3194,8 @@
php_str_replace_in_subject(*search, *replace, subject, return_value,
case_sensitivity, (argc > 3) ? &count : NULL);
}
if (argc > 3) {
- Z_LVAL_PP(zcount) = count;
+ zval_dtor(*zcount);
+ ZVAL_LONG(*zcount, count);
}
}
/* }}} */
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Bug #24281
I stumbled upon bug #24281 while running a few test on the current HEAD
for PHP5--it seems to me that it should be sufficient to change a single
line of code to make str_replace() work as expected, but I'm not
familiar enough with the internals to know whether my fix is good or
not...so, here it is. It seems to work for my test case, and for the
test case reported in the bug.
Cheers,
Marco
Index: string.c
===
RCS file: /repository/php4/ext/standard/string.c,v
retrieving revision 1.391
diff -u -r1.391 string.c
--- string.c20 Jun 2003 15:41:43 - 1.391
+++ string.c22 Jun 2003 13:06:51 -
@@ -3194,7 +3194,7 @@
php_str_replace_in_subject(*search, *replace, subject, return_value,
case_sensitivity, (argc > 3) ? &count : NULL);
}
if (argc > 3) {
- Z_LVAL_PP(zcount) = count;
+ ZVAL_LONG(*zcount, count);
}
}
/* }}} */
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
