Handle breaking change in class property runtime behavior

From https://github.com/Microsoft/TypeScript/issues/12212#issuecomment-428342448 @joeywatts:
class A {
    property = 'some string';
}
class B extends A {
    property;
}
const instanceB = new B();
// "some string" or "undefined" ?
console.log(instanceB.property);

It appears from the current definition at https://github.com/tc39/proposal-class-fields that this code will print undefined.
If the proposal advances further with these semantics, we'll need to figure out a mitigation strategy, preferably sooner rather than later.
One option is to make the code as written a type error for ~2 versions and force people to write an explicit  = undefined initializer, then remove the error.
Edit [@sandersn]:
Here is the current plan, together with what has happened so far.
TypeScript 3.6

[x] #32787: allow accessors like declare class C { get p(): number; } (and set as well)
[x] No changes to .js emit yet
[x] No changes to .d.ts emit yet

TypeScript 3.7

[ ] #33470: emit get/set accessors in declaration files
[ ] #33401: accessors may not override properties and vice versa.
[ ] #33423: uninitialised properties may not override properties.

Introduce new syntax, class C extends B { declare x: number }
Introduce a codefix that inserts declare where needed.
This declaration is erased, like the original declaration in old versions of TS

[ ] #33509 Introduce a new flag, useDefineForClassFields.

When "useDefineForClassFields": false:

Initialized fields in class bodies are emitted as constructor assignments (even when targeting ESNext).
Uninitialized fields in class bodies are erased.
The preceding errors are silenced.

When "useDefineForClassFields": true:

Fields in class bodies are emitted as-is for ESNext.
Fields in class bodies are emitted as Object.defineProperty assignments in the constructor otherwise.

In 3.7, "useDefineForClassFields" defaults to false
Declaration emit is the same regardless of the flag's value.

TypeScript 3.8
(or, the first version after class fields reaches Stage 4)

[ ] "useDefineForClassFields" defaults to true when targetting ESNext.
[ ] issue new errors as suggestions with codefixes, even when "useDefineForClassFields": false.

I am happy to see TS looking into this important compatibility issue. This plan sounds good to me. Another potential incompatibility is that TC39's fields are defined with Object.defineProperty, not =, so setters defined in a superclass will not run.

@littledan this is a bit of a compat nightmare for us and it'd be great to understand why initializers are optional in the current proposal. Why would someone write an initializer-free non-private declaration in the first place? Staking out an own property with the implicit value undefined seems like an odd bit of sugar to have when it creates a footgun for derived classes as a trade-off.

Why is that kind of construct even desirable without static enforcement? It's just a comment written in a different syntax.

No, it's meaningfully different: because it uses [[DefineOwnProperty]] semantics, it guarantees the property is an own data property, rather than risking triggering setters on a superclass.
You can of course put a Object.defineProperty in the constuctor, but that's... not great.

I recall we discussed the possibility of requiring initializers at some point, though I can't dig that up just now.

rather than risking triggering setters on a superclass

I'm sure you guys have discussed this to death already, but having a body-level declaration be subtly different from a constructor assignment (i.e. it only matters when there's a superclass setter) is only going to increase developer confusion.
Now when I look at code with an uninitialized declaration, I have to nervously wonder whether it's there for documentation purposes, or to overwrite a property slot because of the risk of triggering a base class setter (isn't not triggering it the risk? Why is the base class setter there in the first place) ?

We did actually discuss it to death in TC39... the classic Set vs Define debate (see summary by @bakkot; even though we've already discussed it a bunch, I'm really happy to hear your thoughts on the issue). Compatibility and constructor correspondence were raised, but the committee was ultimately convinced to take the Define and implicit = undefined path, partly due to evidence from @jeffmo that these semantics were not very difficult to migrate to in Facebook . The hope was that the Define semantics would actually be easier to understand locally, as you don't have to think about whether the superclass has a setter since you'll always get that property defined.

It's true that when I looked at this before it wouldn't have been difficult to migrate things at Facebook (IIRC very few places would have had issues), but it's also worth noting that usage of setters is pretty rare in JS written at FB (as a matter of both tooling support and style).
Where they are used I was able to flag them for manual inspection -- but it may also be possible to do something more heuristically smart than just manual inspection for codebases that use them more frequently.

This has been a problem with babel's typescript support as well, because we need to know how should we treat field type annotations without an initialization.
Without --strictPropertyInitialization, how should this code be stripped of annotations:
interface Bar {}

class Foo {
  bar: Bar = {}
}

class Baz extends Foo {
  bar: Bar
}

If we only strip the : Bar from the second class, we're actually overriding its value with undefined in babel (as long as it's not being transformed with spec: false). We'd have to strip the entire of bar: Bar to not break at runtime but that'd be a possible break if bar is not actually an inherited field ('bar' in new Baz() would fail for example).

I don't think there's much we can do about the strict breakage, but I'm concerned about the fact that this makes it impossible to re-declare existing fields on subclasses.
One suggestion: use declare to mark a field as "type only"
class N {
  node: Node
}

class E {
  declare node: Element
}

This would have the same behavior as today's redeclaration, while the field syntax would have the standards-compliant behavior.

We'd have to strip the entire of bar: Bar to not break at runtime

This was raised in the office and I strongly opposed it - TS has never used a type annotation to change runtime behavior and I would not want to start now.

use declare to mark a field as "type only"

I like this quite a bit

as you don't have to think about whether the superclass has a setter since you'll always get that property defined.

Every time I hear this it sounds like an extremely solid argument against the behavior as proposed. If your base class has a setter, it almost certainly wrote it as a setter for a reason, and the base class is going to get super confused when it doesn't see its own setter behavior firing. e.g.
class Base {
  // This is a nice property that normalizes null/undef to 0!
  get value { return this._value }
  set value(v) { this._value = v ? v : 0; }

  func(x) {
    this.value = x;
    // Can't happen because the setter fixes it
    Debug.assert(this.value !== undefined);
    console.log(this.value + 10);
  }
}

class Derived extends Base {
  // FYI guys, value comes from the Base class, no worries
  value;
}

const d = new Derived();
d.func(undefined); // oops!

If your derived class is intentionally stomping on its base class setters, I question whether it's even plausible that it's a correctly substitutable instance of its base class.

@RyanCavanaugh I think the main confusion for me that class fields don't trigger setters is mostly because of the use of the = token rather than some alternative.
Personally I would've preferred foo := 12 or some other differing syntax to say, hey this is a declaration not a property assignment. But it is in popular use already thanks to Babel, and Chrome is planning on shipping it soon so we're probably stuck with it.
Getting past the use of = I think it makes sense as it's a lot like an object literal e.g.:
const base = {
  set someValue(value) {
    console.log("triggered a setter!")
  }
}

// No setter triggered
const derived = {
  __proto__: base,
  someValue: 12
}

// No setter triggered
derived.someValue = 12

const derived2 = { __proto__: base }

// setter triggered
derived2.someValue = 12

class Derived extends Base {
  // analagous to someValue: 12 in an object literal
  someValue = 12
}

Something that @littledan brought up last night: the --experimentalDecorators flag currently expects set semantics, not define semantics. We'll likely have to maintain the old emit with this flag turned on.
P.S.: Keywords for me in the future: set define class fields instance fields properties defineproperty defineproperties

* TBD: property as a getter/setter pair if the base class defines that property as a non-getter/setter pair

IMO this case is even more problematic than the other way around as it the new behavior would override the accessors:
class A {
    property = 'some string';
}
class B extends A {
    get property() {
        return 'other string';
    }

    set property() {
        // readonly now!
    }
}

// TypeScript Currently
const instanceB = new B();
console.log(instanceB.property); // "other string"
instanceB.property = "override";
console.log(instanceB.property); // "other string"

// Class fields behavior
const instanceB = new B();
console.log(instanceB.property); // "some string"
instanceB.property = "override";
console.log(instanceB.property); // "override"

Will this feature be disabled by default, so that [[Set]] semantics are default? It's going to introduce red squiggly lines into projects if the class fields suddenly are not allowed due to super classes having accessors. 3.6 isn't a major version bump, you know.
 :)
For example, I made a painting of a gruesome premonition:
class Animal {
    #sound = 'rustling noise in the bushes'

    get sound() { return this.#sound }
    set sound(val) {
      this.#sound = val;
      /* some important code here, perhaps tracking known sounds, etc */
    }

    makeSound() {
        console.log(this.#sound)
    }
}

const a = new Animal
a.makeSound() // 3.14

class Lion extends Animal {
    sound = 'RAWR!'
}

const lion = new Lion
lion.makeSound() // BUG! Expected "RAWR!" but got "rustling noise in the bushes"

It was a bloody mess.

How is that possible - using the private field syntax (which doesn’t work in TS yet) with Set semantic expectations?

@trusktr your code is defining the Lion declaratively - and therefore we do not expect side-effects.  The fix is to make it imperative which will invoke the Animal base class accessor.
class Lion extends Animal {
    constructor() { this.sound = 'RAWR!' }
}

How is that possible
@ljharb

This is not important, you can just replace # to _ (yes, _ is just the old #, if reverse the slogan)

The fix is to make it imperative which will invoke the Animal base class accessor.

@robpalme Yes this is the "fix" if follow the [[Define]] semantic. Unfortunately, such fix is not very obvious to most JS/TS programmers, and many see your "correct code" and want to refactor it to the wrong form. 🙃
There are also many cases, you have no way to "fix". For example: Base class originally use traditional imperative form, subclass override it to accessors. Then one day the author of base class want to adopt class fields because it's a new feature and should be wonderful! Remember the author of subclass can not "fix" the decision of base class.

@trusktr just another example that i just ran into, related to [[Define]], and maybe someone already mentioned it:

It will be a massive mess regardless TS/JS

@bigopon Yes, this is an implication of the semantics that TC39 chose deliberately in 2016 in collaboration with the TypeScript team.

Please, all users are begging, don't make [[Define]] the default.

(We understand inheritance, and we understand side-effects from superclass accessors.)

This is really bothersome. I use frameworks on my base classes which use accessors to make cool things happen with my subclasses.
If I change to using class fields (in JS environments that currently supports it, or in TypeScript 3.6 if it will be the case), then everything just breaks.
It's a total mess.

Please don't break people's code when they update to TypeScript 3.6.
At the very least, having an option like classFieldDefine, even if defaulting to true, would be awesome. I would certainly set it to false.

I still have concerns about the [[Define]] semantics, especially this case:
class Base {
  x = 1;
}

class Derived extends Base {
  get x() { return 2; }
  set x(value) { console.log(`x was set to ${value}`); }
}

const obj = new Derived(); // nothing printed
console.log(obj.x); // 1

The x field on Base replaces the x accessor on Derived, which breaks inheritance and may be confusing for users.
Given the time remaining for 3.6, I'm moving this to 3.7.

The same issue would exist but the other way around with [[Set]], though. 🤔

I've generally found that depending on subclass setters/getters just tends to make the base class much harder to refactor so // nothing printed doesn't really bother me.
The other case of console.log(obj.x); // 1 is a bit more concerning, but I don't really see any way around these sort've problems as it's basically the same as this sort've problem (that will happen regardless of [[Set]] vs [[Define]] semantics):
class Base {
  method = () => {
    return 12;
  }
}

class Derived extends Base {
  method() {
    return 7;
  }
}

new Derived().method(); // 12

Mind you I still think fields should be declared with := rather than = to make it clear class Point { x := 10 } is more like { x: 10 } rather than o.x = 10, but I think it's probably too late to change this.

I believe it never be late to stop a wrong decision and I believe class fields (many issues, especially the footgun of [[Define]] own property semantic) is the worst one in JS history after ES4.

Of course it can be too late; typeof null can never change. Similarly, class fields are shipped in over 50% of web browsers, so the time to make any changes has long passed.

@ljharb First I don't agree solely use shipping data as the threshold, second it can never beyond 50% of web browsers in REAL MARKET. All china mainstream browsers (cover 95%+ share of China market) do not land class fields (even public fields) up to now.

Stage 3: Indicate that further refinement will require feedback from implementations and users
¯\_(ツ)_/¯

Indeed; but that feedback still can’t break the web - so if anyone is relying on Define on the web, it can’t change.

What's an example of a refinement that wouldn't break the web? Why does stage 4 exist at all? Should we just move things to Stage 4 as soon as Chrome puts it out there unflagged?

@ljharb FWIW I don't think it's useful to suggest no changes are possible on a stage 3 proposal until the feedback is collected and presented. It may be practically true, but it's better to be receptive to user/implementer feedback during stage 3 until TC39 has explored the options before them in light of the feedback given.

Fair enough.

The TypeScript team can proceed however they like of course, but IMO it would be worth going ahead and beginning work on updating the semantics of TS class properties to match the new ES spec. The PR could be left open since TC39 could still receive new and significant feedback as class fields are used in the real world. But I think the odds are extremely low that the real-world issues with the Object.defineProperty behavior would be so significant and common that they would justify changing the semantics at this point. I'm concerned about compatibility issues between JS and TS here, especially now that many people are compiling TS with Babel.
BTW, as someone who's not a fan of the Object.defineProperty semantics, I wish people on the TS team had argued against it more earlier in the process, especially those who are on the TC39 committee (although perhaps there were mixed opinions among the TS team). But there were two valid sides to that debate, and at some point we have to accept the spec and move on. Otherwise the differences between TS and JS will probably cause far more issues than would ever have been directly caused by the defineProperty semantics in the first place.

I wish people on the TS team had argued against it more earlier in the process

The best time to fix a issue was early stage. The second best time is now.

After we noticed problems with backward compatibility of .d.ts files in Azure SDK, we decided to change .d.ts emit when --useDefineForClassFields is off. Instead of emitting accessors, which only versions of Typescript will not parse in .d.ts, the compiler will emit a property with a leading comment. So this class:
class B {
  get p() { }
  set p(value) { }
  get q() { }
  set r(value) { }
}

Would emit
declare class B {
  /** @get @set */ p: any
  /** @get */ q: any
  /** @set */ r: any
}

Typescript 3.7 and above will look for these comments on properties and treat them as accessor declarations.

I still have concerns about the [[Define]] semantics, especially this case:
class Base {
  x = 1;
}

class Derived extends Base {
  get x() { return 2; }
  set x(value) { console.log(`x was set to ${value}`); }
}

const obj = new Derived(); // nothing printed
console.log(obj.x); // 1

The x field on Base replaces the x accessor from Derived, which breaks inheritance and may be confusing for users.

@rbuckton Using [[Set]] won't really fix inheritance, but only make the breaking happens to some other people. Say that I need to use throwing getter as abstract property, like:
class Base {
  get brand(): string {
    throw new Error(`Id must be defined`)
  }
}

class Derived extends Base {
  brand = 'derived'
}

const d = new Derived()
console.log(d.brand)

The above works well with [[Define]], but throwing for [[Set]]. You may argue that TypeScript has abstract modifier to better handle this, but abstract cannot be combine with static, for example:
class Base {
  static get brand(): string {
    throw new Error(`Id must be defined`)
  }
}

class Derived extends Base {
  static brand = 'derived'
}

console.log(Derived.brand)

This issue already happens in TypeScript today and break my use case. I'm not going to say [[Define]] is better than [[Set]], in fact, both of them cause footguns and neither is better than another.

That was my point with https://github.com/microsoft/TypeScript/issues/27644#issuecomment-518543395

@trotyl I disagree. When comparing options, we should consider the frequency and severity of the issues, and I think it's a real stretch to say both options are equally good/bad. The use cases I've seen where [[Set]] is problematic are mostly issues of semantic purity or fairly minor issues that would occur pretty rarely. Your example is the first I've seen that I would agree is a pretty significant footgun when using [[Set]]. But the foot-guns with [[Define]] are generally more significant and seem more likely to occur, at least based on what I've seen in online discussions about this issue.
So that's my two cents, but I'm not sure why we're still discussing this at all—the ship has sailed. I agree with those who say that stage 3 shouldn't completely close the window to further changes (e.g. changing the syntax to := instead of =), but I think the bar for justifying such changes should be very high—for example, if the semantics of the current proposal were causing great confusion to thousands of developers on a daily basis after this feature shipped in browsers. Since the Set/Define issue only affects this edge case of inherited fields and setters, I just don't see that happening. I think at this point, far more confusion would be caused by changing the default semantics of a feature that's already shipped than the relatively rare instances where the Set/Define distinction actually matters.

@mbrowne

When comparing options, we should consider the frequency and severity of the issues, and I think it's a real stretch to say both options are equally good/bad. The use cases I've seen where [[Set]] is problematic are mostly issues of semantic purity or fairly minor issues that would occur pretty rarely. Your example is the first I've seen that I would agree is a pretty significant footgun when using [[Set]]. But the foot-guns with [[Define]] are generally more significant and seem more likely to occur, at least based on what I've seen in online discussions about this issue.

I see your points, but have got different conclusions.
Almost every "problematic" examples with [[Define]] I see are violating OO practices, more specifically, overriding a base class member without knowing it intended to be virtual/abstract.
Even the example provided by @rbuckton, from a reviewer perspective, is intended to break the application. Even with the x in Base class being an accessor property, overriding it without calling super getter/setter would always result to unexpected behavior, as the base accessor may contain critical logic for base class to work.
Regarding controlling of override ability, OO language can be divided into two categories, explicit-virtual and explicit final, the latter in practice has been considered a design failure, where in any Java code style you should always write the final manually, and newly created JVM languages like Kotlin has go to the opposite design.
From the lengthy history of OO language, overriding a base class member without knowing it can be overridden is not something feasible, the whole application could break one day or another.
Unfortunately JavaScript is even worse than explicit final languages like Java, which cannot prevent overriding at all (in common declarative class code). If possible, I'd definitely like JavaScript class member to have explicit-virtual semantics, or at least runtime detection like https://github.com/tc39/proposal-class-fields/issues/176#issuecomment-538104298.

What about decorators? Will the property descriptor is passed to decorator if useDefineForClassFields: true?

@trotyl @mbrowne The corpus I inspected, our internal test repos + the ones at ~/Typescript/tests/cases/user, shows that people rarely override properties with accessors and vice versa. I tested the code with --useDefineForClassFields, which disallows property/accessor and access/property overrides.
In fact, failures only happened in older code: there was one example of a property-override-accessor in Angular 2's examples. I believe it was intentional, and would only work with [[Set]]. There were 7 examples of accessor-override-property, all of which were trying to make the derived property readonly by only providing get, which would crash with [[Set]], so I think those accessors were never used.
For modern TS, they would instead write
class B {
  x = 1
}
class D extends B {
  readonly x = 2
}

Google and Bloomberg also checked their code bases and found no tricky failures. It's safe to conclude that [[Set]] vs [[Define]] is not practically important.

Since this targets 3.7.1, I'm going to close this bug. When class fields reaches stage 4, I'll do the final two steps.


Run some migrations only for test purpuse

Hi,
Thanks for this lib.
I use migrations for my database.
For tests it's also useful to init my database before running tests in a  docker container.
Some tests need to insert some fake data before executing it, like a login test. In liquibase word, we have the ability to add some migration only for test, dev, prod environments.
Maybe what I am asking for it is not good practice to keep migrations clean.
So I like to hear from you and floks what do you think?

You can do that without help from this library, and I would suggest that would be the better approach!

thanks for your reply.
I choose to insert data from sql script with the help of testcontainers-node before running tests.
you can close this issue.
Thanks


Migrate to django viewflow.fsm

django-fsm is no longer maintained and was archived on 9 April 2023.
It now lives in viewflow

Actually, viewflow already implement a logging mechanism https://docs.viewflow.io/fsm/models.html#logging

Viewflow is a totally different package, it's not possible to migrate to it (I think).
Here the discussion to migrate to django-fsm-2 which will be mantained.


Linear Search cpp code added

Linear Search cpp code added

Thanks for adding "hacktoberfest-accepted" label to my PR @bhaveshlohana . But I don't know why it is showing Ineligible Repository to the PR in my Hacktoberfest profile section. Could you just confirm it? :)


Add deprecation notice

cc @ehazlett @nathanleclaire @jeffdm @mchiang0610
Not ready for merge just yet, but should be prepped for the 1.8.0 release.

See also https://github.com/boot2docker/boot2docker/pull/1013.

LGTM

LGTM

LGTM, though I'd prefer to also have a proposed EOL date

Docker 1.8.0 was released :smile:

Seems OK to merge this in now

:+1:


Generate BUILD.bazel files before running tests

This should generate all the necessary files by running the "//:gazelle" target before testing anything.

Is it expected that Gazelle does not work on Windows?

Yes, see the comment right next to your edit about how rules_go is broken - https://github.com/bazelbuild/rules_typescript/pull/240/files#diff-b87fc4746c05e7b451e025d6d2914276R40
I think we'll just need to exclude all the go packages from the windows CI right now.
/cc @jayconrod

was merged in 312bfeb8546997d67034e93aaedbc0906e13fefc


is there any other config??my server give a 500error?

i composer it to my server,and chenge the config path,,but it can not run fine!!
<?php

namespace App\Http\Controllers;

use Pbmedia\LaravelFFMpeg\FFMpeg;

class ConvController extends Controller
{
    //
    public function conv2mp3()
    {
        FFMpeg::fromDisk('videos')
            ->open('beeen.Mp4')
            ->export()
            ->toDisk('converted_videos')
            ->inFormat(new \FFMpeg\Format\Audio\Mp3)
            ->save('beeen.Mp3');

    }
}

Maybe you need to start learning the basics of PHP and Laravel. Try to do some more debugging and investigation before opening issues.


Round for doubles should take the number of decimals as argument...

This issue was originally filed by<EMAIL_ADDRESS>
If I have the number 12.346 and I need to round it to only two decimals is not possible, all I have is 12.346.round(), and the result is 12.0. It would be ideal to do 12.346.round(2) so the result can be 12.35.
References:
In C# there is Math.Round(double, decimals)
In Pascal there is RoundTo(double, decimals).

Python equivalent: round(double, decimals)
Being able to round numbers is kind of useful. Dart should definitely have this in the standard library.

num.round() returns an int AFAIK and there is no way to specify the number of fraction digits in double. This would need something like the decimal number in core.

@zoechi num.toStringAsFixed() does exactly what you'd expect from round() in other languages. It's just difficult to discover this fact since the Dart docs for num.toStringAsFixed() don't clearly state that it does rounding for you. I think most people would probably look at the existing num.round() method and see it doesn't support decimals and not bother to look at the very poorly named num.toStringAsFixed() rounding method.

@eukreign I don't argue against that. I think that it just can't be integrated into num.round() because the return types differ.

Up until about 90 minutes ago, I thought dart was attempting a serious language. Now, my confidence is completely shattered and I'm dumbstruck with how ridiculous rounding a number is in dart.
Other languages just do it, even far more complicated and 'correct' focused languages like rust and so on. With dart, I'm getting the most intensely weird problems. 2.2225 in a double with toStringAsFixed (2) will round to 0.0 for example, but using a concrete static type will round correctly. The internet is rife with apologists and excuses for why dart does things in incredibly awful ways. I honestly thought I was being punkt for a second.
I know this post might sound ranty but... I needed somewhere to post this as I'm still in disbelief.

num.toStringAsFixed() returns string, not float. You can't perform arithmetic operations on it, like: num.toStringAsFixed(2) + 1.5

What if I need a double with precision, not a string. i.e . need 1.00 or 2.00 .
num = 1
double.parse(num.toStringAsFixed(2))
this will return 1 again.
Why do we need toStringAsFixed(n) where we can call .toString on every type.
Rather this is more important to have precision that return it's original type.

Yes toStringAsFixed is for strings, no use for Maths. We need it for doubles - especially since flutter has it's peculiarities with like 85.0 + 0.1 = 85.1, but add another 0.1 and it equals 85.19999999 or whatever.

Come on, this is basic stuff.

That's not a Flutter peculiarity. It's an IEEE-754 floating point peculiarity which is shared by all languages using normal floating points. The value of 85.0 + 0.1 + 0.1 is not the same double as 85.2. It's not the same because the numerical value 0.1 is not exactly representable as a double value, and the two additions of inexact values causes the error to accumulate to the point where the difference is distinguishable.
Dart chooses to give different double values different toString results. So does, e.g., Java and C#.
That's not to say that we can't have a rounding operation which rounds to a specific number of decimal digits (and then to the nearest representable double value).

Yes. That was an attempt to get back on track, and not discuss toString :)

I have a solution. It's kinda of a hack.
Multiply the double by a 100 (Increase if you want more precision) then use roundToDouble() and then divide by 100 again.
double num = 0.59841;
double roundedNum = (( num *100).roundToDouble())/100;

@YoussefLasheen The original post stated that he wanted to specify the amount of decimal precision with a simple integer (1, 2, 3 etc). I already made this kind of formula like yours as a workaround too but I think also the point also is we want it built into Dart like toStringAsFixed

Taking @YoussefLasheen's idea a bit further, we can write our own extension methods. Keep in mind that working with doubles is not precise and can give unexpected results. Also, a proper implementation for this should also assert that the number of digits is not higher than a certain number, so pow(10, digits) does not overflow.
import 'dart:math';

extension DoubleRounding on double {
  /// Floors to given number of digits
  ///
  /// 10.2468.floorDigits(1) -> 10.2
  /// 10.2468.floorDigits(2) -> 10.24
  /// 10.2468.floorDigits(3) -> 10.246
  ///
  /// Might give unexpected results due to precision loss: 10.2.floorDigits(5) -> 10.199999999999999
  double floorDigits(int digits) {
    if (digits == 0) {
      return this.floorToDouble();
    } else {
      final divideBy = pow(10, digits);
      return ((this * divideBy).floorToDouble() / divideBy);
    }
  }

