Re: [PHP-DEV] Re: [PHP-DOC] streams reference

[Derick Rethans]

On Thu, 2 Jan 2003, Sara Golemon wrote:

> > Is there a function to get this specific information?  Would
> > that be useful?  Maybe something like get_registered_streams().
> >
> That does sound like it'd be useful... Unfortunately there isn't a
> userland function for that.  There *IS* however, a PHPAPI call for it:
> 
> PHPAPI HashTable *php_stream_get_url_stream_wrappers_hash();
> 
> It wouldn't take much to make a userland wrapper for it since it already
> returns a hash table...
> 
> stream_get_wrappers();  sounds like an appropriate name

right, sounds wonderful :)

Derick

-- 

-
 Derick Rethans http://derickrethans.nl/ 
 PHP Magazine - PHP Magazine for Professionals   http://php-mag.net/
-


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

[PHP-DEV] Re: [PHP-DOC] streams reference

[Sara Golemon]

>--Cross-Post from php-doc discussion thread--
>
> You may want to mention what the following means, this is
> from a phpinfo() on www.php.net:
>
> Registered PHP Streams: http
> php
> ftp
> https
> compress.zlib
>
I mention using phpinfo() to see what wrappers are available, but not
detail on all the builtin streams.  I've got references (w/ links) to
Apendix I for that.

> Is there a function to get this specific information?  Would
> that be useful?  Maybe something like get_registered_streams().
>
That does sound like it'd be useful... Unfortunately there isn't a
userland function for that.  There *IS* however, a PHPAPI call for it:

PHPAPI HashTable *php_stream_get_url_stream_wrappers_hash();

It wouldn't take much to make a userland wrapper for it since it already
returns a hash table...

stream_get_wrappers();  sounds like an appropriate name

> When are certain streams not available, like, I assume
> allow_url_fopen dictates the availability of the http stream?
> FTP module for ftp, etc.
>
This is all documented in Apendix I (which is linked a couple times from
ref.stream), do you think we need to go into it in detail on ref.stream as
well?

-Pollita

Cross posting to php-dev re: addition of stream_get_wrappers() addition.




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

[PHP-DEV] PHP5/ZE2: variables definition, constant variables

[Victor Toni]

Hello,

I am using mainly C/C++, but have some experience with Java, VB,
JavaScript etc.
I started to use PHP4 about 3 months ago, and I am very impressed how
fast it can be learned.
My understanding of the languages cababilities is definitely less then
complete, but I am already missing some features.
Namespaces, static and privat class variables are scheduled for PHP5.
What I do not like about PHP variables, is that they do not have to be
defined before use.
Also there is some inconsistence at this. Personly, I would like a
behaviour similar to visual basic.
Maybe with some kind of option variable (maybe only responsible for
actual context (class, namespace, file)).

- Victor
---

Case 1 (strict):

class a {
  $OPTION['strict'] = true; // only for this class

  var $ID;   // define ID
  var static $count = 0;   // define ref counter

  function a() {
$this->ID = self::$count++; // this would result in an error if ID
is not defined
$ID = $this->ID;  // works in PHP3/4 , should result in an error in
PHP5 with strict checking
echo $this->ID;
  }

---

Case 2 (loose/normal):

class b {
  static $count = 0;   // define ref counter

  function b() {
$this->ID = self::$count++; // works
   $ID = $this->ID;  // works too
   echo $this->ID;
  }

---

one more think I do not like is:

class foo {
  const hey = 'hello';
}

print foo::hey;
---

should be:

class foo {
  const $hey = 'hello';
}

print foo::$hey;



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

[PHP-DEV] Patch for #21309 - memory + php_error_docref.

[nicos]

Hello,

