[PHP-DEV] Differences in VC6 and VC9 Windows builds and MSSQL Driver.
Hi. With regard to http://bugs.php.net/bug.php?id=46971, how much effort is needed (if any) to document that some functionality is not going to be available in all windows builds? [DOC] Or, When will VC6 be dropped? [CORE and DOC] Admittedly, it is only an issue for Microsoft SQL Server (mssql and pdo_mssql) and for Sybase_ct. With Microsoft having their own PHP extension for talking to MSSQL (http://www.microsoft.com/sqlserver/2005/en/us/PHP-Driver.aspx - though documented to only support SQL 2005 and 2008, not 7 or 2000), could this become the standard alternative for php_mssql.dll (though not PDO as the MS extension is procedural only, leaving ODBC as the route for older versions? -- - Richard Quadling Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498r=213474731 Standing on the shoulders of some very clever giants! -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Differences in VC6 and VC9 Windows builds and MSSQL Driver.
Hi Richard, I am not sure, if VC6 can be dropped easily. E.g. some SAPIs that directly map into servers may have problems if using the wrong CRT. Until now, I had no time to build up a Windows Sun Java System Webserver and test it with both CRTs. The code compiles fine on the snaps box, but I am not sure, if the DLL loads into the server. To the snaps build: The NSAPI module tests for #define ZTS and does therefore not compile without thread safety. Why do the windows non-ts builds on snaps.php compile? Is ZTS on windows always defined (it looks like so in the makefile). How to test on windows, if thread safety is available? But better would be to disable thread-unsafe builds for the NSAPI SAPI from the beginning. Uwe - Uwe Schindler theta...@php.net - http://www.php.net NSAPI SAPI developer Bremen, Germany -Original Message- From: Richard Quadling [mailto:rquadl...@googlemail.com] Sent: Wednesday, December 31, 2008 11:12 AM To: PHP Documentation ML; PHP Developers Mailing List Subject: [PHP-DEV] Differences in VC6 and VC9 Windows builds and MSSQL Driver. Hi. With regard to http://bugs.php.net/bug.php?id=46971, how much effort is needed (if any) to document that some functionality is not going to be available in all windows builds? [DOC] Or, When will VC6 be dropped? [CORE and DOC] Admittedly, it is only an issue for Microsoft SQL Server (mssql and pdo_mssql) and for Sybase_ct. With Microsoft having their own PHP extension for talking to MSSQL (http://www.microsoft.com/sqlserver/2005/en/us/PHP-Driver.aspx - though documented to only support SQL 2005 and 2008, not 7 or 2000), could this become the standard alternative for php_mssql.dll (though not PDO as the MS extension is procedural only, leaving ODBC as the route for older versions? -- - Richard Quadling Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498r=213474731 Standing on the shoulders of some very clever giants! -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Differences in VC6 and VC9 Windows builds and MSSQL Driver.
hi Richard, On Wed, Dec 31, 2008 at 11:11 AM, Richard Quadling rquadl...@googlemail.com wrote: Hi. With regard to http://bugs.php.net/bug.php?id=46971, Can you repost (and subscribe to the list if you did not subscribe yet) to the right list please (Windows Internals list)? Thanks, -- Pierre http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [INTERNALS-WIN] [REPOST] Differences in VC6 and VC9 Windows builds and MSSQL Driver.
hi, On Wed, Dec 31, 2008 at 12:37 PM, Uwe Schindler theta...@php.net wrote: In general (this is why I also write to the internals list): DBLIB is no longer supported by Sybase, CT is preferred, according to Sybase. We are working with Sybase on this problem. I met them last year and we will get all SDKs, libs, docs or tools we will need to build sybase_ct for windows using VC9. Cheers, -- Pierre http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] RE: [INTERNALS-WIN] [REPOST] Differences in VC6 and VC9 Windows builds and MSSQL Driver.
In general (this is why I also write to the internals list): DBLIB is no longer supported by Sybase, CT is preferred, according to Sybase. We are working with Sybase on this problem. I met them last year and we will get all SDKs, libs, docs or tools we will need to build sybase_ct for windows using VC9. Great, be sure to also check Sybase 12.5 CTLIB. A lot of servers and tools still run with Sybase 12.5. Or, you should write in the documentation, that it would be enough, to make copies of your Sybase 12.5 DLLS, with syb in the name (this is documented on Sybase homepage and the CTLIB documentation, but for the other way round: A .cmd script, that copies all DLLs to be able to run programs compiled with the old DLL names). If I can help, I have the Sybase 15 and 12.5 CTLIB headers and LIBS here, for some first tests. We have contacts to Sybase Germany (we are the biggest *educational* customer in Germany, see http://www.sybase.com/detail?id=1052607), maybe we can help. If using CTLIB, you are also able to use the Sybase Data Warehouse (Sybase IQ). I never got this working correctly with FreeTDS. On the other hand: I prefer to use ODBC on windows and also UNIX, this makes life a little bit simplier. Uwe -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] [RFC] Re: [PHP-DEV] __invoke() weirdness
Hello David,
Tuesday, December 23, 2008, 5:02:43 PM, you wrote:
Hi folks,
I played with __invoke today:
class Curry
{
protected $callable;
protected $args;
public static function create($callable)
{
$curry = new self($callable, array_slice(func_get_args(), 1));
return $curry;
}
protected function __construct($callable, $args)
{
$this-callable = $callable;
$this-args = $args;
}
public function __invoke()
{
return call_user_func_array($this-callable, array_merge($this-
args, func_get_args()));
}
}
However, it doesn't work consistently.
This works fine:
$d = new DateTime();
$getAtom = Curry::create(array($d, 'format'), DATE_ATOM);
echo $getAtom();
This gives a fatal Call to undefined method DateTime::getAtom()
$d = new DateTime();
$d-getAtom = Curry::create(array($d, 'format'), DATE_ATOM);
echo $d-getAtom();
Is that intentional?
So far it is. Yet I as much as you do not like the inconsistency. So I
spend a little bit on providing the following patch that should do what
you were looking for.
The disadvantage: Calling properties is case sensitive while calling
methods isn't. But since this has nothign to do with this patch and the
patch only increases consistency I am all for applying it.
Comments? Lukas/Johannes?
Oh I hate that case insensitivity and inconsistency
Cheers,
David
Best regards,
MarcusIndex: Zend/zend_object_handlers.c
===
RCS file: /repository/ZendEngine2/zend_object_handlers.c,v
retrieving revision 1.135.2.6.2.22.2.23
diff -u -p -d -r1.135.2.6.2.22.2.23 zend_object_handlers.c
--- Zend/zend_object_handlers.c 31 Dec 2008 11:15:32 -
1.135.2.6.2.22.2.23
+++ Zend/zend_object_handlers.c 31 Dec 2008 16:26:52 -
@@ -791,6 +791,22 @@ static union _zend_function *zend_std_ge
zobj = Z_OBJ_P(object);
if (zend_hash_find(zobj-ce-function_table, lc_method_name,
method_len+1, (void **)fbc) == FAILURE) {
+ if (Z_OBJ_HT_PP(object_ptr)-read_property) {
+ zval *callable, property, *callable_obj;
+ zend_class_entry *ce_ptr;
+
+ INIT_PZVAL(property);
+ ZVAL_STRINGL(property, method_name, method_len, 0);
+ callable =
Z_OBJ_HANDLER_PP(object_ptr,read_property)(*object_ptr, property, BP_VAR_IS
TSRMLS_CC);
+
+ if (Z_TYPE_P(callable) == IS_OBJECT
+Z_OBJ_HANDLER_P(callable, get_closure)
+Z_OBJ_HANDLER_P(callable, get_closure)(callable,
ce_ptr, fbc, callable_obj TSRMLS_CC) == SUCCESS) {
+ *object_ptr = callable_obj;
+ free_alloca(lc_method_name, use_heap);
+ return fbc;
+ }
+ }
free_alloca(lc_method_name, use_heap);
if (zobj-ce-__call) {
zend_internal_function *call_user_call =
emalloc(sizeof(zend_internal_function));
Index: Zend/tests/closure_033.phpt
===
RCS file: Zend/tests/closure_033.phpt
diff -N Zend/tests/closure_033.phpt
--- /dev/null 1 Jan 1970 00:00:00 -
+++ Zend/tests/closure_033.phpt 31 Dec 2008 16:26:52 -
@@ -0,0 +1,31 @@
+--TEST--
+Closure 033: Calling property Closure
+--FILE--
+?php
+
+class Test {
+ public $func;
+ function __construct() {
+ $this-func = function() {
+ echo __METHOD__ . ()\n;
+ };
+ }
+}
+
+$o = new Test;
+ReflectionProperty::export($o, 'func');
+var_dump($o-func);
+$f = $o-func;
+$f();
+$o-func();
+
+?
+===DONE===
+--EXPECTF--
+Property [ default public $func ]
+
+object(Closure)#%d (0) {
+}
+Test::{closure}()
+Test::{closure}()
+===DONE===
Index: Zend/tests/closure_034.phpt
===
RCS file: Zend/tests/closure_034.phpt
diff -N Zend/tests/closure_034.phpt
--- /dev/null 1 Jan 1970 00:00:00 -
+++ Zend/tests/closure_034.phpt 31 Dec 2008 16:26:52 -
@@ -0,0 +1,46 @@
+--TEST--
+Closure 034: Calling property supporting __invoke
+--FILE--
+?php
+
+class Curry
+{
+ protected $callable;
+ protected $args;
+
+ public static function create($callable)
+ {
+$curry = new self($callable, array_slice(func_get_args(), 1));
+return $curry;
+ }
+
+ protected function __construct($callable, $args)
+ {
+$this-callable = $callable;
+$this-args = $args;
+ }
+
+ public function __invoke()
+ {
+return call_user_func_array($this-callable, array_merge($this-args,
func_get_args()));
+ }
+}
+
+$d = new DateTime();
+$getAtom = Curry::create(array($d, 'format'), DATE_ATOM);
+var_dump(is_Callable($getAtom));
+var_dump($getAtom());
+
+$d = new
Re: [PHP-DEV] [RFC] Re: [PHP-DEV] __invoke() weirdness
Marcus Boerger schrieb: Oh I hate that case insensitivity and inconsistency I am all for reducing inconsistencies (and not introducing new ones :-). -- Sebastian Bergmann http://sebastian-bergmann.de/ GnuPG Key: 0xB85B5D69 / 27A7 2B14 09E4 98CD 6277 0E5B 6867 C514 B85B 5D69 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] PHP compiling
Hey Folks! I've got a error in compiling PHP ( 5.3+ ) (or executing the compiled PHP bin). It occurs with including php_xdebug.dll (alt. known as xDebug Server ). When executing the compiled binary of PHP. Any suggestions? Thanks, -- (c) Kenan Sulayman Freelance Designer and Programmer Life's Live Poetry http://MyJurnal.tk/
Re: [PHP-DEV] [RFC] Re: [PHP-DEV] __invoke() weirdness
Hi Markus,
have you measured the performance impact in a class with - say - ten
methods? And what to do with __get() and __call()? How are the
prioritized in the method resolve order?
cu, Lars
Am Mittwoch, den 31.12.2008, 17:38 +0100 schrieb Marcus Boerger:
Hello David,
Tuesday, December 23, 2008, 5:02:43 PM, you wrote:
Hi folks,
I played with __invoke today:
class Curry
{
protected $callable;
protected $args;
public static function create($callable)
{
$curry = new self($callable, array_slice(func_get_args(), 1));
return $curry;
}
protected function __construct($callable, $args)
{
$this-callable = $callable;
$this-args = $args;
}
public function __invoke()
{
return call_user_func_array($this-callable, array_merge($this-
args, func_get_args()));
}
}
However, it doesn't work consistently.
This works fine:
$d = new DateTime();
$getAtom = Curry::create(array($d, 'format'), DATE_ATOM);
echo $getAtom();
This gives a fatal Call to undefined method DateTime::getAtom()
$d = new DateTime();
$d-getAtom = Curry::create(array($d, 'format'), DATE_ATOM);
echo $d-getAtom();
Is that intentional?
So far it is. Yet I as much as you do not like the inconsistency. So I
spend a little bit on providing the following patch that should do what
you were looking for.
The disadvantage: Calling properties is case sensitive while calling
methods isn't. But since this has nothign to do with this patch and the
patch only increases consistency I am all for applying it.
Comments? Lukas/Johannes?
Oh I hate that case insensitivity and inconsistency
Cheers,
David
Best regards,
Marcus
-- PHP Internals - PHP Runtime Development Mailing List To unsubscribe,
visit: http://www.php.net/unsub.php
--
Jabber: l...@strojny.net
Weblog: http://usrportage.de
signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil
Re: [PHP-DEV] PHP compiling
On Wed, Dec 31, 2008 at 12:42, Kenan R Sulayman kur...@kkooporation.de wrote: Hey Folks! I've got a error in compiling PHP ( 5.3+ ) (or executing the compiled PHP bin). It occurs with including php_xdebug.dll (alt. known as xDebug Server ). When executing the compiled binary of PHP. Any suggestions? The best suggestions we can offer so far: 1.) This isn't an issue (at least from the sounds of it) for the Internals list, and is better-suited to the Install and Xdebug lists. This reply goes to both so that you can find those lists. 2.) You never mentioned what the error states. Remember to include that when asking for help. 3.) Despite the insinuation that it's Windows based upon the DLL, we have no real idea what operating system and version you're using. Please include that as well. Please forward the information for #2 and #3 to either the Install list or the Xdebug list, as appropriate. -- /Daniel P. Brown daniel.br...@parasane.net || danbr...@php.net http://www.parasane.net/ || http://www.pilotpig.net/ Unadvertised dedicated server deals, too low to print - email me to find out! -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Re: [PHP-DEV] __invoke() weirdness
Hello Lars,
Wednesday, December 31, 2008, 6:59:08 PM, you wrote:
Hi Markus,
have you measured the performance impact in a class with - say - ten
methods? And what to do with __get() and __call()? How are the
prioritized in the method resolve order?
Translated into user code we now have:
public function __zend_call($name, $args) {
// Added property lookup
if (isset($this-$name)) {// may call __isset
$callable = $this-$name; // may call __get
if (is_callable($callable)) {
return call_user_func_array($callable, $args);
}
}
// Original behavior:
// Check for __call
if (method_exists($this, '__call')) {
return $this-__call($name, $args);
}
// error
error_log('Function ' . __CLASS__ . '::' . $name . ' not found');
return NULL;
}
As to the performance impact. We add one additional hash-lookup per
method call on a default class for a non found function. So whenever
we would normally call __call we add an additional lookup.
cu, Lars
Am Mittwoch, den 31.12.2008, 17:38 +0100 schrieb Marcus Boerger:
Hello David,
Tuesday, December 23, 2008, 5:02:43 PM, you wrote:
Hi folks,
I played with __invoke today:
class Curry
{
protected $callable;
protected $args;
public static function create($callable)
{
$curry = new self($callable, array_slice(func_get_args(), 1));
return $curry;
}
protected function __construct($callable, $args)
{
$this-callable = $callable;
$this-args = $args;
}
public function __invoke()
{
return call_user_func_array($this-callable, array_merge($this-
args, func_get_args()));
}
}
However, it doesn't work consistently.
This works fine:
$d = new DateTime();
$getAtom = Curry::create(array($d, 'format'), DATE_ATOM);
echo $getAtom();
This gives a fatal Call to undefined method DateTime::getAtom()
$d = new DateTime();
$d-getAtom = Curry::create(array($d, 'format'), DATE_ATOM);
echo $d-getAtom();
Is that intentional?
So far it is. Yet I as much as you do not like the inconsistency. So I
spend a little bit on providing the following patch that should do what
you were looking for.
The disadvantage: Calling properties is case sensitive while calling
methods isn't. But since this has nothign to do with this patch and the
patch only increases consistency I am all for applying it.
Comments? Lukas/Johannes?
Oh I hate that case insensitivity and inconsistency
Cheers,
David
Best regards,
Marcus
-- PHP Internals - PHP Runtime Development Mailing List To unsubscribe,
visit: http://www.php.net/unsub.php
Best regards,
Marcus
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Re: [PHP-DEV] __invoke() weirdness
On Wed, Dec 31, 2008 at 20:12, Marcus Boerger he...@php.net wrote:
Hello Lars,
Wednesday, December 31, 2008, 6:59:08 PM, you wrote:
Hi Markus,
have you measured the performance impact in a class with - say - ten
methods? And what to do with __get() and __call()? How are the
prioritized in the method resolve order?
Translated into user code we now have:
public function __zend_call($name, $args) {
// Added property lookup
if (isset($this-$name)) {// may call __isset
$callable = $this-$name; // may call __get
Uhmm. I hope I got this wrong as:
class foo {
function __isset() {
return true;
}
function __get() {
return hello world;
}
function __call() {
}
}
$foo = new foo;
$foo-foobar();
will first execute __isset(), then __get() and then __call()? That is
a major backwards compatibility break, and increases the inconsistency
and decreases readability 10times
-Hannes
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] PF 2009
PF 2009 for PHP internals! And good luck in finishing the PHP 5.3. David G. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] __getStatic
On Sun, Oct 19, 2008 at 3:01 PM, Timm Friebe the...@thekid.de wrote: Hi, First of all, thanks for reviewing and the feedback. I knew this wasn't perfect, and tried to understand what was previously done for __get and __set and transport that to the static counterparts. Unfortunately not all infrastructure like the std_*_property_handler callbacks is in place for static properties so this had to be created, too. Lukas writes: hmm .. i also emailed Timm a few weeks ago and got no reaction. the question now is .. does someone else care enough to work through the issues Stas has noted to get things in shape to be committed? I've been quite busy with personell and budget planning at our company and have thus had neither time yet to shift through my private e-mail nor to do any programming, be it for private projects or for PHP. I was hoping someone else might pick up on this patch and try to complete it, it's been asked for a couple of times in different forums / newsgroups / this list (a Google search reveals these). On the other hand, there's only one really good use-case that pops to my mind for __getStatic(), and maybe the type-safe object properties pattern Sebastian (Bergmann) had in his blog may be another one, but nothing people would care enough for (especially once compared to the feelings around namespaces), so that's probably why this hasn't happened!:-) Stas writes: This patch is definitely not ready, so I'd wait with it unless we get really good one very-very soon. I guess very-very soon is already over, and yes, absolutely, this patch is far from perfection, so I'd also delay it. Maybe someone (Lars from http://wiki.php.net/rfc/static-classes?) might also want to gather some motivation for the __*Static() methods as in good use cases... - Timm Any news on this? :) I don't see this in 5.3 but are there any hopes for pushing this on the HEAD of 6 sometime soon? :)
