Seem to be getting warnings when using ember-cp-validations

I'm getting warnings when in my console:
Ember      : 2.5.0-canary+f2684115
Ember Data : 2.5.0-canary+8dc694025e

WARNING: Dependent keys containing @each only work one level deep. You cannot use nested forms like<EMAIL_ADDRESS>or todos<EMAIL_ADDRESS>Please create an intermediary computed property.
ember.debug.js:27627
WARNING: Dependent keys containing @each only work one level deep. You cannot use nested forms like<EMAIL_ADDRESS>or todos<EMAIL_ADDRESS>Please create an intermediary computed property.

Can you add a snippet of your Validations?
On Monday, February 15, 2016, robbyoconnor<EMAIL_ADDRESS>wrote:

I'm getting warnings when in my console:
Ember      : 2.5.0-canary+f2684115
Ember Data : 2.5.0-canary+8dc694025e
WARNING: Dependent keys containing @each https://github.com/each only
work one level deep. You cannot use nested forms like
<EMAIL_ADDRESS><javascript:_e(%7B%7D,'cvml','todos.@each.owner.name');> or todos.@
<EMAIL_ADDRESS><javascript:_e(%7B%7D,'cvml','each.owner.@each.name');>. Please create an
intermediary computed property.
ember.debug.js:27627
WARNING: Dependent keys containing @each https://github.com/each only
work one level deep. You cannot use nested forms like
<EMAIL_ADDRESS><javascript:_e(%7B%7D,'cvml','todos.@each.owner.name');> or todos.@
<EMAIL_ADDRESS><javascript:_e(%7B%7D,'cvml','each.owner.@each.name');>. Please create an
intermediary computed property.
—
Reply to this email directly or view it on GitHub
https://github.com/offirgolan/ember-cp-validations/issues/119.

--
Thanks,
Offir Golan

It was a simple date validator a couple presence validators -- no dependent relationships
On 02/15/2016 03:06 PM, Offir Golan wrote:

Can you add a snippet of your Validations?
On Monday, February 15, 2016, robbyoconnor<EMAIL_ADDRESS>wrote:

I'm getting warnings when in my console:
Ember : 2.5.0-canary+f2684115
Ember Data : 2.5.0-canary+8dc694025e
WARNING: Dependent keys containing @each https://github.com/each only
work one level deep. You cannot use nested forms like
<EMAIL_ADDRESS><javascript:_e(%7B%7D,'cvml','todos.@each.owner.name');> or todos.@
<EMAIL_ADDRESS><javascript:_e(%7B%7D,'cvml','each.owner.@each.name');>. Please create an
intermediary computed property.
ember.debug.js:27627
WARNING: Dependent keys containing @each https://github.com/each only
work one level deep. You cannot use nested forms like
<EMAIL_ADDRESS><javascript:_e(%7B%7D,'cvml','todos.@each.owner.name');> or todos.@
<EMAIL_ADDRESS><javascript:_e(%7B%7D,'cvml','each.owner.@each.name');>. Please create an
intermediary computed property.
—
Reply to this email directly or view it on GitHub
https://github.com/offirgolan/ember-cp-validations/issues/119.

--
Thanks,
Offir Golan
—
Reply to this email directly or view it on GitHub
https://github.com/offirgolan/ember-cp-validations/issues/119#issuecomment-184367821.

It was a simple date validator and a large chunk of it was taken from the dummy app as a reference.

:+1: thanks for bringing this to my attention. Ill take a deeper look when I have some time

Fixed with v2.4.1

Hi,
I'd like to add you to my professional network on LinkedIn.

Robert

