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,
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 wo
At 10:57 PM 10/22/2004 +0200, dharana wrote:
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 mean
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
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 gues
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
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 ind
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
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 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']
George
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
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 t
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 t
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
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, 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
> anythin
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 get_parent_class()
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: http
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
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
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
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
--
PHP
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
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 members
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.
Lib
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 a
> > 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 com
On Fri, 22 Oct 2004, Hans Zaunere wrote:
> 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.
> > > > 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 p
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 h
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 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 whe
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
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
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 funct
I added some stuff along these lines 3 weeks ago:
http://viewcvs.php.net/viewcvs.cgi/pecl/pdo/pdo_stmt.c.diff?r1=1.47&r2=1.48
+/* {{{ proto int PDOStatement::columnCount()
+ Returns the number of columns in the result set */
+/* {{{ proto array PDOStatement::getColumnMeta(int $column)
+ Retu
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
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 the
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
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.m
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 del
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
42 matches
Mail list logo
