Normalise the extracted entities to an ontology

To be able to extract the 1:M relationships between diseases and phenotypes, it would be useful to follow an ontology based approach of grounding the identifying terms to common term definitions.
Using an ontology gives us 2 important benefits:

More definition. A disease is identified with different ways or referring to the same ontological term across the literature. Being able to have a common definition will improve the clustering algorithm in a later stage when we want to identify the associated phenotypes.
Structure. By giving the constraints of the ontology, we make sure that the terms do not live in the void. This is important in the part where we distinguish between phenotypes and diseases. When we map a label to a HP term, we know that the text most likely refers to a sign and not a disease.

As per the ontologies we should be using, I see 2 interesting possibilities and I don't know which will yield better results:

Using the Experimental Factor Ontology (EFO).
a) I'd define as phenotype every child of these terms:
- phenotype
- measurement
b) Diseases will be defined as any other term included in the OT Disease index that are not included in a)

Using MONDO and the Human Phenotype ontology

The benefits of using EFO is that I am familiar with the dataset structure OT provides, and the benefits of using MONDO/HP is that I have the impression that their coverage and ontological representation might be slightly for this task.

In terms of vector stores there are many we can use: FAISS (simple and local), LlamaIndex, ChromaDB or Pinecone (cloud-based).
Langchain has wrappers around the main vector stores that accommodate common methods for similarity search and clustering, so I'd suggest using implementing them with Langchain in case we want to change the library in the future.
Regarding the embeddings strategy, I'd use here a high quality tokenizer to make sure that the most semantic value is captured (OpenAI's models, basically).

I did a very similar exercise one year ago with a "basic" BERT model Tokenizer. The code for inspiration can be seen here: https://github.com/ireneisdoomed/random_notebooks/tree/main/text_similarity

We have implemented:

[x] The extraction of the embeddings of all the disease labels that represent one EFO ID
[x]  The construction of a vector database in Pinecone that we can query with an API token. The URL of the database: phenomena-38e5d95.svc.us-west4-gcp.pinecone.io
[X] Code to find the most likely EFO ID to a string of an user by embedding the string and querying the Pinecone db

Todo: implement in the FE like a confidence-based ranking system, that shows suggested terms and allows the user to choose from the top 5 most similar EFO IDs.


Add service label on metrics

This commits adds support to have additional information on some metrics[0],
this commit enables users to know the service affected by the metric.
Due to this can be a problematic for Prometheus[1], to enable this a new ENV
variable(APICAST_EXTENDED_METRICS) is defined, so if users that have a few services
they can run the extended metrics without affecting Prometheus stability, if
they thousands of services the recommendation is to have this option disabled.
In case of the extended_metrics is disabled, all the service labels will use
"all" value and Prometheus performance will not be affected.
The new metrics list looks like this:
bash-4.2$ curl http://localhost:9421/metrics -s | grep service
total_response_time_seconds_bucket{service="all",le="00.100"} 91
total_response_time_seconds_bucket{service="all",le="00.200"} 189
total_response_time_seconds_bucket{service="all",le="00.300"} 220
total_response_time_seconds_bucket{service="all",le="00.400"} 220
total_response_time_seconds_bucket{service="all",le="00.500"} 222
total_response_time_seconds_bucket{service="all",le="00.750"} 223
total_response_time_seconds_bucket{service="all",le="01.000"} 223
total_response_time_seconds_bucket{service="all",le="01.500"} 224
total_response_time_seconds_bucket{service="all",le="02.000"} 224
total_response_time_seconds_bucket{service="all",le="03.000"} 224
total_response_time_seconds_bucket{service="all",le="04.000"} 224
total_response_time_seconds_bucket{service="all",le="05.000"} 224
total_response_time_seconds_bucket{service="all",le="10.000"} 224
total_response_time_seconds_bucket{service="all",le="+Inf"} 224
total_response_time_seconds_count{service="all"} 224
total_response_time_seconds_sum{service="all"} 33.616
upstream_response_time_seconds_bucket{service="all",le="00.100"} 93
upstream_response_time_seconds_bucket{service="all",le="00.200"} 190
upstream_response_time_seconds_bucket{service="all",le="00.300"} 220
upstream_response_time_seconds_bucket{service="all",le="00.400"} 220
upstream_response_time_seconds_bucket{service="all",le="00.500"} 223
upstream_response_time_seconds_bucket{service="all",le="00.750"} 224
upstream_response_time_seconds_bucket{service="all",le="01.000"} 224
upstream_response_time_seconds_bucket{service="all",le="01.500"} 224
upstream_response_time_seconds_bucket{service="all",le="02.000"} 224
upstream_response_time_seconds_bucket{service="all",le="03.000"} 224
upstream_response_time_seconds_bucket{service="all",le="04.000"} 224
upstream_response_time_seconds_bucket{service="all",le="05.000"} 224
upstream_response_time_seconds_bucket{service="all",le="10.000"} 224
upstream_response_time_seconds_bucket{service="all",le="+Inf"} 224
upstream_response_time_seconds_count{service="all"} 224
upstream_response_time_seconds_sum{service="all"} 32.226
upstream_status{status="200",service="all"} 224

[0] List of affected metrics:
total_response_time_seconds
upstream_response_time_seconds
upstream_status
[1] https://prometheus.io/docs/practices/naming/#labels

@eloycoto the new metrics should be added to https://github.com/3scale/APIcast/blob/master/doc/prometheus-metrics.md

I think that I found the issue with the test[0].
On the executor, where the phase log happens, the ngx.ctx.context is nil, so
it creates a new context and the old one is not updated.
https://github.com/3scale/APIcast/blob/66168b7a15655f0ea473d862a41ae9fdbb3fa912/gateway/src/apicast/executor.lua#L40-L51
The main problem on log phase, if the batch policy or cache policy is in place
the context.service is not defined, so the Prometheus metrics raise an error
that the service.id cannot be found.
I debug all the code, and the issue is fixed if we add in this the following
code require('resty.ctx').apply(), if we add this the code is working
correctly.
https://github.com/3scale/APIcast/blob/66168b7a15655f0ea473d862a41ae9fdbb3fa912/gateway/conf.d/apicast.conf#L68-L71
I think that it's safe enough, but I want to make sure that I do not introduce
a new issue. Also IMHO we should trigger a error message on
executor:shared_build_context that if the context does not exists maybe we
need to notice. (But I do not have the full overview of the project)
[0] https://github.com/3scale/APIcast/blob/master/t/apicast-policy-3scale-batcher.t#L403-L483

Added the patch on log phase in apicast.conf, now a different test is failing:
https://github.com/3scale/APIcast/blob/66168b7a15655f0ea473d862a41ae9fdbb3fa912/t/apicast.t#L621-L631
Should a request to invalid service reach log phase? Should be denied in the auth phase? @davidor any insight here?

@eloycoto The log phase will run even when the find_service policy cannot find a service for the request. In that case context.service is going to be nil. That explains why the test TEST 17: invalid service that you pasted above fails.
We'll need to take that case into account when updating the Prometheus metrics.

@davidor what about this commit? Is that correct?
https://github.com/3scale/APIcast/pull/1024/commits/190962e6449afa53418e9718cc0a4bd58ea5e05b

@davidor what about this commit? Is that correct?
190962e

@eloycoto and I have been investigating this. Adding require('resty.ctx').apply() to the log by lua block in gateway/conf.d/apicast.conf is not the solution. When starting APIcast with bin/apicast we saw that the context is shared correctly in all the phases, including the log one. There's only one test that fails and the reason is that it is the only one that defines its own rewrite_by_lua: https://github.com/3scale/APIcast/blob/66168b7a15655f0ea473d862a41ae9fdbb3fa912/t/apicast-policy-3scale-batcher.t#L453
Calling require('resty.ctx').apply() in that rewrite block fixes the issue.

Hi,
PR Updated, all the changes in the same commits, the PR is quite small, issues
fixed:

For the context issues, now in the M:log is checking that the
context.service exists if not a empty service will be used. So the test that
had failed last Tuesday are now ok.
For the service, no longer the key "all", a empty string will be send.
For t/prometheus-metrics.t a new helper was added, is like
response_body_like but with multiple options. I did not add this helper in a
proper library because I think that it's only needed here, but if you think
that it's good to move it, I'm happy to move it.

Please, review it again.
Eloy

@eloycoto Sorry, I thought about this after approving the PR. Maybe we should use the service name or  instead of the ID as the label of the metric.
I'm thinking about how this can be used to show data in something like Grafana. The ID will not give much information to the people operating APIcast. It's likely that they'll need to go to the admin portal to check which service that ID corresponds to. Maybe we can save them that step.

For the record, we discussed offline with @davidor:
If we use the ID, the number will never change.
There is a name that the users can update, but that means that the historical information will be lost.
There is a system_name variable that will work, but if you update the Name in the UI the system_name will not be updated, so it's like an old id.
We are going to keep the ID that it's the most reasonable one.

I think we discussed this earlier and kind of agreed using system name. The system name is immutable and should be used instead of an ID because it gives more context. It is immediately obvious in alerts and dashboards what service it is. Ids have zero context and it would be impossible for humans to decipher them without some lookup through 3scale API.

Changes to use system_name added in a new commit. Please review :-)

Hi,
Made some perfomance testing around the multiple services in the labels, it's
not a big change, I didn't notice any memory issue, is around 200req/sec slower
and adds a 2ms latency:
Config: https://gist.githubusercontent.com/eloycoto/37b23b7c74a21645e6a4c37f41197c53/raw/447eaf62434e50cd1e0253b622443f0d6de99d64/3scale-100-nodes.json
wrk setup:
function request()
   wrk.headers["Host"] = tostring(math.random(0,99))
   return wrk.format(nil, "/?user_key=foo")
end

Result with extended metrics:
root@ubuntu-s-4vcpu-8gb-ams3-01:~/APIcast# wrk  --connections 100 --threads 10 --duration 300 'http://<IP_ADDRESS>:8080/?user_key=foo' -s wrk-code.lua
Running 5m test @ http://<IP_ADDRESS>:8080/?user_key=foo
  10 threads and 100 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency    27.49ms    7.93ms 141.59ms   72.14%
    Req/Sec   365.66     40.38     0.95k    75.36%
  1092416 requests in 5.00m, 234.36MB read
Requests/sec:   3640.26
Transfer/sec:    799.69KB

