Re: [PHP-DEV] PHP 5.3 Windows builds, pdo_sqlite
Using the non-VC9 nts build (and after erasing sqlite files so they get created from scratch) I can have PDO sqlite create a table, and add records, but not delete records (SQLSTATE[HY000]: General error: 1 SQL logic error or missing database). Reverting to 5.2.x works again. We use a cache layer that can switch between APC, memcached, and sqlite depending on what we are trying to cache. Locally though, APC is not available for these PHP builds, and i don't have memcached running, so I have to use sqlite. Which is not working. So I'm zero for three and can't test much else. When is alpha 3? On Wed, Sep 10, 2008 at 7:33 AM, Daniel Henning <[EMAIL PROTECTED]> wrote: > Hi lists, > > there is a Problem with pdo_sqlite in PHP 5.3. (downloaded half an hour ago > from snaps) > I've sent a report here : > http://pecl.php.net/bugs/bug.php?id=14098 > > Anyway php_pdo_sqlite_external doesn't have this problem but isn't available > in 5.3 windows-builds anymore. > > Is it possible to activate this extension by default since it is the same > source like "normal" pdo_sqlite? > > > kind regards, > Daniel > > -- > 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] namespace issues
2008/9/22 Stanislav Malyshev <[EMAIL PROTECTED]> > Hi! > > 3. Functions will not be allowed inside namespaces. We arrived to > conclusion that they are much more trouble than they're worth, and summarily > we would be better off without them. Most of the functionality could be > easily achieved using static class methods, and the rest may be emulated > with variable function names, etc. > > Comments? > -- > Stanislav Malyshev, Zend Software Architect > [EMAIL PROTECTED] http://www.zend.com/ > (408)253-8829 MSN: [EMAIL PROTECTED] > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php That means, that if I have a tiny, 70-100 line script and I use a package in a namespace with some global functionality - it should be 100% OOP? Sorry, but that's OOP for the sake of OOP. It's like writing "Hello world!" using patterns (here is an example: http://www.phppatterns.com/docs/design/hello_world_in_patterns) -1 on this.
Re: [PHP-DEV] namespace issues
On Thursday 25 September 2008 9:08:27 am Lukas Kahwe Smith wrote: > > No, namespaces for functions can most certainly *not* be emulated > > with either > > variable functions or static methods. Dropping namespace support for > > functions makes namespaces mostly useless for anyone who is not 100% > > OOP. > > There's no reason to make functions second-class citizens (no pun > > intended). > > sure point taken on the monolithic files, when sticking different > functions into classes just for the sake of them then becoming > namespaceable. but how would allowing functions in namespaces solve > this issue? > > regards, > Lukas Kahwe Smith > [EMAIL PROTECTED] Functions in namespaces serve the same purpose as classes in namespaces, for whatever that purpose is this week. :-) It allows for shorter function names for related functions (that cannot be part of the same class for practical architectural reasons, as mentioned, or for conceptual reasons) and for clustering of functionality in ways that classes are ill-suited for. Another advantage is for differentiation. One problem we have run into in Drupal is that if we have a function named "foo_bar_baz()", is that the "bar_baz()" function of the "foo" module/namespace or is it the "baz()" function of the "foo_bar" module/namespace? (We are trying to implement some performance enhancement logic that depends on knowing the difference between those two case.) Note that we cannot forbid such modules/namespaces as anyone can write a module named whatever they feel like. In theory we could use a double underscore, foo__bar_baz(), but that's just as silly as class Zend_Controller_Factory_View_Plugin_Thing. Ideally we could do foo::bar_baz(), eliminate the ambiguity, and make it easier for module developers, too. Just define your module as a namespace and then you always have a function bar_baz() inside it. And we can continue to split modules across multiple files (absolutely critical for performance) and allow modules to define functions on behalf of another module (absolutely critical for functionality). See the sample code I posted back on 9/9 in response to your request for implementations. My point in the GP post is that "you can just use static methods" to emulate namespaces for functions is wrong, and cannot be used as an argument that functions do not need or should not get namespaces. -- Larry Garfield [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PHP] PHP 5.3.0alpha2
OK, I finally went to do it and this link doesn't work: PHP 5.3.0alpha2 VC9 x86 http://downloads.php.net/pierre/php-5.3.0alpha2-nts-Win32-VC9.zip On Thu, Sep 4, 2008 at 5:23 AM, Johannes Schlüter <[EMAIL PROTECTED]> wrote: > On Wed, 2008-09-03 at 23:36 -0700, steve wrote: >> It is pretty much include() and its relatives. Autoloading with a lot >> of possible include paths. I'm sure if you had a Zend Framework App >> and put it on Windows, and took out all the require_onces with paths >> in them > > Try 5.3 please, our implementation of realpath(), one of the biggest > require_once slowdowns, as well as other parts were improved quite a > lot. > > Feedback is welcome :-) > > johannes > > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP Suspendable requests for Apache
>> Not true.. Tomcat supports comet, and it runs on APR. Yes, the thread pool >> is small, but there is always a solution. The idea is to return the thread >> back to Apache's thread pool while waiting for an event: >> http://tomcat.apache.org/tomcat-6.0-doc/aio.html > > Then convince the Apache developers to implement the feature in Apache > httpd... They are not interested. If you want to have comet apps and stream bits of data fast for email (gmail) or stockprices in the middle of your text (marketwatch) then you have to go use other tools. If you *must* use PHP, you will have to write your own long lasting web server in PHP -- but note that PHP was not designed for that. Neither was apache. There is a reason why all the comet stuff is written in other languages and use other web servers. Best bet -- use another tool stack. Typically you have have it call into other code as needed (like PHP) for things like authentication or data collection, and since the usage pattern is different, you probably want it on a separate cluster anyway. http://cometdaily.com/ is a better channel to gather some info. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] OpenSSL random pseudo bytes
Scott MacVicar escribió: > If you don't care don't pass a parameter. ohh.. right, I misinterpreted it .. sorry ;) -- "A computer is like an Old Testament god, with a lot of rules and no mercy. " Cristian Rodríguez R. Platform/OpenSUSE - Core Services SUSE LINUX Products GmbH Research & Development http://www.opensuse.org/ signature.asc Description: OpenPGP digital signature
Re: [PHP-DEV] OpenSSL random pseudo bytes
On 25 Sep 2008, at 22:59, Cristian Rodríguez <[EMAIL PROTECTED]> wrote: Scott MacVicar escribió: Hi All, Attached and uploaded [1] is a patch to add the OpenSSL random pseudo byte function, at the moment it will return FALSE if the bytes aren't considered cryptographically strong, I am however considering making this parameter controlled. Any objections to me applying this to 5.3? Scott -- [1] - http://whisky.macvicar.net/patches/openssl_prg.patch.txt What is the status of this ? I see nothing that can break with this patch, but I would suggest the function to take the second argument by value instead of by reference, valid code like causes a Fatal error: Only variables can be passed by The second parameter indicates if the resultant data was strong random data. It's not an option. By default it is strong, if it runs out of data it will be weak. If you don't care don't pass a parameter. Scott -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] OpenSSL random pseudo bytes
Scott MacVicar escribió: > Hi All, > > Attached and uploaded [1] is a patch to add the OpenSSL random pseudo > byte function, at the moment it will return FALSE if the bytes aren't > considered cryptographically strong, I am however considering making > this parameter controlled. > > Any objections to me applying this to 5.3? > > Scott > -- > [1] - http://whisky.macvicar.net/patches/openssl_prg.patch.txt > > What is the status of this ? I see nothing that can break with this patch, but I would suggest the function to take the second argument by value instead of by reference, valid code like causes a Fatal error: Only variables can be passed by reference... -- "A computer is like an Old Testament god, with a lot of rules and no mercy. " Cristian Rodríguez R. Platform/OpenSUSE - Core Services SUSE LINUX Products GmbH Research & Development http://www.opensuse.org/ signature.asc Description: OpenPGP digital signature
Re: [PHP-DEV] Classes userland lookup (with namespaces)
And just to answer to myself, here's a sample implementation of the __resolve() magic function. It's missing its second and third parameters and is still far from the final goal of this implementation, but at least it allows me to demonstrate a bit how this works. For example uses & interest, please see my mail from Thu, 25 Sep 2008 07:26:17 +0200. Patch against PHP 5.3.0alpha2: http://ookoo.org/svn/snip/php-5.3.0alpha2_resolve_class.patch Example of something which became possible (it just demonstrates that the whole thing works): http://ookoo.org/svn/snip/resolver_test.php Now I'll try to find out how I'll get the two last arguments (current namespace and use list) and try to make a proper patch out of this so it may have chances (?) to be looked at. The patch url points to a SVN and the file will be updated as soon as I improve the code. The name of the magic function isn't defined either, I guess calling it __resolveclass() would be better than __resolve(), but I was hoping to get some answers from the list. Mark Le jeudi 25 septembre 2008 à 07:26 +0200, Mark a écrit : > Hi, [...] > > Best regards, > Mark Karpeles -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP opcode documentation
zoe wrote: I have some PHP opcode documentation which might be useful, an html version is linked here: http://www.zapt.info/opcodes.html. Cool. I think the php-doc folks can help you come up with something for this. I have cc'ed them. Not sure how easy it will be to convert to docbook-xml, but I am sure we can come up with something. This is a big hole in the docs that would be great to fill. Thanks a lot for the work and the contribution. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] namespace issues
Hi! Right, Stas, did you also discuss removal of constants? Seems logical as the really the same arguments apply. IMO constants do not produce that much trouble, since they are not as extensively used than methods and functions. -- Stanislav Malyshev, Zend Software Architect [EMAIL PROTECTED] http://www.zend.com/ (408)253-8829 MSN: [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] true namespaces, yet another point of view
I share your thoughts and yes namespaces are needed and wanted, but what's implemented at the moment is quite far from what I'd call a namespace. I need and want to see there all language entities including variables, constants, classes, interfaces, and functions. Want to see them all supported by namespaces or nothing. -JV >I disagree here...it is both wanted and and needed. This feature has been >promised to the community for quite some time now and I'd simply remind you >you do have the option of *not* using namespaces if you don't want too. If >you like REALLY_LONG_CLASS_NAMES that's still perfectly valid. Don't like >it, don't use it but I think working through the remaining issues and >getting it out is important. Making right decision on the approach is >important too and from an outsiders point of view a lot of progress has >been made and it now seems very, very close to being a reality. Ditching >it should be the last thing considered. > > I can't say it enough, if you don't like where the namespace > implementation ends up you can simply decide not to use it. > > --Tony > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] true namespaces, yet another point of view
> > or just leave the organization of things to classes (with long class > names with a nice prefix to prevent collissions) and leave it to > class_alias() (and equivalent features for functions .. also with the > option of a compile time aliasing) to handle the aliasing. > > this removes the need for namespaces and use statements, while making it > possible to make class/function names short (that are long for > organizational and collision prevention reasons). > > regards, > Lukas Kahwe Smith > > No, you can't use classes for this. They can't contain the other classes and you can't have a class spanned across several files. There are some other important differences from the compiler perspecives, but still namespaces and classes are containers and you can access their members with exactly the same syntax constructs so it's not only possible but reasonable to implement them very close to each other, as I suggested in one hashtable. As a side effect it will remove the problem with class vs namespace ambiguity. JV -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Fix Bug #46145
According to CVS, it has been that way since at least April of 2002. The last time anyone touched it was a year and a half ago to clean up whitespace. So you're right, this very well may be a "won't fix". In that case, let's mark it as such. Ilia On Thu, Sep 25, 2008 at 12:27 AM, Jani Taskinen <[EMAIL PROTECTED]>wrote: > Ilia Cheishvili wrote: > >> Hey all, >> >> This patch addresses the *printf() bug when dealing with exponents (%e). >> See http://bugs.php.net/bug.php?id=46145 for more details. >> >> The patch is large because there were a lot of unit tests written to >> expect the wrong behavior, so I had to update them. I realize that there is >> the possibility that we might decide to label this as a "won't fix", but I >> figured I might as well put forth the effort :) >> > > You can always make separate patches (preferred) for tests and code > changes. :) > > When did it start misbehaving anyway? If it was like that all the time -> > wont fix, depending of course how long %e has existed.. > > --Jani > >
[PHP-DEV] PHP opcode documentation
Hi I have some PHP opcode documentation which might be useful, an html version is linked here: http://www.zapt.info/opcodes.html. The hard work (writing the samples) was all done by Mich and Toyo. All I've done is written some PHP and used a slightly modified VLD to be able to automatically generate the web page from the sample code. Sara said this could also be done with parsekit, but by that time I'd already fixed VLD (if Derick forgets to apply my VLD patch I'll swap my script to use parsekit :-) ). There are a few codes that don't have samples yet, but these can be added easily by just dropping code into the right directory and then re-running the PHP. I'd like to put the samples and scripts somewhere, but where? It would be good to have them somewhere that people could add the missing samples if they have them. Zoë -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] namespace issues
On 23.09.2008, at 09:47, Dmitry Stogov wrote:
Stanislav Malyshev wrote:
Hi!
On the ZendCon, we (Marcus, Elizabeth, Andi and myself) had a talk
about
what we'd like to do with namespaces, and we arrived at the following
conclusions, which we propose to implement in 5.3:
1. Allow braces for namespaces. So, the syntax for namespaces will
be:
a) namespace foo;
should be first (non-comment) statement in the file, namespace
extends
to the end of the file or next namespace declaration.
b) namespace foo {}
can appear anywhere on the top scope (can not be nested).
Mixing both syntaxes in one file is not possible. The semantics of
both
syntaxes will be identical.
2. Simplify resolution order for classes in the namespace:
unqualified
names are resolved this way:
a) check "use" list if the name was defined at "use", follow that
resolution
b) if not, the name resolves to namespace::name
Consequence of this will be that for using internal class inside
namespace one would need to refer to it either as ::Foo or do
use ::Foo
prior to its usage.
3. Functions will not be allowed inside namespaces. We arrived to
conclusion that they are much more trouble than they're worth, and
summarily we would be better off without them. Most of the
functionality
could be easily achieved using static class methods, and the rest
may be
emulated with variable function names, etc.
Comments?
Great, lets castrate the language to make it consistent. :(
1. I am fine with (1), except for unspecified scope of "use" statement
inside namespace with bracket. I assume it should affect only current
declaration and not the following namespace declarations (even with
the
same name).
2. This is acceptable only if we accept (3) otherwise we will need to
write ::strlen() and so on.
3. In case we remove functions we also need to remove constants as
they
have exactly the same ambiguity problems. It's unclear for me what the
following code will define after all (global function or just emit a
parse error?)
Right, Stas, did you also discuss removal of constants? Seems logical
as the really the same arguments apply.
regards,
Lukas Kahwe Smith
[EMAIL PROTECTED]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] namespace issues
On 23.09.2008, at 05:39, Larry Garfield wrote: "Most of the functionality could be easily achieved using static class methods". As someone who uses both functions and classes with equal comfort, I have to say "GAH, NO NO NO!" to that statement. Classes as pseudo- namespaces are fundamentally wrong. Conceptually they're entirely different things. I have to shut people down every time they try to suggest that in Drupal. It's not just a conceptual issue, either. For a very practical example, consider that a namespaces can be split across any number of files. A class must be all in one file. That means if you want to group functions together, they MUST all be in one single monolithic file. That makes them, sorry, useless for anything even remotely interesting. No, namespaces for functions can most certainly *not* be emulated with either variable functions or static methods. Dropping namespace support for functions makes namespaces mostly useless for anyone who is not 100% OOP. There's no reason to make functions second-class citizens (no pun intended). sure point taken on the monolithic files, when sticking different functions into classes just for the sake of them then becoming namespaceable. but how would allowing functions in namespaces solve this issue? regards, Lukas Kahwe Smith [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] true namespaces, yet another point of view
On 24.09.2008, at 01:17, Guilherme Blanco wrote: For those that do not understand very well the explanation of jvlad... He's suggesting to change the class struct to be an scope struct, and have a property that tells if it's a namespace or a class, and reuse the implementation of class which already works very well. The nested support is achieved afai understand through the Adjacency List algorithm... can you confirm this to me? or just leave the organization of things to classes (with long class names with a nice prefix to prevent collissions) and leave it to class_alias() (and equivalent features for functions .. also with the option of a compile time aliasing) to handle the aliasing. this removes the need for namespaces and use statements, while making it possible to make class/function names short (that are long for organizational and collision prevention reasons). regards, Lukas Kahwe Smith [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [Fwd: [PATCH] Backport of HEADs output API]
hi, On Thu, Sep 25, 2008 at 3:54 PM, Lukas Kahwe Smith <[EMAIL PROTECTED]> wrote: > > On 18.09.2008, at 21:02, Michael Wallner wrote: > >> In case the original with patches attached doesn't get through: >> >> http://dev.iworks.at/PATCHES/php53-backport_output.txt >> http://dev.iworks.at/PATCHES/pecl-backport_output.txt > > > well the question is does it fix some real world bugs? this late in the game > i would not want to include these changes if they "just" add features .. It does not only add features, it cleans up the mess as well. It will also greatly ease our work if HEAD and 5.3 has the same code base. I'm in favor of merging this code to 5.3 (for the record). 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
Re: [PHP-DEV] [Fwd: [PATCH] Backport of HEADs output API]
On 18.09.2008, at 21:02, Michael Wallner wrote: In case the original with patches attached doesn't get through: http://dev.iworks.at/PATCHES/php53-backport_output.txt http://dev.iworks.at/PATCHES/pecl-backport_output.txt well the question is does it fix some real world bugs? this late in the game i would not want to include these changes if they "just" add features .. regards, Lukas Kahwe Smith [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
