Assertion functions don't work when defined as methods

TypeScript Version:
3.9.0-dev.20200220
Search Terms:
assertion signature
Code
type Constructor<T> = new (...args: any[]) => T

let str: any = 'foo'

str.toUpperCase() // str is any

function assert(condition: unknown, message: string = 'Assertion failure', ErrorConstructor: Constructor<Error> = AssertionError): asserts condition {
    if(!condition) {
        throw new ErrorConstructor(message);
    }
}

assert(typeof str == 'string')

str.toUpperCase() // str is string

class AssertionError extends Error { }

class Assertion {
    assert(condition: unknown, message: string = 'Assertion failure', ErrorConstructor: Constructor<Error> = AssertionError): asserts condition {
        if(condition) {
            throw new ErrorConstructor(message);
        }
    }
}

let azzert = new Assertion().assert

let str2: any = 'bar'

azzert(typeof str2 == 'string')  //error 2775

str2.toUpperCase() // str2 is any

Expected behavior:
Assertion functions are usable as methods of a class
Actual behavior:
Assertions require every name in the call target to be declared with an explicit type annotation.(2775)
'azzert' needs an explicit type annotation.
Playground Link:
https://www.typescriptlang.org/play/?ts=3.9.0-dev.20200220&ssl=1&ssc=1&pln=33&pc=34#code/C4TwDgpgBAwg9gOwM7AE4FcDGw6oDwAqAfFALxQIQDuUAFAHSMCGqA5kgFxRMIgDaAXQCUZEgQCwAKCkAbCMCgpUXHiDJQA5ADM4cDVKlL6OAKphIqGEyQRaIgPT3FaKAEsk3Xgclb0CbK6I3Eg2qMC0mIgAJq7AgQhcfgDWCHBUCAA0UAC2ECFMrBBcSq4IrOoaAIIhEGHxUFpMrjLoqBAaWQCiqKi48MhoWDjKsIhKQ7h43b2oJOTVoXGI07hCKjVhHpEIMUsIUADeUlAnblq0AITbu-EiR5Knj1DAABa9NJQ0K5Zjg9i4tFy+UKQgA3MdTgBfKTQ6SSayLWigSBwLTOVBkcgaEplDRCbxGUzmWpWGx2KCOdFuDw41jeTAyBFQBa1PbfKAQAAewAgOw87IOUFhUgZTJZdSC90eCNZEWisXiiQQKTSmRyeSQBSK6NK5Sx4r2DSaLTaHSg33643+I0tf2GUx6uDmzI2bMdqDWwUWW3lhqlTxOrnO1wViDuEIDj1e7wo1HN7ttGGtgI1WrBEaesMesOFkjkCiYAC9C6z1J8XYt4nZ6DKwt58+iAEwqXgVABGLH0cKLJbCSPAEFRTcxmlpeIp9lqMygjYA7LOAKwEtCN4xwMwWUm2BxOJSN6meEBAA
Related Issues:
Perhaps this a design limitation per the following PR?
https://github.com/microsoft/TypeScript/pull/33622
https://github.com/microsoft/TypeScript/pull/33622#issuecomment-575301357

Assertion functions always need explicit annotations. You can write this:
let azzert: Assertion['assert'] = new Assertion().assert;

@RyanCavanaugh Can you explain in a little more detail? I don't understand how to resolve the issue.
This also is failing with the same error:
import * as assert from "assert";
export function exists(value: unknown): asserts value {
  assert(value);
}

export default {
  exists
};

Using:
import assert from "./assert";

assert.exists(true); // error ts(2775)

How does the exists function not have an explicit annotation? Or what can I do to resolve it in this case.
If I just export the function as non-default and do the import as import { exists } from "./assert" then it works but I'd like to have them grouped on the object assert.xyz.

I am also seeing error ts(2775) when using require instead of import
Following has error:
const assert = require('assert')

Following has no error
import assert from 'assert'

@justinmchase , @amber-pli
Create a let/const/var and assign it the assert function you imported. Give that variable an explicit type like in the example provided by @RyanCavanaugh .

I guess whats confusing me is that he said:

Assertion functions always need explicit annotations

But I believe in my code the function does have an explicit type annotation, yet its not working. Are we saying there is a bug and that the variable assigned to the function needs the explicit variable?

@justinmchase The type needs to be explicit, it's not a bug
https://github.com/microsoft/TypeScript/issues/34523
https://github.com/microsoft/TypeScript/issues/34596

Ok, one last time, I swear I'm not being intentionally obtuse but I think I'm homing in.
I think my confusion is because, to my understanding, this function has an explicit type:
export function exists(value: unknown): asserts value {
  assert(value);
}

So when you say the type needs to be explicit its boggling my mind because I don't get how it couldn't be explicit.
But now, I'm wondering if you don't mean the function's type but the type of the argument needs to be explicit? As in the value: unknown is the issue? It needs to be non-generic and not something such as any or unknown? Is that what you mean?

@justinmchase explicitly give it a type where you imported it.

@justinmchase I think the part that is boggling your mind is that the message isn't clear about what exactly doesn't have an explicit type.  You quoted this code, which clearly does have an explicit type:
export function exists(value: unknown): asserts value {
  assert(value);
}

But when you used it, you imported it like this:
import assert from "./assert";

assert.exists(true); // error ts(2775)

The 2775 error you are getting on that line is not about exists needing an explicit type, it's about assert needing one.  You can verify this by importing exists directly:
import { exists } from "./assert";
exists( true ); // works without the error.

So the error isn't telling you about problems with exists, it's telling you that your default export needs to be explicitly typed:
const defaults: {
  exists( value: unknown ): asserts value;
} = {
  exists,
};

export default defaults;

It isn't entirely clear to me why that is the case, and it seems that making the error message clearer about where exactly the problem lies was discussed and rejected.
What I have found can work to avoid having to repeat the typings twice is to move the actual assertion functions into a separate file and then re-export them:
export * from './real-assertions';
import * as assertions from './real-assertions';
export default assertions;

I'm also not entirely clear on why this works, but it seems like it does..

Ok thanks, I'll try it out!
It does seem like there is a bug in here but I'll settle for work arounds for now.

As a prime example where you would expect this to work, but it doesn't—in a way that seems to me at least to pretty clearly be a bug—is namespaces.
For backwards compatibility, Ember's types have both modern module imports and re-exports from the Ember namespace. So we have:
export function assert(desc: string): never;
export function assert(desc: string, test: unknown): asserts test;

import { assert } from '@ember/debug';
assert('this works', typeof 'hello' === 'string');

And we also re-export that on the Ember namespace, with a re-export like this:
import * as EmberDebugNs from '@ember/debug';

export namespace Ember {
    // ...
    const assert: typeof EmberDebugNs.assert;
    // ...
}

const { assert } = Ember;
assert('this FAILS', typeof 'hello' === 'string');

'assert' needs an explicit type annotation.

I understand the constraints as specified, and I'm afraid I must disagree with the team's conclusion about this error message—

We discussed in the team room and agreed that the existing message is fine, so I didn't change it.

—seeing as it took me about half an hour to finally find my way to this thread and understand the problem, and another half an hour to figure out how to rewrite our DefinitelyTyped tests to continue handling this! 😅
For the record, if anyone else is curious, this is how I'm ending up working around it for the types PR I'll be pushing up shortly:
const assertDescOnly: (desc: string) => never = Ember.assert;
const assertFull: (desc: string, test: unknown) => asserts test = Ember.assert;

