[Apps Framework] Separate calls

Summary
Add separate calls for each function on Apps (submit, form source, form submit and lookup). Also updated the filtering with the new logic.
This PR also piggybacks the renaming of markdown and error to text, and filtering out "white space labels" (to avoid no text labels on post options and channel header), and some improvements on the command parser.
Notes for testing: This is a breaking change. All Apps will need to be updated to work properly. The test app will be updated to fit the new approach.
Ticket Link
https://mattermost.atlassian.net/browse/MM-39092
https://mattermost.atlassian.net/browse/MM-39096
https://mattermost.atlassian.net/browse/MM-31121
https://mattermost.atlassian.net/browse/MM-33532
Related Pull Requests
Apps Plugin: https://github.com/mattermost/mattermost-plugin-apps/pull/296
Webapp: https://github.com/mattermost/mattermost-webapp/pull/9263
Test App: TBD
Release Note
Breaking change for Apps: calls are now separated between submit, form, refresh and lookup calls.

Building app in separate branch.

Building app in separate branch.

Successfully building:
https://circleci.com/gh/mattermost/mattermost-mobile/20884
https://circleci.com/gh/mattermost/mattermost-mobile/20883

@DHaussermann
Tested with the Test App, the ServiceNow App, and the Zendesk App
Test App
Went through all:

Channel header bindings
Post menu bindings
Command bindings
Embedded forms

All functions in these areas seem to be working correctly, having the same behavior as on the webapp.
Service Now

Authentication works
Creating a ticket works

Zendesk

Authentication works
Creating a ticket works
Filling out a subscription form works

Note that since Zendesk targets are deprecated, I needed to fake out the code into thinking there was a valid target available. As a result, I was not able to properly test the submission of the subscriptions form.
Other info
There is a known issue with select fields not being pre-selected with default values. This is fixed with https://github.com/mattermost/mattermost-mobile/pull/5640


Error: EISDIR, open 'C:\code\My.Project\index.html'

Very strange error.
The following works just fine:
.pipe(rename("foo.html"))

However this causes an Error: EISDIR, open:
.pipe(rename("index.html"))

This is on Windows 7 and my project is in a folder that has dots in the folder name (which I figured might be relevant).

Duplicate of https://github.com/hparra/gulp-rename/issues/16.


School admin access granting for coco admins

Feature
Note: This is a work-in-progress with plenty of room for improvement, but it's getting there.
We want to give our admins the ability to grant School Administrator access through the admin modal dialog. This requires a new search, state management before and after storing user ID's in the db and interacting with the new API endpoints in https://github.com/codecombat/codecombat-server/pull/57/files.
Asks

How would you manage state in this situation? It quickly grew complex, and the current structure is more a result of debugging and pulling together all the pieces - rather than by intentional design.
What is a good approach for testing this? My focus has been on understanding the systems, interactions and data models. Now that the pieces are interacting the expected way, could this be done in a more testable way?

Todo

[x] Fix current issue with removing teachers
[ ] Improve state management
[ ] Tests

This looks great!
Managing state is a question that I don't think we have really answered. We have a few different attempts to manage state.

State.coffee

Storage.coffee

We also have the Vuex store
I don't think we have any good examples of using these stores. But I think a good path forward would be to try and start using Vuex for our state management. I am super interested how others have dealt with state in CodeCombat?
Scott in his braindump mentions migrating to Vuex a lot more.
I always feel the testing question hinges off the design. Where can we decouple code with side effects and code that is pure. Would it be possible to move the side effect calls away from code that performs logic on the state.
E.g. taking onClickRemoveAdministeredTeacher as an example. Have an auxiliary method that does the filter, that could be tested.
I'm just spitballing here. I don't think we have a best practice. In some places in the code base we use the DOM as a database and query that, which I don't think I recommend.
Interested to discuss this more.

There is currently a known bug where API updates to permissions won't immediately reflect in the user object locally. The value will update in mongo, but not from the users @get('permissions') - until the dialog is closed and opened - meaning the user object has been created again.
Thoughts?


to get qemu_plugin_outs to work you need -d plugin on qemu cli.

https://github.com/novafacing/cannonball/blob/008f1c1afdc928af183c229e43cd5be48086a027/docs/PLUGIN_API.md?plain=1#L30
Not really an issue, but to answer your question, qemu_plugin_outs seems to output on the plugin log item, so you need -d plugin on the command line.

Nice, thanks for the note! Not sure how I missed it :)


Simplify azure-identity error messaging

#10050
This update simplifies error messages of azure-identity. Below are some examples of how error messages are changed.
DefaultAzureCredential when no credentials are available
Without this update
# error message

No credential in this chain provided a token.
Attempted credentials:
    EnvironmentCredential: Incomplete environment configuration. See https://aka.ms/python-sdk-identity#environment-variables for expected environment variables. Currently set variables: AZURE_CLIENT_ID, AZURE_TENANT_ID
    ImdsCredential: IMDS endpoint unavailable
    SharedTokenCacheCredential: The shared cache contains no signed-in accounts. To authenticate with SharedTokenCacheCredential, login
through developer tooling supporting Azure single sign on

Please visit the documentation at
https://aka.ms/python-sdk-identity#defaultazurecredential
to learn what options DefaultAzureCredential supports

With this update
# error message

DefaultAzureCredential failed to retrieve a token from the included credentials.
Attempted credentials:
    EnvironmentCredential: EnvironmentCredential authentication unavailable. Environment variables are not fully configured.
    ManagedIdentityCredential: ManagedIdentityCredential authentication unavailable. IMDS endpoint unavailable.
    SharedTokenCacheCredential: SharedTokenCacheCredential authentication unavailable. No accounts were found in the cache.

DefaultAzureCredential when authentication failed
Without this update
# error message

No credential in this chain provided a token.
Attempted credentials:
    EnvironmentCredential: Unexpected response '{'error': 'invalid_client', 'error_description': 'AADSTS7000215: Invalid client secret is provided.\r\nTrace ID: 23bcca5a-a617-4e6a-b976-10a11bcb1200\r\nCorrelation ID: 7b0c0354-644d-44cc-905b-de9ebe6c7116\r\nTimestamp: 2020-03-11 06:38:26Z', 'error_codes': [7000215], 'timestamp': '2020-03-11 06:38:26Z', 'trace_id': '23bcca5a-a617-4e6a-b976-10a11bcb1200', 'correlation_id': '7b0c0354-644d-44cc-905b-de9ebe6c7116', 'error_uri': 'https://login.microsoftonline.com/error?code=7000215'}'

Please visit the documentation at
https://aka.ms/python-sdk-identity#defaultazurecredential
to learn what options DefaultAzureCredential supports

With this update
# error message

DefaultAzureCredential failed to retrieve a token from the included credentials.
Attempted credentials:
    EnvironmentCredential: Unexpected response '{'error': 'invalid_client', 'error_description': 'AADSTS7000215: Invalid client secret is provided.\r\nTrace ID: 26540322-9488-4e12-8828-556c58b11900\r\nCorrelation ID: 83ca498c-cfd4-4ab9-9158-e93864a778ac\r\nTimestamp: 2020-03-11 06:40:26Z', 'error_codes': [7000215], 'timestamp': '2020-03-11 06:40:26Z', 'trace_id': '26540322-9488-4e12-8828-556c58b11900', 'correlation_id': '83ca498c-cfd4-4ab9-9158-e93864a778ac', 'error_uri': 'https://login.microsoftonline.com/error?code=7000215'}'

Can one of the admins verify this patch?

/azp run python - identity - ci


Deployment Failure With Release V1.2 With Fresh Clone Code

Summary: Upon deploying the fresh latest clone of release V1.2, the deployment fails with errors indicating that the Storage Account and Key Vault are not found. This is occurring despite it being a fresh deployment with no prior state file, where Terraform should ideally create a new resource group along with all other associated services.
Steps to Reproduce:

Clone the project repository.
Checkout to the latest release V1.2.
Initiate the deployment process.
The deployment ends up with errors related to missing resources (e.g., Storage Account, Key Vault not found).

Expected Behavior: For a fresh deployment, without an existing state file, Terraform should create a new resource group along with all necessary services such as Storage Account and Key Vault, without referencing or expecting existing resources.
Actual Behavior: The deployment fails with errors suggesting that the required resources (Storage Account, Key Vault) are not found, preventing a successful deployment.
Error Message: (Screenshot attached )

Hi Ravi,
Please try the deployment again after deleting all of these terraform artifacts.  I've seen this issue before, but never have experienced it after all of these TF artifacts from a previous deployment are removed.

Please try to create a new Codespace and attempt the deployment from there.  Also, examine the TF plan to see if Terraform is attempting to reuse or create the resources.  Since it's a net new environment, the Storage Account and Key Vault should be marked as create in the TF plan.

HI  bjakems
I cloned New codespace and tried to attempt the deployment from there
It is hitting with the same error,
and here is some of the content from the TF plan files

What I feel maybe is from this 5 on main.tf file there is no
depends_on = [
module.kvModule
]
for 3 modules which give an error, functions, and storage
When I have taken a look at the old version V1.1.1 KV module is on
depends_on = [
module.kvModule
] for the
// Function App
module "functions" {
source = "./core/host/functions"
depends_on = [
module.kvModule
]
}
The above is my understanding and findings,
could you please let me know your thoughts on this

Hi Ravi,
Please try the deployment again after deleting all of these terraform artifacts. I've seen this issue before, but never have experienced it after all of these TF artifacts from a previous deployment are removed.

This solved the issue for me, thanks @bjakems

@ravikhunt are you using the latest code in the main branch with no changes?  Version 1.2 introduces managed identity instead of using secrets in Key Vault where possible.  Additionally, Terraform will automatically build its own dependency chain and depends_on is not required if the module accesses the other resources data in its arguments.
What values have you configured in your local.env file (please do NOT include any Subscription IDs, keys, secrets, etc)?


Pokemon not evolving

Pokemon will sometimes not evolve for some reason, even after requirements have been greatly exceeded. Pselling the Pokémon to another player then leveling it up will evolve the Pokemon.

I'd need a consistent way of reproducing this. Has anyone managed to do that?

Not that I know of. The issue is fairly uncommon now, not sure if it was patched. The problem with investigating the bug, is that if they give you the mon to look at, it fixes the bug.

I've had this issue a few times. The few times it has happened have been a result of the pokemon being over the evolution level when caught in the wild. As of right now I believe I caught a koffing at level 35-36, and it has gotten up to lvl 49 with no evolution.

Closing this since it is old.


RDIMM flag on DDR5 devices

When building the bitstream for an RDIMM DDR5 device, I noticed that the generated litedram_settings.json file includes the following entry:
"is_rdimm": false

This seems to impact the training of the device. Is this behavior a bug? Should we manually set this value when using the build scripts?

Thanks for opening this issue.
I've checked Rowhammer code with its dependencies.
It turns out that this is_rdimm field is never used in the code base.
I'll remove this filed from the litedram_settings.json.
As for training code in the third_party/litex/litex/soc/software/liblitedram/ddr5_training.c.
It does have an is_rdimm variable, but it's being set by read_module_type function, which reads DIMMs SPD memory to check for attached memory type.

I've modified code, so that is_rdimm field will not be added to litedram_settings.json.
I think this closes issue, but feel free to reopen it.


send a session cookie after successful basic auth

