rdfextras release

[Gunnar Aastrand Grimnes]

Hi all,

Now that 3.2 is out of the way, we should really release a rdfextras
to match... I do not like this, since the current state of rdfextras
is a bit of a mess, but the existing 0.1 release is also a mess, so at
least it's not going to get worse.

I have some time at the weekend, I will try to clean things up a bit.
I made an issue to collect things we might want to do:

http://code.google.com/p/rdfextras/issues/detail?id=37

Cheers!

- Gunnar

--
http://gromgull.net

[Graham Higgins]

On Friday, 20 January 2012 10:35:20 UTC, Gunnar Aastrand Grimnes wrote:

Hi all,

Now that 3.2 is out of the way, we should really release a rdfextras
to match... I do not like this, since the current state of rdfextras
is a bit of a mess, but the existing 0.1 release is also a mess, so at
least it's not going to get worse.

It depends on what you mean by "a bit of a mess", I think it's pretty much under control ...

http://bel-epa.com/hudson/job/rdfextras-test/

Obviously, some of the stores need a little TLC in order to reintroduce the skipped 

tests but it's not clear to me atm which stores are deemed to be supported and 

which are not.

Apologies for the CI being on a private server, rdfextras is unfortunately rather 

unsuited to shiningpanda's vanilla OS installation and I haven't yet found the time 

to log in and find out if I can install all the distro packages that are required to satisfy 

rdfextras' various OS-level dependencies (MySQL, PostgreSQL, etc).

Cheers,

Graham

[Gunnar Aastrand Grimnes]

Ah - that looks much better than the result I get running run_tests.py locally.

I didn't mean just the test, I meant the random bits of code I have
committed everywhere - and the slight lack of overview :)

Oh and thanks for the doc update Graham - I didn't realise the version
number was stored again in the docs folder.
For some reason my sphinx install is missing the pyramid theme so I
cannot build the docs just now, but could you upload a zip file of
them built to the google code page when you have time?

Cheers!,

- Gunnar

> --
> You received this message because you are subscribed to the Google Groups
> "rdflib-dev" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/rdflib-dev/-/sQVnqUhTMKkJ.
> To post to this group, send email to rdfli...@googlegroups.com.
> To unsubscribe from this group, send email to
> rdflib-dev+...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/rdflib-dev?hl=en.

--
http://gromgull.net

[Thomas Kluyver]

On 20 January 2012 13:37, Graham Higgins <gjhi...@gmail.com> wrote:

Apologies for the CI being on a private server, rdfextras is unfortunately rather 

unsuited to shiningpanda's vanilla OS installation and I haven't yet found the time 

to log in and find out if I can install all the distro packages that are required to satisfy 

rdfextras' various OS-level dependencies (MySQL, PostgreSQL, etc).

I've got ShiningPanda set up for IPython - it is possible to log in and customise the environment, but you don't get root access, so you have to set things up in your own home directory. I don't know if they plan to improve that.

Thomas

[Graham Higgins]

On Friday, 20 January 2012 14:58:50 UTC, Thomas Kluyver wrote:

I've got ShiningPanda set up for IPython - it is possible to log in and customise the environment, but you don't get root access, so you have to set things up in your own home directory. I don't know if they plan to improve that.

Drat, I didn't think it through. Although MySQL and PostgreSQL are installed in the shiningpanda embracing (Debian squeeze) std OS distro environment, the sockets/ports aren't accessible. I don't think the relevant daemons are actually running.

I s'pose rdfextras store tests could be adjusted to use mocking to circumvent the dependencies. Has the disadvantage of not actually testing for real, though.

Cheers,

Graham

[Graham Higgins]

In the end, I pulled rdfextras off shiningpanda (too many dependencies and consuming a highly disproportionate amount of build resource) and set it up on my own hudson ci:

http://bel-epa.com/hudson/job/rdfextras/

I dropped the "cover" and "jython" runs from rdflib on shiningpanda, again in the interests of focusing the resource where it's proving to be most effective.

Cheers,

Graham

[Graham Higgins]

Sorry for the GitHub email noise, I was exploring GitHub's "Organisation" facility in some depth and wasn't aware that it was busily sending out email.

