docs(decision-tree-widget): Add header to decision tree widget section

I commonly tell people about the decision tree widget and every time I do they alway say the same thing: "Oh you should make that more noticeable" 😆
So...I did the laziest thing I could think of, gave it a header.

If someone has better suggestions, go with them instead 😄
I thought about moving it to be at the top, but absolute first-timers might be confused. then again maybe that's an acceptable risk at the expense of helping tons of people discover it. I really is useful to them (and me even). On my laptop, the wizard is below the fold which is likely one of the reasons it's never seen.

Coverage remained the same at 97.68% when pulling ea0c6dda5656281253bf2282e6ba447fb250aac8 on jayphelps:suchwow into 3e9d5295f118c29193f88ea825902ac359901119 on ReactiveX:master.

:shipit:


Distibuted ingestion

@tamirms reminded about distributed ingestion in #1519. Basically for availability we need to have multiple ingesting instances, so when one instance goes down, the other one can continue. This is actually simple to do, we can use key-value store to block on the ledger number (SELECT ... FOR UPDATE) when ingestion is starting. Then we can have many idle ingestion processes that can continue when the main instance stops running.
However, the problem appears when there are multiple ingesting nodes with some in-memory stores (like order book graphs) that should be synchronized in a way that they always respond with a data for the same ledger.
I think in general we have the following options:

Use master-standby pattern. Basically we have n ingesting nodes but only one is a master node that accepts all requests to in-memory structures. It's Horizon admin responsibility to automate flipping process to standby instance when master stops working. This is the simplest solution but require a few devops hours on Horizon admin side for initial configuration. @brahman81 from devops perspective do you think it is hard to do?
Always keep the state for the last few (one?) ledgers. When one of the ingesting nodes is behind, it serves stale data. This was the idea we originally had to tackle this problem at the design meetings.
Inter-node synchronization protocol. In short, all read requests are blocked until all ingesting nodes broadcast that the latest ledger has been processed by them. It probably requires another server to be source of truth to decide what to do if one of the instances stop working or is slow, maybe leader-election algorithm? It's probably the hardest solution but require no work on Horizon admin part (except defining IPs of the other nodes).

Any other ideas? @tamirms @ire-and-curses

Is there any need to do this for performance / load spreading reasons, or is it just availability?
If we're just going for availability, master-standby (with all nodes actively ingesting) seems like the simplest solution by far.
Another simple option is using ip-based affinity for load balancing. That means each client will get consistent results except possibly around the time of a server entering or exiting the rotation. It doesn't solve the issue of consistent results across clients though.

Basically we have n ingesting nodes but only one is a master node that accepts all requests to in-memory structures
Routing in-memory structure requests to a specific node is fairly simple to setup but am not sure it's such a good idea from a scaling perspective. This node effectively becomes a bottleneck/single point of failure. Tools such as Kubernetes, Autoscaling groups or application load balancers can mitigate this to a certain degree if we decide to go down this road but it ends up making distributed Horizon deployments more complex imo.

Is there any need to do this for performance / load spreading reasons, or is it just availability?

It's just for availability.

Another simple option is using ip-based affinity for load balancing. That means each client will get consistent results except possibly around the time of a server entering or exiting the rotation. It doesn't solve the issue of consistent results across clients though.

The problem with this is it's usually based on cookies so if the given client app doesn't properly implement the cookie-jar it may get invalid results. For ip-based affinity, I think some ISPs change their clients IPs from time to time so it may also not be fully reliable.
We just had a quick chat about this with @ire-and-curses and @tamirms and we decided that probably the best solution is to go with master-standby solution. The reasoning is as follows:

The code solution in Horizon seems not trivial (leader election, handling timeouts, discoverability) and can cause a lot of bugs that are hard to track. It seems that products like ZooKeeper are built exactly to solve this issue and they are separate projects on their own.
We don't have exact data what percentage of Horizon users actually need this. There were also no requests like this so far.
If a given organisation's use-case require a more complex deployment, they probably already have an ops team that can prepare master-standby architecture.

However I've exchanged a couple of messages with @brahman81 and he brought some valid points:

Requests to a given endpoint routed to a single instance may slow it down, so it may be required to up the specs.
In general, it adds a complexity compared to the current simple load-balancer.

We still have a couple weeks before the next release date so maybe we can explore the solution that squash offers at the single price level to see if it's faster? If it's not fast enough, maybe we can keep the graph on all nodes as @tamirms suggested. The up to date data is not a huge requirement in this case because there's always a time delay between showing results to the user and them picking an offer that works for them. And it seems that for other existing Horizon features in-memory data structure won't be needed.

Here's another simple alternative:

We allow users to pass in a min_ledger parameter to API calls we want to protect from ingestion issues
We return a current_ledger with API responses
If a Horizon gets a request for a ledger that's larger than its current ledger it does one of two things:

if the min_ledger is 2 or less ledgers away from its current ledger, it blocks until min_ledger == current_ledger, or for a max of 20 secs.
otherwise, Horizon returns a 404.

It means a user can avoid ever seeing an older result after a newer result if they pass the current_ledger from their last request in with their current request as min_ledger. And it allows us to support full round robin load balancing.

Let me propose another idea that is kind of mix of above.
First of all, some observations:

It seems that even selecting a few instances as ingesting requires some configuration that, even if is easy, can be error-prone.
The consistency of Horizon responses makes sense only when we have request batching or something like GraphQL. Without it, we can't really maintain consistent view for two requests. But that's great that we're thinking about it now.
If we decide to update the memory state of non-ingesting instances via DB it requires us to duplicate a lot of code and much more testing. We can end up with invalid state if the code doesn't work exactly the same as in ingesting node.

Here's the idea. We make all nodes ingesting by default. This remove all configuration/routing/leader election issues. As of now, we have two stores: memory (OB graph) and Postgres DB (rest of the data). We make Postgres our single source of truth. Then the ingestion algorithm on each node is roughly:

SELECT ... last_ingested_ledger ... FOR UPDATE. This will make only one Horizon instance to actually get the value and the rest will be in a blocked state until a DB transaction commits/rollbacks. This is actually selecting a leader/master randomly.
We compare last_ingested_ledger value to the last processed ledger sequence (internal_last_ingested_ledger) processed by the current node.
If last_ingested_ledger == internal_last_ingested_ledger: the current node is the master ingesting node in this round. We process the full pipeline.
Else: the other node processed this ledger, we omit processors that store results in a DB but do process data we keep in memory (OB graph in our case).

We can observe that all nodes other than master will be a little bit behind in terms of updating memory data. How to solve this:
In action/controller that gets data from DB only we basically get the results, because DB results are always the latest ingested data.
In action/controller that gets data from memory:

