Re: [PHP-DEV] Huge Pages

[Brian Moon]

On 3/19/16 23:29 , Rasmus wrote:

We have a bit of a problem with how Linux handles huge pages when you
run out of them.

I've been discussing it with Dmitry and he recently committed a way to
disable Huge Pages in the main allocator to master:

https://github.com/php/php-src/commit/945a661912612cdecd221cd126feda7d4335c33c


Unfortunately it looks like Linux is very unhappy when a CoW happens to
a huge page allocated in its parent process and it tries to re-map this
page. If there are no available huge pages you get random seg faults/bus
errors and everything blows up. I don't understand why Linux can't fall
back to a regular page here in this case, but it doesn't. It seems like
an OS bug to me, but nonetheless this affects mod_php/php-fpm since we
have a huge page allocated before the fork, but it also affects any cli
script that does a pcntl_fork(). As far as I can tell there is no way to
fix it. We could try to make sure we never do a MAP_HUGETLB prior to the
fork in mod_php/php-fpm but that still doesn't solve the pcntl_fork() case.

Anatol, we should merge Dmitry's patch into PHP-7.0 and further, I think
we should flip the default to zend_mm_use_huge_pages = 0 in it.

If you have well-behaved code that never tries to allocate a lot of
memory you can turn on huge pages, but I think we should default to
safety here. Those SIGBUS storms are quite alarming and hard to figure out.

There have also been some other issues with huge pages as per these bugs:

https://bugs.php.net/70984
https://bugs.php.net/71272
https://bugs.php.net/71355

This is very much an expert feature that we need to document better and
people should know what they are stepping in when they turn this feature
on.

-Rasmus



This explains a recent issue reported for GearmanManager on PHP 7 as well.

PHP Warning:  pcntl_fork(): Error 12 in 
/usr/local/share/gearman-manager/GearmanManager.php on line 929


Error 12 is a memory allocation error.

https://github.com/brianlmoon/GearmanManager/issues/136

--

Brian.

http://brian.moonspot.net/

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] [Draft] Adopt Code of Conduct

[Brian Moon]

> Why not? The harassment has been nullified.

I agree with your position on most of this, Paul. However, free email, and 
thus, Twitter and other social media accounts are nearly unlimited. It becomes 
an arms race to try and block someone.

Brian.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Core functions throwing exceptions in PHP7

[Brian Moon]

On 7/14/15 16:04 , Sammy Kaye Powers wrote:

Hello lovely PHP nerds,

There are two open PR's for PHP7 to modify the behavior of the CSPRNG's:

https://github.com/php/php-src/pull/1397 (main discussion)
https://github.com/php/php-src/pull/1398

Currently the random_*() functions will issue a warning and return false if
a good source of random cannot be found. This is a potential security hole
in the event the RNG fails and returns false which gets evaluated as 0 in a
cryptographic context.


On the surface, this sounds like a good thing. Although, I question that 
if a user is not checking $result === false, then will they end up just 
wrapping this in an empty try/catch so their code does not fail? There 
is a mechanism to detect the error now.


I question why the cryptographic functions would not force an integer to 
be passed. Those should not accept a boolean and evaluate it as false. I 
am not sure what functions you are talking about though. Maybe 3rd party 
user land code? Accepting a boolean in those cases is a bug in that code 
IMO.


--

Brian.

http://brian.moonspot.net/

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Method call overhead

[Brian Moon]

On 6/2/15 22:30 , Bishop Bettini wrote:

Hi!

I've measured the overhead for method calls in a variety of environments
(Amazon, Travis, and 3v4l).  The results are reliable and here's 3v4l
.

Some observations.  First, as expected, direct calls are faster than static
object calls, which are faster than object calls.  Second, in absolute
times PHP7 outperforms HHVM3 substantially.  Kudos, really impressive.

My question though is on relative times.  Method call overhead is
consistently 50% to 150% over a direct call.  Is my experiment invalid, or
is this overhead expected?  Is the overhead in the allocation,
deallocation, GC?

Cheers,
bishop



This is a better representation of what you are trying to show. It 
removes all the magic call back stuff that could be adding to the 
slowness you are seeing. In addition, it does not create a new object on 
every call for the object method. Creating a new object is going to 
explicitly slow things down. But, it's not related to the call time.


http://3v4l.org/biM9G

--

Brian.

http://brian.moonspot.net/

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Coercive STH - some real world tests and updated RFC

[Brian Moon]

This RFC trying to simpliy and cleanup the coercison rules, having two
different conversion rules for NULL->scalar
depending on userland or internal is counter-productive and bad. The
behavior you describe as null being
empty value is wide-spread in PHP userland code as well.


I agree here with Benjamin. The thing I have wanted in user land for 
years is to be able to build a user land function that worked the way 
internal functions do in terms of type checking without having to build 
my own type checking system. Having internal functions convert null to a 
scalar and not having user land do the same creates an inconsistency. 
For example, sometimes you want to wrap/extend an internal function (you 
see it a lot with json* to do encoding checking). I can't reliably take 
the same input to my user land wrapper that I can send to the internal 
function. I would prefer to see the same rules apply to internal and 
user land.


--

Brian.

http://brian.moonspot.net/

--
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?

[Brian Moon]

On 9/20/14, 0:11 , Sara Golemon wrote:



On Sep 19, 2014, at 18:29, Andrea Faulds  wrote:
Perhaps I’m being unfair and overthinking things,

Yes, you are.


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?

Yes, it is.

-Sara


Yes, What Sara said. I am the type of person that would be excluded. I 
contributed to PHP a lot 10 years ago. However, in all the SVN and GIT 
moving, all my karma has long since been removed. I vote in almost every 
RFC because I have a long history with PHP and care about where it is 
going. People with dead accounts and who don't care about PHP most 
likely don't vote.


Brian Moon
brianlm...@php.net

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [VOTE][RFC] Name of Next Release of PHP

[Brian Moon]

I got the vibe that people weren't happy with the RFC, and that's why
the vote was cancelled, so I was suggesting a way forward, but maybe I
misread the situation.


I think that was 2 days and many, many emails ago. The parties that 
expressed an opinion on the RFC which led to the vote being cancelled 
are actually in agreement now.


If we don't use a counterpoint style debate in the RFC, then '6' only 
has one bullet:


* 6 is the next integer after 5.

Brian Moon
brianlm...@php.net
http://brian.moonspot.net/


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [VOTE][RFC] Name of Next Release of PHP

[Brian Moon]

Or, (maybe this is controversial in itself), drop the entire thing.

Until there is in fact, a next major version, what its name will be is
surely moot, and until there is a GA release (or at the earliest alphas /
beta test releases), there should be no such thing as a versioned /
numbered release.

Assuming the above, there is no need to discuss / vote on this now, but in
1-3 years or so (depending on who you listen to ;)), and in that time
frame, shouldn't it simply remain as PHP.next (or some random codename /
whatever).


As I read this, it occurred to me that naming things before they are 
released is how we ended up in this situation to begin with. People 
started writing PHP6 books and doing talks at conferences before PHP6 
even existed. What if the same thing happens with PHP7? Or it happens to 
PHP6 again? Right now, there is discussion about phpng being php-next. 
What if that is rolled in and later found that it was a bad idea? And 
there are talks and blog posts about "PHP7" that talk about phpng?


With Phorum, we skipped version 2 and version 4 because of this issue. 
We named them, worked on them, and then decided they were bad 
directions. Those numbers were burned. If we had not named them to begin 
with, we would not have been in that boat.


Brian Moon
brianlm...@php.net
http://brian.moonspot.net/

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: AW: AW: [PHP-DEV] FILTER_VALIDATE_INT and +0/-0

[Brian Moon]

Both statements are wrong, since the purpose of the filter extension
is to validate strings. I found this information in BR #52884 (see
last comment). Maybe it should be added to the docs? It's nonsense to
say, that FILTER_VALIDATE_INT must work like var_dump() since they
are both serving different purposes.

With this information I agree on your opinion.

var_dump(filter_var('-0',FILTER_VALIDATE_INT)); // int(0) instead of
the prior bool(false) var_dump('-0'); // string(2) "-0"
var_dump(is_int('-0')); // bool(false)


var_dump does not attempt to convert a string into an integer when 
possible. FILTER_VALIDATE_INT does. This is much more analagous to 
FILTER_VALIDATE_INT IMO.


$ php -r "echo (is_numeric('-0')) ? (int)'-0' : null;"
0

I am not intimately familiar with the internals of filter, but I 
replaced code in userland like this with filter calls.


Brian Moon


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Generators

[Brian Moon]

I don't consider this a very good example.

That's fine.  You are entitled to your opinion. However, you didn't
have to figure out the 106 lines of code that is the Post-Order
iterator.  That was a NIGHTMARE and I'm still not 100% confident that
it works as it is supposed to.  The generator, on the other hand, is
simple and follows the definition very closely.  MUCH better.


Could you show the whole class that this public function belongs to? I 
don't see how this function fits in and compares at all to the class you 
linked.


Brian.

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Generators

[Brian Moon]

On 8/12/12 5:33 PM, Levi Morrison wrote:

On Sun, Aug 12, 2012 at 2:08 PM, Brian Moon  wrote:

Do you have a good example usage other than a file? I don't find 
fopen/fgets/fclose all that complicated. What are the other valid use cases for 
such a thing?


One fabulous use case is creating an iterator for a Binary Search
Tree.  A post order done without generators looks like:
https://github.com/morrisonlevi/PHP-Datastructures/blob/master/src/Spl/PostOrderIterator.php.
  An iterator using a generator looks something like:

 public function getIterator() {
 if ($this->left) yield* $this->left;
 yield $this->value;
 if ($this->right) yield* $this->right;
 }

This is 5 lines.  The fully commented version of the post-order
iterator previously mentioned is 106 lines of code and is considerably
harder to understand.


