[SciPy-Dev] issues trac migration review
Thu Apr 25 19:37:23 CDT 2013
On Thu, Apr 25, 2013 at 8:33 PM, <email@example.com> wrote:
> On Thu, Apr 25, 2013 at 8:25 PM, Skipper Seabold <firstname.lastname@example.org> wrote:
>> On Thu, Apr 25, 2013 at 8:22 PM, <email@example.com> wrote:
>>> On Thu, Apr 25, 2013 at 8:10 PM, Skipper Seabold <firstname.lastname@example.org> wrote:
>>>> On Thu, Apr 25, 2013 at 7:49 PM, <email@example.com> wrote:
>>>>> incorrect crosslinks again
>>>>> comments like this are pretty annoying since the create backlinks
>>>>> a collection of backlinks
>>>>> trac didn't have the backlinks, so incorrect links were less of a distraction.
>>>>> Is there anything we can do? or maybe it's not worth it with old tickets.
>>>> Ugh, I spent an hour fixing the regex for this last night and it
>>>> happens automatically on github anyway.
>>>> I just put that in a code block and it goes away, but no there's no
>>>> way to really do that programmatically.
>>> Yes, I realized that before, there is no way to recognize this with a regex.
>> Well it doesn't convert it to gh-. That's the regex I control.
> gdb traces that are not in triple backticks ``` produce a lot of links
> in the example
> at ../Objects/abstract.c:1795
> #30 0x080b395c in PyEval_CallObjectWithKeywords (func=0xb7903c34,
> arg=0xb7db502c, kw=0x0) at ../Python/ceval.c:3435
> #31 0x080590d0 in PyObject_CallObject (o=0xb7903c34, a=0xb7db502c)
> at ../Objects/abstract.c:1786
> gh-559 0xb7891b0a in init_gobject ()
> from /var/lib/python-support/python2.4/gtk-2.0/gobject/_gobject.so
> gh-560 0xb77c8aa1 in g_source_is_destroyed () from /usr/lib/libglib-2.0.so.0
> gh-561 0xb77ca802 in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0
> gh-562 0xb77cd7df in g_main_context_check () from /usr/lib/libglib-2.0.so.0
> gh-563 0xb77cdb89 in g_main_loop_run () from /usr/lib/libglib-2.0.so.0
> gh-564 0xb73ad574 in gtk_main () from /usr/lib/libgtk-x11-2.0.so.0
> gh-565 0xb76bbd90 in init_gtk ()
> from /var/lib/python-support/python2.4/gtk-2.0/gtk/_gtk.so
> #39 0x080b8ab0 in PyEval_EvalFrame (f=0x818559c) at ../Python/ceval.c:3552
> ---Type to continue, or q to quit---
> #40 0x080ba4b9 in PyEval_EvalCodeEx (co=0xb7b9e0a0, globals=0xb7c119bc,
> locals=0x0, args=0x8155a88, argcount=1, kws=0x8155a8c, kwcount=0,
> defs=0xb7ba8dd8, defcount=2, closure=0x0) at ../Python/ceval.c:2741
Right, I only had a negative lookahead for 0x0 (was 0x00). Should've
just done 0x.
>>> I was thinking more about whether we should manually edit the
>>> offending comments.
>> Sounds fine to me.
>>> At least I would prefer, when I see a wrong backlink in one of the
>>> issues that I look at, to just go and edit the linking comment.
>>> It would trigger a notification, I assume.
>> I don't think a manual edit would. Doing it with the code deletes the
>> old comments and pushes new ones, so that would.
> I don't know, I never edited someone elses comments, and I don't get a
> notification of my edits (still a major shortcoming of the github
> issue notifications compared to trac.)
>> I think we're out of the notification doghouse now though (at least
>> with github...).
>> SciPy-Dev mailing list
> SciPy-Dev mailing list
More information about the SciPy-Dev