My primary concern is to bring some sort of order to rdfextras, now that a py3compat version is being threatened. Some of the stores rely on Python packages that haven't (yet?) been made compatible with Python 3 --- ZODB, for one, MySQL for another (there isn't a port that I can seem tp get to work as yet). Gunnar's lodservice app depends on flask+werkzeug, neither of which are py3-compatible yet. The KyotoCabinet store is py3-compatible but the Python module extension doesn't compile on 2.4/2.5. The RDFa parser's "lax" mode cannot be used with Python3 because of the (py2-only) html5lib dependency. The rdfjson and jsonld parsers both depend on simplejson to run under 2.4/2.5.

It seems highly desirable to split off at least some of the rdfextras sub-modules into their own separate packages with their own py3compat-or-not version filters and install_requires/tests_require dependency enforcements.

I've been investigating whether/how Github might be useful in supporting an array of separate rdflib plugin modules and in providing a central place to host logically-related work such as a py3compat version of pyRFDa, possibly html5lib, Chimezie's FuXi (refactored to be compatible with both rdflib 2.4.1 and rdflib3), etc.

Anyway, the current result of my investigation is here: https://github.com/RDFLib - I think it's very promising.

With respect to the issue tickets, I discovered on a previous foray down this road that issue tickets can be exported (as CSV) from Google and pushed up to GitHub's issue API - with the disadvantage that the OP's email address is lost in the process if GitHub can't match the email address to an existing GitHub a/c, so a changeover period would seem to be desirable.

I haven't found anything else quite so well-suited to the requirements (as I see them). I'd be interested in any observations or suggestions if anyone has any.

Cheers,

Graham

[Dominique Guardiola Falco]

great work...thanks

jsut saw https://github.com/RDFLib/rdflib-postgresql repository holds rdflib-sqlite package

[Graham Higgins]

Thanks for the encouragement,

On Monday, 6 February 2012 10:26:35 UTC, Dominique Guardiola Falco wrote:

great work...thanks

jsut saw https://github.com/RDFLib/rdflib-postgresql repository holds rdflib-sqlite package

yes, most of the sub-modules still need particularising to their own setup, their own tests added, the correct ownership ascribed, etc. So far I've only actually finished two: rdflib-kyotocabinet and rdflib-rdfjason, the rest are being worked on.

As I finish them, I create a Hudson CI build on bel-epa (if suitable, they can be migrated to shiningpanda later) --- there's some funny test results for rdflib-json, fails on everything other than jython :

http://bel-epa.com:8080/hudson/job/rdflib-rdfjson/

Cheers,

Graham

[Graham Higgins]

On Monday, 6 February 2012 10:47:47 UTC, Graham Higgins wrote:

there's some funny test results for rdflib-json, fails on everything other than jython :

http://bel-epa.com:8080/hudson/job/rdflib-rdfjson/

Nah, no mystery there, Jython's output differs slightly from Python's, a slight adjustment of the target string reveals the same issue:

  <rdf:Description rdf:about="http://example.org/about">

    <ns1:maker rdf:nodeID="na Wilder"/>

    <ns2:title xml:lang="en">Anna's Homepage</ns2:title>

    <ns2:creator>Anna Wilder</ns2:creator>

  </rdf:Description>

and

    "http://xmlns.com/foaf/0.1/maker": [

      {

        "type": "bnode",

        "value": "_:na Wilder"

      }

    ],

 I could only find a single example and that is on Ian Davis' talis rdf-json page:

http://docs.api.talis.com/platform-api/output-types/rdf-json

oh wait, there's another one here: https://github.com/bendiken/rdf-json/tree/master/etc

I'll add that later.

 

[Graham Higgins]

On Monday, 6 February 2012 04:54:04 UTC, Graham Higgins wrote:

Some of the stores rely on Python packages that haven't (yet?) been made compatible with Python 3 ... MySQL for another (there isn't a port that I can seem tp get to work as yet).

Although it's not central to rdfextras, the mysql-ctypes package will probably enable RDFLib's MySQL Store to work with pypy:

https://github.com/quora/mysql-ctypes/blob/master/setup.py

For Python 3 I'm looking at PyMySQL [1] which has suggestive commit messages such as "Fixed Python 3 compatibility"

[1] https://github.com/petehunt/PyMySQL/