  double roundDigits(int digits) {
    if (digits == 0) {
      return this.roundToDouble();
    } else {
      final divideBy = pow(10, digits);
      return ((this * divideBy).roundToDouble() / divideBy);
    }
  }

  double ceilDigits(int digits) {
    if (digits == 0) {
      return this.ceilToDouble();
    } else {
      final divideBy = pow(10, digits);
      return ((this * divideBy).ceilToDouble() / divideBy);
    }
  }
}

Working with doubles while requiring precision is never easy. They are designed to be lossful.
Multiplying by pow(10, x) can lose precision (it increases the number of bits required by roughly 2 per x, which might push a number past the 53 available bits of precision). If you only care about .roundDigits(n) for small ns and small numbers, it's going to be fine. If you end up with something already using 48 bits above the decimal point, asking for 3 digits of precision might give a slightly wrong result.
Example:
  var x = (pow(2,43) - 1) + .0625;
  print(x); //<PHONE_NUMBER>207.0625
  print(x.roundDigits(5)); //<PHONE_NUMBER>207.063

@lrhn I agree with everything you say. The thread itself asks for something that doubles are not able to do properly. Even so, there might be cases where the proposed solution is useful.

The functionality can definitely exist. We have the code which does toString and toStringAsFixed, and it can certainly be adapted to generate a new double which is equal to what toStringAsFixed would have output. I'm not sure it's going to be particularly more efficient than actually doing toStringAsFixed, but obviously it can avoid the string allocation.
It's still somewhat worrying to have a function documented as rounding a double to a number of decimal points when most decimal fractions cannot be represented precisely as a double.
We want to avoid doing something which gives a wrong result in some situations. Either you can trust the function, or you can't. It's not enough that it works for small numbers. (Obviously, if we know that it works for small numbers below some threshold, we can use it for small numbers and fall back on toStringAsFixed+parse for large numbers).

Tested @andreidiaconu ' s methods  for a workaround and it works for me.

IMO, people who care about decimal representations probably should consider using something like package:decimal  instead of doubles anyway, and then rounding to a specified number of digits is fairly straightforward. (package:decimal also internally uses BigInt and should avoid problems with overflow.)


Switch to Go modules

Switch to Go modules and remove vendoring
Use different fork of go-powershell: replace the current go-powershell
dependency with https://github.com/antoninbas/go-powershell. This fork
converts the project to Go modules and removes the dependency on juju
packages (which are distributed under an LGPL v3 license, making usage
in commercial products difficult)
Enable CI: run unit tests using Github workflows

Fixes #13

@rakelkar could you enable Github actions in this repo so the tests can run?

@rakelkar could you enable Github actions in this repo so the tests can run?

Hey Antonio - thanks for your PR - quick qn, did you try to get your changes in go-powershell updated to benmoss repo?

Hey Antonio - thanks for your PR - quick qn, did you try to get your changes in go-powershell updated to benmoss repo?

@rakelkar I wasn't planning on doing it, since benmoss/go-powershell is already a fork and the original project seems to be unmaintained. Is that an issue for you? If yes, I can try to reach out to benmoss.

Would be great if you can try to get an okay from benmoss him as a curtsy :)

have enabled actions btw!

I have opened the PR: https://github.com/benmoss/go-powershell/pull/1
If it's accepted, I'll update this PR. Looks like there are some unit tests failures, so I'll address them as well at that time.

I got my answer: https://github.com/benmoss/go-powershell/pull/1#issuecomment-774105035. He recommends switching to a different fork.

@rakelkar I rebased the PR and fix the test failures.
By the way, do you have any insight about the difference between this package and the upstream K8s one: https://github.com/kubernetes/kubernetes/tree/master/pkg/util/netsh?

@rakelkar I rebased the PR and fix the test failures.
By the way, do you have any insight about the difference between this package and the upstream K8s one: https://github.com/kubernetes/kubernetes/tree/master/pkg/util/netsh?

Actually there is no equivalent to https://github.com/rakelkar/gonetsh/tree/master/netroute in upstream K8s

@rakelkar friendly ping for this


Able to work on colab almost effectively except some functionalities

I have updated the widget.py file and based on my modifications, the altair_widgets are running on colab and plus I was able to run a demo colab notebook in which I have shown the working of the altair_widgets with a local customized package based on this pull request widget.py.Demo Colab Link

@alihussainia I've added the commands to the README, and removed other files. Does that look good to you?

Thank you, brother @stsievert it is fine for me but I would say that what if the commands are added to the widget.py file as if you test the widget.py file along with these commands on regular jupyter notebooks and if they won't give any error then it will be good addition to the widget.py especially for those who are looking forward to use it on colab by directly importing the project via pip :)

I've made some changes; now, I issue a warning if the notebook is running on colab, and point to the docs. Would that address the issue?

@stsievert awesome amigo! Thanks bro. I thought I would also become a contributor to the repo but its fine :) thanks for your time and consideration.
Best wishes,
Muhammad Ali

Should I close the PR?

Perfect, I've merged this PR into 20f66597532626a17456f58a3bc3e3a9d4d24c82 (which we co-authored).

Thank you, Thank you so much brother! You just made my day amigo. I am truly happy and grateful to you for this favor brother. Please share your linkedin id too, I would definitely like to connect with such an awesome brother of mine.
Thanks once again brother.
Muhammad Ali
Your brother and now a contributor too <3