Well, it's 52 lines, not 106. The 5 lines above are not commented nor 
are they spaced at all like the ones in the class. In the above example, 
what sets $this->right? or $this->left? There has to be more calling 
code around this. I don't consider this a very good example.


Brian.
brianlm...@php.net


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Generators

[Brian Moon]

Hi Nikita,

I admit, I have ignored these threads as there was no RFC. So, some of 
this may have been covered.


Do you have a good example usage other than a file? I don't find 
fopen/fgets/fclose all that complicated. What are the other valid use 
cases for such a thing?


Also, not allowing rewinding is unintuitive for something that is an 
iterator in PHP. If I can foreach() it and I can call next() on it, I 
expect to be able to reset() it as well. IMO, you would need to issue a 
FATAL PHP error if that simply is not allowed. Or you have to have a 
second syntax for what to do in that case. At that point, you are 
implementing Iterator.


While I am glad that PHP has borrowed syntax from many languages, I find 
the yield keyword to be very WTF when I first saw it. It is also poorly 
explained in your RFC. You use terms like "sending and receiving". That 
does not say "returns from function execution" to me. I had to basically 
figure it out from the code examples.


Lastly, because you cite needing this for sending data to PHPUnit, I 
think this is a user land problem and not a core problem. In about 5 
minutes I implemented a reusable Generator object that does exactly what 
you need. http://pastebin.com/V336rEpR At least, it does what your 
examples show you need. Again, file IO is very easy and perhaps that 
example does not explain your true need very well.


Brian
brianlm...@php.net
http://brian.moonspot.net/

On 8/11/12 8:42 AM, Nikita Popov wrote:

Hi internals!

I think there already was a lot of discussion on the generators, so
it's time to move to the next step. I'd like to vote on the feature in
two weeks, so this the "announce[ment] on internals@, by the author,
with the intention of voting on it".

 https://wiki.php.net/rfc/generators

If you have any further feedback, now would be a good time to raise
it. If there is something you previously posted, but which I didn't
yet address, please let me know. There were around 150 mails and I
sure missed some of them.

Thanks,
Nikita



--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] RFC: Removing PHP tags

[Brian Moon]

Well played Moriyoshi. Well played.

Brian.
http://brian.moonspot.net

On 3/31/12 10:02 PM, Rasmus Lerdorf wrote:

On Mar 31, 2012, at 7:45 PM, Moriyoshi Koizumi  wrote:


Ok, I'll try to fix that part. Thanks for the correction.








No problem. Keeping the April 1st RFCs factually accurate is a top priority 
around here.

-Rasmus


--
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

[Brian Moon]

From your blog post:
> All in all, I have tried to eliminate the syntax noise by
> reducing the key strokes in the the non-significant parts
> of the expression is typing time really the bottleneck for
> productivity

Is typing really the bottleneck for developers these days? I must suck 
then. I spend most of my day thinking or waiting on version control, 
testing and deploy applications, not typing.


Brian.
http://brian.moonspot.net


--
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)

[Brian Moon]

On 6/2/11 11:08 AM, Pierre Joye wrote:

reminder #2, pls do vote here:
https://wiki.php.net/rfc/shortsyntaxforarrays/vote some devs still did
not choose which syntax they want.


I don't really care which syntax wins as long as one of them gets rolled in.

Brian.

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [PATCH] Notice on array to string convertion

[Brian Moon]

I like this for the current stable branch, no bc impact and gives a
way to detect such mistakes (not ideal but better than nothing).

On Thu, Jun 2, 2011 at 12:11 PM, Patrick ALLAERT  wrote:

Hi,

I would like to introduce an E_NOTICE when an array is silently
converted to a string.
This isn't very useful as it constantly produces the following string:
"Array" and in most of the case, this is a sign of an error.

Let me know about your feelings.


I agree with Peirre and would actually support this as an E_WARNING. 
Since there is a patch for E_NOTICE already, I will take it.


--
Brian.
http://brian.moonspot.net

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] RFC: Short syntax for Arrays (redux)

[Brian Moon]

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

Re: [PHP-DEV] Porting PECL to userspace

[Brian Moon]

I think it's the exact opposite - the less C code we need the better.
Developing C code is more work. Maintaining C code is more work.
Distributing C code is more complicated. The less this is needed, the
faster PHP is, the better for everybody (except C programmers ;-) )


I was with you until "The less this is needed, the faster PHP is, the 
better for everybody". PHP is just a glue language on top of an awesome 
library of C. If more people would embrace that and quit including 1000 
classes to show a simple web page then it would be better for everybody.


Brian.

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] == Comparison type juggling

[Brian Moon]

or strcmp()


yeah, strcmp is your friend there.

Brian.

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Function proposal: varset

[Brian Moon]

which one?
I guess that you are talking about the language constructs like isset and
empty.
they aren't functions.


settype() for one.

Brian.

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Function proposal: varset

[Brian Moon]

I proposed something similar over 5 years ago. It ain't gonna happen
because PHP language can't support it.


It supports it. Several functions allow you to pass in variables that 
are not set and don't throw an error. Not sure what you are talking about.


Brian.

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Function proposal: varset

[Brian Moon]

It might be nice to extend it such that if the 1st argument is a list then the
first in the list which is set is returned, eg:

$var = var_set(($_GET['var'], $_POST['var']), 'default');


If that is the usage, I would suggest coalesce() to be consistent with 
the same concept in SQL. And you would not need a list as the first 
argument. Just pass multiple arguments and return the first set value.


$var = var_set($_GET['var'], $_POST['var'], 'default');

http://en.wikipedia.org/wiki/Null_%28SQL%29#COALESCE

Brian.

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Adding a more logical string slicing function to PHP

[Brian Moon]

How would str_contains() be different from strstr()?



They differ in the return type


$instr = (bool)strstr($string1, $string2);

done. No need for a new function.

Brian.

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Named parameters

[Brian Moon]

The absolute minimum is, if you have objections, to be specific, or at
least provide concrete links to specific objections, instead of sending
people to hunt for the decisions manually.


So, anyone that comes on the list and wants to talk about some feature 
should just do so without looking at the history of the topic? That 
seems backwards to me. This group is open to new ideas. But, drudging up 
old ideas over and over and over is not productive. This topic gets 
brought up once per year minimum and never gets traction. But here, I 
will do the work for you this once. It took 10 seconds to search Google.


http://www.php.net/~derick/meeting-notes.html#named-parameters

Have a look at the attendee list on that meeting. If you can convice all 
those people, most of which are all still very active, go for it. But, 
the emails I have seen are the same emails I have seen before. Nothing 
new. Just trying to save people some wasted time.


--

Brian.

http://brian.moonspot.net/

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Named parameters

[Brian Moon]

This is just not happening people. Please re-read all the past 
conversations about it. If you come to some sort of epiphany that solves 
all of the issues brought up in the past, please submit a patch. 
Otherwise, a never ending thread about this *again* is pointless.


Thanks,

--

Brian.

http://brian.moonspot.net/

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Named parameters

[Brian Moon]

This has been discussed to death. Please see the archives. It has been 
turned down multiple times.


--

Brian.

http://brian.moonspot.net/

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] undefined function pcntl_fork

[Brian Moon]

On 9/13/10 11:59 AM, Bharat Nagwani wrote:

Hello,

I am getting this error when using pcntl_fork. The OS is bsd and php
ver is 5.2.3 used in cgi mode.

Fatal error: Call to undefined function pcntl_fork() in...

I have included the ext/pcntl files in the php make. Do I need
another flag/library to include pcntl?

Thanks


This list is for the development of PHP itself and not for PHP support 
questions. Please try the General mailing list.


--

Brian.

http://brian.moonspot.net/

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Strict typing

[Brian Moon]

On 8/11/10 1:03 AM, Zeev Suraski wrote:

We've also had quite a lengthy discussion on this topic, and there
was more support for 'weak' typing then there was for strict typing.


Yes, I would like to restate the obvious from my email in May:


Really, I am confused what the argument is about. We already decided
how this should work years ago. It should work just like the code
below. Having user land functions work different than built in
functions is the most confusing thing you can do. Unless of course
someone plans on fixing all the internal functions too.





$ php test.php

> string(4) "1.25"
> float(1.3)


Warning: substr() expects parameter 1 to be string, array given in
/Users/brianm/test.php on line 17

> NULL
> float(0)

--

Brian.

http://brian.moonspot.net/

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Annoucing PHP 5.4 Alpha 1

[Brian Moon]

2010/8/11 Johannes Schlüter:

On Wed, 2010-08-11 at 00:03 +0200, Kalle Sommer Nielsen wrote:

type hinting


For the record: I consider the current implementation as (one of) the
biggest mistakes in the last ten years.


Is there a summary of what we ended up with? I got so tired of all the 
complaining on the the many threads I lost track. What are all the type 
hints we can use in a function definition in trunk?


--

Brian.

http://brian.moonspot.net/

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Namespace separator constant

[Brian Moon]

On 8/10/10 3:03 PM, Ferenc Kovacs wrote:

like DIRECTORY_SEPARATOR I guess

Tyrael


but, DIRECTORY_SEPARATOR is system dependent. The namespace separator is 
not. It is is always \.


--

Brian.

http://brian.moonspot.net/

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: Detecting if a null variable exists?

[Brian Moon]

> php -r 'function f(){$f=null; var_dump(array_key_exists("f",
> get_defined_vars()));} f();'

So, two function calls? That is not a solution to simply check if a 
variable has been created. You are creating an array and operating on 
said array. It should be a language construct. Why use an array function 
to decide something about a non-array variable?



Brian.

http://brian.moonspot.net/

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Detecting if a null variable exists?

[Brian Moon]

Is it just me or are we missing a way in the language to check if a 
variable that has been set to NULL exists or not?


is_null() on an unset variable throws a NOTICE.
$var === null throws a notice.

