CAT broke 'knock to unlock' app

CAT is working just fine on my MBP 15" 2011 with an IOGEAR 4.0 usb dongle.
handoff, instant hotspot, and airdrop are working just fine.
my problem is with knock to unlock app, that after the installation of CAT is no longer working.
the iphone won't connect with the mac (with the usb bluetooth dongle). what's the problem? maybe the kext patch? how can i solve it?
i've already reinstalled the iOS and OS X companion app, unplugged and plugged in again the dongle but nothing changes.
please help, knock was very useful and time saving.
sorry for the bad english.

Hi, could you please verify if the steps described in #122 solve your issue and then  report back?
Sent from my iPhone

On 13 janv. 2015, at 19:48, MrZar0<EMAIL_ADDRESS>wrote:
CAT is working just fine on my MBP 15" 2011 with an IOGEAR 4.0 usb dongle.
handoff, instant hotspot, and airdrop are working just fine.
my problem is with knock to unlock app, that after the installation of CAT is no longer working.
the iphone won't connect with the mac (with the usb bluetooth dongle). what's the problem? maybe the kext patch? how can i solve it?
i've already reinstalled the iOS and OS X companion app, unplugged and plugged in again the dongle but nothing changes.
please help, knock was very useful and time saving.
sorry for the bad english.
—
Reply to this email directly or view it on GitHub.

unfortunately it doesn't work. the wifi stop working so i've reinstalled CAT to solve the problem, now i'm back with the same issue, handoff and the other continuity features works, knock to unlock doesn't.

If it's helpful, I just encountered some version of this problem while using a early 2011 Macbook Pro 15" with the IOGear Bluetooth 4.0 USB adapter.
I was able to resolve it by uninstalling CAT, rebooting, running and pairing Knock, rebooting again, then reinstalling CAT and rebooting yet again. (I'm not sure the middle reboot was necessary.)
Anyway, after doing that both Knock and Continuity/Handoff seem to be working. If there's anything I can supply to help in troubleshooting, I'd be happy to help.


Add MOTD command

Command for adding a new MOTD.
Test with https://github.com/ScilifelabDataCentre/dds_web/pull/1136
Before submitting a PR to the dev branch:

[ ] Tests passing
[ ] Black formatting
[ ] Rebase/merge the dev branch
[ ] Note in the CHANGELOG

Additional checks before submitting a PR to the master branch:

Change version in dds_cli/version.py (?)

Looks good and works as expected!


To Capture a Screenshot

Summary
What: Page Screenshots
Ability to take page and element screenshots. possibly time-stamped but with option to provide filename
Why:
Taking screenshots is a good way to document UI tests
Acceptance Criteria
Below is a list of tasks that must be completed before this issue can be closed.

[ ] Write documentation
[ ] Write unit tests
[ ] Write integration tests
[ ] {add more checkboxes required by this issue as needed}

Example Pseudo Code (for implementation)
sinco.takeScreenshot(params?:{})// Add example pseudo code for implementation

Please Assign it to me 👍 .

I think screenshot As a method name is more descriptive and easier to type, what do you think?

Yes true, lemme edit that

maybe takeScreenshot?

Yeah I think either works well :)


fix: Add package name

What
add package name to top level package.json in order to enable checking out specific commits from npm/yarn/pnpm. Previously if you were referencing a specific commit in your package.json it would fail with the following error.
 ERR_PNPM_MISSING_PACKAGE_NAME  Can't install git+https://github.com/run-llama/LlamaIndexTS.git#1bd47969b37c86a226f10d1e1a6498de798ca39c: Missing package name. By adding the name property to the top level package.json this error goes away.

Why
This enables developers to experiment with features that are not yet published to NPM.
Testing

I created a test app to demonstrate this. clone this repo and checkout this branch: https://github.com/owencraston/test-app/pull/1
checkout this commit: https://github.com/owencraston/test-app/pull/1/commits/48541659e5d7373b69357868708e8990322913b6
run pnpm install
you should get the error:  ERR_PNPM_MISSING_PACKAGE_NAME  Can't install git+https://github.com/run-llama/LlamaIndexTS.git#1bd47969b37c86a226f10d1e1a6498de798ca39c: Missing package name
then checkout this commit: https://github.com/owencraston/test-app/pull/1/commits/4787248eb953dd8c2c51763c5e0ee07a53ac6d36. This is the commit hash for this PR.
run pnpm install. there should be no errors

@owencraston have you tried pnpm link to fix your problem (testing features that are not on npm?) see https://github.com/run-llama/LlamaIndexTS/blob/main/examples/README.md#using-the-local-build

@marcusschiesser can this work in production?

@himself65 I still think we need to add A package name to the top level. this is a best practice with mono repos.

a better solution could be to have a scope: https://docs.npmjs.com/about-scopes
Then we could import from @llamaindex/core

a better solution could be to have a scope: docs.npmjs.com/about-scopes Then we could import from @llamaindex/core

yes, I'm thinking about that too, package name on top is a good sugession. will add that

While "@llamaindex/core" might be slight more semantically correct in the future, it would add significantly more friction to the new user experience (not to mention breaking existing users' code). @owencraston could the same result be achieved if we just name the top level package.json "@llamaindex/gitrepo" ?

OK apparently with monorepos there's no great way to enable the kind of functionality we're looking for: https://stackoverflow.com/questions/39194648/npm-install-package-from-github-repo-subfolder I'm still not opposed to adding a name to the package.json if that fixes your particular use case, but it might not be something we want to support in general.

@yisding @himself65 I went ahead and changed the name to @llamaindex/monorepo following the example of this well maintained repo.


Added IRSA functionality in AWS code

:gear: Issue
Enable Terraform Code to create IAM Roles for Service Account (IRSA)
:white_check_mark: Fix

Renamed nomad_auto_scaler (boolean) to enable_irsa (map)
enable_irsa is expecting 3 key values to create Role
If the length of enable_irsa is greater than 0, terraform will create IRSA else Static User credentials will be created

:question: Tests

[x] Passed IRSA Creation for Nomad

@soulchips Yes, Currently, It will either create a User or Role. Do we want to give an option where nothing is created?


x/tools/go/packages: Config.Env doesn't support -modfile

% go version
go version go1.17 darwin/amd64
% cat main.go go.mod
package main

import (
	"log"
	"os"

	"golang.org/x/tools/go/packages"
)

func main() {
	_, err := packages.Load(&packages.Config{
		Mode: packages.NeedName | packages.NeedFiles | packages.NeedImports | packages.NeedDeps,
		Env:  os.Environ(),
	}, ".")
	if err != nil {
		log.Fatal(err)
	}
}
module example.com

go 1.17

require golang.org/x/tools v0.1.6

require (
	golang.org/x/mod v0.4.2 // indirect
	golang.org/x/sys v0.0.0-20210809222454-d867a43fc93e // indirect
	golang.org/x/xerrors v0.0.0-20200804184101-5ec99f83aff1 // indirect
)
% go run .
% GOFLAGS=-modfile=go.mod go run .
2021/09/20 08:48:46 err: exit status 1: stderr: build flag -modfile only valid when using modules
exit status 1

I'd like to support GOFLAGS=-modfile=... from tools that use packages.Load, but perhaps more concerning is that the error message indicates some go tool commands are run in non-module mode.

@golang/tools-team

go/packages runs a number of Go command invocations, not just one, so the -modfile flag won't work when set through an environment variable. We can't clear out the value of GOFLAGS when running the first go list to get the Go version, which is why you get this error. Can you set -modfile through the BuildFlags field in the config instead?

go/packages runs a number of Go command invocations, not just one, so the -modfile flag won't work when set through an environment variable. We can't clear out the value of GOFLAGS when running the first go list to get the Go version, which is why you get this error.

Isn't the point of GOFLAGS to affect all go tool invocations, and be ignored for the irrelevant? From the error message (build flag -modfile only valid when using modules) it seems the problem is that x/packages run non-module commands. If that's unavoidable, perhaps the go tool should ignore GOFLAGS=-modfile instead of complaining. I found a similar case where GOFLAGS=-modfile is ignored: https://go-review.googlesource.com/c/go/+/258297.

Can you set -modfile through the BuildFlags field in the config instead?

Not for my use case, where I want a command line tool (gogio) to act as a wrapper for the go tool:
$ GOFLAGS=-modfile=... go build gioui.org/example/kitchen                  # regular build
$ GOFLAGS=-modfile=... gogio -target android gioui.org/example/kitchen     # wrapped build

The issue is that https://pkg.go.dev/golang.org/x/tools/internal/gocommand#GoVersion runs with GO111MODULE=off. I'm not totally sure why--I believe that @heschi wrote this code, so maybe he knows?

@hyangah pointed out that https://github.com/golang/go/issues/34273 is likely the reason for this. We will consider ignoring GOFLAGS for this go list invocation.

Any progress on this issue?
Same problem running golangci-lint using GOFLAGS=-modfile=...


xSQLServer: Remove support for WMF 4.0 (PowerShell 4.0)

Are there users out there that still needs WMF 4.0?
Should we remove support for WMF 4.0 and makes this module WMF 5.x only? Meaning that if it works for WMF 4.0, then great, if it doesn't then we won't make an effort to make it work.
To support PowerShell 4.0 across the entire module will require a lot of work.
We have discussed this in various issues. We have also discussed this in the Community Calls where it was said, more or less, that generally it's okay to only support WMF 5.x, but if a resource can support PowerShell 4.0 then that would be better.

@johlju My thoughts are WMF 4 support can be dropped. There should be no reason why anyone hasn't upgraded their servers to WMF 5.1 (better performance and better security) unless your running Exchange and no one runs SQL Server on an Exchange Server. Your spending a lot of your time trying to maintain WMF 4 support. Your time is precious. If someone really wants WMF 4 support they can always download the older versions of xSQLServer.

When I submit the pull request for the availability group database membership resource, that will force the module to require WMF 5. I wrote it as a class based resource. I'm working on the unit tests now which are proving to be fun!

@Zuldan I though along those lines as well, that they can download an old version. Just want to make sure it is not an overwhelming need for WMF 4.0. But I would be surprised if it was.
@randomnote1 Do you mean the entire module, just not that resource? If you actually mean the entire module will require WMF 5.x, then that will tip the scale in favor of removing support for WMF 4.0.
Just curious what makes the entire module require WMF 5.x? Is it something in the .psd1 and how the module will be loaded?
@randomnote1 I'm looking forward to seeing that resource and the tests! It will be a new experience reviewing that code. 😄

Yes, the entire module. PowerShell 4 can't import the module if there's is a class based resource referenced in the psd1.
Doing the review will be interesting. There will be a few decision points required.

Ah great @randomnote1. Then we can't support WMF 4.0 anymore. I will do that in the PR I'm working on now. Then I can clean out a lot of code and texts.


 Could you sign the ICLA first? https://feedback.line.me/enquete/public/799-Z6ygVz3U

signed ICLA

@shelocks Left a comment which might affect the API of your contribution.

Thanks for working on this :) With HTTP2, client-side balancing is indeed essential to the practicality of armeria.
We do have a (IMO hacky) client-side balancer internally that I have not tried pushing upstream because

It uses armeria as a library rather than integrating directly in. I feel like it can be much more clean (e.g., no proxy) if actually part of the library. I feel like what server to send a request to can be part of the transport layer rather than the invocation layer. But maybe it doesn't really matter either way (the thought of replacing the authority on a client didn't occur to me, and still strikes me as a bug in the library or at least a hole in the documentation).

