Add tests to improve coverage

Added Unit Tests for:

FilterPastTeamCommand
HelpCommand
Person
HelpCommand

Added Loggers for:

UndoCommand
RedoCommand

Codecov Report

Merging #159 (3f28f6a) into master (9ced662) will increase coverage by 2.38%.
The diff coverage is 100.00%.

@@             Coverage Diff              @@
##             master     #159      +/-   ##
============================================
+ Coverage     72.44%   74.82%   +2.38%
- Complexity      601      634      +33
============================================
  Files            88       88
  Lines          1876     1879       +3
  Branches        217      217
============================================
+ Hits           1359     1406      +47
+ Misses          434      396      -38
+ Partials         83       77       -6

Impacted Files
Coverage Δ

...a/seedu/address/model/person/UniquePersonList.java
87.03% <ø> (+4.58%)
:arrow_up:

...java/seedu/address/logic/commands/RedoCommand.java
100.00% <100.00%> (ø)

...java/seedu/address/logic/commands/UndoCommand.java
100.00% <100.00%> (ø)

...c/main/java/seedu/address/model/person/Person.java
96.61% <0.00%> (+10.16%)
:arrow_up:

...c/main/java/seedu/address/model/team/SkillSet.java
94.28% <0.00%> (+12.85%)
:arrow_up:

...ava/seedu/address/model/person/GithubUsername.java
78.26% <0.00%> (+17.39%)
:arrow_up:

src/main/java/seedu/address/model/Model.java
100.00% <0.00%> (+33.33%)
:arrow_up:

...java/seedu/address/logic/commands/HelpCommand.java
86.66% <0.00%> (+56.66%)
:arrow_up:

.../address/logic/commands/FilterPastTeamCommand.java
100.00% <0.00%> (+100.00%)
:arrow_up:

Continue to review full report at Codecov.

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

Looks good to merge!


Java Error when close program

I have this error everytime I close the program.

Thanks, this is fixed in next release (0.1.1).  Will publish tomorrow

0.1.1 is released, closing this now.


Reference to a canonical module in values

I propose adding the following section to the specification:

Any value may have a reference to a canonical module that works with values of that value's type. The reference should be in the static-land/canonical property. For example:
const ListModule = {
  of(x) {
    return {'static-land/canonical': ListModule, data: [x]}
  },
  map(f, v) {
    return {'static-land/canonical': ListModule, data: v.data.map(f)}
  }
}

In case a value has a reference to a canonical module, that module must produce values with references to itself. In the following example, list is an incorrect value, because ListModule2 does not produce values with references to itself:
const ListModule2 = {
  of(x) {
    return {data: [x]}
  },
  map(f, v) {
    return {data: v.data.map(f)}
  }
}

const list = {'static-land/canonical': ListModule2, data: [1]}

Note that the ListModule2 here is correct. Only the list value doesn't follow the specification.

This will allow for generic code without passing modules. For example:
function lift2(f, a, b) {
  const T = a['static-land/canonical']
  return T.ap(T.map(a => b => f(a, b), a), b)
}

lift2((x, y) => x + y, ListModule.of(2), ListModule.of(3)) // ListModule.of(5)

Any thoughts on the idea itself, or specific details, or wording of the section?
This idea was discussed before in fantasyland/fantasy-land#199

👍 on the proposal. Having modules to pass around is great, however type-class instances are meant to be coherent and static-land needs a protocol to specify what are THE type class instances for a certain type.

Ah, one small suggestion — I don't necessarily like that static-land/canonical should be an instance method. For one, this is because having a global, per type dictionary is what separates type classes from OOP classes, so that dictionary really belongs to the "constructor" when dealing with JS classes, because otherwise it signals the wrong semantics — i.e. 2 different values inhabiting that type cannot signal 2 different "canonical" definitions.
Consider this type:
class Box {
  constructor(value) { this.value = value }
  equals(that) { return that && this.value === that.value }
}

const BoxModule = {
  equals: (x, y) => x.equals(y)
}

I would rather pass around static-land/canonical as a static property of Box instead of as a property on Box instances. Because you can always get to static-land/canonical from a Box instance like boxed.constructor['static-land/canonical']. The TypeScript compiler will not type-check this, but that's a small price to pay.
Also, I would rather have it as a function (thunk), to avoid any declaration problems when the "module" is defined separate from the class:
class Foo {
  constructor(value) { this.value = value }
  equals(that) { return that && this.value === that.value }

  static ["static-land/canonical"] = () => FooModule
}

const FooModule = {
  equals: (x, y) => x.equals(y)
}

Thank you for the suggestions! I agree that making static-land/canonical static property will signal the right semantics. But this will require programming style that uses Classes, and I want static-land to support style based on simple objects. For example, we could define a Maybe type like this:
// @flow
type Maybe<T> =
  | {tag: 'some', value: T}
  | {tag: 'nothing'}

const MaybeModule = {
  of<T>(x: T): Maybe<T> {
    return {tag: 'some', value: x, 'static-land/canonical': MaybeModule}
  },

  map(f: A => B, x: Maybe): Maybe {
     if (x.tag === 'nothing') {
       return x
     }
     return MaybeModule.of(f(x.value))
   }
}

I really like this style, and Flow seems to promote using it via its documentation https://flow.org/en/docs/types/unions/#toc-disjoint-unions . To limit us to use of Classes would be a big loss.
Also not sure about the thunk, we could always write it like this:
class Foo {
  constructor(value) { this.value = value }
  equals(that) { return that && this.value === that.value }
}

const FooModule = {
  equals: (x, y) => x.equals(y)
}

Foo.prototype["static-land/canonical"] = FooModule

// or, if we want to use static property:
// Foo["static-land/canonical"] = FooModule

And from the semantics perspective, using thunk would suggest that static-land/canonical may change over time.
Although maybe adding a property later like this may cause issues with TypeScript, Flow, etc. Maybe to use thunk is a good idea indeed.

But this will require programming style that uses Classes, and I want static-land to support style based on simple objects.

Would this still be possible? Could one define constructor manually?
   of<T>(x: T): Maybe<T> {
-    return {tag: 'some', value: x, 'static-land/canonical': MaybeModule}
+    return {tag: 'some', value: x, constructor: {'static-land/canonical': MaybeModule}}
   },

Yes, from a strictly technical perspective both locations (x.constructor['static-land/canonical'] and x['static-land/canonical']) are similar. I think this is more like a messaging issue, e.g. which programming style specification promotes and which discourages. If we use x.constructor['static-land/canonical'] the simple-objects style will be a second class. But with x['static-land/canonical'] both styles will be treated as a first class.

BTW, I think we should use __staticLandCanonicalModule__ instead of static-land/canonical. Two reasons:

Adding "module" at the end should make code easier to understand.
Avoiding "-" and "/" should safe us from any potential issues like this one https://github.com/facebook/flow/issues/2482 .

And from the semantics perspective, using thunk would suggest that static-land/canonical may change over time.

In the context of FP, in which we are, that cannot be — a thunk signals just lazy evaluation, but the call itself has referential transparency. It may indeed return a different reference, or a new reference every time it gets called, but that doesn't matter, being an implementation detail.
By not making it a thunk the API is imposing an evaluation strategy.
On the naming change, here's my 2 cents:

Adding "module" at the end should make code easier to understand.

Ease of understanding is irrelevant for this particular field, because this field is not meant for users, being middleware — or in other words it is solely for library authors that want to build generic code making use of constrained parametric polymorphism, making use of those type classes, in which case they've got bigger problems than understanding the purpose of this field.
Also in my mind "module" as a word is not such a good name, because in other languages at least it is a synonym for namespaces. Yes, I know of ML modules, but ML doesn't do type classes and in the context of type classes these are type class instances 😉
I don't mind "module", I'm just saying that for me at least "module" is not necessarily clarifying anything — but then again I don't really care.

Avoiding "-" and "/" should safe us from any potential issues like this one facebook/flow#2482 .

I think that particular issue is a red herring btw:

TypeScript supports liberals like that, it's only Flow that has this issue and it's probably a very temporary issue — in a year from now, if Flow keeps evolving, I'm sure that it will get fixed
adding typing for these fields is kind of useless, because they'll be used dynamically at the call-site anyway

And for instance the issue mentions fantasy-land/of. Well, it would be nice to have it described with types, but speaking of Fantasy-Land, I don't see the point when you can't describe the monadic bind with types as described in Fantasy-Land — the only language that I worked with and that can describe flatMap / chain as an interface method is Scala and even there it's a pain in the ass, with the interface becoming so parametrized that it ends up being only useful for implementation sharing, but useless for subtype/OOP polymorphism. And if you can't describe an Applicative or Monad interface, then the point of having a typed fantasy-land/of is completely lost.
I have a library at https://github.com/funfix/funfix and I'm rebooting the described type classes to be based on static-land, with the data types also exposing Fantasy-Land methods and I didn't even bother to describe those methods with types, because it's actually better to have them dynamically compiled, due to the obvious code duplication (e.g. trying to build a method that infers them from the object's own interface, see code sample)
But to get back to the point, static-land/canonical is much better precisely because it forces people to use literal properties.
The problem with regular properties such as __staticLandCanonicalModule__ is that compilers like Google Closure will minify them, or even remove them completely via tree shaking, unless those properties get specified as literals.
And given that something like static-land/canonical is a property used dynamically, then it really needs to be there when people do object["static-land/canonical"] interrogations, with or without an aggressive compiler such as Google Closure being used.

In the context of FP, in which we are, that cannot be

Right, but in JavaScript world this might still send a wrong signal. Although we could explain this in specification as clear as possible, which should help.
There is a similar case with the empty, people always ask why it's a function https://github.com/rpominov/static-land/issues/37 https://github.com/fantasyland/fantasy-land/pull/164 . Not sure if evaluation strategy argument applies to empty though, I always thought that it's a function manly for consistency.

Ease of understanding is irrelevant for this particular field, because this field is not meant for users

I was thinking of a person not familiar with static-land reading source code of a library that implements say Maybe.

Also in my mind "module" as a word is not such a good name

But yes, "module" will only confuse people who're not familiar with this specification 😅
I agree it is a bad idea to add it.
Regarding enforcing name to be string literal, I'm also not too concerned with the particular issue I've linked to. I just worry we might have issues that we don't anticipate right now. That was the case with that issue with Flow, when we added namespaces to Fantasy Land. It's only an example of unanticipated issue.
Didn't know about problem with Google Closure, this seems like a good argument for enforcing literals!

Yes, from a strictly technical perspective both locations (x.constructor['static-land/canonical'] and x['static-land/canonical']) are similar.

Aren't the following two technically similar?

x.constructor['static-land/canonical'].map
x.constructor['fantasy-land/map']

And aren't therefore the following two also similar?

