Need to define the symbol relationship(s) in mapping binding patterns

Consider the following:
type Person1 record {|
    string name;
    int mbp2;
    string...;
|};

function test1() {
    string mbp1;
    int mbp2;
    map<string> rbp3;
    {name: <1>mbp1, <2>mbp2, ...<3>rbp3} = <Person1>{name: "Jane Doe", mbp2: 10, "foo": "bar"}; // destructuring assignment stmt
}

A couple of points here:

According to the spec, the var names in binding patterns (e.g., locations <1>, <2>, <3>) are not var references. i.e., they're not expressions. But in the compiler we have modelled them as var refs. I suppose from a practical implementation POV, it makes sense, for providing features such as find refs, rename, goto def. But this also means use of typeOf() on these also works.
Currently, there's no relationship between name in the binding pattern and name in the mapping constructor. Need to take a closer look and decide on the behaviour for this. Does name in the binding pattern refer to the name field in the record type of the RHS expr?

The current impact of this is that plugin features such as find refs, rename, goto def etc. aren't working for the aforementioned cases.

Pointed allocated for the analysis and design.

In the typescript, when we have destructuring, they allow us to perform rename, goto-def and references actions.
interface TypeA {
    name: string;
    age: number;
}

function ert() {
    const { name: df, age} = { name: "dd", age: 23} as TypeA;
}

(TypeScript)
Below is the behaviour when we perform the Rename symbol action on the above source code
Scenario 1:

Scenario 2:

Had a chat with @mohanvive @nadeeshaan @pubudu91 and @sanjana on this. We decided to provide the Rename Symbol functionality for binding patterns defined with variable-name
i.e: mbp2 of the following code
{ name: mbp1, mbp2 } = <Person1>{name: "Jane Doe", mbp2: 10, "foo": "bar"};

Steps:

Created an issue to track the rest  of the development https://github.com/ballerina-platform/ballerina-lang/issues/35377

Had a further chat with @mohanvive @nadeeshaan and @dulajdilshan today regarding this. Specifically about whether or not to consider the field names in a binding pattern as references to field names of the RHS type. Consider the following example,
type Person record {|
    string name;
    int mbp2;
    string...;
|};

function test() {
    string mbp1;
    int mbp2;
    map<string> rbp3;

    {<1>name: mbp1, mbp2, ...rbp3} = <Person>{name: "Jane Doe", mbp2: 10, "foo": "bar"};
}

At first glance, in the above case it'd look like name at <1> is a reference to the name field in Person.
But consider the following case:
function test() {
    string mbp1;
    int mbp2;
    map<string> rbp3;

    record {|string name; int mbp2; string...;|} x = {name: "Jane Doe", mbp2: 10, "foo": "bar"};
    {<1>name: mbp1, mbp2, ...rbp3} = x;
}

In this particular case, do we still consider name at <1> as a reference to the field name of x's record type descriptor?
The conclusion was that we can't consider cases like the above one as referring the exact field. It's saying that it should have a field called name, but it's not referring to the field name in the type descriptor. Therefore, we won't be considering this as a reference of the field name, and consequently, won't be renamed either.


Common Date Transformers

First off thanks to the devs for creating such an awesome and useful library. Just a suggestion - it would be great to add a few date transformers to this library. For example pass on a list of data columns and for each column spit out separate columns year, month, weekday, hour etc. Here is a rudimentary date differ transformer I use often.
import pandas as pd
import numpy as np
import datetime as dt
from sklearn.base import TransformerMixin

class DateDiffer(TransformerMixin):
    '''
    # takes the difference between two dates and returns value in days
    # Please use DateFormatter() before using DateDiffer()

    How it works:
    If you specify 3 dates: [date1,date2,date3]
    Output will be 2 columns:
        date2-date1
        date3 - date2

    The transformer takes the following parameter 'units':
        Y:  year
        M:  month
        W:  week
        D:  day
        h:  hour
        m:  minute
        s:  second
        ms: millisecond
        us: microsecond
        ns: nanosecond
        ps: picosecond
        fs: femtosecond
        as: attosecond
    '''
    def __init__(self, unit='D'):
        self.unit = unit

    def fit(self, X, y=None):
        # stateless transformer
        return self

    def transform(self, X):
        # assumes X is a DataFrame
        beg_cols = X.columns[:-1]
        end_cols = X.columns[1:]
        Xbeg = X[beg_cols].as_matrix()
        Xend = X[end_cols].as_matrix()
        Xd = (Xend - Xbeg) / np.timedelta64(1, self.unit)
        diff_cols = ['->'.join(pair) for pair in zip(beg_cols, end_cols)]
        Xdiff = pd.DataFrame(Xd, index=X.index, columns=diff_cols)
        return Xdiff

My Python foo skills are limited - for example, I am unable to generalize the DateDiffer() transformer to an entire dataframe, or say, pass it a list of columns and do a fit_transform()
Finally, is there a way to pass two numeric columns to a transformer and obtain the column differences? I  know I can create interaction variables with the sklearn polynomial transformer but not df{'x1']+df['x2'] for instance.

I think this is a reasonable request, and certainly a common enough use case. @charlesdrotar let's spend some time discussing

Thanks guys - and I might add some of your classes are already solving some pain points alot of us have e..g: safelabelencoder encodes unseen values. I referenced your work in this stackoverflow thread


save to s3 and then rename

Pull Request
Description
Raise condition, when saving to s3, and downloading at the same time, it creates a problem

To solve this a bit, we
first upload to s3 and then rename

Fixes #
How Has This Been Tested?
Please describe the tests that you ran to verify your changes. Provide instructions so we can reproduce.
Please also list any relevant details for your test configuration

[ ] Yes

If your changes affect data processing, have you plotted any changes? i.e. have you done a quick sanity check?

[ ] Yes

Checklist:

[ ] My code follows OCF's coding style guidelines
[ ] I have performed a self-review of my own code
[ ] I have made corresponding changes to the documentation
[ ] I have added tests that prove my fix is effective or that my feature works
[ ] I have checked my code and corrected any misspellings

Codecov Report

Merging #42 (4106aa3) into main (2a65810) will increase coverage by 0.08%.
 Consider uploading reports for the commit a62dd9f to get more accurate results

@@            Coverage Diff             @@
##             main      #42      +/-   ##
==========================================
+ Coverage   93.31%   93.39%   +0.08%
==========================================
  Files           6        6
  Lines         329      333       +4
==========================================
+ Hits          307      311       +4
  Misses         22       22

Impacted Files
Coverage Δ

metofficedatahub/multiple_files.py
93.00% <100.00%> (+0.20%)
:arrow_up:

:mega: Codecov can now indicate which changes are the most critical in Pull Requests. Learn more

https://github.com/all-contributors please add @jacobbieker for review


Any suggestion to modify the arch based on the gan training result?

I'm training a photo swin_unet_2x model using gan. I use a cosine lr scheduler with init lr = 1e-5. After some tries I found that the discriminator loss fluctuated around 0.8 (the threshold for generator training to begin), so I increased discriminator lr to 5e-5. And this is the result.

After ~160 epochs the gen loss start to increase which trade off with the decrease of discr loss, which is not good. My guess is that maybe the gen model is undergoing some underfitting? So could you give me some suggestion to modify the arch to make the model more complex? Or should I try with a different arch?

I plan to try again in this field in the next month or so.
In my application, the generator (SR model) has VRAM usage and inference time limitations so the model cannot be made complex.
So, for my part, I think a smaller discrminator or some other technique will be necessary.
(For experiments there are larger models such as waifu2x.swin_unet_4xl, waifu2x.winc_unet_2xl,  waifu2x.winc_unet_4xl but need to do full scratch training.)
The other problem I see is that the disc_weight keeps decreasing, I plan to add an option to use a fixed weight instead of using adaptive weight.
Also, because of these problems, I have only run up to epoch=40-80(with --num-samples 25000) in my current release of the model.

I plan to try again in this field in the next month or so.
In my application, the generator (SR model) has VRAM usage and inference time limitations so the model cannot be made complex. So, for my part, I think a smaller discrminator or some other technique will be necessary. (For experiments there are larger models such as waifu2x.swin_unet_4xl, waifu2x.winc_unet_2xl, waifu2x.winc_unet_4xl but need to do full scratch training.)
The other problem I see is that the disc_weight keeps decreasing, I plan to add an option to use a fixed weight instead of using adaptive weight.
Also, because of these problems, I have only run up to epoch=40-80(with --num-samples 25000) in my current release of the model.

Could you briefly explain what l3v1 discriminator is?

It is defined in waifu2x/models/discriminator.py.
It is a PatchGAN type discriminator, with two branches: shallow(v1) and deep(l3).

I plan to try again in this field in the next month or so.
In my application, the generator (SR model) has VRAM usage and inference time limitations so the model cannot be made complex. So, for my part, I think a smaller discrminator or some other technique will be necessary. (For experiments there are larger models such as waifu2x.swin_unet_4xl, waifu2x.winc_unet_2xl, waifu2x.winc_unet_4xl but need to do full scratch training.)
The other problem I see is that the disc_weight keeps decreasing, I plan to add an option to use a fixed weight instead of using adaptive weight.
Also, because of these problems, I have only run up to epoch=40-80(with --num-samples 25000) in my current release of the model.

About the adaptive weight. When adaptive weight is small, does it mean that the gradient of the generator loss is much greater than the gradient of the reconstruction loss?

Ideally, yes.
weight = l2norm(last_layer_gradient(recon_loss)) / l2norm(last_layer_gradient(gen_loss))
loss = recon_loss / weight + gen_loss

However, in practice, when the discriminator gets stronger, weight decrease and psnr increases.
I think it means that 1/weight become too much larger than ideal.
I referenced taming-transformers for GAN loss (L1+LPIPS+GAN), so I adopted adaptive weight.

Ideally, yes.
weight = l2norm(last_layer_gradient(recon_loss)) / l2norm(last_layer_gradient(gen_loss))
loss = recon_loss / weight + gen_loss

However, in practice, when the discriminator gets stronger, weight decrease and psnr increases. I think it means that 1/weight become too much larger than ideal.
I referenced taming-transformers for GAN loss (L1+LPIPS+GAN), so I adopted adaptive weight.

I see you use Hinge loss for discriminator. Have you tried other loss like Wasserstein Loss?

No, I do not have much GAN experience.
My first try was this(DCGAN Binary Cross Entropy)
https://github.com/nagadomi/nunif/tree/master/playground/gan
and the next was waifu2x
(and for the most part, I intended to follow taming-transformers. I first checked it works with 4x SR task using CelebA dataset)

No, I do not have much GAN experience. My first try was this(DCGAN Binary Cross Entropy) https://github.com/nagadomi/nunif/tree/master/playground/gan and the next was waifu2x (and for the most part, I intended to follow taming-transformers. I first checked it works with 4x SR task using CelebA dataset)

Does waifu2x support self-supervised discriminator?

I have tried an autoencoder type self supervised discriminator(refer FastGAN) but I have not commit the model code.


Improve touch support:

Splitters/header controls should work.
Dragging tabs is possible, though it requires two touches.

Thank you for the PR

@ButchMonkey did you take a look at this? I've not had a chance, but if we can get this in and tested it'd be great to cut a new release with all the other fixes plus this.

