mmax: missing span attribute in markable in maz-14172.mmax

When we parse maz-14172.mmax, we can't run
spanstring2tokens(docgraph, docgraph.node[markable][docgraph.ns+':span']).
There seems to be a markable that doesn't have a ns:span attribute.
---------------------------------------------------------------------------
KeyError                                  Traceback (most recent call last)
<ipython-input-47-d98f24611c15> in <module>()
      2     mdg = dg.read_mmax2(fname)
      3     print os.path.basename(fname), '\n==============\n\n'
----> 4     print dg.readwrite.brackets.gen_bracketed_output(mdg), '\n\n'
      5     try:
      6         print_all_chains(mdg)

/usr/local/lib/python2.7/dist-packages/discoursegraphs-0.1.2-py2.7.egg/discoursegraphs/readwrite/brackets.pyc in gen_bracketed_output(docgraph)
     70     Und [in der Region]_markable_22 gibt es Konkurrenz .
     71     '''
---> 72     opening, closing, markable2chain = gen_bracket_mappings(docgraph)
     73
     74     ret_str = u''

/usr/local/lib/python2.7/dist-packages/discoursegraphs-0.1.2-py2.7.egg/discoursegraphs/readwrite/brackets.pyc in gen_bracket_mappings(docgraph, layer)
     39     for markable in markables:
     40         span_tokens = spanstring2tokens(
---> 41             docgraph, docgraph.node[markable][docgraph.ns+':span'])
     42         opening[span_tokens[0]].append(markable)
     43         closing[span_tokens[-1]].append(markable)

KeyError: 'mmax:span'

Problem resolved with commit 229408af83035715513d2a585fa9aae8eceb658b (issue #114)


Upgrade to Bazel 2.0.0 in CI

Upgrade bazel to the latest version in CI.
The full release announcement can be found in the Blog entry on Bazel 2.0, and the release notes here.

@j3parker Seems that the check paths for build-kite have changed, so I have updated the branch rules to use these new checks (the ones above), instead of the old /pr/ ones.

I would estimated that the check paths haven't changed. The ones without /pr/ are just used when it's in-repo. I would suggest keeping the /pr/ ones as required, and start doing your work from a fork (so it's equivalent to any third-party contributor).

Hmm, this PR was a one-off using the web 'edit' (all my other work is from my fork), but is this the intended behaviour of CI?
If it is the intended behaviour, we should probably make a note when doing some improvements to the documentation to document this (maybe in CONTRIBUTING.md)

It's not desired behaviour but it is how it works :( I've messed this up quite often myself.
You can click the edit from your fork, if you remember.
Rather than documenting it we could just rely on branch protection rules. I've set every branch to require a PR (rather than just the master) which I think will solve this.


Audit log enhancements for Kubectl access path

https://github.com/rancher/rancher/issues/33126
This fix is to support audit logging from kubectl access which use kubeconfig tokens. In case of kubeconfig, the userPrincipal is not found and is missing information. Hence the audit log data is not seen.
As a fix, instead of reading extraInfo from user's login token, this is now read from userattributes where the extra info is saved after user logs in. This information can be found using the userId extracted from any token.
The userAttributes.Extra is also saved to ClusterUserAttributes.Extra field.

Discussed with @dramich and @aiyengar2 and following changes/alternatives were identified:

This solution is saving extraInfo from user's login token into userAttribute CR and reading it back by using the token's userId. But we need to additionally lookup principals of the user from the token or from userId if extraInfo is not found in userAttribute  - this is necessary to take care of the upgrade case where old tokens/old userAttribute will not have the extraInfo
We also should ideally fix kubeconfig token to carry the real authProvider and not set "local"; this will let us use the correct principalId of that provider instead of us adding a list of all principalIds to audit log

@prachidamle , even if this is approved, please do not merge it to master yet as it was decided this should not get into 2.6.0  release. So, until branches are created for release/v2.6 (and likely release/v2.6) we should't put it in master.

@snasovich I have reopened this against release/v2.6, added you as well fro review since you had reviewed and approved it earlier.
Closing this one.


fix: [SSO] Remove 'exchangeToken' validation from OauthPrompt

Fixes #4137
Description
This PR removes an outdated validation for token exchange that was causing the exchange between root and skill bots using CloudAdapter to fail.
This validation was already removed from .NET implementation in this commit.
Detailed Changes

Updated oauthPrompt' recognizeToken method removing validation for 'exchangeToken'.

Testing
Here we can see a root and a skill bot properly exchanging the token.

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

0 of 0   changed or added relevant lines in 0 files are covered.
1 unchanged line in 1 file lost coverage.
Overall coverage increased (+0.009%) to 84.555%

Files with Coverage Reduction
New Missed Lines
%

libraries/botbuilder-lg/src/templateExtensions.ts
1
84.48%

Totals

Change from base Build<PHONE_NUMBER>:
0.009%

Covered Lines:
19667

Relevant Lines:
22033

💛  - Coveralls


Giving it a frontend

I might work on a React frontend for it

Sounds interesting! What type of UI did you have in mind?


Make /connect default to SSL

Testing Jenkins PR integration

Testing Jenkins PR integration

Adding a test comment to see if Jenkins notices it.

Another comment to see if Jenkins notices.

And another comment...

Can one of the admins verify this patch?

Jenkins: retest this please

Jenkins: retest this please

Jenkins: retest this please


[DRAFT] feat: add partner counts to partner follow button

This PR resolves DIA-131
Description

PR Checklist

[X] I have tested my changes on iOS and Android.
[ ] I hid my changes behind a feature flag, or they don't need one.
[X] I have included screenshots or videos, or I have not changed the UI.
[ ] I have added tests, or my changes don't require any.
[ ] I added an app state migration, or my changes do not require one.
[ ] I have documented any follow-up work that this PR will require, or it does not require any.
[ ] I have added a changelog entry below, or my changes do not require one.

To the reviewers 👀

[ ] I would like at least one of the reviewers to run this PR on the simulator or device.

Changelog updates
Changelog updates

Cross-platform user-facing changes

iOS user-facing changes

Android user-facing changes

Dev changes

Need help with something? Have a look at our docs, or get in touch with us.

Warnings

:warning:

❌ An error occurred while validating your changelog, please make sure you provided a valid changelog.

  Generated by :no_entry_sign: dangerJS against b766883e4510d1d55368b18c12caeffc6f9a5e0f


GraphQLError Type Omits type Property

:wave: ahoy hoy. It doesn't appear that the type property on GraphQLError is part of the interface as defined here: https://github.com/prisma-labs/graphql-request/blob/016a15c9139faf9c6aabe79d05278f25fc14800e/src/types.ts#L13-L19. Please see the sample response with error below:
{
    "response": {
        "data": {
            "rateLimit": {
                "limit": 5000,
                "cost": 1,
                "remaining": 4900,
                "resetAt": "2022-04-27T13:30:38Z"
            },
            "repository": {
                "defaultBranchRef": {
                    "id": "REF_kwDOHIURH69yZWZzL2hlYWRzL21haW4",
                    "name": "main",
                    "prefix": "refs/heads/",
                    "target": null
                }
            }
        },
        "errors": [
            {
                "type": "INVALID_CURSOR_ARGUMENTS",
                "path": [
                    "repository",
                    "defaultBranchRef",
                    "target",
                    "history",
                    "pageInfo"
                ],
                "locations": [
                    {
                        "line": 15,
                        "column": 13
                    }
                ],
                "message": "`15a30ff3ff23e796f7e2cacf2cabf3b079b8a4e7 23` does not appear to be a valid cursor."
            }
        ],
        "status": 200,
        "headers": {}
    },
    "request": {
    ...

This is a relatively quick fix. Any chance we could get that in?
It's also worth mentioning that the Node convention for the sort of thing that type is trying to accomplish has been codified in the code property for entities inheriting from or extending Error - https://nodejs.org/api/errors.html#errorcode. I'd wager this is a legacy support issue, but I'd encourage you all to adopt the standard and deprecate the type property.

Is type specified by the GraphQL Standard?

You know, I'm not actually sure. But I do know that something is assigning that property with that string-code. If it's not spec, then I'd suggest shipping a type that extends the spec interface, so that type property is properly hoisted.

@shellscape Could you show an example of types with generics that would help you?


[IDEA] Web imports for WASM

When using our WASM code currently doing import to anything that is not packaged in the build (builtins, stdlib) will not work. I suggest we will allow import in a way very similar to any other web resource.
For example when we will run the following from http://test.org/py.html
rp.pyEval("import test")

The WASM import will do a HTTP GET request to http://test.org/test.py and import the content of the file.
We can also allow the users to add other paths to sys.path so the browser will try to look for the imported file there as well. I think that the paths should be treated like html paths:

path/to/import: will be relative to the current file.
/path/to/import : will be absolute to the server root.
'http://rustpypi.org/imports': will look in the imports path at domain rustpypi.org.

We should probably add the js VirtualMachine a setSysPath function like setStdout.

Related to #228

Related to #228

I think that the solution at pyodide is a little more complex then what I suggest. I believe we should start from something simple like importing pure python code first.

We could also use the PyPI API to fetch packages: https://warehouse.readthedocs.io/api-reference/json/; i.e. import x will look up x on PyPI and try to load it all somehow. The problem with both of these is that import is synchronous, as is vm.exec(), while fetch and related APIs are async.

I think that we should start with synchronous fetch maybe by using XMLHttpRequest. After that I think we can try and do something more complex. We can send an asynchronous request when we encounter the import but wait for the import to finish only on the first use.

What if we just had a WasmVM method/browser module export that accepted a module URL and returned a promise for when it was loaded? That way you would either load it from JS or do ```python
def main():
import module
browser.load_module("module", "https://module.url").then(main)

This will work great with new code someone writes specifically for RustPython WASM. I think that we would like a solution that will allow a user to use existing code in the regular way he used to.
I can't actually think about how to do what I suggest right now so I think starting with your suggestion and synchronous fetch would be best. We might want to add the pyEval a parameter with list of modules the user can ask to be loaded before the code is executed:
rp.pyEval("import module; module.cool_func()", {"imports": {"module": "https://module.url"}})

I'm opposed to using synchronous fetch; it's effectively deprecated by web standards and having it be the main or only way to load Python modules would make for a horrible UX on sites that might use RustPython, as it freezes the entire page while it's loading.

I totally agree with your point except that I would not like to force a user to convert every code he has for it to work. I don't have a good option but maybe we should let the user decide how to do it. Once the option to override __import__ will exist the user can actually decide for himself. We should probably just provide the tools. I am in favor of adding a synchronizes function that the user can override __import__ with and have a big red warning that say it is a bad option.

Now that #914 is in I think the next steps are:

[ ] Allow relative paths
[ ] Search in sys.path as possible locations for module.
[ ] Support import chain (a.py import b.py).
[ ] Add import example to demo.

I think we might want to add some mechanism for "pre" imports that will allow defining a list of imports that will happen before the code is executed.

Something I was thinking about was transforming the AST of a module that uses imports to be more like the example you gave for using browser.load_module, but I'm not sure if that would end up working.


Feature Development

I've been developing a feature to compress and encrypt the pappy project files, and have run into a bit of a hanging point.
How should I hook into the core pappy structure to check if the encrypted archive exists, and keep pappy from creating new project files?
Also, I am writing the feature as two separate plugins (one for encryption, one for compression), how do I call/import the compression feature from within the encryption feature?
Thanks in advance for any help/direction you can give me,
onizenso

Please disregard the part about importing plugins into each other, found the answer in the "Writing Plugins" documentation:
Under the "Using defer.inlineCallbacks With a Command" section:
from pappyproxy.console import load_reqlist
Still trying how best to incorporate my plugin into pappy.py, but think I am slowly getting there.
Very open to any help/direction, sorry for the bit of noobishness,
onizenso
Embarassed I didn't RTFM more closely before asking this question.

So I'm not sure if writing a plugin is the best way to go about this. Maybe pass a project file in as a command line argument, extract/decrypt the contents of the file to a temporary directory, do work, then reencrypt/compress the directory back into the file when the program quits. To do this I would probably:

Add some variables to the class in config.py to store information passed into the program
Parse the command line arguments to get the name of the project file (same place as where it checks for lite mode) and put the settings into the configuration object. You'll probably have to do something tricky with configuration since the session object right now takes in a configuration object before it starts.
Add some methods to the session object to deal with setting up/cleaning up a temporary working directory (be sure to watch permissions. data file/cmdhistory shouldn't be world-readable, maintain original permissions if you can)
Call the setup methods in the session object's start() method and the cleanup methods in the session's cleanup() method (this way cleanup will happen even if the program is killed with Ctl-C)

For the most part, I don't think you'll need to write a plugin since by the time plugins can have their commands run, files are already opened and being used. Plus in terms of usability it's probably more intuitive to pass in a project file from the command line.
Loading configuration might be tricky since we need to decrypt/decompress the directory since the config file is in the directory that's encrypted/compressed. I would probably make sure that decompressing/decrypting is the first thing to happen in the session object's start() method, then make sure that loading config.json is included in the setup process so that the rest of the code afterwards can assume that the config is set up correctly.
I sort of rambled a bit so if I didn't describe something well let me know. I'm really glad to have someone working a feature like this!

Totally agree, plugin doesn't seem to be the way to go anymore. Everything I was trying looked really hacky and gross. I can probably rewrite the plugin as a core/config feature, and still re-use alot of the code I've already written. Just need to change the approach. Better to do it right than have it be really fragile+ugly.
Most of what you are recommending is pretty clear, except I'm a little unclear on part 2. When you say project file, do you mean the name of the encrypted zip/bz2 archive?
Are you talking about something like:
On first run, create temp directory
Copy all existing project files (macros, config.json, etc.) into temp directory
Change config to point to temp directory as project root
Do work in temp directory
At close, compress all files in the temp directory into project.[zip/tar.bz2]
Encrypt archive, naming it with user supplied name (or default if none supplied)
Delete temp directory
Thanks for the detailed help on this one, if (probably when) anything else comes up I won't hesitate to post it here. Happy to be helping out.

yeah, exactly that. When I say project file I'm talking about the compressed/encrypted file. I'm imagining something like you start pappy with like pappy -e project.zip or whatever. So you would check if the flag was given and store the filename as a variable in the config object. Then in the actual code, use the filename in the config object.

ok, totally makes sense. I was essentially doing a similar thing with the plugin, but way more clunky. Think this approach will definitely clean things up a bit.
Will be careful to preserve permissions. Should have something working soon fingers-crossed

Almost finished with the crypto feature!
Still need to write some more tests to verify all the edge cases work, but the main functionality is complete. However, it is still a pretty fragile feature at this point.
If the user forgets to pass in the name of the encrypted project archive, pappy just starts in clear-text mode.
For example:
pappy -c proj.crypt starts in crypto mode
project -c silently falls back to clear text mode
Was trying to allow for default crypt file naming, should I just force passing in the archive name? Or should I skip allowing for command line passing, and just load the name from the config file/default settings in config.py?
Also, when starting in crypto mode, if the user has previously encrypted the project, it will ask them for their password to decrypt the file. If they enter the wrong password, an exception is raised, but pappy just falls back to clear-text mode.
How should I halt pappy to force the user to restart and try decryption again?
Thanks for any help/advice in advance.
P.s. At what point do you think it is appropriate for me to submit a pull request?

Awesome! If the user tries to run pappy with the flag but no name, I'd say print an error than quit. What do you mean by how to halt pappy to restart and try decryption again? Would a while loop with a try/except block work? Something like:
while True:
    try:
        do_decryption(arg)
        break
    except DecryptionException:
        print 'Incorrect password, try again?'
        if not some_confirmation_function():
            quit_pappy()

Just make sure that it's run before the listeners are opened and the console is started.
As long as you would feel comfortable using the feature for real work it should be fine to submit as a pull request. I guess as long as it encrypts/decrypts, is easy to use, doesn't open any new security issues, and doesn't crash all the time it should be fine.

Integrated


Refresh RDS branch with latest commits from main

Description of changes

Refresh RDS branch with latest commits from main
CDK / CloudFormation Parameters Changed

Issue #, if available

Description of how you validated changes
Checklist

[x] PR description included
[x] yarn test passes
[ ] Tests are changed or added
[ ] Relevant documentation is changed or added (and PR referenced)
[ ] New AWS SDK calls or CloudFormation actions have been added to relevant test and service IAM policies
[ ] Any CDK or CloudFormation parameter changes are called out explicitly

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

Closing since already refreshed


Fix phpunit stub file

See changes in Laravel upstream project https://github.com/laravel/laravel/commit/d00fdbcd1b17779e843ba02855eb7974a2106833

Done


Ccp netherlands

No data dictionary was provided for this study, so have inferred from field headings. The layout seems to match pretty well with the CORE data dict so I used that to get the value mappings.

table
valid
total
percentage_valid

subject
122
124
98.387097%

visit
119
124
95.967742%

observation
5495
5510
99.727768%

subject

2: data cannot be validated by any definition

visit

5: data must contain ['visit_id', 'subject_id', 'country_iso3', 'start_date', 'outcome', 'date_outcome'] properties

observation

15: data must be valid exactly by one definition (0 matches found)

2 of the subjects appear to be test/dummy data as they're almost completely blank


Checkbox ADA review

Figma:
https://www.figma.com/file/hWEpxUvJlNV6xy9pVDgxGT/Checkbox?node-id=513-4169
Storybook:
https://9299b7df.saltdesignsystem-storybook.pages.dev/?path=/story/lab-checkbox--checkbox-variations
https://9299b7df.saltdesignsystem-storybook.pages.dev/?path=/story/lab-checkbox--horizontal-group
https://9299b7df.saltdesignsystem-storybook.pages.dev/?path=/story/lab-checkbox--long-text-group

@maj-stella to update the ticket with changes needed

Browser: Chrome Version 109.0.5414.75 (Official Build) (64-bit)
Screen readers: NVDA 2019.2.1 and Jaws 2022
Here are some changes which need to be addressed for Url: https://9299b7df.saltdesignsystem-storybook.pages.dev/iframe?id=lab-checkbox--checkbox-variations&viewMode=story

Please check ‘indeterminate’ word with the Content Design team. Language needs to be clear and simple.
Add some spacing between checkboxes for better readability.
aria-checked is not needed as the native html element is used which already provide this information (please see the screenshot below)
Indeterminate checkboxes which are not disabled, need to have all three states (checked, unchecked, and indeterminate) keyboard accessible. E.g when you press Spacebar it should change the state, cycle through different states. At the moment the indeterminate checkbox is static, a user is not able to change the state by pressing the spacebar. (please see the screenshot below)
Please check with the User research team usability of checking/unchecking error checkboxes.(Please see the screenshot below)

@ImmanuelBaskaran
Urls:
https://9299b7df.saltdesignsystem-storybook.pages.dev/?path=/story/lab-checkbox--horizontal-group
https://9299b7df.saltdesignsystem-storybook.pages.dev/?path=/story/lab-checkbox--long-text-group
Only one little change is needed: aria-checked is not needed as the native html element is used which already provide this information. Please delete aria-checked in <input> elements.

April 11 - dev made changes; nav making some design updates re: ADA, shoudl be done today

@maj-stella
URLs for review:
https://316a45cd.saltdesignsystem-storybook.pages.dev/?path=/story/core-checkbox--default
https://316a45cd.saltdesignsystem-storybook.pages.dev/?path=/story/core-checkbox--indeterminate
https://316a45cd.saltdesignsystem-storybook.pages.dev/?path=/story/core-checkbox--uncontrolled-group

2, 3, and 4 issues raised above have been fixed. Please could you confirm that 1 and 5 have been addressed? Thanks

April 12 - sent new build links for review

@ImmanuelBaskaran
Please could you give me a link to recheck the point 5? In 'Checkbox variations' they stay in an error state if you change the state check/uncheck/partially check. Thanks

@maj-stella, I should have clarified that it would be up to developers using the Checkbox component to implement what I've described earlier. We just provide the functionailty to display this error state.

@ImmanuelBaskaran Awesome! Thank you for clarifying.

@maj-stella
https://885a28ef.saltdesignsystem-storybook.pages.dev/?path=/story/core-checkbox--error
I've made the change to the example anyway.


Fix tests

This adds missing data into cover_art_type table, which have been removed previously.
Thanks to @mwiencek for finding the solution: https://chatlogs.metabrainz.org/brainzbot/metabrainz/2016-11-29/?msg=3748725&page=2.

Thanks :)


PEAR-1808: Fix URL issue for cohort builder

Description
Checklist

[ ] Added proper unit tests
[ ] Left proper TODO messages for any remaining tasks
[ ] Scanned for web accessibility with aXe, and mitigated or documented
flagged issues

Screenshots/Screen Recordings (if Appropriate)
https://github.com/NCI-GDC/gdc-frontend-framework/assets/101295912/cb4b4bb2-19ff-4d43-8f04-a9ee5364fa0a

looks good! 👍


Add Loading UI case study

A case study that shows how a loading UI could be handled centrally for long-running actions. Any feedback is appreciated. 🙏

Hey @sundeepgupta, thanks again for this case study. We're trying to find the right balance of showing off core use cases versus showing everything that is possible in TCA. We think that maybe this one is a little too specific, and is mostly covered by some of the other case studies. So, we are going to close for now, but we really do appreciate the exploration!
Also, if yer interested in creating your own repo with case studies then I think it'd be great to feature it on https://github.com/antranapp/awesome-tca

Makes sense - and thanks for the link, I'll check it out


How does SFTTrainer handle instruction formatted datasets when a tokenizer has no chat_template?

Hi! I am interested in using the SFTTrainer for instruction-tuning. Following the docs, I can see that I can provided examples in the following format to have the trainer format things for me:
{"prompt": "<prompt text>", "completion": "<ideal generated text>"}
{"prompt": "<prompt text>", "completion": "<ideal generated text>"}
{"prompt": "<prompt text>", "completion": "<ideal generated text>"}

The docs also say:

The SFTTrainer will then format the dataset for you using the defined format from the model’s tokenizer with the apply_chat_template method.

My question and confusion is, what does the trainer do if the tokenizer has no chat_template, as is the case with the base llama model?

Hi @JohnGiorgi
Thanks for the issue! Per my understanding if there is no chat template that feature is simply not supported - correct @philschmid ?

TLDR is that if you need to use a chat dataset you need to use a model that supports chat templating - if you want to use that model I think you can clone it and manually add a chat template in that model

Hey @JohnGiorgi,
There are fallback templates in tranformers. If the loaded model/tokenizer is not having a chat_template then transformers fallback to the class-specific template, if there is no class-specific template it falls back to base chat template, which is the chatml format.

Thanks all! I understand now better and agree that it is probably best to explicitly define a template.

#1242 might be interesting for you.


Asynchronous server-side rendering (follow-up of Stackoverflow/Twitter discussion)

This is a follow-up from http://stackoverflow.com/questions/20815423/how-to-render-asynchronously-initialized-components-on-the-server & https://twitter.com/elierotenberg/status/418358101880762368
Practical single-page apps are often rendered on the client asynchronously, usually dynamically issuing ajax requests to load parts of the content. Even on the server side, the full rendering often relies on asynchronous operations following node's non blocking, asynchronous paradigm, e.g. db queries or delegated services implementing a network API (REST or w/e). In addition, if the data/models are exposed via an asynchronous web service (usually ajax, or websockets), asynchronously rendered page can induce significant latency due to network roundtrips, which can be effectively handled by the server (either by ensuring that the server operating the rendering is efficently connected to the data service and/or by maintaining a data cache on the server).
I think the right place to initiate asynchronous loading is in ReactComponent.componentWillMount (since its called when using React.renderComponentToString prior to calling ReactComponent.render while React.componentDidMount isn't). However, React.renderComponentToString and the underlying rendering stack is synchronous; which means there is no simple way (or atleast I couldn't think of one) to perform complete server-side rendering of asynchronously-rendered pages. It might be worked around using a "global" per-request synchronization object containing the promises of the asynchronous operations involved, but I've found it to be tricky at best. Supporting asynchronous rendering would allow practical SPA to be rendered on the server.

bump

This project is not actively maintained. We have no intentions of making further changes beyond super basic maintenance.


Having issues creating a new task with tags

For some reason whenever I create a new task with specified tags, the tags aren't saved into Notion.
Here's the code I'm using. It tasks a string such as "this is the name of the task #tag !high" and correctly parses that it has the tags ["tag"], a priority of ["high"], and a name of "this is the name of the task". However, while Notion is saving the priority and name, but not the tags. Am I doing anything wrong? From what I can tell by reading the docs, this should work.
I've tested this with tags that are already defined in Notion.
import argparse
import sys
from notion.client import NotionClient

parser = argparse.ArgumentParser()
parser.add_argument("query")

args = parser.parse_args()

query = args.query

if(query != ''):
    def extract_meta_data(splitQuery, keyString, options=[]):
        final_list = list(set(part[len(keyString):] for part in splitQuery if (part.startswith(keyString) and (len(options) == 0 or (part[len(keyString):] in options)))))
        for item in final_list:
            splitQuery.remove(keyString + item)
        return final_list

    def get_first_item(array):
        if len(array) != 0:
            return array[0]
        return

    client = NotionClient(token_v2="<token>")
    cv = client.get_collection_view("<collection URL>")

    splitQuery = query.split()

    tags = extract_meta_data(splitQuery, '#')
    priority = get_first_item(extract_meta_data(splitQuery, '!', ['urgent', 'high', 'medium', 'low']))

    row = cv.collection.add_row()
    row.name = ' '.join(splitQuery)
    row.tags = tags
    row.priority = priority

This script is run with this command and args
python3 main.py "this is the name of the task #tag !high"

This is the full source code.

Could you provide any error output you receive when running this?
It would also be helpful if you could provide a Notion template of the table you're using. I think I've replicated it, but it would be helpful to confirm.
I think I've narrowed it down to the fact that the tag doesn't exist in your multi-select. I'm digging through the code to see if it's possible to create a tag via this API wrapper. If not, then that would be the problem and it would need to be implemented in the code.

Could you provide a notion template to test against? Your code works for me with predefined tags.
Also do you receive any error output when running this?


[Bug] 1.0.7 resolution issues?

System Info
System:
OS: macOS 13.3.1
CPU: (10) arm64 Apple M1 Pro
Memory: 351.52 MB / 32.00 GB
Shell: 5.9 - /bin/zsh
Binaries:
Node: 18.16.0 - /usr/local/bin/node
Yarn: 1.22.19 - /opt/homebrew/bin/yarn
npm: 9.6.3 - /opt/homebrew/bin/npm
Watchman: 2<IP_ADDRESS> - /opt/homebrew/bin/watchman
Browsers:
Chrome: 112.0.5615.49
Firefox Developer Edition: 110.0
Safari: 16.4
npmPackages:
@rspack/cli: ^0.1.7 => 0.1.7
@rspack/core: ^0.1.7 => 0.1.7
@rspack/dev-server: ^0.1.7 => 0.1.7
Details
After the 1.0.7 release updating ONLY rspack packages i now get resolution issues with @babel/runtime packages from other npm packages.
Sorry i dont have more details but im pretty flabbergasted
Reproduce link
https://github.com/th3fallen/rspack-bug-sass-include-paths
Reproduce Steps

yarn install
yarn start

Can you provide a minimal reproduction? With this link above I can't yarn at first, it contains some internal net packages, after I remove those packages and yarn successfully, yarn start works fine.

absolutely, i'll get right on that


Fix all deprecation warnings from running mix test with Elixir 1.4.0

I looked at #286 and noticed there are other deprecation warnings from Elixir 1.4. Most are on zero-arity functions, some on unused module attributes, and a few remaining deprecations to use MapSet instead of Set.

Awesome - thanks!! 👍


is continue training work with GPU?

I tested that continue training do work with CPU mode by "xgb_model=bst_last_model".
I have googled all the internet but found no example about continue training with GPU.
Can continue training work with GPU?
the same script work fine with CPU,but with GPU params(gpu_hist),It crashed with error "Check failed: devices.Size() != 0 (0 vs. 0) :"

Will take a look.

@kaixinbuyu Do you still have a reproducible script?


Issue with --driver=none flag in k8s.io/docs/tasks/tools/install-minikube/

This is a Bug Report

Problem:
The documentation for linux says
--driver=none
Proposed Solution:
Correct command is (For Linux)
--vm-driver=none
Page to Update:
https://kubernetes.io/docs/tasks/tools/install-minikube/

Hi @neilghosh
Can you confirm what version of Minikube you're using? Older versions did use the command line option name --vm-driver.

I installed minikube from snap, version says
minikube version: v1.10.1 commit: 63ab801ac27e5742ae442ce36dff7877dcccb278

$ type minikube
minikube is /usr/bin/minikube

$ minikube start --driver=kvm2
😄  minikube v1.10.1 on Ubuntu 19.10
✨  Using the kvm2 driver based on user configuration
💿  Downloading VM boot image ...
    > minikube-v1.10.0.iso.sha256: 65 B / 65 B [-------------] 100.00% ? p/s 0s
    > minikube-v1.10.0.iso: 174.99 MiB / 174.99 MiB [] 100.00% 28.29 MiB p/s 6s
👍  Starting control plane node minikube in cluster minikube
💾  Downloading Kubernetes v1.18.2 preload ...
…

--driver works for me.

@neilghosh Minikube has deprecated --vm-driver=none option. You can now use --driver=none for your current minikube version. If you don't minikube can you please provide exact command line used.

/triage needs-information

Sounds nothing needs a fix. Feel free to reopen if there IS an issue.
/close


arch build instructions slightly out of date now that we can build with python3

ping @AtnNn
not sure what all needs to be updated though
http://rethinkdb.com/docs/install/arch/

At least the ugly python work-around


How can I add start hour next to the title in WEEK VIEW?

How can I add start hour next to the title in WEEK VIEW?
Many thanks!

You need to override this function:
https://github.com/mattlewis92/angular-bootstrap-calendar/blob/master/src/services/calendarEventTitle.js#L22
Something like:
.run((calendarEventTitle, moment) => {
  calendarEventTitle.weekView = event => `${moment(event.startsAt).format('hh:mm')} event.title`;
});


Allow policy dependency_criteria for crates-io crates

Previously this wouldn't be allowed, as the dependency-criteria would be
pulled from the audit edges, rather than from the policy. With these
changes, it will be pulled from both places, with policy
dependency-criteria overriding the criteria specified by all audit and
exemption edges.

cc @bholley I'm not sure if we want to do this yet, but it's a rough implementation (without tests) of the idea we briefly discussed on matrix.


Load kubeconfig from dict

/kind feature
Allow loading of kubeconfig from dictionary
The Kubernetes python client has a function to load kubeconfigs from dict which is quite handy in somecases compared to the kubecfg file. Currently the KServeClient supports only loading from kubeconfig i.e, config.load_kube_config().
I have verified that the KServeClient in the master branch does not have it.

@yuzisun
Let me know if it makes sense. I would be happy to work on adding this functionality.


Attempt to improve CI setup-with-retry time with nix

Would love to see if this is possible. I looked into this also but seemed like although nix is great it wouldn't help too much with cutting down the time. I hope I'm wrong though!

 I hadn't used nix in CI before, but from what I have heard about it(and also expect based on how it works), it works pretty well in terms of speed compared to docker. Unless I'm missing something, I fully think that once I get this actually working, it should pretty easily be under 20 seconds.
The real issue is that I dont know whether nix is a technology that commaai would want to use since, while it is very beautiful and useful in some ways, it can be quite frustrating to work with unless you're super into the technology due to
1. Less than stellar documentation. This is a symptom of the fact that the package repository, nixpkgs, is very decentralized and as such, isn't structured super well

2. A lot of tech debt due to being very old. There are some things about nix that you have to deal with.

If I can figure out a way to do this without forcing commaai to have to switch their entire stack to nix, that would be ideal(and what I'm hoping to do with dream2nix).

I had the exact same thought of nix being able to get it under 20s no problem. They would take it as long as it's not overly complex. My attempt was to use https://github.com/cachix/cachix as it supports the use of it in GHA. It seems like nix would be perfect for this but from going through the docs it didn't come across as a solution to solve it since we'd still have to pull the cached binary (assuming we're using cachix) which wouldn't result in much time being saved, the time to pull an image is the bulk of the build when looking at jobs performed.
But keep in mind this is with my knowledge of nix, I stopped investigating due to seeing it as not a solution for <20s. The docs aren't the greatest (and they're aware of that) so I could've totally missed something that would prove me wrong.
I keep intending to get back to investigating at some point but get sidetracked by other opened issues that catch my interest. If you do get it i would love to learn how


Manual Control

User Story
As a user, i want my SmartCar to be able to have basic controls such as going forward/backward, stopping and steering lef/right
Acceptance criteria:

The car commands are gonna be delivered in a fast and reliable manner.

This was fully implemented  with mqtt and the arrows on the screen in pull request #16 and #12 ,  so it's now closed


Implement zoom stack behaviour

I often do "Fit to View" and return to 100%, but I'd like to return to where I did "Fit to View".
Originally posted by @weed in https://github.com/ArsMasiuk/qvge/issues/58#issuecomment-453798419

partially implemented (50%)


Function calls ignore parameter types when inferring return types

Bug Report
🔎 Search Terms

narrowing return types
parameter types infer narrow

🕗 Version & Regression Information
This is the behavior in every version I tried (3.3.3 through 5.1.6, beta, nightly, etc.), and I reviewed the FAQ for entries about narrowing return types.
⏯ Playground Link
Playground link with relevant code
💻 Code

// Function calls do not infer narrower return types given parameter types

function defaultNull  (v: string | null = null) { return v }
function optional     (v?: string)              { return v }
function union        (v: string | number)      { return v }
function generic<T, K>(v: T | K)                { return v }

let v1 = defaultNull("")             // expected `string` got `string | null`
let v2 = optional("")                // expected `string` got `string | undefined`
let v3 = union("")                   // expected `string` got `string | number`
let v4 = generic<string, number>("") // expected `string` got `string | number`

// Workaround requires overloading to explicitly define param/return type combos

function overload<T>(v: T): T
function overload<T>(v?: T): T | undefined
function overload<T>(v: T) { return v }

let v5 = overload<string>("") // expected `string` got `string`
let v6 = overload<string>()   // expected `string | undefined` got `string | undefined`

🙁 Actual behavior
Function calls ignore parameter types when inferring return types.
🙂 Expected behavior
Calling a function with a narrower type should result in a narrowed return type.

The return type of a non-generic function is inferred from the function body itself, not the callsite.  This is not a bug.  To infer things from the callsite, you need to write a generic function.

The return type of a non-generic function is inferred from the function body itself, not the callsite. This is not a bug.

Thanks. Updated to be a suggestion rather than a bug.

Non-generic functions don't have a relationship between their input and output types; this is what the distinction between generic and non-generic is.

But generics aren't inferring narrower types for optional parameters.

I'm curious why these are the exception. Wouldn't it be better to narrow when possible?


Specify viewer.open(plugins='builtins') for all tests

Description
Just saw some zarr tests failing locally that weren't failing on CI, and narrowed it down to different behavior between our magic_imread and the ome_zarr plugin, which I had recently installed in my env.  So this PR changes all of the viewer.open() calls in our tests to specify plugin='builtins' (which is the assumption in our tests anyway).
as a sidenote: I haven't really looked into why they are behaving differently, but I think it has to do with stacking behavior in our function?  (their plugin added 20 layers and ours added 1).  This sort of thing is inevitable, but just wanted to point it out so people can start thinking about how/whether to eventually address that sort of issue where two plugins handle a similar file quite differently.
Type of change

[x] Bug-fix (non-breaking change which fixes an issue)

How has this been tested?

[x] this makes tests more predictable regardless of environment.
[x] all tests pass with my change

Final checklist:

[x] My PR is the minimum possible work for the desired functionality
[x] I have commented my code, particularly in hard-to-understand areas
[x] I have made corresponding changes to the documentation
[x] I have added tests that prove my fix is effective or that my feature works

Yes they assume TZCYX iirc


pnorm in BDC works only with DC with the same geometrty

Could we subclass BlockDataContainer to create, say,
UniformBlockDataContainer, with elements of same type? Would inherit
everything from BlockDataContainer and then add pnorm, that is now
meaningful since all elements are compatible. This avoids having pnorm
available in general in BlockDataContainer. Possibly also the geometry
attribute would make sense then.
On Wed, 18 Dec 2019, 17:23 Vaggelis Papoutsellis<EMAIL_ADDRESS>wrote:

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/vais-ral/CCPi-Framework/issues/474?email_source=notifications&email_token=ACMDSCEZZCTT54YA4D3TRB3QZJL7LA5CNFSM4J4OMAJ2YY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4IBM6E7Q,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ACMDSCE2MYIPI6AAX5TWJ4LQZJL7LANCNFSM4J4OMAJQ
.

Even if the pnorm is meaningful for a subset of BlockDataContainer I believe we can have it as a method with a test along these lines:

def pnorm(self):
    if check_geometries_equal():
         return pnorm
    else:
        raise TypeError('DataContainers in the block are not uniform, so the pnorm is not meaningful')

On the other hand, I see the benefit of having a geometry for a uniform BlockDataContainer and hence the class UniformBlockDataContainer. However this could also be implemented directly in the BlockDataContainer, which when instatiated would test the equality of the geometries and if all equal, it will save the geometry member in the class, otherwise left to None.
So the previous suggestion would be

def __init__(self, *containers, **kwargs):
    self.geometry = None
    if check_geometries_equal(*containers):
        self.geometry = container.geometry.copy()

def pnorm(self):
    if self.geometry is not None:
         return pnorm
    else:
        raise TypeError('DataContainers in the block are not uniform, so the pnorm is not meaningful')

I liek the second solution and particularly check_geometries_equal and everything will be in one file

see #444 #473 as possible duplicates

see also #1445


Fix bugs for the create_gt_database of kitti

Fix bugs for 'get_item' of BasePoints

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.meng-zha seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account.You have signed the CLA already but the status is still pending? Let us recheck it.

Hi @meng-zha ,
Thanks for your kind contribution. Would you like to sing the CLA thus we could merge this PR?

Hi @meng-zha ,
Thanks for your kind contribution. Would you like to sing the CLA thus we could merge this PR?

Of course.:hugs: I have signed the CLA.


crit/images: fix name conflict with letsencrypt

The core.proto and so.proto files provided by criu have conflicting names with the proto files included in https://github.com/letsencrypt/boulder. Since protobuf v1.26.0 a hard error is reported when a compiled Go program starts up that has multiple conflicting protobuf names linked into it. This pull request fixes this error by prepending the criu- prefix to core.proto and so.proto.
Fixes #94

Codecov Report

Merging #95 (33dde40) into master (74ddb08) will not change coverage.
The diff coverage is n/a.

:exclamation: Current head 33dde40 differs from pull request most recent head 4c1eec1.  Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

Steps to test this patch:
git clone -b go-criu/v6 https://github.com/rst0git/libpod
cd libpod && rm -rf vendor/github.com/checkpoint-restore/go-criu/v6
git clone -b fix-proto-name-conflict https://github.com/rst0git/go-criu/ vendor/github.com/checkpoint-restore/go-criu/v6
make -j `nproc`
sudo make test

@rst0git I do not see the result of your revert. How I understand GitHub all the files still have package criu in them.

How I understand GitHub all the files still have package criu in them.

Thank you Adrian for pointing this out! There was some conflict with the revert changes. I have separated the revert changes in a separate commit to resolve this issue.

@adrianreber PTAL

Just wanted to make sure this is ready before merging. Is it ready?

Just wanted to make sure this is ready before merging. Is it ready?

Yes, the first commit reverts the change introducing the package directive (as suggested in the code review). The second commit renames the conflicting core.proto and so.proto files to enable integration of go-criu with Podman (as we currently don't have a better solution to this problem).
I have tested the changes in this pull request locally (following the steps described above) and can confirm that it should resolve the CI errors we currently see in https://github.com/containers/podman/pull/15591.


Updated SwiftPM and CocoaPods support

As discussed in #62, this PR

fixes the SwiftPM support for iOS
updates the CocoaPods support for macOS and iOS

as there are no source code changes, it is only a minor version bump

thanks!


Feat: Reset button to start swiping again from the beginning

The feature that I am requesting is a reset button that allows the user to start swiping again from the beginning.

this will be a good addition


Unable to install on python 3.11

#218
Issue shall have been fixed.
20e381f commit added gdal<=3.4.3, which when I installed from conda, need python 3.10
Can we use a higher version of gdal?

Hi @siakpeng
The GDAL version is "fixed" to match with the GDAL version installed via gdal-bin in the normal geonode-docker installation.
We can check if is possible to updated it to a newer version.


$location.search() return original $$search object

refer to code in location.js
https://github.com/angular/angular.js/blob/master/src/ng/location.js#L358
I've spent many hours to solve strange behavior of my $routeParams.
And found that one of my function get object from $location.search()
and make some changes to this object
without knowing that it is original object in $location service.
For safety I think it shoud return a copy of $$search instead of the original one.

does anyone not agree with the way this library handles this? I was just caught by it. It seems that $location.search should not be a getter for the in memory search object, but a function that always returns the current representation of window.location.search in obj form. I mean why would anyone need the private $$search object and not the current state of the params? They could be different with this approach.

I wonder if the object could be made immutable. Or at least decent documentation should be added if this doesn't change.
If the object is already available when the method is called I understand why they would return it instead of generating a new one

yeah I think at least an added warning to the docs may be the best bet on this one. The docs do currently say that location.search is a getter/setter method, so arguably they do a good enough job. However, It is surprising to me that it has not affected more users.


[Proposal] Change "unknown_type" → "mixed"

This proposal discusses the motivation and alternatives for replacing "unknown_type" with "mixed" in PHPDoc comments, and establishing a standard for this in future contributions to the Framework.
Motivation
The proposed PSR-5 (PHPDoc) defines unknown or multiple types as the same type: "mixed". Framework defines these as "unknown_type".
I propose we [read: happy to submit pull request(s)] change "unknown_type" to "mixed", for the following reasons:

It is consistent with the proposed PSR. The PSR is based on the industry-standard annotations used in phpDocumentor. These are included/supported in a wide range of syntax highlighters, documentation generators, autocomplete tools and IDEs. There is no widely used competition to this standard.
"mixed" is suggested and understood by popular IDEs (like PHPStorm) and is an actual type name in similar languages (like Hack).
"mixed" is quicker to type, and fewer characters also reduces the amount of artificial whitespace used in alignment of parameters [in PHPDoc comments].

Alternatives
In instances where the type is 1 in a limited set; "unknown_type" can be replaced with a set multiple types:
$fileOrID can be File or int, therefore:
@param unknown_type $fileOrID → @param File|int $fileOrID
In instances where the type is 1 of a limited set; multiple types can be combined into [artificial] sum types:
$fileOrID can be File or int, therefore:
@param unknown_type $fileOrID → @param FileOrID $fileOrID where FileOrID is:
class FileOrID
{
    /**
     * @var null|File
     */
    protected $file;

    /**
     * @var null|int
     */
    protected $id;

    /**
     * @return bool
     */
    public function isFile()
    {
        return $this->file !== null;
    }

    /**
     * @return null|File
     */
    public function getFile()
    {
        return $this->file;
    }

    /**
     * @return bool
     */
    public function isID()
    {
        return $this->id !== null;
    }

    /**
     * @return null|int
     */
    public function getID()
    {
        return $this->id;
    }

    /**
     * @param null|File $file
     * @param null|int  $id
     */
    public function __construct(File $file = null, $id = null)
    {
        if ($file === null and $id === null) {
            throw new InvalidArgumentException(
                "Either file or ID must contain a value"
            );
        }

        if ($id !== null and !is_numeric($id)) {
            throw new InvalidArgumentException(
                "ID must be numeric"
            );
        }

        $this->file = $file;
        $this->id = $id;
    }
}

Throwing my support in for this, I've previously done some generous documentation fixes though I stopped because they're not usually responded to promptly. I'm happy to do a lot more if it can be agreed on as a priority (a lot of documentation in SS is great, but some is very bad -- eg Requirements).
I would suggest that using null in the list of types is not as necessary unless it indicates a functional state for that variable. For instance, this class won't even instantiate with a null $file or $id, so null will never be a functional state for any of these variables, therefore they and their getters need not be documented as such.

+1. Thanks @nikrolls for your PR's. Will just rebase those and get them merged in. Any improvement in docs is welcome :)

After watching this (fun!) https://www.youtube.com/watch?v=hI3U6VbUIgc
I agree the better option is a constrained list of types: null|string vs mixed. Both are valid, but the first is more useful for static analysis. An IDE will be able to tell that the int you are trying to use, as a function parameter, is invalid; unless the hint is mixed.

+1 for null|String

Where are we at with this?

unknown_type has been removed; Code now uses mixed where type is unknown. I guess it can be closed!


Issue 494- Storage hint definition to support map type

This PR addresses issue #494.  It introduces the concept of a "storage hint" that can be applied to a model or property definition to give storage and transmission systems additional hints on how to efficiently handle the data, without changing the semantic meaning of the underlying property.
The initial use of this is to support storage of "map-like" data in XDM.  This support is described in the docs.

@cmathis, @harleensahni, @lrosenthol, @ogoldman please take a look.  This proposal is based on the conversation on the initial design given by @cmathis, modified based on a conversation I had with @lrosenthol and @ogoldman earlier this week.

Doesn't the meta:xdmType = map already tell you it should be treated as a map?
For example:
properties: {
"mapField": {
"type":"object",
"meta:xdmType": "map",
"additionalProperties": {
"type":"string"
}
}
}
If a customer sends data in the form of JSON it would look like:
mapField: {key1:value1, key2:value2, key3:value3}
The consumer can see that mapField should be interpreted as a Map and store all the key/value pairs that way.
The other way this could be stored is as a struct which is more of a traditional object. In this case could we continue using the meta:xdmType (which everyone is looking for) and instead have meta:xdmType = object to imply this data should be stored as a dynamically growing struct/object?

Hey @cmathis, after speaking with @lrosenthol, @ogoldman a couple of concerns were raised with that approach:

We have discussed the "xdmType" concept for scalar fields, but this is first time we have tried to apply it to an object.  There is a concern that we are opening the door for allowing semantic details to be defined via "xdmType" that really should be defined using actual schema definitions.  I agree that this creates a gray area: what is a type, versus what is a schema?  For example, why is a "measure"  a schema and not a type?

It was observed that the representation we proposed for map is semantically equivalent to a JSON object (which is also a map).  We are not defining new semantics for the type, simply giving an explicit signal that the keyspace is unconstrained and should be stored appropriately.

It was observed that so far the "map" concept is the only modifier we have for objects, so it might make sense to solve for the specific case, versus more generally opening up the type mechanism.

So what is the xdmType for a field defined as:
properties: {
    "mapField": {
         "type":"object",
         "meta:storageHint": "xdm:storeAsMap"
         "additionalProperties": {
              "type":"string"
         }
     }
}

There isn't one @cmathis - that's the point.  We don't want to use meta:xdmType on an object, bcause of the concerns raised above.  All objects are either a defined XDM schema or an arbitrary map of properties.

So let's say I have an XDM schema like this:
properties: {
   field1: {
        type: object,
        properties: {
            subField1: {
                type: string
            },
            subField2: {
                type: integer
            }
       }
   },
   field2: {
        type: object,
        additionalProperties: {
            type: string
        }
   },
   field3: {
       type: integer,
       minimum: -128,
       maximum: 128,
       meta:xdmType: byte,
  }
}

If I'm trying to map this schema into a parquet schema, how do I know that field1 should be a struct, but field2 should be a map? I'm assuming this is where the meta:storageHint comes in, but now we have two ways to identify specific types. In the case of field3 I look at the meta:xdmType, but now your asking the user to know about this meta:storageHint as well. We need to be consistent one way or the other.
From the registry we use to not have an xdmType for the JSON schema type:array and type:object fields and that resulted in tickets which users flagged as a bug and demanded that every field have an xdmType. I cannot surface fields that do not have explicit data types that are exposed the same way across all fields.

The way you know what should be treated as a struct vs. a map is meta:storageHint - that's exactly what it is for (and why it is named that way).  Nothing more (or less).
meta:xdmType serves a completely different purpose.

xdmType was proposed as a way to provide something equivalent to JSON-LD's @type on an entry in a JSON schema - meaning that you want to give it some rich semantic meaning defined in some other standard.  date is a good example, in that we could (theoretically) get rid of it and just use a type:string + xdmType::xsd:date.  The current 'real' example is BigNumber.

We are being 100% consistent.
meta:storageHint is what the name implies - a hint to a storage system (eg. parquet) about how it should store it - columns or not.  It has nothing to do with the type of data.
meta:xdmType on the other hand is also what the name implies - the actual "rich" type of the scalar field to address providing those rich/extended type semantics.

I'm with @cmathis on this one: call it storageHint, and use it consistently, instead of xdmType. (Otherwise, we're not really using the JSON Schema type system; we're using two type systems at once. In that case we may as well introduce a map type. But I fear this will be endlessly complicated to maintain.)

@cmathis is there something we can do with the naming of the two keys which might help you?

@ogoldman The (known) problem with the JSON Schema typing model is that it is limited and the JSON-LD community is solving it the wrong way (IMO) via the @type key in the JSON data....but we want that information in the schema.  As such, we have to define our own method - in this case meta:xdmType.  As long as we are consistent, I don't see the problem.

@lrosenthol  - This may be one of those areas where we pull in Product Management or some of the end users (individuals from Vasanthi Holtcamp's data on-boarding team) to get their opinion. When we started talking about Map support in XDM, I assumed it would be in the form of an xdmType=map. I may be the only one that thought this way. Would be interesting to see how PM was planning to define a map field in the UI editor and if they planned on adding a Map type next to the existing Integer, Long, Double, etc.
This may be a separate discussion, but as @ogoldman mentioned the xdmType has introduced a second type system which has been a pain. As you know on the XC side users are expecting an XDM schema to be translatable into Postgress tables, Parquet, CosmoDB, Java objects, you name it. This is what demanded the creation of a richer set of data types (xdmType), but it's not an intuitive process for users trying to define these types in JSON schema. According to the documentation (https://wiki.corp.adobe.com/pages/viewpage.action?spaceKey=DMSArchitecture&title=XDM+Architecture#XDMArchitecture-XDMDataTypes) XDM supports long, date, short, integer, etc.  I'm constantly responding to Jira tickets that say "I tried to define a schema with "type":"long" and the registry API throws an error" (which it does because its not valid JSON schema).  The same happens from users of the UI who define a field of type "Long" who then write up bugs because the schema ended up with a "type":"integer" (the UI translates into a JSON schema equivalent). We are trying to battle the problem with documentation, but I feel like it's a never ending pain point. The registry today injects a meta:xdmType on every field to avoid some of the confusion and many of the components have switched to looking at it rather then the type attribute. Even if we dropped meta:xdmType and transitioned to every field having a meta:storageHint it still becomes another type system as the basic JSON schema type will never be sufficient for the XC needs.

Can we circle back on why meta:xdmType is insufficient? It's currently metadata that makes it easy to understand what is being implied by the JSON Schema constraints on a field.
It seems like a natural fit for map fields as it would still be metadata that made it easy to understand what was implied by the additionalProperties structure in an object field. While we have no non-scalar analogs at the moment I would expect that if we wanted to define further complex object types that we would take the same approach in the future. I don't understand why we need to add the complexity of a new meta property in this instance.

I definitely feel that we need to keep the definition of "meta:xdmType" for scalar properties.  As @lrosenthol observed, that tag is intended on giving clear and specific semantics to the JSON types, where the JSON type system is too broadly defined compared to the type systems we interop with.  Those definitions are type definitions, in the same way that the JSON types are, although they are carefully defined to also be fully compatible with the underlying JSON types.
For me, the only question is whether a "map" is really a new type, or is just a modifier on the object type.  This PR says the later: maps are still objects, but with an unconstrained keyset which may be desirable to store differently than a regular object.  But we could also go with the other interpretation, that map is a type distinct from object, in which case we would include it directly in "xdmType".

@lrosenthol  - I'm not sure what you mean by oddity number 1. Arrays in XDM are defined as a fields with  type:array and have a meta:xdmType:array.
Yes, because we are using JSON schema to represent richer data types we are going to need a documentation no matter what we do. Users need to know that sometimes a raw type:string may end up with an xdmType:date (because of theformat attribute supplied) . Same thing for why a raw field defined as type:integer may end up with an xdmType of byte, long, etc. (because of the min/max attributes). This whole discussion is if we apply a similar translation process (based on the translation of the other attributes) and allow fields with type:object to end up with an xdmType:map,
Anyone apposed to me posting a poll in the #xdm-questions channel to see what the broader audience would expect to see?

Just spoke with @kstreeter a little about this. If we go the route of using the xdmType for defining richer scaler types only, then every consumer of XDM schemas (ETL connectors, Data Ingestion, Unified Profile, Campaign, etc.) that need to map the fields to a storage format will need to do the following:
if (xdmType) use xdmType
else if (storageHint) use storageHint
else use type

You basically have three locations to check now. If everyone feels like this is the best way to go then so be it, but let's please send this out as a formal announcement to all platform users so they are aware of this requirement that they must add to their code. We will need to go and update the ETL vendor documentation as well. This needs to be published as the formal way to find the storage format (some would say actual data type) so I do not get tickets against the registry saying that every field is suppose to have an xdmType which is the way it's been.

@cmathis, @kstreeter, @lrosenthol -> I agree with the PR as it stands.
Just catching up on this. The salient question to me after reading the thread is do we decide to:
a) follow correct theoretical design principles that will be lost on many users of the system, or
b) optimize for simplicity and place the property in a location that on first consideration seems like a logical place to put it.
My perspective is that we need to adhere consistently to the the best technical design (a). Intermingling schema definition with value formats is wrong.
Usability is important but this will just make people who understand JSON-Schema/JSON-LD feel that they cannot trust their natural understanding of XDM.
Usability will have to be delivered by helpful UX and for APIs effective validation with complete error messaging.
@cfraser - to your comment about what will we then do if/when we have other non-scalar types. The pattern for when we have a concrete new complex type is to externalize it as its own schema file for inclusion, via an $ref. I am hopeful we will both see constrained usage of the map feature, as it should never be used to avoid defining real schema and that we don't have other cases like this coming up.

Catching up on this as well and a few comments:

Similar to @cmathis I would vote for leveraging xdmType rather than creating yet another syntax/construct that we need to manage (ie. storageHint)
A Map is a dataType and is distinct from a Struct in that it supports arbitrary key->value mappings that are not known ahead of time.  This semantic is expressed in JSON Schema through the use of additionalProperties. To that extent we could detect whether a field needs to be stored as Map or Struct purely based on whether the JSON Schema allows for additionalProperties.
JSON supports both Maps and Structs with a more general "object" type. However, the type distinction is valid in language bindings (e.g. Java/Scala) and frameworks such as Spark.  The choice in  how these types are stored impacts how the related data is queried.  For Example: Maps can be accessed using an indexed syntax:
myDataFrame.selectExpr("tags['key']")
or keys convered to columns with:
myDataFrame.select("explode(tags)")
Point is we are not just talking about how the data is spread out on disk, but also the contract by which clients can interact with that data.

Arrays in XDM are defined as a fields with type:array and have a meta:xdmType:array.

@cmathis That is incorrect.  xdmType is only used when you are specifying something other (or more specifically, additional) to the actual type.  As such, you should never have the construct above.  If there is software currently generating such or existing schemas with that - they need to be fixed.

Since I seem to be outnumbered here, I am willing to concede on using xdmType for doing map on objects - provided that it is the only allowed value on objects and that we continue to not allow it for arrays.


Possible issues to work on

Description of Problem:
I open this issue to comment possible issues from original repository rasa that we could work on.
Overview of the Solution:
List many possible issues on commentaries.

Possible issues encountered by @ErickGiffoni

Rasa 7956: macOS related
Rasa 5657
Contributors 15
Contributors 17
Rasa 7250

Rasa 7401

Hey, I'm taking Rasa #7956 and I'll open a pull request soon.

Hey, I'm taking Rasa RasaHQ#7956 and I'll open a pull request soon.

Done !
https://github.com/RasaHQ/rasa/pull/9296

Issues done:

Rasa 7956: macOS related -> Done by @ErickGiffoni , pull request here

Contributors 17: NLU training -> Done by @juliolitwin, pull request here


AWS scheduled stop with do-not-disrupt pod

Description
Observed Behavior:
We have statefulset running on c5d instance. It has karpenter.sh/do-not-disrupt: "true" annotation. Instance where it runs is supposed to be turned off by AWS in 11 days from now (instance-stop event).
It seems that when karpenter saw this it began deleting the instance with CordonAndDrain action. That seems to have killed the pod (new one created at "2024-09-13T17:20:16Z"). That itself is strange because the CordonAndDrain event happened  at 17:41:25 (why 21 minutes later?)
Timeline (UTC):

7:20:16 pm - new statefulset pod
7:41:25.295 pm - initiating delete from interruption message
7:42:21.358 pm - created nodeclaim
7:42:23.359 pm - launched nodeclaim
7:42:56.454 pm - registered nodeclaim
7:43:19.523 pm - initialized nodeclaim

I understand this event cannot be avoided so honoring the do-not-disrupt might not be needed however what is strange now is the current status which is definitely not expected.
4 nodes (22471m/31640m) 71.0% cpu ████████████████████████████░░░░░░░░░░░░ $1.536/hour | $1,121.280/month
1,203 pods (37 pending 1,166 running 1,203 bound)

ip-10-67-41-241.us-west-2.compute.internal cpu ████████████████████████████████░░░  91% (10 pods) c5d.2xlarge/$0.3840 On-Demand -        Ready rabbitmq 74d
ip-10-67-18-152.us-west-2.compute.internal cpu ████████████████████████████████░░░  91% (10 pods) c5d.2xlarge/$0.3840 On-Demand -        Ready rabbitmq 74d
ip-10-67-83-223.us-west-2.compute.internal cpu ████████████████████████████████░░░  91% (10 pods) c5d.2xlarge/$0.3840 On-Demand Deleting Ready rabbitmq 74d
ip-10-67-92-31.us-west-2.compute.internal  cpu ████░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░  10% (9 pods)  c5d.2xlarge/$0.3840 On-Demand -        Ready rabbitmq 2d19h

What happenes seems to be that the new pod scheduled on the old node. This probably blocked the deletion. And while the new node is saying it is nominated for pending pod and it is not getting deleted and hangs around empty
Old node taints - karpenter taint is there so I don't know why the new pod still scheduled.
Taints:             dedicated=rabbitmq:NoSchedule
                    karpenter.sh/disrupted:NoSchedule

Events:
  Type    Reason             Age                 From       Message
  ----    ------             ----                ----       -------
  Normal  DisruptionBlocked  95s (x30 over 62m)  karpenter  Cannot disrupt Node: state node is nominated for a pending pod

Expected Behavior:

Should Karpenter wait for the actual instance-stop event and emit metrics so we can alert on this? If this would be labeled by nodepool it would be great so I can filter alerts only for interesting nodepools.
If not and it will just kill the pod, I would expect the new pod to end up on the new node.

Reproduction Steps (Please include YAML):
Versions:

Chart Version: 1.0.2
Kubernetes Version (kubectl version): 1.29

Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
Please do not leave "+1" or "me too" comments, they generate extra noise for issue followers and do not help prioritize the request
If you are interested in working on this issue or have submitted a pull request, please leave a comment

Can you show the logs of when Karpenter detected and consumed the event from the interruption queue? It seems odd to me that the instance/node would be deleted 11 days prior to its actual stoppage. Do you also have the stoppage event?

I have only info logs but this is the log message. I removed tags from the message.
{
	"id": "AgAAAZHsebavxXYuzAAAAAAAAAAYAAAAAEFaSHNlY0UwQUFETGw1ek56T3E3TVFBQQAAACQAAAAAMDE5MWVjOGEtYjhmZC00YjlhLWE4ZjQtYmU2MTk2OWMxM2Ex",
	"content": {
		"timestamp": "2024-09-13T17:41:25.295Z",
		"tags": [
<redacted>
		],
		"host": "i-0c9fc3bbd44946e55",
		"service": "karpenter",
		"message": "initiating delete from interruption message",
		"attributes": {
			"dd": {
				"service": "karpenter"
			},
			"controller": "interruption",
			"k8s_namespace": "kube-system",
			"level": "INFO",
			"logger": "controller",
			"Node": {
				"name": "ip-10-67-83-223.us-west-2.compute.internal"
			},
			"commit": "b897114",
			"messageKind": "scheduled_change",
			"reconcileID": "60ac6ee0-d5e9-4187-afa0-d27dad135411",
			"namespace": "",
			"name": "",
			"action": "CordonAndDrain",
			"time": "2024-09-13T17:41:24.298Z",
			"NodeClaim": {
				"name": "rabbitmq-b7sdk"
			},
			"queue": "app1d-karpenter"
		}
	}
}

I think I might have found the event in Datadog. We have it with source amazon_ec2 so it might be it or Datadog got it from some other place
{
	"id": "AgAAAZHsetaYX9mjzAAAAAAAAAAYAAAAAEFaSHNldUVMQUFBcXR5c29lYjJPU2hBQQAAACQAAAAAMDE5MWVjN2MtNWI4NC00YTQxLTliMGQtNTJiY2Y4OGQxMzVm",
	"content": {
		"timestamp": "2024-09-13T17:42:39Z",
		"tags": [
			"source:amazon_ec2",
			"kube_node:ip-10-67-83-223.us-west-2.compute.internal",
			"kernel:none",
			"karpenter.sh/nodeclaim:rabbitmq-b7sdk",
			"aws_ec2launchtemplate_version:1",
			"eks_eks-cluster-name:app1d",
			"karpenter.sh/nodepool:rabbitmq",
			"outreach_data-classification:high",
			"kube_cluster_name:app1d",
			"security-group:sg-0ad0e1ea39737eff0",
			"instance-type:c5d.2xlarge",
			"outreach_bento:app1d",
			"outreach_team:fnd-qss",
			"cluster_name:app1d",
			"env:production",
			"host:i-07c6f88c9383a3936",
			"karpenter.sh/managed-by:app1d",
			"outreach_cluster-state:ready",
			"aws_eks_cluster-name:app1d",
			"karpenter.sh/discovery:app1d",
			"account:182192988802",
			"instance-stop",
			"karpenter.k8s.aws/ec2nodeclass:rabbitmq",
			"aws_account:182192988802",
			"iam_profile:app1d_4882949009964683380",
			"aws_ec2_fleet-id:fleet-381ca0ae-d12f-641e-2e92-2f88428fe9bf",
			"kubernetescluster:app1d.us-west-2.aws.outreach.cloud",
			"cloud_provider:aws",
			"outreach_environment:production",
			"kubernetes.io/cluster/app1d:owned",
			"image:ami-09d255723d286588a",
			"outreach_application:rabbitmq",
			"outreach_personal-information:yes",
			"image:golden-image-eks-1.29-al2023-785",
			"region:us-west-2",
			"aws_ec2launchtemplate_id:lt-084461d8aaecf8ad9",
			"outreach.io/nodepool:rabbitmq",
			"availability-zone:us-west-2c",
			"maintenance",
			"outreach_tier:tier-0",
			"name:app1d-rabbitmq"
		],
		"host": "ip-10-67-83-223.us-west-2.compute.internal-app1d",
		"service": "undefined",
		"message": "%%%\nThe instance is running on degraded hardware\n\ninstance-stop will automatically happen after 2024-09-27 18:00:00 if not manually run before. [aws guide](http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/monitoring-instances-status-check_sched.html#schedevents_actions)\n%%%",
		"attributes": {
			"evt": {
				"id": "7750847193401411082",
				"source_id": 88,
				"type": "status"
			},
			"hostname": "i-07c6f88c9383a3936",
			"service": "undefined",
			"priority": "normal",
			"title": "Upcoming AWS maintenance event instance-stop on instance i-07c6f88c9383a3936",
			"timestamp":<PHONE_NUMBER>000,
			"status": "info"
		}
	}
}

And this we have in datadog from amazon_health
{
	"id": "AgAAAZHseanQ1LzFsQAAAAAAAAAYAAAAAEFaSHNnSjhRQUFELWZudnVwSEFXcGNvdAAAACQAAAAAMDE5MWVjN2MtZmQ1Zi00MDVjLTg5NDQtMjAxZGUyN2FlMDQy",
	"content": {
		"timestamp": "2024-09-13T17:41:22Z",
		"tags": [
	<redacted>
		],
		"host": "ip-10-67-83-223.us-west-2.compute.internal-app1d",
		"service": "ec2",
		"message": "%%%\nDescription: \n```\n\"EC2 has detected degradation of the underlying hardware hosting your Amazon EC2 instance associated with this event in the us-west-2 region. Due to this degradation your instance could already be unreachable. We will stop your instance after 2024-09-27 18:00:00 UTC. Please take appropriate action before this time. You can find more information about retirement events scheduled for your EC2 instances in the AWS Management Console https://console.aws.amazon.com/ec2/v2/home?region=us-west-2#Events * What will happen to my instance? Your instance will be stopped after the specified retirement date. You can start it again at any time after it s stopped. Any data on local instance-store volumes will be lost when the instance is stopped or terminated. * What do I need to do? We recommend that you stop and start the instance which will migrate the instance to a new host. Please note that any data on your local instance-store volumes will not be preserved when you stop and start your instance. For more information about stopping and starting your instance, and what to expect when your instance is stopped, such as the effect on public, private and Elastic IP addresses associated with your instance, see Stop and Start Your Instance in the EC2 User Guide (https://docs.aws.amazon.com/en_us/AWSEC2/latest/UserGuide/Stop_Start.html). However, if you do not need this instance, you can stop it at any time yourself or wait for EC2 to stop it after the retirement date. * Why is EC2 retiring my instance? EC2 may schedule instances for retirement in cases where there is an unrecoverable issue with the underlying hardware. For more information about scheduled retirement events please see the EC2 user guide (https://docs.aws.amazon.com/en_us/AWSEC2/latest/UserGuide/instance-retirement.html). If you have questions or issues, contact AWS Support at: https://aws.amazon.com/support .\"\n```\n\n\nAffected Entities: \n```\n[\n    {\n        \"entityArn\": \"arn:aws:health:us-west-2:182192988802:entity/g1pf6QbeUGUTonkitSbPFG_dx5RL4w0SWzP-b_WKq6djY=1g\",\n        \"eventArn\": \"arn:aws:health:us-west-2::event/EC2/AWS_EC2_PERSISTENT_INSTANCE_RETIREMENT_SCHEDULED/AWS_EC2_PERSISTENT_INSTANCE_RETIREMENT_SCHEDULED_4f62b4a3-18ef-4c1c-b87d-b2303fec0174\",\n        \"entityValue\": \"i-07c6f88c9383a3936\",\n        \"awsAccountId\": \"182192988802\",\n        \"lastUpdatedTime\": \"2024-09-13T17:41:22.601000+00:00\",\n        \"statusCode\": \"IMPAIRED\"\n    }\n]\n```\n\n\nEvent start time : 2024-09-27 18:00:00 UTC\nEvent end time : 2024-09-27 18:00:00 UTC\n\n%%%",
		"attributes": {
			"aggregation_key": "arn:aws:health:us-west-2::event/EC2/AWS_EC2_PERSISTENT_INSTANCE_RETIREMENT_SCHEDULED/AWS_EC2_PERS...",
			"evt": {
				"id": "7750853545852686014",
				"source_id": 201,
				"type": "api"
			},
			"hostname": "i-07c6f88c9383a3936",
			"service": "ec2",
			"priority": "normal",
			"title": "AWS_EC2_PERSISTENT_INSTANCE_RETIREMENT_SCHEDULED --- upcoming",
			"event_object": "arn:aws:health:us-west-2::event/EC2/AWS_EC2_PERSISTENT_INSTANCE_RETIREMENT_SCHEDULED/AWS_EC2_PERS...",
			"timestamp":<PHONE_NUMBER>000,
			"status": "info"
		}
	}
}

The node was tainted
{
	"id": "AgAAAZHsebavxXYuzQAAAAAAAAAYAAAAAEFaSHNlY0UwQUFETGw1ek56T3E3TVFBQgAAACQAAAAAMDE5MWVjOGEtYjhmZC00YjlhLWE4ZjQtYmU2MTk2OWMxM2Ex",
	"content": {
		"timestamp": "2024-09-13T17:41:25.295Z",
		"tags": [
<redacted>
		],
		"host": "i-0c9fc3bbd44946e55",
		"service": "karpenter",
		"message": "tainted node",
		"attributes": {
			"dd": {
				"service": "karpenter"
			},
			"controller": "node.termination",
			"k8s_namespace": "kube-system",
			"level": "INFO",
			"logger": "controller",
			"Node": {
				"name": "ip-10-67-83-223.us-west-2.compute.internal"
			},
			"commit": "b897114",
			"reconcileID": "cc4d8735-b018-40f3-8a48-c44e21a01897",
			"taint": {
				"Value": "",
				"Effect": "NoSchedule",
				"Key": "karpenter.sh/disrupted"
			},
			"namespace": "",
			"name": "ip-10-67-83-223.us-west-2.compute.internal",
			"controllerGroup": "",
			"time": "2024-09-13T17:41:24.331Z",
			"controllerKind": "Node"
		}
	}
}

And karpenter found the provisionable pod from this node
{
	"id": "AgAAAZHsepGuvO9T_gAAAAAAAAAYAAAAAEFaSHNlcGd5QUFCenZvNUVNNmMyM3dBQQAAACQAAAAAMDE5MWVjOGEtYjhmZC00YjlhLWE4ZjQtYmU2MTk2OWMxM2Ex",
	"content": {
		"timestamp": "2024-09-13T17:42:21.358Z",
		"tags": [
<redacted>
		],
		"host": "i-0c9fc3bbd44946e55",
		"service": "karpenter",
		"message": "found provisionable pod(s)",
		"attributes": {
			"duration": "193.032533ms",
			"dd": {
				"service": "karpenter"
			},
			"controller": "provisioner",
			"k8s_namespace": "kube-system",
			"level": "INFO",
			"logger": "controller",
			"commit": "b897114",
			"namespace": "",
			"name": "",
			"Pods": "rabbitmq--app1d/rabbitmq-0",
			"time": "2024-09-13T17:42:21.052Z",
			"reconcileID": "839a738f-4d2c-4180-9bac-47cba50e3b6a"
		}
	}
}

Then it created new nodeclaim but I think the biggest problem is that the pod actually was not rescheduled to new node (although it was deleted) but it ended up on this exact node again. Is it possible the taint was not there yet?


Consider "borrowing" all of Penumbra's work on testnet deployments

main dir: https://github.com/penumbra-zone/penumbra/tree/main/deployments
smoke test: https://github.com/penumbra-zone/penumbra/blob/main/deployments/scripts/smoke-test.sh
testnets: https://github.com/penumbra-zone/penumbra/tree/main/testnets

File where testnet data is generated
https://github.com/penumbra-zone/penumbra/blob/main/crates/bin/pd/src/testnet/generate.rs

closing due to staleness


Color file.

The repo is missing the color file.

The repo is missing the color file.

Hi, it's right there https://github.com/vaniacer/bash_color


Fix get_fee_rate_statics param

close #83

@quake I think this PR is ready for merge.

there is a CI error:
Caused by:
  package `cargo-deny v0.14.0` cannot be built because it requires rustc 1.70.0 or newer, while the currently active rustc version is 1.67.1

could you help to fix it?

@quake Could you please re-trigger the CI action so I can verify that my fix works?

    tests::ckb_indexer_rpc::test_get_indexer_tip failed, fixing...


e2e test framework

To start with functionality test mentioned here

Here's how I would go about this:

Understand the concept of Kubernetes really well, including the idea of Custom Resource Definitions (CRDs)
Understand the functionality of Numaplane well through manual testing
Understand how the e2e test that Dillen wrote for the original Numaplane works. Some of this can probably be reused. His test verifies that end to end works from git all the way to resources being applied. Your test will need to verify that resources get applied, but through the creation of Rollout CRs.
Understand the stretchr/testify suite framework
Come up with and document a high level design for your test framework before coding


Invalid unlock block

Bug description
It can happen that a transaction is signed with the wrong ledger seed, we should verify the signature before sending it, since we know the input addresses we can do this locally without additional API requests

Done here https://github.com/Thoralf-M/wallet-core/commit/443cc6a92a1552183f71b2a89dbc2cc0ca6dcace


fix(uri): make uri attribute public #24

Alaska Airlines Pull Request
Please include a summary of the change and which issue is fixed. Please also include relevant motivation and context. List any dependencies that are required for this change.
Fixes: #24
Summary:
Makes the existing uri attribute public. This is done to allow for changing from the default use of unpkg when it goes down.
Type of change:
Please delete options that are not relevant.

[x] New capability
[ ] Revision of an existing capability
[ ] Infrastructure change (automation, etc.)
[ ] Other (please elaborate)

Checklist:

[x] My update follows the CONTRIBUTING guidelines of this project
[x] I have performed a self-review of my own update

By submitting this Pull Request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
Pull Requests will be evaluated by their quality of update and whether it is consistent with the goals and values of this project. Any submission is to be considered a conversation between the submitter and the maintainers of this project and may require changes to your submission.
Thank you for your submission!
-- Auro Design System Team

:tada: This PR is included in version 3.4.0 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


fix(strip): Transform static class fields to assignments

Fixes #1483.
Also ensures that every test applies the decorator() pass before strip(). This is necessary now, and it makes sense because there shouldn't be decorators in JS.

@kdy1 Any idea what causes this error?

@nayeemrmn I don't have one, but I now have some time to investigate it. I'll fix it and then merge it.


fix(quantic): fixed validation bug with timeframe facet

Introduced a bug in the previous PR. This is the correct fix. It's very nice to have the tests to validate this now 😛

Introduced a bug in the previous PR. This is the correct fix. It's very nice to have the tests to validate this now 😛

I think the fix for numeric facet, no?


Remove macOS bug due to bug in GA plugin

macOS builds always fail due to bug in GA plugin.

Let us rather switch to https://github.com/marketplace/actions/publish-test-results


classifier-free guidance

Have you done any experiments that a classifier free guidance can a bring improvement?

We have tried using classifier free guidance during training. However, we haven't observed significant improvements. I think further exploration is needed.


Scope node cannot find the node in the cluster. Chaosblade-operator 1.7.0

Issue Description
Type: bug report
Describe what happened (or what feature you want)
Chaosblade-operator version 1.7.0. I installed the new version on my k8s cluster and did a few tests with node scope and pod scope. With Pod scope, everything works fine but when I chose node scope, it cannot find the node. Specific error: "error": "invalid parameter node-10-120-127-171, can not find node". It works on 1.6.0
Yaml file:
apiVersion: chaosblade.io/v1alpha1
kind: ChaosBlade
metadata:
name: cpu-load
spec:
experiments:

scope: node
target: cpu
action: fullload
desc: "increase node cpu load by names"
matchers:

name: names
value: ["node-10-120-127-171"]
name: cpu-percent
value: ["80"]

Result:
{
"apiVersion": "chaosblade.io/v1alpha1",
"kind": "ChaosBlade",
"metadata": {
"annotations": {
"kubectl.kubernetes.io/last-applied-configuration": "{"apiVersion":"chaosblade.io/v1alpha1","kind":"ChaosBlade","metadata":{"annotations":{},"name":"cpu-load"},"spec":{"experiments":[{"action":"fullload","desc":"increase node cpu load by names","matchers":[{"name":"names","value":["node-10-120-127-171"]},{"name":"cpu-percent","value":["80"]}],"scope":"node","target":"cpu"}]}}\n"
},
"creationTimestamp": "2022-10-18T13:07:40Z",
"finalizers": [
"finalizer.chaosblade.io"
],
"generation": 1,
"name": "cpu-load",
"resourceVersion": "2113551",
"uid": "81785a22-8631-4a0d-8b61-d1168714ba9d"
},
"spec": {
"experiments": [
{
"action": "fullload",
"desc": "increase node cpu load by names",
"matchers": [
{
"name": "names",
"value": [
"node-10-120-127-171"
]
},
{
"name": "cpu-percent",
"value": [
"80"
]
}
],
"scope": "node",
"target": "cpu"
}
]
},
"status": {
"expStatuses": [
{
"action": "fullload",
"error": "invalid parameter node-10-120-127-171, can not find node",
"scope": "node",
"state": "Error",
"success": false,
"target": "cpu"
}
],
"phase": "Error"
}
}
Describe what you expected to happen
Expected to work as in 1.6.0. It's supposed to find the node in the cluster. The node cpu load should increase.
How to reproduce it (as minimally and precisely as possible)

Install chaosblade-operator 1.7.0
Create a chaos test with node scope and apply the yaml to the cluster
Check the result.

Tell us your environment
Kubernetes 1.21.14
Distributor ID: Ubuntu
Description:    Ubuntu 18.04.5 LTS
Release:        18.04
Codename:       bionic
kubectl get nodes
NAME                  STATUS   ROLES       AGE     VERSION
node-10-120-127-170   Ready    edge,node   3d17h   v1.21.14
node-10-120-127-171   Ready    edge,node   3d17h   v1.21.14
node-10-120-127-172   Ready    node        3d17h   v1.21.14
node-10-120-127-173   Ready    node        3d17h   v1.21.14
Anything else we need to know?

I also have this issue in 1.23.6 k8s cluster with chaosblade-operator 1.7.0
use yaml file, got response:
error: invalid parameter node-10-120-127-136, can not find node
and use cli tool also has this error:
blade create k8s node-cpu fullload --names node-10-120-127-136 --cpu-percent 80 --kubeconfig ~/.kube/config
{"code":54000,"success":false,"error":"unexpected status, expected status: create, but the real status: Error, please wait!","result":{"uid":"dfba8c6de45087c4","success":false,"error":"unexpected status, expected status: create, but the real status: Error, please wait!","statuses":[{"state":"Error","error":"invalid parameter node-10-120-127-136, can not find node","success":false,"kind":""}]}}
kubectl get node
NAME                  STATUS   ROLES       AGE   VERSION
node-10-120-127-136   Ready    node   13d   v1.23.6
node-10-120-127-137   Ready    node   13d   v1.23.6
node-10-120-127-138   Ready    node   13d   v1.23.6
node-10-120-127-139   Ready    node   13d   v1.23.6

I will fix it @binbin0325


Istio Egress gateway for TCP traffic port 22

Is this the right place to submit this?

[X] This is not a security vulnerability or a crashing bug
[X] This is not a question about how to use Istio

Bug Description
Hi Team,
We are getting the below error in the istio-proxy sidecar container, we have egress for wildcard and its working fine but traffic for port 22 is not being routed to egressgateway, below is our configuration file. I am not sure what are we missing in here.
Error From istio-proxy sidecar :
[2024-06-18T13:17:50.593Z] "- - -" 0 - - - "-" 2313 7962 130 - "-" "-" "-" "-" “xx.xx.xx.xx:8443" outbound|443|wildcard|egressgateway.istio-egress.svc.cluster.local xx.xx.xx.xx:46114 xx.xx.xx.xx:443 xx.xx.xx.xx:47368 ec2.eu-west-1.amazonaws.com -
[2024-06-18T13:17:50.729Z] "- - -" 0 - - - "-" 2306 7960 89 - "-" "-" "-" "-" “xx.xx.xx.xx:8443" outbound|443|wildcard|egressgateway.istio-egress.svc.cluster.local xx.xx.xx.xx:46120 xx.xx.xx.xx:443 xx.xx.xx.xx:50828 ec2.eu-west-1.amazonaws.com -
[2024-06-18T13:17:50.821Z] "- - -" 0 NC - - "-" 0 0 0 - "-" "-" "-" "-" "-" - - xx.xx.xx.xx:22 xx.xx.xx.xx:33264 - -
[2024-06-18T13:17:50.821Z] "- - -" 0 NC - - "-" 0 0 0 - "-" "-" "-" "-" "-" - - xx.xx.xx.xx:22 xx.xx.xx.xx:33266 - -
[2024-06-18T13:17:17.231Z] "- - -" 0 - - - "-"<PHONE_NUMBER>4 89986 - "-" "-" "-" "-" “xx.xx.xx.xx:8443" outbound|443|wildcard|egressgateway.istio-egress.svc.cluster.local xx.xx.xx.xx:47366 xx.xx.xx.xx:443 xx.xx.xx.xx:47536 xx.xx.xx.com -
---
apiVersion: networking.istio.io/v1alpha3
kind: ServiceEntry
metadata:
  name: se-port-22
  namespace: istio-system
spec:
  hosts:
  - "example.com"
  addresses:
  - <IP_ADDRESS>/8
  ports:
  - number: 22
    name: tcp
    protocol: TCP
---
apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
  name: istio-egressgateway
  namespace: istio-system
spec:
  selector:
    istio: egressgateway
  servers:
  - port:
      number: 22
      name: tcp
      protocol: TCP
    hosts:
    - "example.com"
---
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: egressgateway-for-tcp
  namespace: istio-system
spec:
  host: istio-egressgateway.istio-system.svc.cluster.local
---
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: tcp-through-egress-gateway
  namespace: istio-system
spec:
  hosts:
  - "example.com"
  tcp:
  - match:
    - port: 22
    route:
    - destination:
        host: "istio-egressgateway.istio-system.svc.cluster.local"
        port:
          number: 22

Version
Client Version: v1.29.1
Kustomize Version: v5.0.4-0.20230601165947-6ce0bf390ce3
Server Version: v1.28.9-eks-036c24b

Additional Information
No response

outbound|443|wildcard|egressgateway.istio-egress.svc.cluster.local  implies its going to subset=wildcard. That is not defined anywhere in your config in the issue. I am fairly confident you have some config that is not in the issue causing this.,

Ah sorry, got it. Do you have port 22 defined on the gateway Service?

do you mean this. Posted the entire config file above.
apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
  name: istio-egressgateway
  namespace: istio-system
spec:
  selector:
    istio: egressgateway
  servers:
  - port:
      number: 22
      name: tcp
      protocol: TCP
    hosts:
    - "example.com"

That just configures the GW, it still needs to be in the Service object as well

That just configures the GW, it still needs to be in the Service object as well

Yes added the same but its still the same issue. Sharing the entire config file.
---
apiVersion: v1
kind: Service
metadata:
  name: tcp-egressgateway
  namespace: istio-system
spec:
  type: ClusterIP
  selector:
    istio: egressgateway
  ports:
  - port: 22
    name: tcp-egress
    targetPort: 22
---
apiVersion: networking.istio.io/v1alpha3
kind: ServiceEntry
metadata:
  name: se-port-22
  namespace: istio-system
spec:
  hosts:
  - "example.com"
  addresses:
  - <IP_ADDRESS>/8
  ports:
  - number: 22
    name: tcp
    protocol: TCP
---
apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
  name: istio-egressgateway
  namespace: istio-system
spec:
  selector:
    istio: egressgateway
  servers:
  - port:
      number: 22
      name: tcp-egress
      protocol: TCP
    hosts:
    - "example.com"
---
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: egressgateway-for-tcp
  namespace: istio-system
spec:
  host: istio-egressgateway.istio-system.svc.cluster.local
---
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: tcp-through-egress-gateway
  namespace: istio-system
spec:
  hosts:
  - "example.com"
  tcp:
  - match:
    - port: 22
    route:
    - destination:
        host: "istio-egressgateway.istio-system.svc.cluster.local"
        port:
          number: 22

closing this as i have raised a new issue


[admin] merge to live

Docs Build status updates of commit 232ce14:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

Skype/AppSDK/Download.md
:white_check_mark:Succeeded

Skype/AppSDK/ReleaseNotes.md
:white_check_mark:Succeeded

For more details, please refer to the build report.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
For any questions, please:Try searching the docs.microsoft.com contributor guidesPost your question in the Docs support channel


Rework the compiler pipeline to be more agnostic to the specific stages

Maybe the pipeline should provide some way for stages to run things in some pool.


ipfs.config.replace

This can't be finished until https://github.com/ipfs/go-ipfs/issues/2927 is resolved

Looks like ipfs/go-ipfs#2927 has been closed but I'm still seeing similar behaviour with go-ipfs master.
There are couple of problems here:

Setting the config to arbitrary object values (e.g. {}) works for js-ipfs but not go-ipfs.  This seems to be because go-ipfs reads in the passed json config file as a config.Config type which ignores and non-valid fields.

I'm not sure js-ipfs should allow the user to replace it's config with something invalid (e.g. without the default fields, fields with invalid values, etc) - it would probably be better if it was a bit more defensive as go-ipfs is (although I think only by virtue of using a type system).

ipfs config show returns a response with a Content-Type of text/plain and not application/json.  This is because go-ipfs marshals the returned config object and runs it though a pretty printer which returns a byte array, it then wraps that in a byte Reader.  This causes the byte array to be interpreted as a string, hence the Content-Type being wrong.  If you skip all that and just do res.SetOutput(cfg) it behaves as expected.

go-ipfs pretty printing JSON strings deep inside it's commands seems like the wrong place to do this, it would be better handled at a higher level by the web framework and probably based on the incoming Accept header.


Use PKCE to secure the authorization code flow

Hello,
I have an in-house-implemented Authorization server in NodeJS and I would like to use it to authenticate users to Superset. By reading the documentation, the only way to secure the authorization code flow is by using a client_secret. In my case, I would like to use the Proof Key for Code Exchange mechanism. It is also important to mention that Authlib, the library that Superset uses to do OAuth, implements PKCE out of the box. May anyone guide me through the process of intergrating it to Superset ?
Any help will be appreciated. Thank you.

You may set up PKCE by passing the code_challange_method in the client_kwargs. Here is an example of the custom OAUTH provider setup. Be sure, that your server-side is supports PKCE too.
CUSTOM_OAUTH_PROVIDER = {
    "name": "myAUTH",
    "icon": "fa-empire",
    "token_key": "access_token",
    "remote_app": {
        "client_id": os.environ["AUTH_KEY"],
        "client_secret": os.environ["AUTH_SECRET"],
        "api_base_url": "https://example.com",
        "client_kwargs": {
            "scope": "profile email",
            "code_challenge_method": "S256",
        },
        "request_token_url": None,
        "access_token_url": "https://example.com/token",
        "authorize_url": "https://example.com/authorize",
    },
}


classname_of gives Exception when used on TBranch

Please consider the following source code
import uproot
import numpy as np

with uproot.recreate("test.root") as f:
    f["Tree"] = {"x": np.array([1,2,3,4,5])}

f = uproot.open("test.root")
print(f.classname_of("Tree/x"))

I would expect it to print "TBranch". However, it actually raises an exception: AttributeError: 'Model_TTree_v20' object has no attribute 'key'.
Uproot version: 4.1.9

I hadn't thought of this as a potential use, but since "/" hides the distinction between paths into nested directories and paths into nested branches, it makes sense that one would try passing such a path into classname_of, streamer_of, class_of, title_of, etc.
The difficulty is that the path-handling is a specialized implementation in uproot.ReadOnlyDirectory.key
https://github.com/scikit-hep/uproot4/blob/3fe33aff6d6ed88203eed90f4edb5f2bc720f3e6/src/uproot/reading.py#L2006-L2021
which would have to get generalized out to be able to use them in the other functions that take paths.
Or maybe it just means that uproot.TBranch.HasBranches objects (i.e. TTree and all TBranch classes) should have a key method? (What about TBranches that contain TBranches? Would that work? I'm talking to myself...) Such a method can't return an uproot.reading.ReadOnlyKey because TTrees and TBranches don't have them the way that uproot.ReadOnlyDirectory does, but maybe a mocked "FakeKey" could duck-type to supply the appropriate information...

This feature request is still open, but I'm not going to attempt to get it in before the 5.0.0 release (next Monday). I'm just removing that label.