Skip to content
Snippets Groups Projects
This project is mirrored from https://git.alchemyviewer.org/alchemy/alchemy-next.git. Pull mirroring failed .
Repository mirroring has been paused due to too many failed attempts. It can be resumed by a project maintainer or owner.
  1. Oct 24, 2017
  2. Oct 13, 2017
  3. Oct 12, 2017
  4. Oct 11, 2017
  5. Oct 10, 2017
  6. Oct 09, 2017
    • Nat Goodspeed's avatar
    • Nat Goodspeed's avatar
      763a04ce
    • Nat Goodspeed's avatar
    • Nat Goodspeed's avatar
    • Nat Goodspeed's avatar
      MAINT-7831: Update viewer_manifest.py to use 'with self.prefix(...):' · be0e3cb2
      Nat Goodspeed authored
      Now that LLManifest.prefix() supports use as a context manager:
      
          with self.prefix(...):
              ...
      
      convert existing calls to that form.
      
      This was an interesting exercise because it surfaced at least two places where
      the indentation did not match the self.prefix() nesting, plus another place
      where existing code was undented without a self.end_prefix() call. (That last
      was an uncaught logic bug.) This underscores the value of using a SINGLE
      consistent, idiomatic mechanism to limit the scope of each self.prefix() call.
      be0e3cb2
    • Nat Goodspeed's avatar
      MAINT-7831: Allow LLManifest.prefix() to be a context manager. · d9d6df31
      Nat Goodspeed authored
      LLManifest.prefix() dates back to before Python had a 'with' statement or the
      notion of a context manager. That's why every prefix() call requires a
      corresponding end_prefix() call.
      
      Existing usage is of the form:
      
          if self.prefix(...some args...):
              self.path(...)
              ...
              self.end_prefix()
      
      The use of an 'if' statement is solely to allow the coder to indent the
      statements between the self.prefix() call and the corresponding call to
      self.end_prefix() -- there is no intention to make that code conditional.
      self.prefix() unconditionally returned True to facilitate that usage.
      
      But now that we have the 'with' statement, this all feels a little silly. Make
      prefix() return an instance of a context-manager class so that it's reasonable
      to say instead:
      
          with self.prefix(...some args...):
              self.path(...)
              ...
      
      and have the Right Things happen simply by leaving the 'with' block.
      
      The only tricky part is code to preserve compatibility with old-style usage:
      
      * The context manager has a __nonzero__() method so that if it's tested in an
        'if' statement, it can unconditionally return True.
      
      * On leaving the 'with' block, rather than simply popping the top of each
        prefix stack, the context manager restores its length to the same length it
        had before that prefix() call. This allows for (erroneous but hardly
        unlikely) usage of the form:
      
          with self.prefix(...some args...):
              self.path(...)
              ...
              self.end_prefix()
      
      Restoring the previous length makes the context manager insensitive to whether
      or not end_prefix() has popped the most recent prefix() entries.
      d9d6df31
  7. Oct 06, 2017
  8. Oct 05, 2017
  9. Oct 04, 2017
  10. Oct 02, 2017
  11. Sep 30, 2017
    • Nat Goodspeed's avatar
      MAINT-7081: Eliminate unused variable errors after new refactoring. · 6b508cd9
      Nat Goodspeed authored
      The new helper functions check_curl_easy_setopt() and
      check_curl_multi_setopt() encapsulate the pervasive idiom:
      
          code = curl_{easy,multi}_setopt(handle, option, arg);
          check_curl_{easy,multi}_code(code, option);
      
      But since each of these helper functions contains its own local CURL{,M}code
      variable 'code', having a caller-scope variable reused for every such call is
      no longer necessary -- in fact is no longer used at all. That produces a fatal
      warning with MSVC. Get rid of those now-unused variables.
      6b508cd9
  12. Sep 29, 2017
  13. Sep 28, 2017
  14. Sep 27, 2017
  15. Sep 26, 2017
  16. Sep 23, 2017
  17. Sep 22, 2017
  18. Sep 21, 2017
Loading