I see no value in making compatibility breaks in 5.x and not in the next
major version. As it is we drive a lot of our users crazy. We already
agreed this is a 6.x thing.
-Original Message-
From: Ilia Alshanetsky [mailto:[EMAIL PROTECTED]
Sent: Sunday, May 06, 2007 11:12 AM
To:
Hi,
On 5/7/07, Stanislav Malyshev [EMAIL PROTECTED] wrote:
pear install phar - or - pecl install phar - done
oh wait the point is that pecl install doesn't work or is in 99% no option
And what is pear install? I don't have such command in my Windows by
default. Neither I have it on my
Sorry, I apologize. Although you were curt I should not have been so in
reply.
I used to manage development of a reasonably popular open source
project, and if one of our developers had ever said something like that,
it would have greatly annoyed me. You never really lose that.
Although I
A little note about executing a phar file, no phar extension is
required to execute a phar archive, neither to create it (see
Right, but php and PEAR are required to read/create/inspect the archive.
--
Stanislav Malyshev, Zend Products Engineer
[EMAIL PROTECTED] http://www.zend.com/
--
PHP
Hi,
On 5/7/07, Stanislav Malyshev [EMAIL PROTECTED] wrote:
A little note about executing a phar file, no phar extension is
required to execute a phar archive, neither to create it (see
Right, but php and PEAR are required to read/create/inspect the archive.
Who has inspected pear.phar? Not
.php) or as a self contained installer. But I would not recommend to
ever use a phar for other purposes like in a production environment.
That's the question - if phar is not to be recommended in production as
deployment format, it belongs to PECL.
--
Stanislav Malyshev, Zend Products
Hello steve,
why don't you give it a try:
http://de.php.net/phar
http://pecl.php.net/package/phar
marcus
Monday, May 7, 2007, 4:55:10 AM, you wrote:
Before reading the thread on the idea of a PHP 5.3 branch, I had never
heard of phar, so please excuse my neophyte questions, but I couldn't
Hello Stanislav,
Monday, May 7, 2007, 7:07:09 AM, you wrote:
they most likely don't, it is designed for deployment and for running
includes directly.
What do you mean directly? Do you mean this is designed for running
application only specifically crafted to run inside phar and would break
It means you can run a phar file. How is that so hard to understand.
It is not hard to understand. What seems to be hard to understand is
that the scenario you describe is by no way the only scenario PHP files
run in. Not all applications are single entry point and of those that
are, not all
phar is a good way of deploying PHP code, as PEAR proves. As a cautious
developer however, I am reluctant to using optional features that might
not be available on my client's installation. And for regular users of
PHP-based software, installing a PECL extension is not an option. If I
cannot be
Andi Gutmans wrote:
I see no value in making compatibility breaks in 5.x and not in the next
major version. As it is we drive a lot of our users crazy. We already
agreed this is a 6.x thing.
IMHO one good reason to start a new branch for 5.x would be
the ability to get rid off
PHP-based software, installing a PECL extension is not an option. If I
cannot be sure that phar works on my client's system, I cannot use it to
deploy software.
Unless your clients immediately upgrade to php 5.3 this is the case
anyway for some time (probably measured in years).
Uploading a
Stefan Priebsch wrote:
phar is a good way of deploying PHP code, as PEAR proves. As a cautious
developer however, I am reluctant to using optional features that might
not be available on my client's installation. And for regular users of
PHP-based software, installing a PECL extension is not an
Hello Stanislav,
Monday, May 7, 2007, 10:04:16 AM, you wrote:
PHP-based software, installing a PECL extension is not an option. If I
cannot be sure that phar works on my client's system, I cannot use it to
deploy software.
Unless your clients immediately upgrade to php 5.3 this is the case
Stanislav Malyshev schrieb:
Unless your clients immediately upgrade to php 5.3 this is the case
anyway for some time (probably measured in years).
Sure. But since PHP4 support is discontinued by the end of this year,
people will have to upgrade to 5.x (or 6) anyway. That would put phar
support
On Sun, 6 May 2007, Unknown W. Brackets wrote:
Sorry, I apologize. Although you were curt I should not have been so in
reply.
I used to manage development of a reasonably popular open source project, and
if one of our developers had ever said something like that, it would have
greatly
PHP 4 Bug Database summary - http://bugs.php.net
Num Status Summary (631 total including feature requests)
===[*Directory/Filesystem functions]
40661 Open cwd is reset when shutdown handler runs
Lester Caine schrieb:
And given the problem getting hosts to ADD PECL extensions, you expect
that they will allow a third party application to install things on
their locked down machines. I think the first problem is how does it
integrate with hosting environments and will those hosts allow
PHP 6 Bug Database summary - http://bugs.php.net
Num Status Summary (42 total including feature requests)
===[*General Issues]==
26771 Suspended register_tick_funtions crash under threaded webservers
27372 Verified parse error
I fully agree to that. I (currently) see phar as a means of deploying
PHP code. But when people start running PHP apps from a phar, I am sure
Then you don't need any extension - install should run without it quite
well.
And, if APC becomes more wide-spread in the future, I guess it does not
Hi,
I'm submitting a patch to perform on the fly MD5/SHA1 digest
calculation of a file uploaded via the HTTP POST method. Being
not uncommon for applications to require some digest of a freshly
uploaded file, doing the math directly in the buffer where the file is
being read can save some
Marcus Boerger wrote:
Well alot of people make use of our PEAR project. It comes with a bunch of
nice sub projects. And even some external (as in non PHP) applications and
projects make use of it. Providing a better internal infrastructure would be
very nice here.
Stas, not sure if you are
On Fri, 4 May 2007, Lukas Kahwe Smith wrote:
Ilia Alshanetsky wrote:
On 4-May-07, at 3:14 PM, Lukas Kahwe Smith wrote:
Yes, to me the question is only if we want to give the message that
software producers should be able to expect phar to be there on 99% of the
systems. Thats
Stanislav Malyshev wrote:
It means you can run a phar file. How is that so hard to understand.
It is not hard to understand. What seems to be hard to understand is
that the scenario you describe is by no way the only scenario PHP files
run in. Not all applications are single entry point and
On Sun, 6 May 2007, Mike Robinson wrote:
It could well be the last chance to get the mail() logger into 5.x as well,
and IMHO a lot of
people are waiting for this that can't/won't migrate to PHP6 quickly.
There is no reason why that can't go into PHP 5.2.3.
regards,
Derick
--
Derick
On 05/07/2007 04:18 PM, Lukas Kahwe Smith wrote:
Marcus Boerger wrote:
Well alot of people make use of our PEAR project. It comes with a bunch of
nice sub projects. And even some external (as in non PHP) applications and
projects make use of it. Providing a better internal infrastructure would
On Sun, 6 May 2007, Lukas Kahwe Smith wrote:
Ilia Alshanetsky wrote:
IMHO one good reason to start a new branch for 5.x would be the ability to
get rid off register_globals and magic_quotes in the 5 series without having
to wait for PHP6 to come around.
What would be the goal of that?
On Mon, 7 May 2007, Lester Caine wrote:
Andi Gutmans wrote:
I see no value in making compatibility breaks in 5.x and not in the next
major version. As it is we drive a lot of our users crazy. We already
agreed this is a 6.x thing.
IMHO one good reason to start a new branch for 5.x
On Mon, 7 May 2007, Antony Dovgal wrote:
On 05/06/2007 10:11 PM, Ilia Alshanetsky wrote:
IMHO one good reason to start a new branch for 5.x would be the ability to
get rid off register_globals and magic_quotes in the 5 series without
having to wait for PHP6 to come around.
That's
Really? I've used this pseudonym for years and years, dozens and dozens
of places. I've got a patch checked into Mozilla using it. I've
communicated with other developers in a wide variety of places...
I cannot recall anyone saying it was rude of me to use such a name. In
fact, most
Derick Rethans wrote:
PHP6 is the next release - PHP5 should now be tied down and put on the same
basis as PHP4 before we end up with even more private initiatives creating
even more mayhem :(
If people want these changes why aren't they working to get PHP6 out?
Amen, besides that you should
Lester Caine wrote:
As for phar? It sounds a little like PDO. No one has time to work on the
Firebird PDO driver because we still need the main driver to provide the
functions PDO does not support. Proper discussion and development of
elements that are planned to become main stream would be
On 5/7/07, Unknown W. Brackets [EMAIL PROTECTED] wrote:
Really? I've used this pseudonym for years and years, dozens and dozens
of places. I've got a patch checked into Mozilla using it. I've
communicated with other developers in a wide variety of places...
I cannot recall anyone saying it
Gregory Beaver wrote:
Phar is not yet perfect, but is also not NEARLY as complex as PDO.
There is no comparison.
The 'comparison' was in the way these packages get added without proper
investigation ;) Someone decides that THIS is how it will be done, and that is
what happens :( and we have
Lester Caine wrote:
Andi Gutmans wrote:
I see no value in making compatibility breaks in 5.x and not in the next
major version. As it is we drive a lot of our users crazy. We already
agreed this is a 6.x thing.
IMHO one good reason to start a new branch for 5.x would be the
ability to get
Antony Dovgal wrote:
On 05/07/2007 04:18 PM, Lukas Kahwe Smith wrote:
Marcus Boerger wrote:
Well alot of people make use of our PEAR project. It comes with a
bunch of
nice sub projects. And even some external (as in non PHP)
applications and
projects make use of it. Providing a better
Lester Caine wrote:
Gregory Beaver wrote:
Phar is not yet perfect, but is also not NEARLY as complex as PDO.
There is no comparison.
The 'comparison' was in the way these packages get added without proper
investigation ;) Someone decides that THIS is how it will be done, and
that is what
Hello Stanislav,
Monday, May 7, 2007, 11:50:15 AM, you wrote:
I think one advantage of phar is that it is backed by PEAR tools that
I think it's a disadvantage.
So you would like to drop PEAR?
distributing PEAR files - but when we
talking about PHP-wide policy I don't think we should
On 7-May-07, at 2:24 PM, Marcus Boerger wrote:
Because believe it or not a bunch ofpeople use PEAR.
Scary, ain't it? ;-)
Ilia Alshanetsky
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On 5/7/07, Ilia Alshanetsky [EMAIL PROTECTED] wrote:
On 7-May-07, at 2:24 PM, Marcus Boerger wrote:
Because believe it or not a bunch ofpeople use PEAR.
Scary, ain't it? ;-)
Totally other discussion, but I don't think it's scary, we are pushing
for much more solid packages and more secure
Stas, not sure if you are aware of this, but the PEAR installer has
gotten wide adoption as a deployment tool.
Meaning a lot of people are running apps packaged in phar's? Could you
bring forward some examples?
--
Stanislav Malyshev, Zend Products Engineer
[EMAIL PROTECTED]
David Coallier wrote:
Anyone has an answer/tests to that bug* so we can stop this discussion ? :)
The bug has apparently been fixed in CVS. Haven't had a chance to test
it, but will do as soon as possible.
Now the question is: When can we expect an update? I see people talking
about what
Stanislav Malyshev schrieb:
All power to them, but why should they use phar as runtime format?
Maybe we could agree on using phar as a means of deploying PHP code, as
I pointed out earlier? Otherwise it seems, as Greg has pointed out, that
PEAR as it is will become pretty useless with the
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 problem. We have:
1. phar needs script-defined named
Hi,
There has been a bit of inevitable FUD with phar. Although the manual
(http://php.net/phar) describes a fair amount of how phar works, the
design decisions are not documented.
Originally, the phar stream wrapper was a userspace thing. Davey Shafik
designed it to take advantage of a neat
Maybe we could agree on using phar as a means of deploying PHP code, as
I pointed out earlier? Otherwise it seems, as Greg has pointed out, that
PEAR as it is will become pretty useless with the release of PHP6.
We could. But you don't need no extensions for that. If PHP6 makes PEAR
useless,
Stefan Priebsch wrote:
Stanislav Malyshev schrieb:
All power to them, but why should they use phar as runtime format?
Maybe we could agree on using phar as a means of deploying PHP code, as
I pointed out earlier? Otherwise it seems, as Greg has pointed out, that
PEAR as it is will become
Gregory Beaver schrieb:
Correction: the *installation* process for PEAR will have to be reverted
to the way it worked in PHP 4. PEAR is unaffected by these changes.
Which, from the end user's viewpoint, makes PEAR useless because they
cannot install PEAR in the first place. That's what I
So if you are wondering about use cases, the PEAR installer is a good
example. Generally I would say phar lends itself for self installing
Let's separate phar as installer format and phar as runtime format. Only
problem I have with the former is that it's custom NIH-syndrome-enabled
format
On 05/07/2007 10:39 PM, 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/7/07, Antony Dovgal [EMAIL PROTECTED] wrote:
On 05/07/2007 10:39 PM, 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
The stub could also easily include code to allow for an extraction flag
to work. So you could run php my.phar --extract and have the code dumped
to the FS as it originally was.
The choice to add these things (the stub and the extract flag), is just
that, a choice. The same as choosing short
On 7-May-07, at 2:35 PM, Dirk Haun wrote:
David Coallier wrote:
Anyone has an answer/tests to that bug* so we can stop this
discussion ? :)
The bug has apparently been fixed in CVS. Haven't had a chance to test
it, but will do as soon as possible.
Please let me know how it works out.
Hello Stanislav,
Monday, May 7, 2007, 8:50:18 PM, you wrote:
So if you are wondering about use cases, the PEAR installer is a good
example. Generally I would say phar lends itself for self installing
Let's separate phar as installer format and phar as runtime format. Only
problem I have
Ilia Alshanetsky wrote:
The bug has apparently been fixed in CVS. Haven't had a chance to test
it, but will do as soon as possible.
Please let me know how it works out.
I've tested php5.2-200705071830.tar.gz from snaps.php.net and the bug
seems to be fixed. Thanks.
One interesting feature
Ilia Alshanetsky wrote:
On 7-May-07, at 2:35 PM, Dirk Haun wrote:
David Coallier wrote:
Anyone has an answer/tests to that bug* so we can stop this
discussion ? :)
The bug has apparently been fixed in CVS. Haven't had a chance to test
it, but will do as soon as possible.
Please let
On 7-May-07, at 4:00 PM, Rasmus Lerdorf wrote:
I must have missed something. Did you change the documented behaviour
that $_SERVER['HTTP_RAW_POST_DATA'] is populated when PHP
encounters an
unknown content type? If so, that was most definitely not a bug
and not
something that should have
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.
- to be able to have PHARs without pretty big PHP_Archive stuff included
It's for install, how big could it
Ilia Alshanetsky wrote:
On 7-May-07, at 4:00 PM, Rasmus Lerdorf wrote:
I must have missed something. Did you change the documented behaviour
that $_SERVER['HTTP_RAW_POST_DATA'] is populated when PHP encounters an
unknown content type? If so, that was most definitely not a bug and not
What purpose does this serve, exactly?...
Seems like anybody who can intercept the upload and send bad file data
can also send a matching MD5 for the bad data...
Actually, re-reading the message clarified for me that you're doing
this only to save the time of whatever it would take to do an MD5
On Mon, May 7, 2007 2:30 pm, Dirk Haun wrote:
Ilia Alshanetsky wrote:
I sure hope those nifty Web 2.0 sites don't use SOAP and XML-RPC but
rather JSON or REST.
Okay, but XML-RPC is used for Pingbacks, Trackbacks, and for pinging
weblog directories like Technorati. That's something like the
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 serialize/unserialize be able to write directly to a
stream and read directly from a stream
On Mon, May 7, 2007 1:17 am, Andi Gutmans wrote:
I see no value in making compatibility breaks in 5.x and not in the
next
major version. As it is we drive a lot of our users crazy. We already
agreed this is a 6.x thing.
+1
If there has to be a 5.3, I'd want to see features that:
are
Stefan Priebsch wrote:
Gregory Beaver schrieb:
Correction: the *installation* process for PEAR will have to be reverted
to the way it worked in PHP 4. PEAR is unaffected by these changes.
Which, from the end user's viewpoint, makes PEAR useless because they
cannot install PEAR in
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 serialize/unserialize be able to write directly to a
stream and read
Gregory Beaver wrote:
[snip]
megabytes of information just to locate a file. The zip file format has
the same limitation - the entire archive needs to be scanned.
Both of these formats were not designed for random access in the way a
traditional filesystem is designed. In fact, I could not
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_version_component(p, PHP/ PHP_VERSION);
}
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.
e.g.
input type=hidden name=__COMPUTE_HASH value=md5
or
68 matches
Mail list logo
