bash: parse_git_branch: command not found

Hello all
I found a code snippet that adds your current git branch to your command line, this works fine in iTerm2 but I'm having some issues getting it to work properly in the ide-terminal.
this is all thats in my bash_profile
# Git branch in prompt.

parse_git_branch() {
  git branch 2> /dev/null | sed -e '/^[^*]/d' -e 's/* \(.*\)/ (\1)/'
}

export PS1="\u@\h \W\[\033[32m\]\$(parse_git_branch)\[\033[00m\] $ "

Is there anything else I need to setup in the package settings?

switched from using bash to using zsh and basically all my problems have been solved. installed oh_my_zsh, the .zshrc config that comes with that package by default sorted it!


Clarify lack of upgrade order for components

Fixes #12323
Adds a sentence to say that there's no specific upgrade order required for kube-controller-manager, kube-scheduler, and cloud-controller-manager as long as kube-apiserver is upgraded first.
/sig docs
/language en
/cc @liggitt @lavalamp

/lgtm

/lgtm
/approve
Can you edit (in a followup?) perhaps line 116 to make it explicit that this means webhooks must be upgraded first?
Webhooks need to be ahead of apiserver and tolerate requests from apiserver version N and N-1.

/approve


1.16.5, village center piece does not generate but its child pieces do

Very weird... almost like a bug in vanilla I am facing but same exact optimization works fine in 1.18.2+?
What did vanilla do back then....

Specific to structureLayoutOptimizer$shrinkStructureTemplateBlocksList mixin


The video no longer available.

On the https://google.github.io/lovefield/  page is a
"LOVEFIELD at JS.LA
Overview by Demetrios Papadopoulos
WATCH NOW"
But I get => This video is no longer available because the YouTube account associated with this video has been closed.
:(

Thanks for the report. The URL seems to have changed. I'll update the README page. In the meantime you can find the video at https://www.youtube.com/watch?v=pwCzMFoheGw.


antipattern analysis output not loaded to BQ output table

While executing the antipattern analysis, I am seeing the following behaviour:

when using input as information schema and output as a bq table, the output is not loaded to the table. I do see in the console log that it recognizes a few queries with anti-patterns, however, nothing is logged in the output table.

When I try using --output_file_path instead of --output_table, the analysis itself changes and no output file is created.

In the above two cases, only the output mode was changed. None of the options produced the output.
Also, option 1 recognized 2 queries with anti-patterns whereas option 2 did not.
Trying to understand what could be the issue here.
Any help is much appreciated.

Fixed with https://github.com/GoogleCloudPlatform/bigquery-antipattern-recognition/pull/7


Connect events service with Redux

Implement a mechanism that allows receiving Janus events in the Redux side.

https://github.com/jangouts/jangouts/pull/245


_SaltedKey solution to ExpansionPanelList

_SaltedKey implementation courtesy of @Hixie
Tested and confirmed working. Screenshot
Fixes #11166

That test will be fine, just some minor tweaks needed before we land it. Thanks!

@Skylled Thanks for your contribution, I'm going to land this as-is and if there's any more style nits we'll fix them in post.


Campaign/applytheme center channel color

Summary
Migrate changeCSS() to CSS variable in utils/utils.jsx, ln. 710
Ticket Link
Fixes #16180
GitHub - https://github.com/mattermost/mattermost-server/issues/16180
Jira - https://mattermost.atlassian.net/browse/MM-30176

Hello @HeroicHitesh,
Thanks for your pull request! A Core Committer will review your pull request soon. For code contributions, you can learn more about the review process here.

This PR has been automatically labelled "stale" because it hasn't had recent activity.
A core team member will check in on the status of the PR to help with questions.
Thank you for your contribution!
/cc @jasonblais @jfrerich @emilyacook

@deanwhillier Could you take a look at this when you get a chance?

This PR has been automatically labelled "stale" because it hasn't had recent activity.
A core team member will check in on the status of the PR to help with questions.
Thank you for your contribution!
/cc @jasonblais @jfrerich @emilyacook

@deanwhillier Can you do your followup review when you get a chance? If you're busy, we can always re-assign


SAML: New auth flow

SAML support will require us to implement an auth flow similar to, but distinct from, the auth flow we have for oauth
Some differences

Customers likely will not want to interact with an external proxy, which the OAuth flow currently uses. While we will probably implement an internal/external proxy to unify auth flows in the long run, it's more important that this auth flow be contained in the k8s cluster (and auth provider) than that it use a proxy. The first implementation of this will probably not use a proxy, and send all auth tokens to pachd directly

Because auth tokens will not go through an external proxy, users will not copy/paste auth tokens. Overall this is a better user experience, but it makes logging in via pachctl more complicated. Pachctl will have to establish a session with pachd after the auth flow is started, and pachd will have to tie the auth token it receives to the session that pachctl has initiated.

Here's a rough drawing of the new auth flow (illustrating the flow where a user logs in via pachctl, but other flows are similar and hopefully apparent from this):

Made some decisions about how this will work (which are particularly relevant to how this would work in a browser):

SAMLRequest is sent to ID provider as a parameter in a GET request. This is safe because the request is signed by pachd (which also means both pachctl and the browser must get it from pachd)
The connection between pachctl and pachd (1. in the diagram above) is a streaming connection, but pachd sends all of its responses at the beginning

The flow (again) with certain new details highlighted:

pachctl (or the dash) opens the streaming connection
pachd sends a response message containing 1) a pachyderm token that doesn't authenticate anyone yet, and 2) a signed SAML request, but does not close the connection
user pastes link in their browser (pachctl) or browser opens a new window (dash) with the destination http://okta?SAMLRequest=<base64-encoded signed SAML request
user is redirected to pachd's ACS endpoint and the ID in the SAMLResponse is connected to the pachyderm token indicated in the SAMLResponse's RelayState
pachd closes the streaming connection in 1. (with an error if auth was unsuccessful for some reason—e.g. couldn't contact Okta's metadata service)

One note: this won't work with IdP-initiated authentication. For that, we need either:

Pachd's ACS endpoint is in the dash's domain, and returns the pachyderm token when queried
Pachd's ACS endpoint returns a redirect to another endpoint that is in the dash domain, with either the pachyderm token, or a temporary code that can be exchanged for the pachyderm token by the browser (I think that in either case, the redirect would need to trigger a POST request from the browser, so that the authorization code isn't transmitted in plain text? In OAuth, browsers seem to send their authorization code in plain text to the client/service provider, though—I'm not sure why that's okay yet)

Update: I'm closing this issue because @gabrielgrant and I decided to take another approach (making this design obsolete). We're planning to implement IdP-initiated login only. I will update the top comment on this issue with a new, superceding issue once I've created it.


tests(fixtures) add /xml and /cache to mock upstream

Summary

/xml: returns a simple XML document
/cache/:n: sets a cache-control header for n seconds

Merged with minor edits; thanks!


How to implement Canary deployment?

Do you want to request a feature or report a bug?

Feature
What did you expect to see?

kubernetes version: 1.17
traefik: 2.2.8
I'd like to implement Canary deployment , I follow the following configuration ，but  I cannot get what I want
apiVersion: traefik.containo.us/v1alpha1
kind: IngressRoute
metadata:
    name: canary
spec:
  entryPoints:
    - web
  routes:
    - match: Host(`traefik.rod.cn`)
      kind: Rule
      services:
        - name: app-v1
          port: 8080
          weight: 3
          namespace: prod-appv1
        - name: app-v2
          prot: 8080
          weight: 1
          namespace: prod-appv2

how to proxy it to multiple namespaces ?

Hi! I'm Træfiker :robot: the bot in charge of communication regulation.
Thanks for your interest in Traefik!
We dedicate the issue tracker to bug reports and feature requests only. My advanced AI has spotted that your issue might be a configuration problem or relates to something that doesn't look like a bug.
To confirm this, please join our Community Forum and reach out to us on the Traefik section.
In case I'm wrong (well, that would be embarrassing :sweat_smile:), my developers will re-open the issue and fix me!
In the meantime, you can double check Traefik's documentation.


crispyDoom: move build dep to python3

Motivation for this change
https://github.com/NixOS/nixpkgs/issues/148779
Things done

Built on platform(s)

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

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

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

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

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

[ ] Fits CONTRIBUTING.md.

Result of nixpkgs-review pr 150049 run on x86_64-linux 1

1 package built:

crispyDoom


Dashboard: Add Dialog to display yaml, i18n, fix some ts error

What type of PR is this?

Added a dialog for showing replicaRecommend, recommendationRule, resourcesRecommend yaml
Added a dialog for showing some frequently used command of resourcesRecommend, replicaRecommend
Wrap word with i18n.t
Fix some ts error

What this PR does / why we need it:
Which issue(s) this PR fixes:

Fixes #
Special notes for your reviewer:

Please resolve these conflicts.

Make the build task for the dashboard normal.
https://github.com/gocrane/crane/runs/7820512156?check_suite_focus=true#step:14:347


Main issue for performance investigations

I'll post information about performance investigations here.

I ran Pose2SLAMG2O on the INTEL dataset from https://lucacarlone.mit.edu/datasets/.
Here's a flamegraph: https://storage.googleapis.com/swift-tensorflow-misc-files/flamegraphs/2020-05-07-SwiftFusion-Pose2G2O.svg
Discussion
It's spending a lot of time doing small matrix operations in TensorFlow. The TensorFlow overhead is large relative to the small operations, so most of the time is probably spent on TensorFlow overhead. Therefore, switching from Tensor to Array (or eventually SIMD) is going to be a huge performance win and we should do that before any other attempts at optimization.
How to make the flame graph (Linux)
Prerequisites:

linux-perf debian package (or equivalent)
clone https://github.com/brendangregg/FlameGraph somewhere