Confirm that you know Robert: https://www.linkedin.com/e/v2?e=0-ini67ojs-nd&t=ssuw&tracking=eml-guest-invite-cta&ek=invite_guest&sharedKey=2rvcOple&invitationId=6130897019268579328
You received an invitation to connect. LinkedIn will use your email address to make suggestions to our members in features like People You May Know. Unsubscribe here: https://www.linkedin.com/e/v2?e=0-ini67ojs-nd&t=lun&midToken=AQFmrFVhGEd36Q&ek=invite_guest&loid=AQGx4jxtCDN9WQAAAVRVSbl1YSwe7_lJbmq4uXq45BhrHI2B3jP-FuDB6OlYqjGQjHKa5lI52FFV6EcvaJsstH4ArTqIxHtNr_2nNBysifv42VFJAHRFrjuJ-BR5J4m-W8CZZiAiyN7C6qDRZSrXtrb3OyZqXoSwhHnl1kdx5d0V9_MHjuEHLOAearkBaAH2Qa33&eid=0-ini67ojs-nd
This email was sent to<EMAIL_ADDRESS>If you need assistance or have questions, please contact LinkedIn Customer Service: https://www.linkedin.com/e/v2?e=0-ini67ojs-nd&a=customerServiceUrl&ek=invite_guest
© 2016 LinkedIn Corporation, 2029 Stierlin Court, Mountain View CA 94043. LinkedIn and the LinkedIn logo are registered trademarks of LinkedIn.


Skip loading unneeded blocks during initial parsing

WIP.  PR to trigger running the tests.

Hm, I hoped merging the PR, no which this one is build would be detected by GitHub.
Please rebase this PR as follows:
~/omnicore$ git fetch upstream omnicore-0.0.10
~/omnicore$ git checkout omnicore-0.0.10
~/omnicore$ git pull upstream omnicore-0.0.10
~/omnicore$ git checkout 0.0.10-Z-DexX-TestSkipBlockList
~/omnicore$ git rebase omnicore-0.0.10

I tend to hold back this PR until the very end, because it greatly reduces the potential of the consensus tests run on the CI server?

PrintToConsole("%s(): to insert %d elements: %.4f ms\n", __func__, blockList.size(), 0.001 * nTime);

Should probably be replaced by something like:
PrintToLog("%s(): going to skip %d blocks [loading time: %.4f ms]\n", __func__, blockList.size(), 0.001 * nTime);

... or similar.

I tend to hold back this PR until the very end, because it greatly reduces the potential of the consensus tests run on the CI server?

This PR was really only just to trigger the consensus tests to see if my new block list was good :)
Can you explain what you mean about reducing potential for consensus tests on CI?

The CI server currently starts fresh, and parses all Omni transactions. If we apply this PR, then certain blocks are skipped, and errors, we may have introduced, may be undetected.
Rephrased: parsing with enabled skipping is less thorough.
Alternatively, and I think this would be useful in general, we could add an option/flag to disable skipping.

The CI server currently starts fresh, and parses all Omni transactions. If we apply this PR, then certain blocks are skipped, and errors, we may have introduced, may be undetected.

Ahh I see what you mean.

Alternatively, and I think this would be useful in general, we could add an option/flag to disable skipping.

Yeah, we'll absolutely add a --seedblockfilter=false so users can opt-out - could the CI jobs just be adjusted to run with this flag?

Yes! :)
Maybe it should be -omnixxxxx though.

Interesting - adding commits didn't trigger CI this time?

After I realized I pushed a PR, which was going to fail due to the missing rules.h include, I stopped the pending Travis jobs (which were going to fail, as consequence of the failing base).
Looks like this also prevented that new pushes triggered new builds.
Check out: https://travis-ci.org/OmniLayer/omnicore/pull_requests
The grey ones can be restarted (actually any job) in the detail view with a click on the restart/replay button:

I see now yep thanks - assume you already pushed the button :)

Something seems to be broken:
https://travis-ci.org/OmniLayer/omnicore/jobs/71184933#L2533
Though it's nearly impossible it has anything to do with this PR.

Mainnet consensus is fine by the way.

Mainnet consensus is fine by the way.

Nice, so the new block list is good then I believe - now we just need to decide how we want to code the list in...

Nice, so the new block list is good then I believe - now we just need to decide how we want to code the list in...

