Inconsistent declarations of method with tightened types

Version/Platform: Dart 2.0.0-dev.65.0 / Windows x64
Given the following code...
abstract class MixinA {
  num method(num n) => null;
}

abstract class MixinB<T, S> {
  T method(covariant S n) => null;
}

abstract class ClassA extends Object with MixinA, MixinB<num, num> {} // works
abstract class ClassB extends Object with MixinA, MixinB<int, num> {} // works
abstract class ClassC extends Object with MixinA, MixinB<num, int> {} // works
abstract class ClassD extends Object with MixinA, MixinB<int, int> {} // doesn't work
// Inconsistent declarations of 'method' are inherited from (int) → int, (num) → num.

Only the last class declaration throws an error.  Is this the intended behavior?  I also wonder if the WIP proposal for interface conflict resolution is related to this.

I don't think there should be any error here.
The error comes from the analyzer, and not from the common front-end, so it's the analyzer being too restrictive.
The fourth case is overriding
  num method(num n) => null;

with
  int method(covariant int n) => null;

and that is a perfectly valid override - the return type is more specific, which is fine, and the parameter type is marked covariant, so it's also fine that it's more specific.

If I change the methods to throw, instead of return null, to get around null-safety, analyzer now reports no errors.

If I change the methods to throw, instead of return null, to get around null-safety, analyzer now reports no errors.


Hello i have a little problem

I launched the index locally but it displays its how I do it?

You closed the issue, got to solve it? Have you added your CoC developer API key?


Fixed updating of dynamic Overlay with tabs=True

Partial fix for https://github.com/ioam/holoviews/issues/2782 ensuring that an Overlay where tabs=True creates a new subplot for each tab and does not try to generate a legend. Full fix also requires https://github.com/ioam/holoviews/pull/2286.

Ready to merge?


add 3.7 releaser to releasers.conf

Had to add the 3.7 brew releaser so we can build against the 3.7 buildroot.

ACK


Check FromCollective of new Orders

When WWCode host adds money to a collective, it's by default coming from her personal Collective, rather than the Host Collective.

Make sure that Add Funds always come from Host account.

