Re: [core] implementer feedback on CORE-SID: Re: [mbj4668/pyang] Sid sx structure (PR #839)

Jernej Tuljak <jernej.tuljak@mg-soft.si> Sat, 25 March 2023 10:58 UTC

Return-Path: <jernej.tuljak@mg-soft.si>
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C79BDC14CE55 for <core@ietfa.amsl.com>; Sat, 25 Mar 2023 03:58:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mg-soft.si
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gN2-XmP1y8Bz for <core@ietfa.amsl.com>; Sat, 25 Mar 2023 03:58:03 -0700 (PDT)
Received: from galileo.mg-soft.si (gate.mg-soft.si [212.30.73.66]) by ietfa.amsl.com (Postfix) with ESMTP id C37C9C14CE40 for <core@ietf.org>; Sat, 25 Mar 2023 03:58:02 -0700 (PDT)
Received: from [127.0.0.1] (teleport2.mg-soft.si [10.0.0.254]) by galileo.mg-soft.si (Postfix) with ESMTP id 79246C41D787; Sat, 25 Mar 2023 11:58:00 +0100 (CET)
DKIM-Filter: OpenDKIM Filter v2.11.0 galileo.mg-soft.si 79246C41D787
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mg-soft.si; s=default; t=1679741880; bh=nINHxREbDsY3JTjmJLcdPCuubd3FokWjqahEDsjNjvE=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=MKaX4kaM7Lh82ljf2TNNMR65jdtUVeFt9p45G5UyKyTXuNCMJO3EK4jmZwulwDZMR cEf1AYDO24QyEvea12pmYlWr2kzBtN3oA5SWhHBnvSaP5npZGDX0pw7SxDWEWDpHGY eO5LWyVvsz7oXLl3jZa+8UkVlhxeY6PVli11I8vW9gpR+iRXMlnJU0lVSHw+8qvQQO ff9RFsSjBtUuhubVbDyZjSY3mKiU1P2EEqi0BGEryIykkttEMoCT1+oegMbprR7pmm mV+ZJMqoiEBOmS2/MXcwm5rowzTEzAtMDrb1Y7Cvf1W+xx8+FLk0DjKGxjmyTny2Ua XCWRX7LDLwjQQ==
Message-ID: <477a30f2-fce5-4efa-8c0c-d084dbe8cedd@mg-soft.si>
Date: Sat, 25 Mar 2023 11:58:00 +0100
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.12.0
Content-Language: en-US
To: Michael Richardson <mcr+ietf@sandelman.ca>
Cc: core@ietf.org
References: <mbj4668/pyang/pull/839@github.com> <mbj4668/pyang/pull/839/c1474951745@github.com> <2897262.1679232828@dyas> <bed2e140-d5e3-2aba-c2e1-6c8066602660@mg-soft.si> <28078.1679313444@localhost> <ea2899eb-e02c-9ad0-2ead-c0a341410225@mg-soft.si> <4633.1679579478@localhost>
From: Jernej Tuljak <jernej.tuljak@mg-soft.si>
In-Reply-To: <4633.1679579478@localhost>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/XYm3Vn2PZJcRhaCy5CrDELgAOF4>
Subject: Re: [core] implementer feedback on CORE-SID: Re: [mbj4668/pyang] Sid sx structure (PR #839)
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/core/>
List-Post: <mailto:core@ietf.org>
List-Help: <mailto:core-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 25 Mar 2023 10:58:08 -0000

On 23/03/2023 14:51, Michael Richardson wrote:
> Jernej Tuljak <jernej.tuljak@mg-soft.si> wrote:
>      > On 20/03/2023 12:57, Michael Richardson wrote:
>      >> Jernej Tuljak <jernej.tuljak@mg-soft.si> wrote:
>      >> > The issue I stumbled upon is not the number of mappings, but how the actual
>      >> > mapping for rc:yang_data is done after my changes compared to master.
>      >>
>      >> You have introduced a possible instability in assignments :-)
>      >> I can live with that as a one-time hit if it makes the code better, but are
>      >> you sure that your code is itself stable?  That might mean sorting keys of a
>      >> dict before using them.
>
>      > I'm not sure I understand what you meant. Were you referring to the change in
>      > the order of assignments for schema nodes? Yes, those occur in "pyang
>
> I'm asking if your new order of assignment would be stable even if the dict()
> implementation was changed, or if it ran on a different architecture.

I just realized that there is no "new order of assignment" in my fork 
compared to the original implementation. The order in which the YANG 
statements are iterated over in code is irrelevant, because all items 
are always sorted by namespace and identifier before any assignments are 
done. I did not change that. The only difference are the additional 
schema nodes that are now part of the mapping (choice, case, etc.).

Jernej

>
>      > I did go through all the tests to make sure nothing's breaking other than in
>      > expected ways, but the amount of cases those check is limited. That is also
>      > the only measure of stability I can provide at this time. I pushed (to my
>      > repo) the changes that would be required for test/test_sid yesterday.
>
> Thank you for going through those tests.
>
> --
> ]               Never tell me the odds!                 | ipv6 mesh networks [
> ]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
> ]     mcr@sandelman.ca  http://www.sandelman.ca/        |   ruby on rails    [
>