text:
Fix modern + granularChunk hydration failing

We were missing one edge case when merging chunks from the modern build. Since granularChunks was enabled to dynamic imports too, some of the dynamic chunks can have null as their name. Handling that case with this PR

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.8s
13.7s
-73ms

nodeModulesSize
46.9 MB
46.9 MB
⚠ +922 B

Client Bundles (main, webpack, commons)

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

main-HASH.js
18.5 kB
18.5 kB
✓

main-HASH.js gzip
6.49 kB
6.49 kB
✓

webpack-HASH.js
1.53 kB
1.53 kB
✓

webpack-HASH.js gzip
746 B
746 B
✓

4952ddcd88e7..1db6754d3.js
12 kB
12 kB
✓

4952ddcd88e7..54d3.js gzip
4.68 kB
4.68 kB
✓

commons.HASH.js
10.9 kB
10.9 kB
✓

commons.HASH.js gzip
4.06 kB
4.06 kB
✓

de003c3a9d30..4155a1d0b.js
38.3 kB
38.3 kB
✓

de003c3a9d30..1d0b.js gzip
13.9 kB
13.9 kB
✓

framework.HASH.js
126 kB
126 kB
✓

framework.HASH.js gzip
39.5 kB
39.5 kB
✓

Overall change
207 kB
207 kB
✓

Client Bundles (main, webpack, commons) Modern

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

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

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

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

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

4952ddcd88e7..b9.module.js
14.9 kB
14.9 kB
✓

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

de003c3a9d30..8b.module.js
33.1 kB
33.1 kB
✓

de003c3a9d30..dule.js gzip
12.5 kB
12.5 kB
✓

framework.HASH.module.js
126 kB
126 kB
✓

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

Overall change
190 kB
190 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.76 kB
4.76 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.94 kB
2.94 kB
✓

_app.js gzip
1.33 kB
1.33 kB
✓

_error.js
10.4 kB
10.4 kB
✓

_error.js gzip
4.07 kB
4.07 kB
✓

hooks.js
1.44 kB
1.44 kB
✓

hooks.js gzip
779 B
779 B
✓

index.js
318 B
318 B
✓

index.js gzip
222 B
222 B
✓

link.js
6.77 kB
6.77 kB
✓

link.js gzip
2.89 kB
2.89 kB
✓

routerDirect.js
411 B
411 B
✓

routerDirect.js gzip
283 B
283 B
✓

withRouter.js
421 B
421 B
✓

withRouter.js gzip
282 B
282 B
✓

Overall change
22.7 kB
22.7 kB
✓

Client Pages Modern

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

_app.module.js
1.54 kB
1.54 kB
✓

_app.module.js gzip
757 B
757 B
✓

_error.module.js
7.35 kB
7.35 kB
✓

_error.module.js gzip
3.06 kB
3.06 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.45 kB
5.45 kB
✓

link.module.js gzip
2.46 kB
2.46 kB
✓

routerDirect.module.js
383 B
383 B
✓

routerDirect..dule.js gzip
273 B
273 B
✓

withRouter.module.js
394 B
394 B
✓

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

Overall change
16 kB
16 kB
✓

Client Build Manifests

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

_buildManifest.js
81 B
81 B
✓

_buildManifest.js gzip
61 B
61 B
✓

_buildManifest.module.js
81 B
81 B
✓

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

Overall change
162 B
162 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.04 kB
1.04 kB
✓

link.html
4.11 kB
4.11 kB
✓

link.html gzip
1.04 kB
1.04 kB
✓

withRouter.html
4.12 kB
4.12 kB
✓

withRouter.html gzip
1.03 kB
1.03 kB
✓

Overall change
12.3 kB
12.3 kB
✓

Serverless Mode (Increase detected ⚠)

General Overall increase ⚠

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

buildDuration
13.9s
13.9s
-48ms

nodeModulesSize
46.9 MB
46.9 MB
⚠ +922 B

Client Bundles (main, webpack, commons)

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

main-HASH.js
18.5 kB
18.5 kB
✓

main-HASH.js gzip
6.49 kB
6.49 kB
✓

webpack-HASH.js
1.53 kB
1.53 kB
✓

webpack-HASH.js gzip
746 B
746 B
✓

4952ddcd88e7..1db6754d3.js
12 kB
12 kB
✓

4952ddcd88e7..54d3.js gzip
4.68 kB
4.68 kB
✓

commons.HASH.js
10.9 kB
10.9 kB
✓

commons.HASH.js gzip
4.06 kB
4.06 kB
✓

de003c3a9d30..4155a1d0b.js
38.3 kB
38.3 kB
✓

de003c3a9d30..1d0b.js gzip
13.9 kB
13.9 kB
✓

framework.HASH.js
126 kB
126 kB
✓

framework.HASH.js gzip
39.5 kB
39.5 kB
✓

Overall change
207 kB
207 kB
✓

Client Bundles (main, webpack, commons) Modern

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

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

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

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

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

4952ddcd88e7..b9.module.js
14.9 kB
14.9 kB
✓

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

de003c3a9d30..8b.module.js
33.1 kB
33.1 kB
✓

de003c3a9d30..dule.js gzip
12.5 kB
12.5 kB
✓

framework.HASH.module.js
126 kB
126 kB
✓

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

Overall change
190 kB
190 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.76 kB
4.76 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.94 kB
2.94 kB
✓

_app.js gzip
1.33 kB
1.33 kB
✓

_error.js
10.4 kB
10.4 kB
✓

_error.js gzip
4.07 kB
4.07 kB
✓

hooks.js
1.44 kB
1.44 kB
✓

hooks.js gzip
779 B
779 B
✓

index.js
318 B
318 B
✓

index.js gzip
222 B
222 B
✓

link.js
6.77 kB
6.77 kB
✓

link.js gzip
2.89 kB
2.89 kB
✓

routerDirect.js
411 B
411 B
✓

routerDirect.js gzip
283 B
283 B
✓

withRouter.js
421 B
421 B
✓

withRouter.js gzip
282 B
282 B
✓

Overall change
22.7 kB
22.7 kB
✓

Client Pages Modern

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

_app.module.js
1.54 kB
1.54 kB
✓

_app.module.js gzip
757 B
757 B
✓

_error.module.js
7.35 kB
7.35 kB
✓

_error.module.js gzip
3.06 kB
3.06 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.45 kB
5.45 kB
✓

link.module.js gzip
2.46 kB
2.46 kB
✓

routerDirect.module.js
383 B
383 B
✓

routerDirect..dule.js gzip
273 B
273 B
✓

withRouter.module.js
394 B
394 B
✓

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

Overall change
16 kB
16 kB
✓

Client Build Manifests

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

_buildManifest.js
81 B
81 B
✓

_buildManifest.js gzip
61 B
61 B
✓

_buildManifest.module.js
81 B
81 B
✓

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

Overall change
162 B
162 B
✓

Serverless bundles

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

_error.js
281 kB
281 kB
✓

_error.js gzip
74.8 kB
74.8 kB
✓

hooks.html
4.19 kB
4.19 kB
✓

hooks.html gzip
1.07 kB
1.07 kB
✓

index.js
281 kB
281 kB
✓

index.js gzip
75.1 kB
75.1 kB
✓

link.js
289 kB
289 kB
✓

link.js gzip
77.1 kB
77.1 kB
✓

routerDirect.js
282 kB
282 kB
✓

routerDirect.js gzip
75.1 kB
75.1 kB
✓

withRouter.js
282 kB
282 kB
✓

withRouter.js gzip
75.2 kB
75.2 kB
✓

Overall change
1.42 MB
1.42 MB
✓

Commit: a575d5ba9f861326ad10d7506c3c9e3a15113a4e

Stats from current PR

Default Server Mode (Increase detected ⚠)

General Overall increase ⚠

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

buildDuration
12.4s
12.7s
⚠ +227ms

nodeModulesSize
46.9 MB
46.9 MB
⚠ +5.71 kB

Client Bundles (main, webpack, commons)

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

main-HASH.js
18.5 kB
18.5 kB
✓

main-HASH.js gzip
6.5 kB
6.5 kB
✓

webpack-HASH.js
1.53 kB
1.53 kB
✓

webpack-HASH.js gzip
746 B
746 B
✓

4952ddcd88e7..1db6754d3.js
12 kB
12 kB
✓

4952ddcd88e7..54d3.js gzip
4.68 kB
4.68 kB
✓

commons.HASH.js
10.9 kB
10.9 kB
✓

commons.HASH.js gzip
4.06 kB
4.06 kB
✓

de003c3a9d30..7d55a2235.js
38.3 kB
38.3 kB
✓

de003c3a9d30..2235.js gzip
13.9 kB
13.9 kB
✓

framework.HASH.js
126 kB
126 kB
✓

framework.HASH.js gzip
39.5 kB
39.5 kB
✓

Overall change
207 kB
207 kB
✓

Client Bundles (main, webpack, commons) Modern

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

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

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

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

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

4952ddcd88e7..b9.module.js
14.9 kB
14.9 kB
✓

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

de003c3a9d30..a0.module.js
33.1 kB
33.1 kB
✓

de003c3a9d30..dule.js gzip
12.5 kB
12.5 kB
✓

framework.HASH.module.js
126 kB
126 kB
✓

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

Overall change
190 kB
190 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.76 kB
4.76 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.94 kB
2.94 kB
✓

_app.js gzip
1.33 kB
1.33 kB
✓

_error.js
10.4 kB
10.4 kB
✓

_error.js gzip
4.07 kB
4.07 kB
✓

hooks.js
1.44 kB
1.44 kB
✓

hooks.js gzip
779 B
779 B
✓

index.js
318 B
318 B
✓

index.js gzip
222 B
222 B
✓

link.js
6.77 kB
6.77 kB
✓

link.js gzip
2.89 kB
2.89 kB
✓

routerDirect.js
411 B
411 B
✓

routerDirect.js gzip
283 B
283 B
✓

withRouter.js
421 B
421 B
✓

withRouter.js gzip
282 B
282 B
✓

Overall change
22.7 kB
22.7 kB
✓

Client Pages Modern

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

_app.module.js
1.54 kB
1.54 kB
✓

_app.module.js gzip
757 B
757 B
✓

_error.module.js
7.35 kB
7.35 kB
✓

_error.module.js gzip
3.06 kB
3.06 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.45 kB
5.45 kB
✓

link.module.js gzip
2.46 kB
2.46 kB
✓

routerDirect.module.js
383 B
383 B
✓

routerDirect..dule.js gzip
273 B
273 B
✓

withRouter.module.js
394 B
394 B
✓

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

Overall change
16 kB
16 kB
✓

Client Build Manifests

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

_buildManifest.js
81 B
81 B
✓

_buildManifest.js gzip
61 B
61 B
✓

_buildManifest.module.js
81 B
81 B
✓

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

Overall change
162 B
162 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.04 kB
1.04 kB
✓

link.html
4.11 kB
4.11 kB
✓

link.html gzip
1.04 kB
1.04 kB
✓

withRouter.html
4.12 kB
4.12 kB
✓

withRouter.html gzip
1.03 kB
1.03 kB
✓

Overall change
12.3 kB
12.3 kB
✓

Serverless Mode (Increase detected ⚠)

General Overall increase ⚠

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

buildDuration
12.9s
12.9s
⚠ +10ms

nodeModulesSize
46.9 MB
46.9 MB
⚠ +5.71 kB

Client Bundles (main, webpack, commons)

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

main-HASH.js
18.5 kB
18.5 kB
✓

main-HASH.js gzip
6.5 kB
6.5 kB
✓

webpack-HASH.js
1.53 kB
1.53 kB
✓

webpack-HASH.js gzip
746 B
746 B
✓

4952ddcd88e7..1db6754d3.js
12 kB
12 kB
✓

4952ddcd88e7..54d3.js gzip
4.68 kB
4.68 kB
✓

commons.HASH.js
10.9 kB
10.9 kB
✓

commons.HASH.js gzip
4.06 kB
4.06 kB
✓

de003c3a9d30..7d55a2235.js
38.3 kB
38.3 kB
✓

de003c3a9d30..2235.js gzip
13.9 kB
13.9 kB
✓

framework.HASH.js
126 kB
126 kB
✓

framework.HASH.js gzip
39.5 kB
39.5 kB
✓

Overall change
207 kB
207 kB
✓

Client Bundles (main, webpack, commons) Modern

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

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

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

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

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

4952ddcd88e7..b9.module.js
14.9 kB
14.9 kB
✓

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

de003c3a9d30..a0.module.js
33.1 kB
33.1 kB
✓