shiningpanda continues to impress: they have just introduced support for a variety of databases including SQLite, MySQL, PostgreSQL and MongoDB, so with luck the relevant persistence-backed RDFLib Stores can take their place in the official shiningpanda CI constellation.

Cheers,

Graham

[Graham Higgins]

On Friday, 20 January 2012 10:35:20 UTC, Gunnar Aastrand Grimnes wrote:

Now that 3.2 is out of the way, we should really release a rdfextras
to match... I do not like this, since the current state of rdfextras
is a bit of a mess

I'm about done with the cleaning up of rdfextras. The stores have been migrated to separate packages, as have the parser/serializer pairs and the MySQL-dependent tools.

https://github.com/RDFLib/rdfextras

Although shiningpanda have introduced some support for MySQL/PostgreSQL/SQLite and MongoDB, there's no support for bsddb[3], so the CI has to remain on my server if the test run is to be executed at all, sorry 'bout that.

The web lodservice module and rdfextras.utils.graphutils are pinned to Python 2 by their dependencies on flask and pydot respectively. Flask cannot be imported in Python 2.4.

I've replicated Thomas's 2-3 setup.py, set up tox testing and there's an output from a hands-off 2-3 run in the CI build here:

http://bel-epa.com:8080/hudson/job/rdfextras/32/TOXENV=py32/console

GitHub experimentation proceeds.

Cheers,

Graham

[Gunnar Aastrand Grimnes]

Hi all,

I appreciate your effort Graham!

BUT :)

I wonder if splitting up the project is really such a good idea. We
already alienated and scared off lots of rdflib users by splitting off
rdfextras in the first place.

Would it not be possible to declare all extra dependencies as
"extra_require", then check in each module upon import if the python
version is acceptable and the dependencies are installed, and throw a
readable exception with instructions if not?

rdfextras was never meant to be highly polished - in fact it says
right there on the front-page that it's perpetual beta :)
In my experience, very fine granular modules are loved by the
developers, but hated by users and create unneeded complexity for
little gain (although I mainly know this from java apps where people
get bitten by the maven bug and go crazy, in the aperture project we
had several modules that contained a single java class)

If everyone disagrees with me though, I'll shut up and live with it :)

- Gunnar

> The web lodservice module and rdfextras.utils.graphutils are pinned to
> Python 2 by their dependencies on flask and pydot respectively. Flask cannot
> be imported in Python 2.4.

The pydot based dot converter in graphutils is quite basic and
semi-broken. We could also just remove it.
The string-based rdf2dot converter is much more "complete".

- Gunnar

>
> I've replicated Thomas's 2-3 setup.py, set up tox testing and there's an
> output from a hands-off 2-3 run in the CI build here:
>
> http://bel-epa.com:8080/hudson/job/rdfextras/32/TOXENV=py32/console
>
> GitHub experimentation proceeds.
>
> Cheers,
>
> Graham
>
>

> --
> You received this message because you are subscribed to the Google Groups
> "rdflib-dev" group.
> To view this discussion on the web visit

> https://groups.google.com/d/msg/rdflib-dev/-/vO3TbPhc-YIJ.

[Thomas Kluyver]

On 8 February 2012 02:27, Graham Higgins <gjhi...@gmail.com> wrote:

I've replicated Thomas's 2-3 setup.py, set up tox testing and there's an output from a hands-off 2-3 run in the CI build here:

http://bel-epa.com:8080/hudson/job/rdfextras/32/TOXENV=py32/console

Thanks, Graham - I'll put having a look at this on my to do list.

On the issue of one package vs several, I'm fairly ambivalent about it. I can see what Gunnar means that users don't want dependency hassle, but to some extent it's up to developers to make sure that there's an easy way to get the necessary components installed.

Thomas

[Graham Higgins]

Like Thomas, I'm ambivalent on the matter, I'm i) merely taking a leaf out of other projects' books and ii) I have my own reasons for the investigation ...

On Wednesday, 8 February 2012 08:30:19 UTC, Gunnar Aastrand Grimnes wrote:

I wonder if splitting up the project is really such a good idea. We
already alienated and scared off lots of rdflib users by splitting off
rdfextras in the first place.