Overview
As a way to migrate users to a strong password hashing scheme without getting a performance hit each time, assuming the client will send back the cookie we send them. we check the cookie first and avoid the hit, but we still fall back to basic auth if necessary.
The AuthSession cookie is extended with a new field that indicates whether it was issued by the default authentication handler or the cookie authentication handler. If the cookie was issued by the default authentication handler the cookie authentication handler will check the username in the basic auth header, if present, is a match for the name in the cookie. If it is not, the cookie is ignored. This ensures that the basic auth header takes precedence for any client that got an unasked-for cookie and ensures their operations are performed as the user they intended.
h/t @glynnbird for the idea
Testing recommendations
covered by tests in cookie_auth_tests.exs
Related Issues or Pull Requests
N/A
Checklist

[x] Code is written and works correctly
[x] Changes are covered by tests
[ ] Any new configurable parameters are documented in rel/overlay/etc/default.ini
[x] Documentation changes were made in the src/docs folder
[ ] Documentation changes were backported (separated PR) to affected branches

note that I also took out a fair few unnecessary ?b2l and ?l2b's here as all the functions take iodata now. I confirmed locally that it makes no difference to the hmac, etc


Add anchor CSS

Add the CSS required for https://github.com/QuiltMC/quiltmc.org/pull/122

Everything's been addressed, so off we go.


Update Unity gitattributes for blender save versions

Blender creates multiple copies of the .blend file, and by default it also creates a .blend1 file.

Thanks for the contribution.


Assignment1

What changes are you trying to make? (e.g. Adding or removing code, refactoring existing code, adding reports)
Include my responds to assignment questions in here on GitHub for the learning support to be able to access
What did you learn from the changes you have made?
How to count the number of columns and rows using python codes
Was there another approach you were thinking about making? If so, what approach(es) were you thinking of?
No
Were there any challenges? If so, what issue(s) did you face? How did you overcome it?
git bash gave some issues but it's ok now
How were these changes tested?
On git bash and VSCode
A reference to a related issue in your repository (if applicable)
Checklist

[ -] I can confirm that my changes are working as intended

You have unfortunately made a pull request to the wrong repo. You shouldn't be making a pull request to UofT-DSI/applying_statistical_concepts, but rather your own forked applying_statistical_concepts repo. Please read the instructions on your onboarding Assignment Submission Guide more carefully.


Mock patients - info

Description
I'm interested in why the mock patient data was removed and only the .json.license files are left.
Added:
https://github.com/StanfordBDHG/LLMonFHIR/pull/38/files
Removed:
https://github.com/StanfordBDHG/LLMonFHIR/pull/42/files
Current:
https://github.com/StanfordBDHG/LLMonFHIR/tree/main/LLMonFHIR/Resources/Mock Patients
Reproduction
N/A
Expected behavior
N/A
Additional context
No response
Code of Conduct

[X] I agree to follow this project's Code of Conduct and Contributing Guidelines

Duplicate of #50

Thanks @PSchmiedmayer i've missed that, seems that it's not rendered on the readme.md


fix send method for zero attempts

Coverage increased (+2.3%) to 94.45% when pulling 8297fadba98de70f4e8291c3ea4625eebfcf5256 on boguslavsky:send-fn-fix into a7897150308065e94c28d2439770f7f1259d9f35 on exonum:master.


[Workspaces] Include current workspace as part of url

Including workspaces as part of url in UI brings benefits like sharing datasets between workspace members or simplify user workspaces management.
my url proposal:
/ws/<current-workspace>/ -> will show workspace datasets
/ws/<current-workspace>/<dataset> -> will show workspace dataset
I've included the ws namespace in url path to contextualize info and regarding future features in UI (management other than workspaces, or personal settings...)
Accessing to home url / will automatically redirect to the main workspace url view.
What do you think @Amelie-V @leiyre @dvsrepo @dcfidalgo ?
See also #810  and #736

Sounds good to me! :rocket:


Task: Make First UI

As a user, I want the program to have a dedicated graphical interface to make it easier to use.
The tkinter library will be used for the development of this interface.
This interface will add all the customizable options that the user will be able to use in the software.

Made. Like an extra, users can put the date with a calendar and the signatures in a incorporate paint.


[Bug] Add link to IGDB doesn't work anymore

Describe the bug
When trying to add a link to IGDN nothing happens, even if the URL is correct. While debugging I found out, that IGDB now throws a 403. That didn't happen some days before.
To Reproduce
Steps to reproduce the behavior:

Click on Add link to IGDB on any game

Expected behavior
A link is generated, if there is one with the game name.
please complete the following information:

Windows version: 11
Playnite version: 10.3
Extension version: 0.4

IGDB had to be removed and will be reintroduced at a later date!


run query/web/collector with java - jar

hi all,
i want to run the  query/web/collector with java - jar like this :
java -jar zipkin-collector-service-1.2.0-SNAPSHOT.jar -f  conf/collector-cassandra.scala
but it can't find the dependencies jar . what can i do ?
use this "sbt package" commond?   package the dependencies  jars in libs folder.
--libs
--zipkin-collector-service-1.2.0-SNAPSHOT.jar
--start_collector.sh
--conf

oh  use " package-dist"


GORM may not respond for a long time after a certain period of time ,GORM隔一段时间后，就会长时间不响应

Your Question

GORM隔一段时间后，就会长时间不响应
GORM may not respond for a long time after a certain period of time
The document you expected this should be explained

前端取消请求后
After the front-end cancels the request

后端的数据库查询直接cancel了
The backend database query was directly cancelled

查看数据库的连接正常
Check if the connection to the database is normal

Expected answer

gorm正常查询数据库
Gorm queries the database normally

Check if the connection to the database is normal

Excuse me, how do you check the db connection?

Check if the connection to the database is normal

Excuse me, how do you check the db connection?

I dont know, but I found the problem is cause by redis ,not grom


Badge changes - issue and request

Provide a general summary of the issue here
Badge styling issues, little padding and no right icon
🤔 Expected Behavior?
I'd expect the badge component to have more padding, or the option to modify the padding. It looks a bit bulky on smaller and medium sizes. A padding sm, md, lg option would be nice.
Also, we'd like the option to either have a dismiss button on the right side, (cross icon), or an option for icon-end.
😯 Current Behavior
Very narrow padding, no icon on right side
💁 Possible Solution
More padding on smaller sizes, or smaller icon
or Option for padding size (sm, md, lg)
Option for icon-start and icon-end
📷 Screenshots

📎 Link to Figma
https://www.figma.com/design/YZeBneflpJkX3KXSyvMrqP/Magister-Light-mode?m=auto&node-id=1444-42838&t=fOzM5v2ckY1BWmn1-1
🎨 Your Theme(s)
Magister
### Tasks
- [x] Add padding
- [ ] remove icon only badge?

We don't add an icon back option due to inconsistency reasons.


"grind deploy" fails with latest gcloud command

gcloud app deploy build/app.yaml --project=dart-pad --no-promote fails with the following output:
File upload done.
Updating service [default]...failed.
ERROR: (gcloud.app.deploy) Error Response: [9] Cloud build 85f3a36e-f568-45a8-b715-6202b71b33d0 status: FAILURE
ERROR: Ignored the following versions that require a different python version: 2.3.0 Requires-Python >=3.8; 2.3.1 Requires-Python >=3.8; 2.3.2 Requires-Python >=3.8
ERROR: Could not find a version that satisfies the requirement Flask==2.3.2 (from versions: 0.1, 0.2, 0.3, 0.3.1, 0.4, 0.5, 0.5.1, 0.5.2, 0.6, 0.6.1, 0.7, 0.7.1, 0.7.2, 0.8, 0.8.1, 0.9, 0.10, 0.10.1, 0.11, 0.11.1, 0.12, 0.12.1, 0.12.2, 0.12.3, 0.12.4, 0.12.5, 1.0, 1.0.1, 1.0.2, 1.0.3, 1.0.4, 1.1.0, 1.1.1, 1.1.2, 1.1.3, 1.1.4, 2.0.0rc1, 2.0.0rc2, 2.0.0, 2.0.1, 2.0.2, 2.0.3, 2.1.0, 2.1.1, 2.1.2, 2.1.3, 2.2.0, 2.2.1, 2.2.2, 2.2.3, 2.2.4, 2.2.5)
ERROR: No matching distribution found for Flask==2.3.2

Could we revert https://github.com/dart-lang/dart-pad/commit/5ef52a3b9cb5e27dfedca77ca5f0f7662b18d3cc or modify it to 2.2.5?

I think this is working if we update app.yaml to python 3.8. I'm pushing up a PR now.


CSS is leaked to JS when @vitejs/plugin-legacy is used

Describe the bug
Even if the CSS is split into separate files, it will still be injected into JS, using @vitejs/plugin-legacy.
Reproduction
Run the following command:
git clone git@github.com:jiyingzhi/vite-bug.git
npm i
npm run build

output:
dist/assets/vendor-legacy.60abe03a.js      51.65kb / brotli: 16.90kb
dist/assets/polyfills-legacy.df455098.js   73.89kb / brotli: 26.08kb
dist/assets/index-legacy.19f6a2d2.js       178.76kb / brotli: 42.35kb
dist/assets/logo.03d6d6da.png    6.69kb
dist/index.html                  1.05kb
dist/assets/index.0af28c7f.js    1.47kb / brotli: 0.71kb
dist/assets/vendor.e2d3fd7e.js   42.92kb / brotli: 15.53kb
dist/assets/index.b97d446c.css   177.38kb / brotli: 41.70kb

The size of dist/assets/index-legacy.19f6a2d2.js  minus the size of dist/assets/index.0af28c7f.js is exactly the size of dist/assets/index.b97d446c.css.
System Info
Output of npx envinfo --system --npmPackages vite,@vitejs/plugin-vue --binaries --browsers:
System:
    OS: macOS 11.2.3
    CPU: (8) arm64 Apple M1
    Memory: 112.16 MB / 16.00 GB
    Shell: 5.8 - /bin/zsh
Binaries:
    Node: 15.14.0 - ~/.nvm/versions/node/v15.14.0/bin/node
    npm: 6.14.13 - ~/.nvm/versions/node/v15.14.0/bin/npm
    Watchman: 4.9.0 - /opt/homebrew/bin/watchman
Browsers:
    Chrome: 91.0.4472.101
    Edge: 90.0.818.41
    Safari: 14.0.3
npmPackages:
    @vitejs/plugin-vue: ^1.2.3 => 1.2.3
    vite: ^2.3.7 => 2.3.7

Used package manager: npm

Before submitting the issue, please make sure you do the following

[ x] Read the Contributing Guidelines.
[ x] Read the docs.
[ x] Check that there isn't already an issue that reports the same bug to avoid creating a duplicate.
[ x] Provide a description in this issue that describes the bug.
[ x] Make sure this is a Vite issue and not a framework-specific issue. For example, if it's a Vue SFC related bug, it should likely be reported to https://github.com/vuejs/vue-next instead.
[ x] Check that this is a concrete bug. For Q&A open a GitHub Discussion or join our Discord Chat Server.

same issue here

Can confirm this is still happening with the latest version of Vite and plugin-legacy. I can't tell why or where this is happening though.

@sapphi-red helped tracked this one down (thanks!), and it looks like a duplicate of https://github.com/vitejs/vite/issues/2062. There's a comment mentioning that it's intentional, but can be improved: https://github.com/vitejs/vite/issues/2062#issuecomment-782385406


[tls] Change CA time check to minutes instead of hours

