test helpers

Thanks!
This may need to be split into 2 types of test helpers. For example, we should be able to inject the User ID into the session so it won't require an additional request.


issue with 3rd level domains

Finally figured it out with 3rd level domains
default test TLDs
.TEST
.COM.TEST
tlds with db id
id     tld
 1    .TEST
 2   .COM.TEST
 4   .example.com
 5   .COM
 6  .example.org

when creating 3rd level domain nic.com.test registry puts it into .TEST tld not into .COM.TEST
and for example.com when adding it  Registry -> TLDs menu and specifiing .example.com in .env file "TEST_TLDs
it dosn't work ... (when checking Domain nic.example.com  error= nic.example.com is not available: Zone is not supported)
so it requires to add .com TLD and when creating nic.example.com it adds it into .COM TLD not into .example.com too

Will reproduce and fix, thanks.

Reproduced. Will work on it for the next few days.

It was actually qute easy.  Replace cp/bootstrap/helper.php with the version from the last commit here and let me know if it got fixed.

CP works fine when cp/bootstrap/helper.php replaced with new....

Great, thanks. Closing this as the code is the same for both, you will just need to clone the full EPP again.


tanzim/refactor events

The PR introduces changes to the backend services, specifically related to model deployments, routers, and metrics.
Summary
The changes in this PR focus on updating the backend services, including model deployments and routers, and enhancing the metrics system. The modifications involve removing certain import statements, adding new functions and decorators, and updating existing functions to include additional functionality for metrics tracking.
Changes

src/backend/model_deployments/`:*

Removed imports related to collect_metrics_chat, collect_metrics_chat_stream, and collect_metrics_rerank from azure.py, bedrock.py, cohere_platform.py, sagemaker.py, and single_container.py.

src/backend/routers/`:*

Added imports and updated functions in agent.py and user.py to include metrics-related functionality, such as add_event_type_to_request_state and MetricsMessageType.
Modified create_user and update_user functions in user.py to include metrics event type and signal.

src/backend/services/metrics.py:

Added imports related to background tasks and updated the dispatch function to include event type and signal handling.
Removed the ROUTE_MAPPING dictionary and the event_name_of function, which were previously used to determine the event type.
Modified the get_event_data function to return None if the message type is not provided.
Updated the report_metrics function to accept a MetricsSignal object instead of MetricsData.
Removed the run_loop function and associated code related to handling task exceptions.
Removed decorators (collect_metrics_chat, collect_metrics_chat_stream, and collect_metrics_rerank) and associated code used for collecting metrics data.

