Title and mail body will both use encoding UTF-8 or UTF8 with BOM.?

mail Title and body will both default convert to use encoding  UTF8 with BOM.?
nice work~！
When the title and body of the email are in Chinese, they appear as gibberish.
Subject =?us-ascii?Q?Oracle=3F=3F=3F=3F=3F=3F=3F=3F=3F=3F?=
Is it in UTF-8 format? Or GBK?

Could there be an option to view attachments next to the download button, allowing direct viewing in the browser without having to download the clicked attachment?

Hi @tqangxl. I believe you already asked the same question in #389, and I answered you here but you did not respond. Did I not understand your question, or did you not understand my answers?

Is all your content encoded in UTF-8 by default, including email subjects, email bodies, and attachments? Will they all be displayed in UTF-8? Thank you. Also, could you add a feature to view the content attachments?

The data (HTML) is transmitted using UTF-8, however I believe your problem is that your emails are not encoded correctly (you should not be using ASCII). Can you please paste here the subject you are tying to encode? I do not mean the encoded version in the email (?us-ascii?Q?Oracle=3F=3F=3F=3F=3F=3F=3F=3F=3F=3F?=), but the actual content of the subject (eg: 这是主题)?
As for the attachments:

Your browser can only open the file formats it supports - if the browser does not support the format (eg: .man) then it will try download the file instead. Mailpit does not convert attachment formats into something your browser can understand (there are literally thousands of file formats).


Google sign in/sign up added

Hi @vishalverma9572 ,
I have added a google sign in option on the sign up and sign in page of your home page.
This is powered by firebase console.
Please refer the READme file for details on how to run it.

issue #113 resolved.
Please review the changes and update me if any changes are required or please proceed to merge my pr.
Thanks!

@ParvamShah1 , There is some issue in npm run build. let me have a look carefully.


merge from template-arlac77-github

.github/workflows/ci.yml

chore(deps): remove 18.18.2 (jobs.test-node.strategy.matrix.node-version)

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 99.206%

Totals

Change from base Build<PHONE_NUMBER>:
0.0%

Covered Lines:
109

Relevant Lines:
109

💛  - Coveralls


Implement rand::RngCore for Rng

This PR implements rand's RngCore trait for Rng. This will not have an additional cost for those depending on the HAL, but does allow generic drivers and libraries. The embedded-hal rng::Read trait is not final and is currently feature-gated, while RngCore has more widespread adoption.

Hey @chocol4te, could you please open the formatting into another PR? That will make this change easier to review (but will also cause merge conflicts for all other open PRs).
I'll try and land at least the temperature PR now to avoid some of the conflicts.

Also, I'm generally positive on using cargo fmt, but you might get some (reasonable) resistance from @hannobraun :)
I agree with him it can make some code less readable, but in general I am personally okay with the tradeoff.

Ah okay :D


Try to replace skeleton construction in contrast calculation with pure outlines as the basis

Looking for a great speed improvement here, as well as dependency reduction.
Since the algo runs on a skeleton outline in the end, which is expensive to calculate, might as well use the original glyph outline. Might be tons faster

@behdad PTAL :)

I haven't been able to come up with an algorithm for contrast calculation yet. Will keep thinking about it.

My thoughts: Currently I'm using an algorithm that renders the glyph into a pixel image, then finds the skeleton line, converts that back into a Bezier path and then uses that to shoot rays perpendicular to it through the glyph outlines and calculate stroke width from the nearest intersections.
But if we're only using simple round glyphs such as o, we could actually skip the entire first step and use either the inner or the outer outline as the basis for perpendicular rays, because those are actually quite similar to the skeleton line, only at a bit of an offset.
And I've already resorted to using only simple glyphs for this as stroke intersections throw off the readings, so might as well skip the entire pixel image stage.

And I've already resorted to using only simple glyphs for this as stroke intersections throw off the readings, so might as well skip the entire pixel image stage.

In that case it will work, yes. But if you have any glyphs with serifs, it would throw it off.

I was able to optimize the code to be roughly 4x faster.
First of all, a simple programming mistake caused this extensive measurement function to be called twice for each instance.
Then I indeed discarded the creation of the skeleton line via a pixel image, which saves ~2s per run but didn't achieve so much in terms of relative performance increase because so many measurements are performed afterwards. I was hoping this to have a greater impact, but it didn't. So we could actually consider to return to it later if necessary.
I have yet to implement a longer list of characteristic characters to measure for each script. When I do, I will have to test if the algo without skeleton line indeed performs well in all situations. It works perfectly for a simple o, but I have yet to test how it would work on an Arabic ٥ or similar that could possible have a thicker stroke at the top that could throw off the reading, even though I'm stripping outliers. This is still pending.
Then I simply turned the measurement precision down to achieve much faster results.
Below is a cProfile rundown of the a few dozen of the heaviest calculations, and it shows that it's all out of my scope to optimize. Particularly @simoncozens bezier.py tool is calculation-heavy.
I suggest that we continue to monitor the expressiveness of the results, and if the interest to use this metric remains strong and the current performance remains insufficient, to implement the heaviest calculations in C, which I've never done before, so we might want to ask someone for help.
         7105361 function calls (7005234 primitive calls) in 2.503 seconds

   Ordered by: internal time

   ncalls  tottime  percall  cumtime  percall filename:lineno(function)
    51760    0.125    0.000    0.125    0.000 site-packages/beziers/affinetransformation.py:33(apply_backwards)
   207040    0.111    0.000    0.144    0.000 site-packages/beziers/point.py:156(transformed)
   485036    0.080    0.000    0.080    0.000 site-packages/beziers/point.py:35(__init__)
    51760    0.070    0.000    0.406    0.000 site-packages/beziers/segment.py:146(alignmentTransformation)
    51929    0.066    0.000    1.110    0.000 site-packages/beziers/utils/intersectionsmixin.py:29(intersections)
    51760    0.061    0.000    0.123    0.000 site-packages/beziers/quadraticbezier.py:66(_findRoots)
658317/654448    0.060    0.000    0.098    0.000 {built-in method builtins.isinstance}
    51760    0.056    0.000    0.310    0.000 site-packages/beziers/segment.py:139(transformed)
667859/581036    0.047    0.000    0.063    0.000 {built-in method builtins.len}
   163086    0.046    0.000    0.073    0.000 site-packages/beziers/point.py:89(clone)
    51760    0.046    0.000    0.892    0.000 site-packages/beziers/utils/intersectionsmixin.py:93(_curve_line_intersections_t)
    51760    0.043    0.000    0.061    0.000 site-packages/beziers/affinetransformation.py:80(rotation)
   155280    0.042    0.000    0.147    0.000 site-packages/beziers/point.py:165(transform)
   492110    0.039    0.000    0.039    0.000 site-packages/beziers/segment.py:39(__getitem__)
    11633    0.038    0.000    0.129    0.000 site-packages/pandas/core/construction.py:518(sanitize_array)
     6759    0.037    0.000    0.178    0.000 site-packages/pandas/core/indexes/base.py:477(__new__)
        1    0.034    0.034    2.493    2.493 /Users/yanone/Code/Github/fontquant/Lib/fontquant/helpers/stroke_contrast.py:68(stroke_contrast)
    51760    0.033    0.000    0.037    0.000 site-packages/beziers/utils/__init__.py:8(quadraticRoots)
    23142    0.033    0.000    0.048    0.000 site-packages/beziers/quadraticbezier.py:25(pointAtTime)
    51760    0.032    0.000    0.973    0.000 site-packages/beziers/utils/intersectionsmixin.py:99(_curve_line_intersections)
    51760    0.031    0.000    0.217    0.000 site-packages/beziers/affinetransformation.py:88(rotate)
    51760    0.030    0.000    0.099    0.000 site-packages/beziers/segment.py:142(<listcomp>)
4415/4324    0.027    0.000    0.214    0.000 site-packages/pandas/core/series.py:371(__init__)
     1889    0.025    0.000    0.166    0.000 site-packages/pandas/core/internals/concat.py:94(concatenate_managers)
    14768    0.024    0.000    0.048    0.000 {pandas._libs.lib.maybe_convert_objects}
    61880    0.024    0.000    0.034    0.000 site-packages/beziers/point.py:57(__mul__)
    12884    0.021    0.000    0.036    0.000 site-packages/pandas/core/generic.py:6147(__finalize__)
    15229    0.020    0.000    0.024    0.000 site-packages/pandas/core/generic.py:274(__init__)
    51760    0.019    0.000    0.024    0.000 site-packages/beziers/affinetransformation.py:46(translation)
8100/1980    0.019    0.000    0.091    0.000 site-packages/pandas/core/internals/blocks.py:533(convert)
    44189    0.017    0.000    0.083    0.000 {built-in method builtins.all}
    14768    0.015    0.000    0.023    0.000 site-packages/numpy/core/numeric.py:274(full)
    62027    0.015    0.000    0.032    0.000 site-packages/pandas/core/dtypes/generic.py:42(_instancecheck)
    81749    0.014    0.000    0.019    0.000 site-packages/pandas/core/indexes/base.py:908(__len__)
     1889    0.013    0.000    0.890    0.000 site-packages/pandas/core/frame.py:10182(_append)
     1980    0.013    0.000    1.049    0.001 site-packages/pandas/core/indexing.py:2141(_setitem_with_indexer_missing)
    11690    0.013    0.000    0.028    0.000 site-packages/pandas/core/internals/concat.py:389(is_na)
    62027    0.013    0.000    0.017    0.000 site-packages/pandas/core/dtypes/generic.py:37(_check)
    53651    0.013    0.000    0.017    0.000 site-packages/beziers/point.py:117(angle)
     1889    0.013    0.000    0.050    0.000 site-packages/pandas/core/internals/concat.py:296(_get_combined_plan)
     4144    0.012    0.000    0.121    0.000 site-packages/pandas/core/internals/managers.py:308(apply)
    10720    0.012    0.000    0.019    0.000 site-packages/pandas/core/indexes/base.py:648(_simple_new)
    10572    0.011    0.000    0.035    0.000 site-packages/pandas/core/generic.py:6206(__setattr__)
     1889    0.011    0.000    0.327    0.000 site-packages/pandas/core/reshape/concat.py:618(get_result)
   103520    0.010    0.000    0.010    0.000 site-packages/beziers/affinetransformation.py:5(__init__)
    11690    0.010    0.000    0.014    0.000 site-packages/pandas/core/internals/concat.py:322(_get_block_for_concat_plan)
     1980    0.010    0.000    0.032    0.000 site-packages/pandas/core/internals/construction.py:237(ndarray_to_mgr)
    12606    0.010    0.000    0.017    0.000 site-packages/pandas/core/internals/blocks.py:2317(maybe_coerce_values)
    27922    0.010    0.000    0.011    0.000 site-packages/pandas/core/construction.py:484(ensure_wrapped_if_datetimelike)
     1980    0.010    0.000    0.192    0.000 site-packages/pandas/core/frame.py:3575(transpose)
     4048    0.009    0.000    0.041    0.000 site-packages/pandas/core/indexes/base.py:5518(equals)
     7620    0.009    0.000    0.013    0.000 site-packages/beziers/line.py:55(tOfPoint)
     6304    0.009    0.000    0.011    0.000 site-packages/pandas/core/dtypes/cast.py:1544(construct_1d_object_array_from_listlike)
     4870    0.008    0.000    0.024    0.000 site-packages/pandas/core/dtypes/common.py:1587(pandas_dtype)

