feat: hide Offline BaseMaps menu item when no sources defined

This alters the behavior of the home screen to hide the Basemaps menu item when the active survey has no basemap sources defined (i.e. we now only show the option when it's actually possible to download basemaps). I had to make a few small fixes to accomplish this:

Sync locally cached surveys upon activation; before, we were relying only on the Offline data, which lead to discrepancies between the offline and remote.
Update local basemap sources on survey sync.
Don't overwrite basemap sources on writing surveys to the local db

Fixes #812
https://user-images.githubusercontent.com/11237600/229591348-2b2faaa2-dcf4-4465-bb09-87ced948ed8a.mov

/gcbrun

/gcbrun

/gcbrun

/gcbrun

/gcbrun

/gcbrun

/gcbrun


Update Difficulty Score

Normalize Score (ensure valid difficulties in given scale)

Duplicate for Issue #9. Do not need


The program flash out instantly

When I open the LxRunOffline.exe, it open a cmd window and exit right away.
How could I solve it?
The version is v3.3.2

LxRunOffline is a command line program so you have to use it through a shell. Open cmd in the directory containing the executable and run LxRunOffline help to find out how to use it.

thx


GUI - Device update screen - Proposal

@cfrancisco I think that this issue was implemented. Is it ok? Can we close this?


fix: styling and layout changes for dashboard, footer and product page

Pre-Flight checklist

[x] Screenshots and design review for any changes that affect layout or styling

[x] Desktop screenshots
[x] Mobile width screenshots

[x] Testing

[x] Code is tested
[x] Changes have been manually tested

What are the relevant tickets?
#91
What's this PR do?

Fixes the styling/layout issues in the footer
Fixes the layout issues on the dashboard
Fixes the layout issues on the Product Detail Page
Removed extra  tags from rich text in product detail page
Removed xPRO's unused style from the footer which was copied over xPRO

Putting simply, these are the things from PDF:

All footer text to be font-weight:400 & spacing Mentioned in PDF
For the dashboard page, adjusted the spacing mentioned in the PDF
For product page background is set to white and spacing adjusted as per PDF

Note: There is a pdf file attached to the associated issue which will help out identifying the required styling changes
How should this be manually tested?

Verify it against the changes mentioned in the PDF attached to the ticket.
Verify the nothing else has been affected by this PR

Where should the reviewer start?

HomePage

Screenshots (if appropriate)
Footer Desktop

Footer Mobile

Dashboard Desktop

Dashboard Mobile

Product Page Desktop

Product Page Mobile

Codecov Report

Merging #98 (a7a1d8e) into main (6ce406d) will increase coverage by 7.00%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##             main      #98      +/-   ##
==========================================
+ Coverage   90.28%   97.29%   +7.00%
==========================================
  Files         201      116      -85
  Lines        5796     2585    -3211
  Branches      280        0     -280
==========================================
- Hits         5233     2515    -2718
+ Misses        480       70     -410
+ Partials       83        0      -83

Impacted Files
Coverage Δ

static/js/containers/pages/DashboardPage.js
100.00% <ø> (ø)

courses/messages.py

authentication/serializers.py

courses/__init__.py

openedx/tasks.py

cms/blocks.py

courses/urls.py

courses/management/utils.py

courses/serializers.py

mail/forms.py

... and 76 more

Continue to review full report at Codecov.

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

This font-size should be applied to the general style in common.scss so all h1's use it. There is no reason to have some h1 elements at 40px and others at 42px/48px. Those values are close enough that you should always assume that the change should be applied to all elements like it. You can also try applying the mobile styles to the common.scss and see how the other h1 elements on other pages look.

I like this idea and I've updated the font size/ lint-height styles common.scss for h1. Instead of setting 40px for all h1 i took the liberty of setting font-size/line-height as 42px/52px for desktops and 34px/38px for mobile. The reason I tried to set 42px instead of 40px was to make sure that we could make the h1 style common keeping it close to the existing design and also being able to do the required styling that's part of this ticket.
Attaching some before/after screenshots below so that you can also take a look at the difference:

You can also remove the courses-heading class from that h1 if the above suggestions work out

I've removed the size and line height-related styling from the class but I've kept the class for spacing-related styles that in my opinion might change in different places e.g. specifically on the dashboard.

If you are fine with these changes we can merge them or if you think the design changes are too broad I will revert the last commit.
CC: @pdpinch (Tagging because this might introduce some design tweaks, not very major but wanted to let you know in any case)

I'm checking with the designer why the course detail page has a larger H1 than the other account creation pages.

InVision has been updated, https://projects.invisionapp.com/d/main?origin=v7#/projects/prototypes/21535972?inbox=true&inboxProjectID=21535972&inboxConversationID=144914028
In any case, the h1 on the course detail should be the same size as all the rest.


Use individual array elements in CasADi backend, instead of storing as vector/matrix

Vector/matrix expansion is far from ideal, duplicating code and possibly resulting in a performance hit.
Using matrices limits us to only storing 2D arrays, whereas Modelica support higher dimensions as well.

JModelica stores individual elements as well,e.g. turning a matrix x into x[1,1], x[1,2], etc. Is there any downside to us doing it this way as well?

The original goal as I understood it is to keep the generated MX graph of CasADi as close as possible to Modelica representation. This means that for loops stay as maps, etc. For speed, it's always possible to expand to SX at the end, which would make everything simple again (no functions, just unary and binary operations). Closing this for now, until a serious bottleneck pops up with the current approach.


[zh] Translate /docs/reference/access-authn-authz/certificate-signing-requests.md into Chinese

/language zh

/reopen
This was incorrectly closed by #24222

/assign


Trigger griddle callbacks on next and previous pagination

Griddle major version
1.8.0
Changes proposed in this pull request
I think the actions should still be triggered for pagination regardless of the data being local.
Why these changes are made
Trying to mutate the state from a reducer on these events.
Are there tests?
No.

I wonder if it would be better to move getNext/getPrevious out of the container (for default and LocalPlugin) down into their corresponding enhancers? Something like:
  mapProps(({ events: { getNext, onNext }, ...props }) => ({
    ...props,
    onClick: combineHandlers([onNext, getNext, props.onClick]),
  }))

@dahlbyk that is kind of what I was thinking when I first looked at this as well. Should I update the PR to reflect this?

I think that would be good to move if possible.
Maybe a discussion for future Griddle versions too -- the breakdown between enhancers and containers and if it is necessary. 🤔

@ryanlanciaux @dahlbyk PR updated now with the actions in the enhancer.
@ryanlanciaux This would be a good conversation to have. One of the big issues I'm facing right now is composing a grid with multiple plugins.

@ryanlanciaux: Maybe a discussion for future Griddle versions too -- the breakdown between enhancers and containers and if it is necessary.
@JesseFarebro: This would be a good conversation to have. One of the big issues I'm facing right now is composing a grid with multiple plugins.

Opened https://github.com/GriddleGriddle/Griddle/issues/733 to continue this conversation.

@dahlbyk anything else that needs to be done here or can this be merged?

Thanks for the update, @JesseFarebro; I think we're close.
I'm thinking we should also update the LocalPlugin button containers to no longer set onClick, since the enhancer handles that. Otherwise we'll fire the action twice, right? (A no-op, but still.)

Hey, I was working with @JesseFarebro but he won't be able to contribute to the project from now on, is there anything else I can do on this PR?

@dahlbyk @ryanlanciaux Now that I think about it, why should the pagination buttons even be concerned with calling Griddle pagination actions when the table is not using the local plugin, shouldn't that be the responsibility of the external data store passing in new pageProperties? Also, after some testing, this change is causing problems with Griddle.


Use static loggers to avoid NPEs when services are serialized

This will need to be ported back into 4.2.x


Doing math with Tensor can be a lot more ergonomic

It seems pretty straightforward to implement std::ops::{Add, Div, Mul}, etc.
impl Add for &Tensor {
    type Output = Tensor;

    fn add(self, rhs: Self) -> Self::Output {
        Context {
            ptr: self.ctx.upgrade().expect("Couldn't get context!"),
        }
        .op_add(self, rhs)
    }
}

It's a little awkward with the vanilla version of GGML though since it doesn't even support subtraction or division so it kind of needs my map ops stuff: https://github.com/KerfuffleV2/llama-rs/commit/7e2d3d0ad24c7597376fe2dd3b8adb413c411c80
I repurposed ^ (XOR) for mat_mul but it could be something else like & or |. I'm not really sure what operator makes the most sense here.
Just for example, code can go from:
impl LayerNorm {
    pub fn norm_ops(&self, ctx: &Context, x: &Tensor) -> Tensor {
        ctx.op_add(&ctx.op_mul(&ctx.op_norm(x), &self.weight), &self.bias)
    }
}

impl Mix {
    pub fn mix_ops(&self, ctx: &Context, x: &Tensor, last_x: &Tensor) -> Tensor {
        ctx.op_add(
            &ctx.op_mul(x, &self.0),
            &ctx.op_mul(last_x, &map_ops::one_minus(ctx, &self.0)),
        )
    }
}

to
impl LayerNorm {
    pub fn norm_ops(&self, ctx: &Context, x: &Tensor) -> Tensor {
        &ctx.op_norm(x) * &self.weight + self.bias.share()
    }
}

impl Mix {
    pub fn mix_ops(&self, ctx: &Context, x: &Tensor, last_x: &Tensor) -> Tensor {
        x * &self.0 + last_x * &map_ops::one_minus(ctx, &self.0)
    }
}

It's actually really convenient that every Tensor has an embedded Context otherwise this wouldn't be possible. As far as I know, the temporary upgrade should be safe (obviously it'll die horribly if you try to perform operations with a dead Context.)
Note: This isn't quite as straightforward as it may appear for the operations that aren't currently supported because my OP_MAP_UNARY|BINARY ops currently only support f32 values. So you couldn't use those to divide/subtract quantized values currently.

Need to do more investigation to make sure the temporary Context approach is safe. Seems like the pointers aren't valid when hitting C code currently.

I'm a bit hesitant about this.
On one hand, it reads much better, but on the other hand the ownership semantics for GGML stuff are already quite tricky. So making things more implicit can obscure important details about who owns the tensor data.
When you call ctx.ops_add(a, b), this will implicitly allocate new tensor data inside of ctx to contain the result. However, a and b are not necessarily allocated inside ctx. This is why, when doing operations, we check if the context for the tensor is still alive using the Weak pointers. This can catch some mistakes, but it's actually not enough. The current API is unsound (and we're aware of it), because data for a tensor may be accessed even after the operation function is executed (ggml builds a computation graph, and only executes it when you tell it to execute at the end).
If we were to model this properly, a tensor operation would need to intertwine the lifetimes of ctx, and the contexts that allocated a and b (ctx.a, and ctx.b, which may or may not be ctx). The correct relation is that a.ctx and b.ctx must outlive ctx. Because otherwise ctx will happily dereference freed pointers when running the computation graph that references a and b.
Changes to improve the soundness of the API are welcome, but so far making fully sound and idiomatic bindings to GGML hasn't been a priority.
This is not just a theoretical concern. Right now, we already have a situation where the context that stores the model's weights and the temporary context used for an inference step are different. It's not a problem because the temporary context is temporary, and the weights for the model have to be alive for as long as the temporary context is.
Anyway, what I meant to say about all this, is that the problem of having tensors use their internal context pointer to do anything other than validation is that the order of operations changes the owner context. Writing a + b and b + a may allocate memory in different contexts and this may have safety implications if one of the two contexts is short-lived.

That's fair (and I'm not sure if you noticed but I actually closed this myself already).
Maybe a better approach would be to have Tensor not be a real GGML tensor. Then it could be used to build the graph and a separate step could transform it into actual tensors. The first part wouldn't actually need to do anything except model the relationship between tensors.
Anyway, I need to do more research on this but I think there definitely should be a way to make building the graph much more ergonomic.
It also could be done in a way that's not a breaking change by just adding a type that those operations could be performed on.


