Audio subtitles support?

Does this library support audio subtitle selection and playing?
Basically, in a video I want the user to be able to select one out of the two audio languages and play audio for that language only. Does this library have that capability? If yes, @phoboslab please provide the code for selection.

No. There are few parts missing for that:

JSMpeg only decodes the first Audio Stream see player.js#53. You'd need to add some functionality to switch to STREAM.AUDIO_2 or others on the fly.
There's no decoder for subtitles
There's no renderer for subtitles

As far as I know, subtitles are usually carried in a private stream. You can ask the demuxer to forward these packets to your subtitle decoder:
player.demuxer.connect(JSMpeg.Demuxer.TS.STREAM.PRIVATE_1, yourSubtitleDecoderInstance);
Also, you may want to decode the Program Stream Map, to figure out what stream is what (i.e. which of the audio streams is what language and what subtitles are present). Again, you can ask the demuxer to forward PSM packets (JSMpeg.Demuxer.TS.STREAM.PROGRAM_MAP), but there's no decoder for it yet.
The decoded subs could either be rendered directly into the canvas (not that easy for WebGL contexts) or layered on top as a simple HTML element.
PRs welcome!

I was talking about audio subtitles(AUDIO_1,AUDIO_2, etc ) only and not text subtitle. From https://github.com/phoboslab/jsmpeg/blob/924acfbd96fdf15e6748d1368a36d79d8f4cecf6/src/ts.js#L219 , I can understand that AUDIO_1 maps to 0xC0. How to understand AUDIO_2, AUDIO_3, etc maps to what?

