Hello PHP dev team!
First of all, many thanks for a great job!
I'm writing to you about a CVS account to help out with the maintaining and completion
of translating the manual in to Swedish. It's quite a big job, and I intend to help
out as best as I can.
I've been in contact with Per Gustafss
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.p
On 19 November 2003 06:12, Andi Gutmans contributed these pearls of wisdom:
> Just a warning.
> I commited your patch. Not sure about the naming but it's the
> status quo for now :)
> Andi
>
>> + case E_STRICT:
>> + error_type_str = "Strict
>> S
From: Michael Sisolak
> It looks like most of these changes are PHP5 specific (either the code
> changes like many of the free()s were already in PHP4, or involve
> things like the global constants cache which don't exist there) which I
> haven't looked at enough to comment on. The only question
On Fri, Nov 14, 2003 at 06:19:16AM -0800, terry chay wrote:
> Jani,
>
> Yes, this happens when I create an RPM, however this is still a bug.
> Here is RPM's build process:
> 1) read spec file and look in /usr/src/redhat/SOURCES for files
> necessary to build RPM
> 2) configure and compile
From: Edin Kadribasic
> Some major win32 build issues that need to be dealt with before RC1:
>
> 1. php4 -> php5 rename
> 2. bundling of libxml2 and dealing with linking issues (static vs.
> dynamic)
> 3. getting rid of external dll dependancies (iconv.dll atm) which is
> related to issue (2)
Too
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Wednesday 19 November 2003 13:38, Rob Richards wrote:
> All but the iconv linking worked, though to export the libxml2 symbols we
> would need a def file or include all its headers, otherwise only a subset
> get exported which a few functions were
From: Edin Kadribasic
> Do you think you can maintain PHP's binary of libxml that suits our needs
> including the .def file.
Yes, this shouldnt too difficult once I can get the environment setup for
the libxml/libxslt release builds.
> Does any xml we use require libxml2 to be compiled with icon
I've been using static builds of iconv and libxml2 for quite some time. Do
you need the .dsp's?
Zeev
At 14:38 19/11/2003, Rob Richards wrote:
From: Edin Kadribasic
> Some major win32 build issues that need to be dealt with before RC1:
>
> 1. php4 -> php5 rename
> 2. bundling of libxml2 and dea
Hi,
Even though this is documented, it is strange behaviour: If the from
parameter to substr() is at, or past, the end of the input string, the
function returns false.
The function is documented as
string substr ( string string, int start [, int length])
IMHO substr() should either
1) be change
From: Zeev Suraski
> I've been using static builds of iconv and libxml2 for quite some time.
Do
> you need the .dsp's?
Thanks, but other than the iconv question, libxml is the easy part in all of
this, unless of course you already have iconv being exported from libxml in
the dsp.
I believe Edin
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi
I did a quick search in the manual and found a bunch of deprecated functions..
Here are some of them:
mysql_db_query
mysql_listtables
mysql_createdb
mysql_dropdb
mysql_selectdb
mysql_listfields
... and a bunch of other aliases.
call_user_method
c
[smarty] french translation of the documentation.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[smarty] french translation of the documentation.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On 19 Nov 2003 at 0:00, Andi Gutmans wrote:
> Hey,
>
> I added an E_STRICT error level today which purists can use to
make sure
> that there scripts are using the latest and greatest suggested
method of
> coding (according to what we decide).
> Ideas are things like:
> a) Not using var for me
At 17:20 19/11/2003, Ferdinand Beyer wrote:
On 19 Nov 2003 at 0:00, Andi Gutmans wrote:
> Hey,
>
> I added an E_STRICT error level today which purists can use to
make sure
> that there scripts are using the latest and greatest suggested
method of
> coding (according to what we decide).
> Ideas are
Attached file, implements validate_file(), which implements a php space syntax
check for PHP scripts. It returns a boolean true/false value indicating
whether the script has parse errors or not. Essentially a "php -l" from
within PHP.
strip_file() is added for completion (might as well :) ) and
Hi,
On 19 Nov 2003, at 17:24, Ilia Alshanetsky wrote:
Any comments?
I find that useful for something I am writing right now and I was about
to
propose that myself :). I'd go for php_check_syntax() or at least
file_validate() and php_strip_whitespace() or at least
file_strip_whitespace(), but that'
Andi Gutmans wrote:
At 07:55 PM 11/18/2003 -0500, Mike Robinson wrote:
Ilia Alshanetsky wrote:
> On a related note, since a major PHP version is now being
> released, perhaps it is the time to finally remove old
> deprecated functionality that in many cases deprecated for
> years. I propose that
On Nov 19, 2003, at 12:59 PM, Derek Ford wrote:
Andi Gutmans wrote:
About the deprecation, I think it's OK to have a mode where
deprecated functionality doesn't work, but we should definitely leave
it in for now to allow people to make an easier transition. Maybe the
best solution is to allow
On Wed, 19 Nov 2003, George Schlossnagle wrote:
>
>On Nov 19, 2003, at 12:59 PM, Derek Ford wrote:
>
>> Andi Gutmans wrote:
>>
>>>
>>> About the deprecation, I think it's OK to have a mode where
>>> deprecated functionality doesn't work, but we should definitely leave
>>> it in for now to allow
At 11:07 AM 11/19/2003 +, Ford, Mike [LSS] wrote:
On 19 November 2003 06:12, Andi Gutmans contributed these pearls of wisdom:
> Just a warning.
> I commited your patch. Not sure about the naming but it's the
> status quo for now :)
> Andi
>
>> + case E_STRIC
Not sure if/how this should be changed.
Isn't it a mistake to give a start position at the end or beyond the
string? In this case, doesn't it make sense to return false?
Andi
At 02:39 PM 11/19/2003 +0100, Morten Poulsen wrote:
Hi,
Even though this is documented, it is strange behaviour: If the
I think it's a very bad idea to start copying lexer code into basic_functions.c
I don't have time to look into it but there must be a cleaner way of doing it.
Andi
At 11:24 AM 11/19/2003 -0500, Ilia Alshanetsky wrote:
Attached file, implements validate_file(), which implements a php space
syntax
At 05:30 PM 11/19/2003 +0100, Jan Lehnardt wrote:
Hi,
On 19 Nov 2003, at 17:24, Ilia Alshanetsky wrote:
Any comments?
I find that useful for something I am writing right now and I was about to
propose that myself :). I'd go for php_check_syntax() or at least
file_validate() and php_strip_whitespace
At 11:53 AM 11/19/2003 -0500, George Schlossnagle wrote:
I agree with --disable-deprecated, it seems to be the best option. Do you
think it would be relevant to have a php.ini option for this?
What's the point of deprecating things if you never remove them? Seems
like an empty threat. And --di
On November 19, 2003 01:33 pm, Andi Gutmans wrote:
> If we're talking about naming the how about script_*?
script_* is good, I have no naming preference. I am more interested to know
whether this functionality is something we need or not...
Ilia
--
PHP Internals - PHP Runtime Development Maili
Yes, this is definitely a problem. Today, when possible, we lowercase the
class at compile-time so that we save time during execution. Supporting
this will lead to a small slow down.
I tend to agree that __autoload() should support this but I'm not sure if
we should change everything to run-time
On Nov 19, 2003, at 1:37 PM, Andi Gutmans wrote:
At 11:53 AM 11/19/2003 -0500, George Schlossnagle wrote:
I agree with --disable-deprecated, it seems to be the best option.
Do you think it would be relevant to have a php.ini option for this?
What's the point of deprecating things if you never re
Well,
At the point the classname is passed to __autoload
is it already in lowercase???
If not, maybe you could just do a single stat in the
file the way it is defined in the __autoload()
function, with no sanity checks (to avoid performance
loss) and include it.
And warn users about it o
Ilia Alshanetsky wrote:
script_* is good, I have no naming preference. I am more interested to know
whether this functionality is something we need or not...
it is not needed, you can just do
system("php -l filename");
instead ;)
actually i would love to have php_check_syntax() as
it would si
On November 19, 2003 02:11 pm, Hartmut Holzgraefe wrote:
> Ilia Alshanetsky wrote:
> > script_* is good, I have no naming preference. I am more interested to
> > know whether this functionality is something we need or not...
>
> it is not needed, you can just do
>
>system("php -l filename");
>
On Wed, Nov 19, 2003 at 02:23:44PM -0500, Ilia Alshanetsky wrote:
> Good idea, we already have some function that utilize php_ prefix, might as
> well continue with the trend. How about php_lint() & php_strip()?
php_lint() sounds goodr, and I'm cool with either php_strip() or
php_strip_whitespa
At 11:09 AM 11/19/2003 -0800, Eduardo R. Maciel wrote:
Well,
At the point the classname is passed to __autoload
is it already in lowercase???
Yes it's already lowercase.
We will need to keep it case-sensitive until this stage. Might not be too
bad because I have thought of a way of improving t
At 08:11 PM 11/19/2003 +0100, Hartmut Holzgraefe wrote:
Ilia Alshanetsky wrote:
script_* is good, I have no naming preference. I am more interested to
know whether this functionality is something we need or not...
it is not needed, you can just do
system("php -l filename");
instead ;)
actuall
At 02:23 PM 11/19/2003 -0500, Ilia Alshanetsky wrote:
> IMHO it should be php_check_syntax() and not
> script_check_syntax() to make clear what it actualy
> checks (it won't check the syntax of my shell, awk
> or perl scripts, would it? ;)
Good idea, we already have some function that utilize php_
On November 19, 2003 02:44 pm, Andi Gutmans wrote:
> I hate the name lint and strip is kind of too short.
> Why not keep it long like Hartmut suggested such as php_check_syntax(),
> php_strip_whitespace()?
Those names are fine too (personally, I dislike overly long function names,
they are harder
Andi Gutmans wrote:
At 02:23 PM 11/19/2003 -0500, Ilia Alshanetsky wrote:
> IMHO it should be php_check_syntax() and not
> script_check_syntax() to make clear what it actualy
> checks (it won't check the syntax of my shell, awk
> or perl scripts, would it? ;)
Good idea, we already have some fun
On Wed, Nov 19, 2003 at 11:24:56AM -0500, Ilia Alshanetsky wrote :
> Attached file, implements validate_file(), which implements a php space syntax
> check for PHP scripts. It returns a boolean true/false value indicating
> whether the script has parse errors or not. Essentially a "php -l" from
On November 19, 2003 02:40 pm, Markus Fischer wrote:
> bool php_check_syntax($filename [, &$error_message]);
I'll need to look at the code, it should be possible to do. Although I'd
prefer to have it return the error rather then return it by reference as an
optional argument.
> As a
It should work out of the box.
--Wez.
> > As a sidenote, would streams be supported (http, ftp) ? Or are there
> > some kind of limitating factors?
>
> That should be possible as well.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
> Not to branch the discussion, but again: if we never plan on removing
> functions, why go to the trouble of deprecating them? Deprecation
> implies it will be removed.
>
.. and as Andi said earlier, removal without loud and clear warning will
break thousands of scripts out there. Making users
Andi Gutmans wrote:
At 11:53 AM 11/19/2003 -0500, George Schlossnagle wrote:
I agree with --disable-deprecated, it seems to be the best option.
Do you think it would be relevant to have a php.ini option for this?
What's the point of deprecating things if you never remove them?
Seems like an
--- Rob Richards <[EMAIL PROTECTED]> wrote:
> If the hash free were moved to php_url_scanner_ex_deactivate(), then
> it would always need to be malloc'd on each new request. Though this
> is an option, it seems the point of ZTS was to reduce the amount of
> malloc/frees needed and reuse memory (p
On Wed, 19 Nov 2003, Andi Gutmans wrote:
>At 02:23 PM 11/19/2003 -0500, Ilia Alshanetsky wrote:
>> > IMHO it should be php_check_syntax() and not
>> > script_check_syntax() to make clear what it actualy
>> > checks (it won't check the syntax of my shell, awk
>> > or perl scripts, would it? ;)
>>
>
On Wed, 19 Nov 2003, Steph wrote:
>> Not to branch the discussion, but again: if we never plan on removing
>> functions, why go to the trouble of deprecating them? Deprecation
>> implies it will be removed.
>>
>
>.. and as Andi said earlier, removal without loud and clear warning will
>break thou
IF you change it, it'll break BC.. :)
IMO, it should just give an error in such case,
and return FALSE too.
--Jani
On Wed, 19 Nov 2003, Andi Gutmans wrote:
>Not sure if/how this should be changed.
>Isn't it a mistake to give a start position at the end or beyond the
>s
On Wed, 19 Nov 2003, Andi Gutmans wrote:
>At 11:09 AM 11/19/2003 -0800, Eduardo R. Maciel wrote:
>>Well,
>>
>>At the point the classname is passed to __autoload
>>is it already in lowercase???
>
>Yes it's already lowercase.
>We will need to keep it case-sensitive until this stage. Might not be
Spotting a missing function is quite easy, your script simply
won't work and give a clear error.. :)
Well, not exactly :) It might just not work anymore at some time in the
future (as you know you never really have 100% code coverage, even with
unit testing and stuff. it's way less than 1
> So, when upgrading, you just go through the new entries, and grep your
> source files for occurences - no big deal.
>
> Where's the missing point? ;)
No one reads the NEWS file.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On Nov 19, 2003, at 5:03 PM, Wez Furlong wrote:
So, when upgrading, you just go through the new entries, and grep your
source files for occurences - no big deal.
Where's the missing point? ;)
No one reads the NEWS file.
Many of these deprecations (call_time_pass_by_reference sticks in my
mind) ha
So, when upgrading, you just go through the new entries, and grep your
source files for occurences - no big deal.
Where's the missing point? ;)
No one reads the NEWS file.
And everone will get the default answer "read the NEWS" once he
complains :) Or you might even add a notice _in the error
On Wed, 19 Nov 2003, Michael Walter wrote:
>> Spotting a missing function is quite easy, your script simply
>> won't work and give a clear error.. :)
>Well, not exactly :) It might just not work anymore at some time in the
>future (as you know you never really have 100% code coverage, eve
Jani Taskinen wrote:
On Wed, 19 Nov 2003, Michael Walter wrote:
Spotting a missing function is quite easy, your script simply
won't work and give a clear error.. :)
Well, not exactly :) It might just not work anymore at some time in the
future (as you know you never really have 100% code c
> As Andi might say: "Why not call this http_headers()?" :)
> (and also rename 'headers_sent' -> http_headers_sent() :)
>
> --Jani
>
As you can probably guess, my answer to your first question is your second
question.
headers_sent() already exists and is in the same general grouping as
Olivier Hill wrote:
Ilia Alshanetsky wrote:
On a related note, since a major PHP version is now being released,
perhaps it is the time to finally remove old deprecated functionality
that in many cases deprecated for years. I propose that we agree on a
certain version as a minimum and remove al
Here is the revised patch. It is now much cleaner (no more lexer stuff) and
supports few additional features. By popular demand the functions have been
renamed to php_check_syntax() & php_strip_whitespace().
php_check_syntax() can now handle remote scripts and if a 2nd (optional)
argument is pa
> No one reads the NEWS file.
I do. But then, I'm anally retentive.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On Wed, Nov 19, 2003 at 03:18:34PM -0500, Ilia Alshanetsky wrote :
> On November 19, 2003 02:40 pm, Markus Fischer wrote:
> > bool php_check_syntax($filename [, &$error_message]);
>
> I'll need to look at the code, it should be possible to do. Although I'd
> prefer to have it return the erro
I am wondering what should happen to the
allow_call_time_pass_reference
php.ini directive.
The following code, for instance, prints no warning with PHP 5 but with
PHP 4.
bar(&$b);
?>
I think the allow_call_time_pass_reference directive should be
removed as it is no longer
60 matches
Mail list logo
