All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Yann E. MORIN" <yann.morin.1998@free.fr>
To: Romain Naour <romain.naour@gmail.com>
Cc: "Jörg Krause" <joerg.krause@embedded.rocks>, buildroot@buildroot.org
Subject: Re: [Buildroot] [PATCH 6/6] support/testing: test_luvi: make luvi test reproducible
Date: Fri, 12 Nov 2021 13:51:51 +0100	[thread overview]
Message-ID: <20211112125151.GI2609@scaer> (raw)
In-Reply-To: <20211112110007.787836-7-romain.naour@gmail.com>

Romain, All,

On 2021-11-12 12:00 +0100, Romain Naour spake thusly:
> As explained by Jörg [1], iteration with pairs() does not result in the
> same order since luajit 2.1.
> 
> From [2]
> "Table iteration with pairs() does not result in the same order?
> 
> The order of table iteration is explicitly undefined by the Lua
> language standard. Different Lua implementations or versions may use
> different orders for otherwise identical tables. Different ways of
> constructing a table may result in different orders, too. Due to
> improved VM security, LuaJIT 2.1 may even use a different order on
> separate VM invocations or when string keys are newly interned.
> 
> If your program relies on a deterministic order, it has a bug.
> Rewrite it, so it doesn't rely on the key order.
> Or sort the table keys, if you must."
> 
> [1] http://lists.busybox.net/pipermail/buildroot/2021-November/627938.html
> [2] https://luajit.org/faq.html
> 
> Signed-off-by: Romain Naour <romain.naour@gmail.com>
> Cc: Francois Perrad <francois.perrad@gadz.org>
> Cc: Jörg Krause <joerg.krause@embedded.rocks>
> ---
>  support/testing/tests/package/test_luvi.py | 10 +++++-----
>  1 file changed, 5 insertions(+), 5 deletions(-)
> 
> diff --git a/support/testing/tests/package/test_luvi.py b/support/testing/tests/package/test_luvi.py
> index eb15ad31b5..27155a75b6 100644
> --- a/support/testing/tests/package/test_luvi.py
> +++ b/support/testing/tests/package/test_luvi.py
> @@ -23,13 +23,13 @@ class TestLuvi(infra.basetest.BRTest):
>          self.emulator.login()
>  
>      def version_test(self):
> -        cmd = "luvi -v"
> +        cmd = "luvi -v | sort"

The issue with this is that, should 'luvi -v' fail, the command will not
fail, because of the pipe. Indeed, the result of a pipe is the result of
the right-most command, in this case 'sort', which I don't think would
ever fail in practice in this case.

So, to properly catch that 'luvi -v' fails, you would sort in the python
code, something like (assuming the luvi version alwas comes first?):

    cmd = "luvi -v"
    output, exit_code = self.emulator.run(cmd)
    self.assertEqual(exit_code, 0)
    self.assertIn('luvi', output[0])
    output = sorted(output[1:])
    self.assertIn('libuv', output[0])
    self.assertIn('luvi', output[1])
    self.assertIn('rex', output[2])
    self.assertIn('ssl', output[3])
    self.assertIn('zlib', output[4])

Regards,
Yann E. MORIN.

>          output, exit_code = self.emulator.run(cmd)
> -        self.assertIn('luvi', output[0])
> -        self.assertIn('zlib', output[1])
> +        self.assertIn('libuv', output[0])
> +        self.assertIn('luvi', output[1])
>          self.assertIn('rex', output[2])
> -        self.assertIn('libuv', output[3])
> -        self.assertIn('ssl', output[4])
> +        self.assertIn('ssl', output[3])
> +        self.assertIn('zlib', output[4])
>  
>      def test_run(self):
>          self.login()
> -- 
> 2.31.1
> 
> _______________________________________________
> buildroot mailing list
> buildroot@buildroot.org
> https://lists.buildroot.org/mailman/listinfo/buildroot

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 561 099 427 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

  reply	other threads:[~2021-11-12 12:52 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-11-12 11:00 [Buildroot] [PATCH 0/6] rework luvi test in gitlab after luajit version bump Romain Naour
2021-11-12 11:00 ` [Buildroot] [PATCH 1/6] package/luvi: don't use LUAJIT_VERSION for the luajit installation path Romain Naour
2021-11-12 13:02   ` Yann E. MORIN
2021-11-12 13:07   ` Yann E. MORIN
2021-11-12 18:50     ` Romain Naour
2021-11-12 11:00 ` [Buildroot] [PATCH 2/6] support/testing: test_luvi: switch to armv5 to boot with rng support enabled Romain Naour
2021-11-12 11:00 ` [Buildroot] [PATCH 3/6] package/luajit: rework BR2_PACKAGE_LUAJIT_ARCH_SUPPORTS Romain Naour
2021-11-12 11:00 ` [Buildroot] [PATCH 4/6] package/luajit: building for 64-bit target requires a 64-bit host for all platform Romain Naour
2021-11-12 12:56   ` Yann E. MORIN
2021-11-12 18:38     ` Romain Naour
2021-11-12 11:00 ` [Buildroot] [PATCH 5/6] package/luajit: disable 64 bit GC objects Romain Naour
2021-11-12 11:00 ` [Buildroot] [PATCH 6/6] support/testing: test_luvi: make luvi test reproducible Romain Naour
2021-11-12 12:51   ` Yann E. MORIN [this message]
2021-11-12 18:35     ` Romain Naour

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20211112125151.GI2609@scaer \
    --to=yann.morin.1998@free.fr \
    --cc=buildroot@buildroot.org \
    --cc=joerg.krause@embedded.rocks \
    --cc=romain.naour@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.