de003c3a9d30..dule.js gzip
12.5 kB
12.5 kB
✓

framework.HASH.module.js
126 kB
126 kB
✓

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

Overall change
190 kB
190 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.76 kB
4.76 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.94 kB
2.94 kB
✓

_app.js gzip
1.33 kB
1.33 kB
✓

_error.js
10.4 kB
10.4 kB
✓

_error.js gzip
4.07 kB
4.07 kB
✓

hooks.js
1.44 kB
1.44 kB
✓

hooks.js gzip
779 B
779 B
✓

index.js
318 B
318 B
✓

index.js gzip
222 B
222 B
✓

link.js
6.77 kB
6.77 kB
✓

link.js gzip
2.89 kB
2.89 kB
✓

routerDirect.js
411 B
411 B
✓

routerDirect.js gzip
283 B
283 B
✓

withRouter.js
421 B
421 B
✓

withRouter.js gzip
282 B
282 B
✓

Overall change
22.7 kB
22.7 kB
✓

Client Pages Modern

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

_app.module.js
1.54 kB
1.54 kB
✓

_app.module.js gzip
757 B
757 B
✓

_error.module.js
7.35 kB
7.35 kB
✓

_error.module.js gzip
3.06 kB
3.06 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.45 kB
5.45 kB
✓

link.module.js gzip
2.46 kB
2.46 kB
✓

routerDirect.module.js
383 B
383 B
✓

routerDirect..dule.js gzip
273 B
273 B
✓

withRouter.module.js
394 B
394 B
✓

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

Overall change
16 kB
16 kB
✓

Client Build Manifests

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

_buildManifest.js
81 B
81 B
✓

_buildManifest.js gzip
61 B
61 B
✓

_buildManifest.module.js
81 B
81 B
✓

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

Overall change
162 B
162 B
✓

Serverless bundles

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

_error.js
281 kB
281 kB
✓

_error.js gzip
74.8 kB
74.8 kB
✓

hooks.html
4.19 kB
4.19 kB
✓

hooks.html gzip
1.07 kB
1.07 kB
✓

index.js
281 kB
281 kB
✓

index.js gzip
75.1 kB
75.1 kB
✓

link.js
289 kB
289 kB
✓

link.js gzip
77.1 kB
77.1 kB
✓

routerDirect.js
282 kB
282 kB
✓

routerDirect.js gzip
75.2 kB
75.2 kB
✓

withRouter.js
282 kB
282 kB
✓

withRouter.js gzip
75.3 kB
75.3 kB
✓

Overall change
1.42 MB
1.42 MB
✓

Commit: d9c593ed81d799a305a4c8e9e766f3af76471b4d

Hey @ijjk sorry I missed this. It's been really hard to reproduce this issue in a test case since this is a chunking based bug and we need a big app to trigger certain chunking conditions.

authors: ijjk janicklas-ralph


text:
Initial build should set requestPath to null

This is required for https://github.com/zeit/now-builders/pull/410 and sets the requestPath property that is passed to Builders to null for initial builds.

Codecov Report

Merging #2200 into canary will increase coverage by <.01%.
The diff coverage is 0%.

@@            Coverage Diff            @@
##           canary   #2200      +/-   ##
=========================================
+ Coverage    4.37%   4.37%   +<.01%
=========================================
  Files         245     245
  Lines        8874    8873       -1
  Branches      945     946       +1
=========================================
  Hits          388     388
+ Misses       8467    8466       -1
  Partials       19      19

Impacted Files
Coverage Δ

src/commands/dev/lib/types.ts
0% <ø> (ø)
:arrow_up:

src/commands/dev/lib/dev-builder.ts
0% <0%> (ø)
:arrow_up:

src/commands/dev/lib/dev-server.ts
0% <0%> (ø)
: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 994b017...ed1509b. Read the comment docs.

source: gharchive/pull-request

authors: codecov-io leo

repo: zeit/now-cli

license_type: permissive

license_source: github-api


text:
Add missing arg for generate_candidate_keywords()

Without fix, running python rake_tutorial.py fails

Thanks

You are welcome, thanks for the tutorial :+1:

authors: philonor zelandiya

repo: zelandiya/RAKE-tutorial

license: mit

license_source: bigquery


text:
Fabric 1.21 tool goes to crafting slot after breaking one block

On a 1.21 Realm, running Fabric
When a tool is switched to your hand, after you break one block, it'll go to your crafting slot
https://outplayed.tv/media/MwMyzg

I'm having a similar issue, and it sometimes randomly throws my sword into my crafting slot when trying to mine barehanded. I've attached a couple of examples for reference.
https://youtu.be/P90ZA8lc_bs
https://youtu.be/x6nZjf2Novc
AutoTools Fabric 1.21 v2.1
Fabric 0.100.7+1.21
Fabric Loader 0.16.0
Thank you for the mod!

this happens to me also when it automatically switches to my shovel (because i'm digging dirt) with slabs in my hand. after one block, it just jumps into my crafting slot for seemingly no reason

I'm having this issue as well, it only seems to happen when I have the "Keep selected slot" option turned on. I like it on because then the new tool doesn't take up an extra slot on the hotbar but if it's going to throw my tool into the crafting grid every time I mine then it isn't worth it.

I'm having this issue as well, it only seems to happen when I have the "Keep selected slot" option turned on. I like it on because then the new tool doesn't take up an extra slot on the hotbar but if it's going to throw my tool into the crafting grid every time I mine then it isn't worth it.

yeah, i just wish it was fixed lol

Hi, sorry for the late reply, but I finally got around to look at the problem. Turns out the fix was quite easy and it should be fixed in the next release of AutoTools

Hi, sorry for the late reply, but I finally got around to look at the problem. Turns out the fix was quite easy and it should be fixed in the next release of AutoTools

yay!!

This issue still perisits in fabric 1.21 since that version hasnt been updated yet. Is this update on the way?

This issue still perisits in fabric 1.21 since that version hasnt been updated yet. Is this update on the way?

you can just use the 1.21.1 version, it works for 1.21 since 1.21.1 is such a minor update.

source: gharchive/issue

repo: zelythia/AutoTools

license: MIT


text:
[Suggestions] Enable zfcampus/zf-development-mode like in ZendSkeletonApp

Looking into  zf-development-mode configuration it only needs a distribution file with an array and is initially executed during composer create-project command along with this is to enable Whoops Error Handling.
For reference, kindly check my ZfExpressiveModularApp implementation
Here is the proposed development.config.php.dist  file content:
use Zend\Expressive\Container;

return [
    'debug' => true,
    'config_cache_enabled' => false,

    // Whoops error template handler
    'dependencies' => [
        'invokables'    => [
            'Zend\Expressive\Whoops'            => Whoops\Run::class,
            'Zend\Expressive\WhoopsPageHandler' => Whoops\Handler\PrettyPageHandler::class,
        ],
        'factories'     => [
            'Zend\Expressive\FinalHandler' => Container\WhoopsErrorHandlerFactory::class
        ]
    ],
    'whoops' => [
        'json_exceptions' => [
            'display'    => true,
            'show_trace' => true,
            'ajax_only'  => true,
        ]
    ]
];

The following configuration is allowing the default
It needs to update also the config.php file with the following:
} else {
    // Load configuration from autoload path
    foreach (Glob::glob('config/autoload/{{,*.}global,{,*.}local}.php', Glob::GLOB_BRACE) as $file) {
        $config = ArrayUtils::merge($config, include $file);
    }

    // Development mode enabled
    if (file_exists(__DIR__ . '/../config/development.config.php')) {
        $config = ArrayUtils::merge($config, require __DIR__ . '/../config/development.config.php');
    }

    // Cache config if enabled
    if (isset($config['config_cache_enabled']) && $config['config_cache_enabled'] === true) {
        file_put_contents($cachedConfigFile, '<?php return ' . var_export($config, true) . ';');
    }
}

Lastly, for the composer.json file:

"require-dev": {
        "zfcampus/zf-development-mode": "^3.0",
        "filp/whoops": "^2.0"
    },
    "scripts": {
        "development-disable": "zf-development-mode disable",
        "development-enable": "zf-development-mode enable",
        "development-status": "zf-development-mode status",
        "post-create-project-cmd": ["@development-enable"]
    }

Any thoughts?

I like the idea. If this would be implemented, the config/development.config.php file must be included in .gitignore so it won't end up on the production server. I see in your repo that you did that already but I'm still mentioning it here in case it's going to be added.
The reason I would be against this is that (as far as I can tell) the zf-development-mode command doesn't remove the possible cached configuration... yet. Also if this requires renaming src to module then again I would advise against this until there is a decision made on what structure to use (zendframework/zend-expressive#176).
I'm not sure how and if this would affect module support (#54).

@xtreamwayz no changes for the directory structure for now, if this will be added. The changes will be on the files mentioned above. So, it still complies the current skeleton app.
With regards to the modular approach, can be discussed in a different thread, it still uses the "mtymek/expressive-config-manager" package but I would suggest to create a separate repository for the core (common) expressive configuration (as Zend\Expressive\ConfigProvider) and add a specific framework-based configuration such as Zend components.
Sample config/modules.config.php
use Zend\Expressive\ConfigManager\ConfigManager;
/**
 * Use Fully Qualified Namespace to enable the expressive configuration
 */
$modules = [
    Zend\Expressive\ConfigProvider::class, // Minimal Components
    Zend\Component\ConfigProvider::class, // Zend Components
    App\ConfigProvider::class, //Application Settings or can be Album tutorial https://github.com/zendframework/zend-expressive/issues/176
];
return (new ConfigManager($modules))->getMergedConfig();

With this approach, we are eliminating the mis-configuration of the expressive skeleton and set this as a library (composer type)
composer.json file (assuming we loaded the zend-component-installer in the skeleton composer.json)
"require": {
        "php": "^7.0",
        "roave/security-advisories": "dev-master",
        "zendframework/zend-expressive": "^1.0",
        "zendframework/zend-expressive-helpers": "^2.0"
},
"autoload": {
        "psr-4": {
             "Zend\\Expressive\\": "src/"
        }
},
"extra": {
       "zf": {
            "config-provider": "Zend\\Expressive\\ConfigProvider"
        }
},
"autoload-dev": {
       "psr-4": {
            "ZendTest\\Expressive\\": "test/"
        }
}

The only file in the repo. (src/ConfigProvider.php)
namespace Zend\Expressive;
final class ConfigProvider
{
    public function __invoke()
    {
        return [
            "dependencies"          => $this->getServiceConfig(),
            "middleware_pipeline"   => $this->getMiddlewareConfig()
        ];
    }
    /**
     * Return dependencies mapping for this module.
     * We recommend using fully-qualified class names whenever possible as service names.
     *
     * @return array
     */
    public function getServiceConfig()
    {
        return [
            // Use 'invokables' for constructor-less services,
            // or services that do not require arguments to the constructor.
            //
            // Map a service name to the class name.
            // Fully\Qualified\InterfaceName::class => Fully\Qualified\ClassName::class,
            'invokables'    => [
                Helper\ServerUrlHelper::class => Helper\ServerUrlHelper::class,
            ],
            // Use 'factories' for services provided by callbacks/factory classes.
            'factories'     => [
                // Application
                Application::class      => Container\ApplicationFactory::class,
                Helper\UrlHelper::class => Helper\UrlHelperFactory::class,
                // Middlewares
                Helper\ServerUrlMiddleware::class => Helper\ServerUrlMiddlewareFactory::class,
                Helper\UrlHelperMiddleware::class => Helper\UrlHelperMiddlewareFactory::class,
            ]
        ];
    }
    /**
     * An array of middleware to register. Each item is of the following specification:
     *
     * <code>
     * [
     *  Required:
     *      'middleware' => 'Name or array of names of middleware services and/or callables',
     *  Optional:
     *      'path'     => '/path/to/match', // string; literal path prefix to match
     *                                      // middleware will not execute if path does not match!
     *      'error'    => true, // boolean; true for error middleware
     *      'priority' => 1, // int; higher values == register early;
     *                      // lower/negative == register last;
     *                      // default is 1, if none is provided.
     * ]
     * </code>
     *
     * While the ApplicationFactory ignores the keys associated with specifications, they can be used to allow merging
     * related values defined in multiple configuration files/locations.
     *
     * This defines some conventional keys for middleware to execute early, routing middleware, and error middleware.
     *
     * @return array
     */
    public function getMiddlewareConfig()
    {
        return [
            /**
             * Add more middleware here that you want to execute on every request:
             * - bootstrapping
             * - pre-conditions
             * - modifications to outgoing responses
             */
            'always' => [
                'middleware' => [
                    Helper\ServerUrlMiddleware::class,
                ],
                'priority' => 10000,
            ],
            /**
             * Add more middleware here that needs to introspect the routing results; this might include:
             * - route-based authentication
             * - route-based validation
             * - etc.
             */
            'routing' => [
                'middleware' => [
                    Container\ApplicationFactory::ROUTING_MIDDLEWARE,
                    Helper\UrlHelperMiddleware::class,
                    // Append here
                    Container\ApplicationFactory::DISPATCH_MIDDLEWARE,
                ],
                'priority' => 1,
            ],
            'error' => [
                'middleware' => [
                    //Add more error handler middleware
                ],
                'error'    => true,
                'priority' => -10000,
            ]
        ];
    }
}

