Fix: Chat - Tiny dots displayed in link name for message/link ([some])  #19646

Details

Fixed Issues

$ https://github.com/Expensify/App/issues/19646
PROPOSAL: https://github.com/Expensify/App/issues/19646#issuecomment-1563916118
Tests

Login to NewDot
Open any chat room
Send a message containing link, for example: ([some])
Make sure render link does not show tiny dot which is actually due to character overlapping the text underline.

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

Offline tests

Bug is not related to offline mode itself. No extra steps needed.
QA Steps

Login to NewDot
Open any chat room
Send a message containing link, for example: ([some])
Make sure render link does not show tiny dot which is actually due to character overlapping the text underline.

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

PR Author Checklist

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

[ ] I added steps for local testing in the Tests section
[ ] I added steps for the expected offline behavior in the Offline steps section
[ ] I added steps for Staging and/or Production testing in the QA steps section
[ ] I added steps to cover failure scenarios (i.e. verify an input displays the correct error message if the entered data is not correct)
[ ] 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)
[ ] 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).

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

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

[ ] 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)
[ ] I followed proper code patterns (see Reviewing the code)

[ ] 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)
[ ] I verified that the left part of a conditional rendering a React component is a boolean and NOT a string, e.g. myBool && <MyComponent />.
[ ] I verified that comments were added to code that is not self explanatory
[ ] 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.
[ ] I verified any copy / text shown in the product is localized by adding it to src/languages/* files and using the translation method

[ ] 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:

[ ] I verified all numbers, amounts, dates and phone numbers shown in the product are using the localization methods
[ ] 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.
[ ] 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.
[ ] I verified the JSDocs style guidelines (in STYLE.md) were followed

[ ] If a new code pattern is added I verified it was agreed to be used by multiple Expensify engineers
[ ] I followed the guidelines as stated in the Review Guidelines
[ ] 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)
[ ] I verified all code is DRY (the PR doesn't include any logic written more than once, with the exception of tests)
[ ] 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
[ ] I verified that if a function's arguments changed that all usages have also been updated correctly
[ ] If a new component is created I verified that:

[ ] A similar component doesn't exist in the codebase
[ ] All props are defined accurately and each prop has a /** comment above it */
[ ] The file is named correctly
[ ] The component has a clear name that is non-ambiguous and the purpose of the component can be inferred from the name alone
[ ] The only data being stored in the state is data necessary for rendering and nothing else
[ ] 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)
[ ] 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)
[ ] All JSX used for rendering exists in the render method
[ ] 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

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

[ ] 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

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

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

[ ] 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.
[ ] 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)
[ ] 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.
[ ] 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.
[ ] 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 author checklist, including those that don't apply to this PR.

Screenshots/Videos

Web

Mobile Web - Chrome

Mobile Web - Safari

Desktop

iOS

Android

I have read the CLA Document and I hereby sign the CLA

I have read the CLA Document and I hereby sign the CLA

recheck

recheck

recheck

recheck

Hi @narefyev91 Can you please help & have a look why CLA bot is still failing?

@spcheema hey! you need to sign CLA agreement

I have read the CLA Document and I hereby sign the CLA

recheck

Reviewer Checklist

[ ] I have verified the author checklist is complete (all boxes are checked off).
[ ] I verified the correct issue is linked in the ### Fixed Issues section above
[ ] 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
[ ] I verified the steps for Staging and/or Production testing are in the QA steps section
[ ] 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)
[ ] 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)

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

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

[ ] 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
[ ] I verified proper code patterns were followed (see Reviewing the code)

[ ] 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).
[ ] I verified that the left part of a conditional rendering a React component is a boolean and NOT a string, e.g. myBool && <MyComponent />.
[ ] I verified that comments were added to code that is not self explanatory
[ ] 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.
[ ] I verified any copy / text shown in the product is localized by adding it to src/languages/* files and using the translation method
[ ] I verified all numbers, amounts, dates and phone numbers shown in the product are using the localization methods
[ ] 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.
[ ] 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.
[ ] I verified the JSDocs style guidelines (in STYLE.md) were followed

[ ] If a new code pattern is added I verified it was agreed to be used by multiple Expensify engineers
[ ] I verified that this PR follows the guidelines as stated in the Review Guidelines
[ ] 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)
[ ] I verified all code is DRY (the PR doesn't include any logic written more than once, with the exception of tests)
[ ] 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
[ ] If a new component is created I verified that:

[ ] A similar component doesn't exist in the codebase
[ ] All props are defined accurately and each prop has a /** comment above it */
[ ] The file is named correctly
[ ] The component has a clear name that is non-ambiguous and the purpose of the component can be inferred from the name alone
[ ] The only data being stored in the state is data necessary for rendering and nothing else
[ ] 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)
[ ] 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)
[ ] All JSX used for rendering exists in the render method
[ ] 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

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

[ ] 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

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

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

[ ] 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.
[ ] 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)
[ ] 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.
[ ] 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.
[ ] 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

Mobile Web - Chrome

Mobile Web - Safari

Desktop

iOS

Android

recheck

recheck

@spcheema Is it any chance that you could take a look on IOS issue with this underline? Maybe we can find the reason why IOS is working like that

@spcheema and also please check failing Lint

@narefyev91 I did try to find a solution but unfortunately this is how iOS rendering engine handles text underline on iOS devices. I just test with Swift UI app and result is the same for iPhone & iPad.
Iphone video:
https://github.com/Expensify/App/assets/19812199/a473e2b3-4ba3-4378-a27e-cd913041b9c5
iPad:

@spcheema and also please check failing Lint

Build is now passing. Also this PR does not have any functional change so I can't find any reason to test it against hight traffic account unless you recommend it.

I think we do not really need here high traffic account, i will review the changes and fill checklist and if nothing will pops up we will be good to go!

🚀 Deployed to staging by https://github.com/PauloGasparSv in version: 1.3.24-0 🚀

platform
result

🤖 android 🤖
success ✅

🖥 desktop 🖥
success ✅

🍎 iOS 🍎
success ✅

🕸 web 🕸
success ✅

@spcheema This issue is still reproducible in iOS https://github.com/Expensify/App/issues/19646 picture below

@spcheema This issue is still reproducible in iOS https://github.com/Expensify/App/issues/19646 picture below

Didn't realize this during tests! @spcheema can you create a follow up P.R. to this?

Understood, thanks for the explanation.
@PauloGasparSv I think we can check this one of the checklist if it was expected that iOS was not fixed with this one. Please stop me if I'm wrong.

@PauloGasparSv @isagoico As I discussed with @narefyev91 that currently there is no solution for iOS (iPhone, iPad). It's the way iOS render underline.

So sorry, I forgot that you explained that before finishing the P.R..

@PauloGasparSv I think we can check this one of the checklist if it was expected that iOS was not fixed with this one. Please stop me if I'm wrong.

I agree @isagoico we can check it off!

🚀 Deployed to production by https://github.com/roryabraham in version: 1.3.24-5 🚀

platform
result

🤖 android 🤖
success ✅

🖥 desktop 🖥
failure ❌

🍎 iOS 🍎
failure ❌

🕸 web 🕸
success ✅

🚀 Deployed to production by https://github.com/roryabraham in version: 1.3.24-5 🚀

platform
result

🤖 android 🤖
success ✅

🖥 desktop 🖥
cancelled 🔪

🍎 iOS 🍎
cancelled 🔪

🕸 web 🕸
success ✅


Separate Interface Package?

Does anyone share my desire to separate the interfaces here into their own
package?
I feel like I want to be able to write packages that required something like
zendframework/permissions-acl-interface rather than the whole implementation.
This way, for example, I could write an authentication package where identity
objects implement RoleInterface, or make some domain package where objects
implement ResourceInterface to facilitate integration but not require
installation of Zend\Permissions\Acl if one desires some alternative
implementation. Something similar to what is done with Aura\Payload and
Aura\Payload_Interface.
Thoughts?

zend-permissions-acl is meant to provide:

Basic interfaces for representing access control lists
A basic, extendable system implementing ACLs

We do not currently see the value in separating them, particularly considering that the LOC amount to only ~1k lines, with only ~300 lines of logic. Removing the implementation just increases the number of dependencies for those that do want the implementation at this point.
We may revisit this in the future (we separated interface-providing packages from implementations in Expressive), but for now, we have no plans to do similarly with the component packages.

Thanks for the response!
Keep up the excellent work!


Allow re-starting a graph node on a new chain.

Do you want to request a feature or report a bug?
Feature
What is the current behavior?
I'm running a private chain locally that I restart sometimes. After a restart, the graph-node complains that the state of the chain is not the same as it was previously. To remediate that I have to clear the docker volumes and restart the node.
If the current behavior is a bug, please provide the steps to reproduce and if possible a minimal demo of the problem.
What is the expected behavior?
It would be super helpful to have an option that, when specified, simply starts the graph node and start indexing on the new chain even if the state does not match with the previous registered one.

This might be solved with an env-var/configuration variable. Thanks for the report @xenoliss! Good point.


[Feature] Add an address list

Hey Andrii(@pasichDev),
It would be nice to have an address list so we don't have to copy paste outgoing addresses all the time.
Cheers,
Gus

Hi @gcarreno what do you mean?

Hi, @gcarreno !
Resolved: Add a contract book and save the latest payments.
You can add addresses and owner information to the contact book.
@pasichDev

Jey Andrii(@pasichDev),
That's bloody awesome!!!
As usual, you demonstrate the professionalism that you have!!!
Cheers,
Gus

@gcarreno It's settled! So I'm closing this issue!

