text:
[bug]: Failed to load sd-1:main:unet model

Is there an existing issue for this?

[X] I have searched the existing issues

OS
macOS
GPU
cpu
VRAM
16GB
What version did you experience this issue on?
3.0.1
What happened?
I'm encountering a persistent issue when trying to use the Unified Canvas in combination with various inpainting models. Specifically, every time I attempt to load an inpainting model onto the mask layer of the Unified Canvas, I receive the following error message: "Failed to load sd-1:main:unet model".
I've tested this problem across multiple inpainting models, including dreamshaper_8Inpainting.safetensors, epicrealism_pureEvolutionV3-inpainting.safetensors, and epicrealism_v10.0-inpainting.safetensors. For these models, the error persists regardless of whether they are installed through the UI or the terminal.
I've also attempted to clear some RAM to ensure that this wasn't a memory-related issue, but it had no effect on the problem at hand. I'm on a 2021 14" MacBook Pro with an M1 Pro processor and 16GB of unified memory.
Interestingly, the stable-diffusion-inpainting model seems to be the only inpainting model that works correctly with the Unified Canvas. I've attached the relevant logs to provide further details on this.
[2023-08-02 14:23:43,116]::[uvicorn.access]::INFO --> 127.0.0.1:63040 - "GET /api/v1/images/?is_intermediate=true HTTP/1.1" 200
[2023-08-02 14:26:38,634]::[uvicorn.access]::INFO --> 127.0.0.1:63141 - "POST /api/v1/images/?image_category=general&is_intermediate=true HTTP/1.1" 201
[2023-08-02 14:26:38,680]::[uvicorn.access]::INFO --> 127.0.0.1:63141 - "POST /api/v1/images/?image_category=mask&is_intermediate=true HTTP/1.1" 201
[2023-08-02 14:26:38,694]::[uvicorn.access]::INFO --> 127.0.0.1:63141 - "POST /api/v1/sessions/ HTTP/1.1" 200
[2023-08-02 14:26:38,724]::[uvicorn.access]::INFO --> 127.0.0.1:63141 - "PUT /api/v1/sessions/7c7942ce-9bc5-49fa-83fe-6eeb0f339a1d/invoke?all=true HTTP/1.1" 202
[2023-08-02 14:26:38,734]::[uvicorn.access]::INFO --> 127.0.0.1:63142 - "PATCH /api/v1/images/9bc7d171-15fe-4a74-b6d8-ce84ad4a02b1.png HTTP/1.1" 200
[2023-08-02 14:26:38,736]::[uvicorn.access]::INFO --> 127.0.0.1:63143 - "PATCH /api/v1/images/916884c9-b6c7-4aff-8bfb-27631822035e.png HTTP/1.1" 200
[2023-08-02 14:26:38,741]::[InvokeAI]::INFO --> Loading model /Applications/InvokeAI/models/sd-1/main/stable-diffusion-inpainting, type sd-1:main:tokenizer
[2023-08-02 14:26:39,090]::[InvokeAI]::INFO --> Loading model /Applications/InvokeAI/models/sd-1/main/stable-diffusion-inpainting, type sd-1:main:text_encoder
[2023-08-02 14:26:51,462]::[InvokeAI]::INFO --> Loading model /Applications/InvokeAI/models/sd-1/main/stable-diffusion-inpainting, type sd-1:main:scheduler
[2023-08-02 14:26:51,738]::[InvokeAI]::INFO --> Loading model /Applications/InvokeAI/models/sd-1/main/stable-diffusion-inpainting, type sd-1:main:unet
[2023-08-02 14:26:57,638]::[InvokeAI]::INFO --> Loading model /Applications/InvokeAI/models/sd-1/main/stable-diffusion-inpainting, type sd-1:main:vae
Generating:   0%|                                                                                | 0/1 [00:00<?, ?it/s]You have disabled the safety checker for <class 'diffusers.pipelines.stable_diffusion.pipeline_stable_diffusion_img2img.StableDiffusionImg2ImgPipeline'> by passing `safety_checker=None`. Ensure that you abide to the conditions of the Stable Diffusion license and do not expose unfiltered results in services or applications open to the public. Both the diffusers team and Hugging Face strongly recommend to keep the safety filter enabled in all public facing circumstances, disabling it only for use-cases that involve analyzing network behavior or auditing its results. For more information, please have a look at https://github.com/huggingface/diffusers/pull/254 .

 11%|███████████████████▌                                                                                | 8/73 [00:07<00:57,  1.13it/s]