Ported the algo over to kurbopy. It's now ~33% faster, sadly not more. Turns out that pandas is now the bottleneck which I rely on for data handling generally, but outlier removal specifically.
A next optimization step could be to replace the outlier removal with an optimized algo.

And so I'm putting this issue to rest. I think we've reached the optimum efficiency here. Thanks everyone.


Create wf_invalid_v_column.dig

I create workflow sample in order to invalid 'Include v column in 'SELECT *' and change directory under scenarios.
I will create README.md later.

#165 is merged.


"Mașloc", "Alioș" and "Remetea Mică" are listed in the drop-down menu

Description:
"Mașloc", "Alioș" and "Remetea Mică" are listed in the drop-down menu alongside its corresponding county and commune, according to the law
Precondition:
The website is up an running.

Step 1
Type "Mașloc" in the search bar.

Expected results
The location is listed in the drop-down menu as "Sat Mașloc, TIMIȘ (Mașloc)" and "Comuna Mașloc, TIMIȘ".

Step 2
Press "x" button.

Expected results
The location was deleted from the search bar.

Step 4
Press "x" button.

Expected results
The location was deleted from the search bar.

Step 5
Type "Remetea Mică" in the search bar.

Expected results
The location is listed in the drop-down menu as "Sat Remetea Mică, TIMIȘ (Mașloc)".


Roll Flutter Engine from debee7cece49 to c4be7372be7e (1 revision)

https://github.com/flutter/engine/compare/debee7cece49...c4be7372be7e
2023-06-26<EMAIL_ADDRESS>Implement union and intersection for DlRegion (flutter/engine#42620)
If this roll has caused a breakage, revert this CL and stop the roller
using the controls here:
https://autoroll.skia.org/r/flutter-engine-flutter-autoroll
Please CC jsimmons@google.com,rmistry<EMAIL_ADDRESS>on the revert to ensure that a human
is aware of the problem.
To file a bug in Flutter: https://github.com/flutter/flutter/issues/new/choose
To report a problem with the AutoRoller itself, please file a bug:
https://bugs.chromium.org/p/skia/issues/entry?template=Autoroller+Bug
Documentation for the AutoRoller is here:
https://skia.googlesource.com/buildbot/+doc/main/autoroll/README.md

Commit queue failed; closing this roll.


Make all dragging actions abortable with right click(Select-Tool)

fixes only for the select-tool-part of #1912

!build


fix: rds cluster deletion protection rule

Changes proposed in this pull request:

fix wrong rule for var check_rds_cluster_deletion_protection_enabled. It should create deletion protection rule for rds cluster RDS_CLUSTER_DELETION_PROTECTION_ENABLED but instead it was creating RDS_SNAPSHOT_ENCRYPTED rule

https://docs.aws.amazon.com/config/latest/developerguide/rds-instance-deletion-protection-enabled.html

@jsarnovsky @sheenamt can you check this pls? :)

Shipped in v7.0.0. Thank you!


"value" cannot be passed as a hex string on a SendTransaction request

If I have a smart contract function that is payable I need to set a value field in the JSON object of the request body for a SendTransaction request.
Today if I set this to a string like this:
{
  "value": "0x01"
}

I get the following result in the FireFly explorer:
{
	"id": "default:25a46a6d-961a-47e2-a7e0-5e3aaeb431f3",
	"message": "json: invalid number literal, trying to unmarshal \"\\\"0x01\\\"\" into Number",
	"success": false
}

I think some of the backslash escaping craziness there is actually just added by the UI.
Ethconnect logs the following:
[2022-06-15T12:57:33.507Z]  WARN Failed to process message MsgContext[SendTransaction/default:25a46a6d-961a-47e2-a7e0-5e3aaeb431f3]: json: invalid number literal, trying to unmarshal "\"0x01\"" into Number

That’s certainly the behaviour as designed today. That those inputs a base 10. The new FFTM connector toolkit is more permissive, using the utility helper FFBigInt from firefly-common.
A PR for an enhancement to also support base16 numbers in ethconnect would be cool.

It does let me pass value as a string though, as long as it is base 10, so I can still express large numbers which is good.

Yep - I think it uses the “json.Number” string type today


RYA-148 Fixed a bug where Joins would write the same binding set with…

… different visibility orders depending on which child node the new result appeared on.

:+1:

Merged.


add dog breed classification web-app

i made a web-app which take photo of dog and classify which dog is this
Fixes #1011
Please review my pr

@agarwalhimanshugaya looks like code copied from another program..

@invigorzz313 no sr i made it but take support from other places

@agarwalhimanshugaya then you might remove the program name(s) from the readme.md file.


Transfer Hook: Off-chain and on-chain helpers are resolving keys incorrectly

Problem
Token2022's off-chain and on-chain helpers for adding the necessary extra account metas for a transfer instruction that requires a transfer hook are missing a crucial step.
Note: This crucial step is missing only from the helpers, thus the on-chain program itself needs no change.
At the bottom of this issue is a test. In it, we're going to build instructions with extra account metas in three ways:

Adding extra metas to a TransferChecked instruction using the Token2022 off-chain helper
Adding extra metas to an Execute instruction using the TLV Account Resolution library's add_to_instruction
Adding extra metas to an Execute CPI instruction using the TLV Account Resolution library's add_to_cpi_instruction

As you can probably infer, the issue is that we are adding the extra metas to a transfer instruction, rather than an Execute instruction.
Consider the instruction keys for TransferChecked (simplified):

[w] Source
[] Mint
[w] Destination
[s] Owner

Now consider the instruction keys as defined in the SPL Transfer Hook Interface's Execute instruction:

[] Source
[] Mint
[] Destination
[] Owner
[] Validation account

As you can see, Execute requires the validation (extra metas) account, while TransferChecked does not.
When extra account metas are hard-coded addresses, ie. ExtraAccountMeta::new_with_pubkey(..), this is not an issue. However, once any extra account meta uses seed configurations that point to other account keys in the list, this difference in account keys bungles the whole resolution.
The problem here is that, at the time of account resolution, the list of account keys for a transfer instruction and the list of account keys for an Execute instruction will yield entirely different resolutions.
For example, if I have a PDA that's based off of the account at index 4, that will be two different accounts depending on the instruction. No bueno.
Consider the test.
const TRANSFER_HOOK_PROGRAM_ID: Pubkey = Pubkey::new_from_array([1; 32]);

const MINT_PUBKEY: Pubkey = Pubkey::new_from_array([2; 32]);

const MOCK_MINT_STATE: [u8; 234] = [
    0, 0, 0, 0, // COption (4): None = 0
    0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
    0, 0, // Mint authority (32)
    0, 0, 0, 0, 0, 0, 0, 0, // Supply (8)
    0, // Decimals (1)
    1, // Is initialized (1)
    0, 0, 0, 0, // COption (4): None = 0
    0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
    0, 0, // Freeze authority (32)
    0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
    0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
    0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, // Padding (83)
    1, // Account type (1): Mint = 1
    14, 0, // Extension type (2): Transfer hook = 14
    64, 0, // Extension length (2): 64
    0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
    0, 0, // Authority (32)
    1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1,
    1, 1, // Transfer hook program ID (32)
];

const MOCK_EXTRA_METAS_STATE: [u8; 86] = [
    105, 37, 101, 197, 75, 251, 102, 26, // Discriminator for `ExecuteInstruction` (8)
    74, 0, 0, 0, // Length of pod slice (4): 74
    2, 0, 0, 0, // Count of account metas (4): 2
    1, // First account meta discriminator (1): PDA = 1
    3, 0, // First seed: Account key at index 0 (2)
    3, 1, // Second seed: Account key at index 1 (2)
    0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
    0, // No more seeds (28)
    0, // First account meta is signer (1): false = 0
    0, // First account meta is writable (1): false = 0
    1, // Second account meta discriminator (1): PDA = 1
    3, 4, // First seed: Account key at index 4 (2)
    0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
    0, // No more seeds (30)
    0, // Second account meta is signer (1): false = 0
    0, // Second account meta is writable (1): false = 0
];

async fn mock_fetch_account_data_fn(address: Pubkey) -> AccountDataResult {
    if address == MINT_PUBKEY {
        Ok(Some(MOCK_MINT_STATE.to_vec()))
    } else if address
        == get_extra_account_metas_address(&MINT_PUBKEY, &TRANSFER_HOOK_PROGRAM_ID)
    {
        Ok(Some(MOCK_EXTRA_METAS_STATE.to_vec()))
    } else {
        Ok(None)
    }
}