x['static-land/canonical'].map
x.constructor['fantasy-land/map']

This will allow for generic code without passing modules.

function lift2(f, a, b) {
  const T = a['static-land/canonical']
  return T.ap(T.map(a => b => f(a, b), a), b)
}

But this generic lift2 has lost the ability to operate using differing instances on the same type, this in my opinion is what sets Static Land apart from Fantasy Land. Now Static Land users would need two kinds of generic functions: one that dispatches to canonical, and one that dispatches to the given type representative. The same can be achieved in Fantasy Land:
function canonicalLift2(f, a, b) {
  const ap = f.constructor['fantasy-land/ap']
  const map = f.constructor['fantasy-land/map']
  return ap(map(a => b => f(a, b), a), b)
}

function coercedLift2(T, f, a, b) {
  const ap = T['fantasy-land/ap']
  const map = T['fantasy-land/map']
  return ap(map(a => b => f(a, b), a), b)
}

Nobody ever uses it like shown in coercedLift2, though. I don't think this is a problem with the spec, but rather with communication. In Fantasy Land, all reasoning starts at the value.

Unless I'm missing something, it seems to me that this change puts Static Land in exactly the same place as Fantasy Land. The one major difference being that Static Land has much better communication, as you seemed to suggest:

I think this is more like a messaging issue, e.g. which programming style specification promotes and which discourages.

Is this indeed the intent of this change? To gain the same capabilities that Fantasy Land has, but improve upon the way it's communicated? Or did I miss something, and are the capabilities different somehow?

Yeah, good question, @Avaq ! What are we trying to do here, we already have Fantasy Land that can do dynamic dispatch. I have concerns like "will it split the community?", "will it put more burden on library authors, having to think about two specifications?", etc. I don't know the answers, and trying to be very cautious — just opened an issue to discuss this so far. My reasoning is the following: this will make Static Land technically as capable as Fantasy Land while keeping all advantages of Static Land (https://github.com/rpominov/static-land#pros). So overall we might end up with a more capable specification. But does it worth it? I don't know.

Now Static Land users would need two kinds of generic functions

I don't think people will have to use two variations at the same time. A person should choose do they want to pass around modules (use lift2(T, f, a, b)) or they want to use dynamic dispatch (lift2(f, a, b)). And then just stick with the preferred style. Not sure I understand you correctly though, maybe you've meant something else?

@Avaq

But this generic lift2 has lost the ability to operate using differing instances on the same type, this in my opinion is what sets Static Land apart from Fantasy Land. Now Static Land users would need two kinds of generic functions: one that dispatches to canonical, and one that dispatches to the given type representative.

I don't think having the ability to operate on different instances is useful at all.
Type classes work reliably only when you can count on their coherence, meaning you're only allowed to have one instance of a type class per type in the whole project. For example if you can't rely on a global equality or ordering notion for a given type, then your generic HashMap implementation is probably screwed.
Edward Kmett touches on the importance of coherence in this presentation, doing a better job than I could: https://youtu.be/hIZxTQP1ifo
The actual advantage that static-land has and what sets it appart as the right approach going forward, is that Fantasy-Land as currently defined is anti-types. You can't define a reasonable Monad interface for Fantasy-Land in either TypeScript or Flow and that won't change any time soon.

Thank you for your replies. I'm really trying to gain an understanding of how Static Land and Fantasy Land differ fundamentally, especially after this change.

this will make Static Land technically as capable as Fantasy Land while keeping all advantages of Static Land -- @rpominov

I want to go over these advantages:

No name clashes. Since a module is just a collection of functions that don't share any namespace we don't have problems with name clashes.

This actually changes with the introduction of static-land/canonical. I believe the ['static-land/canonical'].map property has just as much chance of clashing as the constructor['fantasy-land/map'] property.

We can implement many modules for one type, therefore we can have more than one instance of the same Algebra for a single type. For example, we can implement two Monoids for numbers: Addition and Multiplication.

I always thought this is what set Static Land apart, but according to @alexandru, we cannot have this (unless I misunderstood, see below). Furthermore, this does not apply when working with dynamically dispatched abstractions.

We can implement modules that work with built-in types as values (Number, Boolean, Array, etc).

Except that they cannot have the static-land/canonical property.

I don't think people will have to use two variations at the same time. A person should choose do they want to pass around modules or they want to use dynamic dispatch -- @rpominov

But when they choose module passing, they are using Static Land pre-#45. When they choose dynamic dispatch, they are essentially using Fantasy Land.

Type classes work reliably only when you can count on their coherence, meaning you're only allowed to have one instance of a type class per type in the whole project. -- @alexandru

What you're saying here makes sense. I must've misunderstood something. In the past @joneshf wrote about the ability to have multiple implementations of a type class' instance on the same type, using as an example Applicative Array, I thought that's one of the things that spawned Static Land.

You can't define a reasonable Monad interface for Fantasy Land in either TypeScript or Flow

I always thought this is simply because of the lack of support for higher kinded types. Eg F<T> where F is also a generic. So with the following two assumptions:

this proposal gives Static Land exactly equal capabilities to Fantasy Land ; and
TypeScript cannot implement Monad because of the lack of higher kinded types,

I don't see how Static Land brings a solution to this problem. Which of these assumptions I made are wrong?

You can't define a reasonable Monad interface for Fantasy Land in either TypeScript or Flow

I always thought this is simply because of the lack of support for higher kinded types. Eg F where F is also a generic.

It's not the lack of higher-kinded types. funfix and fp-ts are using an encoding for HKTs of which I ranted about, due to TypeScript 2.7 breaking it, but that's fixable — as long as the language supports generics, then this is possible too.
The problem is actually the co/contra-variance of functions that arises naturally from inheritance (and usage of this of course).
The native description of chain as an interface with single dispatching looks like this:
interface Chain {

  chain(f: A => Chain): Chain
}

But this is wrong, because you can't do this:
class Box extends Chain {

  chain(f: A => Box): Box

}

Should be obvious why, but it's because functions have contra-variant behavior in their parameters. Older versions of TypeScript might not complain, but TypeScript isn't a sound language.
And the second reason for why the contra-variant behavior here is entirely correct is because different monadic types don't compose. For example this makes no sense whatsoever:
promise.chain(_ => list)

list.chain(_ => promise)

The only language I worked with and that allows for a correct Monad definition as an OOP interface describing methods (that does single dispatching) is Scala. And in addition to higher-kinded types, for it you need:

self types
self-recursive types

Here's how it looks like, translated to TypeScript, if TypeScript actually supported HTKs AND self types and self-recursive types:
interface Chain<A, Self extends Chain> { self: Self =>

  chain(f: (a: A) => Self): Self
}

It is obvious that Chain<A, Self extends Chain> is not really a type that you can easily use for describing generic functions. But that's not the only problem, the other problem is that monads need the Applicative.of (or pure or return, as named in other languages).
So you actually need this:
interface Monad<A, Self<T> extends Monad<T, Self>> { self: Self =>

  chain(f: (a: A) => Self): Self

  companion: MonadBuilders<Self>
}

interface MonadBuilders<F extends Monad> {

  of(a: A): F
}

Now compare all that crap, which is in fact only useful for implementation inheritance (used for Scala's collections, but with mixed results), with this:
interface Monad<F<_>> {

  chain((a: A) => F, fa: F): F

  of(a: A): F

}

Which is actually what we have right now in Funfix/fp-ts, with the HTKs encoding:
interface Monad<F> {

  chain((a: A) => HK<F, B>, fa: HK<F, A>): HK<F, B>

  of(a: A): HK<F, A>
}

So you were able to implement HTKs encoding for Static Land because it does not use this? Other than the use of this I see no difference between Fantasy Land and Static Land;
//static land dynamic dispatch
function map (f, m) {
  const dispatch = m['static-land/canonical'].map
  return dispatch (f, m)
}

//fantasy land dynamic dispatch
function map (f, m) {
  const dispatch = m.constructor['fantasy-land/map']
  return dispatch.call (m, f)
}

//static land static dispatch
function map_ (T, f, m) {
  const dispatch = T.map
  return dispatch (f, m)
}

//fantasy land static dispatch
function map_ (T, f, m) {
  const dispatch = T['fantasy-land/map']
  return dispatch.call (m, f)
}

No, I just described F-bounded polymorphism and this makes all the difference in the world.

This all seems to me like a great thing! I actually would like to see Fantasy Land itself go down this road, and hope that one day the two specs can merge in such a way that all beneficial properties are kept. :)

I also wish this would happen, and this is sort of proposed in fantasyland/fantasy-land#199. I just don't know what I can do, I'm up for anything.

Something else entirely: Since this is the PR that introduces association between values and their classes, perhaps this is the best place to discuss another idea related to it.
Namely encoding the major spec version into the association. Something like this:
{ 'static-land/canonical@2': Module, value: x }

The @2 part there contains the major version of the Static Land spec. This would allow for the spec to make breaking changes, and dispatchers/types to implement one or more versions of the spec.
Fantasy Land did this by accident. When it introduced a breaking change in the spec (flipping the argument order of ap), it also changed the name of the property (from ap to fantasy-land/ap), which now allows Fluture to implement both specs, satisfying old dispatchers as well as the ones that kept up with the spec.
I think it would be beneficial to include this from the start in a formalised way. I took the syntax from sanctuary-type-identifiers, where I introduced something similar to this idea.

@Avaq that's actually a pretty cool suggestion. Breaking changes shouldn't come lightly, but when they do, it's pretty cool to namespace versions IMO.
Watched a cool presentation by Rich Hickey where he's campaigning against breakage in version upgrades, in his own words semantic versioning being a recipe for documenting breakage: https://www.youtube.com/watch?v=oyLBGkS5ICk

There is a separate issue about versioning #1 (very first thing I thought about, haha). I also hope we just manage to avoid breaking changes entirely, could be hard to do though.

@rpominov if you have the energy, we can collaborate on that unified repository. I can get involved and I think we can find others as well. Somebody has to start the work, until inertia gets built.
For the specification, it's mostly going to be a copy/paste job, plus corrections. From my experience, we'll move slowly, but if we can do a small bit of work each other week, then we'll crack it eventually.
I'd also like some (light) types in the repository, in addition to that spec and we can do both TypeScript and Flow. Plus laws specified as code as well. Having to read text in a pseudo-language is harder than it is to read some actual code. But this issue is totally up for debate and unimportant right now.

Also, a unified repo should probably fork the current Fantasy-Land repository. It's mostly a social issue — contributors are fond of their contributions and forking without actually forking via Git erases valuable history.

Plus laws specified as code as well.

I've been working on fantasyland/fantasy-laws#1, which is somewhat related.

Sounds interesting, I can't offer much more that's not already in static-land, but together we could compose something better, and present it better. Starting from actually forking fantasy-land sounds like a great idea. I can make a PR to the fork with initial transition. It will look a lot like replacing Fantasy Land with Static Land, but at least I won't have to do such PR to the main repository 😅
Or if anyone else want to make that PR that will be even better, I'll be there for discussions / review in any case. This looks like a plan for a beginning and we could see where this will get us.

It will look a lot like replacing Fantasy Land with Static Land

If the benefits are laid out clearly and a migration path is presented, I expect this change would be widely supported.

After thinking a bit more, I've decided to open a PR in the main Fantasy Land repository after all, and see what happens. Will do it soon, get ready 😱

@rpominov great, but I'd fork the repo into another repository in order for collaboration to happen, otherwise we are limited by comments on the PR and that's going to generate a ton of noise.
It's better for that PR to be polished imo, otherwise there will be 2 threads of conversations going on: (1) possible improvements + (2) do we want this or not and it would be good to get the possible improvements out of the way.
For example, given that this is a breaking change anyway, I'd like to talk about:

function signature convention
naming

Given we have that unified repo, might as well talk there on specifics. Opened my first issue: https://github.com/fantasyland/unified-specification/issues/3

Yeah, sorry about the rush. I've got a little too excited for a moment and didn't realize you have many fresh ideas. The fantasyland/unified-specification repository probably a good place to discuss them, and we can create a temporary fork later as well.

I've started to prepare the temporary fork here https://github.com/rpominov/fantasy-land

@alexandru the repository here https://github.com/rpominov/fantasy-land is more or less ready for the PR, you might want to take a look. I've already created a PR about thunks there https://github.com/rpominov/fantasy-land/pull/2 .
In any case, I'm going to wait for some time before a PR to main Fantasy Land repo, to give everybody opportunity to propose any changes.

Is this gonna happen, or should this proposal be removed from the readme?


Fund Admin pallet: Update permissions

This PR solves the following issues:

Fix #301
Fix #288

@tlacloc PR is ready!


A script to run prediction on any (unlabeled) image. And some small addition to Utils.

Added a function Single_demo to Utils to perform prediction on unlabeled images.
Added test_any_img script for same purpose.
WBR Paul

Thank you very much. I will review shortly.

Otherwise, I will just accept the pull request, and probably modify by my own in the near future,
I think it would be the best course of actions. Because I'm more into quick dirty hacks than a proper programming :( You may put this requirements into ToDo so maybe someone (or even me) will make those sooner than you. :)

Otherwise, I will just accept the pull request, and probably modify by my own in the near future,

I think it would be the best course of actions. Because I'm more into quick dirty hacks than a proper programming :( You may put this requirements into ToDo so maybe someone (or even me) will make those sooner than you. :)

I will accept the merge request then. Thank you very much for the contribution!

Otherwise, I will just accept the pull request, and probably modify by my own in the near future,

I think it would be the best course of actions. Because I'm more into quick dirty hacks than a proper programming :( You may put this requirements into ToDo so maybe someone (or even me) will make those sooner than you. :)

I will accept the merge request then. Thank you very much for the contribution!

Thank You. I greatly appreciate this DeepLab implementation of yours. It is really neat and clean and well documented. Thank You wery much. W.B.R. Paul.


cffi dependency

ImportError: No module named 'cffi'. Necessary for both mac and linux installations

Except that you should never install anything from pip with superuser permissions (it can execute any code).


ci: add env check

Description
Types of changes

[ ] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to change)
[ ] Documentation (change to docs, jsdocs, comments, etc)
[ ] Style (change to code style, formatting, and/or linting)
[ ] Refactor (change which doesn't affect functionality)
[ ] Other (change which doesn't fit into any of the above categories)

Checklist

[ ] My code follows the code style of this project.
[ ] I have updated the documentation accordingly if needed.

:tada: This PR is included in version 0.0.34 :tada:
The release is available on npm package (@latest dist-tag)
Your semantic-release bot :package::rocket:

:tada: This PR is included in version 2.0.30 :tada:
The release is available on npm package (@latest dist-tag)
Your semantic-release bot :package::rocket:

:tada: This PR is included in version 1.0.21 :tada:
The release is available on npm package (@latest dist-tag)
Your semantic-release bot :package::rocket:

:tada: This PR is included in version 1.0.12 :tada:
The release is available on npm package (@latest dist-tag)
Your semantic-release bot :package::rocket:

:tada: This PR is included in version 1.0.19 :tada:
The release is available on npm package (@latest dist-tag)
Your semantic-release bot :package::rocket:

:tada: This PR is included in version 1.0.27 :tada:
The release is available on npm package (@latest dist-tag)
Your semantic-release bot :package::rocket:

:tada: This PR is included in version 1.0.22 :tada:
The release is available on npm package (@latest dist-tag)
Your semantic-release bot :package::rocket:


Json schema and examples

Fixes #344

updated. PTAL.

On Thu, Apr 07, 2016 at 07:14:17AM -0700, Vincent Batts wrote:

updated. PTAL.

It looks like fc6670d4 → 1e2a72d2 addresses all the points raised so
far, except for the version issue which we aren't sure how to handle
1.
There are still some zero values that don't make sense (e.g. in
linux.resources.cpu.period, but 2 has “The minimum quota allowed for
the quota or period is 1ms.”).

@wking fair. Though it also says that a -1 to quotas indicates no restriction, though we have it as a uint64. That does not line up.
I've updated the example.

@vbatts Could you address the latest comments from @wking ?

@mrunalp done.
PTAL.

a341686 → c1612af look good to me, although it's still pretty easy to
find apparently-meaningless example values 1.  I thought part of the
purpose of this PR was fixing these meaningless examples (see also
#348), but we can obviously push some of that to follow-up PRs /
issues if we don't want to check them now.

I think we can do cleanups in follow on PRs. This LGTM overall.

@crosbymichael @vishh PTAL

LGTM


PnP review

Reproducing the action items part from Geraint's review here:
Are proper references made to related work within the LSC? - Generally, yes. A few quick comments below.

[x] On the first page you discuss how 'Once potential candidates are found, ...'. It isn't clear if the citations are for the underlying code packages or applications? E.g. the Biwer et al paper used Kombine [Farr et al 2015] and emcee_pt [Vousden et al 16]. So if citing Speagle for Dynesty, then these would be reasonable?
[x] One or two more waveform references needed in introduction. When citing EOB models, please cite Bohe et al [cited later anyway] and Cotesta et al for the latest generation of current EOB models.
[x] Likewise, please cite Garcia-Quiros:2020qpx and Pratten:2020fqn in the general Phenom citations as the latest generation of Phenom models. A lot of these are cited later in the text either way.
[x] For the methods to speed up PE on Page 8, a citation to Leslie:2021ssu would be reasonable as a way to tackle relative binning using waveform models with precession and higher multipoles.
[x] Please add a citation to Cornish:2010kf, as Neil's work was foundational here.
[x] I would also cite Smith:2016qas as the PhenomPv2 ROQ, as this has been very widely used.

No other actionable comments provided.

Think I've added everything now!


gRPC "socket closed" service exception still occurring

Hey there @saranshdhingra could you share what OS you're running on and what version of the gRPC library you're using where you do not see the "socket closed" issue?  I'm inclined to think this is an issue in the network stack below gRPC or perhaps how gRPC is interacting with the native network stack.

We are running on Ubuntu 18.04 with gRPC v1.28.1 and see this issue with some frequency (on the order of 10s of minutes during a long-lived bi-directional streaming connection).
I'm curious if this issue was solved or if it just did not repro in your environment and hence was closed?  Thanks!
Originally posted by @jaryder in https://github.com/googleapis/google-cloud-php/issues/2427#issuecomment-1317609015

@meredithslota this issue is still ongoing and it's important to let others follow the original thread here https://github.com/googleapis/google-cloud-php/issues/2427

@lukasgit Apologies for the confusion; the linked issue #2427 was marked closed by @saranshdhingra back in April 2022 and I didn't want the last comment to be lost. It's cross-referenced so that previous repro information can still be useful, but if you have current repro steps, please include them here. Thanks!

@saranshdhingra could you help triage this issue, it is out of SLO.

@bcoe @meredithslota I will try to look into this issue this week. It's been a bit difficult to replicate it.
I'll try to find the last environment setup I had for this and continue from there.
Thanks a lot for your patience on this @lukasgit

Reduced priority since it doesn't blocking shipping releases.

@saranshdhingra - Did we find anything on this issue?

I got both issue, "socket closed " and "go away " in python grpc server side. seems like nothing has been resolved lately

So, I am not really sure how I can proceed with this issue as I have not been able to replicate it.
Given that it's a response given by the backend APIs, all we can do at the Client Library's front is retry it, which we are doing.
If someone, can find an instance where the UNAVAILABLE code is not leading to a retry, then I would certainly try to dig deeper. I have tested the retry functionality and that seems to be working as intended.
For anyone who wants to control the retry logic can use the grpcRetryFunction option when they make API calls and test if the retry is in fact happening or not.
But, if there is something at the GRPC extension/product API level, I am afraid, the conversation needs to happen in the respective repository.
After all this while, not being able to give a concrete answer to this is not what I had hoped, but this is the best I can say when I haven't been able to replicate it.
I will be closing this for now, but if anyone encounters an instance where the library doesn't retry in the case where it is supposed to, please reopen this, I would certainly look into it.

A similar issue sporadically occurs when using Bigtable client, @saranshdhingra.
throw(/var/www/html/vendor/google/gax/src/ServerStream.php:84)
Google\ApiCore\ApiException.__construct(/var/www/html/vendor/google/gax/src/ApiException.php:267)
Google\ApiCore\ApiException.create(/var/www/html/vendor/google/gax/src/ApiException.php:148)
Google\ApiCore\ApiException.createFromStdClass(/var/www/html/vendor/google/gax/src/ServerStream.php:84)
Google\ApiCore\ServerStream.readAll(/var/www/html/vendor/google/cloud-bigtable/src/ResumableStream.php:100)
Google\Cloud\Bigtable\ResumableStream.readAll(/var/www/html/vendor/google/cloud-bigtable/src/ChunkFormatter.php:168)
Google\Cloud\Bigtable\ChunkFormatter.readAll
Generator.current(/var/www/html/vendor/google/cloud-bigtable/src/Table.php:331)
Google\Cloud\Bigtable\Table.readRow(/var/www/html/vendor/oat-sa/bundle-bigtable-document-manager/Driver/BigtableDocumentDriver.php:86)

I'm not entirely sure if it should be like that, but I'm guessing the problem could be addressed by adding the same retry mechanism configuration to this piece of configuration.


请问可以再发布一下预训练的权重文件吗

底下的文件链接已经不能下载了

Hi @Maltose0118, thank you for the reminder. The original data were stored in my school's google drive which aren't usable anymore. I have updated those links except for training data of DTU and DeMoN, which are too large and I'm still finding place to store them.


Powershell Terminal Fails to Fully Load

Issue Type: Bug
My default terminal in VS Code is PowerShell.  I've noticed that after starting VS Code and switching to the Terminal tab (at the bottom of VS Code), the terminal doesn't fully load.  I have to touch into the terminal window, and often press the Enter key a few times.  Doing so will get the terminal to load to a point where I can use it.
VS Code version: Code 1.33.1 (51b0b28134d51361cf996d2f0a1c698247aeabd8, 2019-04-11T08:27:14.102Z)
OS version: Windows_NT x64 10.0.17763

System Info

Item
Value

CPUs
Intel(R) Core(TM) i7-6600U CPU @ 2.60GHz (4 x 2808)

GPU Status
2d_canvas: enabledchecker_imaging: disabled_offflash_3d: enabledflash_stage3d: enabledflash_stage3d_baseline: enabledgpu_compositing: enabledmultiple_raster_threads: enabled_onnative_gpu_memory_buffers: disabled_softwarerasterization: enabledsurface_synchronization: enabled_onvideo_decode: enabledwebgl: enabledwebgl2: enabled

Memory (System)
15.93GB (5.14GB free)

Process Argv

Screen Reader
no

VM
0%

Extensions (37)

Extension
Author (truncated)
Version

vscode-sidebar
Acr
1.1.2

bracket-pair-colorizer-2
Coe
0.0.28

vscode-markdownlint
Dav
0.26.0

docs-article-templates
doc
0.2.2

docs-authoring-pack
doc
0.1.2

docs-markdown
doc
0.2.4

docs-preview
doc
0.3.17

docs-yaml
doc
0.2.1

gitlens
eam
9.6.2

code-runner
for
0.9.8

docker-explorer
for
0.1.6

dotnet-test-explorer
for
0.6.6

vscode-pull-request-github
Git
0.6.0

rest-client
hum
0.21.2

azure-pipelines
ms-
1.147.2

vscode-azureappservice
ms-
0.13.0

vscode-azureeventgrid
ms-
0.1.1

vscode-azurefunctions
ms-
0.16.0

vscode-azurestorage
ms-
0.7.0

vscode-cosmosdb
ms-
0.10.1

vscode-logicapps
ms-
0.1.17

mssql
ms-
1.5.0

python
ms-
2019.3.6558

azure-account
ms-
0.8.2

azurecli
ms-
0.4.4

csharp
ms-
1.19.0

powershell
ms-
1.12.1

team
ms-
1.149.2

azurerm-vscode-tools
msa
0.5.0

vscode-docker
Pet
0.6.1

quicktype
qui
12.0.46

vscode-yaml
red
0.4.0

bash-debug
rog
0.3.4

arm-snippets
sam
1.4.13

code-settings-sync
Sha
3.2.9

code-spell-checker
str
1.6.10

vscode-icons
vsc
8.5.0

(1 theme extensions excluded)

Same Issue with vscode latest version and with windows 10 x64

This is a bug in Windows 10 1809, unfortunately we have no way to work around the issue so you will need to wait until you get the next version of Windows 10 (1903).
/duplicate https://github.com/Microsoft/vscode/issues/57803


WIP: Specify compressor version in requirements.txt

With its 2.0 release, django-compressor 2.0 dropped support for Django
1.7. Since Django 1.7 is still considered supported by
django-oscar-paypal, ensure using django-compressor 1.6 (which still
supported Django 1.7).
See also:
https://github.com/django-compressor/django-compressor/commit/e27fce758f0b11ba5fb5562c90832e02ac0006cf

@maikhoepfel This fixes the test build failure encountered in #121. Once this is merged, #121 can be merged too.

Lovely. After trying to be cleverer in #123, I gave up and cherry picked it across in https://github.com/django-oscar/django-oscar-paypal/commit/4d416b0474fdc2e4a047708daeba975fa32e583b.
Thank you.


ML 2.9 : Decision Trees Algorithm (V) #2783

Description 📜
Made a video presentation on a decision tree algorithm.
Fixes #2783

Type of change 📝

[x] Video (Animations, screen-recordings, presentations and regular explanatory films are all possibilties etc)

Domain of Contribution 📊

[x] Machine Learning

Checklist ✅

[x] I follow Contributing Guidelines & Code of conduct of this project.
[x] I have performed a self-review of my own code or work.
[x] I have commented my code, particularly in hard-to-understand areas.
[x] My changes generates no new warnings.
[x] I'm GWOC'21 contributor

Screenshots / Gif (Optional) 📸

@abhisheks008 @geeythree , Can you please kindly review the PR.
M. Ashish Reddy
Batch - 2

@ashish-reddy-20-08 PR Approved.


Compile a list of similarity and distance measures to implement

Binary similarity metrics
Similarity Coefficients for Binary Chemoinformatics Data: Overview and Extended Comparison Using Simulated and Real Data Sets
Roberto Todeschini, Viviana Consonni†, Hua Xiang, John Holliday, Massimo Buscema, and Peter Willett
Multivariate similarity metrics
Benchmarking of multivariate similarity measures for high-content screening fingerprints in phenotypic drug discovery
Felix Reisen , Xian Zhang, Daniela Gabriel, Paul Selzer


Fix startAt completely

Currently, startAt variable is renew at resume() called.
We have to fix startAt completely.

Resolved at #36


Monodevelop + Mono upgrade

I believe this PR has other changes that are not related to the mono updates.

Yes sorry but they were already merged so shouldn't cause any diff?

It's hard to review the PR with those changes, would you rebase please?

Ok will do

Rebased.

Built it locally, seems fine to me. Thanks.


[NO MERGE] Split quicktype into CLI and Core packages

@dvdsgl Please check whether this makes any sense.
I still have to remove some dependencies that aren't needed anymore.

Superseded by #868


Automated cherry pick of #7978

Cherry pick of #7978 on release-5.35.
/cc  @amyblais

/release-note-none

Trying to auto merge this PR.

Pull Request successfully merged
SHA:<PHONE_NUMBER>328ceff4b038668e8b10b5fa66ec78


After last update playlists' covers gone.

could you please mention your spicetify and spotify versions

Spotify for Windows
<IP_ADDRESS>2.g949d5fd0
Spicetify v2.16.1
can reproduce the issue on my end with above configurations.
we will try to fix that. @D4rckeyy thanks

Spotify for Windows
<IP_ADDRESS>2.g949d5fd0
Spicetify v2.16.1

could you please mention your spicetify and spotify versions

@D4rckeyy thanks
it precisely matches with mine
I'll try figure out what happened.

Hey, I'm having the same issue. Using the same version of Spotify and Spicetify as D4rckeyy. Cheers

@Asyx3 even i have this issue btw

I'm trying my best to fix it.

through trial and error here's my work around, I removed the whole  waitForElement([".main-rootlist-rootlistItem"], function () { function and replaced it with the one below. Its a little buggy as in some playlist on the left side are missing and when u click on a playlist that's in the middle of the list it resets the scroll position.  also needs css work but i hope this works and let me know if u find a better solution!
const cache = new Map();
async function fetchPlaylistData(url) {
const response = await Spicetify.CosmosAsync.get(url);
const { items, next } = response;
return [...items, ...(next ? await fetchPlaylistData(next) : [])];
}

async function addPlaylistIcons() {
while (!Spicetify || !Spicetify.Platform || !Spicetify.CosmosAsync) {
  await new Promise((resolve) => setTimeout(resolve, 100));
}

const playlistList = await new Promise((resolve) => {
  const interval = setInterval(() => {
    const element = document.querySelector("#spicetify-playlist-list");
    if (element) {
      clearInterval(interval);
      resolve(element);
    }
  }, 100);
});
const playlistData = await fetchPlaylistData("https://api.spotify.com/v1/me/playlists?limit=50");
const observer = new MutationObserver(async () => {
  observer.disconnect();
  await updatePlaylistList(playlistData);
  observer.observe(playlistList, { childList: true, subtree: true });
});

await updatePlaylistList(playlistData);
observer.observe(playlistList, { childList: true, subtree: true });
}

async function updatePlaylistList(playlistData) {
const playlistElements = await new Promise((resolve) => {
  const interval = setInterval(() => {
    const elements = document.querySelectorAll("#spicetify-playlist-list li a");
    if (elements.length > 0) {
      clearInterval(interval);
      resolve(Array.from(elements));
    }
  }, 100);
});

for (const element of playlistElements) {
  const [id] = element.href.split("/").slice(-1);
  const [type] = element.href.split("/").slice(-2, -1);
  let icon = cache.get(id);
  if (!icon) {
    switch (type) {
      case "playlist":
        const playlist = playlistData.find((p) => p.id === id);
        const image = playlist ? playlist.images[0] || {} : {};
        icon = {
          src: image.url,
          size: "72px",
        };
        cache.set(id, icon);
        break;
      case "folder":
        icon = {
          src<EMAIL_ADDRESS>          size: "72px",
        };
        cache.set(id, icon);
        break;
    }
  }

  if (icon.src) {
    element.style.backgroundImage = `url('${icon.src}')`;
    element.style.backgroundRepeat = "no-repeat";
    element.style.backgroundSize = `${icon.size}`;
    element.style.backgroundPosition = "center";
  }
}
}
addPlaylistIcons();

@clout2k Wow great work!
Ill test this out and try to improve it. If you can make this better, please open a pr
Thanks

@D4rckeyy @Asyx3 its being patched thanks to @clout2k and now it looks like this

all the credit goes to @clout2k
imma leave this open with a different title because it still needs some enhancements.

@Asyx3 @D4rckeyy  conform the fix by installing latest bloom.

closing the issue as completed
@clout2k thanks


[main] Upgrade to latest dependencies

Cron -knative-prow-robot
/cc knative/operations-wg-leads
/assign knative/operations-wg-leads
Produced by: knative-extensions/knobots/actions/update-deps

/test eventing-upgrade-tests
/lgtm
/approve

/lgtm
/test eventing-upgrade-tests


Enhanced auto_envvar_prefix support

This request really has two parts, with the goal of allowing for simpler auto-generated env var names. (I consider this to be desirable in certain cases.)

Support auto_envvar_prefix="". This works already, but results in environment variables like _FOO, which is hard to imagine being desirable. I think it the sensible and natural thing to do in this case would just be to eliminate the leading underscore, resulting in an env var like FOO. This may even be considered a bug fix, perhaps.
Provide an option to turn off "inheritance" of auto_envvar_prefix by child contexts (auto_envvar_prefix_inheritable?). Right now, if you have a command bar with an option foo and a root auto_envvar_prefix of MYCLI, the auto-generated env var for this option will be MYCLI_BAR_FOO. This feature would allow the user to have env vars named like MYCLI_FOO generated – and when combined with the previous adjustment, env vars named simply like FOO.

Any thoughts would be appreciated.

The current behavior is intentional. Enable it, and every param of every command is addressable as an env var in a standard format. If you need different behavior, you can process the command tree and set param.envvar as needed.

@davidism Thanks for getting back to me. That's fair enough. What about just point #1 though? Since an empty auto_envvar_prefix is currently allowed, it might be better to refine this behaviour to something more natural.


[web] Platform views reset the 'cursor' set by the glasspane of the app.

Steps to Reproduce
The current implementation of platform views in the web engine introduce a very aggressive reset CSS stylesheet while in DOM-rendering mode:

src/engine/html/platform_view.dart

This causes that changes to the cursor made by the flutter app (through the glass-pane) get reset once the mouse enters a platform view in the app (it seems to revert to cursor: default).
The fix is to inherit the cursor from the outside, after resetting all properties, with cursor: inherit;.
This happens currently near the tip of master:
$ flutter doctor -v
[✓] Flutter (Channel master, 1.24.0-8.0.pre.356, on Linux, locale en_US.UTF-8)
    • Flutter version 1.24.0-8.0.pre.356 at /usr/local/google/home/dit/github/flutter
    • Framework revision e6bd95bc5c (2 weeks ago), 2020-11-23 14:10:58 -0800
    • Engine revision 23a8e027db
    • Dart version 2.12.0 (build 2.12.0-62.0.dev)

This has rolled to flutter master. Forgot to add "Fixes" on the PR for this :)


Create kubernetes.tweet

@davidsonfellipe please hold the merge until tomorrow then. Otherwise, it will be posted as soon as it reaches master.


feat(cloud): Adding an upload proxy node

This PR adds an upload proxy node. A state aware node that handles the work of uploading content to a remote location on behalf of Shaka Packager. This PR adds no new dependencies.

The base node of the upload proxy is HTTPUpload which runs as a python thread and manages an HTTPServer that Shaka Packager should send all its requests to.
The internal HTTPServer instantiates request handlers for requests coming from Shaka Packager, these request handlers send the incoming requests  to the upload location, and they might add more headers to the request.
Subclasses of HTTPUpload are there to support different protocols -other than http/https- for cloud providers and to extend the HTTPUpload's capabilities, but they should all use an http/https API after processing the upload url.
Manifest files are temporarily stored in the filesystem in case of multi-period concatenation.
RequestBodyAsFileIO is a class that digests a request body incrementally without writing it to the disk. It is used by the request handlers to send the request body that lacks an EOF to the upload location.

Issues:

The GCS upload doesn't authenticate by itself and needs a refresh token from google's oauth 2.0 playground (but the implementation is simpler this way).
S3 upload doesn't yet work because I haven't found google's oauth 2.0 playground counterpart for AWS yet (If it exists).
This feature crashes on Windows (the upload node crashes) because of the presence of backslashes in the url(path) sent to the upload proxy, this happens when Shaka Packager produces files of the pattern somepath\stream_xx.m3u8 which we should be able to control using the argument --playlist_name but for some reason Shaka Packager doesn't recognize it.
The node doesn't yet handle redirects.

My -H "Authorization=Bearer $(gcloud auth print-access-token)" hack failed after about one hour of running.  I started getting HTTP 429 responses from Google Cloud, which makes me think it wasn't an issue with the token itself, but something more fundamental we will need to resolve.
Google's docs say:

If you run into any issues such as increased latency or error rates, pause your ramp-up or reduce the request rate temporarily in order to give Cloud Storage more time to scale your bucket. You should use exponential backoff to retry your requests when:
Receiving errors with 408 and 429 response codes.
Receiving errors with 5xx response codes.

I'm going to revive this and push changes into your branch so you are properly credited for the PR.  Changes I'm planning for this PR:

Go back to using the cloud URL in -c for compatibility for now
Revert extra headers feature for now (use case unclear for now)
Remove upload to HTTP without gs:// or s3:// (use case unclear for now)
Ignore -o if -c given (no need for local files if uploading to cloud)
Revert changes to periodconcat_node and mark it as incompatible with cloud upload (already can't be used for live, helps avoid local temp files)
Remove use_local_proxy from pipeline config, implied by -c
Pipeline directly from incoming request to outgoing request in proxy_node
Try to handle authentication via default credentials in gcs and s3 python modules

I'll follow up later with new changes to:

Allow cloud URLs to be placed into -o
Make -c a deprecated alias to -o (overrides -o if both given)
Add command line arg to pass initial access tokens for oauth via file, maybe also environment variable

I've started by rolling up your original commits, rebasing them, and force-pushing.

@mariocynicys, still a WIP since I haven't finished the S3 upload yet, but it's working well enough for GCS that I'm going to deploy it to my lab to revive our live stream.  Without this, my live stream was running into errors where gsutil would leave files behind in /tmp and fill up the disk.
Please take a look and give me your thoughts.

Okay, S3 is working now, too.

This is working in our lab deployment now!

@joeyparrish now that 1.0.0 is out we started using it and discovered that HTTP was removed

Remove upload to HTTP without gs:// or s3:// (use case unclear for now)

This was actually how we were using the streamer, as we use storage that is neither S3 or GCS. If you're doing that, the only option was HTTP. If there was some kind of storage adapter that would be nice and we'd write our own adapter, however in the absence of that HTTP was our only option.
Any possibility to get it added back?

Yes, definitely.  What are your requirements?
Do you need specific headers or auth tokens, or just for Packager to write output directly to an HTTP(S) URL?

@jspizziri, I filed #210 to discuss your requirements for HTTP upload.  Please let us know what you need!


Kotlin 1.4 breaks ktlint api: java.lang.NoSuchFieldError: FUN_KEYWORD

Using kotlin 1.4 M2,
I got these errors in a test:
java.lang.NoSuchFieldError: FUN_KEYWORD
	at com.pinterest.ktlint.core.ast.ElementType.<clinit>(ElementType.kt:154)

and
java.lang.NoClassDefFoundError: Could not initialize class com.pinterest.ktlint.core.ast.ElementType

More generally speaking, is there a plan to have ktlint working with kotlin 1.4 ?

I forked the repo and yes, definitely the problem is the field FUN_KEYWORD in KtTokens that is used from ktlint's ElementType.

@stephanenicolas hi, thanks for the report and for digging in to root cause. Yes, we will update to support 1.4, likely once it's been officially released.

@shashachu I understand that other aspects of the plugin and its maintenance also require work.
I totally get that and thx for all the work you're doing.
Nonetheless, we cannot test our build and prepare our own migration due to this bug and I guess we're not the only ones.
I tried to check a bit more but I am really not confident on how to address the issue.
Is there a way this issue could be prioritized so that we could test other aspects of our builds. Ideally we would be early adopters of kotlin 1.4 which is already in M2 stage.
We have a very large build and we work often with people from JB to optimize the performance of the kotlin tooling. Fixing this bug would help us to enhance the next kotlin version for the whole community.

@stephanenicolas when you have a chance, can you just add a little more detail about your setup and how you're running your tests? Thanks!

As one of the things that should address this - we are planning to start publishing snapshots that will use kotlin-in-development versions.

Kotlin 1.4.0 has been released: https://github.com/JetBrains/kotlin/releases/tag/v1.4.0

Kotlin 1.4.0 does not fix the issue for me

This should be folded into #830 to de-dupe issues

yep, please track this in #830 (there's already a 0.38.0-alpha01 version that should resolve the aforementioned issue)


Weird ligature interaction in demo Font Book

While playing around with https://www.egui.rs/#Demo, I found out that the Font Book incorrectly applies ligatures when using the Proportional font.

Expected behavior:
Every character should be displayed individually, without ligatures.
Environment:
Browser (Firefox 119, linux)

There doesn't seem to be any ligatures in the code. Each character is in its own button.
https://github.com/emilk/egui/blob/114f8201709aa822a3f620404a20de2e695725ad/crates/egui_demo_lib/src/demo/font_book.rs#L83-L86
What happens is that the first result in the monospace font, "fisheye", doesn't exist in the proportional font, which supports fewer characters, as you can see at the top of the window. The "bullseye" character exists in both, but looks different in each.


How to specify the output layers during model conversion to TFLite in TF2?

Describe the problem
Is there any way to remove the TFLite_Detection_PostProcess in tf2 ssd mobilenet model during conversion to tflite model？In tf1, there is a option to do so, but it seems that in tf2 the option for specifying the output layers is removed.
In tf1, I can specify the output layers by putting the name in output_array:
input_arrays=["normalized_input_image_tensor"]
output_arrays=["raw_outputs/box_encodings","raw_outputs/class_predictions"]
input_tensor={"normalized_input_image_tensor":[1,320,320,1]}
import tensorflow as tf
converter = tf.compat.v1.lite.TFLiteConverter.from_frozen_graph('tflite_graph.pb',input_shapes = input_tensor,
input_arrays = input_arrays ,output_arrays = output_arrays)
converter.optimizations = [tf.lite.Optimize.DEFAULT]
converter.allow_custom_ops = True
converter.target_spec.supported_ops = [tf.lite.OpsSet.TFLITE_BUILTINS_INT8,tf.lite.OpsSet.SELECT_TF_OPS]
converter.inference_input_type = tf.int8
converter.inference_output_type = tf.int8
converter.representative_dataset = representative_dataset_gen
tflite_model = converter.convert()
open('ssd_mobilenet_v2_tf1.tflite', "wb").write(tflite_model)

@qqwerter
In order to expedite the trouble-shooting process here,Could you please fill the issue template,
Thanks!


Really poor implementation on Azure....

This is one area where Azure really sucks.  So, I created a Web API, deployed it as a Docker image which appears in Azure as a Container Registry.  Azure KNOWs it's a Windows / AMD64 resource, but "Run instance" suggests running it as a Linux container.  And when things go wrong, you show a rubbish generic error:
"Deployment to resource group 'DockerDeleteMe' failed. Additional details from the underlying API that might be helpful: At least one resource deployment operation failed. Please list deployment operations for details. Please see https://aka.ms/arm-debug for usage details."
... and (some Googling later), I found that I have to open PowerShell and run a command to actually find out what caused the problem.
az group deployment operation list --resource-group <YourResourceGroup> --name Microsoft.ContainerInstance
Why can't you display the actual error ?!   I seriously have to look at the underlying JSON result to find out why Azure couldn't create a container for me ?
This feature is just unfinished....

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

ID: a114cf0c-a1a0-f73d-f8d2-0f16d62b1e86
Version Independent ID: 203548b7-824f-eb7a-ca5b-e4cfec2c6d51
Content: Troubleshoot common Azure deployment errors
Content Source: articles/azure-resource-manager/resource-manager-common-deployment-errors.md
Service: azure-resource-manager
GitHub Login: @tfitzmac
Microsoft Alias: tomfitz

@MikeInSwitzerland  Thanks for the comment. We are actively investigating on the issue and will get back to you shortly with an update.

Thank you.   I've posted more notes, with some screenshots, here:
https://stackoverflow.com/questions/57999438/running-an-azure-docker-container-registry-created-by-vs2019

@MikeInSwitzerland Here is an document on how to check deployment history and the reason of failure in portal.
Hope this is what you are looking after.

At this point it appears that there's no edits or updates needed for the documentation. Closing this issue for now. If there are further questions regarding this matter or questions or feedback on the documentation, please do let us know and we will gladly continue the discussion.

Same issue with me.  A no help message with no error code for a template that Azure is generating under the covers.  Hoping links above have an answer.

There is a need for documentation updates or a fix in the Azure portal to just show the real error and not this unhelpful one.  The documentation update should state if you are sent to this page without an error message or code, then go to your resource group and look for failed deployments to get the real error.


Add availability zone support for masters

What this PR does / why we need it:
Adds availability zones support for masters
Which issue this PR fixes (optional, in fixes #<issue number>(, fixes #<issue_number>, ...) format, will close that issue when PR gets merged): fixes https://github.com/Azure/acs-engine/issues/1919
Special notes for your reviewer:
If applicable:

[x] documentation
[x] unit tests
[x] tested backward compatibility (ie. deploy with previous version, upgrade with this branch)

Release note:

Add availability zones support for k8s masters

cc @khenidak @feiskyer

FYI got an E2E flake on 1.8:
https://circleci.com/gh/Azure/acs-engine/43044?utm_campaign=vcs-integration-link&utm_medium=referral&utm_source=github-build-link
(just in case we get another flake or two we can start to debug more deeply)

Also added this: https://jenkins.azure-containers.io/view/acs-engine/job/k8s-availability-zones-all/

@jackfrancis @tariq1890 ready for another round of review

As discussed offline, let's re-add the default settings with an additional nil check to only set the default if the value is nil + only error on validation if the value isn't nil && isn't what we want


Review nightly errors and results

Seems https://github.com/gardenlinux/gardenlinux/actions/runs/10805896028   is throwing

Annotations 68 errors upload to S3 / upload to S3 (amd64, gdch, -gardener_prod) Unable to download artifact(s): Artifact not found for name: platform-test-gdch-gardener_prod-amd64-1625.0-f549c95d Please ensure that your artifact is not expired and the artifact was uploaded using a compatible version of toolkit/upload-artifact. For more information, visit the GitHub Artifacts FAQ: https://github.com/actions/toolkit/blob/main/packages/artifact/docs/faq.md

The nightly run just ran through: https://github.com/gardenlinux/gardenlinux/actions/runs/10805896028
No issues with the pipeline.

@yeoldegrove , yes, I see but the 68 annotations look like a real problem to me. Can you please investigate further?
E.g. I see https://github.com/gardenlinux/gardenlinux/actions/runs/10805896028/job/29975907507#step:8:17 which looks like the actual root cause or?

@pnpavlov #2333 Could be a potential fix fox the annotations you see.
These come from the continue-on-error: true step for downloading the platform-test logs on platforms that do not produce those logs.


TexParameterI overloads in preview 5

Summary
In preview 4, there was an overload for GL.TexParameterI that accepted an int:
gl.TexParameterI(GLEnum.Texture2D, GLEnum.TextureWrapS, (int)GLEnum.Repeat);

In preview 5 however, this overload was removed and there now overloads that only accept int* or ref int:
int repeat = (int)GLEnum.Repeat;
gl.TexParameterI(GLEnum.Texture2D, GLEnum.TextureWrapS, ref repeat);

This makes it pretty cumbersome to use, because each parameter must first be saved in variable.
Is there any chance of getting the first overload back?

Hmm I'm not sure. Seeing as glTexParameterI is a pointer, it's probably best we keep it at least a by-reference parameter. If you're passing singular parameters, you might want to use GL.TexParameter instead of GL.TexParameterI

Seeing as glTexParameterI is a pointer, it's probably best we keep it at least a by-reference parameter. If you're passing singular parameters, you might want to use GL.TexParameter instead of GL.TexParameterI

I completely missed that :grimacing:
GL.TexParameter is exactly what I was searching for, thanks!


The game will continue for the remaining players

Leaving in game should lead to update in game. Other players must be able to continue submitting their answers


0.22-DEV version broke my blog page

Hi all,
Does anyone know why something in the latest version 0.22-DEV somehow changed the way hugo generates my paginated blog summary page?
Here's the code where things worked flawlessly in the past but recently gives empty html output.

            {{ range $i, $e :=  .Paginator.Pages }}
            {{ .Render "summary" }}
            {{ if modBool ( add $i 1) 4 }}

        {{ end }}
        {{ end }}

        {{ template "_internal/pagination.html" . }}

And summary.html partial for your reference:

        {{ $url := printf "img/blog/%s" .Params.thumbnail }}

        <time class="blog-time">
            {{ $data := index .Site.Data .Site.Language.Lang }}
            {{ .Date.Day }} {{ index $data.month (printf "%d" .Date.Month) }}, {{ .Date.Year }}
        </time>

            {{ .Title }}

My travis-ci build get hugo executable by go get github.com/spf13/hugo which leaves me no way to specify a version number. The build is run daily and it's only rendered an empty blog page in the last two days so my first thought is something in the new hugo version is the culprit, but I could be wrong though.
It would be very appreciated if someone can shed some lights on this and if there's a way to let me specify a version of stable version of hugo, it would be the best.
Thanks a lot for the great work here anyway.

Please use http://discuss.gohugo.io/ for questions/troubleshooting.


filter-reset - input / button

Hello, thank you for the great plugin.
I should comment:
I think that the filter-reset-button should be <button> not use <input>.
on the input element is not possible to add css :after :before.
You can not insert html . This rather limits the possibilities of adapting this button.
Can be applied only to the class as .btn.
Thank you, consider the possibility of confusion - <input> to <button>

Hi,
You are welcome, you are right about that input limitation, but even now you can add the pseudo elements to the .yadcf-filter-reset-button class which present on each reset button

Thank you for the quick response.
Unfortunately pseudo-element can not be applied to the <input>, that's the problem. For this element of the pseudo-element is not working. The <button> is ok. Here it is possible to apply button:after button:before.
Probably would also be good to better distribute structure within .yadcf-filter-wrapper
as here

    <input class="yadcf-filter form-control">

        <button class="yadcf-filter-reset-button btn btn-default">✕</button>

yet I used jquery .addClass () and .wrap (), but there is a problem if you use
filter_type: "range_number_slider".
In this case the reset button is not working because
function rangeNumberSliderClear... uses .parent().find() and .prev().find()
Maybe you advise me how to do this layout
Thanks

this is my interim solution
I used this script to use my version
function yadcfAddBootstrapStyle() {
        var filterWrapper = $('.yadcf-filter-wrapper'),
            filterInput = $('input.yadcf-filter, input.yadcf-filter-range, input.yadcf-filter-date'),
            filterReset = $('input.yadcf-filter-reset-button');

        if ($('.table-filter').hasClass('js-table-filter-group')) {
            filterWrapper.addClass('input-group');
            filterInput.addClass('form-control');
            filterReset.addClass('btn btn-default').wrap("");
        } else {
            filterInput.addClass('form-control');
            filterReset.addClass('btn btn-default').wrap("");
        }
    }

Only .btn and form.control. sample
Using as .input-group.  sample

a little css for .yadcf-filter-
Unfortunately, in both cases it is necessary to adjust the function, because it is necessary to add the wrapper on the reset button.
function rangeClear(...).
rangeNumberSliderClear(...)
In this style
+$($(event.target).parent().parent().find(),
$(event.target).parent().prev().find().

so changing to input element of reset into button would good enough? or its more than just that replacement ?

Yes, Change <input> element of reset into <button> and wrap to the  element would be sufficient for the possibility of styling. With that, it is necessary to modify the rangeClear and rangeNumberSliderClear function.
general: input element does not support the use of pseudo-element.
this result:

    <button  type="button" class="yadcf-filter-reset-button">✕</button>

for "x" I used this html entity "✕"

While I see the point of changing the input into the button element, I'm not sure about how mandatory is the wrapping with span and I prefer to avoid breaking the current position of the element.

wrap is not required

fixed in 0.8.7.beta.10, showcase updated

pinin: I managed to get a fused input reset button if I applied "input-group" class to the wrapper and "input-group-addon" to the button directly. So I didn't use an extra wrapper span, as books advise. Hopefully it'll keep working.

Since I don't have space for clear buttons in some header cells, my code:
headerCallback: function (thead, data, start, end, display) {
    $(thead).find("th").each(function (thindex, thelement) {
        var clearBtn = $(thelement).find(".yadcf-filter-reset-button");
        if (clearBtn !== null && clearBtn.length > 0) {
            var filterWrapper = $(thelement).find(".yadcf-filter-wrapper");
            if (filterWrapper !== null && !$(filterWrapper).hasClass("input-group"))
                $(filterWrapper).addClass("input-group");
            if (!$(clearBtn).hasClass("input-group-addon"))
                $(clearBtn).addClass("input-group-addon");
        }
    });
}

Plus some extra padding modification is required for the button, IE, Chrome and FF shows them differently.

input-group-addon has a width: 1% CSS for example, not meant to be applied directly to the button.

@MrCsabaToth , couldn't you use the headerCallback for finding and wrapping the yadcf-filter-reset-button with a span element (for example by using http://api.jquery.com/wrap/ )

This is nice, but the wrap on the reset button destroy the reset function when the filter type range.
Therefore it is not possible to wrap reset button.

pinin: you are right, the reset button won't function if it is wrapped.

Here is my solution is not ideal, but it works as I need
HTML

        #
        Name
        Position
        Office
        Extn slider
        Start date
        Status
        Salary

JS
// Add bootstrap style
    function yadcfAddBootstrapClass() {
        var filterInput = $('.yadcf-filter, .yadcf-filter-range, .yadcf-filter-date'),
              filterReset = $('.yadcf-filter-reset-button');

        filterInput.addClass('form-control');
        filterReset.addClass('btn btn-default').html('✕');
    };

    yadcfAddBootstrapClass();

CSS
/* if you do not use the reset button to add the cell this class */
.yadcf-no-reset .yadcf-filter-wrapper {
    padding-right: 0;
}
.yadcf-no-reset .yadcf-filter-reset-button {
    display: none;
}

/* Style no input-group
 * ------------------------------ */
.yadcf-filter-wrapper {
    display: block;

    padding-right: 36px;

    white-space: nowrap;
}
.yadcf-filter-wrapper .form-control,
.yadcf-filter-wrapper .select2-container,
.yadcf-filter-wrapper .select2-container.form-control,
.yadcf-filter-wrapper .yadcf-number-slider-filter-wrapper-inner {
    display: inline-block;

    width: 100%;
}
.yadcf-filter-wrapper .yadcf-filter-range-date {
    width: 100px;
}
.yadcf-filter-wrapper .yadcf-filter-range-number {
    width: 60px;
}

/* Range wrapper */
.yadcf-filter-wrapper-inner {
    display: inline-block;

    vertical-align: middle;
}

/* Range input */
.yadcf-filter-range {
    display: inline-block;

    vertical-align: middle;
}

/* Range separator */
.yadcf-filter-range-date-seperator,
.yadcf-filter-range-number-seperator {
    display: inline-block;

    margin-left: 1px;

    vertical-align: middle;
}

/* Reset button */
.yadcf-filter-reset-button {
    display: inline-block;

    margin-right: -36px;
    margin-left: 1px;

    vertical-align: top;
}
.yadcf-filter-reset-button.btn {
    font-size: 11px;
    line-height: 20px;

    color: #d9d9d9;
}
.yadcf-filter-reset-button.btn:hover {
    color: #333;
}

/* If set stack range
 * ------------------------------ */
/* Range wrapper */
.yadcf-range-stack .yadcf-filter-wrapper-inner {
    display: inline-block;

    vertical-align: top;
}

/* Range input */
.yadcf-range-stack .yadcf-filter-range {
    display: block;
}

/* Range separator */
.yadcf-range-stack .yadcf-filter-range-date-seperator,
.yadcf-range-stack .yadcf-filter-range-number-seperator {
    display: none;
}

Is there a little more style. Hopefully it helps someone


Adding typescript to the project

Hello everything is fine?
I would like to thank you for the library, it is fantastic!
My suggestion with this PR is to contribute to improving the typing in the project
I thank the attention
This closes:
https://github.com/mauricius/vue-draggable-resizable/issues/294
OBS:
[X] All tests passed
[X] Build process working fine
[X] Exporting types

Type autocomplete

Do you think @mauricius that PR makes sense?

Would love to have this implemented!


Added mock setup for CreateCategoryAsync

Added back the the mock setup that was commented out.
I also added a second parameter (CancellationToken ct) to the callback to make things work.

Hi @kl4u5
Great, thank you for your contribution. I have merged your change into the main branch. 😊✌


[CARBONDATA-TEST] jenkins test

Why is this PR needed?
Todo
What changes were proposed in this PR?
Todo
Does this PR introduce any user interface change?

No

Is any new testcase added?

No

Build Failed  with Spark 2.3.4, Please check CI http://<IP_ADDRESS>:12602/job/ApacheCarbonPRBuilder2.3/6369/

retest this please

Build Failed  with Spark 3.1, Please check CI http://<IP_ADDRESS>:12602/job/ApacheCarbon_PR_Builder_3.1/754/

Build Failed  with Spark 2.3.4, Please check CI http://<IP_ADDRESS>:12602/job/ApacheCarbonPRBuilder2.3/6370/

Build Failed  with Spark 2.4.5, Please check CI http://<IP_ADDRESS>:12602/job/ApacheCarbon_PR_Builder_2.4.5/4658/

I'm working on fixing Jenkins. For now, I have an issue to build locally on my machine. I will create few PRs about that.


Compilation errors on Xcode 9.0 beta 3

Using the newly released Xcode 9 beta 3, and the 'QNNetDiag' cocoapod, it fails to compile due to errors with macros.  CocoaLumberjack has had to deal with a compile issue from this new Xcode beta as well.

i meet this error too, how to fix it ?

same issues

I just added a pull request to resolve this problem.

thanks for @escrafford  👍


close(): fix exception and enable fast-close

The current code throws an exception during close() when it tries to convert an empty buffer (chunk_header).
This PR also adds an optional parameter fast=False. Passing True will skip reading.
This addresses #130 (also mentioned in #138)

Let's not add it to close() because that changes it from the Requests API: https://requests.readthedocs.io/en/latest/api/#requests.Response.close
Instead, please add it as a kwarg on Session(). The Session() API already varies from CPython.

Maybe I am missing something, but this would imply that I

add a kwarg to Session()
the constructor saves this as a public property
Response.__init__() will query the property from the Session-object passed to it and save it as an instance attribute
Response.close() uses this instance attribute

This seems rather involved. In my solution, I added an optional argument to Response.close(), so as long as you don't use it, the code is compatible. And the whole Response class is not compatible after all, there are many differences already.
But probably the whole drain-the-buffer-code should not be here after all, but somewhere where the socket is actually closed. Until this is implemented, I see both of my changes as a workaround. Instead of changing the code in many places, it might be wiser to just remove the additional option and wait for the real solution.

And the whole Response class is not compatible after all, there are many differences already.

What are these differences? The intent is that the same code will work with CPython's request.

This seems rather involved.

It is a bit of plumbing but it isn't complex and it preserves the API. I'd have session pass it into the response object as a separate kwarg.

In my solution, I added an optional argument to Response.close(), so as long as you don't use it, the code is compatible.

"so as long as you don't use it" is a big caveat. We shouldn't make it possible to write incompatible code so you don't need to worry about it or need to redo it later.

What are these differences? The intent is that the same code will work with CPython's request.

e.g. the constructor of Response in CPython does not take any arguments.

I'd have session pass it into the response object as a separate kwarg.

What is the fundamental difference between adding an additional kwarg to the Response constructor compared to adding a kwarg to Response.close()?
Anyhow, I will do what you suggested to get the fix for the chunk_size exception merged, that is the most important problem.

What are these differences? The intent is that the same code will work with CPython's request.

e.g. the constructor of Response in CPython does not take any arguments.

I'd have session pass it into the response object as a separate kwarg.

What is the fundamental difference between adding an additional kwarg to the Response constructor compared to adding a kwarg to Response.close()?

Response objects aren't usually created by user code. Instead, they are constructed by the library internally and returned. To me, that makes the constructor more private than close.

Anyhow, I will do what you suggested to get the fix for the chunk_size exception merged, that is the most important problem.

Thanks!

@bablokb what is your thought around fast_close? I understand the chunk bug fix, but don't fully understand this one.

Is there a CPython requests equivalent to the fast_close functionality, or is there something different about our requests semantics?

@bablokb what is your thought around fast_close? I understand the chunk bug fix, but don't fully understand this one.

There are streams that never end (e.g. internet radio mp3-streams). In this case reading the socket until it is empty will never succeed.

I can revert the PR if it makes sense, or if you can just rebase and fix, @justmobilize, that's fine too.

@dhalbert I should have my PR ready by Wednesday. I can do either:

include the empty_chucks and fix and not having close keep reading read
remove the fast_close and fix and not having close keep reading read
Up to you on what's best (revert now or wait)

@justmobilize Do 2., so that we have at least one fix for now.

Sounds good

Tested it with 9.0.0-rc0 and a Pico-W and it works fine.


Support Fedora 40

Packages for Fedora 40 will be available on copr
Packages for Fedora 38 will not be created anymore

Fixed with V1.33.5


Trying to connect accounts opens weird pages in browsers

Aknowledgements

[X] I have checked that there's no other issue describing the same or
similar problem that I currently have, regardless if it has been
closed or open.

[X] I can confirm that this is not an issue with the Discord website,
but it is a problem specific to the WebCord itself. I have tested
if this bug occurs on Chromium/Chrome or any other Chromium-based
browser that uses unpatched/upstream Chromium engine.

[ ] I have tried running the build from the master branch and it does
not have any fixes implemented according to my issue.

[ ] My issue describes one of the unstable and/or not fully implemented
features.

[ ] I have found a workaround to mitigate or temporarily fix this issue
in affected releases (please write it in Additional context section
below).

Operating System / Platform
🐧 Linux
Operating system architecture
x64 (64-bit Intel/AMD)
Electron version
21.1.0
Application version
v3.8.8
Bug description
For example, when connecting github account, it opens https://discord.com/connections/github?loading=true in firefox.
Additional context
No response

It makes sense WebCord will do that, there's almost no exceptions for opening the external links outside of WebCord.
There's also no logic for adding account, it's something I've never done from WebCord.
Also since #294 describe basically the same bug (it's not expected sites such like this to properly work outside of WebCord), but it's focused on it's further consequences, I'll just close it in favour of this issue ticket.


Fix spelling

I tried to find other (obvious) typos or improvements to avoid a trivial one-character PR, but couldn't; sorry!

Hi @rrjjvv. Good catch. Thank you for the PR.


Support for new "gpt-4o" tiktoken tokenizer

I may take a run at it myself but happy to "buy someone a coffee" if they beat me to it :).  Curious if there are any potential pitfalls.

Looks like @CaffeeLake did this. Let me know if it doesn't work for you now

@CaffeeLake thank you!!!!


useState reference on official React docs website          in Corcera

This page doesn’t exist.

Please Explain more about the problem
Attach Screenshot or link

closing the issue as it doesn't contain much data


update localForage

@arma-gast Thank you for your contribution!
@3x14159265 Could you review this pull request?

Take a look at this pr: https://github.com/borisyankov/DefinitelyTyped/pull/5066
@3x14159265 doesn't respond more than a month.


Use different names to convey thread status

Fix: #2
As discussed on Twitter.
The RUBY_INTERNAL_THREAD_EVENT_* names convey state transition not status. Given that gvl-tracing generate areas with a state until the next event, it would be more clear to disaply thread status instead.
I think running is best to describe threads that have acquire the GVL and are actually executing.
For waiting is the best I could find to describe thread waiting for IO or join. But sleeping could do as well.
And finally I think ready works to describe threads that could be executed but are waiting on the GVL.
Either way the README should probably describe the signification of each status.
FYI @ko1

(I left a comment on the macOS support PR, I was thinking I would put out a release after that one is merged as well)

I was thinking I would put out a release after that one is merged as well

Sure. But I was thinking I could take a stab at the GC events (#1) shouldn't be too hard., so might be worth waiting a few more hours.

Oh, nice! Happy to wait then :)


MAINT: sparse: Update EfficiencyWarning message to reflect array/matrix

This is a change in the EfficiencyWarning text to reflect the class name (format and array/matrix).
It ends up touching a lot of tests (those that filter the warning based on the text). The tests now filter on less specific text to allow the message to evolve and still have the filter work.
I'm pulling this out as a separate PR because it is affecting multiple PRs -- reviewing this should be easier without other changes and then the other PRs don't have this large footprint, low information change.
When I committed these changes a couple of linting changes were required by the precommit.
lines near 3740 in test_base.py and lines involving the abbreviation sp for import in test_common1d.py.

This is low-impact, passing CI, and likely to accumulate merge conflicts if left for too long, so I'll merge it now.


Make sure python-yubico works with pyusb>1.0

See<EMAIL_ADDRESS>

Testing seems to indicate that it does support pyusb 1.0.0b2 without modification.


Update README.md

https://github.com/8maheshw/aws-catalog-api/issues/11

Updated the pr for user story


User Profile Manipulation does not work with On-Premises version of SharePoint

User Profile manipulation does not work with On-Premises version of SharePoint. When will an on-premises version be available ?  I Know peoplemanager.SetSingleValueProfileProperty is not available from the product group yet.  There must be a way providing the same functionality for on-premises versions of SharePoint.

Hi Patrick
What the fix for this issue ?
Nigel


feat!: add bytes dataValue parameter to DataChanged event in ERC725Y

What does this PR introduce?
⚠ Breaking Change
In this PR a new parameter is added to the DataChanged event, dataValue.
Also the tests are fixed in order to take into account dataValue whenever it is checked if the event DataChanged was emitted.

For history, the value parameter in the DataChanged event was removed in ERC725Y in version 3.1.0.
see #123 for reference.


The frame of the git commit message editor box disappears when putting a cursor in it

Operating system/version: macOS 10.15.6 (19G73)
VSCode version: Version: 1.47.3
Commit: 91899dcef7b8110878ea59626991a18c8a6a1b3e
Date: 2020-07-23T13:08:29.692Z
Electron: 7.3.2
Chrome: 78.0.3904.130
Node.js: 12.8.1
V8: 7.8.279.23-electron.0
OS: Darwin x64 19.6.0

Settings
I have tried without some extensions installed, the bug still appears.
Steps to reproduce this bug
Put a cursor into the "source control message editor".
Actual behaviour
Without cursor, it looks good:

With a cursor inside, the frame of the box disappeared:

Expected behaviour
With a cursor inside, the frame of the box still shows.

Hello, thanks for your attention.
I checked fast some workbench settings for input control but this it didn't help. So I need some extra time to fix this issue.
sorry for the inconvenience.

Accidentally I found a solution. It look like it was an expected behavior, so without @sainnhe I won't fix it.
But here is a recipe for you, @singularitti :

Open your settings.json file

add this code:

  "workbench.colorCustomizations": {
    "[Gruvbox Material Dark]": {
      "focusBorder": color
    }
  },

Change color depending on your palette:

#3d3835 for hard
#45403d for medium
#504945 for soft

Thank you for your reply, this workaround works for me. However, I still hope this could officially be fixed. For example, the extension input box is still good even if there is a cursor in it:

Personally, I'm with you, but the source code which setup this border is focusBorder: ${palette.bg5}00, 00 means that it should be totally transparent. You can check src/workbench/ if you want

Oh, this is not expected behavior, it's a mistake when I'm designing "borderless" workbench style.

@sainnhe this change will trigger some borders for windows like live share, debugger

You are going to make the decision. I can't use my PC now, and I don't use vscode very much, I use neovim for daily development. If you think the design can be accepted by most of the vscode users, then go ahead and change it.

I find useless borders more annoying, so I think that "sacrifice" this border is acceptable.
But I' ll try to find a way to fix it. Probably is there anyone who have some experience in overriding vscode default behavior?

Or maybe open an issue in the vscode repository. I found another annoying bug recently: in the extension sidebar, the extension name and description can be designed to be grey, but the extension publisher is always white.
I found that the foreground color of the extension publisher is controlled by the foreground key, which means if we set it to grey, then the foreground color of every element will be grey.
I personally think that both of these 2 problem should be fixed in vscode level instead of in a color scheme.

Only tangentially related to border; is there any potential to include support for the sash hover border color introduced in v1.52?
I think it'll go well as an added accent colour customization, similar to the "gruvboxMaterial.darkCursor": "green" options.
Thank you.

@rdhar Done via https://github.com/sainnhe/gruvbox-material-vscode/commit/975407e08499357c33a8bbb020810632b8f8d8c7
I'll create a new release later.

Wow, that's great to hear, @sainnhe!
I'd thought you moved on away from VS Code to Neovim so this is a very welcome surprise!
Thanks for your time and effort for continuing to support the best interpretation of the Gruvbox theme that I've come across.

@rdhar

I'd thought you moved on away from VS Code to Neovim

To be honest, I'm a neovim user from the very beginning, I don't use vscode very much.
I created this theme simply because sometimes I need vscode on windows, and some of my friends need this theme.
So I'll continue to maintain this project. Btw, @Z4RX is also a maintainer of this project, he did a fantastic job, he and me will response when we have time.
This project will be actively maintained for a long time, so don't worry :)


workbox-window should fire controlling events with isExternal: true

In Workbox v6, we modified the behavior of most of the previous workbox-window events so that instead of having "expected" and "external" flavors (waiting, externalwaiting, etc.) we would always fire events with the expected name (waiting, etc.) and set the isExternal boolean flag accordingly.
This change did not happen for the controlling event, however, and the only time controlling will be fired is if the service worker that has taken control of the page is the same as the service worker associated with workbox-window's original registration.
We should update that so that the controlling event is also fired when it's a different service worker that's taken control, and set isExternal: true in that case. (And set isExternal: false otherwise, which also isn't being set.)
https://github.com/GoogleChrome/workbox/blob/27080cccfbc360b121083bb47e20429997051a6f/packages/workbox-window/src/Workbox.ts#L503-L517
It's arguable whether this is a bug fix or a breaking change—the documentation implies that the controlling event would be fired with isExternal: true in this scenario, so I'm erring on the side of bug fix.
CC: @philipwalton in case he has an opinion.

@jeffposnick Hey Jeffrey! I'm testing the newest version of Workbox and it looks like there is something working not exactly correct with this new functionality.
I have this implementation of "page reload for users":
js```
if ('serviceWorker' in navigator) {
const wb = new Workbox('/service-worker.js')
const showSkipWaitingPrompt = event => {
const result = window.confirm()
if (result) {
wb.addEventListener('controlling', () => {
window.location.reload()
})
  wb.messageSkipWaiting()
}

}
wb.addEventListener('waiting', showSkipWaitingPrompt)
wb.register()
}

and first time, when I have a new version of service worker - I decline to activate it (the new version).
Then at `showSkipWaitingPrompt` in the `event` received I see `isUpdate: true, isExternal: false`.

Then I release a new version of the service worker again - I again decline to activate it.
This time at `showSkipWaitingPrompt` in the `event` received I see `isUpdate: undefined, isExternal: true`.

If I repeat this process one more time - I stop receiving `showSkipWaitingPrompt` callbacks for the `waiting` event.

Hello @denieler—how are those new releases detected? Are you calling wb.update() after each deployment of a new service worker, keeping the same page open? And which browser are you seeing this behavior with?

Hello @denieler—how are those new releases detected? Are you calling wb.update() after each deployment of a new service worker, keeping the same page open? And which browser are you seeing this behavior with?

@jeffposnick has this functionality been released? The commit referenced (https://github.com/GoogleChrome/workbox/commit/2426f72aef51ec78c0a750c79d6615ee0aee3fe3) has not been included in any tag as far as I can tell, and npm is still at version 6.1.2
I had figured the fix for controlling not firing on an external worker had not been released yet?

Oh, that's an excellent point—you're correct in that we need to cut a new release for that and a couple of other bug-fix PRs that have been merged recently.
CC: @tropicadri

@jeffposnick yes, I've tried to reproduce it with wb.update() and with
navigator.serviceWorker.getRegistrations()
    .then(serviceWorkers => {
      console.log('workers:', serviceWorkers)
      for (let worker of serviceWorkers) {
        worker.update()
      }
    })

However, I've tried this with the version 5.1.4 of workbox-window and it looks like the behaviour is very similar.
The first time it calls waiting event callback with isUpdate: true,
the second time it calls externalwaiting event callback with isUpdate: undefined
and the third time it stops calling waiting or externalwaiting.

We're looking to get Workbox v6.1.3 out with these related changes early next week. Please give it another try then.

thank you @jeffposnick! definitely looking forward 🙇

Workbox v6.1.5 (which ended up being the next release's version number) includes the changes in #2787. Hopefully things work as expected for you with that version.

Hey, @jeffposnick 👋 Thank you for the release you've guys made 💪 it almost fixed the issue I've reported, however it looks like there is still something wrong there happening. I don't yet have a confident way to reproduce it, but I will try and report later if will find something.
It looks like the waiting listener sometimes got "stuck" and stop being executed after multiple postponing updates for the page. Until I manually reload the page. Then it starts working again. (as I said before I do wb.update() on each react-router change)

I'm also seeing this issue on 6.1.5 with the waiting event. It feels inconsistent as to whether the correct isExternal and isUpdate values are emitted with this event. My scenario:
  if ("serviceWorker" in navigator) {
    const wb = new Workbox('/service-worker.js');

    const showSkipWaitingPrompt = (event: WorkboxLifecycleWaitingEvent) => {
      if (event.isExternal) {
        notification({
          text: "App Update Available",
          onClick: () => {
            wb.addEventListener("controlling", e => {
              window.location.reload();
            });
            wb.messageSkipWaiting();
          }
        });
      }
    };

    wb.addEventListener("waiting", showSkipWaitingPrompt);

    wb.register();
  }

It’s hard to reproduce but it doesn't seem to matter if the tab is in the background or not and generally just feels inconsistent. I feel like I'm super close with this but this really feels like an issue with workbox-window’s waiting event.

Hi there,
Workbox is moving to a new engineering team within Google. As part of this move, we're declaring a partial bug bankruptcy to allow the new team to start fresh. We realize this isn't optimal, but realistically, this is the only way we see it working. For transparency, here're the criteria we applied:

For PRs, we closed everything that doesn't target the current v7 branch.
For Issues, we closed everything that was created before 2024.

Thanks, and we hope for your understanding!
The Workbox team


Importing a GLB exported from SketchUp, all materials have an IOR of 1000

I exported a model from SketchUp 2024 as DAE and GLB. The GLB had all materials set to an IOR of 1000. Comparison below:

Not sure if SketchUp is putting that value in the file or if it's the importer, but I also converted the GLB to GLTF at 3dpea.com, and there doesn't seem to be any IOR stored in the converted file. Importing that GLTF had a more reasonable IOR of 1.5.

floor 3.zip

The .glb file uses the extension KHR_materials_pbrSpecularGlossiness, which is always imported with an IOR of 1000, see #2127. This makes some of the math come out correctly IIRC.