# start in SwiftFusion repo root
# assumes FlameGraph is cloned to ../FlameGraph
swift build -c release
perf record -F 499 -g -- .build/release/Pose2SLAMG2O ~/input_INTEL_g2o.g2o
perf script | ../FlameGraph/stackcollapse-perf.pl | swift-demangle | ../FlameGraph/flamegraph.pl --width 1800 > flamegraph.svg

Am I right in concluding transpose is a lot of the CPU? Not used to reading the flamegraphs

Am I right in concluding transpose is a lot of the CPU? Not used to reading the flamegraphs

Yes, that's correct! And there's an easy optimization to completely eliminate that call. matmul, which is called from this method, has transposed arguments that let you replace
matmul(jacobians[pos].transposed(), r)

with
matmul(jacobians[pos], transposed: true, r)

Thanks Marc for the benchmarks :) I think judging from the flamegraph the TF engine seems to be doing a lot of work for the transpose call? I guess it's a elementwise copy (non-SIMD), but still curious on what exactly is happening under the call.

I think judging from the flamegraph the TF engine seems to be doing a lot of work for the transpose call? I guess it's a elementwise copy (non-SIMD), but still curious on what exactly is happening under the call.

The TF engine has a lot of overheads. I don't know specifically what's happening in the transpose, but in general it's something like this:

calculate the shape of the result
allocate space for the result and reference count the space
indirection: the swift function builds a "tranpose op" and sends it to TF, then TF interprets the op and executes a "kernel" that does the actual work (I think that there are actually even more layers of indirection but I don't know the exact details)
check if any errors happened while executing the op

I wouldn't be surprised if this transpose is spending less than 1% of the time doing the actual work and the rest of the time in TensorFlow overhead.

I switched things from Tensor to an array-backed Vector type and it got a lot faster. The time it takes to do 200 CGLS iterations on the INTEL dataset went from 90sec to 0.1sec.
I still need to clean things up and document them before it's ready for a PR, but here's a draft commit: https://github.com/borglab/SwiftFusion/commit/3e36e82d358a4e8e2f36140bd6bb88ac53deb6f5
Here's the new flamegraph: https://storage.googleapis.com/swift-tensorflow-misc-files/flamegraphs/2020-05-09-SwiftFusion-Pose2G2O.svg

Well, that certainly has the right directionality :-)

FYI, on my mac:

I just did a profile of Pose3SLAM, it seems that most of the time is used in the initialization of Tensors (Tensor.init(), 14s/16s total), the tensor ops actually only uses a fraction of the runtime.

I just did a profile of Pose3SLAM, it seems that most of the time is used in the initialization of Tensors (Tensor.init(), 14s/16s total), the tensor ops actually only uses a fraction of the runtime.

This makes sense, Tensor.init() does heap allocations and Tensor.init() is called a lot of times in the inner loop of linearization for Pose3/Rot3. In principle, this should be very easy to solve by replacing Tensor with Matrix3x3. (Matrix would improve things a bit over Tensor, but it still has a heap allocation for the array). I have filed https://github.com/borglab/SwiftFusion/issues/52 for this. I won't start work on https://github.com/borglab/SwiftFusion/issues/52 right away, because there's another performance thing that I'm looking at (will write it up here soon), but I could do https://github.com/borglab/SwiftFusion/issues/52 pretty soon.

Slowness from heap allocations and dictionary lookup
I can confirm that it is important to minimize heap allocations and dictionary lookups in our inner loop. Evidence:

Here's a flamegraph for Pose2SLAM on the INTEL dataset at current master. Lots of time is spent on allocation/initialization/deallocation and on dictionary operations.
The 900x performance improvement that I mentioned in https://github.com/borglab/SwiftFusion/issues/42#issuecomment-626142882 happens when I did an experiment that removes all heap allocations and dictionary lookups from the CGLS inner loop.

Therefore, we should discuss how to structure the APIs to achieve this.
Dictionary lookup
Dictionary lookups that we have now are:

While evaluating factor errors, the factor looks up values in a dictionary.
While performing GaussianFactorGraph "matmul", the GaussianFactorGrapg looks up the vectorvalue in a dictionary.

We could eliminate this by assigning a consecutive Int to each Key that is added to a NonlinearFactorGraph, and then use that Int everywhere instead of the Key.
Users can still construct factor graphs using arbitrary Keys and they can still refer to their values using Keys. We just do the mapping to consecutive Ints under the hood.
Heap allocations
Heap allocations that currently exist are (in order of badness):

VectorValues allocates its entries on the heap because each Vector is an array. (This is the worst because it happens in the CGLS inner loop.)
Values allocates its entries on the heap because type-erase values require heap allocations.
NonlinearFactorGraph allocates its entries on the heap because type-erased factors require heap allocations.

We could eliminate these heap allocations by implementing some sort of "flattened container" that stores everything as a single array of Doubles under the hood.
e.g. VectorValues really is just an array of Doubles. Right now we're storing it as an array of array of Doubles, but we could flatten it out and store offsets. We can do similar things for Values and NonlinearFactorGraph.
This doesn't have to be exposed through the user-facing APIs at all! These "flattened containers" can have APIs that make them look like totally normal collections of normal structs. Just under the hood, they store things efficiently.

I think these are pretty important to explore soon, because they may require some changes to the APIs, and we don't want to get locked into unperformant APIs.
Thoughts?

Methinks our data-oriented design discussion might have a large influence on this.
some relevant slides that I have not parsed in any depth :-)

Yeah, this is, I think, very related to data-oriented design. I haven't read any of the related work you mentioned during the meeting yet. I'll go read them now and also those slides.

Yeah, esp. http://optlang.org/ should be insightful. We are threading two graphs here: autodiff graph and sparse problem graph.

optlang is very cool. I'm just a few pages into the paper, and I'm already seeing some interesting ideas that could make the SwiftFusion API very different, in a good way.
Idea: The only "fixed" thing is the generic concept of a nonlinear least squares problem. There are multiple concrete representations of the problem. Depending on your concrete problem and depending on what algorithms you want to run on the problem, different concrete representations are optimal.
For instance, should the factor graph (the vertices and edges) be materialized in memory? If so, which graph representation should we use in memory? Should the data associated with the vertices (e.g. the BetweenFactor distance) be stored inside or outside the graph datastructure? There is no right answer. It depends on the concrete problem. E.g:

