How to add proxy parameter

I wonder how can I add a proxy when do http request.
Thanks.

hi @jmcarp , thank you for your awesome  work. I'm totally new in python. I realized that your code above would work perfectly, but as newbie I can't figured it out. I'm using  script below & I would like to run the script via proxy server (e.g. <IP_ADDRESS>:8080).
import re
import robobrowser
import sys

MOBILE_USER_AGENT = "Mozilla/5.0 (Linux; U; en-gb; KFTHWI Build/JDQ39) AppleWebKit/535.19 (KHTML, like Gecko) Silk/3.16 Safari/535.19"
FB_AUTH = "https://www.facebook.com/v2.6/dialog/oauth?redirect_uri=fb464891386855067%3A%2F%2Fauthorize%2F&display=touch&state=%7B%22challenge%22%3A%22IUUkEUqIGud332lfu%252BMJhxL4Wlc%253D%22%2C%220_auth_logger_id%22%3A%2230F06532-A1B9-4B10-BB28-B29956C71AB1%22%2C%22com.facebook.sdk_client_state%22%3Atrue%2C%223_method%22%3A%22sfvc_auth%22%7D&scope=user_birthday%2Cuser_photos%2Cuser_education_history%2Cemail%2Cuser_relationship_details%2Cuser_friends%2Cuser_work_history%2Cuser_likes&response_type=token%2Csigned_request&default_audience=friends&return_scopes=true&auth_type=rerequest&client_id=464891386855067&ret=login&sdk=ios&logger_id=30F06532-A1B9-4B10-BB28-B29956C71AB1&ext=1470840777&hash=AeZqkIcf-NEW6vBd"

def get_access_token(email, password):
    s = robobrowser.RoboBrowser(user_agent=MOBILE_USER_AGENT, parser="lxml")
    s.open(FB_AUTH)

    ## submit login form
    f = s.get_form()
    f["pass"] = password
    f["email"] = email
    s.submit_form(f)

    ## click the 'ok' button on the dialog informing you that you have already authenticated with the Tinder app
    f = s.get_form()
    s.submit_form(f, submit=f.submit_fields['__CONFIRM__'])

    ## get access token from the http response
    access_token = re.search(r"access_token=([\w\d]+)", s.response.content.decode()).groups()[0]
    return access_token

email = sys.argv[1]
password = sys.argv[2]
access_token = get_access_token(email, password)

print(access_token)

I've tried code bellow, but got no expected result.
from requests import Session
import re
from robobrowser import RoboBrowser
import sys

MOBILE_USER_AGENT = "Mozilla/5.0 (Linux; U; en-gb; KFTHWI Build/JDQ39) AppleWebKit/535.19 (KHTML, like Gecko) Silk/3.16 Safari/535.19"
FB_AUTH = "https://www.facebook.com/v2.6/dialog/oauth?redirect_uri=fb464891386855067%3A%2F%2Fauthorize%2F&display=touch&state=%7B%22challenge%22%3A%22IUUkEUqIGud332lfu%252BMJhxL4Wlc%253D%22%2C%220_auth_logger_id%22%3A%2230F06532-A1B9-4B10-BB28-B29956C71AB1%22%2C%22com.facebook.sdk_client_state%22%3Atrue%2C%223_method%22%3A%22sfvc_auth%22%7D&scope=user_birthday%2Cuser_photos%2Cuser_education_history%2Cemail%2Cuser_relationship_details%2Cuser_friends%2Cuser_work_history%2Cuser_likes&response_type=token%2Csigned_request&default_audience=friends&return_scopes=true&auth_type=rerequest&client_id=464891386855067&ret=login&sdk=ios&logger_id=30F06532-A1B9-4B10-BB28-B29956C71AB1&ext=1470840777&hash=AeZqkIcf-NEW6vBd"

def get_access_token(email, password, proxiesvalue):

    session = Session()
    session.proxies = {'http': proxiesvalue}
    s = robobrowser.RoboBrowser(user_agent=MOBILE_USER_AGENT, session=session, parser="lxml")
    s.open(FB_AUTH)

    ## submit login form
    f = s.get_form()
    f["pass"] = password
    f["email"] = email
    s.submit_form(f)

    ## click the 'ok' button on the dialog informing you that you have already authenticated with the Tinder app
    f = s.get_form()
    s.submit_form(f, submit=f.submit_fields['__CONFIRM__'])

    ## get access token from the http response
    access_token = re.search(r"access_token=([\w\d]+)", s.response.content.decode()).groups()[0]
    return access_token

email = sys.argv[1]
password = sys.argv[2]
proxiesvalue = sys.argv[3]
access_token = get_access_token(email, password, proxiesvalue)

print(access_token)

feel free to edit script, any help from you would be much appreciated.
joy


fix: allow unknown type for Parse

Fixes #152

Great. I will create a release today.

Thanks so much for the quick fix.


[Bug]: e2e test with dummy agent: wrong action state outcome

Is there an existing issue for the same bug?

[X] I have checked the troubleshooting document at https://opendevin.github.io/OpenDevin/modules/usage/troubleshooting
[X] I have checked the existing issues.

Describe the bug
Action "Run e2e test with dummy agent / test (pull_request)" running in CI returns success, even though the actual test inside fails with a curious error.
For reference, link to test result log from a PR that itself isn't involved in the test:
https://github.com/OpenDevin/OpenDevin/actions/runs/9644933344/job/26598091132?pr=2552#step:5:32
12:05:46 - opendevin:INFO: agent_controller.py:135 - [Agent Controller default] Starting step loop...

==============
DummyAgent LEVEL 0 STEP 0

12:05:46 - ACTION
AddTaskAction(parent='0.0', goal='run ls', subtasks=[], thought='', action='add_task')
12:05:46 - opendevin:ERROR: agent_controller.py:143 - Error while running the agent: Task does not exist:0.0
12:05:46 - opendevin:ERROR: agent_controller.py:144 - Traceback (most recent call last):
  File "/home/runner/work/OpenDevin/OpenDevin/opendevin/controller/agent_controller.py", line 138, in _start_step_loop
    await self._step()
  File "/home/runner/work/OpenDevin/OpenDevin/opendevin/controller/agent_controller.py", line 324, in _step
    await self.event_stream.add_event(action, EventSource.AGENT)
  File "/home/runner/work/OpenDevin/OpenDevin/opendevin/events/stream.py", line 112, in add_event
    await callback(event)
  File "/home/runner/work/OpenDevin/OpenDevin/opendevin/controller/agent_controller.py", line 168, in on_event
    self.state.root_task.add_subtask(event.parent, event.goal, event.subtasks)
  File "/home/runner/work/OpenDevin/OpenDevin/opendevin/controller/state/task.py", line 204, in add_subtask
    parent = self.get_task_by_id(parent_id)
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/runner/work/OpenDevin/OpenDevin/opendevin/controller/state/task.py", line 183, in get_task_by_id
    raise LLMMalformedActionError('Task does not exist:' + id)
opendevin.core.exceptions.LLMMalformedActionError: Task does not exist:0.0
12:05:46 - opendevin:INFO: agent_controller.py:193 - [Agent Controller default] Setting agent(DummyAgent) state from AgentState.RUNNING to AgentState.ERROR
12:05:47 - opendevin:INFO: agent_controller.py:193 - [Agent Controller default] Setting agent(DummyAgent) state from AgentState.ERROR to AgentState.STOPPED

the agent's ERROR state is reset to STOPPED thus no fail?
the session id is not provided as call to main.py, thus defaulting to "default"?
DummyAgent itself not using correct sid itself?

Current OpenDevin version
0.6.2

Installation and Configuration
CI

Model and Agent
see CI
Operating System
No response
Reproduction Steps
No response
Logs, Errors, Screenshots, and Additional Context
No response

Hello @rbren if you have a minute, I think this issue needs some assistance of yours, thanks! 👋

In the latest action, step 1 error is ignored.

Could you reopen it as the test in #2834 was not failed as expected?


Fix comments

Description of changes:
Fix Email preview logo
Fix Comments not being displayed
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of the met-public license (Apache 2.0).

Codecov Report

Merging #1755 (ab2e150) into main (4236f02) will decrease coverage by 0.01%.
The diff coverage is 83.33%.

@@            Coverage Diff             @@
##             main    #1755      +/-   ##
==========================================
- Coverage   71.43%   71.43%   -0.01%
==========================================
  Files         374      374
  Lines       11178    11177       -1
  Branches      865      865
==========================================
- Hits         7985     7984       -1
  Misses       3057     3057
  Partials      136      136

Flag
Coverage Δ

metapi
79.49% <83.33%> (+0.01%)
:arrow_up:

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files
Coverage Δ

met-api/src/met_api/models/submission.py
80.73% <ø> (-0.07%)
:arrow_down:

met-api/src/met_api/models/comment.py
71.73% <80.95%> (+2.82%)
:arrow_up:

met-api/src/met_api/resources/comment.py
76.36% <100.00%> (+0.43%)
:arrow_up:

met-api/src/met_api/services/submission_service.py
81.15% <100.00%> (ø)

... and 3 files with indirect coverage changes


Why start script does not contain gc log

It is found that there is no gc log in the start script of Pulsar. Could you please tell me the trade-off?

It is found that there is no gc log in the start script of Pulsar. Could you please tell me the trade-off?

It may just not expose the setting of JVM here, if you are interested, please send a pull request to fix this issue.


updates to the Drin visualisation and html

Youssef's HTMl conversion work

merging the pull request from Youssef's branch jzf/vis


Pages can't be scrolled via keyboard

Many parts of the Facette UI can't be scrolled via keyboard unless you focus the content are by clicking it first.  The layout should probably leave the scrolling alone and use position: fixed to keep things visible.
This problem also affects the docs on facette.io.
Tested in Chrome 38 and Firefox 33 on Ubuntu 12.04.

Hi @twm,
Just for letting you know and as it has been a while since you opened this issue.
This has been addressed in the process of rebuilding a fully new UI that should come with one of the next releases when all the remaining work on this UI will be completed :smiley:

Fixed in branch 0.4-alpha.


*: do not suffix "fips" for tikv version ouput

What is changed and how it works?

Issue Number: Close #16200
See #16199

Do not suffix "fips" for tikv version ouput
What's Changed:

Check List
Tests

Manual test
tikv-server -V

Release note

None

/merge


fix(mission_planner, route_handler): enable loop detection of route

Signed-off-by: tomoya.kimura<EMAIL_ADDRESS>Description
In the current implementation, isRouteLooped() always returns false because one primitives has only one id.
Duplicate check of lane_id must be done for the entire segments. I fixed it.

Related links

Tests performed
I confirmed that the following error occurs and route was not published when I tried to set route with overlapping lanes using check points.

Notes for reviewers