That view doesn't seem to be supported by the hike in RDFLib downloads, even we accept as true Thomas's conjecture of it mostly being due to dependency satisfaction from a "big project". I do share your concern about alienating rdfextras users (few as they are) but I also think that much of rdfextras is in danger of going into terminal decline. AFAICT, external perceptions run as harsh as viewing it as little short of a dumping ground for incomplete academic projects. Redressing these negative perceptions has been a personal objective of mine. I think most people would like to know version limitations and dependencies in advance rather than finding out after having spent time installing code, reading docs, etc.

 

rdfextras was never meant to be highly polished - in fact it says
right there on the front-page that it's perpetual beta :)

Maybe so but I can't see how that even begins to address any alienation. But seriously, thanks for reminding me of this, perhaps I need to revisit my assumptions about RDFLib's direction of development.

 

Would it not be possible to declare all extra dependencies as
"extra_require", then check in each module upon import if the python
version is acceptable and the dependencies are installed, and throw a
readable exception with instructions if not?

I don't know how much (initial or continuing) work would be involved in that approach. Supporting Python 2.4 severely complicates matters as it often requires a different version of a package. Python 3.2 complicates the issue even further. I feel the approach risks obfuscating matters further.

You observed in an earlier post that rdfextras was "a mess", I suspect that it is/was in more of a mess than it might have seemed. Having split off the submodules into separate packages, it is now clearly evident that only a couple of rdfextras modules pass all the tests:

http://bel-epa.com:8080/hudson/

the rest are, well, buggy. For example the RDF-JSON parser/serializer had no tests at all and fails even on the example given on Ian's rdfjson page. I make no criticism of the contributor, contributions are always welcome --- but rdflib does have a wiki page that explicitly requests of developers:

"Any new functionality being added to rdflib should have doc tests and unit tests. Test should be added for any functionality being changed that currently does not have any doc tests or unit tests. And all the tests should be run before committing changes to make sure the changes did not break anything."

it's a pity that this seems to have been honoured more in the breach and that has had deleterious effects on the codebase.

One of the subsidiary objectives of migrating modules into plugin packages was to enable me (and, subsequently, contributors/maintainers) to run the relevant package tests with a minimum of fuss and bother. Given the fact that we must cut our maintenance cloth according to our resources coat, the effective triage performed by splitting the modules into separate packages (with separate tests and docs) should allow those incomplete packages that fall on stony ground to wither appropriately and should encourage useful/well-maintained packages to flourish.

In my experience, very fine granular modules are loved by the
developers, but hated by users and create unneeded complexity for
little gain (although I mainly know this from java apps where people
get bitten by the maven bug and go crazy, in the aperture project we
had several modules that contained a single java class)

There's a different perspective that could be adopted - after migrating the modules to packages, there's not a lot left in rdfextras. You mentioned previously that it'd be nice to re-integrate a cleaned-up sparql-p module back into RDFLib core --- the same could be done for the now-cleansed modules: utils, store, tools and web, at which point rdfextras could be completely removed.

If everyone disagrees with me though, I'll shut up and live with it :)

One of the benefits of performing this experimental investigation on GitHub is that it can be expunged completely with a single mouse-click. I'm completely relaxed about doing that, my primary motivation for the investigation is/was very pragmatic, I have been considering the use of rdflib in a commercial context and the exercise was part of my "due diligence" process. 

 

The pydot based dot converter in graphutils is quite basic and

semi-broken. We could also just remove it.

The string-based rdf2dot converter is much more "complete".

Indeed but my point is that work needed to be done in order to expose this (one example, taken at random) as an issue.

There are one or two minor technical issues which I haven't mentioned. At one point I was considering re-including the sparql2sql code but discovered that mercurial doesn't actually delete closed branches, whereas git does. GitHub itself offers direct online editing of docs this lowering of barriers to contributions might help improve the documentation.

As regards developer support, there is a free-for-use-with-FOSS git cross-platform GUI app, smartgit [1] which I found most useful.

I'll refrain from migrating the issue tickets from GCode to Git until this discussion resolves - both have atom-based APIs, so the task is not especially demanding.

[1] http://www.syntevo.com/smartgit/index.html

In closing, I'll mention one other objective of the exercise, which was to lay bare (and perhaps allow limits to be set on) the amount of work involved in getting rdfextras up to py3 compatibility. I imagine this effort will be a lot more manageable if done piecemeal on  separate plugin modules rather than on a monolithic codebase.

Cheers,

Graham