Yeah, I did some testing and its almost there. The only thing we need to look at is the dragging and how it needs 2 touches. But its a major improvement from no touch support :)

Fantastic stuff; thanks!
On Wed, Mar 8, 2017 at 3:04 AM, ButchMonkey<EMAIL_ADDRESS>wrote:

Yeah, I did some testing and its almost there. The only thing we need to
look at is the dragging and how it needs 2 touches. But its a major
improvement from no touch support :)
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/deepstreamIO/golden-layout/pull/225#issuecomment-284985942,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAmsdR7QPt1aD6CyZH3rYXUiVPrgRXplks5rjm8KgaJpZM4MJB_l
.

The only thing we need to look at is the dragging and how it needs 2 touches.

It's the call to _updateTree() in DragProxy that by removing the DOM-element (and destroying the component and its DragListener too) breaks the chain of fired events and makes it require two touches.
Moving the call to _updateTree() into the _onDrop handler fixes the issue, but makes the source-component disappear only after the ghost/clone has been dropped, so it's not acceptable behavior.
Refs:
https://github.com/golden-layout/golden-layout/issues/425#issuecomment-382760334
https://github.com/golden-layout/golden-layout/issues/425#issuecomment-382845718
If anyone has a clever idea on how to fix it, please share :)
Thanks.


[BREAKING] Change path seed from 32 bytes to 64, update constant

Change share-able encrypted file path seed to 64 bytes.
Update exported ENCRYPTION_PATH_SEED_LENGTH constant to 64.

Note: We will have to update MySky before this takes effect.

Don't merge yet. The path seed will change from hex encoding to base64.

Updated the description and title. I've confirmed with the regression tests that only the directory path seed output has changed.


Add detection for the Coq language - fixes #116

Tests won't pass 'til pygments.rb gets updated.

+1 -- thanks for doing this :-)


nushell: 0.75.0 -> 0.76.0

