mashREPL : Better Readline Interaction

Feature description
When using mashREPL we can't move the cursor as we need / want : we can only move one char by one char.
So we need to implement a better way to handle cursor moves : * https://stackoverflow.com/a/12009972

https://unix.stackexchange.com/questions/255707/what-are-the-keyboard-shortcuts-for-the-command-line

[ ] Ctrl-b Move back one character.
[ ] Ctrl-f Move forward one character.
[ ] Ctrl-d Delete the character underneath the cursor.
[x] Ctrl-a Move to the start of the line.
[x] Ctrl-e Move to the end of the line.
[ ] Meta-f Move forward a word, where a word is composed of letters and digits.
[ ] Meta-b Move backward a word.
[ ] Ctrl-l Clear the screen, reprinting the current line at the top.
[ ] Ctrl-k Kill the text from the current cursor position to the end of the line.
[ ] M-d Kill from the cursor to the end of the current word, or, if between words, to the end of the next word. Word boundaries are the same as those used by M-f.
[ ] M-[DEL] Kill from the cursor the start of the current word, or, if between words, to the start of the previous word. Word boundaries are the same as those used by M-b.
[ ] Ctrl-w Kill from the cursor to the previous whitespace. This is different than M- because the word boundaries differ.

Other things :

[x] History is not saved every time when exit

From a TestFlight user :

backspace in mashrepl causes the console to start a new line and a ton of stuff bugs out


Make the reload command executable from the console

make the reload command executable in the console

Closed in #41


Option + return shortkey not showing popup menu to wrap/remove widgets

Steps to Reproduce

Click on any widget in code.
Click option + return.
Nothing shows up. Previously a popup menu to wrap/remove widgets would show up.

I searched about this issue. Quick assists powered by the Dart Analysis Server is already enabled. Im using MacBook.
Version Info
[✓] Flutter (Channel stable, 3.19.5, on macOS 13.0 22A380 darwin-x64, locale en-US)
• Flutter version 3.19.5 on channel stable at /Volumes/workspace/sdks/flutter
• Upstream repository https://github.com/flutter/flutter.git
• Framework revision 300451adae (7 days ago), 2024-03-27 21:54:07 -0500
• Engine revision e76c956498
• Dart version 3.3.3
• DevTools version 2.31.1
[✓] Android toolchain - develop for Android devices (Android SDK version 34.0.0)
• Android SDK at /Users/malhotra/Library/Android/sdk
• Platform android-34, build-tools 34.0.0
• Java binary at: /Applications/Android Studio.app/Contents/jbr/Contents/Home/bin/java
• Java version OpenJDK Runtime Environment (build 17.0.9+0-17.0.9b1087.7-11185874)
• All Android licenses accepted.
[!] Xcode - develop for iOS and macOS (Xcode 14.1)
• Xcode at /Applications/Xcode.app/Contents/Developer
• Build 14B47b
! CocoaPods 1.12.1 out of date (1.13.0 is recommended).
CocoaPods is used to retrieve the iOS and macOS platform side's plugin code that responds to your plugin usage on the Dart side.
Without CocoaPods, plugins will not work on iOS or macOS.
For more info, see https://flutter.dev/platform-plugins
To upgrade see https://guides.cocoapods.org/using/getting-started.html#updating-cocoapods for instructions.
[✓] Chrome - develop for the web
• Chrome at /Applications/Google Chrome.app/Contents/MacOS/Google Chrome
[✓] Android Studio (version 2023.2)
• Android Studio at /Applications/Android Studio.app/Contents
• Flutter plugin can be installed from:
🔨 https://plugins.jetbrains.com/plugin/9212-flutter
• Dart plugin can be installed from:
🔨 https://plugins.jetbrains.com/plugin/6351-dart
• Java version OpenJDK Runtime Environment (build 17.0.9+0-17.0.9b1087.7-11185874)
[✓] Android Studio (version 2021.2)
• Android Studio at /Applications/Android Studio 2.app/Contents
• Flutter plugin can be installed from:
🔨 https://plugins.jetbrains.com/plugin/9212-flutter
• Dart plugin can be installed from:
🔨 https://plugins.jetbrains.com/plugin/6351-dart
• Java version OpenJDK Runtime Environment (build 11.0.12+0-b1504.28-7817840)
[✓] Android Studio (version 2023.2)
• Android Studio at /Applications/Android Studio 3.app/Contents
• Flutter plugin can be installed from:
🔨 https://plugins.jetbrains.com/plugin/9212-flutter
• Dart plugin can be installed from:
🔨 https://plugins.jetbrains.com/plugin/6351-dart
• Java version OpenJDK Runtime Environment (build 17.0.9+0-17.0.9b1087.7-11185874)
[✓] Connected device (3 available)
• Android SDK built for x86 (mobile) • emulator-5554 • android-x86    • Android 11 (API 30) (emulator)
• macOS (desktop)                    • macos         • darwin-x64     • macOS 13.0 22A380 darwin-x64
• Chrome (web)                       • chrome        • web-javascript • Google Chrome 123.0.6312.105
[✓] Network resources
• All expected network resources are available.

@iffraa
Do you mean the intellisense / automcomplate is not showing up ?
What IDE are you using in which you are seeing this ? VSCode or AS ?

Im using Android Studio. I've added flutter doctor v output in my initial query. You can check that.
While clicking on light bulb or using its respective shortkey, the popup menu to wrap/remove widgets is not showing up. I've attached image.

@iffraa
This most probably looks like intellij - flutter plugin issue rather than framework / sdk level issue.
You'll need to report this in dedicated repo: https://github.com/flutter/flutter-intellij/issues
Closing from here.


Allow runtime configuration of issuers

Currently, installing csi-driver-spiffe requires that users have already installed cert-manager and already created an issuer, because issuer config must be passed in at startup.
This presents problems when users wish to install everything and configure it later. It also means that it's not possible to change issuers without risking downtime of the driver, which in turn implies downtime in being able to create any pod which relies on csi-driver-spiffe.
This PR adds support for runtime configuration through a ConfigMap. If enabled, the ConfigMap will be watched and if it exists and the configuration is value, the issuer specified in that ConfigMap will override any issuer configured at runtime.
To support the e2e tests for this, we also add lots of helper functions for generating issuers for e2e tests and retrieving certificate details from pods without copy+pasting boilerplate test code.
EDIT: I forgot to link the design doc which this PR implements.

/test pull-cert-manager-csi-driver-spiffe-test

Hey, I'm trying to wrap my head around the user experience of this new feature. I guess what I am missing is an example of a configmap manifest that people will be expected to write, here is an example for anyone looking at this PR:
apiVersion: v1
kind: ConfigMap
metadata:
  name: csidriverspiffe-config
  namespace: cert-manager
data:
  issuer.group: cert-manager.io
  issuer.kind: ClusterIssuer
  issuer.name: ca

Creating the configmap is a one-liner:
kubectl create configmap csidriverspiffe-config -n cert-manager \
  --from-literal=issuer.name=ca \
  --from-literal=issuer.kind=ClusterIssuer \
  --from-literal=issuer.group=cert-manager.io

By the way, is the dot in issuer.name needed, or is it an established pattern used elsewhere? The flags are --issuer-name etc, so I was kind of expecting the keys issuer-name, issuer-kind and so on 😅

Regarding the why, I assume that the main problem this is trying to solve is to avoid creating an immediately-failing daemonset.

The main problem this is trying to solve is definitely to enable csi-driver-spiffe to be installed at the same time as cert-manager, with the best UX possible. I think the UX of this works pretty well, but it would feel super janky to install csi-driver-spiffe with some dummy issuer name and cert-manager and then have to reconfigure csi-driver-spiffe entirely when the issuer is created.

I'm not sure why restarting the csi-driver-spiffe pods as a consequence of updating the flag --issuer-name is a problem as it should restart almost instantenously.

It feels like a poor UX to me! This design is what was agreed in the design doc when it was discussed. I should've added the link to the design doc to the original description - I'll do that now.

By the way, is the dot in issuer.name needed, or is it an established pattern used elsewhere? The flags are --issuer-name etc, so I was kind of expecting the keys issuer-name, issuer-kind and so on 😅

It couldn't really matter less! I can change it easily if you'd prefer dashes, I really don't mind!

The Helm chart might be slightly off, the flag --issuer-name defaults to spiffe-ca even when using runtimeIssuanceConfigMap. Is that expected?

What I've done:

kind cluster create (1.29.2)

Followed the getting started guide at https://cert-manager.io/docs/usage/csi-driver-spiffe/, with the exception of the helm upgrade step that I slightly edited:
helm upgrade -i -n cert-manager cert-manager-csi-driver-spiffe jetstack/cert-manager-csi-driver-spiffe --wait \
   --set "app.logLevel=1" \
   --set "app.trustDomain=my.trust.domain" \
   --set "app.approver.signerName=clusterissuers.cert-manager.io/csi-driver-spiffe-ca" \
   --set "app.runtimeIssuanceConfigMap=csidriverspiffe-config"

Created the CM:
kubectl create cm csidriverspiffe-config -n cert-manager \
  --from-literal=issuer.name=csi-driver-spiffe-ca \
  --from-literal=issuer.kind=ClusterIssuer \
  --from-literal=issuer.group=cert-manager.io

helm template -n cert-manager deploy/charts/csi-driver-spiffe/ \
 --set "app.logLevel=1" \
 --set "app.trustDomain=my.trust.domain" \
 --set "app.approver.signerName=clusterissuers.cert-manager.io/csi-driver-spiffe-ca" \
 --set app.runtimeIssuanceConfigMap=csidriverspiffe-config

At this point, the pods example-app weren't starting. I found that the csi spiffee approver kept showing these errors related to an unexpected spiffe-ca:

admission webhook webhook.cert-manager.io denied the request: status.conditions: Forbidden: user system:serviceaccount:cert-manager:cert-manager-csi-driver-spiffe-approver does not have permissions to set approved/denied conditions for issuer {spiffe-ca ClusterIssuer cert-manager.io}