Hey Andrii(@pasichDev)
Awesome!! Thanks!! :people_hugging:
Cheers,
Gus


Truly disable Glyphicons (w/styles)

Disables (toggles) glyphicons by commenting the sass @import, saving some kilobytes of unused space.

thanks


TCA Hang on try_lock()

Context
We use a TCA9548a multiplexer in the CubeSat as a means of dividing up our i2c1 bus into multiple I2C busses for communicating with the sensors on each face of the satellite. With over 20 I2C devices in a fully built satellite, without the TCA we would be up a creek without a paddle in terms of efficiently fitting them all onto one bus. Not only would there be address collisions, the entire bus becomes extremely fragile as the failure of only one device could block every other device from using the bus.
Description of the Issue
What appears to be a known but unsolved issue with the CircuitPython TCA9548a library is that if something causes the try_lock() function to error out, an unhandled exception can cause the rest of your code to freeze until interrupted with a user input.
Here is an example of what that error message may look like. When this happens the code completely freezes and does not advance. The code that causes this to happen generally looks like the following:
try:
    tca.channel[0].try_lock()
    ...
except Exception as e:
    print(e)
    ...

It appears that the unhandled OSError is what is causing the code to freeze up.

My attempt to hot fix this is to specifically catch the OSError like so:
            try:
                self._scan_single_channel(channel, channel_to_face)
            except OSError:
                self.error_print("[ERROR][TCA] TCA try_lock failed. TCA may be malfunctioning.")
                self.hardware["TCA"] = False
                return
            except Exception as e:
                self.error_print(f"[ERROR][FACE]{traceback.format_exception(e)}")

It seems to work, but we should leave this issue open for more testing to verify.

This does not seem to fix the issue, for whatever reason even if the TCA try_lock failure is caught by an exception it still hangs the entire software until a WDT reset:

Actually it looks like catching the try_lock with the OS error does work! When the camera was added to PySquared though it added an edge case where we could hang on the try_lock in the camera init.
#38 adds a try / except to fix this.

I was rifling through the tca9548a.py and found this!
    def try_lock(self) -> bool:
        """Pass through for try_lock."""
        while not self.tca.i2c.try_lock():
            time.sleep(0)
        self.tca.i2c.writeto(self.tca.address, self.channel_switch)
        return True

I think this damn infinite loop is what is causing the Cube Killer bug!!!!

This is possibly fixed in Commit 6f50227

Closing this for now, as it does indeed appear to be fixed!


Cannot use "page" route param in MapControllerRoute when Razor Pages enabled

Describe the bug
Hello. When i enable Razor Pages in my ASP.NET Core 3.1 project all routes with param named "page" stop working.
To Reproduce
https://github.com/pogromistik/PageParamBug - here is repo with reproduction example.
There is two methods in HomeController:
public IActionResult Foo(int page)
{
    return Ok(page);
}

public IActionResult Bar(int currentPage)
{
    return Ok(currentPage);
}

and mapping in Startup.cs:
endpoints.MapControllerRoute("test", "home/foo/{page:int}", new {controller = "Home", action = "Foo"});
endpoints.MapControllerRoute("test2", "home/bar/{currentPage:int}", new {controller = "Home", action = "Bar"});

Start application and open this two urls:
https://localhost:5001/home/foo/4
https://localhost:5001/home/bar/4
You will see 4 on both pages.

Uncomment services.AddRazorPages(); and endpoints.MapRazorPages(); in Startup.cs, restart and open those urls again.
https://localhost:5001/home/bar/4 will show 4.

https://localhost:5001/home/foo/4 will return error 404.

Further technical details

ASP.NET Core version 3.1.0
Include the output of dotnet --info

dotnet --info
Пакет SDK для .NET Core (отражающий любой global.json):
 Version:   3.1.100
 Commit:    cd82f021f4

Среда выполнения:
 OS Name:     Windows
 OS Version:  10.0.18362
 OS Platform: Windows
 RID:         win10-x64
 Base Path:   C:\Program Files\dotnet\sdk\3.1.100\

Host (useful for support):
  Version: 3.1.0
  Commit:  65f04fb6db

.NET Core SDKs installed:
  2.1.500 [C:\Program Files\dotnet\sdk]
  2.2.100 [C:\Program Files\dotnet\sdk]
  3.0.100 [C:\Program Files\dotnet\sdk]
  3.1.100 [C:\Program Files\dotnet\sdk]

.NET Core runtimes installed:
  Microsoft.AspNetCore.All 2.1.6 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
  Microsoft.AspNetCore.All 2.2.0 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
  Microsoft.AspNetCore.App 2.1.6 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 2.2.0 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 3.0.0 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 3.1.0 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.NETCore.App 2.1.6 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 2.2.0 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 3.0.0 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 3.1.0 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.WindowsDesktop.App 3.0.0 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
  Microsoft.WindowsDesktop.App 3.1.0 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]

To install additional .NET Core runtimes or SDKs:
  https://aka.ms/dotnet-download

.NET CLI 3.1.0

Thanks for contacting us.
This is by-design. You can read more about the reserved keywords at https://github.com/aspnet/AspNetCore/wiki/MVC-Reserved-Keywords

Thanks


Race condition in zk_loop and KazooClient destructor

I hit the following from time to time on Ubuntu 14.04 while never hit this on OSX 10.9.4
Exception in thread Thread-3 (most likely raised during interpreter shutdown):
Traceback (most recent call last):
File "/usr/lib/python2.7/threading.py", line 810, in __bootstrap_inner
File "/usr/lib/python2.7/threading.py", line 763, in run
File "/opt/simcloud/src/third_party/build/lib/python2.7/site-packages/kazoo/protocol/connection.py", line 472, in zk_loop
File "/usr/lib/python2.7/threading.py", line 585, in set
File "/usr/lib/python2.7/threading.py", line 406, in notifyAll
<type 'exceptions.TypeError'>: 'NoneType' object is not callable
There is a race condition in which if one doesn't call KazooClient.close() explicitly and KazooClient instance, its members, and other static instances may be destructed before the zk_loop exits.  In the case in which some instances of KazooClient are destructed before zk_loop exit, the above errors would be resulted.
The resolution would be to call KazooClient.stop() and close() explicitly within its destructor which doesn't exist yet.

We are on RHEL7 and are facing this issue. Do we have any timelines for fixing this or any workarounds?

A PR was merged to address this, does that fix it?

Closing this as I'm not clear if it still applies.


merge from arlac77/template-arlac77-github,arlac77/template-esm-only,arlac77/template-nginx,arlac77/template-pacman,arlac77/template-systemd

package.json

chore(scripts): add c8 -x 'tests/**/' --temp-directory build/tmp ava --timeout 2m tests/.mjs && c8 report -r lcov -o build/coverage --temp-directory build/tmp (scripts.cover)

Pull Request Test Coverage Report for Build 3914

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

Totals

Change from base Build 3911:
0.0%

Covered Lines:
72

Relevant Lines:
87

💛  - Coveralls


Add twisted D-man to floating point spec

Found another lovely D-Man. Author is again meiz_sandwich

I think this fits well to the "twisted" behavior of floating points (you can also see the D-Man as a 8), but I am open for better suggestions ;-)

I don't think it works.

I don't think it works.

If someone has a better use for this graphic, please go ahead ;-)


Allow api response with 'token' accepted same as access_token

Pull Request Test Coverage Report for Build 1043

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

Totals

Change from base Build 1038:
0.0%

Covered Lines:
0

Relevant Lines:
0

💛  - Coveralls

@anvox @jonspalmer This would be covered by #518 right?

We just need to get #518 logic up into master.  Also need a new release from 1-4-stable

@Alice-Qiu please see #518 for the new way to do this on the 1-4-stable branch.  If you have already upgraded to master we will be porting the same fix to master soon.

@Alice-Qiu alternatively there is another workaround that kist got merged into master.  See #516

We still need to port #518 to master branch.  Leaving this PR open as a reminder.

Codecov Report

Merging #519 (e05f5f1) into master (c6a326b) will not change coverage.
The diff coverage is 100.00%.

@@           Coverage Diff           @@
##           master     #519   +/-   ##
=======================================
  Coverage   89.66%   89.66%
=======================================
  Files          15       15
  Lines         445      445
=======================================
  Hits          399      399
  Misses         46       46

Impacted Files
Coverage Δ

lib/oauth2/access_token.rb
95.77% <100.00%> (ø)

lib/oauth2/client.rb
93.33% <100.00%> (ø)

:mega: Codecov can now indicate which changes are the most critical in Pull Requests. Learn more


'count' in elasticsearch has some problem

Entity:
`
public class Category {
@Id
public String id;

@Required
@MinSize(3)
public String name;

@Required
@MinSize(3)
public String code;

}
`
Create 50 rows of data:
    for(int i = 1; i <= 50; i++) {             Category ctg = new Category();             ctg.id = ""+i;              ctg.name = UUID.randomUUID().toString;              ctg.code = "abc";              em.persist(ctg);          }
Count 1:
    Query q = em.createQuery("select count(ctg) from Category ctg where ctg.code = 'abc'");     String count= q.getSingleResult().toString();     System.out.println("count="+count);
print: count=50, works right.
Count 2:
    Query q = em.createQuery("select count(ctg.name) from Category ctg where ctg.code = 'abc'");     String count= q.getSingleResult().toString();     System.out.println("count="+count);
print: count=801, wrong!!!
remove all datas, and create another 50 rows of data like this:
    for(int i = 1; i <= 50; i++) {             Category ctg = new Category();              ctg.id = UUID.randomUUID().toString;             ctg.name = 'test name ' + i;             ctg.code = "abc";             em.persist(ctg);         }