This change allows to use CA certs duration shorter than 1 day, e.g.:
  tls:
    ingress:
      ca:
        duration: 2h0m0s
      cert:
        duration: 1h0m0s
    podLevel:
      internal:
        ca:
          duration: 2h0m0s
        cert:
          duration:  1h0m0s
      libvirt:
        ca:
          duration: 2h0m0s
        cert:
          duration:  1h0m0s
      ovn:
        ca:
          duration: 2h0m0s
        cert:
          duration:  1h0m0s

/test openstack-operator-build-deploy-kuttl

/test openstack-operator-build-deploy-kuttl


fix(deps): bump

Applied mkpr on undefined
/tmp/mkpr.sh

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

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


Remove dependency on imgpkg and docker cli for building plugins

What this PR does / why we need it
Reasons:

Image tarball generated using imgpkg copy -i IMAGE --to-tar TARFILE is not compatible with the docker load or crane push command.
This might be because the imgpkg tarball format is a special format that only works with imgpkg copy

Considering the above I have POC'd the following approach as part of building and publishing plugin packages.
Building plugin packages:

Use the imgpkg library to push the OCI image to the localhost repository
Use crane pull as a library to generate and save it as a local tarball

Publishing plugin packages:

Use crane push as a library to push the image to the remote repository

This means the builder plugin does not depend on any external binary to build and publish plugin oci images.
Which issue(s) this PR fixes

Fixes #372
Describe testing done for PR
$ make prepare-builder

## Build plugins along with building plugin packages and publishing plugins to the local repository
$ make plugin-build-and-publish-packages

Release note

Remove dependency on imgpkg and docker cli for building plugins

Additional information
Special notes for your reviewer

I'm trying to understand why do we zip and unzip the tar file. Is the zipped format used anywhere else?

I have removed the additional zip and unzip-related code from here. If any system expects the plugin oci image to be in the gzip archive format an additional command (e.g. find ${PLUGIN_PACKAGE_ARTIFACTS_DIR} -name "*.tar" | xargs gzip) can be used to convert the tar file to tar.gz.


Update json to add links found in YT description

-25, 26 (supershapes) changing links to supershape track
-29-smart-rockets adding link to genetic algorithm playlist for
-A* adding link to livestream archive and edited code example links, moved link for 10 to related challenges
-52, 53 random-walker adding link to 2018 class and NOC (from YT desc)
-54islamic-star - adding link to livestream archive
-55-mathematic-rose editing language field and code example links
-59-steering-behaviors add related challenges
-61-fractal-spirograph add link to livestream archive
62-plinko add related challenges
64-kinematics edit related challenges
69-evolutionary-steering-behavior edit related challenges, edited topic for consistency

WOW!


Move BYOC images to multi-account folder

FYI @oshrat, this moves the images to the new folder and deletes the BYOC folder

Thanks 🌹


[Linux] Debian packaging issue cause problems when xkb-qwerty-fr is installed

OS: Ubuntu 24.04
xkb-qwerty-fr: v0.7.3 downloaded from GitHub

When trying to update my system, I get the following error:
$ sudo apt update && sudo apt upgrade
(...)
dpkg: cycle found while processing triggers:
 chain of packages whose triggers are or may be responsible:
  xkb-qwerty-fr -> xkb-qwerty-fr
 packages' pending triggers which are or may be unresolvable:
  xkb-qwerty-fr: /usr/share/X11/xkb/rules/base.xml: /usr/share/X11/xkb/rules/evdev.xml: /usr/share/X11/xkb/symbols/us
dpkg: error processing package xkb-qwerty-fr (--configure):
 triggers looping, abandoned
Errors were encountered while processing:
 xkb-qwerty-fr
E: Sub-process /usr/bin/dpkg returned an error code (1)

In the past, I had noticed a similar issue when upgrading Ubuntu (for instance, from 22.04 to 22.10).

Could you fix it and do a PR?

I am not really familiar with Debian packaging at all, so I don't even know what these errors mean. After I restarted my computer, the keyboard layout was gone, and I had to reinstall the .deb file (same version, 0.7.3) to reactivate it. After doing this, it worked again, and I could run sudo apt update && sudo apt upgrade without any issue... Weird!

Hmm this is weird… I will close the issue for now, feel free to reopen once you have a way to reproduce the bug.


M6.misalignments

This is an implementation of small misalignments and rotations. The code has been benchmarked against TraceWin. Misalignments and rotations work on quadrupoles as well as sections (i.e. DTLs, cavities).
The code uses data from SMF alignment bucket. It treats all data (alignments, angles) as relative to the beamline.
Test cases on HEBT2 fail, because there are absolute rotations after bending magnets in alignment buckets.

Hello Ivo,
This is good,  something I wanted but just never had gotten to.  I looked briefly over your code and I like the implementation.  Just a couple things I wanted to mention:

Sako-san had put misalignments in the quadrupoles (I think that's all) because he needed them ASAP.  It was a major kluge and do not consider that in any way important.  I would like it removed in fact.  Looks like you did get rid of it but I can't be sure.
I was going to implement model misalignments as an independent modeling element, basically a thin lens which would abstractly represent any misalignment regardless of actual hardware.  Looks like you have implemented it as a fundamental property in the modeling element hierarchy?
Not sure why HEBT2 test cases fails, but need to understand better.

Thanks,
Chris
From: ilist2 <notifications<EMAIL_ADDRESS>Reply-To: openxal/openxal <reply<EMAIL_ADDRESS>Date: Friday, March 18, 2016 at 10:06 AM
To: openxal/openxal <openxal<EMAIL_ADDRESS>Subject: [openxal] M6.misalignments (#5)
This is an implementation of small misalignments and rotations. The code has been benchmarked against TraceWin. Misalignments and rotations work on quadrupoles as well as sections (i.e. DTLs, cavities).
The code uses data from SMF alignment bucket. It treats all data (alignments, angles) as relative to the beamline.
Test cases on HEBT2 fail, because there are absolute rotations after bending magnets in alignment buckets.

You can view, comment on, or merge this pull request online at:
https://github.com/openxal/openxal/pull/5
Commit Summary

setting alignment errors on modeling elements
removed calculation of misalignments from envelope trackers, so it's only inside quadrupoles
rotation of quadrupoles (roll only)
rotation errors on quads and gaps
Cleaning up pivot position
fixing the order of rotations
Cleaned up and optimized rotation of thin and thick elements (i.e. quads and gaps)
DTLCells misalignment
Misalignment of element sequences.
Fixes to changed calls that happened during merges.
Checking for first/last slice on element misalignments.
Fixing bug in determination of first/last subslice used in rotations of ThickElements.

File Changes

M core/src/xal/model/alg/EnvelopeBacktracker.javahttps://github.com/openxal/openxal/pull/5/files#diff-0 (18)
M core/src/xal/model/alg/EnvelopeTracker.javahttps://github.com/openxal/openxal/pull/5/files#diff-1 (14)
M core/src/xal/model/alg/EnvelopeTrackerBase.javahttps://github.com/openxal/openxal/pull/5/files#diff-2 (57)
M core/src/xal/model/elem/Element.javahttps://github.com/openxal/openxal/pull/5/files#diff-3 (129)
M core/src/xal/model/elem/ElementSeq.javahttps://github.com/openxal/openxal/pull/5/files#diff-4 (22)
M core/src/xal/model/elem/IdealMagQuad.javahttps://github.com/openxal/openxal/pull/5/files#diff-5 (13)
M core/src/xal/model/elem/IdealPermMagQuad.javahttps://github.com/openxal/openxal/pull/5/files#diff-6 (2)
A core/src/xal/model/elem/SectionEndpoint.javahttps://github.com/openxal/openxal/pull/5/files#diff-7 (134)
M core/src/xal/model/elem/ThickElement.javahttps://github.com/openxal/openxal/pull/5/files#diff-8 (119)
M core/src/xal/model/elem/ThinElement.javahttps://github.com/openxal/openxal/pull/5/files#diff-9 (55)

Patch Links:

https://github.com/openxal/openxal/pull/5.patch
https://github.com/openxal/openxal/pull/5.diff

You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHubhttps://github.com/openxal/openxal/pull/5

On 18.3.2016 19:28, Christopher Allen wrote:

Hello Ivo,
This is good, something I wanted but just never had gotten to. I looked
briefly over your code and I like the implementation. Just a couple
things I wanted to mention:

Sako-san had put misalignments in the quadrupoles (I think that's all)
because he needed them ASAP. It was a major kluge and do not consider
that in any way important. I would like it removed in fact. Looks like
you did get rid of it but I can't be sure.

There were two implementations one in EnvelopeTracker and another in
IdealMagQuad. Those were both commented out. I removed both of them. New
implementation is in IdealMagQuad.

I was going to implement model misalignments as an independent
modeling element, basically a thin lens which would abstractly represent
any misalignment regardless of actual hardware. Looks like you have
implemented it as a fundamental property in the modeling element hierarchy?

Yes and no. Quadrupoles return transformed transfer matrix. RFCavities
are implemented as ElementSeq and those are handled by inserting thin
before and after. The lens is implemented in SectionEndpoint class.
I should mention that I didn't work on bending dipoles and they results
were not benchmarked. Also it seems that bends are a bit trickier to
implement.

Not sure why HEBT2 test cases fails, but need to understand better.

Here is the start of HEBT2 section. Look at pitch angles of first dipole
and quadrupole.

-- Ivo

From: ilist2 <notifications<EMAIL_ADDRESS>Reply-To: openxal/openxal <reply<EMAIL_ADDRESS>Date: Saturday, March 19, 2016 at 1:57 AM
To: openxal/openxal <openxal<EMAIL_ADDRESS>Cc: "Allen, Christopher K." <allenck<EMAIL_ADDRESS>Subject: Re: [openxal] M6.misalignments (#5)
On 18.3.2016 19:28, Christopher Allen wrote:

Hello Ivo,
This is good, something I wanted but just never had gotten to. I looked
briefly over your code and I like the implementation. Just a couple
things I wanted to mention:

Sako-san had put misalignments in the quadrupoles (I think that's all)
because he needed them ASAP. It was a major kluge and do not consider
that in any way important. I would like it removed in fact. Looks like
you did get rid of it but I can't be sure.

There were two implementations one in EnvelopeTracker and another in
IdealMagQuad. Those were both commented out. I removed both of them. New
implementation is in IdealMagQuad.
Good, those should be removed.
Why is it necessary to implement misalignments in particular modeling elements?  Isn't this a general property - not particular to any element?  That is, cannot any component be misaligned and the misalignment parameters all mean the same thing (say pitch, yaw, roll, dx, dy, etc.)?

I was going to implement model misalignments as an independent
modeling element, basically a thin lens which would abstractly represent
any misalignment regardless of actual hardware. Looks like you have
implemented it as a fundamental property in the modeling element hierarchy?

Yes and no. Quadrupoles return transformed transfer matrix. RFCavities
are implemented as ElementSeq and those are handled by inserting thin
before and after. The lens is implemented in SectionEndpoint class.
Seems like using the thin lenses situated post- and pre-element would be the general implementation.  The thin lens would transform the beam to the new (misaligned) coordinate system, the beam would propagate through the element, then the exit lenses would complete the misalignment.
Am I missing something?  These things can have subtleties.
I should mention that I didn't work on bending dipoles and they results
were not benchmarked. Also it seems that bends are a bit trickier to
implement.
Cannot the same technique be applied, with the pre- and post- thin lens transformations?  I feel like I am missing something.

Not sure why HEBT2 test cases fails, but need to understand better.

Here is the start of HEBT2 section. Look at pitch angles of first dipole
and quadrupole.

Thanks Ivo,
Chris
-- Ivo

You are receiving this because you commented.
Reply to this email directly or view it on GitHubhttps://github.com/openxal/openxal/pull/5#issuecomment-198649025


Unable to get VPN_PROFILE.PS1 to generate VPN

This is on version 1709 using user authentication. Made our template VPN, which connects fine. Ran MakeProfile.ps1 fine and it generated the VPN_Profile.XML and PS1 files. We're use Powershell; VPN_Profile.PS1 looks fine to this untrained eye.
When we run it, locally, as an admin of the machine, running Powershell as admin with execution policy set to bypass, we get this error from the script -
"Unable to create AlwaysOn VPN profile: A general error occurred that is not covered by a more specific error code."
I commented out all of the error catching and found the error is the following line -
$session.CreateInstance($namespaceName, $newInstance, $options)
I looked at each of the variables being passed to the createinstance and all seem fine. I'm attached their output here in vars.txt.
I've also attached the vpn_profile.ps1 (as a text file.)
Any thoughts?

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

ID: e7453068-95eb-2a42-fd0b-553ae593adb0
Version Independent ID: b39b2cb7-25b1-2af3-4954-dbcc04c836e9
Content: Configure Windows 10 Client Always On VPN Connections
Content Source: WindowsServerDocs/remote/remote-access/vpn/always-on-vpn/deploy/vpn-deploy-client-vpn-connections.md
Service: unspecified
GitHub Login: @shortpatti
Microsoft Alias: pashort

Vars.txt
VPN_Profile.txt

@DiPersiaTech, I'll consult with the main engineer on this and will let you know of the outcome :)

@DiPersiaTech, I have the engineering team working on providing more details. :)

@DiPersiaTech, Sorry for the delay.
The problem is that AlwaysOn tag needs to be set to True, with a capital T.
True
Let me know if that works :)

NOT a solution, bit T little t, none makes ANY difference at all!
Have situation same like here - https://www.hayesjupe.com/always-on-vpn-technical-follow-up/

I have AlwaysOn set to true (lowercase) and it does work.  However I have other issues such as:

Neither user nor device tunnel register the tunnel IP addresses, they only register the physical NIC's address.  I've tried both true and the capital True.  So, DNS registration is obviously working, but it's the wrong IP address.
AlwaysOn does not always connect/reconnect automatically.  It sometimes requires that the user initiate the tunnel.

This occurs for us on 1709 and 1803

Great going guys, seriously no update to this? why bother rolling out an enterprise feature if it's not able to be deployed to the enterprise...


🗺 export { Component }

Discussed in https://github.com/remix-run/remix/discussions/4719

Originally posted by sergiodxa November 30, 2022
Proposal
Use Component named export instead of export default in route files.
Background

export default was a mistake
By Kent

Using export default makes auto-import suggestions harder, and while you probably don't want, or should, import the route component if you're testing the component in Vitest/Jest you're going to need to import it.
It also encourage exporting anonymous components.
export default () => { ... }

Also all other route exports are named ones.
Use Case

Change the convention to be all named exports

API/Examples
export async function loader(args: LoaderArgs) { ... }

export async function action(args: ActionArgs) { ... }

export function Component() { ... }

And if you want to test this route component
import { Component, loader, action } from "~/routes/something"
import { render } from "@testing-library/remix" // fake lib, for now 😉

test("Component renders", async () => {
  render(<Component />)
  // more test code here
})

test("loader returns response", async () => { ... })

test("action returns response", async () => { ... })

Component
I figured folks would want to name their route component though.
By Ryan

Users could create a named component first and re-export it later
function Settings() { ... }
export { Component: Settings }

This could be either in v2 or in v1 by adding a fallback to export default.
If the route doesn't have a Component export Remix could look up for a default export.
If the route doesn't have Component or default, consider it a resource route.
Then on v2 export default can be removed.
A warning could also be added when remix build find out an export default to tell devs to switch to Component.

I strongly disagree with this change.
The React DevTools will be much more difficult to use if every route is called "Component". This is one situation where a default export is very useful.

I'm also not a fan of this change. I think this is one of the very few cases where a default export is useful, allowing libraries/frameworks to give users the option to name an export however they want.

It also encourage exporting anonymous components.

Most projects use ESLint, and there's already a rule that can prevent this: https://github.com/import-js/eslint-plugin-import/blob/main/docs/rules/no-anonymous-default-export.md.

import { Component, loader, action } from "~/routes/something"
import { render } from "@testing-library/remix" // fake lib, for now 😉
test("Component renders", async () => {
render()
// more test code here
})

Seems like the idea is to keep every test file consistent. This is also doable with
import Component, { loader, action } from '~/routes/something'
import { render } from "@testing-library/remix" // fake lib, for now 😉

test("Component renders", async () => {
  render(<Component />)
  // more test code here
})

IMHO, this being a pure DX change, all pros/cons are and will be biased by personal taste 🍰
All in all, it would enhance tests DX while degrading app DX (devtools).
Sounds to me like an unneeded breaking change, and even with a major version bump, we want to have as little as possible of those)

While it's technically not breaking because either option works, I'm against the idea of adding more ways to do the same thing. It just adds confusion.
I'd be in favor of a breaking change here (with a codemod) if the Remix compiler adds a display name that will show the route name in the DevTools.

Just going to drop a link to my thoughts in the other discussion to explain why I am opposed to this. My opinion mirrors much of what @kentcdodds has already said, but I wanted to make sure it was on the record 😅 https://github.com/remix-run/remix/discussions/4719#discussioncomment-4276919
To clarify: I'm not opposed to this because I like defaut exports. To me this is like arguing over let vs. const or semicolons. I literally couldn't care less. I am opposed because, in order to accommodate this we'd either:

Need two conventions, which just creates more overhead
Yet another breaking change in v2, and for little clear benefit other than "a few folks have opinions"

I'm generally getting uncomfortable with how many things we're doing that will require refactoring to upgrade in a couple of months. And unless we can articulate a clear benefit (which I don't feel like we've done here), I really think we should avoid it as much as possible.

To solve the devtools issue, the route loader could give the component a displayName, something like this:
for (const route of loadedRoutes) {
  route.component.displayName = pascalCase(route.path)
}

I recognize this may look like a superfluous change, so hear me out.
If we want a framework we love in 5 years from now, I think we have to make these small adjustments, too.
When I recently rearranged the menu in the Remix docs, it took a bit of thought about what to call the "default export" and what the URL to the doc should be. Here are the sibling docs and their paths:

Route Module

action → /route/action
CatchBoundary → /route/catch-boundary
ErrorBoundary → /route/error-boundary
handle → /route/handle
headers → /route/headers
links → /route/links
loader → /route/loader
meta → /route/meta

So what would you put in the menu and what would the path be for the default export of a route module?
I tried a few things:

default export → /route/default-export
Route Component → /route/route-component
Component → /route/component

Component seems like the obvious choice, it's how we talk about it already: "your route component".
I prefer when "talking about code" and "writing code" line up.
Nobody is saying "default export" when talking about their "route component". All of the docs say "route component", all of the community blog posts and tutorials say "route component", and all of the future resources will say "route component".
Let's line up the API with the vocabulary, especially since the upgrade path is a quick remix codemod route-component away.

I'm convinced. Let's just make sure the display name is handled and there's only one way to do it and I'll be happy.

@ryanflorence I hear what you're saying. As a PHP/WordPress alum, I have just always appreciated the commitment to back compat and truly believe that's a core pillar of what makes that space so strong and successful (heck, even React is pretty great on this front). I'd like for us to have some sort of way to evaluate breaking changes specifically to make sure the juice is worth the squeeze. Even then, we should try to provide a steady off-ramp for our users—even if that means holding onto some duplication and maintenance version for a bit.
Though I'm still not entirely convinced on the merits of this one, can we at least offer deprecation warnings for the next major release before completely pulling the rug out from users? Seems like a good rule-of-thumb for most breaking changes. We own it for at least one major release to give folks more time to migrate to new conventions while still benefitting from new features (this could probably be it's own proposal).

can we at least offer deprecation warnings for the next major release before completely pulling the rug out from users

That's always the case when changing APIs. Opt-in flag or dual compatibility in v1, deprecation warnings before v2, removal in v2.

I agree with @chaance on the keeping default on v2 and only remove it on v3.
Every deprecated feature should be usable for one major version behind a flag to give more time for migration, plus a code-mod to do it automatically.
And yes, meta should follow the same pattern, keep meta_v2 behind a flag in Remix v1, swap the flags in Remix v2 so meta_v1 is default and meta_v1 is optional, remove meta_v1 in Remix v3
I understand is more code to maintain but it will help make the migrations easier, if you can do the same with flat routes would be ideal, so any Remix v1 app could upgrade to Remix v2 and just enable some flags and get deprecation warnings.

I think the feature-by-feature opt-in of breaking changes in v1 is enough to make the migration path much better than what most people experience with most other packages (as noted with Next v1 to v2). Combine that with a codemod and I just really see no point in Remix shouldering the burden of dual support in v2. People will have plenty of time to upgrade feature-by-feature and with a codemod for stuff like this in particular, the migration for this specific feature should take a few minutes tops 🤷♂

Lets keep this conversation to whether or not export Component is a net good change to make rather than how we move the API forward incrementally without breaking apps (which we do and will continue to do!)

Just dumping some of my thoughts on this here:

Have to assign a .displayName for dev tools now, something we don't have to do today and I'm unlikely to take up as a practice
To get around no display name, you have now made your bundle size and the code you have to write a bit longer by first declaring a meaningfully named function, then exporting it "as".
This feels less accessible to people who program with screen readers but would like to hear from someone who does this.

Addressing documentation for the default export:
We are going to support multiple frameworks, so name it /route/react. We will need a page for each framework in the future anyways. Also, what happens when the framework doesn't call them "components", and instead "elements", or the next word that's invented? Does that framework's remix integration's module format change from Component to Element as the export? Keeping it default allows us to remain future proof in this sense. Your "view" is the default export, and when referring to adding something to the default export component, just refer to it as "The View", or "The View Component".
I'd also like to respond to a few other comments above:

I do rely on the function name to know where I am, in-fact, very heavily. You'll rarely find a duplicate function name in complex code-bases I author as it breaks my mental map of how things work. They need names otherwise it's "x flows into x flows into x flows into x....", same reason we don't name every file / function helper()/helpers.ts, but it breaks my brain more than most probably.
I quite commonly do import route components for re-use elsewhere. It's nice to not have to import {Component as TheActualDescriptiveName}, this is not an exceptional scenario.

My takeaways:

This change would bring no meaningful improvements to how you'd author a remix application and serve as a breaking change for the sake of change.
We can add the route ID to a the meaningful named default exports as an improvement today for developer tooling outside of this proposal.
We should document and encourage naming your components contextual to what they do / display / where they are depending on the type of app. Don't have "Index" everywhere.

I think we haven't been clear. Nobody is saying you have to add .displayName manually. This would be done by Remix at compile-time. So you'd just do:
// app/routes/search.tsx
export function Component() {
  /// yada
}

And the compiler would output something like:
export function Component() {
  /// yada
}
Component.displayName = 'SearchRoute'

Or something like that.

I think we haven't been clear. Nobody is saying you have to add .displayName manually. This would be done by Remix at compile-time. So you'd just do:
// app/routes/search.tsx
export function Component() {
  /// yada
}

And the compiler would output something like:
export function Component() {
  /// yada
}
Component.displayName = 'SearchRoute'

Or something like that.

I'm aware, but We could instead keep it default, and add YourDescriptiveComponentName (routes/the-file). It's not one or the other for the "enhance the debug experience", but I'd even go further and say even if we do name them automatically for the Component export, it is still a degraded debug / authoring experience.
I haven't seen a good reason to do this.

Your "view" is the default export, and when referring to adding something to the default export component, just refer to it as "The View", or "The View Component".

I think when we support multiple frameworks we'd use the right word for the framework? export View?
But yeah, I see the value in keeping it as default for this reason so that the route module API (and compiler that removes server code) doesn't care about the rendering lib. Only the default export can be used differently for rendering libs, but loader/action/etc. would be the same everywhere.

First off, I just wanna thank everyone for weighing in here. It's important that we carefully consider changes we are making to the framework as we move it forward.
I agree with Ryan here that the semantics matter, i.e. it's nice when the way we talk about the code and the words we use in the actual code are aligned.
Everything in a route module has a descriptive name. Your loader, action, headers, ErrorBoundary ... even your default! Er ... wait. What exactly does the default export do? Oh right, that's your component!
So as for "this change would bring no meaningful improvement to Remix" I'd have to disagree. Aligning our code with the language we use in regular conversation and documentation is a worthwhile goal.
Imagine you're helping someone who is new to Remix debug an issue in one of their routes that isn't displaying correctly. You might say "ok, first let's check the loader to see it's returning the data we expect. Uh huh. Ok, that looks good. Now what does the component look like?" At that point they might be confused. Where's the component? At which point you'd say "it's the default export" or something similar.
This change would prevent any confusion from ever happening in the first place, which is a meaningful improvement! 🙌
Again, I thank and respect the opinion of everyone who has participated here. Thank you! But having read all comments up to this point I'm still inclined to do this.

I like the idea of a conventionally-named export, but also don't think my opinion is particularly relevant :P
That being said...if the framework moves away from the default export, does that mean a new convention will be needed for creating resource routes? Or would the rule change to

If a route doesn't export a Component component (?), it can be used as a Resource Route

Separately - if y'all move forward w/ no more default export, would a more agnostic name like Main (if not View) help with the nomenclature differences between frameworks?

If  you can detect that a default export is anonymous, in development time, I think it is better to throw an error to force the user to have a named default export.

I just follow the pattern:
export const loader = async () => { /* ... */ }

export const MyNamedComponent = () => { /* ... */ }

export default MyNamedComponent

In VSCode I have a user defined snippet 'rmxroute' which will create all and name the component the same as the file name.
You could even rename your loader/action/whatever export to make it even easier to import into your tests  export { myNamedComponentsLoader: loader }

Imagine you're helping someone who is new to Remix debug an issue in one of their routes that isn't displaying correctly. You might say "ok, first let's check the loader to see it's returning the data we expect. Uh huh. Ok, that looks good. Now what does the component look like?" At that point they might be confused. Where's the component? At which point you'd say "it's the default export" or something similar.
This change would prevent any confusion from ever happening in the first place, which is a meaningful improvement! 🙌

Having onboarded quite a few developers to a few Remix apps (even developers with little JS experience), I can't say that I agree with this argument. The name "component" does not have a strong meaning, people have related more to "layout of the route" than anything else, so I'd argue that for the teaching aspect of this, "Component" isn't even a good name.

Everything in a route module has a descriptive name. Your loader, action, headers, ErrorBoundary ... even your default! Er ... wait. What exactly does the default export do? Oh right, that's your component!
So as for "this change would bring no meaningful improvement to Remix" I'd have to disagree. Aligning our code with the language we use in regular conversation and documentation is a worthwhile goal.

And related to my previous point, in regular conversations "Component" isn't the name people tend to refer.
Disclaimer: none of the people I've onboarded had experience with React Router, so they might be biased (or maybe "unbiased"?). But since Remix tends to align things with React Router, I understand why you'd reach for this name, unfortunately.
I'm with Jacob on this subject, and would be quite upset to see this change.

@duailibe It sounds that maintaining default is not a better solution than Component. It is rather having a more descriptive (framework-agnostic) name.

@sergiocarneiro I could argue that maintaining default is not a worse solution than Component either, but it's the status quo and won't break anything.
I'll give you that it's not super descriptive (which, in my anecdotal experience, is not really a problem), though it's very framework-agnostic.


LibvirtOvsFetchInterfaceCommandWrapperTest fix (test fails in mac) - skip it if no interfaces with eth and wl

Description
This PR fixes LibvirtOvsFetchInterfaceCommandWrapperTest (test fails in mac) - skip it if no interfaces with eth and wl.

Types of changes

[ ] Breaking change (fix or feature that would cause existing functionality to change)
[ ] New feature (non-breaking change which adds functionality)
[x] Bug fix (non-breaking change which fixes an issue)
[ ] Enhancement (improves an existing feature and functionality)
[ ] Cleanup (Code refactoring and cleanup, that may add test cases)
[ ] build/CI
[ ] test (unit or integration test code)

Feature/Enhancement Scale or Bug Severity
Feature/Enhancement Scale

[ ] Major
[ ] Minor

Bug Severity

[ ] BLOCKER
[ ] Critical
[x] Major
[ ] Minor
[ ] Trivial

Screenshots (if appropriate):
How Has This Been Tested?
Ran unit test in local (mac).
Before change:
[INFO] Running com.cloud.hypervisor.kvm.resource.wrapper.LibvirtOvsFetchInterfaceCommandWrapperTest
[ERROR] Tests run: 2, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.108 s <<< FAILURE! - in com.cloud.hypervisor.kvm.resource.wrapper.LibvirtOvsFetchInterfaceCommandWrapperTest
[ERROR] testGetInterfaceDetailsValidValid(com.cloud.hypervisor.kvm.resource.wrapper.LibvirtOvsFetchInterfaceCommandWrapperTest)  Time elapsed: 0.096 s  <<< ERROR!
java.lang.NullPointerException

[ERROR] Errors:
[ERROR]   LibvirtOvsFetchInterfaceCommandWrapperTest.testGetInterfaceDetailsValidValid » NullPointer
[ERROR] Tests run: 455, Failures: 0, Errors: 1, Skipped: 2

After change:
[INFO] Running com.cloud.hypervisor.kvm.resource.wrapper.LibvirtOvsFetchInterfaceCommandWrapperTest
[WARNING] Tests run: 2, Failures: 0, Errors: 0, Skipped: 1, Time elapsed: 0.109 s - in com.cloud.hypervisor.kvm.resource.wrapper.LibvirtOvsFetchInterfaceCommandWrapperTest

How did you try to break this feature and the system with this change?

@blueorangutan package

@sureshanaparti a [SL] Jenkins job has been kicked to build packages. It will be bundled with  KVM, XenServer and VMware SystemVM templates. I'll keep you posted as I make progress.

Packaging result [SF]: ✔ el7 ✔ el8 ✔ el9 ✔ debian ✔ suse15. SL-JID 10339

code lgtm
Do we need this in 4.18 as well? Maybe we can also add networkInterface.getName().startsWith("en") which may allow the test to run on Mac
Maybe something like networkInterface.getName().matches("^(eth|en|wl).*") for cleaner code

I think, need this in 4.18, i'll rebase to it.
I added "en" check earlier and removed as it's Libvirt/KVM test, should be fine for unit test - will add that.

@blueorangutan package

@sureshanaparti a [SL] Jenkins job has been kicked to build packages. It will be bundled with  KVM, XenServer and VMware SystemVM templates. I'll keep you posted as I make progress.

Packaging result [SF]: ✔ el7 ✔ el8 ✔ el9 ✔ debian ✔ suse15. SL-JID 10355


[backport] Remove random.power test with forbidden value

Backport of #2375

[automatic post] Jenkins, test this please.

Jenkins CI test (for commit cf2cf88fbbeb5eaa1d0a004c3e20cf902542be01, target branch v6) failed with status FAILURE.

LGTM


Create metadata csv files for download

Create a metadata csv file for each file in LabCAS.
When user downloads a file, download the file and the metadata file.
Create a metadata icon in the file list to allow user to get to the metadata file and download.

Works great!


Other runner events should not be captured

Expected behavior
Other runner events should not be captured
Actual behavior
Events manifest and execution are still being captured
Steps to replicate

Enable telemetry
Run gauge run --env=js-wd

The analytics show events manifest and execution

Blocks #1251

Those are left being captured because if the user does not use any IDE but still actively uses gauge via command line daemon wont be started and we wanted to know

Percentage of active user's language runner (JavaScript vs Java vs Python vs Ruby vs Csharp)

Only during execution we find active usage and runner details in that case.

Discussion Update
The events execution and manifest should not be captured


Replace jQueryAJAX by FetchAPI

Questions
Answers

Description?
old jQuery AJAX need to be replaced by modern and native FetchAPI. More details in the related discussion.

Type?
refactor

BC breaks?
no

Deprecations?
no

Fixed ticket?
Fixes PrestaShop/PrestaShop/discussions/34239

Sponsor company
Your company or customer's name goes here (if applicable).

How to test?
1. Get a clean dev branch then apply PR changes.  2. FO - clear Browser cache, BO - clear PS cache (required as this PR has JS changes).  3. Check to make sure that all features of module work as usual in both FO and BO, especially in BO > Modules > Content tab: Drag and Drop, Enable/Disable, Delete a Block in Grid view.

@matks My changes is only in _dev/back/index.js file. 2 JavaScript libraries changes in the diff really come from bot's PR 612, and PR 625. Neither bot nor github build-release run npm run build so I must did it myself :)

@florine2623 I can reproduce that bug without applying this PR changes. The reason is simple: when you add a second block with the same png, the previous uploaded png will be overwritten; then when you request deleting the second block, the current code delete its png without checking whether it is being used by other block.
So I think you can create a new issue and let this PR passed :)

