On Tue, 27 Feb 2001, Tim Peters wrote:

I don't like the new MatchFilename, because it triggers on *all* platforms that #define HAVE_DIRENT_H.

I mentioned this when I originally submitted the patch. The intent was that it be *able* to compile on any unix-like platform -- in particular, I was thinking LinuxPPC was the other case I could think of where someone might want to use a HFS+ filesystem - but that Darwin/MacOSX was likely to be the only system in which that was the default.

Anyone, doesn't that trigger on straight Linux systems too (all I know is that it's part of the Single UNIX Specification)?

Yes. Barry added the _DIRENT_HAVE_D_NAMELINE to handle a difference in the linux dirent structs. ( I'm not sure if he caught my initial statement of intent either, but then the discussion veered into whether the patch should have been accepted at all, and then into the discussion of a general solution... ) I'm not happy with the ineffeciency either, but, as I noted, I didn't expect that it would be enabled by default elsewhere when I submitted it. ( And my goal for OSX was just to have a version that builds and doesn't crash much, so searching for a more effecient solution was going to be the next project. )

Would rather dump MatchFilename and rewrite in terms of the old check_case (which should run much quicker, and already comes in several appropriate platform-aware versions -- and I clearly minimize the chance of breakage if I stick to that time-tested code).

The reason I started from scratch, you might recall, was that before I understood that the Windows semantics was intended to be different, I tried adding a Mac version of check_case, and it didn't do what I wanted. But that wasn't a problem with any of the existing check_case functions, but was due to how check_case was used.

Steven, there is a "#ifdef macintosh" version of check_case already. Will that or won't that work correctly on your variant of Mac? If not, would you please supply a version that does (along with the #ifdef'ery needed to recognize your Mac variant)?

One problem is that I'm aiming for a version that would work on both the open source Darwin distribution ( which is mach + BSD + some Apple extensions: Objective-C, CoreFoundation, Frameworks, ... but not most of the macosx Carbon and Cocoa libraries. ) and the full MacOSX. Thus the reason for a unix only implementation -- the info may be more easily available via MacOS FSSpec's but that's not available on vanilla Darwin. ( And I can't, for the life of me, thing of an effecient unix implementation -- UNIX file system API's + HFS+ filesystem semantics may be an unfortunate mixture! ) In other words: I can rename the current version to check_case and fix the args to match. (Although, I recall that the args to check_case were rather more awkward to handle, but I'll have to look again. ) It also probably shouldn't be "#ifdef macintosh" either, but that's a thread in itself!

Steven and Jack, does getenv() work on both your flavors of Mac? I want to make PYTHONCASEOK work for you too.

getenv() works on OSX (it's the BSD unix implementation). ( I *think* that Jack has the MacPython get the variables from Pythoprefs file settings. ) -- Steve Majewski

On Tue, 27 Feb 2001, Tim Peters wrote:

Please just solve the problem for the platforms you're actually running on -- case-insensitive filesystems are not "Unix only" in any meaningful sense of that phrase, and each not-really-Unix platform is likely to have its own stupid gimmicks for worming around this problem anyway. For example, Cygwin defers to the Windows API. Great! That solves the problem there. Generalization is premature.

This isn't an attempt at abstract theorizing: I'm running Darwin with and without MacOSX on top, as well as MkLinux, LinuxPPC, and of course, various versions of "Classic" MacOS on various machines. I would gladly drop the others for MacOSX, but OSX won't run on all of the older machines. I'm hoping those machines will get replaced before I actually have to support all of those flavors, so I'm not trying to bend over backwards to be portable, but I'm also trying not to shoot myself in the foot by being overly un-general! It's not, for me, being any more premature than you wondering if the VMS users will scream at the changes. ( Although, in both cases, I think it's reasonable to say: "I thought about it -- now here's what we're going to do anyway!" I suspect that folks running Darwin on Intel are using UFS and don't want the overhead either, but I'm not even trying to generalize to them yet! )

...

In other words: I can rename the current version to check_case and fix the args to match. (Although, I recall that the args to check_case were rather more awkward to handle, but I'll have to look again. )

Good! I'm not going to wait for that, though. I desperately need a nap, but when I get up I'll check in changes that should be sufficient for the Windows and Cygwin parts of this, without regressing on other platforms. We'll then have to figure out whatever #ifdef'ery is needed for your platform(s).

__MACH__ is predefined, meaning mach system calls are supported, and __APPLE__ is predefined -- I think it means it's Apple's compiler. So: #if defined(__MACH__) && defined(__APPLE__) ought to uniquely identify Darwin, at least until Apple does another OS. ( Maybe it would be cleaner to have config add -DDarwin switches -- or if you want to get general -D$MACHDEP -- except that I don't think all the values of MACHDEP will parse as symbols. ) -- Steve Majewski

Tim, On Tue, Feb 27, 2001 at 02:27:12PM -0500, Tim Peters wrote:

Jason, I *assume* that the existing "#if defined(MS_WIN32) || defined(__CYGWIN__)" version of check_case works already for you. Scream if that's wrong.

I guess it depends on what you mean by "works." When I submitted my patch to enable case-sensitive imports for Cygwin, I mistakenly thought that I was solving import problems such as "import TERMIOS, termios". Unfortunately, I was only enabling the (old) Win32 "Case mismatch for module name foo" code for Cygwin too. Subsequently, there have been changes to Cygwin gcc that may make it difficult (i.e., require non-standard -I options) to find Win32 header files like "windows.h". So from an ease of building point of view, it would be better to stick with POSIX calls and avoid direct Win32 ones. Unfortunately, from an efficiency point of view, it sounds like this is unavoidable. I would like to test your patch with both Cygwin gcc 2.95.2-6 (i.e., Win32 friendly) and 2.95.2-7 (i.e., Unix bigot). Please let me know when it's ready. Thanks, Jason -- Jason Tishler Director, Software Engineering Phone: +1 (732) 264-8770 x235 Dot Hill Systems Corp. Fax: +1 (732) 264-8798 82 Bethany Road, Suite 7 Email: Jason.Tishler@dothill.com Hazlet, NJ 07730 USA WWW: http://www.dothill.com

[Tim]

...

Jason, I *assume* that the existing "#if defined(MS_WIN32) || defined(__CYGWIN__)" version of check_case works already for you. Scream if that's wrong.

[Jason]

I guess it depends on what you mean by "works."

I meant that independent of errors you don't want to see, and independent of the allcaps8x3 silliness, check_case returns 1 if there's a case-sensitive match and 0 if not.

When I submitted my patch to enable case-sensitive imports for Cygwin, I mistakenly thought that I was solving import problems such as "import TERMIOS, termios". Unfortunately, I was only enabling the (old) Win32 "Case mismatch for module name foo" code for Cygwin too.

Then if you succeeded in enabling that, "it works" in the sense I meant. My intent is to stop the errors, take away the allcaps8x3 stuff, and change the *calling* code to just keep going when check_case returns 0.

Subsequently, there have been changes to Cygwin gcc that may make it difficult (i.e., require non-standard -I options) to find Win32 header files like "windows.h". So from an ease of building point of view, it would be better to stick with POSIX calls and avoid direct Win32 ones. Unfortunately, from an efficiency point of view, it sounds like this is unavoidable.

I would like to test your patch with both Cygwin gcc 2.95.2-6 (i.e., Win32 friendly) and 2.95.2-7 (i.e., Unix bigot). Please let me know when it's ready.

Not terribly long after I get to stop writing email <0.9 wink>. But since the only platform I can test here is plain Windows, and Cygwin and sundry Mac variations appear to be moving targets, once it works on Windows I'm just going to check it in. You and Steven will then have to figure out what you need to do on your platforms. OK by me if you two recreate the HAVE_DIRENT_H stuff, but (a) not if Linux takes that path too; and, (b) if Cygwin ends up using that, please get rid of the Cygwin-specific tricks in the plain Windows case (this module is already one of the hardest to maintain, and having random pieces of #ifdef'ed code in it that will never be used hurts).

Here's the checkin comment for rev 2.163 of import.c: """ Implement PEP 235: Import on Case-Insensitive Platforms. http://python.sourceforge.net/peps/pep-0235.html Renamed check_case to case_ok. Substantial code rearrangement to get this stuff in one place in the file. Innermost loop of find_module() now much simpler and #ifdef-free, and I want to keep it that way (it's bad enough that the innermost loop is itself still in an #ifdef!). Windows semantics tested and are fine. Jason, Cygwin *should* be fine if and only if what you did for check_case() before still "works". Jack, the semantics on your flavor of Mac have definitely changed (see the PEP), and need to be tested. The intent is that your flavor of Mac now work the same as everything else in the "lower left" box, including respecting PYTHONCASEOK. There is a non-zero chance that I already changed the "#ifdef macintosh" code correctly to achieve that. Steven, sorry, you did the most work here so far but you got screwed the worst. Happy to work with you on repairing it, but I don't understand anything about all your Mac variants and don't have time to learn before the beta. We need to add another branch (or two, three, ...?) inside case_ok for you. But we should not need to change anything else. """ Someone please check Linux etc too, although everything that doesn't match one of these #ifdef's: #if defined(MS_WIN32) || defined(__CYGWIN__) #elif defined(DJGPP) #elif defined(macintosh) *should* act as if the platform filesystem were case-sensitive (i.e., that if fopen() succeeds, the case must match already and so there's no need for any more work to check that). Jason, if Cygwin is broken, please coordinate with Steven since you two appear to have similar problems then. [Steven]