So, you have to use isset()? But, ah,

$var = null;
if(isset($var))

yields false.

Is array_key_exists("var", $GLOBALS) the only solution to this problem? 
Seems silly.


perhaps an var_exists() function is needed to fill this hole?

--

Brian.

http://brian.moonspot.net/

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Gearman support for php-fpm?

[Brian Moon]

[gearman]
worker1.path = /path/to/worker1.php
worker1.pm = dynamic
worker1.pm.max_children = 10
worker1.pm.start_servers = 5

worker2.path = /path/to/worker2.php
worker2.pm = dynamic
worker2.pm.max_children = 4
worker2.pm.start_servers = 2


So, this is a proposed new entry in the ini format? I am a bit ignorant 
about fpm, I admit. This would require a good bit of fiddling for our 
gearman set up to work with it. We run X workers that know how to do all 
jobs available and then 1 + n (defined by ini file) that only do one job 
for each available job.  This gives us good coverage with controlled 
process load.  I guess it would just require a lot more configuration 
than we have now. For example, could we pass parameters to the script? 
Having a separate script plus a separate class for every function 
quickly makes a lot of files.


I will simply stay tuned and see where it goes.

FWIW, this is my GearmanManager that basically does this already via 
PHP+pcntl. http://github.com/brianlmoon/GearmanManager. It can not 
dynamically ramp up more workers like FPM can. But, I would never run it 
that way anyhow. I like my processes under control.


Brian.

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Gearman support for php-fpm?

[Brian Moon]

The big difference is that different processes do different jobs in 
Gearman. All PHP workers in fpm just run what ever code is handed to 
them. How do you handle that?



Brian.

http://brian.moonspot.net/

On 6/10/10 9:56 AM, Rasmus Lerdorf wrote:

Has anybody thought about adding Gearman support to the fpm sapi?
Managing Gearman workers is pretty much identical to managing fastcgi
workers, so it doesn't seem like much of a stretch.

-Rasmus



--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Array Dereferencing

[Brian Moon]

The operator that really determines this is 'new' - which is already
documented. So there isn't any ambiguity. Not to say that documenting
the other operators would be bad, just saying there's no ambiguity
here :)
  Also, allowing "new (blah());" would be a fairly big BC break I'd say.


How? Maybe you don't understand what BC break means. Currently, new ( 
produces a parse error. So, no old code would ever be broken. That is 
what a BC break is. A change to the system that breaks old code. New 
code very often does not run on older versions of the parser.


Of course I think all this chaining stuff is for really really lazy 
people that have more time to worry about the how cool their code looks 
and don't have real jobs that actual require them to get things done. =)


Brian.
"In my day!"

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Type hinting

[Brian Moon]

I like the idea of type hinting a lot. (See: 
http://marc.info/?l=zend-engine2&m=102421231114377&w=2) I suggested it 
in 2001 when ZE2 was being designed. Somehow my idea was bastardized 
into only classes and arrays. Guess it was the mad OOP craze of the time.


Anyhow, I would like to use it. And, as much as I appreciate Derick and 
Ilia's work in getting a change in, I likely won't use it. Mainly 
because the web is a bunch of strings. Casting data from MySQL every 
time I want to use it does not interest me at all. Its a number in 
string form, treat it like one. If you use filter, you still have to 
worry with casting. There is no way to always get an int back from 
filter regardless of the input given.


Really, I am confused what the argument is about. We already decided how 
this should work years ago. It should work just like the code below. 
Having user land functions work different than built in functions is the 
most confusing thing you can do. Unless of course someone plans on 
fixing all the internal functions too.






$ php test.php
string(4) "1.25"
float(1.3)

Warning: substr() expects parameter 1 to be string, array given in 
/Users/brianm/test.php on line 17

NULL
float(0)

Brian.

brianlm...@php.net
http://brian.moonspot.net/

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Fixes for parse_url, bug 50563

[Brian Moon]

Because that is, IMO, a bad precedent to start for PHP internal 
functions. Too many functions already produce warnings (fopen) and 
return a status that can be checked. The solution right now is @ and 
that has so much baggage with it that you can now disable that feature 
completely making distributed software not be able to deal with these 
functions and return useful messages instead of spewing warnings 
uncontrollably. I am all for turning off warnings when a function 
returns a success/failure status.


Brian.

http://brian.moonspot.net/

On 5/22/10 9:42 AM, Ilia Alshanetsky wrote:

Instead of removing a warning, why not add an additional parameter to the
function that would instruct it to silence warning messages on parse
failure?

On Fri, May 21, 2010 at 11:55 AM, Brian Moon  wrote:


+1


Brian.

http://brian.moonspot.net/


On 5/21/10 10:38 AM, Ralph Schindler wrote:



Hey all,

Attached is a patch to remove the warning from parse_url() in situations
where parse_url() cannot actually parse the url. The bug report also
claims there should be a new feature for understanding "why" a parsed
url failed. That code currently does not exist, and the current warning
gives no more information than simply returning false does.

http://bugs.php.net/bug.php?id=50563

The first patch is against trunk. I think we should at least get this
done even if the group decides that down the line we want the why
portion explained as well (I actually don't care about the why part).
That feature would require that php_url_parse_ex() add some parsing
intellignce, this would not be a 1 or 2 line feature implementation.

The motivation is that since false and E_WARN are redunant, this patch
would allow developers to STOP using @parse_url(), which we have to do.

I also suggest that we apply this to the PHP_5_3 branch. This behavior
should be backwards compatible with everyone that is actually using the
@parse_url() in their code. The only 1-off situation that might be
affected is if people are catching the error with an error handler and
branching there. Why they wouldn't be branching off the false return
value, I don't know.

Both patches contain test fixes.

Is there anything more I need? Is this commit worthy?

Thanks,
Ralph



--
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] Fixes for parse_url, bug 50563

[Brian Moon]

+1


Brian.

http://brian.moonspot.net/

On 5/21/10 10:38 AM, Ralph Schindler wrote:


Hey all,

Attached is a patch to remove the warning from parse_url() in situations
where parse_url() cannot actually parse the url. The bug report also
claims there should be a new feature for understanding "why" a parsed
url failed. That code currently does not exist, and the current warning
gives no more information than simply returning false does.

http://bugs.php.net/bug.php?id=50563

The first patch is against trunk. I think we should at least get this
done even if the group decides that down the line we want the why
portion explained as well (I actually don't care about the why part).
That feature would require that php_url_parse_ex() add some parsing
intellignce, this would not be a 1 or 2 line feature implementation.

The motivation is that since false and E_WARN are redunant, this patch
would allow developers to STOP using @parse_url(), which we have to do.

I also suggest that we apply this to the PHP_5_3 branch. This behavior
should be backwards compatible with everyone that is actually using the
@parse_url() in their code. The only 1-off situation that might be
affected is if people are catching the error with an error handler and
branching there. Why they wouldn't be branching off the false return
value, I don't know.

Both patches contain test fixes.

Is there anything more I need? Is this commit worthy?

Thanks,
Ralph



--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Autoboxing in PHP

[Brian Moon]

On 5/3/10 10:48 PM, Moriyoshi Koizumi wrote:

Hey,

Just to let you know about a new RFC for adding autoboxing feature in PHP.
Look at http://wiki.php.net/rfc/autoboxing .


I liken this to pecl/runkit. "For all those things you probably 
shouldn't have been doing anyway". It will create a world where scripts 
are not portable. And if you need that for your internal project, that 
is fine. But, having this as part of the PHP core would be a disaster. 
This is even more heinous than __autoload(), IMO. SPL fixed this for 
autoload. I would support an SPL extenstion to treat primitive types as 
SPL objects. They are standardized. Not random.


Brian.

brianlm...@php.net
http://brian.moonspot.net/

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Using default_charset for htmlspecialchars() and others

[Brian Moon]

I am not sure if this has been discussed or not. I will gladly make an 
RFC if not. I think it would be very intuitive if htmlspecialchars used 
the ini value default_charset as its default. And any function that 
takes an optional character set.


A) Has this been discussed?
B) If not, do others think it is worth of a proper RFC?

There would be some BC breakage for sure as the default behavior would 
be changing.


--

Brian.

brianlm...@php.net

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] trunk is alive and open

[Brian Moon]

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 for quicker PHP releases. Seems like every 5.x release has "changed 
the world". Would love to see smaller changes as it comes out. Less 
panic when planning upgrades.


Brian.
brianlm...@php.net

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Removal of deprecated features

[Brian Moon]

safe_mode/register_globals/register_long_arrays/magic_quotes_*/allow_call_time_pass_reference
  - Something we have long time been wanted to remove from PHP, I don't
see a big reason to keep those in the next version, even if its going
to be a 5.4, since we already removed things like
zend.ze1_compatibility_mode. See the magic quotes RFC[4].


+1


asp_tags
  - Proposed to be removed aswell, Tony had a patch for this[5].


-1. Widely used, not a drain on the language. Better in some cases than 
regular PHP tags.



sql_safe_mode
  - Theres currently an RFC in the works about this by Johannes[6].


+1

Brian.

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Named Parameters

[Brian Moon]

I really doubt named parameters would have much of an impact on
anything, but I'd be willing to consider it if a clean implementation
was to show up.


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.


Is the desire for named parameters to only have it for user land 
function/methods? If so, I am kind of -.5 on this because that would be 
a little WTF for a new user.


If not, then it is a huge undertaking as every internal function and 
pecl extension would have to be updated to support them. In which case 
it is a ton of work.


I have long ago started passing arrays and doing validation myself, 
which sucks.  I admit, named parameters + scalar type hints would be 
quite nice and simplify a lot of my code.


Brian.

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] php and multithreading (additional arguments)

[Brian Moon]

