Re: [PHP-DEV] [RFC] Preloading

[Florian Anderiasch]

On Fri, Oct 19, 2018 at 10:17 AM, Dmitry Stogov 
wrote:
> Hi Internals,
> 
> 
> I would like to start discussion on a Preloadng RFC 
> https://wiki.php.net/rfc/preload
> 

This sounds great, but something about the last paragraph:

> And also, this approach will not be compatible with servers that host
multiple applications, or multiple versions of applications - that
would have different implementations for certain classes with the same
name - if such classes are preloaded from the codebase of one app, it
will conflict with loading the different class implementation from the
other app(s). 

Please excuse my lack of knowledge about the opcache internals, but
can't this be remedied by some kind of namespacing? I don't know how
the lookup rules are, but I assume it's by file path - so if you're
preloading and serving preloading bundles, shouldn't this (at least as
a PoC) work with a random prefix, or even the app entry point?

This whole thing is basically tailored to people running their
own applications on their own stack - but if this restriction was
lifted this could be handy for shared hosting or even for people with
multiple application (stacks) on the same webserver.

Yes, I'm sure it's not that simple, but I don't really grasp why this
is different than the current opcache lookup rules.

Greetings,
Florian


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

Re: [PHP-DEV] net_get_interfaces()

[Florian Anderiasch]

On 27.11.2017 17:56, Sara Golemon wrote:
> On Mon, Nov 27, 2017 at 11:38 AM, Florian Anderiasch  
> wrote:
>> Somehow it doesn't match the
>> +#if HAVE_NET_IF_H
>> in net.c
>>
>> I had to unconditionally include it (for testing), otherwise
>> IFF_BROADCAST and IFF_POINTOPOINT are undefined. (they are in
>> sys/net/if.h on OpenBSD, but I only tested 6.2).
>>
> Can you send or gist your config.log?  (Optionally redacted to the
> net/if.h check if you want to do that yourself)
> 
> Are you saying you simply removed the `#if HAVE_NET_IF_H` check?  Or
> that you did that *AND* changed the include directive to `#include
> ` ?
> 
>> Can do a proper bug report if needed, but maybe I get around to test
>> NetBSD as well.
>>
> Thanks!
> 

Filed as https://bugs.php.net/bug.php?id=75582 - let's move the
discussion over there, sorry for the noise.

Greetings,
Florian

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

Re: [PHP-DEV] net_get_interfaces()

[Florian Anderiasch]

On 27.11.2017 16:38, Sara Golemon wrote:
> On Mon, Nov 27, 2017 at 10:34 AM, Florian Anderiasch  
> wrote:
>> Also I'm really sorry that I disappointed you by not managing to finish
>> testing on OpenBSD (which I actually started just before seeing this
>> mail) and I already sent some results for FreeBSD yesterday, which
>> showed a tiny issue.
>>
> Yes! I saw that! Thank you.  It wasn't so much a BSD issue as the fact
> you did a bare build, while my default build happens to include the
> sockets extension (which provides the AF_INET constant I was using in
> the unit test).  Thanks to your testing, I was able to refactor the
> test slightly to not require ext/sockets be enabled in order to work.
> :D
> 
> -Sara
> 

No worries, nothing in that was directed at you, Sara.
(But not sure if having to enable sockets proves my point or not, I
guess it did provide at least some value).

Good news: master after the merge works on OpenBSD, once the build is
fixed.

Somehow it doesn't match the
+#if HAVE_NET_IF_H
in net.c

I had to unconditionally include it (for testing), otherwise
IFF_BROADCAST and IFF_POINTOPOINT are undefined. (they are in
sys/net/if.h on OpenBSD, but I only tested 6.2).

Can do a proper bug report if needed, but maybe I get around to test
NetBSD as well.

Greetings,
Florian

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

Re: [PHP-DEV] net_get_interfaces()

[Florian Anderiasch]

On 27.11.2017 12:15, Dan Ackroyd wrote:
> On 26 November 2017 at 16:28, Florian Anderiasch  wrote:
> 
>> if this simply doesn't work on some OSes for
>> no good reason.. that's a pretty leaky abstraction.
> 
> Cool. Does that mean that we can drop support for 32bit builds if
> leaky abstractions are an important thing?

If someone commits something that only works on 64bit and wasn't tested
a single time on a 32 bit machine - yes.

>> Looks good in theory, but without a lot of thought, how likely is this
>> to break/work on "supported" operating systems?
> 
> It's likely to work on platforms that have the C functions
> implemented. Which is the level of guarantee that PHP aims for; "If
> the platform implements a feature, PHP will expose it, but won't
> always go out of its way to work around missing features".

Yes, I wrote that it's likely. Maybe I just didn't make myself clear
enough that I see a *slight* difference between something that's
relatively nicely encapsulated in the language itself versus something
that not only depends on some C headers, but maybe the whole network
stack of the OS.

>> just because there's one year of time and "we have no CI for that" is
>> not a good excuse in my book.
> 
> If this is important to you, please step up and do something about it.
> 
> If it is only of just enough importance to you that you send an email
> to this list, asking other people to do a shedload of work to satisfy
> your vague feelings, then as Sara said, committing it now gives people
> a whole year to find issues with it, and then we can take action
> against known issues, rather than worrying about unknown unknowns.

I didn't ask anybody to to any work. I saw this as a call for comments,
and Sara kind of addressed my *concerns* where I said I *think* this
*might* break.

Also I'm really sorry that I disappointed you by not managing to finish
testing on OpenBSD (which I actually started just before seeing this
mail) and I already sent some results for FreeBSD yesterday, which
showed a tiny issue.

Insert friendly suggestion to not throw stones when lingering near
breakable structures.

Greetings,
Florian

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

Re: [PHP-DEV] net_get_interfaces()

[Florian Anderiasch]

On 26.11.2017 17:10, Sara Golemon wrote:
> On Sun, Nov 26, 2017 at 10:53 AM, Florian Anderiasch  
> wrote:
>> Looks good in theory, but without a lot of thought, how likely is this
>> to break/work on "supported" operating systems? (Which ones are that,
>> actually? http://php.net/manual/en/install.unix.php lists the BSDs and
>> Solaris and HP/UX)
>>
>> I know, it explicitly mentions Windows and Linux - also probably someone
>> tried it on OSX, and I don't think (Free|Open|Net)BSD will be a big
>> problem here, but as I'm no expert on that - does that matter? Will it
>> need "just a little work" or could the more exotic ones be more problematic?
>>
> Without a comprehensive CI matrix to run diffs like this against,
> there's no way to be absolutely certain it'll work everywhere.
> 
> That said, the config.m4 changes specifically test for the new APIs
> being used.  If they fail to compile in a standalone environment, the
> new function isn't enabled for compilation in the main build.  So, at
> worst, we may find some OSs (AIX, Solaris, etc...) simply don't gain
> the new functionality, but it shouldn't {knock on wood} cause any
> builds to break.  If it does, we have an entire year for interested
> parties to catch it.

Yeah, I know, and I'd agree on the "absolutely certain" part - but as
this is not an extension, I have somewhat of an uneasy feeling to even
merge this without some at least rudimentary testing on "all" OSes. I am
confident it would probably work on most and can be fixed on the others
- but I see that as a TODO during the PR phase.

Speaking from a user PoV - if this simply doesn't work on some OSes for
no good reason.. that's a pretty leaky abstraction. If it's in the PHP
core, I'd assume it will work. Also I wouldn't count on it getting done,
just because there's one year of time and "we have no CI for that" is
not a good excuse in my book.

Don't get me wrong, this sounds like a useful feature - but (and my wild
guessing could be inaccurate) I think it's low-level enough that the
differences might matter.

Greetings,
Florian

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

Re: [PHP-DEV] net_get_interfaces()

[Florian Anderiasch]

On 23.11.2017 23:46, Sara Golemon wrote:
> Planning to add net_get_interfaces()
> https://github.com/php/php-src/pull/2935/files for enumerating the
> adapters on a system and their configured addresses.
> Based on a combination of my own implementation and finding out
> krakjoe and ab@ had a stalled version already.
> 
> If anyone wants an RFC I'll write one up, but this is pretty small so
> mostly just offering for a look before I push.
> 
> -Sara
> 
> Ref: https://bugs.php.net/bug.php?id=17400
> Ref: https://github.com/php/php-src/compare/master...weltling:17400
> 

Looks good in theory, but without a lot of thought, how likely is this
to break/work on "supported" operating systems? (Which ones are that,
actually? http://php.net/manual/en/install.unix.php lists the BSDs and
Solaris and HP/UX)

I know, it explicitly mentions Windows and Linux - also probably someone
tried it on OSX, and I don't think (Free|Open|Net)BSD will be a big
problem here, but as I'm no expert on that - does that matter? Will it
need "just a little work" or could the more exotic ones be more problematic?

Greetings,
Florian

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

Re: [PHP-DEV] PHP's mail servers suck

[Florian Anderiasch]

On 26.10.2017 09:23, Alexander Lisachenko wrote:
> Organizing internals in this way could give a chance for community to grow,
> because everyone knows how to raise an issue on GitHub and how to
> contribute to the documentation/RFC.
> 
> GitHub also provides flexible way to subscribe to repo/issues/summons.
> Maybe it's a good time to move internals to the public open-source system?

Mailing lists in general are fine, the problem at hand really is the
php.net mail infrastructure, so I'd suggest sticking to solving that
problem.

If you want to abandon email as an official discussion medium for this
project, please write up a RFC - https://wiki.php.net/rfc

Greetings,
Florian

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

Re: [PHP-DEV] php.net mailing setup owner?

[Florian Anderiasch]

On 04.12.2016 10:41, Sascha Schumann wrote:
> Ecelerity has been retired for close to two years (Feb 2015).
> 
> The MX for php.net is a single, well-maintained Postfix instance.
> 
> If there are any issues, please let me know and Cc systems@
> 
> Thanks
> Sascha
> 

Added it to the wiki now with all the info provided / easily found out:

https://wiki.php.net/systems/php-smtp2

~Florian

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

Re: [PHP-DEV] [RFC] Replace "Missing argument" warning with "Too few arguments" exception

[Florian Anderiasch]

On 06/01/2016 12:55 PM, Dmitry Stogov wrote:
> hi,
> Please take a look into the proposal.
> 
> https://wiki.php.net/rfc/too_few_args

My first thought went into how people use func_get_args() as this is (in
a sense) the opposite thereof.

That said I couldn't think of a good reason to disagree, but maybe
someone has a valid example where this change would have unforeseen
consequences.

~Florian

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

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

[Florian Anderiasch]

On 22.01.2016 15:29, Pierre Joye wrote:
> 
> Freshly adopted:
> 
> http://rubyonrails.org/conduct/
> https://golang.org/conduct
> 

Ruby (the language) is discussing the adoption of a Code of Conduct
right now, and several people in that thread issue what I think are
similar concerns about the wording in the covenant one:

https://bugs.ruby-lang.org/issues/12004

AFAICT Rails adopted exactly that one, not sure about slight changes.

FWIW, I like the Go one a lot better.


~Florian

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

Re: [PHP-DEV] PHP 7.0.0 final RTM delay

[Florian Anderiasch]