Count 3:
    Query q = em.createQuery("select count(ctg) from Category ctg where ctg.code = 'abc'");     String count= q.getSingleResult().toString();     System.out.println("count="+count);
print: count=787, wrong!!!
Count 4:
    Query q = em.createQuery("select count(ctg.name) from Category ctg where ctg.code = 'abc'");     String count= q.getSingleResult().toString();     System.out.println("count="+count);
print: count=150, wrong!!!
Please check and fix it, thanks!

@dreamingo88
Hey,
Are you starting elasticsearch from Kundera (embedded mode) or deployed externally? Also, How are you deleting the data from elasticsearch.. manually by deleting data directory or through Kundera?
-Karthik

@karthikprasad13
Hi,
I deployed externally.
I deleting the data from elasticsearch (with plugin head).

Is there any news about this problem?

@dreamingo88
We are almost done with Kundera-Elasticsearch update (Elasticsearch 2.3). We will try to replicate this issue  with this latest version.
-Dev

@dreamingo88
Elasticsearch update is added to the trunk. Can you please build code from the trunk and try to replicate your issues now.
You can clone source code using :
git clone https://github.com/impetus-opensource/Kundera.git

-Dev

@dreamingo88
Could you please try this with Kundera 3.5
-Dev

@devender-yadav
Sorry for delayed reply.
I will try soon.

@devender-yadav
Hi, I have test it today, It works right.
Thank you!
You can close this issue.

@dreamingo88
By default, indexes in elasticsearch are not updated immediately after insertion of data. So count query just after insertion of data may lead to wrong results.
We added a property to update indexes immediately. If  user has a usecase to search on newly added data immediately after addition of it, this property can be used.
em.setProperty("es.refresh.indexes", true);

https://github.com/impetus-opensource/Kundera/issues/882 is related issue.
Check testcase for more details.
This will be available in Kundera 3.6 (to be released in  next week).
-Dev


nix: nixBuildPackage’s depRoots are costly on the store

I recently ran out of inodes on my /nix store partition, and I think nixBuildPackage’s depRoot derivations are the cause.
Status quo
Consider a module dependency graph A ← B ← C. Right now, nixBuildPackage will create 6 store paths, roughly like this:
/nix/store/…-A-depRoot:
  (empty)
/nix/store/…-A:
  A.olean
/nix/store/…-B-depRoot:
  A.olean → /nix/store/…-A/A.olean
/nix/store/…-B:
  B.olean
/nix/store/…-B-depRoot:
  A.olean → /nix/store/…-A/A.olean
  B.olean → /nix/store/…-B/B.olean
/nix/store/…-C:
  C.olean

So for each module, there is a -depRoot derivation that contains a symlinks to all the olean’s of its (transitive) dependencies. So if we have a dependency chain of length n, we’ll add O(n²) symlinks to the store.
The problem
These symlinks are small, but still take up considerable filesystem resources.
Moreover, these depRoot store paths don’t seem to be that useful: Mod-depRoot is only re-used when Mod changes. For all unchanged modules, the -depRoot path is not used again. And for all modules whose dependencies change, the -depRoot is not used either.
Moreover, having two store paths for each module doubles the time spent on querying nix caches when building.
A possible fix
Given that analysis (if it turns out to be accurate), it seems reasonable to just not persist the depRoot store path used when building a module, and instead just create it temporarily when building the module.
It’s still useful to have such a store path for the overall library (the foo.modRoot output).
Extension: lean-deps file
Right now, the /nix/store/…-C store path does not depend on anything. Is it ever useful to have C.olean without A.olean and B.olean? It might be prudent to add a text file lean-deps to /nix/store/…-C that lists the (direct) dependencies, so that nix knows about that relation.
Also, the derivation build to build, say, Mathlib-depRoot (or, with this proposal, Mathlib) is rather large (1.3MB), because it lists all it’s dependencies, twice, in deps and depRoots, and then again twice in inputDrvs. I don't have evidence, but I wonder if this might be rather costly in terms of nix evaluation etc. Probably the derivation doesn’t have to mention the indirect dependencies, and could use the lean-deps text file to list all the dependencies.
As before, this is not highly critical, but I wanted to write it down. If @Kha roughly agrees with the analysis and conclusion, I might give it a try at some point.

Yes, this is definitely something I've considered changing before. I don't remember all that many details but one weak reason was that changing it would make nix develop on a module derivation less convenient.

Is it ever useful to have C.olean without A.olean and B.olean?

Not right now, but with a module system that would change.

I wonder if this might be rather costly in terms of nix evaluation

Heh, I would not be surprised. We're taking Nix out of its comfort zone in various ways here.


test cholesky_solve ... FAILED

Sometimes this test fails
https://app.wercker.com/termoshtt/ndarray-linalg/runs/test-openblas/59f195128e888f0001cf3ef5?step=59f19584791109000146172c

If it helps, this is an instance problem that always fails. Copied from the cholesky test, but without randomness:

use ndarray::{arr1,arr2};
#[test]
fn cholesky_solve_fail() {

    let a: Array2<f64> = arr2(&[[2.7518138512052546, 0.0, 0.0],
                                    [-3.0030534432813334, 0.5503895871967794, 0.0],
                                    [0.0, 0.0, 0.4472135954999579]]);
    let x: Array1<f64> = arr1(&[-0.3633966736383765772089, -9.2503560214093027980198, 0.0]);
    let b = a.dot(&x);
    println!("a = \n{:#?}", a);
    println!("x = \n{:#?}", x);
    println!("b = \n{:#?}", b);
    println!("Solution = \n{:#?}", &a.solvec(&b).unwrap());
    assert_close_l2!(&a.solvec(&b).unwrap(), &x, 1e-9);
    assert_close_l2!(&a.solvec_into(b.clone()).unwrap(), &x, 1e-9);
    assert_close_l2!(&a.solvec_inplace(&mut b.clone()).unwrap(), &x, 1e-9);
    assert_close_l2!(&a.factorizec(UPLO::Upper).unwrap().solvec(&b).unwrap(), &x, 1e-9);
    assert_close_l2!(&a.factorizec(UPLO::Lower).unwrap().solvec(&b).unwrap(), &x, 1e-9);
    assert_close_l2!(&a.factorizec(UPLO::Upper).unwrap().solvec_into(b.clone()).unwrap(), &x, 1e-9);
    assert_close_l2!(&a.factorizec(UPLO::Lower).unwrap().solvec_into(b.clone()).unwrap(), &x, 1e-9);
    assert_close_l2!(&a.factorizec(UPLO::Upper).unwrap().solvec_inplace(&mut b.clone()).unwrap(), &x, 1e-9);
    assert_close_l2!(&a.factorizec(UPLO::Lower).unwrap().solvec_inplace(&mut b.clone()).unwrap(), &x, 1e-9);
}

Output:
---- cholesky_solve_fail stdout ----
	a =
[[2.7518138512052546, 0.0, 0.0],
 [-3.0030534432813334, 0.5503895871967794, 0.0],
 [0.0, 0.0, 0.4472135954999579]] shape=[3, 3], strides=[3, 1], layout=C (0x1)
x =
[-0.3633966736383766, -9.250356021409303, 0.0] shape=[3], strides=[1], layout=C | F (0x3)
b =
[-1.0, -4.0, 0.0] shape=[3], strides=[1], layout=C | F (0x3)
Solution =
[-0.36339667363837663, -7.26757935296819, 0.0] shape=[3], strides=[1], layout=C | F (0x3)
thread 'cholesky_solve_fail' panicked at 'called `Result::unwrap()` on an `Err` value: 0.21418077766308938', libcore/result.rs:945:5
note: Run with `RUST_BACKTRACE=1` for a backtrace.

First (and third) component are OK though.

@davenza Thanks for taking a look at this. This particular example fails because a is asymmetric. (Solving with Cholesky decomposition requires a Hermitian (or real symmetric) positive definite coefficient matrix.) Did you get that a matrix from running the cholesky_solve test (which calls random_hpd to generate a random Hermitian positive-definite matrix), or did you create it yourself? In other words, is random_hpd the real problem here?
This does bring up another question: In this particular example, a bad value is returned since a is asymmetric. Should we explicitly check if a is Hermitian and positive definite, and if not return an Err?

@jturner314 Thanks, I didn't notice the symmetric requirement. I was trying to do a different thing, and I think I misunderstood the documentation.
I had a covariance matrix (not created with random_hpd), let's call U:
[7.572479471685095, -8.263844061131207, 0.0]
[-8.263844061131206, 9.321258680898515, 0.0]
[0.0,                              0.0,                             0.2]
I found the lower cholesky decomposition U = LL^T. L is the matrix that I used in the code above:
[2.7518138512052546, 0.0, 0.0]
[-3.0030534432813334, 0.5503895871967794, 0.0]
[0.0, 0.0, 0.4472135954999579]
Then, I tried to solve Lx = [1 4 0] using solvec.

However, related with the problem: while I was doing some cargo test runs, I sometimes had errors. I could try to reproduce the errors again, printing a failing matrix if it is interesting to you.

Fwiw, if you need both the triangular factor (L matrix) and a solution (with .solvec()), you can factor once with .factorizec() or .factorizec_into() to get a CholeskyFactorized instance. You can then solve, take the inverse, take the determinant, get the lower/upper triangular factor, etc., using the CholeskyFactorized instance without having to factor the matrix multiple times.
Regarding the test failures: I think they're due to floating-point errors. (In the cases I've observed the tests failing, the errors have always been pretty small. If you see a case where the error is large, please post it here.) One idea to minimize issues associated with floating-point errors in the tests is to throw out randomly-generated matrices that are ill-conditioned (and generate new ones that are well-conditioned), but I haven't had a chance to try this.