Server selection strategy is not configurable. Mainly since in the end everyone usually just ends up picking simple round-robin, but for a general-purpose library exposing the right interfaces is definitely sound.

Health check could be smarter.

Anyways, please do take a look to see if there are any ideas in this that are useful for a properly armeria-integrated solution. API-wise, if nothing else, we will probably need a way for specifying a health-check mechanism for the server group nodes (here it's just a list of servers populated by health-check requests).
https://gist.github.com/anuraaga/a1ee7f2489718a5462a90c31afbfe01b

Clear separation between ServerGroup and NodeSelectStrategy

How about removing ServerGroup.select() and other stateful properties related with NodeSelectStrategy from ServerGroup?
When registering a ServerGroup, a user could specify both ServerGroup and NodeSelectStrategy, and the ServerGroupInvoker could get them later.

This way, the responsibilities of the two interfaces would be separated more clearly. It also allows a user register the same set of nodes with different strategies.

Make StaticServerGroup immutable and introduce a builder. e.g.

ServerGroup g = new StaticServerGroupBuilder().host(...).host(...).host(...).build();

Introduce an interface ServerGroup and make StaticServerGroup implement it, so that we can allow a user build his/her own ServerGroup implementation.

Once this is done, we could discuss about smaller issues like class names, parameter names, documentation, etc.
Once this is merged, we could use it as a starting point for adding more features to the client-side load balancer, such as 1) using a circuit breaker (or something similar) as a backoff strategy and 2) adding support for dynamic server groups whose node weights change over time.

Health check could be smarter.

Agreed. I wonder if we can use our circuit breaker implementation or its variant (by making it have a pluggable health-check mechanism)
I think it's probably better keeping this PR as simple as possible as a starting point though, since we can do the health check part as a follow-up PR.

/cc @synk due to the mention on using a circuit breaker as a backoff strategy (with some modification)

@trustin @anuraaga Thanks for your quick code reviews! I did some modifications:

Now ServerGroup only contains server nodes info.
Make StaticServerGroup immutable and introduce a builder(StaticServerGroupBuilder).
Add a class NodeSelector which contains ServerGroup info and NodeSelectStrategy.We can also add    health check(or smart node select) logic during the next development iteration.What do you think about this?

For NodeSelectStrategy API,may has two forms:
public interface NodeSelectStrategy {
    /**
     * Return selected node.
     */
    Node select();

}

and
public interface NodeSelectStrategy {
    /**
     * Return selected node.
     */
    Node select(List<Nodes> nodes);

}

For the first form,we can imply that implementation class must hold nodes info and can avoid repetitive computation,but API's intent is not clear(Why selected a node?I didn't set candidate nodes).
For the second form,maybe we need to recompute some states when invoking method,but API's intent is clear.So which one is better?I would like to hear your advice.

@shelocks As I mentioned in this comment We could make the NodeSelectStrategy a factory of NodeSelector, so that the NodeSelectStrategy implementation does not keep the node list by itself and NodeSelector keeps the node list and the state of strategy (e.g. random variable, last index variable)

@trustin,sorry, I didn't get the point of "NodeSelectStrategy as a factory of NodeSelector".Here is some
pseudo code.
public interface NodeSelector {
    Node select();
}

public interface NodeSelectStrategy {
    NodeSelector newSelector(ServerGroup serverGroup);
}

public class RoundRobinStrategy implements NodeSelectStrategy {
    @Override
    public NodeSelector newSelector(ServerGroup serverGroup) {
        return new RoundRobinSelector(serverGroup);
    }

    private class  RoundRobinSelector implements NodeSelector{
        private ServerGroup serverGroup;

        //other state info
        ...

        RoundRobinSelector(ServerGroup serverGroup){
            this.serverGroup = serverGroup;
        }

        @Override
        public Node select() {
            ....
            return selectedNode;
        }
    }
}

Is this code correct? This is just move the previous RoundRobinStrategy's logic to RoundRobinSelector.
I thought the NodeSelector should be a composite class which can combine the ServerGroup with different NodeSelectStrategy to implement different select node logic,not directly implement it.

@shelocks Yes. ...Strategy is merely a factory.

Did proposed refactoring.

Add the node type hierarchy.
Implement NodeSelectStrategy as a factory pattern.

CI build failed does not relate to commit.

@trustin Thanks for your code review.Fix the codes which your comments refer to.

@shelocks Thanks for your patience. It's getting better and better. :-)  I have a few things on the table now:

Is there a better name for Node?

After thinking a little bit more, I guess we need to parameterize StaticServerGroup:

public class StaticServerGroup<T extends Node> implements ServerGroup<T> {
    public StaticServerGroup(T... nodes) { ... }
    public StaticServerGroup(Iterable<? extends T> nodes) { ... }
    ...
}

I'm not sure what we should do about StaticServerGroupBuilder. It always creates a StaticServerGroup of WeightedNode. Should we keep it as it is or rename it to something else?
@anuraaga Care to review again?

ServerNode or HostNode?
Parameterizing StaticServerGroup is necessary.If StaticServerGroup parameterized,StaticServerGroupBuilder also need to parameterize.Like this?

public final class StaticServerGroupBuilder<T extends Node> {
    private List<T> nodes = new ArrayList<>();

    /**
     * Add a host to this server group.
     */
    public StaticServerGroupBuilder<T> host(T serverNode) {
        nodes.add(serverNode);
        return this;
    }

    public StaticServerGroup<T> build() {
        return new StaticServerGroup<>(nodes);
    }
}

or just remove this class,when need StaticGroupGroup instance just invoke StaticServerGroup's constructor function.
@trustin what do you think?

Parameterizing StaticServerGroup is necessary.

Then it doesn't really have any advantage over instantiating via the constructor of StaticServerGroup:
new StaticServerGroup<WeightedNode>(new DefaultWeightedNode(...), ....);\
// or..
List<WeightedNode> list = new ArrayList<>();
list.add(...);
list.add(...);
new StaticServerGroup<WeightedNode>(list);

Update the codes which the comments refer to.

@shelocks Do you remember my comment about using the hostname (or authority) part of a URI as a server group name instead of adding a new field? I think we can define a way to determine the authority of a URI is a real host name or a server group name to achieve that. WDYT? /cc @anuraaga

yes,i'm also struggle with the Clients API design.Maybe keep the current api not change is better,add some documents to explain the server group usage.I will update later.

@shelocks Let me stay tuned to your change then.

@trustin  code updated, could you take a look?:)

I thought about renaming, and here's my suggestion:

Node -> ServerAddress
NodeSelectStrategy -> ServerSelectionStrategy
NodeSelector -> ServerSelector
NodeSelector.serverGroup() -> group()
ServerGroup.nodes() -> addresses()

What do you think, @shelocks @anuraaga ?

@shelocks Mostly trivial comments. I feel like this is gonna be merged after one or two rounds. Great job! :+1:

@trustin  For renaming,i have some suggestions for your reference.
Node -> ServerNode
ServerGroup.nodes() -> servers()
The ServerNode is more expressive if we want add more info to this class in the future.But this is only my personal opinion:)
The others,look good to me.

@shelocks After thinking a little bit more, it seems to me that making these class names start with Server might be confusing to users because it could give them an impression that they are server-side classes.
How about using the term Endpoint instead?

Node -> Endpoint
NodeSelectStrategy -> EndpointSelectionStrategy
NodeSelector -> EndpointSelector
NodeSelector.serverGroup() -> group()
ServerGroup -> EndpointGroup
ServerGroup.nodes() -> endpoints()

LGTM，i will update later.

1)Using the term 'Endpoint' for all class names.
2) Define naming rules for the endpoint group name in the URI.

@shelocks Left some trivial comments. I think it's ready for a merge. Could you squash your commits into one as well?

@trustin addressed your comments,please take a look :)

@shelocks Sorry for asking again, but could you update the commit message so that it includes the related issue number? e.g.
Implement client-side load balancer

Related issue: #87

This commit adds the initial implementation of the client-side load balancer
API, which allows a user to:

- define a named group of endpoints and its load-balancing strategy, and
- use the named group in the 'host' part of a client URI

Example:

    EndpointGroupRegistry.register(
            "myGroup",
            new StaticEndpointGroup(
                    new DefaultWeightedEndpoint("<IP_ADDRESS>", 8080),
                    new DefaultWeightedEndpoint("<IP_ADDRESS>", 8080),
                    ...),
            EndpointSelectionStrategy.WEIGHTED_ROUND_ROBIN);

    SimpleHttpClient client =
            Clients.newClient("none+http://group:myGroup/foo/bar",
                              SimpleHttpClient.class);

@trustin sorry for that,updated commit message,thanks!

Thanks for working on this - in general LGTM, I just did a small round to tweak comments / javadoc.

@anuraaga thanks for your reviews! Update the codes which your comments refer to.

LGTM

@shelocks :+1: Thanks for your patience and hard work. It's been merged now! :-)

@trustin @anuraaga @kojilin thanks for your reviews and help.I would like to continue to contribute the follow-up features like failover strategy,service discovery and so on.

@shelocks Looking forward to them!

Getting into instagram


Use explicit return types in code samples.