Pose2SLAM from a g2o problem: Load an adjacency list representation into memory. Put the data associated with vertices in a homogeneous buffer, for fast access. Linearize, storing the resulting jacobians in a homogeneous buffer. Pass the adjacency list and jacobians to a direct LLS solver.
Optical flow problem (from the bottom of http://optlang.org/): Don't materialize the graph structure in memory! The graph structure is given by a simple function { (vertex: PixelPosition) in [vertex + (0,1), vertex + (0,-1), vertex + (1,0), vertex + (-1,0) }.
Huge SfM problem: Partition the graph into a distributed graph datastructure that lives on multiple machines. Each machine linearizes the factors that it owns, storing the jacobians in a homogeneous buffer. Run a distributed LLS solver.

We want an API with the flexibility to choose different data representations, and then run algorithms that are compatible with those representations. e.g. The linearization algorithm does not care how the graph is represented. It can operate generically on any graph datastructure that supports a query for vertex neighbors, like an adjacency list or the "neighboring pixels" function from the optical flow problem.
This is very compatible with Swift because Swift encourages "protocol oriented programming"! (I highly recommend these talks: Protocol Oriented Programming, Embracing Algorithms). Protocol oriented orogramming is quite similar to data oriented programming. You write types representing your data, you write protocols representing the allowed operations on your data, and you write generic algorithms that can operate on any data that supports the required operations.

We want an API with the flexibility to choose different data representations, and then run algorithms that are compatible with those representations. e.g. The linearization algorithm does not care how the graph is represented.

I agree with that (actually that is exactly what Opt and similar "optimization DSLs" are doing: decoupling abstract representation of data with its in memory representation :)

This is very compatible with Swift because Swift encourages "protocol oriented programming"! (I highly recommend these talks: Protocol Oriented Programming, Embracing Algorithms). Protocol oriented orogramming is quite similar to data oriented programming. You write types representing your data, you write protocols representing the allowed operations on your data, and you write generic algorithms that can operate on any data that supports the required operations.

These talks are great! (BTW I also love 80x24 terminals, haha)

We could eliminate these heap allocations by implementing some sort of "flattened container" that stores everything as a single array of Doubles under the hood.

Yeah I also think we can implement a container-like thing that offers the same API but uses a raw storage backend. (like a memory pool allocator in C++).
P.S. I also did a profile on the G2O for INTEL and the result aligned with yours :-\

Excellent, I’m loving this discussion, and he will I will watch the talks. I think we may be able to undo some of the mistakes that were made in GTSam, because we did not know better at the time.
The one thing we need to absolutely keep is the factor graph abstraction. This is strictly more general than least-squares solving. For example, we can solve a sudoku, by making the factors constraints. Or do inference with Bayes networks, I making the factors probabilities depending on discrete Variables.
Something GTsam cannot do, is mixing discrete and continuous variables. In principle, a factor graph can have both, and factors could be continuous (think least squares or robust error metric), discrete (such as a constraint, or a probability), or mixed.
Really: Factor: anything -> bool or float
Where float is least squares or a negative log(probability) (least squares is -log Gaussian)
Optimization: feasible (all bool factors are True) and sum of floats is minimized

The one thing we need to absolutely keep is the factor graph abstraction. This is strictly more general than least-squares solving. For example, we can solve a sudoku, by making the factors constraints. Or do inference with Bayes networks, I making the factors probabilities depending on discrete Variables.

Something GTsam cannot do, is mixing discrete and continuous variables. In principle, a factor graph can have both, and factors could be continuous (think least squares or robust error metric), discrete (such as a constraint, or a probability), or mixed.

Interesting, thanks for these examples, I will think about them.
Based on this, I'd argue that the general abstraction we should start with is a "Factor Objective" which is a function from "Variables" to "Factor Errors". Perhaps the objective also has a notion of "total error" and "feasibility".
What's not included in the "Factor Objective" abstraction:

Any notion of graph.
Any notion of building it by adding factors.
Any constraints on what types the variables are or what types the errors are.
Any constraints on what the function can do.

So "Factor Objective" is way too abstract to run any useful optimization algorithms on it. (I guess if you have a random generator for variables values, you can try a bunch of random values and see which one gives you the best result.) Therefore, we need slightly more concrete abstractions. (In Swift, making abstractions slightly more concrete is "protocol refinement").
One important refinement would be the FactorGraphObjective, which adds some additional constraints to the objective that let you run graph algorithms on it.
Concrete implementations of FactorGraphObjective could be structs like:
struct AdjacencyListFactorGraph: FactorGraphObjective {
  var factors: [FactorKey: NonlinearFactor]
  var adjacencyList: BipartiteGraphAdjacencyList<FactorKey, ValueKey>
  ...
}

struct DistributedFactorGraph: FactorGraphObjective {
  var factors: DistributedCollection<FactorKey, NonlinearFactor>
  var graph: DistributedBipartiteGraph<FactorKey, ValueKey>
  ...
}

/// This is kinda like the `NonlinearFactorGraph` that is in `master` today.
struct JustAnArrayOfNonlinearFactors: FactorGraphObjective {
  var factors: [NonlinearFactor]
}

Another important refinement is a LinearLeastSquaresObjective supporting the operations required for LLS solvers like CGLS.
Concrete graph types like AdjacencyListFactorGraph, DistributedFactorGraph can conform to LinearLeastSquaresObjective, letting you pass them directly to a CGLS solver.
The power of abstracting things this way is that you're not constrained to use a particular representation of data when you invoke an algorithm. For example, maybe there's some solver that extracts a dense linear least squares subproblem from a factor graph and then runs some LLS solver on that dense problem (dunno if there is such an algorithm, it's just an example). If the LLS solver requires AdjacencyListFactorGraph, then we have to uselessly spend some time constructing an adjacency list before we invoke the solver. If the LLS solver is generic, then we simply construct the most efficient dense representation and immediately pass to the LLS solver.

My favorite way of designing something like this is iteratively building up the abstract protocols and concrete structs together. Today we have some concrete structs already! I'm about to make a PR suggesting a slight abstraction over them.

I like FactorObjective as a protocol, if not its name :-) I think "Factor" would be nice ! Similarly, why not just make the other protocol "FactorGraph". One of the requirements would be that it has an "error", which we could make float, reserving infinity for infeasible configurations.
This has the danger of being religious/subtly, but I don't love "Objective", as it subtly shifts the emphasis away from the factor graph concept, in a way that I think hurts the cause. I understand how after seeing the OPTLang talk everything will seem cool and least-squarey :-)
I think LinearLeastSquaresObjective moves us away even more, now having zero graph concept. But, truly, to me the graph is everything. The stenscils in optlang are all about a concise way of specifying a graph. The actual objective is almost irrelevant to the structure of the computation.
Two Frankisms (aka Crusty grumblings) that are relevant:

a (sparse) matrix is just a clumsy way of writing down a graph
we have to get out of the matrix gutter

Objective pushes us to matrix-land by association.

I'll add my two cents here: I agree with Frank that one of the reasons why Opt is fast is by getting rid of the sparse matrix representation of LS problems (though not completely, as the notion of Jacobian is still there), and replace these into implicit representations, the Jacobian can be computed on GPU ad-hoc, saving a lot of memory bandwidth and ops. I consider the factor graph scheme to be something that effectively encloses the concept of objective function (in a LS sense), but with much more potential.
Currently we are using an immediate-mode evaluation of factors (on linearization), and the graph structure can only be exploited at the sparse Jacobian level. However, with minimal amount of hint, we can effectively extract the common shared structure of sub-graphs, and build optimizations on top of that.
One of the major roadblocks for "matrix-free optimization" in the past is that it is very hard to represent free-form Jacobians in a concise manner without too much boilerplate. S4TF does exactly that, so I think we are pretty lucky here :)

Also, an interesting read would be https://stanford.edu/~boyd/papers/pdf/abs_ops.pdf
Boyd is one of the biggest names in optimization :-\

This conversation has become very interesting. Would you like to have a call some time tomorrow so that we can discuss a bit more efficiently? I'm free any time after 2pm Eastern time?
I'll also keep responding here in github because I can't wait to keep talking :)

This has the danger of being religious/subtly, but I don't love "Objective", as it subtly shifts the emphasis away from the factor graph concept, in a way that I think hurts the cause. I understand how after seeing the OPTLang talk everything will seem cool and least-squarey :-)

I agree that "objective" has some unnecessary connotations, let's remove it.
I agree that LinearLeastSquaresObjective is a terrible name. I have thought more about it and discussed with Dave Abrahams and I think I have a better one now: DecomposedAffineFunction. I will update the PR.

I think LinearLeastSquaresObjective moves us away even more, now having zero graph concept.

Yes and no. There are two things:

There are concrete structs conforming to LinearLeastSquaresObjective, and they absolutely still have the graph concept front and center in them. (You may be thinking in a C++ mindset where having a LinearLeastSquaresObjective superclass dictates things about your implementation. Swift protocols dictate nothing. The concrete structs can be whatever you want.)
There is the abstract protocol LinearLeastSquaresObjective, which does not have a graph concept in it. I argue that this is an unambiguously good thing because it means that algorithms that truly do not depend on graph structure (e.g. CGLS) are not coupled to graph structure.

I'll boldly claim that by decoupling DecomposedAffineFunction from the concept of a graph we actually make things more graph-oriented because you are freed to experiment with different graph representations of a problem without worrying about how you're going to coerce it into whatever concrete type CGLS operates on.
For example, suppose I want to run CGLS on a matrix-free graph. I can't do that today with GaussianFactorGraph. One approach would be subclassing: have a "matrix free jacobian factor" that is allowed to be inside GaussianFactorGraph. This approach has drawbacks: (1) virtual function call overhead (2) not data-oriented (3) assumes that the factors can even be stored in a single array on a single computer (4) each matrix-free jacobian instance needs to store references to the data that it is derived from, even though it's always the same data. The DecomposedAffineFunction approach is very simple and has none of the drawbacks:
struct MyProblem {
  var graphRepresentation: SomeGraphDatastructure
}

// Note that this struct _represents_ the linearized problem at a point, but constructing this
// struct doesn't actually do any linearization work. That happens later when we're actually
// evaluating the affine function.
struct MyProblemLinearized {
  var graphRepresentation: SomeGraphDatastructure
  var point: Point
}

extension MyProblemLinearized: DecomposedAffineFunction {
  typealias Input = KeyedVector
  typealias Output = KeyedVector

  func applyLinear(_ v: KeyedVector) -> KeyedVector {
    return differential(of: { someFactorFunction(graphRepresentation, $0), at: point)(v)
  }

  func applyLinearDual(_ v: KeyedVector) -> KeyedVector {
    return pullback(of: { someFactorFunction(graphRepresentation, $0) }, at: point)(v)
  }
  ...
}

let problem = MyProblem(file: "path/to/my/data.txt")
var x = KeyedVector.zero
var optimizer = CGLS()
optimizer.optimize(problem: problem, initial: &x)

This is very data-oriented. MyProblem just stores the data, and the data doesn't "know" how to do anything to itself. The extension MyProblemLinearized: DecomposedAffineFunction specifies the operations on the data.
It's also very graph oriented -- the user specifies exactly what graph datastructure best represents their problem.
Ohhhhhh, I think after I wrote this example I finally realize what you mean about differential and pullback being very well suited to factor graph optimization. They let you avoid ever materializing the jacobian!

Currently we are using an immediate-mode evaluation of factors (on linearization), and the graph structure can only be exploited at the sparse Jacobian level. However, with minimal amount of hint, we can effectively extract the common shared structure of sub-graphs, and build optimizations on top of that.

Yes, and I think that DecomposedAffineFunction protocol is a very important part of doing this. DecomposedAffineFunction encapsulates precisely what it means to linearize a factor graph, so that you can store whatever structure information you need for computing jacobians, without being constrained by anything except the small number of requirements on DecomposedAffineFunction.

Overall, I'm trying to argue for the view that we should provide a library of generic functions (optimizers, graph algorithms) and a library of graph datastructures. Then, the user with a concrete problem defines their own type representing the data in their own problem, using the most appropriate datastructures from our library, and finally invokes some of our generic algorithms on their datastructure.

/// An affine function decomposed into its linear and bias components.
protocol DecomposedAffineFunction {
  associatedtype Input: EuclideanVectorSpace
  associatedtype Output: EuclideanVectorSpace

  /// Apply the function to `x`.
  ///
  /// This is equal to `applyLinear(x) + bias`.
  ///
  /// Note: A default implementation is provided, if you specify `bias`.
  func callAsFunction(_ x: Input) -> Output

  /// The linear component of the affine function.
  func applyLinear(_ x: Input) -> Output

  /// The dual map of the linear component of the affine function.
  func applyLinearDual(_ y: Output) -> Input