I suggest to revert the AddBlockStr() stuff, given that this was created based on a misunderstanding/miscommuncation from my side.
Other than that, I'm not really sure what to add here. We could just use the string based list and refine later, or try to find an alternative. On the other hand, this would be purely cosmetic, given that even the cluttered string based list is processed within milliseconds.
From another perspective: do you see any risk/potential pitfalls with this approach in general?

I suggest to revert the AddBlockStr() stuff, given that this was created based on a misunderstanding/miscommuncation from my side.

I think it was me who misunderstood mate :)
Reverted and updated the blockString in https://github.com/zathras-crypto/omnicore/commit/3c05139834a8538013d11e15ae1ecee0d34094e1

From another perspective: do you see any risk/potential pitfalls with this approach in general?

Nope, it is purely cosmetic as you note and if we want to refine it we can do so at a later date, for now it does the job it needs to do.

Looks like this also prevented that new pushes triggered new builds.

I'm not quite sure why but seems this is still the case - that last commit didn't trigger a Travis run, I checked on the dashboard and the last build for this PR was 362 which was successful.

I'm not quite sure why but seems this is still the case ...

I'm not sure either. Tried to manually start it a few seconds ago.
I'm going to take another look at this PR, and see, if we can create some kind of structure with starting height, end height, network and the block list - hopefully later.
Other than that, I wouldn't say I have a bad feeling, especially because I trust in tests and if we don't touch the parsing code (and introduce bugs), then this will produce the same results. Nevertheless, I'd feel more comfortable, once we have consensus checkpoints. This however, is something for the future, and it shouldn't hold back this PR.
So my plan:

[x] Update OmniJ (pending, but initiated)
[ ] Another code check and thinking it through
[ ] Potentially minimal refactoring

Do you think it would make sense to wrap the block list into a signed message, say signed with 1Exodus, to ensure the data isn't tampered?

I haven't tested it on mainnet, but compilation works fine, without huge memory consumption spike:
static std::set<int> GetBlockList()
{
    int blocks[] = {249498, 249536, 249559, 249560, /* ... */ 365219};
    return std::set<int>(blocks, blocks + sizeof(blocks)/sizeof(blocks[0]));
}

I'd really like to introduce a structure similar to CChainParams in the future, to handle some base information for different networks. This could then include the block list (and eventually consensus rules/activations).
At this point though, I'm not really sure how to start, so I suggest to continue with the current version of this PR (potentially with the change of https://github.com/OmniLayer/omnicore/pull/135#issuecomment-123912157), and then restructure later.
As alternative to a signed block list, do you think it would be possible (and cheap) to determine the number of valid transactions at any given point? If so, we may add at least some kind of checkpoint, where the number of valid transactions (after scanning) is compared against an expected value?

Do you think it would make sense to wrap the block list into a signed message, say signed with 1Exodus, to ensure the data isn't tampered?

  Plus we'd want to be able to update the list in the future.  With that said though, I don't really see much value to this because if someone has the ability to tamper with the source code there are much more useful modifications to make than adding/removing skipped blocks (such as redirecting funds or sending  keys to remote servers etc etc).

I haven't tested it on mainnet, but compilation works fine, without huge memory consumption spike:

Oh nice, that sounds like it could be a good method - any reason not to go this way?

I'd really like to introduce a structure similar to CChainParams in the future, to handle some base information for different networks. This could then include the block list (and eventually consensus rules/activations).

I think this would be a good idea, but I'm not intimately familiar with CChainParams so would need to research/review that a bit - but yep certainly could be a direction for the future, no objections from me there...

we may add at least some kind of checkpoint, where the number of valid transactions (after scanning) is compared against an expected value?

I have some random thoughts in this area, let me try and make them coherent and I'll reply properly to this later with some bits of code I have too :)

Oh nice, that sounds like it could be a good method - any reason not to go this way?

I'd say, let's go with it. I just wanted to point out that I just tested it locally without chain.

I have some random thoughts in this area, let me try and make them coherent and I'll reply properly to this later with some bits of code I have too :)

