Re: [PHP-DEV] [RFC] Libsodium - Discussion

[Ronald Chmara]

On Wed, Jun 1, 2016 at 10:26 AM, Fleshgrinder  wrote:
> On 6/1/2016 12:48 PM, Marco Pivetta wrote:
>> I also agree with Remi on naming: let's avoid calling the extension
>> `libsodium`.
> On 6/1/2016 12:48 PM, Marco Pivetta wrote:
>>  1. is there a particular reason why abbreviations are used? For instance,
>> why `sodium_randombytes_buf()` instead of `sodium_random_bytes_buffer()`?
>>  2. from a naming perspective, I'd expect `sodium_randombytes_buf()` to
>> give me a buffer of random bytes (probably as a stream), but it returns the
>> actual string of random bytes. Again: confusing naming
>>  3. can we avoid using "themed" naming? For example, instead of
>> `sodium_crypto_secretbox()`, it would be best to express what it actually
>> does, like `sodium_encrypt_and_sign()`. While the naming may be emerging
>> from lower layers, I still (like I did with other RFCs) disagree with
>> inheriting confusing naming. This will just cause users to look up the
>> naming up when reading or writing code, and ultimately add up to silly
>> bugs. I can already foresee that people will use the API incorrectly just
>> because of the naming.
> I agree here too but read on.
>
> On 6/1/2016 12:48 PM, Marco Pivetta wrote:
>>  4. can't we just keep it namespaced under `Sodium`, instead of adding more
>> stuff to the root level namespace? Does anyone have a reference to the
>> coding standards that would cause the rename?
>>
> I was the person who brought this up because it is not desired according
> to the existing CODING STANDARD:
>
> https://github.com/php/php-src/blob/master/CODING_STANDARDS

Hi. 
https://github.com/php/php-src/commit/aa203477bc24b1fadc16d65533c1749162260592
was my commit, put together as a result of discussions on this list
(and sidebars). I can try to speak to it from memory.

> Note that it also encourages this weird C style naming with
> abbreviations, hence, I would be open for discussing it.

It was 2000, 16 years ago.

WRT: "C style naming": C style PHP, *was* a big part of the PHP
adoption base in 2000. No objects. No inheritance. No classes. No
namespaces. Folks were also coming to PHP from ColdFusion, from Perl,
from JavaScript, and bringing their language conventions with them.
Without many guide rails, there was a weird mix of CreaTive_nameing
(and spelling). Conventions like verbnoun, Noun_Verb,
parent_Verb_noun, Parent(Noun())(and most imaginiable
permutations) were sprinkled throughout the code, throughout
documentation, throughout the community... and one of the earliest
public complaints about PHP was about about inconsitent function
naming. The goal was to bend the curve, over the years, to bring some
order and consistency, not just to internal function naming (as in
this case), but to the entire PHP ecosystem. Thus, the standards about
parent naming, about underscores and

...Abbreviation: In 2000, most PHP code was typed, manually, No IDE
completion, no built-in syntax checking, no code generators, every
single keystoke was a human hammering away in emacs/vi, BBedit,
Notepad (etc.), and longer function names tended to decrease code
quality (due to increased human error potential), and take up valuable
screen space (800x600 pixels on emergency terminals, though a nice
developer setup could have had 1024x768 pixels on a screen, all *at
the same time*.)  Coding houses still had rules like "maximum of 80
characters per line", to encourage brevity. Abbreviation in this
environment made for more compact code, with less typing errors, but
came with the costs of inconsistent abbreviations, and decreased
readability.

In 2016, using an editor with built in syntax highlighting,
auto-completion, while at coding desks measuring in thousands of
pixels across multiple screens, it seems a bit dated, but when
debugging text files with vi on a spare monochrome terminal session,
late night over a modem at 3,600 Kbps, those things mattered a great
deal. For folks who are still using modems, terminals, and updating
their PHP on 800 pixel screens, I imagine they might still matter.

-Ronabop

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

Re: [PHP-DEV] Re: Improving PHP's type system

[Ronald Chmara]

On Tue, Apr 19, 2016 at 3:09 PM, Marco Pivetta  wrote:
> In general, improving the type system provides a much more interesting and
> practical playground for any kind of tool that would rely on static
> introspection: IDEs, reflectors, code generators, code inliners,

So, tooling that relies upon (more) strict typing is less useful for
for PHP, therefore, rather than change the tooling to be more capable
with looser typing, change PHP?

-Ronabop

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

Re: [PHP-DEV] Handling of withdrawn RFCs

[Ronald Chmara]

On Thu, Jan 21, 2016 at 12:33 PM, Flyingmana  wrote:
> An RFC could still be valuable for the project, even if the original
> author leaved, so taking it over should be possible. And it should not
> be painful in any way.
> Would we need some rules in case multiple people want to take it over,
> or should we say the first one wins?
> Is there any way to abuse the taking over of an withdrawn RFC?

Hypothetically:

An RFC being used primarily for ongoing debate/argument/trolling
purposes could live indefinitely, generating hundreds, or thousands,
of messages, and changesets/PR's, and list churn, in the name of
"making sure an issue is adequately discussed and resolved".

Even as individual trolls, marks, and sockpuppets were knocked down,
new ones could pick up the mantle of "but we're discussing important
things, here!", and continue the loop, only finally exhausting the
suite of RFC mechanisms all of the trolls/marks/puppets finally gave
up, or were someho0w being administratively prohibited from all future
participation.

Which, if the PHP email lists were an endless trolling/argument/debate
forum like twitter or reddit, would be completely appropriate.

This is all hypothetical, of course.

-Ronabop

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

Re: [PHP-DEV] Handling of withdrawn RFCs

[Ronald Chmara]

On Thu, Jan 21, 2016 at 12:59 PM, Peter Lind <peter.e.l...@gmail.com> wrote:
> On 21 January 2016 at 21:53, Ronald Chmara <rona...@gmail.com> wrote:
>> On Thu, Jan 21, 2016 at 12:33 PM, Flyingmana <flyingm...@googlemail.com>
>> wrote:
>> > Is there any way to abuse the taking over of an withdrawn RFC?
Snip_>
>> An RFC being used primarily for ongoing debate/argument/trolling
>> purposes could live indefinitely, generating hundreds, or thousands,
>> of messages, and changesets/PR's, and list churn, in the name of
>> "making sure an issue is adequately discussed and resolved".
>> Even as individual trolls, marks, and sockpuppets were knocked down,
>> new ones could pick up the mantle of "but we're discussing important
>> things, here!", and continue the loop...
Snip_>
> This thread being about withdrawn/re-proposed RFCs, how is that comment
> relevant?

The relevance is in ways to "abuse the taking over of an withdrawn RFC".

> Seeing as anyone wanting to debate/argument/troll indefinitely can
> do so using their own RFC -

Creating a new RFC has a higher barrier to entry, requiring additional effort.

> or, for that matter, without an RFC.

I would suggest that random email trolling does not have the same
audience, impact, or formal trappings of a public RFC process.

-Ronabop

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

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

[Ronald Chmara]

I note that after much hue and cry, and many arguments, I still do not
know what color this bikeshed will be.

I feel I have been informed of the many examples of problems with
colors, cultural relevance of specific hues, details of paint
techniques, anecdotes of past experiences with varying colors, larger
socio-economic issues reflected through color choices, philosophy of
colors, philosophy *about* the philosophy of color, legal and moral
issues confronted during color evaluation, the impact of other
bikeshed color choices, and how specific colors (and patterns) are
under-represented,  the finer details of paint application personel
selection, and how certain colors are representative of larger social
issues being played out in microcosms in individual environments...

but I still do not know what color this bikeshed will be.

Please advise.

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

Re: [PHP-DEV] Practical comparisons on PHP7

[Ronald Chmara]

On Thu, Dec 10, 2015 at 3:16 AM, Lester Caine  wrote:

> On 10/12/15 11:02, Björn Larsson wrote:
> > Just noticed that Smarty team is working on a 3.1.28 relase that plans
> > to be PHP 7 compliant, see: https://github.com/smarty-php/smarty
> The version I'm running is not giving any errors, similarly ADOdb. Both
> were brought up to be clean on PHP5.4 and that seems to be the case with
> most BC problems. BUT should either of these packages need any 'major
> upgrade' to take advantage of a faster PHP7?


Few software stacks should need any major changes to use PHP7.

They are e_strict compliant
> and well structured so why would they not perform twice as fast on PHP7?


If a portion of a stack is poorly architected, poorly written, or poorly
implemented, the gains in moving to PHP 7 may be negligible.

PHP7 does not double the speed of accessing or updating databases, so if a
page is bogged down by an large amount of DB queries, PHP7 will not fix
that.

PHP7 does not double the speed of filesystem reads and file writes, so if a
page has significant amounts of local filesystem access (say, using
class/file auto-loaders, or messes around with a whole bunch of template
files, data files, whatever) PHP7 will not fix that.

PHP7 does not double the speed of network interactions, so if a page has
significant amounts of network access (say, pulling data from other URL's,
) PHP7 will not fix that.

PHP7 does not double the execution speeds of non PHP library calls, so for
example, (in addition to db access libraries) image manipulation libraries,
PDF builders, (etc.) will not see increased execution speeds, as they are
outside of PHP7.

...Those are just some of the low hanging fruit I've run into professionaly
that have showed big gains in addressing.

There are lots of possible reasons why PHP7 will show dramatic improvements
for some, and little improvement for others. The "PHP7 may double speeds"
holds true for certain kinds of PHP code, and usage, but if a page is
currently bogged down with crap code, or external calls to things outside
of PHP, the overall gains in changing to PHP7 may not be dramatic.

-Ronabop

Re: [PHP-DEV] [RFC] Block requests to builtin SQL functions where PHP can prove the call is vulnerable to a potential SQL-injection attack

[Ronald Chmara]

On Thu, Jul 30, 2015 at 8:38 AM, Craig Francis cr...@craigfrancis.co.uk
wrote:

 On 30 Jul 2015, at 16:26, Ronald Chmara rona...@gmail.com wrote:
  Perhaps I have missed something in this discussion
 I think you have... my email from a couple of weeks ago was ignored... so
 I replied to Matt's suggestion (which is similar, but different).
 Please, just spend a few minutes reading my suggestion, it has absolutely
 nothing todo with breaking applications:
