🐛 | Connectivity issues with mopidy

Hi!
My phoniebox worked quite well and I was ready to hand it on to my godchild, but now - seemingly out of nowhere - new Spotify problems emerged:
I installed the latest developer version of phoniebox and ran the commands of #852 (even though I think they are all part of the developer script already).
Unfortunately I can't play any Spotify content even though it says "Connected" under server status (I do get search results though).
journalctl -u mopidy gives me this where the following lines stick out to me:
Apr 12 12:38:11 raspberrypi mopidy[465]: ERROR    [SpotifyEventLoop] spotify.session Spotify login error: <ErrorType.UNABLE_TO_CONTACT_SERVER: 8> Apr 12 12:38:12 raspberrypi mopidy[465]: INFO     [SpotifyBackend-6] mopidy_spotify.web Logged into Spotify Web API as joseiger Apr 12 13:24:34 raspberrypi mopidy[465]: INFO     [SpotifyBackend-6] mopidy_spotify.lookup Failed to lookup 'spotify:track:0d6bZwEAi1XblGRhnzPfgC': Session must be logged in
So there seems to be some kind of connectivity issue even though it says Logged into Spotify Web API at some point.
The login information is definitely correct and I just created a new cliend ID and client secret.
I don't think there is a general problem with my internet, I don't use any proxy, VPN etc...
sudo systemctl status mopidy doesn't reveal any problems.
Any ideas whta to try?
If it helps, here ist the output of tail -n 500 /var/log/syslog.
Julius

Could be a temporary error on Spotify side, don’t know if you can check on Spotify, if there are any issues.
I read here this error was also caused by expired credit card info on Spotify side:
https://discourse.mopidy.com/t/spotify-login-error-errortype-unable-to-contact-server-8/1400

I installed the latest developer version of phoniebox and ran the commands of #852 (even though I think they are all part of the developer script already).

That’s correct, you only need #852  for master, not develop.

I read here this error was also caused by expired credit card info on Spotify side:
https://discourse.mopidy.com/t/spotify-login-error-errortype-unable-to-contact-server-8/1400
I paid my spotify bills via Paypal, switched to credit card now, which didn't change anything.
I also tried to switch to a different (paid) spotify account.

Earlier today, all of a sudden it worked and I had no idea why. No I'm back with the original problem... I don't get it.

So it didn't work, later it worked and now it doesn't work anymore again?
You should check for service outages on the Spotify website.
Or maybe you could upgrade to latest Iris version as mentioned in #894.

So it didn't work, later it worked and now it doesn't work anymore again?

Exactly!

You should check for service outages on the Spotify website.

Couldn't find anything unfortunytely.

Or maybe you could upgrade to latest Iris version as mentioned in #894

Already did that, but as Iris is just the frontend I don't think the solution can be found there.

That sounds really weird.
I would still guess that could be some hiccups on Spotify server side or the internet connection
But I would expect something to see in journalctl -u mopidy.

Unfortunately the issue persists (I was hoping that there would be some kind of improvement on the server side).
journalctl -u mopidy gives me two error messages (and I assume that they are unrelated):
ERROR [MainThread] mopidy.internal.log Loading logging config '/etc/mopidy/logging.conf' failed. 'formatters'
ERROR [SpotifyEventLoop] spotify.session Spotify login error: <ErrorType.UNABLE_TO_CONTACT_SERVER: 8>

This issue (although from February)
https://github.com/mopidy/mopidy-spotify/issues/257 mentions that this is probably a issue on Spotify side.
I guess that's not a very satisfying answer for you, but right now I don't have any other ideas.

#901 reported the same issue, workaround was to restart mopidy.
Could you try sudo systemctl restart mopidy and try again, if this works then?

I have the same issue, see #901
What helps is to restart the mopidy server manually (e.g. out of Phoniebox under Folder&Files, you can click on scan music library) and then mopidy is able to login to spotify without any errors and then you can play Spotify. I have no idea yet why this happens and why mopidy is not able to login directly after booting.

Again, directly after booting:
Apr 15 10:58:30 raspberrypi mopidy[453]: ERROR    [SpotifyEventLoop] spotify.session Spotify login error: <ErrorType.UNABLE_TO_CONTACT_SERVER: 8>
Apr 15 10:58:31 raspberrypi mopidy[453]: ERROR    [SpotifyBackend-6] mopidy_spotify.web OAuth token refresh failed: Unknown error.
Apr 15 10:58:31 raspberrypi mopidy[453]: ERROR    [SpotifyBackend-6] mopidy_spotify.web Failed to load Spotify user profile

and after sudo systemctl restart mopidy
Apr 15 11:00:11 raspberrypi mopidy[1063]: INFO     [SpotifyBackend-6] mopidy_spotify.web Logged into Spotify Web API as kfuzej1pajj038nhge0w1af92
Apr 15 11:00:11 raspberrypi mopidy[1063]: INFO     [SpotifyEventLoop] mopidy_spotify.backend Logged in to Spotify in online mode
Apr 15 11:00:47 raspberrypi mopidy[1063]: INFO     [SpotifyBackend-6] mopidy_spotify.playlists Refreshed 18 Spotify playlists

I know this is a bad, maybe temporary, solution, but could we just write a script to automatically restart the mopidy server as the last step of the booting procedure? How could we do that?

Most useful could be to add a prerequisite to the mopidy.service that internet connection must be available.

Most useful could be to add a prerequisite to the mopidy.service that internet connection must be available.

How? :-)

There are two parts to Mopidy-spotify:

libspotify - Spotify's closed-source c library, mostly just used for playback these days. Spotify's libspotify servers sometimes have issues. In the logs this is spotify.session and SpotifyEventLoop.
Web API - a newer interface used for searching, playlists, images. In the logs this is spotify.web.

Each part will login separately (using different Spotify servers and different methods) and it happens in the same order that I specified them above.
Between these logs and the ones in #901, sometimes the session fails to connect but web is OK, and sometimes both fail. But I don't see anywhere where the session connects but web doesn't. To me that sounds like either the Internet connection sometimes becomes ready between the two logins. Or Spotify's libspotify servers have an issue. They actually have a pool of load balancing servers and it's been known for some of them to sometimes not work reliably but this is usually fixed within a few days.
To me, the Internet connection not being ready is far more likely. The delay to connect will vary on your network load, particularly if you are using WiFi. I have no idea how your systems are configured but you should be enabling the raspi-config option that waits for the Internet to become ready during boot.  If you could confirm you have enabled that setting we can go from there.

Yes, I'm using WiFi to connect.
How can I enable the option in raspi-config that waits for the Internet to become ready during boot? I didn't enable this proactively? How can I check?

That's it! Solved. Followed this steps for the raspi-config wifi boot option:
https://raspberrypi.stackexchange.com/questions/45769/how-to-wait-for-networking-on-login-after-reboot
Now rebooted twice and all looks good, Spotify plays immediately. No login issues any more.

That's great. I'd recommend that be made the default setting for this project, if possible.

First of all, I'm very happy we got to the bottom of this and found at least a workaround.

That's it! Solved. Followed this steps for the raspi-config wifi boot option:
https://raspberrypi.stackexchange.com/questions/45769/how-to-wait-for-networking-on-login-after-reboot

The only concern I have is offline functionalty. In an ideal scenario I would like my phoniebox to work without internet connection as well. AFAIK mopidy is needed even for playing offline files, correct?
Hence the phoniebox wouldnt boot all the way if there is no internet connection if set up this way.

The only concern I have is offline functionalty. In an ideal scenario I would like my phoniebox to work without internet connection as well.

I agree with you that a default prerequisite for internet connectivity may not work for all users, especially Classic edition without streaming.

AFAIK mopidy is needed even for playing offline files, correct?

Yes, that's right the Spotify edition also uses mopidy for local music.
I think we should at least document this in the Troubleshooting FAQ.
Maybe we should also add a more meaningful button/label to the web UI, so users could restart mopidy.

I see, apologies, I didn't realise you also had that use-case. Please ignore my suggestion!

@MiczFlor, it might be a good first step to add some more details in the web UI that a scan also restarts Mopidy. So users could  just click to fix that issue.

Before I make another bad suggestion because I don't know much about this project, can I just check that you know Mopidy-Local v3.x can update the local database without requiring a restart?

Did anyone come up with a way to avoid the issues discussed in this thread whilst maintaining offline functionality.
I'm thinking of all the hours our little ones have to spend in the car while on their way for summer vacation and all the good a functioning phoniebox could do to their parents :-)

If you click in the web UI to rescan the library after a reboot, mopidy is also restarted, which should fix the issue (until next reboot).

Thanks!
However, I am not quite sure how that would work in practice in an environment where I don't have internet access (hence I can't access the web UI).

Yes, you are right.
There's a hotspot mode since 2.0, but this could need some configuration.
What you could try is to use a RFID card and hack a system command triggered by the RFID card.

@s-martin You need to keep in mind that mopidy needs to be at least once connected in order to play local content. If mopidy does not connect the local playout is not possible. see #898

Hm, I think you're right.
But that would mean that a offline mode is not possible for Spotify edition.
So we could add a fix to wait for internet connection before start of mopidy in Spotify edition.
But for @JuliH29 and others, their use case to use Spotify edition also in offline mode would not work.

I'm bit confused when you say Spotify edition. My understanding was, that there is no classic version anymore. When you say Spotify edition, does that just mean that during the installation the Spotify credentials are entered?
So my understanding is that with Mopidy there is no offline functionality possible. With that I understand that offline is never possible because Mopidy is always used?
A workaround could be using out of the box solutions like Raspotify or Shairport Sync

Thank you for all your comments.
So to summarize we can say, that at the moment the Spotify Edition does not offer offline funtionality (even for local files).
For me that would definitely be a feature which would make Phoniebox even stronger.

I'm a little confused about one thing still. If you don't configure the Spotify username or password, Mopidy-Spotify will not start and it won't cause any problem. It also makes no sense to configure the Spotify credentials for an offline system that can't possibly use Spotify. What am I missing?

The thing is that AFAIK even though there is only one installer now (in contrast to two separate installers before) which installs eithers the Spotify edition or the classic edition (so two different pieces of software).
In my eyes (and my use case) it makes total sense to configure spotify for an offline system. You might use Phoniebox in an environment where you have internet access (at home) most of the time but would also like to use it in other places where internet access is not guaranteed (in your garden, in your car, train...).