Check if this will be an issue for any other type of money coming in? Donations (like in FB's case). Do we have a UI to specify where you want the money to come from?

See order 5810 and 5813 for recent examples

fixed in new v2

This bug is still happening. I see another 22 orders that are from the wrong user (wwcode user c9814, instead of wwcode org c9804)

@clarete this might be relevant for the open collective payment method you are looking into. Please close otherwise.

Unfortunately, I don't think we'd be able to attend this request because LibreJS isn't really compatible with our use of Webpack. The whole frontend is compiled into a huge file that will always be categorized as "NONTRIVIAL" by LibreJS.
Nevertheless, I still think it could be great to track the licenses of the packages that we use. A veeeery quick analysis of our API dependencies shows that from our 1386 dependencies (including different versions of the same package if they exist). From that 1072 are MIT, there's a bunch of BSDs and some very few GPL so most of it is libre software but almost none is copyleft.
I'll create an issue to verify what is the * in some licenses and why we depend on any proprietary licenses (Even Stripe is MIT) so I think we might actually be close to 100% free software as well!
Here's the breakdown of what we currently have in the API:
{'(BSD-2-Clause OR MIT OR Apache-2.0)': 2,
 '(GPL-2.0 OR MIT)': 1,
 '(MIT AND CC-BY-3.0)': 1,
 '(MIT AND Zlib)': 1,
 '(WTFPL OR MIT)': 1,
 'Apache-2.0': 23,
 'BSD': 9,
 'BSD*': 25,
 'BSD-2-Clause': 26,
 'BSD-3-Clause': 62,
 'BSD-3-Clause OR MIT': 1,
 'Custom': 1,
 'Custom: http://graphql.org/': 2,
 'Custom: http://graphql.org/swapi-graphql': 1,
 'Custom: http://linuxcommand.org/man': 1,
 'Custom: https://flowtype.org/': 2,
 'Custom: https://github.com/dominictarr/event-stream': 1,
 'Custom: https://github.com/douglascrockford/JSON-js': 1,
 'Custom: https://github.com/graphql/graphql-language-service': 2,
 'GPL-3.0': 2,
 'ISC': 109,
 'LGPL': 1,
 'LicenseRef-LICENSE': 1,
 'MIT': 1072,
 'MIT*': 24,
 'Public Domain': 1,
 'UNKNOWN': 2,
 'UNLICENSED': 1,
 'Unlicense': 2,
 'WTFPL': 1,
 'license': 1,
 'proprietary': 1}

I'll close this issue and then I'll create another one to trace what proprietary software we're using and why!

I'm closing this one until we have another relevant event.


Add dependabot

Codecov Report

Merging #50 (0a81f6d) into main (9c507a6) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##             main      #50   +/-   ##
=======================================
  Coverage   82.73%   82.73%
=======================================
  Files          13       13
  Lines         643      643
=======================================
  Hits          532      532
  Misses         65       65
  Partials       46       46

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 9c507a6...0a81f6d. Read the comment docs.


refact CreateConfiguration

fix bug that can not get configuration from custom IFileConfigurationRepository
create configuration from IFileConfigurationRepository other than IOptionsMonitor<FileConfiguration>, if there are no file configuration, the file configuration will be empty.
register IOptionsMonitor<FileConfiguration> callback only when DiskFileConfigurationRepository used

@WeihanLi Both of your PRs are failing on the tests, can't merge, can you check it please?

I'll check it. Thanks @thiagoloureiro


Increase linter grade to 10.0

Currently, only the following lint errors exit:
$ pylint $(find src/ -name "*.py") --rcfile=./.github/workflows/pylintrc.conf
************* Module hopla.cli.config
src/hopla/cli/config.py:54:1: W0511: TODO: get_user this value from the HoplaDefaultConfiguration class instead of duplicating it here (fixme)
************* Module hopla.cli.get_user.auth
src/hopla/cli/get_user/auth.py:25:1: W0511: TODO: probably better to remove profilename here regardless (fixme)
************* Module hopla.hoplalib.configuration
src/hopla/hoplalib/configuration.py:108:5: W0511: TODO: this would be nicely testable (fixme)
************* Module hopla.hoplalib.authorization
src/hopla/hoplalib/authorization.py:165:13: W0511: TODO: handle this better: (fixme)

These are all relatively low prio (fixme) errors.
Proposed solution:

Instead of using the code as issue tracker, put these issues on github instead.
Bump the minimal linting score to 10.0
Change the Makefile to turn make test from && to ;  make lint ; make unittest

That way, locally, you can run tests while violating the linter for a few minutes.

https://github.com/melvio/hopla/issues/145

Decided against changing the Makefile.
Keeping code clean is a good idea, and you can always run make unitttest if you just want to run the tests.


eval and pickle are insecure and must NOT be used

@KOLANICH OK, I use eval just to parse the macros parameter, and use pickle to record some system config, I will use json.load instead.

Any progress?


Write a C program to convert binary to hexadecimal

Description
Write a C program to convert binary to hexadecimal
Binary is a base-2 number system. It uses only two digits: 0 and 1. The digits are called bits. A bit is the smallest unit of information in a computer. A bit can be either 0 or 1. A bit can be used to represent a single value, such as 0 or 1, or it can be used to represent a single state, such as on or off.
Hexadecimal is a base-16 number system. It uses sixteen digits: 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, A, B, C, D, E, and F. The digits are called hexits. A hexit is the smallest unit of information in a computer. A hexit can be used to represent a single value, such as 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, A, B, C, D, E, or F, or it can be used to represent a single state, such as on or off.
To convert a binary number to hexadecimal, we can use the following algorithm:

Convert the binary number to decimal.
Convert the decimal number to hexadecimal.

Input  : 1010
Output : A

How to contribute

Save the solution in ConvertBinaryToHexadecimal.c file
Add ConvertBinaryToHexadecimal.c file in convert-binary-to-hexadecimal folder

!assign


Following quickstart guide and I'm getting an error

I'm trying to build the site using hugo server --theme=hyde --buildDrafts and I get the following error:
ERROR: 2015/08/29 template: theme/partials/sidebar.html:4:23: executing "theme/partials/sidebar.html" at <.Site.BaseURL>: BaseURL is not a field of struct type *hugolib.SiteInfo in theme/partials/sidebar.html
ERROR: 2015/08/29 template: theme/partials/head.html:14:39: executing "theme/partials/head.html" at <.Site.BaseURL>: BaseURL is not a field of struct type *hugolib.SiteInfo in theme/partials/head.html
ERROR: 2015/08/29 template: theme/partials/sidebar.html:4:23: executing "theme/partials/sidebar.html" at <.Site.BaseURL>: BaseURL is not a field of struct type *hugolib.SiteInfo in theme/partials/sidebar.html
ERROR: 2015/08/29 template: theme/partials/head.html:14:39: executing "theme/partials/head.html" at <.Site.BaseURL>: BaseURL is not a field of struct type *hugolib.SiteInfo in theme/partials/head.html
ERROR: 2015/08/29 template: theme/partials/head.html:14:39: executing "theme/partials/head.html" at <.Site.BaseURL>: BaseURL is not a field of struct type *hugolib.SiteInfo in theme/partials/head.html
ERROR: 2015/08/29 template: theme/partials/sidebar.html:4:23: executing "theme/partials/sidebar.html" at <.Site.BaseURL>: BaseURL is not a field of struct type *hugolib.SiteInfo in theme/partials/sidebar.html
ERROR: 2015/08/29 template: theme/partials/sidebar.html:4:23: executing "theme/partials/sidebar.html" at <.Site.BaseURL>: BaseURL is not a field of struct type *hugolib.SiteInfo in theme/partials/sidebar.html
ERROR: 2015/08/29 template: theme/partials/head.html:14:39: executing "theme/partials/head.html" at <.Site.BaseURL>: BaseURL is not a field of struct type *hugolib.SiteInfo in theme/partials/head.html
ERROR: 2015/08/29 template: theme/partials/sidebar.html:4:23: executing "theme/partials/sidebar.html" at <.Site.BaseURL>: BaseURL is not a field of struct type *hugolib.SiteInfo in theme/partials/sidebar.html
ERROR: 2015/08/29 template: theme/partials/head.html:14:39: executing "theme/partials/head.html" at <.Site.BaseURL>: BaseURL is not a field of struct type *hugolib.SiteInfo in theme/partials/head.html
ERROR: 2015/08/29 template: theme/partials/sidebar.html:4:23: executing "theme/partials/sidebar.html" at <.Site.BaseURL>: BaseURL is not a field of struct type *hugolib.SiteInfo in theme/partials/sidebar.html
ERROR: 2015/08/29 Error while rendering 404 page: template: theme/404.html:8:123: executing "theme/404.html" at <.Site.BaseURL>: BaseURL is not a field of struct type *hugolib.SiteInfo```

Anyone know what this is? I have all the hugo themes in a themes folder inside my project. I installed hugo on OSX using ```brew install hugo```.

Hi @jamcar23,
Could you please run hugo version in the Terminal and see what version of Hugo you have?
And then perhaps also which hugo to see which hugo executable it is executing?
The Hugo themes, including hyde, has switched over to the new syntax, i.e. from .Site.BaseUrl (Hugo v0.13 and older) to .Site.BaseURL (Hugo v0.14 and up).
According to https://github.com/Homebrew/homebrew/blob/master/Library/Formula/hugo.rb, brew install hugo should install Hugo v0.14 for you.  Is there a chance that perhaps you have an older version of Hugo on your computer, and that was executed instead of the Homebrew version?

Ah. I'm running v0.13 and I just uninstalled and reinstalled using brew but I still get v0.13. I'll download the latest from the site.

Please update to Hugo 0.14.


Dependency graph for configuration items

This commit adds package "depgraph" under EVE/libs implementing a dependency graph.
It will be used in EVE to generically solve the problem of reconciliation between the actual/current
(configuration) state and the latest intended/desired state. Every time the desired state changes,
a certain sequence of Create, Modify and Delete operations has to be scheduled and executed
to update the current state. The order of operations often matters as it has to respect all dependencies
that exist between configuration items.
The plan is to first refactor NIM and use dependency graph for configuration items that device networks
are built with. Based on how NIM refactoring goes, depgraph could be used for zedrouter next.
For more detailed reasoning and motivation behind depgraph, please refer to the proposal presented
on the LF Edge wiki.
Signed-off-by: Milan Lenco<EMAIL_ADDRESS>

Moved to libs/, removed dependency on the pillar's logger and added an example (under libs/depgraph/examples) as suggested by @deitch (see communication on the eve-tsc mailing list).

This is really great. I'm super happy to see complexity and repetitive code pulled out of eve, simplifying it.
I've got some suggestions, will put these on here later. @milan-zededa has helpfully been explaining things to me.

Note that for the start I recommend to review the documentation (Readme file), the APIs (depgraph_api.go) and then maybe have a look the example (examples/filesync; can be easily built and played with: go build && ./filesync). No need to dive into the implementation (depgraph.go) or unit tests until we agree on the graph semantics and the interface.

Before jumping in with some structural recommendations, I need to point out how great this is. Anything that helps eve (and especially things in pillar) act more independently and without having to repeat code and patterns over and over is a good thing. For some reason, you decided to tackle one of the hardest things - state changes - first, so hats off.
Also, thank you (many times over) for writing up a solid README on this, including examples. Too many people miss that, and it makes it harder to grasp. This really really helps.
Naming
My biggest single comment is that, well, this is not a dependency graph, so naming it that confuses people. What you built is something much more powerful: a migration controller or state controller or reconciler or something like that whose input is two dependency graphs: current and target state (either of which might be empty).
As you described it to me offline, the process looks like this:

Create a new “reconciler”
Register a bunch of “handlers”
Create a named desired “state” and tell the "reconciler" the desired state
tell the reconciler to “go to that state"

The reconciler (depgraph here) then uses various handlers to make changes.

If an item existed in the old one but not in the new one, call Delete()
if an item exists in the new one but not in the old one, call Create()
etc

I would recommend naming it exactly what it does (taking your examples from the README and modifying them, leaving out some error handling):
log := MyLogger{}
r := reconciler.New(log)
err := r.RegisterConfigurator(LinuxInterfaceConfigurator{}, "linux-interface")
err := r.RegisterConfigurator(LinuxRouteConfigurator{}, "linux-route")

// THIS is a graph
myNetwork := reconciler.Graph{
     Name:        "My network",
     Description: "Network managed by an agent.",
     Items:       []reconciler.Item{
         LinuxBridge{name: "bd0", uplink: "eth0"},
         LinuxRoute{dst: "<IP_ADDRESS>/24", gw: "<IP_ADDRESS>"},
         LinuxInterface{name: "eth0"},   // Could be and external item
     },
 }
r.Cluster(myNetwork.Name).Put(myNetwork)
err := r.Sync(ctx)

If I give someone writing state machine code a library called "dependency graph", they probably will say, "what do I need one for, perhaps as a way to represent my dependencies, but who uses this one?".
If I give the same person a state reconciler, they say, "oh, exactly what I need! How do I represent the state and how do I tell it what to call to reconcile? Look, state is a DAG, I get that; handlers are registered, cool! Solved my problems!"
Exact same thing you did, but different names.
Handlers
I like what you did here. Register a handler, give it a key (the string) to enable the reconciler to link Items to the handler, it works. I also like that you call it Configurator. I thought I didn't like it, kept trying to come up with something better, and every time I analyzed it, came back to your name. :-)
The way you have built the handlers, as well, they can be generic or specific. So I can build a configurator that knows how to handle "all Linux bridges", and one that specifically knows how to handle "Linux bridge br3":
brc := LinuxBridgeConfigurator{}
brspecial := LinuxBridgeConfigurator{specialOption: "br3"}
err := r.RegisterConfigurator(brc, "linux-bridge")
err := r.RegisterConfigurator(brspecial, "linux-bridge-br3")
myNetwork := reconciler.Graph{
     Name:        "My network",
     Description: "Network managed by an agent.",
     Items:       []reconciler.Item{
         LinuxBridge{name: "bd0", uplink: "eth0"},
         LinuxBridge{name: "br3", uplink: "eth0"},
     },
 }

Dependencies in the Graph
The "graph" actually isn't a graph right now, it is an array:
myNetwork := reconciler.Graph{
     Name:        "My network",
     Description: "Network managed by an agent.",
     Items:       []reconciler.Item{
         LinuxBridge{name: "bd0", uplink: "eth0"},
         LinuxRoute{dst: "<IP_ADDRESS>/24", gw: "<IP_ADDRESS>"},
         LinuxInterface{name: "eth0"},   // Could be and external item
     },

Does the LinuxRoute there depend on the LinuxInterface? I do not know. It is possible, as you mentioned privately, that the handler (Configurator) knows that it should depend, but that eliminates our ability to have generic handlers. More importantly, it links too closely the description and the handler. The description is a graph. I agree that a handler should be able to know dependencies imperatively, not just in the graph declaratively, but the power of a complete graph is what you are building.
myNetwork := reconciler.Graph{
     Name:        "My network",
     Description: "Network managed by an agent.",
     Items:       []reconciler.Item{
         LinuxBridge{name: "bd0", uplink: "eth0"},
         LinuxRoute{dst: "<IP_ADDRESS>/24", gw: "<IP_ADDRESS>", dependencies: ...},
         LinuxInterface{name: "eth0"},
     },

There are different ways to represent graph semantics, e.g. such that LinuxRoute and LinuxInterface both are required independently, but also LinuxRoute depends upon LinuxInterface (i.e. Interface is not just a dependency of Route), and that Interface is a dependency of both Bridge and Route (and maybe Route depends on Bridge too).
If you want, I can track down some and put them in here.
Either way, you really want to be able to reflect your entire desired state and dependencies as, well, a graph.
Items to Configurators
Can you describe in the documentation, and with examples, how the reconciler knows which Configurator handles which Item?
err := r.RegisterConfigurator(LinuxInterfaceConfigurator{}, "linux-interface")
err := r.RegisterConfigurator(LinuxRouteConfigurator{}, "linux-route")
myNetwork := reconciler.Graph{
     Name:        "My network",
     Description: "Network managed by an agent.",
     Items:       []reconciler.Item{
         LinuxBridge{name: "bd0", uplink: "eth0"},
         LinuxRoute{dst: "<IP_ADDRESS>/24", gw: "<IP_ADDRESS>", dependencies: ...},
         LinuxInterface{name: "eth0"},
     },

There is nothing obvious here that links it. In Slack, you described that the Item interface has a func Type() that returns a string, that will be used by a configurator. If I understood your correctly (and it fits with the code and codedoc, let's put that in the README.
In the same vein, we should be consistent. If the way an Item says, "here is the way to find the Configurator to handle me" is via Name() (not explicit in the graph), then the way a Configurator identifies probably should be also.  I found it confusing, so I probably missed something.
What is wrong with?
log := MyLogger{}
r := reconciler.New(log)
err := r.RegisterConfigurator(LinuxInterfaceConfigurator{}, "linux-interface")
err := r.RegisterConfigurator(LinuxRouteConfigurator{}, "linux-route")

myNetwork := reconciler.Graph{
     Name:        "My network",
     Description: "Network managed by an agent.",
     Items:       []reconciler.Item{
         LinuxBridge{name: "bd0", uplink: "eth0"},
         LinuxRoute{dst: "<IP_ADDRESS>/24", gw: "<IP_ADDRESS>"},
         LinuxInterface{name: "eth0"},   // Could be and external item
     },
 }
r.Put(myNetwork)
err := r.Sync(ctx)

Is it that we want the reconciler to have a name and description? So why not give it to the reconciler, rather than the Graph or the Cluster? In your above examples, the Name: "My network" and Description: "Network managed by an agent.", really apply to the reconciler, don't they?
That having been said, I could see why each individual graph instances might want to have a name and a description, although eve is unlikely to use those.
Current and Target State
The way this is built, I Put() a state, Sync(); Put() another state, Sync(), etc. It implicitly must know the current state, and relies on it knowing it.
What happens if it lost the in-memory state, or it got messed up, or my code missed it? I could end up calling the wrong handlers with the wrong information.
Could we change Put() to From() and To(), thus explicitly saying, "I want to go from this state to this state, now go call my handlers"? Or maybe even a simpler Put(from, to Graph), where either can be nil? If you want to keep track of your current state, do it outside of the reconciler, whose job is reconciliation, not data management.
Conclusion
This was a very long comment, mainly because I really like what you are doing. I just have some suggestions around naming and interfaces.

Thanks @deitch for a detailed review. I will respond section-by-section:
Naming
Now that I think of it, it makes sense to call this component by what is does (state reconciliation), not by how it does it (i.e. by use of graph theory). So Reconciler is definitely a better name. Given how much renaming is needed, I will leave this for later, after we agree on the remaining suggestions. And maybe we will have even more naming ideas by then.
But going forward I will denote depgraph as Reconciler...
Handlers
I'm not sure if we will actually need the ability to have generic vs. specialized Configurators. At least within EVE I cannot think of a use-case right now. But we can certainly have this as a feature that might be helpful in the future.
But also note that it might make sense to think about this the other way. What if Items (the descriptions) should be generic and Configurators always specific? For example, a network route description is pretty much always a tuple (dst, gw, interface, metric) regardless of which network stack is being used. So the same description could be used by a "LinuxRouteConfigurator", "OVSRouteConfigurator", etc. But then how would the reconciler know which configurator to use for a particular route instance? So I don't know about this, probably nonsense, just mentioning a different angle on the problem.
Dependencies in the Graph
So firstly, it probably makes sense to move DependsOn from Configurator to Item interface. This is a simple change and it will allow to decouple Items from Configurators. Also, all the declarative descriptions (which DependsOn is part of) will be then solely inside the Item, while Configurator will encapsulate only the imperative methods Create/Delete... So I like this suggestion and will apply it.
Note that while Item.Type() string should return a name for the item type (like reflect.TypeOf(item), but maybe more human-readable), Item.Name() string should return a unique identifier for an item instance. For example, Type() could return "network interface" and Name() could return "eth0".
But don't think of Type() as a method for telling the reconciler which Configurator to use. That would be another instance of Items being closely coupled with Configurators. We can support different ways of mapping Configurators to Items, but this should be done through the Reconciler API, not by having Configurators or Items telling the reconciler to what they should be mapped.
So currently the Reconciler allows to map Configurators by Item types:
RegisterConfigurator(configurator Configurator, itemType string) error

Maybe it could be called instead:
RegisterConfiguratorByItemType(configurator Configurator, itemType string) error

And then have also a (higher-priority) override for a specialized configurator:
RegisterConfiguratorByItemName(configurator Configurator, itemName string) error

Next to this point:

The "graph" actually isn't a graph right now, it is an array.

So in my current implementation, the input to the Reconciler is a set of items, not graph.
This is because, in essence, what you as a user are telling the Reconciler is that you want to have this set of items currently configured (and nothing else). These items may have some dependencies and that determines what ordering of operations is valid, but the fact the Reconciler is based on graph theory and uses DAG as a data structure is a matter of implementation.
And as for clusters - again, a cluster is not a graph per se. It is a grouping of related items (a subset of items if we are talking about the state of the system as a whole). For example (from EVE), all configuration items created for a specific application can be grouped under a cluster. This is useful mostly for when you are building the intended state. Clusters do not affect the reconciliation algorithm. Typically, when the intended state changes, it does not change completely, only some part of it. Another example from EVE: when user un-deploys an application, you do not want to re-render the whole intended state (inefficient), but rather tell the Reconciler to remove the cluster of items that represent the application. Or when the application definition changes, you only need to re-render and replace the content of that one cluster.
Note that most dependencies will be within clusters, but some dependencies will go across clusters. For example: an application network bridge depends on a device port. While the bridge is application specific (and will go away when application is un-deployed), the device port is a "shared" item, always present in the intended state (so it will not be inside the application's cluster).
Items to Configurators
Already mentioned above. I will improve the documentation to make this topic more clear (once we fully agree on the interface).
Clusters
Already mentioned above. If it is still confusing, I can draw some example of how it will be used in EVE.
(I already have a sketch of clusters that will be used for nim & zedrouter, but it is only on a paper).
As pointed out above, the main purpose of clusters is to simplify and make more efficient the process of building/updating the intended state. Descriptions are only a bonus. If you visualize the current/intended state (using RenderDot() + graphviz), descriptions allow you to better understand the state and the purpose of items inside it.
Current and Target state
I think it might make sense to add From() as a way of updating/replacing the view of the actual state. For EVE this could be useful when the device is malfunctioning and so the view of the actual state can be wrong. But the scenarios of this in-memory state representation getting corrupted or out-of-date will be probably rather rare, therefore I would add From() next to Put() and Del().
In theory, your proposal (replace Put/Del with From) is more robust. However, in practice it will be probably very inefficient to use. As I mentioned, usually only a small portion of the intended state changes, so rebuilding it as a whole will be unnecessarily costly. Therefore it makes sense to cache the last applied state. This cache could be separated from the Reconciler and I will think about how this could be done. The challenge is to not make this tightly-coupled with the Reconciler (because then it doesn't make sense to separate it), but at the same time design the cache API such that the reconciliation algorithm can remain being effective. If it will need to get the cache content and convert it to some internal data structure, then it will be very inefficient. So the cache should definitely be already a DAG with appropriate getters.
But also note that I plan to add support for asynchronous operations, which will make the Reconciler even more powerful and useful tool at disposal. When added, Sync() might return even if some operations are still ongoing. This might complicate the Reconciler <-> state cache separation, but I haven't though about it in a great detail yet.
In any case, I think it will be useful to have a representation of the intended state stored/cached in-memory for EVE (with cache being implemented in one place as a lib for all microservices). Currently, you cannot log into a device and ask EVE about what is supposed to be configured (I mean the low-level OS configuration, not config from the controller) and why (the cluster descriptions are partly the "why-s"). And I think this information would be useful for troubleshooting purposes.
Let me know If I missed any of your questions...

probably makes sense to move DependsOn from Configurator to Item interface

Yes, that would make the dependencies visible so one can actually see the tree in the []Item.
But as you do that, would the list in []Item matter? Or the Reconciler will build a tree based on DependsOn?

Now that I think of it, it makes sense to call this component by what is does (state reconciliation), not by how it does it (i.e. by use of graph theory). So Reconciler is definitely a better name

Sounds good.
Hmm, if Reconciler has an API with Put(from, to State), should the call to migrate from from to to be Sync()? Or maybe just, Reconcile()?

I'm not sure if we will actually need the ability to have generic vs. specialized Configurators. At least within EVE I cannot think of a use-case right now. But we can certainly have this as a feature that might be helpful in the future.

Then the middle road is: don't bother with it now, but don't block it for the future. Keep the current RegisterConfigurator that uses the Type() output, and you always can add a Name-based one later.

For example, a network route description is pretty much always a tuple (dst, gw, interface, metric) regardless of which network stack is being used. So the same description could be used by a "LinuxRouteConfigurator", "OVSRouteConfigurator", etc. But then how would the reconciler know which configurator to use for a particular route instance? So I don't know about this, probably nonsense, just mentioning a different angle on the problem.

Actually, this is kind of interesting. I don't know that we need to solve it now, but what you are saying is that rather than having an item say, "I should be handled by this configurator", it says, "I can be solved by any configurator that implements X, and when you run me, you determine which one." That would send the responsibility to the registration phase.
My instinct here is that you are onto something really useful - items that should be handle by specific configurators, items that can be handled by any configurator that implements an interface - but that it should wait for a future iteration.

Maybe it could be called instead:
RegisterConfiguratorByItemType(configurator Configurator, itemType string) error
And then have also a (higher-priority) override for a specialized configurator:
RegisterConfiguratorByItemName(configurator Configurator, itemName string) error

The idea of item type makes sense; the idea of item name, though, is challenging. How would the network stack, e.g. have any clue what is coming down in a configuration and what should be called? Isn't the whole purpose of this to receive configuration and apply it? If my code knows, "I handle eth0 this way", then I weaken the benefits of configuration-driven management.
I think I would start simple, with RegisterConfigurator() as you have it. We always can add ByType or ByName in the future, if/when we need it, without breaking what exists.

But don't think of Type() as a method for telling the reconciler which Configurator to use. That would be another instance of Items being closely coupled with Configurators. We can support different ways of mapping Configurators to Items, but this should be done through the Reconciler API, not by having Configurators or Items telling the reconciler to what they should be mapped.

Something is going to call that API - the calling module, e.g. NIM, and going to tell it how to map things. There will be some string (like the Item.Type()), or interface, or something. We should not require the caller to know what the contents of the config are. Only the what it can handle and how to handle it.
In any case, I would stick with Type-mapping for now. With some experience running this, I suspect the new use cases and optimal ways to use them will open up.

So in my current implementation, the input to the Reconciler is a set of items, not graph.
This is because, in essence, what you as a user are telling the Reconciler is that you want to have this set of items currently configured (and nothing else).

Arguably, as set of Items is a graph, just a really simple one. Nothing prevents you from saying, "right now, we start with a the simplest graph, which is a list of items, and therefore no dependencies or ordering, and in the future we will support dependencies".

These items may have some dependencies and that determines what ordering of operations is valid, but the fact the Reconciler is based on graph theory and uses DAG as a data structure is a matter of implementation

This is semantic debate, but I think the fact that it uses a DAG as an input - items with their dependencies (ok, as a true graph, a single invisible root with an array of sub-nodes, each of which may or may not have more dependencies, but that is nitpicking details) - means that the API actually is a graph. But either way, it doesn't change what you are doing.

a cluster is not a graph per se. It is a grouping of related items (a subset of items if we are talking about the state of the system as a whole). For example (from EVE), all configuration items created for a specific application can be grouped under a cluster.

Any subgraph of a graph is, by definition, a graph (albeit a smaller one). However, from Reconciler's perspective, it doesn't care. It can get a graph of everything, or just a graph of a small subset, or even just one item. It receives current and target state, has configurators, is told Sync(), and it goes.

Another example from EVE: when user un-deploys an application, you do not want to re-render the whole intended state (inefficient), but rather tell the Reconciler to remove the cluster of items that represent the application.

I still see this as just a subgraph, which means Reconciler has no idea. It just gets current and future state and configurators and runs.
You could take this one step further, and have a single graph for the entire state of the entire eve, and have the Reconciler run through the whole graph and figure out which subgraphs are changed, and then call configurators just for those (or create temporary new reconcilers for each minimal changed subgraph and register configurators from its own sets and call Sync()).

Descriptions are only a bonus. If you visualize the current/intended state (using RenderDot() + graphviz), descriptions allow you to better understand the state and the purpose of items inside it.

Indeed. When you put that in the README, I instantly saw the value of them. Nicely done.

I think it might make sense to add From() as a way of updating/replacing the view of the actual state. For EVE this could be useful when the device is malfunctioning and so the view of the actual state can be wrong. But the scenarios of this in-memory state representation getting corrupted or out-of-date will be probably rather rare, therefore I would add From() next to Put() and Del().

I get what you are saying. I think that the current state should be stored in the caller, and not in the Reconciler. The reconciler should be narrowly focused on "give me the current state and target state, tell me to reconcile, and watch me go. When I am done, you can throw me away. If you want a new reconciliation, create a new Reconciler and do the same thing again." We could keep a single object around, for efficiency, but no memory caching.

In theory, your proposal (replace Put/Del with From) is more robust. However, in practice it will be probably very inefficient to use. As I mentioned, usually only a small portion of the intended state changes, so rebuilding it as a whole will be unnecessarily costly. Therefore it makes sense to cache the last applied state.

I think I just understood what you are saying. I think you are saying not that the reconciliation will be expensive, but that the absorption will be expensive. i.e. when I give a Reconciler a current state or a future state, it needs to do something with that to make it useful, before it runs reconciliation?
I am somewhat skeptical that will be the case, especially if we use the objects as-is. Once we convert it to something (what is that something?), it will be about the same.
In any case, let's see what that func is, see if it really gets expensive or saves us anything. This may turn out to be a case of premature optimization, or it might not.

But also note that I plan to add support for asynchronous operations,

Oh, nice. I really like this, and it fits with the whole eve philosophy (awful pseudo-code).
r, err := reconciler.New
r.Put(from, to)
c := make(chan error, 1)
err := r.Reconcile(c)

When it is done, it sent the error, or nil, down the channel.

In any case, I think it will be useful to have a representation of the intended state stored/cached in-memory for EVE (with cache being implemented in one place as a lib for all microservices)

I agree. I don't think Reconciler is the place for it; I think that configmanager is.

Currently, you cannot log into a device and ask EVE about what is supposed to be configured (I mean the low-level OS configuration, not config from the controller)

How do you separate the two? Isn't the entire config driven by the controller?

I agree. I don't think Reconciler is the place for it; I think that configmanager is
@deitch Where can I find "configmanager"? (or is that just a name that such a component should have?)

@milan-zededa sorry that was not an actual component. I blanked at the time on which part of eve-os received the config and processed it, cached it, etc. That happens in zedagent if I recall correctly (which really should get a new name).

@deitch
Until I re-design reconciler and make it stateless, could we first agree and approve the interfaces for Configurators and configured items? It will allow me to go ahead with the NIM refactoring and start preparing implementations for objects managed by NIM.
The interfaces are here:
https://github.com/milan-zededa/eve/blob/dependency-graph/libs/depgraph/depgraph_api.go#L143-L181
https://github.com/milan-zededa/eve/blob/dependency-graph/libs/depgraph/depgraph_api.go#L355-L369
One thing I'm considering to change is to rename Item to StatefulObj. The reason is that item represents a stateful object (that can be created, modified and deleted; like interface, route, volume, etc.) and the typename "Item" is rather vague.

could we first agree and approve the interfaces for Configurators and configured items?

In principle, it looks pretty good. I have some questions:

can you rename the package to reconciler (or whatever we decide on) from the beginning? Also the name of the thing Reconciler or whatever? I think it will make life easier to change some implementations rather than the entire naming convention
How do dependencies work? If I have 5 objects, and number 2 depends on 3 & 4 and number 4 depends on 5, what does it look like?

One thing I'm considering to change is to rename Item to StatefulObj. The reason is that item represents a stateful object (that can be created, modified and deleted; like interface, route, volume, etc.) and the typename "Item" is rather vague.

I would counsel against that. Besides the ugliness of the name, it represents what it is under the covers. I don't think people think about "stateful" vs "stateless" or anything like that. Consumers just look at it and say, "oh, ok, I need to build a graph representation of my configuration items". I think your first instinct of Item was simple and very correct.

can you rename the package to reconciler (or whatever we decide on) from the beginning?

OK

How do dependencies work? If I have 5 objects, and number 2 depends on 3 & 4 and number 4 depends on 5, what does it look like?

Say you have objects Item1, Item2, ... Item5, with names "1", "2", ..., respectively (as returned by Item.Name()).
Then Item.Dependencies would be implemented as follows:
func (item Item1) Dependencies() []depgraph.Dependency {
	return []depgraph.Dependency{}
}

func (item Item2) Dependencies() []depgraph.Dependency {
	return []depgraph.Dependency{}
		&depgraph.ItemIsCreated{
			ItemName:   "3",
			Description: "Describe why it depends on 3...",
		},
		&depgraph.ItemIsCreated{
			ItemName:   "4",
			Description: "Describe why it depends on 4...",
		},
	}
}

func (item Item3) Dependencies() []depgraph.Dependency {
	return []depgraph.Dependency{}
}

func (item Item4) Dependencies() []depgraph.Dependency {
		return []depgraph.Dependency{}
		&depgraph.ItemIsCreated{
			ItemName:   "5",
			Description: "Describe why it depends on 5...",
		},
	}
}

func (item Item5) Dependencies() []depgraph.Dependency {
	return []depgraph.Dependency{}
}

@deitch
One more thing: Do you prefer Cluster or SubGraph? SubGraph is self-explanatory, but cluster is probably somewhat nicer name.

I think I get it. You are saying that the graph entry point looks like this:
myNetwork := reconciler.Graph{
     Name:        "My network",
     Description: "Network managed by an agent.",
     Items:       []reconciler.Item{
         LinuxBridge{"bd0", uplink: "eth0"},
         LinuxRoute{...},
         LinuxInterface{name: "eth1", ...},
     },
 }

And I know that LinuxBridge (item 0) depends on LinuxInterace (item 2) because I:

LinuxBridge.Dependencies() - returns one dependency, called reconciler.ItemIsCreated
ItemIsCreated has a Name: "eth1"
LinuxInterface.Name() returns "eth1"

Is that correct? If so, a few questions:

Really important to describe that in the docs. (ok, not a question :-) )
There are a few places in the documentation where it talks about Configurator.DependsOn and such. Just some cleanup needed.
It would be nice if that all could be captured in the declarative config. I am not quite sure how off the top of my head. I will think it through, but unless you have a straightforward way - perhaps @eriknordmark has some suggestions - don't hold up for that.
The above precludes two distinct items of a different kind having the same name, as it would have no way to distinguish between them. Does that matter? Should we make a dependency depend upon type and name? I.e. each Item has a unique identifier which is a combination of type and name? Or is name that already, and I am overthinking it? Or does it already have that?

I am a little torn on ItemIsCreated. It is a bit heavy of a name, and will we ever have anything other than Created? In any case, should it not be Exists? In which case, maybe the dependency should just be Exists rather than ItemExists or ItemIsCreated?
I think the easiest path for the above is to have a dependency just be a struct, rather than an interface, where it has a Condition, which for now is just Exists. In the future, if you ever have other cases, you can expand the options for Condition.

One more thing: Do you prefer Cluster or SubGraph? SubGraph is self-explanatory, but cluster is probably somewhat nicer name.

Heh, I still don't fully get what it is used for. I get the simple API:
r := reconciler.New()
r.Put(from, to)
r.Reconcile()

from and to can be the entire graph of config, the tiniest single item subset, or everything in between.
So what does Cluster do? Is it just a way to say, "we are working with some in between chunk"? In which case, does it matter to reconciler at all? Maybe it is just the client handling it?

So what does Cluster do? Is it just a way to say, "we are working with some in between chunk"? In which case, does it matter to reconciler at all? Maybe it is just the client handling it?

Yes, exactly - the notion of cluster/sub-graph is only for the client to be able to select a "chunk" of the graph and run reconciliation over it. For reconciler a cluster/sub-graph is just a graph (will implement the same graph API), so it has no effect on the reconciliation algorithm

So should it be part of a reconciler at all? A reconciler is just a one-way machine that takes current and target states and runs actions that go from current to target.
If you want to store sub-chunk-cluster-graphs (haha! I just merged all of them!) then that is out of scope of the Reconciler.
Now, if you wanted to have a convenient place to store subchunks, that very well might fit with the graph part. To wit, if I can pass the following to a Reconciler:
target := reconciler.Graph{
     Name:        "My network",
     Description: "Network managed by an agent.",
     Items:       []reconciler.Item{
         LinuxBridge{"bd0", uplink: "eth0"},
         LinuxRoute{...},
         LinuxInterface{name: "eth1", ...},
     },
 }

Then arguably I should be able to extract any Item and it, too, should be a valid thing to pass:
target := reconciler.Graph{
     Name:        "My network",
     Description: "Network managed by an agent.",
     Items:       []reconciler.Item{
         LinuxBridge{"bd0", uplink: "eth0"},
         LinuxRoute{...},
         LinuxInterface{name: "eth1", ...},
     },
 }
r.Put(nil, target).Reconcile()
sub := target.Items[2]
r.Put(nil, sub).Reconcile()

Is that doable? If each item inside a Graph implements the Graph interface (which actually is a struct now), then it becomes really simple: any part of a Graph also is a Graph.

Really important to describe that in the docs. (ok, not a question :-) )

OK, will do.

There are a few places in the documentation where it talks about Configurator.DependsOn and such. Just some cleanup needed.

Yes, just need to clean this up.

It would be nice if that all could be captured in the declarative config. I am not quite sure how off the top of my head. I will think it through, but unless you have a straightforward way - perhaps @eriknordmark has some suggestions - don't hold up for that.

Given that dependencies of an item are determined by the content/description of the item, I would prefer to have it in the Item's interface. (e.g. LinuxRoute{uplink: "eth0"} will depend on eth0 as determined by the value of uplink attribute)

The above precludes two distinct items of a different kind having the same name, as it would have no way to distinguish between them. Does that matter? Should we make a dependency depend upon type and name? I.e. each Item has a unique identifier which is a combination of type and name? Or is name that already, and I am overthinking it? Or does it already have that?

Item name should be a unique identifier among all the items (of any graph that the item is part of).
This is documented inside the comment for Item.Name().

I am a little torn on ItemIsCreated. It is a bit heavy of a name, and will we ever have anything other than Created? In any case, should it not be Exists? In which case, maybe the dependency should just be Exists rather than ItemExists or ItemIsCreated?

I'm OK with Exist also. But note that item may be requested to be created, but due to unsatisfied dependencies it will be marked in the graph as Pending. In this case does the item exist? It exists in the config, but is not actually created. "Created" is maybe just a little bit more clear than "Exists" IMHO.
Not sure if we will need dependencies with different semantics in the future. Just wanted to keep it extensible.

I think the easiest path for the above is to have a dependency just be a struct, rather than an interface, where it has a Condition, which for now is just Exists. In the future, if you ever have other cases, you can expand the options for Condition.

OK, will change this

Given that dependencies of an item are determined by the content/description of the item, I would prefer to have it in the Item's interface. (e.g. LinuxRoute{uplink: "eth0"} will depend on eth0 as determined by the value of uplink attribute)

Meaning that LinuxRoute might return the value of uplink, while LinuxInterface might return the value of description, LinuxFoo might do some runtime calculation, etc.? Each item struct might choose to determine how it identifies itself uniquely via some other property?
That does make sense, but it makes me wonder if Name() is the right way to do it. Perhaps Key() or ID() is better?

Item name should be a unique identifier among all the items (of any graph that the item is part of).
This is documented inside the comment for Item.Name().
But yes, we could relax this requirement for Name() and say that it should be unique only among the instances of the same item type. Then the combination of type+name would be used as the identifier/reference. I will think about it...

I can see this going either way. As long as we are explicit, making Name() be unique probably is fine.
The one advantage to type+name is that it acts as a typing system. It reduces (but does not eliminate) the chance that we accidentally create a Graph where LinuxRoute depends on WiFiConfig instead of Interface, when both have the names eth0.
This is only a minor advantage.

Not sure if we will need dependencies with different semantics in the future. Just wanted to keep it extensible.

Yup.

That does make sense, but it makes me wonder if Name() is the right way to do it. Perhaps Key() or ID() is better?

Is the suggestion to rename Name() to ID()/Key(), or are you suggesting a bigger change that I missed?
Note that to reference uplink interface for route := LinuxRoute{uplink: eth0}, one could do LinuxInterface{name: route.uplink}.Name().

Firstly, I should mention that based on your feedback I'm splitting the dependency graph from the Reconciler. There will be two packages under libs:

Smooth.

The Clusters/Sub-graphs will be only a notion inside depgraph

Nice.

And yes, I plan to allow to select a single node and have it present itself as a (sub)graph.

Very nice. Should make the interface mighty easy for consumers.

Is the suggestion to rename Name() to ID()/Key(), or are you suggesting a bigger change that I missed?

No suggestion. I was just wondering if Name is the right way to describe "this is the unique ID for this thing in an entire graph", or if it would be better either called ID or Key, or if it were Name is the right way to describe "this is the unique ID for things of this type in an entire graph"
I think, in the end, any of the above will be fine.

I think, in the end, any of the above will be fine.

But probably makes sense to go with either Type+Name as ID, or rename Name to Key/ID.
I'm starting to like Type+Name, especially to decrease the chance of collisions as you pointed out.

But probably makes sense to go with either Type+Name as ID, or rename Name to Key/ID. I'm starting to like Type+Name, especially to decrease the chance of collisions as you pointed out.

The objects we have in nim and some in zedrouter use name strings like "eth0", but the higher-level objects like an AppNetworkConfig has a UUID. So I think type+id makes more sense than type+name for the general case.
I don't know if you've seen pubsub.TypeToName() which determines a string type name from an interface. Might be useful for the type part.

@deitch @eriknordmark
I have refactored my original PR to reflect all the suggestions and feedback from the review. Although I still need to add more unit tests, the rest is ready for review.
The changes I made since your last review can be summarized as:

Dependency graph (depgraph) and reconciler are now two separate packages (under libs, not tied to anything from eve). The graph is just a data structure to store the current and the intended state (as two separate instances of the graph). The reconciler is stateless and implements state reconciliation with two graphs as input.
The mapping between items and configurators is now completely customizable by use of a ConfiguratorRegistry interface. But the default implementation of the registry, which will be probably used in most cases, maps configurators to items by item types.
Added support for asynchronous operations. This made the implementation of the reconciler slightly more complicated, but not as much as I expected/feared.

I invite you to re-read Readmes (depgraph, reconciler) and the APIs (depgraph - boring(!), reconciler). Please let me know if you encounter anything that is not clear in the documentation.

@deitch @eriknordmark
I have added a whole bunch of unit tests to cover all kinds of scenarios. In terms of code coverage, depgraph package has 87.1%, reconciler 85.7%. With that, the PR is complete. Most of the suggestions from the review were reflected in one way or another. Still some changes could be done in the future as we start using these packages and gain experience.
As a next step I would like to actually use this, starting with the NIM microservice. Given how much time I've spent on this, I really hope that it will be have a noticeably positive effect on our code quality, readability, extensibility, etc. But that would come in next PRs.
Anyway, this PR is ready for merge and at this point it should be completely harmless because there are no changes, just new code which is not yet imported by eve/pillar from anywhere.

@eriknordmark I've added control-flow examples into the readme which should help you (and others) better understand how async operations and external items are handled: https://github.com/milan-zededa/eve/tree/dependency-graph/libs/reconciler#control-flow-examples
Still, if you want we can have a call and I can explain in more detail.


Added support for ARM architecture and some chat bot updates

Added support for ARM architecture when performing docker builds due to missing gcc libs.
Chatbot form updates

Added support for pressing enter to submit request
Made the input field required
Added the endpoint name to the output to show where the results originated from

@martinpeck I've backed out the form changes and will PR that change separately without the endpoint output.

Thanks for splitting into 2 PRs @mluker ! 👍

Thanks @mluker!
Can you add some context around building for ARM? E.g. are you on a machine with an ARM chip and wanting to build and run the container image locally? Or are you targetting deployment to another environment with ARM chips?

Or are you running locally on an ARM chip and trying to deploy to ACA? I just checked and realised that we don't currently specify the target platform when building the image to deploy to ACA!

Ok, cool.
I've added #36 to track the image build for ACA deployment.
I've kicked off the validation build again and raised #33 to track resolving the failing test


Howto multiple platforms/accessories?

Hi all,
I am somehow stuck here.
I have homebridge Running with Fibaro Plugin, an also installed Hue Platform and Sonos Accessorie.
However, if i setup Both (Fibaro and Hue) in config json, either Fibaro Or hue is working (the Last in the Config) .
Same with sonos, more than one speaker will nötig work.
I think there is some error/misunderstanding in the config file, so could someone post a Sample file With more than one platform?
Cheers
Joystick

Recently I had the same challenge. I'm new to this all and I had some problem with this { } [ ], things. ;)
Maybe this config.json helps.
config.json.txt

I have the same issue. Is there any documentation on how to append multiple platforms &/or accessories @nfarina? thanks!

@joystick666 Sounds like you may be writing the platforms: [...] block multiple times. Take a look at @DJay1's link, that looks more correct to me.

I had the same problem @joystick666. I was missing a , between the platform and accessory definition. post your json and I'll take a look. remove your creds before posting.


reflect: roll back NumMethod change for interfaces

The NumMethod change for interfaces (#22075) broke code in the standard library that assumed for interfaces that NumMethod() == 0 if and only if it is an empty interface. There is also a lot of code testing NumMethod() against 0 in the wild. See attached nummethod.txt. There are dups in that file but still, there's a bunch.
All that code will break with the change. We should probably roll it back and live with the difference between NumMethod on interfaces and NumMethod on non-interfaces.
nummethod.txt

See also https://github.com/golang/go/issues/41882

If we decide not to change NumMethod, should we change the doc to make it match the code? (It currently says "NumMethod returns the number of exported methods in the type's method set.")

Yes, we should correct the docs.


DNM: Liveness Test Debug + Fix

For contributor use:

[ ] Targeted PR against correct branch (see CONTRIBUTING.md)
[ ] Updated relevant documentation (docs/) or specification (x/<module>/spec/)
[ ] Added a relevant changelog entry to the Unreleased section in CHANGELOG.md
[ ] Re-reviewed Files changed in the Github PR explorer

Codecov Report

Merging #1157 (a6130f7) into main (d143d83) will decrease coverage by 0.23%.
The diff coverage is 8.94%.

@@            Coverage Diff             @@
##             main    #1157      +/-   ##
==========================================
- Coverage   20.21%   19.98%   -0.24%
==========================================
  Files         199      199
  Lines       25062    25397     +335
==========================================
+ Hits         5066     5075       +9
- Misses      19069    19394     +325
- Partials      927      928       +1

Impacted Files
Coverage Δ

osmomath/math.go
64.44% <ø> (ø)

store/node.go
66.94% <ø> (ø)

v043_temp/address/hash.go
80.00% <ø> (ø)

x/claim/abci.go
0.00% <ø> (ø)

x/claim/client/cli/query.go
34.45% <ø> (ø)

x/claim/client/cli/tx.go
0.00% <ø> (ø)

x/claim/handler.go
0.00% <ø> (ø)

x/claim/keeper/claim.go
64.33% <ø> (ø)

x/claim/keeper/grpc_query.go
0.00% <ø> (ø)

x/claim/keeper/hooks.go
28.00% <ø> (ø)

... and 122 more

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update a508900...a6130f7. Read the comment docs.


Command line arguments in docker entrypoint

Currently, the entrypoint script (docker/fiat-lux.sh) only takes one argument -- the positional argument specifying the number of accounts to create.
Ideally, it should allow various configuration options from the command line in excess of this. For example:

Which APIs geth should expose over HTTP

How much balance the accounts start with

Perhaps the best way to achieve this is to add a simple command line argument parser to the entrypoint script.

Going to make a very simple change here (as opposed to using a command line argument parser in fiat-lux.sh):

NUM_ACCOUNTS, which is currently being taken as the first argument to fiat-lux.sh will now be taken from the environment. So the current initialization NUM_ACCOUNTS=${1:-11} will look like NUM_ACCOUNTS=${NUM_ACCOUNTS:-11} after the change.

The command line arguments to fiat-lux.sh will be dumbly passed through to geth:

geth ... $@


Message not scrolling

Please search to check for an existing issue (including closed issues, for which the fix may not have yet been released) before opening a new issue: https://github.com/k9mail/k-9/issues?q=is%3Aissue
Expected behavior
I try to open a long email message and I try to scroll down to the bottom of it, to read the whole message. This is happening on a non-touch device Sonim XP3800 with a small screen.
Actual behavior
I am not able to scroll only to the beginning of the message.
Steps to reproduce

Open a mail message on a non-touch device with small screen.

Environment
K-9 Mail version:
5.719
Android version:
8.1.0
Account type (IMAP, POP3, WebDAV/Exchange):
Please take some time to retrieve logs and attach them here:
Phone:
Sonim XP3800

We'd be happy to accept code contributions that improve support for such devices, but we're not going to spend time on it ourselves.


[SPARK-37831][CORE] add task partition id in TaskInfo and Task Metrics

Why are the changes needed?
There is no partition id in the current task metrics. It is difficult to track the task metrics of a specific partition or the stage metrics of processing data, especially when the stage was retried.
class TaskData private[spark](
    val taskId: Long,
    val index: Int,
    val attempt: Int,
    val launchTime: Date,
    val resultFetchStart: Option[Date],
    @JsonDeserialize(contentAs = classOf[JLong])
    val duration: Option[Long],
    val executorId: String,
    val host: String,
    val status: String,
    val taskLocality: String,
    val speculative: Boolean,
    val accumulatorUpdates: Seq[AccumulableInfo],
    val errorMessage: Option[String] = None,
    val taskMetrics: Option[TaskMetrics] = None,
    val executorLogs: Map[String, String],
    val schedulerDelay: Long,
    val gettingResultTime: Long)

Does this PR introduce any user-facing change?
no
How was this patch tested?
add new tests

For the specific purpose detailed, use index ?

+CC @tgravescs, @Ngone51
I am surprised this is an issue ... want to make sure I am not missing something here !

The main purpose of this issue is to track the task metrics of a specific RDD partition, espetially for input/shuffle reads or output/shuffle writes.
It is very useful when shuffle data diff is found, we can use this to check data computing.
Also, it will be helpful to show the actual computing data size or count in SQL UI.

FWIW, there's a bug on updating the status in the check (https://github.com/apache/spark/pull/35179#issuecomment-1011881076). The tests in this PR looks passed (https://github.com/stczwd/spark/runs/4799251925).

cc @dongjoon-hyun @srowen @cloud-fan

yeah generally index = partition id on the first execution but doesn't work on retries. I remember running into this a few times but was never a huge issue, seems like a good thing to add

@tgravescs Agree, for the first stage attempt this should be fine.
But for any stage attempt which is computing a subset of tasks (retries, specific partition computation via toLocalIterator, etc), this is a concern.
This does look like an important missing functionality, thanks for working on it @stczwd - tagged others since I wanted to make sure I was not missing something here :-)

This does look like an important missing functionality, thanks for identifying and working on it @stczwd ! Given size of the PR, I will try to circle back to it over the weekend.

Took an initial pass through the PR and added some comments - overall looks good. We would need to make sure that skew join and partition coalescing in SQL interact well with this change.

Thanks for you reply. I have test partition coalescing in SQL interact, it works well with this change.

What I want @cloud-fan, @dongjoon-hyun, etc who are more familiar with SQL to look at is - given a single partition gets computed by multiple tasks, what is the expectation ?
Do multiple tasks end up with the same partition-id ? If yes, how do we differentiate between them in case of failures/recompute - if not, how do we identify them ? (or, if I am missing something - would love to understand how this pr is compatible with sql in partition coalascing/skew join scenarios).

kindly ping @cloud-fan @HyukjinKwon @dongjoon-hyun @rdblue

kindly remind @cloud-fan @HyukjinKwon @dongjoon-hyun
Any more question about this pr?

Hi guys, the long holiday is over, can we move on?
@cloud-fan @HyukjinKwon @dongjoon-hyun

It would be good to make sure we test backwards compatibility on the history server. ie use the old history server to read newer event log with this change.

It would be good to make sure we test backwards compatibility on the history server. ie use the old history server to read newer event log with this change.

Thanks for your attension. Yeap, we have already test it with old history server and new server while using a server generate eventLog and read it from another server, they all works fine with this change. Besides, we have already used it in our environment, which has different versions of servers, especially spark2.x.

I wanted to confirm whether we have tests where task index != partitionId - for example stage resubmission case.

Yes, we have already test this.

Would be good to explore how we can default the value to -1 if missing.
Else cleaning up all level-db would be a prerequisite to deploying this.
I am not sure what is the cleanest way to enforce incompatible leveldb format changes - IIRC you had made some >changes recently which require regen, right @dongjoon-hyun ? Any suggestions ? (IIRC we did not bump up the store >version)

ping @dongjoon-hyun. Could you take a look at the question above?

Changes look good to me. Would like to understand how to handle the format change impact based on @dongjoon-hyun's experiences though.

@Ngone51 @mridulm Since the default value can be set, the previous problem does not exist now. Can this pr be merged?

Any more question about this pr? Can this pr merge now?

cc @cloud-fan @mridulm @Ngone51 @HyukjinKwon @MaxGekk GA has passed, can we merge this pr to master/3.3.0?

Thanks all.


Update plotcollection example

📚 Documentation preview 📚: https://arviz-plots--26.org.readthedocs.build/en/26/

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Comparison is base (de2b449) 77.18% compared to head (6f65ef4) 77.18%.

Additional details and impacted files
@@           Coverage Diff           @@
##             main      #26   +/-   ##
=======================================
  Coverage   77.18%   77.18%
=======================================
  Files          10       10
  Lines         561      561
=======================================
  Hits          433      433
  Misses        128      128

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.


Support random grpc port

          > it's ok for me. but I haven't found a good Implementation for GrpcServer at present.

I see. I thought originally you want to support it in a follow up pr.
Like @jerqi said, is there any problem that you can raise up?
Originally posted by @advancedxy in https://github.com/apache/incubator-uniffle/pull/723#discussion_r1151472928

Could we add some descriptive information here? @xumanbu

Is this a duplicate issue?

Closed by #820


Creating a Table from an existing pandas dataframe does not create Variables for series

When doing this:
table = Table(df) # assume df has columns name and value

# then this doesn't work:
table.name.metadata.title = "Test"

We paired on this and decided to drop support for table.name mapping to table.metadata.name, since there is a conflict between this and Pandas mapping table.name to table[name].
So now, we always write: table.metadata.name = 'Test' to avoid confusion


update SimpleIndexer to use IndexCollection.Args

A couple of notes:

AnalyzerMap.java helps avoid a lengthy if/else in SimpleIndexer as we have currently in IndexCollection when selecting language-specific analyzers
storeDocvectors, storePositions etc are usually passed through IndexCollection.Args to the generator. Rather than update all generators with new constructors able to use SimpleIndexer.Args to collect this argument, I currently allow SimpleIndexer to reuse IndexCollection.Args.
A downside of this decision is that when SimpleIndexer is initialized from Args, -collection and -threads must be passed (because they are marked as required in IndexCollection.Args). However, they are not used by Simplelndexer.

See #2060

Codecov Report
Base: 58.93% // Head: 58.54% // Decreases project coverage by -0.39% :warning:

Coverage data is based on head (5b8f592) compared to base (dc0b7ff).
Patch coverage: 2.59% of modified lines in pull request are covered.

:mega: This organization is not using Codecov’s GitHub App Integration. We recommend you install it so Codecov can continue to function properly for your repositories. Learn more
Additional details and impacted files
@@             Coverage Diff              @@
##             master    #2061      +/-   ##
============================================
- Coverage     58.93%   58.54%   -0.39%
  Complexity     1135     1135
============================================
  Files           187      188       +1
  Lines         10960    11032      +72
  Branches       1487     1490       +3
============================================
  Hits           6459     6459
- Misses         4011     4083      +72
  Partials        490      490

Impacted Files
Coverage Δ

...rc/main/java/io/anserini/analysis/AnalyzerMap.java
0.00% <0.00%> (ø)

src/main/java/io/anserini/index/SimpleIndexer.java
20.53% <4.25%> (-12.33%)
:arrow_down:

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

:umbrella: View full report at Codecov.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.


Use Promises internally

Use Promises internally (avoids need for dep. and prepares for readFilesystemTree deprecating callback API)
The Promises and async/await are supported in the maintained Node versions (8+).
Btw, thanks for the commit access. Would you like me to submit any changes as PRs, or directly commit chores like updating non-breaking dependencies, lint fixes, etc.?

Also, are you ok with the preferring const (or if changeable let) style?

@brettz9 Please open PRs for any meaningful changes, and try to get someone else to review and feed back, even if that takes time.
I would strongly prefer to stick to ES5 and callbacks, and not to change anything just for the sake of change.
But I am all for paving a path for Promise preferring programmers. Perhaps we could document manual and library-based .promisify() in README?

https://npmjs.com/util.promisify can be used to support back to node 0.12, or a Promise-polyfilled node 0.4. In newer nodes with util.promisify, it uses that implementation instead.

@ljharb, thanks! I knew there was something like that in core.
I'd be all for adding example with util.promisify to README.

This PR though isn't for returning a Promise, as I know you said you didn't want to add that complexity; this PR actually just eliminates a dependency (and happens to also prepare for a change planned in readFilesystemTree to move to Promises only).
As far as ES6, I tend to find those features make things more succinct and enables me to detect bugs. Are you wishing to enforce ES5 for new features too or are you only against refactoring old code when not needed?

@brettz9 readFilesystemTree is defined in this package. Did you mean read-package-tree? Could you link me to a PR or issue for that planned change?

Using async function blocks older nodes from using it; you can make the function return a Promise directly which works down to node 0.12.

Yes, sorry, read-package-tree.
Here is the source for that statement: https://github.com/npm/read-package-tree/blob/master/rpt.js#L145 , though I see now it is a little tentative in possibly dropping the callback by saying "and/or".

@ljharb : Sure, but didn't you move to only supporting maintained Node versions anyways? It is covered by those versions.

@ljharb : Also, as it is currently, the use of array extras like find won't get Node support that far back.

Fair, but anything that's API can be polyfilled (NODE_OPTIONS='--require=es5-shim --require=es6-shim' licensee, for example) while syntax can't without transpilation.

It seems to me that if users are going to have to go through hoops to use older code, and we aren't testing in CI to ensure they still can, they can try to add transpilation as well. There is value for users too, I think, in making things easier on developers. But sure I can revert if that is desired.

We're also not using the likes of https://github.com/mysticatea/eslint-plugin-node/blob/master/docs/rules/no-unsupported-features/es-syntax.md to ensure that we don't already have some such features like arrow functions which aren't supported by those older versions.

I will ask Isaac about read-package-tree. Eventually SemVer will tell us, either way.
In general, I'm not against any particular syntax or API. I am instead strongly in favor of economy of motion.
If and when an important dependency forces a change, this package will have to adapt. But until then, quiet and simple keep folks like me around. Feature and doc improvements are welcome. I have at least one feature in mind myself. But if this repo starts to churn, I'm going to have to step away from it.

Good to know, and we definitely want you around! :)
Off topic, but just to mention, I made a small commit which I think should be non-controversial in merely ensuring that null is not passed in.

@brettz9 please open PRs for changes. I want to see them, it helps prevent master contention, and it gets my attention so I can decide whether to publish a new version.

Ok, will do. Lot of potential edge cases, so now I know to err on the side of caution.

We now require node 14+, so we can use any syntax in that version as well as util.promisify.

Closing as stale.


Not a file

Hello,
I have a Oneplus 8 pro running Android 13 (OxygenOS).
When trying to change the wallpaper I have an error: termux-wallpaper: command not found.

Could you please check?
Thank you.
EDIT:
I install termux-api package in Termux (the Termux API app in F-Droid cannot be installed) but it doesn't work.

Hi.
So, the problem was that I changed my username but it tries to download from link with old username. Now it should work.
Also it takes a bit of time to actually change wallpapers which is especially apparent when using the notification script so keep that in mind

Sorry but I didn't fully read the question and errors was actually happening for different reasons. I can't really help with the last problem but I did improve the code so you can try redownloading the script and see if it works now


MIN_NOTIONAL Error on Post new order (MARKET)

when I try to post new order on market sometimes  I've got MIN_NOTIONAL  error.
according to my researches, it's because of the Binance trading rules, but I didn't find a way to handle it.
my website is a cryptocurrency shop and when a customer buy for example Bitcoin, I post new BUY  BTCUSDT order (Market)
           var taskResult = Task.Run(() => binanceClient.PostNewOrder("BTCUSDT", amount, 0m, OrderSide.BUY, OrderType.MARKET));

I found this API that returns average of trades in the last 5 minutes (https://api.binance.com/api/v3/avgPrice?symbol=BNBUSDT)
But the point is We don't send price when we post order on Market. It must get from market!
So what can I control it ?

I found this is Binance GitHub page (https://github.com/binance-exchange/binance-official-api-docs/blob/master/errors.md):
"Filter failure: MIN_NOTIONAL"   price * quantity is too low to be a valid order for the symbol.
We Can't control market price, So It seems we can control the quantity
Is it right?


Missing Requirements

So i have recently enabled this on our AD Connect instance and found i had to also do the following steps to get my devices to register as Azure AD Hybrid Joined.

Ensure the AD containers that have contain my computer objects are synced via AD Connect.  Previously we only synced Users and Groups.
Enable GPO "Register domain joined computers as devices" under "Computer Configuration\Policies\Administrative Templates\Windows Components/Device Registration"

Also might be worth noting within the troubleshooting you can see error logs in the event viewer under "Applications and Service Logs\Microsoft\Windows\User Device Registration" - without this it was hard to troubleshoot why my devices where not registering properly.

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

ID: 816f0138-d336-3905-9f4f-e60c04da9326
Version Independent ID: ce5166e4-5d15-ef1f-1090-576a69e601e8
Content: Configure hybrid Azure Active Directory join for managed domains
Content Source: articles/active-directory/devices/hybrid-azuread-join-managed-domains.md
Service: active-directory
Sub-service: devices
GitHub Login: @MicrosoftGuyJFlo
Microsoft Alias: joflore

Actually ignore 1 - i can see that is included in the text.  I missed that on my first pass through.

@eximo84 Thanks for reporting this to us. The GPO "Register domain-joined computers as devices" is ideally not required, as the device registration task runs automatically when it is not configured.
In some scenarios, this GPO is used to do a controlled rollout (stop the devices from registering). Did you get any error in the logs about the GPO?

No errors around GPO - only error i had was the device was missing which was related to me not syncing the containers.  I spoke to an MS engineer yesterday who confirmed for Windows 10 that GPO is not required as the scheduled task that executes on logon already exists in the OS.

@eximo84 Thanks for sharing the info. I will go ahead and close the issue for now.


linux-pam: enable libxcrypt by default

Motivation for this change
#147312
Things done
build pam with support for more hashing schemes by default.
Currently building a VM with this change in but it takes a long time.

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/)
21.11 Release Notes (or backporting 21.05 Release notes)

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

[x] Fits CONTRIBUTING.md.

I can confirm this builds (atop 715f63411952c86c8f57ab9e3e3cb866a015b5f2) and, within a VM, login with a yescrypt hash is successful. I did not test anything else. The build does take a while, and I set security.polkit.enable = false; services.udisks2.enable = false; to minimize some large bits that needed rebuild.
I’m happy to run whatever tests though if someone suggests and wants to avoid building themselves.

Additionally, the regex here should probably get updated to match the new algorithms, maybe.

su, doas, and sudo work as expected. (In a VM)
However, this breaks openssh password authentication badly. (even old hashes are refused) @amarshall can you confirm you can reproduce this error?
As long as this is the case, this patch cannot be shipped.
Nov 27 08:14:45 nixos systemd[860]: PAM unable to dlopen(/nix/store/jjdm85j98ih9d28hkcs8px5k218mcrpr-linux-pam-1.5.1/lib/security/pam_unix.so): /nix/store/z56jcx3j1gfyk4sv7g8iaan0ssbdkhz1-glibc-2.33-56/lib/libcrypt.so.1: version `XCRYPT_2.0' not found (required by /nix/store/jjdm85j98ih9d28hkcs8px5k218mcrpr-linux-pam-1.5.1/lib/security/pam_unix.so)
Nov 27 08:14:45 nixos systemd[860]: PAM adding faulty module: /nix/store/jjdm85j98ih9d28hkcs8px5k218mcrpr-linux-pam-1.5.1/lib/security/pam_unix.so
Nov 27 08:14:45 nixos systemd[860]: PAM failed: Module is unknown
Nov 27 08:14:45 nixos systemd[860]<EMAIL_ADDRESS>Failed to set up PAM session: Operation not permitted
Nov 27 08:14:45 nixos systemd[860]<EMAIL_ADDRESS>Failed at step PAM spawning /nix/store/az8yvxswppdwn9zpm377rzfjk5gwak3b-systemd-249.5/lib/systemd/systemd: Operation not permitted

This is too broad a change to do just like that. #112371 correctly points out that we need to go step-by-step.


Fatal error: Trait "Psr\Log\LoggerAwareTrait" not found in BaseCorvusPayClient.php

I try to create basic checkout.php i have this error, i use init.php

@NewRErg
Hello,
you are probably  missing this dependency: https://github.com/php-fig/log

Hi, thanks!
uf this is much more complicated than Stripe, I'm new in this payment integrations


Fix native code incremental compilation

Alter build_exe so that the executable depends on the object files in native mode, as well as the .cmx files.
It may be necessary to extend this to .cmxa?

Title updated to reflect the slightly broader scope! I think this now deals with all the required cases:

Executables may depend on .cmx and .cmxa files and they now also depend on .o/.obj and .a/.lib files (.cmxa files being pulled in via findlib are not processed further)
.cmxa files depend on .cmx files and they now also depend on the .o/.obj files
.cmxs files (in Jbuilder) depend on a .cmxa file only, and they now also depend on the .a/.lib file

Tested this as well. Looks good. Let's wait for @diml to come back to merge this.
Do you mind ocp-indenting your commits? Sorry for the nit.

Re ocp-indent, I'll get to it - things like that will become easier when I've finished focusing on native Windows opam and can install things like that more easily! It's a weak excuse, though, as I fixed this PR on Linux... :wink:

I've cherry picked this into master to make a release as this bug is causing grief for quite a few users. @diml feel free to amend/review at your leisure.


Enhanced OpenSearchVectorStore - Squashed

These changes enable support for both Exact k-NN and Approximate k-NN searches in OpenSearch. The code was updated and refactored to include this new functionality, as it previously only supported Exact k-NN. This work is based on the squashed changes from Enhance OpenSearchVectorStore #987.

Enhanced OpenSearchVectorStore to support both exact and approximate k-NN search methods.
Updated integration tests to cover common similarity metrics (cosinesimil, l2, innerproduct) for both exact and approximate k-NN.
Made necessary updates to the auto-configuration to accommodate the new support for approximate k-NN.
Updated the OpenSearch Vectorstore documentation to reflect these changes.

@tzolov @markpollack
Hello, I was wondering if there's been any progress on reviewing?


TM Processing L0: EnergyCalibration

2022-07-08 17:56:10,117 Fits file solo_L0_stix-ql-lightcurve_0706233600_V01.fits exists appending data
2022-07-08 17:56:10,269 VerifyWarning: Card is too long, comment will be truncated.
2022-07-08 17:56:10,519 Error processing file /data/stix/out/test/bsdfull/LB/21/6/41/solo_LB_stix-21-6-41_0642211200_V01.fits for 21, 6, 41
2022-07-08 17:56:10,520 index 293 is out of bounds for axis 0 with size 293
2022-07-08 17:56:11,733 Fits file solo_L0_stix-ql-lightcurve_0678758400_V01.fits exists appending data
2022-07-08 17:56:11,889 VerifyWarning: Card is too long, comment will be truncated.
2022-07-08 17:56:11,928 Fits file solo_L0_stix-ql-lightcurve_0678844800_V01.fits exists appending data

the error is somewhere in the rebin_proportional method. i will assign this to you @samaloney
you can invoke with ./stixcore/processing/stix-pipline -b L0 -e L0 -f /data/stix/out/test/bsdfull -s /data/stix/spice/git/solar-orbiter/kernels --filter solo_LB_stix-21-6-41_0642211200_V01*

Yea so the issue here is the sub spectrum configuration changes from one sub spec with all 1024 channels to 3 sub spect with a diff configuration about half way through. I'm kinda surprise this doesn't happen more often kinda related to #168


Text encoding option should be added

I noticed that this only supports UTF-8 text, when the large majority of NFTR fonts I've seen are either UTF-16LE or SHIFT-JIS. Because of this, I'm unable to type anything outside of basic ASCII using this.

This should be fixed in 1.7.0
If the font you're using doesn't use the shift_jis encoding, you can use the new encoding parameter to set for example --encoding utf8


Foundation code for Message Groups

Hey again :)
I got started working on #1183 and I thought I'd get this PR made sooner rather than later so you can take a sneak peek if you want - I've got a decent amount of the foundational work done towards it without (I believe) causing any breakage.
Mostly though I want to ask the question: How would you like to organise getting my changes PR'd into danger? All in one massive PR when I'm all done, or piece-by-piece?
The summary of the changes I've made are that:

