Re: [Python-Dev] python/trunk/Lib/test/test_urllib.py (for ftpwrapper)
ocean wrote: > After I did this change, most errors were gone. > > Index: Lib/urllib.py > === > --- Lib/urllib.py (revision 55584) > +++ Lib/urllib.py (working copy) > @@ -833,7 +833,7 @@ > self.busy = 0 > self.ftp = ftplib.FTP() > self.ftp.connect(self.host, self.port, self.timeout) > -self.ftp.login(self.user, self.passwd) > +#self.ftp.login(self.user, self.passwd) > for dir in self.dirs: > self.ftp.cwd(dir) > > I don't know, but probably 'login' on Win2000 is problamatic. But you can *not* do this, you're trimming functionality from this class. The test that I left commented out in test_urllib.py just tries to simulate the first two FTP server answers, one saying "hello", and the other asking for the user. This is just to test ftpwrapper in its more basic first steps. The simulation goes ok in linux, but not in windows. But the problem is clearly in the tests, even if I can not find it, not in the urllib module. Regards, -- . Facundo . Blog: http://www.taniquetil.com.ar/plog/ PyAr: http://www.python.org/ar/ ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Adventures with x64, VS7 and VS8 on Windows
>> It doesn't need to, and reluctance is not wrt. to the proposed new >> layout, but wrt. changing the current one. Tons of infrastructure >> depends on the files having exactly the names that they have now, >> and being located in exactly the locations where they are currently >> located. Any change to that, whatever minor, will cause problems >> to some people. > > Just to be absolutely clear: You are talking about the build environment, > right? Because I am not proposing to change any layout of the > installed Python (wherever that may be :) Correct. > I am baffled about why the build environment's layout matters, > but once an .msi install can place the binaries in any > old place it wants. The build structure doesn't have to > reflect the final installed structure at all. No. But still, people like to be able to "run" Python out of a source check-out. This has been supported for a long time, and more and more stuff was added to support it. For examples within Python itself, see the support in distutils, getpathp.c, PCbuild/rt.bat, and Tools/buildbot/*.bat. Reportedly (by Mark), building Mozilla (the web browser) also "knows" about PCbuild. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Adventures with x64, VS7 and VS8 on Windows
> Development tools used on windows already have to cope with this. > Spaces are not going away, so why not bite the bullet and deal > with them? Moving forward sometimes means crossing rivers. But in a safe path, step by step. People continue to report problems with spaces in file names, even though many of them have been solved also. > As for Vista issues, I'll gather more data before making any more > claims, but I think that it is important that we play by the rules > here. I completely disagree. It is important that it "works", not that we play by the rules. > Just imagine the a school teacher who in good faith wants to introduce > his pupils to the wonderful programming language of Python, but > when he installs it, all kinds of scary looking warnings drive him off. > Vista is, like it or not, going to be very prevalent. If we want python > to be easily accessible to the masses, we mustn't take an elitist > attitude or else risk scaring people off. I'm completely in favor of fixing actual bugs. However, I'm not aware of any (related to Vista). That it is not logo compliant is *not* a bug. Python hasn't been logo compliant for more than a decade now (the "install to Program Files" is not a new requirement, but existed since Win95). Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Adventures with x64, VS7 and VS8 on Windows
> Supporting both kinds (country and western) on the same machine might be > helpful > to people for this very reason. A lot of legacy modules are only avaible > in 32 bit mode. But people may want to do contemporary development using the > new 64 bit mode. Of course, people who really want that can install both versions simultaneously today. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Unable to commit
> Odd... the call worked here (SVN 1.4.3). Which version is the server using? 1.1. Subversion did a grand renaming at some point. I fixed most of the functions when deploying the script, but apparently missed some. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Distutils] Adventures with x64, VS7 and VS8 on Windows
> From: Jamie Kirkpatrick [mailto:[EMAIL PROTECTED] > Sent: Wednesday, 23 May 2007 5:16 AM > I have a set of extensions that use SWIG to wrap my own C++ library. This library, on a > day-to-day basis is built against VS8 since the rest of our product suite is. Right now > I have no way to work with this code using VS8 since the standard distribution is built > against VS7 which uses a different CRT. This is an absolute nightmare in practice since > I currently have to maintain VS7 projects in parallel with the standard VS8 ones simply > so that I can run and test my python code. If you are brave and willing to ensure your module doesn't voilate certain constraints (such as never passing a CRT 'concept' - such as a file handle or memory block to be free'd) across mismatched CRT boundaries, you may find that you can happily load your VS8 built pronect with VS7 - but yes, your general point is valid but beyond the scope of this discussion. A separate discussion on making Python "crt agnostic" is almost certainly worthwhile though, but not directly related to this current discussion. > I've downloaded the Python source and had a look at building up my own distributions for each case > (ideally there would be an easy way to separate out Release / Debug products as well as the > VS8 / VS7 variants, and I guess potentially for those cross-compiling we'd need to go a step > further and do this per arch as well. Anyway, this isn't how it works at the moment, but I'm > still searching for a way to be able to work on the python code in VS8. Building using the > current projects I seem to get everything in the PCBuild8 / PCBuild dirs. How can I work with > what is build? This is *exactly* the point of this thread, and what we are trying to resolve. In the short term, we have agreed a change to PCBuild8\build.bat that copies the build files into PCBuild is a solution that should "work", where "work" is defined as "allow a source tree built with VS8 to operate in the same way, from the POV of building extensions, as one built with VS8." My primary issue with this is solved by the change to the .bat file, but we welcome all feedback from people who believe this is not ideal. I've agreement from Kristjan on the specific change to that .bat file, I'm just yet to check it in (but it literally just copies everything from the PVBuild8 target dir into the PCBuild dir after checking the expected dirs do indeed exist) > Is there a shell script to build a final distribution tree? If not, is there a simple > way to build an MSI similar to the one found on the Python.org site for the official > releases but using the PCBuild8 stuff? I believe not. In most cases, people who build from source on Windows will run directly from that source tree, rather than attempting the intermediate step of creating a .msi and installing it. > If not how do you recommend getting myself to a state where I have at least a feature complete > distribution build against VS8? I'm happy with a one time build that I can just install into > my source tree and upload to the SCM. I'd suggest that once I check the .bat change in, you build the PCBuild8 directory via that .bat file, then continue to use the 'PCBuild' directory as it it were a VC7 build. Cheers, Mark ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] whitespace normalization pre-commit hook is giving me grief
Brett Cannon schrieb: > Unfortunately the pre-commit hook > does not specify what line a change was made on so I have no clue where > it is failing (maybe this should be added?). It creates a reindent.Reindenter on the new contents, then invokes .run() on it, and complains if that returns true. If you can come up with a patch to reindent that makes it report more detailed errors, please post it, and I'll try to merge it into the hook script. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Distutils] Adventures with x64, VS7 and VS8 on Windows
>> Is there a shell script to build a final distribution tree? If >> not, is there a simple way to build an MSI similar to the one found >> on the Python.org site for the official releases but using the >> PCBuild8 stuff? > > I believe not. It's actually not that difficult. You just have to run Tools/msi/msi.py, with a python interpreter that support PythonCOM (i.e. has PythonWin installed). Replacing all occurrences of PC[Bb]uild with PCbuild8 should do the trick. This will give you a "snapshot" MSI, i.e. one that you can install along with a regularly-release Python interpreter. If you put a config.py with testpackage=True into the msi directory, it will register the extensions .px, .pxw, .pxo, .pxc (rather than .py*), and overwrite the registry at Software\xPython (rather than Software\Python), so that the package shouldn't interfere at all with a regular installation. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Build problems with sqlite on OSX
Darrin Thompson schrieb: > First of all 1000 apologies if this is the wrong list. Please redirect > me if necessary. The list is right, but the question is slightly wrong: > Can someone advise as to the correct configure arguments for sqlite or > something else I might be missing? The question for python-dev is "how can I debug that further, and where should I submit a patch" :-) > (gdb) info threads > * 1 process 18968 local thread 0x1003 0x900e41d1 in strtol_l () > (gdb) bt > #0 0x900e41d1 in strtol_l () > #1 0x900160a5 in atoi () > #2 0x9406fd80 in sqlite3InitCallback () Can you figure out what parameter is being passed to atoi() here? Go up (u) a few stack frames, list (l) the source, and print (p) the variables being passed to atoi(). I'm puzzled that it doesn't display source code information - so one possible cause is that you pick up the wrong sqlite3InitCallback (i.e. the one that came with OSX, instead of the one you built yourself). Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Unable to commit
> I don't know. After some Googling, I found that the call might need to be: > > if fs.node_prop(txn_root, path, SVN_PROP_MIME_TYPE, > 'svn:special') == '*': continue No. Instead, the missing argument was the apr_pool_t parameter, which was mandatory earlier, and is optional in current releases. The requirement to pass an apr_pool_t is answered by putting the entire logic into a single callback function that expects a pool, and then passing the pool to all API functions as the last parameter. The callback itself is passed to run_app. I have fixed the hook, and tested that it still checks regular .py files, but skips them if they are svn:special. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Build problems with sqlite on OSX
One other thing to check is to ensure that sqlite was compiled with -fno-strict-aliasing. I know there was a strange problem on one of the buildbots due to this flag not being present. I have no idea if that could be your problem here though. n -- On 5/28/07, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote: > Darrin Thompson schrieb: > > First of all 1000 apologies if this is the wrong list. Please redirect > > me if necessary. > > The list is right, but the question is slightly wrong: > > > Can someone advise as to the correct configure arguments for sqlite or > > something else I might be missing? > > The question for python-dev is "how can I debug that further, and where > should I submit a patch" :-) > > > (gdb) info threads > > * 1 process 18968 local thread 0x1003 0x900e41d1 in strtol_l () > > (gdb) bt > > #0 0x900e41d1 in strtol_l () > > #1 0x900160a5 in atoi () > > #2 0x9406fd80 in sqlite3InitCallback () > > Can you figure out what parameter is being passed to atoi() here? > Go up (u) a few stack frames, list (l) the source, and print (p) > the variables being passed to atoi(). I'm puzzled that it doesn't > display source code information - so one possible cause is that > you pick up the wrong sqlite3InitCallback (i.e. the one that > came with OSX, instead of the one you built yourself). > > Regards, > Martin > ___ > Python-Dev mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/nnorwitz%40gmail.com > ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Unable to commit
Martin v. Löwis schrieb: >> Odd... the call worked here (SVN 1.4.3). Which version is the server using? > > 1.1. Subversion did a grand renaming at some point. I fixed most of the > functions when deploying the script, but apparently missed some. Okay. Is an upgrade planned? I've heard that several actions were sped up significantly with later releases. Georg -- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