[Gunnar Aastrand Grimnes]

>> I wonder if splitting up the project is really such a good idea. We
>> already alienated and scared off lots of rdflib users by splitting off
>> rdfextras in the first place.
>

Actually - thinking about it again, the two things that people
complained about was after version 3 was: i) renaming packages for
"no" reason (there was a good reason, but perhaps not well explained),
ii) you needed to add the register plugin lines to have sparql.
I don't know why we didn't add the extension entry point for the
sparql plugins straight away - I hadn't understood the plugin stuff at
the time, and I guess others just forgot ....

> [...] Redressing these negative perceptions has been a personal

> objective of mine. I think most people would like to know version
> limitations and dependencies in advance rather than finding out after having
> spent time installing code, reading docs, etc.

And I think in updating the docs and showing that there is some
activity we've already made a good step in the right direction!

>> rdfextras was never meant to be highly polished - in fact it says
>> right there on the front-page that it's perpetual beta :)
> Maybe so but I can't see how that even begins to address any alienation. But
> seriously, thanks for reminding me of this, perhaps I need to revisit my
> assumptions about RDFLib's direction of development.

You do about 90% of the development at the moment :) - you should know
and set the direction! :)

> [...] Supporting Python 2.4 severely complicates matters as it often

> requires a different version of a package. Python 3.2 complicates the issue
> even further. I feel the approach risks obfuscating matters further.

[...]

> One of the subsidiary objectives of migrating modules into plugin packages
> was to enable me (and, subsequently, contributors/maintainers) to run the
> relevant package tests with a minimum of fuss and bother. Given the fact
> that we must cut our maintenance cloth according to our resources coat, the
> effective triage performed by splitting the modules into separate packages
> (with separate tests and docs) should allow those incomplete packages that
> fall on stony ground to wither appropriately and should encourage
> useful/well-maintained packages to flourish.

That is a good point - you bravely restored the different stores, now,
personally I have no interest in maintaining a zope-db store for
instance, if it's in a separate project it'll be obvious if no one
else has any interest either and it lying untouched for years.

> There's a different perspective that could be adopted - after migrating the
> modules to packages, there's not a lot left in rdfextras. You mentioned
> previously that it'd be nice to re-integrate a cleaned-up sparql-p module
> back into RDFLib core --- the same could be done for the now-cleansed
> modules: utils, store, tools and web, at which point rdfextras could be
> completely removed.

Good point - as someone else said a while back, rdfextras is a bit of
a breeding ground for rdflib modules, when something is stable, we
could migrate it back. Proper automatic entry_point based plugin
registration means it doesnt matter so much if the packages change.

Looking again at your new modules, having the DB stores (-postgresql,
-zodb, -kyotocabinet, -mysql) separate does seem to make a lots of
sense, each pull in dependencies for their DB drivers.

jsonld was already mentioned as a suitable candidate for inclusion
back into rdflib, at least when the json-ld spec goes stable.

The -web stuff I would maybe split off as a separate package - it has
lots of heavy dependencies.

Soon my biggest issue is that now I have to really learn git - and I
only just started grokking merging in hg :)

[Graham Higgins]

On Wednesday, 8 February 2012 20:04:34 UTC, Gunnar Aastrand Grimnes wrote:

 

You do about 90% of the development at the moment :) - you should know
and set the direction! :)

My grubby fingerprints are all over the commit record, agreed. But TBH, it's all minor-league stuff: refactoring, shuffling code around and a few straightforward bug fixes. I do almost no actual /development/ per se. By "development", I mean the kind of thing that's currently being thrashed out in the discussions of issue 211, preserving the lexical form of Literals. This is why I tend to defer to others on approaches to the modelling.

you bravely restored the different stores, now,
personally I have no interest in maintaining a zope-db store for
instance, if it's in a separate project it'll be obvious if no one
else has any interest either and it lying untouched for years

Ironically, the zope-db store is one of the few stores that passes all of the tests [1] (although it's a shame it's not py3compat and is unlikely ever to be so). 

The stores that are based on the AbstractSQLStore/FOPLRelationalModel all exhibit the same three/four test failures, strongly suggesting a small set of common issues in the underlying modelling classes which, if fixed, would bring them all back into play as viable modules.