Pre-review checklist for the PR author
The PR author must check the checkboxes below when creating the PR.

[ ] I've confirmed the contribution guidelines.
[ ] The PR follows the pull request guidelines.

In-review checklist for the PR reviewers
The PR reviewers must check the checkboxes below before approval.

[ ] The PR follows the pull request guidelines.
[ ] The PR has been properly tested.
[ ] The PR has been reviewed by the code owners.

Post-review checklist for the PR author
The PR author must check the checkboxes below before merging.

[ ] There are no open discussions or they are tracked via tickets.
[ ] The PR is ready for merge.

After all checkboxes are checked, anyone who has write access can merge the PR.

@mitsudome-r -san is added because I think he did it first.

@tkimura4
can you resolve this conflict?

@taikitanaka3
resolved!


[Question] Same process for init_boot.img?

I'm wondering the process is same for init_boot.img flash?

Fix "STOCK BOOT.IMG NOT NOT FOUND" by magisk canary using Termux
-> Download stock boot.img (init_boot.img mostly in android 14 out of the box)
-> For boot.img

ls -d /dev/block////by-name/boot

ls -d /storage///*/boot.img

<Modify 3rd command line according to first 2 commands output>
dd if=/storage/emulated/0/Download/boot.img of=/dev/block/platform/soc/112b0000.ufshci/by-name/boot_b
-> For init_boot.img

ls -d /dev/block////by-name/init_boot

ls -d /storage///*/init_boot.img

<Modify 3rd command line according to first 2 commands output>
dd if=/storage/emulated/0/Download/init_boot.img of=/dev/block/platform/soc/112b0000.ufshci/by-name/init_boot_b

I'm wondering the process is same for init_boot.img flash?

The partition for init_boot is different, so the script currently doesn't find init_boot partition only the boot(s) partitions. But if you want you can modify the script to search for init_boot in find_boot_block function call at https://github.com/gitclone-url/Boot-img-flasher/blob/8642dcf097ff022f525deb4ca715a3ebf4ddfa88/boot-img-flasher.sh#L196...
I will try implement it in next week thanks for your concern 😀

@DineshValor and I didn't understood your second comment. please can you be more specific? https://github.com/gitclone-url/Boot-img-flasher/issues/1#issuecomment-2259851120


feat: more env vars

Is your feature request related to a problem? Please describe.
I am trying to streamline the redeployment of the current webui and some of the settings have default values which do not have a corresponding env var.
Describe the solution you'd like
Have env vars for all default settings

Hope all is sufficient enough now for users. I'm sure new environment variables will come in the future as well! For reference, here's the current documented list of environment variables that can be set for Open WebUI: https://docs.openwebui.com/getting-started/env-configuration


Configure explicit dependency on the copyFonts task to fix a build

fixes: https://github.com/JetBrains/compose-multiplatform/pull/4247


feat: add job listing

Description
Create an API endpoint to allow users post new job listings.
This endpoint will validate the job posting and then add it to the database.

The changes include:

Endpoint Addition: Added POST /api/v1/jobs for posting new jobs.
Error Handling: Implemented checks for invalid data and unauthorized access.
Testing: Added pytest cases to ensure functionality and edge cases are covered.

Related Issue (Link to issue ticket)
Issue Ticket
Motivation and Context
This feature is essential to allow users post new jobs on the site.
How Has This Been Tested?

Unit Tests: Added tests to validate the addition of jobs to the database, authorization failures and invalid request body.
Test Environment: Tests were run using a mocked database instance to avoid interference with the production environment.

Tests include:

Adding a job to the database successfully.
Handling invalid request body
Handling unauthorized access.

Screenshots:
Successful Request

Invalid request body

Types of changes

[x]  New feature (non-breaking change which adds functionality)

Checklist:

[x]  My code follows the code style of this project.
[x]  My change requires a change to the documentation.
[x]  I have updated the documentation accordingly.
[x]  I have read the CONTRIBUTING document.
[x]  I have added tests to cover my changes.
[x]  All new and existing tests passed.

Make changes and I will merge

@joboy-dev Changes implemented

Merge conflict!!

Merge conflict!!

Merge conflict resolved @joboy-dev

Merge conflict!!

Conflict resolved.
Following the new conventions, this endpoint should only be accessible by an admin.
@joboy-dev


python3Packages.pyinstaller: init at 6.8.0, with dependencies

Description of changes

Closes #249327
I have tested pyinstaller on a small project, verifying that the basic functionality of the main executable works, but not much more.
@septem9er: I have taken you out of the maintainer list for python3Packages.pyinstaller-hooks-contrib for now. Considering you closed #224865, I am guessing you do not want to maintain it. Ping me or open a PR if this is not the case
Things done

Built on platform(s)

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

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

[ ] sandbox = relaxed
[ ] sandbox = true

[ ] Tested, as applicable:

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

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

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

[x] Fits CONTRIBUTING.md.

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

@GetPsyched do you think you could have a go at testing this as well? I'm not too confident that there aren't any branches left where the program would crash due to missing deps or something.

Will try to find the time. Currently, I don't use any project that needs pyinstaller, so this is tricky.

@GetPsyched No worries if you don't have any such project or time to test it, I just pinged you in particular because you opened the issue


Hook race fix

The pre-upgrade hook will now drain all nodes before checking if jobs are running on them in order to prevent a race conditions in which pending jobs are scheduled onto the nodes after the check if complete. Will RESUME nodes on a successful upgrade

Made scontrol changes, only thing is that by using NodeName=all the other named nodes (i.e slurmd-[2-9]) will get added to the list in a drain state, but I'm guessing this wouldn't really be an issue in production?

Actually one thing that I've realised is that this fix introduces a NEW race condition where once the nodes are undrained, jobs could potentially get scheduled onto them before the upgrade starts, I need to move the undraining to a post-upgrade hook


breakfix: Nested imports

Describe the issue
Hi! Thanks for your work on caddy-security. I'm trying to parameterize my configs so that I can keep configurations DRY across authentication/authorization definitions in my Caddyfile. The structure I've come up with has snippets defined in a secondary Caddyfile that's imported. However, I'm getting the following error when loading the config:
lb_1  | Error: adapting config using caddyfile: parsing caddyfile tokens for 'security': malformed "security.authorization.policy.import" directive: [crypto_config]

This seems to imply that the nested import blocks aren't being evaluated? This seems to be related to #45. There's an example config block which should work, so perhaps I'm missing something.
Configuration
Paste full Caddyfile below:
Caddyfile:
import Caddyfile.import

{
    # Wire up caddy-security
    order authenticate before respond
    order authorize before basicauth

    security {
        import security_authorization
    }
}

example.com {
    reverse_proxy http://internal
}

Caddyfile.import:
(crypto_config) {
    crypto default token name auth_token
}

# shared authz config
(authz_config) {
    import crypto_config
    set auth url https://example.com/asdf
    set token sources header cookie
    validate bearer header
}

# authorization definitions
(security_authorization) {
    authorization policy admin_only {
        import authz_config
        allow roles admin
    }

    authorization policy sw_only {
        import authz_config
        allow roles public
    }
}

Version Information
Provide output of caddy list-modules -versions | grep git below:
^ this command doesn't appear to give any output under Caddy 2?
dns.providers.linode v0.0.0-20210701121230-e16993235880
http.authentication.providers.authorizer v1.1.19
http.handlers.authenticator v1.1.19
security v1.1.19

Expected behavior
The nested imports should be expanded.
Additional context

May be related to https://github.com/caddyserver/caddy/issues/4914

I can confirm that this is fixed in the master branch of caddy. :tada:


add IBM Cloud Functions operator

Thanks submitting your Operator. Please check below list before you create your Pull Request.
New Submissions

[x] Have you selected the Project Community Operator Submissions in your PR on the right-hand menu bar?
[x] Are you familiar with our contribution guidelines?
[x] Have you packaged and deployed your Operator for Operator Framework?

Your submission should not

[x] Modify more than one operator
[x]  Submit operators to both upstream-community-operators and community-operators at once
[x] Modify any files outside the above mentioned folders
[x] Contain more than one commit. Please squash your commits.

Operator Description must contain (in order)

[x] Description about the managed Application and where to find more information
[x] Features and capabilities of your Operator and how to use it
[x] Any manual steps about potential pre-requisites for using your Operator

Operator Metadata should contain

[x] Human readable name and 1-liner description about your Operator
[x] Valid category name1
[x] One of the pre-defined capability levels2
[x] Links to the maintainer, source code and documentation
[x] Example templates for all Custom Resource Definitions intended to be used
[x] A quadratic logo

Remember that you can preview your CSV here.
--
1 If you feel your Operator does not fit any of the pre-defined categories, file a PR against this repo and explain your need
2 For more information see here

@lionelvillard please check https://operatorhub.io/preview with your operator and especially last section called Custom Resource Definitions and fix it please.
Also copy and fill form bellow.
Thanks submitting your Operator. Please check below list before you create your Pull Request.
New Submissions

[ ] Have you selected the Project Community Operator Submissions in your PR on the right-hand menu bar?
[ ] Are you familiar with our contribution guidelines?
[ ] Have you packaged and deployed your Operator for Operator Framework?

[ ] Have you tested your Operator in all supported installation modes?

Updates to existing Operators

[ ] Is your new CSV pointing to the previous version with the replaces property?
[ ] Is your new CSV referenced in the appropriate channel defined in the package.yaml ?
[ ] Have you tested an update to your Operator when deployed via OLM?

Your submission should not

[ ] Modify more than one operator
[ ] Submit operators to both upstream-community-operators and community-operators at once
[ ] Modify any files outside the above mentioned folders
[ ] Contain more than one commit. Please squash your commits.

Operator Description must contain (in order)

[ ] Description about the managed Application and where to find more information
[ ] Features and capabilities of your Operator and how to use it
[ ] Any manual steps about potential pre-requisites for using your Operator

Operator Metadata should contain

[ ] Human readable name and 1-liner description about your Operator
[ ] Valid category name1
[ ] One of the pre-defined capability levels2
[ ] Links to the maintainer, source code and documentation
[ ] Example templates for all Custom Resource Definitions intended to be used
[ ] A quadratic logo

Remember that you can preview your CSV here.
--
1 If you feel your Operator does not fit any of the pre-defined categories, file a PR against this repo and explain your need
2 For more information see here

@J0zi thanks for the review. I fixed the missing Rule example and unchecked  "Have you selected the Project Community Operator Submissions in your PR on the right-hand menu bar?". Please see the checklist in above, thanks. I can copy it if needed.

