You can also attach gdb to a running (python) process .. but the
interpreter needs to have the symbol table (eg. not stripped).
I gave a presentation few years back on this exact topic (sorry for the
quality, I was very in-experienced).
I tried a Makefile based build of python (+ some module) in the past for
Android (and macos):
https://bitbucket.org/cavallo71/android
There was no particular problem in dropping autoconfigure+setup.py in the process: the only real problem was the pgen must be
compiled on the host machine
). It's very similar and I'll post more details
when ready.
I hope this helps,
Thnaks
Antonio Cavallo wrote:
Setting up a repo with the code and cleaning a bit here and there.
Over the weekend I can put something useable.
Nick Coghlan wrote:
On 4 September 2014 18:50, A. Cavalloa.cava
2014 11:07, Antonio Cavallo a.cava...@cavallinux.eu
wrote:
I wonder if there is any interest in starting to use the opensuse
build
servers for continuous build and testing on redhat, fedora suse and
(I
think) debian: that will solve once for all the maintenance issues on
those
platforms
Setting up a repo with the code and cleaning a bit here and there.
Over the weekend I can put something useable.
Nick Coghlan wrote:
On 4 September 2014 18:50, A. Cavalloa.cava...@cavallinux.eu wrote:
Yes there are details indeed. But not show stoppers. A prototype can be
seen here:
I wonder if there is any interest in starting to use the opensuse build
servers for continuous build and testing on redhat, fedora suse and (I
think) debian: that will solve once for all the maintenance issues on
those platforms (and provide a reliable build).
Regards,
Antonio
I have a little pet project for building rpm of python 2.7 (it should be
trivial to port to 3.x):
https://build.opensuse.org/project/show/home:cavallo71:opt-python-modules
If there's enough interest I can help to integrate with python.org.
I understand there may be technical challenges with
Yes that is indeed a great news.
Having to debug some binary only extension modules that will make my (rather
selfish) life so much easier ;)
Thanks
On 7 Jul 2013, at 00:04, Victor Stinner victor.stin...@gmail.com wrote:
2013/7/6 Antonio Cavallo a.cava...@cavallinux.eu:
Could that remove
Could that remove the need for the --with-pydebug flag?
On 6 Jul 2013, at 21:54, Antoine Pitrou solip...@pitrou.net wrote:
Hello,
I'm accepting PEP 445 (A C API to customize memory allocators) by
Victor. There is probably some grammar to correct here and there
(neither Victor nor I
How would that work? How could hg purge the .bak, .orig, .rej, .old,
etc. files?
hg purge (it's an extension) removes anything that isn't tracked (and
not ignored in the .hgignore): kind of distclean.
I hope this helps
___
Python-Dev mailing list
*~, .orig, .rej, .back should be kept. They are not generated by
configure nor make.
Ideally they should be left untracked not ignored.
While devs can certainly add them to the .hgignore list to make life
easier, a repository should be clean of extra files (or shown as
untracked).
I'd add
What's the advantage in writing a new build tool? I'm asking this because I'm
doing the same using scons:
https://bitbucket.org/cavallo71/fatpython
At the moment I'm very interested into this problem: the main advantages I see
so far are (in scons) are node dependencies and the fact it is
What's the stack trace?
$ gdb --args ./python.exe -Wd -m test.regrtest test_exceptions
and once in gdb:
gdb bt
That should point on where it happened.
I hope this help
On 2013-05-30 13:08, Łukasz Langa wrote:
This happens after Benjamin's changes in 83937. Anybody else seeing
this?
As part of those changes, I've cleaned up a few aspects of the repo
layout:
* moved the main executable source file from Modules to a separate
Apps directory
Do you mean things that go into the shared library
(libpythonXX/pythonXX.dll) vs executables?
I've had a quick look with grep -R HAVE_ * | egrep '[.]c:'.
Modules/posixmodule.c has HAVE_UTIME_H and it might be standard libc on all
posix platforms.
Objects/obmalloc.c has HAVE_MMAP… but I guess that's fine given other platforms
might not have such facility.
Depending on the granularity
Cavallo wrote:
Cool, next time I have to port an extension written in C/C++ I'll be
looking
only for bytes vs. strings problems. I knew it was easy.
Since I didn't see a smiley, I'll assume that wasn't sarcastic. ;)
In some ways bilingual extension modules are easier because of
#ifdef
It almost always comes down to bytes vs. strings, IME.
Cool, next time I have to port an extension written in C/C++ I'll be looking
only for bytes vs. strings problems.
I knew it was easy.
Thanks
___
Python-Dev mailing list
It's already hard to sell 2.7 in most companies.
Regards,
Antonio
Anyway, you should trust Brett Canon: Python 3.3: Trust Me, It's
Better Than Python 2.7.
https://speakerdeck.com/pyconslides/python-3-dot-3-trust-me-its-better-than-python-2-dot-7-by-dr-brett-cannon
Victor
By the way on the arm (and any platform that can do cross-compiling)
I've created a Makefile based build of the python 2.7.x:
https://bitbucket.org/cavallo71/android
Please don't be fooled by the Android name, it really can take any
crosscompiler (provided it follows the gcc synatx).
It
Correct if I'm wrong but distlib isn't targeting resources managent?
distutils is targeted to distribute python modules/packages instead;
small differences but on the field they really mean different things.
distlib is under http://hg.python.org/distlib too :O
..my first guess would be
There's the distutil mailing list:
http://mail.python.org/mailman/listinfo/distutils-sig
Doug Hellmann wrote:
A couple of us from the OpenStack project are interested in getting involved in
the packaging rewrite/update project. I was following that work for a while,
but have lost track of
in one place).
Funny enough distutils (the old dead horse) does it all except point 2:
that is my reason to clean up the code. I've just seen py3k distutils
but it would be worth a back port to py2k.
Thanks
Nick Coghlan wrote:
On Fri, Dec 14, 2012 at 10:10 AM, Antonio Cavallo
a.cava
It is not that complex... What's ahead is even more complex.
Lennart Regebro wrote:
On Fri, Dec 14, 2012 at 9:49 AM, Antonio Cavallo
a.cava...@cavallinux.eu wrote:
My requirements would quite simple:
2. cross compiling
That is *not* a simple requirement.
//Lennart
I'll have a look into distutils2, I tough it was (another) dead end.
I every case my target is py2k (2.7.x) and I've no case for
transitioning to py3k (too much risk).
Lennart Regebro wrote:
On Mon, Dec 10, 2012 at 8:22 AM, Antonio Cavallo
a.cava...@cavallinux.eu wrote:
Hi,
I wonder
Hi,
I wonder if is it worth/if there is any interest in trying to clean up
distutils: nothing in terms to add new features, just a *major* cleanup
retaining the exact same interface.
I'm not planning anything like *adding features* or rewriting
rpm/rpmbuild here, simply cleaning up that
25 matches
Mail list logo
