On Thu, Feb 23, 2012 at 9:03 PM, Stas Malyshev smalys...@sugarcrm.comwrote:
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
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 sbeat...@ubuntu.com wrote:
Hi Kousuke,
On Thu, Feb 16, 2012 at 06:14:51PM +0900,
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]
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 special
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 could
Hi,
2012/2/24 Rasmus Schultz ras...@mindplay.dk
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
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
2012/2/24 Dmitri Snytkine dsnytk...@ultralogistics.com
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
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 dani...@analysisandsolutions.com
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 keis...@gmail.com
On 24/02/12 00:36, Kris Craig wrote:
Hmm that's a fascinating
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
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
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
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
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 smalys...@sugarcrm.comwrote:
Hi!
If you're planning to have a PHP 5.4 RC9, should Apache 2.4 support be
included? This would reduce any negative
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).
On Fri, 24 Feb 2012 20:57:50 +0100, Stas Malyshev smalys...@sugarcrm.com
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
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 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
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
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
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.
hi,
On Fri, Feb 24, 2012 at 9:30 PM, Tom Boutell t...@punkave.com 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
On Fri, Feb 24, 2012 at 3:47 PM, Pierre Joye pierre@gmail.com 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
On Fri, Feb 24, 2012 at 9:46 PM, Sebastian Bergmann sebast...@php.net 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
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 t...@punkave.com wrote:
On Fri, Feb 24, 2012 at 3:47 PM, Pierre Joye pierre@gmail.com wrote:
that's why
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
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 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
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 knowing
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
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
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 have
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 somebody
Any further thoughts on this?
--Kris
On Mon, Feb 20, 2012 at 5:36 PM, Kris Craig kris.cr...@gmail.com 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
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
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 / easy
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 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
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
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 way.
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 arguments
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
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 $_GET,
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 c...@l-i-e.com wrote:
On Mon, February 20, 2012 7:02 pm, Kris Craig
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
On Fri, Feb 24, 2012 at 2:40 PM, Larry Garfield la...@garfieldtech.com wrote:
To me, it's just a request for some content, and in a REST API that's
read-only, I just don't care if the consumer sends their request as
GET or POST. I'll cheerfully give them what they wanted.
Except that per
On 2/24/12 4:48 PM, Ronald Chmara wrote:
On Fri, Feb 24, 2012 at 2:40 PM, Larry Garfieldla...@garfieldtech.com wrote:
To me, it's just a request for some content, and in a REST API that's
read-only, I just don't care if the consumer sends their request as
GET or POST. I'll cheerfully give
On Fri, Feb 24, 2012 at 5:40 PM, Larry Garfield la...@garfieldtech.com 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
On Fri, Feb 24, 2012 at 2:54 PM, Larry Garfield la...@garfieldtech.com wrote:
On 2/24/12 4:48 PM, Ronald Chmara wrote:
On Fri, Feb 24, 2012 at 2:40 PM, Larry Garfieldla...@garfieldtech.com
Except that per HTTP, GET and POST are completely different operations.
One
is idempotent and
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
On 2/24/12 5:04 PM, Ronald Chmara wrote:
On Fri, Feb 24, 2012 at 2:54 PM, Larry Garfieldla...@garfieldtech.com wrote:
On 2/24/12 4:48 PM, Ronald Chmara wrote:
On Fri, Feb 24, 2012 at 2:40 PM, Larry Garfieldla...@garfieldtech.com
Except that per HTTP, GET and POST are completely different
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 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
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 environments are
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
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
On 25 February 2012 00:18, Reindl Harald h.rei...@thelounge.net 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
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
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
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;
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,
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
-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 language for you, so
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
66 matches
Mail list logo
