Steph Fox wrote:
> Hi Derick,
>
>> I see another issue after reading this, and that is that it makes it
>> much harder for users to depend on specific extensions just being always
>> available by default. It's important for application distributers to
>> have this core set of extensions to rely on
Hi Derick,
I see another issue after reading this, and that is that it makes it
much harder for users to depend on specific extensions just being always
available by default. It's important for application distributers to
have this core set of extensions to rely on. It's annoying enough that
som
On Mon, 2008-02-04 at 14:23 +, ehl lhe wrote:
> >Perhaps you should look into PHP 5.3 which has a lot better support for
> >per-host/per-dir php.ini values. In 5.3 you can specify stuff in the
> >global php.ini file with special sections which only affect the certain
> >host / directory and tho
>Perhaps you should look into PHP 5.3 which has a lot better support for
>per-host/per-dir php.ini values. In 5.3 you can specify stuff in the
>global php.ini file with special sections which only affect the certain
>host / directory and those can not be overwritten anywhere.
>Also there's the use
Perhaps you should look into PHP 5.3 which has a lot better support for
per-host/per-dir php.ini values. In 5.3 you can specify stuff in the
global php.ini file with special sections which only affect the certain
host / directory and those can not be overwritten anywhere.
Also there's the user.ini
hi steph,
well, i'm trying to use apache's mod vhost_alias, which doesn't allow to use
e.g.
php_admin_value open_basedir /some/path/%2
...which means that %2 is usually replaced with a part of the requested URI,
but that does not work, such variables like %2 are interpreded for
vhost_alias-v
On 04.02.2008, at 11:38, Marcus Boerger wrote:
Hello Ben,
None of this is necessary though. What I proposed was moving
extension
development from php-src to PECL an dthen bundle what we see fit
into the
distribution just as we do now, whith the RM having the last say
what goes
in and wh
Hello Ben,
None of this is necessary though. What I proposed was moving extension
development from php-src to PECL an dthen bundle what we see fit into the
distribution just as we do now, whith the RM having the last say what goes
in and what not. In my proposal we would only put stuff into php-
PHP 6 Bug Database summary - http://bugs.php.net
Num Status Summary (61 total including feature requests)
===[*General Issues]==
26771 Suspended register_tick_funtions crash under threaded webservers
===
At 04:33 AM 2/4/2008, Derick Rethans wrote:
On Sun, 3 Feb 2008, Steph Fox wrote:
> Everything else - the fashionistas (JSON, xmlreader/writer) and
the downright
> useful for some but not all (fileinfo, json, com_dotnet, posix)
and the quirky
> stuff (pretty much anything Sara came up with) -
On Sun, 3 Feb 2008, Steph Fox wrote:
> Everything else - the fashionistas (JSON, xmlreader/writer) and the downright
> useful for some but not all (fileinfo, json, com_dotnet, posix) and the quirky
> stuff (pretty much anything Sara came up with) - should be in PECL.
I see another issue after rea
On Sat, 2 Feb 2008, Steph Fox wrote:
> 1) Distribution woes need to end. With the work Greg's been doing lately on
> PHP_Archive/Phar, that's very close to being attainable now in the physical
> 'getting PECL'd extensions out to people' sense, but unless people are running
> CLI or CGI or have acc
Hi,
Pierre Joye wrote:
> Hi,
>
> I think the biggest myths in this CLA discussion are:
>
>>> The main realization was that the vendors could not co-operate with
>>> each other on code without a CLA in place, and that some of them would
>>> not be able to co-operate with the community without a C
On Sun, 3 Feb 2008, Stanislav Malyshev wrote:
> > Like I mentioned before (I think), it should not return an empty string of
> > course because programmatically it's not possible to check for this. As most
> > of our functions return false in those cases, so should this function.
>
> AFAIR false
On Sun, 3 Feb 2008, Steph Fox wrote:
> > > Well thanks to a separate PEAR channel, we have all the infrastructure
> > > easily setup to have a different place for users to pick up the code. Or
> > > are you more concerned about the CVS, than the distribution of the
> > > packages?
>
> I don't ha
On Sun, 2008-02-03 at 10:56 +0100, Lukas Kahwe Smith wrote:
> I am also not sure if including mysqlnd in PHP core is the way to go.
> However I would not be generally opposed to including it in the PHP
> distribution.
There's a technical reason for that: It needs to be statically buildin
to wo
I'd like everything in PECL. Even the core. And yes, it is quite doable.
--Jani
On Sun, 2008-02-03 at 00:21 +0100, Marcus Boerger wrote:
> Hello Steph,
>
> what I want is php-src as minimum you can depend on. And php-default as
> release managers playground. The RM can then say what he thinks
PHP 4 Bug Database summary - http://bugs.php.net
Num Status Summary (625 total including feature requests)
===[*Compile Issues]==
43389 Open configure ignoring --without-cdb flag
===[Apa
On Fri, 1 Feb 2008, Marcus Boerger wrote:
> * Develop a PECL CLA that can optionally be used for PECL projects.
> * If necessary, adapt the PHP License, so that it works nicely
> together with the CLA.
> * The projects that want a CLA can choose between the PHP License or
> LGPL.
> * Change th
Like I mentioned before (I think), it should not return an empty string
of course because programmatically it's not possible to check for this.
As most of our functions return false in those cases, so should this
function.
AFAIR false is not valid JSON, so it would break a lot of code. Also, I
20 matches
Mail list logo