src/backend/tests/routers/`:*

Updated test files (test_agent.py and test_user.py) to reflect the changes made in the corresponding router files.

Makefile:

Added new commands: run-agent-router-tests and run-user-router-tests for running specific router tests.

Codecov Report
Attention: Patch coverage is 78.84615% with 11 lines in your changes missing coverage. Please review.

Project coverage is 81.38%. Comparing base (9125660) to head (d70aa12).
Report is 16 commits behind head on main.

Files
Patch %
Lines

src/backend/services/metrics.py
76.66%
7 Missing :warning:

src/backend/tests/routers/test_agent.py
42.85%
4 Missing :warning:

Additional details and impacted files
@@            Coverage Diff             @@
##             main     #426      +/-   ##
==========================================
- Coverage   86.46%   81.38%   -5.09%
==========================================
  Files         178      197      +19
  Lines        6873     8208    +1335
==========================================
+ Hits         5943     6680     +737
- Misses        930     1528     +598

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.


Andi/farmsearch layout

What's new in this PR?
*Looks best at 90% zoom on laptop.
Implemented Farm Search page.
- completed all basic front end for Farm Search like the headers, search box, buttons, farm cards, new farm card.
- somewhat responsive with the grid column setup, still needs a decent amount of work.
Implemented basic modal overlay. There's a test button to test out the on-click overlay.
How to Review
New Files:
FarmSearch.js
FarmSearch.css
FarmCard.js
FarmCard.css
NewFarmCard.js
NewFarmCard.css
farmProfileCover.png
farmProfilePhoto.png
file-icon.png
Related PRs
png files will clash with phoebe's png files (from her Farm Profile PR https://github.com/calblueprint/ks-web/pull/22). But they are named the same, so we can just delete the duplicates on the merge.
farmProfileCover.png
farmProfilePhoto.png
Merge Farm Profile PR first before Farm Search. I think it'll be fine as long as the duplicate png files are deleted on the merge conflict.
Next steps

Improve responsiveness, specifically with grid column gaps.

Implement GAP Cert. stage and Sort By buttons

Develop backend
- for cards, search feature, individual overlays
- have alternate css for if data is not there (e.g. no farm Cover, no user Icon, not GAP certified, not in FoodHub)

Build upon Modal Overlay
- make farm cards clickable (currently just a button)
- incorporate Phoebe's Farm Profile PR components into the overlay card.

Misc. styling touchups

Screenshots

If there is no cover photo, user icon photo, and is not GAP/HUB button is empty.

Overlay:

Design Status
holy cow css
idk how to determine if something is lo mid or highfi
CC: @dfangshuo

Remember to use BEM convention! https://css-tricks.com/bem-101/

App.js conflicting file due to moving the code into a FarmSearch folder under Screens instead of a shared folder.

PUSHED. Nearly all changes requested tended to.
Changes left on next PR:

add farm modal content
replace with Spring's color/font constants.
add filter button feature
link to airtable backend


jupyter-marimo-proxy with jupyter docker-stacks images

Hi,
I´m am trying to get jupyter-marimo-proxy running with any of the jupyter docker stackes images.
I have a very simple Dockerfile
FROM  quay.io/jupyter/base-notebook

RUN   pip install --no-cache-dir 'marimo>=0.6.21'
RUN   /opt/conda/bin/pip install https://github.com/jyio/jupyter-marimo-proxy/archive/main.zip

Unfortunately, there is no marimo icon after building the image and running the container.

@benz0li
Unfortunately it is not as simple :-)
I mounted a volume to /home/jovyan, to persist the user data, run the commands from here https://github.com/b-data/jupyterlab-r-docker-stack#marimo and restarted the container. No success.
The problem seems to be, which pip gives me /opt/conda/bin/pip and therefore marimo and jupyter-marimo-proxy is not installed persistent in /home/jovyan

@legout I am not using the Jupyter docker stack, but b-data's/my own  JupyterLab docker stack:

Multi-arch: linux/amd64, linux/arm64/v8
:information_source: Runs on Apple M series using Docker Desktop.
Base image: Debian instead of Ubuntu
:information_source: CUDA-based images use Ubuntu.
IDE: code-server next to JupyterLab
:information_source: code-server = Code - OSS in the browser.
Just Python – no Conda / Mamba

– https://github.com/b-data/jupyterlab-python-docker-stack#similar-projects

Thanks. I´ll give it a try!

No success
This is what I did

Started the container

docker run -it --rm \y
  -p 8888:8888 \
  -u root \
  -v "${PWD}/jupyterlab-jovyan":/home/jovyan \
  -e NB_UID=$(id -u) \
  -e NB_GID=$(id -g) \
  -e CHOWN_HOME=yes \
  -e CHOWN_HOME_OPTS='-R' \
   glcr.b-data.ch/jupyterlab/r/base

In Jupyterlab, started a terminal

pip install marimo click
pip install git+https://github.com/b-data/jupyter-marimo-proxy.git@jupyterlab-docker-stack

Restarted the container

There is still no marimo icon

Now its working.
Basically, thats what I´ve done.
FROM quay.io/jupyter/base-notebook
...
USER root

RUN conda install jupyter-server-proxy jupyter-vscode-proxy jupyterlab-git marimo -y && \
    /opt/conda/bin/pip install --no-cache-dir jupyter-marimo-proxy

...
USER jovyan
...

@legout It works again on https://demo.jupyter.b-data.ch.

What did you do to get it back working?

What did you do to get it back working?

To get it working without an associated JupyterHub: https://github.com/b-data/jupyter-marimo-proxy/commit/378ccc1c29c7f3a8b6ea9200cb90849ad0b39276


vm.broadcast() sets incorrect nonce for txs

Component
Forge
Have you ensured that all of these are up to date?

[X] Foundry
[X] Foundryup

What version of Foundry are you on?
forge 0.2.0 (a0a31c3 2023-08-12T00:23:12.943797000Z)
What command(s) is the bug in?
forge script
Operating System
macOS (Apple Silicon)
Describe the bug
contract NonceBug is Script {
    function run() public payable {
        vm.broadcast(1);
        IERC20(0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48).approve(
            address(1), 1000
        );

        vm.broadcast(1);
        IERC20(0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48).approve(
            address(1), 1000
        );
    }
}

Dry-running following script on mainnet will generate two transactions with the same nonce for the same sender:
{
  "transactions": [
    {
        ...
        "nonce": "0x661",
        "accessList": []
      },
      ...
    },
    {
        ...
        "nonce": "0x661",
        "accessList": []
      },
      ...
    }
  ],
...
}

When adding --broadcast flag, script will fail with error EOA nonce changed unexpectedly while sending transactions
I have tracked the issue down to this line of code: https://github.com/foundry-rs/foundry/blob/410c8173e76b9fa42864e2d63309cd7cc4b6cfd9/crates/evm/src/executor/inspector/cheatcodes/mod.rs#L727
And it seems to be actually increasing nonce to correct next value. But somehow on the next broadcast it becomes the old value again.
Another interesting thing here is that following script would generate correct nonces:
contract NonceBug is Script {
    function run() public payable {
        vm.broadcast(1);
        address(0).call("");

        vm.broadcast(1);
        address(0).call("");
    }
}

{
  "transactions": [
    {
        ...
        "nonce": "0x661",
        "accessList": []
      },
      ...
    },
    {
        ...
        "nonce": "0x662",
        "accessList": []
      },
      ...
    }
  ],
...
}

Also, using vm.startBroadcast()/vm.stopBroadcast() instead of vm.broadcast() solves the issue too.

Ah so I have actually run into this in another form i think, and I couldnt tell you at the moment exactly whats going on will try to repro soon but
https://github.com/foundry-rs/foundry/blob/95a93cd397f25f3f8d49d2851eb52bc2d52dd983/crates/evm/src/executor/inspector/cheatcodes/mod.rs#L768-L776
this block would have been executed at the end of your first call.
It sets the broadcast field to None on the Cheatcodes Inspector, so your code block would never be hit after the first broadcast (?)
(This does not happen when you use vm.startBroadcast / vm.stopBroadcast)
Im guessing this is related. Although prank (single call) has the same logic here so not 100%

I think that the reason for this is here:
https://github.com/foundry-rs/foundry/blob/95a93cd397f25f3f8d49d2851eb52bc2d52dd983/crates/evm/src/executor/inspector/cheatcodes/env.rs#L695-L705
It is the only place in the whole codebase which is actually decreases nonce, and somehow it is being called for the first scenario (with ERC20), and not being called for other scenario.
I will try to dive deeper into this logic

This is due to delegatecall which happens when calling USDC. Replacing USDC address with DAI solves the issue

So, the exact flow is as following:

broadcast call is getting processed, and tx.origin is set to the user address
User calls some contract after broadcast
Contract makes delegatecall
call_end function gets entered and due to depth mismatch caller stays the same, but the broadcast is getting removed:
https://github.com/foundry-rs/foundry/blob/95a93cd397f25f3f8d49d2851eb52bc2d52dd983/crates/evm/src/executor/inspector/cheatcodes/mod.rs#L768-L776
The caller is never updated until the next call/prank/whatever
On the next .broadcast, we still have the caller set to the user address, and correct_caller_nonce function decreases it's nonce
https://github.com/foundry-rs/foundry/blob/95a93cd397f25f3f8d49d2851eb52bc2d52dd983/crates/evm/src/executor/inspector/cheatcodes/env.rs#L695-L705


GH-141 Fixed DLQ vs local handler inconsistencies

Given that getErrorMessageHandler is already checking for properties.getExtension().isRepublishToDlq() removing the IF from the configuration phase of the adapter with RetryTemplate ensures the consistency of the behavior for cases when local error handler is configured and RetryTemplate is used.
Resolves #141

@garyrussel, @olegz is it possible to get this in 1.3.x release code as well?


ipc_service: Add icmsg backend

Several points:

Add a PR description
2 commits are missing a commit message
Instead of replacing the static_vrings sample, please add a new sample instead

Several points:

Add a PR description
2 commits are missing a commit message
Instead of replacing the static_vrings sample, please add a new sample instead

I'm about to beautify this PR and make it open, that's just a first toss so you could see general idea. I'll update missing documentation and description soon.
When it comes to the sample this commit would be dropped. I used it for profiling.

I've pushed some changes. Most important one is i removed commit with sample, at least for now. I replaced this with unit tests for ipc_icmsg_buf. Please have a look if you are interested (2nd commit).
@carlocaione I think i addressed all your comments.
@nordic-krch s/a except for uint16_t as for len
@rakons s/a
@hubertmis  I think we should be settled now.
I will update write and read API to uint16_t with next push, be patient.

@nashif could you have a look in CI workflow? I've added some unit tests for the functionality and for some, unknown to me, reason CI is failing.

@nashif @stephanosio could you have a look in CI workflow? I've added some unit tests for the functionality and for some, unknown to me, reason CI is failing.

ERROR   - /__w/zephyr/zephyr/tests/lib/icmsg/src/main.c: Found a test that does not start with test_
ERROR   - /__w/zephyr/zephyr/tests/lib/icmsg: can't load (skipping): /__w/zephyr/zephyr/tests/lib/icmsg/src/main.c: Found a test that does not start with test_

Added commit with sample again
Removed assertion for callbacks existance
fixed a bug in ipc_icmsg_buf where mlen was recreated based on wr_idx + reordered code a bit to aboid rd_idx_temp.
Clean up some documentation notes (removed unnecessary lines)

Some of the CI issues should be fixed by #43903

Regarding icmsg_buf. I wanted to propose an approach with non-wrapping messages. Basically, if message does not fit into buffer and would require wrapping, a padding is added (by adding 0xFF length byte) which indicates that next packet is written from the start (if there is no room at the start -ENOMEM is returned and padding is not added).
This approach slightly decreases memory utilization but simplifies implementation, reduces memory footprint (402->284 in test i run), speeds things up. Also it would allow zero-copy approach where we could get pointer to the message and free it once processed (in read case) which would allow to get rid of array allocated on the stack by upper layer.
Using 0xff as padding marker would limit max packet length to < 0xff00 which should be ok.
I sketch this proposal: https://github.com/zephyrproject-rtos/zephyr/commit/d6c53591ff8a998df0c4d4f6a8fbe3c7e245c068
With small test modification it passes the unit test.

Regarding icmsg_buf. I wanted to propose an approach with non-wrapping messages. Basically, if message does not fit into buffer and would require wrapping, a padding is added (by adding 0xFF length byte) which indicates that next packet is written from the start (if there is no room at the start -ENOMEM is returned and padding is not added).
This approach slightly decreases memory utilization but simplifies implementation, reduces memory footprint (402->284 in test i run), speeds things up. Also it would allow zero-copy approach where we could get pointer to the message and free it once processed (in read case) which would allow to get rid of array allocated on the stack by upper layer.
Using 0xff as padding marker would limit max packet length to < 0xff00 which should be ok.
I sketch this proposal: d6c5359 With small test modification it passes the unit test.

That can be useful. There are tradeoffs but these might be acceptable.
Let's however first finish the PR as is. I fear that once we add another rework we will brake something and add delay.
Once we have the backend in place we could think of pros and cons of proposed change and test the performance. The only tradeoff I can think of is slight memory waste. Performance should actually improve (yes - we might delay the return of the buffer space to other core but since we get rid of one copy the overall throughput will increase). The design of len must be changed as we will no longer be able to have direct uint16_t there. But that's not a problem either as we can have variable length len.
Just please do it in subsequent PR. My whole experience is against prolonged reviews. Code gradually degrades with added feature requests as authors have enough of the changes and so rush things while reviewers also spend less time on actually analyzing the code. Let's fix what we have here and do the change iteratively.

@nordic-krch  @carlocaione  Can as ask you for last round? Reviews are dismissed after i pushed changes with comments.

@carlescufi please have a look and merge if possible.


edit:-narrow-read crash when no option matches filter

Within edit:-narrow-read, if you type a string that leaves no options, and press Enter, Elvish crashes.
To reproduce:
edit:insert:binding[Alt-z] = { edit:-narrow-read { each [s]{ put [&content=$s &display=$s] } [one two] } [arg]{ edit:insert-at-dot $arg[content] } }

Then press Alt-z. If you type "foo" (for example) so that none of the options are left, and press Enter, the following happens:
https://gist.github.com/zzamboni/8584ad18fa1844063381ec4a846ade5b

Apparently edit:listing:start-custom has the same issue; repurposing this issue.

To reproduce, type the following in the minibuf:
edit:listing:start-custom []

And then press Enter. Elvish crashes.

Fixed by #892!


Upcoming funding cycle card issues

Problem to solve
Is your feature request related to a problem? Provide a clear and concise
description of what the problem is. Ex. I'm always frustrated when [...]
Proposal
Describe the feature/solution you'd like. A clear and concise description of
what you want to happen.
More details
Add any other notes or screenshots about the feature request here.

 If its still sus after we fix ballots https://github.com/jbx-protocol/juice-interface/issues/826, we can re-open


Add new 'node_name' label to expose the node name.

See https://github.com/kubernetes/heapster/issues/731

Can one of the admins verify this patch?

Can we somehow fix hostname instead of adding another label which will do more-or-less the same?

This has nothing to do with the hostname. The hostname and the node name are completely separate.
This more similarities to the existing 'host_id' label. We could change the host_id label to be node name, but this changes existing behaviour and may cause backwards compatibility issues.
The problem is that there is currently no label which will always give you the name of the node. Being able to query based on the node name is an important feature, especially if you end up migrating your node from one machine to another.

Can you make sure that this label doesn't go to GCM - we are already hitting the limit (10) of labels AFAIR.

I don't really have a setup for testing with GCM. I can add in something to prevent it from being added to the GCM sink if that is required, but I can't easily test and verify it.
Is there a unit test to take into account this limitation with GCM?

Unfortunately there is no unit test
Filter it in these places:
https://github.com/kubernetes/heapster/blob/master/sinks/gcm/core.go#L254
https://github.com/kubernetes/heapster/blob/master/sinks/gcm/core.go#L281
https://github.com/kubernetes/heapster/blob/master/sinks/gcm/driver.go#L33

This sounds like a very specific GCM issue, which I think should be handled by someone who is more familiar with the GCM sink and this issue. I don't use GCM and I don't have a system configured to test on GCM at the moment.

Can one of the admins verify this patch?

Can one of the admins verify this patch?

ok to test

ok to test
On Mon, Dec 14, 2015 at 1:01 PM, Kubernetes Bot<EMAIL_ADDRESS>wrote:

Can one of the admins verify that this patch is reasonable to test? (reply
"ok to test", or if you trust the user, reply "add to whitelist")
If this message is too spammy, please complain to ixdy.
—
Reply to this email directly or view it on GitHub
https://github.com/kubernetes/heapster/pull/753#issuecomment-164557995.

Ping @mwringe @mwielgus : How do we make progress on this PR?

@vishh I am not sure how exactly to make progress with this PR. There is an issue where the GCM sink can only support 10 labels and this PR pushes the label count to 11.
So with this PR the GCM sink wont be able to function properly. I don't have a GCM account setup to test, and I don't know how exactly to handle this situation.
It seems like someone familiar with the GCM sink should be making the decisions on how it should work.  You may need to open up a new configuration option for GCM to allow admins to specify which labels they actually want or not, or perhaps just hardcode it in the sink.

We might have to define GCM labels which might be a subset of all the
labels.
On Fri, Dec 18, 2015 at 10:48 AM, Matthew Wringe<EMAIL_ADDRESS>wrote:

@vishh https://github.com/vishh I am not sure how exactly to make
progress with this PR. There is an issue where the GCM sink can only
support 10 labels and this PR pushes the label count to 11.
So with this PR the GCM sink wont be able to function properly. I don't
have a GCM account setup to test, and I don't know how exactly to handle
this situation.
It seems like someone familiar with the GCM sink should be making the
decisions on how it should work. You may need to open up a new
configuration option for GCM to allow admins to specify which labels they
actually want or not, or perhaps just hardcode it in the sink.
—
Reply to this email directly or view it on GitHub
https://github.com/kubernetes/heapster/pull/753#issuecomment-165867920.

@vishh @mwringe What needs doing to get this merged?

The GCM sink needs to be updated to support handling more than 10 labels. Or make it more generic and add an option to be able to filter to any sink the list of labels to be considered.

Please do the change in heapster-scalability branch if it is still needed.


Invalid cron spec does not trigger an error

From a discord conversation https://discord.com/channels/1156433345631232100/1217220112570912898/1290004975757557761
@DBOS.scheduled("*/invalid * * * * *") but does not throw an error, either. And its invalid, just checked with an online cron format validator.

Addressed in https://github.com/dbos-inc/dbos-transact-py/pull/125


Compatibly with DPH3205?

Has anyone tried this with the DPH3205 which is the buck-boost converter version of this?

I have none to test. Adding support should be a breeze though as the STM32 is not covered in a sandwich PCB design as with the 5005. Really helps the reverse engineering effort.

Do you have any guidence on how one would go about starting this effort to be compatible with your software? I'm willing to put down the needed time to make it happen, just need some pointers on how to best contribute.

You can start off with my reverse engineering effort and learn how the stock FW controls your device. You need to figure out how the buttons are connected and how the output voltage and current are set. For the DPS5005 the DAC is used for voltage and TIM2 (IIRC) for current limit.
For the voltage setting, I would dial a selection on the stock FW and then check the DAC setting using the ocd-client.py script with OpenOCD connected. For your information, the stock FW freezes from time to time when JTAG halted.

@felixekman Did you tried it?

Are you working on a port @gnbl ? I am interested in this version as it is buck-boost.

@opeRaptor Not since my last post and not again any time soon, so go ahead.

#197

Are the differences between DPS and DPH so big? If someone convinces me that he/she is capable of porting opendps to DPH i will send him DPHxxx device for free.

We have a DPH3205 for our community repair group. It's used by many repair volunteers so it would be amazing to have a better interface where changing current and voltage is more intuitive.


feat: add cli artifacts compare command

What does this PR do?
Adds cli artifacts compare command for comparing command-snapshot.json and schemas/ for each plugin (including JIT) in the CLI. Throws error if breaking change is found in any plugin
Example output
~/repos/salesforcecli/cli (sh/add-jit-plugins) » ~/repos/salesforcecli/plugin-release-management/bin/dev cli:artifacts:compare
Warning: No schemas found for<EMAIL_ADDRESS>Warning: No schemas found for<EMAIL_ADDRESS>Warning: No schemas found for<EMAIL_ADDRESS>Warning: No schemas found for<EMAIL_ADDRESS>Warning: No schemas found for<EMAIL_ADDRESS>Warning: No schemas found for<EMAIL_ADDRESS>Warning: No schemas found for<EMAIL_ADDRESS>Warning: No schemas found for<EMAIL_ADDRESS>Warning: No schemas found for<EMAIL_ADDRESS>Warning: No schemas found for<EMAIL_ADDRESS>Warning: No schemas found for<EMAIL_ADDRESS>Warning: No schemas found for<EMAIL_ADDRESS>=== @salesforce/plugin-settings

Current: 1.2.0
Previous: 1.1.15

Snapshot Changes
alias:list No Changes
alias:set No Changes
alias:unset No Changes
config:get No Changes
config:list No Changes
config:set No Changes
config:unset No Changes

Schema Changes

alias:unset
  - ❌ definitions.alias-1501530572-0-211-1501530572-0-1533943985149 was not found in current schema
  - definitions.SfError.properties.cause.properties.cause.$ref was changed from #/definitions/alias-1501530572-0-211-1501530572-0-1533943985149 to #/definitions/alias-1283098157-0-211-1283098157-0-1533943985149
  - definitions.alias-1283098157-0-211-1283098157-0-1533943985149 was added to current schema

alias:set
  - ❌ definitions.alias-1501530572-0-211-1501530572-0-1533943985149 was not found in current schema
  - definitions.SfError.properties.cause.properties.cause.$ref was changed from #/definitions/alias-1501530572-0-211-1501530572-0-1533943985149 to #/definitions/alias-1283098157-0-211-1283098157-0-1533943985149
  - definitions.alias-1283098157-0-211-1283098157-0-1533943985149 was added to current schema

=== @salesforce/plugin-deploy-retrieve

Current: 1.8.0
Previous: 1.7.2

Snapshot Changes
deploy No Changes
deploy:metadata No Changes
deploy:metadata:cancel No Changes
deploy:metadata:preview No Changes
deploy:metadata:quick No Changes
deploy:metadata:report No Changes
deploy:metadata:resume No Changes
deploy:metadata:validate No Changes
retrieve:metadata No Changes
retrieve:metadata:preview No Changes

Schema Changes
No changes have been detected.

=== @salesforce/plugin-env

Current: 2.0.1
Previous: 1.6.0

Snapshot Changes
❌ Removed Commands: [
  'env:create:sandbox',
  'env:create:scratch',
  'env:delete:sandbox',
  'env:delete:scratch',
  'env:resume:sandbox',
  'env:resume:scratch'
]
env:display No Changes
env:list No Changes
env:open No Changes

Schema Changes

env:resume:scratch
  - ❌ env:resume:scratch was not found in current schema

env:resume:sandbox
  - ❌ env:resume:sandbox was not found in current schema

env:delete:scratch
  - ❌ env:delete:scratch was not found in current schema

env:delete:sandbox
  - ❌ env:delete:sandbox was not found in current schema

env:create:scratch
  - ❌ env:create:scratch was not found in current schema

env:create:sandbox
  - ❌ env:create:sandbox was not found in current schema

=== @salesforce/plugin-functions

Current: 1.17.4
Previous: 1.17.3

Snapshot Changes
deploy:functions No Changes
env:compute:collaborator:add No Changes
env:create:compute No Changes
env:delete No Changes
env:log No Changes
env:log:tail No Changes
env:logdrain:add No Changes
env:logdrain:list No Changes
env:logdrain:remove No Changes
env:var:get No Changes
env:var:list No Changes
env:var:set No Changes
env:var:unset No Changes
generate:function No Changes
login:functions No Changes
login:functions:jwt No Changes
logout:functions No Changes
run:function No Changes
run:function:start No Changes
run:function:start:container No Changes
run:function:start:local No Changes
whoami:functions No Changes

Schema Changes
No changes have been detected.

=== @salesforce/plugin-generate

Current: 1.1.0
Previous: 1.0.45

Snapshot Changes
generate:project No Changes

Schema Changes
No changes have been detected.

=== @salesforce/plugin-info

Current: 2.4.0
Previous: 2.3.6

Snapshot Changes
doctor No Changes
info:releasenotes:display No Changes

Schema Changes
No changes have been detected.

=== @salesforce/plugin-limits

Current: 2.3.0
Previous: 2.2.4

Snapshot Changes
limits:api:display No Changes
limits:recordcounts:display No Changes

Schema Changes
No changes have been detected.

=== @salesforce/plugin-schema

Current: 2.2.3
Previous: 2.2.2

Snapshot Changes
sobject:describe No Changes
sobject:list No Changes

Schema Changes
No changes have been detected.

=== @salesforce/plugin-login

Current: 1.1.17
Previous: 1.1.16

Snapshot Changes
login No Changes
login:org No Changes
login:org:jwt No Changes
logout No Changes
logout:org No Changes

Schema Changes
No changes have been detected.

=== @salesforce/plugin-org

Current: 2.3.0
Previous: 2.2.25

Snapshot Changes
force:org:clone No Changes
force:org:create No Changes
force:org:delete No Changes
force:org:status No Changes
org:create:sandbox No Changes
org:create:scratch No Changes
org:delete:sandbox No Changes
org:delete:scratch No Changes
org:display No Changes
org:list No Changes
org:open No Changes
org:resume:sandbox No Changes
org:resume:scratch No Changes

Schema Changes
No changes have been detected.

=== @salesforce/plugin-sobject

Current: 0.1.0
Previous: 0.0.42

Snapshot Changes
schema:generate:field No Changes
schema:generate:platformevent No Changes
schema:generate:sobject No Changes
schema:generate:tab No Changes

Schema Changes
No changes have been detected.

=== @salesforce/plugin-telemetry

Current: 2.1.0
Previous: 2.0.7

Snapshot Changes
telemetry No Changes

Schema Changes
No changes have been detected.

=== @salesforce/plugin-trust

Current: 2.4.0
Previous: 2.3.2

Snapshot Changes
plugins:trust:verify No Changes

Schema Changes
No changes have been detected.

=== @salesforce/plugin-data

Current: 2.1.24
Previous: 2.1.23

Snapshot Changes
data:create:record No Changes
data:delete:bulk No Changes
data:delete:record No Changes
data:export:tree No Changes
data:get:record No Changes
data:import:tree No Changes
data:query No Changes
data:query:resume No Changes
data:resume No Changes
data:update:record No Changes
data:upsert:bulk No Changes

Schema Changes
No changes have been detected.

=== @salesforce/plugin-user

Current: 2.3.0
Previous: 2.2.1

Snapshot Changes
force:user:password:generate No Changes
force:user:permset:assign No Changes
force:user:permsetlicense:assign No Changes
org:assign:permset No Changes
org:assign:permsetlicense No Changes
org:create:user No Changes
org:display:user No Changes
org:generate:password No Changes
org:list:users No Changes

Schema Changes
No changes have been detected.

=== @salesforce/plugin-custom-metadata

Current: 2.1.1
Previous: 2.1.0

Snapshot Changes
cmdt:generate:field No Changes
cmdt:generate:fromorg No Changes
cmdt:generate:object No Changes
cmdt:generate:record No Changes
cmdt:generate:records No Changes

Schema Changes
No changes have been detected.

=== @salesforce/plugin-community

Current: 2.2.1
Previous: 2.2.0

Snapshot Changes
community:create No Changes
community:list:template No Changes
community:publish No Changes

Schema Changes
No changes have been detected.

=== @salesforce/plugin-packaging

Current: 1.14.1
Previous: 1.14.0

Snapshot Changes
package1:version:create No Changes
package1:version:create:get No Changes
package1:version:display No Changes
package1:version:list No Changes
package:convert No Changes
package:create No Changes
package:delete No Changes
package:install No Changes
package:install:report No Changes
package:installed:list No Changes
package:list No Changes
package:uninstall No Changes
package:uninstall:report No Changes
package:update No Changes
package:version:create No Changes
package:version:create:list No Changes
package:version:create:report No Changes
package:version:delete No Changes
package:version:displayancestry No Changes
package:version:list No Changes
package:version:promote No Changes
package:version:report No Changes
package:version:update No Changes

Schema Changes
No changes have been detected.

=== @salesforce/plugin-signups

Current: 1.4.0
Previous: 1.3.2

Snapshot Changes
org:create:shape No Changes
org:create:snapshot No Changes
org:delete:shape No Changes
org:delete:snapshot No Changes
org:get:snapshot No Changes
org:list:shape No Changes
org:list:snapshot No Changes

Schema Changes
No changes have been detected.

Error: Breaking changes found in artifacts

What issues does this PR fix or reference?
@W-12489891@

QA NOTES

I've still got a few things to test, here is a WIP QA

🟡 description text is repeated twice in --help output.
🟡 I initially tried running this command from the bin/dev of plugin-release-management which obviously failed. Might be worth checking that the current directory is a "cli", maybe by checking oclif.bin?
🟢 Flag additions log (not warn)
🟢 New commands log (not warn)
🟢 Able to compare against old sf with --previous
🟢 Collects correct plugin versions from a --previous cli
🟢 Detects removed commands in snapshot
🟢 Detects removed commands in schema

QA NOTES

I've still got a few things to test, here is a WIP QA

🟡 description text is repeated twice in --help output.
🟡 I initially tried running this command from the bin/dev of plugin-release-management which obviously failed. Might be worth checking that the current directory is a "cli", maybe by checking oclif.bin?
🟢 Flag additions log (not warn)
🟢 New commands log (not warn)
🟢 Able to compare against old sf with --previous
🟢 Collects correct plugin versions from a --previous cli
🟢 Detects removed commands in snapshot
🟢 Detects removed commands in schema

QA UPDATE

🟢 Error is thrown if current is newer than previous
🟢 Able to compare against old sf with --current
🟢 Collects correct plugin versions from a --current cli
🟡 Would it be worth moving Warning: No schemas found for ... to the Summary at the bottom?
🟢 Throws an error if current or previous does not exist
🟢 Works with jitPlugins 🎉 Tested with "@salesforce/plugin-packaging": "1.14.4"
🟡 The semver.lt check could potentially fail if someone was manually adding a prerelease version and didn't bump major/minor/patch also. Not sure if this is worth adding logic for or just something to keep in mind. Here is an example where the current (beta) is technically less than the previous:

Running: bin/dev cli:artifacts:compare
Current Version: 1.65.0-beta.0 # Manually changed in package.json
Previous Version: 1.65.0
Error: Current version 1.65.0-beta.0 must be newer than previous version 1.65.0.


Clean up compat.

[x] Have you followed the guidelines in our Contributing document?
[x] Have you checked to ensure there aren't other open Pull Requests for the same change?
[x] Have you added an explanation of what your changes do and why you'd like us to include them?
[ ] Have you written new tests for your changes? Here's an example.

[x] Have you successfully run brew tests with your changes locally?

Always use this style:
module Compat
end

prepend Compat

There's still e.g. compat/formula.rb using the "open the existing class to overwrite the method" style; you might want to read through all the files in compat for comparison. This style is also taken by extend/os too if it made sense to clean that up in the same fashion.

Well, prepend is only needed if the compatibility layer should be able to call the current implementation, i.e. super, but I guess we can use the same style anyways, just to be consistent.

👍 Gotcha. I'm fine either way. For a future PR this does apply a bunch to the extend/os layer so doing it there too would be 🎉


Update Carrierwave to 1.0.0

Carrierwave needs to be updated to latest version. I use carrierwave but I use the latest version as bootsy depends on 0.11.
Bundler could not find compatible versions for gem "carrierwave":
  In Gemfile:
    carrierwave (~> 1.0.0)

    bootsy was resolved to 2.3.1, which depends on
      carrierwave (~> 0.11)

Fixed at 4b373134e3dbfb67537f0b313fb65c14c119cffd
Thanks for reporting!


[REVIEW] add fix_emb_size param in Categorify op for fixed embedding table size

This PR is created to address Ability to select a fixed cardinality embedding rather than a frequency limit (same options for low frequency; mapping to a single value and hashing) in the issue https://github.com/NVIDIA/NVTabular/issues/194.

@benfred I am having an issue with _get_embeddings_dask func.. It does not generate correct embeddings, when I set max_size > len(df), and num_buckets > 1.  I could not make it to generate correct results for this scenario.
I uploaded an example here. you can run and see.  Please also try the following params.
cat_features = cat_names >> nvt.ops.Categorify(
    max_size={"author": 8, "engaging_user": 12}, num_buckets=5
)

I am thinking may be I need to send raw  unique cardinality values to _get_embeddings_dask so that, we can check if max_size < len(df) then it wont consider num_buckets at all.

Hey - I think there were two issues there:

You were checking the max_size against the length of the dataframe - and only applying nlargest if it was smaller. this caused a problem with the num_buckets - 1 check (like with buckets we could still need to take nlargest)
The logic in the get_embeddings_dask was a little more complicated than I think it needed to be .

I pushed a change there that I think should handle both of these in that last commit - can you take a look?

Hey - I think there were two issues there:

You were checking the max_size against the length of the dataframe - and only applying nlargest if it was smaller. this caused a problem with the num_buckets - 1 check (like with buckets we could still need to take nlargest)
The logic in the get_embeddings_dask was a little more complicated than I think it needed to be .

I pushed a change there that I think should handle both of these in that last commit - can you take a look?

@benfred thanks for your help. Unfortunately we still have the problem. if you can check the latest committed code and run the example again, you will see that we don't get the expected emb_size for  a case like cat_features = cat_names >> nvt.ops.Categorify(max_size={"author": 12, "engaging_user": 8}, num_buckets=5).
My first idea of setting max_size as boolean (True, False) actually would work, and it'd be simpler than this case. what do you think?

I'm not sure I understand - with the code I pasted I get  {'author': (12, 16), 'engaging_user': (8, 16)} with nvt.ops.Categorify(max_size={"author": 12, "engaging_user": 8}, num_buckets=5) . Is that not what we should have?

I'm not sure I understand - with the code I pasted I get {'author': (12, 16), 'engaging_user': (8, 16)} with nvt.ops.Categorify(max_size={"author": 12, "engaging_user": 8}, num_buckets=5) . Is that not what we should have?

No, because the author column has cardinality of

I'm not sure I understand - with the code I pasted I get {'author': (12, 16), 'engaging_user': (8, 16)} with nvt.ops.Categorify(max_size={"author": 12, "engaging_user": 8}, num_buckets=5) . Is that not what we should have?

My understanding from that was,  since, the author column has 8 unique values, so cardinality =8, and since the original cardinality < max_size,  at the end with max_size param which is used for fix_embedding size,  the user should get emb_size maximum 9 (8+1).  I remember we talked on that at our Monday meeting, and we decided if the original cardinalities are less than the max_size, they wont be touched, and left as they are? so in Alberto's case, if he uses max_size together with num_buckets param, he will end up with emb_size original cardinality + num_buckets + 1 for features with only 3 cardinality.  If that's fine,  then we can proceed.

My understanding from that was, since, the author column has 8 unique values, so cardinality =8, and since the original cardinality < max_size, at the end with max_size param which is used for fix_embedding size, the user should get emb_size maximum 9 (8+1). I

So - I think the 'max' size for the embedding table should be specified by max_size here - so it should never be any larger than 12. So if you pass in max_size={"author": 12}  that max value should be 12 here.
However there are 8 unique values, and 5 values for a hash bucket and 1 value for unknown - so the max cardinality here is really 14, so I think having the values returned as 12 is correct in this case . I think we need to keep the hash_bucket sizes here, because we don't know the distribution of unique values in the validation set - just in the train set. If you bump up the 'max_size' to a 100 - it still returns 14 which I think is correct


where filter with 2 Anded  Like clauses and a nearText filter causes weaviate to panic.

minimal setup to reproduce it.
Tested with:

Weaviate version v1.8.0 and v1.9.0
With, and without, Usage Proxy.
With contextionary and transformers

Everything gave same result.
This is the ONLY class needed to reproduce it.
class_schema = {
    'class': 'Test',
    'description': '',
    'properties':[
        {
            'name': 'testOne',
            'dataType': ['text']
        },
        {
            'name': 'testTwo',
            'dataType': ['text']
        }
    ]
}

And only one object is enough:
{
        'testOne': 'test tests',
        'testTwo': 'test'
    }

Now if you do this query:
{
  Get
  {
    Test(
      nearText:{
        concepts: ["ANYTHING YOU CAN COME UP WITH, DOES NOT MATTER  BUT IT HAS TO BE AT LEAST SOMETHING"]
      }
      where:{
        operator: And,
        operands:[
          {
            operator: Like,
            path: ["testOne"],
            valueText:"test*"
          },
          {
            operator: Like,
            path: ["testTwo"],
            valueText:"test*"
          }
        ]
      }
    ) {
      testOne
      testTwo
    }
  }
}

the weaviate crashes with this Console output:
{
  "message": "Failed to fetch",
  "stack": "TypeError: Failed to fetch\n    at https://console.semi.technology/static/js/main.7c685d2a.chunk.js:1:45268\n    at u (https://console.semi.technology/static/js/2.94e923c7.chunk.js:2:981576)\n    at Generator._invoke (https://console.semi.technology/static/js/2.94e923c7.chunk.js:2:981364)\n    at Generator.next (https://console.semi.technology/static/js/2.94e923c7.chunk.js:2:982001)\n    at r (https://console.semi.technology/static/js/2.94e923c7.chunk.js:2:302901)\n    at s (https://console.semi.technology/static/js/2.94e923c7.chunk.js:2:303104)\n    at https://console.semi.technology/static/js/2.94e923c7.chunk.js:2:303163\n    at new Promise (<anonymous>)\n    at https://console.semi.technology/static/js/2.94e923c7.chunk.js:2:303044\n    at fetcher (https://console.semi.technology/static/js/main.7c685d2a.chunk.js:1:45732)"
}

and these weaviate panic logs:
test-t2v-transformers-1  | INFO:     <IP_ADDRESS>:51112 - "POST /vectors HTTP/1.1" 307 Temporary Redirect
test-t2v-transformers-1  | INFO:     <IP_ADDRESS>:51112 - "POST /vectors/ HTTP/1.1" 200 OK
test-weaviate-1          | panic: runtime error: index out of range [1] with length 1
test-weaviate-1          |
test-weaviate-1          | goroutine 595 [running]:
test-weaviate-1          | github.com/semi-technologies/weaviate/adapters/repos/db/inverted.intersectAnd(0xc000d79ab0, 0xc000d79990, 0xc000de9a28)
test-weaviate-1          |      /go/src/github.com/semi-technologies/weaviate/adapters/repos/db/inverted/merge.go:95 +0x37e
test-weaviate-1          | github.com/semi-technologies/weaviate/adapters/repos/db/inverted.mergeAndOptimized(0xc000dd20b0, 0x2, 0x2, 0x71183480e8645301, 0xc000d79a70, 0xc000dd20b0, 0xc000dc03f0)
test-weaviate-1          |      /go/src/github.com/semi-technologies/weaviate/adapters/repos/db/inverted/merge.go:72 +0x37f
test-weaviate-1          | github.com/semi-technologies/weaviate/adapters/repos/db/inverted.(*propValuePair).mergeDocIDs(0xc000d79830, 0xc000de9c01, 0xffffffffffffffff, 0x1, 0x0)
test-weaviate-1          |      /go/src/github.com/semi-technologies/weaviate/adapters/repos/db/inverted/prop_value_pairs.go:88 +0x289
test-weaviate-1          | github.com/semi-technologies/weaviate/adapters/repos/db/inverted.(*Searcher).DocIDs(0xc000de9c88, 0x1486280, 0xc000bfabd0, 0xc000010a10, 0x0, 0x0, 0xc0002ed790, 0x4, 0x5638c8, 0x56385d, ...)
test-weaviate-1          |      /go/src/github.com/semi-technologies/weaviate/adapters/repos/db/inverted/searcher.go:169 +0xe8
test-weaviate-1          | github.com/semi-technologies/weaviate/adapters/repos/db.(*Shard).objectVectorSearch(0xc00048d340, 0x1486280, 0xc000bfabd0, 0xc000dc4800, 0x180, 0x1da, 0x64, 0xc000010a10, 0x0, 0x0, ...)
test-weaviate-1          |      /go/src/github.com/semi-technologies/weaviate/adapters/repos/db/shard_read.go:178 +0x84b
test-weaviate-1          | github.com/semi-technologies/weaviate/adapters/repos/db.(*Index).objectVectorSearch.func1(0x146f401, 0xc000e538c0)
test-weaviate-1          |      /go/src/github.com/semi-technologies/weaviate/adapters/repos/db/index.go:562 +0x210
test-weaviate-1          | golang.org/x/sync/errgroup.(*Group).Go.func1(0xc000dc0390, 0xc000cf7800)
test-weaviate-1          |      /go/pkg/mod/golang.org/x/sync@v0.0.0-20210220032951-036812b2e83c/errgroup/errgroup.go:57 +0x59
test-weaviate-1          | created by golang.org/x/sync/errgroup.(*Group).Go
test-weaviate-1          |      /go/pkg/mod/golang.org/x/sync@v0.0.0-20210220032951-036812b2e83c/errgroup/errgroup.go:54 +0x66
test-weaviate-1 exited with code 2

It fails only if we have both where and nearText filters set, if the root operator is And and if the wildcard is at the end of the word (for the Like operator).
The filters separately work fine.
It seem to fail when you have for the Like a WORD* and you use it in both properties, and one of the properties have the WORD twice but one of them has more characters appended (the order does not matter). For example:

One property: one onet, second property: one, WORD: one
One property: something some, second property: some, WORD: some

NOTE: You could add more words to each property, does not matter where, before, after or in-between, or any combination, as long as one property has the WORD only and the other the WORD and the WORD with some appended characters. One of the properties should NOT contain the WORD with appended characters (otherwise it works). Here is a another object that has the same behaviour:
{
  'testOne': 'this is a test that tests something',
  'testTwo': 'this is a test for fun'
}
# the WORD is 'test'

This is everything I have found out. I hope it helps

closed in #1773


Fix ProvidersDocsGenerator

Codecov Report

Merging #405 (32c52d9) into main (f5ba992) will decrease coverage by 0.07%.
The diff coverage is n/a.

@@             Coverage Diff              @@
##               main     #405      +/-   ##
============================================
- Coverage     93.89%   93.81%   -0.08%
+ Complexity     1982     1979       -3
============================================
  Files           218      218
  Lines          3995     3995
  Branches        386      386
============================================
- Hits           3751     3748       -3
- Misses          146      151       +5
+ Partials         98       96       -2

Impacted Files
Coverage Δ

...ker/idnumbers/pt/br/IdNumberGeneratorPtBrUtil.java
92.59% <0.00%> (-3.71%)
:arrow_down:

.../main/java/net/datafaker/service/FakerContext.java
84.61% <0.00%> (-2.57%)
:arrow_down:

:mega: We’re building smart automated test selection to slash your CI/CD build times. Learn more


Compiling the field "name" in the addRecipient api doesn't updates the Subscriber name on Mailup

Hey @enrike1983!
You have to call MailingList::updateRecipient($recipient) instead of MailingList::addRecipient($recipient)

hi @massimilianobraglia thank you for the info. This means that the "name" parameter for addRecipient useless, shouldn't be better to remove it from that method?

Can you tell me where is the name parameter? MailingList::addRecipient() signature is the following:
    public function addRecipient(Recipient $recipient): Recipient

There is no name parameter

Sorry @massimilianobraglia , I meant that the "recipient" class accepts the "name" parameter in the constructor but that specific argument doesn't seems to be added/updated to the recipient entry in the Mailup list

@enrike1983 to update a recipient in a list first you have to retrieve it via the MailingList:: findRecipient() method and then use the MailingList::updateRecipient() method. The recipient construction just creates a new instance and then you have to use the MailingList::addRecipient to save it in MailUP


Update GameVersion enum and fix GenerateHash

Close #607
I found this information and confirmed backslash \ is replaced with slash / by GET_HASH_KEY.

Nice!

leftas told me that the highest gear supported by GTA V is 7 and confirmed too high gear values causes unexpected behavior, In other words, the game can't control gear values correctly. But 8 is supported by GTA V for vehicle gear values.

Aah, leftas and gp told me the 8th gear does not affect by the game, so I'll change Vehicle.HighGear again, not to accept the 8 value. https://m.imgur.com/a/aQTYT


[HOTFIX] Fixed random test failure

Be sure to do all of the following checklist to help us incorporate
your contribution quickly and easily:

[X] Any interfaces changed?
NA
[X] Any backward compatibility impacted?
NA
[X] Document update required?
NA
[X] Testing done
Please provide details on
- Whether new unit test cases have been added or why no new tests are required?
- How it is tested? Please attach test report.
- Is it a performance related change? Please attach the performance test report.
- Any additional information to help reviewers in testing this change.
corrected test case
[X] For large changes, please consider breaking it into sub-tasks under an umbrella JIRA.
NA

Build Failed  with Spark 2.1.0, Please check CI http://<IP_ADDRESS>:8080/job/ApacheCarbonPRBuilder1/7484/

Build Failed with Spark 2.2.1, Please check CI http://<IP_ADDRESS>:8080/job/ApacheCarbonPRBuilder/6242/

retest this please

Build Failed  with Spark 2.1.0, Please check CI http://<IP_ADDRESS>:8080/job/ApacheCarbonPRBuilder1/7498/

Build Failed with Spark 2.2.1, Please check CI http://<IP_ADDRESS>:8080/job/ApacheCarbonPRBuilder/6251/

Build Success with Spark 2.2.1, Please check CI http://<IP_ADDRESS>:8080/job/ApacheCarbonPRBuilder/6258/

Build Success with Spark 2.1.0, Please check CI http://<IP_ADDRESS>:8080/job/ApacheCarbonPRBuilder1/7531/

Build Success with Spark 2.2.1, Please check CI http://<IP_ADDRESS>:8080/job/ApacheCarbonPRBuilder/6285/

SDV Build Success , Please check CI http://<IP_ADDRESS>:8080/job/ApacheSDVTests/6011/

LGTM

Build Success with Spark 2.1.0, Please check CI http://<IP_ADDRESS>:8080/job/ApacheCarbonPRBuilder1/7570/

Build Success with Spark 2.2.1, Please check CI http://<IP_ADDRESS>:8080/job/ApacheCarbonPRBuilder/6325/

Build Success with Spark 2.2.1, Please check CI http://<IP_ADDRESS>:8080/job/ApacheCarbonPRBuilder/6329/

@mohammadshahidkhan Please add description


feat: LSDV-4915: Async import

1 I tried to run it in OS.
fflag_feat_all_lsdv_4915_async_task_import_13042023_short is enabled and tasks are not imported:
https://user-images.githubusercontent.com/501780/234166459-7e9d2362-f7dc-4e7b-99c0-8c03791b3b83.mp4

I tried to run it in ENT.

import csv / txt has a regression, compare these two screens (first - async import, second - app.heartex.com):


Rmrating and Add Null check in OwnerPageFragment

Closes #184
gets rid of ratings in view user profile UI
also add null check to OwnerPageFragment
Null pointer exception occurs if user has no books owned

The change is working properly. Thanks for figuring out the null error.

@samjwu Why comment the stuff out? Why not just delete it?

in case we still wanted it or something. there's no compelling reason

@samjwu Fair enough.


test.sh picks wrong base branch in CI

@sienna0127, it seems that your good deed is not going unpunished.  :(
https://github.com/RespiraWorks/VentilatorSoftware/pull/172 ran  the following Travis build: https://travis-ci.com/github/RespiraWorks/VentilatorSoftware/builds/162117852
This fails because it's trying to do git diff --name-only jlebar/ycm...HEAD, and the jlebar/ycm branch no  longer exists.
I'm not sure exactly what's going on.  It sort of seems that Travis has gotten confused by the fact that this PR is part of a chain.  jlebar/ycm was the first link in this chain, and #172 depended on it.  Up until I submitted jlebar/ycm, Travis was right to consider only jlebar/ycm...HEAD.  But now that it's submitted, it should be looking at master as the base.

Fixed by #176


Feat/support v8

Update to work with WDIO v8

Hey, can you run all checks inside pipeline.

Workflow is triggered on PR of Push to main branch. Did npm run test on local and all test passed

@christian-bromann, comments have been addressed in new commit

Thanks for the work @jelugbo , let's continue convo in  #113


Multiline comments are not highlighted correctly

Description
Multi-line comments are not highlighted correctly in diff views.
Actual behaviour
Example: commit aa72e3abf9644de3c0478692d7bb357d1c7297e2 in Blender

Another example in Go, to show that it's not limited to C/C++: https://try.gitea.io/drSybren/skyfill/commit/aa87c1c50db6dfd97ab53905097e43fce3c5568e
Expected behaviour
Expected would be to see the highlighting like done when viewing the file regularly (of course with red/green background for the added/removed lines in the diff):

Gitea Version
1.19.0+dev-649-g2093ca517
Can you reproduce the bug on the Gitea demo site?
Yes
Log Gist
No response
Screenshots
No response
Git Version
No response
Operating System
No response
How are you running Gitea?
Self-built from Git
Database
PostgreSQL

I guess it's caused by that Gitea renders the diff page line by line, then highlight doesn't work (the comments are processed line by line). That's why the comment highlight works for whole file rendering, but doesn't work for the diff/compare page.
Maybe related to:

#19684
#21970

looks that's because gitea hasn't checking language by file name and content like file view. but it's sound not a easy job (how to get file content ?). I'd like tag this issue as kind/enhancement instead of kind/bug .
ref:
https://github.com/go-gitea/gitea/blob/443dcc2db0676cae8b1b72c1b0b99e675c21177c/services/gitdiff/gitdiff.go#L1156-L1160

Not only a "language" problem, but the highlighter need all the lines together to do highlight correctly. Otherwise the when highlighter  sees the second line of the comment without /*, it doesn't know it's in the comment context.

Yes, the main reason is diff highlighting is line-by-line so all multiline stuff breaks. We should instead feed both the "before" and "after" documents separately to chroma and then use those highlighted lines to replace the lines with highlighted ones in the diff.

I'm pretty sure this issue is duplicate.

@silverwind Ive also seen it somewhere 👍

This problem is quite challenging. Because at the moment many Diff Lines are provided by git commands without highlight. If we want to highlight the file first then do the diff to get Diff Lines, then the diff code should be (nearly) totally rewritten.
There could be a intermediate solution: git provides the diff lines -> gitea parses the diff lines -> git merge (join) the diff lines as a temp file content and highlight it -> then gitea splits the highlighted content into lines as diff lines.
Correct me if I am wrong.

Could we highlight every section?
Storing the diff as a patch file may be useful for a second time CPU reduction.

@lunny what sections are youy talking about?

I mean the struct of DiffLineSectionInfo

@lunny if so, than I agree. Every section could (and should) be highlighted.

Could we highlight every section?

If you mean the diff "hunks": It would be an improvement, but will not completely fix the issue. A complete fix can only to be to highlight the whole "before" and "after" files and map back the highlighted lines into the reduced subset of diff lines.

Could we highlight every section?

That's my "an intermediate solution" above. However it is only an intermediate solution, you would still lose the correct context because the diff hunk may only content a few lines, there might be no /* in the hunk.

I doubt highlighting hunks as a whole will improve the situation much, I fear it may only make it worse.

hunks as a whole ... I fear it may only make it worse.

Yup, if the a hunk only contains /* but doesn't contain */, the remaining hunks are all rendered as "comment", not good.


Embed likes or views on Twitter/Youtube links

We'd probably want to compute this on a periodic basis in CI


Decrypted NSData has an extra character at the end

When decrypted, the NSData has often (not sure when exactly this happen) an extra character at the end, always a 7.
What am I doing wrong?
NSString *str = [[self convertToString:args] stringByTrimmingCharactersInSet:[NSCharacterSet whitespaceAndNewlineCharacterSet]];
NSData *decodedData = [self dataFromBase64String:paddedStr];

This is my code.

Is your decoded string properly padded with '=' symbols at the end?  If improperly padded, there could be errors in decoding the last character.

great catch! we had the padded '=' symbol converted to %3D by the webservice.
Thank you very much!


解码错误

Traceback (most recent call last):
File "/seu_share/home/qiguilin/230229361/.conda/envs/llama-chat/lib/python3.9/site-packages/datasets/packaged_modules/json/json.py", line 113, in _generate_tables
pa_table = paj.read_json(
File "pyarrow/_json.pyx", line 258, in pyarrow._json.read_json
File "pyarrow/error.pxi", line 144, in pyarrow.lib.pyarrow_internal_check_status
File "pyarrow/error.pxi", line 100, in pyarrow.lib.check_status
pyarrow.lib.ArrowInvalid: JSON parse error: Column(/input) was specified twice in row 397
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/seu_share/home/qiguilin/230229361/.conda/envs/llama-chat/lib/python3.9/site-packages/datasets/builder.py", line 1858, in _prepare_split_single
for _, table in generator:
File "/seu_share/home/qiguilin/230229361/.conda/envs/llama-chat/lib/python3.9/site-packages/datasets/packaged_modules/json/json.py", line 134, in _generate_tables
dataset = json.load(f)
File "/seu_share/home/qiguilin/230229361/.conda/envs/llama-chat/lib/python3.9/json/init.py", line 293, in load
return loads(fp.read(),
File "/seu_share/home/qiguilin/230229361/.conda/envs/llama-chat/lib/python3.9/codecs.py", line 322, in decode
(result, consumed) = self._buffer_decode(data, self.errors, final)
UnicodeDecodeError: 'utf-8' codec can't decode bytes in position 31457279-31457280: invalid continuation byte
我的文件都是用utf-8编码和解码，为什么还一直出现这样的问题？

你的文件有问题格式不对或者存在无法编码字符，就在31457279-31457280的位置

---- 回复的原邮件 ----

发件人
<EMAIL_ADDRESS>

日期
2023年07月02日 03:56

收件人
<EMAIL_ADDRESS>

抄送至
<EMAIL_ADDRESS>

主题
[zhangnn520/chinese_llama_alpaca_lora] 解码错误 (Issue #4)

Traceback (most recent call last):
File "/seu_share/home/qiguilin/230229361/.conda/envs/llama-chat/lib/python3.9/site-packages/datasets/packaged_modules/json/json.py", line 113, in _generate_tables
pa_table = paj.read_json(
File "pyarrow/_json.pyx", line 258, in pyarrow._json.read_json
File "pyarrow/error.pxi", line 144, in pyarrow.lib.pyarrow_internal_check_status
File "pyarrow/error.pxi", line 100, in pyarrow.lib.check_status
pyarrow.lib.ArrowInvalid: JSON parse error: Column(/input) was specified twice in row 397
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/seu_share/home/qiguilin/230229361/.conda/envs/llama-chat/lib/python3.9/site-packages/datasets/builder.py", line 1858, in _prepare_split_single
for _, table in generator:
File "/seu_share/home/qiguilin/230229361/.conda/envs/llama-chat/lib/python3.9/site-packages/datasets/packaged_modules/json/json.py", line 134, in _generate_tables
dataset = json.load(f)
File "/seu_share/home/qiguilin/230229361/.conda/envs/llama-chat/lib/python3.9/json/init.py", line 293, in load
return loads(fp.read(),
File "/seu_share/home/qiguilin/230229361/.conda/envs/llama-chat/lib/python3.9/codecs.py", line 322, in decode
(result, consumed) = self._buffer_decode(data, self.errors, final)
UnicodeDecodeError: 'utf-8' codec can't decode bytes in position 31457279-31457280: invalid continuation byte
我的文件都是用utf-8编码和解码，为什么还一直出现这样的问题？
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you are subscribed to this thread.Message ID<EMAIL_ADDRESS>


flattening HolographERC721Drop contract

Describe Changes
Flattening the HolographERC721Drop smart contract.

Removed dependency from lib folder.
Moved relevant interfaces to drops/interfaces dir.
Placed all relevant contracts inside the HolographERC721Drop contract.
Cleaned up references and code syntax.

Checklist before requesting a review

[x] I have performed a self-review of my code
[x] Code styles have been enforced
[ ] All Hardhat tests are passing
[ ] All Foundry tests are passing

This is looking good 👍


[Bug] Typo in DevRel with Kunal's name

Description
In  and  section, Kunal's last name is spelt wrong. It is supposed to be Kushwaha (afaik), but it is spelt Khushwaha there.
Screenshots

Additional information
No response

@thisisheymde image is not rendering, please fix that so we can confirm the issue

@kaiwalyakoparkar I've updated the original comment. Would you mind checking again please?

I would like to fix this issue

@kelvinparmar feel free to open a PR for the same


[FEATURE]: add order command

[ ] user can order café items: coffee, Tea, Snacks, Desserts
[ ] Image and a motivational post will be sent with the ordered item
[ ] user can also order those for someone else and leave them a message

This Idea I cancelled due to limited usage case


[Feature Request] An option to clear all novels from Library

Add an option to clear all novels from Library. I want to reset and sort novels from my library so this option would be nice specially custom sort still not yet been added

can confirm deleting the app data works.


tidy up Voronoi debugging and add heptagonal aoi to test

Codecov Report

Merging #236 (a213c50) into master (25cd994) will decrease coverage by 0.05%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master     #236      +/-   ##
==========================================
- Coverage   52.94%   52.89%   -0.06%
==========================================
  Files          53       53
  Lines       25686    25624      -62
==========================================
- Hits        13600    13554      -46
+ Misses      12086    12070      -16

Impacted Files
Coverage Δ

resqpy/olio/triangulation.py
91.73% <ø> (-1.16%)
:arrow_down:

resqpy/olio/simple_lines.py
40.65% <0.00%> (-0.48%)
:arrow_down:

resqpy/olio/wellspec_keywords.py
66.66% <0.00%> (-0.31%)
:arrow_down:

resqpy/olio/keyword_files.py
41.80% <0.00%> (-0.13%)
:arrow_down:

resqpy/olio/factors.py
97.14% <0.00%> (-0.08%)
:arrow_down:

resqpy/model.py
66.16% <0.00%> (-0.07%)
:arrow_down:

resqpy/olio/transmission.py
71.49% <0.00%> (-0.05%)
:arrow_down:

resqpy/lines.py
69.87% <0.00%> (-0.04%)
:arrow_down:

resqpy/grid_surface.py
80.68% <0.00%> (-0.03%)
:arrow_down:

... and 9 more

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 25cd994...a213c50. Read the comment docs.


remove backward compat checks for 0.8 proxies

Signed-off-by: Shriram Rajagopalan<EMAIL_ADDRESS>

@rshriram: The following test failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

prow/e2e-mixer-no_auth-mcp.sh
c6fc355fa05c97f23b45794a196d588c302000dc
link
/test e2e-mixer-no_auth-mcp

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

/test e2e-mixer-no_auth-mcp

/approve
/lgtm

[APPROVALNOTIFIER] This PR is APPROVED
This pull-request has been approved by: ijsnellf
The full list of commands accepted by this bot can be found here.
The pull request process is described here

Needs approval from an approver in each of these files:

pilot/pkg/networking/OWNERS [ijsnellf]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

New changes are detected. LGTM label has been removed.

@rshriram: The following test failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

prow/istio-pilot-e2e-envoyv2-v1alpha3-mcp.sh
16a58045a217ee5756737d15991a72278071773d
link
/test istio-pilot-e2e-envoyv2-v1alpha3-mcp

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.


metagenome data for testing

Airway metagenome data for testing can be obtained from ENA, Project PRJEB52640.
https://www.ebi.ac.uk/ena/browser/view/PRJEB52640?show=reads

@LisaHollstein for testing, please see two small fastqs I have been using for all stages at https://github.com/colindaven/ref_testing


Unable to install brackets on Ubuntu 20.xx (both via PPA and via .deb file)

Prerequisites

[x] Can you reproduce the problem with Debug -> Reload Without Extensions?
[x] Did you perform a cursory search to see if your bug or enhancement is already reported?
[x] Did you read the Troubleshooting guide?

For more information on how to write a good bug report read here
For more information on how to contribute read here
Description
It appears the PPA is not being maintained actively as it doesn't have versions mapped for Ubuntu 20.xx (Focal Fossa). Also, .deb file for version 1.14.1 downloaded from www.brackets.io is giving error with unmet dependencies without further details.
Steps to Reproduce

Tried installing via .deb file - no success. The .deb file for version 1.14.1 downloaded from www.brackets.io is giving the following error message with no details on the unmet dependencies. Decided to install via command line (details in the next step)

Tried the following steps from this link - https://github.com/adobe/brackets/wiki/Brackets-Linux-Guide

Solution 2: Install from PPA
Ubuntu has a PPA for Brackets installs which will automatically import libcrypt11 while also keeping Brackets up to date automatically. To install from PPA, open a terminal and then:
sudo add-apt-repository ppa:webupd8team/brackets
    If asked to install key say “yes”
sudo apt-get update
sudo apt-get install brackets

404 Error when trying to update the newly added PPA repository saying no release file linked to the current version of Ubuntu (focal fossa)

Expected behavior:
The installation would proceed and complete as normal with either of these solutions provided.
Actual behavior:
Installation fails with
a) An error message with "unmet dependencies" without listing the names of packages/unmet dependencies (this could possibly be due to an issue with Ubuntu's error message alert within Software Center with the actual message containing details of packages/unmet dependencies being truncated - unsure though so maybe someone else could validate this).
b) Alternate solution to install via PPA fails as well due to 404 error when attempting to update the repo for Ubuntu's latest release (focal fossa) not being mapped correctly within the repository
Versions
Please include the OS and what version of the OS you're running.
Ubuntu 20.04 running on Virtual box 6.1.8 on Win 10 Pro 64-bit

Please include the version of Brackets. You can find it under Help -> About Brackets (Windows and Linux) or Brackets -> About Brackets (macOS)
Trying to install current Brackets version 1.14.1

sudo snap install brackets --classic

I posted a workaround here https://github.com/adobe/brackets/issues/15151#issue-619571301
Working on Debian 10 aka buster

Ran into the same problem and almost just gave up trying to use the program.
Pity it does not install on the current LTS version of the most common Linux distribution without workarounds or methods not documented on the download page.

Also the official linux guide for Brackets has not been updated in almost 3 years.

Revision history says it was last updated on 27-Sep-2017 as of Oct 2020.
Could you please add a note there to say the wiki is outdated and the steps mentioned in that wiki are no longer valid for Brackets ver. 1.14.x / Ubuntu ver. 20.04.xx LTS


Bundle URLs as assets

Upgrade Emscripten to 2.0.21. Few notes:
- Lots of deprecated SIMD intrinsic warnings & errors in JPEG-XL -> Highway; had to suppress erorrs to make project build.
- Moved couple of common link flags to cpp.Dockerfile (note: can't move EXPORT_ES6 otherwise configure will fail).
- MODULARIZE=1 is no longer necessary and implied by EXPORT_ES6.
- EXPORT_NAME=... is no longer necessary in EXPORT_ES6.
- Changed visdif to also use EXPORT_ES6 and ENVIRONMENT=node instead of generic JS.

Update wasm-bindgen.

Bundle URL assets as dependencies
I've added support for new URL(..., import.meta.url) pattern accepted by many bundlers to wasm-bindgen and Emscripten, both for Wasm files as well as for side Workers autogenerated to support multithreading.
On the apps side like Squoosh this means we no longer have to manually specify URLs to be passed to wasm-bindgen or Emscripten init functions. In this PR I'm primarily doing just that - removing all the manual Wasm URL locators, as well as the associated logic.
One notable change on the build system side is that, in order for Wasm and multithreading-related Workers to be detected as dependencies, I'm now walking over referencedFiles in addition to imports when collecting list of dependencies in getDependencies function (client-bundle-plugin.js).
As a side effect, it also included other linked assets - images and CSS - which simplified quite a few caching lists in to-cache.ts as well. Instead of having to manually specify each asset that needs to be included, the logic is inverted and only few extra assets had to be excluded to keep the list of in items cached on the first load as low as it was before the change.
All in all, I think this simplification is worth it and even helped to accidentally uncover & fix one caching bug where WP2 regular JS was cached in addition to WP2 multithreaded JS simultaneously.

I'll recheck the Wasm sizes, those look wrong.

Okay so I am all in favor of upgrading to Emscripten 2.0.21.
As for the URL("some-file.png", import.meta.url) pattern to signal an an asset, I am not sure. I really dislike that it diverges from the semantics of the platform here. But Imma yield to @jakearchibald here because it’s his area.
(As in, if it was up to me, I’d prefer we continue to explicitly import assets with url: prefix.)

I really dislike that it diverges from the semantics of the platform here

How so? It aligns with the platform in that the new URL is valid both before and after the bundling; the job of bundler is just to keep code working, and this is a pattern they currently agreed on as statically analysable.

I'll recheck the Wasm sizes, those look wrong.

I've rechecked, those reproduce even with just Emscripten upgrade with no other changes.
I can only presume that the -O3 which we use for speed reasons (it gave significant boost to codecs like AVIF in the past) got "better" at inling or unrolling loops or something else which now causes it to produce a much bigger code - given that there was a major LLVM bump in-between, this seems likely but cc @kripken in case 20-30% size increase is suspicious.

the job of bundler is just to keep code working

That’s an interesting interpretation. I can get behind that. I was worried about accidentally triggering asset creation where I didn’t mean to, but that still doesn’t affect runtime performance really...

I was worried about accidentally triggering asset creation where I didn’t mean to

Ah yeah, I think it's pretty hard to do that by accident given how explicit the pattern is. I'd agree if it was crawling all the strings that look like URLs, but new URL('...', import.meta.url) is almost like static syntax in terms of explicitness.
I hope import.meta.resolve proposal comes through and pushes it even further in future though.

those reproduce even with just Emscripten upgrade with no other changes.
I can only presume that the -O3 which we use for speed reasons (it gave significant boost to codecs like AVIF in the past) got "better" at inling or unrolling loops or something else which now causes it to produce a much bigger code - given that there was a major LLVM bump in-between, this seems likely but cc @kripken in case 20-30% size increase is suspicious.

In 2.0.17 LLVM switches to the new pass manager, which might explain this. Can maybe do a quick bisect to verify.

In 2.0.17 LLVM switches to the new pass manager, which might explain this.

Do you think the explanation would be "it's a new optimisation" or "it's a regression bug / side-effect of the new pass manager"?

Could be either, really... new pipeline of optimizations, with new heuristics. Sometimes better, sometimes worse.

I just checked the speed of AVIF with standard params, and looks like it barely changed (~7-8% improvement but could be just noise since those are one-off runs). Maybe some more niche code paths did get better, idk.
@kripken I guess what I meant to ask is, whether this sort of size increase (20-30% seems pretty significant) is considered a regression or a problem at all by LLVM, or whether size increases at O3 are ignored as a natural artifact of optimisations and aren't tracked closely.

I don't work enough with LLVM and the LLVM community to be sure of how they are treating regressions. We saw a few (smaller) regressions on the emscripten benchmark suite, but decided not to file issues as the results were mixed (some things did get faster, and some got smaller). But 20-30% larger with no benefit might be worth a bug - I'd file one, worst case it won't get much attention. If you file one, a bloaty diff might be interesting to help the discussion there.

Sounds reasonable. Just to double-check - by "a bloaty diff" do you mean https://github.com/google/bloaty?

Yes.

In 2.0.17 LLVM switches to the new pass manager, which might explain this.

Ha, that doesn't seem to be it. Looks like 2.0.16 produced even slightly larger binaries. Continuing...

Okay, finished bisect. Looks like there was a bunch of size changes over the versions.
Over the whole 2.0.12-2.0.21 range increased avif_enc.wasm increased by 122KB total. However, a single 2.0.11-2.0.12 bump contributed 311KB and looks most suspicious.

Hmm, 2.0.12 Changelog doesn't look like much, but I wonder if it's the CMake change that caused this? (by the sound of it, it started passing -O3 to the CMake where it would previously pass -O2?)

Yes, if you set it, then the default should be ignored. So maybe it's not that.
Can you bisect into the release? The link I gave before shows how. It's pretty easy I think, basically just do emsdk install HASH a few times as you bisect over a side repo. That would give us the specific roll that regressed here. It's a super-useful technique that we are using in more and more bug reports.
https://emscripten.org/docs/contributing/developers_guide.html#bisecting

I think I saw Sam mentioning somewhere that emsdk install doesn't work in Docker? I guess I could try to build outside by copying the flags, just want to make sure I don't introduce impurities into comparisons.

I'm not aware of such an issue, but I do not know the details of how the emscripten docker image works, so it could be.

I don't think I can spend time going into bisecting individual Emscripten commits, so raised an issue upstream instead now that it's confirmed that the size increase is coming somewhere from Emscripten itself: https://github.com/emscripten-core/emscripten/issues/14282

Ok so what should we do here next? It looks like sizes are an unfortunate but legitimate side-effect of upgrade (and different optimisations in LLVM upstream).
We can switch back to optimisation mode with smaller sizes, but then we lose encoding speed. Should I try and experiment with more modes and wait with this PR for now?

Should I try and experiment with more modes and wait with this PR for now?

Trying one more thing, fingers crossed...

Yeah no, tried to switch to the legacy pass manager, but that increased size even more.

Ok so what should we do here next? It looks like sizes are an unfortunate but legitimate side-effect of upgrade (and different optimisations in LLVM upstream).

Can you summarise why the increases are legitimate? As in, what are we winning for the size increase?
@surma what do you think? A 10%-30% increase on pretty much all our wasm seems pretty hefty, especially if we don't gain anything from it. But if it's our only way to stay up to date with emscripten, and they don't see the size increase as an issue, I'm not sure we have any other choice.

Can you summarise why the increases are legitimate? As in, what are we winning for the size increase?

Maybe "legitimate" is not the right word. What I meant is that it's not a bug in the build system, but rather LLVM trying to optimise even more in newer versions, and inlining more functions into each other. Unfortunately, this time we don't win any noticeable performance gains (at least as far as I can tell from my quick tests at default settings).
I don't like the size increase either, which is why I raised the issue on Emscripten side which was tracked down to LLVM upgrade, but then there's not much we can do because size increase is expected at -O3.
We can revert to -Os like before https://github.com/GoogleChromeLabs/squoosh/pull/838 & co., but then we lose the original speed gains as well. I'd love to figure out if there's a specific LLVM pass we could disable to get previous perf gains without the size increase, but doesn't look so either - it's just that implementation of inlining changed under the hood, so it's "all or nothing" sort of situation.

Yeah, this is a tough one... It’s a one-off download that we cache, it’s not part of the critical loading path, we don’t update codecs that frequently. I think we can get away with it. Especially because codecs are our main performance bottle neck right now.
(Part of the problem is probably that in native land — and therefore from LLVMs perspective — bigger binary size for speed is a cheap tradeoff.

I'm happy if you're happy @surma. Eventually we should make codec downloading opt-in, especially if they continue to get bigger, and we add more.

Eventually we should make codec downloading opt-in

At the very least, we could probably respect the Save-Data mode (that Chrome Lite & other similar implementations send) and download things lazily in that mode instead of trying to make Squoosh work offline. But it's out of scope of this PR.

I'm happy if you're happy @surma.

@jakearchibald just fyi - I can't merge this until you change your review on the PR.


Extend parameter parsing functions documentation

Description
Closes #2465.

Readiness checklist

[ ] I added/updated unit tests.
[x] I added/updated integration/compatibility tests.
[x] I added/updated comments and checked rendering.
[x] I made spot refactorings.
[ ] I updated user documentation.
[ ] I ran task all, and it passed.
[x] I ensured that PR title is good enough for the changelog.
[x] (for maintainers only) I set Reviewers (@FerretDB/core), Labels, Project and project's Sprint fields.
[x] I marked all done items in this checklist.

On hold until after 1.2.0 release


Missing rows prediction

row and column detection model missing onto some rows. Because of which end result of HTML table does not contain the contents of that row. Any possible workaround to add missing rows after?

There is no work around for adding missing rows or correcting predictions. You need to do this by hand after processing.
However, there are various config options available that you might tweak to get better results for your type of documents your are dealing with. The configuration was adjusted to achieve as few crashes in the analyzer process as possible. But it does not mean they are optimal for your use case.
In conf_dd_one.yaml increase:
 SEGMENTATION.IOU_THRESHOLD_ROWS or
 SEGMENTATION.IOA_THRESHOLD_ROWS.

You will also need to increase the config setting in row predictor, e.g.
MODEL.ROI_HEADS.NMS_THRESH_TEST for Pytorch. config file: CASCADE_RCNN_R_50_FPN_GN.yaml

or
OUTPUT.FRCNN_NMS_THRESH for Tensorflow. config file: conf_frcnn_rows-yaml

For documents that differ from the training set, the analyzer tends to propose too many rows. In order to deal with that situation, the segmentation removes rows with low confidence score and intersection with other rows.
I am currently preparing integration of https://github.com/microsoft/table-transformer . It will be ready in a couple of days and will allow you to try another model.
These are the options if you do not want to fine tune the model on your own data.

Thanks.
One logic I am thinking is like finding predicted cells which are not overlapped with predicted rows and for non overlapped cells will add row bounding box by taking reference of non overlapped cells position.
Let me try this logic and will confirm if it is working or not and will post code if it is working.

One logic I am thinking is like finding predicted cells which are not overlapped with predicted rows and for non overlapped cells will add row bounding box by taking reference of non overlapped cells position.
Let me try this logic and will confirm if it is working or not and will post code if it is working.


Correct wrong buffer size.

Buffer size is too short.
in cpp. need 28 byte.
for (count = 0; count < 28; count++) {  // first 28 bytes we can process like this
compParams.compArray[count] = Wire.readb();
}

See https://github.com/embeddedadventures/BME280/issues/5, it should be 24, the next read is also 1 byte short for the H6 cal data


facter: 3.14.14 -> 3.14.15

Automatic update generated by nixpkgs-update tools. This update was made based on information from https://repology.org/metapackage/facter/versions.
meta.description for facter is: "A system inventory tool"
meta.homepage for facter is: "https://github.com/puppetlabs/facter"
meta.changelog for facter is: ""
Updates performed

Version update

To inspect upstream changes

Compare changes on GitHub

Impact

Checks done (click to expand)

built on NixOS

The tests defined in passthru.tests, if any, passed

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 3.14.15 with grep in /nix/store/a0i8n3am3gvlkbwgk27p4hsxhwgqbrnf-facter-3.14.15

directory tree listing: https://gist.github.com/18d07bb78d70a499b9b47bc9af5109fe

du listing: https://gist.github.com/14e973ccd66bb7347994b4fc33df1d82

Rebuild report (if merged into master) (click to expand)

4 total rebuild path(s)

1 package rebuild(s)

1 x86_64-linux rebuild(s)
1 i686-linux rebuild(s)
1 x86_64-darwin rebuild(s)
1 aarch64-linux rebuild(s)

First fifty rebuilds by attrpath
facter

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/a0i8n3am3gvlkbwgk27p4hsxhwgqbrnf-facter-3.14.15 \
  --option binary-caches 'https://cache.nixos.org/ https://nix-community.cachix.org/' \
  --option trusted-public-keys '
  nix-community.cachix.org-1:mB9FSh9qf2dCimDSUo8Zy7bkq5CX+/rkCWyvRCYg3Fs=
  cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY=
  '

(The Cachix cache is only trusted for this store-path realization.)
For the Cachix download to work, your user must be in the trusted-users list or you can use sudo since root is effectively trusted.
Or, build yourself:
nix-build -A facter https://github.com/r-ryantm/nixpkgs/archive/402b1e3267621ef7fd0397ac69ebb5ba61c9e936.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/a0i8n3am3gvlkbwgk27p4hsxhwgqbrnf-facter-3.14.15
ls -la /nix/store/a0i8n3am3gvlkbwgk27p4hsxhwgqbrnf-facter-3.14.15/bin

Pre-merge build results
We have automatically built all packages that will get rebuilt due to
this change.
This gives evidence on whether the upgrade will break dependent packages.
Note sometimes packages show up as failed to build independent of the
change, simply because they are already broken on the target branch.
Result of nixpkgs-review run on x86_64-linux 1

1 package built:

facter

Maintainer pings
cc @womfoo for testing.


Fix "submitted date" on caseworker email

Ticket
N/A - Bug report in slack
Changes
We used transmitted_at by accident, but that won't be set until the
email succeeds at sending. Let's use consented_to_authorized_use_at
instead, which represents the time we should initially consider the CBV
flow "complete" and that it is ready to transmit.
Context for reviewers
N/A
Testing
Screenshot of the mailer preview below.


Fix typo in text

Fix typo in the word "s everal" to "several".

[x] I have read freeCodeCamp's contribution guidelines.
[x] My pull request has a descriptive title (not a vague title like Update index.md)
[x] My pull request targets the master branch of freeCodeCamp.
[x] None of my changes are plagiarized from another source without proper attribution.
[x] My article does not contain shortened URLs or affiliate links.

If your pull request closes a GitHub issue, replace the XXXXX below with the issue number.
Closes #XXXXX

Closed and Reopened this PR to attempt to resolve a specific Travis build failure.