See the initial implementation (without test) https://github.com/CodingMatters/zend-expressive-config-provider

@gabbydgab Thanx for the suggestion. This feature is included in #54.

authors: gabbydgab xtreamwayz

repo: zendframework/zend-expressive-skeleton


text:
ReflectionException at serve

I've follow instuctions at README.md
when I run
composer serve
and oll other composer command
it throw this exceptions
[ReflectionException]
Class Fxp\Composer\AssetPlugin\Repository\NpmRepository does not exist

[ErrorException]
Declaration of Fxp\Composer\AssetPlugin\Repository\AbstractAssetsRepository::whatProvides() should be compatible with Composer\Repository\ComposerRepository::whatProvides(Composer\DependencyResolver\Pool $pool, $name, $bypassFilters = false)

Looks like you have bad composer plugins installed. Please try using a fresh install of composer; if you continue to have issues, please report against composer.

authors: fabiopellati weierophinney


text:
New coding standard

Usage of the newly introduced zendframework/zend-coding-standard for CS checks.

Please note that build failures are due to phpunit update in latest service manager

@Koopzington thanks

authors: Koopzington Xerkus

repo: zendframework/zend-validator


text:
Bookのプレビュー表示でサマリー項目がZenn-cliと異なる表示になる

Book のプレビュー画面において summary の項目が改行、空白行等がある場合に zenn-cli との表示が異なる現象を見つけました。symmary の文字列を以下のようなパターンにすると zenn-cli では改行が反映されるのに対して、vscode-extension では反映されません。
# パターン(1)
summary:
  ○○○○○

  ○○○○○

  ○○○○○

# パターン(2)
summary: |
  ○○○○○

  ○○○○○

  ○○○○○

特にダブルクォーテーション("")で囲んでいる場合にはエラーとなり、タイトル等が表示されなくなります。
# パターン(3)
summary: "
○○○○○
\n\n
○○○○○
\n\n
○○○○○
"

これは zenn-cli の方では起こらず、Web 上でも正確に表示されています。サマリーでは複数行で改行したい場合もあるので、このようなフォーマットも正しく表示されるのが望ましいと思いました。
そこで実際に zenn-cli との違いを調査してみたところ、二点の問題がありました。

zenn-cli で利用されている YAML パーサーは js-yaml の load() メソッドで extension の方で利用されている yaml パッケージの parse() だと上のようなパターンでエラーが吐き出される
BookPreview の scss ファイルのスタイルで改行設定がないためエラーを回避しても改行されない

yaml で利用できる parse() メソッドの第二引数のオプション等調べてみましたが、エラーが吐き出されないようにする方法が見つからなかったため、とりあえず js-yaml の load() の方に置換した上でスタイルを調整することでうまく表示されるようになりました。PR を作成してみたので検討してみてください。何か改善点などあれば教えていただけると助かります。

@yo-goto
PR ありがとうございました！マージさせて頂きました。
リリースついては来週を予定しています。
それまではリリース済みの拡張をご利用下さい。
よろしくお願いします。

マージありがとうございます！
楽しみにしています👍

@yo-goto
先ほど v0.0.9 をリリースしましたので、最新バージョンで修正内容をご利用いただけます。
リリース内容については以下の PR からご確認ください。
https://github.com/zenn-dev/zenn-vscode-extension/pull/56
よろしくお願いします。

authors: uttk-dev yo-goto

repo: zenn-dev/zenn-vscode-extension


text:
Image thumbnails in file manager too small

The image thumbnails in the file manager are too small. Additionally, they should not be round as it makes the image even less visible.

@TheMaaarc @rolandschaub zusammen eine passende grösse finden.

authors: nadar rolandschaub

repo: zephir/luya


text:
tests/net/socket/udp fails when code coverage is enabled on qemu_x86

This references #17323
This test fails when code coverage is enabled on qemu_x86 with a "CPU Page Fault" (see below)
SeaBIOS (version rel-1.12.1-0-ga5cab58e9a3f-prebuilt.qemu.org)
Booting from ROM..***** Booting Zephyr OS build v2.0.0-rc1-9-ga8b208aff77f *****
Running test suite socket_udp
===================================================================
starting test - test_send_recv_2_sock
PASS - test_send_recv_2_sock
===================================================================
starting test - test_v4_sendto_recvfrom
PASS - test_v4_sendto_recvfrom
===================================================================
starting test - test_v6_sendto_recvfrom
PASS - test_v6_sendto_recvfrom
===================================================================
starting test - test_v4_bind_sendto
PASS - test_v4_bind_sendto
===================================================================
starting test - test_v6_bind_sendto
PASS - test_v6_bind_sendto
===================================================================
starting test - test_so_priority
PASS - test_so_priority
===================================================================
starting test - test_so_txtime
PASS - test_so_txtime
===================================================================
starting test - test_v4_sendmsg_recvfrom
PASS - test_v4_sendmsg_recvfrom
===================================================================
starting test - test_v6_sendmsg_recvfrom
PASS - test_v6_sendmsg_recvfrom
===================================================================
starting test - test_v4_sendmsg_recvfrom_connected
PASS - test_v4_sendmsg_recvfrom_connected
===================================================================
starting test - test_v6_sendmsg_recvfrom_connected
PASS - test_v6_sendmsg_recvfrom_connected
===================================================================
starting test - setup_eth
PASS - setup_eth
===================================================================
starting test - test_v6_sendmsg_with_txtime
FATAL: ***** CPU Page Fault (error code 0x00000000)
FATAL: Supervisor thread read address 0xff112233
FATAL: PDE: 0x00 Non-present, Read-only, Supervisor, Execute Enabled
FATAL: PTE: 0x00 Non-present, Read-only, Supervisor, Execute Enabled
FATAL: eax: 0x00570930, ebx: 0x0000d204, ecx: 0x00000004, edx: 0x00000000
FATAL: esi: 0xff112233, edi: 0x00570930, ebp: 0x00552c24, esp: 0x00552c18
FATAL: eflags: 0x00000202 cs: 0x0008 cr3: 0x0052d3e0
FATAL: call trace:
FATAL: eip: 0x00100390
FATAL:      0x0013b18b (0x570930)
FATAL:      0x0013b61c (0x5725cc)
FATAL:      0x0012a9ba (0x5725cc)
FATAL:      0x0012acdc (0x5725cc)
FATAL:      0x0012ba39 (0x52d480)
FATAL:      0x0012bde7 (0x52d480)
FATAL:      0x00112c35 (0x52d480)
FATAL:      0x00116a9c (0x52d480)
FATAL: >>> ZEPHYR FATAL ERROR 0: CPU exception
FATAL: Current thread: 0x0052e020 (unknown)
FATAL: Halting system

This can be reproduced by running:
./scripts/sanitycheck --coverage -p qemu_x86 -T tests/net/
$ ./scripts/sanitycheck --coverage -p qemu_x86 -T tests/net/
JOBS: 4
Cleaning output directory /home/camelot/zephyrproject/zephyr/sanity-out
Building testcase defconfigs...
Filtering test cases...
52 tests selected, 21815 tests discarded due to filters
total complete:   43/  52  82%  failed:    0

qemu_x86                  tests/net/socket/udp/net.socket.udp                FAILED: handler_crash
	see: sanity-out/qemu_x86/tests/net/socket/udp/net.socket.udp/handler.log

total complete:   52/  52  100%  failed:    1
Generating coverage files...
HTML report generated: /home/camelot/zephyrproject/zephyr/sanity-out/coverage/index.html
51 of 52 tests passed with 0 warnings in 570 seconds

After running with gdb, it seems that the test fails on the function call in line 721 of tests/net/socket/udp/src/main.c

Interesting that this doesn't fail when --coverage is not used.
Does this fail at all with mps2_an385?

Interesting that this doesn't fail when --coverage is not used.
Does this fail at all with mps2_an385?

It does, in fact, fail with mps2_an385 when --coverage is used
***** Booting Zephyr OS build v2.0.0-rc1-9-ga8b208aff77f *****
Running test suite socket_udp
===================================================================
starting test - test_send_recv_2_sock
PASS - test_send_recv_2_sock
===================================================================
starting test - test_v4_sendto_recvfrom
PASS - test_v4_sendto_recvfrom
===================================================================
starting test - test_v6_sendto_recvfrom
PASS - test_v6_sendto_recvfrom
===================================================================
starting test - test_v4_bind_sendto
PASS - test_v4_bind_sendto
===================================================================
starting test - test_v6_bind_sendto
PASS - test_v6_bind_sendto
===================================================================
starting test - test_so_priority
PASS - test_so_priority
===================================================================
starting test - test_so_txtime
PASS - test_so_txtime
===================================================================
starting test - test_v4_sendmsg_recvfrom
PASS - test_v4_sendmsg_recvfrom
===================================================================
starting test - test_v6_sendmsg_recvfrom
PASS - test_v6_sendmsg_recvfrom
===================================================================
starting test - test_v4_sendmsg_recvfrom_connected
PASS - test_v4_sendmsg_recvfrom_connected
===================================================================
starting test - test_v6_sendmsg_recvfrom_connected
PASS - test_v6_sendmsg_recvfrom_connected
===================================================================
starting test - setup_eth
PASS - setup_eth
===================================================================
starting test - test_v6_sendmsg_with_txtime
FATAL: ***** BUS FAULT *****
FATAL:   Precise data bus error
FATAL:   BFAR Address: 0xff112233
FATAL: r0/a1:  0x2002f9b0  r1/a2:  0xff112233  r2/a3:  0xff112237
FATAL: r3/a4:  0x2002f9af r12/ip:  0x00000019 r14/lr:  0x00039331
FATAL:  xpsr:  0x81000000
FATAL: Faulting instruction address (r15/pc): 0x0000098e
FATAL: >>> ZEPHYR FATAL ERROR 0: CPU exception
FATAL: Current thread: 0x200255ac (unknown)
FATAL: Halting system

This also failed with native_posix which made it easy to figure out the culprit when running with valgrind.

authors: andrewboie camicarballo jukkar

repo: zephyrproject-rtos/zephyr


text:
Convert GPIO users to new GPIO API

List of users to convert:
Boards (DONE)

Module
Assignee
PR
Done

boards/arm/actinius_icarus
@anangl
#20798
✓

boards/arm/degu_evk
@anangl
#20798
✓

boards/arm/hexiwear_k64
@MaureenHelm
#21346
✓

boards/arm/mimxrt1020_evk
@MaureenHelm

N/A - uses hal driver directly

boards/arm/mimxrt1050_evk
@MaureenHelm

N/A - uses hal driver directly

boards/arm/mimxrt1060_evk
@MaureenHelm

N/A - uses hal driver directly

boards/arm/mimxrt1064_evk
@MaureenHelm

N/A - uses hal driver directly

boards/arm/nrf52840_pca10090
@anangl
#20184
✓

boards/arm/particle_*
@pabigot
#21249
✓

boards/arm/nrf52_pca20020
@pabigot

✓

boards/arm/nrf9160_pca10090
@anangl

✓

Drivers

Module
Assignee
PR
Done

drivers/audio/tlv320dac310x
@carlescufi
#22172
✓

drivers/bluetooth/hci
@erwango
#21062
✓

drivers/can
@karstenkoenig
#20944
✓

drivers/display/ssd1306
@jfischer-phytec-iot
#21687
✓

drivers/display/ssd16xx
@jfischer-phytec-iot
#21686
✓

drivers/display/st7789v
@jfischer-phytec-iot
#22146
✓

drivers/display/ili9340
@jfischer-phytec-iot
#22146
✓

drivers/display/mb_display.c
@carlescufi
#22157
✓

drivers/eeprom/eeprom_at2x
@pabigot
#22219
✓

drivers/ethernet/enc424j600-enc28j60
@jfischer-phytec-iot
#22130
✓