   Even if this bug was assigned to sesser, this is a patch that fix the
memory managment and that removes perror and replace it by
php_error_docref().

It's also online if the mailing is denying it:
http://nicos.worldakt.com/ftp_c.patch.

Any comment appreciated, thanks.

Note: it will probably need some reviews.

Regards.
M.CHAILLAN Nicolas
[EMAIL PROTECTED]
www.WorldAKT.com Hébergement de sites internets.




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

[PHP-DEV] Patch fixing truecolor transparency issues in libgd/php (against PHP 4.3.0)

[Steven Brown]

It seems libgd development has started up again, so I'll toss my
truecolor fixes onto the pile.  Some were already fixed in the version
that comes with PHP-4.3.0 (I had originally patched against gd 2.0.1
beta), so these are the remaining issues I know of against PHP 4.3.0's
dist.
The patch is here: http://www-cs.ucsd.edu/~sbrown/php-4.3.0-gd-swb.patch
.

This fixes truecolor PNG image loading trying to extract the
transparency colors from the boolean trueColor flag rather than the
transparent color, fixes a few issues in the truecolor->palette code
with how transparency is handled, and adds gd's imageSaveAlpha to PHP.
I also changed a fix that went in that looked like it wasn't fixed quite
right, gd.c's image copy throwing out alpha when copying palette to
truecolor.  Very few browsers support alpha transparent PNGs so
imageSaveAlpha must be set false to generate boolean transparency.  PHP
4.3.0 (or its included gd) seems to default this to false now anyway (gd
used to default to true).

TrueColor PNG boolean transparency works great in all modern browsers
except desktop win32 IE.  It's your enemy on this.  Funny thing is, IE
3.02 for the Pocket PC works beautifully.  Go figure.  Also, unless it's
been changed since I first wrote this, gd in truecolor mode always
assigns color 0 as black (0,0,0).  IE (5+6) always take color index 0 as
transparent regardless of what index you tell it to use it seems, so the
hack is to always set black as your transparent color so transparent
palettized PNGs will work.  Rather than fix these issues, Microsoft has
some hacky IE-specific DirectX HTML goo
(http://webfx.eae.net/dhtml/pngbehavior/pngbehavior.html) to load
transparent truecolor PNGs.  Problem is, it's also buggy and won't work
with HTTPS addresses last I tried!  If you need to spit transparent
truecolor PNGs out over HTTPS, you need to browser detect these
PNG-challenged IEs and do a imageTrueColorToPalette to dither it down to
a palettized PNG right before you output it until Microsoft gets around
to fixing these major brokennesses in IE.  Otherwise you can browser
detect and use that DirectX hack.

If you've got questions on how to get truecolor transparent PNGs to work
in your own code, I could throw together some sample code.  With this
patch in and those workarounds, it's working great for me.


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

[PHP-DEV] HTTP_RAW_POST_DATA in phpinfo() (request)

[Kristopher Yates]

Hello everyone,

I was wondering if you all would be interested in the following:

When "always_populate_raw_post_data" is set to "on" in php.ini, one 
would be able to see the value of HTTP_RAW_POST_DATA in phpinfo() output.

I found this would have been a nice little time saver for me while 
working on writing an XML server which accepts raw XML data from HTTP POST.

I am interested in receiving any dialogue that is generated by this 
post.  Feel free to CC: me in your discussion as I am not subscribed to 
this list.  If my request is a bad idea, please share this with me so 
that I may be more security conscious in any future requests/ideas I may 
come up with for PHP DEV.  I imagine you guys get some bizarre, and/or 
just plain ridiculous requests.

On a side note of personal curiousity, what is the most 
ridiculous/bizarre feature request ever received by this group?

Regards,

Kris





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

Re: [PHP-DEV] Re: Error Loading mcrypt.dll on Windows XP system

[Derick Rethans]

On Thu, 2 Jan 2003, Christoph Grottolo wrote:

> > You need limcrypt.dll which is not provided by default.
> > Just download it here:
> > http://ftp.proventum.net/pub/php/win32/misc/mcrypt/php-4.3-mcrypt.zip
> > , copy the files: php_mcrypt.dll in your extensions directory and
> > libmcrypt.dll in c:\windows\system32,
> > restart your apache and enjoy ;-))
> 
> How about adding libmcrypt.dll to dlls folder of the windows distributions?
> It's hard to find a matching binary on the web.

We can not do that due to USA export legislation, but it is in the 
manual now:
http://www.php.net/manual/en/ref.mcrypt.php (Requirements)

Derick

-- 

-
 Derick Rethans http://derickrethans.nl/ 
 PHP Magazine - PHP Magazine for Professionals   http://php-mag.net/
-


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

[PHP-DEV] Re: Error Loading mcrypt.dll on Windows XP system

[Christoph Grottolo]

Hi

Jean Baptiste Favre wrote:

> "Jim Bierlein" <[EMAIL PROTECTED]> a écrit dans le message de news:
> [EMAIL PROTECTED]
>> My problem is that I cannot get Apache to properly load the mcrypt
>> module, I keep getting the warning message:
>>
>> Unknown(): Unable to load dynamic library
>> 'c:\php-4.3.0-Win32\extensions\php_mcrypt.dll' - The specific module
>> could not be found.
>>
>> Does anyone know what I am missing or if there is a workaround to
>> this issue.  Any help would be appreciated.  I am kind of new at
>> this.

> Hi,
> You need limcrypt.dll which is not provided by default.
> Just download it here:
> http://ftp.proventum.net/pub/php/win32/misc/mcrypt/php-4.3-mcrypt.zip
> , copy the files: php_mcrypt.dll in your extensions directory and
> libmcrypt.dll in c:\windows\system32,
> restart your apache and enjoy ;-))