Upstream status metrics:
bash-4.2# curl http://localhost:9421/metrics -s | grep ^upstream_status
upstream_status{status="200",service="0"} 10772
upstream_status{status="200",service="1"} 10933
upstream_status{status="200",service="10"} 10410
upstream_status{status="200",service="11"} 11157
upstream_status{status="200",service="12"} 10465
upstream_status{status="200",service="13"} 11176
upstream_status{status="200",service="14"} 10485
upstream_status{status="200",service="15"} 10869
upstream_status{status="200",service="16"} 11551
upstream_status{status="200",service="17"} 11190
upstream_status{status="200",service="18"} 11373
upstream_status{status="200",service="19"} 10638
upstream_status{status="200",service="2"} 10568
upstream_status{status="200",service="20"} 10732
upstream_status{status="200",service="21"} 11071
upstream_status{status="200",service="22"} 11077
upstream_status{status="200",service="23"} 10724
upstream_status{status="200",service="24"} 10985
upstream_status{status="200",service="25"} 10688
upstream_status{status="200",service="26"} 10419
upstream_status{status="200",service="27"} 10913
upstream_status{status="200",service="28"} 11312
upstream_status{status="200",service="29"} 11288
upstream_status{status="200",service="3"} 11297
upstream_status{status="200",service="30"} 10395
upstream_status{status="200",service="31"} 10977
upstream_status{status="200",service="32"} 10810
upstream_status{status="200",service="33"} 11141
upstream_status{status="200",service="34"} 10920
upstream_status{status="200",service="35"} 11128
upstream_status{status="200",service="36"} 10456
upstream_status{status="200",service="37"} 10756
upstream_status{status="200",service="38"} 11159
upstream_status{status="200",service="39"} 10872
upstream_status{status="200",service="4"} 10773
upstream_status{status="200",service="40"} 10346
upstream_status{status="200",service="41"} 10553
upstream_status{status="200",service="42"} 11502
upstream_status{status="200",service="43"} 10724
upstream_status{status="200",service="44"} 10953
upstream_status{status="200",service="45"} 11275
upstream_status{status="200",service="46"} 10420
upstream_status{status="200",service="47"} 11296
upstream_status{status="200",service="48"} 11134
upstream_status{status="200",service="49"} 10559
upstream_status{status="200",service="5"} 10817
upstream_status{status="200",service="50"} 10998
upstream_status{status="200",service="51"} 10654
upstream_status{status="200",service="52"} 10794
upstream_status{status="200",service="53"} 10395
upstream_status{status="200",service="54"} 11651
upstream_status{status="200",service="55"} 10933
upstream_status{status="200",service="56"} 11145
upstream_status{status="200",service="57"} 10777
upstream_status{status="200",service="58"} 10043
upstream_status{status="200",service="59"} 11505
upstream_status{status="200",service="6"} 10780
upstream_status{status="200",service="60"} 10272
upstream_status{status="200",service="61"} 10658
upstream_status{status="200",service="62"} 10847
upstream_status{status="200",service="63"} 11367
upstream_status{status="200",service="64"} 11336
upstream_status{status="200",service="65"} 10528
upstream_status{status="200",service="66"} 10825
upstream_status{status="200",service="67"} 11279
upstream_status{status="200",service="68"} 11098
upstream_status{status="200",service="69"} 10708
upstream_status{status="200",service="7"} 11377
upstream_status{status="200",service="70"} 11280
upstream_status{status="200",service="71"} 11224
upstream_status{status="200",service="72"} 10878
upstream_status{status="200",service="73"} 10995
upstream_status{status="200",service="74"} 11010
upstream_status{status="200",service="75"} 10953
upstream_status{status="200",service="76"} 11471
upstream_status{status="200",service="77"} 10683
upstream_status{status="200",service="78"} 10551
upstream_status{status="200",service="79"} 10088
upstream_status{status="200",service="8"} 11209
upstream_status{status="200",service="80"} 11152
upstream_status{status="200",service="81"} 11418
upstream_status{status="200",service="82"} 10981
upstream_status{status="200",service="83"} 10945
upstream_status{status="200",service="84"} 10713
upstream_status{status="200",service="85"} 10293
upstream_status{status="200",service="86"} 11375
upstream_status{status="200",service="87"} 10748
upstream_status{status="200",service="88"} 10630
upstream_status{status="200",service="89"} 11301
upstream_status{status="200",service="9"} 11493
upstream_status{status="200",service="90"} 11578
upstream_status{status="200",service="91"} 10510
upstream_status{status="200",service="92"} 11049
upstream_status{status="200",service="93"} 11309
upstream_status{status="200",service="94"} 10555
upstream_status{status="200",service="95"} 10859
upstream_status{status="200",service="96"} 11179
upstream_status{status="200",service="97"} 10857
upstream_status{status="200",service="98"} 11392
upstream_status{status="200",service="99"} 10790
bash-4.2#

Without extended metrics:
wrk output:
root@ubuntu-s-4vcpu-8gb-ams3-01:~/APIcast# wrk  --connections 100 --threads 10 --duration 300 'http://<IP_ADDRESS>:8080/?user_key=foo' -s wrk-code.lua
Running 5m test @ http://<IP_ADDRESS>:8080/?user_key=foo
  10 threads and 100 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency    25.81ms    7.61ms 118.59ms   72.33%
    Req/Sec   389.60     46.55     1.07k    79.60%
  1163878 requests in 5.00m, 249.69MB read
Requests/sec:   3878.50
Transfer/sec:    852.02KB
root@ubuntu-s-4vcpu-8gb-ams3-01:~/APIcast#

Metrics:
bash-4.2# curl http://localhost:9421/metrics -s | grep ^upstream_status
upstream_status{status="200",service=""} 1163966
bash-4.2#

@eloycoto I realised one shortcoming when using just system_name. It is no longer unique in multi-tenant environments. Would it be a big issue to have both system name and id? The granularity should be the same, so it shouldn't affect prometheus.

@mikz your comment makes total sense! I do not liked the system_name; a user can't change that and can be out of date quite quickly.
I would format as ${id}-${name}, with that users can use a custom legend based on ID or names, for legend format, they can use the following promQL query, and we allow users to have the correct names on that:
https://prometheus.io/docs/prometheus/latest/querying/functions/#label_replace
What do you think about this? Are you ok with that?
Regards

@eloycoto I actually thought about using two labels. One for id and one for system_name. So people do not have to bother using the label replace and just see the system_name as a hint for what the service is, but still be unique because of the ID. It is just additional metadata.
And for the ones that want, they can use the label_replace based on the id.

@mikz the problem if you add two labels, is that Prometheus matrix will be bigger, and the Prometheus performance will be affected, I'm happy with two labels if have different data, but having two labels for the same data, I'm a bit against

@eloycoto how it will be bigger? the number of combinations is the same if you make an identifier that contains both or if you have two identifiers and one is unique. Prometheus will not store anything in empty timelines.

@mikz latest changes now contains the service_id and the service_system_name labels per metric :-)
Regards.

@eloycoto amazing! 👍

@eloycoto Good job! :+1:


About IMX490 Sensor

Hello, I am working on Auto Exposure algorithm, I want to use ISET as a simulation environment.
I notice ISETCam has introduced imx490 sensor , but the sensorComputeArray' not support imx490 now.
And in imx490Compute , there is imx490 model, but I find it is different in sensorCreateSplitPixel, so is it right to use imx490Compute  simulate 4 sub-frames of imx490?
I think there is a lack of saturation control in imx490Compute

