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 uns
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:
[EMAIL PROTECTED]
[EMAI
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:
[EMAIL PROTECTED]
or
[EMAIL PROTECTED] to
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 way
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 t
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,
--
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
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 bu
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 get
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
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
f
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.
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,
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
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 ha
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 the
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
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 Fireb
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 becau
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
Lukas Kahwe Smith wrote:
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
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
de
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 Firebi
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 Firebi
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 conferenc
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.
Th
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
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
> 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
>> 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 fo
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 will be
bundled or not. It would nice if
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
>
> 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
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
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 abo
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
--enable-pecl=/path/t
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 th
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
Without the pear or pecl commandyou can also simply download the pecl
extension package and do the following:
tar -x
phpize
./c
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 p
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 ar
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
is (P) [mailto:[EMAIL 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 ph
> -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
>
> 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
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 talk
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
mailto:[EMAIL PROTECTED]
Sent: 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 o
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
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
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
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
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 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
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 wron
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 P
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 instal
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 inc
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 be
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
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 fut
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 problem.
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 wh
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 mean
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 bec
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, we
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 stream
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 releas
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] http://www.zend.co
So you would like to drop PEAR?
Where you get these ideas I wonder? I want to use universally used formats.
We are not speaking of a policy here. We are not Java wherenothing else then
I think we are. Endorsing phar as runtime format is endorsing policy, as
I see it.
whatever *AR's work.
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 sec
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
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 sho
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 i
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. Prov
1 - 100 of 167 matches
Mail list logo