Now imagine a whole web server written in PHP (ie. nanoserv), say, using
libevent as the network backend, running the above described real-time web
implementation. Alternatively, you could perhaps even wire it into worker/event
model of apache/other servers instead of rolling your own. It sounds quite 
powerful,
and development-effort-wise cheap - out of a mere HTML preprocessor!


PHP works fine in Apahce worker now if you know what you are doing and 
don't do stupid things with PHP in a web environment.  Keep all the 
stupid stuff in Gearman, cron or non-threaded servers.


This is just not what PHP is for.

Brian.

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Have we reached 1,000 authors for the PHP project?

[Brian Moon]

Neat. I would not count cvs2svn though. Or any other known bots in there 
if there are any.


Would be neat to see the list posted on pastebin though.


Brian.

http://brian.moonspot.net/

On 3/30/10 3:36 AM, Richard Quadling wrote:

Hi.

Just over 9 hours ago (Monday, March 29th 2010 at 23:02:36 UTC),
lduran became author #1000  to the PHP project.

http://svn.php.net/viewvc?view=revision&revision=297116

Using TortoiseSVN which has the ability to cache the commit log and
can generate lists of authors, changes and revisions. The authors list
shows lduran as user 1000.

ID,Name
0,""
1,"cvs2svn"
2,"sniper"
3,"sas"
4,"changelog"
5,"iliaa"
6,"helly"
7,"zeev"
8,"cellog"
...
996,"geissert"
997,"dchill42pecl"
998,"markskilbeck"
999,"gregorycu"
1000,"lduran"

Maybe this could be a news item?

Or are csv2svn and changelog not to be included? In which case we have
to wait a little bit more. Personally, author #1000 is a "good news
story".

Regards.

Richard.




--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] array_seek function

[Brian Moon]

Update: http://phpbenelux.eu/array_seek-return.patch.txt
I've kept the fseek()-style return values (0 when fine, -1 when seek fails)


Any reason why you picked that over the (IMO more logical) true/false
approach?


No, just to keep it similar to fseek(). Either way works for me.


I would expect it to return the same as current, next, prev rather than 
a file io function.


Brian.

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] array_seek function

[Brian Moon]

Right now, it returns the value of a given position.


How it's different from:

array_slice() returns the sequence of elements from the array array as
specified by the offset and length parameters?


array_slice returns an array of elements. This function would return the 
value at the given position.


Brian.

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: RFC: Replacing errors with Exceptions

[Brian Moon]

Le Fri, 24 Jul 2009 15:23:21 +0200, user a écrit :


I published a (work in progress) RFC today about replacing certain
errors with exceptions. I know that there already was something
similiar on the php6dev blog, but this is not completly the same,
so awating your comments:

http://wiki.php.net/rfc/errors_as_exceptions


I'm agree for replacing error by exception. Even if this not a good
idea, i think there is a big problem with error gesture into php.

Exemple :
http://fr3.php.net/manual/en/function.simplexml-load-string.php


A couple of people have used SimpleXML as an example of how _PHP_ errors
are broken.  The only thing that makes SimpleXML nice is the utter
horror that the other XML parsing extensions give you.

SimpleXML error handling and behavior in general is confusing.  So, if
you want to have a discussion about how SimpleXML is messed up, have it. 
But, don't lump the whole language in with it.


Brian.

http://brian.moonspot.net/


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] RFC: Replacing errors with Exceptions

[Brian Moon]

On 7/24/09 6:43 AM, Ben Scholzen 'DASPRiD' wrote:

To you both, this is especially, for library code like Zend Framework.


This tends to invalidate your entire argument IMO.  Changing the core 
language because something is hard in an external framework that only a 
small percentage of actual PHP developers use is not a a good reason.


On 7/24/09 6:40 AM, Kalle Sommer Nielsen wrote:
> I'm a big -1, I don't see a big reason for wrapping all my code in a
> try/catch block when im writing flat out procedural for example, PHP
> isn't an OO-only language

++1 on that.

Brian.

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [PATCH] Bug #46367 - fputcsv does not add the correct newline character on Windows

[Brian Moon]

On 7/7/09 1:27 PM, Jani Taskinen wrote:

John Mertic kirjoitti:

Hi All,

Bringing this one back once more; let me know what everyone thinks
about it. If it's safe to commit than if someone could ( or give me
the karma to do so ) that would be great. If not, let me know what
should be done about it instead.


Is \r\n okay on Mac? Is \r okay on Windows? etc.

Short: Shouldn't this be always \r\n? Or better yet, default to \r\n and
add extra option for fputcsv with which you can set it to anything you
like.. :)

--Jani


The only program I know of in existence that has issues is Notepad on 
Windows.  All the mac programs I use will deal with whatever.


Having said that, it should be just as flexible for creating CSV files 
as fgetcsv is for reading them.


Of course, a good ol' fputs does a fine job of making a CSV file too.

--

Brian.

http://brian.moonspot.net/

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Is there a technical reason

[Brian Moon]

On 6/5/09 2:17 PM, Stanislav Malyshev wrote:

Hi!


So it feels like decoupling 

My proposal would be very simple:
1. short_open_tag setting removed in 6, 
And while few want to talk about short tags (again), it's worth noting
that a discussion specific to decoupling really hasn't taken place
except for silence and a few "yeah, that might be alright... sometime"


I was kind of under impression I talked about it so much at the time
that everybody's sick of it, but maybe I'm wrong :)


No, #1 in your list is why people got sick of it.  You want to bind the 
decoupling of two different issues.


The only change I care to see is that let me clean up templates in so many places.  As it is, I can't use that 
in any distributed project because "short tags" may be disabled.  Leave 
short tags forever for all I care.  Probably more work to remove them 
than it is to leave them in.


--

Brian.

http://brian.moonspot.net/

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] APM

[Brian Moon]

We'd like to have your opinion on our "next steps", what is the most
important feature according to you:
- The development of the central aggregator


Yes, we run 24 boxes with PHP on them running the same code base.  When 
we have the occasional PHP error, it will be logged over and over and 
over and over until someone sees it in the log.  Usually the next day. 
We are talking notice/warning level stuff here of course.  If we could 
have all the errors in file foo.php on line 999 in one interface, it 
would be nice.  We have started on apps several times to aggregate the 
error logs into a database.



- Collecting more info related to an "event" (content of variables
$GLOBALS, $_GET, $_POST,...)


GET, POST and COOKIE would be useful to allow for a recreation of the 
environment.  Not sure about globals.



- alert systems (SNMP, Mailing, ...)


SNMP would be most flexible.  I guess some small shops would want direct 
alerting.  We use Nagios and Cacti to montior our servers.  So, SNMP 
would let us see trends using the tools we already use.  Also, using 
something like the spread protocol could be useful to allow custom 
listeners for events.


One question is what type of performance impact are we looking at here?

Brian Moon
http://brian.moonspot.net/

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Quick question about closing PHP tags

[Brian Moon]

On 2/2/09 2:55 AM, George Antoniadis wrote:

While on this subject, would it be a waste of time to suggest a file
extension or include/require parameter that would consider a whole file as
php even if there is no starting

See 2001: http://marc.info/?t=9998640691&r=1&w=2

--

Brian Moon
Senior Web Engineer
--
When you care enough to spend the very least.
http://dealnews.com/


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] $_GET['a.b.c']

[Brian Moon]

On 1/13/09 4:09 AM, Alexey Zakhlestin wrote:

In 6.0, on the other hand, register_globals is not available. So, it
doesn't make sense to have replacement there too.

5.3 is left with status-quo:
?a.b.c=10  =>   $a_b_c, $_GET['a_b_c']

6.0 will have:
?a.b.c=10  =>   $_GET['a.b.c']


What about the extract() and import_request_variables() functions?  Will 
it still do the replacement?  I foresee a lot of stop gap solutions 
using those functions to get around register_globals.  Not saying it is 
right, just curious.


--

Brian Moon
Senior Web Engineer
--
When you care enough to spend the very least.
http://dealnews.com/


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] php daemons, memory

[Brian Moon]

First, this is not an internals question. But, I would be not many 
people on the general list could help you.



I wrote some daemon scripts for a web crawler in PHP. Now I spent one
day to work around the growing memory consumtion of these scripts.


I have PHP daemons running for weeks that don't use up a lot of memory. 
 You have to be careful what you do in a PHP script.  I would guess you 
are running Linux.  Assuming you are, the linux memory system never 
frees allocated memory back to the OS.  Not until the process dies at 
least.  So, if any part of your code ever needs a lot of memory, that 
will be allocated to the process until it ends.



- Was it a mistake to use PHP for such scripts? What language should I've been
choosing instead?


Any language has its caveats.  And you can waste (leak is a strong word) 
memory with any language.



- My suspicion is, that either pdo_mysql or dom are not freeing their
   used memory during a request. Is that possible?


Are you telling pdo to free its results?  If not, that is bad 
programming.  You have to unset vars and free db result sets yourself to 
ensure they are not building up.  PHP uses a lazy garbage collector that 
is optimized for short lived web scripts.  You have to overcome that 
when working with PHP in a non-web environment.



- I'm using http://libslack.org/daemon now to control the script
   execution. This gave me the idea for a special kind of PHP binary
"php-daemon":
   - php-daemon is an executable that restarts a given php script in a
 loop
   - php-daemon can be combined with apc/xcache to store the bytecode
   Unfortunately I'm still to much a newbie to write this myself.


My standard way to handle scripts that need a lot of memory is to use 
the pcntl functions to fork children that run and do the work.  They can 
end after a certain time or memory usage.  Again, you have to make sure 
the main, parent script is well written and does not waste file 
descriptors, connections, etc.


Hmm, maybe I will write a blog post about this.

--

Brian Moon
Senior Web Engineer
--
When you care enough to spend the very least.
http://dealnews.com/


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Proposal: array_flatten function

[Brian Moon]

On 12/27/08 2:10 AM, Kevin Waterson wrote:

