Shovel emoji

Shovels and Spades are tools used do dig holes and otherwise move sand and other commodities, not limited to construction sites.
The pre-emoji Unicode document L2/03-354 / N2655 proposed a Spade character to indicate agricultural terms in dictionaries, but unlike other proposals in that document (⚒⚓⚔⚕⚖⚗⚘⚙⚚⚛), many of which later became emojis, the spade wasn’t included (and neither were Compasses #241 nor Plummet #242).

I find it very difficult to believe there is no shovel emoji yet.  Of all the emojis I've searched for and not found, this is the one I've missed most often.

agarra la pala

Shovel emoji could be usable.


Unable to access applications using Ambassador with Istio auth

I have a v1.9.2 kubernetes deployment with istio-0.6.0 (installed using kubectl apply -f install/kubernetes/istio-auth.yaml). This environment work using both the sample bookinfo application and my own basic REST application via the default Istio ingress however when I attempt to deploy Ambassador I get the following accessing either application via the Ambassador loadbalancer's public IP:
upstream connect error or disconnect/reset before headers
Connecting to an Ambassador pod and curling the application shows:
/application # curl -v sample-rest.default.svc.cluster.local/api/healthcheck
*   Trying <IP_ADDRESS>...
* TCP_NODELAY set
* Connected to sample-rest.default.svc.cluster.local (<IP_ADDRESS>) port 80 (#0)
> GET /api/healthcheck HTTP/1.1
> Host: sample-rest.default.svc.cluster.local
> User-Agent: curl/7.59.0
> Accept: */*
>
* Recv failure: Connection reset by peer
* Closing connection 0
curl: (56) Recv failure: Connection reset by peer

The sample httpbin redirect does work:
StatusCode        : 200
StatusDescription : OK
Content           : {
                      "origin": "52.191.208.XX"
                    }

RawContent        : HTTP/1.1 200 OK
                    access-control-allow-origin: *
                    access-control-allow-credentials: true
                    x-processed-time: 0
                    x-envoy-upstream-service-time: 10
                    Content-Length: 33
                    Content-Type: application/json
                    Dat...

If I remove istio-auth and install istio without mutual TLS (kubectl apply -f install/kubernetes/istio.yaml) then both the sample bookinfo application and my own basic REST application are accessible via the ambassador loadbalancer's public IP.
ambassador logs show:
λ  kubectl logs ambassador-b5cd67c5d-xq247 ambassador
ACCESS [2018-04-30T18:13:42.380Z] "GET /api/healthcheck HTTP/1.1" 503 UC 0 57 1 - "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/65.0.3325.181 Safari/537.36" "95ccdc6d-d868-496d-86af-26cc16930988" "<IP_ADDRESS>" "<IP_ADDRESS>:80"

I have tried altering the mapping to the service in many ways without any success.
Relevant yml files attached: yml.zip

I get a similar error. My browser tells me the connection was reset and curl states "empty response". Istio is working fine with the bookinfo sample application. I simply followed the tutorial for setting up ambassador with istio and tested it with mutual TLS and without.

I made progress on this by removing: targetPort: 8080 in the ambassador-service.yaml
Now httpbin works, but I get this error:
upstream connect error or disconnect/reset before headers

@MarcErdmann, was that targetPort setting in YAML from Datawire or something else?

I get a similar error too, nobody solve it?

I have solved all my problems. This is some time ago and I can not remember what exactly solved this, but these are my notes form then:
Install Ambassador by running kubectl apply -f ambassador/ambassador-no-rbac-tls.yaml and after all pods are running kubectl apply -f ambassador/ambassador-service-istio.yaml
- if on single server, make sure to delete istio ingress first. Otherwise Ambassador cannot be scheduled due to ports in use
- if some deployments fail to start pods, restart istio-sidecar-injector
- for Ambassador 0.34.3 ports are 80 and 443 and the respective targetPorts are 80 and 443 NOT 8080
- When you have connection reset issues you may have to disable redirect_cleartext_from: 80 in ambassador/ambassador-service-istio.yaml to allow non encrypted traffic (http) - in general make sure you have created the ambassador-certs secret by running sudo certbot certonly --manual --preferred-challenges dns and sudo kubectl create secret tls ambassador-certs --cert=/etc/letsencrypt/live/website.com/fullchain.pem --key=/etc/letsencrypt/live/website.com/privkey.pem. You maybe have to restart ambassador service
- If you get no healthy upstream make sure to set the service in the annotation explicitly like website.namespace.svc.cluster.local instead simply website
ambassador-no-rbac-tls.yaml
---
apiVersion: v1
kind: Service
metadata:
  labels:
    service: ambassador-admin
  name: ambassador-admin
spec:
  type: NodePort
  ports:
  - name: ambassador-admin
    port: 8877
    targetPort: 8877
  selector:
    service: ambassador
---
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: ambassador
spec:
  replicas: 3
  template:
    metadata:
      annotations:
        sidecar.istio.io/inject: "false"
      labels:
        service: ambassador
    spec:
      containers:
      - name: ambassador
        image: quay.io/datawire/ambassador:0.35.1
        resources:
          limits:
            cpu: 1
            memory: 400Mi
          requests:
            cpu: 200m
            memory: 100Mi
        env:
        - name: AMBASSADOR_NAMESPACE
          valueFrom:
            fieldRef:
              fieldPath: metadata.namespace
        livenessProbe:
          httpGet:
            path: /ambassador/v0/check_alive
            port: 8877
          initialDelaySeconds: 30
          periodSeconds: 3
        readinessProbe:
          httpGet:
            path: /ambassador/v0/check_ready
            port: 8877
          initialDelaySeconds: 30
          periodSeconds: 3
        volumeMounts:
        - mountPath: /etc/istiocerts/
          name: istio-certs
          readOnly: true
      - name: statsd
        image: quay.io/datawire/statsd:0.35.1
      restartPolicy: Always
      volumes:
      - name: istio-certs
        secret:
          optional: true
          secretName: istio.default

ambassador-service-istio.yaml
---
apiVersion: v1
kind: Service
metadata:
  labels:
    service: ambassador
  name: ambassador
  annotations:
    external-dns.alpha.kubernetes.io/hostname: brint.de,api.brint.de,dev.brint.de,dev.api.brint.de,www.brint.de #optional for use with kubernetes external dns
    external-dns.alpha.kubernetes.io/ttl: "120" #optional
    getambassador.io/config: |
      ---
      apiVersion: ambassador/v0
      kind:  Module
      name: tls
      config:
        server:
          enabled: True
          redirect_cleartext_from: 80
        client:
          enabled: False
        upstream:
          cert_chain_file: /etc/istiocerts/cert-chain.pem
          private_key_file: /etc/istiocerts/key.pem
spec:
  type: LoadBalancer
  ports:
   - name: ambassador
     port: 80
     targetPort: 80
   - name: ambassador-tls
     port: 443
     targetPort: 443
  selector:
    service: ambassador

@MarcErdmann  helped me solve my "no healthy upstream" issue. Thanks!


Update source.less to fix issue #3

The use of span.authorWrap around a.author was causing the default IRCCloud styling to take precendence. Moving the style to be span a.author correctly overrides the IRCCloud styling. Works with self messages, colourised nicknames on/off.
Only had a chance to confirm that it works with Chrome Stylish since that's all I use for IRCCloud. You may want to confirm it works fine for Firefox as well, though I don't see why the style change wouldn't be accepted by Firefox.

Thanks for contribution! :)


DNS Service not present on docker cluster

Hi,
When trying to deploy to the docker image with an applicationmanifest.xml which uses the DNS I receive the following error:
sfctl application create --app-name fabric:/Exchange --app-type ExchangeType --app-version 1.0.0
(FABRIC_E_DNS_SERVICE_NOT_FOUND) DnsService is not enabled on the cluster.

Is there a way to enable the DNS service on the docker cluster?

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

ID: 36484192-c2fc-5239-9d7a-d6f3bd9176f2
Version Independent ID: f1926b80-64c8-7eff-83c0-137b9a1b6ecc
Content: Set up your development environment on Mac OS X to work with Azure Service Fabric
Content Source: articles/service-fabric/service-fabric-get-started-mac.md
Service: service-fabric
Product: unspecified
GitHub Login: @sayantancs
Microsoft Alias: saysa

@lawrencegripper Thanks for the feedback! We are currently investigating and will update you shortly.

@lawrencegripper have you looked at the documentation for enabling DNS on SF?
https://docs.microsoft.com/en-us/azure/service-fabric/service-fabric-dnsservice
I believe you would need to go through these steps first.

Hi,
Thanks for the quick reply, the linked doc refers to using a SF cluster created through ARM. In the how-to doc I'm using the docker image created for mac.
It looks like the image needs to have config file updated to include the DNSServiceAddon addon
Looking at the docker image and it's setup script the image uses a .xml based cluster configuration file rather than the json format mentioned.
In theory I believe I can edit this file by adding...
    <Section Name="AddOnFeatures">
     <Parameter Name="DnsService" Value="None" />
    </Section>

But when I attempt this in the docker container I receive the following error when starting the cluster:
Running FabricDeployer
Starting FabricHost
Starting Fabric Host as console application.
 I am not seeing the author at MSFT anymore.

@dkkapur or @srrengar either of you might also be able to chime in on this

Hi Lawrence,
In the docs, it is stated that DNS Service not working is a known limitation of this that we are working on.
Known Limitations
The following are known limitations of the local cluster running in a container for Mac's:
DNS service does not run and is not supported Issue #132
Thanks,
Sudhanva.
-- Support will arrive soon.

Thanks @suhuruli! Glad to hear it is already being addressed.
@lawrencegripper I will close this for now but once support does come and if you see issues please let us know :)

No problem! Will update the doc as this gets addressed.


[NTR] Glutaminase deficiency

Preferred term label: Glutaminase deficiency
Synonyms
Definition (free text, please give PubMed ID, if applicable, in format PMID:#######) Glutaminase deficiency is characterized by refractory seizures, respiratory failure, brain abnormalities and death in the neonatal period, though milder cases with spastic ataxia-dysarthria have also been reported. This condition is caused by mutations in the glutaminase (GLS) gene.
Parent term (use OLS, or your favorite ontology browser) MONDO:0017352 disorder of glutamine metabolism
Children terms (if applicable) Should any existing terms that should be moved underneath this new proposed term? Yes.
MONDO:0034147 neonatal epileptic encephalopathy due to glutaminase deficiency
MONDO:0034146 spastic ataxia-dysarthria due to glutaminase deficiency
MONDO:0032678 developmental and epileptic encephalopathy, 71
Your nano-attribution (ORCID) https://orcid.org/0000-0002-7437-8060

3 asserted superclasses here.  Is there some potential for inferring at least one of them?


[Feature Request] Direct connection (non-proxy) mode

Similar to https://github.com/Rantanen/proxide#direct-connection-to-proxide , it would be convenient to have a direct connection mode, so that Mediator can be used even when we don't have a great control over client configurations / cumbersome to change them.

We are refactoring and improving the functions and documentation of mediator, please pay attention to our follow-up updates.
But maybe before refactoring I can also provide this functionality

Sounds great! Thanks for doing this project, (although we couldn't use Mediator due to this issue) it looks great and almost just what we need!

I have some question for it.

Do you own the ssl cert for your target host? If you want to use mediator with direct connect mode over SSL, you need provide the host cert.
Can you briefly describe how you would use mediator? I may be able to make some optimizations for your usage scenario.

Thanks for asking!
Let me describe our setup first

Production path

1. User web browser -> 2. Our Kubernetes ingress (SSL is terminated here.) -> 3. Envoy grpc-web proxy (that converts unencrypted grpc-web to unencrypted grpc) -> 4. NodeJS grpc server

Development path

There is no step 2, and step 3 handles SSL termination.

And we would like to put a gRPC proxy debugger between step 3 and 4 on the development path for debugging.
To answer your question:

SSL is already terminated so the gRPC proxy debugger only deals with unencrypted traffic.
We'll be using it for day-to-day debugging.  It's a complex website and gRPC-web is used heavily.

Useful features for us

Direct connection mode (this issue): Envoy configuration update is a pain, and we strongly prefer consistent prod / dev configurations to reduce unexpected outages.  With direct connection mode, we just have to change the port number.
Command line launch & configuration: All the steps in the development path are executed from a single make watch-dev script.  So we need to launch Mediator from a script with all the configurations.  In the case of Proxide, it was as simple as proxide monitor -l 5555 -t http://localhost:8081 and it worked well.
Easy install on commandline: We maintain a Mac/Linux dependency install script for all our devs, install[...].sh.  For example, proxide could be installed just with cargo install proxide so it was pretty convenient.  Even better, Nix package would be awesome since then that's just one line change in our flake.nix config, though it's not the end of the world without that.

Proxide checked most of the boxes, though critically, it didn't support proto Server reflection and the latest proto 3 spec, so we couldn't use that.  And Mediator UI looks a lot nicer :)


CSV separator at the end of the row

Description
Sometime we get CSVs that doesn't follow the proper csv format and we end up with csv that have a last column empty. Atoti can't read this csv because the last column (empty) doesn't have a name.

Context

Other information (if relevant)

As discussed this is not really the CSV standard so we don't plan to support it at the moment.
There are many ways to workaround that, one being using sed to remove the last character of each line:
sed 's/.$//' input.txt > output.txt

I am closing this issue at the moment but if anyone has the same use case feel free to comment


faraday-agent-dispatcher: 3.4.1 -> 3.4.2

Diff: https://github.com/infobyte/faraday_agent_dispatcher/compare/refs/tags/3.4.1...3.4.2
Changelog: https://github.com/infobyte/faraday_agent_dispatcher/releases/tag/3.4.2
Description of changes

Things done

Built on platform(s)

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

For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)

[ ] sandbox = relaxed
[ ] sandbox = true

[ ] Tested, as applicable:

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

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

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

[ ] Fits CONTRIBUTING.md.

Add a :+1: reaction to pull requests you find important.

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

2 packages built:

faraday-agent-dispatcher
faraday-agent-dispatcher.dist


Migrates to Slack API

@elisalimli Is this still in progress?

@elisalimli Is this still in progress?

Can be merged

@elisalimli How do I deploy this? Can you please update the README?

@homanp

@elisalimli How do I deploy this? Can you please update the README?

I have done already.


[1.3.0-RC1] Eviction behavior changed since 1.2.x

Already noted in https://github.com/sbt/sbt/issues/4706 but since it's such a big behavior change, here is a dedicated ticket for it.
build.sbt:
version := "0.1.0-SNAPSHOT"

scalaVersion := "2.9.1"

resolvers += "typesafe maven" at "https://repo.typesafe.com/typesafe/maven-releases/"

libraryDependencies ++= Seq(
  "com.codahale" % "jerkson_2.9.1" % "0.5.0",
  "org.codehaus.jackson" % "jackson-mapper-asl" % "1.9.10" // as another version of asl
)

Output of show externalDependencyClasspath in sbt 1.2.8:
[info] * Attributed(/home/johannes/.ivy2/cache/org.scala-lang/scala-library/jars/scala-library-2.9.1.jar)
[info] * Attributed(/home/johannes/.ivy2/cache/com.codahale/jerkson_2.9.1/jars/jerkson_2.9.1-0.5.0.jar)
[info] * Attributed(/home/johannes/.ivy2/cache/org.codehaus.jackson/jackson-core-asl/jars/jackson-core-asl-1.9.11.jar)
[info] * Attributed(/home/johannes/.ivy2/cache/org.codehaus.jackson/jackson-mapper-asl/jars/jackson-mapper-asl-1.9.11.jar)

Output of show externalDependencyClasspath in sbt 1.3.0-RC1 (note that the wrong version 1.9.10 of jackson is chosen):
[info] * Attributed(/home/johannes/.coursier/cache/v1/https/repo.typesafe.com/typesafe/maven-releases/com/codahale/jerkson_2.9.1/0.5.0/jerkson_2.9.1-0.5.0.jar)
[info] * Attributed(/home/johannes/.coursier/cache/v1/https/repo1.maven.org/maven2/org/scala-lang/scala-library/2.9.1/scala-library-2.9.1.jar)
[info] * Attributed(/home/johannes/.coursier/cache/v1/https/repo1.maven.org/maven2/org/codehaus/jackson/jackson-mapper-asl/1.9.10/jackson-mapper-asl-1.9.10.jar)
[info] * Attributed(/home/johannes/.coursier/cache/v1/https/repo1.maven.org/maven2/org/codehaus/jackson/jackson-core-asl/1.9.10/jackson-core-asl-1.9.10.jar)

Hmm after some investigation, the resolution in 1.3.0-RC1 seems more correct than the old one because jerkson defines a dependency on jackson with revision [1.9.0,2.0.0). It's unclear to me how version 1.9.11 came into the picture at all (maybe ivy chose the latest one based on contents of http://repo1.maven.org/maven2/org/codehaus/jackson/jackson-core-asl/ where timestamps seem to be missing for 1.9.12 and 1.9.13). Anyway it seems to be quite an edge case. Closing for now.

Yes. Dynamic revision (version range, SNAPSHOT, etc) on Ivy is broken since it tries to go out to Internet to grab the information rather than solve the reasonable candidate from the dependency graph.
Ref https://github.com/sbt/sbt/issues/2954 / https://github.com/sbt/sbt/pull/2959


more changes regarding "allow to enable basic auth by using KM_USERNAME and KM_PASSWORD as ENV VAR"

According the comments from our last PR (https://github.com/sheepkiller/kafka-manager-docker/pull/9)
We did the following small changes:

merge "km.sh" script to "start-kafka-manager.sh"
and make "start-kafka-manager.sh" as the entry point, all the auth logic are included in "start-kafka-manager.sh"

Hi Kevin,
Thank you!
I'm currently in vacation with limited connectivity, I'll review it as soon as I'm back.

sure, take ur time and enjoy holiday.

Hi @kevinleeTCA,
thanks for your PR!

@sheepkiller   no problems


Wrong behaviors when having less items than the grid size

Hello,
Here is a StackBlitz : https://stackblitz.com/edit/ngu-carousel-ng6-dgas5v
You can see that the myCarousel.isLast is not set to true, and there is some weird behaviors when you resize the window (so the grid change). For exemple if you go to xs grid, go to slide 3, and resize the windows to md grid, you're stuck.
Thank you for your work :-)

@adrienlamotte thanks for reporting will check and fix, but it is not a show stopper.


Should support filename longer than 260 characters

Well, I can see that it is a limitation from Microsoft Windows.
But MSDN suggests that this limitation may be removed.
Enable Long Paths in Windows 10, Version 1607, and Later
And there are cases we have to use long paths (when handling some really complicated 3rd-party projects).
Maybe ninja could only raise a warning, but do not stop the build, like cmake does?

Duplicate of #1514.

#1514 was removed by GitHub because the user who created was banned or something. No idea why they won't simply remove his posts only ...
Anyway, I will reopen this one then. #1514 can still be accessed via the GitHub API: https://api.github.com/repos/ninja-build/ninja/issues/1514/comments

https://docs.microsoft.com/en-us/windows/win32/fileio/maximum-file-path-limitation

https://docs.microsoft.com/en-us/windows/win32/fileio/maximum-file-path-limitation

Hi @jhasse,
From the page you linked, the user needs to edit the registry to enable long path support, and also the application needs to declare it in its own manifest (pasted from that page):
<application xmlns="urn:schemas-microsoft-com:asm.v3">
    <windowsSettings xmlns:ws2="http://schemas.microsoft.com/SMI/2016/WindowsSettings">
        <ws2:longPathAware>true</ws2:longPathAware>
    </windowsSettings>
</application>

Presumably adding this to ninja.manifest should work? Or how would this impact compatibility with old Windows?
Thanks.

Oh https://github.com/ninja-build/ninja/pull/1939 already does that actually.

So, what are the next steps for this issue?

RealDiskInterFace uses posix file functions like fopen, and also the *A versions of win32 calls, while the long paths page says only *W versions are affected. Another option might be to prepend \\?\, but this only works for absolute paths.

I made a PR: https://github.com/ninja-build/ninja/pull/2289

Hi @parbo
FYI: It seems that the Windows Universal C CRT only calls CreateFileW. It performs internally a codepage\utf-8 conversion to a wchar_t before calling CreateFileW:
C:\Program Files (x86)\Windows Kits\10\Source\10.0.22621.0\ucrt\lowio\open.cpp (method _sopen_nolock at line 833 for example)

Hmm, why didn't it work with fopen then? Maybe the longPathsAware manifest
doesn't extend through to linked libraries/dll:s?
On Fri, Apr 21, 2023, 10:26 Victor Derks @.***> wrote:

Hi @parbo https://github.com/parbo
FYI: It seems that the Windows Universal C CRT only calls CreateFileW. It
performs internally a codepage\utf-8 conversion to a wchar_t before calling
CreateFileW:
C:\Program Files (x86)\Windows
Kits\10\Source\10.0.22621.0\ucrt\lowio\open.cpp (method _sopen_nolock at
line 833 for example)
—
Reply to this email directly, view it on GitHub
https://github.com/ninja-build/ninja/issues/1900#issuecomment-1517466416,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AA52CQ7SL6436E4ZQDQI67LXCJACXANCNFSM4VDY46VA
.
You are receiving this because you were mentioned.Message ID:
@.***>

@parbo. I am assuming that the longPathsAware manifest option applies to the .exe and is enabled process wide at startup or not. I didn't do a debug session in Ninja, just a debug-trace of a local app that uses fopen on Windows 11.

Maybe only some of the *A functions needed replacing, and not the fopen
et al.
On Fri, Apr 21, 2023, 16:16 Victor Derks @.***> wrote:

@parbo https://github.com/parbo. I am assuming that the longPathsAware
manifest option applies to the .exe and is enabled process wide at startup
or not. I didn't do a debug session in Ninja, just a debug-trace of a local
app that uses fopen on Windows 11.
—
Reply to this email directly, view it on GitHub
https://github.com/ninja-build/ninja/issues/1900#issuecomment-1517904009,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AA52CQ36XK7XM3Q4M5GONNDXCKJE7ANCNFSM4VDY46VA
.
You are receiving this because you were mentioned.Message ID:
@.***>

How is this still an issue? It's looking like my only choice is to switch my workstation over to Linux to be able to build our Android app with the new RN architecture. This shouldn't be a problem.

I can confirm the above comment as well. Even though I configured Windows to allow long paths, Ninja is failing to build a React Native/Expo app with the New Architecture.

How is this still an issue?

How is this still an issue?

True. But isn't it time to move on, and merge a solution?

With #2321 and other PRs now merged, it seems to be fixed! We're just missing an official release, unfortunately.
Here's the workaround I used to compile a RN New Architecture app on Windows:

Download the latest build artifact of Ninja (I used this one) and put it in C:\ninja\ninja.exe.
Go to android/app/build.gradle inside of your RN project and add this bit of code inside of android.defaultConfig:

externalNativeBuild {
    cmake {
        arguments "-DCMAKE_MAKE_PROGRAM=C:\\ninja\\ninja.exe", "-DCMAKE_OBJECT_PATH_MAX=1024"
    }
}

To explain why this is needed:
Even if you've added C:\ninja to your path, Gradle still uses ninja from the built-in CMake from the Android SDK. Of course, it doesn't strictly need to be in C:\ninja, but chances are that most people have it there already. With just the first argument, it should probably compile already. However, CMake is still warning us about potentially broken builds because the path is too long, so we set it to 1024 to fix that with the second argument.
Lastly, if you want to make this more "contributor-friendly", you can run something like where ninja in your build.gradle, instead of having a hardcoded path like this. Just make sure to check the version beforehand :)

@Sculas
I can confirm this works! Thank you!
I reinstalled Windows before trying this and assumed Windows 11 had long paths enabled by default. It doesn't, which is unfortunate. For anyone coming here due to this issue, make sure to do that first.

So, what's the plan for migrating Windows API calls from ANSI to Unicode style?

Why latest release of ninja according to github was in 2022?

@XantreGodlike Because the lastest release of ninja was in 2022.

You're using MinGW, @Sculas was referring to the artifact from GitHub Actions which builds with MSVC. Can you try that instead? Maybe it makes a difference because of the UCRT.

The above built artifact link has expired. But I tried the latest built from the master (ninja-build-artifact), I no longer see the ninja error due long path however my build still fails, Now this could be the MinGW that might be causing it to fail now.
Thanks for the quick response :)

The above built artifact link has expired. But I tried the latest built from the master (ninja-build-artifact), I no longer see the ninja error due long path however my build still fails, Now this could be the MinGW that might be causing it to fail now. Thanks for the quick response :)

Just go to https://github.com/ninja-build/ninja/releases to get latest release

With #2321 and other PRs now merged, it seems to be fixed! We're just missing an official release, unfortunately. Here's the workaround I used to compile a RN New Architecture app on Windows:

Enable Long Paths first! Instructions to do that here.
Download the latest build artifact of Ninja here and put it in C:\ninja\ninja.exe.
Go to android/app/build.gradle inside of your RN project and add this bit of code inside of android.defaultConfig:

externalNativeBuild {
    cmake {
        arguments "-DCMAKE_MAKE_PROGRAM=C:\\ninja\\ninja.exe", "-DCMAKE_OBJECT_PATH_MAX=1024"
    }
}

To explain why this is needed: Even if you've added C:\ninja to your path, Gradle still uses ninja from the built-in CMake from the Android SDK. Of course, it doesn't strictly need to be in C:\ninja, but chances are that most people have it there already. With just the first argument, it should probably compile already. However, CMake is still warning us about potentially broken builds because the path is too long, so we set it to 1024 to fix that with the second argument.
Lastly, if you want to make this more "contributor-friendly", you can run something like where ninja in your build.gradle, instead of having a hardcoded path like this. Just make sure to check the version beforehand :)
edit 21/03/2024: replaced expired artifact link with a link to the latest workflow runs

The artifact link doesn't link to anywhere to download anything, so I assume you mean the latest version 1.11.1?
I have an RN project and a library (react-native-vision-camera) is giving me this error. I enabled long paths and tried your method by adding the code to my build.gradle and also to the camera's build.gradle, none worked. So maybe it's the ninja.exe that I was using?
The only thing that worked was rename my project path from F:/Projects/<project-name>/<dir1>/<dir2>/<dir3> to F:/p/r/m/a/c, which is ridiculous. It's so sad that in 2024, we still can't deal with long paths.

There seem to be some issues left (only MinGW build? Without setting the registry value it should still not work?), but some are fixed. I will close this PR, please create new issues with specific failures that you see with 1.12.0 and in which circumstances they occur.

The artifact link doesn't link to anywhere to download anything, so I assume you mean the latest version 1.11.1?

No, it was a master build with some changes not in 1.11.1. Please try 1.12.0 again.

ninjia 1.12.1 still has not been solved "Filename longer than 260 characters Error" on windows( even Enablelongpath). So a temporary way is to shorten the file name(directory name). For python -m pip install, Temporarily "uuid.uuid4().hex[:8]" at "pip/_internal/req/req_install.py", and after install package, recovery to default.
May be risky, temporary way, wait for ninja to update to new version.

Can you provide exact reproduction steps so we can verify that ourselves (and verify the Ninja version being used too)?

Clone https://github.com/SidneyLann/rn75.git to a long path dir
cd to android
yarn
yarn android
should have error: Filename longer than 260 characters Error

ninjia 1.10.2 still has not been solved "Filename longer than 260 characters Error" on windows( even Enablelongpath).

You're running Ninja 1.10.2, correct? This issue has been fixed in v1.12.0 (get the latest version here).
Make sure you actually have long paths enabled in Windows as well, as this obviously doesn't work without that.
@SidneyLann Next time though, please read the issue comments before you post your own comment saying a version from 4 years ago doesn't work. Numerous fixes have been posted here already, and it was even closed with a "fixed in 1.12.0" comment.
Lastly, it seems your reproducer project is missing the React Native workaround specified here: https://github.com/ninja-build/ninja/issues/1900#issuecomment-1817532728
The Android SDK includes an old version of Ninja, which it uses by default unless you use that workaround (see comment for info).
(@carrot93 make sure you've done this as well if your project is also React Native!)


Make "match" optional

I did not expect the match option to be required - would expect the default behaviour to be to match all files and a regexp filter is only for more advanced scenarios (since I am checking file extensions in my handler anyway).
Additionally, omitting the match parameter produced an unexpected error, since the following code does not work as you expect:
if (!(options.root || options.match || options.transform)) {
throw new Error('options.{root,match,transform} must be defined');
}
Instead I got this error:
TypeError: Cannot read property 'test' of undefined
at C:\Users\Pete\Documents\newsuk\test\node_modules\connect-static-transform\lib\staticTransform.js:59:23

I'll accept a pull request if you want to write it up.


Update to Swift 5 (WIP)

This also prepares for a new release: 0.6.0.

@louoso I'm running into some issues w/ the tests. This is one example:
    func testFloatLabelElement() {
        let app = XCUIApplication()
        let elementsQuery = app.scrollViews.otherElements
        let floatLabelTextField = elementsQuery.textFields["floatLabel"]

        floatLabelTextField.tap()
        app.typeText("Hello World")
        app.alerts.buttons["Dismiss"].tap()
    }

The issue is that the alert shows after the "H" from "Hello World" is typed and then the simulator hangs because it's still trying to type "Hello World" but the text field is no longer the first responder. There are a few ways I could fix the tests:

Only type a single character instead of "Hello World".
Debounce value changes for some amount of time so that "Hello World" can be completely typed out before the alert is shown.
Only call the value change observer once the text field ends editing.

I don't know what the original behavior was, but I'm guessing 1 is the way to go. It seems like the right approach and would also be an easy fix. I'm guessing 2 & 3 would be breaking changes.


Review JReleaser config to publish artifacts directly to Maven Central

[INFO]  Deploying Maven artifacts
[INFO]    [maven] Deploying all staged artifacts
[INFO]      [nexus2] Deploying to maven-central
[INFO]      [nexus2] nexus2 set to FULL_DEPLOYMENT
[INFO]      [nexus2] Verifying prerequisites
[INFO]      [nexus2] Verifying POMs
[INFO]      [nexus2] Signing key B910CB1FBC31D758 expires at 2027-12-01T14:23:28
[INFO]      [nexus2] Checking if key B910CB1FBC31D758 has been published
[INFO]      [nexus2] Key B910CB1FBC31D758 was found as published
[INFO]      [sign] build/staging-deploy/io/github/wfouche/tulip/tulip-runtime/2.0.1-dev/tulip-runtime-2.0.1-dev-sources.jar
[INFO]      [sign] build/staging-deploy/io/github/wfouche/tulip/tulip-runtime/2.0.1-dev/tulip-runtime-2.0.1-dev.module
[INFO]      [sign] build/staging-deploy/io/github/wfouche/tulip/tulip-runtime/2.0.1-dev/tulip-runtime-2.0.1-dev.jar
[INFO]      [sign] build/staging-deploy/io/github/wfouche/tulip/tulip-runtime/2.0.1-dev/tulip-runtime-2.0.1-dev-javadoc.jar
[INFO]      [sign] build/staging-deploy/io/github/wfouche/tulip/tulip-runtime/2.0.1-dev/tulip-runtime-2.0.1-dev.pom
[INFO]      [nexus2] Lookup staging profile for io.github.wfouche.tulip
[WARN]      [nexus2] Could not find a staging profile matching io.github.wfouche.tulip

https://dev.to/tschuehly/how-to-publish-a-kotlinjava-spring-boot-library-with-gradle-to-maven-central-complete-guide-402a


Form Recognizer Track2 api

Some pending issues

[ ] the verb: extract or analyze?

I am going to add another doc with scenarios and sample code.

Closing this.  Will have a new PR for api review.


feat: add visionOS support

Summary
Add support for visionOS
Change log

edited podspec files

Test plan

[x] Packages should work on visionOS

Thanks for the contribution.


kube-aws: do go generate in build script

lgtm. May want to eventually move this into an "internal" package as suggested by @ericchiang


using ajax to add element

if i dynamically add element into menu,they will lose function,how to solve this? thx a lot

same problem after using filter on angular, when i delete the text on the input, the elements reappear but menu stop working.

find about line 250 in the code and compare this function with the original
 function Plugin(option) {
    return this.each(function() {
      var $this = $(this);
      var data = $this.data('mm');
      var options = $.extend({},
        MetisMenu.DEFAULTS,
        $this.data(),
        typeof option === 'object' && option
      );

      if (!data) {
        $this.data('mm', (data = new MetisMenu(this, options)));
      } else {
        $this.data('mm').init();
      }
      if (typeof option === 'string') {
        data[option]();
      }
    });
  }

You notice I added the else statement
    if (!data) {
        $this.data('mm', (data = new MetisMenu(this, options)));
      } else {
        $this.data('mm').init();
      }

This allows metisMenu to be dynamic.
@onokumus can this be added to master? It seems to work for me well

@onokumus it works here too

@sferoze this works for me. Thanks

@onokumus this else statement is really working fine, can it be included in a next release?
It would be like this though:
                        if (!data) {
                            data = new MetisMenu(this, _config);
                            $this.data(DATA_KEY, data);
                        } else {
                            data.init();
                        }

None of the two options mentioned above work for me, any clue?

Hi,
I'm having the same problem with an Angular2 app and none of these options work for me.
Is there any solution ?

Just updated from 2.2.0 to 2.7.0 and the new fix for enabling metis menu to re-initialize with new data is the one that @SuricateCan mentioned.
@onokumus any reason this hasn't been added as functionality to Metis Menu? It's been a long time since this thread has been open and it seems like adding elements dynamically to the menu is a pretty standard thing to do. Any concern with the fix mentioned by @SuricateCan ?

Just updated from 2.2.0 to 2.7.0 and the new fix for enabling metis menu to re-initialize with new data is the one that @SuricateCan mentioned.
@onokumus any reason this hasn't been added as functionality to Metis Menu? It's been a long time since this thread has been open and it seems like adding elements dynamically to the menu is a pretty standard thing to do. Any concern with the fix mentioned by @SuricateCan ?

Has this problem been fixed, I really need to load the menu dynamically


DS-177: add new brand colors

Jira
https://pegadigitalit.atlassian.net/browse/DS-177
Summary
Adds secondary and tertiary brand colors to the color system.
Details

Added wine, berry, pink, and violet to the color map.
Removed xdark and xlight shades from orange and yellow.
Generated CSS custom props for all colors.
Updated color docs and added color shade toggle.

How to test
Run the branch locally and check the color docs under Visual Styles. Create a dummy page and try out the new CSS custom props.
Release notes
Deprecated functions

bolt-color(orange, xdark)
bolt-color(orange, xlight)
bolt-color(yellow, xdark)
bolt-color(yellow, xlight)

@danielamorse Let's merge this one after we merge https://github.com/boltdesignsystem/bolt/pull/1957.


Docs: Add Haystack integration details

vLLM has an integration with Haystack: https://haystack.deepset.ai/integrations/vllm.
This PR aims to update the documentation with the details of that integration.

Hi @bilgeyucel, I believe because vLLM supports OpenAI protocol, you don't need this special integration? Please correct me if i'm wrong. Thank you for your contribution.

Hi @simon-mo, thank you for your reply! I'm not sure if I understand your question correctly. Let me try to explain my take: Haystack is an open source Python framework for building custom LLM applications. The addition of vLLM introduces the capability to deploy self-hosted LLMs for using Haystack pipelines, making it a valuable integration. With this PR, I wanted to showcase this integration in vLLM's documentation
Let me know if anything is not clear or if you have any questions

Ah sorry for the confusion. My point is that because vLLM offers OpenAI compatible API, and Haystack must have a connector directly be able to talk to OpenAI. Is the vLLM special connector necessary? It adds maintenance cost for you all.

You have a fair point 👍  The upcoming Haystack 2.0 version (in the beta phase now) has a connector for OpenAI compatible API but vLLM is the only option for Haystack 1.0 users that we'll support till the end of 2024. The idea is quite similar to this one -> https://github.com/vllm-project/vllm/blob/main/docs/source/serving/serving_with_langchain.rst


Exclude transitive jackson dependencies

zjsonpatch adds older jackson dependencies than the ones that are already being added by wiremock itself.

Not sure what purpose this serves, given that WireMock declares its own (up to date) versions of these dependencies?

Hmmm....this isn't the first time Maven Enforcer has been mentioned. It seems a bit over-weening to me, given that Maven will also upgrade the dependency, but I guess if it's a common problem it's worth appealing to it.


Integration Test - Release - 2022/01/28 03:30:00

Auto create for integration test. IssueCommandFlow

#pri1

Just type '#pri3'

#pri2

#pri3

#assign PRMergerTest1

#assign NonAllowedUser

The following users don't have valid GitHub IDs, or are not collaborators on this repo: nonalloweduser

#reassign PRMergerTest2

#reassign NonAllowedUser

#please-close

The following users don't have valid GitHub IDs, or are not collaborators on this repo: nonalloweduser

GitHub user PRMergerTest2 has been removed from the MicrosoftDocs organization, so they were automatically removed as an assignee.

#unassign PRMergerTest1

#unassign NonAllowedUser


Datepicker causes routing

This is a (multiple allowed):

[x] bug

[ ] enhancement

[ ] feature-discussion (RFC)

Framework7 Version: 1.6.0

Platform and Target: PhoneGap with Aurelia

I'm using Aurelia's router instead of Framework7's. When I click the 'Done' button it navigates to /# and it messes up with my routes. I fixed it in my code using this line inside the onOpen event handler:
calendar.container.find('.button.close-picker').removeAttr('href');
Though I think it's better if the href wasn't there in the first place...
EDIT:
Well, just found out it happens also when changing months using the picker. Changed my solution to:
calendar.container.find('a').removeAttr('href');
b.t.w - thanks, it's a great framework!

Great that you found the solution for your issue.
However, it is usually best to use F7 router instead or others.


Send in $destination into Adapter

So it knows when the destination has been cleared, and can clear its own state.

I like this idea but I also have another suggestion for dealing with navigations that may be useful:
1. Start by creating protocols for navigation actions
(This could be a file named Navigations or something like that, just as you did for the Destinations enum
import DomainModels

public protocol DetailsNavigation {
    func navigateToCountryDetails(country: Country)
}

public protocol AboutThisAppNavigation {
    func navigateToAboutThisApp()
}

2. Make the app's navigator conform to the protocols
extension TravelAdvisoriesNavHost: DetailsNavigation, AboutThisAppNavigation {

    public func navigateToCountryDetails(country: Country) {
        self.destination = Destinations.details(regionCode: country.regionCode)
    }

    public func navigateToAboutThisApp() {
        self.destination = Destinations.aboutThisApp
    }
}

3. Update CountryListAdapter init to receive an entity that conforms to these protocols
(It's worth creating a type alias to improve readability when there are multiple protocols)

// Adding new navigations would be as flexible as adding more protocols to this list
public typealias CountryListNavigation = DetailsNavigation & AboutThisAppNavigation

public struct CountryListAdapter: View {

    private let navigator: CountryListNavigation

    public init(navigator: CountryListNavigation) {
        self.navigator = navigator
    }

4. Invoke the navigations from within CountryListAdapter
    public var body: some View {
        CountryListPage(listUiState: viewModel.state, onItemTapped: { country in
            viewModel.onCountrySelected(country: country)
        }, onButtonTapped: {
            viewModel.onButtonTapped()
        }, onFailOtherTapped: {
            viewModel.onFailOtherTapped()
        })
        .onReceive(viewModel.$navigationDestination, perform: { country in
            guard let country = country else { return }

            self.navigator.navigateToCountryDetails(country: country) // <----- Here

            viewModel.navigationDestination = nil
        })
        .pss_notify(item: $viewModel.error, alertBuilder: {
            $0.asFloatingAlert(viewModel: viewModel) {
                navigator.navigateToAboutThisApp()                   // <----- And here
            }
        })
    }

Pros

Easy to append new navigations for an existing screen
It's possible to reuse existing code (for example: one could navigate from Details screen to About this app screen by reusing the AboutThisAppNavigation protocol
All the screens that will handle navigation events don't have to know the existence of Destination. Indeed, this enum could live strictly within TravelAdvisoriesNavHost

Cons

The class responsible for dealing with the navigation tends to grow exponentially depending on the amount of user interactions
Since TravelAdvisoriesNavHost is a View, it gets weird writing tests to it. (Maybe moving all this routing logic to a separate entity may be an alternative :shrug:)

Context
This is how we are currently handling navigations at Farfetch, and so far the app is scaling pretty well.
There's a short video about it here: https://www.youtube.com/watch?v=Y3hQ6Z_wW9k
Sorry for being nosy and also for the long comment but I found it interesting that this routing strategy seems to fit well on this app 😃


chore: remove unused workflow

#64  👈
main

This stack of pull requests is managed by Graphite. Learn more about stacking.

Join @keeganpotgieter and the rest of your teammates on  Graphite


example code to connect to redis in Kubernetes setup

In my Kubernetes setup, REDIS pods get created as following..
`
crdb-crdb-redisio-sentinel-0                    1/1     Running                 0          39d    <IP_ADDRESS>   samt-worker-02
crdb-crdb-redisio-sentinel-1                    1/1     Running                 0          54d    <IP_ADDRESS>   samt-worker-03
crdb-crdb-redisio-sentinel-2                    1/1     Running                 0          39d    <IP_ADDRESS>   samt-worker-01
crdb-crdb-redisio-server-0                      3/3     Running                 0          54d    <IP_ADDRESS>   samt-worker-03
crdb-crdb-redisio-server-1                      3/3     Running                 0          39d    <IP_ADDRESS>   samt-worker-01
crdb-crdb-redisio-server-2                      3/3     Running                 0          39d    <IP_ADDRESS>
samt-worker-02
`
So 1 master and few slaves
Output of "kubectl get svc" is like:
`
crdb-crdb-redisio                      ClusterIP   <IP_ADDRESS>            6379/TCP                                                                                54d    app=crdb-crdb-redisio,crdb-dbtype=redisio,csf-component=crdb,csf-subcomponent=redisio,heritage=Tiller,redisio_role=master,release=crdb,type=server
crdb-crdb-redisio-readonly             ClusterIP   <IP_ADDRESS>           6379/TCP                                                                                54d    app=crdb-crdb-redisio,crdb-dbtype=redisio,csf-component=crdb,csf-subcomponent=redisio,heritage=Tiller,redisio_role=slave,release=crdb,type=server
`
Expected behavior
I want to connect to both master-slave via Raddison client
Actual behavior
I'm not sure how though because there are like following ways!
config.useClusterServers().
config.useSingleServer().
config.useMasterSlaveServers()
Steps to reproduce or test case
Redis version
not sure
Redisson version
3.3.0
Redisson configuration
This is what i am confused with
Could you please provide a sample code on how best to connect to Redis with master slave configuration?
master could become slave and vice versa so how dynamically Raddision would take care of this switch?
IPs of service needs to be configured or IPs of pods?

Hi,
In your case as you have sentinels you should use sentinel connection mode.

master could become slave and vice versa so how dynamically Raddision would take care of this switch?

Yes.

IPs of service needs to be configured or IPs of pods?

IPs

Thanks for Quick response
So you mean this one
https://static.javadoc.io/org.redisson/redisson/3.4.1/org/redisson/config/SentinelServersConfig.html#SentinelServersConfig--
I see a method
https://static.javadoc.io/org.redisson/redisson/3.4.1/org/redisson/config/SentinelServersConfig.html#addSentinelAddress-java.lang.String...-
What I should be adding here..!??
Regards
Sam
On Mon, 23 Sep 2019 at 10:47 PM, Nikita Koksharov<EMAIL_ADDRESS>wrote:

Hi,
In your case as you have sentinels you should use sentinel connection mode.
master could become slave and vice versa so how dynamically Raddision
would take care of this switch?
Yes.
IPs of service needs to be configured or IPs of pods?
IPs
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/redisson/redisson/issues/2336?email_source=notifications&email_token=ADEXAT5Q7JNQQYAAMAL5FWTQLD2ZZA5CNFSM4IZNLR6KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD7LTDVQ#issuecomment-534196694,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ADEXATYIYMBNT2KSJOIOZDTQLD2ZZANCNFSM4IZNLR6A
.

What I should be adding here..!??

crdb-crdb-redisio-sentinel-0, crdb-crdb-redisio-sentinel-1 ... hosts

redis://crdb-crdb-redisio-sentinel-0:6379
redis://crdb-crdb-redisio-sentinel-1:6379
redis://crdb-crdb-redisio-sentinel-2:6379
Like this...!?
And that's I as client need not to worry about internal switching among
master/ spave?
Connection pooling..?
Load balance..?
Fail over etc...?
On Mon, 23 Sep 2019 at 11:27 PM, Nikita Koksharov<EMAIL_ADDRESS>wrote:poo

What I should be adding here..!??
crdb-crdb-redisio-sentinel-0, crdb-crdb-redisio-sentinel-1 ... hosts
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/redisson/redisson/issues/2336?email_source=notifications&email_token=ADEXATZV7HHZICGMZ7PE3NDQLD7RLA5CNFSM4IZNLR6KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD7LXBXI#issuecomment-534212829,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ADEXATZVRBH7NX254XSGGYDQLD7RLANCNFSM4IZNLR6A
.

Like this...!?

Yes.

And that's I as client need not to worry about internal switching among
master/ spave?
Connection pooling..?
Load balance..?
Fail over etc...?

No, it's all done by Redisson.

Thanks,
Here pasting output of "kubectl get svc -o wide"
crdb-crdb-redisio-sentinel             ClusterIP   <IP_ADDRESS>
        26379/TCP
54d
app=crdb-crdb-redisio,crdb-dbtype=redisio,csf-component=crdb,csf-subcomponent=redisio,heritage=Tiller,release=crdb,type=sentinel
I don't think we can add multiple *sentinels the way you suggested, because
what if more *sentinels get added / deleted then how would it reflect on
my client app dynamically?
so looks like we need to add k8 service name rather than pod(s)
So can i use like below?
Config config = new Config();
config.useSentinelServers().addSentinelAddress("redis://" +
"crdb-crdb-redisio-sentinel:"+"26379");
}
this.redisson = Redisson.create(config);
Regards,
Sameer
On Tue, Sep 24, 2019 at 11:19 AM Nikita Koksharov<EMAIL_ADDRESS>wrote:

Like this...!?
Yes.
And that's I as client need not to worry about internal switching among
master/ spave?
Connection pooling..?
Load balance..?
Fail over etc...?
No, it's all done by Redisson.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/redisson/redisson/issues/2336?email_source=notifications&email_token=ADEXAT47DJHMMMVKH3GXTMTQLGTAJA5CNFSM4IZNLR6KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD7NEWJI#issuecomment-534399781,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ADEXAT2PR4GXYEANUT7ZJOLQLGTAJANCNFSM4IZNLR6A
.

Could you please share a sample which is using redis along with sentinels in k8s cluster..!?

I don't think we can add multiple *sentinels the way you suggested, because
what if more *sentinels get added / deleted then how would it reflect on
my client app dynamically?

You need to define at least one working sentinel at the moment of application startup. Redisson will get remain list of sentinels and will keep them updated.

I have asked this question earlier, mentioning again, can i use kubernetes
SERVICE NAME of redis sentinel ?
Here pasting output of "kubectl get svc -o wide"
crdb-crdb-redisio-sentinel             ClusterIP   <IP_ADDRESS>
26379/TCP
54d
app=crdb-crdb-redisio,crdb-dbtype=redisio,xxx-component=crdb,xxx-subcomponent=redisio,heritage=Tiller,release=crdb,type=sentinel
Config config = new Config();
config.useSentinelServers().addSentinelAddress("redis://" +
"crdb-crdb-redisio-sentinel:"+"26379");this.redisson =
Redisson.create(config);
Because, in k8 setup IP of pod could get modified and we don't expose IPs
externally !
On Tue, Sep 24, 2019 at 1:55 PM Nikita Koksharov<EMAIL_ADDRESS>wrote:

I don't think we can add multiple *sentinels the way you suggested, because
what if more *
sentinels get added / deleted then how would it reflect on my client app
dynamically?
You need to define at least one working sentinel at the moment of
application startup. Redisson will get remain list of sentinels and will
keep them updated.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/redisson/redisson/issues/2336?email_source=notifications&email_token=ADEXAT5L4RMGIULLAHC6JKTQLHFJDA5CNFSM4IZNLR6KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD7NRCTA#issuecomment-534450508,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ADEXAT7BLHBJGUAFCXZKTKLQLHFJDANCNFSM4IZNLR6A
.

I used this code:
Config config = new Config();
config.useSingleServer().setAddress("redis://crdb-crdb-redisio:6379");
RedissonClient redisson = Redisson.create(config);
and from K8s setup:
[root@samt-control-01 AAA]# kubectl get svc crdb-crdb-redisio
NAME                TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)    AGE
crdb-crdb-redisio   ClusterIP   <IP_ADDRESS>           6379/TCP   6h21m
It connected to redis successfully
I need to know what you think about this solution?
Or you think, i should rather use some other API here?
Regards,
Sameer
On Tue, Sep 24, 2019 at 2:19 PM Nikita Koksharov<EMAIL_ADDRESS>wrote:

Anyway Redis use IPs in configuration and not k8 servce names. I'm afraid
that won't work
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/redisson/redisson/issues/2336?email_source=notifications&email_token=ADEXAT7PPI7DWMAAGJANDALQLHIC5A5CNFSM4IZNLR6KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD7NTLAQ#issuecomment-534459778,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ADEXAT6FUVKEJTHHCEUCK5LQLHIC5ANCNFSM4IZNLR6A
.

If kubernetes handles properly dns resolving then it should work


Add auto loader helper

My knowledge of composer and related workflows is limited. Can you explain how this change helps developers use the traditional server PHP code?


webhook EOF errors

/area API
/area test-and-release
/kind bug
Expected Behavior
When we run our e2e tests with chaos there are no failures due to the webhook shutting down.
Actual Behavior
We intermittently see failures like this: Post https://eventing-webhook.knative-eventing-qh1fjbnng8.svc:443/resource-conversion?timeout=30s: EOF ever since we enabled webhook chaos.

cc @vaikas

I already made two changed to try and mitigate this:

Bumped the terminationGracePeriodSecond in our webhook pods to 300 to give the webhook itself greater control over the drain duration.
Bumped the network.DefaultDrainTimeout: https://github.com/knative/pkg/pull/1501 to give the API Server more time to observe the endpoints change.

From the Go http.Server Shutdown documentation:

When Shutdown is called, Serve, ListenAndServe, and ListenAndServeTLS immediately return ErrServerClosed. Make sure the program doesn't exit and waits instead for Shutdown to return.

I wondered if this might be our problem, but we call ListenAndServeTLS here: https://github.com/knative/pkg/blob/f1b82401dc8a5951d6034be93a3a2423556a3104/webhook/webhook.go#L207-L210 and seem to properly check for ErrServerClosed

I started a thread in #sig-api-machinery here: https://kubernetes.slack.com/archives/C0EG7JC6T/p1594910493127400

Alright, so one of the things I have been wondering is around Keep-Alives and whether that might be a reason the API server takes so long to realize an endpoint is no longer good.  I noticed the following comment on Go's SetKeepAlivesEnabled:

SetKeepAlivesEnabled controls whether HTTP keep-alives are enabled. By default, keep-alives are always enabled. Only very resource-constrained environments or servers in the process of shutting down should disable them.

... emphasis mine.
Now it turns out that Go's http logic is already smart about disabling keep-alive when it is shutting down:
func (s *Server) doKeepAlives() bool {
	return atomic.LoadInt32(&s.disableKeepAlives) == 0 && !s.shuttingDown()
}

However, when we lame duck we aren't yet .shuttingDown() so I believe keep-alives will continue throughout our network.DefaultDrainTimeout until Shutdown() is actually called.
I believe testing this should be as simple as calling server.SetKeepAlivesEnabled(false) here: https://github.com/knative/pkg/blob/25f2aa6443803868e6562dca5e57626f2309302d/webhook/webhook.go#L221
However, if this works then we should probably consider doing something similar across our various dataplane components as well.  cc @tcnghia

We believe that @vaikas is still seeing some webhook failures that should be synced past the above change, so we aren't out of the woods yet.

The new "Drainer" handler in the linked PR uses a dynamic drain timeout where it waits for at least network.DefaultDrainTimeout after the last request before terminating the webhook.  With that constant set to 45s, let's see if there are any failures...  🤞

One of the two flakes in eventing yesterday was this:
TestChannelDataPlaneSuccess/InMemoryChannel-messaging.knative.dev/v1/full-event_encoding_binary_version_1.0: creation.go:108: Failed to create subscription "full-event-binary-10-sub": Internal error occurred: failed calling webhook "webhook.eventing.knative.dev": Post https://eventing-webhook.knative-eventing-sfqaktzdqa.svc:443/defaulting?timeout=2s: EOF

I need to track down whether that CI run had the drainer stuff in yet.

Hmm looks like it was at 239f7fc, which includes the drainer.

Tomorrow I'm going to add a workaround for this by using Retry loops, just like we do for when pod creates (or configmaps fail) with very specific error cases. This will be a workaround for now hopefully so that we'll be able to not get tests that fail if they hit this condition. Reconcilers should be resilient to this, but tests that use create*orFail will not, so this will at least cut down some noise. I'll make sure to log these so at least we see how often this happens.

Still happening in serving too I believe: https://prow.knative.dev/view/gcs/knative-prow/logs/ci-knative-serving-continuous/1285454712115564545

It definitely is.  Open to suggestions on how we might keep chipping away at this / instrument / debug / ...

I had an idea chatting with @markusthoemmes a bit on slack.
Right now there's a lot of machinery standing between us and the EOFs that it is making them harder to debug than they should be.  The thought is: can we have a more dedicated probing process that we can use to reproduce this (maybe more consistently)?

I think we should work on getting a small reproducer of this. Create a small webhook, create a ton requests and churn through them quickly or something.

So I created a tiny little Go binary that uses vegeta to load the Serving resource-validation webhook, and found something interesting that may be related.
If I have vegeta send 1 request every 20ms for 3 minutes, then everything completes successfully, and there's an average latency of 18ms (typically).  This remains true even when run under chaos.
If I have vegeta send 1 request every 10ms for 3 minutes, then latency climbs (pretty quickly), and there's an average latency of ~17.5s seconds (the peak is >30s).  I have been playing with values to try and push this latency ever higher to try and trigger an upstream EOF, but haven't managed to yet.
Here's the simple little load-generator:
package main

import (
	"bytes"
	"encoding/json"
	"log"
	"net/http"
	"time"

	vegeta "github.com/tsenart/vegeta/lib"
	admissionv1 "k8s.io/api/admission/v1"
	corev1 "k8s.io/api/core/v1"
	metav1 "k8s.io/apimachinery/pkg/apis/meta/v1"
	"k8s.io/apimachinery/pkg/runtime"
	"knative.dev/pkg/ptr"
	v1 "knative.dev/serving/pkg/apis/serving/v1"
)

func main() {
	ksvc := &v1.Service{
		TypeMeta: metav1.TypeMeta{
			APIVersion: "serving.knative.dev/v1",
			Kind:       "Service",
		},
		ObjectMeta: metav1.ObjectMeta{
			Namespace: "default",
			Name:      "no-matter",
		},
		Spec: v1.ServiceSpec{
			ConfigurationSpec: v1.ConfigurationSpec{
				Template: v1.RevisionTemplateSpec{
					Spec: v1.RevisionSpec{
						PodSpec: corev1.PodSpec{
							Containers: []corev1.Container{{
								Image: "busybox",
							}},
						},
					},
				},
			},
			RouteSpec: v1.RouteSpec{
				Traffic: []v1.TrafficTarget{{
					LatestRevision: ptr.Bool(true),
					Percent:        ptr.Int64(100),
				}},
			},
		},
	}

	gvk := v1.SchemeGroupVersion.WithKind("Service")
	review := admissionv1.AdmissionReview{
		Request: &admissionv1.AdmissionRequest{
			Operation: admissionv1.Create,
			Kind: metav1.GroupVersionKind{
				Group:   gvk.Group,
				Version: gvk.Version,
				Kind:    gvk.Kind,
			},
			Resource: metav1.GroupVersionResource{
				Group:    gvk.Group,
				Version:  gvk.Version,
				Resource: "services",
			},
			Object: runtime.RawExtension{
				Object: ksvc,
			},
		},
	}

	body := new(bytes.Buffer)
	if err := json.NewEncoder(body).Encode(&review); err != nil {
		log.Fatalf("Error serializing admission request: %v", err)
	}

	rate := vegeta.Rate{Freq: 1, Per: 10 * time.Millisecond} // 10 fails, 20 succeeds.
	targeter := vegeta.NewStaticTargeter(vegeta.Target{
		Method: http.MethodPost,
		URL:    "https://webhook.knative-serving.svc.cluster.local/resource-validation",
		Body:   body.Bytes(),
		Header: http.Header{
			"Content-Type": []string{"application/json"},
		},
	})
	// Responses should be fast, but we set a high timeout to see
	// if we can provoke a server-side termination.
	attacker := vegeta.NewAttacker(vegeta.Timeout(3*time.Minute), vegeta.KeepAlive(false))

	log.Print("Starting the attack.")
	success, error := 0, 0
	var totalLatency time.Duration
	for result := range attacker.Attack(targeter, rate, 3*time.Minute, "webhook-probe") {
		if result.Code != http.StatusOK {
			log.Printf("FAILURE[%v: %d: %s] %s", result.Timestamp, result.Code, result.Error, string(result.Body))
			error++
		} else {
			totalLatency += result.Latency
			log.Printf("SUCCESS[%v] %v", result.Timestamp, result.Latency)
			success++
		}
	}
	avgLatency := (totalLatency.Milliseconds() / int64(success))

	if error > 0 {
		log.Fatalf("Completed with %d/%d errors (average latency: %dms).", error, error+success, avgLatency)
	} else {
		log.Printf("Completed %d requests without errors (average latency: %dms).", success, avgLatency)
	}
}

Here's the simply job.yaml to launch it:
apiVersion: batch/v1
kind: Job
metadata:
  name: webhook-prober
  namespace: default
spec:
  parallelism: 1
  backoffLimit: 0
  template:
    metadata:
      labels:
        app: webhook-prober
    spec:
      containers:
      - name: webhook-prober
        # Point me to where the above is saved!
        image: ko://knative.dev/serving/test/test_images/webhook-prober
        resources:
          requests:
            cpu: 100m
      restartPolicy: Never

cc @vagababov @dprotaso

Interestingly without chaos I see a higher average/max latency (28s / 59s respectively), probably in part because the pod shutdown is graceful and we briefly get an additional pod of capacity 🤔

/assign
I'll look next week to see what it is.

At 1 request per 5ms for 10 minutes:
2020/07/26 17:39:02 FAILURE[2020-07-26 17:38:55.523011525 +0000 UTC m=+59.225520149: 0: Post "https://webhook.knative-serving.svc.cluster.local/resource-validation": EOF]

Not sure if this is what we're seeing, but it's the best lead I've seen 😅

That's with chaos running btw.
Also cc @tcnghia as he was chasing webhook timeouts at one point, and this finding is related 😉

Operation: admissionv1.Create,

FYI - this triggers PodSpec dry-run which is enabled by default in serving

Do you see timeouts?
2020/07/29 03:30:25 FAILURE[2020-07-29 03:29:54.078907339 +0000 UTC m=+168.179666060: 0: Post "https://webhook.knative-serving.svc.cluster.local/resource-validation": dial tcp <IP_ADDRESS>:0-><IP_ADDRESS>:443: connect: connection timed out]

Some data from me

PodSpec dry-run disabled

2020/07/29 03:30:25 Completed with 2832/36000 errors (average latency: 11433ms).

PodSpec dry-run enabled
2020/07/29 03:20:16 Completed with 29582/36000 errors (average latency: 87396ms)
2020/07/29 03:09:51 Completed with 28229/36000 errors (average latency: 78468ms).

I bumped the webhook memory to 1Gi and allocated 1 CPU (1000m). I also disabled readiness/liveness probes since failures there would cause restarts

The profile I had mostly shows usage in TLS client, so I guess that is in line with what you see.
May be we need to cache those connections

To avoid timeouts completely I needed to bump my CPU limit even higher - memory was flat

The result:
2020/07/29 13:09:41 Completed 36000 requests without errors (average latency: 12ms).
Turning on PodSpec dry-run resulted in memory climbing and eventually the webhook getting an OOMKilled error. Then I started to see EOF's for the first time

2m23s       Warning   OOMKilling   node/gke-dave-knative-default-pool-0f1da796-39vh   Memory cgroup out of memory: Kill process 1340269 (webhook) score 1997 or sacrifice child
Killed process 1340269 (webhook) total-vm:1717176kB, anon-rss:1020068kB, file-rss:30936kB, shmem-rss:0kB
54s         Warning   OOMKilling   node/gke-dave-knative-default-pool-0f1da796-39vh   Memory cgroup out of memory: Kill process 1353620 (webhook) score 1997 or sacrifice child
Killed process 1353620 (webhook) total-vm:1717176kB, anon-rss:1020264kB, file-rss:30040kB, shmem-rss:0kB

I don't think this explains eventing's use case though - I'll change the runner to do conversions

It doesn't explain Serving's either, does it? We'd see errors without the chaos otherwise too I'd think.

I was referring to eventing not performing PodSpec dry-runs

We'd see errors without the chaos otherwise too I'd think.

What do you mean?
I'm actually just testing with a single webhook instance.

So I replaced prober to probe routes rather than services
Completed 18000 requests without errors (average latency: 12ms).
Probing service
Completed 6000 requests without errors (average latency: 28112ms).
With last requests taking about 58s to complete.
I am getting more and more convinced that it is the dry run validation client ratelimiting.
/cc @whaught

If dry-run is implicated but not well understood, we should move the feature to Disabled. With Beta features the standard should be to roll-back first and ask questions later.

Logging time it takes to call:
err = c.client.Post().Namespace(c.ns).Resource("pods").VersionedParams(&opts, scheme.ParameterCodec).Body(pod).Do().Into(result)
it definitely shows linear growth that the time to make the call takes.
Route, not requiring this call, is pretty consistently constant at even higher loads.

The other thing is that 100QPS requires  CPU~600m (56X top shows) even for simple requests.

If dry-run is implicated but not well understood, we should move the feature to Disabled. With Beta features the standard should be to roll-back first and ask questions later.

As an additional point, since this is behind a feature flag, it should be very easy to flip the flag to disabled and see if it changes the shape of the curve and either confirm or rule out the feature as a culprit. (The culprit still could be in the scaffolding code.)

While this seems like an issue in itself, I'm still not seeing how it's related to the chaos duck, unless the maximum latency surpasses 300s, which is the time the webhook is allowed to take before harshly killed. The drain time shouldn't matter as that's only a timer to wait for accepting new connections. Existing connections should be just fine and handled by the Shutdown call :thinking:.
That's also what I was referring to above @dprotaso. My main question is: Why is this a problem under chaos but not in a system without chaos?

It might not be related to chaosduck per se. But with this out we can re-try chaos duck.

webhook timeout's have happened in serving prior to chaos and we bumped the request limits https://github.com/knative/serving/pull/8048
I think the eventing webhook is even more under-provisioned. I'll make a PR

To clarify I don't disagree with

Why is this a problem under chaos but not in a system without chaos?

I have under load.

Have we seen EOF flakes in serving

Yes, which is why we disabled the chaosduck on the webhook.

While this seems like an issue in itself, I'm still not seeing how it's related to the chaos duck, unless the maximum latency surpasses 300s, which is the time the webhook is allowed to take before harshly killed

Hmm, you are right.  I was attempting to drive the latency up to 45s (network.DefaultDrainTimeout), but for my theory to have held water it should have taken until 300s and the queued calls should have drained gracefully via the shutdown...  🤔

I've got a few runs where I see the EOF in eventing here: https://github.com/knative/eventing/pull/3758 if anyone cares to take a look.
I didn't see anything in the webhook logs that would suggest why the EOF happened. It'd be nice to have API server logs

I'll poke at manually hitting the eventing webhook

running things manually - eventing webhook seems to falls over due to liveness/readiness probes latency (similar to serving)
when I disabled those it ran fine - this is with the limits raised to 500m & 500Mi

2020/08/05 00:46:58 Completed 18000 requests without errors (average latency: 10842ms).

/lifecycle frozen

/unassign @vagababov

/unassign @vagababov

Interestingly one way to reproduce this consistently is to panic in the webhook when handling a request (ie. the defaulting logic)
golang's http server recovers these panics and logs an error.
We should potentially recover ourselves so we can return an 'internal server' type error

As part of https://github.com/knative/serving/issues/11225 I encountered EOF's/context deadline exceeded. After adding some tracing I've seen our web hooks respond <10ms but then the API server still returns a timeout.
So I don't think this is isolated to just our web hooks.


[$500]  IOU - Back button brings user to infinite-loading page after deleting request with message

If you haven’t already, check out our contributing guidelines for onboarding and email<EMAIL_ADDRESS>to request to join our Slack channel!

Version Number: 1.4.22-0
Reproducible in staging?: Y
Reproducible in production?: N
If this was caught during regression testing, add the test name, ID and link from TestRail:
Email or phone of affected tester (no customers):
Logs: https://stackoverflow.com/c/expensify/questions/4856
Expensify/Expensify Issue URL:
Issue reported by: Applause - Internal Team
Slack conversation:
Action Performed:

Go to 1:1 DM
Create a manual request
Go to details page
Change the amount
Delete the request
Tap back button on the top left corner
Tap back button again

Expected Result:
In Step 6, user is redirected to LHN
Actual Result:
In Step 6, user is redirected to a page which loads infinitely.
When tapping back button again (Step 7), user is still redirected to the same infinitely loading page
Workaround:
Unknown
Platforms:

Which of our officially supported platforms is this issue occurring on?

[x] Android: Native
[x] Android: mWeb Chrome
[x] iOS: Native
[x] iOS: mWeb Safari
[x] MacOS: Chrome / Safari
[x] MacOS: Desktop

Screenshots/Videos
Add any screenshot/video evidence

https://github.com/Expensify/App/assets/78819774/cfe05055-955f-410b-8c02-ad297f4e47a9
View all open jobs on GitHub
Upwork Automation - Do Not Edit

Upwork Job URL: https://www.upwork.com/jobs/~01c79b49baf6c222ef
Upwork Job ID:<PHONE_NUMBER>366109696
Last Price Increase: 2024-01-05

This doesn't seem to be an issue on the latest main branch. Only staging. It is fixed by #32543 (merged into main yesterday). This line change in particular is responsible:
From:
https://github.com/Expensify/App/blob/d569d3284c3cc1f2d62dc68d7678e7812144dc82/src/libs/actions/IOU.js#L2361
To:
https://github.com/Expensify/App/blob/0c351a4534f0bfb8278f2fa9b8c0a10187b6c8bb/src/libs/actions/IOU.js#L2440
Could someone else please double check and if confirmed should we close the issue?

Could someone else please double check and if confirmed should we close the issue?

I followed the steps to reproduce, if you do it slowly, giving time to receive the 'responses', it is not possible to reproduce, but if you do all the 'steps' quickly, without giving time to receive the 'responses', we have an error. @codebycarlos can you test and confirm for me please? Thanks.

Couldn't reproduce on staging and production.

Reproducible on v1.4.22-2
https://github.com/Expensify/App/assets/78819774/0e0ecf2b-0415-4898-8b3a-5aa53ed3771f

I'm not able to replicate this on v1.4.23-1
Web
https://github.com/Expensify/App/assets/91962855/027cce7e-5ed9-484a-b1e2-62c596ca9878
Android
https://github.com/Expensify/App/assets/91962855/b2b056fc-9a8f-4dfc-8e02-3c8ebdc2c61a

I also can't reproduce, closing!


Custom theme context injection

Duplicates

[X] I have searched the existing issues

Latest version

[X] I have tested the latest version

Summary 💡
Summary
We are currently trying to upgrade from v4 to v5, however we are running into an issue where our internal theme (we have a custom palette and typography options etc. that are contextual) is getting overridden by the MUI theme as they are sharing the same underlying theme context.
Proposed Solution
It would be great if there was a way to inject our own custom context into MUI's <ThemeProvider /> so that we can have two different distinct themes, one "primary" theme that we can access in the styled-component callback, and one specifically for MUI.
Other Considerations

Do you feel that this is an antipattern? I feel like MUI is designed so that all theming is done within the MUI theme and adheres to the MUI structure
Have you got any other suggestions for how we may be able to accomplish the above? The other thoughts we've had currently are:

to use some sort of "internal" nesting within the MUI theme that contains all of our styles one level down
to access our internal theme explicitly, or via a custom context provider instead of using the styled-components callback while we transition.

Examples 🌈
No response
Motivation 🔦
This has come about because we only use MUI for a small slice of our app (rather than holistically). As such the theme we use for MUI is just a subset of our main theme.

@wgolledge Have you considered having multiple (nested) ThemeProviders in your app: https://mui.com/material-ui/customization/theming/#nesting-the-theme

we only use MUI for a small slice of our app (rather than holistically)

Maybe you could put an outer ThemeProvider around the entire app with your custom (outer) theme, and put an inner nested ThemeProvider around the pages/routes that use Material UI with the default theme

Thanks for the suggestion, we have considered that but (currently, at least) the code isn't split cleanly enough to have MUI sections vs non-MUI sections

Hi @siriwatknp, thanks a lot for the suggestion and snippet! That looks like exactly what we need, I'm very glad to hear that support for this has been introduced.

Hi @siriwatknp, thanks a lot for the suggestion and snippet! That looks like exactly what we need, I'm very glad to hear that support for this has been introduced.

Please let me know if it works for you, we would like to put it in our migration docs. Thanks a lot!

@siriwatknp

why can't I find the THEME_ID?

OK......  I need to upgrade my mui to 5.12.5. ....... I got too many errors and warnings.

I'm closing this issue.


Feature Request: Add TOML support for extra tabs

In GitLab by @mclemente on Dec 30, 2023, 22:00
Add support for extra tabs with (at least) support for an expansible list that can be customized to have input fields.
Main features that could make use of that: Masks Sheets module's Influence tab and Roots module's Tracks (the whole PbtA Track feature is in need of a rework).

In GitLab by @mclemente on Jan 26, 2024, 16:21
mentioned in task #98


Paged optimizer resuming from checkpoint - attributeError: 'int' object has no attribute 'cpu'

System Info
Platform: Linux-<IP_ADDRESS>-2.cm2-x86_64-with-glibc2.35
Python version: 3.10.14
Bitsandbytes version: 0.43.1
Safetensors version: 0.4.5
Accelerate version: 0.34.2
Accelerate config: not found
PyTorch version (GPU?): 2.4.0+cu124 (True)
Tensorflow version (GPU?): 2.16.2 (True)
Flax version (CPU?/GPU?/TPU?): not installed (NA)
Jax version: not installed
JaxLib version: not installed
Using distributed or parallel set-up in script?: yes
Using GPU in script?: yes
GPU type: NVIDIA A100-SXM4-80GB
Reproduction
from trl import SFTConfig, SFTTrainer
import json
from datasets import load_dataset
import transformers
import torch

dataset = load_dataset("openai/gsm8k", "main", split="train")
model_id = "meta-llama/Meta-Llama-3-8B-Instruct"

training_args = SFTConfig(
    dataset_text_field="question",
    per_device_train_batch_size=1,
    eval_steps=4,
    output_dir="tmp1",
    save_steps=4,
    max_steps=4,
    bf16=True,
    fsdp="full_shard auto_wrap",
    optim="paged_adamw_32bit"
)

model = transformers.AutoModelForCausalLM.from_pretrained(model_id, torch_dtype=torch.bfloat16)

trainer = SFTTrainer(model=model, train_dataset=dataset, args=training_args)
trainer.train()

# resume from checkpoint for another 4 steps
training_args = SFTConfig(
    dataset_text_field="question",
    per_device_train_batch_size=1,
    eval_steps=4,
    output_dir="tmp1",
    save_steps=4,
    max_steps=8,
    bf16=True,
    fsdp="full_shard auto_wrap",
    optim="paged_adamw_32bit"
)
model = transformers.AutoModelForCausalLM.from_pretrained(model_id, torch_dtype=torch.bfloat16)
trainer = SFTTrainer(model=model, train_dataset=dataset, args=training_args)
trainer.train(resume_from_checkpoint=True)

Expected behavior
Script works fine, ie. training can resume from checkpoint.
Currently, I get the error: AttributeError: 'int' object has no attribute 'cpu'

@matthewdouglas Would really appreciate any tips here TIA!


fix(deps): update nest monorepo to v10 (major)

This PR contains the following updates:

Package
Type
Update
Change
Pending

@nestjs/common (source)
dependencies
major
^9.1.4 -> ^10.0.0
10.0.3 (+2)

@nestjs/core (source)
dependencies
major
^9.1.4 -> ^10.0.0
10.0.3 (+2)

@nestjs/platform-express (source)
dependencies
major
^9.1.4 -> ^10.0.0
10.0.3 (+2)

@nestjs/schematics
devDependencies
major
^9.0.3 -> ^10.0.0

@nestjs/testing (source)
devDependencies
major
^9.1.4 -> ^10.0.0
10.0.3 (+2)

Release Notes

nestjs/nest
v10.0.0
Compare Source
v10.0.0 (2023-06-15)
Article: TBC
Migration guide: https://docs.nestjs.com/migration-guide
⚠  Node v12 is no longer supported (>= v16 is required).
Bug fixes

core

#11785 fix(core): apply middleware to versioned controllers (ctrl-level) (@kamilmysliwiec)
#11650 fix(core): global prefix exclude when versioning is turned on (@kamilmysliwiec)

platform-fastify

#11718 fix(fastify): validate middleware paths (@kamilmysliwiec)

microservices

#10549 fix(microservices): allow falsy values in options (@Papooch)

Enhancements

platform-express

#11667 feat(express): add support for multer.none (@mathewtrivett)

common, core, websockets

#10545 feat: create method on client to get websocket pattern (@jmcdo29)

common

#11673 fix(common): loosen http exception cause type (@namoscato)
#10953 fix(common)!: when transforming optional boolean parameters on ValidationPipe (@micalevisk)

core

#9809 feat(core): middleware runs once for matching route (@rychardvale)
#11118 feat(core): add support to named groups (@elplancton)
#11142 feat: Support async local storage in interceptors (@nordfjord)

common, core

#10533 feat(core/common): Add @Search decorator to the available HTTP route handlers (@Gustrb)

microservices

#10359 feat(microservices): enable wildcards in redis microservice patterns (@tijsmoree)

common, platform-express, platform-fastify

#10630 feat(common)!: narrow getInstance return type for http adapters (@micalevisk)

Dependencies

Other

#11793 chore(deps-dev): bump mongoose from 7.2.4 to 7.3.0 (@dependabot[bot])
#11792 chore(deps-dev): bump cache-manager from 5.2.2 to 5.2.3 (@dependabot[bot])
#11794 chore(deps-dev): bump ts-morph from 18.0.0 to 19.0.0 (@dependabot[bot])
#11790 chore(deps): update node.js to v19.9 (@renovate[bot])
#11787 chore(deps): update node.js to v18.16 - autoclosed (@renovate[bot])
#11788 chore(deps): update jest monorepo to v29 (major) (@renovate[bot])
#11786 chore(deps): update node.js to v16.20 (@renovate[bot])
#11784 chore(deps): update dependency jest to v28.1.3 (@renovate[bot])
#11783 fix(deps): update graphql-tools monorepo (major) (@renovate[bot])
#11782 fix(deps): update dependency ts-morph to v18 - autoclosed (@renovate[bot])
#11757 chore(deps): update dependency @types/node to v18.16.18 (@renovate[bot])
#11780 fix(deps): update dependency mongoose to v7 (@renovate[bot])
#11775 fix(deps): update dependency @nestjs/mercurius to v11 (@renovate[bot])
#11761 fix(deps): update dependency rxjs to v7.8.1 (@renovate[bot])
#11779 fix(deps): update dependency mongodb to v5 (@renovate[bot])
#11777 fix(deps): update dependency cache-manager to v5 (@renovate[bot])
#11776 fix(deps): update dependency @socket.io/redis-adapter to v8 (@renovate[bot])
#11772 chore(deps): update dependency webpack-cli to v5 (@renovate[bot])
#11768 chore(deps-dev): bump @fastify/multipart from 7.6.0 to 7.6.1 (@dependabot[bot])
#11764 fix(deps): update prisma monorepo to v4.15.0 (@renovate[bot])
#11778 fix(deps): update dependency mercurius to v13 (@renovate[bot])
#11774 fix(deps): update dependency @nestjs/graphql to v11.0.6 (@renovate[bot])
#11773 chore(deps): update jest monorepo to v29 (major) (@renovate[bot])
#11771 chore(deps): update dependency typescript to v5 (@renovate[bot])
#11740 chore(deps): update dependency ts-loader to v9.4.3 (@renovate[bot])
#11762 fix(deps): update dependency sequelize to v6.32.0 (@renovate[bot])
#11763 fix(deps): update nest monorepo (@renovate[bot])
#11746 chore(deps-dev): bump eslint from 7.32.0 to 8.42.0 (@dependabot[bot])
#11747 chore(deps-dev): bump mongoose from 7.2.2 to 7.2.4 (@dependabot[bot])
#11758 fix(deps): update dependency mysql2 to v3.3.5 (@renovate[bot])
#11759 chore(deps): update jest monorepo (@renovate[bot])
#11519 chore(deps): update jest monorepo (@renovate[bot])
#11742 chore(deps): bump dottie from 2.0.2 to 2.0.4 in /sample/07-sequelize (@dependabot[bot])
#11743 chore(deps-dev): bump sinon from 15.1.0 to 15.1.2 (@dependabot[bot])
#11745 chore(deps-dev): bump @apollo/server from 4.7.1 to 4.7.3 (@dependabot[bot])
#11756 chore(deps-dev): bump @types/node from 20.2.5 to 20.3.1 (@dependabot[bot])
#11755 fix(deps): update dependency mongoose to v6.11.2 (@renovate[bot])
#11754 fix(deps): update dependency mongodb to v3.7.3 (@renovate[bot])
#11753 fix(deps): update dependency dotenv to v16.1.4 (@renovate[bot])
#11752 fix(deps): update dependency @nestjs/event-emitter to v1.4.2 (@renovate[bot])
#11748 fix(deps): update apollo graphql packages (@renovate[bot])
#11750 chore(deps): update dependency ts-node to v10.9.1 (@renovate[bot])
#11749 chore(deps): update dependency supertest to v6.3.3 (@renovate[bot])
#11751 chore(deps): update typescript-eslint monorepo to v5.59.11 (@renovate[bot])
#11741 chore(deps): update dependency webpack to v5.86.0 (@renovate[bot])
#11516 chore(deps): update dependency @types/node to v18.16.17 (@renovate[bot])
#11738 chore(deps): update dependency prettier to v2.8.8 (@renovate[bot])
#11739 chore(deps): update dependency ts-jest to v29.1.0 (@renovate[bot])
#11524 fix(deps): update dependency @nestjs/mercurius to v10.2.1 (@renovate[bot])
#11736 chore(deps): update dependency eslint-config-prettier to v8.8.0 (@renovate[bot])
#11723 fix(deps): update apollo graphql packages (@renovate[bot])
#11734 chore(deps): update confluentinc/cp-zookeeper docker tag to v7.4.0 (@renovate[bot])
#11737 chore(deps): update dependency eslint-plugin-import to v2.27.5 (@renovate[bot])
#11732 chore(deps): update babel monorepo to v7.22.5 (@renovate[bot])
#11731 fix(deps): update dependency typeorm to v0.3.16 (@renovate[bot])
#11735 chore(deps): update dependency @nestjs/cli to v9.5.0 (@renovate[bot])
#11730 fix(deps): update dependency socket.io to v4.6.2 (@renovate[bot])
#11733 chore(deps): update confluentinc/cp-kafka docker tag to v7.4.0 (@renovate[bot])
#11724 fix(deps): update dependency @fastify/static to v6.10.2 (@renovate[bot])
#11727 fix(deps): update dependency @nestjs/schedule to v2.2.3 (@renovate[bot])
#11729 fix(deps): update dependency graphql-tools to v8.3.20 (@renovate[bot])
#11728 fix(deps): update dependency @nestjs/sequelize to v9.0.2 (@renovate[bot])
#11726 fix(deps): update dependency @nestjs/apollo to v11.0.6 (@renovate[bot])
#11725 fix(deps): update dependency @grpc/grpc-js to v1.8.15 (@renovate[bot])
#11722 chore(deps): update mysql docker tag to v8.0.33 (@renovate[bot])
#11721 chore(deps): update dependency redis to v4.6.7 (@renovate[bot])
#11720 chore(deps): update dependency @types/express to v4.17.17 (@renovate[bot])
#11695 chore(deps-dev): bump typescript from 5.0.4 to 5.1.3 (@dependabot[bot])

platform-fastify

#11716 chore(deps): bump light-my-request from 5.9.1 to 5.10.0 (@dependabot[bot])

Committers: 17

Antonio Tripodi (@Tony133)
Autofix (@autofix-bot)
Denis Frenademetz (@skrtheboss)
Einar Norðfjörð (@nordfjord)
Jay McDoniel (@jmcdo29)
Kamil Mysliwiec (@kamilmysliwiec)
Mathew Trivett (@mathewtrivett)
Maurer Krisztian (@MaurerKrisztian)
Micael Levi L. Cavalcante (@micalevisk)
Nick Amoscato (@namoscato)
Ondřej Švanda (@Papooch)
Pooyan Khanjankhani (@TheKhanj)
Rychard Valle (@rychardvale)
Tijs Moree (@tijsmoree)
@Gustrb
@elplancton
@mohamadrezamomeni

nestjs/schematics
v10.0.1
Compare Source

chore: upgrade application schematic deps (53b37c4)

v10.0.0
Compare Source

Merge pull request #1451 from nestjs/dependabot/npm_and_yarn/copy-props-2.0.5 (b2fcc64)
chore: bump version numbers (868ebb5)
build(deps): bump copy-props from 2.0.4 to 2.0.5 (85bbae8)
Merge pull request #1449 from nestjs/10.0.0 (d922114)
ci: ignore post install scripts (24b557d)
chore: laying the grounds for v10.0.0 (3389327)
Merge branch 'yigitkurtcu-fix-json-comment-parsing' into 10.0.0 (470d44b)
chore: resolve conflicts (b634d3f)
Merge pull request #1447 from micalevisk/fix/issue-1444 (96efd13)
Merge pull request #1448 from nestjs/renovate/angular-cli-monorepo (2a3c6cd)
fix(deps): update angular-cli monorepo to v16.1.0 (672efbb)
test(utils): add unit test to cover declaration of non existing metadata (f187e0f)
fix(utils): when updating a non-existing nestjs module (04e8376)
chore(deps): update dependency @types/node to v18.16.18 (79ba067)
chore(deps): update typescript-eslint monorepo to v5.59.11 (b1a008a)
chore(deps): update dependency @types/node to v18.16.17 (c0c381e)
Merge pull request #1428 from nestjs/renovate/angular-cli-monorepo (e4d2c54)
chore(deps): update babel monorepo to v7.22.5 (2059b50)
fix(deps): update angular-cli monorepo to v16.0.5 (8cb994c)
chore(deps): update typescript-eslint monorepo to v5.59.9 (394b6ae)
chore(deps): update dependency release-it to v15.11.0 (070c9f0)
chore(deps): update dependency eslint to v8.42.0 (29b1640)
chore(deps): update dependency release-it to v15.10.5 (5b9f41b)
chore(deps): update dependency typescript to v5.1.3 (b9b9355)
chore(deps): update dependency @types/jest to v29.5.2 (42ee6a3)
chore(deps): update commitlint monorepo to v17.6.5 (bb10b39)
chore(deps): update typescript-eslint monorepo to v5.59.8 (b46ac5d)
chore(deps): update babel monorepo to v7.22.4 (d411bd0)
chore(deps): update babel monorepo to v7.22.3 (597030a)
chore(deps): update dependency @types/node to v18.16.16 (7e69507)
chore(deps): update babel monorepo (baf7568)
fix: package-lock (150d414)
fix: package-lock.json (5ff1ab9)
fix: dev dependencies (fd7d958)
chore(deps): update dependency @types/node to v18.16.15 (eeffc81)
fix: conflict fixed (16f62e1)
chore(deps): update typescript-eslint monorepo to v5.59.7 (13d4e78)
Update package.json (cc4c009)
chore(deps): update dependency @types/node to v18.16.14 (c5c07e7)
fix(parsing): json parsing fixed for commented json files (8ef1604)
chore(deps): update dependency eslint to v8.41.0 (fc3878d)
Merge pull request #1399 from nestjs/renovate/angular-cli-monorepo (0e6f0e3)
chore(deps): update dependency @types/node to v18.16.13 (f9dedd7)
fix(deps): update angular-cli monorepo to v16.0.2 (b235b00)

Configuration
📅 Schedule: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined).
🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.
♻ Rebasing: Whenever PR is behind base branch, or you tick the rebase/retry checkbox.
🔕 Ignore: Close this PR and you won't be reminded about these updates again.

[ ] If you want to rebase/retry this PR, check this box

This PR has been generated by Renovate Bot.

Thanks for the PR!
Any successful deployments (not always required) will be available below.
Backend available
Once merged, code will be promoted and handed off to following workflow run.
Main Merge Workflow

⚠ Artifact update problem
Renovate failed to update an artifact related to this branch. You probably do not want to merge this PR as-is.
♻ Renovate will retry this branch, including artifacts, only when one of the following happens:

any of the package files in this branch needs updating, or
the branch becomes conflicted, or
you click the rebase/retry checkbox if found above, or
you rename this PR's title to start with "rebase!" to trigger it manually

The artifact failure details are included below:
File name: backend/package-lock.json
npm ERR! code ERESOLVE
npm ERR! ERESOLVE could not resolve
npm ERR!
npm ERR! While resolving<EMAIL_ADDRESS>npm ERR! Found<EMAIL_ADDRESS>npm ERR! node_modules/@nestjs/common
npm ERR<EMAIL_ADDRESS>from the root project
npm ERR!   peer<EMAIL_ADDRESS>from<EMAIL_ADDRESS>npm ERR!   node_modules/@nestjs/core
npm ERR<EMAIL_ADDRESS>from the root project
npm ERR!     peer<EMAIL_ADDRESS>from<EMAIL_ADDRESS>npm ERR!     node_modules/@nestjs/platform-express
npm ERR<EMAIL_ADDRESS>from the root project
npm ERR!       2 more (@nestjs/core, @nestjs/testing)
npm ERR!     1 more (@nestjs/testing)
npm ERR!   2 more (@nestjs/platform-express, @nestjs/testing)
npm ERR!
npm ERR! Could not resolve dependency:
npm ERR! peer<EMAIL_ADDRESS>|| ^8.0.0 || ^9.0.0" from<EMAIL_ADDRESS>npm ERR! node_modules/@nestjs/axios
npm ERR<EMAIL_ADDRESS>from the root project
npm ERR!
npm ERR! Conflicting peer dependency<EMAIL_ADDRESS>npm ERR! node_modules/@nestjs/common
npm ERR!   peer<EMAIL_ADDRESS>|| ^8.0.0 || ^9.0.0" from<EMAIL_ADDRESS>npm ERR!   node_modules/@nestjs/axios
npm ERR<EMAIL_ADDRESS>from the root project
npm ERR!
npm ERR! Fix the upstream dependency conflict, or retry
npm ERR! this command with --force or --legacy-peer-deps
npm ERR! to accept an incorrect (and potentially broken) dependency resolution.
npm ERR!
npm ERR!
npm ERR! For a full report see:
npm ERR! /tmp/renovate/cache/others/npm/_logs/2023-06-22T11_21_59_423Z-eresolve-report.txt

npm ERR! A complete log of this run can be found in: /tmp/renovate/cache/others/npm/_logs/2023-06-22T11_21_59_423Z-debug-0.log

Edited/Blocked Notification
Renovate will not automatically rebase this PR, because it does not recognize the last commit author and assumes somebody else may have edited the PR.
You can manually request rebase by checking the rebase/retry box above.
⚠ Warning: custom changes will be lost.


New package Corel.MindManager v 23.1.243

Checklist for Pull Requests

[X] Have you signed the Contributor License Agreement?
[ ] Is there a linked Issue?

Manifests

[X] Have you checked that there aren't other open pull requests for the same manifest update/change?
[X] This PR only modifies one (1) manifest
[ ] Have you validated your manifest locally with winget validate --manifest <path>?
[ ] Have you tested your manifest locally with winget install --manifest <path>?
[X] Does your manifest conform to the 1.6 schema?

Note: <path> is the name of the directory containing the manifest you're submitting.

This is another try of the old PR https://github.com/microsoft/winget-pkgs/pull/138829 where only the PackageDependencies failed.
There is a newer version 23.2.209 available, but only for the MSI installer, not the exe installer yet.
Microsoft Reviewers: Open in CodeFlow

Automatic Validation ended with:

No errors to post.

(Automated response - build 878.)

Manual Validation ended with:

8:26:20 AM:  finished with exit code: -1978334960 8:26:20 AM:
2024-05-01 08:26:20.181 [CLI ] ShellExecute installer failed: 3010

Automated error analysis suggests 3010 may mean Install successful but system restart may be required.
(Automated response - build 880.)

Automatic Validation ended with:

2024-05-02 07:09:02.988 [REPO] Failed to open available source: msstore
2024-05-02 07:09:07.974 [REPO] Failed to open available source: msstore
2024-05-02 07:09:11.469 [REPO] Failed to open available source: msstore
2024-05-02 07:09:22.374 [REPO] Failed to open available source: msstore
2024-05-02 07:09:23.909 [CLI ] No suitable installer found for manifest Microsoft.DotNet.Framework.DeveloperPack_4 with version 4.8.1

(Automated response - build 880.)


Chrome 59 on Windows crashes - both 32 and 64 bit

I'm submitting a ...  (check one with "x")
[x ] bug report => search github for a similar issue or PR before submitting
[ ] feature request
[ ] support request => Please do not submit support request here

Current behavior
Chrome 59.0.3071.109 32 bit and 64 bit version - crashes loading the demo page.
Reproduction of the problem
Go on the demo page https://swimlane.github.io/ngx-charts-dag/ with chrome 59 and it will crash
Please tell us about your environment:
It happens both with 32 and 64 bit versions.

It seems to be somehow linked to the animations, on my project it only crashes after editing the graph, the animations are not triggered when the graph is first shown and it displays correctly.

Chrome 60.0.3112.78 (64 bit) - the same problem.

Same with Opera 47. It was working with Opera 45.

Should be fixed now....  please reopen if you still see this on the demo page.

What was the issue? Is it fixed with a new version?

I believe it was a bad build and deploy.  The latest version bumped the devDeps and redepolyed... There were no functional changes.


does repeat number equal consensus length/period?

Hi,
i found that in the output tsv there isn't a field about the exact repeat number, so i assume that this could be calculated as (end-start+1)/period, is that right? In case where indel happens, is there a more precise way to calculate? Thanks for your help.

Using --json will allow you to see how many insertions/deletions occurred, and so you can then calculate the repeat number as (end - start + deletions - insertions) / period. That's not a very nice user experience, and ULTRA should definitely allow users to have easy access to repeat count.
I'll update ULTRA to output repeat counts later this week. I'll comment here to let you know when its done -- thanks for opening an issue!

It took longer than I would have liked to have time for this update, but it is now in place on the main branch. Using "-c" will result in a the following columns in TSV format: #copies, #substitutions, #insertions, and #deletions.
Using -c with --json format will also yield copy count, substitutions, insertions, and deletions (additionally, substitutions, insertions, and deletions are now hidden by default when using --json).
Thank you once again for your feedback, let me know if anything else comes up!


model_internal functions generation error

model_internal functions are not generated as expected:
model_internal::initialize(); in AS file is mapped to
main.mtest.model_internal.org.apache.royale.utils.Language.closure(this.http_$$www_adobe_com$2008$flex$model$internal__initialize, this, 'http://www.adobe.com/2008/flex/model/internal::initialize')();
in js file
Please find the related files : https://drive.google.com/open?id=1KxcXxCAlhjH0OmyIZmwgidVrW0aybYiZ

Hi Alex,
I prepared sample project. Please find : https://drive.google.com/open?id=1jc0H1cf-Z2WJjeQy8Cy3rOuphrGjiNoL
You have to set to env vars for local to build the project :
CLOSURE_HOME
ROYALE_DIST_HOME
Thanks,
Serkan.

In your test case, the source code reads:
	model_internal function initialize() : void
	{
		model_internal::propagateEvents;
		model_internal::propagateEvents;
	}

I don't understand what you expect to happen when just naming a method instead of calling it.
If I change the code to a proper call:
	model_internal function initialize() : void
	{
		model_internal::propagateEvents(null);
		model_internal::propagateEvents(null);
	}

The output looks correct to me.  I suppose we should fix that someday, but probably after I get some other stuff done.

You are right Alex, the original code was like below;
model_internal function initialize() : void
      {
this.serviceControl.addEventListener(ResultEvent.RESULT,model_internal::propagateEvents);
         this.serviceControl.addEventListener(DataServiceFaultEvent.FAULT,model_internal::propagateEvents);
      }

When I was simplyfying source code I tought it was enough for test case. As I am not so good at as development, it was not true :)
Thanks.


Remove deprecated "launch page" options from app-designer

Software and hardware versions
app-designer rev 212 RC2
Problem description
On the "Preview" tab of app-designer, the Launch Page dropdown has 4 options but 3 of them are deprecated and need to be removed. Only ODK Survey Framework Page should remain. Since there will be only one option left, it should probably not be a dropdown anymore either.

Fixed with https://github.com/opendatakit/app-designer/pull/56


migration: migrate all the dependencies from hilt to ktor

Description
In order to migrate to KMM approach, we need to take out the Hilt from our dependencies and use something Kotlin specific, we decided to choose for Koin.
P.S Migration for tests is coming.
Demo

Before the PR
After the PR

Documentation

Link to documentation: Add link here
Link to figma: Add link here
Add here other useful documentation links that are useful for PR reviewer

Checklist

[ ] New functionality is covered by Analytics events
[ ] Analytics events are documented
[ ] Analytics dashboard is updated
[ ] Functionality covered by unit tests
[ ] I have manually tested if the code works

Why is this draft? Do you want to do something more in this branch?

I made it draft because I wanted to make sure we do not merge it to your branch :P I though it will be good idea if you go first with your changes to the develop and I follow you after that