1. 09 Jul, 2003 1 commit
  2. 08 Jul, 2003 10 commits
  3. 07 Jul, 2003 9 commits
  4. 06 Jul, 2003 2 commits
  5. 05 Jul, 2003 1 commit
  6. 04 Jul, 2003 7 commits
    • Just van Rossum's avatar
      #765903: · 27190f0e
      Just van Rossum authored
      - added bundle_id/--bundle-id option, to specify the CFBundleIndentifier
      #765615:
      - in the appropriate situation, prepend $PATH with our path instead of
        setting it.
      27190f0e
    • Jack Jansen's avatar
      Fixed lots of minor issues found by Edward Moy: incorrect version · 37e92842
      Jack Jansen authored
      strings, non-standard naming of things in bundles, etc.
      37e92842
    • Jack Jansen's avatar
      Fixed two bugs in MacOSX framework handling spotted by Edward Moy: · dfac99f6
      Jack Jansen authored
      - In the top level Makefile, the argument to -install_name should be
        prepended with /System/Library/Frameworks/, so it is an absolute path.
      - In the top level Makefile, because of 2), RUNSHARED needs to be set to
        DYLD_FRAMEWORK_PATH=<path to local framework> and $(RUNSHARED) prepended
        to the $(MAKE) lines in the frameworkinstallmaclib and
        frameworkinstallapps targets.
      dfac99f6
    • Jack Jansen's avatar
      Added missing newline at end of file. · d13c9d2d
      Jack Jansen authored
      d13c9d2d
    • Jack Jansen's avatar
      7a3446ee
    • Jack Jansen's avatar
      If a --python option is used to specify the Python to use in the #! · 3a81c3de
      Jack Jansen authored
      line also use this as the executable in the bundle.
      3a81c3de
    • Tim Peters's avatar
      An Anonymous Coward on c.l.py posted a little program with bizarre · c1ae3ec1
      Tim Peters authored
      behavior, creating many threads very quickly.  A long debugging session
      revealed that the Windows implementation of PyThread_start_new_thread()
      was choked with "laziness" errors:
      
      1. It checked MS _beginthread() for a failure return, but when that
         happened it returned heap trash as the function result, instead of
         an id of -1 (the proper error-return value).
      
      2. It didn't consider that the Win32 CreateSemaphore() can fail.
      
      3. When creating a great many threads very quickly, it's quite possible
         that any particular bootstrap call can take virtually any amount of
         time to return.  But the code waited for a maximum of 5 seconds, and
         didn't check to see whether the semaphore it was waiting for got
         signaled.  If it in fact timed out, the function could again return
         heap trash as the function result.  This is actually what confused
         the test program, as the heap trash usually turned out to be 0, and
         then multiple threads all got id 0 simultaneously, confusing the
         hell out of threading.py's _active dict (mapping id to thread
         object).  A variety of baffling behaviors followed from that.
      
      WRT #1 and #2, error returns are checked now, and "thread.error: can't
      start new thread" gets raised now if a new thread (or new semaphore)
      can't be created.  WRT #3, we now wait for the semaphore without a
      timeout.
      
      Also removed useless local vrbls, folded long lines, and changed callobj
      to a stack auto (it was going thru malloc/free instead, for no discernible
      reason).
      
      Bugfix candidate.
      c1ae3ec1
  7. 03 Jul, 2003 2 commits
  8. 02 Jul, 2003 8 commits