improve: use ringbuffer to send spans

Signed-off-by: Andy Lok<EMAIL_ADDRESS>

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

17 of 24 (70.83%)  changed or added relevant lines in 2 files are covered.
3 unchanged lines in 2 files lost coverage.
Overall coverage decreased (-0.4%) to 82.42%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

minitrace/src/util/spsc.rs
14
21
66.67%

Files with Coverage Reduction
New Missed Lines
%

minitrace/src/util/spsc.rs
1
66.67%

minitrace/src/local/local_span_stack.rs
2
93.02%

Totals

Change from base Build<PHONE_NUMBER>:
-0.4%

Covered Lines:
1655

Relevant Lines:
2008

💛  - Coveralls

The commit messages are silent on what the bench results were in terms of improvement.
Can you share any data here?

@taqtiqa-mark Thanks for reminder.
The benchmark for lastest commit:
     Running benches/compare.rs (target/release/deps/compare-ea219fd34fcebaa0)
Gnuplot not found, using plotters backend
compare/Tokio Tracing/1 time:   [25.119 µs 25.251 µs 25.401 µs]
Found 3 outliers among 100 measurements (3.00%)
  3 (3.00%) high mild
compare/Rustracing/1    time:   [10.390 µs 10.450 µs 10.517 µs]
Found 2 outliers among 100 measurements (2.00%)
  2 (2.00%) high mild
compare/minitrace/1     time:   [11.644 µs 11.710 µs 11.777 µs]
compare/Tokio Tracing/10
                        time:   [134.02 µs 134.62 µs 135.37 µs]
Found 8 outliers among 100 measurements (8.00%)
  4 (4.00%) high mild
  4 (4.00%) high severe
compare/Rustracing/10   time:   [52.612 µs 52.919 µs 53.253 µs]
Found 4 outliers among 100 measurements (4.00%)
  4 (4.00%) high mild
compare/minitrace/10    time:   [52.069 µs 52.338 µs 52.626 µs]
Found 5 outliers among 100 measurements (5.00%)
  3 (3.00%) high mild
  2 (2.00%) high severe
Benchmarking compare/Tokio Tracing/100: Warming up for 3.0000 s
Warning: Unable to complete 100 samples in 5.0s. You may wish to increase target time to 6.3s, enable flat sampling, or reduce sample count to 60.
compare/Tokio Tracing/100
                        time:   [1.2430 ms 1.2492 ms 1.2559 ms]
Found 12 outliers among 100 measurements (12.00%)
  1 (1.00%) low mild
  4 (4.00%) high mild
  7 (7.00%) high severe
compare/Rustracing/100  time:   [487.06 µs 489.34 µs 491.74 µs]
Found 8 outliers among 100 measurements (8.00%)
  8 (8.00%) high mild
compare/minitrace/100   time:   [458.61 µs 460.41 µs 462.39 µs]
Found 3 outliers among 100 measurements (3.00%)
  3 (3.00%) high mild
compare/Tokio Tracing/1000
                        time:   [12.412 ms 12.473 ms 12.538 ms]
Found 2 outliers among 100 measurements (2.00%)
  2 (2.00%) high mild
compare/Rustracing/1000 time:   [4.8734 ms 4.8916 ms 4.9110 ms]
Found 10 outliers among 100 measurements (10.00%)
  8 (8.00%) high mild
  2 (2.00%) high severe
compare/minitrace/1000  time:   [4.7386 ms 4.7730 ms 4.8090 ms]
Found 2 outliers among 100 measurements (2.00%)
  2 (2.00%) high mild

     Running benches/object_pool.rs (target/release/deps/object_pool-71ee5e07119c6c6e)
Gnuplot not found, using plotters backend
Vec::with_capacity/object-pool/1
                        time:   [10.360 ns 10.438 ns 10.514 ns]
Vec::with_capacity/alloc/1
                        time:   [12.776 ns 12.816 ns 12.858 ns]
Found 6 outliers among 100 measurements (6.00%)
  5 (5.00%) high mild
  1 (1.00%) high severe
Vec::with_capacity/object-pool/10
                        time:   [10.180 ns 10.215 ns 10.257 ns]
Found 7 outliers among 100 measurements (7.00%)
  1 (1.00%) low mild
  2 (2.00%) high mild
  4 (4.00%) high severe
Vec::with_capacity/alloc/10
                        time:   [13.360 ns 13.440 ns 13.530 ns]
Found 4 outliers among 100 measurements (4.00%)
  2 (2.00%) high mild
  2 (2.00%) high severe
Vec::with_capacity/object-pool/100
                        time:   [10.081 ns 10.125 ns 10.179 ns]
Found 9 outliers among 100 measurements (9.00%)
  7 (7.00%) high mild
  2 (2.00%) high severe
Vec::with_capacity/alloc/100
                        time:   [12.719 ns 12.754 ns 12.789 ns]
Found 1 outliers among 100 measurements (1.00%)
  1 (1.00%) high mild
Vec::with_capacity/object-pool/1000
                        time:   [10.080 ns 10.114 ns 10.157 ns]
Found 5 outliers among 100 measurements (5.00%)
  3 (3.00%) high mild
  2 (2.00%) high severe
Vec::with_capacity/alloc/1000
                        time:   [3.8606 µs 3.8840 µs 3.9100 µs]
Found 28 outliers among 100 measurements (28.00%)
  7 (7.00%) low severe
  5 (5.00%) low mild
  9 (9.00%) high mild
  7 (7.00%) high severe
