Branch: refs/heads/master
  Home:   https://github.com/Starlink/starjava
  Commit: 4e8167d8e3f922c2b878ace6da248e48914860da
      https://github.com/Starlink/starjava/commit/4e8167d8e3f922c2b878ace6da248e48914860da
  Author: Mark Taylor <[log in to unmask]>
  Date:   2013-10-24 (Thu, 24 Oct 2013)

  Changed paths:
    M ttools/src/main/uk/ac/starlink/ttools/build/JyStilts.java

  Log Message:
  -----------
  ttools: remove no-longer-required JyStilts workaround code

JyStilts had code that hacked around some inaccessible methods in
stilts.  These methods will be accessible in any version of stilts
that this version of JyStilts is likely to be working with, so
remove it.


  Commit: 317360e74e8b58f0e1118d13400b1fb18310af80
      https://github.com/Starlink/starjava/commit/317360e74e8b58f0e1118d13400b1fb18310af80
  Author: Mark Taylor <[log in to unmask]>
  Date:   2013-10-24 (Thu, 24 Oct 2013)

  Changed paths:
    M ttools/src/docs/sun256.xml
    M ttools/src/main/uk/ac/starlink/ttools/build/JyStilts.java
    M ttools/src/main/uk/ac/starlink/ttools/task/ChoiceMode.java

  Log Message:
  -----------
  ttools: fix broken non-table-producing JyStilts commands.

Some commands (pixfoot and tcube) do not output tables but are
instances of ConsumerTask.  The JyStilts script was incorrectly
identifying these as commands that present a table as their
primary output.  This caused both a documentation bug, and an
execution bug, since the ProcessingMode that did the work for
them was not getting invoked.  Fix the identification in JyStilts
so that only tasks which output via ChoiceMode are marked thus;
others are executed without special arrangements for making the
result available in python.


  Commit: 40f1aaa2d897b93fd7c695a4bc829515278a720c
      https://github.com/Starlink/starjava/commit/40f1aaa2d897b93fd7c695a4bc829515278a720c
  Author: Mark Taylor <[log in to unmask]>
  Date:   2013-10-24 (Thu, 24 Oct 2013)

  Changed paths:
    M topcat/src/docs/sun253.xml
    M ttools/src/docs/sun256.xml
    M ttools/src/main/uk/ac/starlink/ttools/jel/JELRowReader.java

  Log Message:
  -----------
  ttools: add missing getLongArrayProperty method to JELRowReader

The absence of this method meant that JEL expressions attempting to
subscript long arrays failed.  I'm 95% sure that its omission in
the first place was just an oversight rather than for some subtle
JEL reason.


  Commit: 9dd8af72ef6cf82a48ac8a24cd11c6d8a4f2ed92
      https://github.com/Starlink/starjava/commit/9dd8af72ef6cf82a48ac8a24cd11c6d8a4f2ed92
  Author: Mark Taylor <[log in to unmask]>
  Date:   2013-10-24 (Thu, 24 Oct 2013)

  Changed paths:
    M table/src/main/uk/ac/starlink/table/join/EqualsMatchEngine.java
    M table/src/testcases/uk/ac/starlink/table/join/EqualsMatchEngineTest.java
    M topcat/src/docs/sun253.xml
    M ttools/src/docs/sun256.xml

  Log Message:
  -----------
  table: EqualsMatchEngine now matches scalar numbers on value

The Exact match engine now considers two Number instances equal if they
have the same numeric value; so an Integer can now match a Long or a
Float etc.

Also fixed a bug which could (very rarely) cause a ClassCastException
when attempting to match array values of different types.


  Commit: 87425e1b7f2fb2fe25d45cbdc6c726ddd299488e
      https://github.com/Starlink/starjava/commit/87425e1b7f2fb2fe25d45cbdc6c726ddd299488e
  Author: Mark Taylor <[log in to unmask]>
  Date:   2013-10-24 (Thu, 24 Oct 2013)

  Changed paths:
    M registry/build.xml
    M registry/src/main/uk/ac/starlink/registry/RegistryRequestFactory.java

  Log Message:
  -----------
  registry: fix namespace in SOAP RI1.0 Search request

There was an error in the SOAP request sent for RI1.0 Search operations
by the registry client.  It was generating SOAP messages that started
like this:

   <rs:Search xmlns:rs='http://www.ivoa.net/wsdl/RegistrySearch/v1.0'>
     <rs:Where xmlns:rs="http://www.ivoa.net/xml/ADQL/v1.0"
         xmlns:ad="http://www.ivoa.net/xml/ADQL/v1.0"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
       <ad:Condition xsi:type="ad:likePredType">

The remapping of the rs prefix to the ADQL namespace is clearly wrong.
This was spotted by Menelaus Perdikeas at ESAC.

The problem was related to the fact that the Where element is generated
(by the Where2DOM class in the RAYREG package) in the ADQL namespace,
but it needs to be in the RS namespace.  I had noticed that, and
attempted to patch it up with the line:

   whereEl.setPrefix( "rs" );

Unfortunately, this does something completely different from what
I intended/hoped/assumed.

I've now rewritten it using DOM methods to generate the right starting
elements, namely:

   <rs:Search xmlns:rs="http://www.ivoa.net/wsdl/RegistrySearch/v1.0">
     <rs:Where>
       <ad:Condition xmlns:ad="http://www.ivoa.net/xml/ADQL/v1.0"
               xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
               xsi:type="ad:likePredType">

The broken code was in place for many years.  Although it worked with
the AstroGrid and Euro-VO registries, and an earlier incarnation of
the STSci/NVO/VAO registry service, it did not work after about mid-2010
with the STSci one.


  Commit: 5303b7902c12fefe15802ca558ea5b66a1fff405
      https://github.com/Starlink/starjava/commit/5303b7902c12fefe15802ca558ea5b66a1fff405
  Author: Mark Taylor <[log in to unmask]>
  Date:   2013-10-24 (Thu, 24 Oct 2013)

  Changed paths:
    M topcat/src/docs/sun253.xml
    M ttools/src/docs/sun256.xml

  Log Message:
  -----------
  registry: note regclient fix in user docs


Compare: https://github.com/Starlink/starjava/compare/3eb570e3e252...5303b7902c12