http://news.php.net/php.internals/87207

   https://bugs.php.net/bug.php?id=69886


The RFC and bug report both make an erroneous assumption that unescaped GPC
input is wrong.

I was addressing some cases where it is the correct, intended, behavior.

WRT breaking:
Application stacks which go from zero E_NOTICE warnings, to hundreds or
thousands of them a second or day, is (admittedly) poorly phrased as
breaking. It is a possible side effect of the proposed solutiions. I have
worked in very stingent environments where an unapproved E_NOTICE is
considered a ship-stop break, but I did not explicitly explain that. Such
environments would require re-writes of all SQL that throws an E_NOTICE, or
a per-line exception review and approval process, or disabling/not enabling
the checking.


 And yes, I do have a bypass_the_nerfing function (well, a function to say
 the variable has already been escaped)... but the idea is that it's ever so
 slightly harder to use than the related escaping functions, and rarely
 needed.


Rarely is subjective at this point, a quanyifyable sampling of some kind
could be more meaningful. (How rare?)

Based on *my* purely anecdotal experience, in the last X years of using PHP
I have have frequently encountered situations where passing through
engine-unescaped text strings, to SQL, is desired for some reason, in
nearly every environment. I mentioned one use case that I thought might be
relevant to a large number of users, there are others.

Off the top of my head, some use cases I have dealt with relevant to this
discussion, that should be considered (even if they're discarded as
trivial):
1. Administrator has a web application that is supposed to allow them
access functionally equivalent to a direct connection to a database.
2. Overhead of using the engine escaping technique (setup connection(if not
done yet), send text to escape at network speed, recieve escaped text at
network speed) was considered too much of an additional performance hit.
3. Text needed to have a generic, user written, escaping library/function
to handle multiple destinations (think 5 different data storage systems,
all with different escaping rules, some without connection based escaping).
4. Text being supplied was coming from a pre-cleaned, trusted, source, even
though the variable was GPC, (example: it was a GET string assembled by a
batch job that was pulling from another database)

I'm sure there are many more.

Basing language decisions on personal perceptions of rarely and
frequently is not a good practice, but ensuring that we are covering
multiple use-cases is. Discussing the use cases doesn't mean I think the
idea is without merit.

-Ronabop

Re: [PHP-DEV] [RFC] Block requests to builtin SQL functions where PHP can prove the call is vulnerable to a potential SQL-injection attack

[Ronald Chmara]

Perhaps I have missed something in this discussion where such a change to
PHP does not break every single application that is supposed to pass raw,
user submitted, SQL *without* getting prepared/nerfed, or warned about, by
intentional application design.

If we're just limiting the nerfing for submitted GPC variables (since PHP
is used a lot for web applications) we still have a non-trivial number
of those installed applications which require raw, user created, unescaped
SQL, passing through to function as designed.

I am thinking of the class of applications like phpMyAdmin, as well as the
the millions of other database utility scripts, application install
scripts, (etc.) out there that perform similar tasks, that need to pass raw
SQL, as crafted by users, without preparation, intentionally.

Of course, we could just add a bypass_the_nerfing() function, and such a
function could then possibly see widespread adoption, everywhere, rendering
the entire exercise moot.

Re: [PHP-DEV] Regenerating session ID automatically when IP address has changed

[Ronald Chmara]

On Tue, Sep 24, 2013 at 8:52 PM, Yasuo Ohgaki yohg...@ohgaki.net wrote:

 Hi,
 On Tue, Sep 24, 2013 at 12:46 PM, Ronald Chmara rona...@gmail.com wrote:

 When you have a group of front-end termination points in a pool, proxying
 requests off to hundreds of machines for thousands of applications, tying a
 session to any IP is a headache. IMO, sessions are supposed to be tied to
 users, not any given inbound IP that can, and may, jump between different
 routers, proxies, NAT hosts, etc.

 Session is tied to specific user(browser) regardless of IP unless session
 ID is hijacked.
 Renewing session ID does not matter. Regenerating session ID when IP has
 changed
 would help users to notice session hijack. This is the sole purpose of
 regenerating
 session ID when IP has changed. I think only few apps do this now.


So, say you have many front ends, with load balancing, and public IP
addresses. Those front-ends talk on private IP ranges to back-end machines,
so the session can come in from any public IP, be proxied, and handed off.
This, BTW, is not hypothetical, it's about my work with http://appfog.com.
Some actual numbers to explain : Our Singapore location (for example)
has 29,088
websites, with  6 incoming IP addresses talking to 27 website nodes.
Regenerating session keys is a waste of CPU at that scale, as a given
user's requests may jump around 6 different inbound addresses, and any
number of servers.

Takeaway:
1) Binding session to IP doesn't work at scale.
2) Seeing that the IP has changed is totally useless to detect hijacking.
3) Session libraries that are expecting state, on the internet, are
fundamentally broken by design.

rant
There is no such thing as a secure http session. Ever. The protocol, by
design, does not allow it. Ever. You can add layers (such as https) to make
things better, but if you want secure communication, don't use the
internet.
/rant

-Ronabop

Re: [PHP-DEV] Regenerating session ID automatically when IP address has changed

[Ronald Chmara]

When you have a group of front-end termination points in a pool, proxying
requests off to hundreds of machines for thousands of applications, tying a
session to any IP is a headache. IMO, sessions are supposed to be tied to
users, not any given inbound IP that can, and may, jump between different
routers, proxies, NAT hosts, etc.

-Ronabop


On Mon, Sep 23, 2013 at 7:29 PM, Yasuo Ohgaki yohg...@ohgaki.net wrote:

 Hi all,

 There isn't any good counter measure session hijack.
 However, we can regenerate session ID if IP address has changed.
 Hijacked users might notice that they have been logged out if session
 ID is regenerated by attackers. Therefore, users have slight chance
 to notice that they were under attack. It's not greatly effective, but
 better than nothing.

 Although this can be implemented in user script, it would be better if
 session module supports this behavior. Better security by default
 is good thing. It requires INI, since some apps may assume session
 ID would not change.
 (I do not encourage to use session ID for CSRF protection, but
 there are such implementations, for example.)

 A concern is that there are growing number of browsers share
 state. I do not research these browsers behavior yet. I suppose
 session cookie (expire=0) would not be shared.

 Anyone has any comments on this?

 Regards,

 --
 Yasuo Ohgaki
 yohg...@ohgaki.net

Re: [PHP-DEV] Website down?

[Ronald Chmara]

Same from here.


On Thu, Mar 14, 2013 at 8:43 PM, Thomas Hruska thru...@cubiclesoft.comwrote:

 I'm getting a HTTP 500 Internal Server Error on the php.net homepage (
 http://www.php.net/) from my local machine and a computer in a completely
 different state on a different network.

 --
 Thomas Hruska
 CubicleSoft President

 I've got great, time saving software that you might find useful.

 http://cubiclesoft.com/

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

Re: [PHP-DEV] I think that Function naming inconsistency bug deservers more attention

[Ronald Chmara]

Here I am, ten years later, and the same issue is being rehashed just as it
was when it was brought up ten years ago.

Over those ten years, things have slowly gotten better, but the underlying
issue remains the same. PHP is glue. PHP has not taken the path of
re-naming everything to conform to a new PHP standard, other than
underscores, and attempts at function prefixes.

Sure, we could start adding aliases like libc_strlen(), and maybe that's
worth a thought, but its adding another layer of complexity, to achieve
simplicity.


On Fri, Jan 25, 2013 at 11:04 AM, Rasmus Lerdorf ras...@lerdorf.com wrote:

 On 01/25/2013 10:55 AM, Seva Lapsha wrote:
  Well, how about renaming the functions, create aliases for BC and throw
  E_DEPRECATED or E_STRICT on their usage? And write a PEAR script bundled
  with the distribution to migrate to the new convention?

 Throwing warnings on perfectly working code is really a bad idea. It
 annoys users, slows down their code, and doesn't add any value at all to
 them.

 It should also be noted that many of the function names that people
 don't think are consistent are actually quite consistent when you
 consider that PHP is just a thin wrapper on top of underlying libraries.
 Functions from libc like tempnam() and strlen() are perfectly fine. The
 fact that you can go to your Linux command line and type: man tempnam
 to get a good idea of what is happening behind the scenes of the PHP
 function of the same name is a good thing.

 -Rasmus


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

Re: [PHP-DEV] RFC: ext/mysql deprecation

[Ronald Chmara]

On Wed, Nov 21, 2012 at 10:56 AM, Kris Craig kris.cr...@gmail.com wrote:
 On Wed, Nov 21, 2012 at 7:43 AM, Thomas Hruska thru...@cubiclesoft.comwrote:
 On 11/12/2012 9:22 AM, Derick Rethans wrote:
 Why deprecate?  Just because you like PDO doesn't mean everyone else will
 like it.  Just because mysql_query() tends to create security
 vulnerabilities in the hands of the uneducated who have the tendency to
 string concatenate SQL queries together in an unsafe fashion, doesn't mean
 users won't write insecure code with PDO.  Users are lazy - binding each
 field separately is going to drive some to resort to string concatenation,
 which will result in a situation nearly identical to what you have already.
  In the hands of someone who knows what they are doing, ext/mysql is the
 same as, if not better than, mysqli and PDO.
 PHP is not etched in stone.  It is an ever-evolving, ever-improving
 language.  I'm not sure I understand the reasoning behind your ext/mysql
 is the same as, if not better than, mysqli and PDO remark.

In the hands of someone who knows what they are doing, ext/mysql is
the same as, if not better than, mysqli and PDO.
...is the sentence in question. Note the qualifier.

 The ext/mysql
 extension does not support prepared statements; mysqli and PDO do

If you know what your're doing, prepared statement workflows are just
wasteful code bloat with absolutely no  tangible benefits.
Again, note the qualifier.

 There is simply no rational reason for continuing to use ext/mysql over
 mysqli and PDO.

Not editing millions of lines of stable, and secure, code is a rational reason.

  It does present significant security vulnerabilities.

sarcasm
Well, C has had tons of insecurities over the years, maybe we should
migrate PHP to be written in, oh, Ruby or something new and shiny like
that, because newer languages make shooting yourself in the foot
harder, and new somehow means secure.
/sarcasm

