1. 13 Nov, 2015 1 commit
    • Vermaat's avatar
      wip · 43323c05
      Vermaat authored
  2. 02 Nov, 2015 1 commit
  3. 26 Oct, 2015 1 commit
  4. 26 May, 2015 1 commit
  5. 01 May, 2015 1 commit
  6. 08 Dec, 2014 2 commits
  7. 24 Nov, 2014 3 commits
  8. 04 Nov, 2014 1 commit
  9. 20 Oct, 2014 1 commit
    • Vermaat's avatar
      Use unicode strings · 2a4dc3c1
      Vermaat authored
      Don't fix what ain't broken. Unfortunately, string handling in Mutalyzer
      really is broken. So we fix it.
      Internally, all strings should be represented by unicode strings as much as
      possible. The main exception are large reference sequence strings. These can
      often better be BioPython sequence objects, since that is how we usually get
      them in the first place.
      These changes will hopefully make Mutalyzer more reliable in working with
      incoming data. As a bonus, they're a first (small) step towards Python 3
      compatibility [1].
      Our strategy is as follows:
      1. We use `from __future__ import unicode_literals` at the top of every file.
      2. All incoming strings are decoded to unicode (if necessary) as soon as
      3. Outgoing strings are encoded to UTF8 (if necessary) as late as possible.
      4. BioPython sequence objects can be based on byte strings as well as unicode
      5. In the database, everything is UTF8.
      6. We worry about uploaded and downloaded reference files and batch jobs in a
         later commit.
      Point 1 will ensure that all string literals in our source code will be
      unicode strings [2].
      As for point 4, sometimes this may even change under our eyes (e.g., calling
      `.reverse_complement()` will change it to a byte string). We don't care as
      long as they're BioPython objects, only when we get the sequence out we must
      have it as unicode string. Their contents are always in the ASCII range
      Although `Bio.Seq.reverse_complement` works fine on Python byte strings (and
      we used to rely on that), it crashes on a Python unicode string. So we take
      care to only use it on BioPython sequence objects and wrote our own reverse
      complement function for unicode strings (`mutalyzer.util.reverse_complement`).
      As for point 5, SQLAlchemy already does a very good job at presenting decoding
      from and encoding to UTF8 for us.
      The Spyne documentation has the following to say about their `String` and
      `Unicode` types [3]:
      > There are two string types in Spyne: `spyne.model.primitive.Unicode` and
      > `spyne.model.primitive.String` whose native types are `unicode` and `str`
      > respectively.
      > Unlike the Python `str`, the Spyne `String` is not for arbitrary byte
      > streams. You should not use it unless you are absolutely, positively sure
      > that you need to deal with text data with an unknown encoding. In all other
      > cases, you should just use the `Unicode` type. They actually look the same
      > from outside, this distinction is made just to properly deal with the quirks
      > surrounding Python-2's `unicode` type.
      > Remember that you have the `ByteArray` and `File` types at your disposal
      > when you need to deal with arbitrary byte streams.
      > The `String` type will be just an alias for `Unicode` once Spyne gets ported
      > to Python 3. It might even be deprecated and removed in the future, so make
      > sure you are using either `Unicode` or `ByteArray` in your interface
      > definitions.
      So let's not ignore that and never use `String` anymore in our webservice
      For the command line interface it's a bit more complicated, since there seems
      to be no reliable way to get the encoding of command line arguments. We use
      `sys.stdin.encoding` as a best guess.
      For us to interpret a sequence of bytes as text, it's key to be aware of their
      encoding. Once decoded, a text string can be safely used without having to
      worry about bytes. Without unicode we're nothing, and nothing will help
      us. Maybe we're lying, then you better not stay. But we could be safer, just
      for one day. Oh-oh-oh-ohh, oh-oh-oh-ohh, just for one day.
      [1] https://docs.python.org/2.7/howto/pyporting.html
      [2] http://python-future.org/unicode_literals.html
      [3] http://spyne.io/docs/2.10/manual/03_types.html#strings
  10. 04 Jul, 2014 1 commit
  11. 27 Mar, 2014 1 commit
  12. 26 Jan, 2014 1 commit
  13. 16 Jan, 2014 1 commit
    • Vermaat's avatar
      Port website from web.py to Flask · 0abce583
      Vermaat authored
      This includes changing a lot of routes and parameter names to be more
      consistent. We try to remain backwards compatible as much as possible
      by providing redirects from old routes and parameter names.
  14. 13 Dec, 2013 2 commits
  15. 19 Feb, 2013 1 commit
  16. 01 Oct, 2012 1 commit
  17. 22 Aug, 2012 1 commit
  18. 21 Aug, 2012 1 commit
  19. 20 Aug, 2012 1 commit
  20. 11 May, 2012 1 commit
  21. 12 Apr, 2012 1 commit
  22. 20 Feb, 2012 1 commit
  23. 18 Feb, 2012 1 commit
    • Laros's avatar
      Added the Variant Description Extractor as a web interface. · b8640a1f
      Laros authored
      - Module that provides the Variant Description Extractor functions.
      - Added an automated copyright year update.
      - Added the Variant Description Extractor web interface.
      -  Template page for the Variant Description Extractor.
      - Cosmetic changes.
      Added a presentation.
      git-svn-id: https://humgenprojects.lumc.nl/svn/mutalyzer/trunk@479 eb6bd6ab-9ccd-42b9-aceb-e2899b4a52f1
  24. 29 Sep, 2011 1 commit
  25. 26 Sep, 2011 1 commit
  26. 21 Jul, 2011 1 commit
  27. 05 Apr, 2011 1 commit
  28. 28 Mar, 2011 1 commit
  29. 31 Jan, 2011 1 commit
  30. 26 Jan, 2011 1 commit
    • Vermaat's avatar
      templates/menu.html: · 70c603e2
      Vermaat authored
      - Link to bugtracker is now absolute.
      - Header for external links is no longer a link.
      - Bugfix for previous commit (transparent support for different types of
        line endings in batch input files).
      - Added batch tests with big input files. Added batch tests for different
        types of line endings in input files.
      git-svn-id: https://humgenprojects.lumc.nl/svn/mutalyzer/trunk@166 eb6bd6ab-9ccd-42b9-aceb-e2899b4a52f1
  31. 20 Jan, 2011 1 commit
    • Vermaat's avatar
      Added batch SNP converter. · 09870eec
      Vermaat authored
      - Updated batch routing to include SNP converter.
      - Added result file header line for batch SNP converter.
      - Added batch SNP converter.
      - Updated batch CSV input file parsing. Default is now standard Excel format
        and only if the CSV sniffer can find another dialect using a predefined set
        of delimiter characters without error we use that one.
      - Added link for batch SNP converter.
      git-svn-id: https://humgenprojects.lumc.nl/svn/mutalyzer/trunk@163 eb6bd6ab-9ccd-42b9-aceb-e2899b4a52f1
  32. 19 Jan, 2011 1 commit
  33. 14 Jan, 2011 1 commit
  34. 06 Jan, 2011 1 commit
  35. 05 Jan, 2011 1 commit
  36. 16 Nov, 2010 1 commit
    • Laros's avatar
      Fixed a bug in simplifying a delins and a minor bug in the translation of an · abf9721d
      Laros authored
      EST. Made the runMutalyzer() function in the webservices more robust and added
      some better error messages in the Retriever module.
      - A deletion in the first 3 nucleotides on an EST resulted in a crash, this is
      - A delins with a deletion and an insertion with either a common prefix or
        suffix was handled incorrectly.
      - Made the retrieval of information in the runMutalyzer() function more robust
        by using the getIndexedOutput() function of the Output object.
      - Added a more sensible error when a record could not be retrieved.
      - Fixed some capitalisation for more consistency in the web pages.
      git-svn-id: https://humgenprojects.lumc.nl/svn/mutalyzer/trunk@104 eb6bd6ab-9ccd-42b9-aceb-e2899b4a52f1