Helm chart install problems: User cannot watch resource "namespaces" in API group "kubernetes-client.io" in the namespace "externalsecrets"

I'm trying to install kubernetes-external-secrets on a k3d cluster to experiment with, but I'm running into this issue and I'm not sure how to resolve it.
My environment is:
Helm v3.5.2
kubernetes-external-secrets v6.3.0
k3d v 4.2.0
The command I ran is:
$ helm install kubernetes-external-secrets external-secrets/kubernetes-external-secrets --skip-crds --set env.VAULT_ADDR=$VAULT_ADDR

The pod starts up, but I continually get this error message in the logs:
"namespaces.kubernetes-client.io \"externalsecrets\" is forbidden: User \"system:serviceaccount:default:kubernetes-external-secrets\" cannot watch resource \"namespaces\" in API group \"kubernetes-client.io\" in the namespace \"externalsecrets\""

The only modification I made to the serviceaccount is adding a ClusterRoleBinding to the token reviewer role to enable k8s vault auth:
apiVersion: rbac.authorization.k8s.io/v1beta1
kind: ClusterRoleBinding
metadata:
  name: kubernetes-external-secrets-tokenreview-binding
  namespace: default
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: system:auth-delegator
subjects:
- kind: ServiceAccount
  name: kubernetes-external-secrets
  namespace: default

I'm fairly new to k8s, so I apologize in advance if this has been asked before

same problem here (except i didnt make the modification).
helm Version: v3.5.2
kubernetes-external-secrets v6.3.0
k8s: v1.20.2+k3s1

I am seeing the same issue,
I believe this is the commit thats responsible. Not 100% sure why its ocurring, but its definitely related to the namespacing.
if you define env.WATCHED_NAMESPACES with a specific namespace, then the controller actually works, but obviously that is not ideal, if the desired behavior is to watch all namepaces.

Same problem here, I have to downgrade to 6.1.0 in order for it to work without declaring namespaces in the config.

Cannot reproduce this in kind and k3s is not supported on WSL2 :[
I'm thinking this is an issue related to k3s unless someone here has run into this without using k3s?

Cannot reproduce this in kind and k3s is not supported on WSL2 :[

Did you try k3d (k3s in Docker)?

Right, of course 😅
Can reproduce in k3d indeed.
Fixing the permission could be done with
Setting this in values.yaml
customClusterRoles:
  - apiGroups: ["kubernetes-client.io"]
    resources: ["namespaces"]
    verbs: ["watch"]

However this will still cause a loop of the watch stream dying and restarting infinitely.
Not sure why this happens in k3s but not others.
Made some changes in #673 which avoids the namespace api if not watching a specific namespace.
You can try it out from ghcr.io/external-secrets/kes-dev:pr-673


Remove "Drop-down button" from the transtions perf test.

It's no longer part of the gallery app.
BUG=https://github.com/flutter/flutter/issues/4390

lgtm

Oops, sorry about that.


Added Rod Cutting Problem [Java]

Fixes #{163}
By submitting this pull request I confirm I've read and complied with the below declarations.

[x] I have read the Contribution guidelines and I am confident that my PR reflects them.
[x] I have followed the coding guidelines for this project.
[x] My code follows the skeleton code structure.
[x] This pull request has a descriptive title. For example, Added {Algorithm/DS name} [{Language}], not Update README.md or Added new code.
[x] This pull request will be closed if I fail to update it even once in a continuous timespan of 7 days.

@Monal5031 @singhpratyush @aviaryan please review.

@Monal5031 Please review again.

@Prakash2403 remove {} from your PR description, it should be Fixed #163, this links the issue with this PR.

@Monal5031 Please review it again. Hope it's final review.

@Prakash2403 Thanks, everything looks good now. 👍

Thanks @Prakash2403.
Please set up git properly on your  machine so that Github can recognize your commits.


Exam mode: Improve attendance check with websocket based Id information

Is your feature request related to a problem?
The on site exam mode requires the check of the matriculation number, the name of the student and the artemis username. This information are used to savely identify the student and the open artemis session on the student device.
Currently the student has to open a new tab and show his credentials. This should be improved and implemented more interactively.
Describe the solution you'd like
The instructor should be able to initiate a pop up from the instructors iPad that opens on the students enddevice in the ongoing exam mode.
This pop up should contain the matriculation number, the name of the student and the artemis username.
This information is needed to identify the student and his open exam session.
Describe alternatives you've considered
No response
Additional context
No response

cc @bassner


Desktop: AwtWindow makes MenuBar disappear on MacOS

Describe the bug
When showing an AwtWindow, after the window has closed, the MenuBar does not display anymore on Mac OS X.
Affected platforms

Desktop

Versions

Kotlin version*: 1.9.21
Compose Multiplatform version*: 1.5.11
OS version(s)* (required for Desktop and iOS issues): Mac OS X 14.2 (23C64)
OS architecture (x86 or arm64): X86
JDK (for desktop issues): JBR-17

To Reproduce

Compile and run the following code:import androidx.compose.foundation.layout.Column
import androidx.compose.material.Text
import androidx.compose.runtime.*
import androidx.compose.ui.window.AwtWindow
import androidx.compose.ui.window.MenuBar
import androidx.compose.ui.window.singleWindowApplication
import java.awt.FileDialog
import java.awt.Frame
import java.nio.file.Path
import kotlin.io.path.Path
import kotlin.io.path.absolutePathString

@Composable
fun FileLoadDialog(
    title: String,
    visible: Boolean = true,
    onResult: (result: Path?) -> Unit,
) {
    AwtWindow(
        visible = visible,
        create = {
            object : FileDialog(null as Frame?, title, LOAD) {
                override fun setVisible(value: Boolean) {
                    super.setVisible(value)
                    if (value) onResult(file?.let { Path(directory, file) })
                }
            }
        },
        dispose = FileDialog::dispose
    )
}

fun main() = singleWindowApplication {
    var load: Boolean by remember { mutableStateOf(false) }
    var path: Path? by remember { mutableStateOf(null) }

    FileLoadDialog(
        title = "Load a file",
        visible = load,
        onResult = {
            path = it
            load = false
        }
    )

    MenuBar {
        Menu("File") {
            Item("Load") { load = true }
        }
        Menu("Edit") {
            Item("Hello World!") {}
        }
    }

    Column {
        Text(if (load) "Loading..." else "Use File > Load to load a file")
        path?.let { Text(it.absolutePathString()) }
    }
}

In the screen's top menu, select "File" > "Load"
Select any file and click "Open" (or click "Cancel")
See that the top menu (that should show "File" & "Edit") has disappeared.

Note that if the application window loses focus, when the app regains focus, the menu is shown again.

Please check the following ticket on YouTrack for follow-ups to this issue. GitHub issues will be closed in the coming weeks.


Streaming Video files hosted on Google Cloud Storage

@flovilmart @nlutsenko
Question
My app is hosted on Google App Engine and I want to use Google Cloud Storage to host video files which I will stream to my iOS client. Previously people had trouble using self-hosted parse-server to stream videos. I'm wondering if theres any technical barriers preventing this right now
There was this hack  by @Bragegs previously referenced however I haven't tried it.
#692 #1698 #1973

Thanks for your question!
We want to make sure to keep signal strong in the GitHub issue tracker – to make sure that it remains the best place to track issues that affect the development of Parse Server.
Questions like yours deserve a purpose-built Q&A forum. Would you like to post this question to Stack Overflow with the tag #parse.com? We'll be happy to answer there. Post a link to your Stack Overflow question here, so that we don't lose track of it.
You may also use Server Fault for questions about managing your own servers.


Added backwards compatibility with DRF 2.4.X, fixed media_type pass through

ReadOnlyField is only available in DRF 3.0+ and was causing backwards incompatibility. Also fixed media_type pass through as noted in open issue: https://github.com/ngenworks/rest_framework_ember/issues/17

@jerel greetings, lmk if this looks good... we had to revert version since new one broke on our DRF 2.4.x

Also added camelize of resource name per mentioned https://github.com/ngenworks/rest_framework_ember/issues/20

@gaker hola! wondering if anyone over there can take a look at this? we use this app in production and recent changes broke compatibility for those of us still using rest framework 2.4.X, lmk if you guys can merge it! thx

@erichonkanen thanks for this pull request and for closing related issues (I merged it to the develop branch). I had accidentally unwatched this repo so had missed most of the activity. I'll get a new release tagged up shortly

@jerel np! thanks dude

@jerel doh forgot to push my last push but you can replace these lines:
https://github.com/ngenworks/rest_framework_ember/blob/develop/rest_framework_ember/utils.py#L29-L33
with this:

        if isinstance(resource_name, basestring):
            return inflection.camelize(resource_name, False)

Since I think we always want the resource_name camelized for ember, this makes it work for more than 2 words...

@erichonkanen yes! good catch. aPIRoot has been bugging me ;)


node-red deployed on kubernetes(as a pod) to intereact with azure iot edge

What are the steps to reproduce?
deploy node-red via helm /or as a module to azure kubernetes services
What happens?

What do you expect to happen?
node-red (Module Client - input ) should be able to receive telemetry from another module
Please tell us about your environment:

[ ] Node-RED version: 1.3.4
[ ] Node.js version: 10.24.1
[ ] npm version: n/a
[ ] Platform/OS: azure kubernetes services
[ ] Browser:

Hi, please use the forum if you have questions about how to use Node-RED in particular environments.
This issue list is for bugs etc in the core of the project.

Closed as this has been moved over to the forum.


WIP: Rearrange UI

Related Jira ticket: https://jira.mitre.org/browse/REMS-414

Screenshots (after) on iPad Mini simulated device:
Two horizontal panes

Two vertical panes

When the page is wide, should the patient information be 50% like we have now? Or should it be smaller with maybe a fixed maximum size since it's not the focus of the interface, it's really there for information purposes. The text "Launched with patient context:" should perhaps be smaller and just over the "Patient Info" section? We should discuss this at standup.
Overall it looks and works great though!

Current (after) screenshots

Changes made

Reduced the ratio from 50:50 to 25:75 for the patient info and medication request panes
Added spacing between CDS Hooks Card buttons
Moved Grid component out of the medication request dropdown component


Evict requests if the client has disconnected

🚀 Feature

If a client sends a request and is disconnected, LitServe still processes the request which is a waste of computation. We need to evict the request if the client is disconnected.
Motivation

Pitch

Alternatives

Additional context

Hi @aniketmaurya, I've been exploring potential implementations for this feature
and came across the req.is_disconnected() method, which seems useful for checking if the client has disconnected.
I will try to draft a PR within the next few days to address this issue.
Looking forward to your thoughts on it! 😊

sounds great @bhimrazy!! the only thing to take care of would be that we send the request to another process so request might lose the ability to check if it's disconnected (haven't tested personally). But definitely go ahead and give it a try.
I have one more idea to check using socket connection but we can check that later.

Thank you, @aniketmaurya, for the insights, and apologies for the delay in drafting the PR.
I've tried implementing an idea by checking for the uid. However, I'm a bit unsure if this will impact performance.
It's still a work in progress, but I would appreciate any feedback.