If there are actual security vulnerabilities in ext/mysql, by all
means, that's a good reason for rapid deprecation, but if there are
security vulnerabilities because people who *didn't know what they
were doing*.created them, that's a battle that cannot be won.

-Ronabop

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

Re: [PHP-DEV] RFC: ext/mysql deprecation

[Ronald Chmara]

On Thu, Nov 15, 2012 at 10:38 PM, Johannes Schlüter
johannes.schlue...@oracle.com wrote:
 We, from the MySQL Connector Team at Oracle, add new features to mysqli (and 
 eventually PDO) only, though, for quite some time already. Bugs in ext/mysql 
 are being fixed in a best effort way and we plan to do this as long as 
 required by the community.

 Users should use mysqli for having access to everything MySQL has to offer.

 Officially deprecating mysqli is, in my opinion, mostly a help for users to 
 go in the correct direction early instead of struggling due to missing 
 features later.

Er, mysqli, too? What?

-Ronabop

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

Re: [PHP-DEV] RFC: ext/mysql deprecation

[Ronald Chmara]

On Tue, Nov 13, 2012 at 8:28 AM, Arvids Godjuks
arvids.godj...@gmail.com wrote:
 It took me like 10 minutes of Search  Replace in my IDE to make a switch
 to mysqli and a few more hours to validate that everything is ok and catch
 places where search  replace failed. The amount of work is overestimated,
 especially if you have a regexp capable search  replace.

10 minutes x 50 billion
(http://www.statisticbrain.com/total-number-of-pages-indexed-by-google/
) is not a trivial number. Heck, assume even only 10% of the web pages
on the internet use mysql_* calls, and you're still talking 50 billion
minutes, or about 95 thousand years. At 1%, it's only 9 thousand
years, possibly greater than the entire written and recorded history
of the human race.

Considering there are a huge quantity of PHP end users (Drupal,
Joomla, Wordpress, Magento, etc.) who don't even know what 'regexp'
means, and would take a lot more time than ten minutes just trying to
understand why my website is broken, can you fix it? yeah.

On the less pessimistic side, since I work as a PHP site
author/maintainer for a living, a pool of 9,000 years of work would
suit me just fine. Even 900 years would equate to a huge jobs program
for my field.

-Ronabop

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

Re: [PHP-DEV] Working with floats

[Ronald Chmara]

Your CompSci education (or lack thereof) has failed you.

Use the source.

Floats behave differently under different conditions.

-Ronabop

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

Re: [PHP-DEV] [proposal + patch] array_pick() function

[Ronald Chmara]

Standard hazing:
1. Tests?
2. Docs?

Annoying if needed whining:
I think array_pick and array_rand are precisely the kind of
function naming that makes PHP infamous. I would suggest that
array_rand_key() and array_rand_value(), or array_rand() with an
argument to default to key (for BC).

Speed testing: Are there any metrics to support/prove this is faster
than existing PHP calls to do the same thing?

On Sun, Jul 22, 2012 at 5:15 PM, Andrew Faulds a...@ajf.me wrote:
  Hi there,

 This is a small function, called array_pick(), which takes one argument
 ($array), an array, and returns the value of a random item.

 Much of its usefulness stems from the new short array syntax, which lets you 
 do
 array_pick([funlogo.png, coollogo.jpg, kittens.gif]);, instead of $a =
 array(funlogo.png, coollogo.jpg, kittens.gif); $a = $a[array_rand($a)];
 It's also useful for picking a random value out of a none-literal array. For
 instance today it would have been handy for my markov chain propaganda 
 generator
 (not the most practical example, I realise.)

 However, of course, PHP already has array_rand(), and an equivalent function
 could be implemented in 3 lines of code. The reason I'd like it added to PHP
 though is largely convenience. It's in at least two other languages I use
 (Python's random.choice(), Game Maker/GML's choose()) and I use it quite often
 in different projects (just today I've needed it 4 times in PHP code). It's 
 also
 the logical counterpart to array_rand(), which gets a random key, not a random
 value, so it would help API completeness. I'm pretty sure I'm not the only
 person who wants to fetch a random array value, not a random array key, too.
 It's useful also in the scenario where you want a random value of nested 
 arrays
 ($array['thing']['foo']).

 Enough rambling, here's a pull request. 
 https://github.com/php/php-src/pull/142
 https://github.com/php/php-src/pull/142

 --
 Andrew Faulds
 http://ajf.me/

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

[PHP-DEV] A new idea on PHP6.

[Ronald Chmara]

With PHP 6, lets start with a:
Pure
Object
Oriented
PHP

...idea, and extend it out, so we can have a:
Structured
Heuristic
Idealistic
Taxonomy

..so we reduce user confusion, and eliminate the vast majority of our
userbase, (thus cutting down on bug reports, of course)  so we can
have a:
Heuristic
Accessible
Readable
Available
Helpful
...language advance.

(This is not meant as a serious post, but as a post to increase levity
on this list. Your mileage may vary. Cape does not enable the wearer
to fly.)

-Ronabop

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

Re: [PHP-DEV] A new idea on PHP6.

[Ronald Chmara]

On Thu, Jul 19, 2012 at 11:09 AM, Kris Craig kris.cr...@gmail.com wrote:
 I get that the first two acronyms are POOP and SHIT; however, the third one,
 HARAH, is throwing me off.  Is that a fecal reference in some other language
 or something?

http://www.youswear.com/index.asp?language=Hebrew

I thought about making an acronym for  PAAMAYIM NEKUDOTAYIM, just
for the giggles, but decided it was way too much work, and might be
even *more* obtuse.

-Ronabop

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

Re: [PHP-DEV] Subdomain Set Up

[Ronald Chmara]

On Sat, Jun 16, 2012 at 10:28 AM, Johannes Schlüter
johan...@schlueters.de wrote:
 On Sat, 2012-06-16 at 14:34 +0200, Gustavo Lopes wrote:
 On Sat, 16 Jun 2012 14:17:04 +0200, Paul Dragoonis dragoo...@gmail.com
 wrote:
  I attempted to get (and failed) some attention on my request that I
  posted to php-webmaster mailing list, so I'm escalating it here:
  http://news.php.net/php.webmaster/13696
 I agree that this request should not be granted. I don't see why we should
 be in the business of, among other things, deciding whether code should be
 indented or otherwise formatted.
 I think it is a good thing to push many things to userland. The PHP Core
 distribution should be limited to things we want everywhere and/or which
 have technical benefit from being implemented in C.
 For pushing more stuff to userland some common guidelines make sense.
 But looking at that specific group and request doesn't seem good to me.

fig.php.net
phpfig.php.net
php-standards.php.net
php-conventions.php.net
frameworks.php.net
structure.php.net
security.php.net
coding.php.net

Where does it stop? And why does it even need a php.net subdomain? Is
this just an SEO thing?

phpfig.org, on their own (or a similar domain), should work.

-Ronabop

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

Re: [PHP-DEV] PHP governance question?

[Ronald Chmara]

On Fri, May 18, 2012 at 2:07 AM, lijiu zhang zhangli...@gmail.com wrote:
 Hi everyone:

 I am doing a study report about PHP, could anyone tell PHP governance? Such
 as, who is project manager, package manager, how php make a decision?  And
 finance support situation?

This is an interesting question. I hope you find answers you can explain.

I have had various contacts over 13+ years with the group, and have
not, ever, found a consistent, repeatable, structure, that did not
change massively over time. Sometimes, there is a vote, sometimes not,
sometimes, different votes count, sometimes, not. There is not
governance, so much as guidance.

If you have not read it, I would suggest you read The Cathedral and
The Bazaar, by Eric S. Raymond, to get more exposure to the model,
and mindset, of decentralized control. There are *many* project
managers, *many* package maintainers, and *many* people who make
decisions.

People who have consistently been helpful to the project are listened
to more often, as are people who have made larger contributions than
others. They lead, but not everybody follows. Sometimes the person who
wins is the person with the best ideas, regardless of any existing
power structures. Sometimes, however, it is a person nobody knows, who
just implements a feature, and is never heard from ever again.

In short, there is no central committee, no central governance, no
central cabal. Long term leaders get listened to more than others, but
not because they are better people: It is because they have proven
themselves though work, vision, and their guidance.

If you want to know who is in charge of a specific project, or
specific issue, that can be an easier question to answer, but within a
decade, that answer will be completely different than it was 10 years
ago.

-Ronabop

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

Re: [PHP-DEV] Re voting

[Ronald Chmara]

On Mon, Apr 16, 2012 at 8:42 PM,  sle...@pipeline.com wrote:
 Stas:

 Just b/c there are rarely any women at all that participate on this list, 
 could we at list maintain a facade of gender neutrality?

One of my favorite PHP dev folks is Sara Golemon. A fucking rock star.
Female, I believe. I think she might be into women, but I don't really
know, or care, because we honor *code*, not biological plumbing.

Point being that PHP is not a sex or gender hostile community.

-Bop

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

Re: [PHP-DEV] Mailing list page refers to www.ezmlm.org

[Ronald Chmara]

On Mon, Mar 26, 2012 at 7:10 PM, Adam Harvey ahar...@php.net wrote:
 On 27 March 2012 09:55, Yasuo Ohgaki yohg...@ohgaki.net wrote:
 http://www.php.net/mailing-lists.php

 At the bottom of this  page,  http://www.ezmlm.org/ is refereed.
 However, it seems this domain is dead.

 It looks like the domain has expired. Along with probably ten thousand
 other people, I'll ping djb (off-list). The manual doesn't seem very
 widely mirrored, unfortunately, so it's hard to know what to link to
 as a stopgap.

 BTW, I was looking for ezmlm command to subscribe pull-request list.
 Is there any good page for this?

 As I said above, I couldn't find one at a quick search, but to
 subscribe you should e-mail git-pulls-subscr...@lists.php.net and
 you'll get an e-mail back with instructions.

According to the wikipedia entry:
http://en.wikipedia.org/wiki/Ezmlm
the exmlm page is:
http://cr.yp.to/ezmlm.html
...but note that said page also references the borken domain.

-Ronabop

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

Re: [PHP-DEV] PHP Philosophy (was RE: [PHP-DEV] Scalar type hinting)

[Ronald Chmara]

On Thu, Mar 1, 2012 at 4:18 PM, John Crenshaw johncrens...@priacta.com wrote:
 No, you've misunderstood. The average new not-really-a-developer has no 
 concept of security. Every SQL query they write is vulnerable to injection. 
 Every echo exposes their site to XSS vulnerabilities. Every form is 
 vulnerable to CSRF. If they did anything with files in their script I may be 
 able to read arbitrary files to their server and/or upload and execute 
 arbitrary scripts. If they used eval() or system() I can probably execute 
 arbitrary shell code and take control of the entire site. If their server is 
 badly configured I could capture the entire machine.


PHP is as vulnerable as you make it,

 This isn't a question of keeping software updated and not using deprecated 
 functions, this is a question of discipline that is completely missing among 
 the unwashed masses as you call them. The intuitive way to handle many of 
 the most common PHP tasks is also the completely insecure way. 
 Philosophically, I wonder if we do a great disservice by encouraging these 
 people to tinker with code at all. We do so knowing (or at least we should 
 know) that anything they create will inevitably be hacked. We fuel the 
 widespread security problems that currently plague the web.

 John Crenshaw
 Priacta, Inc.

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

Re: [PHP-DEV] HEADS UP: 5.4 branch is open again

[Ronald Chmara]

On Fri, Mar 2, 2012 at 11:05 AM, Pierre Joye pierre@gmail.com wrote:
 that's totally off topic... but we have no idea yet when will be php
 6, or whatsoever.
 However next is in around a year :)