Simple solution: since we don't need consistency right now (observation 2) we just serve the graph we currently have in memory.
Great solution: if we need consistency (we'll need it at some point) we have a couple options:

We fetch the last_ingested_ledger from DB and compare it to internal_last_ingested_ledger. If it's not equal, we wait for the current node to catchup (maybe using channel signal?).
We extract OB graph processing to another pipeline and keep the graph versions for last few ledger, we query the graph that matches the last_ingested_ledger. This exploits the fact that updating OB graph will probably always be faster that the pipeline modifying a DB.

Advantages:

There's a single code that updates the state on all nodes (observation 3). However, some parts are turned off for non-master ingesting node. It's easier than maintaining two versions of the code (for ingesting/non-ingesting node).
Requests to the data is evenly distributed to all nodes (compared to only one ingesting node in the previously proposed solution).
The configuration is easier.

Disadvantages:

There will be some delays when requesting memory structures (for the simple version above).
???

@bartekn I like the solution. My suggestion is that have two different ingestion pipelines, one for updating database state and another for updating in-memory data structures. The distributed lock will only be necessary for the database ingestion pipelines. The in-memory updating pipelines can operate independently without any synchronization.
If we need consistency for serving requests using in-memory data structures, I prefer the min_ledger approach outlined by @tomquisel .
The problem I see with the work flow of reading last_ingested_ledger from the db and then waiting until  internal_last_ingested_ledger matches that value is that it's possible that the horizon instance serving the request catches up to last_ingested_ledger but by the time that happens the other master horizon instance already advanced to the next ledger.

I also wanted to mention that, as an alternative to select for update,  it's possible to implement distributed locks using advisory locks in postgres https://medium.com/@codeflows/application-level-locking-with-postgres-advisory-locks-c29759eeb7a7

The problem I see with the work flow of reading last_ingested_ledger from the db and then waiting until internal_last_ingested_ledger matches that value is that it's possible that the horizon instance serving the request catches up to last_ingested_ledger but by the time that happens the other master horizon instance already advanced to the next ledger.

@tamirms I agree with that analysis, but doesn't Tom's suggestion have the same possibility? During the 20s grace period before the server catches up or times out another server could advance to the next ledger.

@ire-and-curses I think in tom's proposal we don't require that the response corresponds the latest ledger, we only require that the response corresponds to a ledger which is greater than or equal to the  min_ledger parameter

My suggestion is that have two different ingestion pipelines, one for updating database state and another for updating in-memory data structures. The distributed lock will only be necessary for the database ingestion pipelines. The in-memory updating pipelines can operate independently without any synchronization.

The problem is that LiveSession supports a single pipeline only. We can probably have another LiveSession. Let's discuss this during development.

If we need consistency for serving requests using in-memory data structures, I prefer the min_ledger approach outlined by @tomquisel .

It think the main problem with @tomquisel idea is that the average wait time will be long and it doesn't solve consistency in some cases. I need to make a request first to check what's the latest ledger and then try to guess what number to send to get a result (current_ledger+1/current_ledger+2). Possible cases are:

[Optimistic] At the moment I send my request the min_ledger is actually equal current_ledger so I get the result right away.
When I send my request and min_ledger>current_ledger: Then data from different stores can be at different ledgers min_ledger+X and min_ledger+X+1.
When I send my request and min_ledger<current_ledger: I need to wait. But also it's possible that I get a signal to proceed only some stores are updated. It's not clear how to Tom wants to solve this.

Let me know if there's anything wrong in above.

The problem I see with the work flow of reading last_ingested_ledger from the db and then waiting until internal_last_ingested_ledger matches that value is that it's possible that the horizon instance serving the request catches up to last_ingested_ledger but by the time that happens the other master horizon instance already advanced to the next ledger.

It won't happen if we make all requests to a DB in isolated transaction (REPEATABLE READ).

The problem is that LiveSession supports a single pipeline only. We can probably have another LiveSession. Let's discuss this during development.

yes, I meant to say that there would be two sessions, one for the database updates and another for the in memory updates.

It think the main problem with @tomquisel idea is that the average wait time will be long and it doesn't solve consistency in some cases. I need to make a request first to check what's the latest ledger and then try to guess what number to send to get a result (current_ledger+1/current_ledger+2).

I think the point of the min_ledger approach is that we don't need all the horizon instances to be synchronized. I only care that the response is accurate for a given ledger.
I don't see why an API consumer would make a request to find the latest ledger before calling the path finding endpoint. In most cases, I would assume that API consumers would be content with the latest data available on the given horizon instance. Otherwise, if the response must match a specific ledger the ledger should be provided explicitly.

I think the point of the min_ledger approach is that we don't need all the horizon instances to be synchronized. I only care that the response is accurate for a given ledger.

The problem is that data may not be consistent within a single node (memory vs database at different ledgers). Even when you pass min_ledger and wait, it's still possible, I explained how in https://github.com/stellar/go/issues/1529#issuecomment-514796637.

I don't see why an API consumer would make a request to find the latest ledger before calling the path finding endpoint. In most cases, I would assume that API consumers would be content with the latest data available on the given horizon instance.

So the min_ledger is an optional parameter?

Otherwise, if the response must match a specific ledger the ledger should be provided explicitly.

It's still not clear to me how this solution work. I guess some extra explanations would help. How does it work in the cases I listed above:

[Optimistic] At the moment I send my request the min_ledger is actually equal current_ledger so I get the result right away.
When I send my request and min_ledger>current_ledger: Then data from different stores can be at different ledgers min_ledger+X and min_ledger+X+1.
When I send my request and min_ledger<current_ledger: I need to wait. But also it's possible that I get a signal to proceed only some stores are updated.

The problem is that data may not be consistent within a single node (memory vs database at different ledgers).

@bartekn , this is a very good point. I definitely missed this earlier and now I understand the rationale behind your approach. Given that requirement, I take back my earlier suggestions.
I think we should use the same session to process both the database ingestion and the order book graph as you originally proposed.
I have one question about the great solution, in the second bullet point you mention:

We extract OB graph processing to another pipeline and keep the graph versions for last few ledger, we query the graph that matches the last_ingested_ledger. This exploits the fact that updating OB graph will probably always be faster that the pipeline modifying a DB.

I thought that internal_last_ingested_ledger will always be less than or equal to last_ingested_ledger. There are two cases, either internal_last_ingested_ledger == last_ingested_ledger and we continue serving the path finding request with the in memory order book, or,  internal_last_ingested_ledger < last_ingested_ledger and we block until the current node catches up. I don't see a scenario where we need to maintain several versions of the order book graph. Could you explain why it's necessary?

@tamir in the solution where we maintain two pipelines/sessions (one for OB
graph and the other one for DB updates), the OB pipeline will probably
always be faster. If the processing time of both pipelines is smaller than
average close time the difference should never be more than 1 ledger
(however can be more if there are delays). The reason we need OB graphs for
the last few ledgers is that DB state can be one (or more) ledger behind
the OB state. Here's an example sequence:

DB pipeline starts processing.

OB pipeline starts processing.

OB pipeline ends.

The user requests /paths.

We start a DB transaction with REPEATABLE READ isolation.

We query a DB to get the latest processed ledger (this is our source of
truth). Let's say the returned value is X.

However OB graph represents X+1 (or X+2, X+3... in case of big delays).

DB pipeline ends and commits a transaction.

If we store OB graph for the last few ledgers, we can simply get the result
for the ledger X (instead of X+1). However, as I mentioned above we don't
need this until we have batching so the simple solution where the state of
OB graph is not in sync with a DB is fine.
W dniu czw., 25.07.2019 o 07:58 tamirms<EMAIL_ADDRESS>napisał(a):

The problem is that data may not be consistent within a single node
(memory vs database at different ledgers).
@bartekn https://github.com/bartekn , this is a very good point. I
definitely missed this earlier and now I understand the rationale behind
your approach. Given that requirement, I take back my earlier suggestions.
I think we should use the same session to process both the database
ingestion and the order book graph as you originally proposed.
I have one question about the great solution, in the second bullet point
you mention:
We extract OB graph processing to another pipeline and keep the graph
versions for last few ledger, we query the graph that matches the
last_ingested_ledger. This exploits the fact that updating OB graph will
probably always be faster that the pipeline modifying a DB.
I thought that internal_last_ingested_ledger will always be less than or
equal to last_ingested_ledger. There are two cases, either internal_last_ingested_ledger
== last_ingested_ledger and we continue serving the path finding request
with the in memory order book, or, internal_last_ingested_ledger <
last_ingested_ledger and we block until the current node catches up. I
don't see a scenario where we need to maintain several versions of the
order book graph. Could you explain why it's necessary?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/stellar/go/issues/1529?email_source=notifications&email_token=AADRQKQJHJAZ77GU2I5LOOTQBE6JDA5CNFSM4IF3IWW2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD2YOBIQ#issuecomment-514908322,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AADRQKWIHOBIFLIJLXLC6DDQBE6JDANCNFSM4IF3IWWQ
.

I like Bartek's great solution and would be happy with the simple solution for now.
Specifically, my favorite version of the great solution is this one:

We fetch the last_ingested_ledger from DB and compare it to internal_last_ingested_ledger. If it's not equal, we wait for the current node to catchup (maybe using channel signal?).

This seems simpler than maintaining multiple versions of the data in memory.
I think we should maintain slow consistency even without GraphQL or other request batching. This is the expectation that if you read a value from Horizon, you cannot then read an earlier value. I'd even go further, and say we should ensure that if you read a value from ledger N, you cannot then read a value from any ledger less than N.
I think the simple solution is fine for the very first version since ingestion is typically very fast and issues will rarely show up, but it'd be good to move to maintaining slow consistency in the short term.
I think Bartek's algorithm can be tweaked slightly (unless I misunderstood it) to minimize latency and also guarantee slow consistency.
Here's the tweaked version:

The node fetches the last_ingested_ledger from DB at the time the request comes in. Call this L.
We wait until internal_last_ingested_ledger >= L if needed.
If more than some constant, say 10 seconds passes, we abort the request and return 500.
Otherwise, we service the request.

What I don't love about this is that we're constantly fetching last_ingested_ledger from the DB on every request.

What I don't love about this is that we're constantly fetching last_ingested_ledger from the DB on every request.

@tomquisel actually we only need to compare internal_last_ingested_ledger when handling requests which fetch data from the in memory orderbook. So, we'd only need to fetch last_ingested_ledger from the DB on path finding requests.
All other requests fetch their data from the DB and the data in the DB is consistent with last_ingested_ledger


Define THRUST_CPP_DIALECT correctly under MSVC

MSVC doesnt define __cplusplus correctly unless a compiler flag is passed (/Zc:__cplusplus) but _MSVC_LANG is defined correctly.
To avoid users needing to pass an extra compile flag, I suggest we handle it in the cpp_dialect.h file

Yep, this is a clear oversight.
Running internal CI.
@griwes to code review.

Passed internal CI.

We had to revert this - what we need to do here is a bit more complicated, as MSVC isn't fully compliant (expression SFINAE) until newer versions.
Can you open an issue to discuss this further?

Damn, i only tested using VS2019.
Issue #1030 created to track this.


autocorrecting Style/TrailingComma

chefstyle -a fixed 1044 occurrences

@chef/client-core add a whole lotta trailing commas

Is it possible to enforce this only for multi-line arrays/hashes? After seeing the effect, I'm inclined to not care about trailing commas for single line stuff, if we can pull it off. :+1: if not.

it actually does it only for multi-line.
the problem is that this is multi-line:
         sip_paths= [
            '/System', '/bin', '/sbin', '/usr',
          ]

that could get fixed to either:
         sip_paths= [ '/System', '/bin', '/sbin', '/usr' ]

or:
         sip_paths= [
            '/System',
            '/bin',
            '/sbin',
            '/usr',
          ]

but rubocop can't autocorrect those.

Ok, I see now. Carry on, then. :+1:

:+1:


OpenVPN wizard

We have 2 OpenVPN Servers running on different WAN IPs on different Ports.
If we start the wizard for the 2nd Server and choose the same CA as on the first Server and create a new Server certificate, a new CA with the same name is created.

I'll take a closer look, thanks for the report.

I can reproduce, fix coming in a second. :)


Grid not rerendering when isDraggable or isResizable changes

Thanks a lot for the update!
However, I am facing issues after upgrading. I have an "Edit" button which toggles between "view mode" and "edit mode". I achieve it in the following way (see code):
      <ReactGridLayout
        isDraggable={isLayoutEditable}
        isResizable={isLayoutEditable}
        ...
      >

After the update, the Grid component does not rerender anymore, making it impossible to enter the "Edit mode". Here you can see the edit mode in action (before updating).
I think it is connected to #1123 and might be the same core issue as for #1150. It could also be connected to #892.
I can create a branch in my repository with the updated version of RGL if it helps you reproducing the issue.

I'm having issues with onDrop and the placeholder not rendering. I can get the element to render in the DOM if I modify shouldComponentUpdate in https://github.com/STRML/react-grid-layout/blob/master/lib/ReactGridLayout.jsx#L201 by adding
||  !isEqual(this.state.droppingPosition, nextState.droppingPosition);

But it's still invisible. I think it's related to this issue, but I can file a separate issue if necessary.

Hey @darekkay, thanks for reporting this, indeed it seems to perform weird with the new faster comparison.
@STRML Somehow we missed this, sorry about that. I've run most examples and my own project and didn't notice the issues.
Anyway, I can now reproduce the problems on example-6, adding new items doesn't work unless we compare the children (which I see that you explicitly remove from the comparison for perf reasons).
Also, adding a switch to toggle isResizable and/or isDraggable on the grid doesn't really work properly (this one I'm not sure why since the props are both in the fastRGLPropsEqual comparison, I'm trying to debug it, will shout out if I find anything).

Taking a look now.

Thanks, fixed in 0.18.2, see https://github.com/STRML/react-grid-layout/blob/master/CHANGELOG.md#0182-feb-26-2020 for more detail.

Thanks for fixing this so fast, now everything works just fine 👍


Need validation decorator for Command functions

Decorator should validate a payload based off specified type to ensure all properties of payload dynamic object match expected types and throw readable error back to UI if not.  Needs a boolean flag to determine whether to ignore properties that don't have a matching name.

Partially implemented in the 2.0 release


"reverse" with tenant?

How do I utilize the django urlresolve reverse function to take into account a particular tenant subdomain in the URL? I didn't see any custom reverse function in https://github.com/tomturner/django-tenants/blob/master/django_tenants/urlresolvers.py
Ex:
from django.core.urlresolvers import resolve, reverse
url = reverse('tenant_dashboard')
print(url)  # Result: /en/dashboard

# The next code is the desired functionionality I am looking for
url = tenant_reverse("some_tenant_name", "tenant_dashboard")
print(url)  # Result: http://some_tenant_name.mydomain.com/en/dashboard

I ask this question because I noticed the django-subdomains library has this sort of functionality. See here: https://github.com/tkaemming/django-subdomains/blob/master/subdomains/utils.py#L41
Thanks!

+1

Alright, my fix was this code:
from django.contrib.auth.models import User
from django.contrib.sites.shortcuts import get_current_site
from django.core.urlresolvers import resolve, reverse
from foundation_public.models.organization import PublicOrganization

# ...

def index_page(request):
    org = PublicOrganization.objects.get(owner_id=request.user.id)
    url = 'https://' if request.is_secure() else 'http://'
    url += str(org.schema_name) + '.'
    url += get_current_site(request).domain
    url += reverse('tenant_dashboard')
    print(url)  # Result: http://my_test_tenant.my_test_domain.com

# ...

However, I think having a custom reverse function for specific tenants would be immensely useful.

I can add that in at some point. If someone create a pull request tat would be good.

What a problem adding such func in your project? Everyone can do it on it's own, as not everyone is using sites ;) For example I have custom reverse so it's adding me URL_PREFIX which is smth like /tenant/{{tenant.slug_name}} so finally it's joined into smth like /tenant/abc/some/url/in/app, and I have many tenants per one domain. It all depends how you use this lib.

