On Tue, Jun 24, 2003 at 11:53:05PM -0400, Sterling Hughes wrote :
> Ok, so the BETA todo has been updated, and its available at ::
>
> http://www.php.net/~sterling/php5/TODO
Seems the document has moved (it's
http://www.php.net/~sterling/php5/BETA ).
However, why do I get redirected
Sebastian Bergmann wrote:
> I have MySQL 4.0.13 includes and library in my MSVC paths.
Hmpf, but libmysql.lib (as it is refered to in our project files) is
called mysqlclient.lib in the MySQL distribution.
Replacing libmysql.lib with mysqlclient.lib yields 50+ linker errors,
though :-/
-
I have disabled the built-in ext/mysql on Windows in config.w32.h.
When I enable it and try to build, I get the following linker errors:
php_mysql.obj: error LNK2001:
Unresolved external symbol [EMAIL PROTECTED]
php_mysql.obj: error LNK2001:
Unresolved external symbol [EMAIL
On Wed, 2003-06-25 at 01:00, Sebastian Bergmann wrote:
> Sterling Hughes wrote:
> > Are there any other outstanding issues before a beta?
>
> I think there are a number of stale extensions that should be removed
> from php-src/ before a BETA -- for instance qtdom.
>
There are a number of sta
Sterling Hughes wrote:
> Are there any other outstanding issues before a beta?
I think there are a number of stale extensions that should be removed
from php-src/ before a BETA -- for instance qtdom.
--
Sebastian Bergmann
http://sebastian-bergmann.de/ http://phpOpenTracke
On Wed, 2003-06-25 at 00:41, Sebastian Bergmann wrote:
> Sterling Hughes wrote:
> > sterlingWed Jun 25 00:39:01 2003 EDT
> >
> > Modified files:
> > /php-srcNEWS
> > Log:
> > add zend engine 2 changes.
>
> I think ZEND_CHANGES should be merged into NEWS.
>
Its way
Sterling Hughes wrote:
> (Branch: PHP_5)
At least I'm not the only one confused by HEAD/PHP_5 :)
--
Sebastian Bergmann
http://sebastian-bergmann.de/ http://phpOpenTracker.de/
http://www.professionelle-softwareentwicklung-mit-php5.de/
--
PHP Internals - PHP Runti
Sterling Hughes wrote:
> sterling Wed Jun 25 00:39:01 2003 EDT
>
> Modified files:
> /php-src NEWS
> Log:
> add zend engine 2 changes.
I think ZEND_CHANGES should be merged into NEWS.
--
Sebastian Bergmann
http://sebastian-bergmann.de/ http://phpOpen
Sterling Hughes wrote:
> +- Due to a license change, we are longer bundling
^
+no :)
--
Sebastian Bergmann
http://sebastian-bergmann.de/ http://phpOpenTracker.de/
http://www.professionelle-softwareentwicklung-mit-php5.de/
--
P
At 11:53 PM 6/24/2003 -0400, Sterling Hughes wrote:
Hi,
Ok, so the BETA todo has been updated, and its available at ::
http://www.php.net/~sterling/php5/TODO
The two remaining items are:
- Discuss Integrating SPL with PHP 5, Zend Engine 2
- Discuss Bundling libxml2 with PHP 5
Both of these were
Hi,
Ok, so the BETA todo has been updated, and its available at ::
http://www.php.net/~sterling/php5/TODO
The two remaining items are:
- Discuss Integrating SPL with PHP 5, Zend Engine 2
- Discuss Bundling libxml2 with PHP 5
Both of these were left until a later point, and I'll be starting up
Hey,
I was thinking that perhaps implementing a new error type, E_DEPRECATED
might be a good idea for helping to advocate the deprecation of
functions and such.
It would simply work in that it shows a "notice" type message, that is
only shown under E_ALL and if E_DEPRECATED is appended to the
On Wed, 25 Jun 2003, Marcus Börger wrote:
> RL> On Tue, 24 Jun 2003, Edin Kadribasic wrote:
> >> > At 04:32 PM 6/24/2003 +0200, Sascha Schumann wrote:
> >> > > SQLite should become as pervasive as the session extension.
> >> > > It is really a killer feature.
> >> >
> >> > I think this was
Hello Rasmus,
Wednesday, June 25, 2003, 1:45:48 AM, you wrote:
RL> On Tue, 24 Jun 2003, Edin Kadribasic wrote:
>> > At 04:32 PM 6/24/2003 +0200, Sascha Schumann wrote:
>> > > SQLite should become as pervasive as the session extension.
>> > > It is really a killer feature.
>> >
>> > I thin
On Tue, 24 Jun 2003, Edin Kadribasic wrote:
> > At 04:32 PM 6/24/2003 +0200, Sascha Schumann wrote:
> > > SQLite should become as pervasive as the session extension.
> > > It is really a killer feature.
> >
> > I think this was well put. It seems there is "almost" a consensus that
> > bundl
Just to clarify:
Livedocs is a wez, derick and ilia thing.
Sqlite is a wez, marcus, tal thing.
I'm just an annoying cheerleader :)
-Sterling
On Tue, 2003-06-24 at 18:52, Mike Robinson wrote:
> Andi Gutmans wrote:
>
> > At 04:32 PM 6/24/2003 -0400, Sterling Hughes wrote:
> > >On Tue, 2003-06-2
Andi Gutmans wrote:
> At 04:32 PM 6/24/2003 -0400, Sterling Hughes wrote:
> >On Tue, 2003-06-24 at 17:41, Andi Gutmans wrote:
> > > Do we have documentation for the sqlite extension?
> >
> >yep... Not sure if its on php.net, but its written and committed. Used
> >to be available at http://docs.ph
> At 04:32 PM 6/24/2003 +0200, Sascha Schumann wrote:
> > SQLite should become as pervasive as the session extension.
> > It is really a killer feature.
>
> I think this was well put. It seems there is "almost" a consensus that
> bundling and enabling sqlite by default is a big advantage fo
On Tue, 24 Jun 2003, Tim Parkin wrote:
>> Could you please point me to the recent discussion that takes into
>> account the progress of Postgres and the change in licensing of MySQL
>
>There isn't a discussion on that topic per say, but there are plenty on
>why we do(n't) want to bundle new option
Hello Tim,
Tuesday, June 24, 2003, 10:55:07 PM, you wrote:
>> I suggest we don't open this discussion again. The archives are full
TP> of
>> past discussions. We'll continue with the status-quo barring major,
TP> tiring
>> discussions to change it.
TP> Zeev,
TP> Could you please point me t
On Tue, 24 Jun 2003, Tim Parkin wrote:
> Could you please point me to the recent discussion that takes into
> account the progress of Postgres and the change in licensing of MySQL
There isn't a discussion on that topic per say, but there are plenty on
why we do(n't) want to bundle new options wit
> I suggest we don't open this discussion again. The archives are full
of
> past discussions. We'll continue with the status-quo barring major,
tiring
> discussions to change it.
Zeev,
Could you please point me to the recent discussion that takes into
account the progress of Postgres and the
[To the list]
You can also find the xml sources for the documentation in the CVS
repository under
phpdoc/en/reference/sqlite
--Wez.
- Original Message -
From: "Derick Rethans" <[EMAIL PROTECTED]>
To: "Andi Gutmans" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Tuesday, June 24, 2003
On Tue, 24 Jun 2003, Sterling Hughes wrote:
> On Tue, 2003-06-24 at 17:41, Andi Gutmans wrote:
> > Do we have documentation for the sqlite extension?
>
> yep... Not sure if its on php.net, but its written and committed. Used
> to be available at http://docs.php.net/, but that's having problems a
On Tue, 24 Jun 2003, Andi Gutmans wrote:
> At 04:32 PM 6/24/2003 -0400, Sterling Hughes wrote:
> >On Tue, 2003-06-24 at 17:41, Andi Gutmans wrote:
> > > Do we have documentation for the sqlite extension?
> >
> >yep... Not sure if its on php.net, but its written and committed. Used
> >to be availa
At 04:32 PM 6/24/2003 -0400, Sterling Hughes wrote:
On Tue, 2003-06-24 at 17:41, Andi Gutmans wrote:
> Do we have documentation for the sqlite extension?
yep... Not sure if its on php.net, but its written and committed. Used
to be available at http://docs.php.net/, but that's having problems at
th
On Tue, 2003-06-24 at 17:41, Andi Gutmans wrote:
> Do we have documentation for the sqlite extension?
yep... Not sure if its on php.net, but its written and committed. Used
to be available at http://docs.php.net/, but that's having problems at
the moment.
-Sterling
>
> Andi
--
"A business tha
Hello Andi,
Tuesday, June 24, 2003, 11:41:17 PM, you wrote:
AG> Do we have documentation for the sqlite extension?
We have :-)
Thanks to Johann and Wez.
And then there is of course the sqlite homepage which describes the sql
dialect.
--
Best regards,
Marcusmailto
On Tue, 24 Jun 2003, Andi Gutmans wrote:
> Do we have documentation for the sqlite extension?
I just send you a link by private email. (The url points to a test site
for the livedocs, which is not ready for public).
Derick
--
"Interpreting what the GPL actually means is a job best left to tho
Do we have documentation for the sqlite extension?
Andi
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
At 04:32 PM 6/24/2003 +0200, Sascha Schumann wrote:
SQLite should become as pervasive as the session extension.
It is really a killer feature.
I think this was well put. It seems there is "almost" a consensus that
bundling and enabling sqlite by default is a big advantage for PHP and its
On Tuesday 24 June 2003 7:42 pm, Marco Tabini wrote:
>
> - How many "kernel people" do we know anyway? The majority of PHP users
> are not kernel people (or whatever the equivalent for PHP is). I, for
> one, recompile my kernel rather frequently and enjoy using the
> menu-based tools; and I know l
> I don't know a single kernel guy who uses the graphical interfaces. And
> like Zeev said, we used to have this fancy configuration tool. It even
> had a web interface for a while where you could go and click on checkboxes
> and it would generate your configuration. It was actually pretty good,
After long amounts of reading
+1
However, I'd like to see sqlite remain in PECL, and start using PECL the
way it should be. That would be a good start. I think it would ease
some minds, and point out whatever areas happen to still be *real*
issues (if any).
Shane
--
PHP Internals - PHP Runti
On Tue, 24 Jun 2003, Sascha Schumann wrote:
> On Tue, 24 Jun 2003, Uwe Schindler wrote:
>
> > What branch should now be used for commits to PHP4? PHP_4_3 like in the
> > past or PHP_4?
>
> All PHP 4 commits: PHP_4
I don't see any need to put time in merging to PHP_4, as there is no
real re
I don't think the question is bundling SQLite, as many of us really don't
seem to mind that. Even I who am notorious for not liking bundling
software won't argue with this one. I see it as a Good Thing for PHP as a
whole. I'm not sure that it should be enabled by default though, which is
an enti
Yes, Rasmus hit the nail on the button!
> So yes, while I agree with the general sentiment of moving more stuff to
> PECL, for fundamental things like PCRE, Session and now SQL-access to flat
> files, that make up the core of what makes PHP what it is, I think this
> should be bundled.
The two
On Tue, 2003-06-24 at 08:35, Jani Taskinen wrote:
> On Sat, 21 Jun 2003, Lars Torben Wilson wrote:
>
> >Hi there,
> >
> >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 unin
Yeah, I was surprised to see it on the 4_3 branch as well. I don't think
it should be there.
I would like to suggest a 4.4 release at some point after we get 4.3.3 out
the door with the aim being to bridge users from 4.x to 5.x. It would
look as much like 5.x as is feasible, but be based on the
On Tue, 24 Jun 2003, Hartmut Holzgraefe wrote:
> Gareth Ardron wrote:
> > For those of you who have seen the debconf stuff, how about something like
> > that?
> >
> > Walk through menu of "do you want X enabled? do you want Y enabled?" which
> > just stores as a string and excecutes `./configure {s
Nevermind, I was just wondering about the PHP_4_3 branch
having it too, but that's propably just temporary thing.
--Jani
On Tue, 24 Jun 2003, Jani Taskinen wrote:
>
>Where/when it was decided to be included in the main
>distribution in the first place?
>
>--
Where/when it was decided to be included in the main
distribution in the first place?
--Jani
On 22 Jun 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 lib
Gareth Ardron wrote:
For those of you who have seen the debconf stuff, how about something like
that?
Walk through menu of "do you want X enabled? do you want Y enabled?" which
just stores as a string and excecutes `./configure {string value}`
do you remember the linux kernel times *before* we h
On Tuesday 24 June 2003 3:51 pm, Dan Kalowsky wrote:
> I've proposed such solutions in the past, and only recently have come to
> dislike the means (but not the idea). Mainly because the mechanism to do
> such a configuration could lead to a longer configuration time then
> compile time.
For thos
On June 24, 2003 11:49 am, Sebastian Bergmann wrote:
> Is HEAD now PHP_5? Is PHP_5 now obsolete?
The current CVS layout is this:
http://schumann.cx/phpcvs.txt
Ilia
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Ilia Alshanetsky wrote:
> iliaa Tue Jun 24 11:23:17 2003 EDT
>
> Added files:
> /php-src/ext/standard/tests/strings bug24312.phpt
>
> Modified files:
> /php-src/ext/standard base64.c
> Log:
> Fixed bug #24312 (base64_decode() does not skip 0xF0-0xFF characters)
>
On Sat, 21 Jun 2003, Lars Torben Wilson wrote:
>Hi there,
>
>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. s
Ilia Alshanetsky wrote:
> iliaa Tue Jun 24 10:36:18 2003 EDT
>
> Modified files: (Branch: PHP_4_3)
> /php-src/main fopen_wrappers.c
> Log:
> MFH: typo fix.
PHP_4_3 now builds again on Windows.
--
Sebastian Bergmann
http://sebastian-bergmann.de/
On June 24, 2003 10:50 am, George Schlossnagle wrote:
> I'm not approaching this from a performance standpoint, but from one
> where statically compiled extensions slow the overall release process,
> make it difficult for users to incrementally upgrade their extensions,
> and generally contribute t
Menu driven approach is much slower then the ./configure approach and only
makes sense when you have a mind numbingly large number options like you do
in the Linux kernel. The default packages are the for the average user there
is nothing to say advanced users who have no need to sqlite or anyth
One of the main reasons PHP has reached the popularity it has today is
because it was mindnumbingly easy to get started with it and you could do
so many things with a default PHP installation. You can't twirl a wet cat
without hitting servers with Gallery, PHP-Nuke, PHPBB or one of the other
dozen
At 17:46 24/06/2003, Marco Tabini wrote:
Why not disable all extensions by default and add a configuration
utility that is launched before compilation--sort-of like the Linux
kernel?
We had one of those once, it was so popular that nobody even said anything
when we removed it :)
Zeev
--
PHP Inte
At 17:50 24/06/2003, George Schlossnagle wrote:
On Tuesday, June 24, 2003, at 10:56 AM, Ilia A. wrote:
On June 24, 2003 10:40 am, George Schlossnagle wrote:
I dig including it in ext, and bundling the full sqlite sources as
well. I just don't think it should be enabled by default.
Enabling sqlit
Even with a menu-driven approach (e.g.: make menuconfig in the kernel)?
My thought is that you'd still feed the end result through ./configure,
but the app would make it somewhat easier for those who don't have a
clue. It would also be possible to distribute "pre-packaged"
configurations for common
I've proposed such solutions in the past, and only recently have come to
dislike the means (but not the idea). Mainly because the mechanism to do
such a configuration could lead to a longer configuration time then
compile time.
On Tue, 24 Jun 2003, Marco Tabini wrote:
> Why not disable all ext
Why not disable all extensions by default and add a configuration
utility that is launched before compilation--sort-of like the Linux
kernel?
Marco
On Tue, 2003-06-24 at 10:56, Ilia A. wrote:
> On June 24, 2003 10:40 am, George Schlossnagle wrote:
> > I dig including it in ext, and bundling the
On Tuesday, June 24, 2003, at 10:56 AM, Ilia A. wrote:
On June 24, 2003 10:40 am, George Schlossnagle wrote:
I dig including it in ext, and bundling the full sqlite sources as
well. I just don't think it should be enabled by default.
Enabling sqlite by default has virtually no performance impact
On June 24, 2003 10:40 am, George Schlossnagle wrote:
> I dig including it in ext, and bundling the full sqlite sources as
> well. I just don't think it should be enabled by default.
Enabling sqlite by default has virtually no performance impact. Your binary is
increased by roughly 100k and you
On Tuesday, June 24, 2003, at 10:24 AM, Wez Furlong wrote:
Sterling has a good point that sqlite is something that could really
boost
PHP. Currently, the only way to ensure that it is a standard feature
is to
enable it by default. Sad but true.
That is true. It's something of a chicken and e
SQLite should become as pervasive as the session extension.
It is really a killer feature.
- Sascha
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On Tue, 24 Jun 2003, Uwe Schindler wrote:
> What branch should now be used for commits to PHP4? PHP_4_3 like in the
> past or PHP_4?
All PHP 4 commits: PHP_4
Bug fixes (in addition to PHP_4) can be committed to PHP_4_3
for the next release in the 4.3.x series. No features should
Sterling has a good point that sqlite is something that could really boost
PHP. Currently, the only way to ensure that it is a standard feature is to
enable it by default. Sad but true.
My main misgiving with it being enabled by default is that it will make it
harder for me to publish releases o
What branch should now be used for commits to PHP4? PHP_4_3 like in the
past or PHP_4?
At 16:03 24.06.2003 +0200, you wrote:
All extensions which were marked with "-" have been copied
from php4.unused/ext to php-src/ext. Most extensions had an
empty HEAD branch already. For domxml,
On June 24, 2003 10:17 am, Sebastian Bergmann wrote:
> Sascha Schumann wrote:
> > Sebastian, does PHP_4_3 work for you now?
>
> It's better than before, but the build fails with
>
> php4\main\fopen_wrappers.c(168): error C2059:
> Syntax error: 'type'
That's my fault, I'll fix it momentar
Sascha Schumann wrote:
> Sebastian, does PHP_4_3 work for you now?
It's better than before, but the build fails with
php4\main\fopen_wrappers.c(168): error C2059:
Syntax error: 'type'
--
Sebastian Bergmann
http://sebastian-bergmann.de/ http://phpOpenTracker.de/
On June 23, 2003 01:48 pm, Dan Kalowsky wrote:
> As always I'm against any enable by default thinking.
> Why, oh why, are we making this wonderful configure script
> completely useless?
In a perfect world nothing would be enabled by default and each user would
enable just the extensions they wont
On Tue, 24 Jun 2003 10:03:51 -0400
George Schlossnagle <[EMAIL PROTECTED]> wrote:
> This is a good synopsis of some of my feelings. PECL == Siberia is a
> recurrent gripe, but anytime someone works on a cool project they want
>
> it to bundle, ship and be enabled by default instead of promoting
All extensions which were marked with "-" have been copied
from php4.unused/ext to php-src/ext. Most extensions had an
empty HEAD branch already. For domxml, xslt, hyperwave, I
have manually emptied that branch.
After that, the PHP_4 tags have been copied from PHP_4_3 for
On Tuesday, June 24, 2003, at 09:56 AM, Philip Olson wrote:
This is a wonderful time to promote
PEAR and the PECL situation rather than force featured
bundles on people, like sqlite.
This is a good synopsis of some of my feelings. PECL == Siberia is a
recurrent gripe, but anytime someone works o
-1
People that want to use sqlite can download the source,
they can even use the pear command to do this either by:
a) pear install sqlite (to create the .so)
extension=sqlite.so
b) pear bundle sqlite (to download the source)
./configure --with-sqlite
Forcing the entire world
ok, corny title, but is there the possibility of defining
functions/constants for dealing with Infinity (+ and -) and NaN ? i need
this for an extension im writing (and i have code to do it), but i would
rather not define in an extension what should be a part of the core (or at
least ext/standard).
Ok, here is the normalized diff from the CVS server.
James, now tell me again, why we cannot simply empty the HEAD
branch of these directories?
-apache
-aspell
-ccvs
-com
-cybercash
-cybermut
-cyrus
-dav
-dbplus
-domxml
-dotnet
-fribidi
-hyperwave
-icap
-java
-mailparse
+mono
-muscat
On Tue, 24 Jun 2003, James Cox wrote:
> 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.
A list of extensions you rm -rf from PHP 5 would be
appreciated.
- Sascha
--
PHP Inter
> 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 histories doesn't seem to be
> feasible to me. So I'm OK with it for now.
With the empty branch concept, the unused engine directory
contains only a single anti-pruning
At 09:30 24/06/2003, James Cox wrote:
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.
James,
There's no technical reason for php4 and php5 not to live together in the
same module. It doesn't me
I suggest we don't open this discussion again. The archives are full of
past discussions. We'll continue with the status-quo barring major, tiring
discussions to change it.
Zeev
At 09:50 24/06/2003, James Cox wrote:
>
> Since there's been a lot of talk about disabling mysql by
> default (and
> Well, for once, you can't use -A, which is quite annoying to begin
> with. In addition, various versions of CVS don't handle multiple sticky
> tags too well - so if you'd like to say, update to a certain date in the
> branch - it won't work (you can have just one sticky tag - either date or
> br
At 01:32 24/06/2003, Sascha Schumann wrote:
> 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 f
SS>> clearly a proven model.
SS>>
SS>> What do the active developers on this list think?
I think there's no problem in having PHP4 and PHP5 in single repository as
branches. However, I can live with different modules too. So far I have
seen almost no arguments from either side besides t
79 matches
Mail list logo
