not look like a huge amount of work to me, so I really am
wondering what I am missing here... maybe a formal declaration from the
core devs that extensions not providing a version info will not be
accepted anymore, starting NOW?
Thanks
Gaetano Giunta
--
PHP Internals - PHP Runtime Development
Hello everybody.
I did a bit of analysis concerning the versioning information exposed by all
extensions in 5.2.5 [the data in zend_module_entry, exposed to userland via
phpversion()].
Extensions that do not expose any info at all: 46 out of 83 (the total number
being calculated by counting t
...
- oci extension ONLY updated version info (1.2.3 to 1.2.4) but NOT the code!
OCI8 is (still) a PECL extension, so it's release cycle is not synced with PHP.
Yes I know. We have been testing recent versions a quite bit lately
because of a strange problem with cursors remaining open
plus a 3 numbered version is very easy to assign to a lib (you know,
like a new param for a function bumps up the middle number, a fix - any
fix - bumps up the rightmost one etc... )
That is what $Revision$ CVS tag does, version number is totally different thing
IMO.
Sorry, but I di
Stanislav Malyshev wrote:
...
The question is - should we have an error there? If
so, which one - E_WARNING, E_NOTICE? I'm for E_WARNING.
+1
Also please add at least a warning when errors are found in decoding process,
so that it is somewhat feasible to distinguish a bad decode from
json_de
versions of the files are included
Ideas for further improvement:
+ add table of all available branches in the extensions list page (one
column per branch)
+ add compile log, date, size, in the extensions list page (when
filtered by single branch)
+ other ?
Bye
Gaetano Giunta
--
PHP Internals
Just to add my experience (even though the original poster explicitly
asked for single extensions not to be mentioned) from a
not-completely-unrelated problem: some extensions have an "internal"
version number that is not always updated when the userland API of said
extension is changed - see e
those which are deemed
important enough (judge important as you would like).
PECL contained other extensions - those NOT part of the windows
"standard" package.
On 27/05/07, Gaetano Giunta <[EMAIL PROTECTED]> wrote:
> Just to add my experience (even though the original p
on 2007-05-29 03:17:04 (for php 5.2 and 5.1)
On 5/29/07, Richard Quadling <[EMAIL PROTECTED]> wrote:
Isn't PECL4WIN "official"? It's on the php.net domain.
On 29/05/07, Gaetano Giunta <[EMAIL PROTECTED]> wrote:
> As a side note: does anyone think t
Here's one more little patch: add extension name and link to pecl site on
the pecl4win page listing a single extension (the underlying assumption is
files are named after extensions...)
--- ext.phpTue May 29 17:40:20 2007
+++ ext2.phpTue May 29 17:41:25 2007
@@ -7,7 +7,17 @@
$args = expl
One more patch: a php file to generate rss feeds for pecl4win releases.
It can list all files or all files for a given php branch.
The base rss code is taken from pecl rss.
It assumes that for every extension and php branch, there is only one
file in the db (ie. not many builds corresponding to
s
+$php $base/bin/clean_ext2.php 6_0
+$php $base/bin/mk52.php 6_0
rm -f $base/lock.pecl
New file: fetch.php
* Given a pecl extension name and a target dir, downloads all versions
from pecl
* and unpacks them as subdirectories. Optionally gets a single given
version
* ('last' a
? Is there any (easy)
workaround other than "if the file is not in the distribution, try
getting it from cvs"?
Thanks
Gaetano Giunta
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
...
The first problem I have found is that the APC extension (the first I
tested) has no config.w32 file included in the distribution, even
though one is present in CVS (and has been for quite a while afaict).
This prevents a successful build of the extensions under windows
(note: I only test
Thanks for your encouraging words.
I ran a "complete" build today against php 5.2.3, and these are the stats:
- 134 packaged extensions downloaded from pecl website (sniffed the list
out of cvs.php.net, then got the latest existing package for every one)
of those: only 61 have a config.w32 fil
I think I finally have something demoable, regarding the possibility of
extending pecl4win to offer compiled dlls of the released version pf
pecl packages, besides the compiled cvs version.
The build process is almost ok:
+ two separate build environments (incl. pecl trees) are used: one for
p
On 7/12/07, chris# <[EMAIL PROTECTED]> wrote:
On Thu, 12 Jul 2007 11:38:44 +0200, Tijnema <[EMAIL PROTECTED]> wrote:
> Hello Richard,
>
> On 7/12/07, Richard Lynch <[EMAIL PROTECTED]> wrote:
>> On Wed, July 11, 2007 6:13 pm, Tijnema wrote:
>> > On 7/12/07, Jani Taskinen <[EMAIL PROTECTED]> wro
On Wed, 18 Jul 2007, Zeev Suraski wrote:
...
You know what, I agree. I wrote something to that effect in my post
from a few minutes ago. The vast userbase is mostly comprised of
people we hardly even get to see.
Sorry to chime in on this already long thread with my -negative-
commit karma, but
Shameless plug: I just posted a beginner's tutorial on my own
multiple-php-installs setup:
http://gggeek.altervista.org/2007/07/21/running-multiple-php-versions-on-a-single-apache-install/
it contains links to many similar blog posts that a quick Google search
returned.
The most complete one is:
I have just uploaded my patched pecl4win repo to
http://gggeek.altervista.org/sw/peclwin/
the code is still far for complete (eg php 4 build script is not
finished), but at least I added a dirt quick readme and a sql migration
script (not tested ;) for existing pecl4win installs.
building pa
Pierre wrote:
Hi Gaetano,
I see that you list the version as well. Do you build the packages
yourself using the latest (and best state) release? Or do you rely on
what we have now for pecl4win?
I am not sure I understand the question 100%...
What I do is:
- fetch list of extensions from pecl.p
On 7/22/07, Pierre <[EMAIL PROTECTED]> wrote:
On 7/22/07, Gaetano Giunta <[EMAIL PROTECTED]> wrote:
> What I do is:
> - fetch list of extensions from pecl.php.net, getting the html page of
> cvs.php.net/pecl4win/ and scanning it
> - fetch the latest and greatest version
But pushing the PHP docs (as Steph suggested later) to your site will
only bring you more questions about php's CURL binding. It sounds like
a bad idea :)
The fact is that Daniel does a wonderful job giving out plenty of advice to
php/curl help seekers not just on its website (I'd go as far as
23 matches
Mail list logo
