Stefan, do you truly believe that other languages allow for secure shared
hosting without using a setuid or chroot solution? I mean
take Ruby, Python, Java, C/C++. Can you point out one of them which would not
have the issues that PHP has? I think the problem in
this case is that shared hosters
How familiar are you with Java in shared hosting environments?
-Original Message-
From: Paweł Stradomski [mailto:[EMAIL PROTECTED]
Sent: Thursday, January 11, 2007 12:12 PM
To: internals@lists.php.net
Subject: Re: [PHP-DEV] Comments on PHP security
W liście Andi Gutmans z dnia
Hi Edin,
Thanks for trying to get this to work!
I think eventually it'll be the right move to go to VC8 but I agree that if
it risks a successful 5.2.1 release then it might not be worth doing that
right now. If you can share with us a reproducing case we can try and look
into it and see if we
: Saturday, January 06, 2007 1:28 PM
To: Andi Gutmans
Cc: 'PHP Internals List'
Subject: Re: [PHP-DEV] Windows build
Hi Andi,
Turns out the problem is that Apache is building their binaries using
VC6 so wrong CRT gets loaded. The only solution I found was
to tell Windows to load Apache
Btw, one more thing which we could consider doing (although it means more
work) is to do the nts build with VC 8 and the thread-safe build with VC 6.
It'd probably require another machine (either physical or virtual).
-Original Message-
From: Andi Gutmans [mailto:[EMAIL PROTECTED
Btw, I just saw that these VC 2005 binaries were with profile guided
optimizations. Without those the performance was pretty much the same as the
Intel compiler but still far better than VC6.
Just wanted to clarify for accuracy.
Andi
-Original Message-
From: Andi Gutmans [mailto
Edin,
Thanks for taking care of this!
Andi
-Original Message-
From: Edin Kadribasic [mailto:[EMAIL PROTECTED]
Sent: Friday, January 05, 2007 5:28 AM
To: PHP internals; php-general@lists.php.net
Subject: [PHP-DEV] FastCGI optmized Windows build of 5.2.1RC2
Hello,
I have made
To: Andi Gutmans
Cc: 'PHP internals'
Subject: Re: [PHP-DEV] Dumping support for Windows 98 andWindows ME
+1
It might be a good idea to keep the latest build of php4/5,
that can run on these systems, arround for a while so the
users can download them.
- Frank
Hi all,
In the spirit
Hi all,
In the spirit of dumping Win95 support in PHP 5, I'd like to officialy dump
Windows 98ME support from this point onwards. We are sticking to old
Windows APIs because of this support which doesn't make much sense
considering that Microsoft has stopped supporting those platforms six months
I think that having more than a blackwhite taint mode is actually going to
be a mess and smells much more like a safe_mode problem to me than the bw
approach. It'll be very easy to explain what the simple approach is and that
it assumes that you correctly filter/untaint the data. At the end of the
Static analysis won't work well enough in PHP. I've been down that path and
there's no way it'll be effective enough due to the dynamic nature of the
langage. (In Java it can be much more successfully implemented).
Btw, I don't see someone doing that foreach and using untaint() being
different
That's also a solution.
Either way works for me.
-Original Message-
From: Derick Rethans [mailto:[EMAIL PROTECTED]
Sent: Saturday, December 16, 2006 8:54 AM
To: Andi Gutmans
Cc: 'Ilia Alshanetsky'; 'Stanislav Malyshev'; 'PHP internals'
Subject: RE: [PHP-DEV] display_errors
Well you wouldn't have to use tainted mode of course. This can/should be
turned off by default.
I think having such a mode would be of great help to many users though. It
would allow them to find any quirks in their data/input filtering and help
them focus on where they should do a better job. Of
Well the tool would point the developer at the data they have to
validate/filter. At that point the developer has to have a brain and needs
to know what he's doing with the data. Fortunately, if he has the right sets
of APIs in ext/filter which help him with this task, then it should be clear
to
Time to turn it off in php.ini-dist in addition to php.ini-recommended?
-Original Message-
From: Ilia Alshanetsky [mailto:[EMAIL PROTECTED] On Behalf Of
Ilia Alshanetsky
Sent: Friday, December 15, 2006 4:04 PM
To: Stanislav Malyshev
Cc: PHP internals
Subject: Re: [PHP-DEV]
I wouldn't worry about the specific interface of an explicit taint/untaint
(whether function, case or language construct). That can easily be adjusted
later on.
-Original Message-
From: Wietse Venema [mailto:[EMAIL PROTECTED]
Sent: Friday, December 15, 2006 6:02 PM
To: PHP internals
Lester,
I don't quite understand the relevance of PHPEclipse to the issue.
And I'm not sure how you judge clogging up PHP without seeing a patch
especially as I'm not sure how much PHP internals hacking you've done.
Andi
-Original Message-
From: Lester Caine [mailto:[EMAIL
I briefly reviewed the patch and it looks interesting. Will take me a bit
longer though and I'd also like some others here to do so.
In any case, I think it's risky for PHP 5.2.1 and would prefer to defer it
to the next release even if I end up being in favor of including the patch.
It changes a
I'm OK with all except for COM.
I've actually used the COM extension quite a bit internally here for
reporting and creating Excel files (see one of my blog postings from about a
year ago). I think for those who are on Windows it's a really handy
extension. Last time I checked it was also always
Making the PHP SAPI extension know how to handle static files does not sound
like the right solution to me. You should be able to redirect the PHP
requests only to PHP's FastCGI (which already works today incl. remotely),
and redirect the static content to a Web Server (thttpd or something alike).
fastcgi, in
that way i'm not oblige to maintaine patch to php sapi...
and my modification don't modify cgi implementation and are
completly compatible with the old fastcgi implementation...
Best Regards,
Mathieu
_
From: Andi Gutmans [mailto:[EMAIL PROTECTED]
To: [EMAIL PROTECTED
opinion.
Andi
-Original Message-
From: Marcus Boerger [mailto:[EMAIL PROTECTED]
Sent: Tuesday, November 14, 2006 12:15 PM
To: Dmitry Stogov
Cc: internals@lists.php.net; Andi Gutmans; Stanislav Malyshev
Subject: Re: [PHP-DEV] cgi.check_shebang_line default value
Hello Dmitry,
i
to PHP 5 for a lng time to come
and we will continue to support those users as well as we can.
Andi
-Original Message-
From: Marcus Boerger [mailto:[EMAIL PROTECTED]
Sent: Tuesday, November 14, 2006 3:16 PM
To: Andi Gutmans
Cc: 'Dmitry Stogov'; internals@lists.php.net
Sounds like something which indeed isn't worth breaking. Was this
intentional?
-Original Message-
From: Antony Dovgal [mailto:[EMAIL PROTECTED]
Sent: Monday, November 13, 2006 1:39 PM
To: php-dev
Subject: [PHP-DEV] fgets()/fgetss() BC break in HEAD
Hello all.
I'd like to
Too long of an email to read :) but just wanted to give a heads-up that we
haven't forgotten about this (it's on the PHP 6 list).
We'll try and come with a proposal in the coming weeks with a way to do it.
-Original Message-
From: Sean Coates [mailto:[EMAIL PROTECTED]
Sent: Friday,
There are some cases where this could start becoming quite challenging and
we might get into reference counting/separation problems, i.e.:
function foo()
{
return array(1,2,3);
}
foo()[1] = 4;
or
function foo()
{
$arr = array();
$arr[1] = $var;
}
foo()[1] = 2;
The arginfo patch looks OK to me. Not sure about the visibility patch. I'll
try and look into it tomorrow.
-Original Message-
From: Nuno Lopes [mailto:[EMAIL PROTECTED]
Sent: Thursday, November 09, 2006 9:09 AM
To: PHPdev
Subject: [PHP-DEV] pushing some more optimization patches
Nice patch! Looks good to me... Any other thoughts?
-Original Message-
From: Matt Wilmas [mailto:[EMAIL PROTECTED]
Sent: Wednesday, November 08, 2006 8:47 PM
To: internals@lists.php.net
Subject: [PHP-DEV] Optimization for ..._MULTIPLY_LONG on more systems
Hi,
Here's an
Why not just use a branch? Are you expecting this to come back to the
mainstream PHP distro?
-Original Message-
From: Wez Furlong [mailto:[EMAIL PROTECTED]
Sent: Wednesday, October 25, 2006 6:09 PM
To: php-dev
Subject: [PHP-DEV] ext/openssl copied to pecl/openssl
Just a heads
[mailto:[EMAIL PROTECTED]
Sent: Friday, October 20, 2006 1:11 AM
To: Andi Gutmans
Cc: 'Dmitry Stogov'; 'Ilia Alshanetsky'; [EMAIL PROTECTED]
Subject: RE: [ZEND-ENGINE-CVS] cvs: ZendEngine2(PHP_5_2) /
zend_compile.c
On Fri, 20 Oct 2006, Andi Gutmans wrote:
I cant remember
Exactly. And note where America is :)
Anyway, I see no reason not to keep it this way.
-Original Message-
From: Steph Fox [mailto:[EMAIL PROTECTED]
Sent: Thursday, October 12, 2006 9:11 AM
To: Alexander M. Wirtz; [EMAIL PROTECTED]
Cc: php internals LIST
Subject: Re: [PHP-DEV]
What kind of hackery? Have you looked at the PHP 6 source code?
This is like epsilon compared to the conditionals and hacks that had to be
made for Unicode. In fact, this patch is insignificant compared to the other
changes and provides VERY high value.
Maybe in a purists view it's not great, but
What soup? Did you check out the patch?
It's actually not bad at all. It's even cleaner than what we had previously
as we just make sure we have two versions and we use the right one...
Andi
-Original Message-
From: Sara Golemon [mailto:[EMAIL PROTECTED]
Sent: Friday, September 29,
Great. Thanks all for the help!
-Original Message-
From: Hannes Magnusson [mailto:[EMAIL PROTECTED]
Sent: Thursday, September 28, 2006 8:24 AM
To: Ilia Alshanetsky
Cc: Sean Coates; Andi Gutmans; Philip Olson; internals@lists.php.net
Subject: Re: [PHP-DEV] RSS feed for bugs.php.net
Do we have an RSS feed for bugs.php.net? It would really help maintainers
keep on top of bugs opened for their extension as email isn't great because
a lot of it gets filtered into the generic PHP Bugs folders :)
Thoughts?
Andi
--
PHP Internals - PHP Runtime Development Mailing List
To
Cool. Yes, generating that link would be *very* useful.
Can someone hack that up?
-Original Message-
From: Philip Olson [mailto:[EMAIL PROTECTED]
Sent: Wednesday, September 27, 2006 7:37 PM
To: Andi Gutmans
Cc: internals@lists.php.net
Subject: Re: [PHP-DEV] RSS feed
Yep I agree. I thought the idea was to go to filter_* which has been our
standard for extensions.
I'm sure we can find good names for the functions in this way.
-Original Message-
From: Ilia Alshanetsky [mailto:[EMAIL PROTECTED] On Behalf Of
Ilia Alshanetsky
Sent: Saturday,
Is this a dual-core or a multi-CPU system? There was a race condition in
tsrm_shutdown which has been fixed. Not sure if this fix is in 5.1.6.
-Original Message-
From: Brian Fertig [mailto:[EMAIL PROTECTED]
Sent: Monday, September 11, 2006 8:12 PM
To: internals@lists.php.net;
the usage of the dll?
Are we trying to find out how difficult we can make working
with PHP in windows be? :)
Rob
Andi Gutmans wrote:
OK well I definitely don't propose to change anything right now.
I was just struck by senility and thought you were
discussing making a
chance
As Andrei knows, I believe that not allowing to tune this on a per virtual
host basis, is going to make life very hard for our users. A huge part of
our users are hosting providers, or companies running multiple applications
on the same machine. Probably a majority do not own dedicated boxes. This
: Wednesday, September 06, 2006 6:36 PM
To: Andi Gutmans; 'Andrei Zmievski'; 'PHP Internals'
Cc: 'Dmitry Stogov'
Subject: Re: [PHP-DEV] RFC: unicode.semantics: runtime or not?
Can anyone explain to me why it would be such a big problem
to support PHP 6 and PHP 5 alongside one another? With PHP 6
. CGI is a no issue of course as the exe path is the prefered one.
Andi
-Original Message-
From: Nuno Lopes [mailto:[EMAIL PROTECTED]
Sent: Saturday, September 02, 2006 8:57 AM
To: Rob Richards; Andi Gutmans
Cc: 'Edin Kadribasic'; internals@lists.php.net
Subject: Re: [PHP-DEV] libxml2
[mailto:[EMAIL PROTECTED]
Sent: Saturday, September 02, 2006 8:17 AM
To: Andi Gutmans
Cc: 'Edin Kadribasic'; internals@lists.php.net
Subject: Re: [PHP-DEV] libxml2/threading/win 2003
I am on the fence one this one.
Going the dll route makes my life easier by no longer needing
to maintain
decision now re: bundling.
Andi
-Original Message-
From: Steph Fox [mailto:[EMAIL PROTECTED]
Sent: Saturday, September 02, 2006 8:34 AM
To: Andi Gutmans; 'Rob Richards'
Cc: 'Edin Kadribasic'; internals@lists.php.net
Subject: Re: [PHP-DEV] libxml2/threading/win 2003
Andi - the old
is
to what you want to do?
-Original Message-
From: Edin Kadribasic [mailto:[EMAIL PROTECTED]
Sent: Saturday, September 02, 2006 8:57 AM
To: Andi Gutmans
Cc: 'Steph Fox'; 'Rob Richards'; internals@lists.php.net
Subject: Re: [PHP-DEV] libxml2/threading/win 2003
Andi Gutmans wrote:
We need
:[EMAIL PROTECTED]
Sent: Saturday, September 02, 2006 8:55 AM
To: Andi Gutmans
Cc: 'Rob Richards'; internals@lists.php.net
Subject: Re: [PHP-DEV] libxml2/threading/win 2003
Andi Gutmans wrote:
I don't understand what problems you mean. On the contrary,
statically
linking in everything
will lead to more problems due to
lack of flexibility in people's install. It's a really bad design decision
and I just don't understand how this happened.
Andi
-Original Message-
From: Edin Kadribasic [mailto:[EMAIL PROTECTED]
Sent: Friday, September 01, 2006 2:35 PM
To: Andi Gutmans
Cc
Exactly. And this should be the case for all these 3rd party libraries. They
should always be dlls and not be linked in with php5ts.dll. Throughout our
history we've always had trouble with statically linked 3rd party libs...
Andi
-Original Message-
From: Edin Kadribasic
-
From: Steph Fox [mailto:[EMAIL PROTECTED]
Sent: Friday, September 01, 2006 5:25 AM
To: Andi Gutmans; 'Ilia Alshanetsky'; internals@lists.php.net
Subject: Re: [PHP-DEV] PHP 5.2.0RC3 Released
Hi Andi,
Rock vs hard place - RC's were announced on php.net and
distributed via the download
Hi Ilia,
Can you post it also on the front page of php.net? As we are getting closer
to release 5.2.0 we should make sure that we get as many beta testers as
possible. My experience is that internals@ isn't enough...
Thanks.
Andi
-Original Message-
From: Ilia Alshanetsky
Yep I completely agree.
Although PHP is a volunteers project, the development team represent the
project, and should therefore try and be as professional as possible (in the
many things that encompasses).
-Original Message-
From: news [mailto:[EMAIL PROTECTED] On Behalf Of Sebastian
flexible.
Andi
-Original Message-
From: Rob Richards [mailto:[EMAIL PROTECTED]
Sent: Friday, August 25, 2006 4:26 AM
To: Andi Gutmans
Cc: 'Edin Kadribasic'; internals@lists.php.net
Subject: Re: [PHP-DEV] libxml2/threading/win 2003
MINIT is definitely not the place
Rob,
Is there a reason why we can't call this from MINIT? I'm not sure a good
long-term solution is to have a DllMain when we don't need one.
Andi
-Original Message-
From: Rob Richards [mailto:[EMAIL PROTECTED]
Sent: Thursday, August 10, 2006 2:03 PM
To: Edin Kadribasic;
The new memory manager actually wastes less memory than the old one, scales
better and most important to this discussion, the memory consumption is far
more accurate as it also takes into account the memory manager overhead.
Therefore, we are not consuming 1.5x memory, but we are reporting a more
-intrusive way, at high quality and without making it
significantly harder for debuggers and profilers to work with this is just
not worth it...
Andi
-Original Message-
From: Stanislav Malyshev [mailto:[EMAIL PROTECTED]
Sent: Tuesday, August 08, 2006 7:22 AM
To: Andi Gutmans
Subject
Hey,
Coming into this a bit late (took me a while to read the gazillion emails on
the topic.
First of all, I agree that we can find some middle ground which should make
everyone happy.
I don't think that making interfaces have additional semantics is the way to
go though. I personally don't
Hi Marcus,
I'm still trying to figure out whether this patch might have some far
reaching affects which we're not thinking of.
For example, debuggers would not work with this and would need some serious
changes. Also, there might be something inside Zend which expects the
filename to be correct.
Unless there are objections we can commit it for you.
One change I'd like you to make though is to remove the V in the registry
before the version #. Makes it harder for automated programs. It should just
be SOFTWARE\\PHP\\5\\IniFilePath
Btw, one thing I didn't understand. Are you cascading 5 and
Hi Chung,
Any idea on the performance of OLEDB? My understanding was that due to it
going through the COM layer, performance will be relatively poor.
Any idea?
Andi
-Original Message-
From: Chung Leong [mailto:[EMAIL PROTECTED]
Sent: Friday, July 28, 2006 2:37 PM
To:
Hi Bertrand,
The discussion is on how and what we count, not on whether to count or not.
If you count in 256KB increments instead of in byte increments then there's
less counting to do in order to get to 16MB :)
Andi
-Original Message-
From: bertrand Gugger [mailto:[EMAIL PROTECTED]
] does 16M give a counting overhead ?
Andi Gutmans wrote:
Hi Bertrand,
The discussion is on how and what we count, not on whether
to count or not.
The quoted discussion is/was , this one is about the
possibility to get 16M without counting.
If you count in 256KB increments instead
-Original Message-
From: bertrand Gugger [mailto:[EMAIL PROTECTED]
Sent: Saturday, July 29, 2006 3:30 PM
To: internals@lists.php.net
Subject: Re: [PHP-DEV] does 16M give a counting overhead ?
Andi Gutmans wrote:
There is no hardcoded counting. We either cound
(--enable-memory
, 2006 4:08 AM
To: internals@lists.php.net; Dmitry Stogov; 'Andi Gutmans'
Subject: Re: [PHP-DEV] memory_get_usage with new Memory Manager
Hi Dmitry,
No, there's always more work going on (with
--enable-memory-limit) with every emalloc() call to update
the size even when real_size isn't
functions in PHP (if
not the most).
Cheers,
Andi
-Original Message-
From: Matt W [mailto:[EMAIL PROTECTED]
Sent: Friday, July 28, 2006 8:12 PM
To: internals@lists.php.net; Andi Gutmans; 'Dmitry Stogov'
Subject: Re: [PHP-DEV] memory_get_usage with new Memory Manager
Hi Andi, Dmitry
I personally think that we should keep the more accurate behavior both
because it's the most accurate and what most people would expect when
setting memory limits, and because it does allow us to always enable
memory-limit code due to the significantly smaller overhead of keeping
count.
If some
Although I don't want to clutter the list further, I do agree with
DerickMarcus on this. I actually like ZipArchive() better :)
-Original Message-
From: Derick Rethans [mailto:[EMAIL PROTECTED]
Sent: Thursday, July 20, 2006 2:44 PM
To: Pierre
Cc: PHP Developers Mailing List
I personally don't think it's *that* useful to have an abstraction on top of
archives and in any case, it doesn't make sense for this request to come up
now.
If you'd like something like that, then I suggest to apply for a PECL
account and work on an extension that implments it.
As to having
There's a big difference.
Inherited classes should adhere to the instanceof operator. Meaning that if
you get an object you can check if it's an instance of another class and if
so, you can call it *exactly* the way you could the parent class. This
allows for good polymorphic design in
Can you please send me the latest patch for review? I can't find it for some
reason.
Thx.
Andi
-Original Message-
From: Marcus Boerger [mailto:[EMAIL PROTECTED]
Sent: Monday, July 17, 2006 2:34 PM
To: Sara Golemon
Cc: Jeff Moore; internals@lists.php.net
Subject: Re: [PHP-DEV] Re:
Peer pressure? :)
Steph doesn't want to be left out :) Just kidding...
Andi
-Original Message-
From: Steph Fox [mailto:[EMAIL PROTECTED]
Sent: Wednesday, July 19, 2006 1:26 PM
To: Marcus Boerger; Edin Kadribasic
Cc: Ilia Alshanetsky; PHP Internals
Subject: Re: [PHP-DEV] Date
-Original Message-
From: Dmitry Stogov [mailto:[EMAIL PROTECTED]
Sent: Wednesday, July 19, 2006 8:23 AM
To: internals@lists.php.net
Cc: Marcus Boerger; Andi Gutmans
Subject: RE: [PHP-DEV] PHP 5.2-dev Cannot use array returned
from foo::__get('bar') in write context
__get() never worked
I think we've really reached an unhealthy situation in PHP release
management. We used to shift around this responsibility quite frequently.
Sometimes people would assume responsibility even for a mini release.
When people thought (and rightfully so) that I was a bit too busy to run the
PHP 5.1
Hey,
I don't think question is only in regards to Date.
I think it's a bigger question on what the standard is for internal classes.
We are just at the beginning of this stage in PHP's evolution, and I think
we need to agree on a standard that Date and other following classes will
all adhere to.
-
From: Steph Fox [mailto:[EMAIL PROTECTED]
Sent: Tuesday, July 18, 2006 1:00 PM
To: Andi Gutmans; 'Derick Rethans'
Cc: 'Edin Kadribasic'; 'Dmitry Stogov';
internals@lists.php.net; 'Ilia Alshanetsky'
Subject: Re: [PHP-DEV] Re: PEAR::Date broken (Was: [PHP-CVS]
cvs: php-src(PHP_5_2) /ext/date
I second Ilia.
_
From: Ilia Alshanetsky [mailto:[EMAIL PROTECTED] On Behalf Of Ilia
Alshanetsky
Sent: Tuesday, July 18, 2006 1:55 PM
To: Pierre
Cc: Andi Gutmans; Steph Fox; Derick Rethans; Edin Kadribasic; Dmitry Stogov;
internals@lists.php.net
Subject: Re: [PHP-DEV] Re: PEAR::Date
Either of those are good options IMO, although we should make a high-level
decision if we want to do PHP prefix or we defer that to PHP 6.
Andi
_
From: Ilia Alshanetsky [mailto:[EMAIL PROTECTED] On Behalf Of Ilia
Alshanetsky
Sent: Tuesday, July 18, 2006 1:49 PM
To: Andi Gutmans
Cc
PHPDate and PHP:Date equivalent.
-Original Message-
From: Olivier Hill [mailto:[EMAIL PROTECTED]
Sent: Tuesday, July 18, 2006 2:50 PM
To: Steph Fox
Cc: Andi Gutmans; Derick Rethans; Edin Kadribasic; Dmitry
Stogov; internals@lists.php.net; Ilia Alshanetsky
Subject: Re: [PHP-DEV] Re
There's also a build error in ZTS in ext/filter and warnings in ext/date.
Can someone take a look?
/bin/sh /home/andi/php5/libtool --silent --preserve-dup-deps --mode=compile
/home/andi/php5/meta_ccld -Iext/filter/ -I/home/andi/php5/ext/filter/
-DPHP_ATOM_INC -I/home/andi/php5/include
Oops :)
_
From: Ilia Alshanetsky [mailto:[EMAIL PROTECTED] On Behalf Of Ilia
Alshanetsky
Sent: Tuesday, July 18, 2006 4:54 PM
To: Andi Gutmans
Subject: Re: [PHP-DEV] Re: PEAR::Date broken (Was: [PHP-CVS] cvs:
php-src(PHP_5_2) /ext/date php_date.c php_date.h)
Sounds good to me, but you
; Andi Gutmans;
'Derick Rethans'; 'Edin Kadribasic'; 'Dmitry Stogov';
internals@lists.php.net; 'Ilia Alshanetsky'
Subject: Re: [PHP-DEV] Re: PEAR::Date broken (Was: [PHP-CVS]
cvs: php-src(PHP_5_2) /ext/date php_date.c php_date.h)
Sure, but let's get some perspective as well here. We
Didn't see this but I did :)
Andi
-Original Message-
From: Andrei Zmievski [mailto:[EMAIL PROTECTED]
Sent: Tuesday, July 18, 2006 10:13 AM
To: Dmitry Stogov
Cc: php-cvs@lists.php.net; internals@lists.php.net
Subject: [PHP-DEV] Re: [PHP-CVS] New Memory Manager (Was:
[PHP-CVS]
in PHP.
Andi
-Original Message-
From: Marcus Boerger [mailto:[EMAIL PROTECTED]
Sent: Monday, July 17, 2006 2:49 PM
To: Andrei Zmievski
Cc: Marcus Boerger; Andrei Zmievski; Zeev Suraski; Andi
Gutmans; internals@lists.php.net
Subject: Re: [PHP-DEV] Unicode and fetch class
Hello
]
Sent: Monday, July 17, 2006 4:57 PM
To: Zeev Suraski
Cc: Andi Gutmans; Marcus Boerger; PHP internals
Subject: Re: [PHP-DEV] Unicode and fetch class
Yes, we are. But normalization (in our case) may involve
case-folding (for class/function names), so it's really a
single operation. If you
OK sounds fine.
-Original Message-
From: Andrei Zmievski [mailto:[EMAIL PROTECTED]
Sent: Monday, July 17, 2006 5:28 PM
To: Andi Gutmans
Cc: 'Zeev Suraski'; 'Marcus Boerger'; 'PHP internals'
Subject: Re: [PHP-DEV] Unicode and fetch class
We did talk about this before, on the php
ppl to run some benchmarks on this.
Thx.
Andi
-Original Message-
From: Michael Vergoz [mailto:[EMAIL PROTECTED]
Sent: Monday, July 10, 2006 5:25 PM
To: Andi Gutmans; internals@lists.php.net
Subject: Re: [PHP-DEV] FW: Help needed in benchmarking memory patch
Hi Andi,
I
Are you sure this isn't because the IIS thread is still running? One thread
handles multiple requests.
-Original Message-
From: Michael Vergoz [mailto:[EMAIL PROTECTED]
Sent: Tuesday, July 11, 2006 10:33 AM
To: Dmitry Stogov; 'Andi Gutmans'; PHPdev
Subject: Re: [PHP-DEV] FW: Help
I definitely think that for production apps we should be able to turn this
off. It could significantly slow down apps.
-Original Message-
From: Michael Wallner [mailto:[EMAIL PROTECTED]
Sent: Tuesday, July 11, 2006 3:35 AM
To: internals@lists.php.net
Subject: [PHP-DEV] More
I don't have a problem with the functionality and the patch doesn't seem
problematic.
I do question though whether we want to add this to array_fill()? Not sure
if that parameter overloading is very intuitive as it doesn't just add one
parameter. What do others think? Would you prefer an
No help??? Come on guys. I'm sure some of you can spare a few idle cycles :)
-Original Message-
From: Andi Gutmans [mailto:[EMAIL PROTECTED]
Sent: Friday, July 07, 2006 8:38 PM
To: internals@lists.php.net
Subject: [PHP-DEV] FW: Help needed in benchmarking memory patch
Sending
Anyone who'd like to try benchmark this, please drop me an email. We can
also discuss how best to test.
Thx.
Andi
-Original Message-
From: Andi Gutmans [mailto:[EMAIL PROTECTED]
Sent: Friday, July 07, 2006 8:38 PM
To: internals@lists.php.net
Subject: [PHP-DEV] FW: Help needed
Sending 3rd time this time without the attachment.
You can get the diff at http://gutmans.org/alloc.zip
-Original Message-
From: Andi Gutmans [mailto:[EMAIL PROTECTED]
Sent: Thursday, July 06, 2006 11:06 PM
To: 'internals@lists.php.net'
Subject: Help needed in benchmarking memory patch
Looks good to me. Thanks!
-Original Message-
From: Sara Golemon [mailto:[EMAIL PROTECTED]
Sent: Wednesday, July 05, 2006 2:00 PM
To: internals@lists.php.net
Subject: [PHP-DEV] Inconsistency between FETCH_DIM_IS and FETCH_OBJ_IS
When executing ZEND_FETCH_OBJ_IS on a non-object,
Sounds fine to me.
-Original Message-
From: Andrei Zmievski [mailto:[EMAIL PROTECTED]
Sent: Wednesday, June 28, 2006 3:40 AM
To: PHP Internals
Cc: PHP I18N
Subject: [PHP-I18N] Renaming unicode_semantics
I am considering renaming unicode_semantics to
unicode.semantics to
I think this is a good idea. It seems like it'll work long term and it does
solve a problem we have today (and already went half way to solving it).
-Original Message-
From: Richard Quadling [mailto:[EMAIL PROTECTED]
Sent: Monday, June 26, 2006 1:51 AM
To: internals@lists.php.net
Hey,
First of all I agree. We should be releasing 4.4.3. Derick is supposed to be
on top of that. If that's delayed due to lack of time (understandable) we
can have someone else roll the RCs and releases. In the past we've often
switched release managers for mini releases when the one doing it
Fine with me.
-Original Message-
From: Andrei Zmievski [mailto:[EMAIL PROTECTED]
Sent: Thursday, June 22, 2006 11:08 PM
To: Andi Gutmans
Cc: 'Johannes Schlueter'; internals@lists.php.net; 'Ron Korving'
Subject: Re: [PHP-DEV] Re: strlen() under unicode.semantics
How about
I don't quite agree. I think there's a good chance people will want to save
Unicode strings in a binary format for performance reasons. Save it the way
it looks in memory, and put it back... Why convert to UTF-8 or any other
encoding if it's just about storage?
Andi
-Original Message-
Hmm, I was thinking we might have some binary write function which would do
that automagically. I think it'd be worth it.
-Original Message-
From: Andrei Zmievski [mailto:[EMAIL PROTECTED]
Sent: Thursday, June 22, 2006 11:38 PM
To: Andi Gutmans
Cc: 'Sara Golemon'; 'Ron Korving
:[EMAIL PROTECTED]
Sent: Friday, June 23, 2006 1:16 AM
To: Andi Gutmans; 'Andrei Zmievski'
Cc: 'Ron Korving'; internals@lists.php.net
Subject: Re: [PHP-DEV] Re: strlen() under unicode.semantics
The only way they can get at the internal UTF-16 representation is
via unicode_encode($uni
Maybe sizeof() should not be an alias for strlen() when operating on
Unicode...?
Andi
-Original Message-
From: Andrei Zmievski [mailto:[EMAIL PROTECTED]
Sent: Thursday, June 22, 2006 3:14 PM
To: Ron Korving
Cc: internals@lists.php.net
Subject: Re: [PHP-DEV] Re: strlen() under
301 - 400 of 1734 matches
Mail list logo