You are talking about audio streams then :)
AUDIO_2 would be 0xC1.
The MPEG Standard defines anything between 0xC0 and 0xDF (inclusive) to be possible audio streams (see http://dvdnav.mplayerhq.hu/dvdinfo/pes-hdr.html), so in theory your 2nd audio stream could have any of those IDs. Though sensible encoders will put the 2nd stream in 0xC1, 3rd in 0xC2 etc.

Thanks for the info


Turn the HTTP request retrieving the CSV data into a GET request

... and display the corresponding URL somewhere, to make it - sort of - bookmarkable.
(split from #326)

Fixed in 371ea4d3ad2ca363983a2ae70b26e0ec9439f8e7


Bump CMake version to 3.17.

Updates the required CMake version for Swift and the Swift Benchmarks to 3.18. Updates the docs to reflect this change. Doesn't modify the required version for building the stdlib.
Required for #36082.

@shahmishal This patch would require some of the Linux build bots to be updated.

Can you do a post on the forum about this to check for objections?

I think you'll need to update the CMake built from source too, see #30695 for an example.

@buttaface will do.

Here's the forum post.

@gottesmm any updates or should I try to get swiftpm working?

@swift-ci please test.

@swift-ci please test.

@zoecarver can you add to the commit message that you are updating the cmake tag for 3.19 in update-checkout?

Build failed
Swift Test Linux Platform
Git Sha - debd1727db610acf33d595c4a771e9e86ccd9250

Build failed
Swift Test OS X Platform
Git Sha - debd1727db610acf33d595c4a771e9e86ccd9250

@swift-ci please test

Build failed
Swift Test Linux Platform
Git Sha - debd1727db610acf33d595c4a771e9e86ccd9250

@gottesmm done.
@swift-ci please smoke test.

Looks like there was a version mismatch issue. Maybe a clean build will get the bots green.
@swift-ci please clean test.

Build failed
Swift Test Linux Platform
Git Sha - 520667aa2a2540e6197a6603c2e67f9a9f8d7dea

@gottesmm do you want me to update this to 3.19? It looks like the other PR only updated the checkouts script.

@zoecarver not time yet. Waiting for one other thing.

and I am going to want to update to 3.19.6

@swift-ci please clean test.

Build failed
Swift Test OS X Platform
Git Sha - a13c57c360d12fd19c27129ec6f21add1d71384d

@swift-ci please clean test macOS.

@swift-ci please test macOS.

@swift-ci please test Windows.

@swift-ci please test Windows.

Source kit issues :/
@swift-ci please test Windows.

@swift-ci please test Windows.

FYI: Even when this is green, please don't merge until Sat or Sun. There is a bunch of commits trying to get into main right now and we don't want to churn the tree with something unless we need to.

The windows bots keep failing for unrelated issues. This shows that there isn't a problem with the CMake version, though, because those tests wouldn't even be able to run if there was. I'll give this one more try because it would be nice if it was green, but otherwise I'll just land it tomorrow.
@swift-ci please test Windows.

CC: @drodriguez - this seems to have regressed the VS2017 builders :-(.

CC: @drodriguez - this seems to have regressed the VS2017 builders :-(.

Hopefully the next build will use CMake 3.21. Thanks for the heads up!


Support searching for rubocop/config.yml in compliance with dot-config

Follow https://github.com/rubocop/rubocop/pull/12700#issuecomment-1949764386
This PR supports searching for rubocop/config.yml in compliance with dot-config.
This PR adds project_root/.config/rubocop/config.yml to the list of paths to search, matching XDG path format of the already targeted ~/.config/rubocop/config.yml.
However, support for ~/.config/rubocop.yml is not included in this PR, as the outcome of inquiry https://github.com/dot-config/dot-config.github.io/issues/17 regarding it is still pending.

Before submitting the PR make sure the following are checked:

[x] The PR relates to only one subject with a clear title and description in grammatically correct, complete sentences.
[x] Wrote good commit messages.
[ ] Commit message starts with [Fix #issue-number] (if the related issue exists).
[x] Feature branch is up-to-date with master (if not - rebase it).
[x] Squashed related commits together.
[x] Added tests.
[x] Ran bundle exec rake default. It executes all tests and runs RuboCop on its own code.
[x] Added an entry (file) to the changelog folder named {change_type}_{change_description}.md if the new code introduces user-observable changes. See changelog entry format for details.

Nice!


deleting a pipe does not delete corresponding runs

when a pipe is deleted its corresponding runs are not deleted.
you can notice this when viewing the run/activity for all pipes.
the tables shows run for pipes which have been deleted.

Assumptions:

A pipe can only be deleted if it is not associated with any runs, or if all associated runs are in FINISHED, STOPPED or ERROR state.
Individual pipe runs cannot be deleted.
if a problem is encountered deleteing one or more pipe runs, the pipe is not deleted.

Delivered. I ran the following tests:

Delete a pipe that wasn't run yet
Delete a pipe while no run is in progress (multiple runs were completed before)
Try to delete a pipe with while a run is in progress


ES6

Put all src files in src. was kinda messy having everything at root.
transpile code with babel for node builds. code is placed in the dist folder

main now points at the dist folder

ignore all built files such as files in browser/lib and dist
Babel all the files with babel-preset-env

remove the need for Promise polyfill #472
remove babel-preset-es2015 covered by env

Build no longer runs after install
removed test:node:once:nocover since it was doing the same thing as test:node:run
started factoring out modules. Only logging and error-checking

closes #466
@edi9999

How would you feel about using https://github.com/developit/microbundle/blob/master/README.md ? Would could support many different ecosystems all it once!

We could also use https://www.npmjs.com/package/esm to output a ES Modules build.
So in total we could have:

main - babelified build
browser - browser build
module - ES Modules build

@edi9999 what do you think? do you only want to support a non babelified cjs main and a browser field?
Cons:

Support for node < 6.4 dropped (no es6 before that version)
No support for module field (the future)

Pros:

simple

hello hipster, for the import export, I'm also ok to use it, what I would however like to have is to compile the files without losing file/numbers, so basically only transpile what is really needed, because in node.js, you usually don't use sourcemaps.

The other problem that I see with using ES6 imports (and transpilation in general), is that when you have a stacktrace, you will have to change the path if you use an IDE or tool to "jump" to that position.

I just tested this and my IDE jumped to the correct area with source maps on. I followed this https://schempy.com/2015/05/20/source_maps_with_nodejs/. The source maps seems to work. @edi9999  Would you like to try it out?

@edi9999 I dont think that is really gonna be possible. We don't have optional source maps for browser, so why make them optional for node?

I could optionally require it based on the NODE_ENV. And try to set up a debug build. But I don't know where i would put the debug build in the package JSON. Or maybe if NODE_ENV is set to prod, dont use the source maps.
What are the requirements you need me to satisfy for this to be merged?

@edi9999 the last commit ensures that production builds of jimp don't include source maps. but you can run npm run build:node:debug to get source maps.

@edi9999 I just did something pretty big here (I can move it to another branch if you want). Commit 16b2d94 fixes the browser build!!
The following now actaully works!
var Jimp = require('jimp');

Jimp.read('./exampleImages/dice.png')
  .then(...);

@edi9999 have now verified that source maps work in tests also. Source maps are only included when BABEL_ENV is set to development

@edi9999 after this i have a branch that breaks up the huge index.js file. Make moving through the project so much easier 👍

@edi9999 :) if more source maps issues come up I'm committed to fixing them.

@edi9999 I wanna get this released soon. I've been buggin @oliver-moran on twitter about it. This merge will fix both the browser version and use es5 for older versions of node via babel.
Then we can contact the fine folks at cdnjs to start hosting a version of jimp that works on all platforms! #253
It's been almost a year since jimp worked in browser. Let's make it happen!

@oliver-moran can we merge this? I'd really like this in for the 0.3.0 release.
as well as #477 and #486


Fix DR baselines

This PR fixes various problems with the dimensionality reduction baselines.

density_preservation was giving a correlation of 0.5 when comparing the true data to itself
spectral distances should be optimized by spectral embeddings
spectral distances should weight the eigenvectors by their eigenvalues
Removed some unnecessary baselines
Added a diffusion maps method (incidental, through spectral distance fix) and a zebrafish dataset (as all existing datasets were rather simple)

Closes https://github.com/openproblems-bio/openproblems/issues/803


CameraView takes time to capture image

Camera View takes time to capture the image if we request cameraview.takePicture() it takes about 1 or 3 secs to receive callback for onPictureTaken Callback

Found on Asus Zenphone

I've been trying to figure out what has been going on here for a couple of weeks (albeit I haven't spent a lot of time), glad to see it might just be an issue with Asus Zenfone!

I was having the same issue with a HTC One (M8) and it turned out to be caused by setting auto-focus to true.

It turns out that in the end the camera on Android is just pretty slow overall. That being said, I ended up switching to Fotoapparat: https://github.com/Fotoapparat/Fotoapparat and have found there to be less crashes on various devices


Make timeout cancelable with AbortController polyfill

Landed in https://github.com/metarhia/metautil/commit/5095b0d15c869241c3b37da23aebedbdf24c0735


Fix typo in README.md

This fixes a minor typo in README.md ("Kuberentes" -> "Kubernetes").

Thanks @henrybell!


[Bug]: Incorrect Resume input field when user tries to add their resume in their accounts settings

Contact Details
No response
What happened?
Bug 1:
There is an unnecessary field input for user to upload their resume, the current behaviour is when the user tries to add the resume it just shows an normal text field, so how can a user able to add their resume into that field?

Bug 2:
On mobile devices that resume field just opens the numeric input keyboard

What can be the solution for this?
Instead of adding an text input field we can add file upload input field or an Drag and drop field where user can add the resume in pdf.
and it can be further stored Firebase Cloud Storage

https://firebase.google.com/docs/storage

So every users resume will be stored on firebase separately with unique user id and can be further retrieved from there.
What browsers are you seeing the problem on?
Chrome
Relevant log output
No response
Are you interested in contributing?

[X] I'd like to work on this issue

Code of Conduct

[X] I have used the search function to check if an issue already exists
[X] I agree to follow this project's Code of Conduct

Hey there, Can you assign me this issue, I would really appreciate it 😊

hey there i would like to work on this bug

Hey there I just recreated this bugs and they are not yet fixed i would like to be assigned to this issue.

Hey @youssefjaziri456, we've removed the resume field on new version

Okay I will close the issue now


bugfix in #handle_response when handling collections

Hi,
found a bug today in my code 😅 . It contains the #handle_response method in the model helper when running actions on collections.
I also added some info to changelog and bumped the version already.
👍

@akurkin anything you want me to change?

nope, looking good 👍


Clean up github mockserver used in testing

https://github.com/kubernetes/contrib/blob/master/mungegithub/github/testing/github.go#L325
InitServer takes far too many arguments. We should put that into a struct and clean up.

This issue was moved to kubernetes/test-infra#1632


ibus-engines.hangul: 1.5.0 -> 1.5.1

Semi-automatic update generated by https://github.com/ryantm/nixpkgs-update tools. This update was made based on information from https://repology.org/metapackage/ibus-hangul/versions.
meta.description for ibus-engines.hangul is: '"Ibus Hangul engine"'.

Checks done (click to expand)

built on NixOS
Warning: no invocation of /nix/store/ci2fiwhj08xgpsdbfhnir98g33dz3kx5-ibus-hangul-1.5.1/bin/ibus-setup-hangul had a zero exit code or showed the expected version
0 of 1 passed binary check by having a zero exit code.
0 of 1 passed binary check by having the new version present in output.
found 1.5.1 with grep in /nix/store/ci2fiwhj08xgpsdbfhnir98g33dz3kx5-ibus-hangul-1.5.1
directory tree listing: https://gist.github.com/e3e2860d5365e47abeb02a63067d40ed
du listing: https://gist.github.com/54bf6efad2bb2ce2f025e55e6ee4745f

Test this build with Cachix (click to expand)

One time setup in nixpkgs Git checkout:
cachix use r-ryantm
git remote add r-ryantm https://github.com/r-ryantm/nixpkgs.git

Test this build:
git fetch r-ryantm && git checkout 7743ae66dbde3254771fa1ef95e3ed17013d4981 && nix-shell --pure -I nixpkgs=. -p ibus-engines.hangul

cc @ericsagnes for testing.

Success on x86_64-linux (full log)
Attempted: ibus-engines.hangul
Partial log (click to expand)
make[1]: Leaving directory '/tmp/nix-build-ibus-hangul-1.5.1.drv-0/ibus-hangul-1.5.1'
glibPreFixupPhase
post-installation fixup
shrinking RPATHs of ELF executables and libraries in /nix/store/8sspvcraqlizps9asq2q4clkgh18cj3d-ibus-hangul-1.5.1
shrinking /nix/store/8sspvcraqlizps9asq2q4clkgh18cj3d-ibus-hangul-1.5.1/libexec/ibus-engine-hangul
strip is /nix/store/1hi76hr87bd1y1q1qjk0lv8nmcjip1c8-binutils-2.30/bin/strip
stripping (with command strip and flags -S) in /nix/store/8sspvcraqlizps9asq2q4clkgh18cj3d-ibus-hangul-1.5.1/libexec  /nix/store/8sspvcraqlizps9asq2q4clkgh18cj3d-ibus-hangul-1.5.1/bin
patching script interpreter paths in /nix/store/8sspvcraqlizps9asq2q4clkgh18cj3d-ibus-hangul-1.5.1
/nix/store/8sspvcraqlizps9asq2q4clkgh18cj3d-ibus-hangul-1.5.1/libexec/ibus-setup-hangul: interpreter directive changed from "/bin/sh" to "/nix/store/dkh7l9a4sx7zqh8riqbj3z21sz25p8xy-bash-4.4-p23/bin/sh"
checking for references to /tmp/nix-build-ibus-hangul-1.5.1.drv-0 in /nix/store/8sspvcraqlizps9asq2q4clkgh18cj3d-ibus-hangul-1.5.1...

No attempt on x86_64-darwin (full log)
The following builds were skipped because they don't evaluate on x86_64-darwin: ibus-engines.hangul
Partial log (click to expand)

a) For `nixos-rebuild` you can set
  { nixpkgs.config.allowUnsupportedSystem = true; }
in configuration.nix to override this.

b) For `nix-env`, `nix-build`, `nix-shell` or any other Nix command you can add
  { allowUnsupportedSystem = true; }
to ~/.config/nixpkgs/config.nix.

Failure on aarch64-linux (full log)
Attempted: ibus-engines.hangul
Partial log (click to expand)
-- Performing Test CXX_SUPPORTS_WERROR_DATE_TIME - Success
-- Performing Test CXX_SUPPORTS_WERROR_UNGUARDED_AVAILABILITY_NEW
-- Performing Test CXX_SUPPORTS_WERROR_UNGUARDED_AVAILABILITY_NEW - Failed
building of '/nix/store/nzxz2hn6ssvanp1v6ayprfbprlvx1sf3-rustc-1.27.0.drv' timed out after 3600 seconds
cannot build derivation '/nix/store/746np0zvbhpa2sr6vkkkpnwsgb9dxdga-cargo-1.27.0.drv': 1 dependencies couldn't be built
cannot build derivation '/nix/store/q28r339dz25l1mmw8rfbkz1ldcczwzmj-librsvg-2.42.4.drv': 2 dependencies couldn't be built
cannot build derivation '/nix/store/y3j81m2w0m8ziyz6c0an81icgrxfxh31-hook.drv': 1 dependencies couldn't be built
cannot build derivation '/nix/store/6a6ziwhs1mpmqc3v4wijrxrjzyksnjh6-ibus-1.5.17.drv': 1 dependencies couldn't be built
cannot build derivation '/nix/store/nkzxc9sx2cbhwhvqxcwyqpdrjkphaq2f-ibus-hangul-1.5.1.drv': 1 dependencies couldn't be built
error: build of '/nix/store/nkzxc9sx2cbhwhvqxcwyqpdrjkphaq2f-ibus-hangul-1.5.1.drv' failed


adding_a_cask.md: Rephrase homebrew-versions criterion

Follow up to the https://github.com/caskroom/homebrew-cask/pull/20171 vs https://github.com/caskroom/homebrew-versions/pull/1865 dispute.
Alternative versions of an app that has a principal stable version should always go into homebrew-versions, regardless of whether the principal stable version exists in the main repo or not. This covers edge cases like Safari whose principal stable version should not be vendored by homebrew-cask.

Nice fix. Thank you.


MSPSDS-538: Search cases by keyword

Still a bit of a WIP.
TODOs:
More tests
Figure out how to deal with file metadata
Figure out how to deal with activity search

Pull Request Test Coverage Report for Build 1323

0 of 0   changed or added relevant lines in 0 files are covered.
26 unchanged lines in 4 files lost coverage.
Overall coverage decreased (-0.8%) to 94.828%

Files with Coverage Reduction
New Missed Lines
%

test/controllers/activities_controller_test.rb
1
91.67%

../models/investigation.rb
1
98.94%

../controllers/investigations/activities_controller.rb
6
59.09%

test/models/investigation_test.rb
18
72.31%

Totals

Change from base Build 1318:
-0.8%

Covered Lines:
2512

Relevant Lines:
2649

💛  - Coveralls


refactor: Refactor to custom exception

Pull Request Test Coverage Report for Build #238
Details

0 of 0   changed or added relevant lines in 0 files are covered.
6 unchanged lines in 2 files lost coverage.
Overall coverage increased (+2.7%) to 81.876%

Files with Coverage Reduction
New Missed Lines
%

../../../.gradle/daemon/8.9/util/src/main/kotlin/com/lomeone/util/exception/CustomException.kt
1
90.91%

../../../.gradle/daemon/8.9/application/src/main/kotlin/com/lomeone/application/rest/controlleradvice/ExceptionControlAdvice.kt
5
5.0%

Totals

Change from base Build #236:
2.7%

Covered Lines:
384

Relevant Lines:
469

💛  - Coveralls


KeyError in pandas.io.gbq.read_gbq when no DataFrame should be returned

Problem description
I am trying to use the read_gbq function from pandas.io.gbq as a means to execute INSERT or UPDATE queries on BigQuery. These queries do not return anything and so there is nothing for pandas to retrieve and return to my program, and so my expected output for something like this would be that no dataframe is returned (ie. it should ideally return None), instead of throwing a KeyError despite the fact that the INSERT or UPDATE statement executed successfully.
Code Sample
from pandas.io import gbq

insert_or_update_statement = r"""
INSERT INTO `MyBigQueryTable` (ColumnA, ColumnB, ColumnC) (
    SELECT ColumnA, ColumnB, ColumnC
    FROM `AnotherBigQueryTable`
    WHERE ColumnD = 4
        AND ColumnC = ColumnE + 1
)"""
gbq.read_gbq(insert_or_update_statement, project_id='my-project', dialect='standard')

Actual vs Expected Output
Expected that None would be returned for INSERT or UPDATE statements that don't have any results to retrieve. Actual output is as follows:
    453             self._print('Retrieving results...')
    454
--> 455         total_rows = int(query_reply['totalRows'])
    456         result_pages = list()
    457         seen_page_tokens = list()

KeyError: 'totalRows'

Current Workaround
from pandas.io import gbq

# The statement executes successfully even though a KeyError is raised.
try:
    gbq.read_gbq(insert_or_update_statement, project_id='my-project', dialect='standard')
except KeyError:
    pass

Proposed Solution
This could be fixed in a fairly simple manner by catching the KeyError right there, skipping the row retrieval parts, and returning None. I would be happy to create a pull request to resolve this.

I suppose this would be ok. most sql interfaces expose something like .execute_sql() to do this (which might be ok/better).
cc @parthea

Though why use pandas if you only want to send a query? Why not use the bigquery python library?

@MaximilianR That is definitely a very good point. I am working in a development environment where it is much harder to set-up and use the BigQuery python library directly, but I also feel that it is a good idea to be able to execute insert and update statements from pandas.
@jreback Thanks so much for the help! Please do let me know what would be the best way to go ahead on this.

I tested this locally; it does work, though it also returns the entire new table, which likely isn't desired. I'll leave this open.


Test on GitHub Actions

This tests with the same as Travis CI, and I replaced nightly with 3.10-dev, the nearest equivalent.
Example: https://github.com/hugovk/twitter/actions/runs/360319693
They fail for me because:
details: {u'errors': [{u'message': u'User is over daily status update limit.', u'code': 185}]}

Will try again tomorrow.

Yep, too many tests ran today with the account, will need to retry later

Coverage decreased (-1.7%) to 28.487% when pulling a74ada3ce4ba7ca0a21973fd6967bd3a54efc809 on hugovk:add-gha into 422ff7038af543d5864fd5bc09d860fd115f32b4 on sixohsix:master.

Hey Hugo,
Sorry with my merges and your push, I guess finding a window for the tests was not easy. Can you ask for a rebuild on your github actions tryout?
Then if it's successful, I guess we should prepare a merge by removing the .travis file first and the relative badge in the readme. Do you know if there is a way to keep some kind of badge as well with GH Actions?

Hi, no problem!
I restarted a build:
https://github.com/hugovk/twitter/actions/runs/363545104
Some passed, some failed. I'll check the failures tomorrow.
Yes, it has a badge, will be something like:
![Test](https://github.com/sixohsix/twitter/workflows/Test/badge.svg)

Looking at the test account, it seems like all python versions run simultaneously which might be an issue with the API limits, it is possible to set them to run successively instead of in parallel?

Good idea! Yes, it's possible with jobs.<job_id>.strategy.max-parallel:
https://docs.github.com/en/free-pro-team@latest/actions/reference/workflow-syntax-for-github-actions#jobsjob_idstrategymax-parallel
Updated, and that helped:

https://github.com/hugovk/twitter/actions/runs/366124382

2.7 and PyPy2 fails due to:
CoverallsException: Not on TravisCI. You have to provide either repo_token in .coveralls.yml or set the COVERALLS_REPO_TOKEN env var.
I'll check that (I'm mostly using Codecov on other projects). Maybe using https://github.com/coverallsapp/github-action or https://github.com/AndreMiras/coveralls-python-action instead will help.

Got Coveralls working with https://github.com/AndreMiras/coveralls-python-action:

https://github.com/hugovk/twitter/actions/runs/366327891
https://coveralls.io/builds/34999614

Yeah !  \o/
So I guess we're nearly good to merge?
Do you wanna add the badge change and the travis removal within the PR first, and maybe rename the action as "Tests" with a final "s"?

Yes, I think we're good to merge! I've remove .travis.yml and updated the badge here.

And out of curiosity, could you tell me what do the pip-cache and actions/cache serve for exactly?

Sure, they're for caching the pip downloads, so they don't need to be downloaded from PyPI each time.
PyPI costs $800k/month in hosting! (In March 2020, will be higher now):

https://twitter.com/dstufft/status/1236331765846990848

I believe this is generously donated by Fastly, but it would be good to help reduce it where possible, and CIs will contribute quite a lot.

The config is in two parts:
      - name: Get pip cache dir
        id: pip-cache
        run: |
          echo "::set-output name=dir::$(pip cache dir)"

First, we check the pip cache directory by calling pip cache dir and saving the output in a variable called dir; we can refer back to it in later steps as steps.pip-cache.outputs.dir.
Strictly speaking, this is only needed when testing on multiple operating systems, we could hardcode it as we're only testing on Linux.
More info:

https://github.com/actions/cache/blob/main/examples.md#python---pip

      - name: Cache
        uses: actions/cache@v2
        with:
          path: ${{ steps.pip-cache.outputs.dir }}
          key:
            ${{ matrix.os }}-${{ matrix.python-version }}-v1-${{ hashFiles('**/setup.py') }}
          restore-keys: |
            ${{ matrix.os }}-${{ matrix.python-version }}-v1-

Next, we use the https://github.com/actions/cache action to fetch cache at the start, and potentially save a new cache at the end.
path is the pip dir we saved from the first bit.
key is an ID generated and used when saving the cache. We put in the OS and Python version, to make sure we don't mix and match caches between other OS and Python versions (we could remove OS, as we test use Linux right now). We also hash the setup.py file so a new cache is created when dependencies change. Often dependencies are listed in setup.py or requirements.txt. Now I check, there's actually none listed in setup.py and there is no requirements.txt, so this could be removed, although I doubt it makes too much difference. Finally, the v1 is there as an easy way to invalidate an old cache and force a new one to be created; because GHA doesn't have a UI to delete old caches.
restore-keys is a list of substrings to match old cache names, in case there's none matching key.

So we could reduce those two chunks to something like:
      - name: Cache
        uses: actions/cache@v2
        with:
          path: ~/.cache/pip
          key:
            ${{ matrix.python-version }}-v1-${{ hashFiles('**/setup.py') }}
          restore-keys: |
            ${{ matrix.python-version }}-v1-

Ha great, so it's a cache across successive action runs, I wouldn't even have thought it was possible and was not understanding how caching would work across different python versions :)
Makes total sense now, thanks a lot for the explanations, very useful!