PHPME, PHPXP, PHP Feisty Foxbat, PHP#

Let's name this bike shed*!

-Ronabop

*http://en.wikipedia.org/wiki/Parkinson's_Law_of_Triviality

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

Re: [PHP-DEV] $_PARAMETERS Super Global Object

[Ronald Chmara]

On Fri, Feb 24, 2012 at 2:40 PM, Larry Garfield la...@garfieldtech.com wrote:
 To me, it's just a request for some content, and in a REST API that's
 read-only, I just don't care if the consumer sends their request as
 GET or POST.  I'll cheerfully give them what they wanted.
 Except that per HTTP, GET and POST are completely different operations.  One
 is idempotent and cacheable, the other is not idempotent and not cacheable.
  I very much care which someone is using.

People exploiting security would *never* think of
caching/replaying/modifying  a POST request, that's just totally
unimaginable! It would take, like HUGE computational effort to like,
cURL it or just type it out!

er, no.

-Ronabop

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

Re: [PHP-DEV] $_PARAMETERS Super Global Object

[Ronald Chmara]

On Fri, Feb 24, 2012 at 2:54 PM, Larry Garfield la...@garfieldtech.com wrote:
 On 2/24/12 4:48 PM, Ronald Chmara wrote:

 On Fri, Feb 24, 2012 at 2:40 PM, Larry Garfieldla...@garfieldtech.com
 Except that per HTTP, GET and POST are completely different operations.
  One
 is idempotent and cacheable, the other is not idempotent and not
 cacheable.
  I very much care which someone is using.
 People exploiting security would *never* think of
 caching/replaying/modifying  a POST request, that's just totally
 unimaginable! It would take, like HUGE computational effort to like,
 cURL it or just type it out!
 er, no.
 Please point out where I said that POST not a security risk.  I am quite
 sure I typed no such thing, so how you read such a thing I do not know.  I
 am genuinely curious to see how you managed to interpret anything I said as
 POST is secure because it won't be cached.

Well, I didn't actually say that you said any such thing. I picked up on:
the other is not idempotent and not cacheable
...which is obviously false, and I highlighted, in a security context,
how POSTs are cached, and should be treated with equal distrust as
GET, because both are suspect, user submitted, forms of data, subject
to exploiting.

-Ronabop

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

Re: [PHP-DEV] Wrong/outdated usernames in SVNROOT/global_avail

[Ronald Chmara]

On Sat, Nov 12, 2011 at 1:31 PM, Ferenc Kovacs tyr...@gmail.com wrote:
 On Sat, Nov 12, 2011 at 1:56 AM, Florian Anderiasch m...@anderiasch.dewrote:

 Hey there,
 I just noticed some inconsistencies in svn usernames used in
 SVNROOT/global_avail.

 After some shell magic involving sed,grep and diff these names don't match
 the 1607 people on master, as of a few minutes ago.

 Some are typos I think (sascha - sas, pierre - pajoye, ilia - iliaa),
 others I haven't checked.

Snip_

  ronabob

 that should be ronabop imo

LOL, yeah, that's a typo.

-Ronabop

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

Re: [PHP-DEV] who can vote

[Ronald Chmara]

On Thu, Nov 10, 2011 at 8:09 AM, Anthony Ferrara ircmax...@gmail.com wrote:
 However, and it is what we approved, OSS project leads have a voice,
 today and here. And they are not random people, they know sometimes
 much better than us what should be added to the core (be language, or
 functions in an extension like spl).
 Well, I would like to make a point here.  Right now, and the
 discussion here is that people who contribute to the core and OSS
 project leads get a say in the language.  What would happen if Google
 chose to use PHP instead of Python.  Would they get a voice?  Should
 they get a voice? (even if it's just a single vote)...?  What about
 professional lead/senior developers who use and develop large and high
 traffic sites off the language?  What about the sysadmins and/or OS
 package maintainers who implement and maintain the language for mass
 adoption?  What about the individual hosts that contribute so much to
 the traction and adoption of PHP as a whole?  Do any of them get a
 say?

All of these people do have a voice, and some weight, what they do not
have is *equal* weight, or an *equal* vote (if any vote at all).

Once a php contributor has become familiar with the different players,
and who, and what, they represent, they can selectively evaluate
individual arguments based on their weight. Without naming (outing?)
specific user names, I can say that no less than three of the top ten
websites (on the planet) have voices, and representation, in the
various arguments and discussions here. The largest install bases of
the most popular PHP applications also carry weight here. Same with
frameworks, cross-compilers, etc.

There is also the weight, and arguments, of users who have hundreds,
or even just one (with low traffic), website/project based on php...
but their arguments are often far outweighed by the arguments of those
who represent the needs of thousands, or millions, of websites and
users.

-Ronabop

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

Re: [PHP-DEV] who can vote

[Ronald Chmara]

On Wed, Nov 9, 2011 at 12:07 AM, Ferenc Kovacs tyr...@gmail.com wrote:
 Hi.

 As it was brought up recently that who can vote, and how are the community
 representatives granted with voting rights, I created an RFC draft for
 defining that-
 Please feel free to discuss and extend it.
 https://wiki.php.net/rfc/voting_who

3 BAD ideas:
1. If you haven't contributed into src in 5 years, you must be NEW.
2. If you want PHP to work like the other language you like more
3. My ego is involved, because I matter, and I am important!.

GOOD ideas are harder to come by than self important people which
seem to multiply in abundance.

Something I learned early, from Rasmus, and Zeev, and Andrei (any many
others), is that PHP is not a right, correct, or accurate coding
language.  It's glue. Glue between HTML and C.  That's it.

We can lay lots of layers on top, but that's icing.

-Ronabop

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

Re: [PHP-DEV] Migrating from Subversion to Git

[Ronald Chmara]

On Tue, Sep 13, 2011 at 6:47 AM, Alexander Kitaev kit...@gmail.com wrote:
 Hello David,
 Snip_
 You may download SubGit at http://subgit.com/ and contact us at
 supp...@subgit.com if you have further questions.
 Thanks!

SubGit is a closed source software. You may use this version of it for free.

From:
http://subgit.com/download/index.html

-Ronabop

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

Re: [PHP-DEV] PHP 5.3.8 Released!

[Ronald Chmara]

On Wed, Aug 24, 2011 at 6:51 PM, a...@akbkhome.com a...@akbkhome.com wrote:
 BTW. we could really do with a searchable archive of php.dev + internals...
 - It's pretty difficult to find out if this was ever discussed before..

http://marc.info/?l=php-internals

marc has a ton of the PHP lists. (Is this not what you are looking for?)

-Ronabop

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

Re: [PHP-DEV] [RFC] Choosing a distributed version control system for PHP (or not). Call for Participation.

[Ronald Chmara]

On Mon, Aug 8, 2011 at 6:52 PM, Larry Garfield la...@garfieldtech.com wrote:
 A previous poster claimed that a DVCS would lead to confusion as to what the
 canonical repository was.  That is, in my experience, a common fear of
 someone who has not used a DVCS in production.

Disclaimer: I haven't committed to PHP in years, but since my last
commit, I have worked with a lot of DVCS systems.

The whole *point* of DVCS (IMNSHO) is that the concept of canonical
repository is part of the *problem*, not part of the *solution*.

Here's a pretty good talk by some random guy (1:10:15 worth) on the
topic about juggling lots of code sources, and canonical
authorities, and conflicting trees:
http://www.youtube.com/watch?v=4XpnKHJAok8

(Apologies if this has already been posted upthread)

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

Re: [PHP-DEV] Fwd: What's up with Quercus?

[Ronald Chmara]

On Sun, May 29, 2011 at 3:32 AM, Ferenc Kovacs i...@tyrael.hu wrote:
 On Sun, May 29, 2011 at 4:31 AM, Stas Malyshev smalys...@sugarcrm.comwrote:
 Maybe having experience with Java is exactly the reason why some people are
 reluctant to make PHP more like Java... Just saying ;)
 then those would have informed objections, don't you think?

They have very informed positions about why PHP is a lousy hammer.

It is.

By design.

Intentionally.

Many projects might require a screwdriver, or a spanner/wrench, some
duct tape, maybe some glue, some wood putty, a glue gun, a cutting
torch, etc. That is the heart of PHP.

Put another way, Java was designed by engineers, who know how to make
a damn solid building.

PHP was put together by people who know how to make a building
actually function... regardless of the original design presented.

-Ronabop

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

Re: [PHP-DEV] 答复: [PHP-DEV] full LFS support

[Ronald Chmara]

$code  $complaints;

