text:
Update prettier

ref: #11840
https://prettier.io/blog/2020/03/21/2.0.0.html

Better defaults, a better CLI and better heuristics. Oh, and TypeScript 3.8.

I've updated prettier due to issues with using import type.
Because of using the default settings, there are many changed files.
If you want to make fewer changes, I will need to change the prettier settings.
I just personally like the default. The settings needs to be discussed.

Stats from current PR

Default Server Mode (Increase detected ⚠)

General Overall increase ⚠

zeit/next.js canary
matamatanot/next.js update-prettier
Change

buildDuration
11s
11.1s
⚠ +90ms

nodeModulesSize
59.6 MB
59.6 MB
⚠ +101 B

Page Load Tests Overall increase ✓

zeit/next.js canary
matamatanot/next.js update-prettier
Change

/ failed reqs
0
0
✓

/ total time (seconds)
1.831
1.862
⚠ +0.03

/ avg req/sec
1365.14
1342.4
-22.74

/error-in-render failed reqs
0
0
✓

/error-in-render total time (seconds)
1.089
1.069
-0.02

/error-in-render avg req/sec
2295.44
2339.51
⚠ +44.07

Client Bundles (main, webpack, commons)

zeit/next.js canary
matamatanot/next.js update-prettier
Change

main-HASH.js gzip
6.67 kB
6.67 kB
✓

webpack-HASH.js gzip
746 B
746 B
✓

de003c3a9d30..5ce3.js gzip
10.4 kB
10.4 kB
✓

framework.HASH.js gzip
39.1 kB
39.1 kB
✓

Overall change
57 kB
57 kB
✓

Client Bundles (main, webpack, commons) Modern

zeit/next.js canary
matamatanot/next.js update-prettier
Change

main-HASH.module.js gzip
5.71 kB
5.71 kB
✓

webpack-HASH..dule.js gzip
746 B
746 B
✓

de003c3a9d30..dule.js gzip
6.85 kB
6.85 kB
✓

framework.HA..dule.js gzip
39.1 kB
39.1 kB
✓

Overall change
52.4 kB
52.4 kB
✓

Legacy Client Bundles (polyfills)

zeit/next.js canary
matamatanot/next.js update-prettier
Change

polyfills-HASH.js gzip
26.3 kB
26.3 kB
✓

Overall change
26.3 kB
26.3 kB
✓

Client Pages

zeit/next.js canary
matamatanot/next.js update-prettier
Change

_app.js gzip
1.26 kB
1.26 kB
✓

_error.js gzip
3.29 kB
3.29 kB
✓

hooks.js gzip
881 B
881 B
✓

index.js gzip
222 B
222 B
✓

link.js gzip
2.06 kB
2.06 kB
✓

routerDirect.js gzip
280 B
280 B
✓

withRouter.js gzip
278 B
278 B
✓

Overall change
8.26 kB
8.26 kB
✓

Client Pages Modern

zeit/next.js canary
matamatanot/next.js update-prettier
Change

_app.module.js gzip
599 B
599 B
✓

_error.module.js gzip
2.09 kB
2.09 kB
✓

hooks.module.js gzip
383 B
383 B
✓

index.module.js gzip
223 B
223 B
✓

link.module.js gzip
1.52 kB
1.52 kB
✓

routerDirect..dule.js gzip
279 B
279 B
✓

withRouter.m..dule.js gzip
278 B
278 B
✓

Overall change
5.37 kB
5.37 kB
✓

Client Build Manifests

zeit/next.js canary
matamatanot/next.js update-prettier
Change

_buildManifest.js gzip
61 B
61 B
✓

_buildManife..dule.js gzip
61 B
61 B
✓

Overall change
122 B
122 B
✓

Rendered Page Sizes

zeit/next.js canary
matamatanot/next.js update-prettier
Change

index.html gzip
927 B
927 B
✓

link.html gzip
937 B
937 B
✓

withRouter.html gzip
925 B
925 B
✓

Overall change
2.79 kB
2.79 kB
✓

Serverless Mode (Increase detected ⚠)

General Overall increase ⚠

zeit/next.js canary
matamatanot/next.js update-prettier
Change

buildDuration
11.9s
12.5s
⚠ +589ms

nodeModulesSize
59.6 MB
59.6 MB
⚠ +101 B

Client Bundles (main, webpack, commons)

zeit/next.js canary
matamatanot/next.js update-prettier
Change

main-HASH.js gzip
6.67 kB
6.67 kB
✓

webpack-HASH.js gzip
746 B
746 B
✓

de003c3a9d30..5ce3.js gzip
10.4 kB
10.4 kB
✓

framework.HASH.js gzip
39.1 kB
39.1 kB
✓

Overall change
57 kB
57 kB
✓

Client Bundles (main, webpack, commons) Modern

zeit/next.js canary
matamatanot/next.js update-prettier
Change

main-HASH.module.js gzip
5.71 kB
5.71 kB
✓

webpack-HASH..dule.js gzip
746 B
746 B
✓

de003c3a9d30..dule.js gzip
6.85 kB
6.85 kB
✓

framework.HA..dule.js gzip
39.1 kB
39.1 kB
✓

Overall change
52.4 kB
52.4 kB
✓

Legacy Client Bundles (polyfills)

zeit/next.js canary
matamatanot/next.js update-prettier
Change

polyfills-HASH.js gzip
26.3 kB
26.3 kB
✓

Overall change
26.3 kB
26.3 kB
✓

Client Pages

zeit/next.js canary
matamatanot/next.js update-prettier
Change

_app.js gzip
1.26 kB
1.26 kB
✓

_error.js gzip
3.29 kB
3.29 kB
✓

hooks.js gzip
881 B
881 B
✓

index.js gzip
222 B
222 B
✓

link.js gzip
2.06 kB
2.06 kB
✓

routerDirect.js gzip
280 B
280 B
✓

withRouter.js gzip
278 B
278 B
✓

Overall change
8.26 kB
8.26 kB
✓

Client Pages Modern

zeit/next.js canary
matamatanot/next.js update-prettier
Change

_app.module.js gzip
599 B
599 B
✓

_error.module.js gzip
2.09 kB
2.09 kB
✓

hooks.module.js gzip
383 B
383 B
✓

index.module.js gzip
223 B
223 B
✓

link.module.js gzip
1.52 kB
1.52 kB
✓

routerDirect..dule.js gzip
279 B
279 B
✓

withRouter.m..dule.js gzip
278 B
278 B
✓

Overall change
5.37 kB
5.37 kB
✓

Client Build Manifests

zeit/next.js canary
matamatanot/next.js update-prettier
Change

_buildManifest.js gzip
61 B
61 B
✓

_buildManife..dule.js gzip
61 B
61 B
✓

Overall change
122 B
122 B
✓

Serverless bundles Overall increase ⚠

zeit/next.js canary
matamatanot/next.js update-prettier
Change

_error.js
851 kB
851 kB
⚠ +16 B

404.html
4.18 kB
4.18 kB
✓

hooks.html
3.81 kB
3.81 kB
✓

index.js
851 kB
851 kB
⚠ +16 B

link.js
888 kB
888 kB
⚠ +16 B

routerDirect.js
881 kB
881 kB
⚠ +16 B

withRouter.js
881 kB
881 kB
⚠ +16 B

Overall change
4.36 MB
4.36 MB
⚠ +80 B

Stats from current PR

Default Server Mode (Increase detected ⚠)

General Overall increase ⚠

zeit/next.js canary
matamatanot/next.js update-prettier
Change

buildDuration
11.8s
11.7s
-67ms

nodeModulesSize
59.6 MB
59.6 MB
⚠ +101 B

Page Load Tests Overall increase ✓

zeit/next.js canary
matamatanot/next.js update-prettier
Change

/ failed reqs
0
0
✓

/ total time (seconds)
2.078
1.975
-0.1

/ avg req/sec
1203.2
1265.55
⚠ +62.35

/error-in-render failed reqs
0
0
✓

/error-in-render total time (seconds)
1.329
1.276
-0.05

/error-in-render avg req/sec
1881.77
1959.96
⚠ +78.19

Client Bundles (main, webpack, commons)

zeit/next.js canary
matamatanot/next.js update-prettier
Change

main-HASH.js gzip
6.67 kB
6.67 kB
✓

webpack-HASH.js gzip
746 B
746 B
✓

de003c3a9d30..5ce3.js gzip
10.4 kB
10.4 kB
✓

framework.HASH.js gzip
39.1 kB
39.1 kB
✓

Overall change
57 kB
57 kB
✓

Client Bundles (main, webpack, commons) Modern

zeit/next.js canary
matamatanot/next.js update-prettier
Change

main-HASH.module.js gzip
5.71 kB
5.71 kB
✓

webpack-HASH..dule.js gzip
746 B
746 B
✓

de003c3a9d30..dule.js gzip
6.85 kB
6.85 kB
✓

framework.HA..dule.js gzip
39.1 kB
39.1 kB
✓

Overall change
52.4 kB
52.4 kB
✓

Legacy Client Bundles (polyfills)

zeit/next.js canary
matamatanot/next.js update-prettier
Change

polyfills-HASH.js gzip
26.3 kB
26.3 kB
✓

Overall change
26.3 kB
26.3 kB
✓

Client Pages

zeit/next.js canary
matamatanot/next.js update-prettier
Change

_app.js gzip
1.26 kB
1.26 kB
✓

_error.js gzip
3.29 kB
3.29 kB
✓

hooks.js gzip
881 B
881 B
✓

index.js gzip
222 B
222 B
✓

link.js gzip
2.06 kB
2.06 kB
✓

routerDirect.js gzip
280 B
280 B
✓

withRouter.js gzip
278 B
278 B
✓

Overall change
8.26 kB
8.26 kB
✓

Client Pages Modern

zeit/next.js canary
matamatanot/next.js update-prettier
Change

_app.module.js gzip
599 B
599 B
✓

_error.module.js gzip
2.09 kB
2.09 kB
✓

hooks.module.js gzip
383 B
383 B
✓

index.module.js gzip
223 B
223 B
✓

link.module.js gzip
1.52 kB
1.52 kB
✓

routerDirect..dule.js gzip
279 B
279 B
✓

withRouter.m..dule.js gzip
278 B
278 B
✓

Overall change
5.37 kB
5.37 kB
✓

Client Build Manifests

zeit/next.js canary
matamatanot/next.js update-prettier
Change

_buildManifest.js gzip
61 B
61 B
✓

_buildManife..dule.js gzip
61 B
61 B
✓

Overall change
122 B
122 B
✓

Rendered Page Sizes

zeit/next.js canary
matamatanot/next.js update-prettier
Change

index.html gzip
927 B
927 B
✓

link.html gzip
937 B
937 B
✓

withRouter.html gzip
925 B
925 B
✓

Overall change
2.79 kB
2.79 kB
✓

Serverless Mode (Increase detected ⚠)

General Overall increase ⚠

zeit/next.js canary
matamatanot/next.js update-prettier
Change

buildDuration
12.1s
13.3s
⚠ +1.2s

nodeModulesSize
59.6 MB
59.6 MB
⚠ +101 B

Client Bundles (main, webpack, commons)

zeit/next.js canary
matamatanot/next.js update-prettier
Change

main-HASH.js gzip
6.67 kB
6.67 kB
✓

webpack-HASH.js gzip
746 B
746 B
✓

de003c3a9d30..5ce3.js gzip
10.4 kB
10.4 kB
✓

framework.HASH.js gzip
39.1 kB
39.1 kB
✓

Overall change
57 kB
57 kB
✓

Client Bundles (main, webpack, commons) Modern

zeit/next.js canary
matamatanot/next.js update-prettier
Change

main-HASH.module.js gzip
5.71 kB
5.71 kB
✓

webpack-HASH..dule.js gzip
746 B
746 B
✓

de003c3a9d30..dule.js gzip
6.85 kB
6.85 kB
✓

framework.HA..dule.js gzip
39.1 kB
39.1 kB
✓

Overall change
52.4 kB
52.4 kB
✓

Legacy Client Bundles (polyfills)

zeit/next.js canary
matamatanot/next.js update-prettier
Change

polyfills-HASH.js gzip
26.3 kB
26.3 kB
✓

Overall change
26.3 kB
26.3 kB
✓

Client Pages

zeit/next.js canary
matamatanot/next.js update-prettier
Change

_app.js gzip
1.26 kB
1.26 kB
✓

_error.js gzip
3.29 kB
3.29 kB
✓

hooks.js gzip
881 B
881 B
✓

index.js gzip
222 B
222 B
✓

link.js gzip
2.06 kB
2.06 kB
✓

routerDirect.js gzip
280 B
280 B
✓

withRouter.js gzip
278 B
278 B
✓

Overall change
8.26 kB
8.26 kB
✓

Client Pages Modern

zeit/next.js canary
matamatanot/next.js update-prettier
Change

_app.module.js gzip
599 B
599 B
✓

_error.module.js gzip
2.09 kB
2.09 kB
✓

hooks.module.js gzip
383 B
383 B
✓

index.module.js gzip
223 B
223 B
✓

