Prefer double-quotes

Using single quotes is permitted if their semantics are needed. In all other cases, double quotes are used.
Thoughts? @cam156 @mtribone

I generally use double quotes for strings, me thinks, but I'll look at the files to get an idea of the style corrections.

@awead unfortunately I merged an earlier PR which now causes conflicts with this.

@cam156 no worries. it's easy to redo!


feat(upgrade): upgrade wharfie Go dep to v0.6.8

Problem:

Relates to https://github.com/harvester/harvester-installer/pull/887, but now bump Wharfie's Go dependency version to v0.6.8. Other updates are due consequences of go mod tidy and go mod vendor.
Solution:

Related Issue:
Test plan:

PTAL @bk201 and let me know if I should backport this now or wait for tull tests.


Workflow Instance: Logs horizontal scrolling not working

Problem description
If logs exceed the width of the log output window, there is no way to scroll horizontally. The same issue exists in the full-screen mode of the logs.

Please let me know how I can reproduce this bug, I did try but not found how to reproduce this

Example Workflow:
states:
- id: hello
  type: noop
  log: "helloworldhelloworldhelloworldhelloworldhelloworldhelloworldhelloworldhelloworldhelloworldhelloworldhelloworldhelloworldhelloworldhelloworldhelloworldhelloworldhelloworldhelloworldTHISISTHEEND"

This seems like a more complicated issue than I had initially suspected.
If I add logic for the log lines to wrap, the row grows higher than the parent List/AutoSizer components support, and it spills over the next log line.
If I add logic for the individual log lines to honour their own full width while keeping it to a single-line element, the parent List element doesn't seem to support horizontal scrolling.

not worth fixing, edge case


Problem using with replace loaders

Hello,
So I have a seemingly easy case - I want to replace a string in a html file, which is later processed by the HtmlWebpackPlugin. The problem is, after replacing, the plugin throws:
ERROR in ./~/html-webpack-plugin/lib/loader.js!./src/index.html     Module parse failed (...)  Unexpected token (1:0)     You may need an appropriate loader to handle this file type.
I have even opened a stackoverflow question describing that issue:
https://stackoverflow.com/questions/38359842/use-html-webpack-plugin-with-string-replace-loader-in-webpack
I tried multiple loaders for that but all acted the same way. I started to dive into the source of this plugin, but I figured you guys may be able to help me with that.
Best

+1

Hi, it's not a problem with HtmlWebpackPlugin directly. For more details you can check my answer  on stackoverflow.

Nice one - do you think we could improve the html-webpack-plugin somehow to improve the error message - so that people can find this easier?


在微信小程序中能使用吗？

Please make sure you are testing with the latest release of html2canvas.
Old versions are not supported and issues reported for them will be closed.
Please follow the general troubleshooting steps first:

[ ] You are using the latest version
[ ] You are testing using the non-minified version of html2canvas and checked any potential issues reported in the console

Bug reports:
Please replace this line with a brief summary of your issue AND if possible an example on jsfiddle.
Specifications:

html2canvas version tested with:
Browser & version:
Operating system:

在微信小程序中能使用吗？

same problem


Adding GuardedSwiftyJSON

Project URL
https://github.com/wiggzz/GuardedSwiftyJSON
Description
Just added GuardedSwiftyJSON library. This library is pretty simple and adds an initialisation protocol for SwiftyJSON that makes creating failable initialisers for object models simpler and easier.
Checklist

[x] Only one project/change is in this pull request
[x] Addition in chronological order (bottom of category)
[x] Supports iOS 7 or later
[x] Has a commit from less than 2 years ago
[x] Has a clear README in English

Thanks for contributing, @wiggzz!


Step time increasing as training progresses

In one of the longer training runs that is now running on a tpu-v3-8 I noticed the training ETA kept getting later and later.
Also in the step-time wandb log (picture below) the higher the step number, the longer the lookup time.

Any ideas what could be the cause? I looked a bit at DataLoader prefetch_factor but its only available when using multiprocessing / num_workers > 0
PS: Thanks for creating EasyDel - its amazing what you've created!

hello
thank you :).
and about the issue can i have access to your training arguments (like batch size and etc)
and i would also like to have screen shot of you buffer size chart in WANDB.

For this specific run the config was like this.
(looking at it, maybe it is due to the shuffle() operation?) -- unfortunately TRC access ended today, will retry without shuffle after renewing.
dataset_train = datasets.load_dataset("yhavinga/nedd_x_chat_instruct_tokenized_zephyr_7b_alpha_padright__b1_", split="train").shuffle()
context_length = len(dataset_train[0]['input_ids'])  # 1024
print(f"Using context length of {context_length}")

tokenizer = AutoTokenizer.from_pretrained(tokenizer_id, trust_remote_code=True)
model, params = AutoEasyDelModelForCausalLM.from_pretrained(model_id)
config = model.config
config.freq_max_position_embeddings = config.max_position_embeddings  # 32768
config.max_position_embeddings = context_length
config.c_max_position_embeddings = config.max_position_embeddings

max_length = config.max_position_embeddings

train_args = TrainArguments(
    model_class=EasyDel.FlaxMistralForCausalLM,
    configs_to_init_model_class={
        'config': config,
        'dtype': jnp.bfloat16,
        'param_dtype': jnp.bfloat16,
        'input_shape': (1, 1)
    },
    custom_rule=config.get_partition_rules(True),
    model_name='TowerDutchTest',
    num_train_epochs=1,
    learning_rate=1e-5,
    learning_rate_end=1e-6,
    optimizer=EasyDelOptimizers.ADAMW,
    scheduler=EasyDelSchedulers.WARM_UP_LINEAR,
    warmup_steps=500,
    weight_decay=0.1,
    total_batch_size=2,
    max_steps=48000,
    save_steps=8000,
    do_train=True,
    do_eval=False,
    backend='tpu',
    max_length=max_length,
    gradient_checkpointing=EasyDelGradientCheckPointers.NOTHING_SAVEABLE,
    sharding_array=(1, -1, 1, 1),
    use_pjit_attention_force=False,
    use_flash_attention=False,
    gradient_accumulation_steps=8,
    remove_ckpt_after_load=True,
    ids_to_pop_from_dataset=['token_type_ids'],
    loss_remat="",
    dtype=jnp.bfloat16
)

Wandb link : https://wandb.ai/yepster/EasyDeL-TowerDutchTest/runs/6cweckwk/workspace

To check if shuffling a dataset could cause these increasing times I plotted per sample reading time of a HF shuffled dataset. This is reading with an iterator, but indexed lookup looked almost the same

I don't see any issue with your configurations and I guess it might be related to any of the back processes that you might be running or your kernel running for you I have pre-trained more than 10+ models and this is the first time I'm seeing buffer size increasing over time

Do you have any suggestion for me to fix your issue, i guess you can try disabling shuffle in TrainingArguments and see if the buffer size is still increasing.

this issue is being closed due to no response has been given

Got renewed TRC access and looked into it a bit more. I tried a couple of things:

replace jnp with np in the data-collator: synthetic test showed per loop time much faster than jnp, unfortunately didn't seem to solve increasing step time.
replace jnp with np in the train loops perplexity calculation
commented out mean loss and mean accuracy stats - arrays they operate on grow with step size
set track_mem to off

Result below:
green is unchanged easydel 0.0.42 tag
orange is with only change 1. on easydel from few days ago
red is with the four changes above, on easydel from few days ago

Hello and thank for letting me know where the issue is or how i can make it better
I have tried using numpy instead in jax numpy but that will cause issues and a lot of errors in multiple host training
If you want you can create a pull request from HEAD and make changes other wise you can tell me which parts exactly you want to be modified in order to make it more efficient.

I will do some more experimentation, I suspect only changing the mean calculations is sufficient. When finished I'll create a PR.


Verify identity-vectors.txt

identity-vectors.txt needs to be independently verified.

Hi @shanedk,
I've just tried verifying your identity (IDK) vectors using my implementation and think I found a problem: It seems you're also using the URL's "path" in your HMAC, instead of the host part only.
For example, for a "domain" of example.com/extended, only example.com should go into the hmac according to this:

Only when creating the signature, the path is taken into consideration.
Am I missing something?
Best regards,
Alex

Hi again, @shanedk,
it just occured to me that you are probably simulating the "x" parameter here - sorry for not thinking about that.
With the extended path taken into account, all test vectors pass my verification just fine.
Cheers, Alex

Yes, that's simulating the x-parameter. Thanks!


English translation should not fail the tests

I've realised that English translations (eng ISO code) for names fail the test. This is not ideal since there are names which originates from other countries but they may have English meanings.
Has there been any reasoning behind this @bluzi ?
PR #244 is a good example.

Hi @arminkhoshbin,
The goal of the project is not to translate meanings, it's to spell the name in different languages. The name field should contain the English spelling, and the translations should contain a map of language code and the spelling of that name in this language.
Does this answer your question? What do you think about that?

@bluzi, isn't the example in your comment a file with a non-English spelling in the name field? I think this demonstrates an issue: if we only allow English spellings to have their own files, we prevent non-English aliases that don't directly translate to an English name from being added.
Maybe that's what you want, if it's meant to be a database of primarily English names.

@roastchicken
I want the collection to contain names from all origins, that's for sure.
My vision is having all kind of names, translated to all languages.
For standardization reasons, I thought it'll be best if the title for each name will be its English translation, and each name will have an array of different spellings.
You can add names from other origins (like I did with yoni), but you can't add names spelled in languages other then English (for example, you can't add the name יוני, which is Hebrew for yoni)
So the format in the comment you attached is valid, you can add an Hebrew name, but it should be spelled in English, and it may have translations to any language you want.

So just to confirm @bluzi you can have names from other origins but they need to be spelled in English and you can have translations to any language including English? If that's the case then the translation test needs to be updated because having an English translation will fail it.

@bluzi I guess I misinterpreted Yoni. I thought that spelling was not the Engish spelling. I can't think of an example, and maybe no such names exist, but I have a feeling there are names that don't have a direct match in English. But I guess that isn't exactly related to this issue, because such names wouldn't have English translations either.
@arminkhoshbin if all names are spelled in English in the name field, what would be the point in having an English translation? Wouldn't that just be duplicate data?

Not necessarily @roastchicken. Take the name Santiago or other aliases of it like Diego as an example. It is of Spanish origin but when translated to English it's James. As a matter of fact the name James is a really common name with many forms in other languages.
https://en.wikipedia.org/wiki/Santiago_(name)
https://spanish.stackexchange.com/questions/4588/why-is-santiago-the-equivalent-of-james

@arminkhoshbin could you show me an example file where you would need an English translation? Or are you refuting my first point? I'm having trouble imagining a scenario where an English translation would be necessarily or helpful.

@roastchicken https://github.com/bluzi/name-db/pull/244/files

@arminkhoshbin but @bluzi said the name field should be in English. So that file would be something like this:
{
    "name": "james",
    "meaning": "the one that changes",
    "aliases": ["jacob", "jacobo", "diego"],
    "translations": {
        "spa": "santiago"
    }
}

Thanks @roastchicken. I think you're right. In other words if any name has an English translation then the translation can have its own JSON file. Closing this issue now.

@arminkhoshbin that's correct. The English translation is the name property, and if a name has more than one English translation, it should have its own file.
Are you completely satisfied with this behavior? If you have any comments, please let me know

Yes. All sorted now @bluzi 👍

Good :)
Feel free to create more discussions like this one, I feel like it's good to talk about this kind of stuff.
Also, if you feel like the documentation could be more clear about this matter, feel free to improve it if you want to
@arminkhoshbin @roastchicken


Add MilkmApp

Entry type

New addition

App info
Name: MilkmApp
Description: UI for Milkman orders
URL: https://cow-tools-bleu-fi.vercel.app
Icon: https://github.com/bleu-fi/monorepo/tree/376d43802837f9dcdd75e132a474a2171654699e/apps/cow-tools/public
Homepage:
Twitter: https://twitter.com/cowswap
GitHub: https://github.com/bleu-fi
Discord: https://discord.gg/aRt9t9n3
Supported networks
- Mainnet

Revision checks

[x] Used smart contracts were audited.
[x] Your Safe App include a manifest.json file at the root with the required data.
[x] The app can be loaded as a custom Safe App in the Apps section of https://app.safe.global.
[x] The app auto-connects to the Safe.
[x] You are able to trigger and execute one transaction with a Safe.
[x] RPC requests are optimized (not triggering many requests in a very short time period).

Audit document
https://github.com/charlesndalton/milkman/blob/main/g0audit.pdf
Code for review
https://github.com/bleu-fi/monorepo/tree/main/apps/cow-tools
Team information
Company: blue
Email/Telegram<EMAIL_ADDRESS>

Thanks for reporting this. I didn't test the app with a Safe with multiple queued transactions. Now I am filtering the ones that aren't relevant. Can you test it again?

Looks good, thank you! I'll enable both apps shortly.

Also could you provide an icon URL that is not hot-linking to GitHub? Ideally hosted on the same domain as the app.

Enabled the app, thank you for the contribution!
https://app.safe.global/share/safe-app?appUrl=https%3A%2F%2Fcow-tools-bleu-fi.vercel.app&chain=eth


[TC_PCC_2_3] Re-enabled disabled TC's

Problem

Some TC were disabled due to missing implementation

Change overview

The implementation is done, now re-enable the TC's

Testing

Not tested in the TestHarness but manually using chip-tool

Needs to regenerate tests.  Either regen everything or:
./scripts/tools/zap/generate.py -t examples/chip-tool/templates/tests/templates.json -o zzz_generated/chip-tool/zap-generated src/controller/data_model/controller-clusters.zap

./scripts/tools/zap/generate.py -t src/darwin/Framework/CHIP/templates/tests/templates.json src/controller/data_model/controller-clusters.zap

 ./scripts/tools/zap/generate.py src/controller/data_model/controller-clusters.zap -t examples/chip-tool-darwin/templates/templates.json -o zzz_generated/chip-tool-darwin/zap-generated

Remeber this will fail if PR #17181 is not merged prior to this one.

Delta of this PR looks like 0 files changed.
@tlykkeberg-grundfos should we close or is this missing some commits?

Delta of this PR looks like 0 files changed.
@tlykkeberg-grundfos should we close or is this missing some commits?

Hi @andy31415 this seems to have arrived at the repo thru this commit: https://github.com/project-chip/connectedhomeip/commit/b4e425755d76efcaee1ebd0f82d5aac34c842474, so yes we can safely close this PR. Thanks for noticing it.


Text input with enter_returns_true doesn't commit full string

Describe the bug
If using a text input constructed with enter_returns_true(true), pressing Enter to commit the string results in the string getting truncated to old length + 1 characters.
To Reproduce
let mut my_string = String::new();
ui.input_text("My input", &mut my_string).enter_returns_true(true).build();

Expected behavior
Full string is committed.
Screenshots

Please describe your environment

imgui-rs version 0.8.0
Windows 10

Other information
Sometimes typing enough into a box will cause a crash due to heap corruption!

Can you give this a try on Main? I believe we fixed this already

I will test it once I get finished porting my code to be up to speed with the latest API breakage. I thought it was only yesterday that the API was moving away from ui.widget_name() to imgui::WidgetName::new() and now in the next release it's reversing course. I recognize that the API needs to be cleaned up (in particular I appreciate that we can use Rust native strings now) but this is far too many changes too quickly, many of which seem to be wholly arbitrary. It's getting exhausting having to constantly update every single instance of every widget invocation. Now imgui::Window::new(label).build(ui) doesn't work, so I have to replace it with imgui::Window::new(ui, label).build(). Which by the way is not the same argument ordering as imgui::MenuItem::new() so I get to look forward to that breaking in the future too.

Seems to be fixed.

Would it be at all possible to get the text buffer fixes cherry-picked into a hotfix on crates.io? I'd like to be able to put out a fixed editor and continue working on my engine without having to deal with the current breakage in main.

I think I'm okay with a cherry picked 0.8.1 on crates.io. you're not the only one who has ran into this.
We also have the issue with the free type feature, and I'd like to fix them both at once. I'll talk to Thom and get this sorted over the weekend

Nice! Thanks for the update, and sorry about the duplicate issue!

Hi, any news on this? I need to have working enter_returns_true, since otherwise every letter typed could trigger a package load in my editor which may create a pop-up error message, which would be even more disruptive than this bug.

Hi, I was wondering if there's anything I can do to help get this moving along faster? If an official hotfix release isn't made I might need to make my own crate with the fix. As much as I really dislike the idea of polluting the crates.io package namespace with a third party hotfix stopgap for a specific version of a specific crate, it would at least allow me to continue with my own work. It would also force consumers of imgui to point to the fork crate in Cargo.toml and modify their code to use the forked crate's name if they need to use it with another library that depends on said fork...
Might also want to look into getting an entry filed with rustsec/advisory-db and version 0.8.0 yanked since this is technically a heap corruption bug.

I've made at attempt at finding the relevant bugfixes from main (there was a lot more commits since 0.8 than I thought!) and have made #581
Could you give it a go and check it resolves the problem:
[patch.crates-io]
imgui = { git = "https://github.com/imgui-rs/imgui-rs.git", rev = "1159344386d42202db984d40f0e42c8b1716f836" }
imgui-sys = { git = "https://github.com/imgui-rs/imgui-rs.git", rev = "1159344386d42202db984d40f0e42c8b1716f836" }

Did some preliminary testing and it seems to be working. I can paste and commit text and it accepts the whole thing without crashing.

After a lot of delays, busy lives, and a confused bunch of 0.8 patch releases, these fixes should now definitely be out in v0.9, and future patch releases should be a lot smoother :sweat:


Rustup, fix rustdoc sysroot issue

This uses a different approach to resolve https://github.com/rust-lang/miri/issues/3404: we entirely move the responsibility of setting miri-sysroot to whatever invokes the Miri driver.  cargo-miri knows whether it is inside rustdoc or not and can adjust accordingly. I previously avoided doing that because there are a bunch of places that are invoking the driver (cargo-miri, the ui test suite, ./miri run, ./x.py run miri) and they all need to be adjusted now. But it is also somewhat less fragile as we usually have more information there -- and we can just decide that ./miri run file.rs --sysroot path is not supported.

@bors r+

:pushpin: Commit d23df545a4403708a4dfea2f6285f51a4c551e23 has been approved by RalfJung
It is now in the queue for this repository.

:hourglass: Testing commit d23df545a4403708a4dfea2f6285f51a4c551e23 with merge 5e9a025ef173c5e8df83d5fecb3114413fcf002f...

:broken_heart: Test failed - checks-actions

Closing in favor of https://github.com/rust-lang/miri/pull/3411 which is just the cargo-miri changes without the rustup. (That won't make it work, but it makes more sense to keep that around as a draft.)


Issues Making on Windows 7

Hi all.
I have Windows 7, and I use Cygwin to work on my Pokemon ROM hack.
I want to make custom sprites, so I need a way to convert png to 2bpp.
I thus tried to install and make rgbds to use the rgbgfx function.
I added the depencies via Cygwin, and in Cygwin I do
cd rgbds
then
make.
But then this comes up.
src/asm/asmy.y: warning: 1 shift/reduce conflict [-Wconflicts-sr]src/asm/asmy.y: warning: 3 reduce/reduce conflicts [-Wconflicts-rr]
The files make, but I cannot open them.
Please help if you can :D

That warning is a know issue and it shouldn't affect you: https://github.com/rednex/rgbds/issues/44
Can you build the ROM without modifying anything?

@ChefFloyardee Any comments?

I found a program that converts the files for me, so I would call this resolved.

Which program? If there is still a problem with rgbgfx it would be nice to know. I guess you tried with the prebuilt binaries? https://github.com/rednex/rgbds/releases/tag/v0.3.8

It is called "SNES Converter".
I think the pre-built works as well though, so maybe I do not even need it.

Well, if you have an error message to show regarding the compilation of rgbgfx (try compiling with make Q=) it would be useful to have it here. Most likely it's a problem related to missing libpng. If not, it's better to close this issue.

If there is more information we can reopen this, but closing it for now.


Rename models/Providers.py to follow snake case convention

🐛 Describe the bug
listed file name should follow snake case convention.
Also handle the related imports of this file and make sure that everything works.

@taranjeet one thing, here the name should be like this -> small letter P -> p only right?

yes, small p


Use fs_err for better file operation error message

fs_err is thin wrapper around std::fs, that provides more helpful messages on errors.
Take #727 as an exmaple,
before:
error: No such file or directory (os error 2)

after:
error: failed to create file `/tmp/rye/config.toml`

Caused by:
    No such file or directory (os error 2)

I will add something like this but I need to check first how fs_err works. I would probably prefer actually wrapping the IO error myself in rye.


KL-vanishing issue and another idea

Hi Mathis
Thanks for sharing the implementation. I have two issues:

If I understand correctly, this work can be treated as a sequence VAE model used to learn distributions from observations. The KL-divergence loss term encourages the learned distribution to be as close as to a normal distribution. So have you ever encountered  the KL-vanishing (KL loss = 0) issue? If yes, how have you solved it ?

Instead of feeding the sampled code z merely to Transformer decoder block, how about to adding it to all tokens for the decoder input sequence (plus with the position embeddings)?

Thanks

Hello Fanta007

If I understand correctly, this work can be treated as a sequence VAE model used to learn distributions from observations.

Yes, it is sequence level VAE; it encodes all the sequence into one representation which not depend one time.

So have you ever encountered the KL-vanishing (KL loss = 0) issue? If yes, how have you solved it ?

At the beginning, I struggled a bit to train it, because I was looking for too high values for lambda_kl parameter, and so I had mode collapsing. When I tried very low value, like 1e-7, it begin to work well.

Instead of feeding the sampled code z merely to Transformer decoder block, how about to adding it to all tokens for the decoder input sequence (plus with the position embeddings)?

I think I already tried something similar during my prototypes, but it was at the beginning and it didn't work well.


Readme.md - Link for sign up for a Chimoney developer account  Repo in obtaining API keys Section is not working

@phyleria , can I work on the issue?

Sure, go ahead.

Thank you @phyleria !

@phyleria , I have mentioned you on the PR I submitted for this issue.


Errors (typo) in roles names

Errors in roles names:

Group Administrator
Directory Writer
Should be:
GroupS Administrator
Directory WriterS

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

ID: e3fb85a8-d842-f101-909e-86751922da43
Version Independent ID: 0c99b5ef-753e-1085-a682-c55ea4059207
Content: Enforce group naming policy in Azure Active Directory
Content Source: articles/active-directory/enterprise-users/groups-naming-policy.md
Service: active-directory
Sub-service: enterprise-users
GitHub Login: @curtand
Microsoft Alias: curtand

@Yan-Son thanks for calling this out. Fixing this.

I made a pull request to fix this. https://github.com/MicrosoftDocs/azure-docs-pr/pull/169964
Ref: https://docs.microsoft.com/en-us/azure/active-directory/roles/permissions-reference