On 06.12.2015 09:46, Christian Stocker wrote:
>
> On 04.12.15 23:17, Andrea Faulds wrote:
>> Hi Florian,
>>
>> I think it's worth pointing out that for OS X, Apple themselves
>> distribute PHP, and in addition there's decent community package
>> managers (Homebrew's the one I like), and it's easy to build yourself.

> I'm fine with having that outside of PHP.net and concentrating the
> efforts of the PHP community on the source releases (and Windows ;))

Hi,
I was in no way trying to encourage any change for anyone that's not
intended ;)
My experiences in the past though showed me that "web developers" doing
only PHP and JavaScript development *very often* are neither interested
nor have the knowledge to easily build PHP on either Windows or OS X.
(Yes, it sounds like the typical cliche that only the Linux users know
how to do that by default, but it absolutely matches what I saw.)

And afaik Apple only delivers one version per OS X release, so that only
solves some problems. My point was that it's very easy to build on Linux
and I've seen a share of problems on both Windows and OS X for people
who haven't invested some effort. (Maybe more effort than necessary.)
But I did forget about Homebrew and maybe back then this was a bigger
problem than it is now.

Gretings,
Florian

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

Re: [PHP-DEV] PHP 7.0.0 final RTM delay

[Florian Anderiasch]

On 04.12.2015 19:01, Sebastian Bergmann wrote:
> Am 04.12.2015 um 18:53 schrieb Florian Anderiasch:
>> I hate to say it, but not providing an official Windows build is kind of
>> sticking the finger to everyone using Windows for PHP (not the language)
>> development.
> 
>  Sorry, but that does not explain the special treatment of Windows.
>  Red Hat provides official PHP binaries for RHEL and Fedora. Ubuntu
>  provides official PHP binaries for Ubuntu. etc. Why should Microsoft
>  not provide the official PHP binaries for Windows?

I think we're looking at the same problem from different directions :)

Many languages offer something for different platforms (see below), I
wonder why for example http://php-osx.liip.ch/ is a dedicated project
and no one (or did someone?) try to invite them (or are there better
alternatives?) to be an official part of php.net? (The formal answer
probably is "we only support the release tarball, as downloaded from
php.net - but that's not because users don't matter, just to keep the
reproducability of bugs consistent. And I think on Windows and OS X this
could warrant having blessed builds for ease of use.)

So to answer your question: We're treating Windows differently because
it's badly needed. And neither RHEL nor Fedora or Ubuntu need that.

Greetings,
Florian

3 quick examples:

python.org:
  https://www.python.org/downloads/
  Looking for Python with a different OS? Python for Windows,
Linux/UNIX, Mac OS X, Other

rust-lang.org:
  https://www.rust-lang.org/downloads.html
  Downloads for 3 platforms

ruby-lang.org:
  https://www.ruby-lang.org/en/documentation/installation/
  For Windows, just a link to RubyInstaller

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

Re: [PHP-DEV] PHP 7.0.0 final RTM delay

[Florian Anderiasch]

On 04.12.2015 11:29, Sebastian Bergmann wrote:
> Am 04.12.2015 um 00:09 schrieb Stanislav Malyshev:
>> Windows as a platform is different from Linux/Mac in several aspects
> 
>  True. But why does the PHP Project have to provide Windows binaries on
>  php.net? Microsoft should be treated as any other downstream vendor: let
>  them build their binaries on their infrastructure and let them distribute
>  their binaries through their channels.
> 
>  Again, my intention is not to "bash Microsoft". I appreciate and
>  respect everything they have done to make PHP on Windows more robust.
>  I just think that the PHP project would be better off to focus on
>  one release artifact: the source tarball.

While I'd love to share your view on this I think it's just unrealistic
in regards to ease of use towards anyone who's not a hardcore windows
developer.

a) building a php.net release tarball on a freshly installed
Ubuntu/CentOS/Debian/whatever box:

- it's literally 1 copy/pastable command line to install all
dependencies, then unzip, configure make.

b) building this on Windows:

- to be honest, I don't even know how many steps exactly are involved,
I've given up years ago. And in my team I am usually the one most
confident to develop *anything in any language* on Windows.

I hate to say it, but not providing an official Windows build is kind of
sticking the finger to everyone using Windows for PHP (not the language)
development. Yes, this could be alleviated with builds from external
sources, but most language teams release for "more platforms". And I
stand to what I said above. On Linux (and maybe also on OS X?) you can
get 90% of users non-versed in C development to build their PHP quite
easily, on Windows.. maybe possible, but not worth the hassle.

Greetings,
Florian

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

Re: [PHP-DEV] Re: Move internals discussion to a better medium

[Florian Anderiasch]

On 08/03/2015 12:22 AM, Stephen Coakley wrote:

> Personally, I'd like to see the mailing list move to a forum-type
> system. Lower barrier of entry, more visible archives, and more modern
> medium that supports other kinds of attachments and whatnot.
> 

I don't buy the "lower barrier of entry" argument.

Forum:
- Sign up via web form
- Get authentication email
- click on it, be logged in or not
- post

List:
- Sign up via web form
- Get authentication mail
- reply
- post

Someone iirc said you can even reply without signing up, so it might be
even lower. Unless you're saying people don't know what a mailing list
is or how it works - then ok. The same could be said for any type of
web-based infrastructure.

My actual main gripe with forums is that you can't skim it as easily (if
you're not reading every thread) because everything is split up into
subforums and paginated and whatnot. Or would "internals" be one subforum?

~Florian

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

Re: [PHP-DEV] NAN/INF->int conversion in 5.6

[Florian Anderiasch]

On 28.06.2015 02:46, Stanislav Malyshev wrote:

> My question is: should we backport code from PHP 7 that checks for
> infinity/nan and put it into 5.6? Or it's not worth it and it's ok for
> 5.6 to return random weird stuff there? (I know it's not exactly random
> and there's a reason why it's that number but it looks that way).

While I can't imagine many people would stumble over this (as apparently
there was no bug report) it could be a tricky one if you're not extra
paranoid when working with INF, I don't think it's worth changing this
behaviour so long after 5.6.0 was released. Good that it's fixed in 7
though.

It should absolutely be documented (and I still can't fathom why
searching for INF on the website only gives me function results and not
a direct hit for a 1:1 match on a pre-defined constant in core, but
let's not start this discussion.)

Greetings,
Florian

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

Re: [PHP-DEV] Revisit trailing commas in function call parameters?

[Florian Anderiasch]

On 18.06.2015 08:25, Yasuo Ohgaki wrote:
>> If people still consider it more harm- than useful then please don't flame
>> me and I'll shut up again :-)
>>
> 
> PHP allows
> 
> array(
>   1,
>   2,
>   3,
> );
> 
> therefore
> 
> my_variadic_function(
>"foo",
>"bar",
>"qux",
> );
> 
> is consistent behavior to me.

If variadic functions allow this and normal functions don't (and by most
PHP coding standards you'll format like this all the time because of 80
chars limit I don't see how this is in any way consistent. It's still a
function call after all and not an array.

~Florian

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

Re: [PHP-DEV] Vote process change proposal

[Florian Anderiasch]

On 03/18/2015 12:17 AM, Stanislav Malyshev wrote:
> Hi!
> 
>> people vote to appear/be active I don't see any way to avoid it - people
>> with a strong opinion might still try to win over, others might just go
>> this route if they think something really, really bad is happening -
>> we'll never know unless they publicly post this call to action.
> 
> So, essentially you say that people that participate have better chance
> of getting their way than people that are too busy to care. And that's
> supposed to be a bad thing?

No, essentially I'm saying that the number speak for themselves and I
think it's unrealistic to assume that the *majority* of people eligible
to vote vote on most RFCs. Of course I know that sometimes people are
undecided or deliberately don't want to take part in voting once or ever
- but compare

https://wiki.php.net/rfc/scalar_type_hints_v5#vote - 156 votes
with
https://wiki.php.net/rfc/context_sensitive_lexer#vote - 48 votes

> 
>> TL;DR: I'd prefer no one actively trying to lobby anyone else to vote in
>> their favor, but prodding people with a neutral "hey, check out this
> 
> I'd prefer people to express their opinions and try to convince others
> freely, without any allegation that doing so is somehow bad and should
> be prohibited. If somebody feels that he/she can not objectively vote
> and is easily swayed by lobbying, they could recuse themselves from
> voting, there's no problem with that and it is easy to do. OTOH, if they
> think their friends do not have informed opinions and are easily swayed
> by lobbying, they can refrain from calling such friends to vote. But I
> don't see why they should prohibit normal discussion behavior for others.

I thought I said that, so yes, agreed :) Of course I don't want to limit
proper discussions.

~Florian

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

Re: [PHP-DEV] Vote process change proposal

[Florian Anderiasch]

On 17.03.2015 22:37, Stanislav Malyshev wrote:
>> While I agree with discussing an ongoing vote, I do not find it ok for
>> people
>> to be able to see the current status of an ongoing vote. This might lead to
>> harassing people into voting just to change the outcome. Clear example:
> 
> You frame trying to change people's mind as something negative
> (harassing), but that's exactly what we're doing during discussion
> period. If not that, we wouldn't need it - just publish RFC and go
> directly to vote, nobody "harasses" anybody with discussion. I hope you
> don't think it is a good idea. I think we are all adult enough to be
> able to handle discussion on the merits of the proposals, and if someone
> has enough of it, it's ok too - nobody is forced to participate. But I
> think openness is an important condition of participation.

Sadly you're ignoring inertia/laziness/"life is what happens while
you're busy making other plans".

Just compare the minimum number of votes/median number/(average if you
must)/maximum number of votes (I bet STH got the crown now) - I don't
think there was a real *need* to even alert someones friends and
acquaintainces for 95% of votes.

Yes, STH was exceptional now, but I bet (and maybe know?) a much smaller
amount of lobbying is always in place, and still - unless you *make*
people vote to appear/be active I don't see any way to avoid it - people
with a strong opinion might still try to win over, others might just go
this route if they think something really, really bad is happening -
we'll never know unless they publicly post this call to action.

TL;DR: I'd prefer no one actively trying to lobby anyone else to vote in
their favor, but prodding people with a neutral "hey, check out this
vote you might have missed" is fine, although sometimes even then you
can gauge their vote, but the most active voters will probably not have
overlooked it.

~Florian

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

Re: [PHP-DEV] Voting irregularities

[Florian Anderiasch]

On 15.03.2015 16:44, Pádraic Brady wrote:
> 
> I don't think it's ridiculous in a separate thread around discussing
> voting practices. Anthony specifically notes that he is not calling
> them bad, or calling for them to be ignored in the context of the
> current RFCs. Merely noting that their existence has skewed this
> particular vote, as a recent ongoing example, which it has. I have to
> make an admission here, I cast a vote. I'm not on Anthony's list
> because I have used it previously a couple of times. I'm honestly a
> bit hesitant to believe I should have it, so I've deliberately
> moderated my voting. However, watching those with no prior voting
> history/or minimal history vote No compelled me to use it if only to
> offset one more arguably irregular vote by casting an opposing
> arguably irregular vote.

Maybe many people don't see it that way, but for example for me there's
hardly been any RFC that would shape the *spirit* of the language as
much as this RFC. So I think that's a perfectly valid reason to - for
the first time ever - pitch in with your vote, even if it's not the case
for me personally.

> The entire idea that such arguably irregular votes are spoiling RFC
> votes, i.e. not reflective of what the majority would consider votes
> by those who truly earned it, has been brought up by both sides to
> RFCs inside and outside of this list.

I don't think it's possible to create a system that