See, my point is basically the following: you published a block list, and I trust you, and I believe you didn't tamper the list, but how could I know this is the right list (and no block with DEx payment was accidently left out, which wasn't detected by the consensus tests for any reason, just to name an example)?
If I, as maintainer, am not able to answer this question properly, then I don't have a good feeling of publishing the list without any safe guard/integrity check/[...]. Is there a handy way to reproduce the list? If so, we should point that out as comment.

we may add at least some kind of checkpoint, where the number of valid transactions (after scanning) is compared against an expected value?

I have some random thoughts in this area, let me try and make them coherent and I'll reply properly to this later with some bits of code I have too :)

Let me know what you think of #145 when you have a spare mo mate, and whether this goes towards helping with concerns over the block list...

Let me know what you think ...

I love it! :)
My last open question/remark: how was the block list created?

how was the block list created?

Nothing particularly brilliant mate hehe, just a bunch of printf's scattered throughout the code to dump the block numbers for various bits during a full parse from scratch with the output pumped into sort & uniq.

@zathras-crypto: OmniJ was updated. Could you try https://github.com/OmniLayer/omnicore/pull/135#issuecomment-123912157, if you find some time? :)
I suggtest to merge #145 (once empty entries are skipped), then this one.

Could you try #135 (comment), if you find some time? :)

Sure! :)  But I think I broke something hehe...  At least the new stuff from #145 is doing its job...  I'm investigating further now but have a plane to catch so might take a little while...
$ src/omnicored --server --daemon --checkblocks=1 --startclean
Omni Core server starting
2015-07-26 06:20:07 Initializing Omni Core v<IP_ADDRESS>-dev [main]
2015-07-26 06:20:07 Loading trades database: OK
2015-07-26 06:20:07 Loading send-to-owners database: OK
2015-07-26 06:20:07 Loading transactions database: OK
2015-07-26 06:20:07 Loading smart property database: OK
2015-07-26 06:20:07 Loading persistent state: NONE
2015-07-26 06:20:07 Scanning for transactions in block 249498 to block 360003..
Error: Shutting down due to failed checkpoint for block 270000 (hash<PHONE_NUMBER>000002a775aec59dc6a9e4bb1c025cf1b8c2195dd9dc3998c827c5)
2015-07-26 06:20:15 Scan stopped early at block 270001 of block 360003
2015-07-26 06:20:15 363731 transactions processed, 639 meta transactions found
2015-07-26 06:20:15 Exodus balance: 7648.97980178 MSC
2015-07-26 06:20:15 Omni Core initialization completed
2015-07-26 06:20:15 Omni Core shutdown completed

$ tail -100 ~/.bitcoin/omnicore.log | grep -i verifycheckpoint
2015-07-26 06:20:15 VerifyCheckpoint(): consensus hash mismatch - expected 486a81cb5b0c89d26543e85f2635f225468e87bda89e752ab2dcebf1d2f74248, received 4eb6f75c961308c18dad1e2677170465f30d367489e61cb2510e400dc3d21117

Even more interesting (note seed block filter disabled):
$ src/omnicored --server --daemon --checkblocks=1 --startclean --omniseedblockfilter=false
Omni Core server starting
rich@lenlaptop:~/github/build/omnicore$ 2015-07-26 06:39:53 Initializing Omni Core v<IP_ADDRESS>-dev [main]
2015-07-26 06:39:53 Loading trades database: OK
2015-07-26 06:39:53 Loading send-to-owners database: OK
2015-07-26 06:39:53 Loading transactions database: OK
2015-07-26 06:39:53 Loading smart property database: OK
2015-07-26 06:39:53 Loading persistent state: NONE
2015-07-26 06:39:53 Scanning for transactions in block 249498 to block 360003..
2015-07-26 06:40:23 Still scanning.. at block 255315 of 360003. Progress: 3.42 %, about 14:03 minutes remaining..
2015-07-26 06:40:53 Still scanning.. at block 261212 of 360003. Progress: 6.77 %, about 13:44 minutes remaining..
2015-07-26 06:41:23 Still scanning.. at block 267242 of 360003. Progress: 9.95 %, about 13:33 minutes remaining..
Error: Shutting down due to failed checkpoint for block 270000 (hash<PHONE_NUMBER>000002a775aec59dc6a9e4bb1c025cf1b8c2195dd9dc3998c827c5)