The MessageAggregator class has been added without any methods.
MessageAggregator.aggregate (which does not exist) will be called from Dangerfile#post_results, and it will be created if a request_source has a #update_pr_by_line! method (which none currently do) (I am very happy to change #update_pr_by_line!'s name - it's the best I could come up with at the time!)
The MessageGroup type has been added and has a fairly decent sketch of its methods.
Violation now has a #type, which defaults to :warning, can be set from calls to .new, and all calls to .new inside this codebase pass it - so fail,warn, message all create Violations with the correct type#
Markdown now also has #type - which returns :markdown.
Violation and Markdown now have a thoroughly-tested #<=> method each. in preparation for the sorting code being added to MessageGroup.
Violation and Markdown now inherit from a base type to keep the code a bit DRY-er. In retrospect perhaps the base class should've had a list of types and their orderings - but I only made the base after I'd started on the implementation for sorting them both 😅

A changelog to that effect will be along shortly :)
P.s. is it cool if I add Fuubar and fiddle with the guardfile so it doesn't run rubocop if the rspec tests fail?

          1 Error

:no_entry_sign:
Please include a CHANGELOG entry.
You can find it at CHANGELOG.md.

  Generated by :no_entry_sign: Danger

I'm happy for you to add deverloper-y dependencies, I only get cagey about dependencies which danger consumers end up with.
WRT to how you want to get it in, I prefer that master is always deployable - this looks backwards compat, but if it weren't we could just scope it like:
if env.request_source.respond_to?(:update_pr_by_line!) && process.env.USE_NEW_THING