a) represents the majority of PHP users
b) represents the most active contributors to internals
c) can't be gamed in any way.

We have this system now and until a RFC comes along to change voting
rights or revert to the old "do what you want until someone calls you
out on it" there's hardly some constructive discussion about it in all
the threads where it came up.

Greetings,
Florian

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

Re: [PHP-DEV] [RFC] Anonymous Classes

[Florian Anderiasch]

On 02/24/2015 04:31 PM, Philip Sturgeon wrote:
> On Tue, Feb 24, 2015 at 9:58 AM, Florian Anderiasch  
> wrote:
>> On 02/24/2015 03:29 PM, Dennis Birkholz wrote:
>>> Am 24.02.2015 um 14:52 schrieb Philip Sturgeon:
>>>> https://wiki.php.net/rfc/anonymous_classes
>>>
>>> I like the idea of having anonymous classes, it is very helpful during
>>> development to just try something out without having the burden of
>>> creating a new file and a complete class including namespace and use
>>> declarations, etc.
>>
>> I don't buy this argument. If your class loader or PSR prevents you from
>> temporarily adding a 2nd bogus class to the same file (not talking about
>> best practices here, obviously) then there's the culprit and it's
>> nothing the language needs to fix.
>>
> 
> Your reply seems to assume that avoiding rules in a PSR is the only
> benefit of the RFC, which is weird when there is a whole RFC full of
> benefits of this RFC.

My reply was simply re: the quoted paragraph in the mail I directly
replied to, not yours. I simply think "trying something out" is not a
valid use case of anonymous classes.

I can generally like the RFC and still refute arguments in favor of it,
right? :)

~Florian

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

Re: [PHP-DEV] [RFC] Anonymous Classes

[Florian Anderiasch]

On 02/24/2015 03:29 PM, Dennis Birkholz wrote:
> Am 24.02.2015 um 14:52 schrieb Philip Sturgeon:
>> https://wiki.php.net/rfc/anonymous_classes
> 
> I like the idea of having anonymous classes, it is very helpful during
> development to just try something out without having the burden of
> creating a new file and a complete class including namespace and use
> declarations, etc.

I don't buy this argument. If your class loader or PSR prevents you from
temporarily adding a 2nd bogus class to the same file (not talking about
best practices here, obviously) then there's the culprit and it's
nothing the language needs to fix.

~Florian

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

Re: [PHP-DEV] Can we remove "NEWS" tag ?

[Florian Anderiasch]

On 02/11/2015 10:52 AM, Lior Kaplan wrote:
> Hi,
> 
> I've been doing some editing to the NEWS files, and keep getting this
> problem
> 
> $ git diff NEWS
> fatal: ambiguous argument 'NEWS': both revision and filename
> Use '--' to separate filenames from revisions
> 
> Although I can do as it suggests, I would prefer to remove the NEWS tag we
> have since 2008 as part  of the move from CVS to SVN.
> 
> Any objections ?

While I don't think anyone would actually be using that in the near
future, can't you just rename it to NEWS-2008 or something? (Or manually
retagging and then deleting if nothing else.)

 * still can be found
 * no historically important data is lost (just kidding)
 * problem solved

Just because I've seen people argue in favor of keeping historical
branches and stuff, and while I don't see a lot of value, it might be
needed at some point.

~Florian

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

Re: [PHP-DEV] Is it a good idea to have a "strict" mode?

[Florian Anderiasch]

On 01/30/2015 06:36 AM, Yasuo Ohgaki wrote:
> Hi Cesar,
> 
> On Fri, Jan 30, 2015 at 2:16 PM, César Rodas  wrote:
> 
>> I'm wondering if it would be a good idea to have a `strict` mode in PHP.
>> Many language have them and it is a good idea.
>>
>> I think it should be a bit different in PHP, it should encourage the
>> following things:
>>
>>  - Avoid deprecated things, it should throw an exception.
>>  - Avoid explicit conversions of undefined constants to strings.
>>  - Anything else that could make run-time slower *or* bad practice.
>>
>> ```php
>> "use strict";
>>
>> var_dump(FOOBAR); // should throw an exception, undefined constant.
>> ```
>>
> 
> We have error_reporting INI for this purpose.
> Users may be strict or lazy for errors by the INI setting.
> 

I don't think it's a good idea to have a strict mode at all. I'd prefer
any language to be strict and unambiguous enough from the start. Adding
strict mode after the fact is just a band aid. PHP's error reporting
level isn't that bad, but if you're ignoring legacy code there's hardly
a reason not to develop to the strictest standard possible.

~Florian

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

Re: [PHP-DEV] PHP 7 installation issues.

[Florian Anderiasch]

On 01/29/2015 03:49 AM, Levi Morrison wrote:
> When doing `make install` with a prefix of `/apps/php/7.0.0-dev` I get:
> 
> Installing shared extensions:
> /apps/php/7.0.0-dev/lib/php/extensions/no-debug-non-zts-20141001/
> Installing PHP CLI binary:/apps/php/7.0.0-dev/bin/
> Installing PHP CLI man page:  /apps/php/7.0.0-dev/php/man/man1/
> Installing PHP CGI binary:/apps/php/7.0.0-dev/bin/
> Installing PHP CGI man page:  /apps/php/7.0.0-dev/php/man/man1/
> Installing build environment: /apps/php/7.0.0-dev/lib/php/build/
> Installing header files:  /apps/php/7.0.0-dev/include/php/
> Installing helper programs:   /apps/php/7.0.0-dev/bin/
>   program: phpize
>   program: php-config
> Installing man pages: /apps/php/7.0.0-dev/php/man/man1/
>   page: phpize.1
>   page: php-config.1
> Installing PEAR environment:  /apps/php/7.0.0-dev/lib/php/
> make[1]: *** [install-pear-installer] Error 255
> make: *** [install-pear] Error 2
> 
> 
> Hmm.

I had that exact (I think) problem on building a checkout on Jan 14, but
could not reproduce it no matter how hard I tried, that's why I didn't
open a bug report - but apparently it's kind of valid.

Some info for my machine:

Debian GNU/Linux 7.8 (wheezy)
x86_64

'./configure' \
'--prefix=/usr/local/stow/php-7.0-master' \
'--with-config-file-path=/etc/php5/7.0-master' \
'--enable-fpm' \
'--with-fpm-user=www-data' \
'--with-fpm-group=www-data' \
'--with-gd' \
'--enable-zip' \
'--with-mysqli=mysqlnd' \
'--with-pdo-mysql=mysqlnd' \
'--enable-mbstring' \
'--with-curl' \
'--with-freetype-dir=/usr/include/freetype2' \
'--enable-gd-native-ttf' \
"$@"



Greetings,
Florian

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

Re: [PHP-DEV] [RFC] Remove the date.timezone warning

[Florian Anderiasch]

On 01/27/2015 07:40 AM, Matteo Beccati wrote:
> On 27/01/2015 01:34, Bob Weinand wrote:
>> Hey,
>>
>> I'd like to request removal of the date.timezone warning.
>>
>> Here is the RFC:
>> https://wiki.php.net/rfc/date.timezone_warning_removal
>> 
> 
> The warning is certainly annoying, but making it default to UTC or a
> wrong timezone because the right one can't be guessed is a major WTF.

I don't see how this would be a *major* WTF. Maybe a minor one as PHP
didn't have to have a default one, so maybe an oddity.

I'd argue that it's about setting a good example, UTC is the only sane
default for server software unless you know what you're doing.

We're always arguing about removing options from php.ini and while it
isn't about *removal* here I don't see why there can't be a sane default.

I just reread the RFC, so I'm -1 on next minor version, but +1 on PHP 7.

~Florian

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

Re: [PHP-DEV] PHP7 Homework for everyone reading this list

[Florian Anderiasch]

On 22.01.2015 18:05, Rasmus Lerdorf wrote:
> By installing a couple of apps (Wordpress-4.1, Drupal8 and Moodle -
> there are still some issues in Moodle I haven't figured out yet) on a
> box we've tracked down some bugs over the last couple of days. It would
> be really useful if we got more eyes on this. Install php7, then install
> any random app and see how it goes. Sometimes it is useful to flip back
> and forth between 5.6 and 7 to check if a problem is php7-specific, so I
> have php56-fpm sitting alongside php7-fpm and it is trivial to switch
> back and forth.

We're obviously not Wordpress-level famous but phpMyFAQ has a demo
install with master (not updated nightly, but regularly) at
http://richmond.demo.phpmyfaq.de/ (along with 5.4, 5.5, 5.6 and HHVM)
and our latest release - everything running smooth so far.

Maybe something like https://python3wos.appspot.com/ could make sense
for PHP apps and/or extensions?

Greetings,
Florian

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

Re: [PHP-DEV] Annotation PHP 7

[Florian Anderiasch]

On 04.11.2014 17:34, Andrea Faulds wrote:
> In Python, a decorator is a function (or callable object), and you use one 
> like this:
> 
> @some_decorator(foo, bar)
> def myfunc():
> # function source code here

I wonder how feasible it would be to add something like this and allow
everything that's allowed in a php function/method call as parameters
inside the annotation call - kind of like python does it, which seems to
be one of the simplest (in usage, not implementation) forms possible.

/**
 * @ORM\Entity
 * @Table(name="message")
 */
class User {}

becomes something like

@ORM\Entity
@Table(['name' => 'message'])
class User {}

with Entity and Table being callables, obviously. Maybe classes, with
User being the first argument, but I haven't thought that through.

~Florian

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

Re: [PHP-DEV] [RFC] GitHub Pull Requests Triage Team

[Florian Anderiasch]

On 31.10.2014 09:58, Peter Cowburn wrote:> On 30 October 2014 21:57,
John Bafford  wrote:
>
>> Hi,
>>
>> I would like to propose the creation of a team to triage the pull
requests
>> on GitHub, to help ensure that the pull requests are handled in a timely
>> manner. I am also volunteering to lead such a team, should the RFC be
>> approved.
>>
>
> Slightly off-topic, but how about the same thing for bugs.php.net and
> patches?

This implies that on bugs and with PRs it's the same issue.
My cautious guess is that permissions to merge PRs on GitHub (which not
all developers can do) are not the main reason that stuff doesn't get
merged.
Whereas on the bug tracker, afaik everyone with a php.net account can
triage, edit, assign, etc bugs. And still there are open ones.

So, if it's only a permissions issue and people are active hindered to
get stuff done, go ahead and propose changes. If it just feels like
stuff doesn't get done... maybe no one's around to do it.

~Florian

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

Re: [PHP-DEV] Currently supported versions of PHP

[Florian Anderiasch]

On 10/27/2014 11:29 AM, Sebastian Bergmann wrote:
> On 10/27/2014 10:45 AM, Peter Cowburn wrote:
>> The closest we have, at the moment, is probably http://php.net/eol.php
>> which details the versions which are no longer supported.
> 
>  We need the inverse of that :)
> 
>> Good question.
> 
>  Should we start http://php.net/supported-versions.php then?


I'd suggest to put a table (like on wikipedia, see other child comment)
on that page.
Why seperate it, the correct page is already there, it just doesn't have
the correct information ;)
And nowadays releases are done with a set EOL date anyway.

~Florian

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

Re: [PHP-DEV] Is it fair that people with no karma can vote on RFCs?

[Florian Anderiasch]