Though using auto result = ... is perfectly idiomatic, the purpose of the examples is to show how the functions are used, we should be explicit in them, e.g.:
namespace cbt = google::cloud::bigtable;
using google::cloud::StatusOr;
[](Table table) {
  StatusOr<std::pair<bool, cbt::Row>> row = table.ReadRow("foo");

That makes the example more readable to our customers. This gets even more important for more complex return types, such as:
namespace cbt = google::cloud::bigtable;
using google::cloud::StatusOr;
[](Table table) {
  future<StatusOr<std::pair<bool, cbt::Row>>> row = table.AsyncReadRow("foo");

Assigning to @remyabel so nobody else will start on it (they already did).  @remyabel please let me know if you want me to un-assign this issue.

You can unassign me. It was fairly tedious doing the PR (even though I was using YCM to get the type of each expression) so others may prefer to tackle individual files.

Create a checklist for myself:

[ ] bigtable_hello_app_profile.cc
[ ] bigtable_hello_world.cc
[ ] bigtable_instance_admin_snippets.cc
[ ] bigtable_quickstart.cc
[ ] data_async_snippets.cc
[ ] data_snippets.cc
[ ] instance_admin_async_snippets.cc: in #2610.
[ ] table_admin_async_snippets.cc
[ ] table_admin_snippets.cc


Feat(openaiclient): add Option for custom HTTP client

This MR adds a variadic Option to the OpenAI client, allowing for future customizations. It also adds the WithHTTPClient option that allows setting custom HTTP clients.
Closes #90
PR Checklist

[x] Read the Contributing documentation.
[x] Read the Code of conduct documentation.
[x] Name your Pull Request title clearly, concisely, and prefixed with the name of primarily affected package you changed according to Good commit messages (such as memory: add interfaces for X, Y or util: add whizzbang helpers).
[x] Check that there isn't already a PR that solves the problem the same way to avoid creating a duplicate.
[x] Provide a description in this PR that addresses what the PR is solving, or reference the issue that it solves (e.g. fixes #123).
[x] Describes source of new concepts.
[x] References existing implementations as appropriate.
[ ] Contains test coverage for new functions.
[ ] Passes all golangci-lint checks.
[ ] (remove and do not use this row unless you are a trusted contributor) I am an existing
contributor.

@tmc you reckon this needs tests?

@tmc I think the lint job timed out 🤔

@tmc I think the lint job timed out 🤔

Yeah, we had a poisoned cache so I disabled caching, I'll turn it back on.

I'm new to go and  confused that why not add WithHttpClient in the  llms/openai/openaillm_option.go ，cause  can't  call internal package  llms/openai/internal/openaiclient/openaiclient.go


java.lang.SecurityException: Permission Denial: reading android.support.v4.content.FileProvider uri content://com.packagename.provider/external-path/FolderName/Image_20170207_152529.jpg from pid=0, uid=10008 requires the provider be exported, or grantUriPermission()

in Helper class when uploading image from camera capture on below line i am getting above exception.
cursor = context.getContentResolver().query(uri, projection, selection, selectionArgs, null);
Let me know if any workaround is there

@shishram have you enabled permissions to read / write files for your app on your device?

Yes I have added already the problem was not running it on UI thread, but
this is fixed now. Thanks.
On Thu, Feb 9, 2017, 2:21 PM Terry Kwon<EMAIL_ADDRESS>wrote:

@shishram https://github.com/shishram have you enabled permissions to
read / write files for your app on your device?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/smilefam/SendBird-Android/issues/10#issuecomment-278582042,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ADylfDl8bCLUACzf0CJN5WzxDaypcR9xks5ratOmgaJpZM4L5R-d
.

@shishram that's great to hear! I'll close the issue then.

Sure.
On Thu, Feb 9, 2017, 2:34 PM Terry Kwon<EMAIL_ADDRESS>wrote:

@shishram https://github.com/shishram that's great to hear! I'll close
the issue then.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/smilefam/SendBird-Android/issues/10#issuecomment-278584848,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ADylfMTQ2L1Atzkr_6v8xrxuR4tvXlkoks5ratargaJpZM4L5R-d
.


Maximum update depth exceeded when using useColorPicker

Hi,
I'm using version 2.0.17 with react 18.1.0 and as soon as I call useColorPicker, I get a maximum update depth error.

Is there a way to fix this ?
Thanks

We are seeing this in both React 17 and 18. Here is a React 18 code Sandbox with just your demo code in it: We will need to go back to version 2.0.10
https://codesandbox.io/s/eloquent-cloud-oiq2hg

I did a diff between v2.0.10 and v2.0.11 and I don't see anything obvious. There were a lot of changes to enable the new  width prop. It would take while learning the code and to debug it. I'm not sure I will have the time to dedicate to find it.

Thats no good, I will take a look tonight.

@BentleyDavis & @jpdery thanks for pointing this out, it seems to have slipped through the cracks. I'm not exactly sure what updates were breaking, or better said I'm not sure how that function ever worked, but it was any easy fix. See version 2.0.19.
Happy coding!


Example for upload/download progress

hey, was wondering if it's useful (or already possible) to access the write progress when sending a Request/Response. Assuming the following code (with data holding a lot of data):
info!("(upload) send: {:?}", data);
let url = core.run(client.call(data.into()));
info!("(upload) got: {:?}", url);

I would like to be able to print a progress bar. I think tokio is aware (internally) how much of the data has been successfully sent, and also knows how large the request is (the difference of bytes before and after calling MyCodec::encode with my request).
I understand this is probably a large change/too large of a change, hopefully this might be interesting input for the revamp in the later case. :)

Thanks for the report.
As a result of the Tokio RFC, tokio-proto is going to be significantly simplified. As such, this kind of feature will be out of scope.


[WIP] Changelog Sprint 53

129 PRs
link to azure changelog
link to amazon changelog
[skip ci]

@miq-bot add_label documentation

@miq-bot add_label wip

Need to fix links, remove extra spaces

@miq-bot remove_label wip

@Fryguy please close this!!!

Close or merge?

Merge.
Sent from my iPhone
On Feb 1, 2017, at 12:06 PM, Jason Frey<EMAIL_ADDRESS>wrote:
Close or merge?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/ManageIQ/manageiq/pull/13695#issuecomment-276716747,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ADn8Dqok6rmICMX3uMjf6xY-49OmBucwks5rYLuugaJpZM4LxyRP
.


2nd attempt to fix DREAMS

Changes to TER_atmosphere.data:

Use unix-style line endings everywhere (hence every line being apparently changing)
Change wavelength_unit to nm
Remove duplicate wavelength lines
Extend atmosphere to be far beyond the reach of the J filter to prevent rounding errors

Produces attached figure:

Some more changes, in particular:

Make the PSF larger, because it was less then 1 pixel, which does not work well with ScopeSim
Hack to make the Field of View larger. Should only be necessary until https://github.com/AstarVienna/ScopeSim/pull/433 is merged


U — [WebAPI] DOM general, Fx 75 tasks

Trello
https://trello.com/c/aBs1o6Pg/86-dom-general-enhancements-fx-75
Acceptance criteria

[ ] Ensure click() works on input elements which are disconnected from a document

Small update; 0.5 points I reckon.


luci-app-statistics: Add initial support for DSL status.

Handle data for lantiq dsl metrics.

I have now had a look at it.
I must say I don't have dsl plugged into my system.
That means there are only state_num, power_state_num and uptime and I get the following image.

This is because I Only have the following rrd files on my system.
root@VR2-106149 /tmp/rrd/VR2-106149/dsl # ls -la
drwxr-xr-x    2 root     root           100 Jul 12 10:47 .
drwxr-xr-x    9 root     root           180 Jul 12 10:47 ..
-rw-r--r--    1 root     root          7096 Jul 12 15:59 gauge-power_state_num.rrd
-rw-r--r--    1 root     root          7096 Jul 12 15:59 gauge-state_num.rrd
-rw-r--r--    1 root     root          7096 Jul 12 15:59 uptime-uptime.rrd

The 3 other needed files are missing and so no rrd values could be read for image rendering.
The question now is, how can we solve this so that these artifacts do not appear with a non-existent rrd file?

Finally managed to get back to this. PR updated, now only shows the graphs for which collectd has data -- if DSL was never connected it only shows the "DSL Line Uptime" graph, since that's the only one it has data. Once DSL gets connected and collectd starts to gather data for the other values (i.e. creates the other rrd files) the other graphs will show up.
Another approach would be to always show all graphs and instead change the collectd script to always report all data, and use zero values for the ones that are currently not available. Would that be preferrable?

Thanks for this. And sorry for the delay I overlooked this. I pushed it directly to master via
https://github.com/openwrt/luci/commit/a1741bd13b3747f7ef9dd05d0b8dd29d4da46f86 and merged the two commits to one.
Should we also backport this openwrt-23.05?

Added #6453 for enabling translations, and address the title issue that was mentioned in the code comments on in a1741bd13b3747f7ef9dd05d0b8dd29d4da46f86#r120400575
I think it would be nice to have this in 23.05. Should I create a PR for that or do you simply cherry-pick?

@bluebrother I cherry-picked the requested changes to openwrt-23.05 with the following commits
https://github.com/openwrt/luci/commit/43b8c23e51c2262a98e6c73a6643c20760165f33
https://github.com/openwrt/luci/commit/2d23a3674939a78646f5e44eaa0522fabc859201
https://github.com/openwrt/luci/commit/2c7b34bd7b80023c2833bc7e007616840d1f20cc

Hello,
DSL status currently available in luci-app-statistics?
I have lantiq/xrx200 OpenWrt SNAPSHOT r24256-1d6f9bdfc0 but I didn't see anything in the settings.

Please have a look at https://github.com/openwrt/packages/blob/master/utils/collectd/Makefile#L535

Thank you.
I tried to do something manually but I guess there is nothing I can do.
collectd-mod-lua, libubus-lua installed. I know the location of dsl.lua but the lua plugin does not appear in "Statistics > Setup ".

As far as I can remember, the plugin cannot be configured, only the source is available.
You have to update the collectd.init to process this plugin as https://github.com/openwrt/packages/blob/master/utils/collectd/files/collectd.init#L486 does. Or you could add the missing config  lines to a separate config file for collectd, so the file gets loaded. This is a missing feature. Pullreqeusts are welcome.

I entered the lines related to the lua plugin in the collectd.conf file but without success. Also, the lua settings in collectd.con disappear every time the device restarts.
I hope soon dsl status will be available with collectd.
Thank you for reply.


feat: add commitlint support

i would love to see https://github.com/conventional-changelog/commitlint integrated in ths action

Hi @timomayer can you explain this a bit more? commitlint lints commit messages while this action is intended to lint code.

Closing due to lack of feedback.


Create Simple-Fizzbuzz.py

Thank you for your PR!
Unfortunately a solution similar to yours has already been submitted :/
The goal is to find creative/abstract new solutions to FizzBuzz.
See The top 5 samples here.
Thanks anyway! :)


total data loss :) again

i guess i cant use this module in production.
i cant understand what caused that. must be unstable in some situations.
this morning :
docker volume rm xxx
caused all data to be deleted on the the remote server...
what i exactly did was
#> docker-compose -p A up -d
volume created a_xxx
#> docker-compose -p B up -d
volume created b_xxx
#> docker-compose -p A down
#> docker-compose -p B down
#> docker volume rm a_xxx b_xxx
total data loss :)

i did remove other volume later without data loss.
so im not sure this command does shit in the soup.
but i have no data left

me too today, all my data are loss after running docker-compose down -v
@rafipiccolo did you find a way to figure out this issue ?
is there any way to bind the volume in the remote server so it will persist forever ? is readonly volume could fix the issue ? I'm just mounting existing data to the container, so I don't have any new generated data to be stored in my remote server

sadly no. i still consider using another storage driver but it needs time to study.

Same problem here.
I'm not able to provide any logs, sorry

I would be happy to help but I don't know how to reproduce this problem

Thanks, it would be nice to have some insights / solutions :)
The code source is only 300lines of code. So from reading it through, with my in existent go knowledge, I guess the destructive part is the remove function . Is this code ever needed ?
https://github.com/vieux/docker-volume-sshfs/blob/1e0cd2fcb72d6af0a2ad4689faed8c312124517c/main.go#L114

Maybe there is a problem in docker codebase, that it tries to delete every file before deleting the volume?

What's the rationale for calling os.RemoveAll from Remove?
https://github.com/vieux/docker-volume-sshfs/blob/v1.4/main.go#L128

I just tested this out and did not lose any data. The setup:

Red Hat Enterprise Linux Server release 7.9 (Maipo)
Kernel 3.10.0-1160.53.1
Docker Server 20.10.12
fuse-sshfs 2.10.1

And here's the test (essentially, had to redact/simplify for obvious reasons):
# Install the plugin with debug mode enabled
$ docker plugin install vieux/sshfs DEBUG=1

# Create a volume with the new driver
$ docker volume create \
    -d vieux/sshfs \
    -o sshcmd=sftptestaccount@ftp.example.com:/ \
    -o password='<SNIP>' \
    sftptestaccount_volume

# Verify that the volume can be mounted, listed, has the correct structure, etc.
$ docker run --rm -v sftptestaccount_volume:/data testing-image tree -L 2 /data
/data/
├── testdir1
│   └── file1
└── testdir2
    └── file2

