pydPiper cannot connect to Volumio 3.198 HTTP error [Errno -2] Name or service not known

I've been trying to troubleshoot this issue and not having much luck.
I have a hd44780_i2c 16x2 display connected to my RPi4 running Volumio 3.198 and installed pydPiper from cloning the GIT to my PC and installing docker/volumio .sh scripts.
Docker is running and pydPiper service is running but I see the following in the log and nothing on the display:
2022-03-24 22:21:39,823:DEBUG:Starting new HTTP connection (906): audiostreamer.local
2022-03-24 22:21:39,841:WARNING:audiostreamer.local:3000/socket.io [engine.io waiting for connection] HTTPConnectionPool(host='audiostreamer.local', port=3000): Max retries exceeded with url: /socket.io/?EIO=3&transport=polling&t=1648160499821-0 (Caused by NewConnectionError('<urllib3.connection.HTTPConnection object at 0x1625510>: Failed to establish a new connection: [Errno -2] Name or service not known',))
Accessing audiostreamer.local/socket.io/?EIO=3&transport=polling&t=1648160499821-0 via chrome on my windows machine results in a file called "download" downloading with the following text:
ÿ0{"sid":"2nomW53Hw952M9qCAAAD","upgrades":["websocket"],"pingInterval":25000,"pingTimeout":60000}

I get the feeling that Docker is being blocked on port 3000; even thought pydPiper is started with --network=host which should technically open/let it see Volumio on port 3000.
Does anyone have any idea what the issue might be?

I was able to get a bash shell into the docker container and realised the docker couldn't resolve .local after removing .local the service successfully started but no dice getting anything on the 16x2 display as yet. :)


Add rule/option for only allowing let declarations in for ... in for IE11

First: thank you for this plugin, it's pretty useful. I prefer to use the baseline JavaScript for the legaciest browser I support, i.e. IE11. For keeping my  JS fully IE11 compatible I can disable the no-block-scope rule since that is OK most of the time. But it seems that IE11 doesn't like const declarations in for  (const item in items) loops. It'd  be really cool if this plugin added a rule or expanded the options of the block scoping rule to  (dis-)allow this usage of const.  Thanks, again, have a nice day!

It seems you could use this plugin combined with this other one: https://github.com/Volox/eslint-plugin-ie11#supported-rules, would be awesome for all rules to be in one plugin though...

@Sauloxd thanks, that setup works for me.


feat(add comment when create branch): add comment

resolves #2

:tada: This PR is included in version 1.0.0 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:


Suggestion: Parameter type inference in plain functions

Search Terms

is:issue  parameters type inference
is:issue  parameters type inference duck
is:issue  parameters type inference plain function

Suggestion

Have a way to do not need to write parameter types of obvious funcitons in noImplicitAny mode.
May be adding a global directive // @ts-infer-any
Use Cases
I'm working in very strict mode. Then I am forced to write the types in places where it would not be necessary.
Examples
// @ts-infer-any

function f(name) {
    return !!name.match(/data/)
}

function pythagoras(a, b) {
    return Math.sqrt(a * a + b * b);
}

var good = f('hi');
var error = f(42);
// Error: Argument of type '42' is not assignable to parameter with inferred interface {match:(Regex)=>any}.

var good2 = pythagoras(3, 4);
var error2 = pythagoras('3', ['']);
// Error: Argument of type '3' is not assignable to parameter with inferred number.

see it here
Checklist
My suggestion meets these guidelines:

[x] This wouldn't be a breaking change in existing TypeScript/JavaScript code

Because in noImplicitAny theres no parameters without type

[x] This wouldn't change the runtime behavior of existing JavaScript code
[x] This could be implemented without emitting different JS based on the types of the expressions
[x] This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, etc.)
[x] This feature would agree with the rest of TypeScript's Design Goals.

People have asked us hundreds of times why we don't do this; the answer is that it's architecturally impractical to do this in a way that results in stable, performant checking results in anything other than toy programs. See e.g. https://medium.com/flow-type/what-the-flow-team-has-been-up-to-54239c62004f where the flow team has basically abandoned this feature.
The "infer from usage" refactor is available for this purposes.

Thanks @RyanCavanaugh. I apologize for bothering you with this.
These also explains the point:

https://github.com/microsoft/TypeScript/issues/34738
https://www.typescriptlang.org/play/?noImplicitAny=false&e=28#example/infer-from-usage-changes


Convert notes and revisionMetadata fields

No lossiness since original fields are strings, so still 99.7% conversion success
100% successfully imported into mongodb (with removal of a couple of required fields in revisionMetadata in the schema)
Sample notes conversion:
{
   ...
   "notes": "https://new.qq.com/omn/20200215/20200215A0LD4100.html; Contact with other confirmed cases; quarantined",
    "importedCase": {
      "ID": "000-1-10046",
      ...
      "additional_information": "Contact with other confirmed cases; quarantined",
      "notes_for_discussion": "https://new.qq.com/omn/20200215/20200215A0LD4100.html",
      ...
    }
}

Sample revisionMetadata conversion:
{
    ...
    "revisionMetadata": {
      "id": 0,
      "moderator": "TR"
    },
    "importedCase": {
      "ID": "003-40161",
      ...
      "data_moderator_initials": "TR",
      ...
    }
}

 Ingest existing line-list data into MongoDB


Dump of Hierarchy produces confusing results

I'm working on debugging a Hierarchy generator using RoslynPad and have been running into a limitation on the Dump() command.
When I Dump an object that contains multiple levels of data, I seem to only be able to drill down into 4 layers.

After the 4th layer, there is a Children node, but there is no drilldown for it and no indication that there are further values. If I Dump an object deeper into the tree, I can finally see those values.

If this is not a bug with the Dump command and is working as intended, can there be an indicator that there are values but the software can't drill down?

This behavior is by design. Allowing an unlimited depth is impractical because the result is calculated at the moment of the dump, not when you expand (I wanted snapshot semantics). I may add a way to configure the depth (e.g. in a Dump method argument).
Adding an indicator is a good idea.

Thanks for the quick reply. I completely understand on the unlimited depth issue.
To clarify the identifier a little bit, right now it's difficult to determine which of the two is being shown:

'this is an empty list' (Second image, Name file3.txt)
'this is a list with items which can't be drilled down' (First image, Name Folder4)

They both appear as the type name instead of the collection description <enumerable Count: 2>.

I've added an enumeration count even if it doesn't expand. Additionally, you can now control the depth of dumped graphs, e.g. x.Dump(maxDepth: 10).


No module named 'model'

I am facing this problem when trying to run on colab. I would be grateful if you could help me how to solve this.

ModuleNotFoundError                       Traceback (most recent call last)
 in
13 import pytesseract
14 from io import StringIO
---> 15 from model import TableNet
ModuleNotFoundError: No module named 'model'

NOTE: If your import is failing due to a missing package, you can
manually install dependencies using either !pip or !apt.
To view examples of installing some common dependencies, click the
"Open Examples" button below.

I understand where is this confusion. This project was built locally, hence running it colab is not suggested. training and testing scripts are both under "Training" directory. If you are executing Final.ipynb, load all training files in root directory.


MI v1.1 create automation

Issue
Self-service for MI v1.1 create automation using GithubAction.

Does this need to be updated? https://github.com/sourcegraph/deploy-sourcegraph-managed/pull/957/files#r953262371


Docker Image vulnerabilities being reported

I am using mongo 4.4.19, and see some vulnerabilities cropping up during an image scan. Upgrading to 4.4.20 doesn't remove these vulnerabilities. Can you please let me know when we expect to have a fix for GHSA-g2j6-57v7-gm8c and GHSA-m8cg-xc2p-r3fc issues.

CVE-2023-28642 CVE-2023-25809: Since these are both likely being detected because of gosu, I will point you to https://github.com/tianon/gosu/blob/6a1967c98c3d1854dd29f32433f1e0c59b244c5f/SECURITY.md (and this issue leading up to that policy https://github.com/tianon/gosu/issues/104).

This project does not rebuild/release to "fix" CVEs which do not apply to actual builds of gosu.

So, unless those CVEs appear when running govulncheck the gosu binary will not be updated to a newer dependency just to satisfy a scanner.
$ docker run -it --rm golang bash
root@e36259565d3f:/go# go install golang.org/x/vuln/cmd/govulncheck@latest
...
root@e36259565d3f:/go# export GOSU_VERSION=1.16
root@e36259565d3f:/go# export dpkgArch="$(dpkg --print-architecture | awk -F- '{ print $NF }')"
root@e36259565d3f:/go# wget -O /usr/local/bin/gosu "https://github.com/tianon/gosu/releases/download/$GOSU_VERSION/gosu-$dpkgArch"
...
root@e36259565d3f:/go# govulncheck --mode=binary /usr/local/bin/gosu
govulncheck is an experimental tool. Share feedback at https://go.dev/s/govulncheck-feedback.

Using<EMAIL_ADDRESS>with
vulnerability data from https://vuln.go.dev (last modified 2023-04-12 21:45:55 +0000 UTC).

Scanning your binary for known vulnerabilities...
No vulnerabilities found.


Adds Github Actions to build all Oric projects on Github