On 09/22/2014 08:56 PM, Zeev Suraski wrote:
> The first bullet is the one this thread deals with so far.  It clearly
> states that having an SVN account isn't enough - but that code contributions
> to PHP are mandatory.  We should probably consider revising that to also
> account for people contributing docs and other types of submissions.  I'd
> also consider adding a requirement for contributing at least X commits (say
> 20 or 50) so that someone who did a one-off or two-off patch won't have the
> same vote as someone who contributed  hundreds or thousands of commits.  I
> believe this data can be easily pulled from git.

That's a horrible idea. From a very quick unscientific glance at
https://github.com/php/php-src/graphs/contributors there's only ~50
people *ever* to have more than 20 commits in php-src. (Incidentally I'm
at the very bottom with 22, should I be happy to just have made the cut
if php-src commits are the only metric?)

I'm not saying karma could be revoked after a few years, especially if
there were cases where it was given back instantly on return, but this
all sounds like a bureaucratic mess. Also, how do you value people
reproducing bugs, checking the bugtracker, testing every build, etc.pp?
There are a lot of tasks that are a lot more important in every day work
than only writing internals code.

I don't have a solution ready, but maybe I'm just too much in the middle
ground - not a day to day contributor, but with an account nearly 11
years old and enough inactivity breaks of months to years I feel
entitled enough to see both sides.

Greetings,
Florian

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

Re: [PHP-DEV] [RFC] Loosening heredoc/nowdoc scanner

[Florian Anderiasch]

On 30.08.2014 23:26, Robert Williams wrote:
> If the syntax of heredocs/nowdocs is to be loosened, the biggest aspect I’d 
> like to see addressed is indentation. I can certainly see how it would be 
> nice to loosen the restrictions around the post-closing-token newline to 
> allow easier use in places like array definitions, but, I’ve never run into 
> that problem myself. I have, however, been annoyed by the indentation 
> limitations, so much so that I could probably count with my fingers the 
> number of times that I’ve used the construct in the couple million lines of 
> PHP I’ve written — even though I *want* to use it about once a week. I just 
> find the side-effect on code formatting, when used in a container structure 
> (class, function, method, loop, whatever), to be more than I can handle. Look 
> at this simple example from the docs to see what I mean:
> 
> [...]
> 
> function foo() {
>$string = <<<
>   THEEND
>   This is the document text. Any
>   whitespace appearing in a column
>   that’s before the starting token
>   is automatically ignored for all
>   lines.
>THEEND;
> 

That is the only real problem with heredoc/nowdoc for me as well, not
the delimiter (and the reason why I hardly ever used it).

The problem is that I think this could be very confusing. It would be
the typical case of an additional optional argument to a function, but
it might be hard to implement it with an operator.

Greetings,
Florian

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

Re: [PHP-DEV] Remove generated VM from git?

[Florian Anderiasch]

On 26.08.2014 22:30, Andrea Faulds wrote:
> On 26 Aug 2014, at 21:08, Stas Malyshev  wrote:
> 
>> That would make building PHP for non-internals person harder and the
>> list of dependencies they need to get right longer. While providing zero
>> added value. And yes, there are a lot of non-internals persons building
>> PHP. Sometimes they may even use git.
> 
> Why would a non-internals person want to build PHP from git? That’s just 
> making things harder on themselves. Besides PHP itself (should my proposal 
> succeed), you need other extra dependencies, including a lexer generator if 
> Nikita’s proposal succeeds.
>

Why would an internals person (for various vague definitions of this
term) install php only because they want to build it? Maybe I'm the
exception here but I am regularly building various versions of php on my
laptop without having any version *installed*.

I also would prefer to keep this out of the dependencies.

Greetings,
Florian

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

Re: [PHP-DEV] [VOTE] Mutliple defaults in switch statements

[Florian Anderiasch]

On 14.08.2014 00:12, James Ward wrote:
> I'm not entirely sure that a backwards compatibility break in a minor
> release would be considered non-controversial.
> 
> [...]
>
> I see this as a bad design choice in the language which should be
> rectified... just in a major version.
> 

As it doesn't even work (one is silently ignored) I wouldn't call it a
design choice, but a bug or oversight.

On the one hand I also agree with Sara that this could've easily been
fixed with a commit without RFC.

On the other hand I don't think it's an *urgent* fix and there's no
pressing need to have it in 5.next instead of next.

~Florian

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

Re: [PHP-DEV] Re: Deprecating GD functions imagettftext/bbox

[Florian Anderiasch]

On 24.07.2014 09:13, Pierre Joye wrote:
> hi,
> 
> On Tue, Jul 22, 2014 at 9:01 PM, Lonny Kapelushnik  wrote:
>> Morning,
>>
>> I propose deprecating two GD functions: imagettftext and imagettfbbox.
>>
>> The reasons I would like to deprecate them are:
>> 1. Their functionality is a subset of imagefttext and imageftbbox
>> 2. The imagettf* functions have the same requirements as the imageft*
>> functions
>> 3. The imagettf* functions parameters are compatible with the imageft*
>> functions parameters

As I said on IRC, I think the least invasive action would be to make
them true aliases (so that the ones with less parameters act exactly as
the ones with more) and put that into the docs. This doesn't contradict
future removal.

Greetings,
Florian


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

Re: [PHP-DEV] Re: HTTP supergloblas and request body/query (was: Parsing PUT data)

[Florian Anderiasch]

On 02.10.2013 17:29, Daniel Lowrey wrote:
> The superglobals are a hopelessly poor abstraction. Can we stop trying to
> put the proverbial gold ring in the pig's snout on this?
>
> [...]
>
> Something like the following would be an infinitely superior solution:
> 
> interface HttpRequest {
> function getMethod();
> [...]
> }
> 
> By adding a global function such as `get_request()` that returns the
> immutable request object you get all the functionality you could want:
> 
> 1. Entity body parsing (for cookies or form data) could be done JIT
> 2. Userland code can easily typehint against the request
> 3. No more mutability, eminently testable
> 4. Eliminates the need for `$_GET`, `$_POST`, `$_COOKIE`, etc ...
> 
> This is simply an example of a much better way to model HTTP requests --
> it's not a suggestion for a final implementation. But IMO if we're going to
> fix this then we should really fix it and not continuously tickle the same
> broken abstraction.

While I totally agree with your point, I don't see why this needs to be
in core. This is perfectly done in userspace, even the immutable part.

The only benefit of putting that in core would be the standard-defining
part, but not much else. Plus it's not minimizing any abuse, as long as
the superglobals are still available (and I don't think renaming or
removing them would be a good idea.

Greetings,
Florian


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

Re: [PHP-DEV] Wake up

[Florian Anderiasch]

On 09/12/2013 06:43 AM, Philip Sturgeon wrote:

> As for the comments about the FIG made by others, I agree with Larry
> in that we're doing a pretty good job at trying to build on the
> example set forward by internals. Self moderation and workflow are two
> important factors to the group, and I don't feel like this 4 point
> list is the sort of workflow anyone should be trying to follow or
> enforce.

I'm not sure I'm getting what you're trying to say here:

If it only is about the workflow in FIG, ok, maybe that should be looked
at and put out more descriptively on this list instead of people telling
to go read something somewhere.

If it is about what FIG does, then I disagree - because while I love
what FIG has been come up with (in terms of contents partly and of it
being done at all fully) - I think it has no place in internals and is
very well off as a seperate entity. Like I find a coding standard set by
the language developers kind of nuts. (Go pun not intended, because in
Go it has been there from the public beta version, not introduced like
15 years after inception. Same with Python, afaik it was a PEP that was
basically accepted by the community at large)


Greetings,
Florian

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

Re: [PHP-DEV] Wake up

[Florian Anderiasch]

On 09/11/2013 02:35 PM, Johannes Schlüter wrote:
> On Wed, 2013-09-11 at 12:44 +0200, Florin Patan wrote:
>> - having a RFC to make a language change requires to have a patch
>> which if you don't know C and internals you got no chance of doing.
> 
> Well, so what should happen? An RFC without patch is accepted and then?
> Somebody has to write a patch at some time. Whom of the people spending
> their free time do you want to force to do that even though they might
> not be interested in the feature?

That's a point I keep on hearing on this list (and I actually agree) -
but how do other projects manage that?

Is there a core team that's more inclined to "step up" and just clean a
mess someone else left or handling cruft that somehow pops up?

Unless you have an entity (non-profit or for-profit) that's handling
everyday chores/tasks/steering the vision and demands from its members
to do stuff they don't take up on your own... I don't see how it could
be done in another way :)

Greetings,
Florian


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

Re: [PHP-DEV] windows.php.net

[Florian Anderiasch]

On 01.09.2013 03:01, Pierre Joye wrote:

>> Also I don't consider the separation userfriendly. A user comes to
>> php.net and tries to fetch downloads ... that might be streamlined quite
>> a bit when properly grouped together.
> 
> Many can, could, should or would. Complaining and doing almost nothing
> however do not help anyone.

It felt a lot less like complaining than inquiring.
Big surprise, Johannes isn't the only one wondering about a lot of that
stuff that he asked. You can argue about whether you felt unfairly
attacked or not, but to stay on the topic I'd bet not a lot of people
reading this list (apart from the ones on the w.p.n page) really have
any meaningful insight there. Just look at the list for enquiries about
windows builds and you earn mostly blank stares from the rest of the
team until one of you guys answers.

Greetings,
Florian


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

Re: [PHP-DEV] Re: [PHP-WEBMASTER] Possible denial of access to php.net for PHP developers

[Florian Anderiasch]

On 06/08/2013 02:54 AM, Sherif Ramadan wrote:
> On Fri, Jun 7, 2013 at 1:30 PM, Terry Ellison wrote:
> 
>> The background to this is that I am a community contributor to PHP
>> internals and have been actively engaged on the internals and pecl-dev
>> lists for over a year using my personal domain email address (terry at
>> ellisons dot org dot uk).  When I attempted to post some comments on an
>> internals thread a week ago, I received a
>>
>> internals@lists.php.net SMTP error from remote mail server after MAIL
>> FROM: Terry at ellisons dot org dot uk
>> host pair1.php.net [76.75.200.58]: 550 5.7.1 reject mailfrom [xbl]
>>
>>

Small (maybe unrelated) bump.

I've been getting (and heard it from others as well) these warning mails
every few weeks:

> Messages to you from the internals mailing list seem to
have been bouncing. I've attached a copy of the first bounce
message I received.

As a matter of fact I haven't had any known problem with bounces or
mails to this or other addresses for a few years, so I'm inclined to
blame the php list mail system - I'm not really bothered, but if it
starts acting up enough now to deny complete access maybe we should
really do something there?

Greetings,
Florian

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

Re: AW: [PHP-DEV] Importing namespaced functions

[Florian Anderiasch]

On 04/24/2013 08:15 AM, Martin Keckeis wrote:
> class Something{
> public static function blubb();
> 
> public static function blubb2();
> }
> 
> 
> use Abc\Def\Something;
> 
> Something::blubb();
> Something::blubb2();

Yes of course you can do that as an ugly workaround - but I wouldn't
call that a good reason to treat functions differently than classes.

This is just a gut feeling, but maybe Reflection stuff even differs for
methods and functions. Would be interesting to compare memory footprint
and execution speed of function vs. static method as well. (Do we even
have some sort of general knowledge on this? Can anyone give (relative)
numbers?)

Additionally, it's either semantically wrong to group unrelated
functions in "static tool classes", it's even a well-known antipattern.

Greetings,
Florian

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

Re: [PHP-DEV] Functionality updates to array_column()

[Florian Anderiasch]

On 04/22/2013 11:35 PM, Sherif Ramadan wrote:
> On Mon, Apr 22, 2013 at 1:35 PM, Ben Ramsey  wrote:
> 
>> I've just submitted the following pull request for updates to the
>> array_column() function:
>>
>> https://github.com/php/php-**src/pull/331
>>
>> I asked about these changes on the #php.pecl IRC channel a few weeks ago,
>> and others on the channel agreed that it was best to go ahead and submit
>> these changes while PHP 5.5 is still in beta, since these would potentially
>> create BC breaks once 5.5 is in RC or GA stages.
>>
>>
> I might be wrong here, but I thought beta was a feature freeze. Is it not?
> 

Not sure if this applies to a feature that's just been included before
(or during?) the alphas/betas.

I'd prefer to ship 5.5 with a stable/final feature - so better get it in
now than in 5.5.1 with (even slightly) different behavior...

Greetings,
Florian

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

Re: AW: [PHP-DEV] Importing namespaced functions

[Florian Anderiasch]

On 04/22/2013 12:55 AM, Robert Stoll wrote:
> I agree with Igor. The readability could be improved and I do not see the
> problem of hiding built-in php functions (however, I would not recommend
> it).
> I would say, if someone hides the normal php built-in function then he or
> she is doing that on purpose and is aware of the consequences. Thus it is
> also fine if the same person imports the function, which hides the normal
> php built-in function, in another namespace. 

Huge +1 from me.

I know that using only functions instead of OOP in PHP has this
90s-PHP3-Vibe to it, but as a matter of fact you can write mostly
side-effect free code using only functions in PHP.

This would make using functions much more flexible and even more
importantly, consistent to everything else.

The only downside to this proposal, as Stas correctly mentioned is that
it would allow people to shoot themselves in the foot when using weird
import behavior. But as you deliberately have to misuse this I don't see
any real harm. Something like instance variable shadowing in Java is
much, much more error-prone and still hardly anyone complains about this
kind of feature.

Greetings,
Florian

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

Re: [PHP-DEV] Improve Warning when loading Zend Ext as PHP module

[Florian Anderiasch]

>> Wed, Apr 3, 2013 at 11:01 AM, Johannes Schlüter >> wrote:
>>
>>> Hi,
>>>
>>> with opcache being bundled I expectr to see multiple bugs like #64568
>>> where users are trying to load opcache as PHP module (using extension=
>>> in php.ini), I tried to improve the error message a bit.
>>>
>>> In
>>>
>>>
>> https://github.com/johannes/php-src/commit/a1301253a44de3997548cbd8f83e38d79e4c331c
>>> the PHP module loader will, in case of an error, check for Zend
>>> Extension symbols and give a more verbose error .
>>>
>>> Any opinions on this?


Very good idea, +1

Greetings,
Florian

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

Re: [PHP-DEV] Voting on PHP features

[Florian Anderiasch]

On 03/17/2013 02:12 PM, Clint Priest wrote:
> Unfortunately my experience with that process has been that many people
> will vote who had no part in the discussion.

I don't see a point repeating points of discussion when being in
agreement with people who already stated their opinion, or being
persuaded by arguments given.

I suppose the majority of voters will read the discussion, not
necessarily actively participate. At least that would be sensible, right? :)

