On 16.02.2008, at 11:05, Marcus Boerger wrote:
Hello Steph,
so here's my take on the matters. For 5.4 we collect ideas and
implement
them. So that 5.4 comes out with mostly PECL. I guess we can collect
action
items on Lukas' wiki.
Well maybe we should target this stuff for PHP6 for
Hi Chris,
I'd like to see pecl4win merged into pecl.php.net (adding to Steph's
idea of releasing binaries on pecl.php.net), and the Windows binaries
being built from their correct branch (whatever happened to this
project - it seemed so close?)
What happened to this idea is there's no
Steph Fox wrote:
Hi Lukas,
Well maybe we should target this stuff for PHP6 for the time being. A
possible PHP 5.4 would then be a collection of PHP6 todo items that we
want to fast track, or are you guys already certain about PHP 5.4?
I'm thinking 'get the mechanisms into place in 5.4,
: Re: [PHP-DEV] [RFC] Conditional INI support
The idea makes sense too, but mix of C and SH syntax isn't good.
Dmitry.
BuildSmart wrote:
Now that what-if's are occurring in the theoretical world of intelligent
INI, what about file testing capabilities so that the following can be
used
internals@lists.php.net
Cc: [EMAIL PROTECTED]; Marcus Boerger [EMAIL PROTECTED]; Andi
Gutmans
[EMAIL PROTECTED]; Jani Taskinen [EMAIL PROTECTED]
Sent: Friday, February 15, 2008 2:38 PM
Subject: Re: [PHP-DEV] [RFC] Conditional INI support
The idea makes sense too, but mix of C and SH syntax isn't
Hi Marcus,
I think that the idea of ini preprocessing is great, however I would
like little bit different syntax.
a) I think we don't need (1) ternary support at all, as (2)
if-elif=else-endif may do the same.
b) I think usage of square brackets is not a good idea, because they are
On Fri, 2008-02-15 at 11:36 +0300, Dmitry Stogov wrote:
a) I think we don't need (1) ternary support at all, as (2)
if-elif=else-endif may do the same.
That was already dropped. :)
b) I think usage of square brackets is not a good idea, because they are
commonly used to divide ini files
Jani Taskinen wrote:
On Fri, 2008-02-15 at 11:36 +0300, Dmitry Stogov wrote:
a) I think we don't need (1) ternary support at all, as (2)
if-elif=else-endif may do the same.
That was already dropped. :)
b) I think usage of square brackets is not a good idea, because they are
commonly used
On Fri, 2008-02-15 at 13:02 +0300, Dmitry Stogov wrote:
Jani Taskinen wrote:
c) We can use just value insted of ${value} in conditions.
Yup. ${foobar} is actually not any variable per se, but just a
reference to existing ini entry in the file. And I don't think that
needs to change.
#if defined(PHP_MAJOR_VERSION) PHP_MAJOR_VERSION = 6
extension=unicode.so
#endif
Here PHP_MAJOR_VERSION is a PHP constant that is not defined in php-5.3
but might be defined in the future version.
Dmitry.
Jani Taskinen wrote:
On Fri, 2008-02-15 at 13:02 +0300, Dmitry Stogov wrote:
Jani
Hello Dmitry,
shouldn't this be like in C/C++ where a non existing value is treated like
an empty string which behaves like false in boolean evaluations?
marcus
Friday, February 15, 2008, 11:25:42 AM, you wrote:
#if defined(PHP_MAJOR_VERSION) PHP_MAJOR_VERSION = 6
extension=unicode.so
Hello Jani,
Friday, February 15, 2008, 10:30:15 AM, you wrote:
b) I think usage of square brackets is not a good idea, because they are
commonly used to divide ini files into sections. Why not to use C
syntax? (#if...)
I'd prefer that syntax too, it would be much clearer than mixing the
I think it will work.
#ifdef UNDEFINED 5 (false)
#ifdef UNDEFINED = 5 (true)
(but anyway I think it is possible to find out an unclear condition)
Dmitry.
Marcus Boerger wrote:
Hello Dmitry,
shouldn't this be like in C/C++ where a non existing value is treated like
an empty string which
Marcus Boerger kirjoitti:
Hello Jani,
Friday, February 15, 2008, 10:30:15 AM, you wrote:
b) I think usage of square brackets is not a good idea, because they are
commonly used to divide ini files into sections. Why not to use C
syntax? (#if...)
I'd prefer that syntax too, it would be much
When I think INI I think constants. What happens when I log into some
server I have to debug some app instance and one of the first things I
might do is check the INI and I see.
[IF ${value} == 1]
setting = 1
[ELIF ${value} == 2]
[IF ${valuex} == 1]
setting = 1
[ELIF ${valuex} == 2]
Chris Stockton wrote:
When I think INI I think constants. What happens when I log into some
server I have to debug some app instance and one of the first things I
might do is check the INI and I see.
[IF ${value} == 1]
setting = 1
[ELIF ${value} == 2]
[IF ${valuex} == 1]
setting = 1
[ELIF
Dmitry, please don't throw gasoline on the flames.
We have to keep the ini files as simple as possible, this isn't the job of
the ini file.
--Jani
Dmitry Stogov kirjoitti:
The idea makes sense too, but mix of C and SH syntax isn't good.
Dmitry.
BuildSmart wrote:
Now that what-if's are
Hi Marcus,
On Wed, Feb 13, 2008 at 5:26 PM, Marcus Boerger [EMAIL PROTECTED] wrote:
Also I reduced the number of added values to 'php.zts' and 'php.debug'.
Maybe we can add those two as consts (Pierre?).
Done, both PHP_DEBUG (same as ZEND_DEBUG) and PHP_ZTS, in 5.3 and HEAD.
--
Pierre
The if-else is very basic thing. And it's quite necessary to make the
user.ini stuff useful. Especially for hosting companies.
If someone abuses it, they're pretty much on their own anyway.
--Jani
Chris Stockton kirjoitti:
It might be to late to keep it simple, once you add basic language
It might be to late to keep it simple, once you add basic language
components like IF-ELSE as you can see people already want basically
another programming language embedded into it. It is my opinion that
the INI files should be simple configuration files. Otherwise they
will become more and more
The idea makes sense too, but mix of C and SH syntax isn't good.
Dmitry.
BuildSmart wrote:
Now that what-if's are occurring in the theoretical world of intelligent
INI, what about file testing capabilities so that the following can be
used to preload extensions by existance?
#if -f
Take a look at apache's config mechanism, it allows conditional
arguments.
Yes, it can be abused but we're not talking about an extensive INI
language, just something covering basic conditional control.
On Feb 15, 2008, at 9:48 AM, Chris Stockton wrote:
It might be to late to keep it
Hello Pierre,
cool thx
marcus
Friday, February 15, 2008, 4:10:54 PM, you wrote:
Hi Marcus,
On Wed, Feb 13, 2008 at 5:26 PM, Marcus Boerger [EMAIL PROTECTED] wrote:
Also I reduced the number of added values to 'php.zts' and 'php.debug'.
Maybe we can add those two as consts (Pierre?).
: Friday, February 15, 2008 2:38 PM
Subject: Re: [PHP-DEV] [RFC] Conditional INI support
The idea makes sense too, but mix of C and SH syntax isn't good.
Dmitry.
BuildSmart wrote:
Now that what-if's are occurring in the theoretical world of intelligent
INI, what about file testing capabilities
Hello Jani,
it is a queestion of how easy i can accomplish things. In fact I do not
want to set variables in the ini file first. I want PHP to generate them
for me automatically.
marcus
Monday, February 11, 2008, 12:06:38 PM, you wrote:
On Mon, 2008-02-11 at 10:32 +0100, Marcus Boerger
Hello Pierre,
Monday, February 11, 2008, 10:31:17 PM, you wrote:
Hi Marcus,
Nice addition, it is really handy and it'll help to solve the php.iniS mess :)
On Feb 9, 2008 3:33 PM, Marcus Boerger [EMAIL PROTECTED] wrote:
attached is a patch against 5.3 that brings three feature
additions
Hello Andi, Pierre,
Monday, February 11, 2008, 7:49:04 PM, you wrote:
Hi Marcus,
In general I think conditional INI support can benefit many of our
users. We just need to make sure that we cover the most common needs and
also that we keep it very basic and simple so that we don't boil the
Hi Marcus,
In general I think conditional INI support can benefit many of our
users. We just need to make sure that we cover the most common needs and
also that we keep it very basic and simple so that we don't boil the
ocean and maintain two languages. So it's a balance we need to meet.
It
On Sat, 2008-02-09 at 15:33 +0100, Marcus Boerger wrote:
3) Add more values to INI parsing, namely:
${php.version} = 50300
${php.debug} = 0
${php.zts} = 0
${php.sapi} = CLI
And btw. This also works already:
php_sapi = PHP_SAPI
Parser checks this kind of constant strings for equialent in
On Sun, 10 Feb 2008, Stanislav Malyshev wrote:
3) Add more values to INI parsing, namely:
${php.version} = 50300
${php.debug} = 0
${php.zts} = 0
${php.sapi} = CLI
What these would be used for?
The version one is atleast useful for me to load different variants of
xdebug without
On Mon, 2008-02-11 at 10:32 +0100, Marcus Boerger wrote:
Hello Derick,
exactly why I spent the time working on this. The ability to load the
correct stuff while developing. The sapi stuff might be a better solution
for sapi specific stuff as then you do not need to pass several ini files.
Hi!
1) Ternary support for values
setting = ${value?1:2}
I think it's an overkill. If you need PHP, write it in PHP. Building
another programming language into the config system looks wrong to me.
It's complex enough as it is. We already have the programming language,
and we have
32 matches
Mail list logo