So, feels good to me

Cool - I'm gonna deal with your suggestion on the markdown file, dogfood it more at work to ensure that I've not broken anything, then un-WIP this :)


Server state at startup

Is it possible to get the triggers: state or events: state nodes to output an initial value at deployment, or do I have to use a combination of events:state  and  current state for that?
It would be very useful to be able to get an initial value from the events:state node, to initialize other nodes at startup.

Is it possible to configure the poll nodes to only output the value at init and not continue to poll?
It would be very useful if this could be added to the state nodes at some point, I can't imagine I'm the only one that would appreciate the functionality.
Thanks!

@AYapejian: would a pull request that adds an "output initial state" flag to those nodes be welcome?
If yes, then I'll try adding it.


Enhance GPU assignment.

What would you like to be added:
Prioritize those machines that already have tasks but have free GPUs.
Why is this needed:
Suppose that I have 2 workers, 4 GPUs on each one.
JobA uses 2 GPUs and runs on worker1. When JobB is submitted to OPENPAI, PAI might assign a GPU on worker2 to JobB.
Now the GPU usage is 2/4 and 1/4. I can't submit a 4 GPUs job.
I think OPENPAI should prioritize those machines that already have tasks but have free GPUs. For example, assign a GPU on worker1 to JobB.
Components that may involve changes:
YARN?