Greetings,
Florian

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

Re: [PHP-DEV] RFC Autoboxing Draft

[Florian Anderiasch]

On 02/25/2013 02:43 PM, Nils Andre wrote:
> strings. Not going too much into details here, many programmes always have
> to look up the function definition because very similar functions have
> their parameters in different orders or simply don't act in a predictive,
> well-structured manner. This article is a good read to sum it up:

Hi,
"not going too much into details here"

First, [lease do go into details, this is exactly what it is about.
I can'tpeven begin to fathom what you think autoboxing has to do with
variable order on string functions.

Second, that article might be a lot of things, but "summary" is surely
the worst way to describe it. "Semi-complete, semi-outdated rant
covering every current and past flaw in PHP" might be a better one.

And lastly, if you're suggesting a "startsWith" method on a proposed
String Object, that still has nothing to do with an Autoboxing RFC -
it's step 2 or 3 after the language would have Autoboxing.

Greetings,
Florian

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

Re: [PHP-DEV] rfc:trailing-comma-function-args

[Florian Anderiasch]

On 22.02.2013 22:46, Sebastian Krebs wrote:
> /sign
> Especially about the "implies, that another optional argument may exist":
> One does not simply add arbitrary arguments to a function call. Except when
> the function signature changes, but in this case (to repeat myself) the
> additional diff-line is negligible.

I've thought about this, and the only function I'm using often enough to
have this change be needed/nice/finally there is sprintf - it's the only
function with variable number of arguments that's bitten me with the
trailing comma at least once a month - but not a single other function I
can think ok. (Maybe I should use more var_dump though...)

Greetings,
Florian


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

Re: [PHP-DEV] PHP User Survey

[Florian Anderiasch]

On 02/21/2013 08:14 AM, Pierre Joye wrote:

> I do not have a single doubt. Why? Surveys are one of many ways to get
> feedback. They have no contracting values but give us some numbers about
> one rfc or another. That may help us to focus on one feature instead of
> another if we see a large number of users looking forward to it.

You'll never get perfect results, but I prefer results at all over none :)

There have been a lot of those for other languages:

-
http://cemerick.com/2012/08/06/results-of-the-2012-state-of-clojure-survey/
- http://survey.perlfoundation.org/
- http://survey.hamptoncatlin.com/

Looking forward to this, especially if we could get a few thousand
people to vote.

Greetings,
Florian

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

Re: [PHP-DEV] [RFC] Allow trailing comma in function call argument lists

[Florian Anderiasch]

On 19.02.2013 13:06, Sara Golemon wrote:
> Opening RFC to allow trailing comma in function call argument lists
> 
> https://wiki.php.net/rfc/trailing-comma-function-args
> 
For completeness' sake:

The VCS argument is kind of moot if you format your source code like
it's sometimes/often seen in Haskell code:

$fp = fopen( "sample.txt"
   , "r+"
   );

(but mostly not with function calls, more with data structures afaik)

I know, hardly anyone uses this in PHP, but it's a workaround for the
main reasoning in the RFC.

Personally, I'm +1 :)

Greetings,
Florian

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

Re: [PHP-DEV] VCS Account Request: jenkins

[Florian Anderiasch]

On 04.02.2013 19:13, Ferenc Kovacs wrote:
> yeah, that would work also, but it has some of the concerns that were
> mentioned about the git push way:
> if you somehow compromise the jenkins box, you can get rouge commits to
> the jenkins git.php.net  repo.
> as I mentioned, I think I will use some 3rd party repo(github probably)
> for the configs and manually merge stuff to the web/jenkins repo on
> git.php.net  once in a while.


I omitted "if people are against giving the bot access" - that's why I
suggested GitHub - and I know it's usually only mirroring, but why not
add new repos for "different security contexts" there? (With a big "not
mirrored warning ofc")

Greetings,
Florian

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

Re: [PHP-DEV] VCS Account Request: jenkins

[Florian Anderiasch]

On 03.02.2013 15:18, Ferenc Kovacs wrote:

>>> I requested this one, please approve it and also grant him karma for
>>> web/jenkins.git

Wouldn't it be a possibility to just create a github repo and allow key
access only there?

Greetings,
Florian

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

Re: [PHP-DEV] Proposal for serious BC compatibility aka language versioning

[Florian Anderiasch]

On 03.02.2013 23:49, Thomas Bley wrote:
> Using Debian/Ubuntu, I have "python2.6", "python2.7" and "python3"
> packages, but only one version of "php5-fpm".
> Maybe it would be better to have "php5.3-fpm" and "php5.4-fpm", using
> /etc/php5.3 and /etc/php5.4 ?
> Esp. for Travis-CI it would be much better to have separate packages
> than running custom workarounds.

I don't think you'd find many people here disagreeing with distribution
maintainers providing packages for multiple version at the same time
(like 5.3 and 5.4) - so that suggestion should be brought to these
people. (I know, some are reading this list.)

I've never seen anyone on this list telling a distribution maintainer
not to use /etc/php5.3 or something, please enlighten me if that's not
the case.

Greetings,
Florian

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

Re: [PHP-DEV] ZTS - why are you using it?

[Florian Anderiasch]

On 01/30/2013 07:09 AM, Pierre Joye wrote:
> On Wed, Jan 30, 2013 at 2:15 AM, Stas Malyshev
 wrote:
>> Hi!
>>
>>> Python, for example, is thread safe by default. Extensions developers
>>
>> Doesn't Python have global engine lock?
>
> Right, but they do not give up thread safety. See "Thread State and
> the Global Interpreter Lock" in:
>
> http://docs.python.org/2/c-api/init.html
>
> The TS model in php should be redesigned in the next major version,
> instead of simply giving it up.

You make it sound as if the GIL was a good thing...

And yes, it might have been introduced for that exact reason, but I
haven't read anything pro-GIL in the last few years, according to most
Python developers (mostly those who want to scale) it's basically their
number one pain point.

Doesn't sound like a fair deal at all. Plus, mod_python is dead,
everyone's using FastCGI/UWSGI anyway, so I'm not sure what you're
hinting at... (Or am I missing something?)

NB: Deliberately staying away from any pro/contra PHP-ZTS arguments,
this was just a quick blurb about Python.

Greetings,
Florian

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

Re: [PHP-DEV] Voting periods

[Florian Anderiasch]

On 01/28/2013 10:22 AM, Zeev Suraski wrote:

> My suggestion is for voting periods to be limited to one week, regardless
> of the topic.  It should be more than enough.  Regardless, an ‘open ended’
> voting period is unacceptable IMHO.

Whatever the voting period is, IMHO the most important thing would be to
have the person opening the vote set a mandatory voting end date in the
announcement + RFC itself, no matter how long it will be (to be
discussed seperately)

Greetings,
Florian

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

Re: [PHP-DEV] Re: [RFC][vote] 5.3 EOL

[Florian Anderiasch]

On 01/21/2013 11:44 PM, Christopher Jones wrote:

> Pierre,
> 
> Can you review this RFC and the votes?  The wording "5.5 final
> release" needs assessing.  You probably meant "first 5.5 production
> release".  If anyone interpreted it as it is actually written
> i.e. "terminal 5.5 release", then the vote needs to be re-run.

How do you plan to find out who would've taken it that way? Ask all who
voted?

Maybe it sounds more ambiguous for a native speaker, but I actually had
to reread this mail to get your point. I've never heard anyone use
"final" as "terminal", the "final" in the software development domain
has always been the name for the version after the RCs, at least for me.

Greetings,
Florian

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

Re: [PHP-DEV] PHP 5.3 - end of live schedule

[Florian Anderiasch]

On 10.12.2012 15:24, Johannes Schlüter wrote:
> On Mon, 2012-12-10 at 21:08 +0800, Adam Harvey wrote:
>> To be honest, Debian isn't really the distribution I'm worried about.
>> Ondřej does good work, and Debian Wheezy has PHP 5.4 and isn't miles
>> off, it seems.
>>
>> RHEL and Ubuntu are mostly the ones I'm thinking of here — RHEL 7 is
>> supposed to be out in the second half of next year, but history (and
>> my own experience both in supporting users and dealing with vendors)
>> suggests that RHEL users are slow to upgrade. Ubuntu won't have
>> another LTS release until 2014.
> 
> All those are interested in are "critical"/"security" fixes. Besides
> that the version is frozen. So for those I don't see a benefit to
> continue providing unrelated fixes.

Yes, with RHEL 6.3 using 5.3.3 I don't see how doing anything besides
going into "bugfix mode" is going to benefit those users, or is there a
6.4 planned?

Greetings,
Florian

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

Re: [PHP-DEV] Moving forward: PHP 5.5

[Florian Anderiasch]

On 08.09.2012 13:49, David Soria Parra wrote:
> Let's keep things simple here, stay on topic and debate
> if we want to start with 5.5 and who can RM it.

Hey,
sounds like a really good plan and apart from the probably most-often
named disadvantage, getting people to switch (hard enough to get minor
upgrades rolled out) I'm very much looking forward to this :)

Greetings,
Florian

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

Re: [PHP-DEV] Moving to an AST-based parsing/compilation process

[Florian Anderiasch]

On 09/06/2012 10:47 AM, Sebastian Bergmann wrote:
> On 09/06/2012 06:37 AM, Dmitry Stogov wrote:
>> The only real advantage could be an ability to expose AST to PHP scripts,
>> but only few people may need it.
> 
>  Everyone working on static analysis tools for PHP code needs access to
>  the (canonical) AST. While the number of people behind this "everyone"
>  will be small (hopefully it will grow) but the tools they create based
>  based on the AST will be valuable for every PHP developer.
> 

I fully agree with Sebastian here, nearly all the methods used in the
past to get some meaningful analysis done relied on third party tools,
were immensely prone to breakage or both.

I've used phc up to 5.2 without problems but after that I didn't really
keep up trying yet again another completely different method. This is
such a basic task for static analysis, something not in the core will
always be a second-class citizen.

And yes, the people directly benefitting from this and not indirectly
from the tools produced will probably be quite happy.

So unless something is getting slower, +1.

Greetings,
Florian

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

Re: [PHP-DEV] RFCs and organisation

[Florian Anderiasch]

On 07/26/2012 11:41 AM, Andrew Faulds wrote:
> Hi Stefan,
> 
> I made an RFC page on it. http://wiki.php.net/rfc/howto
> 
> It's not really an RFC, more a meta-RFC or informational wiki page. It
> would helpful if you could edit it too. I just want to make an obvious
> go-to place for info on this.

What I see as most in need of upgrade would be an automatic Table of
Contents on the RFC page itself - with RFCs sorted by status.

There have been numerous cases of people forgetting to put their new RFC
on the index page, not updating to "voting" etc.pp

Greetings,
Florian


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

Re: [PHP-DEV] Make try/catch brackets optinal

[Florian Anderiasch]

On 07/20/2012 11:37 AM, Ivan P @ Hoa wrote:
> On 20/07/12 11:28, Lester Caine wrote:
>> Ivan Enderlin @ Hoa wrote:
>>> Finally, I would like to clarify my proposal: I just wanted to
>>> discuss about
>>> making try/catch braces optional and not criticize PHP syntax…

I don't see how making something worse because of consistency has any
real benefit besides attacking a perceived problem of inconsistency.

This might be me (quick poll on developers with sample size: 1), but in
all the years of doing PHP/Java/x I hadn't even thought once of trying
to use try/catch without braces. I can't even remember using if without
braces.

Greetings,
Florian

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

Re: [PHP-DEV] New String Function: str_replace_limit

[Florian Anderiasch]

On 07/16/2012 10:29 AM, Paul Dragoonis wrote:
> Thanks for the comments guys, I like your idea about skipping the
> by-ref count parameter.
> 
> If the 'default' keyword were to be added in, then you could skip the
> 4th parameter and add your 5th 'limit' option.
> 
> $str = str_replace($search, $replace, $subject, default, 5);
> 
> Does anyone have any objections on this implementation approach?
> (obviously we'd have to wait for the default param skipping to be
> implemented, I'm not sure on the implementation status of that
> feature)

I'm not seeing what's the problem with it being a by-ref variable, as
you've mentioned it twice now. Are you bothered by an additional
variable being set in memory when skipping (i.e. not using it)? Or am I
reading more into it than you tried to say? :)

Greetings,
Florian

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

Re: [PHP-DEV] PHP governance question?

[Florian Anderiasch]

On 05/18/2012 01:01 PM, Pierre Joye wrote:
>> 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?
> 
> There are package leaders in pecl, http://pecl.php.net or extensions
> authors/maintainers, see the CREDITS file in the php sources.

It might be worth mentioning that PHP doesn't have a governing body
(like the Python Software Software, PSF) in the background, only the PHP
Group (see phpinfo() -> Credits or what Pierre said) - but with
different goals (someone else might want to step in to clarify).

Greetings,
Florian

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

Re: [PHP-DEV] Re: [RFC] skipping optional parameters

[Florian Anderiasch]

On 04/18/2012 11:04 PM, Stas Malyshev wrote:
> Hi!
> 
>> "default" is already a reserved keyword. It's used in switch
>> constructs. So it is safe to use :)
> 
> Ah, silly me, indeed it is. Then I guess it doesn't hurt to add it as an
> option. Will do.

