Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/mbstring/tests 027.inc027.phpt

[Yasuo Ohgaki]

Moriyoshi Koizumi wrote:

Hi,

I'm for Derick's option. Can I begin repacking each case to the single 
files now?

The only advantage putting everything in phpt is
is we can take a look at whole thing in one file.
Don't we have multiple windows or buffers? It's too
little advantage compare to have 2 files.

IMO, including script file give us more freedom to
write/execute test script. It's not efficient creating
normal script file when there is problem in phpt.

Anyway, if you volunteer to change it, go ahead.
(Please don't for pgsql tests :)

Please rename 001.phpt to something meaningful.
I just followed existing test script naming convention
and I don't like it, too. ;)

--
Yasuo Ohgaki




Moriyoshi

Yasuo Ohgaki <[EMAIL PROTECTED]> wrote:



Derick Rethans wrote:


Yes, works fine here:

(even with * instead of 025.*)


Thing has been changed ;)
I hope it's documented somewhere.

--
Yasuo Ohgaki









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

Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/mbstring/tests 027.inc027.phpt

[Derick Rethans]

On Tue, 22 Oct 2002, Yasuo Ohgaki wrote:

> Moriyoshi Koizumi wrote:
> > Hi,
> > 
> > I'm for Derick's option. Can I begin repacking each case to the single 
> > files now?
> 
> IMO, including script file give us more freedom to
> write/execute test script. It's not efficient creating
> normal script file when there is problem in phpt.
> 
> Anyway, if you volunteer to change it, go ahead.
> (Please don't for pgsql tests :)

tests may fail because of bugs in include, if you check functions you 
should rely as less possible on others, including include.

> 
> Please rename 001.phpt to something meaningful.
> I just followed existing test script naming convention
> and I don't like it, too.

I agree with this though.

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] Re: Segfaults in 4.2.3? (fwd)

[Aaron Gowatch]

Apologies if you receive this twice.  My posts dont appear to be going 
through...

Cheers.

Aa.

-- Forwarded message --
Date: Mon, 21 Oct 2002 11:57:09 -0700 (PDT)
From: Aaron Gowatch <[EMAIL PROTECTED]>
To: "[EMAIL PROTECTED]" <[EMAIL PROTECTED]>
Subject: Re: [PHP-DEV] Re: Segfaults in 4.2.3?

Is it possible to get any help at all on this?  Do I just need to open a
bug ticket?  I have tons of backtraces as well as tons of debug info being
written to the error log from --enable-debug.

Anyone?

Aa.

-- Forwarded message --
Date: Tue, 15 Oct 2002 12:15:07 -0700 (PDT)
From: Aaron Gowatch <[EMAIL PROTECTED]>
To: Aaron Gowatch <[EMAIL PROTECTED]>
Cc: Andi Gutmans <[EMAIL PROTECTED]>,
 "[EMAIL PROTECTED]" <[EMAIL PROTECTED]>
Subject: Re: [PHP-DEV] Re: Segfaults in 4.2.3?

Heres some more information on this segfault.  I'm running apache with 
MALLOC_CHECK_=2.

(gdb) handle SIGPIPE nostop
SignalStop  Print   Pass to program Description
SIGPIPE   NoYes Yes Broken pipe
(gdb) cont
Continuing.

Program received signal SIGABRT, Aborted.
0x42029331 in kill () from /lib/i686/libc.so.6
(gdb) bt
#0  0x42029331 in kill () from /lib/i686/libc.so.6
#1  0x4202911a in raise () from /lib/i686/libc.so.6
#2  0x4202a8c2 in abort () from /lib/i686/libc.so.6
#3  0x4207d3eb in realloc_check () from /lib/i686/libc.so.6
#4  0x4207b091 in realloc () from /lib/i686/libc.so.6
#5  0x4202b65c in __add_to_environ () from /lib/i686/libc.so.6
#6  0x4202b33f in putenv () from /lib/i686/libc.so.6
#7  0x080c87fb in zif_putenv (ht=1, return_value=0x8a1e5a4, this_ptr=0x0, 
return_value_used=0)
at basic_functions.c:1302
#8  0x0816c05b in execute (op_array=0x89e9880) at ./zend_execute.c:1598
#9  0x0816c22f in execute (op_array=0x866a594) at ./zend_execute.c:1638
#10 0x08148936 in zend_execute_scripts (type=8, retval=0x0, file_count=3) 
at zend.c:812
#11 0x080a61de in php_execute_script (primary_file=0xb670) at 
main.c:1383
#12 0x08153f72 in apache_php_module_main (r=0x82d0684, 
display_source_mode=0)
at sapi_apache.c:90
#13 0x080a2690 in send_php (r=0x82d0684, display_source_mode=0, 
filename=0x0) at mod_php4.c:575
#14 0x080a26de in send_parsed_php (r=0x82d0684) at mod_php4.c:590
#15 0x08174547 in ap_invoke_handler (r=0x82d0684) at http_config.c:538
#16 0x081837ef in process_request_internal (r=0x82d0684) at 
http_request.c:1308
#17 0x08183852 in ap_process_request (r=0x82d0684) at http_request.c:1324
#18 0x0817d0bc in child_main (child_num_arg=7) at http_main.c:4629
#19 0x0817d2b3 in make_child (s=0x829b70c, slot=7, now=1034706069) at 
http_main.c:4799
#20 0x0817d56e in perform_idle_server_maintenance () at http_main.c:4981
#21 0x0817d9f9 in standalone_main (argc=3, argv=0xbb14) at 
http_main.c:5218
#22 0x0817df50 in main (argc=3, argv=0xbb14) at http_main.c:5482
#23 0x42017589 in __libc_start_main () from /lib/i686/libc.so.6
(gdb) frame 8
#8  0x0816c05b in execute (op_array=0x89e9880) at ./zend_execute.c:1598
1598
((zend_internal_function *) 
EX(function_state).function)->handler(EX(opline)->extended_value, 
EX(Ts)[EX(opline)->result.u.var].var.ptr, EX(object).ptr, 
return_value_used TSRMLS_CC);
(gdb) print (char 
*)(executor_globals.function_state_ptr->function)->common.function_name
$1 = 0x822b98f "putenv"
(gdb) print (char *)executor_globals.active_op_array->function_name
$2 = 0x8ab16dc "set_up_language"
(gdb) print (char *)executor_globals.active_op_array->filename
$3 = 0x86214ec 
"/var/www/vhost/webmail.divinia.com/docs/functions/i18n.php"
(gdb) frame 7
#7  0x080c87fb in zif_putenv (ht=1, return_value=0x8a1e5a4, this_ptr=0x0, 
return_value_used=0)
at basic_functions.c:1302
1302if ((ret = putenv(pe.putenv_string)) == 0) {/* 
success */
(gdb) print pe.putenv_string
$4 = 0x8a1e4ec "LC_ALL=en_US"

Heres the snippet of code that appears to be triggering the abort:

if ( !ini_get('safe_mode') &&
 getenv( 'LC_ALL' ) != $sm_notAlias ) {
putenv( "LC_ALL=$sm_notAlias" );
putenv( "LANG=$sm_notAlias" );
putenv( "LANGUAGE=$sm_notAlias" );
}

Seems that I can call this snippet of code all day and it wont segfault, 
however...

Any help would be greatly appreciated.

Aa.

On Mon, 14 Oct 2002, Aaron Gowatch wrote:

> Andi --
> 
> I'm still trying to track that down.  Given the backtrace below, is it
> possible to find out what script or function was executing when the
> process SIGSEGV'd?  I read the docs on bugs.php.net on diagnosing crashes
> with gdb, but this looks a little different (ie. theres no execute() in
> this backtrace).  Its also possible that the bug that caused this SIGSEGV
> happened in a previous request.  I posted some of the errors that php is 
> logging last night, which were similar to:
> 
> [Mon Oct 14 11:06:45 2002]  Script:  
> '/var/www/vhost/webmail.divinia.com/docs/src/read_body.php'
> ---

Re: [PHP-DEV] Forked ext/gd by default

[Derick Rethans]

On Mon, 21 Oct 2002, Rasmus Lerdorf wrote:

> Yes, I think we can do that.  --with-gd without any path should bring in
> the bundled version.  That's also consistent with how we handle the other
> bundled libs.

yeah, sounds like a good idea.

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

[PHP-DEV] Regex Libraries

[Ilia A.]

Currently PHP contains two bundled regular expression libraries, PECL and 
regex. I am wondering if it would be a good idea to drop the old regex (dates 
back to 1999) library and use only PECL. The advantage is performance, 
cleaner code and a more flexible and more recent library. For the people who 
still use ereg functions, we could create wrappers that would implement their 
functionality using PECL and possibly add an E_NOTICE indicating that using 
PECL function preg_* would be a better approach.


Ilia

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

Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/mbstring/tests 027.inc

[Yasuo Ohgaki]

Derick Rethans wrote:

On Tue, 22 Oct 2002, Yasuo Ohgaki wrote:



Moriyoshi Koizumi wrote:


Hi,

I'm for Derick's option. Can I begin repacking each case to the single 
files now?

IMO, including script file give us more freedom to
write/execute test script. It's not efficient creating
normal script file when there is problem in phpt.

Anyway, if you volunteer to change it, go ahead.
(Please don't for pgsql tests :)



tests may fail because of bugs in include, if you check functions you 
should rely as less possible on others, including include.

Sure, but we have complex enough run-tests.php.
Separate file is better if this is the case.
i.e. if we cannot rely on basic things, "php some_test.inc"
is much simpler :)

--
Yasuo Ohgaki



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

Re: [PHP-DEV] Forked ext/gd by default

[Pierre-Alain Joye]

On Mon, 21 Oct 2002 21:05:52 +0200 (CEST)
Derick Rethans <[EMAIL PROTECTED]> wrote:
er image* functions.
> 
> gdImageRotate would be the _internal_ name of the C function our
> bundled GD :)

exactly :) imagerotate from the script.

pa

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

[PHP-DEV] php_value vs. php_admin_value

[Jani Taskinen]

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..)

--Jani



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

Re: [PHP-DEV] longopts in basic_functions.c:1521

[Moriyoshi Koizumi]

I missed the point... BTW that seems to have been fixed now.

Moriyoshi



Melvyn Sopacua <[EMAIL PROTECTED]> wrote:

> At 04:04 10/22/2002 +0900, Moriyoshi Koizumi wrote:
> 
> >./buildconf needed
> 
> ?
> [EMAIL PROTECTED] ~/cvs/php4
> $ history
> [...]
>513  export MAKE=gmake
>514  ./buildconf
>515  ./configure-cmd.sh
>516  gmake
>517  vi ext/standard/basic_functions.c
> 
> Look at the code:
> #ifdef HAVE_GETOPT_LONG
>  struct option *longopts = NULL;
>  int longindex = 0;
> #endif
> 
> struct only defined, when HAVE_GETOPT_LONG is defined.
> line 1521 is the only reference to struct longopts that is not protected.
> 
> Don't see how buildconf could help, and I even did that.
> 
> 
> 
> >Moriyoshi
> >
> >Melvyn Sopacua <[EMAIL PROTECTED]> wrote:
> >
> > > Hi,
> > >
> > > Current CVS doesn't compile for me, cause longopts isn't protected
> > > with an #ifdef HAVE_GETOPT_LONG and an alternate approach.
> > >
> > > /home/msopacua/cvs/php4/ext/standard/basic_functions.c: In function
> > > `zif_getopt':
> > > /home/msopacua/cvs/php4/ext/standard/basic_functions.c:1521: `longopts'
> > > undeclared (first use in this function)
> > > /home/msopacua/cvs/php4/ext/standard/basic_functions.c:1521: (Each
> > > undeclared identifier is reported only once
> > > /home/msopacua/cvs/php4/ext/standard/basic_functions.c:1521: for each
> > > function it appears in.)
> > > /home/msopacua/cvs/php4/ext/standard/basic_functions.c:1521: `longindex'
> > > undeclared (first use in this function)
> > > gmake: *** [ext/standard/basic_functions.lo] Error 1
> > >
> > >
> > > Met vriendelijke groeten / With kind regards,
> > >
> > > Webmaster IDG.nl
> > > Melvyn Sopacua
> > >
> > > <@Logan> I spent a minute looking at my own code by accident.
> > > <@Logan> I was thinking "What the hell is this guy doing?"
> > >
> > >
> > > --
> > > PHP Development Mailing List 
> > > To unsubscribe, visit: http://www.php.net/unsub.php
> > >
> 
> Met vriendelijke groeten / With kind regards,
> 
> Webmaster IDG.nl
> Melvyn Sopacua
> 
> <@Logan> I spent a minute looking at my own code by accident.
> <@Logan> I was thinking "What the hell is this guy doing?"
> 
> 
> -- 
> 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] longopts in basic_functions.c:1521

[Melvyn Sopacua]

On Tue, 22 Oct 2002, Moriyoshi Koizumi wrote:

> I missed the point...

No worries, do you know how hard it is to hit a point? :)

> BTW that seems to have been fixed now.

Yep, saw that and tried and worked.
Thanx Hartmut.

> 
> Moriyoshi
> 
> 
> 
> Melvyn Sopacua <[EMAIL PROTECTED]> wrote:
> 
> > At 04:04 10/22/2002 +0900, Moriyoshi Koizumi wrote:
> > 
> > >./buildconf needed
> > 
> > ?
> > [EMAIL PROTECTED] ~/cvs/php4
> > $ history
> > [...]
> >513  export MAKE=gmake
> >514  ./buildconf
> >515  ./configure-cmd.sh
> >516  gmake
> >517  vi ext/standard/basic_functions.c
> > 
> > Look at the code:
> > #ifdef HAVE_GETOPT_LONG
> >  struct option *longopts = NULL;
> >  int longindex = 0;
> > #endif
> > 
> > struct only defined, when HAVE_GETOPT_LONG is defined.
> > line 1521 is the only reference to struct longopts that is not protected.
> > 
> > Don't see how buildconf could help, and I even did that.
> > 
> > 
> > 
> > >Moriyoshi
> > >
> > >Melvyn Sopacua <[EMAIL PROTECTED]> wrote:
> > >
> > > > Hi,
> > > >
> > > > Current CVS doesn't compile for me, cause longopts isn't protected
> > > > with an #ifdef HAVE_GETOPT_LONG and an alternate approach.
> > > >
> > > > /home/msopacua/cvs/php4/ext/standard/basic_functions.c: In function
> > > > `zif_getopt':
> > > > /home/msopacua/cvs/php4/ext/standard/basic_functions.c:1521: `longopts'
> > > > undeclared (first use in this function)
> > > > /home/msopacua/cvs/php4/ext/standard/basic_functions.c:1521: (Each
> > > > undeclared identifier is reported only once
> > > > /home/msopacua/cvs/php4/ext/standard/basic_functions.c:1521: for each
> > > > function it appears in.)
> > > > /home/msopacua/cvs/php4/ext/standard/basic_functions.c:1521: `longindex'
> > > > undeclared (first use in this function)
> > > > gmake: *** [ext/standard/basic_functions.lo] Error 1
> > > >
> > > >
> > > > Met vriendelijke groeten / With kind regards,
> > > >
> > > > Webmaster IDG.nl
> > > > Melvyn Sopacua
> > > >
> > > > <@Logan> I spent a minute looking at my own code by accident.
> > > > <@Logan> I was thinking "What the hell is this guy doing?"
> > > >
> > > >
> > > > --
> > > > PHP Development Mailing List 
> > > > To unsubscribe, visit: http://www.php.net/unsub.php
> > > >
> > 
> > Met vriendelijke groeten / With kind regards,
> > 
> > Webmaster IDG.nl
> > Melvyn Sopacua
> > 
> > <@Logan> I spent a minute looking at my own code by accident.
> > <@Logan> I was thinking "What the hell is this guy doing?"
> > 
> > 
> > -- 
> > PHP Development Mailing List 
> > To unsubscribe, visit: http://www.php.net/unsub.php
> > 
> 
> 
> 

-- 
With kind regards,

Melvyn Sopacua



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

Re: [PHP-DEV] longopts in basic_functions.c:1521

[Moriyoshi Koizumi]

./buildconf needed

Moriyoshi

Melvyn Sopacua <[EMAIL PROTECTED]> wrote:

> Hi,
> 
> Current CVS doesn't compile for me, cause longopts isn't protected
> with an #ifdef HAVE_GETOPT_LONG and an alternate approach.
> 
> /home/msopacua/cvs/php4/ext/standard/basic_functions.c: In function 
> `zif_getopt':
> /home/msopacua/cvs/php4/ext/standard/basic_functions.c:1521: `longopts' 
> undeclared (first use in this function)
> /home/msopacua/cvs/php4/ext/standard/basic_functions.c:1521: (Each 
> undeclared identifier is reported only once
> /home/msopacua/cvs/php4/ext/standard/basic_functions.c:1521: for each 
> function it appears in.)
> /home/msopacua/cvs/php4/ext/standard/basic_functions.c:1521: `longindex' 
> undeclared (first use in this function)
> gmake: *** [ext/standard/basic_functions.lo] Error 1
> 
> 
> Met vriendelijke groeten / With kind regards,
> 
> Webmaster IDG.nl
> Melvyn Sopacua
> 
> <@Logan> I spent a minute looking at my own code by accident.
> <@Logan> I was thinking "What the hell is this guy doing?"
> 
> 
> -- 
> 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] HEAD b0rked

[Sebastian Bergmann]

  Accessing a phpinfo() script gives me

Warning: No content-type in GET request in Unknown on line 0
Warning: Cannot modify header information - headers already sent in
Unknown on line 0

  Apache 2 + SAPI/CGI on Win32.

-- 
  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: [PHP-CVS] cvs: php4 /ext/mbstring/tests 027.inc027.phpt

[Yasuo Ohgaki]

Melvyn Sopacua wrote:

At 22:00 10/21/2002 +0900, Yasuo Ohgaki wrote:


Derick Rethans wrote:


Yes, works fine here:
(even with * instead of 025.*)



Thing has been changed ;)
I hope it's documented somewhere.



Here's the docs:
http://news.php.net/article.php?group=php.cvs&article=14780


It's not called documentation, but CVS log, isn't it :)

--
Yasuo Ohgaki



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

Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/mbstring/tests 027.inc027.phpt

[Derick Rethans]

On Tue, 22 Oct 2002, Moriyoshi Koizumi wrote:

> I'm for Derick's option. Can I begin repacking each case to the single 
> files now?

please :)

Derick

> Yasuo Ohgaki <[EMAIL PROTECTED]> wrote:
> 
> > Derick Rethans wrote:
> > > Yes, works fine here:
> > > 
> > > (even with * instead of 025.*)
> > 
> > Thing has been changed ;)
> > I hope it's documented somewhere.
> > 
> > --
> > Yasuo Ohgaki
> 
> 
> -- 
> 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] longopts in basic_functions.c:1521

[Melvyn Sopacua]

Hi,

Current CVS doesn't compile for me, cause longopts isn't protected
with an #ifdef HAVE_GETOPT_LONG and an alternate approach.

/home/msopacua/cvs/php4/ext/standard/basic_functions.c: In function 
`zif_getopt':
/home/msopacua/cvs/php4/ext/standard/basic_functions.c:1521: `longopts' 
undeclared (first use in this function)
/home/msopacua/cvs/php4/ext/standard/basic_functions.c:1521: (Each 
undeclared identifier is reported only once
/home/msopacua/cvs/php4/ext/standard/basic_functions.c:1521: for each 
function it appears in.)
/home/msopacua/cvs/php4/ext/standard/basic_functions.c:1521: `longindex' 
undeclared (first use in this function)
gmake: *** [ext/standard/basic_functions.lo] Error 1


Met vriendelijke groeten / With kind regards,

Webmaster IDG.nl
Melvyn Sopacua

<@Logan> I spent a minute looking at my own code by accident.
<@Logan> I was thinking "What the hell is this guy doing?"


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

[PHP-DEV] Forked ext/gd by default

[Andrei Zmievski]

I think we should use forked version of gd library by default for 4.3.0.
>From what I hear it is already the best version of any of them out there
and if it saves us any more grief, all the better. Objections?

-Andrei   http://www.gravitonic.com/

"You choose to do the bad things in your life;
 the good ones come and drag you along with them."
- Michael Marshall Smith

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

[PHP-DEV] Work is beginning on cURL and PHP again

[Sterling Hughes]

Hi,

I'm going to be working on updating the PHP cURL extension in the coming
weeks: 

* adding the multi-interface. 
* ssl session id caching (globally) 
* global dns cache in threaded webservers (same for ssl sesssion id
caching)
* allowing cURL handle re-use.
* allowing "persistent" cURL handles that survive the request, for HTTP
1.1 persistent connections
* Autogenerating much of the interface between cURL and PHP, allowing
PHP to support multiple versions of the underlying cURL library
* Supporting all cURL options/callbacks in one way or another
* Adding a OOP interface to cURL, on the extension level... [undecided]
* Updating the cURL documentation

So, I'm sending this message, to the lists just to get any suggestions,
comments, feature requests, bug reports that you would like me to look
at/consider when revamping the extension.  The changes will be done step
by step to the extension, but the full revamping should be expected
around the time of PHP 5 (PHP 4.3 is too soon for all these changes to
be integrated and tested).

-Sterling

PS: I'll be at the PHP Conference in Frankfurt, and ApacheCon in Las
Vegas, if you're coming to either of those, feel free to talk about it
with me there as well...

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

Re: [PHP-DEV] Work is beginning on cURL and PHP again

[Jon Parise]

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 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Idea to extend language: Explicitly setting variable scope inside user defined function (longer)

[NTPT]

- Original Message -
From: "Maxim Maletsky" <[EMAIL PROTECTED]>
To: "Marco Tabini" <[EMAIL PROTECTED]>
Cc: "Rasmus Lerdorf" <[EMAIL PROTECTED]>; "NTPT" <[EMAIL PROTECTED]>;
<[EMAIL PROTECTED]>
Sent: Monday, October 21, 2002 12:37 PM
Subject: Re: [PHP-DEV] Idea to extend language: Explicitly setting variable
scope inside user defined function (longer)



>
> Well, in a way it is right to have this, but in a way it get things more
> difficult for newbies to start. I prefer PHP handling variables the way
> it does right now.

My suggestion is optional. Programmer can  use it. can != must. ie if he do
not need this feature, he do not use var_scope keyword and everything should
work as normal.


> Maybe something like what is suggested can be
> optional, but I don't think it is really doable as to be "an option".
>
> --
> Maxim Maletsky
> [EMAIL PROTECTED]
>
> www.PHPBeginner.com  // where PHP Begins
>
>
> --
> PHP Development Mailing List 
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>


