Hi!
>>spn> www.mnogosearch.org (mnogosearch-php-extension-1.7.3.tar.gz) and
>>spn> replaced the contents of ext/mnogosearch with the files in this archive
>>spn> and it all worked a treat (with a quick edit to remove the second
>>spn> reference to -lmysqlclient in the EXTRA_LIBS line the PHP Makef
i have an extension which uses a huge chunk of static data (about 1 Meg).
instead of compiling it into the extension, i set up a sub project to
compile the data into a shared object/DLL so memory could be more
efficiently used across multiple processes. in any case i exported the data
(or so i thou
Hi,
Apparently on request shutdown all objects that aren't free'd in the
script don't get free'd. This is a very bad thing when it comes to
handling overloads, as sometimes you can have multiple objects pointing
at the same source, and you don't want to free underlying source until
the last objec
On 8 Jun 2003, Sterling Hughes wrote:
>Err. The release manager does:
>
>php5]$ ./bundle-release
>
>Which bundles the stable version of all the extensions we decide belong
>in php5. Whether this list grows our shrinks would require group
>concensus, and is not the issue here.
So none of tho
Sterling Hughes wrote:
MR> (Sorry if I missed something, but this seems like a no-brainer)
Forcing all developers to work with a broken environment will make
development ineffective/inefficient.
The distribution is "broken," but that doesn't affect development. The
only difference from a develo
SH> On the *server* there will be a symlink connecting php5/ext and pecl.
SH> So long as you checkout php5, you'll have all the extensions, and
SH> everything will work honkey dorey.
For that symlink you can have all my votes, if PECL is moved to top
outside of pear :-)
--
Best regards,
Marcus
On 08 Jun 2003 12:31:11 -0400
Sterling Hughes <[EMAIL PROTECTED]> wrote:
> I agree 100%.
>
> Also, do note that all common extensions will still be direct aliases.
> Meaning there should be no difference from a development perspective
> (we'll still have the same set of extensions in cvs, for a
> MR> (Sorry if I missed something, but this seems like a no-brainer)
>
>
> Forcing all developers to work with a broken environment will make
> development ineffective/inefficient.
The distribution is "broken," but that doesn't affect development. The
only difference from a developer perspect
Hello Mike,
Monday, June 9, 2003, 12:32:18 AM, you wrote:
MR> It's not like PHP5 will get out the door any time soon. If the plan is
MR> to move all php5 extensions to PECL, why wait? Move them. Fix things.
MR> Seems like a good idea, and fairly straight forward, especially when
MR> you have some
It's not like PHP5 will get out the door any time soon. If the plan is
to move all php5 extensions to PECL, why wait? Move them. Fix things.
Seems like a good idea, and fairly straight forward, especially when
you have someone as capable as Sterling volunteering to do the work.
Best Regards
Mike R
On Sun, 8 Jun 2003, Rasmus Lerdorf wrote:
[snip]
> Basically my point is that instead of pushing extensions into the current
> void that is PECL, we need to pull PECL from the void and make it work
> first. You seem to want to take the reverse approach. Push everything
> into PECL and by doing t
Hello James,
Sunday, June 8, 2003, 3:42:04 PM, you wrote:
JC> - Moving all of the right ext to pecl.
JC> - Splitting pecl into it's own module
JC> - The possibility of having a separate $CVSROOT for pear/pecl (makes life
JC> more tidy, and we can autogenerate avail... [not that we can't right
> Basically my point is that instead of pushing extensions into the current
> void that is PECL, we need to pull PECL from the void and make it work
> first. You seem to want to take the reverse approach. Push everything
> into PECL and by doing that force someone to fix it, versus fixing PECL
>
I know the reasoning, but you were discounting everything except the
versioning which I simply pointed out could be done without the move just
as effectively. PECL's versioning support is no better than what can be
done directly with CVS. The pear installer still doesn't work on Windows.
We obvio
On Sun, 2003-06-08 at 12:56, Rasmus Lerdorf wrote:
> On Sun, 8 Jun 2003, Sterling Hughes wrote:
> > I agree 100%.
> >
> > Also, do note that all common extensions will still be direct aliases.
> > Meaning there should be no difference from a development perspective
> > (we'll still have the same se
Rasmus Lerdorf wrote:
> we just need developers to tag their extensions when they deem them
> stable and makedist simply checks out the latest stable version of
> the extension. Problem solved.
Sounds like a good plan to me as it should solve the problem without
causing trouble.
--
Sebasti
On 8 Jun 2003, Sterling Hughes wrote:
> php5]$ ./bundle-release
>
> Which bundles the stable version of all the extensions we decide belong
> in php5. Whether this list grows our shrinks would require group
> concensus, and is not the issue here.
>
> Would you prefer bundling code that is a wor
On Sun, 8 Jun 2003, Sterling Hughes wrote:
> I agree 100%.
>
> Also, do note that all common extensions will still be direct aliases.
> Meaning there should be no difference from a development perspective
> (we'll still have the same set of extensions in cvs, for all practical
> purposes). The onl
On Sun, 2003-06-08 at 12:38, Edin Kadribasic wrote:
> On 8 Jun 2003, Sterling Hughes wrote:
>
> > What does PEAR's stability on windows 32 systems have anything to do
> > with it? This is an internal change. Meaning, as an end-user, you
> > won't see any change. The separation to PECL is purely
On 8 Jun 2003, Sterling Hughes wrote:
> What does PEAR's stability on windows 32 systems have anything to do
> with it? This is an internal change. Meaning, as an end-user, you
> won't see any change. The separation to PECL is purely a release
> management thing.
>
> The move to PECL has been
I agree 100%.
Also, do note that all common extensions will still be direct aliases.
Meaning there should be no difference from a development perspective
(we'll still have the same set of extensions in cvs, for all practical
purposes). The only difference is that when the release manager goes
ah
On Sun, 8 Jun 2003 09:23:29 -0700 (PDT)
Rasmus Lerdorf <[EMAIL PROTECTED]> wrote:
> The one point on the QA issue is that nobody ever looks through all
> the PECL extensions, but we occasionally grep through all the ext/*
> extensions to make sure that an API change, or just a simple mistake
> tha
The one point on the QA issue is that nobody ever looks through all the
PECL extensions, but we occasionally grep through all the ext/* extensions
to make sure that an API change, or just a simple mistake that we found
does not occur in other extensions.
We need to raise the priority of PECL/* in
Hi,
I made local patches in fopen_wrappers.c to get some apache
environment variables like:
myptr = sapi_getenv("VH_VAR_ROOT", strlen("VH_VAR_ROOT") TSRMLS_CC);
But it's causing a segfault when used in php_fopen_with_path()
However, when used in php_check_open_basedir() it works fine.
I gue
What does PEAR's stability on windows 32 systems have anything to do
with it? This is an internal change. Meaning, as an end-user, you
won't see any change. The separation to PECL is purely a release
management thing.
The move to PECL has been agreed upon multiple times. We can't have the
rele
Help translating documentation into zh_CN
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
>
> Is PECL going to move to the top level in CVS? - it's a bit
> hidden away
> at the moment... (and I guess after these are moved -
> creating a 'real'
> php5 directory?? - so their's not so many empty directories
> lying around?)
>
>
Yes. There are a bunch of cvs admin tasks that I am l
Zeev Suraski wrote:
> Was it crashing under a specific script, or always?
Always since the "MEGA-patch: namespaces are R.I.P.".
--
Sebastian Bergmann
http://sebastian-bergmann.de/ http://phpOpenTracker.de/
http://www.professionelle-softwareentwicklung-mit-php5.de/
Zeev Suraski wrote:
> When was it crashing, prior to that fix?
zend.c:1.231 segfaulted. In zend.c:1.232 I "fixed" the segfault, or
what fix did you mean?
--
Sebastian Bergmann
http://sebastian-bergmann.de/ http://phpOpenTracker.de/
http://www.professionelle-soft
At 23:00 05/06/2003, Sebastian Bergmann wrote:
Zeev Suraski wrote:
> It does look like a voodoo fix. What's crashing exactly?
Zeev,
Stanislav already looked into this and the segfault related to
GLOBAL_CONSTANTS_TABLE not beeing malloc()ed in ZTS mode is now gone.
But with a fairly odd fix.
Hi,
Shane Caraveo <[EMAIL PROTECTED]> wrote:
> Marcus Börger wrote:
> >
> >
> > Some extensions like mbstring behave different when not builtin. So
> > i suggest we find out which theses are and let them in.
>
> Having them in pecl in no way prevents them from being compiled builtin.
I basical
> From: Alan Knowles [mailto:[EMAIL PROTECTED]
> Sent: Sunday, June 08, 2003 4:53 AM
> Is PECL going to move to the top level in CVS? - it's a bit hidden
away
> at the moment... (and I guess after these are moved - creating a
'real'
> php5 directory?? - so their's not so many empty directories l
32 matches
Mail list logo
