Checkbox unable to mark as checked via a prop

Bug report
I noticed that the Checkbox has no prop to mark it as checked or not:

We'll need to add a prop to mark the checkbox as checked, such as in the context of persistent data
e.g <Checkbox checked={true} />

should work now
you also don't need to add so much if you don't want.
value and id come from label if they don't exist.
function example() {
  const [check, setCheck] = useState(true)

  function toggleCheckbox(e) {
    setCheck(!check)

    console.log(e)
    // console log returns
    // {name: "lonely-checkbox", id: "lonely-checkbox", value: "lonely-checkbox", checked: true}**
  }

  return (
    <Checkbox label="lonely checkbox" checked={check} onChange={toggleCheckbox}/>
  )
}

should work now
you also don't need to add so much if you don't want.
value and id come from label if they don't exist.
function example() {
  const [check, setCheck] = useState(true)

  function toggleCheckbox(e) {
    setCheck(!check)

    console.log(e)
    // console log returns
    // {name: "lonely-checkbox", id: "lonely-checkbox", value: "lonely-checkbox", checked: true}**
  }

  return (
    <Checkbox label="lonely checkbox" checked={check} onChange={toggleCheckbox}/>
  )
}


pull request for e2e test at 11/09/2016 00:56:09

:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

optest/docs/updated_at.md
:white_check_mark:Succeeded

Details

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


Still using typeahead? #14

I have removed the typeahead class.  Please let me know how this works for you...

Thanks for the PR.  I will try to look at this later this week.

Thanks for the PR, it has been merged

Brill!  Thanks!
On 10 Nov 2017 9:11 pm, "Liam Cavanagh"<EMAIL_ADDRESS>wrote:

Thanks for the PR, it has been merged
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/Azure-Samples/search-dotnet-asp-net-mvc-jobs/pull/15#issuecomment-343587331,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AFj0pMo6TjXPJAHgzdXpgtXGUa3tIbUhks5s1Lv8gaJpZM4QSdHQ
.


delete_all has different behavior when supplying an id instead of an object

This PR reproduces an issue where MultiTenant.with(account) has different behavior from MultiTenant.with(account.id) when calling delete_all or update_all.
Is it expected for the behavior to differ, or should we go ahead and remove the following 2 lines in order to make the behavior consistent for delete_all and update_all?
https://github.com/citusdata/activerecord-multi-tenant/blob/master/lib/activerecord-multi-tenant/relation_extension.rb#L8
And
https://github.com/citusdata/activerecord-multi-tenant/blob/master/lib/activerecord-multi-tenant/relation_extension.rb#L20

@microsoft-github-policy-service agree company="Salesloft"

@reidmorrison please read the following Contributor License Agreement(CLA). If you agree with the CLA, please reply with the following information.
@microsoft-github-policy-service agree [company="{your company}"]

Options:

(default - no company specified) I have sole ownership of intellectual property rights to my Submissions and I am not making Submissions in the course of work for my employer.

@microsoft-github-policy-service agree

(when company given) I am making Submissions in the course of work for my employer (or my employer has intellectual property rights in my Submissions by contract or applicable law). I have permission from my employer to make Submissions and enter into this Agreement on behalf of my employer. By signing below, the defined term “You” includes me and my employer.

@microsoft-github-policy-service agree company="Microsoft"

Contributor License Agreement

@microsoft-github-policy-service agree company="Salesloft"

The tests are now passing locally after these changes made in the PR were merged into master: https://github.com/citusdata/activerecord-multi-tenant/commit/20d09a83db160e40db8e526becf66f59ad65f9a7
Please consider merging this pull request which now only adds tests, since they now include test coverage for the scenario that was fixed.


🎁 Create transaction steps for anything custom in the actor stack

Summary
Review any callbacks for the models/controllers. Make a custom transaction step equivalent so that the model's resource can implement the same actions.
ref:

https://github.com/WGBH-MLA/ams/tree/develop/app/transactions/ams/steps

Acceptance Criteria

[ ]

Screenshots or Video
Testing Instructions
Notes
https://docs.google.com/document/d/1WCB-5qIDCGhMQSuAzM70MDIuP4EQJhtnvgZt2x8MS4o/edit
https://drive.google.com/file/d/1oSLVhSF34JUgJBni9kN7FhPuOao5XSfz/view?usp=sharing

List of transactions we may need:
GenericWork

validates :title, presence: { message: 'Your work must have a title.' }

Image
when IiifPrint is enabled

after_save => SetChildFlag


fix: send email with local name via custom client

There are cases when SMTP server needs fully-qualified client hostname.
so Postee should have a config for it.
it fixes #602

Thanks @afdesk ! Left some comments. Please note we may need a cherry-pick into postee-for-enterprise branch, hopefully this isn't a breaking change :)

Thanks @afdesk ! Left some comments. Please note we may need a cherry-pick into postee-for-enterprise branch, hopefully this isn't a breaking change :)

oh, thanks for the review. I missed it.
yes, there are no breaking changes here.

hey @afdesk ! I was away for a few days - how are we doing on this PR? Ready for review?

LGTM @afdesk ! let's go ahead and merge, and we will open a cherry-pick into postee-for-enterprise branch.


adding a resource

What issue is this referencing?

Do these code changes work locally and have you tested that they fix the issue yourself?

[X ] yes!

Does the following command run without warnings or errors?

[ X] yes! npm run pr-checks

Have you taken a look at our contributing guidelines?

[X ] yes!

My node version matches the one suggested when running nvm use?

[X ] yes!

@sdhinsa11 could you run the lint:fix script and update your code, thanks


Android Chrome 61, video freezes after connecting

Browsers and versions affected
Chrome for Android 61
Description
After a connection is made to the other peer, eg. Desktop Chrome, remote video is black and local video freezes. Audio still works. Funny enough, after setting up remote debugging, all works fine.
Steps to reproduce

Connect to a room with desktop Chrome
Connect to the same room with android chrome 61

Expected results
Should be able to see both local and remote video on android chrome
Actual results
Remote video is black and local video freezes

It's a WebRTC issue : https://bugs.chromium.org/p/chromium/issues/detail?id=769148

+1 +1 +1 +1 +1 +1

we can not share on chrome anymore.

has someone been able to resolve this issue?


Check that no bitcoind processes are running before starting test

~This builds on #17. Review that first.~
This PR adds a check to TestWrapper.setup() that checks whether there are any bitcoind processes running, and exits early with a message if there are any processes running.
This requires installing and importing psutil, which is added to requirements.txt, so the initial pip3 install -r requirements.txt will install it in the virtual environment.
A couple of reasons we might not want this:

adds another requirement. I don't like asking our attendees to install more than they strictly need to
requires cross-platform testing

I have a similar concern on the cross platform (windows) testing. We have not had any attendees say they are on windows yet, but could still happen.
Did you run into a scenario where there is a conflict with other bitcoind instances? @jnewbery

Did you run into a scenario where there is a conflict with other bitcoind instances? @jnewbery

There is also this issue when running setup on multiple TestWrapper object instances.

Rebased on master

Did you run into a scenario where there is a conflict with other bitcoind instances?

Not with the notebooks, but there have been issues in the past with the test framework where a running bitcoind instance is using a required resource (eg tcp port). I also think it's useful to warn the user if they're trying to run the notebook if they have a mainnet bitcoind instance running.

There is also this issue when running setup on multiple TestWrapper instances.

This shouldn't be possible now that #17 is merged.

I'm leaning towards not merging this before the workshops. I'd prefer not to require and additional dependency if possible.
Perhaps we can revisit after the workshops.

Rebased and merged. If this causes problems for people, it's an easy revert.


Linux kernels 2024-03-05

Description of changes
@k900 I see you added DAMON — they've deprecated DAMON debugfs and moved it under DAMON_DBGFS_DEPRECATED.  Do you think we should enable that config option, or just axe it from 6.9 onwards?
Things done

Built on platform(s)

[x] x86_64-linux
[x] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)

[ ] sandbox = relaxed
[ ] sandbox = true