@kingosticks thanks for confirming.
I think it's about the flexibility. So for me/my kids the use case would be at home with spotify streams but also take the box to the grandparents where no wifi access is available to just play the local content or as JuliH29 mentioned, during long distance drives for vacation.

Right OK, that explains it, thanks both. So these systems are sometimes offline, and sometimes online. This is not a traditional usecase for a computer so I don't think Mopidy behaves unreasonably. However, I'll see if there's something simple we can improve in Mopidy-Spotify to handle this situation better.

So these systems are sometimes offline, and sometimes online.

Exactly.

However, I'll see if there's something simple we can improve in Mopidy-Spotify to handle this situation better.

That would be great!

The thing is that AFAIK even though there is only one installer now (in contrast to two separate installers before) which installs eithers the Spotify edition or the classic edition (so two different pieces of software).

Yes, that's correct. The install script let's you choose between Classic edition (uses MPD, very fast startup and works offline, too) and Spotify edition (uses mopidy, works only (to be confirmed) online, somehow slower startup, can access Spotify premium accounts).
While I see the use cases working offline with Spotify edition, too, my current understanding is that right now this is not possible. If @kingosticks finds a workaround/solution that would be great. Otherwise I think we have reached a dead end here.

Hey guys, this is exactly my use case too. Using Spotify at home and local files on the road just like the "Toniebox" works. I was surprised to read that this is not possible at the moment. @kingosticks if you find a workaround or rather solution for this i would be very greatful!

I added a description to the Troubleshooting FAQ:
https://github.com/MiczFlor/RPi-Jukebox-RFID/wiki/Troubleshooting-FAQ#spotify-does-not-connect-or-is-really-slow-to-connect

Currently no real fix available, workaround described in https://github.com/MiczFlor/RPi-Jukebox-RFID/wiki/Troubleshooting-FAQ#spotify-wont-play-but-after-scan-of-library-it-works

We also just merged this, which should help: https://github.com/mopidy/mopidy/pull/1946

We also just merged this, which should help: mopidy/mopidy#1946

Cool. Do you have an estimate for the release of 3.1?

-3 days ago :)
https://github.com/mopidy/mopidy/releases/tag/v3.1.0

Although, I'm not actually sure that has been pushed to apt.mopidy.com...

-3 days ago :)
https://github.com/mopidy/mopidy/releases/tag/v3.1.0

Do I understand correctly that this would improve the performance of an online (=Spotify) installation but wouldn't provide offline functionality to it?

I just ran into the same issue @JuliH29 has described in the initial post.
I am running Mopidy 3.1.0 with Mopidy-Spotify (4.1.0, I manually upgraded from 4.0.1 to check if this fixes the issue).
I have enabled the "Wait for Network on Boot" option in the raspi-config.
I am using WiFi if this matters.
After entering my Spotify (Familiy Premium Account) credentials in the mopidy config file the account was recognized in Iris, I could see my Playlist and the Covers of songs in the Phoniebox UI.
In the Iris settings the account was marked as read-only/restricted access. After logging in through Iris the account shows up as "Autorized" but this did not fix following issue for me.
I am getting the following error directly after booting:
INFO     [SpotifyBackend-6] mopidy_spotify.web Logged into Spotify Web API as XXXX ERROR    [SpotifyEventLoop] spotify.session Spotify login error: <ErrorType.UNABLE_TO_CONTACT_SERVER: 8>
When trying to play a song through the Phoniebox UI (I see the cover) by adding the Spotify URI to a card I see the following in the mopidy log:
[SpotifyBackend-6] mopidy_spotify.lookup Failed to lookup 'spotify:track:7HXBU3UqdSSzKYMFSLpAKD': Session must be logged in and online to load objects: <ConnectionState.LOGGED_OUT: 0>
In Iris I can search Spotify without any issues. When I try to start a song directly through Iris I get the same error:
[SpotifyBackend-6] mopidy_spotify.lookup Failed to lookup 'spotify:track:10waMsh44ojvTwXAIy213n': Session must be logged in and online to load objects: <ConnectionState.LOGGED_OUT: 0>
Manually restarting mopidy, a complete reboot or clicking the "scan library files" button in the Phoniebox UI does not fix the issue for me.
I am experiencing this on a fresh install since at least three days.
Do you have any idea what the issue could be?
From what I have read on multiple sources the issue should not be regarding the network connection because it's mopidy 3.1.0, I tried manually restarting mopidy and the "wait for network on boot" option is enabled.


Improve NavigationObstacle3D usability

This PR is:

Fixing NavigationObstacle3D to be attached to navigation map - without it the NavigationObstacle3D is not working.
Replacing radius approximation algorithm with simple "radius" property.

Ad. 2. Rationale

radius approximation algorithm (currently in master) is counter-intuitive and misleading - when I've first seen the NavigationObstacle3D I was surprised it has no radius just like NavigationAgent3D does.
radius approximation may be done several ways while the algorithm uses only one solution which makes it not flexible at all
radius approximation algorithm is a code that has to be maintained

In general, I suspect the NavigationObstacle3D is just the early draft from early work of @AndreaCatania and it was never properly aligned with other navigation elements.
@AndreaCatania @groud  could you please take a look at my changes and comment?

Thanks!


Update libmemcached config.guess/config.sub to latest

When trying to install this gem on Ubuntu 22.04 on ARM, I'm experiencing the following failure:
checking build system type... config/config.guess: unable to guess system type

This script, last modified 2009-04-27, has failed to recognize
the operating system you are using. It is advised that you
download the most up to date version of the config scripts from

http://git.savannah.gnu.org/gitweb/?p=config.git;a=blob_plain;f=config.guess;hb=HEAD
and
http://git.savannah.gnu.org/gitweb/?p=config.git;a=blob_plain;f=config.sub;hb=HEAD

If the version you run (config/config.guess) is already up to date, please
send the following data and any information you think might be
pertinent to<EMAIL_ADDRESS>in order to provide the needed
information to handle your system.

config.guess timestamp = 2009-04-27

uname -m = aarch64
uname -r = 6.1.29-0-virt
uname -s = Linux
uname -v = #1-Alpine SMP Wed, 17 May 2023 14:22:15 +0000

/usr/bin/uname -p = aarch64
/bin/uname -X     =

hostinfo               =
/bin/universe          =
/usr/bin/arch -k       =
/bin/arch              = aarch64
/usr/bin/oslevel       =
/usr/convex/getsysinfo =

UNAME_MACHINE = aarch64
UNAME_RELEASE = 6.1.29-0-virt
UNAME_SYSTEM  = Linux
UNAME_VERSION = #1-Alpine SMP Wed, 17 May 2023 14:22:15 +0000
configure: error: cannot guess build type; you must specify one

Updating the gem's copy of libmemcached with the latest config.guess and config.sub (as suggested in the error) resolved the issue for me. This should close https://github.com/arthurnn/memcached/issues/210 and https://github.com/arthurnn/memcached/issues/161.

9 years later... bump. I've got the same issue. Can this be merged?

Bump. I've got the same issue. Can this be merged?

same here :/

Bump. I've got the same issue. Can this be merged?

same here is there any workaround to get this work for m1 macs


chore: remove title case from short command descriptions

Most command descriptions follow Ory's official guideline of using sentence case. Some descriptions deviate by using title case.
Checklist

[x] I have read the contributing guidelines
and signed the CLA.
[ ] I have referenced an issue containing the design document if my change
introduces a new feature.
[x] I have read the security policy.
[x] I confirm that this pull request does not address a security
vulnerability. If this pull request addresses a security vulnerability, I
confirm that I got green light (please contact
<EMAIL_ADDRESS>from the maintainers to push
the changes.
[ ] I have added tests that prove my fix is effective or that my feature
works.
[ ] I have added necessary documentation within the code base (if
appropriate).

Can you please address the merge conflict? :)

@aeneasr merge conflict resolved PTAL


Allow user customisation of the the Box Chars

It would be brilliant to allow custom modes where the user can specify the Box Chars. It could allow weird/creative behaviours with minimal change in the final code. I might follow up with a pull request. Stay tuned :D
(Thanks for the brilliant work, BTW).

Do you mean for use with something like Braille Patterns?

Sure, why not. Even if I was thinking of also something more “artisty” like
letters, emoji or anything, actually.
Or other types of glyphs if a different font is used by the term.
On Sun, 20 Feb 2022 at 17:48, Sergey Mudrik @.***>
wrote:

Do you mean for use with something like Braille Patterns
https://unicode.org/charts/PDF/U2800.pdf?
—
Reply to this email directly, view it on GitHub
https://github.com/msoap/tcg/issues/1#issuecomment-1046288099, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AADZZ65USLWQEPYCJZGJW5DU4ESN5ANCNFSM5O4WDRKA
.
You are receiving this because you authored the thread.Message ID:
@.***>