The last thing that is needed, is more array functions..


I would agree except that doing lots of work on arrays in user space 
consumes a lot of memory because of the number of opcodes used when 
working on removing/adding things to the array.


We created an extension for Phorum to do our array tree sorting for 
those users that had large threads of messages (1000+).  We found that 
PHP would quickly consume a memory limit of 128MB and use tons of CPU 
when working in user space to simply reorder an array.


So, in that case, doing the work in a good C function will beat out user 
space work on arrays.


--

Brian Moon
Senior Web Engineer
--
When you care enough to spend the very least.
http://dealnews.com/


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: namespace issues

[Brian Moon]

Greg Beaver wrote:

This is a bit amusing to read if one takes a step back :).  You should
know that there is quite a wide variety of opinions amongst internals
developers about the importance of functions vs. classes.  One
interesting point is that none of the internals developers I know who
use functions primarily seem to care about or want namespaces, so they
have been almost completely silent on implementation details.


That is probably because we are all accustomed to naming our functions 
the way Phorum has, phorum_foo().  C developers have no issue with this. 
 And yeah, if I step back and think about it, I really don't want them 
for MY functions.  I want them for everyone else's functions.  Because 
they are not good developers and name their functions poorly.



To all: your input is heard, and those who actually will do the
committing are working very, very hard both on and off list to try to
find a solution that will satisfy the largest number of developers.


Thank you Greg.  I wish that long ago when I had karma I had kept 
working on the internals and kept my C skills sharp.  They have atrophied


Brian Moon
[EMAIL PROTECTED]

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: namespace issues

[Brian Moon]

3. Functions will not be allowed inside namespaces. We arrived to
conclusion that they are much more trouble than they're worth, and
summarily we would be better off without them. Most of the
functionality could be easily achieved using static class methods, and
the rest may be emulated with variable function names, etc.

Comments?



Figuring that you arrived at the same conclusion nearly three years ago
regarding my namespace patch, and I also agreed that only classes should
be allowed inside namespaces
(http://marc.info/?l=php-internals&m=113320797607651&w=2), I am +1 for
this proposal.



And the congregation wept.  Man, how much more bastard ass step child do 
functions have to become?  Its not bad enough that the OOP stuff is 
littered with every little overly complicated bell and whistle.  Now 
functions are to be left behind with this feature?  Geez people.  Get 
over your OOP arrogance.



Brian Moon
[EMAIL PROTECTED]


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] php7- dropping the $ from the variable name - rfc

[Brian Moon]

mike wrote:

Personally I love the $. It makes it so much easier to identify
variables. It's a single character. Can't see the need honestly to
even bring this up.


+1,000,000.  Horrible idea.  *facepalm*

--

Brian Moon
Senior Web Engineer
--
When you care enough to spend the very least.
http://dealnews.com/


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: [PHP-DOC] Re: [PHP-DEV] [Fwd: #45687 [Opn->Bgs]: Why is PCNTL marked experimental]

[Brian Moon]

Antony Dovgal wrote:

Keeping the experimental status for so many years is a nonsense.
Apparently it's not experimental anymore.


It has been working for me for years.  I would say it is not experimental.

--

Brian Moon
Senior Web Engineer
--
When you care enough to spend the very least.
http://dealnews.com/


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] enabling everything by default

[Brian Moon]

Pierre Joye wrote:

ISP, good or bad, enables what we enable. You can see that in the
extension usage statistic (from nexen.net). They have to be taken with
a bit of salt but they represent a good way to see what actually
happens out there. I heard solutions like "educating the ISPs" and
seriously that's a sweet dream and may not reflect their needs.

An extension not enabled by default is often not used for this exact
reason: it is not enabled by default. So my thoughts are really
simple, unless disable-all is used, enable everything possible as long
as the deps are found (or if there is no dep).


As a maintainer of a distributed open source PHP application, I concur 
with this 1000 fold.  If it is not enabled by default, we can not use it 
in Phorum.  We have found that only extensions that the PHP configure 
includes by default are available on 99% of ISP's servers out there. 
So, if json is not on by default, for example, we can't use it.


--

Brian Moon
Senior Web Engineer
--
When you care enough to spend the very least.
http://dealnews.com/


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Switch Table Extension for PHP

[Brian Moon]

Stefan Esser wrote:

http://www.suspekt.org/switchtable/


Neat I hope this works well and can go into the main engine.  I did not 
look to see if there was a licensing issue.


We have basically done this in PHP land for Phorum.  We had a huge 
switch in our url creation function.  It was the slowest thing in the 
app.  So, we convered it to an array lookup system instead and got lots 
of performance.  We also made a Phorum extension to handle the URL 
creation for those that need that little extra bump.


--

Brian Moon
Senior Web Engineer
--
When you care enough to spend the very least.
http://dealnews.com/


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] New string functions: str_startswith() and str_endswith()

[Brian Moon]

Paweł Stradomski wrote:

W liście Rasmus Lerdorf z dnia poniedziałek, 21 lipca 2008:

It also isn't any shorter:

if(str_endswith($path,'.php'))

vs.

if(substr($path,-4)=='.php')


Only if comparing to a static string, but not for this case:

if (substr($path, -strlen($extension)) == $extension)

Readability would also increase.



In our code base, we have a nice file called string.php that has every 
variation of string functions not covered by the core in it.  We add 
stuff as we need it.  I break strings on the space nearest a given 
length in 80% of all code that runs on my server.  But, I don't expect a 
PHP built in to do it.  If you are worried about performance, you could 
make a PECL Strings package for all the stuff that the core does not do.


Then, your code can be readable and neat like you want.

Hmm, perhaps there is a need for a "standard" (widely used?) PHP 
(non-OO) package that filled in the gaps that the core does not provide. 
 Make it non-OO so that it looks and acts like the core as much as 
possible.  In my "spare time" I will start this. =)


--

Brian Moon
Senior Web Engineer
--
When you care enough to spend the very least.
http://dealnews.com/


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] New string functions: str_startswith() and str_endswith()

[Brian Moon]

Stan Vassilev | FM wrote:

I'm particularly for begins/endswith() function as I do this all over my
code and I'd appreciate the simplification and free extra performance.


I really don't mean to be rude here, but shorter and less typing !== 
performance gain.  The PHP string functions are very fast.  And if you 
are looking to improve your applications performance by using different 
string functions, you are likely looking in the wrong place.


--

Brian Moon
Senior Web Engineer
--
When you care enough to spend the very least.
http://dealnews.com/


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] E_USER_DEPRECATED

[Brian Moon]

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


+1 I loves me some trigger_error() and I like to deprecate things. 
Right now I generate an E_USER_WARNING which is not very accurate.


--

Brian Moon
Senior Web Engineer
--
When you care enough to spend the very least.
http://dealnews.com/


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] [Fwd: confirm unsubscribe from [EMAIL PROTECTED]

[Brian Moon]

Wow, any idea how the PHP list thought this was me that wanted to 
unsubscribe?


--

Brian Moon
Senior Web Engineer
--
When you care enough to spend the very least.
http://dealnews.com/

--- Begin Message ---
Hi! This is the ezmlm program. I'm managing the
internals@lists.php.net mailing list.

I'm working for my owner, who can be reached
at [EMAIL PROTECTED]

To confirm that you would like

   [EMAIL PROTECTED]

removed from the internals mailing list, please send an empty reply 
to this address:

   [EMAIL PROTECTED]

Usually, this happens when you just hit the "reply" button.
If this does not work, simply copy the address and paste it into
the "To:" field of a new message.

or click here:
mailto:[EMAIL PROTECTED]

I haven't checked whether your address is currently on the mailing list.
To see what address you used to subscribe, look at the messages you are
receiving from the mailing list. Each message has your address hidden
inside its return path; for example, [EMAIL PROTECTED] receives messages
with return path: [EMAIL PROTECTED]

Some mail programs are broken and cannot handle long addresses. If you
cannot reply to this request, instead send a message to
<[EMAIL PROTECTED]> and put the entire address listed above
into the "Subject:" line.


--- Administrative commands for the internals list ---

I can handle administrative requests automatically. Please
do not send them to the list address! Instead, send
your message to the correct command address:

For help and a description of available commands, send a message to:
   <[EMAIL PROTECTED]>

To subscribe to the list, send a message to:
   <[EMAIL PROTECTED]>

To remove your address from the list, just send a message to
the address in the ``List-Unsubscribe'' header of any list
message. If you haven't changed addresses since subscribing,
you can also send a message to:
   <[EMAIL PROTECTED]>

or for the digest to:
   <[EMAIL PROTECTED]>

For addition or removal of addresses, I'll send a confirmation
message to that address. When you receive it, simply reply to it
to complete the transaction.

If you need to get in touch with the human owner of this list,
please send a message to:

<[EMAIL PROTECTED]>

Please include a FORWARDED list message with ALL HEADERS intact
to make it easier to help you.

--- Enclosed is a copy of the request I received.

Return-Path: <[EMAIL PROTECTED]>
Received: (qmail 50360 invoked from network); 8 Jul 2008 02:25:57 -
Received: from unknown (HELO lists.php.net) (127.0.0.1)
  by localhost with SMTP; 8 Jul 2008 02:25:57 -
Return-Path: <[EMAIL PROTECTED]>
Authentication-Results: pb1.pair.com [EMAIL PROTECTED]; spf=unknown; 
sender-id=unknown
Authentication-Results: pb1.pair.com [EMAIL PROTECTED]; sender-id=permerror
Received-SPF: unknown (pb1.pair.com: domain dealnews.com does not designate 
90.189.24.86 as permitted sender)
X-PHP-List-Original-Sender: [EMAIL PROTECTED]
X-Host-Fingerprint: 90.189.24.86 pmsn.86.24.189.90.sable.dsl.krasnet.ru Windows 
XP SP1, 2000 SP3 (2)
Date: Mon, 07 Jul 2008 22:25:24 -0400
Received: from [90.189.24.86] ([90.189.24.86:4508] helo=aleksei)
by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP
id 7C/DB-14699-010D2784 for <[EMAIL PROTECTED]>; Mon, 07 Jul 2008 
22:25:24 -0400
Content-Return: allowed
X-Mailer: devMail.Net (3.0.1854.22234-2)
Return-Path: [EMAIL PROTECTED]
Message-Id: <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Subject: RE: 70% Savings ...3 Days Only
From: Henry Osborn <[EMAIL PROTECTED]>
MIME-Version: 1.0
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: 7bit

http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd";> 
 
 
<title>Windows Live Hotmail Print Message</title> 
<html> 
<meta http-equiv=Content-Type content="text/html; charset=unicode"> 
<meta name=Generator content="Microsoft SafeHTML"> 


<title>Untitled Document</title> 


<center> 


<a href="<a  rel="nofollow" href="http://track.msadcenter.ahzm.com/iectbff_ixcdatbedf.html"">http://track.msadcenter.ahzm.com/iectbff_ixcdatbedf.html"</a>; 
target="_blank">Click here to get enrolled for your Medical Billing 
Degree!</a><br><br> 
  <img src="<a  rel="nofollow" href="http://track.msadcenter.kicj.com/glltkzs-ixcdatbedf.gif"">http://track.msadcenter.kicj.com/glltkzs-ixcdatbedf.gif"</a>; border=0 
usemap="#Map"> 


<map name=Map id=Map> 
<area shape=rect coords="282,157,497,265" 
href="<a  rel="nofollow" href="http://track.msadcenter.hvdm.com/znfspmt_ixcdatbedf.html"">http://track.msadcenter.hvdm.com/znfspmt

Re: [PHP-DEV] How bad would it be to say/enforce that namespacing can only apply to classes and not normal functions?

[Brian Moon]

How bad would it be to say that namespacing can only apply to classes and
not normal functions?


Lame, very lame.  It would make them unusable for many distributed 
projects that are not 100% OOP.  Wordpress comes to mind.  My own Phorum 
as well.



It was my understanding that one of the primary reasons for introducing
namespacing was to protect against userland_class vs builtin_class
collision.


No, that is the OOP propaganda machine at work.  Don't listen to the OOP 
machine.  It lies. =)