I found that there is some `--issuer-name` that keeps appearing in the template, although I used `runtimeIssuanceConfigMap`:

```bash
helm template -n cert-manager deploy/charts/csi-driver-spiffe/ \
     --set "app.logLevel=1" \
     --set "app.trustDomain=my.trust.domain" \
     --set "app.approver.signerName=clusterissuers.cert-manager.io/csi-driver-spiffe-ca" \
     --set "app.runtimeIssuanceConfigMap=csidriverspiffe-config" | grep spiffe-ca

shows:
  resourceNames: ["clusterissuers.cert-manager.io/csi-driver-spiffe-ca"]
          - --issuer-name=spiffe-ca

The Helm chart might be slightly off, the flag --issuer-name defaults to spiffe-ca even when using runtimeIssuanceConfigMap. Is that expected? Is that because csi-driver-spiffe needs some value for --issuer-name to be able to start?

The default for issuer-name is not great, yeah. We've discussed changing it in standups and we're going to change it, but it's a breaking change and I didn't want to do that in this PR!
I'd rather default to not having an issuer.
This PR adds some validation of how the issuer is set - previously there wasn't any.

 --set "app.approver.signerName=clusterissuers.cert-manager.io/csi-driver-spiffe-ca"
This explicitly shouldn't be set. The default is to leave it empty now. Anywhere we say to set this we need to update.

To clarify, I think having to change a flag in the deployment (--issuer-name) is a terrible experience because of this "dummy" issuer. The dummy issuer name shows unhelpful error messages about an issuer that was never actually created. What's even worse is that this dummy issuer will probably not have the approve privilege enabled, meaning that the cert-manager webhook will forbid csi-driver-spiffe-approver from creating CRs...

It's not possible to change issuers without risking downtime of the driver.

That's the part I'm confused about: the design doesn't talk about that problem. I'm probably not familiar enough with csi-driver-spiffe's architecture. How is changing --issuer-name going to cause downtime? Existing CSI requests will still be served, then the driver pods restart and start processing CSI requests using the other issuer.
Is the downtime due to the fact that the driver won't know when there is a change of --issuer-name and won't trigger a new CR? I'm assuming that watching the configmap lets you trigger re-issuance, unlike the --issuer-name flag.

I've successfully tested the feature.
Instructions:
kind create cluster
make oci-load-manager oci-load-approver helm-chart kind_cluster_name=kind git_version=v0.0.0
helm upgrade -i -n cert-manager cert-manager jetstack/cert-manager \
  --set extraArgs={--controllers='*\,-certificaterequests-approver'} \
  --set installCRDs=true \
  --create-namespace
helm upgrade -i -n cert-manager cert-manager-csi-driver-spiffe _bin/scratch/image/cert-manager-csi-driver-spiffe-v0.0.0.tgz --wait \
 --set "app.logLevel=1" \
 --set "app.trustDomain=my.trust.domain" \
 --set "app.approver.signerName=clusterissuers.cert-manager.io/csi-driver-spiffe-ca" \
 --set image.repository.driver=cert-manager.local/cert-manager-csi-driver-spiffe \
 --set image.repository.approver=cert-manager.local/cert-manager-csi-driver-spiffe-approver \
 --set image.pullPolicy=Never \
 --set app.issuer.name= \
 --set app.issuer.group= \
 --set app.issuer.kind= \
 --set app.runtimeIssuanceConfigMap=csidriverspiffe-config

Then, install the example app:
kubectl create -f https://raw.githubusercontent.com/cert-manager/csi-driver-spiffe/ed646ccf28b1ecdf63f628bf16f1d350a9b850c1/deploy/example/example-app.yaml

The driver logs tells me there is something wrong. I wish it told me that csidriverspiffe-config wasn't found or something like that:
kubectl logs -n cert-manager -l app.kubernetes.io/name=cert-manager-csi-driver-spiffe

server.go:109] "failed processing request" err="generating certificate signing request: no issuerRef is currently active for csi-driver-spiffe; configure one using runtime configuration"

Then, I created the clusterissuer and the config:
kubectl apply -f https://raw.githubusercontent.com/cert-manager/csi-driver-spiffe/ed646ccf28b1ecdf63f628bf16f1d350a9b850c1/deploy/example/clusterissuer.yaml
kubectl create cm csidriverspiffe-config -n cert-manager \
  --from-literal=issuer-name=csi-driver-spiffe-ca \
  --from-literal=issuer-kind=ClusterIssuer \
  --from-literal=issuer-group=cert-manager.io

This time, the pods are running:
$ k get pods -n sandbox
NAME                         READY   STATUS    RESTARTS   AGE
my-csi-app-6f58c7589-5rqnk   1/1     Running   0          83m
my-csi-app-6f58c7589-cpt8g   1/1     Running   0          83m
my-csi-app-6f58c7589-d5bgj   1/1     Running   0          83m
my-csi-app-6f58c7589-s4dss   1/1     Running   0          83m
my-csi-app-6f58c7589-xpbmt   1/1     Running   0          83m

Questions:

You mentioned that I shouldn't be using the signerName in the Helm chart:
--set app.approver.signerName=clusterissuers.cert-manager.io/csi-driver-spiffe-ca

I think I understand what's up with this 😅

Is there a way to show a friendlier error message when the configmap is missing?

In my helm upgrade command, I had:
--set app.issuer.name= \
--set app.issuer.group= \
--set app.issuer.kind= \

Is this recommended way to configure empty --issuer-name flags?

We had a quick call. Here are the answers:

The problem with --set app.approver.signerName=clusterissuers.cert-manager.io/csi-driver-spiffe-ca is that the user had to know the name of the issuer name when they deploy csi-driver-spiffe, which causes the same problem as having to know --issuer-name when deploying csi-driver-spiffe rather than later on.
yes, the recommended way is to use --set app.issuer.name= to avoid confusing people with a dummy issuer name.

/unhold
I've addressed the nit now and rebased against main!

/lgtm


Exponential notation is not captured as a float

I saw the value 3.933994946453261e-05 was not converted to a sigfig. I am guessing this is because this values is not interpreted as a float.

Try:
if e- or e+ is in the string then assume a float and multiple number by 10^(string after e[-/+])

an alternative:
in the sigfig, if there is an e in the float name then sigfig on values before e and concatonate e in final string


document using latest zk

I wanted to share what I learned in bumping to Solr 8.7 and the latest ZK for the next person ;-).  Please do review that the changes I made are "right".

The <IP_ADDRESS> ones were there on purpose. I don't recall what purpose exactly... is it that without it, they do not listen on localhost? Not sure if any of the scripts/code cares, or if the idea was that you could run zkCli.sh from a docker exec.

I gave it a stab of putting back the <IP_ADDRESS>, and this is what Solr is giving me now:

I removed the <IP_ADDRESS> and Solr became happy again:

Also, I think that run zkCli.sh is kind of devops smell, since we do have our bin/solr zk method, as well as the evolving APIs, like the configset api, to reduce the need to do zkCli.sh.

Sounds good to me

BTW, this has been one of the most useful repos for me to learn more about Solr and Docker!

Thanks for the contribution.  I tried this out, including access ZK's new prometheus support.
I didn't know this "docker-solr-examples" repo existed before today, or I forgot about it.  Maybe stuff like this could go right into Solr's example/ dir?  Any way; such a discussion deserves solr dev list discussion, not hidden here.

Thanks for the contribution.  I tried this out, including access ZK's new prometheus support.
I didn't know this "docker-solr-examples" repo existed before today, or I forgot about it.  Maybe stuff like this could go right into Solr's example/ dir?  Any way; such a discussion deserves solr dev list discussion, not hidden here.

David, as usual, you think beyond just the immediate ticket.  I agree that once the Docker stuff is in Solr (and it's close!) that moving some of this over and beefing up the ref guide will be a nicely block of work!

David, as usual, you think beyond just the immediate ticket.  I agree that once the Docker stuff is in Solr (and it's close!) that moving some of this over and beefing up the ref guide will be a nicely block of work!


Macro: R2 and R3 connection points shown as R1 and R2 on monomer preview tooltip for (R2,R3) peptide

Steps to Reproduce

Switch to Macromolecules view
Load this file: (R2,R3) - R1 gap.zip
Hover mouse over peptide

Actual behavior

System shows R1 and R2 labels instead of R2 and R3 on monomer preview tooltip
Expected behavior
System shows R2 and R3 labels on monomer preview tooltip
Desktop (please complete the following information):

OS: win10
Browser Chrome 120.0.6099.110 (Официальная сборка), (64 бит)

Ketcher version [e.g. v2.4.2].

Verified.


Preloading Imagery For Time Animating Not Working After OL v10.2.0

Describe the bug
As part of our project, we have a feature that allows for animating imagery in a static location across a period of time automatically. When the user requests an animation, we preload the imagery for each date interval across the requested time period by creating a new layer with a new source for each interval, and then store it in cache for later without actually displaying the layer on-screen (this caching is done through cachai). Once all time intervals have preloaded their imagery, we start the animation, and pull the already created layers from the cache and display them on-screen in order for a smooth animation.
This method fully worked in version of OL up to v10.1.0, but once we tried upgrading to 10.2.0 or higher, this animation method no longer seems to work the same. After upgrading, the behavior now almost seems like the imagery wasn't fully preloaded. During the animation now, the imagery flashes to black momentarily before being rendered on-screen, instead of before where it correctly displayed on-screen as soon as we advanced the time step.
To add to the confusion, this behavior seems slightly different on different browsers. It flashes black momentarily before correctly rendering on Firefox, but in Chrome and Safari, it seems to be hit or miss on if the imagery will show at all before the next animation frame is rendered. And on subsequent loops through the same animation, the imagery seems better loaded, which is exactly what we are trying to achieve on the first loop through preloading it.
To Reproduce
I haven't been able to create a small-scale demo of this that shows the issue correctly, but I have a recording of how the behavior looks when run in Firefox (attached at the bottom).
Expected behavior
This should behave the same as it did in versions previous to v10.2.0, where preloaded imagery displays without flashing to black before.
Apologies if this isn't enough information to go off of, I've just run out of avenues to investigate this on my own.
Warning for flashing
https://github.com/user-attachments/assets/d26215bb-d763-4e19-b7d3-cf1e0252d56c

Without seeing how you actually create and cache your layers, it is hard to diagnose what's going on. In v10.0, we started moving the tile cache from the source to the renderer. This was completed in v10.2, so in case you're using tile layers, that could somehow affect what you're doing. If you're using image layers, then I have no idea which change could be causing what you're seeing.
Ideally, "preloading images" would just mean that you let your browser load the images, so they are available in the browser cache. No need to do anything else if the server sends correct cache headers. It sounds like you're doing more to preload images.
Either way, without seeing a minimal reproduction case, it will be hard to diagnose this further.

Apologies for not being able to provide more to work off of, I know that makes this a lot harder to diagnose, so I appreciate you doing what you have with what I've given. We are using tile layers in this instance, and this move from caching in the renderer instead of the source was exactly my hunch on what specifically had changed that caused this, so it's good to know that that was one of your first thoughts as well.
Is there a different way we should be handling tile layers on our end due to this change, as opposed to previous versions? Or is the caching going from source -> renderer only something that matters internally to OL, and I should just look into fixing the cache headers or similar? From my perspective, if it is the case that this is more of an internal change, it does feel odd that it would negatively effect how the caching was working on our end.

Without seeing how you make the layers/sources actually fetch tiles, I cannot help any further. Fact is (and that was the same before the mentioned change) that tiles will only be loaded once a layer has been added to a map, and for the current viewport.
That said, if you're saying you're not displaying the layers on-screen, I don't see how tiles would have been loaded even before that change.

The only cause I could think of is this: do you have an off-screen map that you add your layers to for pre-loading, and do you then remove the layers from that map, adding them to an on-screen map? That would mean you're losing the OpenLayers tile cache.
However, with proper cache headers, the tiles would still be available in the browser cache, so there should be no flickering either.


[X] I have read the Contributing Guidelines on issues.

Prerequisites

[X] I'm using the latest version of Docusaurus.
[X] I have tried the npm run clear or yarn clear command.
[X] I have tried rm -rf node_modules yarn.lock package-lock.json and re-installing packages.
[X] I have tried creating a repro with https://new.docusaurus.io.
[X] I have read the console error message carefully (if applicable).

Description
https://docusaurus.io/docs/api/plugin-methods mentions beforeDevServer and afterDevServer. When I attempted to use these, I found I couldn't get them to do anything. A quick search in GitHub shows only results in .mdx files, so it appears to me like the API simply doesn't exist. Searching for configureWebpack instead, for example, brings up a bunch of results.
Reproducible demo
https://codesandbox.io/p/devbox/examples-classic-b9y9z?file=%2Fdocusaurus.config.js
Steps to reproduce

Run the dev server
Observe that running beforeDevServer isn't logged

Expected behavior
I don't really know because it's completely broken, but I'd expect it to at least console.log when starting the dev server, like it does if I configure the plugin manually using configureWebpack.
Actual behavior
Nothing is logged. I get no behaviour change.
Your environment
No response
Self-service

[ ] I'd be willing to fix this bug myself.

Methods marked as // TODO means they don't exist. Looks very unprofessional to have these stubs in the official documentation, but they have been there since docusaurus had <100 users 😅
I don't think they are off anyone's roadmap, AFAICT, but we haven't seen enough motivating use cases.

I don't particularly care about the APIs in question not existing. In practice, they would have probably saved me little effort. The issue here is the total lack of communication that the wishlist embedded in the documentation is merely that.

Methods marked as // TODO means they don't exist

Why do I have to raise a GitHub issue to establish this? How am I supposed to know this? What I took these docs to mean were "methods with //TODO above them don't have a proper documentation comment". The idea TODO without any context is sufficient communication to anyone, let alone users of the product, is insane.

This entire page is not designed to be user-facing but for communication within a very small group of developers who both develop and consume the plugin APIs. Time has evolved and the audience has changed but the page is not updated. Therefore you are criticizing what is essentially an internal documentation page. I'm not saying it shouldn't be updated, just that no effort has been done and it served its purpose at its time.


Document interaction between initialPassword and initialHashedPassword

The docs of initialPassword / initialHashedPassword are written as if they didn't know the other option existed.

[ ] The docs should explain how they interact, and which one wins if both are set.

From an initial read over the code; both are mingled into users-groups.json here and then a Perl script update-users-groups.pl runs, which seems to prefer initialPassword over initialHashedPassword here, without a comment on why this order makes sense or is preferred.
They were originally introduced simultaneously by @edolstra in https://github.com/NixOS/nixpkgs/commit/1b53a3fcb7d6f1f31c4178131d8dff2177c81060

[ ] The docs should mention the ability to set the password to "!", as was once documented e.g. here and still appears possible. It should be explained whether thta's exactly the same as setting it to null, or whether there are differences.

The docs should mention the ability to set the password to "!"

The idea was that ! and !! are deprecated and only kept for backward compatibility (basically not locking people out their computer). I would not document at all, if possible, or encourage to use null instead.


offset-{x,y} offsets tray, not bar

The title pretty much says it
offset-x offsets the tray icons, and not the bar (and tray-offset-x does that too, but that's normal)
Is there some other parameters of the bar that are incompatible with offset ?
EDIT : polybar -v gives me this, maybe it could be useful ?
polybar 3.1.0-40-g2f11344

Features: +alsa +curl +i3 -mpd +network +pulseaudio

Reinstalled the "normal" version (polybar package instead of polybar-git) : polybar -v
polybar 3.1.0-git

Features: +alsa +curl +i3 -mpd +network

Are you using override-redirect = true? If not, try using it and see if it helps.

That solved the offset problem, but created a new one : now my bar is floating, it is over my window :/

Try wm-restack = i3.

Nothing happened :/

The bar is no longer over my window
It is now behind it :joy:

i3 is very finicky with padding. I think usually people have a dummy bar/window/conky behind it and have polybar floating over it to fix this issue.

Just realized you could also have a transparent border (border-color = #00000000) and border-{left,right}-size as your x offset and border-{top,bottom}-size as your y offset.

That kind of does the trick yes, but it's really tedious

Just tested this a little. It seems this is another quirk of i3, this doesn't happen in hlwm. So I think, there is really not much we can do about this.


Add method to finalize the Response and return the raw output stream

Pippo is an abstraction and convenience layer for the servlet API.  If you
need to implement custom streaming you can not use any of the Response
API when setting up headers, etc.  This change allows you to configure the
Response, as you normally would, and then obtain the raw output stream for
custom response streaming.

Good. Thanks! I cannot merge this PR from github. A rebase is a must after previous PR. Please commit yourself.


Remove trailing whitespace from confirmation view

Though not a real issue, it was highlighted as an error by my commit
hooks, so I took the opportunity to fix it.

Thanks!


change from an oval to an elongated bubble for notifications

before:

after:

Coverage remained the same at 85.931% when pulling fae59712e694eea76b70787e81dd48ac857df436 on abemassry:oval-to-bubble-notifications into 44e825ce6b35e2afa71e4b53fcffe0020528386c on linode:master.

Was waiting on @abemassry to make some changes before merging. But he can get them taken care of now in a future PR.


Add documentation to many parts of the Rust codebase

I added lots of documentation, mostly for graphite-graphene::layers. There is definitely still a lot of room for improvement but its better than nothing. I also added the From<ShapeLayer>, From<TextLayer> and From<FolderLayer> impls for Layer that i talked about in the discord.
(Some functions are documented even though their name is self-explanatory - because it makes the documentation generated by rustdoc easier to read)

Hm forgot to comment again so i'll do it now: I added all your suggestions, re-review please?

From a technical point of view this all looks good, will wait for @Keavon to give his approval after spell checking + linting the text

From a technical point of view this all looks good, will wait for @Keavon to give his approval after spell checking + linting the text

Sure, I can review it for that sort of thing pretty quickly if I don't have to actually think about the logic of it. Let me get started shortly.

My bad! I totally forgot about this. I was supposed to read through it, like, a month ago. I'm terribly sorry for dropping the ball on this! I'll get this done today.

All good, im currently pretty busy irl anyways. No need to hurry

FINALLY done. So sorry for the wait. GDC then school starting got in the way of my last promised time to review it. But now I'm merging it. I guess I've found one of the types of things I am prone to procrastinate: code reviewing lots of non-code. Thank you for the contribution and patience!


Improve AWS credential handling

Is seems that this PR has the same idempotent issue as https://github.com/wcm-io/wcm-io-maven-archetype-aem-confmgmt/pull/30

We should also only ask and use the aws credentials when AWS or terraform is used.

@bellackn i have merged this PR into #41, closing this PR


First take on a schema for OpenSpending Data Package.

WIP: may have errors. Particularly, need to check use of anyOf with types, as we have lots of fields in OSDP that can be string or array. Also, need to implement the whole thing with attributes also being objects, like {"source": "something", "other_key": 1}

Closing because Fiscal Data Package has superseded OpenSpending Data Package.


rling: init at unstable-2023-09-02

Description of changes

Added rling a faster multi-threaded, feature rich alternative to rli found in hashcat utilities.
https://github.com/Cynosureprime/rling
Related to https://github.com/NixOS/nixpkgs/issues/81418
Things done

Built on platform(s)

[x] 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
[x] Tested basic functionality of all binary files (usually in ./result/bin/)
24.05 Release Notes (or backporting 23.05 and 23.11 Release notes)

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

[x] Fits CONTRIBUTING.md.

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

Sorry @tomodachi94 I accidently discarded the changes in this branch I'll be opening a new PR

Please open a new PR (and ping me on it), there are many people now subscribed to this thread.


[feature-request] Include name of documented object in D417 (undocumented-param) error message

Just ran on D417 (undocumented-param) on the codebase. We haven't turned this on yet because we have so many violations. The errors printed look like this:
python_modules/dagster/dagster/_core/definitions/job_definition.py:587:9: D417 Missing argument descriptions in the docstring: `asset_selection`, `run_config`, `run_id`, `tags`

It's useful but it would be better if it included the names of the objects that the failing docstrings are attached to:
python_modules/dagster/dagster/_core/definitions/job_definition.py:587:9: D417 Missing argument descriptions in the docstring for `JobDefinition`: `asset_selection`, `run_config`, `run_id`, `tags`

Nice idea.

(I wonder if we should just do this for all D rules?)


screen inside of toolbox

If I start "screen" inside of toolbox the output is gargabe.
This happens also when my ~/.screenrc is empty.
TERM=linux
Wtih TERM=ansi it is the same issue.
Here some output of "ls -l".
ansari fansari   30 Dec  7 21:20  usr
                                     drwxrwxr-x.   2 fansari fansari   48 Jul 14  2018  vagrant
                                                                                -rw-rw-r--.   1 fansari
 fansari 3269 Jul 15  2018  Vagrantfile
                                       drwx------.  55 fansari fansari 4096 Apr  8  2018  vanessa
                                                                                drwxr-xr-x.   4 fansa
ri fansari   32 May  6 18:30  Videos
                                    drwxrwxr-x.   3 fansari fansari   87 Oct 31  2015  vmware
                                                                                drwxrwxr-x.   4 fansari f
ansari   39 Apr 23  2018  WebstormProjects
                                          drwxrwxr-x.   7 fansari fansari   89 Dec 31  2017  workspace
                                                                                drwxrwxr-x.   2
fansari fansari  259 Dec 23 15:13  X-Air
                                        drwxrwxr-x.   4 fansari fansari   36 Jul  3  2018  zabbix
                                                                                ⬢[fansari@toolbox ~]$

Which terminal emulator were you using?
I haven't seen glitches this bad with VTE and TERM=xterm-256color.

As I said - I tried to set TERM to linux and ansi. Now I have also tried xterm-256color and it behaves the same way.
vanessa
       drwxr-xr-x.   4 fansari fansari   32 May  6 18:30  Videos
                                                                drwxrwxr-x.   3 fansari fansari   87 Oct 31  2015  vmware
                                                                                drwxrwxr-x.   4 fansari fansari   39 Apr 23  2018  WebstormProjects
                                                                                drwxrwxr-x.   7 fansari fansari   89 Dec 31  2017  workspace
          drwxrwxr-x.   2 fansari fansari  259 Dec 23 15:13  X-Air
                                                                  drwxrwxr-x.   4 fansari fansari   36 Jul  3  2018  zabbix
                                                                                ⬢[fansari@toolbox ~]$ echo $TERM
                                                                                screen.xterm-256color
                                                                                ⬢[fansari@toolbox ~]$

I see, ok. :(
I wonder, if like #14, this is also https://github.com/containers/libpod/issues/3179

Could you please try this again with Podman 1.5.0 and Toolbox from Git master?

@fansari ping ?
Somehow I just cannot reproduce using VTE and GNOME Terminal on Fedora.

Today I have updated my Fedora 30 and now I have podman 1.5.1.
When I run screen in toolbox I only get an error message:
Utmp slot not found -> not removed
Then screen is terminating. I have tested TERM linux and ansi but both give this error.

So, let me ask again. What terminal emulator are you using? I am not asking about the TERM variable, but what's the software inside which you are running the shell. Is the Linux console (ie., ctrl+alt+f3 and such) or is it GNOME Terminal or something else?
I am asking because I am not able to reproduce it at all and I haven't seen others bring this up. So I am not sure what's going on.

I always use the default GNOME terminal.

I always use the default GNOME terminal.

Ok. I think that you shouldn't have to change the TERM variable because it's tied to the software that's providing the terminal emulation. eg., for GNOME Terminal TERM should be set to xterm-256color.
Since the last few years, GNOME Terminal doesn't update utmp and wtmp records anymore. I wonder if this Utmp slot not found -> not removed error is somehow related. Could you strace the screen process and see if that reveals something?

What's the ownership and permissions of /run/utmp on your system? I have:
$ ls -ld /run/utmp
-rw-rw-r--. 1 root utmp 1536 Sep 30 12:39 /run/utmp

One workaround is to put deflogin off in your Screen configuration. However, I have deflogin on in my /etc/screenrc and I don't see the error that you have been experiencing on my Fedoras, so I think something else is off.

-rw-rw-r--. 1 root utmp 9216 Sep 30 18:36 /run/utmp

⬢[fansari@toolbox fansari]$ sudo dnf install screen
We trust you have received the usual lecture from the local System
Administrator. It usually boils down to these three things:
#1) Respect the privacy of others.
#2) Think before you type.
#3) With great power comes great responsibility.

Fedora Modular 30 - x86_64                      2.4 MB/s | 2.7 MB     00:01
Fedora Modular 30 - x86_64 - Updates            3.2 MB/s | 4.0 MB     00:01
Fedora 30 - x86_64 - Updates                     11 MB/s |  21 MB     00:01
Fedora 30 - x86_64                               16 MB/s |  70 MB     00:04
Dependencies resolved.
Package         Architecture    Version                  Repository       Size
Installing:
screen          x86_64          4.6.2-8.fc30             fedora          557 k
Transaction Summary
Install  1 Package
Total download size: 557 k
Installed size: 1.0 M
Is this ok [y/N]: y
Downloading Packages:
screen-4.6.2-8.fc30.x86_64.rpm                  3.2 MB/s | 557 kB     00:00
Total                                           688 kB/s | 557 kB     00:00
Running transaction check
Transaction check succeeded.
Running transaction test
Transaction test succeeded.
Running transaction
Preparing        :                                                        1/1
Running scriptlet: screen-4.6.2-8.fc30.x86_64                             1/1
Installing       : screen-4.6.2-8.fc30.x86_64                             1/1
Error unpacking rpm package screen-4.6.2-8.fc30.x86_64
Verifying        : screen-4.6.2-8.fc30.x86_64                             1/1
Failed:
screen-4.6.2-8.fc30.x86_64
Error: Transaction failed

After this screen is installed despite of the error message.
The toolbox is not usable anymore after I ran "dnf upgrade". Or is this not allowed/recommended inside the box?
Now I can open screen but it uses only half of the terminal (vertically).
I can fix this when I comment this line of my .screenrc like this:
# termcapinfo xterm* ti@:te@

After "dnf upgrade":
[fansari@bat ~]$ toolbox enter
toolbox: failed to create /run/.toolboxenv in container fedora-toolbox-30

After this I have to stop and remove the toolbox and recreate it.

The Error: Transaction failed from DNF makes me think that there's something wrong with fuse-overlayfs. What does rpm -q fuse-overlayfs say?

On the host it gives fuse-overlayfs-0.6.2-2.git67a4afe.fc30.x86_64.
Inside of the toolbox it is not installed.

Ok. I see various bug-fixes between fuse-overlayfs-0.6.2 and fuse-overlayfs-0.6.3.
Could you please try fuse-overlayfs-0.6.3-2.0.dev.git46c0f8e.fc30:
https://koji.fedoraproject.org/koji/buildinfo?buildID=1390375
(yes, fuse-overlayfs is only meant to be on the host)
Are the DNF failures more or less reproducable? If so it might be practical to concentrate on those first. Such strange filesystem errors are usually caused by fuse-overlayfs.
Thanks for sticking with this issue for so long. I wish we could have nailed it sooner.


Support Same Resource RC Links

Story
As a content creator I want to be able to insert links within the same resource so that I can reference other material.
As a user I want to be able to click on links within the same resource so that I can navigate and see the related material.
Notes
This task is to add support for Links within the same RC.

This works if implemented as relative links within a resource or as double bracket relative links like [[./LICENSE.md]].  See https://git.door43.org/jag3773/testing_/src/branch/master/README.md as an example.


Read CLI banner information from Cargo

Create a build script to output cargo information as singleton instance of a struct object.
The main file will load the included module to read all of the cli infomation.

See https://doc.rust-lang.org/cargo/reference/environment-variables.html#environment-variables-cargo-sets-for-crates

Does not require a full build script. I can just set constants in the lib.rs file using env!. Then read them on main using tortuga::VERSION, etc.


Path based routing to different service with same prefix

As part of our path based routing we need to have routes hit different services, for example:
  path: /api/v2/endpoint
            backend:
              service:
                name: svc-1

While a route with the same prefix needs to be routed to a different backend:
- path: /api/v2/endpoint/*/service-2
            backend:
              service:
                name: svc-2

As it stands, AGIC is routing everything to service-1, including requests with longer pathing that should be sent to another service (which makes sense in a way). Our endpoints have the same name on different servers, so I assume this is something for rewrite rules to handle, but I can't seem to find any documentation or suggestions on how to get there or whether it's even supported.
Any feedback would be appreciated.

Looks like this has been brought up previously in #844


'ipam.models.MultipleObjectsReturned'

I had to migrate the machine from a Hyper-V environment to an ESX one, and the V2V didn't like the Ubuntu 16.04 server I had it on so...
I fired up a new server, went through the setup process and restored the database using:
pg_dumpall -h (ip of server) > backup.bak
psql -f backup.bak postgres
Pretty much everything works except a few subnets under Prefixes. On those I get the error:

Server Error
There was a problem with your request. This error has been logged and administrative staff have been notified. Please return to the home page and try again.
If you are responsible for this installation, please consider filing a bug report. Additional information is provided below:
<class 'ipam.models.MultipleObjectsReturned'>
get() returned more than one Aggregate -- it returned 2!

I'm guessing I have a duplicate entry somewhere, but I'm not sure how to track down and delete the funky one, or if there's a better way to do it.

That's odd. Does the list of aggregates in the admin UI (IPAM > Aggregates) look correct? You can also check via the shell by running ./manage.py shell and pasting the following code:
from ipam.models import Aggregate
for a in Aggregate.objects.all():
    print('[{}] {}'.format(a.pk, a))

Yeah it looks great, both in the web interface and from the shell.

Wait I figured it out, I'm a dummy. Posting fix.

Sorry everyone, false alarm.  Can I still blame a turkey hangover?

@Fyzzle I'm curious how you ended up with overlapping aggregates in the first place, though. There's validation in place that's supposed to prevent that from happening.

Ah gotcha, I'm a little overextended today but everything is fresh in my head.  I'll write up a step by step of what I did.

Okie dokie:
I went through the docs and installed on Ubuntu 16.04 server using the Debian instructions.
I installed by cloning the git repo and went step by step through the rest up until the "Run Database Migrations".  Before that step I restored the database to the new server.  I think that's where the hang up was, I should have done it later in the process.
The rest of the install was done as written, I did not skip any steps in the process.

Thanks for the follow-up. Barring any recurring errors, it seems like we can attribute this to a fluke.


Fixes various bugs in MainMenuOptions

Fixes various bugs in the options menu:

Resolution combobox does not have a default value
Fullscreen checkbox is tied to vsync checkbox
isInit is removed
Uses std::to_string instead of std::ostringstream

Current known issues:

Resolution popup appears when it shouldn't.
Resolution combobox is changed when re-entering the menu even if Cancel is clicked.
Apply button does not properly disable itself when no changes have been made.
Occasionally fullscreen is applied even though the setting is unchecked.

Some merge conflicts will need to be resolved here. Let's try to merge #158 first, and then rebase this one and fix the merge conflicts.

Rebased and resolved.

I was looking at this one and noticed random displays of the popup "You must restart the game for the video options to take effect". This problem seems to exist on master, so it not unique to this PR. I'm not sure if this PR was intended to fix that or not. It only says "fixes various bugs in the options menu". That's way to vague of a PR description for me to know what this PR is about. Could you please update the description of what this actually does?
Additionally, this PR contains large whitespace changes, which makes it very difficult to see at a glance what this PR is actually changing. We should avoid doing large whitespace changes in the same PR as a large functional change. Could you please rework this one to separate the whitespace changes from the functional changes? Maybe we could apply whitespace changes first, in their own PR, to fix the inconsistency. Postponing whitespace changes until later is also an option if that is easier.
Additionally, I created and merged #194, in case you want to build on top of that.

I've edited the description. The merge from master screwed all kinds of things up. I'll split out the whitespace changes. It was mostly tabifying the document.

The description is much clearer now. Now I know what to expect when I look at the code.

Haven't looked at the code yet on this one but skimming through the comments and I noticed this:

"You must restart the game for the video options to take effect"

There should be no need for the game to be restarted for any video changes to take effect, there is nothing in the renderer that can't be done on the fly.
Anyway, I'll take a look at this at some point and try to make some sense of it (see my comments in another PR).

@ldicker83
How? There are no functions on Renderer to change the window size except on construction. Hence the dialog.

@ldicker83
@DanRStevens
Determining what these functions do is not intuitive at all
    virtual void size(int w, int h) = 0;
    const Point_2df& size();

You're right. They are a bit inconsistent about packed/unpacked parameters.  :/
That said. I've implemented resolution changes without restarting.

@DanRStevens
@ldicker83
Validating the display resolution to be no smaller than 1000x700 breaks any resolution selection below that value. The game works at 640x480. Recommend removing the validation function.

I would be fine if we dropped the minimum supported resolution. That may be an easier and more sensible change than removing any kind of minimum.

Just a reminder, I was asking for a rebase to make these changes easier to review. The large whitespace changes should either be squashed or moved to a new PR, depending on whether the changes were introduced here or pre-existing.

I think the history is fixed. There was one section that could not be split up into any smaller hunks and the changelist was so large I was getting lost on how to use the "edit hunk" feature, especially while staring at a CLI.

FYI:
src/UI/MainMenuOptions.cpp:92:14: warning: unused variable 'gfx_width' [-Wunused-variable]
                const auto gfx_width = cf.graphicsWidth();
                           ^
src/UI/MainMenuOptions.cpp:93:14: warning: unused variable 'gfx_height' [-Wunused-variable]
                const auto gfx_height = cf.graphicsHeight();
                           ^

Weird. Doesn't warn in VS. Fixed now.
Should probably bump the warning level to 4.

Quick question(s) before I get started on this: If I commit the white space changes to this PR, wouldn't cherry-picking earlier commits not contain them?
On that note, committing the white space changes to a new PR would have that new PR be a base to the cherry-picked commits in order for them to contain the new white space, right?


OOD PR fix building ES6+ JS assets in prod

Create documentation for https://github.com/OSC/ondemand/commit/13c780749c531fdfc6f2fcc07f0efe166b9f9460

Nope!


Make POT generator able to extract strings from binary operations

Now strings can be extract from binary operations inside GDScript, such as:
tr("string 1" + "string 2")

Since tr() is runtime and not a macro, I think we could add any constant expressions of the tr() argument to localization keys, not just when it's a concatenation of string literals. Plus it's easier to implement.

@dalexeev This is my first time messing around with anything related to the GDScript parser, so I don't know how I would handle that.

@YeldhamDev I opened an alternative PR #80020.

Nice translation branch, @YeldhamDev. I approved @dalexeev's PR, but thanks for your PR!

Superseded by https://github.com/godotengine/godot/pull/80020.


DRY about linkml model enrichment in Makefile

@cmungall , could you help me try to generalize a pattern for running LME enum annotation over several different enums, in series?
We'll probaly want to tune the ontology_string, max_cosine and trim_parentheticals for each requested_enum_name
I do remember your request to separate the annotation from the NMDC DH build

As of now, the enums are

analysis_type_enum
cur_land_use_enum
dna_cont_type_enum
dna_dnase_enum
dna_sample_format_enum
drainage_class_enum
env_package_enum
fao_class_enum
growth_facility_enum
oxygen_relationship_enum
profile_position_enum
samp_biotic_relationship_enum
sample_type_enum
soil_horizon_enum
storage_condt_enum
tillage_enum

Closing in preparation of archiving this fork. Use the main DataHarmonizer repo for development.


Reproducibility results

Hi,
I checked if I can reproduce the results similar to those in the paper to make sure I am training the model properly. These are the results that I got on Vimeo triplets:

The model prediction is shown for t=1 (predicting between t=0 and t=2), the second row corresponds to interpolation ("Interpol"), and the last row to flow ("Flow pred"). I see that interpolation results are very good, however, I expected the flow to be a bit more accurate. In section 6.2 of the appendix you mention that "IFNet produces clear motion boundaries.", this is also what can be seen in Figure 10. Therefore I wanted to ask if there were any other training steps that I need to add to get flow prediction more accurate. I can of course share more prediction examples that I got.
The training was done for 300 epochs using the reconstruction losses and distillation loss (the latter is with coeff. 0.01) as described in the paper, I didn't change anything in the code to train and obtain these results. This is the loss plot:

I would appreciate if you can confirm that you trained the model the same way and that your flow predictions look similar. I used IFNet for training (self.flownet = IFNet()).

Thanks for sharing the flow results. I tried to improve them on my datasets using regularization, smoothness, and photometric loss components. From my experiments, I see some improvement in terms of predicted flow with regularization and photometric constraints, that e.g. fixes the flow direction and penalizes unnecessary flow vectors. The interpolation is very good in all scenarios once the model converges properly. Did you try earlier to add e.g. photometric loss in your experiments? It might be more challenging to get the network to converge when using more loss components.
Also, I saw in the previous discussion ("training questions" issue) that you are not using distillation loss anymore, but instead have VGG loss. I guess it will give some improvement in terms of interpolation, but I am not sure if that can help for the optical flow prediction. Is the code for the new version  (with only L1 + VGG loss) available somewhere?

Have you heard of TOFlow? https://github.com/anchen1011/toflow
Because I believe that optical flow is just a description of a type of pixel relationship, and for real-time video, optical flow is ambiguous. When downstream tasks are considered, the optical flow properties change again. If you're after better optical flow, maybe work in the field of unsupervised flow can help.

I didn't hear of TOFlow, I checked the paper but they pre-train their motion estimation network on Sintel, in a supervised mode.
I already tried to utilize e.g. UPFlow (https://github.com/coolbeam/UPFlow_pytorch) but I faced the issue that their training was specific for the CV datasets and there were several training stages involved. I wasn't able to reproduce the results easily and actually my research is to apply such techniques to different type of datasets, so I decided to return to RIFE and improve its results. I am also thinking about adding supervised loss to existing reconstruction and distillation losses to improve the flow, other experiments involved adding regularization and photometric components, as I mentioned earlier. I am trying to get consistent results on all datasets at the moment.
Sometimes I saw that distillation error becomes NaN, I may try Batch normalization as you suggested.


Incompatible with Rector 0.18.0

PHP Version
8.1
Shopware Version
<IP_ADDRESS>
Actual behaviour
Running Rector throws an error

Expected behaviour
Running Rector should work correctly
Steps to Reproduce?
I think this is related to https://github.com/rectorphp/rector-src/pull/4698 since the import function has been refactored.

We're having the same issue, had to pin rector/rector to ^0.17 which I believe is what frosh/shopware-rector should use as the dependency target too, given for versions < 1.0 semver states that breaking changes may be introduced on minor version bumps and using ^ instead of ~ properly accounts for that.

I've setup a MRE on this repo: https://github.com/rmobis/shopware-rector-mre
Cloning and running the following commands should reproduce the issue:
$ composer install
$ vendor/bin/rector process src --config .\rector.php

Hi, thanks for reporting. This change is  intended with container switch.
Imported config paths must be explicit.

Looking at shopware configs, there are just 3 files to include, so there is no need for glob loading.
https://github.com/FriendsOfShopware/shopware-rector/tree/main/config/v6.5
Also, exact paths allows PHPStan to validate if path exists.
Use exact paths instead :+1:


[WIP] Reduce time spent rerendering when interacting with the page. Fixes #253. r=jsantell

As mentioned in #253, we are doing lots of rerenders when the page object changes, which it does frequently because of the SET_PAGE_DETAIL and SET_USER_TYPED_LOCATION action types.
This PR gives us a big decrease in the amount of time spent.
I created a test which creates 6 additional tabs (7 total) and then sets the status text 3 times.
Before (~37ms):

After (~9ms):

If you want to try it yourself, I posted a patch with the test code. Feedback welcome on the testing technique.

btw, this very likely breaks multiple tests. I haven't looked at them yet, wanted to get feedback on the approach before changing them

I'm going to close this one out. We'll be going with a similar approach, but focusing on moving changes out of the page object. See #282.


Fixed bug in translating browse paths to node IDs.

The for-loop should iterate over requests, not results which is null at that time.

Thanks, good catch.


Incorrect structure generated for repeating units

I draw the following:

The structure is hard to see:

and generates the following molfile.
   JSDraw204261815252D

 12 11  0  0  1  0              0 V2000
   16.2010   -7.4359    0.0000 C   0  0  0  0  0  0  0  0  0  0  0  0
   17.5519   -8.2160    0.0000 C   0  0  0  0  0  0  0  0  0  0  0  0
   18.9030   -7.4361    0.0000 C   0  0  0  0  0  0  0  0  0  0  0  0
   17.5518   -9.7759    0.0000 N   0  0  0  0  0  0  0  0  0  0  0  0
   18.9031   -5.8761    0.0000 O   0  0  0  0  0  0  0  0  0  0  0  0
   16.2010  -10.5559    0.0000 R#  0  0  0  0  0  0  0  0  0  0  0  0
   21.6054   -5.8765    0.0000 C   0  0  0  0  0  0  0  0  0  0  0  0
   21.6050   -7.4366    0.0000 C   0  0  0  0  0  0  0  0  0  0  0  0
   22.9559   -8.2167    0.0000 C   0  0  0  0  0  0  0  0  0  0  0  0
   20.2540   -8.2161    0.0000 N   0  0  0  0  0  0  0  0  0  0  0  0
   24.3070   -7.4372    0.0000 O   0  0  0  0  0  0  0  0  0  0  0  0
   22.9556   -9.7768    0.0000 O   0  0  0  0  0  0  0  0  0  0  0  0
  2  1  1  1  0  0  0
  4  2  1  0  0  0  0
  2  3  1  0  0  0  0
  3  5  2  0  0  0  0
  3 10  1  0  0  0  0
  4  6  1  0  0  0  0
  8  7  1  1  0  0  0
 10  8  1  0  0  0  0
  8  9  1  0  0  0  0
  9 11  2  0  0  0  0
  9 12  1  0  0  0  0
A    6
R1
M  RGP  1   6   1
M  END

and SMILES is C[C@H](N[H])C(=O)N[C@@H](C)C(=O)N[C@@H](C)C(=O)O.C[C@H](N*)C(=O)O
importing into PubChem Sketcher and moving the overlapping atoms gives:

So one of the repeating units is not attached.

Why not? They are exact structures and should be generated.

Please would you change the toolkit to generate the SMILES and molfile from HELM with repeating units?

Discussed with Yohann. Novartis are interested in using repeating units and would prefer this to be fixed.

Retested and the issue is still present.

I cannot reproduce the issue; if I try out the image generation on the WebService side for PEPTIDE1{A.D'2'.C.F}$$$$V2.0, I get the following:

If I generate SMILES instead and put them into the PubChem Sketcher, I get

which results in

Could it be that the re-test happended with an older version of the WebService still in place?

It looks like you are right. When I test on http://<IP_ADDRESS>/WebService/FirstPage.html I get the right structure, but if I use the webeditor on the same server I get disconnected structures.

So, the conclusion is that the webservices are now working correctly, but the webeditor is creating its own structure and it is resulting in disconnected structures.
Reassigning this issue to Tony.

Actually I have retested with more examples and the webservices version works for peptides, but not for CHEM and RNA. Try the examples below:
CHEM1{[Az]'11'}$$$$V2.0
RNA1{R'11'}$$$$V2.0
So both the webeditor and the webservices still need fixing.

Converting these issues into new separate issue logs as there are several things going on. Closing this log.


ISPN-16185: Possible incorrect include in Configuring Infinispan cach…

https://issues.redhat.com/browse/ISPN-16185

Hi @tristantarrant,
Can you please review the PR?
thanks,
ashwin


I Think the UI should be same between ipad and pc

I use ipad pro for moblie manager, but , it's terrible , the ui should change to pc's version,
can you add the ipad support ?

Useful
Info

Versions
Rancher v1.1.0-dev3 Cattle: v0.161.5 UI: v1.1.3

Access
github admin

Orchestration
Cattle

Route
environments.index

Version - master 7/15
Verified fixed


ProPlus activated on way more than 5 computers

One of our customers (corporate E3 license) has activated ProPlus on 10 different computers.
See attached screenshot.
According to all documentation, the limit is supposed to be 5.
Why is she allowed to do this?

Hi @dhoegl, thanks for getting in touch.
I believe that with a corporate E3 license, Office can be installed by a user on 5 PCs or Macs, 5 tablets (Windows, iPad, and Android), and 5 phones, giving a possible total of 15 devices. You can count 2-in-1 Windows devices, such as the Microsoft Surface Pro, as either a PC or a tablet.
More information can be found here: https://products.office.com/en-ie/business/office-365-enterprise-e3-business-software


0 files in total

doesnt do anything when i run it like this:
papyrus compile -nocache -h "C:\Program Files (x86)\Steam\steamapps\common\Skyrim Special Edition\Data\Source\Scripts" -o "../compiled"
Output is:
C:\Users\Kai\Desktop\papyrus-compiler>papyrus compile -nocache -h "C:\Program Files (x86)\Steam\steamapps\common\Skyrim Special Edition\Data\Source\Scripts" -o "../compiled"
used header dirs ['C:\Program Files (x86)\Steam\steamapps\common\Skyrim Special Edition\Data\Source\Scripts']
0 files in total
parse files: 0.001 ms
parse headers files: 0.001 ms
check files: 0.0 ms
gen files: 0.004 ms
finish 1.255 ms
Maybe some Error Messages would be advisable.

Yes, an error message is indeed missing here. Thanks.


Italic comment does not work

Hi, I'm trying out this new version of NvChad config. One immediate thing I noticed is that when I tried to uncomment the lines and enable italic comments in chadrc.lua, it simply did not work :x

@comment, pls add for this hlgroup too


Unmatched image list and downloaded content

I am interested in checking the implementation of this work. However, when I downloaded the folder from Google Drive, I found the downloaded content and the image list is not matching. For example, the 'rp_adanna_rigged_003_ue4' has following:
CityPark_Showcase
    └───Day
        ├───rp_adanna_rigged_003_ue4
        │   └───SKM_MenReadingGlasses_Shape_01
        │       ├───004
        │       │   └───Pulling_A_Rope__7_
        │       │       └───all_data_with_img-256_hm-64_pose-16_npy
        │       ├───019
        │       │   └───Tender_Placement__1_
        │       │       └───all_data_with_img-256_hm-64_pose-16_npy
        │       ├───022
        │       │   └───Left_Strafing_Jump__1_
        │       │       └───all_data_with_img-256_hm-64_pose-16_npy
        │       ├───023
        │       │   └───Silly_Dancing__10_
        │       │       └───all_data_with_img-256_hm-64_pose-16_npy
        │       ├───025
        │       │   ├───Chapa_2
        │       │   │   └───all_data_with_img-256_hm-64_pose-16_npy
        │       │   └───Smash__5_
        │       │       └───all_data_with_img-256_hm-64_pose-16_npy
        │       └───026
        │           ├───Soccer_Header
        │           │   └───all_data_with_img-256_hm-64_pose-16_npy
        │           └───Soccer_Trip
        │               └───all_data_with_img-256_hm-64_pose-16_npy

But the validation set has following:
../../../../../CT/UnrealEgo/static00/UnrealEgoData/CityPark_Showcase/Day/rp_adanna_rigged_003_ue4/SKM_MenReadingGlasses_Shape_01/019/Tender_Placement__1_
../../../../../CT/UnrealEgo/static00/UnrealEgoData/CityPark_Showcase/Day/rp_adanna_rigged_003_ue4/SKM_MenReadingGlasses_Shape_01/023/Swing_Dancing__18_
../../../../../CT/UnrealEgo/static00/UnrealEgoData/CityPark_Showcase/Day/rp_adanna_rigged_003_ue4/SKM_MenReadingGlasses_Shape_01/023/Swing_Dancing__26_
../../../../../CT/UnrealEgo/static00/UnrealEgoData/CityPark_Showcase/Day/rp_adanna_rigged_003_ue4/SKM_MenReadingGlasses_Shape_01/024/Body_Block__12_
../../../../../CT/UnrealEgo/static00/UnrealEgoData/CityPark_Showcase/Day/rp_adanna_rigged_003_ue4/SKM_MenReadingGlasses_Shape_01/026/Soccer_Header

Or the training set's list:
../../../../../CT/UnrealEgo/static00/UnrealEgoData/CityPark_Showcase/Day/rp_adanna_rigged_003_ue4/SKM_MenReadingGlasses_Shape_01/003/Back_Squat__1_
../../../../../CT/UnrealEgo/static00/UnrealEgoData/CityPark_Showcase/Day/rp_adanna_rigged_003_ue4/SKM_MenReadingGlasses_Shape_01/003/Jump_Push_Up__1_
../../../../../CT/UnrealEgo/static00/UnrealEgoData/CityPark_Showcase/Day/rp_adanna_rigged_003_ue4/SKM_MenReadingGlasses_Shape_01/004/Pulling_A_Rope__7_
../../../../../CT/UnrealEgo/static00/UnrealEgoData/CityPark_Showcase/Day/rp_adanna_rigged_003_ue4/SKM_MenReadingGlasses_Shape_01/005/Guitar_Playing__3_
../../../../../CT/UnrealEgo/static00/UnrealEgoData/CityPark_Showcase/Day/rp_adanna_rigged_003_ue4/SKM_MenReadingGlasses_Shape_01/005/Guitar_Playing__25_
../../../../../CT/UnrealEgo/static00/UnrealEgoData/CityPark_Showcase/Day/rp_adanna_rigged_003_ue4/SKM_MenReadingGlasses_Shape_01/010/Looking_Through_Files_Low
../../../../../CT/UnrealEgo/static00/UnrealEgoData/CityPark_Showcase/Day/rp_adanna_rigged_003_ue4/SKM_MenReadingGlasses_Shape_01/017/Blow_A_Kiss
../../../../../CT/UnrealEgo/static00/UnrealEgoData/CityPark_Showcase/Day/rp_adanna_rigged_003_ue4/SKM_MenReadingGlasses_Shape_01/017/Opening__23_
../../../../../CT/UnrealEgo/static00/UnrealEgoData/CityPark_Showcase/Day/rp_adanna_rigged_003_ue4/SKM_MenReadingGlasses_Shape_01/017/Shooting_Gun__4_
../../../../../CT/UnrealEgo/static00/UnrealEgoData/CityPark_Showcase/Day/rp_adanna_rigged_003_ue4/SKM_MenReadingGlasses_Shape_01/021/Standing_Walk_Left
../../../../../CT/UnrealEgo/static00/UnrealEgoData/CityPark_Showcase/Day/rp_adanna_rigged_003_ue4/SKM_MenReadingGlasses_Shape_01/021/Walk_Backwards
../../../../../CT/UnrealEgo/static00/UnrealEgoData/CityPark_Showcase/Day/rp_adanna_rigged_003_ue4/SKM_MenReadingGlasses_Shape_01/022/Left_Strafing_Jump__1_
../../../../../CT/UnrealEgo/static00/UnrealEgoData/CityPark_Showcase/Day/rp_adanna_rigged_003_ue4/SKM_MenReadingGlasses_Shape_01/022/Short_Left_Side_Step
../../../../../CT/UnrealEgo/static00/UnrealEgoData/CityPark_Showcase/Day/rp_adanna_rigged_003_ue4/SKM_MenReadingGlasses_Shape_01/022/Standing_Torch_Walk_Left__3_
../../../../../CT/UnrealEgo/static00/UnrealEgoData/CityPark_Showcase/Day/rp_adanna_rigged_003_ue4/SKM_MenReadingGlasses_Shape_01/023/Brooklyn_Uprock
../../../../../CT/UnrealEgo/static00/UnrealEgoData/CityPark_Showcase/Day/rp_adanna_rigged_003_ue4/SKM_MenReadingGlasses_Shape_01/023/Hip_Hop_Dancing__6_
../../../../../CT/UnrealEgo/static00/UnrealEgoData/CityPark_Showcase/Day/rp_adanna_rigged_003_ue4/SKM_MenReadingGlasses_Shape_01/023/Silly_Dancing__10_
../../../../../CT/UnrealEgo/static00/UnrealEgoData/CityPark_Showcase/Day/rp_adanna_rigged_003_ue4/SKM_MenReadingGlasses_Shape_01/023/Snake_Hip_Hop_Dance__4_
../../../../../CT/UnrealEgo/static00/UnrealEgoData/CityPark_Showcase/Day/rp_adanna_rigged_003_ue4/SKM_MenReadingGlasses_Shape_01/024/Body_Block__3_
../../../../../CT/UnrealEgo/static00/UnrealEgoData/CityPark_Showcase/Day/rp_adanna_rigged_003_ue4/SKM_MenReadingGlasses_Shape_01/024/Livershot_Knockdown__1_
../../../../../CT/UnrealEgo/static00/UnrealEgoData/CityPark_Showcase/Day/rp_adanna_rigged_003_ue4/SKM_MenReadingGlasses_Shape_01/024/Taunt
../../../../../CT/UnrealEgo/static00/UnrealEgoData/CityPark_Showcase/Day/rp_adanna_rigged_003_ue4/SKM_MenReadingGlasses_Shape_01/025/Chapa_2
../../../../../CT/UnrealEgo/static00/UnrealEgoData/CityPark_Showcase/Day/rp_adanna_rigged_003_ue4/SKM_MenReadingGlasses_Shape_01/025/Smash__5_
../../../../../CT/UnrealEgo/static00/UnrealEgoData/CityPark_Showcase/Day/rp_adanna_rigged_003_ue4/SKM_MenReadingGlasses_Shape_01/026/Goalkeeper_Sidestep__3_
../../../../../CT/UnrealEgo/static00/UnrealEgoData/CityPark_Showcase/Day/rp_adanna_rigged_003_ue4/SKM_MenReadingGlasses_Shape_01/026/Soccer_Trip

I would like to know does 'UnrealEgo impl' folder contain all necessary npy files for training or for validation? It seems like the file that we downloaded are missing some files for both cases. Just want to know if this issue only happens on my side. Thanks!

Hi, thank you for your interest in our dataset!
I was able to access all of the dataset from several Google accounts.
Also, as mentioned in the README, you need to modify the lists in the txt files based on your local paths, e.g., (local path)/UnrealEgoData/Lab_Scene/Day/rp_eric_rigged_001_ue4/SKM_MenReadingGlasses_Shape_01/026/Chip.
Here, you don’t need to add /all_data_with_img-256_hm-64_pose-16_npy to the paths.

Thank you for your quick response. I understand that I need to modify the prefix and no need to add the _npy path at the end of the string. However, the issue is that some of my downloaded folders are missing according to the folder list.
May I know what files should be contained in the 'UnrealEgo impl'? Will that cover all the folders listed in training / validation / testing?
I also tried to download both UnrealEgo 02's and UnrealEgoData-impl-01's CityPark_Showcase folders and combined them together, the result is also different:
CityPark_Showcase
└───Day
    ├───rp_adanna_rigged_003_ue4
    │   └───SKM_MenReadingGlasses_Shape_01
    │       ├───004
    │       │   └───Pulling_A_Rope__7_
    │       │       └───json
    │       ├───017
    │       │   ├───Opening__23_
    │       │   │   ├───fisheye_depth_image
    │       │   │   │   ├───camera_left
    │       │   │   │   └───camera_right
    │       │   │   └───fisheye_final_image
    │       │   │       └───camera_right
    │       │   └───Shooting_Gun__4_
    │       │       ├───all_data_with_img-256_hm-64_pose-16_npy
    │       │       └───fisheye_depth_image
    │       │           └───camera_right
    │       ├───021
    │       │   └───Standing_Walk_Left
    │       │       └───fisheye_depth_image
    │       │           └───camera_right
    │       ├───023
    │       │   ├───Swing_Dancing__18_
    │       │   │   └───fisheye_depth_image
    │       │   │       └───camera_right
    │       │   └───Swing_Dancing__26_
    │       │       ├───fisheye_depth_image
    │       │       │   ├───camera_left
    │       │       │   └───camera_right
    │       │       └───json
    │       ├───025
    │       │   └───Smash__5_
    │       │       └───fisheye_depth_image
    │       │           └───camera_left
    │       └───026
    │           ├───Soccer_Header
    │           │   └───all_data_with_img-256_hm-64_pose-16_npy
    │           └───Soccer_Trip
    │               └───all_data_with_img-256_hm-64_pose-16_npy

Very weird result it seems.

Can you please check if the missing dataset is available on Google Drive at first?
Also, are you using wget or gdrive? I realized that they can be used to download a small number of files (up to 50 files or so) so some of the data will be missing.
So, I will split the dataset to a smaller number of zip files so that users can use wget, for instance.
For now, you can download the dataset directly from Google Drive or write some code to access the dataset.

Those missing files are avaible on the Google Drive website, but when I tried to download them, I guess something went wrong in the Google Drive's zipping function.
It seems to be a known issue for Google Drive: https://support.google.com/drive/thread/4142625/download-all-doesn-t-capture-all-files?hl=en
Maybe could you directly upload zip files so that we can download them directly to avoid this bug? Thank you!

Apparently, this bug hasn’t been solved for a long time :)
I’ll upload the zip version as soon as possible.

Hi, I uploaded the zip version of "UnrealEgo impl 1~3". You can just download them to try our implementation now.
I'm also uploading the zip version of other datasets (UnrealEgo 1~6) now so stay tuned.
Please let me know if you encounter any issues.


feat(TestScheduler): add sync-within-subscribe marker

Description:
This PR now adds a sync-within-subscribe marker as described in this comment.
Previous Description:
This PR changes the ColdObservable implementation so that notifications scheduled at frame zero are emitted within subscribe instead of being scheduled for emission at zero milliseconds. See #5523 for a more detailed explanation.
After making this change, there were a whole bunch of tests - a total of 21, IIRC - that needed to be updated, as they depended upon the notifications at frame zero being emitted after subscribe returned. For example, consider this test:
    const a = cold(  '|');
    const asubs =    '(^!)';
    const b = cold(  '-');
    const bsubs =    '(^!)';
    const expected = '|';
    expectObservable(zip(a, b)).toBe(expected);

If the complete notification in a occurs within the subscribe, the subscription to b - asserted by the test - will never occur.
So, in order for the test to pass - and to effect the behaviour it purports to test - the notification needs to be moved off the zero frame, like this:
    const a = cold(  '-|');
    const asubs =    '^!';
    const b = cold(  '--');
    const bsubs =    '^!';
    const expected = '-|';
    expectObservable(zip(a, b)).toBe(expected);

Pretty much all of the changes to the test are like this. The only exception was the test for throttle - and, TBH, I'm not altogether sure what's going on with that one which will pass once the fix in #5749 is merged.
As I mentioned in the issue, there are existing tests that appear to use cold in a manner that expects sync-within-subscribe notifications and there are others that explicitly use of instead of cold.
Whether or not we should make this change, IDK. As I mentioned in the issue, this behaviour could be seen as a quirk. It is, however, pretty confusing as it is at the moment.
Also, this would be a breaking change for anyone dependent upon the cold-observables-are-never-synchronous-within-subscribe behaviour.
Related issue (if exists): #5523

With regards to our tests, I suppose we need to test the "scheduled(0)" and "unscheduled" routes that things can take. But I'm still thinking about this.
Considering that a - is truly an arbitrary measurement of time (even if we call it "1ms" in some tests, think about it, if we're contracting 1ms, or 100ms to happen "synchronously" in our tests, then what's the difference if a - represents a millisecond or an eon?) I suppose that one might argue that testing any delay at all beyond a synchronous emission is really apples to apples -- meaning that if everything in a desired test is scheduler(fn, 0), the test isn't any different if everything is schedule(fn, 100).
So I think this is okay, but it's a bit odd to me. that the first dash is just different now.
I think that we might consider doing this:
expectObservable(of('a', 'b', 'c')).toBe( '(^abc|)'); // true
expectObservable(of('a', 'b', 'c')).toBe('(abc|)'); // false
expectObservable(scheduled('abc', asyncScheduler)).toBe('(abc|)'); // true

Where a grouping with a '^' at the lead means subscription occurred at that frame, and those values are synchronous with that subscription.
I think this even works with situations where we have a subscription defined and emissions are expected to happen synchronously with the subscription:
const source = hot('-----a---b----------c---d---e--');
const shared = source.pipe(shareReplay());
const sub1 = '      ----^-----------!    ';
const exp1 = '      -----a---b-------    ';
const sub2 = '      -----------^------------------!';
const exp2 = '      -----------(^ab)----c---d---e--'; // NOTE THIS LINE

expectObservable(shared, sub1).toBe(exp1);
expectObservable(shared, sub2).toBe(exp2);

What are your thoughts?

What are your thoughts?

Yeah, I like your (^abc) solution. And the fact that it's not breaking - that was my primary concern.
I'll have a look at implementing it later in the week. It'll change this PR from a fix to a feat. After that, I'll have a look through the tests to see if I can find sources that should be synchronous within subscribe. I'm pretty sure there are a few.

With regards to our tests, I suppose we need to test the "scheduled(0)" and "unscheduled" routes that things can take ...

I think it's worth adding tests to verify that subscriptions to sources that complete or error synchronously with subscribe short-circuit the subscription to further sources.
And, yeah, adding the leading - to the tests makes no difference, IMO. They still test the same thing.

@benlesh The (^abc) thing was pretty easy to implement, but it's still going to be a breaking change. There are about 150 tests in the repo that fail because they have expectations that need to be updated to include the synchronous-within-subscribe indicator - e.g.:
const a = cold('  -');
const asubs = '   (^!)';
const expected = '|';
const b: string[] = [];

expectObservable(a.pipe(zipWith(b))).toBe(expected);
expectSubscriptions(a.subscriptions).toBe(asubs);

Needs to become:
const a = cold('  -');
const asubs = '   (^!)';
const expected = '(^|)'; // HERE
const b: string[] = [];

expectObservable(a.pipe(zipWith(b))).toBe(expected);
expectSubscriptions(a.subscriptions).toBe(asubs);

I'm going to leave this for the moment. The breaking nature of this feature means that some tests require several changes - e.g.:
it('should handle a throw closing Observable', () => {
  const e1 = hot('--a--^---b---c---d---e---f---g---h------|');
  const e1subs =      '(^!)                                ';
  const e2 =  cold(   '#');
  const e2subs =      '(^!)                                ';
  const expected =    '(x#)                                ';
  const x = cold(     '#                                   ');
  const values = { x: x };

  const result = e1.pipe(windowWhen(() => e2));

  expectObservable(result).toBe(expected, values);
  expectSubscriptions(e1.subscriptions).toBe(e1subs);
  expectSubscriptions(e2.subscriptions).toBe(e2subs);
});

The x is emitted within subscribe, so it needs the marker.
The # is emitted outside of subscribe, so it needs to be moved out of the group`.
That means the source needs to emit the # on a different frame.
That changes the subscriptions.
The frame upon which # ends up coincides with the frame upon which b is emitted.
So b has to be moved.

