Test "server ready" feature in integrated terminal

Test for #69898:

[ ] macOS @auchenberg
[x] linux @joaomoreno
[ ] windows @jrieken

Complexity: 3
For a description of the feature, please see https://github.com/Microsoft/vscode/issues/69311#issue-413837459.
In this milestone we've added support for detecting the trigger message in the integrated terminal (in addition to the debug console supported last milestone).
And we improved the error message if  the "Debugger for Chrome" is not installed if a user configures the "server ready" feature to start a browser debug session.
Verify that....

it works out of the box for a node.js "express" application both for openExternally and debugWithChrome actions (see https://code.visualstudio.com/docs/nodejs/nodejs-tutorial#_an-express-application for how to create an express app)
create a simple server application in another language (e.g. C# or Python, etc.) and configure the "pattern" and "uriFormat" properties to match the trigger message.
use intellisense to configure the "server ready" feature to start a browser debug session. Verify that an error dialog is shown if the "Debugger for Chrome" is not installed.

Unable to test this with express-app-sample...

Was able to test this with a regular server:
const http = require('http');

const port = 3001;
const app = http.createServer((req, res) => {
  res.write('Hello world!');
  res.end();
});

app.listen(port);
console.log(`server listening at port ${port}`);

Even cooler, after installing the Debugger for Chrome, I tested this one, which opens Chrome on start and breaks on that client side breakpoint.
const http = require('http');

const port = 3001;
const app = http.createServer((req, res) => {
  res.write(`<script>debugger;</script>`);
  res.end();
});

app.listen(port);
console.log(`server listening at port ${port}`);

The default app generated by the express generator has changed and does not spit out the Listening on port 3000 message any more.
This can be easily fixed:

open "bin/win"
add console.log('Listening on port ' + bind) at the end of the onListening()function:

function onListening() {
  var addr = server.address();
  var bind = typeof addr === 'string'
    ? 'pipe ' + addr
    : 'port ' + addr.port;
  debug('Listening on ' + bind);
  console.log('Listening on port ' + bind);
}

I understand console.log I think what blocks me is that in 9 out of 10 cases debugging just doesn't work for me. Spinning forever not signs of launching

I'm already looking into this issue on Windows....

I'm not able to reproduce node.js debugging issues on Windows.
I tried with node.js 10.2 and 10.15

let debug on my machine then

This seems very flaky (and silent to me). I need a couple of restarts of my VM for debugging to work reliably. Opening firefox only worked after the 5th try, it was likely installing an update, but I had no clue what's going on

Validated all steps using my https://github.com/auchenberg/nodejs-shopping-cart on MacOS with no problems.
I agree with https://github.com/Microsoft/vscode/issues/69311 and https://github.com/Microsoft/vscode/issues/71177, it would be great to have a some logging that also outputs if the pattern doesn't match anything.

It will be difficult to log if the pattern doesn't match anything.
The program output that gets scraped appears at any time while the program runs.
When do we know that the pattern will not match anything?

It's more in the configuration phase, where you don't know whether your regex is working or not, but you could argue that's a generel regex problem ;)


Simplify skipCleanupOnError test flag

The flag skipCleanupOnError defaulted to false, meaning it would cleanup
test resources in the event of a failure. In the Makefile target for e2e
tests, we override -skipCleanupOnError with true, so we keep resources
when a test fails.
Depending on if you're running the tests using make e2e or directly
using go test you'd get different behavior.
This commit renames the variable to be more affimative by removing
skip from the name (skipCleanupOnError actually means
cleanupOnError=false). It also converges the default in the test runner
to be the same as the default in the Makefile, allowing for consistent
behavior regardless of how you invoke the tests. It also adds more help
text to clarify the behavior.

/retest

Rebased to resolve merge conflict.


integration tests locally

Describe your changes

Add python -m sql._testing to start testing containers - postgres, mysql, mariadb
Change the integration testing with docker context level, something like:

#conftest.py
import pytest
from sql import _testing

@pytest.fixture
def setup_postgres():
    with _testing.postgres():
        yield

Preview
Start python -m sql._testing and CTRL-C
https://user-images.githubusercontent.com/123580782/226957366-3d352c1b-43d1-4ede-a809-60ec065fc832.mov
Issue ticket number and link
Closes #248
Checklist before requesting a review

[ ] I have performed a self-review of my code
[ ] I have added thorough tests (when necessary).
[ ] I have added the right documentation in the docstring and changelog (when needed)

:books: Documentation preview :books:: https://jupysql--281.org.readthedocs.build/en/281/

@edublancas
To run integration testing on local, we still need the developer to get docker on the environment. Where do you think we should document it?


Mark notification as read after user click's(views detail of the notification)

Summary:
Currently notifications are marked as read only after the user swipe's to delete them. While if the user clicks on the notification and then returns back notification's are not marked as read.
Steps to reproduce:

Go to notification activity
Click on the notification
Notification detail activity opens
Press back button to return to same activity

Notification was't marked as read although it was supposed to be marked as read
Device and Android version:
Vivo 1713 API level 24
Commons app version:
Latest master
Would you like to work on the issue?
Yes

@vanshikaarora I think it is better to have the notifications color to be changed (decreased intensity) when the user reads the notification and comes back since the user might not want to archive them.

@vanshikaarora I think it is better to have the notifications color to be changed (decreased intensity) when the user reads the notification and comes back since the user might not want to archive them.

I think that's a good suggestion. But before working I would love to hear opinion of other mentors @nicolas-raoul @maskaravivek @misaochan @neslihanturan Please pitch in your suggestions :)

No opinion, as notifications are not showing up for me recently (I will fill an issue as soon as possible).

@maskaravivek @ujjwalagrawal17 Can you please share your opinion :)

@vanshikaarora I think it can be done in 2 ways.
A. the notifications can be divided into 2 groups - new, read. (Then we only need to mark the notification as read when we click them).
B. the notifications can be divided into 3 groups- new, read, archived. We can divide the notifications in 2 groups (new/read) and all the new notifications should above above read ones. Similar to this:

@ujjwalagrawal17 I prefer the option B. There can be three categories with the category new being highlighted. And for the read notification I agree with creating a swipe to archive feature instead of swipe to read.
@maskaravivek @nicolas-raoul @albendz Please share your opinion :)

Notifications are not showing for me as well (neither unread nor read ones). :/
Personally, I would prefer option A because of its simplicity.

If we are going with this flow then we can assume when the user clicks on the notification, he/she read it.

We can probably listen for web view loaded event and mark the notification as read, only after the page loads completely.
If we go with option B, then we will introduce something called archived notifications. Mediawiki API doesn't support archived notifications. You can just mark a notification as read. So if we go ahead with B, we can just store these notifications locally and once the user reinstalls the app then he will have to archive it again.
It would be nice to have @misaochan @neslihanturan @ashishkumar468's opinions too.

So if we go ahead with B, we can just store these notifications locally and once the user reinstalls the app then he will have to archive it again.

Looking upon the problems we have with API i think option A would be a better choice.
@nicolas-raoul @domdomegg @misaochan @neslihanturan Can you please share your opinion here :)

I'd prefer option A for the same reasons as @maskaravivek

Since option A seems preferable. Here is how we can implement it:

Create a section for new notifications (no section in case of no notifications)
Clicking on any of them means the user has marked the notification as read
I am not sure whether we are going to remove the swipe to delete feature or not (yet to be decided)

I am working on the above two features as of now.
Third point still needs opinion of the mentors @nicolas-raoul @maskaravivek @domdomegg @ujjwalagrawal17 . Please  share your opinion :)

I think remove swipe to delete

I also think we should remove swipe to read.


[Bug] mlc_llm generates randomly corrupted Unicode character when outputting Chinese

🐛 Bug

To Reproduce
Steps to reproduce the behavior:

Install latest mlc-llm and mlc-ai in conda with python 3.12, running on an Apple Silicon (M1 Pro) MacBook Pro with 32 GiB of RAM
Download Qwen-2-7b-MLC Model from https://huggingface.co/mlc-ai/Qwen2-7B-Instruct-q4f16_1-MLC (Other LLMs can also reproduce this issue)
Using mlc_llm serve Qwen2-7B-Instruct-q4f16_1-MLC --host <IP_ADDRESS> to run the server (mlc_llm chat can also reproduce this issue)
In any application that can produce many outputs (for example immersive translate working with OpenAI compatible API), I can see the following result, which contains many corrupted Chinese character.

When I use a Linux server with Nvidia L20 GPU, by using the same model, same application, same prompt, I could also reproduce this issue, but not as frequently as MacBook does.

Expected behavior
There should not have corrupted Unicode character when outputting Chinese, which is frustrating, makes me frequently guess what the word should be.

It appeared again when I tried to translate this issue XD

It seems like the corruption often occurred at the first Chinese character after a non-Chinese character, is tokenizers to be the cause?

Hi @LuRenJiasWorld, sorry for the delayed response. Do you mind providing a Python script that runs with MLCEngine and we can use to reproduce? That will be very helpful for identifying the problem.

facing same issue

My best guess is tokenizer.decode inside tvm has some issues

@MasterJH5574
I can reproduce with:
mlc_llm serve HF://mlc-ai/Qwen2.5-32B-Instruct-q4f16_1-MLC  --host <IP_ADDRESS>

and
query with
system: You are a helpful assistant. You can help me by answering my questions. You can also ask me questions.
user: 用遗造句，每句一个编号

Hi @LuRenJiasWorld @samuelqy @bojiang, we fixed this issue in https://github.com/mlc-ai/mlc-llm/pull/2978. It will be merged soon and will be ready in the nightly prebuilt package by tomorrow. Please upgrade the pip package and try again, thanks! And please also let us know if there are further issues.

Great work! Thanks!

Nice work!


Added button idea

added button idea.

Issue:

Hi @reveurguy your repository is way behind and the format of BUTTON_IDEAS.md has changed so can you merge the changes from master first then add your idea?

ok, didn't see that.


A PDF file is showing vertical lines on a page and the content on the page is lost while rendering on thumbnail view in PDF.js viewer

Attach (recommended) or Link to PDF file here: Attached in the comment section. As the sample document belongs to our customer we can not attach the PDF file directly here.
Configuration:

Web browser and its version: Google Chrome Version 104.0.5112.79

Firefox Version 103.0.2 does not even render the file and shows this error-
PDF.js v2.16.48 (build: ab1297f05)
Message:
Stack: putBinaryImageData@https://mozilla.github.io/pdf.js/build/pdf.js:6867:11
paintInlineImageXObject@https://mozilla.github.io/pdf.js/build/pdf.js:8705:25
paintImageXObject@https://mozilla.github.io/pdf.js/build/pdf.js:8656:10
executeOperatorList@https://mozilla.github.io/pdf.js/build/pdf.js:7191:20
_next@https://mozilla.github.io/pdf.js/build/pdf.js:4254:37
webpack_modules</_scheduleNext/<@https://mozilla.github.io/pdf.js/build/pdf.js:4242:14