Note, this may be down to the exclusion of empty balances, and I may need to regenerate the checkpoints...  Will report back...

Alrighty, it's definitely the change to filter empty entries from the consensus hash.  What's got me confused is why Travis didn't pick this up, the CI build would have aborted at block 270000 during parsing for the consensus tests due to a failed checkpoint.
Anywho, the fix is simple, I've generated some new checkpoints based on the new consensus hashing code that filters empty balances.

Could you try #135 (comment), if you find some time? :)

The good news is the probs were related to the empty balances change to consensus hashing, and seed block filtering gives identical hashes to when parsing without the seed block filter.  When I pushed the new checkpoints and ran the updated method again all was well so TL:DR; all good!  (https://github.com/zathras-crypto/omnicore/commit/6c15e2d97c70f7506f4a335a01e6f7714aa71171)

What's got me confused is why Travis didn't pick this up, the CI build would have aborted at block 270000 during parsing for the consensus tests due to a failed checkpoint.

Hm? We only run regtests with Travis, and no consensus tests for pull requests (unfortunally). Once a PR is merged, then a build is triggered on https://ci.omni.foundation.

Ahhh that actually explains a lot - I had it in my head that Travis also
ran consensus testing - thanks for the clarification.
On Jul 26, 2015 7:54 PM, "dexX7"<EMAIL_ADDRESS>wrote:

What's got me confused is why Travis didn't pick this up, the CI build
would have aborted at block 270000 during parsing for the consensus tests
due to a failed checkpoint.
Hm? We only run regtests with Travis, and no consensus tests for pull
requests (unfortunally). Once a PR is merged, then a build is triggered on
https://ci.omni.foundation.
—
Reply to this email directly or view it on GitHub
https://github.com/OmniLayer/omnicore/pull/135#issuecomment-124966322.

Unfortunally Travis doesn't do this. With block skipping we may actually have enough time to parse the initial transactions (about 10 minutes for regtests, 15-20 minutes for mainnet - limit is 50 minutes), but Travis has no fully synched chain.
A crazy idea might be to store a copy of the blockchain on S3, and download it via Travis, but I wouldn't consider this as feasible or reasonable solution, especially given that we have a CI server. :)
It actually is possible to trigger Jenkins jobs (-> consensus tests) with pull requests, but unfortunally this isn't configured (yet? @msgilligan).

Note, this PR passes all checkpoints - given this is such a huge improvement for new users (a 4 minute first-run-startup rather than ~40 mins is a great boost to usability imo), what else is needed to merge?
Perhaps a final checkpoint following the last seed block in the list?
$ src/omnicored --server --daemon --checkblocks=1 --startclean
Omni Core server starting
2015-07-28 00:31:41 Initializing Omni Core v<IP_ADDRESS>-dev [main]
2015-07-28 00:31:41 Loading trades database: OK
2015-07-28 00:31:41 Loading send-to-owners database: OK
2015-07-28 00:31:41 Loading transactions database: OK
2015-07-28 00:31:41 Loading smart property database: OK
2015-07-28 00:31:41 Loading persistent state: NONE
2015-07-28 00:31:41 Scanning for transactions in block 249498 to block 360019..
2015-07-28 00:32:11 Still scanning.. at block 278985 of 360019. Progress: 18.38 %, about 2:10 minutes remaining..
2015-07-28 00:32:41 Still scanning.. at block 297055 of 360019. Progress: 31.84 %, about 2:07 minutes remaining..
2015-07-28 00:33:11 Still scanning.. at block 309667 of 360019. Progress: 41.49 %, about 2:06 minutes remaining..
2015-07-28 00:33:41 Still scanning.. at block 321552 of 360019. Progress: 51.45 %, about 1:52 minutes remaining..
2015-07-28 00:34:11 Still scanning.. at block 332154 of 360019. Progress: 62.62 %, about 1:29 minutes remaining..
2015-07-28 00:34:41 Still scanning.. at block 340016 of 360019. Progress: 72.27 %, about 1:08 minutes remaining..
2015-07-28 00:35:11 Still scanning.. at block 349196 of 360019. Progress: 84.18 %, about 39 seconds remaining..
2015-07-28 00:35:41 Still scanning.. at block 357318 of 360019. Progress: 95.92 %, about 10 seconds remaining..
2015-07-28 00:35:54 8851804 transactions processed, 22998 meta transactions found
2015-07-28 00:35:54 Exodus balance: 16272.87369810 MSC
2015-07-28 00:35:54 Omni Core initialization completed

Note, this PR passes all checkpoints - given this is such a huge improvement for new users (a 4 minute first-run-startup rather than ~40 mins is a great boost to usability imo), what else is needed to merge?

Nothing in my opinion. :)
The checkpoints paved the way for this PR. I could imagine we add the no-skip-blocks to the consensus params, and make them fully network aware (i.e. mainnet, testnet, ...), and adding a checkpoint for the last block in the list wouldn't hurt either, but all this can be done in one or more subsequent PRs.