(I'm also going to have to document that or be ready to explain it, though gladly basically none of our TS users are likely to be doing this.)

I tried to include an assertion function as part of the exports for an inner module in one of my libraries and was heartbroken to find that, while I could use it perfectly within the module, I could not use it when referencing it from outside via the module namespace. @RyanCavanaugh's answer was a godsend!! Thank you so much!
Here's what I was doing:
Project1::src/Http.ts
export function assertThing(thing: any): asserts thing is string {
  // ...
}

Project1::src/index.ts
import * as Http from "./Http";
// ....
export { Http, /* .... and other things .... */ }

Project2::src/Functions.ts
import { Http } from "project1";

export const handler = (thing: any) => {
  Http.assertThing(thing);
  // ....
}

I was getting the error in the original post because of this, and I couldn't get past it. I successfully utilized Ryan's solution by doing this:
Project2::src/Functions.ts
import { Http } from "project1";

const assertThing: (typeof Http)["assertThing"] = Http.assertThing;

export const handler = (thing: any) => {
  assertThing(thing);
  // ....
}

While a little awkward, this is a total life-saver and has allowed me to successfully use this wonderful assertion functionality without limitation. (Note that it was necessary to use the (typeof Http) notation because typescript complained that namespaces can't be used as types.)
Anyway, just wanted to add this for anyone who may be struggling with something similar. Thanks again for the tip, @RyanCavanaugh!

For what it's worth this has made the Assert library usable again when checking JavaScript with Typescript.
const Assert = /** @type {typeof import('assert')} */(require('assert'))

All the type errors reported about non-explicit types are gone (thankfully).

I'm using Typescript 4.1.5 and it baffles me that this error even exists and that the message is so cryptic you have no idea what's going on.
Here is a sample code:
class StringEnum<T extends string> {
	public constructor(
		private readonly values: readonly T[],
	) { }

	public is(value: string): value is T {
		return (this.values as readonly string[]).includes(value);
	}

	public assert(value: string): asserts value is T {
		if (!this.is(value)) {
			throw new Error('invalid string enum variant');
		}
	}
}

const MyEnum = new StringEnum([
	'sample1',
]);

const value = 'sample1';

if (MyEnum.is(value)) { } // works

MyEnum.assert(value); // error

TS Playground
From my understanding, the signature of MyEnum.assert should be (this: StringEnum<'sample1'>, value: string) => asserts value is 'sample1' and that should be enough for the control flow analysis to know that after its call value should be a valid variant.
Also, the fact that .is(value) works and .assert(value) doesn't adds to the confusion.
Since this is a design limitation, it should be forbidden to use asserts in methods in the first place.

The error goes away if you're explicit:
const MyEnum: StringEnum<string> = new StringEnum([
	'sample1',
]);

Unfortunately that defeats the purpose of the generic argument, which is to keep the valid variant types around.

Now I'm pretty sure #34596 is about this exact problem too.

Not only will they not work as methods, but having a (your) custom function defined as an expression/assignment instead of a function declaration seems to be a big no-no. Not sure why the difference but I did spend a couple hours pulling my hair out wondering why my code/types suddenly stopped working all of the sudden.
For example this works:
`function addHighLevelCommands<
A, //extends { [key: string]: { cmd: any } },
B

(attach: A, attachTo: B): asserts attachTo is typeof attachTo & typeof attach {
//{ [k in keyof A]: A[k]["cmd"] } {
Object.assign(attachTo, attach);
}`

but this doesn't (and throws the "must declare explicit type annotations" error when called):
`const addHighLevelCommands = function<
A, //extends { [key: string]: { cmd: any } },
B

(attach: A, attachTo: B): asserts attachTo is typeof attachTo & typeof attach {
//{ [k in keyof A]: A[k]["cmd"] } {
Object.assign(attachTo, attach);
}`

You can see where I commented out part of the ts code in my attempts at debugging and trying to get it to work. Just thought I'd share my experience but I apologize if this is due to any ignorance on my part. As you can tell I'm having some fun with morphing? types but I'm wondering if these changing/changed/resultant types would ultimately show up in a .d.ts file that I could print out and utilized for self-documenting an API?

this is working for me:
import assertMod, { fail, ok, strictEqual, deepStrictEqual, notDeepStrictEqual, throws, doesNotThrow, ifError, rejects, doesNotReject, strict } from "assert";

type AssertT = {
  fail: typeof fail,
  ok: typeof ok,
  strictEqual: typeof strictEqual,
  deepStrictEqual: typeof deepStrictEqual,
  notDeepStrictEqual: typeof notDeepStrictEqual,
  throws: typeof throws,
  doesNotThrow: typeof doesNotThrow,
  ifError: typeof ifError,
  rejects: typeof rejects,
  doesNotReject: typeof doesNotReject,
  strict: typeof strict,
} & ((value: boolean, message?: string) => void);

const assert: AssertT = assertMod;

now you can call without having ts(2775):
assert(false, "always throws");
assert.fail("always throws");

type AssertsIsOneOfType = <T extends ItemClass[]>(
  item: Item,
  types: T,
  prop: string
) => void;

const assertIsOneOfType: AssertsIsOneOfType = <T extends ItemClass[]>(
  item: Item,
  types: T,
  prop: string
): asserts item is Item & { className: T[number] } => {
  if (!types.some((type) => isOfType(item, type))) {
    throw new Error(`Cannot apply ${prop} to ${item.className}`);
  }
};

Do I really have to define all the types of this function twice just because I want to use a generic in my assertion?
If you don't const assertIsOneOfType: AssertsIsOneOfType like this then I get the:

Assertions require every name in the call target to be declared with an explicit type annotation.ts(2775)
issue. So I have to define the call signature twice?

With the goal of being able to write assert.exists(condition) - after much faffing about - I've found the following combinations of named exports, default exports, consts and functions to work. Maybe useful to future travellers...
// assert1.ts
export const exists1: (condition: any, message?: string) => asserts condition = (condition, message) => {
  if (!condition) throw new Error(message || 'An error occurred');
};

export function exists2(condition: any, message?: string): asserts condition {
  if (!condition) throw new Error(message || 'An error occurred');
}

// elsewhere
import * as assert1 from './assert1';

assert1.exists1(something);
assert1.exists2(something);

Or if you don't want to import *, this affront to humanity:
// assert2.ts
const exists1: (condition: any, message?: string) => asserts condition = (condition, message) => {
  if (!condition) throw new Error(message || 'An error occurred');
};

function exists2(condition: any, message?: string): asserts condition {
  if (!condition) throw new Error(message || 'An error occurred');
}

const myDefault: {exists1: typeof exists1; exists2: typeof exists2} = {exists1, exists2};

export default myDefault;

// elsewhere
import assert2 from './assert2';

assert2.exists1(something);
assert2.exists2(something);

With the default export approach, IntelliJ will do auto-imports properly.

What about instance functions that assert something about this? Are they also meant to result into errors?
class Device {
    id: string;
    settingsId?: string | null;

    assertHasSettings(): asserts this is {settingsId: string} & this {
        if (this.settingsId == null) {
            throw new Error(`Device with ID ${this.id}`
                + ` does not have individual settings`);
        }
    }
}

const device = new Device();
device.id = 'hello';
device.assertHasSettings();

TypeScript playground: https://www.typescriptlang.org/play?strictPropertyInitialization=false&ssl=15&ssc=28&pln=1&pc=1#code/MYGwhgzhAEAiCmA3Alse0DeAoavrIBMAuaCAFwCdkA7AcwG4c8J4yybaIBJAgfhPJU60AD7RqAVxAhGTXJBYUyACUgBlVuzoQAFAEoSC+EphkAFshiXMLNh27FSlDgF9oAMmjnr2PH-wAZtA63hAAdLZanDzQALyx4lIgephy-n7mFAD2AO7i8HkAohTZFDoABggoaNA5yObQXLDQACQYoWGELuVp6ekA1NDl0ARZ8DDUWWTQZmCI6DQEyCgEEmAgpJr25XqMfdAuaYeHWMBZ1OQjSKjoCdQFcNdo+owET-CdBHHQAORm8NIsj9Xu8wkYlKoIBo7NoXkA

Without being too repetitive, the following works for me:
type Assert = (condition: unknown, message?: string) => asserts condition;

const assert: Assert = (condition, message) => {
  if (!condition) {
    throw new Error(message);
  }
};

export default assert;

My use case when it breaks is with creating scoped 'logging' utility that adds prefix to save me keystrokes.
const scope = createScope("Foo");

scope.assert(false, "Nope"); // <— throws error `[Foo] Nope`
scope.log("hello"); // <— logs "[Foo] hello"
// etc.

Thus my asset in a way is a method and has to be.
But I cannot use that due to mentioned TS error:
scope.assert(false, "Foo"); // TS: Assertions require every name in the call target to be declared with an explicit type annotation.
// Same for
const { assert } = scope
assert(false, "Foo");
// or
const assert = scope;
assert(false, "Foo");

The only way to make it work is:
const assert: (input: unknown, message: string) => asserts input = scope.assert
assert(false, "Foo"); // TS does not complain and works

but doing it this way (explicitly having to assign type to assert totally misses the point which is my case was - make DX of writing debugging / assert messages easier)

I am also facing this issue any update when this bug will be resolved?

Just throwing in my two-cents because I got struck by this annoying and very unhelpful bug wording today..
My 'branding' string code.
export type DodiAttributeCodeType = string & { _type: 'DodiAttributeCode' };

/* Delcare type to get around TS Bug */
type DodiAttributeCode = {
  guard(str: string): str is DodiAttributeCodeType;
  parse(str: string): DodiAttributeCodeType;
  assert(str: string): asserts str is DodiAttributeCodeType;
};

export const DodiAttributeCode: DodiAttributeCode = {
  guard(str: string): str is DodiAttributeCodeType {
    return !!str; /* some complex test */
  },
  assert(str: string): asserts str is DodiAttributeCodeType {
    if (!DodiAttributeCode.guard(str)) {
      throw new Error();
    }
  },
  parse(str: string): DodiAttributeCodeType {
    DodiAttributeCode.assert(str);
    return str;
  },
};

import { DodiAttributeCode, DodiAttributeCodeType } from '@core/types/DodiAttributeCode';

const a = 'hello';
const b: DodiAttributeCode = a; // TS error 2322, string not valid
DodiAttributeCode.assert(a);
const c: DodiAttributeCode = a; // TS loves it.. Time to do real work now.

Assertion functions always need explicit annotations. You can write this:
let azzert: Assertion['assert'] = new Assertion().assert;

Thanks for the clear explanation, this is a strange behavior from typescript. Got stumped by this error today.

Really strange behavior
const value: unknown = 0

const foo = (value: unknown): asserts value is number => { }
foo(value) // error
value // unknown

const foo_: typeof foo = foo
foo_(value) // ok
value // number

const value: unknown = 0

const foo = {
    bar(value: unknown): asserts value is number { }
}
foo.bar(value) // error
value // unknown

const foo_: typeof foo = foo
foo_.bar(value) // ok
value // number

Also chiming in that I ran into this bug in 4.9.4. I am saddened to hear that the typescript devs believe that this behavior is somehow working as intended.

Fwiw, if t.assertSomething(val) reports that error, you can solve it by doing
const assertSomething: typeof t.assertSomething = t.assertSomething;

assertSomething(val);

so that assertSomething is explicitly annotated as having its own type.

While I can at least understand the decision to consider this working as intended, the error message you get only makes sense after you discover the solution to the problem, which is not an ideal trait in an error message.

I think everybody would prefer that asserts and is behave the same in the context of they definition. The current situation:
declare function makeStruct(): {
   assert(subj: unknown): asserts subj is string
   guard(subj: unknown): subj is string
}

const struct = makeStruct()

declare const subj: unknown

// ts-error:
// "Assertions require every name in the call target to be
//  declared with an explicit type annotation. 10:1:416 typescript2775"
struct.assert(subj)

// No such problem with `guard`
if (struct.guard(subj)) {
  subj // `string` as expected
}

The current restriction is highly unintuitive and reduces ts community ability to create nice assert method for schema dependent parsers/validators.
For example we could have assert method in zod library structs and typeguard unknown data like this:
import z from 'zod`

declare const subject: unknown

z.string().assert(subject)

subject // `string`

@RyanCavanaugh is there somewhere to view the 'completed' work?

The bulk "Close" action doesn't let you pick which "Close" you're doing.
Design Limitations aren't supposed to be left open - it means we're not aware of any plausible way to address them.


Master branch on readthedocs not up to date

As noted in #1790

@st--  a related problem may be that there is a problem building the Sphynx documentation locally. A few months ago I was able to build Sphynx documentation.

modified source/notebooks/theory/SGPR_notes.md
entered make html in doc and got two warnings:
WARNING: toctree contains reference to nonexisting document 'notebooks/intro_to_gpflow2'
WARNING: toctree contains reference to nonexisting document 'gpflow/index'
but the build was reported as succeded.
opened notebooks/theory/SGPR_notes.html with browser and the changes do not appear.


Cherry pick documentation updates (#62) to 6.2 release branch

Cherry pick of https://github.com/ROCm/rocPyDecode/pull/62

@ROCm/rocm-documentation


Inventory Channels Card Header Not Visible on UI When Created Without Description

Note
This is an introduced issue
Current behavior
Inventory Channels card header is not visible on UI when created without description
Expected behavior
The inventory channel card header should be visible in the UI list of inventory channels.
Steps to reproduce the issue
Navigate to the Inventory Channels section in the application.
Attempt to create a new inventory channel by filling in the required details.
Submit the form to create the channel.
Observe that the channel card header does not appear in the list of inventory channels.
Environment details
App version : v3.1.1
App environment : UAT
Additional information
https://jam.dev/c/e02ed2a3-3633-40b9-b06b-9cac201a2dc0

Issue verified and working fine in release v3.1.3. Hence, closing this issue.


Move websites to fastqe.github.io

Website content for fastqe.com currently in /docs
Move to fastqe.github.io for separation from code

Duplicate


Audio embedding

Hi, is it possible to embed audio with Quartz or do you have plans to implement this feature?

Sorry wrong button haha but this is possible! Haven't had much interest from people but this shouldn't be too bad to implement using a custom partial:
https://discourse.gohugo.io/t/playing-audio-files/21117
Will wait for people to make a bit more noise about it before making it an official feature though

Thanks for the link, but it doesn't work with t the shortcode suggested in this thread.
I've created a new direction "shortcodes" under layouts and in it the file "audio.html".
Any idea?

is the audio under the static folder?

Yes, but it doesn't work.
I've tried it in various versions like so:
{{< audio src="/static/audio/audio.mp3" class="something" >}}
{{< audio src="/audio/audio.mp3" class="something" >}}
{{< audio src="/audio/audio.mp3" class="" >}}

Do I have to replace the class with a specific command?

I tried it out until I got it to work. I think it was my mistake. In any case, you have to create a subfolder for the audio files in the static folder. Otherwise it is not enough to create the file as audio.mp3 like {{< audio src="audio.mp3" class="something" >}} The file audio.mp3 must be in a subfolder of static e.g. /static/audio/audio.mp3. Then the embedding must be like this: {{< audio src="/audio/audio.mp3" class="something" >}}

Closing as resolved for now :) Glad you got it fixed!


Support tablespace when adding partitions

Hi @ankane,
Can you support a parameter to specify the tablespace that the child tables will be in?
Excerpt from
https://www.postgresql.org/docs/10/ddl-partitioning.html
CREATE TABLE measurement_y2007m12 PARTITION OF measurement
    FOR VALUES FROM ('2007-12-01') TO ('2008-01-01')
    TABLESPACE fasttablespace;

An option like --tablespace fasttablespace is ok. I can create a PR if you don't have time to look into this.
Thank.

Anyway, I have created one here https://github.com/ankane/pgslice/pull/34


Pre-trained Model on CUB dataset

Hi,
Thanks for the nice work! Is it possible to provide pre-trained models on the CUB dataset?
It would be helpful. Thanks
Best,
Kilichbek

Hi,
In the experiments of CUB, best FID and IS I got corresponding to different checkpoints. Here are some checkpoints I found which might be useful to you.
https://drive.google.com/file/d/14B9kYfEBywc3uNlQF89D3BeXk-PrjwAE/view?usp=share_link
https://drive.google.com/file/d/1StYlf3gLoHiWPfdLmdg6idoWl_zTj5d9/view?usp=share_link
https://drive.google.com/file/d/1nD5PlrXhz-9U3stO16i9c6qvtc5wkSzl/view?usp=share_link

Thank you very much!


GPU for training of baseline model

Hi there,
I set up laypa and started a training for baseline recognition to check if it´s working properly.
I was suprised to see that the GPU seems to be only used for validation and not for the training itself. Forthermore I was confused about the duration of the training. I used approx. 1600 documents for training and the whole process was done after 10 min.
Obviously training duration depends on the hardware etc. but it is possible that I need to change some configurations? And if so, where do I do that?
I use the main.py script for training, the training and validation data as well as a config file. I used a very simple configuration with only the test and training weights defined and an output directory.
Thanks in advance!

Hi Stefan,
thank you for your help! This has seemed to help. Although not I have some other questions that you hopefully can help me answer:

How do I change the configuration to start training with a base model? I want to improve the baseline2 model that is delivered with loghi
The current training is taking way to lang. I started the training with the standard configurations, I only changed the model name and output folder. However I saw that eta is in 1083 days. What can I do to lower the training duration? I´m thinking lowering the number of iterations or maybe something else. However I´m not sure what parameter I should change

I hope you can help me, thanks in advance!

Or if you want to start from step 0, but do use the weights given set the MODEL.WEIGHTS and not the TRAIN.WEIGHTS

This is where you set the path of the baseline2 weights

However I saw that eta is in 1083 days

Again you are right that is way too long. Can you tell me which hardware you are using and when training starts do you see your GPU being used? Changing parameters will obviously help, but not such a big difference. Also are you training through the docker or in a conda environment? It still seems like you are not using a GPU, or you have some other bottleneck. With a single GPU I get an ETA of 2 weeks, but that is for the full training. You should just be finetuning.

SOLVER.MAX_ITER

This controls the number of iterations. If you are finetuning the model, set this to be a lot lower than it currently is.
Also look at:
DATALOADER.NUM_WORKERS
SOLVER.IMS_PER_BATCH
Also check if your GPU is capable of AMP, and change this if not:
MODEL.AMP_TRAIN.ENABLED
Keep me updated

I´m using a NVIDIA RTX 3500 Ada, 8 GB, GDDR6. My CPU is a intel i7-13850HX with 20 Cores and 28 logical processors. And I have 64 GB of RAM.
For NUM_WORKERS I chose 28 and IMS_PER_BATCH 32.
I set up a WSL environment for laypa on my windows pc.

The code for the preprocessing is not made to run on the GPU. So it should not use it there. The fact that the GPU is at 100 percent during training is good to hear. I would suggest first trying to run it with a smaller batch size and number of workers. Let say 4 images and 4 workers, just to see if it will run in a more logical time. A batch of 32 is more suited to the server, not a laptop. And as you are finetuning, it shouldn't need as much computing anyways. The eta you got was after training had started, right? Not with preprocessing as well?

I think I got the eta after the preprocessing, although I´m not totally sure.
I was able to run a training with the same configurations (except for max_iterations I chose 100) and a base model in about 4 hours. I tested the model and was able to see an improvement.


fix(tsm1): tsmFullCompactionQueue has not been updated ever

tsmFullCompactionQueue has not been updated ever.

[ ] CHANGELOG.md updated with a link to the PR (not the Issue)
[ ] Well-formatted commit messages
[ ] Rebased/mergeable
[ ] Tests pass

Apologies for the delay in reviewing this.
Can you split this into 2 separate PRs? One for engine.go, and one for compact.go + cache.go. I feel most confident about the engine.go changes; the compact.go change looks mostly ok to me, but I need some more time to dig around in the code to make sure I'm not missing something.

I updated this PR to be only related to engine.go except for typo.

Apologies for the delay in reviewing this.
Can you split this into 2 separate PRs? One for engine.go, and one for compact.go + cache.go. I feel most confident about the engine.go changes; the compact.go change looks mostly ok to me, but I need some more time to dig around in the code to make sure I'm not missing something.

As for getXXXEncoder(tsdb.DefaultMaxPointsPerBlock) in compact.go, I think it’s OK if don’t change it, because:

c.size is hard-coded in the code and is equal to tsdb.DefaultMaxPointsPerBlock.
getXXXEncoder(size) only affects memory allocation, not program logic errors.
tsdb.DefaultMaxPointsPerBlock is hard-coded in many places.


samples: add Java samples for RunRealtimeReport

@anweshan screenPageViews is a metric, not a dimension. As a result, tests are failing for RunRealtimeReportWithMultipleMetricsSample.java.


Update DocC documentation in the PackageDescription library.

Update DocC documentation in the PackageDescription library.
Motivation:
The DocC documentation in PackageDescription was not complete, and was out of sync with Apple's documentation at developer.apple.com.
Modifications:
Many DocC documentation comments were added or changed inside Sources/PackageDescription.
Result:
There was no code change. Only source code comments were changed in Sources/PackageDescription, and DocC extension files were added in the documentation catalog in that directory.

I wonder if it might be better to divide this PR into multiple smaller PRs, each focusing on just 1 or a few related files? There are a lot of lines changed in this PR. Smaller PRs can be easier (and perhaps faster) to review and prevent things from being overlooked.

The content was merged from the two split PRs. No further work on this PR. Closing.


Fixed Broken/Outdated link in   tensorflow/examples/CONTRIBUTING.md

The https://www.tensorflow.org/community/contribute  in tensorflow/examples/CONTRIBUTING.md  was  mistyped as https://www.tensorflow.org/community/contributing, thus making it land on a 404 not find web page
I fixed it

@yashk2810   @wolffg  @MarkDaoust
please review this

#303

@wolffg
Please review this PR


ARROW-13654: [C++][Parquet] Avoid infinite loop when appending a FileMetaData to itself

(another possibility would be to simply disallow it)

@jorisvandenbossche This fixes the reproducer you posted on the JIRA.

Thanks for the fix!


Installing dependencies fails

Hi,
I'm trying to skaffold a project using Windows 10 and Docker Desktop <IP_ADDRESS>
The following command is stuck in about an hour, after creating 125 970 files.
When I tested one more time, it went stuck on 47 190 files.
In third test it thrown errors, but finished:
docker run -it --rm --name docker-spfx-test02 -v ${PWD}:/usr/app/spfx -p 5432:5432 -p 4321:4321 -p 35729:35729 waldekm/spfx yo @microsoft/sharepoint --solution-name docker-spfx-test02 --component-type webpart --component-name wello-world-webpart --component-description "HelloWorld web part" --is-domain-isolated --framework none --environment spo --skip-feature-deployment false

? ==========================================================================
We're constantly looking for ways to make yo better!
May we anonymously report usage statistics to improve the tool over time?
More info: https://github.com/yeoman/insight & http://yeoman.io
========================================================================== (Y/n)
     _-----_
    |       |    .--------------------------.
    |--(o)--|    |      Welcome to the      |
   `---------´   |  SharePoint Client-side  |
    ( _´U`_ )    |    Solution Generator    |
    /___A___\    '--------------------------'
     |  ~  |
   __'.___.'__
 ´   `  |° ´ Y `

A folder with solution name docker-spfx-test02 will be created for you.
A component for the spo environment will be created for you.
A web part with the name wello-world-webpart will be added to your solution.
Web part description is going to be HelloWorld web part.
Let's create a new SharePoint solution.
Found npm version 6.13.4
Add new Web part to solution docker-spfx-test-02.

   create config/package-solution.json
   create package.json
   create config/config.json
   create config/serve.json
   create tsconfig.json
   create .vscode/extensions.json
   create .vscode/launch.json
   create .vscode/settings.json
   create config/copy-assets.json
   create config/deploy-azure-storage.json
   create config/write-manifests.json
   create src/index.ts
   create README.md
   create .editorconfig
   create .gitignore
   create gulpfile.js
   create tslint.json
   create src/webparts/welloWorldWebpart/WelloWorldWebpartWebPart.module.scss
   create src/webparts/welloWorldWebpart/WelloWorldWebpartWebPart.ts
   create src/webparts/welloWorldWebpart/loc/en-us.js
   create src/webparts/welloWorldWebpart/loc/mystrings.d.ts
   create src/webparts/welloWorldWebpart/WelloWorldWebpartWebPart.manifest.json
   create teams/0761fc5d-9e40-455c-ad4a-ed51dcdfaeee_outline.png
   create teams/0761fc5d-9e40-455c-ad4a-ed51dcdfaeee_color.png

npm WARN deprecated<EMAIL_ADDRESS>gulp-util is deprecated - replace it, following the guidelines at https://medium.com/gulpjs/gulp-util-ca3b1f9f9ac5
npm WARN deprecated<EMAIL_ADDRESS>Please update to minimatch 3.0.2 or higher to avoid a RegExp DoS issue
npm WARN deprecated<EMAIL_ADDRESS>This module relies on Node.js's internals and will break at some point. Do not use it, and update to<EMAIL_ADDRESS>npm WARN deprecated<EMAIL_ADDRESS>request has been deprecated, see https://github.com/request/request/issues/3142
npm WARN deprecated<EMAIL_ADDRESS>Chokidar 2 will break on node v14+. Upgrade to chokidar 3 with 15x less dependencies.
npm WARN deprecated<EMAIL_ADDRESS>use String.prototype.padStart()
npm WARN deprecated<EMAIL_ADDRESS>fsevents 1 will break on node v14+ and could be using insecure binaries. Upgrade to fsevents 2.
npm WARN deprecated<EMAIL_ADDRESS>not actively maintained anymore
npm WARN deprecated<EMAIL_ADDRESS>core-js@<3 is no longer maintained and not recommended for usage due to the number of issues. Please, upgrade your dependencies to the actual version of core-js@3.
npm WARN deprecated<EMAIL_ADDRESS>Please update to minimatch 3.0.2 or higher to avoid a RegExp DoS issue
npm WARN deprecated<EMAIL_ADDRESS>Legacy versions of mkdirp are no longer supported. Please update to mkdirp 1.x. (Note that the API surface has changed to use Promises in 1.x.)
npm WARN deprecated<EMAIL_ADDRESS>https://github.com/lydell/resolve-url#deprecated
npm WARN deprecated<EMAIL_ADDRESS>Please see https://github.com/lydell/urix#deprecated
npm WARN deprecated<EMAIL_ADDRESS>Please upgrade to kleur@3 or migrate to 'ansi-colors' if you prefer the old syntax. Visit <https://github.com/lukeed/kleur/releases/tag/v3.0.0\> for migration path(s).
npm WARN deprecated<EMAIL_ADDRESS>please upgrade to graceful-fs 4 for compatibility with current and future versions of Node.js
npm WARN deprecated<EMAIL_ADDRESS>This package is broken and no longer maintained. 'mkdirp' itself supports promises now, please switch to that.
npm WARN deprecated<EMAIL_ADDRESS>core-js@<3 is no longer maintained and not recommended for usage due to the number of issues. Please, upgrade your dependencies to the actual version of core-js@3.
npm WARN optional SKIPPING OPTIONAL DEPENDENCY<EMAIL_ADDRESS>(node_modules/chokidar/node_modules/fsevents):
npm WARN notsup SKIPPING OPTIONAL DEPENDENCY: Unsupported platform for<EMAIL_ADDRESS>wanted {"os":"darwin","arch":"any"} (current: {"os":"linux","arch":"x64"})
npm WARN notsup Unsupported engine for<EMAIL_ADDRESS>wanted: {"node":"<8.10.0"} (current: {"node":"10.18.1","npm":"6.13.4"})
npm WARN notsup Not compatible with your version of node/npm<EMAIL_ADDRESS>npm WARN optional SKIPPING OPTIONAL DEPENDENCY<EMAIL_ADDRESS>(node_modules/watchpack/node_modules/chokidar/node_modules/fsevents):
npm WARN notsup SKIPPING OPTIONAL DEPENDENCY: Unsupported platform for<EMAIL_ADDRESS>wanted {"os":"darwin","arch":"any"} (current: {"os":"linux","arch":"x64"})
npm WARN<EMAIL_ADDRESS>requires a peer of<EMAIL_ADDRESS>but none is installed. You must install peer dependencies yourself.
npm WARN<EMAIL_ADDRESS>requires a peer of<EMAIL_ADDRESS>|| ^2 || ^2.1.0-beta || ^2.2.0-rc || ^3.0.0 but none is installed. You must install peer dependencies yourself.

npm ERR! code ENOENT
npm ERR! syscall rename
npm ERR! path /usr/app/spfx/docker-spfx-test02/node_modules/@microsoft/gulp-core-build-webpack
npm ERR! dest<EMAIL_ADDRESS>npm ERR! errno -2
npm ERR! enoent ENOENT: no such file or directory, rename '/usr/app/spfx/docker-spfx-test02/node_modules/@microsoft/gulp-core-build-webpack' -><EMAIL_ADDRESS>npm ERR! enoent This is related to npm not being able to find a file.
npm ERR! enoent

npm ERR! A complete log of this run can be found in:
npm ERR!     /home/spfx/.npm/_logs/2020-06-20T10_56_08_954Z-debug.log

      _=+#####!
   ###########|       .--------------------------------------------.
   ###/    (##|(@)    |              Congratulations!              |
   ###  ######|   \   |  Solution docker-spfx-test-02 is created.  |
   ###/   /###|   (@) |       Run gulp serve to play with it!      |
   #######  ##|   /   '--------------------------------------------'
   ###     /##|(@)
   ###########|
      **=+####!

This command however works just fine, very quickly scaffolding a few solution files:
docker run -it --rm --name docker-spfx-test02 -v ${PWD}:/usr/app/spfx -p 5432:5432 -p 4321:4321 -p 35729:35729 waldekm/spfx yo @microsoft/sharepoint --solution-name docker-spfx-test02 --component-type webpart --component-name wello-world-webpart --component-description "HelloWorld web part" --is-domain-isolated --framework none --environment spo --skip-feature-deployment false --skip-install

I wonder we can make it keep installed dependencies within container itself, without mapping to host file system, do you think it might make things more stable?

Also tried like this:
docker run -it --rm --name docker-spfx-test02 -v ${PWD}:/usr/app/spfx -p 5432:5432 -p 4321:4321 -p 35729:35729 waldekm/spfx yo @microsoft/sharepoint --solution-name docker-spfx-test02 --component-type webpart --component-name wello-world-webpart --component-description "HelloWorld web part" --is-domain-isolated --framework none --environment spo --skip-feature-deployment false --skip-install
cd .\docker-spfx-test02
docker run -it --rm --name docker-spfx-test02 -v ${PWD}:/usr/app/spfx -p 5432:5432 -p 4321:4321 -p 35729:35729 waldekm/spfx npm install

Here's the output:
npm WARN deprecated<EMAIL_ADDRESS>gulp-util is deprecated - replace it, following the guidelines at https://medium.com/gulpjs/gulp-util-ca3b1f9f9ac5
npm WARN deprecated<EMAIL_ADDRESS>Please update to minimatch 3.0.2 or higher to avoid a RegExp DoS issue
npm WARN deprecated<EMAIL_ADDRESS>This module relies on Node.js's internals and will break at some point. Do not use it, and update to<EMAIL_ADDRESS>npm WARN deprecated<EMAIL_ADDRESS>Chokidar 2 will break on node v14+. Upgrade to chokidar 3 with 15x less dependencies.
npm WARN deprecated<EMAIL_ADDRESS>request has been deprecated, see https://github.com/request/request/issues/3142
npm WARN deprecated<EMAIL_ADDRESS>use String.prototype.padStart()
npm WARN deprecated<EMAIL_ADDRESS>not actively maintained anymore
npm WARN deprecated<EMAIL_ADDRESS>fsevents 1 will break on node v14+ and could be using insecure binaries. Upgrade to fsevents 2.
npm WARN deprecated<EMAIL_ADDRESS>core-js@<3 is no longer maintained and not recommended for usage due to the number of issues. Please, upgrade your dependencies to the actual version of core-js@3.
npm WARN deprecated<EMAIL_ADDRESS>Legacy versions of mkdirp are no longer supported. Please update to mkdirp 1.x. (Note that the API surface has changed to use Promises in 1.x.)
npm WARN deprecated<EMAIL_ADDRESS>Please update to minimatch 3.0.2 or higher to avoid a RegExp DoS issue
npm WARN deprecated<EMAIL_ADDRESS>https://github.com/lydell/resolve-url#deprecated
npm WARN deprecated<EMAIL_ADDRESS>Please see https://github.com/lydell/urix#deprecated
npm WARN deprecated<EMAIL_ADDRESS>Please upgrade to kleur@3 or migrate to 'ansi-colors' if you prefer the old syntax. Visit <https://github.com/lukeed/kleur/releases/tag/v3.0.0\> for migration path(s).
npm WARN deprecated<EMAIL_ADDRESS>please upgrade to graceful-fs 4 for compatibility with current and future versions of Node.js
npm WARN deprecated<EMAIL_ADDRESS>This package is broken and no longer maintained. 'mkdirp' itself supports promises now, please switch to that.
npm WARN deprecated<EMAIL_ADDRESS>core-js@<3 is no longer maintained and not recommended for usage due to the number of issues. Please, upgrade your dependencies to the actual version of core-js@3.

><EMAIL_ADDRESS>install /usr/app/spfx/node_modules/deasync
> node ./build.js

`linux-x64-node-10` exists; testing
Binary is fine; exiting

><EMAIL_ADDRESS>install /usr/app/spfx/node_modules/node-sass
> node scripts/install.js

Downloading binary from https://github.com/sass/node-sass/releases/download/v4.12.0/linux-x64-64_binding.node
Download complete  ] - :
Binary saved to /usr/app/spfx/node_modules/node-sass/vendor/linux-x64-64/binding.node
Caching binary to /home/spfx/.npm/node-sass/4.12.0/linux-x64-64_binding.node

