Re: [PHP-DEV] PHP and Java

[Dan Kalowsky]

On Thursday, October 24, 2002, at 09:46 PM, Marc Richards wrote:

5) Who is responsible for development of this extension?


Sam Ruby wrote it originally, but alas he seems to have disappeared 
from maintaining it.  A few people have done matiaince on it, you can 
see the bonzai tree, or cvs logs for this.

>---<
Dan Kalowsky"I've learned to fake it,
http://www.deadmime.org/~dankand just smile along."
[EMAIL PROTECTED]- "Candy",
[EMAIL PROTECTED]  Iggy Pop


--
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 / Makefile.global

[Yasuo Ohgaki]

Sander Roobol wrote:

On Thu, Oct 24, 2002 at 11:59:19AM -0400, Jon Parise wrote:


   - Change the compiled default value for output_buffering to 0.
   - Allow output_buffering to be set by ini_set().
   - Specify 'output_buffering = 0' via the -D command line option
 for run-tests.php.
   - Pass a php.ini configuration file to run-tests.php using -C.



Can't we just flush all the open output buffers? Something like this:
	while(ob_get_level()) ob_end_clean();


Of course, I know that.
But my points are

 - run-tests.php itself is not test script, but phpt is.
 - with specific ini, we can get rid of code aren't needed
 - we don't have to care about careless patches, and say
   'Hey your patch does not work with my php.ini".
 - things are easier with certain ini.
 - etc, etc.

So far, I didn't see any good point using various php.ini
settings for run-tsets.php. Person, who get rid of the setting
and insist specifying php.ini is not worth, even cannot
find and fix problem with php.ini-recommended.

Better choice is obvious, isn't?

--
Yasuo Ohgaki



--
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] PHP and Java

[Brad LaFountain]

--- Marc Richards <[EMAIL PROTECTED]> wrote:
> Hi,
> 
> I am looking for any info or documentation on using PHP in a servlet
> environment.  I read what I could find on php.net, and found a couple things
> using google, but not enough to answer my questions.  If someone could tell
> me where to look that would be great.  I am very interested in seing PHP
> more tightly integrated with J2EE as I think that it would add the
> reliabilty and scalability of the J2EE platform to the ease of use of PHP,
> and allow a smooth transition for the existing PHP user base, who need to do
> things with Java.
> 
> These are the type of questions I have right now:
> 
> 1) Is this a pure Java version of PHP?
 No. And why would there be ;)

> 2) What functionality is available? (only core functions?  Some extention
> libraries)
 There are 2 things you can do with ext/java
 1) create instances of java objects thru the php's java class, You should have
access of all the methods available for that object
ex.
$java = new Java("java.util.Hashtable");
$java->put("Key", "Value");
echo $java->toString();

 2) php will run as a servlet engine, meaning you can run php scripts inside
Tomcat. This is done all thru native methods.

> 3) How does it all work? (pass thru mechanism? are pages compiled as
> classes?)

 Pages are not compiled as classes they still exists as php scripts.

> 4) Does this make it eiasier to access Java servlets or EJBs? Does it
> increse performance?

 Well not sure exactly what you mean by accessing java servlets, You can
"access" a java servlet by simply
file("http://someserver.com/servlet/SomeJava.jsp?param=go";); That would make
the servelet execute but I might not know what you mean by access. I guess if
you wanted to you could use the Java() class to create an instance of a servlet
class and invoke its methods directly.

Accessing a EJB from a php script should be fine, (this is purely theory never
tried it or even fully thought it thru). If you take the steps that you would
to create a refrence of an EJB from java and replicate it using ext/java it
should work.
Here is a quick example from OpenEJB HelloWorld example

http://openejb.sourceforge.net/hello-world.html
put("java.naming.factory.initial", "org.openejb.client.JNDIContext");
$p->put("java.naming.provide.url", "127.0.0.1:4201");
$p->put("java.naming.security.principal", "myuser");
$p->put("java.naming.security.credentials", "mypass");


//Now use those properties to create
//a JNDI InitialContext with the server.
$ctx = new Java("javax.naming.InitialContext", $p );

//Lookup the bean using it's deployment id
$obj = $ctx->lookup("/Hello");

//Be good and use RMI remote object narrowing
//as required by the EJB specification.

//** This may not work with ext/java extension ***
$pro = new Java("javax.rmi.PortableRemoteObject");
$helloHome = new Java("HelloHome");
$ejbHome = $pro->narrow( $obj, $helloHome->class);
//** This may not work with ext/java extension ***

//Use the HelloHome to create a HelloObject
$ejbObject = $ejbHome->create();

//The part we've all been wainting for...
$message = $ejbObject->sayHello();

//A drum roll please.
echo $message;
?>

 So except for the static access to "class" from helloHome It should work.
Maybe if I get borred some time i'll try it.

> 5) Who is responsible for development of this extension?

 Sam Ruby was the orig developer. I've played with it. I don't think anyone has
done any new development in awhile.

> 6) When do you expect a non experimental version will be available

 When more intrest becomes of it and someone wants to claim any new
development.


 - Brad


__
Do you Yahoo!?
Y! Web Hosting - Let the expert host your web site
http://webhosting.yahoo.com/

-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] PHP and Java

[Marc Richards]

Hi,

I am looking for any info or documentation on using PHP in a servlet
environment.  I read what I could find on php.net, and found a couple things
using google, but not enough to answer my questions.  If someone could tell
me where to look that would be great.  I am very interested in seing PHP
more tightly integrated with J2EE as I think that it would add the
reliabilty and scalability of the J2EE platform to the ease of use of PHP,
and allow a smooth transition for the existing PHP user base, who need to do
things with Java.

These are the type of questions I have right now:

1) Is this a pure Java version of PHP?
2) What functionality is available? (only core functions?  Some extention
libraries)
3) How does it all work? (pass thru mechanism? are pages compiled as
classes?)
4) Does this make it eiasier to access Java servlets or EJBs? Does it
increse performance?
5) Who is responsible for development of this extension?
6) When do you expect a non experimental version will be available

Any help would be appreciated.

Marc



-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] linking php code to html link

[Jason T. Greene]

Alan,

PHP-DEV(Internals) is the list for the development OF the PHP Language
not WITH the PHP language. The PHP-GENERAL list is what you want.

Before emailing this particular question, I would highly suggest you
read the documentation available on PHP's website (http://www.php.net),
and possibly buy a book.

-Jason

--
Jason T. Greene  <[EMAIL PROTECTED]>
 <[EMAIL PROTECTED]>

On Thu, 2002-10-24 at 17:10, Alan Rawkins wrote:
> Hi there,
> 
> I'm wondering if there is a way to attach a php function to an html 
> tag. I basically want to have a button, that when clicked, will execute some
> PHP code.
> 
> Thanks,
> Alan
> 
> 
> 
> -- 
> PHP Development Mailing List 
> To unsubscribe, visit: http://www.php.net/unsub.php
> 



-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] cannot read /repository/php4/ext/overload/CVS/fileattr

[Sebastian Bergmann]

  During a fresh CVS checkout I got the following message

cvs server: cannot read /repository/php4/ext/overload/CVS/fileattr:
Operation not supported

  What does this mean?

-- 
  Sebastian Bergmann
  http://sebastian-bergmann.de/ http://phpOpenTracker.de/

  Did I help you? Consider a gift: http://wishlist.sebastian-bergmann.de/

-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] linking php code to html link

[Alan Rawkins]

Hi there,

I'm wondering if there is a way to attach a php function to an html 
tag. I basically want to have a button, that when clicked, will execute some
PHP code.

Thanks,
Alan



-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Can't build HEAD on Linux

[Sebastian Bergmann]

Markus Fischer wrote:
> Upgraded your GCC? Googles first hit reads something like:
>
> "FORM 14 is DW_FORM_strp, recently added to GCC.  You need a
> newer binutils."

  Interesting.

  I updated to gcc 3.2 a while ago and it worked fine. This morning, for
  instance, I was able to build HEAD without problems. Just now I was
  able to build httpd-2.0 HEAD without problems.

-- 
  Sebastian Bergmann
  http://sebastian-bergmann.de/ http://phpOpenTracker.de/

  Did I help you? Consider a gift: http://wishlist.sebastian-bergmann.de/

-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Can't build HEAD on Linux

[Markus Fischer]

Upgraded your GCC? Googles first hit reads something like:

"FORM 14 is DW_FORM_strp, recently added to GCC.  You need a
newer binutils."

On Thu, Oct 24, 2002 at 11:18:15PM +0200, Sebastian Bergmann wrote : 
>   /usr/bin/ld: Dwarf Error: Invalid or unhandled FORM value: 14.
>   /usr/bin/ld: Dwarf Error: Invalid or unhandled FORM value: 14.
>   ext/mysql/libmysql/my_tempnam.lo: In function `my_tempnam':
>   /usr/src/php4/ext/mysql/libmysql/my_tempnam.c:103:
>   the use of `tempnam' is dangerous, better use `mkstemp'
> 
> -- 
>   Sebastian Bergmann
>   http://sebastian-bergmann.de/ http://phpOpenTracker.de/
> 
>   Did I help you? Consider a gift: http://wishlist.sebastian-bergmann.de/
> 
> -- 
> PHP Development Mailing List 
> To unsubscribe, visit: http://www.php.net/unsub.php

-- 
GnuPG Key: http://guru.josefine.at/~mfischer/C2272BD0.asc
$ grep docref_root php.ini
docref_root = 
"http://landonize.it/?how=url&theme=classic&filter=RichyH&user=imajes&url=http%3A%2F%2Fphp.net%2F/";

-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Can't build HEAD on Linux

[Sebastian Bergmann]

  /usr/bin/ld: Dwarf Error: Invalid or unhandled FORM value: 14.
  /usr/bin/ld: Dwarf Error: Invalid or unhandled FORM value: 14.
  ext/mysql/libmysql/my_tempnam.lo: In function `my_tempnam':
  /usr/src/php4/ext/mysql/libmysql/my_tempnam.c:103:
  the use of `tempnam' is dangerous, better use `mkstemp'

-- 
  Sebastian Bergmann
  http://sebastian-bergmann.de/ http://phpOpenTracker.de/

  Did I help you? Consider a gift: http://wishlist.sebastian-bergmann.de/

-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: Unsigned Problems Revisited

[David M. Lloyd]

On Thu, 24 Oct 2002, Andi Gutmans wrote:

> At 02:49 PM 10/23/2002 -0500, David M. Lloyd wrote:
>
> >The reality of twos-complement, bitwise arithmatic is that there are
> >three basic shift operations:  shift left, bitwise shift right, and
> >arithmetic shift right.  This simple fact is one of the basic ideas of
> >dealing with twos-complement integers.
>
> I know that but I still wanted the opposite to be available to keep
> things symmetrical. I'm not sure but I think CPU's do support both
> logical and arithmetic shifts and just do the same with both (I might be
> wrong though).

Generally no, it's a waste of opcode space for modern CISC processors.
RISC processors often have integrated barrel-shifters, so they don't need
shift instructions at all.

Intel carries over "arithmetic" shift right instructions from older
architetures for backwards-compatibility with x86, but their RISC
implementation (Itanium) does not contain support for the operation.

One RISC example is ARM.  They give you four shift options: Logical left,
logical right, arithmetic right, and rotate right.  Making the operation
symmetrical is a waste of precious bit combinations, and would have meant
either losing another shift operation or else adding another bit to the
shift operation specifier, which means that another bit would have to be
sacrificed elsewhere.

Another example is SPARC, which implements shifting with discrete
instructions, only implents one left shift operator.  PowerPC does not
implement it either.

> >Given this fact, there is no reason to have a bogus fourth operator in the
> >name of symmetry.  Mathematical operaters are simply not always
> >symmetrical.  There is no such thing as 'arithmetic shift left' or
> >'logical shift left' in terms of twos-complement integers, so why invent
> >it?
>
> I agree that they don't *have* to be symmetrical but I think it's
> better.

Better why?  Anyone who understands twos-complement will understand (and
expect) the ability to do those three operations, and will not be
surprised by the lack of two left shifts.  I argue that they *should NOT*
be symmetrical because it is wrong.

> >Second of all, my understanding of the here-doc operator is that it acts
> >as a unary operation.  I don't see the conflict with the binary
> >application of <<<, given the example of unary and binary -, if it is
> >absolutely neccessary to fulfill the (somewhat psychotic) need for
> >symmetry where it is not realy needed, or even strictly correct.
>
> psychotic? Can we please have discussions on a professional and not
> personal level?

It is true though, unless you can give me a sound mathematical reason that
the ops should exist... and saying "it looks right" or "it is easier" is
not a valid reason, becuase to those with even basic twos-complement math
background, it looks wrong and is not easier.

> As far as I remember it does clash with here-docs. I'm pretty sure I
> thought of an example a while back. I can try and think of one again. In
> any case, I wouldn't want an overloaded operator. We try and keep away
> of that kind of stuff with PHP.

Very well... then let's not put in the nonsense operator, and just have
three shift operations: <<, >>, and >>>.

- D

<[EMAIL PROTECTED]>


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] from one hash to another, in an extension

[Tim Daly, Jr.]

Andrei Zmievski <[EMAIL PROTECTED]> writes:

> On Wed, 23 Oct 2002, Tim Daly, Jr. wrote:
> > > You don't need to SEPARATE_ZVAL() in this case.
> > 
> > I don't need to, or I need not to?
> 
> Don't use SEPARATE_ZVAL() when copying zval from one hash to another.
> 
> -Andrei   http://www.gravitonic.com/

Thanks.

-Tim



-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4(PHP_4_2_0) /ext/bcmath/libbcmath/src config.h

[Markus Fischer]

On Thu, Oct 24, 2002 at 07:06:43AM -0600, Ananth Kesari wrote : 
> We have checked-in most of the files already for the 4.3 branch
> as well. We will be completing that also soon.

Congratulations on the work!

-- 
GnuPG Key: http://guru.josefine.at/~mfischer/C2272BD0.asc
$ grep docref_root php.ini
docref_root = 
"http://landonize.it/?how=url&theme=classic&filter=RichyH&user=imajes&url=http%3A%2F%2Fphp.net%2F/";

-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [PATCH] Changing entity charset handlinginext/standard/html.c

[Edin Kadribasic]

> BTW, the temporary solution is to give a priority to each setting,
like
>
> 1. MBSTRG(internal_encoding)
> 2. SG(default_charset)
> 3. System's locale setting
>
> How about this option?

This sounds fine. This way people who compile php without mbstring
support can alter the default charset.

Edin


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] -=

[Maxim Maletsky]

current value minus this.

int a = 10;
int b = 6;


a -= b;

now a is 4;

But, this is not PHP-DEV question.


--
Maxim Maletsky
[EMAIL PROTECTED]


www.PHPBeginner.com  // PHP for Beginners
www.maxim.cx // my Home

// my Wish List: ( Get me something! )
http://www.amazon.com/exec/obidos/registry/2IXE7SMI5EDI3



"Diana Castillo" <[EMAIL PROTECTED]> wrote... :

> What does it mean in the code when it says - =
> for instance
> a[k][j] -= a[k][i] * a[i][j] / a[i][i];
> thanks,
> Diana
> 
> 
> 
> -- 
> PHP Development Mailing List 
> To unsubscribe, visit: http://www.php.net/unsub.php
> 


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] -=

[Derick Rethans]

Can you please direct questions like this to the 
[EMAIL PROTECTED] mailing list, this list is for development 
_of_ PHP, not for developing _with_ PHP.

Thank you,

Derick



On Thu, 24 Oct 2002, Diana Castillo wrote:

> What does it mean in the code when it says - =
> for instance
> a[k][j] -= a[k][i] * a[i][j] / a[i][i];
> thanks,
> Diana
> 
> 
> 
> -- 
> PHP Development Mailing List 
> To unsubscribe, visit: http://www.php.net/unsub.php
> 

--

---
 Derick Rethans   http://derickrethans.nl/ 
 JDI Media Solutions
--[ if you hold a unix shell to your ear, do you hear the c? ]-


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] -=

[Diana Castillo]

What does it mean in the code when it says - =
for instance
a[k][j] -= a[k][i] * a[i][j] / a[i][i];
thanks,
Diana



-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [PATCH] Changing entity charset handlinginext/standard/html.c

[Moriyoshi Koizumi]

Hello Edin,

I don't know if your proposal is logical or not, I figured the problem 
in the historical context, that it shouldn't rely on mbstring ext too much 
because it's been there since mbstring(formerly called as jstring) was 
introduced.

But, It's a problem that the internal encoding is not necessarily the same 
as the output encoding when mb_output_handler is enabled. So in this sense, 
giving more priority to mbstring.internal_encoding is quite natural to me.

In addition there's a hack in mbstring.c that overrides the Content-Type 
header whatever the SAPI setting is, when output handler is enabled by the 
ini setting.

I think the real issue is we have two similar options that seem to 
stay different as long as the ZE's parser doens't support various charsets, 
at least those which can be handled by the current version of mbstring.

You may want to point me out that we already have --enable-zend-multibyte,
but it's virtually a hack IMO, and it should be integrated to the core at 
lower level in the future version.

BTW, the temporary solution is to give a priority to each setting, like

1. MBSTRG(internal_encoding)
2. SG(default_charset)
3. System's locale setting

How about this option?


Moriyoshi

"Edin Kadribasic" <[EMAIL PROTECTED]> wrote:

> Hey Moriyoshi,
> 
> Sorry for my late entry into the debate, but I run into
> htmlentities() default charset problem today. I wonder why did you
> opt to use mbstring ini setting (thus making this nice feature
> mbstring dependant) when we have "default_charset" ini setting.
> 
> It just sounds more logical to me to use SG(default_charset) for the
> default charset of htmlentities(). Your thoughts?
> 
> Edin
> 
> - Original Message -
> From: "Moriyoshi Koizumi" <[EMAIL PROTECTED]>
> To: "Wez Furlong" <[EMAIL PROTECTED]>
> Cc: <[EMAIL PROTECTED]>
> Sent: Thursday, October 17, 2002 7:48 AM
> Subject: Re: [PHP-DEV] [PATCH] Changing entity charset
> handlinginext/standard/html.c
> 
> 
> > Yep, as far as I read the archives, I haven't found any
> discussions on the
> > charset related backwards problems. So I wrote "*exactly* about
> this
> > issue".
> >
> > You may want to redirect me to bug #9392
> (http://bugs.php.net/bug.php?id=9392), but it doens't seem to
> help...
> >
> > In addition, I found determining the internal charset by LC_CTYPE
> is
> > dangerous because setlocale() is not thread-safe in some libc
> > implementations (glibc seems to be that one).
> >
> > I'm going to read archives more carefully, though I think even
> handling
> > the charset in phpinfo() will yield the same discussion in the
> future.
> >
> >
> > Moriyoshi Koizumi
> >
> > "Wez Furlong" <[EMAIL PROTECTED]> wrote:
> >
> > > Search the archives for the discussion.
> > > phpinfo could determine the charset as your patch does at the
> start,
> > > and then pass the info in php_escape_html_entities.
> > >
> > > Seems easy to me.
> > >
> > > --Wez.
> > >
> > > On 10/16/02, "Moriyoshi Koizumi" <[EMAIL PROTECTED]>
> wrote:
> > > > Wez Furlong <[EMAIL PROTECTED]> wrote:
> > > > > Unfortunately, we absolutely must remain 100% backwards
> compatible with
> > > > > htmlentities(), so this patch should not be applied.
> > > >
> > > > Were there any discussions exactly about this issue? Though I
> have to see
> > > > some historical reason, however I don't understand why 100%
> backwards
> > > > compatibility is required for htmlentities().
> > > > Because the patched htmlentities() acts in the same way with
> default
> > > > configuration, and IMHO defaulting to iso-8859-1 is quite
> meaningless for
> > > > the scripts that uses other charsets than it.
> > > >
> > > > Hmm... otherwise I would like to suggest a mbstring function
> like
> > > > mb_htmlentities(), but it would sound like a reinvention of
> the same
> > > > wheel...
> > > >
> > > > > However, I don't see a problem with making phpinfo determine
> the charset
> > > > > and passing that on to the internal htmlentities function?
> > > >
> > > > The problem is that php_info_html_esc() in ext/standard/info.c
> calls
> > > > php_escape_html_entities() with no charset information
> specified. Without
> > > > the patch, every character is treated as ISO-8859-1 even if a
> fetched
> > > > character is actually a mere first byte of a multibyte
> character.
> > > >
> > > >
> > > > Moriyoshi Koizumi
> > > >
> > > >
> > > >
> > > > --
> > > > PHP Development Mailing List 
> > > > To unsubscribe, visit: http://www.php.net/unsub.php
> > >
> > >
> > >
> >
> >
> > --
> > PHP Development Mailing List 
> > To unsubscribe, visit: http://www.php.net/unsub.php
> >
> >
> >
> 
> 
> -- 
> PHP Development Mailing List 
> To unsubscribe, visit: http://www.php.net/unsub.php
> 


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Re: [PHP-CVS] cvs: php4(PHP_4_2_0)/ext/bcmath/libbcmath/src config.h

[Ananth Kesari]

Hi,

NetWare has a very old PHP, version 4.0.8! We are moving to a later stabler version 
for release on NetWare next month. In that connection Zeev Suraski suggested that we 
move to 4.2 branch which is significantly more stabler than 4.3 branch. So, I am 
checking in files for the 4.2 branch so that our sources are in synch there for any 
possible future releases from that branch. I mentioned this to this group earlier and 
the mail is attached.

We have checked-in most of the files already for the 4.3 branch as well. We will be 
completing that also soon.

Thanks,
Ananth.

>>> Sebastian Bergmann <[EMAIL PROTECTED]> 10/24/02 05:22AM >>>
Anantha Kesari H Y wrote:
> hyanantha   Thu Oct 24 05:15:12 2002 EDT
>
>   Modified files:  (Branch: PHP_4_2_0)
> /php4/ext/bcmath/libbcmath/src  config.h
>   Log:
>   NetWare related changes/modifications.

  Why are all these patches committed to the (dead?) PHP_4_2_0 branch?

-- 
  Sebastian Bergmann
  http://sebastian-bergmann.de/ http://phpOpenTracker.de/ 

  Did I help you? Consider a gift: http://wishlist.sebastian-bergmann.de/ 

-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php 


--- Begin Message ---
Hi all,

I am working on porting PHP onto NetWare.
Currently, we are shipping the older version 4.0.8
on NetWare. We are moving to the latest stable version.
Zeev Suraski suggested that we move to 4.2 branch
since it is significantly more stable than 4.3 branch.

So, I would be checking in NetWare patches into the
4.2 source code branch in a few days from now.
This is for your information.

Thanks,
Ananth.



--
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php



--- End Message ---
-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] ZE2 compile failure with xml-rpc ext

