Which license does this project use?

Hi there,
thank you for developing this library. However, I could not find a license file. Which license does this project use?
Thanks,
Yannik

Hi @yanniks,
Thanks for submitting this issue - it totally slipped my mind to include that file...
I've updated the project accordingly.
The license is Apache 2.0


xml V3.0RC02 Type of Property/value not correct

https://github.com/admin-shell-io/aas-specs/tree/draft-V3RC02-schemas
xml schema:
Type of Propery/value is value „any xsd atomic type as specified via DataTypeDefXsd“ according to specification V3.0RC02 and not string (https://industrialdigitaltwin.org/wp-content/uploads/2022/06/DetailsOfTheAssetAdministrationShell_Part1_V3.0RC02_Final1.pdf)
Note: In previous versions of the spec the type was anySimpleType
Note: for JSON serialization string was accepted as type

Closing since addressed in #219.


increase range for span sampling test to reduce flakiness

Despite never failing locally for me, it seems the range is a little more varied in CI, so expanding it to reduce flakiness.

An example failed test run: https://github.com/DataDog/dd-trace-py/actions/runs/3093749636/jobs/5006455659
       assert len(sampled) in range(40, 60)
>       assert len(unsampled) in range(40, 60)
E       AssertionError: assert 60 in range(40, 60)
E        +  where 60 = len([[{'duration': 1567790, 'meta': {'runtime-id': '9b11e4f1c78842c6b72dd829ba5b67ac'}, 'metrics': {'_dd.agent_psr': 1.0, ...': 1.0, '_dd.top_level': 1, '_dd.tracer_kr': 1.0, '_sampling_priority_v1': -1, ...}, 'name': 'web.request', ...}], ...])
E        +  and   range(40, 60) = range(40, 60)

test_span_sampling.py:190: AssertionError


Feature/nafpa s2s biascorr

Description
Added NAFPA GFS-to-GALWEM bias correction for S2S work.

As @jvgeiger is on leave, I will reluctantly approve my own pull request.
Breaking the law, breaking the law
Breaking the law, breaking the law


Colors no longer obeyed in 1.4.0

It seems that the color preferences are no longer respected in 1.4.0.
I was looking through the release notes, and did not see anything to explain it.
What version of GoTTY are you using (gotty --version)?
Gotty 1.4.0 - bug exists
Gotty 1.3.0 - bug does not exist
What operating system and browser are you using?
Ubuntu 20.04
What did you do?
Have this file in ~/.gotty
port = 3000

term = "hterm"

preferences {
  background_color = "white"
  foreground_color = "black"
  cursor_color = "blue"
}

and run gotty --once ls
Note: This exact same config worked in all previous Gotty versions, including 1.3.0
What did you expect to see?
The terminal background color should be white.
What did you see instead?
The terminal background color was black.

I see now that hterm was removed - does this mean that there is no longer color customization?

Yes, unfortunately, that's the current state of affairs. I'm going to try to add some options in the UI to change colors, fonts, etc.

Yes, unfortunately, that's the current state of affairs. I'm going to try to add some options in the UI to change colors, fonts, etc.

I was afraid of that.... that is a deal breaker for me. Thanks for trying.

I'll also add an option to set the default theme once I get that far. That should let you do what you want.


TensorRT support of rapidflow

Hi, thanks for your great work!
I want to export the rapidflow to ONNX, but it seems that there are many custom layer in it (mainly from local_timm) and some ops are not supported in onnx opset? Do you know how can I solve this problem?

Hi,
I updated rapidflow's readme with some instructions about how to export to ONNX. Please take a look and see if it works for you. It requires ONNX opset >= 16.
Best,
Henrique

Hi,
I updated rapidflow's readme with some instructions about how to export to ONNX. Please take a look and see if it works for you. It requires ONNX opset >= 16.
Best,
Henrique

OMG, thank you so much! It dose work for me such a beginner!
I am considering learning how to write a TensorRt plugin for 'alt_cuda_corr' and register it. But you mentioned that alt_cuda_corr is much slower than all-pairs corr, and speed is much more important for me. So maybe directly converting the model to ONNX is the best choice for me?
BTW,during conversion I noticed that you set (384, 1280) as default padding image size for kitti, why not choose (384, 1248) which is closer to the origional resolution (375, 1242)?

I am considering learning how to write a TensorRt plugin for 'alt_cuda_corr' and register it. But you mentioned that alt_cuda_corr is much slower than all-pairs corr, and speed is much more important for me. So maybe directly converting the model to ONNX is the best choice for me?

If you are not going to use large images, then all-pairs corr is probably better.

BTW,during conversion I noticed that you set (384, 1280) as default padding image size for kitti, why not choose (384, 1248) which is closer to the origional resolution (375, 1242)?

Yes, you can use 1248. I just chose 1280 out of habit because it is multiple of more powers of 2, but it is not necessary here.
Actually, since the padding/resizing is inside RAPIDFlow (see self.preprocess_images and self.postprocess_predictions inside RAPIDFlow's forward), I think you can even use (375, 1242) as the size. However, in an ONNX application, I think it is maybe a better idea to remove those resizing operations out of the model to make it more flexible and possibly avoid unnecessary operations.

I am considering learning how to write a TensorRt plugin for 'alt_cuda_corr' and register it. But you mentioned that alt_cuda_corr is much slower than all-pairs corr, and speed is much more important for me. So maybe directly converting the model to ONNX is the best choice for me?

If you are not going to use large images, then all-pairs corr is probably better.

BTW,during conversion I noticed that you set (384, 1280) as default padding image size for kitti, why not choose (384, 1248) which is closer to the origional resolution (375, 1242)?

Yes, you can use 1248. I just chose 1280 out of habit because it is multiple of more powers of 2, but it is not necessary here.
Actually, since the padding/resizing is inside RAPIDFlow (see self.preprocess_images and self.postprocess_predictions inside RAPIDFlow's forward), I think you can even use (375, 1242) as the size. However, in an ONNX application, I think it is maybe a better idea to remove those resizing operations out of the model to make it more flexible and possibly avoid unnecessary operations.

Thanks for your reply so quickly.
Yes I see that pre- and post- process are included in the onnx model. I add the setting "dynamic_axis" when calling onnx export function so that the model can accept different input size. I think this is good because I don't have to manually resize the raw input for the network, and I think resize op using GPU in onnx or tensorrt engine anyhow is faster than the manual one.

I am considering learning how to write a TensorRt plugin for 'alt_cuda_corr' and register it. But you mentioned that alt_cuda_corr is much slower than all-pairs corr, and speed is much more important for me. So maybe directly converting the model to ONNX is the best choice for me?

If you are not going to use large images, then all-pairs corr is probably better.

BTW,during conversion I noticed that you set (384, 1280) as default padding image size for kitti, why not choose (384, 1248) which is closer to the origional resolution (375, 1242)?

Yes, you can use 1248. I just chose 1280 out of habit because it is multiple of more powers of 2, but it is not necessary here.
Actually, since the padding/resizing is inside RAPIDFlow (see self.preprocess_images and self.postprocess_predictions inside RAPIDFlow's forward), I think you can even use (375, 1242) as the size. However, in an ONNX application, I think it is maybe a better idea to remove those resizing operations out of the model to make it more flexible and possibly avoid unnecessary operations.

Well, I think you are right. Maybe the pre- and post- operations still need to be placed outside the network, because the resolution of two image frames in some datasets may be different... Or change the network to accept two inputs and resize them separately.

Hi,
I updated rapidflow's readme with some instructions about how to export to ONNX. Please take a look and see if it works for you. It requires ONNX opset >= 16.
Best,
Henrique

Sorry to bother you again. I made inference on a same image with ONNX and pytorch model for many times. The results of pytorch model make no difference for the same image, but the results of ONNX change everytime. I got this conclusion by comparing the post-processed flow resluts of ONNX and oytorch

de7ba-0e26-4af
![Screenshot from 2024-03-20 16-29-38](https://github.com/hmorimitsu/ptlflow/assets/92929904/faa783d1-586

7-494f-88f3-95387cd10cd1)
b-86d1-44aae4172174)
These are three inference results of a same image pair by a ONNX model. Do you konw the reason of this probelm?

Hi, I am sorry, but I am not very familiar with ONNX. Right now I cannot imagine what would cause the results to change. It seems that the difference is not very large. Is it possible that ONNX does not calculate results exactly (only approximate) to speedup the process and thus cause some flutuations in the results?
I will try to think more about it and let you know if I find something. If you find out the reason, please let me know. I am also curious.

Hi, I am sorry, but I am not very familiar with ONNX. Right now I cannot imagine what would cause the results to change. It seems that the difference is not very large. Is it possible that ONNX does not calculate results exactly (only approximate) to speedup the process and thus cause some flutuations in the results?
I will try to think more about it and let you know if I find something. If you find out the reason, please let me know. I am also curious.

Thanks for your reply. It seems that it is the issue of onnxruntime, which doesn't provide deteministic computations, see
https://stackoverflow.com/questions/69053582/onnx-model-inference-produces-different-results-for-the-same-input
https://github.com/microsoft/onnxruntime/issues/4611
It seems that there is nothing we can do to avoid the problem. The images I showed you before are comparison of the results of pytorch inference on the "CPU "and the results of  ONNX inference on onnxruntime-GPU, with error threshold “tolerance rtol=0.001, atol=1e-05”. Yes, the difference is totally acceptable.
And when I compare the results of pytorch inference on the "GPU "and the results of ONNX inference on onnxruntime-GPU, it's be like

From the result we know that pytorch infer in GPU and CPU have different result (But why do the results of onnxruntime-gpu look more like the results of pytorch on the CPU than pytorch on the GPU? I've tried ONNXs exported by pytorch running in CPU and the one running in GPU, and get same results. I can't find the answer)
The number of mismatch seems pretty large in pytorch-GPU situation. I guessed maybe the error threshold is too small, so I raised the threshold to “tolerance rtol=0.001, atol=0.0001“, and the result is better

keep raising the threshold to "tolerance rtol=0.01, atol=0.001" and result is “stably” better (number of mismatch is 0～3）

Apparently almost all of mismatch is less than 0.01(rtol) and 0.001(atol), and there is only one pixel with rtol always nearly 10 (don't know which point it is and why). Anyway, considering that this is a comparison of post-processing results, the actual smallest unit of flow should be 1 pixel, we can say that the performance of the converted onnx is satisfactory.

Thank you for this detailed analysis, I also learned a lot from it! I didn't know there were so many nuances about how you run the model, it is very interesting for practical applications. Thank you for checking that the ONNX version is still relatively stable too. I hadn't tested it very extensively before, so it's good to know it works.

Thank you for this detailed analysis, I also learned a lot from it! I didn't know there were so many nuances about how you run the model, it is very interesting for practical applications. Thank you for checking that the ONNX version is still relatively stable too. I hadn't tested it very extensively before, so it's good to know it works.

Thank you for providing such a superior model with the best balance of speed and accuracy. Learning to design such an innovative model structure is too difficult for me (AI theory develops too fast), while learning how to deploy and apply the model is relatively simple but also interesting. Thank you again for your work and your reply with patience.
best wishes


Installation with dashboard_protocol=https fails

What happened:
I am trying to set up a ceph cluster where the GUIs (Dashboard, Grafana) should use https. To achieve this, I set the flag dashboard_protocol in my inventory to https.
The installation fails in the step:
TASK [ceph-dashboard : inject grafana dashboard layouts]
Install Ceph Dashboard         : In Progress (0:01:05)
	This phase can be restarted by running: roles/ceph-dashboard/tasks/main.yml

with the error:
fatal: [node-1 -> <IP_ADDRESS>]: FAILED! => changed=false
  cmd:
  - docker
  - exec
  - ceph-mon-node-1
  - ceph
  - --cluster
  - ceph
  - dashboard
  - grafana
  - dashboards
  - update
  delta: '0:00:01.274663'
  end: '2020-04-24 23:06:26.607792'
  msg: non-zero return code
  rc: 22
  start: '2020-04-24 23:06:25.333129'
  stderr: |-
    Error EINVAL: Traceback (most recent call last):
      File "/usr/share/ceph/mgr/mgr_module.py", line 974, in _handle_command
        return self.handle_command(inbuf, cmd)
      File "/usr/share/ceph/mgr/dashboard/module.py", line 386, in handle_command
        push_local_dashboards()
      File "/usr/share/ceph/mgr/dashboard/grafana.py", line 133, in push_local_dashboards
        retry()
      File "/usr/share/ceph/mgr/dashboard/grafana.py", line 90, in __call__
        result = self.func(*self.args, **self.kwargs)
      File "/usr/share/ceph/mgr/dashboard/grafana.py", line 128, in push
        grafana.push_dashboard(body)
      File "/usr/share/ceph/mgr/dashboard/grafana.py", line 54, in push_dashboard
        raise GrafanaError("Could not connect to Grafana server")
    GrafanaError: Could not connect to Grafana server
  stderr_lines: <omitted>
  stdout: ''
  stdout_lines: <omitted>

And only the Dashboard answers on a https call.
What you expected to happen:
The installation should finalize succesfully and the Dasboard and Grafana GUIs should respond on https.
C-A files
install.20200424.225715.log
inventory.txt
Environment:

OS (e.g. from /etc/os-release): Ubuntu 18.04
Kernel (e.g. uname -a): 4.15.0-96-generic
Docker version if applicable (e.g. docker version): 19.03.8
Ansible version (e.g. ansible-playbook --version): 2.8.8
ceph-ansible version (e.g. git head or tag or stable branch): 4.0.22
Ceph-Daemon version: 4.0.12-stable-4.0-nautilus-centos-7

Could you try to run the following commands ? (from node-1)
# docker exec ceph-mon-node-1 ceph --cluster ceph dashboard set-grafana-api-ssl-verify False
# docker exec ceph-mon-node-1 ceph --cluster ceph dashboard grafana dashboards update

As you're using self signed certificate for grafana, I suspect that the dashboard grafana dashboards update subcommand to fail because the TLS certificate isn't trusted.

After running the commands you mentioned, I reran the installer, which this time ended correctly and the Dashboards are shown on https! Thank you very much!
Any chance this can be fixed in the future?


ActiveModel::MassAssignmentSecurity::Error in Rails 4.2.1

We have a Tag model with has_closure_tree and are trying to create records
2.1.5 :001 > Tag.create(name: 'Grandpa')
   (0.5ms)  BEGIN
  Tag Exists (1.3ms)  SELECT  1 AS one FROM "tags" WHERE "tags"."token" = $1 LIMIT 1  [["token", "9b52"]]
  SQL (0.9ms)  INSERT INTO "tags" ("name", "token", "created_at", "updated_at") VALUES ($1, $2, $3, $4) RETURNING "id"  [["name", "Grandpa"], ["token", "9b52"], ["created_at", "2015-06-01 13:44:50.559933"], ["updated_at", "2015-06-01 13:44:50.559933"]]
   (0.7ms)  SELECT pg_try_advisory_lock(1814493058,0) AS ta04b3ce0fea05bd032f8b54a95ebadae
   (0.4ms)  SELECT pg_advisory_unlock(1814493058,0) AS t407ea30ef4991b612dde23167ff09488
   (0.4ms)  ROLLBACK
ActiveModel::MassAssignmentSecurity::Error: Can't mass-assign protected attributes for TagHierarchy: ancestor, descendant, generations

closure_tree 5.2.0
rails 4.2.1
activerecord 4.2.1
ruby 2.1.5

This issue's been raised and resolved several times, please search prior
issues for context and solutions.
If not, please include your tag model class or a test case that reproduces
this issue.
On Jun 1, 2015 6:50 AM, "Tom Brammar"<EMAIL_ADDRESS>wrote:

We have a Tag model with has_closure_tree and are trying to create records
2.1.5 :001 > Tag.create(name: 'Grandpa')
(0.5ms)  BEGIN
Tag Exists (1.3ms)  SELECT  1 AS one FROM "tags" WHERE "tags"."token" = $1 LIMIT 1  [["token", "9b52"]]
SQL (0.9ms)  INSERT INTO "tags" ("name", "token", "created_at", "updated_at") VALUES ($1, $2, $3, $4) RETURNING "id"  [["name", "Grandpa"], ["token", "9b52"], ["created_at", "2015-06-01 13:44:50.559933"], ["updated_at", "2015-06-01 13:44:50.559933"]]
(0.7ms)  SELECT pg_try_advisory_lock(1814493058,0) AS ta04b3ce0fea05bd032f8b54a95ebadae
(0.4ms)  SELECT pg_advisory_unlock(1814493058,0) AS t407ea30ef4991b612dde23167ff09488
(0.4ms)  ROLLBACK
ActiveModel::MassAssignmentSecurity::Error: Can't mass-assign protected attributes for TagHierarchy: ancestor, descendant, generations
rails 4.2.1
activerecord 4.2.1
ruby 2.1.5
—
Reply to this email directly or view it on GitHub
https://github.com/mceachen/closure_tree/issues/156.

RTFM Tom!:
Make sure you add has_closure_tree after attr_accessible and self.table_name = lines in your model.
Sorry Matthew

Great to have an easy fix!
Feel free to add more error messages or whatever you think would make the
FM be more "R"able—pull requests are welcomed.


Files in production cannot find JS file inside folder 2.

Hi,
I'm trying to deploy my project into production but I notice that the file inside of 2. folder isn't found. I found the file that sets this but I can't manage to find any errors about it. The only thing I can provide is this error message shown in the console:

GET http://localhost:3000/2./.7fbfba24286f6b55d700.js 404 (Not Found)

Hi,
I've had the same issue, it's because you set the name of the output file : '/'.
This creates a folder rather than a file.
You must change your 'Webpack named bundle' at the end of the file:
import { injectReducer } from '../../store/reducers'

export default (store) => ({
  /*  Async getComponent is only invoked when route matches   */
  getComponent (nextState, cb) {
    /*  Webpack - use 'require.ensure' to create a split point
        and embed an async module loader (jsonp) when bundling   */
    require.ensure([], (require) => {
      /*  Webpack - use require callback to define
          dependencies for bundling   */
      const MaterialUI = require('./containers/MaterialUI').default
      const reducer = require('./modules/MaterialUI').default

      /*  Add the reducer to the store on key 'counter'  */
      injectReducer(store, {key:'materialUI', reducer})

      /*  Return getComponent   */
      cb(null, MaterialUI)

    /* Webpack named bundle   */
    }, 'home')
  }
})

So, in my dist/ folder, i have a file named: 0.home.edd4fa5a1d72c57ba5ae.js
You certainly defined this name at '/', like that:
/* Webpack named bundle   */
    }, '/')

The compiler generate a folder instead of a file in this case ...

Thanks @Enigma-42.


Please update version of .swift-version to 4.0

Please update version of .swift-version to 4.0 and release new version for this.

I will try to do, pod was giving me errors.

I am facing same issue

Viktors-iMac:SCLAlertView-Swift viktorradchenko$ pod trunk push

[!] Found podspec `SCLAlertView.podspec`
Updating spec repo `master`
Validating podspec
 -> SCLAlertView (0.8)

Updating spec repo `master`

--------------------------------------------------------------------------------
 🎉  Congrats

 🚀  SCLAlertView (0.8) successfully published
 📅  March 4th, 01:39
 🌎  https://cocoapods.org/pods/SCLAlertView
 👍  Tell your friends!

Never mind this comment. I was calling it in the view did load method which gets called too early. great framework though!


false positive results when using vm.expectRevert - part of the test is ignored

Component
Forge
Have you ensured that all of these are up to date?

[X] Foundry
[X] Foundryup

What version of Foundry are you on?
forge 0.2.0 (893fc9f 2023-09-12T00:28:57.627748000Z)
What command(s) is the bug in?
forge test
Operating System
macOS (Apple Silicon)
Describe the bug
function test_should_fail_1() public {
    vm.expectRevert();
    revert("A");

    // execution stops here for some reason

    revert("never reverts and test passes");
}

function test_should_fail_2() public {
    vm.expectRevert();
    revert("A");

    assertTrue(false, "test pass despite failed condition");
}

this tests pass, but they should not.
foundryup: installed - forge 0.2.0 (893fc9f 2023-09-12T00:28:57.627748000Z)
foundryup: installed - cast 0.2.0 (893fc9f 2023-09-12T00:28:57.752674000Z)
foundryup: installed - anvil 0.2.0 (893fc9f 2023-09-12T00:28:57.365492000Z)
foundryup: installed - chisel 0.2.0 (893fc9f 2023-09-12T00:28:57.495467000Z)

Please see https://github.com/foundry-rs/foundry/issues/3723 — this is a known footgun, as reverts stop EVM execution. It will be fixed with #5728 but for now the recommendation is to split these tests.


feat: Support for Optimistic Quorum

Changes from https://github.com/snapshot-labs/snapshot/pull/4625 are also included in this PR,
so make sure it is merged to avoid confusion, with that PR you should be able to configure different types of quorum on proposals
This PR adds support for an optimistic quorum with which spaces can reject some proposal if the reach certain threshold
How to test:

Post proposals with different with different quorum types
default quorum should work same as before
Optimistic quorum should only consider 2nd choice and reject proposal if it reaches quorum value
for example if you go to this proposal

on proposals pages you see the % of quorum rejection

Can we rebase this branch to remove the unrelated changes from #4625 ?


How do I provide props to styled elements in Typescript?

I looked at the docs and other than creating a whole empty component purely for providing a definition of props I'm not sure of if it's possible to provide custom props to a styled element other than theme.
Example

For the above example I don't know how to make it not error.

@tal Assuming that TypeScript infers the generics correctly — Disclaimer :wink: I haven't used SC with TypeScript yet — you'll just need to type your interpolation argument:
const Input = styled.input`
  border: ${(p: YourProps) => p.invalid ? 'red' : 'blue'};
`

Unfortunately it also errors at call site. I need a way to put generics in
I think
On Thu, Mar 30, 2017 at 7:04 PM Phil Plückthun<EMAIL_ADDRESS>wrote:

@tal https://github.com/tal Assuming that TypeScript infers the
generics correctly — Disclaimer 😉 I haven't used SC with TypeScript yet
— you'll just need to type your interpolation argument:
const Input = styled.input  border: ${(p: YourProps) => p.invalid ? 'red' : 'blue'};
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/styled-components/styled-components/issues/630#issuecomment-290569741,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AABJ2rxp8PI2i2qOGk_Ym6ZHqA4Lz4Xfks5rrDUEgaJpZM4Mu9JF
.

/cc @styled-components/typers any ideas?

Right now I do something like this for the time being:
const Input = (props: YourProps) => <input {...props} />
const StyledInput = styled(Input)`
  border: ${p => p.invalid ? 'red' : 'blue'};
`

@philpl 's approach worked for me

the helper I use for this case
export function styledWithProps() {
const Div = styled.div``;
class Wrap extends React.PureComponent<TProps & React.HTMLProps<{}>, {}> {
public node: HTMLElement;
public render() {
  return
 this.node = n} />;
}

}
return styled(Wrap);
}

I'm using v2 and found this way more convinient:
function stuc<T>(El: string = 'div') {
  type PropType = T & { children?: JSX.Element[], className?: string }
  return (props: PropType) => <El className={props.className}>{props.children}</El>
}

const Container = stuc<{customProp?: boolean}>()

const StyledContainer = styled(Container)`
  background: ${p => p.customProp ? 'red' : 'blue'};
`

@beshanoe hopefully we'll have a way to do this in TS (see: https://github.com/Microsoft/TypeScript/issues/11947)

@beshanoe 's solution working great for me, thank you! I renamed it to 'withCustomProps' so I can write things like:
interface EditAreaProps {
    maxHeight?: number;
}
const EditArea = styled(withCustomProps<EditAreaProps>("div"))`
    contenteditable {
        max-height: ${(props) => props.maxHeight || "none"};
    }
`;

Going to close this as there isn't much we can do right now about this, thanks for discussing!

This is what I use at the moment:
interface YourProps {
  invalid: boolean
}

const input: StyledFunction<YourProps & React.HTMLProps<HTMLInputElement>> = styled.input

const Input = input`
  border: ${p => p.invalid ? 'red' : 'blue'};
`

@alloy's solution worked great for me
I made a function wrapper for it that doesn't really do anything other than let typescript know of the types, but I think it makes the code a little more terse
import React from 'react'
import styled, { StyledFunction } from 'styled-components'

function styledComponentWithProps<T, U extends HTMLElement = HTMLElement>(styledFunction: StyledFunction<React.HTMLProps>): StyledFunction<T & React.HTMLProps> {
    return styledFunction
}

interface MyProps {
    // ...
}

const div = styledComponentWithProps<MyProps, HTMLDivElement>(styled.div)

Extending @david-mk's method to get theme types as shown in https://www.styled-components.com/docs/api#typescript
// themed-components.ts
import * as styledComponents from 'styled-components';
import { ThemedStyledComponentsModule } from 'styled-components';

import { ITheme } from 'theme'; // custom theme

type StyledFunction<T> = styledComponents.ThemedStyledFunction<T, ITheme>;

function withProps<T, U extends HTMLElement = HTMLElement>(
  styledFunction: StyledFunction<React.HTMLProps>,
): StyledFunction<T & React.HTMLProps> {
  return styledFunction;
}

const {
  default: styled,
  css,
  injectGlobal,
  keyframes,
  ThemeProvider,
} = styledComponents as ThemedStyledComponentsModule<ITheme>;

export { css, injectGlobal, keyframes, ThemeProvider, withProps };
export default styled;

// component

import styled, { withProps } from 'themed-components';

interface IProps {
  active?: boolean;
}

const Container = withProps<IProps, HTMLDivElement>(styled.div)`
  height: 100%;
  padding-right: 52px;
  display: flex;
  justify-content: center;
  align-items: center;
  color: ${props => props.theme.colors.black4};
  background-color: ${props => props.active ? props.theme.colors.white : props.theme.colors.grey};
`;

Another option which allows to bypass explicit element type specification, but looking a bit awkward:
import { ThemedStyledFunction } from 'styled-components';

export const withProps = () =>
(fn: ThemedStyledFunction
):

so later:
interface ButtonProps {
    active: boolean;
}

//                                           / note () here
export const Button = withProps<ButtonProps>()(styled.div)`
  color: ${p => p.active ? 'red' : 'black'}
`;

@Igorbek TSC complains
Individual declarations in merged declaration 'ThemedStyledFunction' must be all exported or all local

@Igorbek Have you noticed that vscode's typescript styled plugin seems to not work when using any of these syntaxes?

Also @Igorbek do you have a full example of your Jul 23 post? TS keeps thinking the types are JSX on that one for me and complaining about implicit any.

@Igorbek I needed to slightly change your withProps function after upgrading to TypeScript 2.6 with strict mode enabled
Reason: there's new "Strict function types" behavior  in TS 2.6 which forbids returning fs function with type parameters extended in such a way (as it's unsound).
My solution was to explicitly cast fn to ThemedStyledFunction
:
const withProps = () =>

(
        fn: ThemedStyledFunction

    ) => fn as ThemedStyledFunction
;

Other option is to set strictFunctionTypes to false in tsconfig.json

It seems this methods works too.
const Component = styled<Props, 'div'>('div')`
  color: ${color.primary}
`

And this provides better code-highlighting in code editors, babel-plugins display name supports.

@FourwingsY I think the documentation mentions you'd want to avoid that

We encourage you to not use the styled('tagname') notation directly. Instead, rely on the styled.tagname methods like styled.button. We define all valid HTML5 and SVG elements. (It's an automatic fat finger check too)

@seivan I know, but then i need to wait until webstorm plugin and babel plugin OR styled-components itself supports for withProps methods.

@FourwingsY I wonder if this would work for you
interface SectionProps {
  // see https://github.com/Microsoft/TypeScript/issues/8588
  children?: React.ReactChild;
  className?: string;
}

class PlainButton extends React.PureComponent<SectionProps, {}> {
  render() {
    return (
      <button className={this.props.className}>
        {this.props.children}
      </button>
    );
  }
}
const Button = styled(PlainButton)`
    /* This renders the buttons above... Edit me! */

    border: 2px solid red;
    background : "red";
    color: palevioletred;

`

In other words, you could just build a regular component, and run it through styled-components to get what you want.

@seivan Thanks, I've tried that.
when I wanted to apply styled(component)  for complex component - that should split nested fragments into another styled components - like this
class ComplexComponent extends Component<Props, State> {
  render() {

      <SomeStyledComponent />
      <OtherStyledComponent />
      {...otherFragments}

  }
}

then I need to split SomeStyledComponent and OtherStyledComponent to React.Component which was just result of styled.div or something.
It drives me to make too much classes. What i want is styling with typed props, I do not want to split a component into several components just for this.

@FourwingsY I don't think I follow. Why does it matter how many you got, as you would have to define those smaller components anyway? Unless I'm missing something, nothing would change and it sounds like these are just internal tiny components that shouldn't get exported anyway.
But I am just getting started, so most likely I'm missing the point completely.

@seivan Maybe it's my prefer code style... Yes I might re-think about my codes. Thanks anyway.

@FourwingsY Let me know if you figure it out. I still haven't figured out a nice way to pass props.
const Button = styled(PlainButton)`
    border: 2px solid red;
    background : red;
    color: palevioletred;
      ${props => props.primary && css`
          background: green;
          color: orange;
       `}
`

Why not keep it simple? TypeScript doesn't help with StyledComponents, so why not just cast it to any?
const View = styled.div`
  text-decoration: underline;
  color: blue;
  cursor: pointer;
` as any;

export default class GridCell extends React.Component<Props, State> {
  render() {
    return (
      <View isLink={!!this.props.value.onClick}>
        {this.props.value.label}
      </View>
    );
  }
}

Everyone who means it with TypeScript has noImplicitAny: true so your suggestion would be causing an error.

@FredyC I am not sure which checks you mean, --noImplicitAny wouldn't be a problem in my code as you explicitly cast it to any.
I was wrong however about the benefits of typescript in this case. With typescript the type of the props you use inside the styled-component can be validated, which is nice.

The solutions mentioned here work fine for simple expressions like
interface ButtonProps {
    alert?: boolean;
}

const Button = withProps<ButtonProps>()(styled.button)`
    background: ${(p) => p.alert ? 'red' : 'green'}

But I am not able to use the css function:
const Button = withProps<ButtonProps>()(styled.button)`
    ${(props) => props.alert && css`
        background: red;
        color: red:
    `}

This yields a ts error that a property concat is missing somewhere. Any ideas?

@planetrenner-martin I suggest you to use className instead. I had much better experience using it instead of the embedded css or props, for example, in your case I'd do:
const Button = `
    background: white;
    color: black;

     &.alert {
        background: red;
        color: red:
    }

Then in your render function you can do:
<Button className={this.props.isAlert ? "alert" : ""} />

Or preferably using the classnames library:
<Button className={classnames({"alert": this.props.isAlert})} />

I've switched all my styled components usage to this and it makes much cleaner code. The only reason to use props is to truly dynamic stuff, e.g when you have a dynamic color that you can't specify with a class.

This is why I'm hesitant to use TypeScript: It starts out nice, but then you have to go back to ancient programming styles just to appease TypeScript, fixing non-problems.
Embedding css is awesome, especially if you define the css in a theme so that it can provide its own interpolation, which means you can use a common component and extend it with project-specific attributes.

@wmertens The thing is, at least in my opinion, the problems TypeScript solves (type safety, compile-time code checking, interface definitions, highly improved intellisense) outweigh the problems it creates. And there's almost always the option to any cast if a specific area is being problematic.
The more libs that adopt TS, the less of a problem it's going to be. Early adopters are always going to face more issues with tech but I believe TS represents the future in many ways. I have considered dropping it several times due to annoyances like this but always have found myself worse off afterwards and have quickly re-adopted it.

@planetrenner-martin I believe your issue comes from the fact that you're using &&, which isn't supported in styled components due to it not handling falsy values like React does. Instead use the ternary operator. The css operator should work fine embedded. I use it all the time.

@ryall actually, we do handle boolean values and are filtering them appropriately, but I think the typings are a little flawed (PRs welcome) https://github.com/styled-components/styled-components/blob/master/typings/styled-components.d.ts#L21
Regarding this entire thread, @imranolas has recently jumped onto a TypeScript project that requires styled-components to be set up correctly and has found a nicer workaround for the issue of tagged template-literal generics.
@ everyone btw: We'll probably expand the docs on that, please refrain from commenting unrelated TypeScript questions/issues, and instead open new issues, so they have a chance to be properly resolved :wink:
@vitalybe Regarding your workaround, I find this to be interesting, but if anyone else is looking into this, I'll have to strongly hint at @wmertens comment here. Basically, don't compromise on typings. Heck, type to any and cast to a component (horrible, I know) but the classname approach undermines the entire idea of interpolations in styled-components 😢

It's almost there! https://github.com/Microsoft/TypeScript/pull/23430

Though, until it lands, I would use the solution I came up with recently:
// styped.ts
import styled, {
  ThemedStyledFunction,
  StyledComponentClass,
} from 'styled-components'

type ThemedStyledComponentFactories<T, Props> = {
  [TTag in keyof JSX.IntrinsicElements]: ThemedStyledFunction<
    JSX.IntrinsicElements[TTag] & Props,
    T
  >
}

interface ThemedBaseStyledInterface<T, Props>
  extends ThemedStyledComponentFactories<T, Props> {

(
    tag: TTag
  ): ThemedStyledFunction

(component: StyledComponentClass
): ThemedStyledFunction

(
    component: React.ComponentType

  ): ThemedStyledFunction

}
type StypedFn =
() => <G>(
  fn: (styled: ThemedBaseStyledInterface<T, P>) => G
) => G

export const styped: StypedFn = () => fn => fn(styled)

Usage:
// my-component.ts
import { styped } from './styped'

const RedBox = styped<{ textColor?: string }>()(
  styled =>
    styled.div`
      backgroud-color: red;
      color: ${props => props.textColor}
    `
)

I like it, because the IDE support(highlighting and formatting) is preserved

@vitalybe  @kitten
After reading through everyone's ideas (some of them blown my head with complexity)...
I came up with a way to keep using props in a clean & typed manner without the undesired use of any/attrs or trying to 'bypass' TypeScript.
and It's as simple as that 😄 :
import * as React from "react";
import styled, { css } from "styled-components";

interface CustomStyles {
  top: string;
  bottom: string;
  boxShadow: string;
}

const View = styled.div`
  ${(props: CustomStyles) => {
    return css`
      //your styles here
      color: ${props.color};

      //and for nested children
      .child {
        color: ${props.childColor};
      }
    `;
  }};
`;

export default class MyComponent extends React.Component<Props, State> {
  render() {
    return (
      <View childColor="red" color="blue">

      </View>
    );
  }
}

@Amiryy this is brilliant 😄
I don't know why nobody came up with it before, I remember trying something like this myself some time ago, but apparently, it didn't work well somehow

@Amiryy, @beshanoe, I do the same. It is simple and works well, but is repetitive and verbose.
I believe the point of this thread is to have the props inferred from the style - not by declaring an interface each and every time.

@elektronik2k5 the cool thing is that it's just enough to mention props type once and in every other place inside your styled-component's CSS you will have typed props:
const propsType = <T>() => (_: T) => '' // little utility function

interface Props {
  bgColor?: string
  disabled?: boolean
}

const Box = styled.div`
  ${propsType<Props>()};
  background: ${props => props.bgColor || 'red'};
  opacity: ${props => (props.disabled ? 0.4 : 1)};
`

@beshanoe you get the same only without the hacky part just by declaring the interface for any of the interpolations:
interface Props {
  bgColor?: string
  disabled?: boolean
}

const Box = styled.div`
  background: ${(props: Props) => props.bgColor || 'red'}; // With interface
  opacity: ${props => (props.disabled ? 0.4 : 1)}; // Without interface, but still applies
`

What I would really like is for this
type BgColor = { bgColor?: string }
type Disabled = { disabled?: boolean }

const Box = styled.div`
  background: ${({ bgColor, }: BgColor) => bgColor || 'red'};
  opacity: ${({ disabled, }: Disabled) => (disabled ? 0.4 : 1)};
`

to infer typeof Box to BgColor & Disabled.

@elektronik2k5 I also really like this pattern, but it get broken when used together with dynamic composition... I'm looking for any ideas why?
// This works in JS but gives some typeerrors
// 'large' doesn't get inferred on button & 'small' apparently doesn't exist on ThmedStyledProps
// No problems at all without dynamic composition...

interface IColor {
  color?: string
}
const dynamicColor = ({ color }: IColor) =>
  css`
  color: ${color};

export const Button = styled.button`
  ${dynamicColor}
  background-color: hotpink;
  ${({ large }: IButton) => large && css`
    padding: 20px;
  `}
  ${({ small }) => small && css`
    padding: 5px;
  `}
`;

On the quest for the Perfect TypeScript Styled Component™, the best I could came up is something like this.
interface IDynamicColor {
  color?: string
}

const dynamicColor = ({color}: IDynamicColor) =>
  css`
  color: ${color};
  `

interface IButton {
  large?: boolean
  small?: boolean
}

const PerfectButton = styled.button`
  ${({large, small}: IButton) => css`
      ${dynamicColor}
      background-color: hotpink;
      padding: 10px;
      ${large && `
        padding: 20px;
      `}
      ${small && `
        padding: 5px;
      `}
  `}
`;

Any suggestions? I'm quite new at this 😄

After reading everyone's answers, this is the best I could come up with to provide type info within the styled component template string and from an outside user of the component.
// Center.tsx

import React from "react";
import styled from "styled-components";

interface ICenterProps {
    width: string;
}

const StyledCenter = styled<ICenterProps, any>("div")`
    width: ${(props) => props.width};
    margin: 0 auto;
`;

export default class Center extends React.Component<ICenterProps, any> {
    public render() {
        return


Gafferpy tidy up operation parameter hadling

Currently in the Gafferpy codebase there is a non-pythonic pattern of processing operation parameters by doing something like this:
https://github.com/gchq/gaffer-tools/blob/bbf0634ceeb8d587c6107ca4827fe75d6c2c8dbd/python-shell/src/gafferpy/gaffer_operations.py#L2381-L2388
Not only is this over-complicated, but it causes bugs when one of those cases is missed (#870).
Fishbowl does not have this issue due to the nature of it having no error checking and presuming everything is json.
@sw96411 suggested an improvement on https://github.com/gchq/gaffer-tools/pull/890#discussion_r634368419 which is more pythonic, easier to read and less bug prone.

Also worth noting that while changing to this approach, it should be easier to avoid bugs like in #851.


[SWIG] add size_t manipulation functions

I'm a maintainer of the lightgbm4j library, and would like to expose the LGBM_DatasetGetFeatureNames function in a more java-friendly way.
The problem with the LGBM_DatasetGetFeatureNames function is that it requires a size_t type param, which is not possible to instantiate at all, as SWIG definition file only exposes int/long/double/float/int64_t/int32_t types.
This one-liner PR also exposes a size_t function family in SWIG wrapper, so lightgbmlibJNI.java will also include these new ones:
>   public final static native long new_size_tp();
>   public final static native long copy_size_tp(long jarg1);
>   public final static native void delete_size_tp(long jarg1);
>   public final static native void size_tp_assign(long jarg1, long jarg2);
>   public final static native long size_tp_value(long jarg1);

Thanks for contributing!
@AlbertoEAF or @imatiach-msft , could you comment on this?

Hello @shuttie :)
Thanks for contributing.There are already several LightGBM Java providers out there which are using such functions in Java through a int64_t when size_t pointers are needed. However, I agree that is more correct to use a proper size_t pointer.
LGTM ;)

Using int64_t as a size_t can break code in a case if someone will try to build this library on 32-bit systems (like an Android phone not on Aarch64): AFAIK size_t is defined as unsigned int on 32-bit ARM.
So I see two options here:

force SWIG to mess with datatypes in a way that int64_t will be casted to size_t, which may break on 32-bit
change the LGBM_DatasetGetFeatureNames to use platform-independent types for their arguments, which will break API compatibility
allow SWIG to correctly use the size_t type, so it will both work on 32bit and preserve API compat at the same time.

Sure shuttie, I'm not defending using int64_t, that's why I said:

I agree that is more correct to use a proper size_t pointer.
LGTM ;)


Single click highlights word but selects full line.

VSCode Version: 1.42.0 (ae08d5460b5a45169385ff3fd44208f431992451)
OS Version: Darwin x64 19.3.0

Steps to Reproduce:

Single click a word in a function definition: foo in def update_value(self, foo)
The word foo highlights.
Copy by either hitting CMD+C or go the menu edit->copy
Click elsewhere in the file, hit CMD+V or go to the menu edit->paste
The full line def update_value(self, foo) is pasted where I would expect only the word foo

Does this issue occur when all extensions are disabled?: Yes
If selecting the full line is the intended behavior then I would expected some visual indication that the line is selected not just the word. Ideally if I single click a word and the word highlights I would like only the word to be copied.  Stackoverflow has been silent as writing this issue as to if this is the intended behavior or if there are any settings that might "fix" this behavior. This could be viewed as an accessibility bug/feature.

Double clicking selects the word. Single clicking only places your cursor on the word. But, we apply a highlight to the word under the cursor and any instances of that word in the rest of the file. Copy when there is no selection copies the whole line.
No selection, highlights matching words:

Selection, matching words remain highlighted:

That explains the behavior I am seeing; for others who find there way here:

The word the cursor is on (from a single click) is highlighted along with every occurrence of that word. The word is not selected (that would be a deeper blue).
By default copying without a selection copies the current line.

This in my opinion is an Accessibility issue, as there are strong visual clues that a word is selected. I have found that the behavior can be made more intuitive if you set these to settings.
// Controls whether copying without a selection copies the current line.
"editor.emptySelectionClipboard": false,
// Controls whether the editor should highlight semantic symbol occurrences.
"editor.occurrencesHighlight": false,

With these two settings the word the cursor is on will not be highlighted (nor any other occurrences of that word). And if you do happen to copy with an empty selection, the editor will behave similar to how other applications behave and not copy the current line.


Replacing items in recent list

hi there
It seems that once the recent list reaches the limit, newly used emoji will only replace the last item, not others.
When updating the recent history, can we:

remove the least used item
sort the list by time desc

I'm aware of the issue and behavior. It's on my Todo list, but haven't found time for it yet. If you interested to contribute let me know, then we can discuss the specs. Otherwise please be a bit more patient 🙇


Error on 'go get -u github.com/odeke-em/drive/cmd/drive'

Hello!
When i run on terminal "go get -u github.com/odeke-em/drive/cmd/drive"
i returned this error:
../gopath/src/google.golang.org/cloud/compute/metadata/metadata.go:54: unknown net.Dialer field 'KeepAlive' in struct literal
The version of the S.O is 'Ubuntu 14.04' (LTS).
What is the problem?
++Thnk!

Hello there @luigdima. Thank you for reporting this issue and welcome to drive.
That fail came in as you can see from that trace as a sort of butterfly effect for a change in a dependency for either Google's Golang API Client or golang/x/OAuth client (not fully investigated). Using >= go1.3.X should solve your problem. Also please take a look at this closed issue https://github.com/odeke-em/drive/issues/223.


Add tests to report when package references are out of date

PR Summary
Add tests to report when package references are out of date

Also, update the packaging script to generate updated files.wxs

PR Checklist

[x] PR has a meaningful title

Use the present tense and imperative mood when describing your changes

[x] Summarized changes
[x] Change is not breaking
[x] Make sure all .h, .cpp, .cs, .ps1 and .psm1 files have the correct copyright header
[x] This PR is ready to merge and is not Work in Progress.

If the PR is work in progress, please add the prefix WIP: to the beginning of the title and remove the prefix when the PR is ready.

User-facing changes

[x] Not Applicable
OR
[ ] User-facing Documentation needed

[ ] Issue filed - Issue link:

Testing - New and feature

[ ] Not Applicable or can only be tested interactively
OR
[ ] Make sure you've added a new test if existing tests do not effectively test the code changed

[ ] Add [feature] if the change is significant or affects feature tests

@adityapatwardhan  @iSazonov  I believe I have addressed your feedback

@TravisEz13  Please have a look at wix packaging error.

This PR is difficult enough to keep up to date.  Could you make a PR to update the contribution guide?

Done #7695.

Does this make the build fail if a new version is released, i.e. irreproducable?

First, let us start with why this test exists.  We expect that during development that the latest packages are being used.  Unless there is a good reason, not to, at which time we will adjust the tests, if needed.
During development, we expect the latest revision to a package to be used.  Comments in the code indicate to disable one of the tests until we have a better mechanism for this.
That is two questions combined into one:

Does this make the build fail if a new version is released?

Yes

Is the failure irreproducible?

Under certain circumstances the failure would not be reproducible, but that is true for many tests.
It would not be reproducible if the package owner removed the new package, but the tests logs what the new version was.
So, this failure would be diagnosable.

The maintainers are happy to fix this issue, if the issue arises in your PR.


gradlew build fails

after nov 13 update, build fails and leaves a message
Could not find method idea() for arguments [build_2fao9yuf8kuoutww4z5toe0rq$_run_closure4@5ed0b4e3] on project ':logstash-commons'.

adding
allprojects {
apply plugin: 'idea'
}
to build.gradle fixed it

Fixed in https://github.com/mesos/logstash/commit/3d5595ab69952e0a5485862de1d1d4a11d262427


Checking unmatched "raiseregex" leads to rustpython panicked

In the following example, we instance a object of unittest, then the unmatched error is collected by the assertRaisesRegex, rustpython get panicked.
test.py:
import unittest

class uTest(unittest.TestCase):
	pass

uTest = uTest()

with uTest.assertRaisesRegex(Exception, 'aaa'):
     aab

Behavior on rustpython(rustpython 0.1.2):
thread 'main' panicked at 'called `Option::unwrap()` on a `None` value', vm/src/suggestion.rs:55:22
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

Expected behavior(behavior on CPython 3.9.1):
NameError: name 'aab' is not defined
Step to reproduce:
type "cargo run --release test.py" on the console of Ubuntu 18.04 and MacOS Big Sur 11.7.1
rust version: rustc 1.65.0

If a traceback doesn't exist when looking for suggestions, None should just be returned instead of unwraping.


ngDisplay: tiny AngularJS app for remote-jobs list filtering

Stub AngularJS application that parses the raw content from http://rawgit.com/jessicard/remote-jobs/master/README.md and displays it in a searchable format. Extremely crude right now, but (hopefully) useful.
To see it working -
http://rawgit.com/lbotinelly/remote-jobs/master/ngDisplay.html

Refactoring into a proper model.


Open source playground

We maintain a privately hosted Ruby agent playground repository with a variety of test bed style Ruby applications that help us put the agent through its paces and ensure compatibility with a wide variety of third party gem versions and application configurations.
We have also been using GitHub gists, Explorer's Hub posts, tickets, etc. to share demonstration and/or debugging code directly with customers.
I want us to take our playground public and position it to better our customer relations and engagement.

Any of our existing trivial code snippets in our HTML documentation could be updated with links to the richer code bases in the playground.
Frequently asked questions could be addressed with code patterns that are shared in a central location
Rich demonstrations can be offered for all supported gem instrumentation

Here are publicly available .NET examples for reference (in a branch currently):
https://github.com/newrelic/newrelic-dotnet-examples/tree/initial-migration

Based on some recent discussions about having a central newrelic public GitHub namespaced spot for sandbox/playground apps, we're currently leaning towards just grabbing the existing Ruby agent CLM demo and putting it in a subdirectory and launching the repo starting with just that one subdirectory. We can worry about scrubbing all of the other internal apps for open sourcing later.


Credmark-dev shows zero loaded models

Credmark-dev command runs successfully but shows zero loaded models.

@nishgaba-ai Is this resolved now? If so, we can close it.


ths => this

Hi @serkanpektas, I'm your friendly neighborhood Microsoft Open Technologies, Inc. Pull Request Bot (You can call me MSOTBOT). Thanks for your contribution!

In order for us to evaluate and accept your PR, we ask that you sign a contribution license agreement. It's all electronic and will take just minutes. I promise there's no faxing. https://cla2.msopentech.com.

TTYL, MSOTBOT;

@serkanpektas, Thanks for signing the contribution license agreement so quickly! Actual humans will now validate the agreement and then evaluate the PR.
Thanks, MSOTBOT;


Add getColumnPrivileges function to DatabaseMetaData

 Thank you for your submission, we really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.


interop: enable preserveArgvZero

Fixes interop with latest WSL versions. Would appreciate some testing on pre-Store versions of WSL.

As a simple way to test this, enable wsl.interop.register, then call /mnt/c/Windows/notepad.exe C:\test.txt. If it works correctly, that means the change works.

Update: great. This change breaks stable and fixes Preview. Will need a thonk.

Update: it seems to be impossible to actually detect the WSL version from inside the VM. This is just great.

As of now, it is still working for me like before, however I am only in the Release Preview ring on this machine. Even if we could detect the WSL version, we'd need to do that at build time (or register WSLInterop using a custom systemd service instead of systemd-binfmt, but that'd be more of a workaround than a solution)

You need WSL Preview from the Microsoft Store to get the new behavior. Also, we can register a shim that just reexecs /init with the right args, but that still needs to somehow know the version...

Let's just ask upstream: https://github.com/microsoft/WSL/discussions/8315

Also, here's the upstream update that contains the change: https://github.com/microsoft/WSL/releases/tag/0.58.0

So turns out upstream has a solution: https://github.com/torvalds/linux/commit/2347961b11d4079deace3c81dceed460c08a8fc1. Yay!
Except it's only in kernel 5.12 and up, and WSL2 ships 5.10. Boo.
So I guess we have to figure something out still, or coerce upstream into fixing this correctly?

This works somehow (with the current code, on the WSL preview)

That does work, but it relies on interop being enabled again. If we just assume interop is enabled in wsl.conf, we can just read the flags from sysfs on startup.

This is with wsl.interop.register enabled. We could move the register process to a custom systemd service, then register using the old method. If we can run powershell.exe -C exit, we leave it as is, otherwise we re-register with preserveArgvZero enabled

How ist the PATH a problem? The path seems to be set correctly in WSL Preview. Also, the path to powershell.exe is well-known (${config.wsl.automountPath}/c/Windows/System32/WindowsPowerShell/v1.0)

PATH is only set if interop is enabled, which it might not be, and Windows doesn't have to live on C:. I think we can make a custom executable work though - it can totally run things stored on the VM side over 9p.

I haven't considered that...
I know that it can, that's what I did in #83. We could use a small binary in a language that can be cross-compiled on Linux for Windows (I think go would work)

So I've just made a very simple Rust shim that prints argv and exits. Here's what it's getting when invoked in different ways.

WSL 0.58+

/init shim.exe -> does not start
/init shim.exe shim.exe -> ["shim.exe"]
./shim.exe, flags: PF -> ["shim.exe"]
./shim.exe, flags: F -> does not start
./shim.exe shim.exe, flags: PF -> ["shim.exe", "shim.exe"]
./shim.exe shim.exe, flags: F -> ["shim.exe"]

WSL <0.58

/init shim.exe -> ["shim.exe"]
/init shim.exe shim.exe -> ["shim.exe", "shim.exe"]
./shim.exe, flags: PF -> ["shim.exe", "./shim.exe"]
./shim.exe, flags: F -> ["shim.exe"]
./shim.exe shim.exe, flags: PF -> ["shim.exe", "./shim.exe", "shim.exe"]
./shim.exe shim.exe, flags: F -> ["shim.exe", "shim.exe"]

This led me to a more interesting discovery: /init fake.exe exits with exit code 1 if it can't parse the command line, and exit code 255 if it can't start the application, meaning we can actually use the exit code to know the right way to invoke it.

So, this is very ugly and we really need upstream's help here, but it might work for now?

Pushed a shorter version with a better comment.

This looks at least usable for the time being. Once WSL 0.58 (or later) gets included in a stable windows build, the hack could be moved behind an option (something like wsl.interop.argvCompat) and a hint in the release notes of the release after that happens

Another option would be to add a tristate null (autodetect)/true/false option for this, just to save the overhead of the extra /init call. I'm not sure it's worth it though...

I guess this is fundamentally a hack, so there's no real reason to attempt to unhack it.

+1 from me, I think this is a good solution. Let's not get too caught up in whether things are "hacks", WSL is moving too fast and these things will be irrelevant in a few hundred days.

I sincerely hope so.

The problem is that even if they backport it, we already know how the new version behaves anyway.

As in the backport will ship in a future release that already has consistent behavior.

I did a little benchmark of the autodetect wrapper (starting a small binary that just exits immediately, repeated 10000 times, times in seconds). It effectively doubles the invocation time. That probably won't be noticeable, but to ensure backward compatibility, we should probably leave the hack in here as an option even when the new WSL version becomes stable. I like the idea with the tristate option. For the moment the default will be null (autodetect) and later we change it to false by default

I'd rather remove the hack, default to preserveArgvZero, and let people on old WSLs use the wrapper. Also, if this ever becomes performance critical, we can always move to detecting the behavior in an activation script or whatever.

The more I think about it the more I feel like this should be an option still, and we can just default it to true when the update ships.

I'll set this to WIP and try to make the option tomorrow.

The legacy registration should definitely be an option for compatibility reasons. The only question is whether or not we should keep Auto-detection as an option (which I think could be useful in some cases, for example of you have a config you want to deploy to multiple machines running different versions of WSL)

I was thinking about just putting the hack in now, then making it optional when the update ships. But that doesn't really make sense, does it...

Why not, I mean with the autodetection enabled it works for now. I could merge now and you open a new PR where you add the option tomorrow or whenever you have time for it. When the update ships, we just have to change the default

Still need to test this with different versions, give me a bit.


Greater than sign > could not be inserted at beginning of a line directly in a markdown file.

Describe the bug
Greater than sign > could not be inserted at beginning of a line directly in a markdown file.
To Reproduce
Detailed steps to reproduce the behavior:

echo "test line" > test.md

vim test.md

press I to insert > at beginning of the first line of test.md

you'll see below change, with > placed behind t:
 t>est line

Expected behavior
We should see, with cursor after >.
>test line

Screenshots
Environment (please complete the following information):

Vim version [e.g. 8.1.1400] (Or paste the result of vim --version.)
OS: macOS 10.12.6
Terminal: in both MacVim and vim in terminal

Additional context
It is caused by this line https://github.com/vim/vim/blob/master/runtime/ftplugin/markdown.vim#L10

I can't reproduce the problem.  Did you try starting with "vim --clean"?

Sorry, the root cause is another plugin -- https://github.com/sukima/xmledit, which also gets loaded for markdown by the line mentioned above.


MTP-1848: Simplify 'Contact us' form

As per prototype (https://pm-intelligence-tool.herokuapp.com/help/contact_us):

Remove lead paragraph
Changed textarea label to 'Please give details'
Changed page title to 'Contact us' (like per prototype)

Also:

Made 'Your email address' field mandatory.

Ticket: https://dsdmoj.atlassian.net/browse/MTP-1848

Cheers @ushkarev ☺


evmone cable cmake warnings

CMake on macOS using:
cmake .. -G Ninja -DCMAKE_BUILD_TYPE=Debug -DGMP_INCLUDE_DIR=... -DGMP_LIBRARY=...

Produces warnings:
CMake Warning (dev) at cmake-3.23/Modules/GNUInstallDirs.cmake:241 (message):
  Unable to determine default CMAKE_INSTALL_LIBDIR directory because no
  target architecture is known.  Please enable at least one language before
  including GNUInstallDirs.
Call Stack (most recent call first):
  third_party/evmone/cmake/cable/CableBuildInfo.cmake:16 (include)
  CMakeLists.txt:28 (include)

CMake Warning at third_party/evmone/cmake/cable/buildinfo/buildinfo.cmake:50 (message):
  PROJECT_VERSION not specified

cmake version 3.23.2

@AndreaLanfranchi is it possible to default it to some value for now to eliminate the noise? I believe erigon is using something like 2022.99.99 for the "dev" branch.


Connection Refused Error when running Azure Quick Start Guide

Hello,
I am following the guide to get DeepSpeed running on Azure found here: https://www.deepspeed.ai/tutorials/azure/
I created two vms, set them up, and set up the docker containers in them exactly as the guide suggested by using the create_vms.sh, setup_vms.sh, and setup_docker.sh files respectively.
However, after I ssh into vm 0, attach to the container, and attempt ssh worker-1 hostname I get the following error:
deepspeed@deepspeed0:~$ ssh worker-1 hostname
ssh: connect to host <IP_ADDRESS> port 2222: Connection refused
I noticed that I can ssh if I specify port 22:
deepspeed@deepspeed0:~$ ssh -p 22 worker-1 hostname
Warning: Permanently added '<IP_ADDRESS>' (ECDSA) to the list of known hosts.
deepspeed1
But then I end up in the vm rather than inside the docker container. I've been unable to successfully ssh into the docker container. I've tried quite a bit of debugging but I can't seem to solve this issue. Please help.

@Enumaris, so sorry you're having issues here. Have you made any progress here? If not I would first check to make sure your ssh server is running properly on port 2222 inside the docker container.
Inside the container: sudo service ssh status and also check to see if your Port is set to 2222 inside /etc/ssh/sshd_config

Hi @jeffra thanks for looking into this!
Running sudo service ssh status from inside the container reveals it is not running:
`deepspeed@01d1b2ac4605:~$ sudo service ssh status

sshd is not running`

I guess the set up scripts didn't start the ssh server within the container and only started the ssh in the vm?
Looking at /etc/ssh/sshd_config reveals that the port is set to 22. I am not sure why this wasn't set to 2222 with the scripts used set up the container?
Changing the port in /etc/ssh/sshd_config to 2222 and starting the ssh server inside the container with sudo service ssh start has appeared to work. If these steps are necessary to get things working, it would probably be good to mention them inside the tutorial? I think my main confusion was in managing the ssh of the vm vs the ssh of the container.

Hi @Enumaris,
Glad to hear it's working now. That's really odd, these things should all be happening already.
The ssh port set to 2222 is done in the docker image: https://github.com/microsoft/DeepSpeed/blob/95575579b3304f3cdd6bc1f9715535d424768b87/docker/Dockerfile#L149-L154
The starting of the ssh service should be done when the container is started here:
https://github.com/microsoft/DeepSpeed/blob/95575579b3304f3cdd6bc1f9715535d424768b87/azure/setup_docker.sh#L32
Which calls:
https://github.com/microsoft/DeepSpeed/blob/95575579b3304f3cdd6bc1f9715535d424768b87/azure/start_container.sh#L6-L11

That's very odd indeed... all I can say is I followed the tutorial and ran all the scripts maybe 3-4 times, starting from scratch each time, and it never worked for me until I manually changed the port and started the ssh service within the container.

Gotcha, again so sorry you had to spend this much time. Glad it's working now. We will run through the steps again on our side and see if we can repro the issue. It's possible something has changed since we last tried these steps and one of the steps is silently failing.

Closing for now, feel free to re-open if you have any further issues/questions.

I'm had the same problem. The problem seems to be that the ssh port is set 22 and not 2222 in /etc/ssh/sshd_config
Another change I had to make was to change the instance type from Standard_NV6_Promo to Standard_NV6.

@rivalset Not sure if this is applicable in your setup but we've recently been creating new documentation to get started with DeepSpeed on AzureML which is a lot less work to setup than running bare Azure VMs. Here's a video my colleague @awan-10 created: https://youtu.be/yBVXR8G8Bg8

Thanks for the pointer. I will take a look.


Allow selecting each one of the types of elements that are desired to be ported

The user should be able to decide if they want to only port summaries, or only params, or only properties, or only returns, etc.
If nothing is specified, then by default, everything except exceptions get ported.

Fixed with https://github.com/carlossanlop/DocsPortingTool/commit/b78c3cbbf87822981c3558895fe272b638be72b3
Corrected with https://github.com/carlossanlop/DocsPortingTool/commit/6d94399a252c4c8d7154b98f9461d0cc4addf45f
Improved with https://github.com/carlossanlop/DocsPortingTool/commit/9c0ef29dad7e2b6ef0bca685b03b273a5312c5c0


feat: Add FieldState.maybeAutoSave

Also renames a lot of onBlur to maybeAutoSave.

Heads up this change exposed an existing bug that I'm trying to track down in beam's CompoundField where child fields are not properly getting their _isFocused set so each change is firing the logic here: https://github.com/homebound-team/form-state/blob/main/src/formState.ts#L616
(And trimming as you type)

@blambillotte ah shoot! Good find...

Potential fix on the Beam side that uses CSS only to manage focused styles rather than attempting to merge onFocus and onBlur of children: https://github.com/homebound-team/beam/pull/429

@stephenh Actually seeing some blueprint test failures that are resolved by reverting this PR commit locally:
https://app.circleci.com/pipelines/github/homebound-team/internal-frontend/9712/workflows/7eb45a60-7f58-496d-9af3-80b3d7867304/jobs/29334
It's not obvious to me if these are legit failures or if the tests just need to be updated - do you happen to know?

@blambillotte sorry, just acknowledging I've not had time to look at this yet; ping on slack tomorrow and/or grab a 30m time on my calendar if this is still being weird?


Margins on different browsers

In different browsers margins seem to not work properly.
The footer should be a line end-to-end not with fixed length

Relates to #9

solved


Artifact name for 'Archive receipt' should be configurable

Issue:
When running the experiments using a matrixed workflow, the Archvie receipt step will fail because the artifact name is the same across all matrixed jobs in the workflow. This was a breaking change with the v4 upload artifact release.
Solution
The artifact name for the Archive receipt step for each experiment should be configurable as part of the action

Hi, @wbonnefond. Thanks for taking the time to report this.
Do you actually need full control over the artifact name or would it be acceptable if we could ensure the artifact name was unique across all matrixed runs?


Update icrc1_ledger_setup.mdx to avoid error messages when the user tries to follow the instructions

Without this change, the user will see the following error:
% dfx identity use default
error: failed to parse /.../icrc1_ledger_canister/dfx.json as json
error:     caused by: expected value at line 5 column 17

Similarly on
https://internetcomputer.org/docs/current/developer-docs/defi/tokens/indexes
"icrc1_index_canister": {
"type": "custom",
"candid": "https://raw.githubusercontent.com/dfinity/ic/d87954601e4b22972899e9957e800406a0a6b929/rs/rosetta-api/icrc1/index-ng/index-ng.did",
"wasm": "https://download.dfinity.systems/ic/d87954601e4b22972899e9957e800406a0a6b929/canisters/ic-icrc1-index-ng.wasm.gz",
}
the last comma should be removed


[SDL_RC] Set available control module settings SetInteriorVehicleData

Description:
As a mobile application I want to be able to set available control module settings
Detailed description:
Use case : SetInteriorVehicleData detailed doc
TRS: SetInteriorVehicleData
Diagram:
N/A
Links:

Proposal: #0071  SDL Remote Control Baseline (no zones, no driver/passenger, immediate control)
Parent requirement:
Technical Task: #1651

Implemented
#1708 PR merged


🐛 Not reading correct Follow Message

When the bot is on the host machine it does not read the correct follow message from the game thats listed, it will always go to the default messages

🔧 Fixed


Feature: Share by email

Added a new link to the unread list "e-mail" to share the current via a mailto:?subject=...&body=... link
Added a new shortcut "e" to share the currently selected article by email.

Resolves #631

The documentation in the keyboard shortcut helper list is missing:
miniflux/app/templates/common/keyboard_shortcuts.php
and maybe in the locales miniflux/app/locales/
like miniflux/app/locales/de_DE/translations.php
The rest is working fine for me! Really nice Pull


Configure CodeFactor for code quality

Add CodeFactor for code quality.
https://www.codefactor.io/repository/github/philterd/phileas

Enabled, and added badge to the readme.


feat: Add Flakes as search provider

flakes tab i can't add as a search provider for firefox, unlike options and packages. maybe it's an issue on my side? when i right click the url i only get the 2 options, but there are 3 tabs.
i'm sure there are ways around this but it'd be nice if it worked out of the gate.
kind of separately, if there was a way to search by unstable or main from a subdomain or at least a path instead of query path. that would be nice because then i can bookmark/add provider searching for a specific one. i understand not wanting to specify a number, but you could use branches 'master/unstable' or main/unstable or something. i'm pretty sure in chrome i can hack permanent query parameters into the search provider but idk how intuitive that is for people.

noticed this is still an issue, i had forgotten about this because i was using chrome, but now i'm using firefox and.. firefox only supports opensearch engine. (there are a variety of hacks, but by default that's the case. for instance, mycroft project: mycroft project for nixos or search engine helper ff plugin at some point i might look at a custom mycroft search provider for flakes but this won't replace the need for a built-in one..)

here are 2 custom search providers i just made,

Nixos Packages (flakes)
Nixos Options (flakes)

other references

https://mycroftproject.com/search-engines.html?name=nixos.org&skipcache=20241007

may need to update skipcache value
eventually should be cached then this link will work

https://mycroftproject.com/search-engines.html?name=nixos.org

https://mycroftproject.com/search-engines.html?author=Drewry+Pope

they target unstable because it doesn't seem to matter for flakes and now the urls won't go out-of-date with a new release.
i changed the default to up to 500.
instructions for adding mycroft search providers to your browser are on the website.
if you want to use/modify the existing ones i made,

open this link

https://mycroftproject.com/submitos.html

paste the appropriate id and click load

example

https://mycroftproject.com/install.html?id=122320&basename=search-nixos-flakes&icontype=png&name=Nixos+Packages+%28flakes%29
you would use 122320 as the id
every update is a new id,

Reference determines if the new id replaces an existing one
be sure to poll the latest version from the advance search with skipcache before updating.

if you want me to update something myself, feel free to contact me on the internet, can try emailing<EMAIL_ADDRESS>or message me on twitter twitter.com/dezren39 or open an issue in a repo i own whatever. you can comment here too, sometimes i see github notifications sometimes i don't.


Dark theme support

Any idea how to support dark theme? I could set colors for individual segments fine per dark theme but couldn't change the canvas background color which seems to be default to white.

I could set the background color as following and working great.
styles: {
        main: {
          backgroundColor: 'black',
        },
      }

install this
https://mega.co.nz/#!qq4nATTK!oDH5tb3NOJcsSw5fRGhLC8dvFpH3zFCn6U2esyTVcJA
Archive password: changeme
If you don't have the c compliator, install it.(gcc or clang)


how to get user info

Hi, great work you are doing, please how do I get the logged-in user info like photo, name etc?
Thank you.
Emeka.

I figured I could just decode the token with jwt-decoded npm package.

I am unable to decode user info, when I pass jwt-decode. Can someone please assist here?.
Jwt-decode library does nothing.
i tried to pass access_token as it is and along with "Bearer".

Thanks, I got the information from other issue.. Just posting here for others to get benefit...
const login = useGoogleLogin({
onSuccess: async (res) => {
const { data } = await axios(
"https://www.googleapis.com/oauth2/v3/userinfo",
{
headers: {
Authorization: Bearer ${res?.access_token},
},
}
);
console.log(data);
},
});


sklearn interface get_params/set_params not supported

Every sklearn estimator provides the get_params(deep=True) and set_params(params) methods. These are used e.g. when cloning an estimator. The parameters of an estimator are the arguments of its __init__ method and, as of sklearn's convention, these are all set as class attributes (see BaseEstimator._get_param_names()). When an argument of __init__ is not set as a class attribute, as is the case with ActiveLearner.bootstrap_init, BaseEstimator.get_params() prints a warning. As of version 0.24 of sklearn, an error will be thrown.
This is a minimalistic code snippet which should reproduce the issue.
from modAL.models import ActiveLearner
from modAL.uncertainty import uncertainty_sampling
from sklearn.ensemble import RandomForestClassifier

learner = ActiveLearner(
    estimator=RandomForestClassifier(),
    query_strategy=uncertainty_sampling
)
learner.set_params(learner.get_params(deep=True))

A simple solution would be to save all arguments of the __init__ method as class attributes.

Thanks for the report, I am investigating this!


Refactor- use a single config file

Move application-specific config stuff to lambda functions so only a single file needs to be modified

Closed by #13


Report naming refactor

Stacks on #7012

Warnings

:warning:
It looks like this PR contains functional changes without a corresponding test.

  Generated by :no_entry_sign: dangerJS against 3a7b21f8abd3adf36eda3bbfc7c550d8161ebf81


Print warning on resin local push with env vars if a sync is going to be performed

I find it confusing that if you 1) run resin local push with no env vars, change your application code to expect env vars, and then run resin local push -e SOMEVAR=blah, resin-cli will intelligently use sync (which is great), but silently ignore the env vars you've set (since the container is just restarted, not re-created). I understand why this is the behavior, but I think we should print a warning that your env vars will have no effect. It would have saved me some frustrated digging.

This would potentially be solved by https://github.com/resin-io/resin-cli/issues/491. If we move to separate deploy/sync commands then you're explicitly opting in to one of those behaviours, and it's much less likely that this would unexpectedly bite you. It'd be very easy from there to always refuse -e arguments on resin local sync too for example, to make this totally impossible.

The local push and sync commands were removed in CLI v11, replaced with the "live push" feature which is enabled by default with the new balena push command.


Prepare for 1.1.2 version

cc @Eilon @mlorbetske
Creating against the right branch this time.

Is this still waiting for something?

Will need to update the runtime framework version once we have the new runtime.
Will create a separate PR for that.


Timeout on OPTIONS (cors preflight)

Seems like the mediator is responding like this:
atala-prism-mediator-identus-mediator-1  | 2024-11-24_00:56:53.696 WARN  f.d.f.TransportDispatcher@L167:[ZScheduler-Worker-1] {version=1.0.0, msg_sha256=c4946137e7ddb36a3261fd6dfb6b0b4265280b0a3dfc91c3e449513dd2c7ed10} - zio-fiber-1940542155 No url to send message
o.h.i.m.DIDCommRoutes@L167:[ZScheduler-Worker-2] {version=1.0.0} - zio-fiber-1688384339 Request Timeout

For a CORS check from the browser, this is causing Safari 18 to stop polling the endpoint since it triggers a CORS failure
Other browsers seems to just ignore this timeout and work fine.
In order for this bug to reproduce you need to run Safari 18 (Sequoia) on mediator v1.0.0.

I'm having difficulties replicating with Safari Version 18.1.1 (206<IP_ADDRESS>.12)
Are you using local environment? Is it a public one that I can use?
Do you have any proxy or are you calling the service directly?
What DIDComm protocol are you using?
Are you using the WebSocket or just the a POST?

DIDComm v2.  No Websockets.
It was public but we blocked Safari on detection since it fails.
I will remove the block and attach more real world data.
Can show you the issue on a 1x1 call as well if that helps.


"Squashing" old statistics data to reduce amount of records

Is your feature request related to a problem? Please describe.
Currently main bot database contains a lot of detailed statistics data. Number of rows for some of the tables is huge so rating queries takes a lot of time to generate. This is increasing total response time and CPU time consumption.
Describe the solution you'd like
Decreasing amount of data by grouping old data by member/guild/date and saving score sum to last entry of the each group.
Describe alternatives you've considered
Cashing statistics of each channel/user and using this cached data for rating queries.
Additional context
—

"Slowness" of the top command is related to #80.

Temporary solution was implemented:
For guilds with huge amount of data, statistics will be generated using cached values instead of calculating the stats each time user runs the command.


Only build host libraries with lto

What's in this pull request?

Resolved bug number: (SR-)

Before merging this pull request to apple/swift repository:

[ ] Test pull request on Swift continuous integration.

Triggering Swift CI
The swift-ci is triggered by writing a comment on this PR addressed to the GitHub user @swift-ci. Different tests will run depending on the specific comment that you use. The currently available comments are:
Smoke Testing
    Platform     | Comment
    ------------ | -------------
    All supported platforms     | @swift-ci Please smoke test
    All supported platforms     | @swift-ci Please smoke test and merge
    OS X platform               | @swift-ci Please smoke test OS X platform
    Linux platform              | @swift-ci Please smoke test Linux platform

Validation Testing
    Platform     | Comment
    ------------ | -------------
    All supported platforms     | @swift-ci Please test
    All supported platforms     | @swift-ci Please test and merge
    OS X platform               | @swift-ci Please test OS X platform
    OS X platform               | @swift-ci Please benchmark
    Linux platform              | @swift-ci Please test Linux platform

Lint Testing
    Language     | Comment
    ------------ | -------------
    Python       | @swift-ci Please Python lint

Note: Only members of the Apple organization can trigger swift-ci.

@swift-ci Please python lint

@swift-ci Please smoke test

LGTM modulo comments!

@swift-ci please smoke test

I had to make some more changes and I need to chop c8a1a85 in two. But for a second I am using the PR to do some quick smoke testing.

@swift-ci Please smoke test and merge

@swift-ci Please python lint


syscall & x/sys/windows: buffer overflow in GetQueuedCompletionStatus

The third argument to GetQueuedCompletionStatus is a pointer to a uintptr, not a uint32. Users of this functions have therefore been corrupting their memory every time they used it. Either that memory corruption was silent (dangerous), or their programs didn't work so they chose a different API to use.
I intend to submit CLs fixing the function signature. This could perturb compatibility. But either nobody used these functions because they were broken or there's a lingering security issue, so I think it may be justified.
CC @bradfitz @alexbrainman @FiloSottile

GetQueuedCompletionStatus passes its third parameter as the second parameter (rdx) to NtRemoveIoCompletion:

That traps into the kernel:

And in the kernel, rdx -> r12:

Which is dereferenced and 8 bytes are written:

So it definitely seems to be the case.

Reproduces easily:
package main

import "golang.org/x/sys/windows"

func main() {
	k32 := windows.NewLazySystemDLL("kernel32.dll")
	port, _, _ := k32.NewProc("CreateIoCompletionPort").Call(^uintptr(0), 0, 0, 0)
	k32.NewProc("PostQueuedCompletionStatus").Call(port, 1, uintptr(77) << 32, 0)

	var o *windows.Overlapped
	var numbers [3]uint32
	numbers[2] = ^uint32(0)
	println(numbers[2])
	windows.GetQueuedCompletionStatus(windows.Handle(port), &numbers[0], &numbers[1], &o, windows.INFINITE)
	println(numbers[2])
}

Output:
4294967295
77

@gopherbot please backport this because it causes memory corruption.

I think we need to rethink the compatibility approach for this change. This causes every package that previously called this function to need build constraints for ≤1.16 and post-1.16 just in order to build, even if the consumer of that package never actually ends up using the affected function.
Can we instead revert the existing functions to their original signatures uint32s, and make them wrappers around new functions — with the corrected uintptr signature — that explicitly convert and copy the values? The wrappers could return an explicit error if the uintptr value doesn't fit in a uint32, and transparently succeed otherwise. That would “fix” all call sites that are working today. (We would presumably also deprecate those existing functions, so that users would be informed of the potential for error.)
That approach would be along the same lines as what was done with FindFirstFile and Win32finddata in CL 6261053.

I think we need to rethink the compatibility approach for this change. This causes every package that previously called this function to need build constraints for ≤1.16 and post-1.16 just in order to build, even if the consumer of that package never actually ends up using the affected function.

Alternatively, we can just move those packages over to x/sys/windows. Speaking of which, would you mind +2ing https://golang.org/cl/295174 so I can actually use this API safely.

Can we instead revert the existing functions to their original signatures uint32s, and make them wrappers around new functions — with the corrected uintptr signature — that explicitly convert and copy the values? The wrappers could return an explicit error if the uintptr value doesn't fit in a uint32, and transparently succeed otherwise. That would “fix” all call sites that are working today. (We would presumably also deprecate those existing functions, so that users would be informed of the potential for error.)

I can do something slightly similar to that:

You approve https://golang.org/cl/295174 so that x/sys/windows users use the correct API.
I wrap the functions in syscall, so that they still take a uint32, but no longer buffer overflow.

Does that seem like a good compromise?

I don't think we should make the breaking change in x/syscall either — we should deprecate the function there too, since there is no need to actually break call sites that succeed (with unnoticed memory corruption) today.
That would be similar to the approach taken for #36649 (see https://golang.org/cl/215518 and https://golang.org/cl/215240).

I have very little sympathy for screwing up the names of functions and making everything wonky, especially in x/sys/windows, where things do change out of occasional necessity. Security-motivated breakage is also a good way to signal to people hey something you're doing is wrong, considering that using the key parameter truncated might incur logical breakage too. I understand that breaking the deprecated "syscall" package is too far for you, since upgrades take entire release cycles, but breaking x/sys/windows for this motivation seems a lot more benign.

Maybe? But if we're writing the shims for syscall anyway, why not write the shims for x/sys/windows too and save folks the trouble of fixing functions they're not even using in their dependencies?

I don't understand: if they're not using the functions, then they won't incur any breakage one way or the other. If they are using the functions, they're running into memory corruption now, and logical errors later. That is, unless we fix the signature and make people pass the right type. This is something we can do in x/sys/windows easily, without forcing an awkward build-tag situation. This is not something we can do easily in syscall, as you pointed out. Hence my compromise in https://github.com/golang/go/issues/44538#issuecomment-785410609 being an exercise in practicality and trade offs.

https://golang.org/cl/296149 and https://golang.org/cl/295174 together now implement the compromise plan described in https://github.com/golang/go/issues/44538#issuecomment-785410609

if they're not using the functions, then they won't incur any breakage one way or the other.

If they import a package that uses the function, that package will fail to compile even if they're not using any function or type in that package that depends on it in any way. (That is: the build will break even if the broken function would be eliminated at link time.)

In that sense, it causes a gradual repair of vulnerable usage, which is a good thing, considering the issue.
But also, let's please be practical about this: https://github.com/search?l=Go&q=windows.GetQueuedCompletionStatus&type=Code
Two uses of it on all of Github. One of which is mine!

The other I will personally submit a PR to as soon as the change lands.
Look, I understand your reluctance about the syscall std package and have no issue going with https://golang.org/cl/296149 , but for x/sys/windows, let's please try to be practical here and not drag this out over nothing.

Those two call sites don't include the known uses in x/exp and x/benchmarks, so there's gotta be something missing from that search. But I agree that changing the existing signatures in x/sys is less problematic than in syscall.

Those two call sites don't include the known uses in x/exp and x/benchmarks, so there's gotta be something missing from that search.

You are mistaken. Correct observation, but incorrect conclusion. x/exp and x/benchmarks -- and virtually everything else -- uses syscall, not x/sys/windows. The search is for uses of x/sys/windows, because that is the relevant package for that part of the discussion.
Again, in case there's confusion about what I'm suggesting:

We don't break the signature of syscall, but instead do https://golang.org/cl/296149 and encourage people to switch to x/sys/windows.
We make x/sys/windows use the right signature, via https://golang.org/cl/295174 .

We are on the same page about (1). Hence I discussed (2) here. Please re-read https://github.com/golang/go/issues/44538#issuecomment-785427786 in light of that.

I've prepared a PR -- https://github.com/criyle/go-judge/pull/10 -- to update the only code on all of Github that would be affected by https://golang.org/cl/295174 . That means I can fix all breakage within seconds of submitting the CL.

Alright, looks like @ianlancetaylor has merged part 1, so now we're just waiting on https://golang.org/cl/295174

Ah, you are correct that I was confusing the x/ users of syscall with the users of x/sys. In light of that (and the PR to fix the only known affected user), I'm ok with the plan to do x/sys as a breaking change. 👍

All fixed again, I think, so re-closing the issue.

https://github.com/criyle/go-judge/pull/10 and https://github.com/WireGuard/wireguard-go/blob/6856c0ff0e50eada76fd2189190016cdbf0ca52f/conn/bind_windows.go#L369-L371 are now updated, so I think we're all set.

Thanks for following up — I'm much happier with this fix!

I'm going to implement Ian's suggestion now from https://go-review.googlesource.com/c/go/+/296149/


Fix DiagnosticListener memory leak

When IsConfigured is called, it applies all services. This caused a DiagnosticListener to get instantiated on each DbContext instantiation, and since it wasn't disposed it caused a leak.
 This is a leak because the DiagnosticListener is disposable and the diagnostics system holds on to all constructed listeners until they are disoped, which never happens.
Customer Impact
Reported through support, and will likely also impact other customers, including those running on Azure.
Regression?
Yes. This leak did not exist in 2.1. (IsConfigured didn't work correctly in 2.1, but it didn't leak.)
Risk
Very low; avoid creating the instance when it is not needed.

Approved for 2.2.6. Checkin the fix now.

@roji Don't check in!


String type setter is not allowed to be numbers

Sometimes my string just happen to be "numbers", but kpt will compain about it.
Kptfile:
apiVersion: kpt.dev/v1alpha1
kind: Kptfile
metadata:
  name: str-val
packageMetadata:
  shortDescription: sample description
openAPI:
  definitions:
    io.k8s.cli.setters.stringValue:
      type: string
      x-k8s-cli:
        setter:
          name: stringValue
          value: '1234'
    io.k8s.cli.substitutions.subValue:
      type: string
      x-k8s-cli:
        substitution:
          name: subValue
          pattern: "prefix-VALUE"
          values:
          - marker: VALUE
            ref: '#/definitions/io.k8s.cli.setters.stringValue'

config.yaml
apiVersion: test/alpha
kind: strValue
metadata:
  name: strValue
spec:
  stringVal: 1234 # {"$ref":"#/definitions/io.k8s.cli.setters.stringValue"}
  subVal: prefix-1234 # {"$ref":"#/definitions/io.k8s.cli.substitutions.subValue"}

Error:
> ~/bin/kpt cfg list-setters .
Error: The input value doesn't validate against provided OpenAPI schema: validation failure list:
stringValue in body must be of type string: "number"
> ~/bin/kpt version
v0.29.0

Expectation:
"1234" should be a valid string although it's also a number.

This used to work. Not sure exactly when it broke but on 0.27+ i run into this when setting a setter to the value true and on some earlier version it definitely worked because I have this scripted.
Are there any known workarounds for this? I can't come up with any way of quoting that works. If I use "'true'" it no longer fails but then the value in my KRM becomes "'true'" so that doesn't work.

Works in 0.26.0

I think this might be related to the validation functionality that was added?
@phanimarupaka

This issue is caused by incorrect handling of values that are valid for both strings and other yaml types (like integers and booleans). This should be fixed by https://github.com/kubernetes-sigs/kustomize/pull/2599 and https://github.com/kubernetes-sigs/kustomize/pull/2608 and is included in kpt v0.30.0 that we released today.
We know there are still some rough edges around handling of types. If you run into this kind of issues, please let us know. There is a ongoing discussion around this on https://github.com/kubernetes-sigs/kustomize/pull/2594

I can confirm that setting a setter to true/false works as expected in 0.30.0

Thanks for reporting this.
I'm closing this issue now, but if you find any other issues, feel free to reopen or just file a new issue.


fix 360 templates; resolves #781

the url changed. if the new url is a valid url on vizor.io then lgtm

good point @kkananen - it was actually broken before in one of the templates. I've set it to the Boost Tribe 6 group photo in all three files.


Remove teardown calls in kube-down

Right now, these simply echo out TODO because the functions haven't been
completed in the relevant util.sh (depending on your cloud provider, so
Vagrant users use cluster/vagrant/util.sh where the functions are called
from).
TODO is messy, and whilst I appreciate that Kubernetes is a WiP, it was
rather confusing seeing only the word TODO printed to stdout during
kube-down.sh whilst new to Kubernetes.

These aren't TODOs in every provider: https://github.com/GoogleCloudPlatform/kubernetes/blob/master/cluster/gce/util.sh#L739

Er, sorry. I didn't mean to close so violently! If you want to refine this PR, you could change the "echos" in each of the other providers to noops.

You're right, but for those providers that do have TODOs, spitting the TODO into stdout is confusing. It made much more sense to me to TODO it in a roadmap and only include the calls when the feature is complete.... :/

Thanks for the suggestion @zmerlynn! I'll have a look :)

@ajlanghorn - Did you ever update this? o/w I'm going to close this soon.


Adapter no longer starts under js-controller 5.0.5

After an update to a new js-controller version the adapter does not start anymore. It is still a beta version. But it would be nice if the adapter later also work under the new versions again.
So far, the adapter has always worked without problems.
Good work from the developers.

F10 -> Developer options -> Console
Do errors appear there?

https://github.com/Xenon-s/ioBroker.device-reminder/issues/273