@lionelvillard it is OK, digging deeper locally and got 2 errors:
Plugin olm-tests failed with error (failed to create cr resource: object is being deleted: invocations.ibmcloud.ibm.com "echo-invocation" already exists)
invocation failed (retrying)	{"namespace": "cloud-functions-operator-ezgcy", "name": "echo-invocation", "error": "error creating Cloud Function client Secret "seed-defaults-owprops" not found. (retrying)", "error": "error creating Cloud Function client Secret "seed-defaults-owprops" not found. (retrying)"}


HTTP2 Server Push - Feature Request

It us my understanding that okhttp is persisting pushed streams to disk, accessible through the cache and not accessible via public API. I understand the appeal of maintaining a consistent protocol-agnostic interface and the motivation to be proactive against anti-patterns (e.g. using push when it's not appropriate). With that said however, I need to receive many pushes from a 3rd-party server and writing to disk is not an option. Looking at other mainstream http2 client libraries this is usually supported via a callback mechanism. I'd be happy to volunteer time to implement this functionality, using whatever design you deem appropriate. Thanks!

Just curious – which mainstream HTTP2 client libraries were you looking at?
I’m quite reluctant to do this because it opens the door to many other HTTP/2 features that will be necessary to adequately support this. In particular you’ll likely want the connection to stay open to accept pushes.
Have you considered websockets?
BTW, we haven’t yet implemented any support for HTTP/2 push, but it’s coming.

Tracking here:
https://github.com/square/okhttp/issues/607


Unfloat action to handle focus properly

Current behavior: when unfloating a tab, it will never be the active tab after the unfloat happens.
Desired behavior: if the parent page is in focus when the user unfloats, then it should work as before. If the floating tab is in focus when the unfloat happens, the floating tab should be the active one after the unfloat action.

Won't do - there's no way to determine if the floating tab was the last focused window when the extension icon is clicked.


Export IconSpriteConfig from module

Unable to use DI to provide config(

https://github.com/jannicz/ng-svg-icon-sprite/pull/32

Thank you for your improvement! I just pushed your proposed changes.

I'm trying to inject config like so:

export function iconSpriteConfigFactory() {
  return {
    path: PathUtils.createAbsolutePath('assets/sprites/sprite.svg?v=1')
  };
}

@NgModule({
  imports: [
    IconSpriteModule,
  ],
  providers: [
    {provide: IconSpriteConfig, useFactory: iconSpriteConfigFactory}
  ]

But get an error:
Module not found: Error: Can't resolve 'ng-svg-icon-sprite/lib/icon-sprite-config.model'
Am I doing something wrong?


How to properly parse a boost::beast json response?

I have been working with Beast as an HTTP client. I am able to get the json response into the body as a dynamic_body type. However, I feel like I am missing something with the next step as I try to get that data into custom objects I have. I can convert it to a string with buffers_to_string, and then parse it, but it feels like I am missing the point of the dynamic_body (or the body type in general).
Whats the best way to parse through a json structured body response?

That depends on what your JSON parser requires as input. If it can parse incrementally, you can feed it each buffer in the dynamic body one at a time using a loop. If your JSON parser requires the entire JSON object to be submitted all at once, in a single buffer, you should be using the basic_dynamic_body<flat_buffer> type instead of dynamic_body.
Which JSON parser are you using?

I hadn't gone down that route because it seemed like I might be doing something wrong (some of your comments in other threads made it seem like there might be some kind of native ability to iterate over the response body). If that's not the case, then that also answers my question!
Thanks for the clarification.


Create: 1968-array-with-elements-not-equal-to-average-of-neighbors.py

File(s) Modified: 1968-array-with-elements-not-equal-to-average-of-neighbors.py
Language(s) Used: python
Submission URL: https://leetcode.com/problems/array-with-elements-not-equal-to-average-of-neighbors/submissions/1035102575/

Important
Please make sure the file name is lowercase and a duplicate file does not already exist before merging.

File(s) Modified: 1968-array-with-elements-not-equal-to-average-of-neighbors.py
Description: Modifed solution and with intution and description.
Language(s) Used: python
Submission URL: https://leetcode.com/problems/array-with-elements-not-equal-to-average-of-neighbors/submissions/1035160399


Complicated parameter requirements don't fit

The current widget config interface (which we are probably replacing which would make this issue moot) can't cope with complicated parameter requirements such as those for stop_timetable:

Better to use the configuration page I designed initially?
http://tfc-app3.cl.cam.ac.uk/smartpanel/layout//config/

Yes, that (or something like it) is much better. I'm still getting lost between all the various pages.
I suggest we leave this issue open until we (you) have sorted the final configuration interface.

Closed by PR #84


Fix comment generation when using other kind of linebreaks

Background

Closes #44

It was reported that when a string that is used in comments uses \r for line breaks, the generated code will incorrectly fail to prefix the line with /// resulting in non-compiling source files.
Fix
From what I could tell, the easiest way to fix this is to separate into components based on anything within the predefined .newlines CharacterSet.
It was a bit tricky to do this using firstIndex(of:) in the existing while loop, whereas it was much easier to use components(separatedBy:). However, I am wary because of this comment:
// Unlike `components(separatedBy: "\n")`, it keeps empty lines.

However when I compared the implementation, I didn't see a difference in output:

@kean, please could you confirm if I missed anything here? It looks like it works as expected using the updated approach but I might have misunderstood 🙏

I missed the mention. Yes, I just tested it and it looks like it does keep the empty lines. I'm not sure I done it this way originally.


nixos/grafana: drop insecure default secrets

Description of changes

Things done

Built on platform(s)

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

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[ ] Tested, as applicable:

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

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

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module
[ ] (Release notes changes) Ran nixos/doc/manual/md-to-db.sh to update generated release notes

[ ] Fits CONTRIBUTING.md.

Can you please explain your reasoning behind this PR?
It looks like the values we set are actually Grafana's defaults (you can check <grafana-store-path>/share/grafana/conf/defaults.ini to confirm it). So even when the PR is merged, the values will be the same in the resulting config, so that doesn't really give us any security advantage or otherwise, and I think there's an argument to be made that setting the defaults explicitly is better because the defaults become more visible.
Am I wrong?

Thats not optimal. We should drop those default credentials, too.

I'd rather not diverge with the upstream unless necessary.
How about throwing a warning if default credentials are used? I think throwing an error is way too strict, but a warning should be fine, if not a little annoying.

Well, it also breaks the tests. Sigh.

How about throwing a warning if default credentials are used? I think throwing an error is way too strict, but a warning should be fine, if not a little annoying.

No, throwing an error if insecure and publicly known default credentials for an administration accounts are used is alright.

No, throwing an error if insecure and publicly known default credentials for an administration accounts are used is alright.

The problem is, no one does that. Grafana Helm chart uses default credentials, Grafana config uses default credentials. I haven't ever gotten an error because I haven't changed the default credentials. Usually you get a warning in deployment and in docs about it, and if you didn't pay attention and deployed something to production with default credentials - it's your problem.
Aside from the fact that we'd deviate in a big way, it would also make for a poorer UX. If I can spin up a container and be done with it, why would I use a NixOS module that forces me to change default secrets without giving me a choice, and arguably forces me to do secrets management (which is not only hard, but is also not officially supported by NixOS)?
I know I wouldn't appreciate the PR merged, because I'm currently using Grafana with default credentials (it is a private service). I know that this is not the best practice, but my first priority is getting stuff done, and I'd rather not be forced to manage secrets if I can avoid it. It is a real pain.
In my opinion, the fact that spinning up a service is done in a one-liner is a huge advantage, and forcing the "proper" way is not a great solution. I am strongly against silently changing the defaults and throwing an error with default configuration. I'd rather see a warning.

We often diverge from upstream if there are good reasons like security and secure by default.

I think security should be made easy and transparent. There's a clear difference between us hardening systemd services and forcing a user to change credentials: the former doesn't require any involvement from the end user, and it's pretty well-documented and well-supported. If we can't figure out an easy to follow, easily discoverable, well-documented and in-your-face way to provision a service with the randomly generated secrets (like how, excuse me for an example from a completely different field, Argo CD Helm chart does it - then we shouldn't touch secrets at all. We don't even have a standardized way to handle secrets.

Well crap, why did I miss this, sorry :facepalm:

Usually you get a warning in deployment and in docs about it, and if you didn't pay attention and deployed something to production with default credentials - it's your problem.

People turned tons of IoT devices into a botnet by using default credentials in the past, e.g. https://en.wikipedia.org/wiki/Mirai_(malware)
To me that's a clear indicator that if default credentials exist, people will forget to change those.

I know that this is not the best practice, but my first priority is getting stuff done

If you don't care about secret management, you can still do services.grafana.settings.security.admin_password = "foobar";. Yes, it'll land in the Nix store, but it's still better than using credentials you can look up in the Internet.

the former doesn't require any involvement from the end user

well, we should involve the end-user: in the end they should alter the default credentials :upside_down_face:
However: If somebody actually wants to set the default credentials (by declaring the options manually, no defaults exist anymore) I think that we should allow it rather than erroring out @SuperSandro2000

People turned tons of IoT devices into a botnet by using default credentials in the past, e.g. https://en.wikipedia.org/wiki/Mirai_(malware) To me that's a clear indicator that if default credentials exist, people will forget to change those.

This is a problem, yes. I'd argue we don't have a good solution for that problem. I would also argue that a subpar solution would do more harm than good in this case, more on that later.

If you don't care about secret management, you can still do services.grafana.settings.security.admin_password = "foobar";. Yes, it'll land in the Nix store, but it's still better than using credentials you can look up in the Internet.

Well, you can't, actually. Not if you are using Flakes AND Git. Because then your admin password is unencrypted and (presumably) publicly available.

well, we should involve the end-user: in the end they should alter the default credentials upside_down_face

I disagree for the exact same reason you gave ealier. If default credentials exist, people will forget to change those. If the password has to be set, it will be set to an insecure password. If we care about user's security, then we shouldn't make it a user's problem to apply good security practices. Because security is ridiculously hard even for specialists: you can't expect users to make good decisions.
I think this is a much broader discussion than a simple change to one NixOS module. I think the first problem to be discussed is if we care about the user's security. If we do, then we should come up with a nice solution to provide it, such as generating a random reasonably secure password (like how Argo CD Helm chart which I've referred to earlier does it). This is currently impossible due to technical limitations, and I think those limitations should be first discussed on the organizational level.
To give a more concrete example, NixOS configs currently can be divided into 4 types: legacy + no-git, legacy + git, flakes + no-git, flakes + git. The no-git types aren't problematic: your credentials aren't public, so you don't care. legacy + git approach is a bit trickier: you can read credentials from a gitignored file. flakes + git, however, is a mess. I think it is pretty safe to say that flakes are the future, and it is my opinion that while flakes shouldn't enforce using git, there is a lot of value in doing so, both technical and, uhhh, "societal" (by that I mean, you can share configs and ask help easily, which is very valuable).
The problem with flakes + git approach is that the files that flake sees are scoped to a visible git repo: so no reading from the file outside of the git repo, no reading from a gitignored file. This means that you have to choose your poison:

Commit secrets to git unencrypted (horrible)
Run flakes with --impure, which is a hack and shouldn't be used when it can be helped
Do actual secrets management

As I already said, doing actual secrets management is hard. There is no native solution: there doesn't even exist a concept of "secrets" in Nix, actually. The closest thing we have is a passwordFile pattern, and it's a good solution, except that it is not enforced and there's no native way to take advantage of that. I believe the question of using systemd secrets is currently in discussion: that would be great, if we find a way to provision the secrets reasonably. Currently, though, I don't see Nix enforcing any secret management patterns, so I say we leave it as is until we can find out what we want to enforce and how.
Also: I don't believe there are NixOS modules that force you to change default credentials, right? It would be very inconsistent to make Grafana do that.

Because security is ridiculously hard even for specialists: you can't expect users to make good decisions.

Sorry, but to me this seems like a strawman: yes, security is hard, but we're talking about a small subset: managing secrets.
Most of the flakes-related stuff seems to be about services.grafana.settings.admin_password="foobar";. This is a bad idea anyways since it'll end up in the world-readable Nix store. To quote myself: "If you don't care about secret management". If you want to spin up an instance for testing/development/in a super-internal network then this is probably fine and noone will care.

The closest thing we have is a passwordFile pattern, and it's a good solution, except that it is not enforced and there's no native way to take advantage of that

What do you mean with taking advantage of it? Nix-based deployment tools actually provide support for secrets. And well, e.g. networkd's wireguard integration doesn't even support verbatim PrivateKeys in the NixOS config and I removed raw passwords from Nextcloud quite recently. I think we actually refuse new modules with passwords ending up in the Nix store.
@SuperSandro2000 would you agree with removing the assertions? Then it'd be fine by me.

Sorry, but to me this seems like a strawman: yes, security is hard, but we're talking about a small subset: managing secrets.

This is a pretty big subset, I would say. There is a lot of fundamentally different ways to manage secrets, and even more specific ones, for which we don't have a suggested, officially supported way.

Most of the flakes-related stuff seems to be about services.grafana.settings.admin_password="foobar";. This is a bad idea anyways since it'll end up in the world-readable Nix store.

Yes, it is a bad idea. But once again, we don't really have a model in mind that provides security both at scale and conveniently, do we?

Nix-based deployment tools actually provide support for secrets.

Except that there's no "blessed" deployment tool, so to speak. I have assumed NixOps to be one, so I tried searching the docs for it on nixos.org: NixOS manual links to the NixOps Github repo, which links to the hydra build of the NixOps manual. So the manual isn't even on the main site.
If we don't have a blessed deployment tool, then it's third-party programs with custom solutions built on top for which we don't provide official support. That itself will discourage a lot of people from trying deployment tools. And for other people we can't really provide proper support, because well, the projects are unofficial and we don't have a blessed method. And anyway, we should probably provide a NixOS-without-deploy-tool way of managing secrets if we don't make deploy tools the primary method of interacting with NixOS systems.
Basically, and I guess I sound like a broken record at this point, my problem is that we're trying to provide a DIY distro where you can do whatever you want while at the same time limiting what you can build. It is not the problem of whether the limitation makes sense or not, it is a problem of us introducing limitations as if we ship a ready product, while we do not in fact ship a ready product - we ship building blocks. Ideally, we'd ship a ready product with a lot of options to choose from, and that requires solving the problems I described.

And well, e.g. networkd's wireguard integration doesn't even support verbatim PrivateKeys in the NixOS config and I removed raw passwords from Nextcloud quite recently. I think we actually refuse new modules with passwords ending up in the Nix store.

Okay, I'll trust your experience in the subject, as I haven't had enough experience with Nixpkgs to tell the trends. If that is the case and we already make an effort to remove cleartext passwords outright, then I don't mind the PR. My primary concern with this PR in particular lies in the "error out on cleartext passwords" being inconsistent with how the modules currently are in Nixpkgs and how there's no effort to change it. If there is an effort, then sure, go for it. It doesn't fix any of the general UX problems I outlined above, but this is a more general discussion outside of the scope of this particular PR.
So, to recap: if we plan on removing cleartext passwords outright, then I think the best solution at this point would be to assert that the secrets aren't default and assert/warn to encourage using the file provider. Whichever you think is best.

@SuperSandro2000 would you agree with removing the assertions? Then it'd be fine by me.

I am not sure if the module then would error out or the default credentials are used implicitly. Either is fine for me as long as the default credentials are not used when the module is enabled.
Feel free to pick this up in the other PR since I am not sure if I have time to test this in the next days.

After thinking about it some more, I think we should be more careful with this.
Throwing an assertion on default admin password being "admin" doesn't make sense. Grafana uses it for first run and prompts the user to change the password immediately after logging in as admin. Afterwards, the password is stored in the database securely. The settings only really matters for the first run, so it's no biggie if we leave it as default: it's actually better that way, since it's familiar.
Now, the fun part. The secret_key part. If I'm reading this right, not only would we have to force users to generate a AES-256 CBF key, we'd also have to force them to re-encrypt data keys. And while docs say you CAN change the KEK, I can't find any info on how that should be done. This sounds like "you can change KEK from local to KMS", especially considering that KMS guides instruct you to leave secret_key as is to decrypt existing secrets.
Basically, what I'm trying to say is, I am very not confident in "KEK local -> local migration" being a feature that Grafana supports. I haven't found examples, haven't found guides, haven't found commands for that in CLI, haven't found API endpoints .
I am urging somebody with a little more know-how to take a look at this, because the worst-case scenario looks like "I'm right, the PR is merged anyway". That way we'll force our users to go through a migration procedure only to find out that their secrets are now all encrypted, and they can't roll back to the default encryption key because our module doesn't let them do it anymore.

I think it's also important to resolve this before 22.11, self-assigning.

I think it's also important to resolve this before 22.11, self-assigning.

Could you please test the whole "local migration to another KEK" thingie I've outlined earlier? If that's not possible, I doubt there's anything we can actually do with this PR.

Read it, will take a look when I get to it. That's what I meant with "resolving" this (no matter whether we actually can or cannot ;-) )

OK, so as promised, I read your comment (having a bit time atm) and in this case I agree with you (note: I still disagree with the opinions about secret handling in general we discussed earlier, but that's out of scope here, though an interesting topic. Perhaps we can discuss about that at the next NixCon ;-) )
To summarize:

the fact that Grafana forces you to change the default password on the first install makes the issue pretty harmless.
considering that we already had the behavior of the secret_key before (I'm pretty sure at least) and changing that seems to be quite a pain, let's keep it that way. I mean, we have the JSON stuff placed into a state-directory (a mechanism where dozens of other applications persist their secret stuff), so it's relatively safe (in contrast to storing e.g. db passwords in the store). I don't really understand, why Grafana did this in the first place, if there's a default key, but let's keep it that way then :shrug:


qutebrowser: make gstreamer and pdfjs configurable

Motivation for this change
PDF.js and gstreamer are optional dependencies in other distros.
I added two options to control these but kept the same behavior by default.
Also a small refactor.
Things done

[x] Tested using sandboxing (nix.useSandbox on NixOS)
Built on platform(s)

[x] NixOS
[ ] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[x] Tested compilation of all pkgs that depend on this change using nox
[x] Tested execution of all binary files
[x] Fits CONTRIBUTING.md.

@GrahamcOfBorg eval
(sorry, an issue was introduced in to master which has since been fixed)

I rebased the branch


Spinnaker Integration

Integrate Ortelius into Spinnaker as part of the CI/CD process.

Need to create an Ortelius Spinnaker plugin for capturing configuration, deployment data and relationships for visualization in the Ortelius UI.  Spinnaker Plugin Guide.
Configuration Data:

Field
Description

Build Job
The Continuous Delivery Build Job that is used to build/compile the Component.

Last Build Number
The number of the last Continuous Delivery (CD) Workflow that created the files referenced within the Component. This number will default to the Build ID if one is not set by the CD Workflow.

Build ID
The internal identifier for the Build Engine.

Build URL
The URL to the Build Engine.

Build Date
The timestamp from when the last build job was run.

Helm Chart
The Helm Chart used to deploy the Component.

Helm Chart Version
The Helm Chart Version from the Helm Repository.

Helm Chart Namespace
The sub-division of the Kubernetes cluster where your Component Container should run.

Operator
The RedHat Operator used to deploy your Component container.

Container Registry
The Container registry where the Container is stored.

Container Digest
The SHA number of the Container image.

Container Tag
The tag that was assigned to the Container image.

Git Commit
The Git SHA number. Populated when integrated into Continuous Delivery Pipelines.

Git Repo
The Git Repository that triggered the build.Populated when integrated into Continuous Delivery Pipelines.

Git Tag
The last tag for the Git Repository. Populated when integrated into Continuous Delivery Pipelines.

Git URL
The URL for the Git Repository.Populated when integrated into Continuous Delivery Pipelines.

Deployment Data:

Field
Description

Application Version
Version of the application deployed

Environment
Name of the environment that the application was deployed to

Endpoints
Endpoints in the environment that were updated by the deployment

Relationships:

Field
Description

Application Version
Version of the application

Components Versions
Component versions that belong to the Application Version

Need to create an Ortelius Spinnaker plugin for capturing configuration, deployment data and relationships for visualization in the Ortelius UI.  Spinnaker Plugin Guide.
Configuration Data:

Field
Description

Build Job
The Continuous Delivery Build Job that is used to build/compile the Component.

Last Build Number
The number of the last Continuous Delivery (CD) Workflow that created the files referenced within the Component. This number will default to the Build ID if one is not set by the CD Workflow.

Build ID
The internal identifier for the Build Engine.

Build URL
The URL to the Build Engine.

Build Date
The timestamp from when the last build job was run.

Helm Chart
The Helm Chart used to deploy the Component.

Helm Chart Version
The Helm Chart Version from the Helm Repository.

Helm Chart Namespace
The sub-division of the Kubernetes cluster where your Component Container should run.

Operator
The RedHat Operator used to deploy your Component container.

Container Registry
The Container registry where the Container is stored.

Container Digest
The SHA number of the Container image.

Container Tag
The tag that was assigned to the Container image.

Git Commit
The Git SHA number. Populated when integrated into Continuous Delivery Pipelines.

Git Repo
The Git Repository that triggered the build.Populated when integrated into Continuous Delivery Pipelines.

Git Tag
The last tag for the Git Repository. Populated when integrated into Continuous Delivery Pipelines.

Git URL
The URL for the Git Repository.Populated when integrated into Continuous Delivery Pipelines.

Deployment Data:

Field
Description

Application Version
Version of the application deployed

Environment
Name of the environment that the application was deployed to

Endpoints
Endpoints in the environment that were updated by the deployment

Relationships:

Field
Description

Application Version
Version of the application

Components Versions
Component versions that belong to the Application Version

The Ortelius CI/CD CLI can be used for this. No custom plugin is now needed.  See https://docs.ortelius.io/guides/userguide/integrations/ci-cd_integrations/


added function call capability and minor fixes

added function call capability to chat completion by changing 'content' property from string to dynamic to account for content being null when using function calling also fixed chatCompletion and stream examples to properly show how role must be defined. (OpenAIChatMessageRole.user and not "user")

Hey, I created PR https://github.com/anasfik/openai/pull/70 that adds a bit more robust interface for this instead of making the response dynamic.


Eco system with/without considering wind force and moment in MMG 3DOF simulation.

Even if wind force and moment are not considered, we should input some information of wind for simulating MMG.
This is really bothersome for users.

#59 #60 #61


【RFC】Wechaty support middleware.

问题
Wechaty 已经开发过 plugin 机制，参考：

https://github.com/wechaty/wechaty/issues/1939

但 plugin 的粒度还是相对较粗，导致不同的 plugin 之间还是存在许多重复代码。
以 vote-out 插件为例，假设我们有个需求，需要写个 vote-up 来记录每天群内谁被点贊最多，此时就会发现 vote-out 的所有过滤代码都得原封不动的拷贝至 vote-up 中，然后再完成 vote-up 的真实逻辑。
所以根本原因是 plugin 中的逻辑无法被更小粒度的抽象和复用，
思考
很早之前也粗略的思考过这里的问题，但改造成本较高，且与历史API存在兼容性问题，但最近又思考了一下，发现还是可以解决的。
可以扩展一种针对事件维度的 middleware 机制（洋葱模型）进行更小粒度的抽象。
示例代码如下
在现有模式下，如果要完整类似功能，需要这么写。
// room a 需要 vote-out 功能
bot.on('message', async (message) => {

  const room = message.room()

  if (!room) return
  if (message.type() !== type.Message.Text) return
  if (!matchers.roomMatcher('room a')) return

  console.log('do vote-out action');
});
// room b 需要 vote-up 功能
bot.on('message', (msg) => {

  const room = message.room()

  if (!room) return
  if (message.type() !== type.Message.Text) return
  if (!matchers.roomMatcher('room a')) return

  console.log('do vote-up action');
});

设计事件维度中间件能力后，可以这样写。
// 抽象通过能力为中间件，由中间件控制事件响应
const filterMiddleWare = (options) {
  return async (message, next) => {

    const room = message.room()

    if (!room) return
    if (message.type() !== option.type) return
    if (!matchers.roomMatcher(option.room)) return

    await next();
  }
}

// 只有 room a 中会响应, vote-out 事件
bot.on('message',
  filterMiddlerWare({ type: type.Message.Text, room: 'room a'}),
  (message) => console.log('do vote-out action')
);

// 只有 room b 中会响应, vote-up 事件
bot.on('message',
  [ filterMiddlerWare({ type: type.Message.Text, room: 'room a'}) ],  // support middleware array.
  (message) => console.log('do vote-up action')
);

对于现有插件，我们也可以扩展 use 方法在执行前去装载中间件
// VoteOut 插件只对 room a 生效
bot.use(VoteOut({ /* options */ }), { message: [ filterMiddleWare({ room: 'room a'}) ] })

这样，就能无缝的兼容原来的 API 和 插件能力啦 。
未来插件也可以做得更轻，只专注于功能本身，而不用去写一堆的 if (xxxx) return 啦。
而同时，插件本身也可以通过拼接一堆  middleware 来完成一个大的功能插件。
变更
on (event: WechatyEventName, listener: (...args: any[]) => any): this
on (event: WechatyEventName, middlewares: WechatyMiddleWare | WechatyMiddleWare[], listener: (...args: any[]) => any): this

use(...plugins, option: WechatyPluginMiddleWare);

Related issues

https://github.com/websockets/ws/issues/1818

Recently I'm reading the W3C native supported (standard) EventTarget, which is the browser version of the EventEmitter, and they both have very similar (compatible) API interfaces.
What attracted me the most is, the event.preventDefault() feature of the EventTarget.
As we know the EventEmitter listeners can only control what happens inside itself, and it can not prevent the listener chain to continue.
But the EventTarget can call the event.preventDefault() to stop all the listeners after the current one.
I'm thinking about switching from EventEmitter to EventTarget because of this feature.
@Gcaufy What do you think?

We'd better not to stop events inside one event, because there is no way to reuse the event stopped by other events.
For example
// I need to write code `Only print apple in room-a`
bot.on('message',  (message) => {
  if (/* room is room-a */) {
    // continue;
  }
  // If it's not room-a, then stop all other events
  event.preventDefault();
}

// This works prefect as what we expected.
bot.on('message', (message) => {
  console.log('apple');
});

// BUT, things changed, I need to print banana to all the other rooms, include room-a
bot.on('message', (message) => {
  console.log('banana');  // This won't work, because the other events was stopped, and no way to reuse it.
});

So, if we need to make it right, we need to move the 3rd event to the top, which means we need to be starkly aware of the event sequence.
We could barely to this if the code is quite complicated.
Especially, if we are using many plugins (which has event.preventDefault() inside), plugins interfere with each other, different   use sequence getting different results.
So in this case, I think EventEmitter is better than EventTarget.

I have been thinking about the Middleware proposal for the past few days and I must say this is a brilliant design. Thank you very much @Gcaufy!
I think basically the whole middleware design is good, we definitely can move forward based on that.
Below is some of what I thought about this design:

Can we reuse the wechaty.use() method to also support the middleware? My idea is: the middleware will have more than one (>1) function arguments (like: middleware(...args: any[], next: Function), but the plugin will only have one (=1) (which is plugin(wechaty: Wechaty)). Maybe we can use the Function arguments signature to differentiate them.
In the design, I saw that each middleware needs to bind to one Wechaty event, and I understand that. For example, a middleware is dealing with message, and another is dealing with friendship. Can we encapsulate this event name inside the middleware, instead of specifying the name outside? For example, it would be more simple if we can rewrite the below code:- bot.use(VoteOut({ /* options */ }), { message: [ filterMiddleWare({ room: 'room a'}) ] })
+ bot.use(VoteOut({ /* options */ }), filterMessageMiddleWare({ room: 'room a'}))

I feel each Wechaty event listener is a special middleware that has no next to call. If so, can we generalize the middleware definition for Wechaty listeners? What I think about is: can we simply treat all listeners as middleware?
The on()/addListener() method: those methods are extended from the EventEmitter from Node.js, which I think we should keep their call signatures not changed as possible as we can. So in order to support middle, we might need a factory method, to compose the middleware and the listeners together, then we can use the returned function as a listener, to register with on() and addListener(). for example:bot.on('message', middlewareListener(
  filterMiddlerWare({ type: type.Message.Text, room: 'room a'}),
  (message) => console.log('do vote-out action'),
))

The last one: do you think we need to add a context argument (it can be this) to our middleware? I think we should have some kind of context because it can deliver a message between middleware, and it is essential. We have some options, for example:

this as context: the middleware function will have a this as its context (what should be its initial context schema?)
add a context args as the first argument. (looks verbose?)
other possibilities?

The above is what's in my head now, would love to hear any feedback, and let's push this RFC design move forward together.

作为 .NET 平台上的开发者，我建议参考 ASP.NET CORE middleware 的设计
从使用者的体验角度来说设计成如下风格，中间件采用洋葱模型
//添加全局 middleware
bot.messages
     .use(middleware1)
     .use(middleware2)
//添加指定筛选的 middleware
bot.messages
     .where(filter)
     .use(middleware3)
     .use(middleware4)

middleware 的效果类似于如下签名的函数
//其中 next 代表下一个管道，可以决定是否继续执行下一层
handler(context, next) :Promise

实际编写的时候可以如下面的效果：
bot.messages
     .use(async (context, next) -> {
        console.log("global middleware 1")
        await next(context)
     })
     .use(async (context, next) -> {
        console.log("global middleware 2")
        await next(context)
     })
     .where(message->message.room()=="a")
     .use(async (context, next) -> {
        console.log("middleware 3 with filter")
        await next(context)
     }).use(async (context, next) -> {
        console.log("middleware 4 with filter")
        await next(context)
     })

以上代码中的 where 类似于 ASP.NET CORE middleware 的设计 中的Branch the middleware pipeline例子里面的Map。

作为 .NET 平台上的开发者，我建议参考 ASP.NET CORE middleware 的设计 从使用者的体验角度来说设计成如下风格，中间件采用洋葱模型
//添加全局 middleware
bot.messages
     .use(middleware1)
     .use(middleware2)
//添加指定筛选的 middleware
bot.messages
     .where(filter)
     .use(middleware3)
     .use(middleware4)

middleware 的效果类似于如下签名的函数
//其中 next 代表下一个管道，可以决定是否继续执行下一层
handler(context, next) :Promise

实际编写的时候可以如下面的效果：
bot.messages
     .use(async (context, next) -> {
        console.log("global middleware 1")
        await next(context)
     })
     .use(async (context, next) -> {
        console.log("global middleware 2")
        await next(context)
     })
     .where(message->message.room()=="a")
     .use(async (context, next) -> {
        console.log("middleware 3 with filter")
        await next(context)
     }).use(async (context, next) -> {
        console.log("middleware 4 with filter")
        await next(context)
     })

以上代码中的 where 类似于 ASP.NET CORE middleware 的设计 中的Branch the middleware pipeline例子里面的Map。

这个是 middlewares 本来应该有的样子，完全赞同。
但是当前事件消息完全基于 EventEmitter 的，这样设计可能会完全重构，成本非常高。

另外一个想法： Plugin can be a type of middelware.
初衷
你设计middleware的初衷就是：plugin 的粒度还是相对较粗，导致不同的 plugin 之间还是存在许多重复代码。
那我就想，我们只需要解决plugin的代码复用性的问题就行了，这个时候我想解决办法有很多种，其中的一种就是让插件之间存在一定的有向拓扑依赖关系，然后在wechaty启动的时候就编译成一个plugin tree，同一个tree level的plugins可以并行emit，不同level之间需要同步执行。
草图

simple code
from typing import List, Any

class Plugin1(WechatyPlugin):
    def __init__(self):
        self.plugin_global_variables: Any = {}
        self.plugin_conversation_variables: Any = {}

    def do_something(self):
        pass

class Plugin2(WechatyPlugin):
    def __init__(self):
        self.plugin_global_variables: Any = {}
        self.plugin_conversation_variables: Any = {}

    def do_another_thing(self, data: Any):
        pass

class Plugin3(WechatyPlugin):
    pass

class Plugin4(WechatyPlugin):

    def dependencies(self) -> List[WechatyPlugin]:
        return [Plugin1, Plugin2]

    def customized_func(self):
        plugins = self.get_dependency_plugins()
        plugin1: Plugin1 = plugins[0]
        plugin2: Plugin2 = plugins[1]

        result = plugin1.do_something()
        # but plugin2 don't require plugin1
        plugin2.do_another_thing(result)

Can we reuse the wechaty.use() method to also support the middleware? My idea is: the middleware will have more than one (>1) function arguments (like: middleware(...args: any[], next: Function), but the plugin will only have one (=1) (which is plugin(wechaty: Wechaty)). Maybe we can use the Function arguments signature to differentiate them.

同意使用 use， 但是目前代码 plugin 也是支持多个参数的，所以可能不太好作区分，除非直接改掉，不向下兼容了。

I think there should be some way to know them at some point...
function use (fn: Plugin | Middleware) {
  if (fn.length === 1) {
    fn(this) // <- this is plugin, expecting one arg: wechaty
  } else if (fn.length === 2) {
    fn(context, () => {}) // <- this is middleware
  } else {
    console.error('what fn I have got?')
  }
}

Should we support removing middleware/plugins after they have been installed?

uninstall a middleware?
uninstall a plugin?

Currently, once a plugin or middleware has been installed, there's no way to remove it.
So does the Express middlewares.

function use (fn: Plugin | Middleware) {
  if (fn.length === 1) {
    fn(this) // <- this is plugin, expecting one arg: wechaty
  } else if (fn.length === 2) {
    fn(context, () => {}) // <- this is middleware
  } else {
    console.error('what fn I have got?')
  }
}

Please correct me if I have missed anything.

It make sense, but

Normally plugin have 1 argument, and middlewares have more, but If user use js, he can pass less arguments or more.
They both use use, will it make user confused, the arguments logic is only in the code, how does user recongnize that.

How about we use install for plugins, and use use for middleware

Are we sure to use Context instead of use expanded arguments? If yes, then what's in it? simply put everything in it?.
I still prefer to use expanded arguments.

Context is using for request, because every request would have Req and Resp etc.
But in EventEmitter, different event have diffrent paramter.
In this case, it would Be MessgeContext, FriendShipContext, etc.

As you said, the event listener also can be a middlerware. So that means the listener should have the same arguments with middleware.

@huan Please check the comments so that I can continue :0)

Dear @Gcaufy ,
Thank you very much for pushing this RFC forward, it's a great design, so please go ahead with the PR and make the CI green, then we start discussing based on the draft code, and run some example code based on your new code and test the user experiences for developing.
This week I'm mainly working on the below PR, will back to you after I have finished it:

https://github.com/wechaty/ha/pull/11

Below are some of my options to our previous question:
Typing change of on()  & use()
I believe your original designs are in the right direction. Please update when necessary, and let's follow this design for our middleware draft design.
on (event: WechatyEventName, listener: (...args: any[]) => any): this
on (event: WechatyEventName, middlewares: WechatyMiddleWare | WechatyMiddleWare[], listener: (...args: any[]) => any): this

use(...plugins, option: WechatyPluginMiddleWare);

Question: how to deal with room-invite (and some similar to it) event?
The room-invite event has more than one argument:
https://github.com/wechaty/wechaty/blob/771a7196e981ef483e55819c461629b3bda5f8e3/src/schema/room-events.ts#L100-L104
How do we define a middleware for it?
One middleware interface for all event types?

In the design, I saw that each middleware needs to bind to one Wechaty event, and I understand that. For example, a middleware is dealing with messages, and another is dealing with friendship. Can we encapsulate this event name inside the middleware, instead of specifying the name outside? For example, it would be more simple if we can rewrite the below code:
意思是 middleware 同时返回 eventname 和 function 吗？最初我也这么想过，但考虑到限制死了 middleware 只能用过这个 event了， 所以还是放在外面声明了。比如说， 有个 middleware 在 message 和 friendship 上面都可以用。那该如何去复用呢？

Could you please provide an example middle that "在 message 和 friendship 上面都可以用"?
After I think it more, maybe we can also consider that one middleware only deals with one event type?
The context

Context is used for requests because every request would have Req and Resp etc.

I'm always thinking about that, the interaction between the chatbot and the user is very similar to the Web server and the user., because as you said: "every request would have Req and Resp", the conversation between the chatbot and user have Turn (a concept from BotFramework) for a question/answer (request/response), and the bot needs to store information between turns, which needs a context to store those pieces of information, and BotFramework has a TurnContext for that.
However, as our listener functions will have a this: Wechaty, I believe we can use the wechaty.memory to store that information. If we use wechaty.memory as the context of the turn, then we do not need to do anything additionally.
wechaty.memory is a MemoryCard instance with a ES6 Map like API in Async.

@Gcaufy   Hello, are you still following this issue? This problem is also bothering me.


rephrasing of the note message

@pipposera : Thanks for your contribution! The author(s) have been notified to review your proposed change.

Looks good, signing off in Pat's absence. #sign-off

@sethmanheim: I'm sorry - only the author of this article, @PatAltimore, can sign off on your changes. But we do have an exception process - if you are on the Microsoft content or product team for this product area, you can ask the PR review team to review and merge it by sending mail to the techdocprs alias.


uncomment link tests

What is the purpose of this change? What does it change?
I validated the link command with the latest master, and it was working for me while running manually on my Linux machine across dev cluster, raise this PR to validate it on CI
./odo version
odo v0.0.20 (22b306d2)

Server: https://devtools-dev.ext.devshift.net:8443
OpenShift: v3.10.0+e3465d0-44
Kubernetes: v1.10.0+b81c8f8

Was the change discussed in an issue?
fixes #???
https://github.com/openshift/odo/issues/1492
How to test changes?

We will have to wait / are blocked on https://github.com/openshift/odo/pull/1535 right @kadel ?
For https://github.com/openshift/odo/issues/1492 @syamgk I believe we should make sure that it works correctly / you're able to successfully create a url.
Another thing that is missing is --context (I will comment on the issue too).

Closing this since it make no sense to fix the old test, so rewriting link related tests w.r.t the new workflow
raised a new PR here https://github.com/openshift/odo/pull/1580


Rails 3.2 fixes

TODO: this test is broken https://github.com/plataformatec/devise/blob/master/test/integration/trackable_test.rb#L40

Looks like Rack 1.4.0 does a IP spoofing protection, so we have to add this to this test to pass:
     sign_in_as_user do
+      header "HTTP_CLIENT_IP", arbitrary_ip
       header 'HTTP_X_FORWARDED_FOR', arbitrary_ip
     end

This protection didn't exists on Rake 1.3.5.
@josevalim, @carlosantoniodasilva any thoughts? I don't know a better solution than forcing the HTTP_CLIENT_IP

If we use a not local network IP in the HTTP_X_FORWARDED_FOR the test pass too

@josevalim how I fix this test? Setting the HTTP_CLIENT_IP or using a no local network ip?

I think that is fine to merge now


refactor: use InjectionTokens

:tada: This PR is included in version 7.2.1 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:


Suggestion to open discussions / poll for new language integration

Hey @SWivid,
first of all, thanks for publicly releasing such a groundbreaking tool, F5-TTS is nothing short of incredible!
I've seen many closed issues where people is asking about new languages. From what I could gather, you seem open  to the idea of introducing more languages yourselves.
So I'm here to ask if it's possible to open the GitHub discussions space for this repo. That way you could have a poll there, to take the pulse of the community in regard to which languages are the most sought after - and thus unburdening the issues section from these type of requests (and more to come).
Thanks for the awesome work.

Yes, we have just opened the discussion space ~


Draft: Move pylance to come from npm

This is a draft at the moment. Not sure how to try out the setup authoring just yet.

Submitting this to see if this will run with the token on a subsequent submission


Bump version to 3.2.1

Changelog: https://github.com/gnosis/gnosis-py/compare/v3.2.0...bump-version-3-2-1

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

0 of 0   changed or added relevant lines in 0 files are covered.
1 unchanged line in 1 file lost coverage.
Overall coverage decreased (-0.04%) to 89.417%

Files with Coverage Reduction
New Missed Lines
%

gnosis/eth/ethereum_client.py
1
82.74%

Totals

Change from base Build<PHONE_NUMBER>:
-0.04%

Covered Lines:
2256

Relevant Lines:
2523

💛  - Coveralls


Is there a way to make ovs-cni as the master network with different vlans

It's easy to make ovs-cni as the master network with  or without one vlan tag. It's also possible for me to make two ovs vlans  with NetworkAttachmentDefinition ,  and each pod has one of the vlans  as the second network with multus plugin.
However,  there a  case is that two pods use ovs-cni plugin as master network with different ovs vlan tags .  Dose the ovs-cni support this  scenario. If  so, is there a guide availeble for me?
Thanks!

Ok, I  find a way with multus


[Synapse] Resolve the breaking changes introduced by swagger update

Contributing to the Azure SDK
Please see our CONTRIBUTING.md if you are not familiar with contributing to this repository or have questions.
For specific information about pull request etiquette and best practices, see this section.

API change check
APIView has identified API level changes in this PR and created following API reviews.
Azure.ResourceManager.Synapse

Close this one as the change has been merged.


boards: arm: Add ubx_evknorab10_nrf5340 support

Add support for u-blox EVK-NORA-B100 and EVK-NORA-B106
which use the nRF5340. .
This board is functionally equivalent to the nRF5340dk_nrf5340.
Tested with blinky, button, and Bluetooth peripheral_hr
Signed-off-by: Bob Recny<EMAIL_ADDRESS>

Hi all, just checking on status. Thanks!

@ioannisg, @nashif, @MaureenHelm, @galak
Hi again. Just curious when this PR might be reviewed. I have a couple more in the works based on the nRF5340 and wanted to get this one approved first.
Thanks!
Bob

Found a small error in nrf5340_cpunet_reset.c - updated.

Just checking in again. It's been some time since the PR was created.

Hi @nashif, @ioannisg, @MaureenHelm, @carlescufi, @galak,
Just checking status.
Thanks,
Bob

Hi @nashif, @ioannisg, @MaureenHelm, @carlescufi, @galak,
Just checking status.
Thanks,
Bob

@MaureenHelm, Thanks - rebased now.

I'm going to close this PR, regroup and resubmit after getting the board submitted to trustedfirmware.org. It may be a few more weeks until my schedule frees up to do so.
My fork of Zephyr has also not been kept current and I'm seeing some strange documentation build errors every day. Evidently, I have other things to sort out first.


Support pluggable EventLoop task queue

The default task queue used by EPoll and NIO EventLoop implementations is provided by JCTools, and while it is efficient it has some undesirable properties.  Specifically, it is not non-blocking, and can lead to the EventLoop busy-spinning waiting for a task that may not be provided promptly because the offering thread's execution has been suspended by the operating system.  This is a rare scenario, but it will happen and some application maintainers might like to avoid it.
Unfortunately, there is no simple fix in the use of the queue; the relaxedPoll() method appears to be a candidate, but does not provide volatile visibility guarantees to a preceding offer(), meaning a wakeup could be missed (although we could write to a dummy volatile variable after offering to provide this).  A queue identical to the JCTools one but using a putVolatile to set the item in the queue's backing array would suffice to avoid the busy-spin blocking of the EventLoop, but the issue of future tasks being unreachable until the thread completes would remain.
Ideally, the queue used by these event loops would be pluggable, so that users can choose their ideal point on the spectrum of tradeoffs.
A simple replacement that guarantees progress is the JDK ConcurrentLinkedQueue, but at the cost of slightly more expensive offer() and poll(); the above mentioned modification to the JCTools offer() could be mixed with relaxedPoll() to simply avoid busy-spin blocking, and a custom Mpsc queue implementation could guarantee forward progress with only marginally higher cost.  Permitting the application maintainer to pick their poison would be tremendously helpful.

@nitsanw FYI...

AFAIK the only misbehaviours could happen by using offer of a single-producer JCTools queue or just relaxedPoll instead of poll.
The first one seems not the case here, while on consumer side just using a mix of relaxedPoll()/drain() with poll()/isEmpty() is enough to guarantee strict empty recognition a-la CLQ.
IMO just using poll() could be a simple fix that would force a JCTools queue to use the same semantic of CLQ::poll.

@franz1981 I'm afraid I don't quite follow what you're saying, but we currently do use poll() and this has the problems I describe.
However, I have just taken another look at wakeup(), and since we always perform a compareAndSet, we actually could use relaxedPoll to solve the busy-spin issue.  However, we probably shouldn't be doing an unconditional compareAndSet, since this is costly - it should ordinarily be guarded by a cheap test of its current value.

@belliottsmith when you say we should guard you think of doing something like this:
if (!inEventLoop && !wakenUp.get() && wakenUp.compareAndSet(false, true)) {
    selector.wakeup();
}

?

@belliottsmith
The poll() always return null if there is no pending offering and the only spinning I'm aware of in JCTools is while awaiting the message slot to be filled by the producer (because JCTools offer happen in 2 stages: producer sequence increment AND message slot fill).
If the event loop logic fall into a spinning i don't see how it can be related to JCTools unless:

the queue used is single producer
the event loop logic that perform the sleep/awake is not correct

I think that the awake logic could use a different strategy too, that would avoid using compareAndSwap on offer side: https://github.com/JCTools/JCTools/blob/master/jctools-experimental/src/main/java/org/jctools/queues/blocking/ScParkTakeStrategy.java#L19

@normanmaurer right

@franz1981 the two stages are not atomic, and a thread can be suspended by the operating system in between these two steps

@belliottsmith Correct: that means that you would likely to see a spin into the queue::poll call: that's the issue you're seeing?

@belliottsmith I think I would even argue that we may not need the CAS at all and could just use a volatile. At worse we would call wakeup multiple times. That said maybe just add a get before is good enough as a failed CAS should be at least cheaper then an extra selector wakeup. WDYT ?

@normanmaurer I think the get + CAS is probably safest for now, the problem being the negotiation between the consumer resetting it to false before going to sleep, and a producer seeing the true before this happens and failing to prevent it going to sleep.  It would be possible to avoid a CAS here, but it would require a bit more complex surgery and thought to modify all of the places we actually go to sleep.  On modern chips a CAS isn't so costly anyway, and probably less costly than actually triggering the wakeup (though I don't know how actually costly this is, the code comments suggest it is costly) - it might be something to consider for 5.0 as part of wider refactors, but doesn't intuitively feel like it fits the risk/reward tradeoff for 4.x to me.

@belliottsmith @normanmaurer I think this can be closed now that #9247 is merged?

@njhill yes!

@belliottsmith "Specifically, it is not non-blocking, and can lead to the EventLoop busy-spinning waiting for a task that may not be provided promptly because the offering thread's execution has been suspended by the operating system." - I assume you are referring to the following:
https://github.com/JCTools/JCTools/blob/58a08a14928ca966d55543d3e4f6f40a44a65518/jctools-core/src/main/java/org/jctools/queues/BaseMpscLinkedArrayQueue.java#L265
            if (casProducerIndex(pIndex, pIndex + 2))
            {
                break;
            }
        }
        // INDEX visible before ELEMENT
/* Producer thread is suspended here */
        final long offset = modifiedCalcElementOffset(pIndex, mask);
        soElement(buffer, offset, e); // release element e
        return true;

If this happens the consumer thread will spin-wait for the element to appear in poll():
        Object e = lvElement(buffer, offset);// LoadLoad
        if (e == null)
        {
            if (index != lvProducerIndex())
            {
/* index is visible, but element is not visible until the producer is able to make progress */
                do
                {
                    e = lvElement(buffer, offset);
                }
                while (e == null);
            }
            else
            {
                return null;
            }
        }

This makes the queue blocking. What is worse, successful offer calls from other producers cannot overtake the "stuck producer" and the consumer cannot attend to them (I've always thought of this as a bubble in the queue). The producers can make progress, but the consumer can't skip ahead and deq the items until the "stuck producer" releases it.
If this is the issue under discussion, I'm not sure what the following suggestion means: "A queue identical to the JCTools one but using a putVolatile to set the item in the queue's backing array would suffice to avoid the busy-spin blocking of the EventLoop"
The problem is that the index is visible before the element. Making the element "more visible" (by using a stronger barrier) will not make a difference. The index and the element are not atomically published (as @belliottsmith points out later). Using CLQ will provide better progress guarantees here AFAIK (IIRC the node is only published when fully initialized, so the "bubble" in the queue cannot happen) and I think the feature request is sensible.

@belliottsmith @franz1981 reading through the discussion and the java doc I realize JCTools should do a better job documenting the progress guarantees on this and other queues. I've file a bug: https://github.com/JCTools/JCTools/issues/259

If this is the issue under discussion, I'm not sure what the following suggestion means: "A queue identical to the JCTools one but using a putVolatile to set the item in the queue's backing array would suffice to avoid the busy-spin blocking of the EventLoop"

It means the eventLoop (by using relaxedPoll()) would at least be able to proceed with other work such as reading/writing to a socket, or could stop if it had no other work to do, freeing up a thread for the producer to complete its work.
Obviously a preferable solution is to use a truly non-blocking queue, but blocking the eventLoop is worse than just blocking the external work queue.

I was referring in particular to: "using a putVolatile to set the item in the queue's backing array would suffice to avoid the busy-spin blocking of the EventLoop".
I agree that using a relaxedPoll will return control to the EventLoop, giving you more options in how to utilize time until an element is visible. I don't see how putVolatile makes a difference here.
Thanks.

Well, in combination with #9109 you might appreciate my reasoning.  Long story short, it depends on the behaviour of the code that wraps it to provide blocking behaviour.  putVolatile instead of putOrdered would permit negotiating if a wake-up is not necessary with only LoadLoad barriers.  However, today, Netty imposes a full CAS in each side of that transaction, so it wouldn't actually be necessary.
(It's been a while since I had the context to think about this, so I may bow out of further discussion for now, as I don't really have time to re-research my answers/thoughts)

Reading through the discussion, I understand you have some reservations regarding the semantics/guarantees of JCTools queues, but I can't see how they add up to anything actionable.
If you have a concern with a particular detail please file a bug with JCTools and I'll be happy to address it.
Making the element write a volatile write makes no difference to either ticket AFAICT. It imposes further ordering constraints on the offer, which are irrelevant to the offer and do not help the poll code where these tickets seems to focus. The offer method as a whole already has volatile write semantics (in this implementation) due to the successful CAS operation.

I have no concerns about the semantics, that would imply I thought they were overall problematic.  Every concurrent structure's semantics matter only in the context they're used.
IMO, this project should be using a truly non-blocking queue, but that doesn't mean the algorithm employed by JCTools is of general concern.

"IMO, this project should be using a truly non-blocking queue" - The trade offs are between higher per-element costs (allocation + barriers) and the JCTools option which is lock-less but still risks blocking. The configurable queue impl solves this issue and offers choice, so I think this is solved.
"I consider the default spin-lock blocking behaviour to be a bug" - Would you prefer to put a yield in the loop instead? If you have suggestion I'm happy to hear it.

Given that a relaxed poll can return NULL either due to emptiness and a "not yet" published element I believe that it can be improved by make these 2 cases explicit and let a user to choose what to do while awaiting element publication, but it would mean an additional xxxPoll method: it could be useful, but most JCtools users love and uses it because qs are "kinda" replacement for j.u.c. queues and I'm not sure that Netty would love to be bounded to use MessagePassingQueue API instead of the more general java Queue one.

I've been down enough of these rabbit holes to know any answer will only lead to another, so I hope you don't mind if I bow out for real for now.  I only provided that qualifier as a post-script because I felt I had been dishonest by disclaiming any concerns about JCTools in response to your claim I had expressed general concerns (which I do not feel I had, I was only discussing their semantics in the context of this project).  JCTools is a great library, that you should be proud of; it would be surprising if nobody had any concerns or criticisms.  Perhaps we will have some time to discuss them in person one day.

"JCTools is a great library, that you should be proud of" - Thanks :-)
"it would be surprising if nobody had any concerns or criticisms." - Indeed, and I am keen to address these concerns where I can. So please, if possible, make time to submit issues if appropriate. Even if they remain unresolved they will be informing other users of the risks/rewards/tradeoffs/decision making etc.
Thanks for your time, I hope we have an opportunity to discuss in person in the near future.


Kill old logError calls and replace with spdlog call

This is inherited from HP, but log-aggregation won't work nice with it.

Fixed here: 1d0215a89c0d7777bf8587987c392fa61f02fb0d
Will be merged with more_recorder_fixes branch.


Pi Zero W

Has anyone tried doing this on a pi zero w? I think my build might benefit from having the smaller form factor of the pi zero- I can fit a small speaker inside the frame so it can also play music via bluetooth (I'm going to be lazy and use the speaker's built-in bluetooth instead of programming it into the Smart-Mirror to display what song is playing. I do not have the skills or know-how to pull that off at this time).
I think the pi zero W should have no problem handling the Smart-Mirror software. I just don't want to drop a couple extra bucks on it when I already have it working on my pi3.

Yes I can confirm that this does work. See the Image

I as well have a Pi Zero but it is not working on mine.


[K8s][Helm] Redis Software Update

This pull request implements the deployment of Redis in Kubernetes using a Helm chart. Thoroughly tested for Redis by checking the logs and pods running. Added essential files such as install.sh, values.yaml. Updated Redis image version from redis-rejson:7.0.2-2.0.9 to redis-rejson:7.2.4-2.6.8

Can one of the admins verify this patch?

Need to update redis autoscaler files too.


Allow missing values in ComponentArray constructor

The following construction fails:
ComponentArray(a=1, b=[2, 1, 4, missing], c=[1, 2, 3])
because in utils.jl there is no method for recursive_length(a::Missing)

Thanks for these! Data science things like this are a bit of a blind spot for me, so it's good to have people using them to let me know what doesn't work for those workflows.
As of right now, ComponentArrays will automatically default to Float64 rather than trying to find a bounding type for all the data passed in. To support other types (including type unions with Missing), you can now do ComponentArray{Union{Float64,Missing}}(a=missing, b=[2, 1, 4, 5], c=[1, 2, 3]).

It looks like this fails with ComponentArray{Union{Float64,Missing}}(a=1, b=[2, 1, 4, missing], c=[1, 2, 3]). because I didn't allow heterogeneous array types. Let's keep this open and I'll look into fixing that.

K, it wasn't too bad of a change. Just needed to look for Union{Number, Missing} when making the axes rather than just Number. I'll have to write some more tests for Missing stuff at some point, but for now I'm going to call this good. If you run into any problems with it, feel free to reopen this issue.

@JuliaRegistrator register

Registration pull request created: JuliaRegistries/General/16260
After the above pull request is merged, it is recommended that a tag is created on this repository for the registered package version.
This will be done automatically if the Julia TagBot GitHub Action is installed, or can be done manually through the github interface, or via:
git tag -a v0.4.1 -m "<description of version>" 5688c14142cf06039804f8eecbda374d2cf6834b
git push origin v0.4.1


Enroot with mysql container

Hello,
I was trying to run mysql container in enroot,
using :
$ enroot import docker://mysql
$ enroot create mysql.sqsh
while running the start command i.e:
$ enroot start mysql
Gives error:
harikesh@cdac-Precision-7920-Tower:~$ enroot start mysql
2021-04-27 15:58:34+05:30 [Note] [Entrypoint]: Entrypoint script for MySQL Server 8.0.24-1debian10 started.
2021-04-27 15:58:34+05:30 [ERROR] [Entrypoint]: mysqld failed while attempting to check config
command was: mysqld --verbose --help --log-bin-index=/tmp/tmp.Pt3de50B0T
/usr/local/bin/docker-entrypoint.sh: line 92: mysqld: command not found

This is because enroot uses a login shell by default, and the image is debian based which excludes /usr/sbin from the PATH if you're not root (where mysqld is installed).
Also it looks like that this Docker entrypoint tries to drop privileges and fails if you run it with --root. You can look at their entrypoint with: enroot start mysql cat /usr/local/bin/docker-entrypoint.sh
The following should work, it disables login shell while running as your user, and also create a tmpfs for /var/run/mysqld because it doesn't do it automatically it seems:
ENROOT_LOGIN_SHELL=n enroot start  -e MYSQL_ROOT_PASSWORD=my-secret-pw -m tmpfs:/var/run/mysqld:x-create=dir mysql

Hello,
I've tried running the command but it gives error
2021-04-28 16:34:05+05:30 [Note] [Entrypoint]: Entrypoint script for MySQL Server 8.0.24-1debian10 started.
2021-04-28T11:04:05.505516Z 0 [System] [MY-010116] [Server] /usr/sbin/mysqld (mysqld 8.0.24) starting as process 16542
2021-04-28T11:04:05.505560Z 0 [ERROR] [MY-010338] [Server] Can't find error-message file '/usr/share/mysql-8.0/errmsg.sys'. Check error-message file location and 'lc-messages-dir' configuration directive.
2021-04-28T11:04:05.513366Z 1 [System] [MY-013576] [InnoDB] InnoDB initialization has started.
2021-04-28T11:04:05.652201Z 1 [System] [MY-013577] [InnoDB] InnoDB initialization has ended.
2021-04-28T11:04:05.825583Z 0 [ERROR] [MY-011300] [Server] Plugin mysqlx reported: 'Setup of socket: '/var/run/mysqld/mysqlx.sock' failed, can't create lock file /var/run/mysqld/mysqlx.sock.lock'
2021-04-28T11:04:05.826277Z 0 [System] [MY-011323] [Server] X Plugin ready for connections. Bind-address: '::' port: 33060
2021-04-28T11:04:05.957300Z 0 [Warning] [MY-010068] [Server] CA certificate ca.pem is self signed.
2021-04-28T11:04:05.957823Z 0 [System] [MY-013602] [Server] Channel mysql_main configured to support TLS. Encrypted connections are now supported for this channel.
2021-04-28T11:04:05.961320Z 0 [ERROR] [MY-010262] [Server] Can't start server: Bind on TCP/IP port: Address already in use
2021-04-28T11:04:05.961810Z 0 [ERROR] [MY-010257] [Server] Do you already have another mysqld server running on port: 3306 ?
2021-04-28T11:04:05.962771Z 0 [ERROR] [MY-010119] [Server] Aborting
2021-04-28T11:04:07.311834Z 0 [System] [MY-010910] [Server] /usr/sbin/mysqld: Shutdown complete (mysqld 8.0.24)  MySQL Community Server - GPL.

It works fine on my end, make sure you copied the above command correctly.
As said above, -m tmpfs:/var/run/mysqld:x-create=dir will create the directory needed to fix your error.

I am copying the same command as you mentioned above, i.e:
ENROOT_LOGIN_SHELL=n enroot start -e MYSQL_ROOT_PASSWORD=my-secret-pw -m tmpfs:/var/run/mysqld:x-create=dir mysql
with no changes in it but still it is giving the same error.

Make sure to recreate the container first, also you need to change port:
2021-04-28T11:04:05.961320Z 0 [ERROR] [MY-010262] [Server] Can't start server: Bind on TCP/IP port: Address already in use
2021-04-28T11:04:05.961810Z 0 [ERROR] [MY-010257] [Server] Do you already have another mysqld server running on port: 3306 ?


Lumina 1.0 does not start anymore (xinit  connection to server lost)

Hi,
Under Lumina 0.9 / Freebsd 11.0RC3with DELL Latitude 510m everything worked fine.
After the upgrade to Lumina 1.0 the start-lumina-desktop behave in an not proper way.
X session get just closed with the notice "xinit connection to server lost"
After some digging it seems now that the new start-lumina-desktop get confused by the presence of the 2 displays (internal and external (which is not connected)). The internal is on the PCI Intel:0:2:0 and the external is on the PCI:0:2:1.
I did not change the xorg.conf file which define the screen on Intel:0:2:0.
Is there some workaround or new settings must be taken into account with this version?
Regards,
David

Monitor settings should not crash/close Lumina at all, since that is a completely separate subsystem which does not touch the main session.
How are you starting Lumina? (I am guessing that you are running "start-lumina-desktop" from the CLI after logging in).
Do you have dbus_enable="YES" within your /etc/rc.conf ? There is a bug within Qt right now that requires a dbus session to be available otherwise the Qt libraries will crash. If you don't want to have a dbus session running as root, you can start lumina via dbus-launch --exit-with-session start-lumina-desktop instead, which will only startup a local/user dbus session and allows Qt to function again.

Same behavior when I lunch it within .xinitrc (exec start-lumina-desktop) or with CLI
dbus-enable is set to YES
Same behavior if I start it as root or as a standard user.
I did not change any settings which worked with version 0.9

Sorry for my bad English... On my nettops Intel NUCs Lumina 1.0 dont works on FreeBSD (scfb) with commands "start-lumina-desktop" (CLI), but Lumina works fine, if to add dbus in /etc/rc.conf and to create file, for example: ./lumi in user home directory:
#!/bin/sh exec xinit /usr/local/bin/start-lumina-desktop
And after Run: > ./lumi Lumina works fine only with xinit string.

Thank you Dmitry!! It worked that way.
It should be nice to modify the "start-lumina-desktop" so that Lumina can start the usual way as every other DE and as it was before with version 0.9 :)

I'm observing this in <IP_ADDRESS> on OpenBSD.  The default install is fine, but if a custom luminaDesktop.conf is provided, the program crashes out at this point:
if(setTheme){ LTHEME::setCurrentSettings( themesettings[0], themesettings[1], themesettings[2], themesettings[3], themesettings[4]); }   LUtils::writeFile(setdir+"/sessionsettings.conf", sesset, true);   LUtils::writeFile(setdir+"/desktopsettings.conf", deskset, true); LUtils::writeFile(setdir+"/lumina-open.conf", lopenset, true);
void LUtils::LoadSystemDefaults(bool skipOS)
https://github.com/mmcc1/lumina/blob/v0.9.0-Release-p1/src-qt5/core/libLumina/LuminaUtils.cpp
The theme gets written correctly to ./lumina under the user account, but for some unidentified reason it then drops out to the console with "xinit connection to server lost".

There appears to be a simple fix for <IP_ADDRESS> under OpenBSD and its creating a machine-id.  This is the command (the machine-id may be located elsewhere on other platforms):
dbus-uuidgen > /etc/machine-id
I will test this on a fresh install to confirm.

Confirmed for <IP_ADDRESS> under OpenBSD 6.0.  Run this as root:
dbus-uuidgen > /etc/machine-id

This should be fixed now. I also put a quick detection/fix for the DBUS/Qt bug into the start-lumina-desktop binary so that it will automatically apply the user-level workaround when launching the session (dbus-launch --exit-with-session lumina-desktop)


Update dat_fukken_disk.yml

Changed nuke disk and fake disk size to 5, because I don’t think it makes sense that a laser gun takes up less space than a floppy disk

About the PR
Screenshots

Changelog

:cl:

add: Added fun!
remove: Removed fun!

Scratch that. You can actually just remove the item component all together and it’ll inherit size 5 from the parent.

Ok, how do I do that?

Alright after failing to figure this out, merging it in the current state it’s in won’t cause any problems, right?

sorry, this is my first time using github, is there any way to accept the changes you've suggested?

You can just make the changes to your local branch, and then push them to your github. the PR will automatically update

This is way more stressful than I thought it would be


add frontend support for search results sort

(inspired by https://github.com/ITI/searcch-issues/issues/23)
Three sort "fields":

date
popularity (ratings + reviews + views)
rating

Added the backend support in https://github.com/ITI/searcch-backend/pull/86.