[PHP-DEV] [PATCH] PDO_sqlite data types

[Gwynne Raskind]

The attached patch adds basic support for storing properly-typed  
integer and boolean data in SQLite3 databases. I don't really  
understand why this kind of support has been so consistently lacking  
in PHP database driver implementations. Similar problems have plagued  
the MySQL and MySQLi extensions for a long time, and PDO seems to  
struggle for the support at times. This diff is against PHP 5.2.3,  
but I've verified that it works in 5.2.4RC3, 5.2.4 CVS, and HEAD.  
This by itself disturbs me because it indicates that in all this time  
this code hasn't been touched at all. Was it really that hard to add  
this very simple code?


-- Gwynne, Daughter of the Code
"This whole world is an asylum for the incurable."


Index: ext/pdo_sqlite/sqlite_statement.c
===
RCS file: /repository/php-src/ext/pdo_sqlite/sqlite_statement.c,v
retrieving revision 1.18.2.4.2.2
diff -u -r1.18.2.4.2.2 sqlite_statement.c
--- ext/pdo_sqlite/sqlite_statement.c	1 Jan 2007 09:36:05 -	 
1.18.2.4.2.2

+++ ext/pdo_sqlite/sqlite_statement.c   27 Aug 2007 10:08:42 -
@@ -96,7 +96,22 @@
switch (PDO_PARAM_TYPE(param->param_type)) {
case PDO_PARAM_STMT:
return 0;
-
+   
+   case PDO_PARAM_INT:
+   case PDO_PARAM_BOOL:
+   if (Z_TYPE_P(param->parameter) 
== IS_NULL) {
+			if (sqlite3_bind_null(S->stmt, param->paramno + 1) ==  
SQLITE_OK) {

+   return 1;
+   }
+   } else {
+   
convert_to_long(param->parameter);
+			if (SQLITE_OK == sqlite3_bind_int(S->stmt, param->paramno +  
1, Z_LVAL_P(param->parameter))) {

+   return 1;
+   }
+   }
+   pdo_sqlite_error_stmt(stmt);
+   return 0;
+
case PDO_PARAM_NULL:
if (sqlite3_bind_null(S->stmt, 
param->paramno + 1) == SQLITE_OK) {
return 1;

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Nowdocs revised

[Gwynne Raskind]

On Aug 15, 2007, at 2:00 PM, Christopher Jones wrote:

Did you get any further with merging this?  It would help users of
the XQuery language.

If I understand your intent, I would be able to change the code  
fragment

below to use a nowdoc, and not have to escape the XQuery $i variables.

Chris





I didn't get any further, no :(. The decision of whether to merge the  
nowdocs patch is out of my hands now, since I don't have source  
karma. However, since the main thing standing in the way of its  
implementation was concern over the usefulness, your comment is very  
helpful, and I'd like to open the topic for discussion again on the  
list, if no one out there has any objection :)


-- Gwynne, Daughter of the Code
"This whole world is an asylum for the incurable."

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Nowdocs revised

[Gwynne Raskind]

I've taken my original nowdocs patch and revamped it to be much more  
efficient and functional. This version:


- Parses nowdocs as constant strings rather than ADD_STRING opcodes.
- Allows the flex scanner do less work.
- Enables nowdocs to be used in static_scalar contexts, such as class  
constants and static variable initializers.

- Includes more tests than before.
- Is fully compatible with the most recent CVS checkouts for HEAD and  
PHP_5_2, and also merges cleanly into a 5.2.3 source tree.

- Breaks zero regression tests out of all 3000 or so.

The patch also cleans up the zend_language_scanner.l code a little  
bit, cosmetically speaking, and the PHP_5_2 patch updates the scanner  
by factoring out single-quoted string scanning, as HEAD already did.  
The patch is available for download at phpdoc.gwynne.dyndns.org/nowdocs.zip>, and browsable at phpdoc.gwynne.dyndns.org/nowdocs/>.


-- Gwynne, Daughter of the Code
"This whole world is an asylum for the incurable."

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Nifty feature

[Gwynne Raskind]

On Jul 17, 2007, at 3:44 PM, Rasmus Lerdorf wrote:
Hey Jani, nice job on the unknown configure options check.  I saw  
the
commit go through a couple of days ago, and today it got me to  
clean up
an ancient build script I have been using for ages when it gave  
me this:


Notice: Following unknown configure options were used:

--with-pdflib=/usr/local
--enable-gd-imgstrttf
--with-expat=/usr
--with-xmlreader

Check './configure --help' for available options

This is exactly why I added it. :)