Commented on the PR @bhimrazy! let's move the conversation there.


Added support for additional routes on the Dashboard

This PR covers issue #618 for supporting additional routes on the Dashboard in Bindings column. This makes it easier to navigate to endpoints that you access frequently like /swagger.

Some design feedback: Routes should be an array instead of a semicolon delimited String

Some design feedback: Routes should be an array instead of a semicolon delimited String

Thanks for the feedback, I have applied the requested changes.

Any traction on this? Looking like it's closer now :)

@ante-maric Looks good to me, and rather handy! Thanks for the submission!  The only change I've made is to use blocks for the binding spans, as it starts to get hard to read with many routes.
@ravipal Since I've made changes myself, can you review as well?


Fix broken link:kubeadm.md

Fix broken link:kubeadm.md

NOTE: Please check the “Allow edits from maintainers” box below to allow
reviewers fix problems on your patch and speed up the review process.
Please delete this note before submitting the pull request.

This change is

/lgtm


[Unified Instance Tagging]: Add cloud_metadata to DBM event payloads

What does this PR do?

This PR adds cloud_metadata fields to all DBM event payloads, this adds necessary context in order link DBM event data with related cloud resource data in our backend.
The goal here is to allow customers to filter event data by a new universal tag database_instance, which will be applied across DBM and cloud telemetry.
Motivation

Additional Notes

Review checklist (to be filled by reviewers)

[ ] Feature or bugfix MUST have appropriate tests (unit, integration, e2e)
[ ] PR title must be written as a CHANGELOG entry (see why)
[ ] Files changes must correspond to the primary purpose of the PR as described in the title (small unrelated changes should have their own PR)
[ ] PR must have changelog/ and integration/ labels attached
[ ] If the PR doesn't need to be tested during QA, please add a qa/skip-qa label.

closing this in favor of a newer PR that won't run the extra azure pipelines tests


Update getEmailTemplates using REST API in the AccountLockEnabledTestCase

Purpose
This PR removes resourceAdminServiceClient which has used SOAP services to retrieve the Email Templates(only) and replaced it with a REST API based EmailTemplatesRestClient in the AccountLockEnabledTestCase
Also added IdentityGovernanceRestClient by replacing the soap api based IdentityGovernanceServiceClient

PR builder [7.x.x] started
Link: https://github.com/wso2/product-is/actions/runs/5129127527

PR builder [7.x.x] completed
Link: https://github.com/wso2/product-is/actions/runs/5129127527
Status: cancelled

PR builder [7.x.x] started
Link: https://github.com/wso2/product-is/actions/runs/5129214951

PR builder [7.x.x] completed
Link: https://github.com/wso2/product-is/actions/runs/5129214951
Status: cancelled

PR builder [7.x.x] started
Link: https://github.com/wso2/product-is/actions/runs/5129214951

PR builder [7.x.x] completed
Link: https://github.com/wso2/product-is/actions/runs/5129214951
Status: success


npm install jsdom fails using<EMAIL_ADDRESS>

Here is the output
$ node --version
v2.0.0
$ npm --version
2.9.0
$ nvm --version
0.23.3
$ npm install
npm WARN optional dep failed, continuing<EMAIL_ADDRESS>><EMAIL_ADDRESS>install /home/travis/build/catberry/catberry/node_modules/jsdom/node_modules/contextify
> node-gyp rebuild
make: Entering directory `/home/travis/build/catberry/catberry/node_modules/jsdom/node_modules/contextify/build'
  CXX(target) Release/obj.target/contextify/src/contextify.o
In file included from ../node_modules/nan/nan_new.h:181:0,
                 from ../node_modules/nan/nan.h:74,
                 from ../src/contextify.cc:3:
../node_modules/nan/nan_implementation_12_inl.h: In static member function ‘static NanIntern::FactoryBase<v8::Signature>::return_t NanIntern::Factory<v8::Signature>::New(NanIntern::Factory<v8::Signature>::FTH, int, NanIntern::Factory<v8::Signature>::FTH*)’:
../node_modules/nan/nan_implementation_12_inl.h:172:76: error: no matching function for call to ‘v8::Signature::New(v8::Isolate*, NanIntern::Factory<v8::Signature>::FTH&, int&, NanIntern::Factory<v8::Signature>::FTH*&)’
../node_modules/nan/nan_implementation_12_inl.h:172:76: note: candidate is:
/home/travis/.node-gyp/2.0.0/deps/v8/include/v8.h:4188:27: note: static v8::Local<v8::Signature> v8::Signature::New(v8::Isolate*, v8::Handle<v8::FunctionTemplate>)
/home/travis/.node-gyp/2.0.0/deps/v8/include/v8.h:4188:27: note:   candidate expects 2 arguments, 4 provided
make: *** [Release/obj.target/contextify/src/contextify.o] Error 1
make: Leaving directory `/home/travis/build/catberry/catberry/node_modules/jsdom/node_modules/contextify/build'
gyp ERR! build error
gyp ERR! stack Error: `make` failed with exit code: 2
gyp ERR! stack     at ChildProcess.onExit (/home/travis/.nvm/versions/io.js/v2.0.0/lib/node_modules/npm/node_modules/node-gyp/lib/build.js:269:23)
gyp ERR! stack     at emitTwo (events.js:87:13)
gyp ERR! stack     at ChildProcess.emit (events.js:169:7)
gyp ERR! stack     at Process.ChildProcess._handle.onexit (child_process.js:1009:12)
gyp ERR! System Linux 2.6.32-042stab094.7
gyp ERR! command "/home/travis/.nvm/versions/io.js/v2.0.0/bin/iojs" "/home/travis/.nvm/versions/io.js/v2.0.0/lib/node_modules/npm/node_modules/node-gyp/bin/node-gyp.js" "rebuild"
gyp ERR! cwd /home/travis/build/catberry/catberry/node_modules/jsdom/node_modules/contextify
gyp ERR! node -v v2.0.0
gyp ERR! node-gyp -v v1.0.3
gyp ERR! not ok
npm WARN engine<EMAIL_ADDRESS>wanted: {"node":"0.8.x || 0.10.x || 0.11.x  || 1.0.x"} (current: {"node":"2.0.0","npm":"2.9.0"})
npm WARN prefer global<EMAIL_ADDRESS>should be installed with -g
npm ERR! Linux 2.6.32-042stab094.7
npm ERR! argv "/home/travis/.nvm/versions/io.js/v2.0.0/bin/iojs" "/home/travis/.nvm/versions/io.js/v2.0.0/bin/npm" "install"
npm ERR! node v2.0.0
npm ERR! npm  v2.9.0
npm ERR! code ELIFECYCLE
npm ERR<EMAIL_ADDRESS>install: `node-gyp rebuild`
npm ERR! Exit status 1
npm ERR!
npm ERR! Failed at the<EMAIL_ADDRESS>install script 'node-gyp rebuild'.
npm ERR! This is most likely a problem with the contextify package,
npm ERR! not with npm itself.
npm ERR! Tell the author that this fails on your system:
npm ERR!     node-gyp rebuild
npm ERR! You can get their info via:
npm ERR!     npm owner ls contextify
npm ERR! There is likely additional logging output above.
npm ERR! Please include the following file with any support request:
npm ERR!     /home/travis/build/catberry/catberry/npm-debug.log
The command "eval npm install " failed. Retrying, 2 of 3.
><EMAIL_ADDRESS>install /home/travis/build/catberry/catberry/node_modules/jsdom/node_modules/contextify
> node-gyp rebuild
make: Entering directory `/home/travis/build/catberry/catberry/node_modules/jsdom/node_modules/contextify/build'
  CXX(target) Release/obj.target/contextify/src/contextify.o
In file included from ../node_modules/nan/nan_new.h:181:0,
                 from ../node_modules/nan/nan.h:74,
                 from ../src/contextify.cc:3:
../node_modules/nan/nan_implementation_12_inl.h: In static member function ‘static NanIntern::FactoryBase<v8::Signature>::return_t NanIntern::Factory<v8::Signature>::New(NanIntern::Factory<v8::Signature>::FTH, int, NanIntern::Factory<v8::Signature>::FTH*)’:
../node_modules/nan/nan_implementation_12_inl.h:172:76: error: no matching function for call to ‘v8::Signature::New(v8::Isolate*, NanIntern::Factory<v8::Signature>::FTH&, int&, NanIntern::Factory<v8::Signature>::FTH*&)’
../node_modules/nan/nan_implementation_12_inl.h:172:76: note: candidate is:
/home/travis/.node-gyp/2.0.0/deps/v8/include/v8.h:4188:27: note: static v8::Local<v8::Signature> v8::Signature::New(v8::Isolate*, v8::Handle<v8::FunctionTemplate>)
/home/travis/.node-gyp/2.0.0/deps/v8/include/v8.h:4188:27: note:   candidate expects 2 arguments, 4 provided
make: *** [Release/obj.target/contextify/src/contextify.o] Error 1
make: Leaving directory `/home/travis/build/catberry/catberry/node_modules/jsdom/node_modules/contextify/build'
gyp ERR! build error
gyp ERR! stack Error: `make` failed with exit code: 2
gyp ERR! stack     at ChildProcess.onExit (/home/travis/.nvm/versions/io.js/v2.0.0/lib/node_modules/npm/node_modules/node-gyp/lib/build.js:269:23)
gyp ERR! stack     at emitTwo (events.js:87:13)
gyp ERR! stack     at ChildProcess.emit (events.js:169:7)
gyp ERR! stack     at Process.ChildProcess._handle.onexit (child_process.js:1009:12)
gyp ERR! System Linux 2.6.32-042stab094.7
gyp ERR! command "/home/travis/.nvm/versions/io.js/v2.0.0/bin/iojs" "/home/travis/.nvm/versions/io.js/v2.0.0/lib/node_modules/npm/node_modules/node-gyp/bin/node-gyp.js" "rebuild"
gyp ERR! cwd /home/travis/build/catberry/catberry/node_modules/jsdom/node_modules/contextify
gyp ERR! node -v v2.0.0
gyp ERR! node-gyp -v v1.0.3
gyp ERR! not ok
npm ERR! Linux 2.6.32-042stab094.7
npm ERR! argv "/home/travis/.nvm/versions/io.js/v2.0.0/bin/iojs" "/home/travis/.nvm/versions/io.js/v2.0.0/bin/npm" "install"
npm ERR! node v2.0.0
npm ERR! npm  v2.9.0
npm ERR! code ELIFECYCLE
npm ERR<EMAIL_ADDRESS>install: `node-gyp rebuild`
npm ERR! Exit status 1
npm ERR!
npm ERR! Failed at the<EMAIL_ADDRESS>install script 'node-gyp rebuild'.
npm ERR! This is most likely a problem with the contextify package,
npm ERR! not with npm itself.
npm ERR! Tell the author that this fails on your system:
npm ERR!     node-gyp rebuild
npm ERR! You can get their info via:
npm ERR!     npm owner ls contextify
npm ERR! There is likely additional logging output above.
npm ERR! Please include the following file with any support request:
npm ERR!     /home/travis/build/catberry/catberry/npm-debug.log
The command "eval npm install " failed. Retrying, 3 of 3.
><EMAIL_ADDRESS>install /home/travis/build/catberry/catberry/node_modules/jsdom/node_modules/contextify
> node-gyp rebuild
make: Entering directory `/home/travis/build/catberry/catberry/node_modules/jsdom/node_modules/contextify/build'
  CXX(target) Release/obj.target/contextify/src/contextify.o
In file included from ../node_modules/nan/nan_new.h:181:0,
                 from ../node_modules/nan/nan.h:74,
                 from ../src/contextify.cc:3:
../node_modules/nan/nan_implementation_12_inl.h: In static member function ‘static NanIntern::FactoryBase<v8::Signature>::return_t NanIntern::Factory<v8::Signature>::New(NanIntern::Factory<v8::Signature>::FTH, int, NanIntern::Factory<v8::Signature>::FTH*)’:
../node_modules/nan/nan_implementation_12_inl.h:172:76: error: no matching function for call to ‘v8::Signature::New(v8::Isolate*, NanIntern::Factory<v8::Signature>::FTH&, int&, NanIntern::Factory<v8::Signature>::FTH*&)’
../node_modules/nan/nan_implementation_12_inl.h:172:76: note: candidate is:
/home/travis/.node-gyp/2.0.0/deps/v8/include/v8.h:4188:27: note: static v8::Local<v8::Signature> v8::Signature::New(v8::Isolate*, v8::Handle<v8::FunctionTemplate>)
/home/travis/.node-gyp/2.0.0/deps/v8/include/v8.h:4188:27: note:   candidate expects 2 arguments, 4 provided
make: *** [Release/obj.target/contextify/src/contextify.o] Error 1
make: Leaving directory `/home/travis/build/catberry/catberry/node_modules/jsdom/node_modules/contextify/build'
gyp ERR! build error
gyp ERR! stack Error: `make` failed with exit code: 2
gyp ERR! stack     at ChildProcess.onExit (/home/travis/.nvm/versions/io.js/v2.0.0/lib/node_modules/npm/node_modules/node-gyp/lib/build.js:269:23)
gyp ERR! stack     at emitTwo (events.js:87:13)
gyp ERR! stack     at ChildProcess.emit (events.js:169:7)
gyp ERR! stack     at Process.ChildProcess._handle.onexit (child_process.js:1009:12)
gyp ERR! System Linux 2.6.32-042stab094.7
gyp ERR! command "/home/travis/.nvm/versions/io.js/v2.0.0/bin/iojs" "/home/travis/.nvm/versions/io.js/v2.0.0/lib/node_modules/npm/node_modules/node-gyp/bin/node-gyp.js" "rebuild"
gyp ERR! cwd /home/travis/build/catberry/catberry/node_modules/jsdom/node_modules/contextify
gyp ERR! node -v v2.0.0
gyp ERR! node-gyp -v v1.0.3
gyp ERR! not ok
npm ERR! Linux 2.6.32-042stab094.7
npm ERR! argv "/home/travis/.nvm/versions/io.js/v2.0.0/bin/iojs" "/home/travis/.nvm/versions/io.js/v2.0.0/bin/npm" "install"
npm ERR! node v2.0.0
npm ERR! npm  v2.9.0
npm ERR! code ELIFECYCLE
npm ERR<EMAIL_ADDRESS>install: `node-gyp rebuild`
npm ERR! Exit status 1
npm ERR!
npm ERR! Failed at the<EMAIL_ADDRESS>install script 'node-gyp rebuild'.
npm ERR! This is most likely a problem with the contextify package,
npm ERR! not with npm itself.
npm ERR! Tell the author that this fails on your system:
npm ERR!     node-gyp rebuild
npm ERR! You can get their info via:
npm ERR!     npm owner ls contextify
npm ERR! There is likely additional logging output above.
npm ERR! Please include the following file with any support request:
npm ERR!     /home/travis/build/catberry/catberry/npm-debug.log
The command "eval npm install " failed 3 times.
The command "npm install " failed and exited with 1 during .
Your build has been stopped.

