On Mon, 7 May 2007, Lukas Kahwe Smith wrote:
Stanislav Malyshev wrote:
can write this data to disk. So, you needs 20MB. If serialize (and of
course unserialize) would be able to write directly to disk (or read
directly from disk), you only needs 10MB.
Actually having
I'm a PHP Programmer from China, I'd like to help translate phpdoc_zh.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On Mon, 7 May 2007, Stanislav Malyshev wrote:
We will need it:
- by the time of PHP 6
I think this problem should be fixed not by killing PEAR and converting it to
PHP extensions but by fixing PHP 6 and enabling PEAR to work.
Let me agree with Greg here. We can not go back to the PHP 4.x
On Mon, 7 May 2007, Stanislav Malyshev wrote:
PHP_Archive-based phar archives will no longer work once
allow_url_include is off and user streams wrappers are marked as remote.
So, it won't work with 100% of new installations in future PHP versions.
I guess we are solving the wrong
On 5/8/07, Derick Rethans [EMAIL PROTECTED] wrote:
On Mon, 7 May 2007, Stanislav Malyshev wrote:
We will need it:
- by the time of PHP 6
I think this problem should be fixed not by killing PEAR and converting it to
PHP extensions but by fixing PHP 6 and enabling PEAR to work.
Let me
On 05/08/2007 05:36 AM, Oliver Block wrote:
Hello,
I am getting a SIGSEGV when compiling php-5.2.2.
gdb breaks up at the if statement of the following function
static void php_apache_add_version(apr_pool_t *p)
{
TSRMLS_FETCH();
if (PG(expose_php)) {
Hello internals,
Tuesday, May 8, 2007, 10:13:15 AM, Pierre wrote:
On 5/8/07, Derick Rethans [EMAIL PROTECTED] wrote:
On Mon, 7 May 2007, Stanislav Malyshev wrote:
We will need it:
- by the time of PHP 6
I think this problem should be fixed not by killing PEAR and converting it
to
On 5/8/07, Marcus Boerger [EMAIL PROTECTED] wrote:
Now adding Pecl/Zip was a clever idea as it allows an easy way to
compress stuff on the fly for sites that offer downloads. However
this is a) far far away from a mainstream problem
And to read zip files (upload, ftp, remote data). I think
On 05/08/2007 12:36 PM, Marcus Boerger wrote:
The point is to make local URL wrappers working, not only phar://.
Stanislav and Tony have a point, writing a custom extension to fix a
problem that we introduced is a bad idea and does not solve the
problem for anyone else but phar. If phar will be
On 05/08/2007 12:36 PM, Marcus Boerger wrote:
Now adding Pecl/Zip was a clever idea as it allows an easy way to
compress stuff on the fly for sites that offer downloads. However
this is a) far far away from a mainstream problem and b) we should
not eventhink of turning it into a JAR and hack
Hello Pierre,
Tuesday, May 8, 2007, 10:58:19 AM, you wrote:
On 5/8/07, Marcus Boerger [EMAIL PROTECTED] wrote:
Now adding Pecl/Zip was a clever idea as it allows an easy way to
compress stuff on the fly for sites that offer downloads. However
this is a) far far away from a mainstream
Hello Antony,
Tuesday, May 8, 2007, 10:59:28 AM, you wrote:
On 05/08/2007 12:36 PM, Marcus Boerger wrote:
The point is to make local URL wrappers working, not only phar://.
Stanislav and Tony have a point, writing a custom extension to fix a
problem that we introduced is a bad idea and does
Hi Ilia, all,
I've attached patches for what I think is a better fix here, and it
simplifies the code. Looking at the CVS log, the is_numeric_string() usage
was added in version 1.120 to fix the first numeric key bug. The simple,
better thing would've been to just change zend_hash... to
On 05/08/2007 01:17 PM, Marcus Boerger wrote:
But the main argument for including it that it's going to solve the newly
created problem.
I.e. PEAR and all the other phar packages work perfectly fine without it.
It is not my main argument - not at all. My argument is that it is something
that
Hello Tony,
according to my backtrace, this line (main/main.c:1491) is not processed.
366 if (PG(expose_php)) {
(gdb) p core_globals_id
$4 = 0
The backtrace follows:
Program received signal SIGSEGV, Segmentation fault.
0x40bb4449 in php_apache_add_version (p=0x80a40a8)
at
On 05/08/2007 01:51 PM, Oliver Block wrote:
Hello Tony,
according to my backtrace, this line (main/main.c:1491) is not processed.
How to reproduce it?
366 if (PG(expose_php)) {
(gdb) p core_globals_id
$4 = 0
The backtrace follows:
Program received signal SIGSEGV, Segmentation
On 06/05/07, Tijnema ! [EMAIL PROTECTED] wrote:
On 5/6/07, David Coallier [EMAIL PROTECTED] wrote:
On 5/5/07, Jan Reininghaus [EMAIL PROTECTED] wrote:
I am currently working on my second draw for the page, but I have a
question. For my first draw I assumed that all of the new features will
Am Dienstag, 8. Mai 2007 11:55 schrieben Sie:
On 05/08/2007 01:51 PM, Oliver Block wrote:
Hello Tony,
according to my backtrace, this line (main/main.c:1491) is not processed.
How to reproduce it?
I just compiled the latest php 5 release with zts. I am working on a V-Server
with Plesk
On 05/08/2007 03:27 PM, Oliver Block wrote:
Am Dienstag, 8. Mai 2007 11:55 schrieben Sie:
On 05/08/2007 01:51 PM, Oliver Block wrote:
Hello Tony,
according to my backtrace, this line (main/main.c:1491) is not processed.
How to reproduce it?
I just compiled the latest php 5 release with
Am Dienstag, 8. Mai 2007 13:45 schrieben Sie:
What was your configure line?
./configure --with-apxs2=/usr/sbin/apxs2 --prefix=/usr/local/php5
--enable-debug --enable-maintainer-zts --with-mysql --with-imap
--with-imap-ssl
There was a php4 rpm which was installed by the SuSE setup tool (YaST).
On 05/08/2007 04:02 PM, Oliver Block wrote:
Am Dienstag, 8. Mai 2007 13:45 schrieben Sie:
What was your configure line?
./configure --with-apxs2=/usr/sbin/apxs2 --prefix=/usr/local/php5
--enable-debug --enable-maintainer-zts --with-mysql --with-imap
--with-imap-ssl
There was a php4 rpm
Am Dienstag, 8. Mai 2007 14:12 schrieben Sie:
Ah, so you're compiling a threadsafe PHP to use with a non-threadsafe
Apache and loading both PHP4 and PHP5 in the same time. This looks like a
total misconfiguration.
That's right. It was obviously misconfigured!
I see no connection to
So why don't you come up with a different better solution then?
Not breaking streams in php 6?
--
Stanislav Malyshev, Zend Products Engineer
[EMAIL PROTECTED] http://www.zend.com/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
include to work on those. Making a hack in PHP to allow phar://
streams to work is a bad idea, a C-extension can easily work here.
So from now on, every time we would want to user stream we'd have to do
C extension and all user stream functionality in PHP is just useless?
And all that for
either Greg or me as PHP customers. Nor was Phar designed to solve
that particular issue alone. It was designed to deliver a stable and
fast implementation of PHP_Archive that can be bundled into PHP as
a C extension.
That's fine, the question is why exactly we need fast implementation of
maintaining the pdo_sqlrelay package
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
on every fwrite. And you can not first cache it in memory as you then
lose the whole advantage of this idea.
IIRC sessions are locked by php anyway, and for other uses if locking is
important it is already implemented anyway, so we shouldn't really try
to solve all the world's problems with
? Nobody is talking about sessions here, just about the serialize()
You mean you are not talking about sessions. I, however, do. Sessions
are one of the obvious examples where such functionality could improve
performance.
function that is also used for a myriad of other things...
Oh
Stanislav Malyshev wrote:
? Nobody is talking about sessions here, just about the serialize()
You mean you are not talking about sessions. I, however, do. Sessions
are one of the obvious examples where such functionality could improve
performance.
Well as the topic implies I am quite sure
On Mon, May 07, 2007 at 04:30:28PM -0500, Richard Lynch wrote:
Can you PLEASE make 100% certain that this is specifically documented
to NOT be a Security Feature and it is NOT intended to indicate
secure transmission of the file?
It is not meant to be a security feature. Not in the least.
On Mon, May 07, 2007 at 06:37:29PM -0700, Sara Golemon wrote:
Ditto Richard's comments about false-implications of security, but I'd
also like to add that *IF* folks decide on the whole that this is
worth adding, it should be done more generically than a setting for
md5 and a setting for sha1.
Well as the topic implies I am quite sure that the user request was
about caching into a custom file and not inside the session. Both are
frequent use cases.
If his cache had no locking before, what changed?
--
Stanislav Malyshev, Zend Products Engineer
[EMAIL PROTECTED] http://www.zend.com/
Stanislav Malyshev wrote:
I think it is a good reason. There are plenty of tool-like PHP
applications. Not having to install these, but just be able to
I know one - PEAR. And it's kinds special because it's library
installer. What others are there?
Documentation and other code analyis
On 5/8/07, Richard Quadling [EMAIL PROTECTED] wrote:
On 06/05/07, Tijnema ! [EMAIL PROTECTED] wrote:
On 5/6/07, David Coallier [EMAIL PROTECTED] wrote:
On 5/5/07, Jan Reininghaus [EMAIL PROTECTED] wrote:
I am currently working on my second draw for the page, but I have a
question. For
Antony Dovgal wrote:
On 05/08/2007 04:02 PM, Oliver Block wrote:
Am Dienstag, 8. Mai 2007 13:45 schrieben Sie:
What was your configure line?
./configure --with-apxs2=/usr/sbin/apxs2 --prefix=/usr/local/php5
--enable-debug --enable-maintainer-zts --with-mysql --with-imap
--with-imap-ssl
On Tue, May 8, 2007 10:30 am, David Coallier wrote:
Here is an optimized version for early browsers:
http://dev.agoraproduction.com/php/snaps/snaps2.php
Works for me.
[not a joke]
I'd rather have a simple site that works in Mozaic 1.0 than something
that only mostly kinda sorta works in
On Tue, May 8, 2007 1:17 am, Derick Rethans wrote:
On Mon, 7 May 2007, Lukas Kahwe Smith wrote:
Stanislav Malyshev wrote:
can write this data to disk. So, you needs 20MB. If serialize
(and of
course unserialize) would be able to write directly to disk (or
read
directly from disk),
On Tue, 8 May 2007, Richard Lynch wrote:
On Tue, May 8, 2007 1:17 am, Derick Rethans wrote:
On Mon, 7 May 2007, Lukas Kahwe Smith wrote:
Stanislav Malyshev wrote:
can write this data to disk. So, you needs 20MB. If serialize
(and of course unserialize) would be able to write
On May 5, 2007, at 6:47 PM, Gwynne Raskind wrote:
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
When I first wrote PHP_Archive the entire point of the stub script was
to handle incoming requests, just like the multitude of applications
that have everything go through index.php (S9Y for an example).
Using Phar with MultiViews and mod_rewrite is just same as funnelling
everything through
Stanislav Malyshev wrote:
serving them as a static page. But applications like S9Y, FUDForum,
phpMyAdmin where the *typical* usage is not to serve a large number of
users, this is usually not an issue.
In other words, it is not meant to deploy production applications, only
local-user
No, not in other words. I said the words I said, because I meant those
words. I'm talking about small *production* deployments. I don't see
Why small deployment can't use PHP phar then? If they don't use bytecode
cache parsing PHP on each request obviously isn't a problem for them.
--
Stanislav Malyshev wrote:
No, not in other words. I said the words I said, because I meant
those words. I'm talking about small *production* deployments. I don't
see
Why small deployment can't use PHP phar then? If they don't use bytecode
cache parsing PHP on each request obviously isn't a
On 5/8/07, Davey Shafik [EMAIL PROTECTED] wrote:
Stanislav Malyshev wrote:
No, not in other words. I said the words I said, because I meant
those words. I'm talking about small *production* deployments. I don't
see
Why small deployment can't use PHP phar then? If they don't use bytecode
Stanislav Malyshev wrote:
I think it is a good reason. There are plenty of tool-like PHP
applications. Not having to install these, but just be able to
I know one - PEAR. And it's kinds special because it's library
installer. What others are there?
phpdocumentor, phpunit, phpcodesniffer,
Pierre wrote:
I'm in general in favour of phar but I don't think we should start 5.3
for it. I don't think either that it is stable enough to be bundled. I
doubt it is possible to have a stable package in only three public
releases (even the first public release was already marked stable).
Gregory Beaver wrote:
Stanislav Malyshev wrote:
I think it is a good reason. There are plenty of tool-like PHP
applications. Not having to install these, but just be able to
I know one - PEAR. And it's kinds special because it's library
installer. What others are there?
phpdocumentor,
Hello Antony,
it make it much harder as you would need to load PHP_Archive before
you can do anything else with them. It would mean you cannot easily
execute them unless they contain PHP_Archive themselves
best regards
marcus
Tuesday, May 8, 2007, 11:39:32 AM, you wrote:
On 05/08/2007
I also just realized, these are also all tools where you probably do not
want APC to store the bytecode in memory. Furthermore it is however
still quite useful to have your unit test executing quickly.
How speed of the tests would depend on speed of the loading phpunit
runner? I don't believe
Stanislav Malyshev wrote:
I also just realized, these are also all tools where you probably do
not want APC to store the bytecode in memory. Furthermore it is
however still quite useful to have your unit test executing quickly.
How speed of the tests would depend on speed of the loading
On 05/09/2007 02:00 AM, Marcus Boerger wrote:
Hello Antony,
it make it much harder as you would need to load PHP_Archive before
you can do anything else with them. It would mean you cannot easily
execute them unless they contain PHP_Archive themselves
It's harder for those who create
Hello Pierre,
Tuesday, May 8, 2007, 10:59:08 PM, you wrote:
On 5/8/07, Davey Shafik [EMAIL PROTECTED] wrote:
Stanislav Malyshev wrote:
No, not in other words. I said the words I said, because I meant
those words. I'm talking about small *production* deployments. I don't
see
Why small
Stanislav Malyshev wrote:
include to work on those. Making a hack in PHP to allow phar://
streams to work is a bad idea, a C-extension can easily work here.
So from now on, every time we would want to user stream we'd have to do
C extension and all user stream functionality in PHP is just
There is no reason to have PHP_Archive in a phar. No need whatsoever...
it would be a waste of space! Not having the extension would lead to
Yes, the whole whopping 20K of space uncompressed and with comments, so
could be probably 10K or less without comments, whitespace and minimized
for
The only solution that would allow userspace streams to function *and*
allow security would be to implement safe_mode 2.0: disable all remote
No, that's not the only solution. Other solution would be stop trying to
do what should be done on entirely other level and do it on the OS
level, not
Stanislav Malyshev wrote:
There is no reason to have PHP_Archive in a phar. No need whatsoever...
it would be a waste of space! Not having the extension would lead to
Yes, the whole whopping 20K of space uncompressed and with comments, so
could be probably 10K or less without comments,
56 matches
Mail list logo
