There are serious problems from enabling LFS support like this in a
project like PHP.
If I have some library which uses off_t in its API, e.g. zlib, and I
happened to not compile it with LFS support, e.g. as in most Linux
distributions, I now *cannot* call the zlib functions using off_t from
PHP,
It sounds to me that it makes sense to split the roadmap into two. Probably
something like:
PHP 5.1:
- Improved VM
- PDO
- Possibly improved serialization
- Other minor changes in language and extension
PHP 5.2:
- Better support for i18n
- int64
This is obviously just a general idea and I'm sure
What I planned to do with the streams API for 5.1 was define
php_stream_off_t to be a 64-bit type (regardless of LFS support),
adjust the API where it is needed, and handle the LFS stuff centrally,
using the transitional LFS functions you mentioned if they are
present.
I confess that I haven't
Hi!
I've been trying to get mime_magic to work with PHP 5.0.2, but it seems to
complain about the magic file being valid. I've tried both with the Apache
2.0.52 version of magic and with the PHP5 Win32 version of magic.mime,
but it still says that they're invalid.
Does anyone have a magic.mime
On Fri, 22 Oct 2004 00:05:32 -0700, Andi Gutmans [EMAIL PROTECTED] wrote:
It sounds to me that it makes sense to split the roadmap into two. Probably
something like:
PHP 5.1:
- Improved VM
- PDO
- Possibly improved serialization
- Other minor changes in language and extension
Greg suggests
Wez Furlong wrote:
a) PDO support for most popular DBs. Maybe you can give a status report of
where PDO is today and how much work it still requires? If it requires a
lot of work maybe more people can join the effort. Also is there an online
phpDoc of each DB API one can look at? I've looked at
Andi Gutmans wrote:
It sounds to me that it makes sense to split the roadmap into two.
Probably something like:
PHP 5.1:
- Improved VM
- PDO
- Possibly improved serialization
- Other minor changes in language and extension
Pierre is also working on a new date ext (which seems to be maturing
from
I added some stuff along these lines 3 weeks ago:
http://viewcvs.php.net/viewcvs.cgi/pecl/pdo/pdo_stmt.c.diff?r1=1.47r2=1.48
+/* {{{ proto int PDOStatement::columnCount()
+ Returns the number of columns in the result set */
+/* {{{ proto array PDOStatement::getColumnMeta(int $column)
+
On Fri, Oct 22, 2004 at 09:53:14AM +0100, Wez Furlong wrote:
What I planned to do with the streams API for 5.1 was define
php_stream_off_t to be a 64-bit type (regardless of LFS support),
adjust the API where it is needed, and handle the LFS stuff centrally,
using the transitional LFS
On Fri, 22 Oct 2004 10:45:08 +0100, Joe Orton [EMAIL PROTECTED] wrote:
On Fri, Oct 22, 2004 at 09:53:14AM +0100, Wez Furlong wrote:
What I planned to do with the streams API for 5.1 was define
php_stream_off_t to be a 64-bit type (regardless of LFS support),
adjust the API where it is
On Fri, Oct 22, 2004 at 10:53:25AM +0100, Wez Furlong wrote:
On Fri, 22 Oct 2004 10:45:08 +0100, Joe Orton [EMAIL PROTECTED] wrote:
On Fri, Oct 22, 2004 at 09:53:14AM +0100, Wez Furlong wrote:
What I planned to do with the streams API for 5.1 was define
php_stream_off_t to be a 64-bit
On Friday 22 October 2004 12:08, Joe Orton wrote:
But both approaches are feasible, the important thing is to avoid
using -D_FILE_OFFSET_BITS=64, which just breaks so much.
As far as I can tell we use off_t only once when calling external libraries.
And yes it is in a call to zlib when
On Fri, Oct 22, 2004 at 12:59:04PM +0200, Edin Kadribasic wrote:
However I consider crashing apache children with signal 25 when doing simple
is_file() or fopen() on large files really harmful. Apache flat out refuses
to start if you have enabled php error log and that file happen to be 2GB
On Friday 22 October 2004 13:33, Joe Orton wrote:
On Fri, Oct 22, 2004 at 12:59:04PM +0200, Edin Kadribasic wrote:
However I consider crashing apache children with signal 25 when doing
simple is_file() or fopen() on large files really harmful. Apache flat
out refuses to start if you have
As I mentioned in my original post, --with-module and
--with-module-dir seem to have some inconsistencies themselves
as
well. What is the behavior?
Where are the inconsistencies, can you point those out?
Here are some notes additions from my previous post.
In fact,
For #2, per Robert Silva's post:
For #2, I believe he is referring to searching LD_LIBRARY_PATH
directories for libraries rather than hardcoding /lib everywhere
(which
is how its done now).
Unfortunately it's not that easy from what I remember.
with as it is common to specify
Hi,
I'm trying to wrote my own serialization routines and I've found a
previsible problem: protected members are not visible to my
serialization routine. This is ok and it should be as is, but I've seen
that PHP's serialize function have access to that members anyway, so the
question is: Is there
This one time, at band camp, Wez Furlong [EMAIL PROTECTED] wrote:
Feature-wise, it's missing scrollable (eg: random access) cursors and
Marcus' iterators (sorry Marcus).
So, when do we see iterators?
Kevin
-
Democracy is two wolves and a lamb voting on what to have for lunch.
Liberty
Hi,
Francisco M. Marzoa Alonso wrote:
Hi,
I'm trying to wrote my own serialization routines and I've found a
previsible problem: protected members are not visible to my
serialization routine. This is ok and it should be as is, but I've seen
that PHP's serialize function have access to that
On Fri, Oct 22, 2004 at 02:26:50PM +0200, Edin Kadribasic wrote:
On Friday 22 October 2004 13:33, Joe Orton wrote:
On Fri, Oct 22, 2004 at 12:59:04PM +0200, Edin Kadribasic wrote:
However I consider crashing apache children with signal 25 when doing
simple is_file() or fopen() on large
Joe Orton wrote:
Then consider this your official wake-up call :)
LOL. I use Apache 1.3 and found it to work way better then 2.0. 2.0 does
not offer any useful improvements over the 1.3 base, so why switch? If
anything in my personal experience 1.3 works way better then 2.0 with PHP.
Ilia
--
On Fri, 22 Oct 2004, Joe Orton wrote:
I still use 1.3 (like, I guess, most of the PHP installations outthere).
Then consider this your official wake-up call :)
Perhaps we can consider that when Apache 2 uses static modules like
Apache 1.3. But for now Apache 1.3 works great, and that can not
On Friday 22 October 2004 15:42, Joe Orton wrote:
On Fri, Oct 22, 2004 at 02:26:50PM +0200, Edin Kadribasic wrote:
On Friday 22 October 2004 13:33, Joe Orton wrote:
On Fri, Oct 22, 2004 at 12:59:04PM +0200, Edin Kadribasic wrote:
However I consider crashing apache children with signal 25
Thanks a lot, it was very useful.
Andrey Hristov wrote:
[...]
There is a hack to access private data of an object.
[...]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Is there any manner to know if a class is a subclass of another from
class name as string?
I meant something in the line of is_subclass_of but using the name of
the child class instead of an object instance.
TIA
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit:
Francisco M. Marzoa Alonso wrote:
Is there any manner to know if a class is a subclass of another from
class name as string?
I meant something in the line of is_subclass_of but using the name of
the child class instead of an object instance.
TIA
In such situations I have used
On Fri, Oct 22, 2004 at 09:49:55AM -0400, Ilia Alshanetsky wrote:
Joe Orton wrote:
Then consider this your official wake-up call :)
LOL. I use Apache 1.3 and found it to work way better then 2.0. 2.0 does
not offer any useful improvements over the 1.3 base, so why switch? If
anything in
On Fri, Oct 22, 2004 at 02:36:00PM +0200, Derick Rethans wrote:
AFAIK Joe is going to commit his patch, but we need to fix it for the
PECL extensions too if applicable.
I was kind of waiting for Sascha to review it... do you want me to
commit it now? PECL extensions (or any autoconf code in
On Fri, 22 Oct 2004, Joe Orton wrote:
On Fri, Oct 22, 2004 at 02:36:00PM +0200, Derick Rethans wrote:
AFAIK Joe is going to commit his patch, but we need to fix it for the
PECL extensions too if applicable.
I was kind of waiting for Sascha to review it... do you want me to
commit it now?
Marcus Boerger wrote:
Hello Robert,
Tuesday, October 19, 2004, 10:20:59 PM, you wrote:
The issues surrounding this seemed to have been muddied up a little, I'll
try to clear them up.
I see two different sets of functionality that people are asking for.
#1. The ability to pass null
Marcus Boerger wrote:
Hello Robert,
Tuesday, October 19, 2004, 10:20:59 PM, you wrote:
The issues surrounding this seemed to have been muddied up a little, I'll
try to clear them up.
I see two different sets of functionality that people are asking for.
#1. The ability to pass null
As of PHP 5.1, the request start time is stored by PHP inside the sapi
structure. This data is populated by the information offered by the SAPI
(Apache sapis populate it) otherwise time(0) is used to get the same data.
This means that PHP has a free unix timestamp that tells information
about
On Oct 22, 2004, at 4:43 PM, Ilia Alshanetsky wrote:
The question is what would be the best way to provide this information
within the script. The two alternatives are: adding a new function to
get this info or storing this data inside $_SERVER.
What do you think?
$_SERVER['request_time']
Ilia Alshanetsky wrote:
As of PHP 5.1, the request start time is stored by PHP inside the sapi
structure. This data is populated by the information offered by the SAPI
(Apache sapis populate it) otherwise time(0) is used to get the same data.
This means that PHP has a free unix timestamp that
On Fri, 22 Oct 2004, dharana wrote:
Ilia Alshanetsky wrote:
. Since a lot of script end up having to fetch request start time, this
can be used to save on a timing call
(This information only has second precision, no microseconds).
I would think the reason for fetching request start
Derick Rethans wrote:
For that the granularity is not good enough though.
Ideally we'd have gettimeofday() cached, but looking @ the code it is
called on by lcg code and then only on MINIT. So we'd need an extra
syscall to provide this, I am not sure this is a good idea.
Ilia
P.S. I didn't
On Oct 22, 2004, at 5:05 PM, Ilia Alshanetsky wrote:
Derick Rethans wrote:
For that the granularity is not good enough though.
Ideally we'd have gettimeofday() cached, but looking @ the code it is
called on by lcg code and then only on MINIT. So we'd need an extra
syscall to provide this, I am
At 10:13 AM 10/22/2004 +0100, Wez Furlong wrote:
PHP 5.2:
- Better support for i18n
- int64
This is obviously just a general idea and I'm sure there are other things.
As I discussed with Derick today, I think i18n is something where work can
commence ASAP (even before 5.1) but my guess is
At 02:42 PM 10/22/2004 +0100, Joe Orton wrote:
For Linux at least that was fixed since 2.0.50, or are you using 1.3
still?
I still use 1.3 (like, I guess, most of the PHP installations outthere).
Then consider this your official wake-up call :)
Most people are still using 1.3.x. I don't
On Fri, 22 Oct 2004 13:49:53 -0700, Andi Gutmans [EMAIL PROTECTED] wrote:
At 10:13 AM 10/22/2004 +0100, Wez Furlong wrote:
I'd like to get LFS support into 5.1; it kinda needs int64 support. I
would be happy with a ZVAL_INT64() macro that assigns an int64 type to
a zval; for now it would
On Fri, 22 Oct 2004, Ilia Alshanetsky wrote:
Derick Rethans wrote:
For that the granularity is not good enough though.
Ideally we'd have gettimeofday() cached, but looking @ the code it is
called on by lcg code and then only on MINIT. So we'd need an extra
syscall to provide this, I am not
41 matches
Mail list logo
