From: William S F. <ws...@fu...> - 2007-08-10 22:41:12
|
I was thinking of making a new release later this month. There are quite a few patches and bug reports. I'd appreciate some help for the release, so if anyone feels like going through the bugs and patches, please feel free to commit fixes and patches, even if it is a bit out of your domain, as we don't have many active committers right now. William |
From: William S F. <ws...@fu...> - 2007-10-12 23:09:29
|
I really must get around to making the new release. I would like to have a go by mid next week with a release candidate, so please check in any important fixes now. William |
From: Olly B. <ol...@su...> - 2007-10-15 15:38:20
|
On 2007-10-12, William S Fulton <ws...@fu...> wrote: > I really must get around to making the new release. I would like to have > a go by mid next week with a release candidate, so please check in any > important fixes now. Sounds good to me. I don't think I've anything pending which is in shape for going in, and there have been loads of important and useful changes since the last release, so it would be good to have a new release. Cheers, Olly |
From: Olly B. <ol...@su...> - 2007-10-18 15:03:12
|
On 2007-10-12, William S Fulton <ws...@fu...> wrote: > I really must get around to making the new release. I would like to have > a go by mid next week with a release candidate, so please check in any > important fixes now. It looks like I may have introduced a problem with wrapping constants in PHP. I'm just investigating now, but it would be bad to release with that broken. Cheers, Olly |
From: Olly B. <ol...@su...> - 2007-10-18 16:07:30
|
On 2007-10-18, Olly Betts <ol...@su...> wrote: > It looks like I may have introduced a problem with wrapping constants > in PHP. I'm just investigating now, but it would be bad to release > with that broken. OK, fixed. Release whenever you're ready! Cheers, Olly |
From: William S F. <ws...@fu...> - 2007-10-18 21:33:43
|
Olly Betts wrote: > On 2007-10-18, Olly Betts <ol...@su...> wrote: >> It looks like I may have introduced a problem with wrapping constants >> in PHP. I'm just investigating now, but it would be bad to release >> with that broken. > > OK, fixed. Release whenever you're ready! > I've started going through the test-suite. If anyone feels like tackling this regression, please do: Checking testcase li_std_string (with run test) under perl5 SWIG Perl test failed: TypeError in method 'Foo_testl', argument 2 of type 'unsigned long long' make: *** [li_std_string.cpptest] Error 255 The guile test-suite seems to have a few new problems if Matthias is still around?. Other than that Linux looks okay and I'll start testing on cygwin/windows next. William |
From: Olly B. <ol...@su...> - 2007-10-18 23:47:20
|
On 2007-10-18, William S Fulton <ws...@fu...> wrote: > Checking testcase li_std_string (with run test) under perl5 > SWIG Perl test failed: > > TypeError in method 'Foo_testl', argument 2 of type 'unsigned long long' > > make: *** [li_std_string.cpptest] Error 255 I've just had a quick look, but it passes on x86_64 Linux. I'll see if I spot the problem by inspecting the code, and looking at what's changed. > The guile test-suite seems to have a few new problems if Matthias is > still around? There's a patch on SF for updating SWIG to use the current guile-wrapping API, which may be connected to the problems you see. I don't know enough about guile to feel confident about applying it though. Cheers, Olly |
From: Olly B. <ol...@su...> - 2007-10-19 03:27:52
|
On 2007-10-18, Olly Betts <ol...@su...> wrote: > On 2007-10-18, William S Fulton <ws...@fu...> wrote: >> Checking testcase li_std_string (with run test) under perl5 >> SWIG Perl test failed: >> >> TypeError in method 'Foo_testl', argument 2 of type 'unsigned long long' >> >> make: *** [li_std_string.cpptest] Error 255 > > I've just had a quick look, but it passes on x86_64 Linux. I'll see if > I spot the problem by inspecting the code, and looking at what's > changed. I tried forcing the code path it looks like a 32 bit platform would use but I didn't get anywhere, and I don't have the time to set up a SWIG tree in a 32-bit chroot right now. I did notice that we check errno after the call to strtoull() but don't reset it beforehand so it could have a junk value. I'll commit a fix for that shortly. Cheers, Olly |
From: William S F. <ws...@fu...> - 2007-10-23 23:17:02
|
Olly Betts wrote: > On 2007-10-18, Olly Betts <ol...@su...> wrote: >> On 2007-10-18, William S Fulton <ws...@fu...> wrote: >>> Checking testcase li_std_string (with run test) under perl5 >>> SWIG Perl test failed: >>> >>> TypeError in method 'Foo_testl', argument 2 of type 'unsigned long long' >>> >>> make: *** [li_std_string.cpptest] Error 255 >> I've just had a quick look, but it passes on x86_64 Linux. I'll see if >> I spot the problem by inspecting the code, and looking at what's >> changed. > > I tried forcing the code path it looks like a 32 bit platform would use > but I didn't get anywhere, and I don't have the time to set up a SWIG > tree in a 32-bit chroot right now. > > I did notice that we check errno after the call to strtoull() but don't > reset it beforehand so it could have a junk value. I'll commit a fix > for that shortly. > This came up with the same failure again on Windows 32 bit this time as well as another 32 bit Linux box. I'm using Perl 5.8.7 and 5.8.8. Putting debug info into SWIG_AsVal_dec(unsigned long long)(SV *obj, unsigned long long *val) from perlprimtypes.swg and it showed that nptr contains "9.23456789012111e+18". This shows the problem as the number is in scientific notation which is why strtoull fails. Any suggestions for successfully accepting this format and converting into an unsigned long long? William |
From: Olly B. <ol...@su...> - 2007-10-23 23:34:14
|
On Wed, Oct 24, 2007 at 12:16:51AM +0100, William S Fulton wrote: > Putting debug info into > SWIG_AsVal_dec(unsigned long long)(SV *obj, unsigned long long *val) > from perlprimtypes.swg and it showed that nptr contains > "9.23456789012111e+18". This shows the problem as the number is in > scientific notation which is why strtoull fails. Any suggestions for > successfully accepting this format and converting into an unsigned long > long? If the strtoull() call fails because it doesn't parse the whole string we could use strtod() to convert it to a double, then cast that double to the type we want. The problem is sizeof(double) is typical the same as sizeof(long long) so clearly double can't represent all values of long long. Perhaps use strtold() and long double? On platforms where long double isn't just double, it typically can hold any long long value exactly. Otherwise I think it'll need a custom number parser (or a suitable existing library function, but I don't know of one). Cheers, Olly |
From: William S F. <ws...@fu...> - 2007-10-28 16:43:44
|
Olly Betts wrote: > On Wed, Oct 24, 2007 at 12:16:51AM +0100, William S Fulton wrote: >> Putting debug info into >> SWIG_AsVal_dec(unsigned long long)(SV *obj, unsigned long long *val) >> from perlprimtypes.swg and it showed that nptr contains >> "9.23456789012111e+18". This shows the problem as the number is in >> scientific notation which is why strtoull fails. Any suggestions for >> successfully accepting this format and converting into an unsigned long >> long? > > If the strtoull() call fails because it doesn't parse the whole string > we could use strtod() to convert it to a double, then cast that double > to the type we want. The problem is sizeof(double) is typical the same > as sizeof(long long) so clearly double can't represent all values of > long long. > > Perhaps use strtold() and long double? On platforms where long double > isn't just double, it typically can hold any long long value exactly. > > Otherwise I think it'll need a custom number parser (or a suitable > existing library function, but I don't know of one). > > Cheers, > Olly > I posed the question on the perl-xs mailing list. See http://www.nntp.perl.org/group/perl.xs/2007/10/msg2423.html. It looks like some builds of perl and I presume those with USE_64_BIT_ALL defined will store the number as "9234567890121111113" instead of "9.23456789012111e+18". I modified the Perl test to use a string instead and then it works fine. I think users might just have to use this workaround. BTW for those people who have the test passing (before I modified it), I presume SvUVOK is returning true, so that this snippet of code in SWIG_AsVal_dec (perlprimtypes.swg) is being executed: if (SvUOK(obj)) { if (val) *val = SvUV(obj); return SWIG_OK; } else if (SvIOK(obj)) { William |
From: Olly B. <ol...@su...> - 2007-10-28 17:36:03
|
On Sun, Oct 28, 2007 at 04:43:05PM +0000, William S Fulton wrote: > BTW for those people who have the test passing (before I modified it), I > presume SvUVOK is returning true, so that this snippet of code in > SWIG_AsVal_dec (perlprimtypes.swg) is being executed: > > if (SvUOK(obj)) { > if (val) *val = SvUV(obj); > return SWIG_OK; Yes, I believe that's the code path I was seeing taken. How are we doing release-wise? I wondered if this should be applied before the release - I don't know much about Lua, but it seems that these structures shouldn't be exported: http://article.gmane.org/gmane.comp.programming.swig/11559 Cheers, Olly |
From: John L. <jl...@ma...> - 2007-10-28 22:41:30
|
On 10/28/2007 05:12 PM, William S Fulton wrote: > There is an interesting regression I just introduced to solve > uninitialised return variables in the directors. For anything that is > not a reference or pointer, the type is initialised by calling the > constructor, eg: > > int c_result = int() ; > > However, gcc doesn't like this approach for unsigned values, eg: > > unsigned int c_result = unsigned int() ; > > whereas Visual C++ accepts this. Does anybody have any ideas as to > whether the standard permits this construct? It looks like I'm going to > have to detect these types and initialise to zero instead. I was also > thinking of using a templated initialisation method which gcc does handle: > What about typedef unsigned int __swig_uint; int main() { int c = int() ; unsigned int d = __swig_uint() ; return 0; } Works fine for me with g++ $ g++ --version g++ (GCC) 4.1.3 20070929 (prerelease) (Ubuntu 4.1.2-16ubuntu2) Copyright (C) 2006 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. John |
From: Olly B. <ol...@su...> - 2007-10-28 22:53:54
|
On Sun, Oct 28, 2007 at 05:40:32PM -0500, John Lenz wrote: > What about > > typedef unsigned int __swig_uint; Snap! Except we shouldn't use a "__" prefix - that's "reserved to the implementation". Section 8 of Doc/Devel/internals.html has a good explanation of this. Cheers, Olly |
From: William S F. <ws...@fu...> - 2007-10-28 23:01:11
|
John Lenz wrote: > On 10/28/2007 05:12 PM, William S Fulton wrote: >> There is an interesting regression I just introduced to solve >> uninitialised return variables in the directors. For anything that is >> not a reference or pointer, the type is initialised by calling the >> constructor, eg: >> >> int c_result = int() ; >> >> However, gcc doesn't like this approach for unsigned values, eg: >> >> unsigned int c_result = unsigned int() ; >> >> whereas Visual C++ accepts this. Does anybody have any ideas as to >> whether the standard permits this construct? It looks like I'm going to >> have to detect these types and initialise to zero instead. I was also >> thinking of using a templated initialisation method which gcc does handle: >> > > What about > > typedef unsigned int __swig_uint; > int main() { > int c = int() ; > unsigned int d = __swig_uint() ; > return 0; > } Yeah that is a good solution too. I prefer the template approach though as it will generate cleaner code IMHO and as the test-suite passes, I'll check it in shortly. William |
From: Matthias K. <mko...@ma...> - 2007-10-19 01:14:03
|
William S Fulton <ws...@fu...> writes: > The guile test-suite seems to have a few new problems if Matthias is=20 > still around?.=20 Hi William, I'll try to take a look.=20=20=20 Quick question, I just checked out a fresh copy from SVN, and it seems I have to configure --without-maximum-compile-warnings to get the Guile checks in ./configure working at all. The reason is -ansi -pedantic, which doesn't work with Guile's header files. Do configure checks for other languages have the same problem, and should there be a workaround (removing these max-warning flags) in configure? Thanks Matthias --=20 Matthias K=F6ppe -- http://www.math.uni-magdeburg.de/~mkoeppe (currently @math.ucdavis.edu) |
From: Matthias K. <mko...@ma...> - 2007-10-19 22:33:14
|
William S Fulton <ws...@fu...> writes: > Matthias Koeppe wrote: >> Quick question, I just checked out a fresh copy from SVN, and it seems >> I have to configure --without-maximum-compile-warnings to get the >> Guile checks in ./configure working at all. The reason is -ansi >> -pedantic, which doesn't work with Guile's header files. Do configure >> checks for other languages have the same problem, and should there be >> a workaround (removing these max-warning flags) in configure? > > I'm not sure I follow. The guile test-suite and examples compile using > the default C++ compiler flags, ie no extra options are added to the > compilation. The -ansi and -pedantic and --without--maximum-warnings > are only used for compiling the SWIG executable which doesn't use the > Guile headers. That's true, but at configuration time I also do a compile check (using AC_LINK_IFELSE) to see which of the two possible Guile APIs work. (This is to decide whether to run check-guile-test-suite and/or check-guilescm-test-suite.) Since ac_compile_warnings.m4 pollutes both CFLAGS and CXXFLAGS with -ansi -pedantic, both tests fail. Matthias --=20 Matthias K=F6ppe -- http://www.math.uni-magdeburg.de/~mkoeppe (currently @math.ucdavis.edu) |
From: Matthias K. <mko...@ma...> - 2007-10-22 22:13:53
|
William S Fulton <ws...@fu...> writes: > [Guile test suite failures] I have now fixed both Guile detection in configure.in and also two testcases of the guile-scm test-suite. The only remaining failure is exception_partial_info, which I don't know how to fix. So please go ahead with the new release. Matthias --=20 Matthias K=F6ppe -- http://www.math.uni-magdeburg.de/~mkoeppe (currently @math.ucdavis.edu) |
From: William S F. <ws...@fu...> - 2007-10-28 23:21:28
|
Olly Betts wrote: > On Sun, Oct 28, 2007 at 10:12:37PM +0000, William S Fulton wrote: >> Olly Betts wrote: >>> How are we doing release-wise? >>> >>> I wondered if this should be applied before the release - I don't know >>> much about Lua, but it seems that these structures shouldn't be >>> exported: >>> >>> http://article.gmane.org/gmane.comp.programming.swig/11559 >>> >> Anyone is welcome to fix any bugs they see fit and this one looks useful. >> >> I'm concentrating on getting the test-suite to pass on all platforms I >> have access to. > > Perhaps you misunderstood me - I wasn't trying to say "William, you > should apply this patch", I understood you to mean this, so I apologise if I my response wasn't appropriate. > but rather "This patch looks useful, but I > don't know much about Lua and don't want to break things shortly before > a release so I don't feel I should just apply it without a second > opinion, ideally from our Lua maintainer, if we have an active one". > I think Mark Gossage is still around and usually spots Lua queries, even if it takes a day or two. Still, it might be good to make sure this gets into the release. > Anyway, since you also think it looks useful, I'll apply it locally and > try the Lua testsuite. > >> There is an interesting regression I just introduced to solve >> uninitialised return variables in the directors. For anything that is >> not a reference or pointer, the type is initialised by calling the >> constructor, eg: >> >> int c_result = int() ; >> >> However, gcc doesn't like this approach for unsigned values, eg: >> >> unsigned int c_result = unsigned int() ; >> >> whereas Visual C++ accepts this. Does anybody have any ideas as to >> whether the standard permits this construct? > > When it comes to standards conformance, my money would be on GCC rather > than MSVC. The EDG front-end (used by several C++ compilers) also > rejects it: > > http://www.comeaucomputing.com/tryitout/ > > It's a bit academic whether it's valid or not though - it's not useful > to generate code which won't compile with a popular compiler even if > that compiler is at fault. > Yup agreed. >> It looks like I'm going to >> have to detect these types and initialise to zero instead. > > Hmm, actually for classes you can omit the initialiser anyway (i.e. > "class c_result;" uses the default ctor), so this seems reasonable. > Ah, but there is a subtle difference between: MyType c_result; and MyType c_result = MyType(); If MyType is a POD, then no initialisation occurs in the first case, whereas the type is initialised in the second case. Therefore we need to generate the second case. >> I was also >> thinking of using a templated initialisation method which gcc does handle: >> >> template <typename T> T SWIG_init_value() { >> return T(); >> } >> >> unsigned int c_result = SWIG_init_value<unsigned int>(); > > Alternatively, I think a typedef would do the trick: > > typedef unsigned int swig_typedef_unsigned_int; > > [...] > > int c_result = swig_typedef_unsigned_int(); > > Less elegant than a template, but this would only be needed if the type > name contains a space, so we'd only need this for a handful of types. > Ah yes, you'd have to mangle the generated name if namespaces are present and write some code to detect the types for which typedefs are required. > I use a linux-hosted mingw cross compiler to build releases of a project > and it works well - it'll probably build noticably faster than under > cygwin since the process start up overhead is lower on Linux. Nice to know. Thanks. I've read that exceptions don't work properly with the cross compiler, but as we don't use exceptions, that isn't a problem. Actually speed of compilation isn't an issue as it only takes a minute or two to build SWIG, it is just the hassle of firing up Windows, even though I've now got it running nicely under vmware. The goal is to create one script to build and upload both releases to SF. I can even do a quick sanity check on Linux as wine will run the resulting Windows executable. I'm not insane enough to run the target language interpreters / test-suite under Wine though. William |
From: Olly B. <ol...@su...> - 2007-10-29 00:18:12
|
On Sun, Oct 28, 2007 at 11:20:49PM +0000, William S Fulton wrote: > I think Mark Gossage is still around and usually spots Lua queries, even > if it takes a day or two. Still, it might be good to make sure this gets > into the release. OK, I've run the Lua examples and test suite (and fixed a bug in some of the makefiles for the examples) and this patch doesn't change the output so I've applied it. I had to hack configure to get it to recognise my Lua 5.0 (from Ubuntu gutsy) becuase it needs -llua50 and -llualib50 (rather than -llua and -llualib as configure is hardwired to look for). Is that peculiar to the Ubuntu (and most likely Debian) packaging? Should I fix configure.in to look for the libraries with a suffix like this if they aren't found without? (Questions for Mark, mostly). > Ah, but there is a subtle difference between: > > MyType c_result; > and > MyType c_result = MyType(); > > If MyType is a POD, then no initialisation occurs in the first case, > whereas the type is initialised in the second case. Therefore we need to > generate the second case. Ah yes, I missed that. > >Less elegant than a template, but this would only be needed if the type > >name contains a space, so we'd only need this for a handful of types. > > > Ah yes, you'd have to mangle the generated name if namespaces are > present and write some code to detect the types for which typedefs are > required. I was thinking it would only be unsigned int, long long, etc, but because POD structures need it too, it all becomes more complicated. The typedefs could just be numbered, but that's definitely getting less readable than the template approach, and also harder to generate. > >I use a linux-hosted mingw cross compiler to build releases of a project > >and it works well - it'll probably build noticably faster than under > >cygwin since the process start up overhead is lower on Linux. > > Nice to know. Thanks. I've read that exceptions don't work properly with > the cross compiler, but as we don't use exceptions, that isn't a problem. I don't in the other project either, though I think I've cross-built stuff before which does and it seemed to run OK. Cheers, Olly |
From: Matthias K. <mko...@ma...> - 2007-10-23 00:23:09
|
William S Fulton <ws...@fu...> writes: > My setup also runs the guile test-suite which has a=20 > number of testcase failures, but they are all due to the same errors=20 > shown in the two failures below. I don't recall seeing these before, but= =20 > then I think I have upgraded Guile versions since the last release. > > william@caracal:~/swig/trunk/Examples/test-suite/guile$ guile --version > Guile 1.6.8 > > If you can replicate these and fix that would be great. I have now also fixed the failure of "apply_strings" for "check-guile-test-suite". > Checking testcase cpp_basic under guile > cpp_basic_wrap.cxx:1229: error: =91SWIG_ConvertMember=92 was not declared= in=20 > this scope > primitive_ref_wrap.cxx:1478: error: =91gh_scm2long_long=92 was not declar= ed=20 > in this scope These two I cannot fix easily in "check-guile-test-suite" (which tests the obsolete "gh" API of Guile). We can probably remove the support for the "gh" API from SWIG, since it is only needed for very old Guile versions <=3D 1.3.4, which was released in 1999. I currently don't have time to do that, so maybe we should just disable automatic running of "check-guile-test-suite", keeping only "check-guilescm-test-suite". Matthias --=20 Matthias K=F6ppe -- http://www.math.uni-magdeburg.de/~mkoeppe (currently @math.ucdavis.edu) |
From: Chris S. <c.s...@co...> - 2007-10-23 01:06:52
|
On Mon, Oct 22, 2007 at 05:21:01PM -0700, Matthias Koeppe wrote: > William S Fulton <ws...@fu...> writes: > > > My setup also runs the guile test-suite which has a > > number of testcase failures, but they are all due to the same errors > > shown in the two failures below. I don't recall seeing these before, but > > then I think I have upgraded Guile versions since the last release. > > > > william@caracal:~/swig/trunk/Examples/test-suite/guile$ guile --version > > Guile 1.6.8 > > > > If you can replicate these and fix that would be great. > > I have now also fixed the failure of "apply_strings" for > "check-guile-test-suite". > > > Checking testcase cpp_basic under guile > > cpp_basic_wrap.cxx:1229: error: ‘SWIG_ConvertMember’ was not declared in > > this scope > > > primitive_ref_wrap.cxx:1478: error: ‘gh_scm2long_long’ was not declared > > in this scope > > These two I cannot fix easily in "check-guile-test-suite" (which tests > the obsolete "gh" API of Guile). We can probably remove the support > for the "gh" API from SWIG, since it is only needed for very old Guile > versions <= 1.3.4, which was released in 1999. I currently don't have > time to do that, so maybe we should just disable automatic running of > "check-guile-test-suite", keeping only "check-guilescm-test-suite". As a developer for a project (GnuCash) that relies heavily on SWIG's guile support, let me thank you guys for your outstanding release-engineering work. A *lot* of non-technical users end up building projects that use SWIG from source, and the fact that SWIG works cleanly and reliably on diverse platforms really makes life easier for downstream devs. That said, please yell loudly if there will be any regressions in SWIG's support for guile's "scm" API. Also, I can say that it's almost unimaginable to me that any of SWIG's users would be following the newest SWIG release and still trying to use guile's "gh" API. -chris |
From: Olly B. <ol...@su...> - 2007-10-23 01:53:33
|
On 2007-10-23, Chris Shoemaker <c.s...@co...> wrote: > That said, please yell loudly if there will be any regressions in > SWIG's support for guile's "scm" API. Also, I can say that it's > almost unimaginable to me that any of SWIG's users would be following > the newest SWIG release and still trying to use guile's "gh" API. There's a patch which has been sitting in the tracker for over a year to update SWIG to support guile 1.8. I had a quick look over it a month or so ago as I thought we didn't have an active guile maintainer and made a few comments, but I don't really know much about guile and certainly didn't feel capable of applying it myself: Anyone with guile knowledge care to take a look: http://sf.net/tracker/?func=detail&aid=1511038&group_id=1645&atid=301645 If it's no longer relevant, we should close it. Cheers, Olly |
From: Matthias K. <mko...@ma...> - 2007-10-23 02:23:10
|
Olly Betts <ol...@su...> writes: > There's a patch which has been sitting in the tracker for over a year to > update SWIG to support guile 1.8. I had a quick look over it a month or > so ago as I thought we didn't have an active guile maintainer Indeed I am not very active. > and made a > few comments, but I don't really know much about guile and certainly > didn't feel capable of applying it myself: > > Anyone with guile knowledge care to take a look: > > http://sf.net/tracker/?func=3Ddetail&aid=3D1511038&group_id=3D1645&atid= =3D301645 > > If it's no longer relevant, we should close it. Basically, current SWIG does support Guile 1.8 perfectly as far as I know, though it might use some deprecated functions. At this point of time, I will not apply patches if they break compatibility with Guile 1.6 (not sure if "swig -guile -scm" still supports Guile 1.4, though) purely for the sake of fixing deprecation warnings. I fully agree with your comment, Olly, on the bug tracker item. A patch that uses wrapper-compile-time conditionalization (rather than SWIG-configure-time conditionalization as the submitted patch) on the Guile version to avoid using deprecated interfaces on Guile 1.8 could be easily accepted and merged. Matthias --=20 Matthias K=F6ppe -- http://www.math.uni-magdeburg.de/~mkoeppe (currently @math.ucdavis.edu) |
From: Olly B. <ol...@su...> - 2007-10-23 14:34:53
|
On 2007-10-23, Matthias Koeppe <mko...@ma...> wrote: >> Anyone with guile knowledge care to take a look: >> >> http://sf.net/tracker/?func=detail&aid=1511038&group_id=1645&atid=301645 >> >> If it's no longer relevant, we should close it. > > Basically, current SWIG does support Guile 1.8 perfectly as far as I > know, though it might use some deprecated functions. [...] Thanks for your comments, Matthias. I've pasted a copy (and a link to this message) in the tracker item so we have a record of them there. Cheers, Olly |