Sorry to be slow to respond.  I am traveling on holiday.  I will try to understand your question and respond by early next week.
From: MEYE66 @.>
Date: Tuesday, December 17, 2024 at 1:02 AM
To: ISET/isethdrsensor @.>
Cc: Subscribed @.***>
Subject: [ISET/isethdrsensor] About IMX490 Sensor (Issue #3)
Hello, I am working on Auto Exposure algorithm, I want to use ISET as a simulation environment.
I notice ISETCam has introduced imx490 sensor , but the sensorComputeArrayhttps://github.com/ISET/isetcam/blob/9da413dab0a072a186ceb6d86db4b1c14a23ede8/sensor/sensorComputeArray.m' not support imx490 now.
And in imx490Computehttps://github.com/ISET/isetcam/blob/9da413dab0a072a186ceb6d86db4b1c14a23ede8/sensor/models/imx490Compute.m , there is imx490 model, but I find it is different in sensorCreateSplitPixelhttps://github.com/ISET/isetcam/blob/9da413dab0a072a186ceb6d86db4b1c14a23ede8/sensor/models/sensorCreateSplitPixel.m#L4, so it is right to use imx490Computehttps://github.com/ISET/isetcam/blob/9da413dab0a072a186ceb6d86db4b1c14a23ede8/sensor/models/imx490Compute.m simulate 4 sub-frames.
—
Reply to this email directly, view it on GitHubhttps://github.com/ISET/isethdrsensor/issues/3, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AAOAQWLDAM7I6TIDQB7DXT32F7SCHAVCNFSM6AAAAABTX5LW5KVHI2DSMVQWIX3LMV43ASLTON2WKOZSG42DIMZSGQ3DKNI.
You are receiving this because you are subscribed to this thread.Message ID: @.***>


support for import()

Typescript (latest) erroring out  while using import(). Any idea when this is going to be supported ?

Duplicate of https://github.com/Microsoft/TypeScript/issues/12364


⚠ Bofrost.de has degraded performance

In 4291be4, Bofrost.de (https://www.bofrost.de) experienced degraded performance:

HTTP code: 200
Response time: 1539 ms

Resolved: Bofrost.de performance has improved in e32b623.


PDP Riffmaster driver is stuck on WinUSB and now doesn't work on Clone Hero or Fortnite Festival

I've switched my drivers to play both Fortnite Festival and Clone Hero many times before, but this issue started suddenly yesterday
In RB4 Instrument Mapper my riffmaster shows under WinUSB Xbox Controllers, and when I press Revert Driver it loads for a little bit then does nothing.
In my device manager I see PDP RiffMaster Guitar for Xbox under Universal Serial Bus devices. When I right click here and uninstall device, it just shows back up the exact same after restarting my PC.
I'm using the PDP Riffmaster for Xbox. I've updated to the latest version of RB4 Instrument Mapper and the issue is still happening. I've tried the controller on a friend's computer and it works perfectly.

Yeah this happens on occasion, and I'm not sure why unfortunately. You can uninstall the driver manually, there are instructions here.
I've been working on a new backend that should make this process unnecessary for Riffmasters, hopefully that'll work more reliably. Will be releasing a new version soon that includes it.

Same issue here. Difference is that whenever I try to uninstall the driver it reappears after I restart. I am on Windows 11 while it looks like the screenshots were on Windows 10, could that be the issue? Either way, is there any other way to reset my driver back to the default?

Make sure you're ticking the Delete the driver software for this device checkbox if it exists:

It can also just take multiple attempts sometimes. There's otherwise no real reason the driver should get stuck like that, and the method linked in my prior message is the only method to reset the drivers AFAIK.

I suppose you could try hitting Update Driver and letting it automatically find the right driver, but I'm unclear as to whether the driver is reverting successfully in the first place and simply un-reverting when you restart your PC. The answer to that would change the troubleshooting process a bit.

Took a few attempts but it seems to work now (thank the heavens!). The driver is still listed in my device manager though?!? Just gonna play with my fingers crossed


Can't roll back

Rancher Server Setup

Rancher version: 2.6.5
Installation option (Docker install/Helm Chart): Helm Chart

If Helm Chart, Kubernetes Cluster and version (RKE1, RKE2, k3s, EKS, etc): ACK

Proxy/Cert Details:

Information about the Cluster

Kubernetes version: v1.18.8
Cluster Type (Local/Downstream): Downstream

If downstream, what type of cluster? (Custom/Imported or specify provider for Hosted/Infrastructure Provider): aliyun

User Information

What is the role of the user logged in? (Admin/Cluster Owner/Cluster Member/Project Owner/Project Member/Custom)

If custom, define the set of permissions:
Admin and/or Standard User

Describe the bug

When deploying Deployment through the yaml file, the new version of rancher must specify workload.user.cattle.io/workloadselector to roll back on the UI interface, otherwise it will report an error that the tag cannot be found.
Deployment.apps "nginx-deployment" is invalid: spec.template.metadata.labels: Invalid value: map[string]string{}: `selector` does not match template `labels`

To Reproduce

Unavailable yaml file
apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: nginx
  name: nginx-deployment
spec:
  replicas: 2
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
        - image: 'nginx:1.14.0'
          name: nginx
          ports:
            - containerPort: 80

or Available yaml files
apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: nginx
    workload.user.cattle.io/workloadselector: nginx
  name: nginx-deployment
spec:
  replicas: 2
  selector:
    matchLabels:
      workload.user.cattle.io/workloadselector: nginx
  template:
    metadata:
      labels:
        app: nginx
        workload.user.cattle.io/workloadselector: nginx
    spec:
      containers:
        - image: 'nginx:1.13.0'
          name: nginx
          ports:
            - containerPort: 80

Result
Expected Result

Unavailable yaml files can rollback versions
Screenshots

Additional context

Note for QA - https://github.com/rancher/dashboard/issues/7804 should be tested at the same time

Validated this issue on v2.7-7913e283ff90eebd1f8cc48860a6b410d72cd4dd-head . This issue got fixed and closing the issue.
Validation Details:

Validated below tests with Admin and Standard user
Validated below tests on RKE2 cluster (Downstream cluster)
Validated below tests on Auto and Dark modes

Reproducible Steps:

Provision Rancher
Login with user
Downstream cluster
Create a work load (deployment / Service) (Ex: Deployment->Workload->Image (nginx:1.14.0))
Edit the workload and change the image value to nginx:1.13.0
Save
Roll back this nginx:1.13.0 TO nginx:1.14.0
Save and check the NEW version is deployed successfully
Rollback this version to nginx:1.13.0
Save and check the OLD version is deployed successfully


android 12 support

Android 12 does not ship with locale service, adding support to Android 12 (or older versions) would require Xposed implementations, which are not planned by now.


Version number on jacdac website

I'd like to know if my browser has the latest version of the website. This is useful for validating that fixes have been deployed and are working as expected. Could we please have a version number and a way of checking what the latest version number is?

[x] force reload when update is downloaded
[x] currently service worker checks for updates daily, force check on every nav
[x] display link to commit sha in footer

See short sha in footer


Download links have expired

Are different links available?

Hello, in the near future I will try to post new links. Thanks for the objection!

Hey @helgster77
I updated the links
Respectfully


Updating button styles

Coverage remained the same at 94.6% when pulling 68396f168e5a8cd69b916e69e223a1b994454b49 on reshma-button-css into bc582457b3945c14b1ff73d2368b32ee2c0699f0 on main.


Error when saving output of get_node_names()

Using this simple ensmallen 0.5.2 -based script:
https://github.com/kbaseIncubator/KE_KG/blob/main/src/embeddings/graphs_stats_degrees_nodes.py
to generate node degrees and node labels. Running this script on a graph that I am sharing with you in slack, gives this graph summary and an error when saving the results of the get_node_labels() call with np.savetxt(), see below:
The undirected graph Graph has 169784 nodes and 2596040 unweighted edges, of which 13026 are self-loops. The graph is quite sparse as it has a density of 0.00018 and has 2 connected components, where the component with most nodes has 169782 nodes and the component with the least nodes has 2 nodes. The graph median node degree is 9, the mean node degree is 30.50 and the node degree mode is 7. The top 5 most central nodes are Virus_topology:linear_contig (degree 96796), NCBItaxon:duplodnaviria;heunggongvirae;uroviricota;caudoviricetes;caudovirales;;; (degree 81390), Contig_length:5 (degree 74875), Contig_length:4 (degree 63612) and Virus_topology:direct_terminal_repeats_(dtrs) (degree 30497).
Traceback (most recent call last):
File "/global/u1/m/marcinj/graphs/embiggen/venv/lib/python3.7/site-packages/numpy/lib/npyio.py", line 1424, in savetxt
v = format % tuple(row) + newline
TypeError: must be real number, not numpy.str_
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "src/embeddings/graphs_stats_degrees_nodes.py", line 25, in
np.savetxt("merged_imgvr_mg_nodes.tsv", nodes, delimiter="\t")
File "<array_function internals>", line 6, in savetxt
File "/global/u1/m/marcinj/graphs/embiggen/venv/lib/python3.7/site-packages/numpy/lib/npyio.py", line 1428, in savetxt
% (str(X.dtype), format))
TypeError: Mismatch between array dtype ('<U173') and format specifier ('%.18e')

This was a numpy error and solved by adding a fmt parameter to savetxt.
E.g.:
np.savetxt("node_ids.tsv", node_ids, delimiter="\t", fmt="%s")


[5 pts] Write tests (Diego Vidal)

Required Implementation:

[ ] Write

[ ] Models

[x] food.rb
[x] recipe_food.rb
[ ] recipe.rb
[ ] user.rb

[ ] Controllers

[ ] foods_controller.rb
[ ] general_shopping_list_controller.rb

[ ] Integration test for:

[ ] Authentication (login)
[ ] registration(sign in)
[ ] shopping list page
[ ] Food list page

draft: https://github.com/Diegogagan2587/Recipe-app-bests-dishes/pull/25

draft: https://github.com/Diegogagan2587/Recipe-app-bests-dishes/pull/25


Allow remaining configuration to load when a key-vault reference fails to resolve

[Creating this issue on behalf of @b10-dslappendel as reported in issue #136]
I see that the latest version 4.0 ignores exceptions thrown from keyvault. However, I think I may have misunderstood the use case here. From what I can see, right now the whole configuration is seen as optional, meaning that if at least one keyvault exception is thrown, no configuration values are loaded.
I had hoped that this would cover our use case, which is ignoring only configuration values from keyvault that are inaccessible (e.g. due to no access permissions), instead of ignoring all configuration values if one can't be loaded from keyvault.
Basically, we have hooked up multiple keyvaults in one app configuration, but not all apps have access to all keyvaults that are referenced there. So right now we can't load any configuration if we don't allow access to all keyvaults from all our apps.
In preview version 2, I could still create a custom keyvault delegating handler that ignores 401, 403 and 404 errors and return an empty string, but I also can't seem to find this option anymore in version 4.
Is there any way to support this use case?

@b10-dslappendel Thanks for your feedback. I'm looking into ways to support the use case you shared. The recommended approach is to allow each application to only Select configuration settings that are needed for that application. The configuration provider will only attempt to load settings defined by the criteria defined by the Select clause(s).
In your scenario, is there a reason the application is selecting key-vault references that correspond to key-vaults that it isn't expected to have access to?

@abhilasharora Thanks for moving it in a new issue.
In our scenario, we have a bunch of apps that make use of the same app configuration instance. We have multiple key vaults, but for some higher privileged key vaults, most apps and users shouldn't have access to those unless it's really necessary to pass audits. However, since they are still referenced in app configuration, and they are still selected (because we currently use KeyFilter.All), they fail to be retrieved.
I'm currently discussing with my team to see if we can improve this on our end. Currently we notice that our startup times are getting longer and longer the more settings we add to app configuration and/or key vault.
Using KeyFilter.All isn't the best way to load configurations if 80% of those settings isn't used in one particular app. Currently we aren't using namespaces because we might have been too enthusiastic during preview last year. Namespaces do allow us to select them in a more granular way, but the transition to this is going to be very painful because some settings are used across apps without anything that binds them together in a category.
In the end, we should move to using namespaces, but on short term is not possible.

Hi @b10-dslappendel, please see the proposed solution in #209 and let us know if that works for you.


Fix bug

Hashcode of null set to 0

Codecov Report

Merging #113 (36e1d12) into master (d35cba6) will not change coverage.
The diff coverage is 0.00%.

@@            Coverage Diff            @@
##             master     #113   +/-   ##
=========================================
  Coverage     54.37%   54.37%
  Complexity      515      515
=========================================
  Files           115      115
  Lines          2185     2185
  Branches        245      245
=========================================
  Hits           1188     1188
  Misses          921      921
  Partials         76       76

Impacted Files
Coverage Δ

...ain/java/seedu/address/model/commons/RepoName.java
57.14% <0.00%> (ø)

.../main/java/seedu/address/model/group/LinkYear.java
0.00% <0.00%> (ø)

...ain/java/seedu/address/model/student/UserName.java
57.14% <0.00%> (ø)

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 d35cba6...36e1d12. Read the comment docs.


Player stops animating after pull to refresh

After pull to refresh, the tableview reloads and any cell that is playing/animating stops animating but keeps on playing.

Wait for redesign of feed/sticky cell, could make solving this problem easier


BUG: strip_attr ignores CSS selectors, strip_tags ignores HTML tags

Version (please complete the following information):

OS: MacOS 15.1
Browser: Safari
Web Clipper version: 0.9.5
Obsidian version: 1.7.6

Describe the bug

strip_attr:("class") removes all attributes.
strip_tags:("b") removes all attributes

Expected behavior

strip_attr:("class") should remove either only class or all other attributes (eg id).
strip_tags:("b")  should remove either  …  or all the other tags.

I'm not sure about the intended behavior. Help is confusing. Does it strip only or everything but the provided CSS selectors/HTML tags? I'd prefer the former and a different syntax for the latter, but the other way around is also ok.
URLs where the bug occurs
I added the examples from Help to a test page: https://write.as/i52g2kl1kwnghey2.md
To reproduce
Steps to reproduce the behavior:

Write template with note content:

{{selectorHtml:article}}

---

{{selectorHtml:article|strip_attr:("class")}}

---

{{selectorHtml:article|strip_tags:("b")}}

Go to: https://write.as/i52g2kl1kwnghey2.md

Open Clipper

See error

I expected to see either this result:

Testing Webclipper

Content

Hello world!

---

Testing Webclipper

Content

Hello world!

---

Testing Webclipper

Content

Hello world!

Or that result:

Testing Webclipper

Content

Hello world!

---

Testing Webclipper

Content

Hello world!

---

Content

Hello world

Your template file
{
  "schemaVersion": "0.1.0",
  "name": "Testing Testing",
  "behavior": "create",
  "noteContentFormat": "{{selectorHtml:article}}\n\n---\n\n{{selectorHtml:article|strip_attr:(\"class\")}}\n\n---\n\n{{selectorHtml:article|strip_tags:(\"b\")}}",
  "properties": [],
  "triggers": [],
  "noteNameFormat": "{{title}}",
  "path": "Clippings"
}

Apparently both filters work without brackets. Test:
{{selectorHtml:article}}

---

{{selectorHtml:article|strip_attr:"class"}}

---

{{selectorHtml:article|strip_tags:"b"}}

works almost like expected:

remove all attributes except class
remove all tags except b

Open bugs:

support notation with brackets for consistency with other filters and for compatibility with help pages
fix error in help pages for strip_attr. Help seems to describe the opposite of the actual behavior

Fixed in 0.10.3


Which model should i choose?

i just want to classify the bank invoices ... do anyone could tell me which model (e.g. vggnet, alexnet etc.) i should choose?

Both are okay.  You can start with alexnet.

https://github.com/caffe2/caffe2/blob/master/caffe2/python/models/resnet.py
https://github.com/caffe2/caffe2/blob/master/caffe2/python/examples/resnet50_trainer.py

@futurely do you mean resnet could deal with it?

ResNet has been successfully applied to almost all kinds of compute vision tasks.
https://scholar.google.com.hk/scholar?safe=strict&bav=on.2,or.&biw=1242&bih=602&dpr=1.1&um=1&ie=UTF-8&lr&cites=9281510746729853742


swift 5.2

Hi @kanxue2002, I'm afraid this can't be merged as is.
I am not sure I understand what we'd need to reference Stevia from a fork ?
Could you please elaborate ?


DEVX-8994: Change default client tokens to JWT

[!WARNING]
Do not merge/deploy until @dragonmantank has confirmed this can go out.


Resources should be closed

This pull request is focused on resolving occurrences of Sonar rule squid:S2095 - “Resources should be closed”. You can find more information about the issue here:
https://dev.eclipse.org/sonar/rules/show/squid:S2095
Please let me know if you have any questions.
Ayman Abdelghany.

Hi @AymanDF,
Would you be so kind and sign the ICLA as described here, please?

Closing. Cannot accept contributions without a signed ICLA. Please, check the CONTRIBUTING guide for more explanations and re-open this pull request, if you decide to sign it.


[GetAllAssetAdministrationShellIdsByAssetLink] Do not allow to search for externalSubjectId

What?
In Part 1 externalSubjectId ist described as: "The unique ID of the (external) subject the specific asset ID value belongs to or has meaning to".
In Catena-X the externalSubjectId is used to describe access rules. If a specific Business Partner Number (BPN) is assigned to the asset ID then only this Partner (and the owner of the twin) is allowed to see it.
This means: nobody is allowed to search for the asset IDs with a specific BPN except for the owner/administrator of the Digital Twin Registry/Digital Twin. And the data consumer looking for the asset IDs assigned to him as relevant via his BPN: why should he assign its own BPN to the Asset ID he is looking for?
Probably is should be clearer what is returned if I search for:
Twin ID= 0815:
customerPartId  123  externalSubjectId =ABC
customerPartId  345 (no  externalSubjectId)
customerPartId  567  externalSubjectId =ZYH

Data Consumer with (authenicated) SubjectI D=ABC (==> denotes the expected result)

      GetAllAssetAdministrationShellIdsByAssetLink (assetId = [customerPartId, 123] ==> ?? Twin 0815
      GetAllAssetAdministrationShellIdsByAssetLink (assetId = [customerPartId, 123, ABC] ==> Twin 0815
      GetAllAssetAdministrationShellIdsByAssetLink (assetId = [customerPartId, 123, ZYH] ==> ?? noTwin

      GetAllAssetAdministrationShellIdsByAssetLink (assetId = [customerPartId, 345]  ==> ?? Twin 0815
      GetAllAssetAdministrationShellIdsByAssetLink (assetId = [customerPartId, 345, ABC] ==> ?? Twin 0815
      GetAllAssetAdministrationShellIdsByAssetLink (assetId = [customerPartId, 345, ZYH] ==> ?? Twin 0815

      GetAllAssetAdministrationShellIdsByAssetLink (assetId = [customerPartId, 567] ==> ?? no Twin
      GetAllAssetAdministrationShellIdsByAssetLink (assetId = [customerPartId, 567, ABC] ==> no Twin
      GetAllAssetAdministrationShellIdsByAssetLink (assetId = [customerPartId, 567, ZYH] ==> ??

How?

set externalSubjectId to obsolete in Part 1 and move complete topic to access control

specifiy semantics of Get...ByAssetLink

for Get state that externalSubjectId is not part of the payload or will be ignored, i.e. add note "Whether or not a data consumer is seeing or can search for a digital twin via a specific Asset ID is decided via access rules not specified within the payload itself."

[ ] I have signed the required Developer Certificate of Origin (DCO) already.

see also https://github.com/admin-shell-io/aas-specs-api/issues/193

Decision 2023-11-14: With #19 a new class AssetLink will be introduced that does not contain the attribute externalSubjectId any longer.

closed because this is solved with #19


Add Jest.

This adds Jest as a default test runner with an example snapshot test as announced in the Jest 14 blog post. The generated snapshot for the example looks like this:
exports[`App renders a welcome view 1`] = `

      Welcome to React

    To get started, edit

      src/App.js

     and save to reload.

`;

This integration is the simplest test runner integration I can think of and requires no configuration except for a one-line preset in package.json. We could manage the preset in a separate npm repo if that is desired. It mirrors some configuration from the tutorial for webpack integration.
I'm kind of unhappy about adding a custom preprocessor with transform.js. If there was a .babelrc file available in this repo, babel-jest would be able to take care of this automatically without requiring a separate file. I understand that the "non-ejected" state should not include such configs in the app folder itself, however. Since we are planning on improving babel integration with Jest even further and since we are currently rewriting code coverage support, I'm happy to change babel-jest so that it can be wrapped better, like require('babel-jest').createPreprocessor(require('./babel.dev')), therefore reducing the transform.js file into a one-liner without any code duplication here.
I understand there are many opinions in this space and many people have aspirational goals as to what a test runner and framework should be. In reality, what we have found at Facebook is that when it is hard to set up a test runner or hard to write tests, people simply don't do it. This is why Jest's philosophy is to provide an integrated experience that is well set-up and performant by default.
Further, I believe that snapshot testing and the React test renderer will greatly influence how people write React tests and I'm excited for the possibility of other test runners integrating better with this in the future. DOM testing should be left to webdriver or other end-to-end tests. In a test environment, regardless of the real rendering target, there is little value in rendering to a fake DOM. This is especially true for non-web rendering targets.

End-to-end testing script in tasks/e2e.sh should include npm test in all places after npm run build.

One big difference between this and the sample PR adding Mocha ( https://github.com/facebookincubator/create-react-app/pull/216 ) is that this just uses babel without webpack to do the transform and the Mocha example is using webpack. So @cpojer I am curious on what you think are the pros and cons of using webpack+babel versus just using babel?
In the discussion here - https://github.com/facebookincubator/create-react-app/issues/218#issuecomment-235666867 - folks were in favor of using webpack, and I implemented run that way in https://github.com/facebookincubator/create-react-app/pull/245 , but I am not totally happy with it because Webpack is not really designed for it. It does not have the caching that e.g. babel-node does, and it doesn't handle node_modules sanely by default, so it feels fragile.
It seems like there are a few ways that we will need a "React runtime" that operates on top of node - for testing, for run scripts, and perhaps for running custom middleware. I would rather be constructing it in just one way, which means that if we are going to use babel without webpack for testing, I'd want to redo the script stuff to not use webpack too.

Yeah, I definitely agree that jest-runtime is the way to got for running scripts. This way you don't have to bundle anything and everything (transforms etc.) just happen during runtime.
I'll polish this PR a bit.

Ok I think this is now a sane solution:

npm test will run the template's test using scripts/test.js.
in a created app, npm test will use scripts/test.js and generate a config on the fly.
when ejecting, the config is made permanent and written into package.json; npm test then simply maps to jest. This allows people to easily update or remove the config that they won't have access to otherwise.

One thing we might want to do is run Jest when files change, but that can be done in a follow-up.

OK this starts to look very promising.
I really like that:

We ship snapshot testing by default
We don't need to bundle anything
The configuration isn't super intimidating

If somebody doesn't like Jest, they can eject and replace it with Mocha without rewriting test (unless they rely on snapshot testing a lot, but by this time somebody should just port it to Mocha 😉 ).

Yeah, overall I want to make clear I don't care so much about Jest as I care about snapshot testing and I'm looking forward to when other test runners have the same features integrated. As mentioned in the blog post, we put most of the snapshot functionality into a separate package and we are happy to collaborate with anyone who wants to integrate it and make it more generic so we can standardize on a single snapshot solution in JS eventually.

Ok, I updated the code here and published Jest 14.1 with a cache directory fix. This PR should now fully work but I had to update react to 15.3.0 to make it work with the new react-test-renderer API (otherwise with npm2 npm install would fail).
Please let me know if you'd like me to make any more changes or add documentation.
Follow-up: I talked to @keyanzhang about running Jest every time a file changes while the server through npm start is active. I was thinking of running jest --json and show "All tests passed" or "" if tests fail. This should be a minimal integration that is non-disruptive. We just have to figure out how to deal with jest -u in that mode. We should discuss this in a separate issue after this one has been merged.

Ok, I changed test.js to add react-scripts/node_modules to NODE_PATHS so that on npm2, react-test-utils can be found from within a test. Now everything is actually green, yay! :)

I was thinking of running jest --json and show "All tests passed" or "" if tests fail. This should be a minimal integration that is non-disruptive. We just have to figure out how to deal with jest -u in that mode. We should discuss this in a separate issue after this one has been merged.

I think this is a perfect use case for #65.

Ok, I changed test.js to add react-scripts/node_modules to NODE_PATHS so that on npm2, react-test-utils can be found from within a test.

I think I’d like to do it a bit differently.
Our rule of thumb is: whatever user imports should be in their dependencies.
Since the user imports react-test-renderer directly, I think it’s fair that we put it into generated project’s devDependencies.

Oh, sweet, that simplifies everything a lot. Nice! Pushed an update.

Does the linter configuration currently have jest env? I think we should put it there, or otherwise the users with IDE linter integration will see warnings on define and such even though we don't process them through linter in the console flow.

Also curious if jest env is up to date in ESLint. If to doesn't include Jasmine 2 things like fit maybe we should just hardcode globals into lint config.

It should be up-do-date: https://github.com/sindresorhus/globals/blob/master/globals.json#L917

Ok looks good. Let's add this to main config in config folder then, and we can drop the special case from our root config in dot file.

Ok pushed, we still need it in the project itself for the test in the template though.

Yes but aren't we already using config/eslint there? Seems like Object.assign for jest: true wouldn't do anything because this property is already there now. But maybe I misunderstood.

Oh, yeah I just noticed! Alright, removed it from the project dot file.

Thank you for all the back and forth.

Correct link for the Jest 14 blog post in the title: http://facebook.github.io/jest/blog/2016/07/27/jest-14.html

Per the giant twitter discussion, here is a summary of some of the unresolved concerns with this pull request:

From experience, few use Jest outside of Facebook (said by @ryanflorence, @kentcdodds, @trevordmiller)
Browser + Webpack runner may still be needed for accessibility and browser issues (said by @iammerrick, @marcysutton); Chrome headless browser might be nice coming soon
Mocking is not beginner friendly or isolated (said by @ryanflorence, @iammerrick); @gaearon responded that CRA will not use mocking but still something to consider
CRA wont have browser stuff in it, not yet anyway (said by @gaearon); @trevordmiller suggests using AVA or Mocha with Node only (no browser stuff) instead of Jest since they are much more widely used outside of Facebook

Woah! @trevordmiller you are just great, thank you for doing this!

using AVA or Mocha with Node

As someone who was a big proponent of AVA, I should say that I've since decided that AVA's got some issues that make it difficult to work with and I wouldn't recommend beginners use it. I intend to write a blogpost sometime about things that AVA could do to improve. But for myself I'm switching to Mocha and that's what I'd recommend for CRA.

Mocking is not beginner friendly or isolated (said by @ryanflorence, @iammerrick); @gaearon responded that CRA will not use mocking but still something to consider

Can you please clarify what should be considered there given that the feature is disabled?

Can you please clarify what should be considered there given that the feature is disabled?

Given that mocking is a prominent feature of Jest, documenting the variance from the default behavior should be considered.

DOM testing should be left to webdriver or other end-to-end tests.

Note that Phantom/headless still has issues with testing focus, as far as I know, so that sounds like a good assumption. https://github.com/ariya/phantomjs/issues/10427

As someone who was a big proponent of AVA, I should say that I've since decided that AVA's got some issues that make it difficult to work with and I wouldn't recommend beginners use it. I intend to write a blogpost sometime about things that AVA could do to improve. But for myself I'm switching to Mocha and that's what I'd recommend for CRA.

That's good feedback @kentcdodds - I'll do the same :) I'll update the original post to reflect.

Thank you for bringing up these concerns. First I want to say that we (Facebook) completely dropped the ball on Jest. We open sourced it two years ago and stopped maintaining and working on it. For the entire past year, besides other JavaScript infrastructure work, I have worked full time on Jest to make it actually really good and we now have two people committed to work on it full-time (Hi @dmitriiabramov!). I think these graphs are telling and I am committed to work on Jest long-term. However, I completely understand that we are fighting an uphill battle and negating the negativity around the project from the first year of its existence is really really hard. We thought about rebranding the project but I believe that the only way we can change the perception is by actually putting our hearts into it and making it really good, which is nothing but hard work over a long period of time.
Let me answer your questions:
Few use Jest outside of Facebook and CRA wont have browser stuff in it, not yet anyway; @trevordmiller suggests using Mocha with Node only (no browser stuff) instead of Jest
Jest is definitely less popular than other frameworks, for the reasons I mentioned above. However, more and more people are adopting it recently and Jest now integrates perfectly with react-native. The framework is used in many large apps that you don't often hear about because they aren't open source (I'm often surprised when I find out myself). I would consider it as recently launched, to be honest, and ask you to throw away any preconception you might have built up previously. If popularity is an actual concern, I think we should have never released React or any other one of our open source projects in the first place. What matters are the features and ease-of-use.
Jest provides these things:

Test isolation and sandboxing: no two tests will ever conflict with each other, nor will there ever be any global or module local state that is going to cause trouble.
Performance: Jest is built for scale to support both huge and small projects. It will always be fast. We cache babel's output and always only do the minimal amount of work necessary to always provide fast iteration speed and Jest runs tests in parallel. It is simply not useful to wait for a bundle to be built before tests can be run and not scalable for bigger projects.
Full code coverage support. Simply run Jest using --coverage. No additional tooling is required. We are currently rewriting it and working on making it awesome.
Snapshot testing with great UX for React and react-native integration. We have more ideas for improving the test-renderer and I fully expect snapshot testing without the DOM to become the standard for React and react-native applications.
Easy setup: We made an effort to make it easy to use and set-up and we are working on making our configuration actually really good.

On top of some great features it is really a regular test runner like all the others that use Jasmine. Libraries like chai work with Jest out of the box and there aren't any unexpected surprises. We split up Jest into packages and are happy to integrate other test runners apart from Jasmine.
Please check out everything that is listed on the website and take a look at what we are working on.
Browser + Webpack runner may still be needed for accessibility and browser issues; Chrome headless browser might be a good option
I see testing as a pyramid. The foundation is to have tons of unit tests with a small layer of integration tests on top and then one or two end-to-end (webdriver etc.) tests per product that ensure everything works well together. No one single testing solution is either enough nor useful on its own. However, unit tests should be at the core as unit test runners tend to be fast and give you immediate feedback. End-to-end tests often tend to be flaky, take a long time to run and often aren't very helpful for debugging. We described this in our blog post of why we built snapshot testing. I think it is reasonable for create-react-app to provide a solution for the lowest testing layer and not be opinionated about what people would like to use on top of it.
Mocking is not beginner friendly or isolated; CRA will not use mocking but still something to consider
Please note that there is a significant difference between mocking and automocking. CRA will not use automocking but Jest's module-boundary mocking system is incredibly valuable. I will have more to share on this soon but we are planning to disable automocking by default in the next (or next next) major release of Jest. It's a radical change and we have to be careful and incremental about it, which is why we are starting this here and with the react-native preset first. There are places where it shines, like adding tests to a large codebase that has no test coverage but it loses its value over time and people get confused and frustrated with it. However, we will retain the feature and Jest's module-boundary mocking system is still incredibly valuable to easily stub out any module that would go over the network or does something you want to stub in a test. For example, to achieve something similar to shallow rendering with the test renderer, any React component can simply be mocked using jest.mock('path/to/Button', () => 'Button');.
Final thoughts
Jest is an integral part of all of Facebook's JavaScript code bases: we have many thousands of tests across our web and react-native platforms and use it in all our open source projects. It's heavily integrated with our own continuous integration platform. This means we are committed to make it work well for hundreds of engineers that use it every day as well as making it scalable and performant. The philosophy behind Jest is to provide an integrated unit test experience to make it easy and efficient to write and run tests - especially for React and react-native applications. Please read our performance blog post which highlights some constraints and unique design decisions and work that we have been doing.
Unfortunately we don't get to simply start over with something completely new and we need to incrementally evolve our systems. This also means we focus on bringing the entire community with us to the latest version because open source is not just code. Jest doesn't matter to me. What matters to me are the constraints we put on ourselves, the concepts we want to popularize like snapshot testing and we want to enable people to easily write effective tests in a stable and performant environment. Currently I think Jest has a bunch of major advantages and I'm sure other test frameworks will catch up and adopt similar constraints and concepts over time. I understand that not everyone agrees and testing is an area people are particularly opinionated about but I hope that this post helps build empathy and understanding.
I want to conclude by saying that in the last six months people's reaction to Jest has been predominantly positive as compared to the time before I worked on it. It is still far from perfect but we have a plan for an entire year worth of work sketched out and are excited to tackle the challenge with you (this isn't a hiring pitch but you should come work with me anyway, you are all awesome!).
I encourage you to try out Jest, especially with the defaults we set in create-react-app, and give it a chance.
cc @ryanflorence, @kentcdodds, @trevordmiller

I fully expect snapshot testing without the DOM to become the standard for React and react-native applications.

I hope you're right, that'd be awesome. I can't wait to use that feature.

[We] are happy to integrate other test runners apart from Jasmine.

That's good to hear!

I will have more to share on this soon but we are planning to disable automocking by default in the next (or next next) major release of Jest.

Also great news. Eager to hear more about it.

we have a plan for an entire year worth of work sketched out and are excited to tackle the challenge with you

Great news as well.
I'll give Jest a try. That snapshot testing sounds amazing. Thanks for this comment.

As for including it by default in CRA, I think let's see how people like it. If people don't or find it confusing, try to fix it. If it can't be done, then pull it out. Seems kind of low risk and heck:

Thanks for the work you all put into this stuff!

Hey @cpojer, thank you for your explanation. To be honest I realized that my experience with Jest was when it was first announced and I was very frustrated by it then and gave up adopting it. I think think running browser code in a browser is a good idea but maybe not worth the performance hit/flakiness.
Thank you for taking the time to help me understand how you are thinking about this and why CRA is doing this. To be honest your pitch for Jest was so good, it made me think, "Hey maybe we should move from mocha + karma to Jest" hehe.
Again thank you, not that I am entitled to this information or that my feelings about this matter but I am grateful and feel a lot better about this decision now.

Also, snapshot testing seems very cool reminds me of https://github.com/facebookarchive/huxley which was super cool but didn't take for some reason. :-)

I was thinking the same thing. Huxley was awesome because you could see the changes. This will be much faster though 👍

Agreed @kentcdodds, snapshot tests should be more reliable and less brittle too since rendering engine overhead/glitches won't fire false errors, etc. This is lower on the pyramid and less brittle which is nice!

Thanks for the kind words. I want to stress that Jest isn't perfect yet and if you plan to try it out on a bigger project you are undoubtedly going to run into an issue. I'm happy to help personally to get you started and I want to learn what we can do better for you. Our configuration system is in dire need of a rewrite (@dmitriiabramov is thinking about it) and if you'd like to be part of the discussion to redesign it, please let me know. We are happy to do it out in the open. At Facebook, we have JS Infra teams that own the configuration and setup of their projects so naturally no one ever has to fight with it internally and it is something we traditionally aren't doing as well on as we should. Ironically we are discussing this on a project's issue tracker that was created exactly because of this situation.
I want to point out that we will go where you go and our goal is to make testing easier, not harder. Let's figure this out together.

@cpojer Thank you for the open communication and thoughtful responses. I am definitely willing to give Jest another shot as it sounds like it has improved and is headed in a nice direction. I'll look forward to trying it out. Is the issue tracker at https://github.com/facebook/jest the best place to post feedback?

Yes. I recommend joining our discord channel and talking to me directly. Live discussions are usually much more useful and have better turnaround times.

@cpojer Awesome :) Thank you. Which Discord channel?

I'm sure you will #jest be fine looking for it yourself.

We use jest at Intercom and are extremely happy with it. I remember trying to get it working 2 years ago, and I can't stress enough how much it's changed for the better since then. Highly recommend giving it another go if you're skeptical.

Just to balance @irvinebroque
We use Jest in a medium sized codebase, and it's ok.
Automocking is an anti-pattern (it was a fad in 07-08 in the .Net ecosystem and we quickly learnt it caused problem), however we inherited the codebase, and they had very much gone down that path.  The lack of commitment to improvement from Facebook up to now has been frustrating.  It can be dog slow (we have 1266 tests, and I can heat my flat with the hot air the fans spit out if the suite runs a few times in a row).  It used to take over 200s to run, which has came down to 69s with Jest upgrades over the past 18months.  We aren't using the new snapshot feature yet, this may reduce the run time further.
Having Jest as the default testing framework for this makes sense, as its a FB product.  However, might I suggest that it should be possible to eject only the testing configuration, to allow for swapping that out, while keeping the rest of the app managed.

You don't technically need to "eject" testing configuration because it would be equivalent to just using your own test runner. Since testing is fairly independent all you need to do is to change test to run something else.

It can be dog slow (we have 1266 tests, and I can heat my flat with the hot air the fans spit out if the suite runs a few times in a row).

Do you use watching or do you mean consecutive full runs?

:+1: on Jest.
The goal of create-react-app, as I see it at least, is to have the "batteries included", and Jest is really good at this. I've had some experience introducing people who had never done unit testing before (not even in Java, etc), pointed them at Jest with a few tips to set it up, and they were up and running in no time.
For the longest time I was a Mocha guy and dismissed Jest, wanting browser support, complained about slowness, blah blah. In the last couple of months I had a change of heart.
With recent tooling, node-only test debugging is now pretty easy (eg: iron-node). Also, headless browsers are not close enough to "real" browsers to really be meaningful. And real browsers are poor choices for CI of unit tests (actual unit tests, not e2e or integration tests). So having a suite of "pure" unit tests is easier and better, and you can couple it with a suite of e2e tests running in real browsers with karma or whatsnot.
The test isolation in Jest solves a very common problem where tests leak into each other that plagues begginers. The coverage report of only things you meant to test is also a pretty clever way to get relevent metrics. And now we have snapshot tests.
Even in the original version of Jest, performance would not be a big deal for 99% of users (I like to test everything and end up with several thousand tests, but in the age of micro apps and people only testing a subset of functionalities, the vast majority of users will never hit a threshold where performance is an issue). Even if it was, Jest is decently fast now.
The automocks may be seen by an anti-pattern by some, but its easy to disable, and the implementation in Jest is actually pretty good and flexible. Working with newcomers, I've had a lot of success with it.
I'd dare say, karma+browser for unit tests is the anti-pattern, even if using Mocha or whatsnot, for unit tests you'd want the tests running in node.
The one gotcha, and I mentioned it in a few channels before: they have to commit to keeping Jest working well on Windows. Even though I don't use Windows to develop, a very large segment of the community, especially create-react-app's target demographic, is on Windows, and there's been a lot of hiccups on that side before. Mocha + Chai + Webpack work perfectly on WIndows, so it won't take too many hiccups before people say this was a mistakes.

they have to commit to keeping Jest working well on Windows. Even though I don't use Windows to develop, a very large segment of the community, especially create-react-app's target demographic, is on Windows, and there's been a lot of hiccups on that side before.

We definitely want to keep an eye on this.
Create React App is committed to full Windows support for all its features.

they have to commit to keeping Jest working well on Windows

There's not many Windows users at Facebook. I'm one of them, I actively use Nuclide, Jest, etc. on Windows and submit bug fixes :smile: . Some projects use AppVeyor for continuous integration in a Windows environment to ensure that the Windows builds don't break. Not sure if Jest is using AppVeyor yet, but it's probably worth configuring.

We definitely want to keep an eye on this.
Create React App is committed to full Windows support for all its features.

Yeah, so if it goes the Jest route, that forces the Jest team to have the same commitment (and Linux subsystem for Windows that was released officially yesterday is an escape hatch, but doesn't cover all use cases, so it can't be 100% relied upon).
If they are though, Jest is really the best solution for a project like this :heart:

@carcer thanks for your feedback. Are you talking about 1200 tests or 1200 test suites (individual files)? Generally, any large company will always run into trouble with any test framework if they don't actively work on the test infra themselves, that's just natural. I am planning to eventually switch FB off of automocking entirely and there will likely be codemods that we can share. I recommend for new tests to start off with jest.disableAutomock() and slowly convert old ones when you touch them. We have found this to work well at FB if we provide a few default mocks in our setup files. There are also a bunch of knobs you can turn to get your test suite to be faster, and jest -o should only run affected test files during development to run the minimal amount of tests necessary. Generally, Jest has a lot of room to optimize performance once you get to a bigger scale. I'm also happy to visit your office in person and talk about this and maybe give a talk if you think this is impactful for you and your colleagues.
Replacing Jest
We aren't adding any configuration to the apps created by CRA so swapping Jest for something else only requires to update the scripts.test field in your package.json, there is no overhead or clutter that sticks around.
Windows Support
We are of course committed to supporting windows users well. @Daniel15 has been helping out a lot. If something isn't working well, please bring it up to us and we'll fix it. If someone wants to help fix up Jest's integration tests for a Windows CI and get them running there properly, that would be appreciated as well and makes us more proactive instead of reactive to issues.

Thanks a lot to everyone in this thread for your feedback.
Automocking is now off by default in Jest 15.
The output has been vastly improved too.
Interactive watch mode:

Object diffs and failure output (before and after):

Console output (before and after):

Read more about Jest 15.

I'm SO excited to try this out!

@gaearon @cpojer Much better :) Would be cool if instructions for testing with CRA could be added to https://github.com/facebookincubator/create-react-app/tree/master/template. I would submit a PR, but I'm swamped right now.

Testing with CRA is not out in an official release, that’s why it’s undocumented.
I’m waiting for a couple more small things before cutting it, and I’ll document it when I do.


First contribution

first contribution

wanted to add  details and time/space complexity about binary search.

/assign


Timezone handling when sensor configured in one tz and used in other tz

GGIR was designed with the implicit assumption that measurements take place in the timezone where the device is configured. However, in some studies this is not the case. I am working on a way to separately specify timezone of measurement (current argument desiredtz) and timezone of device configuration (scheduled new argument configtz).

Addressed now for Axivitiy AX3 cwa data, but not for other accelerometer brands and data formats yet. I have clarified this in the documentation and changelog.

I have merged this into the master branch and it will be in the next release on CRAN


Escapes invalid class characters

Pull request type
What kind of pull request is this? Put an x in all the boxes that apply:

[X] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Extend feature (non-breaking change which extends existing functionality)
[ ] Change feature (non-breaking change which either changes or refactors existing functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to change)

What does it change?
tailwindcss-open-variant currently produces classes like this one:
[open].open:rotate-90[open], details[open] .open:rotate-90

The colons are invalid in CSS and need to be escaped. Tailwind's e helper was designed for this use case. My commit produces classes like this:
[open].open\:rotate-90[open], details[open] .open\:rotate-90

With the colons escaped, the CSS is valid.
Why this PR?
See above
How has this been tested?
Tested manually in one of my apps.
Checklist
To facilitate merging your change and the approval of this PR, please make sure you've reviewed and applied the following:

This PR addresses exactly one issue
All changes were made in a fork of this project (preferably also in a separate branch)
It follows the code style of this project
Tests were added to cover the changes
All previously existing tests still pass
If the change to the code requires a change to the documentation, it has been updated accordingly
You have read the notes on contributing to the project and adhere to the rules laid out

If you're unsure about any of these, don't hesitate to ask. We're here to help!

I am running this in my own project with Tailwind 3. And it works well. Looks good to merge to me.

Neat 👍
Just wanted to note that the open variant has first-party support in Tailwind 3.x: https://tailwindcss.com/docs/hover-focus-and-other-states#open-closed-state
This plugin is definitely still useful for anyone on 2.x though.

Thanks @AlexVipond
For anyone switching from this PR code to the logic built in with Tailwind, I previously had:

            {{ $summary }}

        {{ $slot }}

But the open prefix only works on the details element, you'll need to use the preferable group and group-open options like this:

            {{ $summary }}

        {{ $slot }}


Long continous text solution for components

Long continuous texts created below problem in picture for us in Accordions. This task is about making a solution for this.
Additional info:

This character may be used to conditionally split words: Soft Hyphen U+00ad.

Tasks:

[ ] Find out how to insert soft hyphens in text from database in bff
[ ] Make accordion react to special characters the same way it reacts to soft hyphens.

AC:

Long continous texts doesn't make components take up more space than set.

Design review:

Gå til https://am.ui.at23.altinn.cloud/accessmanagement/ui/offered-api-delegations/choose-api og se på det lengste sammenhengende api-navnet om det blir splittet over flere linjer.

så veldig greit ut. Sjekket og satt til test


Practice exercises example solutions do not follow file structure/naming standard

Practice exercises’ example solution files do not follow the structure/naming specified in https://exercism.org/docs/building/tracks/practice-exercises
The docs use the .meta/example.rb (or exemplar.rbif it is a concept exercise) naming convention but the practice exercises use .meta/solutions/exercise_name.rb
(The test suite only covers practice tests, not concept exercises. I'd like to try to extend the test system to include concept exercises, but I'd rather wait until the practice exercises are updated).

Changing the location of the example solutions for practice exercises should be easy to automate with a script. It just needs to move the files and then update the config.json files with new paths. But before we attempt this we would need @iHiD to confirm if he even wants the change in the Ruby track?

Seems like I never got notified of the previous comment, so I did not wait.
Was a learning experience even if it never gets used.


AnimationNodeBlendTreeEditor: Fix popup locations when creating nodes with dragging

Fixes  #69413. _connection_to_empty and _connection_from_empty were using a different callback which used global mouse pos for popup creation instead of animation blend tree's local coordinates

Right. I assume, that graph->get_local_mouse_position() can also be moved to the _popup-function. LGTM.

Thanks!


Fix the faq sec in the mobile view

add a bit of padding outside the faq boxes.
space it out a bit
also fix the overflow at the y axis

Hey @jay-io i would like to work on this issue.

@Debdeep1 #116 Revamped the whole FAQ, so this issue can be closed ig.


cannot use nil as type ora.DrvCfg in argument to ora.Register

I see this error when I try "go build" and import gopkg.in/rana/ora.v4.  No error when I do the same with gopkg.in/rana/ora.v3.
ora.Register(nil) has worked without incident using v3 for months.  Any ideas?

Yes. ora.v4 is a different version, with a few backward-incompatible changes.
You don't need Register anymore.

Thanks for the help.  All squared away.


Add testcards for calibrating CRT monitors

This adds new video testcards for adjusting purity, convergence and linearity on CRT monitors, plus EBU(-ish) 75% and 100% colour bars. These are all full-screen displays that don't show the menu - the dots/crosshatch displays use a single bitplane with full overscan, and the others are copper-generated.
I've tested it on a PAL A500 and A1200, and it seems to produce reasonable RGB and composite signals on both. But this is my first attempt at low-level Amiga graphics programming, so please let me know if I've done anything silly...

Thanks!

Now merged on top of CI fixes. I will follow up with some minor tweaks later, in my tree.


Unable to locate MSBuild in C:\Windows\Microsoft.NET\Framework\v4.0.30319

Is there possible to use MSBuild for .NET 4.0 from OmniSharp VSCode to build .NET 4.6 projects?

No. OmniSharp requires MSBuild 15.1. Also, not that OmniSharp does ship with a version of the MSBuild engine that it will use if it can't find one. However, the tasks/targets for compiling a .NET 4.6 project must be available for it to use.
On Windows, you should be able to install the Visual Studio 2017 Build Tools with the appropriate workloads and OmniSharp will use it.


240 Unit Prototype Refactor

Resolves #240 .  Should be reasonable size minus the JSON (how do we teach GitHub not to count its lines of code?  Tortoise seems to have already picked up on that locally).
This adds unit prototypes to both our JSON, and our import from Civ3.  They will no longer be hard-coded.
I've structured them to have three configurable/expandable properties:

Category.  Land/air/sea for now.  Could be extended in the future.
Actions.  These are, well, actions the user can take with a unit.  Will typically (always?) correspond to a button.
Attributes.  These are properties of the unit.  King unit.  Generates leaders.  Starts golden age.  Etc.

There will likely be more eventually, e.g. AvailableTo, IgnoresMovementCost, CanMoveOnTerrain.  But they can be added as we implement them.
Sample JSON prototype:
      "Warrior": {
        "name": "Warrior",
        "shieldCost": 10,
        "populationCost": 0,
        "attack": 1,
        "defense": 1,
        "bombard": 0,
        "movement": 1,
        "iconIndex": 6,
        "categories": [
          "Land"
        ],
        "actions": [
          "hold",
          "wait",
          "fortify",
          "disband",
          "goTo"
        ],
        "attributes": []
      },

Of note, UnitWithAvailableActions in UnitInteractions is something I'm favoring refactoring as well, now that actions are primarily stored on the prototype.  We still need to return them, but it seems it would make sense to return a list of actions by itself.  However, to avoid scope creep on the refactor, and because the goal of the refactor was to allow back-end improvements (e.g. AI making decisions based on prototypes), I decided to leave that for later.

I'm thinking give it a bit more structure. Not only does that group logically related attributes but it makes it easier to grab a whole set that may contain other keys later:
"cost": {   "production": 10,   "population": 0 }, 'movement": {   "speed": 1,   "ignoreCost": [] }, "bombard": {   "strength": 0,   "range": 0,   "rate": 0 }
etc.

Follow-up thought: we've tossed around the idea of direct JSON serialization, which would suggest the format should follow the class structure. In that case this becomes more of an architectural question...

I thought I'd replied to your comment on 4/25, but must have only thought about it.  My impression is that Ozymandias has been pushing for flatter structures to make it easier to add new properties.  That isn't necessarily incompatible with nesting, however, so long as we make it easy to grab nested properties with keys.  e.g. unitPrototype.get("bombard.strength") could return the nested strength attribute on the bombard group.
The main advantage I see in that is for self-documentation/readability.  Some of the Civ3 properties have similar names to each other, especially on unit prototypes, and I find myself having to look up which one is which occasionally even now.  Admittedly I don't really follow the goal of "makes it easier to grab a whole set that may contain other keys later".  When would that be beneficial?
For now, since there's an approval, and this is required for future Carthage goals (notably around the AI decision-making), I'm going to go ahead and merge that.  No opposition to a discussion/issue/etc. for potential future nesting.


Incorrectly determines the external IP of the server

ip address of the server is incorrect

Using gethostbyname($_SERVER["HTTP_HOST"]) to define gives a more correct result

thanks i will fix this soon


Not all Keys are possible for Hotkey

Some keys can not be used as a hotkey yet:
Mouse Keys (for example m4,m5)
Some special input (for example - +)

fixed in dev branc, works in new releases
middle mouse button not functioning, but leaving that until someone really needs it.. :dancer:


Update Charter: update project structure and add working groups

add Working Groups
change "Technical Committee" to "Committee"
remove language from when we started

replaces part of #71

Can you make sure that all charter changes that the group wants are aggregated into a redline document, so LF legal can review and signoff before they're applied.

Hi Kate,
Do you want one Word document with tracked changes combining all changes (like #71 had it) or a different document for each change that we will vote on (#80, #81, #82, and #83)?

The change was reviewed and approved by Mike Dolan from the LF. The Governing Board accepted this change on 2018-03-15.


upload multiple files

upload multiple files - does not work for Android 7.0

I haven't worked on uploading multiple files yet.


Update value range from 2^40 to 2^100

Anticipating that users and use cases might need a bigger range to accommodate the token practice to use 18 decimals. Using [0, 2^100) as the range allows a token economy built on zeto to have a trillion tokens each with 18 decimals.

There should be some other places used $2^40$, (could be for a different purpose). Worth double check whether it needs update as well


[Select] [Vue] [Feature]: Custom data structure

Hello,
This is related to https://github.com/chakra-ui/ark/issues/826. It would be great to be able to use a custom data structure for the Select component. This would make it possible to use any data source without having to translate it into { label: "", value: "" }.
Use case:
Consider this scenario; currently, I'm trying to implement this with a list of currencies. The currency object structure is:
{
  code: "USD",
  decimal_digits: 2,
  name: "US Dollar",
  name_plural: "US dollars",
  rounding: 0,
  symbol:  "$",
  symbol_native:  "$",
}

It would be great to use this data structure directly within the default slot of SelectOption and subsequently sync it with my state management without additional fuss. At the very least, being able to pass it in addition to the label and value keys would be potentially sufficient. For example:
{
  label: "US Dollar",
  value: "",
  customData: {
    code: "USD",
    decimal_digits: 2,
    name: "US Dollar",
    name_plural: "US dollars",
    rounding: 0,
    symbol:  "$",
    symbol_native:  "$",
}
}

Currently any additional data is stripped from the selected option.
I'm not sure if changing this would affect accessibility adversely, but just throwing it out there as I think it would greatly increase the flexibility of the component.

@jiblett1000 I think this would cause unnecessary overhead and complexity in the underlying logic. With the current approach, you can just check your array of objects with Array.find once it's time to use the value for something.
const ccurrencyObj = currencies.find(c => c.code === selectedOption)

@anubra266 As always, thanks for the response! Unfortunate to hear, but I can appreciate how it might complicate things on your end. I am currently using a solution similar to yours above (as well as mapping the options on the other side of things). I hope you will at least keep it in mind going forward :pray: , but if it never makes it in, also not the end of the world. Either way, I appreciate all the great work :smile:

I did want to refactor the select machine to support that request. Downshift has one of the best APIs for select components, and we could take some ideas from it.
We also need to reduce the DOM queries we’re currently doing to find items in the dom. The current API struggles to handle virtualized selects (with large option data).
We'll improve this over time, but let's use the suggested approach from @anubra266.

fyi I just encountered this also and would have found it much more ergnomic to be able to pass data along. In particular, the current approach makes context.selectedOption questionnable in its usefulness. For example, if I want to render a custom icon in the trigger button, I can't use context because I can't pass that information there. Instead I have to track outside of ark and lookup.


The getter 'notifier' isn't defined for the type 'ChangeNotifierProvider'.

from the doc https://riverpod.dev/docs/from_provider/quickstart
MultiProvider(
  providers: [
    ChangeNotifierProvider.value(value: ref.watch(myNotifierProvider.notifier)),
  ]
)

I get the following error
The getter 'notifier' isn't defined for the type 'ChangeNotifierProvider<myNotifier>'.
Try importing the library that defines 'notifier', correcting the name to the name of an existing getter, or defining a getter or field named 'notifier'.

What do I miss?

Solve: I was using ChangeNotifierProvider from provider, not riverpod


Fix issues reported by luacheck

luacheck is a great tool for checking problems in Lua files.
This patch reduces the number of warnings in these three files
from 44 to 20 (the remaining ones are less critical).
I ran luacheck with:
luacheck parser-gen.lua errorgen.lua peg-parser.lua --ignore '6..'

(The --ignore '6..' option is for ignoring whitespace warnings.
You can create a .luacheckrc file in your repository with some
default luacheck options too.)

Good work! Did you test out the "node" functionality?

Did you test out the "node" functionality?

Not yet, thank you!


Fix missing MOC generation for correct including

If you try to use clean code programming using CMake you will not pollute global namespace with unnessesary variables.
For using this library user had to and newbie developers usually do define something like this:
set(CMAKE_AUTOMOC ON)
set(CMAKE_AUTOUIC ON)
set(CMAKE_AUTORCC ON)

You could see this many times in various tutorials and sample projects.
More correct way is to define variables like AUTOMOC on per project basis library using set_target_property command.
As for define required C++ standard since you do not use specific compiler's features you can use CXX_STANDARD variable as for portable. Again on per project basic.
Since you do use C language (defined by default) you need to define list of used languages (only C++ usually). This will increase CMake configure time especially if users of library also uses only C++ in Qt projects

Thanks for the tips, merged!

You welcome


Could not get usedSpace: Corruption: CURRENT file does not end with newline

Hello,
I am using https://storj.io/share.html and it having problem writing. It gets the error:
Could not get usedSpace: Corruption: CURRENT file does not end with newline .
Can this error be fixed?
Thanks

Sorry, but I don't use that software.


Add Webhook for Telemetry2U

Summary

...
Changes

Added Telemetry2U Webhook

Notes for Reviewers

...
Checklist

[ ] Scope: The referenced issue is addressed, there are no unrelated changes.
[ ] Compatibility: The changes are backwards compatible, they don't break existing deployments.
[ ] Testing: The changes are tested.
[ ] Documentation: Relevant documentation is added or updated.

Hi @nejraselimovic thanks for your feedback, I'd missed those requirements and we'll get to work on them. You will be able to access it from the free trial but there's an extra step required that we'll need to describe in the documentation guide for the integration. We'll get that sorted out in the next couple of days and update the pull request.

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.

Hi @nejraselimovic I've updated the templates.yml and the documentation update is under the following pull request:
https://github.com/TheThingsIndustries/lorawan-stack-docs/pull/841


Need configurable list of certificate hosts

See the following:

https://github.com/mantl/mantl/commit/391181ba5b5370d46b5877a424c3290aaba9f709
https://github.com/mantl/mantl/issues/1937
https://github.com/mantl/mantl/issues/1821

Have you looked at using vault's pki for this?
You would still need the configurable list of defaults per cloud provider, but vault allows you to generate rotatable, audited pkis.
The nice thing is, if you want container-terminated ssl, you will probably need vault or something similar to issue certs with service names injected into the ALT NAMES.
We had this working at my company where every container ran a base_container_startup.sh to ask vault for certs (and fail back to default file location if that failed).
I know the mantl team was looking into this and there may be a PR out there somewheres.

@Theaxiom feedback?

#2017

@kbroughton I was thinking either that, or ACME (Let's Encrypt) or a combination of both.


[Bulk] Validation: duplicate-description | 2

Fix duplicate-description in 49 files - (VB)/(C#) only

Global effort to fix validation errors
@Rick-Anderson
The Content & Learning team is fixing build validation errors on docs.microsoft.com. This effort will eliminate potential accessibility, security, and usability issues. This PR includes only build validation fixes and does not change other content. I’d very much appreciate your timely review and feedback on these changes I’ve suggested. Thanks!


[v2.8] feat: added capi label to kubeconfig secrets

Issue: #42333
Problem
If we upgrade to use CAPI 1.5.0 or higher its required that the secrets used for kubeconfigs contain a label cluster.x-k8s.io/cluster-name=${CLUSTER_NAME}. Without this, the CAPI cluster/machine reconcilers will fail with a failed to retrieve kubeconfig secret for Cluster error.
See the CAPI migration guide: https://github.com/kubernetes-sigs/cluster-api/blob/main/docs/book/src/developer/providers/migrations/v1.4-to-v1.5.md#other
Solution
This adds the required label when we create the secret that contains the kubeconfig. A migration has also been added thats called at startup (on leader election) that will add the label to any kubeconfig secret for an RKE2 cluster.
Even though 1.4.4 will be used with the un-embedding it would be good to get this change in upfront.
Testing

Create an RKE2 based cluster with a previous version
Find the  kubeconfig secret for the cluster. It will be named [CLUSTERNAME]-kubeconfig and will likely be in the fleet-default namespace
Check that it does NOT have a label name cluster.x-k8s.io/cluster-name
Upgrade Rancher to a version with the change in
Check the same secret to see if the cluster.x-k8s.io/cluster-name now exists.
Create a new RKE2 based cluster and when its provisioned, check that the kubeconfig secret has the cluster.x-k8s.io/cluster-name label

Engineering Testing
Manual Testing
Manually local testing carried out.
Automated Testing
NONE
QA Testing Considerations

Regressions Considerations

TODO
Existing / newly added automated tests that provide evidence there are no regressions:

TODO

controller-gen issue seems to be unrelated flake? Probably we need to re-run it

There is now this issue related to controller-gen:
#9 [stage-0  8/18] RUN go install sigs.k8s.io/controller-tools/cmd/controll...

#9 0.409 go<EMAIL_ADDRESS><EMAIL_ADDRESS>Get<EMAIL_ADDRESS>EOF

#9 ERROR: process "/bin/sh -c go install<EMAIL_ADDRESS>did not complete successfully: exit code: 1

But i don't think thats related to this change.

Created a Docker image with a modified Dockerfile.dapper till stage 7 https://github.com/rancher/rancher/blob/446d9f3d77118ef9614b7bfd7866304cc622ba5e/Dockerfile.dapper#L30-L33
Created a docker container with the test image and executed
go install<EMAIL_ADDRESS>
the above completed successfully with exit code 0

Created a Docker image with a modified Dockerfile.dapper till stage 7
https://github.com/rancher/rancher/blob/446d9f3d77118ef9614b7bfd7866304cc622ba5e/Dockerfile.dapper#L30-L33
Created a docker container with the test image and executed
go install<EMAIL_ADDRESS>
the above completed successfully with exit code 0

Drone is getting further now. Its the usual flakiness that happens with drone!

Created a Docker image with a modified Dockerfile.dapper till stage 7
https://github.com/rancher/rancher/blob/446d9f3d77118ef9614b7bfd7866304cc622ba5e/Dockerfile.dapper#L30-L33
Created a docker container with the test image and executed
go install<EMAIL_ADDRESS>
the above completed successfully with exit code 0

Drone is getting further now. Its the usual flakiness that happens with drone!

Seems like an issue with proxy.golang.org https://github.com/golang/go/issues/63684

Seems like it was an issue with proxy.golang.org golang/go#63684

Good find 👍

As per the discussion here added DNM.

Removed DNM since we want it in 2.8 (and 2.9) now. @jakefhyde @Oats87 , please review.

Ideally, we need #43903 merging first so that we can remove the auto-generated code files updates from this PR.


Fixing bug in convertThreeCamValuesToEngineCam

closes https://github.com/KittyCAD/modeling-app/issues/3307
Looking at this table, the previous hard coded vector of <0,0,1> worked because the up vector of the camera was the same orientation for XZ and YZ. For XY the up vector is not <0,0,1> the up vector should be <0,1,0> since Y is now up for the camera.

planes
engine + edit sketch synced

-XY
:x:

XY
:x:

-XZ
:heavy_check_mark:

XZ
:heavy_check_mark:

-YZ
:heavy_check_mark:

YZ
:heavy_check_mark:

After the fix I am able to edit the sketch and pan in each mode and have the engine match the sketch.
Commentary

If this works, lgtm.
One thing I would check is entering an "XY" sketch, then exiting, then dragging the mouse and check the camera and gizmo doesn't do funny. i.e. the blue Z axis should be able to rock backwards like this
https://github.com/user-attachments/assets/c944528d-d486-4e1f-8c4e-1950b161f7ce
But if it ever start rotating sideways, like pointing diagonally like this

Then it's an indication that the camera is no longer using z-up, which we don't want.
I mention this because I've had trouble with sending a command like this and than the engine rotation getting weird afterwards.

If the above is a problem, we might be able to send a sane z-up again when the user leaves sketch mode or something. But maybe it's fine.


postgresql (9.6.2) installation failure

Postgresql 9.4.0 was uninstalled, no postgresql service is running, but postgresql installation fails.
PS C:\Users\martin> $PSVersionTable.PSVersion

Major  Minor  Build  Revision
-----  -----  -----  --------
4      0      -1     -1

PS C:\Users\martin> scoop install postgresql
Installing 'postgresql' (9.6.2).
postgresql-9.6.2-1-windows-x64-binaries.zip (179,5 MB) [======================================================] 100%
Checking hash of postgresql-9.6.2-1-windows-x64-binaries.zip... ok.
Extracting... Unzip failed: Exception calling "ExtractToDirectory" with "2" argument(s): "The process cannot access the
file 'C:\Users\martin\scoop\apps\postgresql\9.6.2\_scoop_extract\pgsql\bin\createuser.exe' because it is being used by a nother process."

Could you help me to solve the issue?

Does the directory C:\Users\martin\scoop\apps\postgresql still exists after uninstalling postgresql?
Did you try to remove it manually?
Have you tried turning it off and on again? (aka restarted your pc)

Does the directory C:\Users\martin\scoop\apps\postgresql still exists after uninstalling postgresql?
Did you try to remove it manually?
after scoop uninstall postgresql directory is correctly removed

Have you tried turning it off and on again? (aka restarted your pc)
yes.

Can you remove in manually?

There was nothing to remove after scoop uninstall postgresql. There was no postgresql in the app folder.

What happens if you extract postgresql-9.6.2-1-windows-x64-binaries.zip manually somewhere? Does this work?  If it does turn out to solve the problem, please let us know which antivirus program you're using. Maybe we can detect it or at least document it for others.

Windows defender was turned off. I turned it on and installation works now.

Thanks a lot for your prompt support!


style(formatting): Run rustfmt

There were the following issues with your Pull Request

Commit: f42f5fa004cacf0f1570d4d38c815a1af958fcd6
Commits must be in the following format: %{type}(%{scope}): %{description}

Guidelines are available at https://github.com/lettre/lettre

This message was auto-generated by https://gitcop.com


Footprints

Can you please add footprints so I can make the PCB layout?
At least I need one for the DFPLayer Mini

Yes please. Footprint seems to be unavailable for this module on Internet.


don't hardcode meth & CN

https://github.com/cvraut/iBAGpkg/blob/fb437579895c4e9a9fd766ef2ab506578c117918/R/objects.R#L21
This should datasource1, datasource2, etc...

we will always need mrna & datasource 1 & outcome

datasource should be a LL

corrected in branch project rename


migrate to 0.4.4

change pragma headers
remove Rejector.sol, not needed in ^0.4.0

fixes https://github.com/OpenZeppelin/zeppelin-solidity/issues/59

Looks good. The Solidity style guide recommends a 2 line separation between top level declarations, so we should format files like this prior to the first release:
pragma solidity ^0.4.4;

import "../MyImport.sol";

/*
 * MyContract
 * Here goes the contract description
 */
contract MyContract {
  ...
}

@federicobond transformed your comment into https://github.com/OpenZeppelin/zeppelin-solidity/issues/61


iosevka: 22.1.0 → 22.1.1

Diff: https://github.com/be5invis/iosevka/compare/v22.1.0...v22.1.1
Description of changes

Things done

Built on platform(s)

[x] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

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

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

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

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[x] Fits CONTRIBUTING.md.

Superseded by #231926


Simplify piped controller by introducing a new deploysource package

What this PR does / why we need it:
Sorry for this big PR. I was unable to break it into smaller ones.
This PR introduces a new deploysource package and applies it in some packages for piped such as scheduler, planner, executor.
By using this new package, we can archive the following benefits:

decoupling the source/config preparing for the running commit and the target commit
(Because the rollback stage does not require the source/config of the target commit. So by decoupling them, when the target commit/configuration could not be loaded successfully, the rollback stage will not be affected)
preparing source will be lazied. This means they will be loaded only when needed
DRY

Which issue(s) this PR fixes:
Fixes #
Does this PR introduce a user-facing change?:

NONE

/todo skip