Yeah, we have it.
https://github.com/microsoft/pai/blob/b2324866d0280a2d22958717ea6025740f71b9f0/subprojects/frameworklauncher/yarn/src/main/java/com/microsoft/frameworklauncher/common/model/LauncherConfiguration.java#L110
Default value of 2 means we choose 2 heaviest nodes, then randomly pick 1. You could set it 1 to avoid randomness. Then Every job will be assign to the heaviest node.


Lint the JS

Do JS linting to catch style issues like this automatically: https://codeclimate.com/github/nnnick/Chart.js/src/Chart.Core.js

We do jshint code in gulp test (which travis runs), perhaps it just needs to be more aligned with this.

I think what we have is good enough (including CodeClimate). The real issue is just that some items are outstanding. I'm working on that, closing this.


[DT] Making document filter properties (CreatedBefore and CreatedAfter) nullable

Made the attributes DocumentFilter.CreatedAfter and DocumentFilter.CreatedBefore nullalbe.

The following tests needed rerunning as there was a change in the request URI
GetAllDocumentStatusesOrderByCreatedOn
GetAllDocumentStatusesFilterByStatusTest
GetAllDocumentStatusesFilterByIdsTest
The change in the request URI is that the createdDateTimeUtcStart and createdDateTimeUtcEnd were no longer included as URL paramters (which makes sense since they're nulled).


[ilp-core] Switch to using Maven only?

 Issue by adrianhopebailie
Friday Sep 29, 2017 at 18:47 GMT
Originally opened as https://github.com/interledger/java-ilp-core/issues/88

We currently have an overly complex build system with both Maven and Gradle.
The majority of contributors use Maven and it has proven to be better supported by plugins. It would be helpful to switch but I propose we take a contributor vote.

 Comment by earizon
Wednesday Oct 18, 2017 at 11:10 GMT

Not problem for me to default to maven. I vote for the one that simplifies CI. (I'm not aware of the pros and cons of each one for CI)

 Comment by adrianhopebailie
Wednesday Oct 18, 2017 at 11:39 GMT

I suggest we implement this change as part of migrating the code over to the Hyperledger Quilt project

 Comment by rizwantanoli
Friday Oct 20, 2017 at 02:37 GMT

I am not a contributor yet, hope to become one, but my preference would be Maven

Maven is now in effect in the quilt project.


Adding tag functionality to component config

Converted to draft as we discuss #87

Closing in favour of #183


Adding inverse transform method to pipelines (#2256)

Adding inverse transform

Release notes for PR 2256

Inverse transform only takes y

Skipping polynomial detrender test

Adding docstring for pipeline inverse transform

Add PR 2256 to future release section

Docstring for SubsetData test transformer

Fix PipelineBase.inverse_transform docstring

Update release notes

Change variable names in ComponentGraph.from_list

Add/fix docstrings

Deleting whitespace

Linting polynomial detrender

Fixing unit tests

Linting with black

Pull Request Description
(replace this text with your description)

After creating the pull request: in order to pass the release_notes_updated check you will need to update the "Future Release" section of docs/source/release_notes.rst to include this pull request by adding :pr:123.

@chukarsten I think we can close this? The RTD issue was resolved right?

Closing because we fixed the RTD issue!