[PHP-DEV] bindlib_w32 fix for Visual Studio .NET
I ran into a problem when building bindlib_w32 using Visual Studio .NEt under Windows XP: nsap_addr.c(38) : error C2491: 'isxdigit' : definition of dllimport function not allowed The attached patch corrects this problem. I don't have commit privileges for the bindlib_w32 module, so if someone could either grant me karma or commit this for me, I'd appreciate it. -- Jon Parise ([EMAIL PROTECTED]) :: The PHP Project (http://www.php.net/) Index: nsap_addr.c === RCS file: /repository/bindlib_w32/nsap_addr.c,v retrieving revision 1.1.1.1 diff -u -r1.1.1.1 nsap_addr.c --- nsap_addr.c 26 Apr 1999 14:02:36 - 1.1.1.1 +++ nsap_addr.c 22 Feb 2003 20:54:56 - @@ -31,7 +31,8 @@ #include "conf/portability.h" -#if !defined(isxdigit) /* XXX - could be a function */ +/* XXX - isxdigit could be an existing function or macro */ +#if !defined(isxdigit) && !defined(_CTYPE_DEFINED) static int isxdigit(c) register int c; -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Files Headers
On Sat, Feb 08, 2003 at 01:31:22AM +0100, Marcus Brger wrote: > From our files haeders: >| available at through the world-wide-web at | > > Shouldn't the first 'at' be dropped? Yes. -- Jon Parise ([EMAIL PROTECTED]) :: The PHP Project (http://www.php.net/) -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: str_ireplace vs. stri_replace
On Thu, Jan 30, 2003 at 01:44:27PM -0800, Sara Golemon wrote: > You're not the first to voice this opinion. *I* feel str_ireplace is better > as it follows the naming convention of _. Others feel > stri_replace is better as that follows eregi_replace's style. I have no > trouble going with whatever the majority feels is best. Get rid of stri_replace() and/or str_ireplace() and just add a fourth optional parameter to str_replace() to control case-sensitivity. -- Jon Parise ([EMAIL PROTECTED]) :: The PHP Project (http://www.php.net/) -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/gd/libgd gd.c
On Tue, Jan 21, 2003 at 01:49:34AM -, Pierre-Alain Joye wrote: > + * Added on 2003/12 by Pierre-Alain Joye ([EMAIL PROTECTED]) > + * (c) 2003 Pierre-Alain Joye I think receiving credit is important, but I don't think it's legal for you to claim copyright like this. It's contradictory to the PHP copyright statement at the top of the file, and, as I understood things, contributing to a project such as PHP essentially waves your individual copyright. -- Jon Parise ([EMAIL PROTECTED]) :: The PHP Project (http://www.php.net/) -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] 'php4' CVS module for PHP 5?
I'm a tool and sent this to the pear-dev list accidentally. Redirecting it here ... -- Jon Parise ([EMAIL PROTECTED]) :: The PHP Project (http://www.php.net/) --- Begin Message --- I'm not trying to start too much trouble, but ... If the next (major) release of PHP is going to be PHP 5, do we plan on continuing development in the 'php4' CVS module? And along the same lines, will be continue to build 'libphp4.so', or will that be changing to 'libphp5.so'? -- Jon Parise ([EMAIL PROTECTED]) :: The PHP Project (http://www.php.net/) --- End Message --- -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PROPOSAL: "unless" control structure
On Sun, Jan 12, 2003 at 12:53:12PM -0600, Michael Sims wrote:
> My apologies if this has been brought up before, but I searched the
> archives and couldn't find a reference to it.
>
> I'm sure this is the sort of thing that would have already been
> implemented if there was any desire for it among the developers, but I
> was wondering if anyone had considered adding support for an "unless"
> control structure, similar to the one Perl has. I personally find it
> much more logical in certain cases.
While it would no doubt be easy to implement, I would consider it
unnecessary syntactic sugar. Besides, it actually ends up using
_more_ characters ("unless(":7, "if(!":4) in the long run.
--
Jon Parise ([EMAIL PROTECTED]) :: The PHP Project (http://www.php.net/)
--
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [PHP-CVS] cvs: php4 /win32 sendmail.c sendmail.h
On Fri, Jan 03, 2003 at 03:17:44PM -, Anantha Kesari H Y wrote: > hyanantha Fri Jan 3 10:17:44 2003 EDT > > Modified files: > /php4/win32 sendmail.c sendmail.h > Log: > NetWare related changes/modifications. Could you _please_ provide more substantive commit messages. I doubt there are many (any?) of us here are familiar with NetWare internals, and we'd really like to be able to understand the content of and motivations for your changes without guessing from the diffs. -- Jon Parise ([EMAIL PROTECTED]) :: The PHP Project (http://www.php.net/) -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] META: Proper quoting
On Sat, Dec 28, 2002 at 02:28:54PM +0100, Sascha Schumann wrote: > I've noticed a trend to extreme over-quoting on the php > developer mailing lists. (Not to mention top-posting, but > that's another topic.) One of the most annoying results of over-quoting is the inclusion of multiple signature blocks in the resulting message. For those vim users out there, the following macro works quite well: normal :g/^> -- *$/,/^$/-1d^M^Lgg It will truncate the message in the current buffer to just before the '-- ' signature delimiter. If you use mutt as your mail client, the following autocmd will automate the process: autocmd BufRead mutt* normal :g/^> -- *$/,/^$/-1d^M^Lgg -- Jon Parise ([EMAIL PROTECTED]) :: The PHP Project (http://www.php.net/) -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] -ldl magic
What's the preferred config.m4 incantation to determine whether the 'dl' library needs to be linked with an extension (for PECL, in this case)? I know very little about the 'dl' library, so please forgive my ignorance. -- Jon Parise ([EMAIL PROTECTED]) :: The PHP Project (http://www.php.net/) -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] -+ [01]
On Thu, Dec 19, 2002 at 11:26:52AM +0200, Zeev Suraski wrote: > Either way, as Sterling pointed out and I pointed out a few days ago, this > +-N is really nothing but an 'I (strongly) (dis)agree', and it is in no way > a voting system. That's one of the key reasons I try to avoid using it, > and stick to the lengthy spelled-out sentence. +1 -- Jon Parise ([EMAIL PROTECTED]) :: The PHP Project (http://www.php.net/) -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] -+ [01]
On Thu, Dec 19, 2002 at 01:51:01PM +0100, Marcus Brger wrote: > >There is nothing funny about that statement. For example, if > >you are not going to do the work on merging the CLI/CGI code, > >just saying that you would like to see that happening has > >little to no effect. Conclusively, there is simply too > >much noise on the php-dev list by people who are not going to > >do any work, but somehow think they are entitled to actually > >waste other people's time with their opinions. > > > >- Sascha > > Ok, now your thoughts become clear and indeed make much sense. But > how do we separate the noise from thoughts that metter and should be > heared before doing any modification. Shall we hear them only when > the initial mail is marked as RFC? No, but attaching a patch definitely helps. I mostly agree with Sascha and Zeev. One of the downsides to PHP's "anyone can be a developer (of PHP)" philosophy is that there are a large number of people with commit bits that can (legitimately?) drop themselves into any discussion with some notion of authority, even if they have never touched the part of the code that's being discussed (such as the CGI / CLI debate). In other large projects (FreeBSD, for example), when someone proposes a modification to something like the VM system, it seldom results in a long, drawn-out conversation involving dozens of people. Only the developers who understand that part of the system contribute. -- Jon Parise ([EMAIL PROTECTED]) :: The PHP Project (http://www.php.net/) -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/standard array.c
On Sun, Nov 24, 2002 at 03:42:02AM +0900, Moriyoshi Koizumi wrote: > I think the "step" option which you added is quite useful in every case. > Why didn't you merge into the branch? there seems no BC problem about it. I may merge it after PHP 4.3.0 is officially released, but I don't want to taint the release candidates (primarily out of principle; I really doubt anything would break). -- Jon Parise ([EMAIL PROTECTED]) :: The PHP Project (http://www.php.net/) -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/standard array.c
On Sun, Nov 24, 2002 at 03:28:45AM +0900, Moriyoshi Koizumi wrote: > Hmm, since nothing is mentioned about the rule of character sequence > generation in the manual, I don't think it's so necessary. IMO this new > feature introduced in 4.1.0 should not be included in the first place > because it broke backwards compatibilities pretty much as one of the user > contributed notes says and its behaviour is also as unexpectable as the > number of charset - encoding mappings out there. Yes, I can see that causing problems. I think it's necessary to leave the capability to generate character sequences in there now, though, for all sorts of backwards-compatibility reasons. My change to range() (the addition of the "step" parameter) was primarily inspired by Python's range() function, described here: http://www.python.org/doc/current/lib/built-in-funcs.html#l2h-47 The Python version does not handle characters, which (as we both agree) is the "better" implementation. -- Jon Parise ([EMAIL PROTECTED]) :: The PHP Project (http://www.php.net/) -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/standard array.c
On Sat, Nov 23, 2002 at 08:47:45PM +0900, Moriyoshi Koizumi wrote:
> Just a notice:
>
> The third optional parameter is not suggested in the branch.
> Therefore I won't try to merge this patch to PHP_4_3, but due to this
> decision the behaviour of the function slightly differs one another in the
> cases like range("A", "Ä");
Please add a note to this effect in the manual. There are already
some behavior-related notes at the bottom of the range() documentation.
--
Jon Parise ([EMAIL PROTECTED]) :: The PHP Project (http://www.php.net/)
--
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Patch for range()
On Sat, Nov 23, 2002 at 06:47:48PM +0900, Moriyoshi Koizumi wrote: > BTW how about renaming it to array_range() and adding an alias for BC? I think that's logical, but I'm leave it up to the QA folks to make the call. -- Jon Parise ([EMAIL PROTECTED]) :: The PHP Project (http://www.php.net/) -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Patch for range()
On Sat, Nov 23, 2002 at 03:37:29PM +0900, Moriyoshi Koizumi wrote:
> I've just found range() behaves unexpectedly in some special cases.
>
> For instance, please try the following script.
>
> echo count(range('a', 'z', 12));
> ?>
>
> will give 45 while it should return an array that consists of 3 elements.
> That is because the counting may exceed the upper limit of positive char
> value during the loop.
>
> The attached patch is a fix for this issue. I'll commit this if there are
> no objections.
No objections (although I haven't actually applied and run your
patch). Thanks for investigating this. I should have tested a wider
set of step values in my original tests.
--
Jon Parise ([EMAIL PROTECTED]) :: The PHP Project (http://www.php.net/)
--
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] show_source()
On Fri, Nov 15, 2002 at 03:11:10AM -0500, John Coggeshall wrote: > 1) I notice that there seems to be a T_LINE token, which should be the > linenumber? However, this never seems > To even come up in the lexer from the zend_highlight() function... T_LINE is the token for the '__LINE__' constant. The current line number is stored in zend_lineno (e.g. CG(zend_lineno)). -- Jon Parise ([EMAIL PROTECTED]) :: The PHP Project (http://www.php.net/) -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] try/catch/throw in php5 ?
On Tue, Nov 12, 2002 at 02:27:49PM +0100, michel 'ziobudda' morelli wrote: > any news about an error management in php5 ? Yes, exceptions are implemented in Zend Engine 2. -- Jon Parise ([EMAIL PROTECTED]) :: The PHP Project (http://www.php.net/) -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP Snaps
On Tue, Nov 12, 2002 at 10:22:36AM +0100, Marcus Brger wrote: > Yes when i introduce a problem with win32 build i have to wait > up to 4 hours until i can see the problem and try to fix it. Then > i have to wait 4 more hours to see whther i did it correctly That sounds sort of like a separate problem (breaking the build). Something like a tinderbox[1] setup would be quite nice, although the resources for it probably don't exist. [1] http://tinderbox.mozilla.org/showbuilds.cgi?tree=SeaMonkey -- Jon Parise ([EMAIL PROTECTED]) :: The PHP Project (http://www.php.net/) -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Stepping on range()
Attached is a patch that adds an optional "step" parameter to the
range() function. This allows the generation of ranges based on a
non-one increment. For example:
range(0, 10, 2);
... would yield an array containing (0, 2, 4, 6, 8, 10).
The change is entirely backwards-compatible with the existing
behavior of range().
I've also attached a test script for the new functionality.
I haven't committed the changes in the interest of getting PHP 4.3.0
out the door, but I will if no one sees a problem. Otherwise, I can
hang onto this until after the release.
Documentation updates will accompany with the commit.
--
Jon Parise ([EMAIL PROTECTED]) :: The PHP Project (http://www.php.net/)
Index: array.c
===
RCS file: /repository/php4/ext/standard/array.c,v
retrieving revision 1.198
diff -u -r1.198 array.c
--- array.c 5 Nov 2002 16:19:19 - 1.198
+++ array.c 11 Nov 2002 05:31:16 -
@@ -1411,48 +1411,60 @@
}
/* }}} */
-/* {{{ proto array range(mixed low, mixed high)
+/* {{{ proto array range(mixed low, mixed high[, int step])
Create an array containing the range of integers or characters from low to high
(inclusive) */
PHP_FUNCTION(range)
{
- zval **zlow, **zhigh;
-
- if (ZEND_NUM_ARGS() != 2 || zend_get_parameters_ex(2, &zlow, &zhigh) ==
FAILURE) {
- WRONG_PARAM_COUNT;
+ zval *zlow, *zhigh;
+ long step = 1;
+
+ if (zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC, "zz|l", &zlow,
+ &zhigh, &step) == FAILURE) {
+ RETURN_FALSE;
}
- /* allocate an array for return */
+ /* We only want positive step values. */
+ if (step < 0) {
+ step *= -1;
+ }
+
+ /* Initialize the return_value as an array. */
if (array_init(return_value) == FAILURE) {
RETURN_FALSE;
}
- if (Z_TYPE_PP(zlow)==IS_STRING && Z_TYPE_PP(zhigh)==IS_STRING) {
+ /* If the range is given as strings, generate an array of characters. */
+ if (Z_TYPE_P(zlow) == IS_STRING && Z_TYPE_P(zhigh) == IS_STRING) {
char *low, *high;
- convert_to_string_ex(zlow);
- convert_to_string_ex(zhigh);
- low = Z_STRVAL_PP(zlow);
- high = Z_STRVAL_PP(zhigh);
- if (*low>*high) {
- for (; *low >= *high; (*low)--) {
+
+ convert_to_string_ex(&zlow);
+ convert_to_string_ex(&zhigh);
+ low = Z_STRVAL_P(zlow);
+ high = Z_STRVAL_P(zhigh);
+
+ if (*low > *high) { /* Negative increments */
+ for (; *low >= *high; (*low) -= step) {
add_next_index_stringl(return_value, low, 1, 1);
- }
- } else {
- for (; *low <= *high; (*low)++) {
+ }
+ } else {/* Positive increments */
+ for (; *low <= *high; (*low) += step) {
add_next_index_stringl(return_value, low, 1, 1);
- }
+ }
}
} else {
int low, high;
- convert_to_long_ex(zlow);
- convert_to_long_ex(zhigh);
- low = Z_LVAL_PP(zlow);
- high = Z_LVAL_PP(zhigh);
- if (low > high) {
- for (; low >= high; low--) {
+
+ convert_to_long_ex(&zlow);
+ convert_to_long_ex(&zhigh);
+ low = Z_LVAL_P(zlow);
+ high = Z_LVAL_P(zhigh);
+
+ if (low > high) { /* Negative increments */
+ for (; low >= high; low -= step) {
add_next_index_long(return_value, low);
}
- } else {
- for (; low <= high; low++) {
+ } else {/* Positive increments */
+ for (; low <= high; low += step) {
add_next_index_long(return_value, low);
}
}
--TEST--
range()
--FILE--
--EXPECT--
Array
(
[0] => 0
[1] => 1
[2] => 2
[3] => 3
[4] => 4
[5] => 5
[6] => 6
[7] => 7
[8] => 8
[9] => 9
[10] => 10
)
Array
(
[0] => 10
[1] => 9
[2] => 8
[3] => 7
[4] => 6
[5] => 5
[6] => 4
[7] => 3
[8] => 2
[9] => 1
[10] => 0
)
Array
(
[0] => 0
[1] => 2
[2] =&
Re: [PHP-DEV] turning strlen() into an opcode
On Fri, Nov 08, 2002 at 04:17:43PM -0500, Andrei Zmievski wrote: > I've made a small patch that turns strlen() into a statement executed by > the engine instead of a function. The reasoning is that something that > integral should probably be in the engine. I haven't done hard > benchmarking but it seems to improve performance of that particular > piece of code by about 25%. Feedback is welcome. I'd be more interested in seeing a more generic len() function (a la Python) that would return the length of the variable passed to it (the number of characters in a string, then number of elements in an array). Actually, I suppose extending count() to handle strings would be mostly equivalent. -- Jon Parise ([EMAIL PROTECTED]) :: The PHP Project (http://www.php.net/) -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 / Makefile.global
On Thu, Oct 24, 2002 at 07:27:31AM +0900, Yasuo Ohgaki wrote: > >So, once again, all I really want to know is what is so special about > >php.ini-dist? And what _specific_ settings do you (Yasuo) feel must > >be applied to run-tests.php in order to run properly? And why can't > >they just be specified via ini_set() calls. > > > >In short, I just want to know why run-tests.php needs an external > >dependency on php.ini-dist. I would much prefer run-tests.php to be > >self-contained. > > I really fail to see why we need to ask troubles for executing > run-tests.php. It's executed by various people and better to run > always with less problems when people typed "make test". Listen, I don't (personally) care about all this "Derick did this" and "Yasuo did that" stuff. All I'm looking for are anwers to the questions I've asked. I'd like to be able to understand the technical situation at hand here before I can even think about taking a side, but I am not receiving the information I'm requesting. I still do not understand what magical values in php.ini-dist need to be applied to run-tests.php and why those values, if they are so important, can't be explicitly enabled via ini_set() calls. -- Jon Parise ([EMAIL PROTECTED]) :: The PHP Project (http://www.php.net/) -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Work is beginning on cURL and PHP again
On Mon, Oct 21, 2002 at 10:52:10PM +0200, Sterling Hughes wrote: > > > Well, currently i plan on using a Perl script to read the curl.h > > > definition file, and generate the code for all options that don't meet > > > the following criterium: > > > > What, you can't write a simple parser in php? Off with his head! ;) > > Yeah, but then you get into the recursive dependency problem (otherwise > i would). You need PHP in order to build PHP, and that just gets messy > ;) Then it's settled; use awk(1)! -- Jon Parise ([EMAIL PROTECTED]) :: The PHP Project (http://www.php.net/) -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] php_value vs. php_admin_value
On Mon, Oct 21, 2002 at 07:46:53AM +0300, Jani Taskinen wrote: > Can someone explain what the difference between > these 'php_value' and 'php_admin_value' directives is? > (and same goes of course for php_flag vs. php_admin_flag..) As I recall (and I'm not looking at the code right now to back this up), the php_admin_* versions are for INI options that can only be set "administratively" (i.e. PHP_INI_SYSTEM), meaning they can't be changed by user-level operations. -- Jon Parise ([EMAIL PROTECTED]) :: The PHP Project (http://www.php.net/) -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Work is beginning on cURL and PHP again
On Mon, Oct 21, 2002 at 10:12:55PM +0200, Sterling Hughes wrote: > * Autogenerating much of the interface between cURL and PHP, allowing > PHP to support multiple versions of the underlying cURL library By what mechanism do you plan on implementing this? -- Jon Parise ([EMAIL PROTECTED]) :: The PHP Project (http://www.php.net/) -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP_INI_MH question
On Tue, Oct 15, 2002 at 01:12:35AM -0400, Jon Parise wrote: > I'm curious about some of the semantics behind PHP_INI_MH. Woops, I had an error in my code that made me interpret things incorrectly. -- Jon Parise ([EMAIL PROTECTED]) :: The PHP Project (http://www.php.net/) -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] PHP_INI_MH question
I'm curious about some of the semantics behind PHP_INI_MH. In my Python extension, I use some custom INI callbacks to set values inside of the Python environment. The Python interpreter is initialized inside of PHP_MINIT_FUNCTION. It appears as though PHP invokes PHP_INI_MH callbacks for values that exist in the php.ini file _before_ the extension is initialized. Therefore, it is necessary for me to test whether or not the Python interpreter has been initialized inside of my PHP_INI_MH callback for both php.ini values and ini_set() calls to work. However, values set in php.ini are never applied to the Python environment because the interpreter never exists at the time the PHP_INI_MH callback is invoked. My solution is to use extension globals to store the new INI values upon entering PHP_INI_MH. If the extension has been initialized, the settings are applied to the Python environment immediately. Otherwise, PHP_MINI_FUNCTION explicitly applies any "cached" INI changes that are now stored in global variables. This doesn't strike me as ideal, but it seems like the best way to handle this situation. Are there other ways? -- Jon Parise ([EMAIL PROTECTED]) :: The PHP Project (http://www.php.net/) -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] CODING_STANDARDS addition re: emalloc
A new CODING_STANDARDS patch is attached, based on feedback from Andi and Dan (thanks!). Please review and comment. -- Jon Parise ([EMAIL PROTECTED]) :: The PHP Project (http://www.php.net/) Index: CODING_STANDARDS === RCS file: /repository/php4/CODING_STANDARDS,v retrieving revision 1.22 diff -u -r1.22 CODING_STANDARDS --- CODING_STANDARDS9 Sep 2002 07:54:11 - 1.22 +++ CODING_STANDARDS9 Oct 2002 13:41:35 - @@ -122,6 +122,20 @@ existing. End users should use function_exists() to test for the existence of a function +[11] Prefer emalloc(), efree(), estrdup(), etc. to their standard C library + counterparts. These functions implement an internal "safety-net" + mechanism that ensures the deallocation of any unfreed memory at the + end of a request. They also provide useful allocation and overflow + information while running in debug mode. + + In almost all cases, memory returned to the engine must be allocated + using emalloc(). + + malloc() should only be used in instances where you need to allocate + memory that will be freed (via free()) inside of a third-party library. + It should also be used in instances where allocated memory has to + survive between multiple requests. + Naming Conventions -- -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] CODING_STANDARDS addition re: emalloc
Attached is a patch that adds a new item to CODING_STANDARDS that suggests using emalloc() and friends over the standard C library version. It also offers an explanation, courtesy of Rasmus' reply to my earlier question on the subject. If no one objects to the addition in principle or in wording, I'll commit this in a few days. -- Jon Parise ([EMAIL PROTECTED]) :: The PHP Project (http://www.php.net/) Index: CODING_STANDARDS === RCS file: /repository/php4/CODING_STANDARDS,v retrieving revision 1.22 diff -u -r1.22 CODING_STANDARDS --- CODING_STANDARDS9 Sep 2002 07:54:11 - 1.22 +++ CODING_STANDARDS9 Oct 2002 02:09:46 - @@ -122,6 +122,15 @@ existing. End users should use function_exists() to test for the existence of a function +[11] Prefer emalloc(), efree(), estrdup(), etc. to their standard C library + counterparts. These functions implement an internal "safety-net" + mechanism that ensures the deallocation of any unfreed memory at the + end of the request. They also provide useful allocation and overflow + information when running in debug mode. + + malloc() should only be used in instances where you need to allocate + memory that will be freed (via free()) inside of a third-party library. + Naming Conventions -- -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] ext/aspell
On Tue, Oct 08, 2002 at 06:05:09PM +0200, Sascha Cunz wrote: > > [] While new comers may not know of pspell, > > people who have compiled PHP before with it will, infact that is what > > they'll expect when configuring their PHP. Since we cannot remove the old > > pspell option like we seem to agree to do for --with-aspell it is cleaner > > IMHO to simply add that little bit of text that will tell people new to php > > that --with-pspell also applies to GNU Aspell. Perpaps, a year down the > > road when we feel confortable to say that GNU marketing(tm) has made pspell > > absolete we can make this change. > > Then why not make --with-pspell cause an error saying: "use > --with-gnu-aspell"? And then move --with-pspell to /dev/null at it's time. Either way, I think it's also appropriate to move the [ap]spell extension to PECL for the next major release (i.e. not for 4.3, but for 4.4 or later). -- Jon Parise ([EMAIL PROTECTED]) :: The PHP Project (http://www.php.net/) -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] String function optimizations
On Thu, Oct 03, 2002 at 10:21:26PM -0400, Ilia A. wrote: > After doing a number of tests on PHP's various string functions, I've came up > with a patch that significantly improves the performance on those functions. > The patch optimizes: If anything, I think it makes the code much more readable, as well. I haven't had a chance to apply the patch and test performance, though. -- Jon Parise ([EMAIL PROTECTED]) :: The PHP Project (http://www.php.net/) -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 /main output.c
On Thu, Oct 03, 2002 at 08:05:51PM +0900, Yasuo Ohgaki wrote: > >Can you please re-test things regarding to this? I reverted Yasuo's > >commits and I might have overlooked something. > > What kind of diff you are using? > I guess you are willing to revert my patches, but you don't. > > BTW, stop breaking things. All should be working as used be > (except a little difference) before your commit. This is starting to get silly, from where I sit. This entire thing would be much simpler if you guys started posting diff's of proposed changes to this list for open discussion. This is one of those cases where the propensity to commit changes as soon as possible is turning the repository into a mess of changes and reversions. What's the hurry? Give other people a chance to comment on your work. That's the open source way. -- Jon Parise ([EMAIL PROTECTED]) :: The PHP Project (http://www.php.net/) -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: PHP Embedded (phplib)
On Mon, Sep 30, 2002 at 02:38:18AM +0200, Sascha Schumann wrote: > - The meaning of PHP_NEW_EXTENSION's sapi_class parameter > will be extended to allow a *list* of SAPI module names > with which the extension can be compiled. And the absence of this list parameter will infer all known SAPI modules, yes? -- Jon Parise ([EMAIL PROTECTED]) :: The PHP Project (http://www.php.net/) -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] emalloc v. malloc
Could someone please describe the differences between malloc() and emalloc()? I'd like to know when I should be using one instead of the other. I don't see this topic mentioned in the coding standards, and they appear to be used interchangeably (although not mixed) throughout the current code. -- Jon Parise ([EMAIL PROTECTED]) :: The PHP Project (http://www.php.net/) -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] getopt function
I wrote a simply getopt function for PHP (based on the system's
getopt() call). This is not meant to compete with the getopt PEAR
class but rather to provide simple command line parsing capabilities
to CLI-based PHP scripts.
If there are no objections, I'd like to commit this over the weekend
(at which point I'll also write the associated documentation).
Comments are, of course, welcome.
--
Jon Parise ([EMAIL PROTECTED]) :: The PHP Project (http://www.php.net/)
Index: basic_functions.c
===
RCS file: /repository/php4/ext/standard/basic_functions.c,v
retrieving revision 1.514
diff -u -r1.514 basic_functions.c
--- basic_functions.c 27 Sep 2002 23:42:38 - 1.514
+++ basic_functions.c 28 Sep 2002 02:25:20 -
@@ -498,6 +498,10 @@
PHP_FE(putenv,
NULL)
#endif
+#ifdef HAVE_GETOPT
+ PHP_FE(getopt,
+ NULL)
+#endif
+
PHP_FE(microtime,
NULL)
PHP_FE(gettimeofday,
NULL)
@@ -1334,6 +1338,92 @@
efree(pe.key);
RETURN_FALSE;
}
+ }
+}
+/* }}} */
+#endif
+
+#ifdef HAVE_GETOPT
+/* {{{ proto array getopt(string options)
+ Get options from the command line argument list */
+PHP_FUNCTION(getopt)
+{
+ char *options = NULL, **argv = NULL;
+ char opt[1] = { '\0' };
+ int ch, argc, options_len = 0, pos = 0;
+ zval *val, **args;
+
+ if (zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC, "s",
+ &options, &options_len) ==
+FAILURE) {
+ return;
+ }
+
+ /*
+* Get argv from the global symbol table. We calculate argc ourselves
+* in order to be on the safe side, even though it is also available
+* from the symbol table.
+*/
+ if (zend_hash_find(&EG(symbol_table), "argv", sizeof("argv"),
+ (void **) &args) != FAILURE) {
+ zval **arg;
+
+ argc = zend_hash_num_elements(Z_ARRVAL_PP(args));
+
+ /* Attempt to allocate enough memory to hold all of the arguments. */
+ if ((argv = (char **) malloc(argc * sizeof(char *))) == NULL) {
+ RETURN_FALSE;
+ }
+
+ /* Reset the array indexes. */
+ pos = 0;
+ zend_hash_internal_pointer_reset(Z_ARRVAL_PP(args));
+
+ /* Iterate over the hash to construct the argv array. */
+ while (zend_hash_get_current_data(Z_ARRVAL_PP(args),
+
+(void **)&arg) == SUCCESS) {
+ argv[pos++] = strdup(Z_STRVAL_PP(arg));
+ zend_hash_move_forward(Z_ARRVAL_PP(args));
+ }
+ }
+
+ /* Initialize the return value as an array. */
+ if (array_init(return_value)) {
+ RETURN_FALSE;
+ }
+
+ /* Create a standard zval to hold the argument string. */
+ MAKE_STD_ZVAL(val);
+
+ /* Disable getopt()'s error messages. */
+ opterr = 0;
+
+ while ((ch = getopt(argc, argv, options)) != -1) {
+
+ /* Skip unknown arguments. */
+ if (ch == '?') {
+ continue;
+ }
+
+ /* Prepare the option character and the argument string. */
+ opt[0] = ch;
+ ZVAL_STRING(val, optarg, 1);
+
+ /* Add this option / argument pair to the result hash. */
+ if (zend_hash_update(HASH_OF(return_value), opt, 1, (void *)&val,
+sizeof(zval *), NULL) ==
+FAILURE) {
+ /* TODO: Raise error and free argv */
+ RETURN_FALSE;
+ }
+ }
+
+ /* Free the memory allocated to the argv array. */
+ if (argv) {
+ for (pos = 0; pos < argc; pos++) {
+ if (argv[pos]) {
+ free(argv[pos]);
+ }
+ }
+ free(argv);
}
}
/* }}} */
Index: basic_functions.h
===
RCS file: /repository/php4/ext/standard/basic_functions.h,v
retrieving revision 1.107
diff -u -r1.107 basic_functions.h
--- basic_funct
Re: [PHP-DEV] patch to restrict database access for ext/pgsql
On Thu, Sep 26, 2002 at 02:15:52PM -0400, Jim Mercer wrote: > this patch adds the config variable pgsql.allowed_dblist [snip] > although it can be accomplished by other means, setting the variable to a > value of ":" effectively locks the code out of pgsql. Isn't it generally better (where "better" means more secure, efficient, and easily maintained) to handle database access control using PostgreSQL's native access mappings? -- Jon Parise ([EMAIL PROTECTED]) :: The PHP Project (http://www.php.net/) -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] autoconf version
On Thu, Sep 26, 2002 at 11:44:37AM -0400, Dan Kalowsky wrote: > I've been getting this on my OSX machine for awhile. Thats because > autoconf 2.53 is the default for the dev tools. Seems to be working > just fine. > > Not entirely sure whats "buggy" about it, but I don't keep up on the > whole autoconf world either. As I recall (check the archives to be certain), autoconf 2.53 does not always properly update its cache when parts of the autoconf chain (e.g. an extension's config.m4 file) are changed. This results in autoconf building a 'configure' script based on a stale cache. -- Jon Parise ([EMAIL PROTECTED]) :: The PHP Project (http://www.php.net/) -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: sockets extension...pecl it
On Thu, Sep 12, 2002 at 10:54:14AM -0700, Brian Lalor wrote: > > On Thu, Sep 12, 2002 at 10:41:47AM -0700, Brian Lalor wrote : > > > Where are the current docs? > > [...] > > > > php.net/sockets > > By which you mean the source? I asked if there was documentation outside of > the source files. Yes, the documentation is at http://www.php.net/sockets (which redirects to the manual entry). -- Jon Parise ([EMAIL PROTECTED]) :: The PHP Project (http://www.php.net/) -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/standard array.c basic_functions.c php_array.h
On Wed, Sep 11, 2002 at 06:13:48PM -, Andrey Hristov wrote:
> andreyWed Sep 11 14:13:48 2002 EDT
>
> Modified files:
> /php4/ext/standardarray.c basic_functions.c php_array.h
> Log:
> New function added : array_diff_assoc() . Like array_diff() but does
> additional checks on key values. Test script will be added too.
[snip]
> +PHP_FUNCTION(array_diff)
> +{
> + php_array_diff(INTERNAL_FUNCTION_PARAM_PASSTHRU, 0 TSRMLS_CC);
> +}
[snip]
> +PHP_FUNCTION(array_diff_assoc)
> +{
> + php_array_diff(INTERNAL_FUNCTION_PARAM_PASSTHRU, 1 TSRMLS_CC);
> +}
Looks good overall, but I would suggest using #define'd values for the
'behavior' parameter instead of explicitly passing 0 and 1 as magic
numbers.
e.g.:
#define DIFF_NORMAL 0
#define DIFF_ASSOC 1
php_array_diff(INTERNAL_FUNCTION_PARAM_PASSTHRU, DIFF_ASSOC TSRMLS_CC);
You get the idea. =)
--
Jon Parise ([EMAIL PROTECTED]) :: The PHP Project (http://www.php.net/)
--
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Default extensions (was: mbstring)
On Mon, Sep 02, 2002 at 03:52:50PM -0400, Dan Kalowsky wrote: > > If we should reduce number of modules built by default, 1st > > module should be MySQL. Removing MySQL does not cause any > > technical problems at all. > > I'll agree to that as well. +1 on removing --with-mysql as a default. > Although realize I'm also +1 on removing any default modules that are not > essential to PHP's running. After some thought, I think I agree with this (disable by default) approach, as well. For instance, if you want just PostgreSQL support, you not only have to --with-pgsql but also --disable-mysql[*]. I don't think there's any harm in asking MySQL users to --enable-mysql support if that's why they want, even if it is purportedly the most popular RDBMS with PHP. Chances are that those same users will likely need to set at least one other ./configure option, anyway. It's much easier, conceptually, to tell PHP users that "everything is off by default" than "look at the './configure --help' output" to figure out if you need to explicitly enable (or disable) something. Of course, I'm making general claims without providing any kind of reliable figures here. Perhaps it would be interesting to conduct some kind of anonymous PHP extension survey to see how many people configure / use which modules. [*] Not that MySQL support harms anything, but why compile something you're not going to use? -- Jon Parise ([EMAIL PROTECTED]) . Information Technology (2001) http://www.csh.rit.edu/~jon/ : Computer Science House Member -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [PHP-CVS] cvs: php4(apache_hooks) /sapi/apache mod_php4.c
On Tue, Aug 27, 2002 at 02:41:53PM -, George Schlossnagle wrote: > gschlossnagle Tue Aug 27 10:41:53 2002 EDT > > Modified files: (Branch: apache_hooks) > /php4/sapi/apache mod_php4.c > Log: > Replaced handler loading commands such that what was > > php_value uri_handler /tmp/foo.php > > is now > > phpUriHandler /tmp/foo.php It might be nice to keep the directives more unified, e.g.: php_uri_handler /tmp/foo.php Or perhaps: php_handler uri /tmp/foo.php php_handler readpost /tmp/foo.php -- Jon Parise ([EMAIL PROTECTED]) . Information Technology (2001) http://www.csh.rit.edu/~jon/ : Computer Science House Member -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Module startup/shutdown in PHP extensions
On Fri, Jul 19, 2002 at 07:42:41AM +0200, David Eriksson wrote: > > Now the problem is when I start apache (net start apache) php seems to call > > the module startup function and then it calls the module shutdown function > > immediately afterwards. The request startup and shutdown functions seem to > > work as expected, i.e. they get called when I make a request to apache. > > > > If I then stop apache (net stop apache) the module shutdown function gets > > called as expected. It's just when starting that the problem occurs. Is > > this the expected behaviour and if so is there anyway of telling in the > > module shutdown function if the module really is shutting down or have I > > done something completely wrong? > > I have seen this behaviour too, I guess PHP just works this way, it calls > the module startup and shutdown function pair once on initilization. I'm only guessing, but that may occur when Apache does it's initial fork(s). It's been a while since I worked with the Apache module API, though. -- Jon Parise ([EMAIL PROTECTED]) . Information Technology (2001) http://www.csh.rit.edu/~jon/ : Computer Science House Member -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] TSRM macros
Is there a reference somewhere that describes how the TSRM macros should be used? I understand the differences between the various macros, but I'd like to read some detail concerning when the context should be passed into a function and when calling TSRM_FETCH() would be acceptable. -- Jon Parise ([EMAIL PROTECTED]) . Information Technology (2001) http://www.csh.rit.edu/~jon/ : Computer Science House Member -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] PiP - Python in PHP
In my spare time (huh), I've been working on a PHP extension that allows the Python language interpretter to be embedded in PHP. This allows a PHP developer to instantiate and manipulate Python objects from within PHP (similar to the Java extension). There is also limited support for accessing PHP data from within the embedded Python environment, as well. All of the appropriate type conversions are performed by the extension. I just put together a web page that describes things in a bit more detail. It's located here: http://www.csh.rit.edu/~jon/projects/pip/ There's a public distribution of the extension at the bottom. Feel free to download and play. At the moment, I am only able to provide a Visual Studio project for building the extension. Putting together a config.m4 file shouldn't be hard; I just haven't done it yet. This is far from finished, but I'm hoping those of you that are interested in the idea will take a few minutes to download and build what I have so far. I'm mostly after general feedback and suggestions. And if you spot a bug, I'd like to hear about that, too. =) -- Jon Parise ([EMAIL PROTECTED]) . Information Technology (2001) http://www.csh.rit.edu/~jon/ : Computer Science House Member -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Errors when building HEAD
On Wed, May 22, 2002 at 09:44:35AM +0200, Martin Jansen wrote: > On Wed, 22 May 2002 09:21:47 +0200, Markus Fischer wrote: > > >autoconf 2.53 isn't supposed to work. Try with 2.13 > > After downgrading to 2.13, I now get the error messages on > can find in the attached buildconf_errors.txt. After running > "./configure" then results in: > > checking whether to include debugging 2.13... ./configure: line 11416: > syntax error near unexpected token `else' > ./configure: line 11416: `else' > > > Any clues? Try running ./cvsclean and then ./buildconf. -- Jon Parise ([EMAIL PROTECTED]) . Information Technology (2001) http://www.csh.rit.edu/~jon/ : Computer Science House Member -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PATCH - improvements for imap_headerinfo() (fwd)
On Mon, May 13, 2002 at 12:35:12AM +0300, Jani Taskinen wrote: Reviewed and committed. - Jon > >Can you check this patch too? :) > >--Jani > > -- Forwarded message -- > Date: 24 Apr 2002 15:02:45 -0400 > From: Adam Kauffman <[EMAIL PROTECTED]> > To: Jani Taskinen <[EMAIL PROTECTED]> > Cc: [EMAIL PROTECTED] > Subject: Re: [PHP-DEV] PATCH - improvements for imap_headerinfo() > > These changes don't (although I realize you shouldn't just take my word > for it) break the functionality of imap_headerinfo(). It just is a > streamlined way of doing it. > > The function as it stands does a mail_fetchheader_full(), takes the > result of that, and turns it into an envelope object. Afterwards, it > has to free that object. The c-client provides a way to get just the > envelope with mail_fetchenvelope(). It is beneficial to use this for a > few reasons: > > 1. As you can see it makes the code much simpler > 2. It is faster. For each message you don't have to fetch full headers > and turn them into an envelope object. You can simply just get the > envelope object. > 3. Simpler for the IMAP server. Instead of making it do a BODY.PEEK, it > just has to fetch the envelope (which some IMAP servers cache). > > Adam > > On Wed, 2002-04-24 at 14:33, Jani Taskinen wrote: > > > > What was this patch supposed to do again? > > At first glance it looks like it's modifying the > > imap_headerinfo() function quite dramatically and > > propably breaks it too.. > > > > Have you compared the output of this function without > > this patch and with it and does it return the same kind > > of object? (and send patches as attachements..) > > > > --Jani -- Jon Parise ([EMAIL PROTECTED]) . Information Technology (2001) http://www.csh.rit.edu/~jon/ : Computer Science House Member -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] IMAP module efficiency improvements
On Fri, May 10, 2002 at 02:49:12PM -0400, Rob Siemborski wrote: > Last summer I sent in some patches to speed up the IMAP module's dealing > with large mailboxes. At the time I noted that there were similar > problems with other parts of the module, but I didn't have time to fix > them then. > > Since I still see the problems in 4.2.0 (and I've suddenly had a need to > improve performance with large #'s of mailboxes), I went ahead and > finished the patch for folder lists. > > The changes to php_imap.c and php_imap.h are attached. Basically the same > things that I did to the message list last year. > > If someone could briefly look these over and commit them that would be > very helpful. Your changes look good, so I just committed them. They probably won't be included in the 4.2.1 release, however. -- Jon Parise ([EMAIL PROTECTED]) . Information Technology (2001) http://www.csh.rit.edu/~jon/ : Computer Science House Member -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] How may I use trim?
On Thu, May 09, 2002 at 04:11:39PM -0500, Andrew Lindeman wrote: [Message reformated due to evil top-posting; don't do that] > > I am developing an extension and I would like to use the trim function inside >one of my functions. > > > > I have seen that I can do it calling the php_trim2 function. > > > > Is this the appropriate way or is there another? > > Wrong list. This is the development OF php not WITH php. Please use > php-general(@lists.php.net) for these sort of questions. Actually, unless I'm misreading the original question, he wants to know how to call a function from one extenion inside of another (from C-land). -- Jon Parise ([EMAIL PROTECTED]) . Information Technology (2001) http://www.csh.rit.edu/~jon/ : Computer Science House Member -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] chora.php.net down
On Mon, Apr 15, 2002 at 02:24:13PM +0200, Roman Neuhauser wrote: > what's up? any estimates of the downtime? Both cvs.php.net and chora.php.net appear to be up now. -- Jon Parise ([EMAIL PROTECTED]) . Information Technology (2001) http://www.csh.rit.edu/~jon/ : Computer Science House Member -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Uploading new release
Apologies; I sent this to the wrong list. -- Jon Parise ([EMAIL PROTECTED]) . Information Technology (2001) http://www.csh.rit.edu/~jon/ : Computer Science House Member -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Uploading new release
I've been trying to upload a new version of the Log package, but I keep running into the same problem. I'll be able to upload the new package, but after a "verify" it, it redirects me back to the login authentication page and asks me to re-enter my username and password. I can't seem to break this loop, so the release is never successfully uploaded. Is this a site bug, or am I doing something wrong? -- Jon Parise ([EMAIL PROTECTED]) . Information Technology (2001) http://www.csh.rit.edu/~jon/ : Computer Science House Member -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Build failure in snprintf.[ch]
On Wed, Apr 10, 2002 at 08:49:21PM -0400, Jon Parise wrote: > Under FreeBSD with the latest HEAD cvs code: > > main/snprintf.lo: In function `ap_php_conv_fp': > /home/jon/build/php4/main/snprintf.c:152: undefined reference to `ap_php_fcvt' > /home/jon/build/php4/main/snprintf.c:154: undefined reference to `ap_php_ecvt' > main/spprintf.lo: In function `xbuf_format_converter': > /home/jon/build/php4/main/spprintf.c:489: undefined reference to `ap_php_gcvt' > *** Error code 1 Fixed by Marcus Börger main/snprintf.c:1.13. -- Jon Parise ([EMAIL PROTECTED]) . Information Technology (2001) http://www.csh.rit.edu/~jon/ : Computer Science House Member -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Bug #16552 Updated: Undefined macro `AC_PROG_LIBTOOL'
On Thu, Apr 11, 2002 at 07:51:49AM -0700, Rasmus Lerdorf wrote: > I get the same in current HEAD > > autoconf 2.13 > automake 1.4 > libtool 1.3.5 You need libtool 1.4+ to build HEAD / 4.2. That's a pain under FreeBSD because libtool 1.3.5 is the latest version in the ports tree, so you need to build and install libtool 1.4 yourself. -- Jon Parise ([EMAIL PROTECTED]) . Information Technology (2001) http://www.csh.rit.edu/~jon/ : Computer Science House Member -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Build failure in snprintf.[ch]
Under FreeBSD with the latest HEAD cvs code: main/snprintf.lo: In function `ap_php_conv_fp': /home/jon/build/php4/main/snprintf.c:152: undefined reference to `ap_php_fcvt' /home/jon/build/php4/main/snprintf.c:154: undefined reference to `ap_php_ecvt' main/spprintf.lo: In function `xbuf_format_converter': /home/jon/build/php4/main/spprintf.c:489: undefined reference to `ap_php_gcvt' *** Error code 1 -- Jon Parise ([EMAIL PROTECTED]) . Information Technology (2001) http://www.csh.rit.edu/~jon/ : Computer Science House Member -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Weird configure problem
Am I the only one seeing this: checking size of char... configure: error: cannot compute sizeof (char), 77 This is with the latest PHP cvs, autoconf-2.53, and automake-1.5 under FreeBSD. I last built PHP successfully on March 26. I'll investigate this further myself in a few days when I have more free time, but I figured I'd at least ask here in case it looks obvious to someone. -- Jon Parise ([EMAIL PROTECTED]) . Information Technology (2001) http://www.csh.rit.edu/~jon/ : Computer Science House Member -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Build failure in mime_magic
In file included from main/internal_functions.c:47: /home/jon/build/php4/ext/mime_magic/php_mime_magic.h:34: warning: `ERROR' redefined /usr/local/include/c-client/mail.h:408: warning: this is the location of the previous definition In file included from main/internal_functions.c:47: /home/jon/build/php4/ext/mime_magic/php_mime_magic.h:160: conflicting types for `uncompress' /usr/include/zlib.h:639: previous declaration of `uncompress' *** Error code 1 -- Jon Parise ([EMAIL PROTECTED]) . Information Technology (2001) http://www.csh.rit.edu/~jon/ : Computer Science House Member -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] iconv configure problem
On Tue, Mar 19, 2002 at 01:30:22PM +0200, Jani Taskinen wrote:
>Does this attached patch fix it?
>(nice to have the checks in one place :)
Yes, everything is now working fine. Please go ahead and commit
the changes, and thanks for you quick reply.
> >The latest iconv detection code doesn't appear to account for the
> >case where iconv_open() is defined in libiconv. It only checks
> >for iconv_open() in libc and libiconv_open() in libiconv.
> >
> >This breaks the build under FreeBSD unless the GNU libiconv port
> >is installed.
> >
> >
>
> Index: acinclude.m4
> ===
> RCS file: /repository/php4/acinclude.m4,v
> retrieving revision 1.164
> diff -u -u -r1.164 acinclude.m4
> --- acinclude.m4 17 Mar 2002 21:09:20 - 1.164
> +++ acinclude.m4 19 Mar 2002 11:27:38 -
> @@ -1347,7 +1347,7 @@
> AC_DEFUN(PHP_SETUP_ICONV, [
>found_iconv=no
>
> - AC_CHECK_LIB(c, iconv_open, [
> + AC_CHECK_FUNCS(iconv libiconv, [
> AC_DEFINE(HAVE_ICONV, 1, [ ])
> found_iconv=yes
>], [
> @@ -1370,7 +1370,7 @@
> if test -f $ICONV_DIR/lib/lib${iconv_lib_name}.a ||
> test -f $ICONV_DIR/lib/lib${iconv_lib_name}.$SHLIB_SUFFIX_NAME
> then
> - PHP_CHECK_LIBRARY($iconv_lib_name, libiconv_open, [
> + PHP_CHECK_LIBRARY($iconv_lib_name, libiconv, [
> found_iconv=yes
> PHP_ADD_LIBRARY_WITH_PATH($iconv_lib_name, $ICONV_DIR/lib, $1)
> AC_DEFINE(HAVE_ICONV, 1, [ ])
--
Jon Parise ([EMAIL PROTECTED]) . Information Technology (2001)
http://www.csh.rit.edu/~jon/ : Computer Science House Member
--
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] iconv configure problem
The latest iconv detection code doesn't appear to account for the case where iconv_open() is defined in libiconv. It only checks for iconv_open() in libc and libiconv_open() in libiconv. This breaks the build under FreeBSD unless the GNU libiconv port is installed. -- Jon Parise ([EMAIL PROTECTED]) . Information Technology (2001) http://www.csh.rit.edu/~jon/ : Computer Science House Member -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Additional warning for mail()
On Sat, Mar 16, 2002 at 03:15:07AM +0100, Markus Fischer wrote: > If no one objects I'ld like to commit the following patch > which raises an extra warning message when using mail() on > unix systems and the shell required for popen() can't be > executed (tested on linux/freebsd). No objection here. -- Jon Parise ([EMAIL PROTECTED]) . Information Technology (2001) http://www.csh.rit.edu/~jon/ : Computer Science House Member -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] buildconf for 4.1.2 breaks Solaris 8
On Tue, Mar 12, 2002 at 06:33:34PM -0500, J Smith wrote: > This is the first time I've tried installing on Solaris, so maybe I'm way > off, but anyways... > > Here's how things look: > > # ./buildconf > rebuilding configure > configure.in:124: warning: AC_PROG_LEX invoked multiple times > rebuilding main/php_config.h.in > > # ./configure [any combination of configure arguments, it breaks regardless > of what I use] > . > . > . > . > ./configure: syntax error at line 3399: `fi' unexpected > # What version of autoconf are you using? You may need to step back to autoconf-2.13. -- Jon Parise ([EMAIL PROTECTED]) . Information Technology (2001) http://www.csh.rit.edu/~jon/ : Computer Science House Member -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] php_ticks.c patch
The following patch quells a warning under 'cc: WorkShop
Compilers 5.0 98/12/15 C 5.0' (Solaris 8). I think it's
theoretically correct, but I'd like a second opinion before I
commit the change.
--
Jon Parise ([EMAIL PROTECTED]) . Information Technology (2001)
http://www.csh.rit.edu/~jon/ : Computer Science House Member
Index: php_ticks.c
===
RCS file: /repository/php4/main/php_ticks.c,v
retrieving revision 1.14
diff -u -r1.14 php_ticks.c
--- php_ticks.c 28 Feb 2002 08:27:04 - 1.14
+++ php_ticks.c 4 Mar 2002 10:49:31 -
@@ -52,7 +52,7 @@
{
TSRMLS_FETCH();
- zend_llist_del_element(&PG(tick_functions), func,
+ zend_llist_del_element(&PG(tick_functions), (void *)func,
(int(*)(void*,
void*))php_compare_tick_functions);
}
--
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: 4.2.0 & CLI
On Thu, Feb 28, 2002 at 12:10:23AM -, Jim Winstead wrote: > > 1. If you compile CGI binary and then issue 'make install' it will be > > installed in $PREFIX/bin, then CLI will be put in the same place overwriting > > it. Any suggestions on what to do in this situation? > > imho, the cgi binary should get called php.cgi. +1 -- Jon Parise ([EMAIL PROTECTED]) . Information Technology (2001) http://www.csh.rit.edu/~jon/ : Computer Science House Member -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] fmod() function
On Thu, Feb 21, 2002 at 08:08:28AM +0200, Andi Gutmans wrote: > Just realized now you're talking about doubles :) > Never mind my previous Email... Would it be worth extending the engine to apply the fmod() behavior to the % operator when operating on doubles? -- Jon Parise ([EMAIL PROTECTED]) . Information Technology (2001) http://www.csh.rit.edu/~jon/ : Computer Science House Member -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] CVS account requests
I was thinking it might be reasonable to a request that a person asking for a CVS account should first present a small contribution. For example, someone interested in translating documentation should submit a translated chapter with their account request, or a person that wants to work on the code should first submit at least one patch or reference some of their bug reports. Would this be going too far? -- Jon Parise ([EMAIL PROTECTED]) . Information Technology (2001) http://www.csh.rit.edu/~jon/ : Computer Science House Member -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Trimming subject lines
I think it cool that discussions travel between php-dev, php-cvs, pear-dev, and the zend-engin2 mailing lists, but I'd like to ask all of you to take the time to trim the subject lines on occasion. By the time a message has traversed two or three list, the prefixes take up a good thirty characters of screen real estate, and the subject is likely no longer accurate in terms of the way the discussion has evolved. [end of communication] -- Jon Parise ([EMAIL PROTECTED]) . Information Technology (2001) http://www.csh.rit.edu/~jon/ : Computer Science House Member -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Negative integers as array keys
The PHP manual[1] states that negative integer values are not valid array keys, but a simple test proves otherwise. Has this changed, or is this behavior simply not guranteed or supported? [1] http://www.php.net/manual/en/language.types.array.php -- Jon Parise ([EMAIL PROTECTED]) . Information Technology (2001) http://www.csh.rit.edu/~jon/ : Computer Science House Member -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Bug report subject lines
On Thu, Feb 07, 2002 at 03:26:47PM -, James Cox wrote: > > A separate "php-bugs" mailing list could be created as a sort of > > sublist of php-dev. I think php-dev could then just list > > php-bugs as a subscriber. > > The problem then, i think, is that the message would then say: > > [PHP-DEV] [PHP-BUG] . > > it wouldn't actually create a good fix unfortunately. i can't think of > anything else, apart from removing stuff from the subject, and/or setting it > like this: > > [PHP-DEV] B# nn Good point. The solution may be to have the two lists share the same subscription list. -- Jon Parise ([EMAIL PROTECTED]) . Information Technology (2001) http://www.csh.rit.edu/~jon/ : Computer Science House Member -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Bug report subject lines
On Thu, Feb 07, 2002 at 03:16:50PM -, James Cox wrote: > > > "[PHP-BUG]15415: " would represent savings of 14 characters from each > > > > Plese with a space after ']' so it reads: > > "[PHP-BUG] 15415: " > > Actually, that wouldn't be possible unless there was a new list. The list > management software prepends the list name to each message. I wonder, > however, if there was some way to alias the list to another. A separate "php-bugs" mailing list could be created as a sort of sublist of php-dev. I think php-dev could then just list php-bugs as a subscriber. -- Jon Parise ([EMAIL PROTECTED]) . Information Technology (2001) http://www.csh.rit.edu/~jon/ : Computer Science House Member -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [PHP-CVS] cvs: php4 / configure.in
On Sat, Feb 02, 2002 at 06:21:59AM -, Jon Parise wrote: > jon Sat Feb 2 01:21:59 2002 EDT > > Modified files: > /php4 configure.in > Log: > Revert revision 1.294. > > This commit broke things in interesting ways under FreeBSD. By adding these > default header files to every header check, a number of subsequent checks > failed (due to unsatisfied header file dependencies). This occured because > , for example, requires . In other words, these > default includes are not autonomous and don't make workable defaults. This fixes the problem some people were seeing where the Zend build would fail early on, saying that it couldn't find va_list. This was a real bitch to track down based on that error. va_list is defined by , which wasn't getting included in Zend due to the HAVE_STDARG_H check. That wasn't getting defined because the configure run was failing (under FreeBSD) for nearly every header file check. Anyway, FreeBSD builds are now working with the latest cvs code. -- Jon Parise ([EMAIL PROTECTED]) . Information Technology (2001) http://www.csh.rit.edu/~jon/ : Computer Science House Member -- 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] Build failure on BSD (current cvs)
On Fri, Feb 01, 2002 at 09:28:31AM -, James Cox wrote: > Is it just me having a really shitty day, or has anyone else noticed that > current CVS fails on BSD? I have the same problem here, but I haven't had the time to investigate it in detail yet. Hopefully, it will look obvious to the person that broke things. After spending a couple of hours making sure that PHP4 cvs builds cleanly on Solaris last week, I'm beginning to wonder whether the PHP developers need to be reminded that all the world is not running GNU/Linux. -- Jon Parise ([EMAIL PROTECTED]) . Information Technology (2001) http://www.csh.rit.edu/~jon/ : Computer Science House Member -- 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] Warnings in current HEAD
On Sun, Jan 27, 2002 at 09:47:45AM +0100, Sebastian Bergmann wrote: > math.c > c:\home\php\php4\ext\standard\math.c(37): warning C4005: 'zend_isinf': > Macro redefined, previous definition in > ..\Zend\zend_config.w32.h(50) This should be fixed in cvs now. Thanks for mentioning it. -- Jon Parise ([EMAIL PROTECTED]) . Information Technology (2001) http://www.csh.rit.edu/~jon/ : Computer Science House Member -- 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] Preview of PHP 5
On Fri, Jan 18, 2002 at 07:48:01PM +0200, Andi Gutmans wrote: > Well the definition of alpha is before all features are in so I think it > should be OK but I don't really care as long as the changes get a bigger > audience. The other option is to call it a "test" release. -- Jon Parise ([EMAIL PROTECTED]) . Information Technology (2001) http://www.csh.rit.edu/~jon/ : Computer Science House Member -- 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] adding finite(), isnan(), isinf()
On Fri, Jan 04, 2002 at 07:12:38PM -0800, Jim Winstead wrote: > these are the standard C library names. are people going to insist > they be phpified? is_finite() is_nan(), is_infinite()? No more than I'd request strlen() be renamed str_len(). =) -- Jon Parise ([EMAIL PROTECTED]) . Information Technology (2001) http://www.csh.rit.edu/~jon/ : Computer Science House Member -- 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] Always building command line PHP
On Thu, Jan 03, 2002 at 09:37:38PM +, [EMAIL PROTECTED] wrote: > > It should still be possible to build a separate CGI executable with a > > different php.ini path for those sites that require it. > > Don't get too stuck on the idea that PHP at the command line is only > for CGI. In fact I don't do CGI any more. I am phasing out ALL perl > CGI scripts because after seeing PHP as a module I can't stand the > extra time it takes to execute the external program. PHP CGI has the > same problem. I just say NO to all CGI. Okay, this is kind of getting out of hand. I don't really disagree with any of your points. All I was saying is that a normal build of PHP (say, for the Apache SAPI interface) should also include a CGI build, for command line usage. This CGI binary will be necessary for the PEAR tools. The fact that it might not be optimized for the user's command line scripting needs is irrelevant because they can go ahead and build their own custom CGI binary by executing 'configure' a second time. In other words, I'm talking about extending the default build to include a default CGI binary build. -- Jon Parise ([EMAIL PROTECTED]) . Information Technology (2001) http://www.csh.rit.edu/~jon/ : Computer Science House Member -- 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] Always building command line PHP
On Thu, Jan 03, 2002 at 04:26:38PM -0500, J Smith wrote: > Just a little annoyance I guess. Nothing to get in knots over. But in the > end, I would prefer separate php.ini files, maybe something like > php-cli.ini for the default CLI file and and php.ini for the Apache/web > server module default. If php-cli.ini doesn't exist, the CLI can always > fall back on php.ini, which would be the default in any case. I agree that it's sometimes necessary to have different configuration files, but I don't consider it a necessity. It should still be possible to build a separate CGI executable with a different php.ini path for those sites that require it. I don't think it's necessary to alter the build process to make that the rule, though. Your suggestion of a separate php-cli.ini has merit, but who will the php binary know when it's being used for CLI purposes and not as a CGI? -- Jon Parise ([EMAIL PROTECTED]) . Information Technology (2001) http://www.csh.rit.edu/~jon/ : Computer Science House Member -- 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] Always building command line PHP
On Wed, Jan 02, 2002 at 04:39:24PM +, [EMAIL PROTECTED] wrote: > One thing to consider, at least the php.ini location needs to be > different between the module and command line compiles. I suspect most > people will have quite a few other differences in ./configure options > between them too. I know I do. I don't see the necessity of requiring different php.ini files. You can specify the php.ini by using the -c option to the php binary, as well. -- Jon Parise ([EMAIL PROTECTED]) . Information Technology (2001) http://www.csh.rit.edu/~jon/ : Computer Science House Member -- 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] Always building command line PHP
On Wed, Jan 02, 2002 at 09:33:32PM +0200, Andi Gutmans wrote: > Creating a CLI sapi module w/o all of the CGI crap is extremely easy. > What might be more challenging is fixing the build so that it always builds > the cli. I think this should be considered a high priority. The PEAR tools require the command line version of PHP, so always building it would be a good step toward making the PEAR stuff less esoteric. Let's focus on the best way to do this before addressing the plethora of other issues related to bringing PEAR up to par. -- Jon Parise ([EMAIL PROTECTED]) . Information Technology (2001) http://www.csh.rit.edu/~jon/ : Computer Science House Member -- 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: [PEAR-DEV] PECL (was PHP 5)
On Wed, Jan 02, 2002 at 08:09:10PM +0100, Martin Jansen wrote: > >I suggest we move PECL either to its own mailing list or to php-dev. > > +1 for it's own mailing list. Additionally we could perhaps set up > an own CVS module for PECL. (Currently it resides in /pear/PECL.) > Guys? I think I agree on both points ([EMAIL PROTECTED] and /PECL). -- Jon Parise ([EMAIL PROTECTED]) . Information Technology (2001) http://www.csh.rit.edu/~jon/ : Computer Science House Member -- 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] Moving extensions to PECL
On Mon, Dec 31, 2001 at 01:58:42PM -0500, Joao Prado Maia wrote: > > > > This is definitely not an inclusive list; it's just a start. I > > > > can't imagine a lot of people using these modules, so they seem > > > > like good candidates for removal from the base PHP distribution. > > What about the 'fribidi' extension then ? ;) Okay, before this gets out of hand: I do _not_ want to create a list of extensions to pull from the base distribution. My intensions are simply to try moving a few "standard" extensions out of the base PHP distribution and into PECL to help test the PECL build infrastructure and to standardize the procedure for moving extensions out of the base distribution. I probably should have made that clearer before. I don't want this to turn into a "this extension is too big and is seldom used" kind of thread. We've had enough of those in the past. -- Jon Parise ([EMAIL PROTECTED]) . Information Technology (2001) http://www.csh.rit.edu/~jon/ : Computer Science House Member -- 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] Moving extensions to PECL
On Mon, Dec 31, 2001 at 11:49:02AM -0700, Zak Greant wrote: > > I think the following "standard" extensions should be moved to > > PECL: > > > > ext/cybercash > > ext/icap > > ext/pfpro > > ext/yaz > > > > This is definitely not an inclusive list; it's just a start. I > > can't imagine a lot of people using these modules, so they seem > > like good candidates for removal from the base PHP distribution. > > > > Are there any well-founded objections to this (either in practice > > or principle)? > > We should probably add cybermut to the list as well. Sure, that sounds fine. I suppose removing some of these less frequently used extensions will also help make the QA team's job a little easier, too. -- Jon Parise ([EMAIL PROTECTED]) . Information Technology (2001) http://www.csh.rit.edu/~jon/ : Computer Science House Member -- 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] Moving extensions to PECL
I think the following "standard" extensions should be moved to PECL: ext/cybercash ext/icap ext/pfpro ext/yaz This is definitely not an inclusive list; it's just a start. I can't imagine a lot of people using these modules, so they seem like good candidates for removal from the base PHP distribution. Are there any well-founded objections to this (either in practice or principle)? -- Jon Parise ([EMAIL PROTECTED]) . Information Technology (2001) http://www.csh.rit.edu/~jon/ : Computer Science House Member -- 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] current CVS and MacOSX
On Fri, Dec 21, 2001 at 11:28:02AM -0500, Dan Kalowsky wrote:
> MacOSX 10.1.2 compiling a pull of CVS from today (and frankly the past
> couple of days) has a problem compiling:
>
> /usr/bin/ld: Undefined symbols:
> _inet_pton
Referenced in:
ext/standard/dns.c: if (inet_pton(AF_INET6, ip, &addr6)) {
ext/standard/dns.c: } else if (inet_pton(AF_INET, ip, &addr)) {
> Interesting thing is, there seems to be no references to inet_pton
> anywhere on the OS. Anyone with a suggestion on correcting this?
That's interesting. From INET(3) under FreeBSD 4.4:
STANDARDS
The inet_ntop() and inet_pton() functions conform to X/Open Networking
Services Issue 5.2 (``XNS5.2''). Note that inet_pton() does not accept
1-, 2-, or 3-part dotted addresses; all four parts must be specified and
are interpreted only as decimal values. This is a narrower input set
than that accepted by inet_aton().
HISTORY
These functions appeared in 4.2BSD.
--
Jon Parise ([EMAIL PROTECTED]) . Information Technology (2001)
http://www.csh.rit.edu/~jon/ : Computer Science House Member
--
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] PHP 4.0.6 IMAP BUG
On Thu, Dec 20, 2001 at 10:32:43AM +0100, Markus Fischer wrote: > Glad I didn't, its a bug in ext/imap. Due the pointer > juggling we're accidantly calling fs_free() on something > which was never explicetely malloced. I've a patch here which > takes care of this but I'm not too familiar with imap code. Your patch looks sound enough, although I'm not very familiar with that code, either. I don't see any harm committing it to the HEAD branch. -- Jon Parise ([EMAIL PROTECTED]) . Information Technology (2001) http://www.csh.rit.edu/~jon/ : Computer Science House Member -- 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] PHP 4.0.6 IMAP BUG
On Wed, Dec 19, 2001 at 05:35:53PM +0100, Markus Fischer wrote: > Verified with latest CVS. No time do dig in right now, but note > the crash occurs in the imap library: Please forward the test case and your backtrace to the c-client mailing list: http://www.washington.edu/imap/c-client-list.html -- Jon Parise ([EMAIL PROTECTED]) . Information Technology (2001) http://www.csh.rit.edu/~jon/ : Computer Science House Member -- 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] Adding session save handler?
On Wed, Dec 19, 2001 at 09:02:01AM +0100, [EMAIL PROTECTED] wrote: > Furthermore, I don't think you should add this function as a built-in > session handler, but make it an extension for the PECL repository in > PEAR. Agreed. Very cool idea, though, Yasuo! -- Jon Parise ([EMAIL PROTECTED]) . Information Technology (2001) http://www.csh.rit.edu/~jon/ : Computer Science House Member -- 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-updates
On Tue, Dec 11, 2001 at 07:48:07PM -, Jim Winstead wrote: > > Any idea why bug postings / updates are not longer posted to this list? > > they were being held up by the spam protection. they should make it > through now (and the ones sent in the last few days should start showing > up soon). Too bad. I was enjoying the fact that the list was limited to development discussion. =) -- Jon Parise ([EMAIL PROTECTED]) . Information Technology (2001) http://www.csh.rit.edu/~jon/ : Computer Science House Member -- 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: Headers
On Tue, Dec 11, 2001 at 07:36:18PM +0100, Sebastian Bergmann wrote: > > As I understood it, it is apparently more correct to list the > > individual years than to use a range of dates. The following > > would be therefore be correct: > > > > Copyright (c) 1997, 1998, 1999, 2000, 2001, 2002 The PHP Group > > Ugh, how so? I don't recall the original reference, but it's also mentioned here: http://www.gnu.org/prep/maintain_7.html "Do not abbreviate the year list using a range; for instance, do not write `1996--1998'; instead, write `1996, 1997, 1998'." Unfortunately, the reasoning isn't explained in that document. -- Jon Parise ([EMAIL PROTECTED]) . Information Technology (2001) http://www.csh.rit.edu/~jon/ : Computer Science House Member -- 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: Headers
On Tue, Dec 11, 2001 at 02:18:50PM +0100, Sebastian Bergmann wrote: > > http://www.sebastian-bergmann.de/header_changes.txt > > Quite some > > -Copyright (c) 1997, 1998, 1999, 2000 The PHP Group | > +Copyright (c) 1997-2002 The PHP Group| As I understood it, it is apparently more correct to list the individual years than to use a range of dates. The following would be therefore be correct: Copyright (c) 1997, 1998, 1999, 2000, 2001, 2002 The PHP Group -- Jon Parise ([EMAIL PROTECTED]) . Information Technology (2001) http://www.csh.rit.edu/~jon/ : Computer Science House Member -- 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: Renaming PostgreSQL functions
On Tue, Dec 11, 2001 at 09:06:52PM +0900, Yasuo Ohgaki wrote: > I would like to rename PostgreSQL functions to comfirm > naming/coding standard. Similar change has been done for > MySQL module, AFIAK. I'll take care documentation changes > also. > > Almost all changes are just a matter of adding "_" to > current names, except pg_cmdtuples. The new name is > pg_affected_rows, like MySQL. I sort of prefer the names the way they are. I'd almost prefer to remove the underscores from the MySQL extension (which I'm not suggesting). The two extensions are disimilar in enough ways to make any attempt to unify the interface moot. For example, look at pg_exec() and mysql_query(). These two functions affectively do the same thing and yet they are named differently and accept their arguments in the opposite order. -- Jon Parise ([EMAIL PROTECTED]) . Information Technology (2001) http://www.csh.rit.edu/~jon/ : Computer Science House Member -- 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 #14367: browscap not well documented
On Mon, Dec 10, 2001 at 06:41:45PM +0100, Daniel Lorch wrote: > AFAIK the browscap.ini is not anymore supported/updated. The only > alternative I know of is: > > http://phpsniff.sourceforge.net/ > > any other suggestions? http://cvs.horde.org/co.php/horde/lib/Browser.php http://www.horde.org/papers/oscon2001-horde_tutorial/17_browser.xml.html -- Jon Parise ([EMAIL PROTECTED]) . Information Technology (2001) http://www.csh.rit.edu/~jon/ : Computer Science House Member -- 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] [NEW EXTENSTION]: templates
On Wed, Dec 05, 2001 at 05:11:13PM +0100, Daniel Lorch wrote: > by the way, anyone got an idea what Z.E.N.D. stands for? ZEev aNDi ... last I had heard, anyway. -- Jon Parise ([EMAIL PROTECTED]) . Information Technology (2001) http://www.csh.rit.edu/~jon/ : Computer Science House Member -- 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] Constants
On Mon, Dec 03, 2001 at 08:24:29PM +0200, Andi Gutmans wrote: > a) There are almost no constants in PHP which are case-insensitive (which > aren't user land defined with define()). Actually the only ones I could > find are in the Zend Engine such as TRUE & FALSE which makes sense. All PHP > extensions which use REGISTER_LONG_CONSTANT() and friends use the CONST_CS > (case-sensitive flag). I would like to change these macros to *always* > register as case-sensitive. Unless I missed some extensions this shouldn't > bite anyone as all extensions seem to use CONST_CS. Of course I won't > change the special purpose constants such as TRUE & FALSE which are today > registered as case-insensitive. What do you guys think? I think that makes a lot of sense. Go for it. > b) REGISTER_MAIN_LONG_CONSTANT() and friends (notice the MAIN) are used to > register constants which shouldn't be unloaded when the PHP extension is > unloaded. I can't think of many cases where this is applicable. For > example, if the pspell extension is unloaded I think all of its constants > should be unloaded too. However, this extension is one example of an > extension using the _MAIN_ macro. Can each of you check your extension and > move to REGISTER_LONG_CONSTANT() unless there's a good reason not to? I can't think of a good reason why an extension should leave any remnants of itself lying around once it's unloaded. -- Jon Parise ([EMAIL PROTECTED]) . Information Technology (2001) http://www.csh.rit.edu/~jon/ : Computer Science House Member -- 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] SMTP extension
On Thu, Nov 29, 2001 at 05:33:30PM -, Richard Heyes wrote: > Anyone object to me committing my SMTP extension to PECL?? It could do with > some testing to say the least :) I don't see a problem with adding it to PECL. -- Jon Parise ([EMAIL PROTECTED]) . Information Technology (2001) http://www.csh.rit.edu/~jon/ : Computer Science House Member -- 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] Out of date modules etc
On Fri, Nov 23, 2001 at 02:32:49PM -, James Moore wrote: > CCVS has now been dropped by redhat (it will be replaced by > MCVE), the module doesnt really seem to be supported either. > With sablotron going the same way (for different reasons > though) perhaps we should create a unsupported or and old > directory in the pear c extension repository for these modules > to reside and move them out of php4/ext. Sounds like a plan to me. This will help populate PEAR with some C code, too, which will encourage the development of that part of the PEAR infrastructure. -- Jon Parise ([EMAIL PROTECTED]) . Information Technology (2001) http://www.csh.rit.edu/~jon/ : Computer Science House Member -- 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: is_executable test
On Mon, Nov 12, 2001 at 09:29:27AM +0100, Sascha Schumann wrote: > Anyway, Linux 2.4.13 gives me a permission denied while > FreeBSD 4.4 does not. I guess this check should be removed > from the testfile or it should be combined with an OS-level > check which determines which behaviour is correct for the > current OS. As I recall, I believe that is one of the fundamental varying behaviors between SysV and BSD -style systems. Of course, no one really knows where Linux fits into that mess. =) -- Jon Parise ([EMAIL PROTECTED]) . Information Technology (2001) http://www.csh.rit.edu/~jon/ : Computer Science House Member -- 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] Session variables confusion
On Sun, Nov 11, 2001 at 12:02:56AM +0100, Sebastian Bergmann wrote:
> Environment: Current CVS on Win32.
>
> session_register('a');
> session_register('b');
> session_register('c');
>
> echo 'GLOBALS[a]: ' . ++$GLOBALS['a'] . '';
> echo '_SESSION[b]: ' . ++$_SESSION['b'] . '';
> echo 'HTTP_SESSION_VARS[c]: ' . ++$HTTP_SESSION_VARS['c'] . '';
> ?>
>
> register_globals = On -> Only ++$GLOBALS['a'] is effective
> register_globals = Off -> ++$GLOBALS['a'] is not effective, the other
> two work (ie. the numbers increase on sub-
> sequent requests)
>
> At the conference Rasmus told me that the $HTTP_SESSION_VARS array
> should work in _both_ situations. Is this broken, or intended? I'm
> confused right now - which is a no so uncommon situation nowadays :-)
What about $GLOBALS['HTTP_SESSION_VARS']['a']?
--
Jon Parise ([EMAIL PROTECTED]) . Information Technology (2001)
http://www.csh.rit.edu/~jon/ : Computer Science House Member
--
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] gettext codeset patch
On Thu, Nov 08, 2001 at 09:58:44PM +0100, Rudi Benkovi wrote: > attached is a little patch that adds function bind_textdomain_codeset(), which > allows you to set the output codeset of your translated strings. It doesn't > break backwards compatibility with older releases of gettext. > > Hopefully someone will test & commit this. It seems to work alright here, so I just committed it. -- Jon Parise ([EMAIL PROTECTED]) . Information Technology (2001) http://www.csh.rit.edu/~jon/ : Computer Science House Member -- 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] Singleton
On Mon, Oct 22, 2001 at 09:12:29PM -0200, Victor Hugo Oliveira wrote: This would be more appropriate on php-general, btw. > Has anyone any ideas on how to implement a Singleton in PHP4 ? The Horde code uses singleton's extensively. For example: http://cvs.horde.org/co.php/horde/lib/Auth.php -- Jon Parise ([EMAIL PROTECTED]) . Information Technology (2001) http://www.csh.rit.edu/~jon/ : Computer Science House Member -- 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: [Zend Engine 2] Re: [PHP-DEV] RE: [Zend Engine 2] Re: [PHP-DEV] Re: [Zend Engine 2] Re: [PHP-DEV] Re: [Zend Engine 2] Re: [PHP-DEV] Re: [Zend Engine 2] Re: [PHP-DEV] Re: [Zend Engine 2] namespaces ambiguity
On Mon, Oct 01, 2001 at 06:19:01PM +0200, Harald Radi wrote:
> > > i don't either, but how else will you bind constants to a class /
> > > namespace ?
> >
> > echo Foo::CONSTANT;
>
> yes, but how do you define them ?
>
> if it's like this:
>
> namespace Foo;
> define("CONSTANT", 123);
On perhaps optionally:
define("CONSTANT", 123, 'Foo');
... which will define the constant in the namespace 'Foo'.
It might also make sense to allow:
define("Foo::CONSTANT", 123);
--
Jon Parise ([EMAIL PROTECTED]) . Information Technology (2001)
http://www.csh.rit.edu/~jon/ : Computer Science House Member
--
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: [Zend Engine 2] Re: [PHP-DEV] Re: [Zend Engine 2] namespaces ambiguity
On Mon, Oct 01, 2001 at 10:12:52AM +0200, Andi Gutmans wrote: > I am OK with such an ambiguity error. What about the rest of the people? I think it will be okay. Anyone using (non-newbie) features like namespaces and ternary operations should understand the ramifications of stressing the syntax. That's not to say that PHP should become complicated, but if ternary operations are the only place this ambiguity shows its face, we can deal. > >Also, I think that namespaces should allow no spaces between namespace names > >and other namespace names or variable/class/constant names. e.g.: > > > >FOO : BAR : BARBARA > > I have also thought of this. I think I will need to scan for namespaces in > the scanner. The right way to put it is the parser but then we'd allow > spaces which I really don't want to do. > > >is illegal as a fully-qualified constant name, so the following would > >eliminate ambiguity as well: > > > >$test ? FOO : BAR:BARBARA; > > In the case of space being illegal you are right about this. I like this whole "spaces" thing. -- Jon Parise ([EMAIL PROTECTED]) . Information Technology (2001) http://www.csh.rit.edu/~jon/ : Computer Science House Member -- 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]