In two of my executions of the cholesky_solve() test, the test failed with this matrices:
 Fail 1
---- cholesky_solve stdout ----
a =
[[0.33597532169190203, -0.8317558045767911, -0.33804679493344636],
[-0.8317558045767911, 7.026626194373293, 5.091368342750945],
[-0.33804679493344636, 5.091368342750945, 6.387675256291089]] shape=[3, 3], strides=[3, 1], layout=C (0x1)
x =
[-1.3640677969149184, 1.4365643322080148, -0.2864128482272794] shape=[3], strides=[1], layout=C | F (0x3)
a =
[[3.147686, -0.6140107, -1.1712251],
[-0.6140107, 3.554442, -0.27945665],
[-1.1712251, -0.27945665, 0.51092684]] shape=[3, 3], strides=[3, 1], layout=C (0x1)
x =
[0.2852047, -0.2701597, -0.70091474] shape=[3], strides=[1], layout=C | F (0x3)
thread 'cholesky_solve' panicked at 'called Result::unwrap() on an Err value: 0.0027820447', libcore/result.rs:945:5``

 Fail 2 (with backtrace)
---- cholesky_solve stdout ----
a =
[[1.2219888536170944, -1.3044421701103923, 1.0844884489891133],
[-1.3044421701103923, 1.622040998971165, -0.25782460724863565],
[1.0844884489891133, -0.25782460724863565, 4.503214907761472]] shape=[3, 3], strides=[3, 1], layout=C (0x1)
x =
[2.3896768802521486, -0.5822467373409934, 1.1002035853153536] shape=[3], strides=[1], layout=C | F (0x3)
a =
[[5.918905, 4.401211, 1.5132039],
[4.401211, 4.052539, -0.07915869],
[1.5132039, -0.07915869, 2.2470446]] shape=[3, 3], strides=[3, 1], layout=C (0x1)
x =
[-0.01866009, -0.6332641, -0.04560638] shape=[3], strides=[1], layout=C | F (0x3)
thread 'cholesky_solve' panicked at 'called Result::unwrap() on an Err value: 0.00379905', libcore/result.rs:945:5
note: Some details are omitted, run with RUST_BACKTRACE=full for a verbose backtrace.
stack backtrace:
0: std::sys::unix::backtrace::tracing::imp::unwind_backtrace
at libstd/sys/unix/backtrace/tracing/gcc_s.rs:49
1: std::sys_common::backtrace::_print
at libstd/sys_common/backtrace.rs:71
2: std::panicking::default_hook::{{closure}}
at libstd/sys_common/backtrace.rs:59
at libstd/panicking.rs:380
3: std::panicking::default_hook
at libstd/panicking.rs:390
4: std::panicking::rust_panic_with_hook
at libstd/panicking.rs:576
5: std::panicking::begin_panic
at libstd/panicking.rs:537
6: std::panicking::begin_panic_fmt
at libstd/panicking.rs:521
7: rust_begin_unwind
at libstd/panicking.rs:497
8: core::panicking::panic_fmt
at libcore/panicking.rs:71
9: core::result::unwrap_failed
at /checkout/src/libcore/macros.rs:23
10: <core::result::Result<T, E>>::unwrap
at /checkout/src/libcore/result.rs:782
11: cholesky::cholesky_solve
at tests/cholesky.rs:146
12: <F as alloc::boxed::FnBox>::call_box
at libtest/lib.rs:1462
at /checkout/src/libcore/ops/function.rs:223
at /checkout/src/liballoc/boxed.rs:788
13: __rust_maybe_catch_panic
at libpanic_unwind/lib.rs:102

It seems that both failures happen with the f32 type and due to floating-point errors, as you said.

One idea to minimize issues associated with floating-point errors in the tests is to throw out randomly-generated matrices that are ill-conditioned

It will be a right way. Since the implementations of LAPACK are trusted, we do not have to check the singular cases.


Spotify error

What version of Music Assistant has the issue?
2.3.0b17
What version of the Home Assistant Integration have you got installed?
2024.8.0
Have you tried everything in the Troubleshooting FAQ and reviewed the Open and Closed Issues and Discussions to resolve this yourself?

[X] Yes

The problem
After this error stop play song in playlist:
2024-09-02 18:20:17.365 ERROR (MainThread) [music_assistant.streams.media_stream] Failed to stream spotify://track:1qeV7JbH1rv3ygF6AhZ5x3 - error: 1 Traceback (most recent call last):   File "/usr/local/lib/python3.12/site-packages/music_assistant/server/helpers/audio.py", line 192, in _feed_stdin     async for chunk in self.audio_input:   File "/usr/local/lib/python3.12/site-packages/music_assistant/server/providers/spotify/__init__.py", line 600, in get_audio_stream     raise AudioError( music_assistant.common.models.errors.AudioError: Failed to stream spotify://track:1qeV7JbH1rv3ygF6AhZ5x3 - error: 1
How to reproduce
Playing songs.
Music Providers
Spotify
Player Providers
Snapcast
Full log output
music-assistant (1).log
Additional information
No response
What version of Home Assistant Core are your running
2024.8.2
What type of installation are you running?
Home Assistant OS
On what type of hardware are you running?
Windows

Yes I have seen this.

please test if this is fixed in 2.3.0b18

b19 same issue.

I simulated it in a way that I pressed 3-4 times in a row the next song from the playlist on Spotify. YT MUSIC is fine.
music-assistantb19.log

This is a snapcast issue (your log is full of issues with snapcast!) - not spotify

Im running snapserver in MA only.

I found this log today while playing. Yes it looks like two Snapcast servers are running. But in reality only one is running in MA.
2024-09-05 08:50:44.359 WARNING (MainThread) [music_assistant.snapcast] {'code': -32603, 'data': "bind: Address in use [system:98 at /usr/include/boost/asio/detail/reactive_socket_service.hpp:161 in function 'bind']", 'message': 'Internal error'}

MA puts an extreme load on the CPU and RAM over time.

I'm also seeing this without snapcast, just using the Chromecast player provider.

I found this log today while playing. Yes it looks like two Snapcast servers are running. But in reality only one is running in MA.

Something else on your network is on this address then. You need to resolve that first.

Combination of MA version 2.3.0b17 and YT music and Snapcast i have log without any issue and without put load on CPU and RAM after 9hours continuous playback. I will send full log later after end of day in building.

I forgot to mention that I completely deleted Spotify from the providers, before that I only had it disabled.

