Remove #[deny(warnings)] from generated code

This declaration causes errors when using cargo doc, since some doc comments include lines that give doc warnings. This doesn't prevent the crate from building, so it's easy for these doc comment warnings to slip through to releases. However, because of this line (which can't be disabled later on), doc comment warnings are treated as errors and prevent documentation for the generated crate from building, as well as any other crate that depends on the generated crate.
For example, the nrf51 crate is generated with svd2rust. This line causes the docs in that crate to error when building. The nrf51-hal crate depends on nrf51, and so it's docs don't build either. The microbit crate depends on nrf51-hal, so it's docs don't build either. Finally, any other crate that depends on any of those can't build docs. This makes it extraordinarily difficult to program using any of these crates.
For more detailed information about the above case, check out therealprof/nrf51#3.

Since removing the #[deny(warnings)] attribute removes wanted functionality in some cases, it can be substituted with either of the following invocations of cargo:
> RUSTFLAGS="-D warnings" cargo build
> cargo rustc -- -D warnings

Like the linked issue says, perhaps we could (additionally) escape [ and ] in generated doc strings to avoid the warning altogether.

I agree that escaping in doc strings is a smart improvement to make, if only to reduce the number of warnings when compiling documentation.

I'm not sure about this, please correct me if I'm wrong. However, I was under the impression that #[deny(warnings)] is problematic in libraries due to adding warnings in rustc is not considered a breaking change. Meaning that it's impossible to guarantee that the library will continue building for newer versions of rustc.

@kjetilkjeka You are correct; see here: https://github.com/rust-unofficial/patterns/blob/master/anti_patterns/deny-warnings.md.

Hey all,
This seems like an overall reasonable change. I believe the "deny warnings" was generally an attempt to catch subtly-incorrect code generation, though @japaric  will have to have the final word on its historical usage.
If @japaric doesn't object, I would suggest modifying the CI to take advantage of one of the options @cgm616 suggested in https://github.com/japaric/svd2rust/pull/229#issuecomment-405033399, so that we can at least retain this at CI time, and remove it from regular usage.
Thanks for the comments and contribution!

I think we have two ways of resolving this:

Fix CI scripts according to the discussion. @cgm616, could you update your PR?
Close PR and leave everything as is. New warnings can be fixed on a regular issue/PR basis.

cc @japaric @jamesmunns

@Disasm

2. Close PR and leave everything as is. New warnings can be fixed on a regular issue/PR basis.

New warnings would have to be fixed in every single svd2rust-generated crate. #[deny(warnings)] is an antipattern and needs to go, no doubt about it.

Note that almost all (*) warnings that come from crates.io (**) dependencies are ignored (silenced) in Cargo builds, regardless of whether that dependency has #![deny(warnings)] in it or not. This is done exactly because of Rust stability promise ("building a crate with a newer stable release should always work").
(*) the exception are warnings related to soundness issues. In that case you will always get the warning but #[deny(warnings)] will not turn the warning into an error.
(**) this doesn't apply to path dependencies since you can modify the source and fix the warning.
What happened with cargo doc (more specifically with rustdoc) in this particular case was a bug that affected nightly and was fixed in nightly. Bugs that affect the statement in my first paragraph are considered high priority (release blocking) bugs and will be fixed before they reach stable.
With that out of the way, if you want to remove #[deny(warnings)] from the generated code go for it. I have no strong opinions on the matter and would prefer not to participate in such discussion.

@cgm616 Please fix the conflicts.

Just updated the CI scripts; I think I got all of them.

Thanks! Howerver, you removed #[deny(warnings)] from svd2rust generated code, not from svd2rust itself: you need to use -D warnings in places, where CI checks the code generated by svd2rust. Here is one of them: https://github.com/rust-embedded/svd2rust/blob/116a125d45c4c6dd7229c44c203fa218310c8c63/ci/script.sh#L13-L19
You may need to git-rebase your changes to cover all of the places.
Generated code is also cargo-checked in the regression tests:
https://github.com/rust-embedded/svd2rust/blob/116a125d45c4c6dd7229c44c203fa218310c8c63/ci/svd2rust-regress/src/svd_test.rs#L164-L169
They probably also need to be patched, but I'm not sure.

@cgm616 Sorry for the delay. Would you still be interested in addressing this? Please update the PR in this case.

@cgm616 Ping? Probably the best to close this and start over.

Sorry about this, I've been super busy lately. I'd still like to do this, so I'll close this PR and in the next week or so I'll try and open another.


Is this supposed to work on Elixir v1.3.2 ?

I'm getting

** (Mix) Could not start application sublime_completion: exited in: SublimeCompletion.start(:normal, [])
    ** (EXIT) an exception was raised:
        ** (ArgumentError) argument error
            :erlang.binary_to_integer(nil)
            (sublime_completion) lib/sublime_completion.ex:11: SublimeCompletion.start/2
            (kernel) application_master.erl:273: :application_master.start_it_old/4

running iex -S mix on the sublime_completion folder.

It's not supposed to work in the console, I guess! I ended up using @YurkoHoshko fork


Unable to understand issue with management tool

taking more than needed time (15 min)

I am using the following command
sudo docker run -it --rm -p 9000:5000 --name arrowhead-react-container -e REACT_APP_ARROWHEAD_SR_URL=http://<IP_ADDRESS>:8442 -e REACT_APP_ARROWHEAD_ORCH_URL=http://<IP_ADDRESS>:8440 -e REACT_APP_ARROWHEAD_GK_URL=http://<IP_ADDRESS>:8448 svetlint/arrowhead-react
and i am getting error with respect to xsel binary now though I have increased the RAM size and did installed xsel. Attached image will give you brief detail about the issue.

solved

Hi, how did you solved it? Having the same issue

Hello!
What is your server/VM configuration?


Selenium window size arguments not working

Hi guys, thanks for the middleware
I have a problem with setting window size , I want to have mobile version of a website but setting user-agent is not enough, but it works when I use Selenium with set_window_size .
Probblem is when I use scrapy-selenium there is no way to use set_window_size selenium command, I tried setting arguments on the settings.py but not working:
SELENIUM_DRIVER_ARGUMENTS=['-window-size=375x667', '-headless']
Any idea how to fix that

--window-size=375,667


OpenGL rotation to Portrait stretches and scales stream

I am using the repo as a library for a flutter project. If I rotate with OpenGL to stream as Portrait instead of landscape, the streamed image doesn’t match the preview. The received video is cropped and streched. I have ensure that the resolution of the preview and stream is the same as the native resolution. I am using a Galaxy tab A8.
Does anyone knows how to fix this issue?

Hello,
I'm not sure what do you mean but using keepAspectRatio in xml like here should fit screen without deform image using black borders or cropping depend if you use adjust or fill aspectRatioMode. You have examples in the demo app:
https://github.com/pedroSG94/rtmp-rtsp-stream-client-java/blob/master/app/src/main/res/layout/activity_open_gl.xml#L12
If you only have problems using flutter. I never tested using flutter so I'm not sure about it.


Publish to Unity Asset Store

I'd like to make this package as easy as possible for people to include in their projects. I'll publish it for free as soon as it's ready.

Are these todos being closed because they are complete or a change of mind?

at least now in 2020 it starts to be possible to make it a package for the package manager


Use helm repo when installing cf-operator

The cf-operator has a helm repo at https://cloudfoundry-incubator.github.io/quarks-helm/.
Please update documentation and such, to use that repo, instead of S3.
ping @fargozhu
#171741424

@manno we are deploying cf-operator from the kubecf bundle which contains the cf-operator version supported on that specific kubecf release.
@f0rmiga would make sense to pull cf-operator from helm repo instead of s3 bucket?


Report a lost/stolen passport abroad

https://trello.com/c/LXA2O1YN/2006-26-feb-changes-to-cancelling-a-lost-stolen-passport-overseas
I've made 2 changes:

updated the first question to ask where the user is rather than where the passport was lost
updated the content for the abroad outcome as it's now the same for all overseas countries

In addition to the content changes, it also needs a logic change to remove the question 'In which country': https://www.gov.uk/report-a-lost-or-stolen-passport/y/abroad
The content changes are currently with HMPO to fact check.


Add absent repounits to create/edit repo API

Adds the ability to enable/disable Actions, Packages and Releases from the API, via the Edit and Get Repository API endpoints.

Thanks for this PR <3 I've merged in the latest commits from main as they include some changes to the CI pipeline


vis2x.: Input field CSS too small

Describe the bug
Input field CSS too small
Expected behavior
CSS input field has same height as screen.
Screenshots & Logfiles

Versions:

Adapter version: ioBroker.vis v2.0.9
JS-Controller version: v4.0.23
Node version: v16.18.1
Operating system: ioBroker.docker v7.2.1
Browser: Google Chrome v107.0.5304.122 (64-Bit)

Hello @ice987987 , please check with 2.0.10

works as expected in v2.0.10
thank you very much!


BCMOHAD-16836 || Updated from Api calls from GET to POST

Deployment Tracker:
Updated the API from GET to POST
Changes:
Classes:
ODRIntegration.cls
ODRIntegrationTest.cls

Closing this PR due to the Omnistudio Build check issue


bug(windows client aarch64): "Firezone signed in" notification not appearing

Describe the bug
Looks like we are calling into tauri_winrt_notification but it's not doing anything, at least on aarch64.
Git  535a61e2a130 works fine on x86_64 and doesn't work on aarch64. I'll mention it to the Tauri notifications repo but it's not a blocker for us since we don't officially support Windows aarch64 yet.
To Reproduce
Run Firezone 1.0.0-pre.10-66-g869bf2407 (Git 869bf2407) debug build on Windows 11 aarch64. When you sign in, there's no notification.
Expected behavior
Expected a "signed in" notification near the tray icon when I sign in or when it auto signs in at startup.
Screenshots / Logs

Platform (please complete the following information)

Component (i.e. macOS client / Linux client / Gateway / Admin portal): Windows Client
Firezone Version (e.g. 1.0.0 or N/A): 869bf2407
OS and version: (e.g. Ubuntu 22.04 or N/A): Windows 11
Deployment method: (e.g. Docker / Systemd / App Store or N/A): cargo build -p firezone-gui-client

Additional context
It's running in Parallels on the Macbook so it may be that our notifications dep doesn't work in aarch64?

Since it only affects aarch64 I'll make a PR to comment that and then close this as not-planned

Won't fix, aarch64 Windows can wait and the PR documents it as a known issue in a code comment.


KYLIN-4080 Project schema update event casues error reload NEW DataModelDesc

Can one of the admins verify this patch?

Can one of the admins verify this patch?

Codecov Report

Merging #976 into master will decrease coverage by 0.01%.
The diff coverage is 28.57%.

@@             Coverage Diff              @@
##             master     #976      +/-   ##
============================================
- Coverage     25.43%   25.42%   -0.02%
- Complexity     6148     6149       +1
============================================
  Files          1414     1414
  Lines         85698    85702       +4
  Branches      12021    12021
============================================
- Hits          21801    21793       -8
- Misses        61776    61786      +10
- Partials       2121     2123       +2

Impacted Files
Coverage Δ
Complexity Δ

.../apache/kylin/rest/controller/ModelController.java
0% <0%> (ø)
0 <0> (ø)
:arrow_down:

.../apache/kylin/metadata/model/DataModelManager.java
26.6% <22.22%> (+1.15%)
9 <0> (ø)
:arrow_down:

...org/apache/kylin/metadata/model/DataModelDesc.java
59.25% <50%> (-0.1%)
72 <1> (+1)

...che/kylin/stream/core/storage/CheckPointStore.java
63.63% <0%> (-3.04%)
21% <0%> (-1%)

...he/kylin/job/impl/threadpool/DefaultScheduler.java
74.41% <0%> (-2.33%)
12% <0%> (ø)

.../apache/kylin/cube/cuboid/TreeCuboidScheduler.java
63.84% <0%> (-2.31%)
0% <0%> (ø)

...rg/apache/kylin/cube/inmemcubing/MemDiskStore.java
69.3% <0%> (-1.52%)
7% <0%> (ø)

...org/apache/kylin/rest/util/QueryRequestLimits.java
40.47% <0%> (+4.76%)
6% <0%> (+1%)
: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 2fb10b0...e037522. Read the comment docs.

Pull Request Test Coverage Report for Build 5333

5 of 14 (35.71%)  changed or added relevant lines in 3 files are covered.
4 unchanged lines in 2 files lost coverage.
Overall coverage decreased (-0.0001%) to 27.91%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

server-base/src/main/java/org/apache/kylin/rest/controller/ModelController.java
0
1
0.0%

core-metadata/src/main/java/org/apache/kylin/metadata/model/DataModelDesc.java
2
4
50.0%

core-metadata/src/main/java/org/apache/kylin/metadata/model/DataModelManager.java
3
9
33.33%

Files with Coverage Reduction
New Missed Lines
%

core-cube/src/main/java/org/apache/kylin/cube/cuboid/TreeCuboidScheduler.java
2
68.46%

stream-core/src/main/java/org/apache/kylin/stream/core/storage/CheckPointStore.java
2
73.74%

Totals

Change from base Build 5320:
-0.0001%

Covered Lines:
23919

Relevant Lines:
85702

💛  - Coveralls


Added require_patch decorators

Hi Mentors :)
Regarding the suggested revisions by Umair, I made this decorator for #2853 and #2858.