link.module.js gzip
1.52 kB
1.52 kB
✓

routerDirect..dule.js gzip
279 B
279 B
✓

withRouter.m..dule.js gzip
278 B
278 B
✓

Overall change
5.37 kB
5.37 kB
✓

Client Build Manifests

zeit/next.js canary
matamatanot/next.js update-prettier
Change

_buildManifest.js gzip
61 B
61 B
✓

_buildManife..dule.js gzip
61 B
61 B
✓

Overall change
122 B
122 B
✓

Serverless bundles Overall increase ⚠

zeit/next.js canary
matamatanot/next.js update-prettier
Change

_error.js
851 kB
851 kB
⚠ +16 B

404.html
4.18 kB
4.18 kB
✓

hooks.html
3.81 kB
3.81 kB
✓

index.js
851 kB
851 kB
⚠ +16 B

link.js
888 kB
888 kB
⚠ +16 B

routerDirect.js
881 kB
881 kB
⚠ +16 B

withRouter.js
881 kB
881 kB
⚠ +16 B

Overall change
4.36 MB
4.36 MB
⚠ +80 B

Stats from current PR

Default Server Mode (Increase detected ⚠)

General Overall increase ⚠

zeit/next.js canary
matamatanot/next.js update-prettier
Change

buildDuration
10.8s
10.6s
-149ms

nodeModulesSize
59.6 MB
59.6 MB
⚠ +101 B

Page Load Tests Overall increase ✓

zeit/next.js canary
matamatanot/next.js update-prettier
Change

/ failed reqs
0
0
✓

/ total time (seconds)
1.795
1.755
-0.04

/ avg req/sec
1392.7
1424.45
⚠ +31.75

/error-in-render failed reqs
0
0
✓

/error-in-render total time (seconds)
1.044
1.033
-0.01

/error-in-render avg req/sec
2395.32
2420.15
⚠ +24.83

Client Bundles (main, webpack, commons)

zeit/next.js canary
matamatanot/next.js update-prettier
Change

main-HASH.js gzip
6.67 kB
6.67 kB
✓

webpack-HASH.js gzip
746 B
746 B
✓

de003c3a9d30..5ce3.js gzip
10.4 kB
10.4 kB
✓

framework.HASH.js gzip
39.1 kB
39.1 kB
✓

Overall change
57 kB
57 kB
✓

Client Bundles (main, webpack, commons) Modern

zeit/next.js canary
matamatanot/next.js update-prettier
Change

main-HASH.module.js gzip
5.71 kB
5.71 kB
✓

webpack-HASH..dule.js gzip
746 B
746 B
✓

de003c3a9d30..dule.js gzip
6.85 kB
6.85 kB
✓

framework.HA..dule.js gzip
39.1 kB
39.1 kB
✓

Overall change
52.4 kB
52.4 kB
✓

Legacy Client Bundles (polyfills)

zeit/next.js canary
matamatanot/next.js update-prettier
Change

polyfills-HASH.js gzip
26.3 kB
26.3 kB
✓

Overall change
26.3 kB
26.3 kB
✓

Client Pages

zeit/next.js canary
matamatanot/next.js update-prettier
Change

_app.js gzip
1.26 kB
1.26 kB
✓

_error.js gzip
3.29 kB
3.29 kB
✓

hooks.js gzip
881 B
881 B
✓

index.js gzip
222 B
222 B
✓

link.js gzip
2.06 kB
2.06 kB
✓

routerDirect.js gzip
280 B
280 B
✓

withRouter.js gzip
278 B
278 B
✓

Overall change
8.26 kB
8.26 kB
✓

Client Pages Modern

zeit/next.js canary
matamatanot/next.js update-prettier
Change

_app.module.js gzip
599 B
599 B
✓

_error.module.js gzip
2.09 kB
2.09 kB
✓

hooks.module.js gzip
383 B
383 B
✓

index.module.js gzip
223 B
223 B
✓

link.module.js gzip
1.52 kB
1.52 kB
✓

routerDirect..dule.js gzip
279 B
279 B
✓

withRouter.m..dule.js gzip
278 B
278 B
✓

Overall change
5.37 kB
5.37 kB
✓

Client Build Manifests

zeit/next.js canary
matamatanot/next.js update-prettier
Change

_buildManifest.js gzip
61 B
61 B
✓

_buildManife..dule.js gzip
61 B
61 B
✓

Overall change
122 B
122 B
✓

Rendered Page Sizes

zeit/next.js canary
matamatanot/next.js update-prettier
Change

index.html gzip
927 B
927 B
✓

link.html gzip
937 B
937 B
✓

withRouter.html gzip
925 B
925 B
✓

Overall change
2.79 kB
2.79 kB
✓

Serverless Mode (Increase detected ⚠)

General Overall increase ⚠

zeit/next.js canary
matamatanot/next.js update-prettier
Change

buildDuration
11.8s
11.7s
-97ms

nodeModulesSize
59.6 MB
59.6 MB
⚠ +101 B

Client Bundles (main, webpack, commons)

zeit/next.js canary
matamatanot/next.js update-prettier
Change

main-HASH.js gzip
6.67 kB
6.67 kB
✓

webpack-HASH.js gzip
746 B
746 B
✓

de003c3a9d30..5ce3.js gzip
10.4 kB
10.4 kB
✓

framework.HASH.js gzip
39.1 kB
39.1 kB
✓

Overall change
57 kB
57 kB
✓

Client Bundles (main, webpack, commons) Modern

zeit/next.js canary
matamatanot/next.js update-prettier
Change

main-HASH.module.js gzip
5.71 kB
5.71 kB
✓

webpack-HASH..dule.js gzip
746 B
746 B
✓

de003c3a9d30..dule.js gzip
6.85 kB
6.85 kB
✓

framework.HA..dule.js gzip
39.1 kB
39.1 kB
✓

Overall change
52.4 kB
52.4 kB
✓

Legacy Client Bundles (polyfills)

zeit/next.js canary
matamatanot/next.js update-prettier
Change

polyfills-HASH.js gzip
26.3 kB
26.3 kB
✓

Overall change
26.3 kB
26.3 kB
✓

Client Pages

zeit/next.js canary
matamatanot/next.js update-prettier
Change

_app.js gzip
1.26 kB
1.26 kB
✓

_error.js gzip
3.29 kB
3.29 kB
✓

hooks.js gzip
881 B
881 B
✓

index.js gzip
222 B
222 B
✓

link.js gzip
2.06 kB
2.06 kB
✓

routerDirect.js gzip
280 B
280 B
✓

withRouter.js gzip
278 B
278 B
✓

Overall change
8.26 kB
8.26 kB
✓

Client Pages Modern

zeit/next.js canary
matamatanot/next.js update-prettier
Change

_app.module.js gzip
599 B
599 B
✓

_error.module.js gzip
2.09 kB
2.09 kB
✓

hooks.module.js gzip
383 B
383 B
✓

index.module.js gzip
223 B
223 B
✓

link.module.js gzip
1.52 kB
1.52 kB
✓

routerDirect..dule.js gzip
279 B
279 B
✓

withRouter.m..dule.js gzip
278 B
278 B
✓

Overall change
5.37 kB
5.37 kB
✓

Client Build Manifests

zeit/next.js canary
matamatanot/next.js update-prettier
Change

_buildManifest.js gzip
61 B
61 B
✓

_buildManife..dule.js gzip
61 B
61 B
✓

Overall change
122 B
122 B
✓

Serverless bundles Overall increase ⚠

zeit/next.js canary
matamatanot/next.js update-prettier
Change

_error.js
851 kB
851 kB
⚠ +16 B

404.html
4.18 kB
4.18 kB
✓

hooks.html
3.81 kB
3.81 kB
✓

index.js
851 kB
851 kB
⚠ +16 B

link.js
888 kB
888 kB
⚠ +16 B

routerDirect.js
881 kB
881 kB
⚠ +16 B

withRouter.js
881 kB
881 kB
⚠ +16 B

Overall change
4.36 MB
4.36 MB
⚠ +80 B

We'll have to do a new PR manually from our side as this PR diff is too large to review. Thanks for the PR though 🙏

authors: ijjk matamatanot timneutkens


text:
Make sure react and react-dom are bundled to main.js in development

main.js should be generated in dev mode to hold react and react-dom.
When this is shipped, compilation will be a lot faster on canary 👍

I like it!

source: gharchive/pull-request

authors: ptomasroos timneutkens

license: mit

license_type: permissive

license_source: bigquery


text:
Native url

Updating native-url, fixes issue on IE11

Stats from current PR

Default Server Mode (Increase detected ⚠)

General Overall increase ⚠

zeit/next.js canary
janicklas-ralph/next.js native-url
Change

buildDuration
13.7s
13.6s
-192ms

nodeModulesSize
49 MB
49 MB
⚠ +1.59 kB

Client Bundles (main, webpack, commons)

zeit/next.js canary
janicklas-ralph/next.js native-url
Change

main-HASH.js
18.1 kB
18.1 kB
✓

main-HASH.js gzip
6.39 kB
6.39 kB
✓

webpack-HASH.js
1.53 kB
1.53 kB
✓

webpack-HASH.js gzip
746 B
746 B
✓

16b1a7225520..4086094cc.js
19.8 kB
19.8 kB
✓

16b1a7225520..94cc.js gzip
7.37 kB
7.37 kB
✓

4952ddcd88e7..49d7903c2.js
9.6 kB
9.6 kB
✓

4952ddcd88e7..03c2.js gzip
3.76 kB
3.76 kB
✓

commons.HASH.js
10.4 kB
10.4 kB
✓

commons.HASH.js gzip
3.91 kB
3.91 kB
✓

de003c3a9d30..dd6294d03.js
21.1 kB
N/A
N/A

de003c3a9d30..4d03.js gzip
8.15 kB
N/A
N/A

framework.HASH.js
125 kB
125 kB
✓

framework.HASH.js gzip
39.4 kB
39.4 kB
✓

de003c3a9d30..93e0efc89.js
N/A
21.2 kB
N/A

de003c3a9d30..fc89.js gzip
N/A
8.18 kB
N/A

Overall change
206 kB
206 kB
✓

Client Bundles (main, webpack, commons) Modern

zeit/next.js canary
janicklas-ralph/next.js native-url
Change

main-HASH.module.js
14.1 kB
14.1 kB
✓

main-HASH.module.js gzip
5.33 kB
5.33 kB
✓

webpack-HASH.module.js
1.53 kB
1.53 kB
✓

webpack-HASH..dule.js gzip
746 B
746 B
✓

16b1a7225520..95.module.js
21.1 kB
21.1 kB
✓

16b1a7225520..dule.js gzip
8.14 kB
8.14 kB
✓

4952ddcd88e7..cc.module.js
11.9 kB
11.9 kB
✓

4952ddcd88e7..dule.js gzip
4.41 kB
4.41 kB
✓

de003c3a9d30..3e.module.js
14.9 kB
N/A
N/A

de003c3a9d30..dule.js gzip
6.11 kB
N/A
N/A

framework.HASH.module.js
125 kB
125 kB
✓

framework.HA..dule.js gzip
39.4 kB
39.4 kB
✓

de003c3a9d30..fc.module.js
N/A
14.9 kB
N/A

de003c3a9d30..dule.js gzip
N/A
6.14 kB
N/A

Overall change
189 kB
189 kB
✓

Legacy Client Bundles (polyfills)

zeit/next.js canary
janicklas-ralph/next.js native-url
Change

polyfills-HASH.js
15.3 kB
15.3 kB
✓

polyfills-HASH.js gzip
4.75 kB
4.75 kB
✓

Overall change
15.3 kB
15.3 kB
✓

Client Pages

zeit/next.js canary
janicklas-ralph/next.js native-url
Change

_app.js
2.92 kB
2.92 kB
✓

_app.js gzip
1.32 kB
1.32 kB
✓

_error.js
13.2 kB
13.2 kB
✓

_error.js gzip
5.1 kB
5.1 kB
✓

hooks.js
1.92 kB
1.92 kB
✓

hooks.js gzip
941 B
941 B
✓

index.js
318 B
318 B
✓

index.js gzip
222 B
222 B
✓

link.js
6.76 kB
6.76 kB
✓

link.js gzip
2.88 kB
2.88 kB
✓

routerDirect.js
413 B
413 B
✓

routerDirect.js gzip
285 B
285 B
✓

withRouter.js
423 B
423 B
✓

withRouter.js gzip
284 B
284 B
✓

Overall change
25.9 kB
25.9 kB
✓

Client Pages Modern

zeit/next.js canary
janicklas-ralph/next.js native-url
Change

_app.module.js
1.53 kB
1.53 kB
✓

_app.module.js gzip
745 B
745 B
✓

_error.module.js
10.3 kB
10.3 kB
✓

_error.module.js gzip
4.24 kB
4.24 kB
✓

hooks.module.js
651 B
651 B
✓

hooks.module.js gzip
371 B
371 B
✓

index.module.js
276 B
276 B
✓

index.module.js gzip
212 B
212 B
✓

link.module.js
5.44 kB
5.44 kB
✓