On Tue, Aug 3, 2010 at 6:01 AM, Ferenc Kovacs i...@tyrael.hu wrote:
 Maybe this is just lost in the weekend's email swarm.
 At least I hope this is the reason for the silence.

 Tyrael

 On Tue, Aug 3, 2010 at 2:11 PM, 高春辉 gaochun...@gmail.com wrote:
 nobody to care this change? :(

 -邮件原件-
 发件人: tyr...@gmail.com [mailto:tyr...@gmail.com] 代表 Ferenc Kovacs
 发送时间: 2010年7月30日 22:14
 收件人: PHP Internals
 主题: [PHP-DEV] full LFS support

 Hi.

 I would like to know what is the current status of the LFS support for php.

 http://bugs.php.net/bug.php?id=27792
 http://bugs.php.net/bug.php?id=48886

 As far as I can see, there are some patches floating around, but some of 
 them doesn't work, some of them are incomplete.

 As far as I can see, with the latest release(5.3.3) you can't stat or 
 filesize a file where the size is = 2GiB on 32bit OS, and = 4GiB on 64bit.
 Is this true?
 From the proposed patches, it seems that there arent that many LOC which 
 needs to be adjusted to provide a decent LFS support.
 Are there any blocker objections or architectural problems, or we just lack 
 specification or manpower to fix this issue?
 If this gets fixed, will this be included into the 5.3 branch, or this can 
 only be added with the next major version?

 Tyrael


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



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

Re: [PHP-DEV] 答复: [PHP-DEV] full LFS support

[Ronald Chmara]

Sorry:
$code  $complaints;

2010/8/4 Ronald Chmara rona...@gmail.com:
 $code  $complaints;

 On Tue, Aug 3, 2010 at 6:01 AM, Ferenc Kovacs i...@tyrael.hu wrote:
 Maybe this is just lost in the weekend's email swarm.
 At least I hope this is the reason for the silence.

 Tyrael

 On Tue, Aug 3, 2010 at 2:11 PM, 高春辉 gaochun...@gmail.com wrote:
 nobody to care this change? :(

 -邮件原件-
 发件人: tyr...@gmail.com [mailto:tyr...@gmail.com] 代表 Ferenc Kovacs
 发送时间: 2010年7月30日 22:14
 收件人: PHP Internals
 主题: [PHP-DEV] full LFS support

 Hi.

 I would like to know what is the current status of the LFS support for php.

 http://bugs.php.net/bug.php?id=27792
 http://bugs.php.net/bug.php?id=48886

 As far as I can see, there are some patches floating around, but some of 
 them doesn't work, some of them are incomplete.

 As far as I can see, with the latest release(5.3.3) you can't stat or 
 filesize a file where the size is = 2GiB on 32bit OS, and = 4GiB on 64bit.
 Is this true?
 From the proposed patches, it seems that there arent that many LOC which 
 needs to be adjusted to provide a decent LFS support.
 Are there any blocker objections or architectural problems, or we just lack 
 specification or manpower to fix this issue?
 If this gets fixed, will this be included into the 5.3 branch, or this can 
 only be added with the next major version?

 Tyrael


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




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

Re: [PHP-DEV] PHP 6

[Ronald Chmara]

On Fri, Mar 12, 2010 at 2:04 AM, Pierre Joye pierre@gmail.com wrote:
 hi,

 On Thu, Mar 11, 2010 at 6:22 PM, Rasmus Lerdorf ras...@lerdorf.com wrote:
 Ah, Jani went a little crazy today in his typical style to force a
 decision.  The real decision is not whether to have a version 5.4 or
 not

Jani is passionate, and that's a good thing.

WRT a 5.4, we can stay on the 5.X tree forever.

Why not 5.194? Why not 5.196187?

If there's a 6.X tree, if there's a 6.X change, we need to have a 6
reason that is clear.

See the 4-5 transitions (along with mail logs, etc.) for background.

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

Re: [PHP-DEV] function call chaining

[Ronald Chmara]

Religious programming is the problem.

On Tue, Jan 19, 2010 at 6:28 PM, Gwynne Raskind gwy...@darkrainfall.org wrote:
 On Jan 19, 2010, at 5:54 PM, Alain Williams wrote:
 $eep-oop()-ork()-ah()-ah();

 the newcomer will have to spend significant time rummaging around the
 source code to figure out what classes are involved.
 As opposed to:
 $oop = $eep-oop();
 $ork = $oop-ork();
 $ah = $ork-ah();
 $ah2 = $ah-ah();

No amount of syntax change will alter the true believer, it just
creates new religions. New rituals, new syntax, new languages.

To that end, I suggest a trinity operator, three colons in a row...
ObjectIDont'Understand::methodIhaven'tread:::DoWhatIWant.

When it fails, the failing will be on the part of the invocator,
because the trinity is not bound by logic. Any bugs would question the
faith, which is infallible, by definition.

Backing up, maybe it's a bad idea to argue about compilers with
people who haven't written them.

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

Re: [PHP-DEV] Bug tracker cannot connect to database

[Ronald Chmara]

WORKSFORME

Details?

On Thu, Nov 19, 2009 at 11:38 PM, Edward Z. Yang ezy...@mit.edu wrote:
 I don't know if this is the right list to report to, but
 bugs.php.net is currently non-functional.

 Cheers,
 Edward

 --
 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: Re[2]: [PHP-DEV] Design of the Zend Engine's Instruction Set

[Ronald Chmara]

On Sun, Aug 16, 2009 at 10:40 PM, Lothar Scholz
sch...@scriptolutions.comwrote:

 If they are doing bad - yes i do. I have to say i give a fuck about
 volunteers - most of them should go to hell because most of them are
 worse to projects and they should/would go better without them and
 with a strict core team. If you base a project only on volunteers its
 just digital environment pollution - and you should be punished for
 putting it out.


Congratulations on destroying your career.

*nix was built by volunteers.

email was built by volunteers.

gopherspace was built by volunteers.

The web (http sites, which really took off) was built by volunteers.

..and you have just given the finger to everybody who built it.

Good luck!

Re: [PHP-DEV] [RFC] APC/PHP Lazy Loading

[Ronald Chmara]

On Feb 26, 2009, at 5:58 AM, Rodrigo Saboya wrote:
Ronald, I think you are overreacting a little bit. It may be that  
proper written could would get no benefit from this patch since it  
would not load unneeded code and this patch ends up speeding up  
environments where such correct loading isn't done. I don't think  
that's a reason to disqualify a feature that brings benefits with  
no significant drawbacks.


For the average PHP programmer, the language will simply get  
faster. That can't be bad in any way. It doesn't encourage you to  
write bad code, it just doesn't kick you in the nuts when you do.


Sold. (The best arguments are always the short ones).

As I said: I'm trying to raise a token flag of discussion/ 
resistance, but nobody in the discussion seems to have found any  
really important downsides, yet, with only me raising *any* sort of  
flag (though I admit it's not much of one).


:)

-Bop

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

Re: [PHP-DEV] Re: add scream feature to core

[Ronald Chmara]

On Feb 26, 2009, at 7:21 PM, Greg Beaver wrote:

Pierre Joye wrote:

Hi,
What's about adding what screan (http://pecl.php.net/scream) to the
standard PHP? Everyone needs it and it should be possible to do that
without having to install an extension.
Comments/objections?
If it can be done easily and unobtrusively to existing code, this  
would
be useful to me for those hard-to-catch bugs in old code.  Of  
course, I
am one of the people Ilia is referring to who can do a 3-4 second  
pecl

install pretty easily, so I don't have a strong stake in the debate
either way :)


I'd rather see this as part of E_ALL, or maybe E_NOSUPPRESS (or  
something that sounds better).


As far as the former, (E_ALL), I'd kind of actually hope that it gave  
me *ALL*, not just *ALL (...except suppressed errors)*. Actually,  
I've assumed it would.


That being said, I:
a) Don't mind typing a few lines to install something
b) Wonder why ALL would be a limited subset of errors, with @  
errors ignored.


-Bop


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

Re: [PHP-DEV] [RFC] APC/PHP Lazy Loading

[Ronald Chmara]

On Feb 21, 2009, at 10:55 PM, shire wrote:

Hi Ronald,
Ronald Chmara wrote:
Wait... so if I understand this right, let's envision a code base  
where,

per some random page load, 70 functions are actually called, but, oh,
7,000, or even 700,000, are being included for whatever reason?
The speed optimization is in *not* copying a massive amount of things
that weren't even needed, or used, in the first place?
Essentially, yes, this is probably best summed up by the 80/20 rule  
where we only use 20% of the code etc...


Well, I can see 80% actually *used* code, with 20% in there by  
accident  but 80% unused code? eep! ack! Call the villagers and  
get the torches and pitchforks!...


...but environments vary, of course. ;)

However, there's still the horribly massive speed hit of semi- 
loading,
and marking, a fairly large amount of unused, un-needed,  
functions, as

available?
I don't agree with the description of describing this as a  
horribly massive speed hit at least in comparison with what was  
happening without lazy loading.


Fair enough. Before the patch, for example, I might describe it (80%  
unused, 20% used code) as an insanely awful, horribly massive speed  
hit, and after the patch, as being reduced to a much lesser  
horribly massive speed hit, but these are just rhetorical, and  
qualitative, language devices that I used to characterize code issues.


In both cases, a large amount of CPU is spent on (effectively) doing  
nothing, but your patch (as I understand its design) reduces the  
amount of CPU waste... doing nothing.


 Also, like I said there's further iterations I plan to make here,  
one of these being increasing the performance of this marking  
functions as available.


One thing I see as quite a beneficial future outcome of your work is  
the ability to further profile code, and be able to seek out code  
that marks massive amounts of functions as available without  
actually ever using them.


I do see the benefit of lazy loading, I'm just not very  
comfortable with
enabling a philosophy of loading up a massive amount of CPU and  
RAM with

just in case they're wanted features and code in the first place.
Well I am assuming that this is what a large amount of code does  
already, except that without lazy loading the situation is  
significantly worse.


Different code bases and philosophies vary.

Since much of what I do (enterprise PHP tuning) involves (among many  
other things) finding, and eliminating, such code, I can say with  
great confidence that there certainly are bloat-bases out there that  
load metric hogs-heads of libraries to show a single web email form,  
but there are also code bases which do *not* rely on endless  
libraries, frameworks, additional template abstractions and end user  
libraries, or other pre-determined architectures... to complete the  
simple task of showing an web email form.


To frame the issue another way, you are trying to make huge,  
complicated, code sets less painful to use, and I am arguing that  
huge, complicated, code sets are a major part of the problem. but  
since neither of us can wave a magic wand and reduce the problem to  
simple, elegant, code sets, you're reducing the magnitude of pain  
involved. Kudos to you.