fix: made the QR code scannable for even shorter lightning addresses

Describe the changes you have made in this PR
The QR code in the receive screen is not scannable when the lightning address name is <=3 characters. The issue might be due to the addition of avatar on the QR code. Few changes to fix this issue might be - increase the QR size, decrease the avatar size, Increase the error correction.
I increased the EC level as this seemed to be the best approach for it.
Link this PR to an issue
Fixes #2774
Type of change

fix: Bug fix (non-breaking change which fixes an issue)

Screenshots of the changes [optional]
These are few lightning addresses which can be used to test whether the QR is working after this change(hardcoded).

How has this been tested?
Hardcoded the lightning address and checked whether it is working for lightning addresses with less than three characters.
Checklist

[x] Self-review of changed code
[x] Manual testing

@rolnz can you please review this PR.
Thanks!


Open-source model definitions

Hey @gabgoh,
Super cool that you're open-sourcing the consistency decoder of Dalle-3 with a MIT license :heart:
Any chance you can also add the model definitions of the torch.jit binary? Otherwise it'll be quite difficult to port the model to other libraries.

I can try to get a more human readable version of this pushed, but does decoder_consistency.ckpt.code work for the time being? The complete model definition is in there.

It is not quite as readable, as you need to plumbing through varies wrappers, for example, you get at high-level:
class ConvUNetVAE(Module):
  __parameters__ = []
  __buffers__ = []
  training : bool
  _is_full_backward_hook : Optional[bool]
  blocks : __torch__.torch.nn.modules.container.ModuleDict
  def forward(self: __torch__.dalle_runner_api.model_infra.modules.public_diff_vae.ConvUNetVAE,
    x: Tensor,
    t: Tensor,
    features: Tensor) -> Tensor:
    blocks = self.blocks
    output = blocks.output
    blocks0 = self.blocks
    up_0_conv_3 = blocks0.up_0_conv_3
    blocks1 = self.blocks
    up_0_conv_2 = blocks1.up_0_conv_2
    blocks2 = self.blocks
    up_0_conv_1 = blocks2.up_0_conv_1
    blocks3 = self.blocks
    up_0_conv_0 = blocks3.up_0_conv_0
    blocks4 = self.blocks
    up_1_upsamp = blocks4.up_1_upsamp
    blocks5 = self.blocks
    up_1_conv_3 = blocks5.up_1_conv_3
    blocks6 = self.blocks
    up_1_conv_2 = blocks6.up_1_conv_2
    blocks7 = self.blocks
    up_1_conv_1 = blocks7.up_1_conv_1
    blocks8 = self.blocks
    up_1_conv_0 = blocks8.up_1_conv_0
    blocks9 = self.blocks
    up_2_upsamp = blocks9.up_2_upsamp
    blocks10 = self.blocks
    up_2_conv_3 = blocks10.up_2_conv_3
    blocks11 = self.blocks
    up_2_conv_2 = blocks11.up_2_conv_2
    blocks12 = self.blocks
    up_2_conv_1 = blocks12.up_2_conv_1
    blocks13 = self.blocks
    up_2_conv_0 = blocks13.up_2_conv_0
    blocks14 = self.blocks
    up_3_upsamp = blocks14.up_3_upsamp
    blocks15 = self.blocks
    up_3_conv_3 = blocks15.up_3_conv_3
    blocks16 = self.blocks
    up_3_conv_2 = blocks16.up_3_conv_2
    blocks17 = self.blocks
    up_3_conv_1 = blocks17.up_3_conv_1
    blocks18 = self.blocks
    up_3_conv_0 = blocks18.up_3_conv_0
    blocks19 = self.blocks
    mid_conv_1 = blocks19.mid_conv_1
    blocks20 = self.blocks
    mid_conv_0 = blocks20.mid_conv_0
    blocks21 = self.blocks
    down_3_conv_2 = blocks21.down_3_conv_2
    blocks22 = self.blocks
    down_3_conv_1 = blocks22.down_3_conv_1
    blocks23 = self.blocks
    down_3_conv_0 = blocks23.down_3_conv_0
    blocks24 = self.blocks
    down_2_downsamp = blocks24.down_2_downsamp
    blocks25 = self.blocks
    down_2_conv_2 = blocks25.down_2_conv_2
    blocks26 = self.blocks
    down_2_conv_1 = blocks26.down_2_conv_1
    blocks27 = self.blocks
    down_2_conv_0 = blocks27.down_2_conv_0
    blocks28 = self.blocks
    down_1_downsamp = blocks28.down_1_downsamp
    blocks29 = self.blocks
    down_1_conv_2 = blocks29.down_1_conv_2
    blocks30 = self.blocks
    down_1_conv_1 = blocks30.down_1_conv_1
    blocks31 = self.blocks
    down_1_conv_0 = blocks31.down_1_conv_0
    blocks32 = self.blocks
    down_0_downsamp = blocks32.down_0_downsamp
    blocks33 = self.blocks
    down_0_conv_2 = blocks33.down_0_conv_2
    blocks34 = self.blocks
    down_0_conv_1 = blocks34.down_0_conv_1
    blocks35 = self.blocks
    down_0_conv_0 = blocks35.down_0_conv_0
    blocks36 = self.blocks
    embed_image = blocks36.embed_image
    blocks37 = self.blocks
    embed_time = blocks37.embed_time
    input = torch.to(features, torch.device("cuda:0"), 6)
    features0 = torch.upsample_nearest2d(input, None, [8., 8.])
    x0 = torch.cat([x, features0], 1)
    _0 = (embed_time).forward(t, )
    _1 = (embed_image).forward(x0, )
    _2 = (down_0_conv_0).forward(_1, _0, )
    _3 = (down_0_conv_1).forward(_2, _0, )
    _4 = (down_0_conv_2).forward(_3, _0, )
    _5 = (down_0_downsamp).forward(_4, _0, )
    _6 = (down_1_conv_0).forward(_5, _0, )
    _7 = (down_1_conv_1).forward(_6, _0, )
    _8 = (down_1_conv_2).forward(_7, _0, )
    _9 = (down_1_downsamp).forward(_8, _0, )
    _10 = (down_2_conv_0).forward(_9, _0, )
    _11 = (down_2_conv_1).forward(_10, _0, )
    _12 = (down_2_conv_2).forward(_11, _0, )
    _13 = (down_2_downsamp).forward(_12, _0, )
    _14 = (down_3_conv_0).forward(_13, _0, )
    _15 = (down_3_conv_1).forward(_14, _0, )
    _16 = (down_3_conv_2).forward(_15, _0, )
    _17 = (mid_conv_1).forward((mid_conv_0).forward(_16, _0, ), _0, )
    _18 = (up_3_conv_0).forward(_17, _16, _0, )
    _19 = (up_3_conv_1).forward(_18, _15, _0, )
    _20 = (up_3_conv_2).forward(_19, _14, _0, )
    _21 = (up_3_conv_3).forward(_20, _13, _0, )
    _22 = (up_2_conv_0).forward((up_3_upsamp).forward(_21, _0, ), _12, _0, )
    _23 = (up_2_conv_1).forward(_22, _11, _0, )
    _24 = (up_2_conv_2).forward(_23, _10, _0, )
    _25 = (up_2_conv_3).forward(_24, _9, _0, )
    _26 = (up_1_conv_0).forward((up_2_upsamp).forward(_25, _0, ), _8, _0, )
    _27 = (up_1_conv_1).forward(_26, _7, _0, )
    _28 = (up_1_conv_2).forward(_27, _6, _0, )
    _29 = (up_1_conv_3).forward(_28, _5, _0, )
    _30 = (up_0_conv_0).forward((up_1_upsamp).forward(_29, _0, ), _4, _0, )
    _31 = (up_0_conv_1).forward(_30, _3, _0, )
    _32 = (up_0_conv_2).forward(_31, _2, _0, )
    _33 = (up_0_conv_3).forward(_32, _1, _0, )
    return (output).forward(_33, )

and how the blocks are defined has to be found here (in the decoder/code/__torch__/torch/nn/modules/container.py):
class ModuleDict(Module):
  __parameters__ = []
  __buffers__ = []
  training : bool
  _is_full_backward_hook : Optional[bool]
  embed_image : __torch__.dalle_runner_api.model_infra.modules.public_diff_vae.ImageEmbedding
  embed_time : __torch__.dalle_runner_api.model_infra.modules.public_diff_vae.TimestepEmbedding
  down_0_conv_0 : __torch__.dalle_runner_api.model_infra.modules.public_diff_vae.ConvResblock
  down_0_conv_1 : __torch__.dalle_runner_api.model_infra.modules.public_diff_vae.___torch_mangle_9.ConvResblock
  down_0_conv_2 : __torch__.dalle_runner_api.model_infra.modules.public_diff_vae.___torch_mangle_15.ConvResblock
  down_0_downsamp : __torch__.dalle_runner_api.model_infra.modules.public_diff_vae.___torch_mangle_21.ConvResblock
  down_1_conv_0 : __torch__.dalle_runner_api.model_infra.modules.public_diff_vae.___torch_mangle_28.ConvResblock
  down_1_conv_1 : __torch__.dalle_runner_api.model_infra.modules.public_diff_vae.___torch_mangle_34.ConvResblock
  down_1_conv_2 : __torch__.dalle_runner_api.model_infra.modules.public_diff_vae.___torch_mangle_40.ConvResblock
  down_1_downsamp : __torch__.dalle_runner_api.model_infra.modules.public_diff_vae.___torch_mangle_46.ConvResblock
  down_2_conv_0 : __torch__.dalle_runner_api.model_infra.modules.public_diff_vae.___torch_mangle_53.ConvResblock
  down_2_conv_1 : __torch__.dalle_runner_api.model_infra.modules.public_diff_vae.___torch_mangle_59.ConvResblock
  down_2_conv_2 : __torch__.dalle_runner_api.model_infra.modules.public_diff_vae.___torch_mangle_65.ConvResblock
  down_2_downsamp : __torch__.dalle_runner_api.model_infra.modules.public_diff_vae.___torch_mangle_71.ConvResblock
  down_3_conv_0 : __torch__.dalle_runner_api.model_infra.modules.public_diff_vae.___torch_mangle_77.ConvResblock
  down_3_conv_1 : __torch__.dalle_runner_api.model_infra.modules.public_diff_vae.___torch_mangle_83.ConvResblock
  down_3_conv_2 : __torch__.dalle_runner_api.model_infra.modules.public_diff_vae.___torch_mangle_89.ConvResblock
  mid_conv_0 : __torch__.dalle_runner_api.model_infra.modules.public_diff_vae.___torch_mangle_95.ConvResblock
  mid_conv_1 : __torch__.dalle_runner_api.model_infra.modules.public_diff_vae.___torch_mangle_101.ConvResblock
  up_3_conv_0 : __torch__.dalle_runner_api.model_infra.modules.public_diff_vae.___torch_mangle_108.ConvResblock
  up_3_conv_1 : __torch__.dalle_runner_api.model_infra.modules.public_diff_vae.___torch_mangle_115.ConvResblock
  up_3_conv_2 : __torch__.dalle_runner_api.model_infra.modules.public_diff_vae.___torch_mangle_122.ConvResblock
  up_3_conv_3 : __torch__.dalle_runner_api.model_infra.modules.public_diff_vae.___torch_mangle_129.ConvResblock
  up_3_upsamp : __torch__.dalle_runner_api.model_infra.modules.public_diff_vae.___torch_mangle_135.ConvResblock
  up_2_conv_0 : __torch__.dalle_runner_api.model_infra.modules.public_diff_vae.___torch_mangle_142.ConvResblock
  up_2_conv_1 : __torch__.dalle_runner_api.model_infra.modules.public_diff_vae.___torch_mangle_149.ConvResblock
  up_2_conv_2 : __torch__.dalle_runner_api.model_infra.modules.public_diff_vae.___torch_mangle_156.ConvResblock
  up_2_conv_3 : __torch__.dalle_runner_api.model_infra.modules.public_diff_vae.___torch_mangle_163.ConvResblock
  up_2_upsamp : __torch__.dalle_runner_api.model_infra.modules.public_diff_vae.___torch_mangle_169.ConvResblock
  up_1_conv_0 : __torch__.dalle_runner_api.model_infra.modules.public_diff_vae.___torch_mangle_176.ConvResblock
  up_1_conv_1 : __torch__.dalle_runner_api.model_infra.modules.public_diff_vae.___torch_mangle_183.ConvResblock
  up_1_conv_2 : __torch__.dalle_runner_api.model_infra.modules.public_diff_vae.___torch_mangle_190.ConvResblock
  up_1_conv_3 : __torch__.dalle_runner_api.model_infra.modules.public_diff_vae.___torch_mangle_197.ConvResblock
  up_1_upsamp : __torch__.dalle_runner_api.model_infra.modules.public_diff_vae.___torch_mangle_203.ConvResblock
  up_0_conv_0 : __torch__.dalle_runner_api.model_infra.modules.public_diff_vae.___torch_mangle_210.ConvResblock
  up_0_conv_1 : __torch__.dalle_runner_api.model_infra.modules.public_diff_vae.___torch_mangle_217.ConvResblock
  up_0_conv_2 : __torch__.dalle_runner_api.model_infra.modules.public_diff_vae.___torch_mangle_224.ConvResblock
  up_0_conv_3 : __torch__.dalle_runner_api.model_infra.modules.public_diff_vae.___torch_mangle_231.ConvResblock
  output : __torch__.dalle_runner_api.model_infra.modules.public_diff_vae.ImageUnembedding