Issue created here : https://github.com/PrestaShop/PrestaShop/issues/35178


Adds postgresql contrib for standard functions

Proposed fix for https://github.com/Expaso/hassos-addon-timescaledb/issues/23#issuecomment-1149714229=
I've not run/tested this as I'm not familiar with the local dev process for addons and ha, however i'm reasonably confident this change should be fine.

Thanks. I hope @Expaso can merge this when it's okay! :)

Sweet! this will definitely be an asset! Thank you so much!


Don't depend on htcondor-ce-condor

htcondor-ce-condor just provides config for htcondor-ce and the condor backend. Installing htcondor-ce brings all the actual packages necessary for testing CE -> condor job submission; we already throw down half of the necessary config by writing our own job routes, so we just need to add the backend condor configuration

Why? Is this what we tell our users?

Well if we want to go by what we tell our users, we should be looking for the osg-ce-<batch system> package, which requires the htcondor-ce-<batch system>. The underlying packages and half the config are already there, I don't see a point in skipping CE + condor testing in this case.

OK.


Skip invalid scrapResults

The recent occurence of LINE bot shows that ListArticle API sometimes failed to properly scrap URLs.
https://rollbar.com/mrorz/rumors-line-bot/items/19/
https://rollbar.com/mrorz/rumors-line-bot/items/151/
It causes:
[{"path": ["ListArticles"], "message": "Cannot destructure property `title` of 'undefined' or 'null'.", "extensions": {"code": "INTERNAL_SERVER_ERROR"}, "locations": [{"column": 7, "line": 3}], "authError": false}]

Then in term cuases:
TypeError: Cannot read property 'edges' of null (Most recent call first)

ListArticles.edges.length

However, scrapping should not interfere with ordinary searches. This PR filters out failed scrap results to fix the problem.
Related: https://github.com/cofacts/rumors-line-bot/issues/10