#[tokio::test]
async fn test_resolve_extra_transfer_account_metas() {
    let spl_token_2022_program_id = crate::id();
    let transfer_hook_program_id = TRANSFER_HOOK_PROGRAM_ID;

    let source_pubkey = Pubkey::new_unique();
    let mut source_data = vec![0; 165]; // Mock
    let mut source_lamports = 0; // Mock
    let source_account_info = AccountInfo::new(
        &source_pubkey,
        false,
        true,
        &mut source_lamports,
        &mut source_data,
        &spl_token_2022_program_id,
        false,
        0,
    );

    let mint_pubkey = MINT_PUBKEY;
    let mut mint_data = MOCK_MINT_STATE.to_vec();
    let mut mint_lamports = 0; // Mock
    let mint_account_info = AccountInfo::new(
        &mint_pubkey,
        false,
        true,
        &mut mint_lamports,
        &mut mint_data,
        &spl_token_2022_program_id,
        false,
        0,
    );

    let destination_pubkey = Pubkey::new_unique();
    let mut destination_data = vec![0; 165]; // Mock
    let mut destination_lamports = 0; // Mock
    let destination_account_info = AccountInfo::new(
        &destination_pubkey,
        false,
        true,
        &mut destination_lamports,
        &mut destination_data,
        &spl_token_2022_program_id,
        false,
        0,
    );

    let authority_pubkey = Pubkey::new_unique();
    let mut authority_data = vec![]; // Mock
    let mut authority_lamports = 0; // Mock
    let authority_account_info = AccountInfo::new(
        &authority_pubkey,
        false,
        true,
        &mut authority_lamports,
        &mut authority_data,
        &system_program::ID,
        false,
        0,
    );

    let validate_state_pubkey = get_extra_account_metas_address(&mint_pubkey, &transfer_hook_program_id);

    let extra_meta_1_pubkey = Pubkey::find_program_address(
        &[
            &source_pubkey.to_bytes(), // Account key at index 0
            &mint_pubkey.to_bytes(),   // Account key at index 1
        ],
        &transfer_hook_program_id,
    )
    .0;
    let mut extra_meta_1_data = vec![]; // Mock
    let mut extra_meta_1_lamports = 0; // Mock
    let extra_meta_1_account_info = AccountInfo::new(
        &extra_meta_1_pubkey,
        false,
        true,
        &mut extra_meta_1_lamports,
        &mut extra_meta_1_data,
        &transfer_hook_program_id,
        false,
        0,
    );

    let extra_meta_2_pubkey = Pubkey::find_program_address(
        &[
            &validate_state_pubkey.to_bytes(), // Account key at index 4
        ],
        &transfer_hook_program_id,
    )
    .0;
    let mut extra_meta_2_data = vec![]; // Mock
    let mut extra_meta_2_lamports = 0; // Mock
    let extra_meta_2_account_info = AccountInfo::new(
        &extra_meta_2_pubkey,
        false,
        true,
        &mut extra_meta_2_lamports,
        &mut extra_meta_2_data,
        &transfer_hook_program_id,
        false,
        0,
    );

    let mut validate_state_data = MOCK_EXTRA_METAS_STATE.to_vec();
    let mut validate_state_lamports = 0; // Mock
    let validate_state_account_info = AccountInfo::new(
        &validate_state_pubkey,
        false,
        true,
        &mut validate_state_lamports,
        &mut validate_state_data,
        &transfer_hook_program_id,
        false,
        0,
    );

    // First use the resolve function to add the extra account metas to the
    // transfer instruction from offchain
    let mut offchain_transfer_instruction = crate::instruction::transfer_checked(
        &spl_token_2022_program_id,
        &source_pubkey,
        &mint_pubkey,
        &destination_pubkey,
        &authority_pubkey,
        &[],
        2,
        9,
    )
    .unwrap();

    resolve_extra_transfer_account_metas(
        &mut offchain_transfer_instruction,
        mock_fetch_account_data_fn,
        &mint_pubkey,
    )
    .await
    .unwrap();

    // Then use the offchain function to add the extra account metas to the
    // _execute_ instruction from offchain
    let mut offchain_execute_instruction = spl_transfer_hook_interface::instruction::execute(
        &transfer_hook_program_id,
        &source_pubkey,
        &mint_pubkey,
        &destination_pubkey,
        &authority_pubkey,
        &validate_state_pubkey,
        0,
    );

    ExtraAccountMetaList::add_to_instruction::<ExecuteInstruction, _, _>(
        &mut offchain_execute_instruction,
        mock_fetch_account_data_fn,
        &MOCK_EXTRA_METAS_STATE,
    )
    .await
    .unwrap();

    // Finally, use the onchain function to add the extra account metas to
    // the _execute_ CPI instruction from onchain
    let mut onchain_execute_cpi_instruction = spl_transfer_hook_interface::instruction::execute(
        &transfer_hook_program_id,
        &source_pubkey,
        &mint_pubkey,
        &destination_pubkey,
        &authority_pubkey,
        &validate_state_pubkey,
        0,
    );
    let mut onchain_execute_cpi_account_infos = vec![
        source_account_info.clone(),
        mint_account_info.clone(),
        destination_account_info.clone(),
        authority_account_info.clone(),
        validate_state_account_info.clone(),
    ];
    let all_account_infos = &[
        source_account_info.clone(),
        mint_account_info.clone(),
        destination_account_info.clone(),
        authority_account_info.clone(),
        validate_state_account_info.clone(),
        extra_meta_1_account_info.clone(),
        extra_meta_2_account_info.clone(),
    ];

    ExtraAccountMetaList::add_to_cpi_instruction::<ExecuteInstruction>(
        &mut onchain_execute_cpi_instruction,
        &mut onchain_execute_cpi_account_infos,
        &MOCK_EXTRA_METAS_STATE,
        all_account_infos,
    )
    .unwrap();

    // Now let's evaluate the different lists of keys

    // The two `Execute` instructions should have the same accounts
    assert_eq!(
        offchain_execute_instruction.accounts,
        onchain_execute_cpi_instruction.accounts,
    );

    // However, the transfer instruction is going to be missing the
    // the validation account at index 4
    assert_ne!(
        offchain_transfer_instruction.accounts,
        offchain_execute_instruction.accounts,
    );
    assert_ne!(
        offchain_transfer_instruction.accounts[4].pubkey,
        validate_state_pubkey,
    );

    // Even though both execute instructions have the validation account
    // at index 4
    assert_eq!(
        offchain_execute_instruction.accounts[4].pubkey,
        validate_state_pubkey,
    );
    assert_eq!(
        onchain_execute_cpi_instruction.accounts[4].pubkey,
        validate_state_pubkey,
    );

    // Despite the differences in indices, we're also going to have entirely
    // different PDAs in each list, and this is the issue
    assert_ne!(
        offchain_transfer_instruction.accounts[4].pubkey,
        extra_meta_1_pubkey,
    );
    assert_eq!(
        offchain_execute_instruction.accounts[5].pubkey,
        extra_meta_1_pubkey,
    );
    assert_eq!(
        onchain_execute_cpi_instruction.accounts[5].pubkey,
        extra_meta_1_pubkey,
    );
    assert_ne!(
        offchain_transfer_instruction.accounts[5].pubkey,
        extra_meta_2_pubkey,
    );
    assert_eq!(
        offchain_execute_instruction.accounts[6].pubkey,
        extra_meta_2_pubkey,
    );
    assert_eq!(
        onchain_execute_cpi_instruction.accounts[6].pubkey,
        extra_meta_2_pubkey,
    );

    // For even more verbosity
    assert!(offchain_transfer_instruction
        .accounts
        .iter()
        .find(|account_meta| account_meta.pubkey == extra_meta_1_pubkey)
        .is_none());
    assert!(offchain_transfer_instruction
        .accounts
        .iter()
        .find(|account_meta| account_meta.pubkey == extra_meta_2_pubkey)
        .is_none());
}

Proposed Solution
We should be able to insert a few lines of code into the helpers that simply converts a transfer instruction into an Execute instruction before resolving the extra account metas.
Since anyone storing extra account meta configs should be considering the list of accounts as it will arrive in their Transfer Hook program's Execute instruction, it makes sense to resolve for Execute.
After all, the main problem we have here is that we're asking TLV Account Resolution to resolve the extra account metas for an Execute instruction, but we're not actually feeding it a valid Execute instruction.

Is there a timeline for publishing v0.3.12? Currently facing 0x7dc8348c (IncorrectAccount) error on using addExtraAccountsToInstruction for the transfer hook.

Is there a timeline for publishing v0.3.12? Currently facing 0x7dc8348c (IncorrectAccount) error on using addExtraAccountsToInstruction for the transfer hook. cc @buffalojoec

https://github.com/solana-labs/solana-program-library/releases/tag/token-js-v0.4.0

Love it sir 😎🫡 my tx is still failing with 0x7dc8348c but at least the new package is out :)
Time to go debug more...

Any luck solving : 0x7dc8348c?


Retweet with comment