  /// The bias component of the affine function.
  ///
  /// This is equal to `applyLinear(Input.zero)`.
  ///
  /// Note: A default implementation is provided, if you specify `callAsFunction`.
  var bias: Output { get }
}

Also, an interesting read would be https://stanford.edu/~boyd/papers/pdf/abs_ops.pdf

This is cool. I've started reading it.
I notice that the "Forward-Adjoint Oracle" is very similar to DecomposedAffineFunction:

applyLinear is the "algorithm for evaluating f"
applyLinearDual is the "algorithm for evaluating f*"
bias is doesn't exist in FAO because FAO is for linear, not affine, functions.

So, I finally matched the error terms between GTSAM and SwiftFusion, and here are the latest benchmark results:

I think Chordal still has some discrepancy against GTSAM, so definitely need to investigate. I am speculating on the ClosestTo method, but need to do a side-by-side with GTSAM to confirm (no time for now)
@dellaert @marcrasi

Awesome work! My bet would be on LM being different, as we discussed.
Perhaps to allow Marc and Dave to concentrate on performance, can you time the inner linear solving step and the linearization separately? Also, you should probably ensure only one thread is used in both cases.

@dellaert Sure thing, I'll try benching the inner loop. BTW, yes, we are using only one thread in both configurations.

Cool graphs! Do you have instructions for generating them so that I can quickly see how perf optimizations show up on these graphs?

Also I'm curious: What linear solver are the GTSAM runs using?

@marcrasi It's the sequential Cholesky solver (a direct solver). I pushed all results and scripts to generate these graphs to https://github.com/ProfFan/expmap-benchmark, however you will also need the prebuilt wheels of GTSAM in different configurations in https://github.com/borglab/gtsam-manylinux-build/branches (the CI artifacts)

@marcrasi It's the sequential Cholesky solver (a direct solver).

Ah, that also explains some things! Can you do PCG with Jacobi also? How do they compare? Again it will be important to choose the exact same convergence criteria on both sides of the "aisle", to make sure we're not timing the convergence criterion but rather the solve.

Can you do PCG with Jacobi also?

For perfectly comparable results, you'll need to do PCG with DummyPreconditioner because I haven't gotten to implementing the Jacobi preconditioning in Swift yet. (I intend to do that after simplifying the matrix boilerplate, because the preconditioning involves some linear algebra that will be much easier when there is an easy way to manipulate matrices.)

@marcrasi It's the sequential Cholesky solver (a direct solver).

Ah, that also explains some things! Can you do PCG with Jacobi also? How do they compare? Again it will be important to choose the exact same convergence criteria on both sides of the "aisle", to make sure we're not timing the convergence criterion but rather the solve.

I wanted to but haven't got time, probably will do next week

Need some new figs:

Dummy & Jacobi in GTSAM (should get same iterations as SwFusion)
CGLS(=Dummy) in SwiftFusion (should give exactly same numbers as in GTSAM)


Tool calls break with uvloop lib installed

Encountered a bug due to uvloop acting as a drop-in replacement for asyncio. In my stack, the Chromadb package installed uvloop, which caused opengpts to fail on function calls. The bug occurs when running function calls with openai_agent (I didn't have time to test the other agents).
Steps to replicate:

pip install uvloop,
create assistant with DDG func call,
ask any question that triggers a search.

I've outlined where the crash occurs below and the debug output.
File and method:
openai_agent.py->get_openai_agent_executor()
# We call the tool_executor and get back a response
responses = await tool_executor.abatch(actions)
Error:
File "/usr/local/lib/python3.11/asyncio/events.py", line 681, in get_event_loop
raise RuntimeError('There is no current event loop in thread %r.'
RuntimeError: There is no current event loop in thread 'ThreadPoolExecutor-1_0'.

ran into the same issue with DDG func call.


ZipExtract Error  with composer install on Windows.

When you try to do a composer install on windows it throws an error with the zip extraction. There is no useful error message but googling suggested it is because of a long path names issue on windows. (I'm using Win 7, WAMP server 2, php 5.5.12 )
Workround was to move the project folder up to the drive root and run it there where it worked fine.
Bit of a faff but not too onorous.
Could this be flagged up or could a more useful error message be generated to save others the time tracking this down?

Sadly this is an issue on Composer itself.
See (after a fast search on Google) https://github.com/composer/composer/issues/3755

Yes, but can it be documented in the setup so it is obvious what the 'solution' is, took me quite a while to sort this out.
Thought it would be easy to add into the read me as a footnote.

On 22 Apr 2015, at 11:04, Jeremy Benoist<EMAIL_ADDRESS>wrote:
Sadly this is an issue on Composer itself.
See (after a fast search on Google) composer/composer#3755
—
Reply to this email directly or view it on GitHub.

Can you submit a PR ?


Release CSV Updates

Updates to release CSVs to make Service Names and Package Display Names match across languages.

My CSV Editor extension for VSCode keeps messing with every line of the CSV. I'll fix this.


Pop-up Calendar positioning is off

The calendar pop-up shows too high above the input text box container. This issue is similar to the one I saw on Stackoverflow at http://stackoverflow.com/questions/33588246/how-to-get-bootstrap-datepicker-calendar-to-anchor-below-textbox

I've got this problem. In my case, it's related to me having a margin on my body.
I fixed it by changing appendOffset to be container.position() instead of container.offset() in the js file.
From the jquery docs: "When positioning a new element near another one and within the same containing DOM element, .position() is the more useful." but not sure if that's correct in this case.

@vsn4ik what do you think of the position/offset change? Or how to solve this?

I've produced a jsfiddle here: http://jsfiddle.net/amgztw11/
That shows the problem when using a div with a margin, which I don't think position() fixes unfortunately, although I've not looked into it in depth yet.

Thanks for the example @abeverley!

Interestingly, when the main Bootstrap CSS file is removed, then it appears in the correct place. This seems to happen regardless of whether the standalone bootstrap-datepicker CSS file is used or not.

To be honest, I don't understand the purpose appendOffset. If I remove it altogether, then the pop-up always appears in the right place. I've tested with margins, with/without the main Bootstrap CSS file, changing the container, and it's always correct. Am I missing something?

+1

+1
Without 'orientation', the datepicker is placed above the input field, with the arrow on top of it (thus at the wrong side).
With 'orientation: "bottom"', the picker is positioned below the field, with the arrow at the bottom.
Using the bootstrap CSS, the arrow is positioned correctly, but it is upside down.

It's worth checking out #1364 and what @yoyos has to say about removing the appendOffset subtractions from the left and top var declarations.

I don't have much to say except I didn't find the usefulness of appendOffset  and everything was fine without it :p.
I haven't check the new release to see if problem was resolved.

changing line 718 tp top = offset.top - 0; fixes the issue

+1 on this. I'm using the bootstrap sticky header and started seeing this with v1.5.0.

+1 on this. I'm experiencing the same problem, but regarding the horizontal positioning. I'm using v1.5.1.

I am experiencing the same when using the datepicker in a Unify Bootstrap3 template. The problem only occurs when the layout is set to "boxed-layout".
In my case:

If the layout takes the whole browser width, the datepicker works fine. In css, it seems that the width attributes are causing the problem - maybe datepicker picks the wrong width / wrong media selector?!:
@media (min-width: 1200px) .container {     width: 1170px; } @media (min-width: 992px) .container {     width: 970px; } @media (min-width: 768px) .container {     width: 750px; }

See simple example here https://jsfiddle.net/d3som9vc/.

+1

In 1.6 I'm getting an effect in which if I specify orientation top it goes to the bottom of the textbox and if I specify bottom it goes to the top! The math calculation of the style top property seems to be inverted. I downgraded to 1.4 and it was working ok.

I had a similar issue, only it shows a lot below. I removed this line of code and it worked perfectly.
if( !elementOrParentIsFixed(this.element) ){
top = top + document.body.scrollTop;
}

👍


gnunet{,-gtk}: bump to 0.13.1

Motivation for this change
follow up to: #77828
the gnunet and gnunet-gtk project seem to be developed in tandem, seems to make sense to have them under the  same directory
Things done

[x] Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS linux)
Built on platform(s)

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

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
[x] Tested execution of all binary files (usually in ./result/bin/)
[ ] Determined the impact on package closure size (by running nix path-info -S before and after)
[ ] Ensured that relevant documentation is up to date
[x] Fits CONTRIBUTING.md.

cc @pstn @vrthra

Changes look good, weird localization behaviour of gnunet-fs-gtk seems to be gone, too.
Anybody against moving me as maintainer to default.nix and also inherit over to gtk.nix? Doesn't seem to make sense to just maintain one of the two when they even share the version number.

@pstn please take another look

I like the changes and learned about mirror:// in nixpkgs. Good to know. Executables still seem fine, too.


match for colors without hash

Allows the ability for colors such as cc241d to be detected, since some configuration formats such as 0xcc241d or cc241d alone do not get detected.

Hi, thanks for taking an interest in the plugin.
The only issue I see with this commit is that if we allow the plugin to highlight any arbitrary hexadecimal text it may end up looking a bit funky when color highlighting isn't perhaps something we want or expect, so my thoughts are that perhaps we should be able to toggle this functionality? I was thinking that adding an additional variable that alters the plugins behaviour might be more ideal.
Let me know what you think.

While you are correct, some words will be mistaken for colors (like BADDAF probably), I prefer this behavior since it is I want to see colors.
I believe what could work is for the pattern to detect values such as 0xEBBDB2 and = EBDDB2 for configuration.


sync autorest.sharp pr 4814: set no-route warning

Sync https://github.com/Azure/autorest.csharp/pull/4814

API change check
API changes are not detected in this pull request.


Add primary key check before delete

Added primary key validation before deleting a record to ensure all records aren't deleted if a primary key is not set when calling db.Delete(value). That behaviour should be reserved for db.DropTable() or have it's own function.
Unfortunately I haven't been able to add a test as running go test returned error:
./query_test.go:311: cannot use gorm.Expr("name = ? DESC", "OrderPluckUser2") (type *gorm.expr) as type string in argument to scopedb.Order
FAIL	github.com/danhardman/gorm [build failed]

Shouldn't have to be fiddling around with other code to get this working!

Hi @danhardman
Sorry, but I don't think this is necessary. I think before delete, you should check the data is valid or not.
Also Delete could also works with structs w/o primary key but other fields as conditions, like: db.Delete(&User{Role: "normal"})

Thank you for your PR anyway.

Hadn't even thought about that, however it would be possible to check if every field on a given value has a "zero-value". Although it would be temperamental I guess. Shame!


[FEATURE REQUEST] Upgrade Kubernetes to 1.22.x

Is your feature request related to a problem? Please describe.
Upgrade K8s to 1.22.x to be able to perform future upgrades.
Describe the solution you'd like
Upgrade K8s to 1.22.x with dependencies: CNI plugins, dashboard, etc. Check release notes for that, deprecated things should be removed/updated.
Additional information
The Kubernetes project maintains release branches for the most recent three minor releases (1.22, 1.21, 1.20). Kubernetes 1.19 and newer receive approximately 1 year of patch support. Kubernetes 1.18 and older received approximately 9 months of patch support.

DoD checklist

[ ] Changelog updated
[ ] COMPONENTS.md updated / doesn't need to be updated
[ ] Schema updated / doesn't need to be updated
[ ] Feature has automated tests
[ ] Automated tests passed (QA pipelines)

[ ] apply
[ ] upgrade

[ ] Idempotency tested
[ ] Documentation added / updated / doesn't need to be updated
[ ] All conversations in PR resolved
[ ] Solution meets requirements and is done according to design doc
[ ] Usage compliant with license
[ ] Backport tasks created / doesn't need to be backported

https://kubernetes.io/docs/reference/config-api/kubeadm-config.v1beta3/#migration-from-old-kubeadm-config-versions

Added #2658 as a blocker.

✔ apply x86_64, aarch64
✔ apply HA cluster
✔ promote to HA
✔ single machine installation
✔ upgrade from v1.0 x86_64
✔ upgrade from v1.1 aarch64
✔ upgrade from v1.0 single machine installation
✔ upgrade from v1.0 HA installation


The system should send an e-mail to the current user when his existing information has been changed.

Branched off from #199.

Duplicates #199


AT-SPI SDSPI with STM32 doesn't work

Answers checklist.

[x] I have read the documentation ESP-AT Programming Guide and the issue is not addressed there.
[x] I have used the latest released firmware or have updated my ESP-AT branch (master or release) to the latest version and checked that the issue is present there.
[X] I have searched the issue tracker for a similar issue and not found a similar issue.

General issue report
HI,
I'm trying to port SDSPI example to STM32L4, but it doesn't work.
As you noted in README, I was starting with checking that hardware works well.
First that I do - upload ESP-AT to ESP32 as slave(using the latest version of core, esp-idf v.5.0.2 and ESP-WROOM-32 devkit). Then I upload ESP example from SDSPI folder and all works fine.("AT" command return "OK")
Then I tried with STM32F103ZE dev board to check the STM32 example before porting and it doesn't work.
The connection is next:
STM32    --->   ESP32
SCLK (PA5)   --->    CLK(GPIO14)
MOSI (PA7)   --->    CMD(GPIO15)
MISO (PA6)   --->    DAT0(GPIO2)
GPIO_INT (PA0)   --->    DAT1(GPIO4)
CS (PA4)   --->    DAT3(GPIO13)
All lines excluding CLK is pulled-up with 10 kOhms resistors.
Project was build using STM32CubeIDE from .ioc config file from example and all code is copied from example.
Debug console oputput:

10:24:14.414 -> E sdspi_trI sdspi_transaction: IOE: 0x02
10:24:16.191 -> I sdspi_transaction: IE: 0x03
10:24:16.191 -> I sdspi_transaction: BUS_WIDTH: 0x40
10:24:16.191 -> I sdspi_transaction: BUS_WIDTH: 0x60
10:24:16.191 -> I sdspi_transaction: Function 1 BS: 0000
10:24:16.191 -> I sdspi_transaction: Function 1 BS: 0200
10:24:16.191 -> D sdspi_transaction: spi_io_read_bytes, will transfer size: 4

and then all is stucked
This is the datagramma of all lines after reset:

@ESP-Coco could you please help take a look

@MichaelXlivnenko  Do you have more detailed LOG? I need to observe a step that detects a problem.

Did you mean LOG iutput in console or signals output?

Full STM32 LOG, you can change deugLevel to 4(https://github.com/espressif/esp-at/blob/master/examples/at_spi_master/sdspi/STM32/Inc/port.h#L48)

10:27:55.666 -> V sdspi_transaction: CMD0
10:27:55.666 -> V sdspi_transaction: r1 = 0x00 hw_cmd.r[0]=0xffffffff


populate ctx.params before running any matched middleware

The problem is that when I use router.use(someMiddleware), in that middleware I have access to payload from query string via ctx.query and to payload from request body via ctx.request.body but I haven't access to route params and this is not so convenient especially in my case.
To be more clear I will tell my story. I have a validation middleware which works like this.
It takes request method from ctx.request.method and matched route from ctx._matchedRoute and using that it takes necessary validation rules from validation schemas that look like this:
'PUT:/users/:id': {
    params: Joi.object().keys({
        id: Joi.string().length(24).alphanum().required(),
    }),

    query: Joi.object().keys(definitions),

    body: Joi.object().keys(definitions)
}

and for each type of payload, if it exists in the scheme, it checks for validity and problem comes here when it tries to validate params because params are not available in the middleware defined using router.use method.
This pull request fixes this type of problems and I think this will will bring much good in the future.
Thanks!

We need this as well

This is huge. @ZijianHe can you please merge this?

@smkoyan thanks for your work on this. this resolves most of my issues with Router.prototype.param.


Cannot install the Hospital Emergency Response App by adding it to Dynamics 365

Hi experts,
I followed the steps in the tutorial, however, I was unable to install the sample app when attempting to add the application to Dynamics 365 at the section https://docs.microsoft.com/en-us/powerapps/sample-apps/emergency-response/deploy-configure#option-b-install-the-app-from-microsoft-appsource and step 4. Maybe it's something related to my account. It said "Sorry, we couldn’t find a Dynamics 365 organization connected to the signed-in user. Please use different credentials or sign up for a free trial and try again." But what should I do to my account next? Please help!
Thanks!

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

ID: d57c5c3d-2fa4-c2cb-94c9-bac11db9b77a
Version Independent ID: 2f434aea-9b32-1470-4928-3d4ddd8e2227
Content: Deploy the Hospital Emergency Response app - Power Apps
Content Source: powerapps-docs/sample-apps/emergency-response/deploy-configure.md
Service: powerapps
GitHub Login: @pankajarora-msft
Microsoft Alias: pankar

Hi v-etzha, hope you are very well.
I had this situation as well. I found a quick work around was to use Power BI Pro/Premium and create a workspace then click the Add Content button. You'll get the screen shown next, choose the discover content from my organization option highlighted in the red rectangle shown next.

You should then see lots of Apps, type in "emergency" as your search term. You should see the 2 Apps as shown next, Notice there are no apps from "my organization" returned, but 2 that meet the criteria we searched for. Choose the left one which is the one you want.

You should see the next screen. Just follow the on screen instructiions of "GET IT NOW" which are easy to follow, it installs very fast.

You end up with the final app shown next. You can customize it as you wish and change or remove the organisation branding. Note that you must be in edit mode to do that.

I also found a way to reconstruct the app in Power BI Desktop which is where numerous people seem to want to see it working as shown next.

Obviously Power BI and Power BI Desktop are two different products whereby you cannot download the Power BI Emergency Response App as a .pbix file, the option is greyed out (shown next). Hence the need for the work around to reconstruct it in Power BI. The template option which Microsoft themselves don't recommend to use was a non-starter for me. Also I wanted to create a pure .pbix file that would work in any version of Power BI Desktop and display correctly. Bypassing the incompatibility of Power Apps and Power BI in certain areas. This is why you get warnings when you try to open certain files in BI Desktop explaining certain elements may not display correctly etc etc.

Thanks for the help! Close this since I have no question for now.


Adds "quote" parameter to "accepted_values" test

Adds quote parameter to accepted_values test. Closes #1873.
Users can now test for acceptable integer values by opting not to quote these values.
...
         - name: day_of_week
            description:
            tests:
              - not_null
              - accepted_values:
                  values: [1, 2, 3, 4, 5, 6, 7]
                  quote: false
...

Results in:
with all_values as (
    select distinct
        day_of_week as value_field
    from dw.dim_date
),
validation_errors as (
    select
        value_field
    from
        all_values
    where
        value_field not in (
            1,
            2,
            3,
            4,
            5,
            6,
            7
            )
)

select count(*)
from validation_errors

While the default behavior is to quote, e.g.
...
         - name: day_of_week_name
            description:
            tests:
              - not_null
              - accepted_values:
                  values: [Sunday, Monday, Tuesday, Wednesday, Thursday, Friday, Saturday]
...

with all_values as (
    select distinct
        day_of_week_name as value_field
    from dw.dim_date
),
validation_errors as (
    select
        value_field
    from
        all_values
    where
        value_field not in (
            'Sunday',
            'Monday',
            'Tuesday',
            'Wednesday',
            'Thursday',
            'Friday',
            'Saturday'
            )
)

select count(*)
from validation_errors

Thanks! Glad to get this test working better - it's been a long time coming :)
I just kicked off the tests here. CLA looks good too (@cla-bot check).
Looking forward to merging this!

@drewbanin anything I need to be doing re: that BigQuery integration test failure? Looks like they all failed, so this may be just a CI thing, but wanted to make sure.

Hmmm, that's really strange! I see this error in the Azure logs:
The job encountered an internal error during execution and was unable to complete successfully.

So, this looks like a BQ blip, I think we're ok here :)


Improve setup, test, and example information in README

README.adoc has a bit of outdated information and could use better description all around for running tests and the web_requests example locally.

Dockerize the deamon to make it run as a service inside the docker-compose would be great

Fixed by https://github.com/delta-io/kafka-delta-ingest/pull/30


use original file/directory with local pyflyte run

TL;DR
Fixes #4426. This PR makes it so that local executions use the original file/directory path instead of creating a temporary copy.
Type

[X] Bug Fix
[ ] Feature
[ ] Plugin

Are all requirements met?

[X] Code completed
[X] Smoke tested
[X] Unit tests added
[ ] Code documentation added
[ ] Any pending items have an associated Issue

Complete description
This PR makes modifications to the underlying click types and FlyteDirectory type so that the original files and directories are used.
Tracking Issue
https://github.com/flyteorg/flyte/issues/
Follow-up issue
NA

@kumare3 can you re-+1? the pyspark tests are unrelated, they're fixed by this: https://github.com/flyteorg/flytekit/pull/2007


Add support for Python 3.6-3.7, drop support for 2.6 and 3.4

Fixes #42.
Python 2.6 and 3.4 are EOL and no longer receiving security updates (or any updates) from the core Python team.

Version
Release date
Supported until

2.6
2008-10-01
2013-10-29

2.7
2010-07-03
2020-01-01

3.4
2014-03-16
2019-03-16

Source: https://en.wikipedia.org/wiki/CPython#Version_history
They're also little used. Here's the pip installs for json2html from PyPI for August 2019:

category
percent
downloads

3.7
32.54%
12,014

2.7
28.25%
10,431

3.6
26.78%
9,889

3.5
8.79%
3,246

null
2.89%
1,067

3.4
0.67%
246

2.6
0.07%
26

3.8
0.00%
1

Total

36,920

Source: pip install -U pypistats && pypistats python_minor json2html --last-month

Also adds support for Python 3.6 and 3.7, adds python_requires to help the right version of this package for the user's Python, and some Trove classifiers.
And also tests on Python 3.8, to help test 3.8 itself, plus ensure this library works on it.

Thanks @hugovk for the stats and the PR.
Why can't we support 2.6 and 3.4 along with other versions?

Well, you probably can, but it's not really worth supporting EOL versions, especially due to low usage. As voluntary maintainers, you should put your efforts into current versions, and take advantage of new Python features.
And more pressing, Python 2.6 is broken on the CI because Travis CI have decided it's not worth supporting with the current images.
Many projects are looking into when to drop Python 2.7, and many already have. See https://python3statement.org.

Thanks @hugojanruiter 👍

You're welcome!


Is Cerbos Playground open source?

Is there an existing issue for this?

[X] I have searched the existing issues

Feature description
Hi, sorry for all the questions (both here and in Slack)
Just wondering - is the Cerbos Playground open source? I would like to run a self hosted version of it on premise instead of developing in VS Code.
What would the ideal solution look like to you?
No response
Anything else?
No response

The playground UI is not open source. We are still doing a lot of development on it and it requires third-party infrastructure that is hard to package for an open source, self-hosted version.
This is a common request from the community and we are thinking of ways to help address it.

Hi @charithe - no worries. It would be great if you could open source it down the line because it provides a significantly better development environment than VS Code.

Hi, I still see playgroundEnabled flag on the configuration documentation and I thought it was still supported. To avoid confusion in the future I suggest the removal of any reference from documentation.


Is there a way to enable I2S Rock64 DAC on a mainline kernel or on the ayufan-rock64 4.4 kernel?

The title says it all.
I guess this requires fiddling with device tree, but I am not knowledgeable enough to figure out what to change. And the documentation on Rock64 wiki seems  to be lacking.

@mikhailian Do you talk about enabling spdif on i2s?

Nope, I am trying to get RCA analog output.
I booted mainline Arch Linux  kernel 5.11 and did not see the audio hat.
Tried with latest Armbian 5.10-21-rockchip64 and saw no audio hat either.
I can switch the built-in audio in mainline Arch Linux kernel before 5.12 with the following trick:
fdtput -t s /boot/dtbs/rockchip/rk3328-rock64.dtb /analog-sound status okay
reboot

Then,  aplay -l shows the following both with and without the DAC hat. I assume this is built-in audio.
**** List of PLAYBACK Hardware Devices ****
card 0: rockchiprk3328 [rockchip,rk3328], device 0: ff000000.i2s-i2s-hifi i2s-hifi-0 [ff000000.i2s-i2s-hifi i2s-hifi-0]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 0: rockchiprk3328 [rockchip,rk3328], device 1: ff010000.i2s-rk3328-hifi ff410000.codec-1 [ff010000.i2s-rk3328-hifi ff410000.codec-1]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 0: rockchiprk3328 [rockchip,rk3328], device 2: ff030000.spdif-dit-hifi dit-hifi-2 [ff030000.spdif-dit-hifi dit-hifi-2]
  Subdevices: 1/1
  Subdevice #0: subdevice #0

This is a ES9023-based DAC, I tried find /usr -name '9023'` but this gives no results.
Don't know where to start exploring from there.

@mikhailian
So, you try to connect to A/C output?
There's a bunch of different outputs on this board:

HDMI sound
RCA on a HiFi shield
Headphone jack on a HiFi shield
A/V Jack

I guess, we talk about RCA on a HiFi shield: these two goldplated connectors?

@mikhailian
From what I see the RCA on HiFi shield should be on i2s1, which is ff010000.i2s-rk3328-hifi. Can you try playing through this device? Can you also change J4 from L and H and vice-versa? This impacts a clock source of ES9023.

I tried all combinations of jumpers on the latest Armbian with kernel 5.10, but the only sound output that works is card0, device 1, which is the built-in audio.
Willing to try with the latest Linux mainline kernel, I wrote Arch Linux Arm to the emmc card, booted with it and  I now see the following:
uname -a
Linux alarm 5.12.0-rc3-3-ARCH #2 SMP Thu Mar 18 00:37:31 UTC 2021 aarch64 GNU/Linux
[root@alarm alarm]# aplay -L
null
    Discard all samples (playback) or generate zero samples (capture)
default:CARD=Analog
    Analog, ff010000.i2s-rk3328-hifi ff410000.codec-0
    Default Audio Device
sysdefault:CARD=Analog
    Analog, ff010000.i2s-rk3328-hifi ff410000.codec-0
    Default Audio Device
default:CARD=HDMI
    HDMI, ff000000.i2s-i2s-hifi i2s-hifi-0
    Default Audio Device
sysdefault:CARD=HDMI
    HDMI, ff000000.i2s-i2s-hifi i2s-hifi-0
    Default Audio Device

As much as I understand this, i2s bus is not even enabled, so I searched around, found  your dtedit script, extracted the current device tree, found
        i2s@ff020000 {
                compatible = "rockchip,rk3328-i2s\0rockchip,rk3066-i2s";
                reg = <0x00 0xff020000 0x00 0x1000>;
                interrupts = <0x00 0x1c 0x04>;
                clocks = <0x02 0x2b 0x02 0x139>;
                clock-names = "i2s_clk\0i2s_hclk";
                dmas = <0x10 0x00 0x10 0x01>;
                dma-names = "tx\0rx";
                #sound-dai-cells = <0x00>;
                status = "disabled";
                phandle = <0x6c>;
        };`

changed the status to okay, created the dtb file and wrote it to /boot/dtbs/rockchip/rk3328-rock64.dtb. Then I checked that is is picked by the kernel by comparing the old device tree to the new.
After all these manipulations aplay -L still shows
[root@alarm ~]# aplay -L
null
    Discard all samples (playback) or generate zero samples (capture)
default:CARD=Analog
    Analog, ff010000.i2s-rk3328-hifi ff410000.codec-0
    Default Audio Device
sysdefault:CARD=Analog
    Analog, ff010000.i2s-rk3328-hifi ff410000.codec-0
    Default Audio Device
default:CARD=HDMI
    HDMI, ff000000.i2s-i2s-hifi i2s-hifi-0
    Default Audio Device
sysdefault:CARD=HDMI
    HDMI, ff000000.i2s-i2s-hifi i2s-hifi-0
    Default Audio Device

dmesg does not seem to complain about i2s
[root@alarm ~]# dmesg -l err
[    2.566197] rockchip-pinctrl pinctrl: pin gpio0-2 already requested by vcc-host-5v-regulator; cannot claim for vcc-host1-5v-regulator
[    2.567342] rockchip-pinctrl pinctrl: pin-2 (vcc-host1-5v-regulator) status -22
[    2.568014] rockchip-pinctrl pinctrl: could not request pin 2 (gpio0-2) from group usb20-host-drv  on device rockchip-pinctrl
[    2.569054] reg-fixed-voltage vcc-host1-5v-regulator: Error applying setting, reverse things back
[    3.534716] gpio-syscon ff100000.syscon:grf-gpio: can't read the data register offset!
[    7.510715] rk_gmac-dwmac ff540000.ethernet: cannot get clock clk_mac_speed

nor does it tell anything about i2s.
[root@alarm ~]# dmesg |grep mclk
[root@alarm ~]#

Here is the gist with the complete device tree.

Also interested in this.   I used to have this working on armbian, but then moved house a few times and it went in a packing box for a while.  Trying to resurect it with the latest armbian no luck.
Today i tried volumio instead and bingo DAC shield RCA outputs work.
volumio@volumio:~$ aplay -l
**** List of PLAYBACK Hardware Devices ****
card 0: HDMI [HDMI], device 0: ff000000.i2s-i2s-hifi i2s-hifi-0 []
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 1: I2S [I2S], device 0: ff010000.i2s-rk3328-hifi rk3328-hifi-0 []
  Subdevices: 0/1
  Subdevice #0: subdevice #0
card 1: I2S [I2S], device 1: ff010000.i2s-snd-soc-dummy-dai snd-soc-dummy-dai-1 []
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 2: SPDIF [SPDIF], device 0: ff030000.spdif-dit-hifi dit-hifi-0 []
  Subdevices: 1/1
  Subdevice #0: subdevice #0
volumio@volumio:~$ uname -a
Linux volumio 4.4.154 #1 SMP Tue Oct 13 11:37:38 CEST 2020 aarch64 GNU/Linux


NullPointerException when projecting on a class with an orphaned link

OrientDB Version: 3.0.8
Java Version: Java8
OS: Linux
Expected behavior
It is possible to create orphaned links in OrientDB by creating a link from one class to another, and then deleting the document the link points too. This should not break the entire class.
Actual behavior
An orphan link essentially creates SELECTING on the entire class, causing a NullPointerException.
Steps to reproduce
This took some doing to detect what was going on and boil it down to something easily reproducible. First run this script to create the classes and add some data.
CREATE CLASS Target;
CREATE PROPERTY Target.id String (MANDATORY TRUE, NOTNULL TRUE);

CREATE CLASS Source;
CREATE PROPERTY Source.id String (MANDATORY TRUE, NOTNULL TRUE);
CREATE PROPERTY Source.target LINK TARGET (MANDATORY TRUE, NOTNULL TRUE);

INSERT INTO TARGET SET id = "target1";

INSERT INTO SOURCE SET id = "source1", target = (SELECT FROM Target WHERE id = "target1");

Selecting from the Source class works fine:
SELECT FROM Source;

A projection also works:
SELECT target.id FROM Source;

Now delete the linked document:
DELETE FROM Target;

Selecting from the source table works.
SELECT FROM Source;

However, trying a projection that includes crossing the orphaned link results in a NullPointerException.
SELECT target.id FROM Source;

The following stack trace appears in the console:
Internal server error:
java.lang.NullPointerException
	at com.orientechnologies.orient.core.sql.parser.OSuffixIdentifier.execute(OSuffixIdentifier.java:76)
	at com.orientechnologies.orient.core.sql.parser.OSuffixIdentifier.execute(OSuffixIdentifier.java:200)
	at com.orientechnologies.orient.core.sql.parser.OModifier.execute(OModifier.java:101)
	at com.orientechnologies.orient.core.sql.parser.OBaseExpression.execute(OBaseExpression.java:127)
	at com.orientechnologies.orient.core.sql.parser.OExpression.execute(OExpression.java:110)
	at com.orientechnologies.orient.core.sql.parser.OProjectionItem.execute(OProjectionItem.java:140)
	at com.orientechnologies.orient.core.sql.parser.OProjection.calculateSingle(OProjection.java:114)
	at com.orientechnologies.orient.core.sql.executor.ProjectionCalculationStep.calculateProjections(ProjectionCalculationStep.java:66)
	at com.orientechnologies.orient.core.sql.executor.ProjectionCalculationStep.access$000(ProjectionCalculationStep.java:13)
	at com.orientechnologies.orient.core.sql.executor.ProjectionCalculationStep$1.next(ProjectionCalculationStep.java:41)
	at com.orientechnologies.orient.core.sql.executor.OScriptExecutionPlan.doExecute(OScriptExecutionPlan.java:91)
	at com.orientechnologies.orient.core.sql.executor.OScriptExecutionPlan.fetchNext(OScriptExecutionPlan.java:49)
	at com.orientechnologies.orient.core.sql.parser.OLocalResultSet.fetchNext(OLocalResultSet.java:35)
	at com.orientechnologies.orient.core.sql.parser.OLocalResultSet.<init>(OLocalResultSet.java:29)
	at com.orientechnologies.orient.core.command.OSqlScriptExecutor.execute(OSqlScriptExecutor.java:55)
	at com.orientechnologies.orient.core.db.document.ODatabaseDocumentEmbedded.execute(ODatabaseDocumentEmbedded.java:587)
	at com.orientechnologies.orient.server.network.protocol.http.command.post.OServerCommandPostBatch.execute(OServerCommandPostBatch.java:203)
	at com.orientechnologies.orient.server.network.protocol.http.ONetworkProtocolHttpAbstract.service(ONetworkProtocolHttpAbstract.java:176)
	at com.orientechnologies.orient.server.network.protocol.http.ONetworkProtocolHttpAbstract.execute(ONetworkProtocolHttpAbstract.java:655)
	at com.orientechnologies.common.thread.OSoftThread.run(OSoftThread.java:69)

Hi @mmacfadden
Thank you for reporting, I'll check it asap and let you know
Thanks
Luigi

Hi @mmacfadden
I just pushed a fix, it will be released with v 3.0.9
Thanks
Luigi

Thanks for the great community support as always!


cmake: OpenAMP build doesn't work for multiple build directories

cmake -B build_h7m4 -DBOARD_CONFIG=nucleo-h745zi:nsh_cm4_rptun -GNinja
cmake -B build_h7m7 -DBOARD_CONFIG=nucleo-h745zi:nsh_cm7_rptun -GNinja
cmake --build build_h7m4
[...] build OK
cmake --build build_h7m7

/home/raiden00/git/RTOS/nuttx/nuttx/openamp/open-amp/lib/remoteproc/remoteproc.c:912:12: error: redefinition of 'remoteproc_virtio_notify_wait'
  912 | static int remoteproc_virtio_notify_wait(void *priv, uint32_t id)
      |            ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/home/raiden00/git/RTOS/nuttx/nuttx/openamp/open-amp/lib/remoteproc/remoteproc.c:902:12: note: previous definition of 'remoteproc_virtio_notify_wait' with type 'int(void *, uint32_t)' {aka 'int(void *, long unsigned int)'}
  902 | static int remoteproc_virtio_notify_wait(void *priv, uint32_t id)
      |            ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/home/raiden00/git/RTOS/nuttx/nuttx/openamp/open-amp/lib/remoteproc/remoteproc.c:902:12: warning: 'remoteproc_virtio_notify_wait' defined but not used [-Wunused-function]

In file included from /home/raiden00/git/RTOS/nuttx/nuttx/openamp/open-amp/lib/rpmsg/rpmsg_virtio.c:14:
/home/raiden00/git/RTOS/nuttx/nuttx/openamp/open-amp/lib/include/openamp/rpmsg_virtio.h:167:1: error: redefinition of 'rpmsg_virtio_notify_wait'
  167 | rpmsg_virtio_notify_wait(struct rpmsg_virtio_device *rvdev,
      | ^~~~~~~~~~~~~~~~~~~~~~~~
/home/raiden00/git/RTOS/nuttx/nuttx/openamp/open-amp/lib/include/openamp/rpmsg_virtio.h:158:1: note: previous definition of 'rpmsg_virtio_notify_wait' with type 'int(struct rpmsg_virtio_device *, struct virtqueue *)'
  158 | rpmsg_virtio_notify_wait(struct rpmsg_virtio_device *rvdev,

if we configure another build directory we result in not patched openamp:
cmake -B build_h7m4_2 -DBOARD_CONFIG=nucleo-h745zi:nsh_cm4_rptun -GNinja
cmake --build build_h7m4_2
[...] failure due to not patched OpenAMP

in that case it looks like openamp/open-amp is replaced with not patched version. openamp/.openamp_patch flag is present so fresh openamp source is not modified.

@anchao @xuxin930 Is there any reason why we don't use PATCH_COMMAND in FetchContent_Declare for patching?
It seems that this problem doesn't occur with command like this:
  FetchContent_Declare(
    open-amp
    DOWNLOAD_NAME "libopen-amp-v${OPENAMP_VERSION}.zip"
    DOWNLOAD_DIR ${CMAKE_CURRENT_LIST_DIR}
    URL "https://github.com/OpenAMP/open-amp/archive/v${OPENAMP_VERSION}.zip"
        SOURCE_DIR
        ${CMAKE_CURRENT_LIST_DIR}/open-amp
        BINARY_DIR
        ${CMAKE_BINARY_DIR}/openamp/open-amp
        PATCH_COMMAND
        patch -p0 -d ${CMAKE_CURRENT_LIST_DIR} <
        ${CMAKE_CURRENT_LIST_DIR}/0001-ns-acknowledge-the-received-creation-message.patch
        && patch -p0 -d ${CMAKE_CURRENT_LIST_DIR} <
        ${CMAKE_CURRENT_LIST_DIR}/0002-Negotiate-individual-buffer-size-dynamically.patch
        && patch -p0 -d ${CMAKE_CURRENT_LIST_DIR} <
        ${CMAKE_CURRENT_LIST_DIR}/0003-rpmsg-wait-endpoint-ready-in-rpmsg_send-and-rpmsg_se.patch
        && patch -p0 -d ${CMAKE_CURRENT_LIST_DIR} <
        ${CMAKE_CURRENT_LIST_DIR}/0004-openamp-add-new-ops-notify_wait-support.patch
        && patch -p0 -d ${CMAKE_CURRENT_LIST_DIR} <
        ${CMAKE_CURRENT_LIST_DIR}/0005-rpmsg_virtio-don-t-need-check-status-when-get_tx_pay.patch
        && patch -p0 -d ${CMAKE_CURRENT_LIST_DIR} <
        ${CMAKE_CURRENT_LIST_DIR}/0006-rpmsg-notify-the-user-when-the-remote-address-is-rec.patch
        && patch -p0 -d ${CMAKE_CURRENT_LIST_DIR} <
        ${CMAKE_CURRENT_LIST_DIR}/0007-openamp-avoid-double-calling-ns_bound-when-each-othe.patch
        && patch -p0 -d ${CMAKE_CURRENT_LIST_DIR} <
        ${CMAKE_CURRENT_LIST_DIR}/0008-remoteproc-make-all-elf_-functions-static-except-elf.patch
        && patch -p0 -d ${CMAKE_CURRENT_LIST_DIR} <
        ${CMAKE_CURRENT_LIST_DIR}/0009-Fix-warn-declaration-of-vring_rsc-shadows-a-previous.patch
        && patch -p0 -d ${CMAKE_CURRENT_LIST_DIR} <
        ${CMAKE_CURRENT_LIST_DIR}/0010-rptun-fix-rptun-don-t-wait-issue-when-get-tx-patyloa.patch
        && patch -p0 -d ${CMAKE_CURRENT_LIST_DIR} <
        ${CMAKE_CURRENT_LIST_DIR}/0011-rpmsg-fix-rpmsg_virtio_get_tx_buffer-no-idx-return.patch
        && patch -p0 -d ${CMAKE_CURRENT_LIST_DIR} <
        ${CMAKE_CURRENT_LIST_DIR}/0012-rpmsg-add-new-API-rpdev_release_tx-rx_buffer.patch
        && patch -p0 -d ${CMAKE_CURRENT_LIST_DIR} <
        ${CMAKE_CURRENT_LIST_DIR}/0013-openamp-add-error-log-when-ept-cb-return-error.patch
        && patch -p0 -d ${CMAKE_CURRENT_LIST_DIR} <
        ${CMAKE_CURRENT_LIST_DIR}/0014-rpmsg-add-cache-flash-when-hold-rx-buffer.patch
        && patch -p0 -d ${CMAKE_CURRENT_LIST_DIR} <
        ${CMAKE_CURRENT_LIST_DIR}/0015-rpmsg-do-cache_invalidate-when-real-data-returned.patch
        && patch -p0 -d ${CMAKE_CURRENT_LIST_DIR} <
        ${CMAKE_CURRENT_LIST_DIR}/0016-openamp-add-new-API-rpmsg_virtio_get_rxbuffer_size.patch
        && patch -p0 -d ${CMAKE_CURRENT_LIST_DIR} <
        ${CMAKE_CURRENT_LIST_DIR}/0017-virtio-follow-virtio-1.2-spec-add-more-virtio-status.patch
        && patch -p0 -d ${CMAKE_CURRENT_LIST_DIR} <
        ${CMAKE_CURRENT_LIST_DIR}/0018-virtio-decoupling-the-transport-layer-and-virtio-dev.patch
        && patch -p0 -d ${CMAKE_CURRENT_LIST_DIR} <
        ${CMAKE_CURRENT_LIST_DIR}/0019-virtio.h-add-version-in-device-id-table.patch
    DOWNLOAD_NO_PROGRESS true
    TIMEOUT 30)

@anchao @xuxin930 Is there any reason why we don't use PATCH_COMMAND in FetchContent_Declare for patching? It seems that this problem doesn't occur with command like this:
  FetchContent_Declare(
    open-amp
    DOWNLOAD_NAME "libopen-amp-v${OPENAMP_VERSION}.zip"
    DOWNLOAD_DIR ${CMAKE_CURRENT_LIST_DIR}
    URL "https://github.com/OpenAMP/open-amp/archive/v${OPENAMP_VERSION}.zip"
        SOURCE_DIR
        ${CMAKE_CURRENT_LIST_DIR}/open-amp
        BINARY_DIR
        ${CMAKE_BINARY_DIR}/openamp/open-amp
        PATCH_COMMAND
        patch -p0 -d ${CMAKE_CURRENT_LIST_DIR} <
        ${CMAKE_CURRENT_LIST_DIR}/0001-ns-acknowledge-the-received-creation-message.patch
        && patch -p0 -d ${CMAKE_CURRENT_LIST_DIR} <
        ${CMAKE_CURRENT_LIST_DIR}/0002-Negotiate-individual-buffer-size-dynamically.patch
        && patch -p0 -d ${CMAKE_CURRENT_LIST_DIR} <
        ${CMAKE_CURRENT_LIST_DIR}/0003-rpmsg-wait-endpoint-ready-in-rpmsg_send-and-rpmsg_se.patch
        && patch -p0 -d ${CMAKE_CURRENT_LIST_DIR} <
        ${CMAKE_CURRENT_LIST_DIR}/0004-openamp-add-new-ops-notify_wait-support.patch
        && patch -p0 -d ${CMAKE_CURRENT_LIST_DIR} <
        ${CMAKE_CURRENT_LIST_DIR}/0005-rpmsg_virtio-don-t-need-check-status-when-get_tx_pay.patch
        && patch -p0 -d ${CMAKE_CURRENT_LIST_DIR} <
        ${CMAKE_CURRENT_LIST_DIR}/0006-rpmsg-notify-the-user-when-the-remote-address-is-rec.patch
        && patch -p0 -d ${CMAKE_CURRENT_LIST_DIR} <
        ${CMAKE_CURRENT_LIST_DIR}/0007-openamp-avoid-double-calling-ns_bound-when-each-othe.patch
        && patch -p0 -d ${CMAKE_CURRENT_LIST_DIR} <
        ${CMAKE_CURRENT_LIST_DIR}/0008-remoteproc-make-all-elf_-functions-static-except-elf.patch
        && patch -p0 -d ${CMAKE_CURRENT_LIST_DIR} <
        ${CMAKE_CURRENT_LIST_DIR}/0009-Fix-warn-declaration-of-vring_rsc-shadows-a-previous.patch
        && patch -p0 -d ${CMAKE_CURRENT_LIST_DIR} <
        ${CMAKE_CURRENT_LIST_DIR}/0010-rptun-fix-rptun-don-t-wait-issue-when-get-tx-patyloa.patch
        && patch -p0 -d ${CMAKE_CURRENT_LIST_DIR} <
        ${CMAKE_CURRENT_LIST_DIR}/0011-rpmsg-fix-rpmsg_virtio_get_tx_buffer-no-idx-return.patch
        && patch -p0 -d ${CMAKE_CURRENT_LIST_DIR} <
        ${CMAKE_CURRENT_LIST_DIR}/0012-rpmsg-add-new-API-rpdev_release_tx-rx_buffer.patch
        && patch -p0 -d ${CMAKE_CURRENT_LIST_DIR} <
        ${CMAKE_CURRENT_LIST_DIR}/0013-openamp-add-error-log-when-ept-cb-return-error.patch
        && patch -p0 -d ${CMAKE_CURRENT_LIST_DIR} <
        ${CMAKE_CURRENT_LIST_DIR}/0014-rpmsg-add-cache-flash-when-hold-rx-buffer.patch
        && patch -p0 -d ${CMAKE_CURRENT_LIST_DIR} <
        ${CMAKE_CURRENT_LIST_DIR}/0015-rpmsg-do-cache_invalidate-when-real-data-returned.patch
        && patch -p0 -d ${CMAKE_CURRENT_LIST_DIR} <
        ${CMAKE_CURRENT_LIST_DIR}/0016-openamp-add-new-API-rpmsg_virtio_get_rxbuffer_size.patch
        && patch -p0 -d ${CMAKE_CURRENT_LIST_DIR} <
        ${CMAKE_CURRENT_LIST_DIR}/0017-virtio-follow-virtio-1.2-spec-add-more-virtio-status.patch
        && patch -p0 -d ${CMAKE_CURRENT_LIST_DIR} <
        ${CMAKE_CURRENT_LIST_DIR}/0018-virtio-decoupling-the-transport-layer-and-virtio-dev.patch
        && patch -p0 -d ${CMAKE_CURRENT_LIST_DIR} <
        ${CMAKE_CURRENT_LIST_DIR}/0019-virtio.h-add-version-in-device-id-table.patch
    DOWNLOAD_NO_PROGRESS true
    TIMEOUT 30)

hi @raiden00pl , I think now this problem is caused by two reasons:

duplicate download
the code is to check whether the .git in the open-amp directory exists, apparently this caused it to be downloaded and decompressed twice in two compilations.

wrong patch target location
I think the original intention of patch target is to mark that openAmp has been patched. This should only be executed once, but it is marked on the outer directory. this caused the patch to not be applied again during the second download.

I think we should deal with these two issues separately. for the second issue, I think using PATCH_COMMAND  is a better way. what do you think? @raiden00pl @anchao

@xuxin930

I think the root cause is download twice, we can just delete the condition of .git suffix

wrong patch target location

patch depends on the target "openamp_patch", the target should only executed once

PATCH_COMMAND is only available for ExternalProject right? FetchContent_Declare may be a better fit due to header file dependencies

@anchao According to https://cmake.org/cmake/help/latest/module/FetchContent.html#commands

The  can be any of the download, update or patch options that the ExternalProject_Add() command understands.

So PATCH_COMMAND is also available for ExternalProject

So PATCH_COMMAND is also available for ExternalProject

@raiden00pl
CMake FetchContent vs. ExternalProject
ExternalProject populates content from the other project at build time. This means the other project’s libraries are not visible until the parent project is built. Since ExternalProject does not combine the project namespaces, ExternalProject may be necessary if you don’t control the other projects.
Since too many modules depend on the header files of openamp, if the download of the content is delayed until the build time, it will cause many files to be incorrectly included, In nuttx, it seems like FetchContent_Declare will be better than ExternalProject

@anchao

So PATCH_COMMAND is also available for ExternalProject

typo. Should be:  So PATCH_COMMAND is also available for FetchContent.

All targets that use FetchContent_Declare need to make similar changes:

Delete the dir suffix of .git
Replace all patch targets with PATCH_COMMAND

@xuxin930 , could you please help enhance this feature if feel free ?

of course😁 @anchao @raiden00pl
besides these two changes, also need to delete PATCH_TARGET & PATCH_TARGET_DEP.
I will do it now, I'll complete both in nuttx and nuttx-apps, and link to this issue to track progress.

Solved by https://github.com/apache/nuttx/pull/10379 and https://github.com/apache/nuttx-apps/pull/1993
Thanks @xuxin930


Slow sub performance

This benchmark is given a result of sub 10K operations a second when immutable JS is hitting around 400K and vanilla JS 700K.
Is there any ideas why this might be the case ?
https://measurethat.net/Benchmarks/Show/11547/0/immer-setautofreezefalse-vs-shallow-vs-ramda-lens-vs-im
This was tested in the browser and whilst I understand the argument about synthetic benchmarks not being representative we are worried about this having an impact on our app if we switched since we have a lot of small updates like this (i.e keeping track of user intereactions)

You will get slightly better results if the data is pre-frozen (immer itself wil freeze output by default, so IRL that isn't needed).
Beyond that I think indeed these syntactic benchmarks are not super relevant indeed, I have yet to see the app where the time to update the state is a bottleneck. Usually the bottlenecks is in updating the UI, which is typically order of magnitude more expensive, and it is the structural sharing concept that helps with that regardless which library you pick (and also the reason the mutate example is useless as reference point, in practice that will be by far the slowest of the solutions in that list).
If you actually hit a perf bottleneck, do check https://immerjs.github.io/immer/docs/performance#performance-tips, or simple opt-out of using immer for certain super critical operations. You can perfectly mix and max immer with manual shallow copies or ramda at any point. (but not with ImmutableJS)