Connecting to different Viiiiva sensors

Vivtools appears to work well with one Viiiiva, but will only work on the first sensor it is connected to.  To be clear, this is what we and another tester encountered

Connect to Viiiiva device 1.
List, copy files etc from Viiiiva device 1
Bring other Viiiivas (e.g. Viiiiva device 2, Viiiva device 3, Viiiiva device 4) into range  and attempt to connect, but all time out.
Device 1 can still connect
To make sure Device 1 isn't causing "interference", we pull the battery on Device 1 and the other devices can still not connect.

As I say, another group who is testing is also seeing the same thing.  We would  love to be able to use vivtools, but need to overcome this issue.
Thanks,

Hi, thanks for the report.
Can you confirm that you were using the -u <uuid> flag to attempt to connect to devices 2+?

Thanks for the response.
No, we did not use that flag, because we didn't see documentation to do so.
Steve
Stephen J. McGregor, Ph.D.
CEO and Founder
Sport Performance Technologies
@.***
734-635-1141
[cid:933ffc58-2a26-4172-b264-103f5d70a73c]

From: Dean Scarff @.>
Sent: Wednesday, July 19, 2023 12:29 AM
To: p00ya/vivian @.>
Cc: Steve McGregor @.>; Author @.>
Subject: Re: [p00ya/vivian] Connecting to different Viiiiva sensors (Issue #1)
Hi, thanks for the report.
Can you confirm that you were using the -u  flag to attempt to connect to devices 2+?
—
Reply to this email directly, view it on GitHubhttps://github.com/p00ya/vivian/issues/1#issuecomment-1641393861, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AZFCA2JVFCMES3IXYKRB6Y3XQ5PCHANCNFSM6AAAAAA2JYI3ZQ.
You are receiving this because you authored the thread.Message ID: @.***>

No problems.  The flag is documented in the man page (man ./vivtool/vivtool.1 from the repo root), but it's not supposed to be mandatory.  What you've encountered still sounds like a bug, because vivtool is meant to fall back to a BLE scan for new devices if it can't find the last-used device.
So for now, there are two workarounds: use the -u flag to connect to a particular device, and/or use defaults delete vivtool LastConnectedDeviceUuid to reset the cached UUID when switching devices.
Meanwhile I'll try and fix the bug so that switching devices just works even without the -u flag.
Best regards

Dean,
Thank you very much for the responsiveness and help.  My developer won't be able to try this until early next week, so, I'll report back then.
Thanks again,
Steve
Stephen J. McGregor, Ph.D.
CEO and Founder
Sport Performance Technologies
@.***
734-635-1141
[cid:6dfbcd7a-6779-4e46-b8cf-a95f11755086]

From: Dean Scarff @.>
Sent: Wednesday, July 19, 2023 8:53 PM
To: p00ya/vivian @.>
Cc: Steve McGregor @.>; Author @.>
Subject: Re: [p00ya/vivian] Connecting to different Viiiiva sensors (Issue #1)
No problems. The flag is documented in the man page (man ./vivtool/vivtool.1 from the repo root), but it's not supposed to be mandatory. What you've encountered still sounds like a bug, because vivtool is meant to fall back to a BLE scan for new devices if it can't find the last-used device.
So for now, there are two workarounds: use the -u flag to connect to a particular device, and/or use defaults delete vivtool LastConnectedDeviceUuid to reset the cached UUID when switching devices.
Meanwhile I'll try and fix the bug so that switching devices just works even without the -u flag.
Best regards
—
Reply to this email directly, view it on GitHubhttps://github.com/p00ya/vivian/issues/1#issuecomment-1642950279, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AZFCA2NLGDLDCS3IN55JXADXRB6PVANCNFSM6AAAAAA2JYI3ZQ.
You are receiving this because you authored the thread.Message ID: @.***>

I tried to repro this bug by:

defaults write vivtool LastConnectedDeviceUuid with a UUID other than my Viiiiva's - this simulates having been previously connected to a device that's no longer present.
Wear my Viiiiva, ensure Bluetooth is enabled on my computer.
vivtool ls -v

vivtool falls back to a scan and finds the device I'm wearing even though it's wasn't the cached UUID.  So it seems like vivtool is working as intended here - this is equivalent to successfully connecting to Device 2 in the original report.
However, I'm unable to test with multiple real devices, so perhaps there is something deeper going on at the macOS/CoreBluetooth layers that is caching previously connected devices and preventing discovery.
I've also created released a new version (v1.1.0) that has a vivtool scan command.
It should print out the names and UUIDs of nearby HRMs.  This can be used to identify the UUIDs to use with the -u option.
Stephen: when your devs get a chance, please ask them:

to use the latest version of vivtool (v1.1.0)
to run vivtool scan between switching devices
to run vivtool ls -v -u UUID where UUID is the identifier printed in brackets by the scan command

If vivtool is still not able to connect to devices 2+ when following those instructions, then please provide the terminal history of those commands and the output, along with the macOS version and the version of the Viiiiva reported in the official 4iiii app to assist me with debugging.

Dean,
Thanks so much for this and your continued assistance.  We will be trying several separate devices and your suggestions over the next day or so and I'll get back with the results.
Steve
Stephen J. McGregor, Ph.D.
CEO and Founder
Sport Performance Technologies
@.***
734-635-1141
[cid:6e33a26f-a36f-4a3a-b205-9a85eaa642fe]

From: Dean Scarff @.>
Sent: Sunday, July 23, 2023 7:46 AM
To: p00ya/vivian @.>
Cc: Steve McGregor @.>; Author @.>
Subject: Re: [p00ya/vivian] Connecting to different Viiiiva sensors (Issue #1)
I tried to repro this bug by:

defaults write vivtool LastConnectedDeviceUuid with a UUID other than my Viiiiva's - this simulates having been previously connected to a device that's no longer present.
Wear my Viiiiva, ensure Bluetooth is enabled on my computer.
vivtool ls -v

vivtool falls back to a scan and finds the device I'm wearing even though it's wasn't the cached UUID. So it seems like vivtool is working as intended here - this is equivalent to successfully connecting to Device 2 in the original report.
However, I'm unable to test with multiple real devices, so perhaps there is something deeper going on at the macOS/CoreBluetooth layers that is caching previously connected devices and preventing discovery.
I've also created released a new version (v1.1.0) that has a vivtool scan command.
It should print out the names and UUIDs of nearby HRMs. This can be used to identify the UUIDs to use with the -u option.
Stephen: when your devs get a chance, please ask them:

to use the latest version of vivtool (v1.1.0)
to run vivtool scan between switching devices
to run vivtool ls -v -u UUID where UUID is the identifier printed in brackets by the scan command

If vivtool is still not able to connect to devices 2+ when following those instructions, then please provide the terminal history of those commands and the output, along with the macOS version and the version of the Viiiiva reported in the official 4iiii app to assist me with debugging.
—
Reply to this email directly, view it on GitHubhttps://github.com/p00ya/vivian/issues/1#issuecomment-1646819015, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AZFCA2NFU37R3HUYMWVGF5TXRUFIPANCNFSM6AAAAAA2JYI3ZQ.
You are receiving this because you authored the thread.Message ID: @.***>

Dean,
I just wanted to check in and let you know that we've made good progress on this after your feedback.  We're able to get data off of several different sensors and will be working toward various enhancements as we progress.
One question I wondered if you could help us with.  One of the main reasons we want to use the Viiiva is as an Ant+ bridge.  So, pairing another Ant sensor with the Viiiva and having the Viiiva write the other sensor's data to its fit file.   For example, pair a power meter with the Viiiva and once paired, the Viiiva will write the power data to the Viiiva's fit file, in addition to the HR data.   I don't suppose you would have any idea how that could be accomplished would you?  We couldn't find anything in your manual, but I honestly didn't expect to.
Again, thank you for your assistance, this is starting to look promising.
Steve
Stephen J. McGregor, Ph.D.
CEO and Founder
Sport Performance Technologies
@.***
734-635-1141
[cid:4a5b3afa-8501-4cb2-9f51-8d907b17f822]

From: Dean Scarff @.>
Sent: Sunday, July 23, 2023 7:46 AM
To: p00ya/vivian @.>
Cc: Steve McGregor @.>; Author @.>
Subject: Re: [p00ya/vivian] Connecting to different Viiiiva sensors (Issue #1)
I tried to repro this bug by:

defaults write vivtool LastConnectedDeviceUuid with a UUID other than my Viiiiva's - this simulates having been previously connected to a device that's no longer present.
Wear my Viiiiva, ensure Bluetooth is enabled on my computer.
vivtool ls -v

vivtool falls back to a scan and finds the device I'm wearing even though it's wasn't the cached UUID. So it seems like vivtool is working as intended here - this is equivalent to successfully connecting to Device 2 in the original report.
However, I'm unable to test with multiple real devices, so perhaps there is something deeper going on at the macOS/CoreBluetooth layers that is caching previously connected devices and preventing discovery.
I've also created released a new version (v1.1.0) that has a vivtool scan command.
It should print out the names and UUIDs of nearby HRMs. This can be used to identify the UUIDs to use with the -u option.
Stephen: when your devs get a chance, please ask them:

to use the latest version of vivtool (v1.1.0)
to run vivtool scan between switching devices
to run vivtool ls -v -u UUID where UUID is the identifier printed in brackets by the scan command

If vivtool is still not able to connect to devices 2+ when following those instructions, then please provide the terminal history of those commands and the output, along with the macOS version and the version of the Viiiiva reported in the official 4iiii app to assist me with debugging.
—
Reply to this email directly, view it on GitHubhttps://github.com/p00ya/vivian/issues/1#issuecomment-1646819015, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AZFCA2NFU37R3HUYMWVGF5TXRUFIPANCNFSM6AAAAAA2JYI3ZQ.
You are receiving this because you authored the thread.Message ID: @.***>

Closing this issue since it seems like the original report (not being able to connect to new devices) has been addressed.
Regarding the ability to pair ANT+ sensors to the Viiiiva: I think it would be feasible, but if it's anything like the file protocol that Viiiiva uses (which is non-standard) then it would require reverse engineering the BLE traffic from the Viiiiva app.  Previously, I obtained BLE traffic using Android's HCI Snoop log.  These days I don't have access to any ANT+ devices that I could test with (other than the Viiiiva itself).  If you can provide me with suitable HCI logs (ideally with corresponding timestamps and screenshots of what you were doing in the Viiiiva app, the ANT+ IDs of the other sensors, etc.), then please file a new feature request with those things attached and I'll see what I can do.  Alternatively, if you can organize the sensor hardware to be sent to Sydney and back, I could capture the BLE traffic myself.

Dean,
I'm not sure how I missed this response.... shoot... would have tried to set things up so we could pursue the ant+ pairing.  I'll look at this response in more detail and see if we can figure something out.
Thanks again for your help.
Steve
Stephen J. McGregor, Ph.D.
CEO and Founder
Sport Performance Technologies
@.***
734-635-1141
[cid:b2669e6a-061c-4d39-89db-23c6b1a3be16]

From: Dean Scarff @.>
Sent: Tuesday, August 22, 2023 12:25 AM
To: p00ya/vivian @.>
Cc: Steve McGregor @.>; Author @.>
Subject: Re: [p00ya/vivian] Connecting to different Viiiiva sensors (Issue #1)
Closing this issue since it seems like the original report (not being able to connect to new devices) has been addressed.
Regarding the ability to pair ANT+ sensors to the Viiiiva: I think it would be feasible, but if it's anything like the file protocol that Viiiiva uses (which is non-standard) then it would require reverse engineering the BLE traffic from the Viiiiva app. Previously, I obtained BLE traffic using Android's HCI Snoop log. These days I don't have access to any ANT+ devices that I could test with (other than the Viiiiva itself). If you can provide me with suitable HCI logs (ideally with corresponding timestamps and screenshots of what you were doing in the Viiiiva app, the ANT+ IDs of the other sensors, etc.), then please file a new feature request with those things attached and I'll see what I can do. Alternatively, if you can organize the sensor hardware to be sent to Sydney and back, I could capture the BLE traffic myself.
—
Reply to this email directly, view it on GitHubhttps://github.com/p00ya/vivian/issues/1#issuecomment-1687397113, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AZFCA2I6YDQNTORM7KMGYMLXWQYE5ANCNFSM6AAAAAA2JYI3ZQ.
You are receiving this because you authored the thread.Message ID: @.***>

Dean,
I thought about your  last response and was considering sending you hardware, but we were able to grab logs using nrf sniffer.  Your last response regarding the matter stated....
Regarding the ability to pair ANT+ sensors to the Viiiiva: I think it would be feasible, but if it's anything like the file protocol that Viiiiva uses (which is non-standard) then it would require reverse engineering the BLE traffic from the Viiiiva app. Previously, I obtained BLE traffic using Android's HCI Snoop log. These days I don't have access to any ANT+ devices that I could test with (other than the Viiiiva itself). If you can provide me with suitable HCI logs (ideally with corresponding timestamps and screenshots of what you were doing in the Viiiiva app, the ANT+ IDs of the other sensors, etc.), then please file a new feature request with those things attached and I'll see what I can do.
So, I think we'll file a feature request and see if that may bear fruit.
Thanks,
Steve
Stephen J. McGregor, Ph.D.
CEO and Founder
Sport Performance Technologies
@.***
734-635-1141
[cid:152f2e49-6b17-450f-80f4-39786b997c4b]

From: Steve McGregor @.>
Sent: Wednesday, November 1, 2023 6:30 PM
To: p00ya/vivian @.>
Subject: Re: [p00ya/vivian] Connecting to different Viiiiva sensors (Issue #1)
Dean,
I'm not sure how I missed this response.... shoot... would have tried to set things up so we could pursue the ant+ pairing.  I'll look at this response in more detail and see if we can figure something out.
Thanks again for your help.
Steve
Stephen J. McGregor, Ph.D.
CEO and Founder
Sport Performance Technologies
@.***
734-635-1141
[cid:b2669e6a-061c-4d39-89db-23c6b1a3be16]

From: Dean Scarff @.>
Sent: Tuesday, August 22, 2023 12:25 AM
To: p00ya/vivian @.>
Cc: Steve McGregor @.>; Author @.>
Subject: Re: [p00ya/vivian] Connecting to different Viiiiva sensors (Issue #1)
Closing this issue since it seems like the original report (not being able to connect to new devices) has been addressed.
Regarding the ability to pair ANT+ sensors to the Viiiiva: I think it would be feasible, but if it's anything like the file protocol that Viiiiva uses (which is non-standard) then it would require reverse engineering the BLE traffic from the Viiiiva app. Previously, I obtained BLE traffic using Android's HCI Snoop log. These days I don't have access to any ANT+ devices that I could test with (other than the Viiiiva itself). If you can provide me with suitable HCI logs (ideally with corresponding timestamps and screenshots of what you were doing in the Viiiiva app, the ANT+ IDs of the other sensors, etc.), then please file a new feature request with those things attached and I'll see what I can do. Alternatively, if you can organize the sensor hardware to be sent to Sydney and back, I could capture the BLE traffic myself.
—
Reply to this email directly, view it on GitHubhttps://github.com/p00ya/vivian/issues/1#issuecomment-1687397113, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AZFCA2I6YDQNTORM7KMGYMLXWQYE5ANCNFSM6AAAAAA2JYI3ZQ.
You are receiving this because you authored the thread.Message ID: @.***>

Sounds good - it seems like https://github.com/p00ya/vivian/issues/2 is asking for this feature, so if you can either attach the logs there (or if you have any privacy concerns about dropping the raw logs on github, you can send them via email).


kernel: use packaging.GitbuilderProject to talk with gitbuilder.

This fixes issue: http://tracker.ceph.com/issues/12795
Signed-off-by: Andrew Schoen<EMAIL_ADDRESS>

Refer to this link for build results (access rights to CI server needed):
http://jenkins.ceph.com//job/teuthology-pull-requests/1805/
Test FAILed.

Refer to this link for build results (access rights to CI server needed):
http://jenkins.ceph.com//job/teuthology-pull-requests/1806/
Test PASSed.


0.6.2 error while checking pending transactions: header not found

Summary

im a new farmer, but it did not work.
Welcome to the Swarm.... Bzzz Bzzzz Bzzzz
           .-.         .--''-.
         .'   '.     /'       '
         '.     '. ,'          |

_        o    '.o   ,'        .-'
.\ /.       .--./'. /.:. :.:.'
< ~O~ >    .'    '.-': ': ': ': ':
'/'     :(.) (.) :  ': ': ': ': ':>-
\ | /      ' ____ .'_.:' :' :' :' :'
|/        '<>/'/ | | :' :' :'
|               \  \
|                '  ' '
INFO[2021-06-02T12:35:15+08:00] version: 0.6.2-984dca0a
Password:
WARN[2021-06-02T12:35:18+08:00] clef is not enabled; portability and security of your keys is sub optimal
INFO[2021-06-02T12:35:18+08:00] using existing swarm network address: XXX
INFO[2021-06-02T12:35:18+08:00] swarm public key XXX
DEBU[2021-06-02T12:35:18+08:00] using existing libp2p key
DEBU[2021-06-02T12:35:18+08:00] using existing pss key
INFO[2021-06-02T12:35:18+08:00] pss public key XXX
INFO[2021-06-02T12:35:18+08:00] using ethereum address XXX
INFO[2021-06-02T12:35:18+08:00] debug api address: [::]:1635
INFO[2021-06-02T12:35:20+08:00] using default factory address for chain id 5: XXX
INFO[2021-06-02T12:35:22+08:00] waiting for chequebook deployment in transaction XXX
TRAC[2021-06-02T12:35:22+08:00] starting to watch transaction XXX with nonce 0
ERRO[2021-06-02T13:16:30+08:00] error while checking pending transactions: header not found
AND
~$ curl localhost:1633
curl: (7) Failed to connect to localhost port 1633: 拒绝连接
~$ curl localhost:1634
curl: (7) Failed to connect to localhost port 1634: 拒绝连接
~$ curl localhost:1635
{"message":"Not Found","code":404}
Steps to reproduce

ubuntu 18.04
version: 0.6.2-984dca0a
config:
--verbosity 5
--debug-api-enable
--swap-endpoint wss://goerli.infura.io/ws/v3/my_code
Expected behavior

Actual behavior

Same issue

Same issue

Same issue

Same issue

Same issue

Same issue

Same issue

Same issue,me too

有人解决了吗

Get a more stable connection to your swap-endpoint.  0.6 monitors the swap-endpoint and will shut down your node if errors are detected.  The postage stamps require this in order to keep track of the currently valid stamps.  The most reliable swap-endpoint you can have is running your own local goerli node.
Or it's just an issue due to the backlog on goerli.  If you hadn't redacted your transaction IDs, we could do additional diagnostics.

same issue,how to solve it  ?

Thanks for your issue. This falls more in the realm of a support question (goerli backlog / overload), and not a problem specifically with Bee itself. For support, please contact us on the #bee-mainnet-support channel.


Run staticcheck in CI

Motivation
We could run staticcheck linter in CI to catch common mistakes, bugs, unused code etc.
Closes #3576
Changes

run statickcheck in quicktests  job in CI
fixed all existing issues reported by statickcheck

DevOps Notes

[x] This PR does not require configuration changes (e.g., environment variables, GitHub secrets, VM resources)
[x] This PR does not affect public APIs
[x] This PR does not rely on a new version of external services (PoET, elasticsearch, etc.)
[x] This PR does not make changes to log messages (which monitoring infrastructure may rely on)

bors merge

bors merge


Chrome Picker - disabling alpha and then selecting a colour on the hue bar returns transparent

How to reproduce:

Insert a ChromePicker component, with the alpha picker disabled.
Without adjusting the colour range, select a colour on the hue bar.
onChangeComplete returns "transparent" as the colour selected.

I can confirm the same experience with the SketchPicker
This is kind of a deal-breaker for me, unfortunately. 😞

I believed this was fixed as I cant seem to reproduce it. Are you still having this problem with the newest version?

@casesandberg I am still facing this issue when using v2.19.x, I am using SketchPicker and following the same steps as the author mentioned the onChange returns "transparent" as the value of event.hex


Write a JavaScript program to find factorial of a number

Description
Write a JavaScript program to find factorial of a number
Factorial of N = N (N-1) (N-2) ... 1
Input  : 5
Output : 120

How to contribute

Save the solution in program/FindFactorialOfANumber.js file
Add FindFactorialOfANumber.js file in find-factorial-of-a-number folder

!assign

!assign

!assign

Hey @anandfresh, this issue is already assigned to @K1118 !!!
Please choose another issue.
Thanks for your interest in contributing to this project.


C/C++ mouse hover tooltip configurations

When I hover over a non-overloaded function with a documentation comment above it, it displays the documentation.
However, when I hover over an overloaded function with a documentation comment above it, it displays all the overloaded functions, but not their corresponding documentation.
I want to choose whether or not those overloads are displayed, and/or would like to see the documentation regardless of whether or not there are overloads.
Screenshots:

/extC++

It looks like this is caused by the C++ extension. Please file the issue to the C++ extension repository. Make sure to check their issue reporting template and provide them relevant information such as the extension version you're using. See also our issue reporting guidelines for more information.
Happy Coding!


EventHubClient.SendAsync() silently dies when running in thread

When running EventHubClient.SendAsync() inside a for loop, it seems to run fine.
Ex:
        static async Task Main(string[] args)
        {
            var random = new Random();
            Parallel.For(0, 1, new ParallelOptions { MaxDegreeOfParallelism = 1 }, async (i) =>
            //for (var i = 0; i < 1; i++) // This approach succeeds
            {
                var eventHubConnectionString = "<connectionString>"
                var eventHubClient = EventHubClient.CreateFromConnectionString(eventHubConnectionString);
                var eb = new EventDataBatch(1046528, "0");
                Console.WriteLine($"Starting Thread {i}");
                try
                {
                    for (var j = 0; j < 10000; j++)
                    {
                        var bytes = new byte[1024];
                        random.NextBytes(bytes);
                        using (var ed = new EventData(bytes))
                        {
                            if (!eb.TryAdd(ed))
                            {
                                await eventHubClient.SendAsync(eb);
                                eb.Dispose();
                                eb = new EventDataBatch(1046528, "0");
                            }
                            eb.TryAdd(ed);
                        }
                        Console.WriteLine($"{j}");
                    }
                }
                catch (Exception e)
                {
                    Console.WriteLine(e);
                }
                Console.WriteLine($"Stopping Thread {i}");
            });
            Console.WriteLine("Done");
        }

"Done" is written but "Stopping Thread" is never written. It seems to fail while attempting to SendAsync(), but doesn't seem to throw any exceptions. The entire thread just exits. I've tried this with other SendAsync() options and not just EventDataBatch - they all seem to repro the issue. Running version 4.0.0 of the package on .netcore 2.2

@serkantkaraca, would you mind taking a look or rerouting to the appropriate person to do so?

Main function call needs to wait until all parallel threads complete. Can you add Console.Readline() at the end and see if it help?

@serkantkaraca Console.ReadLine() appears to allow the remainder of the thread to finish in the background. The weird behavior I'm seeing appears to be due to behavior of Parallel.For finishing when it encounters an await, and is nothing specific to this sdk. Closing this issue, sorry for the confusion!


Fix Sqlite Issue on ARM & MacOS by Updating sqlite Version

The sqlite3 npm package finally had some fixes which now allows it to be installed without problems on ARM devices and newer MacOS versions.
This would also enable us to get rid of the additional -arm docker image tag.
Do we want to do that? Or keep it so that we can easily switch back in case we have similar problems in the future?
I'd prefer to remove it again as so that docker again picks the right image version for me without my involvement.

I'd love to benefitfrom that fix, but when tried to unpin the library last time, the same sqlite3 needs to be installed manually error occured in the Docker smoke tests. That's why I re-pinned it.
If there wouldn't be any more issues, going back to one image would be good. Maybe we should combine that with finally introducing committed lock files, so at least what once worked will keep working?

Mh 🤬 yeah only tested building the image.
Do we know why this is now failing in docker? It looks to me that the sqlite package installs fine without it on both x86 and ARM, but just not in docker.

I didn't investigate that yet b/c it seemed so unnecessary... Maybe it'd also happen for the packaged ZIPs, because they build quite similar to Docker with pruning and all? Just a wild guess, but might be worth checking.

I just tested locally on Windows 10 the following:

Switch sqlite3 version to ~5.0.8
npm install
npm run package:ci
Unpack ZIP into a folder and run npm start there

✅ All works fine! So, it might be either fine on Windows or Docker is really the problem here.

yeah the docker things is really really weird... :(
I've tried something:

Build the image
Run image overwrite entrypoint to start in a shell (docker run --entrypoint sh -it local/juice-shop)
Uninstall & reinstall sqlite3 in docker container. (npm rm sqlite3 && npm install sqlite3)
Start Juice Shop in container (npm run start)
Juice Shop starts up correctly... 🫤

It seems like sqlite has a problem when it is installed in a debian based system and is then copied over to alpine?
You can kinda codify this by moving this (npm rm sqlite3 && npm install sqlite3) to the final alpine based image in the docker file but it looks really ugly :(

Did some further debugging / testing on this.
I've changed the docker image from using alpine to using a distroless image which uses glibc like our node:16 builder image.
It seems to be running correctly, at least on my machine, hoping that the smoke tests work correctly too 🤞
Also found some other size improvements on the image 🎉 (if distroless doesn't work out we should still be able to apply these to the current alpine image 😀)
Compressed Size: 276.02 MiB → 175.59 MiB
Uncompressed Size: 762MB → 509MiB

Did some further debugging / testing on this.
I've changed the docker image from using alpine to using a distroless image which uses glibc like our node:16 builder image.
It seems to be running correctly, at least on my machine, hoping that the smoke tests work correctly too 🤞
Also found some other size improvements on the image 🎉 (if distroless doesn't work out we should still be able to apply these to the current alpine image 😀)
Compressed Size: 276.02 MiB → 175.59 MiB Uncompressed Size: 762MB → 509MiB

Double-wow!!! 🎉🎉 CI passed now as well on 2nd try! 🏁

Can we apply the same changes for the Dockerfile.arm as well? Or maybe we don't even need that one anymore... haven't tried to build with Node 16 on ARM for some time now... 🤷

Ah yeah, forgot about that one 😃 We should be able to delete the arm specific one now.
Works at least on my arm Mac, will also try this again on a raspberry to make sure.

Distroless doesn't have a image for nodejs for arm/v7 only arm64 (which is arm/v8)
So that might not work for 32bit arm devices then, e.g. older raspberry pi's 😕


Update website dependencies

The website is currently built using a very old version of Gatsby. While none of the security issues that pop up should be exploitable as this is a static website, we should still update the dependencies in order not to run into a situation where maintaining it becomes impossible.

I briefly looked into this and the main packages used for the docs website seem all to be either very outdated or abandoned. the docz theme was dropped by its maintainer in favor of a new version that works on top of astro (see readme at https://github.com/doczjs/docz#readme), but that new version was never released.
Astro has a great package to make docs websites, https://starlight.astro.build/. I think it may be reasonable and sensible to move to it as it's more modern and has a lot more traction than gatsby.


GPL-917 Add bed verification to LCMB and make LCMB first class pipeline

Description
Scope what would be required to add bed verification to LCMB process (make good) and then make LCMB first class pipeline (possibly one package of work)
Who the primary contacts are for this work
Andrew
James
Harriet
Knowledge or Stake holders
Ben Farr
Liz Easthope
Lesley
Acceptance criteria
To be considered successful the solution must allow:

[ ] add a list of acceptance criteria here
[ ] ...

Additional context or information
Rich C wrote (Wednesday, 10 March 2021 at 10:10)
RnD commented that the LCMB line is only a partial workflow and they are aware that RnD and Lims support is needed produce a robust, production pipeline.
Stand up 10th March
Discussed stand up on 10th March and consensus (LIMS/R&D) was specification was incomplete and needs further work
Liz E wrote (09 March 2021 12:40)
I’d like to add a story to include bed verification in the LCMB library prep process.  Most of our processing in HTP have the bed verification, but the LCMB library prep doesn’t.  This product line has no up-front QC checks and is often a plate of irreplaceable material.  Having this additional check in place will provide an added measure of control to the process.

Thoughts:
Curently “partial workflow” - confirm what this means?
Want to “produce a robust, production pipeline” - confirm what this means?
“make LCMB” first class pipeline - confirm what this means?
Two steps:

Robot Bed Verification

Currently it is a "partial workflow”, is this because it doesnt have a bed verification step currently?
what are the robot steps involved (!and do they have corresponding robot steps? if not, need to add new bed details)
from and to which plates, on what beds (1 bed = 1 plate)

Pipeline

There isn't currently a LCMB pipeline file in Limber
But the “limber_lcmb” is currently part of the WGS pipeline and Custom Pool pipeline
Think it wants to move LCMB into its own pipeline configuration
What are the request types? -> Request types in SS for LCMB pipeline
Library pass? What is that?
What are the relationships for the LCMB pipeline/ what is the behavior of the plate purposes.
Is it similar to WGS, just skipping a few steps/ changing a few steps
One LCMB moved into own pipeline, remove limber_lcmb from pipelines which currently have it?
If initial plate purpose can do to more than one plate purpose, can use pipeline branches=es
pipeline config files:
each of the "relationships" in Pipeline config file, could have corresponding robot detailing to/from what beds
At run time Limber loads up all pipelines, and finds the pipeline that matches filter, then looks up plate in relationships

A few stories have come out of this research task:
Story 1: GPL-nnn Add bed verification for LCMB (via WGS pipeline) #701

PMAP_0052_LCM_WGS_v0.1.pdf

26.04.21 Stand up - James Mack said he will follow this up with Liz E


WIP programmatic commits closes #102 #127 #103 #104

Codecov Report

Merging #216 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master     #216   +/-   ##
=======================================
  Coverage   12.32%   12.32%
=======================================
  Files           4        4
  Lines         357      357
=======================================
  Hits           44       44
  Misses        313      313

Continue to review full report at Codecov.

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


Calculate nPr

Aim
Calculate nPr
Details
Write a program to calculate nPr, nPr represents n permutation r and value of nPr is (n!) / (n-r)!.
Programming language

[ ] C
[x] C++
[ ] Java
[ ] Python

Assign this issue to me, under LGM-SOC
@Amit366 @ravikr126 @Ayush7614

Can i try in java ?

Assign this issue to me, under LGM-SOC
@Amit366 @ravikr126 @Ayush7614 in java

Assign this issue to me, under LGM-SOC
@Amit366 @ravikr126 @Ayush7614 in C

Assign this issue to me, under LGM-SOC
@Amit366 @ravikr126 @Ayush7614 in C

Bro LGMSOC IS OVER NOW


Lines of code is redundant, or undetected bug...

https://github.com/karimnaaji/3d-quickhull/blob/498df74b117443226c4e3c482728bbe1d7127150/quickhull.h#L1147-L1149
Hi there,
First of all very very nice codebase! this is realy quality work!
However those lines are ether reduntant because they do nothing or you ment to write
if (v->x != 0) v->x = 0;
i am not sure however because i am just getting familiar with the quickhull algorithm...

Hey!
You're right this is redundant and can just go, feel free to submit a PR for this fix if you can, otherwise I'll get to it when I get a chance.
Thanks


"input" option is not added when {args} is used

An "input" option should be created when importing actions that contain {args} as the replacement uses it, but it's not.

label-is_url.action.txt

Fixed in bastion


fix/change-event-date-update-migration

fixed issue with dates in migration

Question: The original ticket only concerns worship services. Is there a reason to include the administrative-unit graph as possible target?

Question: The original ticket only concerns worship services. Is there a reason to include the administrative-unit graph as possible target?

Not really I will take it out.


Do not auto-open release / news page after installation of an update

Description of the new feature / enhancement
After an update of PowerToys was installed, I expect PowerToys to not automatically open a window informing me about the new features of the new release. This because esp. PowerToys for me is a productivity tool which should stay silent in the background and only may become visible if I explicitly request it. Otherwise it will disturb my work flow.
Scenario when this would be used?
Esp. useful together with winget upgrade --all --silent, where I expect a fully silent upgrade of all my software. But I think as long as I do not opt in, this page should never auto-open after an update was installed. And if I want to be informed about the new features I may have missed, I still can open this page manually, or can subscribe to its releases here on GitHub.
Supporting information
I mean this window which automatically poped up while winget upgrade --all --silent was upgrading PowerToys:

/dup #21981


httpsd memory leak in FortiOS 6.2.7

On my home Fortigate, a -61F running v6.2.7 build1190 (GA). I am entering conserve mode after ~12hr of polling at 15s intervals.
I am not observing this on v6.4.4 build1803 (GA) on a Fortigate-VM server.
fortigate (global) # get sys perf stat
[ ...  The result is:
fortigate (global) # get sys perf stat
[ ... ]
Memory: 1964908k total, 776172k used (39.5%), 979792k free (49.9%), 208944k freeable (10.6%)
fortigate (global) # diagnose sys top
Run Time:  0 days, 6 hours and 49 minutes
0U, 0N, 0S, 100I, 0WA, 0HI, 0SI, 0ST; 1918T, 955F
         miglogd      240      S       0.4     1.4
        dnsproxy      217      S       0.4     0.9
         cmdbsvr      150      S       0.0     2.1
         reportd      196      S       0.0     1.9
       ipshelper      213      S <     0.0     1.8
          cw_acd      218      S       0.0     1.7
          httpsd     2235      S       0.0     1.5
         miglogd      177      S       0.0     1.5
         miglogd      242      S       0.0     1.4
         miglogd      243      S       0.0     1.4
         miglogd      239      S       0.0     1.4
          httpsd     2237      S       0.0     1.4
          httpsd     2236      S       0.0     1.3
          httpsd     2234      S       0.0     1.2
[ ... ]
fortigate (global) # diag hard sysinfo memory
MemTotal:        1964908 kB
MemFree:          980336 kB
Buffers:           32972 kB
Cached:           277820 kB
SwapCached:            0 kB
Active:           358048 kB
Inactive:         134784 kB
Active(anon):     299280 kB
Inactive(anon):    21972 kB
Active(file):      58768 kB
Inactive(file):   112812 kB
Unevictable:       89536 kB
Mlocked:               0 kB
SwapTotal:             0 kB
SwapFree:              0 kB
Dirty:               488 kB
Writeback:             0 kB
AnonPages:        271596 kB
Mapped:            73024 kB
Shmem:             49660 kB
Slab:             196140 kB
SReclaimable:      17604 kB
SUnreclaim:       178536 kB
KernelStack:        2496 kB
PageTables:        15772 kB
NFS_Unstable:          0 kB
Bounce:                0 kB
WritebackTmp:          0 kB
CommitLimit:      982452 kB
Committed_AS:   25006324 kB
VmallocTotal:   260046784 kB
VmallocUsed:       84992 kB
VmallocChunk:   259949872 kB

Log for httpsd in debug level -1 attached but I cannot seem to detect any odd things.
httpsd.log
Given that I am not observing this leak on my Fortigate-VM instance, I am thinking this memory leak is probably one of the following:

Bug in 6.2.7
Bug on all current FortiOS on 61F
Bug on all current FortiOS under some specific circumstances

I should be able to upgrade to 6.4.4 soon enough and give that a shot on my 61F. I might also be able to spin up a Fortigate-VM 6.2.7 and see if that has the same behavior.
I have not reported this issue to Fortinet as of yet.
Maybe interesting is that the memory usage is reported to belong to the main VDOM which is my traffic forwarding VDOM, not the management one (root).

For now I have configured a hourly restart of httpsd to contain the issue on this particular Fortigate:
config system automation-action
  edit "restart httpsd for mem leaks"
    set action-type cli-script
    set required enable
    set script "fnsysctl killall httpsd"
  next
end

config system automation-stitch
  edit "restart httpsd for mem leaks"
    set trigger "restart httpsd for mem leaks"
    set action "restart httpsd for mem leaks"
  next
end

config system automation-trigger
  edit "restart httpsd for mem leaks"
    set trigger-type scheduled
    set trigger-frequency hourly
    set trigger-minute 13
  next
end

From my point of view this can only be a Fortigate issue.
So I'm not sure about the bug label. Maybe a device or environment label would be better fit here. 🤔

I created a Fortigate-issue label for these things.

I have verified this behavior on Fortigate-VM 6.2.7 as well.
I ran: while true; do curl 'localhost:9710/probe?target=https://a-fortivm' > /dev/null; done

It seems FortiOS was able to reclaim some memory at times but in the end it stopped responding to HTTPS requests.
On the console I see this:

I am not able to log in on the local console
I will repeat the experiment using 6.4.5 on Fortigate-VM.

Using 6.4.5 this issue seems to have disappeared:

Upgraded my -61F from 6.2.7 to 6.4.5 and disabled the workaround. Memory usage has been stable for the entire day.
Suggest we create a Known Issues part of the README where we do not recommend running the exporter without adding the workaround for versions below 6.4.x
WDYT @secustor ?

Yeah, that is for sure a good idea.

Closing this, as we have documented this now.

Noticed it in Fortigate 100F also. Exclusively using SNMP for now.

@amitkatti If you feel like you have the time, submitting a case to Fortigate would be appreciated.
Otherwise you should be fine on 6.4.x or with the workaround posted above.

I will open a ticket if we decide not to go with the upgrade.

Just FYI - We still have the same issue with 7.0.12 - It seems to be a problem with the API access in general. That's what Fortinet submitted to our tickets at least.


Unable to get video output.

Hello team, Thank you for this tool it's very exciting to work with it but whenever I am running it on a video, it's running and exit's without any error, can you please suggest any solution???
I've trained my model on a custom dataset.
from mmdet.apis import init_detector, inference_detector
import mmcv
config_fname = 'configs/faster_rcnn/faster_rcnn_x101_64x4d_fpn_2x_coco.py'
checkpoint_file = 'epoch_250.pth'
model = init_detector(config_fname, checkpoint_file)
build the model from a config file and a checkpoint file
model = init_detector(config_fname, checkpoint_file, device='cuda:0')
test a video and show the results
video = mmcv.VideoReader('peoples_HCI_107235.mp4')
for frame in video:
result = inference_detector(model, frame)
model.show_result(frame, result)

This might be a bug, we will try to reproduce your bug first.

Hi @neomukul
You may try model.show_result(frame, result, show=True) if you are using a local machine.


Wraps all webpack loader rules into a single oneOf rule

https://github.com/smapiot/piral/blob/a6f52016d1e8720feeed91d2fa5234ca72d3fbba/src/tooling/piral-cli-webpack/src/webpack/common.ts#L98
Would you agree to wraps all webpack loader rules into a single oneOf rule?

"oneOf" will traverse all following loaders until one will match the requirements. When no loader matches it will fall back to the "file" loader at the end of the loader list. create-react-app

This eliminates the need to enumerate other unknown file types, such as xslx.

Sounds good to me. I'm just not sure if / how it will affect "changing" that default config. Will definitely be more complicated, but should be doable (see https://github.com/smapiot/piral/blob/develop/src/tooling/piral-cli-webpack5/extend-config.js).

extend-config.js is under control.
But it's a break change for users who modify the rules of config in webpack.config.js.

But it's a break change for users who modify the rules of config in webpack.config.js.

Yeah that's true. My feeling is that this item would be something for 0.15 - and would be part of the breaking changes. As long as we can keep the API of extend-config.js stable I feel good about this.


docs: Update integration docs for OllamaEmbeddingsModel

Issue: https://github.com/langchain-ai/langchain/issues/24856

Typo in #setup (duplicated )


[datagrid] clrDgLoading loading spinner breaks table

Select one ...  (check one with "x")
[X] bug
[ ] feature request
[ ] enhancement

Expected behavior
Using clrDgLoading to display a loading spinner should not break the datagrid when used to indicate actions being made.
Actual behavior
When the clrDgLoading loading spinner is used, it breaks the datagrid with the ExpressionChangedAfterItHasBeenCheckedError: Expression has changed after it was checked. error and becomes unresponsive after that.
Reproduction of behavior
https://plnkr.co/edit/r0At1g9YYd2wKxcCnZIH?p=preview
Environment details

Angular version: 4.0.X

Clarity version: 0.9.3

@youdz : Please triage...

This is a duplicate of #847.
@jbgarr please follow that issue as I am currently working on it and hope to resolve it soon.

Ah yes, sorry about the dupe!

No worries. Do follow along with #847 though to stay up to date on the fix.


[SDP-1215] Fix the AnyRoleMiddleware so it returns 403 (instead of 401) when the user role doesn't have the required role

What
Fix the AnyRoleMiddleware so it returns 403 (instead of 401) when the user role doesn't have the required role.
Why
Addresses https://stellarorg.atlassian.net/browse/SDP-1215.
Checklist
PR Structure

[x] This PR has a reasonably narrow scope (if not, break it down into smaller PRs).
[x] This PR title and description are clear enough for anyone to review it.
[x] This PR does not mix refactoring changes with feature changes (split into two PRs otherwise).

Thoroughness

[x] This PR adds tests for the new functionality or fixes.
[x] This PR contains the link to the Jira ticket it addresses.

Configs and Secrets

[x] No new CONFIG variables are required -OR- the new required ones were added to the helmchart's values.yaml file.
[x] No new CONFIG variables are required -OR- the new required ones were added to the deployments (pr-preview, dev, demo, prd).
[x] No new SECRETS variables are required -OR- the new required ones were mentioned in the helmchart's values.yaml file.
[x] No new SECRETS variables are required -OR- the new required ones were added to the deployments (pr-preview secrets, dev secrets, demo secrets, prd secrets).

Release

[x] This is not a breaking change.
[x] This is ready for production.. If your PR is not ready for production, please consider opening additional complementary PRs using this one as the base. Only merge this into develop or main after it's ready for production!

Deployment

[x] Does the deployment work after merging?

stellar-disbursement-platform-backend-preview is available here:SDP:      https://sdp-backend-pr295.previews.kube001.services.stellar-ops.com/healthAP:       https://sdp-ap-pr295.previews.kube001.services.stellar-ops.com/healthFrontend: https://sdp-backend-dashboard-pr295.previews.kube001.services.stellar-ops.com


Return AutoGeneratedKey as ResultSet

Solving for Hibernate Integration for Entity class having auto generated keys
@Entity
@JsonIdentityInfo(generator = ObjectIdGenerators.IntSequenceGenerator.class, property = "@id")
public class TestTable {

    @Id
    @Column(name = "ID")
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private int id;

    @Column(name = "MSG")
    private String msg;
}

auto increment value generated for Id field will be returned back to the application.

This change is

Reviewed 19 of 22 files at r3.
Review status: all files reviewed at latest revision, all discussions resolved.

Comments from Reviewable


fix(mrm_handler): add check for autonomous mode and do some refactoring

Description
Currently, if use_emergency_holding is set to true, the ego will enter emergency mode if it is not changed to autonomous mode within "timeout_emergency_recovery" seconds, which is not the expected behavior.
This PR adds a check for Autonomous mode before increasing the timer, which solves the issue.
Related links
Parent Issue:

Link

How was this PR tested?
PSim
https://github.com/user-attachments/assets/f5441097-dd87-41ba-81b6-93d6faa81668
Notes for reviewers
None.
Interface changes
None.

Effects on system behavior
None.

LGTM If you correct Kambe's points.


fix gas reading

R_gas variable replaced as Rgas is the argument passed to prompt_data function

oops, thanks for fixing this oversight!


Adding Normal Sample GT to the VCF file

Would it be possible to add the Normal sample GT/DP/AO to the somatic vcf just for comparison -- for example you can imagine that you have a few "alt reads" in the normal sample compared to 5% or 10% in the tumor which might be much more...  we use this to filter out possible FPs.  Alternately could you spit out a normal VCF with the ref calls for the same positions in the somatic file.  Those could be merged with BCFtools.
Thanks!

@bcantarel
Great thanks for your suggestions!
We added some fields to output the normal sample information, including normal depth and alternate count in normal BAM:
##FORMAT=<ID=NDP,Number=1,Type=Integer,Description="Read depth in the normal BAM">
##FORMAT=<ID=NAU,Number=1,Type=Integer,Description="Count of A in the normal BAM">
##FORMAT=<ID=NCU,Number=1,Type=Integer,Description="Count of C in the normal BAM">
##FORMAT=<ID=NGU,Number=1,Type=Integer,Description="Count of G in the normal BAM">
##FORMAT=<ID=NTU,Number=1,Type=Integer,Description="Count of T in the normal BAM">

since version v0.1.1. We also added the count in different strands of the count(FAU, FCU, FGU, FTU, RAU, RCU, RGU, and RTU tags) in v0.1.7. You might directly use these fields for filtering or checking.
For the GT in the normal sample, the outputted candidates are selected with low alternate reads support in the normal sample, and we feed the tumor-normal pair data into NN to decide the genotype collectively. Hence, for the candidates reported, the GT in normal is considered as '0/0'. Please let us know if you have any ideas on it.

So how would that look in the data line?  ie would the tumor/normal sample have different formats in the same VCF?  or would it be another VCF file for the normal sample?

Yes, we combined the tumor and normal tags into FORMAT column, here are some lines for reference:
#CHROM  POS     ID      REF     ALT     QUAL    FILTER  INFO    FORMAT  SAMPLE
chr17   80000548        .       G       A       6.885   LowQual H;FAU=15;FCU=0;FGU=43;FTU=0;RAU=13;RCU=0;RGU=48;RTU=0   GT:GQ:DP:AF:AD:NAF:NDP:NAD:AU:CU:GU:TU:NAU:NCU:NGU:NTU  0/1:6:119:0.2353:0,28:0.0000:39:0,0:28:0:91:0:0:0:39:0
chr17   80003901        .       G       C       13.060  PASS    H;FAU=0;FCU=13;FGU=47;FTU=0;RAU=0;RCU=11;RGU=43;RTU=0   GT:GQ:DP:AF:AD:NAF:NDP:NAD:AU:CU:GU:TU:NAU:NCU:NGU:NTU  0/1:13:114:0.2105:0,24:0.0000:32:0,0:0:24:90:0:0:0:32:0
chr17   80005657        .       G       A       15.712  PASS    H;FAU=12;FCU=0;FGU=42;FTU=0;RAU=10;RCU=0;RGU=29;RTU=0   GT:GQ:DP:AF:AD:NAF:NDP:NAD:AU:CU:GU:TU:NAU:NCU:NGU:NTU  0/1:15:93:0.2366:0,22:0.0000:28:0,0:22:0:71:0:0:0:28:0

Have not been implemented to split the normal VCF, but would consider it in further release.


Async callbacks

Hello,
I have just been pointed to this repository, as I'm currently investigating scripting languages accessible from rust that would support builtins that return -> impl Future<Output = TheActualResult> (and thus have all lua functions when accessed from rust that would implicitly return -> impl Future<Output = TheActualResult>) in a way that would be transparent to the scripted language, for the configuration file of a server I'm writing.
Until now, the only language I had found that matched this property was gluon, but going with a brand new scripting language makes me uneasy, as users would have to learn it in addition to understanding how my server works.
So I wonder, is async builtins / callbacks being transparently “async'd” through the lua call stack until the initial rust caller something you are considering for luster?
Cheers, and good luck with this rewrite!
Leo

Hm, maaaaybe, but using luster for anything serious is probably a ways off.  I dunno, I'd have to think about exactly how to do it.
I think after luster is more usable and has a working userdata story, you could kind of do this without specific support in luster by taking advantage of the stackless nature.  You'd need to have callbacks call something that sets up some state in a userdata, then the Sequence would pause, and on every sequence step you'd have to check for that waiting state to be set.  Once it is set, you could wait on the condition to be fulfilled before resuming stepping the sequence?
This works because there's a whole lot of overlap between Sequences and Futures, so they give you some of the same abilities, they just have to be different due to lifetimes and threading the garbage collector context.
Is that the sort of thing you were thinking?  I know that definitely isn't automatic, but you could maybe build something automatic off of that.

Hmm so I'm not sure what Sequences exactly describe in luster (I haven't actually tried to read the implementation yet, still being in the exploratory phase). If I understand correctly, the process would be similar to:

Compile the Lua code
Start a Lua VM with the compiled Lua code
When wanting to call a Lua function asynchronously:

“Call” the function on the Lua VM, this gives back a Sequence to be executed
Step-forward the Sequence, this processes the Lua code until the first builtin call
Try to asynchronously perform the builtin call, if it isn't ready, keep the paused Sequence and propagate not-readiness upwards to the (rust) caller
When it is ready, step-forward the Sequence again with the result of the builtin call, and go back to above point

If that is indeed approximately what you mean, then I think it'd be possible to wrap a library over this model so that it could be transparently be used as async, and thus that this issue will solve itself then!
Thank you for your answer, and sorry if I'm misunderstanding something for lack of knowledge of luster's internals. As for luster not being ready, don't worry, my project is very far from being ready too! hopefully we'll manage to get to something usable approximately simultaneously :)

This is an extremely old issue, but I never responded to the question because this was about when I stopped working on the project for four years. I'm going through old PRs / issues right now.

When wanting to call a Lua function asynchronously:

“Call” the function on the Lua VM, this gives back a Sequence to be executed
Step-forward the Sequence, this processes the Lua code until the first builtin call
Try to asynchronously perform the builtin call, if it isn't ready, keep the paused Sequence and propagate not-readiness upwards to the (rust) caller
When it is ready, step-forward the Sequence again with the result of the builtin call, and go back to above point

This is actually exactly how you would do it. Nowadays, you would specifically use Fuel::interrupt to cause the Executor::step driving Lua code to immediately return to Rust, (after registering some waker somewhere, or in some other way propagating unreadiness). I should make an example of this and put it somewhere...


Plagiarism Checks: The warning message is shown in a wrong position

Describe the bug
The warning message "You must notify the student before determining the verdict" is shown in a wrong position when I approach the mouse cursor.
To Reproduce

Go to Plagiarism check in a course
Open a case from any student without notification
Approach the cursor over the button in the Verdict section.
Verify that the warning message for the Plagiarism button is shown in the wrong position. See the screencast

Expected behavior
Should shown the warning message over the Plagiarism button.
Screenshots
https://user-images.githubusercontent.com/88991954/182304551-babebc3e-ff10-4e48-a71a-c226f67b5d9e.mov
What browsers are you seeing the problem on?
Chrome
Additional context
No response
Relevant log output
No response

I have re-done the instructor interface, so this will soon be no longer an issue.


Better accessible name for Filters button and tab

Problem

#826 added a counter to the filters button and filters tab. The labels for these filters appear in two places:

VFilterButton on wider viewports (explicitly generated by the aria-label here, currently of the form {count} Filters in English)
VFilterTab on smaller viewports (implicitly generated by the textual content of the tab, either Filters or {count} Filters depending on whether or not filters are applied)

Screenshots
Wider viewports:

Smaller viewports:

Description

Two things will need to be addressed here:

Unifying the accessibility information available for both viewport sizes. Having an explicit aria-label is useful rather than relying on the textual content, since the order of the number and the word describing Filters could be different in other languages.
Determining if {count} Filters is indeed the most accessible language here.

On the latter point, visually the button/tab conveys the notion that the filters are available under this button (if none are currently applied) or it shows the number of filters currently applied to the search along with the impression that the button is a controller for the filters pane. What is the best way to convey this meaning via text? Would something like Filters: {count} enabled or Filters: {count} applied be appropriate? Does {count} Filters work as-is?

I've added more information to the issue body, and asked for some input from the accessibility Make WordPress Chat channel. If we're able to garner some advice on the appropriate wording for this, then this issue can be worked on. Until then, I'm going to moved it to blocked.

Having an explicit aria-label is useful rather than relying on the textual content, since the order of the number and the word describing Filters could be different in other languages.

I'm not sure that's actually relevant, since both the aria-label and the visible text should be translated. There are some specific accessibility problems caused by having a mismatch between the accessible name and the visible text, because voice control will respond to the accessible name, and if that doesn't match the visible name a user of voice control won't be able to trigger the button easily.
I think the most valuable change might just be word order; the action word should be first, with the supplemental values second. E.g. Filters (2). Adding additional terminology like (2 applied) could be useful, but isn't absolutely critical. In my opinion, it's better to have the visible text be the accessible name of the control than to add extra terms to try and add support for screen readers.
If we believe that Filters (2) is enough information for sighted people to figure out what it means, then we should accord screen reader users the same level of ability to interpret the interface. It's only necessary to add additional context if there is context that is clearly available to sighted users that is not available to screen reader users.

Thank you so much for your input @joedolson! That approach makes sense to me, @WordPress/openverse-frontend & @fcoveram - what are your thoughts?

Sounds good to me! It doesn't necessarily require a visual change, FWIW @AetherUnbound. You can set aria-hidden on the icon-or-filter-count component so that screen readers ignore it, then either add an sr-only text with the parenthised count in a more obvious position relative to the tab/button name, or set it directly on aria-label of the element.
The other PR I mentioned to you, #3941, did something along those lines to give clearer information for the screen reader to delineate the information that was otherwise available only visually... but did so without changing the visual presentation of the page.
The issue Madison mentioned about the word order was because of a difference in the desktop and mobile version of this bit of UI. The desktop button explicitly sets aria-label using a single translated string that includes the placeholder for the number of applied filters. The mobile version does not, and instead gets its accessible button name from the joined content of the button, rather than a single unified and translated string that incorporates the number when needed. We should fix that in the mobile version, for sure, so that they are translated together and identically :+1:

Sounds good to me! It doesn't necessarily require a visual change, FWIW @AetherUnbound. You can set aria-hidden on the icon-or-filter-count component so that screen readers ignore it, then either add an sr-only text with the parenthised count in a more obvious position relative to the tab/button name, or set it directly on aria-label of the element.

+1 to this. There are hidden elements in WordPres.org changes to enhance accessibility, so this approach sounds great to me.


Spike - On setting terminal.integrated.inheritEnv = false always

[ ] Can the extension in its settings turn this off?
[ ] How does this affect people in general on bash?
[ ] What happens if the terminal is already open before the extension starts?
[ ] Does strictEnv for terminal creation imply inherentEnv as false?

This helps with login shell in VSCode remote scenario, the prompt for this should go away soon.


Issues with Binary Windows resource

2 issues regarding the resource, "Binary Windows".
http://cs-unplugged.appspot.com/en/resources/binary-windows/
Preview image:

Issue 1: The 'off' light bulb/'0' image in even numbered pages in Binary windows are on the wrong side of the page.
Currently, the 'off' light bulbs/'0', are on the left side of the page.
This is an issue because, when printing double-sided (as intended), this orientation requires the user to manually adjust printer setting to print on using short-side binding (The default is long-side binding).
Flipping image with the 'off' light bulbs/'0' so that it's on the right page should fix that.
Currently:

How to fix:

Issue 2: The graphic on even numbered pages in Binary windows not aligned with the graphic on odd numbered pages.
Currently, the graphic on odd numbered pages are a few pixels too high compared to the graphic on even numbered pages.
This is an issue because, when printing double-sided (as intended), the graphic is not aligned so that you can't cut out the resource properly.
(After fixing the first Issue 1) Adjusting the second graphic to be a bit lower so that the grid line up should fix that.
Currently:

How to fix:

Thanks for all the detail, makes my job so much easier!


feat: remove RPC_PROVIDER_URL env

Right now we get RPC URL based on chain id from the bot's config https://github.com/ubiquity/ubiquibot/blob/development/src/bindings/config.ts#L13 so we no longer need the RPC_PROVIDER_URL env variable
@0xcodercrane It seems that the process.env.RPC_PROVIDER_URL env variable exists in netlify so when chain id is set to gnosis the ethereum RPC URL is used (instead of gnosis RPC URL) so there is an error on permit generation. Could you remove the RPC_PROVIDER_URL env variable in netlify both for production and development deployments?

Right now we get RPC URL based on chain id from the bot's config https://github.com/ubiquity/ubiquibot/blob/development/src/bindings/config.ts#L13 so we no longer need the RPC_PROVIDER_URL env variable
@0xcodercrane It seems that the process.env.RPC_PROVIDER_URL env variable exists in netlify so when chain id is set to gnosis the ethereum RPC URL is used (instead of gnosis RPC URL) so there is an error on permit generation. Could you remove the RPC_PROVIDER_URL env variable in netlify both for production and development deployments?

Yeah I can remove both of them. but I have to remove them after the PR merged no?

I think we might need to consider adding paid RPC endpoints as well

What does "paid RPC endpoints" mean?

I think we might need to consider adding paid RPC endpoints as well

What does "paid RPC endpoints" mean?

Like we purchased from alchemy/infura rpc providers.

I think we might need to consider adding paid RPC endpoints as well

What does "paid RPC endpoints" mean?

Like we purchased from alchemy/infura rpc providers.

I think we should eventually aim to set up our own endpoints if it's easy like we do on Cloudflare (its just a service they provide, for free.)

@0xcodercrane could you:

merge this PR
remove the RPC_PROVIDER_URL env variable in netlify both for production and development deployments

@0xcodercrane could you:

merge this PR
remove the RPC_PROVIDER_URL env variable in netlify both for production and development deployments

Sure can do

@0xcodercrane did you remove the RPC_PROVIDER_URL env variable from netlify (dev + prod)? waiting for it to check how payouts work in gnosis https://github.com/ubiquibot/production/issues/3

@0xcodercrane did you remove the RPC_PROVIDER_URL env variable from netlify (dev + prod)? waiting for it to check how payouts work in gnosis ubiquibot/production#3

You couldn't test it until we create a sync pr to main. so I am gonna remove RPC_PROVIDER_URL from dev. sounds ok?

@0xcodercrane did you remove the RPC_PROVIDER_URL env variable from netlify (dev + prod)? waiting for it to check how payouts work in gnosis ubiquibot/production#3

You couldn't test it until we create a sync pr to main. so I am gonna remove RPC_PROVIDER_URL from dev. sounds ok?

Gnosis payouts are already deployed to production. So if you remove RPC_PROVIDER_URL both from prod and dev nothing breaks.

RPC_PROVIDER_URL is removed from prod and dev in netlify
Here the correct RPC is used (because we would have process.env.RPC_PROVIDER_URL undefined)

I'm trying to say that it is safe to remove RPC_PROVIDER_URL from prod and that we can omit waiting for a new bot's release. Gnosis payouts should start working as soon as  RPC_PROVIDER_URL is removed from netlify. But if you are concerned from removing RPC_PROVIDER_URL for prod then sure we can start from dev first.

Removed it from both env


Remove SetNameValuePair

Stub issue for C+ review on https://github.com/Expensify/App/pull/16396
We just need BZ team to handle the payment for this sorry there was no App issue created and a review was requested.
Upwork Automation - Do Not Edit

Upwork Job URL: https://www.upwork.com/jobs/~0117222f67cf17114a
Upwork Job ID:<PHONE_NUMBER>440995840
Last Price Increase: 2023-03-31

Triggered auto assignment to @lschurr (Bug), see https://stackoverflow.com/c/expensify/questions/14418 for more details.

Job added to Upwork: https://www.upwork.com/jobs/~0117222f67cf17114a

Bug0 Triage Checklist (Main S/O)

[ ] This "bug" occurs on a supported platform (ensure Platforms in OP are ✅)
[ ] This bug is not a duplicate report (check E/App issues and #expensify-bugs)

If it is, comment with a link to the original report, close the issue and add any novel details to the original issue instead

[ ] This bug is reproducible using the reproduction steps in the OP. S/O

If the reproduction steps are clear and you're unable to reproduce the bug, check with the reporter and QA first, then close the issue.
If the reproduction steps aren't clear and you determine the correct steps, please update the OP.

[ ] This issue is filled out as thoroughly and clearly as possible

Pay special attention to the title, results, platforms where the bug occurs, and if the bug happens on staging/production.

[ ] I have reviewed and subscribed to the linked Slack conversation to ensure Slack/Github stay in sync

@lschurr it's not actually a "bug" but a clean up issue so I checked everyone off in the list. We just need to eventually hook up @0xmiroslav for helping test and review.

Nice! Can it be paid any time @marcaaron or are we waiting for something?

Removing the bug label since it's not a bug (I hope nothing explodes)

Looks like this was deployed yesterday.. https://github.com/Expensify/App/pull/16396#issuecomment-1502153461

When is the payment date for this one @marcaaron @0xmiroslav?

Paid and contract ended in Upwork. I think we're good to close this one.


Nest the 2nd reaction for Mild Nausea within the Allergy - Intoleranc…

…e Observation Template
Before this change, the 2nd drug reaction was nested within the Allergy Concern Act Template in a Reaction Observation Template.  However, the recommendation from the C-CDA Implementation Guide is to place the Reaction Observation Template for an allergy within the Allergy Intolerance Observation Template for that same allergy.  Now the 2nd drug reaction (Mild Nausea) appears under the Allergy - Intolerance Observation Template alongside the Reaction Observation Template for the 1st drug reaction (Severe Nausea).

looks good @pegeenladeau , thanks!


relative import paths don't work

Expected
from .deck_of_cards import DeckOfCards
should import from deck_of_cards.py in the same path
Actual
has to use from poppy.poker.deck_of_cards import DeckOfCards
for import to work
Traceback (most recent call last):
  File "/Library/Frameworks/Python.framework/Versions/3.7/lib/python3.7/site-packages/pop/loader.py", line 122, in python
    return sfl.load_module()
  File "<frozen importlib._bootstrap_external>", line 407, in _check_name_wrapper
  File "<frozen importlib._bootstrap_external>", line 907, in load_module
  File "<frozen importlib._bootstrap_external>", line 732, in load_module
  File "<frozen importlib._bootstrap>", line 265, in _load_module_shim
  File "<frozen importlib._bootstrap>", line 696, in _load
  File "<frozen importlib._bootstrap>", line 677, in _load_unlocked
  File "<frozen importlib._bootstrap_external>", line 728, in exec_module
  File "<frozen importlib._bootstrap>", line 219, in _call_with_frames_removed
  File "/Users/jblair/code/pop-poker/poppy/poker/init.py", line 2, in <module>
    from .poker_dealer import PokerDealer
ModuleNotFoundError: No module named "['poppy"

pop-poker.tar.gz

To replicate from that tarball, change poppy/poker/init.py to use relative imports, then python3 run.py.

This should work in 99% of cases now.


Migration from pdfbox 2 to pdfbox 3

We migrated from pdfbox 2 to 3 in our software recently and noticed,  that the mustang library broke in the process. Since I didn't want to roll the changes back in our software I decided to migrate pdfbox in your project, too.
Be aware, this PR has breaking changes. I had to replace all load() functions with one that accepts a "File" object, since the signature of the PreflightParser changed significantly (eg:PreflightParser.validate(pdfFile).isValid()). I don't know why the Parser is so much more flexible by using RandomAccessRead-classes, but the PreflightPrarser lacks such constructors.
Due to this change I had to change getResourceAsStream to getResource, which should be fine, since the tests don't run in a jar-file.
Additionally I had to modify some tests, because getDocumentInformation is mostly deprecated. The producer can't be set using it anymore:

See also: PDFBox Migration Guide

Suggestion: -> mustang version 3 could get rid of the "library" only proving the "validator" and then also the preflight check could be tackled by verapdf which would be always available


Scenarios testing - add capability to allow for testing array slices in expectations.yaml

Currently, we can test full arrays in expectations.yaml via
E: {status: complete, typekind: R4, rank: 2, value: 1.}

Need ability for more fine grained testing.

PR: #3192


dbeaver/dbeaver#19383 clickhouse catalog handling

Closes dbeaver/dbeaver#19383
Removes catalog omitting and adds metadata entity for catalog

Does it work for the legacy Clickhouse driver? Can you read table data in both drivers? Can you read tables data with schemas and catalogs?

@LonwoLonwo Legacy driver will use only schemas. It doesn't have a feature to show them as a catalog. This is one of the recent features of the driver.

Verified


create button to stop streaming of response

Purpose

These changes will allow the user to stop the streaming of a response if they so choose. This is helpful if the response does not seem to be useful or if the LLM is hallucinating. The approach I used to implement this may not be perfect, but I would love to get some constructive feedback on this @pamelafox.
Does this introduce a breaking change?
When developers merge from main and run the server, azd up, or azd deploy, will this produce an error?
If you're not sure, try it out on an old environment.
[ ] Yes
[X] No

Does this require changes to learn.microsoft.com docs?
This repository is referenced by this tutorial
which includes deployment, settings and usage instructions. If text or screenshot need to change in the tutorial,
check the box below and notify the tutorial author. A Microsoft employee can do this for you if you're an external contributor.
[ ] Yes
[X] No

Type of change
[ ] Bugfix
[X] Feature
[ ] Code style update (formatting, local variables)
[ ] Refactoring (no functional changes, no api changes)
[ ] Documentation content changes
[ ] Other... Please describe:

Code quality checklist
See CONTRIBUTING.md for more details.

[X] The current tests all pass (python -m pytest).
[ ] I added tests that prove my fix is effective or that my feature works
[X] I ran python -m pytest --cov to verify 100% coverage of added lines
[X] I ran python -m mypy to check for type errors
[X] I either used the pre-commit hooks or ran ruff and black manually on my code.

@ssjdan27 please read the following Contributor License Agreement(CLA). If you agree with the CLA, please reply with the following information.
@microsoft-github-policy-service agree [company="{your company}"]

Options:

(default - no company specified) I have sole ownership of intellectual property rights to my Submissions and I am not making Submissions in the course of work for my employer.

@microsoft-github-policy-service agree

(when company given) I am making Submissions in the course of work for my employer (or my employer has intellectual property rights in my Submissions by contract or applicable law). I have permission from my employer to make Submissions and enter into this Agreement on behalf of my employer. By signing below, the defined term “You” includes me and my employer.

@microsoft-github-policy-service agree company="Microsoft"

Contributor License Agreement

@microsoft-github-policy-service agree

Thanks for the PR! I will take a look soon. Am also interested to see feedback from other folks in the thread for https://github.com/Azure-Samples/azure-search-openai-demo/issues/1221

This PR requires an update now that the internationalization change is in. I made the necessary changes but could not push them to your PR since your PR is off a "main" branch. You can see the changes I made here:
https://github.com/Azure-Samples/azure-search-openai-demo/compare/main...pamelafox:azure-search-openai-demo:stopmerge?expand=1
@ssjdan27 Could you bring in those changes?

I've successfully merged the changes you made, @pamelafox, into this PR. Please let me know if there's anything else I should address with these updates!

Any news here @ssjdan27? I would be really interest in this enhancement 🙌

@advanced-flow Hi there! I am still keen on refining this feature, but life has gotten a bit busy these past few months. If I had to put a time on it, I can probably fully revisit this sometime mid December, but I will aim for sooner if time allows!


SIL: Pick default ARC convention for witness thunks based on the kind of the original decl.

Enum constructors take their arguments +1 by default, but they can now be used to satisfy protocol static member
requirements, which take arguments +0 by default. Type lowering would accidentally use the kind of the witness
to determine the conventions for the witness thunk, leading to a miscompile when the requirement is called through
the protocol. Fixes rdar://74117738.

@swift-ci Please test

Build failed
Swift Test OS X Platform
Git Sha - 4becd80fff44cb70548e0f2cd80e49a3355614b6

@swift-ci Please test macOS

@slavapestov I was going to add a verifier check that SILWitnessTable entries match the expected convention of the protocol interface. That seems like it'll more thoroughly catch this class of bug than an execution test would.


improvement

I wonder it's possible to add the name of the streamer directly at the top of the video in addition to the credits in the discription

#35


Add standard dynamic builtins to plc-exe

The plc command was just running with an empty set of dynamic builtins, meaning that it couldn't typecheck or run programs involving the standard dynamic builtins.  I noticed this yesterday when Nikos was asking about a related problem.  I'm sure I've added this at least once or twice before, but I think it's perhaps been accidentally reverted.
Anyway, this is just a small PR to add those builtins.  It turned out to be quite tricky to get the types to work, and I had to add a cal  to runQuoteT at one point.  I'm not sure whether or not this is safe...

OK, is that any better?  I had some trouble aligning my of there; maybe I should just save the typeckecking result in a variable and then have a case on that.  (Also, you can get some really unhelpful type errors if you get the annotation type wrong.)

I just noticed something slightly annoying about this.  The parsed program has annotations of type AlexPosn, but to get it to compile I had to replace these with ():
    PLC.typecheckPipeline (PLC.TypeCheckConfig types) (void prog)  -- Note the void

This is because getStringBuiltinTypes is defined (in OffChain.hs) like this
getStringBuiltinTypes ann =
       dynamicBuiltinNameMeaningsToTypes ann $ getStringBuiltinMeanings @(Term TyName Name uni ())

If you replace () with something else (like AlexPosn) we get "Could not deduce (FromConstant (Term TyName Name uni ann))
...".  As far as I can see we only have an instance of FromConstant for ann = ().  FromConstant provides a method fromConstant which converts a Haskell value to a Constant term in the AST, and has to provide an annotation for the term when it does so, and there's no obvious way to produce an annotation out of thin air in general.
Anyway, the upshot of all this is that we have to throw away annotations when typechecking, so we never get any useful location information in the event of a type error. Maybe this doesn't matter for plc: the type errors aren't very helpful anyway, and we already have to set all the locations to 0 in deserialised CBOR.
This seems to be a recurring problem: I think I had to invent locations in a number of places in the saturated builtins branch, but not for the same reason.

I'd have thought fromConstant should take an annotation, which we could get from the constant node in the AST.


Refactoring: migrate old import stuff to import filters

Blocked on #572 since the import filter needs to be able to create both analog and digital output streams


Pawn Freezing Potential Incomp with  Common Sense

Error code.txt
This is what she sent me. Probably with more unrelated Errors
The Retreat back up.rws.txt
Save file now in here as well as mod list
https://steamcommunity.com/sharedfiles/filedetails/?id=1740592188

That is some weird error text file. Is there anything else that is more like a normal stack trace? I saw the video but the colonist related to the error is outside the view and I can hardly read the red text - even in 720p

Also: a bit later, she drafts the stuck colonist and you can see in the video that she had avoidance turned off - that makes even less sense as it basically shortcuts all the extra logic. I am beginning to think that this isn’t Zombieland related.

I'm sorry but i dont know what you mean by a stack trace My knowledge on these things is so limited. and if you got the the 2 hour 49 minute mark. you can see the colonist in the top left of the screen in which she will eventually unpause. and it may not be Zombieland related but atm we can (paper and i) only assume so as this was working fine (as you saw the otherday) and the only mod update she had was zombie land. but upon removing "Common Sense" the issue has since been resolved

No problem. I got another report and hopefully a save file where the problem occurs just after load and that will help me solve this. If its Zombielands fault I will make sure to fix this asap.

Fixed


bug: comma not working with f F t T motions

Did you check docs and existing issues?

[X] I have read all the flash.nvim docs
[X] I have searched the existing issues of flash.nvim
[X] I have searched the existing issues of plugins related to this issue

Neovim version (nvim -v)
NVIM v0.9.4
Operating system/version
Windows 11 23H2
Describe the bug
When using the f, F, t, T motions, I can use the semicolon to go to the next match, but the comma doesn't work. After moving around, the semicolon will also work to re-trigger the motion, but not the comma key. With the plugin disabled, the normal f F t T work with the comma as expected.
Steps To Reproduce

Search for a character with f a
Press ; to go to the next match
Press ,, but nothing happens

Expected Behavior
The comma key should go to the previous match.
Repro
-- DO NOT change the paths and don't remove the colorscheme
local root = vim.fn.fnamemodify("./.repro", ":p")

-- set stdpaths to use .repro
for _, name in ipairs({ "config", "data", "state", "cache" }) do
  vim.env[("XDG_%s_HOME"):format(name:upper())] = root .. "/" .. name
end

-- bootstrap lazy
local lazypath = root .. "/plugins/lazy.nvim"
if not vim.loop.fs_stat(lazypath) then
  vim.fn.system({ "git", "clone", "--filter=blob:none", "https://github.com/folke/lazy.nvim.git", lazypath, })
end
vim.opt.runtimepath:prepend(lazypath)

-- install plugins
local plugins = {
  "folke/tokyonight.nvim",
  { "folke/flash.nvim", opts = {} },
  -- add any other plugins here
}
require("lazy").setup(plugins, {
  root = root .. "/plugins",
})

vim.cmd.colorscheme("tokyonight")
-- add anything else here

I had the same issue but I found out that it was caused by
vim.g.maplocalleader = ','

Removing this then , works again :)

I thought of this but temporarily setting my local leader to something else didn't work, and I couldn't find a line setting the local leader to ',' anywhere in my config...


Remove highlight md-input-container for mdInput[readonly] on focus

Bug, feature request, or proposal:
Proposal: if we set a mdInput as readonly, it should not highlight the placeholder and border.
It's currently adding a highlight within the md-input-container.mat-focused.
What is the expected behavior?
I believe the border and placeholder should keep the style on focus.
What is the current behavior?

What are the steps to reproduce?
Focus on the readonly input
<md-input-container>
    <input mdInput placeholder="Focus on the input" readonly value="Example readonly" />
</md-input-container>

Providing a Plunker (or similar) is the best way to get the team to see your issue.
http://plnkr.co/edit/Y7hAk6fuZkFTCEfI52IU?p=preview
What is the use-case or motivation for changing an existing behavior?
User Experience. A better way to show the user the input is readonly.
Which versions of Angular, Material, OS, TypeScript, browsers are affected?
macOS Sierra Version 10.12.5
Chrome: 59.0.3071.115 (Official Build) (64-bit)

@angular: 4.2.5
@angular/material: 2.0.0-beta.8

Is there anything else we should know?
I would like to send a PR, but I'm not sure the best approach to solve that.

Solution 1: Add an @Input() readonly  to md-input-container(which could be duplicating code)
Solution 2: Do not add the class mat-focused if is readonly
Solution 3: Add a new class mat-focused--readonly os similar _onFocus() if the input is readonly. (so we wouldn't hightlight the placeholder os something like that) and the user can override it.

Unfortunately the spec does not say anything about read-only inputs. But on the other hand, disabled/read-only is HTML specific.
I think we should treat read-only as disabled. The user does not know the difference between the two.
The difference for devs are that one is sent through POST while the other is not.

@grizzm0 I wouldn't treat readonly inputs as disabled ones. A good case is the date-picker component. I would like to have a readonly input (for the date) but still have an enabled component where the user could click on it and display the date-picker. Although I can do this, now the highlight is gone for the input.

@susox if you use a native date input (<input type="date" readonly />) you shouldn't be able to change its value.
Try it out: http://plnkr.co/edit/QUT9rKOneg7GEsoOYwnI?p=preview
The native input [readonly] works very similar to disabled, however, the material version also changes the label and input colors, which makes more clear the field is disabled.
If you really need to add focus on readonly, you might be able to create a directive or achieving that with CSS.


Skeleton code for refactor with OpenAPI Spec

[x] I have added the tests to cover my changes.
[x] I have updated the documentation, VERSION, and CHANGELOG accordingly.
[x] I have read the CONTRIBUTING document.

This PR will introduce the different microservices for the refactoring of dispatcher component. Also includes the openapi spec for each of the service.

Totally concur with these changes @scottwn , will update the specs accordingly


Add justification analysis.

Compute justifications for atoms (avoids chronological backtracking when MBT remains at fixpoint).

I think the architectural problem originating in the ArrayAssignment.getSomeMBTAssignedAtom has improved now since it relies on the now common AtomTranslator and no longer requires the grounder. Please have a look again @lorenzleutgeb and @rtaupe.

All raised issues should be addressed now. Please have a look again.