Re: [PHP-DEV] Is this what Stefan Esser was referring to ...?
# [EMAIL PROTECTED] / 2007-01-23 08:59:46 -0600: > Roman Neuhauser wrote: > > php.net distributes programs that violate the PHP license: e. g. PHPUnit > > or PHPDocumentor (see http://pecl.php.net). If php.net is ok with > > ignoring the license terms (and has been for several years), does the > > license still mean sh!t? > > Um wrong, phpDocumentor *EXPLICITLY* wrote php group and asked for > permission to use php when we first switched to the php license years > ago. Get your facts straight before posting rumors. If I recall the discussions from several years ago correctly, the provisions to protect "PHP" were meant to prevent proliferation of programs written in PHP and called PHPthis of ThatPHP. So even if a special deal has allowed you to use "PHP" to endorse or promote PHPDocumentor, it is against the spirit of the license if not against the letter. I'd like to get permission to use PHP in the name of my MuchBetterDocumentor, where do I apply? ;) http://www.opensource.org/docs/definition.php#5 -- How many Vietnam vets does it take to screw in a light bulb? You don't know, man. You don't KNOW. Cause you weren't THERE. http://bash.org/?255991 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Diagnosing bug
# [EMAIL PROTECTED] / 2007-01-22 18:08:06 +: > I have been trying to track down a potential bug in my code and after > testing everything I could, I believe it is a bug in PHP. The problem is > that it's quite a complex issue and only occurs when mod_rewrite is > being used on Linux (it works fine on my Windows PC I'm developing on). For the sake of the archives: this was a PEBKAC, see [EMAIL PROTECTED] -- How many Vietnam vets does it take to screw in a light bulb? You don't know, man. You don't KNOW. Cause you weren't THERE. http://bash.org/?255991 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Is this what Stefan Esser was referring to ...?
# [EMAIL PROTECTED] / 2007-01-21 18:25:24 -0500: > Personally I think PHP related projects should avoid using "PHP" in > their name period as it causes far too many problems for the language > itself, since most people fail to distinguish between PHP the > language and project trying to gain popularity by shoving "PHP" into > its name. php.net distributes programs that violate the PHP license: e. g. PHPUnit or PHPDocumentor (see http://pecl.php.net). If php.net is ok with ignoring the license terms (and has been for several years), does the license still mean sh!t? -- How many Vietnam vets does it take to screw in a light bulb? You don't know, man. You don't KNOW. Cause you weren't THERE. http://bash.org/?255991 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 4 Bug Summary Report
# [EMAIL PROTECTED] / 2005-05-23 09:53:57 -0400: > Roman, this strikes me as a not very polite hint that you want > something to be done about it. > You can check the status by reading the bug report. > > If Hartmut wants to volunteer to do something about it, I'm sure he > will, in his own time. > > Remember your netiquette, Roman. Sorry, I absolutely didn't mean to sound impolite, but concise emails sent just before rushing out tend to screw up this way. My fault. Still, you can take the below message at the face value: two honest questions without any hidden meanings or anything like that; I'm just asking about the current state of the bug, and whether Hartmut still hacks ext/ncurses or moved on. > On 5/23/05, Roman Neuhauser <[EMAIL PROTECTED]> wrote: > > # internals@lists.php.net / 2005-05-02 09:00:18 +0200: > > > ===[ncurses > > > related]== > > > 27132 Assigned ncurses_getch() interrupted by receipt of a handled > > > signal > > > > Has this seen any attention since it's been submitted a year ago? > > > > Hartmut, do you still have any interest in ext/ncurses? -- How many Vietnam vets does it take to screw in a light bulb? You don't know, man. You don't KNOW. Cause you weren't THERE. http://bash.org/?255991 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 4 Bug Summary Report
# internals@lists.php.net / 2005-05-02 09:00:18 +0200: > ===[ncurses related]== > 27132 Assigned ncurses_getch() interrupted by receipt of a handled signal Has this seen any attention since it's been submitted a year ago? Hartmut, do you still have any interest in ext/ncurses? -- How many Vietnam vets does it take to screw in a light bulb? You don't know, man. You don't KNOW. Cause you weren't THERE. http://bash.org/?255991 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] snprintf / ap_php_snprintf, %lld, gcc versions?
# [EMAIL PROTECTED] / 2005-03-30 09:55:57 -0500: > On Tue, 29 Mar 2005, Roman Neuhauser wrote: > > > > > #define snprintf ap_php_snprintf > > > > PHPAPI int ap_php_snprintf(char *buf, size_t len, const char > > > > *format,...) > > > > > > For some reason the header file is not included then - that should be > > > fixed as our own (ap_php_snprintf) function should always be used which > > > is not gcc dependent. > > > > Turns out you are right, but probably not the way you expected: > > > > %lld is broken on the boxes where snprintf expands to > > %ap_php_snprintf(). The difference is in the installed > > include/php/main/snprintf.h file (present vs. missing > > HAVE_SNPRINTF check), at least between a pair of hosts I'm looking > > at right now. > > > > So now the question is: what is the best (least intrusive) way to > > make sure the system snprintf is used? #if 0 the snprintf macro? > > Don't do that :) To be honest, at this point I don't trust ap_php_s*printf with my data. If ap_php_snprintf is meant as a drop-in replacement for snprintf, then I don't see what would break if I did exactly that (before recompiling all of PHP + extensions). I wound up putting #undef snprintf in the extencsion's header file, and that fixed it, but to be honest, I'm shitting bricks from fear that other parts of the installation are broken as well, and will break my code in totally unexpected places, and damage the data in new ways. > > BTW, perhaps the unconditional ap_php_snprintf use could be backed > > out until the function is mature enough to actually be an > > improvement? See also > > http://marc.theaimsgroup.com/?l=php-dev&m=110746124520191&w=2 > > No, we should not back it out, but fix our ap_php_snprintf function, but > it seems you already filed a bug about this which is assigned to Marcus. Yup, I did. -- How many Vietnam vets does it take to screw in a light bulb? You don't know, man. You don't KNOW. Cause you weren't THERE. http://bash.org/?255991 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Build system support for stock FreeBSD autoconf ports
# [EMAIL PROTECTED] / 2005-03-29 16:46:37 +0200: > The way some systems start to treat autoconf (installing > multiple versions in an absolutely braindamaged way) is not > something we should support. > > I suggest whoever is bothered by FreeBSD doing stupid things > should go to the ports maintainer and complain to him. What's so stupid about it? Can you suggest a way different versions of autotools could coexist? -- How many Vietnam vets does it take to screw in a light bulb? You don't know, man. You don't KNOW. Cause you weren't THERE. http://bash.org/?255991 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Build system support for stock FreeBSD autoconf ports
# [EMAIL PROTECTED] / 2005-03-29 15:24:07 +0300: > On Tue, 29 Mar 2005, Roman Neuhauser wrote: > > ># [EMAIL PROTECTED] / 2005-03-29 11:11:27 +0300: > >>On Sun, 27 Mar 2005, Jon Parise wrote: > >> > >>>The attached patch allows PHP's build system to recognize FreeBSD's > >>>"versioned" autoconf ports without the need for system-level symlinks > >>>or similar aliasing. It uses 'shtool path' to (attempt to) locate the > >>>appropriate autoconf / autoheader executable. > >> > >>I added such patch once but Sebastian got some problems with > >>it so it was reverted. And I don't want to add this patch > >>either unless there is very good reason to do so. > > > > It would be interesting to know what the problems were so that > > they could be ironed out. > > He had the problems with gentoo and it's autoconf wrapper crap. > > >>And finally: Common users should NEVER EVER run buildconf. > > > > But why make hacking PHP harder? > > And how is it hard atm to run './buildconf' ?? > If you have autoconf (any version above 2.13 works) installed, > there are no problems. I have autoconf-2.13, 2.53, 2.59, automake-1.4.5, 1.5, 1.9.4, libtool-1.3.5, 1.5.10. I have no executable named autoconf, automake, or libtool, instead, there are autoconf213, autoconf253, etc. Without symlinking or installing the desired versions somewhere and munging PATH, running ./buildconf is an uber-easy way to be informed that I don't have the required tools. Such schemes are quite common thanks to incompatibilities between autotools versions, e. g. Subversion's buildconf equivalent accepts the names from environment, mentioning IIRC Debian installing the tools as e. g. autoconf-213. -- How many Vietnam vets does it take to screw in a light bulb? You don't know, man. You don't KNOW. Cause you weren't THERE. http://bash.org/?255991 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Build system support for stock FreeBSD autoconf ports
# [EMAIL PROTECTED] / 2005-03-29 11:11:27 +0300: > On Sun, 27 Mar 2005, Jon Parise wrote: > > >The attached patch allows PHP's build system to recognize FreeBSD's > >"versioned" autoconf ports without the need for system-level symlinks > >or similar aliasing. It uses 'shtool path' to (attempt to) locate the > >appropriate autoconf / autoheader executable. > > I added such patch once but Sebastian got some problems with > it so it was reverted. And I don't want to add this patch > either unless there is very good reason to do so. It would be interesting to know what the problems were so that they could be ironed out. > And finally: Common users should NEVER EVER run buildconf. But why make hacking PHP harder? -- How many Vietnam vets does it take to screw in a light bulb? You don't know, man. You don't KNOW. Cause you weren't THERE. http://bash.org/?255991 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] snprintf / ap_php_snprintf, %lld, gcc versions?
# [EMAIL PROTECTED] / 2005-03-27 07:49:31 +0200:
> On Sun, 27 Mar 2005, Roman Neuhauser wrote:
> > I'm having a puzzling problem with %lld conversion handling
> > in ap_php_snprintf, and it seems to be gcc version-dependent.
> >
> > I found this problem through Statgrab, which has this macro:
> >
> > #define PHP_SG_ADD_LLVAL(rtz, key, val) { \
> > char tmp[256]; \
> > int tmp_len = snprintf((char *)&tmp, sizeof(tmp) - 1, "%lld", val);
> > \
> > add_assoc_stringl_ex(rtz, key, sizeof(key), tmp, tmp_len, 1); \
> > }
> >
> > main/snprintf.[hc]:
> >
> > #define snprintf ap_php_snprintf
> > PHPAPI int ap_php_snprintf(char *buf, size_t len, const char *format,...)
>
> For some reason the header file is not included then - that should be
> fixed as our own (ap_php_snprintf) function should always be used which
> is not gcc dependent.
Turns out you are right, but probably not the way you expected:
%lld is broken on the boxes where snprintf expands to
%ap_php_snprintf(). The difference is in the installed
include/php/main/snprintf.h file (present vs. missing
HAVE_SNPRINTF check), at least between a pair of hosts I'm looking
at right now.
So now the question is: what is the best (least intrusive) way to
make sure the system snprintf is used? #if 0 the snprintf macro?
BTW, perhaps the unconditional ap_php_snprintf use could be backed
out until the function is mature enough to actually be an
improvement? See also
http://marc.theaimsgroup.com/?l=php-dev&m=110746124520191&w=2
--
How many Vietnam vets does it take to screw in a light bulb?
You don't know, man. You don't KNOW.
Cause you weren't THERE. http://bash.org/?255991
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] snprintf / ap_php_snprintf, %lld, gcc versions?
# [EMAIL PROTECTED] / 2005-03-27 07:49:31 +0200:
> On Sun, 27 Mar 2005, Roman Neuhauser wrote:
> > I'm having a puzzling problem with %lld conversion handling
> > in ap_php_snprintf, and it seems to be gcc version-dependent.
> >
> > I found this problem through Statgrab, which has this macro:
> >
> > #define PHP_SG_ADD_LLVAL(rtz, key, val) { \
> > char tmp[256]; \
> > int tmp_len = snprintf((char *)&tmp, sizeof(tmp) - 1, "%lld", val);
> > \
> > add_assoc_stringl_ex(rtz, key, sizeof(key), tmp, tmp_len, 1); \
> > }
> >
> > main/snprintf.[hc]:
> >
> > #define snprintf ap_php_snprintf
> > PHPAPI int ap_php_snprintf(char *buf, size_t len, const char *format,...)
>
> For some reason the header file is not included then
That doesn't seem to be the case. The library is built with
cc -I. -I/usr/ports/sysutils/pecl-statgrab/work/Statgrab-0.3 -DPHP_ATOM_INC
-I/usr/ports/sysutils/pecl-statgrab/work/Statgrab-0.3/include
-I/usr/ports/sysutils/pecl-statgrab/work/Statgrab-0.3/main
-I/usr/ports/sysutils/pecl-statgrab/work/Statgrab-0.3 -I/usr/local/include/php
-I/usr/local/include/php/main -I/usr/local/include/php/Zend
-I/usr/local/include/php/TSRM -I/usr/local/include -DHAVE_CONFIG_H -O -pipe
-prefer-pic -c /usr/ports/sysutils/pecl-statgrab/work/Statgrab-0.3/statgrab.c
-o statgrab.o >/dev/null 2>&1
and when I replace "-o statgrab.o >/dev/null 2>&1" with "-E" I see:
# 65 "/usr/local/include/php/main/snprintf.h"
int ap_php_snprintf(char *, size_t, const char *, ...) __attribute__
((format(printf, 3, 4)));
and the macro calls expanded to use ap_php_snprintf().
Plus, this program works on the machines where the Statgrab extension
produces "%ld":
#include
int
main (int argc, char **argv)
{
char tmp[256];
int tmp_len = snprintf((char *)&tmp, sizeof(tmp) - 1, "%lld", 127LL);
printf("strlen (%s) == %d\n", tmp, tmp_len);
return 0;
}
--
How many Vietnam vets does it take to screw in a light bulb?
You don't know, man. You don't KNOW.
Cause you weren't THERE. http://bash.org/?255991
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] snprintf / ap_php_snprintf, %lld, gcc versions?
Hello,
I'm having a puzzling problem with %lld conversion handling
in ap_php_snprintf, and it seems to be gcc version-dependent.
I found this problem through Statgrab, which has this macro:
#define PHP_SG_ADD_LLVAL(rtz, key, val) { \
char tmp[256]; \
int tmp_len = snprintf((char *)&tmp, sizeof(tmp) - 1, "%lld", val);
\
add_assoc_stringl_ex(rtz, key, sizeof(key), tmp, tmp_len, 1); \
}
main/snprintf.[hc]:
#define snprintf ap_php_snprintf
PHPAPI int ap_php_snprintf(char *buf, size_t len, const char *format,...)
The above macro works fine on some machines, and produces "%ld" on others.
I have these configurations:
working: two FreeBSD-4 boxes (cc is 2.95.4), one of these has PHP 4.3.9
installed, the other one 5.0.3
broken: FreeBSD-5 (cc is 3.4.2 [FreeBSD] 20040728), PHP 4.3.10,
RHEL3 (cc is 3.2.3 20030502 (Red Hat Linux 3.2.3-42)), PHP 4.3.10
I don't see much in common between the broken installs except the major
versions of the compilers.
Has anyone else seen this?
--
How many Vietnam vets does it take to screw in a light bulb?
You don't know, man. You don't KNOW.
Cause you weren't THERE. http://bash.org/?255991
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] system() behavior different from perl, python, ruby
Could some kind soul tell me why is php's system() function
different from the rest of the pack?
perl -e "system('man 3 printf');"
ruby -e "system('man 3 printf');"
python -c "import os; os.system('man 3 printf');"
php -r "system('man 3 printf');"
In perl, ruby, and python, the above has the same results as
typing man 3 printf, IOW the pager takes the terminal and you
can browse the man page till you quit the pager.
In php, the result is the man page streamed through, and the
pager immediately quits. I'm observing this behavior with 4.3.6
but remember seeing this behavior in 4.0.6 or something around
that time.
PHP 4.3.6 (cli) (built: May 2 2004 20:16:20)
Copyright (c) 1997-2004 The PHP Group
Zend Engine v1.3.0, Copyright (c) 1998-2004 Zend Technologies
--
FreeBSD 4.9-RELEASE-p2
7:58PM up 6:05, 3 users, load averages: 0.04, 0.04, 0.01
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [PEAR-DEV] Re: [PHP] PHP 5.0.0 Beta 1
# [EMAIL PROTECTED] / 2003-06-29 14:53:40 -0400: > On Sun, 2003-06-29 at 14:19, Sterling Hughes wrote: > > > > - Due to issues surrounding the MySQL 4.0 license, the MySQL libraries > > are no longer bundled with PHP. For more information on these > > licensing changes please see the MySQL licensing policy [1] > > > > [1] http://www.mysql.com/products/licensing.html > > I read the licensing information in the above link, but I'm curious what > exactly in it necessitated the need to unbundle MySQL? Anyone have a > quick answer? "1. Free use for those who are 100% GPL" IOW, it's not free for PHP "2. Free use for those who never copy, modify or distribute" IOW, it's not free for PHP 3. GPL would infect the whole PHP tree http://www.gnu.org/copyleft/gpl.html -- If you cc me or remove the list(s) completely I'll most likely ignore your message.see http://www.eyrie.org./~eagle/faqs/questions.html -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [PEAR-DEV] Re: [PHP-DEV] [RFC] Binary pecl packages
# [EMAIL PROTECTED] / 2003-06-18 19:39:22 -0400: > On Wed, 18 Jun 2003, Rasmus Lerdorf wrote: > > > On Thu, 19 Jun 2003, Marcus Börger wrote: > > > Why not using RPMs? Only windows is a problem, isn't it ? > > > > Windows is the primary platform we need binaries for. > > And many major Linux distributions do not support RPM... when has PHP (and/or PEAR) become Linux-only software? -- If you cc me or remove the list(s) completely I'll most likely ignore your message.see http://www.eyrie.org./~eagle/faqs/questions.html -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