Your point that we should be sure this does not encourage poor  
coding practices is well taken, but it's been my experience that  
code tends to take this form regardless so I'm hoping to make the  
best of the situation ;-).


There will always be bad code, yes. ;-)

I'm trying to raise a token flag of discussion/resistance to making  
bad code practices less painful, as it still enables bad code practices.


Also keep in mind that there are cases where you may not know in  
advance which functions you will/will not call, but it's probably  
fair to say that the 80/20 rule still holds, so including all the  
functions you may need is not particularly a misuse of the  
language, but rather a necessity of a dynamic application and  
language.


It all depends on the use, and environment, I suppose.

It certainly can boost an APC code set such as facebook, where  
many of
those files and functions *will* likely be used in the next 20  
minutes

or so, but I also fear that it will encourage programmers to load
everything they have, every time, just in case they need it  
and 2Gb

apache processes (and APC space) can be ugly.
I'm not entirely clear on where code being used in the next 20  
minutes come into play, what differenc does 100 milliseconds vs. 20  
minutes make in APC/lazy loading?


FB seems to have a fair bit of traffic, with a semi-patrolled code  
set, so it's likely that any single APC-loaded function will be  
invoked *eventually*, within an hour or so.


Contrast this with 1,000 different sites hosted on a box, using a  
less patrolled, fairly unregulated, 1,000 different batches of PHP  
codesets, where myTotallyCustomDateTime() can have 1,000 different  
variants

Re: [PHP-DEV] [RFC] APC/PHP Lazy Loading

[Ronald Chmara]

On Feb 21, 2009, at 4:10 PM, shire wrote:
I've just checked into APC CVS preliminary support for Lazy Loading  
classes and functions.  This means that rather than copying  
function entries into EG(function_table) and EG(class_table) when  
an include happen it will mark the functions/classes as available  
and only actually insert them into the tables when they are called.


Wait... so if I understand this right, let's envision a code base  
where, per some random page load, 70 functions are actually called,  
but, oh, 7,000, or even 700,000, are being included for whatever reason?


The speed optimization is in *not* copying a massive amount of things  
that weren't even needed, or used, in the first place?


However, there's still the horribly massive speed hit of semi- 
loading, and marking, a fairly large amount of unused, un-needed,  
functions, as available?


While I do see, and understand, the performance benefit of such a  
coding direction, it's not exactly encouraging well designed code.


For example:
?php
include(mega-loader.php);
//which kicks off
-include(site-mega-loader.php);
//which kicks off
--include(sub-site-mega-loader.php);
//which kicks off
---include(sub-site-application-loader.php);
//which kicks off
include(sub-site-application-feature-loader.php);
//which kicks off
-include(sub-site-application-function-loader.php);
//which kicks off
--include(sub-site-application-function-loader-function.php);

//and the actual code which caused the load?
my_custom_site_application_echo( Hello World);

?

This does not make me happy as a coder.

I do see the benefit of lazy loading, I'm just not very comfortable  
with enabling a philosophy of loading up a massive amount of CPU and  
RAM with just in case they're wanted features and code in the first  
place.


It *should* hurt to load something.

Code should not be ever loaded unless needed.

It certainly can boost an APC code set such as facebook, where many  
of those files and functions *will* likely be used in the next 20  
minutes or so, but I also fear that it will encourage programmers to  
load everything they have, every time, just in case they need it  
and 2Gb apache processes (and APC space) can be ugly.


That being said, I think the idea is good, but the possible mis-uses  
are potentially tough issues.


-Bop

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

Re: [PHP-DEV] Typo in INI files

[Ronald Chmara]

On Jan 12, 2009, at 2:58 AM, Richard Quadling wrote:

2009/1/12 Antony Dovgal t...@daylessday.org:

On 12.01.2009 13:38, Richard Quadling wrote:

Can someone please commit these typo fixes.

Committed, thanks a lot.

Just standing on the shoulders ...


Welcome to the pyramid (we've gotten pretty tall, now). :)

-Bop

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

[PHP-DEV] Which list/group handles the PHP mirrors?

[Ronald Chmara]

The server that was http://lu2.php.net had some issues, that have 
hopefully been fixed now... what are the contact points for getting it 
back into the listed mirror pool?


-Bop

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

Re: [PHP-DEV] dns_get_record for OSX

[Ronald Chmara]

On Jan 7, 2009, at 1:44 AM, Pierre Joye wrote:

On a sidenote, I would suggest to take a look at  the djbdns library,
which is available on almost all platform and seems to be much cleaner
than bind(8|9): http://cr.yp.to/djbdns/dns.html


Technical issue: While available, it is not installed (by default) on  
as many platforms as the bind libraries.

Non-Technical issue: redacted

-Bop



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

Re: [PHP-DEV] An optimization idea

[Ronald Chmara]

On Nov 10, 2008, at 5:24 PM, shire wrote:


It sounds like this would only work if the array contents where  
static though, as you're mapping a constant string to the  
contents of the  hash (or did I misunderstand and you'd be  
mapping string const. values  to hash IDs?).

My point is, replacing this process:
$a['foo'] or $a-foo - compute hash of 'foo' - find item for  
hash 'foo' - many items? - resolve conflict - return item

With this process:
$a[% string_literal_id_5 %] - lookup item key 5 for array -  
return item
Notice we skipped hash generation, and conflict resolution  
altogether. We only have the lookup for the integer id.
If some additional work is done, even this lookup can be  
eliminated and make this an O(1) process.

If instead the coder used variable:
$a[$bar] or $a-$foo (var array lookup and var var object lookup),  
then this optimization can't kick in, and the existing algorithm  
will be used.
However static access is the predominant usage, especially for  
objects, but also for arrays, so this should have significant impact.


Thanks for the clarification, this is pretty much the same idea as  
what I've been interested in working on next.  I think I was more  
inclined to store an extra hash value within the zvals themselves,  
with the hope that this could be expanded to non-constant values.   
I believe ruby implements it's lookups this way (noted just for  
reference, not as an argument to copy another language ;-)  ).  Any  
thoughts on reasons not to do this (other than increasing the size  
of zval struct), it's pretty simple to implement this for static  
values I believe, dynamic values are a lot more difficult obviously...


Since nobody else has chimed in with the obvious (to me, anyways):

I've worked with some code that uses disgustingly huge (512Mb)  
arrays, largest implementation was a single 2.5 Gb array (before we  
took the offending programmer into a room and had a... chat).


I'd be interested in seeing some metrics on the needed extra CPU  
ticks for determining if an array (or array sub-element) is static or  
dynamic under the scheme, as well as the extra memory for storing an  
(many?) extra value(s). It sounds like it might be totally livable,  
if done right... done wrong, we could be looking at millions of CPU  
hits for checking millions of single element static arrays (and  
yes, storing millions of values as single element arrays is doing it  
wrong, but I've learned not to underestimate the creativity of  
people who write software).


Oh, and while we're at it, what about re-assigning static arrays?

The idea sounds good, the corner-cases on mis-implementations are  
where it always becomes amusing.


-Bop

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

Re: [PHP-DEV] Re: Case sensitivity

[Ronald Chmara]

On Nov 6, 2008, at 6:27 PM, Nate Abele wrote:


I was shocked and horrified that that ridiculous remove-the-$  
post actually turned into a legitimate discussion.  I mean, seriously?


No, not seriously.

It's an old internet joke, a shibboleth among programmers, not unlike  
GOTO considered harmful, or Real programmers Don't Use Pascal.


Sometimes the humor doesn't make it through the tubes (another  
shibboleth), other times users don't realize that their very subject/ 
idea is so absurd as to be laughable.


For example, I will now propose that for usability reasons:

1. All built-in PHP functions should be aliased in the worlds most  
used languages, so that declaring a function could also be written  
as: funktsioon, otstarve, λειτουργία , ویرایش,  
Fonction, funcionar, fungsi, funzionare, қызмет, 可 
算, メソッド, funkcja (etc.)


Can I get a +1?

While at first blush, it seems like a possibly interesting idea, upon  
closer examination, it turns into either laughter, or a deep sense of  
shame and admonition.


The trick is knowing when a joke is intentional, or not.

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

Re: [PHP-DEV] Restructuring the QA team

[Ronald Chmara]

On Oct 31, 2008, at 5:16 AM, Sebastian Bergmann wrote:


Hannes Magnusson schrieb:

Speaking of QA people, how about crediting those who are actually
working on QA and removing the names who haven't been around for  
years