Vec::with_capacity/object-pool/10000
                        time:   [10.044 ns 10.089 ns 10.139 ns]
Found 12 outliers among 100 measurements (12.00%)
  2 (2.00%) high mild
  10 (10.00%) high severe
Vec::with_capacity/alloc/10000
                        time:   [5.5136 µs 5.5259 µs 5.5373 µs]
Found 8 outliers among 100 measurements (8.00%)
  6 (6.00%) high mild
  2 (2.00%) high severe
Vec::with_capacity/object-pool/100000
                        time:   [10.040 ns 10.084 ns 10.129 ns]
Found 4 outliers among 100 measurements (4.00%)
  2 (2.00%) high mild
  2 (2.00%) high severe
Vec::with_capacity/alloc/100000
                        time:   [7.5572 µs 7.5984 µs 7.6426 µs]

     Running benches/spsc.rs (target/release/deps/spsc-1852d9b57e136832)
Gnuplot not found, using plotters backend
spsc channel/crossbeam/1
                        time:   [91.996 µs 92.566 µs 93.151 µs]
Found 3 outliers among 100 measurements (3.00%)
  2 (2.00%) high mild
  1 (1.00%) high severe
spsc channel/ringbuffer/1
                        time:   [92.819 µs 93.461 µs 94.155 µs]
Found 5 outliers among 100 measurements (5.00%)
  4 (4.00%) high mild
  1 (1.00%) high severe
spsc channel/minitrace/1
                        time:   [92.935 µs 93.440 µs 93.971 µs]
Found 3 outliers among 100 measurements (3.00%)
  1 (1.00%) low mild
  2 (2.00%) high mild
spsc channel/minitrace-legacy/1
                        time:   [95.084 µs 95.689 µs 96.324 µs]
Found 3 outliers among 100 measurements (3.00%)
  1 (1.00%) low mild
  1 (1.00%) high mild
  1 (1.00%) high severe
spsc channel/crossbeam/10
                        time:   [93.219 µs 93.818 µs 94.485 µs]
Found 6 outliers among 100 measurements (6.00%)
  1 (1.00%) low mild
  4 (4.00%) high mild
  1 (1.00%) high severe
spsc channel/ringbuffer/10
                        time:   [93.602 µs 94.275 µs 94.994 µs]
Found 7 outliers among 100 measurements (7.00%)
  4 (4.00%) high mild
  3 (3.00%) high severe
spsc channel/minitrace/10
                        time:   [92.664 µs 93.213 µs 93.764 µs]
Found 4 outliers among 100 measurements (4.00%)
  1 (1.00%) low severe
  2 (2.00%) high mild
  1 (1.00%) high severe
spsc channel/minitrace-legacy/10
                        time:   [98.599 µs 99.188 µs 99.843 µs]
Found 5 outliers among 100 measurements (5.00%)
  1 (1.00%) low mild
  2 (2.00%) high mild
  2 (2.00%) high severe
spsc channel/crossbeam/100
                        time:   [92.536 µs 92.988 µs 93.482 µs]
Found 5 outliers among 100 measurements (5.00%)
  3 (3.00%) high mild
  2 (2.00%) high severe
spsc channel/ringbuffer/100
                        time:   [93.981 µs 94.624 µs 95.300 µs]
Found 3 outliers among 100 measurements (3.00%)
  3 (3.00%) high mild
spsc channel/minitrace/100
                        time:   [93.794 µs 94.310 µs 94.831 µs]
Found 6 outliers among 100 measurements (6.00%)
  5 (5.00%) high mild
  1 (1.00%) high severe
spsc channel/minitrace-legacy/100
                        time:   [110.67 µs 111.31 µs 112.01 µs]
Found 7 outliers among 100 measurements (7.00%)
  1 (1.00%) low severe
  1 (1.00%) high mild
  5 (5.00%) high severe
spsc channel/crossbeam/1000
                        time:   [97.030 µs 97.660 µs 98.354 µs]
Found 7 outliers among 100 measurements (7.00%)
  2 (2.00%) low mild
  4 (4.00%) high mild
  1 (1.00%) high severe
spsc channel/ringbuffer/1000
                        time:   [95.950 µs 96.563 µs 97.202 µs]
Found 5 outliers among 100 measurements (5.00%)
  5 (5.00%) high mild
spsc channel/minitrace/1000
                        time:   [96.789 µs 97.501 µs 98.285 µs]
Found 3 outliers among 100 measurements (3.00%)
  3 (3.00%) high mild
spsc channel/minitrace-legacy/1000
                        time:   [111.36 µs 112.05 µs 112.77 µs]
Found 13 outliers among 100 measurements (13.00%)
  4 (4.00%) low mild
  7 (7.00%) high mild
  2 (2.00%) high severe
spsc channel/crossbeam/10000
                        time:   [141.84 µs 142.91 µs 144.17 µs]
Found 7 outliers among 100 measurements (7.00%)
  1 (1.00%) low mild
  3 (3.00%) high mild
  3 (3.00%) high severe
spsc channel/ringbuffer/10000
                        time:   [120.02 µs 120.82 µs 121.68 µs]
Found 6 outliers among 100 measurements (6.00%)
  4 (4.00%) high mild
  2 (2.00%) high severe
spsc channel/minitrace/10000
                        time:   [120.76 µs 121.41 µs 122.11 µs]
Found 7 outliers among 100 measurements (7.00%)
  2 (2.00%) low mild
  4 (4.00%) high mild
  1 (1.00%) high severe
spsc channel/minitrace-legacy/10000
                        time:   [185.67 µs 187.20 µs 188.88 µs]