Screenshots
No response
Additional context
Logs of failed attempt with other inpainting models.
[2023-08-02 14:22:00,912]::[uvicorn.access]::INFO --> 127.0.0.1:62878 - "POST /api/v1/images/?image_category=general&is_intermediate=true HTTP/1.1" 201
[2023-08-02 14:22:00,952]::[uvicorn.access]::INFO --> 127.0.0.1:62878 - "POST /api/v1/images/?image_category=mask&is_intermediate=true HTTP/1.1" 201
[2023-08-02 14:22:00,965]::[uvicorn.access]::INFO --> 127.0.0.1:62878 - "POST /api/v1/sessions/ HTTP/1.1" 200
[2023-08-02 14:22:01,000]::[uvicorn.access]::INFO --> 127.0.0.1:62878 - "PUT /api/v1/sessions/b33ea185-f7c0-4fa8-9d65-2148bff29a0a/invoke?all=true HTTP/1.1" 202
[2023-08-02 14:22:01,050]::[uvicorn.access]::INFO --> 127.0.0.1:62879 - "PATCH /api/v1/images/f5a5baed-1c1b-42be-b370-a14b872e0ed3.png HTTP/1.1" 200
[2023-08-02 14:22:01,088]::[uvicorn.access]::INFO --> 127.0.0.1:62880 - "PATCH /api/v1/images/5d79a6d3-abd6-4e10-ad68-68e677c6aaab.png HTTP/1.1" 200
[2023-08-02 14:22:02,574]::[InvokeAI]::INFO --> Loading model /Applications/InvokeAI/models/.cache/d35ae597b8af6273326895437bfd6520, type sd-1:main:unet
[2023-08-02 14:22:03,224]::[InvokeAI]::ERROR --> Traceback (most recent call last):
  File "/Applications/InvokeAI/.venv/lib/python3.9/site-packages/invokeai/app/services/processor.py", line 86, in __process
    outputs = invocation.invoke(
  File "/Applications/InvokeAI/.venv/lib/python3.9/site-packages/invokeai/app/invocations/generate.py", line 220, in invoke
    with self.load_model_old_way(context, scheduler) as model:
  File "/Applications/Xcode.app/Contents/Developer/Library/Frameworks/Python3.framework/Versions/3.9/lib/python3.9/contextlib.py", line 117, in __enter__
    return next(self.gen)
  File "/Applications/InvokeAI/.venv/lib/python3.9/site-packages/invokeai/app/invocations/generate.py", line 174, in load_model_old_way
    unet_info = context.services.model_manager.get_model(
  File "/Applications/InvokeAI/.venv/lib/python3.9/site-packages/invokeai/app/services/model_manager_service.py", line 364, in get_model
    model_info = self.mgr.get_model(
  File "/Applications/InvokeAI/.venv/lib/python3.9/site-packages/invokeai/backend/model_management/model_manager.py", line 491, in get_model
    model_context = self.cache.get_model(
  File "/Applications/InvokeAI/.venv/lib/python3.9/site-packages/invokeai/backend/model_management/model_cache.py", line 198, in get_model
    model = model_info.get_model(child_type=submodel, torch_dtype=self.precision)
  File "/Applications/InvokeAI/.venv/lib/python3.9/site-packages/invokeai/backend/model_management/models/base.py", line 286, in get_model
    raise Exception(f"Failed to load {self.base_model}:{self.model_type}:{child_type} model")
Exception: Failed to load sd-1:main:unet model

[2023-08-02 14:22:03,226]::[InvokeAI]::ERROR --> Error while invoking:
Failed to load sd-1:main:unet model

Contact Details
No response

Same exact error with dreamshaper 8 inpainting model

Here from google, same issue. Dreamshaper 4 in-painting will not load, standard SD1-5 inpainting works.
Windows 10

Also on MacOS, been having this same issue since 3.0.1

All pinpointing models except standard are failing for me.

sorry to leave a "same here" comment.
New to Invoke as of today and can confirm this issue persists even with a fresh and clean installation.
only the OG stable diffusion inpainting model works, no downloaded ones work.
I did try converting to diffusers, as well as re-downloading the config yaml for inpainting and linking it.
As well as re-downloading and tagging the checkpoints as inpainting as well as standard checkpoints.
Nothing.
Hope they fix it, the whole reason I moved from A1111 was for the unified canvas.

Many inpainting checkpoint models are not loading properly in 3.0.1. The fix is in the main branch of the code and will be rolled out in 3.0.2 (very soon now).

@lstein
I upgraded to main branch using option 9 in the CLI and I'm still getting the error with Dreamshaper 8 inpainting model.
Thank you for your efforts on this though!

I'm seeing the same as @lstein -- upgraded to main and it's still broken.

same here. the only model that matters aka the inpaint model on the unified canvas on invokeai and its broken.

Updated to Main today (3.0.2a1) and inpainting is resolved for me. I'm inclined to close the ticket unless others have the same issue when pulling from main.

@dannyvfilms Which model worked for you? I'm still getting it.

cyberrealistic_v32-inpainting. I didn't extensively try all of them, so I don't have logs to share at the moment.

CyberRealistic inpainting does seem to work for me, but Deliberate and Deliberate both do not. @dannyvfilms

Just updated to main and tried again, still getting the error. Here's the entire output in the terminal.
[2023-08-07 07:39:16,329]::[InvokeAI]::INFO --> Loading model D:\StableDiffusion\InvokeAI\models\.cache\3b6561f4b4c18bec0fccf5d067e11ae5, type sd-1:main:text_encoder
[2023-08-07 07:39:29,686]::[InvokeAI]::INFO --> Loading model D:\StableDiffusion\InvokeAI\models\sd-1\embedding\FastNegativeV2.pt, type sd-1:embedding
[2023-08-07 07:39:32,380]::[InvokeAI]::INFO --> Loading model D:\StableDiffusion\InvokeAI\models\.cache\3b6561f4b4c18bec0fccf5d067e11ae5, type sd-1:main:unet
====ERR LOAD====
None: Cannot load D:\StableDiffusion\InvokeAI\models\.cache\3b6561f4b4c18bec0fccf5d067e11ae5 because conv_in.weight expected shape tensor(..., device='meta', size=(320, 4, 3, 3)), but got torch.Size([320, 9, 3, 3]). If you want to instead overwrite randomly initialized weights, please make sure to pass both `low_cpu_mem_usage=False` and `ignore_mismatched_sizes=True`. For more information, see also: https://github.com/huggingface/diffusers/issues/1619#issuecomment-1345604389 as an example.
[2023-08-07 07:39:34,449]::[InvokeAI]::ERROR --> Traceback (most recent call last):
  File "D:\StableDiffusion\InvokeAI\.venv\lib\site-packages\invokeai\app\services\processor.py", line 90, in __process
    outputs = invocation.invoke(
  File "D:\StableDiffusion\InvokeAI\.venv\lib\site-packages\torch\utils\_contextlib.py", line 115, in decorate_context
    return func(*args, **kwargs)
  File "D:\StableDiffusion\InvokeAI\.venv\lib\site-packages\invokeai\app\invocations\latent.py", line 428, in invoke
    unet_info = context.services.model_manager.get_model(
  File "D:\StableDiffusion\InvokeAI\.venv\lib\site-packages\invokeai\app\services\model_manager_service.py", line 365, in get_model
    model_info = self.mgr.get_model(
  File "D:\StableDiffusion\InvokeAI\.venv\lib\site-packages\invokeai\backend\model_management\model_manager.py", line 491, in get_model
    model_context = self.cache.get_model(
  File "D:\StableDiffusion\InvokeAI\.venv\lib\site-packages\invokeai\backend\model_management\model_cache.py", line 198, in get_model
    model = model_info.get_model(child_type=submodel, torch_dtype=self.precision)
  File "D:\StableDiffusion\InvokeAI\.venv\lib\site-packages\invokeai\backend\model_management\models\base.py", line 300, in get_model
    raise Exception(f"Failed to load {self.base_model}:{self.model_type}:{child_type} model")
Exception: Failed to load sd-1:main:unet model

[2023-08-07 07:39:34,633]::[InvokeAI]::ERROR --> Error while invoking:
Failed to load sd-1:main:unet model```

Same problem, running InvokeAI 3.01 (hotfix 3). Running Pop!_OS (Ubuntu base). Do not have any issues running Automic1111. Although I really prefer InvokeAI.

Updated to 3.0.2rc1 and the issue appears to persist with epicrealism_pureEvolutionV5-inpainting.safetensors
[2023-08-09 16:44:23,930]::[uvicorn.access]::INFO --> 127.0.0.1:59009 - "POST /api/v1/images/upload?image_category=mask&is_intermediate=true HTTP/1.1" 201
[2023-08-09 16:44:23,940]::[uvicorn.access]::INFO --> 127.0.0.1:59009 - "POST /api/v1/sessions/ HTTP/1.1" 200
[2023-08-09 16:44:23,966]::[uvicorn.access]::INFO --> 127.0.0.1:59009 - "PUT /api/v1/sessions/04c8e416-03c7-40cc-a8f5-8483bb40522b/invoke?all=true HTTP/1.1" 202
[2023-08-09 16:44:23,971]::[uvicorn.access]::INFO --> 127.0.0.1:59010 - "PATCH /api/v1/images/i/c765c45e-097c-4b3e-8209-27890a1de6f9.png HTTP/1.1" 200
[2023-08-09 16:44:23,974]::[uvicorn.access]::INFO --> 127.0.0.1:59011 - "PATCH /api/v1/images/i/d9e31a2c-7e6a-41ff-a159-f6cd60cc8e64.png HTTP/1.1" 200
[2023-08-09 16:44:23,998]::[uvicorn.access]::INFO --> 127.0.0.1:59009 - "GET /api/v1/images/?board_id=none&categories=general&is_intermediate=false&limit=0&offset=0 HTTP/1.1" 200
[2023-08-09 16:44:24,055]::[uvicorn.access]::INFO --> 127.0.0.1:59010 - "GET /api/v1/images/?board_id=none&categories=control&categories=mask&categories=user&categories=other&is_intermediate=false&limit=0&offset=0 HTTP/1.1" 200
[2023-08-09 16:44:24,785]::[InvokeAI]::INFO --> Loading model /Applications/InvokeAI/models/.cache/6161a84c53c26ce2e24a1544860280bb, type sd-1:main:unet
====ERR LOAD====
None: Cannot load /Applications/InvokeAI/models/.cache/6161a84c53c26ce2e24a1544860280bb because conv_in.weight expected shape tensor(..., device='meta', size=(320, 4, 3, 3)), but got torch.Size([320, 9, 3, 3]). If you want to instead overwrite randomly initialized weights, please make sure to pass both `low_cpu_mem_usage=False` and `ignore_mismatched_sizes=True`. For more information, see also: https://github.com/huggingface/diffusers/issues/1619#issuecomment-1345604389 as an example.
[2023-08-09 16:44:25,377]::[InvokeAI]::ERROR --> Traceback (most recent call last):
  File "/Applications/InvokeAI/.venv/lib/python3.9/site-packages/invokeai/app/services/processor.py", line 90, in __process
    outputs = invocation.invoke(
  File "/Applications/InvokeAI/.venv/lib/python3.9/site-packages/invokeai/app/invocations/generate.py", line 220, in invoke
    with self.load_model_old_way(context, scheduler) as model:
  File "/Applications/Xcode.app/Contents/Developer/Library/Frameworks/Python3.framework/Versions/3.9/lib/python3.9/contextlib.py", line 117, in __enter__
    return next(self.gen)
  File "/Applications/InvokeAI/.venv/lib/python3.9/site-packages/invokeai/app/invocations/generate.py", line 174, in load_model_old_way
    unet_info = context.services.model_manager.get_model(
  File "/Applications/InvokeAI/.venv/lib/python3.9/site-packages/invokeai/app/services/model_manager_service.py", line 365, in get_model
    model_info = self.mgr.get_model(
  File "/Applications/InvokeAI/.venv/lib/python3.9/site-packages/invokeai/backend/model_management/model_manager.py", line 491, in get_model
    model_context = self.cache.get_model(
  File "/Applications/InvokeAI/.venv/lib/python3.9/site-packages/invokeai/backend/model_management/model_cache.py", line 198, in get_model
    model = model_info.get_model(child_type=submodel, torch_dtype=self.precision)
  File "/Applications/InvokeAI/.venv/lib/python3.9/site-packages/invokeai/backend/model_management/models/base.py", line 300, in get_model
    raise Exception(f"Failed to load {self.base_model}:{self.model_type}:{child_type} model")
Exception: Failed to load sd-1:main:unet model

[2023-08-09 16:44:25,378]::[InvokeAI]::ERROR --> Error while invoking:
Failed to load sd-1:main:unet model```

@dannyvfilms @nbs @nelsonre @BakonGuy @egoegoegoegoego could y'all try re-adding the model that was giving you difficulty and seeing if that fixes the issue?
@Quildar could you try updating to 3.0.2rc1 and see if the issue persists?

@Millu re-adding the model generated a different issue:
[2023-08-09 19:12:31,087]::[InvokeAI]::INFO --> Converting /Applications/InvokeAI/autoimport/main/epicrealism_pureEvolutionV5-inpainting.safetensors to diffusers format
[2023-08-09 19:12:42,220]::[InvokeAI]::INFO --> Loading model /Applications/InvokeAI/models/.cache/6161a84c53c26ce2e24a1544860280bb, type sd-1:main:tokenizer
[2023-08-09 19:12:42,754]::[InvokeAI]::INFO --> Loading model /Applications/InvokeAI/models/.cache/6161a84c53c26ce2e24a1544860280bb, type sd-1:main:text_encoder
[2023-08-09 19:12:54,358]::[InvokeAI]::INFO --> Loading model /Applications/InvokeAI/models/.cache/6161a84c53c26ce2e24a1544860280bb, type sd-1:main:scheduler
[2023-08-09 19:12:54,571]::[InvokeAI]::INFO --> Loading model /Applications/InvokeAI/models/.cache/6161a84c53c26ce2e24a1544860280bb, type sd-1:main:unet
/Applications/InvokeAI/.venv/lib/python3.9/site-packages/diffusers/configuration_utils.py:134: FutureWarning: Accessing config attribute `requires_safety_checker` directly via 'StableDiffusionGeneratorPipeline' object attribute is deprecated. Please access 'requires_safety_checker' over 'StableDiffusionGeneratorPipeline's config object instead, e.g. 'scheduler.config.requires_safety_checker'.
  deprecate("direct config name access", "1.0.0", deprecation_message, standard_warn=False)
Generating:   0%|                                                                                | 0/1 [00:00<?, ?it/s]You have disabled the safety checker for <class 'diffusers.pipelines.stable_diffusion.pipeline_stable_diffusion_img2img.StableDiffusionImg2ImgPipeline'> by passing `safety_checker=None`. Ensure that you abide to the conditions of the Stable Diffusion license and do not expose unfiltered results in services or applications open to the public. Both the diffusers team and Hugging Face strongly recommend to keep the safety filter enabled in all public facing circumstances, disabling it only for use-cases that involve analyzing network behavior or auditing its results. For more information, please have a look at https://github.com/huggingface/diffusers/pull/254 .
Generating:   0%|                                                                                | 0/1 [00:00<?, ?it/s]
[2023-08-09 19:13:15,918]::[InvokeAI]::ERROR --> Traceback (most recent call last):
  File "/Applications/InvokeAI/.venv/lib/python3.9/site-packages/invokeai/app/services/processor.py", line 90, in __process
    outputs = invocation.invoke(
  File "/Applications/InvokeAI/.venv/lib/python3.9/site-packages/invokeai/app/invocations/generate.py", line 236, in invoke
    generator_output = next(outputs)
  File "/Applications/InvokeAI/.venv/lib/python3.9/site-packages/invokeai/backend/generator/base.py", line 144, in generate
    results = generator.generate(
  File "/Applications/InvokeAI/.venv/lib/python3.9/site-packages/invokeai/backend/generator/base.py", line 328, in generate
    image = make_image(x_T, seed)
  File "/Applications/InvokeAI/.venv/lib/python3.9/site-packages/invokeai/backend/generator/inpaint.py", line 292, in make_image
    pipeline_output = pipeline.inpaint_from_embeddings(
  File "/Applications/InvokeAI/.venv/lib/python3.9/site-packages/invokeai/backend/stable_diffusion/diffusers_pipeline.py", line 826, in inpaint_from_embeddings
    init_image_latents = self.non_noised_latents_from_image(init_image, device=device, dtype=latents_dtype)
  File "/Applications/InvokeAI/.venv/lib/python3.9/site-packages/invokeai/backend/stable_diffusion/diffusers_pipeline.py", line 886, in non_noised_latents_from_image
    init_latent_dist = self.vae.encode(init_image).latent_dist
  File "/Applications/InvokeAI/.venv/lib/python3.9/site-packages/diffusers/utils/accelerate_utils.py", line 46, in wrapper
    return method(self, *args, **kwargs)
  File "/Applications/InvokeAI/.venv/lib/python3.9/site-packages/diffusers/models/autoencoder_kl.py", line 242, in encode
    h = self.encoder(x)
  File "/Applications/InvokeAI/.venv/lib/python3.9/site-packages/torch/nn/modules/module.py", line 1501, in _call_impl
    return forward_call(*args, **kwargs)
  File "/Applications/InvokeAI/.venv/lib/python3.9/site-packages/diffusers/models/vae.py", line 110, in forward
    sample = self.conv_in(sample)
  File "/Applications/InvokeAI/.venv/lib/python3.9/site-packages/torch/nn/modules/module.py", line 1501, in _call_impl
    return forward_call(*args, **kwargs)
  File "/Applications/InvokeAI/.venv/lib/python3.9/site-packages/torch/nn/modules/conv.py", line 463, in forward
    return self._conv_forward(input, self.weight, self.bias)
  File "/Applications/InvokeAI/.venv/lib/python3.9/site-packages/torch/nn/modules/conv.py", line 459, in _conv_forward
    return F.conv2d(input, weight, bias, self.stride,
RuntimeError: Input type (c10::Half) and bias type (float) should be the same

[2023-08-09 19:13:15,922]::[InvokeAI]::ERROR --> Error while invoking:
Input type (c10::Half) and bias type (float) should be the same
[```
Changing the VAE from `sd-vae-ft-mse` to `Default` in combination with re-adding the model resolved the issue.

@dannyvfilms @nbs @nelsonre @BakonGuy @egoegoegoegoego could y'all try re-adding the model that was giving you difficulty and seeing if that fixes the issue?
@Quildar could you try updating to 3.0.2rc1 and see if the issue persists?

Ah that does fix it for me (Dreamshaper 8 Inpainting model). Thank you.

@dannyvfilms @nbs @nelsonre @BakonGuy @egoegoegoegoego could y'all try re-adding the model that was giving you difficulty and seeing if that fixes the issue?
@Quildar could you try updating to 3.0.2rc1 and see if the issue persists?

Updated and found the inpaint models still didn't work. After removing them from Invoke and redownloading them again, they work now.
Cheers

I tried a handful of in-painting models that were giving me issues before. With 3.0.2rc1, they load fine now.

The same model that was fixed for me last night was working, then stopped working without explanation. Changing the VAE and removing the LORA did not resolve the issue.
[2023-08-10 13:59:08,993]::[uvicorn.access]::INFO --> 127.0.0.1:50767 - "POST /api/v1/images/upload?image_category=mask&is_intermediate=true HTTP/1.1" 201
[2023-08-10 13:59:09,017]::[uvicorn.access]::INFO --> 127.0.0.1:50767 - "POST /api/v1/sessions/ HTTP/1.1" 200
[2023-08-10 13:59:09,056]::[uvicorn.access]::INFO --> 127.0.0.1:50767 - "PUT /api/v1/sessions/97b9e9d5-6954-4db4-bb10-e4ae5219d31d/invoke?all=true HTTP/1.1" 202
[2023-08-10 13:59:09,067]::[uvicorn.access]::INFO --> 127.0.0.1:50768 - "PATCH /api/v1/images/i/c5126e81-813f-4e80-825e-07106a030f42.png HTTP/1.1" 200
[2023-08-10 13:59:09,068]::[uvicorn.access]::INFO --> 127.0.0.1:50769 - "PATCH /api/v1/images/i/c8739c12-12fd-43f5-bfd2-84bc8fdeccc8.png HTTP/1.1" 200
/Applications/InvokeAI/.venv/lib/python3.9/site-packages/diffusers/configuration_utils.py:134: FutureWarning: Accessing config attribute `requires_safety_checker` directly via 'StableDiffusionGeneratorPipeline' object attribute is deprecated. Please access 'requires_safety_checker' over 'StableDiffusionGeneratorPipeline's config object instead, e.g. 'scheduler.config.requires_safety_checker'.
  deprecate("direct config name access", "1.0.0", deprecation_message, standard_warn=False)
Generating:   0%|                                                                                | 0/1 [00:00<?, ?it/s]You have disabled the safety checker for <class 'diffusers.pipelines.stable_diffusion.pipeline_stable_diffusion_img2img.StableDiffusionImg2ImgPipeline'> by passing `safety_checker=None`. Ensure that you abide to the conditions of the Stable Diffusion license and do not expose unfiltered results in services or applications open to the public. Both the diffusers team and Hugging Face strongly recommend to keep the safety filter enabled in all public facing circumstances, disabling it only for use-cases that involve analyzing network behavior or auditing its results. For more information, please have a look at https://github.com/huggingface/diffusers/pull/254 .
Generating:   0%|                                                                                | 0/1 [00:00<?, ?it/s]
[2023-08-10 13:59:30,088]::[InvokeAI]::ERROR --> Traceback (most recent call last):
  File "/Applications/InvokeAI/.venv/lib/python3.9/site-packages/invokeai/app/services/processor.py", line 90, in __process
    outputs = invocation.invoke(
  File "/Applications/InvokeAI/.venv/lib/python3.9/site-packages/invokeai/app/invocations/generate.py", line 236, in invoke
    generator_output = next(outputs)
  File "/Applications/InvokeAI/.venv/lib/python3.9/site-packages/invokeai/backend/generator/base.py", line 144, in generate
    results = generator.generate(
  File "/Applications/InvokeAI/.venv/lib/python3.9/site-packages/invokeai/backend/generator/base.py", line 328, in generate
    image = make_image(x_T, seed)
  File "/Applications/InvokeAI/.venv/lib/python3.9/site-packages/invokeai/backend/generator/inpaint.py", line 292, in make_image
    pipeline_output = pipeline.inpaint_from_embeddings(
  File "/Applications/InvokeAI/.venv/lib/python3.9/site-packages/invokeai/backend/stable_diffusion/diffusers_pipeline.py", line 826, in inpaint_from_embeddings
    init_image_latents = self.non_noised_latents_from_image(init_image, device=device, dtype=latents_dtype)
  File "/Applications/InvokeAI/.venv/lib/python3.9/site-packages/invokeai/backend/stable_diffusion/diffusers_pipeline.py", line 886, in non_noised_latents_from_image
    init_latent_dist = self.vae.encode(init_image).latent_dist
  File "/Applications/InvokeAI/.venv/lib/python3.9/site-packages/diffusers/utils/accelerate_utils.py", line 46, in wrapper
    return method(self, *args, **kwargs)
  File "/Applications/InvokeAI/.venv/lib/python3.9/site-packages/diffusers/models/autoencoder_kl.py", line 242, in encode
    h = self.encoder(x)
  File "/Applications/InvokeAI/.venv/lib/python3.9/site-packages/torch/nn/modules/module.py", line 1501, in _call_impl
    return forward_call(*args, **kwargs)
  File "/Applications/InvokeAI/.venv/lib/python3.9/site-packages/diffusers/models/vae.py", line 110, in forward
    sample = self.conv_in(sample)
  File "/Applications/InvokeAI/.venv/lib/python3.9/site-packages/torch/nn/modules/module.py", line 1501, in _call_impl
    return forward_call(*args, **kwargs)
  File "/Applications/InvokeAI/.venv/lib/python3.9/site-packages/torch/nn/modules/conv.py", line 463, in forward
    return self._conv_forward(input, self.weight, self.bias)
  File "/Applications/InvokeAI/.venv/lib/python3.9/site-packages/torch/nn/modules/conv.py", line 459, in _conv_forward
    return F.conv2d(input, weight, bias, self.stride,
RuntimeError: Input type (c10::Half) and bias type (float) should be the same

[2023-08-10 13:59:30,091]::[InvokeAI]::ERROR --> Error while invoking:
Input type (c10::Half) and bias type (float) should be the same
[2023-08-10 13:59:36,613]::[uvicorn.access]::INFO --> 127.0.0.1:50831 - "POST /api/v1/images/upload?image_category=general&is_intermediate=true HTTP/1.1" 201
[2023-08-10 13:59:36,688]::[uvicorn.access]::INFO --> 127.0.0.1:50831 - "POST /api/v1/images/upload?image_category=mask&is_intermediate=true HTTP/1.1" 201
[2023-08-10 13:59:36,737]::[uvicorn.access]::INFO --> 127.0.0.1:50831 - "POST /api/v1/sessions/ HTTP/1.1" 200
[2023-08-10 13:59:36,780]::[uvicorn.access]::INFO --> 127.0.0.1:50831 - "PUT /api/v1/sessions/9a0b3745-45ba-4dfd-9007-1d87759df961/invoke?all=true HTTP/1.1" 202
[2023-08-10 13:59:36,787]::[uvicorn.access]::INFO --> 127.0.0.1:50832 - "PATCH /api/v1/images/i/809f170b-f5c8-4b78-ba61-7045665c7d61.png HTTP/1.1" 200
[2023-08-10 13:59:36,789]::[uvicorn.access]::INFO --> 127.0.0.1:50833 - "PATCH /api/v1/images/i/be5a551a-ad7e-46e8-9405-a3bd6d442d47.png HTTP/1.1" 200
Generating:   0%|                                                                                | 0/1 [00:00<?, ?it/s]You have disabled the safety checker for <class 'diffusers.pipelines.stable_diffusion.pipeline_stable_diffusion_img2img.StableDiffusionImg2ImgPipeline'> by passing `safety_checker=None`. Ensure that you abide to the conditions of the Stable Diffusion license and do not expose unfiltered results in services or applications open to the public. Both the diffusers team and Hugging Face strongly recommend to keep the safety filter enabled in all public facing circumstances, disabling it only for use-cases that involve analyzing network behavior or auditing its results. For more information, please have a look at https://github.com/huggingface/diffusers/pull/254 .
Generating:   0%|                                                                                | 0/1 [00:00<?, ?it/s]
[2023-08-10 13:59:42,968]::[InvokeAI]::ERROR --> Traceback (most recent call last):
  File "/Applications/InvokeAI/.venv/lib/python3.9/site-packages/invokeai/app/services/processor.py", line 90, in __process
    outputs = invocation.invoke(
  File "/Applications/InvokeAI/.venv/lib/python3.9/site-packages/invokeai/app/invocations/generate.py", line 236, in invoke
    generator_output = next(outputs)
  File "/Applications/InvokeAI/.venv/lib/python3.9/site-packages/invokeai/backend/generator/base.py", line 144, in generate
    results = generator.generate(
  File "/Applications/InvokeAI/.venv/lib/python3.9/site-packages/invokeai/backend/generator/base.py", line 328, in generate
    image = make_image(x_T, seed)
  File "/Applications/InvokeAI/.venv/lib/python3.9/site-packages/invokeai/backend/generator/inpaint.py", line 292, in make_image
    pipeline_output = pipeline.inpaint_from_embeddings(
  File "/Applications/InvokeAI/.venv/lib/python3.9/site-packages/invokeai/backend/stable_diffusion/diffusers_pipeline.py", line 826, in inpaint_from_embeddings
    init_image_latents = self.non_noised_latents_from_image(init_image, device=device, dtype=latents_dtype)
  File "/Applications/InvokeAI/.venv/lib/python3.9/site-packages/invokeai/backend/stable_diffusion/diffusers_pipeline.py", line 886, in non_noised_latents_from_image
    init_latent_dist = self.vae.encode(init_image).latent_dist
  File "/Applications/InvokeAI/.venv/lib/python3.9/site-packages/diffusers/utils/accelerate_utils.py", line 46, in wrapper
    return method(self, *args, **kwargs)
  File "/Applications/InvokeAI/.venv/lib/python3.9/site-packages/diffusers/models/autoencoder_kl.py", line 242, in encode
    h = self.encoder(x)
  File "/Applications/InvokeAI/.venv/lib/python3.9/site-packages/torch/nn/modules/module.py", line 1501, in _call_impl
    return forward_call(*args, **kwargs)
  File "/Applications/InvokeAI/.venv/lib/python3.9/site-packages/diffusers/models/vae.py", line 110, in forward
    sample = self.conv_in(sample)
  File "/Applications/InvokeAI/.venv/lib/python3.9/site-packages/torch/nn/modules/module.py", line 1501, in _call_impl
    return forward_call(*args, **kwargs)
  File "/Applications/InvokeAI/.venv/lib/python3.9/site-packages/torch/nn/modules/conv.py", line 463, in forward
    return self._conv_forward(input, self.weight, self.bias)
  File "/Applications/InvokeAI/.venv/lib/python3.9/site-packages/torch/nn/modules/conv.py", line 459, in _conv_forward
    return F.conv2d(input, weight, bias, self.stride,
RuntimeError: Input type (c10::Half) and bias type (float) should be the same

[2023-08-10 13:59:42,971]::[InvokeAI]::ERROR --> Error while invoking:
Input type (c10::Half) and bias type (float) should be the same
[2023-08-10 14:01:43,804]::[uvicorn.access]::INFO --> 127.0.0.1:51024 - "POST /api/v1/images/upload?image_category=general&is_intermediate=true HTTP/1.1" 201
[2023-08-10 14:01:43,844]::[uvicorn.access]::INFO --> 127.0.0.1:51024 - "POST /api/v1/images/upload?image_category=mask&is_intermediate=true HTTP/1.1" 201
[2023-08-10 14:01:43,871]::[uvicorn.access]::INFO --> 127.0.0.1:51024 - "POST /api/v1/sessions/ HTTP/1.1" 200
[2023-08-10 14:01:43,912]::[uvicorn.access]::INFO --> 127.0.0.1:51024 - "PUT /api/v1/sessions/f9394f53-ec3d-43db-94b6-755b7826d858/invoke?all=true HTTP/1.1" 202
[2023-08-10 14:01:43,919]::[uvicorn.access]::INFO --> 127.0.0.1:51025 - "PATCH /api/v1/images/i/0cfb868d-402d-409b-bfe7-31dc5b29a405.png HTTP/1.1" 200
[2023-08-10 14:01:43,921]::[uvicorn.access]::INFO --> 127.0.0.1:51026 - "PATCH /api/v1/images/i/eb759e83-e9f8-4c37-8f86-62493f86d277.png HTTP/1.1" 200
Generating:   0%|                                                                                | 0/1 [00:00<?, ?it/s]You have disabled the safety checker for <class 'diffusers.pipelines.stable_diffusion.pipeline_stable_diffusion_img2img.StableDiffusionImg2ImgPipeline'> by passing `safety_checker=None`. Ensure that you abide to the conditions of the Stable Diffusion license and do not expose unfiltered results in services or applications open to the public. Both the diffusers team and Hugging Face strongly recommend to keep the safety filter enabled in all public facing circumstances, disabling it only for use-cases that involve analyzing network behavior or auditing its results. For more information, please have a look at https://github.com/huggingface/diffusers/pull/254 .
Generating:   0%|                                                                                | 0/1 [00:00<?, ?it/s]
[2023-08-10 14:01:47,490]::[InvokeAI]::ERROR --> Traceback (most recent call last):
  File "/Applications/InvokeAI/.venv/lib/python3.9/site-packages/invokeai/app/services/processor.py", line 90, in __process
    outputs = invocation.invoke(
  File "/Applications/InvokeAI/.venv/lib/python3.9/site-packages/invokeai/app/invocations/generate.py", line 236, in invoke
    generator_output = next(outputs)
  File "/Applications/InvokeAI/.venv/lib/python3.9/site-packages/invokeai/backend/generator/base.py", line 144, in generate
    results = generator.generate(
  File "/Applications/InvokeAI/.venv/lib/python3.9/site-packages/invokeai/backend/generator/base.py", line 328, in generate
    image = make_image(x_T, seed)
  File "/Applications/InvokeAI/.venv/lib/python3.9/site-packages/invokeai/backend/generator/inpaint.py", line 292, in make_image
    pipeline_output = pipeline.inpaint_from_embeddings(
  File "/Applications/InvokeAI/.venv/lib/python3.9/site-packages/invokeai/backend/stable_diffusion/diffusers_pipeline.py", line 826, in inpaint_from_embeddings
    init_image_latents = self.non_noised_latents_from_image(init_image, device=device, dtype=latents_dtype)
  File "/Applications/InvokeAI/.venv/lib/python3.9/site-packages/invokeai/backend/stable_diffusion/diffusers_pipeline.py", line 886, in non_noised_latents_from_image
    init_latent_dist = self.vae.encode(init_image).latent_dist
  File "/Applications/InvokeAI/.venv/lib/python3.9/site-packages/diffusers/utils/accelerate_utils.py", line 46, in wrapper
    return method(self, *args, **kwargs)
  File "/Applications/InvokeAI/.venv/lib/python3.9/site-packages/diffusers/models/autoencoder_kl.py", line 242, in encode
    h = self.encoder(x)
  File "/Applications/InvokeAI/.venv/lib/python3.9/site-packages/torch/nn/modules/module.py", line 1501, in _call_impl
    return forward_call(*args, **kwargs)
  File "/Applications/InvokeAI/.venv/lib/python3.9/site-packages/diffusers/models/vae.py", line 110, in forward
    sample = self.conv_in(sample)
  File "/Applications/InvokeAI/.venv/lib/python3.9/site-packages/torch/nn/modules/module.py", line 1501, in _call_impl
    return forward_call(*args, **kwargs)
  File "/Applications/InvokeAI/.venv/lib/python3.9/site-packages/torch/nn/modules/conv.py", line 463, in forward
    return self._conv_forward(input, self.weight, self.bias)
  File "/Applications/InvokeAI/.venv/lib/python3.9/site-packages/torch/nn/modules/conv.py", line 459, in _conv_forward
    return F.conv2d(input, weight, bias, self.stride,
RuntimeError: Input type (c10::Half) and bias type (float) should be the same

[2023-08-10 14:01:47,492]::[InvokeAI]::ERROR --> Error while invoking:
Input type (c10::Half) and bias type (float) should be the same

with new update sdxl base model, stopped working for me. even after re-adding model. so i dont know, i just dont wanna deal with this anymore.

@dannyvfilms @etha302 try using the default VAE - for inpainting if you see that error. There's a fix coming in 3.0.2 for it

Closing this as it has been addressed in 3.1
For anyone seeing this, if you're still experiencing the issue, try clearing your /models/.cache folder and restarting Invoke.

I also encountered this problem. After a long investigation, I found out that the problem was caused by changing the version of transformers from 4.31.0 to 4.25.0 and changing the version of timm from 0.6.13 to 0.4.12. After I restored the versions of transformers and timm to the versions required by the invokeai project (that is, versions 4.31.0 and 0.6.13), the problem was solved.

Using 3.4.0post2, I have this problem currently using the RevAnimated 1.2.2 model.
Looks like I have:
transformers-4.35.2
timm-0.6.13
How do I get the older versions of these to see if @zhangwenhao666 solution works for me?

authors: BakonGuy Capnphil Millu Quildar dannyvfilms egoegoegoegoego etha302 lstein marpstar nbs nelsonre soundtrackgeek zhangwenhao666

repo: invoke-ai/InvokeAI


text:
Improved working directory and import management

This pull request introduces the following improvements:
Added

Code to get the current working directory.
Code to get the expected working directory based on the location of invokeai_configure.py file.
Logic to switch to the expected working directory if it differs from the current one and to exit gracefully if an error occurs.

Changed

The Imports to follow PEP 8 style guide more closely.
The imports from the local invokeai package to use absolute paths.

Thank you for the contribution. Good call on replacing relative paths with package imports.
Could you please provide some context on what is being solved by the working directory change? What is the "expected" directory here?
The current expectation is that the config interface should work irrespective of the current working directory - is that breaking for you in some way?
Thank you!

@RichKMLS - Can you share your thoughts on the above inquiries?

This PR seems to be inactive. There is an outstanding question with regard to the purpose of this change. @RichKMLS can you respond?

Closing this PR as inactive

source: gharchive/pull-request

authors: Millu ebr hipsterusername lstein originates

license_type: permissive

license_source: github-api


text:
Norton Antivirus thinks Invoke is evil

The launcher is as welcome as an outhouse breeze with Norton on Windows. Not only does the executable itself get detected as spyware and removed (twice), but each time an internal process is launched it also gets detected as spyware and automatically cancelled. While exempting the main launcher works, eventually!, because it uses internal install processes in different temporary directories the only way to begin the installation proper is to disable Norton (both the antivirus and the firewall).
By comparison, the current install script also triggers Norton at each step but passes muster after a scan. This may indicate that Norton will leave everything in peace once a digital signature is available for the launcher executable, but I wonder whether this will be sufficient to allow the system to ignore sub-processes unless these are signed as well.
Norton blows its own wind more than other security packages but is unlikely to be the only trigger-happy antivirus software in regular use. Norton itself is also available for Mac.

The Windows launcher executables are signed. Some users reported that Windows Defender complained about it for a couple days anyways then decided it's OK. I'm not sure what needs to or can happen to convince Norton it's not bad juju.

We expect the issue to be resolved as of v1.1.0a1. Is Norton happy with this version?

Like a baby's breath!

Windows Defender is still reporting this as a problem.

Latest release appears to have solved this in Win, too. Thanks!

source: gharchive/issue

authors: iwr-redmond jintoku psychedelicious

repo: invoke-ai/launcher


text:
🛑 Bitwage API (Sandbox) is down

In 8a38ca0, Bitwage API (Sandbox) (https://api.sandbox.bitwage.com) was down:

HTTP code: 403
Response time: 82 ms

Resolved: Bitwage API (Sandbox) is back up in b508ba7 after 6 minutes.

license: MIT


text:
🛑 Bitwage API (Sandbox) is down

In 133fc40, Bitwage API (Sandbox) (https://api.sandbox.bitwage.com) was down:

HTTP code: 403
Response time: 155 ms

Resolved: Bitwage API (Sandbox) is back up in 0fa0cba after 26 minutes.


text:
🛑 Bitwage API (Sandbox) is down

In cc3f202, Bitwage API (Sandbox) (https://api.sandbox.bitwage.com) was down:

HTTP code: 403
Response time: 115 ms

Resolved: Bitwage API (Sandbox) is back up in 6e2de43 after 36 minutes.


text:
🛑 Bitwage API (Sandbox) is down

In 06fe403, Bitwage API (Sandbox) (https://api.sandbox.bitwage.com) was down:

HTTP code: 403
Response time: 269 ms

Resolved: Bitwage API (Sandbox) is back up in cfda63d after 47 minutes.


text:
🛑 Bitwage API (Sandbox) is down

In c94bcbf, Bitwage API (Sandbox) (https://api.sandbox.bitwage.com) was down:

HTTP code: 403
Response time: 265 ms

Resolved: Bitwage API (Sandbox) is back up in ef8714f after 1 hour, 5 minutes.


text:
Complete multi-page stylesheet

The multi-page stylesheet currently doesn't generate a front page.

Done as of 676f2db111bbf409f3e4c02134023dfd98c91c63.

license: ISC


text:
Update anelhut from 1.0.13. to 1.0.15

1.0.15
(dan1-de) Bugfix for new jscontroller 5: https://github.com/dan1-de/ioBroker.anelhut/issues/35
1.0.14
(dan1-de) Added new Logs messages for Relais Switch Command in Debug Mode

1.0.15 created 13.08.2023 (today)
New releases MUST be available at lastest for at least 5 days and have some users there. Exceptions accure if this is a very urgend hotfix.
In addition you release has several issues whiuch must be fixed:

[ ] [E140] width and height of logo are not equal

[ ] standard github testing is not functional or did not report success
Every release is required to pass at least minimum standard github testing. This is not the case here. Please update testing and retrigger a (hopefully) successful run.
As node 14 is end of life and will no longer be supported by js-controller 5.x, consider removing node 14.x tests from matrix id still present.
Tests for node 16 is mandatory unless you require node 18 and higher.
Tests for node 18 is mandatory as node 18 is the recommended node version for ioBroker. Node 16 will be eol and deprected Q3/2023.
Consider adding node 20 tests unless you already know incompatibilities.
So the recommended testmatrix is [16.x, 18.x, 20.x],

The following issues can be fixed easyly so I would aks to fix them imiidiatly too. If this is not appropiate, please fix until next release:
❗ [E801] No repository about text found. Please go to "https://github.com/dan1-de/ioBroker.anelhut", press the settings button beside the about title and add the description.
❗ [E802] No topics found in the repository. Please go to "https://github.com/dan1-de/ioBroker.anelhut", press the settings button beside the about title and add some topics.
❗ [E605] No actual year found in copyright. Please add "Copyright (c) 2023 dan1-de dan1-de@gmx.de" at the end of README.md
❗ [E701] No actual year found in LICENSE. Please add "Copyright (c) 2023 dan1-de dan1-de@gmx.de" at the start of LICENSE
I will check those errors adn come back if something must be fixed by you. Adaptions to repository entry will be done by me.
❗ [E405] Icon must be in the following path: https://raw.githubusercontent.com/dan1-de/ioBroker.anelhut/main/
❗ [E407] Meta URL (latest) must be equal to https://raw.githubusercontent.com/dan1-de/ioBroker.anelhut/main/io-package.json
❗ [E426] Icon (stable) must be in the following path: https://raw.githubusercontent.com/dan1-de/ioBroker.anelhut/main/
❗ [E428] Meta URL (stable) must be equal to https://raw.githubusercontent.com/dan1-de/ioBroker.anelhut/main/io-package.json
All other issues reported by adapter checker should be reviewed carefully and fixed for the next release if possible.
If you have any concerns or need help, please let us know. Feel free to ping me or Apollon77 be mentionen us in a comment.

RE-CHECK!

RE-CHECK!

The path errors are most likely errors at existing repo entries. I will check and fix.
Admin5 ui is a warning and can be ignored. If possible chevk whether ui still works with admin 6
You may remove common.title but its not required. Its only a warning. Entry is now ignored by admin. Its replaced by common.titleLang which seems to exist already. TitleLang is multi lingual while title was english only.
I ll give some infos related to testing or provide a pr for you. I'm on mobile now, so please wait a little bit until i can use pc.
Rhanks for fixing all other issues.

RE-CHECK!

The path errors are most likely errors at existing repo entries. I will check and fix.
Admin5 ui is a warning and can be ignored. If possible chevk whether ui still works with admin 6
You may remove common.title but its not required. Its only a warning. Entry is now ignored by admin. Its replaced by common.titleLang which seems to exist already. TitleLang is multi lingual while title was english only.
I ll give some infos related to testing or provide a pr for you. I'm on mobile now, so please wait a little bit until i can use pc.
Rhanks for fixing all other issues.

@dan1-de
All issues reported by adapter checker are fixed now or can be ignored.
Please respond to PR for testing to finalize this too

RE-CHECK!

Hi @mcm1957
thanks for your PR. Looks good now. Can we integrate the version 1.0.15 now into stable ?


text:
MQTT Client Mode

In order to use an external MQTT server I want set up as a MQTT client, which published and subscribes (like MQTT  Adapter).
How can I do this?

This is not possible.
The Adapter has its own MQTT Server, there is no need for an external Server.
Why would you do this? It make just no sense for me at the moment because this would be a big issue with subscribtions...

This is not possible.
The Adapter has its own MQTT Server, there is no need for an external Server.
Why would you do this? It make just no sense for me at the moment because this would be a big issue with subscribtions...

I have to use an external MQTT Server in order to distribute the load (one server for each - MQTT and ioBroker) and to have a more reliable MQTT Server for the IoT devices. If ioBroker (in Raspberry Pi in my case) does not work, the MQTT devices can still connect to the MQTT Server and e.g. I can switch the light.

I have to use an external MQTT Server in order to distribute the load (one server for each - MQTT and ioBroker) and to have a more reliable MQTT Server for the IoT devices. If ioBroker (in Raspberry Pi in my case) does not work, the MQTT devices can still connect to the MQTT Server and e.g. I can switch the light.

Ok, thats fine.
But than you dont need this adapter, just use the MQTT Server you want and install the MQTT Server/Client as Client in ioBroker to publisch/subscribe to your topics.
Why you want to use the Sonoff Adapter? The use ist to simplify the MQTT handling, what you want is already done by the MQTT Adapter.

Ok, thats fine.
But than you dont need this adapter, just use the MQTT Server you want and install the MQTT Server/Client as Client in ioBroker to publisch/subscribe to your topics.
Why you want to use the Sonoff Adapter? The use ist to simplify the MQTT handling, what you want is already done by the MQTT Adapter.

@Befrish please close the Issue, because this can not be implemented.
If you have to use an external MQTT Server, than simply setup Tasmota to use this Server.
Than, if you need data in ioBroker, install MQTT Client and subscribe to the topics you need. Simple as that.

authors: Befrish anwa


text:
Saving connection Weights

I have two sheets later being CFSheet with CFprojection . Now what should I do if I want to save the weights into an array or file after few run or at the end ?

I don't think we ever implemented general-purpose weight export code, but you can examine the .cfs attribute of your CFProjection to see the array of ConnectionFields, and then look at the .weights attribute of each CF, exporting it from there however you see fit.

Unless you mean saving them into a file for the purposes of restoring them later (rather than analyzing them), in which case you can use save_snapshot.

Well I tried to save lateral weights of Lissom using
topo.sim["<sheet>"].projections()["LateralExcitatory"].cfs[1,1]
But the problem here is it gives me the cropped weights but I need the whole matrix with extras padded with zero ! I can see them in GUI using connections->Lateralexcitatotry->printing particular weights to terminal.

IIRC this should give you what you want:
topo.sim["<sheet>"].projections()["LateralExcitatory"].view(x, y, situated=True).data

Thanks for your reply .It seems view option isn't available with Resizable CF,
Checked options with dir(topo.sim["<sheet>"].projections()["LateralExcitatory"])

authors: Hima-Mehta jbednar philippjfr

repo: ioam/topographica

license_source: bigquery


text:
Update Nebula intro text

The Nebula version has intro text, which should have two changes:

Automatically minimise the message in the advanced view
Change the text to:

"This gene analysis tool enables you to examine any gene in your genome and identify variants that may have clinical significance.
To get started, enter a gene name (e.g. BRCA2) into the search field in the navigation bar. You can also click on the “Gene panel” button to the right to examine multiple genes at once. In the panel on the left, you will then see a list of all genes that you searched for. Click on a gene to examine it.
This will bring up a 'Variants' panel. It shows the genetic variants that you have in the selected gene. Different types of variants are represented using icons of different shapes and colors. A legend with explanations is located in the left bottom corner. Click on a variant icon to open the 'Variant' panel with more information on the variant. When the gene analysis tool detects important variants, they are shown in a list of variants on the left."

Looks fixed


text:
Added ability to unicast the WOL packet. Needed if sender and TV are on different subnets.

In some cases (like mine) where the issuing device and TV are on different subnets/vlans, for the routing of the packet to take place, it must be given the destination IP address. The library that is used allows such configuration so it was pretty easy.
Tested on OLED65C45LA.DEUQLJP and Tp Link Omada network stack.

Thanks
Will check / merge / relese the nex days.

v2.4.0 should be available at latest repository tomorrow.
Please test the version adn let me now (best at forum - https://forum.iobroker.net/topic/68724/test-adapter-lgtv-v2-3-x ) if everythiung is working as expected.
THANKS for you support and PR.

I think I will follow up with one more, to separate IP address setting for WOL. From my further testing, broadcast based on the unicast IP address is subject to the switch ARP table cache. Once the entry is gone, it will no longer forward to a specific port. In that cases the subnet-directed broadcast may do the trick.

Youre welcome with any improvement / fix.
THANKS for spending your time an d knowlegde.


text:
Create LICENSE.txt

Add Apache License v2 as in https://github.com/DEVSENSE/Phalanger
Hope this is correct.

Thanks for contributing!

repo: iolevel/peachpie-concept


text:
WKSuspendInBackground=false breaks IndexedDB

Environment:

iPhone 7, iOS 13.1.2
cordova: 9.0.0
cordova-ios: 5.0.1

I updated ionic-webview from 4.0.1 to 4.1.2.
If I suspend the app for 30 seconds (or more) with this version and the WKSuspendInBackground-flag set to false, the database will not work anymore.
It just disappears. This can be reproduced at any time.
Reloading the WebView does not help. The whole app has to be restarted.

Screenshot of Safaris Device Inspector before suspend:
(Indizierte Datenbanken := IndexedDB)

After suspend:

Hey, we are experiencing the same issue as well in one of our applications. Removed the property in config.xml and the app is now working as it used to.

Thanks for the suggestion. That is consistent with my experience.
I have migrated the data of my users to SQLite.
This has proven to be very stable.
The only downside was that the app size grew by about 3 megabytes just to integrate the plugin.
If someone reads this: avoid using IndexedDB.
I'm closing this issue.

authors: kolbasa samunit

repo: ionic-team/cordova-plugin-ionic-webview


text:
Error thrown when generating new page in Ionic 3

Ionic version:  (check one with "x")
[ ] 1.x (For Ionic 1.x issues, please use https://github.com/ionic-team/ionic-v1)
[ ] 2.x
[x ] 3.x
I'm submitting a ...  (check one with "x")
[ x] bug report
[ ] feature request
[ ] support request => Please do not submit support requests here, use one of these channels: https://forum.ionicframework.com/ or http://ionicworldwide.herokuapp.com/
Current behavior:
Currently, when running ionic generate page [page name], the automatically generated .module.ts file imports IonicModule, which throws the error Property 'forChild' does not exist on type 'typeof IonicModule`.
Expected behavior:
The module that should be imported is IonicPageModule, which does not throw an error.
Steps to reproduce:
Run `ionic generate page [page name] and navigate to the module file that is generated.
-->
Related code:
import { NgModule } from '@angular/core';
import { IonicModule } from 'ionic-angular';
import { DailyNotesPage } from './daily-notes';

@NgModule({
  declarations: [
    DailyNotesPage,
  ],
  imports: [
    IonicModule.forChild(DailyNotesPage), // error thrown here, should be IonicPageModule
  ],
  exports: [
    DailyNotesPage
  ]
})
export class DailyNotesPageModule {}

global packages:

    @ionic/cli-utils : 1.3.0
    Ionic CLI        : 3.3.0

local packages:

    @ionic/app-scripts              : 1.3.0
    @ionic/cli-plugin-ionic-angular : 1.3.0
    Ionic Framework                 : ionic-angular 3.0.1

System:

    Node       : v6.10.0
    OS         : Windows 10
    Xcode      : not installed
    ios-deploy : not installed
    ios-sim    : not installed

@jordanpurinton update your app-scripts to 1.3.7.
This problem is fixed a long time ago :)

@danielsogl Oh dang, really? I must not have the latest version of Ionic, then or something.

Closing this issue as I can confirm this has been fixed.

authors: danielsogl jgw96 jordanpurinton

repo: ionic-team/ionic


text:
Ionic4.alpha2:  the avatar and button in the item-sliding will make the first rendering of the page very slow.

Ionic version:  (check one with "x")
(For Ionic 1.x issues, please use https://github.com/ionic-team/ionic-v1)
[ ] 2.x
[ ] 3.x
[x] 4.x
I'm submitting a ...  (check one with "x")
[x] bug report
[ ] feature request
Current behavior:
The ion-avatar and ion-button in the ion-item-sliding will make the first rendering of the page very slow(about 4-5 minutes to render).

Expected behavior:
It should render immediately.
Steps to reproduce:
use the standard tabs demo.
Related code:
home.page.html:
<ion-content padding>
  <ion-list>
    <ion-item-group>
      <ion-item-divider>Ha</ion-item-divider>
      <ion-item-sliding>
        <ion-item>
          <ion-avatar><img src="/assets/icon/favicon.png"/></ion-avatar>
          <ion-label>Tomy</ion-label>
          <ion-button slot="end">
            <ion-icon slot="icon-only" name="mail"></ion-icon>
          </ion-button>
        </ion-item>
        <ion-item-options>
          <ion-item-option>
            <ion-icon slot="icon-only" name="arrow-up"></ion-icon>
          </ion-item-option>
        </ion-item-options>
      </ion-item-sliding>
    </ion-item-group>
  </ion-list>
</ion-content>

Other information:
Ionic info: (run ionic info from a terminal/cmd prompt and paste output below):
   @ionic/cli-utils  : 2.0.0-rc.5
   ionic (Ionic CLI) : 4.0.0-rc.5

local packages:

   @angular-devkit/core       : 0.5.7
   @angular-devkit/schematics : 0.5.7
   @angular/cli               : 6.0.0-rc.6
   @ionic/schematics-angular  : 1.0.0-rc.5
   Ionic Framework            : @ionic/angular 4.0.0-alpha.2

System:

   NodeJS : v8.11.1
   npm    : 5.6.0
   OS     : Linux 4.15

I've found it's fast if not refresh from this home tab page after code changed.

Thanks for the issue! Are you still seeing this in latest (4.0.0-beta.13)?

authors: brandyscarney snowyu


text:
bug: Modal backdrop click prevented by .modal-shadow element (mode: 'ios')

Bug Report
Ionic version:
[x] 5.x
Current behavior:
When using a modal with mode: 'ios', the .modal-shadow element prevents clicking the backdrop to dismiss the modal
Expected behavior:
The backdrop should be clickable to dismiss the modal.
Demo code:
https://stackblitz.com/edit/ionic-4-angular-8-start-template-ejcn8f
Ionic info:
Ionic:

   Ionic CLI                     : 6.9.3 (/usr/local/lib/node_modules/@ionic/cli)
   Ionic Framework               : @ionic/angular 5.1.1
   @angular-devkit/build-angular : 0.803.26
   @angular-devkit/schematics    : 9.0.7
   @angular/cli                  : 8.3.25
   @ionic/angular-toolkit        : 2.2.0

Cordova:

   Cordova CLI       : 9.0.0 (cordova-lib@9.0.1)
   Cordova Platforms : android 8.1.0, ios 5.1.1
   Cordova Plugins   : cordova-plugin-ionic-keyboard 2.2.0, cordova-plugin-ionic-webview 5.0.0, (and 23 other plugins)

Utility:

   cordova-res                          : not installed
   native-run (update available: 1.0.0) : 0.2.3

System:

   ios-sim : 8.0.2
   NodeJS  : v12.16.0 (/usr/local/Cellar/node@12/12.16.0/bin/node)
   npm     : 6.14.5
   OS      : macOS Catalina
   Xcode   : Xcode 11.5 Build version 11E608c

@hoi4
Ion-modal component should be used with full height to prevent any further issues.

Thanks for the issue. I am going to close this as this is not a bug in Ionic Framework.
To get this to work, you can add the following to your global CSS:
ion-modal .modal-shadow {
  pointer-events: none;
}

Only out of interest: Why was this behaviour changed? I upgraded from version 5.0.1 to 5.1.1 and before the upgrade, this css was not necessary. 🤔

The .modal-shadow is a new div we added to better support the card-style modal.

authors: hoi4 liamdebeasi roman-rr


text:
fix(tab-bar): hide on keyboard events

fixes #16419
Short description of what this resolves:
Changes proposed in this pull request:

Ionic Version:
Fixes: #

display: flex;
justify-content: flex-end!important;
position: absolute;
width: 100vw;
solves the problem

authors: WeslleyDeSouza manucorporat


text:
Project loading failed

We have written the needed data into you
Issue Type: Bug
f# projects wont load. I am using Remote-SSH. All files say "Not in a F# project"
Extension version: 5.7.1
VS Code version: Code 1.60.0 (e7d7e9a9348e6a8cc8c03f877d39cb72e5dfb1ff, 2021-09-01T10:41:52.311Z)
OS version: Windows_NT x64 10.0.19043
Restricted Mode: No

System Info
A/B Experiments
</details>

<!-- generated by issue reporter -->r clipboard because it was too large to send. Please paste.

Please try the latest version of Ionide, check Ionide's solution explorer on the activity bar and check logs there.
I'll reopen the issue when more details are provided.

authors: Krzysztof-Cieslak jaylenka

repo: ionide/ionide-vscode-fsharp


text:
Invalid or corrupt jarfile ios-server-standalone-0.6.6-SNAPSHOT.jar

Hi,
I am new in iOS native app automation  and trying to automate app using "iOS driver".I am getting an error when tried to run 'ios-server-standalone-0.6.6-SNAPSHOT.jar' from terminal.I have performed following steps

Download  0.6.6-SNAPSHOT from http://ios-driver.github.io/ios-driver/
Download  'InternationalMountains app' from http://ios-driver.github.io/ios-driver/?page=setup
Make new folder 'Test' on desktop
Add files (.jar and .app) into 'Test' folder
Open terminal
Type $java -jar ios-server-0.6.6-SNAPSHOT.jar -aut Mountains.app

Error: It shows an error 'Invalid or corrupt jarfile ios-server-standalone-0.6.6-SNAPSHOT.jar'
I am following 'http://ios-driver.github.io/ios-driver/?page=setup' for setup
If anyone please help me to solve this. It's urgent.Thanks in advance....

Hi,
it's 14 May 2017, and the issue still persists !!
any other alternative please?
Thanks in advance

authors: GunjanRanparia fabytta

repo: ios-driver/ios-driver


text:
Return actual types instead of bson::Documents from database queries

Write our own DTOs.
Then we can use the following things:

[ ] serde_bytes
[ ] Internal tagging for variants

Closed by #119

authors: Alexandcoats grtlr

repo: iotaledger/inx-chronicle


text:
🛑 备用KMS激活服务器 01 is down

In bfca0e0, 备用KMS激活服务器 01 (s11.ikms.eu.org) was down:

HTTP code: 0
Response time: 0 ms

Resolved: 备用KMS激活服务器 01 is back up in d03d4b7 after 11 minutes.

repo: iougemini/ikms-uptime


text:
Define chain ID format for Cosmos Hub

Apparently after hard forks the ID of the Cosmos Hub blockchain changes. See eg https://github.com/cosmos/cosmos-sdk/wiki/Cosmos-Hub-1-Upgrade
This poses a problem for us in that keypairs are registered in combination with a chain ID and the keypair-chainID combination is assumed to be static. Possible solutions include:

Do nothing and require users to reregister their keypair with the new chain ID.
Provide tools to aid users in this kind of reregistration.
Define a static chain ID for Cosmos Hub and handle the change outside the IOV blockchain.
Revisit our entire chain ID specification.

@willclarktech We should support Cosmos ecosystem (any chains on Cosmos), not only the Hubl

authors: annatorok willclarktech

repo: iov-one/iov-core


text:
Update weave to 0.25.1

Not yet released. See https://github.com/iov-one/weave/milestone/9

Waiting on v0.25.1 release to Docker Hub.


text:
[Help] Get current Unix timestamp

Is there any way to get the current Unix timestamp like date +%s%N? I tried to use nsecs, but the returned values are different from the Unix timestamp values. I do not want to use system because of its overhead.
Code:
BEGIN
{
	system("date +%s\n", "%s%N");
	printf("%d\n", nsecs);
	printf("%ld\n", nsecs);
	printf("%lld\n", nsecs);
	printf("%llu\n", nsecs);
}

# bpftrace -c 'bash run-test.sh' read.bt
Attaching 5 probes...
1553818092079803233
...
-857500477
19313610430715
19313610431634
19313610432555

There's the time() builtin, which prints an strftime() code, but it's resolution is seconds.
What's the use case? It might be possible to dig things out of the kernel to map nsecs back to %s%N, but maybe there's an easier way to solve the problem.

@brendangregg thanks for the reply, I am measuring the impact of the clone and execve syscalls, but also I need the execve exit timestamp to serve as the baseline timestamp to calculate the impact of others traces involving JVM profiling with a JVMTI Agent.
This is an output using the system(date +%s%N).
Attaching 5 probes...
1553818672706532132
[1553818672708558753] JVMTI started
[1553818672708590207] VMTrace started
[1553818672709231107] Dynamic code generated: flush_icache_stub
[1553818672709247816] Dynamic code generated: get_cpu_info_stub
...

Code:
tracepoint:syscalls:sys_enter_execve
{
  printf("execve: %s: ", str(args->filename));
  @start[tid] = nsecs;
}

tracepoint:syscalls:sys_exit_execve / @start[tid] /
{
  printf("%d -- %lld\n", nsecs - @start[tid], nsecs);
  delete(@start[tid]);
}

tracepoint:syscalls:sys_enter_clone
{
  @start_clone[tid] = nsecs;
}

tracepoint:syscalls:sys_exit_clone / @start_clone[tid] /
{
  printf("clone: %d\n", nsecs - @start_clone[tid]);
  delete(@start_clone[tid]);
}

Hey @brendangregg I looked at the bpftrace code and saw that the nsecs uses bpf_ktime_get_ns that is the kernel timestamp using the CLOCK_MONOTONIC and the "Unix timestamp" that I mentioned is got using CLOCK_REALTIME, the easy way to solve my problem is adopting CLOCK_MONOTONIC in my JVMTI Agent.
Thanks!!!

authors: brendangregg paulofelipefeitosa

repo: iovisor/bpftrace


text:
improve probes lookup by dropping use of regex

This PR alone won't solve the performance issues, but combined with #410 I was able to reduce startup time when looking up a large library from almost 20s to about 300ms.
Also, let's keep #526 open since there are other performance improvements we can do (for example, only expand wildcards if there's a wildcard in our probe name).

Not fully working yet. Will take a look into this again tomorrow.

I should probably point out that we won't be able to use regex in probe definitions with this PR, but I don't think that's an issue as long as we have wildcards working.

Ok, should be good to merge if there's no objections to https://github.com/iovisor/bpftrace/pull/557#issuecomment-485921116 and if the CI is green.

Not sure if we should fix this here too, but list and attach should use the same method to match and filter probes, but it is currently duplicated (and inconsistent):
https://github.com/iovisor/bpftrace/blob/master/src/list.cpp#L116-L139
https://github.com/iovisor/bpftrace/blob/master/src/bpftrace.cpp#L152
Probably not in the scope of this PR, but we should cut an issue to fix that too.

@dalehamel yes, we need to improve consistency between attaching and listing probes, but it should be worked on another PR.

This is good on my side.

yes, we need to improve consistency between attaching and listing probes, but it should be worked on another PR.

yup, I cut #565 to address that

Thanks!

Nice tests!

authors: ajor brendangregg dalehamel mmarchini


text:
feat: add viewport info util

Adds viewport info util.

looks good to me! 👍


text:
076-ipfs-docs-beta

Blog post to announce docs beta launch. Includes image directory with two embedded images.

@renrutnnej -- Can you please have a look at this blog post for review? If all goes to plan we should be able to formally launch the docs beta Tuesday or Wednesday, so getting ducks in a row. I'm not sure if I have the image linking set up correctly for this, but all else should be OK. Thank you!

+1 from me, this looks great. Excited to share it with the community ☺

authors: jessicaschilling renrutnnej

repo: ipfs/blog


text:
feat: support Accept header in @helia/verified-fetch

Let users get raw data back from CIDs that would otherwise trigger decoding as JSON or CBOR etc by specifying an Accept header.
const res = await verifiedFetch(cid, {
  headers: {
    accept: 'application/octet-stream'
  }
})
console.info(res.headers.get('accept')) // application/octet-stream

Make sure the content-type matches the accept header:
const res = await verifiedFetch(cid, {
  headers: {
    accept: 'application/vnd.ipld.raw'
  }
})
console.info(res.headers.get('accept')) // application/vnd.ipld.raw

Support multiple values, match the first one:
const res = await verifiedFetch(cid, {
  headers: {
    accept: 'application/vnd.ipld.raw, application/octet-stream, */*'
  }
})
console.info(res.headers.get('accept')) // application/vnd.ipld.raw

If they specify an Accept header we can't honour, one that doesn't match the eventual content type, or one returned by the content type parser return a 406:
const res = await verifiedFetch(cid, {
  headers: {
    accept: 'application/what-even-is-this'
  }
})
console.info(res.status) // 406

Change checklist

[x] I have performed a self-review of my own code
[x] I have made corresponding changes to the documentation if necessary (this includes comments as well)
[x] I have added tests that prove my fix is effective or that my feature works

@lidel @2color please take another look - I've added a lot more tests, support for wildcards and q-factor and also the IPLD serialized type conversions from https://specs.ipfs.tech/http-gateways/path-gateway/#accept-request-header

repo: ipfs/helia


text:
The Gateways are down

Things have gotten back to normal on the LBs but the wantlist on gateway node got out of hand. Turns out that the disk space underneath IPFS had run out, causing the daemon to wedge itself. I needed to manually delete some blocks in order to get the daemon to startup again, ran gc, and now everything's back to normal.

authors: diasdavid eefahy

repo: ipfs/infrastructure

license: mit


text:
Let gateway and API use different hosts from each other

Currently, the addon expects that the gateway and API must use the same host (default localhost). While IPFS's default behavior is indeed to bind both gateway and API to 127.0.0.1, the config supports binding each of them to a different address. The addon should ideally be correspondingly flexible, to accommodate such configurations.

Good idea!
I already re-implemented this and versions 2.x.x have separate URLs for both:

It will take some time before we release 2.x.x as a stable version, but if you like to test experimental things  you can install it from Development Channel:

https://addons.mozilla.org/en-US/firefox/addon/ipfs-gateway-redirect/versions/beta

authors: lidel sonatagreen

repo: ipfs/ipfs-firefox-addon


text:
Why shouldn't ipfs-pack be simply an ipfs command?

From the spec, I have seen lots of duplications in functionality with the vanilla ipfs, such as ipfs repo *, ipfs tar *, ...
This results in more documentations and cases to write for each of these new commands, even more documentations to describe how these differ from the default ones.
The only conceivable reason is that restructuring go-ipfs might necessarily result in breaking change, and ipfs-pack was meant to be a fresh, cleaner implementation of just for managing one repository whereas ipfs itself handles many repositories (~ npm vs npm -g) and doesn't default to filestore. But most api calls people have used are add/get/object, unaffected by these details of archive/exchange formats.
Wouldn't it be simpler to have them all be:

ipfs add -> ipfs add
ipfs tar add -> ipfs add --format [bag|warc|car|nar|tar]
ipfs-pack make -> ipfs add --nocopy --pack . or ipfs add --nocopy --format car
ipfs-pack verify -> ipfs repo verify --local
ipfs-pack ls -> ipfs repo ls --local   # implies filestore is being used
ipfs-pack gc -> ipfs repo gc --local
ipfs-pack serve -> ipfs daemon --local
ipfs get/ipfs cat detects whether the hashed content is formatted in bag/warc/car/nar/tar. ipfs get has options to write the output to be whether in bag/warc/car/nar/tar

Part of the point of ipfs-pack is to avoid copying data, and therefore it benefits tremendously from the filestore repo datastore.

--nocopy suffices instead of having to make a separate galapagos island of commands/verbs.

ipfs-pack is intended for use in certain situations where simplicity is a priority. Yes, more advanced users can use a normal go-ipfs daemon and the filestore (and do adds with --nocopy), but the point here is to make it as simple as possible.

authors: rht whyrusleeping

repo: ipfs/ipfs-pack


text:
🛑 NowBoarding (tokyo) is down

In 2597367, NowBoarding (tokyo) (https://tokyo.nowboarding.club/) was down:

HTTP code: 0
Response time: 0 ms

Resolved: NowBoarding (tokyo) is back up in 07609d7 after 5 minutes.

repo: iplanwebsites/up


text:
🛑 Invitation (og.invt.co - v1) is down

In 68d74bb, Invitation (og.invt.co - v1) (https://og.invt.co/felix.png?fontSize=%40felix&theme=light&md=1&images=https%3A%2F%2Flh3.googleusercontent.com%2Fa-%2FAOh14GjUk2VKmkWxpgWZgY0CXWRFi_k6t7f2MBSsfSxR%3Ds96-c) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Invitation (og.invt.co - v1) is back up in f88ec8d.


text:
🛑 Invitation (og.invt.co - v1) is down

In 3005708, Invitation (og.invt.co - v1) (https://og.invt.co/felix.png?fontSize=%40felix&theme=light&md=1&images=https%3A%2F%2Flh3.googleusercontent.com%2Fa-%2FAOh14GjUk2VKmkWxpgWZgY0CXWRFi_k6t7f2MBSsfSxR%3Ds96-c) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Invitation (og.invt.co - v1) is back up in 07a0d6c.


text:
Remove: ICS

Channel ID (required)
ICS.cn
Reason (required)
Other
Notes
From January 2025,ICS will cease transmisson and will be replaced by ShanghaiEye, a 15 minute English Television Magazine Program at 12:00 BJT on Dragon TV

Better say that the channel is closing rather than removing it, then.

authors: BellezaEmporium sunyuanzhe

repo: iptv-org/database

license: Unlicense


text:
UK EPG not updated today

The EPG's Last-Modified header is yesterday, not today.

Fixed.

authors: freearhey willnwhite

repo: iptv-org/epg


text:
Clear push notifications if they've been checked on another device

It appears to be possible now to clear notifications from the lock screen if they've been checked on another device using a silent push notification.
http://stackoverflow.com/questions/21986886/how-does-facebook-messenger-clear-push-notifications-from-the-lock-screen-if-you

Yep, we're planning to support content-available notifications in the future

This should be fixed.

authors: c99koder jwheare pkqk

repo: irccloud/ios


text:
Number of dims and results of reindexed AffineMap doesn't match on Vectorization

What happened?
dispatch: https://gist.github.com/jinchen62/5e2af98f9b5bfc3b55e949f964459815
error log: https://gist.github.com/jinchen62/df2038b5a43ed4680804a3d7d0647d95
The failing op dumped at https://github.com/iree-org/iree/blob/main/compiler/src/iree/compiler/Codegen/Common/GenericVectorization.cpp#L336 is

%10 = linalg.generic {indexing_maps = [affine_map<(d0, d1) -> (d0, d1)>, affine_map<(d0, d1) -> (0, d0)>], iterator_types = ["parallel", "reduction"]} ins(%extracted_slice : tensor<1x4xf32>) outs(%arg2 : tensor<1x1xf32>) attrs =  {lowering_config = #iree_codegen.lowering_config<tile_sizes = [[1, 0], [1, 0], [0, 4], [0, 0]]>} {
^bb0(%in: f32, %out: f32):
%11 = arith.addf %in, %out : f32
linalg.yield %11 : f32
} -> tensor<1x1xf32>

At the assertion failing point https://github.com/llvm/llvm-project/blob/main/mlir/lib/Dialect/Linalg/Transforms/Vectorization.cpp#L474, the map is changed from (d0, d1) -> (0, d0) to (d0) -> (0, d0) so the number of dims and results doesn't match.
Steps to reproduce your issue
Run iree-compile --iree-input-demote-i64-to-i32 --iree-hal-target-backends=llvm-cpu dispatch_1.mlir -o test.vmfb 2> dump.mlir with TOM iree.
What component(s) does this issue relate to?
No response
Version information
No response
Additional context
No response

Inlining the mlir input below. In the beginning, I thought that the (d0, d1) -> (0, d0) is generated during codegen, but it is the case. There is (d0, d1) -> (0, d0) affine_map in the codegen's input. @jinchen62 do you know how the input is generated? It would be very helpful if you can track it back to a small set of linalg ops or tosa/torch ops. The 0 should be folded away by FoldUnitExtentDimsPass at global opt level or flow level, i.e., it should be (d0, d1) -> (d0) when it goes to codegen.
hal.executable public @main_graph$async_dispatch_1 {
  hal.executable.variant public @embedded_elf_x86_64 target(<"llvm-cpu", "embedded-elf-x86_64", {cpu = "generic", cpu_features = "", data_layout = "e-m:e-p270:32:32-p271:32:32-p272:64:64-i64:64-i128:128-f80:128-n8:16:32:64-S128", native_vector_size = 16 : i64, target_triple = "x86_64-unknown-unknown-eabi-elf"}>) {
    hal.executable.export public @main_graph$async_dispatch_1_generic_9x1024_f32 ordinal(0) layout(#hal.pipeline.layout<push_constants = 2, sets = [<0, bindings = [<0, storage_buffer, ReadOnly>, <1, storage_buffer>]>]>) attributes {hal.interface.bindings = [#hal.interface.binding<0, 0>, #hal.interface.binding<0, 1>]} {
    ^bb0(%arg0: !hal.device):
      %x, %y, %z = flow.dispatch.workgroup_count_from_slice
      hal.return %x, %y, %z : index, index, index
    }
    builtin.module {
      func.func @main_graph$async_dispatch_1_generic_9x1024_f32() {
        %cst = arith.constant 0.000000e+00 : f32
        %0 = hal.interface.constant.load[0] : i32
        %1 = hal.interface.constant.load[1] : i32
        %2 = arith.index_castui %0 : i32 to index
        %3 = arith.index_castui %1 : i32 to index
        %4 = hal.interface.binding.subspan set(0) binding(0) type(storage_buffer) alignment(64) offset(%2) flags(ReadOnly) : !flow.dispatch.tensor<readonly:tensor<9x1024xf32>>
        %5 = hal.interface.binding.subspan set(0) binding(1) type(storage_buffer) alignment(64) offset(%3) : !flow.dispatch.tensor<writeonly:tensor<1x9xf32>>
        %6 = flow.dispatch.tensor.load %4, offsets = [0, 0], sizes = [9, 1024], strides = [1, 1] : !flow.dispatch.tensor<readonly:tensor<9x1024xf32>> -> tensor<9x1024xf32>
        %7 = tensor.empty() : tensor<1x9xf32>
        %8 = linalg.fill ins(%cst : f32) outs(%7 : tensor<1x9xf32>) -> tensor<1x9xf32>
        %9 = linalg.generic {indexing_maps = [affine_map<(d0, d1) -> (d0, d1)>, affine_map<(d0, d1) -> (0, d0)>], iterator_types = ["parallel", "reduction"]} ins(%6 : tensor<9x1024xf32>) outs(%8 : tensor<1x9xf32>) {
        ^bb0(%in: f32, %out: f32):
          %10 = arith.addf %in, %out : f32
          linalg.yield %10 : f32
        } -> tensor<1x9xf32>
        flow.dispatch.tensor.store %9, %5, offsets = [0, 0], sizes = [1, 9], strides = [1, 1] : tensor<1x9xf32> -> !flow.dispatch.tensor<writeonly:tensor<1x9xf32>>
        return
      }
    }
  }
}

I worked with @jinchen62 and we got a smaller repro: https://gist.github.com/hanhanW/b3652f5887b93fb8f0df6c6c39c1ef87
To repro, run iree-opt --pass-pipeline="builtin.module(util.func(iree-flow-fold-unit-extent-dims))" ~/repro.mlir.
Then you'll see affine_map<(d0, d1) -> (0, d0)> in the result.
#map2 = affine_map<(d0, d1) -> (d0, d1)>
#map8 = affine_map<(d0, d1) -> (0, d0)>
// ...
    %29 = linalg.generic {indexing_maps = [#map2, #map8], iterator_types = ["parallel", "reduction"]} ins(%collapsed_12 : tensor<9x1024xf32>) outs(%28 : tensor<?x9xf32>) {
    ^bb0(%in: f32, %out: f32):
      %35 = arith.addf %in, %out : f32
      linalg.yield %35 : f32
    } -> tensor<?x9xf32>
// ...

smaller repro: https://gist.github.com/jinchen62/91e216fb39abbb9ba4c0461346d2bb5a
command:
iree-opt --pass-pipeline="builtin.module(util.func(iree-flow-fold-unit-extent-dims))" repro.mlir
or
iree-compile --iree-hal-target-backends=llvm-cpu repro.mlir -o test.vmfb --mlir-print-ir-after-all 2> dump.mlir

@jinchen62 did you get a chance to see which op is generating the IR? The generic op looks invalid to me, like I explained in the above comment.

I think it's

%237 = torch.aten.sum.dim_IntList %235, %236, %true, %none : !torch.vtensor<[?,9,1024],f32>, !torch.list<int>, !torch.bool, !torch.none -> !torch.vtensor<[?,9,1],f32>

I'd suggest to check if there are bugs in torch -> linalg lowering, or other high level dialects -> torch lowering.

torch level repro: https://gist.github.com/jinchen62/601cfce290b81e037383fc49b604a68a
iree-compile --iree-input-demote-i64-to-i32 --iree-hal-target-backends=llvm-cpu --iree-util-zero-fill-elided-attrs repro_torch.mlir -o test.vmfb

part of dump torch repro:
After ExpandOps (memref-expand) -> After Canonicalizer (canonicalize)
https://gist.github.com/jinchen62/ae856e42b0660d0b41426e910039fb9a
@hanhanW I think with a tensor.cast op, the reduction op that you found weird should be good to compile like line381. But after Canonicalizer pass, it looks uncompilable like line817. The following is a compiled repro, it fails on the same error that we are facing without the cast op at the end. Does it make sense?
#map = affine_map<(d0) -> (d0)>
#map1 = affine_map<(d0, d1, d2) -> (d0, d1, d2)>
#map2 = affine_map<(d0, d1, d2) -> (d0, d1, 0)>
module {
  func.func @repro2(%arg0: tensor<1x9x1024xf32>) -> tensor<1x9x1xf32> {
    %cst = arith.constant dense<[false, true]> : tensor<2xi1>
    %cst_0 = arith.constant dense<1> : tensor<2xi32>
    %cst_1 = arith.constant dense<[1, -1]> : tensor<2xi32>
    %cst_2 = arith.constant 0.000000e+00 : f32
    %0 = tensor.empty() : tensor<2xi32>
    %1 = linalg.generic {indexing_maps = [#map, #map, #map, #map], iterator_types = ["parallel"]} ins(%cst, %cst_0, %cst_1 : tensor<2xi1>, tensor<2xi32>, tensor<2xi32>) outs(%0 : tensor<2xi32>) {
    ^bb0(%in: i1, %in_3: i32, %in_4: i32, %out: i32):
      %6 = arith.select %in, %in_3, %in_4 : i32
      linalg.yield %6 : i32
    } -> tensor<2xi32>
    %extracted_slice = tensor.extract_slice %1[0] [1] [1] : tensor<2xi32> to tensor<1xi32>
    %collapsed = tensor.collapse_shape %extracted_slice [] : tensor<1xi32> into tensor<i32>
    %extracted = tensor.extract %collapsed[] : tensor<i32>
    %2 = arith.index_cast %extracted : i32 to index
    %3 = tensor.empty(%2) : tensor<?x9x1xf32>
    %4 = linalg.fill ins(%cst_2 : f32) outs(%3 : tensor<?x9x1xf32>) -> tensor<?x9x1xf32>
    %5 = linalg.generic {indexing_maps = [#map1, #map2], iterator_types = ["parallel", "parallel", "reduction"]} ins(%arg0 : tensor<1x9x1024xf32>) outs(%4 : tensor<?x9x1xf32>) {
    ^bb0(%in: f32, %out: f32):
      %6 = arith.addf %in, %out : f32
      linalg.yield %6 : f32
    } -> tensor<?x9x1xf32>
    %cast = tensor.cast %5 : tensor<?x9x1xf32> to tensor<1x9x1xf32>
    return %cast : tensor<1x9x1xf32>
  }
}

I'm not convinced that the issue is tensor.cast. There are some shape inference passes/patterns in MLIR dialect, and they create tensor.cast op to spell out some static shapes. With the hint, the compiler is smart to fold the shape information into linalg op, which is reasonable to me. The patterns and passes are working at Linalg level, what I can think of is that the frontend is generating invalid ops.
I don't know why we're still triaging the issue at model level, perhaps I did not make it clear. Let me put it this way -- Instead of compiling the whole model, are you able to compile a single %237 = torch.aten.sum.dim_IntList %235, %236, %true, %none : !torch.vtensor<[?,9,1024],f32>, !torch.list<int>, !torch.bool, !torch.none -> !torch.vtensor<[?,9,1],f32> op?

I don't think it's a lowering issue. The torch.aten.sum.dim_IntList op compiles, and I traced up to the onnx->torch and didn't find a lowering bug of any onnx op.
@raikonenfnu and I think there might be an optimization bug in canonicalize pass after memref-expand. We saw the generic op with reduction dim changing from ins(%146 : tensor<?x9x1024xf32>) outs(%149 : tensor<?x?x1xf32>) to ins(%55 : tensor<1x9x1024xf32>) outs(%57 : tensor<?x9x1xf32>) with folding the tensor.cast op. We might want to see it changes to ins(%55 : tensor<?x9x1024xf32>) outs(%57 : tensor<?x9x1xf32>) or ins(%55 : tensor<1x9x1024xf32>) outs(%57 : tensor<1x9x1xf32>). The dump ir is here.

I don't think it's a lowering issue. The torch.aten.sum.dim_IntList op compiles, and I traced up to the onnx->torch and didn't find a lowering bug of any onnx op.
@raikonenfnu and I think there might be an optimization bug in canonicalize pass after memref-expand. We saw the generic op with reduction dim changing from ins(%146 : tensor<?x9x1024xf32>) outs(%149 : tensor<?x?x1xf32>) to ins(%55 : tensor<1x9x1024xf32>) outs(%57 : tensor<?x9x1xf32>) with folding the tensor.cast op. We might want to see it changes to ins(%55 : tensor<?x9x1024xf32>) outs(%57 : tensor<?x9x1xf32>) or ins(%55 : tensor<1x9x1024xf32>) outs(%57 : tensor<1x9x1xf32>). The dump ir is here.

@jinchen62 So what's the plan to fix this issue?

authors: AmosLewis hanhanW jinchen62

repo: iree-org/iree


text:
[NFC] Register tiling implementation for tensor dialect in IREE.

It forces the CPUDoubleTilingPadExpert pipeline explicitly set anchor op. Otherwise, the CodgenStrategy could tile on pad op, which is not expected. In the past, it would not tile pad op because the tiling implementation was not registered. This is an NFC to the CPU pipeline.

It is triggering some issues in experimental path (like fusing pad with its consumers). I looked into the IR dump. It unconditionally (or say greedily) tile and fuse pad into its consumer. But we probably don't want it or need some control on it. After talking to @MaheshRavishankar, I think it is part of pad fusion work. So I'm not going to push this PR forward.
(cc @ThomasRaoux @grypp )


text:
Re-enable SPIR-V linking in VulkanSPIRVTarget.cpp.

This generally increases compile time and can either improve or degrade runtime performance depending on the runtime Vulkan ICD. For example, a debug build of SwiftShader may be significantly slower with this, while an opt build of SwiftShader or a native driver may be faster. Most of the runtime effects occur at startup, as the driver is given a smaller number of (potentially) more complex shaders. Linking can also improve binary size and enable more whole program optimizations.
See https://github.com/google/iree/issues/7819

If this doesn't help then I think the archive approach (where we change the spirv flatbuffer to have multiple shader modules) may be the best route: it gives us all the benefits but appears the same to any implementation. We'd change https://github.com/google/iree/blob/b998f1f8ebcdb80aa07217a9413f8ecc63ba545e/iree/hal/vulkan/native_executable.cc to instead be archive_executable or something and have it call iree_hal_vulkan_create_shader_module for each available (the public entry points of the executable then map to entry points within one or more shader modules).

If this doesn't help then I think the archive approach (where we change the spirv flatbuffer to have multiple shader modules) may be the best route: it gives us all the benefits but appears the same to any implementation. We'd change https://github.com/google/iree/blob/b998f1f8ebcdb80aa07217a9413f8ecc63ba545e/iree/hal/vulkan/native_executable.cc to instead be archive_executable or something and have it call iree_hal_vulkan_create_shader_module for each available (the public entry points of the executable then map to entry points within one or more shader modules).

That approach seems promising.

I collected some timing on cl/414501192 (internal since that's where we originally found issues with timeouts):
All with fastbuild (not opt) on the CPU using SwiftShader. Times include both compilation and runtime - that's why I'm running benchmarks to see the impact on real device runtime performance on this PR.
Sept 22:

xla_ops/reduce without linking: 26 seconds
xla_ops/reduce with linking: 110 seconds

Today:

xla_ops/reduce without linking: 40 seconds
xla_ops/reduce with linking: 53 seconds
layers/SeparableConv2D without linking: 100 seconds
layers/SeparableConv2D with linking: 460 seconds (165 seconds with -c opt)

So that's the time for swiftshader to compile the shader modules/create pipelines at runtime? (not clear if you are talking about "compiler compile times" or "runtime compile times")
The two goals of linking things together are to reduce the tracking/overhead we have to manage and to reduce runtime driver compilation - if this makes the latter much worse then it's not really worth it for the former: this style of linking doesn't get us down to a single executable so it's gotta be a clear win to do.

So that's the time for swiftshader to compile the shader modules/create pipelines at runtime? (not clear if you are talking about "compiler compile times" or "runtime compile times")
The two goals of linking things together are to reduce the tracking/overhead we have to manage and to reduce runtime driver compilation - if this makes the latter much worse then it's not really worth it for the former: this style of linking doesn't get us down to a single executable so it's gotta be a clear win to do.

layers/SeparableConv2D is the entire Python test time, which includes extra time in the IREE compiler linking the executables and MLIR blocks together, as well as time spent at runtime in SwiftShader compiling shader modules and creating pipelines.
xla_ops/reduce I think is only runtime, as compilation happens at build time... but I'm not 100% sure

Those times are really high - reduce has just 20 functions that should be all 1-2 dispatches each O_O

Yeah... for https://github.com/google/iree/blob/main/iree/test/e2e/xla_ops/reduce.mlir, each test case takes around

Configuration
Time per test case

opt
300 milliseconds

fastbuild
2 seconds

opt + linking
500 milliseconds

fastbuild + linking
6 seconds

Would be nice to profile into SwiftShader and see where most of the time is going ¯\_(ツ)_/¯

ouch - well, maybe let's hold off on this then - I think the archive approach should be pretty easy to implement and would sidestep all of this
(I don't trust that real drivers would not have this same behavior... they shouldn't, but ... drivers)

filed https://github.com/google/iree/issues/7824

Benchmark results look to all be within the noise (though some of those Samsung phone benchmarks are really noisy...)

:P

I'd say let's not anchor too much on SwiftShader when discussing about performance. It's only meant for correctness check (and also a guarantee that we can satisfy a very constrained target environments). Nothing really more than that. :)

 :P

Gona have Pixel 6 sooon... :)

Closing as obsolete. I think the right approach here will be a flatbuffer library as detailed #7824.

authors: ScottTodd antiagainst benvanik


text:
Add support for connection pooling

See the HTTP API for reference implementation.

handled as part of 52cf743d2c5e13e86597cb480cbca158b2bb5806
copied implementation from the HTTP API.

authors: korydraughn trel


text:
Add netboot plugin

Proposed Changes
Add netboot plugin
Fixes #

Fixes https://github.com/ironcore-dev/FeDHCP/issues/127

@5kt Please remove the header from the source file and run make addlicense, then the reuse workflow will go green

repo: ironcore-dev/FeDHCP


text:
Add possibility to list loadbalancers

Summary
Add possibility to list all loadbalancers without specifying loadbalancer ID.
Motivation
Current implementation allows only to get loadbalancer with specific ID.

Not needed after merger with dpservice https://github.com/ironcore-dev/dpservice/issues/445
Functionality merged directly in dpservice repo.

repo: ironcore-dev/dpservice-go


text:
Token Control Measure Distance Counts Tokens as Difficult Terrain

The token control ruler tool counts tokens as difficult terrain, even when no tokens are selected. Is this desired behavior? Testing whether someone can cast spells or helping to envision theater of the mind is bunked because players can't use the ruler tool, but I want to be able to count corpses as difficult terrain when players are moving.
IS: Ruler is counting tokens as difficult terrain, even when no tokens are selected and the ruler is being used to assist theater of the mind
SB: Ruler tool should not count tokens as difficult terrain. Tokens are only contain a difficult terrain component for the purposes of green/yellow/red movement shading when dragging tokens, not when determining spell distance or evaluating distance for theater of the mind.

That is an issue with the Ruler, not with Enhanced Terrain Layer.
Enhanced Terrain Layer is just a library, it's up to the ruler to determine how it displays that information.

Closing this issue, cleaning up tickets.


text:
🛑 Web Pusat is down

In 0604afe, Web Pusat (https://www.bps.go.id) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Web Pusat is back up in 97b653a after 3 hours, 2 minutes.

repo: irsadarief/uptime


text:
TikTokLive.types.errors.SignatureRateLimitReached even if only starting one connection

Hi,
I'm not sure if it's a bug, but I often (pretty much always) get the following error when starting the inital connection to a live.
TikTokLive.types.errors.SignatureRateLimitReached: You have hit the rate limit for starting connections. Try again in 1551 seconds. Catch this error & access its attributes (retry_after, reset_time) for data on when you can request next.
Am I doing something wrong in my python script? I am only observing one user, my script checks until he is live, then starts client.run() then gets the livestream and on live end goes back to the loop. am I keeping old sessions active somehow?
Thanks in advance - I love this project!

How are you checking if he is live

How are you checking if he is live

I do a get on 'https://www.tiktok.com/api-live/user/room/?aid=1988&region=DE&sourceType=54&uniqueId= every minute and check the user status in the returned data. If successful I wait 60s and then do a client.run()

@PWSMarcello can you share the repo

How are you checking if he is live

I do a get on 'https://www.tiktok.com/api-live/user/room/?aid=1988&region=DE&sourceType=54&uniqueId= every minute and check the user status in the returned data. If successful I wait 60s and then do a client.run()

It is likely you are calling the connect method too frequently :)

authors: Geczy PWSMarcello isaackogan

repo: isaackogan/TikTokLive


text:
MdbxError(11)

Steps to Reproduce
The Database is failing with an MdbxError(11) as shown in the logs. This bug is hard to reproduce. Personally, i have not encountered it in production yet, others have. Sometimes it occurs after hot reloading the app several times. It seems to be an Error in the Rust part of Isar and i have no clue how to look into that myself. Maybe you can.
There is an ongoing issue at the original Isar repository:
https://github.com/isar/isar/issues/1068#issuecomment-2074245696
Here are my logs:
E/flutter (29750): [ERROR:flutter/runtime/dart_vm_initializer.cc(41)] Unhandled Exception: IsarError: Cannot open Environment: MdbxError (11): Try again

Code sample
Take the counter app, add whatever IsarSchema and open it on running the App. Then hot reload the App a couple of times. I cannot guarantee, that this will produce the Error.
void() main async {
WidgetsFlutterBinding.ensureInitialized();
final dir = await getApplicationDocumentsDirectory();
await Isar.open([schemas], directory: dir.path);
runApp(MyApp());
}

Details

Device: Samsung A53
Platform: Android 12.
Flutter version: 3.16.8
Isar version: 3.1.6

[x] I searched for similar issues already
[x] I filled the details section with the exact device model and version
[ ] I am able to provide a reproducible example

I am not sure if it helps you to reproduce this issue, but in our case we're getting this error consistently once user uses a back arrow (instead of hamburger menu icon) on Android to close the app (goes to detached state) and then taps the app again so it starts again: https://github.com/isar/isar/issues/1068#issuecomment-2119321945

I wrote a demo to reproduce this issue on an Android phone. When the app returns to the home screen while a database write operation is in progress but not yet completed, and then the app is reopened, this issue occurs.
https://github.com/linbiaojj/isar_mdbx_error_demo

I discovered that adding a delay on launch before writing or reading to give the database time to open fully resolved the issue for me. Must be a data race from within the package

Looks like I found a workaround too.
The task is to prevent the app to go to detached state (after pressing 'back').
Add this to your Home widget:
 PopScope(
        canPop: false,
        onPopInvokedWithResult: (bool didPop, Object? result) {
          if (isIos || didPop) return;

          _closeConfirmation();
        },

I use Modal popup 'Do you really wanna close the app?', and if user is pressing 'close', I call 'SystemNavigator.pop();'

Looks like I found a workaround too.
The task is to prevent the app from going to the detached state after pressing 'back.'
Add this to your Home widget:
PopScope(
   canPop: false,
   onPopInvokedWithResult: (bool didPop, Object? result) {
      if (isIos || didPop) return;

      _closeConfirmation();
   },
 child ...

I use a modal popup with the message 'Do you really want to close the app?' If the user presses 'close,' I call exit(0). Please note that SystemNavigator.pop() will have the same effect as 'back' button, so you need to use exit(0).
In this variant, the app never goes to detached state and there won't be any issues with MdbxError(11).
However, there still could be issues with existing transactions, and you can add a function to await them before exiting

@Tr736 can I ask you if you added the delay before opening the database or before the first write/read operation.
Out of curiosity what delay duration worked for you?
In my case I added a delay before the first opening of the DB of 300 ms and I am still seeing the error reported in Crashlytics.

I’ve added the delay after opening and before the first write
unfortunately this repo is pretty much dead and with the new flutter versions I’ve noticed a massive spike in cpu and memory allocations along with all the other issues we’ve experienced.
we’ve decided to pull the database from our repo, which is a lot of work :(

authors: FritzMatthaeus Tr736 linbiaojj marcotta tomekit vizakenjack

repo: isar-community/isar


text:
Test

I have done the following to reach this milestone:

[ ] Write integration tests for each page in the app. Check path, existence of content, interaction.

Approved !

repo: ishimwepati/Recipe-app