drivers/i2c/i2c_esp32
@ExtremeGTX
#20194
✓

drivers/ieee802154/ieee802154_cc1200
@tbursztyka, @pabigot
#22323
✓

drivers/ieee802154/ieee802154_cc2520
@tbursztyka, @pabigot
#22323
✓

drivers/ieee802154/ieee802154_mcr20a
@jfischer-phytec-iot
#22186
✓

drivers/ieee802154/ieee802154_rf2xx*.c
@mnkp
#22214
✓

drivers/led

✓

drivers/led_strip
@mbolivar
https://github.com/zephyrproject-rtos/zephyr/pull/20393
✓

drivers/lora
@pabigot
#22218
✓

drivers/modem
@carlescufi
#22168
✓

drivers/pwm/pwm_led_esp32
@ExtremeGTX
#19753
✓

drivers/spi/spi_context.h
@erwango
#21062
✓

drivers/wifi/eswifi
@erwango
#21066
✓

drivers/wifi/winc1500
@tbursztyka, @pabigot
#22324
✓

Samples

Module
Assignee
PR
Done

samples/basic/blinky

✓

samples/basic/button

✓

samples/basic/threads
@mnkp
#21116
✓

samples/bluetooth/hci_spi
@erwango
#22134
✓

samples/bluetooth/mesh
@mnkp
#22122
✓

samples/bluetooth/mesh_demo
@mnkp
#22122
✓

samples/boards/96b_argonkey/microphone
@avisconti
#21203
✓

samples/boards/96b_argonkey/sensors
@avisconti
#21203
✓

samples/boards/bbc_microbit/ line_follower_robot
@carlescufi
#22068
✓

samples/boards/bbc_microbit/pong
@carlescufi
#22068
✓

samples/boards/bbc_microbit/sound
@carlescufi
#22068
✓