And from there, you need to dig into various of python files to find Conv2d configuration etc.
BTW, this is just unzip the decoder.pt to inspect the underlying Python code.

Uploaded weights and "pseudo code" with correct hparams which contribute to the weight.

The code above looks very much like a conditional UNet with concat conditioning (except that latents are upscaled by 8x using nearest neighbor upsampling). So for a latent of 4x32x32, it would be upsampled to 4x256x256 and then concatenated with the noisy input (3x256x256), then it looks like a regular UNet.

@mrsteyk's code worked for me after some minor edits 👍

Yeah, I realised I messed up skip connections when I went to sleep. Ups originally didn’t have 4 non resizing ConvResblocks

Thanks for this commit. Did you test tiled_decode? Or is it not possible for this model?


Beast XML generation rules

Just a note to say that @pillaip has made great progress on this in the last week and the test_pri branch is almost good to go with this.


Magic button that solves everything in the database

Problem
As evoked in #2255, there are at least two sentry issues related to probable database inconsistencies (like a product list whose products are not in the product database):

https://sentry.io/organizations/openfoodfacts/issues/3329300698/?project=5376745&query=is%3Aunresolved
https://sentry.io/organizations/openfoodfacts/issues/3377849466/?project=5376745&query=is%3Aunresolved

A typical log would display something like unexpected: unknown product for<PHONE_NUMBER>769
Proposed solution
At app startup, we could run a database check and - if needed - solve the database inconsistencies (which means product downloads). We would display a "Oops" dialog with a "fix now!" button.
Additional context
Based on the same idea, we could check the local freshness of the products and suggest a refresh.
Part of

#2255

I propose doing that in a background thread and if needed block the user with a "Updading database version..." dialog, so that it doesn't seem like the app db is sometimes a mess (although it can be)

@VaiTon Actually it's not that messy, it's just a minor inconsistency. And from #2673 it's dealt with automatically when a product is displayed in a list.
We'll see how often we have issues like that.


Blast Furnace and Smoker aren't recognized by villagers as job blocks

I have left a villager next to both a Blast Furnace and Smoker for several in game days and it never once claimed a job.
A thought:
I installed JEI Professions and it says that those jobs' blocks are the FastFurnace versions, at least the tag says it is, but only the Minecraft versions are acquirable. (Looking at it again, I don't think this is the reason)

Don't think this was ever on my end to begin with. Impossible as of 4.5.0 since RR is no more.


Not deploying on Azure DB through azure-devops while using Key vault string instead of db connection string

Hi Johan,
Hope you are doing well.
There is Azure SQL db where I want to deploy the sql deployment scripts using DB Up task through azure-DevOps. But for security reasons, I have stored the DB connection string in Key Vault instead of giving it directly in DB Up the task and using key vault string in the section as per below

But I am getting the below error, Just wanted to confirm like can we go this way or we have to provide a connection string in the section?

If you are asking if it should be possible to use Azure DevOps secrets  as input for the connection string, then yes.
But Azure DevOps does not fail the pipeline if it does not recognize a variable. Can you conferm by other means that the variable does indeed hold the connection string?

Closing due to inactivity. Please open if this is still an issue.


[WinUI] MenuFlyout width error on the first time popup

Describe the bug
        <notifyIcon:TaskbarIcon
            x:Name="TaskbarIconApp"
            DoubleClickCommand="{x:Bind ViewModel.ActiveOrHideAppCommand}"
            MenuActivation="RightClick"
            NoLeftClickDelay="True"
            IconSource="{x:Bind base:Pack.UriIcon}"
            ContextMenuMode="SecondWindow">
            <notifyIcon:TaskbarIcon.ContextFlyout>
                <MenuFlyout Placement="RightEdgeAlignedTop" AreOpenCloseAnimationsEnabled="False">
                    <MenuFlyoutItem Width="180" MaxWidth="180" Text="显示／隐藏" Command="{x:Bind ViewModel.ActiveOrHideAppCommand}" />
                    <MenuFlyoutSeparator/>
                    <MenuFlyoutItem Width="180" MaxWidth="180" Text="退出" Icon="Cancel" Command="{x:Bind ViewModel.ExitAppCommand}" />
                </MenuFlyout>
            </notifyIcon:TaskbarIcon.ContextFlyout>
        </notifyIcon:TaskbarIcon>

Steps to reproduce the bug
No response
Expected behavior
No response
Screenshots
first time popup -> Error width

second time popup -> allright

How can I handle for fixed width?
NuGet package version

Platform
No response
IDE
Visual Studio 2022
Windows Version
Windows 11
WindowsAppSDK Version
1.1
WindowsAppSDK Type
Packaged
Manifest
No response
Additional context
No response

This also happens to me, on first time popup when MenuFlyoutItem has an icon

<tb:TaskbarIcon ContextMenuMode="SecondWindow" NoLeftClickDelay="True">
    <tb:TaskbarIcon.ContextFlyout>
        <MenuFlyout AreOpenCloseAnimationsEnabled="False">

            <MenuFlyoutItem Icon="Sync" Text="Refresh"/>
            <MenuFlyoutSeparator />
            <MenuFlyoutItem Text="Exit1234567890"/>

        </MenuFlyout>
    </tb:TaskbarIcon.ContextFlyout>
</tb:TaskbarIcon>

As far as I remember, I'm currently not taking icons into account when calculating the initial width, so that's a good point.
There is a bug in WinUI with different widths during the first display and after, which we are trying to adapt to so that there is no difference, and they are not going to fix it


Only get the triggering PR for release notes generation

Azure DevOps Extensions
Generate Release Notes (Node Cross Platform)
Is your feature request related to a problem? Please describe.
See #1343
At present all PRs that can be associated with a pipeline run added to the pullrequests array. This is not a behavior wanted by all users
Describe the solution you'd like
Allow a choice if only the triggering PR should be added to the array, or all PRs that can be associated by commit IDs
Describe alternatives you've considered
No response
Additional context
No response

When I checked I found this function was already in place it is the getPRDetails this defaults to true and adds PRs that are found by merge commit ID. If it is false then only the triggering PR (if any) is added


What's your pytorch version?

Thanks for your great job,
now i meet the problem about torchgeometry version and torch version when I run python experiments/test_recursive_proj.py --cfg amass_mojo_f9_nsamp50 --testdata ACCAD --gpu_index 0 . Could u tell me your test env?
Traceback (most recent call last):
File "experiments/test_recursive_proj.py", line 222, in
pred_with_proj(n_seqs=60, n_gens=50)
File "experiments/test_recursive_proj.py", line 101, in pred_with_proj
prev_pose_vp, prev_handpose)
File "experiments/test_recursive_proj.py", line 39, in get_prediction
prev_pose_vp, prev_handpose)
File "/home/zzj/project/MOJO/models/fittingop.py", line 272, in decode_with_fitting
y_i.detach())
File "/home/zzj/project/MOJO/models/fittingop.py", line 209, in fitting_subloop
loss, verts= self.calc_loss(betas, verts_gt, ss)
File "/home/zzj/project/MOJO/models/fittingop.py", line 180, in calc_loss
body_param['global_orient'] = RotConverter.rotmat2aa(RotConverter.cont2rotmat(self.glo_rot_rec))
File "/home/zzj/project/MOJO/models/fittingop.py", line 64, in rotmat2aa
pose = tgm.rotation_matrix_to_angle_axis(homogen_matrot).view(-1, 3).contiguous()
File "/home/zzj/anaconda3/envs/mojo/lib/python3.6/site-packages/torchgeometry/core/conversions.py", line 233, in rotation_matrix_to_angle_axis
quaternion = rotation_matrix_to_quaternion(rotation_matrix)
File "/home/zzj/anaconda3/envs/mojo/lib/python3.6/site-packages/torchgeometry/core/conversions.py", line 302, in rotation_matrix_to_quaternion
mask_c1 = mask_d2 * (1 - mask_d0_d1)
File "/home/zzj/anaconda3/envs/mojo/lib/python3.6/site-packages/torch/tensor.py", line 325, in rsub
return _C._VariableFunctions.rsub(self, other)
RuntimeError: Subtraction, the - operator, with a bool tensor is not supported. If you are trying to invert a mask, use the ~ or bitwise_not() operator instead.

thanks for your interests!
This problem is not caused by version incompatibility, but an internal problem in torchgeometry. As indicated in the error info, you need to jump into "/home/zzj/anaconda3/envs/mojo/lib/python3.6/site-packages/torchgeometry/core/conversions.py" and replace e.g. (1 - mask_d0_d1) with (~mask_d0_d1)

Thanks for your reply,
I had the bug above, but when I try to visualize. I meet some problems. It seems many people meet the similar problems, however it's hard to solve render problem. Could you give me some advice? My open3d version is 0.9.0. Xmanager version is 6
(mojo) video@bcnl-PowerEdge-T640:~/MOJO$ python experiments/vis_kps_amass.py
-- processing: /home/video/MOJO/results/amass_mojo_f9_nsamp50/results/seq_gen_seed1/ACCAD/results_marker_41.pkl
libGL error: No matching fbConfigs or visuals found
libGL error: failed to load driver: swrast
Traceback (most recent call last):
File "experiments/vis_kps_amass.py", line 132, in
seq=seq,gen=gen)
File "experiments/vis_kps_amass.py", line 25, in visualize
vis.create_window(width=960, height=540,visible=False)
RuntimeError: [Open3D ERROR] GLFW Error: GLX: GLX version 1.3 is required