Brian.

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] extensions status, to move to pecl or to drop

[Brian Moon]

Pierre Joye wrote:

You need it? Please help me to maintain and to provide reliable
binaries for windows


This statements makes it sound like extensions that do not build on 
Windows should be removed.  That sounds insane to me.  Please elaborate. 
 I must not understand what you are trying to say.  I could care less 
if any of PHP works on Windows.  I am sure Richard feels the opposite. =)


--

Brian Moon
Senior Developer/Engineer
--
When you care enough to spend the very least.
http://dealnews.com/


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] extensions status, to move to pecl or to drop

[Brian Moon]

Pierre Joye wrote:

  - smnp
  nice ext, any ISP out there willing to help? I can help for the windows 
support


Hmm, we use this.  Is it broken for 5.3 or something?  What do we need 
to do to keep this alive?


--

Brian Moon
Senior Developer/Engineer
--
When you care enough to spend the very least.
http://dealnews.com/


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: Short syntax for array literals [...]

[Brian Moon]

Derick Rethans wrote:

From what I can see there is
not a major majority in favor - in this case I'd even say that 50%
should not be enough for this  to get in.


I know blog comments are not completely scientific and perhaps not an 
accurate representation of the whole commnity. But the comments on my 
blog post seem to indicate that the people in the community, that read 
planet php, who also felt strong enough about it to comment, seemed to 
like it.


http://brian.moonspot.net/2008/05/28/short-array-syntax-for-php/#comments

Again, I know many will think this is horribly innacurate and pointless 
because all of these people don't have CVS karma.  And even I would take 
it with a grain of salt.  But I think as Rasmus has said we have to 
evolve with the common web developer that is using PHP today.


If it was up to me, none of the overly complicated OOP stuff would have 
ever made it in.  I find it useless and pointless.  You can do all that 
with a few functions, IMO.  But it was added to make all the Java 
refugees happy.


--

Brian Moon ([EMAIL PROTECTED])


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: Short syntax for array literals [...]

[Brian Moon]

Mike wrote:

In my opinion I don't think PHP would be where it is today if it wasn't
for being so easy to learn and use.

I attribute this directly to the fact that it didn't use a lot of
"syntax sugar" that is unreadable and can't be "Googled" for. You can't
Google "[]", and my guess is searching PHP.net for "[]" won't return
anything useful either.


Can you google for this:

$var = 1;

$var = "foo";

?

--

Brian Moon
Senior Developer/Engineer
--
When you care enough to spend the very least.
http://dealnews.com/


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: Short syntax for array literals [...]

[Brian Moon]

Antony Dovgal wrote:

On 28.05.2008 02:58, Sebastian Deutsch wrote:

fyi - i added a RFC

http://wiki.php.net/rfc/shortsyntaxforarrays

please add your votes


You do understand that you will not be able to use this syntax in your
products for at least next 5 years without rising min required PHP
version to the latest one, right?
That makes it even more useless.


Right, so the sooner the better. =)

--

Brian Moon
Senior Developer/Engineer
--
When you care enough to spend the very least.
http://dealnews.com/


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] PHP6 new syntax use suggestion

[Brian Moon]

Lars Strojny wrote:

a) write a proposal, b) write a patch for the Zend Engine, c) ask again.


+1 on what Lars said.  Not so much on the syntax.  That just looks like 
a parse error to me.


--

Brian Moon
Senior Developer/Engineer
--
When you care enough to spend the very least.
http://dealnews.com/


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Short syntax for array literals [...]

[Brian Moon]

Andi Gutmans wrote:

Not sure we really reached a conclusion. I think it was inconclusive and people 
got tired.

As I've stated in the past in general I don't like the ability to do things in 
more than one way but in this case I think the advantages of the cleaner syntax 
outweigh the fact that we'd have two ways. I'd prefer to support [] but I don't 
think it's a huge deal if we don't do it. It would make PHP a bit nicer :)

Andi


I almost typed it the other day not thinking.  Been doing a lot of YUI 
and {} and [] are growing on me.


+1

--

Brian Moon
Senior Developer/Engineer
--
When you care enough to spend the very least.
http://dealnews.com/


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Resending session cookies patch

[Brian Moon]

Here is a patch that will add an ini setting (session.cookie_resend) to 
resend session cookies whenever a session is started.  The point of this 
is to keep a cookie's expiration fresh as users use a site.  Currently, 
once a session is started, it will expire after cookie_lifetime no 
matter what.  For my applications, I need that cookie to only expire 
after cookie_lifetime of non use.  I also added a function called 
session_send_cookie() that will send the cookie right then in case you 
don't have access to the ini settings or want to make that customized 
based on events in your application.


The only caveat of this is that currently session_send_cookie() will 
send the Set-Cookie header every time it is called.  There is no flag in 
the _php_ps_globals struct to indicate that a cookie has been sent other 
than PS(send_cookie).  However, I can't rely on that because if the 
session is found and session.cookie_resend is 0 PS(send_cookie) is set 
to 0 already.  I could add a new flag (cookie_sent?) and track that 
anywhere that php_session_send_cookie is called or even inside 
php_session_send_cookie.  But, the coding style of this file did not 
seem to favor altering PS() inside that function.  It does not currently 
check PS(send_cookie).  It simply just fires off the Set-Cookie header.


Thoughts?

--

Brian Moon
Senior Developer/Engineer
--
When you care enough to spend the very least.
http://dealnews.com/

--- php_session.h.orig  2008-05-13 21:08:54.0 -0500
+++ php_session.h   2008-05-13 21:08:09.0 -0500
@@ -104,6 +104,7 @@
char *cookie_domain;
zend_bool  cookie_secure;
zend_bool  cookie_httponly;
+   zend_bool  cookie_resend;
ps_module *mod;
void *mod_data;
php_session_status session_status;
@@ -153,6 +154,7 @@
 PHP_FUNCTION(session_set_cookie_params);
 PHP_FUNCTION(session_get_cookie_params);
 PHP_FUNCTION(session_write_close);
+PHP_FUNCTION(session_send_cookie);

 #ifdef ZTS
 #define PS(v) TSRMG(ps_globals_id, php_ps_globals *, v)

--- session.c.orig  2008-05-13 21:09:00.0 -0500
+++ session.c   2008-05-13 21:06:20.0 -0500
@@ -77,6 +77,7 @@
PHP_FE(session_set_cookie_params, NULL)
PHP_FE(session_get_cookie_params, NULL)
PHP_FE(session_write_close,   NULL)
+   PHP_FE(session_send_cookie,   NULL)
PHP_FALIAS(session_commit, session_write_close, NULL)
{NULL, NULL, NULL}
 };
@@ -194,6 +195,7 @@
STD_PHP_INI_ENTRY("session.cookie_domain",  "",  
PHP_INI_ALL, OnUpdateString, cookie_domain,  php_ps_globals,ps_globals)
STD_PHP_INI_BOOLEAN("session.cookie_secure","",  
PHP_INI_ALL, OnUpdateBool,   cookie_secure,  php_ps_globals,ps_globals)
STD_PHP_INI_BOOLEAN("session.cookie_httponly",  "",  
PHP_INI_ALL, OnUpdateBool,   cookie_httponly,php_ps_globals,ps_globals)
+   STD_PHP_INI_BOOLEAN("session.cookie_resend","0", 
PHP_INI_ALL, OnUpdateBool,   cookie_resend,  php_ps_globals,ps_globals)
STD_PHP_INI_BOOLEAN("session.use_cookies",  "1", 
PHP_INI_ALL, OnUpdateBool,   use_cookies,php_ps_globals,ps_globals)
STD_PHP_INI_BOOLEAN("session.use_only_cookies", "0", 
PHP_INI_ALL, OnUpdateBool,   use_only_cookies,   php_ps_globals,ps_globals)
STD_PHP_INI_ENTRY("session.referer_check",  "",  
PHP_INI_ALL, OnUpdateString, extern_referer_chk, php_ps_globals,ps_globals)
@@ -1148,6 +1150,17 @@
sapi_add_header_ex(ncookie.c, ncookie.len, 0, 0 TSRMLS_CC);
 }