it('should handle a throw closing Observable', () => {
  const e1 = hot('--a--^----b---c---d---e---f---g---h------|');
  const e1subs =      '^---!                                ';
  const e2 =  cold(   '----#');
  const e2subs =      '^---!                                ';
  const expected =    '(^x)#                                ';
  const x = cold(     '----#                                ');
  const values = { x: x };

  const result = e1.pipe(windowWhen(() => e2));

  expectObservable(result).toBe(expected, values);
  expectSubscriptions(e1.subscriptions).toBe(e1subs);
  expectSubscriptions(e2.subscriptions).toBe(e2subs);
});

What are your thoughts on this feature now?

It seems like this change is going to have a large impact. While it fixes the TestScheduler, I'm not sure what impact it will have on the rest of the world, on other people's tests, or on other marble testing libraries. We might consider putting this behind some configuration on the TestScheduler itself or holding off for another major. I'm not sure. Perhaps we should discuss it at the next core team meeting?

Yeah, definitely hold off. Also, I have other changes that I'd like to make to the TestScheduler - both of which would make working with this feature a little easier and both would also be breaking. I agree that discussing it at the next meeting would be best. I'll write up my ideas in a HackMD document before the meeting.

Core Team Meeting: Decided to pass on this work for v7... Look at all-new test scheduler in v8.


