Hi Guys,
I am not sure if anybody is aware i went to download an older version of the
windows PHP binary on http://museum.php.net/php5/php-5.1.6-Win32.zip which
appears to be missing.
Regards
Jarratt
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, whitesp
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 t
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 extr
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
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
>> >>
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 phar
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 phpuni
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
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 01
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, phpu
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).
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, phpcodesn
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 b
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
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.
--
Stan
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 applicat
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 applicat
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 applications. Then the question rai
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
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
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 ab
On Tue, May 8, 2007 9:13 am, David Santinoli wrote:
> If there's enough interest in this, I will rework the patch according
> to
> Sara's hint.
I'd have to be +1 on making more than just the 2 hashes available for
this feature, though if it's a *TON* of work...
--
Some people have a "gift" link
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
>> > > dire
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 "curr
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-
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
> > >
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 too
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?
--
Stanislav Malyshev, Zend Products Engineer
[EMAIL PROTECTED] ht
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/
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 sh
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 l
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 t
Stanislav Malyshev wrote:
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 fa
? 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 reall
On Tue, 8 May 2007, Stanislav Malyshev wrote:
> > 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 shoul
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 th
On Tue, 8 May 2007, Stanislav Malyshev wrote:
> > If we're to add this, make sure writes to the files are atomic.
>
> Does PHP now ensure fwrite is atomic? If it doesn't than writing on serialize
> doesn't change a thing.
Only "a" mode is atomic - per write call; normal fwrites are not.
However
If we're to add this, make sure writes to the files are atomic.
Does PHP now ensure fwrite is atomic? If it doesn't than writing on
serialize doesn't change a thing.
--
Stanislav Malyshev, Zend Products Engineer
[EMAIL PROTECTED] http://www.zend.com/
--
PHP Internals - PHP Runtime Developmen
maintaining the pdo_sqlrelay package
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
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
PHP_A
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 so
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
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 threads
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 whi
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 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 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
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 feat
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
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 /usr/
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 s
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 zend_sym
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
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 mainstrea
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 arou
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 b
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 e
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
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)) {
ap_add_versi
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.
Le
61 matches
Mail list logo