Found 4 outliers among 100 measurements (4.00%)
  1 (1.00%) low mild
  3 (3.00%) high mild

spsc channel send only/crossbeam/1
                        time:   [2.3719 µs 2.3828 µs 2.3945 µs]
spsc channel send only/ringbuffer/1
                        time:   [2.3612 µs 2.3732 µs 2.3875 µs]
Found 10 outliers among 100 measurements (10.00%)
  1 (1.00%) low mild
  2 (2.00%) high mild
  7 (7.00%) high severe
spsc channel send only/minitrace/1
                        time:   [2.3247 µs 2.3336 µs 2.3426 µs]
Found 1 outliers among 100 measurements (1.00%)
  1 (1.00%) high mild
spsc channel send only/minitrace-legacy/1
                        time:   [2.3323 µs 2.3436 µs 2.3546 µs]
Found 1 outliers among 100 measurements (1.00%)
  1 (1.00%) high mild
spsc channel send only/crossbeam/10
                        time:   [2.4191 µs 2.4311 µs 2.4433 µs]
Found 4 outliers among 100 measurements (4.00%)
  4 (4.00%) high mild
spsc channel send only/ringbuffer/10
                        time:   [2.3233 µs 2.3357 µs 2.3493 µs]
Found 2 outliers among 100 measurements (2.00%)
  2 (2.00%) high mild
spsc channel send only/minitrace/10
                        time:   [2.3324 µs 2.3416 µs 2.3500 µs]
Found 4 outliers among 100 measurements (4.00%)
  3 (3.00%) high mild
  1 (1.00%) high severe
spsc channel send only/minitrace-legacy/10
                        time:   [2.3321 µs 2.3417 µs 2.3516 µs]
Found 7 outliers among 100 measurements (7.00%)
  4 (4.00%) high mild
  3 (3.00%) high severe
spsc channel send only/crossbeam/100
                        time:   [2.6391 µs 2.6524 µs 2.6659 µs]
Found 1 outliers among 100 measurements (1.00%)
  1 (1.00%) high mild
spsc channel send only/ringbuffer/100
                        time:   [2.4501 µs 2.4623 µs 2.4751 µs]
Found 14 outliers among 100 measurements (14.00%)
  4 (4.00%) low mild
  7 (7.00%) high mild
  3 (3.00%) high severe
spsc channel send only/minitrace/100
                        time:   [2.4902 µs 2.4993 µs 2.5084 µs]
Found 2 outliers among 100 measurements (2.00%)
  2 (2.00%) high mild
spsc channel send only/minitrace-legacy/100
                        time:   [2.6095 µs 2.6200 µs 2.6323 µs]
Found 13 outliers among 100 measurements (13.00%)
  6 (6.00%) high mild
  7 (7.00%) high severe
spsc channel send only/crossbeam/1000
                        time:   [5.6602 µs 5.6850 µs 5.7114 µs]
Found 5 outliers among 100 measurements (5.00%)
  4 (4.00%) high mild
  1 (1.00%) high severe
spsc channel send only/ringbuffer/1000
                        time:   [3.1930 µs 3.1991 µs 3.2062 µs]
Found 6 outliers among 100 measurements (6.00%)
  5 (5.00%) high mild
  1 (1.00%) high severe
spsc channel send only/minitrace/1000
                        time:   [3.9981 µs 4.0142 µs 4.0321 µs]
Found 2 outliers among 100 measurements (2.00%)
  1 (1.00%) high mild
  1 (1.00%) high severe
spsc channel send only/minitrace-legacy/1000
                        time:   [5.3636 µs 5.3857 µs 5.4111 µs]
Found 9 outliers among 100 measurements (9.00%)
  8 (8.00%) high mild
  1 (1.00%) high severe
spsc channel send only/crossbeam/10000
                        time:   [35.152 µs 35.220 µs 35.295 µs]
Found 12 outliers among 100 measurements (12.00%)
  3 (3.00%) high mild
  9 (9.00%) high severe
spsc channel send only/ringbuffer/10000
                        time:   [10.821 µs 10.867 µs 10.916 µs]
Found 9 outliers among 100 measurements (9.00%)
  8 (8.00%) high mild
  1 (1.00%) high severe
spsc channel send only/minitrace/10000
                        time:   [18.879 µs 18.960 µs 19.060 µs]
Found 5 outliers among 100 measurements (5.00%)
  5 (5.00%) high mild
spsc channel send only/minitrace-legacy/10000
                        time:   [32.857 µs 32.909 µs 32.960 µs]
Found 6 outliers among 100 measurements (6.00%)
  4 (4.00%) low mild
  2 (2.00%) high mild

     Running benches/trace.rs (target/release/deps/trace-f3cf9d355a8dd735)
Gnuplot not found, using plotters backend
trace_wide_raw/1        time:   [6.8527 µs 6.8810 µs 6.9124 µs]
Found 6 outliers among 100 measurements (6.00%)
  6 (6.00%) high mild
trace_wide_raw/10       time:   [47.941 µs 48.158 µs 48.396 µs]
Found 12 outliers among 100 measurements (12.00%)
  3 (3.00%) low mild
  3 (3.00%) high mild
  6 (6.00%) high severe
trace_wide_raw/100      time:   [454.32 µs 455.83 µs 457.45 µs]
Found 3 outliers among 100 measurements (3.00%)
  2 (2.00%) high mild
  1 (1.00%) high severe
trace_wide_raw/1000     time:   [4.5613 ms 4.5758 ms 4.5913 ms]
Found 3 outliers among 100 measurements (3.00%)
  3 (3.00%) high mild
