turbo: init at 1.7.0

Description of changes
Adds Turbo v1.7.0 https://turbo.build/
Things done
I have tested a simple monorepo setup. You can either not install turbo in npm or export this environment varible to override the binary:
export TURBO_BINARY_PATH="${pkgs.turbo}/bin/turbo"

Built on platform(s)

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

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

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

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

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module
[ ] (Release notes changes) Ran nixos/doc/manual/md-to-db.sh to update generated release notes

[x] Fits CONTRIBUTING.md.

@dit7ya thanks for the review, is there anything else?

@SuperSandro2000 lets merge this?

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:
https://discourse.nixos.org/t/prs-ready-for-review/3032/1606

@SuperSandro2000 Please review again

With the release of turbo version 1.7.0, could we update this existing PR? Or would that require a new PR?

Just update this one.

I'll try to upgrade to 1.7, but its a bit of a change, they renamed this to go-turbo and combined it with their rust turbo cli

I've added the rust package but getting the error:
# Error: `#![feature]` may not be used on the stable release channel

Does anyone know how to use beta/nightly in nixpkgs?

You can set RUSTC_BOOTSTRAP = 1; as a hack, it would allow you to use nightly features on stable rust.

@NickCao good idea, but i get this error:
error[E0658]: custom discriminant values are not allowed in enums with tuple or struct variants
  --> crates/turbo-tasks/src/no_move_vec.rs:23:12
   |
23 |     None = 0,
   |            ^ disallowed custom discriminant
24 |     Some(T),
   |     ------- tuple variant defined here
   |
   = note: see issue #60553 <https://github.com/rust-lang/rust/issues/60553> for more information
   = help: add `#![feature(arbitrary_enum_discriminant)]` to the crate attributes to enable

If there is no solution, I could roll it back to v1.6 for now

aah, yet another go2rust migration ^^
for me, the go-turbo checkPhase i failing with Timed out waiting for filesystem event
quickfix in preCheck: rm -v internal/filewatcher/filewatcher_test.go
HOME=$(mktemp -d) is non-deterministic, should be HOME=/tmp or so

Does anyone know how to use beta/nightly in nixpkgs?

not at all, it seems : /
https://nixos.wiki/wiki/Rust

nixpkgs only maintains a single version of the Rust stable toolchain

see also
https://discourse.nixos.org/t/nixpkgs-rustplatform-and-nightly/22870
https://ryantm.github.io/nixpkgs/languages-frameworks/rust/

I have created an issue for the turborepo team to remove unstable features from their codebase https://github.com/vercel/turbo/issues/3356
We have no idea if they will take acion on this, so i have reverted back to the v1.6.3 go only version.

@SuperSandro2000 would you please review again :pray:

@dlip arbitrary_enum_discriminant has been stable since Rust 1.66.

@nox unfortunately nixpkgs is on rust 1.65. I wonder if 1.66 will fix all the compiler errors if they upgrade...

rust 1.66 should be available on master now, you can do a rebase.

I was able to get 1.7.0 working with rustc v1.66! So were back to the latest version again.

@SuperSandro2000 can you please review again :pray:

This PR is mostly ok now. But I found that there are a few extraneous binaries in the final output:
go-turbo  next-dev  node-file-trace  swc-ast-explorer  turbo  turbopack-create-test-app  xtask
Are they all part of the turbo cli? Maybe xtask does not belong here.

@NickCao when vercel acquired turborepo, they combined it with their turbobundle product under the 'turbo' umbrella. I think those extra binaries are needed for turbobundle, but I haven't investigated what they all do yet. Does anyone else know?

Is upstream providing binary releases? We can check that.

failing test: github.com/vercel/turbo/cli/internal/filewatcher
https://github.com/vercel/turbo/issues/3339
→ remove this test

Is upstream providing binary releases?

no, https://github.com/vercel/turbo/releases has only source releases

I found that there are a few extraneous binaries in the final output:
next-dev node-file-trace swc-ast-explorer turbopack-create-test-app xtask

https://github.com/vercel/turbo/search?q=next-dev

the next-dev CLI will keep watching for changes to your application

next-dev to use in integration test

The simplest way to run Turbopack's benchmark suite is with the command cargo bench -p next-dev.

to test the Next.js development server, run cargo run -p next-dev.

→ external binary, can be moved to separate output
https://github.com/vercel/turbo/search?q=node-file-trace

additional PATH environment variable to use for spawning the node-file-trace process

→ internal binary, shoule be part of the node-module-trace npm package
https://github.com/vercel/turbo/search?p=2&q=swc-ast-explorer
→ external binary, can be moved to separate output
https://github.com/vercel/turbo/search?q=turbopack-create-test-app
→ external binary, can be moved to separate output
https://github.com/vercel/turbo/search?q=xtask

turbo-tooling cargo tasks

cargo xtask publish

→ external binary, can be moved to separate output
maybe add turboFull = symlinkJoin ... with all outputs

I've simplified the build to just build turborepo which was the main binary causing issues on nixos, the others seem to be ok when installed via npm.

@SuperSandro2000 can you please review again :pray:

If @SuperSandro2000 is busy, I can review this, though I might miss some things from prior discussion (which there was a lot of) by mistake.

This doesn't seem to be working? Did they change the git tag or something 🤨
$ nix-shell -I nixpkgs=https://github.com/nixos/nixpkgs/archive/2ccbaee72e6f8ef7c9ef6cd8f1faf298ba0bbac1.tar.gz -p turbo
these 5 derivations will be built:
  /nix/store/bq1akrsvhcmpnzlzmnigzcv3vg07scpg-source.drv
  /nix/store/mk6bpg9yvxdxfnpddpg3wp86lpjiz8z8-go-turbo-1.7.0-go-modules.drv
  /nix/store/4244pq2p8n393sa75nxvw8m3qca43c3g-go-turbo-1.7.0.drv
  /nix/store/50kfg3xmdcv06mlc6m41cd5fd8lv3mws-turbo-1.7.0-vendor.tar.gz.drv
  /nix/store/smw0pfy3vy22s9j6ypmmmr0b65wsfhdn-turbo-1.7.0.drv
these 3 paths will be fetched (4.29 MiB download, 16.76 MiB unpacked):
  /nix/store/8n1x03dayw7gvs8rd8d8hbx7215ac6qq-cargo-check-hook.sh
  /nix/store/cvj43037d5vaxrzrwn6z8qp5nhd9zcng-cargo-1.67.0
  /nix/store/z0q61m6bamz9amzdhg8cwasm351mgr51-cargo-build-hook.sh
copying path '/nix/store/cvj43037d5vaxrzrwn6z8qp5nhd9zcng-cargo-1.67.0' from 'https://cache.nixos.org'...
building '/nix/store/bq1akrsvhcmpnzlzmnigzcv3vg07scpg-source.drv'...

trying https://github.com/vercel/turbo/archive/v1.7.0.tar.gz
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
copying path '/nix/store/z0q61m6bamz9amzdhg8cwasm351mgr51-cargo-build-hook.sh' from 'https://cache.nixos.org'...
copying path '/nix/store/8n1x03dayw7gvs8rd8d8hbx7215ac6qq-cargo-check-hook.sh' from 'https://cache.nixos.org'...
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0
100 32.2M    0 32.2M    0     0  11.0M      0 --:--:--  0:00:02 --:--:-- 17.7M
unpacking source archive /build/v1.7.0.tar.gz
error: hash mismatch in fixed-output derivation '/nix/store/bq1akrsvhcmpnzlzmnigzcv3vg07scpg-source.drv':
         specified: sha256-YTuEv2S3jNV2o7HJML+P6OMazgwgRhUPnd/zaTWfDWs=
            got:    sha256-KARLBdoXaGXCcVtBFHasltrWub5Y0eI53I/Q2MTQ3xU=
error: 1 dependencies of derivation '/nix/store/smw0pfy3vy22s9j6ypmmmr0b65wsfhdn-turbo-1.7.0.drv' failed to build


Problem with the massmailer

When the cron runs, the massmailer don´t send de emails and shows the following message in the php_error.log
[10-Jun-2015 03:10:01 UTC] Error executing massmailer queue: Admin is not logged in
Any Idea?

That message is dated June 2015, which was years ago, so isn’t a current error.
Although, I receive a different error when I attempt to use it, although it may be due to the cron job not being setup correctly.

Can people replicate this?
I think if we can't replicate / confirm these old issues it would be best practice to leave them closed. If someone puts in a fresh ticket, then we can take care of it, but otherwise we will just have old issues piling up with nobody who can replicate the issue

related to
'verify_peer' => true,
'verify_peer_name' => true,
?? SSL


OCPBUGS-884: Update rhcos release browser url

With this change, rhcos image can be acquired again: https://brewweb.engineering.redhat.com/brew/taskinfo?taskID=47567090

/cherrypick release-4.11
/cherrypick release-4.10

/approve
/lgtm


Identity Revocation [Milestone 1]

Closes #3

Just realized I forgot to approve this.

Just remembered you asked me to give you a minute on this PR.


Cleanups and substantial bug fixes

This branch contains

some cleanups (mostly mechanical reformatting and some python style changes)

a new MemoryMap class that supports trapping read/write/execute access to particular memory
ranges (e.g. useful to simulate I/O, or to trace/intercept access to special memory locations)

fixes many opcode and addressing mode bugs found by adapting the test suites from the https://github.com/mnaberez/py65 project

implements basic support for BCD mode, though this is incomplete (only handles valid BCD arguments), not especially elegant in implementation and likely still has bugs

The test suites here still find more bugs: https://github.com/Klaus2m5/6502_65C02_functional_tests/
which I may try to look at further

Thank you. Lot's of nice updates.


Project Files and Python Packages sections can hide under Credentials section

This seems to keep happening to me but the Project Files and Python Packages often slip under the Credentials section and I can't find them.
The Credentials and Configuration sections don't have the same problem. I suspect those are "tree views" while Project Files and Python Packages are webview.
https://github.com/posit-dev/publisher/assets/41300090/3d156ee3-ef19-4743-a2f7-5886f3bd1b35

Closing this one as everything is now inside the webview. Nothing will be hidden under, the entire Home view is scroll-able.


java.lang.NoSuchMethodError: android.view.View.setTranslationX

Hey @leixinstar could you provide more details? Like the stacktrace? Also, I should point out that ParallaxPager only support Android 14+

I solved


Make docs tasks cacheable

Make the doc tasks cacheable to allow building the all distribution from cache.

I submitted a PR to the Asciidoc Gradle Plugin to make it cacheable without the hack: https://github.com/asciidoctor/asciidoctor-gradle-plugin/pull/215

Thanks for the feedback @wolfs! Can you have another look. At particular at the PathSensitivity stuff?


