Signed request expected

Issue
Secret key got changed
...
Environment
If you're reporting a bug, please attach the output of the following commands:
7.35
b'rYKfoeKQOwMHtBNTrCgvXEvgJBdwAHeZJFVqsBYh'

new secret: SlkXamhFfBJmlCyNlEuoqgoRSIWMRvOEhbgHBPKs
version: 7.44
i've managed to get the new ones for IOS but all accounts get insta banned no matter what
for future if anyone wants to update this and have a Jailbroken Iphone this will extract the keys and log them in SYS log

You might want to give this key a try, i just extracted it from the Android-Version 7.37.1:
bGXTsUrGsQXlBpRxXjTIRvMAlDIQbweoOJDDAJMP

Thanks, tried it still accounts are banned, Unfortunately i don't have an android Phone neither a Windows machine to check the requests for any change, if u can check them and gonna try
for IOS there is a 1 time request when you open the app for the first time, one you open the app and click continue it gets called if it lets you set Age then your phone is verified with Apple, they couldve implemented the same with Android.
I will try to race the method on IOS to get more info and maybe a way to fake the token.

Maybe you want to try @springjools solutions from issue #19, as far as I recall he got it working back then. If I get to it I'll take a closer look tomorrow and intercept some of the traffic.

Yes, but my accounts also get instabanned. But the first time you check for ban, it reports false. But when you immediately check again, it reports true.

I've found the Token its server to server check https://developer.apple.com/documentation/devicecheck?language=objc
idk if its possible to spoof it or trick it