Only side-effect is that any 3rd party extension which happens to use
the AC_ARG_* macros will cause it to report those as "unknown". But
perhaps it's time to be update.. ;)

*cough* APC *cough*
But this check isn't in a phpize-generated configure script, so I  
don't

see how this is a problem.  The number of people who build pecl
extensions in the main source tree can probably be counted on one  
hand.


*raises hand* I do... all the time. *crawls back under her rock*

-- Gwynne, Daughter of the Code
"This whole world is an asylum for the incurable."

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Patch to add "single-quote" heredocs

[Gwynne Raskind]

So I was using create_function() in various ways, and I said to  
myself, "this would look SO much better if I could use a heredoc that  
acted like a single-quoted string". Then I said to myself, "Wait. I  
know the PHP internals. Why don't I build a new syntax into the  
language?" The result was a small modification of the heredoc syntax  
that I call "nowdoc", and it looks like this:




And the output is:

I see 1.
I see $n.

The b modifier is fully supported; a nowdoc acts exactly like a  
single-quoted string, save that you can embed single quotes into it.  
I wrote the patch for HEAD, backported it to PHP_5_2 (both fully up- 
to-date as of this message), and wrote a set of regression tests. The  
patch breaks none of the existing regression tests, and has no BC or  
SC breaks whatsoever, as far as I can tell. The patch can be found at  
. I hope to see it  
included in PHP 6 and 5.3, maybe even 5.2.4 or 5.2.5 since existing  
scripts will continue to work without modification. <<<~ was a parse  
error before, so anyone who used it was doing something wrong anyway.


Side note: I implemented nowdocs in the parser by sharing the heredoc  
code and passing $ and {$ through unmodified instead of replaced. I  
don't understand the way the HEREDOC_CHARS regexps work well enough  
to write a simpler matching rule for the newdocs, but it's clear that  
the patch could be optimized if only I knew how, since the entire  
content can be parsed by a single call to zend_scan_[unicode|binary_] 
escape_string() rather than having to be parsed for replacements. I  
may look into this later, but for the moment I wanted to get what's  
working out there in the commmunity.


-- Gwynne, Daughter of the Code
"This whole world is an asylum for the incurable."

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] RIP PHP 4?

[Gwynne Raskind]

On Jul 6, 2007, at 10:32 AM, Derick Rethans wrote:

Ladies, Gentlemen, Kings and Princesses,

With the nice PHP 5 / PHP 6 unicode semantics thread under way I am
trying to gauge what people feel about dropping support for PHP 4  
at the

end of this year. That does not mean that we will not fix security
issues, we have to as the install base is too large, but that would be
the only thing that would warrant a new release. I already sort of
mentioned this on april 1st, but I think we should come with a  
slightly

more official statement. Your votes please (only -1 and +1 are
allowed)!

regards,
Derick


+1

-- Gwynne, Daughter of the Code
"This whole world is an asylum for the incurable."

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] toString() and Object #ID

[Gwynne Raskind]

On Jul 1, 2007, at 3:24 AM, Pavel Shevaev wrote:

> always helpful). Is there any other way than casting an object to a
> string to get an objects #ID?

spl_object_hash?

Guys, excuse my being a little offtopic here, but why not introduce
standard "get_object_id" function in PHP6 which could be analogous to
"spl_object_hash"? IMHO it's a basic functionality which deserves to
be in the core...


+1 on PHP_FEALIAS()ing this.

