Hi Marcus,
Cool, thanks. I didn't start modifying it yet, but will soon.
Matt
- Original Message -
From: "Marcus Boerger"
Sent: Friday, July 21, 2006
> Hello Matt,
>
> sounds good then, keep going.
>
> best regards
> marcus
>
> Friday, July 21, 2006, 10:08:19 AM, you wrote:
>
> > Hi
Hi Andrei,
I see you applied my patch. However, the 5.2 code still isn't binary-key
safe (you only changed the second occurrence of add_assoc_zval to the _ex
version). Or was that intentional and you only want to change the behavior
in 6?
And you know 5.2's description is still wrong -- with "k
On Fri, 2006-07-21 at 23:48 +0200, Lukas Smith wrote:
> EXPERIMENTAL is just a way to cover our asses against not being able to
> break BC if we find out we screwed something up in a new extension.
> Bringing something into core obviously gives us a larger testbed and so
> new situations are lik
Hi,
Haven't heard any opinions on these functionality changes... (Though I know
more significant things keep you busy!)
Do many other people use number_format()?? Wouldn't allowing thousands
separator as param #2 simplify things?
Any issues with the semantics of operation? Negative precision
Bullshit. PECL is just as good as "core".
It just needs more marketing. One good way to sell it to people
might be to put some most used extensions there. :)
If some extension is useful and needed people WILL find it in PECL.
--Jani
On Sat, 22 Jul 2006, John Coggeshall wro
Andrei Zmievski wrote:
Awesome.
I am planning to add "s(encoding)" support to parameter parsing, by
the way, so getting strings in UTF-8 encoding will be a bit easier.
Would probably need to change the relevant portions of your commits.
Any idea when this should be ready, or should I just go a
Bullshit. PECL is just as good as "core".
To the developers of PHP and people with dedicated servers this might be
true, however in my experience this is far from true for mass virtual
hosters. If its not included in the core php package it wont be available to
the end user. So moving more
I agree with Jani here. It's a bit of a catch-22 but putting more
popular extensions into PECL should help.
-Andrei
On Jul 22, 2006, at 5:09 AM, Jani Taskinen wrote:
Bullshit. PECL is just as good as "core".
It just needs more marketing. One good way to sell it to people
might
The problem of web hosting remains, and isn't easily resolved. We already
saw what the situation is when it comes to web hosts and the distributed
.ini files; it's much the same when it comes to extensions. The better hosts
may well enable further extensions on request, but many won't - possibly
I probably won't get to it this weekend. Might have it done during
OSCON next week, so it's up to you.
-Andrei
On Jul 22, 2006, at 6:30 AM, Rob Richards wrote:
Andrei Zmievski wrote:
Awesome.
I am planning to add "s(encoding)" support to parameter parsing,
by the way, so getting strings
On 7/22/06, Andrei Zmievski <[EMAIL PROTECTED]> wrote:
I agree with Jani here. It's a bit of a catch-22 but putting more
popular extensions into PECL should help.
So do it and stop (plural form) to add all possible new rules to block
my proposal.
Also remove all the recent additions. no? So fo
On Jul 20, 2006, at 3:21 PM, Marcus Boerger wrote:
I've wished there was a *printf() float specifier that wouldn't
include
trailing zeros/point, as simply converting to string (echo, %s,
etc.) can
result in scientific notation, which I *don't* want (%g in
convert_to_string()). The only other
My recommendations would be:
for (1): Let the build system spit out packages for the most well known
distributions which are similar to the windows ones, e.g. one small php
binary, many *.so in the "standard" package and a pecl *.so package.
Dedicated server owners or small web hosts usually
Bonsoir Matt,
Matt W wrote:
Hi,
Haven't heard any opinions on these functionality changes... (Though I know
more significant things keep you busy!)
Do many other people use number_format()?? Wouldn't allowing thousands
separator as param #2 simplify things?
Any issues with the semantics of o
Hello Andrei,
don't we have a char left for UTF-8 (maybe 8) as it would be a case that
we will have to use very often and checking for a string in braces will
take some time.
best regards
marcus
Friday, July 21, 2006, 9:39:32 PM, you wrote:
> Awesome.
> I am planning to add "s(encoding)" supp
Maybe. An alternate way would be to add modifier to 's' that makes it
accept a converter to use for conversion.
if (zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC, "s>", &str,
&str_len, UG(utf8_conv)) == FAILURE) {
return;
}
This does mean that the caller will have to instantiate t
Hi. Sorry about the delay. Had a blonde moment.
I've used a small script to process the CVS. There are 420 changes!!!
I've used the following regexps for a search/replace ...
$s_search =
'`add_assoc_(bool|double|long|null|resource|rt_stringl|rt_string|stringl|string|unicodel|unicode|zval)*\(([
bertrand Gugger wrote:
Bonsoir Matt,
Matt W wrote:
Hi,
Haven't heard any opinions on these functionality changes... (Though
I know
more significant things keep you busy!)
Do many other people use number_format()?? Wouldn't allowing thousands
separator as param #2 simplify things?
Any iss
Matt W wrote:
Hi,
Haven't heard any opinions on these functionality changes... (Though I know
more significant things keep you busy!)
Do many other people use number_format()?? Wouldn't allowing thousands
separator as param #2 simplify things?
Any issues with the semantics of operation? Neg
Hi Richard,
Replacement script made it pretty simple I guess. :-) But sizeof("key")+1
should just be sizeof("key") (which == strlen("key")+1).
Are there any uses of add_u_assoc_* with hard-coded keys?
These changes make things look a little messy, you think? The string is in
2 places, etc...
On 21.07.2006 19:23, Derick Rethans wrote:
On Fri, 21 Jul 2006, Dmitry Stogov wrote:
dmitry Fri Jul 21 10:32:17 2006 UTC
Modified files: (Branch: PHP_5_2)
/ZendEngine2 zend_object_handlers.c
/ZendEngine2/tests bug32660.phpt bug37667.phpt
Log:
Changed erro
On 23.07.2006 02:31, Stefan Esser wrote:
Hello,
well the policy is you commit to HEAD first so that HEAD and base do not
get out of synch. For PDO we already have the situation and it will mos
Yeah we all know how well commiting to HEAD and then merging the same
untested code to the branches
22 matches
Mail list logo