samples/boards/nrf52/mesh/*
@carlescufi
#22129
✓

samples/boards/reel_board/mesh_badge
@carlescufi
#22137
✓

samples/boards/sensortile_box
@avisconti
#20941
✓

samples/boards/up_squared/gpio_counter
@dcpleung
#21503
✓

samples/drivers/CAN
@karstenkoenig
#20944
✓

samples/drivers/espi
@albertofloyd @franciscomunoz
~#22154~ #22298
✓

samples/drivers/gpio
@mnkp
#21117
✓ Removed

samples/drivers/lcd_hd44780
@carlescufi
#22098
✓

samples/drivers/led_apa102c_bitbang
@carlescufi
#22099
✓

samples/net/lwm2m_client
@carlescufi
#22092
✓

samples/net/nats
@nashif
Removed in master
✓removed

samples/net/wifi/src/wifi_test.c
@pabigot
#22324
✓

samples/sensor/fxos8700-hid
@jfischer-phytec-iot
#22139
✓

samples/subsys/usb/hid-cdc
@jfischer-phytec-iot
#22139
✓

samples/subsys/usb/hid-mouse
@anangl
#20237
✓

Other (DONE)

Module
Assignee
PR
Done

subsys/disk/disk_access_usdhc.c
@JunYangNXP
#21349
✓

subsys/disk/disk_access_spi_sdhc.c
@MaureenHelm
#21918
✓

subsys/usb/usb_device.c
@jfischer-phytec-iot
#22102
✓

tests/bluetooth/mesh
@carlescufi
#22162
✓

tests/boards/intel_s1000_crb
@dcpleung
#21471 #21983
✓

tests/drivers/gpio/gpio_basic_api
@pabigot @mnkp

✓

tests/drivers/pinmux/pinmux_basic_api
@mnkp
#21619
✓

Sensors (DONE)

Module
Assignee
PR
Done

drivers/sensor/adt7420
@pabigot
#21559
✓

drivers/sensor/adxl362
@pabigot
#21561
✓

drivers/sensor/adxl372
@pabigot
#21562
✓

drivers/sensor/amg88xx
@jfischer-phytec-iot
#21579
✓

drivers/sensor/apds9960
@jfischer-phytec-iot
#21267
✓ [ on reelboard ]

drivers/sensor/bma280
@pabigot
#22104
✓no hw

drivers/sensor/bmc150_magn
@pabigot
#22110
✓ no hw [EOL, not documented on BMI site]

drivers/sensor/bmg160
@pabigot
#22111
✓ no hw [EOL, not documented on BMI site]

drivers/sensor/bmi160
@pabigot
#21582
✓

drivers/sensor/ccs811
@pabigot
#22072
✓

drivers/sensor/dht
@pabigot
#21527
✓

drivers/sensor/fxas21002
@MaureenHelm
#21343
✓

drivers/sensor/fxos8700
@MaureenHelm
#21311
✓

drivers/sensor/hmc5883l
@microbuilder
#21718
✓

drivers/sensor/hts221
@pabigot
#19834
✓

drivers/sensor/iis3dhhc
@avisconti
#20941
✓

drivers/sensor/isl29035
@pabigot
#21523
✓

drivers/sensor/lis2dh
@pabigot
#22113
✓

drivers/sensor/lis2ds12
@avisconti
#22040
✓

drivers/sensor/lis2dw12
@avisconti
#20941
✓

drivers/sensor/lis2mdl
@avisconti
#21958
✓

drivers/sensor/lis3mdl
@avisconti
#21972
✓

drivers/sensor/lps22hh
@avisconti
#20941
✓

drivers/sensor/lsm6dsl
@pabigot
#19839
✓

drivers/sensor/lsm6dso
@avisconti
#20941
✓

drivers/sensor/lsm9ds0_gyro
@pabigot
#22114
✓

drivers/sensor/mcp9808
@pabigot
#21427
✓

drivers/sensor/mpu6050
@pabigot
#21566
✓

drivers/sensor/sht3xd
@pabigot
#20295
✓

drivers/sensor/stts751
@avisconti
#21828
✓

drivers/sensor/sx9500
@pabigot
#22115
✓

drivers/sensor/ti_hdc
@jfischer-phytec-iot
#21543
✓

drivers/sensor/tmp007
@pabigot
#22135
✓ [EOL, not documented on TI site]

drivers/sensor/vl53l0x
@erwango
#21063
✓ [on several boards]

@carlescufi
Is that mean I have to update said Apps (via submitting new PRs) with latest GPIO APIs ?

@carlescufi
Is that mean I have to update said Apps (via submitting new PRs) with latest GPIO APIs ?

Yes, please. Send a Pull Request against the topic-gpio branch, since that is the branch we are targeting, not master.

@carlescufi
https://github.com/zephyrproject-rtos/zephyr/pull/16648/commits/ff873b8a49b30cc7b20c91d7fee058d30d060d33 & we have to take reference from this link for modifications (for nrfx). right ?

@carlescufi
ff873b8 & we have to take reference from this link for modifications (for nrfx). right ?

That is modifying an actual GPIO driver, not a user of it. Take a look at the one of the PRs listed in the table in the main description of the issue to get a better feeling.

@vikrant8051 Specifically you should look at the commits with these subjects:

2c6af1f36d [Mon Jun 3 12:29:18 2019 +0200] samples: button: update to use new GPIO API
254e3324e1 [Tue Jan 29 00:33:10 2019 +0100] samples: blinky: update to use new GPIO API

since the only GPIO use in the samples you're responsible for are toggling LEDs and responding to button presses.  The only significant change in API will be in button handling.
(Note: The SHA1s above will change when the topic-branch is updated, so look for the commit message if you can't find them.)

Some notes on converting GPIO users.  If this is useful it may be edited for clarifications/extensions.

If you capture devicetree GPIOS_PIN information in a configuration structure, you should now also capture devicetree GPIOS_FLAGS information so it can be passed to gpio_pin_configure along with any direction/pull/other flags.  Both devicetree values should fit in a u8_t.

Don't make people search out the datasheet to figure out what the active level for a signal should be.  Document in the device bindings the active level of each signal as produced/consumed by the device, and add a note that the flags value in the devicetree node should reflect any inversion performed between the device and the GPIO line.

Ensure that all devicetree nodes include GPIO_ACTIVE_HIGH or GPIO_ACTIVE_LOW as appropriate for the GPIO signal path.

sensors/drivers/hts221 (merged) provides a basic example of how to handle data-ready interrupts in the new infrastructure.  Several platforms don't support level triggers, so the best practice is to use edge triggers.  Some sensors produce level signals which require an operation (like reading the data) to clear the signal.
Be aware that on board reset a level ready signal may already be asserted and if so no observation reports will be triggered.  Thus it's important to check the signal state and trigger a handle operation if already signalled.

sensors/drivers/sht3xd (#20295) shows an example of configuring triggers.  It's mostly the same as for data-ready, but isn't enabled until the trigger is configured.  Be aware that just as with data-ready device reset may have left the signal asserted so handling it when enabling is required here too.

A working idiom to handle interrupts is exemplified in the converted driver for st,hts221:

Provide a setup_signal(dev, enable) function that invokes gpio_pin_interrupt_configure() with GPIO_INT_DISABLE or (usually) GPIO_INT_EDGE_TO_ACTIVE based on the value of the passed enable flag.
Provide a handle_signal(dev) function that invokes setup_signal() to disable the interrupt, then processes the interrupt (signals a semaphore, queues a work item)
Use gpio_pin_configure() and gpio_add_callback() for the signal initializing the trigger infrastructure.
On trigger changes first disable the interrupt with setup_signal(dev, false)
When enabling the trigger use setup_signal(dev, true) then read the signal and if it's asserted invoke handle_signal(dev).

Can someone please explain the reasoning to remove tests/boards/intel_s1000_crb? I need to include rationale in the commit for #21471 . Any thoughts, @dcpleung, @carlescufi?

All identified conversions have been complete.  Any more that are discovered will be addressed when topic-gpio merges to master, or in master.

authors: carlescufi jenmwms pabigot vikrant8051


text:
Failed to run the sample "Native Posix Ethernet"

Describe the bug
The sample "Native Posix Ethernet" failed to run after build
To Reproduce
Steps to reproduce the behavior:

west build -b native_posix samples/net/eth_native_posix
sudo --preserve-env=ZEPHYR_BASE make -Cbuild run
or
sudo --preserve-env make -Cbuild run

Expected behavior
It runs successfully
Impact
Screenshots or console output
...
make: Entering directory '/home/jason/zephyrproject/zephyr/build'
make: *** No rule to make target 'run'.  Stop.
make: Leaving directory '/home/jason/zephyrproject/zephyr/build'
...
Environment (please complete the following information):

OS:  Ubuntu 18.04 LTS
Toolchain Zephyr SDK
Commit SHA: a42617

Additional context

Expected behavior
It runs successfully

what is the issue?

1.west build -b native_posix samples/net/eth_native_posix
2.west build -t run/ ./build/zephyr/zephyr.exe
works for me.
Maybe this is an issue for the second step?

@jasonedn as @overheat said, you are not running the right commands. Please try those and let us know.

@Aaron and@Carles . It still failed at the second step as below:
$ west build -p auto -b native_posix samples/net/eth_native_posix
-- west build: generating a build system
...
-- Configuring done
-- Generating done
-- Build files have been written to: /home/jason/zephyrproject/zephyr/build
-- west build: building application
[1/138] Preparing syscall dependency handling
[138/138] Linking C executable zephyr/zephyr.elf
$ west build -t run/ ./build/zephyr/zephyr.exe
ERROR: source directory ./build/zephyr/zephyr.exe does not exist
FATAL ERROR: refusing to proceed without --force due to above error
Actually "zephyr.exe" exists there and it started properly with the
following:
$ ./build/zephyr/zephyr.exe
UART_0 connected to pseudotty: /dev/pts/1
WARNING: Using a test - not safe - entropy source
*** Booting Zephyr OS build zephyr-v2.2.0-1690-g394a4443004b  ***
It didn't worked as the instruction in the online documents, and they
should be updated.
On Mon, Apr 20, 2020 at 4:14 AM Carles Cufí notifications@github.com
wrote:

Closed #24500 https://github.com/zephyrproject-rtos/zephyr/issues/24500.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/zephyrproject-rtos/zephyr/issues/24500#event-3251269361,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAVS7S5YO6G7C3MMUHRR6B3RNQVAXANCNFSM4ML63PHQ
.

@jasonedn west build -t run and ./build/zephyr/zephyr.exe both  works.
After that you need to UART_0 connected to pseudotty: /dev/pts/1, like screen /dev/pts/1

authors: carlescufi jasonedn overheat


text:
CSIS: RSI: General problem with RSI in privacy 1.2

Statement
Once the RPA changes, the new RSI (Resolvable Set Identifier) shall be generated and AD/SD data shall be updated as well with the new RSI value. This shall be done to avoid the tracking device. There shall not be condition that result in advertising old RSI using new RPA.
Background
If controller-based privacy is used, the HCI_LE_Set_Resolvable_Private_Address_Timeout is used to set "the length of time the Controller uses a Resolvable Private Address before a new resolvable private address is generated and starts being used" (Core 5.3 | Vol 4, Part E, 7.8.45).
Core 5.3 | Vol 3, Part C 10.7.1.1 Privacy feature in a Peripheral with Controller-based privacy
"If the advertising data or the scan response data change regularly then those changes should be synchronized with any changes in private addresses (both local and remote). For this purpose, the Host should either instruct the Controller to synchronize address changes with those data changes or, if the Controller does not support that feature, generate private addresses as described in Section 10.7.1.2 instead of offloading private address generation to the Controller."
Problem
The lack of synchronization in private addresses changes between controller and host. The host does not really know when RPA changed and when to provide new RSI.
Is it guaranteed that the RPA_Timeout is reset on HCI_LE_Set_Extended_Advertising_Enable/HCI_LE_Set_Advertising_Enable?
Maybe Controller might have a global RPA Timer, so that *_Enable command will cause to generate RPA for this advertising only, but the RPA might not last RPA_Timeout but change earlier. Such behavior makes the host impossible to track RPA changes even if it set and knows RPA_Timeout.
The synchronization would require some HCI vendor event so that the host would know when to change RSI.
Core says, that if there is no such synchronization, then Section 10.7.1.2 should be used (10.7.1.2 Privacy feature in a Peripheral with Host-based privacy).
I see two options here:

To stop using Controller-based privacy at all when CSIS is enabled and just fall-back to Host-based.
1 + To have a HCI Zephyr-specific event that provides synchronization in private addresses generation, that could be used with Zephyr controller only.

Moreover, maybe this would require to raise an errata to Core.

ping @cvinayak @jhedberg @Emil-Gydesen-Bose @sjanc @rymanluk

Hi @MariuszSkamra
I remember this being discussed at the GAWG (ping @asbjornsabo @Rasmus-Abildgren-Bose) multiple times, and IIRC it would considered to be an implementation specific challenge.
IMO Coordinated Sets should never have been a GATT profile, as there so many challenges with the data that CSIS requires (LTK, RPA update, etc.).
I had not previously considered the approach of using a VS event to get the RPA; that's a good idea I think.
Perhaps a combination of the two options?
if (controller == Zephyr) {
    use vendor specific event to update RSI
} else {
    require host-based privacy
}

Removed the bug label: It's not really a bug, but a missing feature.

@jhedberg @alwa-nordic
We need to either be able to force Host privacy, or to use a Zephyr specific event to let an application to always know of RPA changes. Does CONFIG_BT_PRIVACY enable host privacy (rpa_expired is guarded by CONFIG_BT_PRIVACY)?

We need to either be able to force Host privacy, or to use a Zephyr specific event to let an application to always know of RPA changes. Does CONFIG_BT_PRIVACY enable host privacy (rpa_expired is guarded by CONFIG_BT_PRIVACY)?

We do not have a API for forcing Host privacy. CONFIG_BT_PRIVACY enables both host and controller privacy. But my understanding is that the current Host implementation does not use Controller privacy for advertising, except for directed advertising. So the problem does not exist yet. However, the all the points for concern stand. To be safe, we have to explicitly assert somewhere in code that we don't use Controller privacy when an rpa_expired event listener is installed.
The search term for finding the code that enables Controller privacy in the Host is "OWN_ADDR_RPA". For advertising, the following is the relevant bit of code.
https://github.com/zephyrproject-rtos/zephyr/blob/1eb9d36d46b6fcfff2696332ca51fd714eb788dc/subsys/bluetooth/host/id.c#L1595-L1606
For context, the following is the call watershed from Host API to bt_id_set_adv_own_addr.

@alwa-nordic Is it correctly understood that updating the RPA only happens in the host then?
We do have something like bt_rpa_create which is also called from the controller and called from ull_filter_rpa_update, which would indicate the the controller may also update an RPA for an advertising set.

@alwa-nordic Is it correctly understood that updating the RPA only happens in the host then?

For non-directed advertising, yes.

We do have something like bt_rpa_create which is also called from the controller and called from ull_filter_rpa_update, which would indicate the the controller may also update an RPA for an advertising set.

This should be controlled by own_addr_type from the HCI command. The Host will never set own_addr_type to "Please generate an RPA" for non-directed advertising.

Alright, thanks
@cvinayak Do you agree with Aleksander's comments?

This is no longer handled by the stack and should be handled by the application. Closing due to this.

authors: MariuszSkamra Thalley alwa-nordic


text:
device tree: generate pinmux

Generate board pinmux from device tree file.
Aim is to use fully pinmux information from dts and get rid of pinmux.c

Part of #2288

Closing this in favor of #22748

authors: carlescufi erwango galak


text:
usb_descriptor: silently overwrites endpoint address

Describe the bug
The usb_validate_ep_cfg_data function in subsys/usb/device/usb_descriptor.c silently overwrites endpoint address!
Please also mention any information which could help others to understand
the problem you're facing:

What target platform are you using?

Dev OS: Linux <my_vm_name_here> 6.5.0-14-generic #14~22.04.1-Ubuntu SMP PREEMPT_DYNAMIC Mon Nov 20 18:15:30 UTC 2 x86_64 x86_64 x86_64 GNU/Linux
Zephyr RTOS: *** Booting Zephyr OS build zephyr-v3.5.0-4378-g2794727c9724 *** --> NOTE: Here githash may vary from that one of main branch! But this shall not change the core of the bug at the moment!

What have you tried to diagnose or workaround this issue?

Build sample project samples/subsys/usb/testusb and run it wit different USB Endpoint addresses
Noticed no USB EP address change on my development machine, if I wary it.

To Reproduce
Steps to reproduce current behavior:

Checkout curent main branch with git checkout main
(optional step) Add USB device to your board. In my case of nucelo_h745zi_q_m7 I've applided following patch:

diff --git a/boards/arm/nucleo_h745zi_q/nucleo_h745zi_q_m7.dts b/boards/arm/nucleo_h745zi_q/nucleo_h745zi_q_m7.dts
index 184232867b..c8ed5f41b3 100644
--- a/boards/arm/nucleo_h745zi_q/nucleo_h745zi_q_m7.dts
+++ b/boards/arm/nucleo_h745zi_q/nucleo_h745zi_q_m7.dts
@@ -26,6 +26,10 @@
 		zephyr,dtcm = &dtcm;
 		zephyr,sram = &sram0;
 		zephyr,flash = &flash0;
+		zephyr,usb-device = &usbd;
+	};
+
+	usbd: usbotg_fs {
 	};

 	pwmleds {
@@ -121,3 +125,12 @@
 &rng {
 	status = "okay";
 };
+
+&usbotg_fs {
+	pinctrl-0 = <&usb_otg_fs_sof_pa8
+				 &usb_otg_fs_vbus_pa9
+				 &usb_otg_fs_dm_pa11
+				 &usb_otg_fs_dp_pa12>;
+	pinctrl-names = "default";
+	status = "okay";
+};

Enable USB debug log in the application samples/subsys/usb/testusb. You may use for it the patch below:

diff --git a/samples/subsys/usb/testusb/prj.conf b/samples/subsys/usb/testusb/prj.conf
index e310a67818..e34ca0104f 100644
--- a/samples/subsys/usb/testusb/prj.conf
+++ b/samples/subsys/usb/testusb/prj.conf
@@ -9,3 +9,6 @@ CONFIG_USB_DRIVER_LOG_LEVEL_ERR=y
 CONFIG_USB_DEVICE_LOOPBACK=y
 CONFIG_USB_DEVICE_LOG_LEVEL_ERR=y
 CONFIG_USB_DEVICE_INITIALIZE_AT_BOOT=n
+
+CONFIG_USB_DRIVER_LOG_LEVEL_DBG=y
+CONFIG_USB_DEVICE_LOG_LEVEL_DBG=y

Set  LOOPBACK_OUT_EP_ADDR to 0x02. You may use here patch below:

diff --git a/subsys/usb/device/class/loopback.c b/subsys/usb/device/class/loopback.c
index 77c5dde4bd..4191899c74 100644
--- a/subsys/usb/device/class/loopback.c
+++ b/subsys/usb/device/class/loopback.c
@@ -15,7 +15,7 @@
 #include <zephyr/logging/log.h>
 LOG_MODULE_REGISTER(usb_loopback, CONFIG_USB_DEVICE_LOG_LEVEL);

-#define LOOPBACK_OUT_EP_ADDR		0x01
+#define LOOPBACK_OUT_EP_ADDR		0x02
 #define LOOPBACK_IN_EP_ADDR		0x81

 #define LOOPBACK_OUT_EP_IDX		0

Build and Run application samples/subsys/usb/testusb on the board of your choise

Open a new terminal on your Linux host and type sudo cat  /sys/kernel/debug/usb/devices. In my case it shows following output for my board:

T:  Bus=03 Lev=01 Prnt=01 Port=01 Cnt=02 Dev#= 81 Spd=12   MxCh= 0
D:  Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs=  1
P:  Vendor=2fe3 ProdID=0009 Rev= 3.05
S:  Manufacturer=ZEPHYR
S:  Product=Zephyr testusb sample
S:  SerialNumber=3438510D00500038
C:* #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr=100mA
I:* If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=(none)
E:  Ad=01(O) Atr=02(Bulk) MxPS=  64 Ivl=0ms
E:  Ad=81(I) Atr=02(Bulk) MxPS=  64 Ivl=0ms

You shall get similiar output!
Please take a closer look at the line E:  Ad=01(O) Atr=02(Bulk) MxPS=  64 Ivl=0ms. The entry E: Ad=01(O) means - it is an endpoint with Address 0x01 of type Output! Compare it with address set in step 4!

Additionally in the log output of your board you shall see an entry with <dbg> usb_descriptor: usb_validate_ep_cfg_data: Fixing EP address 2 -> 1 message. This basically means, that the address from step 4 were overwritten silently!

If you do not see the message, you may need to increase the log buffer size by applying CONFIG_LOG_BUFFER_SIZE=16384 setting. Of course the buffer size may vary for your board. For me 16KiBi worked well.
Conclusion: Here I see endpoint address have been silently overwriten by usb stack, which is kind of unexpected!
Expected behavior
I am expecting USB Endpoint address to become the value I've choosen.
If it is not possible - I am expecting kind of KConfig flag with CONFIG_USB_FIX_SETTING_SILENTLY=y, s.t. setting this setting to n will throw runtime assertion!
Impact
Annoyance: I lost several hours figuring it out, since the change happened silently.
Showstoper: Implementing device driver for already existing usb drivers in Linux Kernel for example may need additional endpoint entries in SoC, which may consume more RAM.
Logs and console output
Zepthyr RTOS v3.5 log output cut:
[00:00:00.000,000] <dbg> usb_descriptor: usb_get_device_descriptor: __usb_descriptor_end 0x240001a4
[00:00:00.000,000] <dbg> usb_descriptor: usb_fix_descriptor: Device descriptor 0x24000110
[00:00:00.000,000] <dbg> usb_dc_stm32: usb_dc_ep_check_cap: ep 0, mps 64, type 0
[00:00:00.000,000] <dbg> usb_descriptor: usb_desc_update_mps0: Set bMaxPacketSize0 64
[00:00:00.000,000] <dbg> usb_descriptor: usb_fix_descriptor: Configuration descriptor 0x24000122
[00:00:00.000,000] <dbg> usb_descriptor: usb_fix_descriptor: Interface descriptor 0x2400012b
[00:00:00.000,000] <dbg> usb_descriptor: usb_fix_descriptor: Endpoint descriptor 0x24000134
[00:00:00.000,000] <dbg> usb_dc_stm32: usb_dc_ep_check_cap: ep 1, mps 64, type 2
[00:00:00.000,000] <dbg> usb_descriptor: usb_validate_ep_cfg_data: Fixing EP address 2 -> 1
[00:00:00.000,000] <dbg> usb_descriptor: usb_validate_ep_cfg_data: endpoint 0x1
[00:00:00.000,000] <dbg> usb_descriptor: usb_fix_descriptor: Endpoint descriptor 0x2400013b
[00:00:00.000,000] <dbg> usb_dc_stm32: usb_dc_ep_check_cap: ep 81, mps 64, type 2
[00:00:00.000,000] <dbg> usb_descriptor: usb_validate_ep_cfg_data: Fixing EP address 81 -> 81
[00:00:00.000,000] <dbg> usb_descriptor: usb_validate_ep_cfg_data: endpoint 0x81
[00:00:00.000,000] <dbg> usb_descriptor: usb_fix_descriptor: Now the wTotalLength is 32

Environment (please complete the following information):

OS:  Linux <my_vm_name_here> 6.5.0-14-generic #14~22.04.1-Ubuntu SMP PREEMPT_DYNAMIC Mon Nov 20 18:15:30 UTC 2 x86_64 x86_64 x86_64 GNU/Linux
Toolchain zephyr-sdk-0.16.4
Commit SHA or Version used: 37352d3d2993f02b26b027b1a3bde11ab2254319

Additional context
At the moment I've found temporary fix for my problem by disabling EP address fix with following patch:
diff --git a/subsys/usb/device/usb_descriptor.c b/subsys/usb/device/usb_descriptor.c
index 7c2ac37d94..ad09d5cc19 100644
--- a/subsys/usb/device/usb_descriptor.c
+++ b/subsys/usb/device/usb_descriptor.c
@@ -258,17 +258,17 @@ static int usb_validate_ep_cfg_data(struct usb_ep_descriptor * const ep_descr,
 				ep_cfg.ep_addr = idx;
 			}
 			if (!usb_dc_ep_check_cap(&ep_cfg)) {
-				LOG_DBG("Fixing EP address %x -> %x",
-					ep_descr->bEndpointAddress,
-					ep_cfg.ep_addr);
-				ep_descr->bEndpointAddress = ep_cfg.ep_addr;
-				ep_data[i].ep_addr = ep_cfg.ep_addr;
-				if (ep_cfg.ep_addr & USB_EP_DIR_IN) {
-					*requested_ep |= (1U << (idx + 16U));
-				} else {
-					*requested_ep |= (1U << idx);
-				}
-				LOG_DBG("endpoint 0x%x", ep_data[i].ep_addr);
+				// LOG_DBG("Fixing EP address %x -> %x",
+				// 	ep_descr->bEndpointAddress,
+				// 	ep_cfg.ep_addr);
+				// ep_descr->bEndpointAddress = ep_cfg.ep_addr;
+				// ep_data[i].ep_addr = ep_cfg.ep_addr;
+				// if (ep_cfg.ep_addr & USB_EP_DIR_IN) {
+				// 	*requested_ep |= (1U << (idx + 16U));
+				// } else {
+				// 	*requested_ep |= (1U << idx);
+				// }
+				// LOG_DBG("endpoint 0x%x", ep_data[i].ep_addr);
 				return 0;
 			}
 		}

The code shows a direct dependency between the endpoint address and its index in the config field/struct, which may seem overengineered compared to commercial drivers.

The usb_validate_ep_cfg_data function in subsys/usb/device/usb_descriptor.c silently overwrites endpoint address!

This is intentional behavior and not a bug.

Showstoper: Implementing device driver for already existing usb drivers in Linux Kernel for example may need additional endpoint entries in SoC, which may consume more RAM.

Looks like your host-side driver is not parsing function descriptors, here endpoint descriptors, but using fixed addresses. Please fix your broken host-side driver.
I do not accept this report. Closing.

The usb_validate_ep_cfg_data function in subsys/usb/device/usb_descriptor.c silently overwrites endpoint address!

This is intentional behavior and not a bug.

Showstoper: Implementing device driver for already existing usb drivers in Linux Kernel for example may need additional endpoint entries in SoC, which may consume more RAM.

Looks like your host-side driver is not parsing function descriptors, here endpoint descriptors, but using fixed addresses. Please fix your broken host-side driver.
I do not accept this report. Closing.

Can you please state the entry in USB standard, which defines this behaviour? Closing this issue with the reason intentional behavior and not a bug seems to me to be very subective reason.
I have a lot of consumer devices with exactly opposit behaviour as already implemented int Zephyr Stack!

Samsung Flash Drive:

T:  Bus=04 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#=  3 Spd=5000 MxCh= 0
D:  Ver= 3.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 9 #Cfgs=  1
P:  Vendor=090c ProdID=1000 Rev=11.00
S:  Manufacturer=Samsung
S:  Product=Flash Drive
S:  SerialNumber=0361415120013210
C:* #Ifs= 1 Cfg#= 1 Atr=80 MxPwr=304mA
I:* If#= 0 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50 Driver=usb-storage
E:  Ad=01(O) Atr=02(Bulk) MxPS=1024 Ivl=0ms
E:  Ad=82(I) Atr=02(Bulk) MxPS=1024 Ivl=0ms

ASRock LED Controller:

T:  Bus=03 Lev=02 Prnt=03 Port=00 Cnt=01 Dev#= 93 Spd=12   MxCh= 0
D:  Ver= 1.10 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 8 #Cfgs=  1
P:  Vendor=26ce ProdID=01a2 Rev= 0.00
S:  Manufacturer=ASRock
S:  Product=LED Controller
S:  SerialNumber=A02019100900
C:* #Ifs= 1 Cfg#= 1 Atr=80 MxPwr=100mA
I:* If#= 0 Alt= 0 #EPs= 2 Cls=03(HID  ) Sub=00 Prot=00 Driver=usbhid
E:  Ad=81(I) Atr=03(Int.) MxPS=  64 Ivl=1ms
E:  Ad=02(O) Atr=03(Int.) MxPS=  64 Ivl=1ms

Gamin Watch:

T:  Bus=03 Lev=02 Prnt=04 Port=00 Cnt=01 Dev#= 94 Spd=480  MxCh= 0
D:  Ver= 2.00 Cls=ff(vend.) Sub=ff Prot=ff MxPS=64 #Cfgs=  1
P:  Vendor=091e ProdID=0003 Rev= 0.01
C:* #Ifs= 1 Cfg#= 1 Atr=80 MxPwr=500mA
I:* If#= 0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none)
E:  Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E:  Ad=82(I) Atr=03(Int.) MxPS=  64 Ivl=125us
E:  Ad=03(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms

Samsung Portable SSD T5:

T:  Bus=04 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#=  4 Spd=5000 MxCh= 0
D:  Ver= 3.10 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 9 #Cfgs=  1
P:  Vendor=04e8 ProdID=61f5 Rev= 1.00
S:  Manufacturer=Samsung
S:  Product=Portable SSD T5
S:  SerialNumber=1234567BDBA5
C:* #Ifs= 1 Cfg#= 1 Atr=80 MxPwr=896mA
I:  If#= 0 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50 Driver=uas
E:  Ad=81(I) Atr=02(Bulk) MxPS=1024 Ivl=0ms
E:  Ad=02(O) Atr=02(Bulk) MxPS=1024 Ivl=0ms
I:* If#= 0 Alt= 1 #EPs= 4 Cls=08(stor.) Sub=06 Prot=62 Driver=uas
E:  Ad=81(I) Atr=02(Bulk) MxPS=1024 Ivl=0ms
E:  Ad=02(O) Atr=02(Bulk) MxPS=1024 Ivl=0ms
E:  Ad=83(I) Atr=02(Bulk) MxPS=1024 Ivl=0ms
E:  Ad=04(O) Atr=02(Bulk) MxPS=1024 Ivl=0ms

All above devices have NO bound between EP I/O addresses! What makes Zephyr RTOS here different? Why Zephyr RTOS have to follow this specific behaviour?

All the above devices have NO bound between EP I/O addresses and theri indexes in the config fields! What makes Zephyr RTOS here different? Why Zephyr RTOS have to follow this specific behaviour?
Following your statement about broken host driver, would mean all the above devices having broken host drivers too. Ok. I would believe if we speak about Garmin Watch. But what about all the Samsung devices? Would you say, Samsung doing broken USB host drivers? Who decides it?

My statement only refers to your original report, everything else you hallucinated is not part of it.

Now I have even more questions. I reopen this issue in the hope all the other people with additional expertise in USB stack and USB standard take a look here. It looks to me know, tha Zephyr RTOS USB stack serving needs of one consumer only. Moreover I see this behavior as a desgin failure bloking it's flexibility.

Okay, still, if you want to discuss, open a discussion.

@carlescufi Could you please add more peaople for review and discussion?

I am the maintainer of this area and do not accept this bug. Pinging my boss here will not help.

@jfischer-no I didn't knew @carlescufi is your superior. I know him, as a person responsible for a lot of management in Zephyr RTOS. Thus I requested him to add more reviewers.
Since you're the maintainer of the USB stack, you shall be more familiar with USB standards than me. Thus I am asking your for a reference in the USB standard, where behavior I mentioned is defined. What I am getting instead is silent closing of my bug-report and mean (see the word "hallucinating" above).
Opening a discussion would be also fine. But you didn't mentioned it in the first bug-closing.
I also do not like, how you behave towards me and my striving to make Zephyr RTOS better. Zephyr RTOS writes it follows respectful communication. In that case I have to notify responsible people.

I too find the if (!usb_dc_ep_check_cap(&ep_cfg)) handling at least semantically problematic to say the least.
The declaration of usb_dc_ep_check_cap reads:
 Function to check capabilities of an endpoint. usb_dc_ep_cfg_data structure
 provides the endpoint configuration parameters: endpoint address,
 endpoint maximum packet size and endpoint type.
 The driver should check endpoint capabilities and return 0 if the
 endpoint configuration is possible.

I would like to emphasise here the "return 0 if the endpoint configuration is possible" part.
Why would you do a "Fixing EP address" if the configuration is possible ?
I too lost quite a considerable amount of hours dealing with this inconsistency which, as @jfischer-no mentioned, silently changes the endpoint number.

I too find the if (!usb_dc_ep_check_cap(&ep_cfg)) handling at least semantically problematic to say the least.
The declaration of usb_dc_ep_check_cap reads:
 Function to check capabilities of an endpoint. usb_dc_ep_cfg_data structure
 provides the endpoint configuration parameters: endpoint address,
 endpoint maximum packet size and endpoint type.
 The driver should check endpoint capabilities and return 0 if the
 endpoint configuration is possible.

I would like to emphasise here the "return 0 if the endpoint configuration is possible" part.
Why would you do a "Fixing EP address" if the configuration is possible ?

Stack, not the driver API you are citing, fixes endpoint address. Additionally endpoint does not have to be occupied. If the endpoint is free and the desired configuration is possible, then reassign the address. Why? Because it makes absolute sense to distribute resources as efficiently as possible and anything else would be silly.

I too lost quite a considerable amount of hours dealing with this inconsistency which, as @jfischer-no mentioned, silently changes the endpoint number.

You would not do this if your host function driver were checking the endpoint descriptor.

I too find the if (!usb_dc_ep_check_cap(&ep_cfg)) handling at least semantically problematic to say the least.
The declaration of usb_dc_ep_check_cap reads:
 Function to check capabilities of an endpoint. usb_dc_ep_cfg_data structure
 provides the endpoint configuration parameters: endpoint address,
 endpoint maximum packet size and endpoint type.
 The driver should check endpoint capabilities and return 0 if the
 endpoint configuration is possible.

I would like to emphasise here the "return 0 if the endpoint configuration is possible" part.
Why would you do a "Fixing EP address" if the configuration is possible ?

Stack, not the driver API you are citing, fixes endpoint address. Additionally endpoint does not have to be occupied. If the endpoint is free and the desired configuration is possible, then reassign the address. Why? Because it makes absolute sense to distribute resources as efficiently as possible and anything else would be silly.

I am still confused by this behavior.
I see Linux Kernel doing exactly opposite for years. Could you please tell why the're not doing endpoint address fix like Zephyr's stack?
Could you also please show any host endpoint driver doing the right way of addressing according to rules you describe?

I too lost quite a considerable amount of hours dealing with this inconsistency which, as @jfischer-no mentioned, silently changes the endpoint number.

You would not do this if your host function driver were checking the endpoint descriptor.

I reopen it. cause there is still no solution to the problem and my questions, ideas etc. seemst to be not answered in a manner I am asking for.

I reopen it, cause there is still no solution to the problem and my questions, ideas etc. seems to be not answered in a manner I am asking for. Moving information of this issue does not give any resonance from the community. Moreover - discussions seems to me to be not effective.

I have already explained to you that this is not a bug in Zephyr, but in your application. I also know that you are aware of the documentation enhancement that explains this in more detail. Stop spamming this bug report.

authors: 3Nigma KozhinovAlexander jfischer-no


text:
CODEOWNERS: add modem ownership

Add @mike-scott as modem drivers maintainer
Signed-off-by: Michael Scott mike@foundries.io

Also added include/drivers/modem/

Codecov Report

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

@@           Coverage Diff           @@
##           master   #14022   +/-   ##
=======================================
  Coverage   52.24%   52.24%
=======================================
  Files         307      307
  Lines       45467    45467
  Branches    10525    10525
=======================================
  Hits        23752    23752
  Misses      16913    16913
  Partials     4802     4802

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 ed20fc9...f831dad. Read the comment docs.

authors: codecov-io mike-scott


text:
samples: Add environmental logger example.

Add example for reel board that turns it into digital thermometer
with option to read its value through BLE.
Add python code for linux host with TICK stack to log all data
into TSDB.
Example is optimized for low power operation.

I tested with reel board and the most recent master of bluez and the test-device script. After connecting to the board it worked well for me.
What do you think of following additional features to make a ready to use example?

A connection manager which lets you select the reel board you want to connect with (in case of several). Identification could be working based on an advertised Service UUID.
Enforce a secure connection based on a displayed passkey on the passive display of the reel board.
Use a simple interface for demo and long time testing (e.g. csv log-file, mqtt post of a JSON structure to localhost).

@Mierunski not sure if PR is still alive but i wanted to run it and i've rebased it to newer master and fixed issues (new include locations). I've pushed here those changes.


text:
drivers/serial: stm32: fix the uart_irq_tx_ready

The TXE flag is on even then tx irq not enabled, so add check
the tx irq enable status.
Signed-off-by: Harry Jiang explora26@gmail.com

There is a long standing debate on whether this is required or not.
Adding it should not break anything on application already using it.
Though, according to API, this is not strictly required:
/**
 * @brief Check if UART TX buffer can accept a new char
 *
 * @details Check if UART TX buffer can accept at least one character
 * for transmission (i.e. uart_fifo_fill() will succeed and return
 * non-zero). This function must be called in a UART interrupt
 * handler, or its result is undefined. Before calling this function
 * in the interrupt handler, uart_irq_update() must be called once per
 * the handler invocation.
 *
 * @param dev UART device structure.
 *
 * @retval 1 If at least one char can be written to UART.
 * @retval 0 Otherwise.
 */