I can't estimate the amount of breakage, but what about using underscore
(literal _) without quotation marks?

In functional languages it's sometimes the "default match" in pattern
matching, that's at least a loose conversion and I hope not many people
would do
define("_", ) in their code.

The question now is, if create_query("a", _, _, _, true) really looks
better...

Greetings,
Florian

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

[PHP-DEV] Question about parser implementation details

[Florian Anderiasch]

Hey there,
due to the widespread acceptance of binary number format (0b1010101) and
the growing demand for backwards compatibility I've started to work on
support for Roman Numerals (I, II, III, ...)

As you might know, this format cannot be strictly parsed from left to
right or right to left, as several number values need a look-ahead
before being able to compute them (like IV), so my naive first
implementation splits the string into tokens (like in 1990 = MCMXC =>
M,CM,XC => 1000,900,90) then simplifying those 3 on their own, then
adding the results, but I'm not sure this could kill performance if
calculated inside zend_language_scanner.l.

I'd appreciate any hints on how to tackle this serious concern.

Btw, in the spirit of x for hex and b for binary I thought about using
this syntax:



unless anyone has any better suggestions?

Greetings,
Florian

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

Re: [PHP-DEV] Providing sandboxed versions of include and require language constructs

[Florian Anderiasch]

Hi,
On 03/06/2012 08:34 AM, Adam Jon Richardson wrote:
[...]
> 1) Internal functions seen as universally safe would by default be allowed
> (e.g, str_replace(), array_pop(), etc.)
> 2) Unsafe internal functions would have to be explicitly declared (e.g.,
> file(), stream_*, etc.)
> 3) Any includes or requires within the sandboxed code would be forced to
> meet the same restrictions. (tricky)
> 4) Code containing unsafe functions not included in the whitelist would
> raise an error.
[...]
> Thoughts?

Isn't that basically what all template engines tried to solve before
with giving you a defined subset of tokens that are more or less
directly converted to php code? The benefit I see is that plugin
developers wouldn't need to learn a new DSL (domain-specific language),
but use PHP code. Just that it's not PHP if you disable 90% of the
functions available.

While the idea is certainly not bad, I'm not sure you could write
sensible plugins for applications with only a few string functions at
hand. My gut instinct tells me you'll run into something like "I wish I
had this dir() to get the files in this directory" more sooner than
later. Last plugin (for Drupal) I wrote for example hooked into the File
API and saves/retrieves uploads to/from MogileFS. So that's file access
AND network access, and those would quite probably the first on the list
to be blacklisted. And if you only blacklist a few, disable_functions
might be enough.

To sum it up, to solve this problem I'd be more thinking about creating
a specific DSL (like puppet) to fill my needs and not try to make people
write some sort of 50%-PHP with constant lookup which functions are
allowed and which are not.

Greetings,
Florian

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

Re: [PHP-DEV] Pierre's employment status

[Florian Anderiasch]

On 04.02.2012 11:10, Lester Caine wrote:
> If not then at least it will explain why there is confusion over your
> connection with Microsoft!

I don't see how this belongs on internals, why don't you go write him a
mail in private?

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

Re: [PHP-DEV] Re: Suhosin patch disabled by default in Debian php5 builds

[Florian Anderiasch]

On 02/03/2012 01:28 AM, Christoph Anton Mitterer wrote:
> But this wouldn't solve our discussion here... the question would
> still be open, whether Debian sets this flag or not, or whether it
> makes two binary packages.

Now that's something I didn't read from Ondřej's mail, but delivering
the packages with and without suhosin would, while being more work,
certainly the most helpful way for users. Then again I'd gladly help if
there's anything of this additional work that can be done.

I'd prefer to have Debian's default php5 package with Suhosin as usual,
but I'm hardly the one making demands or suggestions here.

I'm with Soenke (different mail in this thread) - better keep the
securest-possible package by default. When I need performance, I'm
rolling my own php anyway - no matter what base system or package format.

Greetings,
Florian

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

Re: [PHP-DEV] Urgent patch for traits in PHP 5.4

[Florian Anderiasch]

On 01/16/2012 11:25 AM, Stefan Marr wrote:
> I would argue that __FILE__ and __LINE__ are not referring to conceptual 
> entities, but the literal code. And, I guess, they are mostly used for 
> debugging purposes to identify the relevant code. Thus, I would not change 
> them, but keep them as compile-time constants referring to the actual place 
> where they occur.
> 
> Adapting them to reflect the using classes would at least not seem to be the 
> intuitive semantics, I think.

+1, absolutely.


Greetings,
Florian

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

Re: [PHP-DEV] PHP Wiki Down?

[Florian Anderiasch]

On 01.01.2012 04:49, Clint M Priest wrote:
> Looks like wiki.php.net is down... I'm getting an nginx gateway timeout.

Works for me, now.

Related:
Did the monitoring url change or is it still down?
Are there any efforts to bring munin back?

Unrelatedly, happy new year :)
Florian

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

Re: [PHP-DEV] SVN Account Request: deepakb

[Florian Anderiasch]

On 11/17/2011 03:28 PM, Deepak Balani wrote:
> * Working in the internals of PHP.

Hi,

this document describes how to start contributing to PHP:

http://svn.php.net/viewvc/php/php-src/trunk/README.SUBMITTING_PATCH?view=markup

Greetings,
Florian

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

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

[Florian Anderiasch]

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.

If anyone cares and feels like it, you could check that.
Proofreading is advised.

 adam
 afortaleza
 almanar
 chad
 delrom
 dthompsono99
 edin
 emile
 hugo_quinter
 ilia
 jippie
 kevin
 mitch
 mmeier
 pierre
 ronabob
 sascha
 tkxs
 ufux

And no, don't ask why...

Greetings,
Florian

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

Re: [PHP-DEV] PHP CLI + Valgrind = FAIL

[Florian Anderiasch]

On 08.11.2011 18:47, Rasmus Lerdorf wrote:
> Valgrind should also have a way to turn off grabbing SIGUSR2. What if
> you are valgrinding something that actually needs it for something real?
> Are you out of luck?

According to the docs this might help:

http://valgrind.org/docs/manual/manual-core.html#manual-core.signals