-- Gwynne, Daughter of the Code
"This whole world is an asylum for the incurable."

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: documentation of php5ts.dll and .NET wrapper

[Gwynne Raskind]

On Jun 19, 2007, at 4:38 AM, Richard Quadling wrote:

Sara has a nice article about TSRM:
http://blog.libssh2.org/index.php?/archives/22-What-the-heck-is- 
TSRMLS_CC-anyway.html and since you're using php5ts.dll you have  
zts enabled.

Why have ...

TSRMLS_CC

when ...

, TSRMLS_C

actually looks more "correct" when you're reading the code ...

php_myextension_globals_ctor(&myextension_globals TSRMLS_CC);

vs

php_myextension_globals_ctor(&myextension_globals , TSRMLS_C);


I'm not saying change anything, but from someone trying to make
headway with the source, it just looks right (parameters are separated
by a comma not a space).


Because with ZTS off, this would result in:

php_myextension_globals_ctor(&myextension_globals, );

Which would be a syntax error.

-- Gwynne, Daughter of the Code
"This whole world is an asylum for the incurable."

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] CAPTCHA program on CVS account request?

[Gwynne Raskind]

On Jun 18, 2007, at 4:01 PM, Tijnema wrote:

Hello,

I see that there is a lot of spam coming to this list through the CVS
account request form, I think it would be good to add some kind of
CAPTCHA program to this form, so that there wouldn't be (so much) spam
anymore.

Tijnema


+1

-- Gwynne, Daughter of the Code
"This whole world is an asylum for the incurable."

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] CVS Account Request: gwynne

[Gwynne Raskind]

Philip asked me to request an account for working on the Zend Engine 2 
documentation.

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Documenting the Zend2 extension API

[Gwynne Raskind]

On May 8, 2007, at 2:59 PM, Philip Olson wrote:
Hi all, just wanted to give you a heads-up that I'm still working  
on this project; it took me awhile to get the tools properly set  
up, but I'm plugging away at DocBook XML now, and I'll have a few  
patches to send in soon, I think. Thanks for all the advice so far!

Hello Gwynne,

This is excellent news, and feel free to write the doc list if you  
have any questions and/or the IRC channels on efnet (#php.pecl and  
#php.doc). As far as information on the topic goes, let's start a  
list of the current landscape (with ideas to steal from):


- The official docs: http://php.net/manual/internals
- CodeGen_PECL: http://pear.php.net/package/codegen_pecl
- A few tutorials: http://devzone.zend.com/public/view/tag/extension
- The book: Extending and Embedding PHP by Sara Golemon
- Many README files in php-src: http://cvs.php.net/viewvc.cgi/php-src/
- A few talks: http://talks.php.net/index.php/Internals
- A nice talk: http://netevil.org/talks/furlong-golemon-extending- 
php.pdf

- More talks: http://talks.somabo.de/
- A nice talk: http://talks.somabo.de/ 
200610_zend_conf_php_extension_development.pdf

- A few examples: http://people.apache.org/~nabeel/php/examples/

Also, let's create a FAQ section dedicated to the topic of  
extension writing.


This list of links has been extremely helpful to me, Philip; I  
appreciate it a lot :). I'm embarassed to say I came down with a bit  
of writer's block lately, so I don't have any patches to send in yet,  
unfortunately. However, I would like the opinion of the list on the  
avenue I've chosen.


Basically, it's my estimation that the existing internals  
documentation in the manual is not organized very well, nor lends  
itself to updating with any manner of ease. The material I've been  
writing is a new section dedicated to the API of ZE2, rather than  
trying to consolidate all the information for ZE1 (outdated) and ZE3  
(still changing almost every day). My preliminary outline for the  
content looks like this (yanked out of my diffs for manual.xml.in and  
subject to change):



  &Internals2;
  &internals2.intro;
  &internals2.buildsys.index;   
  &internals2.structure.index;  

  &internals2.memory.index; 
  &internals2.variables.index;  
  &internals2.functions.index;  
  &internals2.objects.index;
  &internals2.resources.index;  

  &internals2.ini.index;
  &internals2.streams.index;

  
  &internals2.apiref.index; 
  &internals2.ze1.index;
  &internals2.ze3.index;