And of course we already sent too many tweets for the day, will rerun the action for the badge to display properly tomorrow!

And now we're finally good! :)
Thx again for this long run :)

Great, happy to help! And thank you for maintaining this library!

Now we really need to bother @sixohsix one more time and ask for a release, or better rights on pypi ;)


Make app store buttons more prominent by inverting colors

Closing, because it's superceded by #180


.nz domain updates

Add .nz 1st level suffix
Adds missing cri.nz 2nd level suffix
Fix typos in parliament.nz and "New Zealand"
Add link to .nz details

I see that CONTRIBUTING.md says

Avoid changing existing sets of data. Some developers use Faker with seeding for unit tests ; changing the data makes their tests fail.

Is the above OK by this restriction?

Well, since you fix a typo in the same time (parliment => parliament), yes ;)

Thanks!


Mistake in  /keep/:name/:from

In /keep/:name/:from, shouldn't it be  ':name , F*ck off. And when you get there...' instead of  ':name: F*ck off. And when you get there...' ? So, a comma instead of a colon

Although I agree with you, I don't think the correction merits changing the API - such a correction could be called pedantic - the endpoint has been in service for some time now and I don't want to risk downstream consumer problems.


Fastnlight: Watch argroupofeducation.com

Fastnlight requests the watch of the watch_keyword argroupofeducation\.com. See the MS search here and the Stack Exchange search in text, in URLs, and in code.

argroupofeducation\.com has been seen in 0 true positives, 0 false positives, and 0 NAAs.

Approved by Jeff Schaller in Charcoal HQ


Why this pointing to global context is giving undefined, even when global variable is defined ?

this is my program

var status = "online"

setTimeout(() => {

    const status = "offline"

    const data = {
        status: "not responding",
        getStatus(){
            return this.status;
        }
    }

    console.log(data.getStatus())
    console.log(data.getStatus.call(this))

}, 0);

why  console.log(data.getStatus.call(this)) is returning undefined ?

the reason it was returning undefined is that regular functions in Javascript have their own this context which does not automatically refer to the lexical scope of where they are defined that is why as ManjulaP1012 said that using arrow function will resolve it.

@ManjulaP1012 actually the expected output should be "online" as this is pointing to global object status. but I'm not understanding why its returning undefined

It should work, you can see the working example here
But if you use some builders like webpack or ecosystems like codesandbox it'll not work, cose they wrap your code in IIFE


Can I use it to initialize the Editor?  defaultEditorState

Through the constructor initialization state,
const sampleMarkup = '
Bold textbaidu.com

';
const contentBlock = htmlToDraft(sampleMarkup);
if (contentBlock) {
    const contentState = ContentState.createFromBlockArray(contentBlock.contentBlocks);
    this.state.initState = EditorState.createWithContent(contentState);
}

Initialize shows that there is no problem, but when the editor be focused, and show some error tips

full code：
import React, {Component, PropTypes} from 'react';
import {Editor} from 'react-draft-wysiwyg';
import draftToHtml from 'draftjs-to-html';
import htmlToDraft from 'html-to-draftjs';
import {convertToRaw, convertFromHTML, ContentState, EditorState} from 'draft-js';
import uploadImageCallBack from './plugins/UploadImageEditor';
import './RichTextEditor.css';

class RichTextEditor extends Component {

  constructor(props) {
    super(props);
    const sampleMarkup = '
Bold textbaidu.com

';
    const contentBlock = htmlToDraft(sampleMarkup);
    if (contentBlock) {
      const contentState = ContentState.createFromBlockArray(contentBlock.contentBlocks);
      this.state.initState = EditorState.createWithContent(contentState);
    }
  };
  static propTypes = {
    onChange: PropTypes.func,
    value: PropTypes.string
  };
  state = {
    outputEditorState: undefined
  };
  onEditorStateChange = function(inputEditorState) {
    const rawContent = convertToRaw(inputEditorState.getCurrentContent());
    const html = draftToHtml(rawContent);
    const contentBlock = htmlToDraft(html);
    if (contentBlock) {
      const contentState = ContentState.createFromBlockArray(contentBlock.contentBlocks);
      const outputEditorState = EditorState.createWithContent(contentState);
      this.setState({inputEditorState, outputEditorState});
    }
    if (typeof this.props.onChange === 'function') {
      this.props.onChange(html);
    }
  };

  render() {
    return (<Editor onEditorStateChange={this.onEditorStateChange.bind(this)} editoerState={this.state.outputEditorState} defaultEditorState={this.state.initState} uploadCallback={uploadImageCallBack} wrapperClassName="global-rte-class" editorClassName="editor-class" toolbarClassName="toolbar-class"/>);
  }
};
export default RichTextEditor;

Thanks

Try this:
Bold textbaidu.com

.
Atm, the lib works only with the tags generated by the editor. But I am open to suggestions to add support for more tags.

This lib is lacking in documentation, I will add that soon.

Seems to be still the same problem, change to
123
  is the same error on editor focused.

Initializing like this in constructor works for me:
constructor(props) {
  super(props)
  const html = '
123
'
  const contentBlock = htmlToDraft(html);
  if (contentBlock) {
    const contentState = ContentState.createFromBlockArray(contentBlock.contentBlocks);
    const outputEditorState = EditorState.createWithContent(contentState);
    this.state = {
      outputEditorState,
    };
  }
}

I do not get any error on focus, but I see there is issue in block structure around image. I will fix that.

I am using the Editor  defaultEditorState  attribute to initialize the Editor .  Has something to do with this?

Check this typo editoerState={this.state.outputEditorState}.
Using defaultEditorState is ok but you should not use both defaultEditorState  and editorState .

+1
convertFromDraftStateToRaw.js?521a:44 Uncaught TypeError: Cannot read property 'toObject' of undefined(…)

+1
getting the same error message as well. It seems ok upon initialising but once focused, the error occurs.

@saymy, @kcabading : this lib is made for use with html generated by react-draft-wysiwyg. Can you plz check and confirm that you are using html from editor only.
Also, this file has example use you can refer: https://github.com/jpuri/html-to-draftjs/blob/master/src/index.js
Let me know if issue still persists.

@jpuri I have the same issue here. I change the demo to this:
// in constructor, I use your code above, but I change outputEditorState to inputEditorState
// in the first Editor, I use this.state.inputEditorState as editorState

class Playground extends Component {

  // state = {
  //   outputEditorState: undefined,
  // }

  constructor(props) {
    super(props)

    const html = '
123
'
    const contentBlock = htmlToDraft(html);
    if (contentBlock) {
      const contentState = ContentState.createFromBlockArray(contentBlock.contentBlocks);
      const inputEditorState = EditorState.createWithContent(contentState);
      this.state = {
        inputEditorState,
      };
    }
  }

  onInputEditorChange = (inputEditorState) => {
    const rawContent = convertToRaw(inputEditorState.getCurrentContent());
    const html = draftToHtml(rawContent);
    const contentBlock = htmlToDraft(html);
//    console.log('1', contentBlock)
    // console.log('2', convertFromHTML(html) && convertFromHTML(html))
    if (contentBlock) {
      const contentState = ContentState.createFromBlockArray(contentBlock.contentBlocks);
      const outputEditorState = EditorState.createWithContent(contentState);
      this.setState({
        inputEditorState,
        outputEditorState,
      });
      console.log('1', inputEditorState.getCurrentContent().getBlocksAsArray())
      console.log('2', contentBlock.contentBlocks)
    }
  }

