Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:29866 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 51391 invoked by uid 1010); 29 May 2007 15:03:26 -0000 Delivered-To: ezmlm-scan-internals@lists.php.net Delivered-To: ezmlm-internals@lists.php.net Received: (qmail 51375 invoked from network); 29 May 2007 15:03:26 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 29 May 2007 15:03:26 -0000 Authentication-Results: pb1.pair.com smtp.mail=rquadling@googlemail.com; spf=pass; sender-id=pass Authentication-Results: pb1.pair.com header.from=rquadling@googlemail.com; sender-id=pass; domainkeys=bad Received-SPF: pass (pb1.pair.com: domain googlemail.com designates 64.233.184.231 as permitted sender) DomainKey-Status: bad X-DomainKeys: Ecelerity dk_validate implementing draft-delany-domainkeys-base-01 X-PHP-List-Original-Sender: rquadling@googlemail.com X-Host-Fingerprint: 64.233.184.231 wr-out-0506.google.com Linux 2.4/2.6 Received: from [64.233.184.231] ([64.233.184.231:56055] helo=wr-out-0506.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id BF/C9-08609-CB04C564 for ; Tue, 29 May 2007 11:03:26 -0400 Received: by wr-out-0506.google.com with SMTP id 58so702424wri for ; Tue, 29 May 2007 08:03:22 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=googlemail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=Pp5qW594jxXVfDSkVcm8O6FXtCm6xDj/LzRLCrsxHd+UqBsJI+f9a3WOtgdHCWRt3PO/xv9pJyYXhg3IMz6brDBDGMcrFLFbPrvtpN4z+4uBzItgp9uERXQUtypNB2q8iz3Vo9rk/tPZMYjKldHXgGyrciQ7qCOOkIPF9YWNl6U= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=beta; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=qb384/As2EqL36Y8PQ8EaFsKCGLX7RAXDGLYIywkw7JD8siKIRgp23B/7obODq/jZO1G6xgboudnmj6lF724PVaIxBaqQQqjtxf2x3+KihR/r26qZdm0Wk0qXNKCrM7EI9zWT1tNzHYoVbiZvhQrraK3DxLrOFQ/cHMXl8BajzY= Received: by 10.90.105.19 with SMTP id d19mr4780599agc.1180451002300; Tue, 29 May 2007 08:03:22 -0700 (PDT) Received: by 10.90.84.3 with HTTP; Tue, 29 May 2007 08:03:22 -0700 (PDT) Message-ID: <10845a340705290803l6524f3edrbc676a3bf150f5c@mail.gmail.com> Date: Tue, 29 May 2007 16:03:22 +0100 Reply-To: RQuadling@GoogleMail.com To: "Gaetano Giunta" Cc: internals@lists.php.net In-Reply-To: <9bf34f240705290756v59f30bb6s1a06eb591164c857@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <4658DD8A.8050004@gmail.com> <10845a340705290716h33d23284j1714658e7e6d504c@mail.gmail.com> <9bf34f240705290756v59f30bb6s1a06eb591164c857@mail.gmail.com> Subject: Re: [PHP-DEV] RE: Fixing PECL + Core From: rquadling@googlemail.com ("Richard Quadling") Isn't PECL4WIN "official"? It's on the php.net domain. On 29/05/07, Gaetano Giunta wrote: > As a side note: does anyone think that providing on pecl4win compiled > versions corresponding to the official pecl package releases besides the > "compiled from cvs" versions would be a good idea? > > Bye > Gaetano > > > On 5/29/07, Richard Quadling wrote: > > > > My post about SNAPS and PECLS a little while ago seems relevant to this. > > > > As a windows user, I have to rely on pre-compiled binaries. > > > > It was/is my understanding that SNAPS would provide me with most > > currently succesfully compiled PHP, with some extensions built in and > > some extensions for my ext directory - 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 wrote: > > > 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 eg. Json and the recent change of behavior on > > > decoding scalar values. > > > > > > This makes it very hard for people maintaining php libraries to code > > > defensively and test the version in use to enable workarounds: > > > - the extension version number is useless (if not managed correctly) > > > - the php version number is useless, since the extension might have been > > > downloaded and compiled from pecl and not correspond to the version that > > > is distributed with the core > > > > > > The only option left in this situation is to test the functionality > > > needed first, then use it, much as it is done in js - a very sad state > > > of things... (of course I would not recommend disabling upgrade / > > > backport of a php extension from pecl as a solution) > > > > > > The fact that the extension lives in both pecl and core and the two > > > might be slightly out of sync does not help at all when trying to find > > > out the cause of regressions... > > > > > > Bye > > > Gaetano > > > > > > -- > > > PHP Internals - PHP Runtime Development Mailing List > > > To unsubscribe, visit: http://www.php.net/unsub.php > > > > > > > > > > > > -- > > ----- > > Richard Quadling > > Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498&r=213474731 > > "Standing on the shoulders of some very clever giants!" > > > -- ----- Richard Quadling Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498&r=213474731 "Standing on the shoulders of some very clever giants!"