+/* {{{ proto void session_send_cookie(void)
+   Sends the cookie back to the browser */
+PHP_FUNCTION(session_send_cookie)
+{
+   if (PS(use_cookies)) {
+   php_session_send_cookie(TSRMLS_C);
+   PS(send_cookie) = 0;
+   }
+}
+/* }}} */
+
 PHPAPI ps_module *_php_find_ps_module(char *name TSRMLS_DC)
 {
ps_module *ret = NULL;
@@ -1259,7 +1272,9 @@
lensess + 1, (void **) &ppid) == 
SUCCESS) {
PPID2SID;
PS(apply_trans_sid) = 0;
-   PS(send_cookie) = 0;
+   if(!PS(cookie_resend)){
+   PS(send_cookie) = 0;
+   }
PS(define_sid) = 0;
}



-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Strict type hints (parameter and return value)

[Brian Moon]

I just did a grep on zend framework for is_int
and there were tons of results.


No offense to Zend, I love thos guys, but I don't think using Zend 
Framework as the gold standard for how people want to code in PHP is the 
right thing to do.


--

Brian Moon
Senior Developer/Engineer
--
When you care enough to spend the very least.
http://dealnews.com/


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Strict type hints (parameter and return value)

[Brian Moon]

Derick Rethans wrote:
I don't think scalar is very useful, but I do think there is a case for 
numeric.


I don't think string is useful.  I would use scalar instead.  I only 
need to know that the variable is not an array or object.  I can echo, 
concatenate, etc. any scalar as if it was a string.


--

Brian Moon
Senior Developer/Engineer
--
When you care enough to spend the very least.
http://dealnews.com/


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] get_magic_quotes_gpc, get-magic-quotes-runtime in head, get a "final" decision

[Brian Moon]

Richard Quadling wrote:

Aren't some things just worth the BC break?

Having never used them, I can quite happily say bomb the bastards!


Agreed.  For Phorum will just change our code from:

if ( get_magic_quotes_gpc() ) {

to:

if ( function_exists(get_magic_quotes_gpc) && get_magic_quotes_gpc() ) {


So, I guess I am +1

--

Brian Moon
Senior Developer/Engineer
--
When you care enough to spend the very least.
http://dealnews.com/

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] U

[Brian Moon]

Stanislav Malyshev wrote:

@Richard: You don't understand the Problem with _REQUEST. It is not
about the fact that someone can forge GET, POST; COOKIE variables.
It is about the fact that COOKIEs will overwrite GET and POST data in
REQUEST.


Isn't it solved by setting variables_order to correct value, at least 
partially? I.e. if you have variable in GET/POST it won't be overwritten 
by the COOKIE one, of course there still may be a scenario when the 
variable is set only in COOKIE, but then doesn't omitting 'C' from 
variables_order exclude cookies from _REQUEST?


I think this argument is a big misunderstanding.  What Stefan (I think) 
is trying to get across is that it is probably not best practices to use 
$_REQUEST  unless you know exactly what it means to use $_REQUEST.  I 
know we had some issues at dealnews where people were using $_REQUEST 
because they wanted to handle GET and POST in one stroke.  But, cookies 
would get in the way because (and this is the key) they are set in other 
pages/apps that are in no way related to the app/page in question.


So, I think Stefan's request is in the spirit of promoting best 
practices to people reading this list.  IMO, best practices for these 
variables would be to access $_GET, $_POST and $_COOKIE explicitly so 
that you always know what you are getting.


Frankly, I have considered changing the order to CGP on my servers. 
Most often, I would want GET to override cookies as they would collide 
most often when I was toggling a setting via a link or form that is to 
be saved to a cookie.


Hmm, I think I feel a blog post coming on.

--

Brian Moon
Senior Developer/Engineer
--
When you care enough to spend the very least.
http://dealnews.com/

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [PATCH] date/timelib: use system timezone database

[Brian Moon]

2008/1/9, Joe Orton <[EMAIL PROTECTED]>:

Hi folks.  It's a bit of a maintenance headache for distributions when
packages include their own copy of the timezone database, since this
needs to be updated frequently.


It is also a bit of a headache when a server does not have a complete 
timezone database for an application to utilize.  PHP did use the system 
timezone database for a long time.  But, applications like Phorum would 
have to end up making their own (and not nearly as robust) anyway 
because servers would not have all the timezones on the system.  The new 
way of PHP solves this for application developers.


-1000

--

Brian Moon
Senior Developer
--
When you care enough to spend the very least.
http://dealnews.com/

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] mysql.connect_timeout default

[Brian Moon]

I would like to propose we set this default value to something more 
appropriate for a web app.  It is currently 60 seconds.  That is a 
really long time for a web page to wait to find a mysql server, IMO. 
And in the spirit of PHP being web first, I think it should be shorter.


The place where this is an issue is when the server is down completely. 
 This bit me in the butt today.  If the server is up, but mysqld is 
not, PHP will disconnect immediately. But if there is no server 
answering on that IP address, PHP will wait `mysql.connection_timeout` 
seconds before telling you it could not connect to the server.


FWIW, the default for MySQL server is 10 seconds (increased from 5 last 
fall) for a connection timeout.


I personally like 5 seconds for the default unless someone knows a 
reason this is a bad idea.  Is there some other internal trigger to the 
connection that could cause this to be hit at 5 seconds?


Other thoughts?

--

Brian Moon
Senior Developer
--
When you care enough to spend the very least.
http://dealnews.com/

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] type hinting

[Brian Moon]

Andi Gutmans wrote:

Look it boils down to the following:

True type enforcement ala === (i.e. you pass "1" to an int and it errors
out) does not make sense for PHP (and yes, philosophy and design goals
of the language are important).

>
> What I suggested in my previous email is type hinting which also does
> the conversion to the request type. This is very much in the PHP
> spirit and also how PHP's internal functions work today. It is
> "consistent".

I agree (and did last time) with Andi about this.  I am all for using a 
== instead of === for type hinting scalars.  This will mean any scalar 
will pass as a string, but arrays and objects will not.


--

Brian Moon
Senior Developer
--
When you care enough to spend the very least.
http://dealnews.com/

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] RE: Optional scalar type hinting

[Brian Moon]

I don't get it.  We already have type hinting, just not for scalars. 
The discussion seems to be about whether or not we should have it all. 
But, the truth is, we have it.  We half way have it.  I fought for it to 
be all or nothing back then and I still think it is half done that we 
don't have scalar type hinting but we have array/object/class type 
hinting.  Talk about inconsistency.


So, can we switch the mundane conversation from "should we have type 
hinting" to "why don't we have scalar type hinting if we have non-scalar 
type hinting?"  That is the real conversation.  Type hinting is here. 
It is not going anywhere.  Let's finish the job.


--

Brian Moon
Senior Developer
--
When you care enough to spend the very least.
http://dealnews.com/

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Fwd: [PHP] php with threaded MPM problem ?

[Brian Moon]

Rashmi Badan wrote:

The test was trying to load mod_php between graceful restarts, i.e start
apache without mod_php, then modify the config file to load it and do a
graceful restart. This clearly fails because mod_php loads only on the
second load within apache. It does this by setting some pool user data in
the beginning of sapi_apache2.c:php_apache_server_startup(). So I'd have to
do two graceful restarts for it to take effect.


PHP has never worked well with graceful restarts.  Frankly, there are 
some Apache things that never seemed to do well either.  I gave up on 
graceful restarts 8 years ago.  Maybe they are better now.


Just do a full restart and all will be fine.  If this is so mission 
critical that you can't be down for 2 seconds, you need more servers and 
load balancing.  Or if you are restarting your server that often, 
something else is likely wrong.


As for changing the code, a patch that does not break anything would be 
the way to approach the list.  It was probably done the way it is done 
for a reason.


--

Brian Moon
Senior Developer
--
When you care enough to spend the very least.
http://dealnews.com/

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Garbage collector patch

[Brian Moon]

Dmitry Stogov wrote:

In general this patch will use more memory.
(4 bytes more for each heap allocated zval).

The only advantage is automatic cycle collection, but most web 
applications doesn't make cycles.


Could it be that this code should only be enabled for the CLI sapi? 
That is where I would want it most.  Only in my cli apps do I run into 
having to trick the garbage collection into working in my favor.  I 
usually end having my loop just call a function on each pass.  That 
seems to help with memory use in PHP currently.


--

Brian Moon
Senior Developer
--
http://dealnews.com/
It's good to be cheap =)

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] RFC: Dropping Namespace

[Brian Moon]

With all the above considerations, especially my first point, I still have not
heard any good reason why namespaces in the current implementation are actually
useful - or what particular case they solve... so I am wondering, are they
really useful? I come now to the conclusion that they are not, and for myself
(and most likely my work projects) I would have to decide not to go with
namespaces, but instead stick with the 3 letter prefixing.  Something that I
have totally no problem with, as it is nice and easy.


I hate to, but I agree.  If the only point is to make class naming 
pretty, it is kind of pointless.  Give me namespaces that scope 
variables to a file and then we have something.  Yeah, I still code the 
way PHP intended you to code, by templateing files together and not 
making gynormous classes to print out some simple HTML over and over.


It would only be useful in that my company's code would not conflict 
with some 3rd party software we use.


--