Works randomly on my side

Hello,
I would like to know how to set the script for 24 hours a day please ?
In addition on my side, it works randomly from 19 to 8 😔
Thank you for your answer.
Google Chrome Browser with Tampermonkey

Hello!
It is late, but I think it is better to update other people.
I believe I've answered your feedback on Greasy Fork
To use the Dim theme for 24 hours, you do not need a script; just go to the settings in your Twitter web app and change the preferred theme.


added code to HTML file

Added the sections of the website (e.g., HTML, CSS, Javascript, etc.) with the list of my notes.
This PR adds all of the HTML we need for the prework study guide application. By the way, section 3.1.6 has all the notws on how to pull a file to Git hub.

N/A


Add Licensing

Hi, great work with this!
What licensing is this repo under?
Would be helpful to know so that I can ensure compatibility with my own personal projects!

Hey,
thanks a lot for the comments! I'll add licensing by the end of next week  :)


RestrictSigninToPattern setting description is a bit misleading

The RestrictSigninToPattern setting description is misleading as it says "determines which accounts can be set as browser primary accounts." Where it actually should be something along the lines of "determines which accounts can be used to sign into the browser." Once you restrict that to whatever pattern it might be, it doesn't matter whether it is a primary profile or a second/third/fourth profile, only accounts that match that pattern are allowed to sign in.

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

ID: 198c6f64-9e5c-f18e-8439-8d0d11d4228d
Version Independent ID: 83f32be1-063c-284c-dfdc-6b5976a5b7cc
Content: Microsoft Edge Browser Policy Documentation
Content Source: edgeenterprise/microsoft-edge-policies.md
Product: microsoft-edge
GitHub Login: @dan-wesley
Microsoft Alias: stmoody

@gmarnold25 Thanks for the feedback!  We've passed it on to the MS Edge Identity Team.  We can follow up if there are any updates/insights to share.
If you have further questions regarding Microsoft Edge please reach out on the Microsoft Edge Tech Community Forum or for Enterprise specific questions please visit the Enterprise section of the Tech Community. Thanks!

Please see https://techcommunity.microsoft.com/t5/enterprise/adding-multiple-domains-to-restrictsignintopattern-string/m-p/1412242 from May 2020.
@Y-Kelly  this still needs some clarifiaction, please.

@gmarnold25 @joegoerlich The policy documentation for RestrictSigninToPattern (https://docs.microsoft.com/en-us/DeployEdge/microsoft-edge-policies#restrictsignintopattern) has been updated.
Thanks!


Align IP selection behavior with kernel

Sorting IPs by bytes.Compare gets rid of creation order, which can
lead to secondary IPs being chosed for masquerading and NodePort SNAT
purposes. Instead, stably sort by ifindex to preserve creation order and
give preference to primary IPs. Also, filter out secondary IPs.
This also more closely aligns with the Linux kernel's IP selection
behavior.
Fixes: #22853
Align selection of IP addresses used for masquerading and NodePort SNAT with Linux kernel behavior, by preferring addresses assigned to the interface earlier and filtering out secondary addresses.

Thanks for your PR. I am not familiar with this code path, so I will ask for  other agent member to review the changes :pray:.

Would appreciate a review on this. Anything I can do to help?

@akhilles I believe the comments on the caller to this function  firstGlobalV4Addr will need updating. Most notably, this statement is no longer true, correct?
// firstGlobalV4Addr returns the first IPv4 global IP of an interface,
// where the IPs are sorted in ascending order.

I believe the addresses will be returned in creation order, as that's how the kernel returns them on my machine.

/test

I think the test failure is unrelated or a flake. I noticed an unrelated PR (22768) failed with the similar error (on a different k8s version):
[unable to upgrade connection: Authorization error](error: unable to upgrade connection: Authorization error (user=kube-apiserver-kubelet-client, verb=create, resource=nodes, subresource=proxy))

Would it be possible to rerun the tests?

/test-1.25-4.19

Looks like Cluster mesh w/ WireGuard test failure is also known flake: https://github.com/cilium/cilium/issues/23044.

Looks like Cluster mesh w/ WireGuard test failure is also known flake: #23044.

Yep, that one was disabled in the meantime so fine to ignore.
Everything else is green and we have reviews so I'll mark ready to merge.

Thanks!


Use "text/plain" content-type

gofmt'd @exarkun commits from #9955
Closes #9955
Fixes #9954

Docs still LGTM - @fredlf @jamtur01

Docs LGTM

LGTM

updated, I added a commit bc those other weren't mine idk if I should have just updated their commit

ummm drone?

Drone is tired, too much work for a single node

https://ci.dockerproject.com/github.com/docker/docker/commit/cd5902fc7bb0da36fedb6ff6a1bb8ef200b212d9?branch=9954-text-plain-content-type its in the queue :D

LGTM


Could you please provide a simple comparison table list between OpenPAI and Kubeflow?

as title :)

sorry, we couldn't comment other products as both could be a moving target. A comment at some point of time could quickly become outdated.
Please refer to the document of OpenPAI here for the detailed functionality. https://openpai.readthedocs.io/en/latest/


Replace Airbyte warning with compatibility warning and generic "low project usage" warnings

When anonymous telemetry reports less than 5 projects successfully running a tap or target over the rolling 90 day window, that is generally an indication that the tap is not working well, or has not been properly documented. We often get new users trying out these taps and getting frustrated if the first 3 or 4 taps they try out are difficult to setup or have some important documentation or usability bugs.
Why 5 minimum projects?
The first 2 or 3 projects are usually the developer themselves testing the plugin, so we should require at least 4 or 5 sightings "in the wild" and running successfully before we remove the top-of-page warning. Since the window is 90 days long, this should be plenty wide of a window to have a minimum usage volume established. (All of the tap-postgres variants have at least 30 projects
What should the warning say
The warning can emulate our current Airbyte "experimental" warning text (example here), but does not need to be overly aggressive or "scary". The goal is not to prevent the user from downloading and testing the tap, but to steer new users to another implementation or another "first tap" to try when they are first getting started. This can also encourage maintainers and existing users of those taps to help improve docs and/or check for implementation bugs which may be affecting other users.
Dropping "experimental" label from Airbyte
With this new warning above added based on "in the wild" implementations, we can remove the tap-airbyte experimental warning, and replace with some generic prereqs and compatibility notes that explain the inherent limitations of Airbyte-based taps, such as the need for docker-in-docker support, and related inability to run on ECS. We can link to Airbyte's own page explaining the limitation here: https://docs.airbyte.com/deploying-airbyte/on-aws-ecs/
We should also try to import or link to Airbyte's own maturity grade for the specific connector (optionally as a follow-on task), since many are clearly denoted as alpha or experimental, and we on the Hub should not skip over declaring those limitations and early-stage dev status warnings to our users.
Airbyte's warning to their users is:

Alpha: An alpha connector signifies a connector under development and helps Airbyte gather early feedback and issues reported by early adopters. We strongly discourage using alpha releases for production use cases and do not offer Cloud Support SLAs around these products, features, or connectors.

And the link to their index with alpha/beta/GA evaluations is here: https://docs.airbyte.com/integrations/
If it is difficult to deep link or import this data to the Hub, we can at least provide the above link to allow potential users of wrapped Airbyte connectors to understand what level of maturity the connector is listed as.

@aaronsteers I think this would be a great feature and starts to remind me of our gold/silver/broze discussions but I dont think this feature should be a blocker to removing the airbyte warning. I personally think we put a disproportionate weight on warning about Airbyte and I think the FAQ does a good job of calling out most of these things already.
I think sufficient info to remove the warning should be: a blurb at the top with a reference to the FAQ, mention that theres extra challenges with deploying container based plugins, and link to the alpha/beta/GA airbyte docs.
Would you be open to decoupling this feature from the Airbyte warning?

I have more thoughts on the feature itself but I'm still ruminating a bit - I think 5 projects makes sense and I think framing it more like "we dont have enough data to be confident in this variant" vs "warning this is probably buggy" makes sense to me since theres only so much the data can reliably tell us. I'm starting to like a star feature where you get a star for each evaluation attribute:

sufficient usage > 5 successful projects?
SDK based
maintenance status active in plugin definition and latest git commit within a year (when we know this)
meltano/meltanolabs supported - maybe even generically org supported meaning meltano/transferwise/stitch/airbyte
other stuff?

But that means meltanolabs tap-github https://hub.meltano.com/extractors/tap-github would be 4/4 stars high confidence in this case and airbyte tap-jira https://hub.meltano.com/extractors/tap-jira--airbyte/ would be 0/4 stars low confidence right now, which I dont think is a true reflection especially because Alex said airbyte's Jira tap was the reason he built the wrapper.

Thanks, @pnadolny13 . Your feedback is much appreciated. I think we have a general park forward here. I'll defer on commenting on the stars/ranking until a bit later but the general direction is right, I think

Would you be open to decoupling this feature from the Airbyte warning?

No, not really. We either need to warn about low usage, or Airbyte, or docker-in-docker/ECS limitations
At least one of these warnings is required, I think.

No, not really. We either need to warn about low usage, or Airbyte, or docker-in-docker/ECS limitations

@aaronsteers I think we might be on the same page already 😄 - in my comment I was pitching:

a blurb at the top with a reference to the FAQ, mention that theres extra challenges with deploying container based plugins, and link to the alpha/beta/GA airbyte docs.

At the top meaning the top of each airbyte plugin page. I'm just saying that I think we can add more details around challenges with Airbyte to remove the warning symbols/preview label without having to implement this "low usage" feature (which I think is a good idea but I'm suggesting we decouple the 2). Is that a reasonable path forward?

Thanks for clarifying, @pnadolny13 . Maybe the minimum change is: "replace Airbyte warning with Docker-in-Docker warning" which is inferred from your comment above but I just would want to be really clear - especially to help prevent people from creating dev-time dependencies on components that are then not possible to deploy to their/our production environment.


cannot load such file -- bundler (LoadError)

Install ruby
gem install benchmark_driver
ruby -e "require 'benchmark/driver'" causes cannot load such file -- bundler (LoadError)

benchmark_driver-0.8.2/lib/benchmark/runner/exec.rb requires bundler, but benchmark_driver gem does not depend bundler gem.

resolved in https://github.com/k0kubun/benchmark_driver/commit/337b64bbba5106a3514beff5199c5ccb9f6d2b4d


Formatting test for #1888

I hope I'm doing right. Please give some feedback if not :)