static inline int uart_irq_tx_ready(struct device *dev)

To be clear, current implementation respects the following (but I don't say this is not error prone):
"UART TX buffer can accept at least one character for transmission (i.e. uart_fifo_fill() will succeed and return non-zero) if function is called in a UART interrupt handler"
"This function must be called in a UART interrupt handler, or its result is undefined."
@explora26, does your application respects these guidelines?

Yes, I'm currently develop application follow the guidelines.
Here is my UART handler very similar to subsys/shell/shell_uart.c
static void uart_callback(void *user_data)
{
    const struct shell_uart *sh_uart = (struct shell_uart *)user_data;
    struct device *dev = sh_uart->ctrl_blk->dev;

    uart_irq_update(dev);

    if (uart_irq_rx_ready(dev)) {
        uart_rx_handle(sh_uart);
    }

    if (uart_irq_tx_ready(dev)) {
        uart_tx_handle(sh_uart);
    }
}

I notice that when RX data coming and then both uart_rx_handle() and uart_tx_handle() are called.
Some platform's driver do check is tx interrupt enabled in uart_irq_tx_ready API (uart_cc32xx.c uart_mcux.c uart_nrfx_uarte.c uart_pl011.c ...),  some platform are not , so the result may difference.
Maybe the implementation need discuss with API owner ?

@explora26 , so don't you find the same issue with uart_irq_rx_ready?

uart_irq_rx_ready has the same behavior.
There is an issue #18815 discuss those function, I think i can close this PR currently and wait for the requirement update.


text:
tests: kernel: critical: add output to support diagnostics

As implemented this test runs for 20 s with no output, which makes it difficult to identify the cause of failure.  Add output indicating progress, and emit diagnostics a particular failure observed on iMX and SAM E70 boards.
This relates to #20585 and #20603.

Tagged for 2.1 because (a) it's a test and (b) it helps us figure out whether things like #20585 have been fixed by a PR.


text:
drivers: clock_control: nrf: Fix nrf53 LFXO pin configuration

Pins used for external LF clock source must be configured as
used by peripheral to allow using LFXO on network side.
Note that it is a temporary location and this will end up in nrfx_clock.
Signed-off-by: Krzysztof Chruscinski krzysztof.chruscinski@nordicsemi.no

@anangl @ioannisg ping. This PR is now blocking #27398

@ioannisg @anangl please review

@ioannisg @anangl please review

@ioannisg @anangl ^^

authors: carlescufi nordic-krch


text:
tests/kernel/timer/timer_api: modify logic for longer real time

SYS_CLOCK_TICKS_PER_SEC of it8xxx2 is 4096 (244us).
Running test_sleep_abs item on it8xxx2 and we get
k_us_to_ticks_ceil32(250) = 2 and late = 2, so it failed.
After we enable the CONFIG_PM, it needs more time to resume
from low power mode, so I modify the logic to <= for passing
the test.
fixes #49605
Signed-off-by: Ruibin Chang Ruibin.Chang@ite.com.tw

Sure.
FWIW: generally when you come in to fix a time aliasing issue in a test like this, it's best to rework the logic so it operates exclusively in ticks, which makes it more robust. Most of these tests were written early on, before the new timeout API, and are using realtime numbers that don't always scale to different devices well.
In this case the test was demanding that you have no more than 1 tick of error, which is really (!) hard to do due to natural skew in the test environment. So effectively you've changed it to two ticks, which seems very reasonable to me. But it would probably work to express this as "< 2" for all platforms, or potentially MAX(2, k_us_to_ticks_ceil32(250)), etc...
Not a reason not to merge, but just a nice thing to fix while you're here if you have the time and inclination.

Done


text:
board: qemu_x86: Allow pcie0 to be referenced

Changing pcie0 to pcie0: pcie0 allows it to be referenced as &pcie0. I am not sure why this is required. Otherwise I get error:
...
parse error: undefined node label 'pcie0'
...

Yep, that's how DTS is... If you only have node { then "node" is the name of the node but not a label. Names can only be referenced using the full path in the DTS hierarchy (e.g. "/pcie0") rather than just the last component. When you do pcie0: pcie0 then the part before the : is a label for the node with the name "pcie0", and you're then able to reference it using the label alone (i.e. ignoring it's placement within the DTS tree-based hierarchy)

@finikorg out of curiosity, where exactly do you need this?

@finikorg out of curiosity, where exactly do you need this?

I want to add qemu_x86_64 specific PCI devices to boards/x86/qemu_x86/qemu_x86_64.dts.
There is also another use case: plug PCIE device to the board.

I think I will follow documented usage for pci0:
https://github.com/zephyrproject-rtos/zephyr/blob/23f057804285c26806863daed1d095dd06ebc2dc/include/zephyr/devicetree.h#L1485-L1503

authors: finikorg jhedberg


text:
subsys/mgmt/ec_host_cmd: rework Host Command support

Rework the Host Command support. It includes:
-update of naming
-change API to backend
-chagne a way of definding rx and tx buffers
-fix synchronization between the handler and backend layer -simply the HC handler
-update the directory structure
Signed-off-by: Dawid Niedzwiecki dn@semihalf.com

Tried configuring hello_world for the it8xxx2 board then checked with menuconfig at these options, and it seems EC_HOST_CMD_BACKEND_SHI_ITE is not available for this board despite the name suggesting that it is - is this expected?

Tried configuring hello_world for the it8xxx2 board then checked with menuconfig at these options, and it seems EC_HOST_CMD_BACKEND_SHI_ITE is not available for this board despite the name suggesting that it is - is this expected?

Have you enabled the "ite,it8xxx2-shi" node?

+1 from me after these changes. I don't know anything about this system so in terms of reviewing the way the code works, I don't know on that front.

Thanks a lot for the review.

Added few nitpicks for the doc format, having a real hard time following the changes in the backends in the third patch, those 4 points in the commit should really be at least 4 separate patches. Are you planning on maintaining this after this PR? If so, I'd say let's go with it but maybe add a MAINTAINERS entry for this.

I get your point. The problem is that some changes implicate other ones. Also adjusting every backend per commit would be really painful. I think this PR should be treated as adding support for the Host Commands from scratch, because of amount of changes. The previous system wasn't usable in my opinion.

The file move of subsys/mgmt/ec_host_cmd/ec_host_cmd_periph/ec_host_cmd_periph_shi.h needs to update the #ifdef guard for the new path.

The file move of subsys/mgmt/ec_host_cmd/ec_host_cmd_periph/ec_host_cmd_periph_shi.h needs to update the #ifdef guard for the new path.

Done

Friendly ping :-)

Sorry, I've added many comments that haven't been visible for you.


text:
DA1469x counter driver

This PR is adding the counter for the Renesas DA1469x microcontroller family

The PR depends on #54263 and all test should be passing when it is merged.


text:
Small macro fixes

Simplify macro to get current cpu.

Can you fix these to use _current_cpu (from kernel_struct.h) instead? That macro includes an assertion that's proven really important for catching mistakes. In general it's not legal to ask "what CPU am I running on?", because you might be preempted and migrated before you can use the answer. _current_cpu checks that you're in a context (e.g. interrupts locked, ISR, pinned thread) where that's impossible.

yep, we can. I don't quite remember why it was not using that to be honest.

@evgeniy-paltsev would you mind take another look please ?

@evgeniy-paltsev ping


text:
samples: net: zperf: Use all the RAM and ROM for Quark SE dev

As the config file disables ARC we can use its RAM and ROM in
x86 side.
Signed-off-by: Jukka Rissanen jukka.rissanen@linux.intel.com

Codecov Report

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

@@           Coverage Diff           @@
##           master    #6275   +/-   ##
=======================================
  Coverage   53.16%   53.16%
=======================================
  Files         412      412
  Lines       40136    40136
  Branches     7731     7731
=======================================
  Hits        21337    21337
  Misses      15664    15664
  Partials     3135     3135

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 10ef346...3eef3a0. Read the comment docs.

This issue needs to be fixes some other way so removing this PR for now.

authors: codecov-io jukkar


text:
Bluetooth: ascs: Check subscription state on ASE notification

Check whether peer is subscribed for ASE state notification before calling bt_gatt_notify. This handles an assert thrown when the notification failed to be sent.
Fixes: #63728

@Thalley same with this one and the linked issue being an enhancement. I'll remove the 3.5 milestone for now, but let me know if this is something more than an enhancement.

@MariuszSkamra You raised the issue an enhancement rather than a bug, although an unexpected __ASSERT would mean a bug in my eyes - Do you agree?

@Thalley @jhedberg looks like the bug label was removed from https://github.com/zephyrproject-rtos/zephyr/issues/63728

@Thalley @jhedberg looks like the bug label was removed from #63728

It had both "bug" and "enhancement", which are mutually exclusive.

authors: MariuszSkamra Thalley jhedberg


text:
Fix MCUboot failed to build on ESP32 platforms

The MCUboot is failing during the build on ESP32 and ESP32S3 boards. The reason is the recent changes in Xtensa architecture and the fact that CI didn't catch those changes. That's why we adding the ESP32 platforms to the MCUboot/--sysbuild samples.
Fixes #74695

fixing https://github.com/zephyrproject-rtos/zephyr/issues/74695

@tejlmand Please revisit.

authors: henrikbrixandersen marekmatej


text:
sensor: lis2dux12: fix: CID 363712: Initialize mode-fs

Following the same pattern used in lis2dux12_sample_fetch_accel.
Fixes #74754

CC @kdunn926
@avisconti please review

authors: aescolar ubieda


text:
arch: riscv: handle PMP setting for _Fault handler

When CONFIG_RISCV_ALWAYS_SWITCH_THROUGH_ECALL is enabled, do_swap() from _Fault triggers a PMP error again if the fault is caused by a PMP violation. This PR handles the PMP settings for faults caused by PMP violations:

For kernel thread stack overflow:
Remove the previous thread's PMP configuration.

For user thread violates memory protection:
Configure the PMP for the thread's privileged stack.

Although this bug occurs only when CONFIG_RISCV_ALWAYS_SWITCH_THROUGH_ECALL is enabled, I think these fixes are also compatible when CONFIG_RISCV_ALWAYS_SWITCH_THROUGH_ECALL is disabled.
Fixes: #75959

A few comments:

Please elaborate more in the commit message for "protect privileged stack
for fault handler" with a list of events illustrating the issue. I still
don't see where the problem is.

I imagine the second patch is a consequence of the first? Please say so in
the commit log. Otherwise it looks like you add stack guard just to remove
it later.

Couldn't z_riscv_pmp_stackguard_disable() be implemented by simply clearing
MSTATUS_MPRV?

@npitre, thank you for your feedback.

Please elaborate more in the commit message for "protect privileged stack
for fault handler" with a list of events illustrating the issue. I still
don't see where the problem is.

The first commit majorly change PMP setting to privileged mode for faults from user mode.
Protect privileged stack just the side effect of this fix.
I have update the commit message to make it clearer.

I imagine the second patch is a consequence of the first? Please say so in
the commit log. Otherwise it looks like you add stack guard just to remove
it later.

These commits are independent to fix 2 different cases:

user thread violates PMP memory protection
The first commit changes PMP setting to privileged mode for fault triggered from user mode.
kernel thread triggers PMP stack guard
The second commit removes the thread's PMP setting for fault triggered by stack overflow.

Couldn't z_riscv_pmp_stackguard_disable() be implemented by simply clearing
MSTATUS_MPRV?

Disabling mstatus.mprv is not enough because do_swap() enables mstatus.mprv in is_kernel_syscall when CONFIG_RISCV_ALWAYS_SWITCH_THROUGH_ECALL is enabled.
The previous stack overflow PMP setting triggers an error during the do_swap() call from the fault handler.

authors: jimmyzhe npitre


text:
kernel: Remove ALWAYS_INLINE from z_unpend_thread_no_timeout()

A little bit of kernel housekeeping.

Removes the declaration for z_sched_abort() as that routine no longer exists.

Removes the ALWAYS_INLINE attribute from the definition of the routine z_unpend_thread_no_timeout() to fix an unresolved symbol error that was occurring with some compilers.  (Fixes #75704)

I agree that most ALWAYS_INLINE are there for performance reasons. However, when it comes to z_unpend_thread_no_timeout(), I think it is misplaced--it was likely beneficial once, but enough changes and tuning have occurred since then to make it less crucial in this case.
Presently, it is only referenced in two places.

sched.c :: z_unpend_thread()
timer.c :: z_timer_expiration_handler()

The fact that it is referenced in timer.c but defined in sched.c using ALWAYS_INLINE raises an eyebrow. Up until now this has not caused an issue. However, based on the report it would appear that the always_inline attribute has the potential to not generate external linkage information (at least on some compilers). Whether the lack of external linkage info is a toolchain bug or if that is something that is up to the toolchain to choose the behavior, is something that I have not yet been able to nail down.  Either way, the simplest solutions to this appear to be either ...
1. Replace _ALWAYS_INLINE_ with _inline_, or ...
2. Remove _ALWAYS_INLINE_.

As z_unpend_thread_no_timeout() does not appear to be on critical paths, I figured removing ALWAYS_INLINE should suffice. However, if anyone would still prefer to see it replaced with inline, I do not have any objections to that approach.

The fact that it is referenced in timer.c but defined in sched.c using ALWAYS_INLINE raises an eyebrow

That sounds like it's just code motion that caused the issue.  But do check the generated code.  It's not impossible that this PR will result in the removal of two duplicated instantiations of the function, which is a win and not a loss.

I did a quick check of the generated code (tests/kernel/timer/timer_api on qemu_x86), and found the following ...

Original Code (ALWAYS_INLINE) - We have both an inline version of z_unpend_thread_no_timeout() within z_unpend_thread() and a full definition that is called from z_timer_expiration_handler().
Proposed Code (Remove ALWAYS_INLINE) - We have only the full definition called from both z_unpend_thread() and z_timer_expiration_handler().
Alternative (Replace ALWAYS_INLINE with inline) - We have only the full definition called from both z_unpend_thread() and z_timer_expiration_handler().

Smaller code size might be a safe bet

OK, I'm sold.  It looks like this broke a while back when one caller moved to a different file; everything used to be in sched.c and the inlining was clear.  But if one case is going to call it as a true function we should err on the side of code bytes for sure.
Really I guess my sense here agrees with yours: the previous optimization pass is now stale and bitrotten, and it's time to get out the microscope and do it again.  A reasonable first step is making everything build cleanly.

authors: andyross cfriedt peter-mitsis


text:
boards/native/doc: Update architecture description

The architecture description was quite out of date in some parts, specially those which changed with the introduction of the native simulator.
Let's update it.
Link to rendered docs (when completed)
https://builds.zephyrproject.io/zephyr/pr/78993/docs/boards/native/doc/arch_soc.html

Thanks for the reviews so far @jori-nordic & @theob-pro . I updated it based on @jori-nordic feedback.


text:
npm run start is hanging

Hi there
starting from scratch following all instructions in the README, when I run npm run start in the client?-directory, the process is hanging with "Starting the development server...". The browser gets opened referring to "localhost:3000", but nothing happens. It will timeout later.
No further details are provided in the console. It just hangs.
I'm pretty sure that no other application is listening on this port (sudo lsof -n -i -P | grep 3000).
Tested on Macbook Pro running MacOS Mojave.
$ node -v
v10.11.0

$ npm -v
6.9.0

$ zos --version
2.3.0

Is anybody else facing this issue?
I remember it has worked exactly one week ago without any issues. Maybe some dependencies have changed and broke it somewhere?

Hey @itinance. I am pretty sure it is zos@2.3.0. Can you try version zos@2.2? We'll add full support of version zos@2.3 with new cool features next week but for now please sick to v2.2.

With zos@2.2.0 it works! Thanks a lot :)

No problem. Sorry for inconvenience and soon will drop more cool features!

authors: itinance ylv-io

repo: zeppelinos/zepkit


text:
🐛 API errors not handled

💡 Summary
API errors aren't being shown in the message box
🥰 Expected Behavior
Errors will be shown in the message box in the top right
🤬 Actual Behavior
API requests will silently fail with no notification to the user
📝 Steps to Reproduce

Open zer0bin
Try creating a paste that exceeds the zer0bin instances max character count

Fixed on 0576a2e


text:
Redirect to a custom path

I would like to direct the links contained in a page notion to a custom path in my vue application.
In a similar way to what happens on the page:
https://vue3-notion.vercel.app/page/de51eee9-6dc3-4698-8484-94e04c0ec2fe
Currently, when I click on a link in the content, I am redirected to my app's route concatenated to the page ID.
I need an example of how I can configure this, or if I can get an event to work this dynamic.
example:
https://root.com/cusom-path/notionId
Does anyone know a solution?

You can setup the mapPageUrl  config, see https://github.com/zernonia/vue3-notion/blob/HEAD/demo/nuxt/composables/useProps.ts

authors: BeanWei GugaAraujo


text:
added a Tennis game

Zero To Mastery - Webblocks 2022 📦📦
PR contains:

Added a Tennis game which is created using html css and javascript.

Breaking changes

None

Screenshots

Closing this PR due to unresolved change request. Feel free to resolve and reopen

authors: MattCSmith thanmaisai


text:
Is zmq.context.instance() thread safe?

It appears that initialization of the global context is not protected by a lock. Is it intentional?

It should probably have a lock.

authors: Kentzo minrk

repo: zeromq/pyzmq


text:
gltfpack: Experimental support for floating point position quantization

Currently gltfpack provides all or nothing quantization: either all
attributes get quantized, or none do.
When quantization is used, we use the most size and memory efficient
formats, which is great, but it can lead to integration issues for
applications - since dequantization uses an extra transform, this
results in changes that are needed for some applications to take that
transform into account. Notably, these changes mostly revolve around
positions (and rarely around texture coordinates wrt texture
replacement, but positions are definitely the main source of issues).
Due to the flexibility of meshopt codecs however, there are other
options available that don't change the coordinate space of mesh
positions, but instead just change the positions a little bit to encode
more efficiently.
This change adds a new mode, -vpf, which uses floating point
quantization to encode position values:

When using regular compression (-c), we quantize each coordinate
individually
When using extra compression (-cc), we use exponential filter when
serializing the position stream

It is expected that either mode is less efficient than integer
quantization, but -cc can be closer to integer quantization and on
meshes with many attributes the extra size could be an acceptable
tradeoff for better compatibility. Of course this also results in geometry
taking a little bit more space after being loaded, since we use 12 bytes
per position instead of 8 bytes.

TODO:

Gather size statistics for various models
Validate quantization bits behavior for models to ensure precision is reasonably close between different modes
Check if exponential encoding (but one coordinate at a time) is better for -c

Using very aggressive 8 bits for position (default is 14) on SciFiHelmet:
-vp 8 -cc (current), ~10.1 bits per position

-vp 8 -vpf (new, float quantization), ~36 bits per position

-vp 8 -vpf -c (new, separate exponent encoding), ~21.7 bits per position

-vp 8 -vpf -cc (new, shared exponent encoding), ~14.3 bits per position

It looks like shared exponent might be too aggressive to pursue, since it introduces a significant amount of error due to coupled components - this gets worse because gltfpack likes to transform meshes to world space, which doesn't matter for quantization but does matter for this new mode (and might be something to disable conditionally...)

BrainStem.gltf - again, with 8-bit quantization (very aggressive):
-vp 8 -cc (quantized integer): 10 bits

-vp 8 -vpf (quantized float): 38 bits

-vp 8 -vpf -c (separate exponent): 25 bits

-vp 8 -vpf -cc (shared exponent): 14 bits

Here shared exponent seems to be doing alright, probably because the mesh is more local / centered which is normal for rigged meshes.

Because quantized compressed positions can be misleading wrt the resulting size, here's just the size stats for the two models above with default bits (14):
SciFiHelmet:
-cc (integer quantization): 32.7 bits
-vpf (float quantization): 47.9 bits
-vpf -c (separate exponent): 44.3 bits
-vpf -cc (shared exponent): 39.6 bits
BrainStem:
-cc (integer quantization): 29.8 bits
-vpf (float quantization): 44.8 bits
-vpf -c (separate exponent): 43.4 bits
-vpf -cc (shared exponent): 32.8 bits
So that I don't get confused in the future: all numbers for float quantization do include vertex codec compression on top even if the current version of the code doesn't allow that configuration.
Here's what the data looks like for the entire glTF buffer (sans textures) after zstd:
SciFiHelmet:
-cc (integer quantization): 562 KB
-vpf (float quantization): 670 KB
-vpf -c (separate exponent): 650 KB
-vpf -cc (shared exponent): 608 KB
BrainStem:
-cc (integer quantization): 254 KB
-vpf (float quantization): 310 KB
-vpf -c (separate exponent): 305 KB
-vpf -cc (shared exponent): 265 KB

CarbonBike model from #433 (the new mode isn't sensible to local transforms to the same extent and as such the model is preserved well), before gzip/zstd:
no quantization: vertex 3208635 bytes, index 126219 bytes
integer quantization: vertex 848142 bytes, index 126219 bytes
float quantization: vertex 1186861 bytes, index 126219 bytes
separate exponent: vertex 1166609 bytes, index 126219 bytes
shared exponent: vertex 1049273 bytes, index 126219 bytes
Overall this feels like a great future replacement for -noq but I'll need to figure out how to think about shared/separate exponent given the precision concerns vs size tradeoff.

One other alternative is to share the exponent between all components of a single coordinate in a vertex stream. This is close in spirit to uniform quantization, as it essentially selects a power-of-two bucket and thus should be close to the error of the integer quantization, but the exponent doesn't take space in the stream as it compresses perfectly.
8 bits + integer quantization: 10.1 bits:

8 bits + float quantization: 36 bits:

8 bits + separate exponent: 20.4 bits:

8 bits + shared exponent: 14.3 bits:

8 bits + component exponent: 14.2 bits:

repo: zeux/meshoptimizer


text:
请问scaler pkl文件在哪里？

请问作者代码中
self.scaler = load_pkl("{0}/scaler_in{1}_out{2}.pkl".format(cfg["TRAIN"]["DATA"]["DIR"], cfg["DATASET_INPUT_LEN"], cfg["DATASET_OUTPUT_LEN"]))
使用了这个文件在哪里可以下载

是运行数据预处理脚本之后自动产生的，无需额外关注。

authors: XZXSean zezhishao

repo: zezhishao/STID


text:
Patch's data can't be changed by listener

Create and update methods has
        } elseif (! $results->isEmpty() && $results->last() !== null) {
            // TODO Change to a more logical/secure way to see if data was acted and and we have the expected response
            $preEventData = $results->last();
        } else {
            $preEventData = $data;
        }

block, which allows listener to change the $data. Patch method has no such as logic. Why? Is it a bug?

See #298 if I understood it right.

repo: zfcampus/zf-apigility-doctrine