Hello Andi,
it works now fine :-)
marcus
Tuesday, February 10, 2004, 11:24:55 AM, you wrote:
> Does this still segfault for you? It doesn't for me.
> Andi
> At 11:29 PM 2/4/2004 +0100, Marcus Boerger wrote:
>>Hello Andi,
>>
>>Tuesday, February 3, 2004, 2:01:12 PM, you wrote:
>>
>> > Hi,
>>
>>
On Wed, 11 Feb 2004, Shane Caraveo wrote:
>Yes, I have a personal issue with php.ini. It can change the behaviour
>of PHP significantly, which makes application development on top of PHP
>more difficult. There are *very* legit reasons for having the ini file,
>but I think it is overused and a
At 03:42 PM 2/11/2004 -0500, Brian J. France wrote:
Ok, let me know if you want me to back them out.
I worked with Vlad on the changes and had him review the patch before
committing it. We (Yahoo) have been running them for a couple of weeks
now with out any problems.
I'm OK with you leaving th
Ok, let me know if you want me to back them out.
I worked with Vlad on the changes and had him review the patch before
committing it. We (Yahoo) have been running them for a couple of weeks
now with out any problems.
Brian
On Feb 11, 2004, at 3:12 PM, Jan Lehnardt wrote:
Hi,
On 11 Feb 2004,
Hi,
On 11 Feb 2004, at 19:50, Brian France wrote:
bfrance Wed Feb 11 13:50:17 2004 EDT
Modified files:
/php-src/ext/pspell php_pspell.h pspell.c
Log:
Added two new functions to set the dict-dir and data-dir options.
We're in fix-only mode. New features should be discussed
with Andi fir
Hi,
On 11 Feb 2004, at 19:50, Brian France wrote:
bfrance Wed Feb 11 13:50:17 2004 EDT
Modified files:
/php-src/ext/pspell php_pspell.h pspell.c
Log:
Added two new functions to set the dict-dir and data-dir options.
We're in fix-only mode. New features should be discussed
with Andi fir
On 2004/02/12, at 3:41, Shane Caraveo wrote:
Yes, I have a personal issue with php.ini. It can change the
behaviour of PHP significantly, which makes application development on
top of PHP more difficult. There are *very* legit reasons for having
the ini file, but I think it is overused and ab
Zeev Suraski wrote:
At 18:20 11/02/2004, Shane Caraveo wrote:
Zeev Suraski wrote:
At 17:27 11/02/2004, Shane Caraveo wrote:
Arguments for this have been gone over in the past and generaly
'security issues' and 'memory usage' are used as reasons to not
change the way it works, both being gener
Ilia Alshanetsky wrote:
On February 11, 2004 11:20 am, Shane Caraveo wrote:
2. php's dl implementation is broken by design, it should never unload a
dl. not only is that a performance issue, but it requires all kinds of
code to verify that the dl CAN be unloaded properly, thus the problem
with dl
Anyway, the problem in PHP is one of implementation. The reason it has
problems is because dl loads/unloads for every request, rather than
loading and leave loaded like all other languages.
I fixed a similar issue recently in the interbase module. I ended up
NULLing the dlopen() handle in the m
On Wed, 11 Feb 2004, Pierre-Alain Joye wrote:
>Jani Taskinen <[EMAIL PROTECTED]> wrote:
>
>> Our codebase is much larger than any other plus we 'misuse'
>> the auto* tools. :) Feel free to bring the stuff up-to-date so
>> we actually COULD update to latest libtool/autoconf, etc.
>>
SC>> 2. php's dl implementation is broken by design, it should never unload a
SC>> dl. not only is that a performance issue, but it requires all kinds of
SC>> code to verify that the dl CAN be unloaded properly, thus the problem
SC>> with dl in php.
Heya... If you don't unload dl(), all argume
At 18:20 11/02/2004, Shane Caraveo wrote:
Zeev Suraski wrote:
At 17:27 11/02/2004, Shane Caraveo wrote:
Arguments for this have been gone over in the past and generaly
'security issues' and 'memory usage' are used as reasons to not change
the way it works, both being generaly bogus. The only r
On February 11, 2004 11:20 am, Shane Caraveo wrote:
> 2. php's dl implementation is broken by design, it should never unload a
> dl. not only is that a performance issue, but it requires all kinds of
> code to verify that the dl CAN be unloaded properly, thus the problem
> with dl in php.
If the
> > zeevWed Feb 11 06:46:21 2004 EDT
> >
> > Modified files:
> > /php-src/ext/standard dl.c
> > Log:
> > Finally add a notice to hint people that using dl() is a bad idea...
>
> > + zend_error(E_STRICT, "dl() is deprecated - use > extension= in
> not an expert of auto* as you seems to be, and only wondering why it
> does not work.
- autoconf 2.50 is six times slower. Which in turn means
that developing with it takes 6 times longer (think of
edit, compile, run cycle. Yeah, someone wrote that build
system with a coup
Fix being submitted as I type.
Thanks for the good reproducing script.
Andi
At 01:29 PM 2/10/2004 +0100, Pierre-Alain Joye wrote:
Hello,
Maybe this usage is wrong but it should not leak:
Text1
EOF;
$sxe = simplexml_load_string($xml);
$sxe->attributes;
?>
# php5 sxe_leak.php
/home/
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
Zeev Suraski wrote:
At 17:27 11/02/2004, Shane Caraveo wrote:
Arguments for this have been gone over in the past and generaly
'security issues' and 'memory usage' are used as reasons to not change
the way it works, both being generaly bogus. The only reason it isn't
fixed is reliance on php
Organization: Freelancer
X-Mailer: Sylpheed version 0.9.8claws (GTK+ 1.2.10; i686-pc-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Organization: Freelancer
X-Mailer: Sylpheed version 0.9.8claws (GTK+ 1.2.10; i686-pc-linux-gnu)
Mime-Version:
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 imple
On Wed, 11 Feb 2004, Pierre-Alain Joye wrote:
>
>I feel this problem in the same way as the auto* tools. Each time
>someone came in and say: "got errors using version x", "we" answer
>please use the(damn old) version 2.x or whatever. As most of other
>applications use recent auto* tools without pro
At 17:27 11/02/2004, Shane Caraveo wrote:
Arguments for this have been gone over in the past and generaly 'security
issues' and 'memory usage' are used as reasons to not change the way it
works, both being generaly bogus. The only reason it isn't fixed is
reliance on php.ini.
Sorry Shane, but t
Stanislav Malyshev wrote:
PJ>> python in my case. And not only langages, please check any tools that
PJ>> allows dynamic load of extensions.
Most languages even don't have a concept of "extensions",
WTF? At least I get a good laugh early in the morning.
Perl, Python, Tcl, Pike, Ruby, *name you
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
Ilia Alshanetsky wrote:
> iliaa Wed Feb 11 09:52:13 2004 EDT
>
> Modified files:
> /php-src/sapi/cgi cgi_main.c
> Log:
> Proper win32 fix.
That fixed it, thanks,
Sebastian
--
Sebastian Bergmann
http://sebastian-bergmann.de/ http://phpOpenTracker.de/
Das Buc
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
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 wri
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 facili
On Wed, 11 Feb 2004, Derick Rethans wrote:
> On Wed, 11 Feb 2004, Sascha Schumann wrote:
>
> > On Wed, 11 Feb 2004, Derick Rethans wrote:
> >
> > > On Wed, 11 Feb 2004, Pierre-Alain Joye wrote:
> > >
> > > > - CLI/CGI (as pointed by Derick, but being wrong while saying (fast)cgi
> > > > is slow
On Wed, 11 Feb 2004, Sascha Schumann wrote:
> On Wed, 11 Feb 2004, Derick Rethans wrote:
>
> > On Wed, 11 Feb 2004, Pierre-Alain Joye wrote:
> >
> > > - CLI/CGI (as pointed by Derick, but being wrong while saying (fast)cgi
> > > is slow ;) )
> >
> > No, CGI is slow and for FastCGI dl() is a pr
On Wed, 11 Feb 2004 15:40:33 +0200 (IST)
Stanislav Malyshev <[EMAIL PROTECTED]> wrote:
> 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 -
PJ>> > For those of us not being Python gurus, could you elaborate?
PJ>>
PJ>> http://www.python.org/doc/current/ref/import.html
Well, when I have time I'll read this. But if you could explain yourself
without me having to go and learn python (which may be very great
language, but that doesn't m
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
On Wed, 11 Feb 2004, Derick Rethans wrote:
> On Wed, 11 Feb 2004, Pierre-Alain Joye wrote:
>
> > - CLI/CGI (as pointed by Derick, but being wrong while saying (fast)cgi
> > is slow ;) )
>
> No, CGI is slow and for FastCGI dl() is a problem again.
Why would dl() be a problem for FastCGI?
Organization: Freelancer
X-Mailer: Sylpheed version 0.9.8claws (GTK+ 1.2.10; i686-pc-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
On Wed, 11 Feb 2004 15:25:33 +0200 (IST)
Stanislav Malyshev <[EMAIL PROTECTED]> wrote:
> For those of us not
On Wed, 11 Feb 2004 15:25:33 +0200 (IST)
Stanislav Malyshev <[EMAIL PROTECTED]> wrote:
> Most languages even don't have a concept of "extensions", so I don't
> see any point here. That's like saying "why I can't work with
> processor registers in PHP - in Assembler I could".
No it is not. And th
On Wed, 11 Feb 2004, Pierre-Alain Joye wrote:
> - CLI/CGI (as pointed by Derick, but being wrong while saying (fast)cgi
> is slow ;) )
No, CGI is slow and for FastCGI dl() is a problem again.
Derick
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.p
PJ>> python in my case. And not only langages, please check any tools that
PJ>> allows dynamic load of extensions.
Most languages even don't have a concept of "extensions", so I don't see
any point here. That's like saying "why I can't work with processor
registers in PHP - in Assembler I could"
Organization: Freelancer
X-Mailer: Sylpheed version 0.9.8claws (GTK+ 1.2.10; i686-pc-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
On Wed, 11 Feb 2004 14:41:19 +0200 (IST)
Stanislav Malyshev <[EMAIL PROTECTED]> wrote:
> Which languages are
On Wed, 11 Feb 2004, Stanislav Malyshev wrote:
> PJ>> Well, php dl sucks? Why it sux for php and not for other langages?
> PJ>> (not kidding here :) ).
>
> Which languages are you talking about? The general answer is, obviously,
> "PHP is not ", but let's go specific -
> what language and what do
PJ>> Well, php dl sucks? Why it sux for php and not for other langages?
PJ>> (not kidding here :) ).
Which languages are you talking about? The general answer is, obviously,
"PHP is not ", but let's go specific -
what language and what do you mean by that?
PJ>> If we have to deprecate dl, then
Committed - thanks!
Zeev
At 14:15 11/02/2004, Rob Richards wrote:
Fixes a segfault when calling reflection_function::export('Foo'); and
function doesnt exist.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP Internals - PHP Runti
Organization: Freelancer
X-Mailer: Sylpheed version 0.9.8claws (GTK+ 1.2.10; i686-pc-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
On Wed, 11 Feb 2004 14:07:16 +0200
Andi Gutmans <[EMAIL PROTECTED]> wrote:
> Pierre,
>
> Just to add to thi
On Wed, 11 Feb 2004, Andi Gutmans wrote:
> Pierre,
>
> Just to add to this, the fact that it's deprecated doesn't mean you can't
> use it.
> It just means that there are known bugs which won't be fixed and the
> function won't be maintained.
> We've been through this a few times in the past few ye
Fixes a segfault when calling
reflection_function::export('Foo'); and function doesnt
exist.
Index: zend_reflection_api.c
===
RCS file: /repository/ZendEngine2/zend_reflection_api.c,v
retrieving revision 1.85
diff -u -r1.85 zend_r
Pierre,
Just to add to this, the fact that it's deprecated doesn't mean you can't
use it.
It just means that there are known bugs which won't be fixed and the
function won't be maintained.
We've been through this a few times in the past few years and the
conclusion has always been that dl() suc
Date: Wed, 11 Feb 2004 14:02:41 +0200
To: Pierre-Alain Joye <[EMAIL PROTECTED]>
From: Andi Gutmans <[EMAIL PROTECTED]>
Subject: Re: dl() problem
Cc: Pierre-Alain Joye <[EMAIL PROTECTED]>,[EMAIL PROTECTED]
Pierre,
dl() should have been deprecated a long time ago.
It's not secure (for example on a
On Wed, 11 Feb 2004 11:46:21 -
"Zeev Suraski" <[EMAIL PROTECTED]> wrote:
> zeev Wed Feb 11 06:46:21 2004 EDT
>
> Modified files:
> /php-src/ext/standard dl.c
> Log:
> Finally add a notice to hint people that using dl() is a bad idea...
> + ze
Hey,
Just wanted to remind you guys that we're going with Beta 4 tomorrow as
planned which will be followed by a feature freeze in preparation for RC1.
Anyone who has last minute changes to make, please do them.
Thanks,
Andi
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscri
50 matches
Mail list logo
