[PHP-DEV] Re: php4 /ext/standard math.c
derick Sun Dec 16 05:59:20 2001 EDT
Modified files:
/php4/ext/standard math.c
Log:
- Fix for bug #14544, bogus warning in pow()
Excuse me for disturbing, but it's actually wrong now. You cannot take the
logarithm of zero. As a consequence, in exponential ways of doing pow()
(i.e. with floating-point exponent) you MUST have a positive (implying
non-zero) base.
However, with a positive exponent, it is possible to determine the limit
base-0 of e^(log(base) * exp), which equals zero. You can argue wether or
not pow() should yield zero in this case, but as people expect pow(x,0.5) to
behave like sqrt(x), I agree it'd be better to yield zero.
In concreto:
Up until revision 1.66:
pow(x, y) [x0] = warning about nonpositive exponent
pow(0, y) [y=0] = warning about nonpositive exponent
pow(0, y) [y0] = warning
Revision 1.67:
pow(x, y) [x0] = warning about nonpositive exponent
pow(0, y) [y=0] = INF/NAN without warning
pow(0, y) [y0] = 0.0 (because exp(NEG_INF) returns 0.0)
I suggest:
pow(x, y) [x0] = warning about negative exponent
pow(0, y) [y=0] = different warning (pow(0, y) is undefined)
pow(0, y) [y0] = 0.0
[begin pseudo-diff]
+ if (Z_DVAL_PP(zbase) == 0.0) {
+ if (Z_DVAL_PP(zexp) 0) {
+RETURN_DOUBLE(0.0);
+ } else {
+ warning
+ }
+ }
if (Z_DVAL_PP(zbase) 0.0) { /* can remain like it is now after all */
:s/nonpostive/negative
[end pseudo-diff]
As for the bug, it is wrong to think that abs always yields a positive
value. abs returns a nonnegative value. So the warning DID correspond to the
case, this issue was that in this particular case it is possible to return a
decent result, even though base is nonpositive and exponent is broken
(=floating point).
#- I think I do not need to tell who screwed this up
Why are you so hatefull?
Regards,
--Jeroen
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] bzcompress() bugfix
Hi,
I suggest MFH'ing the test for bz2. The problem is that size isn't
initialized at the time when it's passed to buff-compress.
I attached a patch to HEAD, for the PHP_4_0_7 branch I don't have a
patch yet, as I don't have more time currently to test it etc, but it
should be straight forward to adapt it to PHP_4_0_7.
I tested this patch. It makes the test work, and a test on a big file too.
The original intention was and is to not use buff(de)compress but those
stream functions in bzlib, in order to just (de)compress one time, in
stead of retrying all the time, but I didn't yet finish that.
--Jeroen
Jeroen van Wolffelaar
[EMAIL PROTECTED]
http://jeroen.A-Eskwadraat.nl
Index: bz2.c
===
RCS file: /repository/php4/ext/bz2/bz2.c,v
retrieving revision 1.29
diff -u -r1.29 bz2.c
--- bz2.c 1 Nov 2001 09:45:25 - 1.29
+++ bz2.c 13 Nov 2001 10:07:16 -
@@ -298,7 +298,8 @@
* of data + 600 which is the largest size the results of the compression
* could possibly be, at least that's what the libbz2 docs say (thanks to
* [EMAIL PROTECTED] for pointing this out). */
- dest = emalloc(Z_STRLEN_PP(source) + (0.01 * Z_STRLEN_PP(source)) + 601);
+ size = Z_STRLEN_PP(source) + (0.01 * Z_STRLEN_PP(source)) + 601;
+ dest = emalloc(size);
/* Handle the optional arguments */
if (ZEND_NUM_ARGS() 1) {
@@ -318,8 +319,9 @@
RETURN_FALSE;
}
- /* size down... */
- dest = erealloc(dest, size);
+ /* size down... and NUL-terminate */
+ dest = erealloc(dest, size+1);
+ dest[size] = 0;
RETURN_STRINGL(dest, size, 0);
}
/* }}} */
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Re: pow() showing odd long/float boundary case characteristics
Rasmus Lerdorf [EMAIL PROTECTED] wrote in message
[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
The pow() regression test is failing due to this strange characteristic:
(...)
}
ie. pow(2147483647,1) returns a float where one would expect it to return
an int. Off by one error somewhere?
I'm quite certain (but not 100% certain of course) this is not the case. The
issue here is that in order to check wether the result is small enough to
fit into a float, I did a exp(log(base) * exp) (line 478), and check that
against long_max/min. Because of fp characteristics, this will give a false
alarm near the boundary: the check says it won't fit into int, but actually,
it does.
I could modify it to run the integer algorithm anyway, and check there for
overflows. Then no false alarms. Because the algorithm is very fast,
performance is not the issue.
Or just leave the code as it is, since the test nearly only exists of rare
boundary cases, it's not realistic. But agreed: it'd be better if always int
is returned when possible.
Same thing happens on the negative boundary.
Here neither is a off-by-one issue, though the code could have a bit more
comments. On entering this loop:
while (lexp 0) {
if (lexp 1) /* odd */
Z_LVAL_P(return_value) *= lbase;
lexp = 1;
lbase *= lbase;
}
lbase will be negative if it was originally, and if the result is negative,
lexp will be odd of course. So already in the first iteration return_value
will be negative, and that won't change anymore because lbase is squared,
and thus there will be taken full advantage of the larger negative range.
If you found a flaw/bug in the code, please mail me.
--Jeroen
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Re: [PHP-QA] Compile troubles, impossible to create .so extensions with current cvs?
FYI, I use ltmain.sh (GNU libtool) 1.4 (1.920 2001/04/24 23:26:18) on one machine, and ltmain.sh (GNU libtool) 1.4.2 (1.922.2.53 2001/09/11 03:18:52) on the other. Downgrading to 1.3.3 did not solve the problem: ltmain.sh (GNU libtool) 1.3.3 (1.385.2.181 1999/07/02 15:49:11) I'm trying further... --Jeroen - Original Message - From: Jani Taskinen [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Friday, November 09, 2001 1:14 PM Subject: Re: [PHP-QA] Compile troubles, impossible to create .so extensions with current cvs? I think it's the libtool 1.4(.x) again that is breaking. Or we're doing something weird. Sascha might know? I noticed this myself sometime ago but I forgot about it.. --Jani On Fri, 9 Nov 2001 [EMAIL PROTECTED] wrote: Hi, First, I'm not well into compiling PHP in specific ways, so consider these semi-newbie questions. I hope someone has an idea about what could be going on, if so, please drop me a line. My system is Linux Debian unstable, everything relevant is up-to-date. My compile-line is: ./configure --disable-static --with-mysql=shared * Result on 406 dist: works fine, mysql.so appears in modules dir * Any recent snapshot: mysql.a and mysql.la appear in modules, but no .so * Latest cvs after ./buildconf: same result * getting back to 406 by means of CVS, ./buildconf fails: cvs up -r PHP_4_0_6 ./cvsclean make clean make distclean [jeroen@richard]~/php/php4 ./buildconf buildconf: checking installation... buildconf: autoconf version 2.52 (ok) buildconf: automake version 1.5 (ok) buildconf: libtool version 1.4 (ok) rebuilding Makefile templates rebuilding configure ./aclocal.m4:814: error: m4_defn: undefined macro: _m4_divert_diversion ./aclocal.m4:360: PHP_SUBST is expanded from... ./aclocal.m4:814: the top level rebuilding main/php_config.h.in ./aclocal.m4:814: error: m4_defn: undefined macro: _m4_divert_diversion ./aclocal.m4:360: PHP_SUBST is expanded from... ./aclocal.m4:814: the top level autoconf: tracing failed Thanks a lot Jeroen -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Fwd: can't build PHP_4_0_7 branch
Hm, it seems I'm not the only one having troubles compiling. I catched this one on php.install These are exact the same errors as I'm getting. --Jeroen Grigori Goronzy [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED]... I checked out the PHP_4_0_7 branch and tried running ./buildconf. I got: bash-2.05$ ./buildconf buildconf: checking installation... buildconf: autoconf version 2.52 (ok) buildconf: automake version 1.5 (ok) buildconf: libtool version 1.4 (ok) rebuilding Makefile templates rebuilding configure ./aclocal.m4:944: error: m4_defn: undefined macro: _m4_divert_diversion ./aclocal.m4:473: PHP_SUBST is expanded from... ./aclocal.m4:944: the top level rebuilding acconfig.h rebuilding main/php_config.h.in ./aclocal.m4:944: error: m4_defn: undefined macro: _m4_divert_diversion ./aclocal.m4:473: PHP_SUBST is expanded from... ./aclocal.m4:944: the top level autoconf: tracing failed bash-2.05$ same with php_4_0_7RC2 and RC3. What can I do? -greg -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Re: [PHP-LANG] Feature or bug?
Yasuo wrote:
PHP does not report any errors for too many parameters for user
defined functions, both normal function and class method :(
Is PHP designed not to report error for this?
Too many parameters for a function is obvious error and any
language MUST report error for this, unless variable length of
parameters is allowed. IMO
php.lang is for language documumentation. Use php-dev for this kind of
issues.
And yes, that is intended. You need it when you do you own argument
handling:
function printall()
{
foreach (function_get_args() as $arg) {
echo "$arg\n";
}
}
--Jeroen
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Re: Bug #13842 Updated: Member variables in parent and child classes overwrite each other
Pleaes use the web interface for updating bugs!
I missed this mail until now.
--Jeroen
- Original Message -
From: Doug Plant [EMAIL PROTECTED]
Newsgroups: php.dev
To: [EMAIL PROTECTED]
Sent: Sunday, October 28, 2001 4:38 AM
Subject: Re: Bug #13842 Updated: Member variables in parent and child
classes overwrite each other
Hi,
Thanks for the reply. Still looks bad.
My mistake, but I left the script in it's good configuration. If you
change the line:
class C2 extends C1_1
To:
class C2 extends C1
the the bad behaviour is shown. I left the line in the former state.
Doug
From: Bug Database [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: Bug #13842 Updated: Member variables in parent and child classes
overwrite each other
Date: 27 Oct 2001 05:37:46 -
ID: 13842
Updated by: sniper
Reported By: [EMAIL PROTECTED]
Old Status: Open
Status: Feedback
Bug Type: Class/Object related
Operating System: Windows NT 5.0 build 2195
PHP Version: 4.0.6
New Comment:
Works fine for me with latest CVS. Please try the
development build from http://www.php4win.com/
--Jani
Previous Comments:
[2001-10-26 17:52:30] [EMAIL PROTECTED]
I'm not all that familiar with PHP, so it's possible I haven't understood
something that should be obvious, or have mistyped something. But
assuming
that's not the case:
To my eye this makes using someone else's classes via inheritence a wee
bit
dangerous, and makes using inheritence at all somewhat problematic since
changing a class that exists in an inheritence makes one liable to create
subtle bugs in code that one has not modified - which defeats one of the
(possibly the most) principal purposes of OO.
If I could make a suggestion: support of 'private' and 'public' for
member
variables might be a good thing. Especially if access defaulted to
'private' and that meant that the variable was only visible to the
immediate class.
Using the CGI binary without modification running on Microsoft-IIS/5.0
I
used the following test script:
html
head
titleInheritence Bug/title
/head
body
?php
file://=
// NOTE:
// Bad behaviour if C2 extends C1, Correct if C2 extends C1_1
class C2 extends C1_1
{
var $m_sMe = C2; // ERROR: this overwrites parent
var $m_sIniter = ;
function C2( $sIniter=)
{
$this-m_sIniter = $sIniter; // OK - by defn
parent::C1( $this-m_sMe); // OK - the way to do it
}
function WhoIsIt()
{
printf( C2::WhoIsIt() : This is: . $this-m_sMe . br\n);
printf( Inited by: . $this-m_sIniter . br\n);
parent::WhoIsIt();
}
}
file://=
class C1_1
{
var $m_sMe_1 = C1;
var $m_sIniter_1 = ;
function C1( $sIniter=)
{
print( (OK)br\n);
$this-m_sIniter_1 = $sIniter;
}
function WhoIsIt()
{
printf( C1::WhoIsIt() : This is: . $this-m_sMe_1 . br\n);
printf( Inited by: . $this-m_sIniter_1 . br\n);
}
function ResetBase()
{
$this-m_sMe_1 = C1;
printf( C1::ResetBase() : This is: . $this-m_sMe_1 . br\n);
printf( Inited by: . $this-m_sIniter_1 . br\n);
}
}
file://=
class C1
{
var $m_sMe = C1;
var $m_sIniter = ;
function C1( $sIniter=)
{
print( (Bad)br\n);
$this-m_sIniter = $sIniter; // ERROR: this overwrites child's value
}
function WhoIsIt()
{
printf( C1::WhoIsIt() : This is: . $this-m_sMe . br\n);
printf( Inited by: . $this-m_sIniter . br\n);
}
function ResetBase()
{
$this-m_sMe = C1;
printf( C1::ResetBase() : This is: . $this-m_sMe . br\n);
printf( Inited by: . $this-m_sIniter . br\n);
}
}
file://=
$test = new C2( Doug);
$test-WhoIsIt();
file://$test-ResetBase();
?
p
In case there is a platform dependency, this is what I consider correct
output:br
pre
C2::WhoIsIt() : This is: C2
Inited by: Doug
C1::WhoIsIt() : This is: C1
Inited by: C2
/pre
/p
/body
/html
ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at
http://bugs.php.net/?id=13842edit=2
_
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Suggestion RFC: Bug db mails
Hi, Suggestion: set the From: of bug-mails to [EMAIL PROTECTED], and put a autoresponer over there asking the user again to use the web interface in stead of replying, and possibly don't give the php-dev mail at all, or as 'only for ...'. --Jeroen -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Bug #13094 Updated: Upload very slow
Please leave alone these. I was going to close them myself as I want to add some information to them too.. I'm sorry, you committed the fix yesterday early, and I thought you might have forgotten them. (but should've know better) I should've mailed you instead, I got a 'then this bug is fixed or not?' mail from the submitter. --Jeroen -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Bug #13846 Updated: Patch: Use [ ] as shortcut forarray()
On Sun, 28 Oct 2001, Zakaria wrote:
For example:
Perl: $list = (1, 2 ,3, 'four', 'five', (6.1, 6.2, 6.3));
Python: list = [1, 2, 3, 'four', 'five', [6.1, 6.2, 6.3]]
Ruby: list = [1, 2, 3, 'four', 'five', [6.1, 6.2, 6.3]]
Tcl: set list {1 2 3 four five {6.1 6.2 6.3}}
PHP: $list = array(1, 2, 3, 'four', 'five', array(6.1, 6.2, 6.3));
Which clearly shows that PHP is readable and all the other languages are
not. -10 from me to this feature.
And these example are still a bit readable, but what about:
$arr1 = [];
$arr2[10] = [2];
$foo = bla('arg1', [2, 3, 4]);
and such cases...
So indeed a bad idea.
--Jeroen
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Fw: [PATCH] Fix for inconsistent float-int converting
On Fri, 19 Oct 2001, Stig S. Bakken wrote: Hm, another way to deal with overflows could be returning null, if it's acceptable to return a different type than expected at least. With 0 or max/min, it won't be possible for a program to detect overflows. With null it would be. I like this idea... But when you do (int)$bla, you really expect an integer... and not null. Still, is null maybe acceptable? ZeevAndi? This reminds me of another suggesting I made: the (number) cast. It will convert to int if possible, float otherwise. Third point: Currently casting array to a number, it will be 1 if non-empty, zero if empty. IMHO, it is more logical to simply return the number of elements. It is BC, since boolean checks for array will still yield false iff array is empty. (I'm - of course - open for discussion on these things) --Jeroen - Stig Jeroen van Wolffelaar wrote: On Fri, 19 Oct 2001, Stig S. Bakken wrote: In cases like these I think PHP should do whatever C does. There's no point in trying to be clever when casts overflow. In C, when you doe int i;, i will contain random data. In PHP, a variable will always be cleared (to null). In C, when you cast a out-of-range-float, I doubt wether it's defined. Furthermore, PHP is not C, so I see no reason to follow C just like that. What do you expect from trying to store a too big float in an integer? I expect an error, and the nearest valid result. I really see no logic in the current behavior, only that it makes a limited amount of unsigned-int faking possible. But floats are floats, that's not going well all the time (see the numerous bugreports on this kind of gotcha's). So also for this reason I believe there should be no such wrapping behaviour, as it might lead people to think unsigned ints are supported, resulting in very strange things. Especially the E_NOTICE when this happens will help a lot of people IMO. In the case of casting larger integers into smallers, it's differnt because you're talking about _intgers_ then, and not floats. --Jeroen - Stig Jeroen van Wolffelaar wrote: Resent, due to lack of feedback from my side ;) Andi replied: Why is it more correct to convert it to min/max values? I can't think of a case where this would make more sense to the developer. Also, there is a reason for the cast to unsigned int if the value is bigger that LONG_MAX. I think it makes sense. If a float is out-of-range, it can usually not be mod'd by 2**32, due to the nature of floats. Therefore, the only consistent way would be going to the nearest integer possible. Okay, because on most systems floats happen to be more precise than int's, you _can_ mod them by 2**32, but there is a quite significant possibility of having rounding errors. You cannot do integer-precision with floats. And it's inconsistent too, PHP int's are ranging from -2**31 to (2**31)-1, there is no such thing as unsigned integers. So why convert the float 3e9 to something way below zero? Additionally, a notice is a good idea here, just like what happens on division by zero: the most natural result is returned, and a notice is issued. --Jeroen - Original Message - From: Jeroen van Wolffelaar [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, October 02, 2001 2:39 AM Subject: [PATCH] Fix for inconsistent float-int converting When a too-large float is converted to integer, it happens in a quite random way. When float is out of range, PHP should stick to the min resp. max values of integer. This patch will achieve this, I tested it succesfully. --Jeroen Jeroen van Wolffelaar [EMAIL PROTECTED] http://www.A-Eskwadraat.nl/~jeroen Name: double.diff double.diffType: unspecified type (application/octet-stream) Encoding: quoted-printable -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] Jeroen van Wolffelaar [EMAIL PROTECTED] http://www.A-Eskwadraat.nl/~jeroen Jeroen van Wolffelaar [EMAIL PROTECTED] http://www.A-Eskwadraat.nl/~jeroen -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Re: Bug #13748 Updated: Exec() and System() broken
ID: 13748 Updated by: mfischer Reported By: [EMAIL PROTECTED] Old Status: Open Status: Bogus Bug Type: Program Execution Operating System: Windows 2000 SP2 w/IIS5.0 PHP Version: 4.0.6 New Comment: Submitted twice - bogus. - Markus Whats up today guys? Did you all forgot that reloading the page also submits form data again? Why isn't php.net redirecting after a POST? That's a common solution, and also makes sure you can have a logic-only php script, since you're redirecting to a page-with-layout. By means of a get var (or coockies) you can pass on the submission result, i.e. succesfull or not. This way you effectively prevent multiple postings. --Jeroen -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Fw: [PHP-CVS] cvs: php4 /ext/standard basic_functions.c
Resent. The discussion isn't closed yet, and this is important, since it
will be already in 4.1.0
--Jeroen
- Original Message -
From: Jeroen van Wolffelaar [EMAIL PROTECTED]
To: Andi Gutmans [EMAIL PROTECTED]
Cc: PHP cvs [EMAIL PROTECTED]
Sent: Wednesday, October 10, 2001 8:46 PM
Subject: Re: [PHP-CVS] cvs: php4 /ext/standard basic_functions.c
Stig,
Can we please keep these function names consistent with the PHP way and
not
with Perl? We decided a long time ago to use significant function names,
i.e., version_equals(). Also, do we really need all of those?
Why not simply return -1, 0, 1, just like any comparator?
The idea of 'comparator' is already in PHP in some places. Then you don't
have an additional parameter, and only 1 function.
version_compare() would be the best name then.
--Jeroen
Andi
At 10:32 AM 10/10/2001 +, Stig Bakken wrote:
ssb Wed Oct 10 06:32:17 2001 EDT
Modified files:
/php4/ext/standard basic_functions.c
Log:
* added function entries for version_{lt,le,gt,ge,eq}
Index: php4/ext/standard/basic_functions.c
diff -u php4/ext/standard/basic_functions.c:1.405
php4/ext/standard/basic_functions.c:1.406
--- php4/ext/standard/basic_functions.c:1.405 Sun Oct 7 14:34:44
2001
+++ php4/ext/standard/basic_functions.c Wed Oct 10 06:32:16 2001
@@ -17,7 +17,7 @@
+--+
*/
-/* $Id: basic_functions.c,v 1.405 2001/10/07 18:34:44 derick Exp $ */
+/* $Id: basic_functions.c,v 1.406 2001/10/10 10:32:16 ssb Exp $ */
#include php.h
#include php_main.h
@@ -792,6 +792,11 @@
/* functions from versioning.c */
PHP_FE(version_compare,
NULL)
+PHP_FE(version_lt,
NULL)
+PHP_FE(version_le,
NULL)
+PHP_FE(version_gt,
NULL)
+PHP_FE(version_ge,
NULL)
+PHP_FE(version_eq,
NULL)
{NULL, NULL, NULL}
};
--
PHP CVS Mailing List (http://www.php.net/)
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail:
[EMAIL PROTECTED]
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Fw: heredoc: change of behavoiur?
Resent due to lack of feedback.
- Original Message -
From: [EMAIL PROTECTED]
Newsgroups: php.dev
Sent: Wednesday, October 10, 2001 5:28 PM
Subject: heredoc: change of behavoiur?
Currently, heredoc as a bit of strange behaviour in syntax of terminating
it.
I think it's a good idea to be a bit looser. It will make it more
consistent, and allows inline use of heredoc.
For BC: I really think that's no problem, but in rare cases it could lead
to
problems. I don't know yet wether BC alone would be showstopper for this
patch.
On the way this patch also solves the bug that mac-newlines are not
understood (didn't see a bug report yet, but that's probably because not
much people use the mac...)
if there are other reasons to hold to the current syntax, please let me
know.
(see also: bug 13610)
Patch available here:
http://www.A-Eskwadraat.nl/~jeroen/php/looser_heredoc.diff
which changes behaviour to:
A heredoc is considered closed when the heredoc identifier appears
directly
after a newline. Remaining characters are allowed, provided they are
invalid
identifyer characters.
Example:
?php
mail('[EMAIL PROTECTED]', 'heredoc test', TEXT
Hello Jeroen,
Greets!
TEXT, 'Cc: [EMAIL PROTECTED]');
?
And this works:
?php
echo HEREDOC
bla
HEREDOCUMENTATION;
HEREDOC; // here the heredoc ends
?
But this doesn't:
?php
echo HEREDOC
bla
HEREDOC UMENTATION;
HEREDOC;
?
for the same reason as this is:
echo bla UMENTATION;
causes a parse error.
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Shuffle() - change of algorithm needed (also relevant for array_rand())
Resent due to lack of feedback. Objections against me changing it to the behaviour I described below? --Jeroen - Original Message - From: Jeroen van Wolffelaar [EMAIL PROTECTED] To: PHP Developers Mailing List [EMAIL PROTECTED] Sent: Monday, October 15, 2001 9:45 PM Subject: Re: Bug #7045 Updated: Shuffle() does behave correctly ID: 7045 Updated by: derick Reported By: [EMAIL PROTECTED] Old Status: Analyzed Status: Open Bug Type: Arrays related Operating System: Linux RH 6 and 7 PHP Version: 4.0.1pl2 New Comment: snip [2000-10-30 10:07:36] [EMAIL PROTECTED] This is probably the property of sort algorithm used in shuffle. Whoever wrote it, please take attention! The algorithm is a mergesort with a random comparer. That's not going to give a well shuffle. There are a few alternatives. First, it's important to know wether one can random-access the array. IIRC, that's not possible. So the straight forward O(n) algorithm won't work directly (well, it'll work, but definitely not in O(n)). It can be easily made to work by simply indexing the array first (from outside). It's straight forward, and thus quite easy to assure that it's correct, and quite easy to implement too. The external indexing step is also O(n), so speed isn't dramatically affected. Note that this algortihm is a lot faster than the current one. Mergesort is O(nlogn), with more memory usage, and quite heavier draw on the random number generator. NB: also the array_rand() function has a bad algorithm. The same algorithm could and should be used, it also elimintates the use of shuffle inside array_rand(). --Jeroen -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Fw: [PATCH] Fix for inconsistent float-int converting
Resent, due to lack of feedback from my side ;) Andi replied: Why is it more correct to convert it to min/max values? I can't think of a case where this would make more sense to the developer. Also, there is a reason for the cast to unsigned int if the value is bigger that LONG_MAX. I think it makes sense. If a float is out-of-range, it can usually not be mod'd by 2**32, due to the nature of floats. Therefore, the only consistent way would be going to the nearest integer possible. Okay, because on most systems floats happen to be more precise than int's, you _can_ mod them by 2**32, but there is a quite significant possibility of having rounding errors. You cannot do integer-precision with floats. And it's inconsistent too, PHP int's are ranging from -2**31 to (2**31)-1, there is no such thing as unsigned integers. So why convert the float 3e9 to something way below zero? Additionally, a notice is a good idea here, just like what happens on division by zero: the most natural result is returned, and a notice is issued. --Jeroen - Original Message - From: Jeroen van Wolffelaar [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, October 02, 2001 2:39 AM Subject: [PATCH] Fix for inconsistent float-int converting When a too-large float is converted to integer, it happens in a quite random way. When float is out of range, PHP should stick to the min resp. max values of integer. This patch will achieve this, I tested it succesfully. --Jeroen Jeroen van Wolffelaar [EMAIL PROTECTED] http://www.A-Eskwadraat.nl/~jeroen double.diff -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Random
(you'd already have expected this, i guess...) I still have hardly no feedback on proposal 3b of random change: http://www.a-eskwadraat.nl/~jeroen/rand/ The main issue - inconsistent and duplicate functions for random, no way to explicitly and portably get reproducable results - isn't solved by bugfixes that have been applied now. Note that it's now __not a redesign__, but new - better IMO - interface to random functions. No BC-problems. --Jeroen Jeroen van Wolffelaar [EMAIL PROTECTED] http://www.A-Eskwadraat.nl/~jeroen -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Fw: [PHP-DEV] Bug #13740 Updated: Call to undefined function: dbmopen()
I really don't know, forwarding to php-dev... That bug hasn't yet been looked after, it contains a reproducing script (dba-related). --Jeroen - Original Message - From: Pierre-Alain Joye [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, October 19, 2001 12:40 AM Subject: Re: [PHP-DEV] Bug #13740 Updated: Call to undefined function: dbmopen() Hello, do you know if there is still someone on the gdbm/dba wrapper part ? I got a bug on my system (Bug #13660). best regards, pa -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Fw: [PHP-CVS] cvs: php4 /ext/standard basic_functions.c
version_compare() with two args returns -1 / 0 / 1 today, if you want to
use it that way please do. I think the third arg is useful, and it's
not exactly bothering people who don't need it. I consider this
discussion as closed.
Hm, I did miss something :(.
I consider the discussion closed too, it just comes down to proper
documentation now.
Sorry
--Jeroen
(Just for the record: version_compare is the only function now,
version_lt friends are gone.)
That I didn't miss...
- Stig
Jeroen van Wolffelaar wrote:
Resent. The discussion isn't closed yet, and this is important, since it
will be already in 4.1.0
--Jeroen
- Original Message -
From: Jeroen van Wolffelaar [EMAIL PROTECTED]
To: Andi Gutmans [EMAIL PROTECTED]
Cc: PHP cvs [EMAIL PROTECTED]
Sent: Wednesday, October 10, 2001 8:46 PM
Subject: Re: [PHP-CVS] cvs: php4 /ext/standard basic_functions.c
Stig,
Can we please keep these function names consistent with the PHP way
and
not
with Perl? We decided a long time ago to use significant function
names,
i.e., version_equals(). Also, do we really need all of those?
Why not simply return -1, 0, 1, just like any comparator?
The idea of 'comparator' is already in PHP in some places. Then you
don't
have an additional parameter, and only 1 function.
version_compare() would be the best name then.
--Jeroen
Andi
At 10:32 AM 10/10/2001 +, Stig Bakken wrote:
ssb Wed Oct 10 06:32:17 2001 EDT
Modified files:
/php4/ext/standard basic_functions.c
Log:
* added function entries for version_{lt,le,gt,ge,eq}
Index: php4/ext/standard/basic_functions.c
diff -u php4/ext/standard/basic_functions.c:1.405
php4/ext/standard/basic_functions.c:1.406
--- php4/ext/standard/basic_functions.c:1.405 Sun Oct 7 14:34:44
2001
+++ php4/ext/standard/basic_functions.c Wed Oct 10 06:32:16 2001
@@ -17,7 +17,7 @@
+--+
*/
-/* $Id: basic_functions.c,v 1.405 2001/10/07 18:34:44 derick Exp $
*/
+/* $Id: basic_functions.c,v 1.406 2001/10/10 10:32:16 ssb Exp $ */
#include php.h
#include php_main.h
@@ -792,6 +792,11 @@
/* functions from versioning.c */
PHP_FE(version_compare,
NULL)
+PHP_FE(version_lt,
NULL)
+PHP_FE(version_le,
NULL)
+PHP_FE(version_gt,
NULL)
+PHP_FE(version_ge,
NULL)
+PHP_FE(version_eq,
NULL)
{NULL, NULL, NULL}
};
--
PHP CVS Mailing List (http://www.php.net/)
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail:
[EMAIL PROTECTED]
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Fw: [PATCH] Fix for inconsistent float-int converting
On Fri, 19 Oct 2001, Stig S. Bakken wrote: In cases like these I think PHP should do whatever C does. There's no point in trying to be clever when casts overflow. In C, when you doe int i;, i will contain random data. In PHP, a variable will always be cleared (to null). In C, when you cast a out-of-range-float, I doubt wether it's defined. Furthermore, PHP is not C, so I see no reason to follow C just like that. What do you expect from trying to store a too big float in an integer? I expect an error, and the nearest valid result. I really see no logic in the current behavior, only that it makes a limited amount of unsigned-int faking possible. But floats are floats, that's not going well all the time (see the numerous bugreports on this kind of gotcha's). So also for this reason I believe there should be no such wrapping behaviour, as it might lead people to think unsigned ints are supported, resulting in very strange things. Especially the E_NOTICE when this happens will help a lot of people IMO. In the case of casting larger integers into smallers, it's differnt because you're talking about _intgers_ then, and not floats. --Jeroen - Stig Jeroen van Wolffelaar wrote: Resent, due to lack of feedback from my side ;) Andi replied: Why is it more correct to convert it to min/max values? I can't think of a case where this would make more sense to the developer. Also, there is a reason for the cast to unsigned int if the value is bigger that LONG_MAX. I think it makes sense. If a float is out-of-range, it can usually not be mod'd by 2**32, due to the nature of floats. Therefore, the only consistent way would be going to the nearest integer possible. Okay, because on most systems floats happen to be more precise than int's, you _can_ mod them by 2**32, but there is a quite significant possibility of having rounding errors. You cannot do integer-precision with floats. And it's inconsistent too, PHP int's are ranging from -2**31 to (2**31)-1, there is no such thing as unsigned integers. So why convert the float 3e9 to something way below zero? Additionally, a notice is a good idea here, just like what happens on division by zero: the most natural result is returned, and a notice is issued. --Jeroen - Original Message - From: Jeroen van Wolffelaar [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, October 02, 2001 2:39 AM Subject: [PATCH] Fix for inconsistent float-int converting When a too-large float is converted to integer, it happens in a quite random way. When float is out of range, PHP should stick to the min resp. max values of integer. This patch will achieve this, I tested it succesfully. --Jeroen Jeroen van Wolffelaar [EMAIL PROTECTED] http://www.A-Eskwadraat.nl/~jeroen Name: double.diff double.diffType: unspecified type (application/octet-stream) Encoding: quoted-printable -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] Jeroen van Wolffelaar [EMAIL PROTECTED] http://www.A-Eskwadraat.nl/~jeroen -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Re: Minor addition to http://php.net/anoncvs.php?
Does anyone object to me modifying the anoncvs.php webpage to include the following note? Does anyone have anything to add - Jeroen? :) There's a typo in it, but that's not what you meant :-) I wouldn't name that SuSE thing, it's way to specific for indicating that something DOESN'T work. I'd just name the combination which _does_ work. I've put a suggestion below, but it's just that -- a suggestion. -- warning para Certain combinations of autoconf, automake and libtool may cause the buildconf script to fail. /para para Under SuSE 7.1 (Linux kernal 2.2.18 i686) autoconf version 2.13, kernal-kernel automake version 1.4 (ok) and libtool version 1.4.2 are suspected not to work. /para I'd say skip the para up here, and in stead: para There seem to be problems with libtool 1.4.2, it is suggested that you use libtool 1.4, along with the most current autoconf and automake. Make sure you install there three tools in the same directory. The following combination is known to work: autoconf 2.52, automake 1.5 and libtool 1.4. /para Feel free to rephrase... para libtool 1.4.2 may not work with any current (as of 2001/09/30) versions of autoconf and automake. /para /warning --Jeroen -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Bug in autoconf report
Hi Jeroen, Did you ever get the problem sorted out? Has anyone encountered the same difficulty? I installed brand new autoconf, automake and libtool into my $HOME. That solved the problem. However, I still don't know what the problem was, probably there were some library files not well installed. Anyway, I'm not the administrator of that computer, so I couldn't do much more than bugging sysop and/or install those tools in my homedir. The former one didn't help, the latter one did. The server I tried on was Debian, and in my original mail you can find the versions I had at that time. Currently, it is: buildconf: checking installation... buildconf: autoconf version 2.52 (ok) buildconf: automake version 1.5 (ok) buildconf: libtool version 1.4 (ok) -- on purpose, read somewhere that some version was giving trouble, so I played on safe. rebuilding Makefile templates --Jeroen I just encountered the same issue in almost the same circumstances. In my case, automake and libtool both live in /usr/bin. % cd php4 % ./buildconf buildconf: checking installation... buildconf: autoconf version 2.13 (ok) buildconf: automake version 1.4 (ok) buildconf: libtool version 1.4.2 (ok) rebuilding Makefile templates rebuilding configure autoconf: Undefined macros: ***BUG in Autoconf--please report*** AC_TRY_DLOPEN_SELF configure.in:162:AC_MSG_RESULT([$PHP_SAPI]) configure.in:182:AC_MSG_RESULT([$php_cv_cc_dashr]) [output truncated for brevity's sake] I am updating all of my Autotools - will try again when that is done. --zak On September 25, 2001 11:53 am, Jeroen van Wolffelaar wrote: On Tue, 25 Sep 2001, Jeroen van Wolffelaar wrote: snip Note: after I solved that warning about automake libtool not being in the same dir, the error remainded the same. (I copied the automake executable to the same dir as the libtool executable) Ok, but it's still a problem with your build tools, it works fine here. You re-ran buildconf I guess? Yes, retrieving the whole CVS again takes quite some time again... what's the command to clean all files that are not from CVS, so that I've got a really clean tree again? make clean / make distclean? (But they don't yet work before you run configure...) So you think libtool is mal-installed? Could be possible... Derick --Jeroen -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Re: zip ext compile problem
Fixed - Original Message - From: Holger Schopohl [EMAIL PROTECTED] Newsgroups: php.dev To: [EMAIL PROTECTED] Sent: Wednesday, September 26, 2001 10:51 AM Subject: zip ext compile problem Hi, in the current cvs tree the zip extension have problems to compile with zziplib 0.10.27 zip.c: In function `zif_zip_entry_open': zip.c:265: parse error before `else' zip.c: At top level: zip.c:266: parse error before `return' zip.c: In function `zif_zip_entry_read': zip.c:290: parse error before `else' zip.c:291: `__l' undeclared (first use in this function) zip.c:291: (Each undeclared identifier is reported only once zip.c:291: for each function it appears in.) zip.c:291: `__s' undeclared (first use in this function) zip.c: At top level: zip.c:291: parse error before `return' Regards, Holger -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug in autoconf report
[jeroen@richard]~/scratch/tmp/php4-cvs ./buildconf buildconf: checking installation... buildconf: autoconf version 2.13 (ok) buildconf: automake version 1.4-p4 (ok) buildconf: libtool version 1.4 (ok) WARNING: automake and libtool are installed in different directories. This may cause aclocal to fail. continuing anyway rebuilding Makefile templates automake: configure.in: installing `Zend/ylwrap' rebuilding configure autoconf: Undefined macros: ***BUG in Autoconf--please report*** AC_TRY_DLOPEN_SELF configure.in:162:AC_MSG_RESULT([$PHP_SAPI]) configure.in:182:AC_MSG_RESULT([$php_cv_cc_dashr]) configure.in:192: AC_MSG_RESULT([$php_cv_cc_rpath]) configure.in:220: AC_DEFINE(HAVE_LIBSOCKET,1,[ ]) ], [ configure.in:238: AC_DEFINE(HAVE_LIBNSL,1,[ ]) ],[ configure.in:241: AC_DEFINE(HAVE_LIBNSL,1,[ ]) ], []) configure.in:267: AC_DEFINE(HAVE_LIBSOCKET,1,[ ]) ], [ configure.in:270: AC_DEFINE(HAVE_LIBRESOLV,1,[ ]) configure.in:363: AC_DEFINE(HAVE_IPV6,1,[Whether you have IPv6 support]) configure.in:437: AC_DEFINE(HAVE_GETADDRINFO,1,[Define if you have the getaddrinfo function]) configure.in:463:dnl AC_MSG_RESULT([$ac_cv_type_in_addr_t]) configure.in:465: AC_DEFINE(in_addr_t, u_int, [ ]) configure.in:528: AC_DEFINE(PHP_SAFE_MODE,1,[ ]) configure.in:530: AC_DEFINE(PHP_SAFE_MODE,0,[ ]) configure.in:540: AC_DEFINE(PHP_SAFE_MODE_EXEC_DIR,/usr/local/php/bin, [ ]) configure.in:541: AC_MSG_RESULT([/usr/local/php/bin]) configure.in:543: AC_DEFINE_UNQUOTED(PHP_SAFE_MODE_EXEC_DIR,$withval, [ ]) configure.in:544: AC_MSG_RESULT([$withval]) configure.in:547: AC_DEFINE(PHP_SAFE_MODE_EXEC_DIR,/usr/local/php/bin, [ ]) configure.in:548: AC_MSG_RESULT([/usr/local/php/bin]) configure.in:551: AC_DEFINE(PHP_SAFE_MODE_EXEC_DIR,/usr/local/php/bin, [ ]) configure.in:552: AC_MSG_RESULT([/usr/local/php/bin]) configure.in:569: AC_DEFINE(PHP_SIGCHILD, 1, [ ]) configure.in:571: AC_DEFINE(PHP_SIGCHILD, 0, [ ]) configure.in:578: AC_DEFINE(MAGIC_QUOTES, 1, [ ]) configure.in:580: AC_DEFINE(MAGIC_QUOTES, 0, [ ]) configure.in:603: AC_DEFINE(DEFAULT_SHORT_OPEN_TAG,1,[ ]) configure.in:605: AC_DEFINE(DEFAULT_SHORT_OPEN_TAG,0,[ ]) configure.in:616:AC_DEFINE(HAVE_DMALLOC,1,[Whether you have dmalloc]) configure.in:629: AC_DEFINE(HAVE_PHP_STREAM, 1, [Whether to use php streams]) configure.in:635: AC_DEFINE(HAVE_CRYPT,1,[ ]) configure.in:655:AC_MSG_RESULT([$PHP_VERSIONING]) configure.in:704: AC_DEFINE(ZTS,1,[ ]) configure.in:817:AC_DEFINE_UNQUOTED(PHP_BUILD_DATE,$PHP_BUILD_DATE,[PHP build date]) configure.in:819:AC_DEFINE_UNQUOTED(PHP_UNAME,$PHP_UNAME,[uname -a output]) configure.in:821:AC_DEFINE_UNQUOTED(PHP_OS,$PHP_OS,[uname output]) configure.in:88:AC_MSG_RESULT([$1.$2 (ok)]) rebuilding acconfig.h rebuilding main/php_config.h.in [jeroen@richard]~/scratch/tmp/php4-cvs Note: after I solved that warning about automake libtool not being in the same dir, the error remainded the same. This is a fresh CVS of 3 minutes ago. When I run configure arterwards: ./configure snip Configuring Zend checking build system type... i686-pc-linux-gnu checking for ld used by GCC... /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... yes checking for BSD-compatible nm... /usr/bin/nm -B updating cache ./config.cache ./ltconfig: ./ltconfig: No such file or directory configure: error: libtool configure failed (indeed, 'ltconfig' doesn't exist) Also note that I didn't ever succesfully build PHP directly from CVS - I didn't have libtool 1.4 till yesterday --Jeroen Jeroen van Wolffelaar [EMAIL PROTECTED] http://www.A-Eskwadraat.nl/~jeroen -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Bug in autoconf report
- Original Message - From: [EMAIL PROTECTED] To: Jeroen van Wolffelaar [EMAIL PROTECTED] Cc: PHP Development List [EMAIL PROTECTED] Sent: Tuesday, September 25, 2001 7:46 PM Subject: Re: [PHP-DEV] Bug in autoconf report On Tue, 25 Sep 2001, Jeroen van Wolffelaar wrote: [jeroen@richard]~/scratch/tmp/php4-cvs ./buildconf buildconf: checking installation... buildconf: autoconf version 2.13 (ok) buildconf: automake version 1.4-p4 (ok) buildconf: libtool version 1.4 (ok) WARNING: automake and libtool are installed in different directories. This may cause aclocal to fail. continuing anyway so don't do that... install them into the same dir. This causes the errors below probably. snip Note: after I solved that warning about automake libtool not being in the same dir, the error remainded the same. (I copied the automake executable to the same dir as the libtool executable) This is a fresh CVS of 3 minutes ago. When I run configure arterwards: ./configure snip Configuring Zend checking build system type... i686-pc-linux-gnu checking for ld used by GCC... /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... yes checking for BSD-compatible nm... /usr/bin/nm -B updating cache ./config.cache ./ltconfig: ./ltconfig: No such file or directory configure: error: libtool configure failed (indeed, 'ltconfig' doesn't exist) Also note that I didn't ever succesfully build PHP directly from CVS - I didn't have libtool 1.4 till yesterday --Jeroen -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Bug in autoconf report
On Tue, 25 Sep 2001, Jeroen van Wolffelaar wrote: snip Note: after I solved that warning about automake libtool not being in the same dir, the error remainded the same. (I copied the automake executable to the same dir as the libtool executable) Ok, but it's still a problem with your build tools, it works fine here. You re-ran buildconf I guess? Yes, retrieving the whole CVS again takes quite some time again... what's the command to clean all files that are not from CVS, so that I've got a really clean tree again? make clean / make distclean? (But they don't yet work before you run configure...) So you think libtool is mal-installed? Could be possible... Derick --Jeroen -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Re: [Zend Engine 2] Re: [PHP-DEV] Fw: Bumping PHP to support 8byteintegers
On Sun, 23 Sep 2001 [EMAIL PROTECTED] wrote: Hey, it's open source, go for it dude. Let us know. :-) I at least wanted to hear wether there are some principial contra's against this, because it would be a waste of time if it turned out that one wouldn't ever think of implementing this. And I didn't know wether this has been thought over before. A major point is of course that it would probably break ALL extensions, unless they use Z_LVAL() macro's all the time in stead of zval.value.lval... I'll see wether I can get it more or less running without too much work... My estimate is that the performance inpact will be not more than a few percents, probably lower. But it's an estimate! On the 32bit environments, 64bit integers are implemented as long long, unless you want to implement the 64bit manipulation routines yourself (yikes.) I didn't plan to implement it myself... yikes indeed. The question was wether all compilers on 32bit platforms DO have long long support at all, in other words: is it true that all compilers for which PHP needs to compile have a C-type which is 64bit (native or not)? --Jeroen Jeroen van Wolffelaar [EMAIL PROTECTED] http://www.A-Eskwadraat.nl/~jeroen -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Re: [Zend Engine 2] Re: [PHP-DEV] Re: [Zend Engine 2] Re: [PHP-DEV]Fw: Bumping PHP to support 8byte integers
On Mon, 24 Sep 2001, Markus Fischer wrote: Hm. You go and figure out and tell us all. :-) Btw, macros should _always_ be used. There is no no ever never a reason not to do so. *waiting for the patch* ;-) Ithink i'm going to try wether it works, and i'll commit my huge findreplace for the macro's... Unsubscribe from php-cvs while you still can ;-) (just kidding... I hope) Jeroen - Markus On Mon, Sep 24, 2001 at 09:13:35AM +0200, Jeroen van Wolffelaar wrote : On Sun, 23 Sep 2001 [EMAIL PROTECTED] wrote: Hey, it's open source, go for it dude. Let us know. :-) I at least wanted to hear wether there are some principial contra's against this, because it would be a waste of time if it turned out that one wouldn't ever think of implementing this. And I didn't know wether this has been thought over before. A major point is of course that it would probably break ALL extensions, unless they use Z_LVAL() macro's all the time in stead of zval.value.lval... I'll see wether I can get it more or less running without too much work... My estimate is that the performance inpact will be not more than a few percents, probably lower. But it's an estimate! On the 32bit environments, 64bit integers are implemented as long long, unless you want to implement the 64bit manipulation routines yourself (yikes.) I didn't plan to implement it myself... yikes indeed. The question was wether all compilers on 32bit platforms DO have long long support at all, in other words: is it true that all compilers for which PHP needs to compile have a C-type which is 64bit (native or not)? --Jeroen Jeroen van Wolffelaar [EMAIL PROTECTED] http://www.A-Eskwadraat.nl/~jeroen -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] Jeroen van Wolffelaar [EMAIL PROTECTED] http://www.A-Eskwadraat.nl/~jeroen -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Re: [Zend Engine 2] Re: [PHP-DEV] Fw: Bumping PHP to support 8byteintegers
On Mon, 24 Sep 2001, Sascha Schumann wrote: `long long´ support has only become recently adopted by compiler vendors. There are still bugs in common implementations like GCC-2 which is why a program which aims at portability should not depend on it yet. I think that IF it is going to be implemented, it should be a compiler option to choose what the type of integer needs to be: long, long long, or something else... With proper use of macro's that would mean 1 single #define. --Jeroen Jeroen van Wolffelaar [EMAIL PROTECTED] http://www.A-Eskwadraat.nl/~jeroen -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Re: Undefining user functions/classes at runtime?
Is it currently possible to undefine user functions or classes at runtime? Although not a newbie ;) I'm unsure if its possible right now. No, you can't do that in PHP-userland (in the C code it can be done, see implementation of create_function). And IMHO that should remain so. If not, will this be support (ZE2) ? I hope not. Can you give an example where you think it will be useful? By the way, I think you can achieve something like this if you really want to with Advices, IMHO another needless feature. What I have against those 2 things is that they can have consequences for existing (library) code, since they call, for example, 'rtrim', and with advices c.q. undef'ing functions you can change that behaviour. --Jeroen -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Fw: Bumping PHP to support 8byte integers
Hi, For a scripting language, integers should IMHO be bounded by a number that will reasonally not be bound by numbers that will be used in normal scripts. That is currently not the case, 4 bytes are insufficient IMHO. Why not make sure PHP uses 8 bytes at least? Or are there platforms not supporting 8byte integers? I believe most popular do... (at least linux on i586 and i686, windows and Solaris (I tested SunOS 5.6)) For implementation, I think that we should introduce p_int and p_float typedefs for php-integer and php-float anyway, and changing THAT isn't a problem. About preformance/memory, I think that's not an issue. Making strings unicode will be much more heavy for PHP... --Jeroen -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Re: [Zend Engine 2] Bumping PHP to support 8byte integers
Hi, For a scripting language, integers should IMHO be bounded by a number that will reasonally not be bound by numbers that will be used in normal scripts. That is currently not the case, 4 bytes are insufficient IMHO. Why not make sure PHP uses 8 bytes at least? Or are there platforms not supporting 8byte integers? I believe most popular do... (at least linux on i586 and i686, windows and Solaris (I tested SunOS 5.6)) An other advantage IMHO is that 64-bit integers can represent any integer that can - in float format - be distinguished from it's neighbour. Recall that C-double == PHP-float have at least 64-bits, so a mantissa of 64bits. So any number n for which n and n+1 are distingwishable in 64-bit floating point numbers, must fall in the range of 64-bit integers. For implementation, I think that we should introduce p_int and p_float typedefs for php-integer and php-float anyway, and changing THAT isn't a problem. About preformance/memory, I think that's not an issue. Making strings unicode will be much more heavy for PHP... --Jeroen -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Re: [Zend Engine 2] Bumping PHP to support 8byte integers
On Sun, 23 Sep 2001, Andi Gutmans wrote: We should check with the MySQL guys what the performance implications are. I remember they had a contest for the fastest longlong2str() function. I guess this was due to performance problems. We should also at least see if this would cause problems with all sorts of standard functions missing for long long such as strtol(). I guess stroll? It works with me. supporting long long's is more than just changing the type in the zval. I do realize that... Most extensions assume the type is 'long', so that needs to be fixed first. No matter how you look at it, it will be big job to do. In PHP performance is IMHO a bit less important than in DBMS's. If you're after performance you shouldn't use a scripting language anyway :). But if this would have a major performance penalty, it's something different... I'll time stroll and strtol to see how much slower it is. Anyway, it would be nice if someone with expericence with changing to 8 byte integers could share his experiences... --Jeroen Andi At 09:13 PM 9/23/2001 +0200, Jeroen van Wolffelaar wrote: Hi, For a scripting language, integers should IMHO be bounded by a number that will reasonally not be bound by numbers that will be used in normal scripts. That is currently not the case, 4 bytes are insufficient IMHO. Why not make sure PHP uses 8 bytes at least? Or are there platforms not supporting 8byte integers? I believe most popular do... (at least linux on i586 and i686, windows and Solaris (I tested SunOS 5.6)) For implementation, I think that we should introduce p_int and p_float typedefs for php-integer and php-float anyway, and changing THAT isn't a problem. About preformance/memory, I think that's not an issue. Making strings unicode will be much more heavy for PHP... --Jeroen Jeroen van Wolffelaar [EMAIL PROTECTED] http://www.A-Eskwadraat.nl/~jeroen -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Fw: Bumping PHP to support 8byte integers
I would be very worried about making numbers 8 bytes by default, unless the CPU supports them natively. There are a lot of consequenses involved with something like that. Assuming a 32 bit register system (x86) integers will no longer fit in registers. This changes EVERYTHING, from passing them to functions, to how arithatic is performed. Nor am I sure what the state of compilers are in all PHP's supported environments, do the compilers handle long long? These are problems indeed, it is just an idea, I don't know what the performance impacts are. Unfortunately it's quite a work to change it, otherwise it's a question of trying it and see what the impact is on typical scripts. For compilers possibly not supporting long long, it's about wether they support 64bit integers. Does someone know how the support of 64bit integers is in compiler-land? --Jeroen -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Re: [Zend Engine 2] Bumping PHP to support 8byte integers (fwd)
This subject is being crossposted to [EMAIL PROTECTED] and [EMAIL PROTECTED] This mail was only on engine2 (let's keep everyting at least on phpdev): -- Forwarded message -- Date: Sun, 23 Sep 2001 22:41:45 +0200 (CEST) From: Jeroen van Wolffelaar [EMAIL PROTECTED] To: Stig Sæther Bakken [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: [Zend Engine 2] Bumping PHP to support 8byte integers On 23 Sep 2001, Stig Sæther Bakken wrote: [Jeroen van Wolffelaar [EMAIL PROTECTED]] Hi, For a scripting language, integers should IMHO be bounded by a number that will reasonally not be bound by numbers that will be used in normal scripts. That is currently not the case, 4 bytes are insufficient IMHO. Why not make sure PHP uses 8 bytes at least? Or are there platforms not supporting 8byte integers? I believe most popular do... (at least linux on i586 and i686, windows and Solaris (I tested SunOS 5.6)) For implementation, I think that we should introduce p_int and p_float typedefs for php-integer and php-float anyway, and changing THAT isn't a problem. About preformance/memory, I think that's not an issue. Making strings unicode will be much more heavy for PHP... I don't know what you had in mind, but replacing long lval with long long lval will increase the size of _every_ zval from 8 to 12 bytes. That's indeed a big issue, since it requires more memory _and_ cpu (more data to move around). zval.value is an union with: (4byte)long lval (8byte)double dval (8byte)struct str (4byte)*ht (8byte)stuct obj So not more cpu time in moving around, since C does not know it doesn't need to copy the last 4 bytes in the union. The size of zval will remain value+type+is_ref+refcount = 8+1+1+2 = 12. - Stig Jeroen van Wolffelaar [EMAIL PROTECTED] http://www.A-Eskwadraat.nl/~jeroen -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Confirmed: False positive in php_ mhash.dll with AntiVir software
FYI, I mailed the authors of that virus program, and they replied the following: - Original Message - From: H+BEDV Datentechnik GmbH [EMAIL PROTECTED] To: Jeroen van Wolffelaar [EMAIL PROTECTED] Sent: Friday, September 21, 2001 11:42 AM Subject: Re: False positive in PHP-distribution Dear Mr. Wolffelaar, thanks for your email. We have a false positiv with this file. With the new update from AntiVir cam not a false positiv. Sorry for the trouble. With kind regards AntiVir Support Team H+BEDV Datentechnik GmbH -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] RE: Bug #13388 Updated: Could not connect to server
How can you determine it is bogus within 2 minutes, please provide your rational. (...) This is probably not a bug ? Are you kidding me ? I hope you are not closing any real nasty bugs because of this reasoning :) From http://www.chiark.greenend.org.uk/~sgtatham/bugs.html Give the programmer some credit for basic intelligence: if the program really didn't work at all, they would probably have noticed. Since they haven't noticed, it must be working for them. Therefore, either you are doing something differently from them, or your environment is different from theirs. They need information; providing this information is the purpose of a bug report. More information is almost always better than less. This isn't really a case of a program not working at all, but somebody coded this feature, and it does work. So you're either doing something wrong, or the cause is in your specific enviroment. Since you're using windows (a popular and widely-used platform, and therefore much tested), Derick guessed - and I think he's right - that you were doing something wrong. To find it out, see the support forums, (http://www.php.net/support.php), because they are there for things like this. If they come to the conclusing this is a bug, you can report it again. --Jeroen -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Time of www.php.net incorrect
I posted a bug-update 5 minutes ago, and from the mail headers: Date: 22 Sep 2001 10:34:57 - It is now GMT/UTC 21 sep 2001 22:30 or something. That means that bugs.php.net is off-time by 12 hours, which is very annoying. (chronology of posts is completely wrong). Can someone please fix this? --Jeroen -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Re: TSRM again
Jeroen, then i have one more question. The real problem im trying to solve is Would some one please answer this question, because this is getting somewhere (mutexs) I don't know much of. And not much is nearly nothing in this case ;-) --Jeroen -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] TSRM coverage question
On Tue, 18 Sep 2001, lo-tek @pb1.pair.com cshmoove wrote:
suppose i have a function which returns a pointer to a variable in
thread
local storage
foo_t *get_global_foo()
{
TSRMLS_FETCH();
return (foo_t *)BAR_G(foo);
}
void fubar()
{
foo_t *foo = get_global_foo();
bar( foo );/* possible multi-thread access */
}
is fubar then thread safe, or is TSRMLS_FETCH() (or TSRMLS_C etc) needed
in
each function needing serialized access to TLS data ?
Well, your just tossing around pointers (your returning a pointer to
an address in the global structure which is assigned to foo, which
you then pass to bar). So thread safety should *not* be affected.
But AFAIK TSRM* do NOT force serialized execution of functions, they just
make sure that each uses a different set of php-globals. So if bar( ) is not
thread-safe, the whole function still won't be thread safe, no matter
whether you use TSRM. It simply depends on the bar( ) function.
I don't know what the solution should be, of course it will be some kind of
locking, but I don't know what would be the best solution.
--Jeroen
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Re: array_sum() needed but not available in 4.0.4 versions..
How can I add the function array_sum() to older php core installations? Grep though the current source with 'array_sum', and add the three things that come up to your 4.0.3-source: a proto in a .h-file, a PHP_FE entry, and the PHP_FUNCTION itself. It should work... but why not simply upgrade? By the way, it is very easy to implement the function in php itself, it's just a bit less efficient than the core-version. --Jeroen -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Rand...
Hi all,
There has been a bit of discussion about rand(). I really appreciate that,
though I would have preferred if it was held BEFORE the changes I (tried to)
make.
Okay, back to business.
By special request, as short as possible:
(I assume you've read the latest proposal, if not, go to
http://www.a-es2.uu.nl/~jeroen/rand/ )
[This part only applies to the controversary part of the proposal, AKA the
'redesign' (which it isn't anymore)]
###Pro's:
* Easier for the user
* All randomness controllable (wasn't the case before).
* The choice-for-algorithm should NOT be to the php-programmer if you're
after random numbers. (this is very important)
* Make it _possible_ to add a real-random-number generator which will be
used by PHP
* Namespace-cleaning: rand, srand, getrandmax, mt_rand, mt_srand,
mt_getrandmax and lcg_value not needed anymore, simply 'random',
'random_set', and possibly 'random_value' for getting a [0,1) float.
###Contra's:
* Slower: not significantly, comparing just-before-jani's-revert and
just-after-jani's-revert, it turns out that the new way is 14 ns slower
(1387ns vs 1373ns). To compare: 1 + 1 takes 712 ns. All this on a quite old
300MHz machine. And the code wasn't optimized at all.
(recall that there go 10 (10^9) nanoseconds in a second)
[I did 10x 1000 (10 x 10^7) experiments, and applied some statistics,
and concluded that the measurement results are accurate to a few
nanoseconds]
* More complicated C-code: True of course, but is that really a reason?
* Leaks, bad coding style, etc: Code wasn't finished yet, of course, that
needs (and will be) fixed, but that's not the issue in this stage
* Don't fix if it isn't broken: This is not a fix. And it 'fixes' the
disadvantages of the current system mentioned in pro's.
### Stop reading here, and comment on these pro's and contra's (especially
if I forgot one). Unless you're really interested, you could read further. A
bit more below, there are some sample scripts.
Other proposed changes are without any objections, and can also be
implemented quite straight-forwardly:
* Easy seeding by user
Sterling recently enhanced srand() to invent a seed by itself. There was
also no discussion about this point.
* Seeding on script startup
There are no objections, so that should be added soon. It is already done
iff you have crypt()
* Thread safe rand()
Can be done, and should be done IMHO. This is no big deal either. 3.3073802
==
Okay, now some examples from practice, why the one way is easier:
php.ini: random_generator = mt
?php // this script uses MT all over:
echo random();
$a = array('a','b','c');
var_dump(shuffle($a)); // uses mt
?
?php // this script uses lcg all over, and will produce same output each
time
// differs from previes script only by first line.
random_set(RAND_LCG, 123);
echo random();
$a = array('a','b','c');
var_dump(shuffle($a));
?
# how to extend:
php.ini:
random_generator = random.org
?php // uses true random numbers
echo random();
$a = array('a','b','c');
var_dump(shuffle($a)); // uses mt
?
php.ini: irrelevant
?php // this script uses MT all over:
// force mt-generation. This is something that shouldn't happen in good
scripts. Which one is the best random-number-generator can only be decided
by system-admin (because could be system-dependent)
ini_set(random_number_generator, mt);
echo random();
$a = array('a','b','c');
var_dump(shuffle($a)); // uses mt
?
===
Currently, you cannot control all randomness, you cannot decide what
algorithm shuffle co should use, you need to change all calls to rand() if
you decide to switch to other algorithm.
Currently there are 3 random number generators in the core of PHP, all are
different and have there specific properties. They should be easily easy to
use, which isn't the case now. lcg for example can't
currently be used well as integer-yielding function.
--Jeroen
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Re: Bug #12690 Updated: array_unique under windows does not work as it does under linux
then why does this work in version 4.0.4 ? It was an implementation side-effect. It was not intentionally. The same issue as that, for example, you can specify a variable violating the naming rules by using: $GLOBALS[0a\n] = Some value; because it would be bad for performance to check for validness of the variable-name, and it isn't easy to do either. Nevertheless you should not trust on this capability: It could change in the future. See also bug 12367, the comments by [EMAIL PROTECTED] --Jeroen -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Re: Note added to rand
Note added by joey, text: My vote: +0 Suggestions/remarks: I'll take the proposal one piece at a time: Good idea :-) float random() / int random(min, max): If I understand correctly, the only way you'll know what kind of return the user is expecting is by counting args. That means if I just want a random number between LONG_MIN and LONG_MAX (what I expect *most* users of a random fuction are looking for), I have to use the longer format of random(min, max). This seems counter-intuitive... The most commonly used version should be the easiest to type. I'd rather see another function entirely for floats. O yes... oversight, indeed. It was a quick idea which I typed in... indeed, a separate function would be better. I thought that you should always give a range because it otherwise makes no sense. But indeed, LONG_MIN ... LONG_MAX does make sense. set_random(): This seems to be to go out of it's way to bring things back to the way they currently are. If they want to change the algorithm, and the algorithm is decided via an ini switch, they can use ini_set/ini_alter(). The primary goal here is to make it possible through a single function call to obtain a random number, is it not? Let random() seed itself. I wasn't clear. Usually, you do NOT call set_random(), indeed, ini-set is the way it is supposed to be. The only circumstance where you need set_random is when you want a specific seedalgorithm, for example while debugging, place it at the top of the script and you'll get identical numbers each call. There is a good idea here, IMHO, and that is to reduce the namespace by wrapping all possible PRNG's with a very thin wrapper, but I don't see any need to break BC or make this wrapper any fatter than it needs to be to serve the purpose. I'll return to this and the rest later, I need to go now, I'm supposed to assist in a workgroup... --Jeroen I'd rather see: new ini switch: rand_algoritm, defaults to mt. (I still think that mt is probably the best for most people, but I know that some people disagree...) new function: int random() : The same as if user called the desired rand() algoritm from user-space, with the added benefit of insuring that a sufficently unique seed has been provided first. I don't see a need for any of the rest of this, but I have said before that I'm really not very good at evaluating things from a Design point of view...I'm much better at evaluating implementations to judge how well the *fit* the proposed design. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Re: Note added to rand
No number is truly random. That is the nature of computers. You can only generate a sequence of numbers, based on a seed. True (of course, I knew that already long ago...), but 1) You can obscure that by using time-varying seeds in order to get seemingly random numbers 2) You can resort to lavalamps, radiosources, monitoring mousemovements/keystrokes, etc etc My god, this is generating a random number, its nothing that complex, so lets not make it such. And, btw, if you want to use lcg, just use the lcg_value() function. Creating a language that is easy to use is very complex. It is very easy to create a language that is hard to use. That was and is my whole point. lcg_value() is another strange duck in the bite: it seeds itself automatically on startup, you cannot seed it yourself, and you can only get it to return rand() / RANDAX, not a integer range (the alg. returns integers!) We don't need PHP to support 15 different algorithms for generating random numbers, if you want that, move it into a php extension, but it doesn't belong in the core. But IMHO the interface needs to me facilitated in the core, otherwise you can't use other RNG's like you can use the core ones. There are 3 different RNG currently in the core! My proposal reduces the namespace-load to PHP to 2: random and set_random. If you want random numbers, you only have one function: random. If you place set_random at the top of any script, you will see that it garantees that the script will act identically on each call, because set_random controls all random! IMHO the power of PHP is it's intuitiveness in using it, and I don't think mt_srand(); mt_rand() is intuitive. Really, then why hasn't anyone complained as of yet? And this is the way it is done in other languages as well (C, Perl, Python). Why change what's working? If you really want, create a new extension, distributed externally, just like Perl has the Math::TrulyRandom module. Most people don't realize it is unnecessarily cumbersome. If you look at newbies code, you see they make all kind of mistakes in it, which would IMHO be reduced if it becomes simpler. Please understand me right, I find it very useful to have someone critically look at my proposal, but please be more specific. Right, those more specific comments belong on list :) I didn't Cc to php-dev, since I could be breaking the law... but you may forward this mail to it :-) I am. ;) -Sterling --Jeroen -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Re: [Zend Engine 2] Right/Left Shift Zero Fill operator
Is there anyone out there who uses on negative numbers? There is the discussion on the engine2 list about whether to make an unsigned right shift, or to introduce a new operator . In my opinion, and should consider integers as a row of bits, thus do not treat the msb differently... I believe you call it shifting unsigned longs? You shouldn't use and for arithmetic, no 'quick' division by 2 etc... --Jeroen -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Re: [Zend Engine 2] Re: [PHP-DEV] Re: [Zend Engine 2] Right/Left Shift Zero Fill operator
FWIW: Signed shift seems to make little sense to me personally, since we are just dealing with a row of bits, and if you really want to do a quick multiplication/division, you might just as well use a * or / operator - it is not going to hurt that much:). I completely agree *However*, it's been possible in different languages since before I had my first computer (e.g. SHL/SHR and SAL/SAR in asm x86), so we might provide the same functionality and create a new operator to discriminate between signed and unsigned shifts.Just a thought. Don't kill me if that would be polluting the language. IMHO: If other languages have strange things, I don't see why PHP should take it over... Don't copy bad operators! But... currently, how does PHP handle this? I'm afraid the wrong way? --Jeroen -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Re: Note added to rand
People interested in rand can still visit http://www.A-Eskwadraat.nl/~jeroen/rand , but if you have something interesting to say you can of course also mail to php-dev! World Wide Web Cie [EMAIL PROTECTED] wrote: Note added by jmoore: My vote: ±1 :) Suggestions/remarks: I think that PHP should provide a nicer more intuative random number system, who wants to have to give a shit about seeding a random number generator etc, I think we should still leave mt_* and *rand() in place as for C programmers they brhave the way we expect which makes our lives easier as we dont have to think but for non C programmers a no brain random() function would be nice. I think that somthing should be done but I am unsure if your proposal is the best way to do it.. Ill try to think of somthing and add to this and then perhaps we can get a better discussion about this whole thing. /quote I like the suggestion to keep rand and srand in place for people used to it. If you want to do it the hard way, why not give them the possibility? I'm not sure wether this is valid for mt_rand etc too, but why not... they will stay for a while anyway because of BC. Keep me posted if you think of something else! --Jeroen -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] About the Rand Merge: apologoy how further?
Stig wrote: Wow. :) [[EMAIL PROTECTED]] (...) I'll keep it short. You were referring to this? Yes, I realized it after I sended it... I (obviously) wrote that before I finished the mail... Jeroen -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Woah
At 01:24 09-09-01, Jeroen van Wolffelaar wrote: Exactly the same goes for ?= unless you happen to stumble across the one-line footnote on the php.net/echo page. So that's a documentation bug. It clearly belongs in the documentation about PHP's various special tags, just next to ?php, ?, %, %= script language=php, etc. There's a logical place to look for that entry. FYI, 'I' added ?= on May 10th to the documentation along with the rest of ?php etc, because I noticed it wasn't there... Cool. Hm, what I wrote was somewhat ambigious, I meant to say that I added ?= on the place where the other variants were already present. So I added JUST ?=, NOT the others. I don't know wether you understood me wrong, but just to be sure... --Jeroen -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Re: php4 /ext/standard rand.c
sterling Wed Sep 5 16:52:45 2001 EDT Modified files: /php4/ext/standard rand.c Log: a bit of api cleanup... move range stuff into a macro (properly :) Yeah yeah... I know by now... +#define RAND_RANGE(__n, __min, __max) \ + (__min) + (int)((double)(__max) - (__min) + 1.0) * ((__n) / (PHP_RAND_MAX + 1.0)) + [in PHP_FUNCTION(rand)] + number = RAND_RANGE(number, Z_LVAL_PP(min), Z_LVAL_PP(max)); } [in PHP_FUNCTION(mt_rand)] + number = RAND_RANGE(number, Z_LVAL_PP(min), Z_LVAL_PP(max)); } PHP_RAND_MAX is only valid for rand, not for mt_rand. mt_rand has MT_RAND_MAX, which could be different (not on most common builds, but on some platforms it is). --Jeroen -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Apology
I'm very sorry for whatever I wrote yesterday, I happend to got a quite drunk because of the closing of the introduction. I shouldn't have gone online in that state. I now redraw whatever I said, because I'm afraid it wasn't all that neat. For today I'm not going to write anything either, since our physics department happend to celebrate the beginning of the new academic year by means of a free 'borrel', with beerwine for nothing... Regards, --Jeroen -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Re: The rand() can of worms
I *NEVER* have anything to say until I have seen the code. Otherwise, it's just a bunch of castles in the air. Okay, that's a point. That is not the custom where I learnwork, actually, there is a saying that design planning is 67% of the job, implementing just 33%. That is if you want a good stable code. (I know, that seems to contradict, but just read on). But, I got no comments at all (except the first time one by Rasmus) on the design. The fact wether something compiles, and how quick it is, is simply irrelevant until the final stage, but people don't seem to agree with me on that point. Compile run is a typical Microsoft approach to programming. In the ideal situation a program won't compile until it is finished, and I'm fine with that. Everybody seems to fall about compile issues and performance problems and leaks. Except for performance problems, which are often related to design, this should have been irrelevant for the discussion (well, not about wether it should already have been merged, but about wether this is the way to go.) And about design, I haven't been given opportunity to discuss about it. I made the mistake to merge it, I shouldn't have done that. But to me it *seemed* the only way to start a discussion. I was really hungry for feedback, which wasn't coming. Apperently because a lot of people go for that compilerun, and discuss afterwards strategy, which is at my place considered the sub-university way of programming. patch that is in such a sorry state by mergeing it to HEAD. Let me know when it is *STABLE*, when it will compile on my machine, and run with a That is the point I make here, I wanted to discuss about the strategy and design. You did have quite some comments on it, and I am of course listening to them. But I didn't get the chance to act according to your remarks/suggestings, rather, it is reverted. Of course, I know now that you really want to have a stable HEAD. But I asked a lot of times to give me feedback on that and other issues, and Zeev even suggested to commit my initial work straight to HEAD. But please you should have let me know that that is an issue with most of you, I only had Zeev's mails as reference, and apperently a lot of people have different feeling about it (or I really misunderstood him of course). --Jeroen PS: it's too much to read all now, so it'll take another day (or two?) before I can get to reply to other mails. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Fw: [PHP-CVS] cvs: php4 /ext/standard rand_mt.c rand_sys.c
News posts seem to be broken, this is a resent: - Original Message - From: [EMAIL PROTECTED] Newsgroups: php.cvs Sent: Thursday, September 06, 2001 12:03 AM Subject: Re: [PHP-CVS] cvs: php4 /ext/standard rand_mt.c rand_sys.c Andrei Zmievski [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED]... On Wed, 05 Sep 2001, Jeroen van Wolffelaar wrote: Just look at the algorithm and you'll see at once it is bogus. Only in the special case that one single key is requested it is correct. Proving it's bogus is trivial, so I'll leave that as an exercise to the reader (I'm serious). There are about 2**31 possibilities for randval. So already when picking 13 elements out of an array, (which can be done in 13! ways), some possibilities are not even possible! Furthermore, it makes simply no sense, just look at the key point, every time r/R, where r and R decrease... that has a really high preference for 'neat' distributions. --Jeroen A little less patronizing, please. I'm very sorry, but this again is an example of simply test things out without reasoning/thinking/proving. Which is IMO very bad. If you simply think about the algorithm, I'm sure you would have seen immediately what was wrong. I must say I didn't do any testing at all with that function, but that's not necessary! -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Fw: The rand() can of worms
Resent - Original Message - From: [EMAIL PROTECTED] Newsgroups: php.dev Sent: Wednesday, September 05, 2001 11:21 PM Subject: Re: The rand() can of worms Bad points: 1) Leaks 2) Inconsistent style 3) Really bizzare macros, etc. Let's put one thing straigt: I merged it already in this early stage (I KNEW it wasn't yet the way it should be, for example the macro thingy: It started out as 2line-macro's, but went bigger. In the optimization and reflection stage, I certainly whould have converted it to a function, but that stage wasn't yet reached) because I thought I would FINALLY ** get comments on the whole thing (AND NOT ABOUT THE PRECISE IMPLEMENTATION, SINCE I STATED VERY CLEARLY THAT WAS NOT YET WHERE YOU NEEDED TO PAY ATTENTION TO). Maybe you don't understand my way of coding (emphasis on CORRECTNESS, the rest comes in later stages). In fact I was REALLY in fast-coding mode because I wanted to commit/merge it before the big part of that introduction I was co-organising. I thought you would be able to discuss it, so after I had time again, I could react to it (in fact, I even doubted wether I got any reactions, since you all didn't seem to care about rand()). I really dislike the way you are handling with this issue: first silently agree, and when nearly FINISHED, go do difficult. In the Netherlads we have a word for this kind of people, but I'm not going to write it down here... --jeroen (still very angry) -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Rand
PS: Egon, go read my reply when you asked that the first time. Wasn't I clear? It was in plain English though... I have only asked you, why have you deleted the comments. It was in my mail: - I DID NOT REMOVE THEM Ich habe den nicht weggeholt!!! I just MOVED them. That was already in my first reply. See rand_mt.c. --Jeroen -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Bug #12841: ++, -- operators does not conert the typeof variable.
Please commit it, I don't know what exactly it was, but I didn't yet find the time for it... jeroen On Tue, 4 Sep 2001, Stanislav Malyshev wrote: From: [EMAIL PROTECTED] Operating system: FreeBSD 4.3 PHP version: 4.0.6 PHP Bug Type: Scripting Engine problem Bug description: ++, -- operators does not conert the type of variable. The attached patch should cure it. jeroen, are you on it or should I commit this patch? Jeroen van Wolffelaar [EMAIL PROTECTED] http://www.A-Eskwadraat.nl/~jeroen -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Bug #13094 Updated: Upload very slow
I think the problem is the fact that we read all of the file into Memory
That seems like a bad idea to me... it doesn't get in PHP directly, only
after specific request. So you mean that PHP read's the whole file, than
writes it to /tmp (or c:\temp), and then clears the memory again?
If that's the case, that should be fixed IMO, there's no need for buffering
like this.
Marcel: Monitor your RAM used by the webserver, by means of ctrl+alt+del, T,
second tab. If it swaps, that's the problem.
--Jeroen
(and therefore probably swap). I couldn't see any erealloc()'s in the code
so I'd bet on the former problem. Maybe ASP writes out the file while it's
arriving.
Anyone have any ideas?
Andi
At 03:17 PM 9/2/2001 +, [EMAIL PROTECTED] wrote:
ID: 13094
Updated by: jeroen
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: Performance problem
Operating System: Windows 2000
PHP Version: 4.0.6
New Comment:
Seems duplicate of 2291, but that one should be fixed in 4.0.6
Previous Comments:
[2001-09-02 07:34:53] [EMAIL PROTECTED]
?php
if(is_uploaded_file($userfile))
{
$FileNameAdd =
$FileName; file://Prefix
for
filename using uniqid();
$FileNameAddDB =
$DBFileName; file://Including prefix used for
database
$filename =
$HTTP_POST_FILES['userfile']['name']; file://Filename as selected
by user
$FileExt = substr(strrchr($filename, .), 1);
if(array_search($FileExt, $Extensions) == FALSE)
{
?
font class=warningNot allowed to upload this
file./font
?php
exit();
}
$DBFileSize = $HTTP_POST_FILES['userfile']['size'];
$DBFileName = $FileNameAddDB.$filename;
move_uploaded_file($userfile, $Mapping .
$FileNameAdd.$filename);
?
Didn't compile anything just use the compiled version as download from
website.
When I upload a file bigger than 10 MB, it takes a very long time (if it
uploads) I adjusted all the needed variables in php.ini.
I'm using it for files (150MB) over a Lan network.
I've tried a ASP uploader and it does the same file in less then three
minutes. PHP was working for 30 minutes and still wasn't done.
I think this is a bug in the code.
Marcel van Leeuwen
Netherlands
Edit this bug report at http://bugs.php.net/?id=13094edit=1
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] [C] struct, function pointers question
Hi,
I'm sure there's some simple (stupid?) error, which an experienced
C-programmer can see immediately... But I don't.
You're missing a variable name (you only put a type), and the line is not
in the beginning of a code block (there's a statement before it).
php_randgen_entry is (supposed to be) a type.
php_randgen_entries is (supposed to be) a variable.
php_randgen_entries[3] = { ... };
is (supposed to be) a statement.
I'm still not seeing what's wrong...
Zeev
--jeroen
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] RAND_REDIGN
Also, I ask again: Why didn't you just add new function random() instead of changing all this and breaking BC. I DID NOT BREAK BC. Sorry, but this has been discussed dozens of times... --jeroen -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Re: [PHP-CVS] cvs: php4 / NEWS
I was waiting for you to tell that now the branch works and I could test it and say 'good, this works you can merge'. I'm sure everybody else waited for same. You do NOT need the implementation to know how it is going to be. I explained that multiple times, and everybody (though silently) agreed. I'm not going to revert this simply because someone first lets someone else work quite a time on this change before telling it isn't like he want's to see it (and *yes* I'm angry, and *yes* I'm talking to someone in particular). --jeroen -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Re: [PHP-CVS] cvs: php4 / NEWS
(and *yes* I'm angry, and *yes* I'm talking to someone in particular). And I'm now going to sleep before it gets worse. Good night, Jeroen -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] [PATCH] Fix for 12245
See attachment. I tested it, and I'm sure it works. --jeroen fix_for_12245.diff -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] How to make Thread Safety work (ZTS,TSRMLS) (was: Re: [PHP-CVS] cvs: php4 /main streams.c )
[Changed subject, I missed this thread until now because of it...]
I assume this difference between 12 and 3 is _strictly_ performance, and
_nothing_ else?
And a note for others: You don't need TSRML* in every function, but you do
need it if you use:
- Global variables, like BG(...) co.
- Use a function which is declared TSRMLS_C[C] in your function
- more?
Greetz,
Jeroen
Zeev Suraski [EMAIL PROTECTED] wrote in message
news:5.1.0.14.2.20010826123513.03102660@localhost...
The thread safety macros pass around a context that the rest of the thread
safety macros use. There are three types of such macros:
1. Macros that are used in function declarations, to denote that the
function accepts this context as an argument:
TSRMLS_D - if it's the only argument (Thread Safe Resource Manager
Local Storage, Declaration)
TSRMLS_DC - if it's not the only argument (Thread Safe Resource
Manager Local Storage, Declaration with Comma)
2. Macros that are used in function calls, to pass the context to
functions that accept it:
TSRMLS_C - if it's the only argument (Thread Safe Resource Manager
Local Storage, Call)
TSRMLS_CC - if it's not the only argument (Thread Safe Resource
Manager Local Storage, Call with Comma)
3. If the context cannot be passed using function arguments (e.g., in
certain callbacks), it can be obtained by calling TSRMLS_FETCH() at the
end of the variable declarations (Thread Safe Resource Manager Local
Storage Fetch)
For performance reasons, using 1+2 is usually preferred to using 3.
Zeev
At 12:07 26-08-01, Joey Smith wrote:
I really don't understand the thread-safety stuff, but shouldn't this
also be using TSRMLS_CC instead of TSRMLS_FETCH()?
- TSRMLS_FETCH();
-
/* these names depend on the values of the
PHP_STREAM_AS_XXX defines in php_streams.h */
static const char * cast_names[3] = {
STDIO FILE*, File Descriptor, Socket
Descriptor
};
+ TSRMLS_FETCH();
+
zend_error(E_WARNING, %s(): cannot represent a stream
of
type %s as a %s,
get_active_function_name(TSRMLS_C),
stream-ops-label,
--
PHP CVS Mailing List (http://www.php.net/)
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
--
Zeev Suraski [EMAIL PROTECTED]
CTO co-founder, Zend Technologies Ltd. http://www.zend.com/
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Re: [PHP-CVS] cvs: php4 / php.ini-dist php.ini-recommended
Better question is, do we really want to do this? This doesn't fix anything. It only breaks things. Second, this will make writing portable scripts harder. Yet another ini setting to be checked for.. No! PLEASE read my propasal, this is a WRONG assumption. Even better: IF wou want a portable script based on this idea's, it can now be done easily and portable, AND via a logic way. The only good way of doing this rand() - mt_rand() change would have been my way (tm) which was rejected. ie. using the mt_* always. Apparently some people really want to have the ability to call system rand... indeed a bad idea, I agree, but if ppl want it, why deny them the possibility? (at their own risk, of course) --Jani -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Re: [PHP-CVS] cvs: php4 / php.ini-dist php.ini-recommended
+; Default random number generator. Specify here which random number generator +; you want to use for the PHP-rand() function. Usually MT (Mersenne Twister, +; see http://www.php.net/manual/en/function.mt-rand.php) is the best choice. +; It is thread-safe, fast, and, quite important, mod and divide-free. +; Possible values are 'system', 'mt' and 'lcg' +random_number_generator = mt shouldn't the default be the backward compatible one? Yes, and if you would have read my proposal, you would know that this ini-setting is irrelevant for BC-issues. I even doubt wether it'd be such a problem anyway: who wants to use the predicability of rand(), which is always bad anyways? (non-thread safe, unknown by which other functions it is used, and system-dependent). And who does want to use that, uses (1) an undocumented feature, and (2) generally knows what he's doing, and is a bit aware of PHP-internals, and probably knows about this changed when it is in NEWS. I am working of a perspective of a not-so-expert user, who uses rand() for what it says: random numbers. THAT use of it should be as easy as possible, without 'seeding' (WTF, most new users would say?, why is that needed?) tc Jeroen -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] pif
What's wrong with php_ prefix? Nothing. It is just the same prefix as for PHPAPI functions, and the purpose was to diffentiate in the name between helper functions and API-functions. But starting it with an underscore is also a good way of achieving that, on second thought. -Andrei Jeroen -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] pif
I'm against that. Usually underscore-prefixed symbols are used by system libraries and OS and we don't need to go in that direction. I'm also against using pif_, because it's not an internal function that you are naming, but rather, a helper one. I don't really have an opinion on this matter, I just wanted to know what to do. So you are suggesting to simply stick with php_ prefix and not doing anything else? Then I'll comply with that. In math.c, I saw that use of underscore as first letter, so that is not according to how it should be done, I assume. Thanks for clearing this up, Jeroen -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] pif
At 23:09 22-08-01, Andrei Zmievski wrote: On Wed, 22 Aug 2001, Zeev Suraski wrote: How about phf_, for PHP Helper Function? I see a point in differentiating language level API functions (e.g. like output buffering) and module-specific helper functions (e.g., like php_mysql_do_connect()). Explain what the point is, then. I would assume that functions like php_mysql_do_connect() are scoped statically, so it shouldn't be a big deal that they have php_ prefix. It's not about possible symbol clashes... Indeed, even when possible no two functions should have the same tail after the prefix. When debugging (or when reading code), it helps to know what's a part of the API and what isn't. It also makes different types of prefix-based searching (e.g., gdb's completion, or emacs' search feature) a bit easier. Is it a big deal? No, but it can be useful and has no real drawbacks. In my case, it is useful IMHO. Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Branching ext/standard?
At 23:37 22-08-01, [EMAIL PROTECTED] wrote: Hi, I've got an experimental beginning of the new rand functions ready. I think it's good if others can comment on it before it is finished, because the course can be changed now quite easily, but when it's all done, I don't feel much about doing that... Do you need the branch the whole directory? It involves basic_func*, *math*, *rand* and *array* files (* are wildcards, not exclamation markings) files. And of course Makefile too. And probably some others too. That makes quite a significant portion of that directory. It is way much easier to branch the whole dir... We usually (read: always) don't use branches for development, i.e., we don't use branches that are planned to eventually merge in. That's because CVS's branch handling leaves a lot to be desired... It may be ok in this case, where the chances of somebody else committing something that would clash with your changes are very slim, but I think you're better off branching just the file or couple of files which you're modifying. Currently it only compiles as non-ZTS, Linux stand-alone executable, and not much else, definitely not windows, ZTS, and as module. This will remain so for quite a time, I guess. That means that the main branch will be broken for those situations for quite a time, and I don't think that's a good idea. So, should I branch ext/standard under the name 'EXPERIMENTAL', or 'RAND_CHANGE', or something else? EXPERIMENTAL is way too general to be good for such a purpose... I'd try and use a fairly descriptive name, which is unlikely to be used again in the future. Eh, RAND_REDESIGN then? Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Branching ext/standard?
If it's such a far reaching change, I suggest you simply send the diff the php-dev. It should be enough to be a basis for a discussion on the proposed changes. If we decide to go through with it, it should be At this time, it's merely a big move-around with code, no single thing of functionality has been changed, though you can see already how it will be implemented. committed to the main branch, and fixed so that it would work everywhere (or find a working solution to keep the tree in a working state). Branching away for long periods in the hope of merging back in is not a good idea. The merging was not the reason: ext/standard is - what rand concerns - quite silent, so that's really a non-issue. I was hoping for a bit of concurrent development, with someone with more ZTS knowledge then myself. This won't happen if I merely send in the diffs. I notice that second propal didn't get any reactions, even after repeated personal mails (hint...). Therefore, I don't have much hope that it yields any useful comment. However, if I change in CVS - even if it is a branch - I touch the holy body of PHP, and people will look at it. It also has more historical importance, changes are logged more carefully, for future reference. Mailing list archives are not useful to use as reference. Simply committing at once with: rewrite everything that has to do with rand won't be any useful. 80% of the diff is the moving of code, and only 20% the real change. You also don't see what changed. Just as bad as mixing WS fixes with real fixes. And about time-span: I guess it - for working in one (my) situation a few weeks at most, and another week for getting it to compile with ZTS etc, totalling about a month or so. Greetz, Jeroen Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Branching ext/standard?
What I would do in your case is: (a) Tag the relevant files as they are today (i.e., PRE_RAND_REDESIGN or whatever) (b) Commit your move-around changes (c) Commit the real changes (can be done immediately after (b), as long as it's separate) The real changes are not ready... and I didn't want to start with it until I know the move-around is okay, since I don't like to work for nothing. I'll commit the move-around changes then, but it will be broken, maybe even normal build, because it is EXPERMENTAL, and I didn't do much testing, it is simply not ready, it's about the idea. (d) Cross your fingers :) I know who to blaim if ppl complain about a broken CVS ;-) I'll do this in 10 minutes unless you change your mind... Thanks for the advice, Jeroen PS: having the tree broken for a few hours or even a couple of days under the This quite optimistic! -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Branching ext/standard?
(a) Tag the relevant files as they are today (i.e., PRE_RAND_REDESIGN or whatever) (b) Commit your move-around changes I really think a lot of people will set ext/standard to PRE_RAND_REDESIGN then, because they want to work on other parts, and don't want a broken build. That's the other way around, a branch would be more logic... Jeroen -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] RAND_REDESIGN branched
Execute - in ext/standard: cvs update -rRAND_REDESIGN Makefile.in php_rand.h php_math.h rand.c rand_mt.c crypt.c And check it out... (I didn't branch whole ext/standard, so it's needed to name the necessary files... sorry) Jeroen -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Re: RAND_REDESIGN branched
Execute - in ext/standard: cvs update -rRAND_REDESIGN Makefile.in php_rand.h php_math.h rand.c rand_mt.c crypt.c Update: changed my mind, and branched whole ext/standard. It seems that it doesn't cause any overhead or whatever. So % cvs update -rRAND_REDESIGN ext/standard will do. --Jeroen -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] pif
Zeev Suraski [EMAIL PROTECTED] wrote in message 5.1.0.14.2.20010822013439.02e0c498@localhost">news:5.1.0.14.2.20010822013439.02e0c498@localhost... At 23:14 21-08-01, [EMAIL PROTECTED] wrote: What about using the pif_ prefix for php's internal functions, analogously to zif? This makes them more clear than the simple lack of PHP_API macro. This sentence does not compute :) Damn, forgotten to dequeue this mail :( anyway, I was thinking about helper-functions, which you only want to use straight from an other function. Mostly this will be the set of functions which are not PHP_FUNCTION or PHP_API. A example in math.c: _php_math_number_format - pif_math_number_format I was going to add some to rand.c. For example: pif_randmax_mt(), only used by the php-api function php_randmax(). (the pif-function is in this case a macro - bad example, but anyway...) Which functions are you talking about, and how does PHPAPI relate to them? Zeev Jeroen -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] chroot(): _not_ safe-mode restricted?
As I read it in CVS, chroot() will work even in safe-mode. Isn't this a bad idea(tm), or am I wrong? If users can chroot in safe-mode, Apache won't serve any more pages after all children have been chrooted to an empty dir? uhm, where have you read that? [ curious ] I just reasoned what could happen. if you chroot a child, I couldn't see a reason why it'd get respawned (since it doesn't die), but it will become a useless child, I guessed. nope, cause it will run as apache user, and you have to be root to chroot(). I believe there are webservers which are run as root, or not? If that is the case, chroot should be disabled in safe-mode IMHO, or better, disabled in webserver envirment. Currently the docs say that it is not *wise* to use it in webserver-env, not that is impossible. That's why I questioned safe-mode restrictions here. -- teodor Jeroen -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] RFC: rand() change, second try
Hi, [Impact and relevance: all functions that use randomness (including array_shuffleco)] After the previous discussion, I've been thinking, and I think I've got a way which has only a neglectible BC problem (unlike my first proposal), while still keeping the following in mind: Probably 99% or more people who use rand() co, simply want as random numbers as possible. In _this_ context, you can say that algorithms are exchangable. Most people don't know/don't want to know about seeding pseudo-random-generators, which algorithms to use, and that kind of stuff, they simply want random numbers. For the 1% people that want to exploit the property that you get the same random numbers after feeding the same seed, _do_ know about that. This proposal has these advantages: - Technical and syntactical possibility to add other sources of randomness: real random numbers (by means of device or internet-source)/other algorithms. No new functions needed in such cases. - Very easy to work with random numbers, this allows quick and easy coding with randomness without needing to worry about how random it is: PHP takes care of it, tunable by ini-entries. - Usually no need for srand(). - Still regression tests possible, with more relevant syntax - Seeding specific numbers and the choice of algorithm also influence functions like array_shuffle. - ? Disadvantages: - Minor break of BC, only if you AND expect a certain number after a certain seed AND you use various random-based functions through eachother. - A very small extra startuptime for each script-execution - Mixed use of algorithms a bit troublesome (no problem in case of serial mixed use) - ? Below I give some examples in stead of some technical explaination. Please let me know what you think of it, Jeroen -- I think I can illustrate my proposal best with some examples: [note: simplified sometimes, it's about functionality, not implementation] = [ini] random_generator = algorithm-x ; typical 'mt' (default) // for simply random numbers: ?php file://seed the random number generator algorithm-x with a 'random' seed (1e6*microtime()) srand(); // (no parameters) echo rand(); // use algorithm-x ? // for simply random numbers: !- on script start, implicit call to srand() (noargs) - ?php echo rand(); // use algorithm-x ? These two previous scripts are equivalent with: algx_srand( (float) microtime() * 1e6); agx_rand(); // for a specific seed: ?php // state that you want to use MT with seed 1234 in all next calls to any random function srand(1234, RAND_MT ); echo rand(1,6); // throw with a dice, using mt. shuffle($array); // this also is affected ? // mixed ?php // state that you want to use the system rand() with seed 1234 in all next calls to any random function srand(1234, RAND_SYSTEM ); echo rand(1,6); // throw with a dice, using system rand(). shuffle($array); // this also is affected srand(); // back to default behaviour echo rand(1,6); // algx, seeded with 1e6*microtime() on previous line ? // also impact on other random functions ?php srand(456, RAND_MT ); array_shuffle($array); // This shuffles the same way each time! ? == If you seed a specific seed, that's possible, but you need to specify the algorithm. (which can be extended!). This is simply because it wouldn't make much sense otherwise. Calling srand() (no-args) while a real-random source is selected, will have no effect. [mt_]srand($arg1) with one argument is deprecated. mt_* are aliasses for their equivelents, so no double set of functions anymore. In PHP 5, all this deprecated stuff should be removed. == // BC: goes OK srand(123); // equivalent to: srand(123,RAND_SYSTEM); echo rand(); == // BC: goes OK mt_srand(321); // equivalent to: srand(321,RAND_MT); echo mt_rand(); // alias of rand() == // BC: changed behaviour, but this is extremely unlikely // You don't mix up mt and system rand... mt_srand(321); // equivalent to: srand(321,RAND_MT); echo rand(); // will use MT, seeded with 321 srand(123); // equivalent to: srand(123,RAND_SYSTEM); echo mt_rand(); // will use SYSTEM, seeded with 123 == // BC: changed behaviour, but this is extremely unlikely mt_srand(321); // equivalent to: srand(321,RAND_MT); array_shuffle($array); // will eat up some random numbers echo mt_rand(); // not the first in the batch, since they have been eaten up == -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Setting up RFC
Hi,
About a month ago there was a discussion on the Engine 2 mailing list, about
a possible RFC-proces for the more imporant PHP-issues. In the end, there
was some consensus that it would be good if such a system exists.
I'm simply writing to get some comments, to hear what the general opinion
is. If that is not negative, I think it should be tried to set it up.
About the details, there needs to be discussion of course, but it would be
more efficient to discuss those things after a proposal has been made, in
stead of construct such a proposal by discussion.
Joey Smith and Zak Great supported the idea on the list, but the discussion
went dead. Below I quote some of their mails.
Regards,
Jeroen
Joey Smith wrote:
Actually, I felt that the Perl 6 design process had a fairly good idea
that was poorly implemented...that of RFC's. Anyone who wants to sponsor
a feature compiles an RFC on it, and is resposible for keeping track of
the discussion on it, and occasionally rolling the comments back into a
new revision of the RFC.
What do you guys think of something like this? We could even mark
certain RFC's as Dead for now, or something like, so that we can kill
threads such as {}, and anyone who doubts the deadness of the thread
can check the status of the RFC before commenting.
One potential risk I see with this approach: Someone sponsors a certain
RFC, goes through much time and trouble to track and merge discussion,
only to have it killed somewhere down the road by the others. This
could possibly lead to the kinds of flare-ups that occur from
time-to-time on php-dev...
Zak wrote:
That sounds like a very good idea. We spend a good deal of time going
around.
The RFC process should have a series of significant benefits:
a.) Less digging through old mail to figure out what was said
b.) The sponsor must be serious
c.) The process of writing an RFC will encourage the sponsor to consider
the
feature more carefully
d.) The RFCs will provide a form that can easily be archived.
--zak
Zak wrote again:
Has anyone else had a chance to think about this proposal?
I think that it is a solid idea.
As Joey points out, it might help prevent the pointless go-rounds
that have been occurring with this discussion *and* would give us a
clear set of documents to refer to in the future.
--zak
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Setting up RFC
Just poit them to php-dev and keep bringing it up until there is some decent comment on it, at the moment there is no democratic process in PHP, people just do what they want and someone normally knows some part of PHP better than anyother, IE if you have a sessions thing speak to sascha (via PHP-DEV), a COM thing speak to Frank, Daniel and Zeev via PHP-DEV, an object thing speak to Andrei, Zeev and Andi etc... RFC's are a good idea but as soon as they are posted to php-dev they are in the archives and it will be a big pain in the arse putting them in CVS due to the karma thing and people who dont have cvs access. php-dev is there so use it, yes we should formalise some of the more important discussions but it should all take place on php-dev. Discussion about RFC's would have taken place at php-dev, of course. For the rest of your arguments, you're right, as long as it goes about minor issues. But I believe it is not true when it comes to really heavy issues, such as syntax of private object-vars (just an example). The question is now, is it worth the effort of a complete RFC process for that, or would a mere formalization of the important discussions, as you suggest, do? On the other hand, the latter one could be named 'RFC process', since it hasn't yet been defined what the heck it is precisely... - James Jeroen -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Setting up RFC
On the other hand, the latter one could be named 'RFC process', since it hasn't yet been defined what the heck it is precisely... RFC.. Request For Comments, its as simple as that someone posts a document outlining what they want changed/want to do, calls it an RFC and is litterally making a request for comments on their idea. I think this is a good idea for large things but if we encourage too much we will suddenly be flooded with RFC's all over the place then they begin to conflict.. I think that if someone feels somthing is really important then an RFC is a good idea but I certainly dont want a couple a week to plough through. That PEP's seem to work quite well, there needs to be some selection on it... For example: several supporters before you may even start an (official) RFC for example. The work on Zend Engine 2 has now started, _without_ a proper definition of it. IMHO, that's not the ideal situation, since this could lead to strange inconsequences, because the precise behaviour is decided during implementation. For example bug 10437, which wouldn't have existed if the zend engine was properly defined _before_ it was implemented. But it simply was the easiest way to implement it... As you say, for 'light' changes, no official RFC should be created, it isn't necessary, mainly because: at the moment there is no democratic process in PHP, people just do what they want Jeroen -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Setting up RFC
The work on Zend Engine 2 has now started, _without_ a proper definition of it. IMHO, that's not the ideal situation, since this could lead to strange inconsequences, because the precise behaviour is decided during implementation. Umm what about the white paper that was prepaired before work on Zend Engine 2 started?? http://www.zend.com/engine2/ZendEngine-2.0.pdf It was some kind of RFC indeed, but not updated as discussion progressed. A lot of other issues were discussed, but without RFC 'backbone'. There was also no good infrastructure to have a constructive discussion, a lot of issues have been discussed quite reasonably, but with quite some open ends. For example bug 10437, which wouldn't have existed if the zend engine was properly defined _before_ it was implemented. But it simply was the easiest way to implement it... Probably the the best way too.. not that Ive read 10437 cause Im currently working.. Useless to comment on this if you haven't read the report... As you say, for 'light' changes, no official RFC should be created, it isn't necessary, mainly because: at the moment there is no democratic process in PHP, people just do what they want Yes this is part of opensource, people will do what they want to do, If I want some feature in PHP Ill program it, the general direction of PHP should be decided by a group of people yes but it gets to a point where everyone is saying we should do it this way, that way or another way and in the end nothing gets done, at the moment people see what others are doing and question it if necessary, if its their extension then they are free to do what they want with it. I am obviously not used enough to open-source, to feel that... I have some some resistance to myself to change/add something if it isn't agreed... You shouldn't try that on a paid closed-source project ;-)... I think you're definitely right on the 'nothing gets done' part. - James -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Setting up RFC
With what end in mind is an RFC to be created for? In the IETF, RFC's are typically long, complex, and authoritative. They are often referenced for years after their inception. Do you honestly think we could (or want to) achieve this with PHP feature RFC's? Or will they be used only before initial feature implementation, then quickly outdated and discarded? That is my biggest problem with documents: they take a lot of effort to create, are often difficult to grok, and _almost always_ have a very short lifecycle. They should _not_ be too technical, _not_ too long, but yet as simple as possible, but exactly as precise enough to be relatively unambigious if you know about the PHP conventions. For example like that zend engine 2 white paper. But they need to be updated, and not discarded. They shouldn't be too hard to create, and definitely not too hard to grok. A simple template could help achieving this. All of the above IMHO, Jeroen -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Re: [PHP-DOC] Bug #12550 Updated: rand() and mt_rand() don't behave as documented
Now you assume that you need to pass arguments to these functions.
Which is not the case. Here's the proto:
/* {{{ proto int rand([int min, int max])
Returns a random number */
So revert that patch. mt_rand() / rand() accecpt either 2 parameters or
none at all. It was at least LESS wrong before. Now it's totally wrong.
_if_ I remember right (not sure), there are now 2 proto's, one with no args,
and one with2 args.
That would mean it is correct now, though I agree with you that that proto
is better.
I prefer your patch though, although it is IMO a hack. But the result was
correct.
Jeroen
--Jani
p.s. Egon, you still haven't explained me why my patch was wrong?
On 12 Aug 2001 [EMAIL PROTECTED] wrote:
ID: 12550
Updated by: jeroen
Reported By: [EMAIL PROTECTED]
Old Status: Open
Status: Closed
Bug Type: Documentation problem
Operating System: N/A
PHP Version: 4.0.6
New Comment:
Fixed. Hope this _is_ accepted...
--Jeroen
Previous Comments:
[2001-08-09 03:17:38] [EMAIL PROTECTED]
Reopened. My workaround wasn't accepted either. :)
--Jani
[2001-08-09 01:56:09] [EMAIL PROTECTED]
I have committed yet another fix for this..
--Jani
[2001-08-08 16:59:08] [EMAIL PROTECTED]
Reopened, since DSSSL doesn't act as expected, and I'm not allowed to do
a workaround.
[2001-08-06 17:09:31] [EMAIL PROTECTED]
IT's changes in the CVS, and will be online tomorrow...
[2001-08-03 21:09:30] [EMAIL PROTECTED]
The documentation is wrong. The proto is this:
mt_rand([int min, int max])
--Jani
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/?id=12550
Edit this bug report at http://bugs.php.net/?id=12550edit=1
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Re: The new $_GET/POST/ENV (was: Re: [PHP-CVS] cvs: php4 / NEWS...)
What about $_TAINTED ? for non-english ppl REQUEST is a more familiar word that TAINTED. I only encountered it when studying JS security. +1, tainted? I needed a dictionary for that... -- teodor -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Re: Bug #12245 Updated: gettype(true true) returns integer!
Patch attached
- Original Message -
From: [EMAIL PROTECTED]
Newsgroups: php.dev
To: [EMAIL PROTECTED]
Sent: Thursday, August 09, 2001 1:12 AM
Subject: Bug #12245 Updated: gettype(true true) returns integer!
ID: 12245
Updated by: jeroen
Reported By: [EMAIL PROTECTED]
Old Status: Open
Status: Assigned
Bug Type: Variables related
Operating System: Solaris
PHP Version: 4.0.6
New Comment:
KISS example:
var_dump(TRUE || TRUE) - int(1)
var_dump(FALSE FALSE) - int(0)
Patch awaiting to be committed, will be fixed in 4.0.7
Previous Comments:
[2001-07-19 05:56:38] [EMAIL PROTECTED]
The operator (and ||) returns an integer value even when both arguments
are boolean. Thus the following code:
function is_true($val)
{
return (is_bool($val) $val);
}
echo (is_true(true) ? 'T' : 'F'),\n;
echo (is_true(is_true(true)) ? 'T' : 'F'),\n;
gives
T
F
-- Nick
Edit this bug report at http://bugs.php.net/?id=12245edit=1
fix12245.diff
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Re: rand_str
but why not put it into PEAR? PEAR can be useful, but the power of PHP is, that is has so many helpful build-in functions. And with pear, it will always be longer. I think that new functions should be added on basis of usefulness, not the coolness factor. IMNSHO this function isn't very useful, To generate random passwords, with characters you decide, and length? I think it is useful, but usefulness indeed is a good point. Does everyone here doubt the usefulness? and it is extremely easy to implement in userland: That is not true, md5 will always return hex, and is of specific length. I can image users don't want (so much) digits, and/or want to exclude certain look-alike chars ( 0 (zero) and O (o), for example). Greetz, Jeroen -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] RFC: mt_* functions
Both function families are the same in syntax returning, only the algorithm is different. I.e.: the semantics is the same. The algorithm - if correct - shouldn't bother, and shouldn't be the concern of the programmer, but rather the system maintainer (specific cases excluded, but than you leave the high-level of PHP, and go to low-level implementation issues.). But they are different in that each will produce a deterministic sequence based on their seeds. If I, as an application developer, distributes a regression test harness which tests my app with a specific seed expecting a specific sequence and the server my app runs on has switched rand() to use the mt_rand() algorithm my regression test will fail. True... though IMHO a regression test is not strictly using PHP in a high-level way, but goes into internal behaviour of it. In the documentation, rand() is defined to return a pseudo-random value between 0 and RAND_MAX. It states nothing about that the same seed yields the same sequence. True, this is the case in (almost) any pseudo-random-generator. But relying on that behaviour is IMO using low-level implementation knowledge. Of course, it is not forbidden to use that knowledge, but if you do, I believe that it is your own responsibility to keep an eye on the changelog when upgrading. And with a rand_generator = system setting, you actually have a guarantee that the system's rand is used, with all it's properties. I'm not denying that this change could break a script (though IMO it would be rare). A solution would be to have it defaulted to 'system', and let the mt_* functions always use mt, regardless of the ini-setting. By default, no result will be different then, while still rand()'s behaviour is determined by an ini-setting. In the end, it'd be best (IMO) to switch the default to mt, and that change - though with less impact - has technically the same consequences as turning register_globals off by default. This is somewhat like saying that we should make crypt() just be an alias for md5() since md5() is a better algorithm. The fact that it is better is rather irrelevant since the output of the algorithm itself is sometimes important. Many times you can swap crypt() for md5(), but many times you can't. Same goes for rand() and mt_rand(). 'somewhat like', indeed, since crypt is defined to use DES, and is targetted at being the same on the same input. This definitely not the case with rand(), it is a regretful consequence of the way computers work why it sometimes can be predicted. -Rasmus Jeroen -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Re: rand_str
and it is extremely easy to implement in
userland:
That is not true,
So how about this?
function str_rand($len=8)
{
$retval = strtr(md5(microtime()), chr(0x30), chr(0x4F));
return substr($retval,0,$len);
}
for($i=0; $i10; $i++){
echo str_rand(), \n;
}
I find rand_str($len , 1..9a..f\x4F) easier... ;-)
And this is still yielding exactly 16 differerent characters.
As you saw for yourself, it is not trivial to implement something like this
in userland. For example str_pad is way easier to implement, only some
playing with str_repeat.
Are there any objections if I implement this? Are you still against this new
function?
Jeroen
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Re: rand_str
Hi Jeroen, I think we're not on the same page. :) I consider both versions of str_rand() I posted trivial... Agree. But they are not what rand_str could do. The result has 16 different chars, just because md5 happens to have that much. Implementing something that has NOT that limitation, is far less trivial. Below is a - limited - implementation Also, and this is strictly subjective, I don't think the function needs to be implemented natively. As I said, it's trivial. :) But my stance could be rated as -0.3... Actually, as I'm thinking about it, -0.2. k, mine is 0.8, 0.9, on the idea, not the details as for the rand_str($len , 1..9a..f\x4F) proto: I don't like it. KISS. Better suggestions? Simple length and a list of characters... and the list-of-characters way is also in addcslashes, and the trims. Jeroen -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Re: PHP Notes
No No No, I mean that the USER needs to confirm in that case.
Hey, i've found a question mark in your note. You realize that it is not
allowed to ask questions here? do that on php-general.
If this is not a question, and you're sure you obeyed the rule, click here
to commit the note...
Jeroen
- Original Message -
From: Andy [EMAIL PROTECTED]
To: Jeroen van Wolffelaar [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Sent: Sunday, August 05, 2001 9:47 PM
Subject: Re: PHP Notes
confirmation would be even worse, then I'd (we'd)
STILL have to go through all of the notes
(and this time even confirm them)the point of
this is so that we don't have to do to much with
the notes ;) (also, people will never get answers
to there questions, etc on doc notes, so if they
get it the first time that doc notes aren't the
way, then they can go to the right place and not
get all mad at us)
On Sun, 05 Aug 2001, Jeroen van Wolffelaar wrote:
Agree, does css have relative fonts? +20% is fine, I suppose (didn't
test)
Anyway, it's about the idea of a bigger font, not _how_ bigger.
And another idea: ask for confirmation if one submits a note with a
question
mark in it, since questions are forbidden. This would help greatly, I
think
Greetz,
Jeroen
- Original Message -
From: Andy [EMAIL PROTECTED]
To: Jeroen van Wolffelaar [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Sent: Sunday, August 05, 2001 9:42 PM
Subject: Re: PHP Notes
20pt font? That's a bit big, don't you think?
On Sun, 05 Aug 2001, Jeroen van Wolffelaar wrote:
Since I have started maintaining the document
notes, I have roughly estimated that 1/2-2/3 of
the notes have to be deleted because people are
not following the guidelines. The page that
tells these guidelines is setup in paragraph
form, which not too many people seem to read. I
propose shortening this page and/or putting the
guidelines in bulleted form.
+1
and font size=+4...
O no, css, well:
.guidelines { font-size: 20pt }
Anybody agree/disagree?
(*Andy*)
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Fw: Re: [PHP-CVS] cvs: php4 /ext/standard math.c
Can't post to php-cvs :-(
jeroen Sun Aug 5 16:27:04 2001 EDT
Modified files:
/php4/ext/standard math.c
Log:
Bugfix in abs(), abs(LONG_MIN) was bogus
---AND---
- Replaced the pow(LONG_MIN,1) fix for a better one
- Removed bogus left-over comment in pow()
--
(thought I already committed that...)
Index: php4/ext/standard/math.c
diff -u php4/ext/standard/math.c:1.51 php4/ext/standard/math.c:1.52
--- php4/ext/standard/math.c:1.51 Sun Aug 5 10:40:14 2001
+++ php4/ext/standard/math.c Sun Aug 5 16:27:03 2001
@@ -19,7 +19,7 @@
+--+
*/
-/* $Id: math.c,v 1.51 2001/08/05 14:40:14 stas Exp $ */
+/* $Id: math.c,v 1.52 2001/08/05 20:27:03 jeroen Exp $ */
#include php.h
#include php_math.h
@@ -49,7 +49,11 @@
if (Z_TYPE_PP(value) == IS_DOUBLE) {
RETURN_DOUBLE(fabs(Z_DVAL_PP(value)));
} else if (Z_TYPE_PP(value) == IS_LONG) {
- RETURN_LONG(Z_LVAL_PP(value) 0 ? -Z_LVAL_PP(value) :
Z_LVAL_PP(value));
+ if (Z_LVAL_PP(value) == LONG_MIN) {
+ RETURN_DOUBLE(-(double)LONG_MIN);
+ } else {
+ RETURN_LONG(Z_LVAL_PP(value) 0 ? -Z_LVAL_PP(value) :
Z_LVAL_PP(value));
+ }
}
RETURN_FALSE;
@@ -466,19 +470,10 @@
}
case 1:
RETURN_LONG(1);
- case LONG_MIN: /* special case since -LONG_MIN == 0 */
- /* lexp != 0, and only lexp==1 is LONG, DOUBLE otherwise */
- if (lexp == 1) {
- RETURN_LONG(LONG_MIN);
- } else {
- dval = exp(log(-(double)LONG_MIN) * (double)lexp);
- RETURN_DOUBLE(lexp1 ? -dval : dval);
- }
default:
/* abs(lbase) 1 */
- dval = exp(log((double) (lbase0?lbase:-lbase)) *
+ dval = exp(log(lbase0? (double)lbase : -(double)lbase ) *
(double) lexp);
- /* long result = 1; */
if (lexp 0 || dval (double) LONG_MAX) {
/* 1/n ( abs(n) 1 ) || overflow */
RETURN_DOUBLE(((lexp 1) lbase0) ? -dval : dval);
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Re: rand_str
Implementing something that has NOT that limitation, is far less trivial.
function str_rand($len = 8, $class = 'a-zA-Z1-9')
{
static $init = 1;
if(1 == $init){
mt_srand((double) microtime() * 100);
$init = 0;
}
$chars = array();
for($i = 0; $i $len; $i++){
$chars[] = chr(mt_rand(0,255));
}
return implode('', preg_grep('|['.preg_quote($class).']|',$chars));
}
Just a little bit different syntax for the second argument.
What's the big deal? :)
Okay, but hey, you're a PHP-expert with probably many years of experience...
By the way, your function won't return strings of length $len... ;)
And you could say that preg_grep is quite a hack.
Anyway, this didn't convince me it's trivial... I'm sorry.
Better suggestions? Simple length and a list of characters... and the
list-of-characters way is also in addcslashes, and the trims.
Jeroen
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] RFC: New math functions: log2, etc
At 01:53 AM 8/4/2001 +0200, Jeroen van Wolffelaar wrote: log(a) / log(n) is not that much harder, and its the right way, imho. Yes, you're right that it is the right way. But for example, for tan(x), the right way is sin(x)/cos(x). (Not such a good example, but anyway) As you said :-) as an anal note, tan(x) is the correct notation, just as logarithms are also a wrapper type in themselves, log is also the correct notation. What is 'correct' here, mathematically correct, or something else? Mathematically you're right of course. But in mathematica co, you'll also get a much nicer view on formula's than in PHP... [snip] However, IMO the log, exp, sinus, etc. functions should be in the core. Yes, I agree, however, expm1 and log1p don't. I agree. Do you suggest here to hold these two, until some kind of advanced-math-extension will be added? Some other thing, the M_* constants. I always wondered why for example M_2_SQRTPI (2/sqrt(PI)) was in PHP. IMO, there are only one or two essential constants to be in the core: PI (of course), and (possibly) the EULER-constant. What about adding PI and, possibly, EULER as constant (without the M_), and deprecating those M_ constants? Or at least promote them to the math-extension? -Sterling Jeroen -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Bug #12566 Updated: Cascaded ternaries evaluate incorrectly
See some messages I had on php-dev back around the first week of January, 2001 on this topic. FWIW, I would like to change it. On http://marc.theaimsgroup.com/?w=4r=1s=trachtenbergq=a , I could only find messages about break/continue in switch statements... Am I overlooking something? Of did you have another mail-name then? Greetz, Jeroen -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] RFC: mt_* functions
Please don't. Ini settings that change semantics are a bother, and people should be able to choose their random function. Both function families are the same in syntax returning, only the algorithm is different. I.e.: the semantics is the same. The algorithm - if correct - shouldn't bother, and shouldn't be the concern of the programmer, but rather the system maintainer (specific cases excluded, but than you leave the high-level of PHP, and go to low-level implementation issues.). - Stig Jeroen -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] RFC: New math functions: log2, etc
log(a) / log(n) is not that much harder, and its the right way, imho. Yes, you're right that it is the right way. But for example, for tan(x), the right way is sin(x)/cos(x). (Not such a good example, but anyway) log($bla,2) is cleaner, IMO, than log($bla)/log(2), not mentioning the possible need for extra ( and ). log2() is going too far IMO, that's why I believe it shouldn't exist. Why not move the more complex functions into a separate math extension or statistics extension? There is a possibility that GSL will be implemented in PHP, but that's in the 'idea to maybe do that stage' (of Jesus). However, IMO the log, exp, sinus, etc. functions should be in the core. -Sterling Jeroen -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] RFC: New math functions: log2, etc
There is a possibility that GSL will be implemented in PHP, but that's in GSL: GNU Scientific Library, http://sources.redhat.com/gsl/ Jeroen -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Re: Patch for ext/standard/[basic_functions.c|php_math.h|math.c]
I am sending this patch to the php-dev list for your consideration. Attached are the listing produced with cvs diff -u, and listed below is a test file to check the changes. Basically I just added some more math funcs from the C library (hyperbolics and exponentials). Hyporbolic functions are indeed good to be added. However, I don't think it's really need to add log2, exp10, cbrt and so forth. It's a bit overkill, and not needed (IMO). the exp / pow / log functions work fine, and this is only a very few characters less typing. cbrt is quite a WTF function, chances are low you guess what it is, since it's not really standard name for cubic root. And pow($x,'1/3') works fine. Greetz, Jeroen -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Re: Patch for ext/standard/[basic_functions.c|php_math.h|math.c]
It might be that. Just implemented the functions taking advantage of their presence in the standard set of math functions of the C library, so the C people might be more familiar that the rest I guess. Agreed, but I'm not certain this is worth the extra bloath of relatively unneeded functions. I was going to add the erf, gamma, etc. function, but I am not sure if those are of general use (and because I am just starting to familiarize myself w/ the Zend/PHP macros/coding style) erf is useful, and not trivial to write different. gamma I don't recall what it does, but I guess that's useful too. Statistics is some time ago for me... I was only talking about functions like log2 and so, that are really trivial to write different. Greetz, Jeroen -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