trace_wide_raw/10000    time:   [46.417 ms 46.560 ms 46.715 ms]
Found 7 outliers among 100 measurements (7.00%)
  6 (6.00%) high mild
  1 (1.00%) high severe

trace_wide/1            time:   [7.0159 µs 7.0527 µs 7.0920 µs]
Found 10 outliers among 100 measurements (10.00%)
  4 (4.00%) low mild
  5 (5.00%) high mild
  1 (1.00%) high severe
trace_wide/10           time:   [48.297 µs 48.577 µs 48.853 µs]
Found 1 outliers among 100 measurements (1.00%)
  1 (1.00%) high mild
trace_wide/100          time:   [457.97 µs 459.65 µs 461.45 µs]
Found 4 outliers among 100 measurements (4.00%)
  3 (3.00%) high mild
  1 (1.00%) high severe
trace_wide/1000         time:   [4.5952 ms 4.6177 ms 4.6411 ms]
trace_wide/10000        time:   [46.449 ms 46.679 ms 46.923 ms]
Found 4 outliers among 100 measurements (4.00%)
  4 (4.00%) high mild

trace_deep_raw/1        time:   [6.9301 µs 6.9833 µs 7.0356 µs]
Found 2 outliers among 100 measurements (2.00%)
  2 (2.00%) high mild
trace_deep_raw/10       time:   [47.949 µs 48.231 µs 48.514 µs]
Found 15 outliers among 100 measurements (15.00%)
  11 (11.00%) high mild
  4 (4.00%) high severe
trace_deep_raw/100      time:   [460.49 µs 462.08 µs 463.85 µs]
Found 6 outliers among 100 measurements (6.00%)
  5 (5.00%) high mild
  1 (1.00%) high severe
trace_deep_raw/1000     time:   [4.6269 ms 4.6557 ms 4.6877 ms]
Found 6 outliers among 100 measurements (6.00%)
  5 (5.00%) high mild
  1 (1.00%) high severe

trace_deep/1            time:   [11.591 µs 11.648 µs 11.710 µs]
Found 6 outliers among 100 measurements (6.00%)
  5 (5.00%) high mild
  1 (1.00%) high severe
trace_deep/10           time:   [47.437 µs 47.562 µs 47.722 µs]
Found 3 outliers among 100 measurements (3.00%)
  3 (3.00%) high mild
trace_deep/100          time:   [469.63 µs 472.45 µs 475.27 µs]
Found 1 outliers among 100 measurements (1.00%)
  1 (1.00%) high mild
trace_deep/1000         time:   [4.5655 ms 4.5811 ms 4.5983 ms]
Found 13 outliers among 100 measurements (13.00%)
  9 (9.00%) high mild
  4 (4.00%) high severe

trace_future/1          time:   [6.9709 µs 7.0134 µs 7.0586 µs]
trace_future/10         time:   [47.765 µs 47.991 µs 48.246 µs]
Found 5 outliers among 100 measurements (5.00%)
  5 (5.00%) high mild
trace_future/100        time:   [460.68 µs 464.18 µs 468.02 µs]
Found 1 outliers among 100 measurements (1.00%)
  1 (1.00%) high mild
trace_future/1000       time:   [4.5754 ms 4.5922 ms 4.6099 ms]
Found 1 outliers among 100 measurements (1.00%)
  1 (1.00%) high mild
trace_future/10000      time:   [46.621 ms 46.827 ms 47.046 ms]
Found 1 outliers among 100 measurements (1.00%)
  1 (1.00%) high mild

     Running unittests src/lib.rs (target/release/deps/minitrace_datadog-d5e9d76c2f46efd8)


Adding Windows Support