Coverage increased (+0.03%) to 89.041% when pulling 2d1ae5812d311777625c09f0db9ea24c24b50724 on fix-scrapurl into 7756bb3153d1632541a9158054759ec0f87b00cd on master.


And what browser are you using?

Ok it works now with the new version.


nni=2.7; torch.cuda.is_available() is False in evaluate_model.

I coding as the script of https://github.com/microsoft/nni/blob/v2.7/examples/nas/multi-trial/mnist/search.py
nni version is 2.7
in "if name == 'main':",torch.cuda.is_available() is Triue
in function evaluate_model() ,torch.cuda.is_available() is False and os.environ["CUDA_VISIBLE_DEVICES"] is -1
I add one line code of "exp_config.training_service.gpu_indices = [0,1,2]"
run the command:
python search.py

I use nni to search hyperparameter with nnictl .But In nas search, I confused how to control the trails.

exp_config.trial_gpu_number = 1;


Port tracking package

Port the tracking package from the dv-ros repository to ROS2

Finished porting the package, see 653b2b2241622ee92229ac0b2e794d79f6beb363. Currently only tested on a DVXplorer Micro with Events-only mode without motion compensation.


Add subdivision es-ct, flag from Catalonia

Hi,
I've created es-ct, flag from Catalonia emoji. I was unable to run "yarn prepublish". So I don't know how can I contribute es-ct emoji properly.
Can you help, me? Or, better, can you get 1f3f4-e0065-e0073-e0063-e0074-e007f.svg and 1f3f4-e0065-e0073-e0063-e0074-e007f.png files and integrate them on Twemoji?
Thanks in advance-

 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.You have signed the CLA already but the status is still pending? Let us recheck it.

This PR, along with #437, would resolve #574.


support uuid as pk

Coverage increased (+8.9%) to 80.383% when pulling 6c1dddb12b7cecab627dc42253d5873acf578e6d on uuid into ac5cb7db7b3fa3c0e4cf0d958a4ee1216c25a46e on master.

Coverage increased (+3.2%) to 74.725% when pulling 66d4888e2dbd03bf8bbfc894d1d21fdf436374df on uuid into ac5cb7db7b3fa3c0e4cf0d958a4ee1216c25a46e on master.


Improve bleptriangle

Reduce the pole coefficient from .999 to .995 which fixes a discontinuity while the filters are cold.
Attached videos demonstrate the effect:
With 0.999
return el.mul(gain, dpole(0.999, el.blepsquare(props, rate)));
https://github.com/elemaudio/elementary/assets/536859/7a0bc0ff-b42f-4159-bc6f-3c77604f0326
With 0.995
return el.mul(gain, dpole(0.995, el.blepsquare(props, rate)));
https://github.com/elemaudio/elementary/assets/536859/f52a7fc3-2540-4fef-8067-df5f9ab28abf

Excellent, thank you @pauliusuza! Mind just changing the base branch to develop? I'm happy to merge then

@nick-thompson done!

Sorry for the delay @pauliusuza! I merged this one via cherry-pick in https://github.com/elemaudio/elementary/commit/3666f511f8b3257dbae26aded3b6dd8b7cebd798, closing the PR here accordingly. Thanks again 🙏


Always runs in flash player mode on Linux+Chrome

I'm using the latest version (v2.23.2) and it always uses flash mode on Linux+Chrome even though the browser plays the movie natively just fine (Chromium 53.0.2785.143).
On Linux+Firefox and Windows+Chrome/Firefox ME runs just fine and plays the movie natively.
The movie used is Big Buck Bunny (H.264/MP4) from here.

e.g. with this HTML (<video> with no ME)...

<!DOCTYPE html>
<html>
<head>
    <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
    <script src="jquery.js"></script>
    <script src="mediaelement-and-player.min.js"></script>
    <link rel="stylesheet" href="mediaelementplayer.min.css" />
</head>
<body>

<video width="640" height="400" id="player1" controls="controls" preload="none">
    <source type='video/mp4' src="output.mp4">
    <track kind="subtitles" src="output.srt" srclang="en" />
</video>

</body>
</html>

...the result is this:

...but when adding ME stuff...
<!DOCTYPE html>
<html>
<head>
    <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
    <script src="jquery.js"></script>
    <script src="mediaelement-and-player.min.js"></script>
    <link rel="stylesheet" href="mediaelementplayer.min.css" />
</head>
<body>

<video width="640" height="400" id="player1" controls="controls" preload="none">
    <source type='video/mp4' src="output.mp4">
    <track kind="subtitles" src="output.srt" srclang="en" />
</video>

<script>
$('audio,video').mediaelementplayer({
    startLanguage:'en',
    enableAutosize: true,
    features: ['playpause','progress','current','duration','tracks','volume','fullscreen'],
    enableKeyboard: true,
    startVolume: 1.0,
});
</script>

</body>
</html>

...the result is flash mode:

Thanks for pointing this. Can you test this with 3.x-dev branch and see if the issue is still there please?

@alindt Perfect. Thank you for verifying this. I'll close this ticket since 3.0 version will be released soon


Upgrade to Bootstrap 5.2.1

I was thinking it would be nice to upgrade the CSS to Bootstrap 5.x and it looks like 5.2.1 is the latest available.
After checking, it seems like it would be almost a 1-for-1 swap, with very small tweaks, since you're using very little of the library by default.
Once Bootstrap 5 is in place, we could potentially take advantage of some of the new features it has to offer.
Is this something you would be interested in doing, please let me know and I'll create a PR. Thanks.

@mostlyvirtual yes I would like to upgrade it to the latest version of Bootstrap. A PR would be great.

Fixed in latest release v1.3 - Upgraded to Bootstrap 5.3


Issues with Nameusage search

Hello,
As part of our update to EUNIS2 database, we are getting some species information from CoL.
We are getting taxonomy from searching by name. For the most part, around 80% of the time, we get accurate results with the search, but for the remaining 20% we get unusually random erroneous results.
Below is an example of a plant that returns a bacteria result.
<https://api.catalogue.life/dataset/3LR/nameusage/search?q=Morella rivas-martinezii&limit=300>
It is not until it reaches search result number 227 when it finally finds the actual taxonomy for "Morella rivas-martinezii"
Here are some two more examples:
Centranthus amazonum -> kingdom:Animalia, phylum:Chordata, class:Amphibia, order:Anura, family:Bufonidae, genus:Bufotes, species:Bufotes boulengeri
Pastor roseus -> kingdom:Animalia, phylum:Nematoda, class:Chromadorea, subclass:Chromadoria, order:Chromadorida, suborder:Chromadorina, superfamily:Chromadoroidea, family:Chromadoridae, subfamily:Euchromadorinae, genus:Crestanema
Also, when the name ends in "all others" like for instance, "Periparus ater all others", then the search always assigns it the same result, with it being:
kingdom:Plantae, phylum:Tracheophyta, class:Magnoliopsida, order:Caryophyllales, family:Amaranthaceae, subfamily:Chenopodioideae, genus:Bassia
Is this a bug in the search API or do I need some additional filters?
Thanks a lot in advance.
Javier

Hi @javiermerino-tracasa
You can limit the search to a given higher taxon, e.g. Plantae using the TAXON_ID parameter.
The default match type is WHOLE_WORDS which means that any name having rivas in the author string will match.
If you change the match type to EXACT you will only get matches that have your query as a full substring.
Using TAXON_ID=P and type=EXACT will find your species here:
https://api.catalogueoflife.org/dataset/3LR/nameusage/search?TAXON_ID=P&limit=50&offset=0&q=Morella rivas-martinezii&type=EXACT
You may however find that in some cases type=EXACT is too narrow when it comes to e.g. spelling variants and different author spellings.

Hello Thomas,
We are using the name search for getting information for hundreds of names in an automated fashion. We cannot rely on the taxon_id suggestion since we will not know the taxonomy for each name beforehand.
As for EXACT, we can try using it first, and for those that it cannot find anything, then we do whole_words.
This will improve the results for those names that match perfectly.
However, it will remain as inaccurate for the examples I showed above.
Thanks.
Javier

Alternatively you can also use the PREFIX type search when you want the name to start with your query string. In your example the querystring Morella rivas-martinezii will be taken as 3 tokens: Morella, rivas & martinezii which will match the name or authorship. You can also restrict the matching to the name alone, avoiding matches to the authorship which in your example hits Rivas almost all the time:
https://api.catalogueoflife.org/dataset/3LR/nameusage/search?q=Morella rivas-martinezii&content=scientificName

this is the prefix search: https://api.catalogueoflife.org/dataset/3LR/nameusage/search?q=Morella rivas-martinezii&content=scientificName&type=PREFIX

Hello Markus,
Thanks for the help.
I am now using type EXACT and then when it fails, content scientific name and it is working much better for us.


Failed to run reactions after neutralization using Uncharger

Describe the bug
I want to use SMARTS reaction to re-assign formal charges to molecules at a typical pH. Take carboxylic acid charge as an example. The first step is to use the Uncharger to neutralize the possibly wrongly assigned charges, the product of which will undergo SMARTS reaction to re-assign the charge.
Take an example SMILES:
from rdkit import Chem
from rdkit.Chem import AllChem
from rdkit.Chem.MolStandardize import rdMolStandardize
from rdkit.Chem.Draw import IPythonConsole
IPythonConsole.drawOptions.addAtomIndices = True
IPythonConsole.molSize = 300,300
IPythonConsole.ipython_useSVG=True

smiles = 'CC(O)CN1CCN(CC(=O)[O-])CCN(CC(=O)[O-])CCN(CC(=O)[O-])CC1'
mol = Chem.MolFromSmiles(smiles)
uncharger = rdMolStandardize.Uncharger()
uncharger.unchargeInPlace(mol)

uncharged_smiles = Chem.MolToSmiles(mol)

return: CC(O)CN1CCN(CC(=O)O)CCN(CC(=O)O)CCN(CC(=O)O)CC1 --> Uncharger did well on neutralizing this molecule.
But upon taking the RDMol Object mol to undergo the reaction:
rxn = AllChem.ReactionFromSmarts('[OH1&+0;$(O-C=O)!$(O~C~[-1]):1]>>[O-:1]')
product = rxn.RunReactants((mol,))[0][0]
try:
    Chem.SanitizeMol(product)
except Exception as e:
    print(e)
print(Chem.MolToSmiles(product))

Return:
Explicit valence for atom # 0 O, 2, is greater than permitted
CC(O)CN1CCN(CC(=O)O)CCN(CC(=O)O)CCN(CC(=O)[OH-])CC1

The O is turned to [OH-] implicitly, making the valence of O > 2.
My current workaround is to reperceive the uncharged_mol from the uncharged_smiles, then apply the reaction on it. The reaction did well.
uncharged_mol = Chem.MolFromSmiles(uncharged_smiles)
product = rxn.RunReactants((uncharged_mol,))[0][0]
try:
    Chem.SanitizeMol(product)
except Exception as e:
    print(e)
print(Chem.MolToSmiles(product))
product

Return: CC(O)CN1CCN(CC(=O)[O-])CCN(CC(=O)O)CCN(CC(=O)O)CC1

Expected behavior
I have the feeling that after the Uncharger, there is still some atom properties that have not been cleaned, requiring the Re-perception using Chem.MolFromSmiles. I wonder if there is any direct solution, so that I don't need to output SMILES to an intermediate level and take it in again.
Screenshots
If applicable, add screenshots to help explain your problem.
Configuration (please complete the following information):

