Cannot migrate storage pools with lxc move anymore

Ubuntu server 20.04 LTS; LXD 4.0.8
It seems it's no longer possible to migrate a container to another storage pool with lxc move.
I’m getting Error: Invalid number of arguments if I try the following:
lxc move <container_name> -s <storage_pool_name>

It works if I also rename the container (e.g. c1_tmp) in the same command, like so:
lxc move c1 c1_tmp -s zfs2

See also: https://discuss.linuxcontainers.org/t/migrate-from-one-storage-pool-to-another/10877/7
Apparently, the following is supposed to work, but doesn't for me:
lxc storage create zfs1 zfs
lxc storage create zfs2 zfs
lxc init images:ubuntu/focal c1 -s zfs1
lxc move c1 -s zfs2

You're on LXD 4.0.8 which does not support server side storage pool move.
This feature was introduced with LXD 4.11.

Because move then does a copy+delete.

I see.
That's very useful to know.


Provide a seed to Chance for repeatability

Is it possible to provide a seed to the factory so that running factory.chance will give repeatable results?
The Chance documentation says that a seed can be provided to Chance using new Chance(mySeed) but I'm not sure if there is a way to pass the seed to the instance of Chance that factory-girl uses.

Unfortunately, new Chance() appears to be hardcoded and no configurable seed is being provided.
https://github.com/aexmachina/factory-girl/blob/master/src/generators/ChanceGenerator.js#L5


kvrpc: deduplicate chained intercept by name

deduplicate chained intercept by name so we can replace SetInterceptor with AddInterceptor

@disksing @nolouch PTAL

/merge


Demo result looks bad compared to hugging face.

Hi, thanks for your great work. I tried to run the demo with the "FC-CLIP (ResNet50x64)" model and got some bad results,

But I also tried the hugging face, I got the certainly good results

Could give me some hints, what could be wrong?
Thanks in advance!

Hi, we use ConvNeXt-L variant for huggingface demo, which should give different results to ResNet ones. But still, I also feel it looks weird in the RN results you obtained. Could you please provide the following information for debugging purposes?

Could you run local demo with ConvNeXt-L FC-CLIP to see if it gives the same results of huggingface demo?
Could you provide the command you used to obtain demo results?
I have never checked visualization from RN backbones, and we do observe that they exhibit some different properties, e.g., we need to ensemble over valid masks to have a reasonable PQ. Thus, it would also be helpful if you can provide visualization for semantic segmentation besides panoptic ones?

Best,

Thanks a lot, after switching into ConvNeXt-L FC-CLIP it works well.


monitor and callback: wrong logic for functions with a large amount of arguments

The symbol monitor feature includes the following code:
symbols_jar.py:
def monitor(self, **args):
    ...
    if arg_count > 0:
        args_c['regs'] = {f'x{i + 2}': 'po' for i in range(arg_count)}

hilda_client.py:
def callback(hilda, frame, bp_loc, options):
    ...
    for name, fmt in options['regs'].items():
        value = hilda.symbol(frame.FindRegister(name).unsigned)

which works for functions with 8 arguments or less.
However, after 8 arguments, any further arguments are passed on the stack, so the current code starts printing gibberish.
Possible solutions are either to just print the registers x0 up to x7 and stop there,
or to read from the stack starting from the 9th argument.
A code that worked for me is something like
if (arg number < 8):
    return p.registers[x arg number]
return p.peek(p.registers.sp + 8 * (arg number - 9))

(using pseudocode because I'm not with my computer right now)

Actually the better and cross-arch solution is to use Hilda's expr = {'$arg1': 'po', ...}
The new PR uses this solution instead


This seems like the most up to date fork of this cookbook

Any chance this can be merged to the upstream repo and then pushed to the supermarket ?
@klamontagne

@klamontagne can we get this merged and pushed to supermarket?


Implement whitelist for mixed content

Controlled via mixedcontentwhitelist entry in plugin config, '*' can be used as a wildcard.
Passed to webkit via libextension, similiar to how CORS whitelist works.

This functionality depends on changes in WPEWebKit which have not been merged yet:
https://github.com/WebPlatformForEmbedded/WPEWebKit/pull/1128

WPEWebKit dependency has already been merged


Update example to include dynamic reference to new markdown from #188

While I point to a provisional blob URL in this commit, this will be updated to point to master once pulled.
This library + script takes the markdown and converts it to HTML client side, live, straight from github so that maintenance overhead is easier in the future and less likely to fall out of date.

@wmurphyrd anything this pull request needs to be added...?

Hey @kylebakerio can you update this to point to master now that the other branch is merged?


Bulid error on Arch Linux

OS : Arch Linux
Kernel version : Linux 5.19.8

Hey ! This is a (very) old project, maybe your compiler is too recent for it. Try with an older one dating back circa the last few commits. If not same process for system libraries. Best would be to use docker to not mess up your system with old stuff, if you come up with a working dockerfile please submit it. Even better would be fixing the code of the project against recent compiler and libs

But, as a current Epitech student yourself and a former one myself, I would recommend to not cheat. Don't be lazy and code your own RType 😉
You are very welcome to take inspiration from how we architectured the project, we put a lot of thought in our Entity-Component-System and were even able to add levels or create a PvP mode without recompiling the game. I can't stop you, but copy-and-modifying the code to evade cheat detection might take you even longer than coding the project yourself, and you won't learn anything doing it this way. Rather go from your own blank page and incorporate ideas from this project.
And, I am still a teacher at Epitech 😉

Thanks for your advices ! Of course I'm doing my own RType, I was just trying to build your repo in order to test it (I have no idea what a RType is, and what are the controls...).
I took inspiration especially from your ECS architecture. But I won't copy/paste anything, don't worry !


Feature - TRSV2-362 - Adding all countries to case creation

Codecov Report
Base: 32.51% // Head: 32.51% // No change to project coverage :thumbsup:

Coverage data is based on head (ab5b308) compared to base (de52ed3).
 Consider uploading reports for the commit e87c3f2 to get more accurate results

Additional details and impacted files
@@           Coverage Diff            @@
##           develop     #187   +/-   ##
========================================
  Coverage    32.51%   32.51%
========================================
  Files           91       91
  Lines         3266     3266
  Branches       552      552
========================================
  Hits          1062     1062
  Misses        2204     2204

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

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


data-integation Script.java

Adding a script into the data-integration steps causes exceptions if the data type is something different than the standard types.  Script.java does not support extracting custom types.  Will file a bug report here.  The exception occurs on line 577 of Script.java

This is a wish list.  Seems that data-integration people have not even taken my first set of patches for the Job Executor and Trans Executor steps.  I will not work on anything else in the pentho's git tree until they take my fixes or give me feedback on what needs to be changed

Is addressing this a requirement for delivering the tile server then?

No,  it's just a bug found during the use of their library.


Voiceover on Safari (MacOS) doesn't read out select options

Describe the bug
Using Voiceover on Safari, a user doesn't hear the options in the select, makes the select all but unusable.
To Reproduce

https://tom-select.js.org/ on Safari/MacOS
Turn on Voiceover (cmd + F5)
Tab to the select example at the top of the page or click in it
Cycle through the options with the arrow keys

Expected behavior
The options to be read out in some way, any other browser (tried Firefox and Chrome) with Voiceover seems to work.
Additional context
Add any other context about the problem here.

OS: MacOs
Browser: Safari
Version: 15.6.1 (probably others too)

<!--
Thanks for taking the time to submit your bug report,
and don't forget to star our repo!

If it works everywhere else, should probably submit it to https://webkit.org/reporting-bugs/


Usage on elixir 1.6.1 on Ubuntu 16.04

When I try to use the image it throw a lot of warnings, some of them:

warning: the variable "count_bind" is unsafe as it has been set inside one of: case, cond, receive, if, and, or, &&, ||. Please explicitly return the variable value instead.

function :sbroker.async_ask_r/3 is undefined (module :sbroker is not available)

variable "self" does not exist and is being expanded to "self()", please use parentheses to remove the ambiguity or change the variable name

But it makes the image. When I try to exec it, I am getting the error:
[info]  Application ocpp_backend exited: OcppBackend.start(:normal, []) returned an error: shutdown: failed to start child: OcppBackend.Repo
** (EXIT) an exception was raised:
** (UndefinedFunctionError) function OcppBackend.Repo.start_link/0 is undefined (module OcppBackend.Repo is not available)
OcppBackend.Repo.start_link()
(stdlib) supervisor.erl:365: :supervisor.do_start_child/2
(stdlib) supervisor.erl:348: :supervisor.start_children/3
(stdlib) supervisor.erl:314: :supervisor.init_children/2
(stdlib) gen_server.erl:365: :gen_server.init_it/2
(stdlib) gen_server.erl:333: :gen_server.init_it/6
(stdlib) proc_lib.erl:247: :proc_lib.init_p_do_apply/3
** (Mix) Could not start application ocpp_backend: OcppBackend.start(:normal, []) returned an error: shutdown: failed to start child: OcppBackend.Repo
** (EXIT) an exception was raised:
** (UndefinedFunctionError) function OcppBackend.Repo.start_link/0 is undefined (module OcppBackend.Repo is not available)
OcppBackend.Repo.start_link()
(stdlib) supervisor.erl:365: :supervisor.do_start_child/2
(stdlib) supervisor.erl:348: :supervisor.start_children/3
(stdlib) supervisor.erl:314: :supervisor.init_children/2
(stdlib) gen_server.erl:365: :gen_server.init_it/2
(stdlib) gen_server.erl:333: :gen_server.init_it/6
(stdlib) proc_lib.erl:247: :proc_lib.init_p_do_apply/3

Hi kele6ra,
Thanks for trying this out, you should realize that this is just a hobby project for me and nowhere ready to be used in any kind of production environment
The failed to start child: OcppBackend.Repo is probably because you don't have a postgres database running or configured correctly, or you didn't ran the ecto migrations
You're welcome to contribute if you find any bugs

Yes, I understand that it is not a business project. I just want to show that there is a problem with elexir version. Could you say what version did you use to build it?

I found that in config file there is a file with 0cpp.backend.Repo function, but not ocpp.backend. Is it right?

I'm using elixir 1.5.3 currently
about the database configuration, have a look at config/config.exs and I suggest reading the Ecto documentation

Sorry, I am working with elixir and ecto for the first time, could you help me with migrations. I can write full guide of installation after after I run it.

looking forward to your pull request after you learned elixir and ecto


feat: add husky with lint-staged

The combination of lint-staged and husky will prevent code that didn't pass ESLint or ran through Prettier from being committed. Personally, I couldn't live with this anymore :)

Lefthook supports linting staged by itself. I have configuration file somewhere. I can update this branch some time later.

Well. It is better that we add it to all the repositories through our repository-sync script.

Lefthook supports linting staged by itself

Interesting. Their migration guide from husky/lint-staged is a bit ambiguous about that. But knowing that it's possible, that guide can be interpreted that way :)

This is the config I was referring to:
pre-commit:
  parallel: true
  commands:
    format:
      run: npx prettier --write {staged_files}

I have noticed that Git hooks run very slow when terminal isn't used. I tested Atom and Github desktop


Send modifier keys to the attached pane via .send_keys()

I really like the look of this project. However, for something that I need to do, I need to be able to send a modifier key, Ctrl to be exact.
I've tried a few different things and I'll continue looking around for a solution, but I figured I would post an issue here in case this is not currently possible.

Would C-key work?
For Ctrl-a,  do C-a or ^-a

@tony Unfortunately I already tried that and it just gives an error, both in zsh and and in bash:

I'm considering making enter=False and suppress_history=False by default.
Give this a shot, it worked for me:
pane.libtmux.Server().sessions[0].attached_window.panes[0].

Quick snippet:
libtmux.Server().sessions[0].attached_window.panes[2].send_keys('C-c', enter=False, suppress_history=False)

@tony Sorry for not responding soon, I was gone and didn't take any machines with me. I had to tweak your snippets to work, but running
libtmux.Server().sessions[0].attached_window.panes[0].send_keys('C-c', enter=False, suppress_history=False)

did work, it did seem to send Ctrl-C!


Stemplayer website not starting while extension is enabled

A recent update went on so now that if you have the extension enabled it'll just loop on the websites Loading screen; preventing access. But if you were to turn off the extension then the website normally loads in.

now uploading link or file not working anymore...


ansible fetch tasks fail

Deploying a getting-started cluster should fetch the krb5.conf file from the kdc and the tdp_user.keytab. These tasks fail (silently).

I am not sure why this is needed as deploy-kerberos.yml is not used anymore ?
I have created https://github.com/TOSIT-IO/tdp-collection-extras/issues/26 for tracking

@leopaul36 It's because it's necessary to kinit as tdp_user to access the TDP web interfaces.


ARM64 Images are Actually AMD64

First of all, thank you for creating this!
I haven't been able to get this working on my ARM64 system, as the transmission-gluetun-port-update binary is compiled for AMD64 in all of the ARM64 images that I tested. I tried building the image locally, and the binary is properly compiled for ARM64; this would point to an issue in the Github Actions cross-compilation workflow, but I haven't been able to find anything that looks incorrect. Are there any references to the local platform hidden anywhere?
Unfortunately, local images can't be used as Linuxserver docker mods, so it would be great if this issue could be fixed. I am happy to test changes.

Hey, I will check the pipelines after Christmas time or in the beginning of the next year. In the meantime if you find something keep me posted;)

After some further testing, I believe that this can be closed as the images are actually being built correctly.
What led me to believe that the images were being built incorrectly was that the transmission-gluetun-port-update binary was compiled for AMD64 in the Linuxserver/transmission image. However, if I just pull the image directly, the binary is properly compiled for ARM64.
So it seems that this issue is coming from how the Linuxserver/transmission docker mods are installed, which I will look into. The other docker mod I have installs correctly, so this could still be a different issue with this docker mod. I will start a new issue if that looks likely.


Adding multi language support system✨

Fixes #1118
@ANSHIKA-26 can you review this please.

@ANSHIKA-26 can you review this please.