><EMAIL_ADDRESS>postinstall /usr/app/spfx/node_modules/core-js
> node -e "try{require('./postinstall')}catch(e){}"

Thank you for using core-js ( https://github.com/zloirock/core-js ) for polyfilling JavaScript standard library!

The project needs your help! Please consider supporting of core-js on Open Collective or Patreon:
> https://opencollective.com/core-js
> https://www.patreon.com/zloirock

Also, the author of core-js ( https://github.com/zloirock ) is looking for a good job -)

><EMAIL_ADDRESS>postinstall /usr/app/spfx/node_modules/uglifyjs-webpack-plugin
> node lib/post_install.js

><EMAIL_ADDRESS>postinstall /usr/app/spfx/node_modules/node-sass
> node scripts/build.js

Binary found at /usr/app/spfx/node_modules/node-sass/vendor/linux-x64-64/binding.node
Testing binary
Binary is fine
npm notice created a lockfile as package-lock.json. You should commit this file.
npm WARN optional SKIPPING OPTIONAL DEPENDENCY<EMAIL_ADDRESS>(node_modules/chokidar/node_modules/fsevents):
npm WARN notsup SKIPPING OPTIONAL DEPENDENCY: Unsupported platform for<EMAIL_ADDRESS>wanted {"os":"darwin","arch":"any"} (current: {"os":"linux","arch":"x64"})
npm WARN notsup Unsupported engine for<EMAIL_ADDRESS>wanted: {"node":"<8.10.0"} (current: {"node":"10.18.1","npm":"6.13.4"})
npm WARN notsup Not compatible with your version of node/npm<EMAIL_ADDRESS>npm WARN optional SKIPPING OPTIONAL DEPENDENCY<EMAIL_ADDRESS>(node_modules/watchpack/node_modules/chokidar/node_modules/fsevents):
npm WARN notsup SKIPPING OPTIONAL DEPENDENCY: Unsupported platform for<EMAIL_ADDRESS>wanted {"os":"darwin","arch":"any"} (current: {"os":"linux","arch":"x64"})
npm WARN<EMAIL_ADDRESS>requires a peer of<EMAIL_ADDRESS>but none is installed. You must install peer dependencies yourself.
npm WARN<EMAIL_ADDRESS>requires a peer of<EMAIL_ADDRESS>|| ^2 || ^2.1.0-beta || ^2.2.0-rc || ^3.0.0 but none is installed. You must install peer dependencies yourself.

added 1771 packages from 1057 contributors and audited 1779 packages in 1077.318s

22 packages are looking for funding
  run `npm fund` for details

found 1993 vulnerabilities (1936 low, 13 moderate, 44 high)
  run `npm audit fix` to fix them, or `npm audit` for details

52 208 files created.
When I run it second time, it stuck on npm install, after creating 52 196 files:
npm WARN deprecated<EMAIL_ADDRESS>gulp-util is deprecated - replace it, following the guidelines at https://medium.com/gulpjs/gulp-util-ca3b1f9f9ac5
npm WARN deprecated<EMAIL_ADDRESS>Please update to minimatch 3.0.2 or higher to avoid a RegExp DoS issue
npm WARN deprecated<EMAIL_ADDRESS>This module relies on Node.js's internals and will break at some point. Do not use it, and update to<EMAIL_ADDRESS>npm WARN deprecated<EMAIL_ADDRESS>Chokidar 2 will break on node v14+. Upgrade to chokidar 3 with 15x less dependencies.
npm WARN deprecated<EMAIL_ADDRESS>request has been deprecated, see https://github.com/request/request/issues/3142
npm WARN deprecated<EMAIL_ADDRESS>use String.prototype.padStart()
npm WARN deprecated<EMAIL_ADDRESS>fsevents 1 will break on node v14+ and could be using insecure binaries. Upgrade to fsevents 2.
npm WARN deprecated<EMAIL_ADDRESS>not actively maintained anymore
npm WARN deprecated<EMAIL_ADDRESS>Legacy versions of mkdirp are no longer supported. Please update to mkdirp 1.x. (Note that the API surface has changed to use Promises in 1.x.)
npm WARN deprecated<EMAIL_ADDRESS>Please update to minimatch 3.0.2 or higher to avoid a RegExp DoS issue
npm WARN deprecated<EMAIL_ADDRESS>Please upgrade to kleur@3 or migrate to 'ansi-colors' if you prefer the old syntax. Visit <https://github.com/lukeed/kleur/releases/tag/v3.0.0\> for migration path(s).
npm WARN deprecated<EMAIL_ADDRESS>core-js@<3 is no longer maintained and not recommended for usage due to the number of issues. Please, upgrade your dependencies to the actual version of core-js@3.
npm WARN deprecated<EMAIL_ADDRESS>https://github.com/lydell/resolve-url#deprecated
npm WARN deprecated<EMAIL_ADDRESS>Please see https://github.com/lydell/urix#deprecated
npm WARN deprecated<EMAIL_ADDRESS>please upgrade to graceful-fs 4 for compatibility with current and future versions of Node.js
npm WARN deprecated<EMAIL_ADDRESS>core-js@<3 is no longer maintained and not recommended for usage due to the number of issues. Please, upgrade your dependencies to the actual version of core-js@3.
npm WARN deprecated<EMAIL_ADDRESS>This package is broken and no longer maintained. 'mkdirp' itself supports promises now, please switch to that.
[            ......] \ refresh-package-json:through2-filter: sill refresh-package-json /usr/app/spfx/node_modules/xml-name-validator

Could anyone test the same on another Windows machine or on a non-Windows machine?

Could it be a temporary glitch with npm? Can you still repro this issue?

Yes, tried once again:
PS D:\docker-spfx-test01> docker run -it --rm --name docker-spfx-test02 -v ${PWD}:/usr/app/spfx -p 5432:5432 -p 4321:4321 -p 35729:35729 waldekm/spfx yo @microsoft/sharepoint --solution-name docker-spfx-test02 --component-type webpart --component-name wello-world-webpart --component-description "HelloWorld web part" --is-domain-isolated --framework none --environment spo --skip-feature-deployment false
>>
? ==========================================================================
We're constantly looking for ways to make yo better!
May we anonymously report usage statistics to improve the tool over time?
More info: https://github.com/yeoman/insight & http://yeoman.io
========================================================================== No

     _-----_
    |       |    .--------------------------.
    |--(o)--|    |      Welcome to the      |
   `---------´   |  SharePoint Client-side  |
    ( _´U`_ )    |    Solution Generator    |
    /___A___\    '--------------------------'
     |  ~  |
   __'.___.'__
 ´   `  |° ´ Y `

A folder with solution name docker-spfx-test02 will be created for you.
A component for the spo environment will be created for you.
A web part with the name wello-world-webpart will be added to your solution.
Web part description is going to be HelloWorld web part.
Let's create a new SharePoint solution.
Found npm version 6.13.4
Add new Web part to solution docker-spfx-test-02.

   create config/package-solution.json
   create package.json
   create config/config.json
   create config/serve.json
   create tsconfig.json
   create .vscode/extensions.json
   create .vscode/launch.json
   create .vscode/settings.json
   create config/copy-assets.json
   create config/deploy-azure-storage.json
   create config/write-manifests.json
   create src/index.ts
   create README.md
   create .editorconfig
   create .gitignore
   create gulpfile.js
   create tslint.json
   create src/webparts/welloWorldWebpart/WelloWorldWebpartWebPart.module.scss
   create src/webparts/welloWorldWebpart/WelloWorldWebpartWebPart.ts
   create src/webparts/welloWorldWebpart/loc/en-us.js
   create src/webparts/welloWorldWebpart/loc/mystrings.d.ts
   create src/webparts/welloWorldWebpart/WelloWorldWebpartWebPart.manifest.json
   create teams/5a05ee81-54dd-4136-b43a-4562814f87e0_outline.png
   create teams/5a05ee81-54dd-4136-b43a-4562814f87e0_color.png

npm WARN deprecated<EMAIL_ADDRESS>gulp-util is deprecated - replace it, following the guidelines at https://medium.com/gulpjs/gulp-util-ca3b1f9f9ac5
npm WARN deprecated<EMAIL_ADDRESS>Please update to minimatch 3.0.2 or higher to avoid a RegExp DoS issue
npm WARN deprecated<EMAIL_ADDRESS>This module relies on Node.js's internals and will break at some point. Do not use it, and update to<EMAIL_ADDRESS>npm WARN deprecated<EMAIL_ADDRESS>Chokidar 2 will break on node v14+. Upgrade to chokidar 3 with 15x less dependencies.
npm WARN deprecated<EMAIL_ADDRESS>request has been deprecated, see https://github.com/request/request/issues/3142
npm WARN deprecated<EMAIL_ADDRESS>use String.prototype.padStart()
npm WARN deprecated<EMAIL_ADDRESS>not actively maintained anymore
npm WARN deprecated<EMAIL_ADDRESS>fsevents 1 will break on node v14+ and could be using insecure binaries. Upgrade to fsevents 2.
npm WARN deprecated<EMAIL_ADDRESS>Legacy versions of mkdirp are no longer supported. Please update to mkdirp 1.x. (Note that the API surface has changed to use Promises in 1.x.)
npm WARN deprecated<EMAIL_ADDRESS>Please update to minimatch 3.0.2 or higher to avoid a RegExp DoS issue
npm WARN deprecated<EMAIL_ADDRESS>core-js@<3 is no longer maintained and not recommended for usage due to the number of issues. Please, upgrade your dependencies to the actual version of core-js@3.
npm WARN deprecated<EMAIL_ADDRESS>https://github.com/lydell/resolve-url#deprecated
npm WARN deprecated<EMAIL_ADDRESS>Please see https://github.com/lydell/urix#deprecated
npm WARN deprecated<EMAIL_ADDRESS>Please upgrade to kleur@3 or migrate to 'ansi-colors' if you prefer the old syntax. Visit <https://github.com/lukeed/kleur/releases/tag/v3.0.0\> for migration path(s).
npm WARN deprecated<EMAIL_ADDRESS>This package is broken and no longer maintained. 'mkdirp' itself supports promises now, please switch to that.
npm WARN deprecated<EMAIL_ADDRESS>please upgrade to graceful-fs 4 for compatibility with current and future versions of Node.js
npm WARN deprecated<EMAIL_ADDRESS>core-js@<3 is no longer maintained and not recommended for usage due to the number of issues. Please, upgrade your dependencies to the actual version of core-js@3.
npm WARN optional SKIPPING OPTIONAL DEPENDENCY<EMAIL_ADDRESS>(node_modules/chokidar/node_modules/fsevents):
npm WARN notsup SKIPPING OPTIONAL DEPENDENCY: Unsupported platform for<EMAIL_ADDRESS>wanted {"os":"darwin","arch":"any"} (current: {"os":"linux","arch":"x64"})
npm WARN notsup Unsupported engine for<EMAIL_ADDRESS>wanted: {"node":"<8.10.0"} (current: {"node":"10.18.1","npm":"6.13.4"})
npm WARN notsup Not compatible with your version of node/npm<EMAIL_ADDRESS>npm WARN optional SKIPPING OPTIONAL DEPENDENCY<EMAIL_ADDRESS>(node_modules/watchpack/node_modules/chokidar/node_modules/fsevents):
npm WARN notsup SKIPPING OPTIONAL DEPENDENCY: Unsupported platform for<EMAIL_ADDRESS>wanted {"os":"darwin","arch":"any"} (current: {"os":"linux","arch":"x64"})
npm WARN<EMAIL_ADDRESS>requires a peer of<EMAIL_ADDRESS>but none is installed. You must install peer dependencies yourself.
npm WARN<EMAIL_ADDRESS>requires a peer of<EMAIL_ADDRESS>|| ^2 || ^2.1.0-beta || ^2.2.0-rc || ^3.0.0 but none is installed. You must install peer dependencies yourself.

npm ERR! code ENOENT
npm ERR! syscall rename
npm ERR! path /usr/app/spfx/docker-spfx-test02/node_modules/.staging/@microsoft/sp-loader-7cbed909
npm ERR! dest /usr/app/spfx/docker-spfx-test02/node_modules/@microsoft/sp-loader
npm ERR! errno -2
npm ERR! enoent ENOENT: no such file or directory, rename '/usr/app/spfx/docker-spfx-test02/node_modules/.staging/@microsoft/sp-loader-7cbed909' -> '/usr/app/spfx/docker-spfx-test02/node_modules/@microsoft/sp-loader'
npm ERR! enoent This is related to npm not being able to find a file.
npm ERR! enoent

npm ERR! A complete log of this run can be found in:
npm ERR!     /home/spfx/.npm/_logs/2020-07-06T09_08_30_783Z-debug.log

      _=+#####!
   ###########|       .--------------------------------------------.
   ###/    (##|(@)    |              Congratulations!              |
   ###  ######|   \   |  Solution docker-spfx-test-02 is created.  |
   ###/   /###|   (@) |       Run gulp serve to play with it!      |
   #######  ##|   /   '--------------------------------------------'
   ###     /##|(@)
   ###########|
      **=+####!

PS D:\projects\docker-spfx-test01\docker-spfx-test02> docker run -it --rm --name docker-spfx-test02 -v ${PWD}:/usr/app/spfx -p 5432:5432 -p 4321:4321 -p 35729:35729 waldekm/spfx gulp serve
internal/modules/cjs/loader.js:638
    throw err;
    ^

Error: Cannot find module '@microsoft/sp-build-web'
    at Function.Module._resolveFilename (internal/modules/cjs/loader.js:636:15)
    at Function.Module._load (internal/modules/cjs/loader.js:562:25)
    at Module.require (internal/modules/cjs/loader.js:692:17)
    at require (internal/modules/cjs/helpers.js:25:18)
    at Object.<anonymous> (/usr/app/spfx/gulpfile.js:3:15)
    at Module._compile (internal/modules/cjs/loader.js:778:30)
    at Object.Module._extensions..js (internal/modules/cjs/loader.js:789:10)
    at Module.load (internal/modules/cjs/loader.js:653:32)
    at tryModuleLoad (internal/modules/cjs/loader.js:593:12)
    at Function.Module._load (internal/modules/cjs/loader.js:585:3)

@shurick81 it's odd that the installation seems to be failing each time on a different package. Which version of the Docker SPFx image are you using?

REPOSITORY                       TAG                 IMAGE ID            CREATED             SIZE
waldekm/spfx                     latest              b028349ee02a        5 months ago        982MB

There seems to be some correlation with whether docker is busy with other containers and whether CPU is busy. So maybe we should just close the issue and if other people have a similar one, they can learn something from here and raise it again if needed?

@waldekmastykarz Hi, I got the same exact behaviour on Windows host and the cause was antivirus (Kaspersky Antivirus). In my case adding solution folder to whitelist fixed this one.

Awesome! Thank you for sharing the solution @Erfa1l! I'm sure others will find it helpful


[CDAP-11899] Integrate user defined directives and field level lineage

[CDAP-11899] Add field-level lineage generation capabilities to wrangler

Waiting on PRs in cdap

Todo:

[x] Test
[ ] Error Handling, exceptions
[ ] Make lineage optional

Waiting on: https://github.com/caskdata/cdap/pull/9240

LGTM. Squash and merge.


Add interface to backprop from multiple variables

https://github.com/chainer/chainer/issues/5709#issuecomment-441972123

Blocked by #6348

Jenkins, test this please.

Jenkins CI test (for commit b673e048d83cfcb7aefbe1a7e56e638c66b0ee1f, target branch master) failed with status FAILURE.

Jenkins, test this please.

Jenkins CI test (for commit a8d08cb7a1fac6cacc647f51c4bbdcae7db0246c, target branch master) failed with status FAILURE.

Jenkins, test this please.

Jenkins CI test (for commit a8d08cb7a1fac6cacc647f51c4bbdcae7db0246c, target branch master) succeeded!

Note:
The PR includes moves of files.  Most of the changes are available at
https://github.com/chainer/chainer/pull/5952/files/d24dd57005cb575635538d8b477352266031252f.


Readme install instructions no longer match reality

In the README.md file it says:
git clone https://github.com/graspologic-org/graspologic
cd graspologic
python3 -m venv venv
source venv/bin/activate
python3 setup.py install

These steps are no longer correct. The setup.py file no longer exists.

pip install graspologic should work - are you having issues with that or looking to install from a local path?


Quality of life changes

This series of patches implements a few quality of life changes:

The option --base64body can be used to tell slapper that the bodies in the targets file are base64-encoded. This can then be used to pass in bodies encoded in binary formats, such as protobuf, that were recorded from live traffic.
Users can specify HTTP headers that should be added to all requests with the -H option on the command line. To add multiple headers, repeat the option, à la curl.
The parser for the targets file is now less fussy about the syntax of the file, while being backwards-compatible with existing syntax. This is for example valid syntax now for specifying multiple targets with empty bodies:

GET http://www.example.com
GET http://www.url.foo

The slapper now supports non-GET HTTP requests via the targets file.
Targets can be read from STDIN, fulfilling a promise made in the documentation.

thank you!


modify res lvs and adding variant D with 6LM to run_lvs

Fixes #<issue_number_goes_here>

[ ] Tests pass
[ ] Appropriate changes to README are included in PR

@FaragElsayed2 , ready for review


Greenkeeper badge image is not showing in readme.md

Greenkeeper badge image url is not found so click that image redirect greenkeeper.io url

Yeah, I've removed greenkeeper - will remove the badge. Thanks for reporting.

:tada: This issue has been resolved in version 1.15.0 :tada:
The release is available on:

Visual Studio Marketplace
GitHub release

Your semantic-release bot :package::rocket:


Getting Started Error

Hello when i follow the getting started on the readme, when I try "swift build" it goes like this, help me please.

Guessing you have git v2.9.1 installed?
There's a bug in 2.9.1 that causes this issue. You can either update to git 2.9.2 or just run swift build over and over again and it should work.

Oh great it's the problem but I think I have another problem because I use XCode 8 with Swift 3 :

I generated an xcode project, i resolved all of this but there is again one left that I don't get it...

Which toolchain are you using?

How can we see that?

In Xcode, like this:

Which toolchain is selected?

Lol, look :

Have you installed the 06-20a toolchain and put it in your path?  Instructions are in README.md

But isn't working...

OK, so you have the toolchain installed - good. Now are you using it on the command-line? In your previous screenshot it said XcodeDefault.xctoolchain which means you are using the Xcode 8.0 toolchain, not 06-20.

Oh okay, so how can I do?

By far the easiest way is to use https://github.com/kylef/swiftenv

Yes swiftenv is useful. The alternative is to add the toolchain directory to your $PATH.

I use swiftenv ->

then it gives my like the other screen ... ->

Can you rm -rf Packages and try again?

Yeah it's work now! Big thanks, now i had to understand all features of kitura x)

Awesome - have fun!


Virtual environment support for uv run

As mentioned in https://github.com/astral-sh/uv/issues/3097, uv run may support working with virtual environment, where:

uv run can specify a venv folder to use that venv for running command
uv run can work without depending on a python project under certain condition (e.g. when a venv folder is specified)

Thanks!

What about something like this:

If we discover a workspace, we use the current behavior.
If we can't discover a workspace, we use our standard Python interpreter discovery, and run in that interpreter. (So, e.g., run in the current venv, or a discovered venv, or whatever you pass in --python.)
We add an option to mark a pyproject.toml as "not managed by uv" / "not part of a workspace" (like managed = false or workspace = false) so that you can use this in codebases that have a pyproject.toml but want to use the pip API.

The first two rules are fairly reasonable! For the third rule, is https://github.com/astral-sh/uv/issues/3404 and https://github.com/astral-sh/uv/pull/3585 relevant regarding workspace = false option?
Though I haven't figured out how a pyproject.toml will impact pip API (the uv pip commands?) yet, in uv run it will cause uv to install current project as package, and disabling it may make not much difference once editable build is installed? (btw, I found in my project uv run ls always try to build and reinstall my project, is that intended?)

I am wondering if workspace = false and managed = false mean different things... You might have a project that's nested in a workspace, but shouldn't be considered part of the workspace, but should still be managed with uv.

btw, I found in my project uv run ls always try to build and reinstall my project, is that intended?

(Do you have dynamic metadata in your project? If so, yes, but we may change that behavior.)

(Do you have dynamic metadata in your project? If so, yes, but we may change that behavior.)

Yes, we have requirements.txt (generated by uv pip freeze | uv pip compile - used for pyroject.toml using
[tool.setuptools.dynamic]
dependencies = {file = ["requirements.txt"]}

Yeah, we have to rebuild your project every time if you have dynamic metadata right now, since we have no way of knowing if it's up-to-date.

We add an option to mark a pyproject.toml as "not managed by uv" / "not part of a workspace" (like managed = false or workspace = false) so that you can use this in codebases that have a pyproject.toml but want to use the pip AP

Would this be equivalent to uv run --isolated?

Nope! uv run --isolated runs a command in an isolated, ephemeral environment.

Ah hm, should --isolated being double duty of ignoring configuration and forcing an ephemeral environment? I think the flag name makes sense for the latter in this command but I worry about expanding the concept.

We could remove it and add a dedicated flag (--ephemeral or whatever), but we still need a solution to running in a venv when a pyproject.toml is present.

Ah hm, should --isolated being double duty of ignoring configuration and forcing an ephemeral environment?

(This is already how it behaves today, just to clarify.)

we still need a solution to running in a venv when a pyproject.toml is present.

Should any explicit flag of python interpreter discovery takes precedence over discovered workspace? That enables user to explicitly specify a venv to use it when in a folder with pyproject.toml (but makes the code in the PR more complicated though).

Unfortunately --python does have a valid meaning and usage in workspaces. If you run --python 3.8, and the venv uses a mismatched version, we'll re-create it.

we still need a solution to running in a venv when a pyproject.toml is present.

Perhaps the answer I'm looking for will fall out of that.
Given the semantics in Ruff, I'd expect --isolated to ignore the pyproject.toml and other configuration files but not change other other behavior like ignoring existing environments. I designed the uv run isolated feature purely to do the latter but yeah it ended up doing both because it's the obvious flag name. I don't think the behavior is unreasonable though. I need to think a bit more about the pyproject.toml-not-a-workspace design :)

Yeah, if --isolated respected an existing venv, then we'd probably find ourselves wanting a flag to do what --isolated does now.
Let me know your thoughts when you can, this work is blocked on feedback on the ideas I proposed.

I'd expect --isolated to ignore the pyproject.toml and other configuration files but not change other other behavior like ignoring existing environments.

I think this will be a very useful behavior. For end-users, implicit would help, while for scripts explicitly helps much.
For my use case, I majorly use conda run/uv run in automated shell scripts, especially in Dockerfile where activating an environment is not convenient, while explicitly specifying an environment to run is a more working solution.
So, for such scripts, I'd expect an explicit flag (--isolated or something) to tell uv to explicitly run in project mode / venv mode, without taking care of what current directory uv is running in.

We now fallback to virtual environments if you're not in a project.


Example should checkout a specific revision

in the tapkick example:
https://github.com/racker/dreadnot/blob/master/example/stacks/tapkick.js
We are just doing a straight up pull, but it should checkout a specific revision / tip.

Fixed in 8ad368a


update opentracing-go version

The latest opentracing-go didn't depend on "golang.org/x/net" any more.
let's update it.

Thank you!


Incorrect implementation of "SetParameterAsync" method in BitCheckBox

After merging the new "HtmlAttributes" feature, the structure of the "SetParameterAsync" method has been changed as follows:

but in the BitCheckBox the overridden method has an incorrect implementation.

this issue has been resolved with the new implementation of the source generator.


sticky child state gets lost when returning to its parent from other than the child

The situation is like this:
I have 3 states(all sticky):
parent1
parent1.child1
parent2
steps:
-> child1 -> parent2 -> parent1 , this causes child1 to disappear and re-access child1 will cause re-initialising the scope, which is not wanted
plunkr:
http://plnkr.co/edit/tnjbOn97BHCkNy3DLa4M?p=preview
Is it a bug? Is there any way to remember child1 once it is accessed? Thx

Did you try deep state redirect?

Putting a deepStateRedirect on parent1
This worked that child1 is no longer lost. But this will make parent1 always redirect to child1 if child1 has been accessed. How could I go to parent1 only?
from the debug info, the inactive states list shows:

when I left child1 to parent2, inactive states: ["top.parent1.child1", "top.parent1"]
Both parent1 and child1 were remembered. This is expected

when I entered to parent1, inactive states:  ["top.parent2"]
"top.parent1.child1" went lost. Is this expected?

It seems the problem is when entering parent state from a state other than its child states, it forgets its sticky child states

hmm I have similar problem after upgrade to 0.0.14
I have a multi column with 2 sticky states on left/right side,
initial layout is:  left1 | empty
steps:
parent.left1 -> parent.left2 -> parent.left1 -> parent.right1
then parent.left1 disappears, parent.left2 shows up   left2 | right 1
the expected request is left1 | right1

I am having similar problem only when i enable futureState together with stickyState.
You might want to turn the debug mode on, and look at how the transitions going on.

This is confirmed as a bug.
Given a sticky state with a sticky substate
      A (sticky)    B
    A.1 (sticky)

There is a difference in how a sticky substate (A.1) is handled when:

Navigating to A will reactivate A (B -> A)

A.1 is exited

Navigating to A when A is already entered (A.1 to A)

A.1 remains inactive

The docs say that the sticky state DOM/controller is retained until the parent to the sticky state is exited.  This statement is not precisely followed, as the two bullet points above demonstrate.  I am going to change the expected behavior to the following statement:

A sticky state's DOM/controller is retained _until the parent state is either: exited, or directly activated

another way to phrase that is:

A sticky state's DOM/controller is retained _while either: the parent is inactive or a sibling of the sticky is active

This is a BC-BREAK from 0.0.14, but it is more internally consistent and consistent with the intention of sticky states.

OP, if you want control over how parent1 and parent1.child1 interact, I suggest using:

dsr: true to get parent1 to redirect to parent1.child
$state.go(parent1, null, {ignoreDsr: true}) to navigate directly to parent1

updated plunk with ui-router-extras 0.0.15-pre3
http://plnkr.co/edit/sQIGly0ImyZYtdus4iuy?p=preview


Handle notification when app is in forground

I don't want to show notification always. Instead I would like to display the notification based on the condition when app is in foreground.
In android, receiving the notification when the app is in foreground.
Please let me know how to display notification based on condition.
Thanks in advance

I have found out. By Creating IPushNotificationHandler we can do this


How i can save instance sql builder for later use

Hi, how to do the following:
let value = Some("Hard".to_string());
let query = SqlBuilder::select_from("users")
    .field("name")
    .field("surname")
    .and_where("surname = ?".bind(&"John"));
if let Some(surname) = value {
    query.and_where("surname = ?".bind(&surname));
}
let res = query.sql()?;

Is it possible?

I found a solution to this question

@myduomilia would be helpful for feature readers to see the solution you found :)

let value = Some("Hard".to_string());
let mut query = SqlBuilder::select_from("users")
    .field("name")
    .field("surname")
    .and_where("surname = ?".bind(&"John"))
    .clone();
if let Some(surname) = value {
    query = query.and_where("surname = ?".bind(&surname)).clone();
}
let res = query.sql()?;


Reword comment to shorten line

This is a fix for issue https://github.com/jdf/processing-py-site/issues/174

Thank you.


Requesting structures of adrb1_melga throws exception

Stack trace
... DEBUG : KNIME-Worker-1 : GPCRDB Structures of a protein : GPCRDB Structures of a protein : 2:1 : Execute failed: String value can't be null.
java.lang.NullPointerException: String value can't be null.
	at org.knime.core.data.def.StringCell.<init>(StringCell.java:110)
	at nl.esciencecenter.e3dchem.gpcrdb.structures.StructuresOfProteinNodeModel.fetchStructures(StructuresOfProteinNodeModel.java:125)
	at nl.esciencecenter.e3dchem.gpcrdb.structures.StructuresOfProteinNodeModel.execute(StructuresOfProteinNodeModel.java:93)

After switching to okhtttp client this issue is back.

See fbf127aab876cd79e112e3332408f7e57df3d372 for previous fix. Now we should adapt the swagger.json to create 2 endpoints

/services/structure/protein/{entry_name}/ returns array
/services/structure/protein/{entry_name}/?single returns object with single pdb

oprk_human has single pdb.
adrb1_melga has multiple pdbs.


Possible typo in config.json.map.example

Expected Behavior
The lines 192 to 195 of config.json.map.example should be:
"//NOTE: Change the max_sniping_distance to adjust the max sniping range (m)": {},
"max_sniping_distance": 10000,
"//NOTE: Change the max_walking_distance to adjust the max walking range when snipe is off (m)": {},
"max_walking_distance": 500,
Actual Behavior
but in the latest commit those lines are:
"//NOTE: Change the max_sniping_distance to adjust the max sniping range (m)": {},
"max_sniping distance": 10000,
"//NOTE: Change the max_walking_distance to adjust the max walking range when snipe is off (m)": {},
"max__walking_distance": 500,
using this config file there will be an error when bot communicates with the map.
Your FULL config.json (remove your username, password, gmapkey and any other private info)

Output when issue occurred

Steps to Reproduce

Other Information
OS:

Branch:
dev
Git Commit:
4cce54823e4209ad0000b5166be7443e5c775194
Python Version:

Any other relevant files/configs (eg: path files)

Short Description

Possible solution

How it would help others

Thank you, fixed
https://github.com/PokemonGoF/PokemonGo-Bot/commit/f9875b6cd40afab7d00dc90fa07be158a03da8fe


Yax test update

Partial update for tests to use YAXArrays. Should be merged after #693.

Hi @DanTanAtAims , I'm confused with the name of this PR. Is this supposed to only update tests? Because it seems to be doing more than this. Is that correct?

It contains a few relatively shallow type changes to so that I could continue altering some types. the rank_to_frequencies was more involved than I though but allowed me to progress further. But yes, I should start working on non-test conversions.

You can leave rank_to_frequencies and related to me


refactor(fonts): enable font awesome cdn. update upgrade-guide refs

fixes https://github.com/patternfly/patternfly-next/issues/1229

Deploy preview for pf-next ready!
Built with commit e79d78d892c8d58cf5daf4b99fcefd2320a5450a
https://deploy-preview-1434--pf-next.netlify.com

:tada: This PR is included in version 1.0.199 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


Load plugin settings from file

I think it will be nice if the settings could be loaded from a configuration file inside the project.
This because in some project you want to format on save, and some other project you don't.

Yeah, it would be a nice feature. I will work on it in a future update.


Develop and style the Signup and Login templates

We would be developing the user signup and login templates here
Tasks

[x] #15
[ ] #39

Refer to #1 for an overview of all frontend related tasks

Done and sent to @ElSam20 for review


Does not work with yarn workspaces

Error stacktrace:
Error: Cannot find module '/projects/workspace-root/apps/project-a/node_modules/next/dist/build/output/log'
Require stack:
- /projects/workspace-root/node_modules/next-logger/lib/patches/next.js

I've merged the fix from 2.2.0-beta.0 into main, and it's been shipped in 2.2.0. Thanks for testing the fix!


Updating EndpointSlice docs for 1.20

This covers https://github.com/kubernetes/enhancements/issues/752 and the changes that were implemented in https://github.com/kubernetes/kubernetes/pull/96440. It also overlaps a bit with https://github.com/kubernetes/website/pull/24927.
/sig network

/assign @kcmartin
/hold pending merge https://github.com/kubernetes/kubernetes/pull/96318
/milestone 1.20

Hi @robscott checking in to see if docs are needed here. Based on the comment https://github.com/kubernetes/kubernetes/pull/96318#issuecomment-725008391 looks like GA will be deferred to 1.21. For the small changes you're making for 1.20, does it require docs change?
If so, please remember to retitle and make sure content reflects the latest progress. Thank you!

Thanks for checking in @annajung! I've updated the title of this PR to a be more reflective of the current scope. I'll still need some small doc updates for https://github.com/kubernetes/kubernetes/pull/96440, but they should be relatively minor.

/hold cancel
k/k pr merged

This is a placeholder PR

will mark as draft
Feel free to revise the PR description and mark it ready for review when it is.

Hi @robscott !
A friendly reminder that Docs "Ready for Review" Deadline is this Monday, Nov. 23rd for the 1.20 release.
Please reach out if you have any questions.

@sftim Thanks for the feedback here! This PR should be ready for a full review now.

/cc @andrewsykim

/lgtm

https://deploy-preview-24935--kubernetes-io-vnext-staging.netlify.app/docs/tasks/administer-cluster/enabling-endpointslices/
https://deploy-preview-24935--kubernetes-io-vnext-staging.netlify.app/docs/concepts/services-networking/endpoint-slices/#topology
pages lgtm
/approve


[BUG] Executor state map becoming too large can result in failures to write the CR to etcd

Description
We use the operator to manage the lifecycle of both batch and Spark streaming applications. Streaming apps in particular are long lived and if using dynamic allocation may scale up and down  over time, resulting in the creation of new executor IDs (see link below for incremented executor IDs inside Spark)
The operator tracks the state of each individual executor pod inside the .Status.ExecutorState field but these entries are never removed. For long lived streaming applications this map will eventually become so large that the operator the CR cannot be written back to etcd as it's over the request size limit.
https://github.com/kubeflow/spark-operator/blob/master/pkg/controller/sparkapplication/controller.go#L367-L436
https://github.com/apache/spark/blob/d82458f15539eef8df320345a7c2382ca4d5be8a/resource-managers/kubernetes/core/src/main/scala/org/apache/spark/scheduler/cluster/k8s/ExecutorPodsAllocator.scala#L460

[X] ✋ I have searched the open/closed issues and my issue is not listed.

Reproduction Code [Required]
Create enough unique executors over the lifetime of a Spark application that eventually the CR becomes larger than the max etcd request size.
Expected behavior
The operator should not fail to write the CR back to etcd.
Actual behavior
If enough executor IDs are accumulated within a single application, eventually the operator may fail to write the CR back to etcd.
Terminal Output Screenshot(s)
I can't find any internal screenshots of how large the executor state map was but did find the etcd write failure log.

Environment & Versions

Spark Operator App version: internal
Helm Chart Version: internal
Kubernetes Version: 1.26
Apache Spark version: 3.3-3.5

Additional context
Internally we found no one was using this field so effectively disabled the tracking. We use EKS so I cannot change the max size of an etcd request but EKS docs say it's 1.5 megabytes.

I think this issue can still occur so commenting to mark as still active

+1 same issuer
If stream with dynamic allocation fails  with some errors it start unstoppable create new workers then failed and start new workers without ending so it create to many keys for etcd and too long manifest with status all workers


Add --max-blocks and --duration flags

These flags can limit how long block_writer runs allowing it to be
used for fixed duration performance tests.

This change is

LGTM


March or June 2024?

Hi,
this article lists March 2023. Within the Teams Admin Center the information is June 2024. What is now true?

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

ID: 67786821-0151-66c1-2fa1-498d88e3b3b3
Version Independent ID: 67786821-0151-66c1-2fa1-498d88e3b3b3
Content: Classic Teams users to be automatically updated to new Teams - Microsoft Teams
Content Source: Teams/new-teams-automatic-upgrade-announced.md
Service: msteams
GitHub Login: @JoanneHendrickson
Microsoft Alias: jhendr

To make it easier for you to submit feedback on articles on learn.microsoft.com, we're transitioning our feedback system from GitHub Issues to a new experience.
As part of the transition, this GitHub Issue will be moved to a private repository. We're moving Issues to another repository so we can continue working on Issues that were open at the time of the transition. When this Issue is moved, you'll no longer be able to access it.
If you want to provide additional information before this Issue is moved, please update this Issue before December 15th, 2023.
With the new experience, you no longer need to sign in to GitHub to enter and submit your feedback. Instead, you can choose directly on each article's page whether the article was helpful. Then you can then choose one or more reasons for your feedback and optionally provide additional context before you select Submit.
Here's what the new experience looks like.
Note: The new experience is being rolled out across learn.microsoft.com in phases. If you don't see the new experience on an article, please check back later.
First, select whether the article was helpful:

Then, choose at least one reason for your feedback and optionally provide additional details about your feedback:

Article was helpful
Article was unhelpful

Finally, select Submit and you're done!


How to bypass all Extractors of ExoPlayer itself and directly use the decoding capabilities of the device？

Please help me, I want to use ExoPlayer&Media3's Api, but I only want to use the decoding ability of the device, directly use the underlying codec, skip the Extractor at the ExoPlayer code level, and not be intercepted.
Let me give an example, for example, there is an FLV video that is composed of h.263. When the parseHeader in VideoTagPayloadReader is directly thrown, "Video format not supported:" but my device already supports it. The underlying device has integrated rich ffmpeg and some purchased formats using Codec2, using MediaPlay
r. You can play it directly. Is there a simple way for ExoPlayer to directly use the underlying decoding capabilities and bypass the app code layer
Extractor

Additional note: My app runs on my customized Android device, and our strategy is to integrate decoding capabilities into the device system (Android extractor, QTI extractor, and ffmpeg extractor) instead of integrating them at the application level. However, we are very happy to use Media3, which has already been reported as not supported at the app level. I need a simple method to achieve this goal

android.media.MediaExtractor +androidx.media3.extractor.Extractor


highlighting menu

the heading of menu in the sidebar is looking same as its elements i can style and highlight it

@parthtaneja0001 Go ahead


Multiple Initialization in material select

When I was trying to use select from materialize with angular i saw weird triangle (caret) appended to input-field after each change in select. When I was search for solution I find in materialSelect directive code that initializing material-select after every change. Is it necessary? I remove last "if" and problem disappeared.
Edit: In my project I use materialize in 0.97.0 version. When I downgrade to lower version it solve the problem. Maybe you could add fix to this project that let him work with latest materialize?

This still exists for me using v0.97.0 of materializecss and download on commit: 2287ff4eacd72b9d1a7e6b5bde415c184071495b and every time I switch a caret appears

Sadly, fix for this problem is not merged yet

Hey, a man can take a vacation.
And besides, the "fix" didn't fix anything, at most it delayed the problem.


Feat: Improvements for Do not Merge

Add "DNM" as a trigger string
Add ability to check tags for WIP/DNM
Add Ability for custom "Do not Merge" button message

@Mezzle Cool!  Would you update README.md about this feature?

(done, btw)

Thanks!


dojot is violating the firmware-update state machine

There is a state machine defined for the firmware update and according to that the 'send' and 'apply' operations must meet some rules:

The 'send operation' can be executed if and only if the state is IDLE.
The 'apply operation' can be executed if and only if the state is DOWNLOADED.

dojot is not imposing any rules to execute these operations; so you can execute them in any order or moment. Furthermore, the GUI returns success messages ('Image successfully transferred' or 'Image applied'), causing misunderstandings of what is happening.

About the operations, we could add these rules in GUI, but should be applied in the backend as well.
About the messages, we could change the response to "command sent to the device: request to transfer image or apply image" or something like this?

For me, the firmware-update operations are special actuations; and the rules should be imposed by the back-end.
Regarding to the messages, we don't have any guarantees that they were sent to the devices. We only know that the back-end accepted the requests. My suggestions are:

Request to transfer firmware image was accepted.
Request to apply the firmware image was accepted.

Regarding the GUI, the messages were updated.
For now, I'll remain this ticket opened and I'm adding @giovannicuriel to clarify the backend points (for further improvements).

Utilizar a tag na gui  mprevide/gui:updatefirmware


Doubt solving page

Before exam a lots of doubts I will be creating a doubt page the users can resolve each other doubt Can you please assign me this issue under GSSOC'24

@Vishnu1804K Assigned

I also want to work in this issue @hereisSwapnil

hey @hereisSwapnil
I am a GSSoc'24 contributor. I also want to work on this . Can you please assign me this issue.

Hello @hereisSwapnil,
As a GSSOC 2024 contributor, I'm keen to tackle new challenges. Please assign me this issue to showcase my skills and grow as a developer. Thanks for considering me!


Renaming

I noticed period_state is still used throughout in this repository. There might be more, see open-autonomy PR #815 for reference.

Fixed


In browser debugger - no access to thrown error when in async context

Bug report

What is the current behavior?
When an exception is caught inside an async function, the debugger does not display the value of the exception parameter given to the catch block.
It is accesible by the program itself, e.g. you can log it to the console, but not to the debugger (tried it with the latest Chrome, Firefox and Edge)
If the current behavior is a bug, please provide the steps to reproduce.

Create a simple async function that throws and catches an exception.
In the browser's dev-tools, place a breakpoint inside the catch block.
The value of the caught exception is not shown on hover.
Also it is not available by typing the parameter's name in the console.

Example function:
        async created() {
            try {
                throw {a: 42, msg: 'hello lilo'};
            }
            catch (e) { // <-- can't inspect in dev-tools
                console.log(e); // <-- prints the value correctly (breakpoint here)
            }
        }

It is worth noting that I found the exception object inside arguments[0].t0 (if you type this into the console you get the exception object passed to the catch block.

What is the expected behavior?
Caught exception should be available to the debugger.
Note that if you remove the async prefix from the function the exception is available.

Other relevant information:
webpack version:  4.41.2
Node.js version: v10.13.0
Operating System: Windows 10
Additional tools: Vue CLI (@vue/cli 4.0.5)
The webpack project was created by the Vue CLI tool.

Seems like you transpiled the async function. Consider disable transpilation for development, that makes debugging easier.

I'm sorry but I couldn't find any documentation on this or anything useful on stackoverflow. How do I disable transpilation just for development?

Depends on your configuration


Evaluating an attribute not in the request's context should return a zero value, not an error

@ZackButcher commented on Mon Feb 27 2017
Today if you try to call the mixer without specifying all of the attributes required to satisfy all expression evaluated at runtime the call will fail. This is because we return errors when we evaluate expressions that contain attributes that are not in the request's attribute bag. Rather than failing the evaluation, we should return a zero value instead so that we can always continue with reasonable values at runtime.
@mandarjog points out that some of the cases aren't straightforward: e.g. what's the zero value of an email?

@kyessenov commented on Mon Feb 27 2017
I think it would wise to never throw errors in expressions (think mysql, jquery, etc). It's up to you to assign values to undefined expressions such as 1/0 or empty email address.

@mandarjog commented on Mon Feb 27 2017
I agree that a user should never see a 500 because something could not be evaluated.
We could start with -- in case of an error Expression gets its baseTypes' default value.
We could let the user specify an alternate value, in case of an evaluation failure.

@ldemailly commented on Tue Oct 03 2017
I agree the | "unknown" needed all over isn't right

@RoeyMaor commented on Tue Oct 03 2017
The problem is that for many VALUE_TYPEs default value literals cannot be created. perhaps the approach should be the same as with the "ip" function defined here: https://github.com/istio/mixer/blob/535eb564667cef6aed334cb4f5e967a104768387/pkg/expr/func.go that allows creating IP_ADDRESS literals from strings. Maybe part of the solution is to define similar functions for the other VALUE_TYPEs that allow to create literals, that way we don't enforce "weird" zero values on the user and give him the option to use whatever values it wishes,
and he might even choose to use those not as default values, but as the actual values for testing. Another discussion is whether These "new" string->value_type_literal functions should crash when the string given as input doesn't match their logical type format ("istio.io" as email, "42" as a timestamp, etc)
regardless of this, indeed when no default value is stated, there should be a warning rather than an error

@mandarjog commented on Wed Oct 04 2017
Forcing the user to give default value for an expression is similar to forcing a user to catch an exception. It is explicit and there are no surprises.
ip or other type conversion functions let you specify a typed default values, including create a typed literal. We are adding all those shortly, however that does not address the usability issue.
If that is turned into a warning, the
re: Crashing, Mixer should never crash because of user input. However evaluation may fail.
Typing error of the kind you suggest are caught during validation stage. These do not result in runtime errors.
We can add missingAttributePolicy as separate settings for {report, check} X {predicate, mapping}.
I wonder how UX would be when things don't work as expected.

@ldemailly commented on Wed Oct 04 2017
IMO it's not similar because the compiler doesn't tell you you should catch said exception
the default/least surprise (and smallest config input/least inconvenience to authors)
is to have 1 or 2 level of default (per type and optional per attribute) and only throw if specifically asked to throw vs the other way around (ie a throw_if_nil(attribute.foo))

I worked on proto3, gRPC and Google APIs, and contributed to many design decisions there. Based on our experience working with many APIs, I highly recommend Mixer to use proto3 default semantics, e.g. every attribute has default value of 0, '", [], or {}.
The reason is that mixer client and mixer will always be out of sync in practice, and there is no way to tell the difference. Using proto3 natural defaults is the simplest and safest choice, because all proto3 based APIs work this way.
When we designed proto3, we had a decade of production experience with proto2. The proto3 default value semantics match the real world much better than proto2. Nowadays, thousands of products are using proto3 based APIs, and this design decision stands well in the real world.

We can stick to proto3 defaults.
However the default values may not be valid or reasonable, as mixer has more data types than proto3 elementary types.
Like we said before there is no reasonable default for data type email_address.
The current mixer protocol has ability to detect presence even though it is proto3. That is why we have the | operator which selects the first “present” attribute.
It puts the onus on the operator to explicitly provide default values at the point of use.

having to sprinkle | "unknown"all over  is quite a sign that something is wrong, don't you agree?
because some type don't have a good default (btw empty is a fine default for an email) doesn't mean every single rule/line needs to have one specified or risk an error

I totally agree with Laurent.
After working with thousands of proto APIs, I am pretty confident that we
don't need default or presence in general. Developers are just fine without
them.
If you let operators choose their defaults, each one will choose something
different. No one can ensure another person's config. Why empty string is
not good enough for email address? Does anyone want to learn how to spell
"unknown" in Korean?
Mixer will be far better off if we remove presence entirely and force
everyone to use proto3 defaults. 2% people will be upset, but the global
consistency and simplicity will pay off hugely.

This was a valid concern. Improvements here would have made the lives of operators better.
But, there is no progress being made here, and work is shifting to the new architecture -- implying changes in config models, etc. As a result, this request for enhancement has been overcome by events. I'm going to close this issue.
We can revisit this in the context of any CEL-based tooling we build for future Istio extensions.


Improvement in backend file structure. #356

closes #356
Here's a short summary of the changes made to the project structure and organization:

File Organization:

Introduced separate directories (config, models, routes, controllers, middleware) to organize different components of the application logically.

Configuration (config/config.js):

Centralized configuration variables (JWT_SECRET, mongoURI) into a dedicated file (config/config.js).

User Model (models/user.js):

Defined the Mongoose schema and model for the User entity in models/user.js.

Routing (routes/router.js and routes/auth.js):

Created a main router file (routes/router.js) to combine all route modules and mount them under /api.
Implemented authentication routes (/signup and /login) in routes/auth.js.

Controllers (controllers/authController.js):

Separated route handling logic into controller functions (signup and login) within controllers/authController.js.

Middleware (middleware/authMiddleware.js):

Added JWT authentication middleware (middleware/authMiddleware.js) to verify and decode JWT tokens.

Main Application Entry (index.js):

Consolidated Express setup, middleware registration, MongoDB connection, route mounting, and server initialization in index.js.
Included error handling middleware (errorHandler.js) for centralized error management.

.gitignore:

Created a basic .gitignore file to exclude commonly ignored files and directories from being tracked by Git.

These changes aim to improve maintainability, separation of concerns, and overall organization of the Node.js application, following best practices for project structure and module separation. Each component (models, routes, controllers, middleware, config) now handles specific responsibilities, enhancing code clarity and scalability.

Kindle Review and merge Pull request.


Rope

Description
This extension adds the ability to add a swinging rope to your game.
How to use the extension
No response
Checklist

[X] I've followed all of the best practices.
[X] I confirm that this extension can be integrated to this GitHub repository, distributed and MIT licensed.
[X] I am aware that the extension may be updated by anyone, and do not need my explicit consent to do so.

What tier of review do you aim for your extension?
Community (Unreviewed)
Example file
Rope.zip
Extension file
rope.json

This is the first version


Update the rewards payout flow to support transactions via the Polkadot API for Substrate wallets.

Addressed in #1966


[BUG]CMS components -' Four columns, boxed' the pictures are not shown in the right places

Describe the bug
Block category 'Images' -' Four columns, boxed'' the pictures are shown one after another instead of in four columns.
How to reproduce
Steps to reproduce the behavior:

Go to 'categories' from Shopware
Select 'Clothing'-'Movies & Toys' from category structure
Go to 'Layout assignment'
Click 'Edit in designer' button
Click 'Settings' icon
Click 'block' icon
Select block category 'Images'
Add ' Four columns, boxed'
Click 'Save' button in the upper right corner
Go to subcategory 'Movies & Toys' on our website
See the error

Expected behavior
Pictures should be displayed in four columns and look the same as in Shopware layout.
Actual behavior
Pictures are displayed in wrong places - one under another.
Screenshots
' Four columns, boxed' block in Shopware 'Shopping Experiences' layout:

' Four columns, boxed' block on the website looks like this:

Devices (please complete the following information):
All devices

It is related to #509 and it will be resolved there