You're trying to install an old version of jsdom. We don't require the contextify dependency anymore.

So, by the moment I've been using jsdom ^3.1.2 because it works with node.js as well as with iojs. But now it looks like there is no such version of jsdom that works with node 0.12 and iojs 2.0.0 at the same time, am I right?

Yeah, although contextify may get updated so it supports iojs, but you'd need to take that up with those guys.

@Sebmaster Thanks for help!


Add hostname to elastalert_status

If multiple instances are writing documents to elastalert_status, there needs to be some way to determine which machine they came from. Hostname would be useful to have in these logs.

I like this idea too. However, I think there should be an optional name property in the config file which defaults to hostname if not set. This would allow users to potentially have multiple instances of EA running on the same host.


Add initial default values for backing bean fields

It should be possible to define  default values to initiate backing bean fields at creation time.

One possibility is to add an attribute id to FluentApiBackingBeanField annotation.
The value annotation then would be set to optional and used for default value.
It's still ok to do so since nobody uses this library at the moment (did first release today)

There should be an additional attribute about initializing collections.
Otherwise the collection should stay null.

Thought about filling arrays and sets, no separate attribute should be necessary. It can be expressed in the value:
['','',...]
' must be escaped for String types

Added initValue attribute of type String[]
This way it's quite easy to support both single and collection/array based types
Extended Implicit Values as well to support Collections and arrays


Add Automatic-Module-Name to MANIFEST

The idea of this commit is to get a release 1.7.26 done with automatic module names for the four outward-facing modules. This allows the issues of service loader, module-info and so on to be sidestepped for now.
This PR is not intended to be merged onto the master branch. Instead, it is intended for there to be a new branch in slf4j starting at 1232e8529f5844e03e4d528a88185413761853e2 where this is the first commit on the branch. I can't get GitHub to do this automatically, so you'd need to create the branch in slf4j first, and I can then re-raise the PR against the new branch. Alternatively, you can cherry pick this commit onto the branch.
There is a case to add Automatic-Module-Name to the inward-facing (impl) jars, but I'm still working out what the best strategy for those is.
thanks

Any progress on this merge? It would be nice to have SLF4j 1.8 with right Automatic-Module-Name

Any plans on merging this change?

@ceki
Any update on https://jira.qos.ch/browse/SLF4J-420?
What are you timelines on launching a version with JDK 9 module support?

Mostly fixed by https://github.com/qos-ch/slf4j/commit/bf50c49d10e37e4d0c82a2529c2f074237262db1


docs: major API changes

The whole IPLD APIs get a review to make them more consistent and
easier to use.
Changes to compared to the current spec:

No more callbacks, everything is Promises.
get():

Is renamed to resolve() to indicate that it also takes a mandatory
path argument.
Doesn’t have a cid in the return value anymore. That use case is
covered by returning all objects that were traversed. Their value
will always be the CID of the next one to traverse. So if you want
to know the CID of the current IPLD Node, just look at the value
of the previously returned IPLD Node.
Doesn’t return a single value, but an iterator.
localResolve option is removed. If you want to resolve a single IPLD
Node only, just stop the iterator after the first item.

getStream() is removed without replacement. Use resolve() which uses
async iterators instead.
getMany() is renamed to get():

takes an iterable of CIDs as parameter.

put():