This PR adds the necessary .yaml files to the project that will trigger Github Actions to build the Oric .DSK files collection whenever a change is made.  With this PR, devs interested in the 8bit Unity project can easily clone the repo, make their own modifications/tweaks to the onboard sample projects, and get a resulting .DSK file ready for use in the Oric, without having to have access to their own Windows build host, or set it up for development, etc.
Please note that 8bit-Unity was originally set up before Github made the recent change that 'main' is the head branch, and it therefore has a 'master' branch - Github Actions run only on a branch named 'main', which is now the default branch when a new repo is created on Github.
Therefore in order for these actions to work, you would have to add a 'main' branch upstream to the main 8bit-Unity repo - which is advised, anyway, as 'main' is now the standard convention.  This should be fixed before promoting these Github Actions as being available to other devs.
Note that these actions produce .DSK files that can be easily downloaded by other devs.
EDIT: ALSO, it was necessary to remove the "oricutron.exe" callout in each of the build/*.bat files, as this is obviously not going to work on a headless build hosted on Github.
EDIT:  I have not included the other platforms in this pull request - but will do so, as soon as it is confirmed working for the Oric builds, first.  Also, there are individual actions per project/per platform, so that these actions can be retriggered specifically for the sample project of interest.

Please note: you won't see these actions run until there is a 'main' branch in the repo - also, its possible that the workflows need to be enabled manually in the Github interface - not sure about that.

Okay, Roger that.

I don't see it as an issue - we don't have a huge backlog of PR's against a branch named master, there are no draft releases, etc.  Best is to just jump over to the new standard now before we get further devs interested, anyway ..

Okay, Roger that.

I don't see it as an issue - we don't have a huge backlog of PR's against a branch named master.

Please also note - the actions won't work until you activate them.  If you need help with this, we can meet on Discord again ..

Thanks for the heads-up.


Microsoft store is not closing

when i open microsoft store using open() method it works but when i try close() method to close microsoft store it show microsoft is not running even if it is running everytime.
it has the same problem with winrar,microsoft to do also

If you add exception manually like this:
from AppOpener import close
import pygetwindow as gw

def close_ms_store():
    try:
        ms_store_windows = gw.getWindowsWithTitle("Microsoft Store")
        if ms_store_windows:
            for window in ms_store_windows:
                if "Microsoft Store" in window.title:
                    window.close()
            print("Microsoft Store closed successfully.")
        else:
            print("Microsoft Store window not found.")
    except Exception as e:
        print(f"Error: {e}")

try:
    close("Microsoft Store", throw_error=True)
except:
    close_ms_store()

Note: pip install PyGetWindow
You may make pull request integrating this into AppOpener. If not, don't worry next version will fix this 👍(it will take time, until use above method)


[WIP] add support for octree labels

Description
This PR will supersede #2392 by adding support for octree labels. In order to get the labels working we still have our pesky raw_to_displayed function (renamed image_converter inside the octree). Whereas in #2392 this wasn't getting called at all, now this function gets called, but it is getting called inside the main thread after a chunk arrives from the worker thread. This leads to really bad performance as the function is slow!
One option would be to move it to the worker thread, another option would be to call the function on the entire array using dask map_blocks, and then compute will get triggered in the worker thread for us, or we wait until all of this can happen on the GPU and we can drop the raw_to_displayed entirely.
Curious @jni @DragaDoncila what you recommend as a next step.
I'll also note in testing this PR I had some problems with multiple multiscale layers which I'll look into elsewhere.
Type of change

[ ] Bug-fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
[ ] This change requires a documentation update

References

How has this been tested?

[ ] example: the test suite for my feature covers cases x, y, and z
[ ] example: all tests pass with my change

Final checklist:

[ ] My PR is the minimum possible work for the desired functionality
[ ] I have commented my code, particularly in hard-to-understand areas
[ ] I have made corresponding changes to the documentation
[ ] I have added tests that prove my fix is effective or that my feature works

Just to note that this is the example I'm working with right now -
file_name = 'data/camelyon16/tumor_001.zarr'
pyramid = [da.from_zarr(file_name + '/' + str(i)) for i in range(10)]

def theshold_block(block):
    return block[:, :, 0] > 220

segmented = [ar.map_blocks(theshold_block, drop_axis=2, chunks=ar.chunksize[:-1], dtype=np.int)[:ar.shape[0], :ar.shape[1]] for ar in pyramid]

# create an empty viewer
viewer = napari.Viewer()

# add the pyramid
# viewer.add_image(pyramid, name='slide', multiscale=True)
viewer.add_labels(segmented, name='thresholded')
napari.run()

If I turn off the image_converter it's actually still slow, so I should make myself a labels zarr that i can load in to compare.
I'm wondering if there might be more we can do, with calling dask.compute to speed things up too, but that is maybe separate ... i'll look into all this more!

Ok, I think this is ready for review now @jni. It puts the raw to displayed conversion in the vispy visual which means that it happens in the main thread.
Right now painting doesn't really work because the tiles are cached and so don't update. I can work on that in a follow up PR, but it would be good to merge this one first!


Is there a way to bind events to non-Elements?

HTMLMediaElement does not expose an event for when a track is changed, HTMLMediaElement.textTracks does. This event does not bubble. Assuming I have something like this:
{{if video}}
  <video controls autoplay>
    <source src="videos/{{video.src}}" type="video/mp4">
    {{#each video.subs as sub}}
      <track kind="subtitles" src="subtitles/{{sub.src}}">
    {{/each}}
  </video>
{{/if}}

and
ractive.set('video', {
  src: "example.mp4",
  subs: [
    { src: "example1.vtt" },
    { src: "example2.vtt" },
  ],
})

What would be the most natural way to bind change on the .textTracks property of the video element? Currently, my workaround is to place logic where the video variable changes, but this is not at all elegant:
const oldVideo = ractive.get('video')
ractive.set('video', video)
.then(() => {
  if (video && !oldVideo) {
    document.queryElement('video').textTracks.addEventListener('change', textTrackChangeHandler)
  }
})

I think there are a few ways to handle this:

make a component that wraps the video element and installs a listener in the render event that fires a component event so that you can install a trackchange (or whatever name suits) listener on the component
a little lighter weight - add a decorator to the video element that installs the listener and raises a trackchange event on the element
slightly prettier, still light weight, but considerably more complicated - add a macro that does a sort of combo of 1 and 2

If you have a working example on the playground or a jsfiddle-ish place somewhere that I can play with, I'd be happy to take a stab at helping you with a solution.

Thank you, your hints helped; though I must say I only understood enough for #1: https://codepen.io/amadanmath/pen/bGPaagB
For #2, I am not sure how often update would be run. For #3, I haven't dealt with macros at all yet.

The docs on decorators and macros really aren't great, which is unfortunate because they can do some super cool and useful things. Nothing is jumping out as a way to update that pen without me having an account, so here's a decorator version:
function cctracked(node) {
  if (node.nodeName === 'VIDEO') {
    const ctx = this.getContext(node);
    const listener = ev => ctx.raise('trackchange', {}, ev.target, Array.prototype.find.call(ev.target, t => t.mode === 'showing'));
    node.textTracks.addEventListener('change', listener);
    return {
      update() {},
      teardown() {
        node.textTracks.removeEventListener('change', listener);
      },
    };
  } else {
    console.warn('cctracked decorator called on non-video element');
    return { teardown() {} };
  }
}

// I'll just register it globally, but this could be an init option
Ractive.decorators.cctracked = cctracked;

The update function doesn't really matter because no params are being passed to the decorator, so it basically lives and dies with the video element. You could change the raise to have the values in the @event data or swap the order on the positional args or whatever fits your case best. Here's the usage, where I set samplevid in the root data to the video const in the setup:
<button on-click="@.set('video2', video2 ? undefined : samplevid)">Toggle Video2</button>
{{#if video2}}

Selected subs: {{subtitle2 || 'None'}}

  <video controls as-cctracked on-trackchange="@.set('subtitle2', $2.label || 'None')">
    <source src="{{video2.mp4}}" type="video/mp4">
    {{#each video2.subs as sub}}
      <track kind="subtitles" label="{{sub.label}}" src="{{sub.vtt}}" default>
    {{/each}}
  </video>
{{/if}}

The benefit to the decorator is that it doesn't have to spin up a whole new ractive instance to do its thing, so it's much less resource intensive. A macro lets you dynamically generate and interact with whatever template you want based on the context it is called in, but I think the decorator probably fits this scenario a little better and less magically than a macro.


Unable to manually type a negative value in the input

Hey, perhaps I'm doing something wrong, here is my configuration
<NumericInput
    ref="offsetLeft"
    min={-100}
    max={100}
    step={1}
    onChange={this.setLabelLeftOffset}
    value={this.state.offsetLeft}
    size={4}
    style={{
        input: {
            marginRight: 3,
            paddingRight: 4,
            textAlign: 'right',
        },
        btnUp: {
            display: 'none',
        },
        btnDown: {
            display: 'none',
        },
    }}
/>

I'm trying to type a negative value inside the input starting by the character - (minus), but it does not register. I'm only allowed to go to the negative value if I use the arrow down or if a number is already typed.

I forked it and fixed it for you in 2.0.9. This isn't on NPM, so you'll have to target the specific git hash in your package.json:
"react-numeric-input": "https://github.com/shahyar/react-numeric-input.git#b01f1f9"
Only code change to be aware of is that because you pass value={this.state.offsetLeft}, which you presumably set in onChange={this.setLabelLeftOffset}, make sure you store the second argument of onChange(valueAsNumber, valueAsString), since valueAsNumber will drop the prefixed +, -, and ..
TU ES BON!!

Amazing! 💃

This should be fixed in 2.0.9.


Upgrade from 1.23 to 1.24 incomplete

Is this the right place to submit this?

[X] This is not a security vulnerability or a crashing bug
[X] This is not a question about how to use Istio

Bug Description
We are running version 1.23.2 of Istio and we have two ingress-gateways installed. We built our operator manifest for installation. When we tried to upgrade to 1.24.0, the installation never completed and it got stuck at installing the second gateway which has deployment and service overlay. So we ended up with one gateway updated to 1.24 and the other is still on 1.23. No debug logs showed me why it was stuck. Please advise.
Version
❯ istioctl version
client version: 1.24.0
istiod version: 1.23.2
istiod version: 1.24.0
data plane version: 1.23.2 (2 proxies), 1.24.0 (26 proxies)
> ❯ kubectl version
Client Version: v1.31.1
Kustomize Version: v5.4.2
Server Version: v1.31.2-eks-7f9249a

Additional Information
No response

Could you provide some details about how you were trying to perform the upgrade? Did you attempt an in-place upgrade or revisioned? Is it possible to provide the IOP resources you used? Did one of your gateways not start successfully or did it come up but the installation didn't seem to correctly detect it?

@ilrudie We used Canary upgrade and we installed 1.24 alongside with 1.23. Both ingress-gateways camp up, but the external-ingress-gateway didn't upgrade. I checked this GW's deployment and service, and they are still on version 1.23. Below is the operator file we use for installation. The installation stuck at ingress-gateway installed:
This will install the Istio 1.24.0 profile "default" into the cluster. Proceed? (y/N) y
✔ Istio core installed ⛵
✔ Istiod installed 🧠
✔ CNI installed 🪢
✔ Ingress gateways installed 🛬

^C

apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
metadata:
namespace: istio-system
name: istiocontrolplane
spec:
revision: 1-24-0
profile: default
components:
cni:
enabled: true
k8s:
affinity:
nodeAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
nodeSelectorTerms:
- matchExpressions:
- key: eks.amazonaws.com/compute-type
operator: NotIn
values:
- fargate
pilot:
  k8s:
    serviceAnnotations:
      ad.datadoghq.com/discovery.check_names: '["istio"]'
      ad.datadoghq.com/discovery.init_configs: '[{}]'
      ad.datadoghq.com/discovery.instances: |
          [
            {
              "cluster_check": true,
              "istiod_endpoint": "http://%%host%%:15014/metrics",
              "use_openmetrics": "true"
              "exclude_labels": [
                "source_version",
                "destination_version",
                "source_canonical_revision",
                "destination_canonical_revision",
                "source_principal",
                "destination_principal",
                "source_cluster",
                "destination_cluster",
                "source_canonical_service",
                "destination_canonical_service",
                "source_workload_namespace",
                "destination_workload_namespace",
                "request_protocol",
                "connection_security_policy"
              ]
            }
          ]

ingressGateways:
  - name: istio-ingressgateway
    enabled: true
    label:
      istio: istio-ingressgateway
    k8s:
      overlays:
        - kind: Service
          name: istio-ingressgateway
          patches:
            # Set a expected nodePort to enable ALB ingress
            - path: spec.ports.[name:status-port].nodePort
              value: 30021
            - path: spec.ports.[name:http2].nodePort
              value: 30080
            - path: spec.ports.[name:https].nodePort
              value: 30443
  - name: istio-external-ingressgateway
    enabled: true
    label:
      istio: istio-external-ingressgateway
    k8s:
      overlays:
        - kind: Deployment
          name: istio-external-ingressgateway
          patches:
            - path: metadata.labels.app
              value: istio-external-ingressgateway
            - path: metadata.labels.istio
              value: external-ingressgateway
            - path: spec.selector.matchLabels.app
              value: istio-external-ingressgateway
            - path: spec.selector.matchLabels.istio
              value: external-ingressgateway
            - path: spec.template.metadata.labels.app
              value: istio-external-ingressgateway
            - path: spec.template.metadata.labels.istio
              value: external-ingressgateway
        - kind: Service
          name: istio-external-ingressgateway
          patches:
            - path: metadata.labels.app
              value: istio-external-ingressgateway
            - path: metadata.labels.istio
              value: external-ingressgateway
            - path: spec.selector.app
              value: istio-external-ingressgateway
            - path: spec.selector.istio
              value: external-ingressgateway
            # Set a expected nodePort to enable ALB ingress
            - path: spec.ports.[name:status-port].nodePort
              value: 31021
            - path: spec.ports.[name:http2].nodePort
              value: 31080
            - path: spec.ports.[name:https].nodePort
              value: 31443

values:
global:
meshID: dev
multiCluster:
clusterName: dev-kubernetes-west
network: dev
gateways:
  istio-ingressgateway:
    autoscaleEnabled: true
    type: NodePort
    name: istio-ingressgateway
    env: {}
    secretVolumes:
      - name: ingressgateway-certs
        secretName: istio-ingressgateway-certs
        mountPath: /etc/istio/ingressgateway-certs
      - name: ingressgateway-ca-certs
        secretName: istio-ingressgateway-ca-certs
        mountPath: /etc/istio/ingressgateway-ca-certs
  istio-ingressgateway:
    autoscaleEnabled: true
    type: NodePort
    name: istio-external-ingressgateway
    env: {}
    secretVolumes:
      - name: ingressgateway-certs
        secretName: istio-ingressgateway-certs
        mountPath: /etc/istio/ingressgateway-certs
      - name: ingressgateway-ca-certs
        secretName: istio-ingressgateway-ca-certs
        mountPath: /etc/istio/ingressgateway-ca-certs

Thanks, can repro in KinD with a simple $ istioctl install -f sample-iop.yaml -y where sample-iop.yaml is the file provided above. No need to even update, regular install hangs.

99% sure I see the issue, building a new istioctl with the fix locally and then will file a PR if it works

@ilrudie Correct, i observed the same hanging behavior for a fresh installation in a different cluster. Btw, we have been using the same operator file for previous versions.

gotcha, yeah I'm pretty sure it's a bug in istioctl but it looks like it is already fixed on the tip of master. just going to try to ID the PR which fixed it and make sure it has been cherry-picked

actually I can repro on tip of master too, will dig into it more tomorrow and try to figure it out

It's a concurrency issue in the install logic. I have a code fix I will PR and will try to get it into 1.24.1 which is being planned now.

#53930 merges this fix into our 1.24 branch so the fix will make it into 1.24.1

Istio 1.24.1 has been released!


add a Tags input

One use case is for example configuring the list of stopwords for LLMs
Also renamed "SelectInput" to "Select" as they are exposed throught "input_widget"
Moved the ChatSettings in a separate file to enable using the input widgets outside of the chat settings

Looks great! I like the Tags Input addition!


Support for non-OpenAI models?

Thanks for making this crate, it seems very useful :)
Would it be possible to make it work for non-OpenAI models (e.g. Claude 3.5 Sonnet), and maybe even integrate with https://crates.io/crates/genai ?

Hi @Boscop I will take a look at trying to get the anthropic models as part of the library soon. Can I just confirm that this requirement would be via Anthopic's API and not something else like Amazon Bedrock ?

@JackMatthewRimmer Yes, via Anthropic API :)
Thanks 🙏

Also I'm interested in using embedding models of VoyageAI and MixedBread :)

@Boscop I've closed this issue and Anthropic will be part of the next release. If there's anything else that you have as a feature request please could you raise separate tickets for those

Ok thanks :)


UnexpectedTracerError when enabling EQX_ON_ERROR=breakpoint

While working on https://github.com/patrick-kidger/optimistix/pull/71 I got an XlaRuntimeError in which the error message suggested to turn EQX_ON_ERROR=breakpoint. However, when I do that, many tests, even ones that didn't fail before, start failing with  UnexpectedTracerError.
Steps to reproduce

Set envvar EQX_ON_ERROR=breakpoint
Run test_minimise tests.

I suspect you also need to set EQX_ON_ERROR_BREAKPOINT_FRAMES; see also the docs at https://docs.kidger.site/equinox/api/errors/#equinox.error_if. This is all to work around a known JAX bug, which is likely what you're bumping into.
This is something I've already improevd for the next release. EQX_ON_ERROR_BREAKPOINT_FRAMES will be set to 1 by default (so that this error doesn't trigger at all, even if you can't navigate the stack), and I've added a lot of extra printout when you open the debugger, better instructing you what to do.


Make dump stack great

https://github.com/docker/containerd/blob/master/cmd/containerd/main.go#L187
This provides useful information but the output is horrible and needs to be processed to make it able to be read.  Lets find a way to output this in either a machine parse-able format or human readable because right now its either.

The output is only horrible when it's not displayed on a terminal if I'm not mistaken, correct?

Yes, if tty then output is readable; otherwise if using something like 2>&1 | tee /tmp/cntrd.log the stored logfile has embedded \n and \t sequences instead of LF/CR or TAB for the stacktrace dump. This is actually true with Docker daemon logging as well, when diverted to a file or system log.
I can look into why; maybe something with the way sirupsen/logrus is handling this byte content -> string when no tty?

I think the common usecase is to log this to a file or sent is in a bug report so we should optimize for this.  Getting the log from a daemon vary rarely involves a TTY at all.

I think it would be good to just focus on the debugging and reporting usecase.  Maybe SIGUSR1 will jump out a file in /var/lib/container/dumps or whatever that is formatted like so:
{
    "version": "1.0.0",
    "commit": "blablalblabla",
    "stack: [
        {},{}
    ]
}

The ctr command line could output these in an human readable format or you could upload it and attach it to an issue and we have all the information that you need to debug a problem in the system.

Any reason not to do this via pprof?

By the way, this is a sirupsen/logrus conscious choice: using %q with fmt on the string, if it finds any non-printables in the string being logged in non-tty mode. Simple test to verify as well as showing fmt with %s and %q methods has the same issue:
package main

import (
	"fmt"

	log "github.com/sirupsen/logrus"
)

const (
	mlstring = `This is a multi-line
string that continues on for
several lines`
)

func main() {
	log.SetLevel(log.DebugLevel)
	log.Debugf("String: %s", mlstring)
	fmt.Printf("FMT percent-s: %s", mlstring)
	fmt.Printf("FMT percent-q: %q", mlstring)
}

@stevvooe the use case seems different than a user of pprof, although there may be some overlap. I think the simplicity of a SIGUSR1 to a daemon and get a stackdump immediately has been very useful to me with our Docker deployments.
@crosbymichael I do like the idea of a stored dump in a separate file which can be collected with other data for debug of a specific instance. I'll see if I can draft that up in a PR.

We moved to storing the dump in a file in docker/docker. Also added (limited) spew debugging in a separate file as well if --debug is set on the daemon.

@estesp @cpuguy83 I really don't understand why you would built a new json format and signal handler when it is just built in, works and supports profiling, blocking profiles and goroutines dumps with a well-documented API.

@stevvooe On docker/docker primarily because the pprof endpoints are not enabled unless debug mode is on, and it's easy to ask a sysadmin to send a signal to the running process and collect the output and doesn't require any extra tooling.
I'm not saying that this is an issue for containerd, just that's a motive for docker/docker.
There's no new json format or anything, just the normal stuck dump... used to go straight to stderr which can change format depending on how logrus is setup, now it goes to a file and is always the same format.
I know also the metrics endpoint exposes some of this go runtime data now as well, which is extremely helpful.

@cpuguy83 We can make sure that containerd doesn't make the same mistakes in exposing its endpoints as docker. The main problem is that we are building a completely different world without any tool support when we don't recognize the usefulness of pprof for this exact case.

@stevvooe the current Docker daemon approach makes a lot of sense to me--pprof is available and very useful for many debug scenarios. I don't think offering an ability to dump stack to file replaces or reduces the validity of promoting the use of pprof for its rich capability set.
What I think is quite different is expecting that every production deployment scenario (of which I think we all hope and assume containerd will be one deployed component) will allow remote connection to a specific port in a production environment, or ignoring whether security rules will allow it, the potential complexity in complicated networking setups. Simply asking an admin to gather a specific log file from the system seems to be a reasonably accepted admin pattern, and offering a way to do that for containerd similar to other components seems worthwhile.
I personally think we can skirt the need for any new JSON format for this dump file, given we can simply name the file with appropriate metadata in the filename (pid, datetime stamp, executable-name + version identifier).

@estesp It sounds like the issue is access. Why don't we feed this to the upstream Go developers, rather than reimplementing this in every project?

How about we just use pprof and build a ctr command line that will generate a nice report for this?  We still need something that people can post in a github issue when they have a hard to find bug or issue.

@crosbymichael I love that suggestion.

If someone would like to implement this it would help out?


Updating Firestore encrypted key.

Generated password / passphrase via:
$ openssl rand -base64 48

Then used it to encrypt the keyfile via:
$ rm -f firestore/tests/credentials.json.enc
$ openssl aes-256-cbc -salt -a \
>   -in path/to/keyfile.json \
>   -out firestore/tests/credentials.json.enc

Need this to go in, currently causing a failure because I updated the env. variables:
https://circleci.com/gh/GoogleCloudPlatform/google-cloud-python/3601

LGTM

NOTE: This failed on first run. I am going to change the value of FIRESTORE_APPLICATION_CREDENTIALS from firestore/tests/credentials.json to /var/code/gcp/firestore/tests/credentials.json and re-run.

Fingers crossed on the re-build: https://circleci.com/gh/GoogleCloudPlatform/google-cloud-python/3603


record.start() returns child process object

this fixes #19
I need this ability to detect when an error occurs (for example, the microphone is unplugged.) Being able to attach to stderr enables determining if the process closed normally or errored.

I would prefer emitting an error event when sox writes something to stderr instead of changing the public interface; this would otherwise require a major version bump.
see https://github.com/gillesdemey/node-record-lpcm16/issues/19#issuecomment-297541840


Kubernetes core-dns and calico-kube-controllers pods do not start up because calico plugin cannot be found

I set up a Kuberenetes Cluster using Kubeadm and after that I installed Calico for self-managed on premise deployments (https://docs.tigera.io/calico/latest/getting-started/kubernetes/self-managed-onprem/onpremises)
Expected Behavior

The cluster should start up and use calico as the networking plugin.
Current Behavior

The coredns and calico-kube-controllers pods don't start up and stay in the "ContainerCreating" state.
The following errors show up in the /var/log/kubelet/kubelet.log file:
E1013 14:57:10.206107    2386 kuberuntime_manager.go:1479] "Failed to stop sandbox" podSandboxID={"Type":"containerd","ID":"8697dcd4338aa6452c88508e3b46888244111ac05d8d569e59dcc4062b4e8775"}
E1013 14:57:10.206130    2386 kuberuntime_manager.go:1079] "killPodWithSyncResult failed" err="failed to \"KillPodSandbox\" for \"3b02d395-2e06-4bcb-946d-f67ab3f1edf3\" with KillPodSandboxError: \"rpc error: code = Unknown desc = failed to destroy network for sandbox \\\"8697dcd4338aa6452c88508e3b46888244111ac05d8d569e59dcc4062b4e8775\\\": plugin type=\\\"calico\\\" failed (delete): failed to find plugin \\\"calico\\\" in path [/usr/libexec/cni]\""
E1013 14:57:10.206146    2386 pod_workers.go:1301] "Error syncing pod, skipping" err="failed to \"KillPodSandbox\" for \"3b02d395-2e06-4bcb-946d-f67ab3f1edf3\" with KillPodSandboxError: \"rpc error: code = Unknown desc = failed to destroy network for sandbox \\\"8697dcd4338aa6452c88508e3b46888244111ac05d8d569e59dcc4062b4e8775\\\": plugin type=\\\"calico\\\" failed (delete): failed to find plugin \\\"calico\\\" in path [/usr/libexec/cni]\"" pod="calico-system/csi-node-driver-khvcm" podUID="3b02d395-2e06-4bcb-946d-f67ab3f1edf3"

Possible Solution

Somehow it tries to find the calico plugin inside the /usr/libexec/cni folder, but it is located inside /opt/cni/bin.
Do I have to reconfigure anything?
Steps to Reproduce (for bugs)

Setup a Kubernetes cluster using kubeadm
Install calico for self-managed on premise deployments

Context

I'm trying to setup a kubernetes cluster using calico for network management
Your Environment

Calico version: 3.28.2
Calico dataplane (iptables, windows etc.): iptables
Orchestrator version (e.g. kubernetes, mesos, rkt): kubernetes
Operating System and version: Alpine 3.13.12
Kubectl, Kubeadm and Kubelet packages where pulled from the Alpine edge branch, as they where not included in the 3.13 branch

I just tested it with Alpine 3.20 and it does still not work

Copying the calico and calico-ipam plugins from the opt folder to the /usr/libexec/cni solves all issues and the pods start just fine.
However, I still think that this is not as it should be. If I understood correctly it should "just work"? Any Ideas what could have went wrong in the installation? I already had a hart time finding anything cni - kubernetes related and I did not find anything about my Issue.

Hi @Placeblock, what container runtime are you using? You might have to make changes to the default CNI binary path for your container runtime.

Copying the calico and calico-ipam plugins from the /opt/cni/bin directory to the /usr/libexec/cni directory solves all issues and the pods start just fine.

Yep, sounds likely that your cluster configuration is just looking in a different place for the binaries than Calico is configured to place them. Different platforms / installers have different CNI configurations.
How are you installing Calico? the tigera/operator has some concept of platform, so is able to modify this path based on the installer (to a degree).
If you're installing with calico.yaml then you need to make sure your install path in the manifest matches the location your cluster expects CNI plugins to be installed.


Fix one-liners args access

These two one-liners were accessing the args struct members without dereferencing the pointer first, causing errors like
stdin:1:39-49: ERROR: Can not access field 'bytes' on type '(ctx) struct _tracepoint_block_block_rq_issue *'. Try dereferencing it first, or using '->'
Checklist

[x] Language changes are updated in man/adoc/bpftrace.adoc and if needed in docs/reference_guide.md
[x] User-visible and non-trivial changes updated in CHANGELOG.md
[x] The new behaviour is covered by tests
There is no new behaviour, this is just documentation

This is not a bug, it's a feature. Since #2578, it is possible and recommended to treat args as a structure instead of a pointer. The errors that you observed cannot be reproduced on the latest master, you were probably trying the one-liners with the system installed bpftrace.
@mmarchini are you ok if we revert this patch?

oh yeah, i was using an older version of bpftrace when i tested it. my bad, #2655 will revert it


extension

Ready for your review @bobholt. This adds extension capabilities to the controller only. I'm not supporting customizing the constructor/static props via extend({...]) here... I think we should recommend using ES6 if users want real class-like behavior. Thoughts?

I think that's fine since it's probably a limited use case, but telling the general public to use ES6 even now still feels a little like telling them to use CoffeeScript 2 years ago (but I know, standards, future, etc).
:+1: ship it.

K. If it becomes a real issue with implementations we can always bring in backbone-style extends without breaking backwards compat.


feat(analyzer): add rules regarding model name suffixes

add four rules checking the suffixes of model names
upgrade Roslyn to latest version since new rules require some API
minor refactor existing codes
add test cases for the new rules

resolve #6905

preview pr on azure-sdk-for-net: https://github.com/Azure/azure-sdk-for-net/pull/38560
@m-nash ^^

Changes since last review:

replace List and Join with StringBuilder
adopt ArrayPool to collect namespaces
merge latest main branch
extract analyzer descriptors to align with other analyzers


Add Homebrew installation info to README.md

Due to the successful merge of https://github.com/Homebrew/homebrew-core/pull/104762, xdg-ninja is now a part of homebrew/core and can now be installed by running:
brew install xdg-ninja

This pull request adds information on installing xdg-ninja with Homebrew to README.md.

Very cool, thank you so much!


Select first slug by default

Select the first slug by default on page load.

Also discuss the policy on
Documents:
  - Minio Server:

  - Minio Client:
      - Minio Client Quick Start Guide:
        Link: https://raw.githubusercontent.com/minio/mc/master/README.md

What we have today : https://domain.com/docs/index.html#<slug_name>
What we actually want : https://domain.com/docs/


narrow: bugfix: Update stream list height after rendering completes.

When switching from Private Messages narrow to
All messages narrow, stream list max-height was not
correctly updated. Stream list max-height was calculated
before new height were updated by browser for
All message narrow.
Inshort:
Stream list max-height was being updated before the browser could
render height for #global_filters. Calling resize after narrow
removes this issue.
czo discussion: https://chat.zulip.org/#narrow/stream/6-frontend/topic/Streams.20list.20glitch

OK, this makes sense to me, merged, thanks @amanagr!


Add REs to Nimble Crawl

Closes #7491

This only suppresses the penalty, but abilities that fire off on off-guard targets would still be active, like sneak attack.

I can't see a way to suppress an entire condition, so I'm closing this for now as not actionable.


test: update snapshots

Another day, another vulnerability

You're probably thinking of #1071 😅

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 65.88%. Comparing base (e619fcc) to head (31949d5).
Report is 1 commits behind head on main.

Additional details and impacted files
@@            Coverage Diff             @@
##             main    #1079      +/-   ##
==========================================
+ Coverage   65.32%   65.88%   +0.56%
==========================================
  Files         150      150
  Lines       12529     9716    -2813
==========================================
- Hits         8184     6401    -1783
+ Misses       3884     2853    -1031
- Partials      461      462       +1

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.

could be!


[Bug] Operator crash on memory allocation

🐛 Bug Report
Operator was running and suddenly core dumped with
memory allocation of<PHONE_NUMBER>9829019192 bytes failed
Many of these messages preceeded the crash:
2022-01-07T10:17:10.720042Z  WARN snarkos::network::operator: [PoolResponse] PoSW proof verification failed
2022-01-07T10:17:10.752415Z  WARN snarkos::network::operator: [PoolResponse] PoSW proof verification failed
2022-01-07T10:17:10.785095Z  WARN snarkos::network::operator: [PoolResponse] PoSW proof verification failed
2022-01-07T10:17:10.826163Z  WARN snarkos::network::operator: [PoolResponse] PoSW proof verification failed
2022-01-07T10:17:10.861617Z  WARN snarkos::network::operator: [PoolResponse] PoSW proof verification failed

Steps to Reproduce
Run Operator with 5 provers.
Your Environment
rustc 1.57.0 (f1edd0429 2021-11-29)
Ubuntu 20.04 LTS

Same here.

This is now fixed in snarkVM's testnet3 branch.


Add summary report to diagnostic bundle

This PR add new state Failed to diagnostics bundles. And use this state in report.json to indicate if bundle was successfully generated on specific node. Report is included in diagnostic bundle.

Codecov Report

Merging #134 into master will increase coverage by 0.27%.
The diff coverage is 69.56%.

@@            Coverage Diff             @@
##           master     #134      +/-   ##
==========================================
+ Coverage   65.14%   65.42%   +0.27%
==========================================
  Files          30       30
  Lines        2855     2863       +8
==========================================
+ Hits         1860     1873      +13
+ Misses        805      799       -6
- Partials      190      191       +1

Impacted Files
Coverage Δ

api/rest/status.go
85.71% <ø> (ø)
:arrow_up:

api/rest/coordinator.go
81.69% <69.56%> (+4.82%)
:arrow_up:

Continue to review full report at Codecov.

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

@drewvanstone I just used this mocking approach with a difference I do not check if function was invoked

:wave: @makkes  Can you review, please?


Most effective parameter for finetuning

Hello, is there any table that should the effective parameter configuration while training for better performance?
I am talking about these parameter -:
--learning_rate 1e-5 \
--fp16 \
--num_train_epochs 5 \
--per_device_train_batch_size 8 \
--per_device_eval_batch_size 8 \
--dataloader_drop_last True \
--normlized True \
--temperature 0.02 \
--query_max_len 64 \
--passage_max_len 512 \
--train_group_size 2 \
--negatives_cross_device \
--logging_steps 10 \

Also, I have observed that keeping the per_device_train_batch_size 1, gives the final train_loss less compared to keeping it per_device_train_batch_size as 8

For some suggestions, you can refer to https://github.com/FlagOpen/FlagEmbedding/tree/master/examples/finetune#3-train. The most important arguments are per_device_train_batch_size, train_group_size .
We use in-batch negatives strategy, where a larger per_device_train_batch_size will bring more negatives to compute loss, so the training loss will be higher when increasing the batch size.  But with more negatives for training,  the performance will be better. So we suggest using a large batch size.
For train_group_size, we suggest to mind hard negatives and set it to 2 or 8.

Thank you it clears my doubt!!


feat: Implement refreshCredentialsIfRequired for intermediate token r…

This PR implements refreshCredentialsIfRequired which will be called by generateToken(). The refresh logic was implemented based on the design doc, which takes into account the refreshMargin and minimumTokenLifetime, and decides on either async or synchronous refresh if one is needed.
Notes:

This PR merges the changes to a feature branch and not the main branch.
Unit tests to follow.

I Renamed refreshCredentials() to fetchIntermediateCredentials() to better reflect its updated functionality. This method now returns the fetched intermediate credentials instead of updating the stored values directly. The update is handled by finishRefreshTask.


Avoid contravariant function fields

Background: https://github.com/dart-lang/site-www/issues/1017
I got positive support for this rule from other internal TLs on dart-lints@:
For example:
class Model<T> {
  final bool Function(T) isGood;
  Model(this.isGood);
}

void main() {
  var typed = new Model<String>((e) => e == 'Matan');
  Model<dynamic> untyped = typed;
  untyped.isGood; // Error: (dynamic) => bool not (String) => bool.
}

Here is my proposed lint in short:
class Model<T> {
  // LINT: avoid_contravariant_function_fields
  final bool Function(T) isGood;
  Model(this.isGood);
}

I imagine we could allow private function fields accessed through a safe method:
class Model<T> {
  // OK since private and accessed through a member element.
  final bool Function(T) _isGood;
  Model(this._isGood);

  // OK since covariance check
  bool isGood(T element) => _isGood(element);
}

If we ever get variance control, invariant "T" could be allowed safely.
The one real issue with be landing this lint, there already many (mis)-uses of this pattern. I could see (a) adding yet-another annotation @suppressUnsafeGeneric, (b) using // ignore: avoid_contravariant_function_fields, or (c) making this a non-error in google3 (i.e. a hint on new code only).

The upcoming experimental lint unsafe_variance could be seen as a response to this request. See also https://github.com/dart-lang/site-www/issues/1017#issuecomment-2489110848.


Proxy DB Records and ES Records to common interface

It would be nice to have the same interface for a Record coming from the DB and one from ES because then

easier to understand code
more reusability

That was essentially achieved in November sprint.


Consolidate Branch Protection Rules

Github's branch protection rule can not be applied to multiple branches.  So, we should consolidate where they make sense.  (And also prune some rules that we don't need anymore.).

This issue is stale and has not had any recent activity. If this is still a concern please reopen the issue. Thanks!


end-of-day report breaks if too many entries

This breaks the window, and only a restart really fixes it. Yikes!
Instead of even trying to fit them in, I should instead prompt the user to open them up in a separate window (#269).

Dupe of #241


Align filters at the top

Right now when filling tags:

try to make it look like this, so when filling tags, all the filters still stay the same at the top


update to latest Symbolics (v6) and SymbolicUtils (v3)

If we could get a release updating these it would be great -- they are holding us back in Catalyst from being able to fully update to them (and ModelingToolkit has now moved to them with the most recent release).

I got behind on the testing/release process here, but this repo doesn't use maketerm at all so the update should just be a version bump.

There is also the issue that arguments is no longer sorted, which we did need to address in several places in Catalyst.

I will take a look at this over the weekend

The tests pass with no problems but I am a bit worries about Sam's remark that arguments a no longer sorted. Is this so for any calls (one should be able to tell a - b from a + b)?
Is there any list of breaking changes of these new releases?

a-b of course would have to keep them sorted because it's not commutative, it's only natively commutative storages which are unsorted and thus don't perform a lexicographical sort upon access.

a-b of course would have to keep them sorted because it's not commutative, it's only natively commutative storages which are unsorted and thus don't perform a lexicographical sort upon access.

Got it, thanks. Then it should be fine, I plan to merge and make a release soon

Yes it really only makes a difference to printing. I'm not sure why it was brought up in the context here since symbolic analyses shouldn't have any difference (which is the reason for not sorting by default because it was about 99% of the time)

We had several places where Catalyst was interfacing with other packages and it seemed to matter from updates @TorkelE needed to make, so I figured it was worth mentioning.

It matters for display and DSLs because those deal with the outside world and read in / write out terms. But almost all symbolic passes can assume +,*, etc. are commutative, in which case they don't need to care about argument order. This is why the BasicSymbolic has Add,Pow, etc. forms, since in its manipulations it can specialize a lot by using hash tables for those operations. The order that then comes out of those is then always made up, because a dictionary is inherently an unordered object, so arguments(ex) would have to take the keys(hashtable) and then run a sort! on it to re-order them. However, since any math doesn't actually care about the difference between x + y + z and x + z + y, any math doesn't need to run that sort! operation.
It's just things like printing, since then if you get random ordering users will think something is broken when in reality, it would be better to just say +(Set[x,y,z])or something that basically says "this really is unordered and we did not even store the ordering, so whatever order we spit is completely random". The way to make it not look completely random is to just always sort is lexicographically: users interpret it as "it performed a simplification at that step", when in reality no simplification actually necessarily occurred (though because it's just a hash table [x =>1 ,y=>1,z=>1], + between sets will automatically simplify), it's just that there is actually no stored ordering so if we want it to look like there's any order to it, we just always have to sort.
However, it was found that this sort! was literally 99% of the profile in most operations, and thus for almost all real symbolic stuff it was the most expensive part even though it was unnecessary. So it was moved to a display operation.

And I will say that some of the sorting added back into Catalyst was actually unnecessary. For example, I think there was a case that was doing it for comparison between objects having a "change". It's really that comparison between two BasicSymbolics should be looking at the subtype of the BasicSymbolic, i.e. which form it is in the unityper, and if it's in this form it's equality between the dictionaries. One way to enforce you have equality is to write the term as a tree structure graph that it represents and then check the terms are the same (which then requires that everything is sorted so you get the same structure), but clearly from this description you could also just check that the keys match and the values match. I think I saw some of that in there. That kind of stuff isn't necessary to police though, if we need to optimize that part of the code I can come around and make a sort-free version, but I assume for DSLs people will probably overuse sorting as it makes things a bit easier than that's okay.
But symbolics passes should almost certainly get away without any sorting, and so the defaulting choice is to force things down the path of no sorting (since it's a lot faster) and if things aren't working for someone give them a sorting option. That sorting option is then a major performance red flag that is easy to audit for and fix, for someone who knows how to deal with this kind of thing, which then makes it rather easy to push the ecosystem down a path where we get a 100x performance benefit.

I have merged the PR with bumping reps but I got some precompilation for ModelingToolkit after the merge. I will take a look at them today-ish and hopefully make a new release.

That's this mess https://github.com/JuliaObjects/ConstructionBase.jl/issues/92, which also effects old versions. I did a release and a ton of backports so hopefully it should be gone within the next half hour.


segfault at exit

What did you do?
after updating prometheus from 2.51.2 to 2.55.0, I notice that some of prometheus servers consumed more CPU. I tried to restart one prometheus instance.
What did you expect to see?
the service stops cleanly and start again
What did you see instead? Under which circumstances?
a segfault during stop
System information
Linux 5.15.0-33-generic x86_64
Prometheus version
prometheus, version 2.55.0 (branch: HEAD, revision: 91d80252c3e528728b0f88d254dd720f6be07cb8)
  build user:       root@9fad779131cc
  build date:       20241022-13:47:22
  go version:       go1.23.2
  platform:         linux/amd64
  tags:             netgo,builtinassets,stringlabels

Prometheus configuration file
No response
Alertmanager version
No response
Alertmanager configuration file
No response
Logs
full stack trace: https://gist.github.com/fatpat/ad1cdb6e2187ed167222bf7b4b2a32e7

Adding a part of the stack here for more visibility

unexpected fault address 0x7f7df0003f00
fault
segmentation violation code=0x1 addr=0x7f7df0003f00 pc=0x47f26e]
goroutine 25582 gp=0xc2ddf51dc0 m=31 mp=0xc0002ae708 [running]:
runtime.throw({0x3dc689a?, 0x3e8?})
        /usr/local/go/src/runtime/panic.go:1067 +0x48 fp=0xc841f14808 sp=0xc841f147d8 pc=0x475a68
runtime.sigpanic()
        /usr/local/go/src/runtime/signal_unix.go:914 +0x26c fp=0xc841f14868 sp=0xc841f14808 pc=0x477a8c
runtime.memmove()
        /usr/local/go/src/runtime/memmove_amd64.s:372 +0x42e fp=0xc841f14870 sp=0xc841f14868 pc=0x47f26e
github.com/prometheus/prometheus/promql.ActiveQueryTracker.Delete(...)
        /app/promql/query_logger.go:209
github.com/prometheus/prometheus/promql.(*ActiveQueryTracker).Delete(0xc2ddf51dc0?, 0x2ee1)
        <autogenerated>:1 +0xe6 fp=0xc841f14900 sp=0xc841f14870 pc=0x2c48c86
github.com/prometheus/prometheus/promql.(*Engine).queueActive.func2()
        /app/promql/engine.go:695 +0x24 fp=0xc841f14920 sp=0xc841f14900 pc=0x2c0c5e4
runtime.deferreturn()
        /usr/local/go/src/runtime/panic.go:605 +0x5e fp=0xc841f149b0 sp=0xc841f14920 pc=0x43b2fe
github.com/prometheus/prometheus/promql.(*Engine).exec(0xc0008bd900, {0x466b3d0, 0xcb1e6c4a50}, 0xc96387d420)
        /app/promql/engine.go:678 +0x3d7 fp=0xc841f14bb0 sp=0xc841f149b0 pc=0x2c0b557
github.com/prometheus/prometheus/promql.(*query).Exec(0xc96387d420, {0x466b3d0, 0xcb1e6c44b0})
        /app/promql/engine.go:245 +0x1c5 fp=0xc841f14ca0 sp=0xc841f14bb0 pc=0x2c08de5
main.main.EngineQueryFunc.func45({0x466b3d0, 0xcb1e6c44b0}, {0xc45d988f00?, 0x0?}, {0x3aa8540?, 0xc4740ce1e0?, 0x0?})
        /app/rules/manager.go:52 +0x95 fp=0xc841f14d20 sp=0xc841f14ca0 pc=0x2f29e95
github.com/prometheus/prometheus/rules.(*AlertingRule).Eval(0xc304f33200, {0x466b3d0, 0xcb1e6c44b0}, 0x0?, {0xc1165fe9a0?, 0x0?, 0x0?}, 0xc000afc1b0, 0xc0004fcd80, 0x0)
        /app/rules/alerting.go:343 +0x23e fp=0xc841f15320 sp=0xc841f14d20 pc=0x2c543be
github.com/prometheus/prometheus/rules.(*Group).Eval.func1(0x7, {0x4695460, 0xc304f33200}, 0x0)
        /app/rules/group.go:516 +0x7b2 fp=0xc841f15bc0 sp=0xc841f15320 pc=0x2c5b692
github.com/prometheus/prometheus/rules.(*Group).Eval(0xc016cc1200, {0x466b3d0, 0xc10a920780}, {0x4614930?, 0x37ff54706?, 0x0?})
        /app/rules/group.go:632 +0x36f fp=0xc841f15c90 sp=0xc841f15bc0 pc=0x2c5accf
github.com/prometheus/prometheus/rules.DefaultEvalIterationFunc({0x466b3d0, 0xc10a920780}, 0xc016cc1200, {0x37e11d600?, 0x350e040?, 0x0?})
        /app/rules/manager.go:81 +0xf7 fp=0xc841f15d20 sp=0xc841f15c90 pc=0x2c60ff7
github.com/prometheus/prometheus/rules.(*Group).run(0xc016cc1200, {0x466b398, 0x67f7ac0})
        /app/rules/group.go:295 +0x9da fp=0xc841f15f88 sp=0xc841f15d20 pc=0x2c5879a
github.com/prometheus/prometheus/rules.(*Manager).Update.func1(0xc016cc1200)
        /app/rules/manager.go:241 +0xa6 fp=0xc841f15fc8 sp=0xc841f15f88 pc=0x2c624e6
github.com/prometheus/prometheus/rules.(*Manager).Update.gowrap2()
        /app/rules/manager.go:242 +0x24 fp=0xc841f15fe0 sp=0xc841f15fc8 pc=0x2c62404
runtime.goexit({})

same issue here https://github.com/prometheus/prometheus/issues/15401#issuecomment-2477274983

same here, the bug is not consistent and can't reproduce easily.

Given that it happens only on shutdown wouldn't the most likely cause be some sort of race introduced by #14064 and/or #14861 ?

Given that it happens only on shutdown wouldn't the most likely cause be some sort of race introduced by #14064 and/or #14861 ? At first glance it looks as if query tracker tries to write to mmap-ed file after that file was already closed.

I think I can reproduce it with this test:
func TestActiveQueryTrackerClose(t *testing.T) {
	dir := t.TempDir()

	maxConcurrent := 10
	fileAsBytes, closer, err := getMMapedFile(path.Join(dir, "queries.active"), 1+maxConcurrent*entrySize, nil)
	require.NoError(t, err)

	queryLogger := ActiveQueryTracker{
		maxConcurrent: maxConcurrent,
		mmapedFile:    fileAsBytes,
		closer:        closer,
		logger:        nil,
		getNextIndex:  make(chan int, 4),
	}

	queryLogger.generateIndices(4)
	veryLongString := "MassiveQueryThatNeverEndsAndExceedsTwoHundredBytesWhichIsTheSizeOfEntrySizeAndShouldThusBeTruncatedAndIamJustGoingToRepeatTheSameCharactersAgainProbablyBecauseWeAreStillOnlyHalfWayDoneOrMaybeNotOrMaybeMassiveQueryThatNeverEndsAndExceedsTwoHundredBytesWhichIsTheSizeOfEntrySizeAndShouldThusBeTruncatedAndIamJustGoingToRepeatTheSameCharactersAgainProbablyBecauseWeAreStillOnlyHalfWayDoneOrMaybeNotOrMaybeMassiveQueryThatNeverEndsAndExceedsTwoHundredBytesWhichIsTheSizeOfEntrySizeAndShouldThusBeTruncatedAndIamJustGoingToRepeatTheSameCharactersAgainProbablyBecauseWeAreStillOnlyHalfWayDoneOrMaybeNotOrMaybeMassiveQueryThatNeverEndsAndExceedsTwoHundredBytesWhichIsTheSizeOfEntrySizeAndShouldThusBeTruncatedAndIamJustGoingToRepeatTheSameCharactersAgainProbablyBecauseWeAreStillOnlyHalfWayDoneOrMaybeNotOrMaybeMassiveQueryThatNeverEndsAndExceedsTwoHundredBytesWhichIsTheSizeOfEntrySizeAndShouldThusBeTruncatedAndIamJustGoingToRepeatTheSameCharactersAgainProbablyBecauseWeAreStillOnlyHalfWayDoneOrMaybeNotOrMaybe"
	queries := []string{
		"TestQuery",
		veryLongString,
		"",
		"SpecialCharQuery{host=\"2132132\", id=123123}",
	}

	want := []string{
		`^{"query":"TestQuery","timestamp_sec":\d+}\x00*,$`,
		`^{"query":"` + trimStringByBytes(veryLongString, entrySize-40) + `","timestamp_sec":\d+}\x00*,$`,
		`^{"query":"","timestamp_sec":\d+}\x00*,$`,
		`^{"query":"SpecialCharQuery{host=\\"2132132\\", id=123123}","timestamp_sec":\d+}\x00*,$`,
	}

	// Check for inserts of queries.
	for i := 0; i < 4; i++ {
		start := 1 + i*entrySize
		end := start + entrySize

		queryLogger.Insert(context.Background(), queries[i])

		have := string(fileAsBytes[start:end])
		require.True(t, regexp.MustCompile(want[i]).MatchString(have),
			"Query not written correctly: %s", queries[i])
	}

	// Delete first 2 queries
	for i := 0; i < 2; i++ {
		queryLogger.Delete(1 + i*entrySize)
	}

	// Close the query logger
	require.NoError(t, queryLogger.Close())

	// Try to delete last 2 queries
	for i := 2; i < 4; i++ {
		queryLogger.Delete(1 + i*entrySize)
	}
}

$ go test -v -count=11 -run=TestActiveQueryTrackerClose ./promql
=== RUN   TestActiveQueryTrackerClose
unexpected fault address 0x752d75c307e0
fatal error: fault
[signal SIGSEGV: segmentation violation code=0x1 addr=0x752d75c307e0 pc=0x4803ee]

goroutine 50 gp=0xc0004b6a80 m=0 mp=0x191f1e0 [running]:
runtime.throw({0xf8ce04?, 0x3e8?})
	/home/lukasz/usr/go/src/runtime/panic.go:1067 +0x48 fp=0xc000535c38 sp=0xc000535c08 pc=0x476c88
runtime.sigpanic()
	/home/lukasz/usr/go/src/runtime/signal_unix.go:931 +0x26c fp=0xc000535c98 sp=0xc000535c38 pc=0x478cac
runtime.memmove()
	/home/lukasz/usr/go/src/runtime/memmove_amd64.s:372 +0x42e fp=0xc000535ca0 sp=0xc000535c98 pc=0x4803ee
github.com/prometheus/prometheus/promql.ActiveQueryTracker.Delete(...)
	/home/lukasz/work/prometheus/promql/query_logger.go:209
github.com/prometheus/prometheus/promql.TestActiveQueryTrackerClose(0xc00049e340)
	/home/lukasz/work/prometheus/promql/query_logger_test.go:222 +0x928 fp=0xc000535f70 sp=0xc000535ca0 pc=0xa0bbe8
testing.tRunner(0xc00049e340, 0x102fb50)
	/home/lukasz/usr/go/src/testing/testing.go:1690 +0xf4 fp=0xc000535fc0 sp=0xc000535f70 pc=0x5506d4
testing.(*T).Run.gowrap1()
	/home/lukasz/usr/go/src/testing/testing.go:1743 +0x25 fp=0xc000535fe0 sp=0xc000535fc0 pc=0x5516c5
runtime.goexit({})
	/home/lukasz/usr/go/src/runtime/asm_amd64.s:1700 +0x1 fp=0xc000535fe8 sp=0xc000535fe0 pc=0x47f1e1
created by testing.(*T).Run in goroutine 1
	/home/lukasz/usr/go/src/testing/testing.go:1743 +0x390

Hopefully #15533 fixes this


AP-2268 update button styling

What
Link to story
Update upload button to use secondary (grey) style to match MoJ Design System, and avoid having two green CTAs on the page
Checklist
Before you ask people to review this PR:

[ ] Tests and rubocop should be passing: bundle exec rake
[ ] Github should not be reporting conflicts; you should have recently run git rebase master.
[ ] There should be no unnecessary whitespace changes. These make diffs harder to read and conflicts more likely.
[ ] The PR description should say what you changed and why, with a link to the JIRA story.
[ ] You should have looked at the diff against master and ensured that nothing unexpected is included in your changes.
[ ] You should have checked that the commit messages say why the change was made.

Codecov Report

Merging #2626 (73d48dd) into master (f318a9b) will not change coverage.
The diff coverage is n/a.

@@            Coverage Diff            @@
##            master     #2626   +/-   ##
=========================================
  Coverage   100.00%   100.00%
=========================================
  Files          528       528
  Lines        10857     10857
=========================================
  Hits         10857     10857

Continue to review full report at Codecov.

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


Contains query intermittently failing with NotSupportedException

Marten Version:  5.11.0
I've been seeing intermittent NotSupportedExceptions being thrown by Marten when using .Contains in a query. After some digging it appears that marten is caching the IMethodCallParser after first lookup.
https://github.com/JasperFx/marten/blob/3ac2692d07f637ee7ab597610df9b33fb754aabc/src/Marten/LinqParsing.cs#L128
The error is thrown reliably in either the EnumerableContains or IsInGenericEnumerable IMethodCallParser. I can reproduce the issue in a test below. If you comment out either one of the queries then no exception is thrown, and the queries run as expected. But when run together in the same test the second query will fail with a NotSupportedException due to finding the wrong parser.
[Fact]
public void Test_Throws_NotSupportedException()
{
    var store = DocumentStore.For(
        x =>
            {
                x.Connection("connection_string");
                x.DatabaseSchemaName = "testschema";
            });

    using var session = store.OpenSession();

    // EnumerableContains
    var query = session.Query<TestModel>().FirstOrDefault(x => x.Ids.Contains(Guid.Empty));

    // IsInGenericEnumerable
    var query2 = session.Query<TestModel>().FirstOrDefault(x => new List<Guid> { Guid.Empty }.Contains(x.Id));
}

public class TestModel
{
    public Guid Id { get; set; }

    public List<Guid> Ids { get; set; } = new List<Guid>();
}

Same issue as in #2452.

I've got this. I might know what the root cause is, and it's already fixed on the "linq" branch. Same little fix will work here too.

This is actually beaten in V7 now.


mysql start fails on ubuntu 14.04

Cookbook version
8.0
Chef-client version
Chef: 12.13.37
Platform Details
Ubuntu 14.04
Scenario:
Trying to create and start default mysql-client and mysql-server
Steps to Reproduce:
mysql_client 'default' do
  action :create
  package_version ''
end

mysql_service 'default' do
  port '3306'
  package_version ''
  initial_root_password rundeck_rdbms['rdbms']['dbpassword']
  action [:create, :restart]
end

Expected Result:
Creation and installation of mysql-server and mysql-client
Actual Result:
Running handlers:
       [2016-08-17T20:25:25+00:00] ERROR: Running exception handlers
       Running handlers complete
       [2016-08-17T20:25:25+00:00] ERROR: Exception handlers complete
       Chef Client failed. 79 resources updated in 03 minutes 52 seconds
       [2016-08-17T20:25:25+00:00] FATAL: Stacktrace dumped to /tmp/kitchen/cache/chef-stacktrace.out
       [2016-08-17T20:25:25+00:00] FATAL: Please provide the contents of the stacktrace.out file if you file a bug report
       [2016-08-17T20:25:25+00:00] ERROR: mysql_service[default] (rundeck::server_install line 243) had an error: Mixlib::ShellOut::ShellCommandFailed: mysql_service_manager_upstart[default] (/tmp/kitchen/cache/cookbooks/mysql/libraries/mysql_service.rb line 50) had an error: Mixlib::ShellOut::ShellCommandFailed: service[mysql-default] (/tmp/kitchen/cache/cookbooks/mysql/libraries/mysql_service_manager_upstart.rb line 68) had an error: Mixlib::ShellOut::ShellCommandFailed: Expected process to exit with [0], but received '1'
       ---- Begin output of /sbin/start mysql-default ----
       STDOUT:
       STDERR: start: Unknown job: mysql-default
       ---- End output of /sbin/start mysql-default ----
       Ran /sbin/start mysql-default returned 1
       [2016-08-17T20:25:26+00:00] FATAL: Chef::Exceptions::ChildConvergeError: Chef run process exited unsuccessfully (exit code 1)

@jtimberman : Can you please take a look at this issue. I have tried lot to debug it. Only thing I found was missing attribute mysql_name here. Thanks.

Fixed up in 8.0.2


[MM-22846]: post forwarding

Summary
this adds post forwarding according to this design
Ticket Link
MM-22846
Related Pull Requests

Has server changes https://github.com/mattermost/mattermost-server/pull/20166

Screenshots
tbd
Release Note
adds post forwarding feature

Thanks @michelengelen!
A few things I noticed:

We should allow CTRL + ENTER to send the forwarded message when in the forward modal. Similarly, when not focused in the comment field, allow ENTER to send the forward message if a destination channel has been selected
Somethings strange in the autocomplete when searching

Button styles for the forward and cancel buttons don't look quite right, I'll defer to @matthewbirtch
Hover effect on the "x" doesn't look quite right missing rounded corners, I'll defer to @matthewbirtch
Styling for long messages overruns modal

Forward button is disabled in DMs and GMs

@hmhealey @BenCookie95 @matthewbirtch would you guys mind expediting reviews if possible? Thanks!

Re 9 + 10: @matthewbirtch, I'm really worried about discoverability if we move it to the ... menu. I'd propose we leave it as is and also add it to the RHS (there seems to be enough room even on small screens). We can always adjust if we get feedback on it being too long or hard to consume

@matthewbirtch I also realized we never designed a "tutorial tip" for this. Should we add something similar to the actions menu tip?

@esethna what do you think about removing the 'reply' icon from this hover menu since it's in the ••• menu already and we have a few other methods to reply (click to open thread, clicking 'reply' in the thread footer)

@matthewbirtch I would rather keep reply (even though it may be repetitive it's the most critical functionality to surface). If we move the forward to the ... menu then let's make sure we design a tutorial tip to help discoverability

@matthewbirtch I would rather keep reply (even though it may be repetitive it's the most critical functionality to surface - and some users might not have the click to reply on). If we move the forward to the ... menu then let's make sure we design a tutorial tip to help discoverability

Ya, I don't disagree with that. I'll make a ticket to design something to bring attention to the feature in the ••• menu

@matthewbirtch and @esethna ... with my latest changes all of your suggestions should now be addressed. Would you mind reviewing again?
The only thing I did not add yet is the pulsating dot and the new badge. Will add this later today or tomorrow.
BTW: using the GenericModal did add some complexities I did not expect, that's why it took longer than expected to adjust! Sorry! 🙇🏼

Looks like we need a keyboard shortcut for the ... menu, maybe "S" for share? 0/5 @matthewbirtch?

Looks like we need a keyboard shortcut for the ... menu, maybe "S" for share? 0/5 @matthewbirtch?

Good catch, I don't have a great suggestion for the shortcut since F is already taken. S works as good as anything else I guess.

Looks like we need a keyboard shortcut for the ... menu, maybe "S" for share? 0/5 @matthewbirtch?

Good catch @esethna, I don't have a great suggestion for the shortcut since F is already taken. S works as good as anything else I guess.

@matthewbirtch shortcut S is already taken (used for saving/unsaving). We could either find a new one, or start using combinations, e.g. Shift + F or something of the sort.
cc @esethna

@matthewbirtch shortcut S is already taken (used for saving/unsaving). We could either find a new one, or start using combinations, e.g. Shift + F or something of the sort.

Not against the idea of going with Shift F, but I was hoping to keep it to a single letter for consistency in this menu. Any other single-letter shortcut will be fairly arbitrary, but we could use the second letter of the word and use O

@matthewbirtch shortcut S is already taken (used for saving/unsaving). We could either find a new one, or start using combinations, e.g. Shift + F or something of the sort.

Not against the idea of going with Shift F, but I was hoping to keep it to a single letter for consistency in this menu. Any other single-letter shortcut will be fairly arbitrary, but we could use the second letter of the word and use O

O might also imply using first character of the word Onward for it! ... so that might still work in that way ... kinda! :D

@matthewbirtch separate from this effort, should we consider adding save to the ... menu even though it's also in the hover menu? I had no idea "S" worked since the shortcut isn't shown anywhere, and it's a pretty commonly used feature I would imagine

@matthewbirtch shortcut S is already taken (used for saving/unsaving). We could either find a new one, or start using combinations, e.g. Shift + F or something of the sort.

Not against the idea of going with Shift F, but I was hoping to keep it to a single letter for consistency in this menu. Any other single-letter shortcut will be fairly arbitrary, but we could use the second letter of the word and use O

O might also imply using first character of the word Onward for it! ... so that might still work in that way ... kinda! :D

The only problem is that it might get confused with 0

separate from this effort, should we consider adding save to the ... menu even though it's also in the hover menu? I had no idea "S" worked since the shortcut isn't shown anywhere, and it's a pretty commonly used feature I would imagine

@esethna, I wouldn't be opposed to that. Would you mind creating a ticket?

@matthewbirtch shortcut S is already taken (used for saving/unsaving). We could either find a new one, or start using combinations, e.g. Shift + F or something of the sort.

Not against the idea of going with Shift F, but I was hoping to keep it to a single letter for consistency in this menu. Any other single-letter shortcut will be fairly arbitrary, but we could use the second letter of the word and use O

O might also imply using first character of the word Onward for it! ... so that might still work in that way ... kinda! :D

The only problem is that it might get confused with 0

To check this I will add 2 options ... one with Shift + F, the other one with X for cross-posting! (really fishy explanation, aye? :D)

To check this I will add 2 options ... one with Shift + F, the other one with X for cross-posting! (really fishy explanation, aye? :D)

Thanks for providing the options @michelengelen. I think my choice would be Shift+F. X feels a bit random.

Adding @cwarnermm for review of the menu text

Still seeing these issues @michelengelen:

modal opens too low when image attachment preview is in shared message

Menu sits under image attachment preview

Can the Forward Message option available from ... be sentence case: "Forward message". It'll match the follow action. Over time, docs plans to sentence case the other options as well for consistency. Also provided casing feedback in the Figma file directly @matthewbirtch

@michelengelen I'm still seeing the modal sitting too low when an image is in the preview:

@BenCookie95 @hmhealey @Willyfrog kind request to try to complete review soon so we make the feature complete cut for v7.2

Hey team - was playing around with the test server and noticed that you can't forward a message to someone unless you've previously opened a DM with them. Recorded a quick vid using DM with myself as an example (but had the same problem with the test user user-1). Is this expected?

The channel doesn't exist if you have never talked with them, so I'd say it is expected. We can try and fix this in a subsequent PR if we want to address it.

Thanks Guillermo for the explanation. 3/5, personally I feel like you should be able to message anyone especially since you have the ability to add a comment for context. Existing DMs could still populate in the recents drop down but as a user I would think that if I wanted to I could forward to anyone with the necessary permission to view the message in question

The channel doesn't exist if you have never talked with them, so I'd say it is expected. We can try and fix this in a subsequent PR if we want to address it.

Thanks Guillermo for the explanation. 3/5, personally I feel like you should be able to message anyone especially since you have the ability to add a comment for context. Existing DMs could still populate in the recents drop down but as a user I would think that if I wanted to I could forward to anyone with the necessary permission to view the message in question

Sure, can you create a bug ticket for that. What I meant was to allow the PR to be merged and then tackle any edge cases in later PRs, but start using the functionality as soon as possible in community to get feedback and polish based on that.

/e2e-test

Successfully triggered e2e testing!
https://git.internal.mattermost.com/qa/cypress-ui-automation/-/pipelines/217498

Sure, can you create a bug ticket for that. What I meant was to allow the PR to be merged and then tackle any edge cases in later PRs, but start using the functionality as soon as possible in community to get feedback and polish based on that.

Agreed with keeping the existing scope of this PR and gathering feedback from Community. Created a ticket for this to be evaluated in the future: https://mattermost.atlassian.net/browse/MM-45688

Hi @michelengelen! Where can I focus my review efforts in this PR?

Hi @michelengelen! Where can I focus my review efforts in this PR?

@cwarnermm focus on anything related to post forwarding - mainly the forward menu option that appears in the ••• menu on posts and the resulting 'Forward message' modal. There's probably not a lot for you to review though

Hi @michelengelen
seeing few issues

White screen when forwarding post from global Threads view

Adding over the limit text to Add comment field, locks the modal input boxes

Sometimes long post forwarding causes few lines of the post to overlap on the forward modal

new menu label is not vertically aligned

One more thing - disregard if this was already mentioned
There are 2 scroll bars when select channel/people option is longer than modal height making it hard to scroll through the list; you have to scroll the list then move the mouse to the right side and scroll a bit more to see the bottom of the list.
Should we drop the list outside of the modal, similarly to how "add member" modal is designed?
I guess if users use search first, they will see a shorter results list - in that case this may not be an issue.

One more thing - disregard if this was already mentioned There are 2 scroll bars when select channel/people option is longer than modal height making it hard to scroll through the list; you have to scroll the list then move the mouse to the right side and scroll a bit more to see the bottom of the list. Should we drop the list outside of the modal, similarly to how "add member" modal is designed? I guess if users use search first, they will see a shorter results list - in that case this may not be an issue.

Hey @jgilliam17
Yes, that scrolling problem hasn't been mentioned, but it is something I am already aware of.
There are 2 different approaches to tackle this problem... but simply letting the menu overflow the modal is not easily done (it includes some performance heavy calculations for scrolling I had problems with in the past and I am not sure if this is even possible with the package we are using for the select)... however: If that is the approach that we want to take I can definitely take a look into it.
as for the other option:
measure the height of the modal body and restrict the size of the options-list so that it does not overflow the container and does not add scrollbars to it.
My latest commit implements that approach, so you can take a look.
in the meantime i will take on the other findings.

Hi @michelengelen seeing few issues
1. White screen when forwarding post from global Threads view

Fixed!

2. Adding over the limit text to Add comment field, locks the modal input boxes

Fixed!

3. Sometimes long post forwarding causes few lines of the post to overlap on the forward modal

this is a separate issue with the message preview component. Ticket is here.

4. `new` menu label is not vertically aligned

Fixed!

To update my review, my only outstanding concern is the NEW badge and it sticking around forever, but we're waiting on @esethna for confirmation on how that should work

@hmhealey @michelengelen the new badge should not stick around forever. I'm not sure what @matthewbirtch had in mind, but I would imagine we would remove it once the user opens the Forward Message dialog for the first time. We may also want to put a time limitation on it, for example, don't show it for longer than 1 month after the user upgrades (even if they don't click the menu item to forward a message)
Thoughts @michelengelen @hmhealey?

Also minor thing but the new badge is missing some padding it seems and the corners aren't as rounded as the design:

Also the gap between the autocomplete and text box is a bit bigger than designed:

design:

1. Warning message when sharing a message from private channel, missing channel name formatting

Fixed!

2. Preview component shows hand pointer on hover, and permalinks can be clicked on, navigate to post in the background. I didn't expect this to happen

Fixed by disabling all pointer events on the wrapping component

3. Expected? Bots are included on the list - I thought having feedback bot would be convenient as you can share a message that contains/discusses an issue directly with Mattermost. 0/5 on this

I don't know if we want to include bots ... i removed them for now.

4. There is a crash when canceling share with feedback bot

Fixed by removing bots from the list.

5. One more white screen - I was opening Threads, but unsure of the steps before I got there

This is unrelated, but the error is coming from this selector returning null and since the return value is immediately destructured it throws an error. This could be easily fixed by giving it an alternate value in case of null
const {total = 0, total_unread_threads: totalUnread} = useSelector(getThreadCountsInCurrentTeam) ?? {};

I will open a ticket and PR for this.

6. We should remove archived channels from the list

Fixed!

7. This may be as designed, just noting here that it wasn't obvious to me as "guest user"

The permalink preview should show that the post is only visible to the user in channel X. Will look into this if it is blocking. @esethna ?

8. Forwarding a post from RHS while on Insights is unsuccessful, throws an error

Fixed!

@hmhealey @michelengelen the new badge should not stick around forever. I'm not sure what @matthewbirtch had in mind, but I would imagine we would remove it once the user opens the Forward Message dialog for the first time. We may also want to put a time limitation on it, for example, don't show it for longer than 1 month after the server is upgraded (even if they don't click the menu item to forward a message)
Thoughts @michelengelen @hmhealey?

I will add a logic that will remove it once it is clicked (and after a month of latest server upgrade)

9. Also minor thing but the new badge is missing some padding it seems and the corners aren't as rounded as the design:

Fixed

Also the gap between the autocomplete and text box is a bit bigger than designed and the autocomplete is being cut off (ie isn't as tall) as designed:

Fixed ... I added a logic that restricts the list-height to the maximum height of the modal body ( - input height - margin) since overflowing the container was not possible without breaking the scroll logic for longer forwarded posts and inputs

11. Another call out is the scroll bar component seems different than other autocompletes

Fixed

@hmhealey I have added a logic to hide the new badge when it is clicked, but I am struggling to find info on how I can retrieve infos on server version (IMO we should check that as well, since it needs to be a very recent version) and last time updated.
IMO we could just as well remove the badge once the feature is a month old or so.
Thoughts?

I'd be fine just removing it from the code in a future release and just assuming people will have upgraded through one of those versions or will have used the feature by then. As you found, we don't have a good way (at least on the client) of knowing how long a server's been on that specific version. Back when I was working on the NPS survey plugin, that even had to keep track of versions it had seen before to determine that itself.
@esethna Along those lines, I've noticed that this is a bit of a recurring theme where we've cared about how long a server has been on the current version for various things (like these "new feature" indicators or the NPS plugin as I mentioned above). I wonder if it would make sense to get a team to build a proper system for tracking that since it keeps coming up as something we want, but it's always for minor details of features that make it hard to dedicate time to working on. We might also be able to implement features that have a better understanding of if it's a fresh install then (so we can do things like not showing this indicator to users who've never used MM prior to 7.2). Just a thought though.

Also, I think https://mattermost.atlassian.net/browse/MM-45781 is a ticket for that error, Michel

I have added a logic to hide the new badge when it is clicked, but I am struggling to find info on how I can retrieve infos on server version (IMO we should check that as well, since it needs to be a very recent version) and last time updated.

IMO we could just as well remove the badge once the feature is a month old or so.
@michelengelen @hmhealey The issue with just removing in a future version is that many folks don't upgrade to every release, so it might be missed if someone upgraded, for example, from v6.5 > v7.5
If we're struggling with a way to identify a time based logic (ie remove the badge 1 month after someone first upgrades to a version that supports forwarding a message), then we can just forget that part for now. As long as the new badge will disappear once the menu item is clicked that is probably fine.
@hmhealey agree it would be nice to have a way to do this though in the future, can you help open a ticket with the technical explanation and share with me so I can add some example use cases?

@esethna your thoughts on point 7. https://github.com/mattermost/mattermost-webapp/pull/10613#issuecomment-1185716047

@jgilliam17 @michelengelen good find re guests users. The permalink preview should not be rendered if the user doesn't have access to the channel where the post exists. We could think about improvements to permalink previews in this case, but I don't think it's blocking.

Thanks @michelengelen
For 3. - Just to clarify - As sysadmin I am not able to search for any DM on the select dropdown. I have user-1 on LHS and have exchanged messages but user-1 is not appearing on the drop down as an option to forward to.

@jgilliam17 the before mentioned issue is now resolved

Thanks @michelengelen
One more thing
The DMs are present on the dropdown, but can't be searched for - return no results
https://user-images.githubusercontent.com/52937121/180013595-badf4065-2be4-4cd6-836e-a895054cf352.mov

@michelengelen How do I get new menu label to show up again?

You should probably create a new user :D

@jgilliam17 there was a mistake on my end ... fixed it! Sorry for the confusion!

Unfortunately I am not able to get the search for DM to work on the forward message modal. I'll try updating branch and re-testing

/update-branch

@michelengelen re-tested - DM search on Forward message modal still not working on the test server

ok, @jgilliam17 I have adressed everything now ...

searching now gets the correct results
bots are removed from the list (for now)
forwarding to and from every channel works as expected

Could you please re-test and see if you can find anything else ... thanks! ... 🙇🏼

Thanks @michelengelen
Bots are still "present" on the list, albeit invisible
https://user-images.githubusercontent.com/52937121/180227227-27abf06a-7435-4b79-893a-168e44f8ffc9.mov

False alarm - one of the browsers wasn't refreshed
@michelengelen
Everything is fixed now - lgtm
I'll create a follow up ticket for guest user experience we discussed previously here.

/cherry-pick cloud

Cherry pick is scheduled.


Add CurrentSongTime support from HttpSiraStatus

HTTPSiraStatus is a branch of the original beatsaber-http-status mod, and added data of currentSongTime

Thank you <3

That was quick 😄


[bug] moon query - flags combined with --affected not respected

Describe the bug
I am running touched-files in conjunction with query projects --affected in my github action. Ever moon version 1.29.0, all secondary flags are not respected.
Steps to reproduce
moon query touched-files | moon query projects --affected --type application --tasks test

The only difference between running my test bash script in between the two screenshots is that I have moon 1.27.9  before, and ran proto pin moon 1.29.0.
Expected behavior
Normally it would bring me all affected projects with code changes, which are of type application, and which are testable with the "test" command.
Screenshots
Before v1.29.0, this would return "just affected applications that have the test command":

After v1.29.0, I now receive a list, of which I cannot even fathom why they are in the list / affected:

Environment
Before
moon --version // 1.27.9

After
moon --version // 1.29.0

@Blissful89 Do the logs actually show all those extras as being affected?

Figured it out, will patch soon!

@Blissful89 Do the logs actually show all those extras as being affected?

Yes

Figured it out, will patch soon!

Super thank you for the quick response!


Issue 3&4 - feature equalTo + specify source compatibility

Codecov Report

Merging #7 (e7fe5de) into master (3404c6a) will increase coverage by 0.14%.
The diff coverage is 100.00%.

@@             Coverage Diff              @@
##             master       #7      +/-   ##
============================================
+ Coverage     96.13%   96.27%   +0.14%
  Complexity       26       26
============================================
  Files            11       11
  Lines           181      188       +7
  Branches         19       21       +2
============================================
+ Hits            174      181       +7
  Misses            2        2
  Partials          5        5

Impacted Files
Coverage Δ

...tlin/com/marcinziolo/kotlin/wiremock/Constraint.kt
100.00% <100.00%> (ø)

...in/com/marcinziolo/kotlin/wiremock/ContainsStep.kt
100.00% <100.00%> (ø)

...iolo/kotlin/wiremock/mapper/toMappingBuilder.kt.kt
91.11% <100.00%> (+0.63%)
:arrow_up:

Continue to review full report at Codecov.

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


Correctly measuring a CLS score of 0

Sorry in advance if this is not the right place to ask this.
I was wondering if it is correct to assume that if the callback for onCLS is never called, then the CLS score for a page is 0. I see here that the callback could potentially be triggered with 0 after FCP is calculated, but I am not sure how this behavior is supposed to work on all use cases.
Thanks!

I was wondering if it is correct to assume that if the callback for onCLS is never called, then the CLS score for a page is 0.

That is not correct. If the CLS value is 0 then the callback will be called with 0. If the onCLS() callback is never called then it means either the browser doesn't support CLS or the page didn't reach FCP (which is often the case if the page was loaded in a background tab).
Note that by default the callback for onCLS() only fires when the page's visibility state changes to hidden, so it's possible it is firing but you're not noticing it because you're expecting it to fire once the page is done loading. If you switch tabs and then switch back, you should see something logged (you can also refresh and make sure "preserve log" is checked in DevTools).

Thank you very much for the promptly answer! We will adjust our logic to that!


Abstract classes not supported anymore

Hi,
we are using abstract classes as a base for some classes. This was supported in previous versions but not with the current version (dev.10). I get the runtime error no valid constructor found. Any workaround you can think about?
BR :)

That should work and seems like a bug. Can you post a snippet of what doesn't work exactly?

Pls see this example
@MappableClass(discriminatorKey: 'type')
abstract class ClassA with ClassAMappable {
  final String? someVariable;
  final String type;

  const Asset(this.type, this.someVariable);
}

@MappableClass(discriminatorValue: 'SomeType')
class ClassB extends Class with ClassBMappable {
  @override
  final int? someOtherVariable;

  const DeliveryNote(String type, String? someVariable, this.someOtherVariable) : super(type, someVariable);
}

If I remove the abstract keyword, the no valid constructor found error disappears. However, the right type is not recognized anymore.

There is a second layer based on the snippet above
@MappableClass(discriminatorKey: 'mainType')
class ClassAState<T extends ClassA> with ClassAStateMappable<T> {
  final String mainType;
  final T content;

  const AssetState(this.mainType, this.content);
}

@MappableClass(discriminatorValue: 'SomeMainType')
class ClassBState extends ClassAState<ClassB> with ClassBStateMappable {
  const ClassBState(String mainType, ClassB content) : super(mainType, content);
}

I hope these snippets help to understand the situation. Pls let me know if you need more information

In the first example the constructors doesnt match the class name. Is this just a copypaste error?

Sry, yes. I corrected both constructors.

I think I know the issue. Are the classes defined in different libraries? If so, you now have to explicitly set all subclasses for a super class:
// In file a
@MappableClass(discriminatorKey: ..., includeSubClasses: [ClassB])
class ClassA ...

// In file b
@MappableClass(discriminatorValue: ...)
class ClassB extends ClassA ...

Yes, they are. Thank you for the information, I will check that.
I assume that will not fix the abstract key?

It can be abstract

Ok, it seems to work but there is a strange behavior where I need to figure out, whether it's caused by the package or something else. Maybe you can add the subclass topic to your migration guide.