# Remove the volume. Separately, verify that contents were not deleted (FTP server-side).
$ docker volume rm sftptestaccount_volume

# Re-create the volume, re-run, and verify contents are still visible
$ docker volume create \
    -d vieux/sshfs \
    -o sshcmd=sftptestaccount@ftp.example.com:/ \
    -o password='<SNIP>' \
    sftptestaccount_volume
$ docker run --rm -v sftptestaccount_volume:/data testing-image tree -L 2 /data
/data/
├── testdir1
│   └── file1
└── testdir2
    └── file2

# Finally, delete the test volume for good…
$ docker volume rm sftptestaccount_volume

The debug logs don't show anything worth mentioning.
The full call chain from os.RemoveAll is long and has quite a few breakpoints, notably on what is essentially Remove(rootpath). My guess is that sshfs implements that as a noop, or maybe "sometimes" as a noop, I'm not sure. Would need to do a bit more digging to be sure.
The question still stands, though — is that call actually necessary? Why not just unmount and not worry about deleting data? (Or, perhaps, making that configurable on the volume, something like DeleteContentsOnRm = false). It's worth noting that Trident, NetApp's high-profile Docker/Kubernetes volume driver, does not actually delete your data when removing a volume.

FWIW, it looks like Amazon's ECS volume driver unmounts before removing which seems like the right semantics here and wouldn't do any harm — the volume protocol plugin docs for Remove say “delete the specified volume from disk”, but I take that to mean cleaning up any resources the volume's using on the host, not unconditionally deleting data on external systems. (I could be wrong.)

I have the same problem.


Remove unnecessary ModeShape dependencies

Resolves: https://jira.duraspace.org/browse/FCREPO-2868
What does this Pull Request do?

Non-functional updates.
Removes unnecessary ModeShape code and dependencies

How should this be tested?

The application should work as before... but with less ModeShape baggage.

Interested parties
@fcrepo4/committers

I can confirm @whikloj's assessment.  Looks good.


An slightly improvements in dimensions support in mapProxy.

When I has deployed some WMS-based configuration I found that the mapProxy has a very limited support of dimensions. In fact dimensions supported only in WMTS service and only with preconfigured values. So I wrote small improvements which added initial support of dimensions for WMS-based services and improve WMTS dimensions support.
This pull request contains next improvements:

added dimension support in answer on WMS GetCapabilities requests (I changed appropriate templates);
added some properties of dimension like 'unit', 'using current value' and so on;
dimension values now can be obtained as a result of parsing answer on GetCapability request to designated source;
added option to define period in seconds between dimension values updates.

To minimize changes in mapProxy  I wrote lazyList decorator (util/lazylist.py) and used it to periodically data updates.
I'm beg my pardon for  bad English

Thanks for you work.
Please read http://mapproxy.org/docs/nightly/development.html before you continue to work on this patch.
I also suggest you to split this into multiple patches:

Extend dimension options
Add dimensions to WMS capabilities
Add support for updating the dimension values

For the last point: MapProxy never makes any requests for the source capabilites in normal operation (only mapproxy-util) and I'm not sure if I'd like to change this. I think it's best to discuss this in a separate issue.


Added doc_cfg where appropriate and silenced warnings when building the docs

#56 - Added doc_cfg where appropriate and silenced warnings when building the docs
Fixes #56
Description
Please include a summary of the change and which issue is fixed. Please also include relevant motivation and context. List any dependencies that are required for this change.
List here your changes

Added #[cfg_attr(docsrs, doc(cfg(...)))] where appropriate in order to properly document conditionally compiled items with --all-features (cargo +nightly rustdoc --all-features --open -- --cfg docsrs).
Silenced warning: unclosed HTML tag DIR by properly enclosing raw text.

Type of change
Please select relevant options.

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

Checklist

[x] My code follows the contribution guidelines of this project
[x] I have performed a self-review of my own code
[x] I have commented my code, particularly in hard-to-understand areas
[x] My changes generate no new warnings
[x] I formatted the code with cargo fmt
[x] I linted my code using cargo clippy and reports no warnings
[x] I have added tests that prove my fix is effective or that my feature works
[x] I have introduced no C-bindings
[x] I increased or maintained the code coverage for the project, compared to the previous commit

Acceptance tests
wait for a project maintainer to fulfill this section...

[ ] regression test: ...

Any ideas what's wrong? I don't think I've touched anything other than the documentation in this brach.

@veeso I checked the logs, it says something about unknown user and unknown issuer. I don't think that the checks failed due to the introduced changes.

yeah, it's okay. Thank you very much for this contribution


Deployment script for v3 account removal CF template

It would be helpful for us to have a deployment script to be able to run multiple account removal CF templates at once.  Siemens has 215 accounts to remove from v3 and tends to do them in batches of 10.  That makes for a lot of repeated entries.  We would like a script where you could input the values for the CF template and then pass it a list of accounts.  This list will need to include both the Account ID and the AWS Account Number.  All the other values should remain the same for all the accounts in a single run of the script.  Once you've provided all the values, the script should deploy one CF template per account you've provided.  Please let me know if you have any questions.
deploy_account_clean_public_subnet.cf.yml.zip

Sorry I missed this. This should normally go through ZenDesk and then I can prioritise and add the issue onto the board.

Done offline


How do I uninstall cursor-vip

Thanks you for test app. How do I uninstall your cursor-vip app ?

https://github.com/kingparks/cursor-vip/issues/14#issuecomment-2526998110


Preventiv fix on Object destruction

List of fixes on strange &QObject::destroyed usage

Download:
Environment: QT=5.12, ARCH=32, PYTHON_PATH=C:\Python37
Environment: QT=5.12, ARCH=64, PYTHON_PATH=C:\Python37-x64


Update doc for env prefix

You filtered env but didn't mention it in the doc. 🥲

@dohooo thanks! can you please rebase? I just updated the docs to v2


fix: wagmi not disconnecting

Description

There was a rogue flag hasSyncedConnectedAccount which was not properly being set on time allowing for desyncs.
We were using unreliable isConnected and isDisconnected flags from wagmi. Replaced with more reliable status flag.

Type of change

[ ] Chore (non-breaking change that addresses non-functional tasks, maintenance, or code quality improvements)
[X] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)

Associated Issues
For Linear issues: Closes APKT-921
Checklist

[ ] Code in this PR is covered by automated tests (Unit tests, E2E tests)
[X] My changes generate no new warnings
[X] I have reviewed my own code
[X] I have filled out all required sections

Closing this due to this fix https://github.com/WalletConnect/web3modal/pull/2751


Added GetConfigEnum and SetConfigEnum to ConfigSection

Added support for semi reading and writing enums.
Made GetConfig work with sub sections by using '.' character.

What are the practical advantages of using this over just having an "EnumStringify"-function with a big switch-case for all the buttons etc?

Just wait with adding this pr until I have added stuff for the controllers as well (since you added that first).

I dont really know. Probably so that the enums can be decided at runtime too.

There we go, it should support Gamepad buttons and axises too now 😄

I dont really know. Probably so that the enums can be decided at runtime too.

Yeah, question is if that is ever going to be needed, or if this is a little over-engineered in that sense? Just a thought.

Currently no the runtime ability isn't used anywhere, but you never know what will happen in the future.
But if you really want it to use a function instead for getting the name of an enum value, then I guess I might change it to do that instead.
In that case should I just make it take a function pointer or a std::function?

I think you misunderstand me. I'm wondering why we need to tell GetConfigEnum which enums there are, when the enum could just as well be stored in the input system itself.
I haven't taken a deep look at this input binding system so you'll have to excuse me, but I feel like it's very convoluted for what it does. In the end, all I wish for is that this system is intuitive for people to use.

So the GetConfigEnum function takes a std::vector<std::pair<T, std::string>> as the enum values because the way it works is that it reads the config as usual, after getting the string value of the config it goes through the list of enum values and finds the correct one. And returns the T value from that std::pair, such that it's possible to combine the index and location values from the config into a more intuitive way of formatting the config.
So the config file would look more like this:
[audioInput]
playWav = Key.1
playMp3 = Key.2
playFlac = Key.3

[inMenu]
closeMenu = Gamepad.Y

[onFoot]
openMenu = Gamepad.Y
lookX = Gamepad.LeftTrigger
lookY = Gamepad.RightTrigger

Instead of this:
[audioInput.playWav]
index = 49
location = 0

[audioInput.playMp3]
index = 50
location = 0

[audioInput.playFlac]
index = 51
location = 0

[inMenu.closeMenu]
index = 3
location = 2

[onFoot.openMenu]
index = 3
location = 2

[onFoot.lookX]
index = 4
location = 2

[onFoot.lookY]
index = 5
location = 2

And the enums are stored in the input system's InputHandler.cpp file at the bottom.
Right under the very amazing comment //PLEASE GOD NOOOO:

Ah, I see. So the "enums" are not known at compile-time?

No they are known at runtime.
Since C++ still have no proper way to stringify an enum.

Okay, so back to my original question. Why can't we have a function that stringifies the enums? A function that can be globally accessible from the GetConfigEnum function so that we don't have to pass the vector.

Or rather, why can't the InputNames variable be accessed from the GetConfigEnum function globally?

So this is the functions inside the ConfigSection.h file if you need it to understand some things.
// Sets a config value with an enum value name.
template <typename T>
void SetConfigEnum(const std::string& key, T value, const std::vector<std::pair<T, std::string>>& enumNames) {
  auto itr = enumNames.begin();
  while (itr != enumNames.end()) {
    if (itr->first == value) {
      SetConfig(key, itr->second);
      break;
    }
    itr++;
  }
}

// Gets the element T that the config's value was the same as.
template <typename T>
T GetConfigEnum(const std::string& key, T def, const std::vector<std::pair<T, std::string>>& enumNames) {
  std::string defName = "";
  auto itr = enumNames.begin();
  while (itr != enumNames.end()) {
    if (itr->first == def) {
      defName = itr->second;
      break;
    }
    itr++;
  }
  if (itr == enumNames.end()) return def;

  const std::string& configValue = GetConfig(key, defName);

  itr = enumNames.begin();
  while (itr != enumNames.end()) {
    if (itr->second == configValue)
      return itr->first;
    itr++;
  }
  return def;
}

As you can probably see it requires all the names of all the enum values to figure out what the actual return value should be in the GetConfigEnum. For the SetConfigEnum having an enum stringify function would work pretty ok, but it wouldn't really work for the getter though.
And I believe that the Config System shouldn't really know that the Input System exists, because if anyone wants to extract the Config System for their own projects then it would work in their own project with little to no errors.

All right. I'll try and adapt the GetConfigEnum to try and visualize my solution:
// Gets the element T that the config's value was the same as.
template <typename T>
T GetConfigEnum(const std::string& key, T def) {
  const std::string defName = FindDefName(def);
  if (defName.empty()) return def;

  const std::string& configValue = GetConfig(key, defName);
  return FindConfigValue(configValue);
}

In above example, FindDefName and FindConfigValue are global functions that performs a switch on a defined set of values.
Granted, I thought this system was for the input system and the input system only. If you want this to be generic, then I understand why you need to pass the look-up table to the function. But if we're calling these functions a lot each frame then it might be nicer to the cache.