RDKit version: 2024.9.1 and 2024.9.3
Are you using conda? yes
If you are using conda, which channel did you install the rdkit from? Conda-forge

This is not a bug. You need to change your SMARTS from
[OH1&+0;$(O-C=O)!$(O~C~[-1]):1]>>[O-:1]

to
[OH1&+0;$(O-C=O)!$(O~C~[-1]):1]>>[OH0-:1]

to specify that you want to set implicit hydrogens on the deprotonated oxygen to 0, as previously there was an implicit hydrogen on the neutral oxygen.
When unsure, please ask these questions in the Discussions tab rather than raising an issue. If it turns out to be a bug, the issue can be raised later.


Experimental hardware device and the pre-training model

What is the GPU version used in the model training experiments in your article? What is the number of GPUs? How long does it take to train a model? And will you release the pre-training model?

Hi @linhanxiao, the details are:
GPU - Nvidia 1080 with 2 GPUs
Training Time: close to 2 days for 120 Epochs.
I will soon upload the training models.
Thanks

Good evening,
apart from the trained model, is there anything else missing from your repository, that was implemented in the paper?

How about the evaluation speed please?


k-bucket@3

Performance improvements to .distance() in this version but API changes too...
PR depends on https://github.com/mafintosh/k-rpc/pull/4 being merged first.

PR depends on https://github.com/mafintosh/k-rpc/pull/4 being merged first.

i've merged and released the pr you sent for k-rpc. we should probably force bump the semver in pkg json

K, will do

Bumped. Let's see if the tests pass now.

rolling the 🎲

7.2.0


Docs Audit  - Tailwind Group 2

Contributing to :

https://github.com/skeletonlabs/skeleton/issues/1049

Checklist

[x] Breadcrumbs
[x] Buttons
[x] Cards
[x] Chips
[x] Lists
[x] Logo Clouds
[x] Placeholders
[x] Tables
[x] Gradient Headings

On the button page, on smaller devices, the button size showcase dialog will have the outer most buttons clip on each side, not sure if this is desired.

Can replicate that as well, I'll leave to @endigo9740 as to proper fix for it.
But looks like both two additional set of eyes have done a review now.

@niktek I was about to say the same about the phone lol
Per the layout, I had disabled the base button for that reason. But I think we can probably edit the text within the buttons to be:
sm | base | lg | xl
That should fit

New sizes work on mobile for me now


Unavailable if you want to use Spot instances

In the pros/cons at the top of the page, it's worth mentioning that you can't (for some reason) use Ephemeral disks if you want to make use of Spot instances.

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

ID: 2b2c2980-a90e-dd58-d572-6da5cd05ec8b
Version Independent ID: 67949cf4-6f6d-0563-6b45-99141924c54a
Content: Use ephemeral OS disk nodes for Azure Batch pools - Azure Batch
Content Source: articles/batch/create-pool-ephemeral-os-disk.md
Service: batch
GitHub Login: @prkannap
Microsoft Alias: prkannap

The error given in the portal says
Ephemeral OSDisk is only supported for pools consisting exclusively of dedicated nodes.

@MatthewSteeples
Thanks for the feedback! I have assigned the issue to content author to check and update the document as appropriate.

@prkannap
Can you please check and add your comments on this doc update request as applicable.

Sorry it has taken so long to respond. I checked with the Spot team and ephemeral OS disks are supported on Spot now. Thank you!
#please-close

@cynthn Would you mind letting the Azure Batch team know that then please? When trying to use them in the Portal and via Batch Explorer you still get the following error message:
code : InvalidPropertyValue
message : The value provided for one of the properties in the request body is invalid.
RequestId:05a83d97-55e1-467e-aa3b-97ff78525fd3
Time:2023-02-18T01:23:32.0289721Z
PropertyName: ephemeralOSDiskSettings
Reason: Ephemeral OSDisk is only supported for pools consisting exclusively of dedicated nodes.

Is there a process for getting this issue re-opened or am I better off opening a new one?
As stated in my first message it is not possible to use ephemeral disks in Batch with nodes that contain Spot instances and the documentation does not make this clear


Deck Transition not Rounding ViewController

I can slide to dismiss and all the functionalities work. The issue is when I present the VC with decktransition, it just covers the whole screen and the top corners are not rounded. Any suggestions?

Sorry for the late response. Could you please upload a reproducible example based on the Example app included in the repo?


making bower a full dependency since it's called from postinstall

Coverage remained the same at 95.402% when pulling 15d444deec2b65127a14aed8010c6953118c861d on dlockhart:bower-dep into 3584ece16376f3d011d96d3e87978a00dee87b2f on Brightspace:master.


Copy File name is not working in explorer in VS CODE

VSCode Version: Code 1.19.0 (816be6780ca8bd0ab80314e11478c48c70d09383, 2017-12-14T09:51:12.123Z)
OS Version: Darwin x64 17.3.0
Extensions:

Extension
Author (truncated)
Version

vscode-markdownlint
Dav
0.12.0

aio-compiler
azt
1.0.2

java
red
0.16.0

vscode-java-debug
vsc
0.5.0

vscode-java-pack
vsc
0.2.0

markdown-all-in-one
yzh
0.11.2

(2 theme extensions excluded)

Steps to Reproduce:

Reproduces without extensions: Yes/No

@HGautam25 what do you mean by "Copy File name"?
The explorer only has a "Copy" and a "Copy Path" action.

This issue has been closed because it needs more information and has not had recent activity. Please refer to our guidelines for filing issues. Thank you for your contributions.


Event filter test

Due to  rustfmt for whole project some extra files have been added in the staging for git ,please ignore them


Refactored Ubiquity Unit Test to fork mainnet

This PR Resolves #630, but i still think theres room for updates unless state otherwise and the team want to close the issue
This PR refactors some of the test and purges "Mocks" dependencies on em, but not all, removing the mocks folder it's a not a trivial thing as there are many other testing depending on it, likewise we use ABI compatible on mainnet, we decide to use interfaces within the unit test, because organizing the interfaces within the folders clash! with current mock tests and other tests
This PR Does not removes or clean Diamonds, diamonds are still being deployed even when forked

This PR adds some new custom test like
Playing with mainnet

There is an virtual function added on top of DiamondTestSetup.sol for bool checking if mainnet is forked

Finally refactored some tests that are playing with mainnet returning mainnet values

More tests
There are also other goods tests and non-trivial, like deploying Curve metapool and adding blazing liquidity to it

The thing is that I don't understand the initial issue. Yes, we should have tests in a forked environment but in my opinion we should separate unit tests (in a none-forked environment) and integrations tests (in a forked environment).

that was why I initially asked for brainstorming when started with this one, but to me, it was a good way to get started into the project

Besides we don't have a production deploy (with the diamond setup) so there is basically nothing to fork. We can basically fork only the UbiquityDollar contract and users' balances.

Which in turns made no necessary to remove any diamonds testing

There are minor issues in this PR like using deprecated abbreviations, deprecated interfaces or modified tests although the implementation is untouched.

`

The main issue with this PR is that it tries to use old/deprecated interfaces with a new diamond setup thus making tests even more complicated to understand.

A reminder that not using ABI compatible on mainnet will get us testing REVERT

I would:

Close this PR as not planned and use it for future reference for integration testing
Mark issue as completed
Create separate issues for integration testing in a forked environment

I'd be happy to take the 3 if you guys going to open new issues for alike tasks

Seems like a solid first contribution. Let me ask @zgorizzo69 on telegram and see what they think about this pull request.

The provided video looks good to me https://github.com/ubiquity/ubiquity-dollar/issues/630#issuecomment-1593771178

gentlemen it looks like we are 2/2, because by the looks says @pavlovcik is +1 & as much as the same way I worked on the tasked, want the PR to make it, as i know theres value, but maybe @rndquu is 50/50, who owns the last word? @zgorizzo69

Unfortunately zgorizzo69 is the code owner of this repository and they said

and I think we should close the pr

Does it make sense to roll in this work as part of the newly created issue #682?
Unfortunately I don't quite understand all of these details as I am not a Solidity developer.

Unfortunately zgorizzo69 is the code owner of this repository and they said

and I think we should close the pr

Does it make sense to roll in this work as part of the newly created issue #682?
Unfortunately I don't quite understand all of these details as I am not a Solidity developer.

this newly opened need more brainstorming as there are points need to be taken, like production deployment mentioned by ndquu, also i notice the label < than a day there, it's not something accomplishable for less than a day
I think this PR mets the requirements for the #630 even tho there may need updates and changes, what about the task there?

this newly opened need more brainstorming as there are points need to be taken, like production deployment mentioned by ndquu, also i notice the label < than a day there, it's not something accomplishable for less than a day

I think this PR mets the requirements for the https://github.com/ubiquity/ubiquity-dollar/issues/630 even tho there may need updates and changes, what about the task there?
@rndquu I'll let you make the decisions here. Feel free to edit the specifications/merge bounties if needed.

this newly opened need more brainstorming as there are points need to be taken, like production deployment mentioned by ndquu, also i notice the label < than a day there, it's not something accomplishable for less than a day

I think this PR mets the requirements for the #630 even tho there may need updates and changes, what about the task there?

@rndquu I'll let you make the decisions here. Feel free to edit the specifications/merge bounties if needed.

appreciate so we can start brainstorming the new requirement, I think i can render a layout for the insfrastructure for commenting and feedback

basically I handcrafted this one without enough context on what what's coming, but following the requirements as state. and now this PR provides the context for future value.
Otherwise,
This PR plays in mainnet and there are refactored tests that were not initially playing in mainnet, this PR handle specific ABI to be able to catch mainnet data that otherwise would not be possible without adding it, after all this PR actually pass the tests without interfering with other tests that are not mainnet

To sum up
Initially it is our fault because:

Issue description is not clear
Even if the description had been clear the PR would have added unnecessary complexity (which basically happened)

At the same time the PR requires additional work even if we considered it for merging
Let's:

Close this PR without merging
Cut bounty reward in half because the work has been done but we can't accept the PR in its current state

@molecula451 Thank you for your contribution, hope you will continue solving other bounties and understand this middle ground decision.


Optifabric still conflicts with Origins mod

It says this when I try to load fabric 1.17.1:
Found conflicting mods: origins conflicts with {optifabric @ [<=1.11.18]}
Creating` Empty clause ?
Idk if I misunderstood the changelog in the latest origins file (1.17, 1.17.1: Origins 1.0.3) tho and origins + optifabric just dont work together but yea, this's all i know

The mods are currently still incompatible, but the OptiFabric dev will maybe update the compatibility again as they have done before.


[TEST] Setting Up ApolloClient with Curriculum Page as Demo

When deploying the repo  / testing in the development API_URL need to be defined in environmental variables.
Reference the curriculum page to understand how to use GraphQL

A different PR will be submitted for a simpler solution. The last update to the PR was to test deployment.


undefined symbol: __atomic_exchange_8 on arm (raspberry pi 4)

This is similar to #20400, however I'm experiencing it on the latest release (1.32) so it seems to still be an issue.
What version of gRPC and what language are you using?
I'm installing grpc 1.32.0 as a rubygem.
gem list | grep grpc
grpc (1.32.0)

What operating system (Linux, Windows,...) and version?
Linux (raspbian), running on a raspberry pi 4.
$ uname -a
Linux raspberrypi 4.19.75-v7l+ #1270 SMP Tue Sep 24 18:51:41 BST 2019 armv7l GNU/Linux