[Jan Schneider]

/bin/sh libtool --silent --mode=compile gcc
-I/home/jan/software/php4/ext/xmlrpc/libxmlrpc -DVERSION=0.50 -Iext/xmlrpc/
-I/home/jan/software/php4/ext/xmlrpc/ -DPHP_ATOM_INC
-I/home/jan/software/php4/include -I/home/jan/software/php4/main
-I/home/jan/software/php4 -I/home/jan/software/php4/Zend
-I/usr/include/libxml2 -I/usr/include/freetype2 -I/usr/include/imap
-I/usr/include/mcal -I/home/jan/software/php4/ext/xml/expat  -DEAPI_MM
-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -DHARD_SERVER_LIMIT=2048
-DDYNAMIC_MODULE_LIMIT=128 -DLINUX=22 -DMOD_SSL=208107 -DEAPI
-I/home/jan/software/php4/TSRM  -g -O2  -prefer-pic -c
/home/jan/software/php4/ext/xmlrpc/xmlrpc-epi-php.c -o
ext/xmlrpc/xmlrpc-epi-php.lo 
/home/jan/software/php4/ext/xmlrpc/xmlrpc-epi-php.c: In function
`set_zval_xmlrpc_type':
/home/jan/software/php4/ext/xmlrpc/xmlrpc-epi-php.c:1348: structure has no
member named `properties'
/home/jan/software/php4/ext/xmlrpc/xmlrpc-epi-php.c:1349: structure has no
member named `properties'
make: *** [ext/xmlrpc/xmlrpc-epi-php.lo] Fehler 1

Jan.

--
http://www.horde.org - The Horde Project
http://www.ammma.de - discover your knowledge
http://www.tip4all.de - Deine private Tippgemeinschaft

-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] I hope this is the last email about this :)

[Zeev Suraski]

At 12:23 24/10/2002, Yasuo Ohgaki wrote:

function prompt($prefix) {
 echo $prefix;
 flush();
}

is _TRIVIAL_ to write. People should have this kind of
function instead of enabling inefficient implicit flushing
since it's more efficient and reliable.


You print something, it doesn't print out.  How is it trivial to solve 
this?  If you happen to know that there's IO buffering and that there's a 
function called flush() then maybe it trivial, but then there are the other 
million users who don't.  Hence the idea of setting is to implicit flush 
for the masses, who not only don't know about the existence of flush(), but 
also don't know why it's even necessary.

Zeev


--
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] I hope this is the last email about this :) (was RFC:

[Ford, Mike [LSS]]

> -Original Message-
> From: Yasuo Ohgaki [mailto:yohgaki@;ohgaki.net]
> Sent: 24 October 2002 07:42
> To: [EMAIL PROTECTED]; Alan Knowles
> 
> Alan Knowles wrote:
> > Im +1 for reverting the patch - (for what it's worth)
> > 
> 
> This makes 2+ for having auto flushing :)

Add one more -- or even more, as I 'd say I'm +>1 for this!

> BTW, real language (i.e. not shell) don't flush. Please let me
> know if there is real language that do automatic flushing by
> default.

But PHP-CLI *is* a shell-scripting language, and therefore should behave
like one.  Other flavours of PHP aren't, and shouldn't.  QED.

> In addition, is it too difficult to write this kind of code?
> 
> function prompt($prefix) {
>   echo $prefix;
>   flush();
> }
> 
> I think this kind of code will be taught at the first
> class of programming course. (I could be wrong,
> since I don't know where people learned programming ;)

At university: learned half-a-dozen languages; *all* of them flushed streams
open on TTY either after every character, or (at line-end or when input
requested from same device).  I've been programming now for over 25 years,
and this is *still* the behaviour I expect by default when programming
command-line-executable scripts or programs.

> Let's guess something interesting.
> 
> How much % of scripts actually needs automatic flushing?
> My guess is less than 1%. What is yours?

For PHP-CLI: more than 90%.
For PHP CGI or SAPI: much less than 1%.

-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] I hope this is the last email about this :) (was

[Ford, Mike [LSS]]

> -Original Message-
> From: Yasuo Ohgaki [mailto:yohgaki@;ohgaki.net]
> Sent: 24 October 2002 09:01
> To: [EMAIL PROTECTED]; Melvyn Sopacua
> 
> Are you going to insist most scripts need inefficient auto flushing?

For CLI, yes.

> Have you ever used other programming languages?

Yes -- over 40 at last count!  (Even written the odd compiler in my time!)

> 
> I don't get it, but this is the 3rd vote.
> Too few still and reasoning is too weak.
> 
> BTW, if anyone would like to vote for inefficient/mostly useless
> auto flushing. Please add your vote to this article.
> 
> http://news.php.net/article.php?group=php.dev&article=89995

I would, but I can't see any way of replying/voting on the page that URL takes me 
to...!

Cheers!

Mike

-
Mike Ford,  Electronic Information Services Adviser,
Learning Support Services, Learning & Information Services,
JG125, James Graham Building, Leeds Metropolitan University,
Beckett Park, LEEDS,  LS6 3QS,  United Kingdom
Email: [EMAIL PROTECTED]
Tel: +44 113 283 2600 extn 4730  Fax:  +44 113 283 3211 

-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] algebra code

[Wez Furlong]

Get a math text book that explains gaussian elimination, learn it, then
ask your question on php-general.

This list is for development of php itself, not writing programs with PHP.

--Wez.

On 10/24/02, "Diana Castillo" <[EMAIL PROTECTED]> wrote:
> does anyone know where I can get the code to solve equations with three
> unknowns?
> eg.
> 2x+4y+3z=234
> 3x+2y+44z=70
> 8x+33y+9z= 8
> I need the code to solve for x , y and z
> Thanks
> 
> 
> --
> Ve mis pinturas - See my paintings::
> http://www.nvtechnologies.com/hgh/paintingweb
> 
> 
> 
> -- 
> PHP Development Mailing List 
> To unsubscribe, visit: http://www.php.net/unsub.php




-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] algebra code

[Diana Castillo]

does anyone know where I can get the code to solve equations with three
unknowns?
eg.
2x+4y+3z=234
3x+2y+44z=70
8x+33y+9z= 8
I need the code to solve for x , y and z
Thanks


--
Ve mis pinturas - See my paintings::
http://www.nvtechnologies.com/hgh/paintingweb



-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [PATCH] Changing entity charset handlinginext/standard/html.c

[Edin Kadribasic]

Hey Moriyoshi,

Sorry for my late entry into the debate, but I run into
htmlentities() default charset problem today. I wonder why did you
opt to use mbstring ini setting (thus making this nice feature
mbstring dependant) when we have "default_charset" ini setting.

It just sounds more logical to me to use SG(default_charset) for the
default charset of htmlentities(). Your thoughts?

Edin

- Original Message -
From: "Moriyoshi Koizumi" <[EMAIL PROTECTED]>
To: "Wez Furlong" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Thursday, October 17, 2002 7:48 AM
Subject: Re: [PHP-DEV] [PATCH] Changing entity charset
handlinginext/standard/html.c


> Yep, as far as I read the archives, I haven't found any
discussions on the
> charset related backwards problems. So I wrote "*exactly* about
this
> issue".
>
> You may want to redirect me to bug #9392
(http://bugs.php.net/bug.php?id=9392), but it doens't seem to
help...
>
> In addition, I found determining the internal charset by LC_CTYPE
is
> dangerous because setlocale() is not thread-safe in some libc
> implementations (glibc seems to be that one).
>
> I'm going to read archives more carefully, though I think even
handling
> the charset in phpinfo() will yield the same discussion in the
future.
>
>
> Moriyoshi Koizumi
>
> "Wez Furlong" <[EMAIL PROTECTED]> wrote:
>
> > Search the archives for the discussion.
> > phpinfo could determine the charset as your patch does at the
start,
> > and then pass the info in php_escape_html_entities.
> >
> > Seems easy to me.
> >
> > --Wez.
> >
> > On 10/16/02, "Moriyoshi Koizumi" <[EMAIL PROTECTED]>
wrote:
> > > Wez Furlong <[EMAIL PROTECTED]> wrote:
> > > > Unfortunately, we absolutely must remain 100% backwards
compatible with
> > > > htmlentities(), so this patch should not be applied.
> > >
> > > Were there any discussions exactly about this issue? Though I
have to see
> > > some historical reason, however I don't understand why 100%
backwards
> > > compatibility is required for htmlentities().
> > > Because the patched htmlentities() acts in the same way with
default
> > > configuration, and IMHO defaulting to iso-8859-1 is quite
meaningless for
> > > the scripts that uses other charsets than it.
> > >
> > > Hmm... otherwise I would like to suggest a mbstring function
like
> > > mb_htmlentities(), but it would sound like a reinvention of
the same
> > > wheel...
> > >
> > > > However, I don't see a problem with making phpinfo determine
the charset
> > > > and passing that on to the internal htmlentities function?
> > >
> > > The problem is that php_info_html_esc() in ext/standard/info.c
calls
> > > php_escape_html_entities() with no charset information
specified. Without
> > > the patch, every character is treated as ISO-8859-1 even if a
fetched
> > > character is actually a mere first byte of a multibyte
character.
> > >
> > >
> > > Moriyoshi Koizumi
> > >
> > >
> > >
> > > --
> > > PHP Development Mailing List 
> > > To unsubscribe, visit: http://www.php.net/unsub.php
> >
> >
> >
>
>
> --
> PHP Development Mailing List 
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
>


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Re: [PHP-CVS] cvs: php4(PHP_4_2_0) /ext/bcmath/libbcmath/src config.h

[Sebastian Bergmann]

Anantha Kesari H Y wrote:
> hyanantha   Thu Oct 24 05:15:12 2002 EDT
>
>   Modified files:  (Branch: PHP_4_2_0)
> /php4/ext/bcmath/libbcmath/src  config.h
>   Log:
>   NetWare related changes/modifications.

  Why are all these patches committed to the (dead?) PHP_4_2_0 branch?

-- 
  Sebastian Bergmann
  http://sebastian-bergmann.de/ http://phpOpenTracker.de/

  Did I help you? Consider a gift: http://wishlist.sebastian-bergmann.de/

-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Upload broken?

[Steve Alberty]

Hi,

is in the cvs tree the file upload currently broken?

I miss the $_FILES['myfile'] variables.

Regards,

Steve

-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] running tests with CGI binary

[Derick Rethans]

On Thu, 24 Oct 2002, Hartmut Holzgraefe wrote:

> comments? ;)

sure :)

> 
> -8<-
> Index: run-tests.php
> ===
> RCS file: /repository/php4/run-tests.php,v
> retrieving revision 1.83
> diff -u -2 -r1.83 run-tests.php
> --- run-tests.php   23 Oct 2002 12:54:57 -  1.83
> +++ run-tests.php   24 Oct 2002 09:26:06 -
> @@ -83,4 +83,6 @@
>   }
> 
> +$php = realpath($php);
> +
>   // Check whether a detailed log is wanted.
>   if (getenv('TEST_PHP_DETAILED')) {
> @@ -425,4 +427,5 @@
> 
>  // Reset environment from any previous test.
> +   putenv("USER_AGENT=run-tests.php");
>  putenv("REDIRECT_STATUS=");
>  putenv("QUERY_STRING=");
> @@ -437,7 +440,8 @@
>  if (trim($section_text['SKIPIF'])) {
>  save_text($tmp_skipif, $section_text['SKIPIF']);
> -   $output = `$php $tmp_skipif`;
> +   putenv("PATH_TRANSLATED=$tmp_skipif");
> +   $output = `$php -q $tmp_skipif`;
>  @unlink($tmp_skipif);
> -   if (ereg("^skip", trim($output))){
> +   if (ereg("^skip", $output)){

This trim was added for a reason, did you check if that broke any tests?

>  echo "SKIP $tested";
>  $reason = (ereg("^skip[[:space:]]*(.+)\$", trim(
> $output))) ? ereg_replace("^skip[[:space:]]*(.+)\$", "\\1", trim($output)) : FAL
> SE;
> @@ -478,5 +482,5 @@
> 
>  // We've satisfied the preconditions - run the test!
> -   save_text($tmp_file,$section_text['FILE']);
> +   save_text($tmp_file,"" . 
>$section_text['FILE']);

This change is going to break some tests, but you just volunteerd to fix 
those:

13:07  oh, yes ... pathes in the phpt files get easier again ... ;)
13:07 <@Derick> you can only do this if you fix all the tests too :)
13:07  this was intentional, i only forgot it ;)
13:07  yes, but that makes standalone tests for phpized extensions possible
13:07 <@Derick> I think it's better to cwd() to the php4/ dir then, where 
run-tests.php is
13:08  so i volunteer

furthermore I propose to apply this patch after pre2, so that we have 
more time to adjust the affected scripts where needed.

regards,
Derick


--

---
 Derick Rethans   http://derickrethans.nl/ 
 JDI Media Solutions
--[ if you hold a unix shell to your ear, do you hear the c? ]-


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] I hope this is the last email about this :)

[Yasuo Ohgaki]

Just wanted to add little more emphasis for the reason why I
(Bsay "weak reasoning".
(B
(BMy thoughts exactly. Defaults should work for the masses - it's not
(Blike it's enforced behavior, that is irreversible.
(B
(B> Anyway, what kind of default we have for implicit flush in
(B> php.ini-dest/recommended now and in the future? We have _OFF_
(B> by default. It also help us to make better decision, IMO.
(B> 
(B> Default OFF is more intuitive, IMHO.
(B
(BI'm talking virtually all current users who are used to
(Bimplicit_flush=Off by default.
(B
(BThis should be called the *MASSES*.
(B
(B--
(BYasuo Ohgaki
(B
(B
(B-- 
(BPHP Development Mailing List 
(BTo unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] I hope this is the last email about this :)

[Yasuo Ohgaki]

Zeev Suraski wrote:
(B> At 10:01 24/10/2002, Yasuo Ohgaki wrote:
(B>
(B>> Melvyn Sopacua wrote:
(B>>
(B>>> At 02:51 24-10-2002, Alan Knowles wrote:
(B>>>
(B Im +1 for reverting the patch - (for what it's worth)
(B
(B Why?
(B Well - most 'average' (and below) PHP programmers when attempting to
(B do CLI programming, will get a serious WTF reaction from wondering
(B why when they 'echo' stuff, it doesnt appear. The more advanced
(B Users can manually turn off flushing, but for most small, quick
(B scripts (eg. 50%+), this instant flush is going to be perfectly
(B acceptable..
(B>>>
(B>>>
(B>>> My thoughts exactly. Defaults should work for the masses - it's not
(B>>> like it's enforced behavior, that is irreversible.
(B>>
(B>>
(B>> ? Which mass ?
(B>> Are you going to insist most scripts need inefficient auto flushing?
(B>> Have you ever used other programming languages?
(B>>
(B>> I don't get it, but this is the 3rd vote.
(B>> Too few still and reasoning is too weak.
(B>
(B>
(B> Too few?  It's 3 times more than the votes in favour, and now it's 4
(B> times more.  Too weak?  That's your opinion, and it doesn't weigh more
(B> than others'.
(B
(BI'm mentioning weakness of reasoning. At least, I was tried to ;)
(B
(B>>> My thoughts exactly. Defaults should work for the masses - it's not
(B>>> like it's enforced behavior, that is irreversible.
(B
(Bimplies most/many scripts/users need additional flushing.
(BThis is obviously wrong.
(B
(BOnly very small portion of scripts need flushing for every outputs.
(B(I'm guessing, but nobody objects right?)
(B
(BEven when flushing is needed
(B
(Bfunction prompt($prefix) {
(B echo $prefix;
(B flush();
(B}
(B
(Bis _TRIVIAL_ to write. People should have this kind of
(Bfunction instead of enabling inefficient implicit flushing
(Bsince it's more efficient and reliable.
(B
(BTherefore, "enabling it for the *mass*/ intuitive for users"
(Bdoes not make sense, hence weak reasoning.
(B
(BIf implicit flush is preferred for some scripts, it should be
(Benabled when it is needed because the needs is obviously fewer.
(B
(BI agree, it's a choice but there is good and bad even
(Bif it's not clear sometimes.
(B
(BWhy don't we follow simple rule "more needs" = default,
(B"less needs" = optional especially when it's easy to switch.
(B(we haven't released it yet :)
(B
(BBTW, please vote to this thread. It easier to follow who is
(Bvoting for.
(B
(Bhttp://news.php.net/article.php?group=php.dev&article=89995
(B
(BAnyway, what kind of default we have for implicit flush in
(Bphp.ini-dest/recommended now and in the future? We have _OFF_
(Bby default. It also help us to make better decision, IMO.
(B
(BDefault OFF is more intuitive, IMHO.
(B
(B--
(BYasuo Ohgaki
(B
(B
(B
(B
(B
(B
(B-- 
(BPHP Development Mailing List 
(BTo unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] PHP usage stats

[Maxim Maletsky]

I think we should listen to Kristian here. It's never bad having some
statistics about PHP usage.

P.S: changins the subject. Other seem not to work too well. I Wonder why
:)

--
Maxim Maletsky
[EMAIL PROTECTED]


www.PHPBeginner.com  // PHP for Beginners
www.maxim.cx // my Home

// my Wish List: ( Get me something! )
http://www.amazon.com/exec/obidos/registry/2IXE7SMI5EDI3



Kristian Koehntopp <[EMAIL PROTECTED]> wrote... :

> On Thursday 24 October 2002 11:28, Zeev Suraski wrote:
> > I don't think that matters that much really.  Even if it's 2%, and not 12%
> > or 50%, we're still talking about billions of lines of code...
> 
> Yes, we do.
> 
> I am still offering the opportunity to run a statistical analysis of choice 
> across a very large assembly of real world PHP use for all of you, provided 
> you come up with a script that does the counting. This is not limited to 
>  
> Kristian
> 
> 
> -- 
> PHP Development Mailing List 
> To unsubscribe, visit: http://www.php.net/unsub.php
> 


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] running tests with CGI binary

[Hartmut Holzgraefe]

fact #1: some tests *require* cgi sapi (eg. POST stuff)

fact #2: current test suid *does not work* with php-cgi

conclusion: a lot of stuff doesn't get any automatic testing

solution: (see attached patch)
  - run-tests.php sets USER_AGENT=run-tests.php
  - run-tests.php prepends testcode with chdir()
  - php-cgi falls back to argc/argv parsing even
if in cgi mode when USER_AGENT=run-tests.php

with the patch applied the following works again:

  export TEST_PHP_EXECUTABLE=sapi/cgi/php-cgi
  sapi/cli/php run-tests.php

comments? ;)

-8<-
Index: run-tests.php
===
RCS file: /repository/php4/run-tests.php,v
retrieving revision 1.83
diff -u -2 -r1.83 run-tests.php
--- run-tests.php   23 Oct 2002 12:54:57 -  1.83
+++ run-tests.php   24 Oct 2002 09:26:06 -
@@ -83,4 +83,6 @@
 }

+$php = realpath($php);
+
 // Check whether a detailed log is wanted.
 if (getenv('TEST_PHP_DETAILED')) {
@@ -425,4 +427,5 @@

// Reset environment from any previous test.
+   putenv("USER_AGENT=run-tests.php");
putenv("REDIRECT_STATUS=");
putenv("QUERY_STRING=");
@@ -437,7 +440,8 @@
if (trim($section_text['SKIPIF'])) {
save_text($tmp_skipif, $section_text['SKIPIF']);
-   $output = `$php $tmp_skipif`;
+   putenv("PATH_TRANSLATED=$tmp_skipif");
+   $output = `$php -q $tmp_skipif`;
@unlink($tmp_skipif);
-   if (ereg("^skip", trim($output))){
+   if (ereg("^skip", $output)){
echo "SKIP $tested";
$reason = (ereg("^skip[[:space:]]*(.+)\$", trim(
$output))) ? ereg_replace("^skip[[:space:]]*(.+)\$", "\\1", trim($output)) : FAL
SE;
@@ -478,5 +482,5 @@

// We've satisfied the preconditions - run the test!
-   save_text($tmp_file,$section_text['FILE']);
+   save_text($tmp_file,"" . $section_text['F
ILE']);
if (array_key_exists('GET', $section_text)) {
$query_string = trim($section_text['GET']);
@@ -502,6 +506,5 @@
putenv("CONTENT_LENGTH=$content_length");

-   $cmd = "$php$ini_settings -f $tmp_file 2>&1 < $tmp_post";
-
+   $cmd = "$php -q $ini_settings -f $tmp_file 2>&1 < ". realpath($t
mp_post);
} else {

@@ -510,5 +513,5 @@
putenv("CONTENT_LENGTH=");

-   $cmd = "$php$ini_settings -f $tmp_file$args 2>&1";
+   $cmd = "$php -q $ini_settings -f $tmp_file$args 2>&1";
}

@@ -524,6 +527,6 @@
 ";

-   $out = `$cmd`;
-
+   $out = `$cmd`;
+
@unlink($tmp_post);

Index: sapi/cgi/cgi_main.c
===
RCS file: /repository/php4/sapi/cgi/cgi_main.c,v
retrieving revision 1.183
diff -u -2 -r1.183 cgi_main.c
--- sapi/cgi/cgi_main.c 13 Oct 2002 09:40:44 -  1.183
+++ sapi/cgi/cgi_main.c 24 Oct 2002 09:26:06 -
@@ -523,5 +523,5 @@
 {
int exit_status = SUCCESS;
-   int cgi = 0, c, i, len;
+   int cgi = 0, c, i, len, testmode = 0;
zend_file_handle file_handle;
int retval = FAILURE;
@@ -574,4 +574,8 @@
 #endif

+#ifndef PHP_FASTCGI
+   s = getenv("USER_AGENT");
+   if(s && !strcmp(s, "run-tests.php")) testmode = 1;
+#endif

 #ifdef ZTS
@@ -876,9 +880,9 @@
zend_llist_init(&global_vars, sizeof(char *), NULL, 0);

-   if (!cgi
+   if ( testmode || (!cgi
 #ifdef PHP_FASTCGI
&& !fastcgi
 #endif
-   ) { /* never execute
 the arguments if you are a CGI */
+   )) { /* never execute the arguments if you are a CGI unl
ess in testmode*/
if (SG(request_info).argv0) {
free(SG(request_info).argv0);


--
Six Offene Systeme GmbH http://www.six.de/
i.A. Hartmut Holzgraefe
Email: [EMAIL PROTECTED]
Tel.:  +49-711-99091-77


--
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV]

[Kristian Koehntopp]

On Thursday 24 October 2002 11:28, Zeev Suraski wrote:
> I don't think that matters that much really.  Even if it's 2%, and not 12%
> or 50%, we're still talking about billions of lines of code...

Yes, we do.

I am still offering the opportunity to run a statistical analysis of choice 
across a very large assembly of real world PHP use for all of you, provided 
you come up with a script that does the counting. This is not limited to 
http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] I hope this is the last email about this :) (was

[Zeev Suraski]

At 10:01 24/10/2002, Yasuo Ohgaki wrote:

Melvyn Sopacua wrote:

At 02:51 24-10-2002, Alan Knowles wrote:


Im +1 for reverting the patch - (for what it's worth)

Why?
Well - most 'average' (and below) PHP programmers when attempting to do 
CLI programming, will get a serious WTF reaction from wondering why when 
they 'echo' stuff, it doesnt appear. The more advanced Users can 
manually turn off flushing, but for most small, quick scripts (eg. 
50%+), this instant flush is going to be perfectly acceptable..

My thoughts exactly. Defaults should work for the masses - it's not like 
it's enforced behavior, that is irreversible.

? Which mass ?
Are you going to insist most scripts need inefficient auto flushing?
Have you ever used other programming languages?

I don't get it, but this is the 3rd vote.
Too few still and reasoning is too weak.


Too few?  It's 3 times more than the votes in favour, and now it's 4 times 
more.  Too weak?  That's your opinion, and it doesn't weigh more than others'.

Zeev


--
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] I hope this is the last email about this :) (was RFC:

[Zeev Suraski]

This has nothing to do with academical correctness.  Flushing or not 
flushing is not a matter of right or wrong, it's a matter of choice.

There's one 'real language' that does automatic flushing, it's called PHP, 
and it's going to stay that way.  Why other languages chose not to do it 
(maybe they don't have the facilities to do it?) is beside the point and 
not all that interesting.

Thank you.

Zeev

At 09:17 24/10/2002, Melvyn Sopacua wrote:
At 08:42 24-10-2002, Yasuo Ohgaki wrote:


I think this kind of code will be taught at the first
class of programming course. (I could be wrong,
since I don't know where people learned programming ;)


Why do you assume people learned programming?
I think Rasmus has made the case for PHP to be a language that
solves problems, not be academically correct, many times on this
list.


With kind regards,

Melvyn Sopacua



--
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php



--
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV]

[Zeev Suraski]

I don't think that matters that much really.  Even if it's 2%, and not 12% 
or 50%, we're still talking about billions of lines of code...

Let's, please, give it a rest.

Zeev

At 11:13 24/10/2002, Kristian Koehntopp wrote:

We have heard a lot of anecdotal evidence about the usage of 
other methods of PHP invocation. In order to clear things up a little, I have
asked a friend of mine for more detailed numbers from a real world example.

The following tests have been done very much ad hoc, and the numbers are not
representative. They have been made across the PHP files found at a very
large german provider. The test has been running for a night until he killed
it, and the friend estimated that a full run across several million domains
would take about 10 days to complete. He did not do anything to filter out
standard scripts such as phpMyAdmin, nor did he do anything else to
postprocess the numbers.

The following numbers have been generated by "find" and "grep" for all lines
that have something that resembles a PHP opening tag. These lines have then
been categorized and counted. The total result set had a size of approx. 1.3
million lines.




<%   0,3%


If you can come up with a script or a program that a) performs and b) can 
take
the output of "find" at stdin, I will ask for a more detailed statistic.

Kristian

--
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php


--
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV]

[Kristian Koehntopp]

We have heard a lot of anecdotal evidence about the usage of http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] I hope this is the last email about this :) (was

[Derick Rethans]

On Thu, 24 Oct 2002, Yasuo Ohgaki wrote:

> Melvyn Sopacua wrote:
> > 
> > My thoughts exactly. Defaults should work for the masses - it's not like 
> > it's enforced behavior, that is irreversible.
> 
> ? Which mass ?
> Are you going to insist most scripts need inefficient auto flushing?

 __   __
 \ \ / /__  ___
  \ V / _ \/ __|
   | |  __/\__ \
   |_|\___||___/ , because it is inituitive for a COMMAND line 
interface to flush after every outputted character. If you DONT want 
this inituitive bahavior you _can_ override it _anytime_ you want.

> Have you ever used other programming languages?

Tons of them, starting with pascal about 10 years ago, and did certainly 
flush after every character. 

> 
> I don't get it, but this is the 3rd vote.
> Too few still and reasoning is too weak.

As you're clearly not listening to other people's comments I'm going to 
put that line back into php_cli.c as the only flawed reasoning is yours.


Derick

--

---
 Derick Rethans   http://derickrethans.nl/ 
 JDI Media Solutions
--[ if you hold a unix shell to your ear, do you hear the c? ]-


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] I hope this is the last email about this :) (was

[Yasuo Ohgaki]

Melvyn Sopacua wrote:

At 02:51 24-10-2002, Alan Knowles wrote:


Im +1 for reverting the patch - (for what it's worth)

Why?
Well - most 'average' (and below) PHP programmers when attempting to 
do CLI programming, will get a serious WTF reaction from wondering why 
when they 'echo' stuff, it doesnt appear. The more advanced Users can 
manually turn off flushing, but for most small, quick scripts (eg. 
50%+), this instant flush is going to be perfectly acceptable..


My thoughts exactly. Defaults should work for the masses - it's not like 
it's enforced behavior, that is irreversible.

? Which mass ?
Are you going to insist most scripts need inefficient auto flushing?
Have you ever used other programming languages?

I don't get it, but this is the 3rd vote.
Too few still and reasoning is too weak.

BTW, if anyone would like to vote for inefficient/mostly useless
auto flushing. Please add your vote to this article.

http://news.php.net/article.php?group=php.dev&article=89995

--
Yasuo Ohgaki


--
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] I hope this is the last email about this :) (was RFC:

[Melvyn Sopacua]

At 16:42 10/24/2002 +0900, Yasuo Ohgaki wrote:


Melvyn Sopacua wrote:

At 08:42 24-10-2002, Yasuo Ohgaki wrote:


I think this kind of code will be taught at the first
class of programming course. (I could be wrong,
since I don't know where people learned programming ;)


Why do you assume people learned programming?
I think Rasmus has made the case for PHP to be a language that
solves problems, not be academically correct, many times on this
list.


Sure, some people just learn programming by themselves.


Indeed.


Are you trying to say "it justifies to have useless settings for
almost all scripts?" I hope not.


No, it justifies less academically correct __overridable defaults__, which are
intuitive for beginners.
Let me emphasize overridable defaults again, just to make sure you get
that I mean overridable defaults.


They should learn such simple thing even to be Sunday programmer.
Beside, the knowledge is useful for other popular languages, C/C++,
Java, Perl, Python, Ruby, etc.


Don't assume people ambition a career in programming, just because they use
a tool, to solve a specific problem they're facing.





void wakeup() {
for(unsigned int cuppajava;drink();cuppajava++);
}


--
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Re: Test suite and user space (Was: Re: [PHP-DEV] I hope this is the last email about this :))

[Yasuo Ohgaki]

Melvyn Sopacua wrote:

At 00:27 24-10-2002, Yasuo Ohgaki wrote:



PS: If you would like to write INI independent scripts, I
suggest you to use php.ini-recommended at least. You don't/
didn't know phps crashing and make test does not work well with
php.ini-recommended, nonetheless, you're insisting there is no
problems.



This is a totally different issue. If ini settings affect the test suite,
it's a bug in the test suite, period. If you depend on a preset 
environment,
you are testing how things behave in that environment, you are not testing
how that specific build for the __end user__ will behave once installed.

Do you realize php.ini used by run-tests.php and phpt differs?
Nothing to do with between them.



Test authors, can enforce specific settings they need, in the --INI--
section. If other settings affect the tests behavior, it is a good thing 
(tm)
to know this. It may be totally unexpected and shed light on why certain
bugs surface.


I'm writing the same thing _number_ of times

Do you realize php.ini used by run-tests.php and phpt differs?
Nothing to do with between them.



I also removed your statement in README.TESTING, which stated that "if a 
test
fails, the user can see if it's a real bug". There are no maybe's in a test
suite. It's a bug or it isn't. Putting in maybe's makes it's purpose 
confusing
and unreliable.

That's fine. When I wrote it, there were more than 30% of failed tests
due to improper maintenance of phpt, etc. It was unrealistic to check
them all at that time. I guess you don't know this fact.


This is one of the reasons, that during QA periods, some major bugs are not
uncovered ('file_exists'). People feel like "oh well, the test is probably
bogus", and do not report it.
Current work being done on the testsuite is IMO the right direction. 
Tests for
every function under whatever environment and the option to post to QA 
so that
the data can now be collected and analyzed.

It should be.
That's why I wrote README.TESTING to make test suite better.
If the more people understood tests, the more people help to
maintain ;)



If you see that the test suite is not working well, with 
php.ini-recommended,
than please report the tests affected. You don't adjust the road, just 
because
certain cars, have questionable steering - you fix the cars.

Do you realize php.ini used by run-tests.php and phpt differs?
Nothing to do with between them.

The more I get reply, the more I believe we should specify
php.ini-dist for run-tests.php. i.e. People are confused.


We do test with phpt, but we shouldn't test run-tests.php.
It's just a waste of time.

Remember, Derick removed the -c option, yet he does not understand
the problem with it, even if I've clearly mentioned _MANY_ times.
This incident is enough to illustrate that people cannot write ini
dependent script even if one has CVS account.

Sometimes simple things became harder to understand...

--
Yasuo Ohgaki




--
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] I hope this is the last email about this :) (was RFC:

[Yasuo Ohgaki]

Melvyn Sopacua wrote:

At 08:42 24-10-2002, Yasuo Ohgaki wrote:


I think this kind of code will be taught at the first
class of programming course. (I could be wrong,
since I don't know where people learned programming ;)



Why do you assume people learned programming?
I think Rasmus has made the case for PHP to be a language that
solves problems, not be academically correct, many times on this
list.


Sure, some people just learn programming by themselves.

Are you trying to say "it justifies to have useless settings for
almost all scripts?" I hope not.

They should learn such simple thing even to be Sunday programmer.
Beside, the knowledge is useful for other popular languages, C/C++,
Java, Perl, Python, Ruby, etc.

--
Yasuo Ohgaki



--
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] I hope this is the last email about this :) (was RFC:

[Melvyn Sopacua]

At 08:42 24-10-2002, Yasuo Ohgaki wrote:


I think this kind of code will be taught at the first
class of programming course. (I could be wrong,
since I don't know where people learned programming ;)


Why do you assume people learned programming?
I think Rasmus has made the case for PHP to be a language that
solves problems, not be academically correct, many times on this
list.


With kind regards,

Melvyn Sopacua



--
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] I hope this is the last email about this :) (was RFC: CLI behave like SH or PERL/RUBY/PYTHON?)

[Melvyn Sopacua]

At 02:51 24-10-2002, Alan Knowles wrote:


Im +1 for reverting the patch - (for what it's worth)

Why?
Well - most 'average' (and below) PHP programmers when attempting to do 
CLI programming, will get a serious WTF reaction from wondering why when 
they 'echo' stuff, it doesnt appear. The more advanced Users can manually 
turn off flushing, but for most small, quick scripts (eg. 50%+), this 
instant flush is going to be perfectly acceptable..

My thoughts exactly. Defaults should work for the masses - it's not like 
it's enforced behavior, that is irreversible.


With kind regards,

Melvyn Sopacua



--
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php