Parser Versions

2009-01-25 Thread Peter Gummer
Oxford Partnership wrote:
 Is there a way to change the probably ought to statement to 
 something a little more definite. i.e. is there a way to formerly 
 request this and get it in to the next build ?

I've merged OPENEHR_VERSION into the ADL Parser's current release 
branch, so you can get accurate details of the parser version.

The version() function that you were calling is gone. You can now call 
out() to get a version string.

Archetype Editor's beta release isn't using this new version of the DLL 
yet. You can get it from the link half-way down the ADL Workbench 
release page:

https://wiki.oceaninformatics.com/confluence/display/TTL/ADL+Workbench+Releases

The direct link is:

http://my.openehr.org/wsvn/oe_distrib/windows/adl_parser/dotnet/?rev=0sc=0

- Peter




Parser Versions

2009-01-24 Thread Peter Gummer
OxfordPartnership wrote:
 This seems work and I get a version back, the version reported is :
 $LastChangedRevision: 203 $
 $LastChangedDate: 2007-04-10 05:17:40 +1000 (Tue, 10 Apr 2007) $

 As this is the parser from the latest beta release of the editor, do
 those values make sense?
   

Unfortunately, not really. That string represents the last time that the 
source file openehr_version.e was committed to the branch of the 
ref_impl_eiffel repository from which the current ADL Parser DLL is 
built. As the last change to that branch was only a month or two ago, 
sadly the so-called version string is wildly inaccurate.

There have been improvements to how this is handled in the TRUNK of the 
ref_impl_eiffel repository. We probably ought to merge those 
improvements back into the ADL Parser's current release branch, in order 
to avoid this confusion.

- Peter




Parser Versions

2009-01-23 Thread OxfordPartnership
I am using the ADL parser library from within a C# application. I want
the application to be able to report on which version of the parser is
being used.

Using the following code :

openehr.version.OPENEHR_VERSION adl_parser_version =
openehr.version.Create.OPENEHR_VERSION.default_create();
EiffelSoftware.Library.Base.kernel.STRING_8 parserVersion =
adl_parser_version.version();

This seems work and I get a version back, the version reported is :
$LastChangedRevision: 203 $
$LastChangedDate: 2007-04-10 05:17:40 +1000 (Tue, 10 Apr 2007) $

As this is the parser from the latest beta release of the editor, do
those values make sense?

Also, is there a way of obtaining the version info from the XML parser library.

regards,
OP



Parser Versions

2009-01-23 Thread Oxford Partnership
Thanks for the prompt reply Peter, much appreciated.

Is there a way to change the probably ought to statement to something a
little more definite. i.e. is there a way to formerly request this and get
it in to the next build ?

thanks once again
OP

On Fri, Jan 23, 2009 at 2:00 PM, Peter Gummer 
peter.gummer at oceaninformatics.com wrote:

 OxfordPartnership wrote:
  This seems work and I get a version back, the version reported is :
  $LastChangedRevision: 203 $
  $LastChangedDate: 2007-04-10 05:17:40 +1000 (Tue, 10 Apr 2007) $
 
  As this is the parser from the latest beta release of the editor, do
  those values make sense?
 

 Unfortunately, not really. That string represents the last time that the
 source file openehr_version.e was committed to the branch of the
 ref_impl_eiffel repository from which the current ADL Parser DLL is
 built. As the last change to that branch was only a month or two ago,
 sadly the so-called version string is wildly inaccurate.

 There have been improvements to how this is handled in the TRUNK of the
 ref_impl_eiffel repository. We probably ought to merge those
 improvements back into the ADL Parser's current release branch, in order
 to avoid this confusion.

 - Peter

 ___
 openEHR-technical mailing list
 openEHR-technical at openehr.org
 http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical

-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20090123/d6b9e9d0/attachment.html