Brian Moon
Senior Developer
--
http://dealnews.com/
It's good to be cheap =)

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Bring back call-time pass-by-reference

[Brian Moon]

Karoly Negyesi wrote:

Dear Brian,

Say, you have a CMS which generally calls some kind of functions and
some of them might need to modify one array the other needs to modify
two arrays... Currently you need to wrap these into a "arguments"
array otherwise func_get_args will butcher your references.

Regards,

NK


So, you need to relabel this, "func_get_args() should allow arguments to 
be passed by reference".  This has nothing to do with call time pass by 
reference IMO.


--

Brian Moon
Senior Developer
--
http://dealnews.com/
It's good to be cheap =)

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Bring back call-time pass-by-reference

[Brian Moon]

Karoly Negyesi wrote:

Hi,

Although this should be an old hat, I am surprised PHP5 has not fixed
it, let's fix it in PHP6. There are things you can't without call time
pass-by-reference, most of all variables arguments with references.
So, please de-deprecate it.


I am feeling froggy.  I will bite.  What can't you do?  I can think of 
several really bad things that can happen.  It can't be OOP cause 
objects are already always passed by reference.


--

Brian Moon
Senior Developer
--
http://dealnews.com/
It's good to be cheap =)

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] PDO performance

[Brian Moon]

Andrew Mason wrote:

Hi guys,
Just a quick question. I've recently been looking  at changing over
our code to use the PDO interface to a mysql database.

Currently we are using MySQLi but after looking at the PDO interface i
personally prefer the way API is presented (not saying mysqli is bad
or  anything like that...completely personal). I was just wondering if
there was any performance or latency hit by using PDO with mysql 5.

From what i have benchmarked there isn't any at all, but since PDO
came back faster for a few things i'm not sure how accurate my
benchmarks were =)

Just looking for some feedback.

many thanks
Andrew



I have not done the benchmark recently, but here is what I found last 
year.  It just depends on what is important to you.


http://dealnews.com/developers/php-mysql.html

--

Brian Moon
Senior Developer
--
http://dealnews.com/
It's good to be cheap =)

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Re: PHP 5.2.5RC1 testing

[Brian Moon]

Any chance we could get bug http://bugs.php.net/bug.php?id=38770 fixed 
before 5.2.5 is final?  It looks like reverting this change would do it.

http://cvs.php.net/viewvc.cgi/php-src/ext/standard/pack.c?r1=1.57.2.5.2.3&r2=1.57.2.5.2.4

Example:

Linux mtest1 2.6.20-gentoo-r8 #1 SMP Thu Jun 28 10:31:14 EDT 2007 x86_64

mtest1 cli # ./php -v
PHP 5.2.0 (cli) (built: Oct 23 2007 10:20:30)
Copyright (c) 1997-2006 The PHP Group
Zend Engine v2.2.0, Copyright (c) 1998-2006 Zend Technologies
mtest1 cli # ./php -a
Interactive mode enabled


array(1) {
  [1]=>
  int(2147483648)
}


mtest1 cli # ./php -v
PHP 5.2.5RC1 (cli) (built: Oct 23 2007 10:22:16)
Copyright (c) 1997-2007 The PHP Group
Zend Engine v2.2.0, Copyright (c) 1998-2007 Zend Technologies
mtest1 cli # ./php -a
Interactive mode enabled


array(1) {
  [1]=>
  int(-2147483648)
}



--

Brian Moon
Senior Developer
--
http://dealnews.com/
It's good to be cheap =)

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] import/use last call

[Brian Moon]

Stanislav Malyshev wrote:
Since many packages (wordpress, propel, horde, phing, etc.) use "import" 
as either class or function name, and we couldn't find a good solution 
to make it work with import keyword without going into all kinds of 
troublesome hacks, so we are thinking about replacing 'import' keyword 
with 'use' keyword, which is already reserved.


If 'use' is already reserved, it makes the most sense IMO.

--

Brian Moon
Senior Developer
--
http://dealnews.com/
It's good to be cheap =)

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] PHP 5.3 Suggested Feature List

[Brian Moon]

All none listed are zero for me.


1) Backport the namespaces patch for PHP 6


1


6) Remove safe_mode, register_globals and magic_quotes


-1

7) Introduce mysqlind library into core and use it as a backend for PDO 
and mysqli extensions (possibly enabling them by default)


1


8) OpenID enabling patch for OpenSSL and PHP 5


1


9) Add array_replace[_recursive] functions (patch is already available)


1


10) Split off deprecation from E_STRICT into E_DEPRECATED


1

16) Introduce new php.ini files parser/scanner + CGI/FastCGI? "htaccess" 
style ini file support


1


--

Brian Moon
Senior Developer
--
http://dealnews.com/
It's good to be cheap =)

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Question about Namespace patch

[Brian Moon]

Derick Rethans wrote:
I sort of agree, I don't see how the current implementation is really 
useful for anything.


Well, for us, it would be useful for using 3rd party applications with 
our internally written code.  We have mostly a functional (as in C not 
as in BASIC) environment.  Recently we wanted to use Wordpress and 
MediaWiki for an internal project.  We had to drudge through THEIR code 
and the error logs to find all the functions that conflicted with ones 
in our own code library.


Now, if we had this namespaces implementation, we could namespace all of 
our internal code with a namespace of dealnews and ideally those 
projects would namespace their projects.  This way there would be no 
conflicts in the global scope.


Now, in Phorum, we did it the hard way and have hundreds of phorum_* 
functions.  It makes for some really bad reading code with those huge 
function names.


I guess what this comes down to is that these namespaces are better for 
project wide things and not so good at smaller parts.  I agree that I 
would not want to work with 50 different namespaces with this solution. 
 But, I would never work with 50 different namespaces as I don't find 
that type of organization useful.


--

Brian Moon
Senior Developer
--
http://dealnews.com/
It's good to be cheap =)

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Question about Namespace patch

[Brian Moon]

David Zülke wrote:
Oh yes, sure, that must be the main point about namespaces - I can use 
"::" instead of "_" as a delimiter! Yay!


If all you are going to do is:



Then why use a namespace?  I really don't see the point.  Namespaces are 
doing nothing for you in this case.


--

Brian Moon
Senior Developer
--
http://dealnews.com/
It's good to be cheap =)

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Question about Namespace patch

[Brian Moon]

import SQLAlchemy::Column
import SQLAlchemy::Table
import SQLAlchemy::Join
import SQLAlchemy::ForeignKey
import SQLAlchemy::Session
import SQLAlchemy::Transaction


Why use namespaces if you are going to do this?  You are just bringing 
your classes into the global name space.  The nice thing about 
namespaces IMO, is that I don't have to have a class named 
SQLAlchemy_Transaction.  I can just have a class named Transaction in 
the SQLAlchemy namespace.  I can then create a new object using $obj = 
new SQLAlchemy::Transaction.


--

Brian Moon
Senior Developer
--
http://dealnews.com/
It's good to be cheap =)

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] DateTime and setlocale()

[Brian Moon]

I was just wondering if it was intentional to ignore setlocale() in the 
new DateTime object and its friends?  That is a real let down if it was 
intentional.  Maybe its just a future feature?


--

Brian Moon
Senior Developer
--
http://dealnews.com/
It's good to be cheap =)

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] RIP PHP 4?

[Brian Moon]

Derick Rethans wrote:

Ladies, Gentlemen, Kings and Princesses,

With the nice PHP 5 / PHP 6 unicode semantics thread under way I am 
trying to gauge what people feel about dropping support for PHP 4 at the 
end of this year. That does not mean that we will not fix security 
issues, we have to as the install base is too large, but that would be 
the only thing that would warrant a new release. I already sort of 
mentioned this on april 1st, but I think we should come with a slightly 
more official statement. Your votes please (only -1 and +1 are 
allowed)!


regards,
Derick


 +1

--

Brian Moon
Senior Developer
--
http://dealnews.com/
It's good to be cheap =)

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Simple Namespace Proposal

[Brian Moon]

Dmitry Stogov wrote:

I think the following example is much better, however I am not sure it's a
right direction. Namespaces are intended to declare names that can conflict
with names from other namespaces (including global namespace), do I am not
sure that we need special keyword for internal functions.

We'll think little bit more. Anyway thank you for feedback and idea.




I could live with this.  Would this only override built-in functions or 
any function in the global scope.  Or, rather, would you have to do this 
for all functions in the global scope?  If so, I see a new problem. =) 
If I write my project using name spaces, and have all my functions 
inside the Phorum namespace and some other project does not use 
namespaces and has the same function name, my project now throws errors 
if I do not use overloaded.


--

Brian Moon
Senior Developer
--
http://dealnews.com/
It's good to be cheap =)

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Simple Namespace Proposal

[Brian Moon]

It is possible to use the same namespace in several PHP files.


Does this mean that a project like Phorum could declare the same 
namespace at the top of all of our files and all the code in those files 
would exist in the same namespace?


common.php:


list.php:



Or, would list.php have to import the Phorum namespace?

Also, I don't see any mention of variables in namespaces.  Will there be 
no effect on variables?


--

Brian Moon
Senior Developer
--
http://dealnews.com/
It's good to be cheap =)

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] apache_child_terminate on Apache 2.x

[Brian Moon]

So, Gentoo has removed Apache 1.3 from Portage.  RedHat and others has 
not installed it for years.  Frankly, the only reason we have for 
sticking with 1.3 is the lack of apache_child_terminate support in PHP 
for Apache 2.


Does Apache 2 simply not provide this anymore?  Was it left out for a 
philosophical reason?  Was it just over looked?  Like it or not, PHP is 
gonna have to work well on Apache 2 at some point.  I don't like it, but 
its reality.  AFAIK, this is the only apache function that does not work 
in Apache 2.


--

Brian Moon
Senior Developer
--
http://dealnews.com/
It's good to be cheap =)

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php