First pass of work needed to get Rustyline to work on Windows (addresses issue #37)
TODO

[x] Move Linux specific TTY logic to a tty module
[x] Create Windows specific TTY logic to the tty module
[x] Run existing tests on AppVeyor for pull requests and master.
[x] Update example.rs for Windows, remove ANSI escape sequences
[ ] Create Stdin module that uses ReadConsoleInputW.
Rust's stdio module uses ReadConsoleW which doesn't return any modifier key presses.

Rebasing and squashing commits....

Rust's stdio module for Windows uses ReadConsoleW which doesn't seem to return anything for CTRL or ALT keypresses.  Seems like I'll have to roll my own stdio to use ReadConsoleInputW  :cry:

Okay, @gwenn  I think I'm going to merge in your new PR into my branch but I think I'll merge the windows_support branch into master for today... I don't want to leave this branch open forever and it at least gives people basic support of rustyline on windows.


Nanosecond precision?

This package says "nanosecond precision" in the description, and API looks as if this is possible. You can't have nanosecond precision in GHC as it only support microsecond precision timeouts and delays, so the API and package description are misleading.

The main part of the package is the data type, which has nanosecond precision. You can use it via FFI with system functions that actually accept nanoseconds (e.g. clock_nanosleep). The timeout/threadDelay are just there for convenience (so that I don't have to convert to microseconds by hand), it wasn't my intention to imply that these versions have a different resolution. You can make a pull request that clarifies this point in the Control.Concurrent.Timeout documentation, I'd be happy to merge it.


Is this project active?

@samuel, is this a dead project? I notice a more active repo at go-zookeeper/zk. Are those new maintainers, or is it just a fork with more activity?

Unfortunately I have not had the time or energy to maintain this project. I can't speak to which fork is the best or most maintained, but I think it's at least important for me to make it clear that there won't be any more work on this repo. But in the interest of providing at least some path forward I've linked to https://github.com/go-zookeeper/zk


Security?

I don't see any thing about security in the Readme. what Security features are in place? Is there End-To-End encryption?

Hello @TheColonel2688, the data was protected by AES256 encryption:
Encrypt: https://github.com/miroslavpejic85/p2p/blob/main/p2pconn/SenderReceiver.cs#L234
Decrypt: https://github.com/miroslavpejic85/p2p/blob/main/p2pconn/SenderReceiver.cs#L53
Regards


Rename all the scrollable classes

Block -> BlockBody
ScrollableBlock -> Block
FixedHeightScrollable -> ScrollableWidgetList
VariableHeightScrollable -> ScrollableMixedWidgetList
BlockViewport -> MixedViewport

LGTM if you give people advance warning


Page title messed up for any index sorted in reverse

(#144750485) Would like some thoughts on this approach, perhaps there is a better way?!

Coverage decreased (-0.004%) to 88.073% when pulling 9e11427fe209d73e8cfabf02b1e45b4b0a111db3 on scottymeyers:page-title-reverse-sort-fix into 574c5986db40422653eb65ec89a2e12471f0ea48 on MushroomObserver:master.

Scott:  I'll try to look at this this weekend. (I've been out all day and will be out most of tomorrow. I usually forget to set my Slack status to Away.)

Joe


Retry networked Dockerfile commands

Codecov Report

Merging #281 into master will decrease coverage by 0.58%.
The diff coverage is 0%.

@@            Coverage Diff             @@
##           master     #281      +/-   ##
==========================================
- Coverage   33.77%   33.18%   -0.59%
==========================================
  Files           2        2
  Lines         228      232       +4
==========================================
  Hits           77       77
- Misses        151      155       +4

Impacted Files
Coverage Δ

lib/kitchen/driver/docker.rb
31.83% <0%> (-0.59%)
:arrow_down:

Continue to review full report at Codecov.

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

Closing this PR due to inactivity. Please submit a new PR if this feature is still needed. Thanks!


Make app themeable

Make colors customizable in the application.

Rather than implement complete theming support, a light and dark theme will be provided for now. This is tracked in #22.


GENERAL_NAME_get0_value function's first parameter is not const but should be const

https://github.com/openssl/openssl/blob/9fdcc21fdc9d148f78d9cd5be34030f38cc45812/crypto/x509v3/v3_genn.c#L146
The function does not modify the passed in GENERAL_NAME but it is not const. Additionally, the return type is void* when in reality all of the returned types are some form of ASN1_STRING* (I believe).

The function does not modify the passed in GENERAL_NAME but it is not const.

Sounds reasonable. Would you like to create a pull request for it? Improving the const-correctness of function arguments is usually considered a non-breaking bugfix which can be cherry-picked to the 1.1.1 stable branch (see e.g. #8945).

Additionally, the return type is void* when in reality all of the returned types are some form of ASN1_STRING* (I believe).

This is almost true, but not entirely: for example, a pointer to an OTHERNAME can be returned:
https://github.com/openssl/openssl/blob/9fdcc21fdc9d148f78d9cd5be34030f38cc45812/crypto/x509v3/v3_genn.c#L155-L156
https://github.com/openssl/openssl/blob/9fdcc21fdc9d148f78d9cd5be34030f38cc45812/include/openssl/x509v3.h#L113-L116
Apart from that, changing the return type of a public API function is a breaking change. It might not break C programs, but C++ programs for sure (because a void pointer can't be assigned to a pointer to a specific type without a cast).

Apart from that, changing the return type of a public API function is a breaking change.

... but wasn't this about constifying the input parameter a?

... but wasn't this about constifying the input parameter a?

https://github.com/openssl/openssl/issues/8973#issue-446851496 consisted of two parts. I agree w.r.t part 1, but disagree w.r.t. part 2, see my response https://github.com/openssl/openssl/issues/8973#issuecomment-494775799.

The function does not modify the passed in GENERAL_NAME but it is not const.

Additionally, the return type is void* when in reality all of the returned types are some form of ASN1_STRING* (I believe).

Heh, I guess I zeroed in on the title a bit much...

The function does not modify the passed in GENERAL_NAME but it is not const.

Sounds reasonable. Would you like to create a pull request for it? Improving the const-correctness of

@mlindner I added two labels as teaser for you ;-)

I'm prevented from creating a pull request at the moment so I won't be able to.

I'm prevented from creating a pull request at the moment so I won't be able to.

Doesn't matter. If nobody else picks the low hanging fruit, I'll do it sometimes in the next few days.

Pull request has been opened.


Fixed spelling and go vet errors

Fixed errors reported here: https://goreportcard.com/report/github.com/spf13/hugo

Thank you @derekperkins!
Merged as bac1ba4.


implement looking at multiple trials to enable stochastic models

[x] repeat stimulus_set with fixed number of repetitions
[ ] ~repeat stimulus_set with per-image repetitions~
[x] average model per-trial responses
[ ] update current benchmarks to use trials
[ ] unit-test

Majaj: ~50 repetitions
Ziemba: 20 repetitions
Rajalingham: ~2 repetitions
Cadena: “at least 2 repetitions” (if I remember in Brain-score you remove images that have NaNs so I think it leaves out only the images that had 4 repetitions but it may be worth revisiting
Kar: 44 repetitions

using 10 trials for ImageNet since that is what many model ensembles use

@tiagogmarques approved


fix: limit user full name to 255 characters

Pre-Flight checklist

[x] Migrations

[x] Migration is backwards-compatible with current production code

[x] Testing

[x] Code is tested
[x] Changes have been manually tested

What are the relevant tickets?
#1438
What's this PR do?

Limits user's full name to have a max of 255 characters
changes user name filed from Text to Char
Adds 255 character limit to user profile form on the frontend
adds a migration to trim existing full names longer than 255 characters

How should this be manually tested?

Setup on master and create an account that has a full name containing more than 255 characters
Shift to this branch, build and run the containers again, and make sure the new migration runs successfully and it trims the full name in the above point to 255 characters
Register a new account, and check that you see a validation error message for the Full Name when you enter more than 255 characters

Where should the reviewer start?

Setup on master, register an account

Screenshots
Before

After

Codecov Report

Merging #1440 (9f31f48) into main (d644e9d) will increase coverage by 3.82%.
The diff coverage is n/a.

:mega: This organization is not using Codecov’s GitHub App Integration. We recommend you install it so Codecov can continue to function properly for your repositories. Learn more
@@            Coverage Diff             @@
##             main    #1440      +/-   ##
==========================================
+ Coverage   83.11%   86.94%   +3.82%
==========================================
  Files         310      146     -164
  Lines       13278     4335    -8943
  Branches      945        0     -945
==========================================
- Hits        11036     3769    -7267
+ Misses       1970      566    -1404
+ Partials      272        0     -272

Impacted Files
Coverage Δ

...ublic/src/components/forms/EditProfileForm_test.js
100.00% <ø> (ø)

...d/public/src/components/forms/ProfileFormFields.js
77.14% <ø> (ø)

users/models.py

cms/tasks.py

mail/apps.py

ecommerce/factories.py

main/features.py

flexiblepricing/mail_api.py

conftest.py

openedx/tasks.py

... and 156 more

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

@pdpinch Could you also take a look at mostly the design part? When the user's full name was very long it would break the UI. The issue was noted in https://github.com/mitodl/mitxonline/issues/1438. In this PR I have limited the display limit of the name to 40 characters at max with extra text to use an ellipsis (Screenshot attached in PR description).
Let me know what you feel about this.

In this PR I have limited the display limit of the name to 40 characters at max with extra text to use an ellipsis

This is a good approach. How did you decide on 40 characters?
How many characters are visible when the user sets their full name in the profile form?

In this PR I have limited the display limit of the name to 40 characters at max with extra text to use an ellipsis

This is a good approach. How did you decide on 40 characters?

This limit seemed reasonable enough and looked fine. How this looks with 40 characters, There is a screenshot in the PR description. We can change this too, let me know if you want to try some other limits and i can get their screenshots for you.

How many characters are visible when the user sets their full name in the profile form?

In the profile form, all the characters would be visible, The display change only affects the name in the header.

The name in the profile form looks like below and it's horizontally scrollable within the field, if that's what you meant in your question.


[Colored Container Tab] Border color for unselected tab

Hey,
On my side the border only appears when a tab is selected (see screenshots). I was wondering if this was the correct behaviour or an issue with my setup ? I already tried disabling all other mods but nothing changed.
The GitHub tab is selected and correctly has the border :

The GitHub tab is not selected and no longer has the border :

Use the code below in userChrome
#tabbrowser-tabs {
& .tabbrowser-tab {
.tab-background {
border: 2px solid var(--identity-icon-color) !important;
opacity: 0.8 !important;
}
}
}

Use the code below in userChrome.css
#tabbrowser-tabs {
& .tabbrowser-tab {
.tab-background {
border: 2px solid var(--identity-icon-color) !important;
opacity: 0.8 !important;
}
}
}

& remove the mod from zen mod store. Or, you can also edit the mod file, go to profile folder>chrome>zen-themes> edit "3ff55ba7-4690-4f74-96a8-9e4416685e4e", Delete existing code & paste this,
#tabbrowser-tabs {
& .tabbrowser-tab {
.tab-background {
border: 2px solid var(--identity-icon-color) !important;
opacity: 0.8 !important;
}
}
}

Or remove the mod & put the code in userChrome.css
#tabbrowser-tabs {
& .tabbrowser-tab {
.tab-background {
border: 2px solid var(--identity-icon-color) !important;
opacity: 0.8 !important;
}
}
}

