Re: [Python-Dev] Newly Built Python3 Binary Throws Segfault
Very interesting. I got this error Fatal Python error: Py_Initialize: Unable to get the locale encoding NotImplementedError Aborted generate-posix-vars failed make: *** [pybuilddir.txt] Error 1 ...but it didn't (of course) segfault. I'll pull gdb, get the results and send them. On January 31, 2015 1:10:18 PM CST, Ryan wrote: >No; I was looking for all uses of _PyRaw_Strdup. Surprisingly, it's >used only a few times. > >Cyd Haselton wrote: >>Question: >>When you said earlier that you found the problem by using grep...were >>you looking for places where strdup called locale? >> >>On January 30, 2015 7:52:47 PM CST, Ryan Gonzalez >>wrote: >>>Regardless, if you're looking to toy more with stuff like this, I'd >>>highly >>>recommend dual-booting with Ubuntu, which is what I'm doing now. (Now >>I >>>rarely ever boot into Windows!) >>> >>>On Fri, Jan 30, 2015 at 7:51 PM, Ryan Gonzalez >>>wrote: >>> Do you have just the SDK (which doesn't require Cygwin) or a rooted >>>phone? If so, I can upload instructions that don't use the NDK. On Fri, Jan 30, 2015 at 6:19 PM, Cyd Haselton >>>wrote: > This is going to take some time...here's why: > > Downloading and installing the NDK/SDK won't be too hard...I have >>to > clear some space...but my primary machine is running Windows 7 and >>>I'd > rather swallow hot coals than install Cygwin. I've got next to no > experience with it, other than knowing that the NDK recommends >>>against > it. > > I've got a CentOS VM...but it's currently in tarball form on an > external drive for space reasons...and it only has the NDK >>>installed. > If I am able to get it back up and running, there's still the task >>>of > getting adb connected to my device. from the VM. > > Not saying it's impossible...just that it'll take time...and I'll > probably have to tackle it tomorrow (earliest) or Sunday (latest). > >>>In > the meantime I'll also check to see if there's anything that can >a) > run in an Android terminal and b) can take a stack trace; it would >>>be > far, far, far easier than either option above. > > > > On Fri, Jan 30, 2015 at 4:19 PM, Ryan Gonzalez >>>wrote: > > Do you have the Android SDK and NDK installed? If so... > > > > Using Google, I've created this series of steps, which may (or >>may >>>not) > > work: > > > > 1. Make sure you have a copy of Python on your computer and make >>>sure > that > > it's built with debug symbols. > > > > 2. Run the following commands from a shell with your phone >>plugged >>>in: > > > > adb forward tcp:5039 tcp:5039 > > adb shell /system/bin/gdbserver tcp:5039 >>executable> > > /arm-linux-androideabi-gdb > > > > Now, GDB should have opened, so type the following commands: > > > > set solib-search-path > > file > > target remote :5055 > > run > > > > Now, wait for the program to crash and type: > > > > backtrace > > > > You should now see a complete backtrace in your terminal. To >GDB, >>>type: > > > > quit > > > > *crosses fingers* > > > > On Fri, Jan 30, 2015 at 2:50 PM, Cyd Haselton >>> > wrote: > >> > >> Unfortunately it is still reporting the same function :-/. > >> > >> On Fri, Jan 30, 2015 at 1:44 PM, Ryan Gonzalez >> > wrote: > >> > Yes... > >> > > >> > Can you check if it's crashing in a different function now? > >> > > >> > On Fri, Jan 30, 2015 at 1:39 PM, Cyd Haselton >>> > >> > wrote: > >> >> > >> >> Yes I did. I did have to enter all the information in > manually...I'm > >> >> not familiar with automated patch application tools and even >>>if I > >> >> were, I'm pretty sure I wouldn't have them on my device. > >> >> > >> >> Just so that I'm absolutely sure I got everything >>>correct...you > wanted > >> >> all of the lines in the patch commented out, correct? >>>Basically > >> >> everything referencing oldloc? > >> >> > >> >> On Fri, Jan 30, 2015 at 1:00 PM, Ryan Gonzalez >>> > >> >> wrote: > >> >> > Are you sure the patch was applied correctly? I was SO >sure >>>it > would > >> >> > work! > >> >> > > >> >> > FYI, you tried the patch I attached to the email message, >>>right? > >> >> > > >> >> > On Fri, Jan 30, 2015 at 12:58 PM, Cyd Haselton < > chasel...@gmail.com> > >> >> > wrote: > >> >> >> > >> >> >> Update: I did try the patch after getting it installed > correctly, > >> >> >> but > >> >> >> I'm still getting a segfault on the newly built binary. > >> >> >> Will post info this afternoon. > >> >> >> > >> >> >> On Fri, Jan 30, 2015 at 12:10 PM, Ryan Gonzalez < > rym...@gmail.com> > >> >> >> wrote: > >> >> >> > No, it returns NULL if malloc gives it a raw pointer. >It > >> >>
Re: [Python-Dev] Newly Built Python3 Binary Throws Segfault
Ergh...this may not work. I've already got BusyBox and a terminal installed, but the python build...and all other utilities that I use...are running in a fakechrooted environment inside the terminal. That environment only filters dynamic calls to libc, so the statically compiled gdb won't work in the environment and running it outside the environment against the python built IN the environment won't work, I think... Let me do some looking around and tinkering...I may just need to build gdb for my environment. On January 31, 2015 1:09:22 PM CST, Ryan wrote: >Ok...try this (based on http://dan.drown.org/android/howto/gdb.html): > >- Install BusyBox and a Terminal Emulator >- Inside the Terminal Emulator, run: > > su > cd /data/local/tmp > wget http://dan.drown.org/android/gdb- >static.tar.gz > tar zxf gdb-static.tar.gz > ./gdb > >Now, inside gdb, type: > > set logging file /mnt/sdcard/bt.txt > set logging on > run > >Wait for Python to crash, then type: > > backtrace > >A backtrace should be printed to the screen and saved to a file named >bt.txt on the SD card. After that, type: > > quit > >to quit GDB. Send the list the bt.txt file on your SD card. > >chasel...@gmail.com wrote: >>I don't have the SDK either...but my device is rooted. >> >>Dual-booting is not an option unfortunately...space reasons. I'll do >>my best to figure out a way to get the instuctions you sent >>implemented, but this may be a deal-breaker for porting Python 3.4.x >>for me...I may go back to working on 2.7.x >> >>Sent from my android device. >> >>-Original Message- >>From: Ryan Gonzalez >>To: Cyd Haselton >>Cc: Python-Dev >>Sent: Fri, 30 Jan 2015 7:53 PM >>Subject: Re: [Python-Dev] Newly Built Python3 Binary Throws Segfault >> >>Regardless, if you're looking to toy more with stuff like this, I'd >>highly >>recommend dual-booting with Ubuntu, which is what I'm doing now. (Now >I >>rarely ever boot into Windows!) >> >>On Fri, Jan 30, 2015 at 7:51 PM, Ryan Gonzalez >>wrote: >> >>> Do you have just the SDK (which doesn't require Cygwin) or a rooted >>phone? >>> If so, I can upload instructions that don't use the NDK. >>> >>> On Fri, Jan 30, 2015 at 6:19 PM, Cyd Haselton >>wrote: >>> This is going to take some time...here's why: Downloading and installing the NDK/SDK won't be too hard...I have >to clear some space...but my primary machine is running Windows 7 and >>I'd rather swallow hot coals than install Cygwin. I've got next to no experience with it, other than knowing that the NDK recommends >>against it. I've got a CentOS VM...but it's currently in tarball form on an external drive for space reasons...and it only has the NDK >>installed. If I am able to get it back up and running, there's still the task >>of getting adb connected to my device. from the VM. Not saying it's impossible...just that it'll take time...and I'll probably have to tackle it tomorrow (earliest) or Sunday (latest). >>In the meantime I'll also check to see if there's anything that can a) run in an Android terminal and b) can take a stack trace; it would >>be far, far, far easier than either option above. On Fri, Jan 30, 2015 at 4:19 PM, Ryan Gonzalez >>wrote: > Do you have the Android SDK and NDK installed? If so... > > Using Google, I've created this series of steps, which may (or >may >>not) > work: > > 1. Make sure you have a copy of Python on your computer and make >>sure that > it's built with debug symbols. > > 2. Run the following commands from a shell with your phone >plugged >>in: > > adb forward tcp:5039 tcp:5039 > adb shell /system/bin/gdbserver tcp:5039 >executable> > /arm-linux-androideabi-gdb > > Now, GDB should have opened, so type the following commands: > > set solib-search-path > file > target remote :5055 > run > > Now, wait for the program to crash and type: > > backtrace > > You should now see a complete backtrace in your terminal. To GDB, >>type: > > quit > > *crosses fingers* > > On Fri, Jan 30, 2015 at 2:50 PM, Cyd Haselton >> wrote: >> >> Unfortunately it is still reporting the same function :-/. >> >> On Fri, Jan 30, 2015 at 1:44 PM, Ryan Gonzalez > wrote: >> > Yes... >> > >> > Can you check if it's crashing in a different function now? >> > >> > On Fri, Jan 30, 2015 at 1:39 PM, Cyd Haselton >> >> > wrote: >> >> >> >> Yes I did. I did have to enter all the information in manually...I'm >> >> not familiar with automated patch application tools and even >>if I >> >> were, I'm pretty sure I wouldn't have them on my device. >> >> >> >> Just so that I'm absolutely sure I got everything >>correct...you wanted >>
Re: [Python-Dev] Newly Built Python3 Binary Throws Segfault
Ok...try this (based on http://dan.drown.org/android/howto/gdb.html): - Install BusyBox and a Terminal Emulator - Inside the Terminal Emulator, run: su cd /data/local/tmp wget http://dan.drown.org/android/gdb- static.tar.gz tar zxf gdb-static.tar.gz ./gdb Now, inside gdb, type: set logging file /mnt/sdcard/bt.txt set logging on run Wait for Python to crash, then type: backtrace A backtrace should be printed to the screen and saved to a file named bt.txt on the SD card. After that, type: quit to quit GDB. Send the list the bt.txt file on your SD card. chasel...@gmail.com wrote: >I don't have the SDK either...but my device is rooted. > >Dual-booting is not an option unfortunately...space reasons. I'll do >my best to figure out a way to get the instuctions you sent >implemented, but this may be a deal-breaker for porting Python 3.4.x >for me...I may go back to working on 2.7.x > >Sent from my android device. > >-Original Message- >From: Ryan Gonzalez >To: Cyd Haselton >Cc: Python-Dev >Sent: Fri, 30 Jan 2015 7:53 PM >Subject: Re: [Python-Dev] Newly Built Python3 Binary Throws Segfault > >Regardless, if you're looking to toy more with stuff like this, I'd >highly >recommend dual-booting with Ubuntu, which is what I'm doing now. (Now I >rarely ever boot into Windows!) > >On Fri, Jan 30, 2015 at 7:51 PM, Ryan Gonzalez >wrote: > >> Do you have just the SDK (which doesn't require Cygwin) or a rooted >phone? >> If so, I can upload instructions that don't use the NDK. >> >> On Fri, Jan 30, 2015 at 6:19 PM, Cyd Haselton >wrote: >> >>> This is going to take some time...here's why: >>> >>> Downloading and installing the NDK/SDK won't be too hard...I have to >>> clear some space...but my primary machine is running Windows 7 and >I'd >>> rather swallow hot coals than install Cygwin. I've got next to no >>> experience with it, other than knowing that the NDK recommends >against >>> it. >>> >>> I've got a CentOS VM...but it's currently in tarball form on an >>> external drive for space reasons...and it only has the NDK >installed. >>> If I am able to get it back up and running, there's still the task >of >>> getting adb connected to my device. from the VM. >>> >>> Not saying it's impossible...just that it'll take time...and I'll >>> probably have to tackle it tomorrow (earliest) or Sunday (latest). >In >>> the meantime I'll also check to see if there's anything that can a) >>> run in an Android terminal and b) can take a stack trace; it would >be >>> far, far, far easier than either option above. >>> >>> >>> >>> On Fri, Jan 30, 2015 at 4:19 PM, Ryan Gonzalez >wrote: >>> > Do you have the Android SDK and NDK installed? If so... >>> > >>> > Using Google, I've created this series of steps, which may (or may >not) >>> > work: >>> > >>> > 1. Make sure you have a copy of Python on your computer and make >sure >>> that >>> > it's built with debug symbols. >>> > >>> > 2. Run the following commands from a shell with your phone plugged >in: >>> > >>> > adb forward tcp:5039 tcp:5039 >>> > adb shell /system/bin/gdbserver tcp:5039 executable> >>> > /arm-linux-androideabi-gdb >>> > >>> > Now, GDB should have opened, so type the following commands: >>> > >>> > set solib-search-path >>> > file >>> > target remote :5055 >>> > run >>> > >>> > Now, wait for the program to crash and type: >>> > >>> > backtrace >>> > >>> > You should now see a complete backtrace in your terminal. To GDB, >type: >>> > >>> > quit >>> > >>> > *crosses fingers* >>> > >>> > On Fri, Jan 30, 2015 at 2:50 PM, Cyd Haselton > >>> wrote: >>> >> >>> >> Unfortunately it is still reporting the same function :-/. >>> >> >>> >> On Fri, Jan 30, 2015 at 1:44 PM, Ryan Gonzalez >>> wrote: >>> >> > Yes... >>> >> > >>> >> > Can you check if it's crashing in a different function now? >>> >> > >>> >> > On Fri, Jan 30, 2015 at 1:39 PM, Cyd Haselton > >>> >> > wrote: >>> >> >> >>> >> >> Yes I did. I did have to enter all the information in >>> manually...I'm >>> >> >> not familiar with automated patch application tools and even >if I >>> >> >> were, I'm pretty sure I wouldn't have them on my device. >>> >> >> >>> >> >> Just so that I'm absolutely sure I got everything >correct...you >>> wanted >>> >> >> all of the lines in the patch commented out, correct? >Basically >>> >> >> everything referencing oldloc? >>> >> >> >>> >> >> On Fri, Jan 30, 2015 at 1:00 PM, Ryan Gonzalez > >>> >> >> wrote: >>> >> >> > Are you sure the patch was applied correctly? I was SO sure >it >>> would >>> >> >> > work! >>> >> >> > >>> >> >> > FYI, you tried the patch I attached to the email message, >right? >>> >> >> > >>> >> >> > On Fri, Jan 30, 2015 at 12:58 PM, Cyd Haselton < >>> chasel...@gmail.com> >>> >> >> > wrote: >>> >> >> >> >>> >> >> >> Update: I did try the patch after getting it installed >>> correctly, >>> >> >> >> but >>> >> >> >> I'm still getting a segfault on the newly built binary. >>> >> >> >> Will post info this aftern
Re: [Python-Dev] Newly Built Python3 Binary Throws Segfault
That looks better! Looks like now the real encoding issues are coming up. Try going to line 269 of pythonrun.c and changing: PyErr_SetNone(PyExc_NotImplementedError); return NULL; to: char* m = malloc(6); strcpy(m, "ascii"); return m; This just sets a default encoding. On Sat, Jan 31, 2015 at 1:21 PM, Cyd Haselton wrote: > Very interesting. I got this error > > Fatal Python error: Py_Initialize: Unable to get the locale encoding > NotImplementedError > Aborted > generate-posix-vars failed > make: *** [pybuilddir.txt] Error 1 > > ...but it didn't (of course) segfault. I'll pull gdb, get the results and > send them. > > On January 31, 2015 1:10:18 PM CST, Ryan wrote: > >> No; I was looking for all uses of _PyRaw_Strdup. Surprisingly, it's used >> only a few times. >> >> Cyd Haselton wrote: >>> >>> Question: >>> When you said earlier that you found the problem by using grep...were >>> you looking for places where strdup called locale? >>> >>> On January 30, 2015 7:52:47 PM CST, Ryan Gonzalez >>> wrote: Regardless, if you're looking to toy more with stuff like this, I'd highly recommend dual-booting with Ubuntu, which is what I'm doing now. (Now I rarely ever boot into Windows!) On Fri, Jan 30, 2015 at 7:51 PM, Ryan Gonzalez wrote: > Do you have just the SDK (which doesn't require Cygwin) or a rooted > phone? If so, I can upload instructions that don't use the NDK. > > On Fri, Jan 30, 2015 at 6:19 PM, Cyd Haselton > wrote: > >> This is going to take some time...here's why: >> >> Downloading and installing the NDK/SDK won't be too hard...I have to >> clear some space...but my primary machine is running Windows 7 and I'd >> rather swallow hot coals than install Cygwin. I've got next to no >> experience with it, other than knowing that the NDK recommends against >> it. >> >> I've got a CentOS VM...but it's currently in tarball form on an >> external drive for space reasons...and it only has the NDK installed. >> If I am able to get it back up and running, there's still the task of >> getting adb connected to my device. from the VM. >> >> Not saying it's impossible...just that it'll take time...and I'll >> probably have to tackle it tomorrow (earliest) or Sunday (latest). In >> the meantime I'll also check to see if there's anything that can a) >> run in an Android terminal and b) can take a stack trace; it would be >> far, far, far easier than either option above. >> >> >> >> On Fri, Jan 30, 2015 at 4:19 PM, Ryan Gonzalez >> wrote: >> > Do you have the Android SDK and NDK installed? If so... >> > >> > Using Google, I've created this series of steps, which may (or may >> not) >> > work: >> > >> > 1. Make sure you have a copy of Python on your computer and make >> sure that >> > it's built with debug symbols. >> > >> > 2. Run the following commands from a shell with your phone plugged >> in: >> > >> > adb forward tcp:5039 tcp:5039 >> > adb shell /system/bin/gdbserver tcp:5039 > executable> >> > /arm-linux-androideabi-gdb >> > >> > Now, GDB should have opened, so type the following commands: >> > >> > set solib-search-path >> > file >> > target remote :5055 >> > run >> > >> > Now, wait for the program to crash and type: >> > >> > backtrace >> > >> > You should now see a complete backtrace in your terminal. To GDB, >> type: >> > >> > quit >> > >> > *crosses fingers* >> > >> > On Fri, Jan 30, 2015 at 2:50 PM, Cyd Haselton >> wrote: >> >> >> >> Unfortunately it is still reporting the same function :-/. >> >> >> >> On Fri, Jan 30, 2015 at 1:44 PM, Ryan Gonzalez >> wrote: >> >> > Yes... >> >> > >> >> > Can you check if it's crashing in a different function now? >> >> > >> >> > On Fri, Jan 30, 2015 at 1:39 PM, Cyd Haselton < >> chasel...@gmail.com> >> >> > wrote: >> >> >> >> >> >> Yes I did. I did have to enter all the information in >> manually...I'm >> >> >> not familiar with automated patch application tools and even if >> I >> >> >> were, I'm pretty sure I wouldn't have them on my device. >> >> >> >> >> >> Just so that I'm absolutely sure I got everything correct...you >> wanted >> >> >> all of the lines in the patch commented out, correct? Basically >> >> >> everything referencing oldloc? >> >> >> >> >> >> On Fri, Jan 30, 2015 at 1:00 PM, Ryan Gonzalez < >> rym...@gmail.com> >> >> >> wrote: >> >> >> > Are you sure the patch was applied correctly? I was SO sure >> it would >> >> >> > work! >> >> >> > >> >> >> > FYI, you tried the patch I attached to the email message, >> right? >> >> >> > >> >> >> > On Fri, Jan 30, 2015 at 12:58 PM, Cyd Ha
[Python-Dev] PEP 484 syntax: NONONONONONONO!
The proposed syntax is abominable. It's the opposite of readable. The function annotation syntax is ugly, but potentially useful for things like documentation. While it may very well have been created with the idea of type-checking, actually using it for such quickly turns into an unreadable morass of information that is far more difficult for human brains to parse, which makes this usage the antithesis of pythonic. I much prefer the idea of a 'where' keyword to denote typing, as discussed http://aroberge.blogspot.com/2015/01/type-hinting-in-python-focus-on.html, but I think a refinement of their idea would prove even better: def retry(callback, timeout, retries=None) where callback is Callable[AnyArgs, Any[int, None]], timeout is Any[int, None], retries is in [int, None], # 'is in' construct is more readable, dunno about complexity return is None: pass def greeting(name) where name is str, return is str: return 'Hello ' + name x, y = [], [] where x, y is List[Employee], List[Manager] To me, this orders of magnitude more readable than the proposed nonsense. PS. Obviously the 8-space indent above would only a convention, not requirement. ___ 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] PEP 484 syntax: NONONONONONONO!
On 01/02/2015 10:13, Benjamin wrote: The proposed syntax is abominable. It's the opposite of readable. I have no views on the subject as I won't be using it, but there is no need to shout to get your point across. -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence ___ 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] Workflow improvement PEPs 474 & 462 updated
Hi Nick, On 02/01/2015 08:46 AM, Nick Coghlan wrote: [...] > The updates to PEP 462, which covers proposed changes to the main > CPython workflow, were more significant, as I've now rewritten that to > depend on PEP 474, and propose replacing the current Rietveld patch > review workflow with an updated approach based on Kallithea and Zuul: > https://www.python.org/dev/peps/pep-0462/ > A small question on: """ Push races would also be a thing of the past - if lots of core developers are approving patches at a sprint, then that just means the queue gets deeper in Zuul, rather than developers getting frustrated trying to merge changes and failing. """ How does the Tool Zuul resolve the case where the patches are not fully compatible. E.g. they touch the same file and some manually merging is needed? (Isn't that a push race? or I'm missing something?) And one minor detail. Early on "Current Tools": """ This proposal suggests replacing the use of Rietveld for code review with the more full-featured Kallithea-based forge.python.org service proposed in PEP 474 . """ and then later on "Perceived Benefits": """ the merge queue would allow that developer to focus more of their time on reviewing patches and helping the other contributors at the sprint, since accepting a patch for inclusion would now be a single click in the Rietveld UI, rather [...] """ Isn't "Kallithea UI" meant here? And +1 for self-hosting on: """ This proposal respects that history by recommending only tools that are available for self-hosting as sponsored or PSF funded infrastructure, and are also open source Python projects that can be customised to meet the needs of the CPython core development team """ I like the PEP. PS: Should this be forwarded to python-workflow or is that other list to be considered obsolete? Regards, francis ___ 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] PEP 484 syntax: NONONONONONONO!
On Sun, Feb 1, 2015 at 9:13 PM, Benjamin wrote: > I much prefer the idea of a 'where' keyword to denote typing, as discussed > http://aroberge.blogspot.com/2015/01/type-hinting-in-python-focus-on.html, > but I think a refinement of their idea would prove even better: > > def retry(callback, timeout, retries=None) where > callback is Callable[AnyArgs, Any[int, None]], > timeout is Any[int, None], > retries is in [int, None], # 'is in' construct is more readable, > dunno about complexity > return is None: > pass Massively verbose, and requires duplication of your argument names. If you're going to have the args all listed down below, the first line is redundant; all you need to do is incorporate the "=None" default into the lower part, and you can drop the first line altogether. def retry( callback: Callable[AnyArgs, Optional[int]], timeout: Optional[int], retries:Optional[int]=None ) -> None: pass Indent that any way you like. Apart from taking advantage of Optional[] rather than explicitly Anying with None, that's a direct translation from your code to actual annotations. Advantage: It works in current code, as long as you backport those names (which typing.py will do). I'm stating the parameter names exactly once each, I'm laying it out pretty much the same way you had it, and there's no need to add any more syntax beyond PEP 3107. ChrisA ___ 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] Workflow improvement PEPs 474 & 462 updated
On 2 Feb 2015 04:56, "francis" wrote: > > Hi Nick, > > On 02/01/2015 08:46 AM, Nick Coghlan wrote: > [...] > > The updates to PEP 462, which covers proposed changes to the main > > CPython workflow, were more significant, as I've now rewritten that to > > depend on PEP 474, and propose replacing the current Rietveld patch > > review workflow with an updated approach based on Kallithea and Zuul: > > https://www.python.org/dev/peps/pep-0462/ > > > > > A small question on: > """ > Push races would also be a thing of the past - if lots of core > developers are approving patches at a sprint, then that just means the > queue gets deeper in Zuul, rather than developers getting frustrated > trying to merge changes and failing. > """ > How does the Tool Zuul resolve the case where the patches are not fully > compatible. E.g. they touch the same file and some manually merging is > needed? (Isn't that a push race? or I'm missing something?) That's an actual merge conflict, the push races I'm referring to are the ones where there's no conflict, but Mercurial objects to the non-linear history. Zuul takes care of linearising everything and making sure the tests pass before committing the change to the relevant branch. > And one minor detail. Early on "Current Tools": > """ > This proposal suggests replacing the use of Rietveld for code review > with the more full-featured Kallithea-based forge.python.org service > proposed in PEP 474 . > """ > > and then later on "Perceived Benefits": > """ > the merge queue would allow that developer to focus more of their time > on reviewing patches and helping the other contributors at the sprint, > since accepting a patch for inclusion would now be a single click in the > Rietveld UI, rather [...] > """ > Isn't "Kallithea UI" meant here? Good catch - I must have missed that one in the update. > And +1 for self-hosting on: > """ > This proposal respects that history by recommending only tools that are > available for self-hosting as sponsored or PSF funded infrastructure, > and are also open source Python projects that can be customised to meet > the needs of the CPython core development team > """ > > I like the PEP. > > > PS: Should this be forwarded to python-workflow or is that other list to > be considered obsolete? I withdrew from participating in that list when an individual banned from the core mailing lists and the issue tracker for persistently failing to respect other participants in those communities chose to participate in it despite an explicit request from me that he refrain from doing so (after wasting years trying to coach him into more productive modes of engagement, I now just cut my losses and flat out refuse to work in any environment where he has a significant presence). Since our moderation practices don't currently include a way to request transferring bans between lists, and I'm reluctant to push for that to change when I have such a clear personal stake in the outcome (it reads like a personal vendetta against the individual concerned), that's the way things are likely to stay unless/until he also gets himself banned from the core workflow list. Regards, Nick. > > Regards, > francis > > ___ > 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/ncoghlan%40gmail.com ___ 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
