Re: [PHP-DOC] Re: Setting up a website for the phpdoc team
Derick Rethans wrote: On Sat, 31 Jan 2004, Mehdi Achour wrote: a big big big +1 here :) It will be great to allow some ssh access for some active persons of the doc team. Having the doc.php.net on another (isolated) machine will also make happy systems@ IMHO :) Why do you need ssh access? Because you always say that you're too busy ? :) It's also handy for webmastering to have the ability of quickly updating the site. For the last problem with bugs.php.net, all I was able to do was sitting there at three a.m. in the morning fighting my sleep to see if the errors were fixed. If only I was able to do something like : ssh bugs.php.net cd /var/www/ cvs up -PAd .. :) What's the point of giving ssh access ? Do we always have to wait for Mr X to update the docs, the sites, ... Why ? Give us some responsabilities :) didou
[PHP-DOC] Re: wrong translation on ref.java.php (french)
Bonjour Arnaud, Thank you for reporting the bug. Next time, can you please fill in a bug report a http://bugs.php.net/ or send your complaint to [EMAIL PROTECTED] ? :) didou Arnaud wrote: Hi I have seen a wrong translation of the expression in-process at the following URL: http://fr.php.net/manual/fr/ref.java.php (french version) It's translated in french with inter-process but it should be something like intra-process. thanks arnaud
[PHP-DOC] cvs: phpdoc /en/reference/ncurses/functions ncurses-border.xml ncurses-getmaxyx.xml ncurses-init.xml ncurses-newwin.xml ncurses-wborder.xml
nlopess Sun Feb 1 07:25:40 2004 EDT Modified files: /phpdoc/en/reference/ncurses/functions ncurses-border.xml ncurses-getmaxyx.xml ncurses-init.xml ncurses-newwin.xml ncurses-wborder.xml Log: new documentation by David Costa http://cvs.php.net/diff.php/phpdoc/en/reference/ncurses/functions/ncurses-border.xml?r1=1.3r2=1.4ty=u Index: phpdoc/en/reference/ncurses/functions/ncurses-border.xml diff -u phpdoc/en/reference/ncurses/functions/ncurses-border.xml:1.3 phpdoc/en/reference/ncurses/functions/ncurses-border.xml:1.4 --- phpdoc/en/reference/ncurses/functions/ncurses-border.xml:1.3Fri Dec 6 21:13:37 2002 +++ phpdoc/en/reference/ncurses/functions/ncurses-border.xmlSun Feb 1 07:25:39 2004 @@ -1,28 +1,37 @@ ?xml version=1.0 encoding=iso-8859-1? -!-- $Revision: 1.3 $ -- +!-- $Revision: 1.4 $ -- !-- splitted from ./en/functions/ncurses.xml, last change in rev 1.1 -- refentry id=function.ncurses-border refnamediv refnamencurses_border/refname -refpurposeDraw a border around the screen using attributed characters /refpurpose +refpurposeDraw a border around the screen using attributed characters/refpurpose /refnamediv refsect1 titleDescription/title - methodsynopsis - typeint/typemethodnamencurses_border/methodname - methodparamtypeint/typeparameterleft/parameter/methodparam - methodparamtypeint/typeparameterright/parameter/methodparam - methodparamtypeint/typeparametertop/parameter/methodparam - methodparamtypeint/typeparameterbottom/parameter/methodparam - methodparamtypeint/typeparametertl_corner/parameter/methodparam - methodparamtypeint/typeparametertr_corner/parameter/methodparam - methodparamtypeint/typeparameterbl_corner/parameter/methodparam - methodparamtypeint/typeparameterbr_corner/parameter/methodparam - /methodsynopsis - warn.experimental.func; -para - warn.undocumented.func; -/para +methodsynopsis + typeint/typemethodnamencurses_border/methodname + methodparamtypeint/typeparameterleft/parameter/methodparam + methodparamtypeint/typeparameterright/parameter/methodparam + methodparamtypeint/typeparametertop/parameter/methodparam + methodparamtypeint/typeparameterbottom/parameter/methodparam + methodparamtypeint/typeparametertl_corner/parameter/methodparam + methodparamtypeint/typeparametertr_corner/parameter/methodparam + methodparamtypeint/typeparameterbl_corner/parameter/methodparam + methodparamtypeint/typeparameterbr_corner/parameter/methodparam +/methodsynopsis +warn.experimental.func; +simpara + functionncurses_border/function draws the specified lines and + corners around the main window. Each parameter expects 0 to draw + a line and 1 to skip it. The corners are top left, top right, + bottom left and bottom right. +/simpara +simpara + Use functionncurses_wborder/function for borders around subwindows! +/simpara +simpara + See also functionncurses_wborder/function. +/simpara /refsect1 /refentry http://cvs.php.net/diff.php/phpdoc/en/reference/ncurses/functions/ncurses-getmaxyx.xml?r1=1.1r2=1.2ty=u Index: phpdoc/en/reference/ncurses/functions/ncurses-getmaxyx.xml diff -u phpdoc/en/reference/ncurses/functions/ncurses-getmaxyx.xml:1.1 phpdoc/en/reference/ncurses/functions/ncurses-getmaxyx.xml:1.2 --- phpdoc/en/reference/ncurses/functions/ncurses-getmaxyx.xml:1.1 Wed Jun 4 17:34:18 2003 +++ phpdoc/en/reference/ncurses/functions/ncurses-getmaxyx.xml Sun Feb 1 07:25:39 2004 @@ -1,12 +1,9 @@ -?xml version='1.0' encoding='iso-8859-1'? -!-- $Revision: 1.1 $ -- -!-- Generated by xml_proto.php v2.0. Found in /scripts directory of phpdoc. -- +?xml version=1.0 encoding=iso-8859-1? +!-- $Revision: 1.2 $ -- refentry id=function.ncurses-getmaxyx refnamediv refnamencurses_getmaxyx/refname -refpurpose - Returns the size of a window -/refpurpose +refpurposeReturns the size of a window/refpurpose /refnamediv refsect1 titleDescription/title @@ -16,9 +13,15 @@ methodparamtypeint/typeparameteramp;y/parameter/methodparam methodparamtypeint/typeparameteramp;x/parameter/methodparam /methodsynopsis -para - warn.undocumented.func; -/para +warn.experimental.func; +simpara + functionncurses_getmaxyx/function puts the horizontal and + vertical size of the window parameterwindow/parameter + into the given variables parameteramp;y/parameter and + parameteramp;x/parameter. Variables must be passed + as reference, so they are updated when the user changes terminal + size. +/simpara /refsect1 /refentry
Re: [PHP-DOC] New docs: ncurses-border ncurses-getmaxyx ncurses-newwin ncurses-wborder
Hi David, Your docs are ok and I've have already commited them. Just some notes: * I think you didn't run 'make test' because you had two XML errors (just small typos) * You re-made the docs instead of opening the original and adding your documentation, resulting in loosing tags (split comment). * You missed the VI comments (didou already noted this) * You should have had the warn.experimental.func; entity to them, because this extension is still experimental (they were in the original docs, but since yo have re-made them...) Just keep your good work! Nuno - Original Message - Hello Everyone, see attached 5 new docs for the ncurses orphans group. Comments ? Suggestions ? let me know :) Regards David Costa
Re: [PHP-DOC] Re: Setting up a website for the phpdoc team
Ah, all right... Understandable. Then the question is still up to systems@ whether there is some willingness to set up a machine/vhost, or we will better do with opening a vhost on some new donated machine offered by a docteam member? The added benefit of the latter option would be that we will not be reliant on the systems@ group for configuration changes, but the site could still be registered as doc.php.net, and we can be more flexible with its development and setup... The more I think about it, the more I like this option :) I don't. You want this to be an official PHP thing, then it should be hosted on an official machine. We can't have each subproject being run by somebody else (if only for security reasons). That server would only need to cvs checkout data anonymously, and it should be reproduceable on any other machine with the contents stored in cvs.php.net (the modules I have mentioned before, plus the new docweb module, plus a lot of generated data produced by the scripts from the sources anonymously checked out). Since it would only host data already publicly available (though in a more organized form), I don't know what is the problem with it... Some PHP.net subdomains already hosted on 'foreign' servers: - wiki.gtk.php.net - vancouver.php.net - sydney.ug.php.net - every PHP.net mirror site The PHP.net mirror sites are considered to be 'official' as far as I can see, and they seem to be harder to control then doc.php.net would be on a non-systems@ operated machine. The operators of doc.php.net would be those who work closely with the docteam, so they are here to contact and act with if something need to be done. It might be true however, that most of the members of the docteam are not experienced server operators (including myself), and you might think that it could be a prestige problem for php.net if someone breaks into the server and uses it for some crude goal... That could happen however with any of the above servers, since the administration skills of those operating the above servers have not been tested AFAIK. I would like to point once more that only data available from CVS, and data generated from those files with scripts available from CVS will be hosted on that machine (given that we are not going to have our own bugs reincarnation, which I take for granted for now, as I have stated before). The actual problem with systems@ is that this group is 'not too responsive'. I have seen requests for cvs module and mailing list creations, and other stuff come and pass without any action taken... I have been asking for months that an 'has_sqlite' column should be added to the mirror registration table, but noone cares to add it... It would be hard to prove that it would be a complicated task to add this column... Still, my repeated requests were dismissed without an answer. I hardly beleive that you don't understand why we would not like to put a new vhost on the shoulders of [EMAIL PROTECTED] In an ideal world, people at systems@ would be responsive, and would do what you ask them, or reply with a letter that you are asking for something silly or too complex. I can understand that everyone has his own work, and this is a volunteer task, everybody is volunteering here. Still I think that it is wrong not to admit that there are problems with the processes going through systems@, and that it often takes very long time to make any change... So while respecting the work done by the guys at systems@, to rapidly develop this new site, the slow pace of systems@ does not seem to be supportive... Goba
Re: [PHP-DOC] Setting up a website for the phpdoc team
Sounds good, let's do it! I'm guessing this project will require a
CVS module and perhaps it can be named phpdoc-web
As far as I have seen 'php' is not included in the CVS module and
mailing list names, just when particularly needed ('php-src').
What about php-news-web, php-master-web, phpweb Gabor ? :)
I'd like to name it php-doc-web for consistency with the other websites
names.
/me nods yes
I don't care :) My impression was that there is a general move-away from
names containing 'php', since this is obvious... This is why internals@
doc-$lang@ and likely named mailing lists have been created... I just
would like to adhere to the current principles here...
Just to provide an interesting addition, Zeev posted a mail in May 2000
about some mailing list changes [1], and it was mentioned, that phpdoc
will be renamed to php-doc for consistency 'soon'. This had not happened
yet. I guess if any rename would be done, then it would be
[EMAIL PROTECTED] instead (conforming to the other
[EMAIL PROTECTED] addresses)...
[1] http://news.php.net/article.php?group=php.announcearticle=21
Goba
[PHP-DOC] cvs: phpdoc /en/reference/strings/functions ord.xml
rioter Sun Feb 1 09:12:11 2004 EDT
Modified files:
/phpdoc/en/reference/strings/functions ord.xml
Log:
added the $str var to the example
http://cvs.php.net/diff.php/phpdoc/en/reference/strings/functions/ord.xml?r1=1.3r2=1.4ty=u
Index: phpdoc/en/reference/strings/functions/ord.xml
diff -u phpdoc/en/reference/strings/functions/ord.xml:1.3
phpdoc/en/reference/strings/functions/ord.xml:1.4
--- phpdoc/en/reference/strings/functions/ord.xml:1.3 Fri May 30 12:47:59 2003
+++ phpdoc/en/reference/strings/functions/ord.xml Sun Feb 1 09:12:10 2004
@@ -1,5 +1,5 @@
?xml version=1.0 encoding=iso-8859-1?
-!-- $Revision: 1.3 $ --
+!-- $Revision: 1.4 $ --
!-- splitted from ./en/functions/strings.xml, last change in rev 1.2 --
refentry id=function.ord
refnamediv
@@ -21,7 +21,9 @@
programlisting role=php
![CDATA[
?php
-if (ord($str) == 10) {
+$str = \n;
+if (ord($str) == 10)
+{
echo The first character of \$str is a line feed.\n;
}
?
[PHP-DOC] Re: cvs: phpdoc /en/reference/strings/functions ord.xml
Jared Wyles wrote:
rioter Sun Feb 1 09:12:11 2004 EDT
Modified files:
/phpdoc/en/reference/strings/functions ord.xml
Log:
added the $str var to the example
refnamediv
@@ -21,7 +21,9 @@
programlisting role=php
![CDATA[
?php
-if (ord($str) == 10) {
+$str = \n;
+if (ord($str) == 10)
+{
No need to break the coding standards here. tsss, go back to sleep rioter :p
didou
Re: [PHP-DOC] New docs: ncurses-border ncurses-getmaxyx ncurses-newwin ncurses-wborder
On Feb 1, 2004, at 1:34 PM, Nuno Lopes wrote: Hi David, Your docs are ok and I've have already commited them. Thanks a lot :D Just some notes: * I think you didn't run 'make test' because you had two XML errors (just small typos) * You re-made the docs instead of opening the original and adding your documentation, resulting in loosing tags (split comment). Aheam, without a CVS account I am fairly limited at the moment. Example: I just finished translating to Italian the cyrus functions and, as the new maintainer for reference/datetime I could easily open both the English and Italian version with a CVS account. Running diff and others procedures via http://cvs.php.net/ is not I requested the account on the 11 Jan sent about 3 reminds but so far no luck. * You missed the VI comments (didou already noted this) Sigh.. * You should have had the warn.experimental.func; entity to them, because this extension is still experimental (they were in the original docs, but since yo have re-made them...) Where do I get download the original docs without a CVS account ? Just keep your good work! Thanks a lot !! not that good yet but I am getting better. I am sorry for the mistakes. Cheers David Costa Nuno - Original Message - Hello Everyone, see attached 5 new docs for the ncurses orphans group. Comments ? Suggestions ? let me know :) Regards David Costa
[PHP-DOC] cvs: phpdoc /en/reference/strings/functions ord.xml
didou Sun Feb 1 09:24:40 2004 EDT
Modified files:
/phpdoc/en/reference/strings/functions ord.xml
Log:
15:20 rioter what coding standardS?
15:22 * rioter crys
# :)))
http://cvs.php.net/diff.php/phpdoc/en/reference/strings/functions/ord.xml?r1=1.4r2=1.5ty=u
Index: phpdoc/en/reference/strings/functions/ord.xml
diff -u phpdoc/en/reference/strings/functions/ord.xml:1.4
phpdoc/en/reference/strings/functions/ord.xml:1.5
--- phpdoc/en/reference/strings/functions/ord.xml:1.4 Sun Feb 1 09:12:10 2004
+++ phpdoc/en/reference/strings/functions/ord.xml Sun Feb 1 09:24:39 2004
@@ -1,5 +1,5 @@
?xml version=1.0 encoding=iso-8859-1?
-!-- $Revision: 1.4 $ --
+!-- $Revision: 1.5 $ --
!-- splitted from ./en/functions/strings.xml, last change in rev 1.2 --
refentry id=function.ord
refnamediv
@@ -22,8 +22,7 @@
![CDATA[
?php
$str = \n;
-if (ord($str) == 10)
-{
+if (ord($str) == 10) {
echo The first character of \$str is a line feed.\n;
}
?
Re: [PHP-DOC] Re: Setting up a website for the phpdoc team
On Feb 1, 2004, at 2:59 PM, Gabor Hojtsy wrote: I don't. You want this to be an official PHP thing, then it should be hosted on an official machine. We can't have each subproject being run by somebody else (if only for security reasons). That server would only need to cvs checkout data anonymously, and it should be reproduceable on any other machine with the contents stored in cvs.php.net (the modules I have mentioned before, plus the new docweb module, plus a lot of generated data produced by the scripts from the sources anonymously checked out). Since it would only host data already publicly available (though in a more organized form), I don't know what is the problem with it... Some PHP.net subdomains already hosted on 'foreign' servers: - wiki.gtk.php.net - vancouver.php.net - sydney.ug.php.net - every PHP.net mirror site The PHP.net mirror sites are considered to be 'official' as far as I can see, and they seem to be harder to control then doc.php.net would be on a non-systems@ operated machine. The operators of doc.php.net would be those who work closely with the docteam, so they are here to contact and act with if something need to be done. It might be true however, that most of the members of the docteam are not experienced server operators (including myself), and you might think that it could be a prestige problem for php.net if someone breaks into the server and uses it for some crude goal... That could happen however with any of the above servers, since the administration skills of those operating the above servers have not been tested AFAIK. I would like to point once more that only data available from CVS, and data generated from those files with scripts available from CVS will be hosted on that machine (given that we are not going to have our own bugs reincarnation, which I take for granted for now, as I have stated before). Someone among the docteam could have the technical skills to operate the server, perhaps some of the senior/leaders. Just thinking loud, but perhaps system needs some hardware donation to keep up with a new server. If that is the case I could help. Perhaps a separate machine or separate hard disk... I would be glad to help. In alternative the new external server could have some security supervision by systems. Regards David Costa
Re: [PHP-DOC] New docs: ncurses-border ncurses-getmaxyx ncurses-newwin ncurses-wborder
Aheam, without a CVS account I am fairly limited at the moment. Example: I just finished translating to Italian the cyrus functions and, as the new maintainer for reference/datetime I could easily open both the English and Italian version with a CVS account. Running diff and others procedures via http://cvs.php.net/ is not I requested the account on the 11 Jan sent about 3 reminds but so far no luck. You may do a checkout using the read-only username, cvsread (more info: http://php.net/anoncvs.php). Getting a CVS account is a process that is a bit slow. I've waited 2 months for mine, so... I've checked in the master server and you have two requests for a cvs account there. Nuno
Re: [PHP-DOC] Re: Setting up a website for the phpdoc team
I don't. You want this to be an official PHP thing, then it should be hosted on an official machine. We can't have each subproject being run by somebody else (if only for security reasons). As much as I'd like to see this project expedited, as well, I agree with Derick, here. It would be nice to have an independent server, but we can't risk the possibility of its admins becoming rogue, and dirtying the php.net domain. umh but if there are 4-5 administrators the possibility that they *all* join the dark force is kind of limited isn't it ? If you have the new box protected by lids (http://www.lids.org/) and regularly monitored updated it should be fairly secure. I am sure that among the docs team there are at least few expert server administrators. I am not sure that there are expert server admins among the currently active members of the docteam But we might also be able to organize this new vhost by putting this all up on the server of some already working PHP.net mirror site to a different vhost (Damien [fr.php.net] comes to mind, and Cece [hu.php.net]). Since these servers are already part of some trusted group (official mirror sites), it might be easier for systems@ to agree that doc.php.net will be set up on one of these machines. Far fetched, maybe.. but systems should be controlled by the systems team. system could have access to the new machine and run some routine security checks. Or someone could donate a new box/hard disk to system if that helps. Of course systems should be available to run the necessary changes and positive to the idea. If I would be a real member of systems@ I would not be keen on doing security checks on a server, where I don't know how things are set up, and I know anyone could change the settings anytime without myself knowing about it... This makes looking for the server a lot harder, and a lot more time consuming IMHO. Goba
Re: [PHP-DOC] Re: Setting up a website for the phpdoc team
On Feb 1, 2004, at 4:48 PM, Gabor Hojtsy wrote: As much as I'd like to see this project expedited, as well, I agree with Derick, here. It would be nice to have an independent server, but we can't risk the possibility of its admins becoming rogue, and dirtying the php.net domain. umh but if there are 4-5 administrators the possibility that they *all* join the dark force is kind of limited isn't it ? If you have the new box protected by lids (http://www.lids.org/) and regularly monitored updated it should be fairly secure. I am sure that among the docs team there are at least few expert server administrators. I am not sure that there are expert server admins among the currently active members of the docteam But we might also be able to organize this new vhost by putting this all up on the server of some already working PHP.net mirror site to a different vhost (Damien comes to mind, and Cece [hu.php.net]). Since these servers are already part of some trusted group (official mirror sites), it might be easier for systems@ to agree that doc.php.net will be set up on one of these machines. Great idea, perhaps you could drop a line to damien and cece and see if they like the idea or need anything for the extra vhost. (oops you are already copying them =) ). How I can help: donation of an Hard disk (money, so they could buy something new and as they like) RAM, other hardware the box, or the equivalent in money et al. If they need something of course. Far fetched, maybe.. but systems should be controlled by the systems team. system could have access to the new machine and run some routine security checks. Or someone could donate a new box/hard disk to system if that helps. Of course systems should be available to run the necessary changes and positive to the idea. If I would be a real member of systems@ I would not be keen on doing security checks on a server, where I don't know how things are set up, and I know anyone could change the settings anytime without myself knowing about it... This makes looking for the server a lot harder, and a lot more time consuming IMHO. You are right. From your previous email I got the impressions that they are quite busy with the currently daily workload and a routine security check will be an extra burden. fr.php.net is running Debian. Security wise should be quite simple to maintain and they do have both the experience and hopefully the time to handle an extra vhost. Regards David Costa
[PHP-DOC] cvs: phpdoc /en/reference/sybase/functions sybase-set-message-handler.xml
nlopess Sun Feb 1 10:49:47 2004 EDT Modified files: /phpdoc/en/reference/sybase/functions sybase-set-message-handler.xml Log: proto fix. noticed by a user note http://cvs.php.net/diff.php/phpdoc/en/reference/sybase/functions/sybase-set-message-handler.xml?r1=1.6r2=1.7ty=u Index: phpdoc/en/reference/sybase/functions/sybase-set-message-handler.xml diff -u phpdoc/en/reference/sybase/functions/sybase-set-message-handler.xml:1.6 phpdoc/en/reference/sybase/functions/sybase-set-message-handler.xml:1.7 --- phpdoc/en/reference/sybase/functions/sybase-set-message-handler.xml:1.6 Thu Jan 15 07:43:32 2004 +++ phpdoc/en/reference/sybase/functions/sybase-set-message-handler.xml Sun Feb 1 10:49:47 2004 @@ -1,5 +1,5 @@ ?xml version=1.0 encoding=iso-8859-1? -!-- $Revision: 1.6 $ -- +!-- $Revision: 1.7 $ -- refentry id=function.sybase-set-message-handler refnamediv refnamesybase_set_message_handler/refname @@ -10,6 +10,7 @@ methodsynopsis typebool/typemethodnamesybase_set_message_handler/methodname methodparamtypecallback/typeparameterhandler/parameter/methodparam + methodparam choice=opttyperesource/typeparameterconnection/parameter/methodparam /methodsynopsis para functionsybase_set_message_handler/function sets a user function to
[PHP-DOC] cvs: phpdoc /en/reference/sybase/functions sybase-set-message-handler.xml
nlopess Sun Feb 1 10:55:06 2004 EDT Modified files: /phpdoc/en/reference/sybase/functions sybase-set-message-handler.xml Log: the connection parameter was added only in 4.3.5 http://cvs.php.net/diff.php/phpdoc/en/reference/sybase/functions/sybase-set-message-handler.xml?r1=1.7r2=1.8ty=u Index: phpdoc/en/reference/sybase/functions/sybase-set-message-handler.xml diff -u phpdoc/en/reference/sybase/functions/sybase-set-message-handler.xml:1.7 phpdoc/en/reference/sybase/functions/sybase-set-message-handler.xml:1.8 --- phpdoc/en/reference/sybase/functions/sybase-set-message-handler.xml:1.7 Sun Feb 1 10:49:47 2004 +++ phpdoc/en/reference/sybase/functions/sybase-set-message-handler.xml Sun Feb 1 10:55:06 2004 @@ -1,5 +1,5 @@ ?xml version=1.0 encoding=iso-8859-1? -!-- $Revision: 1.7 $ -- +!-- $Revision: 1.8 $ -- refentry id=function.sybase-set-message-handler refnamediv refnamesybase_set_message_handler/refname @@ -27,6 +27,11 @@ para return.success; /para +note + para + The parameterconnection/parameter was added in PHP 4.3.5. + /para +/note para example titlefunctionsybase_set_message_handler/function callback function/title
Re: [PHP-DOC] Re: Setting up a website for the phpdoc team
Hi all, On Feb 1, 2004, at 4:48 PM, Gabor Hojtsy wrote: As much as I'd like to see this project expedited, as well, I agree with Derick, here. It would be nice to have an independent server, but we can't risk the possibility of its admins becoming rogue, and dirtying the php.net domain. umh but if there are 4-5 administrators the possibility that they *all* join the dark force is kind of limited isn't it ? If you have the new box protected by lids (http://www.lids.org/) and regularly monitored updated it should be fairly secure. I am sure that among the docs team there are at least few expert server administrators. I am not sure that there are expert server admins among the currently active members of the docteam But we might also be able to organize this new vhost by putting this all up on the server of some already working PHP.net mirror site to a different vhost (Damien comes to mind, and Cece [hu.php.net]). Since these servers are already part of some trusted group (official mirror sites), it might be easier for systems@ to agree that doc.php.net will be set up on one of these machines. Great idea, perhaps you could drop a line to damien and cece and see if they like the idea or need anything for the extra vhost. (oops you are already copying them =) ). How I can help: donation of an Hard disk (money, so they could buy something new and as they like) RAM, other hardware the box, or the equivalent in money et al. If they need something of course. Lemme talk for Damien as we work in the same hosting :) fr.php.net is on a server that already hosts a lot of sites. I'm not sure it will be a great idea to host doc.php.net there as it will require more bandwidth (for cvs updates) and more cpu (for building, parsing, ..) As for the expert admin, we have at least one, Guillaume (cc'ed). He's one of my coworkers and I have discussed the idea of having a website for the phpdoc team with him before starting this thread. I'm sure that he'll be okay to maintain the server if needed. I'll have a discussion with my boss tomorrow to see if my company is okay to provide a dedicated server, or a vserver for our needs. I'll keep you updated. Far fetched, maybe.. but systems should be controlled by the systems team. system could have access to the new machine and run some routine security checks. Or someone could donate a new box/hard disk to system if that helps. Of course systems should be available to run the necessary changes and positive to the idea. If I would be a real member of systems@ I would not be keen on doing security checks on a server, where I don't know how things are set up, and I know anyone could change the settings anytime without myself knowing about it... This makes looking for the server a lot harder, and a lot more time consuming IMHO. You are right. From your previous email I got the impressions that they are quite busy with the currently daily workload and a routine security check will be an extra burden. fr.php.net is running Debian. Security wise should be quite simple to maintain and they do have both the experience and hopefully the time to handle an extra vhost. yep, Debian is our favorite distro, and we have a good experience of it. I'm sharing Gabor arguments (systems@ does a good job, but sometimes a request stay unreplyed, or are replyed after a long time). I really want to have some active phpdoc'ers maintaining the doc.php.net system. I'll do my best tomorrow to bring a nexen-based solution. Stay tuned ! didou
[PHP-DOC] cvs: livedocs / build.sh
momoSun Feb 1 13:25:28 2004 EDT
Modified files:
/livedocs build.sh
Log:
2. the correct fix for relative paths
http://cvs.php.net/diff.php/livedocs/build.sh?r1=1.18r2=1.19ty=u
Index: livedocs/build.sh
diff -u livedocs/build.sh:1.18 livedocs/build.sh:1.19
--- livedocs/build.sh:1.18 Fri Jan 30 00:49:15 2004
+++ livedocs/build.sh Sun Feb 1 13:25:28 2004
@@ -30,7 +30,6 @@
#xmllint --format ${GENDIR}/toc-ugly.xml ${GENDIR}/toc.xml
${PHP} ${LIVEDOCSFORPHP}/mktoc.php ${GENDIRFORPHP}/toc-ugly.xml
${GENDIR}/toc-insert.sql
- cd $curpath
fi
echo -n Making index for $i:
@@ -45,6 +44,7 @@
# make search cache database
mv ${GENDIR}/livedoc-cache-idx.$i.sqlite ${OUTPUTDIR}/$i/
chmod 0666 ${OUTPUTDIR}/$i/livedoc-cache-idx.$i.sqlite
+ cd $curpath
done;
echo -n End:
[PHP-DOC] cvs: phpdoc /en/reference/sybase/functions sybase-set-message-handler.xml
kennyt Sun Feb 1 17:07:15 2004 EDT Modified files: /phpdoc/en/reference/sybase/functions sybase-set-message-handler.xml Log: paramfoo/param to paramfoo/param parameter! :-) http://cvs.php.net/diff.php/phpdoc/en/reference/sybase/functions/sybase-set-message-handler.xml?r1=1.8r2=1.9ty=u Index: phpdoc/en/reference/sybase/functions/sybase-set-message-handler.xml diff -u phpdoc/en/reference/sybase/functions/sybase-set-message-handler.xml:1.8 phpdoc/en/reference/sybase/functions/sybase-set-message-handler.xml:1.9 --- phpdoc/en/reference/sybase/functions/sybase-set-message-handler.xml:1.8 Sun Feb 1 10:55:06 2004 +++ phpdoc/en/reference/sybase/functions/sybase-set-message-handler.xml Sun Feb 1 17:07:15 2004 @@ -1,5 +1,5 @@ ?xml version=1.0 encoding=iso-8859-1? -!-- $Revision: 1.8 $ -- +!-- $Revision: 1.9 $ -- refentry id=function.sybase-set-message-handler refnamediv refnamesybase_set_message_handler/refname @@ -29,7 +29,8 @@ /para note para - The parameterconnection/parameter was added in PHP 4.3.5. + The parameterconnection/parameter parameter was added in + PHP 4.3.5. /para /note para
[PHP-DOC] Smarty-2.6.1
Hello,
I have downloaded Smarty-2.6.1.
Very good templates. But using it I have found one bug (I think
that's bug) with {html_table tr_attr=...}
For example this code does not change the colors of row in table.
index.php:
--
require('Smarty.class.php');
$smarty = new Smarty;
$smarty-assign('data',array(1,2,3,4,5,6,7,8,9));
$smarty-assign('tr',array('bgcolor=#ee','bgcolor=#dd'));
$smarty-display('index.tpl');
index.tpl:
--
{html_table loop=$data cols=4 tr_attr=$tr}
But in Smarty-2.5.0 that was working. When I changed new file with old
(from v.2.5.0) it began working.
--
Best regards,
Igor. mailto:[EMAIL PROTECTED]