Automated message from Dropbox CLA bot
@Juanvulcano, it looks like you've already signed the Dropbox CLA. Thanks!

#2829 Might also need this

You will need some tests as well. Auth code is a serious business :).

Hold on this. Probably not needed.

I'll close this then :) Thanks Umair!


Integrate UPF feature and tests

Summary
Integrate the firecracker snapshot UPF features and enable UPF tests.
Implementation Notes :hammer_and_pick:

Enable UPF features and tests, refer to b6bfcbb7c6679fce46bbf69ddf2dc79dba759b8a
Update firecracker-containerd image default-rootfs.img
Update firecracker-containerd version
Update kernel image firecracker-containerd used

External Dependencies :four_leaf_clover:

https://github.com/char-1ee/firecracker-containerd/tree/firecracker-v1.4.1-vhive-integration

Breaking API Changes :warning:

NA

Simply specify none (N/A) if not applicable.

@char-1ee  Please fix the errors reported by the CI.
@Ruiqi please assist with the runners if necessary. The kubectl error in the integration tests is strange

@lrq619

Hi @char-1ee I've already re-launched the runners, they should work fine now. But your codes still fail to pass these tests, please double check your codes and re-run the failed tests untill all of them are passed.


png_loader.h seems loading 16-bit alpha grayscale incorrectly

png_loader.h, which has functions called for load_png() , contains the following code for loading 16-bit grayscale png:
else if (is_graya() && bit_depth_ == 16)
            {
                for ( unsigned n = 0; n < height_;n++ )
                {
                    const uint16* v = (uint16*)get_row( n );
                    for ( unsigned m = 0; m < width_; m++ )
                    {
                        dlib::uint16 p = v[m*2];
                        if (!pixel_traits<pixel_type>::has_alpha)
                        {
                            assign_pixel( t[n][m], p );
                        }
                        else
                        {
                            dlib::uint16 pa = v[m*2+1];
                            rgb_alpha_pixel pix;
                            assign_pixel(pix, p);
                            assign_pixel(pix.alpha, pa);
                            assign_pixel(t[n][m], pix);
                        }
                    }
                }
}

But rgb_alpha_pixel  according to pixel.h is
unsigned char red;
unsigned char green;
unsigned char blue;
unsigned char alpha;

So when I'm loading the image where all the values are multiplied by 255, save_png then saves empty white output.
I've seen that is_rgb() && bit_depth_ == 16 is converted to 8-bit below, so if 16-bit is totally unsupported (is it so?) then the code above can also convert to 8-bit (matrix<rgb_alpha_pixel> works fine for me for storing grayscale images).
Or am I missing something about it? Maybe first dividing by 255 will be better than just static_cast<uint8> as done below?
The reason of asking is that I'm writing serializer to receive images from Python as I use NN face extractor and this interface seems not supported in Python:
template <long num_filters, typename SUBNET> using con5d = con<num_filters,5,5,2,2,SUBNET>;
template <long num_filters, typename SUBNET> using con5  = con<num_filters,5,5,1,1,SUBNET>;

template <typename SUBNET> using downsampler  = relu<affine<con5d<32, relu<affine<con5d<32, relu<affine<con5d<16,SUBNET>>>>>>>>>;
template <typename SUBNET> using rcon5  = relu<affine<con5<45,SUBNET>>>;

using net_type = loss_mmod<con<1,9,9,1,1,rcon5<rcon5<rcon5<downsampler<input_rgb_image_pyramid<pyramid_down<6>>>>>>>>;

net_type net;

Yeah, it should probably divide the values by 256 before converting to 8bits.  You can submit a pull request for that if you want :)

What's about 16-bit images? I found that only non-alpha grayscale is possible, others are converted to 8-bit then.

Right.  There isn't a 16bit pixel type in dlib for this.  You could add one
if you want but you will need to expand the pixel_traits type appropriately
along with the core routines like assign_pixel().

Here is my wrapper so far, now I'm able to send data from Python to NN code, maybe you will be interested (it is very simple though):
https://github.com/hcl14/Python-Cpp-send-image-to-dlib-as-array
However I haven't found so far methods that allowed sending arbitrary image array (int * in this case) to dlib. It also contains my view of how the load_png function should be changed.


Downloading Invoices failing

I had invoice downloading on one project working then decided to rewrite whole project over in new folder and new eviroment. When I try to do downloadInvoice() on either project, I get the following.
at HandleExceptions->handleError(2, 'A non-numeric value encountered', '/ignite/vendor/dompdf/dompdf/src/FrameReflower/Table.php', 577, array('style' => object(Style), 'columns' => array(array('x' => 0, 'min-width' => 163.0, 'max-width' => 163.0, 'used-width' => null, 'absolute' => 163.0, 'percent' => 0, 'auto' => false), array('x' => 0, 'min-width' => 154.494, 'max-width' => 276.219, 'used-width' => null, 'absolute' => 0, 'percent' => 0, 'auto' => true)), 'i' => 1, 'dims' => array(0, 0, '0', '0', 'auto', 'auto', '2px'), 'delta' => 'auto')) in Table.php line 577

Having the same problem in my Spark application.
Please fix ASAP..

Same issue here, my client's currently can't download their invoices. Using the Braintree package.
@taylorotwell Anyone working on this?

Maybe some dompdf issues?

Should be fixed with the newest Cashier release. Have installed the dev-master branch and it's working perfectly.

@fwartner Is there any way to pay a sigle charge (not subscription) without the user beeing a subscriber? Seems it asks for it and in some cases you might only want single payments.

$user->charge('amount'); should work I guess

