What ARM server can the VSCode desktop version run on?

VS Code Version:  v1.81.1

OS Version: Huaweiyun kungpeng Server，centos7.9_with_arm、centos7.6_with_arm、centos8.0_with_arm，aliyun ARM ，CPU Yitian 710

Steps to Reproduce:

install VSCode， https://code.visualstudio.com/docs/setup/linux
start code error：“/usr/bin/code: line 62:  2779 Trace/breakpoint trap   (core dumped) ELECTRON_RUN_AS_NODE=1 "$ELECTRON" "$CLI" --ms-enable-electron-run-as-node "$@"”

Thanks for creating this issue! It looks like you may be using an old version of VS Code, the latest stable release is 1.81.1. Please try upgrading to the latest version and checking whether this issue remains.
Happy Coding!

https://github.com/microsoft/vscode/wiki/Native-Crash-Issues

https://github.com/microsoft/vscode/wiki/Native-Crash-Issues

no crash dumps.

Crash happens early before application code gets executed which causes missing minidumps. Can you download https://github.com/electron/electron/releases/download/v25.7.0/electron-v25.7.0-linux-armv7l.zip and check if the crash happen when you run ELECTRON_RUN_AS_NODE=1 electron.exe

ELECTRON_RUN_AS_NODE=1 e

bash: ./electron: cannot execute binary file: Exec format error

Crash happens early before application code gets executed which causes missing minidumps. Can you download https://github.com/electron/electron/releases/download/v25.7.0/electron-v25.7.0-linux-armv7l.zip and check if the crash happen when you run ELECTRON_RUN_AS_NODE=1 electron.exe

https://github.com/electron/electron/releases/download/v25.7.0/electron-v25.7.0-linux-x64.zip can generate crash dump file.  core-electron-2972-1693291880.zip

Can you attach the coredump file in this issue, thanks!

https://github.com/microsoft/vscode/files/12461240/core-electron-2972-1693291880.zip

Thanks for the core dump, I just realized that Electron does not generated correct debug symbols for arm architecture https://github.com/electron/electron/blob/9280b79112be0dc307ed81784c885d896bb20e5e/script/copy-debug-symbols.py#L18-L20 which makes it hard for me to debug the above dump.
Is there a devcontainer available to repro the above crash, it would help me to debug the crash locally. I am able to run https://github.com/electron/electron/releases/download/v25.7.0/electron-v25.7.0-linux-arm64.zip with arm64v8/centos:centos7 container

coredump file with arm64v8/centos:centos7 ，https://github.com/microsoft/vscode/files/12484074/core-electron-194-1693469608.zip

Have you installed the pre-requisite libraries for running Electron ? I had to install alsa-lib, gtk3, cups-libs, at-spi2-atk, atk on a fresh installation of arm64v8/centos:centos7 container.

i installed  gtk3 and alsa-lib-devel，other not.  i'm going to  install them

Given the debug symbols are broken there is not much I can do to investigate the crash, would be great to have a reliable repro. I would recommend filing an issue at https://github.com/electron/electron
Can you confirm, when you installed VSCode following the steps at https://code.visualstudio.com/docs/setup/linux did you use the rpm package ?

Can you confirm, when you installed VSCode following the steps at https://code.visualstudio.com/docs/setup/linux did you use the rpm package ?  YES

Given the debug symbols are broken there is not much I can do to investigate the crash, would be great to have a reliable repro. I would recommend filing an issue at https://github.com/electron/electron

I send server connect info to your<EMAIL_ADDRESS>

Hi, Which ARM servers have you verified to successfully run VSCode Desktop (Version 1.81)? What are the specific ARM server name with version and operating system name and version?

Supported OS are documented in https://code.visualstudio.com/docs/supporting/requirements#_platforms, the required dependencies are bundled into the rpm and deb packages. If you are able to install them then it should run fine on your OS.
Thanks for the server credentials, but unfortunately I cannot connect to them due to security concerns. In your case, I do notice a CPU model CPU Yitian 710 which we haven't tested. Given the issue repros with https://github.com/electron/electron and due to lack of debug symbols, there is not much we can do at this time to debug this crash further.
However, for your scenario you can instead use our remote tunnels support https://code.visualstudio.com/docs/remote/tunnels which avoids installing the desktop on this server


Upgrade the underlying terraform provider to at least v3.98 to add new resources and bug fixes.

What problem are you facing?
We need to resources that were added in v3.98 of the azure terraform provider, see #700 . In order to create a PR for those resources, we need this update.
Please update to at least v3.98, latest is currently v3.102

How could Official Azure Provider help solve your problem?

Same for us. We would like to use the azurerm_security_center_storage_defender.scan_results_event_grid_topic_id property introduced with v3.115.0.


Fix error in equality method for bearing elements

Closes #1100

An AttributeError occurs when running the analysis of a rotor with ball bearings due to an issue in the __eq__ method of the BearingElement class. This method checks for equality between elements but fails when comparing instances of the BallBearingElement class. The error arises because some arguments used during the initialization of a BallBearingElement instance (such as n_balls, d_balls, fs, and alpha) are not stored as attributes of the object, leading to a mismatch in the comparison.
To resolve this issue, the list of attributes to be compared in the __eq__ method was refined. The comparison now uses the intersection of the initialization arguments and the object's attribute names, ensuring that only relevant attributes are considered when checking for equality.

I used this PR to fix an issue that arose when comparing bearing elements with attributes of different sizes (this error occurred when I tried to run the tutorial part 2).
Additionally, I noticed a similar error reported in issue #1100 was happening when attempting to save a rotor .toml file containing a BallBearingElement. As a result, some adjustments were made to the save() method of the BearingElement class.


Add an option to use html5 canvas as a rectangle material

Canvas has very useful capabilities and it would be great to be able to use it directly as a material.
I thought of Something like this:
var entity = viewer.entities.add({...});
var canvas= document.querySelector('#canvas');
entity.rectangle.material=canvas;

For now one can use code that looks like this:
var entity = viewer.entities.add({...});
var canvas= document.querySelector('#canvas');
entity.rectangle.material=canvas.toDataURL();

but this way is not very efficient...

I'm surprised this doesn't work already, but I agree we should support it.

I would like to know the status of supporting canvas with rectangle geometries. The use of canvas. in materials instead of toDataURL() will greatly improve the performance of my Cesium application.
Thanks,
Alberto

@alberto-acevedo thanks for the reminder.  You caught me on a good day so I was able to open up #2667 which adds this capability.

I just tried the new tml5 canvas as a rectangle material capability but there seems to be a problem when rendering more than one canvas. The first time I render a canvas it works fine. But when I tried to render a different canvas,  what is rendered is the first canvas. Is it something I'm doing wrong or is this a bug? My code is below:
var multiPointRectangle =  new Cesium.RectangleGraphics();
var multiPointMaterial = new Cesium.ImageMaterialProperty();
multiPointMaterial.image =  canvas1; //Do not works fine in subsequent calls with different canvas object
//multiPointMaterial.image =  canvas1.toDataURL(); //--> works fine in subsequent calls with different canvas object
multiPointRectangle.material = multiPointMaterial ;
multiPointRectangle.coordinates = ....
var entity = new Cesium.Entity();
entity. _id = "someId";
entity.rectangle = multiPointRectangle;
....  add entity to the viewer entity collection

You might be running into the issue described in #2633.  I'll see if I can reproduce and confirm.


[BUG]: Add new component for user profile display #3910

Changes in This PR
This PR addresses issue #3910 and introduces the following enhancements:

Documentation Improvement: Added a comprehensive description for the lineHeight property to clarify its behavior and usage in React Native.

Website Code Fixes: Resolved issues in the React Native website's codebase to ensure it functions correctly and delivers a seamless user experience.

Testing
I have thoroughly tested these changes on my local machine, and I can confirm that they are running as expected.
Please let me know if you have any questions or need further information.

Hey @Ansh101112, due to lack of response I have decided to make a follow up PR, since missing prop description seems to be quite problematic for some of the docs readers. Thanks again for taking initiative to fix in the first place! 🙏


Increment version for managednetworkfabric releases

Increment package version after release of Azure.ResourceManager.ManagedNetworkFabric

API change check
API changes are not detected in this pull request.


Predict confidence so low that Bboxes predict result are filtered out

use model: yolov4
When I use Yolov4 train model with my own data, I get the model. But when I predict, I found predict result is 0, I was confused, So, I check where has wrong, and I found predict confidence is very small, like this:
[[0.06150062]       [0.05631879]     [0.05217019]]
And this result will lead to predict bboxes all filtered out.
Try to fix:
When I check the code, I found generate label need use anchor and gt_bboxes cal iou, and I found iou is very small, So I guess maybe this anchors lead to this problem, I use k-means cal anchors and change this set, and retrain model, but get the same result.
I use faster rcnn I can get correct result, I want compare yolov4 with faster rcnn, which model is better in our data. Anyone can tall me how I can get correct result.
I suspect yolov4 is not suit my data, but I don't know how to proof it.

this is part of train loss:
=> STEP  623/ 645   lr: 0.000027   giou_loss: 2.52   conf_loss: 1.43   prob_loss: 2.62   total_loss: 6.57 => STEP  624/ 645   lr: 0.000024   giou_loss: 4.47   conf_loss: 6.56   prob_loss: 2.00   total_loss: 13.02 => STEP  625/ 645   lr: 0.000022   giou_loss: 2.26   conf_loss: 1.82   prob_loss: 0.84   total_loss: 4.91 => STEP  626/ 645   lr: 0.000020   giou_loss: 1.95   conf_loss: 1.10   prob_loss: 1.26   total_loss: 4.31 => STEP  627/ 645   lr: 0.000018   giou_loss: 1.85   conf_loss: 3.20   prob_loss: 0.57   total_loss: 5.62 => STEP  628/ 645   lr: 0.000016   giou_loss: 1.12   conf_loss: 1.02   prob_loss: 0.14   total_loss: 2.28 => STEP  629/ 645   lr: 0.000015   giou_loss: 1.13   conf_loss: 1.37   prob_loss: 0.16   total_loss: 2.66 => STEP  630/ 645   lr: 0.000013   giou_loss: 3.03   conf_loss: 4.35   prob_loss: 0.43   total_loss: 7.81 => STEP  631/ 645   lr: 0.000011   giou_loss: 3.39   conf_loss: 2.66   prob_loss: 1.16   total_loss: 7.21 => STEP  632/ 645   lr: 0.000010   giou_loss: 1.18   conf_loss: 1.19   prob_loss: 0.12   total_loss: 2.50 => STEP  633/ 645   lr: 0.000009   giou_loss: 1.74   conf_loss: 2.74   prob_loss: 1.24   total_loss: 5.73 => STEP  634/ 645   lr: 0.000007   giou_loss: 2.88   conf_loss: 2.66   prob_loss: 0.33   total_loss: 5.87 => STEP  635/ 645   lr: 0.000006   giou_loss: 1.57   conf_loss: 2.18   prob_loss: 0.64   total_loss: 4.39 => STEP  636/ 645   lr: 0.000005   giou_loss: 1.31   conf_loss: 1.94   prob_loss: 0.51   total_loss: 3.75 => STEP  637/ 645   lr: 0.000004   giou_loss: 2.03   conf_loss: 2.92   prob_loss: 4.37   total_loss: 9.31 => STEP  638/ 645   lr: 0.000004   giou_loss: 1.10   conf_loss: 1.95   prob_loss: 2.95   total_loss: 6.00 => STEP  639/ 645   lr: 0.000003   giou_loss: 1.62   conf_loss: 2.35   prob_loss: 0.40   total_loss: 4.38 => STEP  640/ 645   lr: 0.000002   giou_loss: 2.35   conf_loss: 1.44   prob_loss: 1.22   total_loss: 5.01 => STEP  641/ 645   lr: 0.000002   giou_loss: 0.86   conf_loss: 2.05   prob_loss: 3.07   total_loss: 5.98 => STEP  642/ 645   lr: 0.000001   giou_loss: 1.42   conf_loss: 3.04   prob_loss: 1.16   total_loss: 5.61 => STEP  643/ 645   lr: 0.000001   giou_loss: 3.12   conf_loss: 2.35   prob_loss: 0.69   total_loss: 6.16 => STEP  644/ 645   lr: 0.000001   giou_loss: 1.23   conf_loss: 1.10   prob_loss: 0.35   total_loss: 2.68 => STEP  645/ 645   lr: 0.000001   giou_loss: 1.26   conf_loss: 1.51   prob_loss: 0.35   total_loss: 3.12