I do understand that it's not great for doing it each frame, but it's a config system and it should only ever be used a few times.
It's not a system that should ever run every frame, due to writing to a file for instance.
Oh no the system should be available to anything really.
I mean it's also in use for shaders too, since I wanted the shaders to be read and parsed without writing code for a specific shader it uses the config system to store the shader's attributes and uniforms so if you look at src/Game/Assets/Shaders/debugShader.ini that config file holds all the attributes and uniforms that the DebugShader uses.
And without the GetConfigEnum function it would be very difficult to write the shader config files.
Due to having to figure out the enums index which isn't that intuitive, instead it would now use some generic names for the different uniform types.
Though I don't really know if the names I chose are the best, but here's the list so you can give me feedback on them:
std::vector<std::pair<UniformType, std::string>> UniformTypeNames = {
  { UniformType::FLOAT, "Float" },
  { UniformType::FLOAT_VEC2, "FVec2" },
  { UniformType::FLOAT_VEC3, "FVec3" },
  { UniformType::FLOAT_VEC4, "FVec4" },
  { UniformType::INT, "Int" },
  { UniformType::INT_VEC2, "IVec2" },
  { UniformType::INT_VEC3, "IVec3" },
  { UniformType::INT_VEC4, "IVec4" },
  { UniformType::UINT, "UInt" },
  { UniformType::UINT_VEC2, "UVec2" },
  { UniformType::UINT_VEC3, "UVec3" },
  { UniformType::UINT_VEC4, "UVec4" },
  { UniformType::FLOAT_MAT2, "FMat2" },
  { UniformType::FLOAT_MAT3, "FMat3" },
  { UniformType::FLOAT_MAT4, "FMat4" }
};

Ah, okay! Then all is good here. Sorry for the confusion. I feel well informed now 😊


List supported field selectors by kind

The official documentation is lacking a comprehensive list of supported field selectors.
A few mentioned here and there, like status.phase and spec.nodeName as well as the default metadata.namespace and metadata.name.
This page has a list that was up-to-date more than 10 versions ago: https://github.com/flant/shell-operator/blob/main/docs/src/HOOKS.md#fieldselector.
There should be an official document that's kept up-to-date.

/remove-lifecycle rotten

Slack channel messages 1, 2, and 3 sent seeking tech reviews

/lgtm
Technically this looks right


”Prisăcani”, ”Măcărești”, ”Moreni” are listed in the drop-down menu

Description:
When user writes ”Prisăcani”, ”Măcărești”, ”Moreni” the locations appear in the drop-down menu next to the comune and the county which is a part according to the law.
Precondition:
The website is up an running.

Step 1
Write in the search bar "Prisăcani"

Expected results
The location appears in the drop-down menu as "Sat Prisăcani, IAȘI (Prisăcani)".

Step 2
Press "x" button.

Expected results
The location was deleted from the search bar.

Step 3
Write in the search bar "Măcărești"

Expected results
The location appears in the drop-down menu as "Sat Măcărești, IAȘI (Prisăcani)".

Step 4
Press "x" button.

Expected results
The location was deleted from the search bar.

Step 5
Write in the search bar "Moreni"

Expected results
The location appears in the drop-down menu as "Sat Moreni, IAȘI (Prisăcani)".


Error when deleting preview site before deleting PR

Originally reported by @MarkXA
Describe the bug
If you delete a PR preview site in the portal and then close the PR, the CD pipeline fails when it tries to remove the (now non-existent) preview.
To Reproduce
Steps to reproduce the behavior:
Create a PR in GitHub.
When the preview site has been created, delete it in the portal.
Close the PR in GitHub.
The deployment pipeline fails with an error:
The content server has rejected the request with: BadRequest
Reason: No matching static site environment was found.
Expected behavior
The deployment should ignore the BadRequest response in this situation.
Additional context
The rest of the preview experience works well 👍

This has been fixed!


Vulnerability in Django 1.8.10 of OWASP/django-DefectDojo

Your Django 1.8.10 library, a direct dependency in your OWASP/django-DefectDojo repository, is subject to vulnerability SID-2959: DNS rebinding vulnerability.
A direct dependency is a library that is specified in your project’s setup.py.  A vulnerability in a direct dependency can be fixed by updating the version of the library in your project and rebuilding it.
This issue was fixed in version 1.8.16. However, that version may itself be subject to other vulnerabilities. We suggest that you upgrade to version 1.9.11, which is considered safe.
Be sure to build, test, and re-scan your project to ensure this fix has been successful.
setup.py
...
django == 1.9.11
...

For more information on this vulnerability, please visit the SourceClear Registry.

I took the time to look at all the Source Clear issues entered against Dojo back on April 6th- full details are in this Google Doc.  I figured I should actually add the results to the issues so any of our users can see that we take these things seriously.
Overall for all the issues, I found:

3 False Positives
1 Duplicate
3 Already planned updates of Python modules which we're either not vulnerable or maybe in certain edge cases.

For this specific issue, the TLDR is: A non issue except for users foolish enough to run with DEBUG=True in production and they kinda deserve it.  This will get fixed when we rev Django - see Issue #250 - but won’t up the priority of that activity.


refactor(@angular/build): directly bundle external component file-based style changes

When using the development server with the application builder, file-based component styles will now be bundled during the main builder execution instead of within the application code bundling step. This allows for these styles to be processed independently from any code bundling steps and will support future changes that will allow the builder to completely skip code bundling if only file-based component stylesheets are changed.

The changes were merged into the following branches: main, 19.0.x


Get rid of devise requirement.

The requirement to use devise in this project seems like overkill to me.  The project requires a simple login/logout flow but tests will not pass without using devise.  Devise seems like trying to set a nail with a sledgehammer in this case, too much tool for the job.  I also feel that most students will learn more and gain a better understanding of authentication by not requiring devise be used.
I attempted to roll my own authentication with a session controller, etc... but tests would not pass.  Eventually Learn experts directed me to use devise to implement what I had already implemented without.  I understand that the directions state to use devise to set up the project.  Perhaps if you would like to require the student to use devise, make them include a Github Oauth authorization flow.

Thanks for reporting this issue. We're now aware of it and are tracking it in
issue #28.
We will add this to our internal work queue. We are in the process of updating
the materials in this section and will be rewriting this lesson to address the
current issues. We'll be taking all of this information into consideration in
upcoming releases of this curriculum.
We're closing this issue but invite you to follow the progress.
Thanks for contributing!


Add typescript typing

This PR is adding a docstring + typing for typescript.

FYI, the travis failure isn't related to this PR

Thanks!


fix crash

fixes: https://github.com/hyprwm/Hyprland/issues/7025
tested on older hyprland build and works fine, can't currently build -git

Tested patch locally, fixes my instant hyprland crash with anyrun launcher.

Can confirm this fixes crashing on git


InteractItemEvent is not fired when a target location does not exist.

Version: 1.12.2-7.1.0-BETA-121
The InteractItemEvent is not fired when a target location does not exist, aka the player is not looking at a block (or one is far away). This event is functional on SpongeForge 3465.

Related to: https://github.com/SpongePowered/SpongeCommon/issues/2013


[New Workshop] MultiAssayWorkshop

Short title: Title: Multi-omic Integration and Analysis of cBioPortal and TCGA data with MultiAssayExperiment
Workshop URL: https://github.com/waldronlab/MultiAssayWorkshop
Workshop docker image: docker.io/mr148/multiassayworkshop:latest
Workshop port: 8787
Workshop memory request: 2GB
Workshop description: This is a workshop on acquiring and analyzing data through the
curatedTCGAData and cBioPortalData packages as MultiAssayExperiment objects.
It is built using GitHub actions and pkgdown. Some knowledge of R and basic
Bioconductor structures such as SummarizedExperiment is assumed.

Hi, @LiNk-NY. Thanks for submitting. Your workshop is already loaded from 2020 and updates automatically with changes to the docker image. You're ready to go (just checked that the new version is what launches). If, in the future, you want to version this stuff, you can do that by versioning/tagging the docker image (and workshop materials).

Thanks Sean!


Support DbContext with DbContextOptions options and multi-parameter constructors

It is recommended (and in some cases needed) to use the generic DbContextOptions<TDbContext> and not just DbContextOptions, and is what we use in our project.
I've temporarily worked around the issue by taking in the non-generic version, but it would be nice to get around this issue:
"The DbContext of type 'MyCommonDbContext' cannot be pooled because it does not have a single public constructor accepting a single parameter of type DbContextOptions."

Also, our CommonDbContext constructor requires a ILogger instance as the second parameter, which complicates things with the way OdataToEntity uses pooling.  To workaround this, I subclass CommonDbContext as MyCommonDbContext and create the logger myself, instead of having it dependency injected.
public class FinanceDbDataAdapter : OeEfCoreDataAdapter<MyCommonDbContext>
{
    public FinanceDbDataAdapter(DbContextOptions<MyCommonDbContext> options) : base(options, new OeQueryCache(false))
    {
    }
}

public class MyCommonDbContext : CommonDbContext
{
        public MyCommonDbContext(DbContextOptions<CommonDbContext> options) : base(options, new LoggerFactory().CreateLogger<MyCommonDbContext>())
    {
    }
}

It would be great if I didn't have to do that and instead could just use
public class FinanceDbDataAdapter : OeEfCoreDataAdapter<CommonDbContext>
{
    public FinanceDbDataAdapter(DbContextOptions<CommonDbContext> options) : base(options, new OeQueryCache(false))
    {
    }
}

These might be helpful

https://github.com/aspnet/EntityFrameworkCore/pull/9465
https://github.com/aspnet/EntityFrameworkCore/issues/9433

OeEfCoreDataAdapter already contains this is constructor

@voronov-maxim this so far has been working for me (leaving here in case others run into the issue).
using System;
using Microsoft.EntityFrameworkCore;
using OdataToEntity.Cache;
using OdataToEntity.EfCore;

namespace Finance.Data
{
    public class FinanceDbDataAdapter : OeEfCoreDataAdapter<FinanceDbContext>
    {
        public IServiceProvider ServiceProvider { get; set; }

        public FinanceDbDataAdapter(IServiceProvider serviceProvider) : base(null, new OeQueryCache(false))
        {
            this.ServiceProvider = serviceProvider;
        }

        public override object CreateDataContext()
        {
            return ServiceProvider.GetService(typeof(FinanceDbContext));
        }

        public override void CloseDataContext(Object dataContext)
        {
            // Handled by DI
        }
    }
}


Change bcrypt-ruby dependency to use bcrypt

Change bcrypt-ruby dependency to use bcrypt

