text:
Mac: Failed at the electron@1.6.8 postinstall script 'node install.js'.

Received the following message:
Failed at the electron@1.6.8 postinstall script 'node install.js'. (Exit Status 1)
node.js (and I assume npm with it) were just downloaded and installed from their site.

Electron version: electron@1.6.8
Operating system: macOS Sierra 10.12.4

I'm brand new to working with these types of files and installers, so I'm not sure how to correct this.
Also, I need to know if I can do this as a global install, as I would not like to confront the prospect of installing this in every single project folder.

In my case, npm install electron -g will do the trick.

I am seeing the same error.  Is there a work around for this issue?

I got around this issue by looking at the link "https://docs.npmjs.com/getting-started/installing-npm-packages-locally".  I tried a bunch of things and not sure exactly what fixed it but I did run "npm init" with defaults and then the "npm install mapbox-map-image-export -g" command seemed to work

I've got the same error.
electron@1.6.11 postinstall: node install.js. Exit status 1

Node.js version: v8.1.4
Electron version: v1.6.11
OS: Ubuntu 16.04

@ryan-christopher I updated my node to last version and the error fixed.

The electron-prebuilt repo is being retired and its code has been moved into the electron/electron repo. For the sake of historical transparency, we will leave GitHub Issues enabled on this repository, but if you are still affected by the issue reported here, please open a new issue on electron/electron repo and reference this issue from it so people can get the full context. The electron repository has a large and active contributor community, so your issue is more likely to get the attention it deserves there. Thanks!

authors: aliir74 firsttracks ryan-christopher shakhassan zeke

repo: electron-userland/electron-prebuilt


text:
当使用React时，build会导致找不到文件

问题概况
使用环境：MacOS m2 air (arm64架构，使用electron-builder作为打包工具)
打包命令："build:mac": "tsc && vite build && electron-builder"
使用版本:
{
    "electron-builder": "^24.6.3",
    "vite-plugin-electron": "^0.28.2",
    "vite-plugin-electron-renderer": "^0.14.5"
}
问题：打包后程序白屏，并且提示```Not allowed to load local resource: file:///Users/<myUserName>/code/<projectName>/dist/mac-arm64/<projectName>.app/Contents/Resources/app.asar/dist/index.html```

尝试过的解决方法
尝试过使用--config里写入asar: false，但是signing时报错
Command failed: codesign --sign 71F68ECE58812EEDF39B778BFE80088167174542 --force --timestamp --options runtime --entitlements并且还有Permission denied的提示
个人理解
按照普遍理想而说应该是直接找app.asar就完事了（吧？），实际解包后发现也确实只有一个asar的压缩文件，也压根不是一个目录啊
本项目较为私密，不可以提供开源仓库，请谅解

运行tsc && vite build看一下是否生成了dist文件夹

有生成

那应该是electron-builder配置文件里files字段没加dist，不然肯定会打包进去的

我添加了dist了
{
    "asar": true,
    "appId": "com.rntimer.app",
    "files": ["dist-electron", "dist"],
    "mac": {
        "artifactName": "${productName}_${version}.${ext}",
        "target": ["dmg", "zip"]
    },
    "win": {
        "target": [
            {
                "target": "nsis",
                "arch": ["x64"]
            }
        ],
        "artifactName": "${productName}_${version}.${ext}"
    },
    "nsis": {
        "oneClick": false,
        "perMachine": false,
        "allowToChangeInstallationDirectory": true,
        "deleteAppDataOnUninstall": false
    },
    "directories": {
        "output": "release/${version}",
        "buildResources": "build"
    }
}

并且我尝试用文本编辑器打开我的app.asar，其中也确实有dist/index.html和其相关的文件

还是提供一下minimal reproduction吧

source: gharchive/issue

repo: electron-vite/vite-plugin-electron

license: MIT

license_type: permissive

license_source: github-api


text:
fix broken link to npmjs package

The previous link led to a 404 page on npmjs. 😄

grazie!

source: gharchive/pull-request

authors: stve zeke

license: mit

license_source: bigquery


text:
"Unidentified developer" when opening universal app

Hello, we switched from an app for x86_64 to an universal app. The app runs fine on all platforms when I sign them locally with my developer identity.
However, when we go through Testflight, we are greeted with a "... cannot be opened because the developer cannot be verified" message. This only happens with the universal build, the x86_64 only one works fine. And if I force-resign the app, then it also works fine.
This is how we sign:
electron-osx-sign --entitlements=./entitlements/entitlements.mac.plist --entitlements-inherit=./entitlements/entitlements.mac.inherit.plist --entitlements-loginhelper=./entitlements/entitlements.mac.inherit.plist --identity=${CERTIFICATE_DEVELOPER_SHA} --keychain=signing-cert-keychain --provisioning-profile=./embedded.provisionprofile --type=distribution "${appName}"       productbuild --component "${appName}" /Applications --sign "${CERTIFICATE_INSTALLER_SHA}" "app-name-${params.UPLOAD_ARTIFACT_VERSION}.pkg"

Checking the app with the usual tools (codesign,pkgutil, spctl) gives no clue to any problems. Only at runtime it doesn't work.
I have run out of ideas to try..

I have exactly the same problem, already spent 5 days trying different things but I've exhausted my options.
Does force resigning the universal app actually work for you and you can run it in Test Flight? I couldn't even manage to do that yet.

I meant that resigning locally with my developer identity makes it runnable for me, but I have not tried uploading the resigned app onto Testflight.
Did you test if the same problem occurs when you attempt an app store release? Speculating if this is a problem with Testflight..

I meant that resigning locally with my developer identity makes it runnable for me, but I have not tried uploading the resigned app onto Testflight.

I see, I also have no problems running the app locally when it is signed with the developer identity and notarized. However for TestFlight and the Mac Store it has to be signed either with 3rd Party Mac Developer Application or Apple Distribution certificate. And when we do this we get the above problem.

Did you test if the same problem occurs when you attempt an app store release? Speculating if this is a problem with Testflight..

Yes, the app gets rejected for the same reason. I created a separate issue with more info since I am using electron-builder (not osx-sign directly) here:
#https://github.com/electron-userland/electron-builder/issues/7171
I've attached a build log there which confirms signing goes well, so the problem has to be elsewhere.

Have you tried regenerating the provisioning profile? Will try that next (unfortunately I don't have direct access to App Store so it's a slow process here).. after all the provisioning profile links the developer with the app..

Have you tried regenerating the provisioning profile?

Yes, no difference. Transporter usually complains if your provisioning profile is not correct, so you will never reach TestFlight deployment if it was wrong. But you are welcome to try it in case I missed something.

just fyi, I had another wild theory.. maybe the universal build is loading different dylibs on startup than the x86 build. That could lead it to not find something. If it doesn't find it, the loader goes to search for it. And while searching it checks some invalid directories, which are forbidden unless some entitlements are given, and therefore the signature is rejected.
So i checked and the only diffrence between a working x86 app (left) and the universal app (right) was this:

I think I found the reason. My app uses native modules and they need to be signed, too. For that reason, they are unpacked, using the asarUnpack config option.
However, unlike with the x86 build, in the universal build I have two copies of the same node module. One in the app.asar.unpacked folder, and one in the app.asar archive itself. And only the "unpacked" one is signed. 😨

Ok I have my solution, if I set mergeASARs to false, I get a correctly signed and launching app. Albeit, it still seems that the native modules are duplicated.
I would close this issue now, or leave it to you @gpronet , as I think my solution won't help you

Amazing, mergeASARs: false fixes the issue for me as well.
A non critical dependency of my app was using just one native module, so when I removed it, the error messages were gone as well even without mergeASARs: false. Thank you for pointing me in the right direction @lukas2.

Wow, happy to hear! 🙂
Actually it clicked for me when you said in the other thread that the "Move to Bin"-deleted files are hidden in Trash. I examined mine and saw my module in unsigned form. Then I knew there had to be more than one..  :)
Ok closing this.

I'm still stuck with this error :-(
Can you guys please post your package.json and entitlement files?

Hello i still have this problem

mergeASARs: false

I've set it up > mergeASARs: false and the eror still show in testflight
i using electron + svelkit
this my electron and builder version:
"electron": "^26.2.2",
"electron-builder": "^24.6.4",

repo: electron/osx-sign


text:
Hotfix/support backfill changes on redshift

support backfill changes for alerts model on redshift

LGTM!

Could you please change to branch to v0.4.2.1?

authors: IDoneShaveIt elongl

repo: elementary-data/elementary


text:
Remove version constraint from the installation docs

If one was to copy and paste the Composer installation command from the README when it has the ~1 version constraint they might be confused as to why they don't get all the functionality shown in the docs. Removing the version constraint will have Composer install the latest tagged version and thus they should get all the current functionality.

Cool!

authors: dwightwatson elfet

repo: elfet/cherimola


text:
🛑 UCU - Koha is down