  render() {
    return (

          <Editor
            editorState={this.state.inputEditorState}
            onEditorStateChange={this.onInputEditorChange}
            mention={{
              separator: ' ',
              trigger: '@',
              suggestions: [
                { text: 'A', value: 'a', url: 'href-a' },
                { text: 'AB', value: 'ab', url: 'href-ab' },
                { text: 'ABC', value: 'abc', url: 'href-abc' },
                { text: 'ABCD', value: 'abcd', url: 'href-abcd' },
                { text: 'ABCDE', value: 'abcde', url: 'href-abcde' },
                { text: 'ABCDEF', value: 'abcdef', url: 'href-abcdef' },
                { text: 'ABCDEFG', value: 'abcdefg', url: 'href-abcdefg' },
              ],
            }}
          />

          <textarea
            disabled
            className="demo-content"
            value={this.state.inputEditorState && draftToHtml(convertToRaw(this.state.inputEditorState.getCurrentContent()))}
          />

          <Editor
            editorState={this.state.outputEditorState}
            mention={{
              separator: ' ',
              trigger: '@',
              suggestions: [
                { text: 'A', value: 'a', url: 'href-a' },
                { text: 'AB', value: 'ab', url: 'href-ab' },
                { text: 'ABC', value: 'abc', url: 'href-abc' },
                { text: 'ABCD', value: 'abcd', url: 'href-abcd' },
                { text: 'ABCDE', value: 'abcde', url: 'href-abcde' },
                { text: 'ABCDEF', value: 'abcdef', url: 'href-abcdef' },
                { text: 'ABCDEFG', value: 'abcdefg', url: 'href-abcdefg' },
              ],
            }}
          />

    );
  }
}

Then I will get the same error. I think you can reproduce the issue by this

Thanks for reporting @ShallmentMo , let me check this.

@jpuri In convertFromDraftStateTorRaw.js file, line 44, I change data: block.getData().toObject() to data: block.getData() ? block.getData().toObject() : {},. It seems to be OK. I will try to do this, because I'm kind of in a hurry. But I don't know if there are some side effects. If there are, please let me know.

I am looking into the issue, one point I want to say as I mentioned here https://github.com/jpuri/html-to-draftjs/issues/3#issuecomment-275067546, if you are using HTML format just to save content in DB, reconsider it.

Hey @raisezhang , @saymy , @kcabading , @ShallmentMo : apologies for inconvenience. I could finally replicate it and just released 0.1.0-beta3 with the fix. Issue was coming from function convertToRaw of draft-js which expected a value which the lib was returning undefined.

Also, I am looking forward to more feedbacks to improve this lib, its still in beta.

@jpuri  MENTION PLUGIN STOPS WORKING-
.
i am getting a simple test like paragraph from draftjs to html,
and when  i am converting html to draftjs state ,
and setting it to container , my containers mention plugin stops working .
any idea why it is happening?


failed to run pycolmap.incremental_mapping: F20230221 11:49:22.759709 1251534 bundle_adjustment.cc:304] Check failed: solver_options.IsValid(&solver_error) Invalid configuration. Solver::Options::eta = 0. Violated constraint: Solver::Options::eta > 0.0

Hello, I run pycolmap.incremental_mapping, but it failed, the error shows:
[2023/02/21 11:49:18 hloc INFO] Running 3D reconstruction...
WARNING: Logging before InitGoogleLogging() is written to STDERR
F20230221 11:49:22.759709 1251534 bundle_adjustment.cc:304] Check failed: solver_options.IsValid(&solver_error) Invalid configuration. Solver::Options::eta = 0. Violated constraint: Solver::Options::eta > 0.0
*** Check failure stack trace: ***
How should I do?

Here is the check that failed: https://github.com/ceres-solver/ceres-solver/blob/095d483927d26bffc36d1fcc5fe8e2f1ef7da6b0/internal/ceres/solver.cc#L402, for Solver::Options::eta defined here. Its default is 1e-1, COLMAP doesn't modify it, and PyCOLMAP doesn't expose it - so I don't see how it could get this value.

我已收到文件，谢谢！


Cannot install on Python 3.13

There is no wheel for Python 3.13.

It has been on my TODO list for quite some time but quite low priority.
If anyone wants to try and make a Python 3.13 build, happy to make a review.


Rename KeyVault secret ReadMe

Renaming this file has broken existing links. e.g. - https://github.com/Azure/azure-sdk-for-net where the link to the Readme was included.

Renaming this file has broken existing links. e.g. - https://github.com/Azure/azure-sdk-for-net where the link to the Readme was included.

Thanks for pointing that out, I will update the link.


How to use this skript

Hello Community,
sorry I am a really beginner in the world of iobroker.
I have severel things already relised and now I found the Automower adapter.
How I have to use this script/files to get it running?
Thanks for your support.

I have no idea if it still works.  I haven't used my automower in years so I can't test it.  This was mostly an attempt to share reverse-engineering their API with anyone who wanted a starting point to turn it into a usable library.
If you really want to try, you'd need to copy the example config to config.js, fill it out, and you could run node index.js to see if it parks your mower.

Hi!
It doesn't seem to work anymore.
node index.js
Logged on. Checking for mowers.
404
undefined


Upgrade repo to latest azd/infra/core

This repo uses an old version of azd/infra/core.  There have been many improvements and security updates since this version. Please upgrade to latest found here:
https://github.com/Azure/azure-dev/tree/main/templates/common/infra/bicep
Good example of swa: https://github.com/Azure/azure-dev/blob/main/templates/todo/projects/nodejs-mongo-swa-func/.repo/bicep/infra/main.bicep
Good example of aca: https://github.com/Azure/azure-dev/blob/main/templates/todo/projects/nodejs-mongo-aca/.repo/bicep/infra/main.bicep

@jongio I updated all templates and added the required user assigned identity for the container apps in this branch: https://github.com/Azure-Samples/azure-search-openai-javascript/tree/infra-update
But when deploying I get this error:

Did I missed something? Thanks for your help

@sinedied @jongio Any updates here?

Can you make sure you have the latest infra/core (it may have changed since your last sync).
Also, please compare your bicep with the bicep from the other azure-search-openai templates that use aca.


.asmdef should be "RoyTheunissen.Graphing" to be consistent

Hello, I think the .asmdef for this project should be "RoyTheunissen.Graphing" to be consistant with the package name :

Since FMODSyntax follows that principle

Hey Alexandre! Slow response because it's been a very busy week, but I've gone through the repositories I'm actively working on and updated the .asmdefs to use the RoyTheunissen. prefix as suggested.
Thanks for reporting it 👍


Add more feedback - show diff of expected/obtained ouptut

verify only says to me:
# FAIL

Your solution didn't match the expected output.

Yes, this is a problem for solving things like the stacktrace challenge


Remove browser warning in unset_cookie

Currently unset cookie returns this warning on firefox when used in http:
Cookie “<name-here>” will be soon rejected because it has the “sameSite” attribute set to “none” or an invalid value, without the “secure” attribute. To know more about the “sameSite“ attribute, read https://developer.mozilla.org/docs/Web/HTTP/Headers/Set-Cookie/SameSite
This particular cookie was set with secure=False, http_only=True, same_site="Strict" but I don't think how how it was previously set matters.
From the MDN documentation there seem to be two options to remove this warning:

Setsame_site to Strict or Lax
Set secure to True

Setting same_site seems preferable since secure can be set only in https for some cookie prefixes: https: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Set-Cookie#Cookie_prefixes
Since the cookie is removed after the response, setting same_site to Lax should probably be ok.

The unset cookies method should also accept a path and a domain. Otherwise cookies set with a particular path / domain cannot be unset.

So should unset cookie simply wrap set_cookie except force blank value and -1 expires?

This could be an option. But other than path and domain I'm not sure if any other options can effect the unset cookie. Same site can be set to a fixed value, since it's only used to make the browser accept the cookie.
Still, it may be simpler to just offer the same controls, so that if in the future browser implement other restrictions there is no need to modify this again.

I've updated the pr. I've opted for adding path and domain to unset_cookie


Add ability to cancel a scan in progress

Commit 027951d8542ab0cd162f9b832efd0d4a5db44f72 adds basic support, yet untested on rPi.

Tested on Pi.


How to parse abi hex string from the block?

when use
cleos get block 128

