Hi all,
I've already canvassed Ilia and Stas - can anyone else think of anything
I've missed/mis-explained here?
Thanks guys/guyess,
- Steph
UPGRADE NOTES - PHP 5.1
1. Changes in reference handling
a. Overview
b. Code that worked under PHP 4.3, but now fails
c. Code that was valid u
the info that you can
write SQLite 2 code for PDO via DSN = sqlite2. I've no idea why anyone
would want to do that, but it's there...
- Original Message -
From: "Wez Furlong" <[EMAIL PROTECTED]>
To: "Steph Fox" <[EMAIL PROTECTED]>
Cc: "inter
>I'd also suggest that all the PDO extensions be built shared to
>facilitate easier upgrades via PECL as new features are developed
>there, but that's just me.
:) no it isn't, PDO's cool.
Thanks for all your help over this.
- Steph
--
PHP Internals - PHP Runtime Development Mailing List
To uns
Hopefully I have the PDO stuff outlined a little better now.
I know Dmitry and Derick have both committed changes today that should go in
here, and await the outcome of the zend_parse_parameters() discussion with
interest.
Anything else missing?
- Steph
UPGRADE NOTES - PHP 5.1
1. Changes in ref
Thanks Wez, consider it done - and sorry I took up so much of your time
today, I know you're busy.
- Original Message -
From: "Wez Furlong" <[EMAIL PROTECTED]>
To: "Steph Fox" <[EMAIL PROTECTED]>
Cc: "internals"
Sent: Tuesday, November
Thanks Lukas, looking.
- Original Message -
From: "Lukas Smith" <[EMAIL PROTECTED]>
To:
Sent: Tuesday, November 15, 2005 8:46 PM
Subject: [PHP-DEV] Re: Upgrade notes for PHP 5.1 - 3rd draft
> Steph Fox wrote:
>
> > Anything else missing?
>
> I have
Thanks Derick, consider it done.
- Original Message -
From: "Derick Rethans" <[EMAIL PROTECTED]>
To: "Steph Fox" <[EMAIL PROTECTED]>
Cc: "internals"
Sent: Wednesday, November 16, 2005 7:22 AM
Subject: Re: [PHP-DEV] Upgrade notes for PHP 5.1 - 3r
I know it's 50-50 at least one of these items will change before my mail
reaches the list, but here's version 4 for your perusal.
Note: I have type hints for arrays down as being 'still under discussion' -
this isn't actually ready to go.
I've thrown out new features such as the Zend VM execution
Jani, I'm going to slip that into the upgrade notes - I wasn't aware you
could do this 'til now either!
- Original Message -
From: "Jani Taskinen" <[EMAIL PROTECTED]>
To: "Andi Gutmans" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>;
Sent: Friday, November 18, 2005 8:06 AM
Subject: Re: [PHP
Hi Matthias,
I'm talking about skipping new features, not about skipping changes that
will affect existing code.
'That curly brace thing' is already in. Checking abstraction in interfaces,
thanks for your input!
- Steph
- Original Message -
From: "Matthias Pigulla" <[EMAIL PROTECTED]>
Guys and guyess,
Hopefully this is the final version of the upgrade notes. Please could you
scroll through it (particularly if you've been involved in developing any of
the affected areas) and get back to me ASAP if you find any misconceptions,
missing information about changes that will affect l
Current release: 1.0.0 (stable) was released on 2005-03-15
That means it's not up to date enough to help with 5.0 -> 5.1 upgrades...
- Original Message -
From: "Eric Coleman" <[EMAIL PROTECTED]>
To: "Andi Gutmans" <[EMAIL PROTECTED]>
Cc: "Jani Taskinen" <[EMAIL PROTECTED]>; <[EMAIL PROT
extra note by it?)
- Steph
- Original Message -
From: "Wez Furlong" <[EMAIL PROTECTED]>
To: "Steph Fox" <[EMAIL PROTECTED]>
Cc: "internals"
Sent: Saturday, November 19, 2005 5:14 PM
Subject: Re: [PHP-DEV] Upgrade notes for PHP 5.1 - final draft
text under
discussion.
Andi was thinking of an auto-conversion tool for PHP 6 (something like
autoconf's autoupdate) - this isn't something that's likely to be achievable
in userspace code.
- Steph
- Original Message -
From: "Eric Coleman" <[EMAIL PROTECTED]&g
It is. Try PAT.
- Original Message -
From: "Jani Taskinen" <[EMAIL PROTECTED]>
To: "Markus Fischer" <[EMAIL PROTECTED]>
Cc: "John Coggeshall" <[EMAIL PROTECTED]>; "Andi Gutmans" <[EMAIL PROTECTED]>;
; <[EMAIL PROTECTED]>
Sent: Wednesday, December 14, 2005 2:11 PM
Subject: Re: [PHP-DE
Did somebody revoke PEAR Group's account-giving karma?
On Wed, 14 Dec 2005 07:30:27 -0800
[EMAIL PROTECTED] ("Craig Constantine") wrote:
As per Pierre and Arnaud, I'm requesting a CVS account. I will be the
new maintainer of Pear package System_Command. Copies of Pierre's or
Arnaud's email mess
To be honest I would like to have you as RM. You have the background
to take the right decisions and other can help when it comes to low
level technical or security issues.
From a management, feedbacks or compromises ready point of view, you
have already proven your abilities.
Pierre definitely
Hi Lukas,
I do not see why we need this delayed hand over. RMs managed to take over
during the process in the past and today we even have a check list for
this purpose. The main challenge is managing the politics on this list and
we all know how this works. Of course there are also technical i
Since I already stated that I am only interested in the part of the job
that does not require php-src karma, I am probably not a good fit. I
would definitely change the job scope. As such I think Johannes is then
still the best option for this delayed take over because he can take the
full job
Yes, but we aren't talking about going to the next one up. We're
talking about going to one that's a bit too recent and won't work out
of the box for everybody.
On Nov 13, 2007 5:46 PM, Stanislav Malyshev <[EMAIL PROTECTED]> wrote:
> > Why is everyone in such a rush to get away from the lowest com
Truth now Stas, did you read to the end of my mail? I wasn't
suggesting we *never* upgrade. I was suggesting there are better ways
to do it than alienating our user base.
On Nov 13, 2007 5:55 PM, Stanislav Malyshev <[EMAIL PROTECTED]> wrote:
> > Yes, but we aren't talking about going to the next o
> Re-read it, but I'm not sure I see what you are proposing besides not
> doing it. We want to use better compiler to build PHP on Windows - what
> should we do?
I obviously don't have the knack of proposing then :)
What I was trying to say was that it would be a good idea to make
third party lib
On 11/13/07, Stanislav Malyshev <[EMAIL PROTECTED]> wrote:
> > What I was trying to say was that it would be a good idea to make
> > third party lib collections for the various VC versions and make them
> > available for building. It would give us a way to test both the build
>
> Well, that would b
I think what is highly likely to happen over the next two years that
will change the situation is that XP usage will drop dramatically.
Like, people would move to Vista en masse? Don't see it happening in next
two years. Why do it?
It will happen at some point because if you try to buy a new
Hi Elizabeth,
Bear in mind that the first part of this discussion (at the start of
October) passed me by completely, so I'm arguing in both at present.
I wasn't suggesting replacing the current VC6 builds, I was suggesting
making 2005 builds available for those who want to test. Since linkin
Rob,
Elizabeth is being paid by Microsoft to get a PHP distro with the 2005 CRT
onto the official downloads page. I don't think it's beneficial to PHP or
its users to take that approach. We have a QA site, and I think if there are
to be test distributions then that's the place for them. I've a
Hi Richard,
It would be useful to see some stats about actual performance
increases from using the new runtime. If it is minimal, then
cost/benifit isn't great and we are probably going to have to
"make-do" for a while on VC6.
Agree.
But, if MSVC2005EE (Microsoft Visual C++ 2005 Express Edit
Hi Elizabeth,
Oh for goodness sakes Steph, they did ask what it would take to make it
happen at the Dev summit, and the guys jokingly said "a free Xbox" but for
your information I haven't taken a thing from them nor will I - talk about
starting rumors,.
I was going on what you told me in irc
Sorry Elizabeth and Microsoft,
I just went through the irc logs and no, you didn't exactly say you were
being paid. It was simply the (wrong) impression I came away with.
Mea culpa.
- Steph
- Original Message -
From: "Steph Fox" <[EMAIL PROTECTED]>
To: ; "
Yay, I think we're coming to an agreement :)
- Original Message -
From: "Elizabeth Smith" <[EMAIL PROTECTED]>
To:
Sent: Wednesday, November 14, 2007 2:41 PM
Subject: Re: [PHP-DEV] Providing Visual Studio 2005 builds (again)
Steph Fox wrote:
Hi Elizabeth,
Where did anyone say she should have no space?
Ok, support then. Rather than a no we are not, but an OK, yes, good
idea, let's do it and see what the problems are.
I thought I'd done that two days ago...?
/me checks timestamp on mail.
Some of us doze users submit patches which are overlooked
Thanks Mario, that's useful info.
Mello Marcus
any useful numbers?
ENV: W2k3 Standart Edition (Kernel Version 5.2.3790 SP2) Apache 2.2.6 VS8
SP1
Hardware: AMD Athlon(tm) 64 Processor 3200+ (2.2 GHz) 512 MB DDR 1 RAM
run with the php.exe (cli)
--
But we probably wouldn't distribute them from php.net.
That was my main concern, Stas. (That, and the idea of a double offering on
the downloads/snaps pages.)
- Steph
--
Stanislav Malyshev, Zend Software Architect
[EMAIL PROTECTED] http://www.zend.com/
(408)253-8829 MSN: [EMAIL PROTECTE
Richard, hi...
I suppose, no matter how many times the message "This version of PHP
requires this pack of files from Microsoft" with a link to the files
you are still going to get users complaining that their PHP doesn't
work.
This is exactly why we just had this whole discussion. Making sure
Hi all,
This is just a suggestion at this stage, I'd like to test the waters with it
before writing a patch.
Apropos the VS discussion, I was thinking about suffixing the PHP version
number in these 'beta builds', to help with the ensuing QA logistics, and
then it struck me that it might be
Hi Stefan,
I just wanted to ask if there was ever a decision made that said tainted
mode will go into PHP mainstream.
No decision as such - I believe Wietse is doing his best to find out exactly
how viable it is, no?
it seems some people want the fast implementation of Wietse in the core
w
What I really don't understand is why so many people are so quick to jump
into "us vs. them" attitude. Is there a war or what? Isn't there enough
conflict so that one must look so hard to create a new one?
Or maybe it is worth considering that having good database support is good
for *both* PHP
So, what, exactly, is the fuss all about?
Richard, the problem with a CLA (moral quibbles apart) is it prevents any of
the core contributors doing anything with the code. As in:
+# PDO Specs. CLA required to commit
+unavail||pdo-specs
That's what 'unavail' means.
Surely all this "us/them",
We do have peer-review after all.
Not on CLA'd code we don't.
Steph the CLA seems to just relate to the docbook xml specifications
for PDO.
Someone told you that, or have you developed psychic powers?
The same applies, regardless. If a commit to that module breaks the PHP
manual build, you
Stas - we don't even know what they're planning to put into CVS. Just
And waiting couple of days for the explanation is of course not an option.
But opening up a module in the php.net CVS repository that php.net
contributors are excluded from without discussion is?
- Steph
--
PHP Interna
Hi Johannes,
On a side-note: It's not only about peer review - without signing the
CLA one might still read the code and send reports to the maintainers.
I was responding to Richard when I wrote that. He was operating under the
assumption that php.net have control over what goes into a CLA'd
such switches only add more complexity, confusion for users and
addtional trouble to distributors.
FWIW, amen to that.
- Steph
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Hi all,
It has nothing to do with "little peon".
Be fair Stas, Brian already apologized for the way that post came across.
You argue that we need some language-level change to improve performance
(and it is the only reason to add it). It is suspected that this language
change has very high
Couldn't there be some way to mark a 'bundle' file and use that mark to
discriminate between where multiple namespaces are or are not allowed in
zend_compile.c? That would eliminate the potential for abuse, no?
Not really. People would start "bundling" files left and right, just
because somebo
The need to pack a program all into a single source file for performance
reasons would seem to indicate that the way PHP compiles/interprets could
be improved. Wouldn't it be better to improve this area than add language
features to deal with the issue?
How do you improve the performance of a
That depends on how many 'bundle files' are allowed. I hate to say it, but
if this were an INI directive rather than a keyword it would be possible
to limit bundling to a single file, or to any given number.
Take that back, it wouldn't work... I was thinking of single applications
rather than
I strongly suspect performance difference in bundles does not follow
from syscalls. On include() PHP does a lot more than just issue a couple
of syscalls.
So Michael's right and it needs some proper investigation.
- Steph
--
Stanislav Malyshev, Zend Software Architect
[EMAIL PROTECTED] htt
I'm a firm believer that it's better to throw more CPU power at a
performance problem than to make code less maintainable. Just buy a faster
server.
That hardly applies to library developers, though. They don't have control
over their users' CPU power...
- Steph
--
PHP Internals - PHP Run
Hi D,
extension (DateTime, DateTimeZone). However introducing the new class
DateTimeSpan might break people's code that do things like:
Typo? I guess you meant 'DateTimeSpan' to be in there somewhere...
This is I think the biggest problem with the implementation, that new
internal clas
However, in the global scope (no namespace) it would fail. This is a
bug that is easily fixed. use should allow re-aliasing of global
classes, and I could provide a very easy fix.
This is not a bug - since there you work with test::xmlreader, which of
course you can define. But in global spac
I can't. I can only hope they would do it right, I can't force them to do
it right :)
I guess what I'm really asking is, 'is there any point in allowing
import/use to be used in the global space?' I'm tired and etc, but I just
can't visualize where it would be useful.
Maybe one of the OO gan
I guess what I'm really asking is, 'is there any point in allowing
import/use to be used in the global space?' I'm tired and etc, but I just
can't visualize where it would be useful.
And now I've finished reading old South Park episodes...
OK, it's sinking in now. Because global import/use is
Hi Larry,
namespace me;
use Whatever as LegacyWhatever;
class Whatever{}
I'd missed that in the ebb and flow. I guess the bug in my copy was fixed
then, good. It still doesn't make sense to have global import though...?
(I'm probably going to kick myself sooo hard for this in the morning...
Hi Nate,
Only if you insist on *not* using the namespaces to solve collision
problems. For the 1001th time - you can not expect to put all names into
global space and have the language by some magic to sort it out and go
both ways. One name can mean only one thing, namespaces or not.
Namespaces
Hi Matthias,
Let alone __php__. If you just put all of your code into namespace Mylib,
you're not safe because according to the name resolution rules, internal
classes come after imported ones but before trying to find classes in the
current namespace.
I'd missed that :-( and from what I gathe
Hi Greg,
1) recommend all global non-namespaced code that wishes to import
namespaced code via "use Namespace::Classname" add a "namespace
__php__;" at the top of the file, and that the __php__ namespace be
reserved for use by end-user applications.
That answers my main concern, but I'd make i
hment stripper...
- Steph
- Original Message -
From: "Steph Fox" <[EMAIL PROTECTED]>
To: "Raghubansh Kumar" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Sunday, December 09, 2007 3:31 PM
Subject: Re: [PHP-CVS] cvs: php-src(PHP_5_3) /ext/st
Hi Stas,
I just spent most of two evenings looking at this one - so much for an easy
fix. Read on...
the code is
if (ZEND_NUM_ARGS() >= 3 && Z_TYPE_P(length_param) != IS_NULL) {
length = Z_LVAL_P(length_param);
} else {
length = num_in;
}
and afaik should be
I think in fact it should just
all of a sudden the fourth parameter, preserve_keys, doesn't throw
zend_parse_parameter() warnings any more, regardless of the type you give
it. (You tell me...)
... because I re-used the same variable in the test script after it had been
converted to long.
OK, so that mystery's solved. But
I think in fact it should just parse it as long and not as zval - what
would be any reason to parse it as zval and then convert to long anyway?
The problem is that this function's always been wrong, so it doesn't
really care what you throw at it - it just does a silent conversion to
long if yo
Right, that's what "l" parameter spec is doing, doesn't it? Why convert
it manually?
Because it doesn't know the difference between NULL and 0 if it's a long.
And why this difference is important in array_slice()? I don't see
anything in manual that says anything about NULLs. Could you explai
If Z_TYPE_P(length_param) is 0, it's not NULL because it has something in
it.
Bleh... but you know what I mean :)
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
The manual kind of skirts around it: "If length is given and is
positive, then the sequence will have that many elements in it. If length
is given and is negative then the sequence will stop that many elements
from the end of the array. If it is omitted, then the sequence will have
everything
if (ZEND_NUM_ARGS() >= 3 && Z_TYPE_P(length_param) != IS_NULL) {
+convert_to_long(length_param);
Isn't convert_to_long non-separating one? I think the variable supposed to
be separated before conversion, so convert_to_long_ex (and zval **) would
be in place.
Hm you're probably ri
It builds without complaint and works as expected - what am I missing?
IS_NULL is variable type. length is variable value.
So it's better to check for == 0? What's the difference? Is an IS_NULL check
slower?
- Steph
--
Stanislav Malyshev, Zend Software Architect
[EMAIL PROTECTED] http:/
So it's better to check for == 0? What's the difference? Is an IS_NULL
check slower?
No, it's not slower, but it makes no sense to compare variable value to a
type constant. Even if coincidentally constant value is the same one you
need to compare to.
OK, so if I clean up those patches and r
Both are now on http://bugs.php.net/bug.php?id=43541. Ignore the first of
the three, it breaks when the length param isn't passed.
I'm going offline before I say anything else stupid :)
- Steph
- Original Message -
From: "Steph Fox" <[EMAIL PROTECTED]>
C'mon guys, you're just not trying. Some of us stand to lose bets here...
On Dec 13, 2007 10:19 AM, Sean Coates <[EMAIL PROTECTED]> wrote:
>2.) Probably a better idea, just click that DELETE button on any
> emails you don't feel like reading or responding to. I find that, in
> a case stud
Hi all,
Having spent a few hours tussling with the load-order bogey, I found what I
think is a bit of a gap in the win32 build process.
There are no configure warnings at all when there's a missing extension
dependency... only a bailout if you try to build a dependency as shared for
a static
Could someone please commit this? I just hit the same issue again.
Thanks,
- Steph
- Original Message -
From: "Steph Fox" <[EMAIL PROTECTED]>
To: "internals"
Sent: Friday, December 14, 2007 9:40 AM
Subject: [PHP-DEV] Extension dependencies in win32 build
-1
(OK so I'm late...)
- Original Message -
From: "Johannes Schlüter" <[EMAIL PROTECTED]>
To: "PHP Internals List"
Sent: Friday, January 11, 2008 3:47 PM
Subject: [PHP-DEV] SUMMARY: Array syntax
Hi,
I did a short count of the "votes" about the Array Syntax shortcut on
the list. I
It is better to have input from people with a wide range of experience
levels, it results in a fairer vote that actually represents the
population, rather than putting PHP under the control of a select few.
No, it is not. This has nothing to do with "fairness", as we are not
enacting laws, levy
This broke the TSRM build, trivial patch attached.
- Steph
- Original Message -
From: "Derick Rethans" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Sunday, January 13, 2008 3:16 PM
Subject: [PHP-CVS] cvs: php-src(PHP_5_3) / NEWS /ext/date php_date.c
php_date.
Hi Andi,
As we have discussed in the past the migration path may be extremely hard
moving from PHP 5 to PHP 6. Therefore the community has to come together
and really invest in the migration path more than we have in the past
(like we did from version 2 to 3). This means that during the develo
I think the idea was "no php.ini switch, but the question what "foo"
should produce - IS_UNICODE or IS_STRING is still open for consideration".
"foo" alone should produce IS_STRING. The real question IMHO is how far back
do you backport tolerance for a unicode cast.
- Steph
--
PHP Internal
Blimey. I agree with Rasmus. That's twice now!
I think PHP 6 should be an interim period with support for both scenarios,
but with the default being bog-standard as-we-know-it IS_STRING and anything
IS_UNICODE needing to be marked.
Perhaps PHP 7 can drop the IS_STRING stuff and have it all IS
Hey Andrei,
You can't just say that without giving full details.
We've seen all your 'this will cope with Russian, Hebrew, Greek, Japanese
and Icelandic' demos. We haven't seen what happens to English, French or
German - ever.
So what happens if I pass in "Hello World", in English, and it's
Right, and that's something that does NOT appear in any notes anywhere.
- Original Message -
From: "Andrei Zmievski" <[EMAIL PROTECTED]>
To: "Steph Fox" <[EMAIL PROTECTED]>
Cc: "Rasmus Lerdorf" <[EMAIL PROTECTED]>; "Chris
icode-only and a
MASSIVE push for user education way before it even becomes available, _or_
you hold it all back and force 'non-standard' (sorry rest of the world)
languages to use markers.
- Steph
- Original Message -
From: "Andrei Zmievski" <[EMAIL PROTECT
Andrei Zmievski" <[EMAIL PROTECTED]>
To: "Steph Fox" <[EMAIL PROTECTED]>
Cc: "Rasmus Lerdorf" <[EMAIL PROTECTED]>; "Chris Stockton"
<[EMAIL PROTECTED]>; "php-dev"
Sent: Thursday, January 24, 2008 1:33 AM
Subject: Re: [PHP-DEV
The question here isn't so much where we are going, but exactly how we
will get there and how long that might take.
Absolutely.
- Steph (who has taken several queries over this today thank you)
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/un
Hi Marcus,
so you mean we do not have to confuse our uses by solution 2a becasue we
only have the minimum subset of zip in phar that ohar actually needs?
Yep. But Greg can explain better.
- Steph
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.
I think it is a good thing to require ext/phar even for the read
operations. It certainly allows a shit load of optimization and tricks
that will never be possible otherwise. But Greg or Marcus will give us
a better answer :)
? It's a < 7kb add-in stub to make it open-access.
- Steph
--
PHP In
However I find your actual positions confusing and each mails bring
opposing arguments about the shared work between other archives
extension and phar. Can you clarify your view please?
Essential: nothing
Optional: bz2, spl, zlib
Completely different and nothing whatever to do with phar: ext/zip
phar's zip support. The tests simply need to be modified to create the
zips using pecl/phar and copy the filename to one phar doesn't already
know about, and the failures will go away.
I thought you wanted 'pure' zips for the tests - that told me!
So how do I create a zip with ext/phar then, o
Hi Marcus,
1. include phar in core
2.a. add ext/zip compatible functions and replace ext/zip
2.b. change ext/zip to use zip lib of pahr and add stream support
3. drop ability to disable spl
I have no preference between 2a or 2b. Though technically I guess that 2a
is probably much faster to
Hi Pierre,
Exactly and I'm rather surprised to see this post given the recent
efforts to export the Zip symbols to allow any extension to share the
zip features.
I think until the zip features were shared the library's limitations hadn't
been too obvious.
Most of the discussions have been
The win32 snapshot builds have been done since Jan 20/21, so maybe
there is more than 1 library to fix
No, the errors that caused the original failure were fixed within a day or
two. Also the snaps libxml is up to date, it's just the zip.zip one that
isn't. Machine probably needs a kick.
Rob
Be fair, this is an open list. Anyone can join it, and it keeps the noise
levels down on [EMAIL PROTECTED] Please? ;)
http://news.php.net/php.pdo
- Steph
- Original Message -
From: "Marcus Boerger" <[EMAIL PROTECTED]>
To: "Wez Furlong" <[EMAIL PROTEC
If we're going the PECL refurbishment route, can we have some way of
marking non-standard (as in CLA'd or differently-licensed) extensions to
make contributors' lives easier and future discussions of this nature
moot? Possibly even a separate CVS module that hooks into the PECL
infrastructure?
all we need is to extend the PECL database with a license type field and
a
CLA flag. Nothing else is required at that end. But we should still move
as
much from php-src/ext to pecl as we can.
Hm but then when you checked out you'd have CLA'd stuff as well as normal
PECL stuff, as now. Don't
Hi all,
Just so's Marcus and I don't have to keep cross-posting here... The problems
of PECL vs core extensions are many, and exist with or without the PDO/CLA
debate.
Marcus (among others) says he wants to get as many extensions as possible
out of the core and into PECL. I agree fully with
Personally I do a full pecl checkout alongside my php-src checkout, every
time. The problems with that tend to come out during the build.
- Original Message -
From: "Marcus Boerger" <[EMAIL PROTECTED]>
To: "Steph Fox" <[EMAIL PROTECTED]>
Cc: <[E
Hi Marcus,
what I want is php-src as minimum you can depend on. And php-default as
release managers playground. The RM can then say what he thinks is mature
enough to make it into a release.
What _I_ want is a PHP core that is really core. By that I mean things like:
date, spl, pcre, zlib, f
Hi Marcus,
Anyway my idea is to start everything in PECL and
to to move everything out that can be moved out. And that includes all
MySQL
extensions as well as SQLite. Only this way people will use the PELC
infrastructure. Otherwise we would just reduce functionality of PHP. And
btw
nearly a
Hi Lukas,
Correct me if I am wrong or if I am missing something, but currently
things work more or less like this. I think its important that we get
an understanding of how things are right now and what the issues are,
before we go off and solve them (maybe with the above mentioned
approa
I see no point to discuss solutions for some unknown entities willing
to contribute when they do not consider to introduce themselves. When
they don't explain clearly why we should do the move and what will be
the actual gains for us (read: for "us" not for them). Until a step in
this/our directi
Hi Lukas,
I am not sure if I misunderstood some other persons proposal, but at
least my proposal was that the final thing we ship as version xyz of PHP
would include a set of PECL extensions along with core that we deem as
necessary for the bulk of our users solving the web problem.
That's
Moin Lukas,
Now, PECL has a couple of CLA'd modules already. I don't like them being
there, and you have stated your own opinion loud and clear. I think we
should be looking for some way to separate out CLA'd PECL modules to
elsewhere but leave the PECL structure in place for those modules
Ah sorry - I'm not good with multi-tasking, mixed up two ongoing
conversations here.
Well thanks to a separate PEAR channel, we have all the infrastructure
easily setup to have a different place for users to pick up the code. Or
are you more concerned about the CVS, than the distribution of t
1 - 100 of 728 matches
Mail list logo
