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 consensu
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 i
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, move stuff out of core
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 the
[EMAIL PROTECTED]>
To: "PHP Internals List"
Cc: <[EMAIL PROTECTED]>; "Marcus Boerger" <[EMAIL PROTECTED]>; "Andi
Gutmans"
<[EMAIL PROTECTED]>; "Jani Taskinen" <[EMAIL PROTECTED]>
Sent: Friday, February 15, 2008 2:38 PM
Subject: R
ns"
> <[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 good.
>>
>> Dmitry.
<[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 good.
Dmitry.
BuildSmart wrote:
Now that what-if's are
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 simp
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 (Pi
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 ${EXTENSI
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 f
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
c
Oh ya, that is why PHP isn't widely adopted in the shared hosting
world. Oh btw, I really do think we should give our users bigger guns
to shoot themselves in the foot with. We already know that if we give
them features that could be used incorrectly, they won't use them
incorrectly.
This mess
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
h
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 occurr
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 ${EXTENSIONS_DIR}/gd.so
extension=gd.so
#endif
or some other syntax that allows testing to include a
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 ${
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]
setting
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
Currently UNDEFINED would be just string 'UNDEFINED'.
Doesn't atoi() for non-numeric string make it 0 ??
(or null..:) So that would work without changing anything..
--Jani
Dmitry Stogov kirjoitti:
I think it will work.
#ifdef UNDEFINED > 5 (false)
#ifdef UNDEFINED <= 5 (true)
(but anyway I
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
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
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.s
#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:
Ja
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
> > need
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 t
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
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
commonl
nt with
> PHP. It would look weird for the same solution to have two approaches to
> this.
Both of you guys say the same for the same reasons., so I changed that
as well.
Also I reduced the number of added values to 'php.zts' and 'php.debug'.
Maybe we can add those two a
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
>> ad
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 wrot
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 to INI parsing.
>
> 1) Ternary support for values
>
> setting = $
IL PROTECTED]
> Sent: Saturday, February 09, 2008 6:33 AM
> To: PHP Internals List
> Subject: [PHP-DEV] [RFC] Conditional INI support
>
> Hello PHPlers,
>
> attached is a patch against 5.3 that brings three feature additions
> to INI parsing.
>
> 1) Ternary supp
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 equialen
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 fil
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.
marcus
Monday, February 11, 2008, 9:57:08 AM, you wrote:
> O
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
xd
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 ini_set
Hello PHPlers,
attached is a patch against 5.3 that brings three feature
additions to INI parsing.
1) Ternary support for values
setting = ${value?1:2}
If ${value} evaluates to true then setting becomes 1 otherwise 2.
This cannot be nested and only works for values, not for setting names.
39 matches
Mail list logo
