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).
https://skillsmatter.com/skillscasts/4313-intro-to-python-d
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 (b
m the python binaries
build to insulate the two). 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 Coghl
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. Cavallo wrote:
Yes there are "details" indeed. But not show stoppers. A prototype can be
seen here: http://cclimited.webfactional
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 wit
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 wrote:
> 2013/7/6 Antonio Cavallo :
>> Could that remove the need for the --with-pyd
Could that remove the need for the --with-pydebug flag?
On 6 Jul 2013, at 21:54, Antoine Pitrou 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 are native Engl
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 pla
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 (
> 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
Python-Dev@python.o
I personally agree that huge changesets aren't good. But I can also see
the problem of cross compiling should be sooner or later addressed.
I'm fairly interested in cross building python on android too.
A point to support cross compiling (instead native build arm-on-arm)
could be android doesn
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 that's
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 i
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
wrote:
My requirements would quite simple:
2. cross compiling
That is *not* a simple requirement.
//Le
ack it up everything 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
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
wrote:
Hi,
I wonder if is it worth/i
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 un
18 matches
Mail list logo