to retrive the block's data, it returns
...
{
              "account": "eosio",
              "name": "setabi",
              "authorization": [{
                  "actor": "eosio",
                  "permission": "active"
                }
              ],
              "data": {
                "account": "eosio",
                "abi": "0e656f73...72655f617574680000000000"

},
...

my question is how to generate json format file from the hex string of < acctions.data.abi >
python script is appretiated
thanks

@hashware Have you solved this problem? I also met this issue.

oh, I also met this issue.
https://github.com/EOSIO/eosjs/issues/436


How do I configure claim worlds?

Please make sure your issue complies with these guidelines:

[ ] Idea must have not been suggested previously

[ ] Be detailed on what you want & make sure the idea is plausible

Description
How can I configure the claim world?
I have not been able to figure out where I could configure the worlds that claiming is enabled...
Extra Information
None

All worlds allow claiming by default. You can blacklist certain worlds from claiming within the config.


Added roborock

RE-CHECK!

Automated adapter checker
No changed adapters found
Add comment "RE-CHECK!" to start check anew

First of all - THANK YOU for the time and effort you spend to maintain this adapter.
I would like to give some (preliminary) feedback based on my personal oppinion. This is NOT an offical review and @Apollon77 might have several additional suggestions or even a different oppinion to one or the other statement. Please feel free to contact him (or wait for a response from him) if you cannot follow my suggestsions or before you spend major effort.

sensitive information, especially passwords should be stored encrypted
You configuration seems to contain passwords (or other sensitive information) which is not stored encrypted. As long as those information is not stored inside a table you can encrypt and secure this infomation simply by adding the following configuration to io-package.json. The iob runtime will encrypt / decrypt the data as required; no addition programming effort is required. Note that users will need to reenter this info one time after adding encryption, so drop a note at release notes.
"encryptedNative": [
  "password",
  "data2"
],
"protectedNative": [
  "password",
  "data2"
],

consider using adapter.setTimeout / this.setTimeout instead of (standard) setTimeout
The adapter package provides wrapper routines for native setTimeout, setInterval, clearTimeout and clearInterval. Using those routines ensures that timers are cancelled on on load. Additional checks on thomse limits might be performed, too. So consider replacing native setTimeout/clearTimeout by adapter.setTimeout/adapter.clearTimeout or this.setTimeout/this.clearTimeout. The same refers to setInterval/clearInterval.

check and limit configurable timeouts / intervals
Node setTimeout/setInterval routines have a maximum allowed value of 2,147,483,647 ms. Using delays larger than 2,147,483,647 ms (about 24.8 days) result in the timeout being executed immediately. So all (user configurable) values passed to setTimeout / setInterval should be checked and limited.

check and limit intervals used to access cloud services
Limit all intervals used to access cloud services to a reasonable value. If users configure an inapprobiate access rate this could lead to suspending the service by the provider for all ioBroker users.

cancel all timers at unload
Your code seems to use setInterval to start polling. But there is no clearInterval at onUnload. Clearing all timers is essential to avoid memory leaks when running ion compact mode.

This adapter seems to use sentry, but no sentry info is added to Readme.md
This adapter seems to use sentry for error logging. Please add the suggested sentry information at the top of Readme.md
**This adapter uses Sentry libraries to automatically report exceptions and code errors to the developers.** For more details and for information how to disable the error reporting see [Sentry-Plugin Documentation](https://github.com/ioBroker/plugin-sentry#plugin-sentry)! Sentry reporting is used starting with js-controller 3.0.

This adapter seems to implement sentry by itself and seems to be not using the sentry plugin.
Sentry should / must be an option for users so disabling sending any information to remote locations should be controllable by users. At least the user must be informed aboiut the fact that any data is transmitted. Please consider using the provides ioBroker sentry plugin which will handle opting out of sentry.

Thanks for reading and evaluating this suggestions.
McM1957

Hi. Thank you for your suggestions. I took care of (almost) all of them.

sensitive information, especially passwords should be stored encrypted -> fixed
consider using adapter.setTimeout / this.setTimeout instead of (standard) setTimeout -> done
cancel all timers at unload -> done
This adapter seems to use sentry, but no sentry info is added to Readme.md -> done
This adapter seems to implement sentry by itself and seems to be not using the sentry plugin. -> done

Thank for your effort and for spending tim efor ioBroker adapters!
Hope this makes the official review faster and with less comments.

RE-CHECK!

Automated adapter checker
No changed adapters found
Add comment "RE-CHECK!" to start check anew

RE-CHECK!

Automated adapter checker
ioBroker.lightify

[ ] :heavy_exclamation_mark: [E019] Invalid repository URL in package.json: https://github.com/soef/iobroker.lightify. Expected: git@github.com:soef/ioBroker.lightify.git or https://github.com/soef/ioBroker.lightify.git
[ ] :heavy_exclamation_mark: [E104] No "common.titleLang" found in io-package.json
[ ] :heavy_exclamation_mark: [E114] No adapter are allowed in the repo without admin support (set "common.noConfig = true" and "common.adminUI.config = none" if adapter has no configuration)
[ ] :heavy_exclamation_mark: [E115] No license found in io-package.json
[ ] :heavy_exclamation_mark: [E150] No common.connectionType found in io-package.json
[ ] :heavy_exclamation_mark: [E152] No common.dataSource found in io-package.json
[ ] :eyes: [W171] "common.title" is deprecated in io-package.json
[ ] :eyes: [W109] "common.desc" should be translated into all supported languages (en, de, ru, pt, nl, fr, it, es, pl, uk, zh-cn)
[ ] :eyes: [W170] "common.keywords" should not contain "iobroker, adapter, smart home" io-package.json
[ ] :eyes: [W113] Adapter should support compact mode
[ ] :eyes: [W156] Adapter should support admin 5 UI (jsonConfig) if you do not use a React based UI
[ ] :eyes: [W145] Each "common.news" should be translated into all supported languages (en, de, ru, pt, nl, fr, it, es, pl, uk, zh-cn)
[ ] :eyes: [W145] Each "common.news" should be translated into all supported languages (en, de, ru, pt, nl, fr, it, es, pl, uk, zh-cn)
[ ] :eyes: [W145] Each "common.news" should be translated into all supported languages (en, de, ru, pt, nl, fr, it, es, pl, uk, zh-cn)
[ ] :eyes: [W145] Each "common.news" should be translated into all supported languages (en, de, ru, pt, nl, fr, it, es, pl, uk, zh-cn)
[ ] :eyes: [W145] Each "common.news" should be translated into all supported languages (en, de, ru, pt, nl, fr, it, es, pl, uk, zh-cn)
[ ] :eyes: [W145] Each "common.news" should be translated into all supported languages (en, de, ru, pt, nl, fr, it, es, pl, uk, zh-cn)
[ ] :eyes: [W145] Each "common.news" should be translated into all supported languages (en, de, ru, pt, nl, fr, it, es, pl, uk, zh-cn)
[ ] :eyes: [W145] Each "common.news" should be translated into all supported languages (en, de, ru, pt, nl, fr, it, es, pl, uk, zh-cn)
[ ] :eyes: [W145] Each "common.news" should be translated into all supported languages (en, de, ru, pt, nl, fr, it, es, pl, uk, zh-cn)
[ ] :eyes: [W145] Each "common.news" should be translated into all supported languages (en, de, ru, pt, nl, fr, it, es, pl, uk, zh-cn)
[ ] :eyes: [W145] Each "common.news" should be translated into all supported languages (en, de, ru, pt, nl, fr, it, es, pl, uk, zh-cn)
[ ] :eyes: [W145] Each "common.news" should be translated into all supported languages (en, de, ru, pt, nl, fr, it, es, pl, uk, zh-cn)
[ ] :eyes: [W145] Each "common.news" should be translated into all supported languages (en, de, ru, pt, nl, fr, it, es, pl, uk, zh-cn)
[ ] :eyes: [W145] Each "common.news" should be translated into all supported languages (en, de, ru, pt, nl, fr, it, es, pl, uk, zh-cn)
[ ] :eyes: [W145] Each "common.news" should be translated into all supported languages (en, de, ru, pt, nl, fr, it, es, pl, uk, zh-cn)
[ ] :eyes: [W145] Each "common.news" should be translated into all supported languages (en, de, ru, pt, nl, fr, it, es, pl, uk, zh-cn)

ioBroker.mihome-cloud

[ ] :heavy_exclamation_mark: [E405] Icon must be in the following path: https://raw.githubusercontent.com/TA2k/ioBroker.mihome-cloud/main/
[ ] :heavy_exclamation_mark: [E407] Meta URL (latest) must be equal to https://raw.githubusercontent.com/TA2k/ioBroker.mihome-cloud/main/io-package.json
[ ] :heavy_exclamation_mark: [E426] Icon (stable) must be in the following path: https://raw.githubusercontent.com/TA2k/ioBroker.mihome-cloud/main/
[ ] :heavy_exclamation_mark: [E428] Meta URL (stable) must be equal to https://raw.githubusercontent.com/TA2k/ioBroker.mihome-cloud/main/io-package.json
[ ] :heavy_exclamation_mark: [E606] Current adapter version 0.1.0 not found in README.md
[ ] :eyes: [W171] "common.title" is deprecated in io-package.json
[ ] :eyes: [W105] "common.titleLang" should be translated into all supported languages (en, de, ru, pt, nl, fr, it, es, pl, uk, zh-cn)
[ ] :eyes: [W109] "common.desc" should be translated into all supported languages (en, de, ru, pt, nl, fr, it, es, pl, uk, zh-cn)
[ ] :eyes: [W145] Each "common.news" should be translated into all supported languages (en, de, ru, pt, nl, fr, it, es, pl, uk, zh-cn)
[ ] :eyes: [W145] Each "common.news" should be translated into all supported languages (en, de, ru, pt, nl, fr, it, es, pl, uk, zh-cn)
[ ] :eyes: [W145] Each "common.news" should be translated into all supported languages (en, de, ru, pt, nl, fr, it, es, pl, uk, zh-cn)
[ ] :eyes: [W515] Why you decided to disable i18n support?

ioBroker.roborock

:thumbsup: No errors found

[ ] :eyes: [W400] Cannot find "roborock" in latest repository

ioBroker.semp

[ ] :heavy_exclamation_mark: [E201] Bluefox was not found in the collaborators on NPM!. Please execute in adapter directory: npm owner add bluefox iobroker.semp
[ ] :heavy_exclamation_mark: [E506] Word "DeviceSwitchOffAtEndOfTimer" is not translated to german in admin/words.js. You can use https://translator.iobroker.in/ for translations
[ ] :heavy_exclamation_mark: [E506] Word "DeviceSwitchOffAtEndOfTimer" is not translated to russian in admin/words.js. You can use https://translator.iobroker.in/ for translations
[ ] :eyes: [W156] Adapter should support admin 5 UI (jsonConfig) if you do not use a React based UI
[ ] :eyes: [W202] Version of package.json (1.2.0) doesn't match latest version on NPM (1.0.0)

ioBroker.vis-2-widgets-gauges

[ ] :heavy_exclamation_mark: [E114] No adapter are allowed in the repo without admin support (set "common.noConfig = true" and "common.adminUI.config = none" if adapter has no configuration)
[ ] :heavy_exclamation_mark: [E162] onlyWWW should have common.mode "none" in io-package.json
[ ] :heavy_exclamation_mark: [E124] Main file not found under URL: https://raw.githubusercontent.com/ioBroker/ioBroker.vis-2-widgets-gauges/main/main.js
[ ] :heavy_exclamation_mark: [E504] "main.js" found in package.json, but not found as file
[ ] :heavy_exclamation_mark: [E802] No topics found in the repository. Please go to "https://github.com/ioBroker/ioBroker.vis-2-widgets-gauges", press the settings button beside the about title and add some topics.
[ ] :eyes: [W171] "common.title" is deprecated in io-package.json
[ ] :eyes: [W105] "common.titleLang" should be translated into all supported languages (en, de, ru, pt, nl, fr, it, es, pl, uk, zh-cn)
[ ] :eyes: [W109] "common.desc" should be translated into all supported languages (en, de, ru, pt, nl, fr, it, es, pl, uk, zh-cn)
[ ] :eyes: [W156] Adapter should support admin 5 UI (jsonConfig) if you do not use a React based UI
[ ] :eyes: [W513] "gulpfile.js" found in repo! Think about migrating to @iobroker/adapter-dev package

ioBroker.vis-2-widgets-material

[ ] :heavy_exclamation_mark: [E114] No adapter are allowed in the repo without admin support (set "common.noConfig = true" and "common.adminUI.config = none" if adapter has no configuration)
[ ] :heavy_exclamation_mark: [E162] onlyWWW should have common.mode "none" in io-package.json
[ ] :heavy_exclamation_mark: [E142] logo is too big. It must be less or equal than 512x512
[ ] :heavy_exclamation_mark: [E124] Main file not found under URL: https://raw.githubusercontent.com/ioBroker/ioBroker.vis-2-widgets-material/main/main.js
[ ] :heavy_exclamation_mark: [E504] "main.js" found in package.json, but not found as file
[ ] :heavy_exclamation_mark: [E801] No repository about text found. Please go to "https://github.com/ioBroker/ioBroker.vis-2-widgets-material", press the settings button beside the about title and add the description.
[ ] :heavy_exclamation_mark: [E802] No topics found in the repository. Please go to "https://github.com/ioBroker/ioBroker.vis-2-widgets-material", press the settings button beside the about title and add some topics.
[ ] :eyes: [W171] "common.title" is deprecated in io-package.json
[ ] :eyes: [W105] "common.titleLang" should be translated into all supported languages (en, de, ru, pt, nl, fr, it, es, pl, uk, zh-cn)
[ ] :eyes: [W109] "common.desc" should be translated into all supported languages (en, de, ru, pt, nl, fr, it, es, pl, uk, zh-cn)
[ ] :eyes: [W156] Adapter should support admin 5 UI (jsonConfig) if you do not use a React based UI
[ ] :eyes: [W513] "gulpfile.js" found in repo! Think about migrating to @iobroker/adapter-dev package

Add comment "RE-CHECK!" to start check anew

RE-CHECK!

Automated adapter checker
ioBroker.roborock

:thumbsup: No errors found

[ ] :eyes: [W400] Cannot find "roborock" in latest repository

Add comment "RE-CHECK!" to start check anew

Please remove node 14 from test-and-release.yml and (optionally) add node 20 to testing matrix.
Node 14 is no longer supported and tests will fail since 22.5.2023.
Thanks
McM1957

Sure. How do make this change appear here?

Sure. How do make this change appear here?

simply change it at your repository at main/master branch (edit and commit workflows/test-and-release.yml)
Head revision will be used for github actions

Done.

I've done a recheck of my comments from february. Thanks for applying 99% of my suggestions.
The following suggestion has not been applied yet:

check and limit configurable timeouts / intervals

Node setTimeout/setInterval routines have a maximum allowed value of 2,147,483,647 ms. Using delays larger than 2,147,483,647 ms (about 24.8 days) result in the timeout being executed immediately. So all (user configurable) values passed to setTimeout / setInterval should be checked and limited.
Did I miss something when reading the code?
Currently the intervall values seem to have no limit - neither at jsonCponfig nor inside code. This could result in someone entering zero or even a negative value which in turn could easily overload the ioBroker installation or the target device. So I would suggest to add limits at jsonConfig (min attribute / eventually max attribute) and preferable at code too.
Otherwise everything looks fine for me - but it would be no surprise if apollon77 sees something additional :-)

Do you mean the ones the user can set in the options of the adapter?

Fixed via https://github.com/copystring/ioBroker.roborock/commit/0e4f5d385faaf5a3ac417a63434043e32c3c5dd8

Yes I refer to the interval limits the user can set via config page.
I'm not sure whether setting limits inside io-config.json works; I will have to check this myself. Nerver done there until now.
 You find examples for jsonConfig at mcm57/ioBroker.jsonConfig-demo "adapter". But I'm not sure wthere limiting example is implemented yet.
Please simply try whether you can inster 0 or a negative value into the instance config or use increment / decrement to reach too small values and try to store such a config. If it fails - evrything ok.

I can confirm this works just fine. It is not possible to enter a value below or above min/max.


CodeFormatter requires Visual Studio 2015

https://github.com/dotnet/codeformatter
Nether requires Visual Studio 2017. Currently requires installing 2015 alongside to allow codeformatter review.

See https://github.com/dotnet/codeformatter/issues/199

I made a custom build of CodeFormatter using VS2017 and targetting .NET 4.6, and @krist00fer tested this and reported it working. I will package that somewhere accessible and then temporarily update the RunCodeFormatter.ps1 script to use that version. Once CodeFormatter has a release that supports .NET 4.6 we can revert the script to the official release location.

#454 contains a change to use the custom build (hosted on Azure Storage).
If you already have CodeFormatter downloaded (i.e. you have previously run RunCodeFormatter.ps1) then run RunCodeFormatter.ps1 -ForceCodeFormatterDownload once to download the updated build


issue running the make file

Description
On Sept 27. I installed openlane and went through the instructions posted on the git-hub:
cd $HOME
git clone https://github.com/The-OpenROAD-Project/OpenLane OpenLane_git
cd OpenLane
make
make test

Note that for no good reason I decided to call my cloned directory OpenLabe_git (rather than just OpenLane)
Everything runs as expected.
Today (Oct 4, 2024) I repeated the exact same steps on the same machine (calling the cloned directory OpenLane to do do not overwrite the old one).
cd $HOME
git clone https://github.com/The-OpenROAD-Project/OpenLane
cd OpenLane
make
make test

When running make the "process" exits with ERRORS
If I cd in OpenLane_git and run make and make test everything still works fine (from within the old repository)
There seem to be changes in the github that create an issue, but I am not able to identify them.
Expected Behavior
I expect the installation to be successfull as specified in the documentation.
Environment report
Kernel: Darwin v23.6.0
Distribution: macOS 14.6.1
Python: v3.11.5 (OK)
Container Engine: docker v24.0.6 (OK)
OpenLane Git Version: 1b3cf10884bfae06d8fedceb0d2debd97ea351dd
python-venv: INSTALLED
---
PDK Version Verification Status: OK
---
Git Log (Last 3 Commits)

1b3cf10 2024-10-02T11:10:31+03:00 bugfix: Replaced inappropriate `is` comparison with `==` (#2157) - Ataf Fazledin Ahamed -  (grafted, HEAD -> master, origin/master, origin/HEAD)
---
Git Remotes

origin	https://github.com/The-OpenROAD-Project/OpenLane (fetch)
origin	https://github.com/The-OpenROAD-Project/OpenLane (push)

Reproduction material
I did not add any file. I am just testing the installation with the defaults.
 As you use macOS, your installation of Nix cannot build the Linux-based Docker image.
The latest commit not being pushed to Dockerhub is a huge problem. I will address that immediately. Thank you for the bug report.

I manually just pushed the requisite images, so make should work for you now. I'll be addressing the root cause momentarily.

Thanks a lot,
Claudio
From: Mohamed Gaber @.>
Date: Friday, October 4, 2024 at 16:25
To: The-OpenROAD-Project/OpenLane @.>
Cc: Claudio Talarico @.>, Author @.>
Subject: Re: [The-OpenROAD-Project/OpenLane] issue running the make file (Issue #2159)
I manually just pushed the requisite images, so make should work for you now. I'll be addressing the root cause momentarily.
—
Reply to this email directly, view it on GitHubhttps://github.com/The-OpenROAD-Project/OpenLane/issues/2159#issuecomment-2394784429, or unsubscribehttps://github.com/notifications/unsubscribe-auth/A3NFX6YVWWMVUFL6JWMOH2DZZ4PYBAVCNFSM6AAAAABPMKVZOOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGOJUG44DINBSHE.
You are receiving this because you authored the thread.Message ID: @.***>

Fixed in 3876562d27af3f6825a823941b1cab36f7eb6dc3. Thank you!


bug: CLI Init Commands don't Work OOTB in PowerShell

Provide environment information
System:

OS: Windows 11 10.0.22621
CPU: (16) x64 AMD Ryzen 7 7800X3D 8-Core Processor
Memory: 27.07 GB / 63.15 GB

Binaries:

Node: 18.19.0 - C:\Program Files\nodejs\node.EXE
npm: 10.2.3 - C:\Program Files\nodejs\npm.CMD
pnpm: 8.15.1 - ~\AppData\Roaming\npm\pnpm.CMD

Describe the bug
In PowerShell, a token beginning with the '@' character is used for splatting, and is invalid for use when calling a standard executable.
For a (trivially) better DX, the package name in that command should be enclosed in quotes so that the command doesn't need to be edited before execution in PowerShell.

Reproduction repo
n/a
To reproduce

Go to Framework Setup and select a framework
Copy and paste the "Run the CLI 'init' command..." step into a PowerShell window

Additional information
No response

This is a good note 👍
For v3 the CLI will be called just trigger.dev. Will that work ok with Powershell @erin-allison? I assume dots are ok? Otherwise we could call it triggerdotdev.

Yes, dots are okay, and "@" signs in the middle of a string are fine, just not as the first character of a token.

Thanks! We didn't realise this until our first Powershell user started the CLI. It explains why CLIs are never namespaced packages on npm.

Thanks! We didn't realise this until our first Powershell user started the CLI. It explains why CLIs are never namespaced packages on npm.


feat(cli): Assertion signing keys and verification

Add option to the cli to pass in assertion verification keys, handles assertion signing keys passed in on encrypt

ignore extra commits, im trying to sign the autoformat unverified ones


Add database, role, warehouse to Snowflake credentials resource

Updated tests + make test
Also tested via Postman to make sure the API accepts role, database, warehouse with my own DBT Cloud account.

/ok-to-test sha=997f2bffa53b7b5e414e4e9d7243214937a9e18c

/ok-to-test sha=252b054e2caeba4a497d1f3ed045801edfceb092

/ok-to-test sha=91a0bc399a44039d059ff71eca652a6ea4eae734

/ok-to-test sha=262e9c84f08ce95e804a7e6b7111090aafc255f1

/ok-to-test sha=f9b92316cf6152975fb2cfe5c5d37a5e75bb6bd5

/ok-to-test sha=305447c60090cbd8700a49467630b76bdfc97b80

/ok-to-test sha=305447c60090cbd8700a49467630b76bdfc97b80


feat(global-shortcut): add plugin

I'm mostly just porting existing code to this repo for now, documentation is something we'll need to work a lot later. But i'll resolve these suggestions soon.


Support for google.rpc.Status

We would like to return richer errors using google.rpc.Status with additional details. Would it be possible to add this to the exception service interceptor?
We could write our own, but I assume others would like this too and might be nice to have as base functionality.
I don't mind putting up a PR, but would like your feedback first before I waste my time. Thanks!

I’m not sure I understand what kind of extensions you’re suggesting. Can you give an example?

Right now this only supports the basic string code and description error details. However I would like to use the richer error model here:
https://grpc.io/docs/guides/error/#richer-error-model
Which lets you also return further error details from here:
https://github.com/googleapis/googleapis/blob/master/google/rpc/error_details.proto
Here is a use case:
https://stackoverflow.com/a/55149655/2233608
Here are more details:
https://github.com/grpc/proposal/blob/master/L44-python-rich-status.md

Closing this as we can accomplish this by overriding the handle_exception method as described in #12


update the markdown file in the glossary directory for Chinese version.

update the markdown file in the glossary directory for Chinese version.

The preview doesn't look good to me. E.g.
https://deploy-preview-25244--kubernetes-io-master-staging.netlify.app/zh/docs/concepts/overview/components/
The glossary tooltip expects the markdown containing a header and some body contents. The header has to be what it is today.
What are we trying to fix with this PR?
/hold

page preview here are mostly broken:
https://deploy-preview-25244--kubernetes-io-master-staging.netlify.app/zh/docs/reference/glossary/

page preview here are mostly broken:
https://deploy-preview-25244--kubernetes-io-master-staging.netlify.app/zh/docs/reference/glossary/

performed update once more

/retest

/retest

/ok-to-test

/retest

/retest

/retest

/lgtm
/approve

/hold cancel


Improve function argument type inference

Consider the example:
// module1.ts
export function doOperation(
  options: string,
  callback: (argument: {
    prop1: number,
    prop2: string,
    prop3: SomeComplexInterface
  }) => any
) {
  // implementation is omitted
}

// module 2
import {doOperation} from "./module1"
doOperation("options", operationCallback);
function operationCallback(argument) {
  // argument has implicit type 'any' here
}

I suggest to improve type inference of operationCallback's arguments in this way:

If function don't has defined arguments
Take first usage of that function
Infer argument types from that usage

What do you think about it?

Personally, I think this would be confusing.
I understand the desire, as I sometimes find it annoying that I have to add extra annotations when refactoring, but without those annotations the extracted callback function becomes less readable. And inferring on first use makes reuse difficult, for example if the extracted function were a generic error handler that ignored its argument.
I would suggest the following:
// module1.ts
export function doOperation(
  options: string,
  callback: (argument: OperationCallbackArgument) => any
) { ... }

export interface OperationCallbackArgument {
    prop1: number,
    prop2: string,
    prop3: SomeComplexInterface
}

// module 2
import {doOperation, OperationCallbackArgument} from "./module1"

doOperation("options", operationCallback);

function operationCallback(argument: OperationCallbackArgument) {
    console.log(argument.prop1);
}

Long term, I think the language service will provide refactorings, such as "introduce local function".

Almost impossible in TypeScript, given current architecture.
Currently the compiler only infer local expression, the "bottom up" path, or contextually typing an expression, the "top down" path. Every expression is typed "locally".
What you ask for is global type inference: flow type information back to define site from use site. That's what TypeScript is designed to do. Try flowtype for similar feature (but that's not global inference either, flow just infers the argument type from function body)

duplicate of https://github.com/Microsoft/TypeScript/issues/15114?

Automatically closing this issue for housekeeping purposes. The issue labels indicate that it is unactionable at the moment or has already been addressed.


treewide: implement image editor

This PR implements #473

I'm reluctant to merge this because, as previously discussed, it goes beyond Stylix's goal of "take these theming items, and apply them everywhere".
If we were to instead provide the palette generator as a function, then you could simply call the palette generator with your original wallpaper, do whatever editing based on that palette, then set the final image as stylix.image.
In extension to this, removing the generated palette as the default for stylix.base16Scheme would resolve #437, since we can remove other complications in the code.
Assuming both of the above changes were made, the following combinations would be possible:

Manually choose a scheme (nothing new here){ pkgs, ... }:
{
  stylix.image = ./wallpaper.png;
  stylix.base16Scheme = "${pkgs.base16-schemes}/...";
}

Generate a scheme from the wallpaper (base16Scheme must now be set explicitly){ pkgs, config, ... }:
{
  stylix.image = ./wallpaper.png;
  stylix.base16Scheme = generatePalette config.stylix.image;
}

Generate a scheme from an image, then modify the image using that scheme, and set the result as the wallpaper (this is a new possibility){ pkgs, config, ... }:
{
  stylix.base16Scheme = generatePalette ./wallpaper.png;
  stylix.image = runLutgen ./wallpaper.png config.stylix.base16Scheme;
}

Where runLutgen is the image editor function from this PR and would be defined outside of Stylix

With the palette generator as a function, we could potentially move it to its own repository - it's only part of Stylix because it's been here since the very beginning. Image editor functions such as runLutgen could be distributed separately too.
All of the above can be implemented in two phases:

Copy the palette generator to a new repository, with its own project name, documentation, etc. This would export the generatePalette function described above
Remove the palette generator from Stylix. If base16Scheme is unset, the error message should direct users to the new repository

So in the end, Stylix would handle purely the "applying" tasks, and the "generating" would be a separate project.
@LovingMelody @trueNAHO what do you think?

Think this sounds good to me, unsure what this would look like or how this would affect users. Think the project has been known to have say palette generation by default.

The original idea of Stylix was "give it an image, and everything else happens automatically" hence the palette generator exists, but I think we've strayed from that by adding more options and so on.
If we avoid any big changes, just providing the palette generator as a function should remove the need for this PR.

Foreword

I would have written a shorter letter, but I did not have the time.
-- Blaise Pascal

Body

With the palette generator as a function, we could potentially move it to its own repository - it's only part of Stylix because it's been here since the very beginning.

IMHO, replacing the current mono repo architecture does not add much benefit, especially, when the only use case for those micro repositories is Stylix. Managing these separately does not seem worth it for now.

I'm reluctant to merge this because, as previously discussed, it goes beyond Stylix's goal of "take these theming items, and apply them everywhere".
If we were to instead provide the palette generator as a function, then you could simply call the palette generator with your original wallpaper, do whatever editing based on that palette, then set the final image as stylix.image.

Initially, I had the same opinion. However, considering that this PR will in the future anyway, I don't have any strong feelings about this PR:

Disregarding #63 and the palette extension roadmap, this implementation seems fine for now.
-- https://github.com/danth/stylix/issues/473#issuecomment-2241104865

Assuming both of the above changes were made, the following combinations would be possible:

Your proposal does not seem #63 future proof:

Modifying images at Nix build time stores them in the Nix store. With #63, this results in potentially unbounded duplicate data.
-- https://github.com/danth/stylix/issues/473#issuecomment-2240557282

Actually, I have been thinking about this problem for a while now.
What follows is my prototype draft proposal with #63 and the palette extension roadmap in consideration. I hope it is somewhat understandable:
scheme = mkOption {
  # Another example would be:
  #     example = ./image;
  example = "${pkgs.base16-schemes}/share/themes/catppuccin-latte.yaml";

  # TODO: This option should accept two types of values from which the schemes
  # will be generated:
  #
  # - 'pkgs.base16-schemes' file: Extract scheme from file
  # - image path: Generate scheme from image
  type = null;
}

slideshow = {
  enable = mkEnableOption "slideshow";

  timer = mkOption {
    # This value should be directly passed to the internal systemd service
    # periodically selecting random file from 'stylix.source'.
    #
    # This value defines the update interval.
  }
};

source = {
  path = mkOption {
    default = null;

    description = ''
      Directory containing background sources, including images, videos, GIFs,
      etc.

      This value may be any valid Bash expression.
    '';

    example = "$XDG_RUNTIME_DIR/wallpapers";
    type = types.nullOr types.str;
  };

  # TODO: Potentially better rename this option.
  modifier = mkOption {
    default = null;

    description = ''
      This is the the body of a function, where the first argument is the path
      of the
    '';

    example = "${pkgs.lutgen}/bin/lutgen apply "$1" --output "$2" -- ${colors}";
    type = types.nullOr types.str;
  }

  # TODO: In case, Stylix supports an application's wallpaper can only be set
  # through an option like 'wallpaper=<PATH>' and a systemd service (even a
  # one-shot one) is unable to set the wallpaper, this path should be used.
  # However, if Stylix does not have any such cases, then there is no need for
  # this option.
  wallpaperFallback = mkOption {};
};

Due to application color limitations, Stylix should internally provide and generate the following schemes:
scheme = {
  base16 = {
    0 = "<VALUE>";
    1 = "<VALUE>";
    2 = "<VALUE>";
    3 = "<VALUE>";
    4 = "<VALUE>";
    5 = "<VALUE>";
    6 = "<VALUE>";
    7 = "<VALUE>";
    8 = "<VALUE>";
    9 = "<VALUE>";
    10 = "<VALUE>";
    11 = "<VALUE>";
    12 = "<VALUE>";
    13 = "<VALUE>";
    14 = "<VALUE>";
    15 = "<VALUE>";
  };

  base24 = {
    0 = "<VALUE>";
    1 = "<VALUE>";
    2 = "<VALUE>";
    3 = "<VALUE>";
    4 = "<VALUE>";
    5 = "<VALUE>";
    6 = "<VALUE>";
    7 = "<VALUE>";
    8 = "<VALUE>";
    9 = "<VALUE>";
    10 = "<VALUE>";
    11 = "<VALUE>";
    12 = "<VALUE>";
    13 = "<VALUE>";
    14 = "<VALUE>";
    15 = "<VALUE>";
    16 = "<VALUE>";
    17 = "<VALUE>";
    18 = "<VALUE>";
    19 = "<VALUE>";
    20 = "<VALUE>";
    21 = "<VALUE>";
    22 = "<VALUE>";
    23 = "<VALUE>";
  };

  highlight = { /* VIM highlight groups */};
};

Depending on the stylix.scheme option all other internal schemes should be generated. For example, given a base16 scheme, base24 and highlight should be generated through interpolation. Given an image to stylix.scheme every scheme should be generated as accurately as possible from the image. Note that this may require re-implementing the current generatePalette logic.
If stylix.slideshow.enable is set to true, then a systemd service in the interval given by stylix.slideshow.timer should be created, and it should run the following code. Otherwise, if stylix.wallpaperFallback is not required, then this systemd service could simply be a one-shot service:
# TODO: For brevity, this example assumes that all 'stylix.source' files are
# images.

modifier() {
  ${stylix.scheme.modifier}
}

# This operation finds a random image from 'stylix.source'.
#
# NOTE: In my experience 'find | shuf -n 1' is not random enough and results in
# only a small subset of files ever being shown. But I have not never actually
# measured this. I only noticed this.
#
# NOTE: This function is only here to simplify the pseudo-code.
find_random_image() {
  # TODO: Implement.
}

# TODO: Depending on the user environment (like X or Wayland), this function
# abstracts how to set the background source.
#
# Additionally, in order to avoid "bloating" Stylix size, users should be able
# to set some Stylix option (not included or mentioned anywhere else in this
# message) saying what tool should set the background source.
#
# For example, if Stylix uses package 'A' by default to set the background
# source depending on the user environment, but the user does not use package
# 'A', then they might want to force Stylix to use package 'B', which they
# already use. This would reduce overall Stylix install size.
#
# NOTE: This abstraction could be implemented in Stylix, to avoid this logic
# from happening at runtime. Instead, the correct code could be generated by
# Nix, and then simply injected into this Bash script. This could somewhat
# improve performance and complexity.
set_stylix_source() {
  # TODO: Implement.
}

# This 'file="$(mktemp)"; <OPERATION> "$file"; rm $"file"' pattern avoids
# arbitrary and fragile tests to ensure that we are not overwriting or falsely
# removing the original user files located in 'stylix.source'.
#
# NOTE: If 'stylix.scheme.modifier' is set to 'null', then the logic could be
# simplified to 'set_stylix_source "$(find_random_image)"'. This case should be
# handled in Nix, and accordingly, the correct code should be injected into this
# Bash script. Also note that the previous 'modifier' Bash function in this case
# is no longer necessary.
file="$(mktemp)"
set_stylix_source "$(modifier "$(find_random_image)" "$file")"
rm "$file"

Depending on the stylix.scheme option all other internal schemes should be generated. For example, given a base16 scheme, base24 and highlight should be generated through interpolation. Given an image to stylix.scheme every scheme should be generated as accurately as possible from the image. Note that this may require re-implementing the current generatePalette logic.

Theres no reason to generate a base16 scheme & a base24 scheme when we can just use a fallback table for base24 -> base16

Theres no reason to generate a base16 scheme & a base24 scheme when we can just use a fallback table for base24 -> base16

This is faster, but less accurate.
Unless generatePalette becomes unbearably slow, the base16, base24 and highlight schemes should be directly generated from the image to avoid any form of precision loss. This implies calling generatePalette for each scheme:

Given an image to stylix.scheme every scheme should be generated as accurately as possible from the image. Note that this may require re-implementing the current generatePalette logic.

However, a given scheme, like pkgs.base16-schemes, does not contain more information than the scheme itself. Consequently, it seems reasonable to upscale (from base16 to base24) or downscale (from base24 to base16) depending on the provided scheme (base16, base24 or highlight). This process may reuse original values or interpolate new ones to hopefully achieve better results:

For example, given a base16 scheme, base24 and highlight should be generated through interpolation.

Since I have not yet looked deeper into VIM highlight groups, I am unsure how its upscaling or downscaling would be performed. I assume a combination of value repetition and interpolation, depending on the highlight group's purpose.
Extending generatePalette to extract base24 and highlight schemes from an image is still an open question:

Note that this may require re-implementing the current generatePalette logic.

As a user that based his nix flake config around stylix and treats it as a source of truth for theming I was waiting for this PR to be merged for some time as I am very interested in the said feature.
I don't know if my user feedback is welcome here and is free to be ignored,
but I think that writing up an implementation spec to provide something for people to potentially agree on might be helpful
As far as I understand stylix now works like this:

image has to be set.
if image is set it is used as a source for the color scheme
if color scheme is set explicitly the image is only used for the background.

This is how I would implement this if I was developing stylix:

image has to be set
if image is set it is used as a source for both base16Scheme and base24Scheme

base16Scheme is left for compatibility with legacy base16 modules that were not ported to base24Scheme

if base24Scheme or base16Scheme is set explicitly it means that the user does not want to use the image as color scheme source.

if user sets only base16Scheme stylix will throw an error asking to also set a base24Scheme

I don't know if upscaling is a good idea, in case it is this could be different.

if user sets only base24Scheme the user can also optionally set base16Scheme variant but if not set it will be downscaled from the original base24Scheme.

The fact that user has set a color scheme explicitly might mean that they also want the image to follow the color scheme

stylix = {
  # Modifies the image or images set by stylix.image and
  # stylix.additionalImages before they ever reach hyprpaper, grub, etc ...
  imageEditor = {

    # If explicitly enabled by the user while no color scheme was explicitly provided by the user
    # will use base24Scheme extracted from the image and apply it to the image before it reaches hyprpaper, grub, etc...

    # Enabled by default if the color scheme is set explicitly.
    # if the user set the color scheme explicitly but does not want the image to be modified the user can disable imageEditor.
    enable = true;

    # the only image editor at the moment. lib.types.enum [ "lutgen" ];
    editor = "lutgen";
  };
};

Slideshow can be implemented like this:

stylix = {
  # used for sourcing color scheme in case user does not set one,
  # if the color scheme is set and image editor is enabled, the image is modified,
  # if the image editor is disabled the image is not modified.
  image = ./primary_image.png
  # defaults to empty list, slideshow disabled, is optional
  additionalImages = [
    # not used to generate the color scheme
    # if imageEditor is enabled they are modified, if disabled they stay unmodified
    ./additional_image_1.png
    ./additional_image_2.png
  ];
};

I was waiting for this PR to be merged for some time as I am very interested in the said feature.

Actually, #102 already proposed some of this functionality, although it has essentially been abandoned due to the PR being too large.

I think that writing up an implementation spec to provide something for people to potentially agree on might be helpful

Yes, discussing the public API is a good idea.

As far as I understand stylix now works like this:

image has to be set.
if image is set it is used as a source for the color scheme.
if color scheme is set explicitly the image is only used for the background.

Exactly.

This is where I would take stylix if I was the one to direct it's development:

image has to be set

According to #200 and #442, declaring a background source should be optional.

if image is set it is used as a source for both base16Scheme and base24Scheme.

stylix.image should probably be superseded by my previously proposed stylix.source.path option. Otherwise, this aligns with my proposal:

Given an image to stylix.scheme every scheme should be generated as accurately as possible from the image.

base16Scheme is left for compatibility with legacy base16 modules that were not ported to base24Scheme.

base16Scheme can be deprecated in the future and all modules will have to be ported.

Ideally, VIM highlight groups should become the primary Stylix scheme format:

AFAIK, the current color scheme roadmap is to extend it to VIM highlight groups, although base24 support can be implemented in the meantime.

-- https://github.com/danth/stylix/issues/469#issuecomment-2240043203

To avoid inconsistent module-specific base16 and base24 support, Stylix should provide these schemes since some CLI applications might only support them.

if base24Scheme or base16Scheme is set explicitly it means that the user does not want to use the image as color scheme source.

I am unsure whether Stylix should enforce this behaviour with stylix.image being potentially superseded by stylix.source.path.

if user sets only base16Scheme stylix will throw an error asking to also set a base24Scheme

It might be annoying for to declare the same scheme in base16 and base24, especially with certain schemes not being published in both formats.

* I don't know if upscaling is a good idea, in case it is this could be different.

Downscaling or upscaling would be far more convenient. Additionally, this ensures scheme consistency, avoiding nasty incorrect coloring.

if user sets only base24Scheme the user can also optionally set base16Scheme variant but if not set it will be downscaled from the original base24Scheme.

It might be better that the scheme is extracted from a single source of truth from which all other schemes are generated.

The fact that user has set a color scheme explicitly might mean that they also want the image to follow the color scheme

Personally, re-coloring background sources to the Stylix theme sounds neat. However, I am sure many people would not want this.

stylix = {
  # Modifies the image or images set by stylix.image and
  # stylix.additionalImages before they ever reach hyprpaper, grub, etc ...
  imageEditor = {

    # If explicitly enabled by the user while no color scheme was explicitly provided by the user
    # will use base24Scheme extracted from the image and apply it to the image before it reaches hyprpaper, grub, etc...

    # Enabled by default if the color scheme is set explicitly.
    # if the user set the color scheme explicitly but does not want the image to be modified the user can disable imageEditor.
    enable = true;

    # the only image editor at the moment. lib.types.enum [ "lutgen" ];
    editor = "lutgen";
  };
};

Compare this to my proposal.

Slideshow can be implemented like this:

stylix = {
  # used for sourcing color scheme in case user does not set one,
  # if the color scheme is set and image editor is enabled, the image is modified,
  # if the image editor is disabled the image is not modified.
  image = ./primary_image.png
  # defaults to empty list, slideshow disabled, is optional
  additionalImages = [
    # not used to generate the color scheme
    # if imageEditor is enabled they are modified, if disabled they stay unmodified
    ./additional_image_1.png
    ./additional_image_2.png
  ];
};

This does not scale well, as the sources are copied to the Nix store:

Modifying images at Nix build time stores them in the Nix store. With #63, this results in potentially unbounded duplicate data.
-- https://github.com/danth/stylix/issues/473#issuecomment-2240557282

Unless generatePalette becomes unbearably slow, the base16, base24 and highlight schemes should be directly generated from the image to avoid any form of precision loss.

This could be problematic since the palette generator is pseudo-random, so each format could have a completely different set of colors, leading to inconsistency between applications. IMO, we should generate highlight since it includes the most colors, then downscale to base24 and base16 for compatibility.

I don't mind merging this neat functionality for the time being as it will be replaced in the future anyway:

I'm reluctant to merge this because, as previously discussed, it goes beyond Stylix's goal of "take these theming items, and apply them everywhere".
If we were to instead provide the palette generator as a function, then you could simply call the palette generator with your original wallpaper, do whatever editing based on that palette, then set the final image as stylix.image.

Initially, I had the same opinion. However, considering that this PR will be replaced in the future anyway, I don't have any strong feelings about this PR:

Disregarding #63 and the palette extension roadmap, this implementation seems fine for now.
-- #473 (comment)

If @danth approves, I would be happy to review and test this PR again. Otherwise, we close this PR and keep it for future reference.

considering that this PR will be replaced in the future anyway

@trueNAHO Could you clarify what you meant by this? (Sorry, I've lost track of the conversation since it's been a while)

considering that this PR will be replaced in the future anyway

[...] Could you clarify what you meant by this? (Sorry, I've lost track of the conversation since it's been a while)

No worries.
Essentially, this PR does not scale once #63 is resolved as the number of modified input files would be unbounded:

Modifying images at Nix build time stores them in the Nix store. With #63, this results in potentially unbounded duplicate data.
-- https://github.com/danth/stylix/issues/473#issuecomment-2240557282

In the future, an implementation based on my prototype draft proposal would replace the architecture introduced by this PR:

What follows is my prototype draft proposal with #63, #442, and the palette extension roadmap in consideration.
-- https://github.com/danth/stylix/pull/477#issuecomment-2254170449

Ultimately, the public option introduced by this PR would be removed in the future. However, considering that this might take a while to happen, I am fine with merging the functionality introduced by this PR for now.
I leave the decision up to you:

If [danth] approves, I would be happy to review and test this PR again. Otherwise, we close this PR and keep it for future reference.

I don't see a real reason to add this if it's just going to get removed. Your draft PR overall seems fine, but I'm not fond of the systemd service's implementation that you have outlined. The directory should probably cached & linked to a generation in case the modifier is computationally expensive.

I don't see a real reason to add this if it's just going to get removed.

As mentioned, I don't have strong feelings on merging this, but avoiding another breaking change would be ultimately better.

Your draft PR overall seems fine, but I'm not fond of the systemd service's implementation that you have outlined. The directory should probably cached & linked to a generation in case the modifier is computationally expensive.

I already considered caching, but did not mention it in the prototype.
As mentioned, linking input or output directories to a Nix generation in the Nix store is not ideal due to storage duplication.
When I implemented my custom wallpaper setter, I already considered caching, but never implemented it due to reasonably fast execution time. However, since the source.modifier option from the prototype is externally configurable and may be arbitrarily slow, execution time should not be assumed.
Caching could be implemented by preemptively selecting, modifying, and caching the next <CACHE_NUMBER> background sources in the background using nice --adjustment=<ADJUSTMENT> ${source.modifier}, where 1 >= <ADJUSTMENT> <= 19 holds. If slideshow.timer triggers with an empty <CACHE_DIRECTORY> queue, a new background task should start without the nice wrapper to prioritize getting and setting a new background source.
Additionally, benchmarking and caching the source.modifier execution time (<SOURCE_MODIFIER_BENCHMARK>) at Nix build time would further reduce latency by starting a new high-priority (without the nice wrapper) background task <SOURCE_MODIFIER_BENCHMARK> earlier than slideshow.timer if <CACHE_DIRECTORY> is currently empty. For example, if slideshow.timer = 30 and <SOURCE_MODIFIER_BENCHMARK> = 10, then at time slideshow.timer - <SOURCE_MODIFIER_BENCHMARK> = 20 a new high-priority background task should be started if <CACHE_DIRECTORY> is currently empty.

As mentioned, linking input or output directories to a Nix generation in the Nix store is not ideal due to storage duplication.

In your prototype, every time the service triggers it creates a new temp directory and creates the file there leading to more duplication than there would be in the nix store, which may even be desired behavior for it to be stored in the store ( I agree it shouldn't be the default ).
The reason I point to generations is so that files outside of that generation can be removed when it's no longer valid as well and not just on reboot similar to agenix.

As mentioned, linking input or output directories to a Nix generation in the Nix store is not ideal due to storage duplication.

In your prototype, every time the service triggers it creates a new temp directory and creates the file there leading to more duplication than there would be in the nix store, which may even be desired behavior for it to be stored in the store ( I agree it shouldn't be the default ).

Are you referring to the following snippet:
# This 'file="$(mktemp)"; <OPERATION> "$file"; rm "$file"' pattern avoids
# arbitrary and fragile tests to ensure that we are not overwriting or falsely
# removing the original user files located in 'stylix.source'.
#
# NOTE: If 'stylix.scheme.modifier' is set to 'null', then the logic could be
# simplified to 'set_stylix_source "$(find_random_image)"'. This case should be
# handled in Nix, and accordingly, the correct code should be injected into this
# Bash script. Also note that the previous 'modifier' Bash function in this case
# is no longer necessary.
file="$(mktemp)"
set_stylix_source "$(modifier "$(find_random_image)" "$file")"
rm "$file"

In this case, mktemp actually creates a temporary file placeholder to which the modified file will be written to using the modifier function. Afterwards, the temporary file is removed again using rm "$file". Passing the input file and the modified around through stdout would avoid filesystem operations and improve performance. However, due to lack of implementation detail (due to it still being a prototype) and simplicity, the modified file is simply written to the filesystem.

The reason I point to generations is so that files outside of that generation can be removed when it's no longer valid as well and not just on reboot similar to agenix.

What exactly do you mean by generations and what would be removed?
AFAIK, the agenix cache defaults to $XDG_RUNTIME_DIR, which in turn defaults to /run/user/<UID>. AFAIK, unlike /tmp being cleared on reboot, /run/user is cleared on user logout.
My prototype (without the caching mechanism) leaves the input sources stored on the filesystem untouched and creates no files living longer than a second.

This can be closed, I'll continue maintaining this fork till we get there


Short solution needed: "chrome headless user-data-dir" (chrome-headless)

Please help us write most modern and shortest code solution for this issue:
chrome headless user-data-dir (technology: chrome-headless)
Fast way
Just write the code solution in the comments.
Prefered way

Create pull request with a new code file inside inbox folder.
Don't forget to use comments explain solution.
Link to this issue in comments of pull request.

How to use custom profile with user-data-dir option


More news

Just updated some news

How about adding it above the existing news so that you can scroll down to see the older ones?

I agree with @50Wliu. Most recent news should be at the top.

Merging so people see this update before it's outdated.