Re: [PHP-DEV] PHP 5.0.0 Release information.
Hi, Hi Can you let me know what is the plan for the final PHP 5.0.0 Release - when is it likely to be released? We need this information to plan our activities in submitting the latest NetWare changes into the PHP source tree. http://www.zend.com/php/ask_experts.p see 4th answer. Mehdi -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Little question for the protos
Mehdi, Do you have a list with bad protos now? If you have you may send them to me and I will correct them. Nothing special right now but I'll send you fixes ;) C ya, Mehdi Hi there, What should I do when I find bad protos in the php-src files while I'm looking at them for documentation purpose ? Should I throw a mail here, an unified diff to the source files correcting protos, or should I just cose my eyes and document with the right protos ? Thanks for the answers. Mehdi -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] VCS Account Request: mehdone
I want to start reading the source code and contribute to the development of the PHP runtime. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] About #37799
Hello, I had a look at http://bugs.php.net/37799 and I would really like to have a little warning added upon SSL connection failure. From my understanding, the silent fall back to a normal connection is made in ftp.c at line 269, which as the bug reporter says, "leads to a false sense of security". Anyone ? Best Regards, Mehdi Achour -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] About #37799
Hi, Nuno Lopes wrote: I had a look at http://bugs.php.net/37799 and I would really like to have a little warning added upon SSL connection failure. From my understanding, the silent fall back to a normal connection is made in ftp.c at line 269, which as the bug reporter says, "leads to a false sense of security". I would instead make ftp_ssl_connect failing and returns false. I prefer functions without too much error messages for expected errors (a network connection can fail, no need to raise a warning here). Then let the user decides to try again using ftp_connect. --Pierre Yes, I have to agree here. I would also prefer returning false on failure (as other extensions do). Nuno Pierre, I completely agree, user should have a real error. The problem is that ftp_ssl_connect doesn't really do the SSL connection. The silent switch is made when ftp_login() is called. If we make anyone fail, it should be ftp_login() and that would make sense. Mehdi -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] ncurses
Hello, It seems that the EXPERIMENTAL file for ncurses was lost during the migration of this module to PECL. Was this change intentional? Can we lose the warnings in ncurses docs? Thanks in advance Mehdi -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Improving the documentation
Hello internals, I've been helping with PHP documentation for 4 years now, and I still can't help the fact that a lt of things are not documented, that our/my way of handling the PHP documentation update is not accurate, nor productive, nor bug free at all. Personally, I try to follow commits on php.cvs, bug reports, Change Log?, user notes on the online manual.. but I still have the feeling of missing a lot of changes. After a year away from the project, I have _no_ clue what was added, when, and whether it was added to our documentation or not. I know that you developers are willing to help a lot with it, but that you cannot manage to save the spare time needed to do it the right way. That's why I would like to propose a simple/small/timeless change in your CVS commit messages: If you feel that the change need to be documented, place the @doc keyword at the end of your message log entry. And if you feel like telling us more about what you changed, point us to some online resource or whatever. Simply add that after the @doc tag. This additional comment is optional, and you don't need to bother if the change is obvious, or if you simply don't feel like doing it ATM. This small @doc tag could _slightly_ improve/optimize/sanitize our work on the documentation. By adding some SQL logging in loginfo.pl, and storing the following: * date: commit date * login: CVS account of the developer * branch: CVS branch * files: Changed files * commit: Commit message before @doc * desc : Optional developer description after @doc We would be able to have an interface displaying a dynamic phpdoc TODO, with some nice features like a search by PHP version, extension, assignee, keywords.. Additionally, we can imagine adding an online help feature on the interface, by setting a “help” flag on some hardly understandable change, to have [EMAIL PROTECTED] notified of our need for enlightenment. Any thoughts ? Mehdi Achour -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [PHP-DOC] Re: [PHP-DEV] Re: [PHP-DOC] Improving the documentation
Hello Wez, Thanks for your action. BTW, we need to stick to one tag :) I proposed @doc, you implemented [DOC] .. we should pick one syntax and stick to it. By the way, Etienne (cc'ed) started to work on the web interface I described in my first email. You may want to get in touch with him to help him get things working. Maybe we could set up another newsgroup for the emails? (php.doc.todo) Mehdi On 2/10/07, Wez Furlong <[EMAIL PROTECTED]> wrote: I tweaked loginfo.pl so that if the commit message contains [DOC], phpdoc@ will be Cc'd. Hopefully that'll help in some small way. --Wez. On 2/10/07, Rasmus Lerdorf <[EMAIL PROTECTED]> wrote: > We, and by we I mean all of us who write code and hope that divine > intervention will take care of the documentation, need to do a better > job helping out divinity. A DOC tag in cvs commit messages seems like a > small and easy thing for us to add to the process, so if you feel that > will be enough to make things easier, let's do that. > > Perhaps we can do more though. Maybe you guys could periodically update > internals on problem areas in the docs. Places where you feel things > are vague and really could use the guy who wrote the code to get off his > ass and explain how it works. Or maybe we could get everyone who reads > internals to pick a page or two in the manual on something they are > intimately familiar with and go over it in detail and feed suggestions > back to phpdoc@ > > -Rasmus > > > Ronald Chmara wrote: > > On Jan 27, 2007, at 8:26 AM, Mehdi Achour wrote: > >> Hello internals, > >> I've been helping with PHP documentation for 4 years now, and I still > >> can't help the fact that a lt of things are not documented, that > >> our/my way of handling the PHP documentation update is not accurate, > >> nor productive, nor bug free at all. > > > > I think it's been ~7 years of off and on work for me... same as it ever > > was. I do think it's *much* more productive and accurate than it was 7 > > years ago, though. Not quite bug-free, yet. > > > > (You think it's bad now...) > > > >> Personally, I try to follow commits on php.cvs, bug reports, Change > >> Log?, user notes on the online manual.. but I still have the feeling > >> of missing a lot of changes. After a year away from the project, I > >> have _no_ clue what was added, when, and whether it was added to our > >> documentation or not. > > > > You are in the same boat as me. The dunes change, but the sands are > > always shifting. I might have been away for n years. Much has changed, > > and much has not. > > > >> I know that you developers are willing to help a lot with it, but that > >> you cannot manage to save the spare time needed to do it the right > >> way. That's why I would like to propose a simple/small/timeless change > >> in your CVS commit messages: If you feel that the change need to be > >> documented, place the @doc keyword at the end of your message log entry. > > > > Scenario one: > > All behavior changes must be documented, this tag is always there, and > > thus not useful. > > > > Scenario two: > > Developers decide when changes are "important" enough to be documented, > > and tag as such, in which case we go back to... > > > > Scenario three: > > The problem of developers who don't think documentation is needed for > > their changes. > > > > In the end, I often wonder if this is documentation issue, or a > > developer issue. Developers read the code, and often don't need *any* > > documentation. Our end users read a manual page, and wonder what a > > "bool" or "int" is, as a very large number of our users are fairly new > > to the whole subject matter. > > > > (side joke, does PHP have a zool(), destroyer of all world (global) > > variables?) > > > > Anyways, to me, the real challenge of working on the PHP docs is not > > getting programmers to feed us reliable, consistent, data all the time > > (they won't), but rather, helping out our end users who don't read > > source code. > > > > Vanity devs will want us to document everything, quiet devs will never > > tag it. > > > > In the end, the doc team still has to fix it. > > > > -Ronabop > > > > --PHP Internals - PHP Runtime Development Mailing List > > To unsubscribe, visit: http://www.php.net/unsub.php > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PHP-DOC] Improving the documentation
As Phillip stated, we already have a set of tools that points us to the problems in the documentation. We also are switching the documentation to a clearer format, which we help us to have more accurate results on this, while making docs editing simpler for you guys. I've noted your periodical update proposal. Indeed, a wiki page on phpdoc.info could help to prepare a weekly email to internals (with some statistics like the one Phillip gave us). Thank you all for your replies, I'm happy to see that the snowball effect started! Mehdi On 2/10/07, Rasmus Lerdorf <[EMAIL PROTECTED]> wrote: We, and by we I mean all of us who write code and hope that divine intervention will take care of the documentation, need to do a better job helping out divinity. A DOC tag in cvs commit messages seems like a small and easy thing for us to add to the process, so if you feel that will be enough to make things easier, let's do that. Perhaps we can do more though. Maybe you guys could periodically update internals on problem areas in the docs. Places where you feel things are vague and really could use the guy who wrote the code to get off his ass and explain how it works. Or maybe we could get everyone who reads internals to pick a page or two in the manual on something they are intimately familiar with and go over it in detail and feed suggestions back to phpdoc@ -Rasmus Ronald Chmara wrote: > On Jan 27, 2007, at 8:26 AM, Mehdi Achour wrote: >> Hello internals, >> I've been helping with PHP documentation for 4 years now, and I still >> can't help the fact that a lt of things are not documented, that >> our/my way of handling the PHP documentation update is not accurate, >> nor productive, nor bug free at all. > > I think it's been ~7 years of off and on work for me... same as it ever > was. I do think it's *much* more productive and accurate than it was 7 > years ago, though. Not quite bug-free, yet. > > (You think it's bad now...) > >> Personally, I try to follow commits on php.cvs, bug reports, Change >> Log?, user notes on the online manual.. but I still have the feeling >> of missing a lot of changes. After a year away from the project, I >> have _no_ clue what was added, when, and whether it was added to our >> documentation or not. > > You are in the same boat as me. The dunes change, but the sands are > always shifting. I might have been away for n years. Much has changed, > and much has not. > >> I know that you developers are willing to help a lot with it, but that >> you cannot manage to save the spare time needed to do it the right >> way. That's why I would like to propose a simple/small/timeless change >> in your CVS commit messages: If you feel that the change need to be >> documented, place the @doc keyword at the end of your message log entry. > > Scenario one: > All behavior changes must be documented, this tag is always there, and > thus not useful. > > Scenario two: > Developers decide when changes are "important" enough to be documented, > and tag as such, in which case we go back to... > > Scenario three: > The problem of developers who don't think documentation is needed for > their changes. > > In the end, I often wonder if this is documentation issue, or a > developer issue. Developers read the code, and often don't need *any* > documentation. Our end users read a manual page, and wonder what a > "bool" or "int" is, as a very large number of our users are fairly new > to the whole subject matter. > > (side joke, does PHP have a zool(), destroyer of all world (global) > variables?) > > Anyways, to me, the real challenge of working on the PHP docs is not > getting programmers to feed us reliable, consistent, data all the time > (they won't), but rather, helping out our end users who don't read > source code. > > Vanity devs will want us to document everything, quiet devs will never > tag it. > > In the end, the doc team still has to fix it. > > -Ronabop > > --PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: CVS Account Request: thavincy
Stef Verbeeck wrote: Need translations done in Dutch? Contact me and maybe I can help you out... Usually it's the opposite : You contact us ([EMAIL PROTECTED]), you ask for some work, you do it, you show it to us, and after that you apply for a CVS id if we ask you to do so.. Mehdi Achour -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: constant name
Andi Gutmans wrote:
No, you should say that only [a-zA-Z_\x7f-\xff][a-zA-Z0-9_\x7f-\xff]*
are valid.
In addition, maybe post 5.0 we will unify global const and class const
and then it'll definitely not work with those weird names. There are
also plenty of weird things you can do with C which aren't defined.
Thank you for your answer Andi. Better than a "just leave it"
Mehdi Achour
Andi
At 11:20 AM 5/7/2004 +0200, Mehdi Achour wrote:
Derick Rethans wrote:
On Fri, 7 May 2004, Mehdi Achour wrote:
Should I change the documentation to say that ".*" can be a constant
name, but
that we recommand [a-zA-Z_\x7f-\xff][a-zA-Z0-9_\x7f-\xff]* ?
Just leave it as is.
I wanted to complete the TODO commented on languages/constants.xml
(Example of valid & invalid constant names)
But anyway...
Derick
Mehdi Achour wrote:
Hi !
The manual reads :
"The name of a constant follows the same rules as any label in PHP. A
valid constant name starts with a letter or underscore, followed
by any number of letters, numbers, or underscores. As a regular
expression, it would be expressed thusly:
'[a-zA-Z_\x7f-\xff][a-zA-Z0-9_\x7f-\xff]'"
I know that this is true when trying to echo a constant directly,
as the
parser raise an error, but you can trick it with a constant() call :
define('
(\ /)
{°_°)
() ()
( )( )
', 'barfoo');
echo constant('
(\ /)
{°_°)
() ()
( )( )
') . chr(10); // outputs : bar
Is it a feature or a bug ? :)
Mehdi Achour
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: constant name
Should I change the documentation to say that ".*" can be a constant name, but
that we recommand [a-zA-Z_\x7f-\xff][a-zA-Z0-9_\x7f-\xff]* ?
Mehdi Achour
Mehdi Achour wrote:
Hi !
The manual reads :
"The name of a constant follows the same rules as any label in PHP. A
valid constant name starts with a letter or underscore, followed
by any number of letters, numbers, or underscores. As a regular
expression, it would be expressed thusly:
'[a-zA-Z_\x7f-\xff][a-zA-Z0-9_\x7f-\xff]'"
I know that this is true when trying to echo a constant directly, as the
parser raise an error, but you can trick it with a constant() call :
define('
(\ /)
{°_°)
() ()
( )( )
', 'barfoo');
echo constant('
(\ /)
{°_°)
() ()
( )( )
') . chr(10); // outputs : bar
Is it a feature or a bug ? :)
Mehdi Achour
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: constant name
Derick Rethans wrote:
On Fri, 7 May 2004, Mehdi Achour wrote:
Should I change the documentation to say that ".*" can be a constant name, but
that we recommand [a-zA-Z_\x7f-\xff][a-zA-Z0-9_\x7f-\xff]* ?
Just leave it as is.
I wanted to complete the TODO commented on languages/constants.xml
(Example of valid & invalid constant names)
But anyway...
Derick
Mehdi Achour wrote:
Hi !
The manual reads :
"The name of a constant follows the same rules as any label in PHP. A
valid constant name starts with a letter or underscore, followed
by any number of letters, numbers, or underscores. As a regular
expression, it would be expressed thusly:
'[a-zA-Z_\x7f-\xff][a-zA-Z0-9_\x7f-\xff]'"
I know that this is true when trying to echo a constant directly, as the
parser raise an error, but you can trick it with a constant() call :
define('
(\ /)
{°_°)
() ()
( )( )
', 'barfoo');
echo constant('
(\ /)
{°_°)
() ()
( )( )
') . chr(10); // outputs : bar
Is it a feature or a bug ? :)
Mehdi Achour
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: CVS Account Request: abor
Alan Lorenzo San Jose wrote: Translate php code to spanish language. you mean the documentation ? didou -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] constant name
Hi !
The manual reads :
"The name of a constant follows the same rules as any label in PHP. A
valid constant name starts with a letter or underscore, followed
by any number of letters, numbers, or underscores. As a regular
expression, it would be expressed thusly:
'[a-zA-Z_\x7f-\xff][a-zA-Z0-9_\x7f-\xff]'"
I know that this is true when trying to echo a constant directly, as the
parser raise an error, but you can trick it with a constant() call :
define('
(\ /)
{°_°)
() ()
( )( )
', 'barfoo');
echo constant('
(\ /)
{°_°)
() ()
( )( )
') . chr(10); // outputs : bar
Is it a feature or a bug ? :)
Mehdi Achour
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] constant name
barfoo (c/p error)
Jason Garber wrote:
Does it output "barfoo" or "bar"?
~Jason
At 5/5/2004 10:01 PM +0200, Mehdi Achour wrote:
Hi !
The manual reads :
"The name of a constant follows the same rules as any label in PHP. A
valid constant name starts with a letter or underscore, followed
by any number of letters, numbers, or underscores. As a regular
expression, it would be expressed thusly:
'[a-zA-Z_\x7f-\xff][a-zA-Z0-9_\x7f-\xff]'"
I know that this is true when trying to echo a constant directly, as the
parser raise an error, but you can trick it with a constant() call :
define('
(\ /)
{=B0_=B0)
() ()
( )( )
', 'barfoo');
echo constant('
(\ /)
{=B0_=B0)
() ()
( )( )
') . chr(10); // outputs : bar
Is it a feature or a bug ? :)
Mehdi Achour
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Array Question
This is now [1] a fixed documentation bug :) I didn't find anything about it in the ChangeLog, nor bugs.php.net, so I didn't include any version information in the docs. Drop a mail to the documentation list if you figure it out ;) didou [1] - http://cvs.php.net/diff.php/phpdoc/en/reference/array/functions/array.xml?r1=1.11&r2=1.12&ty=u Red Wingate wrote: I guess that was <= 4.1.0 as i get errors at work ( 4.0.x ) and everything went fine as i misstyped today using 5.0.0rc3 :-) --red Adam Maccabee Trachtenberg wrote: On Thu, 17 Jun 2004, Jason Garber wrote: Is being able to have a comma at the END of an array definition a supported feature, or an undocumented feature that should not be used? If I remember correctly, Zeev or Andi specifically added it as a result of a user request, so I'd say it's an undocumented feature. -adam -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Fixlet for INSTALL
Hi, Please find attached a patch that fix #28921 didou Index: INSTALL === RCS file: /repository/php-src/INSTALL,v retrieving revision 1.33 diff -u -r1.33 INSTALL --- INSTALL 3 Jul 2003 04:14:42 - 1.33 +++ INSTALL 28 Jun 2004 14:05:41 - @@ -8,7 +8,7 @@ http://www.php.net/manual/en/install.apache.php -For Apache 2, instructions and up-to-date information regarding it's +For Apache 2, instructions and up-to-date information regarding its support status, is available here: http://www.php.net/manual/en/install.apache2.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] #20760 : is it really the intended behavior ?
Hi internals,
Trying to close some documentation bugs, I saw #20760.
Here's the problem :
class Foo {
var $bla;
function quux() {
$this->bla = 5;
}
}
class Bar {
var $bla;
function do_stuff() {
$this->bla = 10;
Foo::quux();
echo $this->bla;
}
}
$blabla = new Bar;
$blabla->do_stuff(); // will print 5, Foo::$bar value
Derick claimed that it was an intended behavior, I'd like to
make sure before documenting it. I'd also like to know why
do we have this feature ? It's quiet confusing.
Thank you in advance,
Mehdi Achour
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] [patch] broken link in php.ini-recommended
Hi Internals, Attached a patch fixing a broken link to the manual. Regards, didou Index: php.ini-recommended === RCS file: /repository/php-src/php.ini-recommended,v retrieving revision 1.159 diff -u -r1.159 php.ini-recommended --- php.ini-recommended 15 Jul 2004 19:09:37 - 1.159 +++ php.ini-recommended 22 Jul 2004 08:18:07 - @@ -77,7 +77,7 @@ ; import_request_variables() function. ; Note that register_globals is going to be depracated (i.e., turned off by ; default) in the next version of PHP, because it often leads to security bugs. -; Read http://php.net/manual/en/security.registerglobals.php for further +; Read http://php.net/manual/en/security.globals.php for further ; information. ; - register_long_arrays = Off [Performance] ; Disables registration of the older (and deprecated) long predefined array -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: How to access the per-class constant from a member function?
Hi Kamesh, Try replacing Foo::HELLO with self::HELLO. This should work. (this is documented, the manual will reflect it in the next build) didou Kamesh Jayachandran wrote: Hi All, memberfunc(); ?> With a error_reporting=2047 I get Notice: Use of undefined constant HELLO - assumed 'HELLO' in /rekha/php-5.0.0/test.php on line 5 Whey echo HELLO fails? With regards Kamesh Jayachandran -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: implementation of islamic (hijri) calendar for Calendar extension
> 6) How is Hijri pronounced? Is the j hard like english-"Jump", soft like spanish-"Juego", or silent? Just curious on that one... It's like the g in edge. It comes from "El Hijra", the exodus of Muhamed the Islamic prophet :) didou -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Hebrew Support in PHP Manual
Hi, You should discuss this on [EMAIL PROTECTED], not on internals. See you there :) Mehdi Achour [EMAIL PROTECTED] wrote: Hello all, I don't think that the first message you got about Hebrew support, but I need help about it. The problem with Hebrew is that this language required right to left. (as you all know by now...) The php manual doesn't has rtl support, or I don't know how to use it. How can I help in adding rtl support? This is the thing the prevent many israeli programmers in helping with the manual. Thanks, Hadar Porat --- Walla! Mail, Get Your Private, Free E-mail from Walla! at: http://mail.walla.co.il -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Status of Multibyte support in PHP
The warning will be gone after the next build of the manual. Mehdi Al Baker wrote: So, all the mb_* functions will have the experimental removed? I see a few that still have it, or is that just the mirrors not up to date yet? Al On Sat, 2004-08-28 at 23:35 +1000, Dave Barr wrote: Derick Rethans wrote: On Fri, 27 Aug 2004, Al Baker wrote: Thanks for the confirmation. The experimental warning appears on any of the individual help files for mbstring (e.g. mb_ereg). Can you file a "Documentation" problem for that on bugs.php.net please? Don't bother, I have fixed this in the documentation. regards, Derick Dave -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: CVS
Is it possible to make the affected directories read-only ? Mehdi Derick Rethans wrote: Hello Folks, I just shutdown the CVS server because there are still no diffs being send out. This means that there is no control over who commits what anymore resulting in the probability of bad code into CVS. Until the CVS commit mails work again the CVS will remain down. This problem does not seem to affect all modules though, and also not always. regards, Derick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: CVS
Is it possible to make the affected directories read-only ? Mehdi Derick Rethans wrote: Hello Folks, I just shutdown the CVS server because there are still no diffs being send out. This means that there is no control over who commits what anymore resulting in the probability of bad code into CVS. Until the CVS commit mails work again the CVS will remain down. This problem does not seem to affect all modules though, and also not always. regards, Derick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: CVS
Is it possible to make the affected directories read-only ? Mehdi Derick Rethans wrote: Hello Folks, I just shutdown the CVS server because there are still no diffs being send out. This means that there is no control over who commits what anymore resulting in the probability of bad code into CVS. Until the CVS commit mails work again the CVS will remain down. This problem does not seem to affect all modules though, and also not always. regards, Derick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] [Fwd: note 50716 added to function.mssql-query]
Is this true ? Mehdi --- Begin Message --- Warning ! with php 4.3.10, when you use mssql_query to insert or update data, the returned result is false but the query is really executed. Solution -> Download the ms sql extension patched from: http://sourceforge.net/project/showfiles.php?group_id=75482 PHP 4.3.10 see u Manual Page -- http://www.php.net/manual/en/function.mssql-query.php Edit-- http://master.php.net/manage/user-notes.php?action=edit+50716 Delete: added to the manual -- http://master.php.net/manage/user-notes.php?action=delete+50716&report=yes&reason=added+to+the+manual Delete: bad code-- http://master.php.net/manage/user-notes.php?action=delete+50716&report=yes&reason=bad+code Delete: spam-- http://master.php.net/manage/user-notes.php?action=delete+50716&report=yes&reason=spam Delete: useless -- http://master.php.net/manage/user-notes.php?action=delete+50716&report=yes&reason=useless Delete: other reasons -- http://master.php.net/manage/user-notes.php?action=delete+50716&report=yes Reject -- http://master.php.net/manage/user-notes.php?action=reject+50716&report=yes Search -- http://master.php.net/manage/user-notes.php --- End Message --- -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [Fwd: note 50716 added to function.mssql-query]
Wich versions were broken, I need a confirmation to add a warning in the documentation. Thanks a lot! didou Antony Dovgal wrote: On Tue, 08 Mar 2005 10:03:50 +0100 Mehdi Achour <[EMAIL PROTECTED]> wrote: Is this true ? No, it's fixed in CVS. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Little question for the protos
Hi there, What should I do when I find bad protos in the php-src files while I'm looking at them for documentation purpose ? Should I throw a mail here, an unified diff to the source files correcting protos, or should I just cose my eyes and document with the right protos ? Thanks for the answers. Mehdi -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: CVS Account Request: stercor
Hi Ted, Where is the e-mail forwarding maintenance page? I need to change the destination of mail forwarded through php.net. Click here http://master.php.net/manage/users.php?id=37 :) Mehdi -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Question on php_image_type_to_mime_type
Hi all, I'm in php-src/ext/standard/image.c (revision 1.92) Looking at php_image_type_to_mime it seems like there are two constants not handled : IMAGETYPE_JB2 IMAGETYPE_JPX Am I looking at the good version of the C file ? didou -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Question on php_image_type_to_mime_type
>>I'm in php-src/ext/standard/image.c (revision 1.92) Looking at php_image_type_to_mime it seems like there are two constants not handled : IMAGETYPE_JB2 IMAGETYPE_JPX Am I looking at the good version of the C file ? Yes. Shouldn't be corrected ? didou -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Question on php_image_type_to_mime_type
Marcus Börger wrote: Hello Mehdi, Friday, August 15, 2003, 10:22:28 PM, you wrote: MA> >>I'm in php-src/ext/standard/image.c (revision 1.92) Looking at php_image_type_to_mime it seems like there are two constants not handled : IMAGETYPE_JB2 IMAGETYPE_JPX Am I looking at the good version of the C file ? Yes. MA> Shouldn't be corrected ? No, they are used elsewhere, too. If you mean the support is missing, feel free to add it. Hi Marcus, I don't have karma to php-src :) Here's what should be changed : constant mime-type IMAGETYPE_JPX image/jpx IMAGETYPE_JB2 image/jb2 Can you do it for me ? didou -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Question on php_image_type_to_mime_type
Marcus Börger wrote: Hello Mehdi, Friday, August 15, 2003, 10:47:41 PM, you wrote: MA> Marcus Börger wrote: Hello Mehdi, Friday, August 15, 2003, 10:22:28 PM, you wrote: MA> >>I'm in php-src/ext/standard/image.c (revision 1.92) Looking at php_image_type_to_mime it seems like there are two constants not handled : IMAGETYPE_JB2 IMAGETYPE_JPX Am I looking at the good version of the C file ? Yes. MA> Shouldn't be corrected ? No, they are used elsewhere, too. If you mean the support is missing, feel free to add it. MA> Hi Marcus, MA> I don't have karma to php-src :) MA> Here's what should be changed : MA> constant mime-type MA> IMAGETYPE_JPX image/jpx MA> IMAGETYPE_JB2 image/jb2 Which source are those based on? JB2 : http://cgi.netscape.com/cgi-bin/pi_moreinfo.cgi?PID=11473 JPX : http://www.ietf.org/internet-drafts/draft-singer-jp2-01.txt The source for JB2 mime type may seems not enough. didou -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Question on php_image_type_to_mime_type
Marcus BöRger wrote: Hello Mehdi, Friday, August 15, 2003, 11:20:52 PM, you wrote: MA> Marcus Börger wrote: Hello Mehdi, Friday, August 15, 2003, 10:47:41 PM, you wrote: MA> Marcus Börger wrote: Hello Mehdi, Friday, August 15, 2003, 10:22:28 PM, you wrote: MA> >>I'm in php-src/ext/standard/image.c (revision 1.92) Looking at php_image_type_to_mime it seems like there are two constants not handled : IMAGETYPE_JB2 IMAGETYPE_JPX Am I looking at the good version of the C file ? Yes. MA> Shouldn't be corrected ? No, they are used elsewhere, too. If you mean the support is missing, feel free to add it. MA> Hi Marcus, MA> I don't have karma to php-src :) MA> Here's what should be changed : MA> constant mime-type MA> IMAGETYPE_JPX image/jpx MA> IMAGETYPE_JB2 image/jb2 Which source are those based on? MA> JB2 : http://cgi.netscape.com/cgi-bin/pi_moreinfo.cgi?PID=11473 MA> JPX : http://www.ietf.org/internet-drafts/draft-singer-jp2-01.txt Both are not official and the ietf draft was declined (it's outdated and didn't make it as a rfc). So i don't really see why i should change the current behavior and implement something non standard. Ok, so lest's forget about it ;) Sorry for the time wasted. Mehdi -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5 RC 1 - Article/Tutorial Sponsorship
This one time, at band camp, Andi Gutmans <[EMAIL PROTECTED]> wrote: > There are things beyond articles which need to be > written such as the PHP manual, release notes, NEWS and so on. Ok, what do you need/want written? I assume there are all sorts of topics which still aren't in the PHP manual such as new engine features, XML updates, SimpleXMl and so on (some might already exist). Best to join the [EMAIL PROTECTED] mailing list. Also I suggest ppl on this list who know their work hasn't been documented yet speak up. And if someone already wrote a little bunch of docs but don't want/have the time to come with XML files, he can send it to the documentation list and someone will take care :) didou -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] #26153
Hi Can someone with karma take car of http://bugs.php.net/26153 ? It will also fix the file for Beta 3 :) didou -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: CVS Account Request: yannick
I already work with the french translation team ([EMAIL PROTECTED], [EMAIL PROTECTED], ...) and I'd want a cvs account with the phpdoc-fr karma to commit fixes and changes. Confirmed :) didou -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: CVS Account Request: vrana
Jakub Vrana wrote: Maintaining Czech documentation. If I will find mistake in English documentation, I can send a patch to someone else. Jakub has already helped with the english documentation : http://news.php.net/article.php?group=php.doc&article=969357093 http://news.php.net/article.php?group=php.doc&article=969357092 http://news.php.net/article.php?group=php.doc&article=969357098 didou -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: patch
The patch is missing Nuno :) didou Hi, Here is a patch to output_reset_rewrite_vars because no parameter count was done. Nuno -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] [Fwd: note 39012 added to function.snmpwalk]
Hi ! Just forwarding here in case it was interesting. Have a look here : http://news.php.net/article.php?group=php.notes&article=63539 Mehdi Achour -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Typos in pcntl.c
Hi !
Attached is a patch that will s/singal/signal in the file.
didou
Index: pcntl.c
===
RCS file: /repository/php-src/ext/pcntl/pcntl.c,v
retrieving revision 1.40
diff -u -r1.40 pcntl.c
--- pcntl.c 28 Oct 2003 17:08:18 - 1.40
+++ pcntl.c 23 Jan 2004 00:57:28 -
@@ -520,7 +520,7 @@
php_error_docref(NULL TSRMLS_CC, E_WARNING, "Invalid value for
handle argument specifEied");
}
if (php_signal(signo, (Sigfunc *) Z_LVAL_P(handle), (int)
restart_syscalls) == SIG_ERR) {
- php_error_docref(NULL TSRMLS_CC, E_WARNING, "Error assigning
singal");
+ php_error_docref(NULL TSRMLS_CC, E_WARNING, "Error assigning
signal");
RETURN_FALSE;
}
RETURN_TRUE;
@@ -538,7 +538,7 @@
if (dest_handle) zval_add_ref(dest_handle);
if (php_signal(signo, pcntl_signal_handler, (int) restart_syscalls) ==
SIG_ERR) {
- php_error_docref(NULL TSRMLS_CC, E_WARNING, "Error assigning singal");
+ php_error_docref(NULL TSRMLS_CC, E_WARNING, "Error assigning signal");
RETURN_FALSE;
}
RETURN_TRUE;
@@ -671,7 +671,7 @@
ZVAL_LONG(param, *signal_num);
- /* Call php singal handler - Note that we do not report errors, and we
ignore the return value */
+ /* Call php signal handler - Note that we do not report errors, and we
ignore the return value */
call_user_function(EG(function_table), NULL, *handle, retval, 1,
¶m TSRMLS_CC);
}
/* Clear */
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: CVS Account Request: poz
Vincent Briet wrote: I want to help maintain the French translation of the doc, guest by didou confirmed. didou -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Fwd: Re: dl() problem
Stanislav Malyshev wrote: PJ>> No it is not. And this discussion (sorry) is going to be silly. We PJ>> are not talking about such things but the ability to load a module at PJ>> runtime. Concepts of modules differ. PHP is built, more or less, so that you write in PHP using existing language facilities, and aren't supposed to change the facilities from PHP. That's why dl() is problematic - it violates this principle. PJ>> I want to use an extension in a specific script/part that should not PJ>> be available in other parts. A common usage. Or only for one host but PJ>> not the other? I don't really see a reason why somebody would want to enable GD to one vritual server while denying it to the rest. What's the point in it - you don't save anything? For example, let's take a hosting company (mine). Suppose we decide to buy the last version of IRCG. We'd like to provide it only for some customers (the ones who will pay to have it). Mehdi Achour -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Fwd: Re: dl() problem
Zeev Suraski wrote: At 16:23 11/02/2004, Mehdi Achour wrote: Stanislav Malyshev wrote: PJ>> No it is not. And this discussion (sorry) is going to be silly. We PJ>> are not talking about such things but the ability to load a module at PJ>> runtime. Concepts of modules differ. PHP is built, more or less, so that you write in PHP using existing language facilities, and aren't supposed to change the facilities from PHP. That's why dl() is problematic - it violates this principle. PJ>> I want to use an extension in a specific script/part that should not PJ>> be available in other parts. A common usage. Or only for one host but PJ>> not the other? I don't really see a reason why somebody would want to enable GD to one vritual server while denying it to the rest. What's the point in it - you don't save anything? For example, let's take a hosting company (mine). Suppose we decide to buy the last version of IRCG. We'd like to provide it only for some customers (the ones who will pay to have it). So why not put them on separate servers, or put them through CGI if you don't care about performance? Or maybe implement access restrictions within IRCG? Because we care about performance. Plus, if we want to have the IRCG feature automatically added/deleted for a customer, the two separated servers isn't this good solution. About implementing access restriction for IRCG.. I'm not sure we'd like to hack IRCG for each new version, or hack each extension that we provide this way (ircg is just an exemple) Either way, what Andi said stands - fixing dl() means adding bloat, fixing and maintaining lots of bits and pieces of code in many different places, and it's something that we don't want to do, and said numerous times in the past that we have no intention of doing. In that sense, dl() is deprecated. I'm okay with what Andi said, but maybe there's a better way to deprecate dl() (i.e. provides some replacements). For example, provide some htaccess directive that will be : php_value extension_definition /path/to/some/file.ini this file would contain the extension=foo; part of php.ini. I don't know if it's possible btw.. Mehdi Achour PS : I don't have the skills to provide this replacement, so please avoid answering : "provide a patch or shut up". I was just giving my point of view :) -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Fwd: Re: dl() problem
Derick Rethans wrote: On Wed, 11 Feb 2004, Ilia Alshanetsky wrote: On February 11, 2004 10:00 am, Mehdi Achour wrote: Because we care about performance. Plus, if we want to have the IRCG feature automatically added/deleted for a customer, the two separated servers isn't this good solution. About implementing access restriction for IRCG.. I'm not sure we'd like to hack IRCG for each new version, or hack each extension that we provide this way (ircg is just an exemple) You could always disable a critical function of the IRCG extension, such as the connection initialization function. This way you can effectively turn off the extension for some virtual hosts. disable_functions only works from php.ini AFAIK... so this doesn't work :) Plus, even if it works, keep in mind that IRCG is just an exemple. Should we have to disable all the functions of an extension if each function is "critical" ? Mehdi Achour -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
