> -----Original Message-----
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of
> Alexander Strasser
> Sent: Tuesday, May 07, 2019 6:21 AM
> To: FFmpeg development discussions and patches <ffmpeg-devel@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [PATCH V5 1/2] configure: sort
> decoder/encoder/filter/... names in alphabet order
>
> On 2019-05-05 21:14 +0000, avih wrote:
> > > I guess you were looking at the right patch. I mean this one:
> > > http://ffmpeg.org/pipermail/ffmpeg-devel/2019-May/243380.html
> >
> > I was referring to this patch indeed. Thanks.
> >
> >
> > > > > Agreed; of course we shouldn't just use awk because we can.
> > > > >
> > > > > Though I think not implementing things in shell is often
> > > > > lower risk, as we have no isolation in POSIX shell, we all
> > > > > share the same variables etc. and the configure script is
> > > > > quite big. Then shell is not suited for many tasks because
> > > > > of the way it works
> > > > > ...
> > > >
> > > > This actually sounds to me like you're saying we shouldn't use awk
> because
> > > > we can, but rather use it where possible because it'd be better than
> > > > shell.
> > > >
> > > > In other words: we should write new configure code in awk.
> > > >
> > > > Did I misinterpret the statement or its implications?
> > >
> > > You got me totally wrong :(
> >
> >
> > I'm only human, it happens. But you didn't explain what you actually meant.
>
> It's a communication problem. I tried to explain why I prefer
> the awk version over the shell version of this patch in the email
> before. Seems I was too vague.
>
> I will try to answer your specific questions. If there is more
> to discuss, please don't hesitate to ask.
>
> > Specifically:
> >
> > - What makes this patch a good candidate to use awk rather than shell like
> > the rest of configure?
>
> I would like to rephrase this question a bit. I guess the other aspect
> will be in my answer to your next question anyway.
>
> patch1 (awk) configure: print_in_columns: replace pr with awk version:
> http://ffmpeg.org/pipermail/ffmpeg-devel/2019-May/243380.html
> patch2 (shell) configure: sort decoder/encoder/filter/... names in alphabet
> order (v5 as posted in this thread)
>
> - Why do you prefer patch1 over patch2?
>
> 1. Statistics
> * patch1: 1 file changed, 16 insertions(+), 2 deletions(-)
> * patch2: 1 file changed, 24 insertions(+), 2 deletions(-)
I have no idea which one is better, but I think this point is not the reason.
we can refine the shell patch as below with 15 insertions(+), 2 deletions(-1).
Actually, the line number does not mean something. :)
print_in_columns() {
# the input should not contain chars such as '*', otherwise it will be
expanded.
set -- $(tr ' ' '\n' | sort)
test $ncols -lt 24 && col_width=$ncols || col_width=24
cols=$(($ncols / $col_width))
rows=$(($(($# + $cols - 1)) / $cols))
cols_seq=$(seq $cols)
for row in $(seq $rows); do
print_index=$row
print_line=""
for col in $cols_seq; do
test $print_index -le $# && eval print_line='"$print_line
"${'$print_index'}'
print_index=$(($print_index + $rows))
done
printf "%-${col_width}s" $print_line; printf "\n"
done | sed 's/ *$//'
}
the usage of "test && ||" is already used in configure.
> 2. patch2 uses lots of variables (which is good in itself), but those
> should be local and we cannot express that portably in shell.
> In turn we have raised potential for clashes now or in the future.
> 3. patch2 uses eval combined with non-trivial quoting, which is hard
> to read and hard to grasp quickly. It's not wrong, but it's not as
> easy and straight forward as in patch1.
> 4. Depending on the input (stdin) unexpected things can happen in the
> "eval" and "set" lines. One example is given in the comment.
> 5. patch2 to uses shell for the parts easily expressed in shell and
> uses awk for the parts that are non-trivial in shell.
> 6. The awk implementation should be easier to read and understand for
> the majority of readers/developers.
>
>
> > - What should be the general criteria to choose a scripting language for
> > future patches?
>
> I don't see anywhere that we switch away from shell for configure. So in
> general things should be implemented in shell. Shell though is not really
> suited for implementing all kinds of algorithms. OTOH shell is an excellent
> choice for starting processes that communicate via stdin/stdout/stderr
> and plugging them together.
>
> So I think programming shell, sticking only to shell itself (builtins) is
> almost never a good option. Shell is best when coordinating the execution
> of other programs. Sometimes when you do not have a particular program
> around to help you in your shell script, that void needs to be filled.
> For this purpose awk is often a good choice, because it was especially
> designed to be a fit for this purpose amongst other things. Using only awk
> to implement bigger systems or as a general purpose programming language
> is IMHO nearly as wrong as using shell-only.
>
>
> > On Saturday, May 4, 2019 10:43 PM, Alexander Strasser
> <eclip...@gmx.net> wrote:
> [...]
>
>
> I'm feeling like I might not have expressed my reasoning good and
> precise enough in every level of detail. I apologize for that. My
> natural language skills have their limits and I am not a native
> English speaker. I will try to refine specific points, should you
> or anyone else have more questions or comments.
>
>
> Alexander
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