If you're using signals in clever ways (for example, catching SIGSEGV,
modifying page state and restarting the instruction), you're probably
relying on precise exceptions. In this case, you will need to use
--vex-iropt-precise-memory-exns=yes.

But I've got no access to a mac until tomorrow to test it.

Greetings,
Florian

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

Re: [PHP-DEV] PHP CLI + Valgrind = FAIL

[Florian Anderiasch]

On 11/08/2011 10:34 AM, Yasuo Ohgaki wrote:
> yohgaki@esi-yasmc1$ USE_ZEND_ALLOC=0 valgrind ./sapi/cli/php -v
> ==63465== Memcheck, a memory error detector
> ==63465== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al.
> ==63465== Using Valgrind-3.6.1 and LibVEX; rerun with -h for copyright info

I was testing with valgrind 3.7.0, self-compiled, on OS X and Debian - I
suppose this is what Stas used as well.

Greetings,
Florian

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

Re: [PHP-DEV] PHP CLI + Valgrind = FAIL

[Florian Anderiasch]

On 11/08/2011 11:30 AM, Rasmus Lerdorf wrote:
> Not deferring SIGUSR2 just because valgrind on OSX doesn't like it isn't
> really an option here. We could make debug builds on OSX not defer it, I
> suppose.

I didn't want to imply we should change PHP behaviour in order to be
valgrindable :)

https://wiki.php.net/rfc/zendsignals is still listed as "Under
discussion", but at least the signals listed under "Startup" are already
registered it seems.

I just learned that the various signals on Linux on Darwin have totally
different numbers than on Linux, but
$ valgrind /bin/bash
shows the same behaviour as PHP, so I suspect it's really valgrind, as
seen in memcheck/tests/sigkill.stderr.exp-darwin,92 in valgrind 3.7 source.

I'm not directly able to see what they're doing different on OS X than
on Linux, and if it makes sense at all - that's for someone with more
expertise in C code review I guess :)

Greetings,
Florian

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

Re: [PHP-DEV] PHP CLI + Valgrind = FAIL

[Florian Anderiasch]

On 11/08/2011 06:23 AM, Stas Malyshev wrote:
> Indeed, valgrind says:
> ==47112== Warning: ignored attempt to set SIGUSR2 handler in sigaction();
> ==47112==  the SIGUSR2 signal is used internally by Valgrind
> 
> So it looks like it won't allow PHP to override signal handlers. The
> questions here are - does anybody sees same problem (on Mac or other
> systems) and should PHP really fail in this scenario? Not having the
> possibility to run PHP under valgrind kind of sucks.

Hi,
just poked around a bit on this.
In the valgrind 3.7 source, in tests/sigkill.c you can see that they
skip signal 32 and 33 on Linux, and SIGUSR2 seems to be different on
Darwin than on Linux.

We use SIGUSR2 in these parts of the 5.4 source:

% find . -name "*.[ch]" | xargs grep USR2

./Zend/zend_signal.c:
static int zend_sigs[] = { TIMEOUT_SIG, SIGHUP, SIGINT, SIGQUIT,
SIGTERM, SIGUSR1, SIGUSR2 };
./ext/pcntl/pcntl.c:
REGISTER_LONG_CONSTANT("SIGUSR2",  (long) SIGUSR2, CONST_CS |
CONST_PERSISTENT);
./sapi/fpm/fpm/fpm_signals.c:
#ifdef SIGUSR2
[...]
./sapi/fpm/fpm/fpm_events.c:
case '2' :  /* SIGUSR2 */
[...]

So it looks like only FPM uses it for more than the default behaviour of
"terminate", from a quick glance.

Greetings,
Florian

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

Re: [PHP-DEV] unsolved issues

[Florian Anderiasch]

On 11/07/2011 07:52 AM, Stas Malyshev wrote:
> Could we address these before RC?

Hi,
there's this one bug https://bugs.php.net/bug.php?id=55121 that (as you
can see in the history) went a bit back and forth - and as of now
neither laruence nor I can reproduce it anymore.

It's either a segfault in the integrated webserver or file upload not
working. Both not deal-breaking imho, but it would be very nice to fix
them at latest before 5.4 gets shipped.

So if anyone could take a quick 5min to try to reproduce it, so we can
either find a better fix or declare it closed if more then 2-3 people
(as of now) cannot reproduce it.

Thanks,
Florian

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

Re: [PHP-DEV] SVN Account Request: cpriest

[Florian Anderiasch]

On 11/06/2011 02:07 AM, Clint Priest wrote:
> Interested in developing the PHP language.  I know c and c++ and would like 
> to contribute.

Hi,

this document describes how to start contributing to PHP:

http://svn.php.net/viewvc/php/php-src/trunk/README.SUBMITTING_PATCH?view=markup

Greetings,
Florian

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

Re: [PHP-DEV] [RFC] -W option for CLI "strict mode"

[Florian Anderiasch]

On 05.07.2011 18:24, Adam Harvey wrote:
>> However I guess it's more useful to have something like Perl does with -W.
> 
> It does really combine -w and -W from Perl, now I think about it.

What would be the options of mimicking -W as closely as possible?

There was this extension (iirc named scream and by Johannes) that
unsilenced @calls. Would this fit into as well?

I suppose some kind of monkeypatching
error_reporting/ini_set/whatIforgot to ignore all settings in the
script(s) would be anything from bad style to downright impossible, but
maybe someone has a brilliant idea to enhance this.

Greetings,
Florian

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

Re: [PHP-DEV] [PATCH] Small patch for CLI server regarding IPv6 and commandline parsing

[Florian Anderiasch]

On 29.06.2011 19:09, Christopher Jones wrote:
> Can you log a bug and attach the patch?
> 
> Chris
> 
There you go after bugs is back \o/

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

Greetings,
Florian

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

Re: [PHP-DEV] [PATCH] Small patch for CLI server regarding IPv6 and commandline parsing

[Florian Anderiasch]

Oops,
please have a look at the correct diff :)

http://pastie.org/2138369

--- sapi/cli/php_cli_server.c.old   2011-06-29 09:08:28.971479778 +0200
+++ sapi/cli/php_cli_server.c   2011-06-28 19:43:23.123167815 +0200
@@ -1799,13 +1799,28 @@
}