(I don't even recognized most of those names)?


 How do you recommend measuring who deserves credit?


Who recommends (and how do they recommend) credit for PHP core?
Who recommends (and how do they recommend) credit for PHP extensions?
Who recommends (and how do they recommend) credit for PHP documentation?
Who recommends (and how do they recommend) credit for PHP notes?
Who recommends (and how do they recommend) credit for PHP QA?

One thing that does bother me about Hannes's suggestion is the  
implication that somebody who worked on PHP for 3 years is less  
important than somebody who worked on PHP for a year or so, but they  
did so *very recently*.


We all stand on the shoulders of others.

+1 on adding names.
-1 on removing names.

The PHP project has 2,000+ authors. Some are well known rockstars,  
others are virtually unknown.


-Bop

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

Re: [PHP-DEV] keeping traffic on this list manageable

[Ronald Chmara]

On Oct 31, 2008, at 12:43 PM, Stefan Walk wrote:

 There are cases where one user replied to
multiple mails in a short time without fighting, just explaining and
discussiong, and you don't want to block that - as well as it  
wouldn't stop
random people from suggesting dropping the $ from variables, making  
the
namespace separator configurable etc. IMO, it's the volume of  
people, not the

volume of messages, that is the main problem here.


As a semi-non-random person (though people who have become very  
active only in the last few years may not remember me at all), I'd  
like to put in my two cents, based on, oh, 8+ years of working with  
this list, and my 22+ years of dealing with various lists/groups  
(email goes back to 1961, FWIW, before I was born).


1. Having a fairly advanced MUA helps. If you don't know what an MUA  
(Mail User Agent) is, then you may not remember the days when it was  
easy to get 1,800-10,000 messages a day off of various lists. The way  
this message overload problem was typically solved was with message  
grouping, and mail rules. Don't want to read a thread? Delete whole  
threads, not messages. Don't think a user is contributing? Put them  
in the bit-bucket.


2. Random off-topic-ness happens. It cannot be dictated away,  
moderated away, or programmed away. Feel free to try, but some of the  
best minds in the world have worked on this issue for 47 (yes, 47)  
years. No silver bullets, I'm afraid.


3. The super-seekrit serious chat only about X lists (or CC:  
chains, or IRC meetings, or wiki pages, or whatever) already exist,  
and have always existed. If people knew about them, they wouldn't be  
seekrit, and away from the riff-raff of a publicly available  
mailing list. Most F/OSS projects have these back channels. They are  
not made available for public use because, well, they're not supposed  
to be.


4. If you are a developer of sufficient merit/need/value, you will  
likely be on both public lists for a project, and have access to the  
private back-channels for some things as well. This is just the way  
the system works. Sure, we could make official rules, and another  
shibboleth list/channel/chat/wiki, for a given piece of a project,  
and add another layer... but to what end? We already have a plethora  
of such channels, indeed, as a project grows, said channels create  
themselves out of necessity.


So, to summarize, here's an example chain:
-php-general
-php-dev
-redacted, PHP sub-project hidden/CC lists and chats
-redacted, PHP core current C contributors and debuggers
-NA Zeev (or who ever's) cell phone

These layers already exist.

The problem is not that we (as a community) lack these levels of  
discussion, the problem is that every so often, folks want to  
escalate to another level, or find that they've outgrown the level  
they're in, and complain about the 'Riff-Raff. If you contribute to  
higher levels, if you work on a feature that impacts others at a  
higher level, and want to also be a part of that smaller community,  
well. it already exists. It just doesn't always have a mailing  
list that *anybody* can join because they think they're important.


-Bop

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

Re: [PHP-DEV] keeping traffic on this list manageable

[Ronald Chmara]

On Nov 1, 2008, at 10:20 AM, Lukas Kahwe Smith wrote:


http://www.php.net/reST/php-src/README.MAILINGLIST_RULES

Maybe it needs to be cut down (or just provide the key points at  
the top) and automatically appended to all emails (including the  
welcome email) .


Crontab a monthly mailing of the list rules to all list subscribers?

+1 on appending a rules URL to all list traffic, -1 to appending  
rules to all email. ;)


-Bop

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

Re: [PHP-DEV] UltraSimple Namespace Solution

[Ronald Chmara]

On Oct 17, 2008, at 3:53 AM, Nathan Rixham wrote:


*A Simpler Solution*
Force userland / general naming conventions in PHP.

# namespaces are always lowercase
# functions are always lowercase
# classes are always CamelCaps with initial uppercase letter enforced

thus:
//this is always the function two in namespace one::step
one::step::two();
//this is always the method two of class step in namespace one
one::Step::two();

thoughts, opinions, reasons why it wouldn't work?


Assuming this is a real question:

1. PHP is heading towards broad i18n. How do you uppercase or  
lowercase written languages that don't have a concept of case?


2. PHP was designed for wide adoption, and the authors of libraries  
often used function and class cases that matched their library. So,  
PHP case smashes, to Handle the problem of pg_pconnect (all smashed),  
PG_pConnect (EXTENSION_argumentAction), Pg_Pconnect (first letter  
ucase), etc. etc. etc.
Right now this all works. Changing it would break, well, darned near  
*everything*.


3. The vast majority of user operating systems (and filesystems) out  
there do *NOT*, I repeat, do *NOT* all handle case in the same way, a  
sane way. Windows boxes are still lugging around DOS/VMS legacy with  
UPPERCAS.$1 files, Macs have their own breed of jollies as well, and  
anything that autoloads (such as namespace code) needs to handle all  
of these.


Assuming that this is A Modest Proposal:
1. It needs to be more over the top to be funny to a broad, multi- 
lingual, global, audience.


For example, you might have suggested that we add an include_instead 
() operator, so somebody who wants to use a function/method which is  
located in '/var/location1/file_class.inc', rather than the already  
loaded function/method in '/var/location2/file_functions.inc', can  
override an existing function/method, and for giggles, you might  
suggest that the operator have the power to override all internal  
functions, but just for local execution scope, spawning a new process/ 
thread for each invocation, so a blog post can have 30-80 thousand  
processes with different scopes to render a web page.


Okay, I'm shutting up now. :)

-Bop

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

Re: [PHP-DEV] Re: towards a 5.3 release

[Ronald Chmara]

On Sep 9, 2008, at 6:22 PM, Stanislav Malyshev wrote:

 if we cannot


We already have this serious flaw in our design. If we use new Foo 
(), and it's definition not included, it resolves differently  
(namely, to fatal error) than if we had included the definition.  
Also, with inheritance, if you include or define inherited classes  
in wrong order - i.e. child before parent - you may get problem too.
You'd say this can be changed by autoloading, moving classes  
around, etc. - but behavior you complain about can be changed  
easily too, you just insist there would be no possible case,  
however hard you try to make a mistake, to get different resolution.



make a performant solution in this case, we better have nothing.


I don't see how it's better to have nothing at all than a solution  
that works in 99% of cases - unless you try on purpose to write  
code that doesn't work. I also find it very strange that you and  
other people are so insistent on having no namespace solution at  
all. How that would help you? How that would make PHP better?


Let me advance an idea here, from somebody's who watched this issue  
for a bit, if I may.


The idea is as follows: By writing one's *own* namespace-autoloader- 
conceptual-framework (*cough*), there have been many, many, ideas  
over the years and many, many implementations. Usually, the correct  
one seems to be the one written by the developer arguing for their  
specific variant. This is somewhat to be expected, as a decent amount  
of ego often gets developers through the day.


At one time, this kind of cleverness often took the form of:
include($dynamic_location . $dynamic_filename);

Not too ugly... yet. Seems to make perfect sense. At first.

Lets add a few years, shall we?
foreach ($namespace as $dynamic_location = $dynamic_filename) {
   include($dynamic_location . $dynamic_filename);
}

Not too shabby so far... until $namespace becomes an array with, say,  
40 or 400 even 4000 entries, and somebody doesn't want to be  
hassled with all that upkeep, and just wants the computer to fix  
it. So they start getting clever. They start expecting the language  
to search through all 4000 locations (be they files or objects, or  
*whatever*, it really doesn't matter), looking for the right thing  
the developer wants. (I'd write meta-code for this, but my built-in  
insanity over-ride precludes me from doing so.)


Where namespaces, indeed, where dynamically loading code based on  
arguments has gone south for the last 40 years(!) is not because of  
stubbornness, or because all-we-needed-was-another-language, or all- 
we-needed-was-better-syntax-characters-in-a-language, but rather,  
because it's a really, really, hard problem to fix.


Conceptually, it's a really simple task to 'do what a programmer  
wants'. Computationally, it's hard.


Analogy:
A small child leaves toys strewn all over the floor.

A few solutions:
1) Leave the floor as is.
The child will want some easier way of finding things, because  
there's stuff all over the floor, and they're grabbing the wrong  
thing all the time. They'll try to do their own organization, and  
will fail, and succeed, in various ways.

If the child does not get what they want, the child pouts.

2) Place clearly colored buckets for specific kinds of toys about the  
floor.
Eventually, the child wants different things in different buckets,  
the same thing in multiple buckets, or things to only be in the blue  
bucket after taking a toy from the red bucket.

If this does not happen, the child pouts.

3) Hire a full time nanny to constantly re-arrange toys in bins, and  
buckets, and on shelves, to duplicate toys for them to be in multiple  
locations, to constantly change and modify the toys themselves  
depending on what the child has asked for.
When the child does not get what they want, because the nanny is  
slow, the child pouts.


Now, solution number 3 has sometimes worked for years, in *certain*  
languages, where the nanny can be front-loaded into a compile phase  
of some kind, so it's okay if 80 seconds are consumed by toy  
management, or the language can dynamically create an toy-stack-of- 
all-possible-combinations, according-to-rules, as a cost of severe  
RAM and toy-stack persistence, and solution number 2 has a heavy  
cost, and solution number 1 is where PHP is at in many ways.


...but the child will still pout.

The problem is not the toys, or how they are arranged, sorted,  
managed, or manipulated.


-Bop

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

Re: [PHP-DEV] Re: Closing mysql_pconnects.

[Ronald Chmara]

On Aug 29, 2008, at 7:58 PM, Robert Cummings wrote:


On Sat, 2008-08-30 at 04:40 +0200, Lupus Michaelis wrote:

Richard Quadling a écrit :

 Can someone point me to where or how PHP DOESN'T close persistent
connections


   Maybe because it is... persistent ?


He's probably trying to learn how to do the same. This is internals
after all and not php-general.


If you'd like to peruse the source, to implement a similar feature,  
one place to look is the web gui to CVS for the function:


http://cvs.php.net/viewvc.cgi/php-src/ext/mysql/php_mysql.c? 
revision=1.213.2.6.2.16.2.26view=markup


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

Re: [PHP-DEV] voting

[Ronald Chmara]

On Jan 13, 2008, at 5:58 PM, Stanislav Malyshev wrote:

Voting to achieve what?

Fair decisions in a simpler, effective and right manner (and not
discutable, ideally).


I do not consider fairness, whatever that could mean, having  
anything to do with technical decisions regarding PHP,


I vote that PHP should get a pony! Who's with me!

Voting is good in that it helps express the wills and desires *of  
those who vote*. Some of those opinions may be wrong, insane, or  
silly, but it provides a means to evaluate an opinion professed by a  
group, rather than as an individual.


IMSHO, for PHP, voting is an *informative*, not *conformative*, process.

Let's take two arguments, with different heritages, authors, and  
origins.


Suoshin patches.
mysql_session patches.

We could have 100% voted desire to make all of these HEAD, and still  
say No.


Voting expresses voter *will*, not outcome. For the former and  
latter, these are feature, not technical, requests.


neither I think counting votes is the process that allows to arrive  
to a decision best for PHP.


That's why votes influence, but do not determine, outcomes.


I personally know very little about some areas of PHP code,


It's a big club. We should get T-shirts.

and it make little sense that my vote would carry the same weight  
as opinion of the person that wrote and maintains the code. There's  
nothing in arithmetic majority of people that makes any decision  
better, more effective, more right and not disputable. Thousands of  
people can be wrong as easy as one person can be, and one person  
can be as right as a thousand.


