Classes of same interface type with different rules - cast error

Hi,
I have one scenario and i don't know how to handle it.
I have one class with a collection property:
RuleFor(o => o.MyCollection).SetCollectionValidator(new MyCollectionValidator());
In MyCollectionValidator: AbstractValidator<ElementOfCollection>
I have one property of type MyInterface (MyInterfaceProperty),
This property can be in some elements of MyCollection of type Class1 and in other cases of type Class2.
I want something like this:
 When(o => o.MyInterfaceProperty is Class1, () =>
            {
                RuleFor(o => (Class1)o.MyInterfaceProperty).SetValidator(new Class1Validator());
            });

            When(o => o.MyInterfaceProperty is Class2, () =>
            {
                RuleFor(o => (Class2)o.MyInterfaceProperty).SetValidator(new Class2Validator());
            });

But when i try to validate i get InvalidCastException.

Hi,
This approach won't work. Calls to RuleFor are always invoked immediately - they are not lazily evaluated when inside a When block, so the cast will be happening every time which is why you're getting an InvalidCastException.
You have two options. The simplest is to use the as operator to do a safe cast and get rid of the When block:
RuleFor(x => x.MyInterfaceProperty as Class2).When(prop => prop != null).SetValidator(new Class2Validator()).OverridePropertyName("MyInterfaceProperty");

This is the easiest way to do this, but has a performance implication as it will bypass the expression tree cache, so the expression will be compiled in every instantiation of the validator (only simple property expressions are cached).
An alternative approach is to write a custom PropertyValidator implementation that can handle the polymorphism and will internally select whether or not to use the Class1Validator or the Class2Validator. This issue has an example of how to do this: https://github.com/JeremySkinner/FluentValidation/issues/111 In that post, the user was trying to handle validating polymorphic elements in a collection, which is not the same as what you're trying to achieve, but the approach would be very similar.

It works,
Thanks!


chore(appveyor): fix builds

Signed-off-by: Juan Cruz Viotti<EMAIL_ADDRESS>

Closed in favor of https://github.com/resin-io/etcher/pull/503


Fix: Composer does not refocus on clicking the same chat in LHN

Details

Composer does not refocus on clicking the same chat in LHN.
Fixed Issues

$ https://github.com/Expensify/App/issues/20865
PROPOSAL: https://github.com/Expensify/App/issues/20865#issuecomment-1596492042
Tests

Login with any account
Open any chat
Verify that the composer is focused
Click on the same chat in LHN
Verify that the composer does not lose focus

[x] Verify that no errors appear in the JS console

Offline tests

NA
QA Steps

Login with any account
Open any chat
Verify that the composer is focused
Click on the same chat in LHN
Verify that the composer does not lose focus

[ ] Verify that no errors appear in the JS console

PR Author Checklist

[x] I linked the correct issue in the ### Fixed Issues section above
[x] I wrote clear testing steps that cover the changes made in this PR

[x] I added steps for local testing in the Tests section
[x] I added steps for the expected offline behavior in the Offline steps section
[x] I added steps for Staging and/or Production testing in the QA steps section
[x] I added steps to cover failure scenarios (i.e. verify an input displays the correct error message if the entered data is not correct)
[x] I turned off my network connection and tested it while offline to ensure it matches the expected behavior (i.e. verify the default avatar icon is displayed if app is offline)
[x] I tested this PR with a High Traffic account against the staging or production API to ensure there are no regressions (e.g. long loading states that impact usability).

[x] I included screenshots or videos for tests on all platforms
[x] I ran the tests on all platforms & verified they passed on:

[x] Android / native
[x] Android / Chrome
[x] iOS / native
[x] iOS / Safari
[x] MacOS / Chrome / Safari
[x] MacOS / Desktop

[x] I verified there are no console errors (if there's a console error not related to the PR, report it or open an issue for it to be fixed)
[x] I followed proper code patterns (see Reviewing the code)

[x] I verified that any callback methods that were added or modified are named for what the method does and never what callback they handle (i.e. toggleReport and not onIconClick)
[x] I verified that the left part of a conditional rendering a React component is a boolean and NOT a string, e.g. myBool && <MyComponent />.
[x] I verified that comments were added to code that is not self explanatory
[x] I verified that any new or modified comments were clear, correct English, and explained "why" the code was doing something instead of only explaining "what" the code was doing.
[x] I verified any copy / text shown in the product is localized by adding it to src/languages/* files and using the translation method

[x] If any non-english text was added/modified, I verified the translation was requested/reviewed in #expensify-open-source and it was approved by an internal Expensify engineer. Link to Slack message:

[x] I verified all numbers, amounts, dates and phone numbers shown in the product are using the localization methods
[x] I verified any copy / text that was added to the app is grammatically correct in English. It adheres to proper capitalization guidelines (note: only the first word of header/labels should be capitalized), and is approved by marketing by adding the Waiting for Copy label for a copy review on the original GH to get the correct copy.
[x] I verified proper file naming conventions were followed for any new files or renamed files. All non-platform specific files are named after what they export and are not named "index.js". All platform-specific files are named for the platform the code supports as outlined in the README.
[x] I verified the JSDocs style guidelines (in STYLE.md) were followed

[x] If a new code pattern is added I verified it was agreed to be used by multiple Expensify engineers
[x] I followed the guidelines as stated in the Review Guidelines
[x] I tested other components that can be impacted by my changes (i.e. if the PR modifies a shared library or component like Avatar, I verified the components using Avatar are working as expected)
[x] I verified all code is DRY (the PR doesn't include any logic written more than once, with the exception of tests)
[x] I verified any variables that can be defined as constants (ie. in CONST.js or at the top of the file that uses the constant) are defined as such
[x] I verified that if a function's arguments changed that all usages have also been updated correctly
[x] If a new component is created I verified that:

[x] A similar component doesn't exist in the codebase
[x] All props are defined accurately and each prop has a /** comment above it */
[x] The file is named correctly
[x] The component has a clear name that is non-ambiguous and the purpose of the component can be inferred from the name alone
[x] The only data being stored in the state is data necessary for rendering and nothing else
[x] If we are not using the full Onyx data that we loaded, I've added the proper selector in order to ensure the component only re-renders when the data it is using changes
[x] For Class Components, any internal methods passed to components event handlers are bound to this properly so there are no scoping issues (i.e. for onClick={this.submit} the method this.submit should be bound to this in the constructor)
[x] Any internal methods bound to this are necessary to be bound (i.e. avoid this.submit = this.submit.bind(this); if this.submit is never passed to a component event handler like onClick)
[x] All JSX used for rendering exists in the render method
[x] The component has the minimum amount of code necessary for its purpose, and it is broken down into smaller components in order to separate concerns and functions

[x] If any new file was added I verified that:

[x] The file has a description of what it does and/or why is needed at the top of the file if the code is not self explanatory

[x] If a new CSS style is added I verified that:

[x] A similar style doesn't already exist
[x] The style can't be created with an existing StyleUtils function (i.e. StyleUtils.getBackgroundAndBorderStyle(themeColors.componentBG))

[x] If the PR modifies code that runs when editing or sending messages, I tested and verified there is no unexpected behavior for all supported markdown - URLs, single line code, code blocks, quotes, headings, bold, strikethrough, and italic.
[x] If the PR modifies a generic component, I tested and verified that those changes do not break usages of that component in the rest of the App (i.e. if a shared library or component like Avatar is modified, I verified that Avatar is working as expected in all cases)
[x] If the PR modifies a component related to any of the existing Storybook stories, I tested and verified all stories for that component are still working as expected.
[x] If a new page is added, I verified it's using the ScrollView component to make it scrollable when more elements are added to the page.
[x] If the main branch was merged into this PR after a review, I tested again and verified the outcome was still expected according to the Test steps.
[x] I have checked off every checkbox in the PR author checklist, including those that don't apply to this PR.

Screenshots/Videos

Web

Screencast from 11-07-2023 00:23:22.webm

Mobile Web - Chrome

https://github.com/Expensify/App/assets/113963320/af542a22-11f0-4af3-aee3-80b368d10906

Mobile Web - Safari

https://github.com/Expensify/App/assets/113963320/aea38e15-6aee-4f07-8f40-929951f671c8

Desktop

https://github.com/Expensify/App/assets/113963320/6af64d02-f642-4b38-b396-1aa6a06dabc4

iOS
https://github.com/Expensify/App/assets/113963320/3f71eeb8-a7b7-4847-be70-879f2cb46977

Android

Screencast from 10-07-2023 08:45:35.webm

@tienifr Avoid creating PRs before you are assigned to the issue. This would lead to unnecessary confusion and it's against guidelines.
Please update the recordings after merging the latest main

Switching to other chats the focus is lost on composer, Can you please check @tienifr ?
https://github.com/Expensify/App/assets/85645967/df1a90e2-cb53-4e9e-98b9-cac81edc7a0d

@tienifr Try merging with the main

So this PR becomes invalid if that's the new expectation

@tienifr Did you find where(PR or issue) that change was made?

I'm confused why you brought up this.
On Staging/Main we no longer focus the composer even when switching to different chats refer to the video here.  I've asked if can you find the PR/Issue where this change was made.

Sorry as you can see it was not working for me here.
It was confusing for me as well. It's working now, will try testing again with your changes and let you know!

Reviewer Checklist

[x] I have verified the author checklist is complete (all boxes are checked off).
[x] I verified the correct issue is linked in the ### Fixed Issues section above
[x] I verified testing steps are clear and they cover the changes made in this PR

[ ] I verified the steps for local testing are in the Tests section
[x] I verified the steps for Staging and/or Production testing are in the QA steps section
[x] I verified the steps cover any possible failure scenarios (i.e. verify an input displays the correct error message if the entered data is not correct)
[x] I turned off my network connection and tested it while offline to ensure it matches the expected behavior (i.e. verify the default avatar icon is displayed if app is offline)

[x] I checked that screenshots or videos are included for tests on all platforms
[x] I included screenshots or videos for tests on all platforms
[x] I verified tests pass on all platforms & I tested again on:

[x] Android / native
[x] Android / Chrome
[x] iOS / native
[x] iOS / Safari
[x] MacOS / Chrome / Safari
[x] MacOS / Desktop

[x] If there are any errors in the console that are unrelated to this PR, I either fixed them (preferred) or linked to where I reported them in Slack
[x] I verified proper code patterns were followed (see Reviewing the code)

[x] I verified that any callback methods that were added or modified are named for what the method does and never what callback they handle (i.e. toggleReport and not onIconClick).
[x] I verified that the left part of a conditional rendering a React component is a boolean and NOT a string, e.g. myBool && <MyComponent />.
[x] I verified that comments were added to code that is not self explanatory
[x] I verified that any new or modified comments were clear, correct English, and explained "why" the code was doing something instead of only explaining "what" the code was doing.
[x] I verified any copy / text shown in the product is localized by adding it to src/languages/* files and using the translation method
[x] I verified all numbers, amounts, dates and phone numbers shown in the product are using the localization methods
[x] I verified any copy / text that was added to the app is grammatically correct in English. It adheres to proper capitalization guidelines (note: only the first word of header/labels should be capitalized), and is approved by marketing by adding the Waiting for Copy label for a copy review on the original GH to get the correct copy.
[x] I verified proper file naming conventions were followed for any new files or renamed files. All non-platform specific files are named after what they export and are not named "index.js". All platform-specific files are named for the platform the code supports as outlined in the README.
[x] I verified the JSDocs style guidelines (in STYLE.md) were followed

[x] If a new code pattern is added I verified it was agreed to be used by multiple Expensify engineers
[x] I verified that this PR follows the guidelines as stated in the Review Guidelines
[x] I verified other components that can be impacted by these changes have been tested, and I retested again (i.e. if the PR modifies a shared library or component like Avatar, I verified the components using Avatar have been tested & I retested again)
[x] I verified all code is DRY (the PR doesn't include any logic written more than once, with the exception of tests)
[x] I verified any variables that can be defined as constants (ie. in CONST.js or at the top of the file that uses the constant) are defined as such
[x] If a new component is created I verified that:

[x] A similar component doesn't exist in the codebase
[x] All props are defined accurately and each prop has a /** comment above it */
[x] The file is named correctly
[x] The component has a clear name that is non-ambiguous and the purpose of the component can be inferred from the name alone
[x] The only data being stored in the state is data necessary for rendering and nothing else
[x] For Class Components, any internal methods passed to components event handlers are bound to this properly so there are no scoping issues (i.e. for onClick={this.submit} the method this.submit should be bound to this in the constructor)
[x] Any internal methods bound to this are necessary to be bound (i.e. avoid this.submit = this.submit.bind(this); if this.submit is never passed to a component event handler like onClick)
[x] All JSX used for rendering exists in the render method
[x] The component has the minimum amount of code necessary for its purpose, and it is broken down into smaller components in order to separate concerns and functions

[x] If any new file was added I verified that:

[x] The file has a description of what it does and/or why is needed at the top of the file if the code is not self explanatory

[x] If a new CSS style is added I verified that:

[x] A similar style doesn't already exist
[x] The style can't be created with an existing StyleUtils function (i.e. StyleUtils.getBackgroundAndBorderStyle(themeColors.componentBG)

[x] If the PR modifies code that runs when editing or sending messages, I tested and verified there is no unexpected behavior for all supported markdown - URLs, single line code, code blocks, quotes, headings, bold, strikethrough, and italic.
[x] If the PR modifies a generic component, I tested and verified that those changes do not break usages of that component in the rest of the App (i.e. if a shared library or component like Avatar is modified, I verified that Avatar is working as expected in all cases)
[x] If the PR modifies a component related to any of the existing Storybook stories, I tested and verified all stories for that component are still working as expected.
[x] If a new page is added, I verified it's using the ScrollView component to make it scrollable when more elements are added to the page.
[x] If the main branch was merged into this PR after a review, I tested again and verified the outcome was still expected according to the Test steps.
[ ] I have checked off every checkbox in the PR reviewer checklist, including those that don't apply to this PR.

Screenshots/Videos

Web & Desktop
https://github.com/Expensify/App/assets/85645967/8ff685c8-c58a-47b6-8a13-28b32d0f7653

Mobile All
https://github.com/Expensify/App/assets/85645967/6683af96-7f91-4c96-90f5-bac9f38d2045

@tienifr The test steps don't work as expected for mobile native/web. That's irrelevant here so better update the test steps to test only focus issue on Desktop App &  Desktop Web only.

@tienifr bump!

🚀 Deployed to staging by https://github.com/MonilBhavsar in version: 1.3.42-0 🚀

platform
result

🤖 android 🤖
cancelled 🔪

🖥 desktop 🖥
cancelled 🔪

🍎 iOS 🍎
cancelled 🔪

🕸 web 🕸
cancelled 🔪


Incremental feature from a new log

Hi,
I would like to suggest a feature..
A incremental feature.
Say you have a cron job running goaccess for yesterdays log every day.
How about combining multiple old reports into one big report without the original access log?
i.e. you output a goaccess cvs or whatever format, then ask goaccess to combine them to get like full week or month reports.

Currently, using the on-disk storage, it is possible to have persisted data loaded into a report (without the original access log), however, the incremental part only works if new data is appended to the new access log.
You can use this by configuring goaccess as ./configure --enable-tcb=btree and then use a combination of --keep-db-files and --load-from-disk.
I can add the incremental part when loading the new log. Thanks

I'm using the deb packages provided by goaccess.io. It's not built with btree..
# goaccess -s
Built using GLib On-Memory Hash database.

For data persistence, you will need to compile goaccess and use --enable-tcb=btree

Added the ability to process logs incrementally.
That is, it will combine previously persisted data with a new data set. This is how it works:
If a data set is persisted with --keep-db-files, then using --load-from-disk will load the original data set. If new data is passed (piped or through a log file), it will append it to the original data set.
Note: To preserve the data at all times, --keep-db-files must be used. If --load-from-disk is used without --keep-db-files, database files will be deleted upon closing the program.
e.g.,
// last month access log
goaccess -f access.log.1 --keep-db-files

then
// current access log
goaccess -f access.log --load-from-disk --keep-db-files

To read persisted data only (without parsing new data)
goaccess --load-from-disk --keep-db-files

Feel free to build from dev, otherwise, it will be pushed out in the upcoming version.

cool, will test this new feature.
thanks


Typecheck with Interfaces

Suggestion

🔍 Search Terms

is, interface type, is not.
✅ Viability Checklist
My suggestion meets these guidelines:

[X] This wouldn't be a breaking change in existing TypeScript/JavaScript code
[X] This wouldn't change the runtime behavior of existing JavaScript code
[X] This could be implemented without emitting different JS based on the types of the expressions
[X] This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, new syntax sugar for JS, etc.)
[X] This feature would agree with the rest of TypeScript's Design Goals.

