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.py
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
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
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)
--
___
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
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 hig
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 (
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 de
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/issue34
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:
(
"\(")
--
___
Py
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
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 wa
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
signific
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
Luke Kenneth Casson Leighton 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, bu
Luke Kenneth Casson Leighton 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 ti
Luke Kenneth Casson Leighton 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
Luke Kenneth Casson Leighton 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,
Luke Kenneth Casson Leighton 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
Luke Kenneth Casson Leighton 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 c
Luke Kenneth Casson Leighton 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
Luke Kenneth Casson Leighton 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
Luke Kenneth Casson Leighton 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
Luke Kenneth Casson Leighton 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 free
Luke Kenneth Casson Leighton 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
<http://bugs.python.org/issue3
Luke Kenneth Casson Leighton 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 free
Luke Kenneth Casson Leighton 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 reaso
Luke Kenneth Casson Leighton added the comment:
On Sun, Aug 8, 2010 at 12:27 AM, Éric Araujo wrote:
>
> Éric Araujo 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 bu
Luke Kenneth Casson Leighton added the comment:
On Mon, Feb 2, 2009 at 9:10 PM, Roumen Petrov wrote:
>
> Roumen Petrov 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 i
Luke Kenneth Casson Leighton 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
New submission from Luke Kenneth Casson Leighton :
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
New submission from Luke Kenneth Casson Leighton :
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 _every
New submission from Luke Kenneth Casson Leighton :
class EnvironTests(mapping_tests.BasicTestMappingProtocol):
"""check that os.environ object conform to mapping protocol"""
type2test = None
def _reference(self):
return {"KEY1":&
Luke Kenneth Casson Leighton added the comment:
#5046 supercedes this patch, for python2.7. still relevant
for python2.5 though.
___
Python tracker
<http://bugs.python.org/issue5
New submission from Luke Kenneth Casson Leighton :
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
New submission from Luke Kenneth Casson Leighton :
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:
ms
Luke Kenneth Casson Leighton 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 foc
Luke Kenneth Casson Leighton 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
Luke Kenneth Casson Leighton added the comment:
manifests and rc files for msvcr80 build
Added file: http://bugs.python.org/file12830/x
___
Python tracker
<http://bugs.python.org/issue4
Luke Kenneth Casson Leighton added the comment:
attached also manifests and rc files for building on msvcr80
Added file: http://bugs.python.org/file12829/x
___
Python tracker
<http://bugs.python.org/issue5
Luke Kenneth Casson Leighton 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
New submission from Luke Kenneth Casson Leighton :
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
Luke Kenneth Casson Leighton added the comment:
updated. incorporating roumen's work as well.
Added file: http://bugs.python.org/file12826/f
___
Python tracker
<http://bugs.python.org/i
Luke Kenneth Casson Leighton 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
New submission from Luke Kenneth Casson Leighton :
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
Changes by Luke Kenneth Casson Leighton :
Removed file: http://bugs.python.org/file12764/x
___
Python tracker
<http://bugs.python.org/issue4954>
___
___
Python-bugs-list m
Luke Kenneth Casson Leighton 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
<http://bugs.python.org/issue4
New submission from Luke Kenneth Casson Leighton :
the assumption is made that the result will fit into a PyInt.
obviously, on a 32-bit system, where SIZEOF_LONG is 4 bytes,
that ain't happening.
a complex test would be something like this:
if len <= 9: it's an int, definitely
Luke Kenneth Casson Leighton 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'
Luke Kenneth Casson Leighton 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'
Luke Kenneth Casson Leighton added the comment:
http://www.winehq.org/pipermail/wine-users/2006-May/021624.html
_drat_.
a rebuild of wine, adding a workaround to cope with lack of
support for msvcrt80 xml-based process files, is required,
commenting out a couple of functions from kernel32
Luke Kenneth Casson Leighton 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_s
Luke Kenneth Casson Leighton 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'
Luke Kenneth Casson Leighton 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
Luke Kenneth Casson Leighton 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 :)
___
Pytho
Luke Kenneth Casson Leighton 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
Changes by Luke Kenneth Casson Leighton :
Removed file: http://bugs.python.org/file12758/f
___
Python tracker
<http://bugs.python.org/issue4956>
___
___
Python-bugs-list m
Changes by Luke Kenneth Casson Leighton :
Removed file: http://bugs.python.org/file12755/f
___
Python tracker
<http://bugs.python.org/issue4954>
___
___
Python-bugs-list m
Luke Kenneth Casson Leighton 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 th
Luke Kenneth Casson Leighton 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 propr
Luke Kenneth Casson Leighton 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
Luke Kenneth Casson Leighton 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/file12
Luke Kenneth Casson Leighton added the comment:
here's another clue:
$ ./python.exe
stdin_is_interactive: 0
___
Python tracker
<http://bugs.python.org/issue4956>
___
___
Luke Kenneth Casson Leighton 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.
&g
Luke Kenneth Casson Leighton 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 goi
New submission from Luke Kenneth Casson Leighton :
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
Changes by Luke Kenneth Casson Leighton :
--
type: -> feature request
___
Python tracker
<http://bugs.python.org/issue4954>
___
___
Python-bugs-list mai
New submission from Luke Kenneth Casson Leighton :
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
Changes by Luke Kenneth Casson Leighton :
--
nosy: +lkcl
___
Python tracker
<http://bugs.python.org/issue3871>
___
___
Python-bugs-list mailing list
Unsubscribe:
Luke Kenneth Casson Leighton 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 LON
Luke Kenneth Casson Leighton 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
New submission from Luke Kenneth Casson Leighton :
messy patches which get python 2.5.2 compiling - and producing
python.exe.so - under wine.
the setup.py is presently _wholly_ unsuited to use for building
the modules - get_sysconfig("srcdir") returns None because...
it's suppose
New submission from Luke Kenneth Casson Leighton :
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 (
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
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
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 com
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,
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 se
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 PRO
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 biz
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'
Luke Kenneth Casson Leighton <[EMAIL PROTECTED]> added the comment:
finally! i accidentally found this, when looking for my own work for
yet another project that requires this split.
comments - several
1) the patch was relevant in 2001 at the time of creation; it was
relevant for pyth
82 matches
Mail list logo