Bumped version for nushell (release notes at https://www.nushell.sh/blog/2023-02-21-nushell_0_76.html) and minor fixups
Description of changes

changed the name of the settings such that it complies with the current Cargo.toml
made it possible to apply additional cargo features such as the dataframes feature
made it possible to skip checks to avoid building and running the tests for derivations that modify the cargo features

Things done

Built on platform(s)

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

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

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

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

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

[x] Fits CONTRIBUTING.md.

next update will be to 0.76.1 which will then support flake syntax :+1:

Result of nixpkgs-review pr 218030 run on aarch64-darwin 1

1 package built:

nushell


Fix location of CSS elements for default template

In the default template, the locations of CSS files are prefixed with a "/" This modifies the MetaLink file to remove this prefix

Hello! Thank you for this. However, I believe the leading slash is correct. Why would you want to remove it?

When I run a simple project with the default template, if you open the index.html file from the build folder, the browser can’t find the css files’ relative location (at least on my local machine), and I have to remove the leading slash. Maybe we change the build settings to make that leading slash toggle-able?

On Apr 2, 2024, at 12:30 PM, Paul Hudson @.***> wrote:
Hello! Thank you for this. However, I believe the leading slash is correct. Why would you want to remove it?
—
Reply to this email directly, view it on GitHub https://github.com/twostraws/Ignite/pull/21#issuecomment-2032522295, or unsubscribe https://github.com/notifications/unsubscribe-auth/AABDGITV3KJRQXNJXWEBXW3Y3LMK3AVCNFSM6AAAAABFTWZ7O2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAMZSGUZDEMRZGU.
You are receiving this because you authored the thread.

Broadly speaking, most sites aren't server up as local files, and are instead provided from web servers. If you want to run a local server for testing purposes, open your Terminal app then cd into the Build directory and run python3 -m http.server. We are currently trialing a command-line tool to make this a little easier (https://github.com/twostraws/Ignite/pull/17), but that's not fully delivered yet.

This repository now includes a CLI tool that makes it easier to run a local web server for testing, so I'm going to close this PR.


Task - TaxonName - OTU create

When I create a new taxon name and also want create an OTU, I can click on the OTU radial, and this will create OTU and also open an Radial selector for it, but if I just want to create an OTU, it is little bit annoying, that I have to close the radial selector after. Proposed behavior 2 options:
1: clicking on OTU radial, when OTU does not exist, just creates an OTU, the radial changes the color. Second click will pop up the selector.
2. Add project preferences to create OTU every time a new taxon name is created.

1 - is a matter of preference - I want this button in many places, so I don't think we'll change it.
2 - is already an issue added somewhere here I think
3 - user, not project preference to always create OTU
4 - a boolean/checkbox on the taxon name form that says "also create OTU'.
5 - a seperate icon/button that has create only functionality.
I suspect 4 is the most clear and transparent behaviour.


WSL 1.0.3 hangs forever

Version
Windows version: 10.0.22621.1265
WSL Version

[X] WSL 2
[ ] WSL 1

Kernel Version
<IP_ADDRESS>
Distro Version
Any
Other Software
Docker Desktop
Repro Steps
After installing wsl 1.0.3 cannot start it.  I can see that a new process called vmmemWSL is tarted with around 700mb memory and 0% CPU that lingers around.
Rolled back to wsl 1.0 works ok.
Expected Behavior
wsl to work
Actual Behavior
wsl hangs either on start or on installation with the vmmemWSL process being dropped after a long time (can be speedup by stopping the wslservice process)
Diagnostic Logs
No response

Tried the solution (well it was already there) with the CFG - not helped - the only thing that helped was to completely delete wsl and install the wsl <IP_ADDRESS> from the msixbundle

Without /logs we can't do much.

Without /logs we can't do much.

Will add some, at this moment cannot do that, as it is fixed, but will try during the weekend to update back to 1.0.3 and get the logs of what's going on.

I have the same issue. Here is the log:
WslLogs-2023-02-24_14-04-01.zip
I hope it's useful because wsl already hangs when the user session starts.

Unfortunately did not have time to "break it" to get the logs - have a deadline so need a working machine. Thank you @Gitii <3 hopefully it would be enough to diagnose. Do you have similar behavior where a vmmem process is started with ~700 MB and 0-0.5% CPU that take a very long time to die?

@gaelxcowi I've checked and it's ~830MB for me and 0-0.1% CPU. On my laptop, I noticed that after a clean start, everything is fine. But standby causes this behaviour. After realizing that, I have created a new log file with reproduction:
WslLogs-2023-02-27_11-22-21.zip
I've started logging, put system to sleep (power safe), waited until it's on standby, turned the system on again, waited a few minutes and then stopped logging.
It might be unrelated, but Microsoft Terminal is killed after standby&resume (it's no longer running after resume of the system) and docker desktop is super dead. It cannot start anymore but that's expected as it depends on the wsl2 vm to function.

After a few days of playing around, I can confirm that version 1.0 is working without issues for me (no freezes, no "slow" start). Just as expected. With version 1.0, Microsoft Terminal survives standby, too.

I also have what i think is the same issue. Running wsl --install gives me the following error
Error code: Wsl/Service/CreateInstance/MountVhd/ERROR_FILE_NOT_FOUND
From another issue i found the solution to remove, then tried again and this time it just sits on installing with processes consuming 0% cpu
Whats process for removing wsl completely and installing v1

I'm sorry, I've gotten routed elsewhere and won't be able to look into this for the time being.

@pmartincic No worries and thanks for the honest update! I really appreciate that!

@gaelxcowi I couldn't reproduce this issue with <IP_ADDRESS> and the latest windows update anymore.
So maybe it has been fixed?

@Gitii  sorry for late reply, got really slumped these days, but tried just now and not really, Initially I had this issue;
https://github.com/microsoft/WSL/issues/7850
But after trying the fix in there got back to the same issue, luckily this time didn't have to debug for an hours bur rather downgraded back to <IP_ADDRESS>

@gaelxcowi Did you mean to check the WSL2 checkbox? I only see you mentioning v1.

@DanKaplanSES not sure what you mean, yes I meant to check WSL 2 check box, as I was using WSL 2 version 1.0.3. A for exmple now I am running WLS 2 version <IP_ADDRESS> unless I am mistaking something :/

I'm happy to report that after updating to Windows 11 a few weeks ago, the issue has yet to occur since the update.
The following is the wsl --version output after the update.
WSL version: <IP_ADDRESS>
Kernel version: <IP_ADDRESS>-1
WSLg version: 1.0.59
MSRDC version: 1.2.4677
Direct3D version: 1.611.1-81528511
DXCore version: 10.0.25131.1002-220531-1700.rs-onecore-base2-hyp
Windows version: 10.0.22631.3155

Had quite the same issue, whenever I was starting wsl, it's just stuck forever. No error msg, no CPU usage - only 115mb of RAM was in use.
For some reason, manually enabling of "Host address loopback" in WSL settings app resolved the issue.
@xz-viewray try this one, maybe you face the same issue.
WSL version: <IP_ADDRESS>
Kernel version: <IP_ADDRESS>-2
WSLg version: 1.0.65
MSRDC version: 1.2.5620
Direct3D version: 1.611.1-81528511
DXCore version: 10.0.26100.1-240331-1435.ge-release
Windows version: 10.0.19045.5011


Add Decontamination Script

We should have a way to check our data for both exact string and near-paraphrase decontamination for future data mixes. I think this is fairly important if we want to gather larger and larger datasets.
Looking at LMSYS' LLM decontaminator may be a good start: https://github.com/lm-sys/llm-decontaminator.
I'm not sure where the decontamination tools for olmo are, but using those may also be useful.

Closed by #392


Move Microsoft.Extensions.CommandLineUtils into NuGet repository

This idea came up in https://github.com/aspnet/Extensions/pull/445 (common submodule):
We only use the common project to source-build Microsoft.Extensions.CommandLineUtils 1.0.1, which is only used by nuget-client. We use the servicing/1.0.x branch of common:

[@natemcmaster] The servicing branch is dead from a functional perspective. It only exists to support source-build and the NuGet client's dependency on Microsoft.Extensions.CommandLineUtils 1.x. We don't plan to ship updates to Microsoft.Extensions.CommandLineUtils.
An alternative solution, which I highly recommend, is to copy the sources of Microsoft.Extensions.CommandLineUtils into NuGet.

If the package's sources are moved to nuget-client, we could remove common from source-build. That means the NuGet team can do whatever maintenance they need, and since we regularly upgrade the nuget-client submodule, we would get fixes without extra effort.
@rrelyea, does this suggestion sound reasonable?
/cc @dseefeld @dleeapho

This is being handled by ASP.NET.


useAwaited returns undefined when using defer for queryClient.fetchQuery

Which project does this relate to?
Router
Describe the bug
I tried to use the defer function with queryClient.fetchQuery. But the <Await> component returned undefined for the resolved data. I have looked at the code of the defer and noticed that when I used the defer function in loader, property status was already added to the promise. Then, the defer function was continuing to be used in the useAwaited hook. This time, the defer function inside the useAwaited hook could not assign property data to the promise because the condition was not met. So the resolved data is undefined. I tried to fix the issue by moving the logic for promise.then out of the condition if (!(promise as any).status). The issue was resolved but I am not sure if it is a legit solution. So, I wrote a customDefer function. It can be found at /utils/customDefer.ts in the codesandbox

Your Example Website or App
https://codesandbox.io/p/devbox/n2jq68
Steps to Reproduce the Bug or Issue

Go to https://codesandbox.io/p/devbox/n2jq68
Notices the right section has the "Loading todos..." text. After 3-4 seconds, the text shows "resolvedTodos is undefined"
The logic for the loader function can be found at /routes/index.tsx

Expected behavior
I expected the useAwaited hook can return the resolved data properly when passing a deferred promise fetched by queryClient
Screenshots or Videos
No response
Platform

Browser: Chrome, Microsoft Edge
Version:  131.0

Additional context
No response

This is a mistake in the usage.
The usage of defer here doesn't make sense, since Query is already an asynchronous state management library and therefore mixing it with this primitive is bound to result in an error. When using Query (or a similar library), you want to use its own access patterns for retrieving the fetched data.
So, in the loader you'll just be kicking off the query and awaiting the getPostsQueryOptions().
import { createFileRoute } from '@tanstack/router'

export const Route = createFileRoute('/_management/users')({
  loader: async ({ context: { queryClient } }) => {
    queryClient.prefetchQuery(getTodosQueryOptions())
    await queryClient.ensureQueryData(getPostsQueryOptions())

   // you don't actually return anything
  },
  component: RouteComponent
})

Then in the Route component, you'd be accessing the data using the correct hooks from your async state library of choice. You won't be using Route.useLoaderData().
import { useSuspenseQuery, useQuery } from '@tanstack/react-query'

function RouteComponent() {
  const posts = useSuspenseQuery(getPostsQueryOptions());
  const todos = useQuery(getTodosQueryOptions());

  // ...
}

I'll be sure to add a note in the deferred data loading guide, so callout the fact that when you are using an external library for this kind of caching, you'll only be using the loader to kick-off the fetch.


[RESOLVED] High ICMP ping loss

Problem started at 10:54:14 on 2023.08.01
Problem name: High ICMP ping loss
Host: MF-FG
Severity: Warning
Operational data: Loss: 33.33 %
Original problem ID: 34505
Event details in Zabbix: http://<IP_ADDRESS>/tr_events.php?triggerid=23131&eventid=34505

Problem has been resolved in 1m 0s at 10:55:14 on 2023.08.01
Problem name: High ICMP ping loss
Host: MF-FG
Severity: Warning
Original problem ID: 34505


Use tracy-client directly

As mentioned in the readme there is overhead with going through tracing. Iirc when I measured it, it was on the order of hundreds of ns.
Of course, I think it would make sense to keep the tracing backend since that allows the instrumentation to be used for other things using tracing.

I think that would be a good change too! I think the main reason I didn't do it that way was because all the examples I saw from the crate went through tracing. Would be happy to accept a PR for this, or might get around to doing it myself at some point.

I'll leave this open until 0.1.6 is published

This is published now in 0.1.6 though I re-published as 0.1.7 because I forgot to bump the procmacro crate version


Migration engine incorrectly makes a field non-nullable

When the migration engine is run over the logging package, it "incorrectly" makes the field parent non-nullable. (I put "incorrectly" in quotes because it might be that it's working as intended, but just not matching my expectations.)
The field is initialized by a field formal parameter in the following constructor:
Logger._internal(this.name, this.parent, Map<String, Logger> children)
    : this._children = children,
      this.children = new UnmodifiableMapView(children) {
  /* if (parent != null) */ parent._children[name] = this;
}

Note that the field is explicitly compared to null in this constructor. It's also explicitly compared in a number of other places.
The null is passed in from a factory, and the fact that the field is assumed to be non-nullable is causing the migration engine to add a null check on null:
factory Logger.detached(String name) {
  return new Logger._internal(name, null!, new Map<String, Logger>());
}

The migration results would be closer to what I believe the authors intended if the field were marked as nullable.

I believe this is happening due to #38341.  In short, there is a local variable in a test with an inferred type, and that type is inferred to be the same as the type of parent.  The test expects its local variable to be non-nullable, and becuase that type is inferred from the type of parent, the migration engine is propagating that expectation back to parent itself, rather than inserting a null-check in the test, as it should.  See https://github.com/dart-lang/logging/pull/66/files#r323495145 for details.
Once that bug is fixed we can revisit this one and check whether it still occurs.

The dependency is fixed, and the migrator now correctly marks parent as nullable.


Improving sentence

closes https://github.com/MicrosoftDocs/OfficeDocs-SkypeForBusiness/issues/7022
As instructed by @HowlinWolf-92, thanks!

@JohanFreelancer9 Copy editing is needed for this PR. Thanks.

@HowlinWolf-92 PR has been copyedited and is ready for final review, could you please check and merge? Thanks!


Need loan collateral vault to validate debt ID upon collateral transfer

Currently, the LoanCollateralVault checks that the _operator is the LoanContract's address. This is not a reliable verification since a malicious actor could create their own ERC721 token that hard codes the _operator to the LoanContract's address. The attack ERC721 contract could then be used to deposit it's tokens while acting like the _operator is the LoanContract.
The proposed resolution is to send a validation transaction to the LoanContract.

An initial attempted resolution of "1. Use the _data input parameter as a signed proof that the deposit originated from the LoanContract." has been removed from consideration since I don't believe it is possible to officially "sign" a message by a smart contract.

Resolved with _checkDebtId function within LoanCollateralVault.

Added __loanContract state variable into LoanCollateralVault so that it can be used in the verification function _checkDebtId. Need to add address(loanContract into tests where LoanCollateralVault is initialized.

The LoanCollateralVault, ILoanCollateraVault, LoanContract, and Setup.t.sol contracts been updated. This should be resolved.

In LoanCollateralVault added bool vault; field in Collateral struct to allow storage of additional loans.


Make docker builds able to COPY custom files in

I've been monkey patching this for awhile in an internal plugin to be able to COPY custom files in the Dockerfile since we have final def build.
And I think today I found a potential permanent solution to this.
The fact that docker build does not allow absolute paths outside of the "context" is annoying since Mill is all about absolute path with T.dest. The compromise here is that the user can put any absolute path in the dockerfile but mill-docker will perform a replace(os.pwd.toString, "") and we'll execute the "context" in os.pwd which refers to the root of the project.
If you have a better idea without too much user confusion, let me know.
Thanks

If you have a better idea without too much user confusion, let me know.

I can't tell whether this idea is better, but we could also introduce a dockerResources target or dockerContext  which could provide additional resources. This would result in extra copying operations, but OTOH, we had a more local and controlled context.

Not sure either because you have to make the COPYs relative to that dockerResources. The SBT Native Packager's docker plugin uses this mappings Map which is similar to this idea but gives also control on the path where to put those files.

Given, that you could implement a dockerResources target however you want (just return a dir or  compute, copy or download various files and return those), this is probably much in the spirit of mapping, but a bit more flexible.
I was assuming, that we need to merge multiple resource dirs before we run docker build on it, that's why I said "extra copying".

Are the tests actually failed? Do I need to rerun something?

Yes. Multiple docker tests failed.
contrib.docker.test.test 5 tests failed:
  mill.contrib.docker.DockerModuleTest mill.contrib.docker.DockerModuleTest.docker build.default options
  mill.contrib.docker.DockerModuleTest mill.contrib.docker.DockerModuleTest.docker build.all options
  mill.contrib.docker.DockerModuleTest mill.contrib.docker.DockerModuleTest.dockerfile contents.default options
  mill.contrib.docker.DockerModuleTest mill.contrib.docker.DockerModuleTest.dockerfile contents.all options
  mill.contrib.docker.DockerModuleTest mill.contrib.docker.DockerModuleTest.#utestAfterAll

For example:
STEP 10/12: USER user1
--> d7170a4c97b
STEP 11/12: COPY /home/runner/work/mill/mill/target/workspace/mill/contrib/docker/DockerModuleTest/eval/docker build/all options/assembly.dest/out.jar /out.jar
Error: error building at STEP "COPY /home/runner/work/mill/mill/target/workspace/mill/contrib/docker/DockerModuleTest/eval/docker build/all options/assembly.dest/out.jar /out.jar": checking on sources under "/home/runner/work/mill/mill/target/worksources/mill/contrib/docker/DockerModuleTest/Docker/millSourcePath": copier: stat: "/home/runner/work/mill/mill/target/workspace/mill/contrib/docker/DockerModuleTest/eval/docker": no such file or directory

See https://github.com/com-lihaoyi/mill/runs/7248330085?check_suite_focus=true

I solved the issue with tests.
@lefou can you have a last look?

I solved the issue with tests. @lefou can you have a last look?

Sure, will probably take some time though. Also, your constant rebasing makes tracking of changes (and remembering where I left the review) really hard and frustrating.

Should be good now.


Improve German translations

Some improvements to the heavy work done by @fxedel and @kripton.

Wow, lot of stuff !
@fxedel , @kripton please ACK/NACK cause I can't


Javascript breaks when HTML minify is enabled.

In vendor/shellpea/magento-advanced-elasticsuite-catalog/view/frontend/templates/configuration.phtml Line 17 there is a return statement that uses JS template literals:
get clearUrl() {
    const { protocol, host, pathname, searchParams } = new URL(window.location)

    return `${protocol}//${host}${pathname}${searchParams.has('q') ? '?q=' + searchParams.get('q').toString() : ''}`;
},

The problem is that there is a double back-slash string inside that template literal and the HTML minifier cannot interpret that properly in .phtml files in this context. My guess is that it turns everything after "//" into a comment.
I suggest replacing the clearUrl() method with something like:
get clearUrl() {
    const { protocol, host, pathname, searchParams } = new URL(window.location),
    qParam = searchParams.has('q') ? '?q=' + searchParams.get('q').toString() : '',
    endParam = protocol + '//' + host + pathname + qParam;

    return endParam;
},

I have added changes to fix this issue 🙂
get clearUrl() {
    const { protocol, host, pathname, searchParams } = new URL(window.location.href);
    const queryParam = searchParams.has('q') ? '?q=' + searchParams.get('q').toString() : '';
    return protocol + '//' + host + pathname + queryParam;
},


Contradictory information

At the following sub-title : "Built-in policy initiatives" when describing the 'Bring Your Own User-Assigned Identity' parameter. The section describes that when this parameter is set to true the policy will create a built-in managed identity and assign it and if set to false than it would do nothing.
The bullet point section bellow and the name of this parameter itself imply that if this boolean parameter if set to true than you would ,as the name suggests need to bring your own managed identity and assign it yourself contradicting the first definition.

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

ID: 8201f331-0fa7-a801-9f4d-75d65cd77625
Version Independent ID: 86a66791-11bb-4f20-f77d-42fe58f5dcf4
Content: Manage Azure Monitor Agent - Azure Monitor
Content Source: articles/azure-monitor/agents/azure-monitor-agent-manage.md
Service: azure-monitor
Sub-service: agents
GitHub Login: @guywi-ms
Microsoft Alias: guywild

@blockthrower
Thanks for your feedback! We will investigate and update as appropriate.

Hi @blockthrower I don't believe the doc is contradictory. Bring Your Own User-Assigned Identity set to true creates a custom user identity for you that was predefined. In the next section, it's important to note Managed in Bring Your Own User-Assigned Managed Identity. A different way to interpret would be when set to true, you're basically saying I don't want to use the user the Azure Policy created for me, instead I'll pick one.
Hope that helps. If not, please feel free to comment down below. I'll also raise awareness to content author to have a look. Perhaps rewording this section can alleviate any confusion.


[WIP] Initial Pipeline Viz React Component

Initial Pipeline Viz React Component
Initial component for pipeline visualization
Notes
Functionality/features very likely to change once final designs are in
Tests
Go to samples/[sample id]/stage_results

Looks great. A lot of work here... I think we can make an effort to make it a bit more modular. We can discuss that offline.

This is not a blocker but for the future I would lean towards more popular libraries if possible (re: ajainarayanan/react-pan-zoom). Package hijacking is always possible https://blog.npmjs.org/post/180565383195/details-about-the-event-stream-incident

also there was an end-of-life notice for the (old?) visjs repo https://github.com/almende/vis/issues/4259

also there was an end-of-life notice for the (old?) visjs repo almende/vis#4259

I'll switch to visjs-network, which seems to be the current version (?) (https://github.com/almende/vis/issues/4259#issuecomment-469318846)

looks pretty good 👍 see last comments

ok and see Travis for an out of memory error T_T


[Feature] Viewport Control

Would be awesome if MGUI supported smt like a viewport where people can render their own 2D/3D content inside of.

For simple graphics, you can use a simple element such as an MGBorder, MGSpacer, or MGRectangle as a placeholder on the UI, then subscribe to MGElement.OnEndingDraw.
MGBorder Placeholder = Window.GetElementByName<MGBorder>("CustomContentPlaceholder");
Placeholder.OnEndingDraw += (sender, e) =>
{
    Rectangle BorderBounds = MGUI.Shared.Helpers.RectangleUtils.GetTranslated(Placeholder.LayoutBounds, e.DA.Offset);

    //TODO
    //draw custom content to the placeholder element's bounds

    //Option1: Draw the content using the helper functions in DrawTransaction
    //e.DA.DT.DrawTextureTo(tex, sourceRect, destinationRect);
    //e.DA.DT.DrawTextureAt(tex, sourceRect, destinationPoint);
    //e.DA.DT.DrawText("Arial", text, destination, Color.Black, 12);
    //e.DA.DT.FillRectangle(Vector2.Zero, destination, Color.Red);

    //Option2: Get the `SpriteBatch` from `DrawTransaction` and do whatever you want with it
    SpriteBatch SB = e.DA.DT.SB;

    //  If you need to change the draw settings such as the SamplerType, use DrawTransaction.SetDrawSettingsTemporary(...)
    //  The draw settings will be reverted when the using statement is disposed, so that the rendering of other UI elements won't be affected
    DrawSettings TempSettings = e.DA.DT.CurrentSettings with { SamplerType = SamplerType.LinearClamp };
    using (e.DA.DT.SetDrawSettingsTemporary(TempSettings))
    {
        //TODO draw something with LinearClamp
    }
};

Basically, I want a simple 3D model that keeps rotating, I guess option number 2 would work in that scenario.


Runtime Error: parsing

Hi,
I asked this question on the Greyhack discord, but it got deleted for some reason. I get this message whenever I use MTX in the Steam stable release
`mtx > scan <IP_ADDRESS> 80
[+] <IP_ADDRESS>:80 - Successfully connected!
[] <IP_ADDRESS>:80 - Dump MetaLib from the targeted service...
[+] <IP_ADDRESS>:80 - Current MetaLib loaded: libhttp.so => 1.0.0
[] <IP_ADDRESS>:80 - Perform a scan on libhttp.so...
[###################################]==[ 100% ]
[+] <IP_ADDRESS>:80 - Library scan completed successfully!
[+] <IP_ADDRESS>:80 - Vulnerables addresses founds: 4
Runtime Error: parsing "* " - Quantifier {x,y} following nothing. [line 1190]`
I copied the script several times now, but it still gives me this message. Also when using discover command.
Do I need to download exploits somewhere else, or does this framework do this on its own? (Sorry, still learning)

Nightly seems to work fine one the now stable release. Just FYI. Thanks for this repo! I play single player and none of the popular multi-tools seems to be available for players like me, so this is really helpful :)


Use of possible unsound auto trait impl in the index_vec.

This needs to be addressed in the future since Rust is breaking the compatibility for this one.
https://github.com/oxc-project/oxc/pull/3092#discussion_r1578813018

The clippy warning suspicious_auto_trait_impls  is removed after the 1.78.0 upgrade. I'm not sure if there are more actionable items to this issue.

The clippy warning suspicious_auto_trait_impls is removed after the 1.78.0 upgrade. I'm not sure if there are more actionable items to this issue.

To be honest I'm not sure ATM, The issue is that auto trait impls for Adt<Any> are going to be ignored.
The goal for this auto impl in the indexed_vec is to have the same Send/Sync as the inner T within a wrapped generic slice.
There might be other ways to approach it or we might not even need it since we are not advertising oxc_index as a general-purpose crate.
I've mostly created this issue so we can keep track of it, I didn't put that much thought into fixing it since we wanted to have a clean fork before doing any changes to it.
https://github.com/rust-lang/rust/pull/113312
https://github.com/rust-lang/rust/issues/93367#issuecomment-1954585068


Drop Python 3.6

Closes #525.
Any suggestions to remove 3.6-only code?

I'd rather hope my recent changes going in (like the nox file listing) would happen before nox drops 3.6. GHA/Azure's ubuntu-18.04 still runs Python 3.6 if you use pipx, CentOS 7 & 8 both have python3 -> 3.6, etc. So don't see a huge need to push this out immediately.
I'd use pyupgrade to remove 3.6 code, see https://scikit-hep.org/developer/style. I'd also inject from __future__ import annotations using isort then run it, which will clean up annotations.

I'd rather hope my recent changes going in (like the nox file listing) would happen before nox drops 3.6. GHA/Azure's ubuntu-18.04 still runs Python 3.6 if you use pipx, CentOS 7 & 8 both have python3 -> 3.6, etc. So don't see a huge need to push this out immediately.
I'd use pyupgrade to remove 3.6 code, see https://scikit-hep.org/developer/style. I'd also inject from __future__ import annotations using isort then run it, which will clean up annotations.

Since this seems to be covered by #530, I'll wait for that PR befoe merging this.

Ah, another weird CI failure.

I think our current pre-commit stuff has cleaned the code for dropping Python 3.6, right?

I think our current pre-commit stuff has cleaned the code for dropping Python 3.6, right?

I think the arg to pyupgrade should be bumped here: https://github.com/theacodes/nox/blob/main/.pre-commit-config.yaml#L29

As per https://github.com/theacodes/nox/pull/526#issuecomment-1000435908, a good way to upgrade the source code to use Python 3.7 features is to add the __future__ annotations import using isort, and to replace --py36-plus with --py37-plus in the pyupgrade hook configuration. Could also happen in a follow-up PR to this one.
As per that same comment, we should wait a little before dropping Python 3.6, because it will break people using pipx run nox on Ubuntu 18.04 runners, as well as people installing Nox with the system Python on the current CentOS release. I understand that comment as requesting to cut a Nox release with recently added features before we drop Python 3.6.

If you add me to your fork, I'm happy to help. You can use the following to inject the import:
git ls-files '*.py' | xargs pipx run isort -a "from __future__ import annotations"

I also always git grep for "version_info", "Python 3", and a few others things. I've most recently done this with https://github.com/tomerfiliba/plumbum/pull/573.
Dropping 2.7 & 3.5 is huge and really helps with maintenance. I don't think dropping 3.6 will be nearly as impactful, though the annotations are nice.
PS: it will not "break" people using pipx run nox on Ubuntu 18.04, it just will mean they don't get the new features we have been adding, as they will no longer get any nox upgrades once the drop happens. That's why it's nice to make sure there's an up-to-date release.

Is there any compelling reason to drop 3.6 right now? Are there any specific things in 3.6 that are holding us back?

I don't know about strong reasons to do this.

There were lots of benefits to going 3.6+, but there's really not as much going to 3.7+ beyond from __future__ import annotations (which is really nice, but if you've already written Python 3.6 annotations, it's not exactly pressing). Usually core libraries start dropping support ~6 months after EOL (if I remember correctly). Given Requires-Python, this likely won't cause a problem for a while longer, as well - since old versions keep working, so it's only when you want to start requiring new versions of 3.7+ only libraries that you'll likely hit a problem.
3.8 was a bit bigger from an API standpoint, as it lets you write positional only arguments, so designing a new API (like NumPy's new API) benefits from 3.8+. But as far as maintaining an existing library, I don't think there's much of an issue with 3.6+ for a while.
I can help update the PR then you can see if you think it's worth dropping 3.6. :)

Hi @henryiii, sorry for being offline all this time (I was busy with offline responsibilities). I will try to do it by myself, but if I need help, I will add you to my fork ;)

Ok... I tried what suggested in https://github.com/theacodes/nox/pull/526#issuecomment-1010418212. Any comments about the changes?

Why did CHANGELOG.md and CONTRIBUTING.md change? Is there an issue with endlines or something on your git setup? That's odd.

Hmm... I surely made something wrong :confused:.
@henryiii, I added you to DiddiLeija/nox.

Ahh, those are (now broken) symlinks. Are you on Windows?

Yup :confused:.

git checkout main -- docs/CHANGELOG.md
git checkout main -- docs/CONTRIBUTING.md

fixes it, no worries. There's some git setting somewhere that makes collaborative symlinks a bit less painful on Windows, I think. Okay with me force pushing away history, or would you prefer just additive comments? I see a merge, so I'm guessing the later?

Thanks a lot @henryiii! Well, I suppose this is now ready to merge.

I think the point was to compare and see if it's worth dropping now, or waiting a bit. This was you can see the trade offs. A few small workarounds removed, and a little bit nicer syntax, but nothing too major (not like going 3.6+). It's up to the maintainers.

(I can rebase this and squash a bit so the automated stuff is operate from the few hand changes if it needs to be kept around for a while)

(I can rebase this and squash a bit so the automated stuff is operate from the few hand changes if it needs to be kept around for a while)

You can do it if you want, but as far as I know, I will have to squash the commits for the merge ("merge commits" are not allowed here).

The idea would be to make it easy to apply in the future if it's not something you want to do right now. By separating the automated parts, you can rerun the automated parts - there weren't a huge number of hand written changes.
(So I'd only do it if you want to wait)

I get it. From my side, we can merge at any time, but I also would like to hear other maintainers. BTW, a new Nox release is in the air: https://github.com/theacodes/nox/releases/tag/2022.1.7. I don't know where, but we said that we could drop Python 3.6 after that release?

From my side I think it's okay to drop 3.6 in the next release. As @henryiii said it's not as big a win as 3.5 -> 3.6 but as 3.6 is now EOL I think it's fair game for us to drop, we've already cut a release with all the new recent additions (2022.1.7) so 3.6 users won't be missing out on that (which was a good point for not dropping it until after that release)

Yeah, it's fair (and safe) to merge this now, unless we want to do https://github.com/theacodes/nox/pull/561#issuecomment-1011245649 first.

If nobody says "Stop! Don't do this!" before next week, I'll just go ahead and merge this, since seems like we now want to do this.

A few more bits of information:
Python stats from https://mayeut.github.io/manylinux-timeline/ Jan 10 (would be better averaged, but still interesting):
| Version | Usage |
|=========|=======|
| 2.7 | 5.8% |
| 3.5 | 1.5% |
| 3.6 | 15.1% |
| 3.7 | 54.7% |
| 3.8 | 17.9% |
| 3.9 | 5.3% |
| 3.10| 0.2% |
This is based on downloads for 3,564 packages providing manylinux wheels. The full graph is interesting too.
The most interesting thing to me is how wildly popular 3.7 is. I read that 1.8, 2.7, and 3.6 were especially special/popular releases, but I don't know what's up with 3.7. I can think of some major OS's with 3.6, but 3.7 seems well out of proportion; it took the most popular python (from a 2.7/3.6 tie) in middle 2020 and it's still gaining in popularity (from 2.7-3.6 users, I hope!)
I personally don't have a strong opinion either way for a tool like Nox. I'll likely start moving min versions on core stuff around the time Ubuntu 22.04 comes out and is available as a GHA runner, or around the time manylinux drops 3.6. It may depend quite a bit on development - it's easier to develop with a higher min requirement. Less-core stuff will depend on if I'm actively developing it or not - I like to get a benefit from a Python drop if possible. Numerical stuff is supposed to be 3.8+ now, according to NEP 29, so might be doing that too.

@henryiii that data is actually super interesting! Weird how 3.7 is the majority!

Yeah, why is 3.7 so popular? That's pretty weird for me :thinking:

around the time manylinux drops 3.6

Actually, I already decided to ask at pypa/manylinux#1260, maybe that reminder could be helpful.

I like to get a benefit from a Python drop if possible.

Me either. We didn't win a lot with dropping Python 3.6 like dropping 3.5 or 2, I suppose. However, I think it's important to do it. But in the other hand, I'm starting to get concerned by the Ubuntu thing that @henryiii pointed out.

Ok. Probably, manylinux won't drop 3.6 until 2029. So, I want to know if somebody disagrees with pushing this. If somebody does, I will just close this PR, and recreate it when needed.
cc @theacodes @FollowTheProcess @cjolowicz @dhermes @henryiii

manylinux won't drop 3.6 until 2029

? Pretty sure manylinux will drop 3.6 midway through the year, like always. The main issue I was referring to was ubuntu-18.04 has Python 3.6, so if you use pipx on GHA and use ubuntu-18.04 you get 3.6 (note that ubuntu-latest is ubuntu-20.04, which is fine). Since pip is dropping 3.6, this is becoming a bit nicer. I expect drops to be happening all year.
Note that conda-forge still supports 3.6 (not sure why), so https://github.com/conda-forge/nox-feedstock will need to be updated when this is dropped (https://github.com/conda-forge/pip-feedstock forgot. Both last year and this year!)
To be clear, I don't have any objections, I mostly wanted a release with the recent changes out, and that happened. If nice work has gone in supporting an old Python version, it's nice to release it before dropping.

Wow, you are right. Just followed the issue. I'd be shocked if it lasts till 2029, but okay. 3.6 would be like 2.7 at that point...

Ahh, I (we) misread. It says not before mid-year next year (2023 with "standard support" ending for 18.04). That's more reasonable.
By the miss-read logic, Python 3.5 would not have been dropped (Ubuntu 16.04, EOL 2026), or Python 3.4 (Ubuntu 14.04, EOL 2024) or Python 2.7 (any OS, including RHEL 8 and Ubuntu 2024, just not "default" anymore).

3.5 became very expensive to support in cibuildwheel & manylinux (more so than 2.7, actually, due to the ending of patch updates for it). 3.6 might become that way too, but currently, it's not at all hard to support there.

I'm +1 for dropping 👍🏻

I'm big 👍  for dropping. I feel like most projects have a policy of "last 3 major releases" so it would be nice to get rid of 3.7 too (the download numbers ruin this argument).

I think I've seen NEP 29 (42 months) and official Python EOL (5 years), but not "last three" - the release cadence of Python changed around 3.8, so last three would change in size of support window to only 3 years, while it would have been 5.5 before. This is not a PyData project, so I'd not go drop Python versions that are not past official Python EOL. (I rather wish NumPy had adopted Python EOL, one rule would be nicer than several - I understand why, but doesn't mean I love it)
5 years is often "normal" LTS support, too.

Ok, since it seems like we can drop Python 3.6, I'm gonna merge this. I think we will drop Python 3.7 the next year or even later (I don't really like the "last 3 major releases" policy). Thanks everybody for the guidance!

Python 3.7's EOL is Jun 27, 2023.

After that, it will be every October, in sync with new Python releases.

@henryiii thanks for the information! I didn't know that new Pythons will EOL in October.


Find better default thread numbers for backup and import

Feature Request
Currently, we use 75% of logical CPU cores for backup and 8 threads for importing SST.

For backup, with so many CPU resource used, backup would probably impact the online cluster.
For importing, we can utilize nearly all the resources in the cluster, but the constant 8 is too small for some conditions.

Is your feature request related to a problem? Please describe:
An internal test shows, for a write-only workload, the impact to the cluster is relative to the CPU used by BR.

The green line is QPS.
Chinese text in the graph, from left to right:

Only read the disk.
Run BR, the red line is CPU-cost, and the blue line is the CPU used by backup worker
Run empty for loops. The orange line is the CPU costed by the empty for loops.

... Even the CPU isn't full. The cluster would still be impacted by the CPU usage.
The test also shows it seems the bottleneck isn't the disk:

The gold line is disk usage, blue line is BR CPU usage, orange line is total CPU usage, red line is empty loop CPU usage, green line is QPS.

Describe the feature you'd like:
Choose a better percentage of default thread number to the total CPU.
Modify the default import thread number by the resource of the node.
Describe alternatives you've considered:
Fix the problem throughput down by CPU usage even the CPU isn't full. Or implement some cheaper backup / restore method, say, copy SST files directly.
Teachability, Documentation, Adoption, Migration Strategy:
We can avoid teaching the user how to modify the config file before importing / backing up.

/label component/backup-restore

/component backup-restore

/sig migrate

The available resource for backing up would be vary with workload, e.g. Consider a heavy workload which occupies 60% of total CPU resource and a light workload (say, in midnight) which only uses 10% of total CPU, the best thread number for backup for each of them is indeed different.
As a solution, instead of let ops to decide the best value via experience, we can detect and auto tune the backup threads via a  soft limit. Briefly, it was designed like this:

We make a "token bucket" for backup tasks, with some traits:
a. This token bucket wouldn't generate token automatically.
b. When each backup worker wants to backup a BackupRange, it must acquire a token from the bucket, and put it back to the bucket when finished.
It is easy to prove that the total token number is the maximum backup tasks can be executed concurrently.

Periodically, we get the thread statistics via ThreadInfoStatistics, and according to the remain available CPU resources, put(or take) some tokens from the bucket, for restricting the backup resource costing.

Here is a demo and some test shows that the QPS impacted by backup can grow back eventually.
A test case:


created a seperate subroutine for writing history

Previously, writing history was part of the write_output subroutine. So every time the number of iterations mod write output was called there'd be a check if the number of iterations mod histstep was zero. So in the case that writeoutput wasn't a multiple of histstep in the parameters file the history wouldn't get recorded. I just made recording the history it into a separate subroutine so the history is always recorded and the files are correctly made regardless what the relationship between writeoutput and histstep is.

Thank you very much! I knew there was a bug in write history never got around to fixing it.
Jason
From: Gwenevere Frank @.>
Sent: Friday, June 2, 2023 5:24 PM
To: sccn/amica @.>
Cc: Subscribed @.***>
Subject: [sccn/amica] created a seperate subroutine for writing history (PR #41)
Previously, writing history was part of the write_output subroutine. So every time the number of iterations mod write output was called there'd be a check if the number of iterations mod histstep was zero. So in the case that writeoutput wasn't a multiple of histstep in the parameters file the history wouldn't get recorded. I just made recording the history it into a separate subroutine so the history is always recorded and the files are correctly made regardless what the relationship between writeoutput and histstep is.

You can view, comment on, or merge this pull request online at:
https://github.com/sccn/amica/pull/41
Commit Summary

e78a610 https://github.com/sccn/amica/pull/41/commits/e78a6108d4941c3071584c83bbe793e751d8a4d2  created a seperate subroutine for writing history

File Changes
(1 https://github.com/sccn/amica/pull/41/files  file)

M amica15.f90 https://github.com/sccn/amica/pull/41/files#diff-f591447b8a7fd5312343898d31b0cd0d1f55a4c6f74d9a3bb4ef1545cb7ffe8f  (82)

Patch Links:

https://github.com/sccn/amica/pull/41.patch
https://github.com/sccn/amica/pull/41.diff

—
Reply to this email directly, view it on GitHub https://github.com/sccn/amica/pull/41 , or unsubscribe https://github.com/notifications/unsubscribe-auth/ACRBESRZ73CE4QSRRLKN6PDXJJKYXANCNFSM6AAAAAAYYZ5Z3I .
You are receiving this because you are subscribed to this thread.  https://github.com/notifications/beacon/ACRBESTS2PMB52PRKGXQS3LXJJKYXA5CNFSM6AAAAAAYYZ5Z3KWGG33NNVSW45C7OR4XAZNFJFZXG5LFVJRW63LNMVXHIX3JMTHGPJE5YI.gif Message ID: @.*** @.***> >


Enable the dev server to proxy requests with methods other than GET

Currently all proxied requests are passed through as GET since no method is specified. This commit updates the proxied call to pass through the method that the initial request was made with.

LGTM, we eventually want to replace this with https://github.com/http-party/node-http-proxy but this is a good short term fix in the meantime


updated babel package names and commands

#4475
I have looked at the comments made by @harish-sethuraman and @invinciblejackalope and have updated the outdated package names where necessary.

Can you sign the CLA please?

I have submitted the CLA agreement about an hour ago but it has not yet updated. How can I fix this?

@harish-sethuraman The PR is ready for approval

Hey! I was @invinciblejackalope and opened the original issue. Thanks for writing the PR @tahseenio - wonder why this PR was closed? It doesn't seem like it was merged. It's my first time contributing so I'm not sure if this was intentional. @harish-sethuraman

Im not sure how and why this got closed either. Re opening this pr. PS: Id like to get more opinion before merging so waiting :)

Bump @gaearon? Sorry about the ping, just hoping that this doesn't get forgotten. It's a very simple package name update that would've saved me quite a bit of debugging.


Memory leak

Goals
Initializing a realm without creating a memory leak
Expected Results
Realm instance is autoreleased
Actual Results
try! Realm() increases the memory
Steps to Reproduce
https://github.com/Patrick-Remy/realm-memory-leak
Transition between app's foreground and background state.
Code Sample
https://github.com/Patrick-Remy/realm-memory-leak
Version of Realm and Tooling
Realm framework version: github "realm/realm-cocoa" "v3.12.0"
Realm Object Server version: –
Xcode version: Xcode 10.1
iOS/OSX version: iOS 12.1
Dependency manager + version: Carthage

➤ Lee Maguire commented:
This will be fixed with 4.3.2


RIP Bellhop?

http://i.imgur.com/KURvrBA.png

Oh yeah. I hired an intern to maintain it and at some point he pushed a breaking commit. Feel free to patch it up (I'll give you push access). I'm not planning on maintaining this myself though. :zzz:

Why did he stop working on it at a breaking commit lmao


Authorization for Virtual Machine External Service with ServiceEntry

Bug description
I followed the official guide for "Virtual Machines in Single Network Meshes", version 1.4 (https://istio.io/docs/examples/virtual-machines/single-network/) to connect
a Ubuntu VM to Istio and successfully connected to a web service running on that machine from
pods within my cluster.
However, when I try to connect to this web service with a mesh-external user agent, i.e.
browser on my laptop, I receive RBAC: access denied. I have configured the necessary
resources, in particular a Gateway, VirtualService, Policy, AuthorizationPolicy, however
I cannot get this particular setup to work. I have multiple Deployments and Services in
my cluster and I generally secure them with mTLS and use a JWT token for authorization.
I would expect that I could simply create a Policy and AuthorizationPolicy that state the
particular rules for the web application on my VM. However, I also realize that AuthorizationPolicies
apply not to services but to workloads. Therefore, the question arises if such policies can
be used on external applications running on VMs joined to Istio service mesh.
I add the web service on the Virtual Machine to a specific namespace and configure this
namespace for the intended purpose. The full configuration follows:
`yaml
apiVersion: networking.istio.io/v1alpha3
kind: ServiceEntry
metadata:
name: mesh-expansion-jupyter-lab-namia
namespace: user-nq10017569
spec:
endpoints:

address: <IP_ADDRESS>
labels: {}
hosts:
jupyter-lab-namia.user-nq10017569.svc.cluster.local
ports:
name: http-8888
number: 8888
protocol: HTTP
resolution: STATIC
location: MESH_EXTERNAL

apiVersion: v1
kind: Service
metadata:
name: jupyter-lab-namia
namespace: user-nq10017569
spec:
ports:

protocol: TCP
name: http-8888
port: 8888
targetPort: 8888

apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
name: jupyter-lab-namia
namespace: user-nq10017569
spec:
selector:
istio: ingressgateway
servers:

port:
number: 80
name: http
protocol: http
hosts:

jupyter-lab-namia.datalab-dev.ddc.telefonica.de

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: jupyter-lab-namia
namespace: user-nq10017569
spec:
hosts:

jupyter-lab-namia.datalab-dev.ddc.telefonica.de
gateways:
jupyter-lab-namia
http:
route:

destination:
host: jupyter-lab-namia.user-nq10017569.svc.cluster.local

apiVersion: "authentication.istio.io/v1alpha1"
kind: "Policy"
metadata:
name: default
namespace: user-nq10017569
spec:
peers:

mtls:
mode: PERMISSIVE

apiVersion: "security.istio.io/v1beta1"
kind: "AuthorizationPolicy"
metadata:
name: default
namespace: user-nq10017569
spec:
rules:

from:

source:
namespaces: ["user-nq10017569"]
to:
operation:
methods: [""]
paths: [""]

to:

operation:
methods: ["OPTIONS"]
paths: ["*"]

apiVersion: "security.istio.io/v1beta1"
kind: "AuthorizationPolicy"
metadata:
name: jupyter-lab-namia
namespace: user-nq10017569
spec:
selector:
matchLabels:
app: jupyter-lab-namia
rules:

to:

operation:
methods: [""]
paths: [""]
when:
key: request.auth.claims[iss]
values: ["https://keycloak.datalab-dev.ddc.telefonica.de/auth/realms/badatalab"]
`

[ x] Configuration Infrastructure
[ ] Docs
[ ] Installation
[x ] Networking
[ ] Performance and Scalability
[ x] Policies and Telemetry
[ ] Security
[ ] Test and Release
[ ] User Experience
[ ] Developer Infrastructure
Expected behavior
Steps to reproduce the bug
Version (include the output of istioctl version --remote and kubectl version and helm version if you used Helm)
1.4.6
How was Istio installed?
istioctl
Environment where bug was observed (cloud vendor, OS, etc)
EKS

Meanwhile, I managed to get past RBAC by applying the following AuthorizationPolicy
`apiVersion: "security.istio.io/v1beta1"
kind: "AuthorizationPolicy"
metadata:
name: default
namespace: istio-system
spec:
rules:

{}`

Obviously, this is not what I want because it signifies a general "allow all approach" in the whole cluster. Moreover, I have not been able to combine this "allow all" approach with more restrictive policies per namespace. In particular, none of the following policies have any effect.
`
apiVersion: "security.istio.io/v1beta1"
kind: "AuthorizationPolicy"
metadata:
name: default
namespace: user-nq10017569
spec:
{}
apiVersion: "security.istio.io/v1beta1"
kind: "AuthorizationPolicy"
metadata:
name: jupyter-lab-namia
namespace: user-nq10017569
spec:
selector:
matchLabels:
app: jupyter-lab-namia
apiVersion: "security.istio.io/v1beta1"
kind: "AuthorizationPolicy"
metadata:
name: jupyter-lab-namia
namespace: istio-system
spec:
selector:
matchLabels:
app: jupyter-lab-namia
`


📝 Documentation improvements and baseline structure

This PR includes a set of inicial changes in the documentation structure to describe the different roles, defaults, and descriptions to use for a user.
The description for each default is very simple, but it can be an initial step to mantain in the future as soon new variables or defaults are defined.

@rpelisse or @guidograzioli What do you think? Hope this PR can help to improve the documentation of this collection.


Deprecate IModelAppOptions.rpcInterfaces

@mergifyio backport release/3.7.x

Making it public would force most of the internal parts of the RPC system to become public also. We are trying to deprecate the RPC system right now. Making more and more of it public would push that goal further out of reach.

Instead of "promoting" from internal to public, would it make more sense for some of these things to be "promoted" to beta? Especially if the end goal is to deprecate and completely refactor the entire RPC system, which if we make things public in version N, then deprecate in N+1, then can only remove in N+2 (depending on if it was deprecated at the beginning of the new major) or N+3

In an ideal world, I think maybe.
As it is, these new publics are joining the existing RPC public api subset (RpcInterface, etc). All of that will have to be deprecated correctly once the system replacement is ready…

@paulius-valiunas mind taking a look from a backend perspective? How much will this pr break gpb?

GPB uses BentleyCloudRpcManager.initializeImpl, which doesn't seem to be deprecated here and its argument types are kept compatible. I don't think it will break anything.

@calebmshafer I think this is ready now :-)

All of that will have to be deprecated correctly once the system replacement is ready..

@aruniverse @calebmshafer @swbsi what ever came of these plans for replacing the RPC system?


YAML altsrc fails on Windows

NewYamlSourceFromFile does not understand how to parse a Windows file path e.g. C:\Users\cbranch\program.yaml.
This is because loadDataFrom expects paths to parse like URLs, an assumption that fails on Windows.

This was actually fixed by 7b912d9f8f8a78f192061ed5b0f40918dfda5a07 but hadn't been ported to v2 at the time I saw the issue. Closing.


update request dependency to 2.83.0

fixes #111

solved by https://github.com/coinbase/coinbase-node/pull/122


Update readme to work with newest Docker library

When docker ditched the docker-py library in favor of docker on PyPI they made a few very very small changes that break this library.
I've gone ahead and upgraded the readme to work with these new changes. I should point out that these changes are trivial- it basically amounts to changing docker.client() to docker.APIClient(). That's because the "low level API" that this project is based on has moved- but it is still there, and completely compatible with this library. Literally all anyone has to do in order to use the latest docker python library is change that one call so they get the low level client instead of the high level one.
resolves #78
resolves #79

Hello, Is there a plan to update the documentation?
At the moment, this is the only working library to get docker tty :)
Thanks for your work,
Andrea


runtime/pprof: no API to access deep stacktraces with MemProfileRecord and BlockProfileRecord

Go version
go version devel go1.23-b788e91bad Tue Jun 11 18:08:44 2024 +0000 linux/amd64
Output of go env in your module/workspace:
GO111MODULE=''
GOARCH='amd64'
GOBIN=''
GOCACHE='/home/korniltsev/.cache/go-build'
GOENV='/home/korniltsev/.config/go/env'
GOEXE=''
GOEXPERIMENT=''
GOFLAGS=''
GOHOSTARCH='amd64'
GOHOSTOS='linux'
GOINSECURE=''
GOMODCACHE='/home/korniltsev/go/pkg/mod'
GONOPROXY=''
GONOSUMDB=''
GOOS='linux'
GOPATH='/home/korniltsev/go'
GOPRIVATE=''
GOPROXY='https://proxy.golang.org,direct'
GOROOT='/home/korniltsev/github/go'
GOSUMDB='sum.golang.org'
GOTMPDIR=''
GOTOOLCHAIN='auto'
GOTOOLDIR='/home/korniltsev/github/go/pkg/tool/linux_amd64'
GOVCS=''
GOVERSION='devel go1.23-b788e91bad Tue Jun 11 18:08:44 2024 +0000'
GODEBUG=''
GOTELEMETRY='local'
GOTELEMETRYDIR='/home/korniltsev/.config/go/telemetry'
GCCGO='gccgo'
GOAMD64='v1'
AR='ar'
CC='gcc'
CXX='g++'
CGO_ENABLED='1'
GOMOD='/home/korniltsev/github/go/src/go.mod'
GOWORK=''
CGO_CFLAGS='-O2 -g'
CGO_CPPFLAGS=''
CGO_CXXFLAGS='-O2 -g'
CGO_FFLAGS='-O2 -g'
CGO_LDFLAGS='-O2 -g'
PKG_CONFIG='pkg-config'
GOGCCFLAGS='-fPIC -m64 -pthread -Wl,--no-gc-sections -fmessage-length=0 -ffile-prefix-map=/tmp/go-build1768278824=/tmp/go-build -gno-record-gcc-switches'

What did you do?
I compare stacks from runtime.MemProfile and runtime/pprof.WriteHeapProfile
https://go.dev/play/p/7iUI7DdMI3r?v=gotip
What did you see happen?
I see the MemprofileRecord stacks are truncated at 32 depth and pprof stacks has proper deep stacks.
What did you expect to see?
I expected MemprofileRecord.Stack() to return a slice with correct deep stack.

Similar Issues

https://github.com/golang/go/issues/43669
https://github.com/golang/go/issues/65328
https://github.com/golang/go/issues/64528
https://github.com/golang/go/issues/37446
https://github.com/golang/go/issues/63630

(Emoji vote if this was helpful or unhelpful; more detailed feedback welcome in this discussion.)

runtime.MemProfile and MemprofileRecord are used in [godeltaprof] (https://github.com/grafana/pyroscope-go/tree/main/godeltaprof)
It is probably possible to hack around the limitations by linking into runtime/pprof.memProfileInternal but in the light of https://github.com/golang/go/issues/67401 this now looks like less attractive idea.

I worked on the patch for adding deep stack traces. FWIW I initially tried to make deep stack traces available via the public API, see v35 of my CL.
The problem is that there are various go1compat challenges in doing this, so we'll need a proposal that either avoids them, or build consensus on accepting a minor amount of compat issues.

One of the possible solutions (for godeltaprof) could be to have the same functionality in golang standard library and to deprecate the godeltaprof project alltogether.
https://github.com/golang/go/issues/57765
https://github.com/golang/go/issues/67942

We have a similar issue in with Google's internal peakheap profile implementation. As the name suggest, the peakheap profile keeps track of high-water-mark heap profiles. I was considering filing a proposal to add peakheap profiles to the runtime, but I didn't have enough time to think it through. Given that I am not the only one with such a problem, I am favoring the idea of exporting the larger stacks via a runtime API now.
Regarding the go1compat challenges: Do we have to change the existing API or could there be a v2 API (e.g. in a new package, say runtime/profile).

@rsc I think there's some overlap, but this is really about a specific unresolved part of #43669. Meanwhile, #43669 is now mostly resolved, since as of https://go.dev/cl/572396, deep stacks are available everywhere except the runtime APIs, mentioned in this issue, IIUC. I think maybe we should close https://github.com/golang/go/issues/43669 in favor of this issue?

Sure, if you think #43669 is done, then feel free to close it.
Personally, I would say that the API to access the deep stack traces is runtime/pprof, and we just deprecate the old MemProfileRecord, BlockProfileRecord structs.

I assume we will have to link into new pprof_memPrifileInternal and co. if we want deep stacktraces? I am not missing anything, right?


Cant delete tripods

Looked everywhere and cant find any documentation on how to remove a tripod camera without leaving the world / server.

Unable to reproduce. Does this happen without any other mods?

Yep it looks like it.
All i have in my mods folder is; fabricapi == 1.19 and freecam == 1.19

What version of Freecam/Fabric API are you using?

Tripod Reset was added in 1.1.7.

that would be why, thankyou.
is there a 1.19 mod that is 1.1.7?

The latest version, 1.1.9, works with 1.19.4

I need a 1.19.0 version. If not then I don't mind about the tripods, I rarely use them.

Ah, in that case, 1.1.6 is the only version that supports 1.19.0

Thankyou for clearing this up.
sorry for the waste of your time :)

No problem!


feat: [IDP-2688]: Added a tutorial to use catalog metadata ingestion API

Added a tutorial to use catalog metadata ingestion API to create a jira project and add it back in the catalog
Description

Please describe your changes: Added a tutorial to use catalog metadata ingestion API to create a jira project and add it back in the catalog
Jira/GitHub Issue numbers (if any): ______________________________
Preview links/images (Internal contributors only): __________________

PR lifecycle
PRs must meet these requirements to be merged:

[x] Successful preview build.
[x] Code owner review.
[x] No merge conflicts.
[x] Release notes/new features docs: Feature/version released to at least one prod environment.

Please check the Execution Link of the Pipeline for the Website Draft URL. This is located in the Preview Step behind the Harness VPN and also is available in #hdh_alerts. E.g Website Draft URL: https://unique-id--harness-developer.netlify.app. Current Draft URL is: https://664b30e089a77b700b26859d--harness-developer.netlify.app

Please check the Execution Link of the Pipeline for the Website Draft URL. This is located in the Preview Step behind the Harness VPN and also is available in #hdh_alerts. E.g Website Draft URL: https://unique-id--harness-developer.netlify.app. Current Draft URL is: https://664ed78a16ea9ab29dcd0e66--harness-developer.netlify.app

Please check the Execution Link of the Pipeline for the Website Draft URL. This is located in the Preview Step behind the Harness VPN and also is available in #hdh_alerts. E.g Website Draft URL: https://unique-id--harness-developer.netlify.app. Current Draft URL is: https://664f149ba169fb0af2782258--harness-developer.netlify.app

Please check the Execution Link of the Pipeline for the Website Draft URL. This is located in the Preview Step behind the Harness VPN and also is available in #hdh_alerts. E.g Website Draft URL: https://unique-id--harness-developer.netlify.app. Current Draft URL is: https://66501c5caf6b27e1502c7b4f--harness-developer.netlify.app


Disable peek on F8 (linting)

I love hitting F8 to go to the next lint issue but Peek is super annoying and splits the code which makes it's hard to read.  I'd much rather have to hover over the issue or see it in the status bar.  Or at least have an X I can click to close it.

/duplicate of #51787


Falling tmp to VERSION file, pinning to proper Golang version in promu(!)

This blocks rc release.
cc @sylr
Signed-off-by: Bartek Plotka<EMAIL_ADDRESS>

Issue: https://circleci.com/gh/improbable-eng/thanos/3668


Add RFI link (once it becomes available)

Describe the bug
Link to federalregister.gov/whatever the link is to link to the CEJST RFI.
To Reproduce
Steps to reproduce the behavior:

Go to 'Explore the tool'
Scroll down to 'links below the map'
See error

Expected behavior
Once the RFI is available, we need to link to it.
Screenshots

If applicable, add screenshots to help explain your problem.
Desktop (please complete the following information):

OS: [e.g. iOS]
Browser [e.g. chrome, safari]
Version [e.g. 22]

Smartphone (please complete the following information):

Device: [e.g. iPhone6]
OS: [e.g. iOS8.1]
Browser [e.g. stock browser, safari]
Version [e.g. 22]

Additional context
Add any other context about the problem here.

@BethMattern and/or @KameronKerger - is this the right link for the RFI?
https://www.federalregister.gov/documents/2021/05/05/2021-09109/methods-and-leading-practices-for-advancing-equity-and-support-for-underserved-communities-through

nope @vim-usds , ours isn't live yet but it will be at:
https://www.federalregister.gov/d/2022-03920


Idempotent payconiq transactions

Make sure transaction are created in an idempotent way. If an error happens after the Payconiq payment is made (which I had during testing) and the user retries by pressing the PAY button again, then the money shouldn't be withdrawn from his account a second time. Eg. by always using the same transaction id for the same message. Perhaps use the message key as transaction id.

It was the intention that the form was submitted automatically in case the transaction was already paid. Now the user is stuck. See screenshot:


A11y_ML .NET Model Builder_ Scenario_ Screen Reader: Narrator/NVDA is not reading any information when focus comes to any of the Scenarios

“Check out Accessibility Insights! - Identify accessibility bugs before check-in and make bug fixing faster and easier.”
GitHubTags:
#A11yMAS; #A11yTCS; #Win32; #DesktopApp; #Feature-ML.NETModelBuilder-Win32-Nov2020; #A11ySev2; #NonBenchmark; #Visual Studio; #Screen Reader; #Narrator; #NVDA; #WCAG1.3.1;
Environment Details:
Microsoft Visual Studio 2019 Preview 16.8.0 Version 6.0
Screen Readers:
Narrator; NVDA
Note:
Same issue is observed in "Next Steps" scenario as well
Repro Steps:
1.Start Screen Reader
2.Open Visual Studio Enterprise 2019 Preview
3. Create a new .Net Core Console App (C#)
4. Tab to "Solution Explorer" and right click on the project (Shift + F10) and then from the expanded list Select "Add" and then from the list items select "Machine learning"
5. Verify how screen readers are reading the scenarios
Actual Result:
Narrator/NVDA is not any information when focus comes to any of the Scenarios
Expected Result:
Narrator/NVDA should read the name of the scenario properly
User Impact:
Screen Reader users will not get to know about the scenario if screen readers doesn't read any information about them
Attachment for Reference:
1116_ML .NET Model Builder_ Narrator is not reading any info when focus is on scenario.pptx
1116_ML .NET Model Builder_ NVDA is not reading any info when focus is on scenario.pptx

Build to test here: https://devdiv.visualstudio.com/_apis/resources/Containers/7181026/VSSetup?itemPath=VSSetup%2FMicrosoft.ML.ModelBuilder.vsix.
Download and install the vsix on your Visual studio instance. This build can be used to test all the "Ready to review" bugs (should be all)

Verified the issue in below version.
Microsoft Visual Studio Enterprise 2022 (64-bit) - Current
Version 17.4.4
Issue is fixed, please find below attachment.
Github tag:; #Closed;


Fix docs and error message typos

Fixes various typos I saw in docs and error messages.

We can't merge this until you fix the coverage and I'm not sure how you do that for a PR that is just doc string typo fixes.

I'll close the PR then and add these changes in a commit to a separate PR with a new feature.


no-unused-variable, should be split into no-unused-variable and no-unused-import

Bug Report

TSLint version: 5.7.0
TypeScript version: next
Running TSLint via:  yarn scripts

TypeScript code being linted
import {xyz} from 'abc';
import {foo} from 'bar';

class MyPage {
    test: string = xyz();
}

with tslint.json configuration:
{
  "rules": {
    "no-unused-variable": true
  }
}

Actual behaviour / Expected.
With fix mode it strips the "test" property because its not being used. But it actually is (via a template that this class gets bind too).
Is there a way to just have unused imports checked, but leave my variables alone?

no-unused-variable only complains about unused private properties. Your property test is public. That means your code snippet must be wrong.

no-unused-variable now uses diagnostics directly from TypeScript. Closing this issue as we don't want to maintain two rules that mirror TypeScript's diagnostics.


When using the “winget download” option, the downloaded file is not saved.

Brief description of your issue
When using the "winget download" option, the program file is downloaded, checked and deleted instead of saving
Steps to reproduce
winget download --id Git.Git -e --source winget ;
Expected behavior
presence of the file %Temp%\WinGet\Git.Git.2.45.1\Git-2.45.1-64-bit.exe
Actual behavior
the downloaded file is deleted after checking the hash.
Environment
[winget --info]
Windows Package Manager version: 1.7.11261
Windows: Windows.Desktop version: v10.0.19045.4412
Package: Microsoft.DesktopAppInstaller version: v1.22.11261.0

I'm Sorry, I find files in folder "Downloads"


Type error

Bug summary
When trying to use foyer to produce a hand made molecule (files/DTPA_bis_ethylhexylamino.mol2) it gave found no types for atom error. When 22 amino acids and carboxylic acids were tested, only 1 amino acid and carboxylic acid  passed while all other amino acids failed. This suggests that the error is with oplsaa.xml file that details a possibility of carboxylic carbon to be bonded to amine carbon.
What were you trying to do and what happened instead? Please copy and paste the stack output
when building a custom molecule in structure similar to amino acids the molecule and most amino acids fail the subsequent energy minimize.
List of failed amino acids with  an error foyer.exceptions.FoyerError: Found no types for atom "N" (6), wehre "N" changes depending on molecule:
arginine, histidine, lysine, aspartic acid,  L glutamic acid, serine, threonine, asparagine, glutamine, cysteine, selenocysteine, proline, L alanine, valine, isoleucine, leucine, Methionine, Phenylalanine, Tyrosine.
List of failed amino acids and molecules with an error: fails with an error such as: foyer.exceptions.FoyerError: Found multiple types for atom 2 (6): ['opls_235', 'opls_267']. are :
files/DTPA_bis_ethylhexylamino.mol2, Tryptophan
List of passed amino acids with an exception: Exception: Parameters have not been assigned to all proper dihedrals. Total system dihedrals: 14, Parameterized dihedrals: 13. Note that if your system contains torsions of Ryckaert-Bellemans functional form, all of these torsions are processed as propers:
glycine
List of passed acids:
acetic acid.
Code to reproduce the behavior
Included in the zip, short version:
import mbuild as mb
from foyer import Forcefield
import mbuild.formats.charmm_writer as mf_charmm
water_FF_file = 'files/oplsaa.xml'
water_molecule = mb.load('NCCCCC(N)C(=O)O', smiles=True) # fails lysine
water_molecule.energy_minimize(water_FF_file , steps=10**4)
water_molecule.name = 'DTPA'
water_molecule.save('DTPA_bis_ethylhexylamino.mol2', overwrite=True)#, combine='all')
Please include a code snippet that can be used to reproduce this bug.
# Paste your code here
#
#

Software versions

Which version of Foyer are you using? (python -c "import foyer; print(foyer.version)")
foyer                     0.9.3
mbuild                    0.13.0
aminoError.zip

Which version of Python (python --version)?
python                    3.7.10

Which operating system?
Linux ubuntu

I think this is just the SMARTS string field of the atomtype section of the XML hasn't been fully filled


Create Ubuntu 23.04 Install deps tab in the wiki

previous discution: https://github.com/hyprwm/Hyprland/pull/2196

thanks!

to you guys!!, thanks!


add SYSUCC to contributors

The SVG in this pull request is a bit broken. It seems to be a .png file embedded inside a SVG and it isn't rendering on the website properly.
Do you have a proper SVG file @likelet? Also a monochrome one in white if possible, that's needed for the website homepage.

thanks, i am trying to find one

Hi @likelet,
Any luck finding a vector version of your logo? I've had a bit of a look around on google and can't find anything. I've just made a small PR in #48 where I've replaced the SVG with a PNG (as it was a png embedded within a svg anyway). I also managed to track down a monochrome version of the logo and managed to make a white transparent PNG version for the homepage.
Phil


Add dev container configuration

This adds a dev container configuration for trying out or working on this project in a codespace or local dev container. The default dev container configuration using the universal image does not support this project well.
Why the default config doesn't support this project (click to expand if interested)

Not every project requires such a configuration to be usable in a dev container. When no devcontainer.json file is present, a universal image is used, which is a large image with tools for many languages and frameworks. Furthermore, it can be better to use the universal image than a custom image, if the custom image would have a longer startup time, as is often the case.
Unfortunately, the universal image is unsuitable for working on this project because the Python implementation it ships is built without lzma support. npc-gzip can be used as a library where lzma support is absent, so long as it is not needed. But it is needed for some unit tests to pass (as well as to actually do anything with the lzma compressor). Furthermore, because users often use a codespace to get a feel for a project, all of a project's core functionality should be usable in a dev container, where feasible. The lack of lzma support was helpful when reviewing #30 because it allowed me to verify that the error-handling logic for that condition was working, but for any other goal it is a disadvantage.
Another reason this project benefits from a custom devcontainer.json is that the most popular way to use dev containers is in GitHub Codespaces with small codespaces not offering GPU access. Nothing in this project requires a GPU--that's one of the benefits of the technique presented in the paper and implemented in this codebase--but the modules in examples use PyTorch. On GNU/Linux systems, installing torch from PyPI provides a build that expects CUDA libraries to be installed and raises ImportError when they are absent. One of the goals of dev containers is to be able to get up and running with minimal effort, and providing a custom devcontainer.json enables a workaround for this issue to be applied.

This adds a custom devcontainer.json using the Debian 12 based Python 3.11 image, which is one of the prebuilt Python images. Unlike the universal image, python in that image is built with lzma support, and all tests are able to run and pass. I also included a script run on dev container creation that takes care of installing poetry with useful plugins, using it to install the project, and modifying the resulting environment with a compatible torch package so that the code in examples can also be imported and run.
This supports using the new codebase, including the examples, with minimal effort. Although it would be useful for the dev container to also support using the old codebase with minimal effort, this does not attempt that, because:

I think it may be better to have a separate selectable dev container configuration for it, especially if its dependencies are to be automatically installed during container creation.
More importantly, installing the torch dependency--for old_codebase, not for the new code--uses more RAM than a default codespace provides. (I found that out when testing locally while limiting memory usage, and also on a separate branch with a 3.10 container, since the old codebase requirements.txt is not compatible with 3.11.)

wow this is very considerate @EliahKagan ! thanks!

No problem--I find it useful myself!


define logstream_name with a dynamic value from record

Problem
I'm trying to configure fluentd so that it creats a new logstream for each namespace. log_stream_name does not parse the value of the variable ${record['kubernetes‘]['namespace_name']}.
The logstream is created with this exact name : ${record['kubernetes‘]['namespace_name']}....
Steps to replicate

      @type forward
      port 24224

      @type cloudwatch_logs
      log_group_name my-log-group-sample
      log_stream_name ${record['kubernetes‘]['namespace_name']}
      auto_create_stream true

Expected Behavior or What you need to ask
name of kubernetes namespace
...

@imedaouidene I met the same problem, may I know how did you fix it? Thank you very much.

using log_stream_name_key fixed my issue.


Problem of multi-GPU "'NCCL' has no attribute 'new_uid'"

Hi, I had clone your code and install NCCL. However , when run the file train_multi_gpu.py, I encounter a error:

Traceback (most recent call last):
File "./tools/train_net_multi_gpu.py", line 109, in
max_iter=args.max_iters, gpus=gpus)
File "/home/ultron/py-R-FCN-multiGPU/tools/../lib/fast_rcnn/train_multi_gpu.py", line 205, in train_net_multi_gpu
uid = caffe.NCCL.new_uid()
AttributeError: type object 'NCCL' has no attribute 'new_uid'

I think I installed NCCL correctly, and I found the same problem in the issue, but it did not work

OK. I solve this problem.
I use cmake to build caffe. However, in cmake configuration, it shows Found NCCL, so I ignore USE_NCCL OFF. So, if you use cmake, you should change USE_NCCL from ON to OFF in CMakeLists.txt.


Automates cover

This is a base implementation of cover automation, should it be added to the system and if so, should it be implemented like that ?

how to handle the creature cover for diagonals ? right now i am forcing a minimum of 5 ft. between the attacker and the target
there should probably be an easy way to ignore automated covers during a specific attack
there need to be checks for feats/features that work with cover in pf2e

I think we need to pass on wall cover until walls can be configured for whether and how much cover they provide.


Do this method still works?

Facebook changed alot in their API for video fetching. Just want to make sure, is this method is still effective?

Hey @josephmiller2000

Facebook changed alot in their API for video fetching

This module doesn't depend on Facebook's API. It's working absolutely fine.
I just checked the api for the new facebook videos to see if it's working, and yes, it does.
In case, you wanna quick check the functionality, copy and run the following code -
const fb = require('fbvideos');

const url = 'https://www.facebook.com/TypicalIndianComments/videos/931402620380721/'

fb.low(url).then(res => {
  console.log(res);
  // => { url: 'https://video.fdel11-1.fna.fbcdn.net/v/t42.9040-2/32049004_578096759228372_6824419449538347008_n.mp4?_nc_cat=0&efg=eyJ2ZW5jb2RlX3RhZyI6InN2ZV9zZCJ9&oh=ec30eb0cdfa920e6a00ed7ae7658babf&oe=5AF4C9D1' }

});

fb.high(url).then(res => {
  console.log(res);
  // =>  { url: 'https://video.fdel3-1.fna.fbcdn.net/v/t42.9040-2/32200809_1692887157431523_530251869180657664_n.mp4?_nc_cat=0&efg=eyJ2ZW5jb2RlX3RhZyI6InN2ZV9oZCJ9&oh=0e9b14b1d615db670b434f54c9e608d8&oe=5AF4CA1C' }

});

Hope this solves your problem!

No idea why I'm getting this error when I tried to install it.

This conflict happens when the name of the package and the name of the project folder is same.
Here, you are trying to install fbvidoes as a dependency under the fbvideos directory which already is a node package, so, it's causing this error.
Just change the directory to something  else, example - ($ cd ~/Desktop) and run $ npm install --save fbvideos and things will work fine!

Alright i got it :) now it is working.
So is there anyway to make it work in php? So i can make it run in my website to fetch facebook videos in a regular basis.. for an application.

I don't know how you can make it work in PHP, but if know how to code in PHP, I can explain how this module works so you can port in the language you like.


typo: fix wrong url in readme for v2

Repo not found for github.com/urfave/cli.v2
→ go get github.com/urfave/cli.v2
go get github.com/urfave/cli.v2: git ls-remote -q origin in $GOPATH/pkg/mod/cache/vcs/f2d73ffea2d87a2720e81700b9dcf7285d8c2e5750a4b4c55dff989e537a7c8e: exit status 128:
        remote: Repository not found.
        fatal: repository 'https://github.com/urfave/cli.v2/' not found

Correct path github.com/urfave/cli/v2
→ go get github.com/urfave/cli/v2
go: finding github.com/urfave/cli/v2 v2.0.0-alpha.2
go: downloading github.com/urfave/cli/v2 v2.0.0-alpha.2
go: extracting github.com/urfave/cli/v2 v2.0.0-alpha.2

Was changed in this commit https://github.com/urfave/cli/commit/4545ff3aa17882cf7f3b682eb09086a88abbe60a#diff-04c6e90faac2675aa89e2176d2eec7d8R28
cc @lynncyrin

thanks!

For the sake of tracking, I should mention that the URL had the . in it for at least 4 years: https://github.com/urfave/cli/commit/024b4c6240a085f57e3c7e7378106a3252dc0a77#diff-04c6e90faac2675aa89e2176d2eec7d8R51. I'm not sure what's making the URL wrong now, but we don't need to debug that ^^

@lynncyrin before the change, it was gopkg.in and now github.com. Github hasn't prefixes as gopkg.in


[Search] Layout of listed Products and Recipes

Two column layout to be handled between 900px - 1200px

This has been handled by reducing 60px for RHS section and the relevant fields are adjusted based on it.
PR https://github.com/hlxsites/fonterra-fernleaf/pull/133 contains the fixes along with other changes.

@asthabh23 Please verify the changes.
https://main--fonterra-fernleaf--hlxsites.hlx.page/en

lgtm!


Automate creating conformance config for plain fapi profile

See documentation:
https://openid.net/certification/certification-fapi_op_testing/
This profile uses the Test Trusted Directory.
Steps:

Generate JWKS using Test Trusted Directory and extract keys and certs
Complete DCR using the above

Set redirect_uris to ["https://www.certification.openid.net/test/a/forgerock-plain-fapi/callback", "https://www.certification.openid.net/test/a/forgerock-plain-fapi/callback?dummy1=lorem&dummy2=ipsum"]

Combine the above into conformance suite config (could be a manual process for now).

Alternative solution
Make core accept OB based clients. Then we can use the same code we use for the OB conformance suite to create dcr clients.
Dan to create new issue to make Plain Fapi (core) trust OB clients

These steps currently need to be done manually using Postman.
2 client registrations are required by the conformance suite, so this is a tedious process to do manually.

Closing in favour of supporting OB Trusted Directory (& certs) in core, which means we can reuse the CF pipelines to create FAPI ApiClients.
See:
https://github.com/SecureApiGateway/SecureApiGateway/issues/1338
https://github.com/SecureApiGateway/SecureApiGateway/issues/1339


Develop -> Master

Release 0.1.1

Codecov Report

Merging #222 into master will increase coverage by 0.09%.
The diff coverage is 100%.

@@             Coverage Diff              @@
##             master     #222      +/-   ##
============================================
+ Coverage     88.21%   88.31%   +0.09%
- Complexity     1880     1890      +10
============================================
  Files           119      119
  Lines          6595     6649      +54
  Branches       1069     1080      +11
============================================
+ Hits           5818     5872      +54
  Misses          714      714
  Partials         63       63