link.module.js gzip
2.45 kB
2.45 kB
✓

routerDirect.module.js
386 B
386 B
✓

routerDirect..dule.js gzip
275 B
275 B
✓

withRouter.module.js
396 B
396 B
✓

withRouter.m..dule.js gzip
274 B
274 B
✓

Overall change
19 kB
19 kB
✓

Client Build Manifests

zeit/next.js canary
janicklas-ralph/next.js native-url
Change

_buildManifest.js
244 B
244 B
✓

_buildManifest.js gzip
200 B
200 B
✓

_buildManifest.module.js
251 B
251 B
✓

_buildManife..dule.js gzip
210 B
210 B
✓

Overall change
495 B
495 B
✓

Rendered Page Sizes

zeit/next.js canary
janicklas-ralph/next.js native-url
Change

index.html
4.06 kB
4.06 kB
✓

index.html gzip
1.03 kB
1.03 kB
✓

link.html
4.58 kB
4.58 kB
✓

link.html gzip
1.11 kB
1.11 kB
✓

withRouter.html
4.59 kB
4.59 kB
✓

withRouter.html gzip
1.11 kB
1.1 kB
-1 B

Overall change
13.2 kB
13.2 kB
✓

Diffs

Diff for index.html
@@ -18,7 +18,7 @@
         as="script" crossorigin="anonymous" />
         <link rel="preload" href="/_next/static/chunks/4952ddcd88e7185e66c9cf40e2d848b7e27f1574.6ad24cd530d796126b06.module.js"
         as="script" crossorigin="anonymous" />
-        <link rel="preload" href="/_next/static/chunks/de003c3a9d308750aa009870a5926f9b18ab31f4.8499a53d1674e87c1349.module.js"
+        <link rel="preload" href="/_next/static/chunks/de003c3a9d308750aa009870a5926f9b18ab31f4.7cf360095f4d019aa946.module.js"
         as="script" crossorigin="anonymous" />
     </head>

@@ -58,9 +58,9 @@
         async="" crossorigin="anonymous" nomodule=""></script>
         <script src="/_next/static/chunks/4952ddcd88e7185e66c9cf40e2d848b7e27f1574.6ad24cd530d796126b06.module.js"
         async="" crossorigin="anonymous" type="module"></script>
-        <script src="/_next/static/chunks/de003c3a9d308750aa009870a5926f9b18ab31f4.f076221efab25e5c3391.js"
+        <script src="/_next/static/chunks/de003c3a9d308750aa009870a5926f9b18ab31f4.649df3cf3ededecb4362.js"
         async="" crossorigin="anonymous" nomodule=""></script>
-        <script src="/_next/static/chunks/de003c3a9d308750aa009870a5926f9b18ab31f4.8499a53d1674e87c1349.module.js"
+        <script src="/_next/static/chunks/de003c3a9d308750aa009870a5926f9b18ab31f4.7cf360095f4d019aa946.module.js"
         async="" crossorigin="anonymous" type="module"></script>
         <script src="/_next/static/BUILD_ID/_buildManifest.js" async=""
         crossorigin="anonymous" nomodule=""></script>

Diff for link.html
@@ -16,7 +16,7 @@
         as="script" crossorigin="anonymous" />
         <link rel="preload" href="/_next/static/chunks/4952ddcd88e7185e66c9cf40e2d848b7e27f1574.6ad24cd530d796126b06.module.js"
         as="script" crossorigin="anonymous" />
-        <link rel="preload" href="/_next/static/chunks/de003c3a9d308750aa009870a5926f9b18ab31f4.8499a53d1674e87c1349.module.js"
+        <link rel="preload" href="/_next/static/chunks/de003c3a9d308750aa009870a5926f9b18ab31f4.7cf360095f4d019aa946.module.js"
         as="script" crossorigin="anonymous" />
         <link rel="preload" href="/_next/static/chunks/16b1a72255206b7853bf6603dc58ec83de39b142.bf8f1811d3a9e831f44d.module.js"
         as="script" crossorigin="anonymous" />
@@ -59,9 +59,9 @@
         async="" crossorigin="anonymous" nomodule=""></script>
         <script src="/_next/static/chunks/4952ddcd88e7185e66c9cf40e2d848b7e27f1574.6ad24cd530d796126b06.module.js"
         async="" crossorigin="anonymous" type="module"></script>
-        <script src="/_next/static/chunks/de003c3a9d308750aa009870a5926f9b18ab31f4.f076221efab25e5c3391.js"
+        <script src="/_next/static/chunks/de003c3a9d308750aa009870a5926f9b18ab31f4.649df3cf3ededecb4362.js"
         async="" crossorigin="anonymous" nomodule=""></script>
-        <script src="/_next/static/chunks/de003c3a9d308750aa009870a5926f9b18ab31f4.8499a53d1674e87c1349.module.js"
+        <script src="/_next/static/chunks/de003c3a9d308750aa009870a5926f9b18ab31f4.7cf360095f4d019aa946.module.js"
         async="" crossorigin="anonymous" type="module"></script>
         <script src="/_next/static/chunks/16b1a72255206b7853bf6603dc58ec83de39b142.232776eb4cfc32f0ebfe.js"
         async="" crossorigin="anonymous" nomodule=""></script>

Diff for withRouter.html
@@ -16,7 +16,7 @@
         as="script" crossorigin="anonymous" />
         <link rel="preload" href="/_next/static/chunks/4952ddcd88e7185e66c9cf40e2d848b7e27f1574.6ad24cd530d796126b06.module.js"
         as="script" crossorigin="anonymous" />
-        <link rel="preload" href="/_next/static/chunks/de003c3a9d308750aa009870a5926f9b18ab31f4.8499a53d1674e87c1349.module.js"
+        <link rel="preload" href="/_next/static/chunks/de003c3a9d308750aa009870a5926f9b18ab31f4.7cf360095f4d019aa946.module.js"
         as="script" crossorigin="anonymous" />
         <link rel="preload" href="/_next/static/chunks/16b1a72255206b7853bf6603dc58ec83de39b142.bf8f1811d3a9e831f44d.module.js"
         as="script" crossorigin="anonymous" />
@@ -57,9 +57,9 @@
         async="" crossorigin="anonymous" nomodule=""></script>
         <script src="/_next/static/chunks/4952ddcd88e7185e66c9cf40e2d848b7e27f1574.6ad24cd530d796126b06.module.js"
         async="" crossorigin="anonymous" type="module"></script>
-        <script src="/_next/static/chunks/de003c3a9d308750aa009870a5926f9b18ab31f4.f076221efab25e5c3391.js"
+        <script src="/_next/static/chunks/de003c3a9d308750aa009870a5926f9b18ab31f4.649df3cf3ededecb4362.js"
         async="" crossorigin="anonymous" nomodule=""></script>
-        <script src="/_next/static/chunks/de003c3a9d308750aa009870a5926f9b18ab31f4.8499a53d1674e87c1349.module.js"
+        <script src="/_next/static/chunks/de003c3a9d308750aa009870a5926f9b18ab31f4.7cf360095f4d019aa946.module.js"
         async="" crossorigin="anonymous" type="module"></script>
         <script src="/_next/static/chunks/16b1a72255206b7853bf6603dc58ec83de39b142.232776eb4cfc32f0ebfe.js"
         async="" crossorigin="anonymous" nomodule=""></script>

Serverless Mode (Increase detected ⚠)

General Overall increase ⚠

zeit/next.js canary
janicklas-ralph/next.js native-url
Change

buildDuration
14s
14.2s
⚠ +165ms

nodeModulesSize
49 MB
49 MB
⚠ +1.59 kB

Client Bundles (main, webpack, commons)

zeit/next.js canary
janicklas-ralph/next.js native-url
Change

main-HASH.js
18.1 kB
18.1 kB
✓

main-HASH.js gzip
6.39 kB
6.39 kB
✓

webpack-HASH.js
1.53 kB
1.53 kB
✓

webpack-HASH.js gzip
746 B
746 B
✓

16b1a7225520..4086094cc.js
19.8 kB
19.8 kB
✓

16b1a7225520..94cc.js gzip
7.37 kB
7.37 kB
✓

4952ddcd88e7..49d7903c2.js
9.6 kB
9.6 kB
✓

4952ddcd88e7..03c2.js gzip
3.76 kB
3.76 kB
✓

commons.HASH.js
10.4 kB
10.4 kB
✓

commons.HASH.js gzip
3.91 kB
3.91 kB
✓

de003c3a9d30..dd6294d03.js
21.1 kB
N/A
N/A

de003c3a9d30..4d03.js gzip
8.15 kB
N/A
N/A

framework.HASH.js
125 kB
125 kB
✓

framework.HASH.js gzip
39.4 kB
39.4 kB
✓

de003c3a9d30..93e0efc89.js
N/A
21.2 kB
N/A

de003c3a9d30..fc89.js gzip
N/A
8.18 kB
N/A

Overall change
206 kB
206 kB
✓

Client Bundles (main, webpack, commons) Modern

zeit/next.js canary
janicklas-ralph/next.js native-url
Change

main-HASH.module.js
14.1 kB
14.1 kB
✓

main-HASH.module.js gzip
5.33 kB
5.33 kB
✓

webpack-HASH.module.js
1.53 kB
1.53 kB
✓

webpack-HASH..dule.js gzip
746 B
746 B
✓

16b1a7225520..95.module.js
21.1 kB
21.1 kB
✓

16b1a7225520..dule.js gzip
8.14 kB
8.14 kB
✓

4952ddcd88e7..cc.module.js
11.9 kB
11.9 kB
✓

4952ddcd88e7..dule.js gzip
4.41 kB
4.41 kB
✓

de003c3a9d30..3e.module.js
14.9 kB
N/A
N/A

de003c3a9d30..dule.js gzip
6.11 kB
N/A
N/A

framework.HASH.module.js
125 kB
125 kB
✓

framework.HA..dule.js gzip
39.4 kB
39.4 kB
✓

de003c3a9d30..fc.module.js
N/A
14.9 kB
N/A

de003c3a9d30..dule.js gzip
N/A
6.14 kB
N/A

Overall change
189 kB
189 kB
✓

Legacy Client Bundles (polyfills)

zeit/next.js canary
janicklas-ralph/next.js native-url
Change

polyfills-HASH.js
15.3 kB
15.3 kB
✓

polyfills-HASH.js gzip
4.75 kB
4.75 kB
✓

Overall change
15.3 kB
15.3 kB
✓

Client Pages

zeit/next.js canary
janicklas-ralph/next.js native-url
Change

_app.js
2.92 kB
2.92 kB
✓

_app.js gzip
1.32 kB
1.32 kB
✓

_error.js
13.2 kB
13.2 kB
✓

_error.js gzip
5.1 kB
5.1 kB
✓

hooks.js
1.92 kB
1.92 kB
✓

hooks.js gzip
941 B
941 B
✓

index.js
318 B
318 B
✓

index.js gzip
222 B
222 B
✓

link.js
6.76 kB
6.76 kB
✓

link.js gzip
2.88 kB
2.88 kB
✓

routerDirect.js
413 B
413 B
✓

routerDirect.js gzip
285 B
285 B
✓

withRouter.js
423 B
423 B
✓

withRouter.js gzip
284 B
284 B
✓

Overall change
25.9 kB
25.9 kB
✓

Client Pages Modern

zeit/next.js canary
janicklas-ralph/next.js native-url
Change

_app.module.js
1.53 kB
1.53 kB
✓

_app.module.js gzip
745 B
745 B
✓

_error.module.js
10.3 kB
10.3 kB
✓

_error.module.js gzip
4.24 kB
4.24 kB
✓

hooks.module.js
651 B
651 B
✓

hooks.module.js gzip
371 B
371 B
✓

index.module.js
276 B
276 B
✓

index.module.js gzip
212 B
212 B
✓

link.module.js
5.44 kB
5.44 kB
✓

link.module.js gzip
2.45 kB
2.45 kB
✓

routerDirect.module.js
386 B
386 B
✓

routerDirect..dule.js gzip
275 B
275 B
✓

withRouter.module.js
396 B
396 B
✓

withRouter.m..dule.js gzip
274 B
274 B
✓

Overall change
19 kB
19 kB
✓

Client Build Manifests

zeit/next.js canary
janicklas-ralph/next.js native-url
Change

_buildManifest.js
244 B
244 B
✓

_buildManifest.js gzip
200 B
200 B
✓

_buildManifest.module.js
251 B
251 B
✓

_buildManife..dule.js gzip
210 B
210 B
✓

Overall change
495 B
495 B
✓

Serverless bundles

zeit/next.js canary
janicklas-ralph/next.js native-url
Change

_error.js
256 kB
256 kB
✓

_error.js gzip
67.9 kB
67.9 kB
⚠ +2 B

hooks.html
4.19 kB
4.19 kB
✓

hooks.html gzip
1.07 kB
1.07 kB
⚠ +1 B

index.js
256 kB
256 kB
✓

index.js gzip
68 kB
68 kB
⚠ +2 B

link.js
288 kB
288 kB
✓