Fix tooltip positioning for textAnchor other than middle

When textAnchor is set to something other than middle, the tooltip positioning is off. This ensures the tooltip label is aligned properly.

Is there anything I can do to help get this merged?

@GreenGremlin sorry for the long delay. I've finally had a chance to double check this work. Perfect. Merging.

Thanks! If you have a moment, there's a similar change for the voronoi container here: https://github.com/FormidableLabs/victory-chart/pull/462


Update black-duck-hub-scanner-reference.md

Harness Developer Pull Request
Thanks for helping us make the Developer Hub better. The PR will be looked at
by the maintainers.
What Type of PR is This?

[ ] Issue
[ ] Feature
[ ] Maintenance/Chore

If tied to an Issue, list the Issue(s) here:

Issue(s)

House Keeping
Some items to keep track of. Screen shots of changes are optional but would help the maintainers review quicker.

[ ] Tested Locally
[ ] Optional Screen Shoot.

Please check the Execution Link of the Pipeline for the Website Draft URL. This is located in the Preview Step and also is available in #hdh_alerts. E.g Website Draft URL: https://unique-id--harness-developer.netlify.app

Closing as a dup of PR-3170


"ocne application update" command failing when install did not customize any helm values initially

"ocne application update" command failing when install did not customize any helm values initially.
Fixed map variable from becoming nil
$ ocne application update --release istiod --version 1.19.9 --catalog embedded --namespace istio-system --values - << EOF
> ownerName: helm
> EOF
INFO[2024-11-14T23:26:05Z] Updating release istiod
INFO[2024-11-14T23:26:05Z] Application updated successfully

$ ocne  application show --release istiod --namespace istio-system
ownerName: helm
----------------
NAME: istiod
NAMESPACE: istio-system
CHART: istiod
STATUS: deployed
REVISION: 3
APPVERSION: 1.19.9

While update now succeeds, I am seeing two istiod pods with the new one stuck in pending. The events shows details - I am investigating. This seems related to istiod chart itself and not necessarily my changes. I installed metallb and subsequently updated it successfully - updated destroyed and created new pods correctly
$ ocne application update --release istiod --version 1.19.9 --catalog embedded --namespace istio-system --values - << EOF
> ownerName: helm
> EOF
INFO[2024-11-15T19:40:31Z] Updating release istiod
INFO[2024-11-15T19:40:31Z] Application updated successfully
~ $ kubectl get pods -A -w
NAMESPACE      NAME                                           READY   STATUS    RESTARTS   AGE
istio-system   istiod-5d5c85b7b6-grvh9                        0/1     Pending   0          14m
istio-system   istiod-6d4d8db6b6-ptgbn                        1/1     Running   0          15m
kube-flannel   kube-flannel-ds-slctw                          1/1     Running   0          16m
kube-system    coredns-f7d444b54-ng6pg                        1/1     Running   0          16m
kube-system    coredns-f7d444b54-rw5pc                        1/1     Running   0          16m
kube-system    etcd-ocne-control-plane-1                      1/1     Running   0          16m
kube-system    kube-apiserver-ocne-control-plane-1            1/1     Running   0          16m
kube-system    kube-controller-manager-ocne-control-plane-1   1/1     Running   0          16m
kube-system    kube-proxy-p9htq                               1/1     Running   0          16m
kube-system    kube-scheduler-ocne-control-plane-1            1/1     Running   0          16m
ocne-system    ocne-catalog-578c959566-8jg79                  1/1     Running   0          16m
^C~ $ k -n istio-system get events
LAST SEEN   TYPE      REASON                         OBJECT                           MESSAGE
4m23s       Warning   FailedScheduling               pod/istiod-5d5c85b7b6-grvh9      0/1 nodes are available: 1 Insufficient memory. preemption: 0/1 nodes are available: 1 No preemption victims found for incoming pod.
14m         Normal    SuccessfulCreate               replicaset/istiod-5d5c85b7b6     Created pod: istiod-5d5c85b7b6-grvh9
15m         Normal    Scheduled                      pod/istiod-6d4d8db6b6-ptgbn      Successfully assigned istio-system/istiod-6d4d8db6b6-ptgbn to ocne-control-plane-1
15m         Normal    Pulling                        pod/istiod-6d4d8db6b6-ptgbn      Pulling image "olcne/pilot:1.19.9"
15m         Normal    Pulled                         pod/istiod-6d4d8db6b6-ptgbn      Successfully pulled image "olcne/pilot:1.19.9" in 6.363s (6.363s including waiting). Image size: 201539871 bytes.
15m         Normal    Created                        pod/istiod-6d4d8db6b6-ptgbn      Created container discovery
15m         Normal    Started                        pod/istiod-6d4d8db6b6-ptgbn      Started container discovery
15m         Normal    SuccessfulCreate               replicaset/istiod-6d4d8db6b6     Created pod: istiod-6d4d8db6b6-ptgbn
15m         Normal    NoPods                         poddisruptionbudget/istiod       No matching pods found
15m         Normal    ScalingReplicaSet              deployment/istiod                Scaled up replica set istiod-6d4d8db6b6 to 1
19s         Warning   FailedGetResourceMetric        horizontalpodautoscaler/istiod   failed to get cpu utilization: unable to get metrics for resource cpu: unable to fetch metrics from resource metrics API: the server could not find the requested resource (get pods.metrics.k8s.io)
12m         Warning   FailedComputeMetricsReplicas   horizontalpodautoscaler/istiod   invalid metrics (1 invalid out of 1), first error is: failed to get cpu resource metric value: failed to get cpu utilization: unable to get metrics for resource cpu: unable to fetch metrics from resource metrics API: the server could not find the requested resource (get pods.metrics.k8s.io)
14m         Normal    ScalingReplicaSet              deployment/istiod                Scaled up replica set istiod-5d5c85b7b6 to 1

~ $ ocne application install --name metallb --namespace mlb -c embedded
~ $ kubectl get pods -A -w
NAMESPACE      NAME                                           READY   STATUS    RESTARTS   AGE
istio-system   istiod-5d5c85b7b6-grvh9                        0/1     Pending   0          24m
istio-system   istiod-6d4d8db6b6-ptgbn                        1/1     Running   0          25m
kube-flannel   kube-flannel-ds-slctw                          1/1     Running   0          26m
kube-system    coredns-f7d444b54-ng6pg                        1/1     Running   0          26m
kube-system    coredns-f7d444b54-rw5pc                        1/1     Running   0          26m
kube-system    etcd-ocne-control-plane-1                      1/1     Running   0          26m
kube-system    kube-apiserver-ocne-control-plane-1            1/1     Running   0          26m
kube-system    kube-controller-manager-ocne-control-plane-1   1/1     Running   0          26m
kube-system    kube-proxy-p9htq                               1/1     Running   0          26m
kube-system    kube-scheduler-ocne-control-plane-1            1/1     Running   0          26m
mlb            metallb-controller-5984d4dc7b-ntdmq            1/1     Running   0          40s
mlb            metallb-speaker-jrxzg                          1/1     Running   0          40s
ocne-system    ocne-catalog-578c959566-8jg79                  1/1     Running   0          26m
~ $ ocne application update --release metallb --namespace mlb -c embedded --values - << EOF
> nameOverride: "test"
> EOF
~ $ kubectl get pods -A -w
NAMESPACE      NAME                                           READY   STATUS    RESTARTS   AGE
istio-system   istiod-5d5c85b7b6-grvh9                        0/1     Pending   0          27m
istio-system   istiod-6d4d8db6b6-ptgbn                        1/1     Running   0          28m
kube-flannel   kube-flannel-ds-slctw                          1/1     Running   0          29m
kube-system    coredns-f7d444b54-ng6pg                        1/1     Running   0          29m
kube-system    coredns-f7d444b54-rw5pc                        1/1     Running   0          29m
kube-system    etcd-ocne-control-plane-1                      1/1     Running   0          29m
kube-system    kube-apiserver-ocne-control-plane-1            1/1     Running   0          29m
kube-system    kube-controller-manager-ocne-control-plane-1   1/1     Running   0          29m
kube-system    kube-proxy-p9htq                               1/1     Running   0          29m
kube-system    kube-scheduler-ocne-control-plane-1            1/1     Running   0          29m
mlb            metallb-test-controller-7db5856f69-l6qbd       0/1     Running   0          2s
mlb            metallb-test-speaker-lnn2x                     0/1     Running   0          2s
ocne-system    ocne-catalog-578c959566-8jg79                  1/1     Running   0          29m
mlb            metallb-test-controller-7db5856f69-l6qbd       1/1     Running   0          10s
mlb            metallb-test-speaker-lnn2x                     1/1     Running   0          11s

While update now succeeds, I am seeing two istiod pods with the new one stuck in pending. The events shows details - I am investigating. This seems related to istiod chart itself and not necessarily my changes. I installed metallb and subsequently updated it successfully - update operation destroyed and created new pods correctly
$ ocne application update --release istiod --version 1.19.9 --catalog embedded --namespace istio-system --values - << EOF
> ownerName: helm
> EOF
INFO[2024-11-15T19:40:31Z] Updating release istiod
INFO[2024-11-15T19:40:31Z] Application updated successfully
~ $ kubectl get pods -A -w
NAMESPACE      NAME                                           READY   STATUS    RESTARTS   AGE
istio-system   istiod-5d5c85b7b6-grvh9                        0/1     Pending   0          14m
istio-system   istiod-6d4d8db6b6-ptgbn                        1/1     Running   0          15m
kube-flannel   kube-flannel-ds-slctw                          1/1     Running   0          16m
kube-system    coredns-f7d444b54-ng6pg                        1/1     Running   0          16m
kube-system    coredns-f7d444b54-rw5pc                        1/1     Running   0          16m
kube-system    etcd-ocne-control-plane-1                      1/1     Running   0          16m
kube-system    kube-apiserver-ocne-control-plane-1            1/1     Running   0          16m
kube-system    kube-controller-manager-ocne-control-plane-1   1/1     Running   0          16m
kube-system    kube-proxy-p9htq                               1/1     Running   0          16m
kube-system    kube-scheduler-ocne-control-plane-1            1/1     Running   0          16m
ocne-system    ocne-catalog-578c959566-8jg79                  1/1     Running   0          16m
^C~ $ k -n istio-system get events
LAST SEEN   TYPE      REASON                         OBJECT                           MESSAGE
4m23s       Warning   FailedScheduling               pod/istiod-5d5c85b7b6-grvh9      0/1 nodes are available: 1 Insufficient memory. preemption: 0/1 nodes are available: 1 No preemption victims found for incoming pod.
14m         Normal    SuccessfulCreate               replicaset/istiod-5d5c85b7b6     Created pod: istiod-5d5c85b7b6-grvh9
15m         Normal    Scheduled                      pod/istiod-6d4d8db6b6-ptgbn      Successfully assigned istio-system/istiod-6d4d8db6b6-ptgbn to ocne-control-plane-1
15m         Normal    Pulling                        pod/istiod-6d4d8db6b6-ptgbn      Pulling image "olcne/pilot:1.19.9"
15m         Normal    Pulled                         pod/istiod-6d4d8db6b6-ptgbn      Successfully pulled image "olcne/pilot:1.19.9" in 6.363s (6.363s including waiting). Image size: 201539871 bytes.
15m         Normal    Created                        pod/istiod-6d4d8db6b6-ptgbn      Created container discovery
15m         Normal    Started                        pod/istiod-6d4d8db6b6-ptgbn      Started container discovery
15m         Normal    SuccessfulCreate               replicaset/istiod-6d4d8db6b6     Created pod: istiod-6d4d8db6b6-ptgbn
15m         Normal    NoPods                         poddisruptionbudget/istiod       No matching pods found
15m         Normal    ScalingReplicaSet              deployment/istiod                Scaled up replica set istiod-6d4d8db6b6 to 1
19s         Warning   FailedGetResourceMetric        horizontalpodautoscaler/istiod   failed to get cpu utilization: unable to get metrics for resource cpu: unable to fetch metrics from resource metrics API: the server could not find the requested resource (get pods.metrics.k8s.io)
12m         Warning   FailedComputeMetricsReplicas   horizontalpodautoscaler/istiod   invalid metrics (1 invalid out of 1), first error is: failed to get cpu resource metric value: failed to get cpu utilization: unable to get metrics for resource cpu: unable to fetch metrics from resource metrics API: the server could not find the requested resource (get pods.metrics.k8s.io)
14m         Normal    ScalingReplicaSet              deployment/istiod                Scaled up replica set istiod-5d5c85b7b6 to 1