Operating system and its version: Windows (Not specific to OS)
PDF.js version: 2.16.48
Is a browser extension: No

Steps to reproduce the problem:

Open the PDF file in pdf.js viewer - https://mozilla.github.io/pdf.js/web/viewer.html
Click to show thumbnails view and scroll down to page number 9. You will see the page contains vertical lines and it's content is lost.

What is the expected behavior? (add screenshot)
: Content should be visible/rendered properly in the thumbnail view.
What went wrong? (add screenshot)
: Vertical lines appear on the page and the page content is lost while rendering in the thumbnail view. Please refer to the screenshot here-

Link to a viewer (if hosted on a site other than mozilla.github.io/pdf.js or as Firefox/Chrome extension):

40016810713_v1.pdf
sample file

Duplicate of #12307


Containerise Development Environment

Background
Our Makefile assumes user having a JVM development environment setup. Although this is a JVM library, so it's safe to assume whoever trying to run this project is trying to contribute as this is a framework, not a standalone service. However, It doesn't harm to containerise the development environment to make it easier for contributes from all environments/backgrounds contribute to the project.
Requirements

[x] Use Gradle's jdk17-alpine image.
[x] To use latest Gradle image, you will need: #66
[x] Toolchain should cache runs by mounting the .m2 and .gradle volumes
[x] Toolchain should write to host's output directory  (i.e. mount to project's build directory)
[x] Teardown toolchain container after each run (i.e. --rm)
[x] Project's CI should still use the same MakeFile recipes. (i.e. DIND)
[x] Only Docker should be needed to run the tests.

Also see: (For builds)

Docker - Dedicated Cache
Docker - GitHub Actions Cache
Docker - Local Caching

After a tremendous amount of delay due putting my full-time job, I have finally made the time to complete this beauty. Happy to share we now have a fully containerised development environment that caches perfectly okay in CI and locally with the same level of consistency.
You got docker? Then you can contribute to our project without having to install anything else 🙂


re add docs.kieranrobson.com

this PR reverts 2717cb096115c500879074ec38e6d3bbe3f046a4, all of @KieranRobson's sites are back up and functioning :smile:

That's not right... Git is playing up