---
Odchozí zpráva neobsahuje viry.
Zkontrolováno antivirovým systémem AVG (http://www.grisoft.cz).
Verze: 6.0.401 / Virová báze: 226 - datum vydání: 9.10.2002


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

[PHP-DEV] Global HashTables & access violations

[Brian 'Bex' Huff]

php 4.2.3 and 4.2.2
windows 2000
command line debugging

I posted this a week ago, no replies yet...

Ive written an extension to PHP that (among other things) uses a global 
HashTable object for a mini cache.  I fill it, and then have a simple 
PHP function to pull a string out of the cache, and return it.  However, 
I keep getting wierd internal access violations whenever I try to use it.

In the sample code below, if I do this in test.php:

	$zendTest = idc_env("zendTest");
	echo "zendTest: $zendTest\n";

And execute it, the value "this is a zend test" will be output to the 
screen, as well as everything after. My code executes fine... but at the 
very very last second I get an access violation when 
"zend_execute_scripts" tries to calculate "if(!retval)", because 
suddenly "retval" cannot be evaluated any more.  Whaaa?

Anyway, here's the relevant snippets of my C code:

===

PHP_RINIT_FUNCTION(idc)
{
  zval* val;
  char* key = "zendTest";
  MAKE_STD_ZVAL(val);
  ZVAL_STRING(val, "this is a zend test", 1);

  // move to PHP_MINIT_FUNCTION after all bugs are out
  ALLOC_HASHTABLE(IDC_G(server_environment));
  zend_hash_init(IDC_G(server_environment), 0, NULL, ZVAL_PTR_DTOR, 0);

  // run a test
  zend_hash_update(IDC_G(server_environment), key, strlen(key)+1,
(void *)&val, sizeof(zval *), NULL);

  return SUCCESS;
}

PHP_RSHUTDOWN_FUNCTION(idc)
{
  // move to PHP_MSHUTDOWN_FUNCTION once all bugs are out
  zend_hash_destroy(IDC_G(server_environment));
  FREE_HASHTABLE(IDC_G(server_environment));

  return SUCCESS;
}

PHP_FUNCTION(idc_env)
{
  HashTable *env = IDC_G(server_environment);
  zval **value = NULL;
  char *valueStr = NULL;
  int argc = ZEND_NUM_ARGS();
  char *name = NULL;

  if (zend_parse_parameters(argc TSRMLS_CC, "s", &name) == FAILURE)
return;

  if (zend_hash_find(env, name, strlen(name) + 1,
	(void **) &value) == SUCCESS)
  {
if ((*value)->type == IS_STRING)
{
  valueStr = Z_STRVAL_PP(value);
  return_value->type = IS_STRING;
  return_value->value.str.len = Z_STRLEN_PP(value);
  return_value->value.str.val = estrdup(valueStr);
}
  }
}

===

Im assuming that Im not initializing (or destroying) something properly, 
but my code seems to be fairly correct, based on the other PHP 
extensions.  In addition, if I move the code in RSTARTUP and RSHUTDOWN 
to MSTARTUP and MSHUTDOWN, I get a bunch of memory leaks that dont make 
any sense... the leaks are worse in php 4.2.3 than in 4.2.2. I have no 
clue why that would be.

Any hints on the "right" way to use a HashTable or Zend object in C for 
a global PHP mini-cache would be greatly appreciated...

--

Brian 'Bex' Huff
[EMAIL PROTECTED]
Phone: 952-903-2023
Fax: 952-829-5424


**All Electronic Mail sent from the Stellent, Inc Electronic Communication Network is scanned by Antigen 7.0.**

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

Re: [PHP-DEV] longopts in basic_functions.c:1521

[Melvyn Sopacua]

At 04:04 10/22/2002 +0900, Moriyoshi Koizumi wrote:


./buildconf needed


?
[EMAIL PROTECTED] ~/cvs/php4
$ history
[...]
  513  export MAKE=gmake
  514  ./buildconf
  515  ./configure-cmd.sh
  516  gmake
  517  vi ext/standard/basic_functions.c

Look at the code:
#ifdef HAVE_GETOPT_LONG
struct option *longopts = NULL;
int longindex = 0;
#endif

struct only defined, when HAVE_GETOPT_LONG is defined.
line 1521 is the only reference to struct longopts that is not protected.

Don't see how buildconf could help, and I even did that.




Moriyoshi

Melvyn Sopacua <[EMAIL PROTECTED]> wrote:

> Hi,
>
> Current CVS doesn't compile for me, cause longopts isn't protected
> with an #ifdef HAVE_GETOPT_LONG and an alternate approach.
>
> /home/msopacua/cvs/php4/ext/standard/basic_functions.c: In function
> `zif_getopt':
> /home/msopacua/cvs/php4/ext/standard/basic_functions.c:1521: `longopts'
> undeclared (first use in this function)
> /home/msopacua/cvs/php4/ext/standard/basic_functions.c:1521: (Each
> undeclared identifier is reported only once
> /home/msopacua/cvs/php4/ext/standard/basic_functions.c:1521: for each
> function it appears in.)
> /home/msopacua/cvs/php4/ext/standard/basic_functions.c:1521: `longindex'
> undeclared (first use in this function)
> gmake: *** [ext/standard/basic_functions.lo] Error 1
>
>
> Met vriendelijke groeten / With kind regards,
>
> Webmaster IDG.nl
> Melvyn Sopacua
>
> <@Logan> I spent a minute looking at my own code by accident.
> <@Logan> I was thinking "What the hell is this guy doing?"
>
>
> --
> PHP Development Mailing List 
> To unsubscribe, visit: http://www.php.net/unsub.php
>


Met vriendelijke groeten / With kind regards,

Webmaster IDG.nl
Melvyn Sopacua

<@Logan> I spent a minute looking at my own code by accident.
<@Logan> I was thinking "What the hell is this guy doing?"


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

[PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/mbstring/tests 027.inc 027.phpt

[Yasuo Ohgaki]

Derick Rethans wrote:

Yes, works fine here:

(even with * instead of 025.*)


Thing has been changed ;)
I hope it's documented somewhere.

--
Yasuo Ohgaki



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

Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/mbstring/tests 027.inc027.phpt

[Moriyoshi Koizumi]

> The only advantage putting everything in phpt is
> is we can take a look at whole thing in one file.
> Don't we have multiple windows or buffers? It's too
> little advantage compare to have 2 files.

First I looked at your style, I think it was somewhat cool,
because then I wasn't able to run a single test with a cgi binary
(before CLI era)

> IMO, including script file give us more freedom to
> write/execute test script. It's not efficient creating
> normal script file when there is problem in phpt.
> 
> Anyway, if you volunteer to change it, go ahead.
> (Please don't for pgsql tests :)

I'm never for the unreasonable standarlization. We've been working on a 
voluntary basis, and each style should be respected, unless it only causes 
increasing entropy aka inefficiency. I mean in some cases consistency is 
no longer the first thing, and then yours doesn't look like such a 
obstacle for me.

> Please rename 001.phpt to something meaningful.
> I just followed existing test script naming convention
> and I don't like it, too. ;)

Is good thing, though.


Moriyoshi



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

Re: [PHP-DEV] Work is beginning on cURL and PHP again

[Sterling Hughes]

On Mon, 2002-10-21 at 22:15, Jon Parise wrote:
> 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?
> 

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:

1) There is a definition in for the constant in the file
php4/ext/curl/objects.def, in the form of something like:

CURLOPT_OPTNAME: {
// code goes here
}

2) the type of the constant is OBJECTPOINT

(the words "type" and "constant" are used loosely here :)

Then for constants that are definied in both curl/objects.def and
curl.h, i'll add the code for them into curl.c.  Any other constants
will get simply get the "undefined constant" warning with E_ALL and cURL
will complain that the constant doesn't exist when curl_setopt() is
used, at least this is the current plan for auto-generation.

I'm also debating just having a standard (generated from the latest
stable cURL version) file, in case Perl is not present on the users
system (but if Perl isn't present on your system - that's pretty bad :)

-Sterling




--
Sterling Hughes <[EMAIL PROTECTED]>
Did I help you? Consider a gift: http://wishlist.edwardbear.org/

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

Re: [PHP-DEV] Forked ext/gd by default

[Derick Rethans]

On Mon, 21 Oct 2002, Sander Roobol wrote:

> On Mon, Oct 21, 2002 at 08:45:19PM +0200, Pierre-Alain Joye wrote:
> > On Mon, 21 Oct 2002 14:41:02 -0400 Andrei Zmievski wrote:
> > > I think we should use forked version of gd library by default for
> > > 4.3.0. From what I hear it is already the best version of any of them
> > > out there and if it saves us any more grief, all the better.
> > > Objections?
> 
> Nope, +1.
> 
> > I ll post the patch for gdImageRotate (another name in mind ? ;) )
> > function tonight.
> 
> It should be just imagerotate(), that's more consistent with the other
> image* functions.

gdImageRotate would be the _internal_ name of the C function our bundled 
GD :)

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] Forked ext/gd by default

[Pierre-Alain Joye]

On Mon, 21 Oct 2002 14:41:02 -0400
Andrei Zmievski <[EMAIL PROTECTED]> wrote:

> I think we should use forked version of gd library by default for
> 4.3.0. From what I hear it is already the best version of any of them
> out there and if it saves us any more grief, all the better.
> Objections?

w00t

I ll post the patch for gdImageRotate (another name in mind ? ;) )
function tonight.

hth

pa

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

Re: [PHP-DEV] Forked ext/gd by default

[Sander Roobol]

On Mon, Oct 21, 2002 at 08:45:19PM +0200, Pierre-Alain Joye wrote:
> On Mon, 21 Oct 2002 14:41:02 -0400 Andrei Zmievski wrote:
> > I think we should use forked version of gd library by default for
> > 4.3.0. From what I hear it is already the best version of any of them
> > out there and if it saves us any more grief, all the better.
> > Objections?

Nope, +1.

> I ll post the patch for gdImageRotate (another name in mind ? ;) )
> function tonight.

It should be just imagerotate(), that's more consistent with the other
image* functions.

Sander

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

[PHP-DEV] Re: Forked ext/gd by default

[Peter Neuman]

Hello,

"Andrei Zmievski" <[EMAIL PROTECTED]>:
> I think we should use forked version of gd library by default for 4.3.0.
> From what I hear it is already the best version of any of them out there
> and if it saves us any more grief, all the better. Objections?

+1
BTW: Update to gd-2.0.2 final?
See: http://www.boutell.com/gd/

Cu
Peter Neuman



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

Re: [PHP-DEV] Idea to extend language: Explicitly setting variable scope inside user defined function (longer)

[NTPT]

- Original Message -
From: "Andrey Hristov" <[EMAIL PROTECTED]>
To: "NTPT" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Monday, October 21, 2002 6:16 PM
Subject: Re: [PHP-DEV] Idea to extend language: Explicitly setting variable
scope inside user defined function (longer)


> - Original Message -
> From: "NTPT" <[EMAIL PROTECTED]>
> To: "Andrey Hristov" <[EMAIL PROTECTED]>; "Marco Tabini"
<[EMAIL PROTECTED]>
> Cc: <[EMAIL PROTECTED]>
> Sent: Monday, October 21, 2002 7:14 PM
> Subject: Re: [PHP-DEV] Idea to extend language: Explicitly setting
variable
> scope inside user defined function (longer)
>
>
> >
> > - Original Message -
> > From: "Andrey Hristov" <[EMAIL PROTECTED]>
> > To: "Marco Tabini" <[EMAIL PROTECTED]>
> > Cc: <[EMAIL PROTECTED]>
> > Sent: Monday, October 21, 2002 12:42 PM
> > Subject: Re: [PHP-DEV] Idea to extend language: Explicitly setting
> variable
> > scope inside user defined function (longer)
> >
> >
> > >
> > >
> > > > Marco Tabini <[EMAIL PROTECTED]> wrote... :
> > > >
> > >  > Well, you have to admit that the issue of variable scope is the
first
> > > > thing that hits someone who approaches PHP for the first time and
> comes
> > > > from other backgrounds, like C or ASP!
> > > >
> > >
> > > For me global vars are bad at all.
> > > If you want to use some value in a function then pass it to the
function
> > > even if you
> > > want you can pass an array will variable ammount of vars that has
names
> as
> > > indexes.
> >
> > Nice idea, i use it sometimes, it works, but ..
> >
> > real life situation like this:
> >
> >  > $sqlstring=" UPDATE  testtable SET
> db_value1='$value_1',db_value1='$value_1'
> > .etc db_value_n='$value_n'   ";
> >
> > // now you must produce  $passed_variables array , like this
> >
> >
> > // glue code
> > $passed_variables['value_1']=$value_1;
> > $passed_variables['value_2']=$value_2;
> >
> > .
> > etc
> > .
> > $passed_variables['value_n']=$value_n;
> > // end of glue code
> >
> > $result = db_query($passed_variables,$sqlstring)
> > {
>  I don't use it like you show but
> $result = db_query(array('value_1'=>$value_1, 'value_2'=>$value_2,
> 'value_n'=>$value_n), $sqlstring);
>
> As you see there are no additional lines.

You still need to construct an array, with take a processor time, and when
you pass it to the function you still need to "unpack" it, this action  take
a processor time...  you mean to use 'extract()'  ?


NTPT


---
Odchozí zpráva neobsahuje viry.
Zkontrolováno antivirovým systémem AVG (http://www.grisoft.cz).
Verze: 6.0.401 / Virová báze: 226 - datum vydání: 9.10.2002


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

Re: [PHP-DEV] Work is beginning on cURL and PHP again

[Shane Caraveo]

Sterling Hughes wrote:

On Mon, 2002-10-21 at 22:15, Jon Parise wrote:


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?




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! ;)

Shane



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

[PHP-DEV] Re: Bug count..

[Tom Sommer]

Jani Taskinen wrote:

Here you can find nice curve of the bug count:

  http://www.php.net/~jani/count.png

If this realtime?

--
* Tom Sommer
* http://www.tsn.dk | webmaster(a)tsn.dk
* Any sufficiently advanced bug is indistinguishable from a feature


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

Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/mbstring/tests 027.inc 027.phpt

[Melvyn Sopacua]

At 14:56 10/21/2002 +0200, Derick Rethans wrote:

[]


One test, one file.


... unless test depends on files being external or the include contains 
data shared
between tests. Right?


Met vriendelijke groeten / With kind regards,

Webmaster IDG.nl
Melvyn Sopacua

<@Logan> I spent a minute looking at my own code by accident.
<@Logan> I was thinking "What the hell is this guy doing?"


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

Re: [PHP-DEV] php_value vs. php_admin_value

[Rasmus Lerdorf]

admin directives can only be used in the httpd.conf file.  Non-admins can
be used in both httpd.conf and .htaccess.  ie. directives that end-users
should not be able to change themselves should be admin ones.

-Rasmus

On Mon, 21 Oct 2002, 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..)
>
> --Jani
>
>
>
> --
> 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] Forked ext/gd by default

[Sebastian Bergmann]

Andrei Zmievski wrote:
> I think we should use forked version of gd library by default for
> 4.3.0.

  +1

-- 
  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] Work is beginning on cURL and PHP again

[Sterling Hughes]

On Mon, 2002-10-21 at 22:46, Shane Caraveo wrote:
> Sterling Hughes wrote:
> > On Mon, 2002-10-21 at 22:15, Jon Parise wrote:
> > 
> >>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?
> >>
> > 
> > 
> > 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
;)

-- 
Sterling Hughes <[EMAIL PROTECTED]>
Did I help you? Consider a gift: http://wishlist.edwardbear.org/

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

Re: [PHP-DEV] php_value vs. php_admin_value

[Jon Parise]

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 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: Forked ext/gd by default

[Rasmus Lerdorf]

Whoa, pigs are flying over the skating rink in hell.  Anybody have some
time to go over this and sync things up?

On Mon, 21 Oct 2002, Peter Neuman wrote:

> Hello,
>
> "Andrei Zmievski" <[EMAIL PROTECTED]>:
> > I think we should use forked version of gd library by default for 4.3.0.
> > From what I hear it is already the best version of any of them out there
> > and if it saves us any more grief, all the better. Objections?
>
> +1
> BTW: Update to gd-2.0.2 final?
> See: http://www.boutell.com/gd/
>
> Cu
> Peter Neuman
>
>
>
> --
> 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] Work is beginning on cURL and PHP again

[Jon Parise]

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 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Regex Libraries

[Jan Kneschke]

On Mon, Oct 21, 2002 at 08:30:53AM -0400, Ilia A. wrote:
> Currently PHP contains two bundled regular expression libraries, PECL and 
> regex. I am wondering if it would be a good idea to drop the old regex (dates 
> back to 1999) library and use only PECL. The advantage is performance, 
> cleaner code and a more flexible and more recent library. For the people who 
> still use ereg functions, we could create wrappers that would implement their 
> functionality using PECL and possibly add an E_NOTICE indicating that using 
> PECL function preg_* would be a better approach.

$mail = str_replace("PECL", "PCRE", $mail);
 
> Ilia

  Jan

-- 
http://jan.kneschke.de - localizer, modlogan, pxtools
mailto:jan@;kneschke.de - Jan Kneschke

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

Re: [PHP-DEV] php_value vs. php_admin_value

[Jani Taskinen]

On Sun, 20 Oct 2002, Rasmus Lerdorf wrote:

>admin directives can only be used in the httpd.conf file.  Non-admins can
>be used in both httpd.conf and .htaccess.  ie. directives that end-users
>should not be able to change themselves should be admin ones.

Thanks. This was explained also in manual.. :I

--Jani



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

Re: [PHP-DEV] Regex Libraries

[Derick Rethans]

s/PECL/PCRE/ applies for all undefined references to PECL :-)

Derick

On Mon, 21 Oct 2002, Ilia A. wrote:

> Currently PHP contains two bundled regular expression libraries, PECL and 
> regex. I am wondering if it would be a good idea to drop the old regex (dates 
> back to 1999) library and use only PECL. The advantage is performance, 
> cleaner code and a more flexible and more recent library. For the people who 
> still use ereg functions, we could create wrappers that would implement their 
> functionality using PECL and possibly add an E_NOTICE indicating that using 
> PECL function preg_* would be a better approach.
> 
> 
> Ilia
> 
> -- 
> 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

Re: [PHP-DEV] setcookie problem

[Maxim Maletsky]

You should post this to the PHP General mailing list
([EMAIL PROTECTED]). People there will Definitely answer you.

-- 
Maxim Maletsky
[EMAIL PROTECTED]

www.PHPBeginner.com  // where PHP Begins



"Mehran Ziadloo" <[EMAIL PROTECTED]> wrote... :

> I've reached a problem which I don't know how to get over it.
>  Consider you have a PHP page with the following address:
>  http://www.domain.com/users/signin/set.php
>  this script's job is to set a cookie and it does. The problem is when I set
> them, when some other pages want to use that cookie, only the scripts which
> are in the same folder (with the script that set the cookies) can reach them
> and for other scripts it's hidden.
>  How can I set a cookie that all the pages can access it.
>  I'm setting the cookie with the following script:
>   setcookie("SessionID", $SessionID, 0, "/");
>  and if it helps I'm using IE6
>  thanks,
> 
> 
> 
> -- 
> 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 /ext/mbstring/tests 027.inc 027.phpt

[Derick Rethans]

On Mon, 21 Oct 2002, Yasuo Ohgaki wrote:

> Derick Rethans wrote:
> > On Mon, 21 Oct 2002, Yasuo Ohgaki wrote:
> > 
> > 
> >>Derick Rethans wrote:
> >>
> >>>That's why you can run only one test with:
> >>>PHP_TEST_EXECUTABLE=sapi/cli/php php run-tests ext/mbstring/tests/027.phpt
> >>
> >>Does it work for you ?
> >>
> >>[yohgaki@dev DEV]$ TEST_PHP_EXECUTABLE=sapi/cli/php php run-tests.php 
>ext/mbstring/tests/025.ppt
> > 
> > 
> > It's phpt, not  ppt as extension.
> 
> It's just readline/terminal messed line a little with up allow key.
> Correct command is passed and if file does not exist, error
> message differs. It does not work for me at least.
> 
> Running tests certain dir does not work for a long time,
> also.
> 
> You haven't the answer question, does it work for you?

Yes, works fine here:

[derick@kossu php-4.3.0dev]$ pwd
/dat/dev/php/php-4.3.0dev
[derick@kossu php-4.3.0dev]$ TEST_PHP_EXECUTABLE=sapi/cli/php php 
run-tests.php ext/mbstring/tests/025.*

=
CWD : /dat/dev/php/php-4.3.0dev
PHP : sapi/cli/php
PHP_SAPI: cli
PHP_VERSION : 4.3.0-dev
PHP_OS  : Linux
INI actual  : /etc/httpd/php.ini
More .INIs  : 
Extra dirs  : 
=
Running selected tests.
PASS mb_regex_set_options() [ext/mbstring/tests/025.phpt]

(even with * instead of 025.*)

> >>In addition, I don't know if CGI binary can be used under my
> >>environment(Linux). It never worked for me since the default
> >>binary became CLI.
> > 
> > 
> > It doesn't work because of chdir() issues. Easy to fix though. If I have 
> > some time I make special SAPI wrappers for the testsuite.
> 
> run-tests.php never worked with CGI since it made run with
> CLI.
> 
> I didn't try to look into, if it's easy to fix, it should
> be fixed :)

It's not easy to do it in a clean way.

> >>Anyway, Including test code in phpt does not make much sense to me.
> >>I keep binary like php-cgi-4.0.4pl1, php-cgi-4.0.6-debug, etc, etc.
> >>Plain source file is still very useful to check old behavior
> >>quickly.
> >>
> >>It isn't so important to put php source in phpt.
> > 
> > 
> > Consistency is important
> > 
> 
> Including file is not hurt consistency nor readability
> nor usability, IMHO.

Your opinion is clearly different then.

> 
> I don't mind if anyone willing to spent time
> to copy & paste included files, but separated php source
> is more useful. i.e. execute script with different versions of
> php quickly, easier to check & correct what's wrong test
> script itself, easier to check different parameters, easier
> to test with CGI bin, etc.
> 
> Is there any good reason to keep everything in phpt?
> (I mean does it make things easy, usable, etc?)

One test, one file.

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] Re: [PHP-CVS] cvs: php4 /ext/mbstring/tests 027.inc027.phpt

[Yasuo Ohgaki]

Melvyn Sopacua wrote:

However - it depends on include and relative path issues to
work as expected.


The problem is very frustrating, isn't?
What's the plan for it?

--
Yasuo Ohgaki



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

[PHP-DEV] CVS Account Request: tix

[Oliver Hinckel]

- I'll help do write some german documentation
- I'll help to fix some bug too
- I'll read the source and know more about php's internal structure to start/support 
developping


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

Re: [PHP-DEV] Bug count..

[Maxim Maletsky]

Can it be searchable extension-based and time-wise? That'd be kinda
useful.

-- 
Maxim Maletsky
[EMAIL PROTECTED]




Jani Taskinen <[EMAIL PROTECTED]> wrote... :

> 
> Here you can find nice curve of the bug count:
> 
>   http://www.php.net/~jani/count.png
> 
> The red curve is total amount of reports with these statuses:
> Open, Critical, Analyzed, Verified, Assigned and Feedback.
> 
> --Jani
> 
> 
> 
> -- 
> 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] Forked ext/gd by default

[Sander Steffann]

Hi,

> I think we should use forked version of gd library by default for 4.3.0.
> From what I hear it is already the best version of any of them out there
> and if it saves us any more grief, all the better. Objections?

Sounds wonderful!
+1 from me.

Sander.


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

RE: [PHP-DEV] Re: Forked ext/gd by default

[Mike Robinson]

Rasmus Lerdorf writes:

> Whoa, pigs are flying over the skating rink in hell.

Those aren't pigs. That's the Unisys Legal Department.
It's a common mistake. :)

Regards
Mike Robinson






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

[PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/xml/tests 007.phpt

[Michael Mauch]

I wrote about fun with locales, but forgot to mention the user notes at
. Some users note
that they have to use "Dutch" on their Windows (?) systems. So if we
really need the locale guessing, we probably should add "German" as
well (and hope that the locale string is not localized in some versions
of Windows).

Regards...
Michael

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

[PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/xml/tests 007.phpt

[Michael Mauch]

Derick Rethans <[EMAIL PROTECTED]> wrote:
> On Mon, 21 Oct 2002, Melvyn Sopacua wrote:
> 
>> msopacua  Mon Oct 21 04:55:07 2002 EDT
>> 
>>   Modified files:  
>> /php4/ext/xml/tests   007.phpt 
>>   Log:
>>   Skip this when strtoupper doesn't behave as expected, because casefolding
>>   depends on this.
> 
> erm, this is just a local problem. Just set the locale to "German" here 
> and it will work just fine I think. IMO this is a hack :)

The problem is that there are an awful lot of "German" locales.

Something like

  setlocale(LC_ALL,array('de_DE.ISO8859-1','de_DE.ISO8859-15',
 'de_DE@euro','de','de_DE'));

and some more variations with "-" or "_" after the "ISO", or even "DIS"
instead of "ISO", might work for most platforms that have a German
locale installed. But because some systems don't have a German locale at
all (IIRC on Debian you have to install your locales explicitly and run
locale-gen afterwards), "en_US" and it's variations might be more
promising:

foreach(array('','_','-') as $hyphen)
  foreach(array('ISO','DIS') as $ISODIS)
$locales[] = "en_US.${ISODIS}${hyphen}8859-1\n";
$locales[] = 'en_US@euro';
$locales[] = 'en_US';
$locales[] = 'en';
setlocale(LC_ALL,$locales);

Nice, isn't it?

There's a good page about that at
 (in English). There's also a
small C program called "checklocale".   

But even if we use such a locale guessing: it's not the fault of the XML
code if non-ASCII characters don't work. It might be a good idea to have
a seperate test case for strtoupper() etc., but for testing the XML
extension, I still think that's it's better to just bail out as soon as
we see that strtoupper() doesn't behave.

Maybe we should add

  setlocale(LC_ALL,'');

at the beginning of ext/xml/tests/007.phpt to make sure that the locale
settings of the environment are used (although here the values of the
environment are used even without that statement).

Regards...
Michael

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

[PHP-DEV] 4.2.3pre1

[Tony Bibbs]

All this on a Dell Inspiron 5000 running RH7.3.  I compiled PHP apache
module just fine.  Compiling it as a CGI I get:

gcc: sapi/cli/php_cli.o: No such file or directory
gcc: sapi/cli/getopt.o: No such file or directory

This a bug or did I miss something?

--Tony




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

Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/xml/tests 007.phpt

[Melvyn Sopacua]

[ Sorry Derick, missed a whole bunch of CVS mail, because of multiple spaces
  in the subject and my overeager filtering :) ]

At 23:58 21-10-2002, Michael Mauch wrote:


Derick Rethans <[EMAIL PROTECTED]> wrote:
> On Mon, 21 Oct 2002, Melvyn Sopacua wrote:
>
>> msopacua  Mon Oct 21 04:55:07 2002 EDT
>>
>>   Modified files:
>> /php4/ext/xml/tests   007.phpt
>>   Log:
>>   Skip this when strtoupper doesn't behave as expected, because 
casefolding
>>   depends on this.
>
> erm, this is just a local problem. Just set the locale to "German" here
> and it will work just fine I think. IMO this is a hack :)

The problem is that there are an awful lot of "German" locales.

While I agree, the only thing that should be needed is LC_CTYPE to ISO-8859-1,
which is somewhat managable (ISO8859=1 is the most portable I think?).

IIC - Michael is right that locale names are even less consistent, than a 
lawyer.

So you can either setlocale(LC_CTYPE, "some string") then test if it works, 
maybe
try again with "other string", but you can't grab'm all.

Apart from that:
[EMAIL PROTECTED] ~/cvs/php4
$ /php/bin/php -f ext/standard/tests/strings/strtoupper.phpt
--TEST--
Test strtoupper on non-ASCII characters
--POST--
--GET--
--FILE--
ÀËÏ--EXPECT--
ÄËÏ

[EMAIL PROTECTED] ~/cvs/php4
$ sapi/cli/php -f ext/standard/tests/strings/strtoupper.phpt
--TEST--
Test strtoupper on non-ASCII characters
--POST--
--GET--
--FILE--
àëï--EXPECT--
ÄËÏ

/php/bin/php is 4.2.3 so something has changed not for the better :(

Should I file a bugreport?



Met vriendelijke groeten / With kind regards,

Webmaster IDG.nl
Melvyn Sopacua


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

Re: [PHP-DEV] Idea to extend language: Explicitly setting variable scope inside user defined function (longer)

[Maxim Maletsky]

Marco Tabini <[EMAIL PROTECTED]> wrote... :

> Well, you have to admit that the issue of variable scope is the first
> thing that hits someone who approaches PHP for the first time and comes
> from other backgrounds, like C or ASP!

Or Ruby where instead of the dollar sign for the global variable you use at-mark :)

(The dollar sign is another scope, and C-like prefix-less vars are local :),
Correct me if I am wrong)

Well, in a way it is right to have this, but in a way it get things more
difficult for newbies to start. I prefer PHP handling variables the way
it does right now.  Maybe something like what is suggested can be
optional, but I don't think it is really doable as to be "an option".

-- 
Maxim Maletsky
[EMAIL PROTECTED]

www.PHPBeginner.com  // where PHP Begins


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

Re: [PHP-DEV] Work is beginning on cURL and PHP again

[Alan Knowles]

Non blocking connections would be nice...

- On the generating stuff - why do you want to generate the code on the 
users system? -
all the re2c stuff in CVS is 'pre-genereated'

It would be nice to have extension generator that could be built upon, 
that didnt involve re-reading all those perl/awk manuals, just to add 
features to it. :)
Any idea if  finding 'generic' bits in the php-gtk generator is possible?

Regards
Alan


Sterling Hughes wrote:

Hi,

I'm going to be working on updating the PHP cURL extension in the coming
weeks: 

* adding the multi-interface. 
* ssl session id caching (globally) 
* global dns cache in threaded webservers (same for ssl sesssion id
caching)
* allowing cURL handle re-use.
* allowing "persistent" cURL handles that survive the request, for HTTP
1.1 persistent connections
* Autogenerating much of the interface between cURL and PHP, allowing
PHP to support multiple versions of the underlying cURL library
* Supporting all cURL options/callbacks in one way or another
* Adding a OOP interface to cURL, on the extension level... [undecided]
* Updating the cURL documentation

So, I'm sending this message, to the lists just to get any suggestions,
comments, feature requests, bug reports that you would like me to look
at/consider when revamping the extension.  The changes will be done step
by step to the extension, but the full revamping should be expected
around the time of PHP 5 (PHP 4.3 is too soon for all these changes to
be integrated and tested).

-Sterling

PS: I'll be at the PHP Conference in Frankfurt, and ApacheCon in Las
Vegas, if you're coming to either of those, feel free to talk about it
with me there as well...

 




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

Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/mbstring/tests 027.inc027.phpt

[Yasuo Ohgaki]

Other option is create .php files from phpt file always.

It was useful when there is .php file is created when
error occurred. (Current run-tests.php does not create the
.php files, though)

If .php files is always created and left after running
run-tests.php, all needs are covered. It's a trivial change
to run-tests.php.

We may better to use some strange extension to avoid
unwanted over writes. .src may be a good choice.
Comments?

--
Yasuo Ohgaki


Moriyoshi Koizumi wrote:

echo "=0){\$f=\$argv[\$argc];echo \"\$f\n\";\
\$b=preg_replace(\
'/<\\?php\\s+include\\(\\s*[\"\\']([^\"\\']+)[\"\\']\\s*\\);\\s*\\?>/e',\
'file_get_contents(\"\$1\")',\file_get_contents(\$f));\
\$p=fopen(\$f,'w');fwrite(\$p,\$b);fclose(\$p);}?>" \
| sapi/cli/php -- ext/mbstring/tests/*.phpt



done (a bit dirty).


Moriyoshi


Moriyoshi Koizumi <[EMAIL PROTECTED]> wrote:



Hi,

I'm for Derick's option. Can I begin repacking each case to the single 
files now?


Moriyoshi

Yasuo Ohgaki <[EMAIL PROTECTED]> wrote:


Derick Rethans wrote:


Yes, works fine here:

(even with * instead of 025.*)


Thing has been changed ;)
I hope it's documented somewhere.

--
Yasuo Ohgaki



--
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] Work is beginning on cURL and PHP again

[Sterling Hughes]

On Tue, 2002-10-22 at 01:38, Alan Knowles wrote:
> Non blocking connections would be nice...
> 
> - On the generating stuff - why do you want to generate the code on the 
> users system? -
> all the re2c stuff in CVS is 'pre-genereated'
> 
> It would be nice to have extension generator that could be built upon, 
> that didnt involve re-reading all those perl/awk manuals, just to add 
> features to it. :)
> Any idea if  finding 'generic' bits in the php-gtk generator is possible?
> 
Well, the reason for the generator, is it will build an extension that
mimics the current version of cURL installed which will allow the cURL
extension to support multiple versions of the library without a lot of
maintanence and stuff :)

-Sterling


> Regards
> Alan
> 
> 
> Sterling Hughes wrote:
> 
> >Hi,
> >
> >I'm going to be working on updating the PHP cURL extension in the coming
> >weeks: 
> >
> >* adding the multi-interface. 
> >* ssl session id caching (globally) 
> >* global dns cache in threaded webservers (same for ssl sesssion id
> >caching)
> >* allowing cURL handle re-use.
> >* allowing "persistent" cURL handles that survive the request, for HTTP
> >1.1 persistent connections
> >* Autogenerating much of the interface between cURL and PHP, allowing
> >PHP to support multiple versions of the underlying cURL library
> >* Supporting all cURL options/callbacks in one way or another
> >* Adding a OOP interface to cURL, on the extension level... [undecided]
> >* Updating the cURL documentation
> >
> >So, I'm sending this message, to the lists just to get any suggestions,
> >comments, feature requests, bug reports that you would like me to look
> >at/consider when revamping the extension.  The changes will be done step
> >by step to the extension, but the full revamping should be expected
> >around the time of PHP 5 (PHP 4.3 is too soon for all these changes to
> >be integrated and tested).
> >
> >-Sterling
> >
> >PS: I'll be at the PHP Conference in Frankfurt, and ApacheCon in Las
> >Vegas, if you're coming to either of those, feel free to talk about it
> >with me there as well...
> >
> >  
> >
> 
> 
-- 
Sterling Hughes <[EMAIL PROTECTED]>
Did I help you? Consider a gift: http://wishlist.edwardbear.org/

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

Re: [PHP-DEV] Bug count..

[Jani Taskinen]

On Mon, 21 Oct 2002, Maxim Maletsky wrote:

>Can it be searchable extension-based and time-wise? That'd be kinda
>useful.

Heh..just take a look in the database for bugs and them tell me
how to get that data out of it. :)

--Jani



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

Re: [PHP-DEV] Re: Bug count..

[Jani Taskinen]

On Mon, 21 Oct 2002, Tom Sommer wrote:

>Jani Taskinen wrote:
>> Here you can find nice curve of the bug count:
>> 
>>   http://www.php.net/~jani/count.png
>
>If this realtime?

No. Updated once per day.

--Jani



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

Re: [PHP-DEV] Work is beginning on cURL and PHP again

[Shane Caraveo]

Sterling Hughes wrote:

On Tue, 2002-10-22 at 01:38, Alan Knowles wrote:


Non blocking connections would be nice...

- On the generating stuff - why do you want to generate the code on the 
users system? -
all the re2c stuff in CVS is 'pre-genereated'

It would be nice to have extension generator that could be built upon, 
that didnt involve re-reading all those perl/awk manuals, just to add 
features to it. :)
Any idea if  finding 'generic' bits in the php-gtk generator is possible?


Well, the reason for the generator, is it will build an extension that
mimics the current version of cURL installed which will allow the cURL
extension to support multiple versions of the library without a lot of
maintanence and stuff :)

-Sterling


Actually, the pre-generated stuff should be done, it will make windows 
life easier.

Shane


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

RE: [PHP-DEV] Bug count..

[Mike Robinson]

Jani Taskinen wrote:
> 
> Heh..just take a look in the database for bugs and them tell me
> how to get that data out of it. :)

SQL should do the trick.
:)

Regards
Mike Robinson

(Sorry, couldn't resist...)



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

RE: [PHP-DEV] Bug count..

[Jani Taskinen]

On Mon, 21 Oct 2002, Mike Robinson wrote:

>Jani Taskinen wrote:
>> 
>> Heh..just take a look in the database for bugs and them tell me
>> how to get that data out of it. :)
>
>SQL should do the trick.
>:)

Wise-ass.. :) I did mean that there is no such data in the
database which could be used for this..

--Jani



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

Re: [PHP-DEV] Bug count..

[Maxim Maletsky]

The very same way i supposed you got that very data :)
Since you were on that, i thought you could make it a little
kinda-searchanble.


-- 
Maxim Maletsky
[EMAIL PROTECTED]


On Tue, 22 Oct 2002 03:20:21 +0300 (EEST) Jani Taskinen <[EMAIL PROTECTED]> wrote:

> On Mon, 21 Oct 2002, Maxim Maletsky wrote:
> 
> >Can it be searchable extension-based and time-wise? That'd be kinda
> >useful.
> 
> Heh..just take a look in the database for bugs and them tell me
> how to get that data out of it. :)
> 
> --Jani
> 
> 


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

Re: [PHP-DEV] Bug count..

[Maxim Maletsky]

You're on!

How do you get onto /~jani/ ? If have a section there i could do some
staff too :)

-- 
Maxim Maletsky
[EMAIL PROTECTED]


On Mon, 21 Oct 2002 20:33:25 -0400 "Mike Robinson" <[EMAIL PROTECTED]> wrote:

> Jani Taskinen wrote:
> > 
> > Heh..just take a look in the database for bugs and them tell me
> > how to get that data out of it. :)
> 
> SQL should do the trick.
> :)
> 
> Regards
> Mike Robinson
> 
> (Sorry, couldn't resist...)
> 
> 


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

Re: [PHP-DEV] Bug count..

[Maxim Maletsky]

There must be such data, just, in fact, make a grouped query and you're
in. As long as you have an access to it.

But, seriously, guys, wouldn't be nice having a little summary for bugs
to add? A few years ago i remember having something like that on. Now
there only is listing left of opened/closed ones.

-- 
Maxim Maletsky
[EMAIL PROTECTED]


On Tue, 22 Oct 2002 03:35:43 +0300 (EEST) Jani Taskinen <[EMAIL PROTECTED]> wrote:

> On Mon, 21 Oct 2002, Mike Robinson wrote:
> 
> >Jani Taskinen wrote:
> >> 
> >> Heh..just take a look in the database for bugs and them tell me
> >> how to get that data out of it. :)
> >
> >SQL should do the trick.
> >:)
> 
> Wise-ass.. :) I did mean that there is no such data in the
> database which could be used for this..
> 
> --Jani
> 
> 
> 
> -- 
> 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] Idea to extend language: Explicitly setting variable scope inside user defined function (longer)

[Hans Zaunere]

--- Marco Tabini <[EMAIL PROTECTED]> wrote:
> Well, you have to admit that the issue of variable scope is the first
> thing that hits someone who approaches PHP for the first time and
> comes from other backgrounds, like C or ASP!
> 
> Still, after one adapts to this apparent "weirdness" of scoping, it
> tends to grow on you. I find that no scope inheritance gives me one
> less thing to worry about when writing code...

While some of the scoping tricks proposed seem like potential overkill,
I've yearned for a way to explicitly declare a variable a
"super-global".  Sure, I can stick it in one of the predefined
super-globals, but that just seems wrong.

Something like: 

super $avar;

would be very useful for large projects and wouldn't cause a lot of
harm otherwise.

Hans


> 
> 
> Marco
> 
> On Sun, 2002-10-20 at 22:41, Rasmus Lerdorf wrote:
> > How in the world do you know that "code will run faster" ?
> > 
> > Implementing your suggestion would take quite a lot of changes to
> the
> > internals of PHP.  Instead of just a global and a current symbol
> table, we
> > would now need basically an unlimited number of symbol tables and
> every
> > variable lookup would become more complex.  Ergo it would slow
> things
> > down.
> > 
> > -Rasmus
> > 
> > On Mon, 21 Oct 2002, NTPT wrote:
> > 
> > > Hi.
> > > I have some idea and suggestion  how to extend PHP language a bit
> in some
> > > way. That may probably lead to increasing of php flexibility,
> allow more
> > > modular coding to be done etc
> > >
> > >
> > > My sugestion is simple:
> > > Allow  PHP programmer to explicitelly  told , WHAT variable scope
> will be
> > > used  inside user defined  functions.
> > >
> > > In the traditional approach (afaik , i use php 4.2.2 ), as is
> described in
> > > the manual of php there a diferent varable scopes for each
> functions , only
> > > syntax " global $valuename" ; can lead to use variables global.
> This aproach
> > > is traditional and well known and is sufficient for most tasks.(I
> say
> > > sufficient, not effective...). My idea is going a bit behind it.
> > >
> > > I suggest  to introduce new keyword(s) or function(s)  into the
> PHP language
> > > definiton
> > > (i suggest syntax like  "var_scope scope" or  var_scope("scope")
> )
> > >
> > > That keywords SHOULD be used in user defined  functions to 
> EXPLICITLY
> > > define, WHAT kind of variable scope will be used inside this
> function.
> > >
> > > scope can be either
> > >
> > > 'local' = it means, that all variables used in this function 
> have a local
> > > scope only.(it means like traditional behavior of php and its
> variable
> > > scopes until now )
> > >
> > > 'global' = each variable used in the function  is from global
> scope. Similar
> > > to "global $variable_1,$variable_2... $each variable used
> in the
> > > main execution line of the script"
> > >
> > > 'caller' or 'inherit' This is MOST USEFUL part of the idea .
> Function
> > > variable scope is the SAME as from where the function was called.
> (if
> > > functino bar(),with have var_scope set to 'caller', is called
> from function
> > > foo() it have the same variable scope as function foo(), almost
> like the
> > > code of function bar() was included (by include "something" )
> somewhere
> > > inside foo() )
> > >
> > >
> > > A little example code for demonstrating idea of the syntax and
> how it should
> > > work:
> > > */
> > >  > >
> > > $a=10;
> > >
> > > echo "Varaible $a".$a;
> > > .
> > > $foo_output =foo();
> > > echo "value returnded by foo() ".$foooutput;
> > > echo "value $a after  calling  foo() but before calling bar()
> ".$a;
> > >
> > > $bar_output=bar();
> > > echo "value returnded by bar() ".$bar_output;
> > > .
> > > .
> > > echo "value $a after  calling  bar() ".$a;
> > >
> > > function foo()
> > >  {
> > >  $a=20;
> > >  echo "$a inside function foo() = ".$a
> > >  /* $bar_inside foo = bar();
> > >  echo "Variable $a inside function foo() after calling bar()".$a;
> > >
> > >  */
> > >  .
> > >  .
> > >
> > >  return $a;
> > >
> > >  }
> > >
> > >
> > > function bar()
> > >  {
> > >  var_scope caller // we have the SAME variable scope  as from
> where we are
> > > called
> > >  $a=100;
> > >  .
> > >  .
> > >  .
> > >  return $a;
> > >  }
> > > ?>
> > > this should return :  (with comments behind // )
> > >
> > > Varaible $a" 10
> > > $a inside function foo() = 20
> > > value returnded by foo() 20
> > > value $a after  calling  foo() but before calling bar() 10
> > > value returnded by bar() 100
> > > value $a after  calling  bar() 100  //  var_scope is set to
> 'caller', so $a
> > > in global scope is modified inside bar() the some way, as if
> global $a was
> > > used )
> > >
> > > if you uncomment lines in  bar()
> > >
> > > Varaible $a" 10
> > > $a inside function foo() = 20
> > > Variable $a inside function foo() after calling bar() 100  //
> var_scope in
> > > function bar() is set to caller, so $a IN SCOPE of foo() ONLY  is
> modified
> 

Re: [PHP-DEV] Idea to extend language: Explicitly setting variablescope inside user defined function (longer)

[Marco Tabini]

Personally, I think that variable scope handling works great the way it
is--particularly if you turn on error reporting. This way you have to
explicitly declare that you will be accessing a global variable and
don't run the risk of messing things up without thinking about it.

You could argue that a bit of discipline could solve this problem--but
then again a bit of discipline also makes you use the scoping the way it
is and come away clean without any major problems!

--Mt.

On Mon, 2002-10-21 at 21:19, Hans Zaunere wrote:
> 
> --- Marco Tabini <[EMAIL PROTECTED]> wrote:
> > Well, you have to admit that the issue of variable scope is the first
> > thing that hits someone who approaches PHP for the first time and
> > comes from other backgrounds, like C or ASP!
> > 
> > Still, after one adapts to this apparent "weirdness" of scoping, it
> > tends to grow on you. I find that no scope inheritance gives me one
> > less thing to worry about when writing code...
> 
> While some of the scoping tricks proposed seem like potential overkill,
> I've yearned for a way to explicitly declare a variable a
> "super-global".  Sure, I can stick it in one of the predefined
> super-globals, but that just seems wrong.
> 
> Something like: 
> 
> super $avar;
> 
> would be very useful for large projects and wouldn't cause a lot of
> harm otherwise.
> 
> Hans
> 
> 
> > 
> > 
> > Marco
> > 
> > On Sun, 2002-10-20 at 22:41, Rasmus Lerdorf wrote:
> > > How in the world do you know that "code will run faster" ?
> > > 
> > > Implementing your suggestion would take quite a lot of changes to
> > the
> > > internals of PHP.  Instead of just a global and a current symbol
> > table, we
> > > would now need basically an unlimited number of symbol tables and
> > every
> > > variable lookup would become more complex.  Ergo it would slow
> > things
> > > down.
> > > 
> > > -Rasmus
> > > 
> > > On Mon, 21 Oct 2002, NTPT wrote:
> > > 
> > > > Hi.
> > > > I have some idea and suggestion  how to extend PHP language a bit
> > in some
> > > > way. That may probably lead to increasing of php flexibility,
> > allow more
> > > > modular coding to be done etc
> > > >
> > > >
> > > > My sugestion is simple:
> > > > Allow  PHP programmer to explicitelly  told , WHAT variable scope
> > will be
> > > > used  inside user defined  functions.
> > > >
> > > > In the traditional approach (afaik , i use php 4.2.2 ), as is
> > described in
> > > > the manual of php there a diferent varable scopes for each
> > functions , only
> > > > syntax " global $valuename" ; can lead to use variables global.
> > This aproach
> > > > is traditional and well known and is sufficient for most tasks.(I
> > say
> > > > sufficient, not effective...). My idea is going a bit behind it.
> > > >
> > > > I suggest  to introduce new keyword(s) or function(s)  into the
> > PHP language
> > > > definiton
> > > > (i suggest syntax like  "var_scope scope" or  var_scope("scope")
> > )
> > > >
> > > > That keywords SHOULD be used in user defined  functions to 
> > EXPLICITLY
> > > > define, WHAT kind of variable scope will be used inside this
> > function.
> > > >
> > > > scope can be either
> > > >
> > > > 'local' = it means, that all variables used in this function 
> > have a local
> > > > scope only.(it means like traditional behavior of php and its
> > variable
> > > > scopes until now )
> > > >
> > > > 'global' = each variable used in the function  is from global
> > scope. Similar
> > > > to "global $variable_1,$variable_2... $each variable used
> > in the
> > > > main execution line of the script"
> > > >
> > > > 'caller' or 'inherit' This is MOST USEFUL part of the idea .
> > Function
> > > > variable scope is the SAME as from where the function was called.
> > (if
> > > > functino bar(),with have var_scope set to 'caller', is called
> > from function
> > > > foo() it have the same variable scope as function foo(), almost
> > like the
> > > > code of function bar() was included (by include "something" )
> > somewhere
> > > > inside foo() )
> > > >
> > > >
> > > > A little example code for demonstrating idea of the syntax and
> > how it should
> > > > work:
> > > > */
> > > >  > > >
> > > > $a=10;
> > > >
> > > > echo "Varaible $a".$a;
> > > > .
> > > > $foo_output =foo();
> > > > echo "value returnded by foo() ".$foooutput;
> > > > echo "value $a after  calling  foo() but before calling bar()
> > ".$a;
> > > >
> > > > $bar_output=bar();
> > > > echo "value returnded by bar() ".$bar_output;
> > > > .
> > > > .
> > > > echo "value $a after  calling  bar() ".$a;
> > > >
> > > > function foo()
> > > >  {
> > > >  $a=20;
> > > >  echo "$a inside function foo() = ".$a
> > > >  /* $bar_inside foo = bar();
> > > >  echo "Variable $a inside function foo() after calling bar()".$a;
> > > >
> > > >  */
> > > >  .
> > > >  .
> > > >
> > > >  return $a;
> > > >
> > > >  }
> > > >
> > > >
> > > > function bar()
> > > >  {
> > > >  var_scope caller // we have the SAME variable scope  as f

[PHP-DEV] inplicit_flush off

[Yasuo Ohgaki]

CLI should behave like other *modern* scripting
(Blanguage. i.e. behave like perl, ruby, python.
(B
(BCurrently it behaves like sh.
(Bi.e. flushing stdout for every output.
(B
(BComments?
(B
(B--- php_cli.c.~1.37.~   Wed Oct 16 06:17:34 2002
(B+++ php_cli.c   Tue Oct 22 11:45:09 2002
(B@@ -466,7 +466,6 @@
(BSG(options) |= SAPI_OPTION_NO_CHDIR;
(Bzend_alter_ini_entry("register_argc_argv", 19, "1", 1, PHP_INI_SYSTEM, 
(BPHP_INI_STAGE_ACTIVATE);
(Bzend_alter_ini_entry("html_errors", 12, "0", 1, PHP_INI_SYSTEM, 
(BPHP_INI_STAGE_ACTIVATE);
(B-   zend_alter_ini_entry("implicit_flush", 15, "1", 1, PHP_INI_SYSTEM, 
(BPHP_INI_STAGE_ACTIVATE);
(Bzend_alter_ini_entry("max_execution_time", 19, "0", 1, PHP_INI_SYSTEM, 
(BPHP_INI_STAGE_ACTIVATE);
(B
(Bzend_uv.html_errors = 0; /* tell the engine we're in non-html mode */
(B
(B
(B--
(BYasuo Ohgaki
(B
(B
(B-- 
(BPHP Development Mailing List 
(BTo unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] short_open_tag

[Terence Kearns]

OK, after having read the threads, I know I'm gonna get blasted/flamed, 
but I have to say this cos I've spent a lot of time trying to develop 
"elegent" XML based solutions in PHP and this issue kills it for me 
every time. So let me appologise in advance, BUT...

Speaking on v5, not only should support short tags be off by default, it 
should be completely abandoned

We can't make up for the past in this version because it will break a 
lot of exisitng PHP scripts, but with version 5, ***most scripts will 
have to be ported or patched anyway*** to run on v5. This being the 
case, it won't be difficult for the developers to replace /<\? */ with 
"

I can fully understand all the issues to do with the current v4 and 
prior - particularly ISP issues - but since v5 is a whole new kettle of 
fish, then there is no excuse - particularly since badly written (short 
tag) scripts can be *easily* fixed with a recursive search/replace 
operation.

v5 should be looking after future trends - this means full XML support!
v5 should not be backwards looking!

having to do things like

my_custom_insert_XMLdeclaration(); // *+ see fottnote
my_custom_insert_XML_PI($name,$content);
?>
is bullshit!!!

Notice that I also have to make sure that there is no whitespace between 
the beginning of the file and this opening PHP block because the XML 
spec requires the declaration to be on the first line with no preceeding 
space!!!

My point is, that this is not about "convenience" for XML developers, 
***it's about supporting standards*** - in this case XML - since that's 
where the future is.

come on, lets move with the times here.

I mean no disrespect to anyone (especially Andi and Zeev who seem to 
disagree), but this is my feeling on the matter and I feel strongly 
compelled to express it.

kind regards,
Terence.


*+ and then inside these fuinctions you have to make sure that you use 
single quotes to output the string 




PS. just another example (although not the main issue).
you can do nice things like





...


Now this file can be processed as a normal file but anyone trying to 
pull it directly through the URL will get access denied (or some other 
custom response). This is a good example of how beautiful and elegent 
things *could* be - since PHP is a processor and it makes sense that 



PSS. The reason this keeps coming up again and again and again is 
because it has not been resolved.
V5 is a chance to resolve it. Otherwise, we can all look forward to it 
raising it's ugly head again.
 and again, and again, and again .



Evan Nemerson wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Just a thought, but I think short_open_tag should be Off by default in 
php.ini-dist, to prevent PHP from being confused with XML declarations. I 
know XML declarations aren't required (yet) by w3c, but "XHTML document 
authors are strongly encouraged to use XML declarations in all their 
documents." [http://www.w3.org/TR/xhtml11/conformance.html#s_conform]

I rarely see them in the wild, so I don't think there would be _too_ much of a 
problem with backwards-compatibility... certianly no worse than the 
register_globals fiasco (although it was the right decision).

I'll try to follow this in the archive, but I don't subscribe to this list, so 
if you could CC replies, I'd be grateful.

- -Evan Nemerson
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQE9qn9W/rncFku1MdIRAhmfAJ9cnzvZk2MIinNXC6z1sNNa3hIo6gCfRilp
QQ2/fCIQ3cW6RY/ZiVeC4o8=
=x9Ig
-END PGP SIGNATURE-


 



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

Re: [PHP-DEV] Work is beginning on cURL and PHP again

[Andi Gutmans]

At 01:54 AM 10/22/2002 +0200, Sterling Hughes wrote:

On Tue, 2002-10-22 at 01:38, Alan Knowles wrote:
> Non blocking connections would be nice...
>
> - On the generating stuff - why do you want to generate the code on the
> users system? -
> all the re2c stuff in CVS is 'pre-genereated'
>
> It would be nice to have extension generator that could be built upon,
> that didnt involve re-reading all those perl/awk manuals, just to add
> features to it. :)
> Any idea if  finding 'generic' bits in the php-gtk generator is possible?
>
Well, the reason for the generator, is it will build an extension that
mimics the current version of cURL installed which will allow the cURL
extension to support multiple versions of the library without a lot of
maintanence and stuff :)


Don't forget Windows. No idea how you'll handle that.

Andi


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

Re: [PHP-DEV] short_open_tag

[Terence Kearns]

Zeev Suraski wrote:



No, we shouldn't have.  It is not a deprecated feature or a 
discouraged feature.  If you use the *FAIRLY RARE* combination of 
using PHP to generate XML, you'd have to configure your PHP.  If 
you're with the vast majority of the population and couldn't care less 
about writing XML-embedded scripts, you enjoy a working short tag.

Zeev

OK, maybe *now* it is realatively rare, but what about in the [not too 
distant] future when v5 is widely adopted?
Don't forget that XHTML is also XML!
and surely web developers are moving at least that much (away from 
not-well-formed HTML).


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

Re: [PHP-DEV] short_open_tag & ini_set()

[Terence Kearns]

Yes, but this doesn't solve the problem of whitespace before the 
declaration.

the XML spec says that the declaration has to appear on the first line 
with no whitespace before it.

developers will wonder why XML parsers don't accept their PHP script if 
they accidently put whitespace before 

This seems to be one of the key issues that people seem to be glossing over!


Richard Heyes wrote:

Since there are no drawbacks at all to the 
does cover a great deal of the problem (taking into account the very
limited scope of the problem), I don't see a good reason not to add
it.  Rasmus put it very well in one of his recent letters - PHP is not a
purists' language, complex problem sometimes require 'ugly' solutions...
   


Something else to aid the writing of portable scripts is to allow the
setting
of short_open_tag from the script with ini_set(), for either subsequent
code,
or subsequently included files.

--
Richard Heyes
V-webmail - http://www.v-webmail.co.uk


 



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

Re: [PHP-DEV] short_open_tag

[Terence Kearns]

Yasuo Ohgaki wrote:



I see side effect of 
IMHO, language that supposed to process XML document 

I think there is some sort of assumption by others that HTML is the only 
thing we need to worry about. I suspect the importance of XML compliance 
would be weighed up differently if people believed that PHP will be 
widely used for XML application in the future - particularly with version 5.

Before we have a discussion about short tage removal - "good or bad". We 
need to provide some context for the discussion.
For me, the context is "near future" and version 5.


--
Yasuo Ohgaki





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

Re: [PHP-DEV] short_open_tag

[Andi Gutmans]

I don't get this. Are people replying to you directly and you're cc'ing to 
the list? Because I only see your answers and not their replies.

Andi

At 03:30 PM 10/22/2002 +1000, Terence Kearns wrote:


Yasuo Ohgaki wrote:



I see side effect of 

I think there is some sort of assumption by others that HTML is the only 
thing we need to worry about. I suspect the importance of XML compliance 
would be weighed up differently if people believed that PHP will be widely 
used for XML application in the future - particularly with version 5.

Before we have a discussion about short tage removal - "good or bad". We 
need to provide some context for the discussion.
For me, the context is "near future" and version 5.


--
Yasuo Ohgaki




--
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] short_open_tag

[Terence Kearns]

Agreed.

If short tags were disabled in v5, then there would be no such need for 
a hack like this.

Andi Gutmans wrote:

This is definitely one thing to think about. This is exactly the 
reason why I was against in the beginning. I had a feeling such 
ambiguities could arise.

Andi

At 09:43 AM 10/17/2002 -0700, Rasmus Lerdorf wrote:

My main worry with such a hack would be breaking a script like this:

  
function xml() {
echo "Hello World";
}
  ?>
  ...
  
  ...

Now, people generally don't put spaces between the function name and the
(), but it is a BC concern since the above script works just fine today.

One idea would be to only strip 
tag.  That should cover most cases, but it may be a bit too magical.

-Rasmus

On Thu, 17 Oct 2002, Andrei Zmievski wrote:

> They are _not_ the same person!
>
> On Thu, 17 Oct 2002, Zeev Suraski wrote:
> > Well, I differ with you on that.  I don't think there's anything 
in the
> > same class as 
> >
> > Zeev
> >
> > At 18:08 17/10/2002, Andi Gutmans wrote:
> > >I don't think we should add special hacks to the scanner. Soon 
we're going
> > >to have a zillion hacks for other XML/SGML/foobar documents.
> > >
> > >Andi
> > >
> > >At 12:17 PM 10/16/2002 -0400, Ilia A. wrote:
> > >>Since the general consensus by the developers is not to remove the
> > >>short_tags
> > >>or even disable them. Perhaps we should consider alternate 
solutions to
> > >>this
> > >>problem. Given the buzzword popularity of XML and its slowly 
growing
> > >>popularity among website designers (XHTML) this issue is likely 
to come
> > >>up in
> > >>the future yet again.
> > >>The solution I would like to offer, is a patch that adds 
special handling
> > >>for
> > >>
> > >>inside 
> > >>
> > >>Ilia
> >
> >
> > --
> > PHP Development Mailing List 
> > To unsubscribe, visit: http://www.php.net/unsub.php
>
>
>
> -Andrei   
http://www.gravitonic.com/
>
> "Claiming Java is easier than C++ is like
>  saying that K2 is shorter than Everest."
>  -- Larry O'Brien (editor, Software Development)
>
> --
> 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] short_open_tag

[Andi Gutmans]

At 03:33 PM 10/22/2002 +1000, Terence Kearns wrote:

Agreed.

If short tags were disabled in v5, then there would be no such need for a 
hack like this.

They won't be disabled.
They won't be disabled.
They won't be disabled.
They won't be disabled.
They won't be disabled.
They won't be disabled.
They won't be disabled.
They won't be disabled.

Andi


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

Re: [PHP-DEV] short_open_tag

[Terence Kearns]

Dan Hardiker wrote:


Thousands of programmers use short tags in their scripts, but only
hundreds can't change this setting in php.ini manually.
   

M> Wrong... Many webhosting companies won't allow customers to change
M> php.ini, and my experiences with php_set_ini() aren't too good.

yep, many of hostings don't allow this.
but in 99% XML on such hostings is not allowed too.

I think you shouldn't do the wrong thing if someone does...
   


Your missing the point of my suggestion. Im not suggesting we switch it
off by default, Im suggesting we *remove* the feature.

As the XML community expands and more and more scripting languages (server
and client side) are being designed to interoperate, cross-language
compatability (or at least handling) is required.

The short tag 
and its my recommendation that (in version 5 of the product) the sort tag
option is removed.

Yes - this will break *alot* of sloppy scripts (including scripts taking
the short cut 
sh/sed/awk script could be written that scans a directory tree and
converts all .php files to .php5 files.

Note: this script could also check for other cross version problems that
may arrise.

My *key* point is that come the upgrade jump from v4 to v5 people will
*expect* major differences - otherwise it would just be another step in
the v4 tree. Major upgrades are one of the few times you can make major
modifications to the structure of a system without users whinging.

I am still -1 on anything being changed for v4 in respect to short tags,
but +1 on as much as possible being done in v5 to eradicate short tags.

 



spoken like a person who has actually done some work with XML using PHP.

Terence.


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

Re: [PHP-DEV] short_open_tag

[Brad LaFountain]

It would be very bad for php if short tags were disabled.
I 100% agree with andi. There are ways of dealing with xml and php
without pissing off the WHOLE php user world. I don't even use
long tags EVER, nor will I want to start.
 - Brad
--- Andi Gutmans <[EMAIL PROTECTED]> wrote:
> At 03:33 PM 10/22/2002 +1000, Terence Kearns wrote:
> >Agreed.
> >
> >If short tags were disabled in v5, then there would be no such need for a 
> >hack like this.
> 
> They won't be disabled.
> They won't be disabled.
> They won't be disabled.
> They won't be disabled.
> They won't be disabled.
> They won't be disabled.
> They won't be disabled.
> They won't be disabled.
> 
> Andi
> 
> 
> -- 
> PHP Development Mailing List 
> To unsubscribe, visit: http://www.php.net/unsub.php
> 


__
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

Re: [PHP-DEV] short_open_tag

[Shane Caraveo]

Brad LaFountain wrote:

It would be very bad for php if short tags were disabled.
I 100% agree with andi. There are ways of dealing with xml and php
without pissing off the WHOLE php user world. I don't even use
long tags EVER, nor will I want to start.
 - Brad


Damn, that comes from a SOAP developer too ;)  Just wait till he starts 
embeding php in xsl :)

Shane


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

Re: [PHP-DEV] Global HashTables & access violations

[Tony Leake]

On Mon, 2002-10-21 at 20:19, Brian 'Bex' Huff wrote:

> Ive written an extension to PHP that (among other things) uses a global 
> HashTable object for a mini cache.  I fill it, and then have a simple 
> PHP function to pull a string out of the cache, and return it.  However, 
> I keep getting wierd internal access violations whenever I try to use it.
> 
Hi Brian,

I can't help with your specific problems but there are a couple of
shortcuts you can use in your module. 

You can get the string length of your arguments as they are passes in,
see below.

Also there are macros for returning values which I believe are the
preferred way of doing things. I have made the change in your code below
to show how to get the string length passed in.

you have 2 functions for returning strings :
RETURN_STRING(char *s, int dup) 
and 
RETURN_STRINGL(char *s, int l, int dup) if you know the length of the
string.
int dup, should be 1 unless you estrdup or emalloc the string.

these 2 functions seem to have aliases RETVAL_STRING and RETVAL_STRINGL
I'm not sure which version is preferred.

see for further info
http://zend.com/apidoc/zend.returning.php


HTH
Tony


> PHP_FUNCTION(idc_env)
> {
>HashTable *env = IDC_G(server_environment);
>zval **value = NULL;
>char *valueStr = NULL;
>int argc = ZEND_NUM_ARGS();
>char *name = NULL;
 /* NEW LINE, and line below modified */
 long name_length; 
>if (zend_parse_parameters(argc TSRMLS_CC, "s", &name, &name_length) == FAILURE)
>  return;
> 
>if (zend_hash_find(env, name, strlen(name) + 1,
>   (void **) &value) == SUCCESS)
>{
>  if ((*value)->type == IS_STRING)
>  {
>valueStr = Z_STRVAL_PP(value);
>return_value->type = IS_STRING;
>return_value->value.str.len = Z_STRLEN_PP(value);
>return_value->value.str.val = estrdup(valueStr);
 
/* previous 3 lines can be replaced with */
RETURN_STRINGL(valueStr, Z_STRLEN_PP(value), 1 );
>  }
>}
> }
> 



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

Re: [PHP-DEV] short_open_tag

[Terence Kearns]

Rick Widmer wrote:





I fail to see how using 
plan on distributing your code to the masses or mixing XML/XHTML without
trivially escaping it, I see absolutely no point in using 

In reality, very few people intermix PHP and XML.  It just doesn't 
make a
whole lot of sense to do so.  People tend to keep the two separate and
parse the XML from PHP.

In the XHTML case, a lot of people mistakenly believe that they must 
start
their documents with an  tag, which if you read the
XHTML spec, is actually not necessary. The only use for the XML encoding
tag is for XML parsers to get the right character encoding. Browsers,
which are typically the target of PHP generated pages, get their 
character
encoding from the Content-type header, or optionally from a similar meta
tag. But even if you choose to put in the XML encoding tag, I find it a
hell of a lot easier to just put '?> at
the top instead of changing hundreds of 

PHP became popular because it eliminated most of the tediousness of
writing CGI scripts or low-level Apache modules.  If we slowly but 
surely
eliminate all the convenience aspects of PHP we are going to turn the
experience back into one of tedium again.


I agree with you on the simplicity thing but I guess you've never tried 
writing an XML script in PHP. It is more complicated than it needs to be.



PHP is not a pure language.  It never will be.  The problem it solves is
ugly.  Ugly problems often require ugly solutions.  Solving an ugly
problem in a pure manner is bloody hard.  PHP's aim is to make 
solving the
web problem easy.  Ergo, therefore, Q.E.D, removing all the "ugly"
features of PHP is going to make it harder and harder to use PHP to 
solve
the web problem.


There seems to be a very common thread here. People who are kicking and 
screeming about making PHP XML-compliant are not the least bit 
interested at entertaining the idea that XML may become popular amoungst 
PHP application developers in the not too distant future (aka, version 
5). This, dispite all the wonderful work that has gone into plugins such 
as Sablotron, expat, and DOM xml.

I suppose that most of the experienced people amoung us have been doing 
PHP development for a while now so most of that work would be in HTML 
(where standards have been largely unsuccessful). To that end we come 
away content with what we have (nice comfort zone) and reluctant to 
change. We also come away with a healthy skepticism of standards and a 
deep belief that web standards will always be futile.

I would hate to see PHP's simple but awsome application producing 
capability essentially *crippled* (or at least stifled) when XML becomes 
the norm because inter-application functionality (such as SOAP for only 
*one* example) is essential as the web landscape evolves.

So if standards are the "baby" and the extra 3 charactes are the "bath 
water", then lets not throw the baby out with the bath water because 
we've been jaded by past experiences with failed standards implementation.

And if we do ignore this issue, it *will* return and with more and more 
frequency as PHP enthusiasts embrace a new way of encapsulating and 
exchanging their data. Maybe the reason that this issue will not go away 
is because PHP has a bug in it which is called "short_open_tag". THIS 
ISSUE IS NOT GOING TO GO AWAY if this bug is not squished. To pretend 
that it will is sheer ignorance.

Please, people, when all of you make your comments, please considder 
what will be thought of them in 2 years time.

kind regards,
Terence.











Rick





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