I'm closing this PR because it goes against two important guidelines:
You didn’t check for duplicate issues before starting work, and someone else had already raised this issue.
(#1044)
You didn’t wait to be assigned the issue before working on it, which is clearly stated in the rules.
Please follow the contribution guidelines next time. Working without checking or being assigned only creates confusion and wastes effort. Be sure to follow the process going forward.

im sorry , u assigned me the level so i thought i can work on it.

no one assigned you any level
the tags of ggsoc and hacktoberfest are added be default to any issue that opens via a bot  , i didnt assign you anything


BadMethodCallException

Hello!
Oneup\UploaderBundle\Uploader\Chunk\Storage\FlysystemStorage.php -> $this->filesystem->listFiles -> throws BadMethodCallException with message: Call to undefined method League\Flysystem\Filesystem::listFiles with league/flysystem (1.0.27)
Thank you.

In the current version the listFiles method is a plugin. https://github.com/thephpleague/flysystem/blob/master/src/Plugin/ListFiles.php
This might be a dependency problem.

@sheeep Thank you too.

Reporting that console command bin/console oneup:uploader:clear-chunks throws same exception.

I believe this is a duplicate of #255.

Hello @snarktooth! Thanks for your reply.
It's not that user scenario and it's not related to the OrphanageStorage class.
In short the problems is this:
$this->handleChunkedUpload($file, $response, $request) when we try to configure chunks storage using flysystem.
The scenario is so:
1. We have a js uploader that splits big files in small chunks.
2. We extend AbstractChunkedController and send these chunks via $this->handleChunkedUpload($file, $response, $request).
3. Rest of the process via event listeners.
Basically we try to upload all the chunks directly on sftp via flysystem. Then when the uploaderBundle tries to get that list of chunks in order to reassemble the input original file throws that exception.
Right now we use the chunks uploading on local filesystem and the mapping same way. We have the upload servers different from the api ones so we just have to manage a new way in distributing the post processes using api as local video provider.
Because the mapping itself with the storage type as flysystem is ok and working well, we can upload the big file on sftp using only the mapping. But this way we loose efficiency, because the client js uploader knows how to handle some network problems or resume after a failover. Not mentioning double tasks for one file: uploading in chunks, assembling locally and then reupload the big file on video server via sftp.

You're right; the problems with the Flysystem chunk handling are more extensive than just the attempt to use listFiles.  It looks like the Uploader\Chunk\FlysystemStorage class was copied verbatim from the Gaufrette equivalent without being fully adapted to account for Flysystem's differences.


Description is unclear for vulnerabilities/stale_feed_data trigger/gate, when fired against an image with a distro/version that doesn't have a feed data source

Currently, when a policy evaluation is performed against an image that reports a distro/version that doesn't match a synced (or existing) OS feed, the output to the user can be confusing - for example, using busybox:latest:
vulnerabilities        stale_feed_data                       The vulnerability feed for this image distro is older than MAXAGE (2) days                 warn
vulnerabilities        vulnerability_data_unavailable        Feed data unavailable, cannot perform CVE scan for distro: busybox:v1.31.1                 warn

first - the 'stale_feed_data' trigger while perhaps true, is misleading since there is no OS feed for the image's distro, and can be understandably interpreted as 'there is a feed, but it is out of date' instead of the more accurate 'there isn't a feed for this distro'.  Suggest that this trigger not fire at all when there is no feed, meaning that the check should only fire if there is a feed and it is indeed stale.
second - the vulnerability_data_unavailable detail should be made more explicit to make it clear that this check is only for the OS feed types (as opposed to NVD, other), possibly by introducing additional checks for other feeds and make them more explicit about which type they're referring to.

@nurmi +1 on this issue. I was confused about these exact findings after scanning an image that used a multistage build with quay.io/prometheus/busybox:latest

@nurmi +1 as well, affecting an enterprise customer's end users now.

@nurmi +1 as well, affecting an enterprise customer's end users now.

Agreed, I think those triggers need a semantic review and update since we have multiple feeds that are relevant for any given image that are based on content type as much as distro.

Agreed, I think those triggers need a semantic review and update since we have multiple feeds that are relevant for any given image that are based on content type as much as distro.

+2, Rancher is seeing this on their images built FROM scratch
vulnerabilities | stale_feed_data                | The vulnerability feed for this image distro is older than MAXAGE (15) days | stop
vulnerabilities | vulnerability_data_unavailable | Feed data unavailable, cannot perform CVE scan for distro: Unknown:0        | stop

+2, Rancher is seeing this on their images built FROM scratch
vulnerabilities | stale_feed_data                | The vulnerability feed for this image distro is older than MAXAGE (15) days | stop
vulnerabilities | vulnerability_data_unavailable | Feed data unavailable, cannot perform CVE scan for distro: Unknown:0        | stop

+1 getting the same for ubuntu:20.10

docker.io/ubuntu:20.10 | vulnerabilities | stale_feed_data                | The vulnerability feed for this image distro is older than MAXAGE (2) days
docker.io/ubuntu:20.10 | vulnerabilities | vulnerability_data_unavailable | Feed data unavailable, cannot perform CVE scan for distro: ubuntu:20.10


Race conditions with setting machine storage

Currently the only way that I have found to make machine storages (e.g. batteries) has a fatal flawed approach, with using this code below:
setMachineStorage(ev.block, "energy", realEnergy - amountToSend);
generate(ev.block, "energy", amountToSend);

These two functions have no guaranteed order, and can lead to race conditions such as:

both set and generate are called
the handlers are invoked on the core side
the handler for the generate precise seems to go first and reads the value of the storage type before set has actually written the value
set then finally finishes
generate then happens whenever we run the network send func, it restores the amount before the set was called and then adds its own generated amount ontop, effectively doubling the amount in the machine (assuming its a low priority consumer with nothing consuming on the network)

Why are you calling setMachineStorage? generate should remove whatever is used automatically. You only need to call generate(block, "energy", 0)

generate does that? huh okay, I'll look into that when I head on next, thanks

I'm not entirely sure why this was closed, and I dont have the permissions to reopen it, I mean looking into it, thats not how generate works? There is nothing in the code that does that
export function generateListener(payload: ipc.SerializableValue): null {
  const data = payload as MangledGeneratePayload;
  const location = deserializeDimensionLocation(data.a);
  const type = data.b;
  const amount = data.c;

  const block = location.dimension.getBlock(location);
  if (!block) return null;

  const fullAmount = amount + getMachineStorage(location, type);
  if (!fullAmount) return null;

  const storageType = InternalRegisteredStorageType.forceGetInternal(type);

  MachineNetwork.getOrEstablish(storageType.category, block)?.queueSend(
    block,
    type,
    fullAmount,
  );

  return null;
}

It simply queues sending the amount in the machine already plus the amount to generate,
At no point in the *send generator does it take away the energy either.

Also thats not the best behaviour for generate I just realised? Its not ideal for it to do that because in the scenario where you want a machine to have a limited rate output, this doesn't work because it adds on the amount stored inside

That's not it, that's the line that handles sending power to machines, not take power out of a machine after using the generate function.

Nope that's not it, that's the line that handles sending power to machines, not take power out of a machine after using the generate function, that behavior did not exist until my latest PR that is currently open :p

What? Did you even test it before making your PR?

I also know for a fact that it works because all Bedrock Energistics generators rely on this behavior.


Add beamZ BAC500 and BAC506 fixtures

This PR adds a couple of beamZ fixtures:

[x] Passed the validator test for both fixtures.

coverage: 32.084% (+0.006%) from 32.078%
when pulling 0b0d14e5c290d6e545dc3cd3f58fc0c187e427ae on omichel:patch-1
into 9cec7ac61c982ccf4955ba08a735b3edf5435e9f on mcallegari:master.

Thanks :+1:


 Commit messages are added to the history only if a commit was made through Ctrl+Enter hotkey.

 Thank you for your submission, we really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.:x: grabantot sign nowYou have signed the CLA already but the status is still pending? Let us recheck it.

Closing due to inactivity.


ReduxAsyncConnect fires in Client Side when it shouldn't

While using boilerplate i found some problem.
In reduxAsyncConnect I'm using getData() from my reducer, which loads some info from db. Later, I have a button, that changes one of returned values, but the value remain unchanged for the first time. Clicking second, third, etc. time it works perfectly correct. I think that I found where the problem is - clicking on button, which fires another function from reducer, trigggers some other actions - including "@@router/UPDATE_LOCATION", "reduxAsyncConnect/BEGIN_GLOBAL_LOAD" and "reduxAsyncConnect/END_GLOBAL_LOAD". Also it fires my action that is in reduxAsyncConnect, which causes reseting my reducer to initial state.
It can be checked even on clean boilerplate - all you need to do is to add console.log(action.type) in, for example redux/modules/widget.js and clicking in counter button on home page, shows all these actions, which shouldn't fire on clicking button!
One more info I found - such thing happens only if it's first action we do on page that was loaded from ssr. If we change page and return to home, none of previous functions is firing on clicking button.

+1

+1 redux-async-connect seems too unstable, I also faced as issue where data-checksum is not generated, and client.js returns a error if App Component is not connected using asyncConnect

+1 Just faced this issue. This issue seems to be relevant https://github.com/bdefore/universal-redux/issues/91

A workaround for me is to fire blank action at componentDidMount of the App component

+1

+1. also @PanJ your workaround doesn't work for me. just causes the problem to happen earlier, when the App component mounts rather than on the first action fired.

Issue seems to go away by upgrading to react-router-redux 4.x.x

@cjroebuck 's workaround works.
Just upgrade to react-router-redux@4, and update some files following this PR:
https://github.com/erikras/react-redux-universal-hot-example/pull/951/files


In-memory engine: add metrics for range count

What is changed and how it works?

Issue Number: Ref #16141

What's Changed:
add metrics for range count

It shows the different types of range count:

Related changes

[ ] PR to update pingcap/docs/pingcap/docs-cn:
[ ] Need to cherry-pick to the release branch

Check List
Tests

[ ] Unit test
[ ] Integration test
[ ] Manual test (add detailed scripts or steps below)
[ ] No code

Side effects

[ ] Performance regression: Consumes more CPU
[ ] Performance regression: Consumes more Memory
[ ] Breaking backward compatibility

Release note

None

/merge

/retest-required


Add PaginationTemplate component

In the components/templates folder add a PaginationTemplate.tsx file. Copy the structure of one of the other templates (they're all currently the same apart from name - contents will be added later). Update the component name so it matches the file name.
In the pages/[content].tsx file import the template and add it alphabetically in the correct place between the layout tags
Add the template data to the config file in data/pages.tsx

Hello ma'am,
I have gone through the repository and the given instructions. The issue seems to attract my interest and excites me to work on it. I humbly wait for you to assign the task to me if your analysis of my profile allows.
Yours Sincerely,
Giriraj Roy.

Hey @EmmaDawsonDev I am new to open source and I would like to do this task. Could you please assign me to this task.
Thanks 😄

Sure! If you're taking part in hacktoberfest just wait until October 1st to make the PR.

Ok. Thanks for the heads up. Its my first time taking part in hacktoberfest.

@EmmaDawsonDev Hey while trying to commit to my branch I ran into an error.

Could you please tell me how to fix this

@ahmedsilat44 did you solve the issue you were having with committing? I can’t see the screenshot you posted anymore 🤔 if not, I suggest trying to commit via the terminal and let me know if it doesn’t work

@EmmaDawsonDev Yes I solved the issue. I kept having the error while commiting through Github Desktop but after 2 hours of struggling to find the solution I used the terminal and it worked. Thanks for the reply 👍


Dependency resolution across Python versions

I don't know if this is intentional, but the following project cannot be installed on Python 3.13 if I want to avoid building source distributions:

uv init example
cd example
Use this pyproject.toml:[project]
name = "example"
version = "0.1.0"
description = "Add your description here"
readme = "README.md"
requires-python = ">=3.9"
dependencies = [
    "scipy >= 1.13.1",
]

uv sync --python=3.12 works (same for 3.9, 3.10, and 3.11)
uv sync --python=3.13 --no-build-package=scipy fails, even though it could (should?) use scipy==1.14.1, which is available as a binary wheel.

This surprised me because I expected that by specifying scipy >= 1.13.1, uv would automatically choose a newer version with a binary wheel for Python 3.13. Indeed, there are binary wheels for version 1.13.1 available for Python 3.9 through 3.12, but only version ≥ 1.14.0 has a binary wheel for Python 3.13 (though it no longer supports 3.9). However, it seems that uv is trying to maintain consistent package versions across all supported Python versions.

This is known problem with scientific packages unfortunately. Does splitting the scipy version on the python version as documented at the bottom of https://github.com/astral-sh/uv/blob/main/docs/reference/build_failures.md (out with the next release) help?

Unfortunately not:
[project]
name = "example"
version = "0.1.0"
description = "Add your description here"
readme = "README.md"
requires-python = ">=3.9"
dependencies = [
    "scipy >= 1.13.1; python_version <= '3.12'",
    "scipy >= 1.14.0; python_version >= '3.13'",
]

It tries to build NumPy 2.0.2 from source on Python 3.13, no idea why it doesn't just use >= 2.1:
❯ uv sync --python=3.13 --no-build-package=scipy --no-build-package=numpy
Using CPython 3.13.0
Removed virtual environment at: .venv
Creating virtual environment at: .venv
Resolved 4 packages in 0.97ms
error: Distribution `numpy==2.0.2 @ registry+https://pypi.org/simple` can't be installed because it is marked as `--no-build` but has no binary distribution

Maybe because it also uses NumPy 2.0.2 on Python <= 3.12?
Besides, I think splitting like this feels a bit off, since the ranges actually overlap (unlike in the example).

This feels very un-intuitive to me, too 🤯

Thanks for this detailed explanation! I do like how thoroughly uv has been designed, but given that the scientific ecosystem now pushes it beyond its boundaries, I feel like it makes it very hard to use uv in this context. In the simple example with just a single scipy dependency I have to manually specify constraints for numpy, but in a more realistic project there will probably be dozens of such constraints that I don't want to handle manually.

Fwiw it would be nice if we could make this split automatically for non-abi3 wheels.

I'm not sure if I understand what you're saying, but do you think that uv should do this automatically so that my original example "just works"?

Also, pip resolves these requirements differently: it installs scipy==1.14.1 on >=3.10 and scipy==1.13.1 on ==3.9 (together with suitable binary wheels for numpy). This is the expected behavior at least for me, but probably also for the Python community.

This is the expected behavior at least for me, but probably also for the Python community.

I would like to second this ☝

For numpy at least, Requires-Python doesn't tell us about the upper bounds (https://inspector.pypi.io/project/numpy/2.1.2/packages/1c/a2/40a76d357f168e9f9f06d6cc2c8e22dd5fb2bfbe63fe2c433057258c145a/numpy-2.1.2-cp310-cp310-macosx_10_9_x86_64.whl/numpy-2.1.2.dist-info/METADATA#line.999), so we would need to find a strategy of forking dependent on the wheel on PyPI, e.g.:
Pick a numpy version, analyse the range of https://pypi.org/project/numpy/#files, and if we see consistent range of compiled cp3x tags while there exists a newer version that covers a wider range, fork and so we can pick a newer numpy on newer Python versions.

Another possible solution would be https://github.com/astral-sh/uv/issues/7190

You should never add an upper bounds to Requires-Python. Most packages don't know it until after they are released, and even for ones that know they won't support the next version (like numpy), the existing handing of this field is wrong and things like pip and poetry break if you cap. Looking at the binary wheels available to guide version ranges would be really helpful, though, I think, especially if #7190 wasn't the default. You could also check to see if classifiers are present, and only consider a classifier disappearing as you look at older packages to be the starting point of support for that Python version. Many packages don't have classifiers, but for the ones that do, having a classifiers is a sign of solid support. (That's a lot weirder, though, I don't think a single tool today checks classifiers during a solve).
https://discuss.python.org/t/requires-python-upper-limits/12663 was a discussion about what to do with upper caps.

Yes, I think #7190 would be a great default. In my example at the top, I'm not setting an upper bound at all.

Hello @konstin  and @charliermarsh,
I’m not entirely sure whether to post here or in #7190, but I wanted to take a moment to share some thoughts. The challenge @cbrnr has described is a significant blocker for uv adoption in both my company and several open-source projects I’m involved with.
In our use cases, we typically need to support multiple Python versions while ensuring that the latest possible versions of all packages are installed for each Python version. This is critical for us across local development, CI testing, and deployment workflows.
Unfortunately, the current workaround using python_version selectors to enforce forking isn’t feasible for us. With projects that have dozens of dependencies, adding what could amount to hundreds of additional (and repetitive) lines to pyproject.toml simply isn’t manageable.
As it stands, this issue is preventing our entire data science department—comprising hundreds of professionals—from adopting uv, despite the significant enthusiasm and interest we have for it.
I’d sincerely appreciate it if this issue could be re-prioritized, and I’m more than happy to assist with testing or provide further examples if that would be helpful.
Thank you so much for your hard work, time, and dedication to this project! Your efforts are truly appreciated, and we’re excited about the possibilities that uv offers.
Warm regards,
Richard

@hoechenberger I wonder if you can clarify whether your need for the latest version possible on each Python is for libraries, applications, or both. A thought is that this non-forking approach currently taken is better for applications because it reduces the variations in a lockfile, and I'm curious what other people's needs are.
I'd prefer the forking behavior in applications as well, but I'm not sure whether that's just my library-maker brain having myopia because it's not getting what it wants right now.

In my opinion, packages should be resolved to their highest possible versions for each Python version separately. This is independent whether the project is a library or an app (the distinction is sometimes tricky anyway). If you develop an app, I think you should pin the Python version and all dependencies to fixed versions anyway, so this problem is not relevant. In addition, Python's official package manager pip has always done this, and now uv is doing something very different.

@ryanhiebert In the beginning I was only thinking about libraries here, but I'm quite certain some colleagues of mine would want this behavior for their apps, too. I can definitely see some good arguments for forking when resolving app dependencies, but of course also plenty of arguments against it. I believe for libraries, the case is more clear-cut.

@cbrnr

In addition, Python's official package manager pip has always done this, and now uv is doing something very different.

I believe this is actually an under-appreciated comment. Regardless of whether forking is the "good" or "worse" thing to do, I think we can argue that users and devs have been "trained" over the years to expect this "pip resolution strategy".

FWIW I'd argue that for an app the Python version should be fixed anyway, so the question of forking doesn't really come up.

I think that's worth a lot, and what I'd generally recommend. And if that's a generally good rule to follow for applications, then this exceptional behavior really only affects applications that need to simultaneously support multiple python versions. I suspect that's pretty rare; if I were distributing an application it would almost certainly be in a docker image, so the Python version would be specified as well.

In my opinion, packages should be resolved to their highest possible versions for each Python version separately. This is independent whether the project is a library or an app (the distinction is sometimes tricky anyway). If

This is very use case specific, for all my current uses cases I would rather have the same version of the library where possible, as when I'm testing my application across Python versions I want to minimize the amount of differences there are when investigating issues.

In addition, Python's official package manager pip has always done this, and now uv is doing something very different.

Pip doesn't do any kind of universal resolution and is a package installer, not a package manager, this is comparing apples to oranges. It would be much more apt to compare against Poetry.
That said, if all you want it a matrix of resolutions, uv does offer a pip compile API, and you can do,  uv pip compile --python 3.10 --python-platform windows ..., uv pip compile --python 3.11 --python-platform linux, etc.
FYI I'm not arguing this use cases shouldn't be supported, just it reads as universal declarations to things which are absolutely not universal.

FYI I'm not arguing this use cases shouldn't be supported, just it reads as universal declarations to things which are absolutely not universal.

@notatallshaw I really appreciate you chiming in! For libraries, it seems like the forking behavior would be the optimal default. For applications, I'm of two minds about it, and wish consistency was a good option, but I think for those moments where you really need your application to straddle Pythons it likely makes sense to default to avoiding forking.

This is very use case specific, for all my current uses cases I would rather have the same version of the library where possible, as when I'm testing my application across Python versions I want to minimize the amount of differences there are when investigating issues.

This is also very use case specific.

Pip doesn't do any kind of universal resolution and is a package installer, not a package manager, this is comparing apples to oranges. It would be much more apt to compare against Poetry.

Pip also resolves dependencies, but in a different way. The only important difference here is that pip resolves per Python version, whereas uv resolves across all Python versions.
The point is that we think there should be a flag to switch between these two different resolution modes, that's all. No one is saying that the current mode should be removed.

That said, if all you want it a matrix of resolutions, uv does offer a pip compile API, and you can do, uv pip compile --python 3.10 --python-platform windows ..., uv pip compile --python 3.11 --python-platform linux ..., etc.

This would be a lot of manual work, which is exactly what we would like to avoid.

FYI I'm not arguing this use cases shouldn't be supported, just it reads as universal declarations to things which are absolutely not universal.

I never said that it was universal, but pip is still the official standard. It interprets requirements defined in pyproject.toml a certain way, and uv deviates from this standard.

@cbrnr

The point is that we think there should be a flag to switch between these two different resolution modes, that's all. No one is saying that the current mode should be removed.

I would like to second that.
Like I said above, I don't see a need to argue about which approach is "better":
@hoechenberger

Regardless of whether forking is the "good" or "worse" thing to do, I think we can argue that users and devs have been "trained" over the years to expect this "pip resolution strategy".

We should just try to accommodate those users (and devs!) too, that's all.
@cbrnr

That said, if all you want it a matrix of resolutions, uv does offer a pip compile API, and you can do, uv pip compile --python 3.10 --python-platform windows ..., uv pip compile --python 3.11 --python-platform linux ..., etc.

This would be a lot of manual work, which is exactly what we would like to avoid.

Agreed. If that's the proposed way forward, uv adoption is sadly off the table for me and my colleagues.
I'm still very positive that we'll be able to see a solution that's works for all! 🙂

This is also very use case specific.

Do you have any evidence for that assertion?
Isn't this also Poetry's default behavior? And therefore the most common behavior among Python universal resolvers.

Pip also resolves dependencies, but in a different way. The only important difference here is that pip resolves per Python version, whereas uv resolves across all Python versions.

As a maintainer of resolvelib, the resolver for pip, and a regular contributor to pip's resolver code, I would say that isn't at all an accurate description of what pip does.
Pip only collects packages and requirements for a specific environment, that is, for all the environment markers defined by PEP 496, the resolver itself has no concept of a Python version.

The point is that we think there should be a flag to switch between these two different resolution modes, that's all. No one is saying that the current mode should be removed.

I strongly support this, but comparing universal resolution which is aware of environment markers to pip's resolution is fundamentally flawed way of looking at this.

I never said that it was universal, but pip is still the official standard. It interprets requirements defined in pyproject.toml a certain way, and uv deviates from this standard.

Pip is not an official standard. It is bundled into CPython to allow users to bootstrap their environment. Several core developers have expressed strong aversion to bundeling a dedicated package manager.
Further, there are no standards for resolution, only standards for specifier on a set of versions. The standards documents are very careful to avoid saying anything on how resolution should work.
If you want a pip API from uv then use uv pip, it's very good, I rely on it heavily and am quick to report if there's any unknown deviation with pip.

Yes, I agree that these are extremely valid points. I really do not want to discuss the technical details here, as I think they are not relevant. I'm simply saying that uv cannot be used for things where pip just works (see my example at the very top).
So let me focus on the most important point where everyone seems to agree:

The point is that we think there should be a flag to switch between these two different resolution modes, that's all. No one is saying that the current mode should be removed.

Agreed?

I'm afraid this discussion is derailing a bit. The goal of uv is to replace existing tools like venv, poetry, pip, ...
It's no use to fight over what behavior is better or worse.
Ultimate it's a question of who's the targeted user group.
And all @cbrnr and I are saying: without the ability to change the resolution strategy, we and large parts of our professional networks will fall outside of this group. Which is totally alright, no hard feelings. We just wanted to make the uv devs aware of this.
Have a nice day, everyone! 🤗

I'm afraid this discussion is derailing a bit. The goal of uv is to replace existing tools like venv, poetry, pip, ...
It's no use to fight over what behavior is better or worse.
Ultimate it's a question of who's the targeted user group.
And all @cbrnr and I are saying: without the ability to change the resolution strategy, we and large parts of our professional networks will fall outside of this group. Which is totally alright, no hard feelings. We just wanted to make the uv devs aware of this.
Have a nice day, everyone! 🤗

Yes, agreed it would be great for uv to support this use case, and agreed it's a real need for you.
That said, one nitpick:

I'm simply saying that uv cannot be used for things where pip just works

You can definitely use uv pip to replace pip for everything you've said in this thread.

You can definitely use uv pip to replace pip for everything you've said in this thread.

Then I would lose all the nice things that uv brings to the table like being able to just uv run things 😢, and it would "just" be a faster version of pip. I hope that's not what uv is intended to do.

Regarding the "specificity" of use-cases, uv tries to use consistent versions whenever feasible — this is a fundamental design principle of uv's user experience. I think it's fine to allow you to opt-in to different behavior, but changing the default behavior seems inconsistent.

This is very use case specific, for all my current uses cases I would rather have the same version of the library where possible, as when I'm testing my application across Python versions I want to minimize the amount of differences there are when investigating issues.

FYI, this will often mean you'll be using an old version of a library on a version of Python that wasn't released when it was released. That's the issue this is referring to; Numpy (and most other major scientific libraries) support the last three releases, instead of the last 5 or 6 which is more common (due to EoL often being followed to some degree). And at least Numpy specifically never works on a newer version of Python. If any library you depend on has a restricted Python range (libraries should be allowed to drop old Pythons!), that means you will very often end up with a resolution that would be impossible for pip, an old library on a new Python. It would be nice (and I think possible) if this could be detected and auto-forked if it happens; you never want to resolve a version of a library that is older than the Python you are using if there's a newer release available! This is true even for applications.
I believe this is a case where "consistent versions" is unfeasible. Maybe three modes: minimal versions, auto, and fork, where auto will fork if the python minimum required version causes back solving.

IMO this application should work out of the box without configuration on Python 3.13:
[project]
name = "numexample"
version = "0.1.0"
requires-python = ">=3.9"
dependencies = [
    "numpy",
]

Currently it takes almost two minutes to set up or crashes building NumPy, and likely has issues since it's using a NumPy (2.0.2) that doesn't support 3.13. I think the ideal case would be for it to fork on Python 3.9, so 3.9 has numpy==2.0.2, and 3.10-3.13 has numpy==2.1.2 (which takes 131ms to install).

@henryiii and it gets even worse if you look at my initial example at the very top, because you'd need to manually fork not only the direct dependency, but also all indirect ones.

that means you will very often end up with a resolution that would be impossible for pip, an old library on a new Python. It

I'm not quite groking what you mean here. If you come up with a resolution using pip on an old version of Python then it can also likely be impossible to use that resolution on a new version of Python.

And at least NumPy specifically never works on a newer version of Python.

As an aside, I'd like to understand this a little better. If you don't want to support old versions of numpy for your project, why are you resolving for versions of Python no longer supported by numpy?

As an aside, I'd like to understand this a little better. If you don't want to support old versions of numpy for your project, why are you resolving for versions of Python no longer supported by numpy?

It's the opposite. We want to support an older version, because we'd like to keep supporting Python 3.9 for example. But with uv, we get the old version for all Python versions, including a source build for 3.13.

I'd like to curtail further discussion about the motivation for this feature. I understand the motivation and why it's important. I'm not really interested in changing the defaults right now. But I am interested in supporting it. It is fairly challenging since (e.g.) the NumPy package metadata does not give any indication that (e.g.) NumPy 2.0.2 "doesn't support" Python 3.13, so it requires a variety of new and highly nuanced logic.

Ok, I believe I have this working at https://github.com/astral-sh/uv/pull/9827.


fail to identify route label

1.94.0The route tag element was not recognized after the version update

What language id is that editor using? Maybe the YAML grammar provider change in 1.93 is causing the outer language to miss the end of the YAML fragment in it.

What language id is that editor using? Maybe the YAML grammar provider change in 1.93 is causing the outer language to miss the end of the YAML fragment in it.

Now use the vue3 framework, this route tag is vite plug-in unplugin - vue - the router, https://uvr.esm.is/introduction, there is no question of no update yesterday, None of the syntax after the route tag is highlighted properly after today's update

The issue has been fixed

Now use the vue3 framework, this route tag is vite plug-in unplugin - vue - the router, https://uvr.esm.is/introduction

Now use the vue3 framework, this route tag is vite plug-in unplugin - vue - the router, https://uvr.esm.is/introduction,

What language id is that editor using? Maybe the YAML grammar provider change in 1.93 is causing the outer language to miss the end of the YAML fragment in it.那个编辑器使用什么语言 ID？也许 1.93 中的 YAML 语法提供程序更改导致外部语言错过了其中 YAML 片段的结尾。

https://github.com/microsoft/vscode/issues/227736#issuecomment-2333072638

Now use the vue3 framework, this route tag is vite plug-in unplugin - vue - the router, https://uvr.esm.is/introduction


[Question] large data set / virtualization ?

Hi,
I was wondering if that could be possible to intergrate mixitup with some virtualization such as:
https://bvaughn.github.io/react-virtualized/#/components/Collection
The idea would be to present a lot of items (let say 30K images to represent) and been able to virtualize them (not renderer outside of the view) and add the nice and smooth filtering animations of your library.
Or do you already have a nice way to handle such a data set ?
Many thanks!

Hi @MarcMagnin,
Have you checked out the MixItUp Dataset API? That would be the best way to approach the handling of a large dataset.
The following tutorials should be of interest:
https://www.kunkalabs.com/tutorials/using-the-dataset-api/
https://www.kunkalabs.com/tutorials/integrating-mixitup-into-your-project/

Thanks for the quick reply. I've check the API already.
I was wondering how this library could handle a lot of items (not infinite loading) to be able to filter on a large virtualized list.

Without using a server-side API in conjunction with the MixItUp Dataset API, you would be limited by the speed of the DOM and the DOM selector API, which will not be performant past a few hundred items.
I'm not exactly sure what you mean by "virtualized" in this context, as all items must exist in the DOM (whether hidden or shown). The Dataset API avoids this overhead by only rendering the current dataset, and caching any previously shown items in memory for performance.

Cheers.
I was wondering if we could have a virtualized grid view. Basically only the items in the window are rendered, other items gets rendered when filtering, with animations that simulates existing items (but they were not there at all, they got added to the DOM on the fly).
The advantage of such thing would be: have up to a million items in the grid with smooth animation of appearance, disappearance on filtering, all client side.

Hi Marc,
What you are describing is exactly what the dataset API does. You don't actually need to use it with a server-side API, although that's the most likely use-case.
You could easily just store your items in-memory in a javascript array, but you would need to implement your own system of filtering/sorting that array in the browser (essentially implement a client-side DB). This is exactly what the "Mock API" implementation does in the dataset demos:
https://demos.kunkalabs.com/mixitup/dataset-empty-container/
https://github.com/patrickkunka/mixitup/blob/v3/demos/mock-api.js

Thanks for your reply!
In this component you can easily scroll on a million items list: https://bvaughn.github.io/react-virtualized/#/components/Collection. The big drawback is that is misses the wonderful animations that you provide on appear/disappear of items on filter.

Hi @MarcMagnin,
Sorry - forgot to checkout your attached link until now. This is quite a specific piece of functionality and a bit different to how mixitup works. It's possible only because of absolute positioning, within a massively oversized container with vast amounts of empty space used to enable/fake native scrolling.
Unfortunately, MixItUp's entire "raison d'etre" is to work with pure-css flow-based layout, so anything based on absolute positioning wouldn't be possible in its current state. Have you checked out Isotope by @desandro at all? It's another animated filtering library built on top of the masonry library. I could imagine it might be possible to use it for this sort of thing.

Thanks for looking at it! I'll take a look at Isotope.


Add a message asking to add entry to guides-main.yaml if new guide

If a PR contains a new guide (i.e. new adoc file in docs/src/main/asciidoc), it would be nice if we could add a message such as:
Your pull request contains a new guide, could you add an entry for it in the [guides-main.yaml file of the website](https://github.com/quarkusio/quarkusio.github.io/blob/develop/_data/guides-main.yaml)?

> This message is automatically generated by a bot.

The index will be generated in the future so let’s close this one, not worth the hassle.


Could not load project anymore after project <-> Github repo out of sync

Describe the bug
Could not load project anymore after project <-> Github repo out of sync
To Reproduce
Steps to reproduce the behavior:

I have created a github repo for my project to see how that works
It worked for a while, then I think somehow a commit got lost at least it seems based on the Chrome exception that it looks for a commit that does not exist for some reason (error Sorry, we could not load this project on the Arcade page, additional errors in the Chrome console)
I have then deleted the whole github repo
Still does not load.
Also does not load if I clone the project (maybe that's another bug, that I would not assume that copy would copy the github references to the original project)
I also tried download / upload but did not solve the issue
See additional context for the error message in the Chrome console

Expected behavior
Project loads. :)
Desktop (please complete the following information):

OS: Windows 11
Browser Chrome
Version 114.0.5735.134

Additional context
Add any other context about the problem here.


Can't handle RDL.type for deferred contract

If we don't want to pollute the global namespace, is there a way to annotate methods using the deferred syntax? The obvious thing didn't work:
$ cat /tmp/file.rb
require 'rdl'

RDL.type '() -> NilClass'
def foo; end
$ ruby /tmp/file.rb
/Users/pt/.rbenv/versions/2.4.1/lib/ruby/gems/2.4.0/gems/rdl-2.1.0/lib/rdl/wrap.rb:213:in `block in do_method_added': Deferred type contract from class RDL being applied in class Object to foo (RuntimeError)
	from /Users/pt/.rbenv/versions/2.4.1/lib/ruby/gems/2.4.0/gems/rdl-2.1.0/lib/rdl/wrap.rb:206:in `each'
	from /Users/pt/.rbenv/versions/2.4.1/lib/ruby/gems/2.4.0/gems/rdl-2.1.0/lib/rdl/wrap.rb:206:in `do_method_added'
	from /Users/pt/.rbenv/versions/2.4.1/lib/ruby/gems/2.4.0/gems/rdl-2.1.0/lib/rdl/wrap.rb:623:in `method_added'
	from /tmp/file.rb:4:in `<main>'

:+1: for an alternative to the global namespace!
The other alternative I thought of was ... refinements 😱  !


Let renderers provide expression suggestions

This is a developer-side feature for renderer developers to dynamically suggest expressions based on current singer and resampler settings. An example of this feature is implemented in CLASSIC renderer that reads expressions from a resampler manifest file located in the same folder with the resampler.

Todos:

ship some common resamplers' manifest files with openutau builds (editable by users and not being reseted on updates)
support ENUNU flags (I don't know how ENUNU flag system works)
remove resampler.exe specific flags from new project creation, because some users may never use resampler.exe

An example of resampler manifest: moresampler.yaml
(encoded in UTF-8)
expressions:
  gen:
    name: Gender Factor
    abbr: gen
    type: Numerical
    min: -100
    max: 100
    default_value: 0
    is_flag: true
    flag: g
  bre:
    name: Breathiness
    abbr: bre
    type: Numerical
    min: -100
    max: 100
    default_value: 0
    is_flag: true
    flag: Mb
  tens:
    name: Tension
    abbr: tens
    type: Numerical
    min: -100
    max: 100
    default_value: 0
    is_flag: true
    flag: Mt
  pit:
    name: Pitch deviation (flag)
    abbr: pit
    type: Numerical
    min: -1200
    max: 1200
    default_value: 0
    is_flag: true
    flag: t
  pkcp:
    name: Peak Compressor
    abbr: pkcp
    type: Numerical
    min: 0
    max: 100
    default_value: 86
    is_flag: true
    flag: P
  amp:
    name: Amplitude Modulation
    abbr: amp
    type: Numerical
    min: -100
    max: 100
    default_value: 0
    is_flag: true
    flag: A
  cons:
    name: Unvoiced Consonant Gain
    abbr: cons
    type: Numerical
    min: -20
    max: 100
    default_value: 0
    is_flag: true
    flag: b
  fstr:
    name: Force Stretch
    abbr: fstr
    type: Options
    min: 0
    max: 1
    default_value: 0
    is_flag: true
    options:
    - ''
    - e
    - Me
  opn:
    name: Openness
    abbr: opn
    type: Numerical
    min: -100
    max: 100
    default_value: 0
    is_flag: true
    flag: Mo
  res:
    name: Resonance
    abbr: res
    type: Numerical
    min: -100
    max: 100
    default_value: 0
    is_flag: true
    flag: Mr
  dry:
    name: Dryness
    abbr: dry
    type: Numerical
    min: -100
    max: 100
    default_value: 0
    is_flag: true
    flag: Md
  cors:
    name: Coarseness
    abbr: cors
    type: Numerical
    min: 0
    max: 100
    default_value: 0
    is_flag: true
    flag: MC
  grwl:
    name: Growl
    abbr: grwl
    type: Numerical
    min: 0
    max: 100
    default_value: 0
    is_flag: true
    flag: MG
  dist:
    name: Distortion
    abbr: dist
    type: Numerical
    min: 0
    max: 100
    default_value: 0
    is_flag: true
    flag: MD
  stbl:
    name: Stabilization
    abbr: stbl
    type: Numerical
    min: 0
    max: 10
    default_value: 0
    is_flag: true
    flag: Ms
  mint:
    name: Model Interpolation
    abbr: mint
    type: Numerical
    min: 0
    max: 100
    default_value: 100
    is_flag: true
    flag: Mm

Cool stuff. A minor thing:
"Get suggestion" is quite ambiguous, it would be better to make it "Add all expressions suggested by xxx.exe and xxx.exe".

Cool stuff. A minor thing: "Get suggestion" is quite ambiguous, it would be better to make it "Add all expressions suggested by xxx.exe and xxx.exe".

I'll make it "Add all expressions suggested by renderers", because:

if the project contains a lot of tracks with different renderer and resamplers, the list might be very long and can't display correctly
Non-CLASSIC renderers can also suggest expressions, and the expression may also come from the singer.
This idea actually come from diffsinger development. Recently diffsinger has implemented voice color mixing. Each voice color in the voicebank will be a curve expression. Diffsinger renderer will suggest curve expressions based on voice colors included in the voicebank.


App Skeleton

Related: https://github.com/docker-mailserver/docker-mailserver-admin/issues/1

Goal: Generate the app skeleton which will eventually run the API

Hey @LukeMarlin , what is the language/tool you're choosing for the app and API?

Python with FastAPI, as discussed in other issues.
Most people leaned toward python so I'm pretty sure it's the best choice (possibly more contributors afterwards!).
When it comes to the framework itself, I'm more experienced with Flask, but FastAPI has a lot of nice things (like type checking, automatic "console" to explore the API) so I wanted to use it. I don't think we're going to have very specific development needs anyway, so I'm pretty sure any (light) framework will do just fine.
When it comes to project/packaging management, I'm going to use Poetry, and for testing management I'd go with Tox. These are tools that I'm using quite a lot at work and they've proved very nice so far.
As said before, if anyone has strong feelings against a tool, let's discuss this in this issue!

Most people leaned toward python so I'm pretty sure it's the best choice (possibly more contributors afterwards!).

Three of the most active developers don't either like Python or have much experience with it (myself included). I'm curious how active @DerOetzi and @simonwiles will ultimately be to help (please chime in).
What would objections be to something like golang?

I have more experience with Flask myself, but trying to switch to FastAPI with another project. For this I have the time to give some discussion input and review PRs, but I don't have time to develop the service by myself.

@NorseGaud Valid points, I mentioned people from the thread indeed, as it is a sidecar, so I hope your team won't be bothered too much with it.
I don't think golang is not fit to do this, plenty of libs exist already for APIs, but what I like about python for such simple jobs is how the code will be understandable to anyone, even non-python devs. It also mean that when it comes to small bugfixes, mostly anyone could do it.
Obviously the choice is up to you guys, I however don't intend to dive more into golang than I have (which isn't much), as I'm already trying to learn Rust on the side :)
If you wish, you can even decide once you've seen the skeleton + first route: if it looks like too complex to maintain in case external people bail out, feel free to choose another route, it would be understandable ;)

For sure, please proceed. As long as it works, I'm ok with it :)

I'm very interested in this. Did someone already start building? And is there anyone that is taking the lead in this project? I saw that there was still no decision made between Flask and FastAPI. I would be interested in contributing to a FastAPI application.

@thehunt100, since there's no voice clearly against, I started with fastAPI. Going to push the draft skeleton soon.

OK, great, is there anything you need help with?

Opened #4, which shows how I'd organize the app, feel free to comment about python stuff there!
There still much to do, but the most important part is to first know how to call the bash scripts. We can't just use setup.sh , because it is meant to be ran on the host machine, not inside a container.
My current idea would be to build this Dockerfile on top of docker-mailserver's so that all scripts are loaded and necessary packages installed. Then provide a docker-compose that gives access to postfix-accounts.cf, enabling us to call updateuseremail... One issue being that the image will be way bigger than a simple python one... Any other ideas/pointers welcome here :)

My current idea, that I'll try tomorrow, would be to build this Dockerfile on top of docker-mailserver's so that all scripts are loaded and necessary packages installed. Then provide a docker-compose that gives access to postfix-accounts.cf, enabling us to call updateuseremail... One issue being that the image will be way bigger than a simple python one... Any other ideas/pointers welcome here :)

I think this is a great idea. What we can do is PR in docker-mailserver to split the dockerfile into multiple layers so that you only build from what you need to execute the various inner-scripts.

@LukeMarlin I struggled with accessing the config files and scripts in my current solution, and I came up with some unconventional solutions.
In my situation, it was important to separate the admin part from the server part since I don't maintain the docker mailserver project and didn't want update conflicts.
I didn't want to let the admin run with mailserver editing permissions and be directly accessible from the internet in case of a security problem.
So the solution I came up with was to create a /config/run directory inside the docker volume.
The admin now creates the commands to execute on the mailserver and saves them as a file in the /config/run dir so a cronjob or inotifywait powered script with the right permissions can execute them.
This setup has a few added benefits.
It is straightforward to create an audit log to see when and who executed commands.
The admin can now run in its container with a low permission level since it only needs to access the /config/run for security and maintenance benefits.
Also, it is now easy to test the admin code since you only need to check the outputted commands.
It allows for extra validation on the server side, so the script that executes the commands can catch bugs or security problems.
I realize that this strong decoupled setup also has some downsides. For example, there is no direct feedback to give to the user. I do think this is possible when you run the command executer at a high frequency or on the command creation event with something like inotifywait. Also, to get the server's current state, it needs to provide that in the run dir, which is possible by copying the config files after they have changed.  For my use case, this was not a big problem.

I think this is a great idea. What we can do is PR in docker-mailserver to split the dockerfile into multiple layers so that you only build from what you need to execute the various inner-scripts.

Still, the srcipt to change password relies on dovadm pw, which, as far as I know, needs the complete dovecot package. It would actually be trivial to implement that in python, and the docker would just need access to postfix-accounts.cf file... But that might not be a good long-term solution.

The admin now creates the commands to execute on the mailserver and saves them as a file in the /config/run dir so a cronjob or inotifywait powered script with the right permissions can execute them.

So, you actually created .sh files that contained setup.sh commands, and configured the host machine to run them, correct? While I think this is a clever way of solving the access issue, I wouldn't say this have any impact on security, as a compromised admin could create any script in there anyway. Also, that does require some configuration on the host machine, which might not be what the team had in mind when mentioning a sidecar container

I save the commands as normal text files. Then I let the execute script parse them and validate the commands. Only predefined (whitelisted) scripts and commands will be allowed. You can run the execute script inside the container. In that case, you could copy the script into the container, but you could also do it on the host system like the setup.sh is doing now.

@LukeMarlin, I had envisioned this as running alongside a fully configured docker-mailserver container. That's why I said splitting the layers up a bit more in the mailserver repo so the docker tag layers are already on the host and can be re-used for the admin container without a ton of extra disk space.
How about the API runs on the same host as the mailserver and the UI can be placed anywhere the administrator wants?

That gets my vote!

How about the API runs on the same host as the mailserver and the UI can be placed anywhere the administrator wants?

If you mean running in the same container, I think that this might be the most efficient option. That way it's easy to use the scripts, and the API could still be optional (i.e: docker-mailserver:core & docker-mailser:apified). However from what I recall from the original thread, this wasn't popular among maintainers right?
If you mean on the same host in another container, sure, having more layers will help when it comes to disk usage. But the API will still probably require much more RAM than it should. On the other hand, would it be a viable solution for API other scripts in the future? For account related stuff it's just about a file that is easily shared, but I don't know all the possibilities of setup.sh, maybe some functions need to run on the target container?

Options we have available to us (not exhaustive):

Separate container

runs on the same host as docker-mailserver (core)

built off of and uses the same docker tag as core (minimizing disk usage for any deps specific to docker-mailserver-admin)

mounts config files so that it can execute ./setup.sh or even the various scripts directly

Same Container

update core repo's Dockerfile to run a cron (?) that looks for any mounted addons directories (required further discussion) and then loads them if found (loading the service)

cp scripts into?
mounts files into?

Am I missing anything?

Hey @LukeMarlin , I just updated the list of options available. Let me know if anything is missing.

Yes, as hinted above, we could make this image derive from core; not meant as a sidecar, but as a replacement.
So basically the project would provide two images: docker-mailserver:core-xxx and docker-mailserver:apified-xxx. The later including python stack and API code. This way there is no overhead on core, nothing needs to be added and it's very simple for people to swap from one to another as they see fit. I might be wrong there though, maybe it wouldn't be that practical to do, or develop
Now, my opinion on the list:
1.i: yeah I'm not so sure about this, sounds scary and brittle (might be wrong, not a sysadmin on docker guru)
1.ii.a: while this sounds interesting in general for core, I'm not sure how this applies here. It's not just a bash or perl script, we need an entire language installed, then some libraries to be able to run. Maybe I'm not getting this right though :)
1.ii.b: yes, that would work, but compared to completely replacing core, we're requiring one more container so it sounds like it's less ideal
1.ii.c that covers only the commands related to accounts. While nothing else has been asked for now, maybe we can keep other doors open?
1.ii.d this does work as pointed by @thehunt100. Regardless of potential security issues, it does changes the commands from sync to async, and also I'm not sure it would be possible to get command results/output
2.i :)
2.ii Looks like 1.ii.a, maybe i'm really not getting how it would look like, because I don't have thoughts on it!

Roger that, thanks for the reply to the points!
Updated:

Separate container

Something docker-in-docker? docker-in-docker (not likely a real solution, just referencing it here for those that are smarter and more experienced than I am)
runs on the same host as docker-mailserver (core)

docker-mailserver has a script that will load/start/manage any scripts in a certain folder (mounted). This is actually neat to think about
built off of and uses the same docker tag as core (minimizing disk usage for any deps specific to docker-mailserver-admin)

mounts config files so that it can execute ./setup.sh or even the various scripts directly

runs on a light-weight container tag

mounts in the postfix-accounts  file that when updated, triggers the docker-mailserver check-for-changes to do its thing.

runs on a light-weight container tag

Both the docker-mailserver and docker-mailserver-admin mount a file on the host

A script runs inside of the docker-mailserver to watch this file (it can be included inside of docker-mailserver-config-chksum), and if changed, will execute the command given (like executing updatemailuser)

Inside Same Container

Add to docker-mailserver (this was ruled out, just want it here for reference) similar to how ELK was: https://github.com/docker-mailserver/docker-mailserver/pull/1614/files
update core repo's Dockerfile to run a cron (?) that looks for any mounted addons directories (requires further discussion) and then loads them if found (loading the service)

 FROM mailserver/docker-mailserver:latest
 COPY ...
 CMD [...Run API...]

Side note -- The python version in the container is:
root@mailserver:/# python --version
Python 2.7.16

Are you planning on adding a requirements.txt for us to pip install with?

I'm using poetry for requirements. The version of python used in the draft is 3.9, but we should be able to use whatever python3 version that is on the docker (it's probably 3.7+, try python3 --version)

root@mailserver:/# python3 --version
Python 3.7.3

Just briefly chiming in as I saw this referenced from an issue I was removing a stale tag from today.
I had a response typed out weeks or so ago on the original discussion thread that I never got around to finishing. I shared mostly the same opinion as other maintainers that such a feature should be a separate project/container, but I wasn't against the main projects docker builds including a minimal API binary (eg rust compiled via CI on a separate repo).
That allows for anyone to build a separate container such as on alpine and add in their own public API or admin UI where any auth is implemented and TLS out of the server is taken care of. The main docker image would just be providing an minimal API to provide functionality like the bash scripts do, but imo more reasonable to interact with.
I suppose layering the API on top of the main image as a base works too. I recall a discussion about manipulating files directly instead of using the bash script functionality, and having a concern about changes such as passwords (which the original discussion was focused on).. the API discussion was suggesting pre-hashing passwords which IIRC would not work well if we changed from SHA512-crypt to a different hash at another point (new releases of distributions are shifting to yescrypt I think).

Seemed better to have the internal API service handle any state changes, which would be in sync with the bash scripts if it called those. A separate container proxies the API and can handle any rate limiting, TLS, auth etc. Since preferences may differ, eg for auth some may want OAuth, while others may be happy with mTLS, region locking, how logs/metrics are handled etc.
All of that is a separate concern from the minimal API required for docker-mailserver to expose such functionality without requiring each consumer service to execute scripts or directly manipulate files (maintenance concern).

Update: I'm currently playing with a Dockerfile that inherit docker-mailserver and trying to setup a working supervisord conf to run the program (barebone for now), then I'll add a basic nginx.
Goal here would be to provide a dropin replacement for docker-mailserver to try it out. It will be a testing build, not to be used on a prod server!
Anyway, I'm not very often available at the moment, it should be better mid-august, however I hope to have a build before that :)

then I'll add a basic nginx.

Might I suggest Caddy?
Although personally I still advocate for a minimal internal API service that we can ship on the official image (if dependencies and size required is minimal, like Rust would enable) with a separate image for a public API and anything like nginx/caddy.
Caddy has a very simple config and can handle features you may want such as automatic TLS provisioning with LetsEncrypt, one liner reverse proxy of a service, smart file type defaults for gzip, easy mTLS, etc.

then I'll add a basic nginx.

Might I suggest Caddy?
Although personally I still advocate for a minimal internal API service that we can ship on the official image (if dependencies and size required is minimal, like Rust would enable) with a separate image for a public API and anything like nginx/caddy.
Caddy has a very simple config and can handle features you may want such as automatic TLS provisioning with LetsEncrypt, one liner reverse proxy of a service, smart file type defaults for gzip, easy mTLS, etc.

I get the feeling that we'll have to open a large discussion about that once we prove this works building on top. It seems like a lot of the team is split on this right now (maybe just because they haven't seen it yet). 🤞🏼

Might I suggest Caddy?

Will check, I said nginx but in reality I wanted to first check if apache was present in the image to avoid installing stuff. In any case swapping the proxy could be done at any time anyway!

If you'd like to give Caddy a go, let me know if you'd like any help with it's config.
When using within Docker I believe you'd want to listen to <IP_ADDRESS> to properly respond to any external requests. And if we're not using an internal API with a separate public API container, to support LetsEncrypt or similar, with a public hostname (eg dms-api.example.com), you'd probably want to use an ENV var for that too unless the user is expected to modify the config.
Since Caddy handles the TLS provisioning, it'd need to have access to perform a HTTP port 80 challenge or Wildcard DNS challenge (requires custom caddy builds with DNS plugins IIRC), it is possible to use an existing TLS cert too, but they likewise need to be assigned the SAN that the API responds to. I imagine you might run into similar concerns with nginx or apache as well, but I'm still adamant about Caddy being nicer to work with config wise.
Again, if we had a separate internal API, most of those concerns can be delegated to a sidecar container, which proxies the internal API and perhaps provides a frontend web client for admin or whatever else you like. I assume some users would prefer to have nginx-proxy or traefik handle the frontend + API domains and TLS certs, which can be another use case to keep in mind.
Or perhaps I've misunderstood the approach being taken?

I've misunderstood the approach being taken?

So far my intention was to have only one API. It should be a very simple one since it will mostly call setup.sh. I don't see a need for splitting that in two APIs, especially a separate docker just for that! I'm experimenting to make a secondary docker image (core vs with-api) and that's it. Now, whether or not it ends up that way, it wouldn't change the code itself and most of what's done could be reused so I guess I'm going to continue what I started unless a clear consensus appears.

So far my intention was to have only one API. It should be a very simple one since it will mostly call setup.sh. I don't see a need for splitting that in two APIs

I recall a discussion about the API being reachable from a frontend web client, presumably a REST API.
There was talk of using an API key in the header request for auth, rate limiting and handling HTTPS. None of these things are required for the main API and are better delegated to a separate service imo that proxies the API to the public web if desired.
Is that no longer the case? How is the API being exposed or interacted with? Is the frontend web admin separate from the API project?

Maybe I don't understand what's your idea for an internal API? No https, no security, no rate limiting, so I suppose exposed only locally? What's its purpose?

Is the frontend web admin separate

As far as I'm concerned, yes. It could still be an option in the forked dockerfile, but for sure I don't think it should be embedded and mandatory along the API

What's its purpose?

An API where none of the other features are relevant to it's functionality?
It's quite common for services with Docker to only publish port 80 and defer HTTPS to a reverse proxy where a lot of those concerns are handled. Especially since the requirements and stack can vary for an environment.

I don't think it should be embedded and mandatory along the API

Ok great :+1:

Is the intention to have the API receive requests from the web client directly?
Would that be on different subdomain?
How were you envisioning deployment/configuration of that with HTTPS and related features for the API?

I'm happy to just wait and see once it's ready, my only concern was about how flexible the setup would be for different setups.
We seem to be on the same page, I was just considering the API and security as separate boundaries (it's important to have it, but ideally can be delegated to existing infrastructure that focuses on that).

Is the intention to have the API receive requests from the web client directly?

Current draft API is intended to be used directly, regardless of client. Could be a small cli, could be curl, could be a web panel or as suggested per someone else, a plugin in some webmail.

Would that be on different subdomain?

Didn't look into that. Ideally this should be configurable, for PoC it could be a chosen subdomain

How were you envisioning deployment/configuration of that with HTTPS and related features for the API?

Didn't think much of it yet either, it seems that caddy can take care of HTTPS which is nice. Other than that, I'd expect that a couple env values (token, domain) and a different docker image would suffice. Might be wrong though, I'll know soon enough when I reach that point. Technically I'm somewhat ready to test on my own setup.
As I said above, I'm busy and will be able to provide more after mid-august hopefully!

Could someone summarize - or point at - the decision that's been made so far for building out the container that will run this?
I would like to add to the discussion the idea of setting the API up to run by default on HTTPS.
Three modes we should consider

You already have a web facing webserver with letsencrypt and will proxy to this over HTTP
You need to use whatever webserver the project provides and will integrate with letsencrypt
You will run it with a self signed certificate

We could simplify and ignore 1/2 by just providing instructions to people on how to pull down and configure the linuxserver.io swag image https://docs.linuxserver.io/general/swag - which will get you an nginx with easy let's encrypt integration.
For more details on 3 - I suggest you look at the latest openwrt which defaults to https but using a self signed certificate - they even have details on 'trusting' that cert https://openwrt.org/docs/guide-user/luci/getting_rid_of_luci_https_certificate_warnings
As we are passing tokens / passwords around in the API we should make it secure by default.

Option 2 is the current one: https://caddyserver.com/
Caddy sets up https with letsencrypt by itself and defaults to it. This is the simplest solution, albeit not the most flexible. There should be no issue enabling users to provide their own frontend and certificates later on, however it's additional effort :)


feat(pathfinding)

Closes #91

initial ghost position & direction reverse allow ghosts to go through obstacles


Rename predicate #respond_to into #responds_to

PR for issue 73

How about interface?(:foo) - it would be consistent with dry-types where we have Types.Interface(:foo)

How about interface?(:foo) - it would be consistent with dry-types where we have Types.Interface(:foo)

I am not very familiar with dry gems yet. But i'll look deeply and will add code that ensures successful behaviour with Types.Interface

@solnic Do you mean to suggest using interface? as the name instead of responds_to??
It might work (especially it it's going to accept multiple arguments). responds_to? is a much more obvious name, though.

IMO, this only adds confusion. The ruby convention uses the infinitive form (has_key? -> have_key?). Either interface? or method? would work I think

I'd be OK with either interface? or method? too.

IMO, this only adds confusion. The ruby convention uses the infinitive form (has_key? -> have_key?)

I'm following the precedent made by includes?: https://github.com/dry-rb/dry-logic/blob/9e6d7762664b9bc99a4aa4f6f0e7fb8d7a8800ee/lib/dry/logic/predicates.rb#L184-L192

Either interface? or method? would work I think

I don't have a strong opinion (anything would be better than the status quo), but someone might mistake method? for implying the use of Module#method_defined?.

Ah yeah, I guess includes? wasn't a good choice either 😬

At this point (two years later), I'd say any choice is good enough. As long as it's a change. :-)
Though I guess this particular PR might limit itself to adding a new predicate (in a minor version), for you to remove the obsolete one in the new major (?) version.

I'm gonna go with interface? because we already have Types.Interface in dry-types so this would be consistent.

Closing after all as this was done via #99


CQ unit test needs to be re-enabled

At some point we need to look into why this change had to be made:
https://github.com/influxdb/influxdb/pull/1640/files
and fix the underlying issue.
@corylanou @pauldix

My bad, I should of logged an issue when I did the PR.  I'll be more diligent moving forward.

Duplicate of #1666


Create a compile_commands database for a cxx binary and its dependencies

Hello!
I set up a little C++ project in order to test Buck2 (I don't have any experience with Buck or Bazel).
One of the first thing I tried to do is setting up the generation of a compile_commands database for my IDE. I found the sub_target compile_commands but it seems it only allows generating the db for the binary and not its dependencies. Is it possible to do so? Also, I have to ask explicitly for the sub_target, but I would prefer to always update the db when the binary is updated, is this possible?
Thanks for your help!

There is a compilation-database subtarget on cxx_library and cxx_binary. Internally at Meta we have an LSP mode that when a file is opened, it uses the owners query (through Bxl) to find the right target, grabs the [compilation-database] for that target, and then uses that to drive the LSP. We haven't plumbed any of that into open source pieces. How do existing C++ LSP servers get the compilation database? If that is configurable, then it probably isn't too hard to hook it up to what Buck2 provides. But I don't think anyone has tried yet.

Chiming in since I'd love to see this (it's a huge pain in bazel). Generally speaking, clangd looks it up in a single monolithic compile_commands.json. Handling headers can be a challenge in that context.
For good clangd support, you'd want to aggregate all the compilation database files together output to the source root, and include entries for both source & header files. See https://github.com/hedronvision/bazel-compile-commands-extractor/blob/main/ImplementationReadme.md for a detailed explanation of what's required (and some technical details about how it happens in bazel)

^ Author of that Bazel tool here. Can confirm it was a pain :)
(Arriving not because backlinks are my batsignal or something; I just happened to be checking out the status of buck2.)
@ndmitchell, thanks for all you guys are doing here to share this with the world. Could I add to the header-only question: How do you guys handle the case where a parent target configures its children? For example, where an iOS rule configures cxx_libraries to cross compile?

I use clangd a lot as my C++ lsp, and previously only ever configured it for a single compilation database. But after looking into their issue tracker  a bit, I saw that it was pointed out that you can alternatively configure clangd by paths in a repo:
https://clangd.llvm.org/config.html#if
Clangd also does a bit of guesswork if it doesn't find a file in a configured compilation database: https://clangd.llvm.org/faq#what-can-i-do-if-clangd-chooses-the-wrong-source-file-to-infer-commands-for-a-header
with Bazel I was typically generating one using the hedronvision tool, and then post processing it a bit.

@photex, about that post processing: Anything we should learn from, there? We're always keen to just have the tool automatically clean up the command for folks.

If I really think about it, I think the post processing stopped being necessary in the most recent versions. But basically if the database wasn’t comprehensive enough I’d use the compdb script to fill it out.
https://pypi.org/project/compdb/
Unrelated to Bazel, but some Xcode projects at work also required me to fix toolchain paths and header paths. That’s not really an issue for buck2 though! :)

Thanks for replying so quickly! Compdb just to add commands headers--or for something else? (The tool should already be auto-enriching with headers, and way faster bc it can hit cache, but I definitely want to know if there's something we're missing.)
Curious also if there are more generalizable things we should fix for those Xcode projects. If so, would love more details (either here, or in an issue over on our project to not overly hijack this thread).

I've been fiddling with solutions to this problem.  A simple thing you can do is to just write a little script and build rule that combines databases: https://gist.github.com/andyfriesen/731baabd7cec5d1c24c53cc0691ca249
You can see that it has some problems: You need to name each individual target that you'd like to combine.  It's also pretty slow.  I'm testing this on a project with about 400 source files and it takes about 2s to build the database up from nothing.
BXL seems like it ought to be the solution here as it's super trivial to query the system for all cxx_binary and cxx_library rules, but I'm finding it quite tricky to get at the actual commandline arguments that are passed to the compiler from that angle.
If that's possible, it should be possible to write a single BXL that generates the whole database in a single action.  This should be quite a lot faster and mostly automatic.


output window code page

When i used vscode-cmake-tools to build project, the output text  defualt with utf8 code ; but how i change it to GBK(chinese charset)

Closing this issue. Please reopen if the merge that is referenced did not help with your case.


Recognize All Contributors

https://allcontributors.org 🤍

what is that?

what is that?

https://allcontributors.org is a platform and toolset designed to recognize and acknowledge contributors to open source projects, It aims to automate the process of adding contributor acknowledgements to project documentation, such as the README file, so that project maintainers can focus more on the project itself rather than managing the contributor list


Param bsearch

When parsing the parameter XML file, the parameters are sorted by name when written to the generated parameter files
Do a binary search of parameters when looking up by string
Use the utarray_find function for changed parameters now the bsearch is implemented in NuttX
Add a system command for param find

The drawback of this PR is that saved parameter values will be lost because the handles are no longer the same.
See (#6096)

The parameters test is now failing, unable to find the TEST parameters. https://github.com/stephanbro/Firmware/blob/899a94e78ec865d09dfa70a7f661b35ebe4bba40/src/systemcmds/tests/test_param.c
There are also a few trivial style errors. If you install astyle you can check this locally with make check_format or take a look at the CI failures.

@bkueng Thanks for the review comments! I addressed them in the latest commit and verified that the middle == last case you mentioned is not required.

Thanks @stephanbro, it's on master now.


Support configuring sqlalchemy with custom json_deserializer

This PR provides the ability for external clients to provide json_deserializer. This custom json_deserializer will then be used to configure sqlalchemy json_deserializer

I think it is better to just use **kw, since engine has some other args too.

Done.

I think it is better to just use **kw, since engine has some other args too.

Done

Can I get a PyPI release?


INPC: Skip change check (to support partial patch)

When using <NSwagClassStyle>INPC</NSwagClassStyle> to generate INotifyPropertyChanged, the generated C# code only calls RaisePropertyChanged when the property value differs from the original value.
I'd like to support partial patch (part of the JSON:API spec), which states that sending a property with its default value means something else than omitting it from the request body. For example, sending "firstName": null writes null in the database column, whereas not sending it leaves it unchanged.
I have a prototype using a stateful JSON converter to implement this. A client developer can call my helper to track property assignments. Example usage:
var updatePersonRequest = new UpdatePersonRequestDocument
{
    Data = new DataInUpdatePersonRequest
    {
        Id = "1",
        Attributes = new TrackChangesFor<AttributesInUpdatePersonRequest>(_apiClient)
        {
            Initializer =
            {
                FirstName = null, // <-- this gets tracked
                LastName = "last"
            }
        }.Initializer
    }
};

var response = await _apiClient.PatchPersonAsync(updatePersonRequest.Data.Id, updatePersonRequest);

_apiClient.Clear(); // optional: clears the tracked assignments for _apiClient reuse.

For this to work, I need RaisePropertyChanged to always be invoked when the property is assigned. Conceptually, this dirty tracking is similar to the IBackingStore in kiota, which is activated using the --backing-store switch.
My initial ask is to add a command-line switch to control this. It could be /skipChangeCheck (false by default), or an additional class style INPS (where the "s" means Set instead of Changed).
However, I imagine there's a barrier to adding new configuration switches, from a maintenance perspective. The next best thing would be to ship an adapted liquid template from our NuGet package, which gets activated in the target project from an embedded .props file in the package. But this means we need to include a customized version of the full Class.liquid, which contains many conditionals. While we only need to hide the line at https://github.com/RicoSuter/NJsonSchema/blob/1569e52401628d009af8044d1886d5a26770d05c/src/NJsonSchema.CodeGeneration.CSharp/Templates/Class.liquid#L107C13-L107C51:
if ({{ property.FieldName }} != value)

So the next best thing to ask for, is splitting up this template. This would reduce the risk of our copy getting out of sync with the built-in version. Similar to the existing Class.Inpc.liquid, I'd like to propose introducing Class.PropertySetter.Inpc.liquid with the following contents (extracted from Class.liquid):
{{PropertySetterAccessModifier}}set
{
    if ({{ property.FieldName }} != value)
    {
        {{ property.FieldName }} = value;
        RaisePropertyChanged();
    }
}

Whether it's going to be a new switch or an extracted template, I'd be happy to do all the work to implement/test this.
Please let me know what you think. Would one of these be an acceptable design, or would you prefer something else?
Are there additional concerns I should be aware of?

@RicoSuter Would you mind indicating your preferred solution here? I want to get some input to determine future directions for my project.
And can you please tag the core contributors, so they can also express their opinions?


[bug] Disrupts any use of a 'tap' of the  key (caps2esc etc.)

Description
Atuin, when not in "list mode", (normal usage of the console) absorbs any press of the <ctrl> key (waiting for a <ctrl>-r press) and (speculating here) resends the keys combination only on <ctrl>-<somekey> but not on a tap and release of the <ctrl> key alone. This disrupts any mapping of only the <ctrl> key.
Reproduce

Map some action to the tap of the <ctrl> key (I have mine used for caps2esc )
Start the console without atuin... caps2esc (or any other mapping) should work
start atuin... caps2esc stops working

When you are in "list mode" after pressing <ctrl>-r, caps2esc works as intended until you exit from it.

Hi, thanks for the report. Can you confirm what shell and OS you are running?
Are you using the default atuin setup script (through atuin init ___) or have you rolled your own?

Hi! I am running Linux with my shell being fish. I am using the standard atuin init fish | source in my config.


Fix tail panicing when seeking backwards

Previously tail -c n file.txt caused panic if n > sizeof file.txt.
Now it prints out whole file similarly to GNU tail.
Closes https://github.com/uutils/coreutils/issues/3872

Looks great, thanks


Fix typo in qiskit.optimization import redirect

Summary
In #4767 we added a namespace redirect for qiskit.optimizations to
qiskit_aqua.optimizations, however the module in aqua is named
optimization not optimizations. This commit corrects the oversight to
unblock Qiskit/qiskit-aqua#1127
Details and comments

Closing because of #5006