__MACH__ is predefined, meaning mach system calls are supported, and __APPLE__ is predefined -- I think it means it's Apple's compiler. So:

#if defined(__MACH__) && defined(__APPLE__)

ought to uniquely identify Darwin, at least until Apple does another OS.

( Maybe it would be cleaner to have config add -DDarwin switches -- or if you want to get general -D$MACHDEP -- except that I don't think all the values of MACHDEP will parse as symbols. )

This is up to you. I'm sorry to have broken your old code, but Barry should not have accepted it to begin with <wink>. Speaking of which, [Barry]

SDM> Yes. Barry added the _DIRENT_HAVE_D_NAMELINE to handle a SDM> difference in the linux dirent structs.

Actually, my Linux distro's dirent.h has almost the same test on _DIRENT_HAVE_D_NAMLEN (sic) -- which looking again now at import.c it's obvious I misspelled it!

Tim, if you clean this code up and decide to continue to use the d_namlen slot, please fix the macro test.

For now, I didn't change anything in the MatchFilename function, but put the entire thing in an "#if 0" block with an "XXX" comment, to make it easy for Steven and/or Jason to get at that source if one or both decide their platforms still need something like that. If they do, I'll double-check that this #define is spelled correctly when they check in their changes; else I'll delete that block before the release. Aren't release crunches great? Afraid they're infectious <0.5 wink>.

Tim, On Tue, Feb 27, 2001 at 11:29:33PM -0500, Tim Peters wrote:

Not terribly long after I get to stop writing email <0.9 wink>. But since the only platform I can test here is plain Windows, and Cygwin and sundry Mac variations appear to be moving targets, once it works on Windows I'm just going to check it in. You and Steven will then have to figure out what you need to do on your platforms.

I tested your changes on Cygwin and they work correctly. Thanks very much. Unfortunately, my concerns about building due to your implementation using direct Win32 APIs were realized. This delayed my response. The current Python CVS stills builds OOTB (with the exception of termios) with the current Cygwin gcc (i.e., 2.95.2-6). However, using the next Cygwin gcc (i.e., 2.95.2-8 or later) will require one to configure with: CC='gcc -mwin32' configure ... and the following minor patch be accepted: http://sourceforge.net/tracker/index.php?func=detail&aid=404928&group_id=5470&atid=305470 Thanks, Jason -- Jason Tishler Director, Software Engineering Phone: +1 (732) 264-8770 x235 Dot Hill Systems Corp. Fax: +1 (732) 264-8798 82 Bethany Road, Suite 7 Email: Jason.Tishler@dothill.com Hazlet, NJ 07730 USA WWW: http://www.dothill.com

[Jason]

I tested your changes on Cygwin and they work correctly. Thanks very much.

Good! I guess that just leaves poor Steven hanging (although I've got ~200 emails I haven't gotten to yet, so maybe he's already pulled himself up).

Unfortunately, my concerns about building due to your implementation using direct Win32 APIs were realized. This delayed my response.

The current Python CVS stills builds OOTB (with the exception of termios) with the current Cygwin gcc (i.e., 2.95.2-6). However, using the next Cygwin gcc (i.e., 2.95.2-8 or later) will require one to configure with:

CC='gcc -mwin32' configure ...

and the following minor patch be accepted:

http://sourceforge.net/tracker/index.php?func=detail&aid=404928&gro up_id=5470&atid=305470

I checked that patch in already, about 15 minutes after you uploaded it. Is this service, or what?! <wink> [Guido]

That patch seems fine -- except that I'd like /F to have a quick look since it changes _sre.c.

Too late and no need. What Jason did to _sre.c is *undo* some Cygwin special-casing; /F will like that. It's trivial anyway. Jason, about this: However, using the next Cygwin gcc (i.e., 2.95.2-8 or later) will require one to configure with: CC='gcc -mwin32' configure ... How can we make that info *useful* to people? The target audience for the Cygwin port probably doesn't search Python-Dev or the Python patches database. So it would be good if you thought about uploading an informational patch to README and Misc/NEWS briefly telling Cygwin folks what they need to know. If you do, I'll look for it and check it in.

Tim, On Wed, Feb 28, 2001 at 12:36:45PM -0500, Tim Peters wrote:

I checked that patch in already, about 15 minutes after you uploaded it. Is this service, or what?! <wink>

Yes! Thanks again.

[Guido]

...

That patch seems fine -- except that I'd like /F to have a quick look since it changes _sre.c.

Too late and no need. What Jason did to _sre.c is *undo* some Cygwin special-casing;

Not really -- I was trying to get rid of WIN32 #ifdefs. My solution was to attempt to reuse the DL_EXPORT macro. Now I realize that I should have done the following instead: #if defined(WIN32) || defined(__CYGWIN__) __declspec(dllexport) #endif

/F will like that.

Apparently not.

It's trivial anyway.

I thought so too.

Jason, about this:

However, using the next Cygwin gcc (i.e., 2.95.2-8 or later) will require one to configure with:

CC='gcc -mwin32' configure ...

How can we make that info *useful* to people?

I have posted to the Cygwin mailing list and C.L.P regarding my original 2.0 patches. I have also continue to post to Cygwin regarding 2.1a1 and 2.1a2. I intended to do likewise for 2.1b1, etc.

The target audience for the Cygwin port probably doesn't search Python-Dev or the Python patches database.

Agreed -- the above was only offered to the curious Python-Dev person and not for archival purposes.

So it would be good if you thought about uploading an informational patch to README and Misc/NEWS briefly telling Cygwin folks what they need to know. If you do, I'll look for it and check it in.

I will submit a patch to README to add a Cygwin section to "Platform specific notes". Unfortunately, I don't think that I can squeeze it in by 2.1b1. If not, then I will submit it for the next release (2.1b2 or 2.1 final). I also don't mind waiting for the Cygwin gcc stuff to settle down too. I know...excuses, excuses... Thanks, Jason -- Jason Tishler Director, Software Engineering Phone: +1 (732) 264-8770 x235 Dot Hill Systems Corp. Fax: +1 (732) 264-8798 82 Bethany Road, Suite 7 Email: Jason.Tishler@dothill.com Hazlet, NJ 07730 USA WWW: http://www.dothill.com

Tim, On Wed, Feb 28, 2001 at 05:21:02PM -0500, Tim Peters wrote:

And thank you for your Cygwin work --

Your welcome -- I appreciate the willingness of the core Python team to consider Cygwin related patches.

someday I hope to use Cygwin for more than just running "patch" on this box <sigh> ...

Be careful! First, you may use grep occasionally. Next, you may find yourself writing shell scripts. Before you know it, you have crossed over to the Unix side. You have been warned! :,) Thanks, Jason -- Jason Tishler Director, Software Engineering Phone: +1 (732) 264-8770 x235 Dot Hill Systems Corp. Fax: +1 (732) 264-8798 82 Bethany Road, Suite 7 Email: Jason.Tishler@dothill.com Hazlet, NJ 07730 USA WWW: http://www.dothill.com

Tim, On Wed, Feb 28, 2001 at 03:17:28PM -0500, Jason Tishler wrote:

On Wed, Feb 28, 2001 at 12:36:45PM -0500, Tim Peters wrote:

...

Jason, about this:

However, using the next Cygwin gcc (i.e., 2.95.2-8 or later) will require one to configure with:

CC='gcc -mwin32' configure ...

How can we make that info *useful* to people?

I have posted to the Cygwin mailing list and C.L.P regarding my original 2.0 patches. I have also continue to post to Cygwin regarding 2.1a1 and 2.1a2. I intended to do likewise for 2.1b1, etc.

...

The target audience for the Cygwin port probably doesn't search Python-Dev or the Python patches database.

Agreed -- the above was only offered to the curious Python-Dev person and not for archival purposes.

...

So it would be good if you thought about uploading an informational patch to README and Misc/NEWS briefly telling Cygwin folks what they need to know. If you do, I'll look for it and check it in.

I will submit a patch to README to add a Cygwin section to "Platform specific notes". Unfortunately, I don't think that I can squeeze it in by 2.1b1. If not, then I will submit it for the next release (2.1b2 or 2.1 final). I also don't mind waiting for the Cygwin gcc stuff to settle down too. I know...excuses, excuses...

As promised: http://sourceforge.net/tracker/index.php?func=detail&aid=413750&group_id=5470&atid=305470 Note that the following goofiness: CC='gcc -mwin32' configure ... is no longer needed. Jason -- Jason Tishler Director, Software Engineering Phone: +1 (732) 264-8770 x235 Dot Hill Systems Corp. Fax: +1 (732) 264-8798 82 Bethany Road, Suite 7 Email: Jason.Tishler@dothill.com Hazlet, NJ 07730 USA WWW: http://www.dothill.com