Can someone have a look at this - it appears to work now. - eg. It runs
overloaded classes ok without segfaulting.
Regards
Alan
--
Edit this bug report at http://bugs.php.net/?id=25831&edit=1
[EMAIL PROTECTED] wrote:
ID: 25831
Updated by: [EMAIL PROTECTED]
Reported By: v
Ilia Alshanetsky wrote:
One solution which was to bundle libxml with PHP got rejected and if my
recollection is correct you agreed with that decision. IMHO that was a good
decision, bundling a huge library (3.2+ megs as of 2.6.0) almost as big as
PHP itself seems kind of strange.
Reverting
When configuring PHP 5 for Mac OS X, I get this every time, even with
2.5.10 installed:
not found
configure: error: Please reinstall the libxml >= 2.4.14 distribution
What is the deal?
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
> > This issue is definitely not a reason to stop rolling out RC's nor
betas.
> > Enabling the XML extensions by default is the right decision because
> > this is an important technology which almost every PHP user will
need.
> > I do think it's a good idea though to have a --disable switch that
>
On Sat, 25 Oct 2003, George Schlossnagle wrote:
>That wasn't quite my point, I should have been more clear. I have
>libxml2 on my box. It was a pain to build. Supposedly, it is possible
>to disable the need for xml on the system, however if I uninstall
>libxml2 and run
>
>./configure --disab
Andi Gutmans wrote:
[snip]
This issue is definitely not a reason to stop rolling out RC's nor betas.
Enabling the XML extensions by default is the right decision because
this is an important technology which almost every PHP user will need.
I do think it's a good idea though to have a --disable
We have had discussions about named parameters in the past.
They won't be supported for PHP 5. In any case, even if they are supported
by the engine they will still be very inefficient and will just bloat PHP.
Most languages do without them and I think PHP can do so too.
Andi
At 11:13 PM 10/24/2
At 03:50 PM 10/24/2003 -0400, Dan Kalowsky wrote:
On Fri, 24 Oct 2003, Adam Maccabee Trachtenberg wrote:
> FWIW, I've had good success using fink to install libxml2 and libxsl;
> however, in order to get a version of libxml2 high enough (2.5.10) to
> work with PHP, you need to build from the "unst
Michael Walter wrote:
(the common) way of faking named parameters, you rely on a) hash lookups
at execution time (for _every_ call) and b) on manually dealing with
default values.
I'd even be happy to accept these two drawbacks but the ugliness of the
array() solution is what I'd like to get rid
On October 24, 2003 04:27 pm, Adam Maccabee Trachtenberg wrote:
> That sounds like a great idea. Also, George was saying that he was
> unable to disable all the xml extensions, at least on Mac OS X.
I used --disable-all followed by a list of extensions I want to enable. This
seems to work with la
One solution which was to bundle libxml with PHP got rejected and if my
recollection is correct you agreed with that decision. IMHO that was a good
decision, bundling a huge library (3.2+ megs as of 2.6.0) almost as big as
PHP itself seems kind of strange.
Reverting back to expat does not app
Sorry,
I just find it annoying that something that has worked out of the box
before (compiling PHP with default settings) is now no longer able to do
so easily (on my particular platform).
On Fri, 24 Oct 2003, Ilia Alshanetsky wrote:
> External dependencies are frustrating, but you could always
On Fri, 24 Oct 2003, Ilia Alshanetsky wrote:
> External dependencies are frustrating, but you could always disable
> compilation of all the xml extensions (I do that all the time). That said, do
> we really need just about every XML extension enabled by default and if we
> do, perhaps a 'global
> IMHO, I think that replicating the finally code at the end of every catch
> block, before every throw/return statement and at the end of the try/catch
> statement justify the need of "finally".
My mistake, it's not necessary to replicate the code at the end of every
catch block.
And I forgot to m
Hi internals !
I came into a problem when writing an IDL to PHP5 language mapping
specification and an IDL to PHP5 language compiler. I'm using the community
OpenORB IDL-to-Java compiler as a base for writing the IDL-to-PHP5 compiler,
in fact, it is a translation from Java to PHP5. Everything is o
External dependencies are frustrating, but you could always disable
compilation of all the xml extensions (I do that all the time). That said, do
we really need just about every XML extension enabled by default and if we
do, perhaps a 'global' --disable-all-xml flag should be in order?
Ilia
--
On Fri, 24 Oct 2003, Adam Maccabee Trachtenberg wrote:
> FWIW, I've had good success using fink to install libxml2 and libxsl;
> however, in order to get a version of libxml2 high enough (2.5.10) to
> work with PHP, you need to build from the "unstable" tree.
Great, just what I want, yet another
At 11:53 AM 10/25/2003 -0700, George Schlossnagle wrote:
On Friday, October 24, 2003, at 11:49 AM, Adam Maccabee Trachtenberg wrote:
On Sat, 25 Oct 2003, George Schlossnagle wrote:
How do you make this work without libxml2 (Sterling??)? That's an
utter pain to get built on os x.
FWIW, I've ha
On Friday, October 24, 2003, at 11:49 AM, Adam Maccabee Trachtenberg
wrote:
On Sat, 25 Oct 2003, George Schlossnagle wrote:
How do you make this work without libxml2 (Sterling??)? That's an
utter pain to get built on os x.
FWIW, I've had good success using fink to install libxml2 and libxsl;
On Sat, 25 Oct 2003, George Schlossnagle wrote:
> How do you make this work without libxml2 (Sterling??)? That's an
> utter pain to get built on os x.
FWIW, I've had good success using fink to install libxml2 and libxsl;
however, in order to get a version of libxml2 high enough (2.5.10) to
wor
> Locale settings affecting float parsing [tests/lang/034.phpt]
This fails on all MacOS installs (even with prior PHP) due to locale handling
bug. MacOS claims switch locale, but does not actually do it.
> Bug #25547 (error_handler and array index with function call)
> [tests/lang/bug25547.phpt]
On Friday, October 24, 2003, at 10:06 AM, Andi Gutmans wrote:
Hey,
I've rolled RC1 of beta 2. Although it's a beta I thought it'd be a
good idea to roll an RC so that we can at least do a sanity check to
see that the package is OK and builds.
http://www.php.net/~andi/php-5.0.0b2RC1.tar.bz2
ht
On Friday, October 24, 2003, at 10:06 AM, Andi Gutmans wrote:
Hey,
I've rolled RC1 of beta 2. Although it's a beta I thought it'd be a
good idea to roll an RC so that we can at least do a sanity check to
see that the package is OK and builds.
http://www.php.net/~andi/php-5.0.0b2RC1.tar.bz2
ht
Hey,
I've rolled RC1 of beta 2. Although it's a beta I thought it'd be a good
idea to roll an RC so that we can at least do a sanity check to see that
the package is OK and builds.
http://www.php.net/~andi/php-5.0.0b2RC1.tar.bz2
http://www.php.net/~andi/php-5.0.0b2RC1.tar.gz
Please let me know
At 07:17 AM 10/24/2003 -0700, Eduardo R. Maciel wrote:
Hi,
I agree with Dan´s opinion.
Watching from a point of view of a developer working
on PHP Object Oriented aplications, libs, frameworks,
etc, there is no sense on things like this. Or it IS
object oriented or it IS NOT. Partiality alway
I've written a PHP sapi to use PHP as component from within OpenGroupware Webserver
and access and a PHP module to access its internals. I'm going to release it under
BSD-like license. I'm interested in incorporating it in official PHP distribution.
--
PHP Internals - PHP Runtime Development Ma
Hi,
I agree with Dan´s opinion.
Watching from a point of view of a developer working
on PHP Object Oriented aplications, libs, frameworks,
etc, there is no sense on things like this. Or it IS
object oriented or it IS NOT. Partiality always run
into complications. And that was what happen on P
Sebastian Bergmann wrote:
Named parameters are commonly implemented using an associated array in
PHP:
foo(
array(
'foo' => 'bar',
'bar' => 'foo'
)
);
?>
So, how do you think that isn't known to the original poster as he even
explicitely states that
Hartmut Holzgraefe wrote:
Sebastian Bergmann wrote:
netcat wrote:
Named parameters - i think is very good idea.
Named parameters are commonly implemented using an associated array in
PHP:
which is a nightmare performancewise and suboptimal as far as
syntax is concerned as the additional 'a
This does appear to fix it.. (diff attached) - however I'm not sure if
there are any knock on effects that this may cause?
Regards
alan
[EMAIL PROTECTED] wrote:
This may be where the problem:
zend_get_parameters_array_ex(ZEND_NUM_ARGS(), args);
Would this do the trick?
zend_get_parameter
Sebastian Bergmann wrote:
netcat wrote:
Named parameters - i think is very good idea.
Named parameters are commonly implemented using an associated array in
PHP:
which is a nightmare performancewise and suboptimal as far as
syntax is concerned as the additional 'array(' keyword needed
serves
31 matches
Mail list logo