I'm also experimenting with a SQLAlchemy (dbapi2) version of the now-obsolete SQLObject store that might well provide a useful abstraction, allowing the straightforward use of a variety of DB backends supported by SQLAlchemy [2] merely by switching config string - SQLAlchemy uses a "dburi" scheme to achieve this, e.g. 

mysqluri="mysql+mysqldb://user:password@host:port/dbname?extraconfig"

drizzleuri="drizzle+mysqldb:://user:password@host:port/dbname?extraconfig""

postgresqluri='postgresql+psycopg2://user:password@host:port/dbname"'

It's possibly a chimera because of the inevitable SQL variations between the back-ends (MySQL vs SQLite for example) but worth investigating all the same.

The key-value approach to modelling (e.g. Sleepycat, Kyoto Cabinet) offers some interesting possibilities, e.g. adapting it to a Riak back-end looks reasonably straightforward. The burgeoning number of "no-SQL" data stores in most cases further enhances these possibilities.

jsonld was already mentioned as a suitable candidate for inclusion
back into rdflib, at least when the json-ld spec goes stable.

This is where I tend to defer. My controversial take on it is that RDFLib should offer just RDF/XML. The other parsers/serializers are optional surface syntax additions and are not "core" RDF, so should be made available as separate plugins. That would most likely break a lot of existing code, so we're sort of stuck with the bloat. If it were up to me (but it isn't) I'd resist any further intrusion of Notation3 syntax into RDFLib core. I have yet to find any empirical support for the claim that n3 is much more readable than RDF/XML and I'm occasionally tempted to make the argument that the claim is merely an unsupported conjecture about a issue that is properly in the domain of cognitive psychology but I'm too jaded to care overmuch. So I'm entirely sympathetic when you write that you have little personal interest in devoting time to maintaining a zope-based store because I'm exactly the same where n3 is concerned.

The -web stuff I would maybe split off as a separate package - it has
lots of heavy dependencies.

That would be useful. The flask dependency pulls in werkzeug which pins it to Python 2 - although, as has been observed, using bottle would obviate that version pin.

Soon my biggest issue is that now I have to really learn git - and I
only just started grokking merging in hg :)

Sorry about that, I'm in the same position but GitHub has a clear edge and, according to the technical hardnoses, so goes git. I'll re-recommend Smartgit, it can be used for non-commercial purposes. git's staging is particularly useful for parking your working code, doing a pull from the main repos and then unstaging your working code back over the top of what was pulled. Very useful, I've found.

There's also the Hg-Git mercurial plugin - http://hg-git.github.com/ which will allow you to use hg commands with a git repos. I found that it doesn't handle branches terribly well though.

[1] http://bel-epa.com:8080/hudson/job/rdflib-zodb/

[2] http://docs.sqlalchemy.org/en/latest/core/engines.html#supported-databases 

Cheers,

Graham

[Graham Higgins]

Dear all,

Given that there seems to be a general consensus in favour of moving to GitHub, this weekend I will be completing the migration of both RDFLib and rdfextras from google code to GitHub.

GitHub's RDFLib/rdflib repos is now up to date with respect to the latest commits to the Googlecode repos, Gcode and GitHub are now in synch.

The RDFLib Googlecode wiki pages have been transferred, with most having been rewritten in restructuredText for compatibility with the RDFLib documentation.

Although new releases are planned for the immediate future, right now there is no effect on the current Pypi entries. They can be updated later, on the occasion of the release.

The remaining task, which I intend to perform this weekend, is to transfer the RDFLib and rdfextras issues from Googlecode to their respective github project areas.

I'd be grateful if people could start using the git repositories for contributing changes to the documentation, bugfixes, features and enhancements.

There is a raft of minor documentation/docstring/long_description changes to be made in terms of updating URLs to point to GitHub instead of (variously) rdflib.net / code.google.com.

GitHub offers through-the-web-yet-versioned editing to those with commit privileges. Contributors working on small documentation fixes may well find this more amenable than the previous clone-edit-push cycle (although a "pull" request is still always welcome).

If you'd like to take advantage of this facility, you'll need a (free) GitHub account. Please let me/gromgull know your GitHub a/c name if you need commit privs.

(As far as code contributions are concerned, please see https://github.com/RDFLib/rdflib/wiki/DeveloperGuide)

That is all.

Cheers,

Graham