I've figured everything and its not good :(
Since Version 7.40(in my tests) and up Jodel team Introduced new way to ban accounts by using DCDevice Token.
This token is per-device per-developerAccount and provides two 1 bit fields bit1: 0, bit2: 0 and the developer can assign any value for them.
So if someone tries to make an account with the API, they first need to get a token from their iPhone and make a request with it,
if this new account got banned Jodel team have a copy of the token in their server(it doesn't expire) and they will update apple servers with something like this bit1: 1, bit2: 0, now when you try to make a new account on your phone or by the API, Jodel will receive a new token from you and send it to apple and they see bit1: 1 and the new account is banned before its made.
So you need to wait until Jodel servers update apple servers and switch it back to bit1: 0 after you ban has  expired to use a new account.
If the token that got sent to Jodel is wrong apple will respond with HTTP Code 400 and this account also get banned.

Ok, I think it's difficult to circumvent a DCDevice token, since if I understand it correctly, it's a server to server thing. But I understand this only applies to ios. What about the procecure on android? Something similar there?

Just took a look into the application, there seems to be an alternative route to register iOS devices which do not support the device check:

I've set isSupported to False and it created a new account without DCDevice but i got 7-10 day ban, i think im banned by device_uid i'll try to spoof it
can i ask what decompiler you use, it looks alot better than Ghidra

I've spoofed the UUID before it gets hashed but still getting insta ban
if anyone wants to try build this with Theos, it'll randomize it when called
is there a chance that Jodel just bans all accounts as precaution?

I use IDA as a decompiler for Jodel.
The Apple reference of DeviceCheck says the application must check whether DeviceCheck is supported by the device before using it. Maybe older iPhones do not support DeviceCheck. If we can find an Jodel-Version for e.g. iPhone 6 (iOS 12 is the last supported version) we could try using this version and HMAC-Key to register a user. This might circumvent the DeviceCheck entirely.

to my testing, jodel allows accounts made with old version to work in the old version, but trying to create an account with older version fails and says Please update the app, if you know the last supported version number on iPhone 6 i will downgrade to it and see

Think i made a mistake, I've downloaded Version 7.10 and checked the http request there is the same DCDevice token, it's not new they using it for over a year now

random 3 AM idea might worth it, i noticed on the app that when opening a link to a post it wont open in the app if i got nextDNS enabled, thats because Branch.io is integrated in the app and nexDNS blocks all requests to it. googling Branch.io shows

Branch's attribution technology is designed specifically for the world where universal identifiers such as IDFA and GAID don’t exist.

what if the accounts get banned because of Branch's stuff as its requests aren't implemented here?
we should try to create an account with Branch's HTTPS requests and see if its banned.
when i spoofed UUID before it was for jodel HTTPS requests, but i didn't check if branch's is logging any tokens or anything
im going to sleep now i will follow with this when i wake up.

Might be definitely worth a try but I thing i tested this some time ago and it did not have any effect.

my basic analysis
when creating a new account after wiping the app data Branch makes 1 request to https://api2.branch.io/v1/install
most of it is tracking garbage except a couple.
we care about the token and good stuff
1st token apple_receipt : Apple Docs, looks useless .
2nd apple_attribution_token : Apple Docs, another useless one for ads.
3rd ios_vendor_id & hardware_id : Apple Docs, looks like the only interesting thing only here.
and it gives a response :

Numbers are changed.

{
  "session_id": "10134534657934677872",
  "link": "https://shared.jodel.com/a/key_live_jcESXFnKwxb53gafuWSRFijozto4BLB5?%24randomized_bundle_token=1066931657934513952",
  "data": "{\"+clicked_branch_link\":false,\"+is_first_session\":false}",
  "randomized_device_token": "1059087119560141413",
  "randomized_bundle_token": "1066931657934513952",
  "invoke_register_app": true
}

not very useful but they got 1 thing right, not my first session so im in the system and probably tagged banned if Jodel really integrates with them

Might be helpful
iPhone 6 iOS 12.5.5 last supported version is 4.139
https://github.com/ExTBH/bug-free-repo/blob/main/IPAs/Jodel_4.139_iOSGods.com.ipa

Thank you very much @ExTBH!
Just updated the keys to the 4.139 version, for me most of the tests are currently passing, you might want to give it a try!

Out of home now without my mac, will be back in 9 hours and test, if this works i might use it for another project that i can't fix because of DeviceCheck, thanks

accounts banned for me, what are your results?

I also updated with git pull and it resolves the signed request expected-error. But accounts are still blocked. You need to test it like this:
`Python 3.10.1 (tags/v3.10.1:2cd268a, Dec  6 2021, 19:10:37) [MSC v.1929 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.

import jodel_api
lat, lng, city = 48.148434, 11.567867, "Munich"
j = jodel_api.JodelAccount(lat=lat, lng=lng, city=city)
Creating new account.
Creating account with data {'location': {'country': 'DE', 'city': 'Munich', 'loc_coordinates': {'lat': 48.148434, 'lng': 11.567867}, 'loc_accuracy': 15.457}, 'device_uid': 'e9e0b5fd04b0852d374a2206c877612b7393f12084289536083ad46b2b4644ac', 'language': 'de-DE', 'client_id': 'cd871f92-a23f-4afc-8fff-51ff9dc9184e'}
status, response = j.get_user_config()
print(status)
200
blocked = response.get('user_blocked')
print (blocked)
True`

Moreover, I rememberthat previously the first call used to return False, and any second call to get the same information used to return True.
Also before there was a case when the status of the blocked-variable depended on the lat and lon-coordinates you fed to the function, ie I think geo-fence of some sort.

Not sure what is going on, just tested the requests with updated keys (iOS, 7.51) and the response looks good for me!
Key is as follows:
    secret = 'YEKawcOEwzigovvWEFkBVWPIsgHhnIFmfMtfjYLS'.encode('ascii')
    version = '7.51'

And the corresponding requests i performed are:
import json
import time

if __name__ == "__main__":
    import jodel_api

    lat, lng, city = 48.123456, 11.987654, "Munich"
    j = jodel_api.JodelAccount(lat=lat, lng=lng, city=city)
    status, response = j.get_user_config()
    print("Blocked ", response.get('user_blocked'))
    time.sleep(1)
    print("Karma", j.get_karma())
    time.sleep(1)
    print("Blocked ", response.get('user_blocked'))

which lead to the following output:
Creating new account.
Creating account with data [...]
Blocked  False
Karma (200, {'karma': 100})
Blocked  False

Weird. I updated the secret and version in L30-31 in jodel_api, ran setup build and setup install --user. I get this:

PS > python .\test.py
Creating new account.
Creating account with data {'location': {'country': 'DE', 'city': 'Munich', 'loc_coordinates': {'lat': 48.123456, 'lng': 11.987654}, 'loc_accuracy': 15.457}, 'device_uid': 'b32937fd1e430b55090b264cc657f6d8a3f06e81de0eb3eacc86902b86a421db', 'language': 'de-DE', 'client_id': 'cd871f92-a23f-4afc-8fff-51ff9dc9184e'}
Blocked  True
Karma (200, {'karma': 100})
Blocked  True
PS C:\Users\Pontus\Documents\github\jodel_api>

test.py is copy paste of the code you posted

Try altering the account creation to the following line to ensure the correct secret and version are used:
    j = jodel_api.JodelAccount(lat=lat, lng=lng, city=city, _secret='YEKawcOEwzigovvWEFkBVWPIsgHhnIFmfMtfjYLS', _version='7.51')

Additionally you might want to modify the coordinates to a random value, some bans seem to be based on coordinates.

But we used the same coordinates...

If accounts with the same coordinates are created from different IP addresses, they might detect it and ban them. Therefore a randomisation of coordinates might be necessary.

for a minute i thought Jodel team disabled this shit :(
lat, lng, city, country = 26.4591484, 50.117690, "Saar", "BH"

j = jodel_api.JodelAccount(lat=lat, lng=lng, city=city, country=country)
time.sleep(5)
status, response = j.get_user_config()
print("Blocked ", response.get('user_blocked'))
time.sleep(1)
print("Karma", j.get_karma())
time.sleep(1)
print("Blocked ", response.get('user_blocked'))

Creating new account.
Creating account with data {'location': {'country': 'BH', 'city': 'Saar', 'loc_coordinates': {'lat': 26.4591484, 'lng': 50.11769}, 'loc_accuracy': 15.457}, 'device_uid': 'b9c0f5eb867c835e0430ea4c2523afe06b2c141509bf8361ab0bf3b3fd771d80', 'language': 'bh-BH', 'client_id': 'cd871f92-a23f-4afc-8fff-51ff9dc9184e'}
Blocked  True
Karma (200, {'karma': 200})
Blocked  True

Just checked, the block seems to dependant on the IP address. You might want to try residential proxies, i tested now with two different, one got me blocked, the other one worked like a charm!

i'll check with my cellular IP, something is not right..

For what it is worth, I have tried this with a vpn from several locations (changing coordinates, city and country input every time) and i am also banned every time i make an account. I've tried with both  "https://api.go-tellm.com/api{}" and "https://api.jodelapis.com/api{}".

What about switching to Android version? Does Android implement something like DeviceCheck? +Android is bigger, so if there any its probably bypassed.

I'll perform more tests tomorrow regarding IP address and location. @ExTBH the Android version requires email verification which would require a mail server to verify the account.

Sadly i now can replicate your issue, account seems to be banned instantly.

Guess that was a bug on their servers..
I see 2 options to get this working, if anyone has anything please say

We figure out how to bypass DeviceCheck which will take ALOT of time and probably wont bypass it
We switch to Android version and be limited by google accounts

Defeating DeviceCheck is no possible option from my point of view. Leaving us with the email verification.
I recorded the required requests and documented the (hopefully) complete process here.
Now in theory all it needs is a mail server which allows API access. I tested OpenTrashmail which seems to do just fine. All it takes now is plugging it all together.

i can think of one problem here, Google banning domains after it notices a bunch of accounts made with it.
2 AM for me now, i'll check with a public mail provider tomorrow since i don't have a VPS to work with.
if this work i've got an idea to solve iOS bans for good, basic idea is, MITM the IOS app calling the api, replace the requests to android stuff, get the responses, convert them to something the iOS app understand
i don't see CORS headers also, should be possible for me to make a web client for the app with this

Oki I've followed the steps above but haven't tested step 4, the rest works.
I tried https://www.mohmal.com/ this email service and made a script to make it in 2 steps, should be able to use a free mail with API and work also.
from typing import Union
import requests

#Used by all methods here
baseURL = "https://www.googleapis.com"
querystring = {"key":"AIzaSyDFUC30aJbUREs-vKefE6QmvoVL0qqOv60"}

headers = {
    "X-Android-Package": "com.tellm.android.app",
    "X-Android-Cert": "A4A8D4D7B09736A0F65596A868CC6FD620920FB0",
    "X-Client-Version": "Android/Fallback/X21000001/FirebaseCore-Android",
}

def requestLogin(email: str) -> Union[bool, str]:
    url = f"{baseURL}/identitytoolkit/v3/relyingparty/getOobConfirmationCode"

    payload = {
        "requestType": 6,
        "email": f"{email}",
        "androidInstallApp": True,
        "canHandleCodeInApp": True,
        "continueUrl": "https://jodel.com/app/magic-link-fallback",
        "androidPackageName": "com.tellm.android.app",
        "androidMinimumVersion": "5.116.0"
    }

    response = requests.post(url=url, json=payload, headers=headers, params=querystring)

    if response.json()['kind'] == 'identitytoolkit#GetOobConfirmationCodeResponse' and response.status_code == 200:
        return True
    return f"{response.status_code} | Failed to create account | {response.text}"

def extractOob(link: str) -> Union[bool, str]:
    try:
        url = requests.utils.unquote(link)
        start = 'oobCode='
        end = '&continueUrl'
        return(url[url.find(start)+len(start):url.rfind(end)])
    except:
        return False

def redeemOob(oobCode: str, email: str) -> Union[str, dict]:

    url = f"{baseURL}/identitytoolkit/v3/relyingparty/emailLinkSignin"

    payload = {
        "email": f"{email}",
        "oobCode": f"{oobCode}"
    }

    response = requests.post(url, json=payload, headers=headers, params=querystring)
    responseJsoned = response.json()

    if response.status_code == 200 and responseJsoned['kind'] == 'identitytoolkit#EmailLinkSigninResponse':
        return {
            'idToken': responseJsoned['idToken'],
            'refreshToken': responseJsoned['refreshToken'],
            'expiresIn': responseJsoned['expiresIn'],
            'localId': responseJsoned['localId'],
        }
    return f"{response.status_code} | Failed to redeem Oob | {response.text}"

def refreshTokens(refreshToken: str) -> Union[str, dict]:
    url = "https://securetoken.googleapis.com/v1/token"

    payload = {
        "grantType": "refresh_token",
        "refreshToken": f"{refreshToken}"
    }

    response = requests.post(url, json=payload, headers=headers, params=querystring)
    responseJsoned = response.json()

    if response.status_code == 200:
        return {
            'access_token': responseJsoned['access_token'],
            'expires_in': responseJsoned['expires_in'],
            'refresh_token': responseJsoned['refresh_token'],
            'user_id': responseJsoned['user_id'],
            'project_id': responseJsoned['project_id']
        }
    return f"{response.status_code} | Failed to refresh tokens | {response.text}"

email =<EMAIL_ADDRESS>

if requestLogin(email):
    oob = extractOob(input("Paste URL from Email: "))
    if oob == False:
        print("\n\nCan't extract OobCode")
        exit()

    oobTokens = redeemOob(oob, email)
    if type(oobTokens) != dict:
        print('\n\n' + oobTokens)
        exit()

    refreshedTokens = refreshTokens(oobTokens['refreshToken'])
    if type(refreshedTokens) != dict:
        print('\n\n' + refreshedTokens)
        exit()
    print(refreshedTokens)
    ```

@ExTBH please check out the android_mail_auth branch. For me the registration using email works like a charm:
Requested email verification for [...]
Obtained oob token [...] for email [...]
Creating new account.
Creating account with data {'firebase_uid': 'jtNECbcwmfPGgQVuyKVPpsW8UIE3', 'firebaseJWT': 'eyJhbGciO[...]
Blocked  False
Karma (200, {'karma': 100})
Posts [200, {"posts": [{"message": "Podcast recs? I'm in to true crime " [...]
Blocked  False

Out of home, will check when im back.
Im all in FOSS so yeah im ok

Quick update: Seems like they have a absolutely brilliant bot prevention system. Even though verifying by mail my accounts are now blocked. And quick code update, you can now either pass a mail address and mail fetch handler directly in the constructor or leave them out. Leaving them out prompts you for manual input.
The fetch_handler requires one parameter (the email address argument) and should return a text containig the oobCode. The code is extracted automatically afterwards.
Code example with handler:
import json
import time
import jodel_api
import requests

def email_fetcher(email_address):
    email = None
    while not email:
        response = requests.get(f"https://your.email.service/{email_address}").text
        if "oobCode" in response:
            return response
        else:
            time.sleep(1)

if __name__ == "__main__":
    lat, lng, city = 48.834875, 2.344962, "Paris"
    j = jodel_api.JodelAccount(lat=lat, lng=lng, city=city, email_fetch=email_fetcher<EMAIL_ADDRESS>
Example without handler (interactive mode):
Python 3.9.7 (tags/v3.9.7:1016ef3, Aug 30 2021, 20:19:38) [MSC v.1929 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> from jodel_api import jodel_api
>>> lat, lng, city = 48.834875, 2.344962, "Paris"
>>> j = jodel_api.JodelAccount(lat=lat, lng=lng, city=city)
No email address is given, please enter it manually<EMAIL_ADDRESS>No email fetch handler registered, using manual mode
Requested email verification for<EMAIL_ADDRESS>Please enter the link found in the email: https://ae3ts.app.goo.gl/?link=https://tellm-android.firebaseapp.com/__/auth/action?apiKey%3DAIzaSyBC5AfciIsT15NSwrfhLhsLG5UtFisbeSA%26mode%3DsignIn%26oobCode%3D4W6H43itna23hqunAKTIvh6MdHrHoeJm1Oton9LRz0oAAAGCRn7CPg%26continueUrl%3Dhttps://jodel.com/app/magic-link-fallback%26lang%3Den&apn=com.tellm.android.app&amv=5.116.0
Obtained oob token 4W6H43itna23hqunAKTIvh6MdHrHoeJm1Oton9LRz0oAAAGCRn7CPg for email<EMAIL_ADDRESS>Creating new account.
Creating account with data [...]
>>> status, response = j.get_user_config()
>>> print(response.get('user_blocked'))
True

my attempt with the new branch
Should
lat, lng, city, country =  23.175, 50.1486, "Manama", "BH"

j = jodel_api.JodelAccount(lat=lat, lng=lng, city=city, country=country)
time.sleep(5)
response = j.get_user_config()
print("Blocked ", response.get('user_blocked'))
time.sleep(1)
print("Karma", j.get_karma())
time.sleep(1)
print("Blocked ", response.get('user_blocked'))

No email address is given, please enter it<EMAIL_ADDRESS>No email fetch handler registered, using manual mode
Requested email verification for<EMAIL_ADDRESS>Please enter the link found in the email:<link>
Obtained oob token 7s2ezDQlh1vE2PnK-1lusERUvO-U-K8-03XzbpKFnYMAAAGCRppLOg for email<EMAIL_ADDRESS>Creating new account.
Creating account with data {'firebase_uid': 'jtNECbcwmfPGgQVuyKVPpsW8UIE3', 'firebaseJWT': '<JWT>', 'location': {'country': 'BH', 'city': 'Manama', 'loc_coordinates': {'lat': 23.175, 'lng': 50.1486}, 'loc_accuracy': 15.457}, 'device_uid': '<RandomString>', 'language': 'de-DE', 'client_id': 'cd871f92-a23f-4afc-8fff-51ff9dc9184e'}
Blocked  True
Karma (200, {'karma': 100})
Blocked  True

Your third edit really did the trick for me there! Using the correct client_id, the accounts do not seem to be banned anymore.
Just pushed the changes, does it work for you?

im installing with
pip3 install git+https://github.com/JodelRaccoons/jodel_api.git@android_mail_auth#egg=jodel-api

but it doesn't allow me to set the email now, using same code as before, it just creates an account by itself which is bananed

I split the accounts into iOSJodelAccount and AndroidJodelAccount. The current default is iOSJodelAccount as it is more easy to use for read only access. Try to use the AndroidJodelAccount like mentioned in the branches readme

works! i get False now, i'll test making a post and update

477 sounds to me like the request signing is somehow broken. I'll check that tomorrow and will try to verify the signing mechanism.

calling below works fine, don't think its signing, i dont own an Android to check
j.get_posts_recent(skip=0, limit=60, after=None, mine=False, hashtag=None, channel=None)

iOS post Request looks like the below
link: https://api.jodelapis.com/api/v3/posts?hasDrawing=false&hasHashtag=false
{
  "location" : {
    "loc_coordinates" : {
      "lat" : 26.213154187145772,
      "lng" : 50.557814349952793
    },
    "loc_accuracy" : 3639.623509412248,
    "country" : "BH",
    "city" : "Manama",
    "name" : "unknown"
  },
  "color" : "A867E9",
  "test" : false,
  "channel_id" : "5f8ebbb3fd37e500256f7a67",
  "to_home" : false,
  "section" : "Main",
  "promoted_link" : "",
  "message" : "..."
}

Somehow the HMAC calculation seems off. I tested the same requests in BurpSuite (using the HMAC calculator extension) and they work just fine. Even using BurpSuite as a proxy for the python_api works flawlessly. But i can't spot the difference between the two requests:
Signed by BurpSuite:
POST /api/v3/posts/?explorer=False HTTP/1.1
Host: api.jodelapis.com
Accept: */*
Connection: close
User-Agent: Jodel/8.0.1 Dalvik/2.1.0 (Linux; U; Android 16; Pixel 9 Build/AAAA.123456.789)
X-Location: 52.504062;13.386062
X-Timestamp: 2022-07-29T09:54:56Z
Content-Type: application/json; charset=UTF-8
Authorization: Bearer 88495644-abe900e3-ab95baad-b3db-47a4-bee1-ba8e4092bc1a
X-Api-Version: 0.2
X-Client-Type: android_8.0.1
Content-Length: 238
Accept-Encoding: gzip, deflate
X-Authorization: HMAC 50951DEC80310EA812391D5A82A568DAF72E0C73

{"color": "8ABDB0", "location": {"country": "DE", "city": "Berlin", "loc_coordinates": {"lat": 52.504062, "lng": 13.386062}, "loc_accuracy": 15.457}, "ancestor": null, "message": "Hallo zusammen", "channel_id": "5f8ebbb3fd37e500256f7a67"}

which is signed using the following HMAC input parameters:
[+] Signing request to https://api.jodelapis.com:443/api/v3/posts/
	[+] URL parameters:
	explorer=False
	[+] Timestamp: 2022-07-29T09:54:56Z
	[+] Access token: Bearer 88495644-abe900e3-ab95baad-b3db-47a4-bee1-ba8e4092bc1a
	[+] Location: 52.504062;13.386062
	[+] Constructed HMAC String: POST%api.jodelapis.com%443%/api/v3/posts/%88495644-abe900e3-ab95baad-b3db-47a4-bee1-ba8e4092bc1a%52.504062;13.386062%2022-07-29T09:54:56Z%explorer%False%{"color": "8ABDB0", "location": {"country": "DE", "city": "Berlin", "loc_coordinates": {"lat": 52.504062, "lng": 13.386062}, "loc_accuracy": 15.457}, "ancestor": null, "message": "Hallo zusammen", "channel_id": "5f8ebbb3fd37e500256f7a67"}
	[+] New header:
	    Host: api.jodelapis.com
	    Accept: */*
	    Connection: close
	    User-Agent: Jodel/8.0.1 Dalvik/2.1.0 (Linux; U; Android 16; Pixel 9 Build/AAAA.123456.789)
	    X-Location: 52.504062;13.386062
	    X-Timestamp: 2022-07-29T09:54:56Z
	    Content-Type: application/json; charset=UTF-8
	    Authorization: Bearer 88495644-abe900e3-ab95baad-b3db-47a4-bee1-ba8e4092bc1a
	    X-Api-Version: 0.2
	    X-Client-Type: android_8.0.1
	    Content-Length: 238
	    Accept-Encoding: gzip, deflate
	    X-Authorization: HMAC 50951DEC80310EA812391D5A82A568DAF72E0C73

which successfully creates a post. Performing the same request from python:
POST /api/v3/posts/?explorer=False HTTP/1.1
Host: api.jodelapis.com
User-Agent: python-requests / jodel_api 8.0.1 (https://github.com/JodelRaccoons/jodel_api/)
Accept-Encoding: gzip, deflate
Accept: */*
Connection: close
Authorization: Bearer 88778679-920de650-805418a1-07b7-40ab-9452-d7fb26cf140c
X-Location: 52.5041;13.3861
X-Client-Type: android_8.0.1
X-Api-Version: 0.2
X-Timestamp: 2022-07-29T09:59:39Z
X-Authorization: HMAC ADDE3B615AFE80B6B2610BEEED98DD138F123F5D
Content-Type: application/json; charset=UTF-8
Content-Length: 238

{"color": "8ABDB0", "location": {"country": "DE", "city": "Berlin", "loc_coordinates": {"lat": 52.504062, "lng": 13.386062}, "loc_accuracy": 15.457}, "ancestor": null, "message": "Hallo zusammen", "channel_id": "5f8ebbb3fd37e500256f7a67"}

with the following input parameters:
HMAC String: POST%api.jodelapis.com%443%/api/v3/posts/%88778679-920de650-805418a1-07b7-40ab-9452-d7fb26cf140c%52.5041;13.3861%2022-07-29T09:59:39Z%explorer%false%{"color": "8ABDB0", "location": {"country": "DE", "city": "Berlin", "loc_coordinates": {"lat": 52.504062, "lng": 13.386062}, "loc_accuracy": 15.457}, "ancestor": null, "message": "Hallo zusammen", "channel_id": "5f8ebbb3fd37e500256f7a67"}
Requesting https://api.jodelapis.com/api/v3/posts/
     Endpoint: /v3/posts/
     Payload: {'color': '8ABDB0', 'location': {'country': 'DE', 'city': 'Berlin', 'loc_coordinates': {'lat': 52.504062, 'lng': 13.386062}, 'loc_accuracy': 15.457}, 'ancestor': None, 'message': 'Hallo zusammen', 'channel_id': '5f8ebbb3fd37e500256f7a67'}
     Method: POST
     Headers: {'User-Agent': 'python-requests / jodel_api 8.0.1 (https://github.com/JodelRaccoons/jodel_api/)', 'Authorization': 'Bearer 88778679-920de650-805418a1-07b7-40ab-9452-d7fb26cf140c', 'X-Location': '52.5041;13.3861', 'X-Client-Type': 'android_8.0.1', 'X-Api-Version': '0.2', 'X-Timestamp': '2022-07-29T09:59:39Z', 'X-Authorization': 'HMAC ADDE3B615AFE80B6B2610BEEED98DD138F123F5D', 'Content-Type': 'application/json; charset=UTF-8', 'Accept-Encoding': 'gzip, deflate'}
     Parameters: {'explorer': False}

returns the 477 unknown.

can't think of anything for this as i don't know anything about HMAC

Try to use double quotes instead of single ones. I know in a previous project, that this was the issue. Also the format of string/number.

Try to use double quotes instead of single ones. I know in a previous project, that this was the issue. Also the format of string/number.

the quotes make sense, i think i've worked in a file before i used single or double don't remember and it errored

I think json doesn't support single quotes, or was it requests? Or I may be wrong.

Yeah json is sensitive, maybe jodel server can't parse it

I replicated two absolute identical requests...the one in BurpSuire still worked, the one in python did not. Turned out you need to handle the HMAC key passed into the constructor instead of just ignoring it.
Pushed a new version.

Looks good!

Sounds like we can close this issue for now 👍


proposal: cmd/gofmt: allow case clause to be on the same line

What did you do?
Writing switch statements with single line cases, like so:
package main

import "fmt"

func main() {
        x := "this"

        switch x {
        case "this":  fmt.Println("yes!")
        case "that":  fmt.Println("no...")
        case "thiis": fmt.Println("almost")
        default:      fmt.Println("not at all")
        }
}

What did you expect to see?
it would be nice to see that gofmt does not put all the fmt.Println statements on a newline (leaving the above example as is).
The rule should be that if and only if all case clause bodies are one-liners, the user is allowed to put them on the same line as the case keyword.
Also, similar to other formatting cases, if the user already puts the code on the next line, leave it there.
Additionally, as can be seen in the example, align the start of every clause body, similarly to end of line comments over multiple lines.
i think it improves readability (iff there is only one line) and also looks similar to pattern matching from other languages like Rust or Haskell (which I consider to be syntactically nice-looking).
What did you see instead?
package main

import "fmt"

func main() {
        x := "this"

        switch x {
        case "this":
                fmt.Println("yes!")
        case "that":
                fmt.Println("no...")
        case "thiis":
                fmt.Println("almost")
        default:
                fmt.Println("not at all")
        }
}

Additional notes
The Go compiler would not be affected by this, as the scanning does not necessarily expect a newline (one can compile the first example just fine).
It is also backwards-compatible and actually not changing code that's already written.
Also, not sure if this should be a proposal or not. Let me know if it should be.

We don't allow if cond { stmt }, so I don't see why switch cases should be any different. The current format is perhaps a bit verbose, but it's consistent.

I agree, but I also see case statements different to if cond { stmt }, as they're not surrounded by curly braces. I also use switch mostly for some kind of pattern matching, which would make the similarity to other languages nice.
However, judging by the reactions on the posts, I can see that people are not really enthusiastic on this change. I'll give this another week for other comments, and then will close it.


hack.build: reduce the size of pouch and pouchd binaries

This patch is used for fix issue #1477.
git rev-parse HEAD
6fa7b4b2a52f9f8ceaef7532a3e79ae15fd88c8f
Without this patch:
pouch# make install
pouch# ll -h pouch pouchd
-rwxr-xr-x 1 root root 29M Jun   7 17:21 pouch*
-rwxr-xr-x 1 root root 58M Jun   7 17:21 pouchd*
With the patch:
pouch# make install
pouch# ll -h pouch pouchd
-rwxr-xr-x 1 root root 17M Jun   7 17:19 pouch*
-rwxr-xr-x 1 root root 33M Jun   7 17:19 pouchd*
Signed-off-by: Alex Jia<EMAIL_ADDRESS>
Ⅰ. Describe what this PR did
As subject
Ⅱ. Does this pull request fix one issue?

Ⅲ. Describe how you did it
use strip command to remove the symbol table and debugging information from an executable pouch and pouchd.
Ⅳ. Describe how to verify it
to compare size of pouch and pouchd binaries by ls -lh before and after applying this patch.
Ⅴ. Special notes for reviews

Codecov Report

Merging #1484 into master will increase coverage by 24.07%.
The diff coverage is n/a.

@@             Coverage Diff             @@
##           master    #1484       +/-   ##
===========================================
+ Coverage    16.3%   40.38%   +24.07%
===========================================
  Files         208      251       +43
  Lines       13883    16466     +2583
===========================================
+ Hits         2263     6649     +4386
+ Misses      11464     8964     -2500
- Partials      156      853      +697

Impacted Files
Coverage Δ

daemon/daemon.go
56.25% <0%> (ø)

registry/auth.go
54.12% <0%> (ø)

cri/stream/errors.go
0% <0%> (ø)

storage/volume/core.go
51.66% <0%> (ø)

storage/volume/driver/context.go
8.69% <0%> (ø)

cri/stream/portforward/portforward.go
0% <0%> (ø)

cri/stream/remotecommand/attach.go
0% <0%> (ø)

storage/quota/set_diskquota.go
9.09% <0%> (ø)

registry/auth_challenge.go
62.5% <0%> (ø)

cri/stream/remotecommand/httpstream.go
0% <0%> (ø)

... and 112 more

LGTM


Upgrade to latest openssl version

We are currently building with openssl 1.1.1d. Latest version right now is 1.1.1g

openssl comes from OS packages, with every build we do update. So far there are no CVE for open ssl, d version is safe to use.
Also grin does the same.
Alternative if to build open ssl from the sources. There are no reasons to deal with that problem.


Change opening urls to by-month

Changes
All urls for "openers" are now by-month, i.e. /projects/all/by-month and /projects/team/by-month
Rename the controllers and view paths to match.
Checklist

[ ] Attach this pull request to the appropriate card in Trello.
[x] Update the CHANGELOG.md if needed.

 By month routes and navigation


Update jobs.py: fix invalid escape sequence (issue #508)

Changes
Fixes #508, by making several offending strings into raw strings.
Tests
I used uv run ruff check --select W605  . --no-respect-gitignore on the directory where I have the last distribution of the code, and it seems to think these are the only invalid escape sequences in the project.

Today I was reminded by some warnings in my terminal that this is still a live issue. I would be pleased if it were merged, although it's ultimately of little importantance.
I will update this branch to match the base to keep this pr relevant, as GitHub seems to recommend.

I think this was probably fixed in another way (removing the backslashes entirely), in Sugust, with https://github.com/databricks/databricks-sdk-py/commit/fb30ed98912a4e62a4b535188765f792b7bc6f47#diff-9125abd285f0b94b52f0445f9f85a75a921fae47124d670ab9f8f822de9f33acL6
Hence this pr now has a merge conflict. And, more importantly, is redundant.


[Bug]: Layout shift when using loop with align center in NextJS

Which variants of Embla Carousel are you using?

[ ] embla-carousel (Core)
[X] embla-carousel-react
[ ] embla-carousel-vue
[ ] embla-carousel-svelte
[ ] embla-carousel-autoplay
[ ] embla-carousel-auto-scroll
[ ] embla-carousel-solid
[ ] embla-carousel-auto-height
[ ] embla-carousel-class-names
[ ] embla-carousel-fade
[ ] embla-carousel-docs (Documentation)
[ ] embla-carousel-docs (Generator)

Steps to reproduce
The bug occurs when I use loop with align center in NextJS
Expected Behavior
No layout shift
Additional Context
I have also tried... all possible solutions inclunde seting global options
What browsers are you seeing the problem on?
All browsers
Version
v8.2.0
CodeSandbox
https://codesandbox.io/p/live/484155ed-7efe-4660-bd70-5fa787fb5248
Before submitting

[X] I've made research efforts and searched the documentation
[X] I've searched for existing issues
[X] I agree to follow this project's Contributing Guidelines for bug reports

Uploading 2024-09-02 19-00-11.mp4…

https://github.com/user-attachments/assets/c4140804-440f-41e1-b04a-ec44d8b27fbc


The HP of the same boss is incorrect

Edit IV,The HP of the same boss is incorrect.

are you are talking about frostallion?

https://github.com/EternalWraith/PalEdit/pull/126 fixed it, hopefully, EternalWarith will accept this PR


Add info on "on-click-middle" option to custom module man page

Fixes issue #505

Can you also update other modules that aso implement on-click-middle :)

Updated all man pages that mention "on-click" with "on-click-middle" info

Thanks a lot <3

CI doesn't pass, i reverted the PR :/

Sorry, this is my first PR, so I don't know what that means. How can I fix it?

There's an indention pb, you can take a look at https://travis-ci.org/Alexays/Waybar/builds/625701949


Refactor dependence plot

Refactor dependence plot to core-ui, customize color based on cohortIndex

Areas changed

npm packages changed:

[ ] responsibleai/causality
[x] responsibleai/core-ui
[ ] responsibleai/counterfactuals
[ ] responsibleai/dataset-explorer
[ ] responsibleai/fairness
[ ] responsibleai/interpret
[ ] responsibleai/localization
[ ] responsibleai/mlchartlib
[ ] responsibleai/model-assessment

Python packages changed:

[ ] raiwidgets
[ ] responsibleai
[ ] erroranalysis
[ ] rai_core_flask

Tests

[x] No new tests required.
[ ] New tests for the added feature are part of this PR.
[ ] I validated the changes manually.

Screenshots (if appropriate):
Documentation:

[ ] My change requires a change to the documentation.
[ ] I have updated the documentation accordingly.

Codecov Report

Merging #1230 (5730505) into main (810b861) will increase coverage by 8.38%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##             main    #1230      +/-   ##
==========================================
+ Coverage   67.19%   75.58%   +8.38%
==========================================
  Files          91       10      -81
  Lines        4393      258    -4135
==========================================
- Hits         2952      195    -2757
+ Misses       1441       63    -1378

Flag
Coverage Δ

unittests
75.58% <ø> (+8.38%)
:arrow_up:

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files
Coverage Δ

raiwidgets/raiwidgets/utils.py

...ponsibleai/responsibleai/_tools/shared/__init__.py

.../responsibleai/modelanalysis/constants/__init__.py

raiwidgets/raiwidgets/dashboard.py

...ibleai/_tools/causal/dashboard_schemas/__init__.py

...ai/responsibleai/_tools/counterfactual/__init__.py

raiwidgets/raiwidgets/__version__.py

responsibleai/responsibleai/_config/__init__.py

raiwidgets/raiwidgets/model_analysis_dashboard.py

erroranalysis/erroranalysis/_internal/constants.py

... and 71 more

Continue to review full report at Codecov.

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


Possible to add rotation option for table preview screen?

Users that use a rotated main screen will have all the table previews rotated.
Is it possible to add a setting allowing previews to be rotated?

I'm not sure to what table previews you are refering to. Can you provide a screenshot that describes this?

Here is screenshot

Ah, yes. That's actually a bug. It will be fixed!

Solved, 2.18.3

Reopened the ticket, because now it's broken for users running Baller in portrait mode.

I forgot to close this ticket again. 2.18.4 should have fixed this issue.


add ai.h, and many AI(man intelligence) functions

          > add ai.h, and many AI(man intelligence) functions

https://github.com/JacobLinCool/Bang-C/pull/35#issue-1269333802

Originally posted by @maungzayyar in https://github.com/JacobLinCool/Bang-C/issues/35#issuecomment-1233908858

25


vkGetBufferMemoryRequirements reports wrong buffer alignment when running in the iOS simulator

When running a Metal app in the iOS simulator, Apple requires that align constant buffer offsets for render commands to be 256 bytes. (see: https://developer.apple.com/documentation/metal/developing_metal_apps_that_run_in_simulator?language=objc)
Trying to allocate a uniform buffer, vkGetBufferMemoryRequirements returns the alignment as 64 bytes. This leads to the following assert from the metal API validation: validateFunctionArguments:3722: failed assertion 'Fragment Function(main0): the offset into the buffer _23 that is bound at buffer index 0 must be a multiple of 256 but was set to 24960.'
The issue seems to be coming from this file: https://github.com/KhronosGroup/MoltenVK/blob/05066429e29cb5bf11d21cb2bc2b5ebfff94e7ae/MoltenVK/MoltenVK/GPUObjects/MVKDevice.mm where mtlBufferAlignment is set to 256 only for MVK_MACOS, but there's no check for the iOS simulator.

Thanks for reporting this.
Simulator on arm64 macOS will probably be okay, but X86_64 needs to be adjusted.


Cannot use Params on Link Component

Describe the bug
On the link component, I am not able to use the Params props if I do not want type safety. I dont really care about type safety on the router, and also I have the routes spread on different files instead which makes it hard for typescript to infer the types, therefore I never overrided the types of Router. Tho, on version 194 the Link Component allowed me to pass any Params I wanted, but on the latest version that throws a typing error.

Your Example Website or App
blank
Steps to Reproduce the Bug or Issue
Try to use Link component without overriding the types of router.
Expected behavior
I can use the Params on Link Component without the need to override router types.
Screenshots or Videos
No response
Platform

OS: [e.g. macOS, Windows, Linux]
Browser: [e.g. Chrome, Safari, Firefox]
Version: [e.g. 91.1]

Additional context
No response

Seems to work just fine on the latest version:


[FEAT]: Theme configuration in the profile

Is your feature request related to a problem?

[ ] The feature should solve a problem.

Describe the Problem your feature should fix.
No response
Describe the feature you would like to have.
When you save a profile your theme settings are also saved. This way the profile would be even more complete.
Describe the solution you'd like
No response
Describe alternatives you've considered
No response
Additional context
No response

Do you mean these?

yes

Thanks


[p50] Upgrade from 16.04 to 18.04

Work will soon transition to Ubuntu 18.04, and I also want to use the latest Gazebo 11.0, which is available only on Boinc onward.

Keep getting error.
$ sudo do-release-upgrade

Calculating the changes

Calculating the changes

Could not calculate the upgrade

An unresolvable problem occurred while calculating the upgrade.

This was likely caused by:
* Unofficial software packages not provided by Ubuntu
Please use the tool 'ppa-purge' from the ppa-purge
package to remove software from a Launchpad PPA and
try the upgrade again.

If none of this applies, then please report this bug using the
command 'ubuntu-bug ubuntu-release-upgrader-core' in a terminal.If
you want to investigate this yourself the log files in
'/var/log/dist-upgrade' will contain details about the upgrade.
Specifically, look at 'main.log' and 'apt.log'.

Restoring original system state

Aborting
Reading package lists... Done
Building dependency tree
Reading state information... Done
=== Command detached from window (Wed Sep 30 08:56:30 2020) ===
=== Command terminated with exit status 1 (Wed Sep 30 08:56:40 2020) ===

Kept running into an error:

An unresolvable problem occurred while calculating the upgrade.

Basically https://askubuntu.com/a/1072061/24203 that suggests purging qt helped. I did apt purge libqtcore5* && apt-get autoremove then the error disappeared.

Upgrade is done. Looks like it took a few hours.
Things I noticed so far:

synergy got uninstalled. Re-installed.
Can't switch to mozc? I do see mozc_server running. Looks like this is why I switched to MATE on kudu1? https://github.com/130s/hut_10sqft/issues/394#issuecomment-549500646

Menu shortcut on windows is gone -> Solved by #394 (comment)  apt-get install gnome-panel.

Looks like it got reverted when OS rebooted (I'm not sure why it rebooted. It happened while I was rearranging power and ethernet cables. Laptop should have battery).


Running Phaser 4 in Background?

Running Phaser 4 in the Background ... Example Phaser 2: disableVisibilityChange = true;

This isn't possible (and wasn't in v2 either) - browsers will automatically disable Request Animation Frame as soon as the tab or browser window is sent to the background, and there is nothing you can do to stop this.


balsa: 2.5.7 -> 2.5.9

Semi-automatic update generated by https://github.com/ryantm/nixpkgs-update tools. This update was made based on information from https://repology.org/metapackage/balsa/versions.
meta.description for balsa is: '"An e-mail client for GNOME"'.
meta.homepage for balsa is: '"http://pawsa.fedorapeople.org/balsa/"

Checks done (click to expand)

built on NixOS

The tests defined in passthru.tests, if any, passed

0 of 0 passed binary check by having a zero exit code.

0 of 0 passed binary check by having the new version present in output.

found 2.5.9 with grep in /nix/store/wl15zj5jd8fwx0jld82vxf6cy570vih3-balsa-2.5.9

directory tree listing: https://gist.github.com/cf16737c4df29fc29f18feb19bfb0019

du listing: https://gist.github.com/e3726f60454bad180fb5b8ae1f4ed652

Rebuild report (if merged into master) (click to expand)

4 total rebuild path(s)
1 package rebuild(s)
1 x86_64-linux rebuild(s)
1 i686-linux rebuild(s)
1 x86_64-darwin rebuild(s)
1 aarch64-linux rebuild(s)
First fifty rebuilds by attrpath
balsa

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/wl15zj5jd8fwx0jld82vxf6cy570vih3-balsa-2.5.9 \
  --option binary-caches 'https://cache.nixos.org/ https://r-ryantm.cachix.org/' \
  --option trusted-public-keys '
  r-ryantm.cachix.org-1:gkUbLkouDAyvBdpBX0JOdIiD2/DP1ldF3Z3Y6Gqcc4c=
  cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY=
  '

(r-ryantm's Cachix cache is only trusted for this store-path realization.)
Or, build yourself:
nix-build -A balsa https://github.com/r-ryantm/nixpkgs/archive/7e394a3e822d6cff680473f5ee4a3322c9e785e6.tar.gz

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/wl15zj5jd8fwx0jld82vxf6cy570vih3-balsa-2.5.9
ls -la /nix/store/wl15zj5jd8fwx0jld82vxf6cy570vih3-balsa-2.5.9/bin

cc @romildo for testing.

The main bin runs (mail client) but:
$ ./results/balsa/bin/balsa-ab
Segmentation fault (core dumped)

The address book works for me.

I am getting the same:
$ env G_MESSAGES_DEBUG=all result/bin/balsa-ab
(balsa-ab:7201): GLib-GIO-DEBUG: 15:34:16.601: _g_io_module_get_default: Found default implementation gvfs (GDaemonVfs) for ‘gio-vfs’
(balsa-ab:7201): Gtk-DEBUG: 15:34:16.636: Connecting to session manager
fish: “env G_MESSAGES_DEBUG=all result…” terminated by signal SIGSEGV (Address boundary error)

Backtrace:
#0  0x000000000040ca13 in main (argc=<optimized out>, argv=<optimized out>) at ab-main.c:1101

https://gitlab.gnome.org/GNOME/balsa/blob/2.5.9/src/ab-main.c#L1101
Valgrind:
==8010==
==8010== 1 errors in context 1 of 30:
==8010== Invalid read of size 8
==8010==    at 0x40CA13: main (ab-main.c:1124)
==8010==  Address 0x0 is not stack'd, malloc'd or (recently) free'd

https://gitlab.gnome.org/GNOME/balsa/blob/2.5.9/src/ab-main.c#L1124

But I get that with Balsa 2.5.7 too, so it probably is not regression.

After removing ~/.balsa the program balsa-ab gives segmentation fault (core dumped) for me too.
Tested on archlinux too, with the same behaviour.

Ok, in that case I'll merge.
Maybe worth mentioning upstream though?

https://gitlab.gnome.org/GNOME/balsa/issues/22


small fix

k love u bye

Lol thanks, but I was just about to commit that. If you make commits in the future though please make sure the commit message is more descriptive.


Add classes while dragging upside

I wanted to add classes to 'as-split-area' while dragging upside and when we drag back, the class should remove. Please help
To Reproduce
Create a Stackblitz demoing the bug/issue:
https://stackblitz.com/

Seems like a nice addition, I'm happy to review and merge a PR that adds support for this.


Delete and Append refresh apis should not throw error if data isn't changed

What is the context for this pull request?
Hyperspace throws error for refreshIndex api for following cases:

with delete flag enabled, and no data files were deleted => HyperspaceException
with append flag enabled, and no new data files were appended => HyperspaceException

Ideally the behavior should be, a refreshIndex just end operation saying "Nothing to do!!".
This PR introduces another exception type: NoChangesDetected. The base Action class eats up these exception with logging what happened and why it's not necessary to continue this operation.
The end user just sees log warnings but their code is not broken if source data is not modified.

Parent Issue: Please refer uber PR #187 with complete details
Dependencies: NA

What changes were proposed in this pull request?
Change the behavior of refresh api for deletes and appends if source data is not modified.

Does this PR introduce any user-facing change?
Yes:
Hyperspace will NOT throw error for refreshIndex api for following cases:

with delete flag enabled, and no data files were deleted => logWarning and continue
with append flag enabled, and no new data files were appended => logWarning and continue

How was this patch tested?
updated unit tests for this case

I think it would be good to check the condition - no data change - for "full" refresh mode?
It doesn't need to be handled with this PR, but it seems necessary.

I think it would be good to check the condition - no data change - for "full" refresh mode?
It doesn't need to be handled with this PR, but it seems necessary.

Fair enough, created this issue #190

@apoorvedave1 Can you check the build failure?


Add notice examples and bump versions

Merging without review, as it's just new examples and versions bumps


Issue #1197 Ability to dynamically set the status and exception of a test via ITestResult

Fixes #1197 .
Did you remember to?

[ ] Add test case(s)
[X] Update CHANGES.txt

Fix the ability to dynamically set the status and exception of a Test by
using Reporter.getCurrentTestResult

Instead of if (testResult.getStatus == ITestResult.STARTED), I considered explicitly calling out the states that TestNG could support a user setting, such as FAILED, SKIPPED only, etc.

Thanks for the pull request but could you fix it (a bracket is missing) and add a test case to assure the feature won't be broken anymore?

Well, that's so embarrassing.  I was trying to set up my env and couldn't configure it correctly, so I figured I'd make a simple change to it withOUT an IDE and I goofed that up.  Shows how much I rely on an IDE.  I was working on a sample to reproduce it for the ISSUE, but I'll turn that into a test case now.

@ILikeToNguyen Could you add some non regression tests?

@ILikeToNguyen Hi, any updates? :)

Merged with #1315
Thanks for the fix :+1:

For reference, this feature will only work in a next IntelliJ release: https://youtrack.jetbrains.com/issue/IDEA-167298
@missedone Could you check if the eclipse plugin won't crash with this feature?

@juherr , so far so good with eclipse plugin 6.10.0.x


Density-Based Spatial Clustering of Applications with Noise

Description
If you had referred any resources, add them up in "DS Resources". Similarly, if you had used datasets, include them in "DS Datasets".
This issue will help in getting a better understanding of 'Density-Based Spatial Clustering of Applications with Noise' in a detailed manner.
It's created on contributors request as mentioned in Discord channel.
Domain: Machine Learning
Mentors Assigned : Aishani Singh | Dhruv Bajaj
Points to Note :
The issues will be assigned on a first come first serve basis, 1 Issue == 1 PR.
"Issue Title" and "PR Title" should be the same. Include issue number along with it.
Changes should be made inside the Datascience_With_Python/ directory & Datascience_With_Python branch.
Follow Contributing Guidelines & Code of Conduct before start Contributing.
This issue is only for 'GWOC' contributors of 'DSWP' domain.
All the best. Enjoy your journey ahead. 🌷
Domain
Datascience with Python
Type of Contribution
Audio, Video, Documentation
Code of Conduct

[ ] I follow Contributing Guidelines & Code of conduct of this project.

Name = Hasti Sutaria
Type = documentation
Approach = Practical implementation and theortical overview

/assign

I Would like to work on this in documentation format.

Have you worked on changes addressed to your PR? @HastiSutaria

Yes @prathimacode-hub. I made the required changes yesterday itself

Also ma’am once you approve it. I am ready with another pr completed from my side is data science domain. So I will also create its pr.

Sure, you can proceed. @HastiSutaria

Name - Kishlay Kumar
Batch - 4
Serial No - 673
GithubLink :- https://github.com/kishlayaug15
Approach: A detailed explanation with Audio

You had assigned to other issue also i think? @kishlayaug15

@prathimacode-hub detailed explaination in READme file and practical implementation in ipynb file would be enough ma'am for this issue ?

@prathimacode-hub Ma'am can I please get the exact path under Machine learning branch where to upload file while creating the PR?

Yes, it would be enough. It will go under "Datascience_with_Python/Machine Learning/Tutorials" folder  @HastiSutaria


Support kwargs in export_testcase

close: #717
supported export_testcase with kwargs.
Similarly to https://pytorch.org/docs/stable/onnx.html#torch.onnx.export , you can do this by putting a dictionary of kwargs at the last element of args.
When doing this, users are required to explicitly specify input_names in order to name input pb tensors (kwargs are not positional, so we don't use input_0.pb-like naming).
I also added these remarks in the docs.

/test

Thanks a lot to fix the bug of opset version!


How to switch nodejs version?

I installed nodejs and nodejs-lts, I want switch Node.js LTS version to Node.js latest.
How to do it? Thanks!
PS C:\Users\garfi> node -v
v6.11.0
PS C:\Users\garfi> scoop list
Installed apps:

  7zip (16.04) *global*
  nodejs (8.1.3) *global*
  nodejs-lts (6.11.0) *global*
  sudo (0.2017.03.24)
  yarn (0.27.5)

PS C:\Users\garfi> sudo scoop reset nodejs
'nodejs ()' isn't installed

reset isn't implemented for globally installed apps, so currently you'd have to reinstall these 2 Node.js versions without --global if you want to be able switch between them.
If you need global installs, currently you will need to reinstall nodejs (withsudo scoop uninstall nodejs -g; sudo scoop install nodejs -g) to use it again. So if you need to switch frequently it might work better to use nvm or non-global installs.
I'm marking this as a bug because we need to either implement global resets or give better feedback in the interface.


Added Login Page

Link this login page with homepage. You have to create a login tab in navigation bar and then link it to loginpage.html using  tag.

please check now

Nice work! @shweta-laha Thank you for contributing to the project!


Items in invetnorys are italic by default

I had a look into this but didn't find much

Should be fixed with version 4.4.0

Basically hard coded it to not be italic
component.decoration(TextDecoration.ITALIC, false)

Couldnt figure out a better way


intl.d.ts: cleanup, add missing features, fix library discrepancies

Recent work on the Intl library definitions revealed a lot of outstanding inaccuracies and inconsistencies, and so I've taken a deep dive through ECMA-402 and done some significant housekeeping.
This is a big PR, and I've itemised the changes for ease of review. The majority are straightforward and uncontroversial updates to bring things in line with the spec, and it seems sensible just to have them as one PR.
A couple of proposed changes have breaking potential or are related to the typing meta, and are marked 🚩 to indicate that they may need discussion.
Library-wide
Typings

Where a literal union is used more than once, it is now declared as a type in order to avoid duplication, under the {ConstructorName}Options{PropertyName} naming convention. This practice started to be used here and there in later lib.intl updates, but is now consistent throughout.
Changed the convention for types derived from "option registry" interfaces.

Before, these types were simply aliases to keyof R, which works fine for validation, but isn't very helpful in tsserver output.

type Intl.NumberFormatOptionsStyle = keyof NumberFormatOptionsStyleRegistry – so what are the valid options?

Now, these types are of the form R[keyof R], which ensures that they're resolved to a union type.

type Intl.NumberFormatOptionsStyle = "decimal" | "percent" | "currency" – much more accessible.

🚩 Renamed a small number of remaining option literal union types from {ConstructorName}{PropertyName} to {ConstructorName}Options{PropertyName}. These are exported types, so in theory this is breaking if anyone is importing those specific union types from the library; however, the maintenance and DX benefits of a universal namespace convention seem to support this change. (There are no resulting errors in the user test suite.)
🚩 Removed the type UnicodeBCP47LanguageTag, which is simply a primitive type alias to string. This gets optimised away by the compiler, and serves no useful purpose; there are no other examples of "primitive alias as usage descriptor" elsewhere in the library.

Documentation

MDN links and copied documentation have been removed throughout. I'm guessing these were added due to a sense of mistaken equivalence with the DOM APIs, but they shouldn't be present on ECMA definitions.
Added/updated docblocks for all methods and properties of Intl prototypes.
Docblocks for each individual option property have been removed. This declutters the library significantly, for no significant impact on DX: for self-explanatory options, the description adds nothing, whereas for complex ones, a one-sentence summary doesn't eliminate the need to read the manual.
Docblocks for constructors have been removed, in keeping with the rest of the library.

Tests

Conformance tests are consolidated into a single testfile per lib.intl version.
Many of the existing intl tests were implementation tests copied from MDN, rather than type validation tests, which has been addressed.

Intl

Moved the definition of Intl.supportedValuesOf from es2022 to es2023.
Added override for Intl.getCanonicalLocales to es2020.
Added missing prototype properties of Intl constructors.

Intl.Collator

🚩 Removed string union of valid collations. This list is subject to change in CLDR, and exactly which collations are supported is implementation-dependent. It doesn't seem like the sort of list that should be hard-coded here.

A list of implementation-supported collations is now accessible via es2023's Intl.supportedValuesOf(), if runtime validation is desired.

Moved collation option from es5 to es2021.
The collator options caseFirst and numeric only exist if they are supported by the implementation and are absent if not, hence these are typed as optional.

Intl.DateTimeFormat

Removed bigint from argument types in format functions, as explicitly not supported.
Narrowed ResolvedDateTimeFormatOptions property types in es5.
Moved hourCycle option from es2020 to es2018.
Moved dayPeriod, dateStyle, timeStyle options from es2020 to es2021.
Progressive typing of timeZoneName, with values {short,long}Offset and {short,long}Generic moved to es2022.
Added missing part types relatedYear and yearName to es2020.
Removed duplicate interface properties.

Intl.DisplayNames

Moved the definition from es2020 to es2021.
DisplayNamesOptions properties may be undefined.
Progressive typing of DisplayNamesOptionsType, with values calendar and dateTimeField moved to es2022.
Moved languageDisplay option to es2022.
New DisplayNameConstructor interface.

Intl.ListFormat

Added ListFormatPart interface.
Renamed some existing option literal union types from ListFormat{PropertyName} to ListFormatOptions{PropertyName}.
New ListFormatConstructor interface.

Intl.Locale

Refactored, with the Locale prototype no longer being typed as a child interface of LocaleOptions.
New LocaleConstructor interface.
LocaleOptions properties may be undefined.
Correctly type Locale properties as required/readonly.
The properties caseFirst and numeric only exist if they are supported by the implementation and are absent if not, hence these are typed as optional.

Intl.NumberFormat

Removed bigint from the original definition of the formatToParts method in es2018 (prior to the language feature's existence), and added a new override to es2020.bigint.

Intl.PluralRules

Added the missing selectRange method to es2023.
Added "NumberFormat v3" options to PluralRules in es2023.
Under ResolvedPluralRulesOptions, {minimum,maximum}FractionDigits may be omitted from es2023 onwards, and these are therefore typed as optional throughout. This mirrors the equivalent change to ResolvedNumberFormatOptions in #56902.
Constructor cannot be invoked without new.

Intl.RelativeTimeFormat

Added the missing numberingSystem option.
Partitioned part and unit types for clarity.
Renamed some existing option literal union types from RelativeTimeFormat{PropertyName} to RelativeTimeFormatOptions{PropertyName}.

Intl.Segmenter

Segments#containing may return undefined if the specified index does not exist.
New SegmenterConstructor interface.

Locale methods of primitive prototypes

Arbitrary nomenclature to refer to the three types of locale method definitions within the library:

"es5 placeholders", zero-arity placeholder methods defined in the original ECMA-262 specification, intended to be overriden by ECMA-402 definitions.
"first-generation overrides", defined prior to es2020, which accept a locales parameter of type string | readonly string[].
"second-generation overrides", defined in es2020 and later, which accept a locales parameter of type Intl.LocalesArgument.

Implement the second-generation overrides for Array.prototype.toLocaleString and TypedArray.prototype.toLocaleString under es2020.array, which were omitted from #57679.
Move first-generation overrides String.prototype.toLocale{Lower,Upper}Case to es2015.core.
Ensure the locales argument to all first-generation overrides accepts readonly string[], as per #56513.
Use NumberFormatOptions in the definition of BigInt.prototype.toLocaleString in es2020.bigint, and remove the duplicate NumberFormat definitions.
toLocaleString method of BigInt64Array and BigUint64Array prototypes updated to the second-generation override signature.
Update docblocks for locale methods, including es5 placeholder methods.
🚩 Widen the type of the options parameter of Array.prototype.toLocaleString.

The current type assumes that the only objects overriding toLocaleString will be builtin number-like/date-like objects, whose toLocaleString method will pass its parameters to either NumberFormat or DateTimeFormat.
However, the standard for Array.prototype.toLocaleString doesn't specify this; it will pass its parameters to any object's toLocaleString method, including user-defined methods. All that ECMA-262 asks is that those parameters not be used for anything other than the standard toLocaleString parameter pattern.
Accordingly, this function should, by right, remain agnostic about its elements' toLocaleString implementations – providing they obey the standardised function signature.
To achieve this, the type of the options parameter could be widened to object. However, this comes at the expense of not type-checking any option properties, even for arrays of builtin elements which were covered just fine by the previous behaviour.
The alternative is to leave the parameter as-is, and accept the above limitations.
In an ideal world, we would conditionally infer the options parameter type from T, but this leads to issues with infinite recursion, so doesn't look like it's an option.

🚩 Discussion on #57679 covered the question of whether the locales parameter of first- and second-generation overrides should be required or optional when an es5 placeholder already exists.

The verdict there was that the first parameter should be required, so that the new override and the es5 placeholder don't have overlapping signatures.
However, this disallows usage like the following:numberArray.toLocaleString(undefined, { minimumIntegerDigits: 3 });

...which is a valid way of selecting the default locale while also specifying custom format options. Keeping the first parameter optional is an easy way of allowing this usage case.
It's only the array methods added by the above PR that currently use the "mandatory first parameter" signature; all other existing first- and second-generation overrides have the locales parameter as optional.

@typescript-bot test it

One blooper thrown up by top400, in that I'd managed to partially revert #47720, which has now been restored. The remaining errors are consistent with the removal/renaming of type exports as detailed above.
Re-running top400 might be useful to clarify the lay of the land.

@typescript-bot test it

Here are the results of running the top 400 repos comparing main and refs/pull/58084/merge:
Something interesting changed - please have a look.

date-fns and formatjs have been patched to avoid referencing these types altogether, so these errors should no longer appear.
jupyterlab would just need to add the es2021.intl library in order to use the dateStyle and timeStyle options of DateTimeFormat.

@typescript-bot test it

@typescript-bot test it

Starting jobs; this comment will be updated as builds start and complete.

Command
Status
Results

test top400
✅ Started
👀 Results

user test this
✅ Started
✅ Results

run dt
✅ Started
✅ Results

perf test this faster
✅ Started
👀 Results

perf

Small increase in symbol counts, likely primarily due to new method overrides on Array.prototype and String.prototype
No significant change in overall performance

top400

jupyterlab:

DateTimeFormatOptions dateStyle and timeStyle properties no longer present in ES2020.Intl

fix: add ES2021.Intl to libs

vscode:

ResolvedCollatorOptions numeric property may be undefined

fix: ?? false

UnicodeBCP47LocaleIdentifier no longer exists

fix: replace all instances with string

UnicodeBCP47LocaleIdentifier no longer exists

fix: replace all instances with string

We definitely do not want to be deleting types from lib.d.ts.

Keep and deprecate?

Yes, or keep using (if it makes sense).

I don't know if this is related, but since TypeScript 5.5, we have some issue with changes in Number.ToLocaleString().
// Defined once to avoid copy pasting this everywhere.
const percentOptions = {
    minimumFractionDigits: 2,
    maximumFractionDigits: 2,
    style: "percent",
};

let output1 = number1.toLocaleString(undefined, percentOptions);
let output2 = number2.toLocaleString(undefined, percentOptions);
let output3 = number3.toLocaleString(undefined, percentOptions);

Typescript will shout about this, because "percent" is narrowed to string instead of the subset of valid style values.
Now, of course, we can write this, but nobody is going to remember this from memory and this is just TypeScript getting in the way.
const percentOptions = {
    minimumFractionDigits: 2,
    maximumFractionDigits: 2,
    style: "percent" as keyof Intl.NumberFormatOptionsStyleRegistry,
};

Sorry if this is the wrong place to mention this, but I wasn't sure if opening a new issue was the way to go.

@wartab: This was intentionally changed previously to make the enum-style string option types consistent.
For your example, using as const would be simpler than as keyof..., or you could influence the shape of the options object as a whole by using a satisfies clause or explicitly typing the variable as an Intl.NumberFormatOptions object.


feat(rpc): extra validation send_raw_transaction

Time spent on this PR: 0.2 day
Resolves: #1264
Pull Request type

Please check the type of change your PR introduces:

[ ] Bugfix
[x] Feature
[ ] Code style update (formatting, renaming)
[ ] Refactoring (no functional changes, no API changes)
[ ] Build-related changes
[ ] Documentation content changes
[ ] Testing

What is the new behavior?
Add validation of the transaction's gas limit, max priority fee and max fee.

Does this introduce a breaking change?

[ ] Yes
[x] No

About the gas fee test that fails on the retry, we should probably modify places in the codebase where we have hardcoded stuffs for test like:
https://github.com/kkrt-labs/kakarot-rpc/blob/a93f559f113e70500890ccfa79107529d490584b/src/test_utils/eoa.rs#L226
which doesn't respect your validation condition, wdyt?

trying rn but quite complicated

trying rn but quite complicated

I imagine that this validation also breaks some hive tests no?

I think the hive tests failed because of block number, made a mistake when modifying but should be ok (tm)


Fix for issue #768

Description of Change
I've exposed the dialog style selector for the iOS time picker
Issues Resolved

fixes #768

API Changes
Added picker style properties to TimePickerConfig
Passed values to the Controller for use in the presentation code
Platforms Affected

iOS

Behavioral Changes
Allows the consuming application to show time dialogs in iOS 14 as wheel pickers.
Testing Procedure
Run the test iOS application and specify iOSPickerStyle = iOSPickerStyle.Wheels in the config options

Thanks for the PR


Add relationship between replicators and container groups

@simon3z Please review.

@miq-bot add_label providers/containers
@miq-bot add_label ui

@zakiva Please rebase and push again
cc @simon3z @abonas

@Fryguy Please review.

@dclarizio @h-kataria @martinpovolny Please review

@zakiva @abonas @simon3z For PRs with UI changes, please provide before and after screenshots to help the reviewers.

additions are marked:

:+1: apart from the minor comment this can be merged @Fryguy @blomquisg @chessbyte

@zakiva Please rebase and push again.

@Fryguy seems that Rubocop is giving false positives!

@simon3z Please review

LGTM :+1: ready for merge


Additions to the spy / spy verification APIs

This task is intended as a summary of the currently proposed additions to the spy APIs. This includes #115, #102, #78, #92 and #11.
These are the proposed methods:

generates() - starts generator stubbing (#11) done
resolvesTo() - returns a promise that resolves to a value (#78) not needed
rejectsWith() - returns a promise that rejects with a value (#78) not needed
notifies() - emits a promise notification (#78) not needed
cancels() - causes the promise to be cancelled (#78) not needed
resolvedTo() - verifies that a promise resolved to a value (#78)
rejectedWith() - verifies that a promise rejected with a value (#78)
notified() - verifies that the promise emitted a notification (#78)
cancelled() - verifies that the promise was cancelled (#78)
generated() - verifies that a spy or call returned a generator (#115) OR
generatorReturned() - verifies that a generator returned a value (#115)
generatorThrew() - verifies that a generator threw an exception (#115)
responded() - verifies that a call "responded" (returned the initial generator or traversable) (also passes for returned non-traversables and regular thrown exceptions) (#92)
completed() - verifies that a call "completed" (similar to consumed(), but passes for returned non-traversables and regular thrown exceptions) (#92)
started() - verifies that iteration started (#102) - pretty ambiguous name, maybe we can find a better one
consumed() - verifies that iteration completed (#102)

I've been thinking about an alternate approach to generator, traversable, and promise verification. Perhaps instead of littering the call and spy APIs with lots of verification methods, there could be additional validator interfaces accessible via generated(), produced() (or similar), and promised().
These validators would have only the methods relevant to each, and would still represent a "verification result", so that they can be used in event order verification.
When a user calls generated() for example, this would result in a verification failure unless the spy/call returned a generator. On success, the result would be an event collection containing each of the calls that returned a generator, but it would also implement a generator verification API. This API would allow for method names like returned() and threw() to be re-used, and only apply to generators.
Typical usage might look something like this:
inOrder(
    $spyA->generated(),
    $spyB->generated()->returned('a')
    $spyC->callAt(1)->generated()->threw()
);

There's a side benefit to this approach too, in that these additional validators can be used by both spy validators and individual call validators. This probably means less effort is required to implement these new features.

1.0 HYPE!!! 🎉


[Bug]: "feeds" enum not properly initialized in Python 3.11

Is there an existing issue for this?

[X] I have searched the existing issues

Current Behavior
Python 3.11 changed ENUM behavior; as such, feed parameter is not correctly initialized.
Expected Behavior
No response
SDK Version I encountered this issue in
0.9.0
Steps To Reproduce
Install Python 3.11, try to run the examples in the documentation.

Filled out the Steps to Reproduce section?

[X] I have entered valid steps to reproduce my issue or have attached a minimally reproducible case in code that shows my issue happening; and understand that without this my issue will be flagged as invalid and closed after 30 days.

Anything else?
No response

Hi @amor71 is this still relevant when using the latest version (v0.12) of alpaca-py? If it is could you add a reproducible example of the issue?


BUG in Get_support_vectors

I use MKLRegression or MKLBinaryClassification & Crossvalidation, and I need weights for every feature. To this end, I obtain alphas and support_vectors for every machine.
The machine here was obtained according to this website:
http://www.shogun-toolbox.org/examples/latest/examples/evaluation/cross_validation_mkl_weights_storage.html#
Code:
obs = mkl_obs.get_observation(0)
fold = obs.get_fold(0)
machine = MKLClassification.obtain_from_generic(fold.get_trained_machine())
Then, I use the "machine.get_support_vectors()" to get support vectors, but it's wrong.
But  another function "machine.get_svm().get_support_vectors()" is right.
The results of the two functions are different.
In terms of MKLMulticlass, e.g. 3 class, I use "machine.get_svm(0).get_support_vectors()", "machine.get_svm(1).get_support_vectors()",  "machine.get_svm(2).get_support_vectors()",  to get support vectors respectively.
But again, it's not the right support vectors. So I don't know how to obtain the right support vectors when I use MKLMulticlass.
Apologize for my poor english, and I hope you can understand what I write.
I would appreciate it very much if you would help me with it.

In terms of MKLBinaryClassification:
For example, when I used the "machine.get_svm().get_support_vectors()", I got the right support vectors (11 elements) like:
array([ 0,  1,  3,  5,  9, 11, 12, 13,  2,  6,  7,  8], dtype=int32)
However, when I used the "machine.get_support_vectors()" in the same data set, I just got an array with 11 consecutive numbers, like this:
array([ 0,  1,  2,  3,  4,  5,  6,  7,  8,  9, 10, 11], dtype=int32)
Likewise, when I applied MKLMulticlass to another data set (3 classes), "machine.get_svm(0).get_support_vectors()" only returned an array with consecutive numbers as follows:
array([ 0,  1,  2,  3,  4,  5,  6,  7,  8,  9, 10, 11, 12, 13, 14, 15, 16,
17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33,
34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50,
51, 52, 53, 54, 55, 56, 57, 58, 59, 60, 61, 62, 63, 64, 65, 66, 67,
68, 69, 70], dtype=int32)
Again, I would appreciate it very much if you would help me with the problem.
Thank you.

Sorry, I dont understand what exactly your problem is. Could you make a minimal example where you state what you expect and contrast it with what you get?

Sorry, I will try and clear this up a bit.
My ultimate goal is to obtain the weight for each feature. When a linear kernel is applied, I can achieve it by using the feature set & support_vectors & alphas, right?
For example, I applied a SVR to a toy data set provided by Shogun, the code is:
# - Create toy data
# 13 features, 506 samples
import os
SHOGUN_DATA_DIR=os.getenv('SHOGUN_DATA_DIR', 'shogun-data')
# feats.get_feature_matrix().shape: (13, 506)
feats=RealFeatures(CSVFile(os.path.join(SHOGUN_DATA_DIR, 'uci/housing/fm_housing.dat')))
# labels.get_labels().shape: (506, )
labels=RegressionLabels(CSVFile(os.path.join(SHOGUN_DATA_DIR, 'uci/housing/housing_label.dat')))

# - preprocessing
preproc=RescaleFeatures()
preproc.init(feats)
feats.add_preprocessor(preproc)
feats.apply_preprocessor(True)

# - svr
# linear kernel
kernel = LinearKernel(feats,feats)
svm_c = 1.0
svr_param = 0.1
svr = LibSVR(svm_c, svr_param, kernel, labels, LIBSVR_EPSILON_SVR)
svr.train(feats)

# - alpha & support_vectors
# the shape of alpha is euqal to the shape of support_vectors
# and the shape is less than or equal to feats.get_num_vectors(), namely 506
alpha = svr.get_alphas() # alpha.shape:(494,)
SV = svr.get_support_vectors() # SV.shape:(494,)

# - Weight of each feature
# totally 13 features, so the shape of W is 13
# Obtained W is:
# [ -3.73195103   3.21850969  -1.09377049   2.33308119  -2.92698099
#   13.34006223  -1.76996077  -6.74227507   1.2710798   -3.60773944
#   -6.69543076   3.29937386 -11.98031221]
W = 0
for i, j in enumerate(svr.get_support_vectors()):
    W = W+feats[:,j]*alpha[i]

# - Verify the correctness of the W
# use the W to get the predicted result of a specific sample
# for example, the 100th sample
pred_lab_01 = np.dot(feats[:,100], W)+svr.get_bias() # 22.297838688409424

# directly use the trained svr to get the predicted result of the 100th sample
pred_lab_02 = svr.apply_regression().get_labels()[100] # 22.297838688409445
# pred_lab_01 == pred_lab_02  is TRUE, so the obtained W is correct

In the above example, W is the one that I want, and I verify its correctness by the formula:
Predicted result = W * feat + bias
However, when I perform the Cross Validation, I can not get the right support_vectors from a trained machine of a specific fold, so I cannot work out a right W for features.
Again, for example, I performed Cross Validation on Multiple Kernel Learning like this site:
http://www.shogun-toolbox.org/examples/latest/examples/evaluation/cross_validation_mkl_weights_storage.html
The key code is:
# - CROSS VALIDATION

# mklCV setting
libsvm = LibSVM()
mklCV = MKLClassification(libsvm)
mklCV.set_kernel(combined_kernel)
mklCV.set_labels(labels)

# 3-fold cross-validation
# Multiclass or binary labels required for stratified crossvalidation
fold_num = 3
split=StratifiedCrossValidationSplitting(labels, fold_num)
metric=RecallMeasure() # sensitivity metric
cross=CrossValidation(mklCV, combined_feats, labels, split, metric)
cross.set_autolock(False)

# for each observation of CV
mkl_obs = ParameterObserverCV(True)
cross.subscribe_to_parameters(mkl_obs)

# run MKL with CV
result = CrossValidationResult.obtain_from_generic(cross.evaluate())

# get trained machine of every fold
obs = mkl_obs.get_observation(0)
for foldth in range(fold_num):
    fold = obs.get_fold(foldth)
    machine = MKLClassification.obtain_from_generic(fold.get_trained_machine())

In this example, there are totally 21 samples, so 14 samples are included each train set and the shape of support_vectors is less than or equal to 14.
I first got the support_vectors by using the code:
machine.get_support_vectors()
But I just got an array with 11 consecutive numbers, like this:
array([ 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11], dtype=int32)
In fact, the right support_vectors (11 elements) can be obtained by the code:
machine.get_svm().get_support_vectors()
and the right result is:
array([ 0, 1, 3, 5, 9, 11, 12, 13, 2, 6, 7, 8], dtype=int32)
I have verified the correctness of the support_vectors by using the above formula:
Predicted result = W * feat + bias
However, when I applied MKLMulticlass to another data set (3 classes), the only way to get support_vectors was:
machine.get_svm(0).get_support_vectors()
machine.get_svm(1).get_support_vectors()
machine.get_svm(2).get_support_vectors()

Unfortunately,  it only returned an array with consecutive numbers like:
array([ 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18], dtype=int32)
It's not a right result.
In sum up, when a cross validation is applied, there are some problems with the function "get_support_vectors()".
And I want to know how could I get the right support vectors when I perform cross validation on MKLMulticlass.
Thank you.


Create CONTRIBUTING.md

https://github.com/blog/1184-contributing-guidelines
This should replace https://github.com/tesseract-ocr/tesseract/wiki/FAQ#rules-and-advice
Any comments?

I would keep it in FAQ too, or provide link with short description...

Yeah, this was my intention :-)
I'm more in favor for the link option.

@zdenop
Yesterday there was an option to "squash and merge" in the PR web interface. I don't see it right now. Did you change the setting?
https://github.com/blog/2141-squash-your-commits

No I did not make any changes.

The option is visible in the 2nd step of the merge process: first you select "Merge pull request", then you can change the kind of merge during the confirmation.

Okay :)

I wanted to choose this option, but accidentally push the button itself instead of the arrow :(
Not a big deal...

IMHO, this is bad UX design.

Yes, it is not so nice.
Squashing can also be done in your local copy of the repository (git rebase -i, then update your pull request with git push -f). I personally prefer that variant as it avoids the problem with the GitHub user interface.

Right. but it's too tempting  to use the GUI - just a few clicks...

https://github.com/tesseract-ocr/tesseract/wiki/FAQ#rules-and-advice


Zero gradient from clipping critic output in DDPG?

The actor loss is defined as (Line 164):
self.actor_loss = -tf.reduce_mean(self.critic_with_actor_tf)

Doesn't clipping self.critic_with_actor_tf set large critic gradients to 0 instead of to 1 (Line 125)?
self.critic_with_actor_tf = denormalize(tf.clip_by_value(self.normalized_critic_with_actor_tf, self.return_range[0], self.return_range[1]), self.ret_rms)

Line 125 isn't clipping any gradients. It's just clipping the critic's output by the environment's min/max return. This prevents the critic from predicting a return outside the possible return range of the environment.

What is the gradient when the value is too large and gets clipped?

I don't know, but it doesn't sound like an issue of clipping gradients. Clipping the critic output may be problematic for computing gradients, but not because of gradient clipping.

Sorry, I had a typo in the title of the issue. What I wanted to point out is that clipping the critic output and using the result in a loss function might cause gradients to be zero.


Warning: Unexpected input(s) 'includeForks', valid inputs are ['token', 'template', 'readme']

includeForks is not working
I think it's because you did not publish a new release after adding includeForks.
Can you publish 1.2?
Or will I use your master branch instead?

There was a v1.1 release but was not published on the marketplace (I think I forgot to do it).
I just pushed v1.1 on the marketplace.

Thanks


New refactor forced push

r? @vinipsmaker
(maidsafe_highfive has picked a reviewer for you, use r? to override)

r? @ustulation


Officially deprecate support for python 3.8

What

Resolves: https://github.com/rerun-io/rerun/issues/7830

Checklist

[x] I have read and agree to Contributor Guide and the Code of Conduct
[x] I've included a screenshot or gif (if applicable)
[x] I have tested the web demo (if applicable):

Using examples from latest main build: rerun.io/viewer
Using full set of examples from nightly build: rerun.io/viewer

[x] The PR title and labels are set such as to maximize their usefulness for the next release's CHANGELOG
[x] If applicable, add a new check to the release checklist!
[x] If have noted any breaking changes to the log API in CHANGELOG.md and the migration guide

PR Build Summary
Recent benchmark results
Wasm size tracking

To run all checks from main, comment on the PR with @rerun-bot full-check.

Python actually silences deprecation warnings by default in most user-facing contexts, which is a bit annoying and practically reduces the chances it will be seen by the users in practice, but that's the policy and I'm not going to fight it or workaround it.
Regardless, this is the "most right" way to handle it. If you enable deprecation warnings in your project config you'll see it, otherwise it won't be visible.

Also worth noting that when we drop support, the new wheels will list their incompatibility so people installing will just get an older version or a pypi error if they try to install an explicit version in a 3.8 context.


MWPW-157147: Dynamic Nav Status

Adds a status button to appear in the nav to inform content QA and QA whether or not the Dynamic Nav is active and to provide additional information about Dynamic Nav and it's settings.
The experience is set for tablet and up, since the core user is QA.

Context:
The milo repo does not have the dynamicNavKey in the config, so the first two links will not show the feature. The second set of links, I am using the milo branch "dynamic-nav-preview" due to code bus issues, there is parity between both branches.
Resolves: MWPW-157147
Test URLs:

Before: https://main--milo--adobecom.hlx.page/drafts/slavin/dynamic-nav/bacom-sample-on?martech=off
After: https://dynamic-nav-status--milo--adobecom.hlx.page/drafts/slavin/dynamic-nav/bacom-sample-on?martech=off

Bacom

Before: https://main--bacom--adobecom.hlx.page/drafts/slavin/dynamic-nav/aem-rtcdp-entry?martech=off
After: https://main--bacom--adobecom.hlx.page/drafts/slavin/dynamic-nav/aem-rtcdp-entry?milolibs=dynamic-nav-preview&martech=off

Closing due to commits, will open another.


Associated artefacts

It would be useful to pull in various artefacts associated with the PR (change logs, upstream commit logs) and users could review and annotate them.

Agreed, but how would we consistently pull this info?
I know there's meta.changelog, but it's used more as an exception than the rule

I imagine a set of heuristics. For GitHub, GitLab, GNOME.


home-assistant: 2023.12.2 -> 2023.12.3

Description of changes
https://github.com/home-assistant/core/releases/tag/2023.12.3

Things done

Built on platform(s)

[x] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)

[ ] sandbox = relaxed
[ ] sandbox = true

[x] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[ ] Tested basic functionality of all binary files (usually in ./result/bin/)
24.05 Release Notes (or backporting 23.05 and 23.11 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[x] Fits CONTRIBUTING.md.

Add a :+1: reaction to pull requests you find important.

Interesting that all tests are passing as aioesphomeapi 21.0.0 as in master. I guess that there are no unit tests present and the failure can only be detect by actually running the scanner.


Explore rewriting query proxy in golang

Here we are currently writing the query proxy initially in Perl because this matches what we are familiar with and reduces the unknowns in the surface area.  However we should explore rewriting the query proxy in golang to see if a) we get better performance, and b) if this helps with other aspects.

Initial impressions:

Golang object oriented design and development is a complex and complicated topic.  The interplay between interfaces, types, and composition makes the language very difficult to reason about in some of these areas.  Additionally OOP in Golang invariable requires a fair bit of metaprogramming and use of reflection.  This puts a lot more emphasis on the framework side.
The golang postgres driver is extremely capable and it seems likely that there is a space on this project where it will do extremely well, namely moving
golang interfaces are far less powerful than their Java counterparts
Initial impressions are that once you have framework components down, that development and management of business logic pieces should be fast and easy.
Golang doesn't seem very well suited to business-logic-heavy tasks.  I don't see it ever replacing the Perl-based management tooling that we have
Nevertheless, I think Golang would be the strongest choice for the logical replication piece from Postgres to etcd.  This would save us a large amount of problems and I think that it is likely that a generic tool could be written and only a big of custom logic needed to do this.  This should be an exploration topic for 1.0 since the current LW Agent code has problems due to the nature of the etcd driver.

One further note is that of all the Postgres drivers I have evaluated, golang is the only language which has consumers for the pgoutput logical replication plugin.  I am considering trying to write a logical replication piece to replace the lwagent for v1 even in golang though I don't think the language is great for most other parts of this stack (at present, opinion could change).


fix: Tag mesh peers on graft, remove tags on prune

Closes https://github.com/ChainSafe/js-libp2p-gossipsub/issues/380

comment from @dapplion

Hey! I strongly oppose merging the peer tagging feature before having strong guarantees this won't have a performance penalty.

comment from @dapplion

Hey! I strongly oppose merging the peer tagging feature before having strong guarantees this won't have a performance penalty.

Following a suggestion from @achingbrain we could do the tagging / untagging after the sending an rpc object to a peer (e.g. https://github.com/ChainSafe/js-libp2p-gossipsub/blob/master/src/index.ts#L1241) to unblock grafting / pruning operations, this should avoid the performance penalty.
what do you think @dapplion ?

this should avoid the performance penalty

I think it's important to establish a baseline measurement to ensure we have a basis for comparison of different solutions before we make architectural decisions predicated on performance impact.
@dapplion do you have a specific metric in mind that changes here must not affect?  If you do, is there a benchmark that we can use as the baseline measurement?  If not, can one be created?

Codecov Report
Base: 83.41% // Head: 83.38% // Decreases project coverage by -0.03% :warning:

Coverage data is based on head (90b3bf6) compared to base (20d54f4).
Patch coverage: 33.33% of modified lines in pull request are covered.

Additional details and impacted files
@@            Coverage Diff             @@
##           master     #383      +/-   ##
==========================================
- Coverage   83.41%   83.38%   -0.03%
==========================================
  Files          48       48
  Lines       11779    11785       +6
  Branches     1270     1270
==========================================
+ Hits         9825     9827       +2
- Misses       1954     1958       +4

Impacted Files
Coverage Δ

src/index.ts
70.43% <33.33%> (-0.08%)
:arrow_down:

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

:umbrella: View full report at Codecov.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.

As argued in libp2p/js-libp2p#369 (comment) I do not believe this feature is understood enough to be a net positive in js-libp2p. Collapsing a multidimensional score of "peer usefulness" into a single number can lead to unintended consequences. Note that Go and Rust gossipsub implementations do not use tagging.

The go-libp2p-gossipsub implementation uses a tagTracer which applies tags to peer connections based on their behaviour, leveraging the TagPeer methods from the connection manager implementation
Peers are tagged based on the following criteria:

Directly connected peers are tagged with GossipSubConnTagValueDirectPeer (default 1000).
Mesh peers are tagged with a value of GossipSubConnTagValueMeshPeer (default 20).
If a peer is in multiple topic meshes, they'll be tagged for each.
For each message that we receive, we bump a delivery tag for peer that delivered the message first (using the GossipSubConnTagBumpMessageDelivery variable)
The delivery tags have a maximum value, GossipSubConnTagMessageDeliveryCap, and they decay at a rate of GossipSubConnTagDecayAmount / GossipSubConnTagDecayInterval.

So perhaps we need to expand this PR to accommodate those different types of tags and penalties when adjusting a peer-score . What do you think @achingbrain @wemeetagain  ?

What happened to the diff? +14,000 -42,000

What happened to the diff? +14,000 -42,000

This is just for testing purposes which is why the commit is labelled DNM

After deploying this on Feb 7th and observing on our larger cluster I have some observations. In summary
Pros

Improved throughput
More stable peer count
better gossip scores

Cons

Increased heap usage
slightly increased CPU usage

for more details:
The screenshots are in order of unstable (unstable-lg1k-hzax41)  then  feat2 (feat2-lg1k-hzax41) respectively.
Gossip score (avg / min / max)
Unstable

Feat2

We can observe that unstable on average had more low scores that deviated from the average than feat2 although the variance is not significant over the last 6 days.
Peer count per gossip score threshold
Unstable

Feat2

We can observe that on feat2  there is substantially less variance over the last 6 days than unstable (around 9 at max) as opposed to spikes of 50 peers on unstable , the peer count remained relatively stable in feat2
Process CPU user seconds
Unstable

Feat2

Slightly more on average CPU usage with feat2
Process Heap Bytes
Unstable

Feat2

There is consistently higher heap usage with feat2 with an average higher than unstable’s max.
Received messages per second
Unstable

Feat2

On average feat2 is receiving more messages per second over the last 6 days.
Would be interested to hear your thoughts @dapplion @wemeetagain @tuyennhv

Just sending a reminder @dapplion @tuyennhv

Just sending a reminder @dapplion @tuyennhv

What specific input do you need from us?

Just sending a reminder @dapplion @tuyennhv

What specific input do you need from us?

I wanted to know if you thought these fluctuations were significant enough to be warranted as a performance penalty otherwise we could go ahead with this PR.

Update: this is going to be redeployed by @wemeetagain and double checked.

@wemeetagain :
Having some difficulties verifying this in prod. In production, several major versions behind (gossipsub) - can't easily deploy to a pre 0.45 libp2p released Lodestar
After verifying 0.45 works w.o regressions, this can be tested.

@wemeetagain is going to share the metrics that illustrate below performant behaviour, but he would also like to have this functionality configurable in the interim given that connections are managed differently in Lodestar.

Next steps on this, I will make this feature enabled where it will default to on, and Lodestar can have the option of disabling it.

diff is still huge

I have reverted the package-lock.json which should reduce the diff

Tagging / untagging also needs to be done when we're sending GRAFT / PRUNE msgs.

To my understanding is that's what is being done here no?

I refactored slightly to place the tagging function in sendGraft to make it more apparent.

Peers can be grafted on one topic and pruned on another topic.
This feature should take that into account.
Right now, if a peer is grafted onto topic A and B, but then pruned from topic A, their tag value goes away completely.

Using the topicID as the tag key should solve this, pushed changes in 78a3669

Can you add a test that shows that the peer store is properly cleared of tags when gossipsub is shut down?

Updated @wemeetagain mind you the value is set to 0 not that is removed as referenced in https://github.com/ChainSafe/js-libp2p-gossipsub/issues/380#issue-1479795857

Updated @wemeetagain mind you the value is set to 0 not that is removed as referenced in https://github.com/ChainSafe/js-libp2p-gossipsub/issues/380#issue-1479795857

I don't see the reference to the tag being set to 0 in that comment

My bad, I had misinterpreted the comment that says tag values should be between 0-100 to imply that for all cases, I realize in libp2p when untagging we set the metadata to undefined I have done so in c117cf9

@wemeetagain the test that actually checks for the tagging is flakey but I am not sure why, could it be that the peerStore is being cleared somewhere else?

I've also updated package-lock.json as npm was reporting critical vulnerabilities.

libp2p triage update -

Error handling to be improved
Then review
Then merge!

@achingbrain can you review this? I'm happy with it.


how can i destroy one item and all nested item should destroy to

Hi @amine8ghandi8amine
Nested delete is not supported. This package only formatting nested in few types.

thank you man for reply


implement i2c_reset on lockup condition

Fix for https://github.com/microsoft/jacdac/issues/345

requires:
https://github.com/microsoft/jacdac-stm32x0/pull/21
https://github.com/microsoft/jacdac-c/pull/21

does the reset help? did you get a logic trace for the lockup? maybe we're doing something wrong?

Will get a trace of the issue. I was under time constraints as I need to get things working reliably for EMC testing this week.

Stale -- lock up was caused by reading sensor too frequently.


Rename request.raw_post_data to request.body

Renames HttpRequest.raw_post_data to HttpRequest.body
Provides a Backwards Compatability Shim
Starts the Deprecation Process for HttpRequest.raw_post_data

This was committed in https://code.djangoproject.com/changeset/17210, closing. Thanks @dstufft!


ES6 arrow functions.

Camel case variables
Template literals

@DaftLimmy Updated with the fresh batch on code from your master branch

Ta!


Prepare renaming of main branch from master to main

Rename master to main
Add rust-toolchain file for (more) reproducible builds with a pinned Rust version
Remove toolchain from GH Actions so value from rust-toolchain is used instead
Remove GH Actions matrixes for toolchain version as unused and to enable picking up from rust-toolchain as well

@pimeys I'll try taking care of updating the versions myself, if that doesn't work out let's pin to stable in the rust-toolchain file.


Use a stable header row

This should free us up to rename fields in the form and localize the sucker.

Did you mean to include the CSS change in this PR?

It's just a whitespace fix, but I'll break it out. one sec.

PTAL

thank you!


package.json defaults

I think we should provide some defaults to avoid npm warnings:

description - An awesome donejs app
license - the "no license" license
repository - not sure what to put here .... it would be nice to infer it ... but probably not possible unless there's a .git somewhere.

NPM warnings are muted now because we use loglevel error, so this is probably not needed if it's about warnings.

This is only during init right?  Probably don't want it any other time.

Issue moved to donejs/generator-donejs #199 via ZenHub


Npm audit

Fixes 1079 vulnerabilities
This should fix several of the open greenkeeper pull requests, and make it much easier to handle dependency audits in the future.

Un-pin dependencies (allowing patch updates)
Run npm audit fix to automatically fix vulnerabilities

Some additional dev dependencies need manual review: jest, babel-cli, commitizen
Upgrading jest will be quite a bit of work as newer versions use babel 7, and you have some dependencies on deprecated babel plugins.
I would also recommend adding an .nvmrc file with a supported version of node for dev. 🙂

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

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket: