Check for "$ENV{NIX_CC}", with quotes, not without

In this commit: https://github.com/NixOS/nixpkgs/commit/871cf9f7b3e5a54b6cc1f08487846ff79c26db83#diff-ff2a2145cf58008275b3e5299c8bdcd31a88541c74f23127aa4f5468de69b80eR25, the code IS_DIRECTORY ${ENV(NIX_CC} checks the env var without quotes, which means an unset or empty variables can cause build errors, eg this one for the boring-sys Rust crate in a nix shell:
      "IS_DIRECTORY" "AND" "EXISTS" "/nix-support/orig-libc" "AND" "EXISTS" "/nix-support/orig-libc-dev"
                    ^
                    Nothing here, should have at least an empty string

I'm not sure it's missing quotes though, I don't know how CMake works in this situation, but since that looks like a bash-inspired syntax, I suppose it has bash-inspired bugs too

Full error:
  running: "cmake" "[CARGO_HOME]/registry/src/github.com-1ecc6299db9ec823/boring-sys-2.1.0/deps/boringssl" "-G" "Ninja" "-DCMAKE_TOOLCHAIN_FILE=/nix/store/x25lgahqpdygym97i6kqcy82bif2f89n-macos.arm64.cmake" "-DCMAKE_INSTALL_PREFIX=[CWD]/target/aarch64-apple-darwin/debug/build/boring-sys-400f6fa962fd5ab3/out" "-DCMAKE_C_FLAGS= -ffunction-sections -fdata-sections -fPIC --target=arm64-apple-darwin" "-DCMAKE_CXX_FLAGS= -ffunction-sections -fdata-sections -fPIC --target=arm64-apple-darwin" "-DCMAKE_ASM_FLAGS= -ffunction-sections -fdata-sections -fPIC --target=arm64-apple-darwin" "-DCMAKE_BUILD_TYPE=Debug"
  -- The C compiler identification is Clang 14.0.6
  -- The CXX compiler identification is Clang 14.0.6
  -- Configuring incomplete, errors occurred!
  See also "[CWD]/target/aarch64-apple-darwin/debug/build/boring-sys-400f6fa962fd5ab3/out/build/CMakeFiles/CMakeOutput.log".

  --- stderr
  CMake Error at /nix/store/dz5jcmsfmi4hi6lkajvdfcv8g9dcnvds-cmake-3.24.1/share/cmake-3.24/Modules/Platform/UnixPaths.cmake:51 (if):
    if given arguments:

      "IS_DIRECTORY" "AND" "EXISTS" "/nix-support/orig-libc" "AND" "EXISTS" "/nix-support/orig-libc-dev"

    Unknown arguments specified
  Call Stack (most recent call first):
    /nix/store/dz5jcmsfmi4hi6lkajvdfcv8g9dcnvds-cmake-3.24.1/share/cmake-3.24/Modules/Platform/Darwin.cmake:241 (include)
    /nix/store/dz5jcmsfmi4hi6lkajvdfcv8g9dcnvds-cmake-3.24.1/share/cmake-3.24/Modules/CMakeSystemSpecificInformation.cmake:37 (include)
    CMakeLists.txt:9 (project)

  thread 'main' panicked at '
  command did not execute successfully, got: exit status: 1

  build script failed, must exit now', [CARGO_HOME]/registry/src/github.com-1ecc6299db9ec823/cmake-0.1.48/src/lib.rs:975:5
  note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

Temporary workaround:
Set NIX_CC to garbage, like /does-not-exists, and it will build and run correctly

Ping the relevant and link the issue in the original PR

@poliorcetics probably it is duplicate of https://github.com/NixOS/nixpkgs/pull/192943

idolo


Buf UI shows

Buf UI shows weird text... It doesn't seems right ;-)
I'm using GoLand 2021.3.4 (Build #GO-213.7172.22, built on March 15, 2022)

This is a known bug, but only recurrent with 2022.1 or higher in my . Anyway, I will fix it later.

Ummm...Recurrent with IU-2021.3.3, maybe also with GoLand 2021.3.4

Fixed in 1.5.11


Introduce CheckedClose

Tests can now enforce error checking on tpm close.
Tests now fail if they leak TPM Handles.

Closing in favor of #19


Feature/model separation

Created thoth_api::errors::ThothResult, an alias type to replace all instances of Result<T, ThothError>
Created thoth_api::model with two traits: Crud and HistoryEntry, as well as a couple of macros to help implement the traits
Implemented the above traits for Imprint, under a new module thoth_api::imprint::crud that replaces thoth_api::imprint::handler

The main benefit has been decoupling crud functionality from graphql functions and reduce boilerplate therein

Implemented these traits for all entities except Issue and Contribution (which need to be converted away from composite primary keys first)
Made various improvements to traits to handle special cases encountered with specific entities (e.g. multiple filter parameters, multiple parent ids)
Other small improvements


AGDIGGER-59 trigger jenkins job - 2

Follow up of https://github.com/aerogear/digger-java/pull/2

convert services to singletons and pass them to client
make the delays parametrizable in services

ping @wtrocki @matzew @josemigallas


feat(metrics): support ExponentialHistogram

Calculating buckets from metric data in the form of Exponential Histogram would be complicated implementation.
We could use this package: https://github.com/lightstep/go-expohisto/tree/main
For now, I'd like to work on other issues first.


Document release process

Although we should strive to automate our release process as much as possible, there are currently some things that we need to do manually. As such, they should be documented (probably in the README, since putting it anywhere else is just asking for it to be forgotten).
Here's the list so far:

Updating the version constant for the CLI (#159)
Publishing to the GitHub Marketplace (#168)
Updating the Homebrew formula (#77)

#190 automates the second and third points. The first point could be automated as well, such as by using Swift GYB.


Implement file storage service

We should have(at least) 2 implementations of file storage:

local
AWS S3
We can think about using minio to make things easier.

Could we have something locally without using the docker? For example maybe use local /public folder to get to images and other files from the webapp?
File storage should have single interface:

PutFile
GetFile
...

This task can be divided into several tasks if needed.

Local storage can be mounted to docker as volume to /public directory.


Convert HyparHut to cadwork model and model subfloor.

List of things to manaully change in Rhino:

Element IDs for Floor and Floor Joist
Foundation connection detail

List of things to model in cadwork:

Floor joist joint

Note reminder to remember manually Boolean the tapered joints.


ls.unload 4.1.6 has breaking changes from 4.1.5

In<EMAIL_ADDRESS>you now have to explicitly set window.lazySizesConfig.expand or the plugin will not work unlike 4.1.5 and previous versions. I checked the docs and nothing mentioned this. Is this the correct intent or is this a bug? jsfiddle isn't required for this.. its obvious.

I will check this. I'm currently on holiday.


file name changed

file name changes successfully

Hi @Thiru7747 , thanks for your contribution. If you're interested in getting this merged, can you rename the imports? Like from multiview_mapping_toolkit.config import X to from multiview_mapping_toolkit.constants import X. Some IDEs like vscode will help you make this change automatically.

made changes as you mentioned

Awesome, thank you!


Change dind from volume mount to official dind image

Update calico/containers to adhere to changes in #1 whereby we no longer volume mount docker in from the host, but the new calico/dind which is built from the official dind image

One comment, then looks ok.


Can't set custom notification height in Swift 3

I'm trying to set a custom height for a notification, however, it doesn't seem to be working.
I've set the NotificationType to Custom and specified a NotificationPreferredHeight, however, the notification only covers the status bar when presented.  Any help with this would be greatly appreciated, thanks!

After some more investigation I resolved this issue by set NSNumber objects for these dictionary values instead of Swift Integers.  Not sure if this issue is specific to Swift 3, but nonetheless, this fixed the issue for me


dropwizard-metrics-elasticsearch module?

I need to push metrics from a dropwizard application to an elasticsearch instance. https://github.com/dropwizard/dropwizard/blob/master/CONTRIBUTING.md#new-features says I should first bring the subject here: So, would a PR providing a dropwizard-metrics-elasticsearch module, similar to dropwizard-metrics-ganglia and dropwizard-metrics-graphite, be welcome?
TIA for any answer

@rgbj I think you should open an issue in the Metrics project: https://github.com/dropwizard/metrics
This being said, there are already existing metrics reporters for Elasticsearch, e. g. https://github.com/elastic/elasticsearch-metrics-reporter-java

I had a look (and indeed, make us of right know) https://github.com/elastic/elasticsearch-metrics-reporter-java. I also found https://github.com/tomcashman/metrics-elasticsearch and https://github.com/dropwizard/dropwizard-elasticsearch. What I can't find in these is something akin to the class io.dropwizard.metrics.graphite.GraphiteReporterFactory tailored for elasticsearch, which would allow me to configure metrics-to-elasticsearch rather than code it in. E.g., I can't right now write:
metrics:
  reporters:
    - type: elasticsearch
      host: some.host
      port: 9200

in my dropwizard app yaml configuration file. So that's what I had in mind.

Okay, got it.
Feel free to start such a project. As it doesn't have any hard dependencies into Dropwizard, I'd suggest running it in your own repository and adding it to the 3rd party listing at http://modules.dropwizard.io/

That's what I was wondering -- will do it this way, then. Thanks for your answer, your time and dropwizard!


Cluster controller: Add support for destroy

Hooked up the destroy functionality on the controller. We can now destroy clusters using the DELETE request.

LGTM

LGTM


Extend contains and notcontains

Are you requesting a feature, reporting a bug or asking a question?
Feature
What is the current behavior?
Contains and not contains act on an array and a scalar.
What is the expected behavior?
Intuitively they should work on a pair of scalars as well.
Contains
Contains could be read as subset, which can easily be applied to 2 sets.
["a","b"] contains "a" ==> true
["a","b"] contains ["a"] ==> true
["a","b"] contains ["a", "b"] ==> true

Alternatively, one could add some more, similar functions: containsAny, containsAll.
These allow for more flexible conditions while still being easy to implement.

@SamMousa Yes, it was not hard to implement.
The functionality will be available in the next minor release on this week.
Thank you,
Andrew


The game has been patched.

Nintendo has added an update to the game and I forgot to use a custom DNS so the wii u doesn't patch the game automatic, how many weeks do we need to wait or months so you can add a new trainer version for the 1.1.1v of Botw?

Closing all issues which are probably related to 1.1.1


Prototype payment processing

Description:
[User Story]
Payment processing is necessary for next iteration of reservation service components and a pattern we have not yet done - hence this prototype.
Acceptance Criteria:
Given
When
Then
Given
When
Then
Development Checklist:

[ ] ...
[ ] ...
[ ] ...

Dependencies

Blocked by
Blocking

Wireframe(s):
Workflows:
Definition of Ready (Note: If any of these points are not applicable, mark N/A)

[ ] User story is included
[ ] User role and type are identified
[ ] Acceptance criteria are included
[ ] Wireframes are included
[ ] Design / Solution is accepted by Product Owner
[ ] Dependencies are identified (technical, business, regulatory/policy)
[ ] Story has been estimated (under 13 pts)

Definition of Done

In progress:

[ ] Acceptance criteria are tested (Functionality meets the acceptance criteria defined in the ticket)
[ ] UI meets accessibility requirements
[ ] Unit tests are written
[ ] Work is traceable in GitHub
[ ] PR linked to ticket number
[ ] If needed/required - Dev adds flag/label to highlight any migration steps necessary prior to PROD deployment

Code review:

[ ] Code is peer reviewed and has passed CI/CD tests

QA:

[ ] Acceptance criteria are tested (Functionality meets the acceptance criteria defined in the ticket)
[ ] Code is potentially shippable to the production environment
[ ] Functional features have been tested and passed by QA
[ ] UI components tested by designer
[ ] Code is deployed to PROD when moved to 'done' column (unless requested otherwise by PO)

PO Review:

[ ] Acceptance criteria are tested (Functionality meets the acceptance criteria defined in the ticket)
[ ] Reviewed and approved by Product Owner

Notes:

Using bambora
should be able to test every edge case we need (without using real money)
Testing with bambora is free
Come up with general workflow

Ideas to move forward:

Create a flowchart based on the workflow noted in the description above. (then we can more easily identify other edge cases)

Understand this is potentially blocked by #465 - I need to learn what Bambora is capable of before I build a flowchart we are going to adhere to. This might be a ticket that gets done simultaneously with #465

This has been completed for bambora and now we will do it with Stripe. cc @cameronpettit  @meyerdarcie


Improved documentation

GIF how-to images
clean up things that dont apply

Would be good to browse other extensions for documentation examples, the Python extension for example effectively makes use of GIFs.

I use the https://marketplace.visualstudio.com/items?itemName=arcsine.chronicler extension to generate animated gifs.

Thinking about the things to document with an animation

Optionally creating the launch.json when one is not present
Launching the debugger and selecting a version
Opening of any custom views (like hex view, infoset view, etc)
Evaluating expressions on debug console

Images from this issue back the wiki page at https://github.com/jw3/example-daffodil-vscode/wiki
The goal here was to avoid sending a bunch of binaries into the repo to link in the readme.
Eventually when the repo is in the new org these gifs can be uploaded to a stable location and maintained.  Until then lets just reference the wiki and keep the readme and repo clean of binaries and links to deprecated github projects.


strange behavior

I try to implement this add-on in my code,
So update my Api to return the same meta, so the behavior I got is automatically the add-on, send the request until the pages is full, so it renders all the request before execute the scroll,
To clarify my issue I can't implement the scroll, here is my code.
import Ember from 'ember';
import InfinityRoute from "ember-infinity/mixins/route";
// route/index.js
export default Ember.Route.extend(InfinityRoute, {
    model() {
        return this.infinityModel('trademark', {perPage: 20, startingPage: 1});
    }
});

  "meta": {
        "page": 3,
        "per_page": 20,
        "total_pages": 3,
        "total_records": 58
    }

and my template looks

{{#each model as |trademark|}}

           {{card-limit-display relCards=trademark.marcanet title=trademark.title panref=trademark.id total=trademark.relatedTotal}}

          {{trademark.title}} similares.close
          {{card-hidden hiddenCards=trademark.marcanet}}

{{/each}}
{{infinity-loader infinityModel=model  destroyOnInfinity=true}}

I'm following the README but I can't get it works.
Ember info
DEBUG: Ember           : 2.4.5
DEBUG: Ember Data      : 2.5.2
DEBUG: jQuery          : 2.2.3

It should be
{{#each cards as |trademark|}}
right?

sorry i fix my typo, I copy from my component i try to simplify the html because is the same behavior
but it looks
{{!-- index.hbs --}}
{{#card-list cards=model}}
    {{infinity-loader infinityModel=model  destroyOnInfinity=true}}
{{/card-list}}
{{outlet}}

{{!-- components/card-list.hbs --}}

{{#each cards as |trademark|}}

           {{card-limit-display relCards=trademark.marcanet title=trademark.title panref=trademark.id total=trademark.relatedTotal}}

          {{trademark.title}} similares.close
          {{card-hidden hiddenCards=trademark.marcanet}}

{{/each}}
{{yield}}

This is probably a good issue for stack overflow.  We try to keep github issues for problems in the library, rather than implementation details.


Check for CAA records during selfcheck

We should check that CAA records are set appropriately (i.e. in a manner that won't automatically cause an upstream CA to deny our request) before proceeding to attempt preparation of a certificate (e.g. obtaining authorizations).
Letsencrypt now require that CAA records are either not set, or set correctly in order to issue certificates: https://letsencrypt.org/docs/caa/
This could become a quick way to exhaust letsencrypt ratelimits otherwise.

I ran into this problem as well. Googling for "acme: authorization for identifier domain is invalid" led me to this ticket #653.
I think adding a more desciptive error message might help a lot of people in the future.


Manage Grafana Cloud resources

Recently we have requested the Grafana Cloud Pro account to use it for performance related stuff. Grafana has a terraform provider that we can use to manage all Grafana Cloud resources: https://registry.terraform.io/providers/grafana/grafana/latest/docs
Once we have the performance repository ready, we should take the control of the resources using this repo

Not all the resources can be managed via terraform yet:

https://github.com/grafana/terraform-provider-grafana/issues/1010
https://github.com/grafana/terraform-provider-grafana/issues/1009


Script used for preprocessing Wikipedia data

Thanks for a great release!  I am wondering if you can open source the code used to preprocess the wikipedia data into wikipedia_shuf_train5M.txt?  I'd like to as closely replicate it on a novel dataset and use it alongside the wikipedia data if possible.

@pkmital apologize for the delay in replying. We'll look into providing the preprocessing code and update you shortly.

@pkmital Our script for preprocessing the wikipedia data into wikipedia_shuf_train5M.txt  is mainly based on the WikiExtractor.
Could you take a look and see if that provides what you need to replicate it on the novel dataset?

Closing because no reply.


demo/line-numbers.php error

demo/line-numbers.php ended error:
Parse error: syntax error, unexpected end of file in demo\line-numbers.php on line 94
Do you can fix?

Can you see if 7880e22 fixed your problem? I think that parse error might have been caused because of an accidental short tag.

Yes. It is fixed. Thanks for speedy reply 👍

awesome! first try too 🙌


⚠ GitLab Server has degraded performance

In 585c8f9, GitLab Server (https://gitlab01.its-telekom.eu) experienced degraded performance:

HTTP code: 200
Response time: 13657 ms

Resolved: GitLab Server performance has improved in 499bb85.


MDDialog Button Background color does not have action on the widget

Description of the Bug
Hi people,
I've trying to put some background into the button that is created at the MDDialog widget.
But there is a problem about the md_bg_color. It just remain without a background.
Screenshots

Versions

OS:  Microsoft Windows [Version 10.0.19041.746]
Python: 3.7.7
Kivy: 2.0.0
KivyMD: 0.104.2.dev0

I noticed there is no problem to change the color when the Button is a MDRaisedButton.
I didn't noticed about the following note:

This button is similar to the :class:`~MDFlatButton` button except that you
can set the background color for :class:`~MDRaisedButton`:


Lj/api tasks

Please stop submitting these PRs to this repo. I've asked many times now. This project is full of these random "crud" PRs. PLEASE stop.


Handle section names that are all numeric characters by forcing to String

If section name is all numeric, such as 1234567, the replace function will throw this error.
Uncaught TypeError: $(...).data(...).replace is not a function
Fixing by calling toString() before replace.

Thanks


Update for JS mistreatment of decimals

Coverage increased (+0.02%) to 95.84% when pulling 25b48d8943b23c3847df382d1cd033c3496686ba on nwinch:master into 4e97e3c73510aff2296806b5b142c1c4919de7a4 on bugventure:master.

@nwinch
Thanks for the pull request! Can you, please, give an example of a failure to validate properly with the current implementation of multipleof, so that I can add a test for this case?


Run ram patch command on colibri by default based on board type

Based on CPU type, run the ram patch. This should be done through a uEnv file which would be read by uboot.

#10


Reference https://wiki.rockylinux.org/rocky/bugs/ in README.md

Is this feature request related to a problem? If so, please describe it.
N/A
Describe the solution you'd like to see
Point the user to the wiki page for bugs inside README.md and suggest they read it prior to opening a bug in github.
Have you considered alternative solutions/features? If so, please describe them.
No response
Version and Build Information
N/A
Additional Context
Some users may start reviewing repositories at GitHub. As the wiki is its own separate repository it may not be found first when searching. Peridot does not have its own wiki tab. This can lead to opening issues in Peridot, and potentially other repositories, that may appear to be the correct location. However, with Bugzilla available is not where the issue is preferred to be submitted.
Referencing this in the README.md may reduce the chance that an issue is opened against Peridot directly instead of as a bug in the Bugzilla instance.

Thank you!


October 2024 Recovery 2

[x] Create a milestone October 2024 Recovery 2 @joyceerhl
[x] Bump the version number @joyceerhl
[ ] 🔖candidate issues
[ ] Assign candidate issues to the recovery milestone team
[ ] Review the candidate issues, and if they pass the review assign them to the recovery milestone team
[ ] All candidate fixes are peer reviewed and pushed to main and then cherry-picked into the release branch team
[ ] Initiate insiders build from main
[ ] Issues are tested in the insiders team
[ ] Build and manually release Insider from main branch for vscode.dev (if there were vscode.dev candidates)

[ ] Issues are tested in the insiders team

[ ] Build stable for all platforms from release branch @joyceerhl
[ ] Issues are verified on stable build and the verified label is added @joyceerhl
[ ] Check https://github.com/Microsoft/vscode/compare/release/<x.y> to ensure no other commits have been made in the release branch @joyceerhl
[ ] The insiders build with all candidate fixes needs to be in the wild for 24 hours before recovery release, unless explicitly approved by @kieferrm
[ ] Update the release notes and include a link to a query for the fixed issues @ntrogh
[ ] Sanity Testing

[ ] Windows 64 bit

[ ] System Installer
[ ] User Installer
[ ] Archive
[ ] Server
[ ] CLI

[ ] Windows ARM64

[ ] System Installer
[ ] User Installer
[ ] Archive
[ ] Server
[ ] CLI

[ ] macOS Intel

[ ] Archive
[ ] Universal Archive
[ ] Server
[ ] CLI

[ ] macOS ARM64

[ ] Archive
[ ] Universal Archive
[ ] Server
[ ] CLI

[ ] Linux x64

[ ] Archive
[ ] DEB
[ ] RPM
[ ] Snap

[ ] Linux Server (can be tested from any OS with Docker)

[ ] x64
[ ] ARM32
[ ] ARM64
[ ] x64 Alpine
[ ] ARM64 Alpine

[ ] Linux CLI  (can be tested from any OS with Docker)

[ ] x64
[ ] ARM32
[ ] ARM64
[ ] x64 Alpine
[ ] ARM64 Alpine

[ ] Publish website @joyceerhl
[ ] Publish stable build @joyceerhl
[ ] (if there were vscode.dev candidates) Trigger the vscode.dev Deploy pipeline for release/x.y for the prod deployment target. Note that there are four deploy approvals needed - one for overall and one per each of the three service regions @joyceerhl

[ ] Request approval from another team member at the necessary step to deploy the vscode.dev build. @joyceerhl

[ ] Create an official release @joyceerhl

[ ] Create a tag (make sure you pull the release branch first): git tag <x.y.z> release/<x.y>
[ ] Push the tag: git push origin <x.y.z>
[ ] Create a GitHub release: Open the GitHub tags, and click far right ... > Create Release. Use the correct title and description from our release notes. Example

[ ] Close the milestone on GitHub @joyceerhl

Hello, I'd like to mention that assigning a reviewer to a PR within VS Code no longer functions as expected. It was working fine earlier, but after the October Update, it stopped working.
Now, after creating a PR in VS Code, I have to log in to GitHub manually to add a reviewer.


NPM package is outdated

I was running into issues trying to package js-git with Rollup. Found out it's fixed in this commit.
Can you update the npm package?

Also master was missing some commits.  I think everything is merged in now and 0.7.8 is published to npm.
Let me know if this helps.
Also I have some newer git code that I wrote for a recent project I used rollup on.
https://github.com/creationix/revision/blob/master/src/libs/git-codec.ts


Wrong GSSoC label.

You have added wrong GSSoC label.
The label should be gssoc-extd. And add a level(number) label to be more specific about a task. It has only 3 level. And there should not be any space in between!!!
#10 #9 #7 #4

the isssues has been already taken care off, hence closing this issue!


Route page: both ENC2 and ENC3 control QUANT

https://github.com/jmamma/MIDICtrl20_MegaCommand/commit/c040c23c28b68ea0ac41a5020ae8b584a9555dbd


Kube server binary is no longer bundled in repo

In latest kubernetes releases like 1.5.3 the server binaries
are no longer present in the repo. Instead on needs to get
them using get-kube-binaries.sh script. This patch updates the
vagrant README to reflect the changes in installation process.

Akash,
Would you mind giving a Signed-off-by for both your commits?
For e.g: Signed-off-by: Gurucharan Shetty<EMAIL_ADDRESS>The meaning of Signed-off-by is explained here:
https://github.com/openvswitch/ovn-kubernetes/blob/master/CONTRIBUTING.md
The author as shown in "git show" should have the same spelling and email address as provided in Signed-off-by

Signed-off-by: Akash Gangil<EMAIL_ADDRESS>thanks!

I squashed your commits, but unfortunately, your author name is "Akash Gangil<EMAIL_ADDRESS>and Signed-off-by is Signed-off-by: Akash Gangil<EMAIL_ADDRESS>which don't match.
Can you provide a Signed-off-by with your outlook account?

Signed-off-by: Akash Gangil<EMAIL_ADDRESS>

I merged this.


Too many multi_hit and missense mutation

Describe the issue
When using this powerful tool to plot mutational summary data, I encountered some issues:

I use WES data to generate a filtered VCF file, and then utilize VEP for annotation to obtain an MAF file.
The MAF file contains an excessive number of missense mutations, with up to 10 missense variants occurring in a single gene.
Furthermore, the plot generated by maftools displays an overwhelming amount of multi_hit annotations.
All genes exhibit a 100% occurrence rate.
I'm uncertain as to which step may have led to this issue.

If there is any additional information I should provide to resolve this issue, please do not hesitate to let me know.
Thank you very much.

Command
library(maftools)
laml <- read.maf('vep_merge.maf')
plotmafSummary(maf = laml, rmOutlier = TRUE, addStat = 'median', dashboard = TRUE, titvRaw = FALSE)
oncoplot(maf = laml, top = 30,showTumorSampleBarcodes = F)
Session info

sessionInfo()
R version 4.3.1 (2023-06-16)
Platform: x86_64-pc-linux-gnu (64-bit)
Running under: CentOS Linux 7 (Core)

Matrix products: default
BLAS:   /usr/local/lib64/R/lib/libRblas.so
LAPACK: /usr/local/lib64/R/lib/libRlapack.so;  LAPACK version 3.11.0
locale:
[1] LC_CTYPE=zh_CN.UTF-8       LC_NUMERIC=C               LC_TIME=zh_CN.UTF-8        LC_COLLATE=zh_CN.UTF-8     LC_MONETARY=zh_CN.UTF-8    LC_MESSAGES=zh_CN.UTF-8    LC_PAPER=zh_CN.UTF-8
[8] LC_NAME=C                  LC_ADDRESS=C               LC_TELEPHONE=C             LC_MEASUREMENT=zh_CN.UTF-8 LC_IDENTIFICATION=C
time zone: Asia/Shanghai
tzcode source: system (glibc)
attached base packages:
[1] grid      stats     graphics  grDevices utils     datasets  methods   base
other attached packages:
[1] VennDiagram_1.7.3     futile.logger_1.4.3   circlize_0.4.15       ComplexHeatmap_2.16.0 scales_1.2.1          ggsci_3.0.0           RColorBrewer_1.1-3    agricolae_1.3-7       readxl_1.4.3
[10] lubridate_1.9.3       forcats_1.0.0         stringr_1.5.0         dplyr_1.1.3           purrr_1.0.2           readr_2.1.4           tidyr_1.3.0           tibble_3.2.1          tidyverse_2.0.0
[19] ggrepel_0.9.4         data.table_1.14.8     ggpubr_0.6.0          ggplot2_3.4.4         maftools_2.16.0
loaded via a namespace (and not attached):
[1] tidyselect_1.2.0     digest_0.6.33        timechange_0.2.0     lifecycle_1.0.3      cluster_2.1.4        survival_3.5-5       magrittr_2.0.3       compiler_4.3.1       rlang_1.1.1
[10] tools_4.3.1          utf8_1.2.4           ggsignif_0.6.4       lambda.r_1.2.4       abind_1.4-5          withr_2.5.1          BiocGenerics_0.46.0  stats4_4.3.1         fansi_1.0.5
[19] AlgDesign_1.2.1      colorspace_2.1-0     iterators_1.0.14     MASS_7.3-60          cli_3.6.1            crayon_1.5.2         generics_0.1.3       rstudioapi_0.15.0    tzdb_0.4.0
[28] rjson_0.2.21         DNAcopy_1.74.1       splines_4.3.1        parallel_4.3.1       formatR_1.14         cellranger_1.1.0     matrixStats_1.0.0    vctrs_0.6.4          Matrix_1.6-1.1
[37] carData_3.0-5        car_3.1-2            IRanges_2.34.1       hms_1.1.3            GetoptLong_1.0.5     S4Vectors_0.38.2     rstatix_0.7.2        clue_0.3-65          foreach_1.5.2
[46] glue_1.6.2           codetools_0.2-19     stringi_1.7.12       gtable_0.3.4         shape_1.4.6          munsell_0.5.0        pillar_1.9.0         R6_2.5.1             doParallel_1.0.17
[55] lattice_0.21-8       futile.options_1.0.1 png_0.1-8            backports_1.4.1      broom_1.0.5          Rcpp_1.0.11          nlme_3.1-162         pkgconfig_2.0.3      GlobalOptions_0.1.2

Hi,
You need to filter out germline variants. From your Excel screenshot, it seems that most of the variants are already known to be in dbSNP. There are plenty of articles that can help you get started. Check Filtering with population databases  section here for an examplee.

Hi PoisonAlien,
Thank you for your insights and this paper you've provided. They have been very helpful to me. I wish you all the best. Thank you once again.


Short solution needed: "Get key length in Redis" (redis)

Please help us write most modern and shortest code solution for this issue:
Get key length in Redis (technology: redis)
Fast way
Just write the code solution in the comments.
Prefered way

Create pull request with a new code file inside inbox folder.
Don't forget to use comments to make solution explained.
Link to this issue in comments of pull request.

Get key length in Redis


Fix ClientBaseActor#apps index being number

Foundry declares it as a Record<string,Application|ApplicationV2>

@reonZ I am going to merge this for now, but I am going to revisit this because these mixins are horribly implemented. This issue applies to every other document in the same folder.


Revert changes to remove test app related content in readme

Discussed with Kartik to add test app back.

It looks like there is a merge conflict. Please rebase the source branch to the latest upstream version


FBLoginManager.loginWithPermissions (..) - loginBehaviour?

Is there any way to set the desired login behaviour when not using the FBLogin button but FBLoginManager? Would be really great, since FBLogin doesn't allow too much styling. Thanks!

Have you found out how to do this yet? @skizzo I'm in the same boat. BH

nope, unfortunately not..

can someone here volunteer to test the mentioned PR
and see if this issue is properly resolved for Android
Please continue the conversation in the Pull Request
https://github.com/magus/react-native-facebook-login/pull/105
[install from my fork directly to test (using github url)]

This issue should now be resolved
#130


Improved syntax of the updateBundleConfig method and...

also fixed it in the process. scope was given as a parameter but $scope was used in the method body.

Looks good.

I'll postpone merging this until another change depending on this is ready.


Edit Existing Criteria

Added functionality to edit existing criteria
- Criteria builder will automatically pre-populate fields after user clicks on edit button

This maybe should be its own issue but if you build a criteria and then use that for a different transition the criteria name does not populate


Getting ImportError: No module named evaluation.rank_metrics in Magpie2.0  Ubuntu 16 64 bit

I am trying to execute inspire-magpie with magpie-2.0 version, but it is failing since the current inspirehep-magpie code is  referring magpie-1.0/.
Changes I have made:
In api.py, renamed as
from magpie import Magpie   #- (removed Magpiemodel)
from magpie.config import EPOCHS, BATCH_SIZE  # removed NB_EPOCHS

While executing I am getting error due to the below line
from magpie.evaluation.rank_metrics import mean_reciprocal_rank, r_precision, \
    mean_average_precision, ndcg_at_k, precision_at_k

Error message I am getting :
$ python wsgi.py
/home/user/TrailGitClones/magpie_git/magpie_py2_webins/local/lib/python2.7/site-packages/h5py/__init__.py:36: FutureWarning: Conversion of the second argument of issubdtype from `float` to `np.floating` is deprecated. In future, it will be treated as `np.float64 == np.dtype(float).type`.
  from ._conv import register_converters as _register_converters
Using TensorFlow backend.
Traceback (most recent call last):
  File "wsgi.py", line 19, in <module>
    from inspire_magpie import application
  File "build/bdist.linux-x86_64/egg/inspire_magpie/__init__.py", line 20, in <module>
    from .api import get_cached_model
  File "build/bdist.linux-x86_64/egg/inspire_magpie/api.py", line 28, in <module>
    from magpie.evaluation.rank_metrics import mean_reciprocal_rank, r_precision, \
ImportError: No module named evaluation.rank_metrics

Please provide evaluation module for this.

We removed evaluation modules from Magpie some time ago, Inspire-HEP has not been migrated - it's not really been maintained very well.
You can remove the evaluation code altogether or use this gist to compute some basic metrics for yourself


New pose proposal (#252)

🎉 New feature
Related to #252. To be considered/compared with #581.
Summary

Poses accept rotations in roll, pitch yaw, or quaternions (wxyz), after the usual translations (xyz).
The rotation type can be configured with the attribute //pose/@rotaiton_type, using either rpy_radians, rpy_degrees, q_wxyz, with the default being rpy_radians when unspecified.
Added tests to handle additional spaces or newlines as delimiters between translation and rotation values.

For example, valid poses look like so,
<!-- Read as (x y z   roll pitch yaw), with rotation in radians -->
<pose>1 2 3   0.4 0.5 0.6</pose>

<!-- Read as (x y z   roll pitch yaw), with rotation in radians -->
<pose rotation_type="rpy_radians">1 2 3   0.4 0.5 0.6</pose>

<!-- Read as (x y z   roll pitch yaw), with rotation in degrees -->
<pose rotation_type="rpy_degrees">1 2 3   0.4 0.5 0.6</pose>

<!-- Read as (x y z   W X Y Z), with rotation in quaternions, this is an interesting case, more explanations below -->
<pose>1 2 3   0.707 0.707 0 0</pose>

<!-- Single space delimiter -->
<pose>1 2 3 0.4 0.5 0.6</pose>

<!-- Multiple space delimiters -->
<pose>1 2 3   0.4 0.5 0.6</pose>

<!-- Newline delimiters -->
<pose>
  1 2 3
  0.707 0.707 0 0
</pose>

Implementation details,

Added API for SetParentElement and GetParentElement, modified Element::Clone, Element::Copy to handle setting parent elements for each child value or attribute
SetParentElement attempts to parse previous string-ified values using new parent element attributes, 7 value quaternions changing parent to rpy_degrees which expects 6, will fail, this is covered in tests

Considerations:

After assigning a parent and having its values correctly parsed, the parent Element could have its rotation_type attribute changed, but that the underlying Param will have no way of knowing it. I considered re-evaluating the string-ified values during Get<> functions, but it is a const function, so the values should not change at that point. Unless there is a sort of reactive way to notify children when parent's attributes change, we will have to allow these issues to exist.

param->SetParentElement(RpyElement);
param->SetFromString("1 2 3   0.4 0.5 0.6");

auto rotationType = RpyElement->GetAttribute("rotation_type");
rotationType->Set<std::string>("q_wxyz");

ignition::math::Pose3d val;
param->Get<ignition::math::Pose3d>(val);
// val will still be (1 2 3   0.4 0.5 0.6), instead of failing or getting set to something else

Test it

source ws/install/setup.bash
colcon test --merge-install --packages-select sdformat12

Checklist

[x] Signed all commits for DCO
[x] Added tests
[x] Added example and/or tutorial
[ ] Updated documentation (as needed)
[ ] Updated migration guide (as needed)
[x] Code check passed (In source directory, run sh tools/code_check.sh)
[ ] All tests passed (See test coverage)
[ ] While waiting for a review on your PR, please help review
another open pull request
to support the maintainers

Note to maintainers: Remember to use Squash-Merge

@aaronchongth My understanding according the the updated proposal was that the "simpler" implementation would use the //pose/@rotation_type attribute instead of //pose/translation and //pose/rotation. So for the examples you gave, it would be:
<!-- Read as (x y z roll pitch yaw), with rotation in radians -->
<pose>1 2 3   0.4 0.5 0.6</pose>

<!-- Read as (x y z roll pitch yaw), with rotation in radians -->
<pose rotation_type="rpy_radians">1 2 3   0.4 0.5 0.6</pose>

<!-- Read as (x y z roll pitch yaw), with rotation in degrees -->
<pose rotation_type="rpy_degrees">1 2 3   0.4 0.5 0.6</pose>

<!-- Read as (x y z W X Y Z), with rotation in quaternions -->
<pose rotation_type="rpy_qwxyz">1 2 3   0.707 0.707 0 0</pose>

Do you mind updating this PR to support //pose/@rotation_type?

Thanks for pointing it out, @azeey! I have just made the changes, and tried to adhere more to the proposal.

Codecov Report

Merging #589 (d0f45cc) into main (6a6aba1) will decrease coverage by 0.07%.
The diff coverage is 71.11%.

:exclamation: Current head d0f45cc differs from pull request most recent head 8480dd6. Consider uploading reports for the commit 8480dd6 to get more accurate results

@@            Coverage Diff             @@
##             main     #589      +/-   ##
==========================================
- Coverage   87.54%   87.46%   -0.08%
==========================================
  Files          72       72
  Lines       10514    10557      +43
==========================================
+ Hits         9204     9234      +30
- Misses       1310     1323      +13

Impacted Files
Coverage Δ

src/Param.cc
89.56% <65.78%> (-2.80%)
:arrow_down:

src/Utils.cc
86.56% <100.00%> (+0.62%)
: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 6a6aba1...8480dd6. Read the comment docs.

sh```

1 2 3   0.707 0.707 0 0

This has a weird smell; I think this code (if it works) is doing too much. If @rotation_type isn't specified, then the semantics should only be that of rpy_radians; nothing additional should be inferred from malformed / different sized values, IMO.
Otherwise, an innocent typo can be accepted in a very confusing way.

Codecov Report

:exclamation: No coverage uploaded for pull request base (main@6a6aba1). Click here to learn what that means.
The diff coverage is n/a.

@@           Coverage Diff           @@
##             main     #589   +/-   ##
=======================================
  Coverage        ?   87.42%
=======================================
  Files           ?       72
  Lines           ?    10581
  Branches        ?        0
=======================================
  Hits            ?     9250
  Misses          ?     1331
  Partials        ?        0

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 6a6aba1...e409e1f. Read the comment docs.

@azeey Per VC, https://github.com/ignitionrobotics/sdformat/pull/589/commits/3e42314ac2630f782a6c3be45f5105dab441a215 avoids  the use of IGN_DTOR in the tests, and instead attempt to make the calculations more explicit. Let me know what you think.

I was thinking about the proposed semantics this morning.
I think that the choice of rpy_degrees and rpy_radians makes the rotation_type attribute double-barreled. Something like <pose rotation_type="rpy" angles="degrees"> or <pose rotation_type="rpy" degrees="True"> could be more extensible, because future improvements; in particular allowing other euler rotations, will only add one new case (e.g., ryp) instead of two (e.g., ryp_degrees, ryp_angles).
The choice of attribute name, rotation_type, is a little confusing. In 3D all rotations have the same type, typically called simple, and are rotations in a plane by some angle. (off-topic: you can find other types in higher dimensions, e.g., 4D has simple and double rotations, 6D simple, double, and triple rotations, etc.) However, while all rotations are simple, there are many ways to describe 3D rotations: 12 sets of Euler angles, rotation vector, 2 quaternions, ... Long story short, perhaps it could be an option to rename rotation_type to something like rotation_format because we are actually talking about the same rotation/type; just represented differently.
I also, mistakenly, thought that the attribute name would be type and not rotation_type as proposed here. This lead me to a bit of an alternative idea that compromises between this proposal and #581 . Instead of introducing a rotation_type, we could introduce a type/format string that describes how each value in the element's text is to be interpreted. Matching the examples given above:
<!-- Read as (x y z roll pitch yaw), with rotation in radians -->
<!-- remains backwards compatible -->
<pose>1 2 3 0.4 0.5 0.6</pose>

<!-- Read as (x y z   roll pitch yaw), with rotation in degrees -->
<!-- or which ever mechanism will be chosen for deg/rad -->
<pose degrees="True">1 2 3   0.4 0.5 0.6</pose>

<!-- Read as (x y z roll pitch yaw), with rotation in radians -->
<pose format="x y z r p y">1 2 3 0.4 0.5 0.6</pose>

<!-- Read as (x y z), no rotation :O -->
<!-- unspecified values in the format string are 0 -->
<pose format="x y z">1 2 3</pose>

<!-- Read as (roll pitch yaw), no translation -->
<!-- unspecified values are simply 0 -->
<pose format="r p y">0.4 0.5 0.6</pose>

<!-- Read as (roll pitch yaw) in degrees, no translation -->
<pose format="r p y" degrees="True">90 45 11.25</pose>

<!-- Read as (w x y z) quaternion -->
<pose format="qw qx qy qz">0.707 0.707 0 0</pose>

<!-- Read as (x y z, w) quaternion -->
<pose format="qx qy qz qw">0.707 0 0 0.707</pose>

<!-- Read as (x y z qw qx qy qz), translation + wxyz quaternion -->
<pose>1 2 3 0.707 0 0 0.707</pose>

One could think of allowing similar syntax as Scipy Rotation for euler angles, which would allow adding the missing ones and reducing clutter for rotations only involving one or two axes. Here capital letters denote rotations
wrt. the parent frame and lower case wrt. the current frame:

<!-- Read as (pitch roll yaw) euler rotation (current frame) -->
<pose format="p r y">0.4 0.5 0.6</pose>

<!-- Read as (pitch roll yaw) euler rotation (parent frame) -->
<pose format="P R Y">0.4 0.5 0.6</pose>

<!-- Read as roll-only rotation in degrees, no translation -->
<pose format="r" degrees="True">90</pose>
<!-- parent/current axes are identical in this case -->
<pose format="R" degrees="True">90</pose>

<!-- Read as translation along X only -->
<pose format="X">2.34</pose>

One could allow format="RpY", i.e., mixing parent and current frame rotations, but personally, I would not allow that because it quickly gets confusing and I can't come up with a scenario where you might want that. It could still be added if somebody needs it.
There are two corner cases related to quaternions: (1) specifying partial quaternions, e.g. format="qx qw" and (2) specifying both a euler rotation and a quaternion, e.g. forma="qw qx qy qz r p y". This can be handled by again defaulting to 0 if unspecified and introducing a preference for quaternions over euler angles (i.e. ignoring euler if quaternion is specified), but personally, I would probably raise an exception as it is most likely caused by user error.
It also has the same problem as previous approaches with <pose format="qx qy qz qw">0 0 0 1</pose>, but I guess that needs to be handled explicitly in either case.

Greetings @FirefoxMetzger! Those are very valid points, thanks for bringing them up.
For some background information, the proposal can be found here, which hopefully describes this implementation and the reasons behind it a little better, just in case I miss out anything.

perhaps it could be an option to rename rotation_type to something like rotation_format because we are actually talking about the same rotation/type; just represented differently.

The ambiguity would certainly be a problem going forward, you are right that we are technically just describing different ways of parameterizing a rotation in 3D. In the proposal it looks like //pose[@representation] or //pose[@rotation_representation] might have already been considered, but for the sake of keeping the description concise, //pose[@rotation_type] was decided on.

Something like  or  could be more extensible, because future improvements; in particular allowing other euler rotations, will only add one new case (e.g., ryp) instead of two (e.g., ryp_degrees, ryp_angles)

Instead of introducing a rotation_type, we could introduce a type/format string that describes how each value in the element's text is to be interpreted.

My first intuition regarding supporting these features, would be that though they are highly extensible, we would potentially allow users to make more accidental mistakes that are not easy to debug, especially in simulations with a large number of models, some of which might have their poses handcrafted or copy-pasted from other sources.
With supporting any preferred permutations of elements like qw qx qy qz, qx qy qz qw and maybe even qw x y qy qz z qx (highly unlikely I hope),  I see readability being a huge issue as well.
Regarding the order of representation, it appears that we would also be respecting the suggested representations and order by ROS, REP 0103.

wrt. the parent frame and lower case wrt. the current frame

For relative frames, frame semantics are supported that can be defined using the additional attribute of relative_to in poses, except for waypoint poses in actor, and in inertial.
Thanks again for raising these points! It'd be awesome if you have specific use cases and reasons for the implementations you just proposed, we can discuss more and see how we can fit this into the proposal.

In the proposal it looks like //pose[@representation] or //pose[@rotation_representation] might have already been considered, but for the sake of keeping the description concise

Yes, I saw that section:
Use @representation instead of @type

While "representation" may be a better word than "type", it would be nice to be less verbose while still being concise (e.g. avoiding abbreviations).

The argument for type is that it is less to ... type (the pun!). Personally, I don't think that is a good argument to sacrifice clarity to reduce verbosity, since XML is unavoidably verbose by nature already. In the present case (@format) the difference to @type is 2 characters, and it actually beats @rotation_type assuming we would include the translation part (albeit being more sensical in this case).
I do understand that this is a nit-pick though; in particular, because most users will come from a 3D background and won't need to differentiate between rotation types and representations. All of the considered names work; they just make more or less intuitive sense depending on the final behavior of pose.

we would potentially allow users to make more accidental mistakes that are not easy to debug

I assume you are mainly worried about the format string going too wild? One could simply impose a restriction on what is allowed, e.g., translation comes before rotation, quaternions need to be fully specified (all 4 components), and quaternions and euler angles can't be mixed. This can then be validated with a corresponding regex, e.g., ^X?Y?Z?((r?p?y?)|(qwqxqyqz)?|(qxqyqzqw)?)? (assuming spaces don't matter).
I also just noticed ambiguity between y as an axis and y as yaw rotation, so perhaps strings of the form x y z roll pitch yaw could be more legible?

With supporting any preferred permutations of elements like qw qx qy qz, qx qy qz qw and maybe even qw x y qy qz z qx (highly unlikely I hope), I see readability being a huge issue as well.

Yes, I would also constrain the total number of possible combinations (see above). However, scalar-first and scalar-last quaternions (qw qx qy qz, qx qy qz qw ) have a quite valid use. Scipy (and - hence - most of the scipy universe) uses scalar-last, whereas gym-ignition  and some of if it's dependencies use scalar-first. I'm not sure what ROS does, but my guess is scalar-first.
People coming from the python side will tend to scalar-last, whereas I assume people coming from the ROS side will tend to scalar-first notation. It would be nice if SDF can accommodate both and decrease its learning curve for both communities.
From personal experience  remembering when and how to swap the order is rather error-prone. It also doesn't throw an exception, which makes it hard to find if it does happen. It would be much nicer to just dump the desired config into SDF and let ignition (or any SDF compliant parser) handle the conversion. This way python code can do its python thing, ROS-centric C++ code can do its ROS thing, and the end-user (me) has one problem less to worry about.
Of course, you introduce the potential problem of miss-matching the format string and the pose value if things are manually specified. This is definitely possible; however, I think if you write SDF manually then it is probably better to stick to Euler angles and degrees since they are significantly more intelligible.  In this particular case, it would be even better if you could avoid specifying 0 angles. This will further reduce the change of misspecification - you can't accidentally swap the angle with a 0 - and it is less to type.

For relative frames, frame semantics are supported that can be defined using the additional attribute of relative_to in poses,

Oh no, I think we are misunderstanding each other here. I'm talking about intrinsic and extrinsic Euler angles. (see: https://en.wikipedia.org/wiki/Euler_angles#Conventions_by_intrinsic_rotations)
I'm aware that poses can be specified relative to an arbitrary frame that isn't the parent frame. (Which - btw - I learned is a real snake pit. The docs claim that @relative-to may refer to any named /frame in any of the elements parents (the poses scope?), which makes you think that only  elements are valid targets. It doesn't mention that some elements apparently implicitly create such a frame and I still haven't quite worked out which do, and which don't.)

I'm impartial to @rotation_type vs @rotation_format and having a separate attribute for degrees make sense. I think we need to strike a balance between expressiveness, readability, being error prone, and complexity of parsing. Having a format string specifying individual tokens adds a lot of expressiveness, but IMO, reduces readability because I now have to understand the various formats available instead of just a handful standard options. It also adds more complexity to the parser logic, so I'm not sure if it's worth the effort.
Regarding scalar-first vs scalar-last quaternions, I think we are being explicit in the parameter q_wxyz to avoid the confusion. There is no need to remember which one comes first on the SDFormat side, but if you are generating the quaternion from another library, you still have to know how that library formats its quaternions in order to tell SDFormat whether it's q_wxyz or q_xyzw, so having the option in SDFormat to do both doesn't really help in terms of having to remember things. I would be in favor of supporting only one type/format as long as we're being explicit.

so I'm not sure if it's worth the effort.

I agree; it depends on the requirements. You can have a format that is expressive and adapts to the way you think (pro: easy to manually write SDF, con: more difficult to write parser logic), or you can adapt the way you think to the format (pro: easy to write parsers and easy to verify, con: more error-prone when writing SDF manually).
My current understanding (I could be wrong) is that the ideal solution is /pose/translaion /pose/rotation, but that combination isn't backwards compatible, so the next idea is pose@rotation_[type|format]. The motivation for this is to make it easier to manually write SDF, which suggests that - in the current version - it may not be expressive enough. I have written only little SDF by hand, and mostly for templating, e.g., https://github.com/FirefoxMetzger/panda-ignition-sim/blob/c46220549ce27ee358ea96e3724f4abccef80638/sdf/cube_template.sdf.in , so I can't comment on that aspect too much. However, extrapolating from my experience on urdf, I have to say that being able to only specify angles or translations would make turning DH parameters into SDF a lot easier.
Perhaps there is a middle ground between a format string and this proposal, by having verbose names for a small set of well-defined formats, e.g.  or some other phrasing with default translation_euler. This is essentially what @aaronchongth proposed here, but including the translation into it and allowing to drop either the rotation or translation. I still like single angles, given how useful they are wrt. how we typically choose coordinate frames, but I'm also happy to forego it since this is again something that bindings can take care of.

I would be in favor of supporting only one type/format as long as we're being explicit.

I'm confused. Wouldn't the logical consequence from this maxim be to add neither quaternions nor degrees and stick with x y z roll pitch yaw? There's no ambiguity and it is definitely explicit. I feel like there are two contradictory use-cases here (manual vs automated SDF creation/reading) and the question is which one should be given more weight. On the one hand there is the /pose/translaion /pose/rotation and @degrees proposal, which is very much geared towards manual read/write of SDF, and on the other, there are quaternions, which are very much geared to automated read/write (or maybe it is just me that finds them illegible compared to Euler angles in degrees).
I do agree though that my scalar first/last problem with quaternions can (and probably should) be solved on the parser/serializer level, making it not a very strong argument.

Howdy @FirefoxMetzger!

Re: @rotation_type vs. @rotation_format - rotation_format seems good! (if we stick with this setup)

In 3D all rotations have the same type, typically called simple ([...] 4D has simple and double rotations, 6D simple, double, and triple rotations, etc.)

TIL - thanks!

Re: double-barreled rotation_format="rpy_degrees" vs rotation_format="rpy" degrees="true" or angles="degrees"
Good point on double-barreled-ness!
Concern about a separate attribute is how we handle incompatible combinations; e.g. for a quaternion, degrees="true" or angles="degrees" seems wrong, and degrees="false" / angles="radians" also seems wrong.
Caveat: Choosing a default for binary-valued attribute gets awkward fast when things are incompatible.
Perhaps we could have a default value of angle_units="" resolve to angle_units="radians" if the representation supports it...

I'm confused. Wouldn't the logical consequence from this maxim be to add neither quaternions nor degrees and stick with x y z roll pitch yaw?

The primary motivation outlined in the proposal is for degrees - there are concrete usages of very bad "semi-radians" (e.g. 1.57) when people are writing their models. I'd like to provide a minimum-effort solution to avoid "semi-radians" from being used, if possible.
That being said, you are right about quaternions being a bit of an awkward middle ground. The proposal has no useful motivation for quaternions for the "short-term" solution.
In light of above, we could fully simplify and stick purely to the Euler convention we have, and add one simple attribute, degrees="true" or angles="degrees|radians".
What do y'all think?

Re: @format="translation_{rotation_format}|translation|{rotation_format}"
I can see this being a bit crisper (fewer zeros), but still concerned on additional complexity. As a user, I'm fine with padding it with some zeros to get the translation or rotation only.
I don't have a good suggestion from here, but I say we hold off pending decision on above (no quaternion, if possible).

Re: format string, [x y z roll pitch yaw qw qx qy qz] (or rx ry rz for rotations along axes)
Agreed w/ @azeey about complexity at this point, especially if targeting the "cheap" version of the proposal (or the now "cheaper" version, degrees only).

(or any SDF compliant parser - shameless self plug scikit-bot)

Nice! Would you mind if that were referenced from the SDFormat website?

I also, mistakenly, thought that the attribute name would be type [...]

My bad! Typos in the proposal (edited across a few months).

Given feedback on above, will make PR to proposal to update accordingly (and fix typos).

In light of above, we could fully simplify and stick purely to the Euler convention we have, and add one simple attribute, degrees="true" or angles="degrees|radians".

Works for me.

Nice! Would you mind if [scikit-bot] were referenced from the SDFormat website?

@EricCousineau-TRI I'd be happy if you link it. I would ask though that you wait a couple days with doing so, since I'm currently rebranding the library from ropy into scikit-bot. Long story short, I added semantic versioning but ropy was taken on pypi and the only other robotics-related scikit I'm aware of doesn't seem to be maintained anymore. As a result of this rebranding, a lot of the existing links will change their name.
I can notify you when I'm done if you tell me place where to do so; otherwise it should be finished by Monday.

My bad! Typos in the proposal (edited across a few months).

I think it's mainly my fault of remembering wrongly. I read the propsal and then went off to do household chores while thinking about it and must have remembered wrongly.

The proposal has no useful motivation for quaternions for the "short-term" solution... we could fully simplify and stick purely to the Euler convention we have

For what it's worth, I was looking forward to quaternion support because I often have to make the conversion to Euler to fill SDF files. For example, Ignition messages hold quaternions, and that's what you get when echoing them. I often echo the user camera pose or a model's pose and then copy that into an SDF file.
It's just a very specific use case that I don't think affects many people though. And there are other ways of addressing it without changing the SDF spec. Some options are command line tools (https://github.com/ignitionrobotics/ign-math/issues/198), or GUI tools (https://github.com/ignitionrobotics/ign-gazebo/issues/174).
I'm just mentioning that for future reference, but I agree with the goal of keeping the spec simple and easy to read by supporting only one format.

The proposal has no useful motivation for quaternions for the "short-term" solution... we could fully simplify and stick purely to the Euler convention we have

For what it's worth, I was looking forward to quaternion support because I often have to make the conversion to Euler to fill SDF files. For example, Ignition messages hold quaternions, and that's what you get when echoing them. I often echo the user camera pose or a model's pose and then copy that into an SDF file.
It's just a very specific use case that I don't think affects many people though. And there are other ways of addressing it without changing the SDF spec. Some options are command line tools (ignitionrobotics/ign-math#198), or GUI tools (ignitionrobotics/ign-gazebo#174).
I'm just mentioning that for future reference, but I agree with the goal of keeping the spec simple and easy to read by supporting only one format.

I have also seen the advantage of being able to encode rotations in an SDFormat file. I can't intuit their meaning through visual inspection like I can with our rpy angles, but there are some tools that produce Quaternions, so being able to copy and paste them without trying to convert correctly would be helpful. Also, as long as you know whether it's wxyz or xyzw, Quaternions are less ambiguous than Euler angles.
Also, see https://github.com/ros/urdfdom/issues/13 which has had several 👍  attached and an attempted pull request (which ultimately stalled due to the lack of support for versioning in URDF). I would support a version string that describes the encoding like quaternion_wxyz or quat_wxyz.
I'd prefer to avoid providing completely configurable format strings to reduce parser complexity.

I'm a bit concerned that this review has morphed into design discussions that are deviating substantially from the proposed design from https://github.com/ignitionrobotics/sdf_tutorials/pull/37 that was recently accepted (viewable at http://sdformat.org/tutorials?tut=better_pose_proposal ). I hadn't been following the commentary here very closely because I had assumed they were related to the implementation, not the design itself. I appreciate the insights that @FirefoxMetzger is bringing to the table, but I think it would be easier to discuss changes to the design by making and reviewing pull requests against the following document:

https://github.com/ignitionrobotics/sdf_tutorials/blob/master/specify_pose/proposal.md

I am comfortable with a single attribute, whether it's called //pose/@rotation_type or something else (option 1.B. from that proposal). I also see value in being able to use quaternion coefficients, but I'm not set in stone on this. I'd like to reach consensus about this, and I hope that pull requests to directly discuss design changes will help to reach consensus and ensure that other members of the ignition team have a chance to review the changes to this design.

[...] Ignition messages hold quaternions, and that's what you get when echoing them. [...] and then copy that into an SDF file.

[...] Quaternions, so being able to copy and paste them without trying to convert correctly would be helpful

This doesn't seem ideal. I mean, I understand the need to manually edit sdf files and I particularly agree with the need for easy introspection to find error sources. I'm a bit concerned when we start to enter copy/paste territory since that is something machines should be much better at. For example, one could slap together a small python script that subscribes to the simulator, fetches the next pose, and puts it somewhere, e.g. stdout. (Does ignition use REQ/REP in parallel to PUB/SUB like ROS services? if so this would be even better).
(from the top of my head; untested)
import sys
import skbot.ignition as ign
from scipy.spatial.transform import rotation as rot

with ign.Subscriber(sys.argv[1]) as topic:
    pose_msg = topic.recv(timeout=-1)

# this block depends on the exact message format
# notice that python uses xyzw quaternions
quaternion = (
    pose_msg.quaternion.x,
    pose_msg.quaternion.y,
    pose_msg.quaternion.z,
    pose_msg.quaternion.w
)

euler = rot.from_quat(quaternion).to_euler("xyz")
sdf_rpy = " ".join(euler)
print(sdf_rpy)

Then again this is purely a design decision. SDF //pose can optimize for readability or it can optimize for writability (quaternions, perhaps more features); it seems to be a point where improving one deteriorates the other. I have a preference, but I can ultimately work with both; the only question is in which direction to bias SDF.

I appreciate the insights that @FirefoxMetzger is bringing to the table, but I think it would be easier to discuss changes to the design by making and reviewing pull requests [...]

I originally asked (https://github.com/ignitionrobotics/sdformat/issues/646#issuecomment-889683530) where to comment on proposals and understood that I was to comment directly on the PR; reading it again perhaps I misunderstood? If this is not the right place to discuss, I will not continue here. That said, I currently don't have spare time to spearhead drafting a full counter-proposal.

Then again this is purely a design decision. SDF //pose can optimize for readability or it can optimize for writability (quaternions, perhaps more features); it seems to be a point where improving one deteriorates the other. I have a preference, but I can ultimately work with both; the only question is in which direction to bias SDF.

That makes sense. Specifying roll-pitch-yaw in degrees maximizes human readability, but allowing quaternions or other formats enhances writability. I would add another factor to consider, which is complexity of the parsing task. While supporting generic format strings for the pose coefficients would expand writability, I'm concerned about the additional complexity required of the parser.

I appreciate the insights that @FirefoxMetzger is bringing to the table, but I think it would be easier to discuss changes to the design by making and reviewing pull requests [...]

I originally asked (#646 (comment)) where to comment on proposals and understood that I was to comment directly on the PR; reading it again perhaps I misunderstood? If this is not the right place to discuss, I will not continue here. That said, I currently don't have spare time to spearhead drafting a full counter-proposal.

My apologies for not answering your comment there. I suppose this is a fine place to discuss alternative designs, but if we're going to pursue a design that differs substantially from https://github.com/ignitionrobotics/sdf_tutorials/pull/37, then we should open a pull request in parallel to document those changes. I can try to close the loop with @EricCousineau-TRI, @azeey, and @aaronchongth as well to make sure we're all on the same page. We'll keep your current set of comments in mind even if you don't have time for a counter-proposal.

Apologies for the late reply, @FirefoxMetzger! Thanks for the feedback so far, I spent some time prototyping your suggestion regarding separating the attributes into rotation_format="rpy|q_wxyz" and degrees="true|false", and found the separation of concern very attractive.

I suppose this is a fine place to discuss alternative designs, but if we're going to pursue a design that differs substantially from ignitionrobotics/sdf_tutorials#37, then we should open a pull request in parallel to document those changes.

That sounds good, as of now this PR has deviated slightly from the proposal, by leaving out quaternion support, and keeping the changes to just the addition of //pose[@degrees]. I may be wrong, but in this scenario, I believe it may be a good idea to reduce the scope of the current proposal, https://github.com/ignitionrobotics/sdf_tutorials/blob/master/specify_pose/proposal.md to what was agreed for this current PR, and start a new proposal for the possibility of supporting quaternions, and other variations that has been suggested in this thread. This should allow us to continue this discussion and pin it into a new proposal for future iterations. LMKWYT @azeey @EricCousineau-TRI @scpeters

Let's go ahead with just //pose[@degrees] for this PR and address other concerns in a follow up PR.

Let's go ahead with just //pose[@degrees] for this PR and address other concerns in a follow up PR.

sounds good

Per VC, Aaron to fix printing of poses so that if degrees=true, poses will be printed in degrees.

Thanks for the note, @azeey! This commit https://github.com/ignitionrobotics/sdformat/pull/589/commits/9ac3504b6889d07c33851f39636ccab9ab1c92b2 should be fixing the problem and contains some tests too. The expected values from certain models in other tests have changed as well, I have made the necessary changes.


always return the request id in the error

Pretty simple change - just return the request id if it is actually present, even if the error is an unknown type.  this makes debugging a lot easier, in cases where we aren't getting a good error back from the nodes for some reason.

@glitch003
Only thing that concerns me with this is the cases where we throw errors due to validation and we have not yet sent any request to a Lit Node. If we introduce the request id validation errors client side will get this value and it wont map to a node request.

for sure - in that case, we just print "no request id found" as you can see here https://github.com/LIT-Protocol/js-sdk/pull/490/files#diff-f8df194ec35cd4e8d5042228b9163d51921c46776ca48fac0613bdbd87e965f9R208
so i think this is fine, because like it doesn't add any additional requirements.  call throwError with or without a request id, it still works.  but, if there is a request id, then at least print it.
this PR came from my frustrations of running the SDK with debug off, and occasionally getting this kind of error with no request id in it, which made it hard to debug on the node side.  i did manually test this in pkp-parallel-keygen and it showed the request id, so it accomplished my goal.

Ah yes we do see that. Makes sense l the traces will be more consistent. Merging now!


Registrator support

@JuliaRegistrator register()

Registration pull request created: JuliaRegistries/General/266
After the above pull request is merged, it is recommended that you create
a tag on this repository for the registered package version:
git tag -a v0.1.0 -m "<description of version>" 03e48bb8112ef8458686dac4add1ea3b1d63d960
git push origin v0.1.0


Add an explanation of gradle-wrapper.jar

As a file without source it looks suspicious at first glance for someone not familiar with Gradle. Adding a short explanation with link to the verification process would've been beneficial.
https://docs.gradle.org/current/userguide/gradle_wrapper.html#wrapper_checksum_verification

Thanks for the input. I've added a Github action to avoid malicious code injection and updated the README.md.


Random Crashes ...HELP!

Hi.
I have this version apparently running OK.

THE PC:
Installed v1.6.2 in RDP Wrapper folder in C:\Program Files
autoupdate.bat working OK  (with Task Scheduled for startups).
Windows 10 PRO 21H2  19044.1766
CPU AMD Ryzen3 3300 (8 threads) 3.80 Mhz
32 GB DDR4 RAM 3200 Mhz
Nvidia GeForce GT730 4GB vRAM
AnyDesk is installed (but uninstall it not change anything).
Some Acronis backup software running.
All for emails, MS-Excel and MS-Access tasks, printing, etc.
With 1 or 2 additional sessions works OK  (some 1080p, 2K or 4K).
With more than 3 sessions randomly crashes, closes. Sometimes only Windows Clients closes and session in the main computer is still open and running, and the solution is reconnect.
Another times, sessions seem freeze and the only solution is to close client, and reopen, finding all work lost. Most times totally crashes, client closes, and any work in programs was lost at reopen.
Most connections are LAN and some ones are Zero-Tier VPN. This ones fail less.
Sometimes at login passwords are well entered but not accepted, and need to be reentered.
Another similar PC with more powerful hardware (32 threads, 8GB vRAM) works with same version, supporting without problems more than 8 sessions mostly 1080p (no ZeroTier VPN in this one).
Can anyone please help?

Are you using original termsrv.dll.
Try sfc /scannow

Are you using original termsrv.dll?
Try sfc /scannow

I have not knowingly made any modifications or manually applied any patches to the termsrv.dll file.
Nothing intentional. How could I confirm that it is the original?
The sfc /scannow thing was the first thing I did when the problems arose. This is a fresh Windows 10 installation, on new hardware. Previously there was a Windows 7 pro with rdp wrapper on that PC as well, working for years without any problem. This is a fresh new install of Windows 10, with these problems from the start, from 5 months or so ago.
Thanx for reply.

I have not knowingly made any modifications or manually applied any patches to the termsrv.dll file.
Nothing intentional. How could I confirm that it is the original?

Checking the integrity of system files (sfc /scannow) is usually sufficient for this.

This is a fresh new install of Windows 10, with these problems from the start, from 5 months or so ago.

Perhaps the problems are offsets, but I doubt that in a few months no one else noticed them.
If you want to make sure that the problem is not with the system, but with the RDP Wrapper, then look at the ServerRdsh (Enterprise for Virtual Desktops) edition. All the information is on Google and on the My Digital Life forum.

For a better clarification of the reason, it is better to ask in the Telegram chat of the project or in the Discoed server of the offset developer (sebaxakerhtc)

Closed as answered. The causes of random crashes are currently unknown.

I found the solution. But this issue seems closed.


Change Node.js executable to be a variable

Node.js executable can be a variable with this change since the actual name of the executable varies with the distribution. Newer Debian distributions - Ubuntu 14.04 LTS uses 'nodejs' instead of 'node'.

build.py is gone, so this change is not relevant anymore.


Rewrite the backend in Flask

@ivantha Hello sir, can you provide some details whether this will be related to a project idea for gsoc 2020? I am very excited to work on this!

@ivantha which database are you thinking of using? are we continuing with mongodb?

@ivantha Hi I'm interested to take over this project for GSOC 2020. I have a good experience in flash and I can rewrite this backend in Flask


[rules] Fix OTP digest rule to use execution platform

Use the execution platform's config for opentitantool, so it does not build an RV32 variant when we want to run on the host.

For some reason, the config_setting //sw/device:is_english_breakfast is not getting activated for otp_alert_digest targets:
bazel build    --copt=-DOT_IS_ENGLISH_BREAKFAST_REDUCED_SUPPORT_FOR_INTERNAL_USE_ONLY_    //hw/ip/otp_ctrl/data:otp_json_alert_digest_cfg

yields failures to find constants defined only for top_earlgrey, when that module should be removed by the english_breakfast crate feature.

rules/otp.bzl appears to have gotten a commit that changed it and resolved the issue this is addressing.
The rcfile is not set in rules/otp.bzl in "master" there's no longer an otp_alert_digest

I'm not sure that isn't random luck, as opposed to proper configuration for opentitantool ;)
However, it seems setting it up to use the execution platform's configuration gets rid of all our config settings, which makes this not work for english_breakfast:
//hw/ip/otp_ctrl/data:otp_json_alert_digest_cfg (8d0053f)
  otp_img#//hw/ip/otp_ctrl/data:otp_json_owner_sw_cfg#(TestTrimmingTransition + ConfigFeatureFlagTaggedTrimmingTransition) -> 8d0053f
  $opentitantool#//sw/host/opentitantool:opentitantool#(exec + (TestTrimmingTransition + ConfigFeatureFlagTaggedTrimmingTransition)) -> 3e68476
    action_env:[BAZEL_CXXOPTS=-std=gnu++14] -> [[]]
    compilation_mode:fastbuild -> [opt]
    is exec configuration:false -> [true]
    platform_suffix:null -> [exec-2B5CBBC6]
    fat_apk_cpu:[armeabi-v7a] -> [[]]
    conlyopt:[-std=gnu11] -> [[]]
    copt:[-DOT_IS_ENGLISH_BREAKFAST_REDUCED_SUPPORT_FOR_INTERNAL_USE_ONLY_] -> [[-g0]]
    cxxopt:[-std=gnu++14] -> [[-g0]]
    strip:never -> [always]
    java_runtime_version:local_jdk -> [remotejdk_11]
    jvmopt:[] -> [[-XX:ErrorFile=/dev/stderr]]

Out of curiosity, which config settings are we losing?

For this round, just running with a new idea to check for bugs. Cleanup is needed.

I believe the failing test has a known bug--Please kick me if I did this too soon. ;)
Merging...

Thanks to Alex and the reviewers!


filename should be normalized in lgb.save()

On Ubuntu.
file path like '~/a/b.txt' wont work.
but file path like '/home/user/a/b.txt' works.

please using pathlib for the transfer relative path first.


Strategy updates: passive and active

Currently, the smart strategy removes entries when they get deleted and tries to add them to lists (in the right spot) if they match the query.
There are some edge cases that currently are not covered:

If the entry is smaller or larger it will get added to the beginning or the end of the list respectively. This might not necessary be the case (e.g. when you $skip and $limit there is no certain way of determining if it is in the list or comes at a position after/before)
If an entry gets deleted, it gets removed from reactive lists. If you set $limit they can end up smaller than what you would expect.

If you wanted to cover those edge cases you would use the always strategy which is less than ideal (ultimately I'm not sure it should exist at all).
This is where I think it makes sense to introduce two new list strategies (and remove the smart strategy):
Passive
The passive strategy will update exiting entries in the list (and re-order accordingly) and remove deleted entries but otherwise not modify it (new or updated entries that match the query will not be added).
Active
The active strategy will request a window slightly larger than $limit to be aware of its surrounding entries. That way it will be able to determine for any matching entry where it fits in. If the window gets too small (e.g. because entries were removed from the list) it will re-request a new list.

I recently cleaned up the strategies a little further and made the source a real cold observable (https://github.com/j2L4e/feathers-reactive/blob/cleanup/src/utils.js#L10).
With this we can just switch the stream to the source to refetch data from the server. Implementing the above should be way easier that way. Check how 'always' does it now: https://github.com/j2L4e/feathers-reactive/blob/cleanup/src/strategies.js#L25

A solution for the second (and easier to solve) edge case and requerying in general:
https://github.com/feathersjs-ecosystem/feathers-reactive/compare/autoretry#diff-2b4ca49d4bb0a774c4d4c1672d7aa781R87


cannot subscribe to newsletter on yaoapps.com

Hi,
I'm trying to subscribe to the newsletter from homepage, but I get "Email format validation error!"
Gregorio

My email is in format<EMAIL_ADDRESS>

My email is in format<EMAIL_ADDRESS>
Thanks feedback,i will fix it.

@gregoriopellegrino
I have been fixed it.


from_radix with empty buffer

Calling from_radix_le panics when called with an empty buffer (same for from_radix_be).
This should simply return the value zero, isimilar to how from_bytes_le (and from_bytes_be) return zero.
https://docs.rs/num/0.3.1/num/bigint/struct.BigUint.html#method.from_radix_le

Yes, I agree those should return zero. Would you like to make that change?

Yes, I agree those should return zero. Would you like to make that change?


Include attribute types when listing category products

Closes #131

Codecov Report
Base: 97.88% // Head: 97.88% // No change to project coverage :thumbsup:

Coverage data is based on head (5956c73) compared to base (fff8fed).
Patch coverage: 100.00% of modified lines in pull request are covered.

:exclamation: Current head 5956c73 differs from pull request most recent head a865d7e. Consider uploading reports for the commit a865d7e to get more accurate results

Additional details and impacted files
@@           Coverage Diff           @@
##           master     #132   +/-   ##
=======================================
  Coverage   97.88%   97.88%
=======================================
  Files         172      172
  Lines        2842     2842
  Branches      148      148
=======================================
  Hits         2782     2782
  Misses         52       52
  Partials        8        8

Impacted Files
Coverage Δ

src/catalog/categories/categories.service.ts
100.00% <100.00%> (ø)

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

:umbrella: View full report at Codecov.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.


If a user edits their approved operation, the confirmation message is outdated

Describe the task
After an operation is approved, a user can edit it by returning to the form and clicking "save and continue"/"submit". When they click submit, they receive this message:

The message says "once approved" but the operation has already been approved.
Acceptance Criteria

[ ] first
[ ] second
[ ] third

Additional context

Add any other context about the task here.
Or here

@nanyangpro or @zoeyli-46, I don't think we ever had a confirmation message for this situation. What do you suggest?

Hi @hannavovk & @zoeyli-46 - I feel I may lack context of the situation as described by @BCerki in the ticket description for Reg Pt. 1, thus needing your help confirming the intended behaviour to ensure I provide accurate messaging:

When user makes edits to an already approved BORO ID application, would the status of the application go back to "Pending Approval"?
In that case, would the already issued BORO ID be invalidated before the application is approved again?
When approved again by IRC, would a new BORO ID be issued or the old one remains valid?

What if we just said "Your changes have been saved. " and leave it at that? I think unless we tell them that their BORO ID is impacted there's no reason for them to think otherwise.  If others disagree though then I'm okay with keeping the second sentence as well just without the typo :). So in sum: "Your changes have been saved. The previously issued B.C. OBPS Regulated Operation ID remains valid." (cc @nanyangpro @zoeyli-46 )
Also, let's add this to the ticket description (or acceptance criteria).

Sounds good to me, thanks @hannavovk. The AC has been updated.

Might need to update the messaging in the email too

@nanyangpro , as I was doing this ticket I noticed that the Have not received the confirmation email yet? doesn't actually link anywhere. I can add a link as part of this ticket if we know where it's supposed to go.


Update Readme to specify the SQL script execution

@xpouyat,
Thanks for your contribution as a Microsoft full-time employee or intern. You do not need to sign a CLA.
Thanks,
Microsoft Pull Request Bot

The database connections string should be update in Web.config file or should i add it to application settings -> connection string ?

@nabilnaim You need to update mediadashboardconfig.json ans post it to the storage.
The readme says:
Update the contentProviders section of the template configuration file, mediadashboardconfig.json, with parameters for your media service account, associated storage account, SQL database. Upload this configuration file into a blob storage container named config in your associated storage account.


Update of text field value from js

When I update a text field value from js such as:
$('#customize-control-my-text-field input').val('some value');
//or
$('#customize-control-my-text-field input').attr('value', 'some value');
//and
$('#customize-control-mt-text-field-input').trigger('change'); //force change event

I immediately see the customizer input field showing the new value however when I save and update and refresh the page, the old value remains.  If I click in the input field and manually update it, it saves the new value even if it's simply an edit of the js injected value.
How can I update the input value from js?
On an added note, I also do this successfully from the code field type however I use codemirror's utility function cm.setValue to update it's value.  There must be some other event listener on the normal text field type input that I need to fire...hopefully it's not something like 'keyup'.  Any ideas?

You'll have to use the Customizer's JS API for this...
All fields in Kirki use the Customizer's JS templating engine, and each field has a .js file responsible for getting and saving the values.
Take a look at this line: https://github.com/aristath/kirki/blob/2.0.3/assets/js/controls/text.js#L8
This is what changes the setting's value.
In the code field, we're getting the value from the codemirror API and then pass that on to the customizer API which is probably why you can get this to work with that control: https://github.com/aristath/kirki/blob/2.0.3/assets/js/controls/code.js#L17

Hmm, I wonder why my injected "change" event is not firing the update.  Maybe something to do with lacking an original event object or maybe I just need to delay it slightly.  I'll play around with this thanks for the references, really big help.


FIX-#000: Rebalance partitions in to_csv

What do these changes do?

[ ] commit message follows format outlined here
[ ] passes flake8 modin/ asv_bench/benchmarks scripts/doc_checker.py
[ ] passes black --check modin/ asv_bench/benchmarks scripts/doc_checker.py
[ ] signed commit with git commit -s
[ ] Resolves #?
[ ] tests added and passing
[ ] module layout described at docs/development/architecture.rst is up-to-date

Not actual


Investigate color issue with image banners

As reported by layout, image banners sometimes display with incorrect colors:

Should investigate what causes this. Likely a very rare occurence?

Probably just related to too much compression on images, havent seen such a severe case tho.
Take a look at image rendering in info box, they don't have this issue.
Compression is too aggressive anyway, we have faster internet now

Woops accidental close


Security review: signing & nonce implementation of pledges

Just tagging @gord0b to do a quick sanity check of our implementation.
In order to edit a pledge, the client must PUT the newly updated pledge data, along with a signed message.

use ethers to verify the signature and extract the signer address
compare the signer address and the nonce to the data held in our database for that pledge
if correct, write to the database with the new data

All pledge data is public and available on any client, including the nonce. We only need to worry about preventing unauthorized updates.
API endpoint here:
https://github.com/KlimaDAO/klimadao/blob/staging/site/pages/api/pledge/index.ts
handler logic here
https://github.com/KlimaDAO/klimadao/blob/f123eb6823ceec8ac1c7aa8acc413fc62525f015/site/components/pages/Pledge/lib/firebase.ts#L43
And signature verification here:
https://github.com/KlimaDAO/klimadao/blob/f123eb6823ceec8ac1c7aa8acc413fc62525f015/site/components/pages/Pledge/lib/verifySignature.ts#L10

https://www.klimadao.finance/api has 'access-control-allow-origin: *' set without any request method limitations.

https://www.klimadao.finance/api/block-rate is the only location that has 'access-control-allow-origin: *' limited to only GET request methods.

https://www.klimadao.finance/api/pledge - might be worth limiting 'pledge' to the below.
1: 'access-control-allow-origin: *' to 'Access-Control-Allow-Origin: https://*.klimadao.finance' so that the resource can be accessed only from *.klimadao.finance origin not by any origin.
2: Limit the methods to "GET, PUT",
      {
        key: "Access-Control-Allow-Origin",
        value: "https://*.klimadao.finance",
      },
      {
        key: "Access-Control-Allow-Methods",
        value: "GET, PUT",


Review TravisCI

Review minimal setup to check cats-process build

Checked:

[x] Install Travis CI GitHub App in cats4scala
[x] Check pipeline is running on PR and master branch

Since those are done, and our current defined pipeline is minimal but it is enough to start, I am considering this task done :shipit:


[RFC] risc-v: drivers: intc_plic: enabled interrupts to be handled by all cores

This patch set is to fix an issue #65489.
The problem to fix is that the first context of the PLIC was hardcoded into the driver. The side effect of that was to disable other cores in a multi-core complex from handling interrupts.
The solution presented here started off life as a cut and past from what is done in Linux, however A slightly more elegant solution raised its head during the process: basically, We know how many CPU's will be associated with a Zephyr application prior to compile time. Also, if its an SMP set up we have a mapping of the hartid to the cpu right from the  start.
We can leverage this list of CPU's to enable only the contexts of the harts that are required to run in Zephyr, allowing Zephyr to also play nicely in an AMP setup.

Ugh... @con-pax - may need to rebase and resolve conflicts.

Ugh... @con-pax - may need to rebase and resolve conflicts.

@cfriedt hehe, I was pipped to the post! That's no problem, I can rebase now and push again. Thanks a million!

@cfriedt rebased and pushed.
@ycsin @fkokosinski could I trouble you guys and ask for your re-approval?
Thanks a million for all the help on this!

@ycsin - can you do a bisect on the test that's failing? I would guess it's probably from one of the ones that were just merged ahead of this.

@ycsin - can you do a bisect on the test that's failing? I would guess it's probably from one of the ones that were just merged ahead of this.

@cfriedt Hey Chris, apologies, this was my bad: I see something that in my haste, my rebase wasn't successful: I will rebase again from the point of previous approvals

Hey @cfriedt, @ycsin
All CI builds are passing again after subsequent rebase.
Apologies for the total spam.
Cheers!

Hey @ycsin @fkokosinski
full apologies for the spam here: could I ask you guys for re-approval again (hopefully for the last time) so we can get this merged?
Thanks again for all the help on this, really appreciated.

@con-pax I wanted to test IRQ affinity and tried to enable the RISCV_IRQ_MSOFT for secondary cores here, but the IRQ of the qemu_riscv64 UART is always handled by the first core only, I was expecting to see that the IRQ is handled randomly by all the cores, am I missing something?

@ycsin hey, apologies for the delay, I was off. I can test this out. AFAIK, a similar situation occurs in Linux: though each HART in the Affinity pool can service IRQ's, the same HART normally wins the race (though I know you can mask certain IRQ's to certain HARTS)

I'm reducing the scope down to the main core so the feature added by this PR may be out of the scope of what I'm trying to do for now.
Currently I'm trying to trigger the PLIC to interrupt its 2nd target (i.e. 0x09 for qemu_riscv64), it doens't work on qemu_riscv64 but it does on my custom silicon where the PLIC is connected to RISCV_IRQ_MEXT & RISCV_IRQ_MSOFT: Test code
Any idea on how to get the qemu to work would be nice, I guess I should probably open a discussion thread in the Q&A instead of spamming this closed PR.


AsyncButton proposal

Hey! Nice job with the lib!
For most of my project I use so called AsyncButton based on LoadingButton. Which basically intercepts  onClick handler and handles loading state if function on onClick handler returns Promise. Would you be interested in a pr?

Hi thanks.
It will be useful and avoid dealing with a “loading state” boolean.
I will not be able to merge it into main before the end of solidjs hackathon (April 28th).
I can create a separate branch for contribution and publish the version with a “next” tag instead of “latest”

Hey @fabien-ml
After some time trying to fit this functionality into current codebase it seems to me should be implemented in user land.
My options were:

Add async prop and introduce signal inside Button and maybe do something like const isLoading = local.loading || loadingState.
Make <Button.Async>, but none of the components does that.
Create AsyncButton component next Button. (least appealing)

wdyt?

@NurbekGithub i would prefer to keep Button stateless. Creating an AsyncButton will be the simplest way to do it. You can look into the IconButton component to see how I do the wrapping.

@fabien-ml Here you go https://github.com/fabien-ml/hope-ui/pull/99 :)

closed by #99


Backup to monospace font in Chromium

As long as Chromium doesn't support some fonts, add rule to fall back to simple monospace if Menlo is not present.

I would suggest to use this instead: https://systemfontstack.com/
font-family: Menlo, Consolas, Monaco, Liberation Mono, Lucida Console, monospace;

This is friendly to all 3 major OSes (Windows, Linux, macOS) and does not require extra fonts, and still has monospace in case it's accessed from yet another OS (e.g. some *BSD).
If you want some more context I write a blog post about this a while ago :D https://thiagowfx.github.io/2022/02/website-fonts-just-use-the-system-font-stack/

I would suggest to use this instead: https://systemfontstack.com/
font-family: Menlo, Consolas, Monaco, Liberation Mono, Lucida Console, monospace;

This is friendly to all 3 major OSes (Windows, Linux, macOS) and does not require extra fonts, and still has monospace in case it's accessed from yet another OS (e.g. some *BSD).
If you want some more context I write a blog post about this a while ago :D https://thiagowfx.github.io/2022/02/website-fonts-just-use-the-system-font-stack/

Love it!