It seems like my last PR (#6) added the site back, that explains the confusion. will close


the app stopped work for me today.. i'm on windows 11

What happened?
The software simply does not open even after uninstalling and reinstalling
Steps to reproduce

step one...
step two...

What OS are you seeing the problem on?
No response
Relevant log output
No response

Same

Can you try to install the latest version?
I did many fixes
Install the exe file from
https://github.com/thewh1teagle/vibe/releases/latest

Same pb here . Windows 11 23H2, latest vibe release. Vibe did not launch no error reported

See https://github.com/thewh1teagle/vibe/blob/main/docs/DEBUG.md

I can reproduce the problem and solution!
For the latter:

Vibe must be killed (e.g., w/ Task Manager).
Microsoft WebView must be installed.
Then opening Vibe works just fine!

See https://github.com/thewh1teagle/vibe/issues/370


Feature/lit 3125 sdk for wrapping up walletx

Description
Please include a summary of the changes and the related issue. Please also include relevant motivation and context. List any dependencies that are required for this change.
Type of change

[ ] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
[ ] This change requires a documentation update

How Has This Been Tested?
Please describe the tests that you ran to verify your changes. Provide instructions so we can reproduce. Please also list any relevant details for your test configuration

[ ] Test A
[ ] Test B

Checklist:

[ ] My code follows the style guidelines of this project
[ ] I have performed a self-review of my code
[ ] I have commented my code, particularly in hard-to-understand areas
[ ] I have made corresponding changes to the documentation
[ ] My changes generate no new warnings
[ ] I have added tests that prove my fix is effective or that my feature works
[ ] New and existing unit tests pass locally with my changes
[ ] Any dependent changes have been merged and published in downstream modules

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you all sign our Contributor License Agreement before we can accept your contribution.2 out of 3 committers have signed the CLA.:white_check_mark: Ansonhkg:white_check_mark: joshLong145:x: DashKash54You have signed the CLA already but the status is still pending? Let us recheck it.


Speculatively install lab extension alongside nbcelltests?

I believe installation is just copying to "share". Then when lab is next started, it will request to do a re-build.
If lab is not installed, it just uses up some disk space.
Would avoid separate lab extension installation step.

From setup.py, looks like this is actually done already. Just need to check it works.

might need to update the paths for the js folder


Prepare 1.4.0-rc.0 release

Move beta release notes and update version

Updated
Latest test generation https://gist.github.com/dmcgowan/74e0b9fd6d1c93da2a954ee8e5c6894f


YAML editor component

YAML editor is sync with all channels and packages added from the UI. We are missing to sync the other side, all changes made from the YAML should appear in the UI components too.

The logic implemented here was moved to this branch in order to keep working on creating a new env implementation.


Test for overriding with different symbol name

This test highlights the bug that is the blocker for #254 .
I believe this test needs to pass regardless of how issues #225 and #230 are solved.
Edit: Note that travis is supposed to fail on this PR until the underlying issue is fixed.

Closing this as test was already incorporated in #257


connecting to internet

i downlaod hyper-pana twice and after that when turn on pc , i have ping(even give ping form google ) but all my browser dosn't work

issue in windows for connecting after install


The primevue resolver needs to be updated for PrimeVue v4.

Describe the bug
src/core/resolvers/prime-vue.ts doesn't have ToggleSwitch in there. It only references InputSwitch which is the old name. There are probably other changes required to support v4
Reproduction
add import { PrimeVueResolver } from 'unplugin-vue-components/resolvers' to vite.config and register it as a plugin. All the components that were in v3 are picked up fine, but ToggleSwitch was not picked up because it was renamed from InputSwitch.
System Info
System:
    OS: macOS 14.4.1
    CPU: (10) arm64 Apple M2 Pro
    Memory: 101.77 MB / 16.00 GB
    Shell: 5.9 - /bin/zsh
  Binaries:
    Node: 22.2.0 - ~/.nvm/versions/node/v22.2.0/bin/node
    Yarn: 1.22.22 - ~/.nvm/versions/node/v22.2.0/bin/yarn
    npm: 10.8.0 - ~/.nvm/versions/node/v22.2.0/bin/npm
  Browsers:
    Chrome: 126.0.6478.126
    Safari: 17.4.1

Used Package Manager
npm
Validations

[X] Follow our Code of Conduct
[X] Read the Contributing Guide.
[X] Check that there isn't already an issue that reports the same bug to avoid creating a duplicate.
[X] Check that this is a concrete bug. For Q&A, please open a GitHub Discussion instead.
[X] The provided reproduction is a minimal reproducible of the bug.

I guess you need another primevue resolver.
As doc follows
import { PrimeVueResolver } from '@primevue/auto-import-resolver'

Ah, thanks for that - I have switched over and it seems to be doing the right thing.


Removing BuildCommDCB for support on Windows 10 IoT Core

This change enables serialport to be used on devices running Windows 10 IoT Core (see http://ms-iot.github.io/content/en-US/GetStarted.htm). It’s a minor change to remove the call to BuildCommDCB which isn’t supported in Windows 10 IoT Core. Instead the DCB structure is populated 'manually' with the arguments that were passed to BuildCommDCB.
This is part of the work being done to bring Node.js to Windows 10 IoT Core. Background information can be found here - http://blogs.windows.com/buildingapps/2015/05/12/bringing-node-js-to-windows-10-iot-core/. [Edit: Previous link pointed to the wrong page]

Thanks @reconbot. I'm also waiting on a response to the thread below. I'd like to know how I can help with setting up hardware at Microsoft for CI - https://github.com/nodejs/hardware/issues/13#issuecomment-129606036

@munyirik yes, I've been in talks with Dan and Arunesh on this and I think we are having some progress


VIM-862 | Allow an optional Ex range for :action input

ActionHandler does not allow Ex ranges with its input, which leads to VIM-862 -- ranges given to an :action mapping are ignored. This branch changes ActionHandler to allow an optional range.

Thanks for your pull request! I'll review it soon.

This seems to work for character ranges on the same line, but not multi-line ranges. I think I'll have to go deeper.

I'm going to work on this more and submit another PR soon.


fix: No history message attached when for gemini-pro-vision

选中gemini-pro-vision的时候，会强制将当前对话设置中附带历史消息为0，这样就不会出现错误：Multiturn chat is not enabled for models/gemini-pro-vision

No, the reason is that gemini-pro-vision currently does not support multi-chat like gpt-4-vision-preview does. It might be available in the future, so it's better to maintain the current state rather than refactoring.


septentrio_gnss_driver: 1.2.3-1 in 'foxy/distribution.yaml' [bloom]

Increasing version of package(s) in repository septentrio_gnss_driver to 1.2.3-1:

upstream repository: https://github.com/septentrio-gnss/septentrio_gnss_driver
release repository: https://github.com/septentrio-users/septentrio_gnss_driver_ros2-release.git
distro file: foxy/distribution.yaml
bloom version: 0.11.1
previous version for package: 1.2.2-2

septentrio_gnss_driver
* New Features

  Twist output option

  Example config files for GNSS and INS

  Get leap seconds from receiver

  Firmware check

  VSM from odometry or twist ROS messages

  Add receiver type in case INS is used in GNSS mode

  Add publishing of base vector topics
* Improvements

  Rework RTK corrections parameters and improve flexibility
* Fixes

  /tf not being published without /localization

  Twist covariance matrix of localization

  Support 5 ms period for IMU explicitly

Holding for sync


Implement logic to find old 4 year old E-needs-mcve issues to close

This is the first commit in a series of commits to implement the automatic triaging of old E-needs-mcve issues that was proposed and discussed in t-release/triage and cross-posted to T-compiler. I have included the accepted (read: not objected) proposal below for the convenience of code reviewers.
This commit only implements the logic to find what the issues to close, and prints that info to stdout for inspection. Think of it as a dry run.
After we have convinced ourselves this logic works as it should, we can implement the final steps:

Actually close the issue
Report closes to a "triagebot closed issues" topic in the "t-release/triage" Zulip

Current output of program
https://github.com/rust-lang/rust/issues/117059 will be closed after 47 months
https://github.com/rust-lang/rust/issues/107440 will be closed after 47 months
https://github.com/rust-lang/rust/issues/114252 will be closed after 47 months
https://github.com/rust-lang/rust/issues/116091 will be closed after 47 months
https://github.com/rust-lang/rust/issues/86551 will be closed after 47 months
https://github.com/rust-lang/rust/issues/117077 will be closed after 47 months
https://github.com/rust-lang/rust/issues/89361 will be closed after 47 months
https://github.com/rust-lang/rust/issues/83291 will be closed after 47 months
https://github.com/rust-lang/rust/issues/97344 will be closed after 47 months
https://github.com/rust-lang/rust/issues/88891 will be closed after 47 months
https://github.com/rust-lang/rust/issues/90738 will be closed after 47 months
https://github.com/rust-lang/rust/issues/88912 will be closed after 47 months
https://github.com/rust-lang/rust/issues/89178 will be closed after 47 months
https://github.com/rust-lang/rust/issues/116914 will be closed after 47 months
https://github.com/rust-lang/rust/issues/115750 will be closed after 47 months
https://github.com/rust-lang/rust/issues/102196 will be closed after 47 months
https://github.com/rust-lang/rust/issues/32611 will be closed after 47 months
https://github.com/rust-lang/rust/issues/67427 will be closed after 47 months
https://github.com/rust-lang/rust/issues/116953 will be closed after 47 months
https://github.com/rust-lang/rust/issues/27970 will be closed after 47 months
https://github.com/rust-lang/rust/issues/114731 will be closed after 47 months
https://github.com/rust-lang/rust/issues/116255 will be closed after 47 months
https://github.com/rust-lang/rust/issues/116547 will be closed after 47 months
https://github.com/rust-lang/rust/issues/116394 will be closed after 47 months
https://github.com/rust-lang/rust/issues/116638 will be closed after 47 months
https://github.com/rust-lang/rust/issues/76507 will be closed after 47 months
https://github.com/rust-lang/rust/issues/68015 will be closed after 47 months
https://github.com/rust-lang/rust/issues/64718 will be closed after 47 months
https://github.com/rust-lang/rust/issues/52652 will be closed after 47 months
https://github.com/rust-lang/rust/issues/43241 will be closed after 47 months
https://github.com/rust-lang/rust/issues/116373 will be closed after 47 months
https://github.com/rust-lang/rust/issues/116539 will be closed after 46 months
https://github.com/rust-lang/rust/issues/116462 will be closed after 46 months
https://github.com/rust-lang/rust/issues/112286 will be closed after 46 months
https://github.com/rust-lang/rust/issues/115430 will be closed after 46 months
https://github.com/rust-lang/rust/issues/48409 will be closed after 46 months
https://github.com/rust-lang/rust/issues/115552 will be closed after 46 months
https://github.com/rust-lang/rust/issues/115658 will be closed after 46 months
https://github.com/rust-lang/rust/issues/66003 will be closed after 46 months
https://github.com/rust-lang/rust/issues/113069 will be closed after 46 months
https://github.com/rust-lang/rust/issues/46695 will be closed after 46 months
https://github.com/rust-lang/rust/issues/46019 will be closed after 46 months
https://github.com/rust-lang/rust/issues/97726 will be closed after 46 months
https://github.com/rust-lang/rust/issues/116026 will be closed after 46 months
https://github.com/rust-lang/rust/issues/116023 will be closed after 46 months
https://github.com/rust-lang/rust/issues/115896 will be closed after 46 months
https://github.com/rust-lang/rust/issues/114325 will be closed after 46 months
https://github.com/rust-lang/rust/issues/43349 will be closed after 46 months
https://github.com/rust-lang/rust/issues/115497 will be closed after 46 months
https://github.com/rust-lang/rust/issues/36749 will be closed after 46 months
https://github.com/rust-lang/rust/issues/108762 will be closed after 46 months
https://github.com/rust-lang/rust/issues/37077 will be closed after 46 months
https://github.com/rust-lang/rust/issues/83126 will be closed after 45 months
https://github.com/rust-lang/rust/issues/115525 will be closed after 45 months
https://github.com/rust-lang/rust/issues/115556 will be closed after 45 months
https://github.com/rust-lang/rust/issues/115036 will be closed after 45 months
https://github.com/rust-lang/rust/issues/115495 will be closed after 45 months
https://github.com/rust-lang/rust/issues/75662 will be closed after 45 months
https://github.com/rust-lang/rust/issues/114891 will be closed after 45 months
https://github.com/rust-lang/rust/issues/115349 will be closed after 45 months
https://github.com/rust-lang/rust/issues/48700 will be closed after 45 months
https://github.com/rust-lang/rust/issues/115145 will be closed after 45 months
https://github.com/rust-lang/rust/issues/112785 will be closed after 45 months
https://github.com/rust-lang/rust/issues/87898 will be closed after 45 months
https://github.com/rust-lang/rust/issues/98746 will be closed after 45 months
https://github.com/rust-lang/rust/issues/81524 will be closed after 45 months
https://github.com/rust-lang/rust/issues/114640 will be closed after 45 months
https://github.com/rust-lang/rust/issues/114218 will be closed after 44 months
https://github.com/rust-lang/rust/issues/111513 will be closed after 44 months
https://github.com/rust-lang/rust/issues/114540 will be closed after 44 months
https://github.com/rust-lang/rust/issues/114137 will be closed after 44 months
https://github.com/rust-lang/rust/issues/114163 will be closed after 44 months
https://github.com/rust-lang/rust/issues/56784 will be closed after 44 months
https://github.com/rust-lang/rust/issues/109879 will be closed after 44 months
https://github.com/rust-lang/rust/issues/55411 will be closed after 44 months
https://github.com/rust-lang/rust/issues/35144 will be closed after 44 months
https://github.com/rust-lang/rust/issues/62174 will be closed after 44 months
https://github.com/rust-lang/rust/issues/113305 will be closed after 44 months
https://github.com/rust-lang/rust/issues/44850 will be closed after 44 months
https://github.com/rust-lang/rust/issues/60725 will be closed after 44 months
https://github.com/rust-lang/rust/issues/109711 will be closed after 44 months
https://github.com/rust-lang/rust/issues/113612 will be closed after 44 months
https://github.com/rust-lang/rust/issues/113290 will be closed after 43 months
https://github.com/rust-lang/rust/issues/102952 will be closed after 43 months
https://github.com/rust-lang/rust/issues/113179 will be closed after 43 months
https://github.com/rust-lang/rust/issues/94201 will be closed after 43 months
https://github.com/rust-lang/rust/issues/111511 will be closed after 43 months
https://github.com/rust-lang/rust/issues/112436 will be closed after 43 months
https://github.com/rust-lang/rust/issues/112576 will be closed after 43 months
https://github.com/rust-lang/rust/issues/112187 will be closed after 42 months
https://github.com/rust-lang/rust/issues/111576 will be closed after 42 months
https://github.com/rust-lang/rust/issues/81381 will be closed after 42 months
https://github.com/rust-lang/rust/issues/89295 will be closed after 41 months
https://github.com/rust-lang/rust/issues/74919 will be closed after 41 months
https://github.com/rust-lang/rust/issues/100639 will be closed after 41 months
https://github.com/rust-lang/rust/issues/97776 will be closed after 41 months
https://github.com/rust-lang/rust/issues/63645 will be closed after 41 months
https://github.com/rust-lang/rust/issues/94232 will be closed after 40 months
https://github.com/rust-lang/rust/issues/94758 will be closed after 40 months
https://github.com/rust-lang/rust/issues/109955 will be closed after 40 months
https://github.com/rust-lang/rust/issues/109344 will be closed after 40 months
https://github.com/rust-lang/rust/issues/109530 will be closed after 40 months
https://github.com/rust-lang/rust/issues/109329 will be closed after 40 months
https://github.com/rust-lang/rust/issues/104885 will be closed after 40 months
https://github.com/rust-lang/rust/issues/106237 will be closed after 40 months
https://github.com/rust-lang/rust/issues/107613 will be closed after 40 months
https://github.com/rust-lang/rust/issues/107582 will be closed after 40 months
https://github.com/rust-lang/rust/issues/55146 will be closed after 40 months
https://github.com/rust-lang/rust/issues/67373 will be closed after 40 months
https://github.com/rust-lang/rust/issues/89940 will be closed after 39 months
https://github.com/rust-lang/rust/issues/104682 will be closed after 39 months
https://github.com/rust-lang/rust/issues/104257 will be closed after 39 months
https://github.com/rust-lang/rust/issues/108847 will be closed after 39 months
https://github.com/rust-lang/rust/issues/106630 will be closed after 39 months
https://github.com/rust-lang/rust/issues/106490 will be closed after 39 months
https://github.com/rust-lang/rust/issues/97460 will be closed after 39 months
https://github.com/rust-lang/rust/issues/103234 will be closed after 39 months
https://github.com/rust-lang/rust/issues/103373 will be closed after 39 months
https://github.com/rust-lang/rust/issues/108067 will be closed after 39 months
https://github.com/rust-lang/rust/issues/79197 will be closed after 39 months
https://github.com/rust-lang/rust/issues/96857 will be closed after 39 months
https://github.com/rust-lang/rust/issues/99402 will be closed after 39 months
https://github.com/rust-lang/rust/issues/91704 will be closed after 39 months
https://github.com/rust-lang/rust/issues/99218 will be closed after 39 months
https://github.com/rust-lang/rust/issues/95750 will be closed after 39 months
https://github.com/rust-lang/rust/issues/94323 will be closed after 39 months
https://github.com/rust-lang/rust/issues/94204 will be closed after 39 months
https://github.com/rust-lang/rust/issues/94701 will be closed after 39 months
https://github.com/rust-lang/rust/issues/93073 will be closed after 39 months
https://github.com/rust-lang/rust/issues/92491 will be closed after 39 months
https://github.com/rust-lang/rust/issues/72985 will be closed after 39 months
https://github.com/rust-lang/rust/issues/106211 will be closed after 39 months
https://github.com/rust-lang/rust/issues/108331 will be closed after 39 months
https://github.com/rust-lang/rust/issues/106136 will be closed after 39 months
https://github.com/rust-lang/rust/issues/100923 will be closed after 38 months
https://github.com/rust-lang/rust/issues/105822 will be closed after 38 months
https://github.com/rust-lang/rust/issues/96886 will be closed after 38 months
https://github.com/rust-lang/rust/issues/103959 will be closed after 38 months
https://github.com/rust-lang/rust/issues/105112 will be closed after 38 months
https://github.com/rust-lang/rust/issues/106650 will be closed after 38 months
https://github.com/rust-lang/rust/issues/106800 will be closed after 38 months
https://github.com/rust-lang/rust/issues/94651 will be closed after 37 months
https://github.com/rust-lang/rust/issues/102687 will be closed after 37 months
https://github.com/rust-lang/rust/issues/105042 will be closed after 37 months
https://github.com/rust-lang/rust/issues/106119 will be closed after 37 months
https://github.com/rust-lang/rust/issues/106049 will be closed after 37 months
https://github.com/rust-lang/rust/issues/106159 will be closed after 37 months
https://github.com/rust-lang/rust/issues/106492 will be closed after 37 months
https://github.com/rust-lang/rust/issues/104606 will be closed after 37 months
https://github.com/rust-lang/rust/issues/105299 will be closed after 37 months
https://github.com/rust-lang/rust/issues/102668 will be closed after 37 months
https://github.com/rust-lang/rust/issues/100142 will be closed after 37 months
https://github.com/rust-lang/rust/issues/92976 will be closed after 37 months
https://github.com/rust-lang/rust/issues/86712 will be closed after 37 months
https://github.com/rust-lang/rust/issues/67497 will be closed after 37 months
https://github.com/rust-lang/rust/issues/100715 will be closed after 37 months
https://github.com/rust-lang/rust/issues/102039 will be closed after 37 months
https://github.com/rust-lang/rust/issues/105312 will be closed after 37 months
https://github.com/rust-lang/rust/issues/93123 will be closed after 37 months
https://github.com/rust-lang/rust/issues/105781 will be closed after 37 months
https://github.com/rust-lang/rust/issues/66916 will be closed after 37 months
https://github.com/rust-lang/rust/issues/102217 will be closed after 36 months
https://github.com/rust-lang/rust/issues/102749 will be closed after 36 months
https://github.com/rust-lang/rust/issues/74657 will be closed after 36 months
https://github.com/rust-lang/rust/issues/105211 will be closed after 36 months
https://github.com/rust-lang/rust/issues/80951 will be closed after 36 months
https://github.com/rust-lang/rust/issues/96320 will be closed after 36 months
https://github.com/rust-lang/rust/issues/105057 will be closed after 36 months
https://github.com/rust-lang/rust/issues/104876 will be closed after 36 months
https://github.com/rust-lang/rust/issues/102887 will be closed after 34 months
https://github.com/rust-lang/rust/issues/101694 will be closed after 33 months
https://github.com/rust-lang/rust/issues/96526 will be closed after 33 months
https://github.com/rust-lang/rust/issues/99503 will be closed after 33 months
https://github.com/rust-lang/rust/issues/99537 will be closed after 33 months
https://github.com/rust-lang/rust/issues/98339 will be closed after 33 months
https://github.com/rust-lang/rust/issues/95679 will be closed after 31 months
https://github.com/rust-lang/rust/issues/98902 will be closed after 31 months
https://github.com/rust-lang/rust/issues/98648 will be closed after 31 months
https://github.com/rust-lang/rust/issues/95409 will be closed after 30 months
https://github.com/rust-lang/rust/issues/88975 will be closed after 29 months
https://github.com/rust-lang/rust/issues/84491 will be closed after 29 months
https://github.com/rust-lang/rust/issues/90594 will be closed after 29 months
https://github.com/rust-lang/rust/issues/96219 will be closed after 29 months
https://github.com/rust-lang/rust/issues/95946 will be closed after 28 months
https://github.com/rust-lang/rust/issues/91809 will be closed after 27 months
https://github.com/rust-lang/rust/issues/93701 will be closed after 26 months
https://github.com/rust-lang/rust/issues/79657 will be closed after 26 months
https://github.com/rust-lang/rust/issues/90158 will be closed after 25 months
https://github.com/rust-lang/rust/issues/92180 will be closed after 25 months
https://github.com/rust-lang/rust/issues/74551 will be closed after 24 months
https://github.com/rust-lang/rust/issues/83742 will be closed after 24 months
https://github.com/rust-lang/rust/issues/89872 will be closed after 24 months
https://github.com/rust-lang/rust/issues/91011 will be closed after 24 months
https://github.com/rust-lang/rust/issues/81614 will be closed after 23 months
https://github.com/rust-lang/rust/issues/89197 will be closed after 23 months
https://github.com/rust-lang/rust/issues/81612 will be closed after 23 months
https://github.com/rust-lang/rust/issues/81139 will be closed after 23 months
https://github.com/rust-lang/rust/issues/59705 will be closed after 22 months
https://github.com/rust-lang/rust/issues/89751 will be closed after 22 months
https://github.com/rust-lang/rust/issues/68926 will be closed after 22 months
https://github.com/rust-lang/rust/issues/75577 will be closed after 20 months
https://github.com/rust-lang/rust/issues/85887 will be closed after 19 months
https://github.com/rust-lang/rust/issues/86265 will be closed after 19 months
https://github.com/rust-lang/rust/issues/86508 will be closed after 18 months
https://github.com/rust-lang/rust/issues/86331 will be closed after 18 months
https://github.com/rust-lang/rust/issues/82406 will be closed after 16 months
https://github.com/rust-lang/rust/issues/83685 will be closed after 16 months
https://github.com/rust-lang/rust/issues/76085 will be closed after 15 months
https://github.com/rust-lang/rust/issues/82568 will be closed after 15 months
https://github.com/rust-lang/rust/issues/77907 will be closed after 14 months
https://github.com/rust-lang/rust/issues/47897 will be closed after 14 months
https://github.com/rust-lang/rust/issues/30220 will be closed after 14 months
https://github.com/rust-lang/rust/issues/60304 will be closed after 14 months
https://github.com/rust-lang/rust/issues/79783 will be closed after 13 months
https://github.com/rust-lang/rust/issues/62054 will be closed after 12 months
https://github.com/rust-lang/rust/issues/80198 will be closed after 12 months
https://github.com/rust-lang/rust/issues/78724 will be closed after 12 months
https://github.com/rust-lang/rust/issues/79880 will be closed after 12 months
https://github.com/rust-lang/rust/issues/79647 will be closed after 12 months
https://github.com/rust-lang/rust/issues/71908 will be closed after 11 months
https://github.com/rust-lang/rust/issues/76276 will be closed after 10 months
https://github.com/rust-lang/rust/issues/76770 will be closed after 9 months
https://github.com/rust-lang/rust/issues/75430 will be closed after 9 months
https://github.com/rust-lang/rust/issues/75453 will be closed after 8 months
https://github.com/rust-lang/rust/issues/75131 will be closed after 8 months
https://github.com/rust-lang/rust/issues/74035 will be closed after 7 months
https://github.com/rust-lang/rust/issues/73430 will be closed after 6 months
https://github.com/rust-lang/rust/issues/73429 will be closed after 6 months
https://github.com/rust-lang/rust/issues/71257 will be closed after 6 months
https://github.com/rust-lang/rust/issues/72735 will be closed after 6 months
https://github.com/rust-lang/rust/issues/72313 will be closed after 5 months
https://github.com/rust-lang/rust/issues/69169 will be closed after 5 months
https://github.com/rust-lang/rust/issues/71722 will be closed after 5 months
https://github.com/rust-lang/rust/issues/69195 will be closed after 4 months
https://github.com/rust-lang/rust/issues/70575 will be closed after 4 months
https://github.com/rust-lang/rust/issues/69924 will be closed after 3 months
https://github.com/rust-lang/rust/issues/69472 will be closed after 2 months
https://github.com/rust-lang/rust/issues/68796 will be closed after 2 months
https://github.com/rust-lang/rust/issues/62146 will be closed after 1 months

Accepted Proposal
I would like to propose that triagebot begins to close old E-needs-mcve issues.
Goal
The goal of this proposal is to achieve a net reduction in manual wg-triage work. It shall be less work to manually correct bot mistakes than to manually triage all affected issues.
Heuristics
Under this proposal, triagebot will close issues that

have been labeled E-needs-mcve for more than 4 years,
have had no comments for more than 4 years,
have no label that contains the word "triaged", e.g. AsyncAwait-Triaged.

No such issue currently exist. But one year from now, the bot will have closed this list of issues, averaging at less than 2 issues closed per month.
I have looked at them all, and by my estimation they are all closable by the bot. In two cases (71257, 69169) it looks like E-needs-mcve should be removed, but that's fine. The bot will indirectly help them get removed by bringing this to the attention of a human. (Of course you may remove the labels already now if you wish, now that I brought it up.)
Auditing
To ease auditing, the bot will report all its actions in a Zulip topic called triagebot closed issues in the t-release/triage stream.
Closing comment
The bot makes this comment when closing an issue:

triagebot
Hi and thank you for taking the time to report an issue to the Rust project. This issue has been labelled E-needs-mcve for more than 4 years. To help keep the issue inbox manageable, I will close this issue for now.
If an MCVE is available and E-needs-mcve was no longer applicable, please reopen this issue and remove the E-needs-mcve label by writing a comment containing this line: @rustbot label -E-needs-mcve
In fact, feel free to reopen this issue if you disagree with me for any reason. Also consider reporting it to the triagebot feedback topic in the t-release/triage stream so my heuristics can be improved.

I'd be happy to have triagebot pick a few issues a week meeting this criteria and just posting them to zulip, to "ping" people to look at them.
From there, somebody can look to see if they 1) really have no repro at all (and if so, close) 2) have a repro but no MCVE, and maybe add like a MCVE-triaged label or something to make sure the bot doesn't get around to it (to be removed at some point when we don't need the bot)

