Hi Lester, Milan,
On Wed, Jun 25, 2008 at 7:35 AM, Lester Caine [EMAIL PROTECTED] wrote:
Not a lot of use as it does not give details of how to JOIN
php.internals.win
I sent the email to subscribe, but the commands are the same for all php lists:
list-name[EMAIL PROTECTED]
or
Pierre Joye wrote:
Hi Lester, Milan,
On Wed, Jun 25, 2008 at 7:35 AM, Lester Caine [EMAIL PROTECTED] wrote:
Not a lot of use as it does not give details of how to JOIN
php.internals.win
I sent the email to subscribe, but the commands are the same for all php lists:
list-name[EMAIL
Ryan Panning wrote:
Are you looking for this?
http://news.php.net/
Been there. Don't see any way to subscribe to internals-win, so I can
post to it. Or am I missing something?
Thanks,
--
Milan Babuskov
http://www.guacosoft.com
--
PHP Internals - PHP Runtime Development Mailing List
To
Pierre Joye wrote:
You don't have to be a windows pro as long as you can test it on
windows. The main problem now is that we had no maintainer to take
care of the bugs (there is bugs), to valid a release (sources or
binary), etc.
Are you (still) interested? :)
Yes.
I'll report back when I
Hi,
Stanislav Malyshev wrote:
In general, building PHP on windows should be as easy as on Unix, not
requiring any special knowledge of the tools, meaning:
1. Get environment with MSVC set up
2. Get external libraries (recommended to put them in same upper-level
dir as php checkout)
3. Run
Rob Richards wrote:
Moving this to the windows list.
I'm having problems to post on it. Care to forward?
Make sure you are using the Visual Studio command prompt as it will
setup your env for you (all the paths, etc...).
I am. As I wrote, I can compile wxWidgets and FlameRobin without any
Rob Richards wrote:
Moving this to the windows list.
I'm having problems to post on it via newsgroup interface, and I don't
know how to subscribe to the mailing list, since it is not listed here:
http://www.php.net/mailing-lists.php
Is there a way to contact someone to add it?
Thanks,
--
Milan Babuskov wrote:
Rob Richards wrote:
Moving this to the windows list.
I'm having problems to post on it via newsgroup interface, and I don't
know how to subscribe to the mailing list, since it is not listed here:
http://www.php.net/mailing-lists.php
Is there a way to contact someone
Ryan Panning wrote:
Milan Babuskov wrote:
Rob Richards wrote:
Moving this to the windows list.
I'm having problems to post on it via newsgroup interface, and I don't
know how to subscribe to the mailing list, since it is not listed here:
http://www.php.net/mailing-lists.php
Is there a
Lukas Kahwe Smith wrote:
if nobody with C hacking skills is feeling sufficient pain over this,
the assumption is that the pool of users is too small or the pain is too
small.
Hi,
sorry for such late reply, but I just joined this group. I'm very
interested in Firebird's future in PHP and I
On 23.06.2008, at 14:54, Milan Babuskov wrote:
Lukas Kahwe Smith wrote:
if nobody with C hacking skills is feeling sufficient pain over
this, the assumption is that the pool of users is too small or the
pain is too small.
sorry for such late reply, but I just joined this group. I'm very
On Mon, Jun 23, 2008 at 2:54 PM, Milan Babuskov [EMAIL PROTECTED] wrote:
Lukas Kahwe Smith wrote:
if nobody with C hacking skills is feeling sufficient pain over this, the
assumption is that the pool of users is too small or the pain is too small.
Hi,
sorry for such late reply, but I just
Pierre Joye wrote:
if nobody with C hacking skills is feeling sufficient pain over this, the
assumption is that the pool of users is too small or the pain is too small.
sorry for such late reply, but I just joined this group. I'm very interested
in Firebird's future in PHP and I have C skills.
Hi!
Now, when we're at it, my experience with MSVC and Windows command line
tools is almost none. I tried to build PHP 5.3 with it, but the guide on
PHP website has some errors (some stuff just isn't where it says it is,
and it seems some steps are skipped. Also, the 'configure' script used
On Mon, Jun 23, 2008 at 5:36 PM, Milan Babuskov [EMAIL PROTECTED] wrote:
Pierre Joye wrote:
if nobody with C hacking skills is feeling sufficient pain over this,
the
assumption is that the pool of users is too small or the pain is too
small.
sorry for such late reply, but I just joined
Wez Furlong wrote:
On 5/7/07, Lester Caine [EMAIL PROTECTED] wrote:
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.
Umm, no. Nobody has time for firebird because nobody uses it.
I ask people about
Wez Furlong wrote:
On 5/7/07, Lester Caine [EMAIL PROTECTED] wrote:
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.
Umm, no. Nobody has time for firebird because nobody uses it.
I ask people about
Lester Caine wrote:
PDO simply changes the ground rules without solving any particular
problem as has been said all along. Now you may well convince people
that all the native drivers should be dropped from PHP and only PDO
supplied but I hope that does not happen and that we have a PROPER
Hello Wez,
one is doing this:
stream-orig_path = estrdup(opened_path);
the other something else:
stream-open_filename = __zend_orig_filename ? __zend_orig_filename :
__zend_filename;
stream-open_lineno = __zend_orig_lineno ? __zend_orig_lineno :
__zend_lineno;
best regards
marcus
The point you're missing is that those features all belong in the
firebird driver, not in PDO itself.
--Wez.
On 5/23/07, Lester Caine [EMAIL PROTECTED] wrote:
Wez Furlong wrote:
On 5/7/07, Lester Caine [EMAIL PROTECTED] wrote:
No one has time to work on the
Firebird PDO driver because we
I'd modify that to say that no one with the C skills is interested in
taking it over, and there is almost no incentive to do this because
no one uses it.
--Wez.
On 5/23/07, Lukas Kahwe Smith [EMAIL PROTECTED] wrote:
But anyways, the problem is of course not that
we are uninterested in
Wez Furlong wrote:
I'd modify that to say that no one with the C skills is interested in
taking it over, and there is almost no incentive to do this because
no one uses it.
I would not say that on the firebird-php list Wez - one hell of a lot of
people rely on it for their livelyhood. I know
Lester Caine wrote:
Wez Furlong wrote:
I'd modify that to say that no one with the C skills is interested in
taking it over, and there is almost no incentive to do this because
no one uses it.
I would not say that on the firebird-php list Wez - one hell of a lot of
people rely on it for
On 5/4/07, Marcus Boerger [EMAIL PROTECTED] wrote:
2) Add open_filename debug info to streams
What is this feature and how is it different from stream-orig_path
that has been around for several releases?
--Wez.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit:
On 5/7/07, Lester Caine [EMAIL PROTECTED] wrote:
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.
Umm, no. Nobody has time for firebird because nobody uses it.
I ask people about Firebird at each conference
From: Greg Beaver [mailto:[EMAIL PROTECTED]
Both phar/PHP_Archive and PHK support this. The only file
format that would allow this kind of shebang is the tar
file format, as the first element in the file is a filename.
The original design of PHP_Archive used the tar file format
to
Hello LAUPRETRE,
Tuesday, May 15, 2007, 7:12:27 PM, you wrote:
From: Greg Beaver [mailto:[EMAIL PROTECTED]
This is exactly how phar/PHP_Archive works. For example:
http://pear.php.net/go-pear.phar contains the complete
PHP_Archive class, which will fall back to the phar extension
if
Yes, noone hinders you to write PHP_Archieve into your stub when using
the Phar extension.
Actually, I would say it would be better to have some minimized
version which is extract-only, has all the comments stripped, etc. for
inclusion in the archives.
--
Stanislav Malyshev, Zend Products
Stanislav Malyshev wrote:
Yes, noone hinders you to write PHP_Archieve into your stub when using
the Phar extension.
Actually, I would say it would be better to have some minimized
version which is extract-only, has all the comments stripped, etc. for
inclusion in the archives.
This is
From: Greg Beaver [mailto:[EMAIL PROTECTED]
With all due respect, this is a rather severe exaggeration of
PHK's talents.
PHK does *not* use a standardized file format like ZIP, and
the format is undocumented as of last Friday when I read all
of the docs at your site.
Right. As for
LAUPRETRE François (P) wrote:
From: Greg Beaver [mailto:[EMAIL PROTECTED]
With all due respect, this is a rather severe exaggeration of
PHK's talents.
PHK does *not* use a standardized file format like ZIP, and
the format is undocumented as of last Friday when I read all
of the docs
On 5/14/07, Greg Beaver [EMAIL PROTECTED] wrote:
And, if they don't, unfortunately, it will be one more reason not to
switch to PHP 6 :)
It has been several times by several developers that this specific
problem will/must be fixed, no matter if whateveryoulike will be
bundled or not. It
And, if they don't, unfortunately, it will be one more reason not to
switch to PHP 6 :)
I hate to be the one to burst our bubble, but unicode is a killer
feature and PHP 6 will be adopted en masse, so if this isn't changed, it
will simply mean the death of userspace stream wrappers for
LAUPRETRE François (P) wrote:
From: Stanislav Malyshev [mailto:[EMAIL PROTECTED]
...and phar is the best candidate I know for this.
I'd say the only one
NO, there is an alternate PHP package format. It solves every issues you
rose about phar (including the direct url access to a virtual
Am Freitag, 4. Mai 2007 20:16 schrieb Edin Kadribasic:
I think that Phar is going to be useful only if its
universally available in the PHP installs, and I think that would a good
thing for PHP.
Edin, why do you bind the usefulness to the number of installs? That sounds
more like enthusiam
Am Freitag, 4. Mai 2007 21:24 schrieb Ilia Alshanetsky:
It sounds like the merits of having phar is would only be apparent
after it is included in the core and everyone starts using it because
of that. This won't happen simply because most software producers
can't rely on extensions that are
Am Freitag, 4. Mai 2007 20:09 schrieb Antony Dovgal:
not the other way round. If you don't like PECL or think it's too difficult
to use, let's make it easy enough for all.
That is good point. If PECL extensions could be integrated into php by just
set --enable-extensionX while compiling the
Hello Oliver,
we are discussing situations where make is no option here. Everone that
hasmake as an option and all tools available can always easily do:
pecl install extension
Without the pear or pecl commandyou can also simply download the pecl
extension package and do the following:
tar -x
That is good point. If PECL extensions could be integrated into php by just
set --enable-extensionX while compiling the php distribution. That would be a
Maybe in more generic form like --enable-pecl=EXTENSION or
--enable-pecl=/path/to/file.tgz but if autoconf magicians among us could
pull
On 5/10/07, Stanislav Malyshev [EMAIL PROTECTED] wrote:
That is good point. If PECL extensions could be integrated into php by just
set --enable-extensionX while compiling the php distribution. That would be a
Maybe in more generic form like --enable-pecl=EXTENSION or
Am Donnerstag, 10. Mai 2007 22:47 schrieb Marcus Boerger:
we are discussing situations where make is no option here.
However this is in many situation not possible at all. For once it is
impossible if you are using a shared server.
I know, If I follow that part of the discussion, it's about
On 5/9/07, Marcus Boerger [EMAIL PROTECTED] wrote:
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
From: Stanislav Malyshev [mailto:[EMAIL PROTECTED]
...and phar is the best candidate I know for this.
I'd say the only one
NO, there is an alternate PHP package format. It solves every issues you
rose about phar (including the direct url access to a virtual file). Its
name is PHK and it
-Original Message-
From: Stanislav Malyshev [mailto:[EMAIL PROTECTED]
I guess we are solving the wrong problem. We have:
1. phar needs script-defined named streams
2. Named streams are prohibited by some config option
3. Let's pretend this stream is not actually what it is
4.
PROTECTED]
Sent: Wednesday, May 09, 2007 4:23 AM
To: Stas Malyshev; Stefan Priebsch
Cc: internals@lists.php.net
Subject: [PHP-DEV] RE : [PHP-DEV] [RFC] Starting 5.3
From: Stanislav Malyshev [mailto:[EMAIL PROTECTED]
...and phar is the best candidate I know for this.
I'd say the only one
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
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
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
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
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
: Friday, May 04, 2007 12:44 PM
To: Stas Malyshev
Cc: Edin Kadribasic; internals@lists.php.net
Subject: Re: [PHP-DEV] [RFC] Starting 5.3
Hello Stanislav,
- you don't need a tool - well php - but hey you probbaly
have that tool
- you can run phar archives out of the box - untouched
- you can
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,
To: Marcus Boerger
Cc: internals@lists.php.net
Subject: Re: [PHP-DEV] [RFC] Starting 5.3
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.
Ilia
--
PHP
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
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 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
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
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
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
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
1 - 100 of 158 matches
Mail list logo