What is the relationship between ribbon timeout and hystrix timeout in zuul with semaphore isolation

in English:
I config a application.yml in zuul project, as follow
hystrix.command.default.execution.isolation.thread.timeoutInMilliseconds: 5000
ribbon:
  ReadTimeout: 19000
  ConnectTimeout: 19000

then after running the projects
i visit: curl http://xxxx, I find that timeout  is not 5s but 19s, so  hystrix timeout not work, i can not understand, tell me why
in Chinese:
spring cloud zuul1.x中，hystrix的超时和ribbon的超时，两者之间有什么关系吗?
我在zuul网关项目的配置文件中配置如下：
hystrix.command.default.execution.isolation.thread.timeoutInMilliseconds: 5000
ribbon:
ReadTimeout: 19000
ConnectTimeout: 19000

浏览器访问：等19s后连接断掉，提示超时
curl http://localhost:5555/api-a/add?a=1&b=2&accessToken=12
从上可以看出，超时ribbon起了作用，而hystrix没有看到起什么作用。在zuul中hystrix的超时是通过一个启动定时线程池来实现的，而zuul的隔离策略是semphere信号量，对于semphere策略，hystrix的超时似乎没有任何作用？
我使用的spring cloud zuul的版本为1.3.5、Dalston.SR4
根据我debug zuul和hystrix源码和google发现，当隔离策略是thread时，hystrix超时会打断ribbon的超时；而当隔离策略是semphere时，hystrix超时不会打断ribbon的超时，这个为什么呢，不打断的原因是什么呢

