* [PATCH v11 03/13] ref-filter: introduce ref_formatting_state @ 2015-08-15 18:00 Karthik Nayak 2015-08-16 23:31 ` Eric Sunshine 0 siblings, 1 reply; 4+ messages in thread From: Karthik Nayak @ 2015-08-15 18:00 UTC (permalink / raw) To: git; +Cc: christian.couder, Matthieu.Moy, gitster, Karthik Nayak, Karthik Nayak Introduce ref_formatting_state which will hold the formatted output strbuf and is used for nesting of modifier atoms. Mentored-by: Christian Couder <christian.couder@gmail.com> Mentored-by: Matthieu Moy <matthieu.moy@grenoble-inp.fr> Signed-off-by: Karthik Nayak <karthik.188@gmail.com> --- ref-filter.c | 65 ++++++++++++++++++++++++++++++++++++++++++++---------------- 1 file changed, 48 insertions(+), 17 deletions(-) diff --git a/ref-filter.c b/ref-filter.c index edfb1c7..3259363 100644 --- a/ref-filter.c +++ b/ref-filter.c @@ -55,6 +55,12 @@ static struct { { "color" }, }; +struct ref_formatting_state { + struct strbuf output; + struct ref_formatting_state *prev; + int quote_style; +}; + struct atom_value { const char *s; unsigned long ul; /* used for sorting when not FIELD_STR */ @@ -129,6 +135,26 @@ int parse_ref_filter_atom(const char *atom, const char *ep) return at; } +static struct ref_formatting_state *push_new_state(struct ref_formatting_state **state) +{ + struct ref_formatting_state *new_state = xcalloc(1, sizeof(struct ref_formatting_state)); + struct ref_formatting_state *tmp = *state; + + *state = new_state; + new_state->prev = tmp; + return new_state; +} + +static void pop_state(struct ref_formatting_state **state) +{ + struct ref_formatting_state *current = *state; + struct ref_formatting_state *prev = current->prev; + + strbuf_release(¤t->output); + free(current); + *state = prev; +} + /* * In a format string, find the next occurrence of %(atom). */ @@ -1195,23 +1221,23 @@ void ref_array_sort(struct ref_sorting *sorting, struct ref_array *array) qsort(array->items, array->nr, sizeof(struct ref_array_item *), compare_refs); } -static void append_atom(struct atom_value *v, int quote_style, struct strbuf *output) +static void append_atom(struct atom_value *v, struct ref_formatting_state *state) { - switch (quote_style) { + switch (state->quote_style) { case QUOTE_NONE: - strbuf_addstr(output, v->s); + strbuf_addstr(&state->output, v->s); break; case QUOTE_SHELL: - sq_quote_buf(output, v->s); + sq_quote_buf(&state->output, v->s); break; case QUOTE_PERL: - perl_quote_buf(output, v->s); + perl_quote_buf(&state->output, v->s); break; case QUOTE_PYTHON: - python_quote_buf(output, v->s); + python_quote_buf(&state->output, v->s); break; case QUOTE_TCL: - tcl_quote_buf(output, v->s); + tcl_quote_buf(&state->output, v->s); break; } } @@ -1234,7 +1260,7 @@ static int hex2(const char *cp) return -1; } -static void append_literal(const char *cp, const char *ep, struct strbuf *output) +static void append_literal(const char *cp, const char *ep, struct ref_formatting_state *state) { while (*cp && (!ep || cp < ep)) { if (*cp == '%') { @@ -1243,13 +1269,13 @@ static void append_literal(const char *cp, const char *ep, struct strbuf *output else { int ch = hex2(cp + 1); if (0 <= ch) { - strbuf_addch(output, ch); + strbuf_addch(&state->output, ch); cp += 3; continue; } } } - strbuf_addch(output, *cp); + strbuf_addch(&state->output, *cp); cp++; } } @@ -1257,20 +1283,24 @@ static void append_literal(const char *cp, const char *ep, struct strbuf *output void show_ref_array_item(struct ref_array_item *info, const char *format, int quote_style) { const char *cp, *sp, *ep; - struct strbuf output = STRBUF_INIT; + struct strbuf *final_buf; + struct ref_formatting_state *state = NULL; + + state = push_new_state(&state); + state->quote_style = quote_style; for (cp = format; *cp && (sp = find_next(cp)); cp = ep + 1) { struct atom_value *atomv; ep = strchr(sp, ')'); if (cp < sp) - append_literal(cp, sp, &output); + append_literal(cp, sp, state); get_ref_atom_value(info, parse_ref_filter_atom(sp + 2, ep), &atomv); - append_atom(atomv, quote_style, &output); + append_atom(atomv, state); } if (*cp) { sp = cp + strlen(cp); - append_literal(cp, sp, &output); + append_literal(cp, sp, state); } if (need_color_reset_at_eol) { struct atom_value resetv; @@ -1279,11 +1309,12 @@ void show_ref_array_item(struct ref_array_item *info, const char *format, int qu if (color_parse("reset", color) < 0) die("BUG: couldn't parse 'reset' as a color"); resetv.s = color; - append_atom(&resetv, quote_style, &output); + append_atom(&resetv, state); } - fwrite(output.buf, 1, output.len, stdout); + final_buf = &state->output; + fwrite(final_buf->buf, 1, final_buf->len, stdout); + pop_state(&state); putchar('\n'); - strbuf_release(&output); } /* If no sorting option is given, use refname to sort as default */ -- 2.5.0 ^ permalink raw reply related [flat|nested] 4+ messages in thread
* Re: [PATCH v11 03/13] ref-filter: introduce ref_formatting_state 2015-08-15 18:00 [PATCH v11 03/13] ref-filter: introduce ref_formatting_state Karthik Nayak @ 2015-08-16 23:31 ` Eric Sunshine 2015-08-17 5:15 ` Eric Sunshine 2015-08-17 12:43 ` Karthik Nayak 0 siblings, 2 replies; 4+ messages in thread From: Eric Sunshine @ 2015-08-16 23:31 UTC (permalink / raw) To: Karthik Nayak; +Cc: Git List, Christian Couder, Matthieu Moy, Junio C Hamano On Sat, Aug 15, 2015 at 2:00 PM, Karthik Nayak <karthik.188@gmail.com> wrote: > Introduce ref_formatting_state which will hold the formatted > output strbuf and is used for nesting of modifier atoms. > > Signed-off-by: Karthik Nayak <karthik.188@gmail.com> > --- > diff --git a/ref-filter.c b/ref-filter.c > index edfb1c7..3259363 100644 > --- a/ref-filter.c > +++ b/ref-filter.c > @@ -55,6 +55,12 @@ static struct { > { "color" }, > }; > > +struct ref_formatting_state { > + struct strbuf output; > + struct ref_formatting_state *prev; Upon initial read-through of this patch, I found the name 'prev' confusing since it seems you sometimes treat this as a linked-list and, for a linked-list, this member is customarily named 'next'. However, you also sometimes treat it as a stack, in which case 'prev' makes a certain amount of sense semantically, although so does 'next'. I'd probably have named it 'next', however, attr.c:struct attr_stack names its member 'prev', so there is some precedence for the current choice. Also, it's customary for this member to be the first (or less frequently last) member in the structure. > + int quote_style; > +}; > + > struct atom_value { > const char *s; > unsigned long ul; /* used for sorting when not FIELD_STR */ > @@ -129,6 +135,26 @@ int parse_ref_filter_atom(const char *atom, const char *ep) > return at; > } > > +static struct ref_formatting_state *push_new_state(struct ref_formatting_state **state) This interface seems confused. The caller receives the new state as both the return value of the function and as an out-value of its sole argument. I'd suggest choosing one or the other. Which one you choose depends upon how you view the operation and the data structure. If you view it as linked-list manipulation, then you'd probably want the new state returned, and accept a pointer argument (rather than pointer-to-pointer). On the other hand, if you view it as a stack, then you'd probably want to have it return void and manipulate the sole argument. For this case, it might be clearer to name the argument 'stack' rather than 'state'. > +{ > + struct ref_formatting_state *new_state = xcalloc(1, sizeof(struct ref_formatting_state)); > + struct ref_formatting_state *tmp = *state; > + > + *state = new_state; > + new_state->prev = tmp; > + return new_state; > +} A couple issues: First, you need to initialize the strbuf member of ref_formatting_state after allocation: new_state = xcalloc(1, sizeof(struct ref_formatting_state)); strbuf_init(&new_state->output, 0); Second, if you re-order the code slightly, the 'tmp' variable becomes unnecessary. Assuming that your intention was to match pop_state() and treat this opaquely as a stack rather than exposing its linked-list implementation, I'd have expected the function to look something like this: static void push_new_state(struct ref_formatting_state **stack) { struct ref_formatting_state *s = xcalloc(...); s->next = *stack; strbuf_init(&s->output, 0); *stack = s; } > +static void pop_state(struct ref_formatting_state **state) > +{ > + struct ref_formatting_state *current = *state; > + struct ref_formatting_state *prev = current->prev; > + > + strbuf_release(¤t->output); > + free(current); > + *state = prev; > +} This interface suggests that you're treating it as an opaque stack, in which case naming the argument 'stack' might be clearer. > /* > * In a format string, find the next occurrence of %(atom). > */ > @@ -1195,23 +1221,23 @@ void ref_array_sort(struct ref_sorting *sorting, struct ref_array *array) > qsort(array->items, array->nr, sizeof(struct ref_array_item *), compare_refs); > } > > -static void append_atom(struct atom_value *v, int quote_style, struct strbuf *output) > +static void append_atom(struct atom_value *v, struct ref_formatting_state *state) > { > - switch (quote_style) { > + switch (state->quote_style) { > case QUOTE_NONE: > - strbuf_addstr(output, v->s); > + strbuf_addstr(&state->output, v->s); > break; > case QUOTE_SHELL: > - sq_quote_buf(output, v->s); > + sq_quote_buf(&state->output, v->s); > break; > case QUOTE_PERL: > - perl_quote_buf(output, v->s); > + perl_quote_buf(&state->output, v->s); > break; > case QUOTE_PYTHON: > - python_quote_buf(output, v->s); > + python_quote_buf(&state->output, v->s); > break; > case QUOTE_TCL: > - tcl_quote_buf(output, v->s); > + tcl_quote_buf(&state->output, v->s); > break; > } > } This patch touches all the same lines as the previous patch which converted the code to append to a strbuf rather than emit to stdout, thus it makes the previous patch seem wasted and the current patch much noisier. As such, it might make sense to repartition these two patches as so: patch 2: Introduce ref_formatting_state (but without the 'prev' field), and update callers to append to its 'output' member rather than emitting to stdout. patch 3: Introduce the ref_formatting_state stack machinery; this patch would also add the 'prev' field. > @@ -1234,7 +1260,7 @@ static int hex2(const char *cp) > return -1; > } > > -static void append_literal(const char *cp, const char *ep, struct strbuf *output) > +static void append_literal(const char *cp, const char *ep, struct ref_formatting_state *state) > { > while (*cp && (!ep || cp < ep)) { > if (*cp == '%') { > @@ -1243,13 +1269,13 @@ static void append_literal(const char *cp, const char *ep, struct strbuf *output > else { > int ch = hex2(cp + 1); > if (0 <= ch) { > - strbuf_addch(output, ch); > + strbuf_addch(&state->output, ch); > cp += 3; > continue; > } > } > } > - strbuf_addch(output, *cp); > + strbuf_addch(&state->output, *cp); > cp++; > } > } > @@ -1257,20 +1283,24 @@ static void append_literal(const char *cp, const char *ep, struct strbuf *output > void show_ref_array_item(struct ref_array_item *info, const char *format, int quote_style) > { > const char *cp, *sp, *ep; > - struct strbuf output = STRBUF_INIT; > + struct strbuf *final_buf; > + struct ref_formatting_state *state = NULL; > + > + state = push_new_state(&state); > + state->quote_style = quote_style; > > for (cp = format; *cp && (sp = find_next(cp)); cp = ep + 1) { > struct atom_value *atomv; > > ep = strchr(sp, ')'); > if (cp < sp) > - append_literal(cp, sp, &output); > + append_literal(cp, sp, state); > get_ref_atom_value(info, parse_ref_filter_atom(sp + 2, ep), &atomv); > - append_atom(atomv, quote_style, &output); > + append_atom(atomv, state); > } > if (*cp) { > sp = cp + strlen(cp); > - append_literal(cp, sp, &output); > + append_literal(cp, sp, state); > } > if (need_color_reset_at_eol) { > struct atom_value resetv; > @@ -1279,11 +1309,12 @@ void show_ref_array_item(struct ref_array_item *info, const char *format, int qu > if (color_parse("reset", color) < 0) > die("BUG: couldn't parse 'reset' as a color"); > resetv.s = color; > - append_atom(&resetv, quote_style, &output); > + append_atom(&resetv, state); > } > - fwrite(output.buf, 1, output.len, stdout); > + final_buf = &state->output; > + fwrite(final_buf->buf, 1, final_buf->len, stdout); > + pop_state(&state); > putchar('\n'); > - strbuf_release(&output); > } > > /* If no sorting option is given, use refname to sort as default */ > -- > 2.5.0 ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH v11 03/13] ref-filter: introduce ref_formatting_state 2015-08-16 23:31 ` Eric Sunshine @ 2015-08-17 5:15 ` Eric Sunshine 2015-08-17 12:43 ` Karthik Nayak 1 sibling, 0 replies; 4+ messages in thread From: Eric Sunshine @ 2015-08-17 5:15 UTC (permalink / raw) To: Karthik Nayak; +Cc: Git List, Christian Couder, Matthieu Moy, Junio C Hamano On Sun, Aug 16, 2015 at 7:31 PM, Eric Sunshine <sunshine@sunshineco.com> wrote: > On Sat, Aug 15, 2015 at 2:00 PM, Karthik Nayak <karthik.188@gmail.com> wrote: >> +struct ref_formatting_state { >> + struct strbuf output; >> + struct ref_formatting_state *prev; > > Upon initial read-through of this patch, I found the name 'prev' > confusing since it seems you sometimes treat this as a linked-list > and, for a linked-list, this member is customarily named 'next'. > However, you also sometimes treat it as a stack, in which case 'prev' > makes a certain amount of sense semantically, although so does 'next'. > I'd probably have named it 'next', however, attr.c:struct attr_stack > names its member 'prev', so there is some precedence for the current > choice. s/precedence/precedent/ ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH v11 03/13] ref-filter: introduce ref_formatting_state 2015-08-16 23:31 ` Eric Sunshine 2015-08-17 5:15 ` Eric Sunshine @ 2015-08-17 12:43 ` Karthik Nayak 1 sibling, 0 replies; 4+ messages in thread From: Karthik Nayak @ 2015-08-17 12:43 UTC (permalink / raw) To: Eric Sunshine; +Cc: Git List, Christian Couder, Matthieu Moy, Junio C Hamano On Mon, Aug 17, 2015 at 5:01 AM, Eric Sunshine <sunshine@sunshineco.com> wrote: > On Sat, Aug 15, 2015 at 2:00 PM, Karthik Nayak <karthik.188@gmail.com> wrote: >> Introduce ref_formatting_state which will hold the formatted >> output strbuf and is used for nesting of modifier atoms. >> >> Signed-off-by: Karthik Nayak <karthik.188@gmail.com> >> --- >> diff --git a/ref-filter.c b/ref-filter.c >> index edfb1c7..3259363 100644 >> --- a/ref-filter.c >> +++ b/ref-filter.c >> @@ -55,6 +55,12 @@ static struct { >> { "color" }, >> }; >> >> +struct ref_formatting_state { >> + struct strbuf output; >> + struct ref_formatting_state *prev; > > Upon initial read-through of this patch, I found the name 'prev' > confusing since it seems you sometimes treat this as a linked-list > and, for a linked-list, this member is customarily named 'next'. > However, you also sometimes treat it as a stack, in which case 'prev' > makes a certain amount of sense semantically, although so does 'next'. > I'd probably have named it 'next', however, attr.c:struct attr_stack > names its member 'prev', so there is some precedence for the current > choice. Its sort of a stack in all sense, I mean we get new elements and push it onto the top and pop them once we're done. So that's why prev, also it's more of pushing the current state into the previously defined state. > > Also, it's customary for this member to be the first (or less > frequently last) member in the structure. > Ok will do that. >> + int quote_style; >> +}; >> + >> struct atom_value { >> const char *s; >> unsigned long ul; /* used for sorting when not FIELD_STR */ >> @@ -129,6 +135,26 @@ int parse_ref_filter_atom(const char *atom, const char *ep) >> return at; >> } >> >> +static struct ref_formatting_state *push_new_state(struct ref_formatting_state **state) > > This interface seems confused. The caller receives the new state as > both the return value of the function and as an out-value of its sole > argument. I'd suggest choosing one or the other. > > Which one you choose depends upon how you view the operation and the > data structure. If you view it as linked-list manipulation, then you'd > probably want the new state returned, and accept a pointer argument > (rather than pointer-to-pointer). On the other hand, if you view it as > a stack, then you'd probably want to have it return void and > manipulate the sole argument. For this case, it might be clearer to > name the argument 'stack' rather than 'state'. > I guess it makes to stick to the stack arrangement, will change the argument name to stack. >> +{ >> + struct ref_formatting_state *new_state = xcalloc(1, sizeof(struct ref_formatting_state)); >> + struct ref_formatting_state *tmp = *state; >> + >> + *state = new_state; >> + new_state->prev = tmp; >> + return new_state; >> +} > > A couple issues: > > First, you need to initialize the strbuf member of > ref_formatting_state after allocation: > > new_state = xcalloc(1, sizeof(struct ref_formatting_state)); > strbuf_init(&new_state->output, 0); > Was under the impression that strbuf_init() is not needed after a xcalloc, had to look at that again. > Second, if you re-order the code slightly, the 'tmp' variable becomes > unnecessary. > > Assuming that your intention was to match pop_state() and treat this > opaquely as a stack rather than exposing its linked-list > implementation, I'd have expected the function to look something like > this: > > static void push_new_state(struct ref_formatting_state **stack) > { > struct ref_formatting_state *s = xcalloc(...); > s->next = *stack; > strbuf_init(&s->output, 0); > *stack = s; > } > You mean: static void push_new_state(struct ref_formatting_state **stack) { struct ref_formatting_state *s = xcalloc(...); strbuf_init(&s->output, 0); s->prev = *stack; *stack = s; } >> +static void pop_state(struct ref_formatting_state **state) >> +{ >> + struct ref_formatting_state *current = *state; >> + struct ref_formatting_state *prev = current->prev; >> + >> + strbuf_release(¤t->output); >> + free(current); >> + *state = prev; >> +} > > This interface suggests that you're treating it as an opaque stack, in > which case naming the argument 'stack' might be clearer. > Will do thanks. >> /* >> * In a format string, find the next occurrence of %(atom). >> */ >> @@ -1195,23 +1221,23 @@ void ref_array_sort(struct ref_sorting *sorting, struct ref_array *array) >> qsort(array->items, array->nr, sizeof(struct ref_array_item *), compare_refs); >> } >> >> -static void append_atom(struct atom_value *v, int quote_style, struct strbuf *output) >> +static void append_atom(struct atom_value *v, struct ref_formatting_state *state) >> { >> - switch (quote_style) { >> + switch (state->quote_style) { >> case QUOTE_NONE: >> - strbuf_addstr(output, v->s); >> + strbuf_addstr(&state->output, v->s); >> break; >> case QUOTE_SHELL: >> - sq_quote_buf(output, v->s); >> + sq_quote_buf(&state->output, v->s); >> break; >> case QUOTE_PERL: >> - perl_quote_buf(output, v->s); >> + perl_quote_buf(&state->output, v->s); >> break; >> case QUOTE_PYTHON: >> - python_quote_buf(output, v->s); >> + python_quote_buf(&state->output, v->s); >> break; >> case QUOTE_TCL: >> - tcl_quote_buf(output, v->s); >> + tcl_quote_buf(&state->output, v->s); >> break; >> } >> } > > This patch touches all the same lines as the previous patch which > converted the code to append to a strbuf rather than emit to stdout, > thus it makes the previous patch seem wasted and the current patch > much noisier. As such, it might make sense to repartition these two > patches as so: > > patch 2: Introduce ref_formatting_state (but without the 'prev' > field), and update callers to append to its 'output' member rather > than emitting to stdout. > > patch 3: Introduce the ref_formatting_state stack machinery; this > patch would also add the 'prev' field. > This sounds good, will do this. -- Regards, Karthik Nayak ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2015-08-17 12:43 UTC | newest] Thread overview: 4+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2015-08-15 18:00 [PATCH v11 03/13] ref-filter: introduce ref_formatting_state Karthik Nayak 2015-08-16 23:31 ` Eric Sunshine 2015-08-17 5:15 ` Eric Sunshine 2015-08-17 12:43 ` Karthik Nayak
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).