fix: ensure motive of matches is Bool

Often I'm running into this issue with matches:
#check fun x : Option Nat => decide (x matches some .. : Prop)
-- failed to synthesize instance Decidable ...

To be honest, I don't why it even works at all with if-then-else because there the expected type is also Prop.

To be honest, I don't why it even works at all with if-then-else because there the expected type is also Prop.

@gebner The if-then-else notation waits for the type of the condition to be available.
macro_rules
  | `(if $c then $t:term else $e:term) => `(let_mvar% ?m := $c; wait_if_type_mvar% ?m; ite ?m $t $e)

Note that
set_option pp.match true

#check fun x : Option Nat => if x matches some .. then 0 else 1 -- works
#check fun x : Option Nat => if (x matches some .. : Prop) then 0 else 1 -- fail

The second fails because the type of the condition is Prop, and we fail to synthesize the Decidable instance
  Decidable (_check.match_1 (fun x => Prop) x (fun x => true = true) fun x => false = true)

It is the same problem we have with your example using decide.

The if-then-else notation waits for the type of the condition to be available.

Ah, this explains why it worked most of the time but why I doubted my sanity when I couldn't reproduce the bug separately.  Before this PR, the match waited for the expected type to be available and the if-then-else waited for the type of the match to be available.  So whether the matches worked depended on whether matches or if-then-else succeeded to elaborate first without postponing.
def f (x : Nat) := if x matches 1 then x else 0 -- success
def g (x : Nat) := if x + 1 matches 1 then x else 0 -- fail?!?

(At least that was my theory before looking at the elab traces for the examples above.  wait_if_type_mvar% doesn't postpone in the g function, maybe because the type is a let??)

(At least that was my theory before looking at the elab traces for the examples above. wait_if_type_mvar% doesn't postpone in the g function, maybe because the type is a let??)

@gebner Good catch. Thanks. I will try to fix this issue today.


Add rocksdb section to configure file.

We need to move some hard coded options to config file. We need a rocksdb section to config file right now. There is no need to build the tikv when we want to change options.
https://github.com/pingcap/tikv/blob/master/src/bin/tikv-server.rs#L143
@overvenus Would you like to take over this issue ?

sure : )

can we close it now?


settings: Replace "Custom alert words" with "Alert words".

Fixes #4066

@timabbott Should @synicalsyntax drop the translations commit here and just let it work though the process?

Merged minus translations changes, thanks @synicalsyntax!


SG S6/6.0.1/Chrome: Town results: test truncated at the end of page in Portrait mode

View your issue at Applause Testing Services - https://my.applause.com/u/a#!&view=issues&subview=issues&productId=15105&bugId=2315333
---- ACTION DETAILS ----
Action Performed:

Open the Test URL (elections.dev.passenger.bostonglobe.com/elections/2016) in the Chrome Browser of the mobile device
2)Scroll down and browse through the page
3)Observe the page

Expected Result:
All the text and images must be displayed clearly and with proper spacing
Actual Result:
One of the States name gets truncated in the Portrait mode
Additional Info:
This behavior is observed in SG S6/ Android 6.0.1 mobile device, when viewed the Homepage in Portrait mode
Error Code/Message:
One of the States name gets truncated in the Portrait mode
---- ENVIRONMENT ----
Firewall:McAfee,Language:English ,Operating System:Windows,Web Browser:Chrome,Desktop Accessories:Webcam,Desktop Accessories:Microphone,Desktop Accessories:Speakers,Desktop Accessories:Headset,Antivirus:Microsoft Security Essentials,Operating System Version:10 64-bit
---- UTEST PROPERTIES ----
uTest Bug Id: 2315333
Title: SG S6/6.0.1/Chrome: Town results: test truncated at the end of page in Portrait mode
Status: Pending Approval
Type: GUI
Frequency: Every Time
Severity: Low
Product: Elections (dev)
Test Cycle: Boston Globe Elections Regression Test Case Cycle
---- UTEST Attachment ----
Bug2315333_Truncate.png : https://utest-dl.s3.amazonaws.com/9716/15105/120253/null/bugAttachment/Bug2315333_Truncate.png?AWSAccessKeyId=AKIAJVVOIXUIFRTEEEKQ&Expires=1793825512&Signature=z6KGnpmVecZnHHgvArknu6aymbE%3D

this is not an issue in the updated version


Create CODEOWNERS

Docs Build status updates of commit 0f6efdf:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

CODEOWNERS
:white_check_mark:Succeeded

For more details, please refer to the build report.
Note: If you changed an existing file name or deleted a file, broken links in other files to the deleted or renamed file are listed only in the full build report.

Docs Build status updates of commit 0f6efdf:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

CODEOWNERS
:white_check_mark:Succeeded

For more details, please refer to the build report.
Note: If you changed an existing file name or deleted a file, broken links in other files to the deleted or renamed file are listed only in the full build report.


diskover.py error when running indexing commands

Traceback (most recent call last):
File "diskover.py", line 1464, in
config = load_config()
File "diskover.py", line 175, in load_config
t = config.get('autotag', 'files')
File "/usr/lib/python2.7/ConfigParser.py", line 607, in get
raise NoSectionError(section)
ConfigParser.NoSectionError: No section: 'autotag'

update to the latest rc10 i just pushed and copy autotag section (and any others missing) from diskover.cfg.sample to your diskover.cfg and adjust for your environment.

@hyattdrew11 did you get it working now copying over config settings from diskover.cfg.sample?

Yeah thanks for the quick reply.
On Sat, Jun 16, 2018, 9:35 PM Chris Park<EMAIL_ADDRESS>wrote:

@hyattdrew11 https://github.com/hyattdrew11 did you get it working now
copying over config settings from diskover.cfg.sample?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/shirosaidev/diskover/issues/24#issuecomment-397850483,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ALu6bTZzfGou8SkJjVW4thS0f1IseuuJks5t9cCHgaJpZM4Umnnv
.

there has been a lot of changes/updates to rc10, hoping to finalize it soon, try to grab the latest off github.


Add GET Individual Full Record

IDVA3-2394 - new endpoint for /company/{company_number}/persons-with-significant-control/individual/{notification_id}/full_record
IDVA3-2396 - add to service to retrieve data and return new model
IDVA3-2397 - Internal API key user interceptor

CI: Security warnings found!

CI: Security warnings found!

CI: Security warnings found!

CI: Security warnings found!

CI: Security warnings found!


Don't know how to parse....

HTML source: www.dennikn.sk/minuta/feed

Sorry. It does not support.

see #31


Add e2e tests for resiliency in Bindings/Pubsub

Description
This commit adds several e2e tests for resiliency in bindings/pubsub. This
is primarily focused on the app invocation (input bindings/pubsub subscriptions), though
output binding and publish are also covered by the policy.
This change also addresses the issues found by the e2e test.
Signed-off-by: Hal Spang<EMAIL_ADDRESS>Issue reference
Please reference the issue this PR will close: Resiliency
Checklist
Please make sure you've  completed the relevant tasks for this PR, out of the following list:

[x] Code compiles correctly
[x] Created/updated tests
[x] Unit tests passing
[x] End-to-end tests passing
[ ] Extended the documentation / Created issue in the https://github.com/dapr/docs/ repo: dapr/docs#[issue number]
[ ] Specification has been updated / Created issue in the https://github.com/dapr/docs/ repo: dapr/docs#[issue number]
[ ] Provided sample for the feature / Created issue in the https://github.com/dapr/docs/ repo: dapr/docs#[issue number]

/ok-to-test


Expose DurableElasticsearchSink and/or provide a method to build a sink given provided options

It's a bit misleading that new ElasticsearchSink() ignores the "BufferBaseFilename" parameter (which turns on the durable mode).
I discovered it because I'd like to build a new DurableElasticsearchSink instance and the the only way seems to be through the extension method (which directly attach the sink to the logger configuration so I can't get the ILogEventSink).

The durable sink is based on the Seq client version and although it does what it needs to do, it is implemented in a way that makes swapping it out a bit difficult. Open for suggestions/PR.


Fixed the place curve issue (through points tool) in FixedStructs.cpp

itwinjs-core: https://github.com/iTwin/itwinjs-core/pull/6789

/azp run imodel-native

Don't merge this yet if it depends on linked itwinjs-core PR.

Yes, I just linked the iTwin PR.

/azp run imodel-native

Please describe in your PR title and/or description what "the issue" is.

/azp run imodel-native


Discriminate contextual types

This was split from #19587, and the idea originated from a comment on #19322 (and then the code moved directly into getApparentTypeOfContextualType instead of getContextualThisParameterType so as to be more general), and should be merged after #19587. The primary baseline changes will be visible in tests added in that PR; however there are some small changes already visible here because we toss out uninteresting contextual types earlier based on members we know the type of.
This causes a few things:

Contextual this types are discriminated based on the other members you wrote; meaning methods in objects contextually typed by something now have the this type of only the discriminated member you've indicated, if possible. (This is the primary benefit the tests in the other PR can show)
Contextually typed object literal members are no longer contextually typed by elements of the union for which a discriminant infers they do not apply (for example, if a method signature would be typed by multiple signatures from various discriminant members before, now it will just be typed by one if a discriminant can successfully be applied) - I've added a test for this; this really improves our behavior here (given how badly we handle mismatched signatures).

@sandersn As far as overall perf goes, this has no real effect on a codebase:

Metric
master
discriminate-contextual-types
Delta
Best
Worst

Compiler - Unions - node (v9.0.0, x64)

Memory used
202,235k (±  0.02%)
202,257k (±  0.01%)
+22k (+  0.01%)
202,214k
202,311k

Parse Time
0.67s (±  1.88%)
0.66s (±  0.61%)
-0.00s (-  0.75%)
0.65s
0.67s

Bind Time
0.61s (±  2.03%)
0.60s (±  1.17%)
-0.01s (-  1.96%)
0.59s
0.62s

Check Time
10.14s (±  1.07%)
10.09s (±  0.80%)
-0.05s (-  0.49%)
9.89s
10.27s

Emit Time
0.00s (±  0.00%)
0.00s (±  0.00%)
0.00s (    NaN%)
0.00s
0.00s

Total Time
11.42s (±  0.98%)
11.35s (±  0.71%)
-0.07s (-  0.60%)
11.15s
11.52s

Monaco - node (v9.0.0, x64)

Memory used
330,450k (±  0.01%)
330,510k (±  0.02%)
+61k (+  0.02%)
330,402k
330,684k

Parse Time
1.58s (±  2.84%)
1.55s (±  0.84%)
-0.03s (-  1.77%)
1.52s
1.58s

Bind Time
0.70s (±  0.64%)
0.71s (±  0.82%)
+0.01s (+  1.29%)
0.70s
0.72s

Check Time
3.24s (±  0.44%)
3.24s (±  0.55%)
+0.00s (+  0.06%)
3.20s
3.29s

Emit Time
2.59s (±  0.70%)
2.58s (±  0.96%)
-0.01s (-  0.31%)
2.52s
2.66s

Total Time
8.10s (±  0.77%)
8.08s (±  0.63%)
-0.02s (-  0.28%)
7.99s
8.23s

TFS - node (v9.0.0, x64)

Memory used
287,749k (±  0.02%)
287,707k (±  0.02%)
-43k (-  0.01%)
287,594k
287,820k

Parse Time
1.17s (±  1.66%)
1.17s (±  0.76%)
-0.00s (-  0.09%)
1.15s
1.19s

Bind Time
0.52s (±  1.34%)
0.52s (±  1.13%)
+0.00s (+  0.58%)
0.51s
0.54s

Check Time
3.00s (±  1.24%)
3.01s (±  1.73%)
+0.02s (+  0.67%)
2.95s
3.18s

Emit Time
2.07s (±  0.74%)
2.07s (±  1.07%)
-0.00s (-  0.00%)
2.02s
2.11s

Total Time
6.75s (±  0.69%)
6.77s (±  1.08%)
+0.02s (+  0.31%)
6.67s
6.99s


exporting traces is broken with latest docker release

Description:
When running through the examples provided at
https://www.envoyproxy.io/docs/envoy/latest/start/sandboxes/zipkin_tracing.html no traces show up in the zipkin UI.
When I change the docker version tag from latest to v1.8.0 in the below files traces start to show up. I don't see any errors when running on latest that would explain no traces to be sent.
front-proxy/Dockerfile-service
front-proxy/Dockerfile-frontenvoy

cc @objectiser

This issue is also affecting the jaeger-tracing example.
Looks like it was caused by https://github.com/envoyproxy/envoy/commit/43fc77901ee8a1608239daaa51b531f922628083.
cc @jmarantz

I can take a look; is there an easy way to express this as a unit test?

Not sure - there are unit tests at the various levels (conn_manager_impl, http_tracer_impl, zipkin_tracer) - but looks like there must be some gap in testing. Don't think there are any e2e tests, which might be needed.

E.g. is there a way to tell if this is working without necessarily installing and learning zipkin?

The way I isolated the specific SHA was to update the docker image tag here and here.
Then using the instructions in the jaeger-example to test it out - or you can use the zipkin-example that was mentioned originally.
Only thing I do slightly different from the instructions is I use the following curl command instead:
curl -v localhost:8000/trace/1

Thinking about this -- not having re-reviewed the commit yet, it seems the most likely introduced bug is that a NullTracer is used when it shouldn't be. I'll take a look at that first.