gem install gitrob
Fetching: methadone-1.8.0.gem (100%)
Successfully installed methadone-1.8.0
Fetching: paint-0.9.0.gem (100%)
Successfully installed paint-0.9.0
Fetching: thread-0.1.4.gem (100%)
Successfully installed thread-0.1.4
Fetching: addressable-2.3.6.gem (100%)
Successfully installed addressable-2.3.6
Fetching: dm-core-1.2.1.gem (100%)
Successfully installed dm-core-1.2.1
Fetching: dm-aggregates-1.2.0.gem (100%)
Successfully installed dm-aggregates-1.2.0
Fetching: dm-constraints-1.2.0.gem (100%)
Successfully installed dm-constraints-1.2.0
Fetching: dm-migrations-1.2.0.gem (100%)
Successfully installed dm-migrations-1.2.0
Fetching: dm-transactions-1.2.0.gem (100%)
Successfully installed dm-transactions-1.2.0
Fetching: json_pure-1.8.2.gem (100%)
Successfully installed json_pure-1.8.2
Fetching: dm-serializer-1.2.2.gem (100%)
Successfully installed dm-serializer-1.2.2
Fetching: dm-timestamps-1.2.0.gem (100%)
Successfully installed dm-timestamps-1.2.0
Fetching: dm-validations-1.2.0.gem (100%)
Successfully installed dm-validations-1.2.0
Fetching: bcrypt-ruby-3.1.5.gem (100%)
#######################################################
The bcrypt-ruby gem has changed its name to just bcrypt.  Instead of
installing bcrypt-ruby, you should install bcrypt.  Please update your
dependencies accordingly.
#######################################################
Successfully installed bcrypt-ruby-3.1.5
Fetching: stringex-1.5.1.gem (100%)
Successfully installed stringex-1.5.1
Fetching: uuidtools-2.1.5.gem (100%)
Successfully installed uuidtools-2.1.5
Fetching: dm-types-1.2.2.gem (100%)
Successfully installed dm-types-1.2.2
Fetching: datamapper-1.2.0.gem (100%)
Successfully installed datamapper-1.2.0
Fetching: data_objects-0.10.14.gem (100%)
Successfully installed data_objects-0.10.14
Fetching: do_postgres-0.10.14.gem (100%)
Building native extensions.  This could take a while...
Successfully installed do_postgres-0.10.14
Fetching: dm-do-adapter-1.2.0.gem (100%)
Successfully installed dm-do-adapter-1.2.0
Fetching: dm-postgres-adapter-1.2.0.gem (100%)
Successfully installed dm-postgres-adapter-1.2.0
Fetching: gitrob-0.0.5.gem (100%)
Successfully installed gitrob-0.0.5
23 gems installed

I am only a bystander but even for me it is annoying to see people posting issues instead of pull requests. A pull request takes 5 minutes and fixes problems. An issue takes 9 minutes. 4 minutes for you and 5 minutes for the one finally fixing the issue. Especially if the nice author of the application wrote an easy to follow guide of "How to make a pull request":
How to make a pull request:

