[issue34453] ipaddress module accepts some strange IPv6 addresses that it shouldn't
Luke Kenneth Casson Leighton added the comment: that's interesting, michael: it means that all of the IPv6 validators online are wrong, like this one! https://formvalidation.io/guide/validators/ip/ -- ___ Python tracker <https://bugs.python.org/issue34453> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34428] tokenize
Luke Kenneth Casson Leighton added the comment: yep good call terry, not getting any response from the autopep8 developer, and i believe it was down to a loop where the text is being thrown line-by-line at tokenize and it was losing critical state information. so... not a bug in tokenize. -- ___ Python tracker <https://bugs.python.org/issue34428> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34453] ipaddress module accepts some strange IPv6 addresses that it shouldn't
Luke Kenneth Casson Leighton added the comment: hi prudvi: i have absolutely no idea. i am simply running test validators online, which show and confirm that they are correctly INVALID. a google search shows a number of IPv6 validators: https://www.google.co.uk/search?q=ipv6+address+validator i have absolutely no actual knowledge of what constitutes a valid IPv6 address or not, nor know of any "official" resources. all i know is: consensus tends to agree that these two addresses are accepted by the python ipaddress module when they should not. -- ___ Python tracker <https://bugs.python.org/issue34453> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34453] ipaddress module accepts some strange IPv6 addresses that it shouldn't
Luke Kenneth Casson Leighton added the comment: > Hi lkcl, are you working on the fix? I'd like to work on it. hi prudvi, i'm not: i'm simply making people aware that there's an issue that needs to be addressed (pun intended) -- ___ Python tracker <https://bugs.python.org/issue34453> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34453] ipaddress module accepts some strange IPv6 addresses that it shouldn't
New submission from Luke Kenneth Casson Leighton : adding some unit tests to some code being written, searched randomly on the internet for an IPv6 test suite and found one in php *shudder* # https://github.com/gws/ipv6-address-test/blob/master/Tests/Ipv6TestCase.php converted it to python, and was surprised to find that there are two cases which the ipaddress.IPv6Address module accepts, that it should not! attached is a quick-and-dirty hacked together unit test which shows the issue. the full suite may be found here (over 400 ipv6 addresses to test): https://github.com/threefoldtech/jumpscale_core/blob/development_dynamic/tests/jumpscale_test/test10_j_data_types.py -- components: Tests files: ipv6test.py messages: 323843 nosy: lkcl priority: normal severity: normal status: open title: ipaddress module accepts some strange IPv6 addresses that it shouldn't type: behavior versions: Python 3.5, Python 3.6 Added file: https://bugs.python.org/file47757/ipv6test.py ___ Python tracker <https://bugs.python.org/issue34453> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34428] tokenize
Luke Kenneth Casson Leighton added the comment: ahh darn-it, autopep8 is passing in tokens line-by-line, to be parsed one at a time oh and of course it's losing state information that tokenizer critically relies on. i *think* that's what's going on so it's highly unlikely to be a python tokenize bug... can we wait to see what the autopep8 developer says? -- ___ Python tracker <https://bugs.python.org/issue34428> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34428] tokenize
Luke Kenneth Casson Leighton added the comment:
wtf??? neither can i
import io
import tokenize
text = r'''\
(
r"\(")
(
"\(")
'''
string_io = io.StringIO(text)
tokens = list(
tokenize.generate_tokens(string_io.readline)
)
print (tokens)
works perfectly.
ok a i bet you it's something to do with how
string_io.readline works, or something to do with
the format of the text. give me a sec to triage it.
--
___
Python tracker
<https://bugs.python.org/issue34428>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34428] tokenize
Luke Kenneth Casson Leighton added the comment:
regular expressions are not something i am familiar or comfortable
with (never have been: the patterns are too dense). however REMOVING
"Bracket" from the regular expression(s) for PseudoToken "fixes"
the problem.
some debug print statements dropped in at around line 640 of
tokenize.py show that the match on the "working" code
with r"\(") as input gives a start/end/spos/epos that is DIFFERENT
from when the same code is given just "\("
line 'r"\\(")\n'
pos 0 7 r <_sre.SRE_Match object; span=(0, 5), match='r"\\("'>
pseudo start/end 0 5 (2, 0) (2, 5)
vs
line '"\\(")\n'
pos 0 6 " <_sre.SRE_Match object; span=(0, 4), match='"\\("'>
pseudo start/end 0 4 (5, 0) (5, 4)
there *may* be a way to "fix" this by taking out the pattern
matching on Bracket and prioritising everything else.
while pos < max:
pseudomatch = _compile(PseudoToken).match(line, pos)
print ("pos", pos, max, line[pos], pseudomatch)
if pseudomatch:# scan for tokens
start, end = pseudomatch.span(1)
spos, epos, pos = (lnum, start), (lnum, end), end
print ("pseudo start/end", start, end, spos, epos)
if start == end:
continue
Bracket = '[][(){}]'
Special = group(r'\r?\n', r'\.\.\.', r'[:;.,@]')
# REMOVE Bracket
Funny = group(Operator, Special)
PlainToken = group(Number, Funny, String, Name)
Token = Ignore + PlainToken
# First (or only) line of ' or " string.
ContStr = group(StringPrefix + r"'[^\n'\\]*(?:\\.[^\n'\\]*)*" +
group("'", r'\\\r?\n'),
StringPrefix + r'"[^\n"\\]*(?:\\.[^\n"\\]*)*' +
group('"', r'\\\r?\n'))
PseudoExtras = group(r'\\\r?\n|\Z', Comment, Triple)
PseudoToken = Whitespace + group(PseudoExtras, Number, Funny, ContStr, Name)
--
nosy: -serhiy.storchaka
___
Python tracker
<https://bugs.python.org/issue34428>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34428] tokenize
Luke Kenneth Casson Leighton added the comment: python2.7 and 3.5 also has exact same issue. -- versions: +Python 2.7, Python 3.5 ___ Python tracker <https://bugs.python.org/issue34428> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34428] tokenize
Luke Kenneth Casson Leighton added the comment:
these two line also pass (do not throw an exception):
co = re.compile(
r"\(")
the code that fails may be further reduced to the following:
(
"\(")
--
___
Python tracker
<https://bugs.python.org/issue34428>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34428] tokenize
New submission from Luke Kenneth Casson Leighton :
https://github.com/hhatto/autopep8/issues/414
the following two lines of code are not parseable by tokenize.py:
co = re.compile(
"\(")
the combination of:
* being split on two lines
* having a backslash inside quotes
* having a bracket inside quotes
is an edge-case that _tokenize cannot cope with.
--
components: Library (Lib)
messages: 323698
nosy: lkcl
priority: normal
severity: normal
status: open
title: tokenize
type: crash
versions: Python 3.6, Python 3.7
___
Python tracker
<https://bugs.python.org/issue34428>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5051] test_update2 in test_os.py invalid due to os.environ.clear() followed by reliance on environ COMSPEC
Luke Kenneth Casson Leighton added the comment: that's not the correct solution, ned. what that will do is when someone runs a combination of python and MSYS under wine, the test will be skipped incorrectly. thanks to the work that i did back in 2009, wine has now been improved significantly and has been capable of running python correctly for over 3 years now. i use it to do testing of pyjamas-desktop. bottom line: skipping regression tests by making assumptions based solely and exclusively on the platform type is not good news. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5051 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5051] test_update2 in test_os.py invalid due to os.environ.clear() followed by reliance on environ COMSPEC
Luke Kenneth Casson Leighton added the comment: hi ned, well, the situation surrounding the bug-reporting that i was doing at the time was a general campaign of this person is obviously wasting our time because they're developing yet another port/platform, that is obviously a waste of our time, therefore we will shut him down and ban him from the bugtracker and thus generally make our lives easier. so against that background i really wasn't inclined to contribute to the development of python. the argument given for this specific bug [off-list because i had been ordered not to use the bugtracker] was it's not a supported combination therefore obviously it's not a bug. leaving that aside, and assuming that things have moved on from there and that improvements to python and its expansion into areas beyond where it is currently entrenched are welcomed, the arguments given 3 years ago are actually valid... but from a different perspective: the combination of win32 and bash is particularly weird [i.e. borderline] and thus the test is incomplete. so it would be best i feel to consider what the test is trying to achieve: set environment variables, and then execute a command that results in that environment variable being passed and read back with python's popen command. in the POSIX case, the easiest way to do that would involve using /bin/sh - a pretty standard baseline application that can be expected to exist on every POSIX platform under the sun. but the most generic case would actually involve compiling a small c application which read - in c - a standard environment variable - and printf'd it then exited. a quick google search c getenv shows a perfect example: http://msdn.microsoft.com/en-gb/library/aa246422%28v=vs.60%29.aspx so the *ideal* situation i feel would be to use a shortened version of that, with the env variable HELLO printf'd out. if python popen returns world, the test can be deemed to be successful. the less-than-ideal situation would be, rather than to skip the test, to use command.com or cmd.exe under win32 rather than executing /bin/sh... ... but the irony is that even if you did that, you would run into the same bug because the os.environ.clear() destroys the COMSPEC environment variable! soooOoo.. to fix that, you'd need to record the COMSPEC environment variable just before the os.environ.clear() and re-establish it prior to the popen. so it's a tricky one! * the ideal test is to actually compile up some c code. that would however mean shipping a binary with the python distribution as part of the test suite [eek! there must be other solutions...] * the less-than-ideal test is to use a pre-existing application, but then you have to work out, on a per-supported-platform basis, an OS-specific method of echoing an environment variable * the least perfect method is to skip the test entirely on platforms that don't have /bin/sh, but then you have the situation where the regression tests aren't actually doing their job, thus defeating the goal of python being a platform-independent environment because you can't rely on code working across all platforms. tricky one! -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5051 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3871] cross and native build of python for mingw* hosts
Luke Kenneth Casson Leighton added the comment: the last time this was brought up on python-dev the opinions of the primary python developers was made very very clear: anything that is not written by them is treated with extreme hostile and predudicial contempt. what i mean by that is that the view of the primary python developers is that when they make decisions to decrease their workload, other people are *NOT* welcome to question those decisions. [i questioned their decisions; all bugreports were terminated with excuses without good technical justification, and when i questioned those, access to the bugtracker was terminated]. roumen's work should have been encouraged and welcomed when it was first initiated - FIVE years ago. the best bet therefore is to go over the heads of the primary python developers and to approach the Python Software Foundation's Board of Directors. they are required to enact the PSF Charter in the best interests of the Python Programming Language. what the existing primary python developers can or cannot cope with is of secondary consequence for the Board. the main concern of the primary python developers was that they would be landed with yet another platform to support, and, as they are struggling to cope with the existing ones, they made - and make - absolutely any excuse that they can, regardless of actual merit, to ensure that no other platforms are added. roumen, my opinion is that you have demonstrated over the past five years that you are committed to ensuring that python gets mingw support, and that you yourself are the best person to become the maintainer of python-mingw. you are, already, de-facto, its maintainer. answering some other points: * python-mingw actually requires an entire new platform (built in to sys and os at a fundamental level). neither the platform rules for cygwin, nor the platform rules for gcc, *nor* the platform rules for win32 correctly apply. the MSVC platform rules should also be obviously understood to be useless. mingw uses gcc, but it is gcc for win32: it therefore falls through *all* the existing platforms and requires its own separate class in distutils. * the autoconf-generated pyconfig.h is so insanely slow to generate under mingw (any configure script running under MSYS is insanely slow) that it is virtually impossible to do any development. also, the hard-coded config header file for win32 is also useless: firstly mingw doesn't have all the features of win32 (the headers are reverse-engineered and so are incomplete). secondly, the hard-coded config header file for win32 has MSVC-specific details in it that make it useless. * distutils was frozen because several immature developers made improperly tested commits that caused massive disruption. rather than put in proper review procedures, the primary python developers decided to terminate all possibility of ever adding in a new platform - ever - and began distutils2. this situation has to be reversed. mingw *requires* that distutils have support for the mingw compiler. a way to achieve this is to add separate files into distutils (which cannot be questioned as to their effect on existing files in distutils, because they are separate and therefore have zero effect), and then, once those files have been added and accepted, create a *ONE* line patch to distutils which pulls in the new mingw distutils functionality. a one-line patch cannot really be argued with, esp. if it is only an include. roumen and others: i recommend that you approach the Python Software Foundation and ask that this project be sponsored for 3 months and/or until it is completed and the patches are in. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue3871 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3871] cross and native build of python for mingw32 with packaging
Luke Kenneth Casson Leighton l...@lkcl.net added the comment: distutils2 is the place to add such new features. you're not getting it. you've just told both this mingw32 project and also the new effort by ray that they can go fuck themselves, because their efforts are a total waste of time (as far as python 2 is concerned). why? because without patches to python 2 distutils, you're condemning their work to total irrelevance. why? because nobody in their right mind is going to do what you suggest - go educate people about using distutils2. that's tens of thousands of package maintainers, and you're expecting *two* people to do that job - you must be off your head if you think that's even remotely realistic! i can't quite understand why you would even make such a recommendation, because it's so clearly unworkable and unrealistic. now, if python2 was in any way going to die, be totally irrelevant or otherwise be superceded at any time in the next ten years i would in no way be so pissed at this freeze, and would in no way bother to comment on this. i don't like doing this sort of thing: it makes me look like i'm some sort of fucking idiot - but that's tough luck on me. someone has to tell it straight, and truthfully say the things that everyone else doesn't have the balls to say. what has me particularly pissed off is that the freeze happened years *AFTER* roumen created this initial patch. also what has me particularly pissed off is that the freeze happened because *other people* - not roumen, and not ray - didn't do their job, either in checking that their modifications to distutils would have an impact on any other ports, but more than that, neither did anyone else in the python team. why should ray and roumen's work be made insultingly irrelevant, just because of mistakes made by *other people*? by complete contrast, i absolutely agree with you 100% that in NO WAY should any modifications to distutils in python3 sources be EVER permitted. forcing people to use distutils2 for *new* packages, as well as packages being transitioned to python3, and documenting that fact (and the required procedure to be followed) prominently on the python web site, is perfectly reasonable. the reason why it is perfectly reasonable is because the developer who is writing the new package (or transitioning the old one) is *actively* taking the steps - THEY are taking steps - THEY are the ones ACTIVELY doing the work. intiated BY THEM. people PLURAL. tens of THOUSANDS of people. and those people will read documentation, and will ask questions on the mailing list, and will generally follow the advice and guidance of the community. contrast this with a completely unrealistic expectation that TWO people must DEMAND of those exact same tens of thousands of python2 developers that ohhh, you muuust use distutils2 and you can perhaps appreciate why i am not exactly impressed. of course, if the Python Software Foundation is offering to fund these two developers with a campaign to educate the entire world of python2 package maintainers with the demand that they all convert to distutils2, and is willing to support them by creating a write-up and a series of articles and other supporting documentation on the python.org web site, then that is an entirely different matter. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue3871 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3871] cross and native build of python for mingw32 with packaging
Luke Kenneth Casson Leighton l...@lkcl.net added the comment: The feature freeze applies to all branches. Even when 3.4 starts, the same rule that has been repeatedly explained for two years will apply: no new features in distutils. Again, neither Tarek nor I are happy about that, but it was the decision taken by python-dev due to the big number of setup.py scripts depending on undocumented behavior, bugs and quirks. then you use monkeypatching. split the new functionality into a separate module - /distutils/mingw.py - that is called by a clear ONE LINE modification in distutils.py that CLEARLY cannot have IN ANY WAY not one SINGLE effect on ANY OTHER python port. that line would be something like: if sys.compiler == 'mingw32': import distutils.mingw within that distutils.mingw it would monkey-patch distutils to add itself into the distutils code. the same technique could be used by ray to monkey-patch the cygwin compiler by doing this: distutils/specialportmaintainedbyray.py: distutils.cygwincompiler.RE_VERSION = re.compile(b'[\D\s]*(\d+\.\d+(\.\d+)*)[\D\s]*$') of course, for this to work, support for the ports are required (identification of the ports) down at the sys.py and os.py level. unless you expect these port maintainers to put in special monkeypatching into the c-code itself (which would of course be conditionally compiled and would in no way affect ANY other port of python). this would be perfectly reasonable. the impact on other ports would be zero. consideration of the one line patch would take a few minutes. ... and for those packages that depend on undocumented behaviour? in the unlikely event that they ever get compiled for mingw32 or ray's port, well, the person who compiled such a package would encounter an error, and would wonder why it was broken, and then would get onto a mailing list and go i have a problem, can anyone help me. chances are that the majority of packages would however compile cleanly. there's always a way. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue3871 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3871] cross and native build of python for mingw32 with packaging
Luke Kenneth Casson Leighton l...@lkcl.net added the comment: eric, if you recall there was some discussion that it was acceptable to use distutils but *only* for python 2.N (on the basis that its use is so well entrenched that it would be impossible to force python2.N applications to start using distutils2), and i agreed wholeheartedly with you that the expectation to use distutils2 would be reasonable for python3.N just as an aside: have all python 3.N packaging scripts, for all python-dev scripts *and* all 3rd party packages world-wide, been using distutils2 by default instead of distutils? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue3871 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5043] get_msvcr() returns None rather than []
Luke Kenneth Casson Leighton l...@lkcl.net added the comment: i'm really sorry, eric, but the decision to ban me from interacting with python developers for 18 months+ has left me with zero working knowledge of many of these complex issues which i was heavily and actively involved in at the time, and could have answered immediately. the opportunity to interact with me and to move the mingw32 port forward was at the time, not 18+ months later. i've since *removed* the highly complex development environment which was tricky as hell to set up (mingw32 cross compiler, mingw32 native compiler, python, native python, wine, MSYS under wine, python-win32 under wine) because it was declared that the work being carried out was worthless. i'll have to leave it to roumen to answer this one. l. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5043 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3871] cross and native build of python for mingw32 with distutils
Luke Kenneth Casson Leighton l...@lkcl.net added the comment:
I disagree;
i would say that you're entitled to disagree, but i have to point
out that unless you've actually been through the process of trying
to port python to mingw32 you're not really in a position of ...
how can i put this best... you're entitled to say i disagree
but that doesn't actually carry any weight.
if you said i've tried compiling this patch, and i looked at
it and i disagreed with the decision to create a new platform,
so i removed that code, here's an updated patch, i found it to
work absolutely fine THEN i would say that you are in a position
of authority to disagree.
so - question: have you actually _tried_ compiling python with
mingw32, with the latest patch?
programs compiled with mingw32 run on Windows, and use the MSVC
runtime.
they do indeed. this however has absolutely no relevance.
It's the same platform as the current win32 build.
It's even possible to use mingw32 to compile extensions
for the VS9.0 based python.exe.
it is indeed. the patch that i did allowed you to specify
a gcc spec file which did exactly that: i added options to
compile not only extensions but also the entire python.exe
to use a different MSVCRT runtime.
_and_ it did assemblies, too.
A different compiler does not make a new platform.
ok.
unfortunately, as the work that i did was well over a year ago,
i'm going from memory - but basically, i'm very very sorry to
have to point out that you don't know what you're talking about,
here.
let me try and go through it.
look at the platform detection code: it parses the gcc version
string. it goes if compiler has string gcc but also has win32
then it must be cygwin platform.
otherwise it goes this must be MSVC win32 platform.
this _simply_ doesn't work, hence the need to do further
detection, hence the need to have a separate compiler type.
... but it doesn't end there: there are subtle differences
between MSVC win32 and MINGW32 win32 (differences in the
build .lib files that specify what functions are available
in the DLLs. mingw32 is a reverse-engineering project,
remember?)
to be honest i can't remember if i actually set sys.platform to
mingw32 - but the more time i spent getting more and more modules
to compile, the more blindingly obvious it was that a new platform
type was needed.
i encountered dozens of assumptions that if sys.platform == 'win32'
then you MUST be building using visual studio: f*** off with your
attempt to compile this module using gcc.
over the eight to ten week period in which i focussed on this
non-stop for about 13 hours a day, the list just went on and on
of discrepancies that had to be solved, and if i _hadn't_ set a
new platform type, it would have been necessary to add extra
tests instead:
if sys.platform == 'win32' and not {something to detect mingw32}:
mingw32 _really_ does fall between both worlds: not just the
compiler type is different, but there are even features and
functions _missing_ from mingw32 that are present in MSVC.
i had to work with roumen to get patches to mingw32 upstream
in some cases!
so please _do_ stop putting road-blocks in the way. this is
a complex enough project, having to fit half way between
two disparate worlds, without it being stymied by disagreement
when you haven't _actually_ tried compiling this code (if you
have, i apologise).
btw if you'd like to try compiling it, but are adamant about
staying away from proprietary operating systems, i _did_
manage to get python 2.5 and 2.6 cross-compiled to run under wine.
ironically there were long-standing bugs in wine that ended up
getting fixed as a result of running the 25,000 python unit tests,
but that's another story... :)
l.
p.s. msys runs under wine as well, but the configure stage takes
well over an hour. the patch i created cut out most of configure
and replaced it with a pcconfig.h just like win32, which i had
to create by hand. this was quicker than waiting for configure
to run.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue3871
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3871] cross and native build of python for mingw32 with distutils
Luke Kenneth Casson Leighton l...@lkcl.net added the comment: perhaps, amaury, you might like to, instead of saying i disagree, you might like instead to say something like this: that sounds... interesting, and a little scary - creating an entirely new platform! are you absolutely sure it's necessary?? could you please perhaps elaborate and give a good justification behind why that decision was taken? you see how radically different that is? on the one hand you're telling three volunteers who have spent considerable time and resources - unpaid - on improving python's reach that they are, to put it bluntly, complete ignorant f*g morons, and on the other you're engaging with them, encouraging them, and generally trusting them. i'm really sorry: i really don't like having to be the one to point these kinds of things out, but... you see what i'm saying? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue3871 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3871] cross and native build of python for mingw32 with distutils
Luke Kenneth Casson Leighton l...@lkcl.net added the comment: I am not sure how we should do this, but here's my proposal for distutils2 at least: - make this new feature a standalone package that patches distutils - release it for 2.x - let's add your work in distutils2 as well, so it's back in the stdlib in 3.x that would work very well: people doing new setup.py files, converting from python2 etc., will, duh, need to do _some_ conversion: they'll expect breakage and to be using distutils2 anyway. thank you tarek. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue3871 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3871] cross and native build of python for mingw32 with distutils
Luke Kenneth Casson Leighton l...@lkcl.net added the comment: The current patch makes too many changes in core distutils functions; it cannot be accepted in this form. I'm sure that most of the needed changes can be made in a subclass of the present Mingw32CCompiler. that's what i did when creating the _other_ (yet another) mingw32 patch - however _some_ minimal changes to core distutils _are_ unfortunately required. and to sys.py and os.py - this is, after all, a new platform! it starts off with sys.platform == 'mingw32', requiring detection of gcc compiler type BUT and os type of win32, and goes from there. right now, detection logic is: * if gcc on win32 platform, platform MUST be cygwin * if msvc compiler, platform MUST be win32 both of which are... well... wrong! :) so, i found that it was necessary to start in os.py and sys.py, create a platform-type mingw32 and _then_ it was easy to do a MingW32Compiler etc. with (mostly) additions not modifications to distutils, but _necessary_ to add in detection of the type. if distutils was designed to do exec import distutils.compiler.%s as compiler % sys.platform and go from there then this would be an entirely non-issue: no modifications to distutils would be required, just a completely separate module containing the new compiler... ... but distutils isn't designed that way, is it? :) l. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue3871 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3781] warnings.catch_warnings fails gracelessly when recording warnings but no warnings are emitted
Luke Kenneth Casson Leighton l...@lkcl.net added the comment: erik, i'm really sorry, but the freeze on distutils simply cannot be accepted: there really is no other way, as you can see from the previous walkthrough analysis, and is reinforced by the further analysis below. simply put: if the freeze on distutils is not lifted, then this entire set of work, which has been going on for years and _precedes_ the distutils freeze by at least 18 months, is completely, utterly and totally wasted. let's walk through the situation where distutils2 is forced to be used. what you're asking for is, basically, that every single third party package, of which there must be tens of thousands, must be patched for compilation on mingw32... _just_ so that it says if sys.platform == 'mingw32': from distutils2.core import setup else: from distutils.core import setup, is that correct? does that strike you as being completely and utterly unreasonable an expectation, to ask third parties to modify setup.py scripts which have worked perfectly well for years, many of which are likely to no longer even have a maintainer? that leaves patching - which should be nothing more than _adding_ to - not changing existing compilers - ADDING an extra compiler - distutils as the only option. now, that can be done monkey-patch style (i.e. at runtime, by adding in code very early on in python startup, or perhaps by patching the import system to replace the word distutils with distutilsmingw32) or it can be done... by lifting the distutils freeze. perhaps i should ask: what _exactly_ is the problem, and why do several teams complete and utter failure to do the correct thing by making changes to _existing_ compile platforms have anything to do with _this_ team's patches which add a new totally separate platform that has absolutely nothing to do with any of the other platforms? i could say more, but i believe the point is clear: none of the people involved in seeing mingw32 added as a platform had _anything_ to do with the past failures, so why punish and mis-trust the python-mingw32 for other peoples' failures? -- nosy: +lkcl ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue3781 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3781] warnings.catch_warnings fails gracelessly when recording warnings but no warnings are emitted
Luke Kenneth Casson Leighton l...@lkcl.net added the comment: NUTS. many apologies: my comments should have gone to issue 3871 not 3781. arse! is it possible to delete comments? :) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue3781 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3871] cross and native build of python for mingw32 with distutils
Luke Kenneth Casson Leighton l...@lkcl.net added the comment: erik, i'm really sorry, but the freeze on distutils simply cannot be accepted: there really is no other way, as you can see from the previous walkthrough analysis, and is reinforced by the further analysis below. simply put: if the freeze on distutils is not lifted, then this entire set of work, which has been going on for years and _precedes_ the distutils freeze by at least 18 months, is completely, utterly and totally wasted. let's walk through the situation where distutils2 is forced to be used. what you're asking for is, basically, that every single third party package, of which there must be tens of thousands, must be patched for compilation on mingw32... _just_ so that it says if sys.platform == 'mingw32': from distutils2.core import setup else: from distutils.core import setup, is that correct? does that strike you as being completely and utterly unreasonable an expectation, to ask third parties to modify setup.py scripts which have worked perfectly well for years, many of which are likely to no longer even have a maintainer? that leaves patching - which should be nothing more than _adding_ to - not changing existing compilers - ADDING an extra compiler - distutils as the only option. now, that can be done monkey-patch style (i.e. at runtime, by adding in code very early on in python startup, or perhaps by patching the import system to replace the word distutils with distutilsmingw32) or it can be done... by lifting the distutils freeze. perhaps i should ask: what _exactly_ is the problem, and why do several teams complete and utter failure to do the correct thing by making changes to _existing_ compile platforms have anything to do with _this_ team's patches which add a new totally separate platform that has absolutely nothing to do with any of the other platforms? i could say more, but i believe the point is clear: none of the people involved in seeing mingw32 added as a platform had _anything_ to do with the past failures, so why punish and mis-trust the python-mingw32 for other peoples' failures? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue3871 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3871] cross and native build of python for mingw32 with distutils
Luke Kenneth Casson Leighton l...@lkcl.net added the comment: I'm trying to read the patch. It contains many interesting things (and others I have no opinon about), but it is very large, and makes it difficult to comment or find why some change were made etc. amaury: unfortunately, the development on adding mingw32 as a platform has been ongoing for well over three years, with absolute silence and rejection of its existence. it was only when a fourth person showed interest in it (LRN) that it became accepted - but that was... only two months ago! basically, this situation should never have been allowed to get this far: the very first patch that was created, three nearly four years ago, should have been accepted, and then an incremental process could have been taken, _and_ the silly situation in which distutils gets frozen during the time when people have been completely ignoring this ongoing work would never have occurred. but, that's the situation: the bed has been made, and now developers have to lie in it. sorry to be the one that's pointing this out, but... anyway. your idea to split this into a series has merit: personally i much prefer git, because of git-format-patch, but i have to say i've never done patch regeneration based on a review / change-patch-in-middle-of-series / regenerate git-format-patch cycle. should be fun! :) but the very very first thing that has to happen - before any of this work is begun - is for the distutils freeze to be lifted, or for someone to come up with a _sensible_ alternative solution. if that cannot be done, then roumen and LRN won't _stop_ working on python-mingw32: the end result will be that they just... continue to create a single patch file that will just get larger and larger. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue3871 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3871] cross and native build of python for mingw32 with distutils
Luke Kenneth Casson Leighton l...@lkcl.net added the comment: sorry to have to ask, but could we get some feedback please so that this issue may move forward? currently there is a conflict between what is required and what is stated as being absolute law. let's imagine that it is reasonable to expect distutils2 to be used. python proceeds with the mingw32 patches using distutils2, python 2.N is compiled and released. an average user installs python 2.N mingw32 and they run python setup.py install on a package - what happens? they get a compile error, don't they? why do they get a compile error? because the setup.py tries to build some c code, and at the top of *their* setup.py is import distutils. so you now force thousands of developers to patch a their setup.py scripts - scripts which have worked for years - _just_ so that those packages can cope with the use of distutils2 for the mingw32 platform? so we have another reducto ad absurdum which demonstrates that it is impractical to expect distutils to be frozen. thus, we are forced to consider alternative options, such as monkey-patching of distutils, to satisfy the requirements. would the following be acceptable, to be inserted somewhere in the path so that it is guaranteed to work at all times? import mingw32_distutils_compiler import sys if distutils.compiler in sys.modules: sys.modules['distutils.compiler'] = mingw32_distutils_compiler where mingw32_distutils_compiler performs an import of distutils.compiler and performs a monkey-patch mish-mash to combine and replace various parts of the compiler module at run-time, to get round the freeze objections. would that be acceptable? please say no, because the long-term viability and maintainability of such practices is virtually nil. basically i'm pointing out to you, eric, that the freeze on distutils is unworkable and impractical and unnecessary. this isn't bug-fixing of distutils, it's absolutely necessary and critically required because this is an entirely new platform. * it's not cygwin: cygwin uses standard gcc but with weird outputs and quirks. * it's not standard unix gcc: you need to output .dll not .so * it's not msvc: mingw32-gcc doesn't accept /this /that for options. therefore i'm very sorry to have to spell it out but a new compiler and linker type - a NEW compiler and linker type - an ADDITIONAL compiler and linker type - IS required in order to cater for this platform, and there's no getting away from that fact. please could we have some acknowledgement of this fact, and acceptance of this fact, and a plan for moving forward with careful review of this patch, so that LRN and others do not have their time spent pursuing a direction involving distutils2 which will be completely fruitless? many many thanks, l. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue3871 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3871] cross and native build of python for mingw32 with distutils
Luke Kenneth Casson Leighton l...@lkcl.net added the comment: On Sun, Aug 8, 2010 at 12:27 AM, Éric Araujo rep...@bugs.python.org wrote: Éric Araujo mer...@netwok.org added the comment: FYI, distutils is frozen because even minor bug fixes have broken third-party tools in the past, that’s why new features and bug fixes land in distutils2. Only some bug fixes that are sure not to break things make their way into distutils. distutils2 will be reintegrated into the stdlib in 3.2 or 3.3, but standalone releases will be made for Python 2.4 up to 2.7 and 3.x. eric, it's been a year since i did the mingw32 port so i'll try to recall what it was that i did, but i have recollections of also having to add to distutils, specifically adding an extra compiler class and an extra linker class, derived from cygwin i believe (and then adding, obviously, platform detection logic and options to make use of them). using logic analysis on the conditions, it can be shown that there is nothing that can satisfy the conditions (one of which is distutils is frozen, another is distutils will not go into python2.N or 3.x etc). thus, something has to give. detailed analysis and recommendations follow: if distutils2 is to be standalone it literally makes it impossible to build python 2.4 up to 2.7 and 3.x using mingw32, because the build infrastructure will be entirely missing. how can you build python 2.7 using mingw32 if one of the critical dependencies - actually saying use mingw32 - is missing?!! the decision to keep distutils frozen therefore forces the mingw32 developers to create a special version of distutils, one which has to be added as a patch to python - let's call it distutils_mingw32 - which has the exact same functionality as distutils except that it is extended to have a mingw32 compiler and linker class. adding such a patch (which adds a copy of distutils called distutils_mingw32) would be extremely disruptive, as it would defeat the entire purpose of distutils, and i would be extremely surprised if it was accepted. so, unpalatable-as-defined-by-previous-negative-experience as it may be, the only sensible option is to do an extremely careful and thorough review of LRN's distutils compiler and linker class additions, and ensure that they are _purely_ additional classes, even at the expense of duplicated code. please remember that mingw32 is an _additional_ platform, not a change to any _existing_ platforms. l. p.s. the only other option i can think of would be to add in build-time options where you can specify the fully-qualified path to where distutils2 can be found. this would be somewhat... contrived, but would work. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue3871 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3871] cross and native build of python for mingw32 with distutils
Luke Kenneth Casson Leighton l...@lkcl.net added the comment: On Mon, Feb 2, 2009 at 9:10 PM, Roumen Petrov rep...@bugs.python.org wrote: Roumen Petrov bugtr...@roumenpetrov.info added the comment: The proposed patch for this issue include parts of other pending issues - so its all is single file. If python team don't like idea for canonical host names (part of issue 3754) this patch can be modified do not use host-triplet. Also some discussions in py-dev list show that small patches are preferred. I'm ready to split into small patches to be reviewed. excellent. that _would_ be good. ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue3871 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5051] test_update2 in test_os.py invalid due to os.environ.clear() followed by reliance on environ COMSPEC
New submission from Luke Kenneth Casson Leighton l...@lkcl.net:
class EnvironTests(mapping_tests.BasicTestMappingProtocol):
check that os.environ object conform to mapping protocol
type2test = None
def _reference(self):
return {KEY1:VALUE1, KEY2:VALUE2, KEY3:VALUE3}
def _empty_mapping(self):
vv
os.environ.clear() -- ***
^^
return os.environ
def setUp(self):
self.__save = dict(os.environ)
os.environ.clear()
def tearDown(self):
os.environ.clear()
os.environ.update(self.__save)
# Bug 1110478
def test_update2(self):
if os.path.exists(/bin/sh):
os.environ.update(HELLO=World)
v
value = os.popen(/bin/sh -c 'echo $HELLO').read().strip()
^ finds os.environ['COMSPEC'] to be empty!
self.assertEquals(value, World)
this test will obviously fail, see _PyPopenCreateProcess in
posixmodule.c.
if (i = GetEnvironmentVariable(COMSPEC,NULL,0)) {
char *comshell;
}
/* Could be an else here to try cmd.exe / command.com in the path
Now we'll just error out.. */
else {
PyErr_SetString(PyExc_RuntimeError,
Cannot locate a COMSPEC environment variable to
use as the shell);
return FALSE;
}
the environment variables having been destroyed, there _is_ no
COMSPEC to obtain a working cmd.exe or command.com in order to
execute the /bin/sh (or /bin/sh.exe in the case of having installed
msys and created a symlink from c:/msys/bin to c:/bin).
--
components: Tests
messages: 80502
nosy: lkcl
severity: normal
status: open
title: test_update2 in test_os.py invalid due to os.environ.clear() followed by
reliance on environ COMSPEC
versions: Python 2.7
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue5051
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5056] PyAPI assumes OS can access shared data in loadable modules (windows can't)
New submission from Luke Kenneth Casson Leighton l...@lkcl.net:
an assumption has been made in the python core api that all operating
systems dynamic module loading can access data segments. windows
_cannot_ do this.
the workaround has been to statically link absolutely _everything_
into a single whopping great dll.
the proper solution is to provide accesser functions:
PyAPI_FUNC(PyObject *)
PyErr_GetPyExc_OSError(void)
{
return (PyObject*)PyExc_OSError;
}
PyAPI_FUNC(char*) _PyStructSequence_Get_UnnamedField(void)
{
return PyStructSequence_UnnamedField;
}
... actually the _best_ solution is to have everything that's needed in
a vector-table [discussed on python-dev mailing list]
--
components: Build
messages: 80513
nosy: lkcl
severity: normal
status: open
title: PyAPI assumes OS can access shared data in loadable modules (windows
can't)
versions: Python 2.7
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue5056
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5058] stop pgen.exe from generating CRLF-ended files and causing mayhem with win32-based patch submissions
New submission from Luke Kenneth Casson Leighton l...@lkcl.net:
diff --git a/Parser/pgenmain.c b/Parser/pgenmain.c
index fc27a2c..a4d4911 100644
--- a/Parser/pgenmain.c
+++ b/Parser/pgenmain.c
@@ -49,7 +49,7 @@ main(int argc, char **argv)
graminit_h = argv[2];
graminit_c = argv[3];
g = getgrammar(filename);
- fp = fopen(graminit_c, w);
+ fp = fopen(graminit_c, wb);
if (fp == NULL) {
perror(graminit_c);
Py_Exit(1);
@@ -58,7 +58,7 @@ main(int argc, char **argv)
printf(Writing %s ...\n, graminit_c);
printgrammar(g, fp);
fclose(fp);
- fp = fopen(graminit_h, w);
+ fp = fopen(graminit_h, wb);
if (fp == NULL) {
perror(graminit_h);
Py_Exit(1);
@@ -79,7 +79,7 @@ getgrammar(char *filename)
grammar *g0, *g;
perrdetail err;
- fp = fopen(filename, r);
+ fp = fopen(filename, rb);
if (fp == NULL) {
perror(filename);
Py_Exit(1);
--
components: Build
messages: 80517
nosy: lkcl
severity: normal
status: open
title: stop pgen.exe from generating CRLF-ended files and causing mayhem with
win32-based patch submissions
type: feature request
versions: Python 2.7
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue5058
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5056] PyAPI assumes OS can access shared data in loadable modules (windows can't)
Luke Kenneth Casson Leighton l...@lkcl.net added the comment: apologies - case of mistaken identity! patch attached - beginnings of moving data over to accessor-functions. attached here because it is relevant for vector-table future work. please close this bug. -- keywords: +patch Added file: http://bugs.python.org/file12855/data_into_fns.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5056 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5043] get_msvcr() returns None rather than []
New submission from Luke Kenneth Casson Leighton l...@lkcl.net:
def get_msvcr():
Include the appropriate MSVC runtime library if Python was built
with MSVC 7.0 or later.
msc_pos = sys.version.find('MSC v.')
if msc_pos != -1:
msc_ver = sys.version[msc_pos+6:msc_pos+10]
if msc_ver == '1300':
# MSVC 7.0
return ['msvcr70']
elif msc_ver == '1310':
# MSVC 7.1
return ['msvcr71']
elif msc_ver == '1400':
# VS2005 / MSVC 8.0
return ['msvcr80']
elif msc_ver == '1500':
# VS2008 / MSVC 9.0
return ['msvcr90']
else:
raise ValueError(Unknown MS Compiler version %i % msc_Ver)
return [] -
--
components: Build
messages: 80466
nosy: lkcl
severity: normal
status: open
title: get_msvcr() returns None rather than []
versions: Python 2.7
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue5043
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5046] native win32 and wine mingw+msys build of python2.7
New submission from Luke Kenneth Casson Leighton l...@lkcl.net: this is an update of the mingw+msys port for native win32, with the aim of being both compiled and used under both wine-win32 and native-win32. it is not a cross-compile patch. it does not require -lwine. it does not require a unix system. it does not require cygwin. (repeat the previous four sentences for both build _and_ use of the resultant python.exe). this information is specifically given and stated [so blandly] because several people have been extremely confused by what this patch achieves, due to the tools being utilised to achieve it [wine]. the patch is against svn trunk r68884. as of 2 hours ago, the following tests failed: 22 tests failed: test_cmath test_cmd_line_script test_compiler test_ctypes test_decimal test_distutils test_file test_logging test_mailbox test_math test_ntpath test_os test_parser test_posixpath test_pwd test_smtplib test_startfile test_tempfile test_transformer test_winsound test_zipfile test_zipimport_support since then, several have been corrected. test_pwd should not be being tested. several of the tests (test_tempfile) are fails due to use of native wine msvcrt (it gets better when win32 msvcrt is used). this is work-in-progress for those people interested. builds with --enable-msvcr9build are possible. incorporation of roumen's cross-compile work is ongoing. -- components: Build files: python-2.7a0-r68884-mingw-msys.patch keywords: patch messages: 80481 nosy: lkcl severity: normal status: open title: native win32 and wine mingw+msys build of python2.7 type: feature request versions: Python 2.7 Added file: http://bugs.python.org/file12849/python-2.7a0-r68884-mingw-msys.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5046 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4954] native build of python win32 using msys under wine.
Luke Kenneth Casson Leighton l...@lkcl.net added the comment: updated. incorporating roumen's work as well. Added file: http://bugs.python.org/file12826/f ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4954 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5026] [reopening] native build of python win32 using msys under wine.
New submission from Luke Kenneth Casson Leighton l...@lkcl.net: reopening a new bug with the exact same title due to #4954 having been unilaterally closed without discussion, nor reasons specified. simple courtesy would dictate that some sort of dialog is entered into especially when someone is putting in significant amounts of work in developing python, and has plans to forward-port the patch to python2.6 and trunk, merge it with #3844 and much more. -- components: Build files: f messages: 80339 nosy: lkcl severity: normal status: open title: [reopening] native build of python win32 using msys under wine. versions: Python 2.5 Added file: http://bugs.python.org/file12827/f ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5026 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5026] [reopening] native build of python win32 using msys under both wine and native win32
Luke Kenneth Casson Leighton l...@lkcl.net added the comment: so. let me be clear. this bug is a continuation of work to port python to mingw, with a specific BUT NOT UNIQUE focus of ensuring that python can be compiled under wine. THE ATTACHED PATCH CAN ALSO BE USED TO COMPILE PYTHON UNDER WIN32. -- title: [reopening] native build of python win32 using msys under wine. - [reopening] native build of python win32 using msys under both wine and native win32 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5026 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5026] [reopening] native build of python win32 using msys under both wine and native win32
Luke Kenneth Casson Leighton l...@lkcl.net added the comment: attached also manifests and rc files for building on msvcr80 Added file: http://bugs.python.org/file12829/x ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5026 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4954] native build of python win32 using msys under wine.
Luke Kenneth Casson Leighton l...@lkcl.net added the comment: manifests and rc files for msvcr80 build Added file: http://bugs.python.org/file12830/x ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4954 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4954] native build of python win32 using msys under wine.
Luke Kenneth Casson Leighton l...@lkcl.net added the comment: martin, so sorry, i didn't see your comments - no dang hell no i'm not done yet. regarding graminit.h: graminit.h isn't being removed - i keep editing it out of the patch. i'm not _submitting_ it as part of the patch because what happens is that Parser/pgen.exe generates CRLF and EERY single line of graminit.h gets replaced. so it's a bit irritating to keep having to even see it, so i removed it from my local repository. if i accidentally submit its removal please ignore it, entirely. people _are_ tracking the progress of this development, and assisting in the work. i'm using the bugtracker to communicate the progress. closing the bug looks... like... i dunno - it's not very helpful, though, i have to say. ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4954 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5026] [reopening] native build of python win32 using msys under both wine and native win32
Luke Kenneth Casson Leighton l...@lkcl.net added the comment: martin - apologies for shouting: i hadn't seen your explanations of why #4954 was closed. i'm not happy that it _was_ closed, but that's another story. yes of course i will be going on to python2.6 and up - first though is to focus on python2.5 and get _that_ into shape, then moving on to 2.6 and 2.7 is easy. ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5026 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5010] repoened test_maxint64 fails on 32-bit systems due to assumption that 64-bit fits into long due to it being closed without asking me whether there was anything else involved
New submission from Luke Kenneth Casson Leighton l...@lkcl.net: this is reopening http://bugs.python.org/issue4977 because it was closed without asking whether there was any further information or anything else that required investigation. there is no way for me to reopen the bug so i am forced to open a new one. mark - don't do that again, please. the suggestion to use PyOS_strtol was a good one: you should have left the bug as-is after that suggestion, and WAITED until i had tested that. the bug involves 64-bit zip files. the fact that a 32-bit int is being returned, as -4932893211 (whatever) instead of 44951 (whatever) is causing the problem. so will you be kind enough and courteous enough to wait until i have provided full information and investigated this issue? or do you not want me to bother? -- components: Build messages: 80241 nosy: lkcl, marketdickinson severity: normal status: open title: repoened test_maxint64 fails on 32-bit systems due to assumption that 64-bit fits into long due to it being closed without asking me whether there was anything else involved versions: Python 2.5 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5010 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4977] test_maxint64 fails on 32-bit systems due to assumption that 64-bit fits into long
Luke Kenneth Casson Leighton l...@lkcl.net added the comment: hiya folks, lots of comments here. in no particular order: 1) thanks for reopening the bug 2) apologies for not being clearer - it's Lib/test/test_testzip.py specifically the TestZip64InSmallFiles case that's failing. 3) it's not yet _clear_ whether strtol is the cause of the problem - i haven't yet got round to testing that because i'm in the middle of a rebuild trying to get msvcr80 assemblies to work, and i'll need to back out of that and rebuild with msvcrt or msvcrt71 first. 4) i'm not yet certain as to whether it's the mingw 3.4.5 _compiler_ that's broken (!) there's some empirical evidence suggesting that it might well be, but again, that's not yet determined 5) under wine, strtol goes through to msvcrt, which goes through to ntdll, which goes through to the _unix_ system's strtol. wine is compiled with -m32, so it _should_ still all be doing 32-bit stuff, even though i'm using a 64-bit host (debian/amd64). on balance, i'd very much appreciate this being kept open so that i can keep track of determining what the heck is going on - i have about five or six different things to investigate. ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4977 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3871] cross and native build of python for mingw32 with distutils
Luke Kenneth Casson Leighton l...@lkcl.net added the comment: roumen, hi, can you add: BASECFLAGS=-mthreads $BASECFLAGS LDFLAGS=-mthreads $LDFLAGS when compiling with threads, and... a second request: _block_ people from compiling without mthreads, because there's a bug in wine's msvcrt _filbuf routine where it doesn't perform CRLF (at all) and it should. http://bugs.winehq.org/show_bug.cgi?id=16970 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue3871 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3871] cross and native build of python for mingw32 with distutils
Luke Kenneth Casson Leighton l...@lkcl.net added the comment: roumen, hi, can you add: BASECFLAGS=-mthreads $BASECFLAGS LDFLAGS=-mthreads $LDFLAGS when compiling with threads, and... a second request: _block_ people from compiling without mthreads, because there's a bug in wine's msvcrt _filbuf routine where it doesn't perform CRLF (at all) and it should. http://bugs.winehq.org/show_bug.cgi?id=16970 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue3871 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4954] native build of python win32 using msys under wine.
Luke Kenneth Casson Leighton l...@lkcl.net added the comment: workarounds for a couple of wine bugs, also includes e.g. #4977 64-bit assumptions on 32-bit systems. Added file: http://bugs.python.org/file12780/f ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4954 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4954] native build of python win32 using msys under wine.
Changes by Luke Kenneth Casson Leighton l...@lkcl.net: Removed file: http://bugs.python.org/file12764/x ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4954 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4956] Py_Initialize needs to be done before file load (on msys+wine)
Luke Kenneth Casson Leighton l...@lkcl.net added the comment: hi gabriel, thanks for looking at this, and my apologies for not editing the patch to remove debug and other information: i'm in the middle of a comprehensive porting session. WEIRD_DEBUG was me endeavouring to find out what the hell is going on test_str.py segfaulted python under wine due to HAVE_SNPRINTF not being defined - but that's irrelevant to this issue likewise ignore the modification to setup.py regarding the advice to seek out and understand the cause, i have to say that i much prefer to ... how can i put this best... @BEGIN CAVEAT THE FOLLOWING STATEMENTS ARE MADE WITH ABSOLUTELY NO INTENTION TO CAUSE OFFENSE DO NOT TAKE THIS PERSONALLY IN ANY WAY DO NOT TAKE IT AS A DELIBERATE INTENT TO OFFEND, CAUSE OFFENSE, CRITICISE OR OTHERWISE INDICATE MALICIOUS OR HOSTILE INTENT being absolutely honest: i genuinely do not care about the cause. what i care about is working. does it work if this code is moved? yes. does it work if the code is not moved? no. does it _matter_ if the cause is identified? no. will someone else, possibly in the future, accidentally encounter or deliberately and actively seek out the cause? possibly. so - many many apologies for saying this, but i have much better and more interesting and valuable things to be doing with my time than _finding out_ why moving specific bits of code makes things works. yes it would be nice to know... but i don't care!! because, most importantly, me _knowing_ makes absolutely -all difference to the outcome of whether it will work or not. so, on balance, i'd rather spend my time finding out the additional code-moving and code-improving required to debug the additional bug where python.exe -i will give me a prompt but python.exe with no arguments will not (and hangs). @END CAVEAT gabriel, hi, debugging python.exe under msys under wine under linux is _really_ tricky. * gdb.exe under msys under wine under linux not only segfaults on exit but also refuses to fork() in order to spawn the process to be debugged! * strace obviously cannot be used _inside_ msys / wine * strace _outside_ - on the /usr/bin/wine process - often interferes with the processes it is tracking, causing them to run out of resources and also to fail to start up. * gdb cannot be attached from _outside_ of wine (/usr/bin/winegdb) to an internal process. fortunately, segfaults inside wine result in quite a good stacktrace report, including line numbers and filenames inside python, but in this case it's hanging - and there's something _really_ weird going on with the stdin, stdout and stderr. overall, then, the payoff in time invested in understanding what is going on by using non-standard and laborious debugging techniques is extremely small. small enough so that, i am very very sorry to say, i'm not going to put any further time into this _other_ than to _actually_ fix bugs, rather than understand bugs. it's a development technique that has saved me _vast_ amounts of time. i never worry about why - i just get on with it. ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4956 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4956] Py_Initialize needs to be done before file load (on msys+wine)
Luke Kenneth Casson Leighton l...@lkcl.net added the comment: here's a clue: $ ./python.exe -i Python 2.5.2 (r252:60911, Jan 16 2009, 10:34:33) [gcc] on win32 Type help, copyright, credits or license for more information. exit() close failed: [Errno 0] Success $ ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4956 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4956] Py_Initialize needs to be done before file load (on msys+wine)
Luke Kenneth Casson Leighton l...@lkcl.net added the comment: here's another clue: $ ./python.exe stdin_is_interactive: 0 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4956 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4956] Py_Initialize needs to be done before file load (on msys+wine)
Luke Kenneth Casson Leighton l...@lkcl.net added the comment: here's an updated version, without the cruft. this has a workaround for the problem of stdin being seen as not a tty (!) until _after_ Py_Initialize() is run. Added file: http://bugs.python.org/file12763/x ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4956 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4954] native build of python win32 using msys under wine.
Luke Kenneth Casson Leighton l...@lkcl.net added the comment: martin, hi, thanks for responding. * graminit and configure were removed because they are built automatically. no project should ever include auto-generated files so i assumed that it would be reasonable to remove them from the python_2.5.2 original git commit that i did, in order to produce the diff. on a build, graminit got _replaced_ with one that had ^M after eery siiingle line. so - if graminit and configure _are_ in the main python source tree, it's a serious mistake that should be rectified _immediately_. ... but i doubt that, and so graminit and configure appearing to be removed can be ignored. * regarding your comment that compiling python under msys under wine is a minority platform, i believe that that is also a serious assumption. the reason why it's a minority platform is because... THERE WASN'T ANY CHOICE. i.e. msys and wine simply have not been good enough - and certainly not _demonstrated_ as being good enough - which this patch shows that they now most definitely are - to _have_ any choice about whether python should be compiled with purely free software tools. instead of depending on some ing proprietary piece of double- operating system _and_ the development IDE it walked in on. sorry about that - just to emphasise how distasteful i find it to be _forced_ to use proprietary software, and i'm not the only person. basically, it should be pretty clear that now that python _can_ be compiled for win32 using an entirely free-software platform, the proprietary build chain should be absolutely dropped like a red-hot stone. ... but regarding minority platform? that's really quite funny and ironic. it was a _non-existent_ platform until about... yesterday :) ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4954 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4954] native build of python win32 using msys under wine.
Luke Kenneth Casson Leighton l...@lkcl.net added the comment: hi amaury, thanks for responding. Is Msys+Mingw32 (running on a regular Windows) an interesting configuration to support? [wine+]msys+mingw32 is used to _build_ python - not depend on it. [wine+]msys+mingw32 _replaces_ the proprietary build toolchain MSVC. clarification: * in the case of #3871, msys+mingw32 replaces MSVC. * in the case of #4954, wine+msys+mingw32 replaces MSVC _and_ windows but in either case, you end up with a complete build of python.exe, libpython2.5.dll and modules that is perfectly well capable of running under both wine _and_ native windows... ... WITHOUT requiring, in any way shape or form, EITHER msys OR mingw32. in other words, it's a big damn deal. no more proprietary dependence. ... let me put it this way, martin: if i told richard stallman that you said that msys+mingw32 was a minority platform he'd have a fit!! :) The build tools are similar to the ones used by cygwin, except that the C runtime is msvcrt. ys sort-of - but if you do s/#ifdef __CYGWIN__/#if defined (__CYGWIN__) || defined(__MINGW32__) it all goes _horribly_ wrong :) you actually have to do s/#ifdef _MSC_VER/#if defined(_MSC_VER) || defined(__MINGW32__) because _MSC_VER is used alll over the place to detect and indicate a win32 build (as separate and distinct from a cygwin build). ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4954 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4954] native build of python win32 using msys under wine.
Luke Kenneth Casson Leighton l...@lkcl.net added the comment: updated patch - also removes quotes removal quotes of graminit and configure so that martin is happier :) also included is an updated version of #4956 as it's an essential integral part of compiling and using python.exe under msys that it actually WORK! :) Added file: http://bugs.python.org/file12764/x ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4954 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4954] native build of python win32 using msys under wine.
Changes by Luke Kenneth Casson Leighton l...@lkcl.net: Removed file: http://bugs.python.org/file12755/f ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4954 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4956] Py_Initialize needs to be done before file load (on msys+wine)
Changes by Luke Kenneth Casson Leighton l...@lkcl.net: Removed file: http://bugs.python.org/file12758/f ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4956 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3871] cross and native build of python for mingw32 with distutils
Luke Kenneth Casson Leighton l...@lkcl.net added the comment: roumen, hi, i'm interested in collaborating with you to get python compiled under wine (running msys+mingw32 under wine, on linux). #4954 incorporates much of your work, and takes a slightly different direction for the configure setup - the time taken to complete configure under wine is intolerable (3 hours). also i have found that by setting PATH=%PATH%;c:/mingw/bin in the environment vars, the python.exe that's produced can successfully be used to run setup.py build. ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue3871 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4954] native build of python win32 using msys under wine.
Luke Kenneth Casson Leighton l...@lkcl.net added the comment: Please trust that Python puts generated files into the repository for good reasons. i can respect that :) for no reason other than if somone says please trust, i do :) ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4954 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4954] native build of python win32 using msys under wine.
Luke Kenneth Casson Leighton l...@lkcl.net added the comment: So what CRT do you link with? Is it msvcrt? Which version? i was _just_ beginning to wonder about that, after i saw rpetrov's comments about MSCVER stuff. http://www.mingw.org/wiki/SpecsFileHOWTO aww, _frick_. :) well... it's _going_ to be msvcr80. why don't mingw ship with a pre-prepared msvcr80 specfile?? *sigh*. will get back to you on that one - it may make a difference on the regression tests (250 passed, 12 failed, 8 skpped). ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4954 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4954] native build of python win32 using msys under wine.
Luke Kenneth Casson Leighton l...@lkcl.net added the comment: It is certainly desirable to be able to build extension modules with this configuration; yeah, and the nice thing is - it works, too! :) AFAIU, distutils already supports that case. not without modification, it doesn't: #3871 adds proper mingw32 compiler detection and link options, such as support for dll.a which isn't auto-detected (but is on cygwin) etc. etc. Whether or not it is desirable to be build Python from source in this configuration, I don't know - most people that want to build with mingw seem to be using the Python binaries available from python.org, or from ActiveState. i tried that a few months ago. 1) there is no .tgz for python-win32 so i was forced to install from a binary package 2) there is no .exe so i was forced to install from msi, a proprietary installer - which as a free software developer, i have issues with, but i tried it anyway. 3) msi installed, thanks to winetricks, but segfaulted and borked. as i didn't really want to use it, i wasn't that unhappy. 4) the msi turns out to be understood by the free software cabextract package. but... the filenames are all borked and mangled. at that point, i decided i'd had enough: i wasn't going to go through 100 files looking for the one that _might_ be the python25.lib implib, plus other files that i'd need to do a non-proprietary-dependent build of python software. I'm not sure whether mingw is capable of building Python correctly, with assembly manifests and all. python setup.py build seems quite happy: rpetrov added .S to the compile-extensions and happily compiled win32.S in libffi with it. the only slight issue there is that the assembly file is incompatible with MSVC and so it borked (not at build time, unfortunately - at runtime). there's been a gcc bugreport raised, to get interoperability back (urk). GCC issue #36834. ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4954 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4954] native build of python win32 using msys under wine.
Luke Kenneth Casson Leighton l...@lkcl.net added the comment: yaay! here's the regression test log, including some loovely wine segfaults :) summary: 250 tests OK. 12 tests failed: test_builtin test_cpickle test_file test_gzip test_locale test_mailbox test_os test_pep277 test_socket test_unicode_file test_xpickle test_zipfile 60 tests skipped: 8 skips unexpected on win32: test_bz2 test_cProfile test_bsddb test_profile test_tcl test_sundry test_sqlite test_winsound not baaad :) Added file: http://bugs.python.org/file12765/regressiontest.log ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4954 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3871] cross and native build of python for mingw32 with distutils
Changes by Luke Kenneth Casson Leighton l...@lkcl.net: -- nosy: +lkcl ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue3871 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4954] native build of python win32 using msys under wine.
New submission from Luke Kenneth Casson Leighton l...@lkcl.net: this patch uses work from #3871 to get a build of python for win32 by running msys under Wine, the windows emulator, on linux. no proprietary operating system or proprietary software was used. /bin/sh.exe is so ing unbelievably slow on msys under wine (each sh.exe takes two seconds to start up, loads 240 fonts and 40 libraries) that running configure was completely intolerable. consequently, given that PC/config.h is perfectly useable on nt, this patch totally bypasses the majority of autoconf tests, and thus cuts the configure time down from three hours to (only!) fifteen minutes. configure must be run as: ./configure --prefix/python25 --enable-win32build=yes \ --enable=shared=yes there is an additional bug in msys /bin/sh which stops python.exe from executing scripts that are handed to it on the command-line. scripts that are fed as standard-input are absolutely fine (even the same script). running the same script from python.exe from wineconsole cmd prompt is _also_ fine. as a result, the build process terminates at: ./python.exe -E setup.py build to complete the build, wineconsole cmd must be run, cd $(BUILDDIR) and then run the commands manually: ./python.exe -E setup.py build ./python.exe -E setup.py install then, back in the borked /bin/sh.exe, make install can be run. stunningly, this does actually work: python.exe is build, libpython2.5.dll and libpython2.5.dll.a are built... amazing. other necessary workarounds: * gcc -shared --out-implib=libpython2.5.dll.a etc fails spectacularly to create both the .a implib _and_ the .dll. consequently, it was necessary to split these up and use dlltool to create the dll, implib and .def file etc. etc. * ar and ranlib on msys, versions 2.16, 2.17 _and_ 2.19 of binutils are borked. 2.16 and 2.17 throw an exception; 2.19 segfaults. consequently, building of $LIBRARY had to be terminated with prejudice. --enable-shared=no will fail miserably. regarding testing: it's all a bit... odd. * ctypes tests cause segfaults! the S8H one manages a segfault all on its own, but there are other tests that cause corruption that only shows up later... euurgh. * builtin test_open fails due to putting \r\n instead of \n in the file * test_file.py gets a sharing violation * test_str gets a great one! test_str^M fixme:msvcrt:MSVCRT__sopen : pmode 0x01b6 ignored fixme:msvcrt:MSVCRT__sopen : pmode 0x01b6 ignored err:seh:setup_exception_record stack overflow 872 bytes in thread 001e eip 7bc3b1dc esp 00410fc8 stack 0x41-0x411000-0x61 yup test_floatformatting. ahh, this is gd :) overall it's a damn good start - i'm dead impressed with wine and msys in that they exist at all. compiling and testing python under wine + msys should help test and improve both those projects, and both this patch and #3871 will help get python off of its dependence on proprietary software. -- components: Build files: f messages: 79916 nosy: lkcl severity: normal status: open title: native build of python win32 using msys under wine. versions: Python 2.5 Added file: http://bugs.python.org/file12755/f ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4954 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4954] native build of python win32 using msys under wine.
Changes by Luke Kenneth Casson Leighton l...@lkcl.net: -- type: - feature request ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4954 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4956] Py_Initialize needs to be done before file load (on msys+wine)
New submission from Luke Kenneth Casson Leighton l...@lkcl.net: this is a _very_ strange case where the file contents cannot be read, under msys+wine, but under _just_ wine (cmd.exe) everything goes absolutely fine. by moving Py_Initialize() to _before_ the file load, it works! -- components: Build files: f messages: 79924 nosy: lkcl severity: normal status: open title: Py_Initialize needs to be done before file load (on msys+wine) type: crash versions: Python 2.5 Added file: http://bugs.python.org/file12758/f ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4956 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4880] PyInt_FromSsize_t LONG_MIN and LONG_MAX typecasts needed
New submission from Luke Kenneth Casson Leighton l...@lkcl.net:
there's probably a better way to do this (or a better reason), but
LONG_MIN and LONG_MAX end up as the wrong constant types when compiling
python2.5.2 under wine (don't ask...)
PyObject *
PyInt_FromSsize_t(Py_ssize_t ival)
{
if ((long)ival = (long)LONG_MIN (long)ival = (long)LONG_MAX)
{
return PyInt_FromLong((long)ival);
}
return _PyLong_FromSsize_t(ival);
}
--
messages: 79411
nosy: lkcl
severity: normal
status: open
title: PyInt_FromSsize_t LONG_MIN and LONG_MAX typecasts needed
versions: Python 2.5
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue4880
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4880] PyInt_FromSsize_t LONG_MIN and LONG_MAX typecasts needed
Luke Kenneth Casson Leighton l...@lkcl.net added the comment: oh, duh - 2L not 1L yes you're right :) yeh i believe it's likely to be because in PC/pyconfig.h LONG_MAX is #defined to 7fff not 7fffL i'll double-check. you're right that would make life a looot easier. ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4880 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4880] PyInt_FromSsize_t LONG_MIN and LONG_MAX typecasts needed
Luke Kenneth Casson Leighton l...@lkcl.net added the comment: hmmm... noo, it's already #defined to 0x7fffL in both PC/pyconfig.h _and_ in /usr/include/wine/msvcrt/limits.h so this works (Include/pyports.h) #ifdef __WINE__ /* weird: you have to typecast 0x7fffL to long */ #undef LONG_MAX #undef LONG_MIN #define LONG_MAX ((long)0x7FFFL) #define LONG_MIN ((long)(-LONG_MAX-1)) #else #ifndef LONG_MAX #if SIZEOF_LONG == 4 #define LONG_MAX 0X7FFFL #elif SIZEOF_LONG == 8 #define LONG_MAX 0X7FFFL #else #error could not set LONG_MAX in pyport.h #endif #endif #ifndef LONG_MIN #define LONG_MIN (-LONG_MAX-1) #endif #endif /* __WINE__ */ ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4880 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1597850] Cross compiling patches for MINGW
Luke Kenneth Casson Leighton [EMAIL PROTECTED] added the comment: ok. what's not explained, and isn't clear, is exactly whether you're supposed to - or even _capable_ of - cross-compiling the _entire_ python sourcecode base with mingw32, or whether you're supposed to get _just_ the python.exe interpreter, and, maybe if you're lucky, libpython.a (or libpython.dll - whatever). i got quite a long way, as you can see, in cross-compiling posixmodule.c _by mistake_ - before realising that the whole python sourcecode base is completely inadequately set up for cross-compiling, but is specialised hard-coded to compile python under msvc _only_. so, when doing the cross-compile, it was actually being detected as a _unix_ compile, not a _win32_ compile. #define WIN32 wasn't even being listened to. the end result was that entire areas of posixmodule.c were being compiled when they shouldn't have been. later, i tried to correctly #define WIN32 (or whatever was required), only to find that the mingw32 libraries don't support many of the necessary functions. for example, it's assumed that crypto libraries exist, and many other things. all in all, it didn't go too well :) ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue1597850 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1597850] Cross compiling patches for MINGW
Luke Kenneth Casson Leighton [EMAIL PROTECTED] added the comment: In particular, I think that X-compiling is a common request added another one to the list. justification: pywebkitgtk cross-compiling for win32, using mingw32. i'm not paying for microsoft license fees, i'm not paying for a computer capable of running msvc, i'm not paying for the bandwidth to download msvc and/or set it up. much happier with mingw32, but mingw32 runs like an absolute dog under wine - and often wine_server hangs. (at least a 20x performance hit for running msys and mingw32 under wine). so... that leaves cross-compiling. i need the development libraries from python 2.5 in order to create a windows version of pywebkitgtk. -- nosy: +lkcl ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue1597850 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1597850] Cross compiling patches for MINGW
Luke Kenneth Casson Leighton [EMAIL PROTECTED] added the comment: the cross-compile fails on Parser/acceler.c the reason is because the included file, pyconfig.h, has #define gid_t int for use by the mingw32 compiler, which is... bad! removing gid_t from pyconfig.h bizarrely fixes the compile without.. so far.. any issues ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue1597850 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1597850] Cross compiling patches for MINGW
Luke Kenneth Casson Leighton [EMAIL PROTECTED] added the comment: pyport.h line 773 - commenting out the test for LONG_BIT != 8 * SIZEOF_LONG - we're cross-compiling amd64 host, target mingw32 - 32-bit. ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue1597850 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1597850] Cross compiling patches for MINGW
Luke Kenneth Casson Leighton [EMAIL PROTECTED] added the comment: line 199 of thread_pthread.h and line 221: Python/thread_pthread.h:200: error: aggregate value used where an integer was expected hmmm... maybe this is due to me using mingw32 based on gcc 4.4.4. well, a quick #if 0 seems to fix it :) ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue1597850 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1597850] Cross compiling patches for MINGW
Luke Kenneth Casson Leighton [EMAIL PROTECTED] added the comment: posixmodule.c - line 2328: add this: #if ( defined(__MINGW32__) || defined(__WATCOMC__) || defined(PYCC_VACPP) ) !defined(__QNX__) res = mkdir(path); #else res = mkdir(path, mode); #endif ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue1597850 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1597850] Cross compiling patches for MINGW
Luke Kenneth Casson Leighton [EMAIL PROTECTED] added the comment: posixmodule: line 3530: #ifdef __MINGW32__ master_fd = open(DEV_PTY_FILE, O_RDWR); /* open master */ #else master_fd = open(DEV_PTY_FILE, O_RDWR | O_NOCTTY); /* open master */ #endif not sure i should be compiling posixmodule under mingw32 :) ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue1597850 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1597850] Cross compiling patches for MINGW
Luke Kenneth Casson Leighton [EMAIL PROTECTED] added the comment: line 6193: #if !defined(__MINGW32__) !defined(MS_WINDOWS) defined(HAVE_FCNTL_H) ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue1597850 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
