From owner-freebsd-standards@FreeBSD.ORG Mon May 27 11:06:54 2013 Return-Path: Delivered-To: freebsd-standards@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 656CA37E for ; Mon, 27 May 2013 11:06:54 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 51A966DA for ; Mon, 27 May 2013 11:06:54 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id r4RB6s1L016173 for ; Mon, 27 May 2013 11:06:54 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id r4RB6rNV016171 for freebsd-standards@FreeBSD.org; Mon, 27 May 2013 11:06:53 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 27 May 2013 11:06:53 GMT Message-Id: <201305271106.r4RB6rNV016171@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-standards@FreeBSD.org Subject: Current problem reports assigned to freebsd-standards@FreeBSD.org X-BeenThere: freebsd-standards@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Standards compliance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 May 2013 11:06:54 -0000 Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o stand/177742 standards conflict of dd's bs= option with use of conv=sparse o stand/176683 standards catman pages shall be stored in /var (/usr/local/var,/ o stand/176412 standards newfs writes by default, compare to bsdlabel/disklabel o stand/175711 standards When the server has more than 3 days, rising interrupt o stand/175453 standards Catching C++ std::bad_cast doesn't work in FreeBSD 9.1 o stand/174938 standards Problem statement: iSCSI target failure o stand/173421 standards [libc] [patch] strptime() accepts formats that should o stand/173087 standards pax(1) does not support the pax interchange format o stand/172805 standards Fix catopen(3)'s EINVAL usage and document EFTYPE o stand/172276 standards POSIX: {get,set}groups gidsetsize is u_int not int o stand/172215 standards localeconv() grouping appears not to match POSIX o stand/170403 standards wrong ntohs expression type tickling clang o stand/169697 standards syslogd(8) is not BOM aware o stand/166349 standards Support the assignment-allocation character for fscanf p stand/164787 standards dirfd() function not available when _POSIX_C_SOURCE is o kern/164674 standards [patch] [libc] vfprintf/vfwprintf return error (EOF) o o stand/162434 standards getaddrinfo: addrinfo.ai_family is an address family, o stand/150093 standards C++ std::locale support is broken o stand/130067 standards Wrong numeric limits in system headers? o stand/124860 standards flockfile(3) doesn't work when the memory has been exh o stand/121921 standards [patch] Add leap second support to at(1), atrun(8) o stand/116477 standards rm(1): rm behaves unexpectedly when using -r and relat o bin/116413 standards incorrect getconf(1) handling of unsigned constants gi o stand/116081 standards make does not work with the directive sinclude a stand/86484 standards [patch] mkfifo(1) uses wrong permissions o stand/82654 standards C99 long double math functions are missing o stand/81287 standards [patch] fingerd(8) might send a line not ending in CRL a stand/80293 standards sysconf() does not support well-defined unistd values o stand/79056 standards [feature request] [atch] regex(3) regression tests o stand/70813 standards [patch] ls(1) not Posix compliant o stand/66357 standards make POSIX conformance problem ('sh -e' & '+' command- s kern/64875 standards [libc] [patch] [request] add a system call: fdatasync( o stand/56476 standards [patch] cd9660 unicode support simple hack o stand/54410 standards one-true-awk not POSIX compliant (no extended REs) o stand/46119 standards Priority problems for SCHED_OTHER using pthreads o stand/44365 standards [headers] [patch] [request] introduce ulong and unchar a stand/41576 standards ln(1): replacing old dir-symlinks a docs/26003 standards getgroups(2) lists NGROUPS_MAX but not syslimits.h s stand/24590 standards timezone function not compatible witn Single Unix Spec o stand/21519 standards sys/dir.h should be deprecated some more s bin/14925 standards getsubopt isn't poisonous enough 41 problems total. From owner-freebsd-standards@FreeBSD.ORG Tue May 28 01:11:02 2013 Return-Path: Delivered-To: freebsd-standards@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 72AE5DAC for ; Tue, 28 May 2013 01:11:02 +0000 (UTC) (envelope-from marketing@genevafiduciary.com) Received: from sd-34195.dedibox.fr (unknown [IPv6:2a01:e0b:1:154:ea9a:8fff:fe13:81da]) by mx1.freebsd.org (Postfix) with ESMTP id 244A7C39 for ; Tue, 28 May 2013 01:10:59 +0000 (UTC) Received: by sd-34195.dedibox.fr (Postfix, from userid 10000) id 9A5F93DE1BF; Tue, 28 May 2013 03:10:53 +0200 (CEST) To: Freebsd Standards Subject: =?utf-8?B?zqbPhM63zr3OrCDPhM+DzrnOs86sz4HOsSDPg861IM6xz4DOtc+FzrjOtc6v?= =?utf-8?B?zrHPgiDPg8+Nzr3OtM61z4POtw==?= X-PHP-Originating-Script: 10000:class.phpmailer.php Date: Tue, 28 May 2013 03:10:53 +0200 From: Tamara Message-ID: X-Priority: 3 X-Mailer: PHPMailer (phpmailer.sourceforge.net) [version 2.0.4] MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-standards@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Tamara List-Id: Standards compliance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 May 2013 01:11:02 -0000 Είστε καπνιστής Marlboro? Θέλετε να αποθηκεύσετε τα χρήματά σας για το κάπνισμα? Επισκεφθείτε το online κατάστημα αφορολόγητων μας! http://smokecoins.com μέχρι το τέλος του Μαΐου σε απευθείας σύνδεση κατάστημα αφορολόγητων μας έχει μια ειδική τιμή για Marlboro κόκκινο! Γρήγορα στέλνοντας, δίκαιη τιμή σας περιμένουν. Are you a Marlboro smoker? You want to save your money on smoking? Visit our online duty free shop! www.smokecoins.com up to the end of May our online duty free shop has a special price on Marlboro red! Fast shipping , fair price are waiting for you. Unsubscribe ( http://genevafiduciary.com/joomla/index.php?subid=1064328&option=com_acymailing&ctrl=user&task=out&mailid=14&key=26da4bd0e799bcca520bebb97d76f927 ) From owner-freebsd-standards@FreeBSD.ORG Thu May 30 06:46:42 2013 Return-Path: Delivered-To: freebsd-standards@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 2382A99; Thu, 30 May 2013 06:46:42 +0000 (UTC) (envelope-from das@FreeBSD.ORG) Received: from zim.MIT.EDU (50-196-151-174-static.hfc.comcastbusiness.net [50.196.151.174]) by mx1.freebsd.org (Postfix) with ESMTP id E36AE298; Thu, 30 May 2013 06:46:41 +0000 (UTC) Received: from zim.MIT.EDU (localhost [127.0.0.1]) by zim.MIT.EDU (8.14.7/8.14.2) with ESMTP id r4U6kZEU091680; Wed, 29 May 2013 23:46:35 -0700 (PDT) (envelope-from das@FreeBSD.ORG) Received: (from das@localhost) by zim.MIT.EDU (8.14.7/8.14.2/Submit) id r4U6kZIJ091679; Wed, 29 May 2013 23:46:35 -0700 (PDT) (envelope-from das@FreeBSD.ORG) Date: Wed, 29 May 2013 23:46:35 -0700 From: David Schultz To: David Chisnall Subject: Re: standards/175811: libstdc++ needs complex support in order use C99 Message-ID: <20130530064635.GA91597@zim.MIT.EDU> References: <201302040328.r143SUd3039504@freefall.freebsd.org> <510F306A.6090009@missouri.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Cc: Stephen Montgomery-Smith , pfg@freebsd.org, freebsd-standards@freebsd.org, freebsd-numerics@freebsd.org X-BeenThere: freebsd-standards@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Standards compliance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 May 2013 06:46:42 -0000 On Fri, Feb 22, 2013, David Chisnall wrote: > On 4 Feb 2013, at 03:52, Stephen Montgomery-Smith wrote: > > > We do really seem to have a lot of working code right now. And the main > > barrier to commitment seems to be style issues. > > > > For example, I have code at http://people.freebsd.org/~stephen/ for the > > complex arctrig functions. And Bruce has clog available. And > > presumably he has logl and atanl also available. > > > > The last I heard about my code is Bruce asking for some style changes. > > However I really don't think I will have time to work on it until at > > least the summer. And to be honest, style just isn't my thing. > > > > I propose (a) that someone else takes over my code (and maybe Bruce's > > code) and make the style changes, or (b) that we get a little less fussy > > about getting it all just so right and start committing stuff. > > > > Let me add that the code we have is already far superior than anything > > in Linux or NetBSD, who clearly didn't worry about huge numerical errors > > in many edge cases. Come on guys, let's start strutting our stuff. > > > > Let's commit what we have, even if it isn't perfect. > > Yes, please can this happen? We are currently on 31 test > failures in the libc++ test suite on -HEAD, of which at least 18 > are due to linker failures trying to find missing libm > functions. We are very close to having a complete C++11 > implementation, yet we are held up by the lack of C99 support, > and we are held up there by style nits? > > On behalf of core, please can we commit the existing code and > worry about the style later? Given the expertise required to > work on the libm functions, most of the people who are able to > hack on the code have already read it and so concerns about > consistency readability are somewhat misplaced. I didn't see this thread until now, but coincidentally, I just wrote tests and manpages for and committed Stephen's implementations of most of the missing double/float complex functions. I don't know the status of clog() or cpow(), but murray@ has a patch to port the NetBSD versions, which I'm also willing to commit given the unacceptable delays in producing something better. I was wondering if you could explain a bit about what your goal is here, though. Is there some kind of certification you are trying to achieve? Why can't you just comment out the few missing functions? You've been adamant about this issue ever since joining the Project, even suggesting that we commit bogus implementations just for the sake of having the symbols. I completely agree with you that the lack of progress is unacceptable, and I'm sorry I haven't had more time to work on this stuff myself, but I also don't understand the source of your urgency. The reason I'm asking is that I'm pushing to get a lot of stuff into the tree quickly, but realistically, in the short term we're only going to get 95% of the way there. I doubt good implementations of complicated functions that nobody uses, such as erfcl() and tgammal(), are going to appear overnight. Thus, I would like to know whether the last 5% is needed quickly, and if so, why. From owner-freebsd-standards@FreeBSD.ORG Thu May 30 13:56:27 2013 Return-Path: Delivered-To: freebsd-standards@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 6889F490 for ; Thu, 30 May 2013 13:56:27 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-ie0-x22c.google.com (mail-ie0-x22c.google.com [IPv6:2607:f8b0:4001:c03::22c]) by mx1.freebsd.org (Postfix) with ESMTP id 39694371 for ; Thu, 30 May 2013 13:56:27 +0000 (UTC) Received: by mail-ie0-f172.google.com with SMTP id 17so656652iea.31 for ; Thu, 30 May 2013 06:56:27 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=IORAOblq2wOwGWSdSoX5BpqP8LFSxOX+toid05IcPvk=; b=e8nMr/hInpTU66HYPqmSefZ4tnlkAST6k602doDyp97SE8LCA5DTHeUCdkKgCztsyH TmvlM9PiyhCuO+YgQRAhxBVD+8QozgEHGg4gthJn2Ka34tpUR34B2hIEpa+s3aFQTtSl AtlmBf/O3aKT94/gfnM4McS9zHVtpqWbtUe7taRNsBInuexppm1or3fhiPm84eUkN633 O8U9O/1Y3APl9f/XjZ5h+HkeyqfzxcE5JRcXsjhxWdi5Fiw/KSpAb0hvgGqo64xMKwRW WXD+Su/n0PsCXsTIeXLXixMej1xXFQRNkjDX515JSpfojI64JEq4kOPFEGx4rBY/SKAd TMjA== X-Received: by 10.50.25.4 with SMTP id y4mr3701347igf.111.1369922186925; Thu, 30 May 2013 06:56:26 -0700 (PDT) Received: from 53.imp.bsdimp.com (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPSA id ik6sm7054727igb.3.2013.05.30.06.56.25 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 30 May 2013 06:56:26 -0700 (PDT) Sender: Warner Losh Subject: Re: standards/175811: libstdc++ needs complex support in order use C99 Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <20130530064635.GA91597@zim.MIT.EDU> Date: Thu, 30 May 2013 07:56:24 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201302040328.r143SUd3039504@freefall.freebsd.org> <510F306A.6090009@missouri.edu> <20130530064635.GA91597@zim.MIT.EDU> To: David Schultz X-Mailer: Apple Mail (2.1085) X-Gm-Message-State: ALoCoQko0mRj1NS5YJj2oSKB9Gfc/Ognh/WvgQvY2jzRE6NP83ROYdngu/rsFyoEPo26SVS7eR7x Cc: Stephen Montgomery-Smith , freebsd-standards@freebsd.org, pfg@freebsd.org, freebsd-numerics@freebsd.org X-BeenThere: freebsd-standards@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Standards compliance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 May 2013 13:56:27 -0000 On May 30, 2013, at 12:46 AM, David Schultz wrote: > On Fri, Feb 22, 2013, David Chisnall wrote: >> On 4 Feb 2013, at 03:52, Stephen Montgomery-Smith = wrote: >>=20 >>> We do really seem to have a lot of working code right now. And the = main >>> barrier to commitment seems to be style issues. >>>=20 >>> For example, I have code at http://people.freebsd.org/~stephen/ for = the >>> complex arctrig functions. And Bruce has clog available. And >>> presumably he has logl and atanl also available. >>>=20 >>> The last I heard about my code is Bruce asking for some style = changes. >>> However I really don't think I will have time to work on it until at >>> least the summer. And to be honest, style just isn't my thing. >>>=20 >>> I propose (a) that someone else takes over my code (and maybe = Bruce's >>> code) and make the style changes, or (b) that we get a little less = fussy >>> about getting it all just so right and start committing stuff. >>>=20 >>> Let me add that the code we have is already far superior than = anything >>> in Linux or NetBSD, who clearly didn't worry about huge numerical = errors >>> in many edge cases. Come on guys, let's start strutting our stuff. >>>=20 >>> Let's commit what we have, even if it isn't perfect. >>=20 >> Yes, please can this happen? We are currently on 31 test >> failures in the libc++ test suite on -HEAD, of which at least 18 >> are due to linker failures trying to find missing libm >> functions. We are very close to having a complete C++11 >> implementation, yet we are held up by the lack of C99 support, >> and we are held up there by style nits? >>=20 >> On behalf of core, please can we commit the existing code and >> worry about the style later? Given the expertise required to >> work on the libm functions, most of the people who are able to >> hack on the code have already read it and so concerns about >> consistency readability are somewhat misplaced. >=20 > I didn't see this thread until now, but coincidentally, I just > wrote tests and manpages for and committed Stephen's > implementations of most of the missing double/float complex > functions. I don't know the status of clog() or cpow(), but > murray@ has a patch to port the NetBSD versions, which I'm also > willing to commit given the unacceptable delays in producing > something better. I'm all for better progress... Thank you for your efforts. > I was wondering if you could explain a bit about what your goal is > here, though. Is there some kind of certification you are trying > to achieve? Why can't you just comment out the few missing > functions? You've been adamant about this issue ever since > joining the Project, even suggesting that we commit bogus > implementations just for the sake of having the symbols. I > completely agree with you that the lack of progress is > unacceptable, and I'm sorry I haven't had more time to work on > this stuff myself, but I also don't understand the source of your > urgency. More and more projects are refusing to work around our gridlock. We have = to report R each new release because they have taken out the checks for = the missing symbols. It is really an embarrassment to the project. We've = let the perfect be the enemy of the good. There are R scripts that run = elsewhere and not on FreeBSD. R is the one I know most about since I've = been using R a lot to crunch numbers for work, but there are others. The urgency is we'd like to have this stuff done for 10, if at all = possible. And if not done, then a lot closer to done than where we are = today. > The reason I'm asking is that I'm pushing to get a lot of stuff > into the tree quickly, but realistically, in the short term we're > only going to get 95% of the way there. I doubt good > implementations of complicated functions that nobody uses, such as > erfcl() and tgammal(), are going to appear overnight. Thus, I > would like to know whether the last 5% is needed quickly, and if > so, why. I'm all for getting everything we can into the tree that produces an = answer that's not perfect, but close. What's the error that would be = generated with the naive implementation of long double tgammal(long double f) { return tgamma(f); } But assuming that, for some reason, produces errors larger than = difference in precision between double and long double due to extreme = non-linearity of these functions, having only a couple of stragglers is = a far better position to be in than we are today. Warner= From owner-freebsd-standards@FreeBSD.ORG Thu May 30 15:41:35 2013 Return-Path: Delivered-To: freebsd-standards@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id F35697E6 for ; Thu, 30 May 2013 15:41:34 +0000 (UTC) (envelope-from pfg@FreeBSD.org) Received: from nm1-vm1.bullet.mail.bf1.yahoo.com (nm1-vm1.bullet.mail.bf1.yahoo.com [98.139.213.163]) by mx1.freebsd.org (Postfix) with ESMTP id 7C521FC4 for ; Thu, 30 May 2013 15:41:34 +0000 (UTC) Received: from [98.139.212.148] by nm1.bullet.mail.bf1.yahoo.com with NNFMP; 30 May 2013 15:41:26 -0000 Received: from [98.139.213.1] by tm5.bullet.mail.bf1.yahoo.com with NNFMP; 30 May 2013 15:41:26 -0000 Received: from [127.0.0.1] by smtp101.mail.bf1.yahoo.com with NNFMP; 30 May 2013 15:41:26 -0000 X-Yahoo-Newman-Id: 935342.47691.bm@smtp101.mail.bf1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: BabCFEIVM1lG9dYnW0ApjKaEQqUYGRIAOt95Of5VL7lslDw 0SRE1wwwyNyDyIYQy66ygEjPe6WvzbZGx1_14Uqt.pJG7ajhMWlfJ2Rcog3t lc0B38qJMe5sQbKyCW5TWjhnUylJjTyR5n.WRZ2EtMiFrtUTfyZ87dOKlukE U1bKMm8zbhHnofWl1A07iDouURYQuE7K6wWZTLSkq4d5IcGwJXhdLBRB8fRe QZvru99NhC6ilipyqs5L5EQ2nGXuC119FBFGtRW.lnCVIYBoPvgkC4bp6nlb yP06pOh0bLk3iPCLlMV6YesWHCGeHOc8_vey5u0YIpbtMMF5IzmZ86n9BOJi ldaaO5flRnSazS74aaymGXFqnPdu5tMZO1Uk5YKh7CM3qE45jEyuyyNBMNGB ETYNxtK9yZhCb6qj_1shzgXD3lsk9KJpkE.5V7Lx0BISJxMX8.LfzKH3SEEi v6kZhhLXqJ46cc8UiLL_rvMicLBDEPMfzvgmTSJDHUsY.ChNmmQExPlKFtVo VFAOcRTrTq.m1DjlRzF_qK8vVFnBjstRupPyp9ikT2ZhmPf40xePLB1IxMxZ yfl_PCsd1c737uQ-- X-Yahoo-SMTP: xcjD0guswBAZaPPIbxpWwLcp9Unf X-Rocket-Received: from [192.168.0.102] (pfg@190.157.126.109 with ) by smtp101.mail.bf1.yahoo.com with SMTP; 30 May 2013 15:41:26 +0000 UTC Message-ID: <51A77324.2070702@FreeBSD.org> Date: Thu, 30 May 2013 10:41:24 -0500 From: Pedro Giffuni User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130407 Thunderbird/17.0.5 MIME-Version: 1.0 To: David Schultz Subject: Re: standards/175811: libstdc++ needs complex support in order use C99 References: <201302040328.r143SUd3039504@freefall.freebsd.org> <510F306A.6090009@missouri.edu> <20130530064635.GA91597@zim.MIT.EDU> In-Reply-To: <20130530064635.GA91597@zim.MIT.EDU> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Stephen Montgomery-Smith , freebsd-standards@freebsd.org, freebsd-numerics@freebsd.org X-BeenThere: freebsd-standards@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Standards compliance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 May 2013 15:41:35 -0000 On 30.05.2013 01:46, David Schultz wrote: > On Fri, Feb 22, 2013, David Chisnall wrote: >> On 4 Feb 2013, at 03:52, Stephen Montgomery-Smith wrote: >> >>> We do really seem to have a lot of working code right now. And the main >>> barrier to commitment seems to be style issues. >>> >>> For example, I have code at http://people.freebsd.org/~stephen/ for the >>> complex arctrig functions. And Bruce has clog available. And >>> presumably he has logl and atanl also available. >>> >>> The last I heard about my code is Bruce asking for some style changes. >>> However I really don't think I will have time to work on it until at >>> least the summer. And to be honest, style just isn't my thing. >>> >>> I propose (a) that someone else takes over my code (and maybe Bruce's >>> code) and make the style changes, or (b) that we get a little less fussy >>> about getting it all just so right and start committing stuff. >>> >>> Let me add that the code we have is already far superior than anything >>> in Linux or NetBSD, who clearly didn't worry about huge numerical errors >>> in many edge cases. Come on guys, let's start strutting our stuff. >>> >>> Let's commit what we have, even if it isn't perfect. >> Yes, please can this happen? We are currently on 31 test >> failures in the libc++ test suite on -HEAD, of which at least 18 >> are due to linker failures trying to find missing libm >> functions. We are very close to having a complete C++11 >> implementation, yet we are held up by the lack of C99 support, >> and we are held up there by style nits? >> >> On behalf of core, please can we commit the existing code and >> worry about the style later? Given the expertise required to >> work on the libm functions, most of the people who are able to >> hack on the code have already read it and so concerns about >> consistency readability are somewhat misplaced. > I didn't see this thread until now, but coincidentally, I just > wrote tests and manpages for and committed Stephen's > implementations of most of the missing double/float complex > functions. I don't know the status of clog() or cpow(), but > murray@ has a patch to port the NetBSD versions, which I'm also > willing to commit given the unacceptable delays in producing > something better. Thank you !! > I was wondering if you could explain a bit about what your goal is > here, though. Is there some kind of certification you are trying > to achieve? Why can't you just comment out the few missing > functions? You've been adamant about this issue ever since > joining the Project, even suggesting that we commit bogus > implementations just for the sake of having the symbols. I > completely agree with you that the lack of progress is > unacceptable, and I'm sorry I haven't had more time to work on > this stuff myself, but I also don't understand the source of your > urgency. What I am finding rather disappointing is that our libstdc++ lacks so many features wrt to what is expected from developers used to linux. I think it's reasonable to think that libc++ will require the same features as modern libstdc++ to support a quality port. In addition to R, the current situation also has undesirable effects in boost, where we don't support long double (nevermind the bogus patch on our ports tree). if we if we can just get our local libstdc++ to use C99 that would be an advance. The target at this time would be resolving standards/175811 and it would also be interesting to see what the upstream gcc/libstdc++ requires. > The reason I'm asking is that I'm pushing to get a lot of stuff > into the tree quickly, but realistically, in the short term we're > only going to get 95% of the way there. I doubt good > implementations of complicated functions that nobody uses, such as > erfcl() and tgammal(), are going to appear overnight. Thus, I > would like to know whether the last 5% is needed quickly, and if > so, why. I may be wrong but with long double support people that need erfcl() and tgamma() can get them from boost. The problem is therefore not implementing everything but getting enough to turn on the features supported by libstdc++ and boost. Pedro. From owner-freebsd-standards@FreeBSD.ORG Thu May 30 16:52:38 2013 Return-Path: Delivered-To: freebsd-standards@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 9B52D882; Thu, 30 May 2013 16:52:38 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from fallbackmx08.syd.optusnet.com.au (fallbackmx08.syd.optusnet.com.au [211.29.132.10]) by mx1.freebsd.org (Postfix) with ESMTP id B6C2C669; Thu, 30 May 2013 16:52:37 +0000 (UTC) Received: from mail28.syd.optusnet.com.au (mail28.syd.optusnet.com.au [211.29.133.169]) by fallbackmx08.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id r4UGqRRB032572; Fri, 31 May 2013 02:52:27 +1000 Received: from c122-106-156-23.carlnfd1.nsw.optusnet.com.au (c122-106-156-23.carlnfd1.nsw.optusnet.com.au [122.106.156.23]) by mail28.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id r4UGqDd8011312 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 31 May 2013 02:52:14 +1000 Date: Fri, 31 May 2013 02:52:13 +1000 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Warner Losh Subject: Re: standards/175811: libstdc++ needs complex support in order use C99 In-Reply-To: Message-ID: <20130531015915.N65390@besplex.bde.org> References: <201302040328.r143SUd3039504@freefall.freebsd.org> <510F306A.6090009@missouri.edu> <20130530064635.GA91597@zim.MIT.EDU> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.0 cv=BPvrNysG c=1 sm=1 a=Qub1x3MNGSYA:10 a=kj9zAlcOel0A:10 a=PO7r1zJSAAAA:8 a=JzwRw_2MAAAA:8 a=AyPkC9FW8vsA:10 a=gmrSIYXE1WnqeYESaG8A:9 a=CjuIK1q_8ugA:10 a=ebeQFi2P/qHVC0Yw9JDJ4g==:117 Cc: Stephen Montgomery-Smith , pfg@FreeBSD.org, freebsd-numerics@FreeBSD.org, David Schultz , freebsd-standards@FreeBSD.org X-BeenThere: freebsd-standards@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Standards compliance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 May 2013 16:52:38 -0000 On Thu, 30 May 2013, Warner Losh wrote: > I'm all for getting everything we can into the tree that produces an answer that's not perfect, but close. What's the error that would be generated with the naive implementation of > > long double tgammal(long double f) { return tgamma(f); } On x86, 11 low bits wrong, for an error of 2048 ulps, in addition to any errors in tgamma(). tgamma() on i386 inherits errors of 9 peta-ulps (all 53 bits wrong) from i387 trig functions, but is OK on small args on i386 and better on large args on amd64. On sparc64, 60 low bits wrong, for an error of 1 exa-ulp, in addition to any errors in tgamma(); the latter are the same as on amd64. Sparc64 users of long double precision pay for it with a loss of performance of a factor of several hundred, so they should be unhappy to not get he extra bits when they ask for them (but the above inaccurate version doesn't give them what they asked for). On arches with long double == double, no difference. On i386 with the default rounding precision of double, little difference. > But assuming that, for some reason, produces errors larger than difference in precision between double and long double due to extreme non-linearity of these functions, having only a couple of stragglers is a far better position to be in than we are today. Such extra errors normally don't happen. In fact, my accuracy tests for double functions are essentially to upcast the results of double functions and compare the resulting bits with the corresponding results for long double functions. Nonlinearities tend to only happen at zeros and poles of functions and then they are due to bugs, and for NaNs, and then they are due to implementation-defined behaviour. It is difficult to even determine the location of zeros and poles for some functions, and most of the complexities in libm are to uses especially careful calculations near them when they are known. Bruce From owner-freebsd-standards@FreeBSD.ORG Thu May 30 16:56:14 2013 Return-Path: Delivered-To: freebsd-standards@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 8BF9A8E8; Thu, 30 May 2013 16:56:14 +0000 (UTC) (envelope-from das@FreeBSD.ORG) Received: from zim.MIT.EDU (50-196-151-174-static.hfc.comcastbusiness.net [50.196.151.174]) by mx1.freebsd.org (Postfix) with ESMTP id 614A1690; Thu, 30 May 2013 16:56:13 +0000 (UTC) Received: from zim.MIT.EDU (localhost [127.0.0.1]) by zim.MIT.EDU (8.14.7/8.14.2) with ESMTP id r4UGuBTH093763; Thu, 30 May 2013 09:56:11 -0700 (PDT) (envelope-from das@FreeBSD.ORG) Received: (from das@localhost) by zim.MIT.EDU (8.14.7/8.14.2/Submit) id r4UGuARj093762; Thu, 30 May 2013 09:56:10 -0700 (PDT) (envelope-from das@FreeBSD.ORG) Date: Thu, 30 May 2013 09:56:10 -0700 From: David Schultz To: Warner Losh Subject: Re: standards/175811: libstdc++ needs complex support in order use C99 Message-ID: <20130530165610.GA93684@zim.MIT.EDU> References: <201302040328.r143SUd3039504@freefall.freebsd.org> <510F306A.6090009@missouri.edu> <20130530064635.GA91597@zim.MIT.EDU> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Cc: Stephen Montgomery-Smith , pfg@freebsd.org, freebsd-standards@freebsd.org, freebsd-numerics@freebsd.org X-BeenThere: freebsd-standards@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Standards compliance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 May 2013 16:56:14 -0000 On Thu, May 30, 2013, Warner Losh wrote: > > On May 30, 2013, at 12:46 AM, David Schultz wrote: > > On Fri, Feb 22, 2013, David Chisnall wrote: > > I was wondering if you could explain a bit about what your goal is > > here, though. Is there some kind of certification you are trying > > to achieve? Why can't you just comment out the few missing > > functions? You've been adamant about this issue ever since > > joining the Project, even suggesting that we commit bogus > > implementations just for the sake of having the symbols. I > > completely agree with you that the lack of progress is > > unacceptable, and I'm sorry I haven't had more time to work on > > this stuff myself, but I also don't understand the source of your > > urgency. > > More and more projects are refusing to work around our > gridlock. We have to report R each new release because they have > taken out the checks for the missing symbols. It is really an > embarrassment to the project. We've let the perfect be the enemy > of the good. There are R scripts that run elsewhere and not on > FreeBSD. R is the one I know most about since I've been using R > a lot to crunch numbers for work, but there are others. > > The urgency is we'd like to have this stuff done for 10, if at > all possible. And if not done, then a lot closer to done than > where we are today. It looks like the R in ports just wants logl(), which isn't surprising, and there's already code for that. So getting that in for 10 is achievable. > > The reason I'm asking is that I'm pushing to get a lot of stuff > > into the tree quickly, but realistically, in the short term we're > > only going to get 95% of the way there. I doubt good > > implementations of complicated functions that nobody uses, such as > > erfcl() and tgammal(), are going to appear overnight. Thus, I > > would like to know whether the last 5% is needed quickly, and if > > so, why. > > I'm all for getting everything we can into the tree that > produces an answer that's not perfect, but close. What's the > error that would be generated with the naive implementation of > > long double tgammal(long double f) { return tgamma(f); } > > But assuming that, for some reason, produces errors larger than > difference in precision between double and long double due to > extreme non-linearity of these functions, having only a couple > of stragglers is a far better position to be in than we are > today. Whether this is acceptable depends a lot on who needs it in the first place, which is part of why I was asking. For many years, the only software that cared was libstdc++, and libstdc++ only wanted to wrap it. Here are some of my notes on the status of things: long double log2l(long double); -- bde long double logl(long double); -- bde long double log1pl(long double); -- bde Bruce has these written. We can commit them with a little cleanup. long double acoshl(long double); -- sgk long double asinhl(long double); -- sgk long double atanhl(long double); -- sgk long double log10l(long double); -- bde These are trivial given the first three. I believe Bruce and Steve have the code for them already. long double expl(long double); -- sgk long double expm1l(long double); -- sgk Steve has perfectly committable patches that I've already approved (and furthermore, he doesn't need my approval anymore!) long double coshl(long double); long double sinhl(long double); long double tanhl(long double); long double erfcl(long double); long double erfl(long double); These are easy given expl() and expm1l(). long double powl(long double, long double); This is not so easy, but important, so we can make it a priority. long double lgammal(long double); long double tgammal(long double); These are neither easy nor important; this gets back to my question. float complex clogf(float complex); -- bde double complex clog(double complex); -- bde Bruce has code for these, which should be straightforward to turn into something committable. float complex cpowf(float complex, float complex); double complex cpow(double complex, double complex); This one is tough to do well and even tougher to test -- lots of nasty corner cases. long double complex cexpl(long double complex); long double complex ccosl(long double complex); long double complex ccoshl(long double complex); long double complex csinl(long double complex); long double complex csinhl(long double complex); long double complex ctanl(long double complex); long double complex ctanhl(long double complex); long double complex cacosl(long double complex); long double complex cacoshl(long double complex); long double complex casinl(long double complex); long double complex casinhl(long double complex); long double complex catanl(long double complex); long double complex catanhl(long double complex); long double complex clogl(long double complex); long double complex cpowl(long double complex, long double complex); The long double versions of the complex math functions are trivial once the long double versions of the corresponding real functions are written. From owner-freebsd-standards@FreeBSD.ORG Thu May 30 17:13:49 2013 Return-Path: Delivered-To: freebsd-standards@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id BB96DAFF; Thu, 30 May 2013 17:13:49 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) by mx1.freebsd.org (Postfix) with ESMTP id 8442A78E; Thu, 30 May 2013 17:13:49 +0000 (UTC) Received: from troutmask.apl.washington.edu (localhost.apl.washington.edu [127.0.0.1]) by troutmask.apl.washington.edu (8.14.6/8.14.6) with ESMTP id r4UHDm7M067303; Thu, 30 May 2013 10:13:48 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.14.6/8.14.6/Submit) id r4UHDmUZ067302; Thu, 30 May 2013 10:13:48 -0700 (PDT) (envelope-from sgk) Date: Thu, 30 May 2013 10:13:48 -0700 From: Steve Kargl To: Pedro Giffuni Subject: Re: standards/175811: libstdc++ needs complex support in order use C99 Message-ID: <20130530171348.GA67170@troutmask.apl.washington.edu> References: <201302040328.r143SUd3039504@freefall.freebsd.org> <510F306A.6090009@missouri.edu> <20130530064635.GA91597@zim.MIT.EDU> <51A77324.2070702@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <51A77324.2070702@FreeBSD.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Stephen Montgomery-Smith , David Schultz , freebsd-numerics@freebsd.org, freebsd-standards@freebsd.org X-BeenThere: freebsd-standards@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Standards compliance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 May 2013 17:13:49 -0000 On Thu, May 30, 2013 at 10:41:24AM -0500, Pedro Giffuni wrote: > > I may be wrong but with long double support people that > need erfcl() and tgamma() can get them from boost. > The problem is therefore not implementing everything but > getting enough to turn on the features supported by > libstdc++ and boost. > Of course, you're wrong. :-) :-) <-- Note smileys. C99 defines many long double functions. Anyone wanting to use C and libm, and not C++ and boost, will need quality implementations of these functions. Of course, the lack of any actual C99 compiler tends to dampen this argument. What I find appalling is reading "people are tired of the situation with libm, so I'm going to commit some atrocious hack". The proper response should be "so I'm going to help implement and test the missing functionality". It's unfortunate that only a few individuals are working to fix libm, but such is life. -- Steve From owner-freebsd-standards@FreeBSD.ORG Thu May 30 20:35:14 2013 Return-Path: Delivered-To: freebsd-standards@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 74AEE31B; Thu, 30 May 2013 20:35:14 +0000 (UTC) (envelope-from wollman@khavrinen.csail.mit.edu) Received: from khavrinen.csail.mit.edu (khavrinen.csail.mit.edu [IPv6:2001:470:8b2d:1e1c:21b:21ff:feb8:d7b0]) by mx1.freebsd.org (Postfix) with ESMTP id 4D363640; Thu, 30 May 2013 20:35:14 +0000 (UTC) Received: from khavrinen.csail.mit.edu (localhost [127.0.0.1]) by khavrinen.csail.mit.edu (8.14.5/8.14.5) with ESMTP id r4UKZCqQ069030 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL CN=khavrinen.csail.mit.edu issuer=Client+20CA); Thu, 30 May 2013 16:35:12 -0400 (EDT) (envelope-from wollman@khavrinen.csail.mit.edu) Received: (from wollman@localhost) by khavrinen.csail.mit.edu (8.14.5/8.14.5/Submit) id r4UKZCOZ069027; Thu, 30 May 2013 16:35:12 -0400 (EDT) (envelope-from wollman) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <20903.47104.38977.577307@khavrinen.csail.mit.edu> Date: Thu, 30 May 2013 16:35:12 -0400 From: Garrett Wollman To: Warner Losh Subject: Re: standards/175811: libstdc++ needs complex support in order use C99 In-Reply-To: References: <201302040328.r143SUd3039504@freefall.freebsd.org> <510F306A.6090009@missouri.edu> <20130530064635.GA91597@zim.MIT.EDU> X-Mailer: VM 7.17 under 21.4 (patch 22) "Instant Classic" XEmacs Lucid X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (khavrinen.csail.mit.edu [127.0.0.1]); Thu, 30 May 2013 16:35:12 -0400 (EDT) Cc: freebsd-numerics@freebsd.org, freebsd-standards@freebsd.org X-BeenThere: freebsd-standards@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Standards compliance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 May 2013 20:35:14 -0000 < said: > I'm all for getting everything we can into the tree that produces an > answer that's not perfect, but close. What's the error that would be > generated with the naive implementation of > long double tgammal(long double f) { return tgamma(f); } Perhaps we could implement these functions in such a way that they logged a message to inform the user (once per process) that they were using a low-quality implementation. That would allow us to implement these functions without totally losing the incentive to implement them properly, and those users who don't actually call those functions would not have to pay the price of further delay. (This would be a non-conforming implementation, since it would have side effects other than those specified by the standard, but we already fail to conform by not implementing the functions at all, so it wouldn't make things *worse*.) -GAWollman From owner-freebsd-standards@FreeBSD.ORG Thu May 30 21:17:12 2013 Return-Path: Delivered-To: freebsd-standards@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id F2E8E566 for ; Thu, 30 May 2013 21:17:12 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-ie0-x235.google.com (mail-ie0-x235.google.com [IPv6:2607:f8b0:4001:c03::235]) by mx1.freebsd.org (Postfix) with ESMTP id BE75E967 for ; Thu, 30 May 2013 21:17:12 +0000 (UTC) Received: by mail-ie0-f181.google.com with SMTP id x14so1899077ief.40 for ; Thu, 30 May 2013 14:17:12 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=5fL5r8OZ7yMWK400mw0a+tJ4HcpentBZd9UtNAB+EUM=; b=YlQg2FFheC2e8h6DHyWBCj7LiXPSR+e1bjN2Z03bhrZmkG6m551DoNyRn9AraxfM2L 0Lgk62Pv8fvGsPKbRhtlJtodalKYHc3enb4I78GIxB62C8aeBE9njmQbAZ1dARCTQO62 kIh1pvVc7tp5XzBUzklSf3Dq23loYyWLMURj4KzDvpJhAHd9jrjRxqG31zd5+Xk++uRf 7GHs0t1BAaIaOzIIux283LhxA4I7z/FIHuF7RQea3fDAtcTEFLuGlC2Zp8A/kRGdMiuu SkB34W1o3UB7PuxdOvSpGWWQnarmbtmjqefRE3kwGKipJr99TsR4cNwwD0/limTsVdF3 2/8w== X-Received: by 10.50.43.234 with SMTP id z10mr247671igl.92.1369948632263; Thu, 30 May 2013 14:17:12 -0700 (PDT) Received: from monkey-bot.int.fusionio.com ([209.117.142.2]) by mx.google.com with ESMTPSA id k10sm193977ige.0.2013.05.30.14.17.10 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 30 May 2013 14:17:11 -0700 (PDT) Sender: Warner Losh Subject: Re: standards/175811: libstdc++ needs complex support in order use C99 Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <20130530171348.GA67170@troutmask.apl.washington.edu> Date: Thu, 30 May 2013 15:17:07 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <486AC985-2F3A-4CEB-A229-DF5F4AE9C50F@bsdimp.com> References: <201302040328.r143SUd3039504@freefall.freebsd.org> <510F306A.6090009@missouri.edu> <20130530064635.GA91597@zim.MIT.EDU> <51A77324.2070702@FreeBSD.org> <20130530171348.GA67170@troutmask.apl.washington.edu> To: Steve Kargl X-Mailer: Apple Mail (2.1085) X-Gm-Message-State: ALoCoQl63OPEPAZZ0cRTHt1XAd/0T4jlwXroFI5psHx4DgHNooN4NvySzZPsrt4OSbM5qvltu9Sv Cc: Stephen Montgomery-Smith , David Schultz , Pedro Giffuni , freebsd-standards@freebsd.org, freebsd-numerics@freebsd.org X-BeenThere: freebsd-standards@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Standards compliance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 May 2013 21:17:13 -0000 On May 30, 2013, at 11:13 AM, Steve Kargl wrote: > On Thu, May 30, 2013 at 10:41:24AM -0500, Pedro Giffuni wrote: >>=20 >> I may be wrong but with long double support people that >> need erfcl() and tgamma() can get them from boost. >> The problem is therefore not implementing everything but >> getting enough to turn on the features supported by >> libstdc++ and boost. >>=20 >=20 > Of course, you're wrong. :-) :-) <-- Note smileys. >=20 > C99 defines many long double functions. Anyone wanting > to use C and libm, and not C++ and boost, will need=20 > quality implementations of these functions. Of course, > the lack of any actual C99 compiler tends to dampen=20 > this argument. =20 >=20 > What I find appalling is reading "people are tired > of the situation with libm, so I'm going to commit > some atrocious hack". The proper response should be > "so I'm going to help implement and test the missing > functionality". It's unfortunate that only a few > individuals are working to fix libm, but such is > life.=20 I'd help, but the barriers to entry are somewhat steep and prickly. I = tried to help, and got no end of grief for documenting the differences = in an algorithm that was actually different that people told me was the = same. In that environment, you suck the enthusiasm out of the air an = wind up in the something is better than nothing camp quite quickly. Warner