Hello, I think as you said, problems can be in anchors. Anchors may be to small or too big for your dataset bounding boxes so IoU became small. You can generate new anchors using KMeans.  I am using https://github.com/qqwweee/keras-yolo3/blob/master/kmeans.py for this. But, you need to give little changes to this code such as change path to saving, path to annotations and cluster number. Cluster number should be 18.  Although, problems may be not in anchors, but in your dataset. Check your dataset, please. Write if that worked.


Accessibility utility class for hiding elements but making it visible only for screenreaders, not breakpoint specific.

I know Foundation has utility classes for that. However they all are resolution related like for eg hidden-for-small-only
But I would like to have one class to just make the element screenreader only for all breakpoints.
Something like hidden-for-all.
What do you think?

Hey there.
There actually is an undocument class named "hidden-for-small-up" which will hide it on all resolutions.
Regards,
Lyn.

Thanks a lot for the answer. So it basically means that this "issue" should be either clarified in documentation or be rewritten => simplified to one class to hide for all resolution

We're actually wondering that right now for Foundation 6. While we were doing the accessibility push we ended up with a slew of new accessibility-focused visibility classes, which also have sizing classes (visible-for-small, hidden-for-medium). But how necessary are those, really? If you're using AT to read a web page, it seems like the screen size wouldn't really matter; just the text.
If that's the case, there are two basic scenarios you'd want:

Not visible on screen readers, by using aria-hidden="true"
Only visible on screen readers, by using a CSS class that does that clipping trick

Does that make sense, or do we need all of these responsive accessibility sizing classes? They add a lot of weight to the CSS.

I agree on that it is rather not usual to have the need for size-based accessibility. Personally, I'm always good with one (either the .visuallyhidden from HTML5 boilerplate or the .hidden-for-small-up, which Lynesth mentioned). Tbh, I currently prefer adding the .visuallyhidden to my CSS, since the other one is pretty inconvenient. So from my point of view we're good with one class for all sizes, with a shorter name like just .hidden.

That's what I thought. Right now in our Foundation 6 alpha we have just two helper classes:

.hide-for-sr: visually hides content while allowing AT to read it. It uses the element-invisible() mixin that Foundation 5 already has.
.show-on-focus: hides content unless it has focus, for creating skip links.

No idea how many people are actually using the current accessibility visibility classes, but we can't really remove them since that's a breaking change. We could add the above two classes for now as a stopgap, though.

@gakimball : I agree that a simple .hide-for-sr will be enough but if it's going to be in Foundation 6, the increase in version number should allow the removal of useless classes. People will not just upgrade their projects which are already in prod from 5 to 6.
I mean, that's what a major increase in version means : that some stuff are not BC.

@Lynesth Yeah, we're being really aggressive with how we trim the codebase going from 5 to 6. The upgrade path is going to be more difficult than it was going from 4 to 5, but the codebase really needs it.

That absolute make sense @Lynesth I was actually looking for something simple like one class .hide-for-sr. Removing the legacy with size dependent accessibility classes is way to go with Foundation V6. Can't wait for the new V6.


Switch tx gauge vec to counter vec

Summary
Switch gauge vec to counter vec so that the block generator can compute tps. This probably causes problems for the grafana dashboard.
Test Plan
Manual testing at this point.

Codecov Report

Merging #909 (e829ad3) into fix/metrics (a12ec04) will not change coverage.
The diff coverage is 0.00%.

@@             Coverage Diff              @@
##           fix/metrics     #909   +/-   ##
============================================
  Coverage        58.04%   58.04%
============================================
  Files               40       40
  Lines             4636     4636
============================================
  Hits              2691     2691
  Misses            1614     1614
  Partials           331      331

Impacted Files
Coverage Δ

cmd/algorand-indexer/daemon.go
24.59% <0.00%> (ø)

Continue to review full report at Codecov.

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


New KDE implementation

Fixes the issues described in #1335, and down from ~30% to ~5% of sample set conversion runtime. It could be sped up further by taking advantage of sortedness and batching all the samples between each set of points, but apparently that's not so important for now.
The arithmetic gets pretty tough. I tested a model in BQN while I was developing but haven't written tests for the JS translation yet.
I removed the min and max parameters, since we're not using them. To add them back, we'd need to scale the kernels for points that fall off the edge. The way pdfast does this requires the sample values to be rounded, making it useless, but it shouldn't be that hard to implement from scratch.

Codecov Report

Merging #1339 (d1865fb) into develop (59f1899) will increase coverage by 2.40%.
The diff coverage is n/a.

@@             Coverage Diff             @@
##           develop    #1339      +/-   ##
===========================================
+ Coverage    52.11%   54.52%   +2.40%
===========================================
  Files           19       19
  Lines          401      420      +19
  Branches        23       22       -1
===========================================
+ Hits           209      229      +20
+ Misses         190      189       -1
  Partials         2        2

Impacted Files
Coverage Δ

...rescript/Distributions/SampleSetDist/KdeLibrary.js
97.14% <0.00%> (+9.64%)
:arrow_up:

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

This seems like a tricky algorithm to implement well, kudos for this version.
After it gets cleaned up (and merged), I'd be curious about versions that are optimized more for long tails. There must be a few clever tricks we could do to improve accuracy a lot.

Slava asked why we round the kernel width, so I'll expand on that here. The pdfast library required this... and did lots of other questionable things. But it's worth noting that the kernel width we start with is only ever a heuristic and it should be fine to change it a little.
My reasoning is that a triangular kernel with a width (distance from midpoint to edge) that's a multiple of the step size always has the same sum regardless of where the sample is located. For every discrete x value on the left edge of the triangle, adding the width gives a corresponding point on the right edge and the sum of these two values is always the height of the triangle.  A width that isn't the multiple of the step size doesn't have this property, and one with width below 1/2 can even contribute 0 probability mass to the total.
It's possible to rescale or to use integrals instead of y values from the kernel. I don't think there's any real benefit to doing this because adjusting the width shouldn't be very significant.

I was figuring this out what this code does, and in the process of it had an idea of how to do real integration, so I just went ahead and implemented it.
I'll post it here as a snippet, and unless we find some significant problem with it, I'd prefer we go with it instead of Marshall's implementation, since it seems clearer to me, and I like that it does what it's asked for, instead of modifying the given kernel size.
It also turned out to be more performant than the version in this PR! I'm surprised about it, because, as Marshall pointed to me yesterday, I have to loop over samples three times instead of only once, and sample set is usually 10x larger than the point set in our default settings.
In my benchmarks it's >2x times faster, though.
A few ideas why that might be the case:

no anonymous functions (I'm still convinced that forEach and map can be pretty slow compared to naive for loops)
maybe Marshall's version was doing out-of-bounds lookups somewhere? I heard that might cause slowdowns
I'm also doing normalization in the same loop, since the integral of KDE is easy to precalculate

I'm not sure if bins should be positioned in the way I did it (see the first comment), but it's easy to adjust, and doesn't seem very important.
const integralKDE = (samples, size, width) => {
  // Calculates the KDE function with triangular kernels of `width` width.
  // We store the KDE function as a set of evenly spread out `size` discrete points, so we have to calculate the integral for each bin centered around that point.
  // Leftmost bin is positioned such that the center of it covers the leftmost non-zero point in KDE.
  const len = samples.length;

  // The overall idea is to move from left to right and track the value of (1) KDE value (2) integral of the current bin at each juncture.

  // We need to process all junctures in KDE in order to do this, so we're going to keep track of three indices over the sample set.
  // Each triangle can be represented as a sum of three ramp functions (https://en.wikipedia.org/wiki/Ramp_function):
  // 1) `up1(x) = max(x - sample + width, 0)` (becomes positive when x > sample - width)
  // 2) `down(x) = -2 * max(x - sample, 0)` (becomes negative when x > sample)
  // 3) `up2(x) = max(x - sample - width, 0)` (becomes positive when x > sample + width)
  let up1Idx = 0,
    up2Idx = 0,
    downIdx = 0;

  // leftmost and rightmost non-zero points in KDE
  const min = samples[0] - width;
  const max = samples[len - 1] + width;
  const step = size > 1 ? (max - min) / (size - 1) : 0;

  // This is the total integral of KDE, width * width is the size of each triangle.
  // It guarantees that the sum of `ys` in the final result is always `1`.
  const normalizer = len * width * width;

  let dy = 0; // slope of the KDE function, increments and decrements in integers
  let y = 0; // we track the value of the KDE function after each bin to add it to the area under the curve.

  const xs = [],
    ys = [];

  for (let i = 0; i < size; i++) {
    // Each bin is centered around x and covers the [x - step/2 ... x + step/2] interval.
    const x = min + i * step;
    const binEnd = x + step / 2;

    // Area under the curve is the main value we calculate.
    let area = y * step + (dy * step * step) / 2;
    y += dy * step;

    // Each ramp function can affect:
    // 1) The slope (dy)
    // 2) The area for the current bin
    // 3) The KDE value at the end of the current bin (y) that we need to calculate the area for the subsequent bin.
    // Here we process all possible junctures (of three kinds) that fit in the current bin and update the slope, area and the KDE value accordingly.
    while (up1Idx < len && samples[up1Idx] - width < binEnd) {
      const w = binEnd - (samples[up1Idx] - width);
      y += w;
      area += (w * w) / 2;
      up1Idx++;
      dy++;
    }
    while (up2Idx < len && samples[up2Idx] + width < binEnd) {
      const w = binEnd - (samples[up2Idx] + width);
      y += w;
      area += (w * w) / 2;
      up2Idx++;
      dy++;
    }
    while (downIdx < len && samples[downIdx] < binEnd) {
      const w = binEnd - samples[downIdx];
      y -= 2 * w;
      area -= w * w;
      downIdx++;
      dy -= 2;
    }

    xs.push(x);

    // We could get slightly negative `area` values due to rounding errors, so we're making sure here to always store non-negatives.
    ys.push(Math.max(area / normalizer, 0));
  }
  return { xs, ys };
};

Okay, this passes most tests if the weight parameter is added and it's normalized with normalizer = width * width * step / weight. There's still a problem with using width to adjust the boundaries, because the value of the integral is still nonzero out to width + step / 2. It means there's probability mass outside the chosen range, so the result isn't normalized. To fix this I guess you'd first compute the step with a denominator of size - 2, then re-adjust the edges.
It doesn't seem any clearer to me. There's a lot more math in the integration. More importantly there's no ground truth to test against like the direct KDE evaluation I used. It's not too hard to figure out the kernel it's using, and I did realize eventually that away from the corners it's the same as the normal triangular kernel, because it's averaging a sloped line. Still, extra work we don't have much reason to do.
After digging through so many possibilities... the performance difference is almost entirely due to the call filter(samples, isFinite). If I remove that my version measures 10% slower or so, and if I rewrite the ysum writing loop as follows it's 20% faster.
  for (let i = 0, j = 0; i < size; i++) {
    const begin = min + i * dx;
    const end = begin + dx;
    const j0 = j;
    let left = 0;
    while (j < len && samples[j] < end) {
      left += samples[j] - begin;
      j++;
    }
    const right = dx * (j - j0) - left;
    ysum[width + i + 1] += right;
    ysum[width + i + 2] += left;
  }

I can't reply to the comment on numChecks for some reason. The array length fast-check uses here is usually small, less than 100 even. There's nothing in the KDE that should change with large numbers of samples (the width doesn't even depend on sample count), so that seems fine for testing.

I think I have a better handle now on point evaluation (pdfast and my method) versus area (Slava's). As I mentioned, the area method is equivalent to point evaluation with a different kernel: specifically a triangle convolved with a rectangle of width step/2 centered around 0. This is because the area of a function around a given point is the integral of a rectangle centered at that point times the function, or the value of funtion * rectangle (using * for convolution here) at that point. So the area method gives function * triangle * rectangle, and convolution is associative.
The area-based kernel does ensure that the sum is constant, so no width adjustment is needed. As I mentioned above, the value away from the corners is the same as a triangular kernel. Where the corners were there are now quadratic sections joining the straight parts. I believe the maximum difference between the two kernels is proportional to the step size, so that the integral of the difference is proportional to step size squared, very small.
Both approaches end up spreading some weight from the tip of the triangle to the edges most of the time. For point evaluation it's because linear interpolation on the results cuts off the corners. This effect varies based on where the triangle is located: it's perfectly accurate if the center is on one of the x points and largest if it's halfway between two of them. With the area-based kernel it's more even, but I don't think it's perfectly so.
It might seem that stepwise interpolation is better to represent area-based KDE, but linear interpolation is a lot better because the area mostly changes linearly.
Overall I think any of these differences including the width adjustment aren't important because any error decreases with the step size or faster. They haven't been discussed in any of the material on KDE I've read and this is probably why.

@mlochbaum interesting, thanks for figuring all this out!
Yeah, when I did my area implementation I assumed that pointset is a histogram consisting of rectangular blocks and didn't think about this enough; I realized since that this is not the case (I looked up how integration in XYShape is implemented, it's used not just for rendering for for other operations too).
I agree that if we use linear interpolation then area evaluation approach becomes more dubious / adds more noise, and I agree that linear interpolation probably makes more sense for pointsets.
I still think that your implementation is pretty hard to understand, though. Both algorithmically ("each triangle is indistinguishable from a sum of two triangles with peaks at the sample's two nearest neighbors" — I checked this against a few examples and it seems right, but unless I'm missing some trick, it's a pretty non-trivial statement) and why it's correct (why width adjustment is safe).

I'm going to merge this as is.

the PR is getting stale and I want to get to #1359 which is built upon it
Marshall probably won't do much more work on this and it seems bad to delay this further
I might rewrite the KDE calculation in Marshall's version with my three pointers trick in the future (that would be functionally equivalent to the code in this PR, but seems clearer/more straightforward to me), but it's not important right now
and we'll have to rethink this from scratch when we implement variable bandwidth or gaussian kernels, anyway


Add New Structure Object

New Object: Structure
Adding structures to the specification enables data publishers to inform drivers about structures that affect safe and efficient travel.  Informed drivers and wayfinding applications can reroute drivers to avoid such structures.  Bridges are a good example; They often have height, width, length, weight, or axel restrictions.
Possible Structure Types Include:  Bridge, Overpass, Aqueduct, Tunnel, Cut, Gallery, Retaining Wall, Embankment, Railroad, Building.
Benefits

Enables publishes to inform drivers about structures and their restrictions.
Mitigates loss of life, personal injury, infrastructure damage, lost time and money, unnecessary emissions, and all the other ill effects of incompatible vehicles traversing restricted structures.
Fosters in-vehicle warnings about hazards to navigation.
Extending the specification may draw more agencies into using the Work Zone components of the specification.

Costs

Diversifying the specification is off scope.

Alternative

Associate a Road Event with a structure type by adding a structure property or a structure subclass.

Support

NY State DOT has expressed interest.

Examples

Proposed Model
Mapped Structures
Mapped Structures with Restriction Notices

What is the value of adding these structures? It appears to me that all of the benefits listed here will be achieved by adding the restriction-notice EventType (#178) and allowing a value and units for road event-level restrictions (#155).
I think there is no end to the list of possible structures that could be added, which is problematic. If the purpose is to show an area where there is an effect (restriction) to the roadway, that can be achieved using the updated restrictions property on the RoadEvent object and the restriction-notice event type.
As discussed in the closed issue #156, the consensus of WZDx members seems to be that WZDx should not be used to represent the base details of a roadway (i.e. asset layer), just notable effects to travelers due to road work or a restriction due to a structure. I see minimal value in knowing that a restriction is due to a particular structure type, just that there is a restriction. If the structure does not lead to a restriction, then there is no point in representing it.
Let me know if I am missing potential use cases. The benefits listed above are just not substantial enough to convince me of the value.
I would also like to hear from any prospective consumers regarding why they would want structure information and how it would be used.

Maximizing Benefits
The Work Zone Data Specification is an amazing piece of collaborative work.  There is no doubt in my mind its implementation will save lives.  However, we squander the specification’s potential impact by restricting its use to describing only work zones.  Restricting its use reduces the specification’s social benefit by making only a portion of the population safer.  To maximize the specification’s social benefit we need to extend it, in a controlled manner, to enhance the safety of the most people possible.
I agree scope creep is an issue.  We deflect resources away from the work zone data specification by developing non-work zone features.  To overcome this issue the WZDx Working Group established the Extension Subgroup.  It investigates potential features without syphoning Work Zone Data Specification resources.  I argue the extension subgroup, and its exploration of different uses, strengthens the specification by making it more useful which fosters participation and implementation.
Don’t Comingle Object Types
Good data modeling practices dictate we not comingle objects and properties.
Costs
Not sure what this adds up to, let’s say $20,000.00

5 hours identifying candidate features
5 hours prioritizing features
5 hours modeling
100 hours socializing the idea via meetings and discussions
IT Costs (Software, Hardware)
Fork, Develop, Pull Request, Adopt

Benefits
The purpose of geospatial data is to inform decisions.  Including structures in the specification will foster better decisions and facilitate safe travel.  If we can save one life, prevent a single injury, or avoid damaging a single bridge the effort will probably net a social benefit.
I can’t think of every use case in which mapped structures might inform decisions; there are too many.  Here are a couple:

Structures fulfill the same purpose as the beginning_cross_street and ending_cross_street propertiesin the Road Event object – informed spatial awareness fosters better decisions.
Routing oversized loads around restrictive bridges
(After writing this, there is probably a case for spatially enabling the cross streets.)

Consumer Interests
The 4 co-chairs of the extension subgroup, representing Google, Here, the National States Geographic Information Council, the New York State Department of Transportation, The US Department of Transportation and the Federal Geographic Data Committee, spent a few hours identifying candidate features for inclusion in the specification.  All agreed low clearances were the top priority.  Three of the four initially identified bridges as a priority.  All agreed bridges were a priority after discussing the candidate list.  I would like to hear from more prospective consumers too.
Implementation
This is an optional element.  The burden of including it as a test feature in the specification is minimal.  If it’s useful, demand for it will grow and we can keep it.  If it’s not useful, demand for it will wither and we can toss it.  Either way, we should have room to test new features.

I like the structures concept.  While it is true that restrictions could be conveyed as restrictions, the people who will provide this data think in terms of structures.  When we workshopped this with NSGIC we started with clearance as a priority.  the group was quick to add posted load and width restrictions on structures.  The structures will also be a useful for wayfinding providers to communicate to drivers.  'this restriction is on the Western Gateway Bridge'.

I have been hearing a lot of aspirational expectations of WZDX – more or less growing into the conduit to communicate any critical information to either travel websites of mapping companies.  I am both encouraged and hesitant with these aspirations.
That is where my thoughts on this structures suggestion for an object.   I am both encouraged, but hesitant, be it weight limits or height restrictions --- this information is definitely needed, but at the same time I question of whether WZDX is the location or appropriate conduit.  I have been rather silent on the calls – half because I am treading water coming up to speed, but also due to these larger issues of scope.
I have heard (in other venues) the hope to grow the WZDX into a conduit to communicate fundamental network changes (new interchange, bypass, state route) to mapping companies.  Again – yes it is needed, but the scope on WZDX is turning into ‘everything we need to communicate outwardly’.  Should we instead stub these out and get going on the next standard digital interface(?)
Perhaps we need to simply to fork the effort – keep WZDX thematically pure to works zones, and simultaneously create the bridge and structures data feed (BSDX) – for height, weight, length restrictions targeted for specific group of vehicles, typically large vehicle or commercial vehicles.  Similarly, with fundamental network changes (new roads, bypasses, etc.) get involved / start an effort in the mapping space to set up standard conduits for these changes.  The TETC is getting the participants at the table now in this arena.
I feel there is a ton of work to be accomplished in this digital interface space between DOTs and industry, and if we try to squeeze into this one pipe (WZDX) it may burst.

I love this discussion!

Perhaps we need to simply to fork the effort – keep WZDX thematically pure to works zones, and simultaneously create the bridge and structures data feed (BSDX) – for height, weight, length restrictions targeted for specific group of vehicles, typically large vehicle or commercial vehicles. Similarly, with fundamental network changes (new roads, bypasses, etc.) get involved / start an effort in the mapping space to set up standard conduits for these changes. The TETC is getting the participants at the table now in this arena.

@seyoung1991 I agree about the structures being a separate feed (if there is continued demand to address them), not part of the WZDx feed.
See #191 for another example of a new feed and things to think about when implementing a structures feed and how it fits in and is presented alongside WZDx.

Closing for a lack of interest at this point.


make test failed in case of usign fips

We have compilation problem, when we tried to build the openssl 1.0.1s
test SSL protocol
test ssl3 is forbidden in FIPS mode
*** IN FIPS MODE ***
Available compression methods:
1: zlib compression
47155267252048:error:140A9129:SSL routines:SSL_CTX_new:only tls allowed in fips mode:ssl_lib.c:1720:
47155267252048:error:140A9129:SSL routines:SSL_CTX_new:only tls allowed in fips mode:ssl_lib.c:1720:
test ssl2 is forbidden in FIPS mode
Testing was requested for a disabled protocol. Skipping tests.
make[1]: *** [test_ssl] Error 1
make[1]: Leaving directory `/usr/src/openssl/openssl-1.0.1s-1.syslogng50.12/test'
make: *** [tests] Error 2

I think this is caused by disabling ssl2 by default. But in this case the testfipsssl will fail,
because the ssl2 test will return 1
If I comment out the $ssltest -ssl2 $extra && exit 1, then the make test will passed
echo test ssl2 is forbidden in FIPS mode
$ssltest -ssl2 $extra && exit 1

OK, problem is solved by patch: f4bed7c7b6fe8459dbc14e28f91c6150013b9c5e


feature: support disabling and providing custom SSL certificates

We currently support it for the provider but not the broker itself. I think we should:

Support disabling SSL for the broker interactions
Support specifying custom certificate paths for the broker and the verifier (ideally supporting the OpenSSL convention of the SSL_CERT_FILE and SSL_CERT_DIR environment variables).

See https://github.com/pact-foundation/pact-js/issues/736 for background, it may already be partially supported through the reqwest dependencies.

I believe the issue is that the reqwest dependency uses the rustls-tls feature which uses webpki-roots (basically a vendored certificate store, always ignoring anything about the local system's configuration). The proper fix would be to switch to pulling rustls-native-certs which will do the right thing (same rules as openssl on Linux, use schannel on Windows, security-framework on MacOS).

The problem was due to supporting musl based distributions like Alpine, we switched from openssl to rustls-tls. As long as rustls-native-certs does not require openssl, we can try use that.

Another option would be a top-level feature (which can at least be selectable on the CLI) for deciding what to do (whether that feature is turning musl-compatibility on or switching to native certs is up to you). I understand the desire to make lightweight/static builds easy/possible, but ignoring system standards makes using/supporting tools very difficult.
For companies that use intercepting proxy servers (a lot of companies) or anyone who has internal PKI infra (which lets companies issue certificates for internal services), you can't currently use these pact tools unless you completely disable certificate verification.

Is this all that is needed? It looks like there is now an Alpine specific feature flag that can be enabled, but not sure it works like that: https://github.com/pact-foundation/pact-reference/pull/149

hmm the segfault says otherwise: https://github.com/pact-foundation/pact-reference/pull/149/checks?check_run_id=3647761625#step:3:663

That change was to use the platform TLS support, which means linking to the openssl libs on Linux. We don't want that.
What we need is either to be able to use the Rust TLS support, but use the system root certs (which I assume is what rustls-native-certs does, but I haven't looked into it.), or we need a compile time feature flag to only use Rust TLS when building on Alpine Linux. It can't be a runtime flag (like a CLI switch).

The other option would be to drop Alpine support, which will make a lot of things easier, but anger a lot of people. :-D

I was hoping that adding native-tls-alpn (the alpine variant) magically would work.
Now that I look at the options again, it looks like rustls-tls-native-roots might be what we want?

That PR passed now - does that mean it just works ™ ?

That means it's compiling, on Alpine, which is 90% of the battle :-D
But it doesn't test access to a broker using TLS and custom supplied root certs.

I pulled and built the branch locally. It correctly picks up our enterprise root certificates and can now connect to an endpoint that was previously inaccessible.
(This is Linux with regular glibc, not musl)

That works for me. If it builds on musl, I'm sure it will behave in the same way.

Just tested on my OSX env by importing (and trusting) the baddssl certificates into the keychain - works a treat (much better than an env var, obviously).

For some reason certificate verification still isn't working for me on Windows, will keep you posted

I take it back - this works on Windows (the server I was testing against was misconfigured and wasn't sending the intermediate certificate)


Fix ssh keyscan for urls with ports

Hostname() returns Host without any port number.
This shouldn't clash with #561 looking at the diff, but should be complementary.
Closes #564.

Of course this doesn't actually work. ssh-keyscan doesn't know which port to scan the remote host on. We need to supply a -p $PORT to ssh-keyscan.
But it's more complicated again becasue ssh-keygen -F which tests the presence of the host in the existing known hosts file doesn't understand port numbers.
We're also dumping the comments and errors which ssh-keyscan outputs to stderr into the known_hosts file which we shouldn't be doing. I had invalid lines in my known hosts after scanning a host which couldn't be connected to.
I'm thinking we might need to own this stuff entirely and use something like x/net/ssh/knownhosts or fleet's known_hosts to test for the presence of the host, then parsing the output of ssh-keyscan and only adding good entries to the file. Or something.

Hmmm. Sounds deeply unpleasant.

My vote would be getting x/net/ssh/knownhosts into https://github.com/buildkite/agent/pull/561

Yeah, that's where I was leaning.


invalid response from .well-known/acme-challenge

nginx misconfiguration, closed.

false issue.

How did you fix it?

@jasonrichdarmawan Yes, what's the code?


Emailpassword reset password

closes #431

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 91.784%

Totals

Change from base Build<PHONE_NUMBER>:
0.0%

Covered Lines:
391

Relevant Lines:
426

💛  - Coveralls


implemented functor visitEvent on FluentFunctions

Implemented functor visitEvent on FluentFunctions and JUnit test cases

Awesome, thanks Will - could we add this functionality to the FluentBiFunction and FluentTriFunction classes also?

Hi @johnmcclean-aol , sure, I will add it on Wednesday and get it PRed.


exponential decay

Hi,
Exponential function works for exponential growth but not exponential decay. Do you have any suggestions how to fix it?
Bests

I've had the same problem (in MATLAB though).
If {(x,y)} is your original data with exponential decay, then {(x,1/y)} will have exponential "growth". So you can fit and exponential function to {(x,1/y)} leading to a function, say f(x)=aexp(bx) and then use g(x)=1/f(x) as the regressor for your original data.


[misc|usecase] Update inst.deb.py script file

Update code to native mode in order that run in deepin platform
Remove some unwanted function
Test successfully

LGTM


Ruby head canary test coverage

The setup-ruby action seems to support installing Ruby head, which I presume means we are able to work off the latest development version pulled from GitHub.
https://github.com/ruby/setup-ruby/blob/6bd3d993c602f6b675728ebaecb2b569ff86e99b/ruby-builder-versions.json#L16C6-L16C10
Adding test coverage for head will allow us to prepare for future unexpected issues and incompatibility but should not prevent us from releasing.

If the test suite runs for head on every PR, an unrelated failure would break every CI run.
It feels like this should run at regular intervals (weekly?) and open an issue if there's a failure.

@dmathieu I should have been more explicit but that is what I mean by making a canary build as opposed to having it run on CI every time a PR is opened or merged:

Adding test coverage for head will allow us to prepare for future unexpected issues and incompatibility but should not prevent us from releasing.


Known models only working for Lenovo

After upgrading to the newest version and applying the hotfix, the known model function no longer works for HP or Microsoft products. The Process Log correctly shows 16 known models found in the Query Known Models run but none are selected during the Select Known Models run. I have confirmed the OS versions being queried exist in the HP XML for the expected Known Models. Previous installed version was downloaded 2020-30-3.

Issue resolved itself without a reboot or anything done. Seems to have been a timing issue.


Launcher ask to "confirm replacement" when extracting

Fixed by #599 and available as https://github.com/MovingBlocks/TerasologyLauncher/releases/tag/v4.1.2


[Request] Asar7z

http://www.tc4shell.com/en/7zip/asar/

Asar7z is a small plugin for the popular 7-Zip archiver. You can use Asar7z with 7-Zip to open, modify, or create .asar archives, which are used for packaging applications based on the Electron framework.

to use this plugin, we should have 7zip preset dir for Formats folder to place the plugin dll files https://github.com/ScoopInstaller/Main/issues/992


fix(import): incorrect and unnecessary properties recorder to cdk8s.yaml on cdk8s import

When an import is specified with an alias, i.e cdk8s import<EMAIL_ADDRESS>the alias is being ignored when saving it to the configuration file. This creates duplicate import entries, one with the alias and one without.
In addition, default configuration values that were only meant for in-process operation are written to the config file on import - this should not happen.
Also added a --no-save flag that skips writing the import to the file. This can be helpful if users have comments in cdk8s.yaml, which cannot be preserved upon rewrite.
Fixes https://github.com/cdk8s-team/cdk8s/issues/1442

💚 All backports created successfully

Status
Branch
Result

✅
1.x

Questions ?
Please refer to the Backport tool documentation


feat(starredEntitiesCard): show title if defined & hide unregistered entities

Signed-off-by: Phil Kuang<EMAIL_ADDRESS>Hey, I just made a Pull Request!
Closes #11185
:heavy_check_mark: Checklist

[x] A changeset describing the change and affected packages. (more info)
[ ] Added or updated documentation
[x] Tests for new functionality and regression tests for bug fixes
[ ] Screenshots attached (for UI changes)
[x] All your commits have a Signed-off-by line in the message. (more info)

Maybe just mock the catalog api in the storybook too? (I believe thats needed?) https://github.com/backstage/backstage/blob/master/plugins/home/src/homePageComponents/StarredEntities/StarredEntities.stories.tsx

ah good catch! updated!


Can't create package for net6.0-windows

Type (choose one):

Bug

NPE version: 6.0.64+c118e46e01 (Installed via Store)
OS version: Windows 10 - 22H2 (19045.2311)
Installed from: Microsoft Store
In case of a BUG:

What is the current result?

Create a new package
Add a lib folder
Add a net6.0-windows folder under lib
Add any valid dll to the net6.0-windows folder
Try and save the package
The following error appears and the package is not saved
Some included files are included under TFMs which are missing a platform version: net6.0-windows

What is the expected result?

Package created
Possibly related: https://github.com/NuGet/Home/issues/10845

As a workaround, renaming the folder to net6.0-windows7.0 works for creating the package

Hi @MatthewSteeples
Does it occur when using net5.0-windows too?

Fixed in my branch


Docs Redesigned to Aiden Colors

Color scheme has been changed, layout updated, and a navbar has been added.

Thanks @kohterai!


Replace the Sort component in /works with the new one

Following #8859 we'll look at changing the sort used in /works and use the new one

I'll move this to Blocked for now; it required a lot more changes than expected (the way the form is currently built + routing), and after discussing it with @jtweed last week, we're just not convinced that's where efforts should be focused as I only have a week left before the new year. I'd like to suggest leaving the PR open until I come back from holidays, see then if we find it valuable, but in the meantime I'll focus on the other aims we set for the week.
See PR here: https://github.com/wellcomecollection/wellcomecollection.org/pull/8943

We've agreed not to move ahead with this as we'll shortly be redirecting/deleting the only page that has the old sort component.
I added deleting the old component in the new search release plan.


svviz seems to take a lot of time on some SV's

Hi Noah,
Is there a limit on the SV size that can be visualized with svviz. I’ve been having a little bit of trouble visualizing some deletions/inversions >20kb, probably because of the large number of reads spanning these breakpoints.
This is on Whole Genome Sequencing data on a tumor/normal pair. I assume it’s just that the big events have a lot of reads which takes a while, for e.g I got this message "LOTS OF READS IN REGION:8 43094789 43094790 1227892” for one of the events.
I’ve only waited for a maximum of ~8 hours for some of these events, perhaps I should wait longer? I was wondering if this is expected? Have you thought about downsampling reads perhaps?
Thanks,
Avi

Hrm, you should be no where close to the practical limit of SVs that can be visualized with svviz (should be more over 10mb). The "lots of reads in region” message suggests you have lots of repetitively mapping reads. I’m guessing it’s choking on the step where it’s trying to find the read mates, which are strewn about the genome — if the mates fall in regions of high sequence coverage (eg the bit of chromosome 8 in your example), svviz has to walk through the bam from the closest index point in order to find the read mate of interest, which could take a while.
The easiest solution, if you haven’t already tried this, would be to change the mapq cutoffs; it shouldn’t try to find the mates of reads with low mapq (this only works with --min-mapq, not --pair-min-mapq).
A more general solution would be to give you the option of skipping reads whose mates fall in regions of high coverage. Let me know if the --min-mapq solution doesn’t work, as adding this option should be relatively straightforward.
Should probably improve the documentation around this.

Thanks for the feedback, it does make sense that looking for reads in regions of high coverage could choke.
I tried the -q option(same as --min-mapq) on a deletion of length 47KB, it's taken more than 12 hours at the realign step and is still running, the exact command that I used is below,
./myenv/bin/svviz -t del -b $bam1 -b $bam2 $fasta 2 16332715 16379722 --no-web -e 2:16332715-1       6379722.pdf --summary 2:16332715-16379722.out -q 25

Just to make sure I'm fixing the right problem, can you post the output from svviz so that I know which step it's choking on?
Also, if mapq goes up to 60 in your files, could you just try it with -q 60? Just let me know if it takes more than 5 minutes with that option.

Ok, I checked to make sure that the BAM file has mapping qualities going from [0-60]. I then ran svviz with a cutoff of 60, here's the output after running for about an hour,
   14491  - d0cb366d4727467789c9ddd05f6fde3a
   14492   To-match: 18151, min-mapq: 60.0
   14493   0 18151 starting...
   14494   LOTS OF READS IN REGION:1 121485089 121485090 592721
   14495   1000 18151 9.32695388794
   14496   LOTS OF READS IN REGION:19 27732016 27732017 241936
   14497   2000 18151 4.53237199783
   14498   3000 18151 2.15582108498
   14499   4000 18151 1.64572691917
   14500   5000 18151 1.2749710083
   14501   6000 18151 1.17867612839
   14502   7000 18151 1.2287979126
   14503   8000 18151 1.29893708229
   14504   9000 18151 0.962944030762
   14505   LOTS OF READS IN REGION:10 42388361 42388362 348819
   14506   10000 18151 6.26318287849
   14507   11000 18151 1.27597618103
   14508   12000 18151 1.91607689857
   14509   13000 18151 0.817262887955
   14510   LOTS OF READS IN REGION:2 92315360 92315361 149283
   14511   LOTS OF READS IN REGION:10 42384481 42384482 106801
   14512   14000 18151 4.58829712868
   14513   15000 18151 4.86111187935
   14514   16000 18151 0.904628038406
   14515   17000 18151 1.23500204086
   14516   18000 18151 1.66472911835
   14517   missing pairs: 350
   14518   ** Supplementary alignments found: these alignments (with sam flag 0x800) **
   14519   ** are poorly documented among mapping software and may result in missing **
   14520   ** portions of reads; consider using the --include-supplementary command line **
   14521   ** argument if you think this is happening                                **
   14522   time to find reads and mates:49.6526730061
   14523   number of reads found: 18432
   14524 * Realigning reads *

Okay, so for this run, it seems to be having problems with the realignment step, not pulling in mates as I originally thought.
I tried running the region you're looking at on one of my BAM files and it took 45 seconds to complete running (obviously my bam doesn't have reads supporting the deletion allele, but that shouldn't dramatically affect run time).
Any chance you can share the relevant read data with me? If you use the --save-reads option, you can create a BAM file with only the reads svviz is using for the variant of interest (50,000 reads from a random location on chromosome 1 plus the reads near the event). The file should be roughly 25MB, I think. You could send me a link to the file (box or dropbox or whatever), or I can send you a link for you to upload to.

So that worked fine for me with the files you sent me. I used this command:
svviz -t del -b 2\:16332715-16379722.0.sorted.bam -b 2\:16332715-16379722.1.sorted.bam hg19.fasta chr2 16332715 16379722 -e 2_16332715-16379722.png --skip-cigar
Can you see if you're still having the same problem if you run with the files you sent me, instead of the original BAMs? I'm kind of at a loss for why you might be having this problem.
Just to confirm, after the * Realigning reads * line in the svviz output, you're getting the progress bar for the realignment step, correct?

Yeah you're right, when I run it on just the files that I shared it works fine at my end as well. It's something to do with the original BAM file,
The last line that I see in the logs before the long wait is
 85 * Realigning reads *
 86   Removed 19 reads with only degenerate nucleotides ('N')

I don't see any progress bars. Perhaps I can use a  Python debugger to see whats being executed?

Sure, let me know if you track down the problem. You'll probably want to use --processes 1 so that you don't have to debug across processes.

I'm going to close this issue as it appears to be difficult to reproduce and there's a workaround that works for you. Please let me know if you have any more information on the original issue.

Ok, thanks. Not sure if this is related but when I run it with --processes 1 I get a different error,
#Command
svviz -t del -b $bam1 -b $bam2 /gscmnt/gc2607/mardiswilsonlab/aramu/dat/hs37/all_sequences.fa 2 16332715 16379722 --no-web -e 2:16332715-16379722.pdf --summary 2:16332715-16379722.out --processes 1

#Output
set(['A', 'C', 'T', 'G']) 100 AAGACAGTTGGGCAACTTCATGTGAAGCACGTTTCCCTCACTTCAGAATCCCTCCCTCTTGGAAGTGAACACAAGGACTTGGATGGTTCAGCTTCACTCT
set(['A', 'C', 'T', 'G']) 100 TGATAGCTGGCCTTTTTCAAAAGCATTCCGGCCTGCTAAACAGTGGCCTTTCATGATTTACAAGTTTGGAATCTTTGAGAATTTTCAACAATTAAGGTAC
set(['A', 'C', 'T', 'G']) 100 ACGTGTGAAGTTACAGTCCAGAGCAGGCACTGTCAGATAGTAACTCCAAAGGCTCAGGAGGAAACACTTGCTTTAGCTTAGCATGTCACTGTTTTCGAAG
Traceback (most recent call last):
  File "/gscmnt/gc2607/mardiswilsonlab/aramu/src/svviz/myenv/bin/svviz", line 9, in <module>
    load_entry_point('svviz==1.3.1', 'console_scripts', 'svviz')()
  File "/gscmnt/gc2607/mardiswilsonlab/aramu/src/svviz/myenv/lib/python2.7/site-packages/svviz/app.py", line 296, in main
    run(sys.argv)
  File "/gscmnt/gc2607/mardiswilsonlab/aramu/src/svviz/myenv/lib/python2.7/site-packages/svviz/app.py", line 267, in run
    runRemap(dataHub)
  File "/gscmnt/gc2607/mardiswilsonlab/aramu/src/svviz/myenv/lib/python2.7/site-packages/svviz/app.py", line 89, in runRemap
    sample.alnCollections = remap.do_realign(dataHub.variant, sample.reads, dataHub.args.processes)
  File "/gscmnt/gc2607/mardiswilsonlab/aramu/src/svviz/myenv/lib/python2.7/site-packages/svviz/remap.py", line 198, in do_realign
    refalignments = do1remap(variant.chromParts("ref"), reads, processes)
  File "/gscmnt/gc2607/mardiswilsonlab/aramu/src/svviz/myenv/lib/python2.7/site-packages/svviz/remap.py", line 141, in do1remap
    aln = chooseBestAlignment(read, remapped[read.seq], chromPartsCollection)
TypeError: list indices must be integers, not str

Just posting here for posterity's sake, I'll let you know if I figure out the original issue.

Alright, that's a separate bug which should be fixed in the master

Just an update - We're still seeing this happen with some SV's. The program runs at 100% CPU for hours but it's not able to finish running. Not sure, if this has something to with our internal setup here but we've seen this across multiple BAMs by a couple of users.
Running strace on a process shows this log,
.....
.....
lstat(/dev/shm/sem.nAEKMZ, 0x7fff59d01560) = -1 ENOENT (No such file or directory)
open(/dev/shm/sem.nAEKMZ, O_RDWR|O_CREAT|O_EXCL, 0600) = 13
write(13,<PHONE_NUMBER>0000000000000000000000, 32) = 32
mmap(NULL, 32, PROT_READ|PROT_WRITE, MAP_SHARED, 13, 0) = 0x7f749d048000
link(/dev/shm/sem.nAEKMZ, /dev/shm/sem.mp2510-71) = 0
fstat(13, {st_mode=S_IFREG|0600, st_size=32, ...}) = 0
unlink(/dev/shm/sem.nAEKMZ)           = 0
close(13)                               = 0
unlink(/dev/shm/sem.mp2510-71)        = 0
write(1,  total time elapsed: 3.53334498..., 71  total time elapsed: 3.53334498405
used rsvg-convert to export to PDF
) = 71
clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0x7f749d01c9d0) = ? ERESTARTNOINTR (To be restarted)
--- SIGPROF (Profiling timer expired) @ 0 (0) ---
rt_sigreturn(0x1b)                      = 56
clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0x7f749d01c9d0) = ? ERESTARTNOINTR (To be restarted)
--- SIGPROF (Profiling timer expired) @ 0 (0) ---
rt_sigreturn(0x1b)                      = 56
clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0x7f749d01c9d0) = ? ERESTARTNOINTR (To be restarted)
--- SIGPROF (Profiling timer expired) @ 0 (0) ---
rt_sigreturn(0x1b)                      = 56
clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0x7f749d01c9d0) = ? ERESTARTNOINTR (To be restarted)
--- SIGPROF (Profiling timer expired) @ 0 (0) ---
rt_sigreturn(0x1b)                      = 56
clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0x7f749d01c9d0) = 4874
wait4(4874, 0x7fff59d02664, WNOHANG, NULL) = 0
clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0x7f749d01c9d0) = ? ERESTARTNOINTR (To be restarted)
--- SIGPROF (Profiling timer expired) @ 0 (0) ---
rt_sigreturn(0x1b)                      = 56
clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0x7f749d01c9d0) = ? ERESTARTNOINTR (To be restarted)
--- SIGPROF (Profiling timer expired) @ 0 (0) ---
rt_sigreturn(0x1b)                      = 56
clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0x7f749d01c9d0) = ? ERESTARTNOINTR (To be restarted)
--- SIGPROF (Profiling timer expired) @ 0 (0) ---
rt_sigreturn(0x1b)                      = 56
....

and then there's a lot of lines(~100K) which have the clone() and rt_sigreturn() calls.
Googling around brings this and this up, we may have to fly you up here;) Glad to try any suggestions.

Just to confirm, you're using the --skip-cigar option, right?

I think I lost the thread a bit -- can you post the full output from svviz, including the command you're using to run it? If it's crapping out at the realignment step, I might need the original BAM file in order to do some more debugging. Would it be possible to send me the BAM somehow?

I don't think it is necessarily failing in realignment - it seems to hang in a number of different places.  I just ran the following command and it seems to be hanging on * Exporting views *.  By hanging, I mean spinning at 100% cpu and not really doing anything.  If you connect to the process with strace it spits out the clone() and rt_sigreturn() over and over again.
If it is a kernel issue, we may be hosed...unless we could figure out what is causing the problem and compile that without the 'profile' option?
Command:
svviz --type batch --export svviz/cosmic --summary svviz/cosmic.summary --include-supplementary --processes 1 --skip-cigar -b normal_highcov.bam -b tumor_highcov.bam all_sequences.fa deletions_inversions.vcf"

Output:
Namespace(_parser=ArgumentParser(prog='svviz', usage='%(prog)s [options] [demo] [ref breakpoint...] [ref vcf]', description='svviz version 1.3.2', version=None, formatter_class=<class 'argparse.RawTextHelpFormatter'>, conflict_handler='error', add_help=True), aln_quality=None, annotations=None, bam=['normal_highcov.bam', 'tumor_highcov.bam'], breakpoints=['deletions_inversions.vcf'], context=0, dotplots=False, export='svviz/cosmic', fasta=None, flanks=False, format=None, include_supplementary=True, lenient=False, max_multimapping_similarity=0.95, max_reads=None, min_mapq=0, no_web=True, open_exported=False, orientation=None, pacbio=False, pair_min_mapq=0, port=None, processes=1, ref='all_sequences.fa', save_reads=None, save_state=None, skip_cigar=True, summary='svviz/cosmic.summary', thicker_lines=False, type='batch', verbose=3)
* Sampling reads to calculate Insert Size Distributions *
 > normal_highcov <
  counts +/-:49411  -/+:590    +/+:0      -/-:0      unpaired:0
  insert size mean: 322.08 std: 79.20
  valid orientations: +-
  Using search distance: 480
 > tumor_highcov <
  counts +/-:48510  -/+:1491   +/+:0      -/-:0      unpaired:0
  insert size mean: 303.36 std: 88.02
  valid orientations: +-
  Using search distance: 479
 Using align distance: 655
* Loading variants from input VCF file *
 Loaded 26 variants
* Running for variant 1/26 Deletion::1:9,417,727-9,437,123(19396) *
* Loading reads and finding mates *
 - normal_highcov
  To-match: 22902, min-mapq: 0
  0 22902 Finding mate pairs...
  LOTS OF READS IN MATE-PAIR REGION:2 33141308 33141309 169730
  LOTS OF READS IN MATE-PAIR REGION:6 160521754 160521755 109550
  LOTS OF READS IN MATE-PAIR REGION:11 51590451 51590452 224305
  LOTS OF READS IN MATE-PAIR REGION:2 33141547 33141548 376380
  1000 22902<PHONE_NUMBER>49
  2000 22902 1.9468729496
  3000 22902 2.2770819664
  LOTS OF READS IN MATE-PAIR REGION:2 33141619 33141620 354167
  4000 22902 40.9575459957
  5000 22902 5.28120398521
  LOTS OF READS IN MATE-PAIR REGION:2 33141319 33141320 398687
  6000 22902 46.2647850513
  LOTS OF READS IN MATE-PAIR REGION:2 33141420 33141421 170170
  LOTS OF READS IN MATE-PAIR REGION:12 66451372 66451373 528258
  LOTS OF READS IN MATE-PAIR REGION:15 77910867 77910868 157699
  7000 22902<PHONE_NUMBER>55
  8000 22902 4.08516192436
  9000 22902 17.4634859562
  10000 22902 4.25651812553
  LOTS OF READS IN MATE-PAIR REGION:2 33141466 33141467 393021
  11000 22902 40.2546839714
  12000 22902 1.68355584145
  13000 22902 1.4518020153
  14000 22902 2.08066916466
  15000 22902 3.05457997322
  LOTS OF READS IN MATE-PAIR REGION:2 33091951 33091952 252492
  16000 22902 34.2577848434
  17000 22902 1.06766104698
  18000 22902 2.656042099
  19000 22902 10.8296208382
  20000 22902 4.15118217468
  21000 22902 1.72145199776
  22000 22902 1.76672387123
  missing pairs: 23
  time to find reads and mates:481.862607956
  number of reads found: 23379
 - tumor_highcov
  To-match: 922, min-mapq: 0
  0 922 Finding mate pairs...
  LOTS OF READS IN MATE-PAIR REGION:2 33141422 33141423 181491
  missing pairs: 7
  time to find reads and mates:31.3594670296
  number of reads found: 1092
* Realigning reads *
  time for realigning:118.560303926
  time for realigning:4.96222901344
* Assigning reads to most probable alleles *
 Time for disambiguation: 4.17s
 Time for disambiguation: 0.99s
* Rendering tracks *
* Exporting views *

A few things to try, if you don't mind:
(1) I've created a branch on github that will print out a little more debugging info; I'm at a loss for what might be happening, as svviz does very little of interest after exporting views (really just records some summary statistics), but it's possible it's hanging there for some reason. To use this branch, do:
pip install -U git+git://github.com/svviz/svviz.git@debug16
Then run svviz as before, but with --verbose 9, and send me the output.
(2) Try running svviz without the --export, and instead with just the --no-web option (just in case rsvg-convert is doing something funky).
(3) Have you gotten this error to occur when running locally? If you can run svviz until it hits that infinite loop, you can hit ctrl-c from the terminal and look at the python stack trace which would be more useful than strace (?). Or if it's doesn't exit with a keyboard interrupt, we'd at least know it's because of some external code running.
(4) It would be helpful if you could see about getting me the input BAM, fasta and vcf. Send me an email if this might be possible (I'm guessing these are patient samples so may need to be treated a bit more carefully)

I just ran locally without --export, and it progressed past the first variant.  I ran again with --export to see if I could get a stack trace as you suggested, and I got the following error during Exporting Variants.  I guess this is just indicating that I don't have enough memory locally (8 Gb).  I haven't tried installing the debug branch yet, I will try that next.
* Exporting views *
Traceback (most recent call last):
  File "/gscmnt/gc8001/info/model_data/aregier/bin/svviz/venv/bin/svviz", line 9, in <module>
    load_entry_point('svviz==1.3.2', 'console_scripts', 'svviz')()
  File "/gscmnt/gc8001/info/model_data/aregier/bin/svviz/venv/lib/python2.7/site-packages/svviz/app.py", line 296, in main
    run(sys.argv)
  File "/gscmnt/gc8001/info/model_data/aregier/bin/svviz/venv/lib/python2.7/site-packages/svviz/app.py", line 278, in run
    runDirectExport(dataHub)
  File "/gscmnt/gc8001/info/model_data/aregier/bin/svviz/venv/lib/python2.7/site-packages/svviz/app.py", line 153, in runDirectExport
    exportData = export.convertSVG(exportData, exportFormat)
  File "/gscmnt/gc8001/info/model_data/aregier/bin/svviz/venv/lib/python2.7/site-packages/svviz/export.py", line 240, in convertSVG
    if not canConvertSVGToPDF():
  File "/gscmnt/gc8001/info/model_data/aregier/bin/svviz/venv/lib/python2.7/site-packages/svviz/export.py", line 229, in canConvertSVGToPDF
    subprocess.check_call("webkitToPDF", stderr=subprocess.PIPE, shell=True)
  File "/gscmnt/gc2607/mardiswilsonlab/aramu/lib/python2.7/subprocess.py", line 535, in check_call
    retcode = call(*popenargs, **kwargs)
  File "/gscmnt/gc2607/mardiswilsonlab/aramu/lib/python2.7/subprocess.py", line 522, in call
    return Popen(*popenargs, **kwargs).wait()
  File "/gscmnt/gc2607/mardiswilsonlab/aramu/lib/python2.7/subprocess.py", line 710, in __init__
    errread, errwrite)
  File "/gscmnt/gc2607/mardiswilsonlab/aramu/lib/python2.7/subprocess.py", line 1231, in _execute_child
    self.pid = os.fork()
OSError: [Errno 12] Cannot allocate memory

If you’re running out of memory locally, you might want to just start the jobs on the cluster in an interactive shell — that way you’ll know you’re using the exact same setup as you would be when running the batch jobs (it looks like your local computer is a mac and the batch jobs are being run on linux).
On Oct 8, 2015, at 2:25 PM, Allison Penner Regier <notifications<EMAIL_ADDRESS>wrote:
I just ran locally without --export, and it progressed past the first variant. I ran again with --export to see if I could get a stack trace as you suggested, and I got the following error during Exporting Variants. I guess this is just indicating that I don't have enough memory locally (8 Gb). I haven't tried installing the debug branch yet, I will try that next.

Exporting views *
Traceback (most recent call last):
File "/gscmnt/gc8001/info/model_data/aregier/bin/svviz/venv/bin/svviz", line 9, in
load_entry_point('svviz==1.3.2', 'console_scripts', 'svviz')()
File "/gscmnt/gc8001/info/model_data/aregier/bin/svviz/venv/lib/python2.7/site-packages/svviz/app.py", line 296, in main
run(sys.argv)
File "/gscmnt/gc8001/info/model_data/aregier/bin/svviz/venv/lib/python2.7/site-packages/svviz/app.py", line 278, in run
runDirectExport(dataHub)
File "/gscmnt/gc8001/info/model_data/aregier/bin/svviz/venv/lib/python2.7/site-packages/svviz/app.py", line 153, in runDirectExport
exportData = export.convertSVG(exportData, exportFormat)
File "/gscmnt/gc8001/info/model_data/aregier/bin/svviz/venv/lib/python2.7/site-packages/svviz/export.py", line 240, in convertSVG
if not canConvertSVGToPDF():
File "/gscmnt/gc8001/info/model_data/aregier/bin/svviz/venv/lib/python2.7/site-packages/svviz/export.py", line 229, in canConvertSVGToPDF
subprocess.check_call("webkitToPDF", stderr=subprocess.PIPE, shell=True)
File "/gscmnt/gc2607/mardiswilsonlab/aramu/lib/python2.7/subprocess.py", line 535, in check_call
retcode = call(*popenargs, **kwargs)
File "/gscmnt/gc2607/mardiswilsonlab/aramu/lib/python2.7/subprocess.py", line 522, in call
return Popen(*popenargs, **kwargs).wait()
File "/gscmnt/gc2607/mardiswilsonlab/aramu/lib/python2.7/subprocess.py", line 710, in init
errread, errwrite)
File "/gscmnt/gc2607/mardiswilsonlab/aramu/lib/python2.7/subprocess.py", line 1231, in _execute_child
self.pid = os.fork()
OSError: [Errno 12] Cannot allocate memory

—
Reply to this email directly or view it on GitHubhttps://github.com/svviz/svviz/issues/16#issuecomment-146690375.

Ok - it does not exit with a keyboard interrupt.

I did get a core dump, which is 4.5 Gb

Looking at the core dump with gdb:
Program terminated with signal 3, Quit.
#0  0x00002ad0ec03d9f6 in __libc_fork () at ../nptl/sysdeps/unix/sysv/linux/x86_64/../fork.c:130

I don't know if this is helpful or not.

Same on my end, the interactive job does not terminate with a Ctrl-C, I had to kill the process using top. There is just one running process when it hangs if that helps at all.
This is my site-packages folder if there's any outdated packages we should be looking into,
 svviz --version
svviz version 1.3.3dev

 /bin/ls
Flask-0.10.1.dist-info     flask                        markupsafe                    pyfaidx-0.4.2.dist-info    six-1.10.0.dist-info             wheel
Jinja2-2.8.dist-info       itsdangerous-0.24.dist-info  numpy                         pysam                      six.py                           wheel-0.24.0.dist-info
MarkupSafe-0.23.dist-info  itsdangerous.py              numpy-1.10.0.post2.dist-info  pysam-0.8.3.dist-info      six.pyc
Werkzeug-0.10.4.dist-info  itsdangerous.pyc             pip                           requests                   ssw
_markerlib                 jinja2                       pip-7.1.2.dist-info           requests-2.8.0.dist-info   svviz
easy_install.py            joblib                       pkg_resources                 setuptools                 svviz-1.3.3.dev0-py2.7.egg-info
easy_install.pyc           joblib-0.8.4.dist-info       pyfaidx                       setuptools-18.2.dist-info  werkzeug

Did you get the full batch job to run on the cluster without the export working? The extra logging info might be helpful, but I’m guessing there’s something wrong with rsvg-convert. If it runs fine sans conversion, I can try to add support for wkhtmltopdf instead of rsvg-convert.
On Oct 8, 2015, at 3:38 PM, Avinash Ramu <notifications<EMAIL_ADDRESS>wrote:
Same on my end, the interactive job does not terminate with a Ctrl-C, I had to kill the process using top. There is just one running process when it hangs if that helps at all.
This is my site-packages folder if there's any outdated packages we should be looking into,
svviz --version
svviz version 1.3.3dev
/bin/ls
Flask-0.10.1.dist-info     flask                        markupsafe                    pyfaidx-0.4.2.dist-info    six-1.10.0.dist-info             wheel
Jinja2-2.8.dist-info       itsdangerous-0.24.dist-info  numpy                         pysam                      six.py                           wheel-0.24.0.dist-info
MarkupSafe-0.23.dist-info  itsdangerous.py              numpy-1.10.0.post2.dist-info  pysam-0.8.3.dist-info      six.pyc
Werkzeug-0.10.4.dist-info  itsdangerous.pyc             pip                           requests                   ssw
_markerlib                 jinja2                       pip-7.1.2.dist-info           requests-2.8.0.dist-info   svviz
easy_install.py            joblib                       pkg_resources                 setuptools                 svviz-1.3.3.dev0-py2.7.egg-info
easy_install.pyc           joblib-0.8.4.dist-info       pyfaidx                       setuptools-18.2.dist-info  werkzeug
—
Reply to this email directly or view it on GitHubhttps://github.com/svviz/svviz/issues/16#issuecomment-146707460.

Nope, I haven't been able to get the full batch to work. Even without the --export it hangs.

I think I’ve come the end of ideas I have for remotely debugging this. If you decide it’s okay to send me one of the input BAMs that’s causing the problem, I’ll see if I can replicate the issue here.
On Oct 8, 2015, at 6:30 PM, Avinash Ramu <notifications<EMAIL_ADDRESS>wrote:
Nope, I haven't been able to get the full batch to work. Even without the --export it hangs.
—
Reply to this email directly or view it on GitHubhttps://github.com/svviz/svviz/issues/16#issuecomment-146732341.

I'll look into it - it is cell line data so we might be able to, but I need to check.  I am also trying to set up a vm with a newer OS to see if it replicates there, but it is taking a while to get it all set up.  One note as I was working on setting up the vm - it looks like there is a dependency on zlib1g-dev that isn't noted in the documentation.

I've finally gotten the vm going, and it looks promising, but I'm having to run without --export.  Even though I installed librsvg2-dev, it gave the error:
/bin/sh: 1: rsvg-convert: not found
Can't find rsvg-convert; make sure you have librsvg installed
Traceback (most recent call last):
  File "/usr/local/bin/svviz", line 9, in <module>
    load_entry_point('svviz==1.3.2', 'console_scripts', 'svviz')()
  File "/usr/local/lib/python2.7/dist-packages/svviz/app.py", line 296, in main
    run(sys.argv)
  File "/usr/local/lib/python2.7/dist-packages/svviz/app.py", line 278, in run
    runDirectExport(dataHub)
  File "/usr/local/lib/python2.7/dist-packages/svviz/app.py", line 155, in runDirectExport
    outf.write(exportData)
TypeError: expected a character buffer object

Any ideas?  The vm is on debian trusty.
Update: Damn, I just ran out of memory.  I was only able to get a 8Gb vm.

Sounds like I need to do some memory profiling -- I have lots of RAM on my various dev/test boxes, but svviz should fit in 8GB of RAM, ideally. Lots of things are getting fixed up, except not your original issue (yet!)


EndPointDispatcher LinkGeneration produces empty strings when a route cannot be found

See https://github.com/aspnet/Mvc/pull/8275/files#r210713067

Why is this "100%" intended? The 404s mean something while silently going back to the original URL is a major problem in many cases.

New routing is like attribute routing, which doesn't like to actions that don't exist.  We could do additional work to try and simulate what old routing does, and we're planning to do that based on user feedback.
Neither old nor new behavior does a good job alerting you that you have a problem, do you have suggestions about that?

do you have suggestions about that?

My suggestion is not to hide developer typos and the like in an apparently-successful round trip. The previous behaviour at least resulted in an obvious failure albeit only when the broken link was used.
Moving the failure earlier e.g. resulting in a useful error page would be great. Even throwing from the tag or HTML helpers may be fine now that the developer exception page displays the offending line in the .cshtml file. (Would be better if that part of the stack trace were open by default.)

Closing this bug per @rynowak's point. Let's ship as is and react to feedback later.


UDP traffic not accounted for

Using the 2019 Dec 23 nightly but UDP network traffic is still not accounted for. I know nothing about Windows programming but udp connections do have the ASSURED state. If this is not available then a user configurable timeout for assured would do, i'd set this for 180 seconds.
Please, it's pretty terrible to see only 5-10% of the traffic accounted for.
Otherwise the Network tab looks pretty good, countries stay sorted.
WHEN the Country tab is selected, it'd be pretty great to be able to Pin a certain country and have the country list be displayed with this country at the top. I don't mean resorting, just have the alphabetically sorted country list always keep the pinned country starting at top row, whichever direction the whole list is sorted with.

A bit early with my praise for the country list sorting, why is Spain sorted after China? It's MOSTLY alphabetical... :)

udp connections do have the ASSURED state.

The GetExtendedUdpTable API doesn't have this information.

terrible to see only 5-10% of the traffic accounted for

It's always accounted for the process on the statistics page but not always accounted for individual connections you see on the network tab because ETW doesn't always have the correct to/from address for UDP statistics but always has the correct PID.

Pin a certain country and have the country list be displayed with this country at the top

I have a patch for showing the estimated distance based on geoip. It would be more logical to sort via distance than by specific countries (especially to avoid the appearance of R and favoritism)?

Was thinking of NetworkTrafficView by Nirsoft but forgot it's using winpcap (or rather npcap today), maybe it makes a difference, it has udp conversations view since v2.25. Then again i wouldn't mind installing npcap to get this functionality to PH2.

There were some fixes for the UDP traffic counters in recent nightly builds but they might not include all traffic for that process but instead show as traffic for the System process.

Then again i wouldn't mind installing npcap to get this functionality to PH2.

npcap is outside the scope of the project because of its traffic capture/inspection.


Fixes GEODE-485.

Logging at debug level on a SocketException while closing the connection to avoid any suspect strings written to logs.

The changes in your last commit look good. But something is odd with this PR, you have some commits from develop that have been cherry picked onto your branch.

Thanks Dan. The branch is cleaned up reverting the cherry-picks.

Changed to info rather than debug.


The Blog tags is missing

Actual Behaviour

Visit https://apisix.apache.org/blog/

Click Tags -> practical case

Before clicking:

After clicking:

Expected Behaviour
It should not be hidden.

refer  https://github.com/apache/apisix-website/issues/554 for more details


Status Bar: Add git branch status

Splitting out from #201 - it'd be great to see the current git branch as an optional setting in the status bar. This is one item I miss with the new status bar from #201.

I've got some code for this, I made a component and everything, I'm just not sure where it should go. I added a method to the Git.ts that this needs to run, so it seems like oni-core-statusbar/index.js is not the right place. Any thoughts?

Awesome! That's really great. I've been missing have my git branch in the status bar, I'd be stoked to have this back.
Just to give you an idea of my long-term vision - I'd like to split up pieces of Oni into subcomponents (kind of like how Atom does it). For example, move oni-core-statusbar to an npm package, and same with other plugins. And move some existing functionality into plugins / packages (like quickopen / fuzzy finder).
For git integration in general, I was thinking of creating an oni-core-git plugin under vim/core. To start with, this would be focused mainly on the statusbar. But then later I was planning on extending it a bit, especially to bring in things like diffing and git blame.
So if you're up for that - adding a new plugin (which you can start by copying oni-core-statusbar to a new folder oni-core-git) - that would be awesome. Otherwise, I think oni-core-statusbar is reasonable, because we can always split that out later.
Thanks for looking at it, excited to check it out. Keep me posted if you need any help.

I meant more along the lines that I didn't know if I could put it in it's own file in there or not. I'm not sure about importing Git into index.js, doesn't seem very "decoupled" and also I don't know if javascript is just going to let me import a Typescript file...
Sorry these are just basic questions haha. I like code, not architecture

Sorry these are just basic questions haha. I like code, not architecture

Haha not at all, the module / import system is pretty confusing in JavaScript as it is. Combine that with different strategies we have in TypeScript+Webpack vs JavaScript, and it is certainly a recipe for confusion.
It sounds like you're adding the functionality in Git.ts and then using it in the statusbar. You're right, you can't import that, but we can give access to it in other ways. In that case, we might want to extend the Oni object we expose to plugins to have those methods available.
Having the API available through Oni.git:

Oni.git.isGitRepository(path)
Oni.git.getTrackedFiles()
Oni.git.getBranch()
Oni.git.onBranchChanged(callback)

would be pretty cool / useful. We could add it on the Oni object in browser\src\Plugins\Api\Oni.ts. Let me know if you want help there.

So I'm reading through API/Oni.ts and I  don't quite understand it >_<
Am I just supposed to have Git.ts Imported in Oni.ts? I see lots of notifications getting pushed through plugin channels but that's ti.

Am I just supposed to have Git.ts Imported in Oni.ts? I see lots of notifications getting pushed through plugin channels but that's it.

Ya, it used to be that the plugins ran in a separate process - and the plugin channels were an abstraction to communicate between the processes. There are pros and cons to each approach, but we moved to an in-process model. The plugin channel is still used, but you don't really need it. An example of a place where it isn't used is the configuration - so that might be a good model to follow.
I'd recommend doing the following, and using the Configuration piece of the API to build this out, because that's pretty similiar:

Define the interface in definitions\Oni.d.ts - you'd end up with something like:

export interface Git {
    getBranch(): Promise<string>
    // Define any other APIs you'd need to for your plugin here
}

Copy the browser\src\Plugins\Api\Configuration.ts -> browser\src\Plugins\Api\Git.ts
Import Git.ts instead of Config.ts, and export a class that implements the Git interface from Oni.d.ts
Add git to browser\src\Plugins\Api\Oni.ts. You'd need to create a new private variable (private _git: Oni.Git), import your Git API (import { Git } from "./Git"), and expose it from the Oni API - (public get git(): Oni.Git { return this._git }).

Hope that helps. It's really just using the Plugins\Api\Configuration.ts as a base, which is how the configuration API is defined for plugins. It's pretty similiar because that imports Config.ts (which is the core configuration logic) - we'd just be importing Git.ts.
Once these steps are complete, you should now have Oni.git available in the plugins to call.
Hope that helps, let me know if you want details on any of those steps. I also might be able to start some of this over the weekend.

I have the component made and showing, but I'm not exactly sure why it isn't working. It works if I put a default value in for the branch name, but the call to getBranch() is failing and blocking the Statusbar.
I'm going to submit a PR so you can see the code

Adding feedback here to for visibility: https://github.com/extr0py/oni/pull/540#issuecomment-315550296

@extr0py:

@bert88sta 's feedback regarding additional status info (ie, files modified/uncomitted/etc) . We might be able to get some of this info from the output of the git
Detecting when the branch has changed, since currently we only update on entering a buffer (for example, a user changed branch in the terminal). We could potentially add an event on the Git shared object like branch-changed that the plugin could subscribe to.
A configuration option to enable / disable the statusbar (ie, git.statusBar.enabled)

Regarding the aditional status. I think it is a good idea but I would make it optional with a config (I don't really need that information there and it would take space in the status bar) and/or maybe make it a hover popup thing on the status bar item.

Cheers, thanks for tracking it, @Galbar!

Regarding the aditional status. I think it is a good idea but I would make it optional with a config (I don't really need that information there and it would take space in the status bar) and/or maybe make it a hover popup thing on the status bar item.

Agree 100% - some users will prefer the simpler / less busy experience, so making the additional status optional would be ideal.

@bryphe One idea would be to split this into a Git plugin since there are many different VCSs to choose from. The Git plugin would be responsible to expose this configuration.

👍 , yes that's a great suggestion @badosu . It'd be helpful to generalize a 'version-control-system' interface / API, and then have the git integration be a plugin that implements that (as a proof-of-concept for other systems, like subversion, etc)

I think this is tracked by #1310 and #451, so closing this out to be tracked by those items.


Feature Request: Add Wekan to DockerBunker

Hi, I saw your comment at Hacker News. Can you add Wekan to DockerBunker? I added DockerBunker to Wekan Platforms, Backups and Docker links pages. Wekan website here.
BR,
xet7
Maintainer of Wekan

Sure, thanks!
i’ll add Wekan as soon as I have some spare time and will let you know here.

Hi @xet7, I have just added Wekan. Let me know if there is anything I can improve:-)


Restrict upper limit of TBB version due to ABI changes.

As title.
xref https://github.com/numba/numba/pull/6096

Buildfarm ID: numba_smoketest_cpu_65

This passed on the farm with the exception of aarch64 as the builder was having issues.


Support for Mixed Billing Plans (Recurring + Usage-Based)

Problem Statement
The Shopify API allows for a mixed billing plan that includes both recurring and usage-based charges (Shopify Billing API Documentation). However, the current NPM client (@shopify/shopify-api-js) does not expose an interface for this billing structure.
Current Behavior
Using the NPM client, it's possible to define either a recurring billing plan or a usage-based billing plan but not a combination of both. See here - the mutually exclusive BillingInterval: https://github.com/Shopify/shopify-api-js/blob/HEAD/docs/guides/billing.md
Desired Behavior
The client should support a mixed billing plan, similar to how the GraphQL API allows it, and the Shopify documentation describes here as a mechanism for app developers to earn revenue.
{
  "plan": {
    "appRecurringPricingDetails": { /* ... */ },
    "appUsagePricingDetails": { /* ... */ }
  }
}

Proposed Solution
Enhance the client API to accommodate both appRecurringPricingDetails and appUsagePricingDetails within the same billing plan.
const shopify = shopifyApi({
  billing: {
    'Mixed Billing Plan': {
      appRecurringPricingDetails: { /* ... */ },
      appUsagePricingDetails: { /* ... */ }
    }
  }
});

Steps to Reproduce

Install the latest version of the NPM package (@shopify/shopify-api).
Try to set up a mixed billing plan.

Additional Context
This feature will enable more flexible billing options for merchants, leading to potentially higher revenue and better user satisfaction.
For my service in particular, this is essential.
This issue is urgent due to the growing demand for more flexible billing plans from merchants.

Thank you for working on this!
We're using the new lineItemBilling configuration to enable mixed-type subscriptions (great!). I wanted to note, as part of this same feature, it's essential to also enable querying active subscriptions to retrieve the IDs of individual line items. This functionality is critical because we require the LineItemId of usage-based subscriptions to bill usage records to a shop, as outlined in the Shopify documentation.
Currently, the shopify.client.billing.subscriptions query only returns ActiveSubscriptions, which lacks this detailed information. It provides the ID of the overall subscription but not the IDs of the nested line items within it. The code snippet in question is:
    subscriptions: ({ session, }: import("./types").BillingSubscriptionParams) => Promise<import("./types").ActiveSubscriptions>;

export interface AppSubscription {
    id: string;
    name: string;
    test: boolean;
}
export interface ActiveSubscriptions {
    activeSubscriptions: AppSubscription[];

Hi team, is there any update on this? @lizkenyon


feat: add count to expectCall cheatcodes

Closes #4513

Motivation
Currently we can only assert that a call is made to a function using expectCall(), it would be nice to have another cheatcode to check the number of time a call was made, which can also be useful to assert if a call is not made.

Solution
Overriding the expectCall cheatcodes to also accept the number of times it is expected to be called and enforce the same.

Adding to cheatcodes VM.sol :

Yep in favor of this, per https://github.com/foundry-rs/foundry/issues/509#issuecomment-1488912530. We should also add a similar overload for expectEmit in a follow up PR.
Also @reubenr0d two questions:

Thanks for this + the forge-std PR! Can you also open a PR to the book repo for docs?
If want to expect no calls for a given target/selector (i.e. just the selector, and not caring about the rest of the calldata), can I just past 4 bytes to the cheat? I forget how it works exactly 😅

Can you also open a PR to the book repo for docs?

Sure, @mds1

can I just past 4 bytes to the cheat?

Yep, but as bytes not bytes4, so something like:
cheats.expectCall(address(target), abi.encodeWithSelector(target.add.selector), 0);

It looks like the regular expectCall methods without the new overload now fail if the call count is not 1, i.e. this was a breaking change because previously expectCall allowed any number of calls, but now it defaults to 1.
I'm not sure if this was intentional, but personally I'm ok with this change. Curious to hear your thoughts here @reubenr0d @mattsse. If we keep it, @reubenr0d do you mind getting another PR in to forge-std to update the code comments in Vm.sol to mention that the versions that don't take a count arg default to 1? (and mention this in the book PR too of course)

I'm not sure if this was intentional

Oh that's right! It was intentional, but it didn't strike me earlier, good catch.
Personally I'm okay with this as well, but I will let you'll (@mds1 and @mattsse) decide on how to proceed here.

Just to chime in: we were using expectCall to generically verify all functions from our ABI had been called in a test with code similar to:
    for (uint i = 0; i < selectors.length; i++) {
      vm.expectCall(address(foo), selectors[i]);
    }

With the new API we cannot do this entirely generically since some functions will be invoked multiple times.
I am OK with the change, just wanted to mention it :)

If I put 10 expectCalls, would it expect 10 calls? I.e. do they sum up if I add more expectCall lines? Cause that's what I was thinking how it works and had several expectCalls lines if I expected several (identical) calls.
But now it fails after I've upgraded. So should I just leave one expectCall put a number there now?

do they sum up if I add more expectCall lines?

Yes, that is in fact how it would work before this. And yes, if you do the same now it wouldn't work. Thanks @vicnaum for pointing that out. expectCall() with the same params should not be called multiple times within the same test. Wondering if we should handle the off-chance that someone does call it multiple times. wdyt @mattsse , @mds1 ?

So should I just leave one expectCall put a number there now?

Yes, that is how it is intended to be used.

If I put 10 expectCalls, would it expect 10 calls? I.e. do they sum up if I add more expectCall lines?

It should definitely work like this. See @reubenr0d's comment here:
https://github.com/foundry-rs/foundry/pull/4845#issuecomment-1528894093


Embedding in an Iframe is not possible

The standard dify-web docker container allows to embed the Chatbot in an Iframe on a website.
As I needed to customize the frontend, I followed the instructions and deployed the webapp-conversations frontend on vercel.
It runs perfectly when I open the Vercel URL directly. As soon as I embed it into an Iframe, I always get the error, that the chatbot is still responding, when I try to send a second message.

Already tested:

Using a Reverseproxy in front of Vercel
Using Browser Dev Tools to find possible CORS Errors ect.
Using other Browsers: Chrome, Safari -> Not working, Firefox-> Working

I was able to fix it on my own. The problem was: /app/compontents/index.tsx: The "oncompleted" function fails while fetching the conversations.id . Therefore the bot never reaches the state, where the "setResponsingFalse()" is set.
I rewrote the async onCompleted like this:
async onCompleted(hasError?: boolean) {
        // Immediately set the chatbot as not responding, regardless of potential errors in fetching conversations
        setResponsingFalse();

        if (hasError) {
          return; // Early return if there was an error in the chat message operation
        }

        try {
          // Attempt to fetch all conversations and generate a new name for the conversation
          const { data: allConversations }: any = await fetchConversations();
          if (allConversations && allConversations.length > 0) {
            const newItem: any = await generationConversationName(allConversations[0].id);

            // Proceed with setting new conversation information and resetting state as needed
            const newAllConversations = produce(allConversations, (draft: any) => {
              draft[0].name = newItem.name;
            });
            setConversationList(newAllConversations as any);

            // Additional logic to reset inputs and conversation IDs as needed
            if (getConversationIdChangeBecauseOfNew()) {
              setConversationIdChangeBecauseOfNew(false);
              resetNewConversationInputs();
              setChatNotStarted();
              setCurrConversationId(allConversations[0].id, APP_ID, true);
            }
          } else {
            // Handle the case where no conversations are returned
            console.error("No conversations were fetched.");
          }
        } catch (error) {
          console.error("An error occurred while fetching conversations or generating a new conversation name:", error);
          // Here, handle the error as needed, possibly setting additional error states or displaying a message to the user
        }
      },

After you embed the chatbot in another website, can other people still access your web app UI?

After you embed the chatbot in another website, can other people still access your web app UI?

Before I fixed it -> No
After my fix -> Yes
Please make sure to have SSL activated (For example by using a reverse Proxy), otherwise many brothers will block the iFrame

I found the root cause of this issue: Set-Cookie is  blocked by the browser

then conversations API always returns empty data without session_id cookie.
So,  we can add "SameSite=None; Secure" to the session_id cookie to fix this issue  (webapp-conversation\app\api\utils\common.ts)
export const setSession = (sessionId: string) => {   if (APP_INFO.disable_session_same_site)     return { 'Set-Cookie': session_id=${sessionId}; SameSite=None; Secure` }
return { 'Set-Cookie': session_id=${sessionId} }
}`