On 2005/01/12, at 9:24, Andi Gutmans wrote:
Are you sure this is the right fix? After all, last_op->result.u.var
should already have a temporary variable assigned for when the opcode
was generated. When exactly did you find this is not the case?
As far as I checked, at least a temporary variable
On 2005/01/12, at 17:12, Moriyoshi Koizumi wrote:
However, it looks like the rule doesn't apply to the current HEAD.
Copy'n'paste mistake.. This part should have been like
Moriyoshi
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On 2005/01/12, at 16:31, Kamesh Jayachandran wrote:
Hi Moriyoshi,
Still ent_uni_8592_9002's actual size is 410 but accessed with a index
410.
Huh? I'm confident about it :) It's certainly 411.
#include
static char *ent_uni_8592_9002[] = {
/* 8592 (0x2190) */
"larr", "uarr", "rarr"
Jani Taskinen wrote:
> We only support/use libtool 1.4.3, so..
The detection code for multiple autoconf versions is still wrong, IMHO.
--
Sebastian Bergmann http://www.sebastian-bergmann.de/
GnuPG Key: 0xB85B5D69 / 27A7 2B14 09E4 98CD 6277 0E5B 6867 C514 B85B 5D69
--
PHP
Hi Moriyoshi,
My mistake. I Thought you would have fixed these 2 in one commit and
diffed the latest with earlier one version and found only one fix. Now
things work fine.
With regards
Kamesh Jayachandran
On Wed, 12 Jan 2005 17:27:06 +0900, "Moriyoshi Koizumi"
<[EMAIL PROTECTED]> said:
>
> On
New versions of glibc support a RTLD_DEEPBIND flag to dlopen. The
effect of this flag when loading a "foo.so" with undefined symbols is
that the search that symbol starts at foo.so and its dependencies
*before* the loading process' global symbol table.
This is an effective workaround for symbol n
Hi devs,
after a long discussion on php-general [1], searching the archives and
trying every proposed solution without success I'm asking for your help to
solve the following problem:
class Car {
function drive() {
// I need the name of the calling class here
// in my case it
> With PHP4 it was possible to get the correct class name with
> debug_backtrace(). This behaviour has been changed in PHP5.
> How can I get the name of the extending class that invoked the method in
> drive()?
There was a short discussion on this on this list, too some month ago. The
result was t
"Christian Schneider" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> Torsten Roehr wrote:
> > Something so straightforward and fundamental should be possible!?!
>
> Maybe is isn't as fundamental as you think? I never came across this
> problem in years of PHP programming. But then ag
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, January 12, 2005 6:35 PM
> To: Torsten Roehr
> Cc: internals@lists.php.net
> Subject: Re: [PHP-DEV] Get name of extending class with static method
> call(PHP5)
>
>
> "Torsten Roehr" <[EMAIL PROTECT
Torsten Roehr wrote:
Something so straightforward and fundamental should be possible!?!
Maybe is isn't as fundamental as you think? I never came across this
problem in years of PHP programming. But then again I use classes with
static calls for nothing but separate namespaces :-)
I'm pretty sure
Hey Torsten,
Torsten Roehr wrote:
$persons = Person::load($sql); // returns collection of Person objects
$cars= Car::load($sql);// returns collection of Car objects
Simple solutions:
1) $persons = DB::load('Person', $sql); foreach ($persons as $person)...
2) $person = new Person($sql); whil
Hi Dmitry,
On 2005/01/12, at 18:28, [EMAIL PROTECTED] wrote:
patch for HEAD is incorrect.
You must not edit zend_vm_execute.h directly. You must edit
zend_vm_def.h and then generate zend_vm_execute.h with zend_vm_gen.php.
See README.ZEND_VM for more details.
Excuse me for my ignorance & thank you f
"Daniel Convissor" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> Torsten:
>
> On Wed, Jan 12, 2005 at 04:58:20PM +0100, Torsten Roehr wrote:
>
> > How can I get the name of the extending class that invoked the method in
> > drive()?
>
> class Car {
> function drive($child) {
>
"Johannes Schlueter" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> > With PHP4 it was possible to get the correct class name with
> > debug_backtrace(). This behaviour has been changed in PHP5.
> > How can I get the name of the extending class that invoked the method in
> > drive()?
"Torsten Roehr" <[EMAIL PROTECTED]> writes:
> Hi devs,
>
> after a long discussion on php-general [1], searching the archives and
> trying every proposed solution without success I'm asking for your help to
> solve the following problem:
>
> class Car {
> function drive() {
> // I need
Torsten:
On Wed, Jan 12, 2005 at 04:58:20PM +0100, Torsten Roehr wrote:
> How can I get the name of the extending class that invoked the method in
> drive()?
class Car {
function drive($child) {
echo "parent driven in a $child\n";
}
}
class Porsche extends Car {
function dri
Please don't make broad statements that iODBC and unixODBC are not fast.
They are plenty fast. They run slow in PHP because we use a dynamic
cursor, no other reason can/should be attributed to their performance in
PHP. Our continued use of the dynamic cursor is mostly for BC and my
unwillingn
Hi everyone,
(I sent this question in august last year, but had no replies. Trying
once again as I'm running into the same problem).
While playing with Ldap, Squirrelmail and an Active Directory server I
ran into a limitation of the PHP ldap_modify function.
In general, an (non-PHP) ldap_modify w
Dan Kalowsky wrote:
> As far as including the ODBCRouter in the PHP code, I wanted
> to know more about what it is before it goes further.
Absolutely.
> The website is full of non-useful information regarding what
> ODBCRouter does.
Well, you're too kind. I found the information contained the
Regardless of how self important a patch submitter may sound, there is
no *technical* reason why this patch should not go into PHP; it's not
as though we have a phobia of ODBC drivers.
--Wez.
On Wed, 12 Jan 2005 19:47:14 -0500, Mike Robinson <[EMAIL PROTECTED]> wrote:
> > If it is another case of
I committed the patch to HEAD; I'll leave it to the release masters to
decide if they want it in the next 4.3 and 5 releases.
--Wez.
On Wed, 12 Jan 2005 21:03:41 -0500, Wez Furlong <[EMAIL PROTECTED]> wrote:
> Regardless of how self important a patch submitter may sound, there is
> no *technical*
On Wed, 12 Jan 2005 18:46:24 -0800, Dan Kalowsky <[EMAIL PROTECTED]> wrote:
> There is a technical reason to avoid it if you've listened to any of my
> past efforts to move uODBC forward in time.
No offense Dan, but ext/odbc has been idle for more than a year;
please don't take it personally when
On Jan 12, 2005, at 6:03 PM, Wez Furlong wrote:
Regardless of how self important a patch submitter may sound, there is
no *technical* reason why this patch should not go into PHP; it's not
as though we have a phobia of ODBC drivers.
There is a technical reason to avoid it if you've listened to any
24 matches
Mail list logo
