Dmitry:
you might want to review this fix.
let me explain why crash before this fix.
when doing parse_parameter, then convert the object to string by
calling the ce->cast_object,
and passed the same pointer(although there was a separation), to
the cast_object..
then if __toStrin
> -Original Message-
> From: Lester Caine [mailto:les...@lsces.co.uk]
>
> Richard Lynch wrote:
> >> 1. Is strict typing something that we should seriously consider
> >> > implementing at some point in the foreseeable future?
> > No.
> >
> > If you want that, PHP is not the languag
Oh ok, I think I see where you're getting confused.
This problem occurs when your LoadModule statement is in a *separate* .conf
file; i.e. using the "Include" statement. APXS cannot detect this and just
sticks a LoadModule into the main .conf file. This is what causes the
duplication. It's a ve
On 02/24/2012 04:14 PM, Kris Craig wrote:
No, it happens and it's even clearly documented in APXS.
Basically, if you specify the "-a" option in APXS, it overwrites your
httpd.conf (or apache.conf or whatever it is on your system) and adds the
LoadModule line to it. In PHP's configure script,
No, it happens and it's even clearly documented in APXS.
Basically, if you specify the "-a" option in APXS, it overwrites your
httpd.conf (or apache.conf or whatever it is on your system) and adds the
LoadModule line to it. In PHP's configure script, you'll notice that "-a"
is always specified; t
On 02/24/2012 03:54 PM, Kris Craig wrote:
LoadModule clashes still happen in the current releases. I haven't
tested it on 5.5-dev but it definitely exists on 5.3.x. I have yet
to test it on 5.4 but I'm not aware of any changes there that
would've affected this. So this is an existing problem,
Yeah since we pretty much rely on APXS to do the httpd.conf stuff, we're
really limited in terms of what we can do. That is, unless we want to
start manually doing this in the configure script in lieu of APXS, though
I'm not sure that would be worth the trouble and the overhead.
LoadModule clashe
On 25 February 2012 00:18, Reindl Harald wrote:
>
>
> > Again, why? Because they will skip 5.4.0 in production. And 2.4.1 too.
>
> you are missing the fact that many consider testing the new major versions
> and many of them will only start testing PHP 5.4 in combination with
> Apache 2.4
>
> ...
On 02/24/2012 02:38 PM, Kris Craig wrote:
Thanks for the input! You're right, I'll go ahead and clarify that in the
RFC.
I'll probably initiate voting on Monday unless something changes between
now and then.
--Kris
The real issue with the PHP install is that it doesn't add "AddType"
or "Se
On 02/24/2012 02:38 PM, Kris Craig wrote:
Thanks for the input! You're right, I'll go ahead and clarify that in the
RFC.
I'll probably initiate voting on Monday unless something changes between
now and then.
--Kris
Re https://wiki.php.net/rfc/apxs-loadmodule
The RFC needs more work before
Am 25.02.2012 00:09, schrieb Bostjan Skufca:
> Despite the fact that Apache HTTPD's website says that 2.4.1 "represents
> the best available version of Apache HTTP Server", and that PHP 5.4.0 will
> probably also bear similar notation (guesswork here!), very few (if any!)
> production environment
On 2/24/12 4:55 PM, Jeremiah Dodds wrote:
Except that per HTTP, GET and POST are completely different operations. One
is idempotent and cacheable, the other is not idempotent and not cacheable.
I very much care which someone is using.
Correct me if I'm wrong, but you're referring to the HTT
On 24/02/12 19:35, Kris Craig wrote:
> Could you elaborate on that a little? I.e. "as an interface for the
> call". I'm not sure what you mean by that. If you could provide a
> quick example, that would be awesome! =)
>
> --Kris
Hi Kris,
You're right it wasn't clearly expresseded. Lets see if I can
On 2/24/12 5:04 PM, Ronald Chmara wrote:
On Fri, Feb 24, 2012 at 2:54 PM, Larry Garfield wrote:
On 2/24/12 4:48 PM, Ronald Chmara wrote:
On Fri, Feb 24, 2012 at 2:40 PM, Larry Garfield
Except that per HTTP, GET and POST are completely different operations.
One
is idempotent and cacheable,
Despite the fact that Apache HTTPD's website says that 2.4.1 "represents
the best available version of Apache HTTP Server", and that PHP 5.4.0 will
probably also bear similar notation (guesswork here!), very few (if any!)
production environments are going to even bother considering running first
mi
On Fri, Feb 24, 2012 at 2:54 PM, Larry Garfield wrote:
> On 2/24/12 4:48 PM, Ronald Chmara wrote:
>>
>> On Fri, Feb 24, 2012 at 2:40 PM, Larry Garfield
>>> Except that per HTTP, GET and POST are completely different operations.
>>> One
>>> is idempotent and cacheable, the other is not idempotent
On Fri, Feb 24, 2012 at 5:40 PM, Larry Garfield wrote:
> On 2/24/12 4:34 PM, Richard Lynch wrote:
>>
>> On Fri, February 24, 2012 4:16 pm, Larry Garfield wrote:
>>>
>>> On 2/24/12 3:28 PM, Richard Lynch wrote:
>>> Because GET and POST are not even remotely the same thing and treating
>>> them as c
On 2/24/12 4:48 PM, Ronald Chmara wrote:
On Fri, Feb 24, 2012 at 2:40 PM, Larry Garfield wrote:
To me, it's just a request for some content, and in a REST API that's
read-only, I just don't care if the consumer sends their request as
GET or POST. I'll cheerfully give them what they wanted.
Ex
On Fri, Feb 24, 2012 at 2:40 PM, Larry Garfield wrote:
>> To me, it's just a request for some content, and in a REST API that's
>> read-only, I just don't care if the consumer sends their request as
>> GET or POST. I'll cheerfully give them what they wanted.
> Except that per HTTP, GET and POST a
On 2/24/12 4:34 PM, Richard Lynch wrote:
On Fri, February 24, 2012 4:16 pm, Larry Garfield wrote:
On 2/24/12 3:28 PM, Richard Lynch wrote:
Because GET and POST are not even remotely the same thing and treating
them as completely interchangeable is a bug in the first place.
We'll have to agree
Thanks for the input! You're right, I'll go ahead and clarify that in the
RFC.
I'll probably initiate voting on Monday unless something changes between
now and then.
--Kris
On Fri, Feb 24, 2012 at 2:24 PM, Richard Lynch wrote:
> On Mon, February 20, 2012 7:02 pm, Kris Craig wrote:
> > Openin
On Friday, February 24, 2012 at 5:16 PM, Larry Garfield wrote:
> On 2/24/12 3:28 PM, Richard Lynch wrote:
> > On Wed, February 22, 2012 9:10 am, Michael Morris wrote:
> > > $_REQUEST does nothing of the sort, and it's use is dangerous in
> > > RESTful architecture. $_REQUEST is a smash together of
On Fri, February 24, 2012 4:16 pm, Larry Garfield wrote:
> On 2/24/12 3:28 PM, Richard Lynch wrote:
> Because GET and POST are not even remotely the same thing and treating
> them as completely interchangeable is a bug in the first place.
We'll have to agree to disagree here.
To me, it's just a r
Woops that was a typo lol. I meant to put "and a" between the two.
I hear that a lot; i.e. "If you want static typing, use Java."
Unfortunately, that dismissive answer has not worked too well over the
years, has it? People are still clamoring for this, and I think making
some very valid argumen
On Mon, February 20, 2012 7:02 pm, Kris Craig wrote:
> Opening discussion on RFC pertaining to adding a new option to the
> configure script with regard to how/whether APXS touches the
> httpd.conf
> file.
>
> This is my first RFC post so please go easy on me if I screwed-up on
> procedure in any w
Richard Lynch wrote:
1. Is strict typing something that we should seriously consider
> implementing at some point in the foreseeable future?
No.
If you want that, PHP is not the language for you, so just go use Java
and JSP.
I'm not being rude nor abusive: If anyone dislikes the way P
On 2/24/12 3:28 PM, Richard Lynch wrote:
On Wed, February 22, 2012 9:10 am, Michael Morris wrote:
$_REQUEST does nothing of the sort, and it's use is dangerous in
RESTful architecture. $_REQUEST is a smash together of $_GET, $_POST
and $_COOKIE, in that order but the php.ini directive can chang
On Thu, February 23, 2012 1:21 pm, Kris Craig wrote:
>1. Is strict typing something that we should seriously consider
>implementing at some point in the foreseeable future?
No.
If you want that, PHP is not the language for you, so just go use Java
and JSP.
I'm not being rude nor abusive:
On Wed, February 22, 2012 3:45 am, Flavius Aspra wrote:
> On 02/22/2012 07:29 AM, Rasmus Lerdorf wrote:
>> complicated optimization passes or any of those things
>
> Would such things be welcome/needed in the engine or as an extension?
Note that he said "complicated" :-)
There are many trivial /
Hi!
no because both PHP 5.4 and Apache 2.4 was devel-versions for a long time
It may be anywhere "for a long time", but it was raised here first time
today, as far as I know. It's too late for 5.4.0, there's no point
talking about it, this ship has sailed.
But for the future, if you (not mea
Any further thoughts on this?
--Kris
On Mon, Feb 20, 2012 at 5:36 PM, Kris Craig wrote:
> @Johannes Agreed. That was one of the reasons I decided to make the
> existing behavior (i.e. "-a") the default.
>
> I haven't independently confirmed that issue in APXS but I have heard it
> mentioned b
Am 24.02.2012 20:57, schrieb Stas Malyshev:
> Hi!
>
>> If you're planning to have a PHP 5.4 RC9, should Apache 2.4 support be
>> included? This would reduce any negative user sentiment that "PHP 5.4
>> doesn't even support the latest Apache".
>
> Latest Apache is about 3 days old now :) If som
On Tue, February 21, 2012 11:49 pm, Deepak Balani wrote:
> I am think(actually drafting) about the compilation system of PHP
> scripts.
> I want to make a native C extension which is able to compile the
> scripts in
> the Zend Engines opcodes and execute directly when called.
>
> The extension may
Regardless, I think this part of the conversation is pointless. I
personally couldn't care less whether anybody thinks we're supporting new
Apache builds quickly enough or whose fault it is if the newest one doesn't
make it into the current build. The finger pointing is just a petty
distraction t
On 24/02/12 17:46, Dmitri Snytkine wrote:
> In order to intoduce the enum into php, 'enum' will have to be a keyword like
> 'class', 'interface', etc.
>
> Just a thought, but could there be a problem with using the new keyword
> 'enum' in php. I don't think it's currently a reserved word, so it
On Wed, February 22, 2012 9:10 am, Michael Morris wrote:
> $_REQUEST does nothing of the sort, and it's use is dangerous in
> RESTful architecture. $_REQUEST is a smash together of $_GET, $_POST
> and $_COOKIE, in that order but the php.ini directive can change it.
> Hence there's no way of knowin
On Wed, February 22, 2012 8:57 am, Michael Morris wrote:
> Before writing up a full RFC I want to put out a feeler on something.
> Currently we have several input parameter objects, chief among them
> $_GET, $_POST, $_REQUEST, $_SERVER (for the client HTTP headers). All
> of them are arrays and le
Sebastian Bergmann wrote:
Maybe it just shows that less and less people care about Apache,
We have just taken over another small web hosting company ... first job move all
of the windows/ASP sites on to the local Apache/PHP framework servers so we can
add all the feature the customers have
On Fri, February 24, 2012 1:52 pm, Tom Boutell wrote:
> 2. Why does php turn on thread-safety for mod_php at all on Linux,
> given that it apparently still doesn't work very well with various
> extensions in a genuinely multithreaded situation, slows things down,
> takes more memory, and leads to p
Once a package has been fetched, pecl install does nothing else than:
phpize, make, make install
and phpize does use php-config.
On Fri, Feb 24, 2012 at 9:51 PM, Tom Boutell wrote:
> On Fri, Feb 24, 2012 at 3:47 PM, Pierre Joye wrote:
>>
>> that's why php-config exists, use it to get which ve
On Fri, Feb 24, 2012 at 9:46 PM, Sebastian Bergmann wrote:
> On 02/24/2012 03:11 PM, Christopher Jones wrote:
>>
>> I kinda think Apache 2.4 was under development a bit longer than three
>> days, so PHP could reasonably have been expected to know what was
>> coming.
We have been providing 2.3 sup
On Fri, Feb 24, 2012 at 3:47 PM, Pierre Joye wrote:
>
> that's why php-config exists, use it to get which version of PHP is
> installed or has to be used (nts, ts, php version, api version, etc.).
> That's all parameter you need to know. php-config should give you the
> path as well afair.
Then s
hi,
On Fri, Feb 24, 2012 at 9:30 PM, Tom Boutell wrote:
> Good point. Last I tried that it worked poorly - I couldn't find a
> bytecode cache that worked with it, performance was poor - and I
> switched to the Microsoft accelerator and IIS. But things may have
> changed.
APC with rwlock is fast
On 02/24/2012 03:11 PM, Christopher Jones wrote:
I kinda think Apache 2.4 was under development a bit longer than three
days, so PHP could reasonably have been expected to know what was
coming.
Maybe it just shows that less and less people care about Apache,
including PHP core developers.
--
Good point. Last I tried that it worked poorly - I couldn't find a
bytecode cache that worked with it, performance was poor - and I
switched to the Microsoft accelerator and IIS. But things may have
changed.
Doesn't really explain it on Linux...
But what I really want to know is just how to get p
These things often tend to move slowly. I'm bewildered that most Linux
repos still use PHP 5.1.
The problem is, this patch has not yet gone through the QA wash cycle.
That takes time. The only way to get it into 5.4.0, therefore, would be to
delay it even further. I needn't remind anybody here
These things often tend to move slowly. I'm bewildered that most Linux
repos still use PHP 5.1.
The problem is, this patch has not yet gone through the QA wash cycle.
That takes time. The only way to get it into 5.4.0, therefore, would be to
delay it even further. I needn't remind anybody here
On 02/24/2012 11:57 AM, Stas Malyshev wrote:
Hi!
If you're planning to have a PHP 5.4 RC9, should Apache 2.4 support be
included? This would reduce any negative user sentiment that "PHP 5.4
doesn't even support the latest Apache".
Latest Apache is about 3 days old now :) If somebody expects
As far as Windows is concerned, it is worth noting that the Apache mod_php
(i.e. ZTS) build is supported. Also, though my information is a bit
outdated, last I heard work was being done to support thread-safe PHP as an
ISAPI module on IIS, though I don't know what the status of that is.
--Kris
On Fri, 24 Feb 2012 20:57:50 +0100, Stas Malyshev
wrote:
If you're planning to have a PHP 5.4 RC9, should Apache 2.4 support be
included? This would reduce any negative user sentiment that "PHP 5.4
doesn't even support the latest Apache".
Latest Apache is about 3 days old now :)
[...]
T
Yeah I agree with Stas. I definitely think this is a good idea and should
be included, but since we're already in the RC phase for 5.4.0 and Apache
2.4 is only a few days old, I don't think it's necessary to rush it into
5.4.0 (which has already been delayed far too many times already).
Definitel
I agree with Stas on this one. Certainly not critical and needs some review
while on the trunk.
On Fri, Feb 24, 2012 at 5:57 PM, Stas Malyshev wrote:
> Hi!
>
>
> If you're planning to have a PHP 5.4 RC9, should Apache 2.4 support be
>> included? This would reduce any negative user sentiment tha
Hi!
If you're planning to have a PHP 5.4 RC9, should Apache 2.4 support be
included? This would reduce any negative user sentiment that "PHP 5.4
doesn't even support the latest Apache".
Latest Apache is about 3 days old now :) If somebody expects PHP to have
release version supporting new ma
I'm building a script that installs PHP 5.3.10 from source. One of the
steps is to install apc and mongo support via pecl. I'm building the
CGI/FastCGI version. This is on a box that formerly had mod_php
installed.
If I do 'make install' of PHP (which installs a new pecl binary) and
follow it up i
Stas, David,
If you're planning to have a PHP 5.4 RC9, should Apache 2.4 support be
included? This would reduce any negative user sentiment that "PHP 5.4
doesn't even support the latest Apache".
There is a patch attached to https://bugs.php.net/bug.php?id=61172
It needs review and wider testin
Quick note:
If you're not storing Belarusian, Macedonian, Serbian, or Ukrainian or
have no need for *proper sorting* of the extra letters in these
languages NOR the support of expansions and ligatures; I would revert
to using utf8_general_ci, which is _slightly_ faster but converts all
chars to th
Could you elaborate on that a little? I.e. "as an interface for the
call". I'm not sure what you mean by that. If you could provide a quick
example, that would be awesome! =)
--Kris
2012/2/24 Ángel González
> On 24/02/12 00:36, Kris Craig wrote:
> > Hmm that's a fascinating idea! So, and
Hi, Daniel
I'd also set the collation to *utf8_unicode_ci*. Here's a link to the full
diff of the *my.cnf* file I am using on my dev-server:
https://github.com/SimonSimCity/webserver-configuration/blob/master/mysql/patch.diff
Bye
Simon
2012/2/24 Daniel Convissor
> Hi Johannes:
>
> > 1) You sai
2012/2/24 Dmitri Snytkine
> In order to intoduce the enum into php, 'enum' will have to be a keyword
> like 'class', 'interface', etc.
>
> Just a thought, but could there be a problem with using the new keyword
> 'enum' in php. I don't think it's currently a reserved word, so it could
> potentia
In order to intoduce the enum into php, 'enum' will have to be a keyword like
'class', 'interface', etc.
Just a thought, but could there be a problem with using the new keyword 'enum'
in php. I don't think it's currently a reserved word, so it could potentially
cause problems if a script uses
Hi,
2012/2/24 Rasmus Schultz
>
> Enum-values absolutely must translate to a scalar value, probably an int -
> otherwise, how would you map an enum to a database, or submit it's value
> via a form
>
Strongly agree
I'm not sure what would be the value of a dedicated enum in PHP - I think
> enum
On 24/02/12 00:36, Kris Craig wrote:
> Hmm that's a fascinating idea! So, and please correct me if I'm
> wrong, you're saying that it might be a better approach to determine
> strict vs. dynamic typing on a per file or function basis instead of
> on a per stack basis? In other words, blah.php cou
Just a couple of quick notes...
I think that your proposal looks good, but I'd like to suggest a few
> changes. First of all, I'd like to see the association with integers
> removed. An enum instance shouldn't just be a name for an integer, it
> should be more like a singleton instance of a specia
Hi Johannes:
> 1) You said
> * /etc/my.cnf settings are (no other my.cnf files exist):
> * + default-character-set = utf8
> * + character-set-server = utf8
>
> In which section of the my.cnf file? Both for the server, or for the
> client?
[client]
default-character-set = utf8
[mysqld]
charact
Ping, the patch (https://bugs.php.net/bug.php?id=61043) is simple and
PHP 5.3-SVN is broken when using magic_quotes_gpc. Please review and
merge.
Thanks,
Ondrej
On Thu, Feb 16, 2012 at 10:51, Steve Beattie wrote:
> Hi Kousuke,
>
> On Thu, Feb 16, 2012 at 06:14:51PM +0900, Kousuke Ebihara wrote:
On Thu, Feb 23, 2012 at 9:03 PM, Stas Malyshev wrote:
> Hi!
>
>
> If I create a callback with either of these values:
>>
>> * $callback = 'Foo::bar';
>> * $callback = array('Foo', 'Bar');
>>
>> is_callable() now returns true. In PHP 5.2 and 5.3, it returned false,
>> which is what I'd exp
66 matches
Mail list logo