My thinking is to document ZE2 completely, since the differences  
between 1 and 2 are small enough for the existing internals section  
to be of use to anyone writing for 1, and 3 can be more fully  
documented later (something I'm willing to take on as well).


If I'm given a thumbs-down on this way of doing things, I'll take the  
material I've written already and use it to update the existing  
internals section, but I think this method has the best chance of  
giving people the truly comprehensive online reference we've lacked  
for extension writing up to this point.


-- Gwynne, Daughter of the Code
"This whole world is an asylum for the incurable."

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Documenting the Zend2 extension API

[Gwynne Raskind]

On May 8, 2007, at 2:59 PM, Philip Olson wrote:
Hi all, just wanted to give you a heads-up that I'm still working  
on this project; it took me awhile to get the tools properly set  
up, but I'm plugging away at DocBook XML now, and I'll have a few  
patches to send in soon, I think. Thanks for all the advice so far!

Hello Gwynne,

This is excellent news, and feel free to write the doc list if you  
have any questions and/or the IRC channels on efnet (#php.pecl and  
#php.doc). As far as information on the topic goes, let's start a  
list of the current landscape (with ideas to steal from):


- The official docs: http://php.net/manual/internals
- CodeGen_PECL: http://pear.php.net/package/codegen_pecl
- A few tutorials: http://devzone.zend.com/public/view/tag/extension
- The book: Extending and Embedding PHP by Sara Golemon
- Many README files in php-src: http://cvs.php.net/viewvc.cgi/php-src/
- A few talks: http://talks.php.net/index.php/Internals
- A nice talk: http://netevil.org/talks/furlong-golemon-extending- 
php.pdf

- More talks: http://talks.somabo.de/
- A nice talk: http://talks.somabo.de/ 
200610_zend_conf_php_extension_development.pdf

- A few examples: http://people.apache.org/~nabeel/php/examples/

Also, let's create a FAQ section dedicated to the topic of  
extension writing.


This list of links has been extremely helpful to me, Philip; I  
appreciate it a lot :). I'm embarassed to say I came down with a bit  
of writer's block lately, so I don't have any patches to send in yet,  
unfortunately. However, I would like the opinion of the list on the  
avenue I've chosen.


Basically, it's my estimation that the existing internals  
documentation in the manual is not organized very well, nor lends  
itself to updating with any manner of ease. The material I've been  
writing is a new section dedicated to the API of ZE2, rather than  
trying to consolidate all the information for ZE1 (outdated) and ZE3  
(still changing almost every day). My preliminary outline for the  
content looks like this (yanked out of my diffs for manual.xml.in and  
subject to change):



  &Internals2;
  &internals2.intro;
  &internals2.buildsys.index;   
  &internals2.structure.index;  

  &internals2.memory.index; 
  &internals2.variables.index;  
  &internals2.functions.index;  
  &internals2.objects.index;
  &internals2.resources.index;  

  &internals2.ini.index;
  &internals2.streams.index;

  
  &internals2.apiref.index; 
  &internals2.ze1.index;
  &internals2.ze3.index;



My thinking is to document ZE2 completely, since the differences  
between 1 and 2 are small enough for the existing internals section  
to be of use to anyone writing for 1, and 3 can be more fully  
documented later (something I'm willing to take on as well).


If I'm given a thumbs-down on this way of doing things, I'll take the  
material I've written already and use it to update the existing  
internals section, but I think this method has the best chance of  
giving people the truly comprehensive online reference we've lacked  
for extension writing up to this point.


-- Gwynne, Daughter of the Code
"This whole world is an asylum for the incurable."

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Documenting the Zend2 extension API

[Gwynne Raskind]

On Apr 25, 2007, at 6:51 PM, Antony Dovgal wrote:
I've been plugging around writing extensions long enough to have  
some  idea of the internals; more than once I've answered a  
question by  digging through the Zend sources for the internals of  
some API.

Great!
I'm  willing to at least take a crack at this project; the worst I  
can do  is fail :). Would it make sense to ask for CVS karma on  
the docs now  or wait a bit?

I believe the best way to get karma is to start sending patches.

I would also recommend to establish the build environment for the  
docs (if you don't have one already), it's good idea to test  
patches before committing.
This document should give you a good start: http://doc.php.net/php/ 
dochowto/index.php


Hi all, just wanted to give you a heads-up that I'm still working on  
this project; it took me awhile to get the tools properly set up, but  
I'm plugging away at DocBook XML now, and I'll have a few patches to  
send in soon, I think. Thanks for all the advice so far!


-- Gwynne, Daughter of the Code
"This whole world is an asylum for the incurable."

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Documenting the Zend2 extension API

[Gwynne Raskind]

On Apr 25, 2007, at 6:05 PM, Antony Dovgal wrote:
Hmm... For some reason I missed that in my searches. That being  
said,  the existence of one doesn't preclude the writing of  
another :).  Also, it seems the official documentation in the PHP  
manual could use  some serious updating, which I would also be  
willing to undertake if  people think that would be more useful.
Actually I've been recently thinking of adding some kind of  
documentation to the sources.
Surely this is not supposed to be something similar to php.net/ 
manual/, just short descriptions of functions and their arguments,  
which can be used as a start for the "real" documentation.
But I wasn't lucky enough to find a utility that would fit my  
(personal) needs.


Doxygen (which seems to be uses by the majority of F/OSS projects)  
generates completely unreadable docs.
Every time I look into ICU docs (generated by Doxygen) I get lost  
for 10 minutes trying to find a function _by name_.
In the same time, other tools do not provide such a wide range of  
output formats as available in Doxygen.


Anyways ZE internals documentation definitely needs serious update  
and this would be very much appreciated.
The only problem is that you need to know the internals a bit (or  
at least want to learn it) to be able to document it, and all the  
people with this knowledge are busy with other things most of the  
time..

You can count on me if you need any help/hints, though.


I've been plugging around writing extensions long enough to have some  
idea of the internals; more than once I've answered a question by  
digging through the Zend sources for the internals of some API. I'm  
willing to at least take a crack at this project; the worst I can do  
is fail :). Would it make sense to ask for CVS karma on the docs now  
or wait a bit?


