On 23-mrt-2006, at 0:31, Andrew Barnert wrote: > Thanks for the quick answers, and it's good to know > that I'm not missing information right in front of my > face.... > > Me: >>> First, what's up with ctypes and other things that >>> need libffi? > > Ronald: >> PyObjC contains a port of libffi to darwin/x86, but > sadly >> enough I didn't pay enough attention in the time > between >> WWDC'05 and the release of OSX/x86. My port of > libffi >> no longer works due to slight changes in the calling >> conventions. I'll be fixing this shortly, and push > those >> upstreams and to ctypes. > > OK, I'll wait.... > > By the way, I think I remember seeing some other > project with a libffi port around the same time (late > summer). Maybe pnet or mono or something related? Are > you sharing changes, or just duplication each other's > work? For that matter, is there anyone maintaining > libffi itself, or is it just one of those many > projects that Redhat abandoned and nobody's picked it > up even though people still use it?
Libffi is part of the GCC source tree. I haven't tried merging my port to darwin/x86 yet because of the general hackishness of it at the time. Now that Apple has an actual release of OSX/x86 I'll clean up my patch :-) IIRC libffi is used in the java part of gcc (which isn't used by Apple) > >>> Next, have the python24-fat changes been ported to > the >>> 2.5 trunk? > >> The changes have not been ported to the 2.5 tree > yet, >> but I intend to do so before the 2.5a1 release. > > OK. I can use a pure-Intel build to play around with > 2.5 changes, but your 2.4 universal for actual > development. > >>> How exactly are you supposed to properly install a >>> framework build? > >> Just install using the pkg? My build script in the >> python24-fat tree does a chmod after installing, but >> that's mostly because its predecessor also did that. > > Yeah, that works, unless I want to try a patch, play > with recent trunk changes, use different configure > switches, install two different 2.4.2 versions in > parallel, etc. > > I guess it's not that big a deal if you have to do > some chmod/chgrp stuff to make frameworkinstall happy, > since anyone who's going to install from source ought > to be able to figure it out. > > What are the actual problems with having a root/wheel > 755 framework directory instead of root/admin 775? I > guess it means you can't install modules to > site-packages out of .pkg files? If it's important, it > would be nice if it were easier to do properly. root/admin 775 makes it easier to install packages when you're an admin user, you can do away with the call to sudo. > > I'm guessing it would help the darwinports and fink > guys out, too. Last I checked, fink wouldn't build > Python at all on Intel, and darwinports wouldn't do a > framework install--but even on PPC, they both ended up > with a root/wheel 755 framework directory. I don't use fink, and use darwinports only for unix-y tools, IMHO neither should have to use framework installs :-) > >>> * test_curses is skipped, even though curses > appears to work >>> * all tests that require networking are skipped, > even though >>> at least some (maybe all) of the relevant > modules work >>> * test_re fails >>> * test_{unicode,unicodedata,codecs} fail >> >> Dunno about these, they should work just fine. I >> haven't tried building the trunk on an intel box yet > though. > > I tested a few more things. So far, all of the skipped > tests that I tried manually worked fine, and I'm not > sure why they're skipped. All of the failed tests that > I've tried actually are broken (like the > u'\u2000'.isspace test I mentioned before). And I > couldn't find bugs filed on any of them. Do people > usually file bugs this early in the dev process? According to buildbot (www.python.org/dev/buildbot/trunk) the trunk shouldn't have any test failures. > > I might be able to figure some of these out; others, > probably not. I know that a Unicode space is supposed > to be a space, but when I disagree with the computer > about how some regexp should be parsed, it's usually > the computer that's right.... > > So if I can't figure out the problems, should I at > least gather the verbose test reports and file bugs? > >>> * test_{aepack,applesingle,macostools} fail >> >> Those are expected to fail, the python24-fat tree >> contains bugfixes for this. > > OK, cool. > Ronald _______________________________________________ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig