Skip Montanaro added the comment:
It is executed using the gcc command:
% gcc -c -fno-strict-aliasing -g -O2 -DNDEBUG -g -fwrapv -O3 -Wall
-Wstrict-prototypes -fprofile-generate -I. -IInclude -I./Include
-DPy_BUILD_CORE -o Modules/gcmodule.o Modules/gcmodule.c
clang: warning: argument
Skip Montanaro added the comment:
YACC might be an outlier as well. In any case, it's probably better to use
other common programming languages as a gauge of what's typical. A quick check
of C, C#, C++, Java, Perl, Ruby, and Haskell shows they all list operator
precedence in
Skip Montanaro added the comment:
The latest patch worked fine for me (Mac OS X Yosemite). I've only tried with
2.7 so far. The only thing that was a bit mystifying were the errors during the
initial profile run. There is so much that floats by in the terminal window
that I completely m
Skip Montanaro added the comment:
Not knowing a darn thing about this, I went ahead and made a provisional change
to the README file.
--
Added file: http://bugs.python.org/file40297/README.pgo
___
Python tracker
<http://bugs.python.org/issue24
Changes by Skip Montanaro :
--
nosy: +skip.montanaro
___
Python tracker
<http://bugs.python.org/issue25106>
___
___
Python-bugs-list mailing list
Unsubscribe:
Skip Montanaro added the comment:
This seems to work for me. Diff against default. I have no idea how old the
autoconf setup is here at work. I imagine you'll want to only apply the
configure.ac patch and regenerate configure.
--
keywords: +patch
Added file: http://bugs.pytho
Skip Montanaro added the comment:
Would it be possible to grep out the warning messages, but let everything
else through?
On Sep 19, 2015 1:34 PM, "Brett Cannon" wrote:
>
> Brett Cannon added the comment:
>
> The problem with the output is that error cases are unimporta
Changes by Skip Montanaro :
--
nosy: -skip.montanaro
___
Python tracker
<http://bugs.python.org/issue19475>
___
___
Python-bugs-list mailing list
Unsubscribe:
Skip Montanaro added the comment:
Thanks for the update berker.peksag. I'm still not convinced that the csv
module should be modified just so one user (sorry samwyse) can match the input
format of someone's Java program. It seems a bit like trying to make the csv
module type-sensi
Changes by Skip Montanaro :
--
nosy: -skip.montanaro
___
Python tracker
<http://bugs.python.org/issue10954>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Skip Montanaro :
--
nosy: +skip.montanaro
___
Python tracker
<http://bugs.python.org/issue23659>
___
___
Python-bugs-list mailing list
Unsubscribe:
Skip Montanaro added the comment:
I don't think this is a bug. From the 2.7.9 docs:
The default values used to fill in any missing data when more accurate values
cannot be inferred are (1900, 1, 1, 0, 0, 0, 0, 1, -1).
--
nosy: +skip.mont
Skip Montanaro added the comment:
>>>> time.strptime('2015 3 20 0', '%Y %m %d %w')
> time.struct_time(tm_year=2015, tm_mon=3, tm_mday=20, tm_hour=0, tm_min=0,
> tm_sec=0, tm_wday=6, tm_yday=79, tm_isdst=-1)
>
> All date values are known, the problem i
Skip Montanaro added the comment:
I'm not sure I understand the problem is. You have a list containing four
values, and try to unpack it into five individual objects. There is no element
in the list "data" to assign the name "value".
---
Skip Montanaro added the comment:
I like the idea of the "too many" and "not enough" messages being symmetric. If
it's not too hard, I would prefer them to both identify the number of expected
and received values. I don't have a recent checkout at hand though,
Skip Montanaro added the comment:
I'm completely unqualified to offer a concrete, expert opinion here, but it
seems like defaulting _maxwidth to 1L<<52 should work. I have no idea of the
resulting performance implications though.
>>> for bpf in (45, 46, 47, 48
Skip Montanaro added the comment:
Any chance this will make it into 3.5? It's not a big deal, but I notice that
it's still present in 3.5.0a4.
--
___
Python tracker
<http://bugs.python.o
Skip Montanaro added the comment:
On Tue, Apr 21, 2015 at 2:56 PM, Larry Hastings wrote:
> Issac doesn't have commit bit...
>
> ... but you do.
Alas, my commit bit long ago fell into disuse. I haven't checked
anything in since long before the days of Mercurial and the curren
Skip Montanaro added the comment:
Can you provide a trimmed down example which provokes the segmentation fault?
--
nosy: +skip.montanaro
___
Python tracker
<http://bugs.python.org/issue24
Skip Montanaro added the comment:
> It's confusing that the CFLAGS specified when running make are passed further
> sometimes but not always. So I guess that's a workaround? Or CFLAGS should
> never be specified to make directly?
In my experience, all the magic happens in
New submission from Skip Montanaro:
I was hunting around the current website for notes on installing Python.
Couldn't find any (BTW), so I looked in the Python source. Imagine my surprise
to find two apparently overlapping files describing how to build Python modules:
./Doc/install/inde
Skip Montanaro added the comment:
Can you attach your cab file so we don't need to reconstruct it (and possibly
make a mistake) by reading your program's output?
--
nosy: +skip.montanaro
___
Python tracker
<http://bugs.python.o
Skip Montanaro added the comment:
Sorry, failed to override my phone's spell correction. "cab" should be
"csv".
--
___
Python tracker
<http:
New submission from Skip Montanaro:
Got this reproducibly on the cpython branch on my Mac (Yosemite 10.10.3). It
succeeds on my 3.4 branch, both updated a few minutes ago. Didn't see it
already reported:
% ./python.exe Lib/test/test_os.py
s..sss.
Skip Montanaro added the comment:
I looked at this six years ago. I still haven't found a situation where I pined
for a NamedTupleReader. That said, I have no objection to committing it if
others, more well-versed in current Python code and NamedTuples than I gives it
a pass. Note t
Skip Montanaro added the comment:
Sorry for the delay. With LANG=C I get this extra bit of output:
'this test triggers the Crash Reporter, that is intentional\x80TbG=\x0f\x19t'
With LANG=en_US.UTF-8 (the encoding of my Terminal instance), I get this:
'this test triggers the
Skip Montanaro added the comment:
> OK, that explains the failure. You must have set the OS X crash reporter
default to "Developer" mode on that machine at some point.
Thanks. I certainly don't remember doing anything like that. (I'm not a Mac
user at such a sophisticated
Skip Montanaro added the comment:
In your Mon class, you've left the doublequote parameter unset (it defaults to
None). It completely overrides the default dialect. When no Dialect class is
given, the default is csv.excel. Note that doublequote is set to True in
csv.excel. In your s
Skip Montanaro added the comment:
The defaults for the Dialect class are documented:
https://docs.python.org/2/library/csv.html#dialects-and-formatting-parameters
I think the problem is mostly that csv.Dialect must be subclassed. You can't
use it directly, and if you subclass it as Mi
Skip Montanaro added the comment:
Also, a change in behavior has to be very carefully considered, even
though it passes all existing test cases (and presumably the one(s)
you'll add). The change may well only be acceptable for the next minor
release of 3.x.
On Mon, Sep 5, 2016 at 7:
Skip Montanaro added the comment:
Not relevant to me.
On Sep 8, 2016 5:45 PM, "Christian Heimes" wrote:
>
> Christian Heimes added the comment:
>
> Can we close the ticket or is it still relevant?
>
> --
> nosy: +christian.h
New submission from Skip Montanaro:
Just trying an infrequent update of tip (last time seems to have been early
July), I get a link error on my Mac:
% make
./Programs/_freeze_importlib \
./Lib/importlib/_bootstrap.py Python/importlib.h
dyld: lazy symbol binding failed: Symbol not
Changes by Skip Montanaro :
--
title: cpython tip fails to build on Mac OS X -> cpython tip fails to build on
Mac OS X 10.11.6 w/ XCode 8.0
___
Python tracker
<http://bugs.python.org/issu
Skip Montanaro added the comment:
Thanks, Ned. Unintuitive though it may be, that seems to have done the trick.
--
___
Python tracker
<http://bugs.python.org/issue28
New submission from Skip Montanaro:
Unless I have my hg repo dependencies incorrect, this target seems to be
missing from the 2.7 Makefile.pre.in:
# This is shared by the math and cmath modules
Modules/_math.o: Modules/_math.c Modules/_math.h
$(CC) -c $(CCSHARED) $(PY_CORE_CFLAGS) -o
Skip Montanaro added the comment:
Is this perhaps related to the (closed) issue 24421?
--
___
Python tracker
<http://bugs.python.org/issue28487>
___
___
Python-bug
Skip Montanaro added the comment:
I'm not sure you understood my problem. Starting with
make distclean
./configure
make
the math and cmath modules fail to build because Modules/_math.o is
missing. It's not a make thing. I did notice the cpython Makefile has a
target for Modules/_
Skip Montanaro added the comment:
The problem is solved. It seems there were changes in my 2.7 checkout which hg
update wouldn't overwrite. I vaguely remember applying somebody's patch for a
bug quite awhile ago. Apparently, I failed to revert that change before moving
on.
I obviou
801 - 838 of 838 matches
Mail list logo
