Re: [PHP-DEV] Re: Zend Optimizer+ Source Code now available
Pierre Joye in php.internals (Thu, 14 Feb 2013 11:21:33 +0100): On Thu, Feb 14, 2013 at 11:09 AM, Jan Ehrhardt php...@ehrhardt.nl wrote: Is my impression right that there is still a lot to be done to get this compiled under Windows? I did not succeed and then looked into config.m4. There are huge differenced with config.w32, There are a couple of mistakes in config.w32, Dmitry merged a PR this morning that should fix them. OK, I will take another shot. It failed with Don't know how to make Optimizer\zend_optimizer.c. In the meantime, I uploaded binaries for all supported PHP versions here: https://twitter.com/PierreJoye/status/301999105591373824 VC11 builds of PHP 5.5 (php itself :) snapshots are coming shortly too. I also tried to compile it as a normal extension (in PHP 5.4 and PHP 5.5). The standard Windows (VC9) build script tries to make php_ZendOptimizerPlus.dll in stead of ZendOptimizerPlus.dll. Are there any tweaks needed in configure.js or something like that to make it part of the normal build routine? Jan -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Zend Optimizer+ Source Code now available
hi, On Thu, Feb 14, 2013 at 11:36 AM, Jan Ehrhardt php...@ehrhardt.nl wrote: Pierre Joye in php.internals (Thu, 14 Feb 2013 11:21:33 +0100): On Thu, Feb 14, 2013 at 11:09 AM, Jan Ehrhardt php...@ehrhardt.nl wrote: Is my impression right that there is still a lot to be done to get this compiled under Windows? I did not succeed and then looked into config.m4. There are huge differenced with config.w32, There are a couple of mistakes in config.w32, Dmitry merged a PR this morning that should fix them. OK, I will take another shot. It failed with Don't know how to make Optimizer\zend_optimizer.c. Yes, this bug is fixed in master, I submitter the PR earlier today. In the meantime, I uploaded binaries for all supported PHP versions here: https://twitter.com/PierreJoye/status/301999105591373824 VC11 builds of PHP 5.5 (php itself :) snapshots are coming shortly too. I also tried to compile it as a normal extension (in PHP 5.4 and PHP 5.5). The standard Windows (VC9) build script tries to make php_ZendOptimizerPlus.dll in stead of ZendOptimizerPlus.dll. Are there any tweaks needed in configure.js or something like that to make it part of the normal build routine? Updating your tree should do it. -- Pierre @pierrejoye -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Zend Optimizer+ Source Code now available
Pierre Joye in php.internals (Thu, 14 Feb 2013 12:09:57 +0100): Yes, this bug is fixed in master, I submitter the PR earlier today. OK. It builds now. I also tried to compile it as a normal extension (in PHP 5.4 and PHP 5.5). The standard Windows (VC9) build script tries to make php_ZendOptimizerPlus.dll in stead of ZendOptimizerPlus.dll. Are there any tweaks needed in configure.js or something like that to make it part of the normal build routine? Updating your tree should do it. It still builds php_ZendOptimizerPlus.dll but that might be because I added --enable-optimizer-plus=shared to my configure options. I like to show in my configure line all the extensions I compile in one pass ;-) I will see what happens if I leave that out. Anyway, I suppose adding this to my php.ini will work as well: zend_extension=ext/php_ZendOptimizerPlus.dll Jan -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Zend Optimizer+ Source Code now available
hi Jan, On Thu, Feb 14, 2013 at 12:34 PM, Jan Ehrhardt php...@ehrhardt.nl wrote: I also tried to compile it as a normal extension (in PHP 5.4 and PHP 5.5). The standard Windows (VC9) build script tries to make php_ZendOptimizerPlus.dll in stead of ZendOptimizerPlus.dll. Are there any tweaks needed in configure.js or something like that to make it part of the normal build routine? Updating your tree should do it. It still builds php_ZendOptimizerPlus.dll but that might be because I added --enable-optimizer-plus=shared to my configure options. I like to show in my configure line all the extensions I compile in one pass ;-) I will see what happens if I leave that out. Anyway, I suppose adding this to my php.ini will work as well: zend_extension=ext/php_ZendOptimizerPlus.dll I misread the question, it is expected, like php_xdebug, php_apc, etc. Cheers, -- Pierre @pierrejoye -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Zend Optimizer+ Source Code now available
Pierre Joye in php.internals (Thu, 14 Feb 2013 12:44:30 +0100): I misread the question, it is expected, like php_xdebug, php_apc, etc. Loaded from the command line (PHP 5.5.0alpha4 TS): This program makes use of the Zend Scripting Language Engine: Zend Engine v2.5.0-dev, Copyright (c) 1998-2013 Zend Technologies with Zend Optimizer+ v7.0.0-dev, Copyright (c) 1999-2013, by Zend Technologies Time for real tests! Jan PS. X64 was a step too far. And php_apc.dll does not compile anymore under PHP 5.5 after I went back to apc 3.1.13. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Zend Optimizer+ Source Code now available
Pierre Joye in php.internals (Thu, 14 Feb 2013 11:21:33 +0100): VC11 builds of PHP 5.5 (php itself :) snapshots are coming shortly too. I will stick with VC9 for the moment ;-) http://dl.dropbox.com/u/8954372/php-5.5.0alpha4-Win32-VC9-x86.zip http://dl.dropbox.com/u/8954372/php-5.5.0alpha4-nts-Win32-VC9-x86.zip The PHP 5.4.11 and PHP 5.3.21 zips are in my dropbox as well. Jan -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Zend Optimizer+ Source Code now available
On Thu, Feb 14, 2013 at 2:40 PM, Jan Ehrhardt php...@ehrhardt.nl wrote: Pierre Joye in php.internals (Thu, 14 Feb 2013 11:21:33 +0100): VC11 builds of PHP 5.5 (php itself :) snapshots are coming shortly too. I will stick with VC9 for the moment ;-) http://dl.dropbox.com/u/8954372/php-5.5.0alpha4-Win32-VC9-x86.zip http://dl.dropbox.com/u/8954372/php-5.5.0alpha4-nts-Win32-VC9-x86.zip The PHP 5.4.11 and PHP 5.3.21 zips are in my dropbox as well. VC9 snaps are already available for all almost all commits at http://windows.php.net/downloads/snaps/ Releases are at: http://windows.php.net/qa/ (f.e. a4) -- Pierre @pierrejoye -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] File system watcher/monitoring
Hi internal, A missing feature in PHP is a file system watcher/monitoring available for almost all platforms. On Linux, we have inotify (available in PHP through pecl/inotify), on Mac OS X, we have /dev/fsevents (not available in PHP, since we need ioctl to do that in pure PHP —and sudo—, no C extension needed), on FreeBSD, we have FAM, and on Windows, we have FileSystemWatcher in .NET. All major platforms have a solution ready to use. By now, if we didn't use these solutions, we should use a finder (thanks to RecursiveIteratorIterator and DirectoryIterator in SPL) that runs every n seconds and compute a diff with the previous run. This solution works fine for a small set of files but it can slow for a big one. This is just a tricky solution, not a proper one. Possible domains where it is needed: test, CI, log, file transfering, security etc. Is it possible to have such a feature landing in PHP (core if karma allows it)? or do you want such a feature? Best regards :-). -- Ivan Enderlin Developer of Hoa http://hoa-project.net/ PhD. student at DISC/Femto-ST (Vesontio) and INRIA (Cassis) http://disc.univ-fcomte.fr/ and http://www.inria.fr/ Member of HTML and WebApps Working Group of W3C http://w3.org/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Zend Optimizer+ Source Code now available
Pierre Joye in php.internals (Thu, 14 Feb 2013 14:47:48 +0100): VC9 snaps are already available for all almost all commits at http://windows.php.net/downloads/snaps/ http://windows.php.net/downloads/snaps/php-5.4/r4b900f4/ do not include php_ZendOptimizerPlus.dll yet. http://windows.php.net/qa/ (f.e. a4) http://windows.php.net/downloads/snaps/php-5.5/r1bde2b4/ do not include php_ZendOptimizerPlus.dll yet. Or am I looking with my nose? Jan -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] File system watcher/monitoring
On Thu, Feb 14, 2013 at 3:03 PM, Ivan Enderlin @ Hoa ivan.ender...@hoa-project.net wrote: Hi internal, A missing feature in PHP is a file system watcher/monitoring available for almost all platforms. On Linux, we have inotify (available in PHP through pecl/inotify), on Mac OS X, we have /dev/fsevents (not available in PHP, since we need ioctl to do that in pure PHP —and sudo—, no C extension needed), on FreeBSD, we have FAM, and on Windows, we have FileSystemWatcher in .NET. All major platforms have a solution ready to use. By now, if we didn't use these solutions, we should use a finder (thanks to RecursiveIteratorIterator and DirectoryIterator in SPL) that runs every n seconds and compute a diff with the previous run. This solution works fine for a small set of files but it can slow for a big one. This is just a tricky solution, not a proper one. Possible domains where it is needed: test, CI, log, file transfering, security etc. Is it possible to have such a feature landing in PHP (core if karma allows it)? or do you want such a feature? Best regards :-). Hello :-) I don't see why we would have such a thing into PHP Core. We are already smooth about the file system accesses with a realpath cache, and users may use different pecl ext if they want to take hand on a lib such as inotify. Julien
Re: [PHP-DEV] File system watcher/monitoring
Hi Mike, On 14/02/13 15:18, Mike Ho wrote: Just a quick note, FileSystemWatcher in .NET is actually not recommended for use by Microsoft. It does not guarantee that an event will be raised on every new file or file mod in a given folder… and it's even less determinstic when trying to deal with network share drives. Microsoft's own developer blogs usually recommend that people roll their own polling-based solution instead of depending on FileSystemWatcher (googling FileSystemWatcher will yield many many results regarding this). I'm not necessarily saying that the overall idea is without merit… but it's just that if someone does want to try and implement something like this on Windows, they should try and avoid whatever Win32 API calls that FileSystemWatcher uses. Ok, thank you for the note. I didn't look deeply in Windows API, just Mac OS X and Linux for the moment… Thank you again. --Mike On Feb 14, 2013, at 6:03 AM, Ivan Enderlin @ Hoa ivan.ender...@hoa-project.net wrote: Hi internal, A missing feature in PHP is a file system watcher/monitoring available for almost all platforms. On Linux, we have inotify (available in PHP through pecl/inotify), on Mac OS X, we have /dev/fsevents (not available in PHP, since we need ioctl to do that in pure PHP —and sudo—, no C extension needed), on FreeBSD, we have FAM, and on Windows, we have FileSystemWatcher in .NET. All major platforms have a solution ready to use. By now, if we didn't use these solutions, we should use a finder (thanks to RecursiveIteratorIterator and DirectoryIterator in SPL) that runs every n seconds and compute a diff with the previous run. This solution works fine for a small set of files but it can slow for a big one. This is just a tricky solution, not a proper one. Possible domains where it is needed: test, CI, log, file transfering, security etc. Is it possible to have such a feature landing in PHP (core if karma allows it)? or do you want such a feature? Best regards :-). -- Ivan Enderlin Developer of Hoa http://hoa-project.net/ PhD. student at DISC/Femto-ST (Vesontio) and INRIA (Cassis) http://disc.univ-fcomte.fr/ and http://www.inria.fr/ Member of HTML and WebApps Working Group of W3C http://w3.org/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Ivan Enderlin Developer of Hoa http://hoa-project.net/ PhD. student at DISC/Femto-ST (Vesontio) and INRIA (Cassis) http://disc.univ-fcomte.fr/ and http://www.inria.fr/ Member of HTML and WebApps Working Group of W3C http://w3.org/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] File system watcher/monitoring
Hello Julien, On 14/02/13 15:29, Julien Pauli wrote: On Thu, Feb 14, 2013 at 3:03 PM, Ivan Enderlin @ Hoa ivan.ender...@hoa-project.net wrote: Hi internal, A missing feature in PHP is a file system watcher/monitoring available for almost all platforms. On Linux, we have inotify (available in PHP through pecl/inotify), on Mac OS X, we have /dev/fsevents (not available in PHP, since we need ioctl to do that in pure PHP —and sudo—, no C extension needed), on FreeBSD, we have FAM, and on Windows, we have FileSystemWatcher in .NET. All major platforms have a solution ready to use. By now, if we didn't use these solutions, we should use a finder (thanks to RecursiveIteratorIterator and DirectoryIterator in SPL) that runs every n seconds and compute a diff with the previous run. This solution works fine for a small set of files but it can slow for a big one. This is just a tricky solution, not a proper one. Possible domains where it is needed: test, CI, log, file transfering, security etc. Is it possible to have such a feature landing in PHP (core if karma allows it)? or do you want such a feature? Best regards :-). Hello :-) I don't see why we would have such a thing into PHP Core. We are already smooth about the file system accesses with a realpath cache, and users may use different pecl ext if they want to take hand on a lib such as inotify. Well ok, forget PHP core, but an extension would be great. -- Ivan Enderlin Developer of Hoa http://hoa-project.net/ PhD. student at DISC/Femto-ST (Vesontio) and INRIA (Cassis) http://disc.univ-fcomte.fr/ and http://www.inria.fr/ Member of HTML and WebApps Working Group of W3C http://w3.org/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] File system watcher/monitoring
2013/2/14 Ivan Enderlin @ Hoa ivan.ender...@hoa-project.net Hello Julien, On 14/02/13 15:29, Julien Pauli wrote: On Thu, Feb 14, 2013 at 3:03 PM, Ivan Enderlin @ Hoa ivan.ender...@hoa-project.net wrote: Hi internal, A missing feature in PHP is a file system watcher/monitoring available for almost all platforms. On Linux, we have inotify (available in PHP through pecl/inotify), on Mac OS X, we have /dev/fsevents (not available in PHP, since we need ioctl to do that in pure PHP —and sudo—, no C extension needed), on FreeBSD, we have FAM, and on Windows, we have FileSystemWatcher in .NET. All major platforms have a solution ready to use. By now, if we didn't use these solutions, we should use a finder (thanks to RecursiveIteratorIterator and DirectoryIterator in SPL) that runs every n seconds and compute a diff with the previous run. This solution works fine for a small set of files but it can slow for a big one. This is just a tricky solution, not a proper one. Possible domains where it is needed: test, CI, log, file transfering, security etc. Is it possible to have such a feature landing in PHP (core if karma allows it)? or do you want such a feature? Best regards :-). Hello :-) I don't see why we would have such a thing into PHP Core. We are already smooth about the file system accesses with a realpath cache, and users may use different pecl ext if they want to take hand on a lib such as inotify. Well ok, forget PHP core, but an extension would be great. At least for inotify there is an extension, which works quite fine. Never searched something similar for other OSs. Regards, Sebastian -- Ivan Enderlin Developer of Hoa http://hoa-project.net/ PhD. student at DISC/Femto-ST (Vesontio) and INRIA (Cassis) http://disc.univ-fcomte.fr/ and http://www.inria.fr/ Member of HTML and WebApps Working Group of W3C http://w3.org/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- github.com/KingCrunch
Re: [PHP-DEV] File system watcher/monitoring
Hi Sebastian, On 14/02/13 15:40, Sebastian Krebs wrote: 2013/2/14 Ivan Enderlin @ Hoa ivan.ender...@hoa-project.net Hello Julien, On 14/02/13 15:29, Julien Pauli wrote: On Thu, Feb 14, 2013 at 3:03 PM, Ivan Enderlin @ Hoa ivan.ender...@hoa-project.net wrote: Hi internal, A missing feature in PHP is a file system watcher/monitoring available for almost all platforms. On Linux, we have inotify (available in PHP through pecl/inotify), on Mac OS X, we have /dev/fsevents (not available in PHP, since we need ioctl to do that in pure PHP —and sudo—, no C extension needed), on FreeBSD, we have FAM, and on Windows, we have FileSystemWatcher in .NET. All major platforms have a solution ready to use. By now, if we didn't use these solutions, we should use a finder (thanks to RecursiveIteratorIterator and DirectoryIterator in SPL) that runs every n seconds and compute a diff with the previous run. This solution works fine for a small set of files but it can slow for a big one. This is just a tricky solution, not a proper one. Possible domains where it is needed: test, CI, log, file transfering, security etc. Is it possible to have such a feature landing in PHP (core if karma allows it)? or do you want such a feature? Best regards :-). Hello :-) I don't see why we would have such a thing into PHP Core. We are already smooth about the file system accesses with a realpath cache, and users may use different pecl ext if they want to take hand on a lib such as inotify. Well ok, forget PHP core, but an extension would be great. At least for inotify there is an extension, which works quite fine. Never searched something similar for other OSs. I have written: “On Linux, we have inotify (available in PHP through pecl/inotify)”, so yup, I know for inotify :-). I propose to gather all these API and give a proper one to the end-user. -- Ivan Enderlin Developer of Hoa http://hoa-project.net/ PhD. student at DISC/Femto-ST (Vesontio) and INRIA (Cassis) http://disc.univ-fcomte.fr/ and http://www.inria.fr/ Member of HTML and WebApps Working Group of W3C http://w3.org/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Zend Optimizer+ Source Code now available
hi Jan, On Thu, Feb 14, 2013 at 3:21 PM, Jan Ehrhardt php...@ehrhardt.nl wrote: Pierre Joye in php.internals (Thu, 14 Feb 2013 14:47:48 +0100): VC9 snaps are already available for all almost all commits at http://windows.php.net/downloads/snaps/ http://windows.php.net/downloads/snaps/php-5.4/r4b900f4/ do not include php_ZendOptimizerPlus.dll yet. http://windows.php.net/qa/ (f.e. a4) http://windows.php.net/downloads/snaps/php-5.5/r1bde2b4/ do not include php_ZendOptimizerPlus.dll yet. Or am I looking with my nose? Yes ;-) PHP does not bundle Optimizer, at least not yet. Snaps for pecl (or other external exts) are at: http://windows.php.net/downloads/pecl/snaps/ And today snaps for Optimizer is at: http://windows.php.net/downloads/pecl/snaps/Optimizer/7.0.0-dev/ Cheers, -- Pierre @pierrejoye -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Zend Optimizer+ Source Code now available
Great to see. The README covers much of the content (and in more detail) that I previously wanted to see in the RFC. Excellent! There are some things still missing from the RFC, though: - do you see Optimizer+ being enabled (if not in PECL) or disabled by default, etc. I *think* we should strive to have it enabled by default, but it should definitely be possible to turn it off too. I guess that can be another voting possibility - bundle turn on by default (vs. just bundle). - your email comment to John Carter about Zend Guard decoder We don't want to create any special cases in O+; We would either take care of integrating it by having slightly patching our O+ build, or we'd add generalized facilities to O+ that will allow the loader to interact with it directly (that would not be unique to the Zend loader but could be used by any extension). From my point of view, it's nice-to-have to solve it before 5.5.0, not a must-have. - There are still open questions in the RFC; these need to be closed before voting. I think the only open question is integration with other modules, most notably debuggers. This is something we'd like to tackle sooner rather than later, and I think it'll be easier to just go ahead and do that now that the source code is available. Any other open questions that need answering? Comments: - The README gives recommended parameters. Taking that advice at face value, I think these should be default settings. The default settings are designed to minimize the chance that an app or a workflow - which worked fine w/o O+ - will suddenly fail after O+ is installed. The 'recommended' settings are for max-performance. You can view it like 'Safe' vs. 'Extreme' settings. Personally I think the default settings should be closer to the Safe ones... - Should the name reflect the code's main purpose (op-code caching), and allowing a future use of optimizer for a more sophisticated optimizer implementation? Or do you see Optimizer+ being the framework for such optimizations? O+ does perform some optimizations in addition to caching code, in a pretty sophisticated manner actually (block optimizations). Optimizations - which can be expensive to carry out - are definitely a good fit with an opcode cache, that ensures that you wouldn't have to do these optimizations more than once. I'm obviously subjective but I think the name Optimizer+ does a good job at suggesting that it's both an Optimizer but also something else. Perhaps we should call it OptiCache? :) Questions (I haven't dug through the code): - What do CLI processes share? IIRC nothing, presently it's not very useful for CLI except for testing (it'll only apply to a single run). I could be wrong though, Dmitry? - Is there an architectural reason why the 'embed' embedded SAPI couldn't be supported? (Lack of parent forking??) As long as we can map the shared memory piece to the same base address, there's no inherent reason why we couldn't make it work with SAPI/embed. That's how we work on Windows where there's no concept of fork(); We could apply a similar concept on Linux - although note that it's not 100% reliable, a base address that's free in one process may not be available in another... Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Zend Optimizer+ Source Code now available
On Thu, Feb 14, 2013 at 7:21 PM, Zeev Suraski z...@zend.com wrote: O+ does perform some optimizations in addition to caching code, in a pretty sophisticated manner actually (block optimizations). Optimizations - which can be expensive to carry out - are definitely a good fit with an opcode cache, that ensures that you wouldn't have to do these optimizations more than once. I'm obviously subjective but I think the name Optimizer+ does a good job at suggesting that it's both an Optimizer but also something else. Perhaps we should call it OptiCache? :) Questions (I haven't dug through the code): - What do CLI processes share? IIRC nothing, presently it's not very useful for CLI except for testing (it'll only apply to a single run). I could be wrong though, Dmitry? Well, if it does block-level optimizations, that is already enough to make it useful for CLI-scripts, as even though caching is not relevant for long-running processes, optimizations should make things faster. Are optimizations documented? -- Alexey Zakhlestin, http://github.com/indeyets -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] File system watcher/monitoring
On 2/14/2013 7:18 AM, Mike Ho wrote: Just a quick note, FileSystemWatcher in .NET is actually not recommended for use by Microsoft. It does not guarantee that an event will be raised on every new file or file mod in a given folder… and it's even less determinstic when trying to deal with network share drives. Microsoft's own developer blogs usually recommend that people roll their own polling-based solution instead of depending on FileSystemWatcher (googling FileSystemWatcher will yield many many results regarding this). I'm not necessarily saying that the overall idea is without merit… but it's just that if someone does want to try and implement something like this on Windows, they should try and avoid whatever Win32 API calls that FileSystemWatcher uses. --Mike For Windows, I've got notes that there is a Windows API for accessing the NTFS journal (DeviceIoControl() with FSCTL_QUERY_USN_JOURNAL). IMO as the author of a change monitoring tool, that API would be the most reliable user-mode access point for watching for the majority of file system changes: http://msdn.microsoft.com/en-us/library/aa365736%28VS.85%29.aspx It requires system or Administrator privileges to read NTFS journal records. Of course, if you are going to go as far as needing admin rights, it might simply be better to write a Windows driver and hook the file system calls as some SysInternals tools do and get reliable results. With the user-mode Windows API, you still run the risk of missing entries with NTFS if there are a bunch of updates back to back. It still qualifies as polling, but it is faster polling than scanning a large number of files and directories. It also only works with NTFS, so other mounted file systems won't work. -- Thomas Hruska CubicleSoft President I've got great, time saving software that you might find useful. http://cubiclesoft.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Zend Optimizer+ Source Code now available
Zeev Suraski in php.internals (Thu, 14 Feb 2013 17:21:48 +0200): I think the only open question is integration with other modules, most notably debuggers. php_ZendOptimizerPlus.dll and php_xdebug.dll loaded both together in PHP 5.3 and PHP 5.4 (x86, TS and NTS). I do not know yet if there are any issues. As far as I know there is no php_xdebug.dll yet for PHP 5.5. Jan -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Zend Optimizer+ Source Code now available
Pierre Joye in php.internals (Thu, 14 Feb 2013 15:58:21 +0100): Or am I looking with my nose? Yes ;-) Snow for my eyes, frost on my nose. My zips do contain php_ZendOptimizerPlus.dll and a lot of other extensions. Jan -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Zend Optimizer+ Source Code now available
On Thu, Feb 14, 2013 at 4:21 PM, Zeev Suraski z...@zend.com wrote: - Should the name reflect the code's main purpose (op-code caching), and allowing a future use of optimizer for a more sophisticated optimizer implementation? Or do you see Optimizer+ being the framework for such optimizations? O+ does perform some optimizations in addition to caching code, in a pretty sophisticated manner actually (block optimizations). Optimizations - which can be expensive to carry out - are definitely a good fit with an opcode cache, that ensures that you wouldn't have to do these optimizations more than once. I'm obviously subjective but I think the name Optimizer+ does a good job at suggesting that it's both an Optimizer but also something else. Perhaps we should call it OptiCache? :) If this will go into PECL first then I see no reason to change the name from Optimizer+. If this will go into PHP then it shouldn't need a name at all, should it? It could just be opcode cache (--enable-opcode-cache / --disable-opcode-cache). That seems more descriptive to me then some fancy name like Optimizer+. Regarding the optimizations it contains, imho those are a separate concern and if Optimizer+ goes into core both aspects should be cleanly separated (and you should be able to enable/disable them separately). The optimizations are not directly related to caching. Caching makes them more viable for web requests, but as someone already pointed out the optimizations are also useful on CLI, where compile times just aren't a concern anyway (but run times can be). Btw, I was quite surprised to see the block optimizations in O+ :) Really cool! Nikita
Re: [PHP-DEV] Zend Optimizer+ Source Code now available
On Thu, Feb 14, 2013 at 9:02 AM, Nikita Popov nikita@gmail.com wrote: On Thu, Feb 14, 2013 at 4:21 PM, Zeev Suraski z...@zend.com wrote: - Should the name reflect the code's main purpose (op-code caching), and allowing a future use of optimizer for a more sophisticated optimizer implementation? Or do you see Optimizer+ being the framework for such optimizations? O+ does perform some optimizations in addition to caching code, in a pretty sophisticated manner actually (block optimizations). Optimizations - which can be expensive to carry out - are definitely a good fit with an opcode cache, that ensures that you wouldn't have to do these optimizations more than once. I'm obviously subjective but I think the name Optimizer+ does a good job at suggesting that it's both an Optimizer but also something else. Perhaps we should call it OptiCache? :) If this will go into PECL first then I see no reason to change the name from Optimizer+. If this will go into PHP then it shouldn't need a name at all, should it? It could just be opcode cache (--enable-opcode-cache / --disable-opcode-cache). That seems more descriptive to me then some fancy name like Optimizer+. Regarding the optimizations it contains, imho those are a separate concern and if Optimizer+ goes into core both aspects should be cleanly separated (and you should be able to enable/disable them separately). The optimizations are not directly related to caching. Caching makes them more viable for web requests, but as someone already pointed out the optimizations are also useful on CLI, where compile times just aren't a concern anyway (but run times can be). I usually don't chime in with 'me too' comments, but I think Nikita summed it up nicely. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Zend Optimizer+ Source Code now available
On 02/14/2013 10:55 AM, Jan Ehrhardt wrote: Zeev Suraski in php.internals (Thu, 14 Feb 2013 17:21:48 +0200): I think the only open question is integration with other modules, most notably debuggers. php_ZendOptimizerPlus.dll and php_xdebug.dll loaded both together in PHP 5.3 and PHP 5.4 (x86, TS and NTS). I do not know yet if there are any issues. Make sure you load ZO before xdebug and it seems to work ok. If you load xdebug first you will run into interesting problems. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Zend Optimizer+ Source Code now available
Rasmus Lerdorf in php.internals (Thu, 14 Feb 2013 11:14:20 -0500): On 02/14/2013 10:55 AM, Jan Ehrhardt wrote: Zeev Suraski in php.internals (Thu, 14 Feb 2013 17:21:48 +0200): I think the only open question is integration with other modules, most notably debuggers. php_ZendOptimizerPlus.dll and php_xdebug.dll loaded both together in PHP 5.3 and PHP 5.4 (x86, TS and NTS). I do not know yet if there are any issues. Make sure you load ZO before xdebug and it seems to work ok. If you load xdebug first you will run into interesting problems. Hmm. I was loading them the other way around, but did not encounter any interesting problems yet... Jan -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Zend Optimizer+ Source Code now available
On 02/14/2013 11:21 AM, Jan Ehrhardt wrote: Rasmus Lerdorf in php.internals (Thu, 14 Feb 2013 11:14:20 -0500): On 02/14/2013 10:55 AM, Jan Ehrhardt wrote: Zeev Suraski in php.internals (Thu, 14 Feb 2013 17:21:48 +0200): I think the only open question is integration with other modules, most notably debuggers. php_ZendOptimizerPlus.dll and php_xdebug.dll loaded both together in PHP 5.3 and PHP 5.4 (x86, TS and NTS). I do not know yet if there are any issues. Make sure you load ZO before xdebug and it seems to work ok. If you load xdebug first you will run into interesting problems. Hmm. I was loading them the other way around, but did not encounter any interesting problems yet... Most things work fine, but I hit a weird segfault in some complicated code which I fixed by flipping the order. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Zend Optimizer+ Source Code now available
Rasmus Lerdorf in php.internals (Thu, 14 Feb 2013 11:32:55 -0500): Make sure you load ZO before xdebug and it seems to work ok. If you load xdebug first you will run into interesting problems. Most things work fine, but I hit a weird segfault in some complicated code which I fixed by flipping the order. Was that on Windows or on Linux? Jan -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] File system watcher/monitoring
2013/2/14 Ivan Enderlin @ Hoa ivan.ender...@hoa-project.net: I have written: “On Linux, we have inotify (available in PHP through pecl/inotify)”, so yup, I know for inotify :-). I propose to gather all these API and give a proper one to the end-user. If you are doing so, I would suggest you to create this as a C library, that way you could bring that feature to any applications/languages and you would only have to create a bridge as a PECL extension. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] File system watcher/monitoring
On Thu, Feb 14, 2013 at 5:00 PM, Patrick ALLAERT patrickalla...@php.netwrote: 2013/2/14 Ivan Enderlin @ Hoa ivan.ender...@hoa-project.net: I have written: “On Linux, we have inotify (available in PHP through pecl/inotify)”, so yup, I know for inotify :-). I propose to gather all these API and give a proper one to the end-user. If you are doing so, I would suggest you to create this as a C library, that way you could bring that feature to any applications/languages and you would only have to create a bridge as a PECL extension. and to carry on from Patrick's point, it would probably be cleaner to do it this way so your library wouldn't need to work around PHP stuff. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Zend Optimizer+ Source Code now available
On Thu, Feb 14, 2013 at 5:32 PM, Rasmus Lerdorf ras...@lerdorf.com wrote: On 02/14/2013 11:21 AM, Jan Ehrhardt wrote: Rasmus Lerdorf in php.internals (Thu, 14 Feb 2013 11:14:20 -0500): On 02/14/2013 10:55 AM, Jan Ehrhardt wrote: Zeev Suraski in php.internals (Thu, 14 Feb 2013 17:21:48 +0200): I think the only open question is integration with other modules, most notably debuggers. php_ZendOptimizerPlus.dll and php_xdebug.dll loaded both together in PHP 5.3 and PHP 5.4 (x86, TS and NTS). I do not know yet if there are any issues. Make sure you load ZO before xdebug and it seems to work ok. If you load xdebug first you will run into interesting problems. Hmm. I was loading them the other way around, but did not encounter any interesting problems yet... Most things work fine, but I hit a weird segfault in some complicated code which I fixed by flipping the order. Shouldn't we document that, or add some notice at extension loading by detecting Xdebug ? Julien.Pauli
Re: [PHP-DEV] Zend Optimizer+ Source Code now available
On 02/14/2013 08:02 AM, Nikita Popov wrote: On Thu, Feb 14, 2013 at 4:21 PM, Zeev Suraski z...@zend.com mailto:z...@zend.com wrote: - Should the name reflect the code's main purpose (op-code caching), and allowing a future use of optimizer for a more sophisticated optimizer implementation? Or do you see Optimizer+ being the framework for such optimizations? O+ does perform some optimizations in addition to caching code, in a pretty sophisticated manner actually (block optimizations). Optimizations - which can be expensive to carry out - are definitely a good fit with an opcode cache, that ensures that you wouldn't have to do these optimizations more than once. I'm obviously subjective but I think the name Optimizer+ does a good job at suggesting that it's both an Optimizer but also something else. Perhaps we should call it OptiCache? :) If this will go into PECL first then I see no reason to change the name from Optimizer+. If this will go into PHP then it shouldn't need a name at all, should it? It could just be opcode cache (--enable-opcode-cache / --disable-opcode-cache). That seems more descriptive to me then some fancy name like Optimizer+. Regarding the optimizations it contains, imho those are a separate concern and if Optimizer+ goes into core both aspects should be cleanly separated (and you should be able to enable/disable them separately). The optimizations are not directly related to caching. Caching makes them more viable for web requests, but as someone already pointed out the optimizations are also useful on CLI, where compile times just aren't a concern anyway (but run times can be). This raises questions for Zeev to address. Btw, I was quite surprised to see the block optimizations in O+ :) Really cool! Nikita The php.ini parameters will likely need a name (or two - if the optimizer is distinct from the op-code cache) as a prefix. Chris -- christopher.jo...@oracle.com http://twitter.com/ghrd Newly updated, free PHP Oracle book: http://www.oracle.com/technetwork/topics/php/underground-php-oracle-manual-098250.html -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Zend Optimizer+ Source Code now available
Hi! Well, if it does block-level optimizations, that is already enough to make it useful for CLI-scripts, as even though caching is not relevant for long-running processes, optimizations should make things faster. For most scripts, optimizations are not really worth it unless you run the same code over and over, so for CLI it would be noticeable only if you run long-running CPU-intensive server. Are optimizations documented? Not yet AFAIK. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Zend Optimizer+ Source Code now available
On Thursday 14 February 2013 10:24:22 Stas Malyshev wrote: For most scripts, optimizations are not really worth it unless you run the same code over and over, so for CLI it would be noticeable only if you run long-running CPU-intensive server. Apart from the long-running servers, there is also cronjobs. I have quite a number of them running on some of my servers, some of them once per minute, and they all share a certain number of classes between them. I imagine their startup and execution could profit a bit from an opcode cache. What keeps an opcode cache from using a persistent memory mapped file, maybe one per UID for security reasons, to cache opcodes from separate CLI invocations? best regards Patrick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Zend Optimizer+ Source Code now available
On 02/14/2013 07:21 AM, Zeev Suraski wrote: Great to see. The README covers much of the content (and in more detail) that I previously wanted to see in the RFC. Excellent! There are some things still missing from the RFC, though: - do you see Optimizer+ being enabled (if not in PECL) or disabled by default, etc. I *think* we should strive to have it enabled by default, but it should definitely be possible to turn it off too. I guess that can be another voting possibility - bundle turn on by default (vs. just bundle). To avoid too many voting choices, I think this can be decided outside the RFC process. - your email comment to John Carter about Zend Guard decoder We don't want to create any special cases in O+; We would either take care of integrating it by having slightly patching our O+ build, or we'd add generalized facilities to O+ that will allow the loader to interact with it directly (that would not be unique to the Zend loader but could be used by any extension). From my point of view, it's nice-to-have to solve it before 5.5.0, not a must-have. This should still be stated in the RFC. (The PHP community suffers from poor RFCs. Since you are a leader in the PHP community, your RFC should set a good example.) - There are still open questions in the RFC; these need to be closed before voting. I think the only open question is integration with other modules, most notably debuggers. This is something we'd like to tackle sooner rather than later, and I think it'll be easier to just go ahead and do that now that the source code is available. Any other open questions that need answering? I think this should be reworded before the vote occurs. I'm fine with leaving it under a heading for future investigation, i.e. stating it won't happen in an initial release. Comments: - The README gives recommended parameters. Taking that advice at face value, I think these should be default settings. The default settings are designed to minimize the chance that an app or a workflow - which worked fine w/o O+ - will suddenly fail after O+ is installed. The 'recommended' settings are for max-performance. You can view it like 'Safe' vs. 'Extreme' settings. Personally I think the default settings should be closer to the Safe ones... We can probably meet in the middle: leave the hard coded defaults as they currently are, and use those values in the php.ini-development examples. Php.ini-production can have the values recommended in the README. (Giving the proposed php.ini settings is another thing the RFC should have...) - Should the name reflect the code's main purpose (op-code caching), and allowing a future use of optimizer for a more sophisticated optimizer implementation? Or do you see Optimizer+ being the framework for such optimizations? O+ does perform some optimizations in addition to caching code, in a pretty sophisticated manner actually (block optimizations). Optimizations - which can be expensive to carry out - are definitely a good fit with an opcode cache, that ensures that you wouldn't have to do these optimizations more than once. I'm obviously subjective but I think the name Optimizer+ does a good job at suggesting that it's both an Optimizer but also something else. Perhaps we should call it OptiCache? :) It seems a good time to disambiguate its relationship to any current or future Zend product. Chris -- christopher.jo...@oracle.com http://twitter.com/ghrd Newly updated, free PHP Oracle book: http://www.oracle.com/technetwork/topics/php/underground-php-oracle-manual-098250.html -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] File system watcher/monitoring
Hi! A missing feature in PHP is a file system watcher/monitoring available for almost all platforms. On Linux, we have inotify (available in PHP through pecl/inotify), on Mac OS X, we have /dev/fsevents (not available in PHP, since we need ioctl to do that in pure PHP —and sudo—, no C extension needed), on FreeBSD, we have FAM, and on Windows, we have FileSystemWatcher in .NET. All major platforms have a solution ready to use. I think it'd be great to have a library with unified interface and an extension that uses it. However, I'm not sure if these libraries are useful in common php use case - short-lived requests. Could I get the changes since the last request? Or is it useful only for long-running persistent processes? Is it possible to have such a feature landing in PHP (core if karma allows it)? or do you want such a feature? I'm not sure why it has to be in core though. I don't see so far anything that requires modifying language core. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] File system watcher/monitoring
I think it'd be great to have a library with unified interface and an extension that uses it. However, I'm not sure if these libraries are useful in common php use case - short-lived requests. Could I get the changes since the last request? Or is it useful only for long-running persistent processes? You're right of course that you are implicitly lengthening a request. But if you are already embracing a long-polling model that waits for filesystem changes, the back-end service can actually use fs events instead of looping -- much more efficient. In fact I do this already on Windows by running an external FileSystemWatcher EXE and waiting for it to return (+ a timeout in the wrapper). -- S. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Zend Optimizer+ Source Code now available
On 14/02/13 18:24, Stas Malyshev wrote: Are optimizations documented? Not yet AFAIK. No, but they are pretty self-explanatory. O+ is a _Zend_ extension rather than a _PHP_ extension and this enables it to exploit extra hooks (see the tail of ZendAccelerator.c) and specifically follow through accel_op_array_handler() and the routines in the Optimizer subdirectory. Essentially this hook is invoked as an epilogue to the generating of any op_array. What this does is a number of peephole optimizisations to simplify and NOP out instruction sequences, and the last pass compresses the code removing dead NOPs to shrink the op_array -- this is typical of the sorts of things that the optimization passes of a compiler would do. And this is a segue into one architectural issue the immediately struck me on scanning the code: surely there is a natural domain separation between compilation, image startup/rundown, and execution. (i) is optimally done once per S/W version, (ii) per request, (iii) per instruction executed. Surely O+ is currently a hybrid of (i) and (ii) and whilst this might have occurred for understandable historical reasons, I question this rationale going forward. (A) The op-code optimization should be integrated into the core compiler and enabled through a GC(compiler_option) to be available to *any* opcode cache -- or to the application designer (by exposing these options through an INI directive. (B) The O+ opcode cache itself is logically quite separate. It makes great sense to keep ithis as a Zend extension (given the desire from some of the dev team to maintain a clear logical separation between the upper PHP environment and the Zend, Hippop, ... execution environments that support it). A Zend opcode cache belongs firmly in the Zend world and shouldn't be a PHP extension. I also note some interesting difference in approaches between O+ and APC, say for example: 1) in the handling of the ZEND_INCLUDE_OR_EVAL instruction where APC patches the op handler and O+ does peephole opcode examination. Both these workarounds could be avoided by tidying up the scope of work in the instruction code. 2) in the treatment of early binding class inheritence: APC include some reasonably complex logic to back this out; O+ sets a compiler option to disable this inheritance occurring in the first place, an approach that APC might want to copy.
Re: [PHP-DEV] Zend Optimizer+ Source Code now available
Hi! (A) The op-code optimization should be integrated into the core compiler and enabled through a GC(compiler_option) to be available to *any* opcode cache -- or to the application designer (by exposing these options through an INI directive. Most optimizations would not give perceivable benefit unless the optimized code is run many times. So enabling it without opcode cache would not produce very big benefit. But yes, in theory these code parts can live separately and they don't actually need each other. that support it). A Zend opcode cache belongs firmly in the Zend world and shouldn't be a PHP extension. I must say I don't understand this conclusion. I also note some interesting difference in approaches between O+ and APC, say for example: 1) in the handling of the ZEND_INCLUDE_OR_EVAL instruction where APC patches the op handler and O+ does peephole opcode examination. Both these workarounds could be avoided by tidying up the scope of work in the instruction code. Could you explain this a bit more? -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] O+ 1st results
hi! Here are a first result set using 5.5 and O+. http://windows.php.net/downloads/snaps/ostc/pftt/perf/results-20130213-5.4.11-5.5.0devvc11.html We did not update the templates for the report, please read the table as: - No Cache: . 5.5 VC11 PGO vs 5.4 VC9 PGO - Wincache . 5.4 PGO + Wincache vs 5.5 PGO + O+ TS mode is totally broken using O+, so ignore this column. Mediawiki is slower because it does not support yet O+ for usercache, along other things. Please keep in mind that these tests are only the performance related tests. Unit tests using all apps and phpts are still running. Further tests are running for: - 5.4 PGO + APC vs 5.4 PGO + Wincache vs 5.4 PGO + o+ - 5.3 PGO + APC vs 5.3 PGO + Wincache vs 5.3 PGO + o+ - 5.5 PGO + APC vs 5.5 PGO + Wincache vs 5.5 PGO + o+ I will post the results as soon as they are available. I would also suggest to publish releases as soon as possible on pecl.php.net to increase the user base. Thanks to Steve Zarkos and Matt Ficken for their work :) Cheers, -- Pierre @pierrejoye -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Zend Optimizer+ Source Code now available
On Thu, Feb 14, 2013 at 4:56 PM, Jan Ehrhardt php...@ehrhardt.nl wrote: Pierre Joye in php.internals (Thu, 14 Feb 2013 15:58:21 +0100): Or am I looking with my nose? Yes ;-) Snow for my eyes, frost on my nose. My zips do contain php_ZendOptimizerPlus.dll and a lot of other extensions. That's all nice but we do not do it anymore. Users then tend to think that these extra extensions are part of the core and/or fully supported, that's not the case. Cheers, -- Pierre @pierrejoye -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] File system watcher/monitoring
hi, On Thu, Feb 14, 2013 at 10:47 PM, Sanford Whiteman swhitemanlistens-softw...@cypressintegrated.com wrote: I think it'd be great to have a library with unified interface and an extension that uses it. However, I'm not sure if these libraries are useful in common php use case - short-lived requests. Could I get the changes since the last request? Or is it useful only for long-running persistent processes? You're right of course that you are implicitly lengthening a request. But if you are already embracing a long-polling model that waits for filesystem changes, the back-end service can actually use fs events instead of looping -- much more efficient. In fact I do this already on Windows by running an external FileSystemWatcher EXE and waiting for it to return (+ a timeout in the wrapper). There are native APIs for that (read: non .net, aka C) on Windows, using an external process for this purpose would be horrible, in all possible ways. Cheers, -- Pierre @pierrejoye -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] File system watcher/monitoring
There are native APIs for that (read: non .net, aka C) on Windows Well aware of that. The EXE does use the Win32 API, not a .NET wrapper. I've used that API ever since it's been documented. using an external process for this purpose would be horrible, in all possible ways. Well, yeah, that's my very point... having the engine/extension do this is the proper direction (I only use this hack to check completion of some scheduled tasks, it's all private). Stas says typical PHP apps don't have a need for file system hooks. Sure, long-polling may not be good with thread-per-process webservers, but those aren't the only PHP environments in the wild. Once you accept that people already roll out long-polling back ends with PHP, the next step is to minimize the check-sleep-loop hackery and offer true event-driven alternatives when possible. Nothing I'm saying is controversial. -- Sandy -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] File system watcher/monitoring
P.S. This was the very extension I was referring to when I posted to Internals sometime last year about developing extensions, latest books, etc.. It'd been a longtime fantasy of mine because I use PHP for a lot of sysadmin-type tasks on Windows servers -- DB import/export, nightly HTTP and FTP transfers from data feed providers, things like that -- and having this API supported right in PHP would be great (instead of relying on Windows apps that do use the API but have their own arcane embedded scripting languages, if they have any at all). But my C and Win32 are not what they were when I was writing DLLs as part of my day job, so there's almost zero chance I could do the job. -- S. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