True, that.

For those not versed in US-style democracy, the way we do it here is  
to elect (theoretically) somebody with a clue. Their one clue  
easily vote trumps thousands.


The thing is, is that, well, if Rasmus, Zeev, Andi, Wez, *whoever*  
has a big voice, stopped listening or went insane or *whatever*, we  
have to have a way of fixing such a case.


Also, vast majority of PHP users never read this list and would  
know nothing of any votes held or announced here, so representing  
that as a poll reflecting opinion of a millions-wide PHP community  
makes no sense whatsoever.


Agreed.

-Ronabop

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

Re: [PHP-DEV] Internals read-only

[Ronald Chmara]

On Dec 13, 2007, at 6:17 AM, rich gray wrote:

If this suggestion from Jani is supported then all I can say is WTF  
a bunch of prima donnas you internals/core devs are ... You don't  
want to listen to your users who are in most cases NOT technically  
ignorant and are in the trenches using your product and trying to  
make a living?


My php.net dev number is #181. I've been actively, and passively,  
involved with the project since 2000 or so, to the point where I'm  
listed in the manual credentials. My first PHP project was converting  
~14K files from PHP2/FI to PHP 3. So, I'd say that I've seen quite a  
bit of the PHP history, and I've actually invested quite a chunk of  
my life (and occasionally cash) into it.


I think what Jani is proposing is certainly worth consideration, to  
cut down on external flames, rantings, musings, etc. ...


... But that's kind of how we've *always* done things on this project  
(and it's apparently worked). Here's the normal workflow:


Some core dev, or some random end user, throws an idea out, and we  
debate.


We argue.

We create differing implementations

and then we argue and debate some more.

(To paraphrase an old joke, if there are two PHP developers in a  
room, there are at least 3 opinions.)


Differing voices are granted different weights, and the goal is that  
the *best* ideas win.


Over the years, the 10-50 core PHP folks have gotten familiar with  
the mindsets, strengths, and weaknesses of the (*many*) others in the  
overall project. Voices from outside are not nearly as understood,  
or as helpful, in advancing the debate, *until* they are understood  
on the same level.


From what I gather, Jani wants to improve the *quality* of debate,  
by reducing down the *quantity* of debate. That's simply the way Jani  
thinks, and is part of what he brings, as a strength, to the larger  
PHP team, in that he tries to focus on *high-relevance targets*. He's  
not being a prima donna, he actually doing his job, by trying to  
make sure that the signal to noise ratio is low, and thus, core dev  
is more efficient.


All that being said, I like Jani's idea to a certain extent. I  
think that folks like Tim Starling *should* be allowed a voice in the  
debates, as he's running a high-profile site, regardless of any  
personal CVS activity. OTOH, [EMAIL PROTECTED] may have a good point,  
but have no idea of the underlying issues, and thus, contribute zero  
intellectual content to the debate.


-Bop

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

Re: [PHP-DEV] RFC: Dropping Namespace

[Ronald Chmara]

On Dec 5, 2007, at 12:52 AM, Robert Lemke wrote:

Hi Derick,
I also agree with your arguments - beautifying class names is not  
reason enough for

introducing namespaces.
On 04.12.2007 at 23:16 Derick Rethans wrote:

4. What is wrong with simple prefixes in the first place? Both  
PEAR_*,
  Zend_*, ezc*, and ezp* are perfectly acceptable markers for  
different

  'namespaces'.  We could optionally create a registry on php.net for
  this to avoid conflicts.


While experimenting with namespaces to use with the next major  
version of

TYPO3, I realized that always using a full class name such as

   T3_MyPackage_MySubPackage_Controller_DefaultController

has many advantages. Autoloading becomes a lot easier and if the  
filename
equals the class name (ie. the full name, not only  
DefaultController.php)

you are never in doubt where a file belongs to or comes from.

Therefore we in the TYPO3 project currently tend to not using  
namespaces

even if PHP6 had support for them.



Wow, total Deja Vu.

http://www.phpbuilder.com/lists/php-documentation-list/2001071/0109.php

I, for one, would not enjoy typing out:
T3_MyPackage_MySubPackage_Controller_DefaultController any more  
often than I absolutely *had* to. And in a somewhat amusing sense,  
the register_global vs. local variable debates aren't that far  
off from register_class_as_global vs. local class  namespace  
debates


Maybe we could all just re-read the email archives from back then,  
and save ourselves a lot of arguing?


:)

-Bop

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

Re: [PHP-DEV] Garbage collector patch

[Ronald Chmara]

On Dec 3, 2007, at 1:01 PM, Andi Gutmans wrote:


Hi all,

Was hoping to send this off earlier but I was travelling for the past
week and had very limited email access.

As promised in the past few weeks we have spent a significant  
amount of

time in reviewing the garbage collector work and testing it in our
performance lab. Dmitry has been exchanging ideas and patches with  
David

Wang during this time. Suffice to say that as I've mentioned in the
past, memory management is an extremely sensitive piece of PHP,  
which is

why it was important for us to review this work in great depth before
committing it to the code base.

The updated patch still retains the same algorithm as David's original
implementation however the data structures have been changed in  
order to

work faster and use less memory.
...
Personally I think the decision should be either in or out. Adding  
this

as a compile option is not a good idea as it would create binary
compatibility issues and would be a pain for the community.
...
The stage is open for ideas/thoughts/suggestions


I'm really hesitant to even *mention* this idea, but

Could alternate memory management systems be made available via  
PECL add-ons, or, more to the point:
What is the *actual cost and complexity* involved in implementing  
(possibly many) different user-selectable memory management systems,  
and what other future benefits/drawbacks might we see by doing such a  
thing? (GC is big now, but what about memory pools per mod_auth user,  
or SHM/SEM pools, or tuning amounts of memory per function, etc...)


I will now apologize to everybody who I just made cry, scream, or  
damage their furniture, as I didn't mean to hurt you, just trying to  
stimulate ideas.


-Ronabop

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

Re: [PHP-DEV] Garbage collector patch

[Ronald Chmara]

On Dec 3, 2007, at 10:30 PM, Andi Gutmans wrote:

-Original Message-
From: Ronald Chmara [mailto:[EMAIL PROTECTED]
What is the *actual cost and complexity* involved in implementing
(possibly many) different user-selectable memory management systems,
and what other future benefits/drawbacks might we see by doing such a
thing? (GC is big now, but what about memory pools per mod_auth user,
or SHM/SEM pools, or tuning amounts of memory per function, etc...)

I will now apologize to everybody who I just made cry, scream, or
damage their furniture, as I didn't mean to hurt you, just trying to
stimulate ideas.


Hi Ronald,

PHP 5.2.x already supports the ability to hook in different page
managers. In PHP 5.3 you can also override the memory allocation
functions. However, this would not include garbage collection like
algorithms which actually require changes in the core PHP data type  
such

as zvals. In fact the garbage collection adds memory to the basic
datatypes which is why I suggested to either always make these  
changes,

or don't make them so that we retain binary compatibility across all
builds of PHP.
So overriding basic memory allocation functions, yes, ability to  
provide

various GC implementations, no.


Okay, so, without this patch, I can allocate mem, and destroy it, on  
a per page level, but not on a zval level, and the choice is:
a) zval (etc.) destruction with this patch, which has a 5% speed hit  
at times (varies per test)

b) no patch, no change
c) something which hasn't been thought of yet?

I'd have to (sadly) ask that anything that slows down PHP by 5%, to  
improve performance for programmers that, uhm, leak or otherwise  
gobble RAM, that they, uhm, refactor their code as professional  
programmers.


Thanks for clearing it up for me, Andi.

-Bop

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

Re: [PHP-DEV] CODING_STANDARDS

[Ronald Chmara]

On Dec 3, 2003, at 1:01 PM, Jani Taskinen wrote:
On Wed, 3 Dec 2003, Edin Kadribasic wrote:
On Wednesday, Dec 3, 2003, at 10:12 Europe/Copenhagen, Derick Rethans
wrote:
derick		Wed Dec  3 04:12:39 2003 EDT

  Modified files:
/php-srcCODING_STANDARDS
  Log:
  - I am sure I reverted this before
No you didn't. Care to elaborate on this change?
What I understood from quickly reading all posts,
this was just a removal of requirement to use suckCaps ?
So anyone is free to do either..why is this a problem?
I just want to scream ENOUGH.

There is religion, and there is constancy. Religion fights for it own 
way, in spite of all prior beliefs.

These threads keep getting religious. If someone prefers to use 
underscores, or StudlyCaps, it does not deny god, it does not mean the 
downfall of civilization, it does not mean millions of coder hours are 
obsolete. It will not make the human race extinct.

If it means OO programmers are too inflexible, to rigid, too clueless, 
to use other conventions, so be it. If the latest fad was 
Studly_Underscored_Caps, and coding language X required or preferred 
it, so what? Python freaks out over whitespace, so why should PHP freak 
out over caps?  Alias the damn code. Create a standard where 
super_function_foo and SuperFunctionFoo must both work. It's not a lot 
of extra lines. If StudlyCapsCoding dominates later, we can shift to 
that.

This isn't rocket surgery! :-)

-Bop

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

Re: [PHP-DEV] No disk space on snaps.php.net during win32 compile

[Ronald Chmara]

On Nov 18, 2003, at 4:29 AM, Edin Kadribasic wrote:
Fixed, thanks for noticing.
Edin
On Tuesday, Nov 18, 2003, at 10:12 Europe/Copenhagen, Uwe Schindler 
wrote:
Looking into the win32 snapshot logs: A lot of errors during compile 
because of no disk space.
Uwe

There are scripts to warn of such things (lack of space). I suggest 
that they be implemented, if feasible, or, if not, a call go out to the 
community to ask for more disk.

Disk is cheap.

-Bop

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

Re: [PHP-DEV] function registration patch

[Ronald Chmara]

On Tuesday, March 18, 2003, at 03:07  PM, Sterling Hughes wrote:
PS: or, *gasp* drop case-sensitivity.  For which I'm an enormous +1. :)
Aw, and steal enormous hours from consultants like me who make mad 
dollars from running grep -i misbehaving function?

How cruel.

:-)

-Bop

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