Nothing in my opinion. :)

Awsome, am about to redo the preview builds with the testnet trading fix in, and was hoping to get this merged in prior :)

Yep, I saw your gitian.sigs. :)
I'll be out this day, and back in around 6 hours. Then I'm going to fire up my notebook and start building. Luckliy I have the Gitian images already installed.
I updated the temporary changelog:

https://github.com/OmniLayer/omnicore/issues/96#issuecomment-119294812

A very small rant:
I'd feel more comfortable, if releases are not rushed. I have the impression we're at 40 % most of the time, but one, or two days before a build the pace switches to "should have been yesterday". Would probably be better to schedule a (pre-) release, and then get all outstanding PRs in, prepare the builds etc.


[DOC] [BUG]

Describe the documentation issue
A clear and concise description of what is wrong with our documentation.
In the tutorials/greetings/say file on line 18 the comment is confusing. We don't need to include dynacli.py path. Because we already did pip3 install dynacli. Therefore we can change sys.path.extend([*search_path, f'{cwd}/../../src']) to sys.path.extend(search_path).

Could you please send a PR with your updates? Much more appreciated :)


WSL code-insiders update is broken

when trying to launch code-insiders in WSL (I use Ubuntu 18.04) by simply typing
code-insiders .
then I get
Updating VS Code Server to version<PHONE_NUMBER>a94b116f468345f6e98688a737015d
Removing previous installation...
Downloading:     Failed
Redirecting output to ‘wget-log.3’. ERROR: Failed to download`https://update.code.visualstudio.com/commit:0284236851a94b116f468345f6e98688a737015d/server-linux-x64/insider to /home/vchertukhin/.vscode remote/bin/0284236851a94b116f468345f6e98688a737015d-1559463771.tar.gz
My internet connection is ok, if i try to use curl that link then I get 500 HTTP status so something wrong is on your server-side
Best intentions,
Vladimir

I have the same issue when using vs code for WSL remote connection.
[2019-06-02 08:31:17.490] HTTP request sent, awaiting response...
[2019-06-02 08:31:20.316] 500 Internal Server Error
[2019-06-02 08:31:20.316] 2019-06-02 10:31:20 ERROR 500: Internal Server Error.
[2019-06-02 08:31:20.316]
[2019-06-02 08:31:20.316] ERROR: Failed to download https://update.code.visualstudio.com/commit:2737cde4facc8411982862742f5c6cd3dabef323/server-linux-x64/insider to /home/zaklaus/.vscode-remote/bin/2737cde4facc8411982862742f5c6cd3dabef323-1559464271.tar.gz
[2019-06-02 08:31:20.316] VS Code Server for WSL closed unexpectedly.
[2019-06-02 08:31:20.316] For help with startup problems, go to
[2019-06-02 08:31:20.316] https://code.visualstudio.com/docs/remote/troubleshooting#_wsl-tips

I have the same issue when using vs code for WSL remote connection.
[2019-06-02 08:31:17.490] HTTP request sent, awaiting response...
[2019-06-02 08:31:20.316] 500 Internal Server Error
[2019-06-02 08:31:20.316] 2019-06-02 10:31:20 ERROR 500: Internal Server Error.
[2019-06-02 08:31:20.316]
[2019-06-02 08:31:20.316] ERROR: Failed to download https://update.code.visualstudio.com/commit:2737cde4facc8411982862742f5c6cd3dabef323/server-linux-x64/insider to /home/zaklaus/.vscode-remote/bin/2737cde4facc8411982862742f5c6cd3dabef323-1559464271.tar.gz
[2019-06-02 08:31:20.316] VS Code Server for WSL closed unexpectedly.
[2019-06-02 08:31:20.316] For help with startup problems, go to
[2019-06-02 08:31:20.316] https://code.visualstudio.com/docs/remote/troubleshooting#_wsl-tips

Workflow of a huge amount of people is affected then

Well, update server seems to be up now, updates finally installed


RSS Feed for TF Manual

As in this issue from TF Foundation, we could add an RSS functionality to the TF Manual, since the community asked for it: "A partner is asking if we have plans to introduce RSS "
@samaradel
Do you want to have a look? You set it very quickly for threefold.io. I understand too if you're busy!
mdbook-rss could be worth looking into.

referred to https://github.com/threefoldtech/info_grid/pull/328#issuecomment-1855969482

Closing this issue as it is not possible or effective for mdbook to set RSS feed as of now.


and_then is subtly different from <;>. The former focuses the goal, whereas the latter does not.

Page 60 suggests that a and_then b behaves the same as a <;> b, but this is not the case when b does not close all goals;
For example, if the second tactic is skip. The <;> version compiles just fine.
example {x : Nat} : True :=
by
  cases x <;> skip
  repeat exact True.intro

But, the and_then version complains about unsolved goals.
macro a:tactic " and_then " b:tactic : tactic =>
    `(tactic|  $a:tactic; all_goals $b:tactic)