@spencergibb first I am so sorry I had not look this in time in order to new year, my WeChat code is yaoyuan5324. I am still puzzled to the question of timeout

@spencergibb If it is possible that i may send you a video about my operated process by wechat, thanks

@holy12345 first I am so sorry I had not look this in time in order to new year, my WeChat code is yaoyuan5324. I am still puzzled to the question of timeout. if it is possible that i may send you a video about my operated process by wechat, thanks


Embed Flutter and App frameworks for add-to-app on iOS

Previously, the iOS Flutter module copied the Flutter.xcframework and created a dummy version of App.framework in the the ephemeral .ios directory, as well as two corresponding podspecs that pointed at these frameworks.  On every compilation of the host app, flutter assemble would create the real App.framework and copy the right Flutter.framework variant into the Xcode BUILT_PRODUCTS_DIR.  On the first build, CocoaPods would then copy/re-codesign/re-strip the frameworks and embed them into the app.
However, since flutter assemble updates the frameworks in BUILT_PRODUCTS_DIR and not the dummy frameworks in the ephemeral directory, on incremental builds CocoaPods would not run its copy script because the timestamp of the dummy ephemeral frameworks did not change.  So the compiled dart code embedded in the app would not be updated, and would be stale until a hot reload.

Stop creating the dummy ephemeral directory frameworks so CocoaPods can find them.  Instead, use the existing tool podhelper scripts that embed the frameworks into the app.  assemble already codesigns, bitcode strips, and debug symbol strips the frameworks, so all that's left it to rsync them to the right place in the app.
Deduplicate engine/plugins logic in the add-to-app podhelper.rb ruby script to use the Flutter SDK flutter_tools/bin/podhelper.rb version of this file to push as much logic as possible into the SDK instead of the module project.
Update the SDK ruby script to use relative paths in places where it had assumed relative location from the Podfile (since now it's being called from host apps, which are located outside the Flutter module).

Fixes https://github.com/flutter/flutter/issues/101979
Probably would have resolved parts of https://github.com/flutter/flutter/issues/94481
Follow-up to https://github.com/flutter/flutter/pull/101943
Pre-launch Checklist

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

If you need help, consider asking for advice on the #hackers-new channel on Discord.

friendly ping @christopherfujino


engine: align WithdrawalRequestV1 with EIP-7002 and consensus spec

There is an inconsistency between the withdrawal request defined in EIP-7002 (see validator_pubkey field and related PR), the consensus spec (see ExecutionLayerWithdrawalRequest), and the execution api.
This PR align the execution api spec WithdrawalRequestV1 with the other specs.
Most ELs currently return it as validatorPublicKey with the exception of Besu which uses validatorPubKey

Do we wanna include this for devnet-1? Might need more visibility on it first, I am not that familiar how you do this on the execution api side but maybe could bring this up in discord and see if there is any opposition to the change


Already exist project

My simple answer is this if there exist better product like app.eraser.io and excail draw why would i even look to your project
convince me that this project is better than those two mentioned above

@AnikethDeb2004  you said absolutely right . First of all this project is to understand how this big things work . The uniqueness of the project is second thing . We are here to make people understand what is open source really . Not just make to work as a single person , but working in a team . There is no need to convince , it is upto you , whether you want to dive into this niche and learn how things work .
You may even compare the code bases , our code is small enough to understand . Well the choice is yours . We are not bounding you .
We love opensource , and we spread it  . That's simple 👩🚀

I am closing it , if you want to discuss more , you may repopen this .


Add Effect entity

[x] Add an Effect entity as something that affects a unit during an specified amount of turns (could last forever).
[ ] Make Effects of the same type stackable.
[x] Make Explode an Effect, not an Ability.

Duplicate of #14