Since April retweet with comment (http://techcrunch.com/2015/04/06/retweetception/) has been available but I can't find it supported. Am I just lost?

To get this effect, mention the full url of the "retweeted" tweet in the content of your new tweet:
api.update_status("My reaction https://twitter.com/screenname/status/123456789")

I have a patch for this, but I can't upgrade due to the blocker issue #620.  What version of tweepy are you on?

Hey @johnkw ,
any news on this?
Care to explain why is it being blocked by #620?
Thanks!

Bug #620 blocks doing anything using the newer tweepy versions. It's a complete blocker to all usage (for certain with caching enabled, which is a must), so I can't rebase to the latest for any patches for other bugs, such as this one. I don't understand how anyone is able to use the newer tweepy versions at all, given the tremendous severity of #620.

Ah OK, I see. Thanks for the info. Then, I guess whoever is using it, it's for dev/fun purposes not for production environments. :)

As explained, this can simply be done by using API.update_status and including the URL for the Tweet you want to Retweet in the text of your new Tweet.
No patch is necessary, and it shouldn't matter what version of Tweepy you're using.
#620 has been fixed, but it's worth noting that it is and was completely unrelated to this issue and wouldn't have been a "blocker" for a fix for this issue, even if one was required, as caching is not mandatory and the library should be fully functional without using it. I'm also pretty sure that issue did not affect initial requests to an endpoint, but rather just returned incorrect results for requests afterwards with different arguments.


Consider allowing intervening directories in _sources

Currently the structure of _sources is just _sources/<package>/<version>. Suppose we allowed _sources/**/<package>/<version>. Then you could do things like this:
_sources/plutus
- plutus-core/...
- plutus-ledger-api/...
_sources/hackage-patches
- flat/...

And so on.
What's the benefit here? One is purely psychological: it lets people group stuff in a way that maybe makes more sense to them. The other is that it makes it much simpler to define e.g. a CODEOWNERS file, where you could match on plutus/* rather than having to list every package.
The intervening directories would of course have no effect on the build, so you could move them around freely.

TBH I think the _sources/<package>/<version> schema is mostly historical. This also gave us headaches because we have to make sure the location of meta.toml matches the resulting package id.
We could just glob **/meta.toml and only make sure there are no duplicates at the end; but it will give a worse user experience since nothing is going to tell you what packages you are looking at (since the name will only known when we cabal sdist). Also this doesn't help you with CODEOWNERS.


Adds DebugLogging to card merchant.

[#139908611]
https://www.pivotaltracker.com/story/show/139908611

@eldavido PTAL


Rendering Error

Office version: 2010 (too old?)
origin file:

quicklook preview:

It seems that these words are transparent.

Do you have Intel HD 4000 series GPU? If so, see https://github.com/QL-Win/QuickLook/issues/442.

Unfortunately I've got Intel HD 620.
And I still tried this
But it didn't help.


Fix ui graph decimal axis

#3084
add format

/1e-9 : n
/1e-6 : µ
/1e-3 : m

Let's just be complete and consistent and take all the prefixes from https://en.wikipedia.org/wiki/Metric_prefix with the exception of those with exponents not dividable by 3 (i.e. d, c, da, h)

@stuartnelson3
@beorn7
thank you and done.

:+1: But I'll wait for @stuartnelson3 's approval.

Code is good, but a small visual preference question:
The larger units currently don't have any cap to their length (unlike the smaller units with the negative exponents), so:
y = 1234486
1234486
y / 1e6
1.234486
y / 1e6 + "M"
"1.234486M"
(y / 1e6).toFixed(3) + "M"
"1.234M"

And this gets increasingly silly:
y =<PHONE_NUMBER>478654
1234567543478654
y / 1e15
1.234567543478654
(y / 1e15).toFixed(3)
"1.235"

@beorn7 should we do an "across the board" limit of decimal accuracy to 3 places?

SGTM. The exact values will be displayed in the graph hover box anyway.
On Mon, Sep 18, 2017 at 5:27 PM stuart nelson<EMAIL_ADDRESS>wrote:

Code is good, but a small visual preference question:
The larger units currently don't have any cap to their length (unlike the
smaller units with the negative exponents), so:
y =<PHONE_NUMBER>4486
y / 1e61.234486
y / 1e6 + "M"
"1.234486M"
(y / 1e6).toFixed(3) + "M""1.234M"
And this gets increasingly silly:
y =<PHONE_NUMBER>4786541234567543478654
y / 1e151.234567543478654
(y / 1e15).toFixed(3)"1.235"
@beorn7 https://github.com/beorn7 should we do an "across the board"
limit of decimal accuracy to 3 places?
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/prometheus/prometheus/pull/3184#issuecomment-330259872,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAANaK0eF7FO5G54G0xj4dTqDBFRNiYEks5sjovvgaJpZM4PZ2XO
.

We should limit the number of digits everywhere to the same value, but perhaps more than 3? How much does fit into the space in the graph? The fewer digits we allow, the more likely we run into a similar case as before, where the lower bar is 1.2340 and the upper bar is 1.2344, and both display as 1.234.

Your call, but I think 5 is probably the most we should do for this first attempt. I'm not sure how many numbers the container/graph shows well.

I think we should have 5 consistently.
I can change that while fixing the merge conflict. Will merge into release-1.7, canary, and then draft a release.

So this is a bit more complicated than anticipated. With the toFixed, it will display the given number of digits in any case, even if it is a perfectly round number. The plain old toString does a quite good job.
I'll add this to this PR while merging to save a roundtrip. It's also just being merge into a branch.

Please check out what we have now in the release-1.7 branch. I think that's pretty much what we wanted.


Error with custom front end and autowire

Hey!
I just wanted to extend existing Dropzone Controller:
<?php
namespace App\Controller\Admin;

use Oneup\UploaderBundle\Controller\DropzoneController;

class CustomController extends DropzoneController
{}

And in the config of the bundle:
oneup_uploader:
    mappings:
        gallery:
            frontend: custom
            custom_frontend:
                class: App\Controller\Admin\CustomController
                name: gallery

But it doesn't work because of autowiring.

Cannot autowire service "App\Controller\Admin\CustomController": argument "$storage" of method "Oneup\UploaderBundle\Controller\AbstractController::__construct()" references interface "Oneup\UploaderBundle\Uploader\Storage\StorageInterface" but no such service exists. You should maybe alias this interface to the existing "oneup_uploader.storage.gallery" service. Did you create a class that implements this interface?

That make sense because symfony doesnot know which services to use. So the first idea was to disable autowiring for my custom controller:
services:
    App\Controller\Admin\CustomController:
        autowire: false

And guess what ? It works. The second idea is to manually add arguments in that file if you don't want to disable  autowiring. A bit annoying. So i wrote a small compiler pass for the bundle. PR comes soon.

I think so. Arguments are dynamically generated (based on config of bundle) when container is compiled.


how to use with vitepress

component imported in hoisted tags not work as expected
https://github.com/vuejs/vitepress/issues/443

@kagawagao try this,m you shoulod point to the vitepress theme/components dir ()this is how we use on docs package on vite-plugin-pwa repo (if you don't use icons plugin, just remove  resolvers option):
// https://github.com/antfu/vite-plugin-components
    Components({
      dirs: [
        '.vitepress/theme/components',
      ],
      // allow auto load markdown components under `./src/components/`
      extensions: ['vue', 'md'],

      // allow auto import and register components used in markdown
      include: [/\.vue$/, /\.vue\?vue/, /\.md$/],

      // generate `components.d.ts` for ts support with Volar
      dts: false,
      // auto import icons
      resolvers: [
        // https://github.com/antfu/vite-plugin-icons
        IconsResolver({
          componentPrefix: '',
          // enabledCollections: ['carbon'],
        }),
      ],
    }),


PDF text copying

Currently, copying text from generated PDFs are incorrect when pasted.

This is fixed in the develop branch

I've incorporated implementing view to work for coordinates as well in the roadmap from where it will be tracked: #74


Filter spawn attempts by type

Spawn attempts renderer has been removed until I can figure out a way to make it useful.


grafana: support socket protocol

Motivation for this change
Grafana supports unix sockets, but this cannot be configured using the protocol option.
Things done
This PR adds the socket value to the services.grafana.protocol enum, allowing grafana to listen on a unix socket.

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

[x] 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/)
[x] Fits CONTRIBUTING.md.

18.03:
[detached HEAD f956b4fa6c5] grafana: support socket protocol
Author: Ben Wolsieffer<EMAIL_ADDRESS>Date: Thu Apr 12 22:46:12 2018 -0400
1 file changed, 1 insertion(+), 1 deletion(-)


Okapi WASM is reporting the wrong internal version 0.1.0

This is a compile time constant that we need to preserve. Let's verify it for non WASM binaries as well.

This has since been fixed


How to make a site public?

Hey everyone,
maybe someone can help me with making a site public?
The Public group had all ticks on show and the guest user is in the public group.
I then ticked "show" on the specific site for the public role but if i take the link and want to open it without being logged in, i get to the login page.
What am I doing wrong?

The public group is the default group for public registrations. I'm otherwise unsure if access is available without registration / logon.
If it isnt, implementing OAuth with G. Suite is a fairly straightforward process.

Oh ok, i thought public meant, that everybody can see it without login.
So this option isn't implented yet?

I'm not sure, @ssddanbrown is this a function?

@Biepa @lithium-ap Yes it is possible, under settings enable this setting:

I have not tested this but I would imagine you could set "Allow public viewing" to yes and then set the permissions level to a higher level on the content you want to "hide".

@TBK Tested it, you're right. I set "Allow public viewing" to yes and the can "hide" if I dont tick "view" for the public group.
Maybe there is a better way to implement this?
For example if we could set the "public viewing" option per book/chapter/page. This way you also don't have to overwrite all permissions for every book/chapter/page, you don't want to make viewable to the public.
Then you just have to tick it, where you want it, and not everywhere you don't want.
Or maybe there is an another, better idea.

One solution would be to add a new view to "Settings" where you could see and change the permissions of all content individually and in bulk.

Another workaround was mentioned in an earlier feature request #407 the steps are as follows:

To achieve a 'whitelist' approach for public users you can do the following:

Turn on the "Allow public viewing" setting.
Edit the 'Public' role and uncheck all permissions then save.
Go to the book you want to make visible publicly and edit the permissions via the dropdown to the right of the 'Edit' link.
Check 'Enable Custom Permissions' then set all the permissions you want, Ensuring you check the view permission for the public role.

Following the above has worked for me in that any shelf/book/chapter/page I want public.

Thank you @tpeacock19 !
Still not the best way i think, but much better than the alternative.

Thanks everyone for providing support. Will now close this as it looks solved (Although I am aware the permissions UX needs a bit of work).
As an extra tip, You could keep all public books in a bookshelf, Then when you need to update the permissions of those, You can simply change the shelf permission and there's a button to apply the same permissions to all child books. Pages and chapters within books will then inherit those book permissions. Just a way to potentially make things more manageable by batch-setting permissions.


kernel: add note in device.h

DEVICE_AND_API_INIT() is preferred over DEVICE_INIT() since
DEVICE_INIT() does not set the API struct at build time.
Signed-off-by: Andrew Boie<EMAIL_ADDRESS>

Codecov Report

Merging #11819 into master will decrease coverage by 0.09%.
The diff coverage is n/a.

@@            Coverage Diff            @@
##           master   #11819     +/-   ##
=========================================
- Coverage   48.29%    48.2%   -0.1%
=========================================
  Files         280      280
  Lines       43333    43320     -13
  Branches    10375    10374      -1
=========================================
- Hits        20929    20881     -48
- Misses      18252    18284     +32
- Partials     4152     4155      +3

Impacted Files
Coverage Δ

include/device.h
100% <ø> (ø)
:arrow_up:

subsys/logging/log_output.c
62.38% <0%> (-10%)
:arrow_down:

subsys/logging/log_core.c
66.36% <0%> (-4.88%)
:arrow_down:

misc/printk.c
81.81% <0%> (-3.13%)
:arrow_down:

include/logging/log_msg.h
89.09% <0%> (-1.82%)
:arrow_down:

include/logging/log_core.h
100% <0%> (ø)
: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 965128b...ed690cc. Read the comment docs.

recheck


Diagram Update

Hello,
Thank you for your schema. It seems great but diagram is outdated. Do you consider to update the diagram? If you can, that will be great.
Have a nice day!

Hey I figured it out but can you explain that how i can process products attributes and variations?


OJS trigger update ordering bug causes flashes

Hi,
There are noticeable flashes scrolling quickly through the OJS Variables example. I experience them in my own drafty example that uses OJS trigger values.
Screencast from 2024-11-15 18-56-41.webm
The flases are caused by the trigger index incrementing before 0izing progress. So you get index A progress 100% then index B progress 100% then index B progress 0%: the middle change causes the flash.
Here I show the same issue scrolling up/down the OJS Variables example:
Screencast from 2024-11-15 19-03-03.webm
Hopefully this isn't a tricky fix - So far I like the design of this a lot!
Thanks!
Declan

Good spot @declann . I think this is the same issue that we noticed a few months back:
https://github.com/qmd-lab/closeread/pull/40#issuecomment-2209265243
I'm looking at the second globe that shows up in our gallery example, though, and I see the same flashing behavior. @jimjam-slam any idea what's up?

@andrewpbray It looks like our second globe still uses my old trigger block-based maths. We should probably convert it over to a progress block too! I wonder if we should make some tweaks to our docs to push progress blocks a bit harder for the situations in which they're helpful.
@declann, give a progress block a try. It lets you track progress over several triggers at once, so you don't have to juggle events and potentially hit this event race problem. Let us know how you go!

Thanks @andrewpbray - progress block does work!
However, I amn't trying to control a single animation across many triggers - each trigger is for a separate animation, so I must track trigger index too.
The mapping of crTriggerIndex+crTriggerProgress to a d3 scale as in the second globe is particularly elegant for what I'm trying to do!
Using progress blocks, I think I can get the effect I need with just a little different logic (a division).
But also, a workaround for the event race might be to conditionally subtract one in crTriggerIndex+crTriggerProgress :thinking:
I know I have a few options to try, so I will report back on what works for me soon - thanks!

I reckon it might be good for us to add a warning to the end of our OJS demo not to rely on the timing of crTriggerIndex and crTriggerProgress for continuous animations!

This fudge I am using:

edit: Now I'm setting progress = crTriggerIndex+crTriggerProgress-(crTriggerProgress>0.99999?1:0)+(crTriggerProgress<0.00001?1:0) and using progress in my scales as in second globe example. So far no jank on this formula

Works pretty well! It's not perfect: somehow I had the flash problem once or twice in my testing. It's usually perfectly smooth. (but I'll be more confident when I finish my animation)
I guess it's also possible to massage conditional updates of trigger index/progress into closeread.js or just define a new progress variable for smooth animations across triggers
Just calling out the issue also works - it's up to you!


Request an Icon like Eclipse on Linux

Can you guys provided an icon or linux version like Eclipse did, So that when I create a shortcut on Ubuntu. I can assign the icon for shortcut.
Thanks

.deb packages are coming in the upcoming release which will installs a .desktop entry as well as a bin command. It's currently available on the insiders build: http://code.visualstudio.com/insiders


Carthage 'realm-cocoa' build fails

Hi,
My understanding is realm-cocoa was removed but it is still somehow available for Carthage, I am unable to define sugarrecord as dependency as the build fails...
`*** Building scheme "Realm" in Realm.xcworkspace
Build Failed
Task failed with exit code 65:
/usr/bin/xcrun xcodebuild -workspace /Users/czaku/Projects/apps/freeme/Carthage/Checkouts/realm-cocoa/Carthage/Realm.xcworkspace -scheme Realm -configuration Release -derivedDataPath /Users/czaku/Library/Caches/org.carthage.CarthageKit/DerivedData/realm-cocoa/v1.1.0 -sdk iphoneos ONLY_ACTIVE_ARCH=NO BITCODE_GENERATION_MODE=bitcode CODE_SIGNING_REQUIRED=NO CODE_SIGN_IDENTITY= CARTHAGE=YES clean build
This usually indicates that project itself failed to compile. Please check the xcodebuild log for more details: /var/folders/yp/h01n__7s3250_sjy3ymrwpbh0000gn/T/carthage-xcodebuild.bxdCUp.log
`

Hi @czaku , thanks for the report. I completely forgot about it. I'll fix it and push a new version so that you can integrate the framework using Carthage.

@czaku I've pushed a new version https://github.com/carambalabs/SugarRecord/releases/tag/3.1.3. Could you try now?

@pepibumur fixed, thanks :)


[Feature Request] Send to Printer

Is it possible to add the print feature to send the rendered content to the printer?
Thanks a lot!

Is it possible to add the print feature to send the rendered content to the printer?

Right-click somewhere in the rendered content and choose "Print..." :wink:

Hi,
this should already work.
Try right click in the view.
There should be a "print"-entry in the context menu.
I get this (its in german "Drucken.." for "Print")


Can Aurura be used to control window border colors?

I'm a complete newcomer to Aurora, so forgive me if this question is off base. Does Aurora have the ability to control the coloring of UI elements within Windows? I saw this neat border coloring demo and immediately thought "it would be cool if a centralized RGB app could control that", which led me here after some web searching.

That's possible but seeing the example, you have to manually configure which windows to recolor.
Also, this would need to be done in DeviceManager part of Aurora which needs some development for window detection.
I am also in vacation for whole August so I can't add this for a while


go: Generate separate package init functions per file. [phab:D2197]

Created by fromberger at 2018-02-22 22:25:39:
Previously, we were blaming all package-level function calls on an implicit
init function for which the indexer created one instance per package on demand.
But packages may consist of multiple files, so calls may wind up blamed on a
function which appears to be located in a different file. This isn't strictly
wrong, but it is confusing to the user.
To address this, allow there to be a separate implicit package init function
per package source file, as needed. These are disambiguated by the offset in
the token stream of the package clause in that file, which is unique within the
package. Calls within a given file are mapped to that file's package init
instead of a shared one, ensuring that each gets attributed to the correct
file.

schroederc accepted this revision at 2018-02-22 22:30:17

fromberger closed via commit 8e60c7d71f41d833e72927bc77a133b6c8ea6464 at 2018-02-22 22:36:01


Convert to json contains class name key.

is it have a way to get a json with class name?
public class Person {
    public String name;
}

=>
person {name:xxx}

That isn't even valid json. What are you looking for exactly?


Clarifying that synchronous Subscribers are RECOMMENDED to request() …

…at the end of signal processing
See #429

To me adding it as proposed is fine.

@rkuhn Thanks Dr. Kuhn!

looks ok, but it would still be nice to emphasize here that subscribers should request the max they can receive, not necessarily one.

I think that a recommendation for request(…) should go into the Intent section of 2:1—https://github.com/reactive-streams/reactive-streams-jvm#2.1
Please open a PR with a suggested wording

(I mean that it is a good addition and it deserves its own PR :))