Thanks you very much, I managed to make it work !
For documentation purpose, the following code was also necessary to hide the line from Zen itself :
.tab-context-line{
	display: none !important;
}

An improvement could be adding the same behaviour for pinned tabs but I'm not sure how much you want to maintain the mod. It's not a big issue and it doesn't bother me as is.


ILI9486 (Waveshare 3.5-inch (B)) support

The following additions, primarily to device.py are working for me when using this ILI9486-based display:
https://www.waveshare.com/3.5inch-rpi-lcd-b.htm
attached directly to the GPIO header of an RPi4 Model B.  That particular display (or the controller) wants to run in portrait mode, 320x480.  Rotation is thus necessary to use it as 480x320.  (I was stuck for quite a while getting an odd display trying to use it in landscape mode.)
The various demos within luma.examples all seem to be happy, using either full_frame or the diff algorithm to update the framebuffer.  Some misc observations:

I've run the bounce.py demo with a SPI bus frequency up to 50 MHz, achieving ~23 fps.  Performance does still scale with SPI bus frequency.

The pi_logo.py demo also runs at such high frequencies, but the rendered colors end up being incorrect.  The leaves on the Pi logo end up being orange instead of green!  Slowing down to 32 MHz gets the colors correct.  (Animation speed is still quite good at that SPI frequency using the diff algorithm.)

Interestingly, the gradient example within colors.py is still unhappy even at 32 MHz.  Even though the rest of that example, including the opening photo and the rainbow screen, all look fine, the gradient screen ends up with artifacts suggesting bad data transfer.  Slowing down to 28 MHz, the gradient screen looks perfectly normal (photos below).

Thanks,
Matt
fixes #135
Gradient screen from colors.py @ 32 MHz

Gradient screen from colors.py @ 28 MHz

Nice!
Out of interest, have you tried the Linux framebuffer driver with this display?
To get this PR through we ought add some simple regression tests and update the documentation

... and probably convert the CI from Travis to GitHub actions (in another PR) beforehand

... and probably convert the CI from Travis to GitHub actions (in another PR) beforehand

See #137

Out of interest, have you tried the Linux framebuffer driver with this display?

Yes, I first tried out the display via the repository that Waveshare provides:
https://github.com/waveshare/LCD-show.git
I didn't use their shell scripts, but inspected what overlay they make use of and loaded it myself.  The dtoverlay uses a compatible string of ilitek,ili9486 with these addition parameters:
            waveshare35b@0 {
                compatible = "ilitek,ili9486";
                reg = <0x00000000>;
                pinctrl-names = "default";
                pinctrl-0 = <0x00000001>;
                spi-max-frequency = <0x00e4e1c0>;
                txbuflen = <0x00008000>;
                rotate = <0x0000005a>;
                bgr = <0x00000000>;
                fps = <0x0000001e>;
                buswidth = <0x00000008>;
                regwidth = <0x00000010>;
                reset-gpios = <0xffffffff 0x00000019 0x00000001>;
                dc-gpios = <0xffffffff 0x00000018 0x00000000>;

in addition to an array of init bytes.  The spi-max-frequency above is 15 MHz.   The overlay file looks to be identical to the GPL-licensed one at
https://github.com/TobiasVanDyk/RaspberryPi-GPIO-Displays/blob/master/ili9486/Waveshare/waveshare35b-v2.dts
(The relationship between that github repository and Waveshare's is unclear to me.)
The luma.examples work fine via linux_framebuffer, with bounce achieving >20 fps when using the diff algorithm.  The combination of luma.core's diff algorithm with whatever approach the device driver is taking for updates leads to a fair amount of tearing.  Using full_frame, bounce gets 6.2 fps through the framebuffer.
Using luma.lcd directly at 50 MHz (a frequency that is certainly questionable for this display), bounce is achieving 5.3 fps with full_frame and 19 to 23 fps with diff.  There's much less tearing, though! :)

To get this PR through we ought add some simple regression tests and update the documentation

I'll take a look at what the tests require.  Since the tests presumably run without actual display hardware, are they just performing some sanity checks?  The ili9486 addition mimics the structure of the ili9341 support identically.
My chief concern is that other ili9486 displays may not have the 16-bit registers of the particular Waveshare that I have.  Looking around github at other (open license) implementations for ili9486 support, the byte padding only gets mentioned in conjunction with Waveshare.  That would seem straightforward to support -- use a conditional to control whether padding gets added or not -- but that conditional would be unique to the ili9486.  I also have no means of HW testing it.

Any hints on how one runs tests?  I'm still relatively new to Python development, and the amount of infrastructure around Python projects is impressive.  That said, I don't know how to run much!

@mattblovell from repo checkout directory:
tox -e py37

or py38 or whatever version you're using.

I tend to develop luma code & run tests on a Mac or desktop Linux machine rather than on an RPi. It was often painfully slow - certainly on RPi 2B, but might be better now on 4B

Also, I can help out with the tests. We can mostly do a cut’n’paste job from ili9341

Also, I can help out with the tests. We can mostly do a cut’n’paste job from ili9341

That would be most appreciated!  I'll see if I can free up some time tonight to try out tox (per @thijstriemstra's reply above), but I don't necessarily know what I'm doing with the test infrastructure.

I double-checked that the padding zeros are indeed needed for the Column Address Set (0x2A) and Page Address Set (0x2B) commands within ili9486.display().  Removing any of the zero padding (either after the command or those in between any of the command's parameters) results in the diff_to_previous algorithm not getting drawn correctly on-screen.
"Armed" with that information, I thought I would reexamine the positive and negative gamma settings for ili9486 in both juh/fbcp-ili9341 and ImpulseAdventure/Waveshare_ILI9486.  Adding the commands with byte pads just yields terrible colors -- blues and purples end up with really bad saturation.
Dumping the initialization bytes from the dtoverlay that Waveshare makes available and pulling the gamma correction from those, colors seem fine but don't appear noticeably different than what the display uses without any gamma controls specified.
The Waveshare overlay is using 18-bit colors, which matches the initialization I'm trying (via Memory Access Control, 0x36).  The other two repositories are only set up for 16-bit colors.  Perhaps that explains the difference.
Anyway, just thought I'd explore the gamma settings a bit further.

I think I have the entries in test_ili9486.py working.  I only have one screen size (full) supported.
tests/test_ili9486.py::test_init_320x480 PASSED                                                                    [ 56%]
tests/test_ili9486.py::test_init_invalid_dimensions PASSED                                                         [ 58%]
tests/test_ili9486.py::test_offsets PASSED                                                                         [ 60%]
tests/test_ili9486.py::test_contrast PASSED                                                                        [ 61%]
tests/test_ili9486.py::test_hide PASSED                                                                            [ 63%]
tests/test_ili9486.py::test_show PASSED                                                                            [ 64%]
tests/test_ili9486.py::test_display_full_frame PASSED                                                              [ 66%]

Execution time for tox -e py37 on an RPi4:
real    0m14.644s
user    0m9.499s
sys     0m1.141s

I don't immediately know why the Python 3.8 tests are unhappy.

I don't immediately know why the Python 3.8 tests are unhappy.

Ah, linting woes.  I like blank lines, though!  :)
I'll try to then that up...

FYI, you can run tox -e qa to run the PEP8 and documentation checks, and usually flake8 can be used to auto format (we should probably have a tox target that does this)

I’ve got one of these on order now because of you!

Excellent!  Hopefully it even works! 😄
Did you get the Waveshare one or a different ILI9486-based one?  I have to say that the IPS panel is a nice feature.

Great!
I'm very glad to contribute back to luma.lcd.  The excellent documentation for this project, and the breadth of supported displays, is what encouraged me to give these little LCD displays a try in the first place.  I've learned a lot since September.

v2.8.0 released with this in :rocket: https://pypi.org/project/luma.lcd/2.8.0/

16-bit

RE: 16-bit registers, I just found this : https://github.com/torvalds/linux/blob/master/drivers/gpu/drm/tiny/ili9486.c#L38


added calculator.py

I have added a full working calculator to hooman/demon folder.

Hi @TheBigKahuna353,
I'm really sorry i have mistaken the context and just created a calculator demo with out using hooman. I have made changes to the calculator.py by using hooman and rasied a PR-https://github.com/Abdur-rahmaanJ/hooman/pull/73. please review and merge it.
Thanks in advance.


Error (exit code 1): Inference failed

Hello - I am trying to upload this behavioural-cloning-baseline without any modifications to AICrowd to see if it works, but I keep getting this error "inference failed" without further error descriptions.

I have followed the instructions in https://github.com/minerllabs/basalt_2022_competition_submission_template/ but changing the github repository to be this one instead of the submission template. When I tried the same with the submission template it worked so this probably has something to do with the differences between the submission template and this repo.
Could you direct me please to how I can diagnose this problem further?

Hey. Did you train and upload the trained models as part of the submission? To submit this baseline solution, you need to locally train the models, add them to the git, upload them to the server and then do the submission.

Ohh that explains! Thank you.

Ah, so you need to (and can) upload a big model as part of your submission: this is ran on the server right away and result is uploaded on the leaderboard. Then during training phase (after submissions close), we will remove all big files and presubmitted models, and run the training code instead to train the models, and test those models to see if the resulting behaviour is similar as when you originally submitted the submission.

I see! Thank you for the clarification!

Wait - I can't push these large files via git because it exceeds GitHub's file size limit of 100MB.. What should I do?

Wait - I can't push these large files via git because it exceeds GitHub's file size limit of 100MB.. What should I do?

You need to use git LFS for that. See these instructions.

Hello again! I was able to upload the files, and the BuildVillage challenge succeeded, but the other tasks failed. I saw that there was an update to this behavioural cloning baseline repo yesterday (where there was a change in the model used for the BuildVillage task) so I pulled that change, and that made all tasks fail. Judging from this, I was speculating that the 2x.model is not available in the data directory of the server, while the foundation-model-1x.model is. Is this the case?
Related to this, can we use data/VPT_models/... in the code, or are we supposed to do os.path.join(os.environ.get('MINERL_DATA_ROOT'), "VPT_models", "...") ? In the examples given, the data directory seems to be hardcoded as data/VPT_models/... but in the README it looks like the data directory on the server is at a different path, given as MINERL_DATA_ROOT so I was confused.

By the way, I tried replacing all instances of 2x.model with foundation-model-1x.model and the inference worked:) So I'm guessing that if I want to use the 2x.model I have to commit that to git? But then I thought this is already provided in the server..

