Skip to content
Snippets Groups Projects
  1. Mar 03, 2021
  2. Dec 30, 2020
  3. Oct 10, 2020
  4. Sep 29, 2020
  5. Sep 09, 2020
  6. Sep 08, 2020
  7. Dec 14, 2018
    • Nat Goodspeed's avatar
      SL-10153: Review and rationalize fetching paths from environment. · c4096f67
      Nat Goodspeed authored
      Use LLStringUtil::getenv() or getoptenv() whenever we fetch a string that will
      be used as a pathname.
      
      Use LLFile::tmpdir() instead of getenv("TEMP").
      
      As an added extra-special bonus, finally clean up $TMP/llcontrol-test-zzzzzz
      directories that have been accumulating every time we run a local build!
      c4096f67
  8. Dec 20, 2017
    • Nat Goodspeed's avatar
      MAINT-8087: Use env vars from VMP for AppData\Roaming and Local. · 5002bf56
      Nat Goodspeed authored
      On Windows, when logged in with a non-ASCII username, every one of the three
      documented APIs -- SHGetSpecialFolderPath(), SHGetFolderPath() and
      SHGetKnownFolderPath() -- fails to retrieve any pathname at all. We cannot
      account for the fact that the oldest of these continues to work with the
      release viewer and within a Python script (though not, curiously, from a
      Python interactive session). With a non-ASCII username, they consistently fail
      when called from an Alex Ivy viewer build: "The filename, directory name, or
      volume label syntax is incorrect."
      
      Empirically, with a non-ASCII username, the preset APPDATA and LOCALAPPDATA
      environment variables are also useless, e.g. c:\Users\??????\AppData\Roaming
      where those are, yup, actual question marks.
      
      Empirically, the VMP is able to successfully call SHGetFolderPath() to
      retrieve both AppData\Roaming and AppData\Local. Therefore, we make the VMP
      set the APPDATA and LOCALAPPDATA environment variables to the UTF-8 encoded
      correct pathnames. Instead of calling SHGetSomethingFolderPath() at all, make
      LLDir_Win32 retrieve those environment variables.
      
      Make LLFile::mkdir() treat "directory already exists" as a success case. Every
      single call fell into one of two categories: either it didn't check success at
      all, or it tested specially to exempt errno == EEXIST. Migrate that test into
      mkdir(); eliminate it from call sites.
      
      Make LLDir::append() and add() convenience functions accept variadic
      arguments. Replace add(add()...) constructs, as well as clumsy concatenations
      of directory names and getDirDelimiter(), with simple variadic add() calls.
      5002bf56
  9. Oct 13, 2016
  10. Nov 10, 2015
  11. Apr 20, 2018
  12. Apr 15, 2015
    • Nat Goodspeed's avatar
      Strip down the Windows ll[io]fstream implementations to constructors · e9be710d
      Nat Goodspeed authored
      and open() methods. The only remaining value added by ll[io]fstream over
      std::[io]stream is proper handling of non-ASCII pathnames, which can be done
      by deriving from std::[io]stream, converting pathname strings and passing them
      to the corresponding base-class methods.
      This is only necessary on Windows. On Posix, ll[io]fstream are already
      typedefs for std::[io]fstream.
      This change removes a significant volume of cruft from llfile.{h,cpp}.
      e9be710d
  13. Apr 10, 2015
  14. Apr 07, 2015
  15. Jan 28, 2015
    • Nat Goodspeed's avatar
      MAINT-4744: Eliminate viewer dependency on (old) GNU libstdc++. · ae6440ee
      Nat Goodspeed authored
      To be more accurate, this changeset doesn't actually eliminate the dependency:
      it eliminates the use cases for the llifstream / llofstream feature that
      requires it.
      Currently you can construct an llifstream or llofstream from an open LLFILE*
      file handle (or, except on Windows, an int file descriptor). But rather than
      containing a streambuf implementation based on FILE*, llfile.h relies on the
      fact that the Windows std::filebuf happens to support that as a nonstandard
      extension; also on a nonstandard GNU extension __gnu_cxx::stdio_filebuf<char>.
      To move from GNU libstdc++ to clang's libc++ (the direction on Mac), we could
      code a streambuf that supports FILE*. But before doing that, it's worth asking
      whether anyone actually uses this questionable feature.
      In fact there were only two methods: LLWearable::exportFile() and importFile()
      -- and only one call to either, in LLViewerWearable::saveNewAsset(). The code
      in saveNewAsset() opened the LLFILE* immediately before calling exportFile(),
      meaning we could reasonably push the open operation down into exportFile().
      That logic was complex anyway due to the need for the caller to close the
      LLFILE* regardless of the success of the exportFile().
      Change LLWearable::exportFile() and importFile() to accept a std::string
      filename rather than an open LLFILE*. Change LLViewerWearable::saveNewAsset()
      to simply call exportFile(filename) rather than horsing around with an LLFILE*
      handle. (This improves the code in another way too: it encapsulates the need
      to open the relevant file in binary mode. Previously, each caller had to
      remember to do that.)
      To prevent inadvertent reintroduction of ll[io]fstream(LLFILE*) code, add
      llstream_LLFILE preprocessor macro (default 0) to control access to the
      relevant constructors. Also suppress rdbuf() override, the only method whose
      signature references llstdio_filebuf.
      ae6440ee
  16. Oct 17, 2014
  17. Mar 07, 2014
  18. Apr 30, 2013
  19. Apr 22, 2013
  20. Mar 29, 2013
  21. Nov 15, 2012
    • Richard Linden's avatar
      SH-3406 WIP convert fast timers to lltrace system · 9d77e030
      Richard Linden authored
      cleaning up build
      moved most includes of windows.h to llwin32headers.h to disable min/max macros, etc
      streamlined Time class and consolidated functionality in BlockTimer class
      llfasttimer is no longer included via llstring.h, so had to add it manually in several places
      9d77e030
  22. Sep 22, 2012
  23. Sep 20, 2012
  24. Apr 18, 2012
    • Nat Goodspeed's avatar
      IQA-463: Add error logging for certain LLFile operations. · 54228ddf
      Nat Goodspeed authored
      Attempting to debug an observed LLFile::remove() failure, I was floored to
      find that remove() made no attempt whatsoever to report its lack of success!
      Add warnif() function to log errno text in platform-dependent way. Support the
      notion that for some functions, certain errno values are acceptable -- e.g. we
      expect stat() to frequently hit ENOENT -- and need not be logged.
      Add commented-out Windows-specific logic to try to provide further information
      in the case of EACCES ("Permission denied," e.g. another process has the file
      open). To use, enable the code block, download handle.exe and turn on DEBUG
      logging for LLFile. handle.exe can be obtained from:
      http://technet.microsoft.com/en-us/sysinternals/bb896655
      54228ddf
  25. Nov 19, 2010
  26. Oct 13, 2010
  27. Sep 21, 2010
  28. Aug 13, 2010
  29. Jan 07, 2009
  30. Jun 25, 2008
  31. Jun 02, 2008
  32. May 08, 2008
  33. Mar 25, 2008
  34. Mar 20, 2008
  35. Mar 14, 2008
Loading