Fork it ( https://github.com/michenriksen/gitrob/fork )
Create your feature branch (git checkout -b my-new-feature)
Commit your changes (git commit -am 'Add some feature')
Push to the branch (git push origin my-new-feature)
Create a new Pull Request

gem server # inside gitrob project

You will notice that dm-types 1.2.2 requires bcrypt-ruby. Even creating a PR here won't solve that message, please check dm-types gemspec.
I think that we can close this issue.

Hi,
I guess, as I see it fixed on the code, you realized you had to change bcrypt-ruby for bcrypt. Would you mind issuing a new release so when we require this gem we don't get that error message anymore? The latest (dm-types 1.2.2) is still requiring bcrypt-ruby.
Thanks!


Rename the Cmd name of QOS command 'Ready' to ready

What is the purpose of the change
fix #6113
Brief changelog
XXXXX
Verifying this change
XXXXX
Follow this checklist to help us incorporate your contribution quickly and easily:

[x] Make sure there is a GITHUB_issue field for the change (usually before you start working on it). Trivial changes like typos do not require a GITHUB issue. Your pull request should address just this issue, without pulling in other changes - one PR resolves one issue.
[ ] Format the pull request title like [Dubbo-XXX] Fix UnknownException when host config not exist #XXX. Each commit in the pull request should have a meaningful subject line and body.
[ ] Write a pull request description that is detailed enough to understand what the pull request does, how, and why.
[ ] Write necessary unit-test to verify your logic correction, more mock a little better when cross module dependency exist. If the new feature or significant change is committed, please remember to add sample in dubbo samples project.
[ ] Run mvn clean install -DskipTests=false & mvn clean test-compile failsafe:integration-test to make sure unit-test and integration-test pass.
[ ] If this contribution is large, please follow the Software Donation Guide.

@htynkn PTAL


removed useless comment

Good morning kind sir,
I've removed the unneedful stuff from your code
Cheers

Looks good to me


Roll engine 77c5812d48b8..1cd130444333 (5 commits)

https://github.com/flutter/engine/compare/77c5812d48b8...1cd130444333
git log 77c5812d48b8..1cd130444333 --first-parent --oneline
2020-02-18<EMAIL_ADDRESS>Control test timeouts based on debugger status or command line flags. (flutter/engine#16375)
2020-02-18<EMAIL_ADDRESS>Roll src/third_party/dart 999eeea5a3ff..3883c6070942 (5 commits) (flutter/engine#16666)
2020-02-18<EMAIL_ADDRESS>Roll src/third_party/skia c1bb9cba16be..7281a8623799 (9 commits) (flutter/engine#16665)
2020-02-18<EMAIL_ADDRESS>Lift restriction that embedders may not trample the render thread OpenGL context in composition callbacks. (flutter/engine#16653)
2020-02-18<EMAIL_ADDRESS>update hash code logic on the web (flutter/engine#16624)
If this roll has caused a breakage, revert this CL and stop the roller
using the controls here:
https://autoroll.skia.org/r/flutter-engine-flutter-autoroll
Please CC<EMAIL_ADDRESS>on the revert to ensure that a human
is aware of the problem.
To report a problem with the AutoRoller itself, please file a bug:
https://bugs.chromium.org/p/skia/issues/entry?template=Autoroller+Bug
Documentation for the AutoRoller is here:
https://skia.googlesource.com/buildbot/+/master/autoroll/README.md

Commit queue failed; closing this roll.


Large inaccuracies near (but not on) triangle

Thank you so much for providing this library. So far I've had success with the particle dipoles, and I'm triangle to get dipoles on triangles working.
I'm running into an issue that I get large inaccuracies even for a just one double-sided triangle.
I'm calling the compiled fortran code from Matlab. In the following example I place a single unit-dipole-strength triangle along the yz-plane, then I compute the potential at grid locations on the xy-plane.
% Source triangle
VF = [0 0 0;-1 1 0;-0.2 -0.2 0.2];
N = [1 0 0];
C = mean(VF');
% Target grid
[X,Y] = meshgrid(linspace(-1,1),linspace(-1,1));
Z = zeros(size(X));
% Target positions
Q = [X(:) Y(:) Z(:)];

iprec = 3;
UFMM = lfmm3dtria(iprec,1,VF,N',C',0,0,1,1,N',0,0,size(Q,1),Q',1,0);
UDIR = l3dtriadirect   (1,VF,N',C',0,0,1,1,N',0,0,size(Q,1),Q',1,0);

UDIFF = real(UFMM.pottarg - UDIR.pottarg);
UREL = abs(UDIFF)./abs(UDIR.pottarg);
err_abs = max(abs(UDIFF))
err_rel = max(abs(UREL))

Running this, I see that the absolute and relative errors are quite large:
err_abs =
       1062.8
err_rel =
       312.11

If I visualize the direct solution (ground truth), I see what I expect:

If I visualize the fmm solution I see wild errors near the source triangle (cyan and yellow colors indicate out-of-range). Increasing the iprec option changes the error locations, but does not alleviate the problem (animation):

I can also visualize the order of the error (log base 10 of absolute value) increasing iprec values, for the absolute error:

and the relative error:

The bottom left corner seems to really work correctly, but I'm not sure what's going on elsewhere.
Any chance I'm calling this function wrong? Or that there's a fix?

Mac OS X 10.12, MATLAB r2018a, gfortran (gcc version 7.2.0)

Update: I've confirmed that I get the same problem on Linux.

Ubuntu 16.04.3, GNU Fortran (Ubuntu 5.4.0-6ubuntu1~16.04.5) 5.4.0 20160609, MATLAB r2017a

Hi, you are calling the function correctly, this is a known issue with
layer evaluation tools. For single or double layer density evaluation, the
FMM library has been designed to evaluate layer potentials on the surface
of somewhat uniformly discretized geometry and targets that are in the far
field (meaning at least one radius away for each triangle in
triangulation). This test hit the worst case scenario: the triangle is
locally big with respect of very fine target grid located very close to the
boundary. I checked the fmm oct-tree for this geometry, the source triangle
is located at the very edge of a large box inside oct-tree, leading to
large errors in formed multipole expansions.  This issue is not activated
in particle-target FMMs, since all points are automatically assigned to
correct computational boxes inside the oct-tree.
A possible fix would involve modifying the underlying FMM oct-tree, so that
it would be aware of source triangle radii, forcing direct evaluation for
nearby target points, and using some QBX FMM ideas to get robust high order
layer tools working.
A better fix that you can currently do (this has been tried by others,
because of lack of better tools and interface) is to write your own
high-order target evaluation routine as follows: first, replace the source
triangle densities with point discretizations by using a well-conditioned
interpolation/quadrature scheme (by either using the tensor-product Gauss
rule in src/triagauc.f or optimized nodes in src/triasymq.f), sort all
targets into the far-field and near-field targets, then, call the point FMM
for point-wise discretized geometry and far-field targets, and, finally,
evaluate the remaining interactions with near-field targets directly.
A quick workaround would be to refine the source geometry, making the
source triangles smaller and effectively pushing all targets further into
the far field with respect to the source geometry:
% Debugging output to screen and fort.13
fmm3dprini(6,13)
verts = [0 0 0;-1 1 0;-0.2 -0.2 0.2];
ifaces = [1 2 3]';
[verts,ifaces]=atrirefine(verts,ifaces);
[verts,ifaces]=atrirefine(verts,ifaces);
[verts,ifaces]=atrirefine(verts,ifaces);
[verts,ifaces]=atrirefine(verts,ifaces);
[triaflat,trianorm,triaarea,centroid,triatang1,triatang2] = ...
atriproc(verts,ifaces);
% Source triangle
VF = triaflat;
N = trianorm;
C = centroid;
% Target grid
[X,Y] = meshgrid(linspace(-1,1),linspace(-1,1));
Z = zeros(size(X));
% Target positions
Q = [X(:) Y(:) Z(:)];
nsource = size(C,2);
charge = zeros(nsource);
dipstr = ones(nsource);
iprec = 3;
UFMM = lfmm3dtria(iprec,nsource,VF,N,C,0,0,1,dipstr,N,0,0,size(Q,1),Q',1,0);
UDIR = l3dtriadirect   (nsource,VF,N,C,0,0,1,dipstr,N,0,0,size(Q,1),Q',1,0);
UDIFF = real(UFMM.pottarg - UDIR.pottarg);
UREL = abs(UDIFF)./abs(UDIR.pottarg);
err_abs = max(abs(UDIFF))
err_rel = max(abs(UREL))
err = reshape(UDIR.pottarg - UFMM.pottarg, 100, 100);
err = reshape(UFMM.pottarg, 100, 100);
imagesc(log10(abs(err)))
colorbar
On Wed, Dec 27, 2017 at 1:56 PM, Alec Jacobson<EMAIL_ADDRESS>wrote:

Update: I've confirmed that I get the same problem on Linux.
Ubuntu 16.04.3, GNU Fortran (Ubuntu 5.4.0-6ubuntu1~16.04.5) 5.4.0
20160609, MATLAB r2017a
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/zgimbutas/fmmlib3d/issues/1#issuecomment-354176576,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AGydmizwnXFyNc9pXrq5q-hwf-hCrz_iks5tEq8TgaJpZM4RNvES
.

Thanks. This response is super helpful. I'll try both immediate suggestions.
Is there a programmatic way to determine which targets are in the near / far field for a given: set of triangles, iprec value and set of targets?
I imagine I should compute closest distance from all targets over all triangles, but what is a safe radius? Will it depend on the aspect ratio of the triangles? Will it depend on the extend and spacing of the other target points?

If you have a closed geometry, there is a nice trick involving double layer
potential with constant density to determine points close to the boundary:
the potential due a constant double layer density is 1 inside and 0 outside
the domain, and something else near the boundary. More accurate/correct way
involves hacking into the FMM tree structure and reading out the list of
targets inside so called List 1 of interaction boxes.
As for the second question. right now, some experimenting is needed to
determine the right parameters. I usually set the far field cutoff radius
to be about 2-3 source triangle radii, depending on precision.  I haven't
experimented with the aspect ratio and point distributions, but they do
matter in setting up the computational box structures, so the answer here
is likely to be yes.
On Thu, Dec 28, 2017 at 3:04 PM, Alec Jacobson<EMAIL_ADDRESS>wrote:

Thanks. This response is super helpful. I'll try both immediate
suggestions.
Is there a programmatic way to determine which targets are in the near /
far field for a given: set of triangles, iprec value and set of targets?
I imagine I should compute closest distance from all targets over all
triangles, but what is a safe radius? Will it depend on the aspect ratio of
the triangles? Will it depend on the extend and spacing of the other target
points?
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/zgimbutas/fmmlib3d/issues/1#issuecomment-354365102,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AGydmhhzJB5FjvehiNA6hye8y6uDJFLKks5tFBBsgaJpZM4RNvES
.


Dragging and dropping pictures does not work in last version of plugin.

Hello.
Dragging and dropping pictures does not work for me in chrome with last version of plugin.
Important: It is not usual dragging and dropping, it does not work only when you tries to move picture from one tab to another - you select picture, move to tab with input-uploader and drop picture on input - result - you get this error message:
TypeError: Cannot read property 'type' of undefined
at ng-file-upload.js:1321
at Object.forEach (angular.js:325)
at validateAsync (ng-file-upload.js:1318)
at upload.validate (ng-file-upload.js:1355)
at upload.updateModel (ng-file-upload.js:593)
at updateModel (ng-file-upload.js:1840)
at ng-file-upload.js:1797
at wrappedCallback (angular.js:11572)
at angular.js:11658
at Scope.$eval (angular.js:12701)
It works correct with version 10.0.0.
If you need an example, you can use your own - https://angular-file-upload.appspot.com/. And video for you - http://screencast.com/t/nodjQsLg

I believe this bug has been introduced recently, you can try to use older versions until it is fixed in the next version.

Thanks!
When do you think next release will be available?

ETA Less than a week

Fixed at 12.0.1

Thanks!

@ruslan5t Did this fix work for you? I'm seeing the same error with 12.0.1 when I drag an image from one tab to another.

@OverZealous You are right, I was too naive.
@danialfarid Can you please check your fix?


sudo python3 setup.py install doesn't compile

There are multiple issues with bme68xmodule.c
pi@raspberrypi:~/bme688/bme68x-python-library $ sudo python3 setup.py install
running install
running bdist_egg
running egg_info
writing bme68x.egg-info/PKG-INFO
writing dependency_links to bme68x.egg-info/dependency_links.txt
writing top-level names to bme68x.egg-info/top_level.txt
reading manifest file 'bme68x.egg-info/SOURCES.txt'
writing manifest file 'bme68x.egg-info/SOURCES.txt'
installing library code to build/bdist.linux-armv6l/egg
running install_lib
running build_py
running build_ext
building 'bme68x' extension
arm-linux-gnueabihf-gcc -pthread -DNDEBUG -g -fwrapv -O2 -Wall -g -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -fPIC -I/usr/local/include -I/usr/include/python3.7m -c bme68xmodule.c -o build/temp.linux-armv6l-3.7/bme68xmodule.o -D BSEC
In file included from BSEC_<IP_ADDRESS>_Generic_Release_04302021/algo/normal_version/bin/RaspberryPi/PiThree_ArmV6/bsec_interface.h:73,
from internal_functions.h:22,
from bme68xmodule.c:4:
bme68xmodule.c: In function ‘bme_set_heatr_conf’:
BSEC_<IP_ADDRESS>_Generic_Release_04302021/algo/normal_version/bin/RaspberryPi/PiThree_ArmV6/bsec_datatypes.h:88:38: error: expected identifier before ‘(’ token
#define BSEC_SAMPLE_RATE_DISABLED    (65535.0f)      /*!< Sample rate of a disabled sensor */
^
bme68xmodule.c:357:42: note: in expansion of macro ‘BSEC_SAMPLE_RATE_DISABLED’
requested_virtual_sensors[0].BSEC_SAMPLE_RATE_DISABLED;
^~~~~~~~~~~~~~~~~~~~~~~~~
bme68xmodule.c: In function ‘bme_get_bsec_data’:
bme68xmodule.c:516:9: error: ‘bsec_rlst’ undeclared (first use in this function); did you mean ‘bsec_rslt’?
bsec_rlst = bsec_read_data(self->data, &data_length, time_stamp, bsec_inputs, &num_bsec_inputs, sensor_settings.process_data, sensor_settings.op_mode, &(self->bme));
^~~~~~~~~
bsec_rslt
bme68xmodule.c:516:9: note: each undeclared identifier is reported only once for each function it appears in
bme68xmodule.c: In function ‘bme68x_init_type’:
bme68xmodule.c:231:13: warning: ignoring return value of ‘fread’, declared with attribute warn_unused_result [-Wunused-result]
fread(&serialized_settings[0], sizeof(unsigned char), BSEC_MAX_PROPERTY_BLOB_SIZE, bsec_conf);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
error: command 'arm-linux-gnueabihf-gcc' failed with exit status 1

Problem is in this line in bme68xmodule.c. Is this compiling on your box?
requested_virtual_sensors[0].BSEC_SAMPLE_RATE_DISABLED;

I had same problem, there are also other two typos in the same file that prevented the building to finish successfully


Update podspec file and make it rely on package.json.

Hi,
first of all I'd like to thank you for all the work you put into this project. react-native-spring-scrollview and react-native-large-list are both of great value to a feature we implemented in one of our apps.
We've been using it with CocoaPods because it simplifies our building and deploying processes. The current version of podspec file has a misconfiguration that prevents it from being compiled. It relies on the path based on the root of the repo instead of the root of the npm package; src/ios/SpringScrollView/**/*.{h,m} and not SpringScrollView/**/*.{h,m}.
In this PR, the source files configuration was fixed and also some more work to make other configurations to be read from package.json, so no additional work is required when a new version is to be released.
Please, let me know your thoughts and how can I help to get this merge in.
Thank you!

Thank you for your PR.
Have you tried your podspec file? The source files are in src/ios/SpringScrollView/**/*.{h,m}, not SpringScrollView/**/*.{h,m}

If you are sure it is right, I will megre at once I do not have time to test it right now.

Hello,
thank you for your swift response. I believe PodSpec source_files attribute is relative to the location of the podspec file itself. Keeping it src/ios/SpringScrollView/**/*.{h,m} doesn't return any compile errors, but I get this runtime error:
Invariant Violation: requireNativeComponent: "SpringScrollContentView" was not found in the UIManager.

This error is located at:
    in SpringScrollContentView (at SpringScrollView.js:115)
    in SpringScrollView (at createAnimatedComponent.js:151)
    in AnimatedComponent (at SpringScrollView.js:101)
    in RCTScrollContentView (at ScrollView.js:959)
    in RCTScrollView (at ScrollView.js:1098)
    in ScrollView (at SpringScrollView.js:130)
    in SpringScrollView (at LargeList.js:207)

By having the source_files set to SpringScrollView/**/*.{h,m}, no errors are thrown.

same result for me, I can only seem to get this to work with cocoapods if I change the source_files to what's in this PR.

OK，I got it!


Update to latest Plex API, add music support.

Description:
This updates the Plex media player component to use the latest PlexAPI dependency. This fixes the inability to control Plex media players, from the web frontend or the home-assistant backend.
I've also added in support for music media, media stop commands, and volume set commands.
The new PlexAPI has an annoying _NA type internally which only compares to None directly, but will decompose to a __NA__ string if not caught. This broke a ton of HA's media player internals, so I had to add a helper method to convert it to a real None where required. In some places PlexAPI uses the _NA objects without checking itself, leading to certain API calls returning invalid URLs rather than None (or another _NA object).
Related issue (if applicable):
Fixes #2125.
Pull request in home-assistant.io with documentation (if applicable): home-assistant/home-assistant.io#
Not required.
Example entry for configuration.yaml (if applicable):
No changes.
Checklist:
No documentation/user facing changes. There is one new PyLint error in this update as the PlexPy _NA object is only True when directly compared to None, i.e.:
_NA() is None is False
_NA() == None is True

Ok, I've no idea how to get the flake8 to pass on my deliberately wonky code (which unwraps the _NA() object from the PlexAPI library). Anyone have any ideas?

Avoiding that is literally the point of that helper function - the PlexAPI library returns a custom type that compares equal to None, but is None evaluates to False.

Okiedokie, converted it over to using the NA object for comparisons. I really wish I hadn't open up this can of worms now - I didn't realise the new version had that new "optional"ish return everywhere that would cause so much flakiness. Looks like the library author didn't fully think it through either, given than several APIs return stringified NA objects in there with no checks.
This seems to work for me, I can see and control several simultaneous Plex instances. Tested:

Firefox web client (Music with no album art, music with album art, video)
Chrome web client (Music with no album art, music with album art, video)
Rasplex client (Video)

NOT tested: Premium PlexPass login, since I don't have an account. I need someone else to test this out and confirm it's working/broken.
More Plex testers should also try this out with other combinations, just to shake out any additional issues I've missed due to the wonky return schema and API changes.

Further testing is what the dev channel is for so I will go ahead and merge this 👍 🐬
The issues where the album url actually contains __NA__ should probably be reported upstream, as that sounds like a bug.


Requirements are incorrect: "make[1]: rice: Command not found"

platform:
centos7 & rhel7 minimal build and web-server build with working docker/docker-compose
[user@docker opt]$ sudo git clone https://github.com/ninech/reception.git
Cloning into 'reception'...
remote: Enumerating objects: 163, done.
remote: Total 163 (delta 0), reused 0 (delta 0), pack-reused 163
Receiving objects: 100% (163/163), 91.88 KiB | 0 bytes/s, done.
Resolving deltas: 100% (71/71), done.
[user@docker opt]$ cd reception/
[user@docker reception]$ ls
common  contrib  dns  docker  go.mod  go.sum  http  LICENSE  Makefile  README.md  reception.go  resources  VERSION
[user@docker reception]$ sudo make
make[1]: rice: Command not found
make[1]: *** [clean] Error 127
make: *** [http] Error 2

Thank you for reporting this. I recognize that there were some problems with the dependencies, i.e. they were very outdated.
But I believe the problem here is that $GOPATH/bin is not part of your $PATH. See https://github.com/golang/go/wiki/GOPATH#integrating-gopath

But I believe the problem here is that $GOPATH/bin is not part of your $PATH.

This is indeed the problem...but for a different reason. I don't have GO installed on the server I run the containers on... Thank you for your response.


Add clear_method_caches to Utils.py

This PR adds functionality used in #4241

@scoder could you please review this PR?


Visual bug when hovering with a new drag and drop event

Some times when you try to drop an event it seems like you are going to be dropping it under another one. I made a video so it is easier to see since I can't screenshot the exact moment.
https://user-images.githubusercontent.com/2206700/196709047-8703322b-0986-4c0b-9e2d-c088b93622ad.mp4
As you can see, the events seem to be inside the one just above the one you are going to be creating. Not sure what it is causing it.

Since the new line indicator, this doesn't happen any more. Closing.


bump to v4.0

looks like failure on macOS is known; https://trac.macports.org/ticket/55746

@jakirkham after switching to the conda-build 3 compiler syntax the linux build broke with this error:
ERROR: gnutls not found using pkg-config

I'm googling aroung to understand what is going on, but maybe you have already an idea?

Could try setting the environment variable PKG_CONFIG_PATH to PREFIX/lib/pkgconfig in build.sh.

no luck with env var, tried another fix including other libs. Now it says:
gcc is unable to create an executable file.
If gcc is a cross-compiler, use the --enable-cross-compile option.
Only do this if you know what cross compiling means.
C compiler test failed.

@jakirkham sorry do you have any other suggestion? Seems like the CI now can't find the compilers... Also, osx build broke with my latest fix attempt, which is 😲 for me since the change should have nothing to do with finding/not finding a working compiler...

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

Selectors are suggested to take a <two spaces>#<one space>[<expression>] form. See lines [32]

Hi! This is the friendly automated conda-forge-linting service.
I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.

Sorry for the slow reply, @carlodri. Have been completely swamped.
Copying your comment over here, @carlodri.

should we also add the --static flag to compile also the statically linked library? I think that this could be the reason for which ffmpeg builds (https://github.com/conda-forge/ffmpeg-feedstock/pull/47) fail to find zlib.

Don't think this is the problem.
Think PR ( https://github.com/conda-forge/conda-forge-pinning-feedstock/pull/52 ) will solve your issue. We need to hammer that out.
cc @msarahan @mingwandroid (for awareness)

thanks @jakirkham, no worries!
to me it looks more like a library or include path issue, rather than a version pinning issue...

@jakirkham it's fixed!! 🎉 🍾 🎉
the trick was to explicitly --enable-zlib

Thanks a lot for the sweating Carlo.
I'm not very familiar yet with all the new conda-smithy + conda-build 3 mechanisms, but I think this should be ready to go after 1) rebasing to a single commit 2) confirming that using the new compilers is not problematic for downstream dependencies (I guess it won't be since new version of these should start using the new compilers too, is that where CF is moving @jakirkham?).

Thanks a lot for the sweating Carlo.

Indeed. Impressive work, @carlodri!

I'm not very familiar yet with all the new conda-smithy + conda-build 3 mechanisms, but I think this should be ready to go after 1) rebasing to a single commit 2) confirming that using the new compilers is not problematic for downstream dependencies (I guess it won't be since new version of these should start using the new compilers too, is that where CF is moving @jakirkham?).

We are working on docs. ( https://github.com/conda-forge/conda-forge.github.io/pull/576 )
Basically conda-smithy 3 + conda-build 3 handles pinning automatically based on this. Re-rendering refreshes the pins (so may need a build number bump if they change). Package specific pinnings live in .ci_support in the feedstock.
We are not using the new compilers yet. Instead we are in an intermediate phase where the {{ compiler("c") }} is a stand-in for the toolchain. ( https://github.com/conda-forge/toolchain-feedstock/pull/34 ) Ultimately we want to phase that out and use the new compilers, but that will require a lot of rebuilding due to ABI incompatibilities between the current compilers and new ones. More details to follow in a post.

Thanks for the roadmap hints @jakirkham; it sounds like a well thought plan - specially the part where we can migrate all recipes to use the compiler directive without actually using yet the newer compilers.

...specially the part where we can migrate all recipes to use the compiler directive without actually using yet the newer compilers.

Can thank @msarahan and @isuruf for that idea and work. 😄

a (for me) very instructive comment on the matter of pinnings&co: https://github.com/conda-forge/source-highlight-feedstock/pull/1#discussion_r185330958
you're welcome folks, it had become some kind of personal challenge... 😅

will polish this in the evening

Yeah, boost-cpp is an exception rather than the rule. numpy is similar in this respect. The rest we can blindly trust to conda-forge-pinning. Hopefully this significantly reduces maintenance burden. :)

Thanks @carlodri. Added some simple suggestions. Mainly tidying up the changes a bit. Hopefully straightforward. Please let me know if you have questions.

After the changes suggested by @jakirkham are implemented and maybe squashing again, this LGTM.

I would massage (or simply trim) the commit message. Right now there is a lot of noise in there.
@carlodri Now that we are at it,  should we try to add support for openh264 as per #44? It should entail:

adding openh264  # [not win] to deps
adding --enable-libopenh264 to build.sh

I will open a PR if you feel like you had enough already ;-)

thanks for your help @jakirkham @sdvillal

@carlodri can you detail why you swapped yasm for nasm in this PR please?

To clarify, that discussion happened out-of-band.
ref: https://gitter.im/conda-forge/conda-forge.github.io?at=5af9dbe85a1d895fae3c7779

Happened here too: https://github.com/conda-forge/ffmpeg-feedstock/pull/47#pullrequestreview-117266644 :)


Adding Support For Docker / Docker Compose

I'm not sure if this is something you would like to bring into the core, I've been working on the side to make pushd run in a docker container this pr adds support for such a thing. Feel free to comment or close, but since I had done the work I figured I'd throw it out for feedback.

Why:

Enables developers to clone the repo and run docker-compose up -d
able to start using the project
New sample env format for environment variables
New mechanisms for running tests by using docker-compose run api npm test

Thanks!

I find having a Dockerfile ready to go useful, but I'm not sure why @christopherhein decided to use CentOS, and an old version of that, as a base. I would think using official Node image would make more sense? I did that on my version.

Nice work @zokier do you want me to close mine and you can submit yours? Looks like you're using the same settings.coffee as well so we're 1005 compliant with each other…

Maybe @rs could chime in on what he would prefer?

standard node image sounds better.

Ok. I want to make couple of tweaks, but then I make new pull request

Just cleaning up PRs sounds like I can close this?

Sure


Pause all labels of queue time if you are not in matchmaker tab

Prevents useless GPU usage if you are not in the "Matchmaker" tab

@Marc-Spector were you planning on continuing this?

The #2619 PR fixed the high GPU usage issue. So this PR is no longer relevant.


[#158] Put the figma in the 3 main page screen wirefeme  for v2.0

HOME PAGE
TRAINING PAGE
MINE PAGE

Leave your comment here


refactor: added vue 2 backwards compatibility for @vue-flow/background

refactor: migrated vue 2 backwards compatibility for @vue-flow/background

Description
This MR refactors the @vue-flow/background package to be entirely SFC independent, allowing for backwards compatibility with Vue 2.7.* as well as continuing support for Vue 3.
Essentially, these changes should be able to be merged into master / main without any trouble at all for the existing package.
Testing 🔧
Vue 2 App Example (with just the background component rendered*):

Vue 3 Vite App Example:

I'd tag this change as a feature instead of a refactor request as that's more in line with what's actually happening.

I'd tag this change as a feature instead of a refactor request as that's more in line with what's actually happening.

Cool. I think the changesets will need the appropriate minor bump too. Do you want me to take care of this?

Changed the base branch to feat/vue2 so changes can be collected in there before release.

I'm wondering how we could run the test suites for the Vue 2 components as well 🤔

I'm wondering how we could run the test suites for the Vue 2 components as well 🤔

What is your current test setup? Cypress?

I'd tag this change as a feature instead of a refactor request as that's more in line with what's actually happening.

Cool. I think the changesets will need the appropriate minor bump too. Do you want me to take care of this?

Take care of the changesets.

Yeah, tests are done with cypress component testing

Could you possibly add a Vue 2 example App to the examples folder, so that this can be tried out?

Could you possibly add a Vue 2 example App to the examples folder, so that this can be tried out?

So I have added one locally, and it works well (not much use to you, granted) ... but we would need to migrate @vue-flow/core before we have full compatibility ...

Why would you need to strip that? The app can use a different vue version without the whole repo using the same ^^

You'd probably just need to remove the peerDepedency

So after a bit of playing around, it turns out you can do defineComponent<Props>, which will roll up the proper types for the component and is usable in Vue 2.
const Background = /* #__PURE__ */ defineComponent<BackgroundProps>({
	// rest here...
})

That is a massive W tbh and should make this a lot easier.
Though defining default args for props is still a hassle 😄

defineComponent<BackgroundProps>

Yeh this is a really strange one ... I'm wondering if this is a bug with Volar ... 🤔

No idea :/

Btw, appending + force pushing every commit you make messes up the comments on existing pieces of code ^^
You can just Squash the commits at the end instead of just forcing each time to preserve 1 commit

@bcakmakoglu Yeh fair, sorry. Will squash at the end.
So some of my testing has found some quirky things to make this Vue 2 & Vue 3 compatible:

toRef doesn't work as expected with Vue 3, we have to use computed for Vue 2 to work reactively (I want to see if props are "reactive" inside render functions for both, will investigate this).
props need to be explicitly stated otherwise, Vue 2 does not pass them though correctly.
there is still a typing issue in the imported package, I am going to attempt to understand this today and reach out to the Volar team.

toRef doesn't work as expected with Vue 3, we have to use computed for Vue 2 to work reactively (I want to see if props are "reactive" inside render functions for both, will investigate this).

Bummer but should be fine for now

props need to be explicitly stated otherwise, Vue 2 does not pass them though correctly.

Yeah, seems so - though for maintenance it might be better to define the props object in another file? iirc you can import object prop definitions

there is still a typing issue in the imported package, I am going to attempt to understand this today and reach out to the Volar team.

"a typing" issue or is it that the types aren't properly hinted in general?

Bummer but should be fine for now

I'll continue to dig into why this is, and understand the cause in the API disparity.

Yeah, seems so - though for maintenance it might be better to define the props object in another file? iirc you can import object prop definitions

Yeh I think we can do something like:
export default {
  props: {
    title: String,
    likes: Number
  }
}

"a typing" issue or is it that the types aren't properly hinted in general?

Yeh the hints is non-existing, and in the template usage where most of the mistakes will inevitably happen. I've reached out to the core team for some advice. I'm just not 100% sure ...

I'll continue to dig into why this is, and understand the cause in the API disparity.

Well, toRef from @vueuse/core would probably work - I think the whole concept of MaybeRefOrGetter doesn't exist, even in Vue 2.7, making toRef(() => {} unusable anyway if I'm not mistaken.
toValue doesn't exist in Vue 2 either (which accepts a MaybeRefOrGetter type), which is another bummer.
This one was added pretty recently to the Vue 3 core API so no surprise here. Though this one is imported from @vueuse/core as I was using it even before it was part of the core API and atm there's an amigious export issue in the examples when I switch the import to vue (still investigating the reason for this problem)

Yeh the hints is non-existing, and in the template usage where most of the mistakes will inevitably happen. I've reached out to the core team for some advice. I'm just not 100% sure ...

Alright, let's wait and see :)

@braks Closing this one as I will refactor on top of the core migrated PR.