I find that pred = get_prediction_stats(traj, 'dlow', sample_num=cfg.nk, num_seeds=num_seeds, concat_hist=True) in line 70 in eval_jts_pred.py, get_prediction_stats  has no define. Do you mean 'get_prediction' in the line 17?

for the open3d question, i think it is an open3d problem and you could ask in their repo. You perhaps did not install all dependencies of open3d.
For the second question, probably yes.


Environment created in terminal while in restricted mode not detected when entering trusted mode

Start in restricted mode
Create and open a Python file
python -m venv .venv in the terminal
Leave restricted mode
Notice how the newly created virtual environment is not automatically selected

We don't even automatically select the newly created env in trusted mode, so I think you mean

I basically meant what I said, but I did it make it clear that the lack of selection is expected. 😅 What I was trying to point out is why create the new environment if we are not going to select it as expected?

I tried reproducing the issue with a workspace folder open, seems like opening a terminal itself requires trusting the workspace first:

So python -m venv .venv command cannot be run and we won't land in this situation.
If no workspace is opened, we don't offer creating or selecting local virtual environments anyway. Can you clarify whether you have a workspace opened?

Btw, if no interpreter has previously been selected for the workspace, we should ideally automatically select the local .venv once it is trusted.

So python -m venv .venv command cannot be run and we won't land in this situation.

If I remember correctly, I created the virtual environment outside of VS Code.

I don't see the issue if no interpreter has been previously configured for the workspace, i.e the .venv automatically gets selected. You probably have a python.defaultInterpreterPath set in User settings, which is overriding the auto-selection behavior.

You probably had python.defaultInterpreterPath set in User settings

That definitely wasn't the case. It may be that not being able to open a terminal in untrusted mode changed and so this isn't feasible anymore. I'm going to close as outdated and worry about it if I come across it again.


Unclear how containsPoint is meant to be used?

The implementation of containsPoint seems to expect the lower and upper will have a compareTo method, but this isn't documented and it's not obvious how this would work in practice, as ranges will typically be numbers or dates which won't have a compareTo method.
For example:
intRange = range.parse('[1, 10)', x => parseInt(x))
// Range { lower: 1, upper: 10, mask: 4 }
intRange.lower
// 1
intRange.upper
// 10
intRange.containsPoint(5)
// Uncaught TypeError: this.lower.compareTo is not a function

I note that there's currently no test coverage for containsPoint or containsRange, so perhaps they're not ready for use yet? However, they are included in the TypeScript types so they appear to be public.
Thanks!

Thanks for reporting this! Not sure where the .compareTo() came from, I think it's from the Java package which is the inspiration for this one. It should be fixed now, just update to the latest version which is 1.1.2. But if you found any other issue with it please do let me know! Also PRs are welcome on any aspects of the module. ;)

@clarkdave I'm going to close this issue. Feel free to re-open if you have anything else to add.


Run Go unit tests in different versions

Adding functionality to run Go tests for the following versions:

latest (1.15.x)
major release before latest (1.14.x)
project version (from .go-version)
prerelease version (1.16beta1)

In order to use the project version in a job's matrix, I moved parsing of go-version into a separate job which the test job depends on.
All matrix jobs will run even if another matrix job fails. This is so that tests for different versions can all run independently.
The prerelease version has continue-on-error set to true so that the workflow will show as SUCCESSFUL (green tick) even if tests for the prerelease fails. The failed tests will still be annotated in the workflow summary.

Looks good except I don't understand what the project-go-version job is about.

We want to always run the unit tests on the version that ts-bridge is on, which is tracked in the file .go-version.
I wasn't able to run cat .go-version inside the matrix config, so I had to do it in a separate job. project-go-version extracts this version and puts it into an output named go-version, which is later used via needs.project-go-version.outputs.go-version on line 41.
It's a bit complicated so please let me know if there's an easier way of doing this.

Looks good except I don't understand what the project-go-version job is about.

We want to always run the unit tests on the version that ts-bridge is on, which is tracked in the file .go-version.
I wasn't able to run cat .go-version inside the matrix config, so I had to do it in a separate job. project-go-version extracts this version and puts it into an output named go-version, which is later used via needs.project-go-version.outputs.go-version on line 41.
It's a bit complicated so please let me know if there's an easier way of doing this.


Added tests for fill_holes_in_rc96_segment and search_sorted_optimistic hints

search_sorted_optimistic was previously called find_element and has been renamed to match the correct Cairo function it's called from, since there are three variations of very similar hint code.

PTAL


OffCanvasSingleton removes all offcanvas elements from the DOM

PHP Version
8.2
Shopware Version
6.5
Expected behaviour
Being able to use the bootstrap native offcanvas implementation, together with the shopware implementation.
The native offcanvas elements should not be removed from the DOM by the shopware implementation, instead they should be just be closed.
Actual behaviour
Shopware now uses the offcanvas feature bootstrap, which I very much welcome. However, it is not possible to use the native bootstrap implementation, because in the OffCanvasSingleton all elements with the class offcanvas are removed from the DOM.
How to reproduce
Implement an offcanvas element somewhere on the storefront, just like it is mentioned in the bootstrap documentation

As workaroud you could create a custom offcanvas css class to avoid using .offcanvas
.my-offcanvas { @extend .offcanvs}


JS: whitelist $(location) for xss in simple cases

This could be solved more generally with flow labels, but for now I'd like to ensure that this FP goes away in the common case.

Added a change note.


Enable Tern to run on Kubernetes

Describe the Feature
Tern can be package as a container. Next, let's make it run on Kubernetes so users can deploy and utilize Tern at scale or as part of their CI/CD pipelines.
Implementation Changes
There are two approaches to running Tern on Kubernetes:

Run Tern jobs as ephemeral containers each with the job of scanning one container image.

Run Tern in some number of persistent containers running as a service in a K8s cluster, scaled to the resource environment. Something calls out to the “Tern cluster” via its APIs and asks for work (the 100 containers names for scanning).  Tern figures out how to load balance those across its available instances, perhaps with Kubernetes spinning up more worker instances of Tern container if resources are available or the quality of the Tern service gets to low.