{
-   char *p = strchr(host, ':');
-   if (p) {
+   char *p = strrchr(host, ':');
+   char *end = strchr(host, ']');
+   if (p && (end == NULL || p > end)) {
*p++ = '\0';
port = strtol(p, &p, 10);
+   if (port < 0 || port > 65535) {
+   printf(stderr, "Invalid built-in web-server 
addr:port argument\n");
+   return FAILURE;
+   }
}
}

+   if (*host == '[' && host[strlen(host)-1] == ']') {
+   char v6address[40];
+   int success = sscanf(host, "\[%39[^]]\]", v6address);
+   if (success != 1) {
+   php_cli_server_logf("Failed to listen on %s:%d (reason: 
%s)"
TSRMLS_CC, host, port, errstr ? errstr: "?");
+   return FAILURE;
+   }
+   host = pestrdup(v6address, 1);
+   }
+
server_sock = php_network_listen_socket(host, &port, SOCK_STREAM,
&server->address_family, &server->socklen, &errstr TSRMLS_CC);
if (server_sock == SOCK_ERR) {
php_cli_server_logf("Failed to listen on %s:%d (reason: %s)"
TSRMLS_CC, host, port, errstr ? errstr: "?");


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

[PHP-DEV] [PATCH] Small patch for CLI server regarding IPv6 and commandline parsing

[Florian Anderiasch]

Hi all,
as of yesterday the CLI server didn't seemed to listen to addr:port in
format like [::1]:3000, so here's a patch.

Feedback very welcome.

Greetings,
Florian

See http://pastie.org/2138304 or this:

--- php_cli_server.c.orig   2011-06-28 19:43:23.123167815 +0200
+++ php_cli_server.c2011-06-29 09:08:28.971479778 +0200
@@ -1799,28 +1799,13 @@
 }

 {
-char *p = strrchr(host, ':');
-char *end = strchr(host, ']');
-if (p && (end == NULL || p > end)) {
+char *p = strchr(host, ':');
+if (p) {
 *p++ = '\0';
 port = strtol(p, &p, 10);
-if (port < 0 || port > 65535) {
-printf(stderr, "Invalid built-in
web-server addr:port argument\n");
-return FAILURE;
-}
 }
 }

-if (*host == '[' && host[strlen(host)-1] == ']') {
-char v6address[40];
-int success = sscanf(host, "\[%39[^]]\]", v6address);
-if (success != 1) {
-php_cli_server_logf("Failed to listen on %s:%d
(reason: %s)" TSRMLS_CC, host, port, errstr ? errstr: "?");
-return FAILURE;
-}
-host = pestrdup(v6address, 1);
-}
-
 server_sock = php_network_listen_socket(host, &port,
SOCK_STREAM, &server->address_family, &server->socklen, &errstr TSRMLS_CC);
 if (server_sock == SOCK_ERR) {
 php_cli_server_logf("Failed to listen on %s:%d (reason:
%s)" TSRMLS_CC, host, port, errstr ? errstr: "?");

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

[PHP-DEV] from __future__ import...

[Florian Anderiasch]

Hello,
there's something that's been on my mind for a while, but I've not yet
fully managed to think more about feasibility.

For those who didn't know this already, Python has a pseudo-module
__future__ that allows BC breaks in future versions to be anticipated.

I'll quote an example:

===
Under 2.0, it prints:
x is 42
Nested scopes[2] are being introduced in 2.1.
But under 2.1, it still prints
x is 42
and also generates a warning.

In 2.2, and also in 2.1 *if*
"from __future__ import nested_scopes" is
included at the top of scope.py, it prints
x is 666
===

The whole process is detailed in PEP-236 [1].

So, I do know we're in dealing with BC differently than python does and
even the import methodology may make slightly less sense with namespaces...

...but did everyone ever put some thought into this?

- As this is done at compile-time, wouldn't it be a
  glorified auto-prepend on steroids?
- Would it imply backporting much stuff? probably not possible,
  like for example "traits in 5.3"
- Would it be worth some effort in PHP itself so that people could
  code forward-compatible in 5.x to anticipate BC breaks in 5.x+1?
- Does it make sense at all? :)

Just some food for thought.

Greetings,
Florian


[1] http://www.python.org/dev/peps/pep-0236/

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

Re: [PHP-DEV] [IDEA/PRE-RFC] PHP Core Mentorship Program

[Florian Anderiasch]

Hey all,
while I share some of Pierre's concerns I also think this is a great
idea. Fresh contributors always put some extra weight on the people
already on the project, that's nothing new and not exclusive to open
source projects. I do think that a concerted effort like this proposed
program could really help in that way.

And as long as some people are available as mentors there's no harm in
trying.
To get back to the "improve docs" part I'd gladly collect the artifacts,
mails, wiki entries, etc of this effort and try help create this
"contribute page" Pierre spoke of.

Greetings,
Florian

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

Re: [PHP-DEV] [RFC] Improved parser error message

[Florian Anderiasch]

On 16.05.2011 14:15, Felipe Pena wrote:
> Other examples and patch at:
> https://wiki.php.net/rfc/improved-parser-error-message

Just for completeness, here's the lengthy thread
we had in October 2010 about this:

http://news.php.net/php.internals/49978

FWIW, I like the Easter Egg :)

Greetings,
Florian

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

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

[Florian Anderiasch]

On 27.03.2010 13:13, Ferenc Kovacs wrote:
> I like the way how the debian guys elect the project leader:
> http://en.wikipedia.org/wiki/Debian#Project_organization
> http://en.wikipedia.org/wiki/File:Debian-organigram.png
> http://en.wikipedia.org/wiki/Schulze_method

Hi,
while I do agree that they have a decent model there, I think this would
be very hard to implement in PHP, even when ignoring the technical hurdles.

The core differences I'm seeing here is:

- DPL (Debian Project Leader) != PHP RM (Release Manager)
  It's actually not even remotely comparable.
- It's for one year and also a somewhat representative role.
  I've not seen many RMs stand out to the public as "representatives",
  but that's absolutely ok. It's mostly a technical position.
- Debian has a decently high entry hurdle, before you're going to be a
  DD (Debian Developer) there's a lot of work and especially a lot of
  time involved. In PHP we've much more often have people pop out of
  nowhere, do a ton of work and vanish again.
- Much in the Debian process is based on your "trusted @debian.org GPG
  key" - that's also used for any election talk and voting  - afaik.
  OK, we got SVN accounts, that'd probably be a reasonable voting
  platform.
- Although there are a lot more people involved in Debian than in PHP
  (at least that's my impression) I think the people inside the PHP
  project reading and deciding here is much smaller. To me this doesn't
  look as a "everyone with a @php.net email address==svn account can
  vote" would be anywhere close to the decisions ever made.

TLDNR:
I don't see many paralles to even start a decent comparison, PHP simply
does not have this level of democracy where someone contributing some
translated pages has the same vote as someone having been RM and doing
core work for years.

Greetings,
Florian

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

[PHP-DEV] A patch for bug 44331

[Florian Anderiasch]

Hi there,
I've tried to come up with a solution for

Formatting option for json_encode
http://bugs.php.net/bug.php?id=44331

Any comments are highly welcome :)

the patch is against the PHP_5_3 branch as HEAD changes quite some
unicode stuff.

Greetings,
Florian
--- ext/json/json.c.orig2009-12-09 22:15:33.0 +0100
+++ ext/json/json.c 2009-12-09 22:48:04.0 +0100
@@ -42,6 +42,7 @@
 #define PHP_JSON_HEX_APOS  (1<<2)
 #define PHP_JSON_HEX_QUOT  (1<<3)
 #define PHP_JSON_FORCE_OBJECT  (1<<4)
+#define PHP_JSON_FORMAT_OUTPUT (1<<5)
 
 #define PHP_JSON_OUTPUT_ARRAY 0
 #define PHP_JSON_OUTPUT_OBJECT 1
@@ -81,6 +82,7 @@
REGISTER_LONG_CONSTANT("JSON_HEX_APOS", PHP_JSON_HEX_APOS, CONST_CS | 
CONST_PERSISTENT);
REGISTER_LONG_CONSTANT("JSON_HEX_QUOT", PHP_JSON_HEX_QUOT, CONST_CS | 
CONST_PERSISTENT);
REGISTER_LONG_CONSTANT("JSON_FORCE_OBJECT", PHP_JSON_FORCE_OBJECT, 
CONST_CS | CONST_PERSISTENT);
+   REGISTER_LONG_CONSTANT("JSON_FORMAT_OUTPUT", PHP_JSON_FORMAT_OUTPUT, 
CONST_CS | CONST_PERSISTENT);
 
REGISTER_LONG_CONSTANT("JSON_ERROR_NONE", PHP_JSON_ERROR_NONE, CONST_CS 
| CONST_PERSISTENT);
REGISTER_LONG_CONSTANT("JSON_ERROR_DEPTH", PHP_JSON_ERROR_DEPTH, 
CONST_CS | CONST_PERSISTENT);
@@ -172,9 +174,10 @@
 }
 /* }}} */
 
-static void json_encode_array(smart_str *buf, zval **val, int options 
TSRMLS_DC) /* {{{ */
+static void json_encode_array(smart_str *buf, zval **val, int options, int 
nesting_level TSRMLS_DC) /* {{{ */
 {
-   int i, r;
+   int i, r, fmt;
+   int ii = 0;
HashTable *myht;
 
if (Z_TYPE_PP(val) == IS_ARRAY) {
@@ -184,6 +187,7 @@
myht = Z_OBJPROP_PP(val);
r = PHP_JSON_OUTPUT_OBJECT;
}
+   fmt = ( options & PHP_JSON_FORMAT_OUTPUT) ? 1 : 0;
 
if (myht && myht->nApplyCount > 1) {
php_error_docref(NULL TSRMLS_CC, E_WARNING, "recursion 
detected");
@@ -195,6 +199,9 @@
smart_str_appendc(buf, '[');
} else {
smart_str_appendc(buf, '{');
+   if (fmt) {
+   smart_str_appendc(buf, '\n');
+   }
}
 
i = myht ? zend_hash_num_elements(myht) : 0;
@@ -227,8 +234,7 @@
} else {
need_comma = 1;
}
- 
-   php_json_encode(buf, *data, options 
TSRMLS_CC);
+   php_json_encode_ex(buf, *data, options, 
nesting_level+1 TSRMLS_CC);
} else if (r == PHP_JSON_OUTPUT_OBJECT) {
if (i == HASH_KEY_IS_STRING) {
if (key[0] == '\0' && 
Z_TYPE_PP(val) == IS_OBJECT) {
@@ -241,27 +247,43 @@
 
if (need_comma) {
smart_str_appendc(buf, 
',');
+   if (fmt) {
+   
smart_str_appendc(buf, '\n');
+   }
} else {
need_comma = 1;
}
 
+   if (fmt) {
+   for 
(ii=0;ii<=nesting_level;ii++) {
+   
smart_str_appendc(buf, '\t');
+   }
+   }
json_escape_string(buf, key, 
key_len - 1, options TSRMLS_CC);
smart_str_appendc(buf, ':');
 
-   php_json_encode(buf, *data, 
options TSRMLS_CC);
+   php_json_encode_ex(buf, *data, 
options, nesting_level+1 TSRMLS_CC);
} else {
if (need_comma) {
smart_str_appendc(buf, 
',');
+   if (fmt) {
+   
smart_str_appendc(buf, '\n');
+   }
} else {
need_comma = 1;
}
 
+   if (fmt) {
+   for 
(ii=0;ii<=nesting_level;ii++) {
+   

[PHP-DEV] Patch for Bug #49757

[Florian Anderiasch]

Hello,
I've tried to fix http://bugs.php.net/bug.php?id=49757

As it's my first patch in c, any reviews and suggestions would be very
welcome.

Greetings,
Florian

Index: ext/standard/basic_functions.c
===
--- ext/standard/basic_functions.c  (revision 289129)
+++ ext/standard/basic_functions.c  (working copy)
@@ -3932,6 +3932,7 @@
int ip_len;
unsigned long n;
struct in_addr myaddr;
+   char str[INET_ADDRSTRLEN];
 
if (zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC, "s", &ip, &ip_len) 
== FAILURE) {
return;
@@ -3940,7 +3941,14 @@
n = strtoul(ip, NULL, 0);
 
myaddr.s_addr = htonl(n);
-   RETURN_STRING(inet_ntoa(myaddr), 1);
+
+#ifdef HAVE_INET_NTOP
+   inet_ntop(AF_INET, &myaddr, str, INET_ADDRSTRLEN);
+#else
+   str = inet_ntoa(myaddr);
+#endif
+
+   RETURN_STRING(str, 1);
 }
 /* }}} */
 
Index: ext/standard/basic_functions.h
===
--- ext/standard/basic_functions.h  (revision 289129)
+++ ext/standard/basic_functions.h  (working copy)
@@ -59,6 +59,7 @@
 #endif
 PHP_FUNCTION(ip2long);
 PHP_FUNCTION(long2ip);
+#define INET_ADDRSTRLEN 16
 
 /* system functions */
 PHP_FUNCTION(getenv);
Index: ext/standard/basic_functions.c
===
--- ext/standard/basic_functions.c  (revision 289129)
+++ ext/standard/basic_functions.c  (working copy)
@@ -3923,6 +3923,7 @@
int ip_len;
unsigned long n;
struct in_addr myaddr;
+   char str[INET_ADDRSTRLEN];
 
if (zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC, "s", &ip, &ip_len) 
== FAILURE) {
return;
@@ -3931,7 +3932,14 @@
n = strtoul(ip, NULL, 0);
 
myaddr.s_addr = htonl(n);
-   RETURN_RT_STRING(inet_ntoa(myaddr), ZSTR_DUPLICATE);
+
+#ifdef HAVE_INET_NTOP
+   inet_ntop(AF_INET, &myaddr, str, INET_ADDRSTRLEN);
+#else
+   str = inet_ntoa(myaddr);
+#endif
+
+   RETURN_RT_STRING(str, ZSTR_DUPLICATE);
 }
 /* }}} */
 
Index: ext/standard/basic_functions.h
===
--- ext/standard/basic_functions.h  (revision 289129)
+++ ext/standard/basic_functions.h  (working copy)
@@ -59,6 +59,7 @@
 #endif
 PHP_FUNCTION(ip2long);
 PHP_FUNCTION(long2ip);
+#define INET_ADDRSTRLEN 16
 
 /* system functions */
 PHP_FUNCTION(getenv);

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

[PHP-DEV] patch for bug #47839

[Florian Anderiasch]

Hello,
bug #47839

Here's a small patch, trying to add the manual page as well (got karma
there) once I figured out how insert a new one, but I can't access
php-src/UPGRADING obviously.

Greetings,
Florian

--- UPGRADING.old   2009-04-18 07:22:26.0 -0400
+++ UPGRADING   2009-04-18 07:23:05.0 -0400
@@ -287,6 +287,7 @@
   mysqli_get_connection_stats()
   mysqli_poll()
   mysqli_reap_async_query()
+   - Network: gethostname()
- OpenSSL: openssl_random_pseudo_bytes()
- PCNTL:   pcntl_signal_dispatch()
   pcntl_sigprocmask()

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

Re: [PHP-DEV] phps line numbering

[Florian Anderiasch]

arg, I'm wrong - ignore me please

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

Re: [PHP-DEV] phps line numbering

[Florian Anderiasch]

Kevin Waterson schrieb:
> Addition of line numbering to phps
> This is a rather simple addition and will be benificial to all who use phps
> for debugging and/or displaying code. Its a simple diff to zend_highlight.c

Hello Kevin,
I haven't tested this - but if phps output is numbered, it will be
completely cluttered and you can't copy-paste anymore. Exactly when
*displaying* code so that people can adapt it that's a quite bad idea
then imho. Rather add another extension and leave .phps like it is.

Greetings,
Florian

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

Re: [PHP-DEV] is_int/is_numeric possible bug

[Florian Anderiasch]

Gareth Ardron wrote:
> Hi.
> 
> Think I've just stumbled upon a possible bug with is_int.
Hello Gareth,
if I'm not mistaken, $_REQUEST['days'] is a string, and unless you use

if (!is_int(intval($_REQUEST['days'])) || $_REQUEST['days'] < 0) {

I see no problem in is_int taking a string with numerals inside as not int.

Greetings,
Florian

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

[PHP-DEV] CVS Account Request: fa

[Florian Anderiasch]

I would like to help with translating the manual to German.
FYI: This script on de2.php.net produced an error (failed to open socket on 
master.php.net)

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