I still don't think these issues are an automatic candidate for closing, but I do think they're a great candidate for "hey, these are questionable and probably easy to triage", so I don't think it's worth just outright dropping this!

Triage: I think it makes a lot of sense to turn this into auto-closing of old S-needs-repro issues. Any objections? (If not I'll implement this some time in the future.)
Kudos to everyone involved in getting S-needs-repro in place btw.

I still think it's not a great idea to auto close old issues like that. Would still be very happy to see this as a zulip ping to look at issues (and actually, that logic is useful for other things too, so writing it is useful regardless)

This has slipped down on my prio list, and I don't see myself getting time to resume work on this in the near future unfortunately. I don't like to keep PRs open indefinitely, so I will close this for now.


Add run_with function to load a list of .dyon files as prelude

I often want some functions in the prelude for a scripting environment but don't want to write a loader in Dyon.

Actually, it is easier to control the function table when writing a loader in Dyon. For example, if there is a module used by two other modules, but both uses a third module, you can import the third into the first module to make the function table more cache friendly.
I also often need a loop or something to repeat the overall task of the program, and the loader is the perfect place to do this. So while writing a loader might seem like extra work at first, it often turns out to be useful later.
Closing as I am not whether this should be added.


Release 0.5.0 dont have Count functionality in Elastix.search module

I see count function added into Elastix.search module but release 0.5.0 didnt have that.
When are you planning to release next version?

The next version (0.6.0) should be released in a few days now :)


feat: Adding the new feature Access Control Segmentation

added a new resource Scope
added a new resource Subscope
added a new resource Target
added more methods related to resources above

PR summary

PR Checklist
Please make sure that your PR fulfills the following requirements:

[ ] The commit message follows the Angular Commit Message Guidelines.
[ ] Tests for the changes have been added (for bug fixes / features)
[ ] Docs have been added / updated (for bug fixes / features)

Current vs new behavior

Does this PR introduce a breaking change?

[ ] Yes
[ ] No

Other information

:tada: This PR is included in version 5.5.0 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:


Added info the the README

Reject this if you actually plan to put documentation here.
I'd recommend just putting some overview of the devforum post here, and then making your documentation an actual website, but your choice.

Apologies for the delayed response. This is sort of a weird time to release my library because something unexpected happened in my life. But I do plan to add documentation. For now, I will probably just document the code in more detail and add documentation to the README and dev forum post.
I am working on a website for a brand I am trying to build and will probably give this library its own page on that domain in the future.


icmp serialize: adding payload serialization.