takes an iterable of CIDs as parameter.
Doesn’t take cid as an option anymore. The CID is always calculated
(https://github.com/ipld/js-ipld/issues/175).
The options don’t take the format (which is a string), but the codec
(which is a multicodec) (https://github.com/ipld/js-ipld/issues/175).
the cidVersion option always defaults to 1.

.treeStream() is renamed to .tree() and returns an async iterator.
remove():

takes an iterable of CIDs as parameter.

.support.add() is renamed to .addFormat().
.support.rm() is renamed to .removeFormat().
options.loadFormat() is no longer callback based but is using an async
function.

Almost all open issues in regards to the IPLD API got adressed. One bigger
thing is the Patch API, which also isn’t part of the current specification.
Here’s an overview of the issues:

https://github.com/ipld/js-ipld/issues/66

[ ] IPLD Resolver patch API: There is no patch API yet

https://github.com/ipld/js-ipld/issues/70

[x] lazy value lookups: Can be done as IPLD Formats is pure JavaScript
[x] get external / local paths only: @vmx doesn’t know what this is,
considers it a “won’t fix”
[x] toJSON + fromJSON - roundtrip: A roundtrip is not a goal anymore
=> won’t fix
[ ] put + patch api #66: Patch API is still missing
[x] text summary: @vmx doesn’t see a strong use case for this => “won’t fix”
[x] globbing: Out of scope for js-ipld

https://github.com/ipld/js-ipld/issues/175

[x] Deprecate passing a CID to ipld.put?: Current spec doesn’t allow
put() with a CID

https://github.com/ipld/js-ipld/issues/182

[x] API Review: Links to many other issues, I list the individual issues
below

https://github.com/ipld/js-ipld/issues/183

[x] getting the merkle proof with resolver.resolve: resolve() returns
all CIDs along the traversed path

https://github.com/ipld/js-ipld/issues/184

[ ] Pass down the options object to resolver.resolve(): This needs a
custom resolver. @vmx isn’t sure if the js-ipld API should make this
possible, or of it should just be easy enough to create your own
resolver.

https://github.com/ipfs/interface-ipfs-core/issues/81

[x] The dag API - One API to manipulate all the IPLD Format objects:
Interesting discussion, but not relevant anymore.

https://github.com/ipfs/interface-ipfs-core/issues/121

[x] dag api: add {ls, tree}: tree() is not part of js-ipld anymore as
the IPLD Nodes are just JavaScript objects which you can easily traverse
if you like. Though tree()-like functionality might be added as an
example or separate module.

https://github.com/ipfs/interface-ipfs-core/issues/125

[x] dag get --localResolve vs dag resolve: This is solved by the new
resolve() API

https://github.com/ipfs/interface-ipfs-core/issues/137

[x] add level option to ipfs.dag.tree: tree() is not part of js-ipld
anymore. It should be considered if tree() is implemented (probably
as an example or separate module)

Closes #70, #175, #182, #183
Closes https://github.com/ipfs/interface-ipfs-core/issues/121
Closes https://github.com/ipfs/interface-ipfs-core/issues/125
Closed https://github.com/ipfs/interface-ipfs-core/issues/137

This one is already reviewed an approved via #185. This will be merged once #190 is merged.

@vmx  is this PR in sync with latest #190?

@lidel Yes. If not it's a bug.

@gozala proposes a different (simpler) API: https://gozala.hashbase.io/posts/Constraints of an API design/
It really has good points and I think we should follow this route and change the API outlined here to the proposed one. As a start we won't implement any batching yet, but just do the single item commands.
What do you think @alanshaw @mikeal?

Only operating on individual CIDs/nodes means we can't perform optimisations at the library level - batching to not swamp the DHT, parallelising where it makes sense, etc.  You consequently push that complexity onto the calling code - so the API might be simpler but the code you have to write to consume it in an efficient manner will not be.

Is it guaranteed that number of nodes match number of CIDs?

Since a node has a single CID, I'd say yes.  Granted it's hard to guarantee this in code because iterators are unbounded.

Is order of nodes correspond to order of CIDs returned ?

Also yes, otherwise we're into non-deterministic territory.  Again, hard to express in code but a documentation note should be sufficient?

If there is a failure to put nth node would rest of the nodes still be put or aborted ?

Our datastore is immutable so rolling back puts after a failure seems a little weird, but I guess there's the .remove method if the user wants that to happen.
I suppose you might want to control when and where to abort based on error conditions (e.g. abort after failure or continue after failure), but then you can drop down to the version without syntactic sugar:
const iter = ipld.put(someIterator)

while (true) {
  try {
    const { done, value } = await iter.next()
    // do something
  } catch (err) {
    // abort, continue, revert - it's up to you
  }
}

One thing:

put():

takes an iterable of CIDs as parameter.

Shouldn't this be an iterable of nodes?  Also, why not an async iterable so we don't have to hold the whole list in memory?

put():

takes an iterable of CIDs as parameter.

Shouldn't this be an iterable of nodes? Also, why not an async iterable so we don't have to hold the whole list in memory?

It is nodes. The README is already right, the commit message is wrong. And it also can be an async iterable (the code has support for it).

@achingbrain thanks for going through questions I’ve mentioned. As I later I attempted to point out those questions are symphtom of incidental complexity. I am huge proponent of batching optimization, but again if I were to distill that post into two centences - batching API needs to a careful designed optimized towards it’s user rather than imposing solution optimized for internal batching to all users. Argument I’m trying to make that while (async) iterators seem neat they’re added complexity for non-batch operations and are far from good even for batched operations.
They might be adequate for single use case of streaming chunked ops and making that default interface for everyone is just makes all other uses prone to error.
In other words if batching is important use case

If there is a failure to put nth node would rest of the nodes still be put or aborted ?

Our datastore is immutable so rolling back puts after a failure seems a little weird, but I guess there's the .remove method if the user wants that to happen.

I think you're misunderstanding my question here, I was not talking about rolling back operations (which in theory could also fail) but rather that if you put([a, b, c]) and b fails would put still attempt to do c or not ?
I also know the answer, what I was trying to illustrate that those questions will arise and that is because in some use cases you'd want one behavior and in other the other.

My proposal would be not to try and optimize API for batching without having support for that in first place. Once support for batching is being worked lets craft API that takes into account constraints and optimization opportunities into account as well as enables consumers to choose optimizations strategies, failure modes and some & mechanism to recovery (and maybe even unroll).

I’m starting to get very confused about who the consumer of this API is. We’re making good improvements but as we start to narrow in on each one the expectations from the consumer of the API start to matter.
It seems like we’re trying to create a new, cleaner, layering scheme but we’re also shoving all of those new layers into a single API.
Right now, this single interface is responsible for:

Encoding/decode data to/from objects to blocks.
Resolving paths through multiple blocks.
Storing and retrieving data from a pre-defined interface (BlockService).

If these were separate libraries/layers the interfaces between them would be much more obvious, but having them all together makes it unclear to me what the consumer wants to be doing. However, because the old interface combined all of this functionality it would be a much bigger shift to change it too much at a time when js-ipfs is also migrating to async/await.
If the goal here is just to have a replacement for the current interface that uses async/await so that we can continue to make progress on the migration in IPFS then let’s just merge and land this as soon as possible. I don’t think it’s productive to have larger meta conversations about the ideal interface while we also try to make the migration for js-ipfs as seamless as possible.
We can come back to better interfaces for IPLD generally after this lands.

If the goal here is just to have a replacement for the current interface that uses async/await so that we can continue to make progress on the migration in IPFS then let’s just merge and land this as soon as possible.

No it's more than this. It's a major clean-up and a major breaking change. As there are more projects that are using js-ipld than js-ipfs, it would be a bad if we would breaking the API a lot.
The current implementation of the new API quite trivial. We don't do any fancy optimizations, it's really all sequential.
Taking @Gozala concerns into account, the only change would be to make the get(), put() and remove() to use a single item instead of an iterable as input. Of course the consumers would need to be changed accordingly. But when I look e.g. at js-ipfs-mfs, it is using almost only the "single node" interface anyway (I won't link the others, but I expect it to be similar). So a simpler interface would even make code simpler.
So if we do this change now (chaning from "multi" to "single" operations), we can talk about all the batching/requesting several items at the same time later on, without breaking any of the API again.

It is worth pointing out that current put / get API is unary, ao if anything I’m proposing to make less breaking API

current put / get API is unary

This is not strictly true, there's .getMany(cids, callback) which IPFS makes use of and which we will lose if we switch to only one-in-one-out.  The reason we use this is to not swamp the DHT (when it arrives in the next js-ipfs release).

when I look e.g. at js-ipfs-mfs, it is using almost only the "single node" interface

It does for fs manipulations (e.g. copying/moving files, etc) but when reading and writing whole files it uses the unixfs exporter/importer.
The exporter uses .getMany (as above) but there's no equivalent for writing multiple nodes simultaneously - it'd be a big win to be able to do so.
Using iterables for single-node operations is a bit clunky - can't we just have both?
interface IPLD {
  put<a>(node:a):Promise<CID<a>>;
  putMany<a>(nodes:AsyncIterable<a>):AsyncIterable<CID<a>>;
  get<a>(cid:CID<a>):Promise<a>;
  getMany<a>(cids:AsyncIterable<CID<a>>):AsyncIterable<a>;
}

In the case of errors, from an IPFS point of view it's best to fail quickly and give the user a useful error message so the default behaviour of exploding halfway through an iteration and stopping is fine.
If you want fancy error handling strategies you can just fall back to the non-syntactic sugar version as I  suggested earlier.  If the syntax offends, you can just wrap it in a module and publish it.

This is not strictly true, there's .getMany(cids, callback) which IPFS makes use of and which we will lose if we switch to only one-in-one-out. The reason we use this is to not swamp the DHT (when it arrives in the next js-ipfs release).

We also lose it in the current implementation I did for this API as it was too hard to do with the current callback based interface of the underlying libraries. So instead of implementing that properly I could invest my time on doing the batch API.

Using iterables for single-node operations is a bit clunky - can't we just have both?

One of my goals is keeping the API surface small. I don't think the clunky single node operation justifies adding new 3 new API calls (get, put, remove).

If you want fancy error handling strategies you can just fall back to the non-syntactic sugar version as I suggested earlier. If the syntax offends, you can just wrap it in a module and publish it.

One more question here. The current implementation would throw if there was an error. What would you do if you want to continue with the rest of the nodes? Would it be an option in that it returns errors instead of throwing them?
PS: @achingbrain It is not clear from my replies, but you've good points here.

We also lose it in the current implementation I did for this API

You mean that the implementation of getMany(cids)/get(cids) goes from parallel to serial?  I think that's less of a concern for this conversation because we can fix the implementation without changing the interface, as long as the interface takes multiple CIDs in some form.

I don't think the clunky single node operation justifies adding new 3 new API calls (get, put, remove)

Not sure I agree - I think the improved DX makes it worthwhile.
The fact that the implementation adds non-standard .first, .last and .all methods to the returned generators shows you've felt the pain too..

What would you do if you want to continue with the rest of the nodes?

From an IPFS point of view It's hard to see why you'd want that.  Imagine writing a 10TB file and the first node fails.  You're not going to want to wait for the last node to be written to tell the user - Hey I'm done, by the way not all of your file made it kthxbye!
I suppose you could retry the failed nodes - if it became a requirement and there was no API available I'd just use the non-syntactic sugar version and do my own error handling.

The fact that the implementation adds non-standard .first, .last and .all methods to the returned generators shows you've felt the pain too..

Good point.

From an IPFS point of view It's hard to see why you'd want that.

I'm talking from an IPLD point of view here.

I suppose you could retry the failed nodes - if it became a requirement and there was no API available I'd just use the non-syntactic sugar version and do my own error handling.

I don't think you can resume an iterator that throws. Can you? Though you could manually keep track of the things you've already processed and then skip the one that failed. This is quite painful (as @Gozala explanations show), though I'm not sure how much of a problem that really is as it is certainly still possible somehow.

I don't think you can resume an iterator that throws. Can you?

Yes, if you don't use for await...of:
'use strict'

const iterator = {
  [Symbol.asyncIterator] () {
    return {
      i: 0,
      values: [0, 1, 2, 3],
      next () {
        this.i++

        if (this.i === this.values.length) {
          return Promise.resolve({ done: true })
        }

        if (this.i === 2) {
          throw new Error('Nerp')
        }

        return Promise.resolve({ done: false, value: this.values[this.i] })
      }
    }
  }
}

async function surviveErrors () {
  console.error('--> Will continue after error')

  const iter = iterator[Symbol.asyncIterator]()

  while (true) {
    try {
      const { done, value } = await iter.next()

      console.info('done', done, 'value', value)

      if (done) {
        return
      }
    } catch (err) {
      console.info('got an error', err)
    }
  }
}

async function exitOnError () {
  console.error('--> Will not continue after error')

  try {
    for await (const value of iterator) {
      console.info('value', value)
    }
  } catch (err) {
    console.info('got an error', err)
  }
}

async function main () {
  await surviveErrors()
  await exitOnError()
}

main()

$ node test.js
--> Will continue after error
done false value 1
got an error Error: Nerp
    at Object.next (/Users/alex/Desktop/test.js:16:17)
    at surviveErrors (/Users/alex/Desktop/test.js:32:42)
    at process._tickCallback (internal/process/next_tick.js:68:7)
    at Function.Module.runMain (internal/modules/cjs/loader.js:745:11)
    at startup (internal/bootstrap/node.js:283:19)
    at bootstrapNodeJSCore (internal/bootstrap/node.js:743:3)
done false value 3
done true value undefined
--> Will not continue after error
value 1
got an error Error: Nerp
    at Object.next (/Users/alex/Desktop/test.js:16:17)
    at exitOnError (/Users/alex/Desktop/test.js:49:26)
    at process._tickCallback (internal/process/next_tick.js:68:7)
    at Function.Module.runMain (internal/modules/cjs/loader.js:745:11)
    at startup (internal/bootstrap/node.js:283:19)
    at bootstrapNodeJSCore (internal/bootstrap/node.js:743:3)

Using iterables for single-node operations is a bit clunky - can't we just have both?

I am very much advocating for having unary operations and having a separate batch operations.

One of my goals is keeping the API surface small. I don't think the clunky single node operation justifies adding new 3 new API calls (get, put, remove).

I think size of API surface is far less important than a good API.

If you want fancy error handling strategies you can just fall back to the non-syntactic sugar version as I suggested earlier. If the syntax offends, you can just wrap it in a module and publish it.

For some reason there is a bias towards (async) iterators which I really don't understand. They introduce incidental complexity for both batch on unary operations and require user to keep track of additional local state. As I illustrated in the post you can have far better representation for batch operations that remove need for keeping track of state, pairing inputs with outputs and even can offer .retry() and .undo(). It is also certainly possible to add a method for async iterable  consumption of results.
I would really like to know what are the basis for choosing async iterators ?

This is quite painful (as @Gozala explanations show), though I'm not sure how much of a problem that really is as it is certainly still possible somehow.

Please consider that not every one is an expert and if you're API precludes that, that's a bad smell. Best APIs are the one that don't let you plug square peg into round hole

For some reason there is a bias towards (async) iterators which I really don't understand.

The reason is that at lot of IPFS/IPLD APIs are using pull-streams and async iterators are a good replacement for that.

@vmx what's the strategy for moving forward on this? FWIW I agree with @Gozala's analysis, on top of which I'd add learnability and usability concerns. Consider the code and explanation overhead in the proto.school lessons. They'd be moving from teaching what (await ipld.get(cid)).value.foo breaks down as to what (await ipld.get([cid]).first()).value.foo does.
If there's concern about burdening downstream consumers (ipfs) with having to build their own abstractions to get iterable-like functionality, just bundle those use-cases in a utility module or as helper functions (or ideally as entirely separate packages) and leave the basic API clean and singular. let resultIter = require('ipld/util').getManyParallel(ipld, cidIter) and the list of helpers could expand to cover other use cases, fail-fast, skip-missing, order-undefined, strictly-sequential, whatever. The code you have in #190 could go straight into one of those.

My current plan would be to add single and multi versions. So we would have:

get/getMany
put/putMany
remove/removeMany

This way, we have a simple interface, for single operations (like @Gozala suggested). We also need getMany() for js-ipfs so that we don't spam the DHT. So it would only be symmetric (and I like symmetric APIs) to also have "many" versions of the two other calls.
Implementation wise, the logic will be put into the single item versions and the "many"-versions will call into those. As a start it will be just sequential operations. But it leaves it open for the future to have more optimised "many"-calls.
How does that sound @achingbrain @alanshaw @Gozala @mikeal @rvagg?

@vmx sounds good. I’ll note that, long term, we’ll still end up with more usage of async iterators than straightforward single methods because even simple mutations of a graph will produce multiple block changes.

@vmx I think it's a good compromise. Longer term I would still encourage to design a batch batch operations tailor for specific use cases instead of generic async iterator.

I've updated the document. Please see the commit message as well as the new README. There's now also *Many() calls.
Can I please get an approval from @achingbrain @alanshaw @Gozala @mikeal @rvagg

Thanks a lot @Gozala for the valuable comments. I opened a few issues based on your comments so that we discuss them outside this PR and hopefully get this one merged (together with the implementation) soon.


Arduino Board Settings

Hello RandomHacks,
Which Arduino settings are you using to compile the source code?

Hi,
You need to select "Generic RP2040" on the board menu and "Adafruit TinyUSB" for the USB Stack.
BTW, I just updated the code so you might want to download the source code again.
If you just want to update the firmware without modifying anything you can use the precompiled versions here: https://github.com/RandomHacks-Git/Best-Improvement-RP2040/releases/

Hello RandomHacks,
Thank you for the information and the reference to the finished compiled version.
It would just be good to know if I ever get the idea to change or extend your code.
Are these the correct Arduino board settings?

Yes that is correct 👍


Maintain a historical record

If we use jekyll, it should be pretty easy to keep a historical status record.
It would also be pretty easy to set up a web feed!

keep a historical status record

Done!

set up a web feed

Done!


Make .api command result less verbose.

Current behavior
The result of the .api command breaks for larger fonts and smaller terminals.
Expected behavior
As taiko's API is self-explanatory, I think we just need to list it as a comma separated value. If more details are required it can be expanded with .api method
For e.g
> .api

closeBrowser, goto, reload, click, doubleClick, rightClick, hover, focus, write,
upload, press, highlight, scrollTo, scrollRight, scrollLeft, scrollUp, scrollDown,
screenshot, $, image, link, listItem, button, inputField, fileField, textField, comboBox,
checkBox, radioButton, text, contains, toLeftOf, toRightOf, above, below, near,
alert, prompt, confirm, beforeunload, intervalSecs, timeoutSecs, waitForNavigation,
to, into, browser, page, selector, relativeSelector,  RelativeSearchElement, ElementWrapper

Run `.api <name>` for more info on a specific function. For Example: `.api click`.
Complete documentation is available at https://getgauge.github.io/taiko/.

Unlike the sample above, The api must be alphebetically ordered.

Why do we need sorting? The listing is shown in the following format and I think we should keep it this way.

Browser related functions(openBrowser, closeBrowser...)
page related functions(click, hover...)
selectors(link, button...)
relative search element selectors(toLeftOf, above...)
events(alert, confirm...)
helper functions(to, into...)

Because it's easier to locate?
Let's say I need to see if there's a method to handle checkboxes, I can quickly scan.

Can't this be achieved by using find functionality in the terminal?

Linux terminals (i think even the default macos one) does not have a find option.

Alphabetically ordered
$, above, alert, beforeunload, below, browser, button, checkBox, click, closeBrowser,
comboBox, confirm, contains, doubleClick, ElementWrapper, fileField, focus, goto,
highlight, hover, image, inputField, intervalSecs, into, link, listItem, near, openBrowser,
page, press, prompt, radioButton, RelativeSearchElement, relativeSelector, reload,
rightClick, screenshot, scrollDown, scrollLeft, scrollRight, scrollTo, scrollUp, selector,
text, textField, timeoutSecs, to, toLeftOf, toRightOf, upload, waitForNavigation, write

Order mentioned here
openBrowser, browser, page, closeBrowser, goto, reload, click, doubleClick, rightClick,
hover, focus, write, upload, press, highlight, scrollTo, scrollRight, scrollLeft, scrollUp,
scrollDown, screenshot, $, image, link, listItem, button, inputField, fileField, textField,
comboBox, checkBox radioButton, text, contains, toLeftOf, toRightOf, above, below,
near, alert, prompt, confirm, beforeunload, intervalSecs, timeoutSecs, waitForNavigation,
to, into, selector, relativeSelector, RelativeSearchElement, ElementWrapper

I can change it to the first format but I find the second one more useful.

Looking at this, I agree. Sorry for the tangent. retain order 2

Also, consider something like this.
> .api

Browser actions:
 openBrowser, browser, page, closeBrowser, goto, reload

Page actions :
 click, doubleClick, rightClick, hover, focus, write, upload, press, highlight, scrollTo, scrollRight, scrollLeft, scrollUp, scrollDown, screenshot, $, image, link, listItem, button, inputField, fileField, textField,
comboBox, checkBox radioButton, text,

Proximity selectors:
 contains, toLeftOf, toRightOf, above, below, near

Events:
 alert, prompt, confirm, beforeunload, intervalSecs, timeoutSecs, waitForNavigation

Selectors:
 to, into, selector, relativeSelector, RelativeSearchElement, ElementWrapper


Feature Request: Persisted Queries

API Caching on CDN level is nearly impossible since there is no real support for persisted queries (=> GET requests).
Implementing the persisted queries concept would have a positive impact on usability, performance and security.
For reference: Persisted Queries in NodeJS

The library is low level and should not care about persisted queries. It's up to the developers to decide how to use the library. Remember this is not a fully featured GraphQL framework. It is just a minimalistic library that can parse/validate/execute queries. I am closing this issue for now.


refactor(log_store): remove associated type Namespace in LogStore

I hereby agree to the terms of the GreptimeDB CLA.
Refer to a related PR or issue link (optional)
#4026
What's changed and what's your intention?

Remove the associated type Namespace in the LogStore trait
Change KafkaLogStore's read method behavior. Let the read method return entries in the namespace(instead of entries belonging to a specific region)

Checklist

[x] I have written the necessary rustdoc comments.
[x] I have added the necessary unit tests and integration tests.
[ ] This PR requires documentation updates.

@v0y4g3r PTAL


jenkins.model.Jenkins default value breaks empty context form round trip

https://github.com/jenkinsci/extension-filter-plugin/blob/33202c8708d46c2e57466ecbb4a2d7e10620363c/src/main/java/org/jenkinsci/plugins/Exclusion.java#L23 and https://github.com/jenkinsci/extension-filter-plugin/blob/33202c8708d46c2e57466ecbb4a2d7e10620363c/src/main/java/org/jenkinsci/plugins/ConfigurableExtensionFilter.java#L92 indicate it should be possible to have a null context.
https://github.com/jenkinsci/extension-filter-plugin/blob/33202c8708d46c2e57466ecbb4a2d7e10620363c/src/main/resources/org/jenkinsci/plugins/ConfigurableExtensionFilter/global.jelly#L12 breaks round-trip behavior, as it will replace a null value with jenkins.model.Jenkins on subsequent form submissions.
JenkinsRule#configRoundtrip can help write a test.

Thanks I will try to take a look at it unless someone pick it before.
Plugin need other refresh (example https://github.com/jenkinsci/extension-filter-plugin/issues/54)


source code

thanks for your wonderful job,Will the code be open sourced soon？

Hi there, thanks so much for your interest!
The code has been under review for release since yesterday. It will be made public soon!
Best,


[WIP] Use R 4.0.0 in AppVeyor for Apache Spark 3.1.0

What changes were proposed in this pull request?
This aims to see the readiness for R 4.0.0 at Apache Spark 3.1.0.
Why are the changes needed?
R 4.0.0 is released on April 24th, 2020.

https://stat.ethz.ch/pipermail/r-announce/2020/000653.html

Does this PR introduce any user-facing change?
No. (This PR aims to test R 4.0.0 in AppVeyor environment.)
How was this patch tested?
See the AppVeyor result.

Test build #121854 has started for PR 28353 at commit 313a2be.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder-K8s/26526/
Test PASSed.

Test build #121855 has started for PR 28353 at commit f9fc332.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder-K8s/26527/
Test PASSed.

Test build #121856 has started for PR 28353 at commit 27642f6.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder-K8s/26528/
Test PASSed.

Test build #121855 has finished for PR 28353 at commit f9fc332.

This patch fails Spark unit tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test FAILed.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/121855/
Test FAILed.

Test build #121854 has finished for PR 28353 at commit 313a2be.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/121854/
Test PASSed.

Test build #121856 has finished for PR 28353 at commit 27642f6.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/121856/
Test PASSed.


Fix RectilinearToPixel for multi-devices situations

Summary
This merge request fixes the RectilinearToPixel function in multi-devices situations. LeapC.cs had an outdated signature and there were no implementation of RectilinearToPixelEx. The changes in these commits have been tested and confirmed to work but might require more testing to ensure that it works in all situations.
It is highly recommended to implement PixelToRectilinearEx before merging this branch
Contributor Tasks

[ ] Pair review with a member of the QA team.
[ ] Add any release testing considerations to the MR for the next release.
[ ] Check any relevant CHANGELOG files have been updated.
[ ] Ensure documentation requirements are met e.g., public API is commented.
[ ] Consider any licensing/other legal implications for this MR e.g. notices required by any new libraries.
[ ] Add any relevant labels such as breaking to this MR.
[ ] If this MR closes a Jira issue, make sure the fix version on the JIRA issue is set to the correct one.

Reviewer Tasks
Use emojis in review threads to communicate intent and help contributors.

[ ] Code reviewed.
[ ] Non-code assets e.g. Unity assets/scenes reviewed.
[ ] Documentation has been reviewed. Includes checking documentation requirements are met and not missing e.g., public API is commented.
[ ] Checked and agree with release testing considerations added to MR for the next release.

Closes JIRA Issue
Closes UNITY-857

I have fixed my code according to your suggestion. As stated in the request, I have only implemented RectilinearToPixel for multi-devices, as I only needed to fix this one. I would highly recommend implementing PixelToRectilinear for multi-devices for features parity.


Add APIServerSession w/ refresh

I tested this manually by removing rows from db sessions and user_pubkey_auth tables then restarting the service.  Gregor connect worked.

cc @maxtaco


Add localtime template tag

Fixes #37
This requires adding the time-elements script (https://github.com/github/time-elements) to the pages this is used on.

Can you rebase this branch? CI was broken previously.

Regarding:

This requires adding the time-elements script (github/time-elements) to the pages this is used on.

At a minimum, this needs to be documented in the localtime docstring.
However, I think we need to provide more support for downstreams to use this library. How about a second template tag, which could be used within the page <head>, to add the appropriate <script>?

I'd love for this to be upstreamed and agree with @brianhelba 's suggestions.

This is a working incantation for getting the library from CDN:
<script type="module" src="https://unpkg.com/<EMAIL_ADDRESS>


Deprecated on PHP 8.1

Describe the bug
Deprecated: Return type of _HumbugBox87c495005ea2\KevinGH\RequirementChecker\RequirementCollection::getIterator() should either be compatible with IteratorAggregate::getIterator(): Traversable, or the #[\ReturnTypeWillChange] attribute should be used to temporarily suppress the notice in phar:///cecil.phar/.box/src/RequirementCollection.php on line 15

Deprecated: Return type of _HumbugBox87c495005ea2\KevinGH\RequirementChecker\RequirementCollection::count() should either be compatible with Countable::count(): int, or the #[\ReturnTypeWillChange] attribute should be used to temporarily suppress the notice in phar:///cecil.phar/.box/src/RequirementCollection.php on line 19

To reproduce

PHP 8.1
Cecil 5.79.7

docker run -it --rm php:8.1-cli bash -c "curl -LO https://cecil.app/cecil.phar && chmod +x cecil.phar && ./cecil.phar new:site"

Same on macOS with PHP 8.1.1 (cli) (built: Dec 17 2021 22:38:05) (NTS)
Expected behavior
No Deprecated messages
Version
5.79.7
Operating System
No response
Relevant log output
No response

Hello @ensimo, thanks for your report.
I'm working on a new release to support PHP 8.x, but this is a problem with the way I build PHAR: box-project/box#562. The PR to fix it (box-project/box#578) is already in progress.
I'm waiting :-)

Work in progress (finally) : the last beta (6.0.0-beta.6) is now working with PHP 8.1 (and PHP 8.2).
While waiting for the stable release (certainly tomorrow), you can test the preview via:
cecil self-update --preview

Hello @ensimo, Cecil finally support PHP 8.1+ with the last release 🥳
cecil self-update


add demos

add two demos:
road network

I've created json files for input and config. You can check road.py

EMA network
Same. I've assumed the constant avg speed for the arcs.
I've used n1 -> n3 for OD pair as I don't know much about the network.
Please try some other pairs.
To run:
(bns) hyeuk@LT-73476:/mnt/c/Projects/BNS_JT$ python -m BNS_JT.demos.EMA.batch
Let me know your thoughts.

Wow this is amazing. I am running wth an OD pair 'n22' and 'n53' now for it is one of the most challenging pairs as both nodes are connected to so many edges. It is still running generating many rules.
I will spend some more time playing around with the code : D


Add Contact us page

Is your feature request related to a problem? Please describe.
The website currently lacks a "Contact Us" page, which is important for user communication and support. A dedicated "Contact Us" page should be added to allow users to reach out for inquiries or support.
Describe the solution you'd like
A functional "Contact Us" page with:
A user-friendly form including fields for Name, Email, Subject, and Message.
Backend support for receiving and processing submissions.
A confirmation message or email notification upon successful submission.
Describe alternatives you've considered
An alternative could be integrating a contact form directly into the footer of the website instead of a standalone page, or using a pop-up form triggered by a "Contact" button.
Additional context
The page should align with the overall design and theme of the website. A reference for design inspiration could be the current design deck page at https://design-deck.vercel.app/.

@jahnvisahni31 As i can see there is no update on this feature , so can you please assign it to me , so that I can complete this fast
'

already someone has done that

i was working on it :)


Feature: API should only allow Wi-Fi config requests over Ethernet interface

overview

As a user, I don't want my robot's Wi-Fi configuration to be messed with by anyone who does not have physical access to the robot
As a user, it is confusing when I change my robot's Wi-Fi network to a network I am not on because it is difficult to figure out if I succeeded

In order to prevent Wi-Fi configuration by users who are not physically connected to the OT-2, the Wi-Fi configuration endpoints should be blocked on the wireless network interface.
acceptance criteria

[ ] Calls to Wi-Fi config requests over the Ethernet interface should succeed
[ ] Calls to the config endpoints over Wi-Fi should 403

implementation notes

The SSH key endpoints are only accessibly over link-local IP addresses, which is similar to this functionality as described
TODO: decide what desired behavior is for requests over Ethernet from non-link-local addresses (e.g. robot is on a wired network with a DHCP server)

┆Issue is synchronized with this Wrike Task by Unito

Bug triage determination: LMM


Bump selenium-webdriver to 3.142.6

https://trello.com/c/aQbqH2uC/1196-vulnerability-fix-weekly-tracking
Snyk alerted us that our version of rubyzip (a dependency of selenium-webdriver) had a vulnerability. https://app.snyk.io/org/digital-marketplace/project/fb32c449-df7b-4456-897b-f3fa8c9a17c1
Bumping the (selenium gem) addresses this in the Gemfile.
Tests seem fine when running locally, hopefully Jenkins will be fine too?

Redoing the nix freeze...


Re-enable HTTP/2 server

HTTP/2 support, which has been dropped since #377 for some reason, now becomes available.

It turns out that this problem was caused by LLVM 17.0.0 (https://github.com/rust-lang/rust/commit/443c3161dd04f4c1b656a626f9079921bee9c326) and fixed by LLVM 17.0.5 (https://github.com/rust-lang/rust/commit/dd430bc8c22f57992ec1457a87437d14283fdd65).


Automatically update command documentation

Currently, the main README lists all of the commands and is auto-updated.
But the docs/commands/* docs are not auto-updated and many commands are not documented.  It would be nice to improve the automation to keep these docs up to date.

@iplay88keys wrote a test to ensure that the ReadMe is updated and includes all the commands. We'll continue to iterate on this to create more robust documentation. Closing this for now. We've created stories in our backlog to broaden om documentation.


Filter by outgoing IP

How to filter by outgoing IP?
Example with blocking www.reddit.com by domain name is great, but you know, it does not block a smart user, who can connect to IP instead or to another domain pointing to target IP.
My goal is to block private ranges (<IP_ADDRESS>/8, <IP_ADDRESS>/16, ...) for a malicious user won;t be able to get access to infrastructure. That also implies blocking of domains like <IP_ADDRESS>.xip.io or any other resolving to private IP range.
It is tricky to do using iptables without containerizing goproxy, as on the same machine the could be other daemons which should not be blocked.
So a hook inside goproxy after domain resolution seems adequate here.
Is it possible to set up such a hook?

I ended up with
  proxy.Tr.Dial = func(network, addr string) (c net.Conn, err error) {
    tcpaddr, err := net.ResolveTCPAddr(network, addr)
    if err == nil {
      if allowConnectTo(tcpaddr.IP) {
        log.Printf("Tr.Dial %s, %s -> %s", network, addr, tcpaddr)
      } else {
        log.Printf("Tr.Dial %s, %s -> %s -! badip", network, addr, tcpaddr)
      }
      c, err = net.Dial(network, tcpaddr.String())
    } else {
      log.Printf("Tr.Dial %s, %s -! %s", network, addr, err)
    }
    return
  }


Kibana 6.4.0 crashes with fatal error

When using 6.4.0 RC images, Kibana fails to start, crashing with this message:
FATAL "elasticsearch.password" setting was not applied. Check for spelling errors and ensure that expected plugins are installed.

Here is a script to reproduce the error:
#!/bin/bash

set -xeuo pipefail

version=6.4.0
build=89d563cd
products='elasticsearch kibana logstash apm-server auditbeat filebeat heartbeat metricbeat packetbeat'

for product in ${products}; do
  curl https://staging.elastic.co/${version}-${build}/docker/${product}-6.4.0.tar.gz | docker load
done

sed -i "s/6[.][0-9][.][0-9]/${version}/" .env

docker-compose -f setup.yml up -d
watch docker logs kibana

I'm trying to determine if something has changed with the use of the keystore in Kibana 6.4.0, or if there is a problem with the 6.4.0 RC Docker image.

This should be resolved with https://github.com/elastic/kibana/pull/22022


[v3] firestack.database() is not a function error - documentation error

In several places in .md files for this library, firestack.database().ref('someNode/')... is recommended but I kept getting an error that firestack.database() was not a function. I opened the firestack object and indeed couldn't find such a function. I had to go into FirestackApp, the example working app, to see how they had done it just to realise that firestack.database.ref('someNode/')...  - ie. without trying to invoke firestack.database ...works...
This is where the objective is simply to write an entry to database.

I would try to update docs myself and make a PR but it's in multiple places and also in Salakar's fork and maybe others so thought I'd make an Issue for now and see what people think.

@tam-borine v3 branch on here has been re-synced with my fork - the docs should be correctly saying to use database() - main point of my fork is to have it match the firebase web api - so the docs can therefore be minimal. \o/
I believe @Ehesp was also doing some work on the docs?

@Salakar I've been using the firebase JS library as follows...
import firebase from 'firebase'
import config from './firebaseConfig'

firebase.initializeApp(config)

export const albumsRef = firebase.database().ref('albums/v1-0')

I just tried  pulling down the v3 branch and swapping out firebase for react-native-firebase:
import firebase from 'react-native-firestack'
import config from './firebaseConfig'

firebase.initializeApp(config)

export const albumsRef = firebase.database().ref('albums/v1-0')

However, I'm getting an error _reactNativeFirestack2.default.database is not a function
I tried deleting my node_modules folder and reinstalling as well as react-native unlink / link, but the problem persists. Is there any additional config that I need to do in the v3 branch?

@smkhalsa it's not swapped out correctly, you need to empty the existing dir before pulling down - otherwise there's a mash of files.  e.g. database.js vs database/index.js

@Salakar Do you know when it will be released?
Thanks.

database.js seems to be still in the v3 repo and overrides database/index.js See here: https://github.com/fullstackreact/react-native-firestack/blob/v3/lib/modules/database.js
This is also the cause for this issue: https://github.com/fullstackreact/react-native-firestack/issues/220

@moooji see https://github.com/fullstackreact/react-native-firestack/issues/220#issuecomment-271256869

Looks like database.js has been removed by @auser in the v3 repo. I guess this can be closed now.


double click on FileMosaic opens an alert

Describe the bug
When double clicking on the FileMosaic an alert will show with the text "double click on file", I provided my own onDoubleClick to the component, but it doesn't override the default function but I'm still able to call my custom function.
To Reproduce
Steps to reproduce the behavior:

Render this code
<Dropzone            onChange={updateFiles}            value={files}            accept=".csv"            maxFiles={1}          >            {files.map((file: ExtFile) => (              <FileMosaic                key={file.id}                {...file}                onDelete={removeFile}                info={true}                onDoubleClick={() => {                  console.log("hi there");                }}              />            ))}          </Dropzone>
upload something in the dropzone
double click on the FileMosaic
An alert will show up with the text "double click on file"

Expected behavior
A clear and concise description of what you expected to happen.
Screenshots

I'm using @files-ui/react: 1.0.5

Hi @JuanPabloOS, thanks for the alert.
We are sorry for the inconvenience.
Could you please upgrade to @files-ui/react 1.0.8?
That's the latest version in which we have already solved this issue.
Please, tell us if that worked for you:
Thanks in advance! 🎆

Hey @JuanPabloOS , we hope you solved the problem by updating the library. 🚀
If not, feel free to open the issue again!
Sincerely.

Hi guys, thank you very much for the support!
On Tue, Apr 4, 2023, 10:55 AM JinSSJ3 @.***> wrote:

Hey @JuanPabloOS https://github.com/JuanPabloOS , we hope you solved
the problem by updating the library. 🚀
If not, feel free to open the issue again!
Sincerely.
—
Reply to this email directly, view it on GitHub
https://github.com/files-ui/files-ui-react/issues/5#issuecomment-1496302414,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AKEBK5YZZHJWJE5NL6KGONLW7RHAVANCNFSM6AAAAAAWMK574Q
.
You are receiving this because you were mentioned.Message ID:
@.***>


Make creation of default External API group configurable

This PR makes the default group creation of the external api configurable.

@lkiesow Quick explanation: The External API group loader will create an EXTERNAL APPLICATIONS group for each organization if it doesn't exist. If you have a different set of groups already, this might be annoying, so SWITCH patched it out. I thought it might be nice to be able to turn this off.

Because it's a configuration that can anyone activate/deactivate, I will merge it


[router] Don't bid if RPCs failing

Currently routers can leave users in a Preparing state if they cannot get RPC requests/responses to go through. There should be a system to track error rates on RPC calls and refuse to respond to auctions if they are too high (indicating a node has gone down)

Couldn't we do something more simple and just do a simple health check at the time of auction?

Run provider calls to make sure.


melonloader fails to find the file "System.Runtime"

All of the following criteria must be met

[X] All Requirements must be installed.
[X] Changed the title so that it doesn't just says "[Bug]: "
[X] I have searched the GitHub issues for my bug, even in the closed issues.

All of the following are optional to answer

[ ] Tried reinstalling the Game.
[x] Tried reinstalling MelonLoader.
[ ] Tried restarting PC.
[x] Was able to see the Start Screen.

Describe the issue.
hi, the game is bonelab it worked until yesterday, and now don't work any more idk what happend, beacuse i didn't modify anythink...
i tried to remove the incriminated mods but same problem for every mod...
Latest.log
Did you attach your log file?
Yes, I attached my log file to the text box above.

we are in two having this problem

Bonelab got updated, community will be moving to MelonLoader 0.6. Please ask in your local Bonelab modding server for more information.


Can't deploy Jaeger on AWS EKS using Calico

Describe the bug
Jaeger deployment on AWS EKS running Calico CNI fails with below error:
Internal error occurred: failed calling webhook "mjaeger.kb.io": Post "https://jaeger-operator-webhook-service.monitoring.svc:443/mutate-jaegertracing-io-v1-jaeger?timeout=10s": Address is not allowed

Expected behavior
Jaeger instance deploys successfully.
Additional context
I faced similar issue installing jaeger-operator. Fix was on cert-manager side, I had to set hostNetwork: true on deployment.

Question is... where to set hostNetwork, and if it's possible to change port used by webhook in case I run into conflicts.
I did run into conflict with cert-manager, but switching ports on that one was very easy.

Ok... I was able to make it work.
Had to:

add hostNetwork: true to operator deployment spec
change health port from 8081 to something else (I used 10270)
change kube-rbac-proxy secure port from 8443 to something else (I used 10280)

I had to leave webhook listener port on 9443 because I wasn't able to find a flag that would allow operator to listen on different port than 9443. I was lucky enough, I don't have anything else listening on that port...


Simple object Detection

Pull Request for DL-Simplified 💡
Issue Title : Simple object Detection

Info about the related issue (Aim of the project) :The aim of the project is to build neural network which is able to detect objects in frame.
Name: Manish Kumar Gupta
GitHub ID: manishh12
Email ID<EMAIL_ADDRESS>Idenitfy yourself: (Mention in which program you are contributing in. Eg. For a JWOC 2022 participant it's, JWOC Participant) GSSOC'24 Contributor

Closes: #734
Describe the add-ons or changes you've made 📃
The project successfully explored various object detection models and techniques using the Simple Object Detection Dataset. By comparing the performance of different models, valuable insights were gained into their strengths and weaknesses, aiding in informed decision-making for future object detection tasks.
Type of change ☑
What sort of change have you made:

[ ] Bug fix (non-breaking change which fixes an issue)
[x] New feature (non-breaking change which adds functionality)
[ ] Code style update (formatting, local variables)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
[ ] This change requires a documentation update

Checklist: ☑

[x] My code follows the guidelines of this project.
[x] I have performed a self-review of my own code.
[x] I have commented my code, particularly wherever it was hard to understand.
[x] I have made corresponding changes to the documentation.
[x] My changes generate no new warnings.
[x] I have added things that prove my fix is effective or that my feature works.
[ ] Any dependent changes have been merged and published in downstream modules.

@abhisheks008 Could you please review this pull request? I've implemented five models, so kindly assign the appropriate labels accordingly. Thank you!


Evaluator Issue.

SEALContext context(parms);
print_parameters(context);
cout << endl;

KeyGenerator keygen(context);
auto secret_key = keygen.secret_key();
PublicKey public_key;
keygen.create_public_key(public_key);
RelinKeys relin_keys;
keygen.create_relin_keys(relin_keys);
GaloisKeys gal_keys;
keygen.create_galois_keys(gal_keys);
**Encryptor encryptor(context, public_key);
Evaluator evaluator(context);
Decryptor decryptor(context, secret_key);**

====above is the basic CKKS example in SEAL's code.
So I have a thought, the evaluator has only one param which is the context. so would below computation run well? There are only one context object, only one evaluator object, two encryptors, two decryptors.
Context ctx = a context object;// only one context
Encryptor ept1 = Encryptor(ctx, pk1);
Decryptor dpt1 = Decryptor(ctx, sk1);
Ciphertext ct1 = ept1.encrypt(a);
Encryptor ept2 = Encryptor(ctx, pk2);
Decryptor dpt2 = Decryptor(ctx, sk2);
Ciphertext ct2 = ept2.encrypt(a);
Evaluator evt(ctx);// only one evalueator
encrypted_result = evt.multi_cipher(ct1, ct2); //ct1 is encrypted by ept1, and ct2 is encrypted by ep2. ept1 and ept2 are different encryptor,  while evt is the only evaluator here, would this multi_cipher function run well?
plaindata = dpt1.decrypt(encrypted_result );// would this run well?
plaintdata' = dpt2.decrypt(encrypted_result); // would this run well?

Ciphertext multiplication will run. Both decryption will fail.

Ciphertext multiplication will run. Both decryption will fail.

Fine.. that's the same as I guess as using different public key for encryption.
Well... is any way to do this? I mean each user has his own public key/private key, and encrypted his data, then any way for a cloud service to do HE computations over these encrypted data together, and at least the cloud service could decrypt the output result? no need for each user to decrypt.
For example, Alice and Bob and Cloud Service addition in Azure.
Alice has a number 1, and pk1, the number 1 is encrypted into encrypted data a;
Bob has a number 2,  and pk2; the number 2 is encrypted into encrypted data b;
a and b are sent to the Cloud Service addition in Azure for computing sum, and get a encrypted c, then the cloud service itself decrypt this c, and get the number 3. Could this be done in any ways? The point is Alice and Bob doesn't reveal his/her own number, while they don't care about the sum which is 3 in plaintext.
BR

HE alone offers data privacy to the secret key owner. What you want is a 2-party secure computing protocol, which may or may not be instantiated with HE. If HE 's involvement is a must, search for multi-key or multi-party homomorphic encryption works.

great, thanks for your answer.
BR


Forces VMs to be replaced when placement policy is destroyed

Tested:

Deploy VM with no placement
Add placement with max_distance: 1; re-deploy
Edit max_distance from 1 -> 2; re-deploy
remove placement; re-deploy

Each time it recognizes that VM must be destroyed.
Note: If one does not turn auto_delete_boot_disk: false you will still get an error on second apply as it will not find disk. This can be worked around by doing another apply. This disk issue is a known pain point that is unrelated to the placement policy error.
Submission Checklist
Please take the following actions before submitting this pull request.

Fork your PR branch from the Toolkit "develop" branch (not main)
Test all changes with pre-commit in a local branch #
Confirm that "make tests" passes all tests
Add or modify unit tests to cover code changes
Ensure that unit test coverage remains above 80%
Update all applicable documentation
Follow Cloud HPC Toolkit Contribution guidelines #

Can you wrap the array with flatten and repeat test?

I tried but I get Unexpected expression found in replace_triggered_by. or A static list expression is required..
From poking around online it looks like replace_triggered_by requires "static references" and cannot accept an expression.
Additionally the documentation for replace_triggered_by states:

If the reference is to a resource with multiple instances, a plan to update or replace any instance will trigger replacement.

So I think they have accounted for it to take a reference to a array resource, as is in this case.
I propose to leave it as is.

Spot check test failed in way that makes it seem that standard no placement policy case does not work, although this was tested manually.
I am dismissing approval so this doesn't get merged until I have a chance to debug.

While it looks like replace_triggered_by can handle an array of instances, it does not seem to handle the case when count=0. I have updated to rely on a null_resource as a proxy for a trigger. I am dubious of this methodology but wanted to put something forward that is at least working as expected.

I cannot get rid of the lifecycle on the VM. I get the following error:
Error: Error adding resource policies: googleapi: Error 400: Invalid resource usage: 'Instance must be in stopped state'., invalidResourceUsage

It looks like it still tries to modify the resource policy on the live VM instead of destroying the VM.


Problems with AppConfig

It seems that if an application is specified via AppConfig, it will not work:
INSTALLED_APPS = (
    'wiki.apps.WikiConfig'
)

For django-wiki, this produces errors like TemplateDoesNotExist: "wiki:wiki/base.html". Other variations like specifying the app config {% extends "wiki.apps.WikiConfig:wiki/base.html" %} aren't working neither.
Specified as just the app, it works:
INSTALLED_APPS = (
    'wiki'
)

I kind of gather from the implementation that it's assumed that the entry of INSTALLED_APPS is importable models and not AppConfig class paths?
https://github.com/bittner/django-apptemplates/blob/master/apptemplates/__init__.py#L18

Just found out that this works fine with django-app-namespace-template-loader, and I'm good switching to that :)

Thanks for the hint!
The issue seems to be identical to https://github.com/Fantomas42/django-app-namespace-template-loader/issues/10.

You can see the fix in the diffset between 0.3 and 0.3.1 where it was fixed: https://github.com/Fantomas42/django-app-namespace-template-loader/compare/0.3...v0.3.1

Do you want to try a PR?

No, I switched to the other app -- remember https://github.com/Fantomas42/django-app-namespace-template-loader/pull/15 ? ;)

Just checking. Thanks for reporting, anyway.


[Draft] Types package simplification

Same as last time, here's a draft PR showing the general direction of what I've done without the noise. My full changes live on the daylon/types branch, but it's 66 files changed, 1805 insertions(+), 1860 deletions(-), so it has quite a bit of noise from refactoring.
So I think, with these changes, adding a new type is now as simple as fulfilling the Value interface, and adding the new NomsKind in KindToType and KindToString in noms_kind.go. Exposing the type through SQL isn't as straightforward, but I'd like to make those same kind of changes (implement one interface for full coverage) after this project.

Messing around a bit with InlineBlob and I think I'll change it to hex instead of Base64. I wanted Base64 at first because it's more space efficient, but now that I'm seeing the tabled output, it seems more straightforward to reason that you're looking at byte data when you see hexadecimal.

Draft PR has served its purpose. Full PR: https://github.com/liquidata-inc/dolt/pull/172


smarter delete (like yEd)

This shouldn't be too hard, but will take some time. Please ping me if you'd like to work on it.
yEd has a more useful delete feature than draw.io, but we should be able to reproduce the same behavior.

[ ] if group is expanded and deleted, only remove the group and not its children
[ ] if a group is collapsed and deleted, delete the group and anything nested inside it
[ ] make sure that undo functionality still works

desired yEd behavior:

current bad draw.io behavior:

I'm currently using javascript: https://github.com/StateSmith/StateSmith-drawio-plugin/blob/main/StateSmith-drawio-plugin.js
At some point I'd like to switch to typescript if it will help make development easier.
I'll be recording a video in a day or so to help explain how to get started hacking on the plugin. Are you interested in helping work on this issue?

yes i want to work on this issue

awesome! Did you want to join our discord https://discord.gg/rNxNGQXWsU ? Or we can use github discussions: https://github.com/StateSmith/StateSmith-drawio-plugin/discussions


Create Issue Templates

Add to the .github folder the templates for submitting issues

Question - https://github.com/david-engelmann/DoccanoClient.jl/commit/287e56e97cb09d1856aa7d33d516514f6d127410
Bug - https://github.com/david-engelmann/DoccanoClient.jl/commit/fb646a97f9dfc288af8ce435335d0db3356233d6

Added in this pr


Consider including guidance about running ReactRedux pages as IIS sub-apps

In aspnet/templating#555 one of our users had trouble getting a react-redux app set up as a sub-application in IIS. We might want to add some instructions about how to use the homepage parameter in package.json to make that work. Details in the bug.

The problem with the homepage package.json approach as far as I can see, is that it's a static string defined at build time. So in the event that your IIS configuration changes (i.e. the sub-app is moved or renamed) you have to do a rebuild of the application which seems really bad to me. I guess you could possibly get away with manually changing the  tag in the index.html but then you're manually changing the base html to fix your IIS routing.
Imo, we need a way to make this dynamic either by having .Net generate the homepage prefix and plugging it in at runtime, or we need to refactor the template to use a index.cshtml razor view where we can expose the kestrel URL in the viewbag. Or something else?

@guardrex 	can you add a note to the appropriate doc
For information on running ReactRedux pages as IIS sub-apps, see aspnet/Templating#555
Then we can close this issue.

I'm not familiar with these technologies. Idk if this applies to the React project template, too.
@ryanbrandenburg, should I add a new section to the Use the React project template topic under the existing Publish and deploy section?


Added an awesome Git list

https://github.com/Nezteb/Git_Is_Hard#readme
It's a list containing various helpful resources and tutorials on Git. It should be included because it's awesome and contains other awesome lists in it as well
By submitting this pull request I confirm I've read and complied with the below requirements 🖖
Please read it multiple times. I spent a lot of time on these guidelines and most people miss a lot.
Requirements for your pull request

You have to review at least 2 other open pull requests. Try to prioritize unreviewed PRs, but you can also add more comments to reviewed PRs. Go through the below list when reviewing. This requirement is meant to help make the Awesome project self-sustaining. Comment here which PRs you reviewed. You're expected to put a good effort into this and to be thorough. Look at previous PR reviews for inspiration.
I have read and understood the instructions for creating a list.
This pull request has a descriptive title in the format Add Name of List (Example: Add Swift), not Update readme.md or Add awesome list.
The entry in the Awesome list should:

Include a short description about the project/theme of the list. It should not describe the list itself.Example: - [Fish](…) - User-friendly shell., not - [Fish](…) - Resources for Fish..
Be added at the bottom of the appropriate category.

The list I'm submitting complies with the below requirements.

Requirements for your Awesome list

Has been around for at least 30 days.That means 30 days from either the first real commit or when it was open-sourced. Whatever is most recent.
It's the result of hard work and the best I could possibly produce.
Non-generated Markdown file in a GitHub repo.
Includes a succinct description of the project/theme at the top of the readme. (Example)
The repo should have awesome-list & awesome as GitHub topics. I encourage you to add more relevant topics.
Not a duplicate.
Only has awesome items. Awesome lists are curations of the best, not everything.
Includes a project logo/illustration whenever possible.

Either centered, fullwidth, or placed at the top-right of the readme. (Example)
The image should link to the project website or any relevant website.
The image should be high-DPI. Set it to maximum half the width of the original image.

Entries have a description, unless the title is descriptive enough by itself. It rarely is though.
Includes the Awesome badge.

Should be placed on the right side of the readme heading.

Can be placed centered if the list has a centered graphics header.

Should link back to this list.

Has a Table of Contents section.

Should be named Contents, not Table of Contents.
Should be the first section in the list.
Should only have one level of nested lists, preferably none.

Has an appropriate license.

That means something like CC0, not a code licence like MIT, BSD, Apache, etc.
WTFPL and Unlicense are not acceptable licenses.
If you use a license badge, it should be SVG, not PNG.

Has contribution guidelines.

The file should be named contributing.md. Casing is up to you.

Has consistent formatting and proper spelling/grammar.

The link and description are separated by a dash. Example: - [AVA](…) - JavaScript test runner.
The description starts with an uppercase character and ends with a period.
Consistent and correct naming. For example, Node.js, not NodeJS or node.js.

Doesn't include a Travis badge.You can still use Travis for list linting, but the badge has no value in the readme.

Go to the top and read it again.

Looks like this repo has a lot of valuable resources! Your README and the resources within would be easier to browse through if you used descriptive links instead of just the URL itself.
For example,

About Gitlab

instead of

https://about.gitlab.com/


How to set section title color??? No api for this

If I want to change color of text of the section in drawer list, how to do that, I do not see any api for that.
It will be great if you provide apis like getView() getTitleTextView, getNotificationTextView() or simple setTitleTextColor() etc etc.

If you want to set all sections colors you can customize your drawer, check the Theming page
You can also add a section color, that allows you to set the color of the section when it is selected.

Hey thank you for the quick reply,
Yes I know that, what if I want same section color  but different section title color. For doing this I did
View view = materialSectionActions.getView();
TextView textView = (TextView) view.findViewById(R.id.section_text);
if (textView != null) {
textView.setTextColor(getResources().getColor(R.color.font_gray_dark));
}
something like this... now if you check above code, I needed to mention "R.id.section_text" which is there in your library.
One more thing, when I click on empty space in drawer below the top sections, the view behind it (views inside fragment) gets clicked. So how to handle this?

@niketkadde for programmatical methods please wait for the next release.
The other bug you have found there is an opened issue -> #146

Okay thanks for that. :+1:

1.3.1 released
you can use this method: setUsernameTextColor for the username (first line)
and setUserEmailTextColor for the second line


Bump version number to 0.1.18

I accidentally pull requested onto main so I thought, "Eh, what the heck, let's just bump the version number..."

I'm screwing this up faster than I can think


[PE-D][Tester A] Incorrect error message for edit commmand

I keyed in edit cs2222 /M cs2223 and the software gives out the following error message:

However, it seems to me that the error is input wrong code prefix.

Labels: type.FeatureFlaw severity.Medium
original: DerrickSaltFish/ped#6

Fix check for presence of prefixes before checking module code validity. Similar fix for #147, #150.


Frontend feedback (misc)

remove "progress bar" misconception
make customize link more prominent
change verbige for unreleased features
check font for subheader
don't hide options but grey out

Add more details about public vs private workflow


Send Transaction Confirmation Email on Submit

Once a transaction has been completed, send user an email noting the following:

Greeting: Hello ,
Subject: Transaction receipt from MidAtlantic Babywearing
Body:
Check out these pointers...
https://www.youtube.com/watch?v=rfJvWBh7KPw
https://midatlanticbabywearing.org/babywearing-safety/
https://docs.google.com/document/d/1AxWPN7ACTVN76glH8wAllX5ggs2HwC0cwgBshJz_tnQ/edit?usp=sharing
You can also get a fit check on our facebook group.
Please keep the following for your records:

Item Information
Check-Out Date
Check-In Due Date
Location

Thank you for using MidAtlantic Babywearing.

@abronkema how is this different from #168 ?

@pollygee - it isn't! closing :)


ImportError: No module named lcm

The visualizer gets the following failure when I try to run it:
$ make superbuild
...
$ ./build/install/bin/drake-visualizer
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/home/blegat/git/director/build/install/lib/python2.7/dist-packages/director/drakevisualizer.py", line 3, in <module>
    from director import lcmUtils
  File "/home/blegat/git/director/build/install/lib/python2.7/dist-packages/director/lcmUtils.py", line 1, in <module>
    import lcm
ImportError: No module named lcm

When you make superbuild it compiles with a minimal configuration, without lcm.  Here's how you can enable lcm on your existing build:
$ cd build
$ cmake -DUSE_LCM=ON .
$ make -j2
Or, if you're familiar with the ccmake tool, you can run that in the build dir and browse the other options, too.

It works, thanks !
Isn't scrolling supposed to zoom in/zoom out ?

hold right-click and move the mouse up and down to zoom

That makes sense, left-click to rotate, right-click to zoom, middle-click to move :)


Duplicate of https://github.com/companieshouse/acsp-manage-users-web/pull/102

https://github.com/companieshouse/acsp-manage-users-web/pull/102 was merged into a sub branch, not main.
This PR targets and will be merged into main.

CI: No security warnings found