Ronald Oussoren added the comment:
Ned: do you have time to backport this to 3.2 and 2.7?
Also, the code might not be entirely correct for all machines: on my machine
'gcc-4.2' still exists in /usr/bin but doesn't work because the actual compiler
(/usr/bin/i686-apple-darwin11-g
Ronald Oussoren added the comment:
OSX Server should have the same kernel as the client.
Also, the license terms for OSX 10.6 client don't allow running in a VM, while
the 10.6 server terms do allow that.
Is there anything special about this buildbots system configuration? Is the
files
Ronald Oussoren added the comment:
The logical location for installing and embedded Tcl/Tk is either in
{sys.prefix}/lib (for a unix install of Tk) or in
Python.framework/Versions/X.Y/Frameworks (for a Tcl/Tk framework install).
In either case Tcl/Tk would be installed *inside
Ronald Oussoren added the comment:
It would be nice to have a simple self-contained example, especially one that
could be converted to a testcase later on.
Using the pysvn workbench should be good enough to find the problem though
(assuming it is open source). Is there a download URL for
Ronald Oussoren added the comment:
BTW. bundlebuilder is deprecated and is no longer present in py3k.
Also: IDLE.app for python 2.7 is build using bundlebuilder, and that app works
just fine.
--
___
Python tracker
<http://bugs.python.
Ronald Oussoren added the comment:
Test_tools passes for me with the tip of the default branch and
BUILDDIR!=SRCDIR.
I'm currently running a 2.7 test run, but AFAIK this issue is fixed.
--
___
Python tracker
<http://bugs.python.org/is
Ronald Oussoren added the comment:
2.7 works as well.
Roumen: what doesn't work and how can we reproduce that?
--
resolution: -> fixed
stage: needs patch -> committed/rejected
status: open -> pending
___
Python tracker
<http:
Ronald Oussoren added the comment:
It probably works because IDLE.app only uses the stdlib (that is, anything
imported from the main script is in the stdlib)
The bundlebuilder call for IDLE.app:
$(RUNSHARED) @ARCH_RUN_32BIT@ $(BUILDPYTHON) $(BUNDLEBULDER) \
--builddir
Ronald Oussoren added the comment:
The patch can cause problems when either DYLD_LIBRARY_PATH or the current
working directory contains whitepace, a better fix is:
RUNSHARED=DYLD_LIBRARY_PATH="`pwd`:${DYLD_LIBRARY_PATH}"
(That is, replace the single quotes by double quotes)
-
Ronald Oussoren added the comment:
> Hynek Schlawack added the comment:
>
> $(pwd)
I'd usually agree, but this is a configure script and those shouldn't contain
shell features invented after 1970 :-)
More seriously, a large subset of command interpolations in configur
Ronald Oussoren added the comment:
On 31 Dec, 2012, at 15:59, Fabian Groffen wrote:
>
> Fabian Groffen added the comment:
>
> re: single quotes -> double quotes
>
> I made RUNSHARED consistent (although, as you point out, less broken) with
> the other RUNSHARED assi
New submission from Ronald Oussoren:
On OSX 10.8 with the following configure line and a fresh checkout (as of 10
minutes ago):
'../configure' '--enable-framework'
'--enable-universalsdk=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Deve
Ronald Oussoren added the comment:
That's quick, thank :-).
--
___
Python tracker
<http://bugs.python.org/issue16847>
___
___
Python-bugs-list mailing list
Ronald Oussoren added the comment:
Using '-framework Python' is suboptimal because this doesn't control which
framework is used for linking (in particular, if you have both Python 2.7 and
3.3 installed '-framework Python' will link against the one installed las
Ronald Oussoren added the comment:
There are tests for samefile and sameopenfile in test_genericpath.GenericTest
which is included by test_ntpath (NtCommonTest subclasses
test_genericpath.CommonTest which again subclasses GenericTest).
I cannot easily test on Windows (the only windows systems
New submission from Ronald Oussoren:
If a class implements __dir__ to also return a number of attributes that aren't
present in the class __dict__ inspect.classify_class_attrs gets confused and
assumes the home class is None.
This in turn confused pydoc, docclass in pydoc assumes tha
Ronald Oussoren added the comment:
I appear to be running into this as well in py2app, with the current 2.7 tree
and a --enable-shared build py2app's updates to the environment (with setenv
from C code) won't be seen by Python, even though Python is initialized after
the call to se
Ronald Oussoren added the comment:
Would it be possible, and sane, to enforce a minimal delay on OSX? That is,
code that automaticly ensures that the delay has some minimal value.
Or does the required delay depend on what you are doing?
--
nosy: +ronaldoussoren
Ronald Oussoren added the comment:
The patch didn't work for me because I manually applied and missed a bit. The
patches fixes <https://bitbucket.org/ronaldoussoren/py2app/issue/81> for me,
and the environ(7) manpage also indicates that the call to _NSEnvironment is
needed in share
Changes by Ronald Oussoren :
Added file: http://bugs.python.org/file28726/1602133.patch
___
Python tracker
<http://bugs.python.org/issue1602133>
___
___
Python-bugs-list m
Ronald Oussoren added the comment:
tp_cache and tp_weaklist are also for internal use only, but are documented.
One reason for documenting them is that users will run into them when running
with a high enough warning level in GCC.
--
nosy: +ronaldoussoren
Changes by Ronald Oussoren :
--
stage: commit review -> committed/rejected
status: open -> closed
type: -> behavior
___
Python tracker
<http://bugs.python.org/
New submission from Ronald Oussoren:
pydoc currently uses inspect.getfullargspec to determine the signature of a
callable when rendering its documentation. It should use inspect.signature
instead because that function can work with callables that aren't python
functions or methods.
Cha
Ronald Oussoren added the comment:
The attached patch is a very rough prototype which seems to work (but wasn't
tested beyond running pydoc on a number of function(-like) objects.
With the patch the documentation for a callable defined in C but with a
__signature__ property shows arg
Ronald Oussoren added the comment:
I'm not sure if it is worthwhile to switch right now. Apple does deprecate the
use of OpenSSL, but there version does offer a feature that's not in the
default tree: it verifies SSL certificates against the CA list in the system
keychain.
Ronald Oussoren added the comment:
Replacing openssl by the supported crypto api's is something for 3.4 or even
3.5.
There is a way to keep the current functionality while still shipping a build
of openssl: apply the patch that implements the feature to the upstream version
when buildi
Ronald Oussoren added the comment:
I've once again reviewed the _scproxy code and that code seems correct
(although that doesn't say too much for subtle bugs because I wrote the initial
version of the module).
Dan: is it possible to tell moviegrabber to use another python instal
Ronald Oussoren added the comment:
If it is the moviegrabber I linked to: that's a 100% python script using some
other opensource libraries.
It does use multiprocessing, and that might mean this is the same problem as
issue9405. That issue should be fixed in the repository (for a long
Ronald Oussoren added the comment:
This is an alternate patch, it replaces the PyObject_INIT and PyObject_INIT_VAR
macros by inline functions with macro wrappers for compatibility (the macros
are used to suppress type warnings).
I don't particularly like my patch, but it might be a bette
Ronald Oussoren added the comment:
It doesn't raise an exception on OSX (close to the tip of the default branch),
both for http://www.google.com/ and https://www.google.com/
--
___
Python tracker
<http://bugs.python.org/is
Ronald Oussoren added the comment:
I don't know how the main copy of libffi in the CPython tree is updated, and if
it is a straight copy of the upstream release. Given the mercurial log I'd
guess that Modules/_ctypes/libffi is libffi 3.0.11 with a small patch in
Modules/_ctypes/l
Ronald Oussoren added the comment:
Matthias: libffi_osx already contains the workaround you refer to.
libffi_osx is the same as the variant of libffi included with PyObjC, and that
is derived from the system libffi on OSX (IIRC the last time I merged their
changes was around 10.7).
The
Ronald Oussoren added the comment:
See also: issue 15740
A version of OpenSSL as included in some versions of OSX can be downloaded from
<http://opensource.apple.com/tarballs/OpenSSL098/>, as mentioned in issue 15740
the versions as included in the most recent OS updates doesn't
Ronald Oussoren added the comment:
I've closed the issue because I can no longer reproduce the issue, the
changesets mentioned by Ned have fixed the problem.
--
status: pending -> closed
___
Python tracker
<http://bugs.python.org
Ronald Oussoren added the comment:
What other problems? Do you have more information on that?
--
___
Python tracker
<http://bugs.python.org/issue17128>
___
___
Ronald Oussoren added the comment:
libffi_osx is not a copy of the regular libffi, but a (fairly old) fork. I
don't know how far the two "branches" have diverged.
An important feature of liffi_osx is that is compiles cleanly when all intel
and ppc related sources are compi
Changes by Ronald Oussoren :
--
nosy: +ronaldoussoren
___
Python tracker
<http://bugs.python.org/issue19019>
___
___
Python-bugs-list mailing list
Unsubscribe:
Ronald Oussoren added the comment:
I'd really like to include this patch in 3.4, but haven't managed to do any
opensource work in the previous period and don't know when I'll be able to
actually commit this (and more importantly, be available
Ronald Oussoren added the comment:
A problem with __objclass__ is that it is undocumented other than in PEP 252.
That why I called it a workaround, at the time I created this issue I had just
found the problem and workaround and as far as I knew __objclass__ was an
undocumented feature of
Changes by Ronald Oussoren :
--
nosy: +ronaldoussoren
___
Python tracker
<http://bugs.python.org/issue19219>
___
___
Python-bugs-list mailing list
Unsubscribe:
Ronald Oussoren added the comment:
I don't think you can provide a solution that's compatible with existing
3th-party extensions that use Tk and includes a private copy of Tcl/Tk.
IMHO the best solution would be to provide the Tcl/Tk headers in the Python
framework as well,
Ronald Oussoren added the comment:
AFAIK this still is a problem, although as Brett mentioned you have to do some
work to end up with a non-functional install.
I ran into this in the context of py2app, that output of py2app basically
contains a "portable" python installation and
Ronald Oussoren added the comment:
I for the most part agree with the comments and will provide an updated patch
on thursday. Would you mind if I committed that without further review (due to
cutting it awfully close to the deadline for beta 1)?
Some comments I want to reply to specifically
Ronald Oussoren added the comment:
I've attached an updated version of the patch that should fix most of the
issues found during review.
I've also changed the two FMT_ constants to an enum.Enum (but still expose the
constants themselves as module global names because that&#
Ronald Oussoren added the comment:
Following the instruction in the log message would also be useful, that is, in
a shell window:
$ env CA_DEBUG_TRANSACTIONS=1 /Applications/Python\
2.7/IDLE.app/Contents/MacOS/IDLE
With some luck the stack trace will point to the source of the problem. As
Ronald Oussoren added the comment:
Updated patch after next round of reviews.
--
Added file: http://bugs.python.org/file32754/issue-14455-v10.txt
___
Python tracker
<http://bugs.python.org/issue14
Ronald Oussoren added the comment:
That's quick... The patch fixes the issue for me as well.
Thanks!
--
resolution: -> fixed
stage: needs patch -> commit review
status: open -> closed
___
Python tracker
<http://bugs.pyth
New submission from Ronald Oussoren:
I get a compilation error for _ssl when building on OSX 10.9 using the 10.9
SDK, the relevant error:
/Users/ronald/Projects/python/rw/default/Modules/_ssl.c:1029:24: error: no
member named 'crldp' in 'struct x509_st'
dps
New submission from Ronald Oussoren:
To reproduce:
* create a package with the following structure:
pkg/
__init__.py
_sub.py
* __init__.py contains:
from pkg._sub import *
* the contents of _sub.py is not important
* in a python shell do:
>>> import pkg.
Ronald Oussoren added the comment:
oops... thanks for the patch. I'll review later this week, in particular the
128 bit integer support because I don't know if Apple's libraries support those.
--
___
Python tracker
<http
Ronald Oussoren added the comment:
> On 19 jul. 2014, at 23:22, Mark Dickinson wrote:
>
>
> Mark Dickinson added the comment:
>
> The relevant piece of code in the struct module looks like this:
>
> static PyObject *
> nu_bool(const char *p, const formatd
Ronald Oussoren added the comment:
> On 20 jul. 2014, at 10:32, Mark Dickinson wrote:
>
>
> Mark Dickinson added the comment:
>
>> In practice, I doubt that Python's going to meet such platforms in a hurry.
>
> Hrm; looks like that's not a particul
Ronald Oussoren added the comment:
I just confirmed that clang only uses the LSB for _Bool values by looking at
the assembly generated for the following code:
#include
#include
int main(void)
{
_Bool x;
*(unsigned char*)&x = 42;
printf("%d\n
Ronald Oussoren added the comment:
The last draf of ISO C '11:
<http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf>.
This says that _Bool is large enough to store 0 and 1, and that conversion of
any integer data to _Bool results in 0 or 1. If I interpret the document
corr
Ronald Oussoren added the comment:
Sure... The issue is still present. To demonstrate the problem:
arch -i386 ./python.exe
Python 3.5.0a0 (default:9b450b19aa11+, Jul 21 2014, 10:03:38)
[GCC 4.2.1 Compatible Apple LLVM 5.1 (clang-503.0.40)] on darwin
Type "help", "copyright
Ronald Oussoren added the comment:
The attached patch (for the default branch) adds information about the unit of
maxrss to the documentation, and removes the sentences about calculating the
total memory size from the getpagesize documentation.
--
assignee: ronaldoussoren
Ronald Oussoren added the comment:
Does anyone have feedback for my proposed patch (other the bug in test code
when sizeof(bool) != 1, the test values for big and little endian are in the
wrong order)?
--
___
Python tracker
<h
Changes by Ronald Oussoren :
--
versions: +Python 3.5 -Python 3.3
___
Python tracker
<http://bugs.python.org/issue15730>
___
___
Python-bugs-list mailin
Ronald Oussoren added the comment:
The use of context lib in _read_output should not be necessary anymore as file
objects and NamedTemporaryFile objects already are context managers with the
right semantics.
I'm not sure how to avoid the import of tempfile other than adding a mi
Ronald Oussoren added the comment:
I'd be in favour of closing this issue, I haven't seen the problem in a while
and it is almost certainly due to a platform bug on OSX 10.6.
--
___
Python tracker
<http://bugs.python.o
Ronald Oussoren added the comment:
There'd still need to be some way to update the shell environment, but I agree
that there needs to be something better than we have now.
One option is to add a small shell script that can be sourced from the shell
profile and adds the various p
Ronald Oussoren added the comment:
The issue still is present, wouldn't it be better to just remove the
availability annotation from the docs (2.7, 3.4 and trunk) while waiting for a
better solution?
That would at least remove confusion for these docs. At the very least the
"
Ronald Oussoren added the comment:
I don't have a better solution for this, although I'd slightly prefer to add a
hack to the turtledemo main function to force itself to the foreground on
startup. That way the hack also works when the user starts the script in a
Termi
Ronald Oussoren added the comment:
BTW. There is also an argument to be made against my patch and for a
documentation update: it is unclear to me if clang ever creates _Bool false
values where the bit pattern isn't exactly the same as the zero value of an
integer of the same size (for ex
Changes by Ronald Oussoren :
--
assignee: ronaldoussoren ->
components: -Macintosh
nosy: -ronaldoussoren
___
Python tracker
<http://bugs.python.org/issu
Ronald Oussoren added the comment:
OSX returns a strange value in os.listdir because the HFS+ filesystem itself
has unicode filenames and transforms byte strings that are assumed to contain
UTF-8 into something the filesystem can handle (and seems to replace bytes that
aren't valid UTF-8
Ronald Oussoren added the comment:
I'm not convinced that this is a bug in python. __PYVENV_LAUNCHER__ is an
implementation detail of CPython used in the implementation of the pyvenv
functionality.
I consider using this undocumented environment variable in distlib as a bug in
distlib,
Ronald Oussoren added the comment:
> On 25 sep. 2014, at 19:58, Ronald Oussoren wrote:
>
>
> Ronald Oussoren added the comment:
>
> I consider using this undocumented environment variable in distlib as a bug
> in distlib, which should be fixed
Speaking of whic
New submission from Ronald Oussoren:
When you build python 2.7 on an OSX 10.9 machine with Xcode but without the
command-line tools installed that build mostly succeeds, but doesn't detect a
number of dependencies (in particular zlib).
The attached patch teaches "add_dir_to_list&
New submission from Ronald Oussoren:
When you build python on an OSX 10.9 machine with Xcode but without the
command-line tools installed that build mostly succeeds, but Tkinter fails to
build.
The following error message is from a 2.7 build, but the same problem occurs
when building 3.3 and
Ronald Oussoren added the comment:
I'm working on an update for your patch that addresses these comments:
* I don't like supporting 128 bit integers because Apple's public APIs
don't support those values. That is, the value 'kCFNumberSInt128Type'
is not in a
Ronald Oussoren added the comment:
The attached patch should fix the open issues:
* Negative integers are supported (based on Serhiy's patch), but without
support for 128-bit integer (as per my previous comment)
* Test updates for this
* Updated version tags in the document
Ronald Oussoren added the comment:
Attached a script (using PyObjC) that demonstrates the behavior of Apple's
Foundation framework with large integers. The same behavior should occur when
the script is rewritten in Objective-C.
--
Added file:
http://bugs.python.org/file33206/
Ronald Oussoren added the comment:
Updated patch.
--
Added file: http://bugs.python.org/file33207/negative_int_support-2.txt
___
Python tracker
<http://bugs.python.org/issue14
Changes by Ronald Oussoren :
--
keywords: +needs review, patch
stage: -> patch review
___
Python tracker
<http://bugs.python.org/issue20022>
___
___
Python-
Ronald Oussoren added the comment:
Removing bundle builder should be easy enough if it is only used to create the
PythonLauncher application bundle: that bundle does not contain python code at
all and constructing it is just a matter of copying files to the right location.
The attached patch
Ronald Oussoren added the comment:
Conversion to XML results in:
$ plutil -convert xml1 -o - 18446744073709551615.plist
http://www.apple.com/DTDs/PropertyList-1.0.dtd";>
a
18446744073709551615
This is the same as what I get with my latest patch:
>>>
Changes by Ronald Oussoren :
--
nosy: +ronaldoussoren
___
Python tracker
<http://bugs.python.org/issue20078>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Ronald Oussoren :
--
resolution: -> fixed
stage: patch review -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.or
Ronald Oussoren added the comment:
However, I have no idea how to write that file using Apple's APIs.
I'd prefer to either be compatible with Apple's API (current behavior), or just
outright reject values that cannot be represented as a 64-bit signed integer.
The file you ge
Ronald Oussoren added the comment:
kCFNumberSInt128Type is not public API, see the list of number types in
<https://developer.apple.com/library/mac/documentation/corefoundation/Reference/CFNumberRef/Reference/reference.html>.
I agree that CFBinaryPlist.c contains support for those, a
Ronald Oussoren added the comment:
Reopening because Cocoa behaves differently that I had noticed earlier...
The (Objective-C) code below serialises an NSDictionary with an unsigned long
of value ULLONG_MAX and then reads it back. I had expected that restored value
contained a negative number
Ronald Oussoren added the comment:
The big question is why ctypes uses RTLD_NOW in the first place. There's
probably a good reason for it because it's added unconditionally to the user
provided flags.
BTW. I'd prefer to keep the dlopen flags on OSX the same as on other plat
Ronald Oussoren added the comment:
As I wrote in msg116385 I'd prefer to drop the consistency check completely
because updating data like the filename in the central directory is a cheap way
to rename files without completely rewriting the zip
Ronald Oussoren added the comment:
I just ran into this problem myself.
On fresh installs of OSX 10.9 LC_CTYPE is set to "UTF-8" (at least for english
language users), and now sphinx won't work :-(
Is Dimitrys patch acceptable (either as is, or with my suggestion o
Ronald Oussoren added the comment:
Serhiy: the issue should now be fixed.
I finally understand why I was so sure that Apple's code serialised large
positive numbers as negative numbers: due to a bug in PyObjC large positive
numbers end up as NSNumber values that are interpreted as neg
Ronald Oussoren added the comment:
Why is _call_external_zip needed at all? The code says it is used when the
zipfile module is not available, but that module is part of the stdlib and
should always be available.
--
nosy: +ronaldoussoren
___
Python
Changes by Ronald Oussoren :
--
nosy: +ronaldoussoren
___
Python tracker
<http://bugs.python.org/issue20581>
___
___
Python-bugs-list mailing list
Unsubscribe:
Ronald Oussoren added the comment:
AFAIK OpenSSL has hooks that can be called when a certificate needs to be
validated. If I my memory is correct this could be used to validate
certificates using a public API (basically doing the same as Apple's patch, but
using public APIs for the syste
Ronald Oussoren added the comment:
keflavich: Please open a new issue for the problem you are running in, it
is a completely seperate issue than the one you appended your message to.
Where can I download a 64-bit capable version of Tcl/Tk?
BTW. The correct fix would be to add a probe to
Ronald Oussoren added the comment:
Adam: where can I download a 64-bit version of Tcl/Tk?
--
___
Python tracker
<http://bugs.python.org/issue6441>
___
___
Pytho
Ronald Oussoren added the comment:
The manpage says that nl_langinfo returns an empty string when there is
an invalid setting.
There is validity in saying that 'LANG=utf-8' is an invalid setting, the
LANG variable is supposed to a locale name, which would be a language
setting
Ronald Oussoren added the comment:
The attached patch (issue6393-fix.patch) seems to fix the issue.
Could you please test and have a look at the patch? It basicly tests if
the output of nl_langinfo(CODESET) is the empty string and defaults to
'UTF-8' in that case (but only on OSX).
Ronald Oussoren added the comment:
Good catch, the code in the else is indeed in the wrong order.
--
___
Python tracker
<http://bugs.python.org/issue6
Ronald Oussoren added the comment:
At the very least PythonLauncher should not be the default for opening
python files, and should actively warn against being the default
(basicly reversing the current default).
When PythonLauncher is the default application for .py files double-
clicking a
Ronald Oussoren added the comment:
The issue with execv seems to be resolved on OSX 10.6, and hence the
problem will go away by itself in the future.
But until OSX 10.5 and earlier have died of this is a valid issue.
My gut feeling is that I'm -1 on killing all threads in os.execv be
Ronald Oussoren added the comment:
The default value for the -arch flag changed in SL. It used to be the
same as the output of the arch command (i386 on intel systems) and now
is x86-64.
I'll create a patch for configure to automaticly detect the right value.
As a workaround you can
Ronald Oussoren added the comment:
The attached patch (configure-in-sl.patch) fixes the build issue on SL,
I haven't committed the patch yet because it needs testing on 10.5/10.4.
NOTE: the patch touches configure.in without also patching configure.
Therefore you need to run 'autoc
Ronald Oussoren added the comment:
My current plan is to fix this issue, and the issue of 64-bit universal
builds on SL in the weekend.
BTW. I'm not planning to fix this for 2.5 and 2.4, AFAIK both are no
maintained beyond critical security pa
New submission from Ronald Oussoren :
Note: this is mostly a reminder for myself to clean up the pythonw stub
executable
The current implementation of pythonw on OSX uses exec to start an
executable inside the framework, this is needed to be able to use GUI
functionality from the command
1701 - 1800 of 2445 matches
Mail list logo