Hey, I have this issue too. Only Chromecast provider.
Logs:
2024-09-06 18:24:04.293 ERROR (MainThread) [music_assistant.streams.media_stream] Failed to stream spotify://track:0SWgf5CW30gZB9zlB8E6V - error: 1
Traceback (most recent call last):
File "/usr/local/lib/python3.12/site-packages/music_assistant/server/helpers/audio.py", line 192, in _feed_stdin
async for chunk in self.audio_input:
File "/usr/local/lib/python3.12/site-packages/music_assistant/server/providers/spotify/init.py", line 601, in get_audio_stream
raise AudioError(
music_assistant.common.models.errors.AudioError: Failed to stream spotify://track:0SWgf5CW30gZBzZlB8E6V - error: 1
2024-09-06 18:24:09.829 ERROR (MainThread) [music_assistant.streams.media_stream] Failed to stream spotify://track:0AIcr2wW0FiHkNS82AwLE9 - error: None
Traceback (most recent call last):
File "/usr/local/lib/python3.12/site-packages/music_assistant/server/helpers/audio.py", line 192, in _feed_stdin
async for chunk in self.audio_input:
File "/usr/local/lib/python3.12/site-packages/music_assistant/server/providers/spotify/init.py", line 601, in get_audio_stream
raise AudioError(
music_assistant.common.models.errors.AudioError: Failed to stream spotify://track:0AIcr2wW0FiHkNS82wLE9 - error: None

Also this:
2024-09-06 18:32:15.961 ERROR (MainThread) [music_assistant.streams.media_stream] Failed to stream spotify://track:0AIcr2wW0FiHkNS82AwLE9 - error: None
Traceback (most recent call last):
File "/usr/local/lib/python3.12/site-packages/music_assistant/server/helpers/audio.py", line 192, in _feed_stdin
async for chunk in self.audio_input:
File "/usr/local/lib/python3.12/site-packages/music_assistant/server/providers/spotify/init.py", line 601, in get_audio_stream
raise AudioError(
music_assistant.common.models.errors.AudioError: Failed to stream spotify://track:0AIcr2wW0FiHkNSAwLE9 - error: None
I see the music title appearing on my TV but then it stops playing and empties the queue.

So after a full day of playing music in the combination mentioned below the log is clean with no errors. Please see the log stating that it started playing today 2024-09-06 at 8:43 and finished at 20:39, completely without any problems.
logb17.log

Combination of MA version 2.3.0b17 and YT music and Snapcast i have log without any issue and without put load on CPU and RAM after 9hours continuous playback. I will send full log later after end of day in building.

For those reporting the error code 1 you need to advise what server version you are running. If you aren’t on beta 19 or 2.2.3 then you need to update

Got the error just now, version 2.3.0b19
2024-09-06 19:40:58.815 ERROR (MainThread) [music_assistant.streams.media_stream] Failed to stream spotify://track:5N8KsYJ8IEMQVw33JvytW8 - error: 1 Traceback (most recent call last):   File "/usr/local/lib/python3.12/site-packages/music_assistant/server/helpers/audio.py", line 192, in _feed_stdin     async for chunk in self.audio_input:   File "/usr/local/lib/python3.12/site-packages/music_assistant/server/providers/spotify/__init__.py", line 601, in get_audio_stream     raise AudioError( music_assistant.common.models.errors.AudioError: Failed to stream spotify://track:5N8KsYJ8IEMQVw33JvytW8 - error: 1

For those reporting the error code 1 you need to advise what server version you are running. If you aren’t on beta 19 or 2.2.3 then you need to update

Latest as of the time of writing, which is 2.2.3. Installed it yesterday.

Please test again when beta 20 or later is released

Beta 20:has been released

Just tested out a bit, the error is no longer happening which is great! The only issue now is that the playlist will just pause itself after a while (think I got through maybe 5-7 songs before it paused itself again). If I click play it resumes fine though, so maybe something to do with the substitute track being pulled in?

Those are different problems. Review the similar open issues and if yours is not the same then open a new one.


Fix go module issue

When building LND docker image I got the following error when populating go modules
go<EMAIL_ADDRESS>unknown revision cdab10132e8c

The commit in question cdab10132e8c, doesn't seem to be part of the master branch so I suspect that's why it's failing
Updating the revision of ltcd resolved the issue
Fixes #2394.

The commit in question cdab10132e8c, doesn't seem to be part of the master branch so I suspect that's why it's failing

I was just looking at the master branch and couldn't find it. I thought I was tripping. This make sense now.
You can likely close #2260 too.
Is there no concern bumping from July 2018 to Jan 19?

Yeah looks like they force pushed to their main branch which removed that commit all together. We may want to consider just vendoring all our deps to avoid funky situations like this in the future.

Is there no concern bumping from July 2018 to Jan 19?

No, there's been no major changes since then. I originally made ltcd, and since then the Litecoin team has taken it over, re-making the fork as it had drifted a bit from btcd.

confirmed, this resolved my issue

this resolved my issue as well, thank you


[SPARK-38139][PYTHON][ML][TESTS] Adjust tolerance in ml.recommendation.ALS doctest

What changes were proposed in this pull request?

This PR reduces precision of the result in pyspark.ml.recommendation.ALS doctest to four decimal digits.
Why are the changes needed?

In certain configurations, ALS consistently converges to value slightly below  0.69291, causing repeated test failures.
Does this PR introduce any user-facing change?

No.
How was this patch tested?

Existing tests, executed with configuration where this test normally fails.

Merged to master.


specify stakeholder need for DSO astrophotographer

as per https://github.com/Mach30/m30ml#stakeholder-need

Blocked by #12, as it should reference it


Water bodies with tag landuse=reservoir

In OSM data, this is a a somewhat-but-not-really deprecated way to describe (among others) lakes that are used for controlled water storage: http://wiki.openstreetmap.org/wiki/Tag:landuse=reservoir
The VectorTiles should reflect this tag usage and (maybe unless covered=yes is present) treat this similar to a normal lake.
Example:
http://www.openstreetmap.org/way/7997604
= http://maps.stamen.com/watercolor/#17/51.29759/12.40117
= https://tangrams.github.io/carousel/?refill#17/51.29759/12.40117

Implemented - for the next release. Actually the landuse=reservoir should also be tagged natural=water then it would already be rendered. So it is a tagging mistake we need to handle (that happens pretty often).

The VectorTiles should reflect this tag usage and (maybe unless covered=yes is present) treat this similar to a normal lake.

I exclude covered reservoirs.


Should understand -d param

I expected pgcli to understand all the params of psql, including -d/--dbname for database name. It would be a nice tweak if it could work as a drop in for psql as far as possible.

Yes it should. I'll add that in.
Thank you!


Add support for text protocol

Hello,
Any idea when this project can support the text protocol ? twemproxy is very popular and unfortunately is supporting only text protocol.
Silviu

Hi @silviucpp,
I started working on ascii protocol support. I'll probably finish it this weekend...
https://github.com/lpgauth/anchor/tree/ascii

Hello,
Any idea when you will have an working version using ascii protocol ?
Silviu

@silviucpp turns out it's a bit more complicated then I expected since the protocol is not 100% compatible... I'm almost done a first version I just need to clean it up. Probably by end of week I'll have a fully functional branch.

Hello,
I don't want to stress you but your project seems for me one of the most clean driver for memcache in erlang :) For this reason I want to integrate it into my projects.. Do yo have any news on the ascii protocol which unfortunately for me is the one I need..
Silviu

Hi, I've decided not to support ASCII protocol. The interface is too different to support along side the binary protocol without major architectural changes.


make compatible with java 1.6

fixes #5 , Everything built again with java 1.6, working as expected

Great, thanks!


Draft: Updates to modernize component

Changes

Linting using HA Core dev tooling
Added all the types
Updated to use Standard HA classes / enums
Swapped to _attr_media_title style attributes
Reduced duplicate code form MediaPlayerEntity class.
Swapped to .get() when pulling data from responses so that we don't error on key not found.
Swapped to /api/system/status as this endpoint is always active even with FPP Daemon is offline.
Added _base_url

Changed name to FPP, revert these if you dont wan't that change.
TODO

Build API client for FPP
Swap to async
Swap from requests to aiohttp -> from homeassistant.helpers.aiohttp_client import async_get_clientsession
Enable UI Config
Leverage SSPS/easyconfig to pull _fpp from mdns for auto config using https://developers.home-assistant.io/docs/network_discovery/

Thank you for your work, I will check your corrections in the near future, and if everything works as it should, I will accept them

Thank you for your work, I will check your corrections in the near future, and if everything works as it should, I will accept them

Feel free to make changes to merge request before accepting.
I've been looking at the fpp and xlights code for how they automatically search for the fpp clients. Seems like some mdns, bonjour, and custom multicast packets.
Would be awesome to work our way to ui setup, even if it's just setting ips and names.

Thank you for your work, I will check your corrections in the near future, and if everything works as it should, I will accept them

Feel free to make changes to merge request before accepting.
I've been looking at the fpp and xlights code for how they automatically search for the fpp clients. Seems like some mdns, bonjour, and custom multicast packets.
Would be awesome to work our way to ui setup, even if it's just setting ips and names.

I had an idea to do an automatic search for instances, but I still couldn't figure out how to do it correctly, about configuring it from the interface, I'll try to do it, but I haven't done it yet, and this is generally my work on integrations

@zackbcom I worked hard on the integration, and added a setting from the interface to it, and also started working on automatic search, but so far this is not clear to me, I'll deal with switching the system to asynchronous mode a little later, since I already figured out how to do this when I made these settings, if you don't have more experience could take a look, maybe there's something I did wrong https://github.com/Aleks130699/ha-fpp/discussions/12


[Entitas:] Modules / Packs / Kits

I think that is actually the next big cool feature if I manage to find a solution. I was thinking about Entitas and modules / packs / Kits and how one could tackle this.
The goal
Someone writes a bunch of systems and components, packs them and calls it PathFindingKit or PhysicsKit or AnimationKit. Basically a self contained and tested module that you drop into your game and voila you have PathFinding, Physics or Animation.

Kits most likely come with their own contexts and components, so first of all I have to find a solution for #303  (Support for multiple contexts in ReactiveSystem).

Vision
You download a PathFindingKit. I comes with components, systems and contexts. You install / register this kit somehow with Entitas and declare that your own GameEntity is also a PathFindingEntity (defined in the Kit). Now your GameEntity supports methods like e.AddPath() and things like that.

It's an interesting though which would enable the Entitas community to share Kits which solve certain problems. We basically could create small reusable building blocks and put them together in our games

Awesome idea!!
It reminded me of:

https://github.com/PlayMakerEcosystem
https://hutonggames.fogbugz.com/?W1181

It https://github.com/sschmid/Entitas-CSharp/issues/309 It can help in the dependencies

I gave the whole idea some thoughts which I want to share.
As I see it there are two ways how a Kit can be implemented.

Actor Model approach. (https://en.wikipedia.org/wiki/Actor_model)
A Kit is a self sustained package. It has it's own set of contexts with resulting Matchers and Entity types. It has it's own set of components and systems. As a user we have to instantiate it's context and the root system of the kit and trigger it in our game loop. We interface with the Kit by using the context to create it's entities and set components in it.
Context Extension/Inheritance approach.
A Kit provides base functionality. It defines Components and Systems which we can use by extending our context with it.

Both approaches has complications.
In Actor Model approach we would have to bridge data from our context to the Kits context. Which can lead to tedious mapping code.
In Context Extension approach we will basically end up with multiple inheritance and lots of inefficiencies. Because if Kit A contains 20 components and I extend my context with Kit A I am inheriting all 20 components and my Entity get's 20 more slot's in the underlying array. Even if I use only 3 out of them. As always Pareto principal (https://en.wikipedia.org/wiki/Pareto_principle) applies. Only 20% of the components will be needed by 80% of the users meaning that everyone will put a 80% overhead in there projects by Context Extension approach.
I personally would rather try to tackle the problem of entity mapping. We could introduce a mechanism which a Kit developer could introduce in order to make the mapping automatic. Like for Example provide an interface which my components have to implement in order for the kit to run through an "unknown" entity and extract data which it needs.
So for example Kit has a PositionComponent and it implements a Kit.IPosition interface. If you have your own PositionComponent just let it implement this interface and than you can pass your entity to Kit's context and Kit's component will be able to extract the data.
I believe actor model is much more superior to the inheritance model in simplicity, but than again I am biased :)
<EMAIL_ADDRESS>

First proof of concept!

TL;DR
Currently struggling. I'll probably have to step back and check if there are other solution or try again on the weekend.
If you guys have any suggestions or ideas how to solve this, let me know!
The setup:
I've create a new C# solution with 2 projects

PhysicsKit (name ist just a placeholder)
This project contains 2 components in the namespace PhysicsKit

PositionComponent
VelocityComponent

MyGame project
This console application project contains 1 components and serves as a test project to integrate the PhysicsKit.

I updated the project's Entitas.properties with new Kit syntax. When specifying contexts you can optionally register Kits like this
Entitas.CodeGeneration.Plugins.Contexts = Game: PhysicsKit + OtherKit + YetAnotherKit

The code generator will pick this up and when generating extensions for the Game context it will load and inspect the PhysicsKit and also generate extensions. This works great. You can now write sth like this
var context = new GameContext();
var e = context.CreateEntity();
// SomeComponent from the Game context
e.Some();

// Generated extensions from the Physics Kit. The Game context and the GameEntity can now also use the components from the Kit
e.AddPhysicsKitPosition(4, 5, 6);
e.AddPhysicsKitVelocity(10, 10, 10);

Console.WriteLine("e: " + e);

Console.WriteLine("e.position.x: " + e.position.x);
Console.WriteLine("e.physicsKitPosition.x: " + e.physicsKitPosition.x);

The code generator produces a few new interfaces as well.
PhysicsKitEntity will now implement the new IPhysicsKit interface
PhysicsKitContext will now implement the new IPhysicsKitContexinterface
PhysicsKitMatcher will now implement the new IPhysicsKitMatcherinterface
Matchers are different now, you access them through the context:
context.matcher.physicsKitPosition

This is necessary because in the scope of the PhysicsKit, the PositionComponent might have index 0, but when used as a Kit the index gets remapped ontop of already existing indices and will be another index. Since context.matcher will return an IPhysicsMatcher, it works both in the Kit and in the Game. In the Kit IPhysicsMatcher will be the actual PhysicsMatcher , in the game it will be MyGameMatcher which implements IPhysicsMatcher
This is what I called Phase I. Works great. Done. But:
Phase II is about also using systems from another Kit. So I added a simple MoveSystem to the PhysicsKit project
using Entitas;

namespace PhysicsKit {

    public sealed class MoveSystem : IExecuteSystem {

        readonly IGroup<PhysicsKitEntity> _group;

        public MoveSystem(IPhysicsKitContext context) {
            _group = context.GetGroup(context.matcher.AllOf(
                context.matcher.physicsKitPosition,
                context.matcher.physicsKitVelocity
            ));
        }

        public void Execute() {
            foreach (var e in _group) {
                var p = e.physicsKitPosition;
                var v = e.physicsKitVelocity;
                e.ReplacePhysicsKitPosition(p.x + v.x, p.y + v.y, p.z + v.z);
            }
        }
    }
}

Going back to the MyGame project and using it like this would be the goal
var system = new MoveSystem(context);

The problem:
My current problem is to resolve the casting problems. In theory MyGame context, entity and matchers will implements IPhysicsContext, IPhysicsEntity, IPhysicsMatcher.
Problem 1:
MyGameContexts implements IPhysicsContexts
This was my 1st try in order to pass it to the MoveSystem which requires a IPhysicsContexts in the ctor. But then MyGameContext has to implement all the methods from the IContext<T> interface again, now with T being PhysicsKit additionally to MyGame. This will result in duplicated methods.
E.g. the IContext<T> interface makes you implement TEntity CreateEntity(). By creating a new context new Context<GameEntity> this is already taken care of, but when now implementing IPhysicsKit I need to implement PhysicsKitEntity CreateEntity(). Yet another Kit would require to implement SomeOtherKitEntity CreateEntity()
But obviously I cannot cast and GameEntity to a PhysicsEntity.
I see, the text is already pretty long, so I guess I'll stop here ;)
The short version: I tried casting and implementing different interfaces to resolve the issue, but I'm not there yet. I'll probably have to step back and check if there are other solution or try again on the weekend.
If you guys have any suggestions or ideas how to solve this, let me know!

EntitasKitsTest.zip
Here's the project if anyone want to see the setup. Pretty simple. EntitasKitsTest.sln contains boths projects. Goal: Get rid of compiler errors :) Or find a completely new approach. Go and check the generated code and maybe modify it, e.g. try what happens if GameContext also implements IPhysicsContext...

Seems to me if I'm going through the trouble of telling the code generator what context I want the kit to exist in that the code generator should generate code to integrate it transparently into said context. As an end user of a kit, do I really need to make the distinction at compile-time that a set of components/systems came from a kit?
It makes sense to me that the code generator would generate versions of the kit's systems/components that function/appear the same as systems/components I've authored myself. Otherwise I'm taking on additional mental overhead to use a kit, which is contrary to the reason I'm using a kit in the first place.
Perhaps that means creating kit-authoring-specific types (Context, Entity, Matcher, etc) that can function for testing/building a kit and easily be replaced by the code generator with the end user's types?

Do any of you know tips on how to reuse:

a reactive system in two different game repos?

I tried to make a few Entitas components, systems, and MonoBehaviours that I could reuse between games.  I ran into problems that are related to those discussed above.

The examples of a reactive system hard-code:

the entity class, such as GameEntity.
the context class, such as GameContext.
the context property on the generated contexts object, such as contexts.game.

I can generalize to TEntity and TContext.  Yet the generic system looks verbose and less useful.  With a generic class I cannot operate on components, unless those components have an interface, which is generated if the components exist in multiple contexts.
Or I can specify the entity and context.  Then the code in the library is non-compatible with the code in the specific game, because the library code needs to be generated to function, but the specific game code also needs to generate code, which goes into the specific game's folder.  So the library is always in a broken state.  It can't be tested outside of a game.
Namespacing is important to write library code.  I'm probably doing it wrong, but last I tried, namespaces made awkwardly verbose generated code by prefixing the namespace to the component variables in the context.

Right now Kit feature blockers are:

partial keyword in generated folder
ComponentsLookup indexes
Contexts facade coupling

Solutions could be:

Extension methods
Attribute/reflection during initialization (similar to PostConstructorAttribute in Contexts)
static int initialization for indexes

#407 Entitas.Generic solved these in one way
Could you tell if any changes in this field are expected?

What if Entitas adopts a standard set of contexts (but continues to allow new ones)?

What if Entitas adopts a standard set of contexts (but continues to allow new ones)?

Actually, wait, here's a better idea; what if instead of directly distributing custom systems or components, custom code generators that generate these systems or components are shared instead?  The code generators, to my knowledge, don't care how Entitas is implemented, so this wouldn't require a fundamental rework of Entitas.  Instead, this would require more documentation and guidance for custom code generators.  And, just as importantly, this would require the code generator implementation process to be more streamlined, with less boilerplate required by the user.

I was thinking about a code gen oriented solution to kits recently.

Do tell.

I'm not super advanced in my thinking here, but as Jesse said, the code gen are pretty much walled off from your specific implementation. The idea would be to add a host of new attributes for kits, that would generate things. You could have the cg generate components and systems and even contexts, and the user could have a bit more custom control over the naming / prefixes / suffixes etc with some configs.

This means that instead of talking about how to implement kits, we can now talk about how to improve the usability and documentation of custom code generators.  What do you think, @sschmid?

@sschmid the module/packs/kits idea is something I implemented with flecs modules, where just like you describe, there are a number of reusable  modules that implement a feature, like rendering, collision detection, movement etc. Some of the projects created with these modules are this, this and this.
I'll deposit some things I had to overcome here, in case it's useful for the Entitas design:
One major challenge I had to address was how to order systems the right way. Some systems imported from a module should be executed at the beginning of a frame (like cleanup systems), while others needed to be ran after game logic was processed (collision detection). I addressed this with three mechanisms:

Systems can be assigned to a "phase" (PreUpdate, OnUpdate, PostUpdate, Render etc)
Within a phase systems are executed in the definition order
Modules can import other modules

A second challenge was how to organize modules. I ended up creating separate modules for components and systems. The component modules establish a common interface for doing certain things, like expressing physics, geometry, or even something completely different like an HTTP server. The system modules only implement the systems that use these components. This lets you "easily" plug in different implementations for the same functionality. For example, an application could swap to a different rendering engine by just importing a different rendering system module, while still using the same components module.
A third challenge was how to prevent systems that don't do anything from impacting performance. When importing a systems module there is a good chance that a number of systems won't be used. In a normal application that's ok, since the user has full control, but in a module a user may not have access to the systems. I addressed this in three ways:

The ECS framework automatically removes systems that don't match any entities from the critical path
The application can pass a flags argument into the import statement to include/exclude certain features (for example, I want to import physics, but only for 2D)
The import function returns a struct with handles to the imported systems, which an application can then manually turn on/off

The fourth challenge I faced was more UI related. I have a web dashboard that shows all the loaded systems (similar to the Entitas panel in Unity) and when you import multiple modules, you can get a lot of systems in your UI. Even for a trivial Pong example, I had over 30 systems, most of which weren't doing much. To address this, I added an EcsHidden tag to the framework which can be used to mark "framework" functionality that is not directly related to the application logic. An UI can use this information to automatically hide or flag these systems, so that a user can easily see which systems are "application logic", like this (orange triangles are framework):

Anyway, that's a blurb with some thoughts, hope it is helpful :)


Remove test timings

🚀 Pull Request
Description

Here is some more Iris functionality that I did not know existed, until @pp-mo mentioned it the other day.  Described by the removed comment
https://github.com/SciTools/iris/blob/6eb0401011a8edce51a942a176e2feb06f4b3f09/lib/iris/tests/__init__.py#L940-L946
I tried to run this with unittest discover as the comment recommends, but got errors, particularly from test_pandas.py.  I found that this functionality can be used with pytest -s -v, so if we do want to keep the functionality we should probably document that.  I'm unsure if it can be made to work with pytest-xdist.
In any case, pytest provides its own functionality to tell you the timings of the slowest running tests via the --durations flag, and of course we now have some pytest tests which don't inherit from IrisTest, so won't work with the bespoke functionality unless we go through and add the decorator.
More generally, the more we can simplify these test classes, the better chance we have of eventually ditching unittest altogether.
This functionality was added at #2372.

Consult Iris pull request check list

Thanks @lbdreyer, good spot!  I only grepped the python files.  Now fixed and also rebased to address the whatsnew conflict.  I don't know why the CI isn't running 😕


[5.7] Module aliases override updates

Use alias value defined upstream as a key downstream for overriding and chain them
Add pre-chained aliases to targets when needed and show diags
Resolves rdar://93445417, rdar://93218209

Cherrypicked from https://github.com/apple/swift-package-manager/pull/5585

@swift-ci  smoke test

@swift-ci smoke test


Failed to parse SourceMap: http://localhost:3002/css/sass

I was using this boilerplate and was working very well.
From yesterday, all of a sudden, everytime I run "gulp dev" or "gulp prod", I get this error into my browser (in my chrome console): Failed to parse SourceMap: http://localhost:3002/css/sass.
React logic continues to work, but I have some style serious issues (for example, using Select from react-bootstrap package, the dropdown menu isn't working anymore).
This error also happens on an empty project, reproduced this way:
git clone https://github.com/jakemmarsh/react-rocket-boilerplate
cd in it
npm install
gulp dev

Update: the problem is present only when the project is in development mode "gulp dev". When I run "gulp prod" and serve the build/ folder via an HTTP server (tried with a Python SimpleHTTPServer) the problem isn't there.

This may have been solved by #33, could you get latest and provide an update?

I've created a pull request ( #40 ) that fixes this issue.

Should be fixed in #40


Slovenian translation - Pull request

Hi,
Please, release link for edit Slovenian translation directly on GitHub, without use other translation utulities.
Big thanks,
Jadran Rudec

Hi Marcin,
I send you now updated Slovenian language file for Bulk Crap Uninstaller 5..
Best Regards,
Jadran
V V sob., 12. feb. 2022 ob 13:03 je oseba Marcin Szeniak <
@.***> napisala:

Closed #346 https://github.com/Klocman/Bulk-Crap-Uninstaller/issues/346.
—
Reply to this email directly, view it on GitHub
https://github.com/Klocman/Bulk-Crap-Uninstaller/issues/346#event-6056717916,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AMUTEQRX7EC6MPKUFW2V23LU2ZEABANCNFSM5NZPLZCQ
.
Triage notifications on the go with GitHub Mobile for iOS
https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675
or Android
https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.
You are receiving this because you authored the thread.Message ID:
@.***
com>


update the links for testing tools to vilib

[X] This contribution adheres to CONTRIBUTING.md.

What does this Pull Request accomplish?
Testing Tools were recently updated and as a result the linking in this repo is outdated.  This updates the links to point to an install of the testing tools.
Why should this Pull Request be merged?
New pulls of this repo + testing tools will require this relinking every time as it is now.
What testing has been done?
No longer throws linking errors when opening the repo with testing tools installed.

@papowerNI I'm setting up a clean dev VM to test these changes to make sure everything got re-linked.


[Explicit Module Builds] On an incremental build, skip re-building module dependencies when they are up-to-date

In an all-or-nothing coarse-grained fashion, for now.

@swift-ci test


KAFKA-8289: Fix Session Expiration and Suppression (#6654)

Fix two problems in Streams:

Session windows expired prematurely (off-by-one error), since the window end is inclusive, unlike other windows
Suppress duration for sessions incorrectly waited only the grace period, but session windows aren't closed until gracePeriod + sessionGap

Update the tests accordingly
Reviewers: A. Sophie Blee-Goldman<EMAIL_ADDRESS>Boyang Chen<EMAIL_ADDRESS>Matthias J. Sax<EMAIL_ADDRESS>Bill Bejeck<EMAIL_ADDRESS>Guozhang Wang<EMAIL_ADDRESS>More detailed description of your change,
if necessary. The PR title and PR message become
the squashed commit message, so use a separate
comment to ping reviewers.
Summary of testing strategy (including rationale)
for the feature or bug fix. Unit and/or integration
tests are expected for any behaviour change and
system tests should be considered for larger changes.
Committer Checklist (excluded from commit message)

[ ] Verify design and implementation
[ ] Verify test coverage and CI build status
[ ] Verify documentation (including upgrade notes)

@bbejeck Here's the 2.1 cherry-pick for #6654  (see also #6670 )

same here, I'll keep my eye on the build and merge once passes

Java 8 build timed out, Java 11 failed with kafka.server.DynamicConfigTest.shouldFailWhenChangingClientIdUnknownConfig
retest this please

Java 8 passed, Java 11 timed out
retest this please

Java 11 failed on kafka.admin.DeleteTopicTest.testAddPartitionDuringDeleteTopic.
retest this please

Builds finally succeeded. I'll resolve the ticket to proceed with the RC prep.

Merged #6671 into 2.1


Continuous highlighting of syntax errors

Today, students have to click Run to realize they have made an obvious syntax error.  Would be great to find them and place obvious annotations on the editor, so that they can be fixed immediately without a context switch and having to go back and re-understand the syntax.

There are basically two implementation options here:

Occasional round-trips to the server.
Build haskell-src-exts on the client with GHCJS.

The second is more appealing to me, but has the problem that error messages will differ from the compiled code.

I've neglected this, but it's still interesting.  Especially if we could invoke GHCJS with arguments that cause it to check the syntax and types but stop before generating code, then I think it could be efficient enough to be feasible.  Particularly if we do it with an adaptive frequency based on the current server load.

Note to self: the argument I wished for above should be -fno-code.  I haven't verified that it works for GHCJS, but I don't see why it wouldn't.

Some initial work: https://github.com/google/codeworld/commit/c57ebc85450fc418e99af23e822c7dc1ff394b45 and https://github.com/google/codeworld/commit/c9ae860c6c890e1b47ef8585517861a0d2956a06
There is now a /errorCheck endpoint on the server that tries to compile submitted code without generating code or linking.  This is suitable for a prototype of continuous error highlighting.  However, I probably want to look into some kind of a priority system before deploying publicly.  That is, instead of blocking indefinitely on the semaphore, /errorCheck should probably try to grab a low-priority semaphore, which will be aborted if a true build request comes in.  I could imagine a scheme where client polling frequency is adjusted, too, based on measured server load; so if the server is very busy, then clients attempt builds less often.
There are outstanding UI challenges, as well.  The error display window is currently synced to the running program, which is different from the current contents of the editor buffer.  This could get confusing if error highlighting refers to a newer version of the code than the errors that are clearly displayed on the screen!  On the other hand, I wouldn't want to clear the old errors too eagerly, since a student may be working down the list and fixing them.  Definitely requires some thought.

Going to use CodeMirror linter for this.


Improve speed of DBS3Reader APIs

Impact of the new feature
Current implementation of DBS3Reader API relies on sequential access of data from DBS. Even though it works just fine for heavy populated datasets/blocks it can be very slow especially when we require to fetch information from lots of blocks, e.g. parentage information. This ticket should address the speed of DBS3Reader APIs by refactoring codebase to take advantage of concurrency in API calls
Is your feature request related to a problem? Please describe.
For heavily populated datasets (with lots of blocks) I found that certain APIs, e.g. listDatasetFileDetails is very slow, see https://github.com/dmwm/dbs2go/issues/5
Describe the solution you'd like
Refactor code to take advantage of concurrent (parallel) execution of APIs
Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.
Additional context
See this ticket: https://github.com/dmwm/dbs2go/issues/5

The proposed approach in PR#11099 can be applied to the following APIs:

listFilesInBlockWithParents
listFileBlockLocation
getParentFilesGivenParentDataset
getParentFilesByLumi
findAndInsertMissingParentage
fixMissingParentageDatasets

All of them uses sequential calls to DBS APIs via for loop. These calls can be parallelized which will significantly reduce time spent in a given API. I suggest to provide individual PRs for each listed APIs.

@amaltaro I think this issue should stays open until we merge #11099

PR #11099 addresses first three APIs:

listFilesInBlockWithParents
listFileBlockLocation
getParentFilesGivenParentDataset

The getParentFilesByLumi is partially covered by parallel execution, and last two APIs findAndInsertMissingParentage and fixMissingParentageDatasets will require more significant effort to make their code execute concurrently.

Reopening it because the right PR to fix it is being discussed in https://github.com/dmwm/WMCore/pull/11099


Create .NET Repo for Flag Implementation

It would be beneficial to implement a Flagr Client for .NET (probably in .NET Standard). Ideally, the repo would live here.
Expected Behavior
.NET Repo for Flagr exists in Openflagr org
Current Behavior
Does not exist
Possible Solution
Create the repo
Steps to Reproduce (for bugs)
N/a
Context
I made my own Flagr implementation, then realized this is all open source. Giving back to the community is create, so putting a client out there for us is even better under the openflagr name, instead of just my little user.
Your Environment
N/a

Likewise, I would like to see if we can get a Kotlin repo as well...


Add options for gco [#] and branches with hyphens

If this is helpful, here are changes I've added for my use case - issues detailed here: https://github.com/shinriyo/breeze/issues/22

gco [#] applies absolute path to branches, ie /Users/{user}/workspace/etc (from PR #20)
gco splits branch names with hyphens

:+1: :-1:


Fix/pass test job w new spec

New spec.js errors in build + tests. Attempt to fix

@howardchung I think the only way forward is to upgrade the spec to OpenAPI 3.1 and then to use OpenApiParser instead of SwaggerParser in the test. Busy setting that up, and I've pushed an example of what the openapi spec would look like.
You can copy paste the json here to see how the OpenAPI spec renders: https://editor-next.swagger.io/
All that remains is for me to re-add the route/func definitions to the auto-generated conversion, and to use components to define repeated parameters and schemas. That last part will probably be the most work, going through every route and adding the re-used params/schemas to the list of components. But, if you're cool with the idea to upgrade to OpenAPI 3, then I'm happy to proceed and chip away at it over next few days or week

Looks like it's failing with a syntax error--es6 imports are not yet supported yet

Also, is it fine if I revert the previous merge and you can include those changes in this PR?

Also, is it fine if I revert the previous merge and you can include those changes in this PR?

Absolutely, I was surprised how quickly it was merged! I wanted to figure out about downstream impacts or what tests were necessary. Took a break since last week so I'll continue plugging away at it. Probably lots of small things to check so I'll mark PR ready when tests pass

Looks like it's failing with a syntax error--es6 imports are not yet supported yet

Ah yeah I started updating the CommonJS require statements to ES6 imports. Kind of my own OCD to want things up to date if they can be, but seems very minor and nit-picky of me. It needs some other config changes in package.json to work properly. If there's any reason to stick to CommonJS then please let me know, otherwise I assume the upgrades are welcome

I would maybe make the syntax changes in a separate PR so it's less mixed together

I would maybe make the syntax changes in a separate PR so it's less mixed together

Indeed, decided the same!
I'm almost ready to push the latest changes for the spec. It looks ... much cleaner :-)

@howardchung boom, the spec is valid. now moving on to tests.
notes:

created responses.js to collect all response definitions. this can be better organised, but for now this made sense
params + responses are neatly defined in components
a few more params can be ref'd out of the spec, responses can also be refactored to use common types
added a couple to-do's

Excellent, the build test is passing now.
Some more work to do before I'm completely happy with it:
E.g. picks_bans in MatchResponse has the follow definition:
    picks_bans: {
      description:
        "Object containing information on the draft. Each pick/ban contains a boolean relating to whether the choice is a pick or a ban, the hero ID, the team the picked or banned it, and the order.",
      type: "array",
      items: {
        type: "object",
      },
    },

In order to use an openapi client generator, these objects need to be defined:
picks_bans: {
  description: "Array containing information on the draft. Each item contains a boolean relating to whether the choice is a pick or a ban, the hero ID, the team the picked or banned it, and the order.",
  type: "array",
  items: {
    type: "object",
    properties: {
      is_pick: {
        description: "Boolean indicating whether the choice is a pick or a ban",
        type: "boolean",
      },
      hero_id: {
        description: "The hero ID",
        type: "integer",
      },
      team: {
        description: "The team that picked or banned the hero",
        type: "integer",
      },
      order: {
        description: "The order of the pick or ban",
        type: "integer",
      },
    },
  },
},

There may be many instances such as this. My goal is to be able to use the openapi generator, so I'll include all changes until the generator succeeds. Maybe it's a couple hours work, or maybe I'll only get around to it next weekend. But in the meantime, everything else looks ready for review. @howardchung

The openapi-generator-cli succeeds when the openapi version is set to 3.0.3. Throws error with 3.1.0, and seems to be an issue with the generator, not the spec.
So I'm happy to say this upgrade is ready for review. I recommend a version bump, considering there may be breaking changes

@ff137  it looks like the paths for the docs are now incorrect and omit the /api in the path. Is this easily fixed?

@howardchung I don't know. In the OpenApi 3 spec the url is correctly defined:
  servers: [
    {
      url: "https://api.opendota.com/api",
    },

That includes /api in the path.
Just went to https://docs.opendota.com/ to check it out, and yeah, first of all there's the warnings:
No "type" specified at "#/components/parameters/matchIdParam". Automatically detected: "object"
No "type" specified at "#/components/parameters/accountIdParam". Automatically detected: "object"
No "type" specified at "#/components/parameters/fieldParam". Automatically detected: "object"
No "type" specified at "/paths/~1search/get/parameters/0". Automatically detected: "object"
No "type" specified at "/paths/~1rankings/get/parameters/0". Automatically detected: "object"
No "type" specified at "/paths/~1benchmarks/get/parameters/0". Automatically detected: "object"
No "type" specified at "/paths/~1request~1{jobId}/get/parameters/0". Automatically detected: "object"
No "type" specified at "#/components/parameters/heroIdPathParam". Automatically detected: "object"
No "type" specified at "#/components/parameters/leagueIdPathParam". Automatically detected: "object"
No "type" specified at "#/components/parameters/teamIdPathParam". Automatically detected: "object"
No "type" specified at "/paths/~1records~1{field}/get/parameters/0". Automatically detected: "object"
No "type" specified at "/paths/~1constants~1{resource}/get/parameters/0". Automatically detected: "object"

So that'll need to be patched.
When I clicked on GET /heroes as an example, it indeed takes me to https://api.opendota.com/heroes instead of https://api.opendota.com/api/heroes.
Seems to me like an issue with the documentation rendering tool, because the url is right in the spec. It's maybe using an outdated version? Because Swagger 2.0 and OpenApi 3.0 do have different ways of defining the server. But I don't have any knowledge of the doc rendering. What do you think?

@howardchung with regards to those warnings, I can confirm that, e.g. for matchIdParam, the spec is correct:
  matchIdParam: {
    name: "match_id",
    in: "path",
    required: true,
    schema: {
      type: "integer",
    },
  },

The type is correctly defined; in OpenApi 3 it must be inside a schema field.
This further confirms I think the documenting tool is out of date (still expecting Swagger spec)

@howardchung You're lucky I'm a machine. Found the prob and fixed it in https://github.com/odota/docs/pull/19


Transistor amplifier benchmark

Added the MTK version of transistor amplifier problem, from #359
I'm not sure how the solvers are set up, so everything below line 58 (tspan = (0.0, 0.2)) is from ChemicalAkzoNobel.jmd

Copy/pasting the solvers is 👍. They should all have about the same setup, though they can be tweaked a little bit to avoid any instabilities that can show up (which messes up the plot), so a tolerance may be tweaked down or specific solvers can be commented out / moved to a separate plot to accommodate that. We'll see what this generates.

Weird. I'll try running this locally tomorrow and see if I can find the problem.

Line 56 seems to be the issue, it can't create the system

@YingboMa does MTK support parsing linear mass matrices like that right now?

MTK tries to transform the system so that it is an almost identity matrix, i.e. the semi-explicit form. I tried it on the latest MTK, but initialization of the DAE then fails.


Extract DefaultMetricsClient to own project

The DefaultMetricsClient uses prom-client library to gather and set metrics. As preparation for v4.0.0 release we should extract this client to its own library so we do not need the peerDependency  prom-client  if people do not use it.
Idea:

New repository
Library should be scoped, e.g. "dreamit" or "sgohlke"
Library should depend on  prom-client and @dreamit/graphql-server
Linting, tests and CI should be similar to this repository
npm publish should be triggered when release is created (same as this repository)

Extracted to
https://github.com/sgohlke/graphql-prom-metrics/
https://www.npmjs.com/package/@sgohlke/graphql-prom-metrics


What will be happened if the message of adding recovery node be ignored?

In a circumstance, yarn launched a recovery node and then this node send a message of type control::ADD_NODE to the scheduler node. But, if the heartbeat_timeout is large enough so that the scheduler don't find one node has been dead. So, the scheduler will ignore this recovery message so the recovery node will not be added into the management of the scheduler . What will be happened to this event? Thanks.
@mli

The message will be sent again if no ACK message received.


Handle symengine based parameter expressions

Summary
In Qiskit/qiskit-terra#6270 symengine is being added as an optional (but
default on common platforms) backend for parameters and parameter
expressions. However, the aqua version of the gradient code there is an
implicit assumption that parameterexpressions are internally just wrappers
of sympy expressions. This assumption about the internals of terra breaks
with Qiskit/qiskit-terra#6270 where they might be symengine or sympy
expressions. While symengine and sympy expressions are interchangeable
this can only be done with an explicit conversion step (for example,
sympy.sympify(symengine.Symbol('x'))). This commit fixes this by
updating the derivative base class as was done for terra's version in
Qiskit/qiskit-terra#6270 so that the deprecated aqua copy continues to
work wither versions of terra after Qiskit/qiskit-terra#6270 merges.
Details and comments

I'm labeling this as on hold until we have agreement that Qiskit/qiskit-terra#6270  is going to happen (I assume it will because the performance improvement is significant, but we haven't had the discussion yet). Once there is agreement this will need to merge to unblock CI on Qiskit/qiskit-terra#6270.

This is unblocked now, Qiskit/qiskit-terra#6270 has been approved. We need this fix to unblock the terra PR now.
The one open question in my head is do we want to somehow guard against a potential situation where someone has aqua >=0.1.0 installed and symengine installed by terra <0.18.0 ? Because right now if someone installs aqua master with symengine but is using terra 0.17.x I think this will fail (because it's building a symengine expression instead of a sympy expression like what is unconditionally used in terra 0.17.x)