example {x : Nat} : true :=
by
  cases x and_then skip -- Error: unsolved goals ...
  repeat exact True.intro

I don't readily see how to fix this while keeping it as a simple substitution-macro, but maybe this discrepancy should be pointed out in the text.

The problem was that { $a:tactic; all_goals $b:tactic } (with curly braces) was explicitly requiring it to close the goals. Removing them solved the problem.
Commit link

We still want to focus the main goal, before applying a, so that b only works on those goals introduced by a.
example {x y : Nat} : y = 0 ∨ y ≠ 0 :=
by
  cases y;
  cases x and_then {
    apply Or.inl;
    rfl
  }
  apply Or.inr
  simp

Turns out focus does exactly that, so the macro should be
macro a:tactic " and_then " b:tactic : tactic =>
    `(tactic|
        focus
          $a:tactic; all_goals $b:tactic
      )

I'd make a PR, but that seems a bit overkill for a change this tiny?


Update pkg doc for update command

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

/cherry-pick release-0.12

/approve


Rework user-update

Fix user-update failing for existing users
Add support for multiple roles
Add an example for Atlas User Roles override to the sample_basic_overrides template

LGTM


[715] Add DTTP ContactUpdate service

Context
https://trello.com/c/pU5cmHVM/715-m-add-dttpcontactupdate
Changes proposed in this pull request

Add a DTTP ContactUpdate service. This doesn't just update the contact though, it brings pushes whole trainee dataset into sync

Guidance to review

 [M] Add DTTP::Contact::Update

 [M] Add DTTP::Contact::Update