When serializing an ICMP layer the current function allocates 8 bytes of space which only included the id, seq, and type code.
Rather I think it should reserve what it needs to by adding the required 8 bytes and the length of the payload. Then add the payload to the byte array.
I am fairly new to Go so the submitted solution may not be as clean as it could be.
If the payload is not correctly serialized many types of ICMP messages can be dropped or not properly responded to.
If my proposed solution goes against the structure of the library please let me know and I will edit accordingly.

@googlebot I signed it!


mail notifications for releases are send for user with deactivated e-mail

Gitea Version
1.16.1
Git Version
No response
Operating System
No response
How are you running Gitea?
Gitea helm chart
Database
PostgreSQL
Can you reproduce the bug on the Gitea demo site?
No
Log Gist
No response
Description
I have created a (bot) user with a fake e-mail adress but deactivated the e-mail address in the administration settings.
But when I create a release of a project a e-mail notification is send to this user.
Since the user doesn't have a valid mailbox a bounce message is generated
and sent to the mail system administrator.
How can I disable all e-mail notifications for a bot user ?
Screenshots

It seems like that none of the sending mail functions is taking into account if a email address might be de-activated... Marking as bug.

@Gusted Can you please give ma link to the relevant code section ?
I look forward to get this fixed - maybe I can send a pull request.

There too many code paths that eventually lead to sending a mail and many more functions, which uses those function and can access the user/database and can see if a email is inactive. If it was a general function it would be easier, but the code is quite cluttered.


OSGI header Private-Package

I think there is something wrong in MANIFEST.MF generation.
In version 1.0.1 we have this:
Private-Package: org.apache.ibatis.type
Which makes all handlers invisble when running in for example Karaf.
When looking at the POM's (both this one and parent) it seems correct.
In parent we add Private-Package only if the property ${osgi.private} is set and it's not set in this projects pom from what I can see but still we get the header in MANIFEST.MF

I am not familiar with OSGi, so I googled 'osgi private-package'.
These SO Q&As seem to suggest that the 'Private-Package' has no effect at runtime.

http://stackoverflow.com/questions/13514123/what-does-the-private-package-manifest-header-do
http://stackoverflow.com/questions/13878308/whats-the-deal-with-private-packages

How did you verify that the problem is caused by the MANIFEST.MF ?

kuseman is right - without proper Export-Package declarations in MANIFEST.MF, this JAR is not usable in OSGi. Provided merge request with a fix.