If i'm not wrong it asks for the user to be a customer already (and in fact it must) but that function does not require the stripe token, so it must be added manually i guess to the user's table... the sub method have a ->create($token) and that makes the deal!
Do you think (i haven't tried it) that ->charge($ammount)->create($token) would work?

I would refer to the docs ^^

It's a dompdf issue and it's fixed in v0.8.0, cashier needs to update to that version.

Should be fixed in the latest version.


memtest86-efi: 8.4 -> 9.3.1000

Things done

Built on platform(s)

[x] x86_64-linux

[x] Tested basic functionality of all binary files (usually in ./result/bin/)
[x] Fits CONTRIBUTING.md.

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:
https://discourse.nixos.org/t/should-ipfs-be-used-as-a-source-for-fetchurl-in-nixpkgs/16312/1

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:
https://discourse.nixos.org/t/should-ipfs-be-used-as-a-source-for-fetchurl-in-nixpkgs/16312/3

FYI - It looks like memtest86-efi is broken on stable now. Maybe this should be backported.


Implement metrics pusher as hosted service

@sanych-sun Run run-me.sh, it will do some cleanup.

@sanych-sun I did some cleanup before merge. We can discuss later about.


Bottom of characters are getting cut off in composition view

#25339

VSCode Version: Code - Insiders 1.12.0-insider (48ae6e3027be560d45dd1ebfbe090d6ff77af7f0, 2017-04-26T06:32:53.505Z)
OS Version: Linux x64 4.10.0-19-generic
Extensions:

Extension
Author
Version

EditorConfig
EditorConfig
0.9.3

lorem-ipsum
Tyriar
1.0.0

sort-lines
Tyriar
1.2.0

theme-sapphire
Tyriar
0.1.0

vscode-svgviewer
cssho
1.4.0

tslint
eg2
0.12.0

git-project-manager
felipecaputo
1.3.2

md-navigate
jrieken
0.0.1

vscode-scss
mrmlnc
0.6.2

seti-icons
qinjia
0.1.3

안:

@Tyriar I could not reproduce on OSX and I failed to configure CJK input method on Ubuntu (I gave up after 10 minutes and 5 reboots).
Can you please help me reproduce?

Seems to be fixed, at least on Ubuntu 18.04


Remove ca_file option in Kiali operator CR

Kiali has moved away from the deprecated service serving interface. The
Kiali operator is providing good defaults for ca_file in OpenShift, so
it's no longer needed that maistra operator specifies these options.

I'll see if I can try this.

I had no luck trying this. The reconciliation of smcp fails.
So, I'm promoting this as is and leaving testing to the maistra team.

cc @rcernich

/ok-to-test
Hi @israel-hdez, this will require a ticket in the MAISTRA project on Jira

@dgn Ticket is https://issues.redhat.com/browse/MAISTRA-1719
Hmm... I see CI issue.
I understand that first, I need to update both maistra-1.0 and maistra-1.1 branches with these changes.
I'll create those PRs.

@israel-hdez Can you please run make gen on this?

This was implemented in 529.


Flag -k/--reset-cache does not work in a pre-commit hook

Describe the bug
Flag -k/--reset-cache does not work in a pre-commit hook.
To Reproduce
I don't know how to reproduce the state when it's passing all the checks when --reset-cache not used, but fails when the --reset-cache is used. For me it happened somewhere after I changed/created a file, committed it and pre-commit hook run automatically and passed (having --reset-cache), but then it failed in CI/CD pipeline where --reset-cache flag is working properly.
Expected behavior
Flag -k/--reset-cache does should work in a pre-commit hook.
Actual behavior
.pre-commit-config.yaml
  - repo: https://github.com/tconbeer/sqlfmt
    rev: v0.17.0
    hooks:
      - id: sqlfmt
        name: Format SQL
        description: Format SQL using sqlfmt
        entry: sqlfmt
        args:
          - --check
          - --reset-cache
          - dbt_projects
        language_version: python3.9

> sqlfmt --check dbt_projects
174 files passed formatting check.

> sqlfmt --check dbt_projects --reset-cache
1 file failed formatting check.
173 files passed formatting check.
dbt_projects/[...].sql failed formatting check.

> pre-commit run --all -v
Format SQL...............................................................Passed
- hook id: sqlfmt
- duration: 1.96s

174 files passed formatting check.

Additional context
What is the output of sqlfmt --version?
sqlfmt, version 0.17.0

From the logs you provided, I think the -k flag is working, but the formatting of the file is unstable (so formatting it again is producing a different result). Can you provide the contents of the file that is producing the failure?


fix error/warning in setup install

Resolves Issue:  #82
Fixes:

fixed error "'await' outside async function" and changed start to be an async function
fixed warning "'classifiers' should be a list, got type 'tuple'", changed 'classifiers' tupel to a list

Tested on:

Windows 10 1903
python 3.9.4

thank you


FIX: error counter for test assertions

During some refactoring of the handling of internal error messages the
error counter got broken. It will increase the error always by one for
each error printing even it was an expected error.
This is now fixed as such as an option was introduced to select if the
error counter should be increased (normally used by UTF errors) or not
(normally the case for UTF assertions).
Close: #311.

Small example using this fix:
/// UTF_EXPECTED_FAILURE
Function Test()

	FAIL()
End

Function Foo()

	FAIL()
End

  Start of test "Unnamed"
  Entering test suite "Proc0"
  Entering test case "Test"
  Expected Failure: 0: is false. Assertion "FAIL()" failed in Test (Proc0, line 11)
  Leaving test case "Test"
  Entering test case "Foo"
  0: is false. Assertion "FAIL()" failed in Foo (Proc0, line 16)
  Leaving test case "Foo"
  Failed with 1 errors
  Leaving test suite "Proc0"
  Test finished with 1 errors
    ▶ Assertion "FAIL()" failed in Foo (Proc0, line 16)
  End of test "Unnamed"

Without this fix:
  Start of test "Unnamed"
  Entering test suite "Proc0"
  Entering test case "Test"
  Expected Failure: 0: is false. Assertion "FAIL()" failed in Test (Proc0, line 11)
  Leaving test case "Test"
  Entering test case "Foo"
  0: is false. Assertion "FAIL()" failed in Foo (Proc0, line 16)
  Leaving test case "Foo"
  Failed with 3 errors
  Leaving test suite "Proc0"
  Test finished with 3 errors
    ▶ Assertion "FAIL()" failed in Foo (Proc0, line 16)
  End of test "Unnamed"

That was indeed to quick. I forgot to set the default of the parameter which caused the new issue. 🤦♂


EINVAL (Invalid argument)

When trying to write to vpn output with vpnOutput.write(bufferFromNetwork), the java.io.IOException: write failed: EINVAL (Invalid argument) is thrown. It happens on several phones.
It is ok for some requests, but for some I get this exception and then the vpn stops working.
In the LogCat I can see several  java.net.SocketException: recvfrom failed: ECONNRESET (Connection reset by peer) errors.
Can you point me to the solution of this?
Thanks

Have you ever found the solution to this or a cause?

OK, I have found the cause in my case.
Looks like bad/corrupted IP headers may cause this error.
I was trying to create a tun tunnel between socat and my own VpnService implementation.
socat was prepending each data packet with 4 bytes, which turned out to be a "Packet Information" (see https://www.kernel.org/doc/Documentation/networking/tuntap.txt for the IFF_NO_PI ifreq flag). So, adding the iff-no-pi option to the socat tun has stopped prepending each packet with 4 extra bytes and thus solved the problem for me.

@KostyaEsmukov @hexene
Hi, i am trying to build a own VpnService with Raw socket implementation. Could you give me some help on receiving packet and how to write packet to tun? Thanks for your help

@Dojav
How is that related to this project? If you want to contact anyone directly – please use email for that instead of an issue tracker of some project.
Stack Overflow is even a better venue for questions than private email communications, and chances for getting help there are much higher.
And before asking for help, please make some effort to solve your issue by yourself and present the problem such as it's easy to grasp. Stack Overflow has a great writing on asking questions mannerly: https://stackoverflow.com/help/how-to-ask

@KostyaEsmukov So your fix was not in the LocalVPN source files?


Login/Logout along with Framework of Registation

Added User Login and Logout
Added framework for User Registration - Dialog and QB Sign up method
Changed Login layout to Fragment
Added Interfaces for inter Fragment communication
Added start Session of QB Application

+1

+1
Butterknife provides a handy @OnClick annotation for clicklisteners
See http://jakewharton.github.io/butterknife/

+1

+1


device name character limit

Why void NimBLEDevice::init(const std::string &deviceName) trunc the string up to 8 characters? I have several devices and I'd like to identify them by their name+mac address (MyDevice-FF:FF:FF:FF:FF:FF). Is it posible?

The name will be truncated to the max characters that will fit in the advertising packet. If you turn on scan response that will provide up to 29 bytes for the device name.

You're right. Thank you!

Glad it works, you're welcome!

You're right. Thank you!


⚠ ClamAV has degraded performance

In 5ca7dea, ClamAV (https://spamassassin.apache.org/) experienced degraded performance:

HTTP code: 200
Response time: 101 ms

Resolved: ClamAV performance has improved in 301b75d.


No way to exit "add range"

On the gallery tab, if you hit "add range" by mistake, there's no way to abort.

This will no longer be relevant with the new method of selecting images.

This is still relevant because you can shift+click to start a range, and then there's no way to abort.

Fixed in new_ui - Use ESC keep


treewide: Rename lium to cro3

Rename lium to cro3 according to our decision.

It looks like running cargo fmt is needed . Please refer to the CI log and  fix that!

Ok, btw, cargo fmt shows below warnings. (Just FYI)
Warning: the `fn_args_layout` option is deprecated. Use `fn_params_layout`. instead

Makefile also contains "lium" keyword still...
 21     @printf "\nlium is successfully installed at `which cro3`. Try \`cro3 --help\` if you want!\n"

Did you only replaced the name in *.rs files?

Sorry, it looks like that's the only line missing. All other usage seems to be fixed. Thank you! (Please feel free to submit after fixing the Makefile!)

OK, let me update it and merge.


Longhorn manager not run on RancherOS

I try run Longhorn on RancherOS node, install open-iscsi after show error:
time="2019-10-23T13:36:56Z" level=info msg="Start overwriting built-in settings with customized values"
time="2019-10-23T13:36:56Z" level=info msg="Start Longhorn replica controller"
time="2019-10-23T13:36:56Z" level=info msg="Start Longhorn engine controller"
time="2019-10-23T13:36:56Z" level=info msg="Start Longhorn websocket controller"
time="2019-10-23T13:36:56Z" level=info msg="Start Longhorn Engine Image controller"
time="2019-10-23T13:36:56Z" level=info msg="Start Longhorn node controller"
time="2019-10-23T13:36:56Z" level=info msg="Start Longhorn Setting controller"
time="2019-10-23T13:36:56Z" level=info msg="Start kubernetes controller"
time="2019-10-23T13:36:56Z" level=info msg="Starting Longhorn instance manager controller"
time="2019-10-23T13:36:56Z" level=info msg="Start Longhorn volume controller"
time="2019-10-23T13:36:56Z" level=fatal msg="Error starting manager: cannot get disk info of directory /var/lib/rancher/longhorn/: Failed to execute: nsenter [--mount=/host/proc/5423/ns//mnt stat -fc {\"path\":\"%n\",\"fsid\":\"%i\",\"type\":\"%T\",\"freeBlock\":%f,\"totalBlock\":%b,\"blockSize\":%S} /var/lib/rancher/longhorn/], output , stderr, nsenter: failed to execute stat: No such file or directory\n, error exit status 1"

Also getting this error, Brand new cluster and node setup on RancherOS.

Changing to Ubuntu and ditching RancherOS fixed this. Must be some incompatibility with the latest RancherOS?

Same  issue.
RancherOS 1.5.4, Rancher 2.3, Longhorn 0.70. Fresh installed cluster,

Same issue.
RancherOS 1.5.4, Rancher 2.3.3, Longhorn 0.70. Fresh installed cluster,

@Rancheroo @greyman-hh Can you raise an issue in RancherOS and link here? Seems something was missing in the RancherOS.

New issue created
https://github.com/rancher/os/issues/2937

Same issue.
RancherOS 1.5.5, Rancher 2.3.3, Longhorn 0.8.0. Fresh installed cluster,

Same issue as well.
RancherOS 1.5.5, Rancher 2.3.3, Longhorn 0.8.0. Fresh installed cluster,

I was able to get Longhorn working on RancherOS by running the following set of commands:
sudo wget https://busybox.net/downloads/binaries/1.31.0-i686-uclibc/busybox_STAT -O /bin/stat
sudo wget https://busybox.net/downloads/binaries/1.31.0-i686-uclibc/busybox_FLOCK -O /bin/flock
sudo chmod +x /bin/stat
sudo chmod +x /bin/flock
sudo ros s enable open-iscsi
sudo ros s up open-iscsi

This basically just downloads the missing utilities (stat, flock) from busybox and enables open-iscsi.
The issue is that the /bin folder doesn't persist between reboots, so this isn't a real solution. Seems like stat and flock would just need to be included in RancherOS and Longhorn would work fine.

thx, works fine, I hope we see this soon in the next release.

I was able to get Longhorn working on RancherOS by running the following set of commands:
sudo wget https://busybox.net/downloads/binaries/1.31.0-i686-uclibc/busybox_STAT -O /bin/stat
sudo wget https://busybox.net/downloads/binaries/1.31.0-i686-uclibc/busybox_FLOCK -O /bin/flock
sudo chmod +x /bin/stat
sudo chmod +x /bin/flock
sudo ros s enable open-iscsi
sudo ros s up open-iscsi

This basically just downloads the missing utilities (stat, flock) from busybox and enables open-iscsi.
The issue is that the /bin folder doesn't persist between reboots, so this isn't a real solution. Seems like stat and flock would just need to be included in RancherOS and Longhorn would work fine.

I asked in the last k3s meetup about this Issue, I got following response: "this is off topic from the meetup, but ill get it to the devs. you should know that we are no longer focusing heavily on rancher os."
Looks like its time to ditch RancherOS for me.

That was me. I don't know all the technical details of this issue.  I also don't know if this bug applies specifically to just rancher os or some other subset of linux OSes.

@normanschlatter  That worked for me

Please @yasker and @superseb, promote this changes on RancherOS in order to support Longhorn natively:
For all on this thread that want to implement the change - Explained:
Changes on Container os-base - https://github.com/rancher/os-base/blob/master/config/busybox-dynamic.config:
Enable Flock on busybox:
from:
	# CONFIG_FLOCK is not set
to:
	CONFIG_FLOCK=y

Stat is already set by default:
CONFIG_STAT=y
CONFIG_FEATURE_STAT_FORMAT=y
CONFIG_FEATURE_STAT_FILESYSTEM=y

Change fix-up-image.sh - https://github.com/rancher/os-base/blob/master/scripts/fix-up-image.sh:
Remove lines
     usr/bin/flock \
     usr/bin/stat \

Publish the image on a http server as explained at: https://github.com/rancher/os-base/blob/master/README.md

Changes on RancherOS:

Dockerfile.dapper
ARG OS_BASE_URL_amd64=http://<IP_ADDRESS>:8080/os-base_amd64.tar.xz

The new ISO will have flock and stat necessaries by longhorn installed by default at the distribution.

Just installed longhorn 1.0.1 and, although this article helped (adding stat and flock), I found I was also missing lsblk, which I "stole" from an overlay file system:
cp /var/lib/docker/overlay2/84b6637f5e5e0d1a160300637d3a183f0d1cf0cb3c483545fb9e4ad72cf9a1c3/merged/bin/lsblk /bin/
(your long hex string WILL be different, I used "find / -type f -name lsblk -print" to find one.  Make sure you get one from the "merged" path).
I will update here if I ever figure out how to make these three executables "permanent" after boot.

@uhcl-lund I modified RancherOS to include stat and flock. I'll also include lsblk.  I was wondering if you can test it ? Thanks.

I’d be happy to.  I am new to GitHub, but not to git in general.  Do you have a document to help me set up my workstation to do the pull/build?  Sorry if it is obvious, but I didn’t poke around much, just submitted the comment.
Thanks to Longhorn, I now have my own docker-registry, so…
Kurt
From: Gabriel Knepper Mendes<EMAIL_ADDRESS>Sent: Tuesday, August 4, 2020 10:35 PM
To: longhorn/longhorn<EMAIL_ADDRESS>Cc: Lund, Kurt<EMAIL_ADDRESS>Mention<EMAIL_ADDRESS>Subject: Re: [longhorn/longhorn] Longhorn manager not run on RancherOS (#828)
@uhcl-lundhttps://urldefense.com/v3/__https:/github.com/uhcl-lund__;!!BCR0FSePrR4x!UZQmQlYf4qtTHW30IGwk_ONeUMPr6HNBqy8rrOdONQ6KWRdWCnwR0HgbkBeV$ I modified RancherOS to include stat and flock. I'll also include lsblk. I was wondering if you can test it ? Thanks.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://urldefense.com/v3/__https:/github.com/longhorn/longhorn/issues/828*issuecomment-668960111__;Iw!!BCR0FSePrR4x!UZQmQlYf4qtTHW30IGwk_ONeUMPr6HNBqy8rrOdONQ6KWRdWCnwR0OulZNiq$, or unsubscribehttps://urldefense.com/v3/__https:/github.com/notifications/unsubscribe-auth/AQQFXDQNEUD2BFW7565WX6DR7DHM3ANCNFSM4JEBQF6Q__;!!BCR0FSePrR4x!UZQmQlYf4qtTHW30IGwk_ONeUMPr6HNBqy8rrOdONQ6KWRdWCnwR0NBglMmf$.

Hi everyone, any updates on this? I still facing the same issue...

Hi everyone, any updates on this? I still facing the same issue...

@raelix I think because RancherOS it's in EOL, people are looking for other options.

@raelix I think because RancherOS it's in EOL, people are looking for other options.

Switch console to alpine and reboot the node
sudo ros console switch alpine

I tend to agree with @gknepper - neither k3os nor the other options suggested really meets the brief that RancherOS did. That said, there is an effort to maintain it moving forward over at BurmillaOS, so perhaps it might be worth submitting the proposed changes there.


Strip README path

I used file: README.rst in my setup.cfg files, which works with setuptools. The space needs stripping when converting to TOML.

Thanks! Could you add a test that verifies this behavior? (or someone else can help with that if you don't want to do it)
Also don't forget to add a changelog fragment using towncrier. The towncrier docs should explain how - basically run towncrier create with suitable options - but let me know if you want more specific instructions.

Done and done!

Thanks! One last thing, sorry: the commit message is rather sparse as is, so would you mind adding putting a bit more detail about what the bug was and what your fix is, and mention that you added a test for it?

How’s this now?


Use of "-W 100%" Sometimes causes red hue to image

Tested on both pngs and jpegs.

Added original image not sure what more could I can do to help?

Sorry about that I thought I had found the correct "source".

No worries! It's... more confusing than it ought to be!


llama3-gradient going crazy

What is the issue?
Just ran ollama run llama3-gradient and this happened. Used the default (2k) context size

OS
Windows
GPU
Nvidia
CPU
Intel
Ollama version
0.1.32

Hi there, the runtime parameters have been updated to help with this issue when the context limit is hit. Please try re-pulling using ollama pull llama3-gradient which should fix this.

Hi there, the runtime parameters have been updated to help with this issue when the context limit is hit. Please try re-pulling using ollama pull llama3-gradient which should fix this.

When have they been updated? I downloaded the model a few minutes before creating this issue. Also the default context size is 2k, not 8k, sorry. So my input was above the context size

After re-pulling the model it seems to be working :)

@DuckyBlender great to hear, and sorry again about that.

Everything seemed to be working perfectly, until it started repeating itself

I'm seeing the same thing.  llama3-gradient was working fine for a while and now it endlessly repeats it's self.

Maybe a higher repeat penalty can fix this?

 Everything seemed to be working perfectly, until it started repeating itself

I have the same thing. Worst thing is, that it doesn't stop but keeps going for a really long time, using resources.


Implementation of Stack using Linked List [Python]

Is your feature request related to a problem? Please describe.
I will add the program to implement stack considering all the main methods along with some other methods also with the help of linked lists in Python.
Do you want to work on it
Yes!
Languages used
Python
Participant of GSSOC'21

Is your feature request related to a problem ? Please describe.
I have already done this program in C++. I can do the same in Python.
Describe the solution you'd like.
I will make different functions for checking if the stack is empty or full and to perform push, pop operations and for displaying the stack.
Do you want to work on it?
I would like to contribute to this issue
I am a participant of GSSoC'21.
Will you please assign this issue to me @raksha009 @tarun26091999

I want to work on this issue. Please assign this issue to me.


Use Skylark git_repository workspace rule

The native git_repository rule does not honor git's proxy settings
(https://github.com/bazelbuild/bazel/issues/3893), so this means
that anything that depend on protoc-gen-validate will fail when building
while behind a proxy.
Example of failing build of envoy:
DEBUG: /root/.cache/bazel/_bazel_root/2ca1f4ebdc59348ffdc31d97a51a98d5/external/envoy/bazel/repositories.bzl:84:5: External dep build exited with return code: 0
ERROR: /root/.cache/bazel/_bazel_root/2ca1f4ebdc59348ffdc31d97a51a98d5/external/com_lyft_protoc_gen_validate/validate/BUILD:35:1: no such package '@com_github_golang_protobuf//proto': failed to fetch com_github_golang_protobuf: # cd .; git clone https://github.com/golang/protobuf /root/.cache/bazel/_bazel_root/2ca1f4ebdc59348ffdc31d97a51a98d5/external/com_github_golang_protobuf
Cloning into '/root/.cache/bazel/_bazel_root/2ca1f4ebdc59348ffdc31d97a51a98d5/external/com_github_golang_protobuf'...
fatal: unable to access 'https://github.com/golang/protobuf/': Failed connect to github.com:443; Connection refused
2018/02/08 00:00:37 exit status 128
 and referenced by '@com_lyft_protoc_gen_validate//validate:go_default_library'

I'm encountering the following error when building envoy behind a proxy. I have set the HTTP_PROXY, HTTPS_PROXY, http_proxy, and https_proxy, environment variables, and have configured git to use the proxies. I even configured git to disable ssl verification, and have imported the github certificate into cacerts.
ERROR: /open/usr/mancini/.cache/bazel/_bazel_zk49xik/b1b7ee4f2abe773f993beb4c85591835/external/com_lyft_protoc_gen_validate/BUILD:18:1: no such package '@com_github_golang_protobuf//ptypes/wrappers': failed to fetch com_github_golang_protobuf: # cd .; git clone https://github.com/golang/protobuf /open/usr/mancini/.cache/bazel/_bazel_zk49xik/b1b7ee4f2abe773f993beb4c85591835/external/com_github_golang_protobuf
Cloning into '/open/usr/mancini/.cache/bazel/_bazel_zk49xik/b1b7ee4f2abe773f993beb4c85591835/external/com_github_golang_protobuf'...
fatal: unable to access 'https://github.com/golang/protobuf/': SSL certificate problem: unable to get local issuer certificate
2018/05/21 11:29:30 exit status 128
and referenced by '@com_lyft_protoc_gen_validate//:go_google_protobuf'


correct stream ids to match HTTP/2

From the HTTP/2 spec

Streams are identified with an unsigned 31-bit integer.  Streams initiated by a client MUST use odd-numbered stream identifiers; those initiated by the server MUST use even-numbered stream identifiers.  A stream identifier of zero (0x0) is used for connection control messages; the stream identifier of zero cannot be used to establish a new stream.

Consider this for discussion.  It seems like something has to change here.  I didn't want to change the code until the spec is agreed.

I'd also like to tighten up the stream id usage in one of two possible ways

Match the HTTP/2 Spec - No reuse and monotonically increasing

The identifier of a newly established stream MUST be numerically
greater than all streams that the initiating endpoint has opened or
reserved.  This governs streams that are opened using a HEADERS frame
and streams that are reserved using PUSH_PROMISE.  An endpoint that
receives an unexpected stream identifier MUST respond with a
connection error (Section 5.4.1) of type PROTOCOL_ERROR.
The first use of a new stream identifier implicitly closes all
streams in the "idle" state that might have been initiated by that
peer with a lower-valued stream identifier.  For example, if a client
sends a HEADERS frame on stream 7 without ever sending a frame on
stream 5, then stream 5 transitions to the "closed" state when the
first frame for stream 7 is sent or received.
Stream identifiers cannot be reused.  Long-lived connections can
result in an endpoint exhausting the available range of stream
identifiers.  A client that is unable to establish a new stream
identifier can establish a new connection for new streams.  A server
that is unable to establish a new stream identifier can send a GOAWAY
frame so that the client is forced to open a new connection for new
streams.

Add to the end of Stream Sequences and Lifetimes - "An implementation SHOULD only reuse IDs with prior knowledge of the support by the remote implementation."

I agree, it's better if we match HTTP/2 spec.
The problem is that now we are having a little bit of users, then we need to either:

coordinate the changes in our different libraries.
use the version field to deal back-compatibility.

I would prefer going for the first solution (because we control the users).
What others think?

👍 for monotonically generated, not reused stream IDs (Option 1)
I understand the following needs to be changed to match HTTP/2 spec:

How to handle unexpected stream IDs: Close connection upon receiving a response frame with stream ID that is never generated (more than the last generated stream ID)
On Stream ID exhaustion: Server MUST close the connection if the stream IDs are exhausted for the server. Client must use a different connection if the stream IDs are exhausted for the client.

Since, we are tightening the usage of Stream IDs, I suggest that we revisit Handling the Unexpected section. eg: "Receiving a Request frame on a Stream ID that is already in use MUST be ignored." sounds like an error case much like receiving a stream ID that is never generated.
Also, today I do not see in the spec a guidance on how to close a connection i.e. should a ERROR frame (on stream 0) must be sent before closing the connection? I will add another issue for that.
@stevegury
I agree that incrementing version seems heavy handed for this change. I think we should add a status section in the protocol and we term the current state as "draft 1". Any changes from now can move to the next draft number till we are comfortable that we are good to freeze the protocol.

BTW my thoughts on needing to create new connections after exhausting all stream ids

@NiteshKant @yschimke I agree with everything.

Sounds like I should leave this with you and you will follow up with issues etc.  Let me know if you would like me to help out or make the changes, but I'll close the PR for now.

@NiteshKant also flipping so
odd are client generated
even are server generated

Hey all, so sorry to be late to this conversation.
Restarting the entire connection upon stream id exhaustion seems to be fairly heavy handed. Consider the case where there are long-lived interactions such as Channels or Subscriptions over a connection. These might encapsulate state and be very expensive to restart. Shutting down the connection and starting a new one may not be ideal. What about not shutting down the existing connection?
I wonder if we can also talk about stream_id reuse. I've done some pondering and I think we can't reuse streams_ids because of race conditions and edge cases. Is this provably correct? Not reusing stream ids means we could exhaust the stream IDs fairly quickly. The JS library currently does around 50K RPS, which works out to be just under a day before we exhaust the IDs.

Yeah, I missed that.  I wasn't considering that the server must close the connection.  The connection is still valid to my thinking, just exhausted for new streams.  This would match http/2

5.1.1.  Stream Identifiers
A server
that is unable to establish a new stream identifier can send a GOAWAY
frame so that the client is forced to open a new connection for new
streams.
6.8.  GOAWAY
The GOAWAY frame (type=0x7) is used to initiate shutdown of a
connection or to signal serious error conditions.  GOAWAY allows an
endpoint to gracefully stop accepting new streams while still
finishing processing of previously established streams.  This enables
administrative actions, like server maintenance.

Just to clarify, the idea was to gracefully shutdown the connection (sending ERROR frame on stream ID 0) as I hinted in my comment. I am yet to file an issue of clarifying in the protocol how to do graceful shutdown.
As per discussion in issue #59 it was determined that ERROR frame on Stream ID 0 and no more leases is equivalent to GOAWAY (graceful shutdown).
Thanks @yunong for pointing this out.


Attempting to import an unknown module gives a confusing error message.

Program: https://code.world/haskell#
Comment:
GTK
Message:
program.hs:1:1-22: error:
    Could not find module ‘Graphics.UI.Gtk’
    Use -v to see a list of the files searched for.

This user was apparently looking for GTK.  It's not available.  However, the Use -v to see a list of files searched for. is not useful. I can add a sanitizer message that replaces it.

One interesting aspect of this problem is that the error message is equally wrong for Haskell mode.  This suggests that maybe the error sanitizer should also run in Haskell, but just with a smaller set of replacements.

This was already fixed for CodeWorld mode.  I'm going to close this, since there are lots of reasons not to start mucking with GHC messages for Haskell mode.


CI for VM runtime repo

What:
Enable CI for Arktos VM runtime repo
WHY:
currently the CI is pretty much disabled due to a security related issue in general Arktos CI common infra. We need to address this issue and re-able the CI.
alternatively, it can be enabled with the CircleCI if the security issue in Arktos CI infra cannot be addressed properly.

enabled.


Make participant groups optional

Currently, participant groups are mandatory. However, in some projects, it might not be useful not to have to group participants.
This involves mainly setting the nullable flag to true and managing properly requests and access.

Why do we have to specify a project id when at the participant level when it is already specified in a participant group? What happens if they are not equal?


CONFIG_THREAD_ANALYZER_AUTO crash in native_posix

I have made a very simple demo application based on the samples/basic/threads/src/main.c, where I just send simple text messages via a queue between a couple of threads. Nothing fancy here (full source is shown in the end of this issue report)
I then want to check stack and cpu usage by using the builtin thread analyzer.
The analyzer support to automatically create an "analyzer thread" via the following option CONFIG_THREAD_ANALYZER_AUTO.
However if I enable this option the application crash.
It specifically crash with a zero-division in zephyr/subsys/debug/thread_analyzer.c in the function static void thread_analyze_cb(const struct k_thread *cthread, void *user_data) in the snippet below - more precisely in the info.utilization = (info.usage.execution_cycles * 100U) / rt_stats_all.execution_cycles; calculation.
Because rt_stats_all.execution_cycles is zero it fails.
#ifdef CONFIG_THREAD_RUNTIME_STATS
	ret = 0;

	if (k_thread_runtime_stats_get(thread, &info.usage) != 0) {
		ret++;
	}

	if (k_thread_runtime_stats_all_get(&rt_stats_all) != 0) {
		ret++;
	}
	if (ret == 0) {
		info.utilization = (info.usage.execution_cycles * 100U) /
			rt_stats_all.execution_cycles;
	}
#endif

My assumption is that it is because no threads have executed yet (either because the CONFIG_THREAD_ANALYZER_AUTO thread has higher priority or doesn't wait until somethings have executed). In general the best approch might be to check if rt_stats_all.execution_cycles is zero or not as part of the if (ret == 0) { statement.
Of course you could disable the calculation by disable the CONFIG_THREAD_RUNTIME_STATS option, but this is part of the reason why you do thread analysis... and it is automatically enabled when CONFIG_THREAD_ANALYZER=y.
The output before the crash is:
 [00:00:00.000,000] <inf> thread_analyzer: Thread analyze:

If I implement the analyzer myself and make sure all other threads have executed, I can implement the analyzer with the code shown below
void analyzer_out(void)
{
	while (1) {
		k_msleep(5000);
		thread_analyzer_print();
	}
}

To verify / test this bug add the following configs in prj.conf:
CONFIG_THREAD_ANALYZER=y
CONFIG_THREAD_ANALYZER_USE_PRINTK=y
CONFIG_THREAD_ANALYZER_USE_LOG=y
CONFIG_THREAD_ANALYZER_AUTO=y
CONFIG_THREAD_ANALYZER_AUTO_INTERVAL=5
CONFIG_THREAD_ANALYZER_AUTO_STACK_SIZE=1048
CONFIG_THREAD_NAME=y
CONFIG_THREAD_RUNTIME_STATS=y

Next do create a src/main.c with the following content:
#include <zephyr/kernel.h>
#include <zephyr/device.h>
#include <zephyr/debug/thread_analyzer.h>
#include <zephyr/drivers/gpio.h>
#include <zephyr/sys/printk.h>
#include <zephyr/sys/__assert.h>
#include <string.h>

/* size of stack area used by each thread */
#define STACKSIZE 1024

/* scheduling priority used by each thread */
#define PRIORITY 7

struct printk_data_t {
	void *fifo_reserved; /* 1st word reserved for use by fifo */
	uint32_t led;
	uint32_t cnt;
};

K_FIFO_DEFINE(printk_fifo);

void blink(uint32_t led, uint32_t sleep_ms)
{
	const size_t size = sizeof(struct printk_data_t);
	int cnt = 0;
	int gpio_state = 0;

	while (1) {
		gpio_state = cnt % 2;

		struct printk_data_t tx_data = { .led = led, .cnt = cnt };

		char *mem_ptr = k_malloc(size);
		__ASSERT_NO_MSG(mem_ptr != 0);

		memcpy(mem_ptr, &tx_data, size);

		k_fifo_put(&printk_fifo, mem_ptr);

		k_msleep(sleep_ms);
		cnt++;
	}
}

void blink0(void)
{
	blink(1, 100);
}

void blink1(void)
{
	blink(2, 1000);
}

void uart_out(void)
{
	while (1) {
		struct printk_data_t *rx_data = k_fifo_get(&printk_fifo,
							   K_FOREVER);
		printk("Toggled led%d; counter=%d\n",
		       rx_data->led, rx_data->cnt);
		k_free(rx_data);
	}
}

K_THREAD_DEFINE(blink0_id, STACKSIZE, blink0, NULL, NULL, NULL,
		PRIORITY, 0, 0);
K_THREAD_DEFINE(blink1_id, STACKSIZE, blink1, NULL, NULL, NULL,
		PRIORITY, 0, 0);
K_THREAD_DEFINE(uart_out_id, STACKSIZE, uart_out, NULL, NULL, NULL,
		PRIORITY, 0, 0);

The zephyr version (commit hash) is: bc5fbc929bb805e3c562c7280dd02a6f9f1f9087

Hi @thucon ,
I don't expect the thread analyzer to provide you any usable information in native_posix. In the POSIX architecture :

Code takes 0 simulated time to execute. So the analyzer will report 0 cycles being used. (I presume the division by zero you see is the result of this)
The stack allocated by Zephyr is not actually used (except for a tiny part used by the arch code itself to do a bit of thread bookkeeping). The POSIX architecture uses a separate stack (from an underlying Linux pthread) which Zephyr is blind about. So the thread analyzer is going to only report a tiny stack utilization.

Maybe the thread analyzer kconfig option should have a depends on !POSIX_ARCH to avoid people trying to use it in native_posix.
CC @joerchan

Hi @aescolar
First of all thank you very much for a very quick and concise answer.
What you write makes sense, and the idea of making a compiler flag to avoid using Thread Analyzer for native builds might be the best way to deal with it.


fixing device automation triggers for HA 2022.04.1

This was a regex search and replace to make ARGS compatible with optional arguments by converting them to a PARAMS dictionary (numbered).
Is supposed to fix as may issues as possible related to https://github.com/home-assistant/core/issues/69375

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

1 of 1 (100.0%)  changed or added relevant line in 1 file are covered.
No unchanged relevant lines lost coverage.
Overall coverage increased (+0.003%) to 80.355%

Totals

Change from base Build<PHONE_NUMBER>:
0.003%

Covered Lines:
5383

Relevant Lines:
6699

💛  - Coveralls

@dumpfheimer have you confirmed this change works?
{v: k for v, k in enumerate([0, 26, 5])} is just dict(enumerate([0, 26, 5])), which generates {0: 0, 1: 26, 3: 5}. The "params" dictionary has only string keys so I'm not sure how this will be able to extract the n-th value from the dictionary.

Only with an Ikea 5 button remote.
I believe that in the event data it ends up with positional and named entries but I could be mistaking.

If you know how this can be tested by an average user it would be great if we could provide them with steps how they can test it to gain confidence in these changes

Creating a custom quirk containing just the fixed Python module for the ikea/*.py device will allow for local testing but considering there are only 45 quirks using device automation triggers with ARGS, what do you think about just fixing them to use PARAMS properly, with the expected keys? I'm going to try patching a unit test to generate these dictionaries with string keys, maybe it will be relatively quick.

That would of course be better and would be the next step. I just wanted to have a solution as fast as possible (and I did not have time for a "proper" fix)

Hmm, the lax matching of PARAMS may be a problem: some quirks could be relying on ARGS: [1] being exact. For example, if [1, 2] is sent, ARGS: [1] won't match, but PARAMS: {"key": 1} will.

You're right that might be possible. Did you see such a case?

I have not, it just occurred to me that this is a possibility.

Okay. I know this is far from optimal and it should definitely not stay this way but I think a fix should be published as fast as possible even if it does not work 100%. Remote control not working is imho pretty much a worsed case. That is why I am eager to get something out. Don't think about the poor men standing in front of a broken remote. Think about the wives next to them 😬

My approach didn't work, the automation triggers are too free-form to be programmatically migrated. The good news is that only a few commands are affected (basically anything with newly-added optional parameters):
COMMAND_STEP
COMMAND_STEP_COLOR_TEMP
COMMAND_STEP_SATURATION
COMMAND_STEP_HUE
COMMAND_MOVE

Narrowing the scope of this change to just these commands is safer and will hopefully ensure no other quirks will break while trying to fix the IKEA remotes. There are thankfully only 91 of them so I'll do it with the actual parameter names.

Not needed


Remove remaining references to BlockHeaderHash and BlockHeight

In #905, we renamed BlockHeaderHash to block::Hash and BlockHeight to block::Height.
But there are still a few instances of the old names in comments, debug formatters, and tests. We should replace them with the new names.

Oops, my bad, I did this using the rust-analyzer rename feature and touched up references in comments that I saw while fixing up import paths, but I should have done rg BlockHeight or rg BlockHeaderHash to check for completeness that all of the references were gone.


Remove reduntant config

Since Jest 23.5.0 has now updated the default testURL value to http://localhost, there's no need to specify the same config again in package.json.

This is awesome, thank you very much @aulisius.


Part 1: doc restructure, introduce categories

Based on the discussions from #1360, this PR contains the following changes for part 1:

Introduce the categories "First steps", how-to guides (recipes), addendum, and references based on the Diátaxis doc framework
Clean up the first page and move some resources into resources.md file.
Add a high level overview on the first page. Tell the reader how the Lark documentation is organized.
Minor changes in titles to adhere to the overall doc type

I've compiled it with make html but got some warnings. However, it seems, they exist in the master branch as well.
Let me know what you think, @erezsh.
Open questions
When I worked on this PR, I stumbled upon the following issues:

Do we want a table of content in the first page although we have already one on the left sidebar? Should we keep the first page clean? Only difference is the depth of the TOC.
Should we present the features on the first page instead of using the link?
The doc is a mixture of RST and Markdown. Probably there is a reason for that ("we are get used to Markdown/don't like RST"?).
Using different formats in one doc makes it hard to stay consistent. Both have a different set of syntax and features. What works with one doesn't work for the other.
IMHO, this makes it also hard to contribute. But this is for a different PR (if any), but I would really recommend to use only one format.

Result

TOC: Unsure. If it's just mostly the same as the left nav, it's pointless. If it has more depth (and this depth is actually useful. Doesn't look like it for the JSON tutorial for example), then I would say get rid of it. Also, can't then left nav get more depth and expand if you click on it?
Features list: No opinion from me.
With regard to markdown vs rst, check here: #640 . So in some sense it's mostly historic.

TOC: Unsure. If it's just mostly the same as the left nav, it's pointless. If it has more depth (and this depth is actually useful. Doesn't look like it for the JSON tutorial for example), then I would say don't get rid of it. Also, can't then left nav get more depth and expand if you click on it?

Exactly. I think we can configure Sphinx to show more content for the left sidebar/TOC. In that case, the TOC in the content would be useless and could be removed.

With regard to markdown vs rst, check here: Please use Sphinx for documentation #640 . So in some sense it's mostly historic.

I see. As a first time contributor, I was puzzled. Usually, writers (and probably contributors as well) don't want to deal with two formats. It's just makes live harder as you have to switch context (MD <-> RST).
I've read the issue you gave me, but I'm still a bit confused. It's for historical reasons, okay. Are we forced to keep it? If not, can we use one format? Or are there any objections?
At this point, we have the following options:

Convert the .md files to .rst to make it consistent.
Stop here and merge the existing PR after all reviews are done. Make the conversion in another PR or keep it as is.

Apart from the above change, I realized there might be another question to consider. The current structure under docs/ is flat. With the current split into these four doc types, we maybe should reflect this change in the structure as well.
For example, we could create docs/references, docs/tutorials/ directories and move the files there. That would make contribution a bit clearer, hopefully. However, it would make the PR a bit bigger. But this idea is independent from the two options above and could be done also in another PR (or not, if you prefer the current structure).
It's your project, I'll give you just some ideas to think about. :slightly_smiling_face:  If you think this would be beneficial, I'm willing to work on it.
What do you think?

I've read the issue you gave me, but I'm still a bit confused. It's for historical reasons, okay. Are we forced to keep it? If not, can we use one format? Or are there any objections?

We can convert the markdown files to rst, I have no objections (erezsh might). The point is more that we don't/didn't consider it worth the effort to convert them. But I don't think that should happen in this PR.

The current structure under docs/ is flat. With the current split into these four doc types, we maybe should reflect this change in the structure as well.

Sure. But IMO this should also be a separate PR to keep them all manageably small.
Let's wait for erezsh to add their opinion.

I see no advantages in having two formats at the same time. Just some additional thoughts:

Consistency is key. This is the overall parenthesis that holds it together.
We should make the life of potential contributors easier, not harder.
Having one format, we:

can use the full set of syntax. We do not have to deal with a subset or work with limitations of one format.
can get rid of some dependencies which are useless after the conversion.
looks consistent and clean

Conversion is a matter of calling pandoc and fixing the leftovers (we have to do it once).

@MegaIng / @erezsh Anything that I can do to make your life easier? Or anything that's missing?
I know you are probably quite busy before the holiday season, but it would help me if I'm on the right track and if there is still interest to proceed further. :green_heart:
Thank you and have a great vacation.

@tomschr Thanks! Sorry to keep you waiting. I've actually been on vacation these past 3 weeks, and might have a bit more free time in a week or two.

Thank you! Hope the vacation was fantastic! :smile:  No problem, have a good day.

Hi @tomschr ,
I got to looking at your branch. There were some changes I liked, and some that I didn't understand. More importantly, looks like your changes from the docs. This is how it looks when I build your branch locally:

Also, looks like you intentionally removed all the links from the index page. I think that's wrong. It's arguable how much links should be there, but definitely there should be a few "call to actions" for the most common pages users would like.

@erezsh Thank you for your time! I'm sorry, it seems I had accidentally committed my last experiment. That shouldn't be the case, I've corrected the TOC now. Could you check again?

@erezsh Any additions, corrections, or suggestions from your side?

Sorry, I've been busy. If it was as simple as just merging it, I would have already done so.
I will need to take the time to write my thoughts in detail, and explain what I think needs changing and why.
I will try to get to it soon!

@tomschr Sorry again for the long wait. At an overview, I agree with these changes, but not with all of the choices you made.
A few points:

Examples don't belong in "first steps". The way I see it, first steps should be reserved for tutorials, beginner guides, and installation instructions (if we had any). Maybe it should contain the "How to use Lark" section too.
It definitely shouldn't contain a whole section called "Grammar Composition", which is an advanted topic, and definitely isn't important for beginners.

( I might be persuaded that it should contain the beginner examples, but I think examples should be together. Probably in their own separate section )

I think "How to use Lark" is a better title than "Working with Lark"

The portion you moved to "Resources" needs editing to adjust to the new structure

Now that I think about it, "Parsers" section belongs in reference.

Possibly "features" also belongs in the reference section.

Thank you for your response!
After such a long time it's hard to remember all the details that I made and the reasons behind it. :laughing:

Examples don't belong in "first steps". The way I see it, first steps should be reserved for tutorials, beginner guides, and installation instructions (if we had any).

That is true, but as we don't have these guides yet I had to put at least something. Keep in mind, we are just migrating from one structure to a new one. It's an intermediate step, it's not the end. We can always adjust it later.
If you prefer to move these things, I can do that. But then we maybe end up with only one article under "First steps".

I think "How to use Lark" is a better title than "Working with Lark"

I did it on purpose, because "working" is a verb and means action. The problem with starting with "How to..." is, it propagates quite fast and you have other articles with very similar titles. That makes it harder for the reader to distinguish them. The difference in each title appears too late. In my work as a professional writer, I try to avoid starting with "How to..." if possible.

Now that I think about it, "Parsers" section belongs in reference.
Possibly "features" also belongs in the reference section.

That shouldn't be a problem to move them. I'll do that later.

The portion you moved to "Resources" needs editing to adjust to the new structure.

I'm not sure I got that. Any examples?
Thanks for your time!

No need to thank me! I'm glad you're trying to contribute to Lark, and like I said, I'm sorry it took so long.

After such a long time it's hard to remember all the details that I made and the reasons behind it

Now you get a glimpse of how I feel about docs I wrote 4 years ago :)

But then we maybe end up with only one article under "First steps".

That is acceptable. I think it's better than a mis-categorization, that might confuse a newcomer.
We can also include the "How to write a DSL" tutorial as an external link.

I try to avoid starting with "How to..." if possible.

Maybe there's a third option. Like "A guide to using Lark" or "best-practices for using Lark", etc.

I'm not sure I got that. Any examples?

Well, I wrote it as a "quick-links" section. Since you moved it as-is, it contains a lot of links for sections that are not really resources, like "philosophy", "features", "examples" etc.

No need to thank me! I'm glad you're trying to contribute to Lark, and like I said, I'm sorry it took so long.

Haha, no problem. Now I had to say sorry as I wanted to work on it last week.

Now you get a glimpse of how I feel about docs I wrote 4 years ago :)

Haha, very true!

[... suggestions to move sections...]

This is done in commit c3470e1 now.

That is acceptable. I think it's better than a mis-categorization, that might confuse a newcomer.

Okay, no problem.

Maybe there's a third option. Like "A guide to using Lark" or "best-practices for using Lark", etc.

Hmn. :thinking:  My idea was all about consistency: References and conceptual topics are in nominal style  ("Grammar Reference", "JSON parser" etc.) whereas task-oriented topics uses verbs ("Contributing to Lark", "Working with Lark" etc.). Perhaps "Working" isn't the best verb and it can be improved.
Your suggestion "A guide to using Lark" or "Best-practices for using Lark" just adds more fluff to the title. :wink: From my point of view, it's just too wordy. :wink: Whether it's a guide or a section doesn't really matter to the user. It's an implementation detail. The readers want to know what is the topic about and they want to understand it fast. Anything that distracts the user reduces their understanding. :wink:
Just wanted to tell you my reasoning and why I think it matters. If you really want to go with your suggestion, I can do that change of course. :slightly_smiling_face:

I'm not sure I got that. Any examples?

Well, I wrote it as a "quick-links" section. Since you moved it as-is, it contains links to sections that are not really resources, like "philosophy", "features", and "examples". Also, some of these "resources" are either guides, or examples, or something in between, and would probably fit there better than to "resources".

Yes, I moved it "as-is" to reduce the impact of the changes. Remember, it's part 1. In this part I deal only with restructuring, maybe correcting titles here or there, but not touching the overall text. This could be done at a later point.
But maybe I did misunderstood you.

My idea was all about consistency

I appreciate consistency, but I think clarity is even more important.
"Working with Lark" isn't a terrible title, but I feel that it doesn't communicate well what the content might be. If I was looking for best-practices, I might miss it if I was trying to scan the menu.
Anyway, I don't feel that strongly about it.

Yes, I moved it "as-is" to reduce the impact of the changes

It's good to keep the changes small. But I don't want the docs to end up looking wrong or broken, even if it's temporary.
If you're still confused, I can try to fix that page myself. But it needs doing.

"Working with Lark" isn't a terrible title, but I feel that it doesn't communicate well what the content might be. If I was looking for best-practices, I might miss it if I was trying to scan the menu.

I see what you mean. But the titles work in combination with the guide title. I think we are talking about different things:

Task-oriented/"recipes"/"first steps": more for beginners. Explains the topic more in a step-by-step style (if possible). Usually more task-based. Could be a "Working with Lark"
"Best practices": more for medium users to experts. Explains the topic in a broader context. Could be something like "Optimizing your grammar" (hypothetical).

From what I see, I think these are different guides. If you have this distinction, you can focus on your titles. Beginner will be attracted by "First steps", more advanced users will gravitate the Best Practices or other guides.

But I don't want the docs to end up looking wrong or broken, even if it's temporary.

Sure, absolutely. :+1:

If you're still confused, I can try to fix that page myself. But it needs doing.

If it's not too much to ask for, please go ahead.


feat: support snap build for Ubuntu 22

resolves #31

Sorry, I don't think I understood the tutorials correctly as it's looking for signatures with metadata for snap build with this branch. Will need to look into this further.


Fix Protocol IDs in src/protocols/Protocols.h

Problem
Protocol IDs have been assigned somewhat randomly in Protocols.h. They should be edited to reflect the values assigned in the spec.
Proposed Solution
IDs should be edited to reflect the spec.

Seems to have been fixed by #9851 and #6631


readme in Torque3D-3.9-LinBinaries.tar.gz has links to non-existance wiki

The readme in Torque3D-3.9-LinBinaries.tar.gz https://github.com/GarageGames/Torque3D/wiki/Project-Manager to read about/download the project manager and that wiki no longer exists

What readme? The Torque3D-3.9-LinBinaries.tar.gz file don't have readme.


Now we can do SimpleCov.add_group "Group", ["path", "other/path"]

This commit  makes it possible to define a group with multiple directories.
SimpleCov.configuration do
add_group "Units", ["app/models", "lib", "app/helpers"]
end
By the way, great gem, very easy to read, well commented.

Ping! I’m trying to put together a new release. Please update if you want this feature included.

Since #375 was merged and recognized as the new version of this PR, can this one be closed?

@onebree Yes, I believe so.


⚠ SkipTheCommericals has degraded performance

In 698869d, SkipTheCommericals ($STC) experienced degraded performance:

HTTP code: 200
Response time: 5983 ms

Resolved: SkipTheCommericals performance has improved in 05a393a.


fix: specify text color of nav bar in light mode

Fixes #33

@yr1404 Thank you! Looks awesome!

I've pushed the release to the production server as well. You can now see your changes at www.bcitflex.tech.


How actively maintained?

Just curious how actively maintained this code-base is and if I should consider a different project to use in my app.

I maintain in my spare time. The fastest way to get something fixed is by submitting a pull request.


Generate code from json config

So existing karabiner users can import their config.

It is now a new project karabiner.ts.import-json, however, I am not sure I will have enough time to finish it.


Question:  inference  takes long time

Thank you for providing the source code for this interesting work. However, I have a question regarding the inference time. On my device ( RTX 3090 (24GB)), a single inference takes 2.92 seconds (average of 100 runs), whereas the paper reports that it can achieve about 50 fps. I look forward to your response.

@lyp-deeplearning one other thing to mention:
The TF models should take advantage of the GPU automatically, but the PyTorch DINOv2 code needs some modifications to dino_extract.py:

Line 38: after this line, add a call self.model.cuda() to send the model to GPU mem
Line 113: replace with: out = self.model.get_intermediate_layers(image.cuda(), n=self.feature_layer)[0] - i.e., send image to GPU mem with a .cuda() call

After this, hopefully all models are run on GPU and you should see some inference latency improvements.


Merge prTesting_201908060858 branch to master branch

Docs Build status updates of commit b824084:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details
Dependent Files

split/updateTestCon.md
:white_check_mark:Succeeded

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


#63: Creating the ide wrapper script

Fixes #63

Pull Request Test Coverage Report for Build<PHONE_NUMBER>
Details

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 56.274%

Totals

Change from base Build<PHONE_NUMBER>:
0.0%

Covered Lines:
3751

Relevant Lines:
6412

💛  - Coveralls

https://github.com/devonfw/IDEasy/issues/63#issuecomment-1963770443

I have made the required changed, and the commits contain all the changes that we also discussed. I also managed to fix the diff war by setting the core.autocrlf to false. Therefore the file pom.xml now shows only the changes from the main branch file. I also adapted the Test for the IdeHomeRequired, so that the PR passes all the tests.


Add a timeout to DetectorWriters when they wait for index to increment

In a flyscan, a common problem I have found is if the hardware is incorrectly configured, any writer (ie. the hdf writer) will hang because it's expecting to have read data (After it's recieved a trigger, say from a panda). Of course if it's not wired properly, it will just hang.
This prevents it from hanging indefinitely, and allows the timeout to be configurable on the flyer class.

My finger slipped and I accidentally merged main instead of rebasing. Oops.
I don't think it particularly matters since I'll do a squash and merge anyways.


Release 0.14.0

This PR prepares the release for version 0.14.0.
Once the PR is merged into master, run bundle exec rake release:finish to tag and push to trunk.

This PR was created during the testing phase of the release automation script.
The real and final release PR is #300


Bump aiohttp from 3.8.6 to 3.9.0 (amended)

Bumps aiohttp from 3.8.6 to 3.9.0.

Release notes
Changelog
Commits

updated-dependencies:

dependency-name: aiohttp dependency-type: direct:production ...

TP2000-1137 Dependabot alert: aiohttp's ClientSession is vulnerable to CRLF injection

Why

Dependabot-generated PR was failing unit tests due to incorrect mocking behaviour in aioresponses after bumping to aiohttp version 3.9.0 (possibly having introduced a breaking change to the aiohttp.ClientResponse or aiohttp.ClientSession APIs).
Also bump aiohttp to latest version, 3.9.1.
What

Additionally bump the version of aioresponse, which appears to fix the response or session management issue / incompatibility.

Checklist

Requires migrations? No
Requires dependency updates? Yes

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Comparison is base (c5fe135) 92.72% compared to head (160bc14) 92.72%.

Additional details and impacted files
@@           Coverage Diff           @@
##           master    #1106   +/-   ##
=======================================
  Coverage   92.72%   92.72%
=======================================
  Files         460      460
  Lines       35157    35157
  Branches     2694     2694
=======================================
  Hits        32600    32600
  Misses       2028     2028
  Partials      529      529

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.


How to store on disk an in-memory zarr

Hi alimanfoo,
Great work on your library. I have a library (vtk for medical image visualization) that outputs a 3D numpy array.
I want to store it on disk however it doesn't seem like there is a "convert", "save" or export function.
I tried using the following as well:
data is a 3d numpy array
outFile is path/to/my/image.zarr
z = zarr.array(data,
    **path=outFile**, dtype='int16',
    chunks=(100, 100, 100), compression='blosc', compression_opts=dict(cname='zstd'))

I get no error, z is created in memory, but nothing on disk.
For reference bcolz has a rootdir parameter that seems to be able to do what I want.

Hi Mamy,
The easiest way to create a Zarr array using the filesystem for storage is to use the open_array function. There is an example in the tutorial section on persistent arrays.
If you have several arrays you want to store on disk, you might find it convenient to use groups. The easiest way to create a persistent group via the open_group function.
Both open_array and open_group are actually convenience function. An alternative way of creating on-disk arrays is to pass a DirectoryStore as the value of the store keyword argument to any of the array creation functions. E.g.::
import zarr
store = zarr.DirectoryStore('/path/to/data')
z = zarr.array(data, store=store, dtype='int16', chunks=(100, 100, 100), compressor=zarr.Blosc(cname='zstd'))

Hth.

Thank you very much,
Your DirectoryStore example worked.
Using open_array or open_group wouldn't work as easily as I would have to compute the proper shape to pass it as a parameter and then copy the NumPy array into the Zarr array.
Looking at the documentation, there is actually this example that I missed:
store = zarr.ZipStore('example.zip', mode='w')
z = zarr.zeros((1000, 1000), chunks=(100, 100), dtype='i4', store=store)

but there is no example with exporting/writing an existing array to a DirectoryStore.
I'm creating a PR for that.


Verify compatibility notes

The notes for compat between V0 seem to be wrong. Currently, V1 is not able to equivalently load V0 encodings. This may be a bug in 2.0.0 as well.
To complete this, go back to v1.0.1, verify behavior of nil encodings and ensure that they are replicated in the latest versions. Then, update the package docs to ensure compatibility notes are correct.

Places where nil even can occur as of 1.0.1:

nil slice
nil map
NOT in binary - that one did not allow such.
a binary returning either an empty or nil slice as its data was encoded as zero-len slice

1.1.0 had already upgraded to newer form nils


Cannot run test due to fs.readFileSync

Hi,
I just install ypress-cucumber-preprocessor and i have this error :
Uncaught TypeError: fs.readFileSync is not a function
This error originated from your test code, not from Cypress.
When Cypress detects uncaught errors originating from your test code it will automatically fail the current test.
Cypress could not associate this error to any specific test.
We dynamically generated a new test to display this failure.
Check your console for the stack trace or click this message to see where it originated from.
Do you know where I can look to fix it ?
thanx

Never mind, I duplicate the config in both index.js

move the functionality causing that into cypress/support/ such as in commands.js


Make KafkaConsumer's NetworkReceive memory pool configurable by ConsumerConfig

Allow the KafkaConsumer's network memory pool to be configured by ConsumerConfig.

Supply linkedin.pool.class.name for memory pool implementation with default constructor with no args
Supply linkedin.pool.class.name with GloballPoolDelegate and pass the object instance with linkedin.memorypool.pool.instance in properties map.
Moved the leak check config from common client config to Consumer config

./gradlew cleanTest rat checkstyleMain checkstyleTest :clients:unitTest :core:unitTest --no-daemon -PxmlFindBugsReport=true -PtestLoggingEvents=started,passed,skipped,failed

Ran
./gradlew cleanTest rat checkstyleMain checkstyleTest :clients:unitTest :core:unitTest --no-daemon -PxmlFindBugsReport=true -PtestLoggingEvents=started,passed,skipped,failed


SSLError: EOF occurred in violation of protocol (_ssl.c:590)

Hi Guys,
I was using the maps absolutely fine last night.
anyway this morning when I wake up I get this error?
The problems start when the debugger pin code is shown..
any ideas how to get around this?
Thanks
Jonah

Debugger pin code: 315-030-935
Exception in thread search_thread:
Traceback (most recent call last):
File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/threading.py", line 801, in __bootstrap_inner
self.run()
File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/threading.py", line 754, in run
self.__target(*self.__args, **self.__kwargs)
File "example.py", line 581, in main
api_endpoint, access_token, profile_response = login(args)
File "example.py", line 92, in memoizer
cache[key] = obj(*args, **kwargs)
File "example.py", line 514, in login
access_token = get_token(args.auth_service, args.username, global_password)
File "example.py", line 429, in get_token
global_token = login_ptc(username, password)
File "example.py", line 331, in login_ptc
r = SESSION.get(LOGIN_URL, headers=head)
File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/requests/sessions.py", line 487, in get
return self.request('GET', url, **kwargs)
File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/requests/sessions.py", line 475, in request
resp = self.send(prep, **send_kwargs)
File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/requests/sessions.py", line 585, in send
r = adapter.send(request, **kwargs)
File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/requests/adapters.py", line 477, in send
raise SSLError(e, request=request)
SSLError: EOF occurred in violation of protocol (_ssl.c:590)

Facing the same problem


The provided storage account shared access signature or account storage key is not valid.

Update-AzSqlServerAdvancedThreatProtectionSetting             -ResourceGroupName "demo-rg"
-ServerName "dbsrv1"             -Enable 1 Update-AzSqlServerVulnerabilityAssessmentSetting
-ResourceGroupName "demo-rg"             -ServerName "dbsrv1"
-StorageAccountName "mystorage"             -RecurringScansInterval Weekly
-ScanResultsContainerName "vulnerability-assessment"
Results in an error: Update-AzSqlServerVulnerabilityAssessmentSetting: The provided storage account shared access signature or account storage key is not valid.
Need to add:
-BlobStorageSasUri "https://StorageAccountName.blob.core.windows.net/vulnerability-assessment?" `
For it to work

Document Details
⚠ Do not edit this section. It is required for learn.microsoft.com ➟ GitHub issue linking.

ID: abac8313-5b62-7a01-748b-8db14e5b1a3f
Version Independent ID: 93192a83-6999-4c64-a9e3-2700edf3dd41
Content: Manage vulnerability findings in your Azure SQL databases - Microsoft Defender for Cloud
Content Source: articles/defender-for-cloud/sql-azure-vulnerability-assessment-manage.md
Service: defender-for-cloud
GitHub Login: @dcurwin
Microsoft Alias: dacurwin

@applefacts
Thanks for your feedback! We will investigate and update as appropriate.

@applefacts
Thanks for bringing this to our attention.
I'm going to assign this to the document author so they can take a look at it accordingly.

#reassign:alizabernstein

#reassign:dcurwin

#label:"backlog-item-created"

@applefacts Thank you for bringing this to our attention. After speaking to the product team, they determined that this error is a result of a specific customization in your environment, and therefore we will not be updating the documentation. For further discussion, we recommend opening a support ticket.
#please-close


[Add] book yards

Site URL
www.bookyards.com
Description of the above provided site
'The Library to the World', in which books, education materials, information, reference materials, documents, and content will be provided freely
Category
Resources
Sub Category
ebook
Checklist

[X] I have checked the existing issues
[X] I have read the Contributing Guidelines
[X] I am willing to work on this issue (optional)
[X] I am a GSSoC'23 contributor

You are assigned @S-ishita


Debugging in vscode with Jest Runner

I'm trying to debug this template using vscode and the vscode-jest-runner extension. I can run the initial test successfully but when I try to debug the test I receive the following error:
SyntaxError: /.../tests/handler.test.ts: Unexpected token, expected ";" (5:38)

      3 |
      4 | test("hello", async () => {
    > 5 |   const event = { body: "Test Body" } as APIGatewayEvent;

To summarize:

using vscode-jest-runner:  https://github.com/firsttris/vscode-jest-runnerhttps://github.com/firsttris/vscode-jest-runner
tests run perfectly when running the serverless-bundle test command
debugging in vscode using the extension mentioned above does_not work

Any idea why this might be happening or how I can resolve it? It seems like the run and debug are using different jests or something like that.
Thanks.

I'm realizing that this might be a re-issue of something I brought up a while ago: https://github.com/AnomalyInnovations/serverless-bundle/issues/70. I can delete this issue if things are still in limbo.

I'm realizing that this might be a re-issue of something I brought up a while ago: https://github.com/AnomalyInnovations/serverless-bundle/issues/70. I can delete this issue if things are still in limbo.


Titlecase synced column names in Wizard tab

Makes the droplists for column names in the wizard tab show titlecased
labels when using an external table from the data library.  Also adjusts
the corresponding sql query composition to account for that possibility.
Companion to PR #121 and PR #122.

it's clever and beautiful +1


Add a drag and drop query builder in the UI

To make queries easier to build, and to help users learn PQL,  it might be useful to have a drag and drop 'query builder'. This could consist of a UI that allows the user to visually select operators, and functions that are available for the user to build a query and to drag and drop between entities (maybe different cloud components) and create powerful queries by pointing and clicking without having the learn PQL. Although the option to use it should still be there.

something similar to this, but instead of tables, we would have 'cloud objects':
https://www.mysql.com/common/images/products/MySQL_Workbench_Visual_Design_Linux.gif

I've put this in the wrong place...moving to service UI.


Bump reflex-platform

The hydration branch has already been merged and removed, and this removes code relating to old GHCs which is already removed upstream.

Hydra eval: https://hydra.reflex-frp.org/eval/191653


On Binance Smart Chain the "New Spending Limit" does not work

On Binance Smart Chain the "New Spending Limit" operation seems to pass successfully, but the limit is not set, nor even the DailyLImitModule is added to the list of installed modules.
It's a weird thing that this does not work without any error messages.
https://smart-binance.portonvictor.org

There was several bugs about contract addresses making impossible setting spending limits and some other operations. Now they are fixed. Zero users were affected by this bug.


Rejection policy refactor

closes #115
closes / supercedes #138
I've been working through #138 (which was a great start!) which led to some refactoring. Instead of pushing the changes to that branch (and over writing some of the initial work), I copied the branch and pushed it here so that we can discuss/compare if necesary.
I had some nitpicks that I've addressed here:
Config class and RejectionPolicy

The Config and RejectionPolicy classes really seem to be two YAML compatible configuration files for applying pipeline procedures. However RejectionPolicy lacked a constructor (or default file) that helps the user to know what fields there are, what can be set, etc.. I've added a constructor here, and API doc.

Config is just a recipe that gets passed to the LosslessPipeline class, while RejectionPolicy is both the recipe and the machinery to make the recipe, which I think was confusing API wise. in this branch, both configs are just the recipes, and all the machinery remains with the pipeline class.

on #138 , RejectionPolicy.apply() is sleek, but it is a bit confusing per my point above, and because apply suggests that we are changing some object directly, but really this method makes a new clean copy and returns it. On this branch, RejectionPolicy.Apply is replaced by LosslessPipeline.make_cleaned_raw which is hopefully more clear that we are returning a new object.

I was/am a little concerned about the default copy every time we apply the rejection policy (memory consumption), but I also can see your logic behind preserving the state of the pipeline and its raw object, so I left the default copy and if it becomes a problem in the future we can address it then.

tests and tutorials
I built out the unit tests to be more comprehensive (there was a typo in #138 that wasn't being caught by the tests), and I've added a tutorial on running the pipeline and applying the Rejection Policy
I committed my changes directly on my local #138 branch then duplicated it into this branch for this PR. So if there are concerns about contributing authorship etc, we can push the changes onto that branch and merge there.

Note that in https://github.com/mne-tools/mne-icalabel/pull/130 , ICALABEL changed the name of their constant dict from ICLABEL_LABELS_TO_MNE to ICA_LABELS_TO_MNE, which is part of the latest stable released just yesterday (0.5), thus breaking our tests today.
Because this is still a very small project I think it's okay to pin to mne-icalabel 0.5 or greater, and I added an mne.utils.check_version to our package so that in the event that someone on our team doesnt have at least 0.5, they will get an informative error.


[Linux]  Run npm scripts with requesting user input

Hello,
I have a script bash who wait for the user to select one option between many.
When I run the script with my local terminal, the jetbrain built-in terminal or npm built-in feature, it works fine. But when I run this script with run npm scripts from RN Console, I can't enter text, it's look like a read-only terminal.
How can I do to make it works ?
Thanks

This could be done, but need the IDEA 2019.2 x version with the latest terminal support. I'll do a research on it soon.

This issue has been fixed, please download https://github.com/beansoftapp/react-native-console/blob/master/react-native-console.jar to test it. And i've submit a plugin update.
And this fix works on WebStorm 2017 to 2019. Pls have a try.

It works fine with this jar, thanks.