link.js gzip
77.1 kB
77.1 kB
⚠ +1 B

routerDirect.js
281 kB
281 kB
✓

routerDirect.js gzip
75.1 kB
75.1 kB
⚠ +1 B

withRouter.js
281 kB
281 kB
✓

withRouter.js gzip
75.2 kB
75.2 kB
⚠ +1 B

Overall change
1.37 MB
1.37 MB
✓

Commit: 69525176851007c8dbe635eac1fe49010459b80e

authors: ijjk janicklas-ralph


text:
Theme support?

What is the preferred way to do theming with styled-jsx?  Some examples in the readme reference a theme and say that theming is supported, but there aren't any specific examples of how this should be done.
Most other css-in-js libraries use a ThemeProvider, would that be where styled-jsx is going?

Along these same lines... the README mentions Dynamic styles and theme support but I don't see any examples or documentation about how to make themes work in styled-jsx out of the box. Can some documentation be added for this on the README?

source: gharchive/issue

authors: nmackey skitterm

repo: zeit/styled-jsx


text:
GridView: in ActionColumn unavable action icon.

use yii\grid\ActionColumn as BaseActionColumn;

class ActionColumn extends BaseActionColumn
 protected function initDefaultButtons()
    {
        if (!isset($this->buttons['view'])) {
...
                return Html::a('', $url, $options);
            };
        }
        if (!isset($this->buttons['update'])) {
...
            return Html::a('', $url, $options);
            };
        }
        if (!isset($this->buttons['delete'])) {
...
       return Html::a('', $url, $options);
            };
        }
    }

I don't understand you. What is your issue?

колонка action в gridview для иконок использует
,
которые я предлагаю заменить на semantic

ActionColumn использует для иконок glyphicon, которые я предлагаю заменить на вариант от semantic-ui.

Конкретнее. Как проблема касается данного расширения?

в GridView для редактирования, просмотра и удаления в ссылках иконки, использующие bootstrap.css, которые недоступны при его (bootstrap) отключении.

да, верно.
Добавил в версии 0.2.4 ActionColumn и Pjax.

authors: pol-den zelenin


text:
How to prefill with default values

I am using this plugin. I have an array object. I want to add the token in the input by default. for not i am trying to add a javascript come:
$('#tokenize').tokenize().tokenAdd(value, text);
unfortunately from the javascript file, this didnt work but when using this code in console, it works perfectly.
Please help me!

Try this:
$(function(){
    ...
    $('#tokenize').tokenize().tokenAdd(value, text);
    ...
});

I am trying to do this in on ready() function.

sir,
it will be really great if you can solve the above mentioned issue

Ok I understand your problem, if you want add item in the select on load that not listed in the select options you have to set the option newElements at true.

Thank you sir! worked like a charm. There is one more issue. I have a list of localities in an array object. Total count of localities is 35. I am putting these localities in the drop down using this code in my javascript:
localityList.forEach(function(locality) {
    var id = locality.localityId;
    var name = locality.localityName;

    //trying to put the locality value in the dropdown list using append function
    var option = $('<option value=' + id + '></option>').text(name);
    $('#userLocality').append(option);
 });

But instead of containing 35 localities, the maximum no. of elements getting inserted is only 10. Is there any restrictions in it. Please help!

Please read the doc: https://www.zellerda.com/projects/jquery/tokenize
By default the dropdown show only 10 values but you can incrase this value with nbDropdownElements

repo: zellerda/Tokenize


text:
Floating URLbar only appears when you start typing

The floating URL bar appears (in the middle of the screen) only when you start typing something. Until then, even when pressing CTRL+L, the entire text in the top URL bar gets selected. Once you start typing, the mode activates as it should, appearing in the middle of the screen.

My ZEN Version is up-to-date

Solved: you need enable shortcuts in search

Solved: you need enable shortcuts in search

repo: zen-browser/theme-components

license: MIT

license_source: github-api


text:
Can you give me a pointer...

Hey Craig,
I want to use Biz to create a list of forthcoming time slots within business hours. For example, if I have business hour monday-friday 10am - 3pm, I want to be able to offer a list of slots of 2 hours, every hour until closing, i.e. mon: 10-12, 11-13, 12-4, 13-15, and onwards thru tuesday etc.
Not asking for a full solution, but could you give me a hint of where to start?
Thanks.
James

Any assumptions that can be made that would make it easier? Would the time slots always start on the hour, or does it depend on when the business hours start (e.g., if hours were 10:30 - 15:30, would you be looking for 10:30 - 12:30, 11:30 - 13:30, etc.)?

Thanks Craig for responding so fast and allowing me to abuse github issues. It's dependent on business hours start, so would be every hour from then.

Here's something to start with:
require 'bundler/inline'

gemfile do
  source 'https://rubygems.org'

  gem 'biz', '1.6.0'
end

require 'biz'
require 'pp'

SCHEDULE = Biz::Schedule.new do |config|
  config.hours = {
    mon: {'09:00' => '17:00'},
    tue: {'10:00' => '16:00'},
    wed: {'08:30' => '11:00', '12:00' => '17:00'},
    thu: {'09:30' => '17:30'},
    fri: {'08:00' => '17:30'}
  }
end

def slots(origin:, duration:, offset:)
  Enumerator::Lazy.new(SCHEDULE.periods.after(origin)) do |yielder, period|
    start_time = period.start_time

    loop do
      slot = Biz::TimeSegment.new(start_time, start_time + duration.in_seconds)

      fail StopIteration unless (period & slot).duration == duration

      yielder << slot

      start_time += offset.in_seconds
    end
  end
end

pp(
  slots(
    origin:   Time.utc(2016, 7, 11, 8),
    duration: Biz::Duration.hours(2),
    offset:   Biz::Duration.hours(1)
  ).take(35).map(&:endpoints).to_a
)

# [[2016-07-11 09:00:00 UTC, 2016-07-11 11:00:00 UTC],
#  [2016-07-11 10:00:00 UTC, 2016-07-11 12:00:00 UTC],
#  [2016-07-11 11:00:00 UTC, 2016-07-11 13:00:00 UTC],
#  [2016-07-11 12:00:00 UTC, 2016-07-11 14:00:00 UTC],
#  [2016-07-11 13:00:00 UTC, 2016-07-11 15:00:00 UTC],
#  [2016-07-11 14:00:00 UTC, 2016-07-11 16:00:00 UTC],
#  [2016-07-11 15:00:00 UTC, 2016-07-11 17:00:00 UTC],
#  [2016-07-12 10:00:00 UTC, 2016-07-12 12:00:00 UTC],
#  [2016-07-12 11:00:00 UTC, 2016-07-12 13:00:00 UTC],
#  [2016-07-12 12:00:00 UTC, 2016-07-12 14:00:00 UTC],
#  [2016-07-12 13:00:00 UTC, 2016-07-12 15:00:00 UTC],
#  [2016-07-12 14:00:00 UTC, 2016-07-12 16:00:00 UTC],
#  [2016-07-13 08:30:00 UTC, 2016-07-13 10:30:00 UTC],
#  [2016-07-13 12:00:00 UTC, 2016-07-13 14:00:00 UTC],
#  [2016-07-13 13:00:00 UTC, 2016-07-13 15:00:00 UTC],
#  [2016-07-13 14:00:00 UTC, 2016-07-13 16:00:00 UTC],
#  [2016-07-13 15:00:00 UTC, 2016-07-13 17:00:00 UTC],
#  [2016-07-14 09:30:00 UTC, 2016-07-14 11:30:00 UTC],
#  [2016-07-14 10:30:00 UTC, 2016-07-14 12:30:00 UTC],
#  [2016-07-14 11:30:00 UTC, 2016-07-14 13:30:00 UTC],
#  [2016-07-14 12:30:00 UTC, 2016-07-14 14:30:00 UTC],
#  [2016-07-14 13:30:00 UTC, 2016-07-14 15:30:00 UTC],
#  [2016-07-14 14:30:00 UTC, 2016-07-14 16:30:00 UTC],
#  [2016-07-14 15:30:00 UTC, 2016-07-14 17:30:00 UTC],
#  [2016-07-15 08:00:00 UTC, 2016-07-15 10:00:00 UTC],
#  [2016-07-15 09:00:00 UTC, 2016-07-15 11:00:00 UTC],
#  [2016-07-15 10:00:00 UTC, 2016-07-15 12:00:00 UTC],
#  [2016-07-15 11:00:00 UTC, 2016-07-15 13:00:00 UTC],
#  [2016-07-15 12:00:00 UTC, 2016-07-15 14:00:00 UTC],
#  [2016-07-15 13:00:00 UTC, 2016-07-15 15:00:00 UTC],
#  [2016-07-15 14:00:00 UTC, 2016-07-15 16:00:00 UTC],
#  [2016-07-15 15:00:00 UTC, 2016-07-15 17:00:00 UTC],
#  [2016-07-18 09:00:00 UTC, 2016-07-18 11:00:00 UTC],
#  [2016-07-18 10:00:00 UTC, 2016-07-18 12:00:00 UTC],
#  [2016-07-18 11:00:00 UTC, 2016-07-18 13:00:00 UTC]]

Let me know if you have questions or if any of that doesn't make sense.
Hope that helps!

Thank you so much Craig. Way more than than I hoped for. Thanks for making such a useful gem too.

repo: zendesk/biz


text:
Cluster metadata not refreshed after a topic has been reassigned

We were using Kafka::Client#each_message to consume from __consumer_offsets in order to report consumer lag. When we migrated the topic to a new set of brokers (as part of an upgrade), our script stopped receiving new offsets due to Kafka::UnknownTopicOrPartition. The script kept retrying and kept receiving the same error, because the cluster metadata is never refreshed in that situation.
The fix is simple: https://github.com/zendesk/ruby-kafka/pull/609/files

Fixed by #609.

authors: dasch ttamimi

repo: zendesk/ruby-kafka


text:
No zend-debug ^3.0 tagged yet

remove || ^3.0 from zend-debug require list

Thanks, @samsonasik; nice catch!

authors: samsonasik weierophinney

repo: zendframework/ZendDeveloperTools


text:
Db\Sql\Select- add support to select column with Sql\Select

Currently the Db\Sql\Select::processSelect() supports only expression as column.  It will be nice to add the support for Select object too. So it will produce "SELECT (SELECT ...) as column".
e.g.
$select->columns(['column' => new Select()])
It's required to change https://github.com/zendframework/zf2/blob/develop/library/Zend/Db/Sql/Select.php#L640 like following:

if ($column instanceof self) {
    $columnName .= '(' . $this->processSubSelect($column, $platform, $driver, $parameterContainer) . ')';
} elseif ($column instanceof ExpressionInterface) {

This issue has been closed as part of the bug migration program as outlined here - http://framework.zend.com/blog/2016-04-11-issue-closures.html

authors: GeeH bacinsky

repo: zendframework/zendframework


text:
Android系统版本兼容ReflectiveOperationException问题

反射获取getTag接口报ReflectiveOperationException
private static String getWakeLockTag(PowerManager.WakeLock wakeLock) {
        String tag = "Default-WakeLock-Tag";
        if (wakeLock == null) {
            return tag;
        }
        try {
            Method getTagMethod = wakeLock.getClass().getDeclaredMethod("getTag");
            getTagMethod.setAccessible(true);
            tag = (String) getTagMethod.invoke(wakeLock, (Object[]) null);
        } catch (ClassNotFoundExceptione) {
            LogUtil.w(TAG,e);
        }
        return tag;
    }

上述的说法并不完全正确，因为发现如果我们修改代码如下：
 private static String getWakeLockTag(PowerManager.WakeLock wakeLock,String wakeLockName) {
        String tag = "Default-WakeLock-Tag";
        if (wakeLock == null) {
            return tag;
        }

        if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.KITKAT) {
            try {
                Method getTagMethod = wakeLock.getClass().getDeclaredMethod("getTag");
                getTagMethod.setAccessible(true);
                new ReflectiveOperationException("test");// 直接New一个，而不是在catch的代码块里面
                tag = (String) getTagMethod.invoke(wakeLock, (Object[]) null);
            }catch (Exception e) {
                LogUtil.w(TAG,e);
            }
        }else {
            LogUtil.d(TAG, "api < 19 ,so wakeLockName: " + wakeLockName);
            return wakeLockName;
        }
        return tag;
    }

这样在运行时，并不会报错。

那么catch里面和直接在代码里面直接去new有什么区别呢？

catch代码块在类加载时就会进行校验
而代码中需要运行时才会检测

