🌐 Mailman 3 October 2000 - Pythonmac-SIG - python.org

Re: [Pythonmac-SIG] Python on on a second drive
by JoanCarles p Casasín Oct. 13, 2000

Oct. 13, 2000

At 13/10/00 17:59 Jack Jansen wrote: >Okay. So it seems that applets will not work correctly if Python is >installed >on a drive different than the boot drive. > >I could try detecting this situation in the installer or ConfigurePython, >and >offering to copy PythonCore to the extension folder (in stead of creating >the >alias). > >Is that a good idea? Hmm, it's looks like... -> jc, tw®

1 0

Re: shared libs in extension folder
by kjray Oct. 13, 2000

Oct. 13, 2000

>The reason to have an _alias_ there (as opposed to the real PythonCore >library) is that this is about the only way that you can have two Python >installations on the same disk. Because the application folder is searched >before the Extensions folder I can have both 1.5.2 and 2.0 on my machine. >Whenever I run PythonInterpreter from the 1.5.2 folder it'll pick up the >1.5.2 Dynamic (shared) libraries on the Mac have internal version numbers and names that are independant of the file name (and vers resource). There should be _no_ problem in having different versions of a shared library in the Extensions folder at the same time. To avoid the DLL hell that Windows suffers, you have to use the versioning features that Apple put into its dynamic-library architecture. It is slightly confusing, but you should be using it. Please read the documentation and what I have to say later in this message: <http://developer.apple.com/techpubs/mac/PPCSoftware/PPCSoftware-41.html#HE ADING41-42> quoting the documentation: "To take a simple example, suppose that an application uses a single import library. When the application is created, it is linked with some version of that library. .... The version of the import library used at link time is called the definition version of the library (because it supplies the definitions of exported symbols, not the actual implementation of routines and initialization of variables)." "The essential requirement is that the implementation version of an import library used at run time be compatible with the definition version used at link time. The two versions do not need to be identical, but they must satisfy the same programming interface. (The implementation can be a superset of the definition library.)" "Every import library contains three version numbers: the current version number, the oldest supported definition version number, and the oldest supported implementation version number. The two latter version numbers are included to provide a way for the Code Fragment Manager to determine whether a given definition version is compatible with a given implementation version, if the current versions of the library and the definition version used to link the application are not identical." " IMPORTANT The current version number must always be greater than or equal to both the oldest supported definition version number and the oldest supported implementation version number." ------ If you're building a PythonCore 2.0 PPC shared library in CodeWarrior that is _incompatible_ with Python 1.x, go to the Project Settings / Linker / PPC PEF pane... the "Version Info" in that pane is NOT the 'vers' resource -- it allows you to specify the library (code-fragment) version information. The "Fragment Name" should be the shared-library-name excluding version-number, trademark symbols and other frills. Call it "PythonCore". "Current Version" (a single number) is the version of this library... say, "200" "Old Definition" (a single number) is the oldest supported lib-definition supported by this library. If this library is incompatible with Python 1.x, then use the same number "200". "Old Implementation" (a single number) is the oldest support implementation supported by this library. If this library is incompatible with Python 1.x, then use the sane number "200". If you're building a PythonCore 1.5.2 shared library, and it is _compatible_ with applications that were built against a hypothetical PythonCore 1.4 and later, then your PPC PEF info would be: "Fragment Name" == "PythonCore". "Current Version" == "152" "Old Definition" == "140" "Old Implementation" == "140" The hypothetical 1.4.0 PythonCore could also live in the extensions folder with the 1.5.2 PythonCore and the 2.0 PythonCore. Obviously the file names would have to be different. Since the file names are _not_ used by run-time linking, they can be anything, perhaps "Python Core 1.5.2", "PythonCore 1.4.0" and "PythonCore2". Apps built against 2.0 would runtime-link with the 2.0 library because that is the only one it is version-compatible with. Apps built against 1.5.2 would runtime-link with the 1.5.2 PythonCore, because the 2.0 PythonCore doesn't have version-compatbility, but the 1.5.2 PythonCore does. Apps built against 1.4.0 would runtime-link with 1.5.2 PythonCore, because it is more recent, but its version info claims compatibility with 1.4.0.