Ah - I guess the failure was because I trained my models a couple of days ago when the train.py was using the foundation-model-1x.model as a base, but since then there was an update and now it is assumed that the weights are for 2x.model but I still had weights for the foundation model. :P

So I guess the only question I have is:

Can we use data/VPT_models/... in the code, or are we supposed to do os.path.join(os.environ.get('MINERL_DATA_ROOT'), "VPT_models", "...") ? In the examples given, the data directory seems to be hardcoded as data/VPT_models/... but in the README it looks like the data directory on the server is at a different path, given as MINERL_DATA_ROOT so I was confused.

Oh! And upload failed with the error message
Upload: Error (exit code 1): open /mainctrfs/outputs/score.json: no such file or directory

Yup the code was updated! Sorry for the confusion ^^. I should have maybe defaulted it to the original behaviour. My mistake.

Can we use data/VPT_models/... in the code

I would recommend using the MINERL_DATA_ROOT variable: it allows us on the backend side change the data location if for some reason we need to. Buuuut generally you can assume data is the location where things are stored.

Upload: Error (exit code 1): open /mainctrfs/outputs/score.json: no such file or directory

Hmm where/when did this happen? I do not regocnize the error

Thank you so much for your responses - really appreciate all your hard work!!
This specific error happened after the inference stage and during the upload stage. At some point it said upload in progress and I was able to see the green circles under the "Evaluation Status", but then it failed with this error and the green circles also disappeared.

@shuishida Ah, this might have been a random crash which occured as we were tuning the system... Feel free to try submitting again, although for a debug submission, it did pass; it just failed at the final internal steps 🙃 . If you can share link to the submission issue page I can dig deeper into things.
(PS: we generally answer faster on our Discord server, but I will continue to monitor these github pages!)