所以，出现了上述的现象。在代码中 new ReflectiveOperationException("test");并没有真正的运行，但是在catch代码块中直接就爆出了 java.lang.VerifyError`。

repo: zengjingfang/AndroidBox


text:
VQA generate form

Hi thanks for your work and public release of the code.
I have checked your code and I could not find the generate function of your model while using the VQA model. I want to be able to input new questions to the model and generate answers which are independent of the ground truth (which is what currently your VQA evaluation does et. model the task as ranking at inference). I have also checked your Captioning task, but this one does not receive any question for the generation of the caption. Therefore it has not been clear for me where to input the question or the merge question+image embedding for the generative task.
Could you please provide the generative function of your VQA model (with text_encoder and text_decoder) in a generative fashion?
Thank you,
MA

Hi,
do you still need it?
I have the code, but I did not release it since I only use it for some private tasks.

Hi, do you still need it? I have the code, but I did not release it since I only use it for some private tasks.

Do you have the instructions to just evaluate your model with other dataset? Thanks


text:
net: ipv4: udp: broadcast delivery not supported

Zephyr drops UDP packet with broadcast destination IP and unicast MAC. According to RFC 1122 4.1.1 this scenarion should be supported by UDP: "... to use communications services (e.g., multicast or broadcast delivery) not available from TCP."
ipv4-udp-bcast-dst.pcap.gz

New pcap, with correct Zephyr MAC address.
ipv4-udp-bcast-dst2.pcap.gz

repo: zephyrproject-rtos/zephyr


text:
Improved user interface for devicetree (like guiconfig)

Is your enhancement proposal related to a problem? Please describe.
Devicetree is widely used by Zephyr, but it lacks convenient tooling for development.
It is used by most in-tree device drivers to instantiate struct device objects and describe desired boot-time configuration. Users are expected to understand enough about devicetree to configure and enable devices using devicetree overlays, and an increasing amount of basic pin control is using devicetree as well.
However, the user-visible tooling for viewing and editing the final devicetree is lacking in maturity compared to Kconfig. Users basically have to open build/zephyr/zephyr.dts and build/zephyr/include/generated/devicetree_unfixed.h to get information about the final devicetree itself and check their work while developing.
This is a usability hurdle which also causes support burden. The complexity of dealing with devicetree is a regular complaint against the project.
Describe the solution you'd like
A graphical devicetree viewer and editor, like 'guiconfig' for DTS. This program should be able to load the devicetree from a build directory and pair nodes with contextual information about bindings, as well as suggest or even perform edits (such as "here's how to refer to this property from C", or "here's how to enable this node in an overlay file").
Describe alternatives you've considered
A curses-based console application like 'menuconfig' was considered but rejected because:

I am not willing to write one, and anyway
the windows-curses library we depend on for cross-platform curses is going unmaintained

Additional context
I am inspired by the excellent work done in @trond-snekvik 's VS code extension and @ulfalizer 's 'menuconfig' and 'guiconfig', as well as the original Linux C programs for managing the kconfig tree.
I would like to have a portable, IDE-independent interface for Zephyr that uses edtlib and is written in Python.

No schedule and I have not started work. I'm just putting this into the world as something I want to do to get comments from elsewhere.

I can offer some help if PySide2 (a.k.a. Qt for Python) is considered as a viable GUI framework.

I can offer some help if PySide2 (a.k.a. Qt for Python) is considered as a viable GUI framework.

That's exactly what I'm thinking. Let's talk when it comes time.

I can offer some help if PySide2 (a.k.a. Qt for Python) is considered as a viable GUI framework.

Does it require installation of Qt5 ?
Why not Tkinter which is bundled with python3 also it is used in guiconfig.

Does it require installation of Qt5 ?

You can install PySide2 it with pip just like any other binary python dependency.

Why not Tkinter which is bundled with python3 also it is used in guiconfig.

To be honest, because tkinter based interfaces look really dated and there doesn't seem to be a lot of developer momentum behind the project.

I ran across this interesting message on the DT spec mailing list:
https://www.spinics.net/lists/devicetree-spec/msg00950.html
It seems to be exactly what this issue anticipates and something to investigate further. cc @trond-snekvik

I personally would find this to be quite useful to help with understanding how to use dt.

authors: ExtremeGTX gmarull mbolivar-nordic rlneumiller


text:
Bluetooth: Add a dynamic TX Power API

Implement a new Bluetooth API that is able to set the TX power dynamically, sending the VS HCI commands  that are already in the tree and implemented manually in this file:
https://github.com/zephyrproject-rtos/zephyr/blob/main/samples/bluetooth/hci_pwr_ctrl/src/main.c

Is there any update to develop this feature?
Also I found that the above sample (https://github.com/zephyrproject-rtos/zephyr/blob/main/samples/bluetooth/hci_pwr_ctrl/src/main.c) only works when "Extended Advertising" has not been used. While as you can find in this file:
zephyr/subsys/bluetooth/controller/ll_sw/nordic/lll/lll_adv_aux.c
static int prepare_cb(struct lll_prepare_param *p)
{
...
#if defined(CONFIG_BT_CTLR_TX_PWR_DYNAMIC_CONTROL)
	radio_tx_power_set(lll->tx_pwr_lvl);
#else
	radio_tx_power_set(RADIO_TXP_DEFAULT);
#endif /* CONFIG_BT_CTLR_TX_PWR_DYNAMIC_CONTROL */
...
}

It is expected to set tx power to a desired value when "CONFIG_BT_CTLR_TX_PWR_DYNAMIC_CONTROL" has been set, but there is no way to set lll->tx_pwr_lvl outside of this function, even the above example can't affect on this variable.

It is expected to set tx power to a desired value when "CONFIG_BT_CTLR_TX_PWR_DYNAMIC_CONTROL" has been set, but there is no way to set lll->tx_pwr_lvl outside of this function, even the above example can't affect on this variable.

Support for Dynamic Tx Power in  Extended Advertising is fixed here: https://github.com/zephyrproject-rtos/zephyr/commit/a3127afb53bdbcdf0046db0a196160aadbd0d159

Related: https://github.com/zephyrproject-rtos/zephyr/pull/65273

authors: alwa-nordic carlescufi cvinayak saleh-unikie


text:
tests: drivers: : ethernet: fails to link for sam_v71_xult and sam_v71b_xult

Describe the bug
The daily build fails to link for this test / platform combination.
To Reproduce
twister -i -p sam_v71_xult -s tests/drivers/build_all/ethernet/net.ethernet.build
twister -i -p sam_v71b_xult -s tests/drivers/build_all/ethernet/net.ethernet.build

Expected behavior
The daily build should not fail.
Impact
Showstopper for anyone using ethernet on these platforms.
Logs and console output
/opt/toolchains/zephyr-sdk-0.13.2/arm-zephyr-eabi/bin/../lib/gcc/arm-zephyr-eabi/10.3.0/../../../../arm-zephyr-eabi/bin/ld.bfd: zephyr/drivers/spi/libdrivers__spi.a(spi_sam.c.obj):(.rodata.__compound_literal.0+0x0): undefined reference to `__device_dts_ord_27'
/opt/toolchains/zephyr-sdk-0.13.2/arm-zephyr-eabi/bin/../lib/gcc/arm-zephyr-eabi/10.3.0/../../../../arm-zephyr-eabi/bin/ld.bfd: zephyr/drivers/spi/libdrivers__spi.a(spi_sam.c.obj):(.rodata.__compound_literal.0+0x8): undefined reference to `__device_dts_ord_27'
collect2: error: ld returned 1 exit status
ninja: build stopped: subcommand failed.

Environment (please complete the following information):

OS: CI
Toolchain: Zephyr SDK 0.13.2
Commit SHA: 7f5eb921dc8bb1b7014886986bbffdf111b68b15

Additional context
Daily build failure:
https://github.com/zephyrproject-rtos/zephyr/runs/4676614702?check_suite_focus=true

seems similar to #41677

authors: cfriedt dkalowsk


text:
tests-ci : drivers: watchdog test Build failure of mimxrt1064_evk

Describe the bug
when build the samples/drivers/watchdog for the mimxrt1064_evk   platform
build error occurs on the 'MSEC_PER_SEC' undeclared
To Reproduce
Steps to reproduce the behavior:

west build -p auto -b mimxrt1064_evk samples/drivers/watchdog^
See error

Expected behavior
build PASSED
Impact
ci fails
Logs and console output

./drivers/watchdog/wdt_mcux_imx_wdog.c: In function 'mcux_wdog_install_timeout':
./drivers/watchdog/wdt_mcux_imx_wdog.c:79:32: error: 'MSEC_PER_SEC' undeclared (first use in this function)
   79 |         if (cfg->window.max < (MSEC_PER_SEC / 2)) {
      |                                ^~~~~~~~~~~~
./drivers/watchdog/wdt_mcux_imx_wdog.c:79:32: note: each undeclared identifier is reported only once for each function it appears in

Environment (please complete the following information):

OS:  ubuntu
Toolchain Zephyr SDK,0.15.0
Commit SHA 07de2ffbb01a4633cdec7e48190ae369ecc37c9b

probably same as https://github.com/zephyrproject-rtos/zephyr/issues/51436


text:
hardening: hardened.csv is outdated

Describe the bug
Zephyr's hardening tool might be one of those hidden gems that many folks (including maintainers) don't even know exist.
https://docs.zephyrproject.org/latest/security/hardening-tool.html#usage
The hardened.csv file is meant to help with flagging the use of features not recommended for production devices (ex. experimental features, logging, ...).
It appears that the file hasn't been maintained and several features that moved out of experimentals (NET_SOCKETS_OFFLOAD, UART_ASYNC_API, ...) are still marked experimental there. What's more, there's probably many other features added over the years that'd need to be properly documented w.r.t their recommended values.
To Reproduce
Steps to reproduce the behavior:

west build -b nrf52840dk_nrf52840 .\samples\subsys\logging\logger (a samples that uses UART_ASYNC_API)
cd build
ninja hardenconfig
FAIL due to CONFIG_UART_ASYNC_API being set to Y when recommend is N. But this API is not experimental anymore so shouldn't be "not" recommended.

Expected behavior
hardened.csv file should reflect actual recommended values as per maintainers/security group, in particular all the experimental/beta features should be aligned with current codebase.
Impact
Lack of clarity w.r.t relevance/usefulness of the hardening tool.
Environment (please complete the following information):

OS: all
Toolchain: 0.16.0
Commit SHA or Version: 3a08d9620ae5528d36f3b013b906eadfc9fed5e7

Additional context
cc @ceolin @kestewart

@de-nordic seems like this feature is similar to https://github.com/zephyrproject-rtos/zephyr/pull/47698

@de-nordic seems like this feature is similar to #47698

indeed, thanks for flagging

indeed, thanks for flagging, this might end up being a good replacement for the hardening tool altogether?

I do not think so: https://github.com/zephyrproject-rtos/zephyr/pull/47698#pullrequestreview-1418466474

authors: kartben nordicjm stephanosio


text:
Make options depend on their features

This PR contains misc. Kconfig cleanups.
Including;

Hiding features from users that are working on platforms where the feature is unsupported.
Reducing copy-paste between Kconfig options, e.g. using 'if' instead of many 'depends on' statements.
Adding checkboxes to menu's to visualize whether anything within the menu category is enabled.
Hiding empty menus

Overall, it makes the Kconfig menu more navigatable and prevents invalid configurations.

Codecov Report

Merging #12234 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master   #12234   +/-   ##
=======================================
  Coverage    48.3%    48.3%
=======================================
  Files         293      293
  Lines       44134    44134
  Branches    10591    10591
=======================================
  Hits        21318    21318
  Misses      18550    18550
  Partials     4266     4266

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 06d7835...629623e. Read the comment docs.

authors: SebastianBoe codecov-io


text:
USB: Unifying legacy and composite (including cherry-picked)

Cherry-picked patches from PR #11041 (which was closed). Rebased against latest master.
@aurel32 please push any missing patches to this branch if needed.

@finikorg Is it still WIP?

Rebased and fixed conflicts with master.

Tested it for a while:
hci_usb :x: (on master :x:)
cdc_acm :white_check_mark:
cdc_acm_composite :white_check_mark:
dfu :white_check_mark:
dfu + composite mode :x: (class_handler (and custom_handler) is hardcoded to primary set of descriptors, dfu has two set of descriptors and does not work in composite configuration)
hid-mouse :white_check_mark:
hid-cdc :white_check_mark:
mass :white_check_mark:
testusb :white_check_mark:

Tested with nrf52840_pca10056:

Sample
Result

cdc_acm
:heavy_check_mark:

cdc_acm_composite
:heavy_check_mark:

hid
:heavy_check_mark:

hid-mouse
:heavy_check_mark:

hid-cdc
:heavy_check_mark:

mass
:heavy_check_mark:

Although all of them exhibited reconnection issues, as expected.


text:
gpio: add simulated gpio driver

This change has similar goals to #26003 except that this is targeting gpio rather than i2c.
By simulating a GPIO controller and a number of pins, integration testing can be made simpler where high-level input needs to be validated against low-level I/O.
Fixes #26477

Current status:
*** Booting Zephyr OS build zephyr-v2.3.0-630-gcae423d86622  ***
Running test suite gpio_basic_test
===================================================================
START - test_gpio_port
Validate device GPIO_0
Check GPIO_0 output 0 connected to input 1
OUT 0 to IN 1 linkage works
- bits_physical
- pin_physical
- check_raw_output_levels
- check_logic_output_levels
- check_input_levels
- bits_logical
- check_pulls

    Assertion failed at WEST_TOPDIR/zephyr/tests/drivers/gpio/gpio_basic_api/src/test_gpio_port.c:510: check_pulls: (raw_in() not equal to false)
physical pull-down does not read low
 FAIL - test_gpio_port
===================================================================
START - test_gpio_callback_add_remove

    Assertion failed at WEST_TOPDIR/zephyr/tests/drivers/gpio/gpio_basic_api/src/test_callback_manage.c:104: test_callback_add_remove: (rc not equal to 0)
init_callback failed
 FAIL - test_gpio_callback_add_remove
===================================================================
START - test_gpio_callback_self_remove

    Assertion failed at WEST_TOPDIR/zephyr/tests/drivers/gpio/gpio_basic_api/src/test_callback_manage.c:153: test_callback_self_remove: (rc not equal to 0)
init_callback failed
 FAIL - test_gpio_callback_self_remove
===================================================================
START - test_gpio_callback_enable_disable

    Assertion failed at WEST_TOPDIR/zephyr/tests/drivers/gpio/gpio_basic_api/src/test_callback_manage.c:205: test_callback_enable_disable: (rc not equal to 0)
init_callback failed
 FAIL - test_gpio_callback_enable_disable
===================================================================
START - test_gpio_callback_variants
FAIL - test_callback@89. config PIN_IN interrupt fail: -38

    Assertion failed at WEST_TOPDIR/zephyr/tests/drivers/gpio/gpio_basic_api/src/test_callback_trigger.c:132: test_gpio_callback_variants: (test_callback(GPIO_INT_EDGE_FALLING) not equal to TC_PASS)
falling edge failed
 FAIL - test_gpio_callback_variants
===================================================================
Test suite gpio_basic_test failed.
===================================================================
PROJECT EXECUTION FAILED
FAILED: zephyr/CMakeFiles/run
cd /home/chrisfriedt/workspace/zephyrproject/zephyr/build && /home/chrisfriedt/workspace/zephyrproject/zephyr/build/zephyr/zephyr.exe
ninja: build stopped: subcommand failed.
FATAL ERROR: command exited with status 1: /usr/local/bin/cmake --build /home/chrisfriedt/workspace/zephyrproject/zephyr/build --target run

Need to add a mechanism to the backend for clearing interrupts still.

This PR is close-ish to being done, so it makes sense to get some comments.
On my TODO list:

[ ]  fill in parts of code marked TODO (e.g. checking pin / mask validity)
[ ] add "backend" mechanisum for unpending an interrupt (i.e. marking it complete)
[ ] document gpio_sim.h

Not sure how to reference a source file in Doxygen .. would be nice to point to exmaples with hyperlinks for the doxygen in gpio_sim.h.
Also, any pointers for un-pending interrupts would be appreciated.

buildkite is failing because of some unrelated test in qemu_arc_hs. Hopefully that gets fixed soon.

I still need to add at least one test for clearing interrupt status. In Zephyr GPIO drivers, is the convention that the IRQ clears the interrupt status bits before calling callbacks?

@mnkp and @pabigot could you please take a look?

Didn't notice these before:

how to reference a source file in Doxygen (would be nice to point to examples with hyperlinks for the doxygen in gpio_sim.h)

I don't know.

un-pending interrupts

That would normally be done in the ISR, which here is simulated by gpio_sim_pend_interrupt() being invoked when pins change via gpio_sim_input_set_masked().
Normally all interrupts that are set in the call to gpio_fire_callbacks() would be cleared before it's invoked.   So there is no need to store them in the interrupts data word, unless you want to support an interrupt architecture where the condition can be captured but doesn't trigger as an interrupt until the pin is configured to interrupt mode.
What you do need to do, though, is fix the pend code for level interrupts.  One way to do that could be: after calling gpio_fire_callbacks() go through and check the level interrupts again, and if any are pended re-invoke gpio_fire_callbacks().  Repeat until no pins are found to be pended.  This would of course deadlock if the callbacks don't reconfigure the interrupts or change the state that triggered the level---which is exactly how real hardware behaves.

are __syscall prefixes required for the gpio_sim.h API calls?

Only if you expect the simulator manipulation functions to be invoked from a user process.  I would guess that's unlikely.

Thanks for all of the suggestions. I'm in a rabbit hole elsewhere but will get to this soon!

Didn't notice these before:

un-pending interrupts

That would normally be done in the ISR, which here is simulated by gpio_sim_pend_interrupt() being invoked when pins change via gpio_sim_input_set_masked().
Normally all interrupts that are set in the call to gpio_fire_callbacks() would be cleared before it's invoked. So there is no need to store them in the interrupts data word, unless you want to support an interrupt architecture where the condition can be captured but doesn't trigger as an interrupt until the pin is configured to interrupt mode.
What you do need to do, though, is fix the pend code for level interrupts. One way to do that could be: after calling gpio_fire_callbacks() go through and check the level interrupts again, and if any are pended re-invoke gpio_fire_callbacks(). Repeat until no pins are found to be pended. This would of course loop forever if the callbacks don't reconfigure the interrupts or change the state that triggered the level---which is exactly how real hardware behaves.

Thanks @pabigot
I'll have a look at unpending this afternoon, and I think I addressed all of your other points as well.

Didn't notice these before:
What you do need to do, though, is fix the pend code for level interrupts. One way to do that could be: after calling gpio_fire_callbacks() go through and check the level interrupts again, and if any are pended re-invoke gpio_fire_callbacks(). Repeat until no pins are found to be pended. This would of course loop forever if the callbacks don't reconfigure the interrupts or change the state that triggered the level---which is exactly how real hardware behaves.

@pabigot - please have a look at gpio_sim_pend_interrupt() again. I believe this should take into account level interrupt behaviour.
I could put together another test for that though, if you like. Interrupt bits are generated in a separate function now. The first time, it will generate interrupt bits for both edge and level interrupts. On the second and subsequent checks, only level-interrupt bits are generated. Level interrupts continue to be generated until the level is changed.

Any progress on this one?

Any progress on this one?

I have not had an iota of time to revisit it.
Customer requires

dynamic pthread stack allocation
dns-sd
various RF modifications for the cc1352r

Reworking these changes is not funded per se, so it has to take the bench until I have some time. I currently have a workaround for the first one, but neither of rhe latter two.
Just about done dns-sd.

What is the 'stashing' commit for?

An additional goal right now is to ensure that tests also pass for the gpio_api_1pin suite as well as checking off the box below:
- [ ] configurable interrupt mode via DT bindings - level, edge, and / or double-edge

Incidentally, is G using Z for a new BMC? Sounds very interesting.. If only I got > 4/5 stars when I intereviewed!

The gpio_basic_api and gpio_api_1pin test suites pass now but I feel like it's a bit hackish.
@pabigot - any thoughts?
The gpio_api_1pin test suite ensures that callbacks are called maximally once per event.
The last modification I made was to not duplicate callbacks when both an interrupt fires (the usual behaviour) and when an output pin changes value (for emulation of 'wiring'). I was getting two callbacks for a single pin change. I guess that I could add another variable saying which pins have had interrupts fire, and then mask off pins that were already handled by their input interrupts?

Suggestion to move to k_semaphore for mutex because that's more common, but since we're not consistent in Zephyr I won't insist.

I think the mutex is necessary in one or 2 locations due to reentrancy.

I think a lot of uint32_ts should be something more specific like gpio_port_value_t.  That should be cleaned up, if so.

Ok, will have a look.

Also the for statement where entry and exit statements are longer than the body really ought to be changed.

Hehe.. fair enough - will look at that today.

I think I had some visions of being able to use properties the binding to control implicit behavior on a per-instance basis, but I don't remember the details so I'm OK with having this go in.  I do want it flagged as experimental so we don't have to fight with users if the API needs to change.

Yep, those features were added. I think there is a separate commit for it, including bindings. It makes support for rising / falling / dual-edge as well as high / low / dual-level optional on a per-instance basis.
I broke it all out into individual bools in DT and the tests / samples enable all interrupt types Have not yet written test cases / overlays for every permutation though.

Suggestion to move to k_semaphore for mutex because that's more common, but since we're not consistent in Zephyr I won't insist.

I think the mutex is necessary in one or 2 locations due to reentrancy.

I'm not saying you don't need a mutex, but the mutex type you chose isn't what we normally use.  k_mutex is reentrant and priority inheriting; most things use k_sem with a maximum count of 1.

Uh-oh - will need to back off my last changeset.

I think I saw a issue with a separate driver failing some tests, so rebased. Hopefully it's all green again.

Missed looking at the binding, found a couple more uint32_t.

I think I got the last of them. Thanks!

authors: carlescufi cfriedt pabigot sjg20


text:
tests: adding test cases for counter RTC on nucleo_l152 board

This patch enables the RTC as counter feature so that the testcase tests/drivers/counter/counter_basic_api
can run on this nucleo_l152re board from STMicroelectronics
$ west build -p auto -b nucleo_l152re tests/drivers/counter/counter_basic_api/
Signed-off-by: Francois Ramu francois.ramu@st.com

START - test_all_channels
Testing RTC_0
D: Set Alarm: 11
PASS - test_all_channels
START - test_late_alarm
Skipped for RTC_0
PASS - test_late_alarm
START - test_late_alarm_error
Skipped for RTC_0
PASS - test_late_alarm_error
START - test_short_relative_alarm
PASS - test_short_relative_alarm
START - test_cancelled_alarm_does_not_expire
Skipped for RTC_0
PASS - test_cancelled_alarm_does_not_expire
START - test_set_top_value_without_alarm
Skipped for RTC_0
PASS - test_set_top_value_without_alarm
Test suite test_counter succeeded
PROJECT EXECUTION SUCCESSFUL

@FRASTM please rebase

@FRASTM please rebase

@FRASTM please rebase

@ABOSTM maybe you could rebase this PR so we can get it in?

rebase

authors: FRASTM carlescufi ioannisg


text:
tests: interrupt: add test cases for testing direct interrupt of arch x86 and posix

Add test cases of direct interrupt for arch x86 and posix. Note here we need to add an extra compiler option "-mgeneral-regs-only" to make it works in arch x86. Because there are some existing x87 instructions inside interrupt context.
If we do not add GCC compiler option "-mgeneral-regs-only" as configuration when we use direct interrupt in arch x86, otherwise, a compilation error will happen: "sorry, unimplemented: 80387 instructions aren't allowed in an interrupt service routine".

Sorry, where is the FPU code that this is tripping over?   If that's real, we need to fix that much more urgently than we need to merge this test.

Sorry, where is the FPU code that this is tripping over? If that's real, we need to fix that much more urgently than we need to merge this test.

Hi @andyross  the error message is like this when we did not add  -mgeneral-regs-only
/home/mm/zephyrproject/zephyr/tests/kernel/interrupt/src/direct_isr.c:49:1: sorry, unimplemented: 80387 instructions aren't allowed in an interrupt service routine
49 | ISR_DIRECT_DECLARE(direct_isr1)
And I remembered during my trial, I ever saw some message related to SSE,  seems like in lib/os/cbprintf.c
va_start(ap, format);
rc = cbvprintf(out, ctx, format, ap);
va_end(ap);
Sorry, I did not remember how I make this message happened, let me try to reproduce it.

Please address the "Compliance" failure.

Please address the "Compliance" failure.

Ok, @LeiW000 got it. Got it fixed. Thank you!

Hi,  @andyross
I really did not find any FPU code here. I also tried to define an isr handler myself like this:
__attribute__ ((interrupt)) void direct_isr1(void *stack_frame)
{
        //ARG_UNUSED(stack_frame);

        //ISR_DIRECT_HEADER();

        //direct_int_executed[0]++;

        //ISR_DIRECT_FOOTER(0);
}

Even I comment all all code inside this function, it still shows following message:
/home/mm/zephyrproject/zephyr/tests/kernel/interrupt/src/direct_isr.c:48:1: sorry, unimplemented: 80387 instructions aren't allowed in an interrupt service routine
   48 | {
      | ^

I found two ways can avoid this compilation error:

Add the "-mgeneral-regs-only" gcc option for x86.
Remove the attribute ((interrupt)) in "include/arch/x86/ia32/arch.h" line:316
(This means in the exit of this function will use RET instead of IRET. I am not sure doing this is acceptable)

I was stuck here for a while, could you please give me some advice, thanks!

OK, I think I get it.  We have code generation set to enable floating point, so this function (or any that it calls) can legally build with float or double variables and emit 8087 instructions.  But GCC assumes that FPU exceptions can't be handled in an interrupt (this isn't actually true in the general case, you CAN have a scheme that allows this in theory, but it's not common OS design).
The GCC warning is actually correct as far as it goes.  We don't have any protection in our x86 arch layer to prevent kernel code in an interrupt from calling into something that tries the hit the FPU.  We just assume that it won't because we didn't write any such code.  But the compiler can't know that.
Dig around, there is very likely a code generation attribute that you can apply to this particular function that will disable FPU generation on this one particular function and thus suppress the warning.
Alternatively, we have to fix this at the level of the direct interrupt feature.   We could hide it behind a "CONFIG_X86_ENABLE_DIRECT_IRQ" or something, and when that is true disable FPU registers everywhere.  Which seems... not awful I guess.
Alternatively alternatively, we could drop the direct interrupt feature from the architecture entirely.  It's obviously not compatible with the MMU or userspace, I don't think we ever made it work on x86_64, it doesn't play well with the scheduler (we don't document it, but direct interrupts always return to the interrupted thread and thus can't wake a high priority thread up or suspend _current) and frankly super-low-latency interrupts aren't a x86 design goal on any current platforms.  @dcpleung might have input regarding 32 bit x86 needs.

Wow, it was a kind of epiphany, thank you so much! @andyross
For x86_64 in our design, we only have dynamic isr in place.
For x86, our codebase has all these three kinds of interrupts implemented, but so far I did not see the existing test cases for the IRQ_DIRCT_CONNECT (or IRQ_CONNECT), that's why I am trying to add them here.
But your words let me understand there are indeed other design considerations for this.
So it seems like we might at least have two choices here:

Add a dedicated CONFIG_X86_ENABLE_DIRECT_IRQ for enabling this and without using FPU to ensure system security. Although it might have some problems or potential security risks.
Do not use direct isr for x86. I was thinking if this is the option, from QA's perspective, we might need to remove the existing code of this, otherwise, we cannot achieve the goal of the code coverage.

And hope for some input about x86 from @dcpleung , thanks!

No one uses direct interrupt on x86, AFAIK.

authors: LeiW000 andyross dcpleung enjiamai


text:
mgmt/mcumgr/lib: Fix multi-image upload not working

The commit fixes the issue where duplicated code in
img_mgmt_impl_upload_inspect caused redirecting all image uploads,
in multi-image configuration, to the first image.
Signed-off-by: Dominik Ermel dominik.ermel@nordicsemi.no

Why isn't this issue upstream? https://github.com/apache/mynewt-mcumgr/blob/master/cmd/img_mgmt/port/zephyr/src/zephyr_img_mgmt.c

Because the issue has been introduced by me while moving the code and applying the compliance fixes.


text:
samples: sensor: grove_temperature: Remove sample

All this sample does is read SENSOR_CHAN_AMBIENT_TEMP which the
sensor shell does as well.  Additionally the CONFIG_GROVE_LCD_RGB
related code has been broken for some time.
Signed-off-by: Kumar Gala galak@kernel.org

Marked DNM for @MaureenHelm to take a look when she's back.


text:
tests: subsys: portability: get rid of dependencies of tests

Break the dependency of tests, and let them be independent with each other.
Signed-off-by: Zhao Shuai shuai1x.zhao@intel.com

This is leaking the event flags.

Ok, I have modified it. Please have a look again. Thanks. @stephanosio

No, this is what I meant (only pseudocode, not to be taken literally):
setup()
{
	// relocated from L76-77
	evt_id = osEventFlagsNew(&event_flags_attrs);
	zassert_true(evt_id != NULL, "Failed creating event flags");
}

teardown()
{
	// moved from L218-219
	zassert_true(osEventFlagsDelete(evt_id) == osOK,
		     "EventFlagsDelete failed");
}

I think it will be better to use before function because it can run before every single test in this suite, so it will make these tests independent. But if we use setup function, it will only run once per test suite, it can't get rid of dependencies of tests. And if we use teardown function, it will run at the end of all the tests in the suite, but in the last test, it is already use osEventFlagsDelete function to free the evt_id, so it don't need to free it again.

No, this is what I meant (only pseudocode, not to be taken literally):
setup()
{
	// relocated from L76-77
	evt_id = osEventFlagsNew(&event_flags_attrs);
	zassert_true(evt_id != NULL, "Failed creating event flags");
}

teardown()
{
	// moved from L218-219
	zassert_true(osEventFlagsDelete(evt_id) == osOK,
		     "EventFlagsDelete failed");
}

I think it will be better to use before function because it can run before every single test in this suite, so it will make these tests independent. But if we use setup function, it will only run once per test suite, it can't get rid of dependencies of tests. And if we use teardown function, it will run at the end of all the tests in the suite, but in the last test, it is already use osEventFlagsDelete function to free the evt_id, so it don't need to free it again.

And I also add zassert in the before function to judge whether creating event flags succeed.

But if we use setup function, it will only run once per test suite, it can't get rid of dependencies of tests.

why?

No, this is what I meant (only pseudocode, not to be taken literally):
setup()
{
	// relocated from L76-77
	evt_id = osEventFlagsNew(&event_flags_attrs);
	zassert_true(evt_id != NULL, "Failed creating event flags");
}

teardown()
{
	// moved from L218-219
	zassert_true(osEventFlagsDelete(evt_id) == osOK,
		     "EventFlagsDelete failed");
}

I think it will be better to use before function because it can run before every single test in this suite, so it will make these tests independent. But if we use setup function, it will only run once per test suite, it can't get rid of dependencies of tests. And if we use teardown function, it will run at the end of all the tests in the suite, but in the last test, it is already use osEventFlagsDelete function to free the evt_id, so it don't need to free it again.

And I also add zassert in the before function to judge whether creating event flags succeed.

@stephanosio @enjiamai

But if we use setup function, it will only run once per test suite, it can't get rid of dependencies of tests.

why?

Firstly, these tests are in a test suite. And now we need to use osEventFlagsNew to create a event_flags for every test, because all these tests need to use event_flags. Otherwise, it must execute the first test firstly, then execute other tests.

Otherwise, it must execute the first test firstly, then execute other tests.

Have we ever supported running multiple tests in a suite in parallel?

Otherwise, it must execute the first test firstly, then execute other tests.

Have we ever supported running multiple tests in a suite in parallel?

No, it don't mean making these tests to run parallelly. We do this change, then just want it can also pass when these tests run out of order, such like add CONFIG_ZTEST_SHUFFLE. After that, these tests will be independent.


text:
ITE soc/riscv/ite: add intc, twd node for chip it82xx2

Chip it82xx2 intc and twd register are remapped, so I add both new node.
Signed-off-by: Ruibin Chang Ruibin.Chang@ite.com.tw

We will open another PR that includes it82xx2 drivers and board changes, so I close this PR.


text:
STM32F4 ADC DMA support

This PR adds the support of the DMA for the STM32F4 ADC (valid also for STM32F2, F7 and L1).
Also adds an ADC DMA test for Nucleo F401RE.
Fixes #67741

@anangl Please review.

authors: gautierg-st henrikbrixandersen


text:
Flash and nvs improvements

NVS is very slow when CONFIG_SPI_NOR_IDLE_IN_DPD is defined because every flash operation involves entering and exiting the FLASH part's deep power down mode. In addition to the SPI cmd involved, there is typically a non-trivial delay required after issuing the exit from DPD cmd. These delays of every FLASH SPI operation can dramatically slow down NVS (in my tests, mounting a small NVS of 256 sectors too over an order of magnitude longer when DPD was enabled).
The main CL in this pull request introduces a new FLASH driver API that involves two new functions called acquire and release. These are implemented for the spi nor driver to call it's already existing acquire and release functions that do the DPD management, with some modification to reference count the acquires/release calls because they can now be nested.
NVS uses the new APIs if they exist, allowing multiple FLASH operations to be called while the FLASH part is acquired and kept out of DPD, avoiding the extra delay involved in each FLASH operation, but still putting the FLASH part to deep power down once we're idle.
The second CL is a smaller one that improves a comparison function, making it faster and reducing it's stack usage.

Okay, I've split into actually three PRs (third is the removal of the unneeded enter_dpd() call at end of spi_nor_configure() in spi_nor.c).
Using runtime pm is cleaner, but a little awkward in that anyone previously using CONFIG_SPI_NOR_IDLE_IN_DPD to save power will actually want to disable that now in favor of using runtime pm, and make sure to enable it in their device tree.

Split to two PRs, the changes are unrelated. I do not think there is a need for callbacks nor internal counter, PM already handle that. There are pm_device_runtime_get and pm_device_runtime_put functions use usage counter provided by the PM. What we probably lack here is the PM callback processing.

I  make the requested change. Please review again.

Please have the stale label removed.

@mjchen0 my knowledge on the PM subsystem is insufficient to confirm that the correct method is used (from the intro in PM I would think using pm_device_busy_set() and pm_device_busy_clear(), but I am not sure).
@JordanYates, @ceolin you are better placed to provide feedback.

I believe myself and @ceolin have come to an agreement that the SPI NOR driver should be automatically performing the PM operations in flash_read/write/erase/etc, closing with a device_runtime_pm_put_async(dev, some_delay).
The async put would mean multiple requests closely grouped in time would not result in multiple PM transitions. This would resolve not only the issue here, but a collection of other flash users.
I just haven't had a board using the spi_nor driver since I left my previous job, so I hadn't gotten around to actually making the changes.

Could you take a look at #73246 and see if it resolves your issue?

@mjchen0 have you had the time to check #73246 to see if this resolves the issue. If it does please close the PR.

@mjchen0 a gentle nudge...

@mjchen0 have you had the time to check #73246 to see if this resolves the issue. If it does please close the PR.

I just took a look and yes, I think it should resolve the issue as well, though there are differences. In my PR, if NVS is the only user of the spi_nor FLASH, the FLASH it is put to sleep as soon as possible after NVS is done. There is no additional latency for the async wait timeout and there is no extra code execution for scheduling and cancelling the work when a burst of FLASH activity occurs, etc. So I think my PR is complementary and has advantages.

I understand that the PR has advantages but I think it is too pm specific to integrate into NVS. What do you think about adding a routine to nvs: int nvs_long_operation_cb(struct nvs_fs *fs, bool enable) that would be called with enable=true at start end enable=false at the end?

I just took a look and yes, I think it should resolve the issue as well, though there are differences. In my PR, if NVS is the only user of the spi_nor FLASH, the FLASH it is put to sleep as soon as possible after NVS is done. There is no additional latency for the async wait timeout and there is no extra code execution for scheduling and cancelling the work when a burst of FLASH activity occurs, etc. So I think my PR is complementary and has advantages.

I agree that this PR is more optimized for this particular use case (reading or writing from one NVS key), however I am not convinced that the performance improvement is significant. If NVS is the only user of the flash, then the delay can be set to 1ms and achieve the same functionality as this PR with minimal overhead (1ms of idle vs DPD on the flash, 1 additional SoC wakeup).
I am curious how often you are reading/writing to the NVS, that these few milliseconds are a problem.

@mjchen0 I propose to close this PR. When #73246 is merged it would not be needed to integrate PM into nvs.

authors: JordanYates Laczen mjchen0


text:
tests: document skipping tests

Add documentation about skipping tests and listing sub testcases (cases
within test projects).
Signed-off-by: Anas Nashif anas.nashif@intel.com

Codecov Report

Merging #7289 into master will increase coverage by <.01%.
The diff coverage is n/a.

@@            Coverage Diff            @@
##           master   #7289      +/-   ##
=========================================
+ Coverage      55%     55%   +<.01%
=========================================
  Files         474     474
  Lines       51717   51717
  Branches     9934    9934
=========================================
+ Hits        28446   28447       +1
+ Misses      19309   19308       -1
  Partials     3962    3962

Impacted Files
Coverage Δ

lib/posix/pthread.c
69.84% <0%> (+0.5%)
:arrow_up:

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 0ec79d6...4a7629e. Read the comment docs.

@dbkinder  fixed

achtung_regex

for starters, we need to change this variable name.
I do not think we should be adding links, if it is documented, that should be enough. Otherwise we will have to add links to every other error or warning.

authors: codecov-io nashif


text:
esp32c3: improve memory utilization

Change the layout of MCUboot segments to increase the memory available in the user application.
This will reduce the difference of available memory between the simple boot and MCUboot app builds.

Fixing https://github.com/zephyrproject-rtos/zephyr/issues/73400

It requires https://github.com/zephyrproject-rtos/zephyr/pull/73816


text:
Feature/frdm mcxn947 lvgl

Enable lvgl for frdm-mcxn947

hello @danieldegrasse , the code is updated following the comments, please help review, thanks.

Please address the compliance issue


text:
usb: device_next: hid: move few pointer to a config struct

Some of the fields currently in hid_device_data are constant.
Move them to a const config struct to save some RAM and drop the rest of the data static initializers to runtime to save some flash as well.

merge conflict, rebased


text:
Renew DHCPv4 address if network connectivity is restored

Fixes #7553

Codecov Report

Merging #8027 into master will decrease coverage by 0.01%.
The diff coverage is 11.76%.

@@            Coverage Diff             @@
##           master    #8027      +/-   ##
==========================================
- Coverage   55.03%   55.02%   -0.02%
==========================================
  Files         481      481
  Lines       53936    53950      +14
  Branches    10474    10479       +5
==========================================
+ Hits        29686    29687       +1
- Misses      19981    19993      +12
- Partials     4269     4270       +1

Impacted Files
Coverage Δ

include/net/net_if.h
63.73% <ø> (ø)
:arrow_up:

subsys/net/ip/net_private.h
40% <ø> (ø)
:arrow_up:

subsys/net/ip/dhcpv4.c
6.03% <11.76%> (+0.3%)
:arrow_up:

boards/posix/native_posix/timer_model.c
98.21% <0%> (-1.79%)
:arrow_down:

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update d93ecda...dbca46c. Read the comment docs.

ok I know why I don't get on/off: raising an event from an event callback is a no go. Well, if you apply the changes I requested about etherent carrier stuff, it will be "solved". But I'll still fix the net_mgmt so it should be possible to raise an event from an event callback

Current solution needs also support from #8112 and #8113
Lets see if we can avoid some of the net-mgmt changes.

Fixed version according to comments. Also added #8112 as commits in that PR are needed for this PR to work properly. This has been tested with frdm-k64f device.

Also IMHO this should not be stuffed into 1.12 (it should have been released on May 31th, no?).

Also IMHO this should not be stuffed into 1.12 (it should have been released on May 31th, no?)

This is PR is fixing issue #7553 which is marked as medium bug to 1.12 thus that is why I have been working on this lately.

This is PR is fixing issue #7553 which is marked as medium bug to 1.12 thus that is why I have been working on this lately.

I just noticed that the 1.12 target was removed from the original bug thus I will modify the target in this PR too.

I just noticed that the 1.12 target was removed from the original bug thus I will modify the target in this PR too.

bugs usually do not have a target by default, bugs apply to the coming release unless we set something to the following release, so this is still valid for 1.12.

Updated the PR so that ethernet driver uses work queue instead of generating the carrier on/off event itself.

Rebased against master.

Changed the dhcpv4 handling and removed unnecessary checks.

Hope also @therealprof can confirm and ack that this PR in its current state works for him. (I don't have an advanced enough DHCP setup to test it myself for example.)

@therealprof

Can't test this since the STM32 driver does not generate the required events.

D'oh, sorry!

I've seen one implementation where they essentially periodically polled the PHY for the current link status but meh...

That's how frdm_k64f, as used in this PR, is implemented, so don't be too shy about it - nice features sometimes require some workarounds/overhead ;-).

Updated according to comments.

authors: codecov-io jukkar nashif pfalcon tbursztyka


text:
Fix headers guards

Identifiers starting with an underscore followed by either uppercase letter or other underscore are reserved and should not be used according with C99.
This pr address this problem on headers guards only. #9882

@pfalcon fair enough. Can I prefix every header guard with "HEADER_GUARD" ? or "HEADER" ?
@jhedberg are you ok doing it to bluetooth as well ?

@pfalcon fair enough. Can I prefix every header guard with "HEADER_GUARD" ? or "HEADER" ?

Well, you're trying to make Zephyr compliant and well-behaving. Just imagine if some other / all projects would prefix their header guards with something simple and obvious, like "HEADER_GUARD" - they all would be clashing/non-compliant. IMHO, if doing another pass on that at all, then do it right, and that means doing project-specific namespacing. YMMV

@ceolin follow this guide for example:
https://google.github.io/styleguide/cppguide.html#The__define_Guard
I would not go all the way and add the path, but ZEPHYR_ADC_H should do it.
I would start a document (or use an existing one) to document those and make it part of the Zephyr style and naming conventions.

@ceolin IMO having _H in the define already spells sufficiently "header". I'm fine with the current solution, or if you want to add a __ suffix I'm not opposed to that either.

@nashif :
The doc you link to clearly has a trailing underscore.

I would not go all the way and add the path, but ZEPHYR_ADC_H should do it.

ZEPHYR_ADC_H means "something high (e.g. high part) of ADC value in Zephyr project (where ZEPHYR is mandatory namespacing prefix for all API symbols). Again, perfect name for a public symbol, not header guard.

The doc you link to clearly has a trailing underscore.

yes, I forgot the trailing underscore, ZEPHYR_ADC_H_ is fine, but I can also live with ADC_H_, no preferences really. The only issue with ZEPHYR_ADC_H_, it is long.

A trailing underscore should be enough to mess with our API. Putting the whole namespace will make some guards really big, I changed the guards within kernel/* because are few of them and are my main focus now and tried to keep the others (fixing what made them not compliant).
So, can we proceed with these changes adding only a trailing underscore ?

The only issue with ZEPHYR_ADC_H_, it is long.

Long is good. The longer, the less probability of clash, pure mathematical statistics.

@pfalcon I've no problem with long names for header guards, this is basically one time thing. We just need to get a conclusion on this. Prefix everything with ZEPHYR and add a trailing underscore resolve our problem, or we can be more strict and use the whole file's path. The latter is a little bit to much IMHO.

@ceolin : I'm only a developer, so can only give suggestions. You can combine votes from different developers, requests from project leaders, and your own opinion to get to the result.
If the choices are:

ZEPHYR_ + filename + H_
ZEPHYR_ + pathname + H_

My vote is for p.2, as it's more formal and more unambiguous. If for some reason choice 2 doesn't include "ZEPHYR_", I vote for that choice which does include prefix ;-). Indeed, header guards are write-once, so optimizing them for length doesn't make much sense, instead optimizing for formal uniqueness does, IMHO.

i vote for
ZEPHYR_ + filename + H_

I second for option 2, we have files with same name on project.

p/zephyr » find -name "util.h"
./drivers/bluetooth/util.h
./include/misc/util.h
./subsys/bluetooth/controller/util/util.h

#WeAreTheSystem

@ceolin I am fine with the above.

@andyross As fair as I understood this is reserved for the compiler and not for the system.
@nashif are you fine with the path in the guards ? or is something else ?

@nashif are you fine with the path in the guards ? or is something else ?

path in the guard.
to @andyross point, this is a one time change and we will not bother with that again, what we need to do is however, any change needs to be added to some guide to developers so we can point them to it if wrong style is being added to new changes, can you start with such guide?

@nashif ack !

How about simply using #pragma once? While it is not in the C standard it does not violate it and every relevant compiler supports it officially.

I rather prefer using #pragma too, the problem is that to be MISRA C compliant we have to follow the C standard, and to be honest there are other advantages of doing it too.

MISRA C2012 does allow the usage of extensions (#pragma once in this case) as long as the implementation-defined behavior is documented and understood.

@rettichschnidi there is one advisory guideline that says to not use language extensions. You're right, you still can use if the behaviour is defined and you document it. But to me, is just easier change these guards to be compliant than need to document it for each supported compiler.
I know that we inevitable will need to do it for some guidelines, but we should avoid this for this simple fixes.

@aescolar can you check it again please ?

@aescolar can you check it again please ?

It seems fine, yes. Thanks

authors: aescolar ceolin jhedberg nashif pfalcon rettichschnidi


text:
Remove automatic panel popup when entering the KSC

fixes #42
Probably not the best fix, but its simple enough and works for my personal use.

Sorry for bugging a nearly year-old post, but could you provide instructions on how we could use your fix? The only change from your fork that's displayed is related to the source code, and I'm not sure how one builds a KSP mod.

Sorry for bugging a nearly year-old post, but could you provide instructions on how we could use your fix? The only change from your fork that's displayed is related to the source code, and I'm not sure how one builds a KSP mod.

No worries at all! Its been a few months since i've looked at this - but heres a zip of my local copy of this mod. I believe it should contain the fix in question: https://github.com/rettoph/AdjustableModPanel/releases/tag/43
Let me know if you have any questions or issues!

authors: SimplyTadpole rettoph


text:
[BUG][FEATURE] if log file missing will throw EXC

[ ] rename log file to excd.log (or another .suffix)
[ ] relocate log file to <KSP_ROOT>\Logs\ExceptionDetector\
[ ] if log file not found, create blank one
[ ] if settings file not found, create default

@lisias, help on this would be greatly appreciated since you know how to stick the logs there.
[LOG 22:36:02.004] [AddonLoader]: Instantiating addon 'ExceptionDetector' from assembly 'ExceptionDetector'
[EXC 22:36:02.011] DirectoryNotFoundException: Could not find a part of the path "X:\KSPDEV\GameData\godarklight\ExceptionDetector\Plugins\Log\ed.log".
	System.IO.FileStream..ctor (System.String path, System.IO.FileMode mode, System.IO.FileAccess access, System.IO.FileShare share, System.Int32 bufferSize, System.Boolean anonymous, System.IO.FileOptions options) (at <9577ac7a62ef43179789031239ba8798>:0)
	System.IO.FileStream..ctor (System.String path, System.IO.FileMode mode, System.IO.FileAccess access, System.IO.FileShare share, System.Int32 bufferSize, System.Boolean isAsync, System.Boolean anonymous) (at <9577ac7a62ef43179789031239ba8798>:0)
	System.IO.FileStream..ctor (System.String path, System.IO.FileMode mode, System.IO.FileAccess access) (at <9577ac7a62ef43179789031239ba8798>:0)
	(wrapper remoting-invoke-with-check) System.IO.FileStream..ctor(string,System.IO.FileMode,System.IO.FileAccess)
	ExceptionDetector.ExceptionDetector.InitLog () (at <29f588e644614682a2bd5ea2b875251f>:0)
	ExceptionDetector.ExceptionDetector.Awake () (at <29f588e644614682a2bd5ea2b875251f>:0)
	UnityEngine.DebugLogHandler:LogException(Exception, Object)
	KSPe.Util.Log.UnityLogDecorator:UnityEngine.ILogHandler.LogException(Exception, Object)
	ModuleManager.UnityLogHandle.InterceptLogHandler:LogException(Exception, Object)

#31 #45 #43 #42 #41 #44


text:
add link references to contact.html; update contact-btn to link-btn; …

add link references to contact.html; update contact-btn to link-btn; delete duplicate home button
[FIX][UPDATE] bugs and reference issues in header in index.html. add links to header in contact.html #280
https://github.com/zero-to-mastery/Keiko-Corp/issues/280
Pull Request Template

Please provide all of the details below. Pull requests missing any of the information below will be closed!
Providing the issue number/url helps us identify the problem being solved and keep the issues tab clean and tidy

Summarise what this PR fixes
add link references to contact.html; update contact-btn to link-btn; delete duplicate home button
<Detail your PR changes/fixes>
What ISSUE NUMBER does this fix?
Fixes #<#280>
Checklist:
(Add an x between the brackets to check the items)

[x ] I have summarised what this PR fixes above
[x ] I have provided the issue ID/URL above
[x ] This PR fixes only the issue mentioned above (create separate PRs for separate issues)
[x ] I was the first one to claim the issue or I created the issue

Hey @Guitarhub786
Unfortunately this has a conflict I am unable to resolve on my end. Any chance you can take a look.
Feel free to reach out on Discord if you have any problems.
Regards
Matt

Fix sent in another pr, closing this one.

authors: Guitarhub786 MattCSmith brittneypostma

repo: zero-to-mastery/Keiko-Corp


text:
Fix/888 - Fixed Blog Page to Have Same Header/Sticky Header as Home Page

Pull Request Template

Please provide all of the details below. Pull requests missing any of the information below will be closed!
Providing the issue number/url helps us identify the problem being solved and keep the issues tab clean and tidy

What issue does this fix?.
Summarize what this PR fixes:-
Previously the blog page had a transparent sticky header. I took the header and sticky header from the home page and placed it in the blog page. It broke the styling of the blog page so I had to also fix that.
What ISSUE NUMBER does this fix?
Fixes #888
Checklist
(Add an x between the brackets to check the items)

[x] I have summarize what this PR fixes above
[x] I have provided the issue ID/URL above
[x] I have not added Bootstrap or jQuery and used correct styling guide.
[x] This PR fixes only the issue mentioned above (create separate PRs for separate issues)
[x] I was the first one to claim the issue or I created the issue - I created the issue

These look like good changes. Unfortunately, someone else was working on the blog page as well and made a pr before you that added images. This caused conflicts with your pr. I suggest running the git pull upstream master command and trying to repair the conflict with the images intact.

authors: brittneypostma sdangoy


text:
Non-Transferrable NFT Badges for Gigs

Non-Transferrable NFT Badges for Gigs
Description:
This project involves creating two types of non-transferrable NFT badges:

Client Badge: Awarded to a client upon requesting a gig on the platform.
Creator Badge: Awarded to a creator upon completing a gig on the platform.

Purpose:

These badges serve as a record of participation and reputation within the platform's ecosystem.
They can incentivize users to engage with the platform by offering benefits or recognition for their activity.

Technical Considerations:

The badges will be non-transferrable, meaning they cannot be sold or traded to other users.
The platform will need to implement a system for issuing and tracking the badges.
The badges could be integrated with the platform's user interface to display them on profiles or portfolios.

Success Criteria:

Successful implementation of non-transferrable NFT badges.
Increased user engagement on the platform.
Potential benefits or recognition for users holding badges are clearly defined.

Next Steps:

Define the specific benefits or recognition associated with each badge type.
Determine the design and visual elements of the badges.
Develop the technical infrastructure for issuing and tracking the badges.

Additional Notes:

Consider exploring the potential for integrating the badges with other blockchain-based applications or services.
Ensure compliance with any relevant regulations regarding NFTs.

Decentralized Creator Reputation

Decentralized Client Reputation

Veritas (RXP Logo name)

repo: zeroauthority-dao/mission