1 0

clearing the output window in code?
by tom smith Oct. 13, 2000

Oct. 13, 2000

hi because at the moment I'm dealing with big blocks of text, I'd like to be able to clear the output window before splurging my stuff at it... I tried, import PyConsole PyConsole.PyConsole.clearbuffer() ..but it needs a given instance of PyConsole...anyone know which class I could request this from, thanks tom

1 0

Re: [Pythonmac-SIG] Python on on a second drive
by Jack Jansen Oct. 13, 2000

Oct. 13, 2000

> It sounds as if the PythonCore alias points to something that isn't > "extension-like". In that case, perhaps you could provide an alternate but > well known location, such as > ...:System Folder:Preferences:MacPython:PythonCore (probably for post 2.0). Correct. But: putting it somewhere else than in Extensions isn't going to work (as far as I know), because Extensions is the only place that is searched for libraries. Let me quickly explain the reason for putting the alias there in the first place. Maybe someone here has a bright idea for organizing things differently so we don't need it. PythonInterpreter (and the Applet main program code, which is actually the same code) is a tiny executable which is linked against the PythonCore shared library. The code is also little more than a single subroutine call (to the "real" main program, which lives in PythonCore). We want PythonInterpreter to be tiny, because it will be included in each and every applet you have. The reason to have an alias to PythonCore in Extensions is that this allows applets to live anywhere on your disk. When you use a shared library the operating system searches for that shared library in two places: the application folder (i.e. the folder from where you double-clicked the applet) and the Extensions folder. The reason to have an _alias_ there (as opposed to the real PythonCore library) is that this is about the only way that you can have two Python installations on the same disk. Because the application folder is searched before the Extensions folder I can have both 1.5.2 and 2.0 on my machine. Whenever I run PythonInterpreter from the 1.5.2 folder it'll pick up the 1.5.2 PythonCore from that folder. Whenever I run PythonInterpreter from the 2.0 folder it'll pick up the 2.0 PythonCore from that folder. Whenver I run an applet that is in neither folder it'll go to the extensions folder and use the PythonCore from there (which will be whichever one was installed last, I think). -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen(a)oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.oratrix.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm

1 0

Re: [Pythonmac-SIG] Python on on a second drive
by JoanCarles p Casasín Oct. 13, 2000

Oct. 13, 2000

At 13/10/00 16:07 Jack Jansen wrote: >> I've been working with Python (though not hardly) in a second drive for >> quite time and never happened something like that. The only strange thing >> that happened and happens is that with my last machine (G4, with MacOS >> 9.0.4) I've to launch 'Configure Python' each session I want to work with >> an app with Python embedded. Otherwise it can't find "PythonCore". This >> was reported by me (and some other guy) to the list, but we could never >> have other solution than having 'Configure Python' as a StartUp Item... > >Ah... Now we're getting somewhere! At least: we're getting somewhere with >your >problem. My guess is that because the PythonCore alias points to another >disk, >and that disk is not mounted yet when MacOS starts looking for INITs in the >Extension folder it will somehow break the alias (probably while trying to >resolve it). THAT'S IT! I made a rough arrangement but worked. I've copied the PythonCore extension to my startup disk (from the second drive with all the Python stuff). Made an alias from it, renamed to "PythonCore 1.5.2c1", put it in the extensions folder and now (after, of course, restart) the application with Python embedded launches with no problems. Great! -> jc, tw®

1 0

Re: [Pythonmac-SIG] Python on on a second drive
by Jack Jansen Oct. 13, 2000

Oct. 13, 2000