-- Gwynne, Daughter of the Code
"This whole world is an asylum for the incurable."

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Documenting the Zend2 extension API

[Gwynne Raskind]

On Apr 25, 2007, at 3:33 PM, Derick Rethans wrote:
Given the recent discussion of the lack of real documentation for  
the Zend
API, and the endless links provided to various sources of usually  
incomplete
information, I thought it might be a good idea if someone wrote an  
actual book
on the subject. I'm interested in taking that project upon myself,  
and I'm

wondering what advice anyone has to offer on the idea.

There is one:
http://www.amazon.com/Extending-Embedding-PHP-Developers-Library/dp/ 
067232704X/ref=sr_1_1/102-2890754-1426549? 
ie=UTF8&s=books&qid=1177529537&sr=8-1


Hmm... For some reason I missed that in my searches. That being said,  
the existence of one doesn't preclude the writing of another :).  
Also, it seems the official documentation in the PHP manual could use  
some serious updating, which I would also be willing to undertake if  
people think that would be more useful.


-- Gwynne, Daughter of the Code
"This whole world is an asylum for the incurable."

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Documenting the Zend2 extension API

[Gwynne Raskind]

Given the recent discussion of the lack of real documentation for the  
Zend API, and the endless links provided to various sources of  
usually incomplete information, I thought it might be a good idea if  
someone wrote an actual book on the subject. I'm interested in taking  
that project upon myself, and I'm wondering what advice anyone has to  
offer on the idea.


-- Gwynne, Daughter of the Code
"This whole world is an asylum for the incurable."

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] CVS Account Request: gwynne

[Gwynne Raskind]

I want to contribute to the development of PHP.

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php