(I mean that it is a good addition and it deserves its own PR :))

Sorry, was busy over ScalaDays, I can PR the mini improvement today, I suppose "on top of" this PR.

I think that a recommendation for request(…) should go into the Intent section of 2:1—https://github.com/reactive-streams/reactive-streams-jvm#2.1
Please open a PR with a suggested wording

PSed https://github.com/reactive-streams/reactive-streams-jvm/pull/435

@reactive-streams/contributors Thanks for reviewing!


Support COPY TO Externally Defined File Formats, add FileType trait

Which issue does this PR close?
Closes #8345
Revives #8667
Rationale for this change
Previously, COPY TO queries could only be planned/executed for a preset enum of FileTypes. CREATE EXTERNAL TABLE supports arbitrary file formats via the FileFormat and TableProvider traits. This PR removes the FileType enum in favor of a FileType trait and updates COPY TO plans to work with any externally implemented dyn FileFormat.
This PR also enables future work to remove csv, parquet, json, ect... formats into dedicated crates (datafusion-csv, ...).
What changes are included in this PR?

Deletes the FileType enum and replaces with a trait
Creates a wrapper struct for FileFormat that implements FileType to enable conversions between the two
Extends LogicalExtensionCodec to allow serde of dyn FileType

Are these changes tested?
Existing tests verify behavior for currently supported formats remains the same.
Are there any user-facing changes?
Yes, there are API changes relevant for developers using DataFusion.

This looks awesome -- thank you @devinjdangelo  -- I plan to review this carefully, but probably not until tomorrow

Thank you, @devinjdangelo, for proposing this extensibility feature. I would like to clarify a few points to ensure I understand correctly:

We cannot merge FileType and FileFormatFactory due to dependency issues.
We cannot merge FileFormatFactory and FileFormat because of stateful format factories.

If these points are correct, I am considering whether we could move these states (extension options, like CsvOptions) into FileType somehow to remove one of these layers. This is just a thought experiment; I don't want to block the PR, which I believe improves extensibility.

Thank you for taking a look @berkaysynnada

We cannot merge FileType and FileFormatFactory due to dependency issues.

That is correct. Logical planning cannot depend on FileFormatFactory or FileFormat to avoid a dependency on datafusion's execution engine during logical planning.

We cannot merge FileFormatFactory and FileFormat because of stateful format factories.

Yes, SessionState stores a HashMap<String, Arc<dyn FileFormatFactory>. Each FileFormatFactory could be shared among multiple concurrent queries and must be able to produce many, differently configured, Arc<dyn FileFormat>s. If SessionState stored only a Arc<dyn FileFormat> it would have to have a &mut self method enabled by a Mutex<> and even with that it would possibly lead to unexpected behavior if multiple queries modified the format during execution.

Yes, SessionState stores a HashMap<String, Arc>. Each FileFormatFactory could be shared among multiple concurrent queries and must be able to produce many, differently configured,

I wonder if it wuld be possible to store the file format state outside the FileFormat and pass in the format options as part of each query somehow 🤔

I wonder if it wuld be possible to store the file format state outside the FileFormat and pass in the format options as part of each query somehow 🤔

I think this is possible, but it would also make implementing FileFormat a bit inconvenient. We would have to pass in and parse format_options on every trait method. E.g. something like:
pub trait FileFormat{
        async fn create_physical_plan(
        &self,
        state: &SessionState,
        conf: FileScanConfig,
        filters: Option<&Arc<dyn PhysicalExpr>>,
        format_options: &HashMap<String, String>,
    ) -> Result<Arc<dyn ExecutionPlan>>;
    ...
}

And each method would have to parse the format_options. FileFormatFactory avoids this by allowing FileFormat to be created during physical planning when query specific options are known and can be parsed once/stored in the FileFormat struct.

I merged up to resolve a conflict

Forward ! Thank you @devinjdangelo  and @Weijun-H


Let Form::Date[nil] return nil

Date.parse(nil) raises a TypeError, so handle that case explicitly.
I could've rescued from TypeError, but that would allow for
Form::Date[2] to return 2. That's probably not how form coercions should
behave.
This fixes #83.

Form types are only meant to work with string input so this behavior is not needed.


Add support for TC and Maya short codes

I'm not certain where in the build/deploy process is the previously existing generate:tokens is called.
We need to add generate:shortcodes:thorchain and generate:shortcodes:mayachain to that routine.

closing in favor of #731


black version upgrade

Signed-off-by: sungho<EMAIL_ADDRESS>

https://github.com/yurirocha15/leetcode-practice-python/issues/21


kubectl hangs on almost any command that should return cluster info