How about adding libmcrypt.dll to dlls folder of the windows distributions?
It's hard to find a matching binary on the web.

Christoph



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

Re: [PHP-DEV] 4.3.0, RedHat 7.3:"Fatal error: Nesting level too deep- recursive dependency? in Unknown on line 0", even with empty file

[Wez Furlong]

Make a backtrace and then we will have a clue about what is happening...

--Wez.

On Thu, 2 Jan 2003, Tobias Schlitt wrote:

> Hi everyone!
>
> Today i compiled 4.3.0 on my Laptop (Redhat 7.3). Compiling
> works fine. Running Scripts works (until now) fine. Except,
> that i'm getting the same error, with every file i parse (even
> with whole empty ones).
>
> The Error is: "Fatal error: Nesting level too deep - recursive
> dependency? in Unknown on line 0".
>
> I have no auto_prepend oder _append settings defined inside my
> php.ini. The error occurs with the apache SAPI and with the
> CLI, too.
>
> Does anyone know about this error or / and know how to fix
> that? Or may it be a bug??


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

[PHP-DEV] 4.3.0, RedHat 7.3:"Fatal error: Nesting level too deep - recursive dependency? in Unknown on line 0", even with empty file

[Tobias Schlitt]

Hi everyone!

Today i compiled 4.3.0 on my Laptop (Redhat 7.3). Compiling 
works fine. Running Scripts works (until now) fine. Except, 
that i'm getting the same error, with every file i parse (even 
with whole empty ones).

The Error is: "Fatal error: Nesting level too deep - recursive
dependency? in Unknown on line 0".

I have no auto_prepend oder _append settings defined inside my 
php.ini. The error occurs with the apache SAPI and with the 
CLI, too.

Does anyone know about this error or / and know how to fix 
that? Or may it be a bug??

Thanks for every help!

Regards,
Toby
-- 


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

[PHP-DEV] Re: Another question on PHP building on Linux.

[Thomas Seifert]

built it as a shared module, i.e. later via the apxs-way.


Thomas


On Thu, 02 Jan 2003 07:35:17 -0700 [EMAIL PROTECTED] (Ananth Kesari) wrote:

> Hi,
> 
> We have another question on building PHP on Linux:
> 
> When building for Apache, we don't get, on Linux, the core PHP part as
> a separate binary from the Apache module. This is what the hacked up
> build scripts produced. Thus, instead of having a single core part which
> can be used by Apache 1.3 module, Apache 2.x module, command line
> interface program etc, the whole PHP core is bound statically into each
> of these!
> 
> We would like to know whether there is a way to do the way we want it
> to be done by some configure option OR do we need to modify the input
> files to the autotools to enable this?
> 
> Thanks,
> Ananth.
> 

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