> I've been working with Python (though not hardly) in a second drive for > quite time and never happened something like that. The only strange thing > that happened and happens is that with my last machine (G4, with MacOS > 9.0.4) I've to launch 'Configure Python' each session I want to work with > an app with Python embedded. Otherwise it can't find "PythonCore". This > was reported by me (and some other guy) to the list, but we could never > have other solution than having 'Configure Python' as a StartUp Item... Ah... Now we're getting somewhere! At least: we're getting somewhere with your problem. My guess is that because the PythonCore alias points to another disk, and that disk is not mounted yet when MacOS starts looking for INITs in the Extension folder it will somehow break the alias (probably while trying to resolve it). > Now I've tried to set the (finder) flag to "File has no INIT" (with > ResEdit), once restarted the same happened, and both flags (No init, and > inited) were checked in the alias file. I don't know if this is what you > meant. I'm off of being an expert. Hmm, yet another good idea out the window. Does anyone else know of MacOS problems with aliases in the Extensions folder? I do notice that PythonCore is the only alias I have in the extension folder on my machine, so maybe it isn't a good idea to have aliases there in the first place? -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen(a)oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.oratrix.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm

2 1

Re: greyed dialog
by tom smith Oct. 13, 2000

Oct. 13, 2000

on 13/10/00 11:59 am, Francois Granger at fgranger(a)altern.org wrote: > I clicks "Choose". The > windows of EditPython Prefs is grayed and I can't click OK. Up to now the > only way arount is "cmd-opt-esc". I get this too. I suspect Navigation Services... Anyone else got CGISlave to work? tom

1 0

Re: [Pythonmac-SIG] Python on on a second drive
by Jack Jansen Oct. 13, 2000

Oct. 13, 2000

> I have another issue. If I launch EditPythonPref and I click on set > $(PYTHON) home folder. I select the folder I want. I clicks "Choose". The > windows of EditPython Prefs is grayed and I can't click OK. Up to now the > only way arount is "cmd-opt-esc". Ah yes, I ran into this problem in another situation just before I went on holiday. Now if only I can remember what the solution was again.... :-) -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen(a)oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.oratrix.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm

1 0

Re: [Pythonmac-SIG] Python on on a second drive
by JoanCarles p Casasín Oct. 13, 2000

Oct. 13, 2000

At 12/10/00 22:27 Jack Jansen wrote: >There's a bug report on the sourceforge site that having Python on a >second drive causes problems with warm restarts (they don't proceed >past the happy mac state). Actually the problem may be only with >removable drives, the bug report isn't very clear, and it is anonymous >so I can't ask the original submitter. > >The submitter seems to think that the problem is with PythonCore being >an alias to an external drive. I can hardly imagine this, but I can't >test it as I don't have a second drive.If someone could give this a >try that would be helpful. Also, if it indeed turns out to be a >problem i think a workaround may be to set the "File has no INIT" >flags on the alias file, so if that could be tested too I'd be very >happy... I've been working with Python (though not hardly) in a second drive for quite time and never happened something like that. The only strange thing that happened and happens is that with my last machine (G4, with MacOS 9.0.4) I've to launch 'Configure Python' each session I want to work with an app with Python embedded. Otherwise it can't find "PythonCore". This was reported by me (and some other guy) to the list, but we could never have other solution than having 'Configure Python' as a StartUp Item... Now I've tried to set the (finder) flag to "File has no INIT" (with ResEdit), once restarted the same happened, and both flags (No init, and inited) were checked in the alias file. I don't know if this is what you meant. I'm off of being an expert. But *never* had the problem with the "happy mac" locked and always (as far as I remember) had Python in a second drive. Hope this helps, at least a bit. Cheers, -> jc, tw®

1 0

Python on on a second drive
by Jack Jansen Oct. 13, 2000

Oct. 13, 2000

There's a bug report on the sourceforge site that having Python on a second drive causes problems with warm restarts (they don't proceed past the happy mac state). Actually the problem may be only with removable drives, the bug report isn't very clear, and it is anonymous so I can't ask the original submitter. The submitter seems to think that the problem is with PythonCore being an alias to an external drive. I can hardly imagine this, but I can't test it as I don't have a second drive.If someone could give this a try that would be helpful. Also, if it indeed turns out to be a problem i think a workaround may be to set the "File has no INIT" flags on the alias file, so if that could be tested too I'd be very happy... -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen(a)oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.oratrix.nl/~jack | ++++ see http://www.xs4all.nl/~tank/ ++++

2 1