all lists on lists.proxmox.com
 help / color / mirror / Atom feed
From: Thomas Lamprecht <t.lamprecht@proxmox.com>
To: Dominik Csapak <d.csapak@proxmox.com>,
	Dietmar Maurer <dietmar@proxmox.com>,
	Wolfgang Bumiller <w.bumiller@proxmox.com>
Cc: pmg-devel@lists.proxmox.com
Subject: Re: [pmg-devel] applied: [PATCH] panel/acme-domains: fix cyclic dependency in view model
Date: Wed, 24 Mar 2021 08:34:50 +0100	[thread overview]
Message-ID: <e2d76229-50d8-51e0-7b87-0decc0d9808d@proxmox.com> (raw)
In-Reply-To: <1652ef3e-d29c-45a4-8dfa-09db3322260b@proxmox.com>

On 24.03.21 08:31, Dominik Csapak wrote:
> On 3/24/21 08:21, Thomas Lamprecht wrote:
>> On 23.03.21 19:22, Dietmar Maurer wrote:
>>>> So, if on evaluation a get(X) is missed due to it being not always called,
>>>> like with boolean statements where a single truthy is enough for an or expression
>>>> like above, that data dependency is lost and one may see bug like behaviour.
>>>>
>>>> Use intermediate variables to combat that, for example, above `accountValueHidden`
>>>> formula should read:
>>>>
>>>> accountValueHidden: (get) => {
>>>>      let editable = get('accountEditable'), available = get('accountsAvailable');
>>>>      return !editable || !available;
>>>> },
>>>
>>> I guess a good JIT can still optimize that away?
>>>
>>
>>
>> You're right, that may be the case.
>> Albeit, I guess that for such short method where the JS engine cannot know if it is
>> a "hot" function (lots calls) so the JIT won't be used initially, and the interpreter
>> probably isn't smart enough to detect this optimization.
>>
>> At least above approach helped a bit ago when I ran in such a bug, but 
yeah, it may
>> not be really future proof...
>>
>>
> 
> but AFAIR, extjs actually parses the function *text* to find the
> data dependencies (see https://docs.sencha.com/extjs/6.0.1/classic/src/Formula.js.html)
> 

here the rendered docs version of that source code link
https://docs.sencha.com/extjs/6.0.1/classic/Ext.app.bind.Formula.html

> and i hope that the JIT does not change the text of the function
> at all....
> 

Not sure if there are any guarantees on that and not touching the src.
But yeah I slowly remember, and my issue then probably came from an use of
a variable as get parameter, which then naturally cannot work.




  reply	other threads:[~2021-03-24  7:35 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-23 18:22 Dietmar Maurer
2021-03-24  7:21 ` Thomas Lamprecht
2021-03-24  7:31   ` Dominik Csapak
2021-03-24  7:34     ` Thomas Lamprecht [this message]
  -- strict thread matches above, loose matches on Subject: below --
2021-03-23 16:29 Thomas Lamprecht
2021-03-23 17:27 ` Thomas Lamprecht

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=e2d76229-50d8-51e0-7b87-0decc0d9808d@proxmox.com \
    --to=t.lamprecht@proxmox.com \
    --cc=d.csapak@proxmox.com \
    --cc=dietmar@proxmox.com \
    --cc=pmg-devel@lists.proxmox.com \
    --cc=w.bumiller@proxmox.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.
Service provided by Proxmox Server Solutions GmbH | Privacy | Legal