http://cvs.php.net/diff.php/ZendEngine2/zend_compile.c?r1=1.403&r2=1.404&ty=h&num=10
removed the T_DOC_COMMENT from being ignored by zendlex -
looks like at the moment, optional_doc_comment is splattered all over
the parser.
the other way to do this (is what phpcodedoc does) is just to
remembe
At 07:30 02.04.2003, Andi Gutmans wrote:
I'm not completely sure but from first glance at exif it is *completely*
broken everywhere.
You're not supposed to use zval_dtor() on parameters you get via
zend_get_parameters_ex(). They are read-only as they are reference counted
and are possibly pointe
The attached source presents a multiplication routine with
built-in overflow detection. For x86/GCC, we can avoid
floating point arithmetic by using a small assembler
fragment. Support for other platforms can be added as
necessary.
There are two distinct uses for this in
This patch fixes Bug #22774 PHP crashes when exiting.
All it does is move the registration of the php_free_xml_doc destructor to
the end of the list, so it is called after destroying nodes and attributes
in the instances where the domxml extension is loaded via a dl() call.
It seems the only time
Patch didnt get attached in last message.
It can be found here: http://www.digarc.com/php_domxml.c.diff
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On Wed, 2003-04-02 at 12:26, Rob Richards wrote:
> Patch didnt get attached in last message.
>
> It can be found here: http://www.digarc.com/php_domxml.c.diff
applied. thanks
chregu
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Translating the spanish documentation
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Is there a way to tell PHP to not include some sources in CLI build?
PHP_NEW_EXTENSION( mymodule , mymodule.c , nocli) doesn't work as I expected - it
doesn't include extension in main/internal_functions_cli.c but it link mymodule.o
to sapi/cli/php.
regards,
Wojtek
--
PHP Internals - PHP Runti
On Wed, 02 Apr 2003, Alan Knowles wrote:
> http://cvs.php.net/diff.php/ZendEngine2/zend_compile.c?r1=1.403&r2=1.404&ty=h&num=10
>
> removed the T_DOC_COMMENT from being ignored by zendlex -
>
> looks like at the moment, optional_doc_comment is splattered all over
> the parser.
>
> the other way
Can the purpose of doc comments be clarified? Why aren't class variables
important enough to document? I think everything exposed by a class -
variables, methods, constants, etc. - are all equally important and should
be documented.
> -Original Message-
> From: Andi Gutmans [mailto:[EMAIL
On Wed, 02 Apr 2003, Lance Lovette wrote:
> Can the purpose of doc comments be clarified? Why aren't class variables
> important enough to document? I think everything exposed by a class -
> variables, methods, constants, etc. - are all equally important and should
> be documented.
The problem is
> >This problem bites just about any places where people used /** */ as
> >comments.
> >For example:
> >if ($a > 5) { /** This is a smart check *.
> >}
> >
> >IMO, we can't break BC this badly.
>
> Ah, that's right. We probably need to rethink our strategy then, and tie
> doc comments to the re
On Wed, 02 Apr 2003, Andi Gutmans wrote:
> Oh, I didn't think of that. You are completely right. This is definitely a
> problem. Andrei's patch returns a token for /** */ on the parser level so
> only places which are allowed to have this work.
> This sounds like a serious flaw because any place
At 10:38 AM 4/2/2003 -0500, Andrei Zmievski wrote:
> >This problem bites just about any places where people used /** */ as
> >comments.
> >For example:
> >if ($a > 5) { /** This is a smart check *.
> >}
> >
> >IMO, we can't break BC this badly.
>
> Ah, that's right. We probably need to rethink our
At 10:41 AM 4/2/2003 -0500, Andrei Zmievski wrote:
On Wed, 02 Apr 2003, Andi Gutmans wrote:
> Oh, I didn't think of that. You are completely right. This is definitely a
> problem. Andrei's patch returns a token for /** */ on the parser level so
> only places which are allowed to have this work.
> T
At 18:38 02/04/2003, Andrei Zmievski wrote:
> >This problem bites just about any places where people used /** */ as
> >comments.
> >For example:
> >if ($a > 5) { /** This is a smart check *.
> >}
> >
> >IMO, we can't break BC this badly.
>
> Ah, that's right. We probably need to rethink our strate
On Wed, 02 Apr 2003, Andi Gutmans wrote:
> How about:
> if ($a
> /**
> $a is great variable */
> || $b) {
>
> }
>
> I'm sure I can find other more realistic examples which would break. I
> don't know why I didn't think of it before but I think having this in the
> parser is impossible.
On Wed, 02 Apr 2003, Zeev Suraski wrote:
> I don't really like the idea of cluttering the parser with additional rules
> if it's not really necessary. I think that the idea proposed by Alan is
> actually the best way to go (keep the last comment in a global, use and
> reset it in the next relev
At 18:51 02/04/2003, Andrei Zmievski wrote:
On Wed, 02 Apr 2003, Zeev Suraski wrote:
> I don't really like the idea of cluttering the parser with additional
rules
> if it's not really necessary. I think that the idea proposed by Alan is
> actually the best way to go (keep the last comment in a gl
On Wed, 02 Apr 2003, Zeev Suraski wrote:
> >We don't want to apply this doc comment to class Bar, so it needs to be
> >reset on every statement, basically. Isn't that right?
>
> Probably, yes. I think Alan mentioned it.
So it would be enough to reset it in unticked_statement rule?
-Andrei
Contributing an XML_NITF class to PEAR, I need access to the portion of the PEAR/XML/
tree and whatever access I need to add DocBook information for the class in the PEAR
repository.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On Wed, 02 Apr 2003, Andrei Zmievski wrote:
> + if (EG(active_namespace) != ns) {
> + orig_namespace = EG(active_namespace);
> + EG(active_namespace) = ns;
> + CG(class_table) = &ns->class_table;
> + }
> + register_class = zend_register_internal_class
to create a template engine extension in C that runs standard on all PHP
engines. Instead of running smarty here and another one there, I am
in the process of building an extension that handles all of it fast and
hopefully to become standardized.
--
PHP Internals - PHP Runtime Development Maili
> xml_parser_create($maxs);
I can't reproduce this one and I don't really see how passing a long
string to that code could be a problem.
-Rasmus
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On Wed, 2 Apr 2003, Matt Jarjoura wrote:
> to create a template engine extension in C that runs standard on all PHP
> engines. Instead of running smarty here and another one there, I am
> in the process of building an extension that handles all of it fast and
> hopefully to become standardized.
Co
I just checked out a copy of HEAD and can't build PHP5, it looks like
some changes were made to rename everything from php4->php5 and there
are still some php4 references floating around that end up in the
Makefile:
[EMAIL PROTECTED] ~/php5]$ make
make: *** No rule to make target `libphp4.la', ne
N/M... ./buildconf is a wonderful thing... (whoops)
-~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~-
John Coggeshall
john at coggeshall dot org http://www.coggeshall.org/
-~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~-
>-Original
Here's a patch for the GD lib.. I'd like to commit this if there is no
objection. It does a few things:
1) Creates a warning for imagepscopyfont()... It's in the docs and right
now its completely commented out in the source... For BC this really
should not just completely disappear (even if T1Lib
John,
Please separate the patches for review. I have a feeling that some
might not be desirable (the first), while other portions look good.
-Sterling
On Wed, 2003-04-02 at 21:54, John Coggeshall wrote:
> Here's a patch for the GD lib.. I'd like to commit this if there is no
> objection. It do
IMO we should not enable a buggy function, the output may be un expected and
if it results in memory corruption we could end with a fairly annoying and
hard to trace problem.
Ilia
On April 2, 2003 09:54 pm, John Coggeshall wrote:
> Here's a patch for the GD lib.. I'd like to commit this if ther
I'll separate the patches in a minute, but this isn't enabling the
function -- it's just throwing an E_WARNING (probably should
RETURN_FALSE too)... Otherwise you get a not-defined error.
John
-~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~-
John Coggeshall
john at coggesh
On Wed, Apr 02, 2003 at 02:16:56PM +0200, Wojtek Meler wrote:
> Is there a way to tell PHP to not include some sources in CLI build?
> PHP_NEW_EXTENSION( mymodule , mymodule.c , nocli) doesn't work as I expected - it
> doesn't include extension in main/internal_functions_cli.c but it link mymodule
Okay... Here's the patch again. This is only one patch to correct the
error handling of the GD extension when using T1Lib... If someone really
wants me to post a second patch for the imagepscopyfont() function I
will, but it's a really trivial... I just suggested we throw a warning
instead of comp
Here's another small little patch to fix imagepsextendfont() that sanity
checks the $extend parameter to make sure it's greater than zero.
Although less than zero "works" (i.e. it doesn't crash anything) it
really shouldn't be allowed.
John
-~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~
On Wed, 2 Apr 2003, Andi Gutmans wrote:
> I'm not completely sure but from first glance at exif it is *completely*
> broken everywhere.
> You're not supposed to use zval_dtor() on parameters you get via
> zend_get_parameters_ex(). They are read-only as they are reference counted
> and are possibly
35 matches
Mail list logo