In 9ab1963, UCU - Koha (http://biblioteca.ucu.edu.ar/) was down:

HTTP code: 0
Response time: 0 ms

Resolved: UCU - Koha is back up in 45007ae.

repo: elfoche/monitoreo


text:
🛑 MCU - GRH is down

In 6d96763, MCU - GRH (http://produccion.cdeluruguay.gob.ar/GRH/forms/login.jsp) was down:

HTTP code: 0
Response time: 0 ms

Resolved: MCU - GRH is back up in 7257ed7.


text:
Problem with searching

Hi!
I have some problems with zamunda.net. For some reason when Elementum successful login to zamunda and i search for some movie, Elementum find results with right search string: http://zamunda.net/bananas?c42=1&c25=1&c35=1&c46=1&c20=1&c19=1&c5=1&c24=1&c31=1&c28=1&search=avengers+endgame+2019&incldead=1&field=name
but after that Elementum create another request with other string: https://zamunda.net:443/login.php?returnto=%2Fbananas%3Fc42%3D1%26c25%3D1%26c35%3D1%26c46%3D1%26c20%3D1%26c19%3D1%26c5%3D1%26c24%3D1%26c31%3D1%26c28%3D1%26search%3Davengers%2Bendgame%2B2019%26incldead%3D1%26field%3Dname
and this string loged me out from Zamunda and finaly Elementum cannot display any results.
Can you help with this?
If you need user and pass for Zamunda, tell me where to send them.
Thank you in advance!

I fix the problem.


text:
400 Login failed on [toloka] provider

When try to execute any search on toloka provider it returns no links.
From log debug I can see errors of 400 bad requests and information that Request Header or Cookie Too Large.
Not sure is it something about client, configuration or the provider itself.
I've verified that the login/password are correct.
I've also get try to lgin from postman using this form-data from config
"{'username': USERNAME, 'password': PASSWORD, 'autologin': '1', 'login': 'Enter'}"

and it seems to be working, at least it returns me redirect instead of bad request.
Here is the part of log debug:
2024-09-22 12:49:48.502 T:4449    debug <general>: [script.elementum.burst] Searching with payload (general): {'proxy_url': '', 'internal_proxy_url': 'http://10.10.10.108:65222', 'elementum_url': 'http://10.10.10.108:65220', 'silent': False, 'skip_auth': False, 'query': 'FOO'}
2024-09-22 12:49:48.505 T:4449  warning <general>: [script.elementum.burst] Burstin' with Гуртом
2024-09-22 12:49:48.506 T:4449  warning <general>: [script.elementum.burst] No 'en' translation available...
2024-09-22 12:49:48.511 T:3816    debug <general>: ------ Window Init (DialogExtendedProgressBar.xml) ------
2024-09-22 12:49:48.512 T:4449    debug <general>: [script.elementum.burst] Translated titles from Elementum: {'source': 'FOO', 'original': 'FOO'}
2024-09-22 12:49:48.513 T:4468    debug <general>: [script.elementum.burst] [toloka] Processing toloka with general method
2024-09-22 12:49:48.514 T:4468    debug <CSettingsManager>: requested setting (filter_music) was not found.
2024-09-22 12:49:48.515 T:4468    debug <general>: [script.elementum.burst] [toloka] General URL: https://toloka.to/tracker.php?nm=QUERYEXTRA&o=10
2024-09-22 12:49:48.517 T:4468    debug <general>: [script.elementum.burst] [toloka] execute_process for toloka with <function extract_torrents at 0x7e114938>
2024-09-22 12:49:48.518 T:4449    debug <general>: [script.elementum.burst] Timer: 0s / 27s
2024-09-22 12:49:48.527 T:4468    debug <CAddonSettings[0@plugin.video.elementum]>: trying to load setting definitions from old format...
2024-09-22 12:49:48.549 T:4468    debug <general>: [script.elementum.burst] [toloka] Queries: ['{title}']
2024-09-22 12:49:48.550 T:4468    debug <general>: [script.elementum.burst] [toloka] Extras:  ['']
2024-09-22 12:49:48.551 T:4468    debug <general>: [script.elementum.burst] [toloka] Before keywords - Query: '{title}' - Extra: ''
2024-09-22 12:49:48.552 T:4468  warning <general>: [script.elementum.burst] [toloka] Falling back to original title in absence of None language title
2024-09-22 12:49:48.557 T:4468  warning <general>: [script.elementum.burst] [toloka] Using translated 'original' title 'FOO'
2024-09-22 12:49:48.559 T:4468    debug <general>: [script.elementum.burst] [toloka] After keywords  - Query: '%D1%80%D0%B0%D1%82%D0%B0%D1%82%D1%83%D0%B9' - Extra: ''
2024-09-22 12:49:48.560 T:4468    debug <general>: [script.elementum.burst] -   toloka query: '%D1%80%D0%B0%D1%82%D0%B0%D1%82%D1%83%D0%B9'
2024-09-22 12:49:48.561 T:4468    debug <general>: [script.elementum.burst] --  toloka url_search before token: 'https://toloka.to/tracker.php?nm=FOO&o=10'
2024-09-22 12:49:48.561 T:4468    debug <general>: [script.elementum.burst] --- toloka using POST payload: {}
2024-09-22 12:49:48.562 T:4468    debug <general>: [script.elementum.burst] ----toloka filtering with post_data: {}
2024-09-22 12:49:48.562 T:4468    debug <CSettingsManager>: requested setting (toloka_passkey) was not found.
2024-09-22 12:49:48.577 T:4468    debug <general>: [script.elementum.burst] Opening URL: b'https://toloka.to/login.php'
2024-09-22 12:49:48.770 T:4449    debug <general>: [script.elementum.burst] Timer: 0s / 27s
2024-09-22 12:49:49.029 T:4468     info <general>: Skipped 1 duplicate messages..
2024-09-22 12:49:49.029 T:4468    debug <general>: [script.elementum.burst] Status for b'https://toloka.to/login.php' : 400
2024-09-22 12:49:49.031 T:4468  critical <general>: [script.elementum.burst] [toloka] Login failed: 400
2024-09-22 12:49:49.034 T:4468    debug <general>: [script.elementum.burst] [toloka] Failed login content: '\r\n<title>400 Request Header Or Cookie Too Large</title>\r\n\r\n
400 Bad Request
\r\nRequest Header Or Cookie Too Large\r\n
nginx\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n'
2024-09-22 12:49:49.047 T:4468  warning <general>: [script.elementum.burst] [toloka] >>              Гуртом returned  0 results in 0.5 seconds

System: Android TV
Kodi version: 21.1
Elementum version: 0.1.103
Elementum burst version: 0.0.89
Any suggestions will be appreciate.

@olegmiercoles

Maybe it is because of long cookie.
There is a file with cookies in .kodi/temp/burst/common_cookies.jar (see https://kodi.wiki/view/Kodi_data_folder for location of .kodi in your OS)
It is a plain text file, you can open it and search for toloka and see if cookie is "bad" (maybe it has some garbage and it is indeed too long).
Anyway - remove the line for toloka and try again. also, you can backup that file and remove the file completely.

Also, in burst settings in "maintenance" tab you can remove all cookies - in case if you unable to get access to file system of your device.

There is no "login_headers": field for toloka so it should not be "Request Header" issue.
https://github.com/elgatito/script.elementum.burst/blob/97dcfb60aa43fa646712c6ec60fb9fc7ee80ecc0/burst/providers/providers.json#L2381

Thank you, @antonsoroko
I did as you suggested: I've renamed common_cookies.jar to common_cookies_bkp.jar and it helped.
Probably I will keep backup-file for some time, but later will remove it.
Thank you again for assistance!

@olegmiercoles I am just curious - have you tried to take a look into that file? Interesting how a line for toloka looks like. Probably it has some garbage for some reason. If you remove toloka_sid from that line - you can share it here (so it will not have your login cookie).
Up to you of course.

Sure. I did my the best to cleanup all the hashes and IDs. Hope, I didn't miss anything :)
First line for toloka_data was pretty huge combo of hash+autologinid+hash+userid+hash
And toloka_302_u also contained around 8.000 characters hash inside.
#LWP-Cookies-2.0
Set-Cookie3: toloka_data="something-was-here-like-b%432%3b%9Bs%3d%autologinid%here-as-well-something-likeb%432%3b%9Bs%3d%userid-and-here-the-same"; path="/"; domain="toloka.to"; path_spec; secure; expires="2025-05-29 18:56:57Z"; httponly=None; version=0
Set-Cookie3: toloka_302_tt=there-was-some-numbers; path="/"; domain="toloka.to"; path_spec; secure; expires="2025-05-29 18:56:57Z"; version=0
Set-Cookie3: toloka_302_f="there-was-something-like-in-the-first-line-a%54b%33%"; path="/"; domain="toloka.to"; path_spec; secure; expires="2025-05-29 18:56:57Z"; version=0
Set-Cookie3: toloka_302_uf=there-was-some-numbers; path="/"; domain="toloka.to"; path_spec; secure; expires="2025-05-29 18:56:57Z"; version=0
Set-Cookie3: toloka_302_u="about-8.000-characters-was-here"; path="/"; domain="toloka.to"; path_spec; secure; expires="2025-05-29 18:56:57Z"; version=0
Set-Cookie3: toloka___tt=there-was-some-numbers; path="/"; domain="toloka.to"; path_spec; secure; expires="2025-03-04 19:58:37Z"; version=0
Set-Cookie3: toloka___f="there-was-something-like-in-the-first-line-a%54b%33%"; path="/"; domain="toloka.to"; path_spec; secure; expires="2025-03-04 19:58:37Z"; version=0
Set-Cookie3: toloka___uf=0; path="/"; domain="toloka.to"; path_spec; secure; expires="2025-03-04 19:58:37Z"; version=0
Set-Cookie3: toloka___u="there-was-something-like-in-the-first-line-a%54b%33%"; path="/"; domain="toloka.to"; path_spec; secure; expires="2025-03-04 19:58:37Z"; version=0

@olegmiercoles thanks!
so looks like by default many popular HTTP servers have total limit for HTTP Header (and cookie is a part of header) as 8KB.
so looks like in total your cookies were >8KB, thus i think we found the root cause.
somehow toloka website generated such long cookie.
i guess we could create a "blacklist" for cookies (e.g. ignore and do not save some cookies), although i am not sure if we really need it, since i see such issue for the first time. maybe @elgatito can add more ideas.
but anyway, thanks for info.
if there will be more issues like this then we can circle back to this.

@antonsoroko Quick googling says there is nothing "ready" in Python's requests to control size of a request to avoid such errors.
I also have problems with Toloka, even with sync, it does something (I was not debugging those), that invalidates a session everywhere, not only on Elementum/Burst side.
Not sure if we should/can do something with it.

authors: antonsoroko elgatito olegmiercoles


text:
Missing HTTP CONNECT method

Pretty straight forward, can't seem to do an HTTP CONNECT request.
For example:
$ http-prompt http://example.com
Version: 0.11.2
http://example.com> httpie connect
http http://example.com/connect

should actually be
http-prompt http://example.com
Version: 0.11.2
http://example.com> httpie connect
http CONNECT http://example.com

Addressed in #145, shipped in v1.0.0.

authors: eliangcs wheelerlaw

repo: eliangcs/http-prompt


text:
archetype generation command fails

I copied the command from your Wiki to start a project from the Maven archetype:
mvn archetype:generate -DarchetypeGroupId=org.jogger -DarchetypeArtifactId=jogger-archetype -DarchetypeVersion=0.9.0 -DarchetypeRepository=http://repository.elibom.net/nexus/content/repositories/releases/

This was the output:
mvn archetype:generate -DarchetypeGroupId=org.jogger -DarchetypeArtifactId=jogger-archetype -DarchetypeVersion=0.9.0 -DarchetypeRepository=http://repository.elibom.net/nexus/content/repositories/releases/
[INFO] Scanning for projects...
[INFO]
[INFO] ------------------------------------------------------------------------
[INFO] Building Maven Stub Project (No POM) 1
[INFO] ------------------------------------------------------------------------
[INFO]
[INFO] >>> maven-archetype-plugin:2.4:generate (default-cli) > generate-sources
@ standalone-pom >>>
[INFO]
[INFO] <<< maven-archetype-plugin:2.4:generate (default-cli) < generate-sources
@ standalone-pom <<<
[INFO]
[INFO] --- maven-archetype-plugin:2.4:generate (default-cli) @ standalone-pom --
-
[INFO] Generating project in Interactive mode
[INFO] Archetype defined by properties
Downloading: http://repository.elibom.net/nexus/content/repositories/releases/or
g/jogger/jogger-archetype/0.9.0/jogger-archetype-0.9.0.jar
[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 1.974 s
[INFO] Finished at: 2016-03-18T10:25:32+09:00
[INFO] Final Memory: 15M/245M
[INFO] ------------------------------------------------------------------------
[ERROR] Failed to execute goal org.apache.maven.plugins:maven-archetype-plugin:2
.4:generate (default-cli) on project standalone-pom: The desired archetype does
not exist (org.jogger:jogger-archetype:0.9.0) -> [Help 1]
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e swit
ch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions, please rea
d the following articles:
[ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/MojoFailureExc
eption

Hi @garfieldnate ,
I think this project is pretty much dead. In case you are looking for alternatives I suggest you take a look at either Spark or Pippo. Jooby might also be worth a try eventhough I have no experience with it.

That's too bad, this was very quick to set up. It's just that the author's repo site is down. Maybe they could be moved to Maven Central if they could be found. I'll leave this issue here for future reference.

authors: garfieldnate wowselim

repo: elibom/jogger


text:
Preprint history event data parse, update fixture.

Added new parsing functions to gather preprint version event history data.
The existing test fixture 2022.10.17.512253.docmap.json is updated to reflect the latest docmap data available for it.

Re issue https://github.com/elifesciences/issues/issues/7721

repo: elifesciences/docmap-tools


text:
MSID: 99785 Version: 1 DOI: 10.1101/2024.07.15.603526

MSID: 99785
Version: 1
Preprint DOI: https://doi.org/10.1101/2024.07.15.603526
Step 1. Awaiting reviews
Editorial to post reviews via hypothesis
Useful links:

DocMap: https://data-hub-api.elifesciences.org/enhanced-preprints/docmaps/v2/by-publisher/elife/get-by-manuscript-id?manuscript_id=99785
New model tracking: https://docs.google.com/spreadsheets/d/1_fHaoOy7hjyocptKtVJRijeNpUY4hBS7Ck_aVmx6ZJk/
Reviews on sciety: https://sciety.org/articles/activity/10.1101/2024.07.15.603526

For trouble shooting (e.g. no Docmaps available):

DocMap issue addressing: https://miro.com/app/board/uXjVNCwK6EI=/
Explore DataHub DocMaps API: https://lookerstudio.google.com/reporting/4c2f0368-babb-4beb-b5b3-497e7e7b0f08/page/ejphD
Unmatched submissions and preprints: https://lookerstudio.google.com/u/0/reporting/9f86204f-3bf7-477c-9b18-5c5ef141bf69/page/p_gxi57ha93c
Unmatched manuscripts spreadsheet: https://docs.google.com/spreadsheets/d/15QcK8w-ssB7109RQEDtFpJPZ0J5HTGxoHa_2TtpMBbg/edit#gid=1336081641

Step 2. Preview reviewed preprint
Production QC content ahead of publication
Instructions:

QC preview: https://prod--epp.elifesciences.org/previews/99785v1
Update ticket with any problems (add blocked label)
When QC OK, add QC OK label to ticket and add publication date and time to https://docs.google.com/spreadsheets/d/1amAlKvdLcaDp5W8Z8g77NmkwbMF5n_u89ArSqPMO8jg
Move card to next column
(At end of the day post link in #enhanced-preprint and ask for PDF to be generated)

Useful links:

Preprint DOI :  https://doi.org/10.1101/2024.07.15.603526
Confirm reviews returned by EPP: https://prod--epp.elifesciences.org/api/reviewed-preprints/99785/v1/reviews
To update the MECA path in the docmap: https://docs.google.com/spreadsheets/d/1mctCQuNFBjSn97Lihy7_vBO6z7-N-oqyLv4clyi6zHg

Step 3: Awaiting search reindex
This step adds the reviewed preprint to the homepage: https://elifesciences.org
The search reindex is triggered once an hour. We need the reviewed preprint to be indexed as the search application serves the journal homepage.
Useful links:

Jenkins pipeline to reindex search can be triggered sooner or monitored here: https://alfred.elifesciences.org/job/process/job/process-reindex-reviewed-preprints/

Step 4: Published! PDF requested
Waiting for PDF to be generated
Useful links:

PDF tracking: https://docs.google.com/spreadsheets/d/106_XeDjmuBae7gexOTNzg60lapeqjl2aRn9DzupGyS8/

Step 5: Introduce PDF to data folder and git repo
Upload PDF to relevent folder in git repo https://github.com/elifesciences/enhanced-preprints-data/
Step 6: Done!

[ ] Kettle is on!

Hi @acollings / @FionaBryant, please could you take a look, and if necessary tweak the assessment for this one?

The authors solidly connect proteostasis ...

Thanks @fred-atherden this has been fixed

Many thanks!

WOS query sent

Confirmed Ok to proceed RE WOS.
Waiting for https://sciety.org/evaluations/hypothesis:nlvGcJarEe-W4aOBdYgobQ/content to update

authors: acollings fred-atherden


text:
🛑 Radarr is down

In 503e26a, Radarr (https://radarr.elightcap.com) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Radarr is back up in baa21c0.

repo: elightcap/statuspage


text:
demjeson install cannot be done since setuptools upgrade, so neither justpy can.

Today on a new deploy I did :
pip3 install justpy

but ends up failing because:
ERROR: Cannot install justpy==0.0.5, justpy==0.0.6, justpy==0.0.7, justpy==0.0.8, justpy==0.0.9, justpy==0.1.0, justpy==0.1.1, justpy==0.1.2, justpy==0.1.3, justpy==0.1.4 and justpy==0.1.5 because these package versions have conflicting dependencies.

The conflict is caused by:
    justpy 0.1.5 depends on demjson>=2.2.4
    justpy 0.1.4 depends on demjson>=2.2.4
    justpy 0.1.3 depends on demjson>=2.2.4
    justpy 0.1.2 depends on demjson>=2.2.4
    justpy 0.1.1 depends on demjson>=2.2.4
    justpy 0.1.0 depends on demjson>=2.2.4
    justpy 0.0.9 depends on demjson>=2.2.4
    justpy 0.0.8 depends on demjson>=2.2.4
    justpy 0.0.7 depends on demjson>=2.2.4
    justpy 0.0.6 depends on demjson>=2.2.4
    justpy 0.0.5 depends on demjson>=2.2.4

To fix this you could try to:
1. loosen the range of package versions you've specified
2. remove package versions to allow pip attempt to solve the dependency conflict

it is an open issue at demjson repo:
https://github.com/dmeranda/demjson/issues/40
Downgrading to setuptools 57.5.0 it des not work, it installs but while doing:
import justpy

gives:
import justpy
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/data/giodegas/dev/AQ2009/myenv/lib/python3.8/site-packages/justpy/__init__.py", line 1, in <module>
    from .justpy import *
  File "/data/giodegas/dev/AQ2009/myenv/lib/python3.8/site-packages/justpy/justpy.py", line 13, in <module>
    from .chartcomponents import *
  File "/data/giodegas/dev/AQ2009/myenv/lib/python3.8/site-packages/justpy/chartcomponents.py", line 2, in <module>
    import demjson
  File "/data/giodegas/dev/AQ2009/temp/demjson/demjson.py", line 645
    class json_int( (1L).__class__ ):    # Have to specify base this way to satisfy 2to3
                      ^
SyntaxError: invalid syntax

@elimintz what can I do now?
Thank you for your support.

Thanks for alerting me to this. I'll try to figure something out. In the meantime, it seems that if you downgrade to anything less than python 3.10 and setuptools to 57.5.0 it should work. Let me know if it doesn't

I am using python 3.8.10 now, setuptools 57.5.0 with a virtual env, still with the import problem.
I may try downgrading setuptools more.

Ok, please let me know how it goes

ok found setuptools 56.0.0 is OK!
this is now my pipi listi in the virtual environment:
pip list
Package            Version
------------------ ---------
addict             2.4.0
aiofiles           0.7.0
anyio              3.3.0
asgiref            3.4.1
certifi            2021.5.30
charset-normalizer 2.0.4
click              8.0.1
demjson            2.2.4
h11                0.12.0
httpcore           0.13.6
httpx              0.19.0
idna               3.2
itsdangerous       2.0.1
Jinja2             3.0.1
justpy             0.1.5
MarkupSafe         2.0.1
pip                21.2.4
pkg_resources      0.0.0
rfc3986            1.5.0
setuptools         56.0.0
sniffio            1.2.0
starlette          0.16.0
uvicorn            0.15.0
websockets         9.1

Thanks for finding a workaround.
I am now in the process of publishing a new version without using setuptools (using flit). Perhaps this will solve the issue.

btw, using docker and latest python3:8 image I found this better setuptools 57.4.0:
pip list
Package            Version
------------------ ---------
addict             2.4.0
aiofiles           0.7.0
anyio              3.3.0
asgiref            3.4.1
certifi            2021.5.30
charset-normalizer 2.0.4
click              8.0.1
demjson            2.2.4
h11                0.12.0
httpcore           0.13.6
httpx              0.19.0
idna               3.2
itsdangerous       2.0.1
Jinja2             3.0.1
justpy             0.1.5
MarkupSafe         2.0.1
pip                21.2.4
rfc3986            1.5.0
setuptools         57.4.0
sniffio            1.2.0
starlette          0.16.0
uvicorn            0.15.0
websockets         9.1
wheel              0.37.0

You might want to switch to demjson3 in case you really only want to support Python 3 anymore.

Thank you for the suggestion. I will make the change.

I have the same problem but am unable to downgrade to Python <3.8.8 because I'm on a Mac with an M1 chip.

Hi,
Is there any solution yet for this problem? JustPy isn't just getting installed!
Please see if you can port things to demjson3.
Thanks,
Sam

I need to find time to release a new version with this. There is a demjson compatible package called demjson3 that solves this issue. If you want to fix it locally, change all import demjson lines to import demjson3 as demjson
And you need to install demjson3.
The advantage of using demjson is that it can parse correctly javascript objects where the keys do not need to be between quotes.

same problem here on python 3.6.9
downgrading setuptools to 56.0.0 as giodegas stated worked for me.

@elimintz Replacing demjson with demjson3 indeed fixes the issue for me. Also see PR.

Version 0.2.3 is out that should this problem.  Replaced demjson with demjson3.
Would appreciate confirmation that this indeed is the case. Did not have time for too much testing but the changes were very limited. The changes are not reflected in the code on github yet but all I did was replace import demjson with import demjson3 as demjson in 4 places.
@poke1024 @1081 @nielstron @giodegas @Ledjob @docsteveharris @Flova

Some preliminary test show it is ok now. Thank you.

It works fine for me too

duplicate of #408

authors: Flova Ledjob WolfgangFahl docsteveharris elimintz giodegas nielstron poke1024 samiit

repo: elimintz/justpy


text:
New Worlds

Hello, I've been trying to get Star Trek New Worlds to run, with
DDrawCompat= 1
DSoundCtrl= 1
I do get into the game, however after a few seconds it just freezes.
I'm using compatibility mode for windows 7, 16 bit color mode, disabled optimizations for full screen.
I've added the logfile I got from Process Monitor:
Logfile.zip
I got the feeling I'm missing something really small, since it does start and you can move around for a few seconds.
(Edited with new logfile, previous didn't properly include the whole game session)

dxwrapper-stnw.log
Here's the wrapper log when the issue occurs

It looks like the game is crashing.  Try setting DSoundCtrl = 0.  Also try adding this line into the ini file: HandleExceptions = 0.  This will allow you to see the crash.
If that does not work, try using the attached updated files.  This works with Star Trek Armada 1 and Star Trek Armada 2.
ddraw.zip

The 2 settings seemed to have worked (at least it doesn't crash in 10 seconds), I did not use the Armada files. The game needed to be launched from a FAT32 usb stick or partition to work properly. I didn't have time to test the game properly but thus far it seems ok!

Closing this since the issue seems to be resolved.  If the issue comes back you can reopen.

authors: LAguido elishacloud

repo: elishacloud/dxwrapper

license: Zlib


text:
feat(wes): add service-info

Description
This PR creates a service info component for WES.

closing this will create a PR for the same, as there have been changes in design package.

repo: elixir-cloud-aai/cloud-components


text:
Fix type definition

+ @type parsec_success :: {:ok, tokens, String.t(), context(), integer(), integer()}
- @type parsec_success :: {:ok, tokens, String.t(), context(), {integer(), integer()}, integer()}

as consumed by e.g. makeup_elixir or makeup_erlang.
I take this time to also introduce dialyxir to CI, which surfaces another issue (opaqueness-related) already mentioned next to stream_data.
Actions missing from this:

waiting for a stream_data update and subsequent import here
(potentially) updating nimble_parsec (as per acceptance of this pull request) [optional]

Edit: while reading the CONTRIBUTING guide I didn't quite understand how to handle the RELEASE.md part (is this required?). Regarding the CHANGELOG.md, do you prefer I do it? Or do you, prior to release?

A PR to fix the specs is welcome but we don't plan to introduce dialyzer at the moment, thank you :)

Sure. I can remove that bit. Thanks.

@josevalim, shall I wait for a nimble_parsec release to update this? Or are you good without it? Thanks.

:green_heart: :blue_heart: :purple_heart: :yellow_heart: :heart:

The goal of this update is to fix a Dialyzer -related issue with makeup_erlang and makeup_elixir (for which now I'm thinking you don't want dialyxir introduced 😄). Do you think it would make sense to tag-release it, to prevent consumers from finding a dialyxir issue.

authors: josevalim paulo-ferraz-oliveira

repo: elixir-makeup/makeup


text:
Fix catching the object by value.

Fixes #4

Fixed the CPPCheck issue, but this line that was changed is not covered by tests.
Going to create a test for this to get the patch coverage up.

That last commit is for the release build. I should have put it in the preprocessor def as an else though since iostream is already included in the debug build.
Fixy fix.

Fixed a bug where capturing multiple streams in the same test resulted in an Access Violation on Windows cl in Debug.
PR now has sufficient patch coverage for merge.

repo: eljonny/TestCPP

license: Unlicense


text:
Cannot understand how any function that requires the Model can be used

For example when I have an instance of the DatePicker type as returned by init, how can I then call getDate in order to obtain the Maybe Date value? getDate requires a Model which is not what I have.
Without being able to understand how to call getDate, setDate or setFilter I really can't work out how to synchronise two date pickers into a range.
Would really appreciate some help (if I am missing something) or some clarification if a fix of some kind is required.
Happy to help if I can by the way.

I'm glad you noticed that too! It occurred to me recently that those functions wouldn't do anyone any good. You're not missing anything; I think a (hopefully fairly simple) fix is in order to convert them to DatePicker -> instead of Model ->. I'll certainly get to it soon if no one else does.

Hey, if you're happy with that change to the interface, I'm happy to have a go at making that change myself and send you a PR. I'm keen to get involved because I think there are a number of enhancements that we would like to make in the future (keyboard control, multi-month views, internationalisation etc) so it would be good to get familiar with things.

authors: bbqbaron julianjelfs

repo: elm-community/elm-datepicker


text:
The type Additive have incorrect variants.

The type Additive have the variants AdditiveNone | AdditiveReplace, but should have AdditiveReplace | AdditiveSum (with correction to the corresponding function in TypesToStrings.elm).
Source: https://developer.mozilla.org/en-US/docs/Web/SVG/Attribute/additive
Comes up when combining transform animations in this way:
<rect x="10" y="10" width="40" height="20"
      style="stroke: #000000; fill: none;">
    <animateTransform attributeName="transform" attributeType="XML"
                      type="scale"
                      from="1" to="3"
                      begin="0s" dur="10s"
                      repeatCount="indefinite"
                      additive="sum"
            />
    <animateTransform attributeName="transform" attributeType="XML"
                      type="rotate"
                      from="0 30 20" to="360 30 20"
                      begin="0s" dur="10s"
                      fill="freeze"
                      repeatCount="indefinite"
                      additive="sum"
            />

(http://tutorials.jenkov.com/svg/svg-animation.html)

I think I can fix this.

repo: elm-community/typed-svg


text:
Compiler freezes when annotating a weird self-referential type

Trying to compile the following code causes the compiler (elm 0.18.0 on Archlinux) to freeze. If I remove the type annotation from idF it will produce an error message about a weird self-referential type, but with the annotation it just gets stuck.
module Test exposing (..)

type alias Focus b s =
    { get : b -> s
    , update : (s -> s) -> b -> b
    }

create : (b -> s) -> ((s -> s) -> b -> b) -> Focus b s
create get update =
    { get = get
    , update = update
    }

idF : Focus { r | id : a } a
idF =
    create .id (\f s -> { s | id = f })  -- should be { s | id = f s.id }

Development build captures it:

It is not pointing out the infiniteness in an ideal way, but it does not hang at least.

authors: evancz nonpop

repo: elm-lang/elm-compiler


text:
Fix typo in If Expressions section

Hope this will make it less confusing for people who follow in the future

Nice, thanks!

authors: HarleyKwyn evancz


text:
Failed parsing Firefox header

I tried to parse my browsers header and ran into the invalid media type error indicating that the header is syntactically invalid.
Does that mean that Firefox does not implement the header format correctly or is it an error in this project?
I added a test case for the header (text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,*/*;q=0.8).
Result:
=== RUN   TestGetMediaType/Firefox_header
    contenttype_test.go:221: Unexpected error "invalid media type" for text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,*/*;q=0.8
--- FAIL: TestGetMediaType (0.00s)

Ah nvm, I did not realize there is GetAcceptableMediaTypeFromHeader.

repo: elnormous/contenttype


text:
Sign In With Solana with Solana Mobile Stack

Solana Mobile Team is implementing the SIWS (Sign In With Solana) API on Mobile Wallet Adapter. (Probably on v2.0)
https://github.com/solana-mobile/mobile-wallet-adapter/issues/439
After that, we can use SIWS on both of Web Apps and Solana dApps on the Saga phone.
For now, SIWS is available with Next.js WebApp with Skeet.
Check /webapp folder for that.
https://github.com/elsoul/skeet-solana-mobile-stack/tree/main/webapp
Wallet Adapter for Web is here
https://github.com/elsoul/skeet-solana-mobile-stack/blob/main/webapp/src/components/providers/SolanaWalletProvider.tsx

Mobile Wallet Adapter specification
Version: 2.0.0-DRAFT
https://solana-mobile.github.io/mobile-wallet-adapter/spec/spec.html

It's done already

repo: elsoul/skeet-solana-mobile-stack


text:
edit: Fix crash in history listing mode

When you had too few history entries to display in the terminal,
entering history listing mode attempted to access a negative index and
crashed.

I've wanted to make two additional edits but was unsure about their possible side-effects on other parts.
The first was not entering history listing mode if there was no history. Off I went to startHistoryListing, but got stuck a bit in the semantics. What happens if newHistoryListing returns an error (which makes sense in our situation)? Would the user still be in history listing mode? Perhaps it'll be best then to move the mode switch below the check.
The second was in trimToLines, I badly yearned to put a if len(b.cells) < low check in the beginning, but it may introduce subtle bugs (why aren't things trimming?) if used in certain contexts, and it felt wrong to do it without more knowledge of the system.
Great job on the shell, btw. It's mighty impressive.

Hi! Thanks for the fix. You are correct that the mode switch should be moved down, and I prefer to leave trimToLines as it is, due to the concerns you just stated.
By the way, history listing was something I didn't finish; the ultimate goal is to steal the design ptpython's history listing (#63), which allows you to scroll through the whole history and more importantly, compose a chunk of code by cherry-picking multiple entries from the history. Before trying to implement it, I observed that it has quite a lot in common with existing completion and navigation listings -- esp. wrt. the scrolling and trimming behavior -- so a good abstraction should be made to capture the common behavior. Unable to come up with a good abstraction, I didn't bother to think hard and turned to other parts of elvish instead, leaving this unfinished thing in the code :)
If you find this interesting enough, you are more than welcome to contribute. Keep me informed about your progress, so that I won't rewrite the whole line editor in a midnight and ruin all your efforts.

authors: Zirak xiaq

repo: elves/elvish


text:
add --nobrowser field to test codecoverage.

Outline
Running embark test -c will cause the browser to automatically open with the code coverage report. The goal of this task is to add --nobrowser field for users that don't want this.
Acceptance Criteria

running embark test -c --nobrowser should running the tests & code coverage as normal, but not open the browser.
embark test -c should work as now.

PR opened: https://github.com/embark-framework/embark/pull/950

@iurimatias Seems like the task is already done

Thanks for pointing this out @subramanianv !
Yes this landed as https://github.com/subramanianv/embark/commit/890b46977780d3b3d0199ba8c459c102d6f85596
Closing this one.

@vs77bb this issue won't allow me to payout and has been closed already, can you help?

Hi @StatusSceptre it seems you need to approve me now and I will click on the 'submit' afterwards.

Approved @cryptomental

@StatusSceptre thank you, I submitted via GitCoin.

authors: PascalPrecht StatusSceptre cryptomental iurimatias subramanianv

repo: embark-framework/embark


text:
Status Bar and Cooling Icon

I was using the previous plug-in which used to provide a cooling or heating status in the status bar of each room/level but I am not getting this function with this plug-in. I would also get a change in the colour icon of each unit based on activity from Green to Blue when Cooling and to Orange when Heating. Is this option available with this plug-in.
Thanks

Is this due different plugin functionality or due to a change in HomeKit, i.e. how Apple chooses to display it? Do you have a reference implementation of a plugin that achieves these UI distinctions?

Hi
Thank you for getting back to me. Prior to using this plug-in, I was using the Panasonic Air Conditioner plug-in by Cody1515 which has now been archived. He mentioned that your plug-in is based on the same coding, the difference being that yours uses the platform rather than individual accessories/units (trying to explain this as best as I can but my knowledge is pretty basic) His plug-in also did not initially update the status bar nor did it control the icon colour based on setting, Green for Standby, Blue for Cooling and Orange for Heating. But one of the last updates included these functions which were quite useful. So for example, when using the cooling option, the Green Circle would turn Blue and the Status Bar on the top of the Room/Level would change from Idle to Cooling and note the temperature much like the Heatmiser accessories would show the Room was Heating. I hope this clarifies the “issue”.  As I am very dependent on this plug-in, I would be willing to donate but there is not such option on your plug-in.
Many Thanks

I’m attaching screenshots I found of the features I was trying to explain.
This is the Status Bar up top that shows that the AC is on Cooling and the Temperature of the Room

And this is a side by side of my Underfloor Heating on Standby (Green) and the AC on Cooling (Blue) and again showing the Temperature within the circle.

I hope this helps
Thanks again

The results of my debugging session suggest that we might be dealing with a Homebridge or HomeKit bug.

The status icon in the Home app is controlled by the CurrentHeaterCoolerState characteristic of the accessory.

On this line, we set the current state to IDLE when the AC is in cooling mode and the current temperature is less than the set temperature. However, in my test the Home app displays the status of the AC as inactive.

In my debugging session, I also tried setting the current state to INACTIVE instead of IDLE and I got the same result on the UI.

As an additional test, I set the current state to HEATING. The Home app UI reflected this correctly (as Heating), which leaves me thinking that Homebridge or HomeKit don't distinguish between the IDLE and INACTIVE modes.

@1homebridge, upon further exploration I can confirm that I actually see the "Cooling" indicator and the blue arrow in my Home app.

In your previous comments, you uploaded images of how you want it to look like, but can you upload a screenshot of how it actually looks like for you right now?
My previous comment alleged a bug with regards to how IDLE and INACTIVE lead to the same UI representation. It does not, however, confirm your original thesis of the indicators not being available at all. Could you help me clarify the problem statement?

The overlap between the IDLE and INACTIVE statuses is addressed in this issue in the Homebridge repository.

can you set Debug to "true" in your config. Restart and post the output from your log.
Maybe we can resolve the issue then.
My config looks like this;
{             "name": "Homebridge Panasonic AC Platform",             "email": "xxxxxxxxxxxxxxxxxxx@xxx.xxx",             "password": "xxxxxxxxxxxxxxxxxx",             "exposeOutdoorUnit": true,             "debugMode": true,             "platform": "Panasonic AC Platform"         },

@1homebridge, is this the same type of issue as in #23 and #31?

Hi, thanks for getting back to me.
Yes, though with the new UI in iOS16 the Status Bar no longer indicates between Idle-Cooling-Heating states so the issue is just to obtain an indoor temperature reading from the outdoor unit as described in #23 and #31 to stop getting a 0.0* indicator. This would then allow the units to show the Blue colour indicating that they are in Cooling mode as requested in the other threads.
Thanks

Okay, thanks for confirming and the additional context. Will deal with it through the other open issues.


text:
Update to latest minimatch to avoid deprecation warning

Avoids npm WARN deprecated minimatch@2.0.10: Please update to minimatch 3.0.2 or higher to avoid a RegExp DoS issue

@stefanpenner Awesome!!

repo: ember-cli/broccoli-concat


text:
Convert EmbraceDeliveryServiceTest to use a real DeliveryCacheManager

Goal

Testing

Release Notes

WHAT:
WHY:
WHO:

[!WARNING]
This pull request is not mergeable via GitHub because a downstack PR is open. Once all requirements are satisfied, merge this PR as a stack on Graphite.
Learn more

#618
#617  👈
#616
master

This stack of pull requests is managed by Graphite. Learn more about stacking.

Join @bidetofevil and the rest of your teammates on  Graphite

Merge activity

Mar 26, 3:09 AM EDT: @bidetofevil started a stack merge that includes this pull request via Graphite.

repo: embrace-io/embrace-android-sdk


text:
Add in an additional step to validate in ExecutionCoordinator

Goal

Testing

Release Notes

WHAT:
WHY:
WHO:

#960  👈
master

This stack of pull requests is managed by Graphite. Learn more about stacking.

Join @bidetofevil and the rest of your teammates on  Graphite

Merge activity

Jun 13, 2:22 AM EDT: @bidetofevil merged this pull request with Graphite.


text:
Bug: hover data when geo is changed

When hovering, the data onHover is not changed after the data is updated from a subregion to country view.

Resolves in the latest version

authors: emeeks susielu

repo: emeeks/react-dorling-map


text:
La'Tonia Mertica EW Mentee Assessment (to date)

as much as could complete on my own

Hello Those Powering EW,
Didn't see option to add reviewer(s) et cetera. Apologies if this pull request is in error in any way.
Thanks for this opportunity, please stay safe.

repo: emergentworks/mentee-assessments


text:
Update pure_glow example to glutin 0.30

A lot has changed in glutin 0.30, it would be nice if the pure_glow example could be updated to glutin 0.30 :)
I had some code that was based on the pure_glow example before, now I'm updating it to glutin 0.30, but I'm not sure if I'm doing everything correctly with the new ways of doing things.
You can find my code here: https://github.com/rust-windowing/glutin/issues/1445#issuecomment-1337903593
I would appreciate if you can let me know if it's correct. The pure_glow example could be updated similarly.

@coderedart Thanks. And should I use .with_profile(GlProfile::Core) or not? :)

@coderedart Thanks. And should I use .with_profile(GlProfile::Core) or not? :)

always use Core, unless you are targeting really ancient hardware.

authors: Boscop coderedart

repo: emilk/egui


text:
Fix: Use default features in Image Crate

Closes #4489
Related #4495

Fix: Use default features in Image Crate
Because only .png is available after update #4495.
Required to use JPEG, etc.

No - eframe only need png support, and should not be paying for the compilation of ten other image formats

authors: emilk rustbasic


text:
Add support for iOS PWA app bar

Add the ability to match the colour of the iOS PWA application bar to the overlay colour to create a more native feel.
Examples
Without iOS App Bar Support

With iOS App Bar Support

Solution

User needs these meta tags

<meta name="apple-mobile-web-app-status-bar-style" content="black-translucent" />
<meta name="apple-mobile-web-app-capable" content="yes" />

Changes made in vaul/src/index.tsx to dynamically change the background colour to match overlay background colour
Will also solve some of the issues with this issue https://github.com/emilkowalski/vaul/issues/259

maybe， can solve this issue #199 too

It seems like #199 isn't an issue with body backgrounds.

repo: emilkowalski/vaul


text:
How to swipe outside of the drawer to open/close?

The ChatGPT mobile app has the most beautiful drawer functionality, and I'm trying to recreate that.
At any time the user can side swipe the chat or drawer area to open or close the drawer and shift the entire page layout.
My main hurdle is being able to swipe outside of the drawer while still being able to select what's beneath that outside swipeable area...
Does my entire layout need to be inside the drawer? With only half of it looking like the drawer? And without the drawer being allowed to fully close?
Any suggestion anyone reading this has would be fantastic.
Thank you!

check MUI swipable drawer

@max-17 I haven't tried this yet but I think a horizontal CSS scroll snap on the layout solves my needs

That's not supported here. The Drawer here is a Dialog meaning that it usually sits on top of other elements.
If you'd want to use this Drawer for something like ChatGPT's mobile app you could position the Drawer off screen initially and add an additional drag event to the body that would translate the content.

@max-17 Did you create a fork and build this functionality?

I was able to achieve this quite easily:

Use a controlled Vaul drawer, ie open and onOpenChange
Add a react-swipeable handler to my layout, and capture specific onSwipeStart events within X pixels of the edge of the screen and set open to true


text:
Update data-dall.Rmd

Handful of typo corrections & suggested syntax revisions. Looks like this is / will be a great resource!
This is a quick test with just a handful of suggested edits. Happy to modify process if there's a better way to submit these, e.g. with separate commits (e.g. I'm not sure "consumer robotics" company is necessarily better descriptor than "e-commerce" company).

Wow - thanks so much for taking the time, @jonspring ! I really appreciate these

authors: emilyriederer jonspring

repo: emilyriederer/data-disasters


text:
Add PROJECT_BRIEF to Doxyfile

Come on, why wasn't it done before?
Let me know if I fucked this up, I don't have Doxygen installed.

"why wasn't it done before?" Because I expect people consulting the source code documentation to already know what source they are studying...

authors: NieDzejkob idmean

repo: emojicode/emojicode


text:
query to get all elements

what should I specify in the query to get all elements without filters?

Thanks for asking @ArtiikSK
Could you detail what are you trying to do?
Are you launching a web server to try?
You can add a vídeo or screenshot too if you like.

authors: ArtiikSK herrardo

repo: empathyco/x


text:
How can we display Custom Error message

//custom validate method
validator.validator.custom = function(el, event){    if($(el).is('[name=password]') && $(el).val().length < 5){        return 'Your password is too weak.';    } }
This method only return but it can not display any error on the screen.

The returned string is used as error message, you can define rule and message for specific input.

Okay, thanks @emretulek

repo: emretulek/jbvalidator


text:
update stripe api version

The change logs after 2015-09-08 don't have any major changes in the koudoku code.

LGTM

hitomi :heart:

authors: mediavrog pcboy shawila

repo: en-japan/koudoku


text:
Schedule notifications upon registering or claiming rewards

Currently, we use the feed to schedule notifications for the registering and meetup reminders, but we can actually schedule them from within the app when we do certain actions.

After registering, we can schedule two notifications, which should be reminders for the next meetup:

24 hours before the meetup time
1 hour before the meetup time

The meetup time can be fetched here: https://github.com/encointer/encointer-wallet-flutter/blob/6fc236c622932d2b503f2ae5055c846dd6c7ccaa/lib/store/encointer/sub_stores/community_store/community_store.dart#L64. The value can't be null after registering, as it can only be null if we have not chosen a community.

After claiming the rewards, we can set a reminder to register at the start of the registering phase. Note: We must only schedule the notification if we claim the rewards in the attesting phase, not in the registering phase, obviously.

The timestamp to use is the the nextPhaseTimestamp: https://github.com/encointer/encointer-wallet-flutter/blob/6fc236c622932d2b503f2ae5055c846dd6c7ccaa/lib/store/encointer/encointer.dart#L81
Caveats:

How do we ensure unique IDs that don't overlap with the IDs we assign to the notifications we get from the feed? Maybe we have to maintain an internal global counter for that.
We should only schedule notifications if we are connected to the parachain on kusama, the nctr-k

If we use global counter How do we ensure unique IDs that don't overlap with the IDs we assign to the notifications we get from the feed? Maybe we have to maintain an internal global counter for that.
Can we use cache?

I suggest generate meetupId by meetupTime
void main() {
  final meetupTimeAfter1Day = DateTime.now().add(const Duration(days: 1)).millisecondsSinceEpoch;
  final meetupTimeAfter7Days = DateTime.now().add(const Duration(days: 7)).millisecondsSinceEpoch;
  final meetupTimeAfter10Days = DateTime.now().add(const Duration(days: 10)).millisecondsSinceEpoch;
  final meetupTimeAfter15Days = DateTime.now().add(const Duration(days: 15)).millisecondsSinceEpoch;
  final meetupTimeAfter30Days = DateTime.now().add(const Duration(days: 30)).millisecondsSinceEpoch;

  print(generateMeetupIdByTimeStamp(meetupTimeAfter1Day)); // 1
  print(generateMeetupIdByTimeStamp(meetupTimeAfter7Days)); // 7
  print(generateMeetupIdByTimeStamp(meetupTimeAfter10Days)); // 10
  print(generateMeetupIdByTimeStamp(meetupTimeAfter15Days)); // 15
  print(generateMeetupIdByTimeStamp(meetupTimeAfter30Days)); // 30
}

int generateMeetupIdByTimeStamp(int meetupTime) {
  final now = DateTime.now().millisecondsSinceEpoch;
  int id = 0;
  int c = meetupTime - now;
  do {
    c -= 86400000; // 1 day = 86400000 milliseconds
    id++;
  } while (c > 0);
  return id;
}

So I think we can generate dynamic id without using any cache. Please let me know your opinion.

Hi @Eldar2021,
You suggestions look good!

When user registers to a meetup, can he register to another meetup before that meetup ends?
Yes, this is possible, but the app should not allow that because you have not yet got your reputation and you will be a newbie again. You should only be allowed to do that after the rewards have been claimed.

If we use global counter How do we ensure unique IDs that don't overlap with the IDs we assign to the notifications we
In general, I like your approach of using the meetup time. Why do you need to divide by 86400000, is the number too big? I think this could lead to problems where we end up with the same ID for reminders, which are very close to eachother, do you agree?

Is there registration deadline time? or registration finishes when meetup starts?
The registration deadline is when the registering phase is over. Remember, we have 3 phases REGISTERING > ASSIGNING > ATTESTING. As long as we are in the registering phase, the nextPhaseTimeStamp is the deadline for registering. And in the assigning phase you can already register for the meetup in the next assigning phase.

repo: encointer/encointer-wallet-flutter


text:
Convert Image to Canvas?

Is it possible to convert a image to a canvas and back so I can draw onto it?
if not could you add Graphics.NewCanvas(Image Image) and Graphics.NewCanvas(ImageData ImageData)?

There is no such method, but you can draw an image onto the canvas.

but this requires the draw event right?
I was trying to do it so it could be used anywhere

See Love.Graphics.Present. This should be what you are looking for.

can support be added so that images and canvases can be explicitly converted back and forth?

a example here :

copy the utils class into your project:
https://gist.github.com/endlesstravel/027799eb772d644b0d4110284256da6a

use it like :

static public void Test_Issue75_ToPintImage()
{
    ISSUE_75.Init();
    var imgData = ISSUE_75.PrintImage(300, 300, () =>
    {
        Graphics.SetColor(Color.LightPink);
        Graphics.Rectangle(DrawMode.Fill, 0, 0, 100, 100);
        Graphics.SetColor(Color.White);
        Graphics.Circle(DrawMode.Line, 100, 100, 20);
    });
    Resource.EncodeToFile("test.png", imgData, ImageFormat.PNG);
}

can this be added to love2dcs as a explicit image conversion?

authors: Shadowblitz16 Shylie endlesstravel


text:
[Fedora-Linux] Update EOL dates and command

F36 was delayed, which pushed back the F34 end of life date: https://fedorapeople.org/groups/schedule/f-36/f-36-key-tasks.html
F35 EOL date from: https://fedorapeople.org/groups/schedule/f-37/f-37-key-tasks.html
As for the command change, it's due to lsb_release not being installed by default anymore

Fedora is delayed again. EOL moved to 2022-06-07. Could be delayed more.


text:
Feature request: style dots and corners

If you can add more flexible feature to style qt such as this

I am very grateful! :grin:

Hi @mortezakarimi thank you. I will not add this myself but if someone is willing to contribute on this, that would be great.

The new upstream QR code library supports that now.

@DASPRiD What do you mean by "The new upstream QR code library"?

@DASPRiD What do you mean by "The new upstream QR code library"?

BaconQRCode, which this library is using.

@DASPRiD Do you by any chance have a reference where I can learn how to do so?
I can't seem to find anything about changing the style.

@DASPRiD Do you by any chance have a reference where I can learn how to do so?
I can't seem to find anything about changing the style.

There's not really any documentation for this, but the ImageRenderer takes a RendererStyle object, which can be configured. Best to look at the source:
https://github.com/Bacon/BaconQrCode/blob/master/src/Renderer/ImageRenderer.php#L26
https://github.com/Bacon/BaconQrCode/blob/master/src/Renderer/RendererStyle/RendererStyle.php

Closed as this will not be implemented here.

authors: DASPRiD MelchiorKokernoot endroid mortezakarimi

repo: endroid/qr-code


text:
chore(main): release 0.2.3

:robot: I have created a release beep boop
0.2.3 (2024-01-17)
Bug Fixes

mise tasks are experimental and must be activated (4ab703b)

This PR was generated with Release Please. See documentation.

:robot: Release is at https://github.com/engeir/volcano-core/releases/tag/v0.2.3 :sunflower:

repo: engeir/volcano-core


text:
Links to social media posts

It would be really handy if there were a way to access the links leading to the social media posts from within the entry.  I'd like to automatically display the links as part of the craft entry.  "Join the discussion on Facebook/Twitter", etc.

Just to confirm, this would be from the front-end? This way, you could post the entry to Facebook, have it record the posted URL, and then being able to access in your template?
Something like:
{% set post = craft.socialPoster.post({ account: 'facebook', entryId: entry.id }) %}

{% if post.url %}
    Join the discussion on Facebook
{% endif %}

Exactly.  That way you could drive traffic from the website to the social media posts.

Just to follow this up - this is now implemented in 1.2.0. Use the following template code:
{% set posts = craft.socialPoster.posts({ element: entry }) %}

{% for post in posts %}

         Join the discussion on {{ post.handle | capitalize }}

{% endfor %}

authors: engram-design pixeljitsu

repo: engram-design/SocialPoster


text:
Repo and Org Variables

I wonder if this statement holds true:
https://github.com/engswee/flashpipe/blob/687862ea650f903531ae0dfe13d1459582c95847/docs/github-actions-sync-apim.md?plain=1#L28
Github Actions offers Repo and Org variables (doc)
Are you referring to something else?

Thanks for highlighting this. Unfortunately, documentation often can't keep up with the speed that new features are introduced 😅
If you see the screenshot from the following page, you can see that variables were not there in the past.
https://engswee.github.io/flashpipe/github-actions-sync-to-git.html
I'd have to admit that I can't keep track of all the new features that are constantly being rolled out, so have definitely missed this one out. It's good to know about this, so that I can use it in my workflows and also update the documentation.
I'll keep this issue open until I get around to updating the documentation 😉

authors: ambravo engswee

repo: engswee/flashpipe


text:
Prepare 6.0.1

Stepping through the commits is the easiest way to review this because of the docs changes.
Draft because we are waiting on https://github.com/enketo/openrosa-xpath-evaluator/pull/136 and then a 2.0.9 release.
Verified the following:

[ ] npm update
[ ] npm audit fix --production
[ ] npm run test
[ ] npm run test-browsers
[ ] npm run beautify
[ ] npm run build-docs

npm run test-browers has a scary Firefox failure. It'd be good to see if it fails on v5.17.6.
```Firefox 93.0 (Mac OS 10.15) merging an instance into the model when the record contains namespaced attributes, the merged result is CORRECTLY namespaced namespaces are added correctly FAILED``

https://github.com/enketo/enketo-core/pull/822 should also be merged first, right?

authors: lognaturel yanokwa

repo: enketo/enketo-core


text:
Site created on startup

The default site is created on application start. WIth app and info-page content types, including populated fields.

Should we just remove the site init code and let the user manually setup office-league with site office-league?
This would still keep the init of the office-league repoes but remove the auto generated site.

Remove the auto generated site. Keep the generated repo storrage.

repo: enonic/app-office-league


text:
fix: swap the order of handling order and pred  in the graph select func

multi order may generate predicates, so running the order funcs first allows reusing aliases.
If the predicates run first if there is a multiOrder field that generates it's own predicates, the predicates are unable to find the alias of the join and errors not finding the column on the table.
Related to: https://github.com/ent/contrib/pull/559

Thanks for the contribution, @michaelcaulley 🚀

repo: ent/ent


text:
Add support for more template generators

YAML
cfndsl - https://github.com/stevenjack/cfndsl

Any others?

It might be nice to have JSON support with comments. Would need to find a library to strip them out I guess.
Another one might be just using plain old ERB?

If you want JSON support with comments, technically you can just use YAML.  An alternate syntax of YAML is actually just JSON + comments, so any YAML parser should be able to parse a JSON file with comments in it.
[1] pry(main)> require 'yaml'
=> true
[2] pry(main)> test = "{\n#testing\n}"
=> "{\n#testing\n}"
[3] pry(main)> YAML.load(test)
=> {}

So yeah, +1 for YAML input. should be pretty trivial to add, I'll fork and see.

cfndsl support would be really good as it is the most popular generator of cloudformation templates that is written in ruby. it should be really easier to integrate as it is just running cfndsl commands.
I also use the ppjson to pretty print the generated cloudformation code.
I've built alot of examples for cfndsl at https://github.com/neillturner/cfndsl_examples
and there is a utility to convert templates to cfndsl format that is very handy.

Hi @neillturner we have added basic CfnDsl template support with #99. However, this dose not add support for using cfndsl variables. How would you like that supported in SM? How would you imagine a user supply values for cfndsl variables when using a cfndsl template with SM?

authors: flyinbutrs gstamp neillturner stevehodgkiss thekindofme


text:
Number of stats and length of stat name should be configurable

Envoy currently hardcodes a limit of 16k individual stats, with a fixed maximum name length.  These values should be tunable.

+1

Defaults should be settable at compile-time via .bazelrc (or similar), and overridable via CLI flag at startup.

@hennna

It is easy to make finding unused stats O(1) with a free-list or similar. But doing the name-lookups is a little bit harder in shared memory. We'll probably need a lookup table of some kind in the shared memory.

If we want to do this, I would recommend doing it as a totally independent change from the length stuff. Given how low frequency stat allocation is from shared memory the current situation is probably not that big of a deal for most people.

I was going to benchmark filling up a somewhat big number of stats, maybe 1M or something, and see how long it takes.  That should simulate the worst likely-case, which is startup with a large configuration.  But I'm expecting that would be pretty slow: n^2 is 1 trillion operations.
But I agree that it can be done in a separate change.  Making the sizes tunable won't cause any degradation to existing use cases unless users opt-in to a really large stat size, and they should immediately notice some pain on startup if they choose too-large of a size.

authors: ggreenway htuch mattklein123

repo: envoyproxy/envoy


text:
Add Attributes connection.transport_failure_reason

Title: Add Attributes connection.transport_failure_reason along with TLS connection errors
Description:

Describe the desired behavior, what scenario it enables and how it
would be used.
Purposed Attributes
connection.transport_failure_reason:
Currently upstream.transport_failure_reason is included in the attributes to indicate the upstream transport failure such as certificate validation failed. But there's no similar ones for downstream connection. Considering recent PR added downstream transport failure reason to access log, it can be added to attributes as well for consistency.

[optional Relevant Links:]

Any extra documentation required to understand the issue.
https://www.envoyproxy.io/docs/envoy/latest/intro/arch_overview/advanced/attributes.html#attributes
https://github.com/envoyproxy/envoy/pull/25322/files

cc @kyessenov

@mattklein123 could you add a "help wanted" tag to revive this issue?

authors: XinyiZhangAws mattklein123 ytsssun


text:
Test flake: //test/extensions/filters/http/ext_proc:ext_proc_integration_test

https://dev.azure.com/cncf/envoy/_build/results?buildId=179508&view=logs&j=4930ecaf-18f4-5b3c-dea3-309729c3b3ae&t=573d8780-d7b9-52e3-b4e0-a89886b0b9ff&l=3840
[ RUN      ] IpVersionsClientTypeDeferredProcessing/ExtProcIntegrationTest.GetAndCloseStreamWithTracing/IPv4_GoogleGrpc_WithDeferredProcessing
test/extensions/filters/http/ext_proc/tracer_test_filter.cc:52: Failure
Expected equality of these values:
  want
    Which is: "0"
  got
    Which is: ""
grpc.status_code: 0 not found in tags:
component: proxy
status: canceled
upstream_address: 127.0.0.1:37667
upstream_cluster: ext_proc_server_0

@tyxia

@cainelli Do you mind taking a look at this? Thank you!
I think tracing related feature was added by your change

oh sorry about that. I will take a look into it this week.

@tyxia the failure is a timeout and the tracing failure is a side effect. I don't see how such simple request would take more than 5s to run.
test/extensions/filters/http/ext_proc/ext_proc_integration_test.cc:281: Failure
Value of: fake_upstreams_[0]->waitForHttpConnection(*dispatcher_, fake_upstream_connection_)
  Actual: false (Timed out waiting for new connection.)
Expected: true

....

test/extensions/filters/http/ext_proc/ext_proc_integration_test.cc:277: Failure
Expected equality of these values:
  std::to_string(status_code)
    Which is: "200"
  response.headers().getStatusValue()
    Which is: "504"
Stack trace:
  0x1578018: (unknown)
  0x13cb8bc: (unknown)
  0x7fc368411a4d: testing::internal::HandleSehExceptionsInMethodIfSupported<>()
  0x7fc3683f822e: testing::internal::HandleExceptionsInMethodIfSupported<>()
  0x7fc3683dfb1d: testing::Test::Run()
  0x7fc3683e060e: testing::TestInfo::Run()
... Google Test internal frames ...

actually, is the timeout 5ms? should we increase it a bit?
https://github.com/envoyproxy/envoy/blob/7a7df5d8887dfe673eef51ce396feab4bff9383f/test/integration/http_integration.cc#L555-L556

@cainelli Thanks for spending effort reducing the flakiness.
In the past, we have test (as you linked in slack) that have larger then 5s timeout. However, that is because  Please don't waitForHttpConnection with a 5s timeout if failure is expected. In your case, failure is not expected.
I am not sure if the flakiness is because tracing will take a bit more time but 5s should be sufficient here. Or maybe because ext_proc_integration test has grown very big now. Do you happen to know what is the flakiness rate?

if you can't repro the flake (per slack) one thing you can do is add a LogLevelSetter in that test such that CI logs more information when it flakes.  then next time we see a failure you'll have more information.

One thing I've found often helps if you can't repro a flake is to run stress -c 16 (or however many CPU cores) in another terminal while the test runs with --runs_per_test=n. (Flags also depending on if the flakiness is from being CPU bound or network bound or disk bound.)

Thank you all for the context and tips.

One thing I've found often helps if you can't repro a flake is to run stress -c 16 (or however many CPU cores) in another terminal while the test runs with --runs_per_test=n. (Flags also depending on if the flakiness is from being CPU bound or network bound or disk bound.)

I did tried that with various combinations to stress during the test but did not have any luck reproducing it.

if you can't repro the flake (per slack) one thing you can do is add a LogLevelSetter in that test such that CI logs more information when it flakes. then next time we see a failure you'll have more information.

I will try this path moving forward (https://github.com/envoyproxy/envoy/pull/36583).

authors: alyssawilk cainelli ravenblackx tyxia


text:
Implement a Token Introspection (RFC 7662) HTTP Filter

Token Introspection (RFC 7662): Implement an HTTP Filter to verify external token
Description:

Allow external OAuth2/OIDC token to be valided via the Token Introspection api in order for envoy to act as a Identity Aware Proxy (IAP)

Relevant Links:

https://datatracker.ietf.org/doc/html/rfc7662
https://www.oauth.com/oauth2-servers/token-introspection-endpoint/

Please get familiar with our extension policy: https://github.com/envoyproxy/envoy/blob/main/EXTENSION_POLICY.md

cc @tyxia @mattklein123 @TAOXUY (as oauth, jwt extension owners who may be interested in this proposal)

authors: nezdolik supercairos


text:
Redis through envoy gets high response time with redis-benchmark

Hi,
I’m deploying envoy redis in our environment and I’ve found out that it’s increasing the RTT of the 95 percentile requests to redis in about 7~ms, I have run redis-benchmark tool in both configurations, and through envoy the higher percents getting a much higher response time. results attached.
this is the configuration file:
static_resources:
  listeners:
  - address:
      socket_address:
        address: 0.0.0.0
        port_value: 50051
    filter_chains:
    - filters:
      - name: envoy.http_connection_manager
        config:
          codec_type: auto
          stat_prefix: ingress_http
          route_config:
            name: local_route
            virtual_hosts:
            - name: local_service
              domains:
              - "*"
              routes:
              - match:
                  prefix: "/"
                route:
                  cluster: local_service_grpc
          http_filters:
          - name: envoy.router
            config: {}
  - name: redis_nrt_listener
    address:
      socket_address:
        address: 0.0.0.0
        port_value: 6379
    filter_chains:
    - filters:
      - name: envoy.redis_proxy
        typed_config:
          "@type": type.googleapis.com/envoy.config.filter.network.redis_proxy.v2.RedisProxy
          stat_prefix: egress_redis
          settings:
            op_timeout: 0.03s
            enable_redirection: true
            enable_hashtagging: true
          prefix_routes:
            catch_all_route:
              cluster: redis_nrt_cluster
  - name: redis_vol_listener
    address:
      socket_address:
        address: 0.0.0.0
        port_value: 6380
    filter_chains:
    - filters:
      - name: envoy.redis_proxy
        typed_config:
          "@type": type.googleapis.com/envoy.config.filter.network.redis_proxy.v2.RedisProxy
          stat_prefix: egress_redis
          settings:
            op_timeout: 0.03s
            enable_redirection: true
            enable_hashtagging: true
          prefix_routes:
            catch_all_route:
              cluster: redis_vol_cluster
  clusters:
  - name: local_service_grpc
    connect_timeout: 0.250s
    type: logical_dns
    lb_policy: round_robin
    http2_protocol_options: {}
    health_checks:
    - timeout: 1s
      interval: 3s
      interval_jitter: 1s
      unhealthy_threshold: 3
      healthy_threshold: 3
      tcp_health_check:
        send:
        receive: []
    hosts:
    - socket_address:
        address: router-us-east4-b-prod.ocddx.com
        port_value: 50051
  - name: redis_vol_cluster
    connect_timeout: 1s
    type: strict_dns # static
    lb_policy: MAGLEV
    load_assignment:
      cluster_name: redis_cluster
      endpoints:
      - lb_endpoints:
        - endpoint:
            address:
              socket_address:
                address: redis-us-east4-b-prd.ocddx.com
                port_value: 6379
  - name: redis_nrt_cluster
    connect_timeout: 1s
    type: strict_dns # static
    lb_policy: MAGLEV
    load_assignment:
      cluster_name: redis_cluster
      endpoints:
      - lb_endpoints:
        - endpoint:
            address:
              socket_address:
                address: redis-nrt-us-east4-b-prd.ocddx.com
                port_value: 6379
admin:
  access_log_path: "/var/log/envoy_admin_access.log"
  address:
    socket_address:
      address: 0.0.0.0
      port_value: 9901

redis-benchmark running from container to the envoy sidecar:
redis-benchmark -h collector_envoy -t set,get
====== SET ======
  100000 requests completed in 7.06 seconds
  50 parallel clients
  3 bytes payload
  keep alive: 1

4.92% <= 1 milliseconds
59.69% <= 2 milliseconds
73.69% <= 3 milliseconds
82.54% <= 4 milliseconds
88.11% <= 5 milliseconds
91.77% <= 6 milliseconds
94.26% <= 7 milliseconds
95.89% <= 8 milliseconds
97.18% <= 9 milliseconds
98.01% <= 10 milliseconds
98.58% <= 11 milliseconds
98.97% <= 12 milliseconds
99.22% <= 13 milliseconds
99.43% <= 14 milliseconds
99.58% <= 15 milliseconds
99.73% <= 16 milliseconds
99.78% <= 17 milliseconds
99.81% <= 18 milliseconds
99.88% <= 19 milliseconds
99.90% <= 20 milliseconds
99.90% <= 21 milliseconds
99.93% <= 22 milliseconds
99.97% <= 23 milliseconds
99.98% <= 24 milliseconds
99.98% <= 28 milliseconds
100.00% <= 29 milliseconds
14164.31 requests per second

====== GET ======
  100000 requests completed in 7.66 seconds
  50 parallel clients
  3 bytes payload
  keep alive: 1

4.18% <= 1 milliseconds
55.05% <= 2 milliseconds
71.89% <= 3 milliseconds
81.03% <= 4 milliseconds
87.10% <= 5 milliseconds
90.96% <= 6 milliseconds
93.66% <= 7 milliseconds
95.49% <= 8 milliseconds
96.44% <= 9 milliseconds
97.22% <= 10 milliseconds
97.75% <= 11 milliseconds
98.34% <= 12 milliseconds
98.83% <= 13 milliseconds
99.15% <= 14 milliseconds
99.34% <= 15 milliseconds
99.49% <= 16 milliseconds
99.59% <= 17 milliseconds
99.69% <= 18 milliseconds
99.72% <= 19 milliseconds
99.81% <= 20 milliseconds
99.87% <= 21 milliseconds
99.89% <= 22 milliseconds
99.91% <= 23 milliseconds
99.92% <= 24 milliseconds
99.93% <= 25 milliseconds
99.96% <= 26 milliseconds
99.97% <= 27 milliseconds
99.97% <= 28 milliseconds
99.98% <= 29 milliseconds
99.98% <= 34 milliseconds
99.98% <= 35 milliseconds
99.99% <= 36 milliseconds
100.00% <= 37 milliseconds
13063.36 requests per second

redis-benchmark running from container to a single redis host (part of a  masters cluster):
bash-4.4# redis-benchmark -h 10.240.15.147 -t set,get
====== SET ======
  100000 requests completed in 4.95 seconds
  50 parallel clients
  3 bytes payload
  keep alive: 1

11.96% <= 1 milliseconds
94.58% <= 2 milliseconds
96.80% <= 3 milliseconds
98.02% <= 4 milliseconds
98.75% <= 5 milliseconds
99.27% <= 6 milliseconds
99.58% <= 7 milliseconds
99.75% <= 8 milliseconds
99.89% <= 9 milliseconds
99.96% <= 10 milliseconds
99.97% <= 11 milliseconds
99.97% <= 12 milliseconds
99.99% <= 13 milliseconds
100.00% <= 13 milliseconds
20197.94 requests per second

====== GET ======
  100000 requests completed in 5.07 seconds
  50 parallel clients
  3 bytes payload
  keep alive: 1

15.41% <= 1 milliseconds
90.76% <= 2 milliseconds
95.60% <= 3 milliseconds
97.79% <= 4 milliseconds
98.70% <= 5 milliseconds
99.23% <= 6 milliseconds
99.60% <= 7 milliseconds
99.76% <= 8 milliseconds
99.82% <= 9 milliseconds
99.83% <= 11 milliseconds
99.87% <= 12 milliseconds
99.89% <= 13 milliseconds
99.91% <= 14 milliseconds
99.97% <= 15 milliseconds
99.99% <= 16 milliseconds
100.00% <= 16 milliseconds
19704.43 requests per second

As you can see there's a huge different between the response times, I've been trying to change some configuration for example: type to logical_dns instead of strict_dns, remove the lb_type and add max_buffer_size_before_flush and buffer_flush_timeout and even change the dns to point to only one member of the redis cluster, the same host I checked in the second test, to ensure the reliability of the redis-benchmark test.
I'd be glad if someone who using redis with envoy will do the same test I did and share the results, and if someone has any recommendations to solve this response time issue

@zuercher please add a BUG label, seems like its happening also in other environments

Are you introducing a network hop in the envoy case in your test?
Here's the result for my test against a local docker container:

root@8362fe3593b4:/# redis-benchmark -h redis-server -p 7001 -t get,set
====== SET ======
100000 requests completed in 3.07 seconds
50 parallel clients
3 bytes payload
keep alive: 1
84.07% <= 1 milliseconds
99.09% <= 2 milliseconds
99.84% <= 3 milliseconds
99.93% <= 4 milliseconds
99.94% <= 5 milliseconds
99.96% <= 6 milliseconds
99.96% <= 9 milliseconds
99.96% <= 10 milliseconds
99.97% <= 11 milliseconds
99.99% <= 26 milliseconds
100.00% <= 27 milliseconds
100.00% <= 27 milliseconds
32626.43 requests per second
====== GET ======
100000 requests completed in 3.04 seconds
50 parallel clients
3 bytes payload
keep alive: 1
85.27% <= 1 milliseconds
98.79% <= 2 milliseconds
99.85% <= 3 milliseconds
99.97% <= 4 milliseconds
99.97% <= 9 milliseconds
99.99% <= 10 milliseconds
100.00% <= 11 milliseconds
32894.74 requests per second
root@8362fe3593b4:/# redis-benchmark -p 6381 -t get,set
====== SET ======
100000 requests completed in 3.78 seconds
50 parallel clients
3 bytes payload
keep alive: 1
0.00% <= -32 milliseconds
0.01% <= -30 milliseconds
0.02% <= -29 milliseconds
0.03% <= -28 milliseconds
0.03% <= -26 milliseconds
0.04% <= 0 milliseconds
24.19% <= 1 milliseconds
89.52% <= 2 milliseconds
99.04% <= 3 milliseconds
99.78% <= 4 milliseconds
99.82% <= 5 milliseconds
99.84% <= 6 milliseconds
99.85% <= 7 milliseconds
99.87% <= 8 milliseconds
99.89% <= 10 milliseconds
99.94% <= 11 milliseconds
99.96% <= 12 milliseconds
99.97% <= 13 milliseconds
99.98% <= 14 milliseconds
99.98% <= 15 milliseconds
99.98% <= 16 milliseconds
99.99% <= 19 milliseconds
100.00% <= 20 milliseconds
26462.03 requests per second
====== GET ======
100000 requests completed in 3.05 seconds
50 parallel clients
3 bytes payload
keep alive: 1
28.07% <= 1 milliseconds
96.50% <= 2 milliseconds
99.51% <= 3 milliseconds
99.80% <= 4 milliseconds
99.95% <= 5 milliseconds
100.00% <= 6 milliseconds
100.00% <= 6 milliseconds
32797.64 requests per second

Here's the relevant section of envoy.yaml:
static_resources:
  listeners:
    - name: listener_1
      address:
        socket_address:
          address: 127.0.0.1
          port_value: 6381
      filter_chains:
        filters:
          name: envoy.redis_proxy
          config:
            stat_prefix: redis_stats
            prefix_routes:
              catch_all_route:
                cluster: cluster_1
            settings:
              op_timeout: 5s
  clusters:
    - name: cluster_1
      connect_timeout: 0.25s
      lb_policy: RING_HASH
      hosts:
      - socket_address:
          address: redis-server
          port_value: 7001
      type: STRICT_DNS

envoy is a sidecar container on the application

I ran both tests on the envoy container to get an apple to apple measurement.

@mosespx i am facing the same issue. Did you got any solution or workaround?

@saagar241290 no, I didn't use this solution because of this issue.
please share here if you find something interesting

@mosespx I tried by increasing number of connections of redis pool to 100 and it gave me a better performance. Earlier there was only a single connection.

@saagar241290 when you says

tried by increasing number of connections of redis pool to 100 and it gave me a better performance. Earlier there was only a single connection.

Are these connections on client?

authors: HenryYYang mosespx ramaraochavali saagar241290


text:
pre startup checks for windows: log if system variables need changing

pre startup checks: Check os variables before startup on windows
Description:
As a fix for issue https://github.com/envoyproxy/envoy/issues/7130, PR #8600 introduces an interface and a posix implementation that runs platform specific checks before startup.
The win32 implementation source/exe/win32/platform_checks.cc adds a no-op which should be implemented.

#7130 is fixed via #9098, which just adds user documentation instead of moving checks into envoy source code.


text:
API Request: Add HttpFilter.instance_name

HttpFilter.name is used to instantiate a specific type of filter by http_connection_manager
In that sense HttpFilter.name is the className parameter.
In filters like WASM and lua, a filter with the same name is deployed multiple times.
This makes it difficult to identify a specific filter instance without resorting to peeking inside HttpFilter.typed_config.
Add
message HttpFilter {
  // The name of the filter to instantiate. The name must match a
  // :ref:`supported filter <config_http_filters>`.
  string name = 1 [(validate.rules).string = {min_bytes: 1}];

  string instance_name = 5;

  // ...
}

Using instance_name, the filter can be identified in a meaningful way.
In the following example, without instance_name=wasm.stats both filters have the same name envoy.filters.http.wasm.
filters:
- name: envoy.http_connection_manager
   typed_config:
    '@type': type.googleapis.com/envoy.config.filter.network.http_connection_manager.v2.HttpConnectionManager
    forward_client_cert_details: APPEND_FORWARD
    generate_request_id: true
    http_filters:
    - instance_name: wasm.stats
      name: envoy.filters.http.wasm
      config:
        config:
          root_id: stats_inbound
          vm_config:
            code:
              inline_string: envoy.wasm.stats
            runtime: envoy.wasm.runtime.null
            vm_id: stats_inbound
    - instance_name: wasm.metadata_exchange
      name: envoy.filters.http.wasm
      config:
        config:
          vm_config:
            code:
              inline_string: envoy.wasm.metadata_exchange
            runtime: envoy.wasm.runtime.null

Here

@kyessenov @rshriram

My initial sniff test is that this is not generally useful, and I don't see why it's that bad to peak inside the typed_config, but happy to be swayed if there is a convincing argument.

I think this would be useful for Filter Config discovery service. Having a common field across all filter configs helps in discovery and monitoring IMHO. I don't think it's possible to express that Any in the typed config must have a specific field, so pulling it up one level to filter config seems reasonable:
# static config
name: envoy.http.wasm
config_name: wasm1
typed_config: {}
# dynamic config
name: envoy.http.wasm
config_name: wasm1
config_source:
  ads: {}

In the case of FCDS, we will be moving config up to a oneof, and then the config itself will have to have a name and a config source, so I think it would be covered there?

Yeah, it can be done either way. But it would help us to have config name to be a peer of typed_config instead of being nested in a oneof peer. This is because we run multiple transformation passes, and having a name in the xDS helps with identifying the config/filter instance. This is consistent with the rest of xDS where each resource has a name in its proto.

@htuch any thoughts on ^?

I think this is useful in the context of FCDS, WASM and tooling (or control planes) that operate on opaque config (i.e. they can't peek inside).
Here's an interesting thought for v3; since we will no longer have untyped Struct, and will have a world of only TypeStruct and Any, and every extension should have its own unique config proto, we should in face be able to get rid of the need to have any filter type. I.e. you don't need to write envoy.wasm, your use of the WASM config option implies that via the embedded type URL. This means that the name field could be used arbitrarily for user purposes in v3+.

@htuch This would work if every filter config is unique per filter. I think there may be cases where two filters share a proto for the config. Not sure if that's something dis-allowed already.

One more use case for the control plane to operate on this config in an opaque way is to be able to do partial ordering between different filters. I.e. if control plane is provided with 10 "envoy.wasm" filters, there is no meaningful way to describe a relative order between them.
@htuch, just having "name" as a unique arbitrary name and rely on type for the actual type in v3 works as well.

Partial order is one of the motivating use case here. Peeking inside requires specific knowledge of the filter.
Changing the meaning of “name” from type_name to unique_name seems risky, though it will work.
If we add instance_name / config_name field we can actually add it to both v2 and v3

For xDS v2, we can relax the constraint that the config message must match the filter name (as long as it's not a regular struct). That would allow arbitrary names without a breaking change.

This instance_name which will be referenced by FCDS.
Looks like in the cpp code the expression would be resource.XX_name(). Maybe calling it resource_name()?

It would be good to have a v2 xDS solution here, but we need to be very clear what the semantics are if we reuse the field, i.e. it should only be possible if fully unambiguously typed configuration is otherwise present. It also might surprise some folks, as they may have built validators in their config pipeline to ensure consistency of name and config.

We could also add a filter_type field that unambiguously denotes the type. If the type field is specified then name can be free form.

@htuch In the linked PR, we can infer the name of the extension from the protobuf type for most cases. There are just two exceptions:

Empty, which is being solved separately.
Migrated APIs. I think we need this information regardless, but it seems clear that all versions of configs should be distinct.

I agree about the surprise effect. Fortunately that only happens with the invalid config, e.g. some invalid config might become valid since name is not significant.
I actually quite like the name/typed_config pattern. It applies in many places across the code base.

@kyessenov what do you reckon the state of this issue is?

I think this is resolved. If typed_config is used with the extension-specific type, name can be set to anything. I've updated the unit tests https://github.com/envoyproxy/envoy/pull/10071, https://github.com/envoyproxy/envoy/pull/10122, https://github.com/envoyproxy/envoy/pull/10130

Ack, thanks @kyessenov for the rad contribution here, closing.

authors: alexburnos htuch kyessenov lambdai mandarjog mattklein123


text:
[fuzz] Got rid of all uninteresting call logs in health check fuzzing

Signed-off-by: Zach Reyes zasweq@google.com
Commit Message: Got rid of all uninteresting call logs in health check fuzzing
Additional Description: Uninteresting call logs were slowing down my health check fuzzer in oss-fuzz. This PR gets rid of all uninteresting call logs by wrapping applicable objects in NiceMocks. However, since at the beginning of my internship I refactored the unit tests to also use fuzz tests, I put the unit test classes back in test/common/upstream:health_checker_impl_test.cc, and renamed test/common/upstream:health_checker_impl_test_utils to health_check_fuzz_test_utils.
No loss in coverage over source/common/upstream/health_checker_impl.cc. Speed up to 30 exec/sec on my cloudtop instance.
Risk Level: Low

/assign @asraa @htuch @adisuissa

Thanks! What was the before of the speed on cloudtop?

Honestly Asra it was same speed, 30 exec/sec.

authors: asraa zasweq


text:
docs: Use yaml build config for vars

Signed-off-by: Ryan Northey ryan@synca.io
Commit Message: docs: Use yaml build config for vars
Additional Description:
Another breakout from #15229
This adds a build configuration file for vars passed through to sphinx
Risk Level:
Testing:
Docs Changes:
Release Notes:
Platform Specific Features:
[Optional Runtime guard:]
[Optional Fixes #Issue]
[Optional Deprecated:]
[Optional API Considerations:]

I think this looks good, other than the question re: descriptor_path parameter in the validating code block.

lgtm

authors: dmitri-d phlax


text:
bazel: remove old luajit workaround

According to https://luajit.org/install.html

Important: this relates to LuaJIT 2.0 only — use LuaJIT 2.1 to avoid these complications.

Since we have updated past 2.1 we shouldn't need these anymore which is
great since it breaks on Apple Silicon
https://github.com/envoyproxy/envoy/issues/16482#issuecomment-846439439
Signed-off-by: Keith Smiley keithbsmiley@gmail.com

@moderation wdyt?

LGTM. I commented these lines out when I got M1 building a while back - https://github.com/envoyproxy/envoy/issues/16482#issuecomment-846439439
Removing as we don't require makes sense. MacOS CI failing however

Yea I just noticed that we can probably remove them instead. Turns out I can't let the options fallthrough, hopefully green now

authors: keith moderation


text:
conn pool: default enable runtime feature conn_pool_delete_when_idle

Signed-off-by: Greg Greenway ggreenway@apple.com

Commit Message: This enables the new behavior (clean up conn pools when they're idle, to avoid leaking memory in some configurations) from #17403 by default. It can still be disabled by setting runtime feature envoy.reloadable_features.conn_pool_delete_when_idle to false.
Additional Description:
Risk Level: Medium
Testing: Test coverage was added in #17403.
Docs Changes:
Release Notes: Added in #17403
Platform Specific Features:
[Optional Runtime guard:]
[Optional Fixes #Issue]
[Optional Deprecated:]
[Optional API Considerations:]

have we smoke tested somewhere yet?

have we smoke tested somewhere yet?

It's still the same code (minus one possible crash when a cluster is removed via CDS) that @rgs1 smoke tested awhile ago.

have we smoke tested somewhere yet?

It's still the same code (minus one possible crash when a cluster is removed via CDS) that @rgs1 smoke tested awhile ago.

... tested with the new tcp conn pool, whereas the additional crashers were with the old pool fwiw ...

Ah cool, didn't realize the prior version had been canaried.
Just to check my memory, the folks encountering tcp proxy crashes didn't provide additional data, and agreed they should switch back to the new pool in any case right?  If so LGTM-as-long-as-you-cc-them because it's as safe as it's going to get (folks shouldn't be using the old pool without informing us the new one is problematic)

@bianpengyuan FYI this change, that you reported a crash in #16948, is being reintroduced.
Looking at that report again, it's very possible that it was the same crash fixed in #17522. Not enough information to know for sure, but it's a possible match, so it may be fixed.

coverage test flake; unrelated:
2021-08-03T20:04:16.6349000Z test/extensions/transport_sockets/starttls/starttls_integration_test.cc:329: Failure
2021-08-03T20:04:16.6350199Z Value of: test_server_->server().listenerManager().numConnections()
2021-08-03T20:04:16.6350878Z Expected: is equal to 1
2021-08-03T20:04:16.6351556Z   Actual: 0 (of type unsigned long)
2021-08-03T20:04:16.6352267Z Stack trace:
2021-08-03T20:04:16.6352891Z   0x454827: (unknown)
2021-08-03T20:04:16.6353611Z   0x7f6ad1696d96: testing::internal::HandleSehExceptionsInMethodIfSupported<>()
2021-08-03T20:04:16.6354475Z   0x7f6ad167b701: testing::internal::HandleExceptionsInMethodIfSupported<>()
2021-08-03T20:04:16.6355200Z   0x7f6ad1663042: testing::Test::Run()
2021-08-03T20:04:16.6355864Z   0x7f6ad1663b58: testing::TestInfo::Run()
2021-08-03T20:04:16.6356462Z ... Google Test internal frames ...```

/retest

/retest

authors: alyssawilk ggreenway rgs1


text:
reformat dynamic metadata emitted by Mongo proxy

Description: Emit metadata as map<resource, list(operations> so that it can be used in metadata matchers easily. The existing format (messages:list(structs)) is too hard to represent in metadata matchers.
Risk Level: LOW
Testing: Unit tests
Signed-off-by: Shriram Rajagopalan shriramr@vmware.com
cc @venilnoronha

@dio the PR that implemented this was merged yesterday :). So users have not seen this stuff yet. So version history doesn't exist..


text:
Global downstream connection limits.

Add a overload manager configuration to limit the total number of downstream connections
https://www.envoyproxy.io/docs/envoy/latest/configuration/operations/overload_manager/overload_manager#limiting-active-connections

It appears that the functionality is incomplete and unsuitable for production use. Should we enable it?

@tmsnan im fine waiting, but atm we dont have any way of enabling overload manager

@arkodg  If possible, I could first add other overload manager features that are already fully supported.

@tmsnan sure, imo the others like heap size based will require an API addition, putting the burden of getting it right on the user .
Was trying to use this GH issue to enable sensible defaults

@arkodg Maybe we can refer to Google VRP edge server configuration.
`overload_manager:
refresh_interval: 0.25s
resource_monitors:

name: "envoy.resource_monitors.fixed_heap"
typed_config:
"@type": type.googleapis.com/envoy.extensions.resource_monitors.fixed_heap.v3.FixedHeapConfig
TODO: Tune for your system.
max_heap_size_bytes: 2147483648  # 2 GiB
actions:
name: "envoy.overload_actions.shrink_heap"
triggers:

name: "envoy.resource_monitors.fixed_heap"
threshold:
value: 0.95

name: "envoy.overload_actions.stop_accepting_requests"
triggers:

name: "envoy.resource_monitors.fixed_heap"
threshold:
value: 0.98`
https://www.envoyproxy.io/docs/envoy/latest/configuration/best_practices/edge#best-practices-edge

Please assign me

authors: arkodg shahar-h tmsnan

repo: envoyproxy/gateway