Re: [PHP-DEV] Patch for #21330 - socket_select()

[Wez Furlong]

It's also broken as it will not allow for a null value to give an
infinite wait period.

--Wez.

On Thu, 2 Jan 2003, Tularis wrote:


> if (sec != NULL || sec != 0) {
> convert_to_long_ex(&sec);
> tv.tv_sec = Z_LVAL_P(sec);
> tv.tv_usec = usec;
> } else {
> tv.tv_sec = 0;
> tv.tv_usec = 0;
> }
> tv_p = &tv;
>
> But, as I said it's just a fashion statement, and nothing important...
> let stand that it will make *any* difference ;)
>
>
> --
> 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] PHP in 2003 (leading to PHP 5)

[Dan Kalowsky]

On Thursday, January 2, 2003, at 05:08 AM, John Coggeshall wrote:


When it comes to bug reporting/fixing, perhaps it's feasible to
completely separate bug reporting for each module from PHP itself? For
example, if each module is maintained completely separately from PHP
with it's own version # then there should also be a separate bug
reporting system for bugs found with that module.


I tend not to see this as the real issue.  The bug system can be 
adapted to our needs as we see fit.  The bigger issue is the QA team 
time, energy, and effort that can be expended to all these test 
scenarios.  This type of decision though will have to be made by the 
PHP/QA team, and not really by PHP-DEV.  If this is of concern to you 
(developers), I suggest you (developers) become active in the QA 
process.

I really don't see this being an issue any different for PHP Developers 
than currently setup.  Which is support only exists for the latest PHP 
engine (hence the "please try newer version" bug responses popularity).

When I look at PECL, I envision a system where modules are completely
separated from the PHP core. Each module and their maintainer(s)
(whomever they are) deal with their own bugs for that module, modules
have minnimum PHP core versions for which they work with, etc. We could
make this easier by providing a source-forge type of cookie-cutter bug
tracking system for each module, and perhaps by making the modules
themselves clearly independent of PHP. I'd like to see a system for
modules where what modules PHP uses is not defined at compile-time at
all by a ./configure statement. Rather, what modules are being used are
defined in some sort of configuration file (where the configuration
parameters for those modules are also located) and the modules are
loaded dynamically. I should be able to go download the GD module and
stick it in a subdirectory of /usr/local/lib/php and then edit my
modules.conf (or something) file:


   Allow_jpeg=true
   Allow_tiff=false




Just remember the idea right now is to move things into PECL to get 
ready for an eventual version freedom from PHP, but that is not 
happening just yet.  Stig Bakken has suggested this in the past, and 
you'll find it in archives, that this would be taking the first step 
towards, working out a lot of the bugs if found and getting the process 
to iron out.

Please realize this change also removes the PHP idea of anyone can 
fix/add/modify to an extension mantra, and forces it to a realm of per 
extension release manager/authority.  While I like this idea (something 
I and few others have advocated for awhile), it takes a rather 94 
degree turn from how PHP has been developed for the last few years.

But it also removes the need to worry about what is enabled by default 
:)

1) Faster and easier installations of PHP
By removing all of those compile-time ./configure options it will make
PHP much easier to compile and install. Problems with a single module 
at
compile-time won't stop a user from getting PHP running, and if there 
is
a problem when the module is dynamically loaded it will be easier to
figure out what's going wrong.

This isn't necessarily the right track to take.  Remember that Windows 
users do not have the need/use of a compiler on their local machines 
always.  As such, a system for distributing a binary is required.  This 
has been hashed out, and Stephen Esser was at one time working on 
implementing it.  Please see the archives for more information about 
this.


>---<
Dan Kalowsky"Thought I'd visit the club,
http://www.deadmime.org/~dankGot as far as the door."
[EMAIL PROTECTED]  - "Don't Get Around Much Anymore",
[EMAIL PROTECTED]Ella Fitzgerald


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

[PHP-DEV] Another question on PHP building on Linux.

[Ananth Kesari]

Hi,

We have another question on building PHP on Linux:

When building for Apache, we don't get, on Linux, the core PHP part as
a separate binary from the Apache module. This is what the hacked up
build scripts produced. Thus, instead of having a single core part which
can be used by Apache 1.3 module, Apache 2.x module, command line
interface program etc, the whole PHP core is bound statically into each
of these!

We would like to know whether there is a way to do the way we want it
to be done by some configure option OR do we need to modify the input
files to the autotools to enable this?

Thanks,
Ananth.


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

[PHP-DEV] [PDF Creation] Insertion of image on a PDF using EzPDF library

[Natacha Salmon]

Hi all,

Here is my problem. I got a web application, who must build a PDF using
datas from a MySQL table and a logo (JPEG format), and send the PDF
generated by mail.

I manage to build the PDF.

Instead of sending it via mail, I tried to open it directly on my browser,
IE 6.0. All is ok, I see my datas, and the logo.

But when I send it via mail, all I got when I open it on Acrobat Reader is
datas, but the logo isn't displayed. Instead , I got a grey bow, and an
alert message telling me : "Image too big".

Of course I tried to put an image 15px*15px, so, not that big ;) but it's
the same.

I really don't understand, and as the library I use is specifical, it's not
really easy to find help or documentation. And to be honnest, my application
is soon finished, and if I had to change of library, it would take me lot of
time :(

I would really appreciate any help :)

Thanks a lot.

Natacha




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

[PHP-DEV] Re: [PHP-CVS] cvs: php4(PHP_4_3) / acinclude.m4 configure.in /main streams.c

[Andrei Zmievski]

On Wed, 01 Jan 2003, Wez Furlong wrote:
> wez   Wed Jan  1 04:55:38 2003 EDT
> 
>   Modified files:  (Branch: PHP_4_3)
> /php4 acinclude.m4 configure.in 
> /php4/mainstreams.c 
>   Log:
>   Workaround a bug in glibc 2.2.9x and later that causes it not to seek to EOF
>   for stdio streams opened with a mode of "a+".

Wez,

How about implementing those persistent STDIO streams for 4.3.1?

-Andrei   http://www.gravitonic.com/
* Think digital, act analog. *

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

Re: [PHP-DEV] ChangeLog

[Andrei Zmievski]

I'll check on this.

On Wed, 01 Jan 2003, Wez Furlong wrote:
> Is there some magic that needs to be done to rotate the ChangeLog?
> By this I mean:
> 
> gzip ChangeLog
> mv ChangeLog.gz ChangeLog2002.gz
> touch ChangeLog
> cvs add -kb ChangeLog2002.gz
> cvs ci -m "rotate changelog" ChangeLog ChangeLog2002.gz
> 
> It seems the most recent entry in the log is from the 29th December, and
> I wonder if some script needs to be kicked to update the log.
> 
> --Wez.
> 
> 
> -- 
> PHP Development Mailing List 
> To unsubscribe, visit: http://www.php.net/unsub.php



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

What's hard, in hacking as in fiction,
is not the writing, it's deciding what to write.
-- Neal Stephenson

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

Re: [PHP-DEV] Patch for #21330 - socket_select()

[Tularis]

[EMAIL PROTECTED] wrote:

Well it was attached it looks the mailing list is dening them.

It put it online: http://nicos.worldakt.com/socket_select.patch

Regards.
M.CHAILLAN Nicolas
[EMAIL PROTECTED]
www.WorldAKT.com Hébergement de sites internets.


I know this doesn't really belong here, but,
I always like to keep my code as small as possible, do I think you 
should change:

 if (sec != NULL || sec != 0) {
 convert_to_long_ex(&sec);
 tv.tv_sec = Z_LVAL_P(sec);
 tv.tv_usec = usec;
 tv_p = &tv;
 }
 else {
 tv.tv_sec = 0;
 tv.tv_usec = 0;
 tv_p = &tv;
 }

to:

if (sec != NULL || sec != 0) {
   convert_to_long_ex(&sec);
   tv.tv_sec = Z_LVAL_P(sec);
   tv.tv_usec = usec;
} else {
   tv.tv_sec = 0;
   tv.tv_usec = 0;
}
tv_p = &tv;

But, as I said it's just a fashion statement, and nothing important... 
let stand that it will make *any* difference ;)


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

[PHP-DEV] Re: Patch for #21330 - socket_select()

[Wez Furlong]

#21330 actually sounds completely bogus after having looked at the
code...

--Wez.

PS: add "diff -u" to your .cvsrc

On Thu, 2 Jan 2003 [EMAIL PROTECTED] wrote:

> This is the patch that fix the issue of socket_select that doesn't wait if
> value for timeval is 0.
>
> Tell me what you think.
>
> Regards.
> M.CHAILLAN Nicolas
> [EMAIL PROTECTED]
> www.WorldAKT.com Hébergement de sites internets.
>
>



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

Re: [PHP-DEV] Patch for #21330 - socket_select()

[nicos]

Feel free to take a look at the URL then.

--
Regards.
M.CHAILLAN Nicolas
[EMAIL PROTECTED]
www.WorldAKT.com Hébergement de sites internets.

"Daniel Lorch" <[EMAIL PROTECTED]> a écrit dans le message de news:
[EMAIL PROTECTED]
> hi,
>
> > Well it was attached it looks the mailing list is dening them.
>
> The mailinglist will only let you get through text/plain Attachements.
>
> -daniel



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

Re: [PHP-DEV] Patch for #21330 - socket_select()

[Daniel Lorch]

hi,

> Well it was attached it looks the mailing list is dening them.

The mailinglist will only let you get through text/plain Attachements.

-daniel

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

Re: [PHP-DEV] Patch for #21330 - socket_select()

[nicos]

Well it was attached it looks the mailing list is dening them.

It put it online: http://nicos.worldakt.com/socket_select.patch

Regards.
M.CHAILLAN Nicolas
[EMAIL PROTECTED]
www.WorldAKT.com Hébergement de sites internets.

- Original Message -
From: "Derick Rethans" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Cc: "Wez Furlong" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Thursday, January 02, 2003 1:21 PM
Subject: Re: [PHP-DEV] Patch for #21330 - socket_select()


> On Thu, 2 Jan 2003 [EMAIL PROTECTED] wrote:
>
> > This is the patch that fix the issue of socket_select that doesn't wait
if
> > value for timeval is 0.
> >
> > Tell me what you think.
>
> "There is no patch"
>
> Derick
>
> --
>
> -
>  Derick Rethans http://derickrethans.nl/
>  PHP Magazine - PHP Magazine for Professionals   http://php-mag.net/
> -
>


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

Re: [PHP-DEV] Patch for #21330 - socket_select()

[Derick Rethans]

On Thu, 2 Jan 2003 [EMAIL PROTECTED] wrote:

> This is the patch that fix the issue of socket_select that doesn't wait if
> value for timeval is 0.
> 
> Tell me what you think.

"There is no patch"

Derick

-- 

-
 Derick Rethans http://derickrethans.nl/ 
 PHP Magazine - PHP Magazine for Professionals   http://php-mag.net/
-


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

[PHP-DEV] Patch for #21330 - socket_select()

[nicos]

This is the patch that fix the issue of socket_select that doesn't wait if
value for timeval is 0.

Tell me what you think.

Regards.
M.CHAILLAN Nicolas
[EMAIL PROTECTED]
www.WorldAKT.com Hébergement de sites internets.



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

[PHP-DEV] Status of NSAPI and Servlet SAPIs?

[Jari Lehtonen]

Hello,

as a webmaster for largish university using Sun ONE Web Server (former 
iPlanet) I've been wondering for a while what really is the status of PHP's 
NSAPI SAPI module? It seems to stay unchanged from release to release, and 
bugs relating to the worst problem with NSAPI (serving of PHP pages stops 
at random) seem not to be solved. (And no, it is not a problem with file 
descriptor limit setting in the operating system.)