Hmmm you make a good point @kosz85. What do you think we should do in this case? I think having somesort of resolve function per tenant to be a extremly useful function.

I was thinking a bit about this issue. For me it's more like thing for examples chapter in docs (some kind of HowTo), then smth placed in core lib.
We would need to have specific implementation to be able implement resolve like that, so I think maybe another project that is using this one, or new module with explicit implementation of models. This lib isn't the simplest, but you know this problem itself isn't one of the simplest one :)
But if you want to add some implementation, I suggest to add resolve method on TenantMixin and dummy one, so that later you could overwrite it when inheriting. Then what you would do is use just tenant.resolve('some_view') . That or another way (by domain, or url path) it's tenant related, so it can be a method of tenant. But overwriting/monkeypatching django resolve should stay on shoulders each developer, we can write how to do that at docs and docstrings. Especially that it's different from lib to lib, as DRF has to be mokeypatched separately.

Thanks for your input @kosz85. This sounds like a great idea! I'd like to implement your suggestion. 👍


Force insert at a given key

Is it possible to forcibly insert a value at a given key? Either by allocating up to a given key, inserting into a vacant entry, or evicting a already occupied one. I'm in a situation where I need to keep multiple slabs and keep the same key between all of them. Would the bookkeeping make this prohibitively expensive?

The cost of that would be linear time. The slab stores the list of unused indexes by threading a linked list through the slab. Removing something from that linked list requires traversing the entire linked list to find the position that comes before it.

An alternative solution to this pattern is to have one slab, used to determine the index and maintain a freelist, and maintain Vec<Option<T>>s on the side that share the same indexes.


[bug] pynb-dag-runner dev-container: pip install -e fails

check that jupyter works

[ ] in mnist-demo pipeline repo
[ ] in pynb-dag-runner repo


Prepare demand

What existing problem does the pull request solve and why should we include it?

