At 22:50 12/02/2004, Andrei Zmievski wrote:
On Wed, 11 Feb 2004, Zeev Suraski wrote:
> By the way - dl() is trivial to implement if we were to go down your path,
> and make dl()'s persist forever. However, that's exactly where the
problem
> is coming from - it completely doesn't fit the theme of
At 12:50 PM 2/12/2004 -0800, Andrei Zmievski wrote:
On Wed, 11 Feb 2004, Zeev Suraski wrote:
> By the way - dl() is trivial to implement if we were to go down your path,
> and make dl()'s persist forever. However, that's exactly where the
problem
> is coming from - it completely doesn't fit the t
On Wed, 11 Feb 2004, Zeev Suraski wrote:
> By the way - dl() is trivial to implement if we were to go down your path,
> and make dl()'s persist forever. However, that's exactly where the problem
> is coming from - it completely doesn't fit the theme of PHP (not to mention
> the security and res
On Wed, 11 Feb 2004, Shane Caraveo wrote:
> 1. languages have dynamicaly loadable binary extensions (only second
> rate ones do not)
> 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 veri
On Wed, 11 Feb 2004, Derick Rethans wrote:
> 2. for PHP GTK you usually don't want the extension=php_gtk.so line as
>it inteferes with normal operation.
How does it interfere with normal operation?
- Andrei
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http:
On Thu, 2004-02-12 at 11:00, Stanislav Malyshev wrote:
> SSB>> Convenience, modularity, ease of administration (or lack thereof for
> SSB>> people using shared hosting environments). With dl() you can
> SSB>> install an extension from PECL and use it immediately even in a
> SSB>> shared hosting en
On Thu, 12 Feb 2004 13:05:38 +0200 (IST)
Stanislav Malyshev <[EMAIL PROTECTED]> wrote:
> PJ>> Indeed, compare apples and peanuts, all good ;). What's about the
> PJ>per> host module?
>
> I think it's a valid concern, but using dl() for it is not good, at
> least in its present form.
> By the way
PJ>> Indeed, compare apples and peanuts, all good ;). What's about the per
PJ>> host module?
I think it's a valid concern, but using dl() for it is not good, at least
in its present form.
By the way, how exactly do you plan to use dl() for that? Making
auto_prepend that dl()'s it, or what? How
SSB>> Convenience, modularity, ease of administration (or lack thereof for
SSB>> people using shared hosting environments). With dl() you can
SSB>> install an extension from PECL and use it immediately even in a
SSB>> shared hosting environment. If I hosted by stuff in such an
If you are managin
On Wed, 2004-02-11 at 17:42, Stanislav Malyshev wrote:
> 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>
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
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
> 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
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
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
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
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
48 matches
Mail list logo
