fix(content/en|jp/docs/rules): update list of ignored syscalls

What type of PR is this?
/kind bug
/kind content
Any specific area of the project related to this PR?
/area documentation
What this PR does / why we need it:
Update the list of ignored system calls to match output from falco:0.23.0

Special notes for your reviewer:

Thanks for your pull request. Before we can look at it, you'll need to add a 'DCO signoff' to your commits.
:memo: Please follow instructions in the contributing guide to update your commits with the DCO
Full details of the Developer Certificate of Origin can be found at developercertificate.org.
The list of commits missing DCO signoff:

41261e8 Update _index.md

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

Welcome @DrPhil! It looks like this is your first PR to falcosecurity/falco-website 🎉

[APPROVALNOTIFIER] This PR is NOT APPROVED
This pull-request has been approved by:
To complete the pull request process, please assign lucperkins
You can assign the PR to them by writing /assign @lucperkins in a comment when ready.
The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

/assign @lucperkins
Sorry if this PR is noise. My output didn't correspond with the docs.
❯ docker run falcosecurity/falco:0.23.0 -- /usr/bin/falco -i
<snip>
Ignored Event(s): access alarm brk capget clock_getres clock_gettime clock_nanosleep clock_settime close container cpu_hotplug drop epoll_create epoll_create1 epoll_ctl epoll_pwait epoll_wait eventfd eventfd2 exit_group fcntl fcntl64 fdatasync fgetxattr flistxattr fstat fstat64 fstatat64 fstatfs fstatfs64 fsync futex get_robust_list get_thread_area getcpu getcwd getdents getdents64 getegid geteuid getgid getgroups getitimer getpeername getpgid getpgrp getpid getppid getpriority getresgid getresuid getrlimit getrusage getsid getsockname getsockopt gettid gettimeofday getuid getxattr infra io_cancel io_destroy io_getevents io_setup io_submit ioprio_get ioprio_set k8s lgetxattr listxattr llistxattr llseek lseek lstat lstat64 madvise mesos mincore mlock mlockall mmap mmap2 mprotect mq_getsetattr mq_notify mq_timedreceive mq_timedsend mremap msgget msgrcv msgsnd munlock munlockall munmap nanosleep newfstatat newselect notification olduname page_fault pause poll ppoll pread pread64 preadv procinfo pselect6 pwrite pwrite64 pwritev read readv recv recvmmsg remap_file_pages rt_sigaction rt_sigpending rt_sigprocmask rt_sigsuspend rt_sigtimedwait sched_get_priority_max sched_get_priority_min sched_getaffinity sched_getparam sched_getscheduler sched_yield select semctl semget semop send sendfile sendfile64 sendmmsg setitimer setresgid setrlimit settimeofday sgetmask shutdown signaldeliver signalfd signalfd4 sigpending sigprocmask sigreturn splice stat stat64 statfs statfs64 switch sysdigevent tee time timer_create timer_delete timer_getoverrun timer_gettime timer_settime timerfd_create timerfd_gettime timerfd_settime times ugetrlimit umask uname ustat vmsplice wait4 waitid waitpid write writev

LGTM label has been added.  Git tree hash: 8f2523c0ef15033d24aed010437935f0da2a9638

[APPROVALNOTIFIER] This PR is APPROVED
This pull-request has been approved by: leodido
The full list of commands accepted by this bot can be found here.
The pull request process is described here

Needs approval from an approver in each of these files:

OWNERS [leodido]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment


Cannot parse checkbox's Description

Version

PyPDFForm=1.4.37
Issue Description

Unable to parse the description for the checkbox. This is important info for someone who has no reference to the original template (PDF).
Code Snippet

import json
from PyPDFForm import PdfWrapper
pdf_form_schema = PdfWrapper("i-90.pdf").schema
print(json.dumps(pdf_form_schema, indent=4, sort_keys=True))

Sample of Json Output
{
        "P1_checkbox4[1]": {
            "type": "boolean"
        },
        "P1_checkbox4[2]": {
            "type": "boolean"
        },
        "P1_checkbox6c_Unit[0]": {
            "type": "boolean"
        },
        "P1_checkbox6c_Unit[1]": {
            "type": "boolean"
        },
        "P1_checkbox6c_Unit[2]": {
            "type": "boolean"
        }
}

PDF Form Template
i-90.pdf

Screenshots (if applicable)

I tried to extract the TU ('/TU'), but its not working
WIDGET_KEY_PATTERNS = [
    {T: True},
    {TU: True},
    {Parent: {T: True, TU: True}},
]

Solved
Had to modify some files
Created new function in template.py get_widget_description
        P1_checkbox4[0]": {
            "description": "Part 1. Information About You. Your Full Name. 4. Has your name legally changed since the issuance of your Permanent Resident Card? Select Yes. (Proceed to Item Numbers 5. A. through 5. C.).",
            "type": "boolean"
        },
        "P1_checkbox4[1]": {
            "description": "Part 1. Information About You. Your Full Name. 4. Has your name legally changed since the issuance of your Permanent Resident Card? Select No (Proceed to Item Numbers 6. A. through 6. I.).",
            "type": "boolean"
        },
        "P1_checkbox4[2]": {
            "description": "Part 1. Information About You. Your Full Name. 4. Has your name legally changed since the issuance of your Permanent Resident Card? Select Not Applicable - I never received my previous card. (Proceed to Item Numbers 6. A. through 6. I.).",
            "type": "boolean"
        },

Hey thanks for posting, and sorry for a rather late response.
You can open a PR against branch PPF-757 if you want.

Hey @freaksie , if I'm not mistaken this fork is where your changes are at right?
I will be making a version bump of the library on New Year and would like to include your changes. To give me enough time to review/revision them, could you raise your PR against branch PPF-757 no later then Dec 20th? Thanks.


Playlist with 1 or more Pages doesnt work ...

Error:

https://sourceb.in/Ny8h8CBODV

Java Version: 11
Debian 10
Tried Java v13, v15, v16, v17

Doesnt work with them at all..
If i use them and try to do searches i always get this error: https://sourceb.in/jCMWdVEbQH

nevermind, it didn't update the lavalink.jar which i thought, bugs are fixxed with latest version! 👍


Upload Tokens

# User story
If tagged token list is available with the user, provide the option of uploading it and storing it in the database, so that the draft that is generated in the end would be of a better quality
# Definition of done
An administrator will be satisfied if

he can upload the tagged tokens to the server
provide a way to the end user access these tokens for translation (probably without exposing the underlying strong's numbers as that might confuse the end user)
ensure the completeness of the tagged tokens (the tagged tokens should represent the entire source text without missing any)

Assigned to @Joel-C-Johnson

Not in Stage 1


API is not clear to me about notational entry of options: upper: and lower: for root finding optimistix.Bisection/Newton

Hi Patrick,
solver = optx.Bisection(rtol=1e-19, atol=1e-15, lower = jnp.array(0.), upper = jnp.array(64000) )
y0 = (jnp.array(0.01))
sol = optx.root_find(fn=speed_curve_function, solver = solver, y0 = y0, args = root_find_pytree)
Thv = sol.value

I've tried inserting upper and lower several different ways.
Thanks,
Tom

You want:
optx.root_find(..., options=dict(lower=..., upper=...))

The options in the docstring is referring to the argment of the name in root_find. I can see that that's not the clearest for new users -- I'll tweak the docs to highlight the appropriate way to pass this in.

I've just opened #19 for this.
To explain why these are passed in a separate location, by the way -- this is to separate information about the solver itself (Bisection(...)) from the details of the problem it is being applied to (fn=..., options=...).

Thank you. That part of it worked. Now to deal with inf.


Add setMethods (#116)

Adds a setMethods function to allow for easy mocking of methods as discussed in #116 .

Can you also add a section in the docs?

Hey, I made the changes and updated the docs!
Let me know if you want anything else done. I might also try to focus some attention on the docs for both this lib and the official utils.

Added link to SUMMARY.md.


allow test to run even if VS150COMTOOLS is not defined

we can define it ourselves

@saul I don't see the InstallDir in registry, I'd say if it break on someone, that someone can then fix it, right now it breaks on everyones and it fixes it for 99.99% of them.

@smoothdeveloper are you looking under Wow6432Node? This value always exists.

@saul yes, it doesn't exist anymore for VS2017, at least on my machine.

I'm making that change so it is easy for most people to run tests from VS itself (without having to run it from a special shell), it can be improved further but this is already an improvement I think.

Urgh they got rid of it in 2017 😒
HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\VisualStudio\SxS\VS7 use the 15.0 value.

@saul / anyone, can someone confirm what is the situation in registry when several VS2017 are installed (I believe you can have them side by side)

I'm ok adding registry to the list of things we check, but I'd not like it to break because we'd have removed the hardcoded folders and that it doesn't look the same when there are several editions installed.

Good question - what do we use the environment variable for out of interest? Is it just for the F# compiler - if so it doesn't really matter which edition we use

@saul, looking a bit at usage (which I didn't do when I was just fixing that to get tests running in my VS), it is just bellow: it prepares an AssemblyCatalog from "IDE\CommonExtensions\Microsoft\Editor" folder.
It looks like MEF components gets registered this way, and for the purpose of unit tests, I don't think the different edition would have an impact.
We can still add better resolution with registry, I've made some more change to make that area of the code a bit better.

Start a VS command window for the version of VS you want it to run against and it will set the variables you need.  Replacing that script with a bunch of code is not really that interesting, and likely to be a maintenance bug farm.
So ... I am inclined to close this PR, there are plenty of places where we have code and scripts that adapt to the lack of this configuration, and they always have introduced unreliability and confusion and make it difficult to reason about or discover what happens.
What is the scenario you have in mind where the tests are run in the absence of running that script.
Kevin

@KevinRansom the scenario I'm using it for:

click VS2017
open VisualFSharp.sln
run any of the salsa tests from "Test Explorer" (many people like to run unit test from VS, either with Resharper or NUnit test adapter)

The tests don't rely on all the environment variables, they just need the location to the "IDE\CommonExtensions\Microsoft\Editor" folder.
It is ok to close it of course, but the concern of having tests run on most machines (without having to restart VS because it wasn't started from specific command prompt).
Generally to make the work in this repository look more like normal workflow (click build.cmd, open VS and get ready to work) is important concern.
@KevinRansom maybe ask the VS team to make that devenv will set the same stuff as the command line, that might be a sensible thing for future VS releases?

@smooth developer I haven't had a chance to see if this could help, but perhaps it might.
https://msdn.microsoft.com/en-us/library/jj635153.aspx

@KevinRansom this is something users of VS test runner can use, but it won't work in third part test runner (like Resharper, which is way superior).
I understand the concern about replicating C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\Common7\Tools\VsDevCmd.bat but here we just want VS folder, only enabling this via environment variable, or requiring the developer to update a .runsettings hurts the workflow for the common developer.

@smoothdeveloper
Almost all of the files in that location are available in nuget packages.  Nuget seems like the appropriate long term solution, also it would also remove another dependency of our build on the install location of VS ... that would be an excellent outcome ...
Microsoft.VisualStudio.CoreUtility.dll                      ---- https://www.nuget.org/packages/Microsoft.VisualStudio.CoreUtility/
Microsoft.VisualStudio.Editor.dll                           ---- https://www.nuget.org/packages/Microsoft.VisualStudio.Editor/
Microsoft.VisualStudio.Language.StandardClassification.dll  ---- https://www.nuget.org/packages/Microsoft.VisualStudio.Text.Data/
Microsoft.VisualStudio.Text.Data.dll                        ---- https://www.nuget.org/packages/Microsoft.VisualStudio.Text.Data/
Microsoft.VisualStudio.Text.Logic.dll                       ---- https://www.nuget.org/packages/Microsoft.VisualStudio.Text.Logic
Microsoft.VisualStudio.Text.UI.dll                          ---- https://www.nuget.org/packages/Microsoft.VisualStudio.Text.UI
Microsoft.VisualStudio.Text.UI.Wpf.dll                      ---- https://www.nuget.org/packages/Microsoft.VisualStudio.Text.UI.Wpf

Microsoft.VisualStudio.Editor.Implementation.dll            ----
Microsoft.VisualStudio.Platform.VSEditor.dll                ---- https://dotnet.myget.org/feed/roslyn-tools/package/nuget/Microsoft.VisualStudio.Platform.VSEditor

We may not require : Microsoft.VisualStudio.Editor.Implementation.dll and Microsoft.VisualStudio.Platform.VSEditor.dll.  If we do we can try to get them both added to nuget.  I'm sure we can get Microsoft.VisualStudio.Editor.Implementation.dll  added to myget?
I realize it is more work ... but releasing ourselves from an install location dependency seems like a win, what do you think?
Kevin

@KevinRansom I'd definitely be  a big fan of it, VSSDK version conflicts and directory changes and all the other finicky maddening configuration twiddles and tweaks are exasperating. The more consistency and stability when it comes to these dependencies the better 😁

Good idea @KevinRansom, I'll look to get it work this way.

@KevinRansom I'm seeing there are pending work on the build in several PRs, which might impact the packages.config stuff / location of packages.
Can we get this PR merged and postpone further change to leverage nuget packages or should I close this?

@smoothdeveloper I would prefer a nuget based solution to this issue.  we can close this and make an issue suggesting that we move the dll dependencies to a nugget package.

@KevinRansom that's what I did in https://github.com/Microsoft/visualfsharp/pull/2698

I think we need to fix this a different way.


Rest type

Add rest types. They implement the semantics of object rest as detailed in the second part of the proposal #10727. I have copied and updated that proposal here.
Notes:

Rest types are not difference types and are not usable as the constraint of a mapped type.
The nested rest-type relationships are not implemented yet because I'm not sure if they are worthwhile.

Rest types
The rest type is the opposite of the spread type. It types the TC39 stage 3 object-rest destructuring operator.  The rest type rest(T, 'a' | 'b' | 'c') represents the type T after the properties a, b and c have been removed, as well as call signatures and construct signatures.
A short example illustrates the way this type is used:
/** JavaScript version */
function removeX(o) {
  let { x, ...rest } = o;
  return rest;
}

/** Typescript version */
function removeX<T extends { x: number, y: number }>(o: T): rest(T, 'x') {
  let { x, ...rest }: T = o;
  return rest;
}

Syntax
The syntax is rest(T, U) where T is any type and U is string or a union of string literals (including never and single string literals).
Type Relationships

rest(A, never) is not equivalent to A because it is missing call and construct signatures.
rest(A | B, 'a') is equivalent to rest(A, 'a') | rest(B, 'a').
rest(A, string) is equivalent to {}.
rest(rest(A, 'a'), 'b') is equivalent to rest(A, 'a' | 'b') and therefore also to rest(rest(A, 'b'), 'a').

Assignment compatibility

rest(T, 'x') is not assignable to T.
T is assignable to rest(T, 'x') because T has more properties and signatures.
rest(T, V) is assignable to rest(U, W) if T is assignable to U and V is assignable to W.

Properties and index signatures
The type rest(A, P) removes P from A if it exists. Otherwise, it does nothing. A retains its index signatures unless P is string.
Call and Construct signatures
rest(A) does not have call or construct signatures.
Precedence
Rest types are just below the keyof operator in precedence.

Suggestion:

rest(T, keyof U) is equivalent to {} when U is assignable to T

Doesn't this break some design consistency?
All value argument lists are now delimited with braces ().  And all type argument lists are now delimited with brackets <>.
This PR adds a rest keyword and a type argument list delimited with ().
Since, I regard Pick<T>, Partial<T>, Readonly<T>as type operators. I would rather see Rest<T, 'x', 'y'>.

@Igorbek I didn't call it out sufficiently in the proposal text above, but the second argument of rest(T, U) can not be generic. It has to be a string or string literal union [1]. So there's no way to construct a generic rest(T, keyof U). And there's no other way to construct a string union that covers all possible properties of T.
[1] The reason that the second argument is not generic is that it's impossible to produce a generic object rest — you have to hard-code the names of properties that will be removed in the object destructuring/binding.
@tinganho I don't have a strong design opinion one way or another on the syntax. The only constraint is that we expect rest and spread types to be used rarely, especially rest types, so I don't want to use T - U as the syntax, because we'll probably want to use that for something else some day.
How about we gauge the community's preference by using :+1: to your comment to indicate Rest<T, 'x' | 'y'>, :-1: to indicate rest(T, 'x' | 'y') and :confused: to indicate something else. I see we already have 2 more votes for Rest.

interface FooBar {
    foo: string;
    bar: string;
}
interface Foo {
    foo: string;
}
interface Bar {
    bar: string;
}

would Rest<FooBar, keyof Foo> be equivalent to Bar?

@sandersn thanks for your comment. Sorry, that I didn't discovered your initial proposal earlier(I just read the spread part).
I think, I understand why you use lowercase rest here. I guess, it is to indicate an intrinsic type operator. Though, I don't really, like the special casing of the type system here. Even if we use capitalized Rest<T, 'x', 'y'>. May I suggest something more of a generic solution that might cover this special case? I have thought about it for months, but haven't had the time to submit it yet.

@sandersn I see what you mean. But isn't that the case for computed properties?
Currently this works, however is not properly typed:
const b = "b";
let c = { [b]: b, a: 10 }; // c is { [x: string]: string | number, a: number; }
let { [b]: b1, a: a1 } = c; // b1 is any; a1 is number

so should this be restricted then?
const b = "b";
let rest = { a: 10 };
let c = { [b]: b, ...rest };
let { [b]: b1, ...rest1 } = c; // BTW, this is allowed by the spec and Babel supports it

and generic case:
function destructure<T, U extends keyof T>(src: T, name: U): { value: T[U]; rest: rest(T, U); } {
  const { [name]: value, ...rest } = src;
  return { value, rest };
}

just thinking out loud

@rozzzly Yes.
@tinganho I would much prefer a general solution too; I tried to make something work with mapped types already. Maybe you can use these problems that I ran into to come up with something:

There are too many quirks in rest's semantics to use it as a real basis for generalisation. (Why drop methods and call signatures? Because the definition is based on Object.assign, of course!) But the general solution still has to work for rest.
Set difference of literal unions is the obvious general candidate, but doesn't really solve any compelling problems besides rest. At least I couldn't think of any.

Although I don't love the proposed rest syntax I don't really care for the generic type syntax either in this case. The advantage of not introducing new syntax is just that it would allow a better syntax to be introduced, preferably one that covered more type operators, in the future without causing confusion because it would be a shorthand or sugar as opposed to an alternate manifest form.

@sandersn So I submitted my idea to the issue tracker, though it is very rough. Though my initial idea was to solve typings for ORMs, but it seems it can apply to Rest<T, 'x', 'y'> as well. Please checkout #13500.
type Rest<T, ...S extends string[]> => {
    type Type;
    for (KT in T) {
        type IsInS = false;
        for (KS of S) {
            if (S[KT] != undefined) {
                IsInS = true;
            }
        }
        if (!IsInS) {
            Type[KT] = T[KT]
        }
    }
    return Type;
}

@Igorbek

Even with a call to destructure, the compiler can't know what the value of the thing is, just the type, which is just some set of string literal types:

function concrete(tricky: keyof (typeof c)) {
  return destructure(c, tricky)
}

This might remove a and it might remove b from c: { a: number, b: string }. Should concrete return {}? There is no useful way to avoid hard-coding the field names in a rest type.

The spec, babel and the typescript emitter all support computed properties with rest — check your examples in the playground to see that it handles computed properties correctly.

The typescript checker should be compared to flow, which doesn't support the generic case either and defaults to returning any (or probably an object with a string indexer, because flow doesn't produce any as readily as typescript). Even in the non-generic case, flow and typescript both fail to remove the computed property from the rest type if it's not a simple constant.
I will add an error instead. I don't like silently failing to remove properties that people asked to remove.
@aluanhaddad I hoped that introducing new, bad syntax would have nearly the same benefits as not introducing new syntax at all, with the added benefit that the syntax for generic types stays consistent.

So, does the rest operator finally allow the strict typing of applying map to a homogenous tuple type of arbitrary length without a large number of overloads?
declare function map<A extends Array<T>, T, U>(input: A | [void], operator: (t: T) => U): Array & { [P in keyof rest(A, keyof Array<T>)]: U };

const x = map([1,2,3], (x: number) => x.toString()); // x should have type [string, string, string], or at least one that has all the same semantics

Alternatively, if you want to generate invariant tuples:
function asInvariantTuple<A extends Array<any>>(input: A | [void]): rest(A, keyof []) & { readonly length: A['length'] } {
    return input;
}

const y = asInvariantTuple([1, 2, 3]); // y has type { 0: number, 1: number, 2: number, length: number }

Can't wait for this to land!
I feel helpless everytime I try to type a React HOC which reduces child props. :)

@raveclassic do you mind giving a miniature example that I can turn into a test case? I would like to make sure that scenario works.

@sandersn the most common example is https://github.com/reactjs/react-redux/blob/master/docs/api.md#connectmapstatetoprops-mapdispatchtoprops-mergeprops-options
let's say we have a component:
type Props = {
   a: number;
   b: number;
   c: number;
};

function Component(props: Props) {
  return (
{props.a}{props.b}{props.c}
);
}

the simplest example for HOC is:
function pass5AsA
(Decorated: ComponentClass
): ComponentClass<rest(P, "a")>;

but it's not very common, I think. Usually it would be something like:
type DecoratedComponent<DecoratorProps> = <InternalProps>(component: ComponentClass<InternalProps>): ComponentClass<rest(InternalProps, keyof DecoratorProps)>;
function decorateWithProps
(someProps: P): DecoratedComponent
;

@sandersn Sure, here's another example. I've omitted React for simplicity:
type TControlledProps<TValue> = {
  value: TValue | undefined,
  onChange: ((value?: TValue) => void) | undefined
}

type TStatefulProps<TValue> = {
  defaultValue?: TValue,
  value: never,
  onChange?: TControlledProps<TValue>['onChange']
}

class Component<TProps> {
  constructor(props: TProps) {

  }
}

function stateful() {
  return function decorate<V, P extends TControlledProps<V>>(Target: Component
): Component<Rest<P, keyof TControlledProps<V>> & TStatefulProps<V>> {

  }
}

type TControlledComponentProps = TControlledProps<string> & {
  //smth more
  foo: string
}
class Controlled extends Component<TControlledComponentProps> {

}

const controlled = new Controlled({
  //structure is valid (both value and onChange are explicitly required although can be undefined)
  value: '123',
  onChange: undefined,
  foo: '123' //required param
})

const Stateful = stateful()(Controlled);
const foo = new Stateful({
  value: '123' //value is restricted here by 'never',
  defaultValue: '123', //defaultValue and onChange are not required but may be present
  onChange() {
  },
  foo: '123' //still required param
})

@mkusher's example is still absolutely correct

Thanks @mkusher and @raveclassic. I also found the simple example at https://facebook.github.io/react/docs/higher-order-components.html to be useful:
render() {
  // Filter out extra props that are specific to this HOC and shouldn't be
  // passed through
  const { extraProp, ...passThroughProps } = this.props;

  // Inject props into the wrapped component. These are usually state values or
  // instance methods.
  const injectedProp = someStateOrInstanceMethod;

  // Pass props to wrapped component
  return (
    <WrappedComponent
      injectedProp={injectedProp}
      {...passThroughProps}
    />
  );
}

@sandersn I also just yesterday reviewed a PR to styled-components where I pointed to this very awaited feature.
Please also note from the examples provided by @mkusher and @raveclassic, that people are expecting to use it with generics on a right-hand side. You were against it, weren't you?

@Igorbek That's why I expect to use Rest with keyof on the right side which returns a string literal union.
@mkusher also used just a string literal.
@sandersn According to your words:

[1] The reason that the second argument is not generic is that it's impossible to produce a generic object rest — you have to hard-code the names of properties that will be removed in the object destructuring/binding.

I'm very far from TS internals so I don't get the problem with generic - is it impossible to resolve string literal union via keyof when generic is on the right side of Rest? Because in all other cases typesystem is able to resolve it.

@raveclassic your example uses keyof with a type parameter as its argument, which isn't supported by the current PR. Currently, this PR only supports actual strings or string unions, which of course can be produced by keyof, but only when its argument is an object type. That's because (1) I couldn't think of a way to strip off arbitrary properties using object rest destructuring and (2) the rest type is much simpler without a generic right side.
What is the body of decorate? Does it use object rest destructuring?

@sandersn Ahh, I see the difference now.
Yes, it uses destructuring. My example is too simplified and is incorrect due to class constructors (because of omitted React) but it reflects the idea that a HOC wrapper provides some required values to its child but does not require them itself. Your example from official facebook doc fits much more.
Still I've tried to adopt decorate to react:
type TStatefulState<TValue> = {
	value?: TValue
};
export function stateful() {
	return function decorate<V, P extends TControlProps<V>>(Target: React.ComponentClass
): React.ComponentClass<Rest<P, keyof TControlProps<V>> & TStatefulProps<V>> {

		class Stateful extends React.Component<Rest<P, keyof TControlProps<V>> & TStatefulProps<V>, TStatefulState<V>> {
			componentWillMount() {
				this.setState({
					value: this.props.defaultValue
				});
			}

			render() {
				//destructuring here
				const {onValueChange, defaultValue, ...rest} = this.props;

				return React.createElement(Target, { //tsx... :(
					...rest,
					value: this.state.value,
					onValueChange: this.onValueChange
				});
			}

			protected onValueChange = (value?: V): void => {
				this.setState({
					value
				});
				const {onValueChange} = this.props;
				onValueChange && onValueChange(value);
			}
		}

		return Stateful;
	};
}

The key point is to be able to use original Controlled that requires TControlledProps along with its Stateful version that injects that props and does not require them.
I ses that this PR is only about object types then if I coould manually specify keys like Rest
 - that would be enough. However supporting generics would be much more helpful.

@raveclassic I misread your example — it's more complex than I thought at first. decorate will work with the current implementation of rest types because the right side is keyof TControlProps<V>, which is known to be "value" | "onChange", unlike something like keyof V, which is unknown.
But in this case, couldn't Stateful extend React.Component<TStatefulProps<V>> ? The definitions of TControlProps and TStatefulProps is so similar that it seems superfluous to remove one via rest and add the other via &. If you use TStatefulProps, then you just have to make sure that it's a subclass of TControlProps by making onChange optional in both. (onChange already allows undefined in TControlProps, which is almost equivalent.)

@sandersn You claimed that the reason for restriction of using generic types here is that you do not know any possible way to produce an instance of rest(T, U) by having an instance of T without explicitly enumerating fields to remove. But that is not the only use case. The type itself has more useful properties, such as what can be used in the React HOCs.
The most important property of the rest type is this (which you didn't mention in the proposal):

rest(T, keyof U) ... U is assignable to T
however U ... rest(T, keyof U) is not assignable to T, because rest(T, keyof U) can have conflicting properties with U

By having this property, we can prove this:
declare const r: rest(T, keyof U);
declare const u: U;
const t: T = { r, ...u }; // this is proven now

That is exactly what we need for React HOC generalization.

You are right that I claimed that the only useful way to produce a rest type is from an object rest destructuring. The reason is that the ES spec defines both object rest and object spread as removing call signatures and non-own, non-enumerable properties, which Typescript approximates as class methods.
That means that basic identities just break down:

{} ... T is not assignable to T.
rest(T, never) is not assignable to T.

I considered adding a non-ES-based type similar to the intersection type called the difference type and then defining rest in terms of difference. But in January I arrived at the conclusion that it required too many additional features and that I couldn't find examples of any additional problems that difference solves on its own. In particular, I'm waiting to see existing Javascript code that can't be typed in Typescript right now.

Ah, yes, you're right. This rules are breaking basic identities.
We can still have some type relations in this form:

rest(T, keyof U) ... U is assignable to {} ... T (at least we removed redundant U type)

As an example of generic HOC could be:
const withProps =

(props: P) =>
    <T /* missing constraint that P extends T */>(Component: Component<T>) =>
      (innerProps: rest(T, keyof P)) =>
        <Component {...{innerProps, ...props}} />

const Sample = (props: { a: string; b: string; }) =>
{a + b)
;
<Sample a='hello, ' b='world' />

const HelloSample = withProps({ a: 'hello, '})(Sample);
<HelloSample b='world' />

An alternative approach could be using something like Mapped conditional types #12424 where properties could be filtered out or replaced with some other type (like, make some members optional).

And one more alternative:
const withProps =

(props: P) =>
    <T>(Component: Component<{...T, ...P}>) =>
      (innerProps: T) =>
        <Component {...{innerProps, ...props}} />

This is perfect typing, but the issue here is that type is not inferred (I'd like it would).

@sandersn Maybe I should have not included  | undefined in my example - it's a bit confusing, so let's omit it.
TStatefulProps cannot inherit TControlledProps because then ComponentClass<TStatefulProps> would require passing value each time to Stateful components while they hold this value inside their state and should not accept any.
So generally a HOC injects some required props to its child and also makes it possible to render this wrapped child without specifying these props like it's shown in @Igorbek's example with Sample and HelloSample.

Is there any way of seeing this merged at least without support of generics?

How about using \ (inspired by the complement of a set) for the syntax? e.g.:
function removeX<T extends { x: number, y: number }>(o: T): T \ 'x' {

Perhaps this could be solved with a syntax closer matching JS (avoids syntax clash, keeps learning curve low) with the type-level destructuring explored in #10727: type { a, ...Rest } = { a: 1, b: 2 };.
Maybe then one might grab them from objects and/or unions using a spread as well, hopefully allowing for straight-forward support for generics:
// destructure object
type Obj = { a: 1, c: 3 };
type { ...Obj, ...Rest } = { a: 1, b: 2 };
// Rest: { b: 2 }

Note Obj's role becomes more pattern-matching (leaving the rest for that ...Rest) than assignment.
Questions on most desirable behavior:

error if the values for keys in Obj don't match?
ignore unused keys in Obj? or error?
variance?

Alt.: destructure unioned keys
type Obj = { a: 1, c: 3 };
type Keys = keyof Obj; // 'a' | 'c'
type { ...Keys, ...Rest } = { a: 1, b: 2 };
// Rest: { b: 2 }

Notes:

destructuring unions here is new -- JS never had unions
Keys is a union of keys (pattern-matched to pass on whatever remains), while Rest is assigned an object here

@sandersn:

I arrived at the conclusion that [set difference of literal unions] required too many additional features

Hm. I forgot if I got it from another thread, but I'd imagined this as a unary negating operator ~, such that ~1 would mean "a type that is not 1", so a difference might be expressed as (1 | 2) & ~1 (-> 2).
That said, it doesn't necessarily just revert union operations -- (1 | number) & ~1 would produce not number, but number & ~1 (ditto for unresolved generics, (A | B) & ~B -> A & ~B).
I could theoretically foresee small use-cases e.g. number & ~0 (useful for typing a safe division operation?), but honestly can't think of much outside of calculating object difference either.
If you foresaw needing 'many additional features' I suppose I didn't get quite as far in exploring further considerations though.

Tried for a bit more to do a union difference operation using today's syntax.
type UnionDiff1<Big extends string, Small extends string> = UnionDiff<Big, Small>[Big] /*!*/;
type test1 = UnionDiff2<'a' | 'b' | 'c', 'b' | 'c' | 'd'>;

This yields "a" | "b" | "c" instead of just "a". Somehow having the [Big] index operation directly in there fails -- help appreciated!
Second attempt, separate the steps...
type UnionDiff2<Big extends string, Small extends string> =
  {[K in Big]: { 1: Union2Keys<Big>[K], 0: undefined }[NotS<UnionHas>]} //[Big] /*!*/;
type A = UnionDiff<'a' | 'b' | 'c', 'b' | 'c' | 'd'>;
// now manually do that second step...
type Big = 'a' | 'b' | 'c';
type B = A[Big];

This returns either "a" (yay!), or "a" | undefined if strictNullChecks are enabled.
The strictNullChecks scenario could be fixed if the assertion operator ! were exposed on the type level... if my first attempt could be made to work as well, could that perhaps be an elegant route to tackle this feature?

How about trying never instead of undefined? It seems to be working for me in strict mode:
type UnionDiff2<Big extends string, Small extends string> =
  {[K in Big]: { 1: Union2Keys<Big>[K], 0: never }[Not<UnionHas>]} //[Big] /*!*/;
type A = UnionDiff2<'a' | 'b' | 'c', 'b' | 'c' | 'd'>;
// now manually do that second step...
type Big = 'a' | 'b' | 'c';
type B = A[Big];

let testYes: B = "a"; // typechecks
let testNo: B = "b";  // fails

PS nice type level magic. Kind of sad this works only for string literal types, not arbitrary types due to index signature limitation though.

@jaen: progress! thanks for that! 😄
I'll concede the limitation is unfortunate, yeah. Out of curiosity though, what's your use-case?
They probably closed #4183 under the impression this covered most, as seen in @sandersn's quote:

I couldn't find examples of any additional problems that difference solves on its own

I couldn't think of much either, hence I'm all the more curious. :)

Depends on use case of what you're asking about. If we're talking about subtracting of arbitrary types from union (which is what led me here) it's fairly simple, our codebase uses tsmonad with strict null checks leading to some annoying issues, for example:
const maybe: <T>(value: T) => Maybe<T> =
    (value) =>
        !!value
            ? Just<T>(value)
            : Nothing<T>();

maybe(null)
    .fmap(x => x + 2); // complains about `x` being possibly null, even though
                       // `fmap` will by definition be only called with inhabited
                       // `Just` values

which could be alleviated with something like either of (or preferably both):
const betterMaybe: <T>(value: T) => Maybe<T - null | undefined> = …;
// alternatively by lifting non-null assertion to type level
const betterMaybe: <T>(value: T) => Maybe<T!> = …;

Is that a satisfactory answer?

@jaen: hmm. what if you'd write say .fmap(x => x! + 2)? type-level ! would be nicer, but yeah...

Yeah, I am aware of the non-null assertion, but this has the overhead of having to write it out inside each fmap` lambda, which is suboptimal. It would be nice to solve this in one place with a proper type.
As for your suggestion — this will work I assume, but will require me forking tsmonad and modifying the source, which I wanted to avoid. Being able to do this on the type level has the added benefit on being able to do it in a local typings file to shadow the library's type.
So that's my use case, I guess — this can be done otherwise, by writing down a non-null assertion at each use site or forking and modifying the library to work with strict null checks, but both feel fairly inelegant to me.

@jaen:
Hmm. In this particular case, if I were you I'd just make a PR to tsmonad, since this seems like a fairly beneficial change, wouldn't suspect it to be particularly controversial.
From the TS team's perspective, I suppose a general solution was considered fairly involved, in the sense it'd require introducing negation types ('a type that is not T'), for one.
That said, the logic that would solve your current use-case appears to be implemented already in that ! operator -- in my perception, the only change needed to address this would be for them to just expose it as part of the type-level syntax as well.
Given demand for that, perhaps they'd be more open to that idea than to having to tackle the more complex generic case.

Hm, I guess I could consider a PR. I thought the library was dead (had improvements over last version in the repo, but no officially released package), but now that I checked it's not, so it might make sense to change that upstream, I guess.
Well, I'd probably prefer a more generic solution, since while lifting the ! into types solves this use case, I can imagine other kinds of subtractions might come in hand in the future, but even having a type-level ! would be nice.
Do you have any link explaining why the negation type would be needed? I would assume you can remove from a union by equality (which types already have) so I'm not sure why some not-T would be required to implement type union subtraction. Maybe I'm missing some use cases though.

@jaen: that was this idea. There may well be ways without it. I personally just hope - will still be introduced for type-level numeric substraction hahaha, perhaps that just lead me to adhering that version rather than that in the OP there.

Putting things together based on @nirendy's solution to work around the glitch by cutting things into steps with generics defaults:
type Obj<T> = { [k: string]: T };
type SafeObj<O extends { [k: string]: any }, Name extends string, Param extends string> = O & Obj<{[K in Name]: Param }>;
type SwitchObj<Param extends string, Name extends string, O extends Obj<any>> = SafeObj<O, Name, Param>[Param];
type Not<T extends string> = SwitchObj<T, 'InvalidNotParam', {
  '1': '0';
  '0': '1';
}>;
type Union2Obj<Keys extends string> = { [K in Keys]: K };
type Union2Keys<T extends string> = Union2Obj<T> & { [k: string]: undefined };
type UnionHasKey<Union extends string, K extends string> = ({[S in Union]: '1' } & { [k: string]: '0' })[K];

export type UnionDiff_<Big extends string, Small extends string> =
  {[K in Big]: { 1: Union2Keys<Big>[K], 0: never }[Not<UnionHasKey>]}//[Big];
export type UnionDiff<
    Big extends string,
    Small extends string,
    Step extends UnionDiff_<Big, Small> = UnionDiff_<Big, Small>
> = Step[Big];
type TestUnionDiff = UnionDiff<'a' | 'b' | 'c', 'b' | 'c' | 'd'>;
// ^ 'a'

Should this be closed?

On hold for now


Uncaught HTTP verbs by error handler

per debug output swagger-tools:middleware:metadata   Is a Swagger path: false
all HTTP verbs except for GET never gets caught by error handler.

What happens is if you request a path that is not a Swagger path, none of the middlewares will do anything and will just send the request downstream.  Now if the request is for a Swagger path but there is no Swagger operation defined, you will get a 405.  Since your debug output matches that of the first scenario, what is happening is by design.
Since this seems to be unexpected, I need to know your path definition string and the request path to help further.

Thats exactly what i expected but swagger-tools:middleware:metadata still gets called.
below is the complete debut output.
swagger-tools:middleware:metadata PUT /users +1m
swagger-tools:middleware:metadata   Is a Swagger path: false +0ms

I don't have a /users endpoint specified in my swagger spec.
below is my cURL output
> POST /users HTTP/1.1
> Host: localhost:10010
> User-Agent: curl/7.43.0
> Accept: */*
>
< HTTP/1.1 404 Not Found
< Access-Control-Allow-Origin: *
< Access-Control-Allow-Methods: GET,PUT,POST,DELETE
< Connection: close
< X-Content-Type-Options: nosniff
< Content-Type: text/html; charset=utf-8
< Content-Length: 19
< Date: Thu, 08 Oct 2015 15:19:55 GMT
<
Cannot POST /users
* Closing connection 0

It's working as designed.  All of the middleware provided by swagger-tools, which is what swagger-node uses, are only interested in Swagger paths.  If you request a path that is not a Swagger path, we send the request downstream to allow other parts of your server to get involved.
There has been some requests to make swagger-node/swagger-tools have some "strict mode" where you'd error on non-Swagger paths, error on undefined parameters, etc.  But that is not available as of now.
That being said, swagger-node does not care that you requested a path that is not a Swagger defined path and will send the request downstream.

I don't understand what behavior you're expecting. Are you saying that you want your error handler to be able to capture 404s?

If I understand correctly, @kadjei wants an error to be thrown whenever a request is made to a path that is not a Swagger path instead of the request falling through and resulting in a 404.

Its exactly as described by @theganyo and i have a method to handle 404s as show below.
// 404 Errors
app.get('*',function(req,res,next){
   res.status(404);
   var response = {"code": "NOT_FOUND","message" : "Resource not available"};
   logging.info(response);
   res.json(response);
   next(err);
});

// All Errors
app.use(function(err,req,res,next){
   res.set("Content-Type","application/json");
   logging.error(err);
   res.json(err);
})

I get the expected behavior for GET requests but all other HTTP verbs product Cannot {HTTP verb} /users

Your first handler is only capturing "get" requests (app.get). Is that the problem?

@theganyo That was an oversight on my end should've had a co-worker look at it before posting an issue.
Thank you

On another note you guys are doing great work on this project.
Thank you both.

Awesome, @kadjei. Glad it's worked out! :)

Thanks @kadjei.


GPX read support

Fixes https://github.com/georust/geozero/issues/47
This adds a GeomProcessor for GPX files

@pka @michaelkirk This is ready for another review

The outputs in the tests look ok to me. Could you please "fix" them and reduce the git commits?

The outputs in the tests look ok to me. Could you please "fix" them and reduce the git commits?

Done

reduce the git commits?

Can we just use the "Squash and merge" feature in the GitHub pull request?

reduce the git commits?

Can we just use the "Squash and merge" feature in the GitHub pull request?

I'm afraid that @michaelkirk's commits are lost with "Squash and merge", so a manual git rebase -i session is needed.

FWIW - I'm happy to see this get merged with or without my commits staying in tact. Go wild!

https://github.blog/changelog/2019-12-19-improved-attribution-when-squashing-commits/

Before today, whoever opened the pull request became the sole author of the squash commit. Now, we will automatically credit every commit author in the pull request as a co-author on the squash commit.

GitHub will attribute everyone in the PR


Allow providing non-encoded password input for MessagingUser

Requiring MessagingUser passwords to be base64-encoded has been a common source of errors for users. It would be convenient if they could specify the password as plain text instead of base64. Possible using a type 'password-plain' or change 'password' to 'password-base64'.

@lulf , as idea, it could be the same field as now, but marked password as Artemis does. If it contains ENC(xyz) the password must be encoded, if no, it's already encoded. Also, could be added additional properties with encoding algorithms and/or encoding on the flight mark.

Perhaps we should follow the model used by Kubernetes secrets stringData i.e. use a separate field that accepts the clear text and internally produces the encoded value.

In this way, may be try to use Kubernetes secrets for store passwords and not implement own logic for this.

@dmvolod Using secrets would require EnMasse to have access to the secrets in an application's namespace, requiring the application to setup an addition Role + RoleBinding. We can certainly support that use case as well though, but for application running on cluster, I think the serviceaccount user type is more attractive.

This is addressed in #4391


Have a default value for sort_by

For example:
sort_by :created_at, default: :asc
To sort even if not sort params are given.

@btrd is this still an issue?

Don't know :/


Redesign our User Journey Map

Describe the issue
Following our effort to knowing our user and fine tuning our service, mapping the User experience will help us into visualizing the steps our users going through. This exercise will help us as well to look at our service in a different clearer angle.
Which Sprint Goal is this issue related to?

Note: 'Milestone' is a ZenHub term that we use synonymously with 'Sprint'.

The 'Milestone' description (created in ZenHub) should clearly list Sprint Goals. This section should indicate which 'goal' this issue is related to.
Additional context

This is a great article about the difference between 2 and this is a video that explains it all together. As for template we can adapt this one.
Reference in Devhub

Definition of done

talk to users/business owners
map their journey (if we have users who went through the whole process)
deliver a draft journey diagram
if possible, choose an analogy/format that is more editable
out of scope: publishing the journey map

This is already documented in the Service Blueprint document.


bug: merge iterator panics when cancelling (dropping)

Describe the bug
commit: 6b3177a53ee4c50cc7098051faada224c12e7f63
https://buildkite.com/risingwavelabs/main/builds/2356#0184bea5-1058-4d0f-9a9d-06e0329a391e
   5: core::option::Option<T>::expect
             at /rustc/b8c35ca26b191bb9a9ac669a4b3f4d3d52d97fb1/library/core/src/option.rs:741:21
   6: <risingwave_storage::hummock::iterator::merge_inner::MergeIteratorInner<I,NE> as risingwave_storage::hummock::iterator::HummockIterator>::key
             at ./src/storage/src/hummock/iterator/merge_inner.rs:300:9

To Reproduce
No response
Expected behavior
No response
Additional context
No response

https://github.com/risingwavelabs/risingwave/blob/15030ea76be219a5a2bd64ad28527852ded1a724/src/storage/src/hummock/iterator/merge_inner.rs#L251-L268
The PeekMut here crosses the await point. If we cancel the iterator at this point, we'll get the iterator to be in an inconsistent state. This is similar to https://github.com/risingwavelabs/risingwave/pull/1099.
cc @wenym1

The problem seems irrelevant to the peek_mut. It's caused by the current code of OrderedMergeIterator, which takes all the nodes with the same user key out, do async next, and then put the node back to the heap. If we put all the nodes out, and the future gets canceled, the heap will become empty, and fail to get the key of the top node, which causes this panics. cc @hzxa21
I will fix this issue later.

The panic occurred when dropping the PeekMut. 🤔
  13: <alloc::collections::binary_heap::PeekMut<T> as core::ops::drop::Drop>::drop
             at /rustc/b8c35ca26b191bb9a9ac669a4b3f4d3d52d97fb1/library/alloc/src/collections/binary_heap.rs:297:22
  14: core::ptr::drop_in_place<alloc::collections::binary_heap::PeekMut<risingwave_storage::hummock::iterator::merge_inner::Node<risingwave_storage::hummock::iterator::HummockIteratorUnion<risingwave_storage::hummock::iterator::Forward,risingwave_storage::hummock::iterator::merge_inner::MergeIteratorInner<risingwave_storage::hummock::iterator::HummockIteratorUnion<risingwave_storage::hummock::iterator::Forward,risingwave_storage::hummock::shared_buffer::shared_buffer_batch::SharedBufferBatchIterator<risingwave_storage::hummock::iterator::Forward>,risingwave_storage::hummock::sstable::forward_sstable_iterator::SstableIterator>,usize>,risingwave_storage::hummock::iterator::merge_inner::MergeIteratorInner<risingwave_storage::hummock::sstable::forward_sstable_iterator::SstableIterator,usize>,risingwave_storage::hummock::iterator::concat_inner::ConcatIteratorInner<risingwave_storage::hummock::sstable::forward_sstable_iterator::SstableIterator>>,()>>>
             at /rustc/b8c35ca26b191bb9a9ac669a4b3f4d3d52d97fb1/library/core/src/ptr/mod.rs:491:1

The panic occurred when dropping the PeekMut

When dropping the PeekMut, it will try getting the key of the top node. When the top node is also a merge iter, it will try to get the key from an empty heap, and panics.


Navbar Styling Issue on Homepage on meduim size (640 to 760)

Description
The navbar on the homepage doesn't look visually appealing for the medium size like . The alignment and spacing seem off, especially when viewed on different screen sizes. This issue is noticeable in the attached screenshot.

Steps to Reproduce:
Visit the Rustcrab homepage.
Observe the navbar's alignment and spacing on a medium-sized screen (640 t0 760px width).
Expected Behavior:
The navbar should have consistent spacing and alignment across all screen sizes.
The text should be centered vertically, and the spacing between menu items should be even.

@FrancescoXX  can i work on this

hey @prathmesh0125 , @TukhtayevaRoziya already raised a PR. I can assign this to them or you can work on it.
#158

ok you can assign them , they already fixed it


fix(positioning): fallback positions should work while scrolled

r: @jelbourn

Firefox and IE are unhappy. Looking into it

LGTM


Saving status toast should be shown slower

Description:
On sensor settings page when user changes setting it will be synced to cloud with status toast popping up at bottom of the screen.
The first "saving to cloud..." status shows too fast for user to be able to read it
Let's make it a little bit slower

@markoaamunkajo
Actually toast for "Saving to cloud... Please wait." is showing for indefinite time. Once it's saved or failed toast is replaced by "success" or "fail" message. I can add additional delay, what should it be?

500ms - should be delay

QA passed


Creating more than one network

Weave's IPAM supports only one subnet at present, which means (assuming IPAM is the only kind of co-ordination) that the weave plugin can have only one network. So this will have wait for IPAM to be able to allocate subnets, and support allocating IPs from a specific subnet.

So this will have wait for IPAM to be able to allocate subnets, and support allocating IPs from a specific subnet.

This requirement is encoded as the "symbolic names" variety of https://github.com/weaveworks/weave/issues/676

When the plugin is deployed as a global driver, we get multiple network support by virtue of using Docker's default IPAM. There is no advantage to using our own IPAM because Docker still does KV operations on container start/stop to propagate service discovery information to all hosts - consequently there is no point extending our IPAM to support multiple subnets.
With the plugin deployed as a local driver to avoid the kv dependency (see #43) we can have only one subnet, so although we would be using our own IPAM there is no need to extend it to support subnet allocation.
Given the above we cannot make progress on this issue until such time as Docker allow us to create global drivers without requiring a kv store.

When the plugin is deployed as a global driver, we get multiple network support by virtue of using Docker's default IPAM.

Specifically: Docker's default IPAM will allocate a fresh, distinct subnet for each network, and that means that even if weave does nothing on network creation, the containers on each network will be in a subnet together.


Use a proper file browser widget in DataBrowser

Current behaviour
In order to change the list of files displayed in DataBrowser's QListView one has to open a filedialog, navigate to a different directory and close that dialog.
Desired behaviour
This process could be streamlined by simply using some file browsing widget in place of the QListView in the first place.

On Mac an Windows:
The file browser has a frozen view of home directory.
It allows for browsing down to required files, but can be annoying when they are deep in folder tree.
Also, it doesn't allow to view files in directories above the /~, which is not a big problem, but a small limitation.
Maybe there is a straightforward solution?

Horizontally frozen view: The easiest solution might be adding a horizontal scrollbar.
Browsing beyond ~: I implemented this as a feature with the idea to limit the visible file system to the relevant parts. It's trivial to change this behaviour to include everything from the file system root. However, at least in linux (and likely MacOS?) it should be unlikely to be necessary to browse beyond ~? Is it different on windows?

Fixed with 74ae70f
One idea would be to use the currently obsolete Open File function (shortcut Ctrl + O) to instead set the displayed filesystem root. This we, we can start with a reasonable default but give users the freedom to visit their whole filesystem. Thoughts?

The problem actually appeared already.
At the beamline, data are shared between machines via mapped drivers. On windows that means that mapped driver gets its own address (e.g. Z:\), and therefore cannot be accessed from C:\Users\xxx
Same problem will inevitably appear on Linux and Mac, where mapped directories are located in /Volumes/xxx/.


PMID:25402480

abolished 18s rRNA cytidine (1297 and 1815) acetylation
abnormal ribosome biogenesis

cant work out how to set a new label...wanted to add a "workshop" label

Label added.
(For future reference: go to the Issues list, and click the Labels tab.)

from here,
https://github.com/pombase/fypo/issues
not from the ticket
On 28/10/2015 13:16, Antonialock wrote:

cant work out how to set a new label...wanted to add a "workshop" label
—
Reply to this email directly or view it on GitHub
https://github.com/pombase/fypo/issues/2390#issuecomment-151842290.

--
Cambridge University
PomBase http://www.pombase.org/
Cambridge Systems Biology Centre http://www.sysbiol.cam.ac.uk/Investigators/val-wood

abnormal rRNA modification FYPO:0005015
abolished 18S rRNA acetylation at C1297 and C1815 FYPO:0005016
abnormal ribosome biogenesis FYPO:0005017

edit file: e3d1b713aa95d645445e05c97850f44e29b33b5c
release: 9d851f2dcd57ad8363ea4df4506fc965481b8033


OpenAPI generator: Deny using z.file() in input.

z.file() was introduced in v2.1.0.
It should not be used for I/O at all.
Perhaps it should be refactored into something else.

Since the interface is not changed, while the behaviour changed, I'm going to consider this as a patch according to SemVer.


Playing external subtitles with m3u8 link of video

Bug

Platform

Which player are you experiencing the problem on:

iOS

Environment info

React native info output:
 // paste it here

Library version: x.x.x
Steps To Reproduce

...
Expected behaviour

Reproducible sample code

Video sample
If possible, include a link to the video that has the problem that can be streamed or downloaded from.

Although your explanation is not very clear, I am currently having the same problem. I would like to play hls m3u8 subtitles

    selectedTextTrack={{
        type: 'language',
         value: 'en',
       }}
       textTracks={tracks}

Hi @RobertArissen , i'm talking about these two props of react-native-video. When my source file is in m3u8 format, adding external subtitles from these props hangs the video. But if i use .mp4 video, it works perfectly fine,
The question i asked was if i could use these props for m3u8 link.

this issue is open from #1511.

Use dash format for your video

Thankyou for the guidance. Will dash format be able to support subtitles on IOS with this package?
Also, how can i convert my m3u8 format to dash in react?


feat: rolldown dev integration (POC)

vite base branch https://github.com/rolldown/vite/pull/43
rolldown https://github.com/rolldown/rolldown/tree/hmr-poc
prior experiment https://github.com/hi-ogawa/experiments/tree/main/viteroll

examples
pnpm -C playground/rolldown-dev-react dev
pnpm -C playground/rolldown-dev-ssr dev

todo

[x] integrate plugins

[x] decouple @vite/client
[x] decouple current dev plugin container
[x] setup PluginContext
[x] integrate user plugins

[ ] adopt core plugins

[x] define
[x] alias
[x] oxc transform
[ ] vite:build-html

[ ] tests

Closing in favor of https://github.com/rolldown/vite/pull/66


Update and rename ActionGroupManager.frozen to ActionGroupManager.netkan

I'm wondering if this changes are enough to make ActionGroupManager Continued available to CKAN from SpaceDock.

Looks like @linuxgurugamer asked the author whether it was OK to add this mod, and he didn't receive a "Yes." It's probably not a good idea to merge this as long as that's the case. Please let us know whether that situation changes.
https://forum.kerbalspaceprogram.com/index.php?/topic/161919-131-en-es-de-action-group-manager-continued/&do=findComment&comment=3172862


Add option to read all fields from I3 files

Rather than specifying pulse maps, features, etc. similar to existing (in icetray) HDF5 converter. Could be done by making an EverythingExtractor.

@asogaard  I'll take a look at this


Menu editing

I had added a category page to my menu and later returned to edit that link to change to point to a standard page, but the changes were not saved. I had to first delete the existing menu link and then add the new one (version 1.0.8).
Also after editing a menu link, clicking save does not collapse the edit box.

its a bug - confirmed


BIGTOP-3929. Fix build failure of Flink due to transitive dependency on pentaho-aggdesigner-algorithm.

https://issues.apache.org/jira/browse/BIGTOP-3929
Building flink fails due to missing transitive dependency on pentaho-aggdesigner-algorithm.
[ERROR] Failed to execute goal on project flink-connector-hive_2.12: Could not resolve dependencies for project org.apache.flink:flink-connector-hive_2.12:jar:1.15.3: Failed to collect dependencies at org.apache.hive:hive-exec:jar:2.3.9 -> org.pentaho:pentaho-aggdesigner-algorithm:jar:5.1.5-jhyde: Failed to read artifact descriptor for org.pentaho:pentaho-aggdesigner-algorithm:jar:5.1.5-jhyde: Could not transfer artifact org.pentaho:pentaho-aggdesigner-algorithm:pom:5.1.5-jhyde from/to conjars (http://conjars.org/repo): Transfer failed for http://conjars.org/repo/org/pentaho/pentaho-aggdesigner-algorithm/5.1.5-jhyde/pentaho-aggdesigner-algorithm-5.1.5-jhyde.pom: Connect to conjars.org:80 [conjars.org/<IP_ADDRESS>] failed: Connection timed out (Connection timed out) -> [Help 1]

I backported the patch of FLINK-27640 to branch-1.5 here for Bigtop 3.2.1 which should not have big version bumping. We can file another JIRA for bumping Flink (to 1.17.0 or later?) for Bigtop 3.3.0.

You can not reproduce the issue if you have cached artifact under ~/.m2/repository/org/pentaho.

+1
I reproduced this error within docker container, which have no cache, on arm64/RockyLinux8 host.
$ ./gradlew flink-pkg-ind  -POS=rockylinux-8
...
[ERROR] Failed to execute goal on project flink-connector-hive_2.12: Could not resolve dependencies for project org.apache.flink:flink-connector-hive_2.12:jar:1.15.3: Failed to collect dependencies at org.apache.hive:hive-exec:jar:2.3.9 -> org.pentaho:pentaho-aggdesigner-algorithm:jar:5.1.5-jhyde: Failed to read artifact descriptor for org.pentaho:pentaho-aggdesigner-algorithm:jar:5.1.5-jhyde: Could not transfer artifact org.pentaho:pentaho-aggdesigner-algorithm:pom:5.1.5-jhyde from/to conjars (http://conjars.org/repo): Transfer failed for http://conjars.org/repo/org/pentaho/pentaho-aggdesigner-algorithm/5.1.5-jhyde/pentaho-aggdesigner-algorithm-5.1.5-jhyde.pom: Connect to conjars.org:80 [conjars.org/<IP_ADDRESS>] failed: Connection timed out (Connection timed out) -> [Help 1]
[ERROR]
...
BUILD FAILED in 16m 48s

And after applying this PR, I succeeded the build on both arm64/RockyLinux8 and amd64/Ubuntu22.04
$ wget https://github.com/apache/bigtop/pull/1104.patch
$ patch -p1 < 1104.patch

$ ./gradlew flink-clean flink-pkg-ind  -POS=rockylinux-8  # on arm64/RockyLinux8
...
BUILD SUCCESSFUL in 36m 57s

$./gradlew -POS=ubuntu-22.04 -Pdocker-run-option="--privileged" flink-clean flink-pkg-ind # on amd64/Ubuntu22.04
...
BUILD SUCCESSFUL in 51m 8s


$ pnpm install dep1 dep2 logs only dep1, swallowing evertyhing else while installing both though

It seems like pnpm logs only first target modules to install. Simple test case for pnpm 0.17.0 are no-deps packages as inherits and ramda:
$ pnpm i inherits
  inherits                                                          2.0.1 ✓
$ pnpm i ramda
  ramda                                                            0.19.1 ✓
$ pnpm i inherits ramda
  inherits                                                         0.19.1 ✓
$ pnpm i ramda inherits
  ramda                                                            0.19.1 ✓

how about pnpm-install ramda inherits?

nope:
$ pnpm-install ramda inherits
  ramda                                                             2.0.1 ✓

i looked into that cli switch, nope installMultiple gets both packages and logger with getTask get both packages to act on as well .

shame, I can't believe I missed this.

its fine, i just didn't find yesterday exact lines where this missing happens, so i decided to share this problem


Issue with creating a order of type "Market"

Endpoint /order/place is giving a 400 when creating an order of type MARKET

@clprdp
Are you still experiencing this issue?
If yes, please raise a query on the Upstox community. This is where both our team and the active developer community are diligently checking and responding.
Thanks!


Code changes to fix the description bug

If description of the parameter is not the last node e.g in below, then "Request Body Example" will be used as description instead of Request Body
Request Body
        Request Body Example

Mentioned it in description, is that not clear?

In reply to: 403985847 [](ancestors = 403985847)

I read the description, but I don't get it. Is there an issue or bug I can read? Or can you give an example of what is correct vs not correct?

I didn't log an issue but sure can if it helps, but content will not change much so explaining here, consider below documentation
Request Body
        Request Body Example
In the above example description of the param "sampleObject1" is Request Body but before this fix, "Request Body Example" is being parsed as description which is a bug. And that is happening b/c paramElement.DescendantNodes().ToList() returns
list of all the descendants node and not just the immediate child node, and then the logic was picking last text node as description which was Request Body Example and not Request Body. So updated code to use
element.Nodes() which gives immediate child node and fixes the issue. Does this make issue more clear?

In reply to: 403991798 [](ancestors = 403991798)


Milestone 3

In the third milestone,  you will complete the last sections of the website.
- In the magazine and Editor’s pick
- Newspaper main sections
- Subscribe / Newsletter

@SajjadAhmad14 thank you for your comments and suggestions. They helped us to clean the code and see some missing things we had.
We correct all your suggestions:

Remove horizontal scroll.
Use Semantic HTML tags in the footer and sections needed.
Remove !important rule in CSS file.

@mricanho thanks for your suggestion. We did the change you suggested:

Delete empty spaces in the code.


Cmd + Tab does not work when kwm is running

Hello @koekeishiya,
thanks for this nice tool, it seems really promising!
I just started playing around with it and noticed that Cmd + Tab does not behave as usual while kwm is running, do you have any idea why?
Thanks and please keep up the good work!

I purposely disabled it in hotkeys.cpp, apparently I have forgotten to mention that.
If you open hotkeys.cpp and remove the "case kVK_Tab:" block, it should work again.

Oh I see, thank you!


Replace rand() and sample() use of MT

As per discussion on the Julia lang Slack, the Mersenne Twister rng needs to be replaced with (possibly) Xorshift

Addressed with commits https://github.com/pdimens/PopGen.jl/commit/a9970f761303dffe1241503e1fa59f0c2fc90e8a and https://github.com/pdimens/PopGen.jl/commit/a6775b729b94755005412f150659f4e4b091c808


Idn working 4merge

This pull request is for merging IDN SAKERNAS into the main branch. GLD and country details are complete. I deleted other countries' folders. Let me know if you have any questions.

@gronert-m Hi Mario, I have updated country details fully according to the changes we agreed on during last meeting. These changes are now ready for your review. One thing to be noted is that although I have put administrative division crosswalk and the Guide into the utilities folder, I have not linked them to the text yet as we have not received any response from the Indonesian team upon their approval.

I have finished all editing and checking work! Updates include:

changing the LFP graph to its newest version.
splitting geographic significance level to a separate document.
adding industry and occupation mapping methodology and the correspondence tables created.
rewriting correspondences between national and international classifications section in the main intro.

There was a set of conflicts and I needed to add a small change to the Manual so this pull request is dealt with in #266
Thanks for everything! 👍 :)


Added an option to analyse a small sample of frames to create a single colour palette for the whole gif

I extended Moments for my own project, and I thought other people might find these changes useful, as I get more stable colours and substantially faster encoding time now.
What Moments does now:
The existing version of Moments creates a new colour palette for every frame in a gif. NeuQuant is computationally expensive, so this makes encoding slow and, more importantly, it can result in "flickering" colours every frame when the NeuQuant operation quantises the colors slightly differently with a moving camera or changing colors on the screen.
What my additions do:
My fork gives Moments the ability to sample several frames from a gif, analyze those frames together with NeuQuant, and create a single color palette that every frame will map to, without further NeuQuant calls.
I've added a "Frames Per Color Sample" field to the inspector, which allows you to sample every n-th frame in a recording for color mapping purposes. If the "Frames Per Color Sample" is set to zero, Moments reverts to its current default behaviour of creating a brand new color palette every frame.
The results:
By setting "Frames Per Color Sample" to 6, for instance, I halved the encoding time for my 5.5 second gifs on Windows and I get rock-solid colours for the duration of my gif, without the frame-by-frame flickering I experienced previously.
BEFORE: (please note the flickering pinks and purples on some objects)

AFTER:

Whoa not sure how I missed this PR. That's a very nice addition, thanks for taking the time to implement it. I think the PR is missing a file though? See the inline comment.


Wrong filter Values in category

Bug report
Wrong Filter Values(Brand attribute) in categories
Even if a particular brand is not selected for a category it is shown on that category filter.
Issue Description
Create a brand value from the admin panel and associate it with a category but this brand will also be shown in all the other categories filter where it is not associated. e.g if I created a brand value as condom brand name like(skore,durex. etc) it is showing in the condoms filter which is correct but it is showing in the filter of  sanitary pads categoriy even without association which is absolutely wrong
Preconditions
Please provide detailed information about your environment as possible.
1. framework Version I am using is 1.2.0.
2. Commit id.

Steps to reproduce
Create a brand value from the admin panel and associate them with any desired category and channel
Expected result
It must shown on filters with associated categories only
Actual result

Instead it is showing on every single category whether it is associated with this attribute value or not. To support my argument please find the screenshot of the category where these attribute values are not associated.

@jyoti-webkul @shubhwebkul @asif-webkul @bhanu-webkul Any help will be appreciated.

@rockgold22
please check now, this is resolved in the master branch.
So closing this, feel free to reopen anytime if still exist.

@vaishaliwebkul how will i get in my existing website , in past you have told me to upgrade my composer.jsoon to latest version but i already have 1.2.0(which is the latest version itself) so to what version i have to upgrade my composer.json

Hi @vaishaliwebkul ,  I have upgraded my bagisto version to the latest as per the documentation. Surprise, I am seeing new error on the front end as well as in the backend. Can you quickly check and let us know the solution to this issue?

hi, @vaishaliwebkul  can you please help with the above issue faced by @rahulanand77  since I am also facing the same issue after updating my existing site on the localhost.

@rahulanand77 @rockgold22
it seems the migration command is not executed successfully so you both are getting this issue.


boolean evaluation with non-comparable types has an odd return type

This seems buggy to me
In [1]: df = DataFrame([['Alice', 100, 1],
   ...:                 ['Bob', 200, 2],
   ...:                 ['Alice', 50, 3]], columns=['name', 'amount', 'id'])

In [2]: from blaze import *

In [3]: t = Data(df)

In [4]: t
Out[4]:
    name  amount  id
0  Alice     100   1
1    Bob     200   2
2  Alice      50   3

# this should raise TypeError or at the very least return a blaze expression
In [5]: t.id=='foo'
Out[5]: False

In [6]: t.id==3
Out[6]:
      id
0  False
1  False
2   True

In [7]: type(t.id==3)
Out[7]: blaze.expr.arithmetic.Eq

In [8]: type(t.id=='foo')
Out[8]: bool

Should definitely be a TypeError


New BearingElement classes based on neural networks

Related to the discussion #687.

The file called random_sampler.py from ross-ml is causing this errors. It is not relevant to the package and will be removed. Then, a new release should be deployed to PyPI.

I'm canceling this PR to move these new classes to ROSSML, as it has been spoken in Issue #687.


Add e2e test for syncsets

Add e2e test for syncsets.
According to Cesar's detail and helpful review comments, add watch of object deletion, standard coding style, and fix issues Cesar found.
there exists needed ginkgo package in go.sum, so this PR doesn't change go.sum file.

@csrwng Modified done. It's taking up your time again, I want to say sorry , and thanks a million.

@lwan-wanglin this looks really good, thx!
/lgtm
(it won't merge until merging is re-enabled on master tomorrow)

Great work Lin, thanks!
On Mon., Apr. 27, 2020, 10:40 p.m. OpenShift Bot<EMAIL_ADDRESS>wrote:

/retest
Please review the full test history
https://prow.svc.ci.openshift.org/pr-history/?org=openshift&repo=hive&pr=956
for this PR and help us cut down flakes.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/openshift/hive/pull/956#issuecomment-620326137, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AAAMQQNKZPAWULJV6OLL4CDROYXZ7ANCNFSM4MRGPYOQ
.


Added GANs in Action Book

Hey, me and my co-author are writing a book that could (hopefully) help many people who are interested in learning about GANs!
Let me know what you think!

Hi, the book seems really interesting. I will merge this PR as soon as the whole book becomes available from the link above.


pyi files missing from wheels

Thanks a lot for including the stubs in the 1.2 release!
Unfortunately, they appear to be missing in the binary distributions/wheels.
Could they be added for a future release?

Sorry for the missing file. Where does the ide expect the file. We need to add it to the data_files section in setup.py.
I'd be happy to accept a PR for this.
On December 30, 2020 2:11:21 PM UTC, Michi<EMAIL_ADDRESS>wrote:

Thanks a lot for including the stubs in the 1.2 release!
Unfortunately, they appear to be missing in the binary
distributions/wheels.
Could they be added for a future release?
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/jpype-project/jpype/issues/915

--
Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.

The .pyi files should just be next to the .py files, where they also are in the repository.


docs: add new items and pricing/cps

closes #1
this pr adds new items for the econode store. they are based on the (albeit kinda small) list posted in #1 with my own prices and cps values. note that this is labeled as a proposal; i would like some feedback on the values and if they should be increased, decreased, whatever.

LGTM, exponential but not too much


Adjusts http to listen on non 80 port

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

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

Totals

Change from base Build<PHONE_NUMBER>:
0.0%

Covered Lines:
0

Relevant Lines:
0

💛  - Coveralls


Reuse of CTR initial counter value

First: love your little utility!
Second: it seems that the the code uses the default value (=1) for the initial counter value for CTR mode for each and every key and encrypted message, which is ... kind of ok.
Reusing the same initial counter value with the same key is bad, but credstash seems to use a new unique key for each encrypted secret it stores. That particular usage pattern doesn't introduce any vulnerability for the same counter value.
However, any possible future changes of credstash or other possible applications that would use the encrypted secrets in DDB, which would use the same key to encrypt another secret, would have to change that practice and should use a different initial counter values.
Furthermore, any audit of the code will have security engineers cringe and they will have to spend additional effort to ensure that keys and counter values are not reused together.
Looking at the code, it feels that the changes to initialize the counter with a random value, and to store that value with the meta-data in the DDB-record, would not change the code significantly. This could even be implemented in a backwards compatible way (no record value for the initial counter value would default the value to 1).
Are you open to change the code to accommodate unique random initial counter values per key and per encrypted secret?

As you said, credstash generates a new data encryption key for every secret (and every version of every secret), so it's never actually reusing counter/key combinations, which is why it's safe to use use the same counter every time.
That said, you raise a really good point about having to explain that to auditors, or someone in the future not realizing that they need to not ever reuse that key and doing something risky.
I'm happy to just randomize the ctr and stick that in the record on a future change, or accept a PR that does the same.
Thanks!


Make application form visually good and connected to Google sheets

Is your feature request related to a problem? Please describe.
A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]
Describe the solution you'd like
A clear and concise description of what you want to happen.
Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.
Additional context
Add any other context or screenshots about the feature request here.

What will be benefits of connecting a Google Sheet?

The data will be more organized it will be easy to manage the data .
Multiple users will be able to edit the data. In real time

The data will be more organized it will be easy to manage the data .
Multiple users will be able to edit the data. In real time
On Sat, 11 May, 2024, 9:27 pm Aman Yadav, @.***> wrote:

What will be benefits of connecting a Google Sheet?
—
Reply to this email directly, view it on GitHub
https://github.com/Its-Aman-Yadav/Community-Site/issues/92#issuecomment-2105939556,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/BDTDDF7MESQD6QJZ3AOCLVDZBY5VBAVCNFSM6AAAAABHR75XYSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCMBVHEZTSNJVGY
.
You are receiving this because you authored the thread.Message ID:
@.***>

Please assign this issue to me @Riyasharma28 under GSSoC'24.


Hard-coded “(Press escape to close)” in dialog title aria-label (l10n)

There is a “(Press escape to close)” appended to the dialog title aria-label that can't be overridden through the accessible_title or the localization options added in https://github.com/humaan/Modaal/issues/41.
https://github.com/humaan/Modaal/blob/master/source/js/modaal.js#L358

Thanks @mirka good pickup.

This has been been addressed. The relevant hard coded text has been replaced with the close_aria_label option value so users who wish to overwrite it along with the close button label, can do so.
This will be rolled out in the next milestone release


alternatives/blas: fix ILP64 check

Motivation for this change
This bug fix allows for MKL ILP64 builds. The deleted line served as a valid check for Openblas builds, but prevented MKL ILP64 builds (it was quietly built for LP64 even when ILP64 was request in the input).
CC @matthewbauer
Things done

Built on platform(s)

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

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
[ ] Tested execution of all binary files (usually in ./result/bin/)
21.11 Release Notes (or backporting 21.05 Release notes)

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

[x] Fits CONTRIBUTING.md.

@GrahamcOfBorg eval


Thank you

No bug! Just dropping this issue to say "thanks" — I found the various threads where @squidfunk (understandably) wasn't able to support ARM64 and saw you volunteered to do this unofficially. It saved me a lot of time today :)

Thanks a lot for the kind words! Glad I could help.


Adding placeholders for instance sharing related functions in K8sPlatformManager

This PR addresses NGPBUG-78199.
With https://github.com/cloudfoundry-incubator/service-fabrik-broker/pull/528/ and https://github.com/cloudfoundry-incubator/service-fabrik-broker/pull/570, instance sharing feature was introduced for director and docker instances. However, corresponding implementation was not added for requests originating from kubernetes platform, leading to failure in such bind requests.
This PR provides a temporary fix for this by adding corresponding placeholders in K8sPlatformManager.

Pull Request Test Coverage Report for Build 2746

4 of 4 (100.0%)  changed or added relevant lines in 1 file are covered.
No unchanged relevant lines lost coverage.
Overall coverage increased (+0.02%) to 90.039%

Totals

Change from base Build 2743:
0.02%

Covered Lines:
8776

Relevant Lines:
9424

💛  - Coveralls

@jayeshjk have you tested this for k8s both below cases:

bosh service - i. bind ii. unbind
docker service - i. bind ii. unbind

@ketakig12 , yep all the four cases have been tested on aws-staging with request having context.platform: 'kubernetes'.


Porting to boto3 and explicitly sending AllowReassociation=False

Addressing the discussion at #24

Thank you for the contribution @wilerson. I'll review it in the next couple of days.


Update auto-generated documentation

Repository: openmicroscopy/ome-documentation
Already up-to-date.
Generated by build OMERO-DEV-latest-docs-autogen#412.

--no-rebase

Merge build green with this included, merging for release.


Improve debuggability of custom chain flush/delete

These failures were previously ignored, but that hides error codes that
might be useful for debugging. Add warning messages for these commands
too.

This change is

test-me-please

Coverage decreased (-0.03%) to 44.08% when pulling a6b3c575af70a99ca2afce27668afdd254d393b9 on joestringer:submit/improve-iptables-debugging into d5235e3c2f0ad26517db6ea8956dee3b8fa88f42 on cilium:master.


Order links in web UI

Links are ordered arbitrarily in the web UI, and it annoys me.
I think the panel should order alphabetically by link
The JSON of the response could be ordered instead

Closed with added sorting code in https://github.com/KeyValueSystems/SimpleShortener/commit/53f1ffa3fc8e5d5fabbb2779b58d7ad2f70abea7


Keyboard Manager does not take effect after reboot

Microsoft PowerToys version
0.68.0
Installation method
GitHub
Running as admin
Yes
Area(s) with issue?
Keyboard Manager
Steps to reproduce
Use an external wireless keyboard, mine is MX Keys mini for Mac.

Mapping Win to Alt, Alt to Win
Reboot the computer
Keyboard can not be mapped successfully, need to switch keyboard manager again.

✔ Expected Behavior
Turning on computer keyboard mapping still works.
❌ Actual Behavior
When turning the computer back on, I need to disable or enable the keyboard manager in order to map it successfully.
Other Software
No response

Are you still experiencing this issue? /needinfo


perlPackages.HTTPDaemon: 6.01 -> 6.14, patch for CVE-2022-3108

Description of changes

Update perlPackages.HTTPDaemon to 6.14
Patches for CVE-2022-3108:

https://github.com/libwww-perl/HTTP-Daemon/commit/331d5c1d1f0e48e6b57ef738c2a8509b1eb53376 (prerequisite)
https://github.com/libwww-perl/HTTP-Daemon/commit/e84475de51d6fd7b29354a997413472a99db70b2
https://github.com/libwww-perl/HTTP-Daemon/commit/8dc5269d59e2d5d9eb1647d82c449ccd880f7fd0

Patches not included:

https://github.com/libwww-perl/HTTP-Daemon/commit/faebad54455c2c2919e234202362570925fb99d1 (due to https://github.com/libwww-perl/HTTP-Daemon/issues/57)

Upstream issue: https://github.com/libwww-perl/HTTP-Daemon/issues/56
Things done

Built on platform(s)

[X] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

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

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

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

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module
[ ] (Release notes changes) Ran nixos/doc/manual/md-to-db.sh to update generated release notes

[ ] Fits CONTRIBUTING.md.

@GrahamcOfBorg build perlPackages.HTTPDaemon

If you give the patches a name that includes the CVE id it usually allows tools like vulnix to automatically consider them as fixed.


Next Permutation

Description
Algorithm to generate Next Permutation of a number
Domain
Algorithm
Type of Contribution
Addition
Code of Conduct

[X] I follow Contributing Guidelines & Code of conduct of LearnCPP.

@Lakhankumawat
i would like to work on it under Gssoc22

Only one issue can be assigned to one contributor at a time you have made two issues .

either close this one or existing one

Only one issue can be assigned to one contributor at a time you have made two issues .
@Lakhankumawat
i didn't know that so created many issue. now what to do ?

I'll help you close them .


WIP: Added logic to check extra contraints

Added logic to check extra constraints and show error messages for them.

Since the list of constraints is based on types that do not exist in Brooklyn, an impromevent of this would be to actually add those types in Brooklyn.
Transforming this bit of code into an extension and moving it to the dependent project looks like a pain to me, however if desired I am sure it is possible.

Cheers!

Added logic to check extra constraints and show error messages for them.

Since the list of constraints is based on types that do not exist in Brooklyn, an impromevent of this would be to actually add those types in Brooklyn.
Transforming this bit of code into an extension and moving it to the dependent project looks like a pain to me, however if desired I am sure it is possible.

Cheers!

We should consider moving implementation of constraints into Brooklyn core.

We should consider moving implementation of constraints into Brooklyn core (did not mean to close this PR).

@geomacy Thank you for your input. We will be parking this until further notice.


Docs: 9/22 weekly digest [draft]

Updating Gestalt digest (two last weeks)
Thanks for creating a PR! Please follow this template and delete items/sections that are not relevant to your changes, including these instructions.
Please also make sure your PR title matches our format: {ComponentName}: Description (mentioning platform if relevant), or {ComponentName}, {OtherComponentName}: Description (mentioning platform if relevant) if multiple components are affected.
Summary
Gestalt digest (blog post json file) update
What changed?
We added the latest updates from Gestalt regarding the two last weeks (September 11-22)
Why?
This is a weekly or a bi-weekly team process.
Links

[TDD](not applicable)
Figma

Checklist

[ ] Added unit and Flow Tests
[ ] Added documentation + accessibility tests
[ ] Verified accessibility: keyboard & screen reader interaction
[ ] Checked dark mode, responsiveness, and right-to-left support
[ ] Checked stakeholder feedback (e.g. Gestalt designers)

@rlingineni hello! I think now it is ready to merge. Please review it when you get a chance <3  Ty!


Rewrite on Telethon, add quoting

Add quoting to .py and .code commands, because it`s useful to select some piece of text (code) and run it


clarify use of env vars for self-signed certs in http remotes

removed the ssl_verify flag mention as well
From https://github.com/iterative/dvc.org/pull/2116#discussion_r567695284

Thanks @skshetry !!


create initial project governance docs

The files in this pull request should act as examples of how other HoloViz projects could quickly adopt the default project docs using references to the project docs at holoviz/holoviz.
The maintainer list is based on the HoloViz Duties spreadsheet. All three maintainers should participate and/or approve.
I'll mention this at the next docs meeting, but I've written the guidance to create project docs. I'll update this if there are any further changes to this PR.

Looks good to me!

Should we maybe have a tag like param-governance on the holoviz repo, so that these documents could point to that tag as an unambiguous version, but then we could move that tag whenever we wanted to inherit the new changes from holoviz?

A tag is a good idea though if we want to point to a different version for different projects then yes, we will need a <project>-governance tag for every project. Still probably better than pointing to an obscure SHA.

Should we maybe have a tag like param-governance on the holoviz repo, so that these documents could point to that tag as an unambiguous version, but then we could move that tag whenever we wanted to inherit the new changes from holoviz?

I've never done something like this, but I assume that in order to use a consistent param-gov-tagged link like https://github.com/holoviz/holoviz/blob/param-gov/file.md (not a real link) which starts on commit 'A',  then when it is time to update the param-gov tag to a more recently committed version of this document, commit 'B', then someone with merge permissions for holoviz/holoviz repo would have to first delete the tag from the commit 'A' and then push the tag to 'commit B'.
I'm not a maintainer for param so don't consider this a blocker, but I'm not sure I agree with this approach since the history of such a reference update would not live within the Param repo. Alternatively, an update to the SHA links would just be a matter of updating 4 such links and the history would be a pull request within the Param repo (and I imagine that this would happen pretty rarely)

Moving a git tag should be straightforward for any holoviz maintainer.
We're already depending on an external repo, because the explicit sha being referenced currently has no meaning outside of the external repo. It's true that it's not difficult to replace the sha in four files, but it is difficult to know how many files, and which ones, need to be updated. Each time we need to do that there will be an investigation where we find an original PR like this or grep the repo for that sha or something of the like, all to make a trivial change.
I do agree that it's helpful to have a history of the governance versions, and moving a tag doesn't immediately provide such a history, which is a downside. But as we indeed don't expect many changes to the governance, and generally look forward rather than backward, I'd favor having it be straightforward and obvious how to update to the latest version from holoviz, rather than optimizing for preserving past links. Other maintainers, please weigh in if you disagree or have a better suggestion, and not just for Param but for other HoloViz projects, as it would be best to handle them all similarly by default.

param-gov tag has been created and updated the links in this PR and the instructions on the google doc linked in the description at the top. I'll merge now


Microsoft.WinGet.Client throws System.InvalidOperationException: Attempt to update previously set global instance

Microsoft.WinGet.Client throws System.InvalidOperationException:“Attempt to update previously set global instance.” when used in winget configure with a resource from Microsoft.WinGet.DSC
This is because the custom AssemblyLoadContext implemented by the client module loads WinRT.Runtime.dll into the same processes where the configuration server already have WinRT.Runtime.dll loaded. When there are multiple versions of WinRT.Runtime.dll loaded in process this exception gets thrown. More info
The fix is to always load WinRT.Runtime.dll into the default assembly context, if its not loaded by the time our handler is executed and always return null in the Load implementation of the custom ALC.
This is a problem any PowerShell module that uses cswinrt will have (if there's another one out there)
Microsoft Reviewers: Open in CodeFlow

/azp run

/azp run


545408B2 - WWE 2k14

Marketplace
Tested on https://github.com/xenia-canary/xenia-canary/commit/5cb86f7173bef8af18c6f1f99e337a1f804a77f7
Issues:
Game crashes while starting Kick-off match.
In 30 years of Wrestlemania mode in first match while entrance screen gets black, but sound is working and then again getting same error.
Frame drops and sound flickering is happening.
Game is working fine in Streak Mode and I'm able to play matches with 30 to 45 FPS.
Royal Rumble match is working for me with 60 FPS and only frame drops in some camera cuts while finishers
Tried dlc but didn't worked.First it was showing an error that your save can't be loaded due to incorrect dlc but i came to know that all files was not extracted but after then i extracted full dlc in content folder with correct steps and done a title update after then game successfully loads but dlc is not working.
Log:
Kick-Off Match
xenia.zip
30 Years Of Wrestlemania
xenia.zip
The Streak Mode
xenia.zip
Screenshot(s):
Kick-Off

30 Years of Wrestlemania

The Streak Mode

Labels:
state-gameplay

should this also have a crash label?

Now. Is works this game with Xenia / Canary?

Tested on xenia-canary/xenia-canary@dc29307
Using the following special configs:
gpu = "vulkan"
gpu_allow_invalid_fetch_constants = true
ignore_offset_for_ranged_allocations: true
Some wrestlers will be invisible during their entrance and during their victory sequence. It does not affect every wrestler, I've not been able to figure out what it is about certain wrestlers that makes them invisible while others display fine. In the below screenshot you can see the shadow of where the wrestler's feet should be.

Tested on xenia-canary/xenia-canary@dc29307
Using the following special configs: gpu = "vulkan" gpu_allow_invalid_fetch_constants = true ignore_offset_for_ranged_allocations: true
Some wrestlers will be invisible during their entrance and during their victory sequence. It does not affect every wrestler, I've not been able to figure out what it is about certain wrestlers that makes them invisible while others display fine. In the below screenshot you can see the shadow of where the wrestler's feet should be.

ty so much bro game works perfectly. I really appreciated, much love.

Tested on xenia-canary/xenia-canary@dc29307
Using the following special configs: gpu = "vulkan" gpu_allow_invalid_fetch_constants = true ignore_offset_for_ranged_allocations: true
Some wrestlers will be invisible during their entrance and during their victory sequence. It does not affect every wrestler, I've not been able to figure out what it is about certain wrestlers that makes them invisible while others display fine. In the below screenshot you can see the shadow of where the wrestler's feet should be.

In my case, the game was working in some sort of slow-motion and I fixed it by doing what you have done plus setting framerate_limit = 0.


PropertyGraphIndex

This PR introduces a new index type: ProeprtyGraphIndex
Along with this PR, we have

new PropertyGraphStore storage layer
new PropertyGraphIndex
new property graph index retriever
sub-retrievers for property graphs (mix and match whatever you need)
kg_extractors for extracting nodes and relationships from text
extensive docs and examples
(some) unit tests

@BeautyyuYanli hmm, is it possible to make the schema more generic? How specific does it have to be?
For example, the most generic I can think of
Entity has name: str, id: str, type: str, and properties: dict (properties could even be a json string to simplify?)
Relation has type: str, id: str, properties: dict
Chunk has text: str, id: str, type: str, and properties: dict
There's no way to generically define a schema around that?

Thanks for suggestion. We are tring to implement a more generic schema