Re: [Python-Dev] Sad status of Python 3.x buildbots
Yes there are "details" indeed. But not show stoppers. A prototype can be seen here: http://cclimited.webfactional.com The nice bit is testing will be executed in a total fresh instance, an added bonus On 4 September 2014 05:16:01 GMT+01:00, Nick Coghlan wrote: >On 4 September 2014 11:07, Antonio Cavallo >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 (and provide a reliable build). > >It sounds like a good idea in principle, but I suspect there would be >a lot of devils in those details. That doesn't make it a bad idea, >just something that would need a volunteer to investigate further >before we could form a real opinion. > >Cheers, >Nick. > >-- >Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia -- Sent from my Android device with K-9 Mail. Please excuse my brevity.___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Slides from today's parallel/async Python talk
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 was born out of the frustration with trying to adapt ./configure to do cross compiling. It is a sliglty different update to the problem as tried by the kiwy project for example. I hope this helps, Antonio On 2013-03-14 13:38, Antoine Pitrou wrote: Le Thu, 14 Mar 2013 13:21:09 +0100, Christian Heimes a écrit : IMHO you should target x86, x86_64, ARMv6 and ARMv7. ARMv7 is going to be more important than x86 in the future. We are going to see more ARM based servers. Well we can't really see less of them, since there are hardly any ;-) Related reading: http://www.anandtech.com/show/6757/calxedas-arm-server-tested ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [RELEASE] Python 2.7.4 release candidate 1
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 ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] The end of 2.7
;) there's the missing bit. btw apologies if that looked offensive: it wasn't intended. I disagree on "bilingual extension modules are easier". While #ifdef can sort some issues (compiling ones mostly) it won't be much of a help if a module crash (and not much help from testing either). In that case debugging it involves a lot of steps as gatering the core dumps (if available), having a readily build python debug version, a debugger and restoring the crashing system in a similar state. All these steps might not be possible at all (imagine a secured production server). I'm not saying it is not possible but the caused downtime can quickly escalate (think of it in days terms more than hours). These are hidden costs to a company and it is hard to convince anyone to agressively port something to 3.x if it is reliably working on let's say 2.x: especially under time pressure conditions. On the bright side there's some success moving into 2.7: and we can all make sure the move to 3.x will be as small as possible in case in future time/policy constraints are relaxed. Thanks, Antonio On 2013-04-09 00:48, Barry Warsaw wrote: On Apr 08, 2013, at 11:32 PM, Antonio 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, but the general principle still holds. If you have a clear bytes v. strings story, it's not really that difficult to port extension modules either, at least IME. -Barry ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Structural cleanups to the main CPython repo
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? ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Segmentation fault on 3.4 with --pydebug
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? Intel i5 2.4 GHz, Mac OS X 10.8.3, clang $ hg up default $ make distclean $ MACOSX_DEPLOYMENT_TARGET=10.8 ./configure --with-pydebug $ make $ ./python.exe -Wd -m test.regrtest test_exceptions [1/1] test_exceptions Fatal Python error: Segmentation fault Current thread 0x7fff74254180: File "/Users/ambv/Documents/Projekty/Python/cpython/py34/Lib/test/test_exceptions.py", line 453 in f File "/Users/ambv/Documents/Projekty/Python/cpython/py34/Lib/test/test_exceptions.py", line 453 in f File "/Users/ambv/Documents/Projekty/Python/cpython/py34/Lib/test/test_exceptions.py", line 453 in f ... (repeated a 100 times) Command terminated abnormally. Everything runs fine without --with-pydebug (or before 83937 with --with-pydebug). ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] End of the mystery "@README.txt Mercurial bug"
.. or having hg "purging" unwanted build artifact (probably cleaning up the .hgignore file first) find $(srcdir)/* ... to avoid this problem. It won't expand the .hg top-level directory. Or find \( -type d -name .hg -prune \) -o ... Oleg. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] End of the mystery "@README.txt Mercurial bug"
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 Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] End of the mystery "@README.txt Mercurial bug"
*~, .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 that generated files (like the one generated from pgen) shouldn't be part of defaul make target but keept as fully tracked files (and regenerated on demand through a special make target). I hope this helps. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