[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[ ] Tested basic functionality of all binary files (usually in ./result/bin/)
24.05 Release Notes (or backporting 23.05 and 23.11 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[x] Fits CONTRIBUTING.md.

Add a :+1: reaction to pull requests you find important.

@OfBorg test kernel-generic.linux_testing

Merging this so I can base the next stable update off of it.

Apologies for not leaving a review earlier!
Changes look good, I just didn't get to testing them so far, so I haven't left a review here.


How to wait for a webpage to be fully loaded before starting to test ?

I'd like to be sure that the webpage I'm going to test (using Nightmare) is totally loaded (no more loading loader visible... ). How can I proceed ?
I've saw that I can wait for a DOM element, but pictures can haven't finish their loading.
Thank's a lot for your answer,
Antoine

Unfortunately you can't.  Selenium can't track images loading, it can operates only with DOM and viewport.

Same question, but about puppeteer & Chrome. Can I in some way 'waitForImageLoaded' ?

I think this is possible through window.performance.


urnresolver: Uniform Resource Names - URN Resolver

Quick links

Wikipedia

EN: https://en.wikipedia.org/wiki/Uniform_Resource_Name
PT: https://pt.wikipedia.org/wiki/URN

RFC

Uniform Resource Names (URNs): https://tools.ietf.org/html/rfc8141
Functional Requirements for Uniform Resource Names: https://tools.ietf.org/html/rfc1737

IANA Namespaces: https://www.iana.org/assignments/urn-namespaces/urn-namespaces.xhtml

"A Uniform Resource Name (URN) is a Uniform Resource Identifier (URI) that uses the urn scheme. URNs are globally unique persistent identifiers assigned within defined namespaces so they will be available for a long period of time, even after the resource which they identify ceases to exist or becomes unavailable.[1] URNs cannot be used to directly locate an item and need not be resolvable, as they are simply templates that another parser may use to find an item." -- Wikipedia

As part of reference the datasets (temporary internal name: hdataset) from different groups (temporary internal name: hsilo) makes sense to have some way to padronize naming. And URNs, even if is complicated to implement in practice, at least could serve as hint for humans simply avoid using whatever is their creative idea at the moment. (This actually is more important if we're implementing localized translations as part of the [meta issue] hxlm #11 with equal equivalent between translations).

Because of this topic, we will need to create some sort of local vault for permanent storage.

One idea about the namespace urn:data: is, while some more complex namespaces may actually do whatever they want (including using full unicode), we could have some base functionality to for an query like urnresolver urn:data:un:locode if already have files on local computer, return the exact URI "$HOME/.config/hxlm/urn/data/un/locode/locode.csv" instead of return error and suggest the documentation https://unece.org/trade/uncefact/unlocode.
I think that in fact, instead of "return error" if the user does not force return error, but allow the urnresolver return ANOTHER urn (like urn:data-i:un:locode), and that urn would return the information like https://unece.org/trade/uncefact/unlocode, this could help with direct usage via command line.
Note: I know that urn:data:un:locode could "ideally" be something like urn:data:un:unece:locode, but the "UN/LOCODE" is so famous, that could worth the idea of make some types of aliases.

This is the current result. As for baseline URN processing strategy (likely to be the "organization" inside an already namespaced country/territory) could be both an single identifier or (since I'm not sure if most people in the middle of urgency would agree with something) then use an domain name itself.
fititnt@bravo:/workspace/git/EticaAI/HXL-Data-Science-file-formats$ ./tests/test_core_urn.py
DataUrnHtype(value='urn:data--i:un:locode') {'nid': 'data', 'nid_attr': 'i', 'bpgp': 'un', 'bpln': 'locode', 'nss': 'un:locode'}
DataUrnHtype(value='URN:DATA--I:UN:LOCODE') {'nid': 'data', 'nid_attr': 'i', 'bpgp': 'URN', 'bpln': 'DATA--I', 'nss': 'URN:DATA--I:UN:LOCODE'}
DataUrnHtype(value='urn:data:un:locode') {'nid': 'data', 'nid_attr': 'd', 'bpgp': 'un', 'bpln': 'locode', 'nss': 'un:locode'}
DataUrnHtype(value='urn:data--i:xz:hxlcplp:fod:bool') {'nid': 'data', 'nid_attr': 'i', 'bpgp': 'xz', 'bpln': 'hxlcplp', 'nss': 'xz:hxlcplp:fod:bool'}
DataUrnHtype(value='urn:data:br:__saude.gov.br__:covid-19-vacinacao') {'nid': 'data', 'nid_attr': 'd', 'bpgp': 'br', 'bpln': 'saude.gov.br', 'bpln_isdn': True, 'nss': 'br:__saude.gov.br__:covid-19-vacinacao'}
DataUrnHtype(value='urn:data--i:cn:__中国.icom.museum__:test') {'nid': 'data', 'nid_attr': 'i', 'bpgp': 'cn', 'bpln': '中国.icom.museum', 'bpln_isdn': True, 'nss': 'cn:__中国.icom.museum__:test'}
DataUrnHtype(value='urn:data--i:ru:__россия.иком.museum__:test') {'nid': 'data', 'nid_attr': 'i', 'bpgp': 'ru', 'bpln': 'россия.иком.museum', 'bpln_isdn': True, 'nss': 'ru:__россия.иком.museum__:test'}
DataUrnHtype(value='urn:data--i:eg:__مصر.icom.museum__:test') {'nid': 'data', 'nid_attr': 'i', 'bpgp': 'eg', 'bpln': 'مصر.icom.museum', 'bpln_isdn': True, 'nss': 'eg:__مصر.icom.museum__:test'}

The idea is the urnresolver be able to (if do exist one already prepared dataset on a path available on local filesystem) based on most comon URNs even if implementers do not create something very specific for the country or the organuzation, at least the default strategy would allow people working with datasets some place to put the files.
If the default is good enough, while documentations could always require the humans manually translate, at least the default resolver could make documentations directly usable!

The current version of HXL-Data-Science-file-formats is v0.7.3.

I think that the tools for URN resolving worth an different group from HXL2 topic. In fact, the URN resolving often would be applied to content that still not HXLated yet or deal with issues also related to HXL, like very sensitive content (like how to name URLs that may be protected just by randomness, not by access control?)

We already have a proof of concept of the command line interface for the internals of HXLm related to URN parsing, so we can at least mark this topic as with some proof of concept.
The version will be updated to v0.7.4 soon so in the worst case scenario (like we from EticaAI/HXL-CPLP don't go forward with this, but people could reuse work several years later) is possible to look around this date. Anyway all the things are public domain dedication.
As of the current "official" release, only v0.7.0 was published. The problem is so many new features from v0.7.0 that I would not even know where to start documenting without breaking things in complete separate projects. But at the moment it is not 100% clear what is worth focus and involve beyond early drafts (even if they are usable).
Relation with the [meta issue] hxlm #11
While most features of HXLm (temporary name) library are to help use HXL also as a common format to convert from/to common data science formats, the urnresolver, if do have some minimal functionality, could still be used without need to keep updated with the latest version of this full repository. Also if this project is not broken in smaller parts by EticaAI or HXL-CPLP initiative, if this starts to get used in production, it may make sense just extract the smaller parts, even if renaming classes to avoid confusion.
But in case of actually being used, I think it is worth paying more attention to the way to document URNs index files (the file formats, the way to share in private, etc) than the code itself that converts then to usable URLs.
But I still think that it is very, very important that any implementation at bare minimum allows converting an URN string to an URL or local path that could be used by HXL command line tools (or, for solid files, like encrypted it compressed, any other tool on the machine).

Note: one workaround to convert URNs to URLs would be to prefix the URNs to http:// and override /etc/hosts file to some server that de facto redirect to the real URL. Also while the urnresolver is designed to be usable by a human on a local computer it actually can be used to convert URNs for others inside one already secured intranet. Maybe with libhxl-python CLI tools actually become an private provider of data (either by retrieving remote resources or by local files on disk).

Dynamic Delegation Discovery System (DDDS) & Name Authority Pointer (NAPTR)

https://en.wikipedia.org/wiki/NAPTR_record
https://www.iana.org/domains/arpa

https://tools.ietf.org/html/rfc3405

https://tools.ietf.org/html/rfc2168
https://tools.ietf.org/html/rfc2915
https://tools.ietf.org/html/rfc3402

Context
We're doing urnresolver using static files, but what some time ago I imagined that could be implemented with DNS, actually was not only not new, but planned more than 20 years ago. The idea of Dynamic Delegation Discovery System (DDDS) seems actually very focused on Regexes, so as long as URNs are somewhat standarlized, the thing could be reused again.
And about private/restricted access
Maybe I missed, but the experimental RFCs related to Dynamic Delegation Discovery System (DDDS) did not mentioned some way to authenticate user (or at least don't leak information).
Air gapped
Maybe what we could do is both have a public end point, and then allow have private resolvers. But instead of overly complicate, we just optimize the full thing to be able to air-gapped (means have local cache, deal with copy and paste data from external world to internal network, etc) and somewhat allow even a local resolver just work from static files.
Both public and private
The intermediate case (a resolver from someone that both work locally and then fallback to public resolver) may be tricky on context of privacy.
For example, if we from Etica.AI actually release a public endpoint, the way internet works, means that if user ask a request, the resolver may travel entire internet and hit that request to both CloudFlare (and GitHub). Even if we dont have this request, and the fact that all information actually is public, this could leak information that someone requested something.
Maybe if we eventually release one public endpoint could make sense that we try to find sites that are equivalent to GitHub on other regions of the world.

Humm... it's something.

Ok that this is not that useful since we don't actually save cache on disk yet. But since there is at least 3 ways to process URNs:

via urnresolver scripts when doing locally

like urlresolver urn:data:xz:hxl:standard:core:attribute

result: https://docs.google.com/spreadsheets/d/1En9FlmM8PrbTWgl3UHPF_MXnJ6ziVZFhBbojSJzBdLI/pub?gid=1810309357&single=true&output=csv

via proxy, like this Do it yourself http://data.urn.arpa/

like http://data.urn.arpa/urn:data:xz:hxl:standard:core:attribute`

via DNS resolving

I still am not even 30% sure how to do it based on these near 20 years old RFCs

But I know that in theory is possible do do it, even with standard DNS configurations like the ones from Cloudflare

I think that anything that could not fit ok on standanone shell or python scripts, instead of 1000 lines long scripts, we just put the work inside the hdp-toolchain.

I believe we should add a few more parameters on the urn.yml files. All other options are new ones (most of then already are not implemented parameters on the current urnresolver cli toon to expose these features, but this could be done soon.
One change is the source now is fontem.
The urn.yml format
Old format
Example 1
# Trivia:
#  - "fontem"
#    - https://en.wiktionary.org/wiki/fons#Latin
#  - "auxilium"
#    - https://en.wiktionary.org/wiki/auxilium#Latin
#  - "dēscrīptiōnem"
#    - https://en.wiktionary.org/wiki/descriptio#Latin
#  - "explānandum"
#    - https://en.wiktionary.org/wiki/explano#Latin

- urn: "urn:data:xz:hxl:standard:core:hashtag"
  descriptionem:
    eng-Latn: HXL/CSV version of the HXL Standard core hashtags.
  auxilium:
    - https://data.humdata.org/dataset/hxl-core-schemas
  fontem:
    - ontologia/codicem/hxl/standard/core/hashtag.hxl.csv
    - https://proxy.hxlstandard.org/data.csv?dest=data_edit&strip-headers=on&url=https%3A%2F%2Fdocs.google.com%2Fspreadsheets%2Fd%2F1En9FlmM8PrbTWgl3UHPF_MXnJ6ziVZFhBbojSJzBdLI%2Fpub%3Fgid%3D319251406%26single%3Dtrue%26output%3Dcsv
    - https://docs.google.com/spreadsheets/d/1En9FlmM8PrbTWgl3UHPF_MXnJ6ziVZFhBbojSJzBdLI/pub?gid=319251406&single=true&output=csv

Example 2
- urn: "urn:data:xz:eticaai:ontologia:codicem:anatomiam:terminologia-anatomica"
  descriptionem:
    eng-Latn: >
      Table with code references for body parts, in special
      Terminologia Anatomica (TA). Can be used with other ontologies and
      to transform for a few natural languages descriptions.
  explanandum:
    # Good references:
    - +v_fipat_ta2
    - +v_fipat_ta98_id
    - +v_fipat_ta98_latin
    # Generic references:
    - +v_wikidata
    - +v_fi_yso
    - +v_fr_universalis
    - +v_it_bncf
    - +v_jp_ndl
    - +v_uberon
    - +v_uk_britannica
    - +v_us_jstor
    - +v_us_mag
    - +v_us_mesh
    - +v_us_umls_cui
  auxilium:
    - https://github.com/HXL-CPLP/forum/issues/44
    - https://www4.unifr.ch/ifaa/Public/EntryPage/TA98%20Tree/HelpPage/TA98%20Latin%20Page%20Help.pdf
  exemplum:
    # Since terminologia-anatomica.hxl.csv 1,8mb, we only deploy a sample
    - ontologia/codicem/anatomiam/terminologia-anatomica-EXEMPLUM.hxl.csv
  fontem:
    # run ontologia/codicem/anatomiam/make.sh to get terminologia-anatomica.hxl.csv
    # or let the urnresolver download from live URNs
    - ontologia/codicem/anatomiam/terminologia-anatomica.hxl.csv
    - https://proxy.hxlstandard.org/data/b02a5f/download/HXL_CPLP-FOD_medicinae-legalis_humana-corpus.csv
    - https://docs.google.com/spreadsheets/d/10axnLpDNtAc8Bh921dz5XPXCwo0FUXRcKS6-ermiu5w/edit#gid=1622293684

Old format

# URNResolver v1.2.1
# hdp-toolchain v<IP_ADDRESS>

# @see https://data.humdata.org/dataset/hxl-core-schemas
- urn: "urn:data:xz:hxl:standard:core:hashtag"
  source:
    - ontologia/codicem/hxl/standard/core/hashtag.hxl.csv
    - https://proxy.hxlstandard.org/data.csv?dest=data_edit&strip-headers=on&url=https%3A%2F%2Fdocs.google.com%2Fspreadsheets%2Fd%2F1En9FlmM8PrbTWgl3UHPF_MXnJ6ziVZFhBbojSJzBdLI%2Fpub%3Fgid%3D319251406%26single%3Dtrue%26output%3Dcsv
    - https://docs.google.com/spreadsheets/d/1En9FlmM8PrbTWgl3UHPF_MXnJ6ziVZFhBbojSJzBdLI/pub?gid=319251406&single=true&output=csv

Added reverse search, like urnresolver -?? +v_iso15924 or urnresolver -?? country+code+v_iso2
I believe we will need to build some table that could give a hint that some codes, like country+code+v_iso2, could also mean other variants of ISO 3166-1. This could help more automated search of what something means.
# fititnt@bravo:/workspace/git/EticaAI/HXL-Data-Science-file-formats$ urnresolver -?? +v_iso15924
urn:data:xz:eticaai:ontologia:codicem:linguam
# fititnt@bravo:/workspace/git/EticaAI/HXL-Data-Science-file-formats$ urnresolver -?? country+code+v_iso2
urn:data:xz:eticaai:ontologia:codicem:locum
# fititnt@bravo:/workspace/git/EticaAI/HXL-Data-Science-file-formats$ urnresolver --urn-explanandum-list
urn:data:xz:eticaai:ontologia:codicem:anatomiam:terminologia-anatomica	+v_fipat_ta2
urn:data:xz:eticaai:ontologia:codicem:anatomiam:terminologia-anatomica	+v_fipat_ta98_id
urn:data:xz:eticaai:ontologia:codicem:anatomiam:terminologia-anatomica	+v_fipat_ta98_latin
urn:data:xz:eticaai:ontologia:codicem:anatomiam:terminologia-anatomica	+v_wikidata
urn:data:xz:eticaai:ontologia:codicem:anatomiam:terminologia-anatomica	+v_fi_yso
urn:data:xz:eticaai:ontologia:codicem:anatomiam:terminologia-anatomica	+v_fr_universalis
urn:data:xz:eticaai:ontologia:codicem:anatomiam:terminologia-anatomica	+v_it_bncf
urn:data:xz:eticaai:ontologia:codicem:anatomiam:terminologia-anatomica	+v_jp_ndl
urn:data:xz:eticaai:ontologia:codicem:anatomiam:terminologia-anatomica	+v_uberon
urn:data:xz:eticaai:ontologia:codicem:anatomiam:terminologia-anatomica	+v_uk_britannica
urn:data:xz:eticaai:ontologia:codicem:anatomiam:terminologia-anatomica	+v_us_jstor
urn:data:xz:eticaai:ontologia:codicem:anatomiam:terminologia-anatomica	+v_us_mag
urn:data:xz:eticaai:ontologia:codicem:anatomiam:terminologia-anatomica	+v_us_mesh
urn:data:xz:eticaai:ontologia:codicem:anatomiam:terminologia-anatomica	+v_us_umls_cui
urn:data:xz:eticaai:ontologia:codicem:sexum:binarium	+v_iso5218
urn:data:xz:eticaai:ontologia:codicem:sexum:binarium	+v_iso5218_extended
urn:data:xz:eticaai:ontologia:codicem:sexum:binarium	+v_fipat_ta98_latin
urn:data:xz:eticaai:ontologia:codicem:sexum:hl7	+v_iso5218
urn:data:xz:eticaai:ontologia:codicem:sexum:hl7	+v_iso5218_extended
urn:data:xz:eticaai:ontologia:codicem:sexum:hl7	+v_us_cdc_sex
urn:data:xz:eticaai:ontologia:codicem:sexum:hl7	+v_un_icao_sex
urn:data:xz:eticaai:ontologia:codicem:sexum:hl7	+v_us_NAACCR
urn:data:xz:eticaai:ontologia:codicem:sexum:hl7	+v_us_census_sex
urn:data:xz:eticaai:ontologia:codicem:sexum:non-binarium	+lat_codices_anonyma
urn:data:xz:eticaai:ontologia:codicem:sexum:non-binarium	+v_iso5218_extended
urn:data:xz:eticaai:ontologia:codicem:linguam	+v_iso15924
urn:data:xz:eticaai:ontologia:codicem:locum	country+code+v_iso2
urn:data:xz:eticaai:ontologia:codicem:locum	country+code+v_iso3
urn:data:xz:eticaai:ontologia:codicem:locum	+v_hrinfo_country
urn:data:xz:eticaai:ontologia:codicem:locum	+v_reliefweb
urn:data:xz:eticaai:ontologia:codicem:locum	country+code+v_reliefweb
# fititnt@bravo:/workspace/git/EticaAI/HXL-Data-Science-file-formats$ urnresolver -? urn:data:xz:hxl:standard:core:attribute
[
    {
        "urn": "urn:data:xz:hxl:standard:core:attribute",
        "descriptionem": {
            "eng-Latn": "HXL/CSV version of the HXL Standard core attributes."
        },
        "auxilium": [
            "https://data.humdata.org/dataset/hxl-core-schemas"
        ],
        "fontem": [
            "ontologia/codicem/hxl/standard/core/hashtag.hxl.csv",
            "https://proxy.hxlstandard.org/data.csv?dest=data_view&url=https%3A%2F%2Fdocs.google.com%2Fspreadsheets%2Fd%2F1En9FlmM8PrbTWgl3UHPF_MXnJ6ziVZFhBbojSJzBdLI%2Fpub%3Fgid%3D1810309357%26single%3Dtrue%26output%3Dcsv&strip-headers=on",
            "https://docs.google.com/spreadsheets/d/1En9FlmM8PrbTWgl3UHPF_MXnJ6ziVZFhBbojSJzBdLI/pub?gid=1810309357&single=true&output=csv"
        ],
        "urnref": "urnresolver-default.urn.yml"
    }
]

👋 Thank you!


Add optional SPF record

what

Add ability to create an SPF record for the domain identity

why

An SPF record improves email deliverability and makes it more difficult to use the domain in an email spoofing attempt.

references
None

/terratest

/terratest

/terratest

@hans-d thanks - changes made as requested

/terratest

/terratest

@Mergifyio refresh

/terratest


Allow setting API key explicitly

Please add a method to FcmClient for setting the API key explicitly. In my application I am reading the key from a database -- since I send notifications to different Firebase projects -- and it is a bit inconvenient to set the appropriate system properties before creating an instance of FcmClient.

Hi,
I was in similar situation like you, so I added new factory method in PropertiesBasedSettings.java #10 and now you can create instance of FcmClient from a properties object.
     /**
      * Reads the properties from a Properties object.
      *
      * @param properties Properties instance
      * @return Initialized Client Settings
      */
     public static PropertiesBasedSettings createFromProperties(Properties properties) {
         return new PropertiesBasedSettings(properties);
 }

But new version has not been yet published to Maven repository. So @bytefish could you please buld and publish new version of the library with all the latest changes?
Thank you.

Here you have an example using the new factory method:
public class YourFCMSender {

    private static final String FCM_API_KEY = "fcm.api.key";
    private static final String FCM_API_URL = "fcm.api.url";
    private FcmClient fcmClient;

    public YourFCMSender() {
        Properties clientProperties = createPropertiesFromDB(getApiFromYourDB(), getUrlFromYourDB());
        this.fcmClient = new FcmClient(PropertiesBasedSettings.createFromProperties(clientProperties));
    }

    private Properties createPropertiesFromDB(String apiKey, String url) {
        Properties properties = new Properties();
        properties.setProperty(FCM_API_KEY, apiKey);
        properties.setProperty(FCM_API_URL, url);
        return properties;
    }

    private String getUrlFromYourDB() {
        // TODO implement
        return "";
    }

    private String getApiFromYourDB() {
        // TODO implement
        return "";
    }

}

The FcmClienttakes a FcmClientSettings it reads the settings from.
You could easily implement this interface for passing an API key into it:
// Copyright (c) Philipp Wagner. All rights reserved.
// Licensed under the MIT license. See LICENSE file in the project root for full license information.

package de.bytefish.fcmjava.client.tests.settings;

import de.bytefish.fcmjava.client.FcmClient;
import de.bytefish.fcmjava.constants.Constants;
import de.bytefish.fcmjava.http.client.IFcmClient;
import de.bytefish.fcmjava.http.options.IFcmClientSettings;
import org.junit.Test;

class FixedFcmClientSettings implements IFcmClientSettings {

    private final String apiKey;

    public FixedFcmClientSettings(String apiKey) {
        this.apiKey = apiKey;
    }

    @Override
    public String getFcmUrl() {
        return Constants.FCM_URL;
    }

    @Override
    public String getApiKey() {
        return apiKey;
    }
}

public class FcmClientSettingsTest {

    @Test
    public void testFixedClientSettings() {

        // Construct the FCM Client Settings with your API Key:
        IFcmClientSettings clientSettings = new FixedFcmClientSettings("your_api_key_here");

        // Instantiate the FcmClient with the API Key:
        IFcmClient client = new FcmClient(clientSettings);
    }

}


0.19

Checklist

[ ] Used a personal fork of the feedstock to propose changes
[ ] Bumped the build number (if the version is unchanged)
[ ] Reset the build number to 0 (if the version changed)
[ ] Re-rendered with the latest conda-smithy (Use the phrase @conda-forge-admin, please rerender in a comment in this PR for automated rerendering)
[ ] Ensured the license file is being packaged.

Hi! This is the friendly automated conda-forge-linting service.
I wanted to let you know that I linted all conda-recipes in your PR (recipe) and found some lint.
Here's what I've got...
For recipe:

Package version releases/FreeCAD-0-19 doesn't match conda spec

For recipe:

License is not an SPDX identifier (or a custom LicenseRef) nor an SPDX license expression.

Documentation on acceptable licenses can be found here.


adds evasion against toString test

Override console.debug to evade the toString test.

Why isn't this merged into master? Running it results in
Headless detection *failed*.
😎  Evaders are winning!

Right?

I was hesitating because the change breaks console.debug(), but that seems OK.


Move marinate into BaseView

Added marinate as a static method on BaseView Also added eslint configuration and fixed up eslint errors.
Not ready to merge as this currently depends on the eslint-config-1stdibs repo which needs to be created.

let's remove the eslint dep for now. It looks like a decent amount of the code was linted already so that should be fine.

@hellatan Removed.

cc @robrichard @twhid moving marinate into BaseView instead.
Next steps will be to change all of the marinate references to start using this instead.


iOS Support

Here are my learnings after trying to make the iOS SDK available in React Native.
We distribute our SDK via Swift Package Manager (the recommended approach for all Swift packages these days). React Native doesn't support this though, and given the lack of activity on the issue proposing it, I don't think we can expect it to happen any time soon. So Swift Package Manager was out.
Next we tried to add CocoaPods support to the SDK. This was a non-starter as well.
gRPC Swift, perhaps the most important dependency in our SDK, dropped support for CocoaPods in April '22 (see here). This happened after SwiftNIO, its networking dependency dropped support for it. I considered trying to fork these projects to add support but for SwiftNIO, that would be extremely difficult. From the announcement:

However, supporting it comes with additional maintenance cost: each release
requires the SwiftNIO team to publish 40+ Podspecs over the various SwiftNIO
repositories. While this is semi-automated, it is still a time consuming task
which is prone to failure.

So that was that.
The final idea was to try to compile the SDK into a large static library. This ran into a wall when it was discovered that the swift-atomics package, a dependency of SwiftNIO, doesn't support being packaged in a static library (see this issue for more details).
Given all of these issues, we can't support the current iOS SDK in React Native at this time.

I'm taking a second look at the cocoapods route. Assuming (naively) the invariant that: "if a cocoapod exists for a dependency, it'll work if we convert xmtp-ios to a cocoapod" then:

web3swift has a cocoapod: https://cocoapods.org/pods/web3.swift
GzipSwift too: https://cocoapods.org/pods/GzipSwift

secp256k1 doesn't but I can shove that functionality into the Rust framework pretty quickly. It might be good cause the Swift library appears to be more experimental than the RustCrypto ones we use.
XMTPProto isn't a cocoapod but doesn't seem crazy to either vendor it or make it one.
Finally seems like we can specify the XMTPRustSwift.xcframework as a vendored binary and just stick it in the xmtp-ios repo. Not ideal but theoretically seems fine.
I'm sure this strategy is full of holes but wanted to get your thoughts @nakajima

Ya, I think this is the way. React Native already knows about cocoapods so we should be good here.
I am confused about how web3.swift has a cocoapod but still relies on SwiftNIO. Looking at the pod spec, it doesn't seem like they're pulling in websocket-kit which is what was bringing in SwiftNIO?

Update for future reference:
We were able to string together a solution that completely unblocks xmtp-ios as the backend for a React Native app (or SDK).
https://github.com/xmtp/libxmtp/tree/michaelx_secp256k1_in_rust_swift
https://github.com/xmtp/xmtp-rust-swift/tree/0.1.2-beta0 (overview of rough plan in README, but only for Swift Package side. The cocoapod work can be traced by following podspecs)
https://github.com/xmtp/xmtp-ios/releases/tag/0.1.3-beta0
Two cocoapods were manually pushed (XMTPRust => 0.1.2-beta0) and (XMTP => 0.1.3-beta0)
Current work is productionizing the Rust side of things.


[chore] Update service_mesh related keys

Notes for Reviewers
This PR updates the keys with 'service mesh' in their names with 'cloud native'
Goes in tandem with https://github.com/layer5io/meshery-cloud/pull/2595
Signed commits

[x] Yes, I signed my commits.

@dragon-slayer875 let's discuss this PR during the Meshery dev meeting call, if you would. Please add it as an agenda item to the meeting minutes.

@Yashsharma1911


bug: toggle should have a hover state

What version of daisyUI are you using?
daisyui 4.5.0
Which browsers are you seeing the problem on?
All browsers
Reproduction URL
n/a
Describe your issue
By default, DaisyUI's button has hover https://github.com/saadeghi/daisyui/blob/c13b26bea8db8fa0d45eb60055f4fdee865f911e/src/components/styled/button.css#L23-L43
However, I noticed the same doesn't exist for toggle.
Is this done intentionally?

PS. thanks for the amazing library

Happy to send a PR if it should have hover state.

I don't think it's necessary, but of course you can customize the style for your own project using utility classes.


Generating additionalProperties of a schema

Problem description
additionalProperties are currently not reflected inside the generated .proto. Considering the following OpenAPI definition, an empty message is currently generated for the response.
/testResponseAdditionalProperties:
    get:
      operationId: testResponseAdditionalProperties
      responses:
        '200':
          description: successful operation
          content:
            application/json:
              schema:
                type: object
                additionalProperties:
                  type: integer
                  format: int32

What would be a proper way to generate additionalProperties inside .proto?

Based on the discussion on swagger.io, we might consider generating them as a protobuf map field.
However, this might be a tad weird/break the contract because the generated type would have an extra level of depth. Example: response.GetFieldThatsAMap().Get("key") rather than response.Get("key") like a "dictionary".
The nature of protobuf makes it hard to have "free form" objects.

Thanks Noah. I implemented it accordingly.
@noahdietz if we have additionalProperties with type array (see), it gets generated like this, because we can't do something like map<string, repeated int32> ok = 1; If that is ok, I would close this issue.

This is a little tougher. A google.protobuf.Any requires an actual Message type to still be associated with it. See the documentation where it states:

The Any message type lets you use messages as embedded types without having their .proto definition. An Any contains an arbitrary serialized message as bytes, along with a URL that acts as a globally unique identifier for and resolves to that message's type

An OAS array is not the same as a protobuf Message, arrays can only be used in protobuf when contained as a field in a Message. Thus, we wouldn't be able to deserialize the Any bytes into a corresponding type.
I don't think this will work, but to address that we'd add a Message type of our own to wrap the response in. For example:
message TestAdditionalPropertiesArrayResponsesSet {
  repeated int32 items = 1;
}

message TestAdditionalPropertiesArrayResponses {
  map<string, TestAdditionalPropertiesArrayResponsesSet> ok = 1;
}

Again I don't think this will work because it is fundamentally different from the JSON representation.
This specific combination might be one that we cannot support. It is very specific and I'm OK with not supporting it until someone opens an issue for it or we can supply an example of it being used in the wild.
WDYT?

Ok I see. So I think the best thing to do at this point is to warn the user that an array inside additionalProperties won't be represented inside the proto definition. And if someone opens an issue about this, we can implement it accordingly.

Agreed!

Closed for now.


[BUG] setup.cfg find_namespace: includes build directory

setuptools version
54.2.0
Python version
3.8.2
OS
Ubuntu 18.04
Additional environment information
No response
Description
I am not sure if this is a bug or a documentation issue (or both).
My goal is to port the minimal setup.py based example here to the minimal setup.cfg based example here.
Outputs for each variant are in READMEs of each of the directories.
The output contains the build directory if it exists in the local directory, even though setup.cfg excludes it (or attempt to at least).
Side note:
The setup.py based example do not need to explicitly exclude build, and does not end up with a build dir in the wheel even on subsequent runs.
In terms of usability, it would be great if we can achieve the same behavior without an explicit blacklist of directories.
Code of Conduct
I agree to follow the PSF Code of Conduct

Hi @omry, thank you very much for bringing this up.
I think it all boils down to the fact that you are using the include parameter with setup.py, but then you use exclude with setup.cfg...
Have you tried also using include with setup.cfg?
There also seems to be a problem with your exclude configuration, both include and exclude accept package names, not file paths. So instead of build/*, I would use build.*...
I will close this issue for now, but please let me know if this does not work for you and I will re-open it.


Change sonar.javascript.lcov.reportPaths path

Codecov Report
Patch and project coverage have no change.

Comparison is base (e238343) 62.50% compared to head (491c4ab) 62.50%.

Additional details and impacted files
@@           Coverage Diff           @@
##             main       #8   +/-   ##
=======================================
  Coverage   62.50%   62.50%
=======================================
  Files           4        4
  Lines          64       64
  Branches        6        6
=======================================
  Hits           40       40
  Misses         23       23
  Partials        1        1

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


python312Packages.cryptodatahub: 0.12.2 -> 0.12.4

Diff: https://gitlab.com/coroner/cryptodatahub/-/compare/refs/tags/v0.12.2...v0.12.4
Changelog: https://gitlab.com/coroner/cryptodatahub/-/blob/0.12.4/CHANGELOG.rst
Description of changes
FIx build (https://hydra.nixos.org/build/256665845)

Things done

Built on platform(s)

[ ] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)

[ ] sandbox = relaxed
[ ] sandbox = true

[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[ ] Tested basic functionality of all binary files (usually in ./result/bin/)
24.05 Release Notes (or backporting 23.05 and 23.11 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[ ] Fits CONTRIBUTING.md.

Add a :+1: reaction to pull requests you find important.

Result of nixpkgs-review pr 309009 run on x86_64-linux 1

12 packages built:

python311Packages.cryptodatahub
python311Packages.cryptodatahub.dist
python311Packages.cryptolyzer
python311Packages.cryptolyzer.dist
python311Packages.cryptoparser
python311Packages.cryptoparser.dist
python312Packages.cryptodatahub
python312Packages.cryptodatahub.dist
python312Packages.cryptolyzer
python312Packages.cryptolyzer.dist
python312Packages.cryptoparser
python312Packages.cryptoparser.dist


feat: allow setting threat exceptions

Currently if you add threat exception in the UI, the module will try to remove it:
  # module.cloud-ids.google_cloud_ids_endpoint.ids_endpoint will be updated in-place
  ~ resource "google_cloud_ids_endpoint" "ids_endpoint" {
        id                       = "projects/demo-project/locations/us-east1-a/endpoints/cloud-ids"
        name                     = "cloud-ids"
      ~ threat_exceptions        = [
          - "12345",
        ]
        # (8 unchanged attributes hidden)
    }

This PR adds a new variable, which is an empty list by default, that allows adding threat exceptions.

/gcbrun


Release 2023.8.0

Checklist

[x] Used a personal fork of the feedstock to propose changes
[ ] Bumped the build number (if the version is unchanged)
[x] Reset the build number to 0 (if the version changed)
[x] Re-rendered with the latest conda-smithy (Use the phrase @conda-forge-admin, please rerender in a comment in this PR for automated rerendering)
[x] Ensured the license file is being packaged.

Fixes https://github.com/conda-forge/dask-sql-feedstock/issues/64
Fixes https://github.com/conda-forge/dask-sql-feedstock/issues/66
Fixes https://github.com/dask-contrib/dask-sql/issues/1169

Thanks Ayush! 🙏

Could you please drop these lines and re-render?
https://github.com/conda-forge/dask-sql-feedstock/blob/4ec2ca4dbe6b95fcaa20e9bb20184d4fca1f6824/recipe/conda_build_config.yaml#L1-L3
This will resolve issue ( https://github.com/conda-forge/dask-sql-feedstock/issues/64 )

@conda-forge-admin, please rerender

Thanks Ayush! 🙏
Added automerge so this merges once CI passes


Fix View.propTypes deprecation warning.

Getting a deprecation warning for View.propTypes
react: 16.0.0-alpha.6
react-native: 0.44.0
Looks like it's being caused right here
https://github.com/DylanVann/react-native-fast-image/blob/master/FastImage.js#L90

DONE!


Decide which scripts, etc to include in the mdtk package

Probably most/all of them? But we should think about exactly what functionality the end-user would want.

I reference this in https://github.com/JamesOwers/midi_degradation_toolkit/pull/79 latest comment. In my opinion, for now, we just expect people to:

clone the repo
pip install as the "setup" step to get code in the repo to work i.e. all this really does is makes all import mdtk... references in code work (and imports of required packages)

At a later date we can think about releasing scripts with the package, but for now I like this setup as it's more explicit for users. Pip installing mdtk with scripts will hide away readme files and other stuff, requiring us to make some sort of documentation website.

That seems reasonable to me. Will think about this.


Add metric-nfsstat.rb

Pull Request Checklist
Is this in reference to an existing issue? No.
General

[x] Update Changelog following the conventions laid out on Keep A Changelog

[ ] Update README with any necessary configuration snippets

[x] Binstubs are created if needed

[x] RuboCop passes

[ ] Existing tests pass

New Plugins

[ ] Tests

[x] Add the plugin to the README

[x] Does it have a complete header as outlined here

Purpose
This metric plugin runs the nfsstat command and prints the metrics. Example output follows:
% /opt/sensu/embedded/bin/ruby bin/metric-nfsstat.rb --scheme nfsstat
nfsstat.v3.client.total 66<PHONE_NUMBER>
nfsstat.v3.client.getattr 20<PHONE_NUMBER>
nfsstat.v3.client.lookup 6<PHONE_NUMBER>
nfsstat.v3.client.access 16<PHONE_NUMBER>
nfsstat.v3.client.fsstat 12<PHONE_NUMBER>
nfsstat.v3.client.fsinfo 8<PHONE_NUMBER>
nfsstat.v3.client.pathconf 4<PHONE_NUMBER>
nfsstat.v4.client.total<PHONE_NUMBER>189379
nfsstat.v4.client.read 42583<PHONE_NUMBER>
nfsstat.v4.client.open 2<PHONE_NUMBER>
nfsstat.v4.client.open_conf 2<PHONE_NUMBER>
nfsstat.v4.client.close 1<PHONE_NUMBER>
nfsstat.v4.client.fsinfo 11<PHONE_NUMBER>
nfsstat.v4.client.renew 8<PHONE_NUMBER>
nfsstat.v4.client.setclntid 2<PHONE_NUMBER>
nfsstat.v4.client.confirm 2<PHONE_NUMBER>
nfsstat.v4.client.access<PHONE_NUMBER>379
nfsstat.v4.client.getattr<PHONE_NUMBER>189379
nfsstat.v4.client.lookup 22<PHONE_NUMBER>
nfsstat.v4.client.lookup_root 12<PHONE_NUMBER>
nfsstat.v4.client.pathconf 8<PHONE_NUMBER>
nfsstat.v4.client.statfs 8<PHONE_NUMBER>
nfsstat.v4.client.readdir 4<PHONE_NUMBER>
nfsstat.v4.client.server_caps 19<PHONE_NUMBER>
nfsstat.v4.client.secinfo 5<PHONE_NUMBER>

Known Compatablity Issues
I've only tested this on Ubuntu Trusty. No known issues so far.

I've left some items unchecked as there's no need for config snippets for this plugin and there are no tests in this repository.

Does anyone have chance to review this?

Mind renaming metric- to metrics-? This is usually how we call metrics scripts.

@analytically Thank you for reviewing. Should we rename other metrics plugins in this repository as well?

Yes please.

Okay, will do.

Done. If everything looks fine, I'll squash the fixups.

I was thinking to squash commits, but anyway, thank you! Mind making a new release? Note that this contains breaking changes due to the renaming.

Hmm I'm wondering if I should have contributed this script to sensu-plugins/sensu-plugins-memory-checks rather than here as it's all about memory.


Workspaces

Description
This PR implements some workspaces stuff, hopefully addressing #4.
The code is a bit messy but hopefully the basic stuff is there. To test, fetch a list of available workspaces and their IDs by running
clockify-tui list-workspaces

After including the ID in the config file you can run
clockify-tui workspace-info

to fetch information about the workspace ID you provided in the config.
The workspace info thing might be a bit useless, but I suppose it just serves to demonstrate that it works. Having this ability to fetch and set workspace IDs will come in handy later when implementing further functionality.
Fixes #4
Type of change

[ ] Documentation (non-breaking change that adds or improves the documentation)
[x] New feature (non-breaking change which adds functionality)
[ ] Optimization (non-breaking, back-end change that speeds up the code)
[ ] Bug fix (non-breaking change which fixes an issue)
[ ] Breaking change (whatever its nature)

Key checklist

[x] All tests pass (eg. python -m pytest)
[ ] The documentation builds and looks OK (eg. python -m sphinx -b html docs docs/build)
[ ] Pre-commit hooks run successfully (eg. pre-commit run --all-files)

Further checks

[ ] Code is commented, particularly in hard-to-understand areas
[ ] Tests added or an issue has been opened to tackle that in the future. (Indicate issue here: # (issue))

I've addressed the first half of your comment, but I'm not really sure how we want to go about the try_read_config() problem. If no config is present then the user is prompted to create one, if the user selects no then it fails. The problem is we always need to have a config file because we always need at least the API_KEY. It seems that we shouldn't really be offering the user the option to not create a config file?

Sorry, I thought I replied to this and now I've noticed you're away :-(.
The issue is that while almost every command needs a valid config file for the program to work, there are a couple of cases where we need the command to run even without a config file (or a malformed one). For example, we want the user to be able to run clockify-tui --help without one and that won't currently work.
As you're away, I'll just finish this up so we can make use of it today. Hope that's ok!


Can pretrained models for yolox and yolov7 be provided?

The models trained on the COCO dataset are available at YOLOX and YOLOv7 repositories.
The YOLOX models trained on the MOTChallenge datasets are available at the ByteTrack repository.
I will be releasing the YOLOv7 models for MOTChallenge soon.

@NirAharon Thanks for the work. I'm curious about the difference of metrics when using YOLOX and YOLOv7.


[DeformConv] Fix zero outputs when not running on cuda:0

Currently, deform_conv only works for cuda:0
from ops.dcn.deform_conv import DeformConv, deform_conv

## Works normally
device = "cuda:0"
out = deform_conv(x, offset, weight, 1, [1, 1], 1, 2, 2)
print(out.mean(), out.var())
# tensor(0.1310, device='cuda:0'), tensor(0.1312, device='cuda:0')

## Fails to work
device = "cuda:1"
out = deform_conv(x, offset, weight, 1, [1, 1], 1, 2, 2)
print(out.mean(), out.var())
# tensor(0., device='cuda:1'), tensor(0., device='cuda:1')

The patch aims to fix the issue.

Thanks for the fix!

Hi @Lyken17 ！First of all, we want to express our gratitude for your significant PR in the mmdetection project. Your contribution is highly appreciated, and we are grateful for your efforts in helping improve this open-source project during your personal time. We believe that many developers will benefit from your PR.
We would also like to invite you to join our Special Interest Group (SIG) private channel on Discord, where you can share your experiences, ideas, and build connections with like-minded peers. To join the SIG channel, simply message moderator— OpenMMLab on Discord or briefly share your open-source contributions in the #introductions channel and we will assist you. Look forward to seeing you there! Join us ：https://discord.gg/raweFPmdzG
If you have WeChat，welcome to join our community on WeChat. You can add our assistant ：openmmlabwx. Please add "mmsig + Github ID" as a remark when adding friends：）
Thank you again for your contribution❤


question: is node-gyp required as a dependency?

When using node-gyp-build to build a Node.js native addon:
is the node-gyp package required in the project too, or does node-gyp-build have the same capabilities?
In my Node.js project, I have a binding.gyp file, C and C++ code. I use node-gyp-build and also prebuildify to create prebuilds to speed up local development.

The node-gyp package comes bundled with npm (meaning all users have it) and that's what node-gyp-build uses by default. In order to use a newer (or older, or just consistent) version of node-gyp, you can add it to your dependencies, and then node-gyp-build will prefer that over the npm-bundled one.

Actually let me double-check that - I might be confusing prebuildify behavior with node-gyp-build.

OK I checked, prebuildify has a workaround to override the npm-bundled node-gyp but node-gyp-build does not. In other words, for node-gyp-build you do not need to add node-gyp to your dependencies and even if you did it would not make a difference (for end users). You can choose to add node-gyp to your devDependencies though, if you need that for prebuildify.

Thank you for clarifying!
That makes total sense, because I had by accident put node-gyp in the devDepencencies section of my project (but all things still working fine). 😄


new theme and adjustments

[x] new logo
[x] new theme: sphinx-book-theme
[x] new extensions: sphinx-copybutton and sphinx-design. The latter substitutes sphinx-panels which is now no longer maintained.
[x] added comments in conf.py
[x] pages examples.rst and index.rst have been updated to use sphinx-design instead of sphinx-panels.
[x] index.rst and team.rst have also been refactored to adjust to the new layout.
[x] added dependencies in sarkas_env.yaml
[x] removed old theme files

there are some minor issues with this new theme

[ ] sidebar toggle not being inherited ( sphinx-book-theme issue #541 ) ---- no solution has been found yet.
[ ] wrong content section in the sidebar ( sphinx-book-theme issue #545 ) ----- this is now fixed upstream, we just need to wait for a release
[ ] the recursive creation of api pages doesn't always work on functions. See for example links in potentials -> sarkas.potentials.egs


FEAT: support chatglm3 with ggml format

Resolve #609
Resolve #608

it looks like not chatglm3
    "model_description": "ChatGLM3 is the third generation of ChatGLM, still open-source and trained on Chinese and English data.",     "model_specs": [       {         "model_format": "ggmlv3",         "model_size_in_billions": 6,         "quantizations": [           "q4_0"         ],         "model_id": "Xorbits/chatglm2-6B-GGML",


Add difficulty calculation

while target is the precise threshold, difficulty is popular
includes https://github.com/apoelstra/rust-bitcoin/pull/42

ACK


totem: build with gst-libav and gst-plugins-ugly

Things done

[x] Tested using sandboxing (nix-build --option build-use-chroot true or nix.useChroot on NixOS)
Built on platform(s)

[x] NixOS
[ ] OS X
[ ] Linux

[x] Tested compilation of all pkgs that depend on this change using nix-shell -p nox --run "nox-review wip"
[x] Tested execution of all binary files (usually in ./result/bin/)
[ ] Fits CONTRIBUTING.md.

Without gst-libav, totem is unable to play most video files.

cc @lethalman @DamienCassou

Travis passed, thanks.


Support Kafka supervisor adopting running tasks between versions

Motivation
A Kafka supervisor expects to 'own' all index_kafka type tasks running on its configured datasource. When the supervisor starts up, it checks TaskStorage to get a list of all the active tasks, and for each running Kafka task for the datasource, it checks whether the task is 'adoptable' or has to be terminated because it does not match the supervisor's configuration. A task is adoptable by a supervisor if it was created with the same strategy for assigning Kafka partitions, has a set of starting offsets that matches the state described in the metadata store, and has the same data schema and tuning config. All of this information is represented in the sequenceName hash that is calculated on task creation and is stored as part of the task metadata.
Currently, when checking for adoptability, the supervisor generates a hash based on its expected starting offsets and its data schema / tuning configuration, and then compares the hash to the one generated when the task was created. If they match, the supervisor adopts and starts tracking the lifecycle of the task; otherwise the task is killed and a new one is created from the supervisor's configuration.
If between Druid versions the definition of DataSchema or KafkaTuningConfig changes (for example a new field is added), this implementation will cause the calculated hash to differ and the task to be rejected, even if the ingestion specs are 'equivalent'. This is because the logic compares the stored hash generated using the old ingestion schema definition with one generated with the new schema definition which may be backward-compatible but generates a different hash. As a result, doing a rolling update of the overlord may cause indexing tasks to terminate unnecessarily.
Proposed Changes
Instead of the supervisor computing the sequenceName hash for its own configuration and comparing this to the hash the task was created with, the supervisor should re-compute the task's hash using the task's data schema and tuning config. This will have the effect of changes in the data schema and tuning config class definitions being represented in the hash so that a proper comparison can be made.
Changed Interfaces
None
Migration
None
Alternatives
An alternative implementation might be to exclude the data schema and tuning config from the hash altogether, meaning that a supervisor would adopt an existing running task without consideration of the ingestion parameters, and would just let it run to completion. Once that task completes, the supervisor would then spawn subsequent tasks that match the supervisor's new configuration regardless of how the previous task was configured.
I think the complexity here comes in when you consider replica tasks and what a supervisor should do if there are replicas and a task fails. Since replicas are expected to do the same thing and generate identical segments independently, the supervisor would need to spawn a replacement task that has a configuration that matches the old configuration being used by the replica rather than using its own configuration.
There may be other complications in not including the ingestion spec as part of the sequenceName hash. Ultimately, the proposed change feels more straightforward and accomplishes the objective of supporting task adoption across versions.

I'm working on this issue

is this the cause of #6854

It sounds like it probably is.

the documentation for rolling updates should then atleast reflect this info that there can be several minutes of query downtime when doing a rolling update to the overlord.
if any configuration value can be adjusted to make this downtime shorter, it should be listed in said documentation

It looks like there is intent to fix this before the next release anyway.

correct me if i am wrong, but this is scheduled for 0.15 release right?
shouldn't we atleast update the 0.14 release where this issue will still exist


ReferenceError when Markdown file contains HTML with curly braces

🐛 Bug Report
I have automatically generated Markdown files (.md) that contain HTML. The page crashes if that HTML contains a pair of curly braces:

This {html} code is in a .md file.

Results in: ReferenceError: html is not defined
Have you read the Contributing Guidelines on issues?
Yes.
To Reproduce

https://codesandbox.io/s/reverent-lederberg-f8jcl
Access the first page.
An error is thrown: ReferenceError: page is not defined

Expected behavior
I was expecting to be able to access the page and read my content.
Actual Behavior
Instead the page crashed with an error message.

Your Environment

Public source code: https://codesandbox.io/s/reverent-lederberg-f8jcl
Public site url: https://codesandbox.io/s/reverent-lederberg-f8jcl
Docusaurus version used: 2.0.0-alpha.70
Environment name and version: Chrome 88.0.4324.192, Node.js v10.23.0
Operating system and version: macOS Catalina 10.15.6

Reproducible Demo
https://codesandbox.io/s/reverent-lederberg-f8jcl
If you want to reproduce it on your own, here's how you can do it:

Create a new docusaurus project.
Edit a Markdown file and add HTML in it with something wrapped with curly braces, for example:
Hey {there}!

Start the application and try accessing the page you edited.

Although I like the idea that Docusaurus is able to infer some nice defaults, it seems that Markdown has some incompatibilities with MDX. So perhaps it should not be parsed as MDX if the file extension is .md?

I just stumbled upon the feature request and RFC.
Feel free to close this issue if you think it's a duplicate.

I don't think this was fixed by #3018 since even if I specify format: 'md' in my front matter I still get Could not parse expression with acorn (caused by the unescaped { in the markdown file)


Support a subset of annotations on the service resources

This should allow users to specify custom healthchecks per service and resolve #93.

Coverage decreased (-0.5%) to 20.867% when pulling 7607db222ff28ca5d18ec93dfa9f5d8326a3d7f1 on service-annotations into 0ddcba1f8274780ff68aaf50e4683023802b5f00 on master.

Minor changes requested. Spinning up a test cluster now to do some verification.

The only issue i've hit when testing the controller doesn't fallback on the ingress resource as they should.
For example, I've set my healthcheck-port to 8880. In the ingress resource.
$ kubectl get ing -n echoserver echoserver -o yaml
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  annotations:
    alb.ingress.kubernetes.io/healthcheck-interval-seconds: "30"
    alb.ingress.kubernetes.io/healthcheck-port: "8880"

But in AWS, it's still using the traffic port as seen below.

If I add this setting to the service, it will be respected.
apiVersion: v1
kind: Service
metadata:
  annotations:
    alb.ingress.kubernetes.io/healthcheck-port: '8880'

But after removal from the service resource, even though that setting is still in the ingress resource, it goes back to the default (traffic port).
$ kubectl get -o yaml -n echoserver svc echoserver
apiVersion: v1
kind: Service
metadata:
  annotations:
    kubectl.kubernetes.io/last-applied-configuration: |
      {"apiVersion":"v1","kind":"Service","metadata":{"annotations":{},"name":"echoserver","namespace":"echoserver"},"spec":{"ports":[{"port":80,"protocol":"TCP","targetPort":8080}],"selector":{"app":"echoserver"},"type":"NodePort"}}
  creationTimestamp: 2017-11-18T00:33:17Z
  name: echoserver
  namespace: echoserver
  resourceVersion: "6811"
  selfLink: /api/v1/namespaces/echoserver/services/echoserver
  uid: 12541ce2-cbf8-11e7-8ebd-0aeebdf18292
spec:

Perhaps this is a small issue inside of the new annotations.Join?

Gotta be. That’s what I get for not writing a test function.
On November 17, 2017 at 4:59:15 PM, joshrosso<EMAIL_ADDRESS>wrote:

The only issue i've hit when testing the controller doesn't fallback on
the ingress resource as they should.
For example, I've set my healthcheck-port to 8880. In the ingress
resource.
$ kubectl get ing -n echoserver echoserver -o yaml
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
annotations:
alb.ingress.kubernetes.io/healthcheck-interval-seconds: "30"
alb.ingress.kubernetes.io/healthcheck-port: "8880"
But in AWS, it's still using the traffic port as seen below.
[image: image]
https://user-images.githubusercontent.com/6200057/32975028-02e716d8-cbb8-11e7-8187-04c65072d6b1.png
If I add this setting to the service, it will be respected.
apiVersion: v1
kind: Service
metadata:
annotations:
alb.ingress.kubernetes.io/healthcheck-port: '8880'
[image: image]
https://user-images.githubusercontent.com/6200057/32975040-34ad91ba-cbb8-11e7-8f9d-23630f37e2f5.png
But after removal from the service resource, even though that setting is
still in the ingress resource, it goes back to the default (traffic port).
$ kubectl get -o yaml -n echoserver svc echoserver
apiVersion: v1
kind: Service
metadata:
annotations:
kubectl.kubernetes.io/last-applied-configuration: |
{"apiVersion":"v1","kind":"Service","metadata":{"annotations":{},"name":"echoserver","namespace":"echoserver"},"spec":{"ports":[{"port":80,"protocol":"TCP","targetPort":8080}],"selector":{"app":"echoserver"},"type":"NodePort"}}
creationTimestamp: 2017-11-18T00:33:17Z
name: echoserver
namespace: echoserver
resourceVersion: "6811"
selfLink: /api/v1/namespaces/echoserver/services/echoserver
uid: 12541ce2-cbf8-11e7-8ebd-0aeebdf18292
spec:
[image: image]
https://user-images.githubusercontent.com/6200057/32975064-6a96580c-cbb8-11e7-8162-ba1e981e3afd.png
Perhaps this is a small issue inside of the new annotations.Join?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/coreos/alb-ingress-controller/pull/269#issuecomment-345404849,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAfB8xYYsGwvsg76D8d8x1Xqb9Ce0gQYks5s3ivigaJpZM4QirOm
.

Why are we not simply specifying the custom healthcheck per targetGroup inside the ingress file itself ? Why the need to use an annotation from the service definition? Wont this be so much cleaner and intuitive like this:
#ingress yaml
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: myIngress
  namespace: default
  annotations:
    alb.ingress.kubernetes.io/scheme: internal
spec:
  rules:
  - host: myhost.com
    http:
      paths:
      - path: /path1
        backend:
          serviceName: service1-stg
          servicePort: 8080
          healthCheckPath: /path1/health
      - path: /path2
        backend:
          serviceName: service2-stg
          servicePort: 9000
          healthCheckPath: /path2/health

@rahulsen agreed, but its not supported in the ingress spec, i know they are looking at extending it


Docs: Progress bar for pipelines

We plan to add an optional progress bar to the run method in the dependency, fluxus: https://github.com/BCG-X-Official/fluxus/issues/23
It will then be available to the run method in artkit and we should introduce it in the "Building Your First ARTKIT Pipeline" tutorial, specifically in the section where we introduce the core ARTKIT functions.
Once the progress bar is added and we have updated the fluxus version in artkit, we will re-open this issue.

Goodmorning @rgriff23 , I would like to work on this issue, could you please assign it to me?
Also, if I have any doubts, can I reach out to you on this thread?

Hi @ParthJohri! You can certainly pick this up - I suggest tagging @seanggani for questions.

Hi @ParthJohri , apologies for missing your comment! Please let us know if there's anything we can help with

Thank you, @seanggani @rgriff23 for assigning the issue.
Screen Recording & Screenshots
I implemented this progress bar using progressbar2 package instead of tqdm on the page to show how to instantiate a Gemini model class to interact with the Gemini API:
https://github.com/BCG-X-Official/artkit/assets/76129377/021773f8-de6c-4800-83e8-fedb2e0cacc0

So we have to do the same on the pipeline page right?
The progress bar for pipeline by this I understood when the user would run the pipeline, the progress should start and show the progress, right?

Could you please tell if I am understand it wrong or moving in right direction?

Thanks @ParthJohri, this is a great start! I'll defer to @seanggani and @breakbotz to review the implementation details.
My main suggestion is for the progress bar to be implemented as an optional argument for the run function, e.g., progress_bar=True displays a progress bar, and I'd suggest it defaults to False. This approach ensures that the progress bar is only shown when it is actually useful, avoiding unnecessary clutter when the pipeline runs quickly due to cached results (which is the case in all of our documentation tutorials) or because the user is testing out a simple pipeline.
I'd suggest we introduce the progress bar explicitly in the "Building Your First ARTKIT Pipeline" tutorial, in the section where we introduce the core ARTKIT functions. Otherwise, I don't think we should include it throughout our documentation tutorials since all the tutorials are using cached results to ensure reproducibility, and we don't want to display progress bars which could give a misleading perception of how fast the pipelines run when there is no cache.

@ParthJohri the core team will need to discuss implementation internally before we can give feedback for you to move forward. Thanks in advance for your patience!

Thank you @rgriff23 for your reply, I would be waiting for the response to the implementation.

@ParthJohri thanks for making the first pass at solving this! After discussing internally, we realized this is a more complex implementation which needs to be implemented in a dependency called fluxus. The change will require a good understanding of the underlying architecture of fluxes, so we think it is best handled by our core team.
Conclusion from our technical discussion:

The challenge is, there is no straightforward way of telling how many results a flow will produce, given that individual steps or parallel steps can create multiple outputs for any one input. Thus, while it is easy to count how many run results are already complete, we cannot easily translate this to 100%. For a meaningful progress bar, we need to come up with progress estimates for all steps & propagate these along the flow. I.e. once we know the number of inputs, we estimate the number of outputs of every step to be 1, then update that estimate if the input/output ratio starts to be different. in most cases this will lead to a reasonable progress bar. In some cases, estimates may need to be updated and progress can go from say 80% back to 60%.

Some suggestions for alternative ways to contribute to artkit:

There are a couple of "good first issues" you could tackle. These aren't very interesting from an engineering perspective, but they would be useful contributions to the documentation:
a. Add GitHub links to tutorials: https://github.com/BCG-X-Official/artkit/issues/46
b. Add badges to README: https://github.com/BCG-X-Official/artkit/issues/29
For a more interesting engineering challenge, you could take on:

Add a new LLM connector for Cohere: https://github.com/BCG-X-Official/artkit/issues/47

After we add a progress bar to the run function in fluxus and update the fluxus version used in artkit, we will want to add a demo and explanation to the artkit documentation. If you're interested, we can assign that to you.

Let me know what you think!

@ParthJohri thanks for making the first pass at solving this! After discussing internally, we realized this is a more complex change which needs to be implemented in a dependency called fluxus. The change will require a good understanding of the underlying architecture of fluxes, so we think it is best handled by our core team.
FYI - some details from our technical discussion:

The challenge is, there is no straightforward way of telling how many results a flow will produce, given that individual steps or parallel steps can create multiple outputs for any one input. Thus, while it is easy to count how many run results are already complete, we cannot easily translate this to 100%. For a meaningful progress bar, we need to come up with progress estimates for all steps & propagate these along the flow. I.e. once we know the number of inputs, we estimate the number of outputs of every step to be 1, then update that estimate if the input/output ratio starts to be different. in most cases this will lead to a reasonable progress bar. In some cases, estimates may need to be updated and progress can go from say 80% back to 60%.

Some suggestions for alternative ways to contribute to artkit:

There are a couple of "good first issues" you could tackle. These aren't very interesting from an engineering perspective, but they would be useful contributions to the documentation:

Add GitHub links to tutorials: https://github.com/BCG-X-Official/artkit/issues/46
Add badges to README: https://github.com/BCG-X-Official/artkit/issues/29

For a more interesting engineering challenge, you could take on:

Add a new LLM connector for Cohere: https://github.com/BCG-X-Official/artkit/issues/47

After we add a progress bar to the run function in fluxus and update the fluxus version used in artkit, we will want to add a demo and explanation to the artkit documentation. We will rescope this issue as documentation-only and re-open it then. If you're interested in taking that on, we can keep you assigned.

Let me know what you think!

Thank you @rgriff23 for the clarification, I would be glad to work on the beginner issues and make my way to understand the code base to contribute further.

@ParthJohri great! Do you mind checking the beginner issues and commenting on the one you'd like to pick up first? I can't assign an external contributor until you engage with the issue.

@ParthJohri great! Do you mind checking the beginner issues and commenting on the one you'd like to pick up first? I can't assign an external contributor until you engage with the issue.

Absolutely @rgriff23 thank you so much, also sorry for not being able to reply promptly, I am unwell at the moment.
I would surely look at other issues as soon as I feel better, pick up one and would tag you to get it assigned.


SW-6343 Replace accelerator welcome banner image

Use design provided SVG
OLD

NEW

Noticed it look very little in mobile:

Noticed it look very little in mobile:

Yep, I think this is actually an improvement from how it used to look.  Moreover we don't support accelerator features in mobile at the moment so I think this is okay.


stuck at "manage merchants" page

Self-hosting, localhost, docker
After login, it'll get stuck on this page. Nothing at all happens

Which version are you using? This issue should be fixed in the latest release

An old one which was release in August.
I've removed the repo, re-cloned it, re-created a docker image, but it still is using on old version:
docker-compose -f docker-compose.local.yml up --force-recreate --build oxygen

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

oxygen-oxygen-1    | {"level":"info","service":"oxygen","version":"2761fee189884718ea48ba32522a17eecf170a5e","env":"production","host":"0830d8b85e3c","channel":"scheduler","cron_spec":"@every 30s","job":"checkIncomingTransactionsProgress","job_id":"checkIncomingTransactionsProgress-1696295488","time":"2023-10-03T01:14:28Z","caller":"/src/internal/app/app.go:306","message":"job completed"}

where 2761fee189884718ea48ba32522a17eecf170a5e is  as hash of v0.5.1
Why?


Fixing Pagination to Accept Offsets

Description
Please add an informative description that covers that changes made by the pull request and link all relevant issues.
If an SDK is being regenerated based on a new swagger spec, a link to the pull request containing these swagger spec changes has been included above.
All SDK Contribution checklist:

[ ] The pull request does not introduce [breaking changes]
[x] CHANGELOG is updated for new features, bug fixes or other significant changes.
[x] I have read the contribution guidelines.

General Guidelines and Best Practices

[x] Title of the pull request is clear and informative.
[x] There are a small number of commits, each of which have an informative message. This means that previously merged commits do not appear in the history of the PR. For more information on cleaning up the commits in your PR, see this page.

Testing Guidelines

[x] Pull request includes test coverage for the included changes.

@kushagraThapar for some reason this code is causing an issue related to continuation tokens. I am trying to track down the cause. Here is the continuation token which looks properly formatted:
With my changes: {"token":"-RID:~gvZRALmnZ+0BAAAAAAAAAA==#RT:1#TRC:1#ISV:2#IEO:65567#QCF:8","range":{"min":"","max":"FF"}}
Without my changes: {"token":"-RID:~gvZRAK0tfIIBAAAAAAAAAA==#RT:1#TRC:1#ISV:2#IEO:65567#QCF:8","range":{"min":"","max":"FF"}}
Error is:
com.azure.spring.data.cosmos.exception.CosmosAccessException: Failed to query items; nested exception is {"ClassName":"CosmosException","userAgent":"azsdk-java-cosmos/4.32.0-beta.1 Windows11/10.0 JRE/11.0.14","statusCode":400,"resourceAddress":null,"error":"{"message":"INVALID JSON in continuation token {\"token\":\"-RID:~gvZRAItbTSABAAAAAAAAAA==#RT:1#TRC:1#ISV:2#IEO:65567#QCF:8\",\"range\":{\"min\":\"\",\"max\":\"FF\"}} for Top~Context"}","innerErrorMessage":"INVALID JSON in continuation token {"token":"-RID:~gvZRAItbTSABAAAAAAAAAA==#RT:1#TRC:1#ISV:2#IEO:65567#QCF:8","range":{"min":"","max":"FF"}} for Top~Context","causeInfo":null,"responseHeaders":"{}"}

@kushagraThapar for some reason this code is causing an issue related to continuation tokens. I am trying to track down the cause. Here is the continuation token which looks properly formatted:
With my changes: {"token":"-RID:~gvZRALmnZ+0BAAAAAAAAAA==#RT:1#TRC:1#ISV:2#IEO:65567#QCF:8","range":{"min":"","max":"FF"}}
Without my changes: {"token":"-RID:~gvZRAK0tfIIBAAAAAAAAAA==#RT:1#TRC:1#ISV:2#IEO:65567#QCF:8","range":{"min":"","max":"FF"}}
This is only happening on 1 unit test that I see, CosmosTemplatePartitionIT.testPartitionedFindAllPageableMultiPages(). This is the only test trying to use nextPageable() which is when it errors.
Error is: com.azure.spring.data.cosmos.exception.CosmosAccessException: Failed to query items; nested exception is {"ClassName":"CosmosException","userAgent":"azsdk-java-cosmos/4.32.0-beta.1 Windows11/10.0 JRE/11.0.14","statusCode":400,"resourceAddress":null,"error":"{\"message\":\"INVALID JSON in continuation token {\\\"token\\\":\\\"-RID:~gvZRAItbTSABAAAAAAAAAA==#RT:1#TRC:1#ISV:2#IEO:65567#QCF:8\\\",\\\"range\\\":{\\\"min\\\":\\\"\\\",\\\"max\\\":\\\"FF\\\"}} for Top~Context\"}","innerErrorMessage":"INVALID JSON in continuation token {\"token\":\"-RID:~gvZRAItbTSABAAAAAAAAAA==#RT:1#TRC:1#ISV:2#IEO:65567#QCF:8\",\"range\":{\"min\":\"\",\"max\":\"FF\"}} for Top~Context","causeInfo":null,"responseHeaders":"{}"}

because of the change in this PR, the second query turned into a offset limit query, which will go through the TopDocumentQueryExecutionContext.java, which is expecting a different continuationToken format, for example:
2022-06-20 22:50:22,400       [TestNG-method=queryDocumentsWithTopContinuationTokens-1] INFO  TestSuiteBase - {"limit":3,"sourceToken":"{"token":"-RID:~vQpdANp5vMUFAAAAAAAAAA==#RT:1#TRC:5#ISV:2#IEO:65567#QCF:8","range":{"min":"","max":"FF"}}"}
so the sequence is:

first request is a simple query, continuationToken is whatever the server returned back
due to the change in this PR, the second request turned into offset limit query -> TopDocumentQueryExecutionContext -> expecting topContinuationTokn -> failed because the continuationToken returned from the first query is not top continuationToken

proposing change:
long offset = 0;
        long pageSize = 0;
        try {
                offset = query.getPageable().getOffset();
                pageSize = query.getPageable().getPageSize();
        } catch (UnsupportedOperationException ex) {
            // Ignore
        }

        if (query.getLimit() > 0) {
            queryString = new StringBuilder(queryString)
                    .append(" OFFSET ")
                    .append(offset)
                    .append(" LIMIT ")
                    .append(pageSize).toString();
        }

Add changelog.
move serialization logic under if condition.
use offset variable.

Done!


Update SETI-CommunityTechTree.netkan

Introduced recommended and suggested mods, since many people do not seem to look at the forum thread at all...
Thank you very much!
PS: I m the author of this mod.

Tests fine locally, it fails because Jenkins used 1.0.0 as the ksp_version and there's no version of CTT compatible with 1.0.0.
With that said, is SETI-CTT actually dependent on KSP-AVC? I'm able to run SETI-CTT without installing KSP-AVC.

I m not sure I understand.
Does that mean that I can not update the SETIctt netkan file?
How can I remedy the problem or what needs to be done?
While KSP-AVC is not technically necessary, I consider it necessary to reduce support.

Sorry, I lost track of this PR the last couple days.
If it's not technically necessary, I'm sorry but we won't force users to install it. It can happily be added as a recommends which will install by default unless a user actively unticks the checkbox. As an aside for my own education, what does KSP-AVC offer that the mini plugin doesn't?

Lots of mods only provide a .version file (for KSP-AVC), but not the mini plugin.
The problem is, that

SETI has interactions with lots of other mods
Many users who use ckan still install some mods manually
CKAN usage decreases the incentive to check the forums

So users tend to rely on ckan to keep the mods up to date, but they may forget their manually installed mods, or ckan does not have the newest version for some time (several days).
Especially for a mod like SETI with all the mod interactions, setting KSP-AVC as a dependency reduces possible support issues, which are totally avoidable.
You are not forcing users to install it. I, as the mod author, am forcing users to install it, if they install via ckan.
PS: Quill18 made a youtube series, which used SETI. He did not read the install instructions in the forum thread and did not install the CTT for many episodes. That resulted in a lot of headaches and a very wrong impression of SETI (totally bugged). Since then I m trying to minimize totally avoidable issues, eg like problems arising from the usage of SETI in combination with outdated mods (which provide a .version file for KSP-AVC, but not the KSP-AVC mini plugin).

So users tend to rely on ckan to keep the mods up to date, but they may forget their manually installed mods, or ckan does not have the newest version for some time (several days).

If a mod is hosted on KerbalStuff or GitHub, it automatically adds new releases to CKAN within the hour. But when it's hosted on Curse or Dropbox, the mod dev must add a new .ckan file manually.
I understand your dependency on KSP-AVC

You updated SETI-CTT's OP to reflect to all users of the mod that KSP-AVC is a requirement and that's good enough for me. I just want equal treatment for all users. Merging with my thanks.


Implement RV32C instruction decompressor

I implemented the RV32C extension on this emulator. Excepts C.EBREAK, all the other instructions are passed the compliance test. The detail of implementation are recorded in the commit message.
I understand that the way I implement the decompressor is very different from the instruction decoder in this project. I will try to reorganize the code and make it more modularized.
Edit at 1/20: modularization has been done.
There are somethings that I am not sure whether I implement correctly:

The error handling on the invalid 16-bits instruction (0x0000). For now, if the emulator encounters an invalid 16-bits instruction, it will halt immediately.
The address alignment in the memory_read_ifetch(). I wonder if the function returns correct data at the boundary of a chunk.
When should I increase the rv->csr_cycle?

I would like to ask ccs100203 to review.

I would like to ask ccs100203 to review.

I would like to ask ccs100203 to review.

Sorry for late reply, but should I contact ccs100203 myself to ask for a review?

I would like to ask ccs100203 to review.

Sorry for late reply, but should I contact ccs100203 myself to ask for a review?

I implemented the RV32C extension on this emulator. Excepts C.EBREAK, all the other instructions are passed the compliance test. The detail of implementation are recorded in the commit message.

Add corresponding FIXME/TODO in the comment of source files.

There are somethings that I am not sure whether I implement correctly:

The error handling on the invalid 16-bits instruction (0x0000). For now, if the emulator encounters an invalid 16-bits instruction, it will halt immediately.
The address alignment in the memory_read_ifetch(). I wonder if the function returns correct data at the boundary of a chunk.
When should I increase the rv->csr_cycle?

Instead of halting, can you raise verbose error messages when executing invalid 16-bits instruction?

I implemented the RV32C extension on this emulator. Excepts C.EBREAK, all the other instructions are passed the compliance test. The detail of implementation are recorded in the commit message.

Add corresponding FIXME/TODO in the comment of source files.

I think I implement the decoder for C.EBREAK correctly. I tried to print some message to see if the emulator executes EBREAK when it encounters C.EBREAK, and the result shows that it actually does. But in compliance test, it checks the correctness of implementation by verifying the memory dump, and it shows that the case C.EBREAK doesn't manipulate memory correctly (there should be something in the memory, but the range it tests are all filled with deadbeef). I am not sure whether the problem comes from emulator or the device configuration in compliance test. Should I still add the TODO comment?

There are somethings that I am not sure whether I implement correctly:

The error handling on the invalid 16-bits instruction (0x0000). For now, if the emulator encounters an invalid 16-bits instruction, it will halt immediately.
The address alignment in the memory_read_ifetch(). I wonder if the function returns correct data at the boundary of a chunk.
When should I increase the rv->csr_cycle?

Instead of halting, can you raise verbose error messages when executing invalid 16-bits instruction?
I raise rv_except_illegal_inst error when encounter that.

I noticed that there is a ENABLE_COMPUTED_GOTO feature in current implementation, but the DISPATCH() part do not support compressed instruction yet. Should I also add the decoder part into DISPATCH()?

Drop in favor of #11


make final page more helpful

it was a good quick start it would be good if you add links for good courses
or a book or even a deeper tutorial in c# and .net

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

ID: 0d9e98de-9df3-d63f-f6a6-aa079eb5095f
Version Independent ID: a057574c-020f-a9f0-9dfc-f8936a1132fe
Content: Collections interactive tutorial - C# quickstarts
Content Source: docs/csharp/quick-starts/list-collection.yml
Product: dotnet-csharp
GitHub Login: @BillWagner
Microsoft Alias: wiwagn

I would like to contribute to this...!

thanks bro books you mentioned seem to be really useful

Why tjis PR didn't merged...?

Why this PR didn't got merged...?

@parthpandyappp
@rpetrusha gave you an explanation when he closed your PR in https://github.com/dotnet/docs/pull/8157#issuecomment-427948943. Is that not sufficient for you?

@svick Yes.!
He said that these books were very useful to him the also that PR didn't got merged...?


Avoid multiprocessing.Queue.qsize() in MPFramework

The qsize method on multiprocessing.Queue throws a
NotImplementedError on various flavors of unix, including macOS.
Avoiding the use of this method is the only logic change necessary for
distrib-rl to run well on these systems.

I'd like to come up with a completely working solution here rather than just removing it. It may be that whatever behavior I was seeing that caused me to write all that awful qsize stuff still exists and would show up again if I looked for it without that fix. I'm sure there's a better way (perhaps just using mp.Manager.Queue is enough), so let's work on that and replace this with that solution later.

Yeah, I think there likely is a better way. Multiprocessing Queues do have some weird race conditions, and mp.Manager.Queue does work around those.
I think mp.Manager is probably fine for now, but there are some trade-offs to be aware of. Most importantly, the BaseManager  type spins up an extra server process that "owns" the objects that it manages, and all access happens via proxy objects. The docs aren't super clear about how the interprocess comms work from there on, but I think they're happening over TCP.
That comes with the benefit that it's designed for use across multiple hosts, but it may not be as efficient for this application as a queue implemented in shared memory.
With that in mind, I think if you are happy with the trade-offs of a mp.Manager.Queue, we might also want to consider Ray, as I believe it's meant to serve a similar purpose and it's meant to be quite a bit faster than mp.Manager. Otherwise we'll probably want to go for a shared memory Queue.

Here's an article on Ray with a couple of brief examples: https://towardsdatascience.com/10x-faster-parallel-python-without-python-multiprocessing-e5017c93cce1

Going to close this for now and will reopen something new when we've had a chance to talk through this some more.


include more security events in loadgen traffic

Generate a list of ~10 unique attach events that will trigger security monitoring.

Simple attacks added, PR created.

Looks good 👍. Closing.