Describe the bug
first time KUI user here - any command involving kubectl getting info (or outputting it) just hangs with the indicator showing that it's "working". Looking at the process list shows that kui started a kubectl process, it seems to exit, but kui still reports it as "running".
I suspect user error or something peculiar with my installation, but cannot find the cause.
kubectl config commands work, as do some unformatted outputs (like kubectl version).
helm works
unfortunately i couldn't find a way how to enable verbose logging or debug output.
Steps to reproduce the behavior

run kubectl version - works
kubectl get pods -> infinite spinner
also mentioning that the namespace indicator on the bottom is "Loading" very long.

Expected behavior
kubectl pods outputting ... something.
Screenshots

Also worth mentioning that prereq --module Kubernetes shows red for kubectl, but no explanation as to why.

"up" shows all good.
Code snippets
If applicable, add code samples to help explain your problem.
System

Kui version: probably 10.8.1 (about screen does not show a version number) - via chocolatey
Operating system: Windows 10 20h0
kubectl 1.22 via chocolatey
helm 3.7.0 via chocolatey

I faced the same problem and restarting windows fixed for me, for now.

I am experiencing the same behavior. Kui worked the first time I used it after install, but after quitting the first session it has not worked again.

Found a bit of detail:
turns out this happens only on specific clusters (especially those managed through rancher).
Kui spawns a "kubectl proxy" process on start, listening and forwarding port 8001. This process has several problems:

It is not killed when Kui exits - it stays around and will block port 8001 - later invocations of Kui cannot spawn another kubectl process and might run up in the wrong context, but usually will just hang. It's possible that this only affects Windows.
It is not killed/replaced if you switch contexts. This results in a guaranteed hang of all kubectl commands if you switch contexts in Kui.
It does not work properly when connecting to rancher. It never shows the target context - instead it shows resources from Rancher's management cluster.

Found a bit of detail:
turns out this happens only on specific clusters (especially those managed through rancher).
Kui spawns a "kubectl proxy" process on start, listening and forwarding port 8001. This process has several problems:

It is not killed when Kui exits - it stays around and will block port 8001 - later invocations of Kui cannot spawn another kubectl process and might run up in the wrong context, but usually will just hang. It's possible that this only affects Windows.
It is not killed/replaced if you switch contexts. This results in a guaranteed hang of all kubectl commands if you switch contexts in Kui.
It does not work properly when connecting to rancher. It never shows the target context - instead it shows resources from Rancher's management cluster.


optimize property define

we should define custom element property when define r2wc . it's a multi-defined while there is a define in Greeting  by React too.
const WebGreeting = r2wc(Greeting, {
  props: {
    name: "string",
  },
})

so. how about define in this way.
Greeting.propTypes = {
  name: PropTypes.string
}

Greeting.defaultProps = {
  name: ""
}

I find that you currently use propTypes as the property keys.
So, how about use typeof defaultProps  instead of {props:{name:"string"}}.
then the api r2wc don't need the second params. code will be much clearly and pure.

hey, most persons do not use defaultProps. I personally have never seen it in a codebase. We use propTypes only if props object is not passed. This is not ideal though because propTypes are generally not available in production. defaultProps also does not give us the explicit types for each prop. We would have to loop though each value in the defaultProps object and parse it's type. Again, this is not ideal.


too much prejudice towards backward movement in local plan

Greetings,
I have observed that teb have preference to turn back and move rather than moving forward as human do.
I am attaching two screen shots to help me pose this question.  I have also observed that even in case of diff-drive robot vehicle do not considers rotation in place as one of the feasible options.
Kindly advise which parameters I should tune so that preference to forward movement is higher.
I am using following parameters for teb

TebLocalPlannerROS:
odom_topic: odom
Trajectory
cmd_angle_instead_rotvel: false    #NITIN
teb_autosize: True
dt_ref: 0.3
dt_hysteresis: 0.1
global_plan_overwrite_orientation: True
max_global_plan_lookahead_dist: 3.0
feasibility_check_no_poses: 5
Robot
max_vel_x: 0.4
max_vel_x_backwards: 0.2
max_vel_y: 0.0
max_vel_theta: 0.3
acc_lim_x: 0.5
acc_lim_theta: 0.5
min_turning_radius: 0.0 # diff-drive robot (can turn on place!)
footprint_model:
type: "point"
GoalTolerance
xy_goal_tolerance: 0.2
yaw_goal_tolerance: 0.1
free_goal_vel: False
Obstacles
min_obstacle_dist: 0.25 # This value must also include our robot radius, since footprint_model is set to "point".
include_costmap_obstacles: True
costmap_obstacles_behind_robot_dist: 1.0
obstacle_poses_affected: 30
costmap_converter_plugin: ""
costmap_converter_spin_thread: True
costmap_converter_rate: 5
Optimization
no_inner_iterations: 5
no_outer_iterations: 4
optimization_activate: True
optimization_verbose: False
penalty_epsilon: 0.1
weight_max_vel_x: 2
weight_max_vel_theta: 1
weight_acc_lim_x: 1
weight_acc_lim_theta: 1
weight_kinematics_nh: 1000
weight_kinematics_forward_drive: 1
weight_kinematics_turning_radius: 1
weight_optimaltime: 1
weight_obstacle: 50
weight_dynamic_obstacle: 10 # not in use yet
Homotopy Class Planner
enable_homotopy_class_planning: True
enable_multithreading: True
simple_exploration: False
max_number_classes: 4
selection_cost_hysteresis: 1.0
selection_obst_cost_scale: 1.0
selection_alternative_time_cost: False
roadmap_graph_no_samples: 15
roadmap_graph_area_width: 5
h_signature_prescaler: 0.5
h_signature_threshold: 0.1
obstacle_keypoint_offset: 0.1
obstacle_heading_threshold: 0.45
visualize_hc_graph: False

i suggest you could tune weight_kinematics_forward_drive to 1000

The planner produces time-optimal trajectories.
Depending on the limits on linear velocity, turn rate and accelerations it is often slower to rotate in place. Obviously, if the optimizer would minimize path length rather than time, rotations in place would be preferred (this is currently not implemented, but this feature might be added easily).
As @hapi007 suggested, you can try to heavily penalize backwards motions. Currently it is not possible to guarantee forward motions only in all situations. I am going to add it to my TODO list ;-)
I close this issue now, but you can still continue commenting.

Hello! First of all, thanks for this awesome planner, and the hints in this thread.
I'm using TEB with a configuration that is optimized for path following, which works quite well. In my case, I have a diff drive robot, and I would be interested in implementing a way to minimize path length, and therefore prioritize in-place rotations over backwards movements. Is this still in the TODO list? May I have a pointer to at least check how much effort it would take to implement it?
I've already tried penalizing backwards motions, but it still feels like with rotations in place it will work better (the robot sometimes get's stuck when trying to reach rotate-only goals).