--
Ciao,
r-
((lambda (x) (list x (list 'quote x))) '(lambda (x) (list x (list 'quote
x))))

emoji or something like that will be difficult to use because the library is designed for a pixel grid

Well, depending on the configuration of pixels in a group it choses the
right glyph to render. If the glyph has the same estetic as the pixels
configuration you get a “meaningful” image. But they do not have to, do
they 😀.
Weird effects could be achieved this way.
On Sun, 20 Feb 2022 at 21:47, Sergey Mudrik @.***>
wrote:

emoji or something like that will be difficult to use because the library
is designed for a pixel grid
—
Reply to this email directly, view it on GitHub
https://github.com/msoap/tcg/issues/1#issuecomment-1046327409, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AADZZ65PNYCI3UX4YK34653U4FOPFANCNFSM5O4WDRKA
.
You are receiving this because you authored the thread.Message ID:
@.***>

--
Ciao,
r-
((lambda (x) (list x (list 'quote x))) '(lambda (x) (list x (list 'quote
x))))

If the glyph has the same estetic as the pixels configuration you get a “meaningful” image

Yeah, it makes sense


[refactor]: update iroha_cli_derive to use syn 2.0

Description
A part of #3682
Seems like we do not need to introduce manyhow and darling for this crate

Linked issue

Closes #4117

Benefits

Checklist

[x] I've read CONTRIBUTING.md
[ ] I've used the standard signed-off commit format (or will squash just before merging)
[ ] All applicable CI checks pass (or I promised to make them pass later)
[ ] (optional) I've written unit tests for the code changes
[ ] I replied to all comments after code review, marking all implemented changes with thumbs up

Seems like we do not need to introduce manyhow and darling for this crate

There's definitely no use for darling here, but I still prefer to use manyhow in macros that don't return errors, as it handles the proc_macro2::TokenStream to proc_macro::TokenStream conversion, allowing us to not mention any proc_macro types.

There's definitely no use for darling here, but I still prefer to use manyhow in macros that don't return errors, as it handles the proc_macro2::TokenStream to proc_macro::TokenStream conversion, allowing us to not mention any proc_macro types.

Done!
Added manyhow to the project.

The code is good, although the first two commits are missing sign-offs.
Here's a seemingly sane guide onto how that can be done retroactively


Automated Package Upgrade

:tada: This PR is included in version 25.4.2 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


Remote Server/Compatible clients?

I have a remote Plex server and am running bw_plex on a (Windows 10) computer on my local network.
It's saying it is calling the jump but nothing is happening
2018-06-18 15:09:19,005 :: bw_plex :: DEBUG :: Called jump with <bw_plex.db.Processed object at 0x000000001FE23668> 632 28.4212244898 None
2018-06-18 15:09:19,005 :: bw_plex :: DEBUG :: Called client_action with 28.4212244898 00:28 632 None
2018-06-18 15:09:19,066 :: bw_plex :: DEBUG :: client Bedroom 9

Apple TV is my primary client but I figured maybe it didn't work so I tried some others
PMP on macOS and Windows (the machine running bw_plex), Plex/Web via Safari and Chrome, Plex on iOS, Plex for Kodi.
Are any of these clients supported or am I doing something wrong?  I know having remote clients doesn't work but does a remote server not work either?

I have tested this on iOS (iPhone, had to reboot iPhone first), openpht, plex web (buggy). I did a real quick test on one of the pmp modes, I can’t remember which and it worked (it was like a one sec test) I don’t have a remote server to test with. Any change you can install pms on the same computer that has bw_plex installed?

I might be able to later but I don't store media locally.  When you call the jump is that a command sent to the server or directly to a client?  My PMS has no way of reaching my clients (firewall, shared ports, etc), unless the clients maintain some sort of connection with the server waiting for commands like this.

I’m pretty sure I try to send the command via pms. If you dont mind getting you hands dirty you can try to comment out https://github.com/Hellowlol/bw_plex/blob/master/bw_plex/plex.py#L711

Tried commenting that, didn't make a difference.  No worries, though - I think having a remote PMS is not a common setup.

I’ll look into it. :)

I think the remote control command you send to PMS uses Plex Companion, so the PMS has to be able to access your client somehow.  On the port forwarding page for plex it shows the companion ports for PHT (discontinued) and Roku - neither of which I have, but none of the other clients.  Old help page needs to be updated.  Either way if it uses the same port on each device it's not going to work because of NAT, and PMS isn't going to be aware of the LAN IP for the client in question so bw_plex won't be able to contact the client directly anyway without a lot of effort.
Remote servers (and remote clients) should probably work fine then if the correct ports are open.

So i have started on a wiki to document what client works. If you want to test this your should include do  bw_plex --debug watch as this includes the httpcalls so it easier for see why something fails. If you ca verify a new client please update the wiki.

Closing this. If you verify that a client works. please update the wiki.


Add more details to status table in merged_flow

When creating elists, it might be nice to add some info to the status table (e.g. merged_flow), including the start and end dates of the record and number of samples that makes it into the analysis. This will differ from earlier calculations because some samples got cut due to flow record matching issues.

This is now done in the merged_flow step - will allow us to keep track of site-parameter combos that may have data issues (e.g., high proportion of censored values).


point to main: option to turn off survey is merged

the ability to turn off surveys in the trachoma repo is now merged to main, so point dependencies for this repo at main and not the branch with this ability to turn surveys off in it. This is important as the branch which it was pointing to doesn't have the correction to updated MDA from https://github.com/NTD-Modelling-Consortium/ntd-model-trachoma/pull/59

@mattg3004 Your tests were only failing due to a bug in the main branch - so once I merged that in this all worked. PS when I'm back let me show you how you can run the tests locally, a bit less painful that pushing up to CI to see if it works!


write data to configuration

After usage of resol-vbus-python now is working excellent I wonder if it is possible to add the other side: writing data to configuration. This is technically working - take a look at https://danielwippermann.github.io/resol-vbus/#/md/docs/customizer-example . So it would be nice if I could

get a list of all configurable variables
read values of such variables
change values (setting blocks active / inactive, set relais outputs on/ off / auto)

If I can do this I will be able to optimize the complete system with external influences like weather forecasts.

@danielwippermann is a developer of Resol. I think if you are knowing what you do it is not dangerous. Because of you write this data to a flash-based memory you should not spam write accesses to the device - thats all. I am actually trying to port the java code to python. https://github.com/danielwippermann/resol-vbus-java/tree/master/vbus-example/src/main/java/de/resol/vbus/example/parameterization


SDK Proposal: Activity Worker

Summary
This PR is the basis for a discussion about the Activity Worker SDK.
The scope of the SDK component discussed in this proposal is to allow hosting arbitrary Temporal activities written in .NET.
This SDK component will be built on top of Core.

NOTE:
This is opened here rather than in the proposals repo to streamline the process:
We make sure that the proposed API surface actually compiles in the context of the larger SDK. That could not be achieved as easily within temporalio/proposals.

Related work items

https://github.com/temporalio/sdk-dotnet/issues/99

Details
This proposal for the Activity Worker SDK consists of 2 parts:

Src/Samples/ActivityWorker.UsageSamples/Temporal.Sdk.ActivityWorker.UsageSamples/public/Program.cs:
Demonstrates the proposed API surface in 12 small samples.
Src/SDK/ActivityWorker/Temporal.Activities.Worker/public/Api.cs:
Implements the proposed API surface. Only the signature definitions are provided, plus the minimal amount of code to validate the feasibility of implementation.

The samples to review are:

Sample01_MinimalActivityHost
Sample02_HostSimpleSyncActivities
Sample03_HostSimpleAsyncActivities
Sample04_NonStaticActivityMethods
Sample05_NewClassInstanceForEachActivityInvocation
Sample06_MultipleArguments
Sample07_UnderlyingMechanicsA
Sample08_UnderlyingMechanicsB
Sample09_Heartbeat
Sample10_ParallelThreading
Sample11_WorkflowActivityContextA
Sample12_WorkflowActivityContextB

Review process
We will review this proposal using the steps below.

NOTE:
We welcome feedback from everybody at any time.
Please, however, be aware that in order to keep the process going, we will prioritize this order, in case there is a lot of feedback on specific items.

Collect feedback from currently active contributors.
(@mightyshazam, please take note 😃)
Incorporate the feedback and update the proposal.
Collect feedback from the Temporal SDK team.
Incorporate the feedback and update the proposal.
Collect the feedback from the wider community. Start implementing the proposal.
Update the spec and the implementation based on continuous feedback from the community.

Sorry to jump in here, I am not quite firm with the internals, just want to share the idea.
As far as I understand, the current approach is to register workflows and activities with a worker, either explicitly or by using attributes and then invoke them via these workers.
Would it be also an idea to write workflow&activity classes again an iface and then create a dynamic proxy like you do with mocking libraries or lazy loading in ef core, which would then handle all the temporal delegation?
Like that, using temporal would be transparent to the consumer code…
Of course injecting context etc. would not be as straight forward…


When a package doesn't have a minified version, spinner should not be displayed

Reproduce Steps
Search for "deep-freeze" & select a version.
In the last step, the spinner is displayed because the package doesn't have a minified version.

Suggestions

Display a message "This package has no minified file(s).".
or
Turn off minified checkbox.

Works!


Use env for repro tests, improve repro names

This PR:

Removes the reproducibility_test flag in the yaml config, and we instead use an environment variable. I don't think experiments should explicitly need to worry about this, and there's no way for users to leverage this feature locally anyway, so an env flag seems more appropriate.
Improves some names to better reflect what some reproducibility test functions are doing.

What's the issue with the 4 GPU job?

What's the issue with the 4 GPU job?

Not sure yet, still needs fixes..

I incremented the reference counter because I think it's far easier to "reset" our comparable references than to support comparing data exported from HDF5 formats (which we now use to support reproducibility tests for GPU jobs) with NC files (which we previously used).

If the restart job gets tripped up again, then I'll manually merge.


Add Build Flags -trimpath -buildmode=pie -s -w

Issue #, if available:
N/A
Description of changes:
Add build flags to reduce binary execution/size
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

stale


[Request] Add lang detection API (getLanguageFromCode) without highlighting

Please add API like getLanguageFromCode(code, languageSubset) which will work as currently available highlightAuto(code, languageSubset) but without the highlighting (will not return value which contain HTML string with highlighting markup) thus will run faster and it will be useful for using the auto-detection mechanism.
also support getLanguageFromCode(code) which will act as languageSubset contain all available/supported languages

Great idea, though I don't believe it would actually run that much faster (in the real world)... Also, if you really need this behavior you can already achieve it easily enough with a custom emitter (that emits nothing)... so this isn't a feature we need to add to core.
You can find the default tree emitter:
https://github.com/highlightjs/highlight.js/blob/master/src/lib/token_tree.js
Most importantly we are a highlighter, not a language classifier.  The core library will stay focused on highlighting.  If you (or anyone else) would like to write a small plug-in that uses our grammars for classification that'd be great - although there also plenty of existing libraries out there that already do classification.


Fixing memory leaks

Valgrind has found 4 memory leaks in xrdp-sesman. No leaks have been found in the xrdp binary. No memory leak is major, but it's good to fix them to keep our coding standards high.

Looks good.

Let's merge.


xdot: unbreak build

Motivation for this change
Fix xdot build failure on hydra.
Things done

[X] Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS linux)
Built on platform(s)

[X] NixOS
[ ] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[X] Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
[X] Tested execution of all binary files (usually in ./result/bin/)
[ ] Determined the impact on package closure size (by running nix path-info -S before and after)
[ ] Ensured that relevant documentation is up to date
[X] Fits CONTRIBUTING.md.

Result of nixpkgs-review pr 108020 run on x86_64-linux 1

3 packages built:

python37Packages.xdot
xdot (python38Packages.xdot)
python39Packages.xdot

duplicate, but different approach to #107872

Oops, I should have checked for other PRs first. Closing.


Deprecated APIs Removed In 1.16: DaemonSet in the extensions/v1beta1 and apps/v1beta2 API

Deprecated APIs Removed In 1.16:
Deployment in the extensions/v1beta1, apps/v1beta1, and apps/v1beta2 API versions is no longer served
Migrate to use the apps/v1 API version, available since v1.9. Existing persisted data can be retrieved/updated via the new version.
Issue #, if available: https://kubernetes.io/blog/2019/07/18/api-deprecations-in-1-16/
Description of changes: changed argo v2.2.1 to v2.8.2
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

thanks @manishdhawaria for the PR. I'm currently in the middle of changing our default branch. Since this PR has conflicts that must be resolved before merging, I'm going to close... can you re-open once the default branch has been renamed? (you'll probably have to re-fork)


Typo in README: the Requirements section is incorrect

Currently, the Requirements section of README.md says

Windows 7 SP1 through Windows 10 (1708) or Windows Server 2008 R2 SP1 through Windows Server 2016

However, there is no such a version of Windows 10 called 1708.
Besides, based on my test, Chocolatey GUI 0.16.0 works on Windows 10 Version 1903.
Please solve the problem to get rid of confusion.
Thanks.

@Lemmingh thank you for raising this. I believe I have clarified this in this recent commit:
https://github.com/chocolatey/ChocolateyGUI/commit/3750053af87b6386d5acf175d1da0b3d7f06707f


v0.4.0

This version attempts to this package with align ReScripts v11 uncurrying standards. It required us to explicitly type our parameters and uncurry our return value definitions.
If this PR passes review, I would prefer us to go this route over the "uncurried": false configured PR as this will be enforced behavior in Rescript 12.
Both PRs update the package.json dependencies and remove "@glennsl/bs-jest" as it was abandoned and had numerous security advisories

Everything here looks good. This is probably the direction we need to go anyway, but I'm curious what we'll have to do in Kraken to make it work. Will it just drop in, or will we have to completely uncurry the Xml.Decoder stuff in Kraken?

Everything here looks good. This is probably the direction we need to go anyway, but I'm curious what we'll have to do in Kraken to make it work. Will it just drop in, or will we have to completely uncurry the Xml.Decoder stuff in Kraken?

Seemingly no changes are required from Kraken to use the updated library. I pulled in this branch and fixed a build issue with older versions of ReScript not knowing what rescript.json was.


HOWTO: Добавить гайд по i18n

От app до shared

Можно посоветоваться с @karina-jovian

It's hard to recognize how it concluded to  contributors from other languages. can you also provide for English version?

@dante01yoon I don't think it's practical to translate all of these old conversations. These conversations are more for internal use, as guidance about how to write docs, but if you would like to know what they say, you can use Google Lens to translate images

Any updates?

Not yet, but thanks for letting us know that you're interested! We will keep it in mind when we get to writing more guides.


Consider adding a human intervention

Consider adding a human intervention? Like AutoGPT, there are times when the program repeats an impossible task, and we can manually intervene.

Hey @chen9965
It will be a great plan to add human feedback or intervention during running program. i think i have seen this in AutoGPT as well as Agent GPT.
look forward to this feature. what's your opinion on this @joshbickett ?

@Yash-1511 @chen9965, I think human intervention could help in some cases, but if it makes sense since this project's vision is to let it be a "self-operating computer". It may make sense to fork this project into something different to add this.

Hey @chen9965
It will be a great plan to add human feedback or intervention during running program. i think i have seen this in AutoGPT as well as Agent GPT.
look forward to this feature. what's your opinion on this @joshbickett ?

 I reckon @joshbickett is right: should we just fork it and replicate bascially what AppAgent has done for android but on desktop? Using say, pyautogui and threading libraries @Yash-1511 ?


move from class to functional for client

hot new style: let's try functional components instead of classes

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

TBD where we land on this - but now I've put other changes into the branch
so may need to cherry pick out if we go back to classes / just re-implement
classes
On Mon, Sep 16, 2024 at 3:32 PM Tom Ballinger @.***>
wrote:

@.**** approved this pull request.
🔥
—
Reply to this email directly, view it on GitHub
https://github.com/get-convex/templates/pull/14#pullrequestreview-2307947359,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AACZQW2DA7DQHPUXD27AJLLZW5MATAVCNFSM6AAAAABOKHGV4WVHI2DSMVQWIX3LMV43YUDVNRWFEZLROVSXG5CSMV3GSZLXHMZDGMBXHE2DOMZVHE
.
You are receiving this because you authored the thread.Message ID:
@.***>

going with classes for now


lang: new internal writer to use bpf mem syscalls

resolves #1585

CreateOfficer  from the cfo test goes from Program consumption: 83366 units remaining to Program consumption: 91197 units remaining.
Huge difference

might have to keep using Cursor for non bpf targets. we're not sure if it's necessary.
https://discord.com/channels/428295358100013066/517163444747894795/950946676670078986

might have to keep using Cursor for non bpf targets. we're not sure if it's necessary. https://discord.com/channels/428295358100013066/517163444747894795/950946676670078986

ok cool, just let me know when you find out. I'll add some target arch checks in there for the writer instantiations.

@paul-schaaf do the target arch configs in the source code not deal with this?

oh thats right they do!


Metadata about CIDR's or IPs

Is there a idiomatic way to store metadata like name and alike for the various CIDRs/ IPs ?

No, this is not implemented and also not desired, because go-ipam is designed to be as fast as possible, and adding meta data to the IPs/Prefixes would add quite a lot of data.
We at metal-stack store these information alongside the gathered IP/Prefix.


Removing instance group does not remove QuarksStatefulSet

Describe the bug
When an instance group is removed from the deployment manifest, the corresponding instance group is not removed.
To Reproduce

Deploy KubeCF.
Wait for it to settle.
Apply the following ops file†:

- type: remove
  path: /instance_groups/name=nats

Reinstall the helm chart (as an upgrade).

† This can be accomplished with a custom values.yaml for the kubecf chart:
system_domain: blah.example.com
operations:
  inline:
  - type: remove
    path: /instance_groups/name=nats

Expected Behaviour
The nats QuarksStatefulSet should be removed.
Actual Behaviour
The nats QuarksStatefulSet remains.
Environment

CF-Operator Version: v5.0.0-0.gd7ac12bc
KubeCF master

Additional context
Manually deleting the QuarksStatefulSet doesn't make it come back again.
It does have the correct information, so that we should be able to track it:
metadata:
  creationTimestamp: "2020-07-07T22:39:58Z"
  generation: 1
  labels:
    quarks.cloudfoundry.org/deployment-name: kubecf
    quarks.cloudfoundry.org/deployment-version: "0"
    quarks.cloudfoundry.org/instance-group-name: nats
  name: nats
  namespace: kubecf
  ownerReferences:
  - apiVersion: quarks.cloudfoundry.org/v1alpha1
    blockOwnerDeletion: true
    controller: true
    kind: BOSHDeployment
    name: kubecf
    uid: 14a54471-b113-4c13-8db9-8daf74682ab9
  resourceVersion: "239622"
  selfLink: /apis/quarks.cloudfoundry.org/v1alpha1/namespaces/kubecf/quarksstatefulsets/nats
  uid: 06252470-f068-4b69-abce-926859edd686

Also note that removing nats does cause all the things that require it to break (because template-render can no longer find the link).  So the changes are being applied, but not wholly.

Hi @mook-as,
Added the feature with this PR https://github.com/cloudfoundry-incubator/quarks-operator/pull/1039. Re-open is you still see the issue.


Make "energy transformation" subclass of "transformation"

Description of the issue
energy transformation and trasformation are both subclasses of process.
transformation is defined as:

A transformation is a process that transforms one or more inputs into at least one output.

energy transformation is defined as:

Energy transformation is a process in which one ore more certain types of energy as input result in certain types of energy as output.

Ideas of solution
Make energy transformation subclass of transformation.
Workflow checklist

[x] I discussed the issue with someone else than me before working on a solution
[x] I already read the latest version of the workflow for this repository
[x] The goal of this ontology is clear to me

I am aware that

[x] every entry in the ontology should have a definition
[x] classes should arise from concepts rather than from words

Thank you. I like this suggestion. transformation is currently in the model module while energy transformation is in the physical module. Does that cause trouble, @akleinau ?

we could just implement transformation in oeo-physical too but I'm not sure if that's the best solution or if it would be cleaner to create a new module for classes that get implemented in all our edits. Or if we should reformulate transformation so this subclass relationship doesn't exist.
@jannahastings what would be best in your opinion/ in line with other ontologies?

I think it might be best if we create an "oeo-shared" module in which we implement classes that are needed in multiple modules. This would also allow us to implement relations that are needed in multiple modules, which I think we already do have, although we don't have any other classes. An advantage is that we could simplify our imports structure as the shared module could handle the imports that are currently repeated in all the edits modules. But of course the disadvantage is that it would represent quite a significant change to our module structure.

An alternative name for the "shared" module might be "core"?

"core" to me sounds like that is the main module of our ontology which would be a wrong conclusion.
I like "shared" though

then I'll implement. The only thing that could get merge conflicts because of that is the vehicle branch but I hope this will work fine too.


🔒 Feature Request - Automatic SSL certs with mkcert

Hi @typicode !
First and foremost, thanks for the useful tool. I use it almost every day at work and it's been amazingly great so far, kudos 🙏 !
Would it be possible to integrate something such as @FiloSottile/mkcert to have automatic ssl certs generated when we add or remove a server ?
I've done it manually (replacing cert.pem and key.pem in the .hotel dir with the mkcert generated ones) and it's working perfectly but I would prefer for it to be automated/built in…
Thanks and have a nice day !

@the0neyouseek Hi, this feature came into my mind 2 years ago. And I remember it was also mentioned in other quite a few issues as well. That was why I started this alternative tool and started using it since.
https://github.com/layerssss/localhostd
It has gone through my own trial and fixes these 2 years and had a few additional features including trustable SSL built in. So I'm now inviting everyone to try it as well.

@the0neyouseek

I've done it manually (replacing cert.pem and key.pem in the .hotel dir with the mkcert generated ones)

Which names did you use when creating the cert with mkcert? I tried *.localhost, but that doesn't work, since wildcards on TLDs aren't supported.

@shreyasminocha Here's the command I've used :
mkcert localhost <IP_ADDRESS> hotel.localhost <name-of-project>.localhost followed by any domain where I need ssl.
It's a bit of cumbersome process to do this manually and I would prefer it if hotel generated the cert itself on every domain creation/removal but it works.

@the0neyouseek Thanks! I thought there was some shorthand that worked with all .localhost domains.

It's a bit of cumbersome process to do this manually and I would prefer it if hotel generated the cert itself on every domain creation/removal but it works.

Agreed.

Here's a one-liner that works for me:
ls ~/.hotel/servers | sed -E 's/\.json/.localhost/g' | tr '\n' ' ' | xargs mkcert -key-file ~/.hotel/key.pem -cert-file ~/.hotel/cert.pem 'localhost' '<IP_ADDRESS>' '<IP_ADDRESS>' 'hotel.localhost'


[dv/otp-ctrl] add flash and otbn using push-pull agents

This PR adds the two other key interfaces - flash and otbn using push
pull agents
Signed-off-by: Cindy Chen<EMAIL_ADDRESS>

The CIs are passing here:
https://dev.azure.com/lowrisc/opentitan/_build/results?buildId=24558&view=results
https://dev.azure.com/lowrisc/opentitan-private/_build/results?buildId=24557&view=results


chore: Bump karpenter-core for machine cluster state change

Fixes #
Description

Bump karpenter-core for machine cluster state change

How was this change tested?

make presubmit

Does this change impact docs?

[ ] Yes, PR includes docs updates
[ ] Yes, issue opened: #
[ ] No

Release Note

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

/karpenter snapshot

/karpenter snapshot


NestJS in nx workspace as an Azure function

As a developer, I want to have the possibility that I can deploy my nestjs application with infrastructure as code to Azure.

First thing we need is a builder, becasue

azure functions require js files per function
all available builders create a single bundle

I have manually configured an nx app (based on @nrwl/node that contains an azure function project which builds fine. But without the ability to output multiple files when building we would only able to create a single function per project :)
I'm no expert in webpack but looking at:

the current node webpack config
and this article

It looks doable without major surgery. That said I never build an angular builder :)
After getting azure functions to build the next would be to tackle:

schematic for creating an azure function app
schematic for adding new function

After that one can look creating schematics for specific apps like nest.

Update:

this following azure function webpack plugin  looks promising. Its based on the previously azure-fucntion-pack package which is no longer maintained
it scans the entry directory for functions.json files and uses those to build the individual functions
we would also need to resolve tsconfig patsh properly, luckily there seems to be a very well supported webpack plugin for handling that

Thanks a lot for all the input! I will try to check how I can fit it into this project! But let's start with small steps. So first thing we should do is to be able to deploy a nestjs app with 1 function. than we can go ahead with splitting in multiple functions.
I know from Kamil they they are working on a feature there where you can set separate functions via decorator on modules. Hope this lands soon to nestjs
https://github.com/nestjs/serverless-core

Not easy to integrate it as easy as possible :(
2 options are there:

you need to maintain a separate package.json with all the dependencies for the node / nest app
Find a way to automatically align all required dependencies. Here I am trying at the moment this package: https://github.com/zeit/ncc but seems not to work. Trying still to make a workable solution with it.

Ok figured out that the problem was just a wrong runtime version of node on azure :) so ncc is working amazingly! I will go for it

Implemented first version by #24


Change RucioConMon APIs' prefix.

Fixes #11388
Status
ready
Description
With the current PR we are changing the API prefix of the RucioConMon Url. There has been a change/rearrangement of the APIs' paths on the Rucio Consistency Monitoring  side, which was not reflected in our code.
Is it backward compatible (if not, which system it affects?)
NO
NOTE: We need to wait for confirmation from Rucio Team the change is about to be permanent, before we merge and patch our production services.
Related PRs
None
External dependencies / deployment changes
RucioConMon server

hi @amaltaro , In this case I tend to disagree. I know it is uncomfortable to have an url in hardcoded, but in this case it was not the server url hardwired into our code. This is  part of the API structure that  has changed on the Server side. The server part of the Url is still unchanged.  This  server does provide more than one APIs on it like:
https://cmsweb.cern.ch/rucioconmon/ce etc. So this is
And we  do have our generic service module RucioConMon created already, which is having a separate function for each such API call for handling the call to the server itself and all resulted error codes and exceptions etc. What has changed here is only the path to the APIs we have been using for MSUnmerged.  I'd prefer to not break the hierarchy structure of the module  and preserve it as it is.

I see. I think we need to understand how is the REST endpoints structured for the RucioConMon service.
If there are different REST mount points than the unmerged in the url below:
https://cmsweb.cern.ch/rucioconmon/unmerged
then I completely agree with you. Otherwise we would be limiting the wrapper module to only the APIs that are required by MSUnmerged.
The ce endpoint from your url is basically an HTML, so I would not consider it for our REST-based wrapper module.

And Igor confirmed that currently there are only these 2 REST endpoints:
https://cmsweb.cern.ch/rucioconmon/unmerged/stats
and
https://cmsweb.cern.ch/rucioconmon/unmerged/files
To me, it would be safer and more robust to make the changes I suggested above.

Hi @amaltaro

I would be inclined to remove the leading slash from the API name

Agreed. Implemented and tested. we are ready to merge I believe.

These changes have been cherry-picked and ported to the 2.1.5_cmsweb branch:
https://github.com/dmwm/WMCore/pull/11393
and a new version has been released on top of that: <IP_ADDRESS>
@todor-ivanov please follow this MSUnmerged deployment up with the HTTP team.

thanks @amaltaro! I am on it now.

And thank you for linking the configuration changes to the original description!


no relate .ts use same name interface notice error

VSCode Version: 1.21.0 x64
OS Version:  Win10

Steps to Reproduce:

a.ts

interface Student {
  name?: string
  age?: number
}

b.ts

interface Student {
  name?: string
  age?: number
}

1 not use module export
2 a.ts and b.ts no relate only with a workspace
3 can tsc translate to .js and no error

why vscode notice has error but tsc can complie to js

Does this issue occur when all extensions are disabled?: No

What is the error? Please share the full error text
Also, this only occurs when extensions are enabled? Try tracking down which one causes this

error notice: All declarations must have the same modifier.

when i create new workspace and create a.ts and b.ts. all is well。so i must think twice. thx u help


Add alternative parametrization for Student distribution

Codecov Report

Merging #99 (f7cb3bf) into main (28d89e0) will increase coverage by 0.20%.
The diff coverage is 95.83%.

@@            Coverage Diff             @@
##             main      #99      +/-   ##
==========================================
+ Coverage   72.12%   72.32%   +0.20%
==========================================
  Files          15       15
  Lines        1668     1684      +16
==========================================
+ Hits         1203     1218      +15
- Misses        465      466       +1

Impacted Files
Coverage Δ

preliz/tests/test_distributions.py
100.00% <ø> (ø)

preliz/distributions/continuous.py
98.39% <95.83%> (-0.12%)
:arrow_down:

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.


Need a plan of the KIngress prober for HTTPRoute

KIngress has prober function but HTTPRoute does not have it.
Additionally, the HTTPRoute's "admitted" status will not work as it is different from "Ready" status. Please see - https://kubernetes.slack.com/archives/CR0H13KGA/p1611865803004000

This is super important for the semantics of our Ingress, but I honestly have no clue on how to generically solve this.
We kind of have a same'ish problem in Openshift where we have a separate routing plane that gets configured for every Knative ingress. The networking setup of these routes can change from cluster to cluster and there is no guarantee that the knative-serving namespace can even reach those routers. There's also no generic way of listing all possible routers which might even be worse with IngressV2, seeing as there will be different implementations on it.
Ideas super welcome :sweat_smile:

Previously all of the net-xyz controllers did their own probing, right? So the closest match to this would be to have all IngressV2 implementors do the same, by pushing for a true "Ready" status field in the API?
That seems like the most pure way to implement it - however, I have some pretty major concerns about implementors actually implementing it correctly for knative semantics. AFAIK no Envoy based implementations would be able to do this without a lot of efforts, which accounts for ~half of the currently implementors I think.

Previously all of the net-xyz controllers did their own probing, right?

Yes but strictly speaking, Knative has a common library for probing as:
https://github.com/knative/networking/blob/45fe1f5dd35eaebaf6f8ce03ab0983ede9497369/pkg/status/status.go#L135
and net-xyz controllers just calls it like:
(e.g. net-istio)
https://github.com/knative-sandbox/net-istio/blob/c4e24bc7750441150ef56e8ece9c937661993c9d/pkg/reconciler/ingress/controller.go#L131-L140
https://github.com/knative-sandbox/net-istio/blob/c4e24bc7750441150ef56e8ece9c937661993c9d/pkg/reconciler/ingress/ingress.go#L230-L233

So the closest match to this would be to have all IngressV2 implementors do the same, by pushing for a true "Ready" status field in the API?

Yes, that's correct. The perfect solution is that Ingress v2 supports Ready status in their API but I think they will not accept it due to the reason you mentioned.

@howardjohn I guess IngressV2 implementors could do the same probing we do in Knative to achieve the same effect. I'm aware that Envoy doesn't give you the "I"m actually ready to serve this config" signal via its config, which is a bummer. The difference is that the IngressV2 implementor intimitaly knows the router while Knative only knows the IngressV2 plane, which makes probing on our end brittle.

Right, exactly. That "not guaranteed to reach the data plane" is the problem we'll have in Knative too :cry:

Note this GEP will allow us to include a label for in cluster gateway deployments. If we can lookup the service by the label then we can endpoints we can probe.
https://github.com/kubernetes-sigs/gateway-api/pull/1757

^ the above in my mind is a fallback

/assign @dprotaso

It might also be possible to do probing without requests hitting the activator/queue proxy
eg. match on the probe header and do a redirect
https://gateway-api.sigs.k8s.io/reference/spec/#gateway.networking.k8s.io%2Fv1.HTTPRequestRedirectFilter

Though we would lose an assurance that there's an activator/queue proxy in the data path.

I've written a proposal here on how we can include endpoint probing - 2024 - Gateway API Endpoint Probing
It's more or less the same approach as we took in Contour


Packagist vulnerabilities are not being reported for some packages

I've recently done an initial implementation for having osv-detector use the osv.dev api, but it looks like it's not 1:1 with the offline databases, at least for Packagist.

Using this lockfile:
{
    "_readme": [
        "This file locks the dependencies of your project to a known state",
        "Read more about it at https://getcomposer.org/doc/01-basic-usage.md#installing-dependencies",
        "This file is @generated automatically"
    ],
    "content-hash": "b63765525e5fabcf664728d548ecf8a2",
    "packages": [
        {
            "name": "enshrined/svg-sanitize",
            "version": "0.13.3",
            "source": {
                "type": "git",
                "url": "https://github.com/darylldoyle/svg-sanitizer.git",
                "reference": "bc66593f255b7d2613d8f22041180036979b6403"
            },
            "dist": {
                "type": "zip",
                "url": "https://api.github.com/repos/darylldoyle/svg-sanitizer/zipball/bc66593f255b7d2613d8f22041180036979b6403",
                "reference": "bc66593f255b7d2613d8f22041180036979b6403",
                "shasum": ""
            },
            "require": {
                "ext-dom": "*",
                "ext-libxml": "*"
            },
            "require-dev": {
                "codeclimate/php-test-reporter": "^0.1.2",
                "phpunit/phpunit": "^6"
            },
            "type": "library",
            "autoload": {
                "psr-4": {
                    "enshrined\\svgSanitize\\": "src"
                }
            },
            "notification-url": "https://packagist.org/downloads/",
            "license": [
                "GPL-2.0-or-later"
            ],
            "authors": [
                {
                    "name": "Daryll Doyle",
                    "email"<EMAIL_ADDRESS>                }
            ],
            "description": "An SVG sanitizer for PHP",
            "time": "2020-01-20T01:34:17+00:00"
        }
    ],
    "packages-dev": [],
    "aliases": [],
    "minimum-stability": "stable",
    "stability-flags": [],
    "prefer-stable": false,
    "prefer-lowest": false,
    "platform": [],
    "platform-dev": []
}

❯ osv-detector-t --use-api --parse-as composer.lock /mnt/c/Users/Gareth/Downloads/safe-svg-composer.lock.txt
/mnt/c/Users/Gareth/Downloads/safe-svg-composer.lock.txt: found 1 package
  no known vulnerabilities found

❯ osv-detector-t --use-dbs --parse-as composer.lock /mnt/c/Users/Gareth/Downloads/safe-svg-composer.lock.txt
/mnt/c/Users/Gareth/Downloads/safe-svg-composer.lock.txt: found 1 package
  Loading OSV databases for the following ecosystems:
    Packagist (862 vulnerabilities, including withdrawn - last updated Fri, 13 May 2022 23:58:47 GMT)

<EMAIL_ADDRESS>is affected by the following vulnerabilities:
    GHSA-fqx8-v33p-4qcc: Cross-site Scripting in enshrined/svg-sanitize (https://github.com/advisories/GHSA-fqx8-v33p-4qcc)

  1 known vulnerability found in /mnt/c/Users/Gareth/Downloads/safe-svg-composer.lock.txt

The vulnerability here correctly lists says it affects versions below 0.15.0, but it's not reported even if I use the version:
❯ curl -X POST -d '{"commit": "bc66593f255b7d2613d8f22041180036979b6403"}' 'https://api.osv.dev/v1/query'
{}
❯ curl -X POST -d '{"package": {"name": "enshrined/svg-sanitize"}, "version": "0.13.3"}' 'https://api.osv.dev/v1/query'
{}
❯ curl -X POST -d '{"package": {"name": "enshrined/svg-sanitize", "ecosystem": "Packagist"}, "version": "0.13.3"}' 'https://api.osv.dev/v1/query'
{}

Going with the lowest version for this package doesn't return anything either, when it should return three vulnerabilities.
(my current theory is that this because the advisory doesn't have any versions, and the api isn't checking against ranges?)

Yep, we are currently lacking Packagist versioning support: https://github.com/google/osv/issues/230. This will need a little bit of work, as it seems to have some strange quirks.

Is this the only ecosystem you think is affected by this? (So far everything else seems to be matching between the databases and api, but I've not yet tried extensively across all the ecosystems).
fwiw I'm pretty confident that semantic should be 80% of what you need in terms of implementation, so hopefully you could just port that over? (the only thing it doesn't do right now is the "dev < alpha < beta < etc" list - it does handle arbitrary + different number of components and views rc.1 as equal to rc1).

Given the many different versioning semantics out there, I'm not sure if it makes sense to have a single versioning package which tries to handle every single scheme out there. We'll likely need to build specific support for every ecosystem we want to support for the most robust/precise results.
e.g. Maven has similarly complicated semantics (https://maven.apache.org/pom.html#Dependency_Version_Requirement_Specification) which would conflict with the PHP ones and a different set of special cases.

Is this the only ecosystem you think is affected by this?

Out of all the main ecosystems currently supported, Packagist is the only one lacking support.

Given the many different versioning semantics out there, I'm not sure if it makes sense to have a single versioning package which tries to handle every single scheme out there.

I think if you're trying to support actually handling ranges then maybe but fwiw I also have support for parsing Maven ranges into a minimal version number: https://github.com/G-Rath/osv-detector/blob/main/internal/lockfile/parse-maven-lock_test.go#L107

OSV will need this for handling ranges. Our infra takes care of "expanding" the non-semver ranges into the "versions" arrays to make these advisories easier to match without having to implement all the different version ordering schemes out there.

but isn't that just for the versions property right? why not fallback to the actual affected ranges? (which is why osv-detector is able to match the vulnerabilities when using the database, without having the versions array)

Falling back is fine if the local tool can implement it correctly (checking the ranges is part of the evaluation algorithm). OSV infra just guarantees that it will always expand and populate the "versions" field for convenience.

Maybe I'm missing something, but doesn't that then loop us back to the start of this issue / this comment? while inconvenient you don't yet have a stable way of populating "versions" for Packagist vulnerabilities, you should still be able to ensure correct support by checking the ranges which should be safer to support because you shouldn't have to deal with package-manager-specific constraints/ranges (or, you should be able to provide support for static versions right now, and hopefully be able to support constraints in future)

I think there might have been some miscommunication somewhere :)  Let me try to unpack our conversation and correct me if I've misunderstood something.
For OSV: OSV.dev infra needs Packagist support for expanding affected ranges into static versions lists. This requires proper implementation of Packagist's versioning/ordering scheme. Checking ranges to match vulnerabilities also requires this to be implemented.
For osv-detector: there is a generic semantic package that you implemented which tries to support every single version scheme and their comparison rules out there. My claim is we will need to have more specific support (i.e. one package ver versioning scheme) rather than a generic library which tries to do everything because there will inevitably be conflicts.

Maybe I'm missing something, but doesn't that then loop us back to the start of this issue / https://github.com/google/osv/issues/426#issuecomment-1127094656?

Yes, the core problem here is there is no correct implementation of Packagist version ordering support in either OSV.dev infra or your osv-detector.

you should still be able to ensure correct support by checking the ranges which should be safer to support because you shouldn't have to deal with package-manager-specific constraints/ranges

I'm not sure I fully understand this. To check ranges, we also need to implement correct version ordering support. And if we implement that, in our implementation we can just expand and index on the static versions instead. Could you please clarify?
Happy to have a call some time to talk through this :)

I think maybe there's been some confusion on the "ranges" (on my side) - right now I'm focusing on just a single version e.g. v1.0.0.
I believe currently that it should be possible to implement a best-effort package for handling most common representations of single specific versions across a number of ecosystems that is "good enough" for initial support (e.g. it'll handle 80%+ of common cases, which is far better than supporting 0%), and in turn this means you should be able to support checking "OSV ranges" that are also single-version¹ - I also believe I've proven this with osv-detector.
I think at this point I do somewhat disagree that you need to explicitly have a package per versioning schema, for similar reasons - I'm definitely not saying that it's perfect but I am also wondering if you're aiming for perfect so missing hitting "good"?
This is also completely still focused on that single static version - I completely agree that if you add constraints into the mix, things get a lot more complex (e.g. Maven which you've linked to, Pip supporting !=, etc) but personally I think the best place to start for handling that is with the native package managers as they're the ones who'll know best what the final version(s) will be - which brings me back to "perfect is the enemy of good": if you can get decent support for static versions like what I've got with semantic, that'll allow people to start by providing the exact versions given to them by their package managers (this is me starting to give my 2 cents now - happy to do a call to discuss further)
I think it'd probably be really useful if you had any examples of where semantic doesn't work (excluding constraints of course 😉)
¹: so far all of the OSVs I've seen have had this, though the specification for ECOSYSTEM does not say that these ranges have to point to a single package meaning it might be valid to have an OSV that specifies e.g. a Maven constraint that actually matches multiple versions, which might be what you were getting at earlier

so far all of the OSVs I've seen have had this, though the specification for ECOSYSTEM does not say that these ranges have to point to a single package meaning it might be valid to have an OSV that specifies e.g. a Maven constraint that actually matches multiple versions, which might be what you were getting at earlier

Versions in OSV ranges should absolutely refer to single versions. Sorry for the confusion here -- I think our terminology of native package manager constraints vs OSV ranges are mixed up. We don't want native package manger constraints to get encoded at all in any advisories.
Resolving versions/constraints from a manifest file is indeed a whole separate problem to tackle.

I think at this point I do somewhat disagree that you need to explicitly have a package per versioning schema, for similar reasons - I'm definitely not saying that it's perfect but I am also wondering if you're aiming for perfect so missing hitting "good"?

One key motivation behind OSV is to make sure we have precision and accuracy over existing standards (no false positives or negatives), and we already do have proper support for every major versioning scheme -- only Composer/Packagist is missing. I believe the effort for OSV.dev would be much better spent to just implement that vs porting or trying to support a generic version scheme.

Right I think we're on the same page now (I think the bulk was that terminology mixup 😅) - I didn't realise that you'd already got full spec implementations for all the other standards; in that case I completely agree you might as well try and land a complete spec (the only reason semantic is "generic" is because it turned out that actually works for most of the specs).
I still think semantic is pretty close to being 1:1 with composer - the only thing I know is missing is that list order. If you like I can have a look at getting that implemented, and then hopefully it should just be a matter of porting that over to the OSV.dev infrastructure codebase (which I might be able to help with too).

we already do have proper support for every major versioning scheme

Is that public somewhere? if so could you link me to it?

Is that public somewhere? if so could you link me to it?

It's at https://github.com/google/osv/blob/master/lib/osv/ecosystems.py

Closing this one as the required work is being tracked in https://github.com/google/osv.dev/issues/230.


frames support + slider styling controls

@nicolaskruchten ready for review
partially closes #391

💃 for what we've got so far! would be nice to get some of those naming bits sorted out too but that could go into a later pass

Also we should add a panel-link-visibility item to #290


getVolumeRootPathCeph should detect and return ENOENT errors

When a subvolume is deleted but before its relevant RADOS objects and keys are deleted a service fault occurs, then the next delete request is expected to garbage collect the same. This is done on errors where the image is not found in the background, but RADOS information leads us to the image (like in newVolumeOptionsFromVolID).
To satisfy this requirement and edge case, ENOENT errors from getVolumeRootPathCeph need to be detected and appropriately handled in the DeleteVolume request to only garbage collect the RADOS information stored for the same.
This is akin to returning ErrImageNotFound from getImageInfo and handling the same in DeleteVolume request in the rbd plugin code.

@poornimag would you like to take this?


Update more_information.md

Add another project using druid.

Cool I'll try to keep it up to date with druid so it serves as an example to learn from.


RoutablePageMixin messes up with preview_modes

Issue Summary
RoutablePageMixin is incompatible with multiple preview_modes
Steps to Reproduce
Here's an example of a model
class FeedbackPage(RoutablePageMixin, Page):
    body = StreamField(
        BaseStreamBlock,
        verbose_name="Content block",
        blank=True,
        use_json_field=True,
    )

    # Thanks post-submission settings
    thanks = StreamField(
        BaseStreamBlock,
        verbose_name="Thnk-you page content",
        blank=True,
        use_json_field=True,
    )

    preview_modes = [
        ("form", _("Form")),
        ("thanks", _("Thank you page")),
    ]

    thanks_template_name = "feedback/thanks.html"

    def get_preview_template(self, request, mode_name):
        if mode_name == self.default_preview_mode:
            return super().get_preview_template(request, mode_name)
        return self.thanks_template_name

    # @path("thanks/")
    # def thanks_page(self, request):
    #     return self.render(request, template=self.thanks_template_name)

I commented the route to be sure it wouldn't mess up with rest, but it's actually what I would want to do (see also #4835)
The preview_modes selector is correctly displayed, but the preview doesn't show the correct template. It can be traced back to get_preview_template() not being called as RoutablePageMixin overrides serve_preview() to render the default route.
It is fixable by overriding serve_preview() to use the one from PreviewableMixin:
    def serve_preview(self, request, mode_name):
        return super(Page, self).serve_preview(request, mode_name)

Technical details

Python version: 3.10.6
Django version: 4.2.2
Wagtail version: 5.0.1

What do you think should be the probable fix for this? Any suggestions or workaround?

@YashTote for a workaround see my comment:
    def serve_preview(self, request, mode_name):
        return super(Page, self).serve_preview(request, mode_name)

This is what I found on the wagtail docs: https://docs.wagtail.org/en/stable/reference/pages/model_reference.html#wagtail.models.PreviewableMixin.get_preview_template
This is the default behaviour of Mixins according to the docs. So isn't this an enhancement type bug? If yes then how may I proceed to fix this?


⚠ Bofrost.de has degraded performance

In 7002d60, Bofrost.de (https://www.bofrost.de) experienced degraded performance:

HTTP code: 200
Response time: 1285 ms

Resolved: Bofrost.de performance has improved in e5e4279.


Simplified build chain and updated build scripts to VS 2022

Hi Will,
I added the wix installer code. Could you please "re-approve" it, so that we can get this into main. I steal and merged your PR #14 into this PR.


What is your result tested on wider face?

Havn't test it yet. My own mAP on all wider face validation set is 0.7 mAP as said in README.md.
One of the trainer reached 0.78mAP on hard and 0.83mAP on easy using this code.


Rebuild DB state from local session log

Currently, if the Fedimint DB is corrupted due to a bug or manual edits one can rebuild it by re-syncing using the session log of a peer. This is unnecessarily bandwidth and time consuming though since the on-disk log could be used instead. It is signed, so any corruption would be detected and could trigger a re-download.

Honestly, looking at it RN, does not seem worth the extra complexity, and even more so prioritizing it over many other things we could be doing. Every recovering client will possibly download large chunk of history, etc. so a peer doing DR once in a blue moon is not worth worrying about.


CI: github actions: In the linux dbg tests, update apt before installing packages.

The test suite "Linux Tests / Python 3.7-dbg" on github actions has been failing in recent PRs because of errors in the script such as
E: Failed to fetch http://azure.archive.ubuntu.com/ubuntu/pool/main/g/glibc/libc6-dbg_2.27-3ubuntu1.3_amd64.deb  404  Not Found [IP: <IP_ADDRESS> 80]
Fetched 96.9 MB in 3s (28.6 MB/s)
E: Unable to fetch some archives, maybe run apt-get update or try with --fix-missing?
Error: Process completed with exit code 100.

Following a suggestion in https://github.com/actions/virtual-environments/issues/675, I added sudo apt-get update to the script, before attempting to install packages with apt.
The "Linux Tests / Python 3.7-dbg" suite passed, so it looks like the tip was a good one.

In it goes then, thanks for the catch of the day @WarrenWeckesser !

may need to backport as well so labelling just in case


升级nacos-client到1.3.1版本

Please do not create a Pull Request without creating an issue first.
What is the purpose of the change
升级nacos-client到1.3.1版本
Brief changelog
XX
Verifying this change
XXXX
Follow this checklist to help us incorporate your contribution quickly and easily:

[ ] Make sure there is a Github issue filed for the change (usually before you start working on it). Trivial changes like typos do not require a Github issue. Your pull request should address just this issue, without pulling in other changes - one PR resolves one issue.
[ ] Format the pull request title like [ISSUE #123] Fix UnknownException when host config not exist. Each commit in the pull request should have a meaningful subject line and body.
[ ] Write a pull request description that is detailed enough to understand what the pull request does, how, and why.
[ ] Write necessary unit-test to verify your logic correction, more mock a little better when cross module dependency exist. If the new feature or significant change is committed, please remember to add integration-test in test module.
[ ] Run mvn -B clean package apache-rat:check findbugs:findbugs -Dmaven.test.skip=true to make sure basic checks pass. Run mvn clean install -DskipITs to make sure unit-test pass. Run mvn clean test-compile failsafe:integration-test  to make sure integration-test pass.

already finish in pr #218


Startup scripts

Created and made the startup script (deploy.sh).

Hi. This pull request conflicts with PR #31. @jschlind411 I'm happy to explain what's changed and why in my pull request. Please contact me on email.

Hello Mike,
Please let me know what conflicts were created so I can fix my script file.
Thanks for your time!

Jeff

On Sep 23, 2017 11:28 AM, "Mike Matera"<EMAIL_ADDRESS>wrote:

Hi. This pull request conflicts with PR #31
https://github.com/BCLab-UNM/SwarmBaseCode-ROS/pull/31. @jschlind411
https://github.com/jschlind411 I'm happy to explain what's changed and
why in my pull request. Please contact me on email.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/BCLab-UNM/SwarmBaseCode-ROS/pull/36#issuecomment-331655266,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AR4IfLdFgpOMNpsDZfN8QJARxPJ25hX_ks5slT_CgaJpZM4PhTuP
.

Hi Jeff!
I have a deploy script in my PR #31. It's in ./misc/deploy_host.sh The script is just 56 lines and works this way:

You build and test your code locally, in your own workspace and manage git there.
Enable installation steps in catkin like this:

$ catkin --config install

Deploy your current workspace to the rover like this:

$ ./misc/deploy_host.sh <rover-name-or-ip-address>

The deploy script calls catkin build. With installation enabled the catkin build command creates an ./install directory in the workspace. It contains all binaries and scripts that are required to execute the rover code. There are some advantages to doing it this way:

It only takes 44 seconds to do a clean build on my desktop compared to 5+ minutes on the swarmie.
The install directory in my workspace contains 22MB of stuff which copies quickly.
The rover name is specified on the command line so you don't have to change the script to use it.
Binaries on the rover are copied into the /tmp directory and run from there, reducing the likelihood of confusion with repository code in /home

Hey Mike!
That's awesome, the script I added allows the user to pull from github and
transfer files to the swarmie (also building, packaging, unpacking and
running), transferring a working local copy to a rover for use in testing,
or simply running rovers with their current Working code. All of which I
have been successful pulling and transferring code to 3 swarmies in under a
few minutes.
How can we best merge these 2 together?
Jeff
On Sep 25, 2017 9:23 AM, "Mike Matera"<EMAIL_ADDRESS>wrote:
Hi Jeff!
I have a deploy script in my PR #31
https://github.com/BCLab-UNM/SwarmBaseCode-ROS/pull/31. It's in
./misc/deploy_host.sh The script is just 56 lines and works this way:

You build and test your code locally, in your own workspace and
manage git there.
Enable installation steps in catkin like this:

$ catkin --config install

Deploy your current workspace to the rover like this:

$ ./misc/deploy_host.sh
The deploy script calls catkin build. With installation enabled the catkin
build command creates an ./install directory in the workspace. It contains
all binaries and scripts that are required to execute the rover code. There
are some advantages to doing it this way:

It only takes 44 seconds to do a clean build on my desktop compared to
5+ minutes on the swarmie.
The install directory in my workspace contains 22MB of stuff which
copies quickly.
The rover name is specified on the command line so you don't have to
change the script to use it.
Binaries on the rover are copied into the /tmp directory and run from
there, reducing the likelihood of confusion with repository code in /home

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/BCLab-UNM/SwarmBaseCode-ROS/pull/36#issuecomment-331916459,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AR4IfJW-6kdIYlY5TjTiGzhRs7j7tSxpks5sl8WJgaJpZM4PhTuP
.

Hi Jeff

How can we best merge these 2 together?

That's for you to decide. For mine to work there must be corresponding changes in various CMakeLists.txt files and I would appreciate it if those were merged. You should look at how mine copies the /install directory instead of the whole project. It's a lot faster.

@mike-matera

That's for you to decide. For mine to work there must be corresponding changes in various CMakeLists.txt files and I would appreciate it if those were merged. You should look at how mine copies the /install directory instead of the whole project. It's a lot faster.

Looking through your extensive changes, you appear to have removed a lot of used code from:

README

build.yaml

config.yaml

package.xml's from

abridge
behaviours
diagnostics
gazebo_plugins
obstacle_detection
rqt_rover_gui
sbridge
ublox_gps
ublox_msgs
ublox_serialization
rover_onboard_node_launch

added a deploy_host.sh script

Now , first off, I am coming in to this completely blind trying to sort through your extensive removal of code.  if I am reading this right you are merely transferring the necessary files for the rover to run.  How does this work with the real rovers?  Are simulated rovers effected by this?
Secondly, you are renaming the workspace to rover_workspace by default.  Is that subject to change?
I cannot merge my code with yours due to extensive changes to, or the now completely hollow, rover_onboard_node_launch script.  Is it necessary to gut the entire script in your code?
As per the name, I don't think deploy.sh and deploy_hosts.sh should create any conflicts.
@gmfricke
I am unsure which route you wish to take.  The script I wrote uses all existing code and implements the existing rover_onboard_node script as it sits in master currently.  As per the issue with the apriltags_ros dependancy, it was added because of an issue when transferring files onto a swarmie.  The issue has since been resolved and is extraneous.  I am removing it from the pull request.

@jschlind411 Please ignore all changes in .catkin_tools. All of the files in there are generated and the pull request adds that directory to .gitignore as it should be. Which means they won't pollute commits ever again. Yay!
The central changes are:

Add the misc/deploy_host.sh script
Modify launch/swarmie.launch to support both simulated and physical launch profiles.
Cut a bunch of code out of misc/rover_onboard_node_lauch.sh because we can use swarmie.launch instead.
Modify a bunch of CMakeLists.txt files to add install commands.

Sorry for the confusion with all the XMLs. Couldn't be helped until .gitignore is fixed! Happy hacking.


Adding api-version to VSTS Agent download.

An older api-version must be used, as the schema has changed.

Hi @davidrea-MS, I'm your friendly neighborhood Azure Pull Request Bot (You can call me AZPRBOT). Thanks for your contribution!

This seems like a small (but important) contribution, so no contribution license agreement is required at this point. Real humans will now evaluate your PR.

TTYL, AZPRBOT;

Thanks davidrea


Changing internal interface breaks public base class even though it doesn't derive from interface

I know the subject of this issue sounds crazy, but it's true. If I make a change to an internal interface in an assembly it causes classes derived in another library to break even through it does not, directly or indirectly, derive off the interface in any way. There is no public api change! Not only that, but it fails with a very strange error. See: https://github.com/jabbera/InterfaceBug for a demo.
You can clearly see that: ITroubleInterface is internal and is only implemented by: TroubleClass which is also internal. The assembly does not expose internals.
Note: ITroubleInterface is not Implemented by TestBase
In my derived assembly there is a class UnrelatedClass that derives from TestBase Note again: This does not implement ITroubleInterface. It does however have another interface IUnrelatedInterface that has a mirror property of ITroubleInterface
If I rebuild my base assembly but comment out the IToubleInterface:QueryContext property, my UnrelatedClass fails to load with the following exception
Unhandled Exception: System.TypeLoadException: Method 'get_QueryContext' in type 'DerivedClasses.UnrelatedClass' from assembly 'derivedclasses, Version=<IP_ADDRESS>, Culture=neutral, PublicKeyToken=null' does not have an implementation.
   at ConsoleDriver.Program.Main()

This exception makes no sense. UnrelatedClass clearly implements IUnrelatedInterface:QueryContext since it derives from TestBase which has an implementation here.
My understanding is this change should be ABI compatible. It certainly is source compatible as rebuilding my derived classes fixes the problem. I'm sure this has something to do with having duplicate interfaces with the same property, and that may seem like an anti-pattern, but this is part of a code generator so it's not as crazy as it sounds.
Windows 7/10/2008 R2 .NET 4.6.2., 4.7, 4.5.2

@HaloFour you may find this interesting?

Closing as the most active variant of this issue is at https://github.com/dotnet/coreclr/issues/13564


Support bigger head dims

Is it possible to support this version of flash attention, i find that by just editing your code and replacing the 128 with 512 i get an error with stable diffusion 1.5. Is it possible to write the code to dynamically switch the head dim based on the model that's running. Furthermore I don't have enough knowledge to know if just replacing 128 would make it support the 512 version. If you could look into that would be great.

Yeah in my quickdif app I have a setup that uses try/catch instead of a dim check to support any flash attention library
import torch
from torch import Tensor
from typing import Callable

def _patch_sdpa(
    patch_func: Callable[[Tensor, Tensor, Tensor, Tensor | None, float, bool, float | None], Tensor],
):
    """(query, key, value, attn_mask=None, dropout_p=0.0, is_causal=False, scale=None)"""

    torch_sdpa = torch.nn.functional.scaled_dot_product_attention

    def sdpa_hijack_flash(query, key, value, attn_mask=None, dropout_p=0.0, is_causal=False, scale=None):
        try:
            return patch_func(query, key, value, attn_mask, dropout_p, is_causal, scale)
        except Exception:
            hidden_states = torch_sdpa(
                query=query,
                key=key,
                value=value,
                attn_mask=attn_mask,
                dropout_p=dropout_p,
                is_causal=is_causal,
                scale=scale,
            )
        return hidden_states

    torch.nn.functional.scaled_dot_product_attention = sdpa_hijack_flash

try:
    from flash_attn import flash_attn_func

    def sdpa_hijack_flash(q, k, v, m, p, c, s):
        assert m is None
        result = flash_attn_func(
            q=q.transpose(1, 2),
            k=k.transpose(1, 2),
            v=v.transpose(1, 2),
            dropout_p=p,
            softmax_scale=s if s else q.shape[-1] ** (-0.5),
            causal=c,
        )
        assert isinstance(result, Tensor)
        return result.transpose(1, 2)

    _patch_sdpa(sdpa_hijack_flash)
    print("# # #\nPatched SDPA with Flash Attention\n# # #")
except ImportError as e:
    print(f"# # #\nCould not load Flash Attention for hijack:\n{e}\n# # #")

I don't see why it won't also work for ComfyUI, but I haven't used Comfy in a while.

So if I would just slap that code in your node that could work ?

Probably. Replace the existing block.

I guess this can be closed then


sensu check cron scheduling support

adds cron configuration to sensu checks
Description

Added the code relevant to check configuration and some tests
Motivation and Context

fixes #551
How Has This Been Tested?

Added relevant test
Screenshots (if appropriate):
Types of changes

[ ] Bug fix (non-breaking change which fixes an issue)
[X] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

[x] My change requires a change to the documentation.
[ ] I have updated the documentation accordingly.
[X] I have read the CONTRIBUTING document.

I would say if you have integration tests feel free to remove the unit tests. If they were a library function it would make more sense to write a unit test for it.

Hi,
Fixed the issues - tests pass.

Sorry this fell off my radar. I will work on merging, writing up a changelog entry, and cutting a release.

released: https://supermarket.chef.io/cookbooks/sensu/versions/5.3.0


System crashes while build the velox

Problem description
when I try to execute "make" command in velox root directory it was build perfectly fine until it utilize full main memory and after utilizing 16GB memory(RAM) and 16 swap memory the system crashed.
Out of 2022 file it was perfectly build 1510 file within the 16 GB RAM and 16 GB swap memory.
suggest me way to fix it or else i did any mistake ??
command i have used:
git clone --recursive https://github.com/facebookincubator/velox.git
cd velox
./scripts/setup-ubuntu.sh
make
System information
Velox System Info v0.0.2
Commit: abb0df44d20326dca58691fb726432e84ee2d88f
CMake Version: 3.22.1
System: Linux-6.5.0-21-generic
Arch: x86_64
C++ Compiler: /usr/bin/c++
C++ Compiler Version: 11.4.0
C Compiler: /usr/bin/cc
C Compiler Version: 11.4.0
CMake Prefix Path: /usr/local;/usr;/;/usr;/usr/local;/usr/X11R6;/usr/pkg;/opt

CC: @assignUser @majetideepak @kgpai

Hi @Sujanhid , Set NUM_THREADS to 8 or something smaller so that you have enough memory to compile Velox.
NUM_THREADS=8 make


Stage UUIDs

What changes are proposed in this pull request?
Resolves #485 and prevents view bar stages from flickering when the view is changed from python.
view = dataset.take(1)
session.view = view
session.view = view # _randint remains the same and no animations occur in the view bar!

How is this patch tested? If it is not, please explain why.
A uuid serialization and deserialization test has been added to the stage unit tests.
Release Notes
Is this a user-facing change that should be mentioned in the release notes?

[ ] No. You can skip the rest of this section.
[x] Yes. Give a description of this change to be included in the release
notes for FiftyOne users.

Take and Shuffle seeds are persisted to the App.
What areas of FiftyOne does this PR affect?

[x] App: FiftyOne application changes
[ ] Build: Build and test infrastructure changes
[ ] Core: Core fiftyone Python library changes
[ ] Documentation: FiftyOne documentation changes
[ ] Other

The Shuffle and Take stages don't seem to be working when created from the app (as far as I can tell, they don't finalize - they're not showing up in the Python shell). Still trying to track it down, but I noticed that those two are the only stages that changed in this PR, besides the base ViewStage class.
Side note, the second parameter to Take is named "reverse" in the app, and I'm pretty sure it should be "seed", like Shuffle.

OK, good catches. Stages created in the view bar were not initialzing "hidden" (_randint) parameters correctly.
Things seem to be working now.

I think we should merge this before #514, then I can merge develop into #514 and monkey test for ~10 minutes.
Reviewing #532 now.


refactor: Better button description for view modes

Type of Change

Language File
What issue does this relate to?

N/A
What should this PR do?

Change wording of the view modes button to be easily understandable
What are the acceptance criteria?

Checks Needed:

Spelling
Translated to other languages
Button sizing adapts correctly

Hey, @LucaTanks - Thanks a ton for this PR! 😄
Would you please shoot me an email when you get a chance?
mcowley at digitalocean dot com 🎉

Hi, could you add the hacktoberfest-accepted label?

This repo is already participating in Hacktoberfest, so you should be good to go as this PR has been merged


Added quality cli option and better input checking.

Added --quality cli option, also the program now checks if the user input for the quality is out of range.

@smoqadam this PR has been open for over a year without any comment. Is this project dead?

I've fixed the conflicts in this MR here: https://github.com/Matt8898/rust-youtube-downloader/pull/1


ARROW-15973: [CI] Split nightly reports into three: Tests, Packaging, Release

This will need changes in https://github.com/ursacomputing/crossbow as well, but are necessary to be merged first.

@github-actions crossbow submit -g nightly-tests