⭐ Suggestion

Being able to do type check just like instanceof Class for interfaces.
📃 Motivating Example

interface Person{
   name: string;
   age: number;

  // Validate here and return boolean
  *is(target) {
     return "name" in target && typeof target.name === "string" && "age" in target && typeof target.age === "number";
  }
}

// Use
const data = await http.get("url");

if (data is Person) {
  // data is typed as Person here
  person.name // string
}

// and maybe
if (data is not Person){
 // just like C# does, it can be a shortcut and a more declarative way of doing if(!(data is Person))
}

💻 Use Cases

I think it is a cool feature that many languages have, some of them do it in a different way such as using classes, but in Javascript/Typescript, we often use objects. With this approach, some libraries also can add a way to check their interfaces.
It has a similar way in Typescript, too. Such as const isPerson = (target: any): target is User => /* operation here */, but using it in interface might be a more readable way, especially in if condition.

[x] This could be implemented without emitting different JS based on the types of the expressions

You want to emit different JS based on the type.

[x] This could be implemented without emitting different JS based on the types of the expressions

You want to emit different JS based on the type.
Your suggestion would also be against the design goal 8:

Avoid adding expression-level syntax.

I didn't know that, sadly. Okay, I am going to close this, thanks.


IfcFinder specifying the property name in IfcPropertyRule doesn't yield results

Describe the bug 📝
I'm using the IfcFinder to get the Reference property with value starting with Por on the small.ifc example file as shows the image below.

When specifying the property name, IfcFinder returns an empty result which shouldn't be correct as there are elements with property Reference starting with Por.

However whenever I don't specify the property name, IfcFinder returns the correct results.

Reproduction ▶
No response
Steps to reproduce 🔢
No response
System Info 💻
System:
    OS: Windows 11 10.0.22631
    CPU: (16) x64 11th Gen Intel(R) Core(TM) i7-11700F @ 2.50GHz
    Memory: 8.91 GB / 23.86 GB
  Binaries:
    Node: 20.11.1 - C:\Program Files\nodejs\node.EXE
    Yarn: 1.22.22 - C:\Program Files\nodejs\yarn.CMD
    npm: 10.8.2 - C:\Program Files\nodejs\npm.CMD
  Browsers:
    Edge: Chromium (127.0.2651.74)
    Internet Explorer: 11.0.22621.3527

Used Package Manager 📦
npm
Error Trace/Logs 📃
No response
Validations ✅

[X] Read the docs.
[X] Check that there isn't already an issue that reports the same bug to avoid creating a duplicate.
[X] Make sure this is a repository issue and not a framework-specific issue. For example, if it's a THREE.js related bug, it should likely be reported to mrdoob/threejs instead.
[X] Check that this is a concrete bug. For Q&A join our Community.
[X] The provided reproduction is a minimal reproducible example of the bug.

Hey @atefMck that happens because “name” refers to the name of the attribute of the IfcPropertySingleValue. In other words, that property single value looks like this:
{
  Name: "Referencia",
  NominalValue: "Por defecto - 30cm",
  ...
}

So as you can see, Referencia is actually not a name, but a value whose name is Name. You probably want something like this:
    const propertyRule2: TOC.IfcPropertyRule = {
      type: "property",
      name: /Name/gm,
      value: /Referencia/gm
    };

    const propertyRule1: TOC.IfcPropertyRule = {
      type: "property",
      name: /NominalValue/gm,
      value: /Por.*/gm
    };


Use dpkg-deb directly rather than regex

This is based on @kwilczynski's work in #2434

ping @chef/client-core

yeah that looks fine to me.
you're updating the @new_resource which should be avoided but you're just preserving the behavior of the old code.  it could probably use a #FIXME above it if you don't have time to actually fix it now, those are kind of bad bugs which are often exposed by resource cloning in horrible ways.

@lamont-granquist i updated to not hit new_resource

if that works, its better, not sure what that code was doing or if you're gonna hit an edge case....

:+1:

:+1:


Groups in Hub

Support organizations in Hub, similar to Guesstimate.
### Tasks
- [ ] Create an org
- [ ] Org page, similar to user page
- [ ] Invite users to an org (inviting Hub users is enough, but email invites are also nice)
- [ ] Email when invited
- [ ] Accepting org invites
- [ ] Remove users from an org
- [ ] Org roles (admin/member, only admins can remove other users)
- [ ] Create model belonging to an org, with proper permissions

I'm thinking that "groups" might be a better name.
While "organizations" is used for this on GitHub (and on Guesstimate), it's kinda long. It also feels too much like a big decision: we're probably going to use this feature a lot for organizing models into collections, and Squiggle models are usually smaller than GitHub repos, so this will happen more frequently on Squiggle Hub than on GitHub.
We could also go with "teams" or "communities", but that puts too much weight on the collaborative aspect, and I expect that many lists will be maintained by a single author, while "group" is more neutral.
Other related things to consider:

Redirects when a model is moved from a personal page to a group? I think this will happen quite a lot.
Do we want to list models authored by a user that belong to a group on that user's profile page? This might be useful. But then we need to track the model's primary ownership, or distinguish between "major contributions" and "minor contributions", or set this flag manually.

My guess is that we'll eventually want these to primarily be about the collaboration aspect (in which case, "teams" seems better), but for now, groups works.
Workspace is another potential name, but is obviously longer.
Also, see: https://manifold.markets/OzzieGooen/what-should-we-call-groupsteamsorga

Things to decide:

Are group pages public? On Guesstimate, they are (example), and I think it's ok to keep them public initially. We can add a flag to hide a group later.
What's the permission model for group memberships? For now, I'm going to implement two roles, Member and Admin, where only admins can add and remove new members and remove a group.
Are group memberships public? I think it's ok to have memberships public initially, and we can add isPublic flag that can be configured by group admins later (Github does this).
Can models be owned by a group? On Guesstimate, a model is owned by a user even if it belongs to an org. This is easier to implement, but I think it's a bad shortcut (what if the user left the organization?). Unfortunately, making Model.ownerId field polymorphic is more complicated, and will require a non-trivial database migration.

Are group pages public? -> Yes
What's the permission model for group memberships?  -> Members and Admins seem great. Guesstimate was simpler (just one admin), foretold allowed for multiple admins.
Good question. I'm fine with them being public, for now.
Group models should be editable/controllable by the group. I didn't realize that this specific thing was an issue with Guesstimate - that's good to flag. (There have likely been sitatuations, so far, where it has been suboptimal, if it's true). I think I agree with your intuitions here.


Add examples or high-level documentation for Monix/cats-based implementation.

I'm currently evaluating outwatch for a small project I'm planning. While initial experiments on an older version seemed really promising, I thought I'd give 1.0.0-RC2 a try, and some of my ideas don't really seem to be practical anymore with this version. Some small but complete examples would be helpful to figure out how to structure your app.
It would also help a lot if there was at least a high-level intro to some of the design choices.
I'm specifically curious why Handler.create[T] returns an IO. It's not really obvious to me what the side-effect that we're wrapping in the IO here is.
I'm particularly interested about this design change since it seems to make some of the design ideas I had less straight-forward.

Thanks for opening an issue. We are currently working on a changelog to better explain the changes and ideas behind it (https://github.com/OutWatch/outwatch/pull/167). I agree, examples are still missing.

I'm specifically curious why Handler.create[T] returns an IO. It's not really obvious to me what the side-effect that we're wrapping in the IO here is.

This is effectively a factory for an object that has sideeffecting functions like subscribe/onNext/onComplete, which is why it is modeled as an effect.
For IO, there is a work in progress to abstract over the cats.Effect type, which might be of interest: https://github.com/OutWatch/outwatch/pull/178. This also enables working with different effect types.

some of my ideas don't really seem to be practical anymore with this version

it seems to make some of the design ideas I had less straight-forward.

Which were your ideas? Can you show some code / design ideas you have?
We have to know what new users find unintuitive, so we can make it more clear or change the API.

Related: #75

@SergeantSod In case it helps, you can find here a complete example: https://github.com/mariusmuja/outwatch-extras/blob/master/demo-spa/src/main/scala/demo/DemoApp.scala
In most cases, the code remains almost the same compared to the non-referential transparent API, for example something like this:
 val names = createStringHandler()

val node = div(
input(placeholder := "Name", inputString --> names),
  hr(),
  h2("Hello ", child <-- names)
)

now becomes:
val node = Handler.create[String].flatMap { names =>
  div(
    input(placeholder := "Name", inputString --> names),
    hr(),
    h2("Hello ", child <-- names)
  )
}

As to why Handler.create[T] returns an IO look for example at line 210 in the example, where there's something like this:
tr(
  td(TodoModule(loggerSink, store.
  td(TodoModule(loggerSink, store.sink))
)

Another way to write it with the current API is:
val todoModule = TodoModule(loggerSink, store.sink)
tr(
  td(todoModule),
  td(todoModule)
)

and it works the same way. With the non-referential transparent API from before, it would display the two todo modules, but they would have the same handler internally, so adding something to one would have resulted in the item being added to both.

Thanks for the explanations so far. I think I'll have to peruse the example code @mariusmuja  pointed out a bit more to wrap my head around what it means for my use-case. What I wanted to achieve might already be available as outwatch-extras's Component.
This also touches on @fdietze's question about what I wanted to achieve. My ideas are pretty half-baked, so bear with me here:
I intended to add a thin layer of classes on top of outwatch's API, to allow me to separate views (mostly DOM elements and streams of events) from the other concerns (transformations, extracking data from the model, glue code etc.), which could be pushed into another class (for lack of a better words, let's call it a presenter). For this purpose I envisioned the view class exposing its events along the following lines:
class ExampleView{
  val clickStream = createInputHandler()

  def element ={
    div(
      "Look at my shiny dom",
      div("More dom",
         clicks --> clickStream
      )
    )
  }
}

The intention would be that the presenter would just grab an ExampleView's clickStream (and other event streams that are exposed the same way), map over it and pass the resulting stream off to somewhere else. If I extract some traits, I could even reuse different views with the same presenter and vice versa. I would still have to hide the fact that clickStream is also a sink (by narrowing the type) from the outside world, but the idea is the same.
I haven't really figured out how this would work if clickStream is an IO that will yield a new Handler each time it's mapped over. At least the naive approach like the following probably wouldn't work:
class ExampleView{
  val clickStream : IO[Handler] = Handler.create[MouseEvent]

 def element = {
    for {
       _clickSink <- clickStream
    } yield {
      div(
        "Look at my shiny dom",
        div("More dom",
           onClick --> _clickSink
        )
      )
    }

  }
}

AFAICS, that way, the presenter could map over clickStream again, but that would yield a fresh instance of Handler[MouseEvent], instead of the one that is connected to the DOM element's onClick.

Since I'm not so experienced with IO, I'm also interested in how to design such an architecture with IO. @LukaJCB @mariusmuja?


Why are the error rate accumulated?

❓ Questions & Help

Details
Each call of the error rate accumulates the distance and length. Why is that?Is it to have a running average kind of thing?
Why don't you just return the point-wise wer? @upskyy

@OleguerCanal  We did so because it's good to understand the tendency when it's accumulated as a whole. Is there a reason why you want to do point-wise wer?

This makes sense but if using wandb or tensorboard it can already be smoothed like this right?
I'm saying because I was training an architecture with a ctc head and an attn head and wanted to compare the wers of each one. Since I used the same instance of wer_estimator, the values got mixed without me knowing

Hi @OleguerCanal! Thank you for your good opinion!
I recycled the code that I made before, so I made it like this.
@upskyy As @OleguerCanal said, why don't we add a way to show the ER for each batch? Let's add this as an option.
--error_rate_logging: accumulate, batch like this?

I like this solution @sooftware ! :+1:

I think batch would be good as the default


Support for MS-DOS and Open Watcom

Hello,
I would like to request support for MS-DOS using the Open Watcom compiler.
Best regards.

Hello. Unfortunately, we're kinda a long way from supporting that platform because our asm-differ tool only supports certain architectures. Not to say it could never happen, but you'd need to first add support there.
Do you know of any decomp projects using this compiler / platform? I'd be curious what their workflow is and what kinds of tools they're using.

Hello,
Thank you for your fast and detailed answer.
I thought that the Godbolt decompiler was supporting Open Watcom, but upon inspection, this isn't the case.
The project https://github.com/dethrace-labs/dethrace is the only one I know that makes use of the Open Watcom compiler, but I can't say for sure that it's purely a decompilation project. It would be best to ask @dethrace-labs directly.
I'll keep an eye on that issue, in the meantime.

Not public, but I'm aware of a project to binary match the original Command and Conquer windows binaries that used watcom 10.5. Workflow is using custom scripts to dump asm from IDA. Its helped a lot by the fact so much of the original code was released open source as part of the Command and Conquer remaster release, but there are lots of undocumented changes in the code from the original and code for Sole Survivor was not released.

Done in #794


a2dp-sink APT-X ?

hello, working a2dp-sink APT-X ?
Available BT profiles:

a2dp-source Advanced Audio Source (APT-X, SBC)
a2dp-sink   Advanced Audio Sink (SBC)

root@raspberrypi:~# bluealsa -h
Usage:
bluealsa [OPTION]...
Options:
-h, --help            print this help and exit
-V, --version         print version and exit
-S, --syslog          send output to syslog
-i, --device=hciX     HCI device to use
-p, --profile=NAME    enable BT profile
--a2dp-force-mono     force monophonic sound
--a2dp-force-audio-cd force 44.1 kHz sampling
--a2dp-volume         control volume natively
Available BT profiles:

a2dp-source Advanced Audio Source (APT-X, SBC)
a2dp-sink   Advanced Audio Sink (SBC)
hfp-hf      Hands-Free (v1.7)
hfp-ag      Hands-Free Audio Gateway (v1.7)
hsp-hs      Headset (v1.2)
hsp-ag      Headset Audio Gateway (v1.2)

By default only output profiles are enabled, which includes A2DP Source and
HSP/HFP Audio Gateways. If one wants to enable other set of profiles, it is
required to explicitly specify all of them using -p NAME options.

raspberry pi zero w

hello, working a2dp-sink APT-X ?

No, APT-X Sink is not available right now. It will be supported in the future, though :)

hello, working a2dp-sink APT-X ?

No, APT-X Sink is not available right now. It will be supported in the future, though :)
What about LDAC? Is LDAC sink support also planned?

+1 Looking forward to this as well.

Looking forward to supports LDAC sink as well!
I test LDAC source is ok...
hh

I would really value aptX-HD support too.

The apt-X and apt-X HD sink (decoding) is available in the master brach since commit b11cff0c2fd436e64c98b77943bb20a2d3d0ea77 and LDAC decoding is available since commit d76252bc88f5a5ae26f679d1e45b32d205351e76.

The apt-X and apt-X HD sink (decoding) is available in the master brach since commit b11cff0c2fd436e64c98b77943bb20a2d3d0ea77 and LDAC decoding is available since commit d76252bc88f5a5ae26f679d1e45b32d205351e76.


Revisiting conditions for linting error

I have changed pylint's behavior so that it is more relaxed and does not get so much in our way, here are the changes:

Will only fail when we have accumulated enough conditions to be below a 9 rating.
Minimum number of methods per class is 1. The warning will just indicate when a class has no purpose. This still affects data classes, but it is a matter for another time.
Warnings do no longer get printed on console, instead, they are exported to a file called 'pylint.report.txt'. This is because pylint will only print on console when an error occurred.
Made pylint use 4 threads, should speed things up a bit.

@bregman-arie Sure, I will remove those related to the few methods error. Warnings in general still count for the score, so we should still keep an eye on the generated report and not let much get stacked.


InterfaceError if wait_ready sent immediately after send or receive_ack

I've been tinkering with the PN532 in this Grove NFC module in I2C configuration attached to a Raspberry Pi Pico. For me, calling process (e.g. pn532.process(&Request::GET_FIRMWARE_VERSION, 4, 100.millis())) consistently results in InterfaceError(Abort(1)) (which I believe is ABRT_7B_ADDR_NOACK from the RP2040 datasheet - no ack from address). After a bit of debugging, I've narrowed it down to the wait_ready calls happening too soon after send or receive_ack. If I delay the wait_ready by 1ms or simply retry wait_ready after the InterfaceError(Abort(1)), things seem to work as expected.
I'm pretty new to working with I2C, so it's not clear to me if that's something this library should handle/tolerate. I vaguely recall this PN532 C lib not giving me this trouble (though it was a while back with a different board). At quick glance, they seem to retry the wait for ack until timeout without any other error handling or early return conditions. If it makes sense to you to continue retrying on InterfaceError(_), I'd be willing to put together a PR.
I'm gonna switch to using the IRQ interface, as I suspect it will make this a non-issue, but I figured I'd at least point this out. I also have a different PN532 device I'll try soon.

As suspected, this is not an issue when using I2CInterfaceWithIrq.

Thanks for investigating this!

If it makes sense to you to continue retrying on InterfaceError(_), I'd be willing to put together a PR.

This might be a good way forward but before I'd like to better understand why the error occurs.
It would be interesting to know if this has something to do with the Grove NFC module, the RP2040 Hardware or the RP2040 software.
What baud rate is your I2C bus running at?
Do you have access to an oscilloscope or logic analyzer and would you be able to post the waveforms here?

I2C was at 400 KHz. I did also try 100KHz with the same result.
I don't have a scope, but I did just have a couple cheap logic analyzers arrive yesterday - I just need a bit of time to teach myself how to use them, but I'll post the waveforms once I figure it out.
I also have an ITEAD PN532 NFC module that I'll test on; I should be able to quickly swap that out tomorrow just to compare different PN532 modules on the same RP2040.

Fwiw, I changed some of the wiring connecting the PN532 module (previous wiring was a bit suspect), and now it only repros in --release mode, but I get the same behavior with both the the Grove - NFC and ITEAD PN532 modules.

Code snippet
Sends GET_FIRMWARE_VERSION twice. First with logic to retry on wait_ready errors, and then via process.
  info!("Sending GET_FIRMWARE_VERSION");
  if let Err(err) = pn532.send(&Request::GET_FIRMWARE_VERSION) {
      error!("Error sending GET_FIRMWARE_VERSION: {}", defmt::Debug2Format(&err));
  }

  info!("Wait Ready");
  for _ in 0..10 {
      match pn532.interface.wait_ready() {
          Poll::Ready(Ok(_)) => {
              info!("Receive ACK");
              let ack_res = pn532.receive_ack();
              info!("ACK Result: {}", defmt::Debug2Format(&ack_res));
              break;
          }
          Poll::Pending => {
              info!("Not ready to receive ack");
          }
          Poll::Ready(Err(err)) => {
              error!("Error waiting for ready: {}", defmt::Debug2Format(&err));
          }
      };
  }

  info!("Wait Ready");
  for _ in 0..10 {
      match pn532.interface.wait_ready() {
          Poll::Ready(Ok(_)) => {
              let result = pn532.receive_response(Request::GET_FIRMWARE_VERSION.command, 4);
              info!("GET_FIRMWARE_VERSION response: {:?}", defmt::Debug2Format(&result));
              break;
          }
          Poll::Pending => {
              info!("Not ready to receive ack");
              delay.delay_ms(1);
          }
          Poll::Ready(Err(err)) => {
              error!("Error waiting for ready: {}", defmt::Debug2Format(&err))
          }
      };
  }

  let result = pn532.process(&Request::GET_FIRMWARE_VERSION, 4, 200.millis());
  info!("GET_FIRMWARE_VERSION process: {:?}", defmt::Debug2Format(&result));

Output
Debug output
INFO  Sending GET_FIRMWARE_VERSION
INFO  Wait Ready
INFO  Receive ACK
INFO  ACK Result: Ok(())
INFO  Wait Ready
INFO  GET_FIRMWARE_VERSION response: "Ok([50, 1, 6, 7])"
INFO  GET_FIRMWARE_VERSION process: "Ok([50, 1, 6, 7])"

Release output
INFO  Sending GET_FIRMWARE_VERSION
INFO  Wait Ready
ERROR Error waiting for ready: Abort(1)
INFO  Receive ACK
INFO  ACK Result: Ok(())
INFO  Wait Ready
INFO  Not ready to receive ack
INFO  GET_FIRMWARE_VERSION response: "Ok([50, 1, 6, 7])"
INFO  GET_FIRMWARE_VERSION process: "Err(InterfaceError(Abort(1)))"

Next up is to figure out this logic analyzer. :smile:

Did you happen to find out more?

I have not. It's still on my to do list, but not very urgent, and I've yet to break in my logic analyzers.

I think I've figured it out: while waiting to be ready the PN532 doesn't at all answer to requests for its address. i2c.read() in wait_ready consequently returns an error and the whole thing stops. Adding let _ =  solves the issue for me. I'm quite new to rust so i don't really feel comfortable with submitting a patch but I'm happy to test....

I had a look at this with a logic analyzer.
The protocol looks like this:

send request
wait 1
read ack
wait 2
read response

If one sends a I2C message during "wait 1" and the PN532 is not ready it will not ACK the read request in Interface::wait_ready

Interestingly this is not the case for "wait 2", where things work as expected.
The way I see it this leaves us two options:

add a delay after "send request"
ignore I2C errors in Interface::wait_ready

I went with the second option in #14 but I'd be interested in what you think @anowell @sebarnd

As the device has already answered before I think ignoring protocol errors here shouldn't be too harmful. But taking also in account that the bus needs to be constantly polled by this approach it seems more elegant to have some delay there.

Those are some good points.
Running I2C at 400kHz there's up to 10 reads that fail before succeeding. This might be different for other commands than GET_FIRMWARE_VERSION.
I found this in the PN532 User Manual 6.2.4:

it may happen that the PN532 does not acknowledge its own address immediately after having finished a previous exchange.

Another thing to take into account is that a delay doesn't make much sense for the other interfaces or even for some of the other provided public API like Pn532::process_async

Maybe there could be a delay after a AdrNACK'ed communication? So that there would be somehow a rate limiting for the polls?

After thinking about this a bit I've decided with the following:

in the short term go with the quick fix in #14
in the long term, redesign the API in a way where where we can utilize the provided timer to handle this case in a better way

Thanks for your help

Just adding this as it seems relevant: PN532 datasheet section "12.26 Timing for the I2C interface" lists a minimum time between a STOP condition and a START condition of 1.3ms...  It also states that it may need to stretch the clock when woken by up to 1ms.


NESPARK-187 KyuubiAppMaster Namespace与publishServer

Codecov Report

Merging #5 into NESPARK-185 will decrease coverage by 0.51%.
The diff coverage is 40%.

@@                Coverage Diff                @@
##             NESPARK-185       #5      +/-   ##
=================================================
- Coverage          77.98%   77.47%   -0.52%
+ Complexity           622      618       -4
=================================================
  Files                 79       79
  Lines               3534     3538       +4
  Branches             496      496
=================================================
- Hits                2756     2741      -15
- Misses               506      523      +17
- Partials             272      274       +2

Impacted Files
Coverage Δ
Complexity Δ

...cala/yaooqinn/kyuubi/ha/HighAvailableService.scala
84.44% <40%> (-2.77%)
7 <1> (ø)

...main/scala/org/apache/spark/ui/KyuubiUIUtils.scala
69.23% <0%> (-15.39%)
0% <0%> (ø)

.../scala/org/apache/spark/ui/KyuubiSessionPage.scala
81.81% <0%> (-5.06%)
12% <0%> (-4%)

...la/yaooqinn/kyuubi/operation/KyuubiOperation.scala
59.11% <0%> (-3.12%)
60% <0%> (ø)

...la/yaooqinn/kyuubi/spark/SparkSessionWithUGI.scala
77.06% <0%> (-1.84%)
18% <0%> (ø)

Continue to review full report at Codecov.

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


MM-46289 : Investigate adding automated tracking of bundle size

Summary

Ticket Link
https://mattermost.atlassian.net/browse/MM-46289
Related Pull Requests
n/a
Screenshots
n/a
Release Note

NONE

E2E tests not automatically triggered, because PR has no approval yet. Please ask a developer to review and then try again to attach the QA label.

Closing this as the package uploads the artifacts to a 3rd party service in favour of using original github action


[Forwardport 2.9] system-upgrade-controller k8s 1.28 chart support

This is a forward port of https://github.com/rancher/rancher/issues/43730

QA TEST PLAN

#
Scenario
Test Case

1
Validate system-upgrade-controller version in freshly-installed RKE2 v1.28 cluster
Provision downstream RKE2 v1.28 cluster and validate the system-upgrade-controller chart version

2
Validate system-upgrade-controller version in upgraded RKE2 v1.28 cluster
Provision downstream RKE2 v1.27 cluster, upgrade to v1.28 cluster and validate the system-upgrade-controller chart version

3
Validate system-upgrade-controller version in an imported K3s v1.27 cluster
Provision a standalone K3s v1.28 cluster, import it into Rancher, upgrade to v1.28 and validate the system-upgrade-controller chart version

4
Validate system-upgrade-controller version in K3s cluster after upgrading Rancher
Setup Rancher v2.8.2, provision a downstream K3s v1.26 cluster, upgrade Rancher, upgrade to v1.28 and validate the system-upgrade-controller chart version

5
Validate system-upgrade-controller version in an imported RKE2 cluster after upgrading Rancher
Provision a standalone RKE2 v1.26 cluster, setup Rancher v2.8.2, import the cluster into Rancher, upgrade Rancher, upgrade cluster to v1.28 and validate the system-upgrade-controller chart version

Sent back to "Working" for rancher/rancher side changes.

Validated this against v2.9-head https://github.com/rancher/rancher/commit/a485774c4f71cc32464537e5982583335956443c.
ENVIRONMENT DETAILS

Rancher install: Docker
Rancher version: v2.9-head https://github.com/rancher/rancher/commit/a485774c4f71cc32464537e5982583335956443c

TEST RESULT

#
Scenario
Test Case
Result

1
Validate system-upgrade-controller version in freshly-installed RKE2 v1.28 cluster
Provision downstream RKE2 v1.28 cluster and validate the system-upgrade-controller chart version
:white_check_mark:

2
Validate system-upgrade-controller version in upgraded RKE2 v1.28 cluster
Provision downstream RKE2 v1.27 cluster, upgrade to v1.28 cluster and validate the system-upgrade-controller chart version
:white_check_mark:

3
Validate system-upgrade-controller version in an imported RKE2 v1.27 cluster
Provision a standalone RKE2 v1.28 cluster, import it into Rancher, upgrade to v1.28 and validate the system-upgrade-controller chart version
:white_check_mark:

4
Validate system-upgrade-controller version in K3s cluster after upgrading Rancher
Setup Rancher v2.8.2, provision a downstream K3s v1.26 cluster, upgrade Rancher, upgrade to v1.28 and validate the system-upgrade-controller chart version
:white_check_mark:

5
Validate system-upgrade-controller version in an imported RKE2 cluster after upgrading Rancher
Provision a standalone RKE2 v1.26 cluster, setup Rancher v2.8.2, import the cluster into Rancher, upgrade Rancher, upgrade cluster to v1.28 and validate the system-upgrade-controller chart version
:white_check_mark:

VALIDATION STEPS
Scenario 1

Provisioned a downstream RKE2 v1.28.6+rke2r1 cluster (1 etcd, 1 cp, 1 worker) as a standard user.
Noted that that the chart is at the following version: system-upgrade-controller:104.0.0+up0.7.0.

Scenario 2

Provisioned a downstream RKE2 v1.27.10+rke2r1 cluster (1 etcd, 1 cp, 1 worker) as a standard user.
Noted that that the chart is at the following version: system-upgrade-controller:104.0.0+up0.7.0.
Upgraded the cluster to v1.28.
Validated that the chart version is still the same.

Scenario 3

Provisioned a standalone RKE2 v1.27.10+rke2r1 cluster.
Successfully imported the cluster into Rancher.
Upgraded the cluster to v1.28.6+rke2r1.
Noted that the deployment version is at: rancher/system-upgrade-controller:v0.13.1.

Scenario 4

Provisioned a downstream K3s v1.26.13+k3s2 cluster (1 etcd, 1 cp, 1 worker) as a standard user.
Noted that the chart is at the following version: system-upgrade-controller:103.0.0+up0.6.0.
Upgraded Rancher to v2.8-head.
Validated SUC chart is at the same version pre-upgrade.
Upgraded cluster to v1.28.6+k3s2.
Validated that the SUC chart version has been upgraded to system-upgrade-controller:104.0.0+up0.7.0.

Scenario 5

Provisioned a standalone RKE2 v1.26.13+rke2r1 cluster.
Successfully imported the cluster into Rancher.
Upgraded Rancher to v2.8-head.
Upgraded cluster to v.128.6+rke2r1.
Validated that the deployment version is at: rancher/system-upgrade-controller:v0.13.1.


Add support for vertical layout of sliders

Someone on Stackoverflow asked if Flutter sliders can be arranged vertically, which is not possible with the current code base:
https://stackoverflow.com/questions/44341650/
Quoting the answer on Stackoverflow:
The slider component does not support switching the axis from horizontal to vertical. While you could technically rotate the sliders using a RotatedBox or the Transform class, that messes up the position calculation for the sliders. The slider class uses a HorizontalDragGestureRecognizer, so the thumb position change will be adjusted based on horizontal instead of vertical drags.
Steps to Reproduce
Run the example code from the Stackoverflow answer and try to move the scrollthumb. Vertical scrollthumb position is triggered by moving finger from left to right.
Flutter Doctor
Flutter • channel alpha • https://github.com/flutter/flutter.git
Framework • revision e2f54df5ab (3 days ago) • 2017-06-02 10:43:54 -0700
Engine • revision 1f2aa07571
Tools • Dart 1.24.0-dev.3.0

Material Design doesn't seem to discuss vertical sliders:
https://material.io/guidelines/components/sliders.html#
so it would be useful to have examples of ones you're looking for if these belong in the Material library itself.  Alternatively maybe this should just be a separate package?

Angular Material Design components have an example of vertical sliders, see https://material.angularjs.org/latest/demo/slider

Regarding the separate package: Maybe, but having an axis='x' | 'y' setting would probably not require large code changes.

Any update on this? We're building a app that requires vertical sliders.

Any updates on this one?

You can use this package, (flutter_xlider)[https://pub.dartlang.org/packages/flutter_xlider/versions/2.1.0)

@Ali-Azmoud - The vertical slider looks awesome!   Want to add a comment about usage- to make it not crash when changing the axis to vertical it needs to be wrapped in a parent widget like a container and the height must be set.
Again thanks for putting this together- it looks great and I'm excited to use it!

@benoitjadinon Sorry, I moved to another country and haven't been online for long time, didn't mean to ignore. Seems like Ali already created a better one!

It seems you can now simply wrap a Slider in a RotatedBox and it works fine. There are no problems with positionining or gesture detection - it all just works, I've just tried it. I would suggest that this issue could be closed?
RotatedBox(
     quarterTurns: 1,
     child: Slider( ... )
)

Given solution has been provided above. I am closing this issue now.

It seems you can now simply wrap a Slider in a RotatedBox and it works fine. There are no problems with positionining or gesture detection - it all just works, I've just tried it. I would suggest that this issue could be closed?
RotatedBox(
     quarterTurns: 1,
     child: Slider( ... )
)

ValueIndicator text is sideways if you do this.  No way I can see to rotate that as RangeSlider's RangeLabels accepts Strings, not Widgets.  Has anyone found a workaround for this? Example below:

It seems you can now simply wrap a Slider in a RotatedBox and it works fine. There are no problems with positionining or gesture detection - it all just works, I've just tried it. I would suggest that this issue could be closed?
RotatedBox(
     quarterTurns: 1,
     child: Slider( ... )
)

ValueIndicator text is sideways if you do this. No way I can see to rotate that as RangeSlider's RangeLabels accepts Strings, not Widgets. Has anyone found a workaround for this? Example below:

I was able to get around this by using a custom thumb shape that I rotated the canvas on.
For the slider:
RotatedBox(
        quarterTurns: -1,
        child: SliderTheme(
          data: SliderThemeData(
            activeTrackColor: color,
            inactiveTrackColor: Colors.black,
            thumbShape: CustomSliderThumbRectangle(color: color),
            trackHeight: 70,
          ),
          child: Slider(
            min: 0,
            max: 255,
            value: widget.value,
            onChanged: widget.onChanged
          ),
        ),
      ),

and then my thumb class:
class CustomSliderThumbRectangle extends SliderComponentShape {
  final Color color;
  final int min;
  final int max;

  const CustomSliderThumbRectangle({
    @required this.color,
    this.min = 0,
    this.max = 255
  });

  @override
  Size getPreferredSize(bool isEnabled, bool isDiscrete) {
    return Size.fromRadius(40);
  }

  @override
  void paint(
      PaintingContext context,
      Offset center, {
        Animation<double> activationAnimation,
        Animation<double> enableAnimation,
        bool isDiscrete,
        TextPainter labelPainter,
        RenderBox parentBox,
        SliderThemeData sliderTheme,
        TextDirection textDirection,
        double value,
        double textScaleFactor,
        Size sizeWithOverflow,
      }) {
    final Canvas canvas = context.canvas;

    TextSpan span = new TextSpan(
      style: AFTextStyles.timeline,
      text: (min + (max - min) * value).round().toString(),
    );

    TextPainter tp = new TextPainter(
        text: span,
        textAlign: TextAlign.center,
        textDirection: TextDirection.ltr
    );
    tp.layout();
    Offset textCenter = Offset(center.dy - (tp.height / 2), - center.dx - (tp.width / 2));

    Paint paintRB;
    final RRect borderRectB = BorderRadius.circular(8).resolve(textDirection).toRRect(Rect.fromCenter(center: center, width: 30, height: 70));
    paintRB = new Paint()
      ..color = Colors.black
      ..style = PaintingStyle.fill;

    Paint paintR;
    final RRect borderRect = BorderRadius.circular(8).resolve(textDirection).toRRect(Rect.fromCenter(center: center, width: 30, height: 70));
    paintR = new Paint()
      ..color = color
      ..style = PaintingStyle.stroke
      ..strokeWidth = 5;

    canvas.drawRRect(borderRectB, paintRB);
    canvas.drawRRect(borderRect, paintR);

    canvas.rotate(1.5708);
    tp.paint(canvas, textCenter);
  }
}

lotta bad hard code in there I know, but I just thought I'd share anyway.


Encapsulate message footer size requirement

Problem
Application-level code that allocates a packet buffer for a message of
a particular size has to be aware that up to kMaxTagLength additional
bytes may be necessary for the message authentication code. High-level
code shouldn't need to be aware of this.
Summary of Changes
Added:

chip::MessagePacketBuffer::New()
chip::MessagePacketBuffer::NewWithData()
chip::MessagePacketBuffer::HasFooterSpace()

Fixes #4666 - Hide low-level message authentication code requirements from high-level packet buffer allocation

@saurabhst @jelderton ?


Broken link in documentation

Hi
This link in the README.md file is broken:
https://cloud.ibm.com/docs/services/Registry?topic=registry-security_enforce#default_policies
Please update.

https://databunker.org/

Thanks for the report.
Links are broken in the project and the chart README.md.


spi_slave: change length to nwords

Summary
spi_slave: keep consistent with the parameter of the spi_slave_receive function declaration
CODE size_t   (*receive)(FAR struct spi_slave_dev_s *sdev, FAR const void *data, size_t nwords);
Impact
spi slave
Testing

@FelipeMdeO please take a look


Revert "[DistributionBundle] Fix real vendor dir , reading from composer.json"

I propose that the commit https://github.com/sensiolabs/SensioDistributionBundle/commit/798ddcd26ce04bcf3e0b08dd466ee89c415832ea gets reverted for the reasons I stated in the inline comments (sorry if this complicates issue reporting).

reverted for now.


hoot new error

When running the command hoot new I get the following stack trace:
(node:55837) UnhandledPromiseRejectionWarning: TypeError: item.toLowerCase is not a function
    at validateItem (/usr/local/lib/node_modules/hoot-cli/bin/commands/utility/newItem.js:8:30)
    at Command.newItem (/usr/local/lib/node_modules/hoot-cli/bin/commands/utility/newItem.js:32:5)
    at Command.listener (/usr/local/lib/node_modules/hoot-cli/node_modules/commander/index.js:291:8)
    at Command.emit (events.js:315:20)
    at Command.parseArgs (/usr/local/lib/node_modules/hoot-cli/node_modules/commander/index.js:672:12)
    at Command.parse (/usr/local/lib/node_modules/hoot-cli/node_modules/commander/index.js:459:21)
    at Object.<anonymous> (/usr/local/lib/node_modules/hoot-cli/bin/index.js:53:9)
    at Module._compile (internal/modules/cjs/loader.js:1176:30)
    at Object.Module._extensions..js (internal/modules/cjs/loader.js:1196:10)
    at Module.load (internal/modules/cjs/loader.js:1040:32)
(Use `node --trace-warnings ...` to show where the warning was created)
(node:55837) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). To terminate the node process on unhandled promise rejection, use the CLI flag `--unhandled-rejections=strict` (see https://nodejs.org/api/cli.html#cli_unhandled_rejections_mode). (rejection id: 1)
(node:55837) [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.

We can add a hook in index.js to help resolve this with a custom error message.

comment

I've fixed this with ac2e825. Closing the issue.


Missing class MultipartRequestHelper

@sergiodesousafilho commented on Thu Oct 03 2019
Hello, the class "MultipartRequestHelper" is not implemented or builtin.

Detalhes do documento
⚠ Não edite esta seção. É necessário para a vinculação do problema do docs.microsoft.com ➟ GitHub.

ID: 9a5cfa38-0e6c-4346-dafc-84ea5c513fcf
Version Independent ID: c6787f0f-3e9a-6efb-0e6e-5ccb957d3f4a
Content: Uploads de arquivos no ASP.NET Core
Content Source: aspnetcore/mvc/models/file-uploads.md
Product: aspnet-core
Technology: aspnetcore-mvc
GitHub Login: @ardalis
Microsoft Alias: riande

@srvbpigh commented on Thu Oct 03 2019
Hello, @sergiodesousafilho
Thank you for your feedback.
We are actively reviewing your comments and will get back to you soon.
Kind regards,
Microsoft DOCS International Team

Hi team, please check this issue.
Thanks!

@lichasu Open these using the feedback form on the English topic :point_right: https://docs.microsoft.com/en-us/aspnet/core/mvc/models/file-uploads

It is implemented ... see the sample app :point_right: https://github.com/aspnet/AspNetCore.Docs/blob/master/aspnetcore/mvc/models/file-uploads/samples/2.x/SampleApp/Utilities/MultipartRequestHelper.cs

Actually ... YES! ... let's call that out in the text. I'll add that to the 3.0 updates on https://github.com/aspnet/AspNetCore.Docs/pull/14770.

Thanks @lichasu and @sergiodesousafilho ... that update will go in when #14770 merges. :rocket:


Dotted line in thumbnail strip doesn't appear when importing canvases

If you're dragging a canvas from an external manifest, the dotted line around the canvas in the thumbnail strip (where the imported canvas will go) doesn't appear unless you have already rearranged some of the canvases in the thumbnail strip.

When the canvases have been reordered via drag & drop, the dotted line also appears when dragging canvases from source manifests. When they haven't been reordered before, the dotted line does not appear.


Publish on CurseForge

Although Modrinth is the better platform, for so many reasons, there is a big community of people that exclusively use CurseForge. I shouldn't ignore it any longer, it's worth publishing the data packs on there.

Going to start with publishing No Free Deaths on Curseforge, then I plan to update the versions of the data packs to mark them as compatible with 1.21.3 and publish those.
I've been rethinking my strategy for publishing updated versions because there are two conflicting issues:

If I don't update the packs, it looks like they don't work on a new version.
Updating the packs gives me free publicity on the "recently updated" section
If I do update the packs, then I'm publishing an update where the changelog is "bumped the version" and I hate that from a maintainer's perspective and a user's perspective. And what point should I stop? Do I do that for every update or just some?

If Curseforge makes me re-assess my strategy here, I'll be very happy.

This is in progress now.

Now waiting on CurseForge to approve it.


DOC: add whatsnew for #11920

#11920 (forgot to add to commit when merging)

Current coverage is 85.77% (diff: 100%)

Merging #13953 into master will increase coverage by 0.47%

@@             master     #13953   diff @@
==========================================
  Files           139        139
  Lines         50159      52054   +1895
  Methods           0          0
  Messages          0          0
  Branches          0          0
==========================================
+ Hits          42786      44649   +1863
- Misses         7373       7405     +32
  Partials          0          0

Powered by Codecov. Last update cce7993...24628c7


Page for badges for swag

Did you mean badges like this or what kind of badges can we create for that page?

Its looking good,  but we need to make it look good and clear.

Yes something like this... However, the important thing to know for someone who is going to implement this is not the design for the actual badge, but rather the overall design for the page where the badges go

This will welcome the student to the first test before he/she moves to next test.

Badges for collected swag is now shown under "My Account", under the "My Swag" tab.


Fix GZip handling for requests

Fixes https://github.com/Azure/azure-sdk-tools/issues/4103
The change here is to make sure that gzipped request bodies are stored decompressed (matching the behavior for response bodies). We also will decompress the body in playback mode before sanitization/matching.

@JoshLove-msft I really appreciate this PR. I don't see any issues jump out at me. I think for the most part where people ran into this bug, they ended up disabling body matching entirely. This means that this change should be backwards compatible, but I need to actually confirm that via an eng/common update before we merge this.
I'll kick an internal build of this to get a published image and run do a smoke-test runs of a couple suites that I know involve gzipped content.

Thank you! Yes, testing against the other repos first is much appreciated!

/check-enforcer override

Thanks @scbedd, @JoshLove-msft.
/cc: @nisha-bhatia we should be able to enable GZip tests in the playback mode now.


[WEB-1180-196] WIP: historical apy

contains
* net_apy
* gross_apr

fees:
* management
* performance
* withdrawal
* keep_crv
* cvx_keep_crv

TODO

[x] check if data already exists per metric
[x] align snapshot timestamps with the existing data based on timestamps (currently it's based on blocks)
[ ] check for experimental flag properly set
[ ] check if metrics are merged
[ ] check metric keys match (vault name, address etc.)

closing this for now


Add HKU School of Professional and Continuing Education

@tonyhhyip Des this school of Univeristy of Hong Kong offer long-term (>1 year) IT-related courses? Which website is better to browse to learn more about the school? https://learner.hkuspace.hku.hk seems to provide no general information about the school and the courses...

@philipto Yes, it does, here is the CS. Its official website is on http://hkuspace.hku.hk/. This domain is the student email domain.

@tonyhhyip Thank you for the details. Pull request merged. Please notice that the free license granted to a student is for educational  purpose, and students who study online only (have no classes in classrooms) are not eligible to use this free license. Feel free to comment if you have any questions or ask<EMAIL_ADDRESS>for details regarding using free licenses.


Fabric 2.0 support

Do you plan to upgrade this for Hyperledger Fabric 2.0?

In principle, yes, but I have not had the time to perform the upgrade. I will add an issue regarding this plan.
Any help offered is welcome :)


Tests for cells

These are the tests for notebook/cells and the subsequents tweaks and bug fixes that they revealed.

File
% Stmts
% Branch
% Funcs
%Lines

notebook/cells/
99.26
86.62
100
99.62

editor.js
100
92.86
100
100

index.js
100
50
100
100

model.js
98.58
91.43
100
100

widget.js
99.29
82.05
100
99.28

FYI, this PR is on hold because https://github.com/jupyter/jupyterlab/pull/101 will require it to be rebased and somewhat refactored.

LGTM, thanks!


Shoot, sorry. Git is a little confusing still!

—
Reply to this email directly or view it on GitHub.

@raesu No worries! :)


Migrate network/perf to go modules

It migrates network/performance to go modules ( so fixes a part of #1099 )
It also adds a way to specify pull policy for locally built images

Hi @sknat, please sign CLA (detailed instructions appear when you click "Details").

Hi @oxddr , sorry for the delayed response
I missed the timeout for signing the CNCF individual contributor CLA the first time, and I've been unable to re-trigger the email since, nor emailing support through the interface.
Any idea who can help me on this one ?
Thanks in advance

I signed it

The CI bot doesn't see it as signed. If you indeed signed, trying closing this PR and opening a new one.
BTW, please move the "imagePullPolicy" flag changes to a separate PR


Add support for double socket smart plugs

added device _TZ3000_jak16dll / TS011F

Resolves: #374
Note this is a naive first attempt at a solution for adding support for this device.
Feedback welcome and happy to iterate. Alternatively, feel free to modify as required.

@JohanBendz I am leaving this in draft since I am not entirely sure what I am doing with this since it is first time I am developing for Homey.

Tested this with my device, and it seems to work. Not sure if exposing the second outlet as a sub device is the best experience, but given that the device has two power buttons and metering seems to be "global", seems the best way is the second outlet to be a on/off subdevice.

Hi @abn, I'll have a look at the code. Can you share a console log?

@JohanBendz let me know if I can do anything to help here. Or if you need any additional info.

@JohanBendz gentle ping. Anything I can do to help this along?

Hi @abn, sorry for the delay,
Log looks good, the "time" cluster can be ignored.
I agree with the choice to use subdevice, most users want a separate device per socket.
I'll merge the PR and have this added to next release.
Well done! :)

Awesome. Thank you @JohanBendz. Looking forward to the next release. :)

@JohanBendz do you know when you will be able to get a new test/stable release out with this change in it?


Question: why do we add this.robot.name before the message when DM

Hi @loafoe,
i was wondering why we need to add username in this case :
https://github.com/loafoe/hubot-matteruser/blob/e62fbbed0e3f153ea8c74ce199caf9eff912c405/src/matteruser.js#L369-L371
I have a custom version on my side where i've removed this part of code. If not, it does not work with something like that :
robot.hear(/^!bot$/i, msg => {
...
}

In my case, the bot should reply only to !bot, not for another message like foo bar !bot.
But as we add username before the message, it's hard to check this.

hi @jgarec this might be a leftover of past behaviour of the server. Indeed it does not look like it's strictly required and the name can probably be stripped if it's there before further processing. Accepting PRs for improving this..  👍🏻

Hi @loafoe, could you publish a new release including #111 ?
Thx :)

Will create a release shortly

v5.4.4 released


Challenge anyone

I'd like to be able to challenge anyone, not a specific user. Currently this "problem" is solved by begging.

I took a stab at this a while ago, but I think the flow could be better.
https://github.com/andrewvy/slack-pongbot/commit/9bec87761108d869f737d4465bc4eebbb7fc09c3

I think it should work like this: pongbot challenge singles (it can't be pongbot challenge singles anyone because someone could be named anyone :), which creates a Challenge without any challenged opponents, then when you pongbot accept you become either the opponent or a teammate for doubles. Codewise it means looking for one such open challenge when you accept.

That sounds good to me. I like the dual use of the challenge command.
pongbot challenge singles
pongbot challenge doubles
I think there should just only be one open challenge, it could get confusing. So joining one would just be whatever current open challenge there is. And then trying to create another open challenge would just remind you that there's one already.
I feel like an open challenge should expire over time though, just in case someone created one but no one joined ( :cry: ) and it got left overnight.

:+1:

I think generally there's no reason to have long lived challenges that aren't accepted, opened https://github.com/andrewvy/slack-pongbot/issues/53.


Bad chars enhancement

added new class to realize customized bad char replacement

2 hidden fields for output string and regular expression replacement
initialization method to parse customBadChars string
method to actually do the replacement

added followup parameter for option customBadChars
changed codes to call the newly added method
added description for the new syntaxes for bad chars.

sorry that i added too many commits. sometimes i just wanted to make it better but made some mistakes which i found out later... and had to fix them which might leads to more mistakes or dissatisfaction, so i had to change more...


Repeatedly initializing and releasing player

Hi, am playing local mp4 files in recycler view and I've managed to break the player by quickly switching focus(playback) between two neighbour players in recycler view. By quickly I mean player came in focus and player initialization started but I would switch(release the player) to neighbour player before play(rendering frames) started, doing that repeatedly causes the player to silently crash with error log after several tries.
I've created the log file MediaPlayerCrashLog.rtf because it's not practical to paste such a huge log here. I suggest you to open it in text editor with wrap line set to false. In log file I've isolated 3 situations:

last successful play just before first crash happens
first player crash(player silently crashes with error log)
second player crash(also silent crash) which is induced after continuing to switch focus between 2 neighbour players after player was already crashed with first player exception

Aditional notes:

after player have crashed, it's not possible to play any video until i kill the app and restart it again.
also when player crashed MediaPlayer.OnErrorListener() was not called.
i have hardcoded in my app that after player release minimum 250ms must pass before new player can kick in with init/play. If time passed from player release until new play request is less than 250ms, init/play is delayed for diff = 250 - elapsed_time_since_release

Issue produced on Google nexus 5x.

Hi, I can't really tell from the logs but it's probably an issue with the render surface, maybe because both players operate on the same recycled surface at the same time (e.g. player A is preparing with surface X while player B is still releasing surface X).
Can you prepare a small example activity so I can reproduce the issue?

I'll upload the code until day end.

Hi, sry for delay I was busy with other stuff and it wasn't trivial to create example. The example i uploaded is written in MVP and is actually my production code stripped of all unnecessary things. If you found your self difficult navigating through the code i can clean it even further or clarify some parts. There are lot of classes and interfaces but actually there is not so much logic it's just MVP boilerplate ...
Classes you would be interested in:
MediaPlayerImp -> wrapper arround MediaPlayerExtended
MomentsView -> recyclerview which is responsible for hosting the video players
ItemVisibilityUtil -> util which calculates most visible item in recyclerview
MomentPresenterImp -> presenter responsible for controlling single video player in recyclerview
MomentViewHolder -> viewholder which represents single item in recyclerview
I've also put in assets folder several mp4 files and their starting thumbnails so you have everything setup for play.
https://github.com/xylik/MediaPlayerList

Thanks for the example app and thank you again for helping me find an unpleasant bug!
There was a memory leak in release() that prevented codecs and audio tracks (and the PlaybackThread) from being released, ultimately leading to your observed errors once the maximum number of MediaCodec instances was reached. I assume this is what @piotrmadry observed as well and reported in #45.
I've already fixed it, but will do some more testing tomorrow before I release a new version.

4.2.2-rc1 is online, please give it a try and let me know if it works for you. All leaks should be fixed and I can now scroll through the videos forever without playback failing.
In your sample app, I'm still getting two exceptions when switching many times quickly between videos, one from an invalid surface, and the other is a NullPointerException somewhere in your code. I'm not sure if the first exception is the player's fault or if your app is trying to use the same surface on two players at the same time.

I don't think my code is setting same surface on two players but I will create new example with all MVP removed and playback counter rx thread removed just to eliminate code complexity and possible errors.
I've carefully examined the Verbose log and saw a pattern that potentially triggers the error state:
-player release is being called before player would reach prepared state("D/MediaPlayer: onPrepared") which allways resulted with Player writing to error log

player at first is failing with this exception:
4143-5586/hr.fer.com.mplayerlist E/MediaCodecVideoDecoder: reinitCodec: illegal state
4143-5586/hr.fer.com.mplayerlist E/MediaPlayer: cannot create video decoder: null
4143-5586/hr.fer.com.mplayerlist E/MediaPlayer: cannot create audio decoder: null
4143-5586/hr.fer.com.mplayerlist E/MediaPlayer: prepareAsync() failed: cannot decode stream(s)
java.io.IOException: cannot decode any stream
at net.protyposis.android.mediaplayer.MediaPlayer.prepareInternal(MediaPlayer.java:328)
at net.protyposis.android.mediaplayer.MediaPlayer.access$500(MediaPlayer.java:36)
at net.protyposis.android.mediaplayer.MediaPlayer$2.run(MediaPlayer.java:423)
at java.lang.Thread.run(Thread.java:818)
4143-4143/hr.fer.com.mplayerlist E/MediaPlayer: Error (1,-1004)

-then it fails with several different errors but it's allways failing after release is being called and player have not yet reached prepared state:
1st error
4143-5608/hr.fer.com.mplayerlist D/MediaCodecVideoDecoder: reinitCodec 35ms
4143-5608/hr.fer.com.mplayerlist E/MediaPlayer: cannot create audio decoder: null
2nd error
/hr.fer.com.mplayerlist E/MediaPlayer: prepareAsync() failed: something is in a wrong state
java.lang.IllegalStateException
at android.media.MediaCodec.native_dequeueOutputBuffer(Native Method)
at android.media.MediaCodec.dequeueOutputBuffer(MediaCodec.java:2379)
at net.protyposis.android.mediaplayer.MediaCodecDecoder.dequeueDecodedFrame(MediaCodecDecoder.java:309)
at net.protyposis.android.mediaplayer.Decoders.decodeFrame(Decoders.java:81)
at net.protyposis.android.mediaplayer.MediaPlayer.prepareInternal(MediaPlayer.java:365)
at net.protyposis.android.mediaplayer.MediaPlayer.access$500(MediaPlayer.java:36)
at net.protyposis.android.mediaplayer.MediaPlayer$2.run(MediaPlayer.java:423)
at java.lang.Thread.run(Thread.java:818)
/hr.fer.com.mplayerlist E/MediaPlayer: Error (1,0)
3rd error
/hr.fer.com.mplayerlist E/BufferQueueProducer: [SurfaceTexture-0-4143-15] connect(P): already connected (cur=3 req=3)
/hr.fer.com.mplayerlist I/MediaCodec: native window already connected. Assuming no change of surface
/hr.fer.com.mplayerlist E/MediaCodec: configure failed with err 0xffffffea, resetting...

You are right, the problem was that release() didn't wait for prepareAsync() to finish, which in some situations led to these errors.
I'm now at a point where whatever I do, I can't provoke an exception any more. Very cool, I've always been looking forward to this :) Thanks again for your valuable help, rc2 will follow tomorrow :) I think a new example app won't be necessary any more. Except if you had a really simple example with minimal dependencies, that would make a nice addition to the demo app!

4.2.2-rc2 is online, please give it a try!

I've tested rc2 and player is super super stable :), I couldn't break it no matter what I do - great job!
There is one more thing that is still bodering me and that's recyclerview lagging while player initialization is going on.

Is it possible that some part of your player initializaiton(some heavy operation) is done on main thread and if so could it be moved to background thread just to achieve smooth UI rendering ?
I've updated my example with 250ms delay(from player release to new play) removed and you'll see that fast scrolling without lag is now not possible.

Yup this lagging is extremely annoying, but I don't think it is the player, at least not directly. prepareAsync does nothing on the main thread, my measurements on a N5X show an execution time < 1 millisec. What's taking some time is setDataSource, about 30 millisecs, but moving it into the background thread doesn't fix the lagging even a bit. Then there's no other "heavy" methods left.

Figured it out. It's actually the release() method that takes a long time (~200ms, because it now waits until prepareAsync has finished). If I put it into the background the lagging is completely gone, there's two problems though:

I can't move it into the background, because it would break MediaPlayer API compatibility,
and you shouldn't do it in your app because it again leads to exceptions regarding the surface (tried it with an AsyncTask).

So I think the best approach is the one you already had, add a delay and only call prepareAsync when the user stays at the video.

I see, the problem is actually more visible when user is slowly swypeing through list because when he is moving to next video release is happeing and lag occures. When user do fast swipe, items(players) are passing to fast over the screen and neither one player init/release cycle happens due to 250ms trashold and everything is smooth.
Could it be somehow possible to create releaseAsync() - extend api for the sake of UX and somehow deal with surface destroy?

So, I've been spending a lot of time on this issue and I was able to write a working releaseAsync method, but I won't publish it... it didn't solve the UI lag because the next problem which appeared then is the setDataSource method which also takes a while. So in the end, there are this 3 main methods in the player's lifecycle that take some time: setDataSource, prepare/prepareAsync and release, and I think it should not be the focus of this library to get them away from the main thread, as it complicates the architecture and largely deviates from the original MediaPlayer API.
In special cases like yours, I think you'll have to take care about getting the MediaPlayer off the main thread by yourself. I made a quick and dirty hack in your sample app and put the heavy MediaPlayer methods into AsyncTasks, and got buttery-smooth scrolling, but unfortunately also some exceptions and thread leaks that I couldn't manage to fix. It demonstrated though that your goal is reachable, that the result can be great, but also that AsyncTasks are not the way to go. I think a nice way might be managing the MediaPlayer on a HandlerThread and calling all methods from there (use the synchronized prepare).
I'm closing this issue now because the original issue, the exceptions and crashes (and associated leaks), are solved. If you want to further discuss how to get the player off the UI thread to get smooth scrolling, you're welcome to open another issue!

Thanks for detail explanation, I've forked your repo. Would you be so kind and do a pull request with those async modifications so I can observe what you've done and maybe continue working on making those heavy methods async ?

I pushed the branch with the releaseAsync method to feature/release-async and the experimental async demo to xylik/MediaPlayerList#1.


feat: Adds virtualization option to antd based Table component

SUMMARY

This PR adds a virtualization prop to the recently added ant based Table component.  Virtualization allows the tables to be used in cases where there are hundreds or thousands of columns, or large dataset with many thousands of rows with no pagination enabled.
BEFORE/AFTER SCREENSHOTS OR ANIMATED GIF

TESTING INSTRUCTIONS

Checkout PR and open console at superset/superset-frontend
run npm ci
run npm run storybook and view docs and test virtualized table at: http://localhost:6006/?path=/story/design-system-components-table-overview--page under the "Virtualization for Performance" section, or interact directly with virtualized table instance at: http://localhost:6006/?path=/story/design-system-components-table-examples--virtualized-performance
Ensure the other table example stories work correctly
run npm run dev-server and go to http://localhost:9000/dataset/add/?testing to ensure the table instance used in the create dataset workflow still behaves as expected following instructions on this prior PR: https://github.com/apache/superset/pull/21948

ADDITIONAL INFORMATION

[ ] Has associated issue:
[ ] Required feature flags:
[ ] Changes UI
[ ] Includes DB Migration (follow approval process in SIP-59)

[ ] Migration is atomic, supports rollback & is backwards-compatible
[ ] Confirm DB migration upgrade and downgrade tested
[ ] Runtime estimates and downtime expectations provided

[X] Introduces new feature or API
[ ] Removes existing feature or API

Hello @eric-briscoe. Thanks for this PR!
I have some questions about VirtualTable:

There's react-virtual (5.3 kB) which 3 times less than rc-resize-observer (15.6 kB) and provides hook for this func copmonent. Should we use react-virtual for VirtualTable?
Why do we use antd based Table instead of react-table. react-table already supports virtualization - virtualized-infinite-scrolling and virtualized-rows
Can we also use the VirtualTable in FilterableTable for result data in SQL Lab

Hello @eric-briscoe. Thanks for this PR! I have some questions about VirtualTable:

There's react-virtual (5.3 kB) which 3 times less than rc-resize-observer (15.6 kB) and provides hook for this func component. Should we use react-virtual for this VirtualTable?
Why do we use antd based Table instead of react-table. react-table already supports virtualization - virtualized-infinite-scrolling and virtualized-rows
Can we also use the VirtualTable in FilterableTable for result data in SQL Lab

@EugeneTorap Great questions!
@michael-s-molina noted in a diff comment on this PR we already have 'react-resize-detector' as a dependency used in components such as MetadataBar so I refactored to use that library in place of rc-resize-observer and this PR introduces no new dependencies now
Bigger picture, the introduction of src/components/Table based on antd is continuing of work started with https://github.com/apache/superset/issues/20159 (SIP-82) about more consistent theming, use of Ant Design components and establishing a formal design system using antd as a base for new components.
VitrualTable is never intended to be used directly.  It is a sub component to enable the src/components/Table to operate in a virtualized mode if needed and implementation is based from this antd example, then modified for our needs: https://ant.design/components/table/#components-table-demo-virtual-list
If you check out PR and run storybook, you will see the documentation for using the new Table component, and in this PR docs on using the virtualize prop have been added.
As far as using a different library such as react-table I was asked to use antd for consistency in a single Table implementation so that features like column definitions, sort functions, cell renderers, data formats, etc can be consistent, and the UI controls are consistent wether we are using the Table with or without virtualization.
Regarding use in SqlLab, the goal is to replace eventually replace all tables across superset-frontend with the new src/components/Table (but never VirtualTable directly).  Table uses VirtualTable as a sub component when the Table prop virtualize is set to true.  This allows of are lot of the common logic between virtual and non-virtual rendering to be handled at the Table component level and not duplicated in VirtualTable.
I was asked to introduce the Table capability incrementally so that it can be used for the new dataset creation and editing workflows, fix issues in the drill to detail modal, and the target other high use areas of the app to start swapping out.  Some Table features will be need to be exposed / added as we do this and features refined as it gets used more.  I was also asked to make Table an abstraction to antd so that it can leverage antd components but streamline usage for Superset use cases and not require developer to understand / use antd directly.  That is bigger picture goal for design system which will likely be a follow on SIP to SIP-82, but still doing some research / prototyping to get this ready for community discussion.
I would really appreciate more eyes on the storybook examples and documentation so we can improve it to make usage as clear and efficient as possible for all Superset contributors.  If you have any time to take a look and have feedback please send my way!

@eric-briscoe Thank you for your answer! I like what you do!

Can we eliminate the scroll space of the table when there's no scroll?

When using virtualize the render function is not being called which prevents me from formatting the content.

When using virtualize the render function is not being called which prevents me from formatting the content.

@michael-s-molina support for the render function on column definitions when in virtualized mode has bee added in latest commit

@eric-briscoe Can you add the behavior to scroll to the top when paginating?

@eric-briscoe We have the concept of column formatting as you can see in the screenshot below:

I'm wondering about the best approach to implement this. It looks pretty similar to the filters concept provided by Ant Design's table. If we follow the same pattern, we can have formattings, defaultFormatting, onFormatting properties on ColumnsType to create the popup selector. We would also need to provide a TimeCell renderer that can be used when rendering dates/timestamps/numbers. WDYT?

@eric-briscoe @michael-s-molina
I found a bug when I use virtualize and usePagination={false} at the same time, I still see pagination!


Add --output-json flag and output machine readable on STDOUT

In order to simply integrate jira-offline with other apps, it would be useful to have a JSON output option, which makes the app print JSON on stdout.

Closed in #38


Feature request: better support for parameterized (new)types

If I say:
data Foo a = Foo [a]
deriveQA ''Foo

I get:
instance QA a => QA (Foo a) where
  type Rep (Foo a) = [a]
  toExp (Foo x) = toExp x
  frExp x = Foo (frExp x)
  frExp _ = error "DSH: Impossible happened"

This is wrong. Rep (Foo a) should be Rep [a], not [a]. Obviously, same happens if Foo is a newtype.
generateTableSelectors also does not handle parametrized types. For example, I had to write this selector by hand although it is very simple to derive it:
where_prov_keyQ :: (QA a) => Q (WhereProvAnnot a) -> Q a
where_prov_keyQ (view -> (_, _, key)) = key

Interestingly, if I say:
data Foo a = Foo { foo :: a }
deriveQA ''Foo

this also doesn't work but if I add a field of a concrete type:
data Foo a = Foo { foo :: a, bar :: Integer }
deriveQA ''Foo

then it works. This looks like a bug.


Migrate to Angular 2

This relates to issue #4 but needs to be completed before we move on to UI/UX improvements

Also probably related to #5
Having angular will drastically reduce work needed for time controls


how do I train a large dataset that out of memory?

I want to train a detector based on object365 dataset, but object365 is pretty large, and caused out of memory error in my computer.
I want to split the annotation file to 10, such as ann1,ann2,...ann10, then build 10 datasets and concatenate them, but I'm not sure whether it's
gonna work or not.
Any better suggestion?

Hi, Firstly, you can try to set workers_per_gpu = 0 to avoid OOM. Seems that your idea might work, but we haven't verified yet. Your idea is in the plans of MMDet for the next few months.

@BIGWangYuDong  has there been any updates on this issue.I noticed that ZwwWayne marked it as completed.


Tag a release

For composer installation it would be very helpful if you could tag a release (e.g. 1.0). When using dev-master, composer has to scan the git repository on each update to figure out the appropriate git hash. This slows things down considerably. Having a tagged release speeds up installation markedly.

No problem, just tagged 0.9


Unable to build native binaries on new Mac with XCode 12

Describe the bug
I got a new Mac and started completely clean and  I followed the instructions for building Ghidra (building the debugger branch).  I installed XCode 12 and then built using gradle buildGhidra.  When building the native binaries, it fails with various "no member found" exceptions.  I have tracked it down to XCode 12 (apparently, 10+ as well) to not having the libstdc++ libs included or supported anymore and should be using libc++.  The instructions for building don't mention anything regarding this.  I think builds work for most people if they have had previous XCode versions or some other installations that have libstdc++.
Here is an example of on of the errors:
sleighbase.cc:230:18: error: no member named 'emplace_back' in 'std::__1::vector<FloatFormat, std::__1::allocator<FloatFormat> >'     floatformats.emplace_back();     ~~~~~~~~~~~~ ^
To Reproduce
Steps to reproduce the behavior:

Use a completely clean Mac or a Mac with no libstdc++
Install XCode 12
run buildNatives_osx64

Expected behavior
The native binaries to build properly
Environment (please complete the following information):

OS: Mac OS Catalina 10.15.7
Ghidra Version: latest debugger branch
Clang 12.0

I'm not sure this will solve everything, but it sounds similar to problems I was having with the M1 mac.
In the file Ghidra/Features/Decompiler/build.gradle, insert
			b.cppCompiler.args "-std=c++11"

at around line 549 so it looks like this:
		else if (b.toolChain in Clang) {
			b.cppCompiler.args "-std=c++11"
			b.cppCompiler.args "-Wall"

Hope this helps. If it does, I will make a PR for it.

I'm not sure this will solve everything, but it sounds similar to problems I was having with the M1 mac.
In the file Ghidra/Features/Decompiler/build.gradle, insert
			b.cppCompiler.args "-std=c++11"

at around line 549 so it looks like this:
		else if (b.toolChain in Clang) {
			b.cppCompiler.args "-std=c++11"
			b.cppCompiler.args "-Wall"

Hope this helps. If it does, I will make a PR for it.

I just confirmed that on 10.15.7, the master branch fails without the above change but it builds after making the change.
The debugger branch also builds. I did not try running the debugger, however.

I just confirmed that on 10.15.7, the master branch fails without the above change but it builds after making the change.
The debugger branch also builds. I did not try running the debugger, however.

@tomnelson Re debugger, there's no current support for lldb, and the versions of gdb commonly available for the Mac, e.g. homebrew, don't support the Pty interface we're using.

@tomnelson Re debugger, there's no current support for lldb, and the versions of gdb commonly available for the Mac, e.g. homebrew, don't support the Pty interface we're using.

@tomnelson Re debugger, there's no current support for lldb, and the versions of gdb commonly available for the Mac, e.g. homebrew, don't support the Pty interface we're using.

So there will be no debugger support on OSX?  Or there just isn't yet?

@tomnelson Re debugger, there's no current support for lldb, and the versions of gdb commonly available for the Mac, e.g. homebrew, don't support the Pty interface we're using.

So there will be no debugger support on OSX?  Or there just isn't yet?

I'm not sure this will solve everything, but it sounds similar to problems I was having with the M1 mac.
In the file Ghidra/Features/Decompiler/build.gradle, insert
			b.cppCompiler.args "-std=c++11"

at around line 549 so it looks like this:
		else if (b.toolChain in Clang) {
			b.cppCompiler.args "-std=c++11"
			b.cppCompiler.args "-Wall"

Hope this helps. If it does, I will make a PR for it.

I just pulled your fix and it built successfully.  thanks!!

I'm not sure this will solve everything, but it sounds similar to problems I was having with the M1 mac.
In the file Ghidra/Features/Decompiler/build.gradle, insert
			b.cppCompiler.args "-std=c++11"

at around line 549 so it looks like this:
		else if (b.toolChain in Clang) {
			b.cppCompiler.args "-std=c++11"
			b.cppCompiler.args "-Wall"

Hope this helps. If it does, I will make a PR for it.

I just pulled your fix and it built successfully.  thanks!!

@brian-rose-sp there isn't any yet - we had hoped current versions of lldb would support the gdb/MI out-of-the-box, but the lldb developers seem to have gone a different route. Support for osx will require building up a fresh model based on the lldb API, which is unfortunately a good bit more work.

@brian-rose-sp there isn't any yet - we had hoped current versions of lldb would support the gdb/MI out-of-the-box, but the lldb developers seem to have gone a different route. Support for osx will require building up a fresh model based on the lldb API, which is unfortunately a good bit more work.

The ability to build on an Apple M1 has been addressed for patch and master.  While builds for this platform will not be provided with standard distributions of Ghidra, it should build for a user on an M1 in support of the local architecture.

The ability to build on an Apple M1 has been addressed for patch and master.  While builds for this platform will not be provided with standard distributions of Ghidra, it should build for a user on an M1 in support of the local architecture.


Completion tests disabled

Description:
Few completions tests were disabled due to changes to AbstractListener change from https://github.com/ballerina-platform/ballerina-lang/pull/17558

Fixed in https://github.com/ballerina-platform/ballerina-lang/pull/17641