~ $ ocne application install --name metallb --namespace mlb -c embedded
~ $ kubectl get pods -A -w
NAMESPACE      NAME                                           READY   STATUS    RESTARTS   AGE
istio-system   istiod-5d5c85b7b6-grvh9                        0/1     Pending   0          24m
istio-system   istiod-6d4d8db6b6-ptgbn                        1/1     Running   0          25m
kube-flannel   kube-flannel-ds-slctw                          1/1     Running   0          26m
kube-system    coredns-f7d444b54-ng6pg                        1/1     Running   0          26m
kube-system    coredns-f7d444b54-rw5pc                        1/1     Running   0          26m
kube-system    etcd-ocne-control-plane-1                      1/1     Running   0          26m
kube-system    kube-apiserver-ocne-control-plane-1            1/1     Running   0          26m
kube-system    kube-controller-manager-ocne-control-plane-1   1/1     Running   0          26m
kube-system    kube-proxy-p9htq                               1/1     Running   0          26m
kube-system    kube-scheduler-ocne-control-plane-1            1/1     Running   0          26m
mlb            metallb-controller-5984d4dc7b-ntdmq            1/1     Running   0          40s
mlb            metallb-speaker-jrxzg                          1/1     Running   0          40s
ocne-system    ocne-catalog-578c959566-8jg79                  1/1     Running   0          26m
~ $ ocne application update --release metallb --namespace mlb -c embedded --values - << EOF
> nameOverride: "test"
> EOF
~ $ kubectl get pods -A -w
NAMESPACE      NAME                                           READY   STATUS    RESTARTS   AGE
istio-system   istiod-5d5c85b7b6-grvh9                        0/1     Pending   0          27m
istio-system   istiod-6d4d8db6b6-ptgbn                        1/1     Running   0          28m
kube-flannel   kube-flannel-ds-slctw                          1/1     Running   0          29m
kube-system    coredns-f7d444b54-ng6pg                        1/1     Running   0          29m
kube-system    coredns-f7d444b54-rw5pc                        1/1     Running   0          29m
kube-system    etcd-ocne-control-plane-1                      1/1     Running   0          29m
kube-system    kube-apiserver-ocne-control-plane-1            1/1     Running   0          29m
kube-system    kube-controller-manager-ocne-control-plane-1   1/1     Running   0          29m
kube-system    kube-proxy-p9htq                               1/1     Running   0          29m
kube-system    kube-scheduler-ocne-control-plane-1            1/1     Running   0          29m
mlb            metallb-test-controller-7db5856f69-l6qbd       0/1     Running   0          2s
mlb            metallb-test-speaker-lnn2x                     0/1     Running   0          2s
ocne-system    ocne-catalog-578c959566-8jg79                  1/1     Running   0          29m
mlb            metallb-test-controller-7db5856f69-l6qbd       1/1     Running   0          10s
mlb            metallb-test-speaker-lnn2x                     1/1     Running   0          11s

I created a cluster with more memory and storage for libvirt-based cluster. Then "ocne application update" command work correctly - existing istiod pod was deleted and new istiod pod got recreated successfully
providers:
  libvirt:
    controlPlaneNode:
      memory: 8Gi
      cpu: 4


[DATA] Create DAOs Table

Overview
This adds everything related to the data needed to display basic DAO information for the Alpha version of the "DAOs Table" in the Hub App.
Details
The "DAOs Table" in Hub App Alpha version doesn't include totals, filters, and search. These can be added in a later version.
We talked about a few possible inclusions, such as:

Possibly a getAllDAOsByUserAddress

List of DAOs user is a member of by address
name is only metadata right now
Can add metadata for the other fields such as proposalCount

@skuhlmann I'm not sure what is appropriate in scope to include for this, but wanted to get the card created for this.
Related Issues

The UI feature issue for this is outlined in #107
The Pagination issue (#106) may make sense to combine with this

Deliverables

DAO data fetching functions added to our data package

https://github.com/HausDAO/daohaus-monorepo/pull/136


Fallback to encoding images with libwebpjs

So I made a thing based on whammy. But I wanted it to work in Firefox. So I added support for libwebpjs. If someone is interested in those changes, I'll clean them up. (This repo does not seem like it would accept pull requests. Also, there is the licensing headache, which I haven't even begun to think about…)
The settings for encoding need some tuning.

Hi, awesome work, super interested in those changes. Just wondering where if you've got this file to hand? libwebp-0.1.3.min.js