Added step _consolidate_demand_for_assign() in household.py to prepare ctramp demand into the format assignment expects, while retaining the trip tables from each global iteration
Fixed a bug in highway maz auto assignment, on MAZ index miss-match between the trip table (full size MAZs) and the highway network MAZ nodes (missing 5 disconnected MAZs - https://app.asana.com/0/12291104512575/1199091221400653/f)

What is the testing plan?
Demonstrate the code is solid by discussing how results are verified and covered by tests

[ ] Code for this PR is covered in tests
[ ] Code passes all existing tests

Code formatting
Code should be PEP8 compliant before merging by running a package like black

[ ] Code linted

Applicable Issues
Issues List

closes...
closes...

Ran tm2py successfully with 3-global iterations. Run time is uploaded to Box.


Overlapping Elements in Player Destruction Game Mode

During the "Waiting for Players" period on Player Destruction Maps, the _budhud folder hudmatchstatus.res ObjectiveStatusTimePanel element, hudobjectivetimepanel.res WaitingForPlayersLabel element, and the hudobjectiveplayerdestruction.res CountdownContainer element overlap with each other.

It's fine during the round.

During Player Destruction rounds, the _tf2hud folder hudobjectiveplayerdestruction.res CarriedContainer element overlaps with the _budhud folder disguisestatuspanel.res bh_DisguisePin element.

Should be a simple fix. I just don't know how you'd want the elements to reposition.
If you want to, maybe consider adding the CarriedContainer element into the _budhud folder hudobjectiveplayerdestruction.res and edit it to look like budhud's MVM money counters. I don't know if it's possible to make it look exactly like the counter in MVM. It's just that in the default HUD, they look very similar. Of course, you don't have to do this. There are other avenues to making it fit the budhud style, and it's not like its current design isn't already functional.

Yeahhh I had a feeling it would overlap with something like that when I moved it back lmao. What I may do is just remove the background and then move it down below where the "respawn time" message appears. I think I'd need to remove the background just because it's going to have to move so far down that it might become a distraction.
For the other thing you pointed out, I'll take a look and see what I can do.

not the hugest fan but i honestly may just stick with doing this lmao. I don't really like the alternatives

Couldn't the image next to the number be made a bit smaller? I think it would look better that way.

I could shrink it up a bit, or move it down there. Although shrinking it overall would probably be better


Fix spelling of 'inputed'

Changed spelling of 'inputed' for 'Add Placeholder Text to a Text Field' to 'input.'
Closes #6787

:+1:


change in CSS in style.css

The guidelines specifically state that there should be no changes to the home page. Do not become discouraged and raise a new issue.


ping reply in python3 broken

no ping replies are sent

all send is broken? just ping.py works...


Freegeoip Deprecations

First off, thanks for this great project!!
Secondly, has there been any work done to handle the Important Announcement section which was outlined on the freegeoip github page https://github.com/apilayer/freegeoip/?  Most importantly that an api key will now be required, to use the service.
Since freegeoip is the default IP lookup strategy, I just wanted to see if this was on the radar to be upgraded, or if I just missed a solution that allows to me to add my api_key.

@mc962 I am working on a PR for this, but it is slow going as I am only able to give it a few hours a week.

I think a post-install message would be good, as well as a deprecation notice when using the freegeoip lookup (maybe allow it to accept an option to silence the log message for it for those that don't care).
I think there can't be too many places to let people know they are using deprecated services.
Were you planning on changing the name of freegeoip / adding a new service in it's place? My understanding is that ipstack is taking over the freegeoip project, and so it would probably be more accurate to use their name  for the service (although it would break some compatibility).

Yeah I think a new service would be the best option, as the api is now capable of returning better errors, and response codes.

Sorry for the slow reply @Heath101, and thanks for working on this. I think a post-install message would be good (explaining that :freegeoip is deprecated and will be discontinued on July 1st, 2018), and maybe showing the same warning whenever the lookup is loaded. After July 1st, we'll just remove :freegeoip entirely. Thanks!

@alexreisner I should have PR for this in the next couple of days.

@alexreisner I'm not sure where the best place is to put the warning for when the lookup is loaded.  Are you thinking just in the actual lib/geocoder/lookups/freegeoip.rb file itself (maybe right under the require statements), such that when the lookup spawn method dynamically requires in this file it will log out the warning just once?  Or are you thinking whenever a Geocoder::Lookup::Freegeoip is instantiated?  Seems like that would be really verbose, but it may be more appropriate for this warning to be super chatty, so that it gets noticed/fixed.

I'm actually going to submit a PR for this without the warning ( it will include the post install message ).  We can continue this discussion on the PR comments I think.


Consume reusable linting workflow

part of: https://github.com/kairos-io/kairos/issues/1234

The hadolint errors were there before but the earthly target has a mistake and didn't catch them. There are legitimate issues we should fix.

I'm not sure I agree with the hadolint suggestions:
./images/Dockerfile.opensuse-leap-arm-rpi:9 DL3037 warning: Specify version with `zypper install -y <package>=<version>`.

from here. As far as I know, not every version is available for installation at any given image. It's the responsibility of the distribution to include package versions that "work". I understand builds should be reproducible but I'm not sure pinning the version of every package is doable.

I created a .hadolint.yaml file to assign them the severity "info" and then ignore them (not fail on them).


Improvement for k8s.io/docs/tasks/administer-cluster/kubeadm/

I think this section should start with kubeadm init and kubeadm join

Link: https://kubernetes.io/docs/tasks/administer-cluster/kubeadm/

If you are interested in learning about setting up a cluster, you may want to check https://kubernetes.io/docs/reference/setup-tools/kubeadm/. The page you mentioned is about administration tasks that are for day2 operations.
/close


fix: Some NFT's floor price feature on mass-listing cart does not work

Thank you for your contribution to the KodaDot - One Stop Shop for Polkadot NFTs.
👇 __ Let's make a quick check before the contribution.
PR Type

[x] Bugfix
[ ] Feature
[ ] Refactoring

Context

[x] Closes #7223

Did your issue had any of the "$" label on it?

[x] Fill up your DOT address: Payout

Community participation

[x] Are you at KodaDot Discord?

Screenshot 📸

[x] My fix has changed something on UI;

Copilot Summary

🤖 Generated by Copilot at 5b7ebe0
This pull request adds a feature to disable listing buttons for collections without a floor price, and fixes a bug in useCollectionDetails that caused an error for empty collections.

🤖 Generated by Copilot at 5b7ebe0

useCollectionDetails
Fixes bug with empty list
No error in fall

works for me, nice job

@hassnian
i think in this case below, complete listing button should be deactivated until you type a listing price for the 0 floor collection, wdyt?

😍 Perfect, I’ve sent the payout
💵 $30 @ 4.01 USD/DOT ~ 7.481 $DOT
🧗 13QUj3pZyFNfYj4AM336hRdyLQbevj5H3sR4PKmLEXLdwZhh
🔗 0xd8a9ae4770b0810d9cddf77c7a7c8e9316df8daeb0f6be3d1fef1a19afd1d2ea
🪅 Let’s grab another issue and get rewarded!
🪄 github.com/kodadot/nft-gallery/issues


feat: Indices classes

Created a new LocalIndex class in the local_index.py module. and defined an associated base (placeholder) class. Local indices used to be defined and used in the RouteLayer.

Could we also rename indices to index — see MS style guide

@Siraj-Aizlewood seems good so far, let's get Pinecone added as an index before we merge so we can see more easily find anything that should be modified
Also, could we rename remove to delete? Aligns better with numpy, pinecone, and others — thanks!

Just noting that this has been done.

Could we also rename indices to index — see MS style guide
because there is likely to be confusion whether we use indexes or indices we should stick with the singular form

Ah cool yeah will stick to indices for maths!
Also good to know that we generally try and keep singular form for module/folder names. Should be consider changing the folders: encoders, llms, splitters and utils to singular too?

Could we also rename indices to index — see MS style guide
because there is likely to be confusion whether we use indexes or indices we should stick with the singular form

Ah cool yeah will stick to indices for maths!
Also good to know that we generally try and keep singular form for module/folder names. Should be consider changing the folders: encoders, llms, splitters and utils to singular too?

We can keep plural for the others for now, went with singular solely due to easy confusion between different forms of indexes or indices

Cool no worries @jamescalam !

closing for #146


Get maintenance page showing up when backends are down

https://alonetone.com/maint.html shows up now when rails is down.
However, there's problems with the height of the image, it doesn't adjust. I spent 30 min trying to figure it out, I'm guessing maybe some raw js is going to be needed. Maybe @ofsound has ideas


is there a way to tweak the yellow color?

Hello,
First of all thank you so much for this awesome theme!  I recently starting using React and I noticed that in my React files there is a lot of yellow coloring for the parens and the corchet-brackets (see the screenshot).  Maybe it's because my monitors are shoddy, but I'm
having a hard time seeing it (contrast issues with the white background).  Is there any way to tweak this yellow color in VS Code?
Thank you in advance!

Btw I read the color theme documentation that you linked to, however, I couldn't figure out how to change this particular yellow coloring...

Thank you for reporting this issue @mattdimicelli. Could you try the latest version (0.0.10) I just published and let me know if you still see the issue?
Here is a sample screenshot:

https://marketplace.visualstudio.com/items?itemName=wassimdev.windows-nt-vscode-theme

Hi manekinekko,
Thank you for following up and for the update!  Yes, it still looks very nice and it is now much easier for me to see those characters!

Thank you and have a great weekend


Change round fields in housemeasure tables

See https://github.com/averbraeck/housinggame-common/issues/28

Fields used_in_round and bought_in_round are available:


dotnet-sdk_8: 8.0.203 -> 8.0.204

Automatic update generated by nixpkgs-update tools. This update was made based on information from passthru.updateScript.
meta.description for dotnet-sdk_8 is: .NET SDK 8.0.204
meta.homepage for dotnet-sdk_8 is: https://dotnet.github.io/
Updates performed

Ran passthru.UpdateScript

To inspect upstream changes
Impact
Checks done

built on NixOS
The tests defined in passthru.tests, if any, passed
found 8.0.204 with grep in /nix/store/73ryd5mbqlk93i132fjgdh9hapjikvla-dotnet-sdk-8.0.204
found 8.0.204 in filename of file in /nix/store/73ryd5mbqlk93i132fjgdh9hapjikvla-dotnet-sdk-8.0.204

Rebuild report (if merged into master) (click to expand)

38 total rebuild path(s)

38 package rebuild(s)

First fifty rebuilds by attrpath
ArchiSteamFarm
bicep
btcpayserver
btcpayserver-altcoins
cavalier
celeste64
csharp-ls
csharprepl
denaro
discordchatexporter-cli
dotnet-aspnetcore_8
dotnet-outdated
dotnet-runtime_8
dotnet-sdk_8
dotnetCorePackages.aspnetcore_8_0
dotnetCorePackages.dotnet_8.aspnetcore
dotnetCorePackages.dotnet_8.runtime
dotnetCorePackages.dotnet_8.sdk
dotnetCorePackages.dotnet_8.vmr
dotnetCorePackages.runtime_8_0
dotnetCorePackages.sdk_8_0
dotnetCorePackages.sdk_8_0_1xx
dotnetCorePackages.sdk_8_0_2xx
garnet
kavita
libation
lubelogger
marksman
mqttmultimeter
naps2
nbxplorer
omnisharp-roslyn
osu-lazer
parabolic
roslyn-ls
ryujinx
space-station-14-launcher
technitium-dns-server

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/73ryd5mbqlk93i132fjgdh9hapjikvla-dotnet-sdk-8.0.204 \
  --option binary-caches 'https://cache.nixos.org/ https://nix-community.cachix.org/' \
  --option trusted-public-keys '
  nix-community.cachix.org-1:mB9FSh9qf2dCimDSUo8Zy7bkq5CX+/rkCWyvRCYg3Fs=
  cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY=
  '

(The Cachix cache is only trusted for this store-path realization.)
For the Cachix download to work, your user must be in the trusted-users list or you can use sudo since root is effectively trusted.
Or, build yourself:
nix-build -A dotnet-sdk_8 https://github.com/r-ryantm/nixpkgs/archive/6a2b014f05f66fc483506cf34dd11fbb430634a5.tar.gz

Or:
nix build github:r-ryantm/nixpkgs/6a2b014f05f66fc483506cf34dd11fbb430634a5#dotnet-sdk_8

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/73ryd5mbqlk93i132fjgdh9hapjikvla-dotnet-sdk-8.0.204
ls -la /nix/store/73ryd5mbqlk93i132fjgdh9hapjikvla-dotnet-sdk-8.0.204/bin

Pre-merge build results
We have automatically built all packages that will get rebuilt due to
this change.
This gives evidence on whether the upgrade will break dependent packages.
Note sometimes packages show up as failed to build independent of the
change, simply because they are already broken on the target branch.
nixpkgs-review took longer than 120m and timed out

Maintainer pings
cc @kuznero @mdarocha for testing.

@ofborg eval


fix TypeError

fix TypeError: Object.keys called on non-object when paginate or dto
options are used
Fixes #49

A test for this still needs to be written but I am unsure of where to put it.

The tests for this file will be done later, when we break down the main file (work on that should be done soon I hope).


Selecting a country on 'Add to a place' spins forwver

eg adding US to http://www.inaturalist.org/taxa/silverleaf_whitefly

Looks like this is working now. Would you mind checking when you get a chance?

I'm going to call this fixed. Please give an example if anyone disagrees

Yes just tested this it's fixed, thanks


Add P2Pdoc

What kind of PR is this?
Select only one to speed up review/approval; i.e., don't lump an addition and a removal into a single PR.

[x] Adding something new to awesome-ipfs
[ ] Editing something already listed on awesome-ipfs
[ ] Removing something from awesome-ipfs
[ ] Something else (if so, please explain in the "Additional details" section below)

Pre-submit checklist
Please confirm ALL of the following before submitting your PR.

[x] This PR includes only one addition, removal, or edit.
[x] I edited the /data directory instead of the README.md.
[x] I reviewed the content policy and the and the IPFS Community Code of Conduct to ensure my submission meets the requirements.
[x] I have followed the CONTRIBUTING.md guidelines.

Additional details
Is there anything else we should know about this PR?

No.
For new additions: What is your project's current size/reach?

I don't know.
For new additions: What is your project's potential size/reach?

I don't know.
For new additions: How critical is IPFS to your project?

[x] Essential
[ ] Somewhat critical
[ ] Useful, but not critical

For new additions: What core goal(s) does your project address?

[ ] Big-data solutions
[x] Freedom from corporate/government interference
[ ] Data integrity
[ ] Dev tools or other ways to enable developers
[ ] Disaster resilience/recovery
[ ] File storage/retrieval
[ ] File streaming
[ ] Permanent archiving
[ ] Self-sovereign identity
[ ] Platforms that utilize consensus, reputation, or incentivization
[x] Other (please list)

Publishing writting to IPFS.
Is anything about IPFS blocking your project?

No.

Thanks!


generate dot graph visualizations for authorization models

Given an authorization model *openfgapb.AuthorizationModel generate a dot graph representing the direct and indirect edges in the graph of relationships.
In our graph package we can parse the model and export a digraph structure using https://github.com/emicklei/dot, for example:
package graph

import (
  ...
  "github.com/emicklei/dot"
)

// ToDigraph processes the provided authorization model and produces a directed-acyclic graph (digraph)
// in graphviz DOT format.
func ToDigraph(model *openfgapb.AuthorizationModel) (*dot.Graph, error) {
    digraph := dot.NewGraph(dot.Directed)
    // todo: construct the digraph from the model

    return digraph, nil
}

Then we can use the Digraph structure and print it out and run it through https://dot-to-ascii.ggerganov.com/ . For example,
input
digraph {

    "document editor" -> "user";
    "document editor" -> "group member";
    "document viewer" -> "document editor";
    "document viewer" -> "group member";
    "group member" -> "user";
    "group member" -> "group member";
}

output
     +-----------------+
     | document viewer | -+
     +-----------------+  |
       |                  |
       |                  |
       v                  |
     +-----------------+  |
  +- | document editor |  |
  |  +-----------------+  |
  |    |                  |
  |    |                  |
  |    v                  |
  |  +-----------------+  |
  |  |  group member   | <+
  |  +-----------------+
  |    |
  |    |
  |    v
  |  +-----------------+
  +> |      user       |
     +-----------------+

Working on this a bit on the side. Check out what I have so far
https://github.com/jon-whit/openfga-graphviz-gen

Closing since we have been working on https://github.com/jon-whit/openfga-graphviz-gen


[helm-chart] Add helm-docs to the helm chart workflow

Increment the version in the charts/garnet/Chart.yaml file
we only trigger the github workflow on a commit on charts/garnet/Chart.yaml.

If the version is updated, a new helm chart package will be built/pushed and a new PR is created to update the README.md.
If only another thing is updated (ie. contributors, icon, home ...), the allready existing helm-chart with the same version is overwrited and a new PR is created to update the README.md.

@babykart, this PR is having a action failure:


1.06 patch broke IshinFix

Hi,
The latest update - patch 1.06 - broke IshinFix. The game will crash during the warning intro screen. I removed IshinFix and the game booted up fine again.

Can confirm that I'm getting that crashing too on 1.06. It doesn't actually appear to be an issue with IshinFix but rather with the ASI loader. If you delete IshinFix.asi, you'll still get crashing on startup. I'll need to look in to this further.

Okay looks like adding winmm.ini with these contents will fix the crashing. I'll add this file to the latest release.
[GlobalSets]
DontLoadFromDllMain=0

Yup, the game boots up fine now. Thanks for the quick fix!

Downloading the latest release worked for me! Thank you!


[Bug]: TypeError: Cannot read properties of undefined (reading 'set') in react-refresh-webpack-plugin

System Info
System:
OS: macOS 14.2
CPU: (10) arm64 Apple M1 Pro
Memory: 344.97 MB / 32.00 GB
Shell: 5.9 - /bin/zsh
Binaries:
Node: 20.10.0 - ~/Library/Caches/fnm_multishells/25528_1712483917618/bin/node
Yarn: 1.22.18 - /opt/homebrew/bin/yarn
npm: 8.19.2 - ~/Projects/autodesk/acs-sc-web-platform/node_modules/.bin/npm
pnpm: 8.3.1 - ~/Library/pnpm/pnpm
bun: 1.0.0 - ~/.bun/bin/bun
Watchman: 2<IP_ADDRESS> - /opt/homebrew/bin/watchman
Browsers:
Chrome: 123.0.6312.107
Edge: 123.0.2420.81
Safari: 17.2
Packages:
"@module-federation/enhanced": "^0.1.2"
"@pmmmwh/react-refresh-webpack-plugin": "^0.5.11"
"@rsbuild/core": "^0.5.8"
"@rspack/core": "^0.5.9"
Details
Description
While running the application, I encountered an unexpected TypeError. Here are the details:
Command: rsbuild dev --open
Expected Result: No crash and react hmr support
Actual Result: Application crashes with a TypeError
Error Message:
<e> [webpack-dev-middleware] [Error:   × TypeError: Cannot read properties of undefined (reading 'set')
<e>   │     at Object.fn (/Users/x/Projects/autodesk/acs-sc-web-platform/node_modules/@pmmmwh/react-refresh-webpack-plugin/lib/index.js:309:47)
<e>   │     at SyncHook.callAsyncStageRange (/Users/x/Projects/autodesk/acs-sc-web-platform/node_modules/@rspack/core/dist/lite-tapable/index.js:215:21)
<e>   │     at SyncHook.callStageRange (/Users/x/Projects/autodesk/acs-sc-web-platform/node_modules/@rspack/core/dist/lite-tapable/index.js:233:14)
<e>   │     at QueriedHook.call (/Users/x/Projects/autodesk/acs-sc-web-platform/node_modules/@rspack/core/dist/lite-tapable/index.js:194:26)
<e>   │     at /Users/x/Projects/autodesk/acs-sc-web-platform/node_modules/@rspack/core/dist/Compiler.js:524:244
<e>   │     at last.function (/Users/x/Projects/autodesk/acs-sc-web-platform/node_modules/@rspack/core/dist/Compiler.js:685:28)
<e>   │
<e> ] {
<e>   code: 'GenericFailure'
<e> }

Reproduce link
No response
Reproduce Steps
Add the plugin to the webpack config:
 this.compiler.options.plugins.push(new ReactRefreshPlugin());

@hardfist I have an idea: add something like unsupported() (like todo!() in rust but works in runtime) to emit warnings for unsupported hooks and APIs, this can also detect which plugin we already supported

@hardfist I have an idea: add something like unsupported() (like todo!() in rust but works in runtime) to emit warnings for unsupported hooks and APIs, this can also help to detect which plugin we already supported

good idea，it helps for public api


Scan Results

Would this report allow us to pull scan results - particularly files with errors?

Thank you for submitting feedback.
I think the best way forward is if you open a service ticket in your tenant so this can get resolved ASAP. Based on the outcome let me know if it is something that can be called out in the docs.
Please follow this link to contact support for business products:https://docs.microsoft.com/office365/admin/contact-support-for-business-products
Please keep us posted here on the resolution so we can feed whatever information you discover into the content.


Fix USB-Serial stdin

Raspberry Pi Pico is fully able to write data to stdout which is displaying correctly in Serial Monitoring software.
Pico is entirely unresponsive to stdin reads (tested only with scanf()). The scanf() function is a blocking function and should not be used with our final product. It is possible that the blocking nature of scanf() is why stdin over serial is nonfunctional; however, this issue may have an underlying issue related to the USB-Serial driver, CMakeLists.txt file, and/or Windows operating system.

The scanf() function is now functional, the issue was caused by some minor oversights previously.
However, input is not echoed to the user over serial. As in 3ff94210a5995502d25daffff92ace69a9deb647, we can scan individual characters from stdin and manually collect them into a character array, but we need a maximum buffer size.
Thinking 1500 bytes to remain consistent with TCP standard MTU. This would only be the data portion of the transmission, and would exclude any header bytes we might choose to add (awaiting #11).

Investigating https://github.com/raspberrypi/pico-sdk/issues/1603


Migration Permanent Exception Error

this does not work, i spent time setting up the PowerShell parts witch eventual worked after updated discontinued commands
but the actual migration part fails with one of the two below errors

MigrationPermanentException: Target user 'USER' already has a primary mailbox. --> Target user 'USER' already has a primary mailbox.

MigrationRecipientNotFoundException: A recipient wasn't found for "USER" on the target. Create a recipient of the appropriate type for this migration on the target and try again.

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

ID: c61c960c-f5c3-76f7-ac18-dfeaf30230e4
Version Independent ID: 3dc607b2-869e-976f-80da-d73cfb1210e5
Content: Cross-tenant mailbox migration - Microsoft 365 Enterprise
Content Source: microsoft-365/enterprise/cross-tenant-mailbox-migration.md
Product: microsoft-365-enterprise
GitHub Login: @kelleyvice-msft
Microsoft Alias: kvice

@karmicsynergy Thank you for your feedback. I'm currently testing this and will update the document if need be.

@karmicsynergy Thank you for your feedback. Sorry about the delay, I was able to test the scripts and migrate using my lab tenant. If this continues to be an issue, please contact Microsoft support via the need help option in the M365 admin center.
Thanks
Sri

@msbemba Thank you very much for the contribution and sharing this explanation. @karmicsynergy Hope this comment is helpful for you. If you see a documentation update is required, please feel free to open an issue for the same. We proceed here to close it. Thanks for taking out some time to open the issue. Appreciate and encourage you to do the same in future also.


CORE-19976 Prevent components from being marked as 'DOWN' instead of 'ERROR'

Addresses an issue where a subscription, on encountering a fatal exception, causes the coordinator to transition to 'DOWN'. This leaves the component marked as 'DOWN' instead of 'ERROR', which means it will not be restarted by K8s.

This has been identified as a problem in 5.2 when turning on kafka resiliency tests. We should patch this.


[FLINK-4656] [rpc] Port the existing code to Flink's own future abstraction

This pull request removes Scala's Futures from all new Flip-6 components and replaces them with Flink's own Future abstraction.

Will merge the PR since it's prone to merge conflicts.


[README.md] fix: French translation of CoC title

What does this PR do?
Improve repo
For resources
README.md
Description
Fix of wrong and inconsistant French translation of conduct word in README.md document.

Thanks, and welcome to free-programming-books!


fixes hook amd presubmit to use proper env var

Issue #, if available:
Description of changes:
When I added the arm build I copied the env var from other presubmit jobs.  The one we were using is wrong, we changed at one point and never updated these jobs.  The actual env var is, FAKE_ARM_BINARIES_FOR_VALIDATION, per https://github.com/aws/eks-anywhere-build-tooling/blob/main/Common.mk#L452.  We do not to usually set it because its auto set based on the binary_platforms
The hook build is a bit different because I left the amd build building both binary platforms, because it can, most of the other examples cannot because they are cross compiling use CGO.  I left it this way so that checksum updates is a bit easier. So for this presubmit I am going to set the fake explicitly.
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

/lgtm
/approve


Activating Open Collective

Hi, I'm making updates for Open Collective. Either you or a supporter signed this repo up for Open Collective. This pull request adds backers and sponsors from your Open Collective https://opencollective.com/celluloid ❤
It adds two badges at the top to show the latest number of backers and sponsors. It also adds placeholders so that the avatar/logo of new backers/sponsors can automatically be shown without having to update your README.md. [more info]. See how it looks on this repo.
You can also add a "Donate" button to your website and automatically show your backers and sponsors there with our widgets. Have a look here: https://opencollective.com/widgets
P.S: As with any pull request, feel free to comment or suggest changes. The only thing "required" are the placeholders on the README because we believe it's important to acknowledge the people in your community that are contributing (financially or with code!).
Thank you for your great contribution to the open source community. You are awesome! 🙌
And welcome to the open collective community! 😊
Come chat with us in the #opensource channel on https://slack.opencollective.com - great place to ask questions and share best practices with other open source sustainers!

Thank you @monkeywithacupcake!
I've established an Open Collective foundation affiliation for Celluloid in anticipation of the future. We're all a bit tied up at the moment though, so will need some time to react to this and start proactively working through Open Collective.

@monkeywithacupcake I forgot about this PR, my bad. Then I added the sponsorship linkage. If you get a chance, could you please rebase this? Otherwise will come back to this; thanks for the start here.

Are we still using open collective?


Is it possible to use Drag and Drop together with CAB?

Is it possible to use Drag and Drop together with CAB? Like the google app Keep or google drive?
In case a press and hold would enable drag and drop and the CAB, once I drag the item to another position, the CAB would disapear.

@hsdmiranda yes this should be possible. as you can control both features independent from each other.


Bluetooth: Mesh: Fixes Same appkey add to multi netkey

The latest MESH.TS <IP_ADDRESS> 4.15.10 Appkey List Procedures
MESH/NODE/CFG/AKL/BI-04-C
Verify that the IUT can respond to an Config AppKey Add
message with NetKeyIndex and AppKeyIndex already stored.

Repeat step 1 with the same AppKey, the same
AppKeyIndex, but NetKeyIndex field set to 0x001.

The Lower Tester expects the IUT to respond
with an Config AppKey Status message with the
Status field set to 0x04 (Invalid NetKey) and
the NetKeyIndex and AppKeyIndex values equal to
those sent in step 5.

Signed-off-by: Lingao Meng<EMAIL_ADDRESS>

@LingaoM Did you test it with PTS? If yes - which version?

yeap, 8.0.3

I guess this change is not enough. Description of returned statuses is not relevant anymore.
https://github.com/zephyrproject-rtos/zephyr/blob/main/include/bluetooth/mesh/cfg.h#L394
Should be fixed.


[Docs] update How to 6, path annotator

Closes https://github.com/napari-threedee/napari-threedee/issues/210
In this PR I have:

removed the unused, but potentially confusing spline_annotator_plugin.py script
renamed the How to to use path instead of spline and updated the toc.
These changes match the name of the widget in the Plugins > napari-threedee menu.
Then, I updated the copy of the How to: (note the diff shows this as a new file, but it's a rename and update in place)
clarify download/run of the script
update the layer names
clarify the behavior for adding new paths, using the n key and selecting paths using the Points layer.

Note for this one, the widget is different because it no longer has a advance index. It might be worth redoing the videos?

@kevinyamauchi

Note for this one, the widget is different because it no longer has a advance index. It might be worth redoing the videos?

What do you think?

I updated the download and activate wording based on the suggestions from the other PR(s).


Trouble with installing DPViewer

I get the same thing:
CMake Error at /home/colab/anaconda3/envs/dpvo/lib/python3.10/site-packages/cmake/data/share/cmake-3.22/Modules/CMakeTestCUDACompiler.cmake:56 (message):
The CUDA compiler
      "/usr/bin/nvcc"

    is not able to compile a simple test program.

    It fails with the following output:

      Change Dir: /home/colab/code/DPVO/DPViewer/build/temp.linux-x86_64-3.10/CMakeFiles/CMakeTmp

      Run Build Command(s):/usr/bin/gmake -f Makefile cmTC_e03e9/fast && /usr/bin/gmake  -f CMakeFiles/cmTC_e03e9.dir/build.make CMakeFiles/cmTC_e03e9.dir/build
      gmake[1]: Entering directory '/home/colab/code/DPVO/DPViewer/build/temp.linux-x86_64-3.10/CMakeFiles/CMakeTmp'
      Building CUDA object CMakeFiles/cmTC_e03e9.dir/main.cu.o
      /usr/bin/nvcc      -c /home/colab/code/DPVO/DPViewer/build/temp.linux-x86_64-3.10/CMakeFiles/CMakeTmp/main.cu -o CMakeFiles/cmTC_e03e9.dir/main.cu.o
      ptxas /tmp/tmpxft_0024e7e0_00000000-6_main.ptx, line 9; fatal   : Unsupported .version 8.2; current version is '7.7'
      ptxas fatal   : Ptx assembly aborted due to errors
      gmake[1]: *** [CMakeFiles/cmTC_e03e9.dir/build.make:78: CMakeFiles/cmTC_e03e9.dir/main.cu.o] Error 255
      gmake[1]: Leaving directory '/home/colab/code/DPVO/DPViewer/build/temp.linux-x86_64-3.10/CMakeFiles/CMakeTmp'
      gmake: *** [Makefile:127: cmTC_e03e9/fast] Error 2

Something about ptx wanting version 8.2 ptx?


Cover more test/widgets tests with leak tracking

Description
This PR changes testWidgets by testWidgetsWithLeakTracking in number of flutter/test/widgets tests according to the https://github.com/dart-lang/leak_tracker/issues/134.
Marks leaks

https://github.com/flutter/flutter/issues/134572
https://github.com/flutter/flutter/issues/134575

Tests

Updates form_test.dart to use testWidgetsWithLeakTracking;
Updates fractionally_sized_box_test.dart to use testWidgetsWithLeakTracking;
Updates framework_test.dart to use testWidgetsWithLeakTracking;
Updates gesture_detector_semantics_test.dart to use testWidgetsWithLeakTracking;
Updates gesture_detector_test.dart to use testWidgetsWithLeakTracking;
Updates gesture_disambiguation_test.dart to use testWidgetsWithLeakTracking;
Updates global_keys_duplicated_test.dart to use testWidgetsWithLeakTracking;
Updates global_keys_moving_test.dart to use testWidgetsWithLeakTracking;
Updates grid_paper_test.dart to use testWidgetsWithLeakTracking;
Updates grid_view_layout_test.dart to use testWidgetsWithLeakTracking;
Updates grid_view_test.dart to use testWidgetsWithLeakTracking;
Updates heroes_test.dart to use testWidgetsWithLeakTracking;
Updates hit_testing_test.dart to use testWidgetsWithLeakTracking;
Updates hyperlink_test.dart to use testWidgetsWithLeakTracking;
Updates icon_test.dart to use testWidgetsWithLeakTracking;
Updates image_filter_quality_test.dart to use testWidgetsWithLeakTracking;
Updates image_filter_test.dart to use testWidgetsWithLeakTracking;
Updates image_headers_test.dart to use testWidgetsWithLeakTracking;
Updates image_icon_test.dart to use testWidgetsWithLeakTracking;
Updates image_resolution_test.dart to use testWidgetsWithLeakTracking;
Updates image_rtl_test.dart to use testWidgetsWithLeakTracking.

Pre-launch Checklist

[X] I read the [Contributor Guide] and followed the process outlined there for submitting PRs.
[X] I read the [Tree Hygiene] wiki page, which explains my responsibilities.
[X] I read and followed the [Flutter Style Guide], including [Features we expect every widget to implement].
[X] I signed the [CLA].
[X] I listed at least one issue that this PR fixes in the description above.
[ ] I updated/added relevant documentation (doc comments with ///).
[X] I added new tests to check the change I am making, or this PR is [test-exempt].
[X] All existing and new tests are passing.

cc @polina-c

@polina-c thanks for the review.

@polina-c, what to do if it happens that there is the same leak in a couple of testWidgetsWithLeakTracking?
Do I need to mark the leak in only one of them and revert all others to the testWidgets, or do I need to mark all the tests?

@polina-c, what to do if it happens that there is the same leak in a couple of testWidgetsWithLeakTracking? Do I need to mark the leak in only one of them and revert all others to the testWidgets, or do I need to mark all the tests?

Thanks for asking. I will add answer to top description of the main issue. Let's convert just one test. It will be enough for issue resolution. When we have too much issues, we need to stop conversion and fix them, before going forward.

@polina-c, what to do if it happens that there is the same leak in a couple of testWidgetsWithLeakTracking? Do I need to mark the leak in only one of them and revert all others to the testWidgets, or do I need to mark all the tests?

Thanks for asking. I will add answer to top description of the main issue. Let's convert just one test. It will be enough for issue resolution. When we have too many issues, we need to stop conversion and fix them, before going forward.

Thanks a lot for the answer and review!


React site information 1.16.1: Upgraded PnP JS to 3.11.0

Category

[ ] Bug Fix
[x] New Feature
Related issues: fixes #X, partially #Y, mentioned in #Z

What's in this Pull Request?
React site information 1.16.1: Upgraded PnP JS to 3.11.0

Closing this and will create another PR.


[Backport-1.x] Upgrading commons-codec in hdfs-fixture and cleaning up dependencies …

…in repository-hdfs (#1603)
Signed-off-by: Vacha<EMAIL_ADDRESS>Description
Backport of #1603
Issues Resolved
[List any issues this PR will resolve]
Check List

[ ] New functionality includes testing.

[ ] All tests pass

[ ] New functionality has been documented.

[ ] New functionality has javadoc added

[X] Commits are signed per the DCO using --signoff

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

WhiteSource integration issue #1593


Kernel not created with the name python38364bit

Bug: Notebook Editor, Interactive Window, Editor cells

Steps to cause the bug to occur
1.open python file in vscode 1.46
2.open context menu and click 'Run current file in pytthon interactive window'
3.error occured with:
Kernel not created with the name python38364bitcd6122aef71d4519826b67f7226332d6, display_name Python 3.8.3 64-bit. Output is Installed kernelspec python38364bitcd6122aef71d4519826b67f7226332d6 in C:\Users\dell\AppData\Roaming\jupyter\kernels\python38364bitcd6122aef71d4519826b67f7226332d6
Actual behavior
Expected behavior

Your Jupyter and/or Python environment
Please provide as much info as you readily know

Jupyter server running: Local | Remote | N/A
Extension version: 20YY.MM.#####-xxx
VS Code version: #.##
Setting python.jediEnabled: true | false
Setting python.languageServer: Jedi | Microsoft | None
Python and/or Anaconda version: #.#.#
OS: Windows | Mac | Linux (distro):
Virtual environment: conda | venv | virtualenv | N/A | ...

Developer Tools Console Output

Microsoft Data Science for VS Code Engineering Team: @rchiodo, @IanMatthewHuff, @DavidKutu, @DonJayamanne, @greazer, @joyceerhl

Hey @acrobatman . Thanks for reporting this issue. It looks like a problem with creating and installing a kernelspec for your actively selected python interpreter. To help narrow this down, can you please repro the issue and when you do go to Help -> Toggle Developer Tools. In that window that pops up you can go the console tab, then you can right click on the console log and save that to a file and attach that file to a comment here. That log has our diagnostics output that can help me tell what's going on here.

console.ts:137 [Extension Host] Error Python Extension: 2020-06-17 12:38:39: Failed to get kernelspec from stdout [Error: KernelSpec file not found
at D.getKernelSpecFromStdOut (c:\Users\river.vscode\extensions\ms-python.python-2020.6.88468\out\client\extension.js:1:700632)
at runMicrotasks ()
at processTicksAndRejections (internal/process/task_queues.js:85:5)]
console.ts:137 [Extension Host] Error Python Extension: 2020-06-17 12:38:39: Failed to parse kernel creation stdout, Class name = D, completed in 2ms, has a falsy return value, Arg 1: "Installed kernelspec python38364bitenvvenv8829b410600649e9b641b69e925b7556 in C:\Users\river\AppData\Roaming\jupyter\kernels\python38364bitenvvenv8829b410600649e9b641b69e925b7556\r\n", Return Value: undefined [Error: KernelSpec file not found
at D.getKernelSpecFromStdOut (c:\Users\river.vscode\extensions\ms-python.python-2020.6.88468\out\client\extension.js:1:700632)
at runMicrotasks ()
at processTicksAndRejections (internal/process/task_queues.js:85:5)]
console.ts:137 [Extension Host] Error Python Extension: 2020-06-17 12:38:39: Failed to register an interpreter as a kernel, Class name = D, completed in 6526ms, has a falsy return value, Arg 1: {"architecture":3,"path":"c:\Users\river\src\nutmini-weeklyreport\env\Scripts\python.exe","version":{"options":{"loose":false,"includePrerelease":false},"loose":false,"raw":"3.8.3-final","major":3,"minor":8,"patch":3,"prerelease":["final"],"build":[],"version":"3.8.3-final"},"sysPrefix":"c:\Users\river\src\nutmini-weeklyreport\env","fileHash":"0204d438a5d16d4905f5b44024e085b2a9a3aa9577423799c74601283a2b95a2df188d7fc8da01a6294e4120f74322c64c37871310f026417912d48b22ddb7a6","envName":"env","type":"Venv","displayName":"Python 3.8.3 64-bit ('env': venv)"}, Arg 2: false, Arg 3: undefined, Return Value: undefined [Error: Kernel not created with the name python38364bitenvvenv8829b410600649e9b641b69e925b7556, display_name Python 3.8.3 64-bit ('env': venv). Output is Installed kernelspec python38364bitenvvenv8829b410600649e9b641b69e925b7556 in C:\Users\river\AppData\Roaming\jupyter\kernels\python38364bitenvvenv8829b410600649e9b641b69e925b7556
at D.registerKernel (c:\Users\river\.vscode\extensions\ms-python.python-2020.6.88468\out\client\extension.js:1:698243)
at runMicrotasks (<anonymous>)
at processTicksAndRejections (internal/process/task_queues.js:85:5)]

console.ts:137 [Extension Host] rejected promise not handled within 1 second: Error: Kernel not created with the name python38364bitenvvenv8829b410600649e9b641b69e925b7556, display_name Python 3.8.3 64-bit ('env': venv). Output is Installed kernelspec python38364bitenvvenv8829b410600649e9b641b69e925b7556 in C:\Users\river\AppData\Roaming\jupyter\kernels\python38364bitenvvenv8829b410600649e9b641b69e925b7556
console.ts:137 [Extension Host] stack trace: Error: Kernel not created with the name python38364bitenvvenv8829b410600649e9b641b69e925b7556, display_name Python 3.8.3 64-bit ('env': venv). Output is Installed kernelspec python38364bitenvvenv8829b410600649e9b641b69e925b7556 in C:\Users\river\AppData\Roaming\jupyter\kernels\python38364bitenvvenv8829b410600649e9b641b69e925b7556
at D.registerKernel (c:\Users\river\.vscode\extensions\ms-python.python-2020.6.88468\out\client\extension.js:1:698243)
at runMicrotasks (<anonymous>)
at processTicksAndRejections (internal/process/task_queues.js:85:5)

mainThreadExtensionService.ts:65 [[object Object]]Kernel not created with the name python38364bitenvvenv8829b410600649e9b641b69e925b7556, display_name Python 3.8.3 64-bit ('env': venv). Output is Installed kernelspec python38364bitenvvenv8829b410600649e9b641b69e925b7556 in C:\Users\river\AppData\Roaming\jupyter\kernels\python38364bitenvvenv8829b410600649e9b641b69e925b7556
mainThreadExtensionService.ts:66 Error: Kernel not created with the name python38364bitenvvenv8829b410600649e9b641b69e925b7556, display_name Python 3.8.3 64-bit ('env': venv). Output is Installed kernelspec python38364bitenvvenv8829b410600649e9b641b69e925b7556 in C:\Users\river\AppData\Roaming\jupyter\kernels\python38364bitenvvenv8829b410600649e9b641b69e925b7556
at D.registerKernel (c:\Users\river\.vscode\extensions\ms-python.python-2020.6.88468\out\client\extension.js:1:698243)
at runMicrotasks (<anonymous>)
at processTicksAndRejections (internal/process/task_queues.js:85:5)

-1592401595051.log
@IanMatthewHuff attachment is the log file,please check it.

Thanks for providing the log. At this location do you see a kernelspec.json file?

C:\Users\dell\AppData\Roaming\jupyter\kernels\python38364bitcd6122aef71d4519826b67f7226332d6

If so, what are the contents of that file?

Jupyter was running in venv, and there was no any files in that location.
获取 Outlook for iOShttps://aka.ms/o0ukef

发件人: Ian Huff<EMAIL_ADDRESS>发送时间: Thursday, June 18, 2020 12:24:51 AM
收件人: microsoft/vscode-python<EMAIL_ADDRESS>抄送: Shun Li<EMAIL_ADDRESS>Manual<EMAIL_ADDRESS>主题: Re: [microsoft/vscode-python] Kernel not created with the name python38364bit (#12346)
Thanks for providing the log. At this location do you see a kernelspec.json file?
C:\Users\dell\AppData\Roaming\jupyter\kernels\python38364bitcd6122aef71d4519826b67f7226332d6
If so, what are the contents of that file?
―
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHubhttps://github.com/microsoft/vscode-python/issues/12346#issuecomment-645462408, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AAEHQNR2VJLM4PXLW2FON2LRXDU5HANCNFSM4N5IAWGA.

Thanks for providing the log. At this location do you see a kernelspec.json file?

C:\Users\dell\AppData\Roaming\jupyter\kernels\python38364bitcd6122aef71d4519826b67f7226332d6

If so, what are the contents of that file?

This directory is not exist.
In fact, there is only C:\Users\dell\AppData\Roaming,  no  sub dir named jupyter.

This is a dupe of #11412


x64: improve generation of i128 icmp

Previously, we used the flags of AND for SETcc. This change uses
TEST instead, which discards the AND result but sets the flags needed
for SETcc. This reduces register pressure slightly for this sequence.

This is a follow-on improvement from #3886.


When initializing angular-froala with value associated to the model the undo button is active

I have the following code:
app.controller('rteController', function ($scope) {

                $scope.rteModel = "Hello world from AngularJS text area!";

                $scope.froalaOptionsRTE = {
                    height: 300,
                    width: 650,
                    inlineEdit: false,

                };
});

  <textarea id="area" froala="froalaOptionsRTE" ng-model="rteModel" ></textarea>

And when the page loads, the froala editor displays the undo button enabled.
If I press the undo button it clears the text.
Is it possible to change it to disable the undo button upon initialization? Or is this a bug?
Thanks.

@hiperlouro this is a side effect because of the way the html was set on initiation, this commit (fa0143fd0a1c3882fe45d897b5d14ce8ac80acf5) resolves this issue.

Thanks for the quick fix! :+1:


Add deprecation notice

Add @Deprecated and @deprecated (javadoc) to all artifacts.
We should also add "Deprecation Notice" throughout all documentation, eg. reference manual, project site, samples, etc.

You plan to deprecate everything, even though spring-security doesn't yet have feature parity?

@OrangeDog Yes, the sole purpose of 2.4.0 is to deprecate everything. We'll be announcing the details in a blog post same day as release this Thur Nov 14.


adopt kd-tree for data structure of node list

Currently, nodes are stored to std::vector, and the NN and NBHD search are implemented by linear search.
In high dimensional space, to solve effectively above problems, kd-tree is suitable data structure.
https://ieeexplore.ieee.org/document/4084578

I merged feature of simple kd-tree which rebuilds the tree when a depth of the tree exceeds 1 / certain ratio * log(size of tree).
https://github.com/kyk0910/sampling-based-planners/pull/2

It is probably better to implement a kd tree that is always in equilibrium.


Arabica light node fails to run

Celestia Node version
v.0.6.0
OS
Alpine image on Docker
Install tools
I created a docker container using this dockerfile.
FROM alpine:latest
FROM golang:1.19.1-alpine

EXPOSE 26659

COPY --from=golang:1.19.1-alpine /usr/local/go/ /usr/local/go/

ENV PATH="/usr/local/go/bin:${PATH}"

RUN apk update
RUN apk add curl tar wget clang pkgconfig libressl-dev jq alpine-sdk bash
RUN rm -rf celestia-node && git clone https://github.com/celestiaorg/celestia-node.git && cd celestia-node && git checkout tags/v0.6.0 && make install && make cel-key && celestia light init

Others
None
Steps to reproduce it
Init arabica
celestia light init --p2p.network arabica
celestia light start --p2p.network arabica

Run the light node using the command in the docs
celestia light start --core.ip https://limani.celestia-devops.dev --core.grpc.port 9090 --gateway --gateway.addr localhost --gateway.port 26659 --p2p.network arabica
Expected result
The light node should run as expected.
Actual result
/go # celestia light start --core.ip https://limani.celestia-devops.dev --core.grpc.port 9090 --gateway --gateway.addr localhost --gateway.port 26659 --p2p.network arabica
2022-12-17T15:02:44.451ZINFObadgerv2@v2.2007.4/levels.go:183All 0 tables opened in 0s

2022-12-17T15:02:44.453ZINFObadgerv2@v2.2007.4/value.go:1158Replaying file id: 0 at offset: 0

2022-12-17T15:02:44.453ZINFObadgerv2@v2.2007.4/value.go:1178Replay took: 28.375µs

2022/12/17 15:02:44 failed to sufficiently increase receive buffer size (was: 208 kiB, wanted: 2048 kiB, got: 416 kiB). See https://github.com/lucas-clemente/quic-go/wiki/UDP-Receive-Buffer-Size for details.
2022-12-17T15:02:44.466ZINFOmodule/statestate/keyring.go:69constructed keyring signer{"backend": "test", "path": "/root/.celestia-light-arabica-2/keys", "key name": "my_celes_key", "chain-id": "arabica-2"}
2022-12-17T15:02:44.466ZINFOmodule/headerheader/config.go:54No trusted peers in config, initializing with default bootstrappers as trusted peers
2022-12-17T15:02:44.469ZINFOheader/storestore/store.go:166loaded head{"height": 1, "hash": "04EE55B212745B88F29943D7B9528C415473A211F12EEF6E9333EF32E4DEAF3C"}
2022-12-17T15:02:44.469ZINFOheader/syncsync/sync_head.go:39subjective header expired{"height": 1}
2022-12-17T15:02:49.462ZINFObasichostbasic/natmgr.go:94DiscoverNAT error:no NAT found
2022-12-17T15:02:59.471ZERRORnodenodebuilder/node.go:95starting Light Node: OnStart hook added by go.uber.org/fx.(*lifecycleHookAnnotation).Build.func1 failed: context deadline exceeded

github.com/celestiaorg/celestia-node/nodebuilder/header.newInitStore.func1() took 656.792µs from:
github.com/celestiaorg/celestia-node/nodebuilder/header.newInitStore (/go/celestia-node/nodebuilder/header/constructors.go:91)
go.uber.org/fx.(*lifecycleHookAnnotation).Build.func1.1() took 46.291µs from:
go.uber.org/fx.(*lifecycleHookAnnotation).Build.func1 (/go/pkg/mod/go.uber.org/fx@v1.18.2/annotated.go:447)
github.com/celestiaorg/celestia-node/nodebuilder/header.newP2PExchange.func1.1() took 28.292µs from:
github.com/celestiaorg/celestia-node/nodebuilder/header.newP2PExchange.func1 (/go/celestia-node/nodebuilder/header/constructors.go:57)
go.uber.org/fx.(*lifecycleHookAnnotation).Build.func1.1() took 22.917µs from:
go.uber.org/fx.(*lifecycleHookAnnotation).Build.func1 (/go/pkg/mod/go.uber.org/fx@v1.18.2/annotated.go:447)
github.com/celestiaorg/celestia-node/fraud.(*ProofService).Start-fm() took 22.292µs from:
github.com/celestiaorg/celestia-node/nodebuilder/fraud.newFraudService.func1 (/go/celestia-node/nodebuilder/fraud/constructors.go:31)
github.com/celestiaorg/celestia-node/nodebuilder/p2p.PeerRouting.func1() took 792ns from:
github.com/celestiaorg/celestia-node/nodebuilder/p2p.PeerRouting (/go/celestia-node/nodebuilder/p2p/routing.go:43)

2022-12-17T15:02:59.471ZINFOheader/syncsync/sync_head.go:145new network head{"height": 99533, "hash": "BF133D1DA95EBE7567E29679EA0B0933FAED9C25FEC79C6986936D783303119D"}
2022-12-17T15:02:59.471ZWARNheader/syncsync/sync_head.go:55subjective initialization with an old header{"height": 99533}
2022-12-17T15:02:59.471ZWARNheader/syncsync/sync_head.go:57trusted peer is out of sync
2022-12-17T15:02:59.472ZERRORheader/p2pp2p/exchange.go:107head request to trusted peer failed{"trustedPeer": "12D3KooWHX8xpwg8qkP7kLKmKGtgZvmsopvgxc6Fwtu665QC7G8q", "err": "context deadline exceeded"}
2022-12-17T15:02:59.471ZERRORheader/p2pp2p/exchange.go:107head request to trusted peer failed{"trustedPeer": "12D3KooWHX8xpwg8qkP7kLKmKGtgZvmsopvgxc6Fwtu665QC7G8q", "err": "context deadline exceeded"}
2022-12-17T15:02:59.472ZINFObasichostbasic/basic_host.go:758error resolving /dns4/limani.celestia-devops.dev/tcp/2121/p2p/12D3KooWNpRWxpi1APzV6CnwHvdgNRuTUbMNvg4ta2i1fnqYXR7H: lookup limani.celestia-devops.dev: i/o timeout
2022-12-17T15:02:59.472ZERRORheader/p2pp2p/exchange.go:107head request to trusted peer failed{"trustedPeer": "12D3KooWNpRWxpi1APzV6CnwHvdgNRuTUbMNvg4ta2i1fnqYXR7H", "err": "context deadline exceeded"}
2022-12-17T15:02:59.472ZERRORheader/p2pp2p/exchange.go:107head request to trusted peer failed{"trustedPeer": "12D3KooWHr2wqFAsMXnPzpFsgxmePgXb8BqpkePebwUgLyZc95bd", "err": "context deadline exceeded"}
Error: node: failed to start: OnStart hook added by go.uber.org/fx.(*lifecycleHookAnnotation).Build.func1 failed: context deadline exceeded

github.com/celestiaorg/celestia-node/nodebuilder/header.newInitStore.func1() took 656.792µs from:
github.com/celestiaorg/celestia-node/nodebuilder/header.newInitStore (/go/celestia-node/nodebuilder/header/constructors.go:91)
go.uber.org/fx.(*lifecycleHookAnnotation).Build.func1.1() took 46.291µs from:
go.uber.org/fx.(*lifecycleHookAnnotation).Build.func1 (/go/pkg/mod/go.uber.org/fx@v1.18.2/annotated.go:447)
github.com/celestiaorg/celestia-node/nodebuilder/header.newP2PExchange.func1.1() took 28.292µs from:
github.com/celestiaorg/celestia-node/nodebuilder/header.newP2PExchange.func1 (/go/celestia-node/nodebuilder/header/constructors.go:57)
go.uber.org/fx.(*lifecycleHookAnnotation).Build.func1.1() took 22.917µs from:
go.uber.org/fx.(*lifecycleHookAnnotation).Build.func1 (/go/pkg/mod/go.uber.org/fx@v1.18.2/annotated.go:447)
github.com/celestiaorg/celestia-node/fraud.(*ProofService).Start-fm() took 22.292µs from:
github.com/celestiaorg/celestia-node/nodebuilder/fraud.newFraudService.func1 (/go/celestia-node/nodebuilder/fraud/constructors.go:31)
github.com/celestiaorg/celestia-node/nodebuilder/p2p.PeerRouting.func1() took 792ns from:
github.com/celestiaorg/celestia-node/nodebuilder/p2p.PeerRouting (/go/celestia-node/nodebuilder/p2p/routing.go:43)

Relevant log output
No response
Notes
No response

The default bootstrap p2p nodes are configured here
From my debugging the timeout is 60 seconds. This isn't so much a bug, more so these nodes appear  overloaded and do not respond quick enough
At the moment, it is unclear to me how to increase the timeout.

Still reproducible in latest main. Thanks for creating this bug @PrasoonPratham and flagging additional info @dougEfresh 🙏
We tried to increase the bootstrappers' hw resources but still got these issues.

After applying #1603 on top of main with #1608 I see issues like this
2023-01-18T10:19:35.191+0100	ERROR	header/p2p	p2p/session.go:142	requesting headers from peer failed.	{"failed peer": "12D3KooWDpJ3SRJwVZGVJcEENVC7Mi8i7TSWzj7dpY7suL4jzHHc", "err": "header/p2p: failed to open a new stream: context deadline exceeded"}
2023-01-18T10:19:35.191+0100	DEBUG	header/p2p	p2p/session.go:148	Retrying the request from different peer
2023-01-18T10:19:35.191+0100	ERROR	header/p2p	p2p/session.go:142	requesting headers from peer failed.	{"failed peer": "12D3KooWPYUXL5nFh9fngu5oXRaqyqzMmVmLnYHvDKLcV1uBg7NJ", "err": "header/p2p: failed to open a new stream: context deadline exceeded"}

After seeing more logs like above, das module is not progressing forward and just receiving latest network head

This is now tracked in https://github.com/celestiaorg/celestia-node/issues/1623


Add a test to verify xml/intellisense docs are present

This probably should be reviewed commit by commit. The first commit is a cleanup fixing some warnings pointed out by shellcheck. The second commit is the test.
This assumes all the xml docs are only present in the targeting packs, and not anywhere else.
I am not sure if the ignore list is correct: do all the packages listed look okay?
Fixes: #2127

CI errors were in building (in downloading source build artifacts tarball), not in the smoke tests.
@crummel @dseefeld  @MichaelSimons can you please take a look at this PR?

Sure, taking a look now.

It looks like just network issues, I kicked the failed legs and I'll check back in.


Calculation of the gradient of a loss function that requires the calculation of the gradient of a Flux model.

Calculating the gradient of a loss function that requires computing the gradient of the energy, which is currently defined by a Flux neural network model. I did not find a clean and performant way to do this. For the moment I am computing the gradient of the neural network model "analytically", particularly, the gradient of a feed-forward neural network using relu as activation function (see here). In addition, I had to use Flux.destructure to extract the parameters of the model.
Links related to this issue:

https://discourse.julialang.org/t/how-to-add-norm-of-gradient-to-a-loss-function/69873/16
https://discourse.julialang.org/t/issue-with-zygote-over-forwarddiff-derivative/70824
https://github.com/FluxML/Zygote.jl/issues/953#issuecomment-841882071

Solving this issue enables working with many types of neural network architectures, not only FFNN. For example, it allows experimenting with different models in this script which helps to find the optimal hyperparameters of the model

Progress on https://github.com/cesmix-mit/PotentialLearning.jl/pull/25 by @dallasfoster

See also the following issue in Zygote: https://github.com/FluxML/Zygote.jl/issues/1244.

Based on PR above, next example is closer to actual neural potential training. This code addresses reverse mode over reverse mode with the latest version of Flux. It consumes a substantial amount of memory, so it would be good to iterate it. Months ago something similar happened with the reverse mode over forward mode approach, it worked but very slowly.

using Flux

# Range
xrange = 0:π/99:π
xs = [ Float32.([x1, x2]) for x1 in xrange for x2 in xrange]

# Target function: E
E_analytic(x) = sin(x[1]) * cos(x[2])

# Analytical gradient of E
dE_analytic(x) = [cos(x[1]) * cos(x[2]), -sin(x[1]) * sin(x[2])]

# NN model
mlp = Chain(Dense(2,4, Flux.σ),Dense(4,1))
ps_mlp = Flux.params(mlp)
E(x) = sum(mlp(x))
dE(mlp, x) = sum(gradient(x -> sum(mlp(x)), x))

# Loss
loss(x, y) = Flux.Losses.mse(x, y)

# Training
epochs = 10; opt = Flux.Adam(0.1)
for _ in 1:epochs
    g = gradient(()->loss(reduce(vcat, dE.([mlp],xs)),
                          reduce(vcat, dE_analytic.(xs))), ps_mlp)
    Flux.Optimise.update!(opt, ps_mlp, g)
    l = loss(reduce(vcat, dE.([mlp],xs)),
             reduce(vcat, dE_analytic.(xs)))
    println("loss:", l)
    # GC.gc()
end

Note: NeuralPDE, a project with similarities to this one (training of MLPs using ML Julia abstractions) moved from Flux to Lux.


Bugfix

This change is

Fix Issue #99 & #100

Coverage increased (+0.08%) to 85.182% when pulling 83a4dfd1e2620fec533d2d67b6e295163399e907 on bugfix into 66941e448d355342396952efefa576364fd08707 on master.

Coverage increased (+0.08%) to 85.182% when pulling f338c02bf2d3ad66cab77766e6b776e67ce4a1ec on bugfix into 66941e448d355342396952efefa576364fd08707 on master.

Coverage increased (+0.3%) to 85.406% when pulling d17c80e8a3e246102af3defd4eba6208398f9750 on bugfix into 66941e448d355342396952efefa576364fd08707 on master.


Refactor javaharness.

Simplified the code structure by merging Dagger modules and some interfaces along with their implementations as we only have Android implementation now.
There are 3 main packages now:

api/ where common Arcs classes like Handles, PEC live.
2, android/ where Android specific codes like services, WebView based environment live. And android/demo for the demo application.
3, crdt/ remains unchanged.

To review, the best is to start with AndroidArcsClient which is supposed to be the entrance for Arcs users. This class wraps access to ArcsService and provides easy-to-use APIs for clients by automatically queuing calls to ArcsService when ArcsService is not ready.
The DI graph is much simplified: there is only one module for the SDK (android/ArcsAndroidModule.java). And for the demo app, I used ArcsDemoApplication to provide injections so activities/services don't need their own components.
Some main renames/merges:

PecInnerPort renamed to PecPort as there is not outer port.
2, RemotePecPort renamed to PecPortProxy as it's not a re-implementation of PecPort. Instead, it serves more like a proxy which forwards messages to another PecPort.
3, Merged DevicieClient into AndroidArcsEnvironment so we don't need to expose WebView outside of AndroidArcsEnvironment, a much safer approach imo.
4, Merged UiBrokerImpl and AndroidUiBrokerImpl into AndroidUiBroker.
5, Merged PortableJsonAndroidImpl and PortableJson into PortableJson, ParticleExecutionContextImpl and ParticleExecutionContext into ParticleExecutionContext as we don't have web now.
6, Removed demo particles/services like AlertRenderer and ClipboardService as these are not used and they are introducing extra classes/dependencies into ArcsService which should be kept minimal.

And restrict class accesses to package only unless they must be exposed public.

Yuan, maybe you could add a description of the refactoring changes, because the diff doesn't show renames, but new / deleted files instead, and it's a bit hard to keep track of the changes. Alternatively, if there was a way to break it into a series of smaller changes, that would help too, but i realize that it might be too hard, so just suggesting.

Hi,
I updated the description of this PR to make it easier to review. PTAL, thanks!

PTAL, thanks.

I don't have a problem with the overall changes, except I would keep in mind the need to support a mode where the WebView is replaced via DI with an implementation that drives the PEC directly.

Yeah I understood. I do expect to do another round of refactoring when the DI implementation is done or the design is finalized.

PTAL.
Rebased on recent PRs.
Now this PR mainly focuses on merge ArcsLocal into ArcsService and ArvcsServiceBridge into ArcsAndroid and all the dagger modules into 1 so it's easier to import into another DI system.


Implement UserDefinedNetwork resource API

Short description:
This PR introduces the UserDefinedNetwork class, which supports the creation and management of UserDefinedNetwork custom resources (CRs) in a Kubernetes environment.
More details:
What this PR does / why we need it:
To support this epic:
https://issues.redhat.com/browse/CNV-45524
Which issue(s) this PR fixes:
https://issues.redhat.com/browse/CNV-47585
Special notes for reviewer:
Bug:

Summary by CodeRabbit

New Features

Introduced a new constant K8S_OVN_ORG for enhanced Kubernetes integration.
Added a comprehensive framework for managing User Defined Networks (UDNs) in Kubernetes, including classes for different network types and methods for monitoring network conditions.

Improvements

Enhanced capabilities for network readiness and synchronization status detection, allowing for better management and monitoring of UDNs.

Report bugs in Issues
The following are automatically added:

Add reviewers from OWNER file (in the root of the repository) under reviewers section.
Set PR size label.
New issue is created for the PR. (Closed when PR is merged/closed)
Run pre-commit if .pre-commit-config.yaml exists in the repo.

Available user actions:

To mark PR as WIP comment /wip to the PR, To remove it from the PR comment /wip cancel to the PR.
To block merging of PR comment /hold, To un-block merging of PR comment /hold cancel.
To mark PR as verified comment /verified to the PR, to un-verify comment /verified cancel to the PR.
verified label removed on each new commit push.
To cherry pick a merged PR comment /cherry-pick <target branch to cherry-pick to> in the PR.

Multiple target branches can be cherry-picked, separated by spaces. (/cherry-pick branch1 branch2)
Cherry-pick will be started when PR is merged

To build and push container image command /build-and-push-container in the PR (tag will be the PR number).

You can add extra args to the Podman build command

Example: /build-and-push-container --build-arg OPENSHIFT_PYTHON_WRAPPER_COMMIT=<commit_hash>

To add a label by comment use /<label name>, to remove, use /<label name> cancel
To assign reviewers based on OWNERS file use /assign-reviewers
To check if PR can be merged use /check-can-merge

Supported /retest check runs

/retest tox: Retest tox
/retest python-module-install: Retest python-module-install

Supported labels

hold
verified
wip
lgtm

/verified

@sbahar619
please follow https://github.com/RedHatQE/openshift-python-wrapper/blob/main/CONTRIBUTING.md#adding-a-new-module-resource using class-generaor

@sbahar619 please follow https://github.com/RedHatQE/openshift-python-wrapper/blob/main/CONTRIBUTING.md#adding-a-new-module-resource using class-generator

The link class_generator README not working.
But I already followed the manual steps.

@sbahar619 please follow https://github.com/RedHatQE/openshift-python-wrapper/blob/main/CONTRIBUTING.md#adding-a-new-module-resource using class-generator

The link class_generator README not working. But I already followed the manual steps.

I don't think it's hard to find it, anyway the link was fixed.

/verified

class_generator

@sbahar619 please follow https://github.com/RedHatQE/openshift-python-wrapper/blob/main/CONTRIBUTING.md#adding-a-new-module-resource using class-generator

The link class_generator README not working. But I already followed the manual steps.

I don't think it's hard to find it, anyway the link was fixed.

Thanks, I applied the changes of the class_generator.

I don't where you use the generator, did you run it?

class_generator

@sbahar619 please follow https://github.com/RedHatQE/openshift-python-wrapper/blob/main/CONTRIBUTING.md#adding-a-new-module-resource using class-generator

The link class_generator README not working. But I already followed the manual steps.

I don't think it's hard to find it, anyway the link was fixed.

Thanks, I applied the changes of the class_generator.

I don't where you use the generator, did you run it?

I followed the documentation, and generated the UserDefinedNetwork class it populated, and then I updated it to reflect the changes.
Isn't it what you meant?

class_generator

@sbahar619 please follow https://github.com/RedHatQE/openshift-python-wrapper/blob/main/CONTRIBUTING.md#adding-a-new-module-resource using class-generator

The link class_generator README not working. But I already followed the manual steps.

I don't think it's hard to find it, anyway the link was fixed.

Thanks, I applied the changes of the class_generator.

I don't where you use the generator, did you run it?

I followed the documentation, and generated the UserDefinedNetwork class it populated, and then I updated it to reflect the changes. Isn't it what you meant?

You need to use class-generator to create all the resources that you want.
each resource in a file (class-generator will do it for you)
If you have extra code to add you need to add it after the generated code.
Do not edit the class generator code and comments.

@sbahar619 please follow https://github.com/RedHatQE/openshift-python-wrapper/blob/main/CONTRIBUTING.md#adding-a-new-module-resource using class-generator

Done and merged.

/verified

@sbahar619
Please close his PR and open a new one.
/hold