Hey! Thanks for your feedback. I played with the minimization of the path lengths in the early development stage of the planner, but personally, I preferred the minimum time solution over the shortest path. Nevertheless, I can fully understand the use-case ;-)
If you want to modify the optimization problem, you need some basic knowledge of the g2o-framework / hyper-graph least-squares-optimization.
Then, it is straightforward to add an optimization edge that minimizes path length (just add a binary edge that minimizes the Euclidean distance between two consecutive poses.
You need to turn of the time-optimal edge of course.
But now, you have to provide additional information to the optimizer, otherwise, the optimization problem is ill-posed:
Since the time-differences (Delta T_k) between two consecutive poses are still subject to optimization, you need to add more constraints:
E.g. you could try to fix the velocity always to its maximum speed or maximize it within its bounds. Or you could try to fix the Delta T vertices during optimization. But in that case, the automatic insertion and deletion of discrete poses does not work anymore since it is based on Delta T. You would need to define a distance metric in SE1, in order to add or remove poses (you could also, of course, try to keep the number of poses fixed at all.)


vodlocker does not work anymore

It used to only be the url that was changed, but they changed a lot more now. Thank you for the tool!

I apologize, but this is not sufficient information for us to help you solve the problem. See our [https://yt-dl.org/reporting](bug reporting guidelines) for information of what a good bug report should contain.

It's kind-of rude to not even let me reopen the issue with additional information.
There is a test case in extractor/vodlocker.py, that would show the problem. I can include the output nevertheless.
> youtube-dl --version
2015.12.23
> youtube-dl http://www.vodlocker.city/e8wvyzz4sl42 -v
[debug] System config: ['--prefer-free-formats']
[debug] User config: ['--ignore-errors', '--continue', '--no-mtime', '--all-subs', '--add-metadata', '--xattrs', '-f', '[height <? 720]']
[debug] Command-line args: ['http://www.vodlocker.city/e8wvyzz4sl42', '-v']
[debug] Encodings: locale UTF-8, fs utf-8, out UTF-8, pref UTF-8
[debug] youtube-dl version 2015.12.23
[debug] Python version 3.4.3 - Linux-4.2.8-300.fc23.x86_64-x86_64-with-fedora-23-Twenty_Three
[debug] exe versions: ffmpeg 2.8.4, ffprobe 2.8.4
[debug] Proxy map: {}
[Vodlocker] e8wvyzz4sl42: Downloading webpage
[Vodlocker] e8wvyzz4sl42: Waiting for 3 seconds
[Vodlocker] e8wvyzz4sl42: Downloading video page
ERROR: Unable to extract thumbnail; please report this issue on https://yt-dl.org/bug . Make sure you are using the latest version; see  https://yt-dl.org/update  on how to update. Be sure to call youtube-dl with the --verbose flag and include its complete output.
Traceback (most recent call last):
  File "/usr/lib/python3.4/site-packages/youtube_dl/YoutubeDL.py", line 665, in extract_info
    ie_result = ie.extract(url)
  File "/usr/lib/python3.4/site-packages/youtube_dl/extractor/common.py", line 291, in extract
    return self._real_extract(url)
  File "/usr/lib/python3.4/site-packages/youtube_dl/extractor/vodlocker.py", line 49, in _real_extract
    r'image:\s*"(http[^\"]+)",', webpage, 'thumbnail')
  File "/usr/lib/python3.4/site-packages/youtube_dl/extractor/common.py", line 586, in _search_regex
    raise RegexNotFoundError('Unable to extract %s' % _name)
youtube_dl.utils.RegexNotFoundError: Unable to extract thumbnail; please report this issue on https://yt-dl.org/bug . Make sure you are using the latest version; see  https://yt-dl.org/update  on how to update. Be sure to call youtube-dl with the --verbose flag and include its complete output.

I did not test HEAD, because there have not been updates to the vodlocker extractor since then.

Thanks for dealing with it so quick!


[BUG] Update Wrangler to v2 tag

Rancher Server Setup

Rancher version: 2.9-head

Describe the bug

Rancher is using an untagged version for rancher/wrangler. The current version of Wrangler used in Rancher and supporting repositories includes all of the breaking changes introduced by wrangler/v2 but does not include the Wrangler/v2 package update.
This issue tracks updating the wrangler commit hash in go.mod to a tagged wrangler v2 version.
Before rancher/rancher can be updated to a wrangler/v2 tag, ancillary repos must be updated first.
Dependent Repos

[ ] https://github.com/rancher/apiserver
[ ]  https://github.com/rancher/channelserver
[ ]  https://github.com/rancher/steve
[ ]  https://github.com/rancher/dynamiclistener
[ ]  https://github.com/rancher/aks-operator
[ ]  https://github.com/rancher/eks-operator
[ ]  https://github.com/rancher/gke-operator

Testing Validation
No specific validation should be needed for this issue other than confirming that Rancher is using a tagged version.

/backport

Order of PRs to merge for Rancher v2.9 branch

apiserver: https://github.com/rancher/apiserver/pull/47
dynamiclistner: https://github.com/rancher/dynamiclistener/pull/88
channelserver: https://github.com/rancher/channelserver/pull/25
steve: https://github.com/rancher/steve/pull/142
aks-operator: https://github.com/rancher/aks-operator/pull/349
eks-operator: https://github.com/rancher/eks-operator/pull/320
gke-operator: https://github.com/rancher/gke-operator/pull/267


Optionality - T*

One question I have that I couldn't find a satisfactory answer to in the paper (though it is referenced at the very top of page 3, second bullet, see below)
"an X that only for { flexibility, optionality } happens to be passed by pointer (which in turn may or may not be safe to store to outlive the function call)"

is how to replace T* where T* is optional.
E.g.
void process(int a, Logger* logger)
{
    if (logger != nullptr) {
        logger->log(a);
    }
    ...
}

This is a pretty contrived example but could you do this using the new in/out/inout approach?
In the talk from CppCon 2020 it mentions in would be pass by T* when the size of the type is larger than some threshold, but then say if it's an object would one need to dereference it or use ->? I'm just wondering with in would you also need in* or something similar? Or would the expectation be to use std::optional instead for these types of thing?
Overall I love the idea, I'd adopt this in a second if I could. I just wanted to make sure I understand this part, I've most likely missed something 🙈
Thanks!
Tom

Thanks. Yes, I'd take either in T* or an in optional<T>, either is fine; two other alternatives are overloading and default arguments. Pointers are still a fine thing to pass when you want to do that to say what is being passed, in this case an optional parameter. The main place this proposal would remove raw T* parameters is when they are being used to express "how" not "what", such as for out T parameters.
I'll add a note about this in the doc. Thanks again.

Awesome that makes perfect sense 😊 Thank you very much for following up and for all the fantastic work you do.
Best of luck with the paper and I look forward to one day getting to use this simpler, more beautiful C++ 🙂


Why not using snake_case?

I read your paper in a bout of insomnia this past night, and found that it was really fascinating and thoughtful. I came to your work by the way of this other paper https://arxiv.org/pdf/2401.03910.pdf, which mentions it in its discussion about "world models".
Looking at the code, I cannot help wondering if the use of CamelCase for class members, instead of the more conventional snake_case, could have had a certain influence on the Python generating performance? Also, to a lesser extent, the mix of f-strings and string concatenation.

That's a very good question. From looking at the generated programs GPT-4 seems to overall deal with this correctly. That said, it might have had some impact on our experiments with CodeLlama.


Feat: Something more can be done with buttons to make it attractive.

Describe the feature
I find the discord and the LinkedIn button unattractive .I would like to make the discord and LinkedIn buttons attractive by changing its UI and i think if we add the logo of discord  in the discord button and add the logo of LinkedIn in the LinkedIn button , it will make it's look fantastic.
I would like to work on this , please assign me this task.
Add ScreenShots

Record

[X] I agree to follow this project's Code of Conduct
[X] I'm a GSSOC'24 contributor
[X] I want to work on this issue

I would like to work on this issue please assign it to me , it will be very great of you . Thank you.


Decide on API

While API is on my mind - We should make a decision on what we want our public API to be and make everything else private.
This will help organize the package and will make it clear to us which functions/methods are public and thus should be stable. It also relieves us of documenting/maintaining functions that are only used internally.
CC @Andesha
EDIT: FYI, during development almost nothing was made private... This is why I'm bringing it up now.

It is unlikely that we will change a function from private to public. Maybe just listing the public functions that you think should be made private and we can discuss these, specifically? I am not a big fan of trying to put everything private (not saying that it is what you aim to do)... I'd avoid putting private anything that might have an external use (even though we may not have coded it with this in mind) and putting private only what is very specific to the internals and unlikely to ever be useful for re-use... I am not rigid on that position, but that is how I see it at this point. This is a research tool, aim at researchers who are expected (and should feel welcome) to play with the code beyond the narrowly drawn borders of the use case we may have thought about...

Sure, I can propose a list of functions that should not be part of the API.
I agree with you that there are some utilities outside the main pipeline methods that can be useful and be a part of the API.


Fix typo in cmdline assembly module.

check for use of "fa" instead of "infoseq". We should use the latter as it is more generally available.

changed.


cargo-tree: 0.18.0 -> 0.19.0

Motivation for this change
Things done

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

[x] 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"
[x] 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)
[ ] Fits CONTRIBUTING.md.

@GrahamcOfBorg build cargo-tree

Success on x86_64-linux (full log)
Attempted: cargo-tree
Partial log (click to expand)

installing
post-installation fixup
shrinking RPATHs of ELF executables and libraries in /nix/store/sqgbhl8mixc8y32lnz6b53hzbw00n3l3-cargo-tree-0.19.0
shrinking /nix/store/sqgbhl8mixc8y32lnz6b53hzbw00n3l3-cargo-tree-0.19.0/bin/cargo-tree
strip is /nix/store/4qvrxzxa535y8304mk195x50b6p9607d-binutils-2.30/bin/strip
stripping (with command strip and flags -S) in /nix/store/sqgbhl8mixc8y32lnz6b53hzbw00n3l3-cargo-tree-0.19.0/bin
patching script interpreter paths in /nix/store/sqgbhl8mixc8y32lnz6b53hzbw00n3l3-cargo-tree-0.19.0
checking for references to /build in /nix/store/sqgbhl8mixc8y32lnz6b53hzbw00n3l3-cargo-tree-0.19.0...
/nix/store/sqgbhl8mixc8y32lnz6b53hzbw00n3l3-cargo-tree-0.19.0

Success on aarch64-linux (full log)
Attempted: cargo-tree
Partial log (click to expand)

installing
post-installation fixup
shrinking RPATHs of ELF executables and libraries in /nix/store/piildnjs6fyxngp6bhj1082l6wyh42lx-cargo-tree-0.19.0
shrinking /nix/store/piildnjs6fyxngp6bhj1082l6wyh42lx-cargo-tree-0.19.0/bin/cargo-tree
strip is /nix/store/0pjsgkxz0rp5baycq5sp2s72lrr5q9sg-binutils-2.30/bin/strip
stripping (with command strip and flags -S) in /nix/store/piildnjs6fyxngp6bhj1082l6wyh42lx-cargo-tree-0.19.0/bin
patching script interpreter paths in /nix/store/piildnjs6fyxngp6bhj1082l6wyh42lx-cargo-tree-0.19.0
checking for references to /build in /nix/store/piildnjs6fyxngp6bhj1082l6wyh42lx-cargo-tree-0.19.0...
/nix/store/piildnjs6fyxngp6bhj1082l6wyh42lx-cargo-tree-0.19.0

Success on x86_64-darwin (full log)
Attempted: cargo-tree
Partial log (click to expand)
running 0 tests

test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out

installing
post-installation fixup
strip is /nix/store/7ddbq63v97nk8gkbf7gcsfmby37h6gbl-cctools-binutils-darwin/bin/strip
stripping (with command strip and flags -S) in /nix/store/cz8dqk6hf4mcqq7pn8hxnwajfn9xnk2z-cargo-tree-0.19.0/bin
patching script interpreter paths in /nix/store/cz8dqk6hf4mcqq7pn8hxnwajfn9xnk2z-cargo-tree-0.19.0
/nix/store/cz8dqk6hf4mcqq7pn8hxnwajfn9xnk2z-cargo-tree-0.19.0


[BUG]: Make the website Multilingual

Is there an existing issue for this?

[X] I have searched the existing issues

Describe the bug
Feature Request: We need to implement multilingual support for the Agrotech AI website to make it accessible to a wider audience, especially farmers from various regions.
Expected behavior
Proposed Solution:
Language Files: Create JSON/YAML files for different languages (e.g., English, Hindi, etc.).
Example: en.json, hi.json, etc., containing key-value pairs for translated text.
Language Switcher: Implement a language switcher (dropdown or buttons) for users to choose their preferred language.
Dynamic Content Loading: Modify the frontend to load text dynamically based on the selected language. This could involve using JavaScript frameworks or libraries like i18next or vanilla JS.
Multilingual SEO: Ensure the URLs and metadata reflect the selected language for SEO purposes (e.g., example.com/en/, example.com/hi/).
Add ScreenShots
No response
On which device are you experiencing this bug?
No response
Record

[X] I have read the Contributing Guidelines
[X] I'm a GSSOC'24 contributor
[X] I have starred the repository

hi @Swarali1107 ..thank you so much for showing interest in this project and your idea is excellent ...can you implement it using google translate modeule....because in previous project we have have already tried your idea using i18next...for that we have faced so many problems as the project size increases...so it is better to implement that by using google translate...
take referece from this repo...
https://github.com/VaibhavArora314/StyleShare
we have shifted from  i18next to google translate...check this repo once...
please let me know if any information is needed...

Great...I will work on it today and will report to you till evening

@manikumarreddyu I have mailed you about the issue...kindly check my mail and reply

Hi,
I hope you're doing well. I wanted to ask you about the Google Translate
API integration for the multilingual support feature. While the API does
offer a free tier, it requires a billing account to be set up. The free
tier allows up to 500,000 characters per month at no cost. However, if the
usage exceeds that, charges will be applied.
Could you please confirm whether you would like me to proceed with the free
version, with careful monitoring of usage, or if you’d prefer the paid
version for larger-scale usage without restrictions?
In free version I think Microsoft translator (azure) will be better ...as
it allows 2M character per month
Once I receive your confirmation, I can move forward accordingly.
Looking forward to your response.
On Wed, Oct 2, 2024, 7:52 AM manikumarreddyu @.***>
wrote:

Assigned #52 https://github.com/manikumarreddyu/AgroTech-AI/issues/52
to @Swarali1107 https://github.com/Swarali1107.
—
Reply to this email directly, view it on GitHub
https://github.com/manikumarreddyu/AgroTech-AI/issues/52#event-14481889993,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/BCRZYDI7ZNSUQC7EFKWN4J3ZZNKHDAVCNFSM6AAAAABPGEXGO6VHI2DSMVQWIX3LMV45UABCJFZXG5LFIV3GK3TUJZXXI2LGNFRWC5DJN5XDWMJUGQ4DCOBYHE4TSMY
.
You are receiving this because you were assigned.Message ID:
@.***>

hi ,
@Swarali1107 please dont go for paid versions...try to use free versions only..if they ask you to give credit/debit card details..please dont give.i dont want to put you in risk beacuse of this task.
https://github.com/VaibhavArora314/StyleShare/blob/main/frontend/src/components/GoogleTranslate.tsx
check this once...i think they have not used any api keys..not sure..but you check it once.
thank you

hey @Swarali1107   thanks you so much for showing interest in AgroTech AI..looking for more contributions from your side.

hi @Swarali1107 any updates ?


Boolean on the last line should be: $true

See title
# Create a storage account with AllowBlobPublicAccess set to true (or null).
New-AzStorageAccount -ResourceGroupName $rgName `
    -Name $accountName `
    -Location $location `
    -SkuName Standard_GRS `
    -AllowBlobPublicAccess $false

[Enter feedback here]

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

ID: a299cd29-143b-c263-7996-3467035b8937
Version Independent ID: a8a1d0d0-411e-44eb-51da-c1f8ab90befa
Content: Configure anonymous public read access for containers and blobs - Azure Storage
Content Source: articles/storage/blobs/anonymous-read-access-configure.md
Service: storage
Sub-service: blobs
GitHub Login: @tamram
Microsoft Alias: tamram

@slashd
Thanks for your feedback! We will investigate and update as appropriate.


Compiler dose not fully support the code presented

Type of issue
Code doesn't work
Description
Compiler from web-browser offered by you, dose not support to create a collection with "[ ]" syntax
[Enter feedback here]
Page URL
https://learn.microsoft.com/en-us/dotnet/csharp/language-reference/operators/nameof
Content source URL
https://github.com/dotnet/docs/blob/main/docs/csharp/language-reference/operators/nameof.md
Document Version Independent Id
7c19d7e6-f241-2f7e-9dad-737df8328663
Article author
@BillWagner
Metadata

ID: d4b82de3-3121-209c-6dc4-6267f726dcfe
Service: dotnet-csharp
Sub-service: lang-reference

Thanks @cirmaciuadrian
I've opened a PR to fix this issue.


Fula client enc dec

Changed the chunking process in both encryption in the file protocol and decryption in the fula-client.
It is now aligned with the go-fula.

The last commit (d75d0e8) is fixing the issue in testling exit. It returning status code 1 causes the box to somehow not be able to accept further connections from web.


PayForCombiningItems: false option doesn't work

The config option PayForCombiningItems: false does not work in all cases. If at least one piece of armour is damaged, you will still be rewarded for combining the items:
https://imgur.com/a/T5dBdaC
It's because you just check wether there are two equal items next to each other while iterating through inventory: 466b1ce#diff-e094452f709d92d9ec5f71a3e933b6f8R588
Unfortunatly we have no idea how to fix it so we can't open a pullrequest. Hopefully you can fix this issue :)
Jobs 4.16.2
Paper 1.16.3 - 204

Can't reproduce, works like a charm here. There are another commit for it: https://github.com/Zrips/Jobs/commit/9545af4dd656a0598e555840f8bcd37b9146ad53#diff-e094452f709d92d9ec5f71a3e933b6f8 which is working.

Yeah, I linked the wrong commit, sorry. But the latest commit doesn't work either. Here is my testsetup:

Jobs 4.16.2
Paper 1.16.3 - 204

I still don't get any of job xp increase when I'm repairs an item. I think you have duplicated diamond_pickaxe with repair action given in jobConfig.

We have no duplicate entries in jobConfig. I have just checked it. Also, the payment does not come from the repair action, but from the crafting action. Furthermore the crafted result is not taken out of the field with shift, but dragged and dropped from the crafting field into the inventory.

Did you forget to commit some changes?
https://github.com/Zrips/Jobs/blob/master/pom.xml#L8 is building 4.16.1 versions. Maybe some other changes are not up to date yet.

We made a mistake testing it, it works like a charm! Thank you :)

Did you forget to commit some changes?
https://github.com/Zrips/Jobs/blob/master/pom.xml#L8 is building 4.16.1 versions. Maybe some other changes are not up to date yet.


os: os.DirFS doesn't work with Windows UNC paths

What version of Go are you using (go version)?

$ go version
go version go1.19 linux/amd64

Does this issue reproduce with the latest release?
Yes
What operating system and processor architecture are you using (go env)?
I build on Linux and run on Windows (Microsoft Windows [Version 10.0.19044.1889])
go env Output
$ go env
GO111MODULE=""
GOARCH="amd64"
GOBIN=""
GOCACHE="/home/patrik/.cache/go-build"
GOENV="/home/patrik/.config/go/env"
GOEXE=""
GOEXPERIMENT=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOINSECURE=""
GOMODCACHE="/home/patrik/go/pkg/mod"
GONOPROXY="REDCATED"
GONOSUMDB="REDCATED"
GOOS="linux"
GOPATH="/home/patrik/go"
GOPRIVATE="REDACTED"
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/usr/local/go"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/usr/local/go/pkg/tool/linux_amd64"
GOVCS=""
GOVERSION="go1.19"
GCCGO="gccgo"
GOAMD64="v1"
AR="ar"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD="/home/patrik/REDACTED/go.mod"
GOWORK=""
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -Wl,--no-gc-sections -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build4002045871=/tmp/go-build -gno-record-gcc-switches"

What did you do?
I created a test program that tries to walk the root dir. I test it with a normal path and also a UNC path.
The program gives the expected output on Linux using wine, but on a real Windows machine it doesn't work.
I created my own "fixed" implementation of os.DirFS that seems to solve the issue.

package main

import (
	"fmt"
	"io/fs"
	"os"
	"path/filepath"
	"runtime"
)

func main() {
	runTests()
}

func runTests() {
	type testT struct {
		name string
		fs   fs.FS
	}
	tests := []testT{
		{name: "Normal path 1", fs: os.DirFS("C:\\")},
		{name: "UNC Path 1", fs: os.DirFS("\\\\?\\C:\\")},
		{name: "Normal path 2", fs: OSDirFS("C:\\")},
		{name: "UNC Path 2", fs: OSDirFS("\\\\?\\C:\\")},
	}
	for _, t := range tests {
		fmt.Println("Testing:", t.name)
		err := testFS(t.fs)
		if err != nil {
			fmt.Println("Error:", err)
		} else {
			fmt.Println("OK")
		}
	}
}

func testFS(tfs fs.FS) error {
	err := fs.WalkDir(tfs, ".", func(path string, d fs.DirEntry, err error) error {
		if err != nil {
			return err
		}
		return fmt.Errorf("dummy")
	})
	if err != nil && err.Error() != "dummy" {
		return err
	}
	return nil
}

type osDirFS string

func OSDirFS(dir string) fs.FS {
	return osDirFS(dir)
}

func containsAny(s, chars string) bool {
	for i := 0; i < len(s); i++ {
		for j := 0; j < len(chars); j++ {
			if s[i] == chars[j] {
				return true
			}
		}
	}
	return false
}

func (dir osDirFS) Open(name string) (fs.File, error) {
	if !fs.ValidPath(name) || runtime.GOOS == "windows" && containsAny(name, `\:`) {
		return nil, &fs.PathError{Op: "open", Path: name, Err: fs.ErrInvalid}
	}

	f, err := os.Open(filepath.Join(string(dir), filepath.FromSlash(name)))
	if err != nil {
		return nil, err // nil fs.File
	}
	return f, nil
}

func (dir osDirFS) Stat(name string) (fs.FileInfo, error) {
	if !fs.ValidPath(name) || runtime.GOOS == "windows" && containsAny(name, `\:`) {
		return nil, &fs.PathError{Op: "stat", Path: name, Err: fs.ErrInvalid}
	}
	f, err := os.Stat(filepath.Join(string(dir), filepath.FromSlash(name)))
	if err != nil {
		return nil, err
	}
	return f, nil
}

What did you expect to see?
I expected the UNC path with fs.WalkDir() to work.
What did you see instead?
It gives me an error: CreateFile \\?\C:\/.: The filename, directory name, or volume label syntax is incorrect.
Seems like Windows doesn't like forward slashes in UNC paths.
Testing: Normal path 1
OK
Testing: UNC Path 1
Error: CreateFile \\?\C:\/.: The filename, directory name, or volume label syntax is incorrect.
Testing: Normal path 2
OK
Testing: UNC Path 2
OK

Suggested fix
I think the os.DirFS implementation should convert the forward style slashes of the fs.FS implementation to platform native path separators before sending the function calls off to the os.Open() and os.Stat().

@PatrLind Can you try replacing / with string(PathSeparator) of the Open Stat method, what happens.

see also #44279

@rsc @iant, not sure what the best plan here is.
The fix recommended in the bug report does work, but creates an import cycle, which is unfortunate.  A certain amount of code shuffling would fix that.
The fix recommended in https://go.dev/cl/425876 seems to not be enough.

We can't import path/filepath but the functions being used are trivial, so let's just copy them into the os package.  Only not literally because "os" shouldn't import "strings" either.
Does https://go.dev/cl/426094 fix the problem?

We can't import path/filepath but the functions being used are trivial, so let's just copy them into the os package. Only not literally because "os" shouldn't import "strings" either.
Does https://go.dev/cl/426094 fix the problem?

I think it is a feasible and good solution.


cf push should print upload progress

cf push should show upload progress. At the moment it just prints "Uploading XXX..." and for large applications it looks like it has hanged, although it's still uploading.

We added progress indicators (see https://github.com/cloudfoundry/cli/issues/236).  What version of the CLI do you have (cf -v)??