Translating PHP Manual into Chinese (HK Trad.)
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
PHP 4 Bug Database summary - http://bugs.php.net
Num Status Summary (925 total including feature requests)
===[*Configuration Issues]
20490 Analyzed enable versioning not supported on OSX
21195 Verified Configure warnings/errors
21973 O
hi,
I wonder whether a function which allows me to create an object and call the
constructor while the parameters are given as an array (similar to
call_user_func_array()) will be implemented?
I read something about new_object_array() in today's PHP4 bug summary report ... will
this function be
Hi,
So now that the PEAR framework for bundling extensions is in place, I
figured I'd start a thread about moving all extensions to PECL, and then
selectively bundling them from PECL (perhaps maintaining physical
aliases as well.)
With the new system, when a release is made, the RM simply needs t
>
> So now that the PEAR framework for bundling extensions is in
> place, I figured I'd start a thread about moving all
> extensions to PECL, and then selectively bundling them from
> PECL (perhaps maintaining physical aliases as well.)
>
I'm +1 on this.. And already offered to move stuff, s
James Cox wrote:
So now that the PEAR framework for bundling extensions is in
place, I figured I'd start a thread about moving all
extensions to PECL, and then selectively bundling them from
PECL (perhaps maintaining physical aliases as well.)
I'm +1 on this.. And already offered to move stuf
Hello Sterling,
Saturday, June 7, 2003, 7:15:23 PM, you wrote:
SH> Hi,
SH> So now that the PEAR framework for bundling extensions is in place, I
SH> figured I'd start a thread about moving all extensions to PECL, and then
SH> selectively bundling them from PECL (perhaps maintaining physical
SH>
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.
Also for extensions like ext/gd i don't see any reason to move them
out of the
On 7 Jun 2003, Sterling Hughes wrote:
> Hi,
>
> So now that the PEAR framework for bundling extensions is in place, I
> figured I'd start a thread about moving all extensions to PECL, and then
> selectively bundling them from PECL (perhaps maintaining physical
> aliases as well.)
-1
I'm strongly
I have been hearing about a move to PECL.
What is the difference between an extension compiled into libphp4.so
versus and extension in PECL?
Can someone fill me in.
md
--
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?)
Regards
Alan
Sterling Hughes wrote:
Hi,
So now that the PEAR framework for
I agree with Edin here. We need to make sure the Windows builds are not too
far behind the *nix releases. In other words we need to make sure
everyting is in place to build and release on Win32 before we move all
extensions.
- Frank
> On 7 Jun 2003, Sterling Hughes wrote:
>
> > Hi,
> >
> > So n
12 matches
Mail list logo