028f2d5d89
Started on release notes and readme for 2.2a2.
2001-08-29 22:04:08 +00:00
3070ee6b37
Experimental feature: allow \n as well as \r as newline for text files, by breaking in to the lowlevel I/O system. Can be disabled by defining WITHOUT_UNIX_NEWLINES.
2001-08-27 23:16:34 +00:00
e7d8322630
exceptions was missing from the module list. Added.
2001-08-27 22:50:41 +00:00
3c06b9a7d4
Use the new macresource module to open the accompanying resource file (if needed).
2001-08-27 21:41:23 +00:00
a5d7da528b
need() now returns the refno of the resource file opened, or None if the
...
specified resource was already available and no file was opened.
2001-08-27 21:37:45 +00:00
de3226f7f9
Module to help other modules locate their resources. It currently knows about
...
resources in applets and separate OS9 style resource files, but it will
eventually also be thought the hoops to jump through on OSX/MachO.
2001-08-27 21:21:07 +00:00
8f2b13efce
These have long outlived there usefulness, in my opinion. Moved to Unsupported.
2001-08-27 21:17:44 +00:00
de1d4957c0
Added Dean Draayer to the thank you list.
2001-08-27 15:30:48 +00:00
911e87de6f
Patch by Dean Draayer: support for indeterminate progress bars. You
...
get these by specifying maxval=0, which is now also the default.
Untested.
2001-08-27 15:24:07 +00:00
206bd57355
When we're freezing to sourcecode and one of the modules is a dynamic module that is in a package we freeze that module at toplevel (outside any package). Not optimal, but there is little more we can do as config.c has no way to specify a builtin module has to be dumped into a package.
2001-08-27 13:59:35 +00:00
60aa4ccdc0
Updated to the current state of affairs.
2001-08-27 13:58:21 +00:00
1c2a2b71e1
Added targets for building the Carbon and Classic interpreter if you don't want to go through fullbuild.py.
2001-08-27 13:57:43 +00:00
dc4d925be9
- A forgotten "from Carbon".
...
- Made the "killed unknown window" code dependent on a global var,
so you can easily turn the behaviour off for IDE debugging.
2001-08-27 10:55:41 +00:00
4d3052acb0
A few forgotten "from Carbon"s.
2001-08-27 10:54:55 +00:00
5a6fdcd371
Import the MacOS toolbox modules from the Carbon package.
2001-08-25 12:15:04 +00:00
6dba6bc0a2
Step 2 in putting the MacOS toolbox modules in a package: issue a DepracationWarning in the compatibility modules.
2001-08-25 11:53:43 +00:00
75a2f85593
Last renamed module that wasn't removed yet.
2001-08-24 09:17:15 +00:00
cf144b0e9e
Wrapper modules underound the toolbox modules, which now have an _ prepended.
2001-08-23 14:13:06 +00:00
25a5bd7708
Renamed.
2001-08-23 14:11:10 +00:00
50ecb0ad83
Renamed the Mac toolbox modules to have an initial _ in their name.
2001-08-23 14:02:09 +00:00
77105a960b
The MacOS toolbox modules have acquired an _ in front of their name. Normal usage is through a wrapper module (without underscore) which lives in the Carbon package.
2001-08-23 13:51:46 +00:00
404e0b7c1e
These long dead files somehow got revived. Killed them (but for how
...
long? :-).
2001-08-21 10:51:47 +00:00
0e53685d10
This file has been dead for aeons. I have no idea how it suddenly
...
surfaced again.
2001-08-21 10:49:11 +00:00
a0f4369f5a
Oops, these compatibility modules were missing. Which went unnoticed because their companions had been put in the wrong place.
2001-08-20 15:35:57 +00:00
7586b049ba
Various toolbox modules were generated in lib-dynload accidentally
...
in stead of in Carbon. Fixed.
2001-08-20 15:31:56 +00:00
d0688ebc10
Oops, this file shouldn't have been removed.
2001-08-20 10:20:27 +00:00
914f9e926d
The destination folder is now :Lib:lib-dynload
2001-08-19 22:32:57 +00:00
f60edf861c
PATCHLEVEL is outdated, use PY_VERSION.
2001-08-19 22:32:27 +00:00
ad251c7516
Step 1 in packaging the toolbox modules and making MacPython more
...
like normal Python. toolbox modules are now in the Carbon package
in :Mac:Lib, with a workaround flat namespace in :Mac:Lib:lib-compat.
Other dynamic modules are in :Lib:lib-dynload. :Mac:Lib:lib-toolbox and
:Mac:Plugins are gone.
2001-08-19 22:30:31 +00:00
d39c246a4c
Dynamic modules are now put in :Lib:lib-dynload by default. For the toolbox modules this is overridden to put them in :Mac:Lib:Carbon.
2001-08-19 22:29:57 +00:00
edb17c971f
Compatibility modules. lib-compat is on the default sys.path for MacPython 2.2, and each of these modules imports * from its namesake in the Carbon package.
2001-08-19 22:28:32 +00:00
63f6b4984b
Moved to either :Mac:Lib (WASTEconst and files that weren't generated) or to the Carbon package.
2001-08-19 22:20:55 +00:00
ab98ae9b4e
The modules with toolbox constants.
2001-08-19 22:13:00 +00:00
06eb422a37
Carbon is now a package encapsulating all the toolbox modules. Carbon is not
...
the best of names right now (because QuickTime, for instance, is part of
its own framekwork in OSX terminology, and because all these modules also
work on pre-Carbon MacOS) but in a year or so it will be:-).
2001-08-19 22:07:59 +00:00
52caac1c55
Moved here form lib-toolbox, for lack of a better place to go.
2001-08-19 22:05:33 +00:00
d0fc42f439
Moved here from lib-toolbox, where they should never have been in the first place (all the other stuff there wa generated with bgen).
2001-08-19 22:05:06 +00:00
42b1539e98
Step 1 in packaging the toolbox modules and making MacPython more
...
like normal Python. toolbox modules are now in the Carbon package
in :Mac:Lib, with a workaround flat namespace in :Mac:Lib:lib-compat.
Other dynamic modules are in :Lib:lib-dynload. :Mac:Lib:lib-toolbox and
:Mac:Plugins are gone.
2001-08-19 22:02:56 +00:00
106fceacb2
Temporarily disabled the import hook. It breaks with the package-based
...
Carbon and its workaround.
2001-08-19 22:00:20 +00:00
13dca1d50f
Got rid of all the plugin xml files: they are generated, and
...
they were only in the repository for people building MacPython from
CVS (the .cmp project files are in a MacPython source
distribution). The process to regenerate them is now easier (and
documented!) so these shouldn't be needed anymore.
And eventually they should all be built by setup.py anyway.
2001-08-19 20:28:39 +00:00
e791a6421f
If genpluginprojects is called from fullbuild we set the Python source directory to be the same as fullbuild uses (in stead of using the default sys.prefix). This fixes an issue Mark Day raised that you can't use fullbuild with one Python installation to build another one.
2001-08-16 20:39:17 +00:00
7a401795db
Long time overdue: change sys.path defaults so that people will
...
have to do "from PIL import Image" instead of "import Image".
2001-08-16 15:16:19 +00:00
1690409243
Updated to the current state of things (long overdue).
2001-08-16 14:10:56 +00:00
686a4a6d0f
Removed expat from the access paths, it isn't needed.
2001-08-16 14:10:08 +00:00
ce3016a142
Merged release21-maint changes.
2001-08-12 00:11:15 +00:00
d7b568ac4d
test_glob found a nasty bug in GUSI opendir(): it will not fail when called on files, but in stead open the parent directory! We now explicitly test for the argument being a directory and simulate ENOTDIR otherwise.
2001-08-11 23:18:55 +00:00
b5982221bb
Before asking the finder to start the application (if start=1 is specified), check that it isn't incidentally running already.
2001-08-11 22:29:18 +00:00
fb513a20b5
Got rid of the activate() so codewarrior doesn't come to front. It isn't needed, and without it you can get work done while building the projects:-)
2001-08-11 22:28:11 +00:00
af86470e85
Added a note about the various tests here.
2001-08-11 21:13:19 +00:00
f3456912e4
use the proper prefix file under Carbon
2001-08-11 10:07:23 +00:00
09379da7de
Regenerated.
2001-08-10 12:17:04 +00:00
Jack Jansen
Just van Rossum