flaky tests in packages/jellyfish-api-core/__tests__/*

What happened:
We frequently see flaky tests in packages/jellyfish-api-core/__tests__/*, this needs to be fixed to optimized the PR experience.
/triage accepted
/area packages

Any specific tests that are particularly flaky or where can I find the logs for this?

Any specific tests that are particularly flaky or where can I find the logs for this?

Right now it's unclear; there are a few on the loan side. I open a thread to start tracking them so we can watch for them and resolve them.

Here's one:
FAIL packages/jellyfish-api-core/__tests__/category/loan/placeAuctionBid.test.ts (260.244 s)
  ● placeAuctionBid success › should placeAuctionBid with utxos
    RpcApiError: 'Insufficient funds', code: -4, method: placeauctionbid

@fuxingloh where's the thread?


combine HITheme and HIPalette into HIAppearance

Combines the Theme and Palette structs into one structure, provides a single code path for accessing state affecting the current appearance.
Refactors HIApplication into multiple files

what are you kids doing lol?


Kimikyu lobby screen

About the PR
Adds a new lobby screen for nyano and it's downstreams by a new artist in our community
Media

[ x] I have added screenshots/videos to this PR showcasing its changes ingame, or this PR does not require an ingame showcase

Changelog
:cl: TheBlackHorizons

add: Added new lobby screen

replace one of the 3dcg ones with this

removed the last one

I'm going to miss the room.


Create metadata output file for fitting parameters

Right now there is no metadata file for the fit. If someone wants to refit a dataset exactly how it has been fit previously, there would not be an easy way to do so.
We should include a fit metadata file that includes all user inputs into the fit, and that can be read back into the code. All of the FitMethod inputs should be included here.

Can resolve #82 as well in a single PR


Allow only to put edges on some of the entities through ExtendedMaterial

put value in the gbuffer through the deferred value, creating a mask of the entites whose pixels should run the edge detection shader

[x]  allow for having the plugin in either per component, or full mode
[x] create a bundle of components needed on the Camera to enable this effect
[x] make the flag position in the deferred buffer a constant somehow
[x] dont require the custommaterial to have the wgsl code in assets
[x] more ergonomic ExtendedMaterial usage for this usecase

@IceSentry please have a look and see if this is something you would like to include in this library

So, I don't like that this forces people to use deferred and a custom material to achieve this. I like that the current plugin doesn't force any configuration and can work with any material.
This approach is fine if deferred is detected but it should be optional. If deferred isn't used the plugin should still work but maybe warn that individual mesh outline won't work.
For the material, I'd much prefer if the plugin offered a few utility functions that material author need to call to make the feature work instead of relying on an extended standard material. This way it would work with any material.

Hmm
Yeah I get your point, still it doesnt really work with any material I assume, since it cant work with transparent types.
But trying to get the pipeline to adapt this much to what is essentially a camera component that can be added whenever, is a bit beyond me. Mostly because I do not have the understanding about the graphics pipeline.
Do you have any idea on how to achieve this, or could an approach be to add a EntityEdgeDetectionPlugin alongside the regular EdgeDetectionPlugin, and maybe rename that to FullscreenEdgeDetectionPlugin? Or should that particular configuration live as a member inside EdgeDetectionPlugin?
Regarding the material, I have no better idea currently...

I don't really have a suggestion but what I'd like to see is this feature to be completely optional. I don't mind it only working with deferred but I don't like forcing deferred while the algorithm works perfectly fine with forward.
For the material, I think all you'd have to do is provide a write_edge_mask_bit() function or something like that that does the logic and users would just need to import that function and call it in their shader. As long as the plugin is added to bevy the function will be available from any shader using #import bevy_mod_edge_detection::write_edge_mask.
To support this in forward it would need a separate mask texture that users would need to write to. It's definitely more complicated so I'd be fine if it wasn't in this PR.

Hmm, would this be acceptable as a feature on the crate then, that is not available by default?
"per_entity_edge_detection" or "edge_detection_material" perhaps?

As long as it's opt in I don't mind too much. I'd prefer a way to not require a feature flag but if it's the only way to make it opt in then that's fine.

Managed to get it feature gated, and also workable without any kind of modification to the simple example, then added a completely new example for the extendedmaterial


fix typo in gen_fisher_data.py and created new static fish data with …

…it for 5.25 fish

Thanks! Some day I will remember to run this script regularly.


nike flake check warns of unknown output for Home-Manager configs

Currently running the test target yields:
 ➜ make test
nix-shell shell.nix --command 'nix flake check'
warning: Git tree '/home/nikita/Documents/repos/infra' is dirty
warning: unknown flake output 'homeConfigurations'

Investigate if there is a way to disable this warning.

Closing - currently a limitation of flakes.


[KeyVault] listPropertiesOfSecretVersions failing from 2nd page

I'm using @azure/keyvault-secrets version 4.5.0 with the following code
public async listSecretVersions(secretName: string): Promise<Array<{version, createdOn}>> {
    const versions = [];
    for await (const page of this.client.listPropertiesOfSecretVersions(secretName).byPage()) {
        for (const versionOptions of page) {
            versions. Push(versionOptions);
        }
    }
    versions. Sort((a, b) => a.createdOn < b.createdOn ? 1 : -1);
    return versions;
}

The above code is based on the sample from the official documentation and used to work with version 4.4.0.
After upgrading to version 4.5.0 I started seeing 404s on the 2nd page of this call.
Downgrading back to version 4.4.0 works well and inspecting the code showed that both calls seems to go to the same URL with the same query params (api-version = 7.3 and skipToken looks the same).

Hi @barneaoren, thanks for the report! I have reproduced the issue and am investigating.

I have identified the issue and will be releasing a 4.5.1 with the fix later today. I've also fixed the gap in our test coverage that allowed this to slip through the cracks. Appreciate your patience, and apologies for the inconvenience.

Just a quick note that I see this is already live:

@barneaoren please give the update a try and let us know if you are still having any issues.
Huge thank you to @timovv for the quick fix!

@xirzec - Just updated my code to pick up with v4.5.1 and was able to run it with no errors.
Thanks for the super quick turnaround @timovv


boehmgc: 8.0.0 -> 8.0.2

https://github.com/ivmai/bdwgc/releases/tag/v8.0.2
Motivation for this change
Sending to staging due to (guessed) rebuild count.
Things done

[ ] Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS)
Built on platform(s)

[ ] NixOS
[ ] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nox --run "nox-review wip"
[ ] Tested execution of all binary files (usually in ./result/bin/)
[ ] Determined the impact on package closure size (by running nix path-info -S before and after)
[ ] Assured whether relevant documentation is up to date
[ ] Fits CONTRIBUTING.md.

@GrahamcOfBorg  build nix nixUnstable w3m asymptote

Been working for me, doesn't seem reason to delay.  Borg is timing out, FWIW :).


Add GitHub social provider to uProxy

Greg, can we close this and track smaller issues with the label "Github"?

This is now done


[API] Remote control?

I see that Gabin may be connected to a "Companion" device. Is there any documentation anywhere to see what features may be controlled by a remote controller?

We were waiting for Companion to load our module but they are busy working on Companion V3
We decided to stop developing the module and to give access through OSC!


agent: Use agent field to control create message for this flag

filing as per #800
The context around this particular TODO seems unclear. If anyone has context around this, would they mind posting a comment explaining what needs to be done to close out the TODO?
https://github.com/yewstack/yew/blob/1ede16795a8f08975708e1808c0d528f31d5c946/src/agent.rs#L825

Irrelevant as of #2326
If improvement is needed, feel free to recreate the issue in gloo repository


docs(samples): updated samples code to use async await

Fixes googleapis/google-cloud-node#2869 (it's a good idea to open an issue first for discussion)
Fixes https://github.com/googleapis/nodejs-tasks

[ ] Tests and linter pass
[ ] Code coverage does not decrease (if any source code was changed)
[ ] Appropriate docs were updated (if necessary)

@ajaaym Hi, Please review the code changes and let me know if any changes required, need approval to create PR!


Using newly trained lstm models

A scaler file is required in order to use a lstm model other than the ones saved in the repository.  @jmframe where do these get generated from?  Wasn't clear in the neuro hydrology if it produces this.  Can you provide any guidance on the steps to bring a new lstm model for inclusion?

Yes, it is created by NeuralHydrology when the training data are compiled. It looks like newer versions use a YML file, instead of a pickle file, which is probably better: https://github.com/neuralhydrology/neuralhydrology/blob/1ff36ea8c8eff99ad25fa0f56f0119acbc9e6799/neuralhydrology/datasetzoo/basedataset.py#L193

Just to make sure, you are training a new model with NeuralHydrology? If not, that is okay too, just need to know.

Just trying to get some people familiar with the entire process, including training a model and then operating it here.  @madMatchstick worked through training a model using neuralhydrology but didn't find the scaler file to try using it with the lstm bmi.  It may be that we were just looking for a pickle file instead of the yaml file, haha.  I browsed through the code and found the function you referenced, but wasn't sure if it required some custom option to ensure it got dumped or not.  Thanks for the quick reply!

Yeah, no problem. Feel free to ask away. I'm happy to help, and I would like to stay involved, if possible. Where are you doing the training? What machine, what dataset?

Thanks @hellkite500 & @jmframe for clarification on scaler pickle vs yaml file.
I was able to adjust get_training_configurations() and get_scaler_values() for proper yml read-in.
However, I am still getting a runtime error during bmi.initialize , but very possible that the newly trained file(s) are garbage.
Current model's batch_size and inputs are correct; ([256, 35]).
When manually matching the model "shape" to the apparent weights shape ([256, 128]), the forward-pass fails at  input_view.
I'm generating another simple sample training set to test, and will leave this issue open for now.
RuntimeError: Error(s) in loading state_dict for Nextgen_CudaLSTM:
        size mismatch for lstm.weight_ih_l0: copying a param with shape torch.Size([256, 128])
        from checkpoint, the shape in current model is torch.Size([256, 35]).

Curious @jmframe - how much of your focus was on training and evaluating via neuralhydrology? I do have a couple (configuration, etc.) questions if you're up for it and have the time to spare?
Oh and I'm using hourly_camels_us dataset but only over a handful of basins as I'm just running things on my work laptop.

@madMatchstick okay, this should be an easy fix. You should have a NeuralHydrology configuration file that the BMI is reading in, correct? Can you send me a link or paste it here? What inputs are you trying to use?
All the training and evaluation was done with NeuralHydrology. And it was extensive.
Yes, let's meet during an afternoon next week.


jstl 1.2 embeds the taglibs/standard dependency

taglibs/standard is no longer necessary since it is in the jstl 1.2 jar
see: http://stackoverflow.com/tags/jstl/info

Merged into 4.2 as well.


Initial Setup for Henry

[x] 1. Henry has GitHub access and is invited to the ANNDEA page.
[ ] 2. Henry - Git Clone ANNDEA to his local PC
[ ] 3. Henry can log in to lxplus and download and install ANNDEA there.
[x] 4. Overview of the ANNDEA
[ ] 5. Access to Google Drive with Files
[ ] 6. Download the B41 file.

Blocked, as we waiting for a proper LXPLUS account.


approximate cautions consequences

I would just call the function approximate and return None if a problem became unsatisfiable.

But I already did the changes in my previous commit. :cry:

Sorry, I think I messed it up.
I tried to restore you changes.
Can you check that everything is good now.

It's really easy to restore a commit:
git reset --hard 766d6cecb64dbccc53bce5927515e9a1e6d70034
git push --force

As long as git did not cleanup, you can even restore commits that are not in the history (git reflog is your friend here).

The PR would be okay from my side but maybe you still want to add something.

Thanks, I just added a clarification on returning None. It is now ready on my side


ERROR running force:source:deploy: Component conversion failed: Cannot create property 'CustomObject' on string ''

Summary
When deploying custom fields and custom object the deployment failed with this strange message.
Steps To Reproduce:
NOTE: If your issue is not reproducable by dreamhouse-lwc, i.e. requires specific metadata or files, we require a link to a simple Salesforce project repository with a script to setup a scratch org that reproduces your problem.

Retrieve your custom fields
Try to deploy them with the sfdx force:source:deploy -x manifest/package.xml --targetusername devUserNameAlias --checkonly --verbose

Expected result
Deploy with success.
Actual result
*** Deploying with SOAP API v52.0 *** ERROR running force:source:deploy:  Component conversion failed: Cannot create property 'CustomObject' on string ''
System Information
sfdx-cli/7.136.2 linux-x64 node-v14.6.0
Additional information
Package.xml file below
<?xml version="1.0" encoding="UTF-8"?>
<Package xmlns="http://soap.sforce.com/2006/04/metadata">
    <types>
        <members>Account</members>
        <name>CustomObject</name>
    </types>
    <types>
        <members>Account.Field1__c</members>
        <members>Account.Field2__c</members>
        <members>Account.Field3__c</members>
        <name>CustomField</name>
    </types>
    <version>52.0</version>
</Package>

Feel free to attach a screenshot.

I am experiencing this again in 7.180.0. The workaround solved the issue but it appears the fix is no longer working.


Refactor the entire interface

From #61 by @art-w:

You probably don't want to call this run on all the http calls, rather the Equinoxe api should also produce Lwt values when the backend requires it. To stay compatible with "direct style" I/O, you can abstract the monad in the backend:
type 'a m
val return : 'a -> 'a m
val bind : ('a -> 'b m) -> 'a m -> 'b m
(* ... *)
val post : t -> path:string -> Json.t -> Json.t m

Then the backend can instantiate with type 'a m = 'a Lwt.t or type 'a m = 'a (here's an example of what it might look like)

I'm not sure that Json.t = (Ezjsonm.value, ...) result is the right type for the input? (the body of the request could be a string or Ezjsonm.value, but the backend shouldn't care about an Error in the input?)

The HTTP module should be abstract to hide to the user the content.
The Json type should be updated to better fit the requirement. The result type might not be needed only from extraction. Maybe the result type should be used as follow `(Json.t, Json.error) result.

Done in #63.


Improve layout

While testing https://github.com/atom/atom/pull/9274 I noticed the messages run into the footer.

This PR makes only the .chat-messages scroll, but keeps the rest visible:

@simurai Thank you so much :+1:


prometheus: 2.26.0 -> 2.27.1

Motivation for this change
Open redirect vulnerability in the /new endpoint that was used for migration between the old and the new UI.
https://github.com/prometheus/prometheus/security/advisories/GHSA-vx57-7f4q-fpc7
Sadly the vulnerability was introduced in 2.23.0, which is the exact version we have in 20.09.
https://github.com/prometheus/prometheus/releases/tag/v2.27.1
https://github.com/prometheus/prometheus/releases/tag/v2.27.0
Things done

[x] Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS linux)
Built on platform(s)

[x] NixOS
[ ] macOS
[ ] other Linux distributions

[x] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
[ ] Tested execution of all binary files (usually in ./result/bin/)
[ ] Determined the impact on package closure size (by running nix path-info -S before and after)
[ ] Ensured that relevant documentation is up to date
[x] Fits CONTRIBUTING.md.

Not having looked at the code.. they've backported it to 2.26.x - surely the redirect code that was added in 2.23 wasn't touched heavily (at all?) in that time, so I wouldn't have expected a further backport to be difficult.

Yup, looks small.
https://github.com/prometheus/prometheus/commit/6eeded0fdf760e81af75d9c44ce539ab77da4505


Fix missing logs for majority of routes

closes #225

Pull Request Test Coverage Report for Build 936218219

8 of 8 (100.0%)  changed or added relevant lines in 5 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage increased (+0.009%) to 98.971%

Totals

Change from base Build 928301381:
0.009%

Covered Lines:
362

Relevant Lines:
364

💛  - Coveralls

Pull Request Test Coverage Report for Build 936218219
Warning: This coverage report may be inaccurate.
This pull request's base commit is no longer the HEAD commit of its target branch. This means it includes changes from outside the original pull request, including, potentially, unrelated coverage changes.

For more information on this, see Tracking coverage changes with pull request builds.
To avoid this issue with future PRs, see these Recommended CI Configurations.
For a quick fix, rebase this PR at GitHub. Your next report should be accurate.

Details

8 of 8 (100.0%)  changed or added relevant lines in 5 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage increased (+0.008%) to 98.971%

Totals

Change from base Build 928301381:
0.008%

Covered Lines:
362

Relevant Lines:
364

💛  - Coveralls


python36Packages.praw: 5.4.0 -> 6.0.0

Semi-automatic update generated by https://github.com/ryantm/nixpkgs-update tools. This update was made based on information from https://repology.org/metapackage/python3.6-praw/versions.
meta.description for python36Packages.praw is: '"Python Reddit API wrapper"'.
Compare changes on GitHub

Checks done (click to expand)

built on NixOS

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

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

found 6.0.0 with grep in /nix/store/l21xcs2a0pn5rd0fsipaff256l7h69s1-python3.6-praw-6.0.0

directory tree listing: https://gist.github.com/78ee3361a268e7812795f762e0a9380f

du listing: https://gist.github.com/982f1d57b16fbeb1ae1cbbacd5e54359

Outpath report (click to expand)

Outpath difference report
15 total rebuild paths
4 package rebuilds
4 x86_64-linux rebuilds
4 i686-linux rebuilds
3 x86_64-darwin rebuilds
4 aarch64-linux rebuilds
First ten rebuilds by attrpath
i3pystatus
python27Packages.praw
python36Packages.praw
python36Packages.sopel

Instructions to test this update (click to expand)

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

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

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/l21xcs2a0pn5rd0fsipaff256l7h69s1-python3.6-praw-6.0.0
ls -la /nix/store/l21xcs2a0pn5rd0fsipaff256l7h69s1-python3.6-praw-6.0.0/bin

cc @jgeerds for testing.

Success on aarch64-linux (full log)
Attempted: python36Packages.praw
Partial log (click to expand)
tests/unit/models/reddit/test_modmail.py ..                              [ 93%]
tests/unit/models/reddit/test_more.py ..                                 [ 93%]
tests/unit/models/reddit/test_redditor.py ..........                     [ 95%]
tests/unit/models/reddit/test_submission.py ...........                  [ 97%]
tests/unit/models/reddit/test_subreddit.py ..........                    [ 99%]
tests/unit/models/reddit/test_wikipage.py .....                          [100%]

========================= 596 passed in 43.51 seconds ==========================
pytestcachePhase
/nix/store/y5r3kn4xfcrqi0c5sq2k7bygh5mkdrj3-python3.6-praw-6.0.0

Success on x86_64-darwin (full log)
Attempted: python36Packages.praw
Partial log (click to expand)
tests/unit/models/reddit/test_modmail.py ..                              [ 93%]
tests/unit/models/reddit/test_more.py ..                                 [ 93%]
tests/unit/models/reddit/test_redditor.py ..........                     [ 95%]
tests/unit/models/reddit/test_submission.py ...........                  [ 97%]
tests/unit/models/reddit/test_subreddit.py ..........                    [ 99%]
tests/unit/models/reddit/test_wikipage.py .....                          [100%]

========================= 596 passed in 20.27 seconds ==========================
pytestcachePhase
/nix/store/yqww1hdk5prn7f5jx6ra6hddw75w9xg4-python3.6-praw-6.0.0

Success on x86_64-linux (full log)
Attempted: python36Packages.praw
Partial log (click to expand)
tests/unit/models/reddit/test_modmail.py ..                              [ 93%]
tests/unit/models/reddit/test_more.py ..                                 [ 93%]
tests/unit/models/reddit/test_redditor.py ..........                     [ 95%]
tests/unit/models/reddit/test_submission.py ...........                  [ 97%]
tests/unit/models/reddit/test_subreddit.py ..........                    [ 99%]
tests/unit/models/reddit/test_wikipage.py .....                          [100%]

========================= 596 passed in 22.53 seconds ==========================
pytestcachePhase
/nix/store/l21xcs2a0pn5rd0fsipaff256l7h69s1-python3.6-praw-6.0.0


support only remain slash

fix #599

@swaggo/swaggo-core-team please help review it.

Codecov Report

Merging #605 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master     #605   +/-   ##
=======================================
  Coverage   85.94%   85.94%
=======================================
  Files           7        7
  Lines        1693     1693
=======================================
  Hits         1455     1455
  Misses        149      149
  Partials       89       89

Impacted Files
Coverage Δ

operation.go
90.77% <ø> (ø)
:arrow_up:

Continue to review full report at Codecov.

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

I found sometimes GitHub CI would be a CI failure. Maybe we can consider disable it until fix this problem.

I will jump to v1.6.5 after this PR merged.


How to set Authorization header in player?

How can i add Request Header like Authorization to the video request?
Can you show me?

any news?

The video request itself is made by the browser by default, for HLS it uses hls.js and for dash it uses dashjs. We have callbacks for the requests, but the video itself is loaded by the browser. Are you still having this issue?

@DoanhNV Is this still an issue or can I close the issue? Thank you!

Closing the ticket due to a lack of feedback over an extended period. Please feel free to reopen if you have further input or require additional assistance. Thank you.


ingress invalid type

dear author:
when i use ingress service , there  are some issue as below:
param: ingressRequest := &livekit.CreateIngressRequest{
InputType:           livekit.IngressInput_URL_INPUT,
Name:                "ingress_" + name,
RoomName:            room,
ParticipantIdentity: from,
ParticipantName:     from,
Url:                 url,
}
result: {"error": "twirp error invalid_argument: invalid ingress type
could u please tell me what should i do to resolve them?

dear david，
docker hub pull latest，1.2.1 and 1.1.0 ，i tried them all，cant solve the problem？  also，could u tell me how to sovle the  latency about rtmp egress and egress，now when i try to connect sip endpoint ,the latency is more then 9s,thank you!

Which version of the cli and livekit-server?


Extraneous playerclip in dm_mannworks

There is a playerclip solid that is invisible but blocks player movement in dm_mannworks. See screenshot. Coordinates 779, -67, 310

Mostly a minor annoyance, but very easy run into on accident and lose momentum.

This will be fixed in the upcoming set of Mannworks updates


Updating 'column profiling based on top 1000 rows' to column profiling based on the entire dataset in Power BI.

[The explanation on how to update 'Column Profiling based on top 1000 rows' to the entire dataset is not clear. How exactly do I make the profiling based on the entire dataset? Kindly assist thanks. https://learn.microsoft.com/en-us/power-query/data-profiling-tools]

Document Details
⚠ Do not edit this section. It is required for learn.microsoft.com ➟ GitHub issue linking.

ID: 003c71f8-2874-f664-fa87-8759f571107b
Version Independent ID: d96c778a-06ba-1ca9-4e74-45df237bd048
Content: Using the data profiling tools - Power Query
Content Source: powerquery-docs/data-profiling-tools.md
Service: powerquery
GitHub Login: @ptyx507
Microsoft Alias: miescobar

Hi @jeremiahomueti
Thanks for the feedback! The method for changing between "Column profiling based on top 1000 rows" and "Column profiling based on entire data set" has been added to the first note in Using the data profiling tools.

Cool. So I made Microsoft update its documentation. Nice :-)
Thanks for your careful attention to this matter.
Regards @DougKlopfenstein


feat(config): deprecate cache.dir option

Description

Closes #3272
This PR removes the cache.dir option and reuses Vite's cacheDir to save cache.
Related

https://github.com/vitest-dev/vitest/pull/4036

Please don't delete this checklist! Before submitting the PR, please make sure you do the following:

[x] It's really useful if your PR references an issue where it is discussed ahead of time. If the feature is substantial or introduces breaking changes without a discussion, PR might be closed.
[ ] Ideally, include a test that fails without this PR but passes with it.
[x] Please, don't make changes to pnpm-lock.yaml unless you introduce a new test example.

Tests

[ ] Run the tests with pnpm test:ci.

Documentation

[x] If you introduce new functionality, document it. You can run documentation with pnpm run docs command.

Changesets

[x] Changes in changelog are generated from PR name. Please, make sure that it explains your changes in an understandable manner. Please, prefix changeset messages with feat:, fix:, perf:, docs:, or chore:.

Deprecating is not a breaking change as long as it's still resolved.

Deprecating is not a breaking change as long as it's still resolved.

Aha...thanks for clarifying! As you said it's still resolved, do I need to handle cache.dir in resolving config? Like assigning Vite's cacheDir as cache.dir if it exists?

Deprecating is not a breaking change as long as it's still resolved.

Aha...thanks for clarifying! As you said it's still resolved, do I need to handle cache.dir in resolving config? Like assigning Vite's cacheDir as cache.dir if it exists?

Yes, I would expect cache.dir to affect the directory somehow until the option is removed completely in the next major.


Unsub can cause deadlock

Hey,
I have encountered a deadlock with the library.
Basically when a goroutine that was previously subbed stops listening (in our case when a client disconnects) and calls a defered function to unsub all. But between the time that it stops reading the channel and when it calls unsub something publish's to a channel its subscribed to (this has to publish more messages than the pubsub chan size).
The steps would be (where A and B are different goroutines and R is the registry goroutine):
A: x := ps.sub("1") // Which successfully registers
B: ps.pub("testing", "1") // This writes down registry's cmd chan
B: ps.pub("testing", "1") // This writes down registry's cmd chan - assuming buffer of 1
A: unsub(x, "1") // or unsub(x) - which writes unsub down cmd chan
R: reads the pub event
R: send("1", x) // which blocks on ch <- msg
B: ps.pub("testing1", "1") // next event to route

And we are all asleep:
A: waits for the registry to read its unsub op
B: waits for the registry to accept its pub op
R: waits for A to accept its pub.

Please keep this issue open, so people that want to use this package are aware of existing issues.

What about using 2 different command channels for messages and control?
And drain the channel in remove before closing it.


Remove .stl files after PrintJob completed

This should also include the ability to archive print Jobs for sensitive jobs


Capacitor Bank: Long term TPS drain with large multiblock sizes (probable memory leak)

Is there an existing issue for this?

[X] I did not find any existing issues.

Current Behavior
Symptom: multi-second delays on some (but not all) ticks in server, multi-second lockups in integrated-server (singleplayer), ultimately leading the tick watchdog to crash (160 seconds).
TLDR/likely cause: Memory leak in machine block entity capability caching due to adding duplicate invalidation listeners to the LazyOptional capabilities causing VM to hit memory limit, causing GC to thrash.
--
The long version of the story is that I was gradually building up a large cap bank to act as the central storage in my base. Around the time I hit the million RF/t generation (though probably not deeply relevant) my server (which is a personal server for me and my SO) began hitting extremely low TPS after several hours before ultimately hitting the tick watchdog check and crashing (160 second tick). Then when I would start the server again, it would be fine for several hours, rinse and repeat.
I did a ton of Spark and Observable profiling to try to ascertain the cause (this is in ATM9 and we're near the end game, so there was tons to check) but could not find an obvious culprit. Then during one of the TPS drain events I noticed that my cap bank entities were somewhat slower than before (probably not relevant as you'll see) and on that hunch decided to remove the capacitor bank. The issue went away and has not recurred.
The Vibrant capacitor bank was around 192 blocks large.
I raised this on the EnderIO discord and we had some conversations about potential causes. During this time I was able to reproduce the problem with a 3 * 8 * 8 multiblock after 2.5 hours in a singleplayer world using the same modpack. Since it was singleplayer, it would lock up the entire client, which was a clue, since iirc even in integrated server mode the server ticks are run on a separate thread from the client. The lock ups lasted about 4 seconds each, and happened every 4-8 seconds.
Here is the test setup at the time it was built (the left is EIO's Creative Energy block, the right is an energy trash can from the Trash Cans mod).

Here are two Sparks taken while the lockups were occurring. There isn't much to look at in the profiler view.
https://spark.lucko.me/7GlO6pfBby
https://spark.lucko.me/halqg3TAUb
In these, the most expensive tick cost was around mob ticks, but ATM9 has tons of mods that mixin to mob ticks, and the total amount of time wasn't anywhere near the length of time of each lock up.
After gathering the data, I split the multiblock in half, which immediately resolved the issue- the 4 second lock ups stopped happening almost instantly.
These do capture one pertinent fact: there was 14.1 GB of RAM in use (out of 14.3 allotted in the Java configuration), and an average GC old generation time of 4.4 seconds, which is bang on for the length of time of each lock up.

Furthermore, that explains why the entire client locked up, despite Minecraft running the server/client ticks on separate threads.
So this is actually a memory leak which eventually causes the VM to run out of allocatable memory, causing the GC to thrash looking for enough space to free up, and likely having to do a lot of compaction to enable the next allocation(s).
This explains why it took about 3-4 hours on my personal server (which has 16GB of RAM, but is not running the client portion) and took 2.5 hours on my local machine (around an equivalent VM memory limit, but has both the server and client allocations in the working set).
@Rover656 noticed that capability caching could be at fault here:

I reckon this could well be our capability caching; if each cell in this arrangement is caching its neighbours that could explain memory consumption?
...
It looks to be maybe more to do with the invalidation listener
yeah one thing that isn't being done is removal of the invalidation listener when we clear and refill the cache
that will absolutely lead to a heap of handlers just lying dormant
do that in all 6 directions of a multiblock, I imagine every tick as we recompute when neighbours change (need to check this claim by checking out 1.20.1 tomorrow) and boom you get a lot of listeners

This does make sense on reading the code, at least on the 1.20.1 branch, the updateCapabilityCaches() method of MachineBlockEntity ultimately calls addInvalidationListener() on the capabilities it finds in it's 6 cardinal directions. That method adds an invalidation listener on the LazyOptional returned by the capable block in order to mark its own cache as invalid (to be rebuilt on the next server tick). However, no effort is made to prevent adding superfluous listeners to the same LazyOptional objects- so if an ICapabilityProvider reuses the same capability object (which would be the most sensible thing to do since they are invalidate-able), EIO will just keep adding additional listeners every time the cache is marked invalidated. This would have two deleterious effects: acting as a memory leak, and also causing other mod's invalidation notifications to take longer than they need to, though that would be limited primarily to the function call itself and a single value assign (isCapabilityCacheDirty = true), so it's not too likely to be noticed, even when the amount of duplicate listeners is quite high.
The Forge API does not include a method for removing invalidation listeners, so unfortunately a simple approach such as tracking all registered listeners within the MachineBlockEntity and removing them prior to updating the cache is not possible (at least for 1.20.1).
The other alternative would be to keep a weak set of the lazy optionals that have already have listeners added and consult the set prior to adding a new one. The listener itself need not be memoized.
I'm hoping to confirm that this is indeed the issue via reproduction in an EIO-only dev environment, I'll update this issue as I learn more.
If you are interested in the full Discord discussion, you can find it here: https://discord.com/channels/373534853259329536/373534853259329538/1249677198537789471
Expected Behavior
Not leading to OOM / GC thrashing.
How to Test
Should be repeatable by:

Making a sufficiently large vibrant capacitor bank (for my testing I used 192 (3 x 8 x 8))
Adding an EIO creative energy block to pump in energy
Adding a reasonable "load" (for my testing I used the Energy Trash Can from the Trash Cans mod with unlimited speed).
Watch memory usage climb until GC thrashing occurs.
Once client / server is locking up, break the capacitor bank to reduce it's size. I caught mine roughly in half. I did happen to cut through it in a way that one of the two resulting multiblocks then had the energy source, and the other one had the energy load.
The GC thrashing stops

Local Environment
- **Operating System**: Replicated on Linux and Windows
- **Java version**: 17.0.8
- **Minecraft Version**: 1.20.1, forge-47.2.20
- **Version**: EnderIO 1.20.1-6.0.25-alpha
- **Other Mods**: ATM9-0.2.58 without any customizations

Any Additional Information?
No response

I've done a bit of testing and there's a bigger issue at play: MachineBlocks delete capability caches every time an adjacent block is updated, and machines force update themselves the moment their energy changes. Adding a cache for invalidations does at least slow down the leak, but only if you never clear it.


Inner Source Maturity Model?

All,
I wanted to ask if anyone has developed or come across an inner source maturity model.
Specifically I am looking for something that could be used to evaluate internal projects across multiple relevant dimensions to assess the degree to which a project is already demonstrating attributes and capabilities needed to effectively "do inner source" (perhaps w/o the project team even having known what inner source is -- e.g., perhaps they already work to a "public" roadmap within the 4 walls of their organization.)
I was thinking (and might argue that) these dimensions might be similar to those that @mindthegab, @copiesofcopies, @pmonks and I used a few years back to build the FINOS board report and health check rubric, but perhaps not.
Again, use of the model would be the assess projects inner source readiness across 6-8 dimensions, and an associated rubric.
Thanks,
Rob
rob(at)ttmadvisors(dot)com

Hey @brooklynrob that's a really great question. I personally haven't seen anything in my experience personally. Perhaps this would be a great project for this SIG to work on? We could pool our varied experiences and see if we can create a common maturity model. The model should provide a baseline and guide organizations to build on it for their own use cases.
That rubric might be a good scaffold to build on, but I think we'd need to tailor it. Ideally we have levels of maturity that are encouraging at any level, I wouldn't want organizations to feel they have to be at the highest maturity level and feel discouraged when it's challenging to get there. Adoption could be encouraged by having organizations share what level some of their products are at. It'd also provide us insights where the SIG could focus on.
Anywho, love the idea!

There are a few InnerSource maturity models out there.
This one for example:
https://github.com/InnerSourceCommons/InnerSourcePatterns/blob/a9e136eb57fd927c12ee27827e35cd7215226e53/patterns/2-structured/maturity-model.md

Thanks so much @Ludmila-N 🚀
The InnerSource SIG is meeting Wednesday, 14 April 2021 - 10am EST / 3pm UK if you would like to comment on the agenda below and join the call as I'm sure this issue will be raised?
https://github.com/finos/InnerSource/issues/10
cc @finos/innersource-maintainers

There are a few InnerSource maturity models out there.
This one for example:
https://github.com/InnerSourceCommons/InnerSourcePatterns/blob/a9e136eb57fd927c12ee27827e35cd7215226e53/patterns/2-structured/maturity-model.md

Thank you for sharing these! Perhaps it would be useful for us to try pilot this (or another maturity model) with our inner source communities within our organisations. By doing this we can provide feedback on the pattern as well as a 'guide' / tips on how others can do the same.
Just a thought.

Hey @daniela-g-zheleva-db - What are your thoughts on making this issue the first InnerSource GitHub Discussion. Maybe this could be raised in the InnerSource SIG meeting https://github.com/finos/InnerSource/issues/11 ..? 🤔


Project files browser progress

Old/inaccurate dialog shows when adding new files.

No Files in project
Added val resume
Clicked add new file
Dialog shows with old data and 2/2 (not sure where the 2 came from)

Since we are converting images on upload/import there are now two steps involved: transformation to .webp, then coping to the location.
The first step (1/2) always displays a progress bar of 50% as the lib being used does not have progress events.
The second step (2/2) is moving the optimized image to the save location. This does give out progress (which you can see in the dev tools console logs), but the files are typically quite small and the move happens so quickly that you don't see the progress bar grow.

@thomsong does the comment above resolve this issue?

It explains the 1/2 and 2/2, but it doesn't explain why it shows up again with old info when you select a second file to add.


Inventory not showing tooltips

Whenever I add NEI the tooltips stop working in my inventory (so when you hover over items in your inventory it doesn't show the pop up telling you what they are). I checked all the configs and couldn't find any settings to change to correct the issue.
CodeChickenCore <IP_ADDRESS>
CodeChickenLib <IP_ADDRESS>
NEI <IP_ADDRESS>
JEI <IP_ADDRESS>

Known issue, working on it.


cadeau token

Please note: This repository is being rebuilt to accept the new volume of token additions and modifications. PR merges will be delayed.

I agree to not ping anybody on Discord/Twitter/email about this pull request. Instead I will inquire by posting a new comment in the pull request if needed.

PRs are reviewed in bulk and and can take up to two weeks to be merged.
This repository is managed using an auto merge action. Please ensure your PR has no deleted lines, and it will be merged.
Please provide the following information for your token.
Please include change to the src/tokens/solana.tokenlist.json file in the PR.
DON'T modify any other token on the list.
At minimum each entry should have

Token Address:
Token Name:
Token Symbol:
Logo: (logo should be uploaded under assets/mainnet//*.<png/svg>)
Link to the official homepage of token:
Coingecko ID if available (https://www.coingecko.com/api/documentations/v3#/coins/get_coins__id_):

Auto merge requirements
Your pull request will be automatically merged if the following conditions are met:

Your pull request only adds new tokens to the list. Any modification to existing
tokens will require manual review to prevent unwanted modifications.

Your pull request does not touch unrelated code. In particular, reformatting changes to unrelated
code will cause the auto merge to reject your PR.

Any asset files added correspond to the token address you are adding. Asset files
must be PNG, JPG or SVG files.

Your change is valid JSON and conforms to the schema. If your change failed validation,
read the error message carefully and update your PR accordingly.

No other tokens shares the same name, symbol or address.

For example, this change would be rejected due to unrelated changes:

The bot runs every 60 minutes and bulk-merges all open pull requests to prevent conflicts.
This means that you need to wait up to 60 minutes for your pull request to be merged or reprocessed.

Great functionality, works perfect.
I did my FIRST SOLANA TOKEN, incuding TOKEN NAME and LOGO
token: Dj9PmgbVBCpaqmwqrgq8LxFusHJr4QEmUuSRDRh3x4mS
WHO CAN HELP ME: I don't know how to create the SECOND TOKEN??? Do not understand the steps to take. Do I have to FORK again???
Please I would appreciate your support SO MUCH
Best regards,
Jan


Recorded Future Sandbox Connector

When submitting a connector, please make sure that you follow the requirements below, otherwise your PR might be rejected. We want to make you have a well-built connector, a smooth certification experience, and your users are happy :)
If this is your first time submitting to GitHub and you need some help, please sign up for this session.

[ ] I attest that the connector doesn't exist on the Power Platform today. I've verified by checking the pull requests in GitHub and by searching for the connector on the platform or in the documentation.
[ ] I attest that the connector works and I verified by deploying and testing all the operations.
[ ] I attest that I have added detailed descriptions for all operations and parameters in the swagger file.
[ ] I attest that I have added response schemas to my actions, unless the response schema is dynamic.
[ ] I validated the swagger file, apiDefinition.swagger.json, by running paconn validate command.
[ ] If this is a certified connector, I confirm that apiProperties.json has a valid brand color and doesn't use an invalid brand color, #007ee5 or #ffffff. If this is an independent publisher connector, I confirm that I am not submitting a connector icon.

If you are an Independent Publisher, you must also attest to the following to ensure a smooth publishing process:

[ ] I have named this PR after the pattern of "Connector Name (Independent Publisher)" ex: HubSpot Marketing (Independent Publisher)
[ ] Within this PR markdown file, I have pasted screenshots that show: 3 unique operations (actions/triggers) working within a Flow. This can be in one flow or part of multiple flows. For each one of those flows, I have pasted in screenshots of the Flow succeeding.
[ ] Within this PR markdown file, I have pasted in a screenshot from the Test operations section within the Custom Connector UI.
[ ] If the connector uses OAuth, I have provided detailed steps on how to create an app in the readme.md.

@microsoft-github-policy-service agree [company="Recorded Future"]

@microsoft-github-policy-service agree company="Recorded Future"

Hello @lindarecfut,
Thank you so much for submitting your new connector artifacts.
As we ask all Verified Partner to register their connectors, may I ask you please to register your connector by filling out our registration form.
Please let me know if you have any questions.
Thank you so much again.

Thank you @Amjed-Ayoub. Since it is an update of an existing connector my colleague @johannesh-recordedfuture updated the connector in his ISV Studio environment. Do you know a way how we all can be connected to the same group in ISV?

Hello @lindarecfut thank you so much for reaching out. I have sent you an email regarding this. Thank you.


Add support for AdapterPlus

This PR aims to add support for AdapterPlus
Github: https://github.com/visinf/adapter_plus
Paper: https://arxiv.org/pdf/2406.06820
Integration of AdapterPlus into the adapters library will involve adding new parameters/options to the BnConfig
Checklist of things that are added/to be added

New type of scaling called channel, in which we add learnable parameters for the channel/input_size dimension
New type of init_weights called houlsby, where the projection matrices $W_{down}$ and $W_{up}$ will be initialized with zero-centered Gaussian with a standard deviation of $10^{-2}$ truncated at 2 standard deviations, and zeros for bias
Support for drop_path, also known as stochastic depth ONLY applicable for vision based tasks using residual networks - located under a new file called /methods/vision.py

@calpt It looks like there is a missing torchvision import error happening in the CI. Is the CI configured to install the package? I don't see it inside as a core dependency in setup.py but not exactly sure if that is the correct place to look.

@calpt It looks like there is a missing torchvision import error happening in the CI. Is the CI configured to install the package? I don't see it inside as a core dependency in setup.py but not exactly sure if that is the correct place to look.

you're right, it's not currently installed in CI. we could add it as optional dependency in setup.py, similar to what HF does here: https://github.com/huggingface/transformers/blob/405b56269812056d9593869e22b7b264d806cb1e/setup.py#L312 and then install that additional dep package here https://github.com/adapter-hub/adapters/blob/bcace97bd3fb0db821780d4c2bcd087fbf200386/.github/workflows/tests_torch.yml#L66

@calpt It looks like there is a missing torchvision import error happening in the CI. Is the CI configured to install the package? I don't see it inside as a core dependency in setup.py but not exactly sure if that is the correct place to look.

you're right, it's not currently installed in CI. we could add it as optional dependency in setup.py, similar to what HF does here: https://github.com/huggingface/transformers/blob/405b56269812056d9593869e22b7b264d806cb1e/setup.py#L312 and then install that additional dep package here
https://github.com/adapter-hub/adapters/blob/bcace97bd3fb0db821780d4c2bcd087fbf200386/.github/workflows/tests_torch.yml#L66

Would you like that in a separate pr? I know other open-source libraries prefer another pr to differentiate scopes of pull requests

@calpt It looks like there is a missing torchvision import error happening in the CI. Is the CI configured to install the package? I don't see it inside as a core dependency in setup.py but not exactly sure if that is the correct place to look.

you're right, it's not currently installed in CI. we could add it as optional dependency in setup.py, similar to what HF does here: https://github.com/huggingface/transformers/blob/405b56269812056d9593869e22b7b264d806cb1e/setup.py#L312 and then install that additional dep package here
https://github.com/adapter-hub/adapters/blob/bcace97bd3fb0db821780d4c2bcd087fbf200386/.github/workflows/tests_torch.yml#L66

Please correct me if I'm wrong, but wouldn't torchvision need to be included as a core dependency since (and maybe there is an alternative that avoids this) we're importing the torchvision stochactic_depth function in methods/modeling.py? Users will be missing the library for that import whenever the file is being used if they install adapters straight up.
Thats sort of why I originally wrote the native implementation in the library so that we don't need to include any new core dependencies.

@calpt It looks like there is a missing torchvision import error happening in the CI. Is the CI configured to install the package? I don't see it inside as a core dependency in setup.py but not exactly sure if that is the correct place to look.

you're right, it's not currently installed in CI. we could add it as optional dependency in setup.py, similar to what HF does here: https://github.com/huggingface/transformers/blob/405b56269812056d9593869e22b7b264d806cb1e/setup.py#L312 and then install that additional dep package here
https://github.com/adapter-hub/adapters/blob/bcace97bd3fb0db821780d4c2bcd087fbf200386/.github/workflows/tests_torch.yml#L66

Would you like that in a separate pr? I know other open-source libraries prefer another pr to differentiate scopes of pull requests, so just wondering what your preference is

fine to include here since this is directly related to the new functionality implemented in this pr

@calpt It looks like there is a missing torchvision import error happening in the CI. Is the CI configured to install the package? I don't see it inside as a core dependency in setup.py but not exactly sure if that is the correct place to look.

you're right, it's not currently installed in CI. we could add it as optional dependency in setup.py, similar to what HF does here: https://github.com/huggingface/transformers/blob/405b56269812056d9593869e22b7b264d806cb1e/setup.py#L312 and then install that additional dep package here
https://github.com/adapter-hub/adapters/blob/bcace97bd3fb0db821780d4c2bcd087fbf200386/.github/workflows/tests_torch.yml#L66

Please correct me if I'm wrong, but wouldn't torchvision need to be included as a core dependency since (and maybe there is an alternative that avoids this) we're importing the torchvision stochactic_depth function in methods/modeling.py? Users will be missing the library for that import whenever the file is being used if they install adapters straight up.
Thats sort of why I originally wrote the native implementation in the library so that we don't need to include any new core dependencies for timm or torchvision.

that's a good point. I think what we can do is to make the import of torchvision conditional on the package being available. this is pretty standard practice across Transformers and they have helper methods for checking all sorts of packages, including torchvision: https://github.com/huggingface/transformers/blob/33868a057c02f0368ba63bd1edb746be38fe3d90/src/transformers/utils/import_utils.py#L361
If torchvision is not installed & stochastic_depth is used, we should thrown an exception, otherwise we don't care whether it's installed. This keeps it optional for all non-vision use cases.

looks good to me overall, thanks a lot for working on this! can be merged from my side once all checks are passing

I have fixed the code quality issues - thanks!


Package Update - loopback4-ratelimiter

Describe the bug
remove all current vulnerability present in loopback4-ratelimiter
To Reproduce
Steps to reproduce the behavior:

Go to '...'
Click on '....'
Scroll down to '....'
See error

Expected behavior
A clear and concise description of what you expected to happen.
Screenshots
If applicable, add screenshots to help explain your problem.
Additional context
Add any other context about the problem here.

:tada: This issue has been resolved in version 4.2.1 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


Comprehensive Unity Tutorial uses C# module instead of rust

This is being worked on currently by @SteveBoytsun. We are going to be implementing this:
https://docs.google.com/document/d/1VA3ZO-QsoDimr_PIVGPZsWWD4eU9tYabgZa4Gr9ZnA0/edit?tab=t.0


Watch mode not working in 2.2.0-rc.0

Do you want to request a feature or report a bug?
bug
What is the current behavior?
Watch mode is not able to recover after an error in a file (at least for JSX errors).
If the current behavior is a bug, please provide the steps to reproduce.
See simple example application of how to reproduce it here https://github.com/skovhus/webpack-2-slowness/tree/watch-mode
What is the expected behavior?
Watch mode should work, i.e. rebuild the file after the error in the source code is fixed.
Please mention other relevant information such as the browser version, Node.js version, Operating System and programming language.

OS: Max OS X 10.10.5
Node: v7.0.0
Yarn: 0.17.9
Webpack: 2.2.0-rc.0

Two questions:

Was this working in the latest 2.1.0 beta?
Could you try if this does work in Node v6? There are some weird issues with watching Node v7.

Was this working in the latest 2.1.0 beta?

Yes. It work in<EMAIL_ADDRESS>

Could you try if this does work in Node v6? There are some weird issues with watching Node v7.

Watch mode for 2.2.0-rc.0 doesn't work in node v6.9.2

Okay, thanks, that helps narrowing down the issue. Possibly #3479 has caused this.

@SpaceK33z I can try reverting https://github.com/webpack/webpack/pull/3479/files locally and see if it solves it.

Setting cache to false did the trick - but that's far from ideal, I think.

@skovhus yes please!

Okay, thanks, that helps narrowing down the issue. Possibly #3479 has caused this.

I can confirm  #3479 is not the cause.

Might be some of the caching/performance fixes in https://github.com/webpack/webpack/pull/3428
Although those helped with speed, it might have killed watch mode.
https://github.com/webpack/webpack/issues/3480

It's not just the watch mode.
HMR is not working properly when an error is spawned.

I've got a fix. But writting a test case is difficult...

@sokra ETA for pushing the fix to a new release?

today


Added '3D Image Gallery' component

What is the change?

Added a new component inside the 'Image-Gallery' folder.

Related issue?
closes: #368
How was it tested?
Remove this line and tell us how the code was tested.
Checklist:
Before you create this PR, confirm all the requirements listed below by checking the checkboxes [x]:

[x] Have you followed the Contribution Guidelineswhile contributing.
[x] Have you checked there aren't other open Pull Requests for the same update/change?
[x] Have you made corresponding changes to the documentation?
[x] Have you tested the code before submission?
[x] Have you formatted your code ? (You can use any html,css beautifier)
[x] My changes generates no new warnings.
[x] I'm Diversion2k23 contributor.
[x] I have commented my code, particularly in hard-to-understand areas.

GIF/video of the working of component you created:
Add here the GIF you created.
Demo Video:
https://user-images.githubusercontent.com/92919173/217323992-8d253758-cba3-4529-881c-ce62c1bcbae7.mp4

It's showing 'This branch has conflicts that must be resolved' in the end but I don't have the write access so can you resolve the conflicts(probably cuz of bug fix commit ig) and merge this file?


[Cypress12] Ensure cypress functional tests run with Cypress12

The opensearch-dashboards-functional-test repo is working on upgrading the version of Cypress used in the repo from v9 to v12.
There is a feature branch in the repository called feature/cypress12 to work on the upgrade and ensure that all repositories that have functional tests in the repo can verify that their tests run successfully with the upgraded version of cypress. If any updates to tests are required please submit a PR against the function test repo and base the PR on the feature/cypress12 branch to show the tests running with the upgraded version of Cypress.
Please refer to the migration guide from Cypress to reference when updating tests.
If no work is required to update the tests then please close this issue and indicate that no update is required.

[Triage -- attendees 1, 2, 3, 4, 5, 6, 7]


Prebuilt unbound-exporter binary

Hello,
Do you have the rebuilt unbound-exporter binary for amd64?

Hello,
I uploaded the linux-amd64 unbound-exporter binary under link:
https://github.com/ar51an/unbound-exporter/blob/main/bin/amd64/
Let me know if you face any issues.

Firstly,
Thanks a lot.
I've changed some configurations to fit to my environment and it's working perfectly.


Title case is not really title case!

I wanted to have my headings in my blog with the correct title case. I assumed this plugin would to this with the case: title. But for example with the heading "Developing A Software Renderer" the a becomes big while it actually should be a small a. This is not proper title case.
Compare with this: https://saijogeorge.com/title-case-converter/

@trenki2 I think this bug should be reported upstream, in https://github.com/blakeembrey/change-case.

@waldyrious that may not help. The author has no interest in implementing proper title case, see https://github.com/blakeembrey/title-case/pull/12#issuecomment-377909941.
What about using https://github.com/zeit/title?

I believe this plugin targets mostly programming needs.
What you ask is totally dependent on natural language, it seems you ask that only for English, which is a bit narrow (although in French, we don't use title case at all, at least not for story titles).


Update manifest-sources-for-serverless-lambda.md

Please check the Execution Link of the Pipeline for the Website Draft URL. This is located in the Preview Step behind the Harness VPN and also is available in #hdh_alerts. E.g Website Draft URL: https://unique-id--harness-developer.netlify.app. Current Draft URL is: https://661eac7199b25346f5ea6959--harness-developer.netlify.app

Please check the Execution Link of the Pipeline for the Website Draft URL. This is located in the Preview Step behind the Harness VPN and also is available in #hdh_alerts. E.g Website Draft URL: https://unique-id--harness-developer.netlify.app. Current Draft URL is: https://661f6d3b6992496ff3dc6ede--harness-developer.netlify.app

Please check the Execution Link of the Pipeline for the Website Draft URL. This is located in the Preview Step behind the Harness VPN and also is available in #hdh_alerts. E.g Website Draft URL: https://unique-id--harness-developer.netlify.app. Current Draft URL is: https://661f7fda763d89f6b17ec908--harness-developer.netlify.app


Allow specifying JSON schema for chat completions

Q
A

Bug fix?
no

New feature?
yes

BC breaks?
no

Related Issue
Fix #397

Describe your change
Allow specifying JSON schema for chat completions. See the added unit test (jsonSchema in TestChatCompletions) for a simple example of how to use.
Note: This feature is only available for models 4o and later.
What problem is this fixing?
OpenAI's API supports specifying JSON schema for recent models. This library does not currently allow the user to specify this, and now it will.
One benefit is that (as can be seen in the added unit test), you do not have to specify the schema in the messages themselves now.

This looks fantastic - @aallam Any reason not to merge & release this highly anticipated feature?

LGTM! thanks a lot for your contribution!

@aallam, would you mind pushing these changes into the 4.0 beta?


[TASK] Put CSV body and parameters into CsvInspectionRequest

Currently it uses query parameters for parameters and body for CSV payload, unlike other formats. Align CSV to put everything into CsvInspectionRequest JSON. Don't forget to change the contentType at backend side from text/csv to JSON.

It's OK to separate the parameters from CSV payload, but need to put under CsvInspectionRequest as opposed to the individual URL parameters currently we do. So send a single JSON body just like this without any URL parameters:
https://github.com/atlasmap/atlasmap/blob/main/lib/modules/json/model/src/main/java/io/atlasmap/json/v2/JsonInspectionRequest.java#L34-L46
https://github.com/atlasmap/atlasmap/blob/main/lib/modules/json/service/src/main/java/io/atlasmap/json/service/JsonService.java#L112
while for CSV the parameters are URL parameters not wrapped in a JSON request object - sending multiple parameters and a CSV body together in a POST request
https://github.com/atlasmap/atlasmap/blob/main/lib/modules/csv/service/src/main/java/io/atlasmap/csv/service/CsvService.java#L117

The thing I'm talking about is https://github.com/atlasmap/atlasmap/blob/main/lib/modules/json/service/src/main/java/io/atlasmap/json/service/JsonService.java#L113 which makes us parse the whole payload to extract parameters and body with json parser i.e. read the whole payload. On the other hand when you pass a CSV in body and parameters as URL params then I simply read URL params and just the first line of CSV from the body and I'm done.
Are you saying to move the logic to javascript and get just the first line in js and send it for inspection?

Ah OK maybe not feasible to stream JSON payload. And yes, take the header at UI side and discard the rest is the option. But... no we don't want to think about the line breaks and etc at UI side...
This sounds like a wider spread problem, actually it's same for JSON/XML instance inspection. And even if it managed to perform inspection, the huge instance file will be stored into the DataSourceMetadata contained in .adm file so it makes .adm file bigger.
That said, I would say, don't upload a real huge file for the inspection, that's just an example to inspect...

Yeah, in case of CSV it's simple for the end user to crop the file. In case of JSON/XML instance it might not be that easy so I would actually move towards the approach I used for CSV, i.e. have the file in body and any parameters as URL parameters. That said we are not yet parsing JSON/XML instances/schemas as streams so we would not benefit until it is re-implemented.

Yeah ATM it's too far before doing it - at least runtime should support huge file with streaming, and then .adm file has to be restructured to store inspection result and discard inspection source so that the repeating element could be thrown away when it's stored in datasource metadata, etc.
Anyway, this issue is not worth doing with that direction, hopefully the parameters won't change much anymore as it changes REST interface everytime. Closing.


[AVM Module Issue]: nat-gateway claims missing PIP when called in a module multiple times

Check for previous/existing GitHub issues

[X] I have checked for previous/existing GitHub issues

Issue Type?
Bug
Module Name
avm/res/network/nat-gateway
(Optional) Module Name if not listed above
No response
(Optional) Module Version
1.0.4
Description
👋 I came across this when playing around with Hub Spokes configurations. I could isolate the issue and it is reproducible here.
Isolated scenario:

Want to create a PIP and a NAT Gateway for several regions
Created a bicep module using avm-nat-gateway module
Call the custom module for two regions (sweden, poland) from main bicep file

Error:

There is a race condition as well, depending on wether poland or sweden nat deployment finishes first, the other nat gateway fails claiming that it can't find the PIP for the other region
Checking deployment logs, the input parameters are correct sweden PIP for sweden NAT and poland PIP for poland NAT

/subscriptions//resourceGroups/rg-avm-nat-gateway-bug/providers/Microsoft.Resources/deployments/pvk5ah5axffra-nat-poland","message":"At least one resource deployment operation failed. Please list deployment operations for details. Please see https://aka.ms/arm-deployment-operations for usage details.","details":[{"code":"NotFound","message":"Resource /subscriptions//resourceGroups/RG-AVM-NAT-GATEWAY-BUG/providers/Microsoft.Network/publicIPAddresses/PIP-NAT-SWEDEN not found.

That is why I assume it could be some bug within the nat-gateway module when resolving the PIP input parameters.
Thanks for having a look ❤

(Optional) Correlation Id
c9afebf5-59e5-4368-a3cd-a9e787145bf3

Hey @fabmas, please take a look as soon as you can to sort this it if we can reproduce the behavior.
@h2floh thanks for raising the issue (:

@h2floh can you consider the following workaround in the main.bicep file?
module hubSpokePoland './hubSpoke.bicep' = {
dependsOn: [
hubSpokeSweden
]

Hey @fabmas completely missed to try that out 🤦 I'll check if it will work but I guess you already verified that it does. Thanks for checking in. Can you share some details on why that is, I didn't had time to drill into the code.

Hello, @h2floh! The issue stemmed from the formattedPublicIpResourceIds module, which lacked a unique deployment name. I’ve created a Pull Request to address this issue. Thank you once again for identifying it

Thanks @fabmas and @AlexanderSehr !


How to put the input in edit mode without clicking on the input or the edit button

There is a button on the page that the user clicks to create a new edit text element
I want a new edit text element to be created when the user clicks on the button and the edit text element will be  on edit mode automatically

Hi,
I don't quite understand what you are asking for.
It would be helpful to have some screenshots to support your description.
Otherwise, please feel free to fork the repo, raise a PR and i'll be happy to review.


SpeechLM: How to resample phonemes' frame rate from 30ms to 20ms?

Hi, thank you for your great work.
According to the appendix of paper, it uses a kaldi model to convert audio into phonemes. I have trained a kaldi model with frame rate of 30ms.
To generate the SpeechLM Base label (10ms), I just repeat each phoneme 3 times, it works fine.
But the SpeechLM Large label (20ms) cannot be generated simply by repeat phonemes. Could you provide some details about this convertion?

Actually, The frame rate of the model is 20ms for both the base and the large models (determined by the CNN module). When you feed 10ms labels and set model.label_rate=100, the code will automatically adjust(downsample) them to 20ms. So it is equal to either set model.label_rate=100 with 10ms labels, or to set model.label_rate=50 with 20ms labels.
As for the 30ms labels, since the label_rate is an integer, you can 1) repeat phonemes 3 times and set model.label_rate=100, or 2) repeat phonemes 3 times then downsample them 2 times manually and set model.label_rate=50. The above two options should work for both base and large models.  We use the second choice in our large model since it would require smaller files.
Hope the above information could help you.

That's very helpful, thank you 😊

You are welcome.


Avoid css compression

This PR removes css compression in templates/base.html
For more details on the reson behind this PR see: #426

This will be irrelevant becase we are removing all templetes related to CRM soon.


feat(clerk-js): Add dev mode notice to components

Description
Add a development mode notice to our components to avoid going to productions with dev keys by accident.

Checklist

[x] npm test runs as expected.
[x] npm run build runs as expected.
[ ] (If applicable) JSDoc comments have been added or updated for any package exports
[ ] (If applicable) Documentation has been updated

Type of change

[ ] 🐛 Bug fix
[x] 🌟 New feature
[ ] 🔨 Breaking change
[ ] 📖 Refactoring / dependency upgrade / documentation
[ ] other:

!preview

Hey @octoper, your preview is currently deploying and should be available shortly.

Status
Preview
Updated (UTC)

:cook: Deploying...
Inspect
Aug 01, 2024 08:54 AM

!preview

!snapshot

Hey @octoper - the snapshot version command generated the following package versions:

Package
Version

@clerk/astro
1.0.5-snapshot.v741fdbd

@clerk/backend
1.5.0-snapshot.v741fdbd

@clerk/chrome-extension
1.1.8-snapshot.v741fdbd

@clerk/clerk-js
5.11.0-snapshot.v741fdbd

@clerk/elements
0.11.0-snapshot.v741fdbd

@clerk/clerk-expo
2.0.1-snapshot.v741fdbd

@clerk/express
0.0.22-snapshot.v741fdbd

@clerk/fastify
1.0.24-snapshot.v741fdbd

gatsby-plugin-clerk
5.0.0-beta.45

@clerk/localizations
2.5.3-snapshot.v741fdbd

@clerk/nextjs
5.2.9-snapshot.v741fdbd

@clerk/clerk-react
5.3.0-snapshot.v741fdbd

@clerk/remix
4.2.8-snapshot.v741fdbd

@clerk/clerk-sdk-node
5.0.21-snapshot.v741fdbd

@clerk/shared
2.4.2-snapshot.v741fdbd

@clerk/tanstack-start
0.1.12-snapshot.v741fdbd

@clerk/testing
1.2.4-snapshot.v741fdbd

@clerk/themes
2.1.15-snapshot.v741fdbd

@clerk/types
4.10.0-snapshot.v741fdbd

Tip: Use the snippet copy button below to quickly install the required packages.
@clerk/astro
npm i<EMAIL_ADDRESS>--save-exact

@clerk/backend
npm i<EMAIL_ADDRESS>--save-exact

@clerk/chrome-extension
npm i<EMAIL_ADDRESS>--save-exact

@clerk/clerk-js
npm i<EMAIL_ADDRESS>--save-exact

@clerk/elements
npm i<EMAIL_ADDRESS>--save-exact

@clerk/clerk-expo
npm i<EMAIL_ADDRESS>--save-exact

@clerk/express
npm i<EMAIL_ADDRESS>--save-exact

@clerk/fastify
npm i<EMAIL_ADDRESS>--save-exact

gatsby-plugin-clerk
npm i<EMAIL_ADDRESS>--save-exact

@clerk/localizations
npm i<EMAIL_ADDRESS>--save-exact

@clerk/nextjs
npm i<EMAIL_ADDRESS>--save-exact

@clerk/clerk-react
npm i<EMAIL_ADDRESS>--save-exact

@clerk/remix
npm i<EMAIL_ADDRESS>--save-exact

@clerk/clerk-sdk-node
npm i<EMAIL_ADDRESS>--save-exact

@clerk/shared
npm i<EMAIL_ADDRESS>--save-exact

@clerk/tanstack-start
npm i<EMAIL_ADDRESS>--save-exact

@clerk/testing
npm i<EMAIL_ADDRESS>--save-exact

@clerk/themes
npm i<EMAIL_ADDRESS>--save-exact

@clerk/types
npm i<EMAIL_ADDRESS>--save-exact


Better folder navigation with long lists and hierarchies

Checklist

[X] I have used the search function to see if someone else has already submitted the same feature request.
[X] I will describe the problem with as much detail as possible.
[X] This issue only contains a request for one single feature, not multiple (related) features.

App version
8.0
Problem you are trying to solve
I like to organise my mail into a large set of IMAP folders, and use nested folders to group them. This works very nicely in many clients, including Thunderbird for desktop, where I can collapse sections of the tree for easier navigation.
K-9 Mail has never supported the nesting explicitly, but shows each folder separately as "Foo/Bar", meaning more scrolling.
The new folder navigation in 8.0 makes this much, much worse, because of the increased padding around the names.
On my Nokia 5.4 (a reasonably standard sized screen), there is room for 14 items at the new spacing; 3 of these are fixed (the account header, "Manage folders", and "Hide accounts"); the first screen is almost entirely taken up by default IMAP folders, then I have to scroll to see at most 11 folders at a time.
Suggested solution
Firstly, some options for the padding:

Reduce the default padding; space is at a premium on small screens.
Add a "Density" setting for the Folder List, similar to the one for the Message List.
Automatically adjust padding based on number of folders.

In addition:

Show nested folders as a tree / accordion. For instance, a + / - button or rotating arrow to the right of a folder name could show/hide all folders nested inside it.
Ideally, the state should be remembered when closing and opening the app, so that rarely viewed sections could be collapsed and opened only when needed.

Screenshots / Drawings / Technical details
No response

Note that this was also raised on the K-9 forum here: https://forum.k9mail.app/t/compact-folder-list/10701
It would be helpful if a member of the development team replies there, linking to this issue if you agree it is something you can look into

This issue seems related to #630 or duplicated, but your description is much more detailed and can be helpful for doing that.

what would really help is searching the list.  when i want to move a message and have a lot of folders, lack of search makes the process painful

@pcause: This issue is about navigating folders, not about filtering the list of folders when moving a message. That is already possible. Tap the toolbar icon with the three horizontal lines getting narrower towards the bottom.
(I'm going to hide these comments because they're off-topic for the original issue)


getConnection method from PgConnection does not use configuration

Context: https://github.com/CartoDB/Windshaft-cartodb/blob/567928a7f50befe44e2bd063018e518eb5edf84c/lib/cartodb/backends/pg_connection.js#L111
The getConnection method should use the configuration to set, among other options, the max number of connections.

Looking into the current configuration params (in addition to connection params), we have:
"extent":"xxxx",
"row_limit":xxxx,
"persist_connection":true/false,
"simplify_geometries":true/false,
"use_overviews":true/false,
"max_size":xxxx

and the PSQL could receive (in addition to connection params):
 * @param {Object} poolParams
 * - size
 * - idleTimeout
 * - reapInterval
 * @param {Object} options
 * - {Number} maxRowSize The max number of bytes for a row, when exceeded the query will throw an error.

So, we can set the size (Max database connections in the pool). And it seems, no one more

Branch created. We must do an intensive acceptance, similar to a load benchmark in order to ensure the right behavior due to the increment of the pool size

That postgres attribute refers to Mapnik's PostGIS datasource. The Mapnik's PostGIS datasource use a different pool from the one we use —through node-postgres— for other PostgreSQL queries.
I would not use that pool size for node-postgres.
The ideal solution

Create a new general configuration entry for PostgreSQL pool.
Move "postgres" attributes inside Mapnik's renderer configuration to make it clear where that belongs.

Unify PostgreSQL pool configurations
Apart from that, we could do some clean-up in the configuration. Right now, we define the pool configuration for different components, e.g. the MVT renderer.
We should unify that, so in our production environment, it's possible to have the same configuration for all components.
Why?
The node-postgres version we use, v6.1.x, manages internally a multi-pool, creating different pools for each different configuration object. That's very nice because it abstracts you from handling the pools, however, that means that if you throw a different combination of configuration values for the same user —let's say same database host and user, size set to 16, but different reapInterval— you will end with two different pools for a total of 2*16 connections, which is far from ideal.
That's why having just one source for the PostgreSQL pool configuration is so important. As important as having just one version of node-postgres in your environment, to avoid multiple pools for the same database/user.
Hope that helps.

Thank you very much @rochoa And of course, your comment helps me a lot, increasing my knowledge of the current state and defining an objective

VAMOS! 💪

I'm taking care of this issue since I'm in RT and @oleurud is working on copyfrom/copyto feature.
A couple of notes to take into account:

In Windhaft-cartodb we create psql clients always w/o passing poolParams argument. Indeed, we pass conString as connection config which is used to create the key for the pool object (note that it just uses username, password, database,  dbhost and  dbport). For the same user connection params we use the default pool configuration through pg.defaults with 16 connections per pool. So the poolSize param never is used to compose the poolName.

However, in Windshaft we create psql clients with default pool params for attributes backend and custom pool params for the brand new postgis-mvt renderer. As postgis-mvt renderer is not being used in production yet, we can say that we are safe... for now. We are safe because the pool-params that we pass as the second argument in node-cartodb-psql overrides the pg's defaults which is a singleton and after that, we will use a different pool-params configuration for incoming requests.

On the other hand, as we can see in global.settings.environment.postgres there is a comment that claims that it's a config for mapnik datasource. But taking a deeper look into it, we only use some properties (user, password, host and port) as default parameters to create a user or public user connections mainly.

Regarding the pool parameters that we defined for different renderers (mapnik, mvt, geojson and torque). We use them for mapnik, mvt and http but we missed to pass the configuration for torque renderer. We didn't notice because it uses the internal cartodb-psql value for poolSize which is 16.

Regarding the poolSize value for mapnik renderer is 8 for the production environment. This parameter could be misleading because it's going to be used by tilelive-mapnik as the number of maximum number of loaded maps at the very same time. Then, mapnik has an internal pool for Postgres connections with a maximum value of 10 (by default).

In Windhaft-cartodb we create psql clients always w/o passing poolParams argument. Indeed, we pass conString as connection config which is used to create the key for the pool object (note that it just uses username, password, database,  dbhost and  dbport). For the same user connection params we use the default pool configuration through pg.defaults with 16 connections per pool. So the poolSize param never is used to compose the poolName.

But we could use the connection object.

However, in Windshaft we create psql clients with default pool params for attributes backend and custom pool params for the brand new postgis-mvt renderer. As postgis-mvt renderer is not being used in production yet, we can say that we are safe... for now. We are safe because the pool-params that we pass as the second argument in node-cartodb-psql overrides the pg's defaults which is a singleton and after that, we will use a different pool-params configuration for incoming requests.

That was one my motivations to get this right before we go full throttle with that renderer.

On the other hand, as we can see in global.settings.environment.postgres there is a comment that claims that it's a config for mapnik datasource. But taking a deeper look into it, we only use some properties (user, password, host and port) as default parameters to create a user or public user connections mainly.

We actually do pass the postgres properties into grainstore datasource. Later, we use those options to compose the XML for Mapnik.

Regarding the pool parameters that we defined for different renderers (mapnik, mvt, geojson and torque). We use them for mapnik, mvt and http but we missed to pass the configuration for torque renderer. We didn't notice because it uses the internal cartodb-psql value for poolSize which is 16.

So, this is in a similar to MVT Postgis renderer, isn't it?

Regarding the poolSize value for mapnik renderer is 8 for the production environment. This parameter could be misleading because it's going to be used by tilelive-mapnik as the number of maximum number of loaded maps at the very same time. Then, mapnik has an internal pool for Postgres connections with a maximum value of 10 (by default).

As stated above, this is overriden by in grainstore with the postgres object.
HTH.

We actually do pass the Postgres properties into grainstore datasource. Later, we use those options to compose the XML for Mapnik.

OMG, I totally missed that XML has the datasource configuration. Can you imagine the day that I'm able to keep every single detail of our stack in my mind?
Thanks for your comments @rochoa. Now, I have the whole picture to carry on with this issue.

For the record, postgis datasource parameters reference ->  https://github.com/mapnik/mapnik/wiki/PostGIS

Tasks to be achieved:

Windsahft-cartodb:

[ ] Create a new general configuration entry for PostgreSQL pool.
[ ] Move "postgres" attributes inside Mapnik's renderer configuration to make it clear where that belongs.
[ ] Pass the very same pool configuration while creating windshaft's renderers

Windshaft:

[ ] Unify configration poolParam we use to create PSQL client for different renderers.

Maybe it's a good time to have a look at pg-pool and how it integrates with node-postgres.

@Algunenano don't throw the stone and hide your hand 😂 => What are you thinking about?

:moyai: :moyai: :moyai:
As I've been reviewing lately the changes in node-postgres I saw several references to the pools and a big change in v6:
v6.0.0
Breaking Changes
Remove pg.pools. There is still a reference kept to the pools created & tracked by pg.connect but it has been renamed, is considered private, and should not be used. Accessing this API directly was uncommon and was supposed to be private but was incorrectly documented on the wiki. Therefore, it is a breaking change of an (unintentionally) public interface to remove it by renaming it & making it private. Eventually pg.connect itself will be deprecated in favor of instantiating pools directly via new pg.Pool() so this property should become completely moot at some point. In the mean time...check out the new features...
New features
Replace internal pooling code with pg-pool. This is the first step in eventually deprecating and removing the singleton pg.connect. The pg-pool constructor is exported from node-postgres at require('pg').Pool. It provides a backwards compatible interface with pg.connect as well as a promise based interface & additional niceties.
You can now create an instance of a pool and don't have to rely on the pg singleton for anything:

var pg = require('pg')

var pool = new pg.Pool()

// your friendly neighborhood pool interface, without the singleton
pool.connect(function(err, client, done) {
  // ...
})
Promise support & other goodness lives now in pg-pool.

Please read the readme at pg-pool for the full api.

I haven't taken the time to check any changes but, as I think we should tend to be as close to upstream as possible, we could take the time and adapt our node-cartodb-psql module to use the latest (7) release to the fullest instead of relying in the old functions (pg.connect...).

Got it. Let me create a ticket with your proposal. ;)

Also somewhat related: I created a PR to update the fork to 6.4.1 plus some improvements (pg10 support + test in travis, remove warnings) but if you feel it's superseded by a future update to node-postgres@7 we could drop it.

In Windhaft-cartodb we create psql clients always w/o passing poolParams argument. Indeed, we pass conString as connection config which is used to create the key for the pool object (note that it just uses username, password, database,  dbhost and  dbport). For the same user connection params we use the default pool configuration through pg.defaults with 16 connections per pool. So the poolSize param never is used to compose the poolName.

But we could use the connection object.

Hey @rochoa,
Something that yesterday I realized is that actually poolParams is never used to create the key for the pool object as it uses the configuration passed as argument that we built with that.getConnectionConfig(). Later node-postgres overrides poolSize and idleTimeoutMillis. However, if the pool was created previously then the pool exists already and never gets the new pool configuration.
So basically we have one pool per combination of user, password, database, host and port. On the other hand, poolSize or idleTimeoutMillis will have the values that were used to create that pool for the first time and that pool.
My question is: do you think we should change this behaviour?.
In my hummble opinion, we should change it and we should NOT modify pg's defaults and replace existing pools if the pool configuration changes.


Why use gofn?

What is the difference from github.com/samber/lo?

I think they share the same purpose. I haven't known lo yet before your question.