Probably it is worth also to put type handlers in some subpackage, like "org.apache.ibatis.type.jsr310", in order to avoid split-package issue with some other bundles providing type handlers. OSGi is very sensitive to split-package issue (https://nirmalsasidharan.wordpress.com/2010/09/02/split-packages-an-osgi-nightmare/).

Fixed by #22 . Thanks for the help, @skapral !
And thank you for the info about the split-package issue, too.
Changing package is a little bit tricky, though.
Because TypeHandlerRegistry has references to the JSR-310 type handlers.
If it is actually causing troubles, we could move these type handlers to MyBatis core (it became possible just recently).
We haven't done it because it could be confusing and there was no good reason to justify it.


Chore/gh docker workflow

Github workflow for docker build
Related Issue/Asana ticket: https://app.asana.com/0/1203949671901133/1208783033988313/f
Short description: Docker container for graph service build.

To see the specific tasks where the Asana app for GitHub is being used, see below:

https://app.asana.com/0/0/1208915525552685

This should be working now; they will all push to a public container ghcr.io/kadena-community/graphql during various CI tasks.

Permissions are fixed, this workflow runs and updates the docker image correctly now.  Ready to merge if that's all it needed.

Also the package is called 'graphql' now, not 'graph'


Requesting clarification on Kiwi build process

Hey there, not filing this issue to start an argument, as I know source code has been a point of contention for a while, I'm just trying to understand how the builds work.
It looks like this repository hasn't been updated in 3 months, but builds continue to be made for the latest versions of Chromium. There was even a build today.
If we look at the Actions for this repository, it seems a bit odd.
https://github.com/kiwibrowser/src.next/actions/runs/6859307693/job/18651412292

The source code is cloned, but no files are actually used for the build.
The only file present in the source code that is referenced directly is args.gn, but the Actions step that refers to it is actually incorrect and can't find the file, then ends up uploading a blank file instead.
Pre-built Chromium APKs are downloaded via rclone from a URL that is censored from the build
These builds are uploaded as-is and not modified by the build at all except for signing them
The step titled Calling buildbot has a hardcoded false condition preventing it from ever running, and would have curl'd ipinfo.io for some reason?

https://github.com/kiwibrowser/src.next/blob/64f705f0f92204892c61ac769d12c21a60e327cf/.github/workflows/build_and_sign_release_apk.yml#L125-L127
It's not clear what exactly what the function of this repository's source code is for these builds, nor is it clear how to actually build the latest version of Kiwi from this repository. But I think some users may find it alarming that a "CI/CD" is pulling pre-built binaries from source inside of an Actions workflow that clones code and then never uses it 😬
I am not finger pointing, but at face value, without any context for how this build infrastructure works, this CI/CD appears to be largely performative, and not really the open source CI/CD build process a casual user might think it is. Not saying it IS trying to be performative, but it currently looks that way. I am trusting that there is a rationale for these decisions.
Has this project moved to a closed-source development process? If yes, can this be clearly stated in the Readme?
If not, is there any information on how to build the latest version of Kiwi from source using this repository?
Thanks for your efforts on this browser!

Hey,
TL;DR: Time is precious and I have limited amount of it but I agree that your vision is better in a pure world.
Kiwi is staying open-source, but expect the GitHub updates to be delayed (but will eventually come), the same way Telegram had such for some time, probably some big clean-up in 2024.
Keep in mind that Kiwi is provided for free and relies on volunteers work.
The long long version (sharing open thoughts):
You are actually quite kind in your approach.
It's a mix of many things.
The buildbot step with ipinfo.io is some left over of a test, likely to see from which datacenter in Azure connections were coming from.
This was to be able to place to binary objects cache as closest to the buildbots as possible.
Regarding the question of the updates of the repo, there is one part technical, one non-tech, and this is a conscious choice.
I just want to share the reasoning behind; I do not say this is the right thing to do, but just a perception of how I see it and the thought process behind.
From a tech-side, building Chromium is super slow and taking lot of space + CPU.
I've tried at some point to go the route you mention, and actually, you can see the steps that have been used for very long time:
https://github.com/kiwibrowser/src (check the workflows)
They perfectly work there, but it has some drawbacks.
My initial vision was to have everything running in GitHub Actions, and I actually had succeeded at some point in the past.
In the past, using that specific workflow, Kiwi had fully transparent build (and was one of the only browser to have end-to-end build), but it had practically no impact (nor positive, nor negative), and at the end, it was a bit sad because it didn't matter so much and nobody actually cared of the efforts (maybe one helpful person noticed in 2 years).
So many many workarounds had to be found (rclone as a cache for .o files) but also some cool magic (like for example, using MacOS workers), and it was cheap and convenient, but it didn't last.
The current setup right now is that I have one big machine, and then I do all the work / experiments then, and then I do a final build (still taking about an hour, because I have to do 4x dev builds + 4x standard builds)

For that reason, it's faster to work on the machine and then eventually sync with the public repo.
At the end I have to take decisions on how I organize my day, and Kiwi still has the place of a fun side-project (though it's a popular one I agree).
I do not have infinite time to work on Kiwi (I need to work on other projects to pay for my everyday life), and I do not have infinite ressources allocated to Kiwi either (and this is a side-consequence of... being ethical, being ethical means no money, because you don't sell data of the users, you don't push crypto, etc.);
I could potentially hire, but I have somehow little hope on the open-source community to spontaneously engage and come to work for free.
It's already very difficult to find skilled people for Chromium projects, so now imagine volunteers that would give hours and hours for free are even a more rare animal (and I am one of such, I gave away literally 1000+ hours in /src repo).
On Minecraft maybe there is a ratio of 1 dev on about 1'000 players (this is imaginary) who can script LUA or create scenarios, but on a Chromium project it gets probably more around 1 dev for 100'000 users.
I'm still amazed by some of the contributors in Kiwi though, some folks (d3ward, Delphox and others, and translators too!) really made Kiwi a much much much better product, and these people are really, really amazing (d3ward saved the project many times).
At the end, maintaining the repo is more of a net cost, than benefit; so from a pure cold reasoning, it's not a priority in terms of time / reward ratio, at least right now (it's not 5 minutes thing but more like few days of work).
In practice, nearly all the people interested into /src.next forks are almost exclusively the same type of pattern "commercial company from China looking to add crypto to the browser", or something similar, and it's very annoying.
Fixing the build pipeline and maintaining the repo has a cost, we don't talk about money, but about the most precious thing in the world: time.
Hopefully a better 2024, I kinda liked the old system as well.
Arnaud.

A very comprehensive response, thank you very much!
As for getting everything running in Actions, I have had success relying on on-demand Spot runners in AWS triggered via GitHub Actions, and I'm happy to share my Action for that if it's of any use:
https://github.com/ubergeek77/aws-ec2-spot-runner/
The default GitHub Actions VMs are next to useless, and I can't imagine any kind of Chromium build working well on those. The Action I linked would let you launch on-demand AWS instances to to a build which are inexpensive and ephemeral. I imagine it would cost about ~$0.25 to $0.40 for a full build, though this would add up on frequent builds. The VMs destroy themselves after the build is done, or after a failsafe amount of time, to prevent costs from being accrued. It's pretty simple and relies entirely on scripting, so everything that Action does is fully readable. You're more than welcome to take inspiration from it :)
Regarding these comments:

Regarding the question of the updates of the repo, there is one part technical, one non-tech, and this is a conscious choice.
TL;DR: Time is precious and I have limited amount of it but I agree that your vision is better in a pure world.
Kiwi is staying open-source, but expect the GitHub updates to be delayed (but will eventually come), the same way Telegram had such for some time, probably some big clean-up in 2024.

From my perspective, I personally do not believe there is much time commitment required to push the current copy of the code you have to this repo. You are maintaining a separate repo which is now out of band from this one, but that code exists somewhere. The time commitment you mention to keeping this repo up to date is stemmed solely from the decision to do staggered source releases. If you only had one repo, then keeping the source updated and keeping the app updated would be one and the same.
However, I have seen your other discussions about this on Reddit, and I am getting the picture that this staggered source release is done in an attempt to combat cloned apps.
And regarding:

I could potentially hire, but I have somehow little hope on the open-source community to spontaneously engage and come to work for free.

That's true, but also keep in mind that many people are probably being turned away by the current state of the repo, and they're also not able to contribute to the project currently, since the last 3 months worth of releases have sadly been closed.
For instance, I have a lot of experience with CI/CD management, and I would like to help, but this repository currently gives me almost no information on how Kiwi's current builds work. I can't contribute to your project because the relevant information is behind closed doors. If this repo was fully open source, I would be happy to help you achieve fully hands-off reproducible builds where your only responsibility would be to keep the code updated, but as it stands, your project direction now requires you to manually handle all of this.
I do understand your position though, and I thank you for your response. TL;DR is, these decisions were made to combat cloned Kiwi apps, so Kiwi is only "open source" a few times a year.
I think that ultimately, a decision will need to be reached on open source vs combating Kiwi forks. Chromium forks are a dime a dozen on the Play Store, and I think that is just the unfortunate reality. You can't really have both.
If you ever change project direction and decide to build fully against this repo, I would be happy to help contribute to the project, and I'm sure many others would too :)
In any case, thanks again for your response!

Can't understand why you can't provide complete code that can be compiled locally, it's not very friendly to secondary developers.


[Snowflake] Handle grantee type database_roles

What happened?
In case when the permission is granted outside Pulumi to a database role in snowflake, the planning stage will fail with "unknown grantee - DATABASE_ROLES"
Expected Behavior
Understand that database role is an open feature in Snowflake for now, I'd expect Pulumi to ignore these grantees for now until the GA of this feature on Snowflake, followed by a proper API to address this grantee
Steps to reproduce

Use a grant API, such as schemaGrant to grant some permission (say usage or monitor) on a schema to some roles
Create a new database role in Snowflake (outside Pulumi) and grant the similar permission as step 1
The next Pulumi preview or Pulumi up will fail at planning stage with the error "Unknown grantee type DATABASE_ROLE"

Output of pulumi about
CLI
Version      3.50.2
Go Version   go1.19.4
Go Compiler  gc
Plugins
NAME           VERSION
aws            5.1.0
command        0.7.0
datadog        4.12.0
docker         3.1.0
ec             0.3.0
fastly         5.1.0
gcp            6.12.0
github         5.1.0
google-native  0.14.0
kubernetes     3.23.0
kubernetes     3.16.0
mongodbatlas   3.5.2
nodejs         unknown
opsgenie       1.1.9
postgresql     3.6.0
random         4.3.1
snowflake      0.18.0
snowflake      0.5.2
terraform      5.6.7
tls            4.1.0
Host
OS       alpine
Version  3.17.0
Arch     x86_64
This project is written in nodejs: executable='/usr/bin/node' version='v18.12.1'
Additional context
Open a feature request ticket for long term solution: https://github.com/pulumi/pulumi-snowflake/issues/201
Contributing
Vote on this issue by adding a 👍 reaction.
To contribute a fix for this issue, leave a comment (and link to your pull request, if you've opened one already).

Going to close this as stale since there have been a few provider releases since – please reopen if there are any further questions/ issues


Update to add every error and fix missed use cases

Dear @chirag04,
Thank you for your work. Please merge this PR to close #15 finally and as alternative to move forward the suspended PR in https://github.com/chirag04/react-native-in-app-utils/pull/21.
Kind regards,
Denis

LGTM. This is a breaking change tho. SKErrorPaymentCancelled is now going to be an error in javascript. Users needs to handle this in javascript now.  Can you also document this in the readme?
cc @grabbou

LGTM.

It seemed to me there is nothing to update. :)```
var productIdentifier = 'com.xyz.abc';
InAppUtils.purchaseProduct(productIdentifier, (error, response) => {
if(response && response.productIdentifier) {
AlertIOS.alert('Purchase Successful', 'Your Transaction ID is ' + response.transactionIdentifier);
//unlock store here.
}
});

can you not bump the version in package.json? we should be doing 3.0 instead of 2.4.

Of course, no problem.

thanks @DenisIzmaylov & @grabbou
released v3.0.0 on npm.

Great! 👍


Adding JSON output

Provide a lightweight JSON output to support scripting.
cc @impedimenta, @taquitos

now provides three modes of output:

current time
adjusted remote time
adjusted local time

My first pass at this produces the following output:
% now bath uk --remote 4p -j
{
  "place" : "Local",
  "zone_name" : "Mountain Time",
  "provider" : "https:\/\/github.com\/erica\/now",
  "time_zone" : "MDT",
  "time" : "2020-06-02T15:00:00Z",
  "version" : "1.0.0"
}
% now bath uk --local 9a -j
{
  "place" : "Bath",
  "zone_name" : "United Kingdom Time",
  "provider" : "https:\/\/github.com\/erica\/now",
  "time_zone" : "GMT+1",
  "time" : "2020-06-02T15:00:00Z",
  "version" : "1.0.0"
}
% now bath uk -j
{
  "place" : "Bath",
  "zone_name" : "United Kingdom Time",
  "provider" : "https:\/\/github.com\/erica\/now",
  "time_zone" : "GMT+1",
  "time" : "2020-06-02T16:20:41Z",
  "version" : "1.0.0"
}

This actually looks pretty good.
I'm not sure of the need for a provider key, especially if it's always going to be "https:\/\/github.com\/erica\/now"?
I do have a feature request, adding a --pretty @Flag. So we can get unformatted JSON out.

I'm hesitant to add more exposed features to a utility I want to keep simple. Can you argue against pretty JSON for me? As far as I know, decoders can ignore the pretty printing.
I want to introduce only one format (non-pretty or pretty) and a single option (--json / -j) to keep that exposed surface area small.
I think there's value to having a version in case the output changes but agree the provider is marginally pointless.

No, you are correct. I don't have a good argument against pretty JSON being the only option.
I agree with the version, I'm assuming it's going to follow Semantic Versioning?

I just posted my Semantic Versioning code to a gist, it might be useful: https://richardstelling.com/Swift-Gists/#semantic-versioning

@rjstelling How about a single digit: version 1, 2, 3...? I don't anticipate changing the JSON output but I'd like to have a version there just in case.

Personally I prefer to have the option of Semantic Versioning, but 1, 2 etc are still valid semantic versions. So, everyone is a winner.

I'm going to go with that, then, with the understanding that I expect the JSON to not change much (if at all over time). Closing this issue and pushing the version with JSON support.


Types not released to package

It's coming soon!

I believe you should keep this issue open until the types are released.

https://github.com/lmsqueezy/lemonsqueezy.js/issues/4
I just discovered this issue, if it remains open, I would have opened this duplicate issue.

So please re-open either of these issues.


Alter id fields and add postgresql-client

Codecov Report

Merging #227 (2c00453) into master (1a2cc8f) will not change coverage.
The diff coverage is 100.00%.

@@           Coverage Diff           @@
##           master     #227   +/-   ##
=======================================
  Coverage   87.85%   87.85%
=======================================
  Files          78       78
  Lines        5424     5424
=======================================
  Hits         4765     4765
  Misses        659      659

Flag
Coverage Δ

unittests
87.85% <100.00%> (ø)

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

Impacted Files
Coverage Δ

tribal_wars_planer/settings.py
92.47% <100.00%> (ø)

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


Food sponsor for Hack Series

@zachlatta Once this is confirmed, please close this!

Sourcegraph is confirmed as a food sponsor. Going to try and get a16z as well.


override default NimblePool checkout timeout

Should we allow users to override the default timeout of 5 seconds for NimblePool.checkout/4? It seems like there's now way to do this currently (we still sometimes have some ci failing because of this now 🙂 )

Guess you can give it a try :shrug:
Not sure if it'll help though, it sounds a bit like you have a more general issue with your CI setup? Are you just trying to print a whole lot of PDFs in parallel? If so, increasing the number of sessions to spawn would probably help. Or maybe add a work queue and simply assert that a print job has been added?
In the end, ChromicPDF's session pool was never designed to function as a queue. In other words: If you want to print 6 PDFs in parallel with 5 workers, it by design should error on the 6th PDF (minus the allowed 5s checkout timeout). The sole purpose of the pool is to provide (bounded) parallelism.

Or another idea: Spawn a chromic process in the test (ExUnit's start_supervised) and inject the chromic instance to use into the test (via process dict, for instance). That way you would simply start another browser for each test that wants to print a PDF.

Not sure if it'll help though, it sounds a bit like you have a more general issue with your CI setup? Are you just trying to print a whole lot of PDFs in parallel? If so, increasing the number of sessions to spawn would probably help.

This did help actually, thanks! Also, I've removed async: true from the tests that use ChromicPDF, which results in having more cpu available when the tests run.

In the end, ChromicPDF's session pool was never designed to function as a queue. In other words: If you want to print 6 PDFs in parallel with 5 workers, it by design should error on the 6th PDF (minus the allowed 5s checkout timeout). If you want to queue work up, you need to add a queue (e.g. Oban). The sole purpose of the pool is to provide (bounded) parallelism.

Makes sense!

Or another idea: Spawn a chromic process in the test (ExUnit's start_supervised) and inject the chromic instance to use into the test unit (via process dict, for instance). That way you would simply start another browser for each test that wants to print a PDF.

I'll keep this in mind if the problem pop-ups again. Thanks!


Setting the stem attribute doesn't take effect

If I set the :stem: attribute :stem: latexmath and try to use inline stem
stem:[\forall x \in X, \quad \exists y \leq \epsilon]

it doesn't render properly. I have to explicitly name the macro for it to work
latexmath:[\forall x \in X, \quad \exists y \leq \epsilon]

I will check it.

Sorry to bump, but has there been any progress in this? It's a bit weird because non-inline math does show without problems. A workaround would be enough for now but I don't know enough Asciidoc for that :/

@marioortizmanero This is the non-asciidoctor workaround I'm using: https://superuser.com/a/1586450/1183493.

The same problem occurs for AsciiMath if the stem attribute is set to asciimath or blank (which has an implicit value of asciimath).
The problem is that the inline stem macro is not being treated as an alias for asciimath or latexmath. Instead, it's being processed as something entirely different, which is incorrect.
I'll submit a PR.

@ProgramFan Can you please make a new release?

I can do this. But I am not the owner of the gem on rubygems.org. We'd better refer to @tstumm for a release or a transfer-the-maintainership permission.

I am also considering refactor this gem to support multiple backends since the library behind mathematical is not well maintained. But I will find time only after the busy end of the year.

@ProgramFan Oh, thanks for letting me know. I did not know (or did not remember) who owned the gem on rubygems.org.
@tstumm Are you able to continue to release this gem? If so, can you make a new release? The release is now handled by GitHub Actions since Travis CI is no longer open source friendly. You'll first need to define the RUBYGEMS_API_KEY secret under Settings > Secrets so the GitHub Actions release workflow will complete when you push the tag.
Either way, can you also add me (mojavelinux) as an owner of the gem on rubygems.org (at https://rubygems.org/gems/asciidoctor-mathematical/owners)? I should have asked that when we transferred the repo to the asciidoctor organization. Thanks!

I am also considering refactor this gem to support multiple backends since the library behind mathematical is not well maintained.

That is fantastic news. Please reach out to the other Asciidoctor developers in https://gitter.im/asciidoctor/asciidoctor if you need help.

@mojavelinux Thanks for your efforts! I added you as an owner of this package in rubygems but also added the API key to the secrets.
We still need to bump the version though, but then we can tag a new release.

Thanks @tstumm!
GitHub Actions is configured to publish the gem to rubygems.org when a tag is pushed. See https://github.com/asciidoctor/asciidoctor-mathematical/blob/master/.github/workflows/release.yml. If for some reason it fails to run, I'll be around to help fix it.

It succeeded!! :tada: https://rubygems.org/gems/asciidoctor-mathematical


Converted README.md to README.rst

see #316

removing the .md messes up the github page 🤕
https://github.com/CityOfZion/neo-python/tree/readme.rst

It's not because of removing the .md, it's because the .rst has a syntax error and that's why it's not rendering properly. Sorry, taking a look atm.

Works now!

Coverage remained the same at 78.085% when pulling d3f4773efc6dceda35fde92a330a3feca5d4ac95 on readme.rst into 1cf02a58ba9b99a0b99dcd21f3cb2d4245c3dd85 on development.


:robot: triggering CI on branch 'release-next' after synching from upstream/main

/retest

/test unit

/retest
as https://github.com/openshift/release/pull/56511 merged


RD form value on login page

Correct rd form value when param not specified.
https://example.domain.com/oauth2/sign_in
<form method="GET" action="/oauth2/start">
  <input type="hidden" name="rd" value="/">

  <button type="submit" class="btn">Sign in with a GitHub Account</button>

</form>

Incorrect rd form value when param specified, making redirect to login_page again (loop)
https://example.domain.com/oauth2/sign_in?rd=/
<form method="GET" action="/oauth2/start">
  <input type="hidden" name="rd" value="/oauth2/sign_in?rd=/">

  <button type="submit" class="btn">Sign in with a GitHub Account</button>

</form>

Version: 2.2.1-alpha
      containers:
      - args:
        - --provider=github
        - --email-domain=*
        - --github-org=exampleOrganisation
        - --github-team=exampleGroup
        - --upstream=file:///dev/null
        - --cookie-domain=example.com
        - --cookie-name=_oauth2_proxy_test
        - --http-address=<IP_ADDRESS>:4180
        - --proxy-prefix=/oauth2
        image: docker.io/colemickens/oauth2_proxy:latest
       [...]

Currently it's not supported to add rd=... param to the sign-in page url. You have two options:

if using original proxy mode, just trying to visit the intended final page while not authenticated will return the sign-in page with rd set correctly
if using "nginx auth_request" mode, set the X-Auth-Request-Redirect header, see https://github.com/bitly/oauth2_proxy#configuring-for-use-with-the-nginx-auth_request-directive

I see it now why it stopped working for me. nginx-intress-controller for kubernetes fixed the rd param handling in nginx-0.9.0-beta.12 version with this commit: https://github.com/kubernetes/ingress/commit/b2be9f0e040d4207aab80f088b9fdfe79954741e#diff-b7803798d356c6c17a90d93cc58bdbaaR588
Correct me if I am wrong, but adding X-Auth-Request-Redirect header won't solve the problem unless rd param is still being set in error_page 401 directive.
The only way is custom nginx template for ingress which reverts changes from above mentioned commit.

Reading code seems like X-Auth-Request-Redirect would work if set to static destination.
The preferred way would be to remove SingInPath from RequestURI near that code: https://github.com/bitly/oauth2_proxy/blob/b1e29c329bc0232d99e381e0ff71d5b4539cdd9e/oauthproxy.go#L367-L373

see #427
(also I forgot about a third option: don't use the sign-in page at all, redirect straight to /start)

Assuming I still want to use login page I prepared a PR fixed both mentioned use-cases.
The corresponding test is also in-place.

Yes, I am facing the exact same issue. I tried to upgrade from nginx-0.9.0-beta11 to nginx-0.9.0-beta15 and authentication started to fail (infinite redirect loop). I tracked this to the exact change @krogon-dp mentioned.
PR #457 and #427 seem to be stuck so I am not sure what to do. For now I am sticking to nginx-controller-beta11 which is suboptimal. @aledbf  @ploxiln any suggestion ?
Thanks guys


Avoid using local time in client update

Closes: #2180
Description
Simple fix: use source network status instead of local time when computing client expiry status.

PR author checklist:

[X] Added changelog entry, using unclog.
[ ] Added tests: integration (for Hermes) or unit/mock tests (for modules).
[X] Linked to GitHub issue.
[] Updated code comments and documentation (e.g., docs/).

Reviewer checklist:

[ ] Reviewed Files changed in the GitHub PR explorer.
[ ] Manually tested (in case integration/unit/mock tests are absent).

Thank you very much

For config validation and client creation with parameters, maybe we should add a check for trusting_period > N * block_time, not sure about the value of N but definitely >=1.
For clients that hermes doesn't create it's not much we can do.


Geojson Should allow for tracksViewChanges to be set on custom markers

Summary
With data in a GeoJSON format, if you have thousands of markers performance degrades very quickly.  Allowing for setting the tracksViewChanges property via the Geojson component might help improve the overall performance while using the GeoJSON component.
Reproducible sample code
<Geojson
  geojson={GEOJSON}
  onPress={handleMarkerSelect}
  markerComponent={
    <Image source={require("../../assets/imgs/marker.png")} />
  } />

Steps to reproduce
Render a Geojson component with many "points"
Expected result
The map should work without severe performance degredation.
Actual result
the map is rendered unusable and freezes indefinitely (tested on android)
React Native Maps Version
0.32.2
What platforms are you seeing the problem on?
Android
React Native Version
0.68.2
What version of Expo are you using?
SDK 45
Device(s)
Google Pixel 6
Additional information
Are there any other things that can be done short of removing some markers to improve performance with many markers? Seems like this might be a fairly common use case.

Hi @jcuffney 👋. Sounds reasonable. How would you expect this to behave? A single prop that controls tracksViewChanges for all markers?

@Simon-TechForm  I think the single prop on <Geojson /> would solve the performance related issues for most cases...but I think a better solution would be to have a combination of the single prop as the "default" value to be used for all markers, but allow that value to be overridden by the value of properties.tracksViewChange within the geoJSON so it can also be driven by the data.  That way if for some reason someone needed to track view changes for some markers but not others - it would be possible to do so.

@jcuffney I agree that being able to specify the prop for each individual marker would be optimal.
Would you be up for taking on the task of a PR? If so, I'll be happy to review and merge once it's done. Implemeting the default prop for all markers should be quite simple, while doing it for each individual marker might be as well, but would at least require extending the type we use from @types/geojson.

@Simon-TechForm sure I can have a go at a PR - I just opened a, initial pass #4347  but might need a little more info on how you'd expect to extend the geojson types to work.
Would this just extend the FeatureCollection type to include tracksViewChanges?

@jcuffney Exactly. I was under the impression that data like this would normally be added as a foreign member, which would also allow us to type it, instead of relying on the any type in properties. But having had a look at other implementations, using the properties member seems totally viable, so I'm happy with the solution in your PR. Besides, since we are dealing with JSON, the geojson prop is most likely to be passed an any type either way.
Lets continue the discussion in the PR 👍


set_col_width and set_row_height don't work

Cargo.toml:
[dependencies]
spreadsheet-ods = "0.4.0"
color-rs = "0.5.0"

main.rs:
use spreadsheet_ods::*;
use spreadsheet_ods::style::*;

fn main() {
    let output_file = std::path::Path::new("test.ods");

    let mut wb = WorkBook::new();

    let mut style = Style::new_cell_style("Square style", "");
    style.col_mut().set_col_width(Length::Cm(10.0));
    style.row_mut().set_row_height(Length::Cm(10.0));
    wb.add_style(style);

    let mut sheet = spreadsheet_ods::Sheet::new_with_name("test");
    sheet.cell_mut(1, 1).set_style("Square style");
    wb.push_sheet(sheet);

    if let Err(x) = spreadsheet_ods::write_ods(&wb, output_file) {
        println!("Error: {}", x)
    }

}

result(compressed because GitHub doesn't support ods): test.zip

I see, should have put a few locks in place.
style.col_mut() is only useful for Style::new_col_style() and style.row_mut() for Style::new_row_style().
The way to do this is
sheet.set_row_height(&mut wb, 1, cm!(10));
sheet.set_col_width(&mut wb, 1, cm!(10));
sheet.set_value(1, 1, "");

The first two calls create the correct styles, and set_value assures that the cell is actually written to the file.
This works better, but there seems to be another issue. The row height is set for the first row too. Will check where that comes from.

0.4.1 fixes the write bug.
There is an alternative usage
sheet.set_row_height(&mut wb, 1, cm!(10));
sheet.set_col_width(&mut wb, 1, cm!(10));
sheet.set_value(1, 1, ());
It is still necessary to set a cell value (or formula, or cell-style).
All row/column styles beyond the maximum cell are discarded.


Does P/R/C reporting on argo list -o wide still work?

Whenever I try running any of our workflows and I used
argo list -o wide  -A

NAMESPACE   NAME                                                         STATUS      AGE   DURATION   PRIORITY   P/R/C   PARAMETERS
dev         dev-abc-defghij-default-1659528000                           Running     4m    4m         0          0/0/0
dev         stable-another-job-def-g64cn                                 Succeeded   11d   7h         0          0/0/0

I've tried this with our job definitions and I've also tried this out of the box some of the workflows in argo-workflows/examples and I've yet to see a case where it works.
Summary
What happened/what you expected to happen?
The P/R/C column is populated based on the number of pending/running/completed steps of the workflow.
What version are you running?
We're running v3.2.9 but I've also tried it with v3.3.7

This happen because of this line of code:
https://github.com/argoproj/argo-workflows/blob/f27475feb850dc43e07c3c5215cc9638947f0859/cmd/argo/commands/list.go#L48
It should be easy to add an option for wide.

Hi @alexec, I am new to open source and would like to try and work on this issue.
Can you assign it to me?

Update on the issue: I have been learning Go and Kubernetes and reviewing the documentation to better understand the project.

Hi @alexec, I have made the following changes:

After this I ran the command make cli and was able to submit an example workflow to get the expected P/R/C results.

Kindly let me know if this fixes the issue or if I need to make more changes.
Also, I would highly appreciate it if you could tell me what unit tests I should add for the above changes before making a pull request. :smiley:


feat: add aspect-cli 5.5.4 derivation

Description of changes
This PR adds a new derivation for https://github.com/aspect-build/aspect-cli, a Bazelisk alternative.
Things done

Built on platform(s)

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

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[ ] Tested, as applicable:

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

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

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

[ ] Fits CONTRIBUTING.md.

Hi @matthiasbeyer @h7x4, thank you both for the review! 🙇🏻
I've addressed some of your comments, and added myself as maintainer of the package.

Please split up your first commit into two:

maintainers: add ar3s3ru
aspect-cli: add ar3s3ru as maintainer

I'm not able to make the binary working properly. Do you have a project you could test it on?

I'm not able to make the binary working properly. Do you have a project you could test it on?

What kind of issues are you encountering?
It seems to be working on my project (I basically just copy-pasted the local derivation I was using on my project's devshell).

[nix-shell:~/.cache/nixpkgs-review/pr-251557-1]$ results/aspect-cli/bin/bazel --help
bash: results/aspect-cli/bin/bazel: cannot execute: required file not found

[nix-shell:~/.cache/nixpkgs-review/pr-251557-1]$ results/aspect-cli/bin/bazel help
bash: results/aspect-cli/bin/bazel: cannot execute: required file not found

On another note, it seems like the project expects the command to be named aspect. Are you sure it's supposed to be named bazel?

@h7x4 are you testing this in a Linux/NixOS environment? It may be similar to the issue with bazelisk (source)
If that's the case, we can restrict the platforms to (x86-64|aarch64)_darwin and I can figure out the Linux stuff later.

On another note, it seems like the project expects the command to be named aspect. Are you sure it's supposed to be named bazel?

The idea of this tool is to serve as a replacement for bazel. Maybe what I can do is:

Copy the $src to bin/aspect in installPhase,
Symlink bin/bazel to bin/aspect,
that way both aspect and `bazel are available in the PATH.

Wdyt?


Question, what's the minimal version of OpenGL & OpenGL ES?

Would nxt-standalone could be able compiled to WebGL or WebGL2 code?
For example, like https://github.com/floooh/oryol
Oryol seems not support for Computing but nxt-standalone support.
So maybe compute can be an optional feature?

No, it will not work on WebGL or OpenGL ES. The OpenGL backend, which requires OpenGL 4.5 (or 4.1 without compute) is a proof of concept, and it probably will not be possible to maintain forever due to fundamental incompatibilities of the API design with OpenGL.
NXT is a prototype of the next-generation "GPU for the Web" API, the goal of which is to make a new web graphics API that will solve performance and structural limitations of WebGL. Implementing it on top of WebGL would not be that useful since it would only change the shape of the API (though it could slightly help get a head start on porting). Something like NXT is expected to eventually ship natively in all major browsers, once we have standardized it.

@kainino0x For mobile platforms, There are platforms that only support for OpenGL ES 3.0, would OpenGL ES 3.0 be enough?

No, I don't think it works with any version of OpenGL ES at all. Once we have a complete Vulkan backend, it could be made to work on Android. For iOS, we already have a Metal backend, but nothing has ever been built on iOS.
Ultimately this project is still a prototype and will most likely be replaced by some other open source library that serves the same function - implementing the final "GPU for the Web" API.


Fix bad reference to property channels

I think this is a mistake; psubscribe refers to this.channels and punsubscribe refers to this.patterns...

LGTM, thanks @sebastienfilion!


Game closes.

Hi! i have a problem with the mod
when i choose any week, the screen goes black and closes (except in Polus, first the scene appears and then closes)
i tested with the Gamebanana link and the mirror, and doesnt work
how can it be fixed?
also, you and your team made an awesome work with this mod!  Thank you so much for the help <3


Rule suggestion: check qualifier for parameter-properties

Rule Suggestion
It would be great to have rule that enforces 'this' qualified access to constructor's parameter properties in the constructor code.
basically this suggestion is for a rule that prevents the developer from an error like this:
public constructor(private name: string) {
   name = name.replace('foo', 'bar');
}

While expecting that the 'name' property does not contain the string 'foo' anymore.
In this case the developer wanted to transform the value of the property 'this.name', but he did only change the value of the local variable 'name' (which is shadowed by the parameter property).
whilst the correct code would look like this:
public constructor(private name: string) {
   this.name = this.name.replace('foo', 'bar');
}

Interesting idea. What would be expected with code that uses the modified variable after the fact?
Example:
public constructor(private name: string) {
   name = name.replace('foo', 'bar');
   console.log(name);
}

...should the rule only capture parameter property arguments that are modified after any code that would work on them is done?

Also note that the tsc no unused parameters check would produce an error here:

@Josh, I’d would like the rule to capture every time the local variable is used at all, to prevent unwanted usage.
@Adi, yeah, that’s a good start but in the scenario I’m thinking about, especially the mixed access on “name” and “this.name” is causing the unexpected behaviour.

Note: per #4534, this issue will be closed in less than a month if no PR is sent to add the rule. If you really need the rule, custom rules are always an option and can be maintained outside this repo!

💀 It's time! 💀
TSLint is being deprecated and no longer accepting pull requests for new rules. See #4534. 😱
If you'd like to see this rule implemented, you have two choices:

Recommended: Use typescript-eslint to lint your TypeScript code with ESLint ✅
Legacy: Write it as a custom TSLint rule 🤷♂

👋 It was a pleasure open sourcing with you!
If you believe this message was posted here in error, please comment so we can re-open the issue!

🤖 Beep boop! 👉  TSLint is deprecated 👈 (#4534)  and you should switch to typescript-eslint! 🤖
🔒 This issue is being locked to prevent further unnecessary discussions. Thank you! 👋


Is there support for TL series fans and controller?

Is there support for TL series fans and controller?
I have these in my system and can provide any troubleshooting required to make this work.

Are you on Linux? I have a fork of this repo where I can add your product id and fan specs to see if that works.

@bcarvalho2500 Yes I dual boot this system with Windows and PopOS.
This is what is reported from Windows:

Huh that has a VID I was not expecting. Can you try running lsusb -v | grep -i 0cf2 on PopOS and see if that returns anything? If that doesn't return anything can you try lsusb -v | grep -i lianli

@bcarvalho2500 I certainly can, Just at work atm but can do in ~6 hours time :P.
I will edit this message once I have more information.

@bonkas  Alright I think I may have something that will work. Just for my piece of mind there are somethings in the original code that I don't exactly understand so I copied the lines for the 'SLI' fans which are relatively new also. How the whole program works is that it just edits the files on start so if it doesn't work and uninstall and reboot should do the trick.
If you wanna go ahead and try it out you can clone it with this: git clone -b feature/add_support_for_tl_fans --single-branch https://github.com/bcarvalho2500/uni-sync.git

hmm I am still having no luck, I am thinking it is a "me" problem though.
I have been uninstalling, installing, rebooting over and over a number of times now but I am not getting the config file to populate except for ONCE it populated (I will paste contents below) I noticed the RGB dissapeared from the fans so something must have communicated with the fans so I tried to increase the fan speed to 100% and restart the service but nothing happened. I havent been able to repeat the config file being created since.
I have tried installing as my regular user and using sudo to no avail, the config file is either not created or is created as an empty json in the folder containing the application. The path given in the github doesnt seem to exist either, well I can see it but cannot do anything with it... not sure what is going on here.
Is this something you can offer some assistance with?
This is the config I managed to generate ONE time only.
{
"configs": [
{
"device_id": "VID:1046/PID:29554/SN:Nuvoton",
"sync_rgb": false,
"channels": [
{
"mode": "Manual",
"speed": 100
},
{
"mode": "Manual",
"speed": 100
},
{
"mode": "Manual",
"speed": 100
},
{
"mode": "Manual",
"speed": 100
}
]
}
]
}

@bonkas So the empty json is created when you install but when the application first runs, that's when the json is filled with default values and once the json is filled out, it's never created again. So if I read what you said correctly, that should be normal behavior.
I'll need to take a look more into how to write to HID devices to try and see why yours didn't work. Your fans vendor id was different from all the others so maybe something changed there? I'll try to learn how to get report data but may need you to provide it since you have a working L-connect with those fans.
Sorry I couldn't get it to work sooner.

Yup, happy to help further but am a bit out of my depth here.
I have tried to include as much information as possible about what I noticed to try narrow down the issue but it seems the controller gets communicated with and then freaks out, only a hard reset of the device and then subsequent drive removal/reinstall in windows resolves this.

Hello,
I want to add to this issue to hopefully help.
The newer TL hubs seem to have somethings that is above the controller.
lsusb output:

Bus 003 Device 005: ID 0416:7372 Winbond Electronics Corp. TL_Series_ControllerV0.58
Bus 003 Device 003: ID 1a40:0801 Terminus Technology Inc. USB 2.0 Hub

lsusb -t output:

/:  Bus 03.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/12p, 480M
|__ Port 6: Dev 3, If 0, Class=Hub, Driver=hub/4p, 480M
|__ Port 3: Dev 5, If 0, Class=Vendor Specific Class, Driver=, 12M
|__ Port 3: Dev 5, If 1, Class=Human Interface Device, Driver=usbhid, 12M
|__ Port 3: Dev 5, If 2, Class=Human Interface Device, Driver=usbhid, 12M

Looking forward to seeing this support the TL line.
Regards.

Any changes since?


rancher-pipeline.yml reference

There is no reference for the rancher-pipeline.yml to be found. Yet the docs under https://github.com/rancher/docs/blob/master/content/rancher/v2.x/en/k8s-in-rancher/pipelines/example/_index.md explain there should be one.
There are 2 issues with this.
Generally,
It's probably bad practice to suggest the existence of docs that do not exist. And getting into pipelines is harder for me as a developer looking for config files he can push, rather than a click through tutorial.
For my case,
I can't find a way to schedule a pipeline. So I can only trigger it via commit, or manually. Making nightly builds impossible. Or only doable via some unreliable hack like committing with a script or do an API call every evening.
To solve this I would, update the docs so it doesn't create false hope for something that doesn't exist. (Which cost me a lot of time). And, if there is an option for it, document how to schedule a pipeline via the rancher-pipeline.yml.

Closing this issue because it addressed by this PR https://github.com/rancher/docs/pull/2419


Removed the generation of self-signed certificates

We no longer need to generate self-signed certs as we are using
the device certificate to establish a secure connection with cloud.

Compatible with - https://github.com/PelionIoT/maestro/pull/140

Compatible with - https://github.com/PelionIoT/maestro/pull/140

FYI @PelionIoT/team-edge_sqa This might break test cases if you are looking the .ssl folder.

FYI @PelionIoT/team-edge_sqa This might break test cases if you are looking the .ssl folder.


Graceful handling "connection: close" header

When gun receives "connection: close" header from a server it terminates the connection. There is a small time window (~1ms) though when a worker tries to process another request on the same connection (as it hasn't received gun_down message yet) which will be terminated before server is able to send a response. It causes an error which results in duplicate requests.

fixed by #26


Chunking file uploads in StreamHandler?

For users without cURL installed and therefore rely on the StreamHandler, is there support for large objects? I'm getting memory limit problems because of this line since it's loading the request body into memory.
This is more of a general question, but can PHP's default HTTP stream context handle chunking? Something like this might work.

This is not possible with the PHP stream handler. It has to load the entire payload into memory unfortunately.
The link you provided uses raw sockets, which would work, but Guzzle does not have a built-in raw socket based adapter. Guzzle has built-in curl and PHP stream handlers. Writing an adapter using raw sockets and hooking it up to Guzzle is certainly possible, but not something that I think would end up in the core Guzzle library.