Re: can not install latest DBI developer release with cpan on Win32
Steffen Winkler wrote: I can not get a ppm package for a developer release because ActiveState or someone else does not build that automaticly. Than I use the typical 2nd way - cpan. This was the reason to run cpan using the *.tar.gz. Maybe than I do the same actions like StrawberryPerl. I do not set extra environment. Inside of ths perl distribution are 3 binary identical files: D:\Perl\site\bin\g77.exe D:\Perl\site\bin\g++.exe D:\Perl\site\bin\gcc.exe g++.exe is than the same like gcc.exe In the directory D:\Perl\site\lib\auto\MinGW\bin are this files: addr2line.exe ar.exe as.exe c++.exe c++filt.exe cpp.exe dlltool.exe dllwrap.exe g++.exe g77.exe gcc.exe gccbug gcov.exe gprof.exe ld.exe mingw32-c++.exe mingw32-g++.exe mingw32-gcc-3.4.5 mingw32-gcc.exe mingw32-make.exe mingwm10.dll nm.exe objcopy.exe objdump.exe ranlib.exe readelf.exe size.exe strings.exe strip.exe windmc.exe windres.exe Here is g++.exe the same binary file like mingw32-g++.exe and gcc.exe is the same like mingw32-gcc.exe and mingw32-gcc-3.4.5. g++.exe is different to gcc.exe. I think that is, to allow any name. But at the end it should give the same result. You see, there is a lot off staff inside of such a binary Perl distribution. And instead of a complex environment there are a lot of copied files. I do only start cpan and run the DBI*.tar.gz. I do not select any compiler or anything else. The gear mechanism comes from Makefile.PL, CPAN, and the Perl distribution. As a Windows user you typical not look into a binary tool. It works or not. If not, use an other software. *** I'm very impressed that DBD::Oracle is alife. The last release that ActiveState has build was 1.21, maybe later a lot of conflicts they had. But I can not see the ActiveState build status, to find out why. Maybe that important pages were removed. *** It is not easy to write a distribution for Windows - I know. But ActiveState has Enterprise Perl. This is very good for stupid managers. At work we have to change from Perl to Java now. There is 1 reason only - enterprise. It seems to be better to have support for damaged software as running open source software. Regards from Steffen Steffen, I don't see anything I recognise from your problem other than the path that fails looks rather long and as Jens pointed out on IRC the: -out:blib\arch\auto\DBI\DBI.dll ends up being reported as: output file ut:blib\arch\auto\DBI\DBI.dll: Invalid argument and note, usually -o is used for output files and -out:blib\arch\auto\DBI\DBI.dll would end up as a file called ut:blib\arch\auto\DBI\DBI.dll is -o was the argument. Somehow the generated Makefile is creating commands which are wrong for the compiler/linker you are using. I doubt this is a DBI development release issue - are you sure it works with the previous (non development) DBI? Perhaps you could tell us: where you got the Perl from in D:\Perl if it is ActiveState perl what version? Did you install MinGW? Martin -- Martin J. Evans Easysoft Limited http://www.easysoft.com
vendors and the related DBDs
hi, some of you might be aware that I have submitted a grant request to the TPF that was focusing on two things: 1) fund-raising for TPF 2) promoting Perl on various non-Perl events The main selling point to the companies was providing help to them to find Perl developers.[1] I'd like to extend the proposal with some ideas on supporting development of CPAN modules and on improved contact with vendors. That means if my grant gets accepted I'll work on these items as well along with the fund-raising and promotion. As I am only a user of DBI and with very limited usage I'll need your help. I'd like to get your input regarding database vendors, the relevant DBDs and the relationship with the vendors. Which DBDs need a lot of investment? How do you think vendors could help? (Giving money?, Giving software licenses? Allocating developer time?) Which vendors are already involved? Should this go through TPF or do you think there are better channels for this? Who could help me in building up the contacts at the vendors? regards Gabor http://szabgab.com/ [1] http://news.perlfoundation.org/2010/06/hague-grant-application-perl-e.html
Take care with version numbers (eg DBD::Pg)
FYI - Forwarded message from David Golden xda...@gmail.com - Date: Thu, 8 Jul 2010 06:52:57 -0400 From: David Golden xda...@gmail.com To: Nigel Horne n...@bandsman.co.uk Cc: CPAN Testers Discuss cpan-testers-disc...@perl.org Subject: Re: CPAN::Reporter: test results were not valid, Prerequisite version too *high* On Thu, Jul 8, 2010 at 3:48 AM, Nigel Horne n...@bandsman.co.uk wrote: ! DBD::Pg 2.6 2.17.1 Let's review version number math: 2.6 = 2.60 2.17.1 = 2.017001 2.60 2.017001 I can't help it if module authors do stupid things with their version numbers. C.f. http://www.dagolden.com/index.php/369/version-numbers-should-be-boring/ -- David - End forwarded message - - Forwarded message from David Golden xda...@gmail.com - Date: Thu, 8 Jul 2010 07:34:35 -0400 From: David Golden xda...@gmail.com To: Nigel Horne n...@bandsman.co.uk Cc: CPAN Testers Discuss cpan-testers-disc...@perl.org Subject: Re: CPAN::Reporter: test results were not valid, Prerequisite version too *high* On Thu, Jul 8, 2010 at 7:15 AM, Nigel Horne n...@bandsman.co.uk wrote: I can't help it if module authors do stupid things with their version numbers. That doesn't address the issue that I raised of informing developers that they've made a mistake. Historically, authors have complained about getting FAIL reports when prerequisites are not met so we have erred on the side of not sending FAIL reports in such a case. We *do* send PASS reports even if prerequisites aren't satisfied. I don't know of a general way to determine if authors mis-specified their prerequisites without an easy back-pan index to see if the version they specified ever existed and that would still presume an internet connection. In any case, that kind of prerequisite analysis is (mostly) static and I think it's better for CPANTS or some other static analysis tool instead of CPAN Testers. David - End forwarded message -
Re: Take care with version numbers (eg DBD::Pg)
On Jul 8, 2010, at 8:31 AM, Tim Bunce wrote: FYI On Thu, Jul 8, 2010 at 3:48 AM, Nigel Horne n...@bandsman.co.uk wrote: ! DBD::Pg2.6 2.17.1 Let's review version number math: 2.6 = 2.60 2.17.1 = 2.017001 2.60 2.017001 Looks like it should have been 2.6.0: 2.6.0 = 2.006001 2.17.1 = 2.017001 2.006001 2.017001 Version number suck. And clearly, three-version numbers suck harder. Best, David
Re: vendors and the related DBDs
On 07/08/10 14:21, Gabor Szabo wrote: hi, Hi Gabor, some of you might be aware that I have submitted a grant request to the TPF that was focusing on two things: 1) fund-raising for TPF 2) promoting Perl on various non-Perl events The main selling point to the companies was providing help to them to find Perl developers.[1] This is a very good idea. As contractor I often see requests of companies which are searching Perl developers via staffing agencies - which might not work properly. http://jobs.perl.org/ is not well know, but on the other hand big companies do not contract developers directly - they do not like to many different agreements. I'd like to extend the proposal with some ideas on supporting development of CPAN modules and on improved contact with vendors. That means if my grant gets accepted I'll work on these items as well along with the fund-raising and promotion. As I am only a user of DBI and with very limited usage I'll need your help. I'd like to get your input regarding database vendors, the relevant DBDs and the relationship with the vendors. Which DBDs need a lot of investment? I cannot speak for other DBD's, but during the development on Meta-DBD's for DBI-1.612 we (Martin Evans, H. Merijn Brand and myself) developed some ideas how to improve the Meta-DBD's to make them more useful. How do you think vendors could help? (Giving money?, Giving software licenses? Allocating developer time?) If a company would hire/contract DBI/DBD developers to get a specific job done, that will always help. Tim offeres it on http://dbi.perl.org/support, others would be available, too (e.g. me). Which vendors are already involved? I can report that a big chemical company paid for some SQL::Statement speed up. Should this go through TPF or do you think there are better channels for this? Looking at the agreement problems of big companies (those who have money), I think TPF would be a good address to start. Who could help me in building up the contacts at the vendors? What kind of support do you imagine? Best regards, Jens regards Gabor http://szabgab.com/ [1] http://news.perlfoundation.org/2010/06/hague-grant-application-perl-e.html
Re: Take care with version numbers (eg DBD::Pg)
On 07/08/10 16:32, David E. Wheeler wrote: On Jul 8, 2010, at 8:31 AM, Tim Bunce wrote: FYI On Thu, Jul 8, 2010 at 3:48 AM, Nigel Hornen...@bandsman.co.uk wrote: ! DBD::Pg2.6 2.17.1 Let's review version number math: 2.6 = 2.60 2.17.1 = 2.017001 2.60 2.017001 Looks like it should have been 2.6.0: 2.6.0 = 2.006001 2.17.1 = 2.017001 2.006001 2.017001 Version number suck. And clearly, three-version numbers suck harder. Best, David I think, the best way out would be a hard consensus and CPAN reindex. This might break some things in the first way - but my experience as Perl module packager for pkgsrc packaging system is, that most authors do not react until things fail (and many of them do not react then). But this will touch the sacred cow of downward compatibility ... We can't have both. Jens
Re: Take care with version numbers (eg DBD::Pg)
On Jul 8, 2010, at 9:38 AM, Jens Rehsack wrote: Looks like it should have been 2.6.0: 2.6.0 = 2.006001 2.17.1 = 2.017001 2.006001 2.017001 Version number suck. And clearly, three-version numbers suck harder. I think, the best way out would be a hard consensus and CPAN reindex. The closest thing to a concensus is represented in David's blog post: http://www.dagolden.com/index.php/369/version-numbers-should-be-boring/ Fortunately, version number parsing is gradually becoming stricter. You can only use strictly-formatted version numbers in `use MODULE VERSION` and `package MODULE VERSION` (as of 5.12). It will be at least 10 years before loosely-parsed version numbers are deprecated, though. And perhaps not then. Besides which, if my META.yml says DBD::Pg: 2.6 It assumes decimal notation (2.600), not three-digit (2.006). It has no way to tell that I really mean the latter. This might break some things in the first way - but my experience as Perl module packager for pkgsrc packaging system is, that most authors do not react until things fail (and many of them do not react then). But this will touch the sacred cow of downward compatibility ... We can't have both. No, we can't, alas. Best, David
Re: Take care with version numbers (eg DBD::Pg)
-BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 Looks like it should have been 2.6.0: Yep, there is no such thing as version 2.6 of DBD::Pg. I think, the best way out would be a hard consensus and CPAN reindex. Consensus on what exactly? Perhaps it would be good if the mixing of two and three dot versions on the same check was treated as a severe error and caused an automatic FAIL report. I can't see a case where using both forms would ever be desired. - -- Greg Sabino Mullane g...@turnstep.com End Point Corporation http://www.endpoint.com/ PGP Key: 0x14964AC8 201007081302 http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8 -BEGIN PGP SIGNATURE- iEYEAREDAAYFAkw2Bf4ACgkQvJuQZxSWSsitqACg/ci1wC6pC3KIsQ1EXctbhg57 /jcAnRrGkbzhvcoIZTZy6UlGdUN8uuDW =I0v4 -END PGP SIGNATURE-
Re: Take care with version numbers (eg DBD::Pg)
On Jul 8, 2010, at 10:09 AM, Greg Sabino Mullane wrote: Perhaps it would be good if the mixing of two and three dot versions on the same check was treated as a severe error and caused an automatic FAIL report. I can't see a case where using both forms would ever be desired. In my META.yml, I'll use three-digit notation for modules that use it (DBD::Pg) and decimal for those that don't (DBI). It might be useful for the version validation code to complain if I specify decimal and the module uses three-digit (or vice versa). But then that would screw things up for modules that unfortunately changed their versioning algorithm. I would no longer be able to require DBD::Pg 1.49, for example, even thought that's perfectly valid. Best, David
Re: Take care with version numbers (eg DBD::Pg)
-BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 I can't see a case where using both forms would ever be desired. In my META.yml, I'll use three-digit notation for modules that use it (DBD::Pg) and decimal for those that don't (DBI). Right, I didn't mean to imply you can't mix and match across modules. It might be useful for the version validation code to complain if I specify decimal and the module uses three-digit (or vice versa). Could be a lot of work, yes, but it would certainly catch things like the existing RWDE problem (as would my proposal by itself). But then that would screw things up for modules that unfortunately changed their versioning algorithm. I would no longer be able to require DBD::Pg 1.49, for example, even thought that's perfectly valid. Good point, but hopefully such changes are a very rare and momentous event (as was the case with DBD::Pg). Version 1.49 (the last of the two dot versions for those playing at home) is *severely* deprecated. One of the reasons DBD::Pg jumped to 2.0.0 was to prevent any version comparison confusion, as even Perl's wacky versioning tools cannot deny that 2 1. :) - -- Greg Sabino Mullane g...@turnstep.com End Point Corporation http://www.endpoint.com/ PGP Key: 0x14964AC8 201007081340 http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8 -BEGIN PGP SIGNATURE- iEYEAREDAAYFAkw2DsMACgkQvJuQZxSWSsjeLACgsakZH/iVhwltaCqXOMOmcF8e ZBkAnjJlhWBgf0jWMJiRsPJDUkXWbxF2 =MhsI -END PGP SIGNATURE-
Re: Take care with version numbers (eg DBD::Pg)
On Jul 8, 2010, at 10:46 AM, Greg Sabino Mullane wrote: But then that would screw things up for modules that unfortunately changed their versioning algorithm. I would no longer be able to require DBD::Pg 1.49, for example, even thought that's perfectly valid. Good point, but hopefully such changes are a very rare and momentous event (as was the case with DBD::Pg). Version 1.49 (the last of the two dot versions for those playing at home) is *severely* deprecated. One of the reasons DBD::Pg jumped to 2.0.0 was to prevent any version comparison confusion, as even Perl's wacky versioning tools cannot deny that 2 1. :) A lot of folks changed without any momentous reason. So this suggestion, frankly, is right out. Frankly, I consider even momentous reason dubious. Pick a version and stick to it. I myself maintain a module or two with hinky version numbering systems because I inherited them and see no benefit to changing. Best, David
Re: can not install latest DBI developer release with cpan on Win32
The installation is ok now: - ActivePerl-5.12.1.1201-MSWin32-x86-292674.msi installed - run cpan install TIMB/DBI-1.611_93.tar.gz CPAN output: It looks like you don't have a C compiler and make utility installed. Trying to install dmake and the MinGW gcc compiler using the Perl Package Manager. This may take a a few minutes... Downloading MinGW-5.1.4.1...done Downloading dmake-4.11.20080107...done Unpacking MinGW-5.1.4.1...done Unpacking dmake-4.11.20080107...done Generating HTML for MinGW-5.1.4.1...done Generating HTML for dmake-4.11.20080107...done Updating files in site area...done 1070 files installed Please use the `dmake` program to run commands from a Makefile! Set up gcc environment - 3.4.5 (mingw-vista special r3) CPAN: Storable loaded ok (v2.22) CPAN: LWP::UserAgent loaded ok (v5.834) CPAN: Time::HiRes loaded ok (v1.9721) Fetching with LWP: http://ppm.activestate.com/CPAN/authors/01mailrc.txt.gz CPAN: YAML::XS loaded ok (v0.33) Going to read 'D:\Perl\cpan\sources\authors\01mailrc.txt.gz' CPAN: Compress::Zlib loaded ok (v2.027) DONE . . . and then a lot of output that ends with . . . t/zvxnp_50dbm_simple.t . ok t/zvxnp_51dbm_file.t ... ok t/zvxnp_52dbm_complex.t skipped: Not running with SQL::Statement t/zvxnp_85gofer.t .. ok All tests successful. Files=166, Tests=6188, 70 wallclock secs ( 1.33 usr + 0.24 sys = 1.56 CPU) Result: PASS D:\Perl\bin\perl.exe -Iblib\lib -Iblib\arch test.pl test.pl DBI test application $Revision: 12537 $ Switch: DBI 1.612 by Tim Bunce, 1.612 Available Drivers: CSV, DBM, ExampleP, File, Gofer, ODBC, Oracle, Proxy, SQLite, Sponge dbi:ExampleP:: testing 3 sets of 20 connections: Connecting... 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 Disconnecting... Connecting... 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 Disconnecting... Connecting... 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 Disconnecting... connect 20 and disconnect them, 3 times: 0.s / 60 = 0.s Testing handle creation speed... Set up gcc environment - 3.4.5 (mingw-vista special r3) 4 NullP sth/s perl 5.012001 MSWin32-x86-multi-thread (gcc 3.4.5 -O2) 0.2 5s test.pl done TIMB/DBI-1.611_93.tar.gz D:\Perl\site\bin\dmake.exe test -- OK Running make install Prepending D:\Perl\cpan\build\DBI-1.611_93-ywTvvv/blib/arch D:\Perl\cpan\build\D BI-1.611_93-ywTvvv/blib/lib to PERL5LIB for 'install' Files found in blib\arch: installing files in blib\lib into architecture depende nt library tree Installing D:\Perl\site\lib\auto\DBI\DBI.dll Installing D:\Perl\html\site\lib\DBI.html Installing D:\Perl\html\site\lib\DBD\DBM.html Installing D:\Perl\html\site\lib\DBD\File.html Installing D:\Perl\html\site\lib\DBD\Gofer.html Installing D:\Perl\html\site\lib\DBD\Proxy.html Installing D:\Perl\html\site\lib\DBD\Sponge.html Installing D:\Perl\html\site\lib\DBD\File\Developers.html Installing D:\Perl\html\site\lib\DBD\File\Roadmap.html Installing D:\Perl\html\site\lib\DBD\Gofer\Policy\Base.html Installing D:\Perl\html\site\lib\DBD\Gofer\Transport\Base.html Installing D:\Perl\html\site\lib\DBD\Gofer\Transport\null.html Installing D:\Perl\html\site\lib\DBD\Gofer\Transport\pipeone.html Installing D:\Perl\html\site\lib\DBD\Gofer\Transport\stream.html Installing D:\Perl\html\site\lib\DBI\DBD.html Installing D:\Perl\html\site\lib\DBI\Profile.html Installing D:\Perl\html\site\lib\DBI\ProfileData.html Installing D:\Perl\html\site\lib\DBI\ProfileDumper.html Installing D:\Perl\html\site\lib\DBI\ProxyServer.html Installing D:\Perl\html\site\lib\DBI\DBD\SqlEngine.html Installing D:\Perl\html\site\lib\DBI\Gofer\Execute.html Installing D:\Perl\html\site\lib\DBI\Gofer\Serializer\DataDumper.html Installing D:\Perl\html\site\lib\DBI\Gofer\Serializer\Storable.html Installing D:\Perl\html\site\lib\DBI\Gofer\Transport\Base.html Installing D:\Perl\html\site\lib\DBI\Gofer\Transport\pipeone.html Installing D:\Perl\html\site\lib\DBI\Gofer\Transport\stream.html Installing D:\Perl\html\site\lib\DBI\ProfileDumper\Apache.html Installing D:\Perl\html\site\lib\DBI\SQL\Nano.html Installing D:\Perl\html\bin\dbiprof.html Installing D:\Perl\html\bin\dbiproxy.html Appending installation info to D:\Perl\lib/perllocal.pod TIMB/DBI-1.611_93.tar.gz D:\Perl\site\bin\dmake.exe install -- OK *** Thank you for help and activating me to try more. Regards Steffen. -- GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01
Re: DBD::Oracle DRCP_1.25
Hi Luben I have incorporated your patch into the DRCP branch and I have also merged that branch back into trunk for any testing that you will be doing I would try it with the Trunk which you can find here http://svn.perl.org/modules/dbd-oracle/trunk I went with the ORA_DRCP_* for the attribute names rather than POOL. as well I made ORA_DRCP_CLASS an optional value. Some users my not want to use it. Thanks again John Scoles On Wed, Jul 7, 2010 at 4:34 PM, luben karavelov lu...@unixsol.org wrote: As I have promissed, here comes the documentation patch. I am not native speeker, so may be it will need an edit. Also, I have added processing of environment valiables ORA_POOL_CLASS, ORA_POOL_MIN, ORA_POOL_MAX, ORA_POOL_INCR if there is ORA_DRCP env set. Best regards luben -- New! Learn why how to love your data with Pythian's new webinar series. Topics, details register: http://www.pythian.com/webinars
Re: vendors and the related DBDs
On Thu, Jul 08, 2010 at 04:33:28PM +, Jens Rehsack wrote: On 07/08/10 14:21, Gabor Szabo wrote: How do you think vendors could help? (Giving money?, Giving software licenses? Allocating developer time?) If a company would hire/contract DBI/DBD developers to get a specific job done, that will always help. Tim offeres it on http://dbi.perl.org/support, others would be available, too (e.g. me). For the record, I've never had any ongoing support contract with any company for Perl DBI support. There have been a couple of occasions where the development of specific new features in DBI and DBD::Oracle were sponsored. (Things like swap_inner_handle in DBI and support for LOBs in DBD::Oracle.) The closest thing to an ongoing arrangement was with Oracle where they paid me some money to provide nominal support for DBD::Oracle. That lastest about a year, IIRC, and was a small sum for a small commitment. Tim.
Re: Take care with version numbers (eg DBD::Pg)
My take on this, for the record, is to prefer two part numbers in the form X.YYY where YYY never has a trailing zero. Short, sweet, simple. Tim. p.s. No one commented on the DBI going from 1.609 to 1.611 :)
Re: Take care with version numbers (eg DBD::Pg)
On Jul 8, 2010, at 3:29 PM, Tim Bunce wrote: My take on this, for the record, is to prefer two part numbers in the form X.YYY where YYY never has a trailing zero. And thus may be X.Y or X.YY as well. Short, sweet, simple. Yeah, I'm with you. All of my modules use this format. (Except Bricolage. Don't ask.) Tim. p.s. No one commented on the DBI going from 1.609 to 1.611 :) That's one louder, isn't it? David
Re: Take care with version numbers (eg DBD::Pg)
Tim Bunce wrote: My take on this, for the record, is to prefer two part numbers in the form X.YYY where YYY never has a trailing zero. Short, sweet, simple. Tim. p.s. No one commented on the DBI going from 1.609 to 1.611 :) You mean now? 1.611 came out on April 29th. Or did you mean the completely different 1.611_93? Confusing! And that points to an example of something else that should become common practice for numbers. Projects that have any version X.Y_Z should never also have a version X.Y for the same X plus Y. Instead, the Y should always increment when moving between a developer release and a production release. See how DBD::SQLite does things for an example that I think is better. This is also analogous to Perl's own versioning X.Y.Z scheme, where there are never developer and production releases with the same Y. Its much less confusing that way. It also avoids the confusion of relating 1.002003 to 1.002_003, say; are those the same version or different versions? So, if the next DBI release after the latest 1.611_93 is going to be a stable release, then keep the current plan for it to be 1.612. Then, when making a subsequent dev release, call it 1.613_1 or 1.613_001 or such. Does that not make more sense? -- Darren Duncan
Re: Take care with version numbers (eg DBD::Pg)
Underscores should be banned from version numbers. Full stop. Best, David On Jul 8, 2010, at 3:46 PM, Darren Duncan wrote: Tim Bunce wrote: My take on this, for the record, is to prefer two part numbers in the form X.YYY where YYY never has a trailing zero. Short, sweet, simple. Tim. p.s. No one commented on the DBI going from 1.609 to 1.611 :) You mean now? 1.611 came out on April 29th. Or did you mean the completely different 1.611_93? Confusing! And that points to an example of something else that should become common practice for numbers. Projects that have any version X.Y_Z should never also have a version X.Y for the same X plus Y. Instead, the Y should always increment when moving between a developer release and a production release. See how DBD::SQLite does things for an example that I think is better. This is also analogous to Perl's own versioning X.Y.Z scheme, where there are never developer and production releases with the same Y. Its much less confusing that way. It also avoids the confusion of relating 1.002003 to 1.002_003, say; are those the same version or different versions? So, if the next DBI release after the latest 1.611_93 is going to be a stable release, then keep the current plan for it to be 1.612. Then, when making a subsequent dev release, call it 1.613_1 or 1.613_001 or such. Does that not make more sense? -- Darren Duncan