What runtime / compiler are you using (e.g. python version or version of gcc)
$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/arm-linux-gnueabihf/8/lto-wrapper
Target: arm-linux-gnueabihf
Configured with: ../src/configure -v --with-pkgversion='Raspbian 8.3.0-6+rpi1' --with-bugurl=file:///usr/share/doc/gcc-8/README.Bugs --enable-languages=c,ada,c++,go,d,fortran,objc,obj-c++ --prefix=/usr --with-gcc-major-version-only --program-suffix=-8 --program-prefix=arm-linux-gnueabihf- --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --enable-bootstrap --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-libitm --disable-libquadmath --disable-libquadmath-support --enable-plugin --with-system-zlib --with-target-system-zlib --enable-objc-gc=auto --enable-multiarch --disable-sjlj-exceptions --with-arch=armv6 --with-fpu=vfp --with-float=hard --disable-werror --enable-checking=release --build=arm-linux-gnueabihf --host=arm-linux-gnueabihf --target=arm-linux-gnueabihf
Thread model: posix
gcc version 8.3.0 (Raspbian 8.3.0-6+rpi1)

$ ruby -v
ruby 2.5.5p157 (2019-03-15 revision 67260) [arm-linux-gnueabihf]

What did you do?
Installing the gem works as expected:
$ gem install grpc

However, when I attempt to use it I get a runtime error:
ome/jh/git/home-data/vendor/bundle/ruby/2.5.0/gems/grpc-1.32.0/src/ruby/lib/grpc/grpc_c.so: undefined symbol: __atomic_exchange_8 - /home/jh/git/home-data/vendor/bundle/ruby/2.5.0/gems/grpc-1.32.0/src
/ruby/lib/grpc/grpc_c.so
  /home/jh/git/home-data/vendor/bundle/ruby/2.5.0/gems/grpc-1.32.0/src/ruby/lib/grpc/grpc.rb:22:in `require'
  /home/jh/git/home-data/vendor/bundle/ruby/2.5.0/gems/grpc-1.32.0/src/ruby/lib/grpc/grpc.rb:22:in `<top (required)>'
  /home/jh/git/home-data/vendor/bundle/ruby/2.5.0/gems/grpc-1.32.0/src/ruby/lib/grpc.rb:19:in `require_relative'
  /home/jh/git/home-data/vendor/bundle/ruby/2.5.0/gems/grpc-1.32.0/src/ruby/lib/grpc.rb:19:in `<top (required)>'
  /home/jh/git/home-data/vendor/bundle/ruby/2.5.0/gems/gapic-common-0.3.4/lib/gapic/grpc.rb:15:in `require'
  /home/jh/git/home-data/vendor/bundle/ruby/2.5.0/gems/gapic-common-0.3.4/lib/gapic/grpc.rb:15:in `<top (required)>'
  /home/jh/git/home-data/vendor/bundle/ruby/2.5.0/gems/google-cloud-monitoring-v3-0.1.4/lib/google/cloud/monitoring/v3/metric_service/client.rb:171:in `require'
  /home/jh/git/home-data/vendor/bundle/ruby/2.5.0/gems/google-cloud-monitoring-v3-0.1.4/lib/google/cloud/monitoring/v3/metric_service/client.rb:171:in `initialize'
  /home/jh/git/home-data/vendor/bundle/ruby/2.5.0/gems/google-cloud-monitoring-1.0.0/lib/google/cloud/monitoring.rb:154:in `new'
  /home/jh/git/home-data/vendor/bundle/ruby/2.5.0/gems/google-cloud-monitoring-1.0.0/lib/google/cloud/monitoring.rb:154:in `metric_service'
  /home/jh/git/home-data/vendor/bundle/ruby/2.5.0/gems/stackdriver_simple-0.2.0/lib/stackdriver_simple.rb:21:in `submit_gauge'
  /home/jh/git/home-data/daikin-stackdriver:121:in `write_gauge'
  /home/jh/git/home-data/daikin-stackdriver:103:in `block in execute'
  /home/jh/git/home-data/daikin-stackdriver:102:in `each'
  /home/jh/git/home-data/daikin-stackdriver:102:in `execute'
  /home/jh/git/home-data/daikin-stackdriver:172:in `execute'
  /home/jh/git/home-data/vendor/bundle/ruby/2.5.0/gems/clamp-1.3.1/lib/clamp/command.rb:66:in `run'
  /home/jh/git/home-data/vendor/bundle/ruby/2.5.0/gems/clamp-1.3.1/lib/clamp/subcommand/execution.rb:18:in `execute'
  /home/jh/git/home-data/vendor/bundle/ruby/2.5.0/gems/clamp-1.3.1/lib/clamp/command.rb:66:in `run'
  /home/jh/git/home-data/vendor/bundle/ruby/2.5.0/gems/clamp-1.3.1/lib/clamp/command.rb:140:in `run'
  /home/jh/git/home-data/vendor/bundle/ruby/2.5.0/gems/clamp-1.3.1/lib/clamp.rb:8:in `Clamp'
  /home/jh/git/home-data/daikin-stackdriver:161:in `<top (required)>'

Configuring bundler to set -latomic at compile time resolves the issue:
$ bundle config --local build.grpc --with-ldflags="-latomic"
You are replacing the current local value of build.grpc, which is currently nil

$ bundle
Fetching gem metadata from https://rubygems.org/.......
Using public_suffix 4.0.6
Using addressable 2.7.0
Using bundler 2.0.2
Using clamp 1.3.1
Using multipart-post 2.1.1
Using faraday 1.0.1
Using google-protobuf 3.13.0
Using googleapis-common-protos-types 1.0.5
Fetching grpc 1.32.0
Installing grpc 1.32.0 with native extensions
Using googleapis-common-protos 1.3.10
Using jwt 2.2.2
Using memoist 0.16.2
Using multi_json 1.15.0
Using os 1.1.1
Using signet 0.14.0
Using googleauth 0.13.1
Using gapic-common 0.3.4
Using google-cloud-env 1.3.3
Using google-cloud-errors 1.0.1
Using google-cloud-core 1.5.0
Using google-cloud-monitoring-dashboard-v1 0.2.3
Using google-cloud-monitoring-v3 0.1.4
Using google-cloud-monitoring 1.0.0
Using stackdriver_simple 0.2.0
Bundle complete! 4 Gemfile dependencies, 24 gems now installed.                                                                                Bundled gems are installed into `./vendor/bundle`

What did you expect to see?
I expected to be able to require and use the grpc gem.
What did you see instead?
See above.
It'd be great if the could set -latomic automatically when compiled on arm systems.
I noticed the debian package maintainers have configured a workaround as well: https://salsa.debian.org/debian/grpc/-/commit/289d884261d05d49465fb5bf33385d477d007974
Anything else we should know about your project / environment?
Not that I know if.

We added libatomic auto-detection to gRPC Python packages only. We might need to evaluate whether it's possible to add this to ruby package. In the meantime, having bundle config --local build.grpc --with-ldflags="-latomic" could be effective workaround, thanks!

It doesn't seem like that workaround works. We are running into an issue building grpc for armhf Raspberry Pi Raspbian Buster since updating to Ruby 2.7.
Using bundle config build.grpc --with-cflags="-latomic" --with-ldflags="-latomic" causes this error during bundle install:
gcc: error: unrecognized command line option ‘--with-ldflags=-latomic’

Using bundle config build.grpc --with-cflags="-latomic" --with-ldflags="-latomic" causes this error

Does it work without --with-cflags="-latomic"?

The libatomic detection for python does not work for me on Raspberry with Raspian Bullseye. It did previously work on Buster
$ python3
Python 3.9.1+ (default, Feb  8 2021, 22:09:01)
[GCC 10.2.1 20210110] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import grpc
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/pi/develop/speech-to-text/venv_grpcio/lib/python3.9/site-packages/grpc/__init__.py", line 23, in <module>
    from grpc._cython import cygrpc as _cygrpc
ImportError: /home/pi/develop/speech-to-text/venv_grpcio/lib/python3.9/site-packages/grpc/_cython/cygrpc.cpython-39-arm-
linux-gnueabihf.so: undefined symbol: __atomic_exchange_8

Content of my venv

Package
Version

grpcio
1.36.1

pip
20.3.4

pkg-resources
0.0.0

setuptools
44.1.1

six
1.15.0

This worked for me:
# This can be added to your ~/.bashrc
export LD_PRELOAD=/usr/lib/arm-linux-gnueabihf/libatomic.so.1.2.0
python3 some_script_using_grpcio.py

Does it work without --with-cflags="-latomic"?

Yes, it does. To be clear, this works on Debian buster (as well as other platforms):
bundle config build.grpc --with-ldflags=-latomic

The libatomic detection for python does not work for me on Raspberry with Raspian Bullseye. It did previously work on Buster

Note that Debian bullseye changed the default linker flags to use --as-needed. As explained in this Wiki page:

What is --as-needed? The --as-needed flag is passed to the GNU linker (GNU ld). The flag tells the linker to link in the produced binary only the libraries containing symbols actually used by the binary itself. This binary can be either a final executable or another library.

If you attempt to use --with-ldflags=-latomic with Ruby on Debian bullseye, the resulting grpc_c.so will NOT be linked to libatomic. Ruby attempts to create a shared library via g++ -o shared. However, the default --as-needed flag causes it to omit libatomic, even if -latomic is specified.
I imagine something similar is happening with Python.
I think the best option is to add -Wl,--no-as-needed to LDFLAGS when compiling the interpreter. Ruby v3.0.4 now does this.
If you wanted to avoid that, you can also pass those flags when building grpc. However, it's a little tricky. Due to https://github.com/rubygems/rubygems/issues/5972, Ruby's bundler does not appear to work properly when multiple arguments are passed to --with-ldflags delimited by spaces.
For Ruby 2.7.5, configuring bundler to avoid this space by using --with-ldflags and --with-dldflags appears to work:
bundle config build.grpc --with-ldflags=-Wl,--no-as-needed --with-dldflags=-latomic

Note that libatomic is only needed if gcc targets -march=armv6 as explained in https://github.com/protocolbuffers/protobuf/issues/5219#issuecomment-1226049062.
Newer Raspberry Pi models use armv7l, which does not need libatomic.


The SortOrder interface could support a reverse option?

I was struggling to remember I needed to specify order: "descending" instead of reverse: true. Perhaps we could support both?

The use of reverse: boolean in ChannelDomainOptions is confusing because it doesn’t mean (exactly) to reverse the order: it means to use descending natural order instead of ascending natural order. The difference is that descending natural order still puts null/unorderable values last, whereas reversing ascending natural order would put null/unorderable values first. Therefore it would probably make more sense to add a order option to the ChannelDomainOptions interface, and change the meaning of the reverse option so that it puts nulls first (assuming that you leave order as the default ascending). We could also allow the order option in ChannelDomainOptions to be specified as a comparator function.


Ensure that delayed diagnostics in protocol conformance checking are emitted.

It was recently discovered that some delayed conformance error diagnostics are not being emitted by the MultiConformanceChecker. While the desire to even have this delayed diagnostics infrastructure is ripe for debate, for now I think it would be good make the MultiConformanceChecker and ConformanceChecker destructors more robust by ensuring that they check for lost diagnostics.
For MultiConformanceChecker we now try to force-flush delayed diagnostics if one of its ConformanceCheckers has not already complained. I also added an assert in ConformanceChecker to identify obviously-forgotten diagnostics.
As a result, this PR fixes one missing "does not conform to protocol" error diagnostic that was not being emitted.
Fixes rdar://73641790

@swift-ci please test