On Tue, 24 Jun 2003, Chris wrote:
> Since there's been a lot of talk about disabling mysql by default (and
> having another option available), the PostgreSQL people are pretty excited
> about this and are keen to see what can be done about getting postgres
> enabled by default instead.
>
> Wha
>
> Since there's been a lot of talk about disabling mysql by
> default (and
> having another option available), the PostgreSQL people are
> pretty excited
> about this and are keen to see what can be done about getting
> postgres
> enabled by default instead.
>
I certainly don't speak fo
All,
Since there's been a lot of talk about disabling mysql by default (and
having another option available), the PostgreSQL people are pretty excited
about this and are keen to see what can be done about getting postgres
enabled by default instead.
What do people think about this?
How can we
And so on.
Once you guys realize how that php4 can't be in the same tree as php5,
then you will begin to realize what it was that I was trying to do.
> -Original Message-
> From: admin [mailto:admin] On Behalf Of Sebastian Bergmann
> Sent: Tuesday, June 24, 2003 6:20 AM
> To: [EMAIL PROT
On Tue, Jun 24, 2003 at 07:28:40AM +0200, Andi Gutmans wrote :
> However, I am not convinced that having to explicitly checkout the PHP_5
> branch is such a good idea. I thought the idea was to have HEAD be the
> current development version and branch if off when necessary. I would
> prefer thi
... because ext/com is missing.
--
Sebastian Bergmann
http://sebastian-bergmann.de/ http://phpOpenTracker.de/
http://www.professionelle-softwareentwicklung-mit-php5.de/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.
Sascha Schumann wrote:
> The great unification has commenced.
Thanks for your effort!
--
Sebastian Bergmann
http://sebastian-bergmann.de/ http://phpOpenTracker.de/
http://www.professionelle-softwareentwicklung-mit-php5.de/
--
PHP Internals - PHP Runtime Developm
Rob Richards wrote:
> Also, it looks like at least domxml and xslt were dropped from the
> php_4 branches.
There is, however, ext/sqlite in PHP_4_3 :)
--
Sebastian Bergmann
http://sebastian-bergmann.de/ http://phpOpenTracker.de/
http://www.professionelle-softwaree
At 05:25 AM 6/24/2003 +0200, Sascha Schumann wrote:
So, we should get comfortable with the idea of having a Zend
_and_ a ZendEngine2 dir at the same time(*).
Thoughts?
I think in the long run it tends to be a bit ugly, but I don't see any
alternative right now, because merging the CVS
Right now, CVS users have to know which engine they need for
a particular PHP version. The reason for this? The
php4/php5 CVS aliases have been removed, because they
conveyed a false impression -- php4 just wouldn't give you
PHP 4, if you did not also specify the correct branc
On June 23, 2003 05:37 pm, Sascha Schumann wrote:
A clean checkout using "cvs co -r PHP_4_3 php-src-ze1" does not appear to
fetch the TSRM directory.
Ilia
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Test please ignore
--
Jason Greene <[EMAIL PROTECTED]
<[EMAIL PROTECTED]>
He who laughs last hasn't been told the terrible truth.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
"Sascha Schumann" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> I haven't run into these.. details would certainly simplify
> that decision.
I found that it was not possible to get a diff between two dates with two -D
options in a branch which works fine in HEAD.
Edin
Just a couple of things about the current state of the repository.
A bunch of files in TSRM for PHP_5 need to be reverted to the previous
revision to get them back working with php5. The ones which were synched
with the php4 branch are now missing all the changes/fixes made to them over
the past x
For public scrutiny, here is the action log for today's CVS
modifications.
0. CVS access disabled.
1. /repository/php5 became php-src.
2. /repository/php4 became php4.unused.
3. Locally checked out HEAD module php-src. Created branch PHP_5 from that
using "cvs tag -b PHP_5".
Repeate
> I think that PHP 5 (or whatever the latest major version of PHP in the
> works is at a given moment) should be in HEAD, and not in a branch. CVS
> branches are really useful for maintaining old versions, but I think HEAD
> is the most suitable branch for ongoing development(*), and we're not
> r
> Is it possible to perhaps make PHP_5 synonymous with HEAD while this is
> the main dev branch? Perhaps through an alias? The move the alias when
> the main dev branch becomes something else? It does seem a bit weird to
> not have main development on HEAD.
The lack of consistency regarding
At 00:37 24/06/2003, Sascha Schumann wrote:
The great unification has commenced.
There is now a single module php-src which contains all PHP 4
and PHP 5 branches.
BRANCH INFORMATION
Please make yourself familiar with the "cvs checkout -r
BRANCH" notation. It will be necessary
> PHP 5: cvs co -r PHP_5 php-src-ze2
Is it possible to perhaps make PHP_5 synonymous with HEAD while this is
the main dev branch? Perhaps through an alias? The move the alias when
the main dev branch becomes something else? It does seem a bit weird to
not have main development on HEA
Hi out there,
Wondering what should go into the docs about this:
It seems that array appending has changed wrt negative indices. I had
just documented the new behaviour but now I'm not entirely sure whether
I've just documented an unintentional change. Is this new behaviour what
is desired (i.e.
On Mon, Jun 23, 2003 at 11:37:56PM +0200, Sascha Schumann wrote:
> The great unification has commenced.
>
> There is now a single module php-src which contains all PHP 4
> and PHP 5 branches.
>
> BRANCH INFORMATION
>
> Please make yourself familiar with the "cvs checkout -r
>
James Cox wrote:
There is a cumulative patch available here:
http://cvs.php.net/~imajes/big.patch.gz which incorporates all the
changes from PHP_4_3 to HEAD, which I merged. Simply by reversing the
patch and applying it backwards to your code should be sufficient to
remove the changes occurred when
The great unification has commenced.
There is now a single module php-src which contains all PHP 4
and PHP 5 branches.
BRANCH INFORMATION
Please make yourself familiar with the "cvs checkout -r
BRANCH" notation. It will be necessary from now on for a
checkout.
Some
> Just to clarify. The proposal is:
Right. Nice diagram :)
> If so, I am all for it. A version-agnostic php-src module with
> appropriate branches and tags would be very nice. This tree looks more
> complicated than it actually is. Obviously a number of the branches are
> inactive and do
At 19:49 23/06/2003, Derick Rethans wrote:
I think I rather have people bitching about that than bitch about the
wrongly set setting. The latter creates bugreports, the first only
stupid questions.
I don't consider people bumping into problems upgrading asking questions as
being stupid... Most pe
On Mon, 23 Jun 2003, Sascha Schumann wrote:
> Here is a plan.
>
> - rename /repository/php5 to /repository/php-src
> - copy PHP_4_3 tags to PHP_4 branch (i.e. reset the PHP 4
> head branch to the current 4.3 code)
> - workaround Zend/ZendEngine2 issue (they should be in the
>
At 08:04 PM 6/23/2003 +0200, Sascha Schumann wrote:
> A bunch of things are broken. Files are missing in php4 head and the
> wrong versions of files are also in there. I think we need to roll this
> change back as soon as possible and take another shot at this in a much
> more organized manner.
On Mon, 23 Jun 2003, Rasmus Lerdorf wrote:
> I agree with the single module for evolutionary code approach.
>
> Should we disable CVS for a while to stop commits until this gets cleaned
> up? I think this problem needs the special Sascha touch.
sounds like a good plan to me
Derick
--
"Interp
On Mon, 23 Jun 2003, Sascha Schumann wrote:
> > A bunch of things are broken. Files are missing in php4 head and the
> > wrong versions of files are also in there. I think we need to roll this
> > change back as soon as possible and take another shot at this in a much
> > more organized manner.
>
Sounds good. If you have time do it in that way.
+1
At 20:04 23.06.2003 +0200, Sascha Schumann wrote:
> A bunch of things are broken. Files are missing in php4 head and the
> wrong versions of files are also in there. I think we need to roll this
> change back as soon as possible and take another
Hello George,
Monday, June 23, 2003, 8:11:35 PM, you wrote:
GS> On Monday, June 23, 2003, at 02:04 PM, Marcus BXrger wrote:
>> 1) SPL doesn't work when not being a built-in extension.
GS> Works fine for me. I tested all the interfaces except for
GS> spl_array_write_ex.
You could simply run
On Mon, 2003-06-23 at 14:04, Sascha Schumann wrote:
> > A bunch of things are broken. Files are missing in php4 head and the
> > wrong versions of files are also in there. I think we need to roll this
> > change back as soon as possible and take another shot at this in a much
> > more organized m
At 08:33 PM 6/23/2003 +0200, Marcus Börger wrote:
Hello Andi,
Monday, June 23, 2003, 8:14:30 PM, you wrote:
AG> At 09:14 AM 6/23/2003 +0100, Wez Furlong wrote:
>>[This is not a dig!]
>>
>>The same could be said about the engine code itself ;)
AG> :)
AG> We do need some sort of email which explai
Hello Stanislav,
Monday, June 23, 2003, 9:34:41 AM, you wrote:
SB>>> > Anybody cares to explain what SPL is?
SB>>>
SB>>> http://cvs.php.net/cvs.php/spl
>>From the initial look at the code, it seems it contains a large parts of
SM> duplicated engine code. Which means, unless I am missing some
Hello Andi,
Monday, June 23, 2003, 8:14:30 PM, you wrote:
AG> At 09:14 AM 6/23/2003 +0100, Wez Furlong wrote:
>>[This is not a dig!]
>>
>>The same could be said about the engine code itself ;)
AG> :)
AG> We do need some sort of email which explains the API and the semantics. For
AG> instance,
On Monday, June 23, 2003, at 02:04 PM, Marcus BXrger wrote:
1) SPL doesn't work when not being a built-in extension.
Works fine for me. I tested all the interfaces except for
spl_array_write_ex.
gs
-- George Schlossnagle
-- Principal Consultant
-- OmniTI Computer Consulting, Inc.
-- +1.410.87
> A bunch of things are broken. Files are missing in php4 head and the
> wrong versions of files are also in there. I think we need to roll this
> change back as soon as possible and take another shot at this in a much
> more organized manner.
Here is a plan.
- rename /repository/php5 t
Hello Sebastian,
Monday, June 23, 2003, 8:50:17 AM, you wrote:
SB> Sterling Hughes wrote:
>> SPL should be integrated into the engine imho. I think its incredibly
>> useful from a purely internals perspective.
SB> Either way I think the functionality should be part of PHP 5 and
SB> enabled
Hello Sterling,
Monday, June 23, 2003, 4:38:42 AM, you wrote:
SH> Hey,
SH> Unless anyone objects I'm going to enable the sqlite extension by
SH> default for PHP5. The extension comes with the bundled sqlite library
SH> which is 1.5mb in total (cd ext/sqlite/libsqlite/src/; du -ch *.c *.h),
SH>
On Mon, Jun 23, 2003 at 10:32:56AM -0700, Rasmus Lerdorf wrote:
> A bunch of things are broken. Files are missing in php4 head and the
> wrong versions of files are also in there. I think we need to roll this
> change back as soon as possible and take another shot at this in a much
> more organi
-1
As always I'm against any enable by default thinking.
Why, oh why, are we making this wonderful configure script
completely useless?
On Sun, 22 Jun 2003, Sterling Hughes wrote:
> Hey,
>
> Unless anyone objects I'm going to enable the sqlite extension by
> default for PHP5. The extension c
>
> At 10:32 AM 6/23/2003 -0700, Rasmus Lerdorf wrote:
> >A bunch of things are broken. Files are missing in php4
> head and the
> >wrong versions of files are also in there. I think we need to roll
> >this change back as soon as possible and take another shot
> at this in a
> >much more or
At 10:32 23.06.2003 -0700, you wrote:
On Mon, 23 Jun 2003, Andi Gutmans wrote:
> At 05:43 PM 6/23/2003 +0200, Sascha Schumann wrote:
> > Can someone explain why James just made it impossible to
> > properly work with source code which resides in PHP 4 and 5?
> >
> > - diffing is imposs
At 10:32 AM 6/23/2003 -0700, Rasmus Lerdorf wrote:
A bunch of things are broken. Files are missing in php4 head and the
wrong versions of files are also in there. I think we need to roll this
change back as soon as possible and take another shot at this in a much
more organized manner.
Maybe it's
On Mon, 23 Jun 2003, James Cox wrote:
> > I am not quite sure how/what broke. However, no matter if
> > what James did was the right or wrong thing to do, I think it should
> have
> > been discussed first (in detail).
> >
>
> The opportunity was made available, many times.
Lack of feedback does
>
> I am not quite sure how/what broke. However, no matter if
> what James did was the right or wrong thing to do, I think it should
have
> been discussed first (in detail).
>
The opportunity was made available, many times.
-- james
--
PHP Internals - PHP Runtime Development Mailing Li
On Mon, 23 Jun 2003, Andi Gutmans wrote:
> At 05:43 PM 6/23/2003 +0200, Sascha Schumann wrote:
> > Can someone explain why James just made it impossible to
> > properly work with source code which resides in PHP 4 and 5?
> >
> > - diffing is impossible
> > - merging is impossible
>
At 07:14 PM 6/23/2003 +0200, Sebastian Bergmann wrote:
Andi Gutmans wrote:
> spl_foreach is ugly as hell.
What about ForeachIterator?
And "Iterator"? :)
Anyway, forget discussing names now. It'd be nice to see a short spec of
what SPL does so that we can discuss it.
Andi
--
PHP Internals - PHP
At 05:43 PM 6/23/2003 +0200, Sascha Schumann wrote:
Can someone explain why James just made it impossible to
properly work with source code which resides in PHP 4 and 5?
- diffing is impossible
- merging is impossible
- history of new commits becomes fragmented
James, why di
Andi Gutmans wrote:
> spl_foreach is ugly as hell.
What about ForeachIterator?
--
Sebastian Bergmann
http://sebastian-bergmann.de/ http://phpOpenTracker.de/
http://www.professionelle-softwareentwicklung-mit-php5.de/
--
PHP Internals - PHP Runtime Development Mai
At 09:14 AM 6/23/2003 +0100, Wez Furlong wrote:
[This is not a dig!]
The same could be said about the engine code itself ;)
:)
We do need some sort of email which explains the API and the semantics. For
instance, I'm pretty sure I won't like the names of the interfaces :)
spl_foreach is ugly as
James, in the past, there was very little interest in a PHP 4
HEAD branch, if you care to recall. Because your rashness
has rendered diff and merge unusable between PHP 4/5, we can
only expect to see even less interest.
Lowering the bar should be the answer to faiding interest
nope, just in cvs. and just as of last night. :) But the footprint of
php5 is actually smaller with regards to sqlite, as the client library
caused more download time.
-Sterling
On Mon, 2003-06-23 at 13:58, Andi Gutmans wrote:
> At 01:12 AM 6/23/2003 -0400, Sterling Hughes wrote:
> >1.5 mb is t
At 01:12 AM 6/23/2003 -0400, Sterling Hughes wrote:
1.5 mb is tiny :)
1.5 mb is just a du -ch *.c *.h, and its a one time download. Then you
cvs upd the rest of the changes as they happen. As a point of
reference, the mbstring extension is 2.9 mb of data, sqlite is in total
1.9 mb of data.
Libm
On Mon, 23 Jun 2003, Zeev Suraski wrote:
> At 18:39 23/06/2003, Rasmus Lerdorf wrote:
> >On Mon, 23 Jun 2003, Zeev Suraski wrote:
> > > Maybe we can go for a compromise - enable it with ZEND_INI_PERDIR and
> > > ZEND_INI_UUSE. That way it will be possible to use it with httpd.conf /
> > > .htacce
Use snapshots:
http://snaps.php.net/
Do not run "buildconf" unless you're 100% sure what you're doing..
--Jani
On Mon, 23 Jun 2003, Antony Dovgal wrote:
>On Mon, 23 Jun 2003 10:09:50 +0200 (CEST)
>Derick Rethans <[EMAIL PROTECTED]> wrote:
>
>> that should be -
>
> There is one fix for all of this, the most appropriate fix,
> which is to properly revert a file to revisions previous to
> the first php5 development, and then bring HEAD into sync
> with the branch [1].
>
The reference here was
http://elib.cs.berkeley.edu/admin/cvs/cvsrevert.html ... S
>
> The problem is that I now have conflicts in my changes
> because CVS was doing its job and merging changes into my
> local code. In addition, some of my changes have been
> clevery merged with 4.3 specific changes. So, I have to go
> and audit my code by hand and check which of the change
> Can someone explain why James just made it impossible to
> properly work with source code which resides in PHP 4 and 5?
>
> - diffing is impossible
> - merging is impossible
> - history of new commits becomes fragmented
>
> James, why did not you discuss this first? All
On Mon, 23 Jun 2003, Allowee wrote:
> can't somebody just put the yesterday backup of the repository in there?
> check the list to patch the files which where not backed up.
>
> all comments are welcome, just don't tell me that there is NO backup.
I made a backup, cause I was expecting this. Thi
On Mon, 2003-06-23 at 03:34, Stanislav Malyshev wrote:
> SB>> > Anybody cares to explain what SPL is?
> SB>>
> SB>> http://cvs.php.net/cvs.php/spl
>
> >From the initial look at the code, it seems it contains a large parts of
> duplicated engine code. Which means, unless I am missing something,
On Monday 23 June 2003 17:43, Sascha Schumann wrote:
> Can someone explain why James just made it impossible to
> properly work with source code which resides in PHP 4 and 5?
>
> - diffing is impossible
> - merging is impossible
> - history of new commits becomes fragmented
>
>
Err, no.
*Hacking the repository is not using revision control properly*.
The problem is that I now have conflicts in my changes because CVS was
doing its job and merging changes into my local code. In addition, some
of my changes have been clevery merged with 4.3 specific changes.
So, I have to
On Mon, 23 Jun 2003, Sascha Schumann wrote:
[snip]
> James, why did not you discuss this first? All opensource BSDs
> have been using _one_ source module since their inception.
> In the case of FreeBSD, that dates back to 1993, so this is
> clearly a proven model.
>
> What do
On Mon, 2003-06-23 at 11:59, Zeev Suraski wrote:
> At 18:39 23/06/2003, Rasmus Lerdorf wrote:
> >On Mon, 23 Jun 2003, Zeev Suraski wrote:
> > > Maybe we can go for a compromise - enable it with ZEND_INI_PERDIR and
> > > ZEND_INI_UUSE. That way it will be possible to use it with httpd.conf /
> > >
Wez Furlong wrote:
> (thought Zeev had checked it in already)
Another commit reverted by you-know-who?
--
Sebastian Bergmann
http://sebastian-bergmann.de/ http://phpOpenTracker.de/
http://www.professionelle-softwareentwicklung-mit-php5.de/
--
PHP Internals - PHP
At 18:39 23/06/2003, Rasmus Lerdorf wrote:
On Mon, 23 Jun 2003, Zeev Suraski wrote:
> Maybe we can go for a compromise - enable it with ZEND_INI_PERDIR and
> ZEND_INI_UUSE. That way it will be possible to use it with httpd.conf /
> .htaccess / ini_set(), but not with php.ini, so people will at lea
On Mon, 2003-06-23 at 03:55, Thies C. Arntzen wrote:
> On Sun, Jun 22, 2003 at 10:38:42PM -0400, Sterling Hughes wrote:
> > Hey,
> >
> > Unless anyone objects I'm going to enable the sqlite extension by
>
> i object strongly. sterling, why have you gotten into the
> enable-all, bundle-all
Can someone explain why James just made it impossible to
properly work with source code which resides in PHP 4 and 5?
- diffing is impossible
- merging is impossible
- history of new commits becomes fragmented
James, why did not you discuss this first? All opensource BSDs
On Mon, 23 Jun 2003, Zeev Suraski wrote:
> Maybe we can go for a compromise - enable it with ZEND_INI_PERDIR and
> ZEND_INI_UUSE. That way it will be possible to use it with httpd.conf /
> .htaccess / ini_set(), but not with php.ini, so people will at least have
> to make a slightly more informed
At 20:59 22/06/2003, Sterling Hughes wrote:
hi,
currently, soley for backwards compatibility purposes we provide the
ze2.implicit_clone option. this option is globally settable, and may be
used by shared hosting providers to make it more likely that old scripts
can run unmodified. this however m
Hi Stas,
It's a one line fix to configure; I'll do that shortly (thought Zeev
had checked it in already).
--Wez.
On Mon, 23 Jun 2003, Stanislav Malyshev wrote:
> When building PHP5 from fresh checkout, if I build in the separate
> directory, I get the following error:
>
> Assembler messages:
>
After all discussions what should we do with our 2 checkouts (PHP5-HEAD and
PHP 4.3.3RC2).
I have checked out php5 and used HEAD. -> Looks good
On my harddisk is also a checkout of php4 with tag PHP4_3 (this seems to be
the same with the STABLE snapshot)
Today I checked also out php4 HEAD and ha
Problem is from TSRM when HEAD was synch'd with the php4 branch. Anything
that was done in HEAD is gone in latest revision. Until this is sorted out,
grabbing the previous revision for the changed files seems to work.
Rob
From: Sebastian Bergmann
>php5\ext\standard\filestat.c(582): warning
On Mon, 23 Jun 2003, Olivier Hill wrote:
> Hi,
>
> What would it take to make PHP OSI Compliant (Certified?)?
That's on the way already.
> It seems it
> would permit PHP to be linked to MySQL libs, or am I wrong?
You are not right (yet).
- Sascha
--
PHP Internals - PHP Runtime De
Hi,
What would it take to make PHP OSI Compliant (Certified?)? It seems it
would permit PHP to be linked to MySQL libs, or am I wrong?
Do we have to hire a bunch of lawyers or is it a simple procedure that
no one want to do?
Oliver
--
PHP Internals - PHP Runtime Development Mailing List
To un
When building PHP5 from fresh checkout, if I build in the separate
directory, I get the following error:
Assembler messages:
FATAL: Can't create main/streams/streams.o: No such file or directory
make: *** [main/streams/streams.lo] Error 1
As soon as I create main/streams/ manually, everything is
On Fri, 20 Jun 2003, Jeraimee Hughes wrote:
> zval *params;
> zval *function_name;
> zval *params_wddx = NULL;
> zval *params_array;
[snipped]
> add_index_zval(params_array, 0, params);
>
> if (FAILURE == call_user_function(CG(function_table), NULL, function_n
>
> The point is that there are now a number of core developers
> who updated their existing php5 checkouts and now have a load
> of crap from 4.3 merged into their php5 development.
>
For what it's worth, the last 5 or so warning emails I have dropped onto
the list making it very clear what th
I think it's a good idea.
Zeev
At 05:38 23/06/2003, Sterling Hughes wrote:
Hey,
Unless anyone objects I'm going to enable the sqlite extension by
default for PHP5. The extension comes with the bundled sqlite library
which is 1.5mb in total (cd ext/sqlite/libsqlite/src/; du -ch *.c *.h),
and is
The point is that there are now a number of core developers who updated
their existing php5 checkouts and now have a load of crap from 4.3
merged into their php5 development.
Yes, its a nice idea to make php4 HEAD work for php4 again, but after a
grace period to allow people to migrate to the "rea
On Mon, 2003-06-23 at 11:35, Derick Rethans wrote:
> Sure, and delete my work from my current checkout right away then? You
> obviously have no clue.
I didn't say that, Derick. You can still get a CVS diff that you can
apply to the php5 tree and keep working.
> > Breakage is neccessary sometime
On Mon, 23 Jun 2003, Per Lundberg wrote:
> On Mon, 2003-06-23 at 11:04, Derick Rethans wrote:
> > Great, thanks for this nice mess, we now ended up with useles PHP 4.3
> > checkouts with PHP 5 development stuff in it.
>
> Yeah, what's the big deal about that? Just get the php5 module from
> CVS
On Sun, 22 Jun 2003, Rasmus Lerdorf wrote:
> On Sun, 22 Jun 2003, Johann Hanne wrote:
> > The point is that with valueretrieval set to 0, the SNMP value is still
> > retrieved with snprint_value()/sprint_value(). I've been really really
> > careful with this...
> >
> > Of course the statement "The
On Mon, 2003-06-23 at 11:04, Derick Rethans wrote:
> Great, thanks for this nice mess, we now ended up with useles PHP 4.3
> checkouts with PHP 5 development stuff in it.
Yeah, what's the big deal about that? Just get the php5 module from
CVS...
Breakage is neccessary sometimes. James: thanks
On Mon, 23 Jun 2003, James Cox wrote:
> The next stage to happen is that I will bring php4 HEAD into sync with
> the 4.x development branch, so expect a big patch.
ARGH! Didn't I ask you NOT to do this... you just created a lot of
trouble for people working with a php5 checkout (co php5)... it n
On Mon, 2003-06-23 at 04:38, Sterling Hughes wrote:
> Unless anyone objects I'm going to enable the sqlite extension by
> default for PHP5. The extension comes with the bundled sqlite library
> which is 1.5mb in total (cd ext/sqlite/libsqlite/src/; du -ch *.c *.h),
> and is a good alternative to u
On Sat, 2003-06-21 at 22:17, Georg Richter wrote:
> Zak is already working on license problems, incompatibility and possible
> solutions. Wouldn't it be better to give him and MySQL AB a little bit more
> time?
That would be a good thing. What I think should be clearly stated is
that it is a *
On Mon, 23 Jun 2003 10:09:50 +0200 (CEST)
Derick Rethans <[EMAIL PROTECTED]> wrote:
> that should be --prefix=/usr (note the / )
Sorry, this was a typo - I've really used "--prefix=/usr" instead of "--prefix=usr".
So, all binaries are in /usr at this moment.
But I don't think this matters, 'cause
WF>> The same could be said about the engine code itself ;)
I see your point, but the rest of the engine does not need to be
integrated with itself, it already is. Also, the parts of the engine that
are exposed to the user are or will be (I hope) documented pretty well,
just as user-exposed part
On Mon, 22 Jun 2003, Sterling Hughes wrote:
> Unless anyone objects I'm going to enable the sqlite extension by
> default for PHP5. The extension comes with the bundled sqlite library
> which is 1.5mb in total (cd ext/sqlite/libsqlite/src/; du -ch *.c *.h),
> and is a good alternative to using My
[This is not a dig!]
The same could be said about the engine code itself ;)
--Wez.
On Mon, 23 Jun 2003, Stanislav Malyshev wrote:
> Ah. Well, then a brief intro into how it is meant to work and what it is
> meant to do would help a lot. I value very much the ability of all authors
> to write se
When I bundled the library, I only included the required files (the
official distro is a bit larger than what we include in ext/sqlite).
--Wez.
On Mon, 23 Jun 2003, Andi Gutmans wrote:
> On one hand I think having 1.5MB in our release tree is quite a lot (can
> anything be removed)? On the other
On Mon, 23 Jun 2003, Antony Dovgal wrote:
> On Mon, 23 Jun 2003 09:17:08 +0200 (CEST)
> Derick Rethans <[EMAIL PROTECTED]> wrote:
>
> > Sounds like something definitely broken on your system then...
> may be =(
> I did just `./configure --prefix=usr; make; make install` in autoconf, automake &
SB>> > Can't it be done without keeping another copy of entire Zend engine?
SB>>
SB>> As Sterling already mentioned, it should be merged into Zend at some
SB>> point in time, preferably before PHP 5 :)
Ah. Well, then a brief intro into how it is meant to work and what it is
meant to do would
On Sun, Jun 22, 2003 at 10:38:42PM -0400, Sterling Hughes wrote:
> Hey,
>
> Unless anyone objects I'm going to enable the sqlite extension by
i object strongly. sterling, why have you gotten into the
enable-all, bundle-all mode lately? what do you gain?
thies
--
PHP Internals - PHP
Stanislav Malyshev wrote:
> Can't it be done without keeping another copy of entire Zend engine?
As Sterling already mentioned, it should be merged into Zend at some
point in time, preferably before PHP 5 :)
--
Sebastian Bergmann
http://sebastian-bergmann.de/ http://phpOp
SB>> > Anybody cares to explain what SPL is?
SB>>
SB>> http://cvs.php.net/cvs.php/spl
>From the initial look at the code, it seems it contains a large parts of
duplicated engine code. Which means, unless I am missing something,
constant maintenance nightmare. Can't it be done without keeping
Stanislav Malyshev wrote:
> Anybody cares to explain what SPL is?
http://cvs.php.net/cvs.php/spl
--
Sebastian Bergmann
http://sebastian-bergmann.de/ http://phpOpenTracker.de/
http://www.professionelle-softwareentwicklung-mit-php5.de/
--
PHP Internals - PHP Runti
On Mon, 23 Jun 2003 09:17:08 +0200 (CEST)
Derick Rethans <[EMAIL PROTECTED]> wrote:
> Sounds like something definitely broken on your system then...
may be =(
I did just `./configure --prefix=usr; make; make install` in autoconf, automake &
libtool sources.
>or are you using third party extens
1 - 100 of 105 matches
Mail list logo