(No idea why I never answered... But it's easy to find anyway.)


Add completion handler

Added completion handler on finish of transition

Ported from https://github.com/voltbank/ReplaceRootViewController thanks


format the python files with yapf

This change is

/ok-to-test
@jlewi Could we invite mitake to be a member of kubeflow then we don't need to enable his PR's test

/lgtm

Coverage increased (+0.1%) to 27.599% when pulling 9a253502e76b2aaabf08024cd986e52920c598f9 on mitake:yapf into 5d0d12688e08f80b41bb5eeac2da5418b73bfbbe on kubeflow:master.

@mitake The Travis failed because of #428 , so no need to worry about it.

should've been caught by CI

@mitake #428 is merged, please rebase and let travis do its work again.

/lgtm


Generate thumbnails with ffmpeg

Eventually we want to be able to generate thumbnails using our transcoders (alongside segment transcoding), for now though I'm implementing this in catalyst using ffmpeg similar to other cases.

Did you happen to check resource utilization on the pods when ffmpeg is running for somewhat long vod file? Do CPUs get pegged?

Did you happen to check resource utilization on the pods when ffmpeg is running for somewhat long vod file? Do CPUs get pegged?

Thanks for the reminder 😬 yeah it's not brilliant:

I've done a fair bit of digging today though and I can't see a simple way to improve it, you can get ffmpeg to output keyframes which is obviously really efficient but then we end up with different thumbnail frequency for different videos. So might have to leave it like this for now until we move it to the transcoders, and only turn it on for specific customers that need it?

@emranemran I've now switched to extracting keyframes only, this reduces processing time to under 1 second for a 10 min video and ~8 seconds for a 1hr15 video I tested with. Sound ok?

@emranemran I've now switched to extracting keyframes only, this reduces processing time to under 1 second for a 10 min video and ~8 seconds for a 1hr15 video I tested with. Sound ok?

Nice, that's a great perf improvement for now. I'll begin working on moving this to T-layer as a separate effort.


Whatsapp send media failed 13.1.3

i cann't send any media by whatsapp its failed on iPhone 11 13.1.3
i didn't know what's problem and i can't fix it pls help me

This is the same issue here:
https://github.com/pwn20wndstuff/Undecimus/issues/1744

same problem here

Same issue on iPhone pro max 13.0

Duplicated of #1744


add support for response file to fsc

like roslyn. it's not because is roslyn, i think is useful
add @file argument to fsc
ref https://msdn.microsoft.com/en-us/library/8a1fs1tb.aspx
Long story short:
A file that lists compiler options or source code files to compile, instead of pass compiler arguments.
Goodies:

Response files can have comments that begin with the # symbol.
Combine multiple options. @file1.rsp @file2.rsp
command line arguments can override previously listed options in response files.
options in a response file will override options listed previously on the command line or in other response files

it's nice to have a base configuration, and two files, for example debug, test or perf as additional
more easy to track in source control ( it's a text file ) instead of concat argument list in script

:+1:

Yes, this is a long time missing feature from F#, I have been figuring I would add it at some point, however, nothing fails to work because it is missing, so it has seemed like a very low priority feature to me.
If we do this, we should also consider adding response files for FSI.
I would certainly eagerly consider accepting a PR for this feature.

i'll try to add it, it's really useful for dotnet cli development.
About this feature, @ is really wierd, it's like a special case of source file.
Should we use @ or a normal (short) argument like --rsp for consistency ? /cc @dsyme
I'll start with @, is not difficult to change after it's done

I've encountered response files in the past and it was always using @ prefix, though I don't remember which compiler it was.
https://gcc.gnu.org/wiki/Response_Files
I'd vouch to keep the same convention as others compilers, especially if roslyn uses the same.

ah nice @smoothdeveloper , good that is a shared command line option, thx for feedback
llvm too http://llvm.org/docs/CommandLine.html#response-files nice.
no more open questions so :smile:

Fixed in https://github.com/Microsoft/visualfsharp/issues/831


Enable test runner to use the NNBD SDK

As part of migrating the repo tests to NNBD, the test runner will need to be able to select the NNBD-migrated Dart SDK when running tests in NNBD modes. This issue tracks that support.

Fixed by: https://dart-review.googlesource.com/c/sdk/+/121143. If the test configuration enables the "non-nullable" experiment, the test runner reads from the forked SDK build directory.


Crash when calling NrrdImageIO::Write() with an overly long file name

Description

Calling NrrdImageIO::Write(const void* buffer) with a buffersize larger than 1025 byte.
This will finally be passed to _biffMsgAddVL(biffMsg *msg, const char *errfmt, va_list args) as argument in args.
vsprintf writes the argument together with the format string into the local buffer errstr, which has a fixed size of 1025 byte.
This overwrites the stack and leads to a crash.

Steps to Reproduce
This crash was observed in our MITK based application and was reproducible there.
Expected behavior
Application should not crash.
Actual behavior
Application crashes.
See the debugger stack trace below:

Reproducibility
100% reproducible
Versions
ITK 5.2 as part of MITK 2023.04
Environment
Ran as part of a MITK based application.

@seanm Could it be that you already fixed this issue, by your efforts to replace sprintf usage with snprintf? (This issue was reported with ITK 5.2.)
For example:

pull request #3469

Could be!
@TrudbertSchwoerer do you repro with master?

Hi.
No, I do not consume ITK directly, but indirectly by using MITK 2023.04.0.
Best Regards
Trudbert Schwörer

Von: Sean McBride @.>
Gesendet: Mittwoch, 1. Mai 2024 15:17
An: InsightSoftwareConsortium/ITK @.>
Cc: Schwoerer, Trudbert @.>; Mention @.>
Betreff: Re: [InsightSoftwareConsortium/ITK] Crash when calling NrrdImageIO::Write() with an overly long file name (Issue #4623)
Sie erhalten nicht oft eine E-Mail von @.*** Erfahren Sie, warum dies wichtig isthttps://aka.ms/LearnAboutSenderIdentification
EXTERNAL EMAIL
Could be!
@TrudbertSchwoererhttps://github.com/TrudbertSchwoerer do you repro with master?
—
Reply to this email directly, view it on GitHubhttps://github.com/InsightSoftwareConsortium/ITK/issues/4623#issuecomment-2088449186, or unsubscribehttps://github.com/notifications/unsubscribe-auth/BDZKLANJCXTS4FQEZ5O2PZ3ZADTQDAVCNFSM6AAAAABG6QXUHOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAOBYGQ2DSMJYGY.
You are receiving this because you were mentioned.Message ID: @.***>
CAUTION: External email. Do not click links or open attachments unless you recognize the sender and know the content is safe. Please forward all suspicious emails to @.***
Follow this link to read our Privacy Statementhttps://www.stryker.com/content/stryker/gb/en/legal/global-policy-statement.html/

In fact no, I did not fix this, because it's not in ITK proper but in 3rd party code in /Modules/ThirdParty/NrrdIO/src/NrrdIO/biffbiff.c
This should be fixed in their upstream.


Bigquery ADC docs

prepare a guide on how to run bigquery ingestion from CLI using the google cloud cli auth instead of passing the input parameters to gcsConfig

@ulixius9 did we document this?

@harshach yes ADC docs are already available, closing this issue


T2WML will not import metadata from xslx file

Describe the bug
Related to #295. I created an existing project in v2.4.0, and then upgraded to v2.4.0-Datamart. The project loaded; but none of the metadata is imported in the T2WML file. I commented out several lines of the YAML (e.g., the region, which are defined by the variable column). T2WML does not seem to import anything.
Expected behavior
T2WML should use the metadata schema defined in the csv to propose a YAML file.
Desktop (please complete the following information):

OS: Windows 10 pro
Version v2.4.0-Datamart

Addressed in release 2.4.1-Datamart.


noImplicitAny checks don't work for a setter parameter of Object.defineProperty

TypeScript Version:
master
Code
Object.defineProperty({}, '', {
  set(a) { // a is an implicit any type
  }
});

Expected behavior:
error
Actual behavior:
pass

it gets a contextual type from the declaration, see https://github.com/Microsoft/TypeScript/blob/master/lib/lib.d.ts#L81.
we could change the definition of defineProperty to use TypedPropertyDescriptor instead of PropertyDescriptor, that will make your setter argument inferred from declaration, so it will be {} and not any, which would be closer to an error. but that would be a breaking change.

so just to be clear, the reported behavior is expected given the lib.d.ts definition. if there is anything to do is to change the definition in lib.d.ts

related: #8373

I don't think they are actually related.  It is being properly contextually typed as any.  What I think @mhegazy is suggesting is that it might be worth this being implemented in lib.d.ts in the future, as it stands at the moment it will always be non-implicit any because of the contextual typing:
interface PropertyDescriptor<T> {
    configurable?: boolean;
    enumerable?: boolean;
    value?: T;
    writable?: boolean;
    get? (): T;
    set? (v: T): void;
}

interface ObjectConstructor {
    defineProperty<T>(o: any, p: string, attributes: PropertyDescriptor<T>): any;
}

I suspect there are a few other places too that would need to be adjusted.

As noted earlier, there is a context type passed through, and that suppresses the noImplicitAny errors. you can get a better behavior by defining an extra overload of define property as:
interface ObjectConstructor {
    defineProperty<T>(o: any, p: string, attributes: TypedPropertyDescriptor<T>): any;
}

it is not clear there is much value in changing the lib.d.ts definitions for everybody though.


Rethink (im)mutabiltiy of device paths (DevicePathBuilder / install_protocol_interface)

DevicePathBuilder::finalize() returns a &DevicePath. If one wants to install this to a handle using install_protocol_interface, one has to cast that to a *mut c_void. It feels unhandy to change the mutability here.
Also, I'm not sure if install_protocol_interface could just consume a *const`. In the spec, I don't find something that says that this needs to be mutable:
https://uefi.org/specs/UEFI/2.10/07_Services_Boot_Services.html?highlight=install_protocol_interface
Code that uses this functionality can be found here: https://github.com/nix-community/lanzaboote/pull/194

🔝 I wonder if this is possible without (procedural) macros but only const functions 🤔

I agree with you that install_protocol_interface could just take a const pointer. Put up https://github.com/rust-osdev/uefi-rs/pull/981 for that.
Interesting idea about constructing const device paths. It's tricky in the general case since some nodes are rather dynamic. We'd also have to change our current trait-based approach (https://docs.rs/uefi/latest/uefi/proto/device_path/build/trait.BuildNode.html), since I don't think there's any way to declare const fns in traits yet.

I opened https://github.com/rust-osdev/uefi-rs/issues/983 for building device paths as constants. install_protocol_interface & co have been updated to take a const pointer, so closing this issue.


New package: NetEvolve v0.1.0

Registering package: NetEvolve
Repository: https://github.com/ltatka/NetEvolve
Created by: @ltatka
Version: v0.1.0
Commit: 058b2c068c70f3cfc5b44065dc57d1f07e300973
Reviewed by: @ltatka
Reference: https://github.com/ltatka/NetEvolve/commit/058b2c068c70f3cfc5b44065dc57d1f07e300973#commitcomment-142065816

Hi and congrats on the new package! I have questions about registration:

Can it really be useful to users outside of your specific project?
If so, can you come up with a more specific name, one that highlights the link to chemical reactions for instance?

Hi @gdalle,
Yes, there is use beyond the case I mentioned. You're right and I should update the readme to reflect that. There are three primary use cases in the field of systems biology

Evolving reaction networks with specific behaviors. The default is oscillation, but in the future I may add additional behaviors. Additionally, users can input time series that reflect those desired behaviors.
Evolving reaction networks (or ensemble models) to fit time series data. Often systems biologist will have timeseries data from experiments and will want to search for a reaction network (or group of them) that can recapitulate the time series data. This is useful for building models, informing future experiments or looking at output models for common reaction themes which may indicate the presence of those reactions in the ground truth.
Parameter (rate constants) fitting. In the case where model topology is known (for example, the biologist has already built the model from first principles) and wants to generate parameter values for those reactions that will recapitulate experimental time series data.

There are also some expansions I have planned for the future. In some cases, researchers might be certain of the presence of a few reactions but uncertain of the rest of the network. In this case, a user could input reactions and indicate the level of confidence they have that those reactions occur in the "true" system. The package would then evolve supplementary reactions to fit time series data.  Other expansions include different types of rate laws, more customizations of the evolution algorithm.
As you can see, the core functionality of the package is evolving networks, hence the name. But if you think it would be helpful or clarifying to indicate that the networks are specifically chemical reaction networks, I will try to think of a more informative name.
Thanks for the feedback. I will try to think of a new name and update the readme to reflect the utility of the package. And of course fix all the things that caused the automatic tests to fail.

Thanks for the answer!

There are three primary use cases in the field of systems biology

My bad, I had spontaneously associated "reaction networks" with chemical reactions, but it can be networks of, say, predator-prey interactions as well?

But if you think it would be helpful or clarifying to indicate that the networks are specifically chemical reaction networks, I will try to think of a more informative name.

The central tenet is that the name space for Julia packages is limited, so each time we take a spot, it's good to be as specific as possible. Abbreviations are usually discouraged, and longer are rarely a bad thing (you can always do import MyPackage as MP).

I will try to think of a new name and update the readme to reflect the utility of the package.

What about ReactionNetworksEvolution?


Malformed JSON for "Install the ServiceMap and InfrastructureInsights solutions"

The JSON for step "Install the ServiceMap and InfrastructureInsights solutions" is missing the closing braces at the end of the JOSN;  }
Add } to line 62

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

ID: 59ea9b7f-4a00-3623-7841-a06f71a9d224
Version Independent ID: 745cb2a2-f053-8410-553d-dc80eecb3304
Content: Onboard Azure Monitor for VMs (Preview)
Content Source: articles/monitoring/monitoring-vminsights-onboard.md
Service: azure-monitor
GitHub Login: @MGoedtel
Microsoft Alias: magoedte

@paulmackinnon-adv365 Thanks for bringing this to our attention. Your feedback has been shared with the content owner for further review.

Perhaps I could help fix this?

The clone's taking too long. How do you guys do it?

@fluffy-cakes - Apologies for not addressing this sooner.  I updated the code block and verified it is working as expected.  You should not have any issues applying it in the future.  #please-close.


Read karmor probe data  Ref kubearmor/kubearmor-client#19

Signed-off-by: Esther Adenekan<EMAIL_ADDRESS>

Ref https://github.com/kubearmor/kubearmor-client/issues/19

Codecov Report

Merging #822 (759eb05) into main (804b690) will decrease coverage by 4.07%.
The diff coverage is 59.67%.

@@            Coverage Diff             @@
##             main     #822      +/-   ##
==========================================
- Coverage   39.90%   35.82%   -4.08%
==========================================
  Files          30       31       +1
  Lines        9285     9347      +62
==========================================
- Hits         3705     3349     -356
- Misses       5092     5530     +438
+ Partials      488      468      -20

Impacted Files
Coverage Δ

KubeArmor/core/karmorprobedata.go
58.33% <58.33%> (ø)

KubeArmor/core/kubeArmor.go
46.69% <100.00%> (-3.97%)
:arrow_down:

KubeArmor/core/crioHandler.go
0.00% <0.00%> (-63.87%)
:arrow_down:

KubeArmor/core/dockerHandler.go
0.00% <0.00%> (-47.53%)
:arrow_down:

KubeArmor/monitor/processTree.go
85.48% <0.00%> (-10.22%)
:arrow_down:

KubeArmor/common/common.go
38.55% <0.00%> (-4.82%)
:arrow_down:

KubeArmor/core/containerdHandler.go
52.59% <0.00%> (-4.45%)
:arrow_down:

KubeArmor/monitor/logUpdate.go
68.19% <0.00%> (-3.28%)
:arrow_down:

KubeArmor/monitor/syscallParser.go
61.51% <0.00%> (-1.78%)
:arrow_down:

... and 3 more

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


Why govendor puts all sub packages to vendor.json?

Hi.
Say I'm using:
	"github.com/aws/aws-sdk-go/aws"
	"github.com/aws/aws-sdk-go/aws/session"
	"github.com/aws/aws-sdk-go/service/s3"

in my project. Why
govendor add +external
generates vendor.js with lot of garbage like this,
             {
		"checksumSHA1": "f7zg170Rm9Jh1QKLCpOD2dGvPTo=",
		"path": "github.com/aws/aws-sdk-go/aws",
		"revision": "69836214e899aa2562455259e32bd48a412ed036",
		"revisionTime": "2017-06-23T20:55:00Z"
	},
	{
		"checksumSHA1": "Y20DEtMtbfE9qTtmoi2NYV1x7aA=",
		"path": "github.com/aws/aws-sdk-go/aws/session",
		"revision": "69836214e899aa2562455259e32bd48a412ed036",
		"revisionTime": "2017-06-23T20:55:00Z"
	},
	{
		"checksumSHA1": "fEviiLbCHyTuedwpXTJSFNeu7FA=",
		"path": "github.com/aws/aws-sdk-go/service/s3",
		"revision": "69836214e899aa2562455259e32bd48a412ed036",
		"revisionTime": "2017-06-23T20:55:00Z"
	}

instead of inserting only the main package?
Thanks.
P.S.
For now, we may edit vendor.json manually and use:
			"tree": true
flag. But maybe there is a way to generate vendor.js to include only top-level packages?

govendor doesn't pay attention to "repo" only "package".


Removing the loading... indicator when we have an error

Fixes #249

Any tests?

@jankowiakmaria here I got some tests 👍


macOS port

I'm interested in building a true native macOS client. Is there any reason this framework couldn't (or shouldn't) include a macOS build target?
I'm currently looking into adding it myself. A lot of the work appears to be replacing the UI* classes with their NS* counterparts, like so:
#if TARGET_OS_IPHONE
    UIImage* foo;
#elif TARGET_OS_OSX
    NSImage* foo;
#endif

... and then #import <Cocoa/Cocoa.h> instead of <UIKit/UIKit.h> when the platform is macOS
I notice that the OLMKit pod currently doesn't support macOS, but after a very brief (10 min) skim through that project, it looks like that would be portable to macOS as well. However, since it's hosted on matrix.org instead of github, I'm not sure what the protocol is for contributing.

It would be absolutely awesome to have a true native macOS client.  matrix-ios-sdk itself is a relatively low level library that wraps and manages the Matrix HTTP API itself, and can probably be made to build for macOS very easily indeed.  However, all the UI stuff (e.g. UIImage and friends) lives in matrix-ios-kit (MatrixKit), which I think is more where the porting work would need to happen.
Many bits of MatrixKit probably can be made to support both targets, but there's going to be some higher level layers which will probably need entirely separate macOS variants rather than using #ifdefs.  For instance, I suspect you'd need to build a separate tree of XIBs for macOS in addition to the current iOS ones, and of course the storyboard of the app itself will need to be different.
My suggestion (beware: i've not actually hacked on matrix-ios-kit and matrix-ios-sdk that much and am a bit rusty on iOS dev) would be to fork matrix-ios-sdk and matrix-ios-kit on Github, take the MatrixKitSample app (https://github.com/matrix-org/matrix-ios-kit/tree/develop/Samples/MatrixKitSample), and try working your way through, adding in ifdefs, as well as 'forking' the XIBs & Storyboards to support macOS.  Perhaps you may not need to fork any actual controllers themselves.
In terms of OLMKit: libolm itself builds on OSX, although the Makefile requires minimal tweaking; i currently have:
diff --git a/Makefile b/Makefile
index 438fa68..db0e701 100644
--- a/Makefile
+++ b/Makefile
@@ -15,8 +15,8 @@ EMCC = emcc
 AFL_CC = afl-gcc
 AFL_CXX = afl-g++

-RELEASE_TARGET := $(BUILD_DIR)/libolm.so.$(VERSION)
-DEBUG_TARGET := $(BUILD_DIR)/libolm_debug.so.$(VERSION)
+RELEASE_TARGET := $(BUILD_DIR)/libolm.dylib.$(VERSION)
+DEBUG_TARGET := $(BUILD_DIR)/libolm_debug.dylib.$(VERSION)
 JS_TARGET := javascript/olm.js

 JS_EXPORTED_FUNCTIONS := javascript/exported_functions.json
@@ -107,10 +107,8 @@ lib: $(RELEASE_TARGET)

 $(RELEASE_TARGET): $(RELEASE_OBJECTS)
        $(CXX) $(LDFLAGS) --shared -fPIC \
-            -Wl,-soname,libolm.so.$(MAJOR) \
-            -Wl,--version-script,version_script.ver \
             $(OUTPUT_OPTION) $(RELEASE_OBJECTS)
-       ln -sf libolm.so.$(VERSION) $(BUILD_DIR)/libolm.so.$(MAJOR)
+       ln -sf libolm.dylib.$(VERSION) $(BUILD_DIR)/libolm.dylib.$(MAJOR)

 debug: $(DEBUG_TARGET)
 .PHONY: debug

...although obviously that should be built into the Makefile itself.  I know of no reason why OLMKit itself couldn't be made to trivially build on macOS.  The reason it sits on matrix.org/git rather than github is purely legal (the code has been written by folks in the UK & France, and we don't want to have to jump through cryptography re-export hoops by importing it to Github in the US, and thus be responsible when folks then export it out of the US again by downloading it from Github.  matrix.org/git is hosted in the UK & Holland, so we sidestep having to worry about US export compliance).

@aapierce0 out of interest, are you getting anywhere with a macOS client? someone else was asking about this just now in Matrix HQ

I have something that connects to a home server, but I wouldn't recommend anyone use it. Right now, it's only able to authenticate a user with a username/password, show them the rooms they're already part of, and allow them to chat (text only) in those rooms.
https://github.com/aapierce0/MatrixClient

Ooh, this looks incredibly promising :D let us know if there's any way we can help :)


Addresses #1910 Build eye slim

Addresses #1910 Build eye slim

We must wait for PR #1939 to merge, so the "upper slim" QC would run here.
When it's merged, we need to add eye to the list of slims in the cl.Makefile.

Is a QC/coverage report available for this subset or does https://github.com/obophenotype/cell-ontology/pull/1939 have to be merged first?

Is a QC/coverage report available for this subset or does #1939 have to be merged first?

#1939 have to be merged first.

I've run the report in my local;
#####Coverage percentage#####
85.47%
#####Number of terms covered by each term in the slim#####
retinal cell,61
retinal bipolar neuron,19
iris pigment epithelial cell,1
retina horizontal cell,26
compound eye retinal cell,1
corneal endothelial cell,1
photoreceptor cell,19
scleral cell,1
choroidal cell of the eye,1
crystallin accumulating cell,12
amacrine cell,33
conjunctival epithelial cell,2
corneal epithelial cell,1
#####Terms that are not covered by 1910_eye_SLIMS.csv under UBERON:0000970#####
http://purl.obolibrary.org/obo/CL_0000315,tear secreting cell
http://purl.obolibrary.org/obo/CL_0002243,smooth muscle cell of sphincter of pupil
http://purl.obolibrary.org/obo/CL_0002303,pigmented ciliary epithelial cell
http://purl.obolibrary.org/obo/CL_0002304,non-pigmented ciliary epithelial cell
http://purl.obolibrary.org/obo/CL_0002363,keratocyte
http://purl.obolibrary.org/obo/CL_0002367,trabecular meshwork cell
http://purl.obolibrary.org/obo/CL_0002485,retinal melanocyte
http://purl.obolibrary.org/obo/CL_0002550,fibroblast of the conjunctiva
http://purl.obolibrary.org/obo/CL_1000391,melanocyte of eyelid
http://purl.obolibrary.org/obo/CL_1000433,epithelial cell of lacrimal canaliculus
http://purl.obolibrary.org/obo/CL_1000435,epithelial cell of lacrimal duct
http://purl.obolibrary.org/obo/CL_1000436,epithelial cell of lacrimal sac
http://purl.obolibrary.org/obo/CL_1000437,epithelial cell of nasolacrimal duct
http://purl.obolibrary.org/obo/CL_1000443,ciliary muscle cell
http://purl.obolibrary.org/obo/CL_1000444,mesothelial cell of anterior chamber of eye
http://purl.obolibrary.org/obo/CL_1000445,myoepithelial cell of dilator pupillae
http://purl.obolibrary.org/obo/CL_2000070,optic choroid fibroblast
http://purl.obolibrary.org/obo/CL_4030000,choroidal melanocyte

Thank you for running it, @ubyndr. I will have another look to see if I can improve the coverage.

CL:0009004,http://purl.obolibrary.org/obo/cl#eye_upper_slim,retinal cell

Selecting this term would result in overlap with other terms ('retinal bipolar neuron','retina horizontal cell'). Consider if 'retinal cell' is too broad or if the subclasses are unnecessary.

Selecting this term would result in overlap with other terms ('retinal bipolar neuron','retina horizontal cell'). Consider if 'retinal cell' is too broad or if the subclasses are unnecessary.

The subclasses are unnecessary. I will clean them.

Thank you for running it, @ubyndr. I will have another look to see if I can improve the coverage.

I've updated the reports, fyi

According to the report, there is overlap with 'retinal cell' and 2 other classes. Since 'retinal cell' seems quite broad and this subset seems to have a retina bias anyway, consider replacing 'retinal cell' with the major subclasses under 'retinal cell'.

According to https://github.com/obophenotype/cell-ontology/pull/1940#issuecomment-1513495276, there is overlap with 'retinal cell' and 2 other classes. Since 'retinal cell' seems quite broad and this subset seems to have a retina bias anyway, consider replacing 'retinal cell' with the major subclasses under 'retinal cell'.

I have tested it. The coverage falls slightly from 84% to 77%. These numbers are slightly higher in reality, as it doesn't include the 11 new terms I added recently. However, now it misses some cells like retinal astrocyte, retinoblast and Mueller cell, which are important. I guess it is ok to add the in the slim, but there might be too many classes that do not group.

This is the current coverage. There are some terms that might be too specific, though.

@aleixpuigb, can you remind me what constitutes the denominator for the percentages reported in these reports? I don't see 'retinal ganglion cell' mentioned in these reports, which I would consider a major cell type in the eye.

@aleixpuigb, what constitutes the denominator for the percentages in these reports?
'retinal ganglion cell' is missing in the reports, which is a major cell type in the eye.

'retinal ganglion cell' is in the slim. However, it is not captured in the coverage:
'retinal ganglion cell' has two axioms:

CNS neuron (sensu Vertebrata)
has soma location some retina

Moreover, retina also has 'has part' some 'retinal ganglion cell'. It seems that the query cannot capture these relationships. I understand 'has part' is not captured, as not all of x are part of y. However, 'has soma location; I think it should be considered. What do you think, @bvarner-ebi and @ubyndr?

Hi @aleixpuigb and @bvarner-ebi  , I've created this report by adding 'has soma location' RO:0002100 to the coverage script in my local environment. I can also test the blood_and_immune_upper_slim and share the updated report with you. Then we can decided whether to add it or not.
#####Coverage percentage#####
88.17%
#####Number of terms covered by each term in the slim#####
corneal epithelial cell,1
Mueller cell,1
iris pigment epithelial cell,1
retinal blood vessel endothelial cell,1
compound eye retinal cell,1
retinoblast,1
retinal astrocyte,1
corneal endothelial cell,1
scleral cell,1
choroidal cell of the eye,1
conjunctival epithelial cell,2
crystallin accumulating cell,12
retinal bipolar neuron,19
photoreceptor cell,19
retina horizontal cell,31
amacrine cell,33
retinal ganglion cell,64
#####Terms that are not covered by src/templates/eye_upper_slim.csv under UBERON:0000970#####
http://purl.obolibrary.org/obo/CL_0011104,interplexiform cell
http://purl.obolibrary.org/obo/CL_0011105,dopamanergic interplexiform cell
http://purl.obolibrary.org/obo/CL_0011106,GABAnergic interplexiform cell
http://purl.obolibrary.org/obo/CL_1000391,melanocyte of eyelid
http://purl.obolibrary.org/obo/CL_1000433,epithelial cell of lacrimal canaliculus
http://purl.obolibrary.org/obo/CL_1000435,epithelial cell of lacrimal duct
http://purl.obolibrary.org/obo/CL_1000436,epithelial cell of lacrimal sac
http://purl.obolibrary.org/obo/CL_1000437,epithelial cell of nasolacrimal duct
http://purl.obolibrary.org/obo/CL_1000443,ciliary muscle cell
http://purl.obolibrary.org/obo/CL_1000444,mesothelial cell of anterior chamber of eye
http://purl.obolibrary.org/obo/CL_1000445,myoepithelial cell of dilator pupillae
http://purl.obolibrary.org/obo/CL_2000070,optic choroid fibroblast
http://purl.obolibrary.org/obo/CL_4030000,choroidal melanocyte
http://purl.obolibrary.org/obo/CL_0000315,tear secreting cell
http://purl.obolibrary.org/obo/CL_0002243,smooth muscle cell of sphincter of pupil
http://purl.obolibrary.org/obo/CL_0002303,pigmented ciliary epithelial cell
http://purl.obolibrary.org/obo/CL_0002304,non-pigmented ciliary epithelial cell
http://purl.obolibrary.org/obo/CL_0002363,keratocyte
http://purl.obolibrary.org/obo/CL_0002367,trabecular meshwork cell
http://purl.obolibrary.org/obo/CL_0002485,retinal melanocyte
http://purl.obolibrary.org/obo/CL_0002550,fibroblast of the conjunctiva
http://purl.obolibrary.org/obo/CL_0002586,retinal pigment epithelial cell

I've created this report by adding 'has soma location' RO:0002100 to the coverage script in my local environment. I can also test the blood_and_immune_upper_slim and share the updated report with you.

@ubyndr need to think of a way to generalise this too. Not all slim will use the same logical axioms as context.

need to think of a way to generalise this too. Not all slim will use the same logical axioms as context.

We had a small discussion with @aleixpuigb and @bvarner-ebi, I've just added it to see the affect of that axiom. When we finalise the discussion we can make necessary changes. Currently we still use part of and subClassOf relations


CI: Add github workflow using Apple M

going to split this into cmake fixes and the originally intended gh workflow


Add CJS/ESM module exports

With this pull request I am adding the support for both CJS and ESM module export. This will allow for example bundlers like webpack, rollup, vite, ... to threeshake any unnecessary code when writing web apps
To achieve this I ended up using rollup (easy to understand and configure) in combination with esbuild (for its speed)
I also update caniuse-lite to latest version (solved a warning during build) and typescript to latest version (due to an issue of version 4.4.2 (https://github.com/rollup/plugins/issues/983)
This pull request relates to discussion #49
Resolves #79

Have you done testing to make sure that the resulting ESM target is tree shakable? Just because it's ESM-compatible doesn't guarantee that it's tree-shakable, so I just want to confirm. Honestly, I don't think bundling everything in a single index.js file is ideal, would be best to leave it as separate files, but as long as it's tree shakable and sourcemaps are generated correctly, it shouldn't matter much.

I tried it using Vite (so Rollup + esbuild) and it was threeshaking perfectly. If you want to try it out wiht webpack, please feel free to do so. Easiest way to try this out is to clone the branch containing these changes, yarn pack to get the .tar.gz, then create a new webpack based project and install it from the .tar.gz archive, then see if it works with webpack too
Regarding the single file vs multiple file, I opted for single file just to make the lib a bit smaller, but If you think multiple files is preferable then I will update it tomorrow toghether with the tsconfig options

Okay, thank you.

I can confirm that also with webpack it is three shaking correctly! I've tested it on vue-cli project I have and these are the results
Code added
import * as _ from "radash";
console.log(_.first([1, 2, 3]));

Here are the differences

Build size withouth above code

chunk-vendors.45b3efd9.js - 269.15 KiB

Build size with above code and current version of radash available on npm

chunk-vendors.45b3efd9.js - 291.06 KiB

Build size with above code and the new version of radash containing the changes in this PR

chunk-vendors.45b3efd9.js - 269.26 KiB

esnext does not work with node 12. Following the mapping reported already previously (https://github.com/microsoft/TypeScript/wiki/Node-Target-Mapping) I will go to es2019 to support node 12 and above

No idea why the pipeline failed, it seems to be related to something  I did not actually touch (and btw, with same node version test pass locally...). If you can @rayepps, rerun the workflow.
Anyway, I added something with respect to the previous commit, which I will specify here:
  "exports": {
    "import": "./dist/esm/index.mjs",
    "require": "./dist/cjs/index.cjs",
    "types": "./dist/index.d.ts"
  },

I added the exports section and I used the .cjs and .mjs extensions to make sure that node uses the correct loader.
It should be something minor, and three-shaking works, I can confirm that

@matteosacchetto I love this! I'm so excited to merge it. A bunch of PRs were merged recently so there is a new conflict but it's an easy one in the yarn.lock. I cloned your branch and ran it all locally, did some testing 👍 works perfectly.
@gander I would love to know how to improve that test cus I agree, it's dumb 😃

@rayepps I have resolved the conflict with the yarn lock and kept typescript version 4.8.3
Since a couple of weeks back typescript 4.8.4 was release, do you want me to bump the version before merging?

@matteosacchetto can you run rm yarn.lock && yarn this way you'll just regenerate the yarn.lock (thats what I did locally)
I just published 8.0.0-rc.1 from this branch if you want to install it.

This is awesome, I don't understand how/why but this CJS/ESM change brought the package size down by almost half, as well as providing the tree shaking 🤩

@matteosacchetto can you run rm yarn.lock && yarn this way you'll just regenerate the yarn.lock (thats what I did locally)
I just published 8.0.0-rc.1 from this branch if you want to install it.

I run rm yarn.lock && yarn and pushed the changes

Again, issue on the same test mentioned above by @gander

This is awesome, I don't understand how/why but this CJS/ESM change brought the package size down by almost half, as well as providing the tree shaking star_struck

The main reason of the smaller size is the bump on the tsconfig lib and target, so it is doing less transpilation and taking advantage of more modern JS

I made an issue to fix the issue in the tests (#102)
cc: @gander

I'm glad this was merged. When is it going to be released?

@gustavopch it will go out in 2 days (Monday) in v8.0.0. I'm working on a few other changes for the major release and I also happen to currently be traveling 😅


[MXNET-414] Tutorial on visualizing CNN decisions using Grad-CAM

Description
Tutorial on visualizing CNN decisions using Grad-CAM
Checklist
Essentials
Please feel free to remove inapplicable items for your PR.

[x] The PR title starts with [MXNET-$JIRA_ID], where $JIRA_ID refers to the relevant JIRA issue created (except PRs with tiny changes)
[x] Changes are complete (i.e. I finished coding on this PR)
[x] All changes have test coverage:
[x] Code is well-documented:
[x] For new examples, README.md is added to explain the what the example does, the source of the dataset, expected performance on test set and reference to the original paper if applicable
Check the API doc at http://mxnet-ci-doc.s3-accelerate.dualstack.amazonaws.com/PR-$PR_ID/$BUILD_ID/index.html

@indhub I think you forgot to edit the docs/tutorials/index.md file to add your tutorial to the list

Awesome tutorial @indhub! Makes me wonder if the visualization could make its way to the contrib package at some point rather than example folder :)


Should _default_get be inherited on chained operations?

>>> dd = distributed_executor.persist(local_dd)
>>> dd._default_get
<function dask.threaded.get>
>>> dd._default_get = distributed_executor.get
>>> dd.head(compute=False)._default_get
<function dask.threaded.get>

Due to the fact that currently _default_get is not inherited, I'm getting a weird traceback if I do dd.head():
>>> dd.head()
/opt/conda/lib/python3.5/site-packages/dask/dataframe/core.py in head(self, n, compute)
    369
    370         if compute:
--> 371             result = result.compute()
    372         return result
    373

/opt/conda/lib/python3.5/site-packages/dask/base.py in compute(self, **kwargs)
     35
     36     def compute(self, **kwargs):
---> 37         return compute(self, **kwargs)[0]
     38
     39     @classmethod

/opt/conda/lib/python3.5/site-packages/dask/base.py in compute(*args, **kwargs)
    108                 for opt, val in groups.items()])
    109     keys = [var._keys() for var in variables]
--> 110     results = get(dsk, keys, **kwargs)
    111
    112     results_iter = iter(results)

/opt/conda/lib/python3.5/site-packages/dask/threaded.py in get(dsk, result, cache, num_workers, **kwargs)
     55     results = get_async(pool.apply_async, len(pool._pool), dsk, result,
     56                         cache=cache, queue=queue, get_id=_thread_get_id,
---> 57                         **kwargs)
     58
     59     return results

/opt/conda/lib/python3.5/site-packages/dask/async.py in get_async(apply_async, num_workers, dsk, result, cache, queue, get_id, raise_on_exception, rerun_exceptions_locally, callbacks, **kwargs)
    486                 _execute_task(task, data)  # Re-execute locally
    487             else:
--> 488                 raise(remote_exception(res, tb))
    489         state['cache'][key] = res
    490         finish_task(dsk, key, state, results, keyorder.get)

AttributeError: 'Future' object has no attribute 'head'

Traceback
---------
  File "/opt/conda/lib/python3.5/site-packages/dask/async.py", line 267, in execute_task
    result = _execute_task(task, data)
  File "/opt/conda/lib/python3.5/site-packages/dask/async.py", line 249, in _execute_task
    return func(*args2)
  File "/opt/conda/lib/python3.5/site-packages/dask/dataframe/core.py", line 365, in <lambda>
    dsk = {(name, 0): (lambda x, n: x.head(n=n), (self._name, 0), n)}

It also seems that _default_get is not used much (I would expect distributed_executor.persist() set it automatically; am I doing something wrong?)

You should use the following:
dask.set_options(get=distributed_executor.get)

_default_get is a class attribute and not something that users should feel comfortable changing.

dask.set_options is a global setting, and I'm not a fan of global changes. Especially, when local setting is expected to work.

You can use set_options as a context manager.  You can supply get=e.get in any compute call.  Are these options sufficient for you?
You should treat dd._default_get as global as well, just a global option that is not supported or intended.

I can live even with ugly API, but I would like to make it better. Wrapping data with e.persist, I expect that my next operations on this data are performed wherever my data is persistent on, and I certainly wouldn't expect to get 'Future' object does not have a method...

Agreed.  I've run across that error as well and it took me (who presumably wrote the error message) a while to figure out what was going on.
One option is to have the Executor set itself as default upon construction (see https://github.com/dask/distributed/pull/319).  This is pretty robust but does affect global state.
Making _default_get a field and passing it through is possible, but would take a lot of work, both today and for all future changes to dask.dataframe.
We could also try to catch that error and redirect to the last constructed Executor.
Any thoughts or suggestions on how best to handle this?

The intrinsic problem here is that dask graphs are separate from the scheduler.  This was an early decision that helped tremendously (for example all of the dask collections work today with the distributed scheduler, which was constructed after they were designed) but this freedom does cause ambiguity and opportunities for the user to shoot themselves in the foot.

Making _default_get a field and passing it through is possible, but would take a lot of work, both today and for all future changes to dask.dataframe.

Hmm, why are you talking like there is no _default_get implementation at all? (It is a part of dask.base.Base implementation.)

One option is to have the Executor set itself as default upon construction (see dask/distributed#319). This is pretty robust but does affect global state.

Why don't just set _default_get on a persisted instance, and inherit _default_get on chained operations?

You can use set_options as a context manager.

The implementation doesn't seem to be thread-safe, so I would avoid using it as much as possible.

_default_get is a static field on the class, not on the objects.  We would need to pass it around through all operations.  We would also need to figure out what to do when two different objects with different default-gets interact.  I'm not saying no to this I'm just saying that it's a lot of work.  If you're interested in implementing it then please I'd love to see a PR.  I think it'd be a great addition.
Regarding thread-safety of set_options I've found it to be very effective.  I tend not to run many dask programs in separate threads though.   Given your reaction here I assume that you presumably do.

_default_get is a static field on the class, not on the objects.

Silly me. Sorry, I missed this.

We would also need to figure out what to do when two different objects with different default-gets interact.

I am fine with the current behaviour, which is to raise an exception: https://github.com/dask/dask/blob/master/dask/base.py#L166
I will see how far I can get with my ideas.

As Matt said above, _default_get is an attribute of the class itself, and not meant for mucking with. If you'd like to discuss changes to how this works, #1068 was an attempt to codify this as a public spec for use by other packages. Closing for now, feel free to reopen if you're still interested in this.


Initial implementation of tracing interceptor

Initial implementation of tracing interceptor.

[x] tracing interceptor
[x] javadoc
[x] integration tests
[x] mvnw
[x] release configuration

Decorator STANDARD_TAGS adds HTTP and PEER tags. However on redirects HTTP_URL is set to original URL, but PEER tags point to redirected host.
I think it can be confusing.
@yurishkuro @bensigelman

@bensigelman thanks for review :+1:
Basically in all these java-instrumentations users have to pass/access context manually in various ways.
It would be great to have a standard way to access active/last span context.
It is my first step to instrument various frameworks and then work on how to simplify accessing active span context.

@pavolloffay let me know when/if you'd like me to take another look at this. (I'm doing a survey of PRs I should be looking at right now :)

@bensigelman thanks! This needs some hacks,  I will let you know :+1:

PR updated. I got rid of threadlocal and everything is passed via request#tag(). Tag is wrapped to TagWrapper with tracing data.
@swankjesse thanks for the review I really appreciate it :+1:  If you could have a quick look it would be great :100: .

@bensigelman @swankjesse @objectiser thanks for reviews :+1: !


Kinematic Body (3d) infinite_inertia false still moving RigidBody

Godot version:
3.2.1 Stable
OS/device including version:
Windows 10
In the documentation, it says that if the infinite_inertia parameter for move_and_slide is false then it will not interact with RigidBody. It says that it would treat it as if it were a StaticBody. However, with this parameter false, it still is moving the RigidBody. If GodotPhysics is selected instead of Bullet for the physics engine, the game just crashes.
Also tested a similar setup with Godot 4.0 branch and the results are the same
KinematicBug.zip

duplicate:
https://github.com/godotengine/godot/issues/31981
https://github.com/godotengine/godot/issues/33988

Closing as duplicate of #31981.


MRG, ENH: Add cov.plot_topomap

Closes #7384
Closes #8183

Also adds support for time_label='' to avoid having the time printed.
With a bit of squaring, we get correct units / scale factors / whitening compared to what's in master.

master versus PR

Travis is failing on 3.8 segfaulting on plot_source_estimates, hopefully just spurious

thx @larsoner !


Feature request: optimize permutable nested prange

Feature request
I have a function with three nested range loops. I optimize it using @njit(parallel=True).
The size of the ranges really depends, and some can be trivial (range(1)).
Doing some testing I observed that the only way to parallelize all three is to use prange on each.
But now, I observe that permuting the three loops changes the performance (my loop sizes are very unequal, one range is ~2000 and the other ~20), which is understandable (I think only the outermost prange is used).
What do you recommend? The best solution would be to support a way for numba to understand that you can permute the loops depending on their size / for cache hit optimization (think generalized prange). Numba could maybe even "test" the order and select the best one, while running (not sure it makes any sense).
Nested loops have this structure:
for i1 in prange(n1):
    # code before
    for i2 in prange(n2):
        # recursive structure
    # code after

If there is no code before or after or if it is fast, supporting a permutable version of itertools.product would be sufficient (like a pproduct).
for i1, i2, i3 in pproduct(range(n1), range(n2), range(n3)):
    # code before 1
    # code before 2
    # code before 3
    # code inside
    # code after 3
    # code after 2
    # code after 1

Else, one should ensure that the "code before" in prange(n2) doesn't use i1 by computing a dependency graph or providing a syntax for the user to specify it. For example:
l1, l2, l3 = permutable(range(n1), range(n2), range(n3))
for i1 in l1:
    # code before
    for i2 in l2:
        # recursive structure
    # code after

Thanks for the request. Extracting the code from https://stackoverflow.com/questions/50255126/numba-doesnt-parallelize-range below.
from numba import njit, prange
from time import time

@njit
def f1(n):
    s = 0
    for i in range(n):
        for j in range(n):
            for k in range(n):
                s += (i * k < j * j) - (i * k > j * j)
    return s

@njit
def f2(n):
    s = 0
    for i in prange(n):
        for j in prange(n):
            for k in prange(n):
                s += (i * k < j * j) - (i * k > j * j)
    return s

@njit(parallel=True)
def f3(n):
    s = 0
    for i in range(n):
        for j in range(n):
            for k in range(n):
                s += (i * k < j * j) - (i * k > j * j)
    return s

@njit(parallel=True)
def f4(n):
    s = 0
    for i in prange(n):
        for j in prange(n):
            for k in prange(n):
                s += (i * k < j * j) - (i * k > j * j)
    return s

for f in [f1, f2, f3, f4]:
    d = time()
    f(2500)
    print('%.02f' % (time() - d))

As Numba is using JIT compilation, the timing part of the code above is including the compilation time as well as the execution time in the reported time. For reference, the above gives me:
21.39
21.18
21.20
14.00

editing the timing part of the code so that it is just timing execution:
for f in [f1, f2, f3, f4]:
    f(10) # invoke once with the type used in the timed section to trigger compilation
    d = time()
    f(2500)
    print('%.02f' % (time() - d))

gives:
21.09
20.92
20.92
12.71

it doesn't make much difference as the compute part of the code is quite heavy for the given n, but it should always be considered.
As to the four variants of the loop and what is observed in the timings:
@njit
def f1(n):
    s = 0
    for i in range(n):
        for j in range(n):
            for k in range(n):
                s += (i * k < j * j) - (i * k > j * j)
    return s

Function f1 is a standard CPU compiled triple nested loop.
@njit
def f2(n):
    s = 0
    for i in prange(n):
        for j in prange(n):
            for k in prange(n):
                s += (i * k < j * j) - (i * k > j * j)
    return s

Function f2 has loops declared with prange, but no parallel=True option set in njit, as a result the compiler sees prange as an alias of range.
@njit(parallel=True)
def f3(n):
    s = 0
    for i in range(n):
        for j in range(n):
            for k in range(n):
                s += (i * k < j * j) - (i * k > j * j)
    return s

Function f3 has parallel=True so analysis for transforming the code to execute in parallel will happen, however, the analysis correctly decides that there is nothing to parallelize (no loop was declared as parallel with prange). The example referred to in the parallel documentation that contains range is parallelizing the loop body which contains many computations on arrays, it is these that are fused and transformed into a parallel region. In the example it is also worth nothing that w is a loop carried dependency (iteration i+1 needs the result from iteration i) and so an embarrassingly parallel loop execution is not possible.
@njit(parallel=True)
def f4(n):
    s = 0
    for i in prange(n):
        for j in prange(n):
            for k in prange(n):
                s += (i * k < j * j) - (i * k > j * j)
    return s

Function f4 has parallel=True and the loops are all declared with prange, this allows analysis for transforming the code to execute in parallel and as there are explicitly declared parallel loops that are suitable for parallel transformation the transform is done and the code runs more quickly.
Declaring prange on inner loops when there is an outer loop prange translates to the inner ones being run as range loops, this prevents nested parallelism and also makes it such that larger work blocks are available per thread.
The information about what parallel=True is doing can be found by setting the environment variable NUMBA_DEBUG_ARRAY_OPT_STATS, with this set the terminal states:
Function f3 has no Parfor.
Parallel for-loop #0 is produced from pattern '('prange', 'user')' at issue2960.py (41)
Parallel for-loop #1 is produced from pattern '('prange', 'user')' at issue2960.py (40)
Parallel for-loop #2 is produced from pattern '('prange', 'user')' at issue2960.py (39)
After fusion, parallel for-loop After fusion has 1 nested Parfor(s) #1.
After fusion, parallel for-loop After fusion has 2 nested Parfor(s) #1.
After fusion, function f4 has 1 parallel for-loop(s) #{2}.

Which shows f3 has no parfor transform, and f4 has 3 parallel loops identified from prange and it fuses them into a single loop (loop 2, the outer one).
In answer to your feature request... at present Numba compiles code based on the type of the arguments and not the values, it also compiles everything to machine code upfront and dispatches to compiled code based purely on type. The behaviour described in the feature request requires analysis based on run time values and so is more amenable to a tracing JIT which could feasibly analyse a loop nest instance at run time and perform dynamic loop nest optimisations. However, this is out of the scope of what Numba can do at present, I would think https://github.com/numba/numba/issues/2949 will help towards being able to achieve this though.
This all said, I think you will get loop nest optimisation from the LLVM backed via e.g. loop switching if you use loop bounds that are fixed at compile time, e.g. if you declare your loops having a fixed sized like range(20).

Hi, thanks you for this very precise answer.
Do you have any hints about the loop order that fits best? I think the best performance is achieved when the outer loop is bigger, but in a concrete world example, i, j and k could also be array indexes and SIMD would be eventually used ; so I think the order of the innermost loops counts as well.
Another temporary solution would be to write the code multiple times with different orders and select heuristically the best one. In my real world example, changing the loop order reduced my running time of more than 30% (and it wasn't even the worst possible case).

For an arbitrary loop nest with a trivial, largely memory access free, body in which loops can be interchanged there's unlikely to be an advantage of parallelizing one over the other.
What will matter in practice will be your data access patterns and instruction selection as it is unlikely that the loop body is trivial as per the examples. The loop order can in part can be guided by prior knowledge of the hardware and data layout, but should also be informed by profiling and testing. It is probably worth reading the performance tips page, and if you feel so inclined looking at the .inspect_llvm() and .inspect_asm() methods on the CPU dispatcher objects (the object returned by decorating a function with a @jit family decorator) to see the LLVM IR and assembler generated respectively.

This raises an interesting question of how to do effective metaprogramming in Python.  Ideally, you would want a factory function that could generate code with different loop permutations, benchmark each, and then pick the best one for the rest of the application run.  (I've used this technique to pick CUDA thread grid configurations with great success.)
Unfortunately, there isn't an easy way to do this kind of code generation in Python (probably not in most languages).  There's no macro system, so much of the metaprogramming that Numba does internally is achieved by constructing strings of Python source code, execing them on the fly, and then feeding the resulting function object to the Numba compiler.

Thank you, I was looking for the work metaprogramming. I think that just permuting loop products is easy. The idea here would not to benchmark them but to optimize the iteration order. Don't hesitate to correct me, I don't know very well the inners of numba (I'm starting to read the code), but I think it would be possible (although not trivial).

I think the LLVM IR generated will essentially be invariant of loop permutation if the inner loop body is trivial.
The general class of problem presented as optimising loop iteration order for non-trivial cases without benchmarking is hard, but tools like https://polly.llvm.org/ can help. I've added https://github.com/numba/numba/issues/2996 as a reminder to consider adding this to the Numba LLVM builds.
If your problem is not amenable to text based generation, either mutation of .__code__.* and instantiating a types.CodeType then types.FunctionType can work, or AST manipulations via inspect and ast could also be successful.

Closing this question as it seems to be resolved. Numba now has a discourse forum https://numba.discourse.group/ which is great for questions like this, please do consider posting there in future :) Thanks!


After silent install and autorun, the settings icon does not appear

Environment
Windows build number: 10.0.18363.720
PowerToys version: 0.17.0
PowerToy module for which you are reporting the bug (if applicable):

Steps to reproduce

Install PowerToys silently with the system account, reboot
Start PowerToys as user and set "run at startup", reboot
PowerToys process is startet (taskmanager), but the settings icon in the taskbar is not there

Expected behavior
Settings icon in the taskbar should be there
Actual behavior
Settings icon in the taskbar is not there
Screenshots

@enricogior, should .20 fix this?

@crutkas
not sure what this bug is about: the icon is not in the tray?
A silent install shouldn't make any difference in the first place.

@Birba80 this is pretty old issue, does this still occur with 0.20 or newer builds?

@crutkas This has been fixed. It works now


Reverse proxy without exposing ports

Description
Both my NPM and Jellyseer are on the same docker network, and this should be sufficient for NPM to access Jellyseer, without exposing port 5055 on the entire docker machine. However, it currently isn't, and port mapping 5055:5055 has to explicitly be specified, for reverse proxy to work.
Details
I am accessing Jellyseer behind a reverse proxy (NPM), as jellyseer.example.org

I don't want to expose the 5055 port for the entire docker machine
Both my NPM and Jellyseer are on the docker network media-services
When I remove the ports section from my Jellyseer compose.yaml — I get a 502 Bad Gateway error from NPM
When I put the ports section back — it works fine
My NPM is accessing Jellyseer via the internal docker network via http://jellyseer:5055
I have tried using expose instead of ports and it doesn't work

Compose
I have the following configuration in my Jellyseer's compose.yaml:
  jellyseerr:
    container_name: jellyseerr
    image: fallenbagel/jellyseerr:latest
    networks:
      media-services:
        ipv4_address: <IP_ADDRESS>
    depends_on:
      - jellyfin
      - radarr
      - sonarr
    volumes:
      - jellyseer-config:/app/config
    environment:
      - TZ=Europe/Kyiv
      - LOG_LEVEL=debug
      - PORT=5055
    ports:
      - 5055:5055 // <-- I want to remove this
    expose:
      - 5055 // <-- This doesn't help either

In my NPM, I configured the custom config in the Advanced section:
location / {
  proxy_pass http://jellyseer:5055;
  proxy_set_header Host $host;
  proxy_set_header X-Real-IP $remote_addr;
  proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
  proxy_set_header X-Forwarded-Proto $scheme;
  proxy_set_header X-Forwarded-Protocol $scheme;
  proxy_set_header X-Forwarded-Host $http_host;
  proxy_buffering off;
}

Version
2.0.1
Steps to Reproduce

Remove ports from compose.yml
NPM reverse proxy gives 502 Bad Gateway
Add ports back to compose.yml
Reverse proxy works
It should work without ports when both NPM and Jellyseer are on the same docker network

Screenshots
No response
Logs
No response
Platform
desktop
Device
Browser
Operating System
Docker on Ubuntu
Browser
Chrome
Additional Context
No response
Code of Conduct

[X] I agree to follow Jellyseerr's Code of Conduct

This is more of a troubleshooting configuration issue and I would suggest you move this over to discord and also share you nginx proxy manager docker compose. This is more of a docker configuration thing and not related to jellyseerr.

Maybe this is an issue with the docker image itself? @Fallenbagel
I'll join discord and provide more info tomorrow, thanks!

Maybe this is an issue with the docker image itself? @Fallenbagel

As mentioned above, many have this exact same setup (i can vouch for it too because I personally have + have helped people out with out issues that had the exact same type on docker networking Setup which is why im asking for troubleshooting first)

Extremely sorry for the confusion and hassle! I had a typo where in some places jellyseer was used, versus jellyseer in others, single r. No idea why explicitly exposing ports worked even with typo. Thanks for all the quick replies, all works now and Jellyseer is gorgeous ❤


[FEATURE] Customize MaxRecurringJobRetain

Is your feature request related to a problem? Please describe (👍 if you like this request)
Hardcoding the MaxRecurringJobRetain may be inadequate in some cases.
Describe the solution you'd like
Introduce a setting or field to allow customizing the max retaining number.
Describe alternatives you've considered
None
Additional context
https://github.com/longhorn/longhorn-manager/pull/1827

https://github.com/longhorn/longhorn-manager/pull/1827#pullrequestreview-1375899590

Update:
When the number of snapshots for a volume is up to 250, the recurring job pod will still try to create a new snapshot but it would be blocked about 30 minutes and then fail, and after retrying 3 times, the job status would show it failed.

Verified pass on longhorn master(longhorn-manager 88d986) with test steps

set setting recurring-job-max-retention to 10 and create recurring job with the retain number 15 failed

failed to create recurring job c-ru27cr: admission webhook "validator.longhorn.io" denied the request: retain value should be less than or equal to 10

set setting recurring-job-max-retention to 251 failed

failed to set the setting recurring-job-max-retention with invalid value 251: value 251 of settings recurring-job-max-retention is invalid: the value 251 should be between 1 and 250

Create recurring job with the retain number 8, the recurring job worked well.
test_recurring_job.py worked well


Please add a name of the project

Please add a name of the project to README file

Added a project name


Create Check Armstrong number.cpp

please star the repo if u think this helped u for hacktoberfest :) @JituJakhar2000


Keyboard dead after exiting Karabiner

After exiting Karabiner, to restore built-in keyboard, the built-in keyboard went dead. Starting Karabiner didn't solve the issue. This issue happens from time to time. Some times it works, some times it doesn't.
Karabiner version: 0.90.86
macOS version: 10.12.3 (16D32)
[2017-02-14 11:03:35.750] [info] [grabber] pid:541 is exited
[2017-02-14 11:03:35.769] [info] [grabber] Connected devices are ungrabbed
[2017-02-14 11:03:35.782] [info] [grabber] event_tap_manager terminated
[2017-02-14 11:04:52.504] [info] [console_user_server] version 0.90.86
[2017-02-14 11:04:53.527] [info] [console_user_server] Check version...
[2017-02-14 11:04:53.528] [info] [grabber] karabiner_console_user_server is connected (pid:23274)
[2017-02-14 11:04:53.528] [info] [console_user_server] grabber_client_ is connected
[2017-02-14 11:04:53.529] [info] [console_user_server] karabiner.json was loaded.
[2017-02-14 11:04:53.530] [info] [console_user_server] Check for updates...
[2017-02-14 11:04:53.531] [info] [grabber] event_tap_manager initialized
[2017-02-14 11:04:53.533] [info] [grabber] Apple Internal Keyboard / Trackpad is ignored.
[2017-02-14 11:04:54.542] [info] [grabber] system_preferences_values_updated
[2017-02-14 11:04:54.542] [info] [console_user_server] system_preferences::values is updated.
[2017-02-14 11:05:28.328] [info] [console_user_server] karabiner.json was loaded.
[2017-02-14 11:05:28.329] [info] [grabber] Apple Internal Keyboard / Trackpad is ignored.
[2017-02-14 11:06:21.221] [info] [console_user_server] version 0.90.86
[2017-02-14 11:06:22.482] [info] [console_user_server] Check version...
[2017-02-14 11:06:22.483] [info] [grabber] karabiner_console_user_server is connected (pid:546)
[2017-02-14 11:06:22.483] [info] [console_user_server] grabber_client_ is connected
[2017-02-14 11:06:22.488] [info] [grabber] event_tap_manager initialized
[2017-02-14 11:06:22.516] [info] [console_user_server] karabiner.json was loaded.
[2017-02-14 11:06:22.517] [info] [console_user_server] Check for updates...
[2017-02-14 11:06:22.518] [info] [grabber] initialize_virtual_hid_keyboard
[2017-02-14 11:06:22.518] [info] [grabber]   keyboard_type:40
[2017-02-14 11:06:22.518] [info] [grabber]   caps_lock_delay_milliseconds:0
[2017-02-14 11:06:22.519] [info] [grabber] Apple Internal Keyboard / Trackpad is ignored.
[2017-02-14 11:06:22.523] [info] [grabber] matching device:
[2017-02-14 11:06:22.523] [info] [grabber]   manufacturer: pqrs.org
[2017-02-14 11:06:22.523] [info] [grabber]   product: Karabiner VirtualHIDKeyboard
[2017-02-14 11:06:22.523] [info] [grabber]   vendor_id: 0x0
[2017-02-14 11:06:22.523] [info] [grabber]   product_id: 0x0
[2017-02-14 11:06:22.523] [info] [grabber]   location_id: 0x0
[2017-02-14 11:06:22.523] [info] [grabber]   serial_number: org.pqrs.driver.Karabiner.VirtualHIDDevice.VirtualHIDKeyboard
[2017-02-14 11:06:22.523] [info] [grabber]   registry_entry_id:<PHONE_NUMBER>
[2017-02-14 11:06:22.527] [info] [grabber] Apple Internal Keyboard / Trackpad is ignored.
[2017-02-14 11:06:23.500] [info] [grabber] system_preferences_values_updated
[2017-02-14 11:06:23.500] [info] [console_user_server] system_preferences::values is updated.
[2017-02-14 11:06:24.805] [info] [grabber] version 0.90.86
[2017-02-14 11:06:25.615] [info] [grabber] IOServiceOpen is succeeded @ void virtual_hid_device_client::matched_callback(io_iterator_t)
[2017-02-14 11:06:25.623] [info] [grabber] matching device:
[2017-02-14 11:06:25.623] [info] [grabber]   manufacturer: Apple Inc.
[2017-02-14 11:06:25.623] [info] [grabber]   product: Apple Internal Keyboard / Trackpad
[2017-02-14 11:06:25.623] [info] [grabber]   vendor_id: 0x5ac
[2017-02-14 11:06:25.623] [info] [grabber]   product_id: 0x262
[2017-02-14 11:06:25.623] [info] [grabber]   location_id: 0x14400000
[2017-02-14 11:06:25.623] [info] [grabber]   registry_entry_id:<PHONE_NUMBER>
[2017-02-14 11:06:26.892] [info] [grabber] current_console_user_id: 501
[2017-02-14 11:06:26.892] [info] [grabber] Check version...
[2017-02-14 11:06:36.266] [info] [grabber] pid:546 is exited
[2017-02-14 11:06:36.266] [info] [grabber] Connected devices are ungrabbed
[2017-02-14 11:06:36.266] [info] [grabber] event_tap_manager terminated
[2017-02-14 11:06:50.263] [info] [console_user_server] version 0.90.86
[2017-02-14 11:06:51.296] [info] [grabber] karabiner_console_user_server is connected (pid:792)
[2017-02-14 11:06:51.296] [info] [grabber] event_tap_manager initialized
[2017-02-14 11:06:51.296] [info] [console_user_server] Check version...
[2017-02-14 11:06:51.296] [info] [console_user_server] grabber_client_ is connected
[2017-02-14 11:06:51.296] [info] [console_user_server] karabiner.json was loaded.
[2017-02-14 11:06:51.297] [info] [grabber] Apple Internal Keyboard / Trackpad is ignored.
[2017-02-14 11:06:51.297] [info] [console_user_server] Check for updates...
[2017-02-14 11:06:52.371] [info] [grabber] system_preferences_values_updated
[2017-02-14 11:06:52.371] [info] [console_user_server] system_preferences::values is updated.

Duplicate of #417?