We will start by first implementing the first approach - running Tern as a container on Kubernetes. The second approach will take more time to thoughtfully design (and might possibly overlap with https://github.com/tern-tools/tern/issues/1096).

On further investigation, it seems like Tern can run on Kubernetes as of release 2.9.1, but requires volume mounts. Therefore, we will just add some documentation to the README explaining how to do that with minikube.


Fix/utf 8

Text rendering doesn't work with utf-8...
I can't render chinese, arabic... or special chars as éèûîà...
It seems that the string function to convert utf-8 to unicode is quiet simple.
Ref: #3933
[Note]: OpenImageIO is used in the gpx2video project.

Before:

After:

Can you please base the PR on the current master so you aren't comparing across branches and seeing hundreds of files in the diff? Thanks.

Also, would you mind please making sure to sign your commits to invoke the DCO? Thanks.

This is somewhat problematic as large parts of <codecvt> including wstring_convert and codecvt_utf8 have been deprecated since c++17 [1].  They didn't have a long life due to a variety of reasons. Once we move to c++20 you'll get warnings/errors in many environments [2].
[1] https://en.cppreference.com/w/cpp/locale/wstring_convert
[2] https://godbolt.org/z/PMn4hMK18

I like the intent of this PR. It would be great to burn artists actual names in a slate for instance.

@jessey-git I'm not sure exactly why it seems to pass CI for us (including the test where we do use C++20), but Godbolt certainly makes a compelling case that this is problematic.
What's the preferred approach these days?
Can the implementation we are using in Strutil::utf8_to_unicode be repaired to fix whatever shortcoming inspired this PR?

For the windows builder it might be because it's using -DCMAKE_CXX_STANDARD=11 during the build?
For the linux builders I think it's a combination of not using a warning level that would show the warnings and/or not using -stdlib=libc++ as I did in my example.  Really weird that base gcc and its std library aren't showing the deprecations...
Unfortunately I don't quite know what's state-of-the-art in terms of unicode in c++ nowadays.

It was not me who did it, but I have a feeling that the unreliability of wstring_convert (not existing prior to C++11, and perhaps also knowing that a deprecation was on the way for C++17), is what inspired the unicode decoding from http://bjoern.hoehrmann.de/utf-8/decoder/dfa/ being added to Strutil. The nice thing about that it that it's small and independent of the std or any other dependencies. The down side, of course, is that there appear to be some sequences it doesn't handle properly, which had never been reported prior to this PR. I still think that if this code can be repaired (or substituted with a different implementation with a license acceptable to us), that would be better than relying on std::wstring_convert. But I definitely am in favor of some kind of fix; @progweb is correct that we should render those codes properly.

@progweb Can you supply any test case that we can try out other solutions (such as whatever made your example above)?
I noticed that the code in Strutil is not the only formulation on that web page it came from; maybe it is the only buggy one and the others work properly? But I don't have a good test.

I'm going to try to fix it with an other implementation...

Work as expected.
STR:      t   e   s   t   :        é      è      ú      ç      à      ï      ö        €

UTF8:    %74 %65 %73 %74 %3A %20 %C3%A9 %C3%A8 %C3%BA %C3%A7 %C3%A0 %C3%AF %C3%B6 %E2%82%AC
UNICODE: %74 %65 %73 %74 %3A %20   %E9    %E8    %FA    %E7    %E0    %EF    %F6    %20AC

Work as expected.
STR:      t   e   s   t   :        é      è      ú      ç      à      ï      ö        €

UTF8:    %74 %65 %73 %74 %3A %20 %C3%A9 %C3%A8 %C3%BA %C3%A7 %C3%A0 %C3%AF %C3%B6 %E2%82%AC
UNICODE: %74 %65 %73 %74 %3A %20   %E9    %E8    %FA    %E7    %E0    %EF    %F6    %20AC

I took the liberty of adding a test for this and pushing it to your tree. Once we see that it passes CI, I'll do the merge.


Update Japan prefectures to reflect ISO_3166-2:JP with standard Engli…

…sh Spelling (https://www.iso.org/obp/ui/#iso:code:3166:JP).

Thanks @rwearing!


Adds CLI option to configure Cluster ID

/assign @jakexks
fixes #27
This PR exposes the option to allow configuring the Cluster ID. This is used to configure the authenticator to allow requests from istio which doesn't use the default Cluster ID.

/retest
/unassign
/assign @JoshVanL

/retest


Modpack not on Wabbajack

I went to install the pack after buying skyrim legendary edition, and I can't find it in the wabbajack modlist page. I noticed that there is an update page that v1.3.0 is unreleased as of right now, is this related?

It is supposed to be skyrim anniversary edition.
Uhm... I wonder if it is currently under maintenance, or something... else. 🤔
Good luck!


[Enhancement] Company Merger for Genres

I'd like to see the same plugin as Company Merger but for genres.
I'm loving Company Merger, thanks for making it!

Check out the LibraryManagement plugin. (Though honestly it's a bit janky, so I wouldn't mind an alternate myself.)

I was gonna say the same thing. The speciality of Company Comnpanion to find similar company names isn't so easy to apply to genres, because there aren't any generic words like "studio" or "interactive" or business entities to remove to find duplicates. Library Manager has the advantage, that you can set rules, which genres (or other fields) you want to merge and what you want to name the merged result. Those rules then will be applied automatically on library updates. I built Company Companion mainly, because adding rules manually for companies would be tedious because of the amount of different names. Genres are generally much more managable.
I have some ideas to write my own Library Management addon and include stuff from Company Companion into it, but that will be a rather big addon, I guess. That definitely won't happen before Playnite 11 is out.


stream load large varchar failed

Steps to reproduce the behavior (Required)
CREATE TABLE `duplicate_tbl` (
                  `k1` int,
                  `k2` varchar(1048576)
                ) ENGINE=OLAP
                DUPLICATE KEY(`k1`)
                COMMENT "OLAP"
                DISTRIBUTED BY HASH(`k1`) BUCKETS 3
                PROPERTIES (
                "replication_num" = "1",
                "storage_format" = "V2"
                );
curl --location-trusted -u root: -T /home/disk1/yangning/StarRocksTest/lib/../common/data/1m_varchar_data -XPUT -H label:stream_1642661516583 http://<IP_ADDRESS>:8534/api/large_varchar_load_test_75518444_79bd_11ec_b447_00163e0e550b/duplicate_tbl/_stream_load

Expected behavior (Required)
load ok
Real behavior (Required)
Error: Value count does not match column count. Expect 1, but got 2.' ### StarRocks version (Required)

You can get the StarRocks version by executing SQL select current_version()
6d8e035

Not A problem.

我这边也碰到同样的问题，这个是什么原因呢

check delimiter in load file


crash reporting

Are there plans for the dash_analytics package to provide support for crash reporting?

That should be okay to send crash reporting to the GA endpoint, we'll just need to add an event enum for crash reporting for each tool. However, this GA instance shouldn't be used for debugging those crashes by sending stacktraces, etc.
On the flutter tools side, with the previous reporting package, we would send an event indicating a crash has occured to GA but also send the details around the crash to crash.corp.google.com with detailed information about the crash

... also send the details around the crash to crash.corp.google.com ...

That's what I was referring to. We used to use the telemetry package in the SDK repo for both analytics and crash reporting. The question is whether the analytics package will have support for that.

Ah I see what you mean now. I would need to familiarize myself with the how google crash reporting endpoint works but we could add another feature that can handle crash reporting as well and sends to a separate endpoint. But at the moment, this package isn't capable of handling this

Closing this issue for now, feel free to re-open this if more discussion is needed...  but at the moment, it doesn't seem that package:unified_analytics will be reporting crashes for dash related tooling


Template and ISO views pagination is inconsistent

The listTemplates and listIsos doesn't return unique templates, but all duplicates for all zones which creates pagination issue. Introduce an API key to allow listing of unique items, fix this with next CloudStack release - https://github.com/apache/cloudstack/issues/4041

Assigned to @davidjumani


⚠ Jenkins Plugins Artifactory has degraded performance

In 6af3fc6, Jenkins Plugins Artifactory (https://get.jenkins.io/plugins/artifactory/) experienced degraded performance:

HTTP code: 200
Response time: 1266 ms

Resolved: Jenkins Plugins Artifactory performance has improved in 0b79e7c after 26 minutes.


Updated hints to default behaviour

Added tooltip to the Active device filter
Replaced help buttons in the Notification Editor to default behaviour

Thank you!


Using ${workspaceRoot} in "configFile" field not working

I expected to be able to do something like:
"eslint.options": {         "configFile": "${workspaceRoot}/.eslintrc",         "useEslintrc": false     },
However, this doesn't appear to be working.  For example, if ${workspaceRoot} were to point to /my/workspace/root/, the parser is instead returning:
/my/workspace/root/${workspaceRoot}/.eslintrc
Specifically, it is doing the lookup correctly and is pasting it in, but isn't removing the ${workspaceRoot} text.

The reason for this is that VS Code itself has no support for this. See https://github.com/microsoft/vscode/issues/2809
I will close this as upstream since there is nothing I can do without proper API (I don't want to be in the business of reinterpreting this on my end).
One tip: you can use relative paths. The ESLint extension will run ESLint relative to the workspace folder or relative to the working directories setting.


Starting Pods fails: apparmor_parser not found

Environmental Info:
K3s Version:

# k3s -v
k3s version v1.21.1+k3s1 (75dba57f)
go version go1.16.4

Node(s) CPU architecture, OS, and Version:

Linux ubuntu-master 4.4.0-210-generic #242-Ubuntu SMP Fri Apr 16 09:57:56 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux

Cluster Configuration:

1 Server / single node cluster
Describe the bug:

Starting new Pods failed with the error Error: failed to create containerd container: get apparmor_parser version: exec: "apparmor_parser": executable file not found in $PATH then after restarting the cluster, all containers fail to start with the same error
Steps To Reproduce:

Installed K3s:
configured the k3s system upgrade controller with the stable releases
Installed kilo (modifies network)

Expected behavior:

Pods start without problems
Actual behavior:

No pods start
Additional context / logs:

logs

Is this actually Ubuntu, or k3os? Please see: https://github.com/rancher/k3os/issues/702

it's ubuntu, but the fix in rancher/k3os#702 fixed the issue


Structure like 'NativebaseKitchenSink' but android back button does not work..

I have basically redone my project with the structure of NativebaseKitchenSink, I created the drawer and the stack but from any page the back hardware button of android makes me exit the App, which instead the app NativebaseKitchenSink does absolutely but always returns to the previous page .... by chance has already happened to someone? if want i place my project on expo..
This is my code:
import { Root } from 'native-base';
import { StackNavigator, DrawerNavigator } from 'react-navigation';

import ForgetPassword from './components/Login/forgetPassword';

import Home from './components/Home/homeScreen';
import Login from './components/Login/loginScreen';
import News from './components/News/newsScreen';
import Contacts from './components/Contacts/contactsScreen';
import Chat from './components/Chat/chatScreen';

import SideBar from './components/sidebar';

const Drawer = DrawerNavigator(
  {
    Home: { screen: Home },
    Login: { screen: Login },
    News: { screen: News },
    Contacts: { screen: Contacts },
    Chat: { screen: Chat },
  },
  {
    initialRouteName: 'Home',
    contentComponent: props => <SideBar {...props} />,
  }
);

const AppNavigator = StackNavigator(
  {
    Drawer: { screen: Drawer },

    ForgetPassword: { screen: ForgetPassword },
  },
  {
    initialRouteName: 'Drawer',
    headerMode: 'none',
  }
);

export default () => (
  <Root>
    <AppNavigator />
  </Root>
);```

@nobady90 Not related to NativeBase, you can get help from react-navigation team and Stack Overflow


Add redirect for docs

@ckerr-IDM and @celiot-IDM, where should the redirect go? Most of our docs redirect to idmod.org/docs/.

@lgeorge-idm this is dealing with the covasim/covasim-docs ordeal from yesterday, i'll do it now


use localized controls keys

https://github.com/wintercms/wn-builder-plugin/issues/49

@dimti @LukeTowers is there any way we can shift the translation into the client-side (ie. in the templates)? It seems a bit weird that we would need to have the translation here being used an array key.

@bennothommo i added new solution for this
Groups controls used both for separate render template an adding field model and in mass adding fields on the model, where groups merge into one array. Now, groups have a marks with integer constant, and a localized label move to group property.


Update required packages in setup.py

Specifically:

[ ] OpenCV is not listed anywhere. This might have been intentional since installing this via pip is a hassle from what I recall. If this is indeed the case, at least document that decision in a comment or something.
[x] Webcam support is not essential. Can v4l2 be made optional?
[x] Review imports across the project and add any other ones that are missing. I suspect there may be quite a few.

Reviewed and updated but not much testing.


[DO NOT MERGE] Add script to generate flash algo from pack

Add a script to generate the DAPLink flash algo and target information for pack devices.

This requires that cmsis-pack-manager is installed with pip (its not in pypi yet).
On first installation you need to download the pack index:
pack-manager cache -e

You can then use cmsis-pack-manager to find the device you want:
pack-manager find-part <name to search for>

And this script to build the flash algo:
python generate_blobs_from_pack.py <device name>


Update to Node16

Per https://github.blog/changelog/2022-09-22-github-actions-all-actions-will-begin-running-on-node16-instead-of-node12/, workflows using the latest version of this action are generating warnings like the below:
Node.js 12 actions are deprecated. For more information see: https://github.blog/changelog/2022-09-22-github-actions-all-actions-will-begin-running-on-node16-instead-of-node12/. Please update the following actions to use Node.js 16: actions/upload-artifact, softprops/action-gh-release, actions/upload-artifact

It looks like this isn't going to cause any serious problems until Summer 2023, but getting things migrated earlier rather than later seems like it'd be a good thing!

Duplicate of #249

Fixed


Headless browser tests in Safari fail since 0.2.82

Describe the Bug
After the wasm-bindgen update to version 0.2.82, my project's headless browser tests constantly fail in Safari. No problems exist in Firefox and Chrome. There are no such problems with the previous version 0.2.81.
Steps to Reproduce

Update wasm-bindgen to version 0.2.82.
On macOS, run sudo safaridriver --enable and wasm-pack test --headless --safari.

Expected Behavior
The tests should run successfully.
Actual Behavior
The tests fail with the following error:
Running headless tests in Safari on `[http://<IP_ADDRESS>:49974/`](http://<IP_ADDRESS>:49974/%60)
Try find `webdriver.json` for configure browser's capabilities:
Not found
Starting new webdriver session...
Error: non-200 response code: 500
Visiting http://<IP_ADDRESS>:49973.../
{"value":{"error":"unknown error","message":"","stacktrace":""}}

I saw this error in my project's CI pipeline for the first time but I can also reproduce it on my local machine.

This seems to have been introduced in #2936.

Okay, this seems to be a bug in safaridriver - navigating to any page with Cross-Origin-Opener-Policy: same-origin causes it to crash.

I can confirm that I'm encountering the exact same error with safaridriver. This issue seems to occur on both MacOS 11 and 12, and it still occurs with the most recent wasm-bindgen-test-runner 0.2.83. Is there a way to work around this (maybe by adding an option to not emit the COOP headers).

Could this be the following webkit bug: https://bugs.webkit.org/show_bug.cgi?id=245346

We could stop emitting the headers when using safaridriver and instead use JSC_useSharedArrayBuffer.
See https://webkit.org/blog/11364/release-notes-for-safari-technology-preview-117.
Would make the PR myself but don't have access to an Apple device.

I can no longer reproduce this, so I think the bug in safaridriver might have been fixed.
It might've been fixed in 16.4, since the release notes have a vague mention of 'Fixed automation sessions terminating during navigation'.
@pemistahl or @josephlr, can you confirm that it's also fixed for you?

I can confirm that this was fixed, using it in multiple CIs on GitHub Actions and tested on desktop Safari v16.4 as well.

Great!

Yes, the bug has been fixed, apparently. My tests pass now again. :)


EXSWHTEC-322 - Implement common utilities for texture fetching tests

Texture reference class
Fixed-point representation helper
Kernels
Vec4 type
Test fixture.

PR has been merged into develop branch via commit 16128f659a9dc9cac485bc3533cfe5f8a79ced5b.


Making the project go gettable

Hey, kudos for the nice work. It will be great if the project was  easy to install without the make instructions.
That can be easy if the name of the repository would have to change and remove the dash(-) character. I suggest you name it something like avatar .
That way, gor people who wants to install  the command it can just type
go get  -v github.com/holys/avatar/cmd/avatar

And for those who want to install the library can just type
go get  -v github.com/holys/avatar

That is ofcourse after moving the contents of  github.com/holys/initials-avatar/avatar to github.com/holys/avatar

@gernest  Thanks for your suggestion.  I will add go get-able command to Readme.md.
As for the name, dash will be fine. I just want to distinguish my project from other, like idenicon avatar.

@holys That is great.  I will be hacking on the getInitials  function defined here
If you don't mind can you explain a little bit about what do you mean by name initials so I can be sure to cover the edge cases? thanks in advance.

FYI, on the subject of make project go gettable, I found this URL http://blog.turret.io/organizing-go-code-to-be-go-gettable/

@gernest If you're going to be modifying getInitials, I recommend looking at grapheme clusters so you handle unicode characters properly. We did a bit of toying around on IRC and found this: https://play.golang.org/p/RMMO7luJvh .
Hope that helps!


[HOLD #21461 ][$2000] IOU - Add bank account is looping when clicking pay with expensify

If you haven’t already, check out our contributing guidelines for onboarding and email<EMAIL_ADDRESS>to request to join our Slack channel!

Action Performed:

Have an account (under the wallet beta) with a silver/pending wallet. Note: every account under the wallet beta has a silver wallet created automatically.
If this account does not have a personal bank account (PBA) set up, follow the below steps:
Log into NewDot and navigate to Settings > Payments > Add payment method > Bank account
Select Connect via plaid and use the following credentials:
Wells Fargo
Username: user_good
password: pass_good
Mobile verification code: credential_good
Plaid saving
Have another user request money to the user you are testing with
Attempt to pay the money request

Expected Result:
User able to proceed with payment as bank account already added
Actual Result:
Add bank account is looping when pay with expensify clicked
Workaround:
Can the user still use Expensify without this being fixed? Have you informed them of the workaround?
Platforms:

Which of our officially supported platforms is this issue occurring on?

[ ] Android / native
[ ] Android / Chrome
[ ] iOS / native
[ ] iOS / Safari
[x] MacOS / Chrome / Safari
[x] MacOS / Desktop

Version Number: v1.3.24-4
Reproducible in staging?: Yes
Reproducible in production?: Cannot test in prod
If this was caught during regression testing, add the test name, ID and link from TestRail: N/A
Email or phone of affected tester (no customers):
Logs: https://stackoverflow.com/c/expensify/questions/4856
Notes/Photos/Videos: Any additional supporting documentation
https://github.com/Expensify/App/assets/44479856/06ec81b6-0540-45fd-9b89-fe15a1ebdc71
Expensify/Expensify Issue URL:
Issue reported by: Applause - Internal team
Slack conversation:
View all open jobs on GitHub
Issue found while executing QA for https://github.com/Expensify/App/pull/19753
Upwork Automation - Do Not Edit

Upwork Job URL: https://www.upwork.com/jobs/~014f5fed1085f06532
Upwork Job ID:<PHONE_NUMBER>539529216
Last Price Increase: 2023-06-20

Issue is failing PR https://github.com/Expensify/App/pull/19753 from the checklist deploy

Following this - https://github.com/Expensify/App/issues/17027#issuecomment-1584842843

@isagoico please check if credentials for the Wells Fargo are correct.

Not overdue, still looking for proposals and I think this may need reproduction confirmation

I think we might be waiting on @Skalakid to look into this based on - https://github.com/Expensify/App/issues/17027#issuecomment-1584842843

We are no longer waiting FYI. It is not related to that PR

Looks like we're waiting on proposals!

Not overdue. Looking for proposals

Melvin, we are still waiting for proposals

Hello
Currently, seems that the product version for Plaid is being run on local dev env. How can run the staging version on local dev env?

Contributor details
Your Expensify account email<EMAIL_ADDRESS>Upwork Profile Link: https://www.upwork.com/freelancers/~010d3ea472a2944d4e

@pauldriggers911 Go to Settings -> Preferences and switch on the "Use Staging Server" switch. For follow up questions please ask on slack #expensify-open-source channel. If you don't have slack access please checkout the contributing guide.

Hello, @isagoico. Will you provide full video for this issue? I am not sure which step you were facing it in.

Reporting another issue that I think is impacting the testing fo this one - https://expensify.slack.com/archives/C049HHMV9SM/p1687475426113199
I'll follow this ^ chat thread and provide more information

https://github.com/Expensify/App/issues/21461 - I think this might be blocking testing of this issue. @s77rt @pauldriggers911 let me know if you agree!

@Christinadobrzyn Yes, it seems to be the case. Should we put this on hold?
https://github.com/Expensify/App/assets/16493223/8f8b5126-9b02-41b3-9979-335971226d5b

Yes - thanks for testing. Let's put this on hold for https://github.com/Expensify/App/issues/21461

on hold for https://github.com/Expensify/App/issues/21461

on hold for https://github.com/Expensify/App/issues/21461

I'm going to be ooo until August 31st so going to unassign and assign a new teammate.
At this time, we're on hold for https://github.com/Expensify/App/issues/21461

moving to weekly since it's on hold

i believe we are still holding - https://github.com/Expensify/App/issues/21461

Back from ooo - thanks for handling this @maddylewis I can take it off your plate

Still on hold

Hey @s77rt this is now closed - https://github.com/Expensify/App/issues/21461
I just tested our OP steps again and I'm seeing this error so I wonder if this is expected or if something else needs to happen before working on this?

@Christinadobrzyn Since https://github.com/Expensify/App/issues/21461 was closed as not to be fixed, I think we can close this one too as it's also related to the "Pay with Expensify".
cc @marcaaron

Sounds good! let's close this one for now and we can reopen it if needed.


Fixed NIST Visual Display pages

Description of Work
Fixes #82
Visual display pages are now produced for each starting position and the links are correct in the main tables.
Testing Instructions

Run example_runScript.py in the mantidpython console.
Check the links in the NIST tables and make sure that they link to the correct pages.

merge conflict

---------------------------------------------------------------------------
IOError                                   Traceback (most recent call last)
C:\Midlertiddig\fitbenchmarking\example_scripts\example_runScripts.py in <module>()
    100                     group_name=group_suffix_names[idx],
    101                     use_errors=use_errors, color_scale=color_scale,
--> 102                     results_dir=results_dir)

C:\Midlertiddig\fitbenchmarking\fitbenchmarking\results_output.py in save_results_tables(minimizers, results_per_test, group_name, use_errors, color_scale, results_dir)
     71     tables_dir = make_result_tables_directory(results_dir, group_name)
     72     linked_problems = build_indiv_linked_problems(results_per_test, group_name,
---> 73                                                   results_dir)
     74
     75     accuracy_tbl, runtime_tbl = \

C:\Midlertiddig\fitbenchmarking\fitbenchmarking\results_output.py in build_indiv_linked_problems(results_per_test, group_name, results_dir)
    144         name = '`' + name_index + ' ' + \
    145                build_visual_display_page(prob_results, group_name, results_dir,
--> 146                                          count)
    147         linked_problems.append(name)
    148

C:\Midlertiddig\fitbenchmarking\fitbenchmarking\results_output.py in build_visual_display_page(prob_results, group_name, results_dir, count)
    258                                figure_fit, fit_function_details_table,
    259                                gb.minimizer, see_also_link)
--> 260     save_VDpages(rst_text, problem_name, file_path)
    261
    262     return rst_link

C:\Midlertiddig\fitbenchmarking\fitbenchmarking\results_output.py in save_VDpages(rst_text, prob_name, file_path)
    348
    349     html = publish_string(rst_text, writer_name='html')
--> 350     with open(file_path + '.' + FILENAME_EXT_TXT, 'w') as visual_rst:
    351         print(html, file=visual_rst)
    352         logger.info('Saved {prob_name}.{extension} to {working_directory}'.

IOError: [Errno 2] No such file or directory: 'C:\\Midlertiddig\\fitbenchmarking\\example_scripts\\results\\neutron\\VDPages\\neutron_data_enginx_193749_calibration_spectrum_651_peak_19_1.txt'

@Anders-Markvardsen
Sorry, tested it on my machine and it produces the expected results. Did you remote update and pull?

No worries - my mistakes - I needed to restart the console. Test and NIST pages looks good including the line to external page at the bottom

I am almost done restructuring the whole project (since having a bunch of big .py files is not considered good practice as it is hard to read and understand what the script is doing - can confirm that this was the case when I started working on this). Therefore, I will add full function descriptions in #88 if that is ok.

That sounds good


fix: ensure that the root data path exists before creating lock files

WIthout that fix, if $HOME/.local/share/iroh doesn't exist yet the lock creation fails.
ping @b5 since that may conflict with your work on start/stop.

considering it's a one-line fix, want me to incorporate this into #360?

considering it's a one-line fix, want me to incorporate this into #360?

yes, wfm.

superseded by #360


add pyrmont testnet

Thanks for the PR but it's already in the dev branch (#157).
It will be released early next week. :)


Idea: remove size computation in serialization, serialize in one pass

Currently we do serialization in two passes. First pass computes buffer size. We then allocate a blob with the computed buffer size and serialize to that blob.
This two-pass implementation relies on being able to write an offset or address value to object headers, and that we can distinguish offsets/addresses from object tags. These offsets/addresses are used to preserve sharing of mutable variables during serialization and avoid looping.
This causes problems with #2790 (which is needed for #2706). With #2790 we no longer have a 32-bit space in headers available to the serializers. See my comment below.
If we make serialization work in one pass it solves the issues with overwriting object headers to preserve sharing and avoid looping, and also allows putting more information in object headers in #2790.
Here's how it would work:

We will need a "linked buffer" data type. Serialization code will start with a fixed-size buffer, and extend it by allocating new blobs and linking them to the previous buffer chunk. We will also need a function for writing these linked buffers to the stable memory, using one ic0.stable_write per chunk in the list.

Serialization will use this new buffer type, and allocate new chunks as needed.

After that we will no longer need the size computation, because we can now grow the buffer as needed. We can start with e.g. 1 KiB buffer, and either extend it by allocating same sized chunks, or maybe add 1.5 KiB, then 3 KiB and so on.

For sharing, we use the "forwarding pointer" tag that the copying GC uses. Whenever we see a mutable variable, we serialize it, and update the object in heap with a forwarding pointer. The forwarding pointer will have the offset of the object's serialization, in the final, linear, serialization buffer. In other words, if the buffer is written to stable memory address N and the serialization of the mutable variable will be in N+M in the stable memory, the field will have value M.
(We could also introduce a new tag for this, but I'm not sure that's necessary)

(Previous step will leave the serialized objects in an inconsistent state, but I think that's OK as these objects won't be traced by the GC)

No changes needed in deserialization

Changes to runtime: We won't need a pass for computing the size, so that's a win. Writes will need to check the buffer size, and grow the buffer as needed. We currently do not check the buffer size and assume it has the right size (i.e. the buffer size pass is correct), so this will be extra cycles used in runtime. We should check the size and grow as needed in batches. For example: do one "grow_buffer" call for N writes that will write in total M words, then do unchecked writes in those N writes. (not sure what the max. value of N here, I suspect it won't be too big)
Unclear whether the net result will be a positive or negative.
Writing to stable memory will be done in multiple steps, instead of one step. I doubt this will be a problem though, we could tweak buffer size to minimize number of calls. Hard to say for sure without numbers. It would be helpful to know buffer sizes of some of the real-world Motoko canisters, and max. seen so far.
Deserialization will work as before.
Changes to binary sizes: Unclear whether it'll grow or shrink. We will remove the code for the size computation, but add code for (1) the linked buffer implementation (2) for growing the buffer as needed during serialization. Note that buffer size functions are generated per type, so removing this pass removes one function per serialized type. So I expect this change to be a win for binary sizes.
Changes to memory usage: 2 word overhead per buffer chunk. Should be negligible.

Right after posing this I realized that if it's OK to leave serialized objects in an inconsistent state (one of my assumption in my design above) then we don't need to worry about overwriting the header bits for gc metadata.
Having one-pass implementation might still be worthwhile though.

Interesting idea. This would still be necessary if we allowed programmatic serialization of extended (mutable)  Candid to blobs, but we don't yet and I don't see why we would want to.

We could also abuse the Text ropes for binary buffer, I suspect.

Yes yes yes. I have always wanted something like that; buffered serialization, and writing out the serialized data in chunks. This will also greatly improve candid encoding when encoding a message argument or reply, if one doesn't need a separate buffer that contains the full result, but just smaller chunks. And I assume that blobs and texts can be written out to the reply/stable memory directly, without copying. After all, that's why defined the system API to allow chunked writes!
So all for it. I just didn't do it so far because it's “just” an optimization, and adds complexities (managing these buffers, flushing them, etc). But once there isn't anything more important to do, yes, please.

As for stabilization, this has been obsolete with enhanced orthogonal persistence.


Which transfomer version could be used with VLLM 0.6.2?

VLLM 0.6.2 had just released few hours ago, it said no support multi image inference with Qwen2-VL.
I've try it, but it require the newest transformer and automatic install it.
When I start it use follow script (worked with vllm 0.6.1)
VLLM_WORKER_MULTIPROC_METHOD=spawn CUDA_VISIBLE_DEVICES=0,1 python -m vllm.entrypoints.openai.api_server --served-model-name Qwen2-VL-72B-Instruct-GPTQ-Int4 --model Qwen/Qwen2-VL-72B-Instruct-GPTQ-Int4 --port 7869 --dtype half --trust-remote-code --kv-cache-dtype fp8 -q gptq --disable-log-requests --gpu-memory-utilization 0.998 --max-model-len 24576 --max_n
um_seqs 16 -tp 2

it report error like
  File "/DaTa/.local/home/hai.li/miniforge3/envs/vllm/lib/python3.12/site-packages/vllm/config.py", line 1746, in _get_and_verify_max_len
    assert "factor" in rope_scaling
           ^^^^^^^^^^^^^^^^^^^^^^^^
AssertionError
Unrecognized keys in `rope_scaling` for 'rope_type'='default': {'mrope_section'}

if I return to old transformer with
pip install git+https://github.com/huggingface/transformers@21fac7abba2a37fae86106f87fcf9974fd1e3830

it report error like
  File "/DaTa/.local/home/hai.li/miniforge3/envs/vllm/lib/python3.12/site-packages/vllm/transformers_utils/configs/mll
ama.py", line 1, in <module>
    from transformers.models.mllama import configuration_mllama as mllama_hf_config
ModuleNotFoundError: No module named 'transformers.models.mllama'

same issue +1

the same

seems the issue is found:https://github.com/vllm-project/vllm/pull/8829

We have just now fixed the issue in https://github.com/vllm-project/vllm/pull/8837.

We have just now fixed the issue in vllm-project/vllm#8837. Please install vLLM from source to resolve the config loading problem.

vllm 依然不支持多张图片或视频的问答，请问是否有计划修复？

We have just now fixed the issue in vllm-project/vllm#8837. Please install vLLM from source to resolve the config loading problem.

vllm 依然不支持多张图片或视频的问答，请问是否有计划修复？

Multi-image input is currently supported in both offline and online inference, while video input is only supported for offline inference at the moment. If you need to pass videos to be model via OpenAI API, you can instead provide multiple images for now. Please check the example in examples/openai_vision_api_client.py (especially the part labelled "Multi-image input inference")

We have just now fixed the issue in https://github.com/vllm-project/vllm/pull/8837. Please install vLLM from source to resolve the config loading problem.

Can we get a .post0 release for this? Installing from source is a lot more difficult.

use
pip install https://vllm-wheels.s3.us-west-2.amazonaws.com/nightly/vllm-1.0.0.dev-cp38-abi3-manylinux1_x86_64.whl
it will install the latest version of vllm.It worked for me just now

use pip install https://vllm-wheels.s3.us-west-2.amazonaws.com/nightly/vllm-1.0.0.dev-cp38-abi3-manylinux1_x86_64.whl it will install the latest version of vllm.It worked for me just now

I'd recommend against installing .whl files directly unless it's from a source that you trust.

vllm 0.62 运行还是报这个错：Unrecognized keys in rope_scaling for 'rope_type'='default': {'mrope_section'}

vllm 0.62 运行还是报这个错：Unrecognized keys in rope_scaling for 'rope_type'='default': {'mrope_section'}

Please install vLLM from source to fix the issue.

Hi everyone, I'm encountering the same error. It seems related to the rope_scaling["type"] settings in Qwen2VLConfig from the transformers library.
You can check the relevant code here:
if self.rope_scaling is not None and "type" in self.rope_scaling:
    if self.rope_scaling["type"] == "mrope":
        # self.rope_scaling["type"] = "default"
    self.rope_scaling["rope_type"] = self.rope_scaling["type"]
rope_config_validation(self, ignore_keys={"mrope_section"})

After commenting out that line, my program work well with transformers=4.45.2 and vllm=0.6.2.

change type to rope_type in config.json can fix this error in vllm==0.6.2


[FLINK-12742] Add insert into partition grammar as hive dialect

What is the purpose of the change
This pull request introduces a new insert into tbl1 partition(col1=1, col2='abc') grammar as an Apache Hive dialect.
Brief change log

Add a partition keyword to sql insert
Add a new SqlConformance named FlinkSqlConformance

Verifying this change
See tests in FlinkSqlParserImplTest and FlinkSqlUnParserTest.
This change added tests and can be verified as follows:
Does this pull request potentially affect one of the following parts:

Dependencies (does it add or upgrade a dependency): no
The public API, i.e., is any changed class annotated with @Public(Evolving): no
The serializers: no
The runtime per-record code paths (performance sensitive): no
Anything that affects deployment or recovery: JobManager (and its components), Checkpointing, Yarn/Mesos, ZooKeeper: no
The S3 file system connector: no

Documentation

Does this pull request introduce a new feature? yes
If yes, how is the feature documented? not documented

merged with 4320d8372f93e8fa4d82da06e5e0a0ba310195a2


fixed index page numbers

The cogs name list started from 2 in the index page, I made a small fix for it.
The main file was shown as "No Category" in the help command, so I made a small fix for it.

"No Category" is the name used by the built-in help command, since commands in "No Category" don't have a cog.
Also, cog numbering starts from 2 because it's supposed to reflect the page number the cog is on, not the cog number. See #39 and #38

Well, it does look a bit awkward for the numbering starting from 2, you are saying that it is the page number

I personally agree, but it seems @stroupbslayen prefers it this way. It might be best to make it an option, though.

Regarding the "no category" thing, only the makn file is named as "no category", since it isn't am extension. Any other file that you use in your bot and contains commands will be a cog, the cog names are present in the index page already. Also if you create cogs within your main file also, they will be considered as seperate cogs by the pretty help package. So having that as "Main cog" would seem more apt.

I'm going to close this and try to think of a different way to do address the concern. The issue has been brought up enough times that it's worth looking into. Thank you for your input though.


The input format for XNLI seems wired?

I try to test the XNLI results using the latest commit. And I find the inputs have a prefix_token which looks like:
[(('', ' 他说，妈妈，我回来了。, 正确? 是的, 校车把他放下后，他立即给他妈妈打了电话。'), [1], [55363, 2296, 55361, 2049, 55361, 55407, 7523, 55364, 55440, 55363, 2128, 56818, 5927, 55362, 55440, 52081, 55587, 5492, 6731, 55446, 55361, 55425, 1935, 3644, 2049, 7810, 878, 55364])]

This is the content of requests for _loglikelihood_tokens. The context is '' and context_enc is [1]. It is appended in this function from lm_eval/api/model.py:
    def loglikelihood(
        self, requests, disable_tqdm: bool = False
    ) -> List[Tuple[float, bool]]:
        new_reqs = []
        for context, continuation in [req.args for req in requests]:
            if context == "":
                # BOS or EOS as context
                context_enc, continuation_enc = (
                    [self.prefix_token_id],
                    self.tok_encode(continuation),
                )
            else:
                context_enc, continuation_enc = self._encode_pair(context, continuation)

            new_reqs.append(((context, continuation), context_enc, continuation_enc))

        return self._loglikelihood_tokens(new_reqs, disable_tqdm=disable_tqdm)

As XNLI's config (xnli_zh.yaml) is this:
dataset_name: zh
doc_to_choice: '{{[premise+", 正确? 是的, "+hypothesis,premise+", 正确? 所以, "+hypothesis,premise+",
  正确? 不是的, "+hypothesis]}}'
doc_to_text: ''
include: xnli_common_yaml
task: xnli_zh

It merges both premise and hypothesis and has no context. So, the code will add a prefix_token_id to the input for any model.
This input format seems wired for base model as most LLM do not use bos or eos in the start of inputs (maybe except Gemma).

cc @lintangsutawika


community packages not showing

First, take a look at this:

It states that I have 29 community packages installed but I can see only 1.
Atom version : 1.5.3
Mac OS X El Capitan

@cloxure You're probably running into the same issue as atom/settings-view#591 - that issue should help you identify the misbehaving package.

thanks @50Wliu.


Add stats for procrustes

As per @sturlamolden's suggestion in #4540 scipy.spatial.procrustes should provide statistical testing:

Randomization test for p-values and bootstrapping for standard error is the easiest, ...

I don't think we need this, at least it's not high-prio. Closing as we do with many old enhancement requests.


Blog app: add devise

In this milestone of the project, I did the following:

Install and setup devise.
Modify code to register a new user.
Modify code to enable a User to logs in with a combination of email and password.
Modify code to store Hashed password in the database.
Modify code to ask for confirmation of email.
Modify code to reset password.

@OLIPLICHE thank you very much, sir.


BaseStream.Length() shouldn't need to be necessary prior to BlockBlobStorageClient.Upload

Is your feature request related to a problem? Please describe.
I created my own BaseStream implementation with the OnRead function mimicing libcurl's readdata callback function. However, due to the work that is being done in that function (librsync delta creation via it's streaming api) I don't know the size of the uploaded data before calling BlockBlobStorageClient.Upload. Ideally, the length of the stream shouldn't need to be known before the upload.
Describe the solution you'd like
Uploading via libcurl doesn't require the size to be known ahead of time, so I'd think the azure library shouldn't either.
Describe alternatives you've considered
Only alternative I can think of is to do a block stage and commit (where the block size is small enough that it's not too much data in memory at one time)
Information Checklist
Kindly make sure that you have added all the following information above and checkoff the required fields otherwise we will treat the issuer as an incomplete report

[x] Description Added
[x] Expected solution specified

Hi @ashf , if you look at the REST API reference, the Content-Length header is sent before sending out the HTTP request body. So I think the length is required to be known before uploading.

Uploading via libcurl doesn't require the size to be known ahead of time

Do you know how it's implemented in libcurl? Does libcurl cache all the data in memory and only start uploading when it gets all the data and knows the length? If that's the case, we cannot do that, because many of our customers transfer huge size of data to/from storage that memory is not big enough to cache all the data.

Only alternative I can think of is to do a block stage and commit (where the block size is small enough that it's not too much data in memory at one time)

I believe this is the right way to go.

Do you know how it's implemented in libcurl? Does libcurl cache all the data in memory and only start uploading when it gets all the data and knows the length? If that's the case, we cannot do that, because many of our customers transfer huge size of data to/from storage that memory is not big enough to cache all the data.

Unsure of how libcurl does it under the hood. I think it has more to do with how the receiving endpoint handles an unknown content length (but I could be mistaken).
I have switched to using the block stage/commit and that works well for my needs. Thanks.