Fact is, we need a reliably working PHP and currently we don't have that. 
Which leads me to think about the servlet implementation, which probably 
would be as efficient on Sun ONE server as NSAPI. Is the servlet SAPI being 
developed? I tried it as of PHP 4.2.3, and it compiled fine using Sun's JDK 
1.4.1_01 on Solaris 8, and with servlet.jar suppied with Sun ONE server. It 
even partially worked. Now, using PHP 4.3.0 the servlet SAPI doesn't even 
compile; the makefile directives are badly formed and do not point to 
correct files. Hasn't anyone tested it before release?

I'm willing to test developmnents to both SAPIs and to provide feedback, 
but I'm not fluent enough in C to contribute code. If one or both of those 
SAPIs are being phased out, I'd like to hear that too, so that we can make 
better recommendations to our users.

For reference, our platform is
- Sun Fire 280R server
- Solaris 8 (with recommended patches as of 2002/12)
- Sun ONE Enterprise Web Server 6.0SP5
- PHP 4.3.0

--

   Jari Lehtonen
   Unix & Network Services
   University of Turku, Computing Center

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

RE: [PHP-DEV] PHP in 2003 (leading to PHP 5)

[Dan Hardiker]

> [John Coggeshall]
> These are all just thoughts I have.. Feedback is more than welcome. I
> think a system such as this would accomplish a number of (in my mind)
> benfitial things:
>
> 1) Faster and easier installations of PHP
> [...]
>
> 2) More accurate and managable module maintaing
> [...]

Also, having the php configuration (compile-time) separated from the
module configuration (run-time) would enable external build structures
(such as the FreeBSD "ports" system) to install "base" php installations,
and with it tools to update/install/deinstall modules dynamically.

For "jack-in-the-box" (preconfigured) systems/packages like RedHat rpm's /
other binary distributions, this would also have the same advantage.
[currently 3 or 4 binaries are created depending on the amount of modules
you want and in what way you want them configured]


-- 
Dan Hardiker [[EMAIL PROTECTED]]
ADAM Software & Systems Engineer
First Creative



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

RE: [PHP-DEV] PHP in 2003 (leading to PHP 5)

[John Coggeshall]

I tend to agree that completely separating PHP from the modules does
cause a problem when it comes to support modules, etc. However, IMHO I
feel that as the numbers of modules written for PHP increases there
becomes a greater and greater need to separate modules from the core of
PHP.

When it comes to bug reporting/fixing, perhaps it's feasible to
completely separate bug reporting for each module from PHP itself? For
example, if each module is maintained completely separately from PHP
with it's own version # then there should also be a separate bug
reporting system for bugs found with that module. 

Also, on that note, is there any hard and fast standard in place for
modules/extensions and the minnimum PHP version those modules support?
I.e. is there anything that is designed to prevent me from trying to
load a module in PHP 4.0 when it won't work with any version of PHP less
than 4.2? I mean more than it throwing an error at compile-time of
course.

When I look at PECL, I envision a system where modules are completely
separated from the PHP core. Each module and their maintainer(s)
(whomever they are) deal with their own bugs for that module, modules
have minnimum PHP core versions for which they work with, etc. We could
make this easier by providing a source-forge type of cookie-cutter bug
tracking system for each module, and perhaps by making the modules
themselves clearly independent of PHP. I'd like to see a system for
modules where what modules PHP uses is not defined at compile-time at
all by a ./configure statement. Rather, what modules are being used are
defined in some sort of configuration file (where the configuration
parameters for those modules are also located) and the modules are
loaded dynamically. I should be able to go download the GD module and
stick it in a subdirectory of /usr/local/lib/php and then edit my
modules.conf (or something) file:


   Allow_jpeg=true
   Allow_tiff=false


These are all just thoughts I have.. Feedback is more than welcome. I
think a system such as this would accomplish a number of (in my mind)
benfitial things:

1) Faster and easier installations of PHP
By removing all of those compile-time ./configure options it will make
PHP much easier to compile and install. Problems with a single module at
compile-time won't stop a user from getting PHP running, and if there is
a problem when the module is dynamically loaded it will be easier to
figure out what's going wrong.

2) More accurate and managable module maintaing
If modules are completely separated from PHP itself, then the status of
a particular module, the people who are maintaining it, news about the
modules, etc. will be easily found. 

There are more, but it's late and I'm going to get to sleep :) Like I
said, feedback is more than welcome and I'd love to work with whomever
is interested to move PHP in this direction. 

Cheers,

John


>-Original Message-
>From: Dan Hardiker [mailto:[EMAIL PROTECTED]] 
>Sent: Thursday, January 02, 2003 3:59 AM
>To: [EMAIL PROTECTED]
>Cc: [EMAIL PROTECTED]
>Subject: Re: [PHP-DEV] PHP in 2003 (leading to PHP 5)
>
>
>> [...]
>> different distribution packages can be
>> built when php releases occure, such as 'php core' which 
>would contain 
>> the 'most important' stable extensions, 'php stable' which would 
>> contain  all stable extensions, and 'php bleeding' which could be a 
>> package with  the latest development snapshot at time of release.
>>
>> With this also extensions now can take on a life of their own, 
>> releasing  at different times than php, and visaverse.  I think this 
>> would make releasing new versions of php much more manageable.
>
>>From my past experiance, Ive found this sort of idea to be great - if 
>>the
>modules are retrieved else where, otherwise you end up with a 
>support nightmare.
>
>Currently in the bug tracker we only need to ask what version 
>of PHP they have and we automatically know what version all 
>the of the modules are as they come bundled. If all the 
>modules are updateable independantly of the PHP release having 
>"PHP x.x.x" installed is no longer enough release information, 
>we (via the end user) would also have to gather the version 
>number for each module - ouch.
>
>Not to mention the painful testing! [eg:] I have 4 
>installations running 4 different versions of PHP for 
>regression testing and bug fixing. If I relied on 3 different 
>modules and wanted to check 2 versions of each, I would need 4 
>* 3 * 2 (24) installations - just to test.
>
>Im not against the concept of modules, but Id encourage the 
>idea to be well thought out (especially the impact) as well as 
>encouraging them to be thought more of "plug-ins" which are 
>independant and may well be "upgraded".
>
>
>
>
>-- 
>Dan Hardiker [[EMAIL PROTECTED]]
>ADAM Software & Systems Engineer
>First Creative
>
>
>
>-- 
>PHP Development Mailing List 
>To unsubscribe, visit: http://www.php.net/unsub.php
>
>


-- 
PHP Development Mailing L

Re: [PHP-DEV] PHP in 2003 (leading to PHP 5)

[Dan Hardiker]

> [...]
> different distribution packages can be
> built when php releases occure, such as 'php core' which would contain
> the 'most important' stable extensions, 'php stable' which would contain
>  all stable extensions, and 'php bleeding' which could be a package with
>  the latest development snapshot at time of release.
>
> With this also extensions now can take on a life of their own, releasing
>  at different times than php, and visaverse.  I think this would make
> releasing new versions of php much more manageable.

>From my past experiance, Ive found this sort of idea to be great - if the
modules are retrieved else where, otherwise you end up with a support
nightmare.

Currently in the bug tracker we only need to ask what version of PHP they
have and we automatically know what version all the of the modules are as
they come bundled. If all the modules are updateable independantly of the
PHP release having "PHP x.x.x" installed is no longer enough release
information, we (via the end user) would also have to gather the version
number for each module - ouch.

Not to mention the painful testing! [eg:] I have 4 installations running 4
different versions of PHP for regression testing and bug fixing. If I
relied on 3 different modules and wanted to check 2 versions of each, I
would need 4 * 3 * 2 (24) installations - just to test.

Im not against the concept of modules, but Id encourage the idea to be
well thought out (especially the impact) as well as encouraging them to be
thought more of "plug-ins" which are independant and may well be
"upgraded".




-- 
Dan Hardiker [[EMAIL PROTECTED]]
ADAM Software & Systems Engineer
First Creative



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

[PHP-DEV] CVS Account Request: uuuuumesh

[umesh kumar chaudhary]

To Test

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