Hi @SaschaNaz, I'm your friendly neighborhood Microsoft Pull Request Bot (You can call me MSBOT). Thanks for your contribution!

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

TTYL, MSBOT;

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

thanks @SaschaNaz, but you need to make it pass for now :). what i would do is comment out the correct check and add a comment:
// Expected behavior, should work once bug 1888 is fixed
// verify.currentLineContentIs('        ""');
verify.currentLineContentIs('"    """');

@mhegazy Oh, I see, I fixed some lines to make the test pass.
BTW, how can I run a single specific test? jake runtests tests=formattingOnChainedCallbacks does not show any passing/error log...

thanks!
@CyrusNajmabadi was just mentioning the same issue today. we need to look into this.


⚠ Bofrost.be has degraded performance

In f312524, Bofrost.be (https://www.bofrost.be) experienced degraded performance:

HTTP code: 200
Response time: 2128 ms

Resolved: Bofrost.be performance has improved in 4565332.


Create a basic index view

The project needs a basic index view that will display when the user navigates to the root "/" URL.  This should probably contain a basic static template with introductory text and links to other views.
NOTE:  This view should probably be created at the project level rather than in the "talks" app to make "talks" more reusable later.

Will relocate appropriate files and folders


How to use plonkit to verify proof for given public inputs?

After calling plonkit prove I have proof.bin, proof.json, public.json.
Public.json contains the public inputs and the public output of the circuit, correct? So how I can verify the proof is valid for that public data? That is, if i change the public inputs the proof should fail verification.
I'm envisaging something similar to this:
snarkjs groth16 verify verification_key.json public.json proof.json
e.g.
plonkit verify vk.bin public.json proof.json
But current verification only requires proof.bin, e.g. `plonkit verify proof.bin vk.bin'. What is stored in proof.bin? Does it already contain the public inputs and outputs too? Thanks.

Yes.
Proof.bin contains both proof and input. These two *.json are mainly used for ETH contract.
Welcome to our tech telegram group~ https://t.me/fluid_dex

Yes.
Proof.bin contains both proof and input. These two *.json are mainly used for ETH contract.
Welcome to our tech telegram group~ https://t.me/fluid_dex


How to add a postcss plugin?

This is more of a question than an "issue".
Has anyone figured out how to add a postcss plugin that is not included with the postcss plugin? If you can give me any hints it would be much appreciated!
I'm trying to add the rfs plugin (https://github.com/twbs/rfs) but everything I've tried doesn't seem to work.
In a vanilla vue cli project I'd just add this to the postcss.config.js file:
module.exports = {
  plugins: {
    tailwindcss: {},
    rfs: {},
    "vue-cli-plugin-tailwind/purgecss": {},
    autoprefixer: {}
  }
};

I've tried adding this to gridsome.config.js:
...
css: {
    loaderOptions: {
      postcss: {
        plugins: {
          rfs: {}
        }
      }
    }
  }

But I get the following error:
$ gridsome develop
Gridsome v0.7.11

Initializing plugins...
Load sources - 7.7s
Create GraphQL schema - 0.1s
Create pages and templates - 0.07s
Generate temporary code - 0.05s
Bootstrap finish - 9.92s
TypeError: (postcss.plugins || []).concat is not a function
    at applyLoaders (~project/node_modules/gridsome/lib/webpack/createBaseConfig.js:298:44)
    at createCSSRule (~project/node_modules/gridsome/lib/webpack/createBaseConfig.js:271:5)
    at module.exports (~project/node_modules/gridsome/lib/webpack/createBaseConfig.js:150:3)
    at module.exports (~project/node_modules/gridsome/lib/webpack/createClientConfig.js:8:18)
    at Compiler.resolveChainableWebpackConfig (~project/node_modules/gridsome/lib/app/Compiler.js:23:25)
    at createWebpackConfig (~project/node_modules/gridsome/lib/develop.js:107:39)
    at module.exports (~project/node_modules/gridsome/lib/develop.js:28:31)

Hey,
you use Tailwind as i see in your Config.
Than you dont need to add a seperate PostCSS Plugin. Its already built in.
https://www.npmjs.com/package/gridsome-plugin-tailwindcss
Just add this to your Gridsome config.
modules.exports = {   plugins: [     {       use: 'gridsome-plugin-tailwindcss',       options: {         tailwindConfig: './some/file/js',         purgeConfig: {},         presetEnvConfig: {},         shouldPurge: true,         shouldImport: true,         shouldTimeTravel: true,         shouldPurgeUnusedKeyframes: true,       }     }   ] }
Let me know if you need further assistance

The error itself tells you that postcss.plugins is an array and you should be adding your plugins in the array.
Try the following:
const rfs = require('rfs/postcss')

// and then

css: {
  loaderOptions: {
    postcss: {
      plugins: [
        rfs()
      ]
    }
  }
}

Awesome, thank you @Microflash !
I thought that I had tried every possible combination of things but apparently not!


Updated module importer to follow new schema and spreadsheet

Merge activity

Apr 22, 7:41 PM EDT: @tommylau523 merged this pull request with Graphite.


Project("{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}") = "CustomGroupMembershipPolicyInstaller", "CustomGroupMembershipPolicyInstaller\CustomGroupMembershipPolicyInstaller.csproj", "{33E91DFE-D591-40B9-B9AB-CB04002C3D42}"

https://github.com/oleksabor/GroupMembershipPolicy/blob/master/CustomGroupMembershipPolicy.sln#L2-L15

Hi could you please give more details as to the issue?


Update build files.

Removed internal app notes. Added updates from QAT 24.02 release.

Closing to re-do a new PR with Ronny.


Request detail: preview record tab

Current preview landing page is a jinja template (here the code). In consequence (as far as I understand) it's not possible to have the record tab previewing the record unless we have 2 different views for the preview, one with jinja and another with react, I personally would discard this as it's hard to mantain and only adds complexity. In my opinion I see 2 different solutions:

The preview view is not inside the record tab but it's just a button that will redirect to the already implemented preview view, as it's done currently in the deposit form, this way we can reuse the jinja template.
Cons: We change the initial design by removing the "record" tab and adding the preview button and it's less user-friendly.
Pros: easy to implement, easy to maintain.

Re-implement the preview page in react, this way we can have different views reusing the same components.
Cons: Redesign the landing page with react, doesn't make much sense to have a "static" page that doens't need any state build with react.
Pros: Easy to reuse components in differents preview views.

I would personally go with the first one.

2 more possibilities:
3. implement tabs in jinja and include the details.html template (not sure how big would the implications be, especially if we are talking about differences in serializers, its potentially complicated)
4. iframe to the records detail view


An error of poses_diff() function

def poses_diff(x):
    H, W = x.get_shape()[1], x.get_shape()[2]
    x = tf.subtract(x[:, :1, ...], x[:, :-1, ...])
    x = tf.image.resize_nearest_neighbor(x, size=[H.value, W.value], align_corners=False)  # should not alignment here
    return x

the subtract operation subtract x[:, :1, ...] and x[:, :-1, ...], while the first input might be wrong, it should be x[:, 1:, ...]. Current operation in fact subtract the first postion for all frames with array broadcast.
I have test that train the lite network on SHREC coarse data, the acc of validation is almost the same while the acc of training dataset is lower than validation. Which might be the reason of too much dropout. There might be still some space for improving.
If I'm wrong, please let me know

yes, I also find this error, after fixing it , the accuracy gets better.

Thanks very much for pointing out this issue. I had corrected them in the current version. As both of you had mentioned, such a correction did an improvement in SHREC data (for coarse data: It was improved from 94.6 to 94.8 with 1.82M parameters and from 91.8 to 94.1 with 0.15M parameters).

Thanks very much for pointing out this issue. I had corrected them in the current version. As both of you had mentioned, such a correction did an improvement in SHREC data (for coarse data: It was improved from 94.6 to 94.8 with 1.82M parameters and from 91.8 to 94.1 with 0.15M parameters).

great job! very fast and high accuracy. And have you ever tried this model on other dataset ,especially the NTU RGB+D dataset. which is very hot for skeleton based action recognition. and how is the performance

Sorry, I may not try it since the skeleton contains much noise and loses context information, it is not as good as only using RGB and I stop further investigate it from one year ago (this paper was made last year). If you are working on it, stacking more modules (e.g., 2s-AGCN) might help to boost the performance of NTU to ~96+(CV) and ~90+(CS).


Backport of current CIEID java tool

Hello,
I recently retried to work on cie-middleware-linux, and backported the latest java CIEID tool to your project (the pkcs11lib builds and works perfectly, but  CIEID is currently unusable for enabling new cards (there is a bug in how PIN is captured from JPassword fields). Hoping can help.

Thanks for your efforts. Anyway I can't merge this fort two main reasons:

I can't do a review of 199 changed files in only two commit.
I don't understand the need of backporting. This codebase is in sync with latest upstream source code.
The PIN works, at least for me. Can you try with the latest 4 digit of your PIN?

Right. Maybe I can tell my experience. I built your code after 1 year (now I own a CIE card, and I'm able to do some work). Wen I ran the java tool under jre11 the pin was refused in the abbinaCie method, because the getPassword() did not return the 1 character string content of the field, but a textual representation of the related JPasswordField
https://github.com/M0Rf30/cie-middleware-linux/blob/podofo-vanilla/cie-java/src/it/ipzs/cieid/MainFrame.java#L3620
The original code used the (deprecated) getText() instead, which gives the correct result.
I guessed (may be incorrectly) that the problem was corrected upstream, so I decided to backport the current version, hoping to include other fixes/features as well.
Too much! I will redo the PR, including only a single fix for the PIN problem.


Some questions about implementation

Hi,
I've been using your code in some experiments.
I have the following questions:

Applying your recent committed changes to the loss actually resulted in predicted values with weird (larger) ranges in my experiments, which were weirder to convert to an image. I had to "roll back" to the previous version...

Shouldn't the last layer have a sigmoid as activation so that the output has values between 0 and 1? These values should be comparable to the input ones, which I think are rescaled to be between 0 and 1, I am correct? Does this affect the reconstruction loss?

Also, in some other implementations the common reconstruction loss is the mean squared error and not the mean absolute error. Do you use 'mae" for some reason?

This is an extra issue that I'm having. Have you been able to use the Tensorboard callback to log the losses and metrics? When trying to add the Tensorboard callback I get an error which I think is because the ae model is made of two models, and thus internally has more than one loss. I get the following error:   line 1050, in _write_custom_summaries
summary_value.simple_value = value.item()
ValueError: can only convert an array of size 1 to a Python scalar
I could not find a solution yet..!

Minor detail: Why changing the stddev to its absolute value? Can it ever be negative?!

I'm sorry for the long text and for raising all these issues, but I think they may be relevant for more users too!
Thank you in advance!

The last commit changed the applied value of beta loss to be summed instead of averaged over the values in the latent space, which I think is what is done in other implementations. This greatly increases beta's contribution to the gradient.

Changing the output to sigmoid would force the output to the desired range, so it is probably a good idea. Without that, the problem is likely much more difficult for the network to learn. I will test out this change.

I am using the mean absolute error / L1 distance because that is what was used in the cyclegan paper, and I just remembered that as I was making this.

I have not tried to use tensorboard with this system yet. Post something if you figure it out! I am interested what the solution could be.

I made this change mostly because negative std deviation did not make sense to me. And I am pretty sure it would break the loss function (https://github.com/alecGraves/BVAE-tf/issues/4)

Thanks for the questions 😄

Update: the variable named stddev (which was the output of the previous layer) actually represents log variance, which can be negative. I corrected the variable name and undid the abs in https://github.com/alecGraves/BVAE-tf/commit/810506b1a142da49b3cc7eddcc4bb32856d5e51c

This is also kinda a better resolution to #4

Thank you for your reply and updates!
I'm going to test the refactored version and I'll let you know if something changes on my experiments. I saw you added a tanh activation. I'll also let you know if I figure something out regarding the use of tensorflow.
Please let me know if you happen figure something out too :)
Thank you

Hi!
I've tested your refactored version with my experiments. Results are different! For the better since I am able to get better reconstructions. Cool, thank you!
Just a question: is there any difference in feeding the auto-encoder with a range [-1,1] like you do, or feed the images in the range [0,1]? I'm using the second option and everything looks fine. The auto-encoder should adapt to the range (sampling layer adapts to any distribution), correct?
The only thing I think I should change is the final activation layer to a sigmoid so that my outputs are also in the range [0,1]. The loss function should be the same?
Thank you again!

Yes, the network should adapt to the different range without a problem. Changing the output layer to sigmoid would probably help the network because you are constraining the output to the desired range.


add new events for community.

We need to add more events for the community. Each one can contribute with some link of an event for development or for another context.
The data file can be found here. Add more links in it in the following template:

I'll like to be assigned this issue, I also want to be clear about the task, should I just get a link to an event for development and add it to the project or is there more to it?

Just a link with title, description, if possible image and deadline for registration.
Example:
{
        "title": "Hacktoberfest 2022",
        "image": "https://user-images.githubusercontent.com/43012757/193366195-c23979e1-60fd-4195-95e3-b0372f8a3c75.png",
        "description": "Hacktoberfest is a month-long celebration of open source software run by DigitalOcean in partnership with GitHub and Twilio. Hacktoberfest is open to everyone in our global community!",
        "url": "https://hacktoberfest.digitalocean.com/",
        "end_date": "2022-10-31"
}

This issue can be assigned by multiple people

Ok

@KartikChinda Sure! We are accepting contributions to this issue. Good hacktoberfest!

@clebsonf I would like to contribute. Please assign it to me.

I would like to assign some events 👀

Hello! Can I help with this issue?

Please check if I've completed the task as you expected.
On Wed, Oct 5, 2022, 18:31 Clebson @.***> wrote:

Assigned #8 https://github.com/OctobearHub/octobear.org/issues/8 to
@aparna03dubey https://github.com/aparna03dubey.
—
Reply to this email directly, view it on GitHub
https://github.com/OctobearHub/octobear.org/issues/8#event-7525015204,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AYJY3DACVUS64ADBKOFWRHDWBV337ANCNFSM6AAAAAAQ3QU2M4
.
You are receiving this because you were assigned.Message ID:
@.***>

@clebsonf hey there, I also want to add some OSS programs and summits in the programs section. Kindly assign this issue to me too. I would then be making a corresponding PR. Thank you!


Add jm_meessen, markewaite, poddingue as artifactdeployer developers

Add jm_meessen, markewaite, poddingue as artifactdeployer developers
Add @jmMeessen, @markewaite, and @gounthar as developers of the artifactdeployer plugin.  The plugin is up for adoption so permission should not be required from current maintainers.
We will use the plugins we adopt as part of our "Contributing to Open Source" workshop at DevOps World 2022. Participants will be invited to create useful contributions to the plugins as part of the workshop.  We'll assure the plugins have been updated sufficiently to use as a baseline for the workshop. Participants in the workshop will be guided as they take specific steps to improve the plugin.  We'll have reference pull requests that the contributors can use as "answers" when they are perplexed by a problem or unable to proceed.

Repository: https://github.com/jenkinsci/artifactdeployer-plugin
Pull requests: https://github.com/jenkinsci/artifactdeployer-plugin/pulls?q=is%3Apr+author%3AjmMeessen

Submitter checklist for adding or changing permissions
Always

[x] Add link to plugin/component Git repository in description above

When adding new uploaders (this includes newly created permissions files)

[x] Make sure to @mention an existing maintainer to confirm the permissions request, if applicable
[x] Use the Jenkins community (LDAP) account name in the YAML file, not the GitHub account name
[x] Make sure to @mention the users being added so their GitHub account names are known if they require GitHub merge access (see below).
[x] All newly added users have logged in to Artifactory at least once

Reviewer checklist (not for requesters!)

[ ] Check this if newly added person also needs to be given merge permission to the GitHub repo (please @ the people/person with their GitHub username in this issue as well). If needed, it can be done using an IRC Bot command
[ ] Check that the $pluginId Developers team has Admin permissions while granting the access.
[ ] In the case of plugin adoption, ensure that the Jenkins Jira default assignee is either removed or changed to the new maintainer.
[ ] If security contacts are changed (this includes add/remove), ping the security officer (currently @Wadeck) in this pull request. If an email contact is changed, wait for approval from the security officer.

There are IRC Bot commands for it

jenkins-admin: make jmMeessen a committer on artifactdeployer-plugin
jenkins-admin: make markewaite a committer on artifactdeployer-plugin
jenkins-admin: make gounthar a committer on artifactdeployer-plugin
Done


fix(ast): replace ArrayElementType[wip]

fix: #325
Not ready for review. I draft it to test CI and will check it in more detail.
cargo coverage passed now, but I am not really sure if I should write more test cases for this PR.

cargo coverage passed now, but I am not really sure if I should write more test cases for this PR.

cargo coverage covers everything, there is no need to create standalone tests (unless it's a fuzzing test).
Besides this, is this PR ready from your side?


Move papermill from pip to conda

Description

@roalexan @yueguoguo and I are having so much fun with the tests in Recommenders. We discovered that having papermill in pip instead of conda causes problems. This PR will prevent problems in the future
Related Issues

Checklist:

[ ] My code follows the code style of this project, as detailed in our contribution guidelines.
[ ] I have added tests.
[ ] I have updated the documentation accordingly.

it looks there is a problem with the dataset call:
E           urllib3.exceptions.MaxRetryError: HTTPSConnectionPool(host='nlp.stanford.edu', port=443): Max retries exceeded with url: /projects/snli/snli_1.0.zip (Caused by SSLError(SSLError("bad handshake: Error([('SSL routines', 'tls_process_server_certificate', 'certificate verify failed')],)",),))


enable set cluster log level using restart_server()

[!WARNING]
This pull request is not mergeable via GitHub because a downstack PR is open. Once all requirements are satisfied, merge this PR as a stack on Graphite.
Learn more

#918  👈
#907
main

This stack of pull requests is managed by Graphite. Learn more about stacking.

Join @BelSasha and the rest of your teammates on  Graphite


on mac os (m1) path for zls binary is correct, yet it keeps failing to run the zls server.

zig is installed using binary from master, zls built from source.
Path is: /Users/my-user-name/zls/zig-out/bin/zls

nvm, apparently the triangle character got pushed into there. Removing that fixed it.


Update card layout, footer, navbar menu and add .gitignore

📝 Change Description

Update card layout.
Footer layout
Navbar Menu Shadow
Add .gitignore

🔧 Fixes #102

📷 Provide related Screenshot/Gifs if any.
Card Layout:

Footer layout:

Navbar Menu Shadowing:

- [ ✔ ] I have performed a self-review of my own code.
- [✔  ] I'm a contributor in Hacktoberfest'21.

Hi @saloni-15 ,
I've reverted the card layout to default bootstrap card.
Please see changes below screenshot:

can you share the full page screenshot?

Hi @saloni-15 ,
Please see below full page screenshot.


Bootstrap tool tips not supported

Steps to Reproduce:

Fire up the skeleton navigation app (As per here:https://github.com/aurelia/skeleton-navigation)
Open welcom.html

Add the following code to the end of the first name input:
data-toggle="tooltip" data-placement="top" data-title="bootstrap tooltip" title="html tooltip"

Run the app

Hover the mouse over the first name input.  The tool tip shows as a plain html tool tip (not bootstrap).
Expected: tool tip would have the back background and white text that is default for a bootstrap tooltip.

Just to be sure, I also added the following to the top the file (below <template>):

I also tried adding this to index.html
I also added import 'bootstrap' to the welcome.js.
Nothing I did could get a bootstrap styled tooltip to show.  Since other bootstrap classes work fine, I assume that this is an issue with the template's support for the popup that is in a tool tip.

Bootstrap's tooltip component requires javascript. Use a custom attribute to execute the tooltip javascript
import {customAttribute, inject} from 'aurelia-framework';
import $ from 'jquery';
import 'bootstrap';

@customAttribute('bootstrap-tooltip')
@inject(Element)
export class BootstrapTooltip {
  constructor(element) {
    this.element = element;
  }

  bind() {
    $(this.element).tooltip();
  }

  unbind() {
    ${this.element).tooltip('destroy');
  }
}

Then on the element, add the bootstrap-tooltip attribute:
<require from="./bootstrap-tooltip"></require>

<input bootstrap-tooltip data-toggle="tooltip" data-placement="top" data-title="bootstrap tooltip" title="html tooltip">

@jdanyow Thank you so very much for this code example!  I was stuck and about to have to make a hard design change on my app.  This opens it up again!  Thank you a ton!

@Vaccano with Bootstrap4 which is developed on ES6, this will be even better.

Thanks! For those who want to, you can also access the jQuery selector functionality from Bootstrap instead of from jQuery itself. Updated example below:
import {customAttribute, inject} from "aurelia-framework";
import $ from "bootstrap";

@customAttribute("bootstrap-tooltip")
@inject(Element)
export class BootstrapTooltip {
    constructor(element) {
        this.element = element;
    }

    bind() {
        $(this.element).tooltip();
    }

    unbind() {
        $(this.element).tooltip("destroy");
    }
}

This suggestion doesn't work, or perhaps I'm missing something.
Unhandled promise rejection TypeError: $(...).tooltip is not a function
Stack trace:
bind@http://localhost:3000/lib/attributes/bootstrap-tooltip.js!transpiled:28:13
bind@http://localhost:3000/vendor/npm/aurelia-templating@1.0.0-beta.1.1.0/aurelia-templating.js:2774:9
bind@http://localhost:3000/vendor/npm/aurelia-templating@1.0.0-beta.1.1.0/aurelia-templating.js:847:9
bind@http://localhost:3000/vendor/npm/aurelia-templating@1.0.0-beta.1.1.0/aurelia-templating.js:2766:9
automate@http://localhost:3000/vendor/npm/aurelia-templating@1.0.0-beta.1.1.0/aurelia-templating.js:2712:7
swap/<@http://localhost:3000/vendor/npm/aurelia-templating-router@1.0.0-beta.1.1.0/router-view.js:116:9
notify/</run@http://localhost:3000/vendor/npm/core-js@2.0.3/modules/es6.promise.js:116:49
notify/<@http://localhost:3000/vendor/npm/core-js@2.0.3/modules/es6.promise.js:130:9
flush@http://localhost:3000/vendor/npm/core-js@2.0.3/modules/_microtask.js:25:7

I m using
tooltip.js -
import {customAttribute, inject, bindable} from 'aurelia-framework'; import $ from 'bootstrap'; @customAttribute('tooltip') @inject(Element) export class Tooltip {     element: HTMLElement;     @bindable title: any;     @bindable placement: any;     constructor(element) {         this.element = element;     }     attached() {         $(this.element).tooltip({             title:this.title,             placement:this.placement         });     } }
and view is

                     Offering:                     ${offering}

the binding to  tooltip="placement:left; title:${offering}" not working...
any idea please?

I believe there's a but with interpolation inside of an options attribute. Try title.bind instead and see if that fixes it for you.

With tooltip="title.bind: ..." it works.
I suggest extending @jdanyow solution to sth that allows dynamic title change:
@customAttribute('bootstrap-tooltip')
@inject(Element)
export class BootstrapTooltip {
    $element:any;
    @bindable title:string;

    constructor(element) {
        this.$element = $(element);
    }

    bind() {
        this.$element.tooltip({title: this.title})
    }

    unbind() {
        this.$element.tooltip('destroy');
    }

    titleChanged() {
        this.$element.data('bs.tooltip', false)
        this.$element.tooltip({title: this.title});
    }
}

<i class="icon-attention" bootstrap-tooltip="title.bind: msgs"

@krostkowski I get a Uncaught Error: No method named "destroy" when I hide (if.bind="show") a div that contains these tooltips. If I comment out the unbind method's body this goes away.

@jpravetz If you are using Bootstrap 4, "destroy" is now "dispose". So your code would look like: this.$element.tooltip('dispose');

Bootstrap puts the content of the title attribute into data-original-title
So instead of using title.bind="..."
I used data-original-title.bind="..."
And worked a treat with dynamic changes to the title attribute.

What would this look like using Typescript?

Can anyone point me to a Typescript version of this?  I'm sure I'm making a simple mistake, but I'm new to this.  The compilation error is : Property 'tooltip' does not exist on type 'JQuery'.
The code looks like:
'''
import { customAttribute, inject } from "aurelia-framework";
import "jquery";
import "bootstrap";
@inject(Element)
export class BootstrapTooltipCustomAttribute
{
constructor(element:any)
{
this.element = element;
}
bind()
{
$(this.element).tooltip();
}
unbind()
{
$(this.element).tooltip("destroy");
}
element:any;
}
'''

It look like a problem loading bootstrap+jQuery not Aurelia.
Typescript version be the same code, but if you are you using jspm, webpack
or other module system it can demand some configuration to use jQuery and
bootstrap together, see the bootstrap document if is this case
Em 01/12/2017 20:32, "robscottnh"<EMAIL_ADDRESS>escreveu:

Can anyone point me to a Typescript version of this? I'm sure I'm making a
simple mistake, but I'm new to this. The compilation error is : Property
'tooltip' does not exist on type 'JQuery'.
The code looks like:
'''
import { customAttribute, inject } from "aurelia-framework";
import "jquery";
import "bootstrap";
@Inject https://github.com/inject(Element)
export class BootstrapTooltipCustomAttribute
{
constructor(element:any)
{
this.element = element;
}
bind()
{
$(this.element).tooltip();
}
unbind()
{
$(this.element).tooltip("destroy");
}
element:any;
}
'''
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/aurelia/templating/issues/233#issuecomment-348607094,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AA5o5Vu93Iqc0Q8bovZE1Ij7TeugPfdQks5s8GJNgaJpZM4G2JBK
.

Sorry, I didn't saw that was a compilation error. You should install
bootstrap typings. Npm install @types/bootstrap (something like this)
Em 01/12/2017 20:32, "robscottnh"<EMAIL_ADDRESS>escreveu:

Can anyone point me to a Typescript version of this? I'm sure I'm making a
simple mistake, but I'm new to this. The compilation error is : Property
'tooltip' does not exist on type 'JQuery'.
The code looks like:
'''
import { customAttribute, inject } from "aurelia-framework";
import "jquery";
import "bootstrap";
@Inject https://github.com/inject(Element)
export class BootstrapTooltipCustomAttribute
{
constructor(element:any)
{
this.element = element;
}
bind()
{
$(this.element).tooltip();
}
unbind()
{
$(this.element).tooltip("destroy");
}
element:any;
}
'''
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/aurelia/templating/issues/233#issuecomment-348607094,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AA5o5Vu93Iqc0Q8bovZE1Ij7TeugPfdQks5s8GJNgaJpZM4G2JBK
.

Nuno,
Thank you so much.  It was a combination of needing to install the types
and updating the webpack config.  I appreciate you helping a newb out.
Regards,
Rob
On Fri, Dec 1, 2017 at 4:21 PM, Nuno Cruz<EMAIL_ADDRESS>wrote:

Sorry, I didn't saw that was a compilation error. You should install
bootstrap typings. Npm install @types/bootstrap (something like this)
Em 01/12/2017 20:32, "robscottnh"<EMAIL_ADDRESS>escreveu:

Can anyone point me to a Typescript version of this? I'm sure I'm making
a
simple mistake, but I'm new to this. The compilation error is : Property
'tooltip' does not exist on type 'JQuery'.
The code looks like:
'''
import { customAttribute, inject } from "aurelia-framework";
import "jquery";
import "bootstrap";
@Inject https://github.com/inject(Element)
export class BootstrapTooltipCustomAttribute
{
constructor(element:any)
{
this.element = element;
}
bind()
{
$(this.element).tooltip();
}
unbind()
{
$(this.element).tooltip("destroy");
}
element:any;
}
'''
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<https://github.com/aurelia/templating/issues/233#issuecomment-348607094
,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/
AA5o5Vu93Iqc0Q8bovZE1Ij7TeugPfdQks5s8GJNgaJpZM4G2JBK>
.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/aurelia/templating/issues/233#issuecomment-348617355,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABxNKmHJ_rmyKyANJTN_tQpPFrSFCLy3ks5s8G3FgaJpZM4G2JBK
.


add claude 3.5 sonnet support to Bedrock InvokeAPI

Description
Please include a summary of the change and which issue is fixed. Please also include relevant motivation and context. List any dependencies that are required for this change.
Version Bump?
Did I bump the version in the pyproject.toml file of the package I am updating? (Except for the llama-index-core package)
Yes (0.1.10 -> 0.1.11)
Type of Change
Please delete options that are not relevant.
New feature (non-breaking change which adds functionality)
How Has This Been Tested?
I tested on my local environment.
Suggested Checklist:
I have performed a self-review of my own code
New and existing unit tests pass locally with my changes (There are 2 failed tests regardless of my changes. I test it before and after my changes, nothing different)
I ran make format; make lint to appease the lint gods

Hey @logan-markewich and @kamilmuratyilmaz! Thank you for your work, but I believe there is a small bug.
There is a missing comma, that prevents the usage of streaming for haiku and sonnet3.5 models:
from llama_index.llms.bedrock.utils import STREAMING_MODELS
STREAMING_MODELS
{'amazon.titan-text-express-v1',
'amazon.titan-tg1-large',
'anthropic.claude-3-5-sonnet-20240620-v1:0anthropic.claude-3-haiku-20240307-v1:0',
'anthropic.claude-3-opus-20240229-v1:0',
'anthropic.claude-3-sonnet-20240229-v1:0',
'anthropic.claude-instant-v1',
'anthropic.claude-v1',
'anthropic.claude-v2',
'anthropic.claude-v2:1',
'meta.llama2-13b-chat-v1',
'mistral.mistral-7b-instruct-v0:2',
'mistral.mistral-large-2402-v1:0',
'mistral.mixtral-8x7b-instruct-v0:1'}
ValueError: Model anthropic.claude-3-5-sonnet-20240620-v1:0 does not support streaming

You were right. I applied the fix by adding the comma. Just opened a PR.


IntanIO problem with one file per stream format

Which page is the problem on?
IntanIO
What is the problem?
IntanIO reads problematic. The function works well with rhd files but is problematic with dat files. Here are the pictures of the result.

When reading .dat file from numpy directly(Fig 1), everything goes well. But the IntanIO seems wrongly loaded data. I doubt whether the data type is causing this problem. [.rhd, uint16; .dat, int16].
Suggestions for fixing the problem
Could you please provide more information about reading .dat files?

That looks like a scaling error. I'll look into this later today. Which version one file-per channel or one file per stream?

The simulated data were generated using Intan version 3.3.1.
Here is the code:
from neo import io
data_rhd = io.IntanIO(r'F:\MATLAB\RHD_test\RHD_test.rhd')
raw_chunk_rhd = data_rhd.get_analogsignal_chunk(block_index=0,
                                      stream_index=0,
                                      seg_index=0)

rhd = data_rhd.rescale_signal_raw_to_float(raw_chunk_rhd, stream_index=0)
plt.plot(rhd[:,3])

data_dat = io.IntanIO(r'F:\MATLAB\DAT_test\info.rhd')
raw_chunk_dat = data_dat.get_analogsignal_chunk(block_index=0,
                                      stream_index=0,
                                      seg_index=0)
dat= data_dat.rescale_signal_raw_to_float(raw_chunk_dat, stream_index=0)
plt.plot(dat[:,3])

The scale is correct but not the wavefoms with .dat files.

The simulated data were generated using Intan version 3.3.1.
Here is the code:
import os
from neo import io
import matplotlib.pyplot as plt

# Load rhd file
data_rhd = io.IntanIO(r'F:\MATLAB\RHD_test\RHD_test.rhd')
raw_chunk_rhd = data_rhd.get_analogsignal_chunk(block_index=0,
                                      stream_index=0,
                                      seg_index=0)

rhd = data_rhd.rescale_signal_raw_to_float(raw_chunk_rhd, stream_index=0)
plt.plot(rhd[:,3])

#Load dat file
data_dat = io.IntanIO(r'F:\MATLAB\DAT_test\info.rhd')
raw_chunk_dat = data_dat.get_analogsignal_chunk(block_index=0,
                                      stream_index=0,
                                      seg_index=0)
dat= data_dat.rescale_signal_raw_to_float(raw_chunk_dat, stream_index=0)
plt.plot(dat[:,3])

#Load from numpy
def load_dat(filename, num_channels):
	fileinfo = os.stat(filename)
	num_samples = fileinfo.st_size // (num_channels * 2)

	with open(filename, 'rb') as f:
		v = np.fromfile(f, dtype=np.int16, count=num_channels * num_samples)
		v = v.reshape((num_samples, num_channels)).T
	v = v * 0.195
	return v
data_wiht_numpy = load_dat(r'F:\MATLAB\DAT_test\amplifier.dat', 64)
plt.plot(data_wiht_numpy[3])

The scale is correct but not the wavefoms with .dat files.

Linked a PR that should fix it!

Great！
Everything is going well. I revised the intanrawio script as you showed.


Update GNO and OWL logos

Please update GNO and OWL token logos to the new ones:
Files can be found here: https://drive.google.com/drive/folders/1FIZNqA_kPDx5UB0mqGzKpKF3M22AIgat

@mikheevm Updated


Update georss_client to 0.4

Description:
Update georss_client to version 0.4 which loosens its own third-party dependencies, trying not to interfere with Home Assistant's own dependencies.
Related issue (if applicable): n/a
Pull request in home-assistant.io with documentation (if applicable): n/a
Example entry for configuration.yaml (if applicable): n/a
Checklist:

[x] The code change is tested and works locally.
[x] Local tests pass with tox. Your PR cannot be merged unless tests pass

If the code communicates with devices, web services, or third-party tools:

[x] New dependencies have been added to the REQUIREMENTS variable (example).
[x] New dependencies are only imported inside functions that use them (example).
[x] New or updated dependencies have been added to requirements_all.txt by running script/gen_requirements_all.py.

You can push updates to the same branch. Add an additional commit then it would be part of #18088.

Sure, no problem. I've merged the two PRs now, and will close this one.


Add option to support forcing tox failure when Poetry is not available

Improving support for the mitigation of #2 mentioned in #30

@johnthagen The changes made here may help to better support the problem you highlighted here. If you update to 0.6 and don't install the poetry extra when installing this plugin then you should avoid the poetry-uninstalling-itself problem. More docs on this feature are here.

@enpaul Sounds great, thanks!


Add the ability to limit the number of concurrent requests

Description
Add the ability to limit the number of concurrent requests handled by the server.
Related issues
Addresses [issue #1065 ].
Testing
Added unit tests.

Not sure the use case for this, but we might want to call out either in the error message or the configuration that this is a per-instance limit. If you scale the service out to n instances you're going to have n*limit available requests if your distribution is perfect.

What's the use case of this feature? And how are we going to decide value for  ConcurrentRequestLimit config?

This looks good overall. My only (nit picky) comment would be about naming. This is actually not about throttling (reduce throughput) overall. The goal is to limit the number of concurrent requests to increase overall throughput by avoiding pathological behavior when the service gets overwhelmed. Throttling (as in max number of requests per some period of time) is maybe a bit different.


reworded link from 'View a list of suppliers'

to 'Download list of suppliers'

Makes sense :+1: when/if Travis goes green.


MBBSEmu- command line help should include -console option

Describe the bug
Running MBBSEmu with incorrect or no arguments prints the help file. Help is missing the -console option and description.
Expected behavior
The help output should include a description of the -console option.

Closed with #83


Column size not getting adjusted during data overflow

Please suggest me how to use mui-datatables to make columns to adjust the size as per the data.
Below is a sample picture of the overflow data:

These are my table and column options:

this.options = {
      filter: true,
      filterType: "textField",
      print: false,
      downloadOptions:  {filename: 'test.csv', separator: ','},
      draggableColumns: {enabled:true},
      fixedHeader: true,
      resizableColumns: true,
      // responsive: "auto",
      rowsPerPageOptions: [2,5,10,20],
      searchPlaceholder: "Quick Search",
      searchOpen: true,
      customToolbar: () => {
        return (
          <TableDefaultTools addNewRecord={this.props.addNewRecord}/>
        );
      },
      customToolbarSelect: () => {
        return (
          <TableOnSelectTools addNewRecord={this.props.addNewRecord}/>
        );
      }
    };

Start Date & Time column options:

options: {
      sortThirdClickReset: true,
      customBodyRender: (value, tableMeta, updateValue) => (
        <DateTimePickerView/>
        )
    }

DateTimePickerView:

import React from "react";
import DateTimePicker from 'react-datetime-picker';

class DateTimePickerView extends React.Component {
  state = {
    selectedDate: new Date()
  };

  handleChange = date => {
    this.setState({
      selectedDate: date
    });
  };

  render() {
    return (
        <DateTimePicker
          onChange={this.handleChange}
          value={this.state.selectedDate}
        />
    );
  }
}

export default  DateTimePickerView;

Look at the setCellProps column option. You'll want to add something that looks like this:
let columns = [
    {
        name: 'data',
        options: {
            setCellProps: () => ({style: {whiteSpace:'nowrap'}})
        }
    }
];

That will keep the table cells from overlapping, though it will add a vertical scollbar to the table (you can't really avoid that if your data is being bunched up).

@patorjk Your solution has worked for me. Thanks.


Exit code is zero when parsing fails

Detailed Description

I would like to use swagger2openapi for validation of my OpenAPI 3 yaml files in our build process.  When I run it on an invalid input file I get the expected error message on STDERR, but the exit code is zero.  It would be much easier to detect invalid files if the exit code was non-zero.
bash-3.2$ swagger2openapi swagger.yaml
(node:13188) UnhandledPromiseRejectionWarning: Unhandled promise rejection (rejection id: 2): Error: (Patchable) info object is mandatory
(node:13188) [DEP0018] DeprecationWarning: Unhandled promise rejections are deprecated. In the future, promise rejections that are not handled will terminate the Node.js process with a non-zero exit code.
bash-3.2$ echo $?
0

(Also the actual error message is buried in the UnhandledPromiseRejectionWarning which isn't ideal.  It would be nice to get rid of those unhandled promise warnings.)
Other stuff

I found the tool while looking for a good way to convert our Swagger 2.0 files to OpenAPI 3.  The awesome-openapi3 list helped.
Thanks.

Thanks for the report, will take a look at both issues.

Can I check which version you're running?
It looks like that got fixed in commit 72bd25bb - which is included in v2.11.13
node swagger2openapi.js test/\!missing-info/swagger.yaml && echo ok
Error: (Patchable) info object is mandatory
    at fixInfo (/home/mike/nodejs/swagger2openapi/index.js:1129:27)
    at /home/mike/nodejs/swagger2openapi/index.js:1313:9
    at new Promise (<anonymous>)
    at convertObj (/home/mike/nodejs/swagger2openapi/index.js:1198:28)
    at /home/mike/nodejs/swagger2openapi/index.js:1376:13
    at new Promise (<anonymous>)
    at convertStr (/home/mike/nodejs/swagger2openapi/index.js:1362:28)
    at /home/mike/nodejs/swagger2openapi/index.js:1415:17
    at FSReqWrap.readFileAfterClose [as oncomplete] (fs.js:511:3)

You might get clearer output from using testRunner -n in your CI process, and this has the benefit that it actually runs the validator on the converted output:
node testRunner.js -v -n swagger.yaml && echo ok
Gathering...
Error: (Patchable) info object is mandatory

Failures:
Converter failed swagger.yaml

Tests: 0 passing, 1 failing, 0 warnings

In both cases above ok is not echoed, as the exit code is non-zero.

Fantastic!  All I needed was an update.  :)
I also really appreciate the advice about the testRunner.  And most of all, thank you for the quick response!  I'm about to modify a bunch of services and I'm very, very happy to know this before I start.  🙇

No problem, please let me know if you hit any other issues.


ANSI colors are wrong

@ccbrown
First off, amazing library. I was a giant Ink fan (https://boostlib.dev/docs/cli) so am really excited for this.
I noticed that Color::AnsiValue renders the wrong colors. If I render 147, which should be a lavender/purple color, it actually renders yellow in the terminal. I tried a few other colors, and they were all wrong.

Edit: nevermind, spoke to soon. I had some custom enums that would be casted using as u8 but my indices were off.


extract method does not work with '#' since v6.5

Hi!
I am trying to update the library from v6.2 and I have found an issue since v6.5. The extract method returns an empty string when I pass a value with a #. For example

extract('https://wwww.domain.com#hello?param=1'); // returns ''
extract('#hello?param=1'); // returns '';

I think the problem is in the function "removeHash", introduced in the v6.5. This function removes all the string that is after the #. I wrote this simple fiddle with an example: https://jsfiddle.net/5Ljnwc07/
Do you think it's a bug? Or I am doing something wrong?
Thank you!

// @ChrisCindy

It seems that this is the intended behaviour:
https://github.com/sindresorhus/query-string/blob/a1d108fe41ac34ca574d5e00823d0e4562c9d8be/test/extract.js#L8

Additional potential support that this is intended behavior: see this stackoverflow answer(which references to RFC 3986). Percent encoding can escape the #, if that is something you have control over.

Closing as this is working as intended.