> I intent to push the awk version. I will wait at least until
> Thursday, so people can further test, comment, or object.
No further comments here.
Thanks!
Avi
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
> 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?
t should be the general criteria to choose a scripting language for
future patches?
On Saturday, May 4, 2019 10:43 PM, Alexander Strasser
wrote:
Hi!
On 2019-05-04 06:28 +, avih wrote:
> > On 2019-05-02 08:55 +, avih wrote:
> > > > It seems awk is unconditi
> On 2019-05-02 08:55 +0000, avih wrote:
> > > It seems awk is unconditionally required already. However I wanted to
> > > say that it's a very nice dep to have
> >
> > While it's possibly nicer than other deps to have, it's still better to use
> > it
> It seems awk is unconditionally required already. However I wanted to
> say that it's a very nice dep to have
While it's possibly nicer than other deps to have, it's still better to use
it IMHO only when it adds some value, like simpler code, better performance,
compliance with some things,
> What do you think about using awk instead of shell?
No objection here, especially if it's more robust in some ways than this
or other shell code (though personally I'm not fluent in awk).
My only concern was preventing a considerable performance impact which could
otherwise be avoided
> print_in_columns() {
> - cols=$(expr $ncols / 24)
> - cat | tr ' ' '\n' | sort | pr -r "-$cols" -w $ncols -t
> + # the input should not contain chars such as '*',
> + # otherwise, '*' will be expanded to be all files in the current
> + # working directory which don't begin with a
> log_file(){
> - log BEGIN $1
> - pr -n -t $1 >> $logfile
> - log END $1
> + log BEGIN "$1"
> + log_file_i=1
> + while IFS= read -r log_file_line;do
> + printf '%5s %s\n' "${log_file_i}" "${log_file_line}"
> + log_file_i=$(($log_file_i+1))
> + done < "$1" >>
> how about add the keyword local which makes the variables not global.
No. It's not portable and not standard, and will break with a lot of shells
which ffmpeg currently supports.
Different shells have different ways to limit a variable scope to the current
function, some don't have a way at
gin with a dot (`.`).
On Wednesday, April 24, 2019 12:08 PM, avih wrote:
> btw, I tried read as following, looks that read also expands '*':
> print_in_columns() {
> read inputs
> echo $inputs
> }
No. It expands at `echo` because you didn't quote `$inputs`.
As I commented
> btw, I tried read as following, looks that read also expands '*':
> print_in_columns() {
> read inputs
> echo $inputs
> }
No. It expands at `echo` because you didn't quote `$inputs`.
As I commented on your v4 part 2 patch, you _must_ quote all strings unless
you know for a fact that
> log_file(){
> log BEGIN $1
> - pr -n -t $1 >> $logfile
> + i=1
Shell variables are global. This means that any part of the code which ends
up calling `log_file` directly or through some other function (and not isolated
in a subshell) will get its `i` variable clobbered by `log_file`.
's a good practice in general where possible, so it's fine to keep it.
- To measure the runtime of a program you can do `time program `.
To measure the runtime of sections in a script you can use `time.sh` which I
used with `configure` in the past - https://github.com/avih/time.sh .
> To check a
> print_in_columns() {
> - cols=$(expr $ncols / 24)
> - cat | tr ' ' '\n' | sort | pr -r "-$cols" -w $ncols -t
> + col_width=24
> + cols=$(expr $ncols / $col_width)
> + rows=$(expr $(expr $# + $cols - 1) / $cols)
> + for row in $(seq $rows); do
> + index=$row
> +
of the attached patch.
Avi
From 4940963648cb431f1a8e827adefb58d318186b38 Mon Sep 17 00:00:00 2001
From: "Avi Halachmi (:avih)"
Date: Tue, 28 Aug 2018 17:14:55 +0300
Subject: [PATCH] configure: _deps: validate, reduce sensitivity
- Allow to add deps in any order rather than "in linking o
was another matter though. I had to build a nice magnet
(time.sh) to find the needles in this haystack ;)
Glad others like it too.
Avi
On Monday, August 27, 2018 5:49 PM, James Almer wrote:
On 8/25/2018 6:15 PM, Michael Niedermayer wrote:
> On Sat, Aug 25, 2018 at 06:11:10PM +0000, a
the commit message accordingly.
It fixes the linkage failures mentioned
at:http://ffmpeg.org/pipermail/ffmpeg-devel/2018-August/233674.html
On Saturday, August 25, 2018 9:09 PM, avih
wrote:
For overview see:
http://ffmpeg.org/pipermail/ffmpeg-devel/2018-August/233665.html
Attached is patch
From d1cf17fdb518b3a456bbac61e306599d0a4a7400 Mon Sep 17 00:00:00 2001
From: "Avi Halachmi (:avih)"
Date: Mon, 30 Jul 2018 22:48:04 +0300
Subject: [PATCH] configure: print_enabled_components(): speedup x4 - x10
Inside print_enabled components, the filter_list case invokes sed
about 350 times to parse
7 00:00:00 2001
From: "Avi Halachmi (:avih)"
Date: Sun, 5 Aug 2018 06:16:44 +0300
Subject: [PATCH] configure: check_deps(): x4 - x25 speedup
check_deps() recursively enables/disables components, and its loop is
iterated nearly 6000 times. It's particularly slow in bash - currently
consum
ause any regressions.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
From 7593d9f6580afd8a1066df1e1910a817d7c2fff1 Mon Sep 17 00:00:00 2001
From: "Avi Halachmi (:avih)"
Date: Mon, 30 Jul 2018 22:39:15 +0
Thanks.
I'll post the 3 parts of main.patch unmodified as individualemails like Timo
requested, and then I'll look at the failures.
On Saturday, August 25, 2018 9:00 PM, Michael Niedermayer
wrote:
On Sat, Aug 25, 2018 at 02:33:03PM +, avih wrote:
> Hi,
>
>
ir help with testing.
This is my first mail to this list, and I wasn't sure how to split the
patches. After asking a veteran, it was suggested to me that I should
put all of them in one email. Just let me know if you prefer something
else (dev mailing lists are not my fo
22 matches
Mail list logo
