RuntimeError: No response returned 0.5.1

Bug Report
Installation Method
docker compose
Environment

Open WebUI Version: [v0.5.1]

Ollama (if applicable): [v0.5.0]

Operating System: [Ubuntu 20.04]

Browser (if applicable): [Chrome 131.0]

Confirmation:

[x] I have read and followed all the instructions provided in the README.md.
[x] I am on the latest version of both Open WebUI and Ollama.
[x] I have included the browser console logs.
[x] I have included the Docker container logs.
[x] I have provided the exact steps to reproduce the bug in the "Steps to Reproduce" section below.

Expected Behavior:
Normal website access
Actual Behavior:
Upgrade complete. Error when accessing the website.
Logs and Screenshots
Docker Container Logs:
`INFO  [open_webui.routers.ollama] get_all_models()
[GIN] 2024/12/27 - 06:10:47 | 200 |     375.641µs |       <IP_ADDRESS> | GET      "/api/tags"
ERROR:    Exception in ASGI application

Exception Group Traceback (most recent call last):
|   File "/usr/local/lib/python3.11/site-packages/starlette/_utils.py", line 87, in collapse_excgroups
|     yield
|   File "/usr/local/lib/python3.11/site-packages/starlette/middleware/base.py", line 190, in call
|     async with anyio.create_task_group() as task_group:
|   File "/usr/local/lib/python3.11/site-packages/anyio/_backends/_asyncio.py", line 815, in aexit
|     raise BaseExceptionGroup(
| ExceptionGroup: unhandled errors in a TaskGroup (1 sub-exception)
+-+---------------- 1 ----------------
| Traceback (most recent call last):
|   File "/usr/local/lib/python3.11/site-packages/uvicorn/protocols/http/httptools_impl.py", line 401, in run_asgi
|     result = await app(  # type: ignore[func-returns-value]
|              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|   File "/usr/local/lib/python3.11/site-packages/uvicorn/middleware/proxy_headers.py", line 70, in call
|     return await self.app(scope, receive, send)
|            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|   File "/usr/local/lib/python3.11/site-packages/fastapi/applications.py", line 1054, in call
|     await super().call(scope, receive, send)
|   File "/usr/local/lib/python3.11/site-packages/starlette/applications.py", line 123, in call
|     await self.middleware_stack(scope, receive, send)
|   File "/usr/local/lib/python3.11/site-packages/starlette/middleware/errors.py", line 186, in call
|     raise exc
|   File "/usr/local/lib/python3.11/site-packages/starlette/middleware/errors.py", line 164, in call
|     await self.app(scope, receive, _send)
|   File "/usr/local/lib/python3.11/site-packages/starlette/middleware/cors.py", line 85, in call
|     await self.app(scope, receive, send)
|   File "/usr/local/lib/python3.11/site-packages/starlette/middleware/base.py", line 189, in call
|     with collapse_excgroups():
|   File "/usr/local/lib/python3.11/contextlib.py", line 158, in exit
|     self.gen.throw(typ, value, traceback)
|   File "/usr/local/lib/python3.11/site-packages/starlette/_utils.py", line 93, in collapse_excgroups
|     raise exc
|   File "/usr/local/lib/python3.11/site-packages/starlette/middleware/base.py", line 191, in call
|     response = await self.dispatch_func(request, call_next)
|                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|   File "/app/backend/open_webui/main.py", line 716, in inspect_websocket
|     return await call_next(request)
|            ^^^^^^^^^^^^^^^^^^^^^^^^
|   File "/usr/local/lib/python3.11/site-packages/starlette/middleware/base.py", line 166, in call_next
|     raise RuntimeError("No response returned.")
| RuntimeError: No response returned.
+------------------------------------

During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/usr/local/lib/python3.11/site-packages/uvicorn/protocols/http/httptools_impl.py", line 401, in run_asgi
result = await app(  # type: ignore[func-returns-value]
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/local/lib/python3.11/site-packages/uvicorn/middleware/proxy_headers.py", line 70, in call
return await self.app(scope, receive, send)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/local/lib/python3.11/site-packages/fastapi/applications.py", line 1054, in call
await super().call(scope, receive, send)
File "/usr/local/lib/python3.11/site-packages/starlette/applications.py", line 123, in call
await self.middleware_stack(scope, receive, send)
File "/usr/local/lib/python3.11/site-packages/starlette/middleware/errors.py", line 186, in call
raise exc
File "/usr/local/lib/python3.11/site-packages/starlette/middleware/errors.py", line 164, in call
await self.app(scope, receive, _send)
File "/usr/local/lib/python3.11/site-packages/starlette/middleware/cors.py", line 85, in call
await self.app(scope, receive, send)
File "/usr/local/lib/python3.11/site-packages/starlette/middleware/base.py", line 189, in call
with collapse_excgroups():
File "/usr/local/lib/python3.11/contextlib.py", line 158, in exit
self.gen.throw(typ, value, traceback)
File "/usr/local/lib/python3.11/site-packages/starlette/_utils.py", line 93, in collapse_excgroups
raise exc
File "/usr/local/lib/python3.11/site-packages/starlette/middleware/base.py", line 191, in call
response = await self.dispatch_func(request, call_next)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/app/backend/open_webui/main.py", line 716, in inspect_websocket
return await call_next(request)
^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/local/lib/python3.11/site-packages/starlette/middleware/base.py", line 166, in call_next
raise RuntimeError("No response returned.")
RuntimeError: No response returned.`

It's a warning you can ignore.


[Hardware][Intel GPU]Add Initial Intel GPU(XPU) inference backend

This PR is first PR for RFC #3725
Intel is contributing both Intel CPU and Intel GPU support for vLLM. Initial PR #3634 for CPU already got merged.
This PR adds a new Intel GPU(also named XPU in pytorch context) backend to vLLM and supports the basic model inference feature, with FP16 type support.
Changes to vLLM:
Added VLLM_TARGET_DEVICE ENV to specify backend explicitly.
Added XPUExecutor, XPUWorker, XPUModelRunner to isolate XPU backend with others.
Updated TorchSDPABackend to support MHA on XPU.
Forwarded DeviceConfig to CacheEngine to avoid cuda hardcoded device memory allocation.
Leverage high performance custom ops(paged_attention_v1/2, reshape_and_cache, etc) from IPEX library to support run vLLM on Intel GPU.
Refactor kernel uts to enable for Intel GPU.
Limitations:

require oneAPI 2024.1
Only support Intel Data Center GPU, Intel Arc GPUs are not supported currently.
Only support half type, bf16, float are not supported currently.
quantization are not supported.
Verified Llama model only, haven't tested all popular models yet.
only python 3.10 supported.

BEFORE SUBMITTING, PLEASE READ THE CHECKLIST BELOW AND FILL IN THE DESCRIPTION ABOVE

 PR Checklist (Click to Expand)
Thank you for your contribution to vLLM! Before submitting the pull request, please ensure the PR meets the following criteria. This helps vLLM maintain the code quality and improve the efficiency of the review process.
PR Title and Classification
Only specific types of PRs will be reviewed. The PR title is prefixed appropriately to indicate the type of change. Please use one of the following:

[Bugfix] for bug fixes.
[CI/Build] for build or continuous integration improvements.
[Doc] for documentation fixes and improvements.
[Model] for adding a new model or improving an existing model. Model name should appear in the title.
[Frontend] For changes on the vLLM frontend (e.g., OpenAI API server, LLM class, etc.)
[Kernel] for changes affecting CUDA kernels or other compute kernels.
[Core] for changes in the core vLLM logic (e.g., LLMEngine, AsyncLLMEngine, Scheduler, etc.)
[Hardware][Vendor] for hardware-specific changes. Vendor name should appear in the prefix (e.g., [Hardware][AMD]).
[Misc] for PRs that do not fit the above categories. Please use this sparingly.

Note: If the PR spans more than one category, please include all relevant prefixes.
Code Quality
The PR need to meet the following code quality standards:

We adhere to Google Python style guide and Google C++ style guide.
Pass all linter checks. Please use format.sh to format your code.
The code need to be well-documented to ensure future contributors can easily understand the code.
Include sufficient tests to ensure the project to stay correct and robust. This includes both unit tests and integration tests.
Please add documentation to docs/source/ if the PR modifies the user-facing behaviors of vLLM. It helps vLLM user understand and utilize the new features or changes.

Notes for Large Changes
Please keep the changes as concise as possible. For major architectural changes (>500 LOC excluding kernel/data/config/test), we would expect a GitHub issue (RFC) discussing the technical design and justification. Otherwise, we will tag it with rfc-required and might not go through the PR.
What to Expect for the Reviews
The goal of the vLLM team is to be a transparent reviewing machine. We would like to make the review process transparent and efficient and make sure no contributor feel confused or frustrated. However, the vLLM team is small, so we need to prioritize some PRs over others. Here is what you can expect from the review process:

 After the PR is submitted, the PR will be assigned to a reviewer. Every reviewer will pick up the PRs based on their expertise and availability.
 After the PR is assigned, the reviewer will provide status update every 2-3 days. If the PR is not reviewed within 7 days, please feel free to ping the reviewer or the vLLM team.
 After the review, the reviewer will put an  action-required label on the PR if there are changes required. The contributor should address the comments and ping the reviewer to re-review the PR.
 Please respond to all comments within a reasonable time frame. If a comment isn't clear or you disagree with a suggestion, feel free to ask for clarification or discuss the suggestion.

Thank You
 Finally, thank you for taking the time to read these guidelines and for your interest in contributing to vLLM. Your contributions make vLLM a great tool for everyone!

Hi @WoosukKwon There will be a new IPEX release this week which contains the necessary kernels with big optimizations, this patch will be refactored to use the IPEX kernels and the code will be simplified a lot.
thanks,
-yuan

Hi @jikunshang @zhouyuan , thanks for your brilliant works. Does this PR is ready for further testing? Still only support Intel Data Center GPU? I got a Arc A770 and like to have a shot.

Hi @jikunshang @zhouyuan , thanks for your brilliant works. Does this PR is ready for further testing? Still only support Intel Data Center GPU? I got a Arc A770 and like to have a shot.

Thanks for your attention!. This patch only works on Intel Data Center GPU currently.
However, we have a backup branch with hand write sycl code version which could run on Arc A770, while the performance may not be optimal. Please take a try:)

@jikunshang Thanks for the PR and apologies for the delay in my review. I've checked that the code works pretty smoothly and the performance looks fine although I believe it has a room for improvements. 👍 In terms of functionality and performance, I think it's good enough for the initial integration. However, I have small concerns on code duplication and style. Please check out my comments.

@WoosukKwon Thanks for you review! I have address most of your comments, please review it again.

@jikunshang @zhouyuan Thanks for updating the PR and apologies for all the delays in review. I think the PR is in a pretty good shape now. Just left some (mostly minor) comments.

@WoosukKwon  Got time to review again? thanks!

Hi @WoosukKwon, this pr is ready to review again, thanks!

@jikunshang Thanks again for the PR. Also, sorry again for the delays in the review process. We are really happy to have the intel XPU backend!
I'm generally good with the PR, but added minor comments, mostly questions. Please check them out.

Thanks for your comments! I just did some rebase and refactor to fit recently custom operators code change.

@jikunshang Just merged the PR! Thanks for your patience and all hard work despite the delays in the review process. This is amazing!
BTW, I found that CI/CD was not set up properly. Could you please take a look?

@jikunshang Just merged the PR! Thanks for your patience and all hard work despite the delays in the review process. This is amazing!
BTW, I found that CI/CD was not set up properly. Could you please take a look?

@WoosukKwon Appreciate a lot for your patience and effort! I will take a look about CI issue.

@WoosukKwon thanks a lot! Will try to adding more optimizations on Intel PVC/ARC
also CC @atanikan @jgong5 @ganyi1996ppo for their awareness
thanks, -yuan


Refactoring types and invariants

I'm opening this issue to explore how we can encode some existing panic/assert invariants in static typing. This is one design I'm considering:
pub enum ImageContent {
    Rgba {
        palette: Option<ColorPalette>,
        cels: CelsData<pixel::Rgba>,
        tilesets: TilesetsById<pixel::Rgba>,
    },
    Grayscale {
        palette: Option<ColorPalette>,
        cels: CelsData<pixel::Grayscale>,
        tilesets: TilesetsById<pixel::Grayscale>,
    },
    Indexed {
        palette: ColorPalette,
        transparent_color_index: u8,
        cels: CelsData<pixel::Indexed>,
        tilesets: TilesetsById<pixel::Indexed>,
    },
}

Any invariant behavior around the pixel format (a palette must be present, etc) would be encoded in this single ImageContent enum. This would replace the PixelFormat and Pixels enums, and additionally contain the dependent data. Cels and Tilesets would become generic over a pixel type.
Cels and Tilesets also contain a lot of non-pixel metadata. Making these types generic would make it harder to work with all of the non-image content. I also considered a design where the pixel data would live in a separate map from the non-pixel metadata:
// Only these pixel tables are generic.
// The rest of the data remains non-generic, in the existing top-level maps.
// This would prevent the generic types from "leaking" into other code that touches cels or tilesets.
pub struct CelPixelsById<T>(HashMap<CelId, Vec<T>>);
pub struct TilesetPixelsById<T>(HashMap<TilesetId, Vec<T>>);

pub enum ImagePixelContent {
    Rgba {
        palette: Option<ColorPalette>,
        cels: CelPixelsById<pixel::Rgba>,
        tilesets: TilesetPixelsById<pixel::Rgba>,
    },
    // etc
}

This indirection would allow users to use Tilesets and Cels from multiple files without regard for their pixel format.

Hm, I haven't found a good time to fully wrap my head around how the tileset stuff fits in.
But I have a few quick thoughts on the handling of indexed data.

All indexed Pixel data uses the same palette, so they can all get an Rc<Palette> so we don't need to deal with lifetime parameters.
The transparent pixel index would be part of the palette.
The palette would always be of size 256, and the unused slots would all be transparent. That way we don't have to worry about out of bounds accesses.
We'd still validate that all indices are in range when we convert the data read from the file into our pixel data types. That conversion/validation must obviously happen after we have read the palette from the file.

The validator should still check for out of bounds indices. But if it has a bug there won't be a crash, just some transparent pixels.
The one ugly spot would be the handling of background-layer or not. I think that info shouldn't be moved into the cel, so it must be handled somewhere else.


Set up initial project structure

Includes setting up main classes and the stage for other features to build from

Excellent, this is a good starting point

issue approved


Change sshd port from 22 to 2222 in README.md

According to https://github.com/devcontainers/features/blob/e90f4f9e0a327466254f3f1693fbe75aaa2a862f/src/sshd/install.sh#L12 the default port is 2222 and not 22 as previously documented. Forwarding port 22 does not in fact work.

@samruddhikhandale Sorry I didn't catch it at first😅
NOTES.md changed👍


TST: add map twice

Codecov Report

Merging #26 into master will increase coverage by 0.15%.
The diff coverage is 100%.

@@            Coverage Diff             @@
##           master      #26      +/-   ##
==========================================
+ Coverage   97.13%   97.28%   +0.15%
==========================================
  Files           4        4
  Lines         803      848      +45
==========================================
+ Hits          780      825      +45
  Misses         23       23

Impacted Files
Coverage Δ

redsky/tests/test_streams.py
99.14% <100%> (+0.09%)
:arrow_up:

Continue to review full report at Codecov.

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


XLA Compilation does not work with Embeddings Layer

Please make sure that this is a bug. As per our
GitHub Policy,
we only address code/doc bugs, performance issues, feature requests and
build/installation issues on GitHub. tag:bug_template
System information

Have I written custom code (as opposed to using a stock example script provided in TensorFlow): Yes
OS Platform and Distribution (e.g., Linux Ubuntu 16.04):  Colab
Mobile device (e.g. iPhone 8, Pixel 2, Samsung Galaxy) if the issue happens on mobile device: n/a
TensorFlow installed from (source or binary): Default on colab
TensorFlow version (use command below): 2.3.0
Python version: 3.6.9
Bazel version (if compiling from source): n/a
GCC/Compiler version (if compiling from source): n/a
CUDA/cuDNN version: 10.1
GPU model and memory: Tesla P4 (8gb)

Describe the current behavior
I'm using a simple model with Embeddings which works with normal tf.function but does not work with tf.function(experimental_compile=True). I suspect it is because Embeddings are kept on the CPU while the other model layers are on the GPU, however, moving the tensors explicitly to the right device did not help (as demonstrated in the script).
Describe the expected behavior
The function should run without errors just like with a normal tf.function.
Standalone code to reproduce the issue
Provide a reproducible test case that is the bare minimum necessary to generate
the problem. If possible, please share a link to Colab/Jupyter/any notebook.
https://colab.research.google.com/drive/1dDjBiks335If3zqBleL_CPrNZ8CIanPP?usp=sharing
Other info / logs Include any logs or source code that would be helpful to
diagnose the problem. If including tracebacks, please include the full
traceback. Large logs and files should be attached.

@n2cholas
I have tried in TF-nightly version (2.4.0-dev20200930) and i am not seeing any issue. Please, find the gist here. Thanks!

@ravikyram Thanks! I was able to get it running on colab, but I still get the error on my local machine even with tf-nightly. Here are the specifications:

OS Platform and Distribution (e.g., Linux Ubuntu 16.04): Ubuntu 18.04
Mobile device (e.g. iPhone 8, Pixel 2, Samsung Galaxy) if the issue happens on mobile device: n/a
TensorFlow installed from (source or binary): pip (so binary)
TensorFlow version (use command below): 2.4.0-dev20200930
Python version: 3.8.5
Bazel version (if compiling from source): n/a
GCC/Compiler version (if compiling from source): n/a
CUDA/cuDNN version: 11.0
GPU model and memory: Titan RTX (24gb)

@n2cholas
Can you please share the error log.Thanks!

@ravikyram here's all the output from running it:
2020-10-05 13:56:02.579136: I tensorflow/stream_executor/platform/default/dso_loader.cc:48] Successfully opened dynamic library libcudart.so.11.0
2020-10-05 13:56:07.217818: I tensorflow/compiler/jit/xla_cpu_device.cc:41] Not creating XLA devices, tf_xla_enable_xla_devices not set
2020-10-05 13:56:07.218509: I tensorflow/stream_executor/platform/default/dso_loader.cc:48] Successfully opened dynamic library libcuda.so.1
2020-10-05 13:56:07.284812: I tensorflow/core/common_runtime/gpu/gpu_device.cc:1720] Found device 0 with properties:
pciBusID: 0000:17:00.0 name: TITAN V computeCapability: 7.0
coreClock: 1.455GHz coreCount: 80 deviceMemorySize: 11.78GiB deviceMemoryBandwidth: 607.97GiB/s
2020-10-05 13:56:07.284838: I tensorflow/stream_executor/platform/default/dso_loader.cc:48] Successfully opened dynamic library libcudart.so.11.0
2020-10-05 13:56:07.286588: I tensorflow/stream_executor/platform/default/dso_loader.cc:48] Successfully opened dynamic library libcublas.so.11
2020-10-05 13:56:07.287851: I tensorflow/stream_executor/platform/default/dso_loader.cc:48] Successfully opened dynamic library libcufft.so.10
2020-10-05 13:56:07.288096: I tensorflow/stream_executor/platform/default/dso_loader.cc:48] Successfully opened dynamic library libcurand.so.10
2020-10-05 13:56:07.289287: I tensorflow/stream_executor/platform/default/dso_loader.cc:48] Successfully opened dynamic library libcusolver.so.10
2020-10-05 13:56:07.289664: I tensorflow/stream_executor/platform/default/dso_loader.cc:48] Successfully opened dynamic library libcusparse.so.11
2020-10-05 13:56:07.289776: I tensorflow/stream_executor/platform/default/dso_loader.cc:48] Successfully opened dynamic library libcudnn.so.8
2020-10-05 13:56:07.290790: I tensorflow/core/common_runtime/gpu/gpu_device.cc:1862] Adding visible gpu devices: 0
2020-10-05 13:56:07.291078: I tensorflow/core/platform/cpu_feature_guard.cc:142] This TensorFlow binary is optimized with oneAPI Deep Neural Network Library (oneDNN) to use the following CPU instructions in performance-critical operations:  AVX2 AVX512F FMA
To enable them in other operations, rebuild TensorFlow with the appropriate compiler flags.
2020-10-05 13:56:07.291830: I tensorflow/compiler/jit/xla_gpu_device.cc:99] Not creating XLA devices, tf_xla_enable_xla_devices not set
2020-10-05 13:56:07.293287: I tensorflow/core/common_runtime/gpu/gpu_device.cc:1720] Found device 0 with properties:
pciBusID: 0000:17:00.0 name: TITAN V computeCapability: 7.0
coreClock: 1.455GHz coreCount: 80 deviceMemorySize: 11.78GiB deviceMemoryBandwidth: 607.97GiB/s
2020-10-05 13:56:07.293321: I tensorflow/stream_executor/platform/default/dso_loader.cc:48] Successfully opened dynamic library libcudart.so.11.0
2020-10-05 13:56:07.293346: I tensorflow/stream_executor/platform/default/dso_loader.cc:48] Successfully opened dynamic library libcublas.so.11
2020-10-05 13:56:07.293363: I tensorflow/stream_executor/platform/default/dso_loader.cc:48] Successfully opened dynamic library libcufft.so.10
2020-10-05 13:56:07.293378: I tensorflow/stream_executor/platform/default/dso_loader.cc:48] Successfully opened dynamic library libcurand.so.10
2020-10-05 13:56:07.293399: I tensorflow/stream_executor/platform/default/dso_loader.cc:48] Successfully opened dynamic library libcusolver.so.10
2020-10-05 13:56:07.293416: I tensorflow/stream_executor/platform/default/dso_loader.cc:48] Successfully opened dynamic library libcusparse.so.11
2020-10-05 13:56:07.293434: I tensorflow/stream_executor/platform/default/dso_loader.cc:48] Successfully opened dynamic library libcudnn.so.8
2020-10-05 13:56:07.299268: I tensorflow/core/common_runtime/gpu/gpu_device.cc:1862] Adding visible gpu devices: 0
2020-10-05 13:56:07.299335: I tensorflow/stream_executor/platform/default/dso_loader.cc:48] Successfully opened dynamic library libcudart.so.11.0
2020-10-05 13:56:07.749866: I tensorflow/core/common_runtime/gpu/gpu_device.cc:1261] Device interconnect StreamExecutor with strength 1 edge matrix:
2020-10-05 13:56:07.749896: I tensorflow/core/common_runtime/gpu/gpu_device.cc:1267]      0
2020-10-05 13:56:07.749901: I tensorflow/core/common_runtime/gpu/gpu_device.cc:1280] 0:   N
2020-10-05 13:56:07.751331: I tensorflow/core/common_runtime/gpu/gpu_device.cc:1406] Created TensorFlow device (/job:localhost/replica:0/task:0/device:GPU:0 with 10910 MB memory) -> physical GPU (device: 0, name: TITAN V, pci bus id: 0000:17:00.0, compute capability: 7.0)
WARNING:tensorflow:Layer lstm will not use cuDNN kernel since it doesn't meet the cuDNN kernel criteria. It will use generic GPU kernel as fallback when running on GPU
WARNING:tensorflow:Layer lstm_1 will not use cuDNN kernel since it doesn't meet the cuDNN kernel criteria. It will use generic GPU kernel as fallback when running on GPU
WARNING:tensorflow:Layer lstm_2 will not use cuDNN kernel since it doesn't meet the cuDNN kernel criteria. It will use generic GPU kernel as fallback when running on GPU
2020-10-05 13:56:11.378588: I tensorflow/compiler/xla/service/service.cc:168] XLA service 0x1be075d0 initialized for platform CUDA (this does not guarantee that XLA will be used). Devices:
2020-10-05 13:56:11.378619: I tensorflow/compiler/xla/service/service.cc:176]   StreamExecutor device (0): TITAN V, Compute Capability 7.0
2020-10-05 13:56:11.927927: I tensorflow/stream_executor/platform/default/dso_loader.cc:48] Successfully opened dynamic library libcublas.so.11
2020-10-05 13:56:20.457126: I tensorflow/compiler/jit/xla_compilation_cache.cc:325] Compiled cluster using XLA!  This line is logged at most once for the lifetime of the process.
2020-10-05 13:56:21.618453: W tensorflow/core/framework/op_kernel.cc:1763] OP_REQUIRES failed at xla_ops.cc:231 : Invalid argument: Trying to access resource _AnonymousVar10 located in device /job:localhost/replica:0/task:0/device:CPU:0 from device /job:localhost/replica:0/task:0/device:GPU:0
/job:localhost/replica:0/task:0/device:CPU:0
/job:localhost/replica:0/task:0/device:GPU:0
/job:localhost/replica:0/task:0/device:CPU:0
Traceback (most recent call last):
  File "main.py", line 83, in <module>
    forward(train_data[:batch_size], train_labels[:batch_size])
  File "/local/nvadivelu/jax-paper/tmp/env/lib/python3.8/site-packages/tensorflow/python/eager/def_function.py", line 795, in __call__
    result = self._call(*args, **kwds)
  File "/local/nvadivelu/jax-paper/tmp/env/lib/python3.8/site-packages/tensorflow/python/eager/def_function.py", line 822, in _call
    return self._stateless_fn(*args, **kwds)  # pylint: disable=not-callable
  File "/local/nvadivelu/jax-paper/tmp/env/lib/python3.8/site-packages/tensorflow/python/eager/function.py", line 2947, in __call__
    return graph_function._call_flat(
  File "/local/nvadivelu/jax-paper/tmp/env/lib/python3.8/site-packages/tensorflow/python/eager/function.py", line 1927, in _call_flat
    return self._build_call_outputs(self._inference_function.call(
  File "/local/nvadivelu/jax-paper/tmp/env/lib/python3.8/site-packages/tensorflow/python/eager/function.py", line 556, in call
    outputs = execute.execute(
  File "/local/nvadivelu/jax-paper/tmp/env/lib/python3.8/site-packages/tensorflow/python/eager/execute.py", line 59, in quick_execute
    tensors = pywrap_tfe.TFE_Py_Execute(ctx._handle, device_name, op_name,
tensorflow.python.framework.errors_impl.InvalidArgumentError: Trying to access resource _AnonymousVar10 located in device /job:localhost/replica:0/task:0/device:CPU:0 from device /job:localhost/replica:0/task:0/device:GPU:0 [Op:__inference_forward_16492]

Here is the output of pip freeze:
absl-py==0.10.0
astunparse==1.6.3
cachetools==4.1.1
certifi==2020.6.20
chardet==3.0.4
flatbuffers==1.12
gast==0.3.3
google-auth==1.22.1
google-auth-oauthlib==0.4.1
google-pasta==0.2.0
grpcio==1.32.0
h5py==2.10.0
idna==2.10
Keras==2.4.3
Keras-Preprocessing==1.1.2
Markdown==3.2.2
numpy==1.18.5
oauthlib==3.1.0
opt-einsum==3.3.0
protobuf==3.13.0
pyasn1==0.4.8
pyasn1-modules==0.2.8
PyYAML==5.3.1
requests==2.24.0
requests-oauthlib==1.3.0
rsa==4.6
scipy==1.5.2
six==1.15.0
tb-nightly==2.4.0a20201005
tensorboard-plugin-wit==1.7.0
termcolor==1.1.0
tf-estimator-nightly==2.4.0.dev2020100501
tf-nightly-gpu==2.4.0.dev20201005
typing-extensions==<IP_ADDRESS>
urllib3==1.25.10
Werkzeug==1.0.1
wrapt==1.12.1

@n2cholas
It looks like you are using an older Version of Tensorflow . Many bugs have been fixed in the latest version. Could you please execute your code using Latest Version 2.5 and let us know if the issue still persists? Thanks!

@Saduf2019 the issue still persists with 2.5.0. With 2.6.0, the code works there is a different issue.  Consider the following snippet (directly from the colab):
def to_cpu(x):
    with tf.device('/CPU:0'): return tf.identity(x)

def to_gpu(x):
    with tf.device('/GPU:0'): return tf.identity(x)

x = tf.convert_to_tensor([1, 2, 3])
print(x.device)
print(to_gpu(x).device)
print(to_cpu(to_gpu(x)).device)

This prints the following in 2.5.0 (which is correct):
/job:localhost/replica:0/task:0/device:CPU:0
/job:localhost/replica:0/task:0/device:GPU:0
/job:localhost/replica:0/task:0/device:CPU:0

But in 2.6.0, it prints:
/job:localhost/replica:0/task:0/device:CPU:0
/job:localhost/replica:0/task:0/device:CPU:0
/job:localhost/replica:0/task:0/device:CPU:0

The second line should be GPU. Why is this happening? is this a bug?

I met the same problem, did you know how to solve it now?

@n2cholas,
I tried to execute the mentioned code on tensorflow v2.14(GPU) and it was executed without any issue/error. Kindly find the gist of it here.
Also the code was providing the output as GPU which you are mentioning the above. Kindly find the screenshot for the reference.

Thank you!


can it support the mcwifipnp mod？

link to the mod
https://modrinth.com/mod/mcwifipnp

Do you have a link to the mod?

yes,here you are
https://modrinth.com/mod/mcwifipnp

it looks like that

Do you have a link to the mod?

yes,here you are
https://modrinth.com/mod/mcwifipnp
thanks a lot
and it looks like this

Thank you! I will take a look at it.

This has now been released as part of v1.2!


Feature: type alternatives (to facilitate traits/mixins/type decorators)

The type system does a great job at mirroring most type patterns in JS, all except mixins/traits, anything that decorates types - which unfortunately is very common in JS.
Without it the type system remains incomplete - that is, we're still one step short of being able to describe JavaScript mixin type patterns.
Duplication and interfaces are not the answer, because this does not reflect what's actually happening in JavaScript - e.g. not duplication, but type decoration of sorts. Not sure if I'm using the correct terminology here.
This small library is an example of a real-world decorator - duplicating all of it's method declarations in every single model type in a view-model hierarchy would be extremely impractical.
The following is a simplified example:
class User {
	public name: string;
}

interface Events {
	on(event: string, callback: {():void});
	// other methods here...
}

function addEvents<T>(object: T): T {
	// decorate the object:
	object['on'] = function() {
		// ...
	}
	return <T> {};
}

var user = addEvents(new User());

The drawback here is you have to choose which is more important - that User is still a User after being decorated by addEvents(), or that it is now also Events. There is no direct way to document this type pattern - your only option currently is to document the shape of the resulting type fully, duplicating all the member declarations contributed by the decorator.
I propose syntax along the lines of the following, to support type alternatives:
function addEvents<T>(object: T): T|Events {
	// decorate the object:
	object['on'] = function() {
		// ...
	}
	return <T|Events> {};
}

var user = addEvents(new User());

The return type of the call is now User|Events which is a distinct composite type composed members of User and Events.
The resulting composite type extends User and implements Events, and should pass type-checks for both.
This should facilitate type-safe traits/mixins and probably other arbitrary type-patterns possible in JS.
Static type-hints with composite types are implemented in this way in e.g. PhpStorm using php-doc annotations, and it works well.
I think this may be a simpler and more flexible way to support mixins/traits, without explicitly adding support for those patterns specifically.
Thoughts?

@joewood, they don't need to be extends, only implements.
function addEvents<T>(o: T): implements T, Events {
  o["on"] = function(){}
  return <implements T, Events>o;
}

If an interface could be extend a type parameter, this would provide an alternative solution, more verbose, but also possible to be more type-safe:
class C { c(){}}

interface HasEvents<T> extends T { on(name, fn: (o: T, n:number);}

function addEvents<T>(object: T) {
  object["on"]=function(){};
  return <HasEvents<T>>object;
}

OK this is not like #14 or #805, it's kind of the opposite. Here we need to say, in a generic way, "if you give me any object I will give you back the same object but now supporting a new interface", i.e. of both types so it is an intersection type not a union type.
If interfaces could extend a type parameter this would solve the issue and enable expressing the traits pattern properly, as above.
In the a real-world example we would want something like this (standard Emitter pattern):
interface Emitter{
  on(event, fn);
  once(event, fn);
  off(event, fn);
  emit(event);
}
interface EmitterTrait<T> extends T, Emitter{}

function MakeEmitter<T> : EmitterTrait<T>(t: T){
  // add the functions to the object
  require('emitter-library').mixin(t);
  return <Observable<T>>t;
}

Presumably it would also allow writing a type-safe .d.ts which did the same.

@mindplay-dk , I think this is resolved by Intersection types #3622 committed to master 21 days ago.

@benliddicott is correct. closing..


FindEntityByPropertyValue should accept the null and empty string as …

…a search criteria
FindEntitiesByPropertyValue should accept null or "" as search param.
The validation from the OMRS should be removed.
Also, the validation from the Atlas connector should be removed.
All the entities with the given type should be returned from the find method.
Signed-off-by: Daniela Otelea<EMAIL_ADDRESS>

I'll need to make some other changes to the IGC handling for the case where searchCriteria is null...  Just to confirm: null or "" should be treated the same (ie. retrieve all entities of the type in both cases)?

I'd also suggest we add a sentence to the JavaDoc comments (or searchCriteria parameter itself) indicating that when null / empty this is the expected behaviour, just for clarity down the road =)

Agree with @cmgrote that the JavaDoc commets should be updated - not just in the interface but all implementations - Base, Local, Enterprise, Atlas, IGC, Graph, Inmemory ...

@danielaotelea -- I think all that was left on this one now is to update the JavaDoc comments to indicate this as expected behaviour for null / ""...  Hopefully then we can get this committed and closed? 😁

is this PR still needed ?

As discussed with @danielaotelea I'll close this PR


Retire storage enabled volumes for the OCI registry

Which area/kind this issue is related to?

/area registry
Issue Description

Currently, the registry operator and the registry helm chart support the usage of a storage enabled volume for the OCI registry path to be mounted on. This allowed OCI artifacts to persist across deployments of the registry. These OCI artifacts at this point are created from the source content on the devfile-index (registry server) image, therefore in addition with security challenges with OpenShift it is best that support for this feature is retired.
The registry operator field spec.storage.enabled should be deprecated and the helm chart field persistence.enabled should also be deprecated. The field spec.storage.enabled should be disabled by default in https://github.com/devfile/api/issues/1092.
Acceptance Criteria

[ ] spec.storage.enabled should be disabled by default
[ ] spec.storage.enabled should be marked as deprecated
[ ] persistence.enabled should be marked as deprecated
[ ] Update documentation to reflect these changes

We might need to add the acceptance criteria for this issue. Putting it on "waiting" for now.

We might need to add the acceptance criteria for this issue. Putting it on "waiting" for now.

This issue description has been updated to include the acceptance criteria items.

Make sure the doc includes that the doc mentioned will be using emptyDir storage by default.

Hii , i would like to work on the issue .can refer where to make changes exactly?


21

Codecov Report

Merging #23 (57d3660) into main (6d8ae76) will decrease coverage by 5.72%.
The diff coverage is 50.00%.

@@            Coverage Diff             @@
##             main      #23      +/-   ##
==========================================
- Coverage   76.52%   70.80%   -5.73%
==========================================
  Files          21       21
  Lines         622      757     +135
==========================================
+ Hits          476      536      +60
- Misses        146      221      +75

Impacted Files
Coverage Δ

controle_contas/ext/site/views.py
33.33% <25.25%> (-7.67%)
:arrow_down:

controle_contas/ext/admin/model_view.py
68.23% <76.92%> (+3.37%)
:arrow_up:

controle_contas/ext/serializer/models.py
98.07% <92.30%> (-1.93%)
:arrow_down:

controle_contas/ext/db/models.py
90.69% <92.59%> (-0.61%)
:arrow_down:

controle_contas/ext/admin/__init__.py
100.00% <100.00%> (ø)

controle_contas/ext/auth/models.py
76.92% <100.00%> (+1.92%)
:arrow_up:

controle_contas/ext/site/forms.py
100.00% <100.00%> (ø)

controle_contas/ext/api/views.py
91.07% <0.00%> (-2.39%)
:arrow_down:

Continue to review full report at Codecov.

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


Wrong Version Connecting to File Share

Preflight Checklist

[X] I have installed the latest version of Storage Explorer.
[X] I have checked existing resources, including the troubleshooting guide and the release notes.
[X] I have searched for similar issues.

Storage Explorer Version
1.25.1
Regression From
No response
Architecture
x64
Storage Explorer Build Number
20220809.7
Platform
Windows
OS Version
Windows Server 2019
Bug Description
Unable to connect to fileshare with below error:
{
"name": "FetchError",
"message": "request to https://edhakinfs.file.core.windows.net/?sv=2021-06-08&ss=f&srt=sco&sp=rwdlc&se=2022-09-27T03:55:49Z&st=2022-09-26T19:55:49Z&sip=<IP_ADDRESS>&spr=https&SAS Token Redacted&comp=list failed, reason: tunneling socket could not be established, cause=write EPROTO<PHONE_NUMBER>:error:100000f7:SSL routines:OPENSSL_internal:WRONG_VERSION_NUMBER:../../third_party/boringssl/src/ssl/tls_record.cc:242:\n",
"stack": "FetchError: request to https://edhakinfs.file.core.windows.net/?sv=2021-06-08&ss=f&srt=sco&sp=rwdlc&se=2022-09-27T03:55:49Z&st=2022-09-26T19:55:49Z&sip=<IP_ADDRESS>&spr=https&SAS Token Redacted&comp=list failed, reason: tunneling socket could not be established, cause=write EPROTO<PHONE_NUMBER>:error:100000f7:SSL routines:OPENSSL_internal:WRONG_VERSION_NUMBER:../../third_party/boringssl/src/ssl/tls_record.cc:242:\n\n    at ClientRequest. (C:\Program Files (x86)\Microsoft Azure Storage Explorer\resources\app\node_modules\se-file-extension\dist\src\index.js:2:114361)\n    at ClientRequest.emit (node:events:526:28)\n    at ClientRequest.onError (C:\Program Files (x86)\Microsoft Azure Storage Explorer\resources\app\node_modules\se-file-extension\dist\src\index.js:2:599774)\n    at Object.onceWrapper (node:events:646:26)\n    at ClientRequest.emit (node:events:526:28)\n    at TLSSocket.socketErrorListener (node:_http_client:442:9)\n    at TLSSocket.emit (node:events:526:28)\n    at emitErrorNT (node:internal/streams/destroy:157:8)\n    at emitErrorCloseNT (node:internal/streams/destroy:122:3)\n    at process.processTicksAndRejections (node:internal/process/task_queues:83:21)",
"type": "system",
"errno": "ECONNRESET",
"code": "ECONNRESET"
}
Steps to Reproduce
Connect to storage account with SAS url
Attempt to connect to fileshare
Error
Actual Experience
Fileshare doesn't appear, produces SSL error instead
Expected Experience
No response
Additional Context
No response

@edhakin Are you using a proxy? If so, you need to set either "use app settings" or "use system proxy" in the proxy setting.

Closing due to lack of response. If you are still encountering this problem we recommend you open a support ticket via the Azure Portal. Alternatively you can open a new issue here.


Merge prTesting_202004161933 branch to master branch

Docs Build status updates of commit 8771bc8:
:clock10: Pending: waiting for processors (14 builds ahead of you)
:warning: Docs Build is busy, currently there are 14 builds ahead of this one, for more information you can view the Build queue graph on the Docs Portal.

Docs Build status updates of commit 8771bc8:
:warning: Validation status: warnings

File
Status
Preview URL
Details

split/updateTestCon.md
:warning:Warning

Details

split/updateTestCon.md

[Warning] Missing attribute: author. Add the current author's GitHub ID.
[Warning] Missing attribute: title. Add a title string to show in search engine results.
Line 1: [Suggestion] H1 is required. Use a single hash (#) followed by a space to create your top-level heading. NOTE: This Suggestion will become a Warning on 04/01/2020.

For more details, please refer to the build report.
Note: If you changed an existing file name or deleted a file, broken links in other files to the deleted or renamed file are listed only in the full build report.


ViewBinding in AppCompatDialogFragment

From Official docs:
Fragments outlive their views. Make sure you clean up any references to the binding class instance in the fragment's onDestroyView() method.
My question is the following:
`
public class SomeDialogFragment extends AppCompatDialogFragment {
private DialogSomeBinding binding;
@NonNull
@Override
public Dialog onCreateDialog(Bundle savedInstanceState) {
binding = DialogSomeBinding.inflate(LayoutInflater.from(requireContext()));
return new MaterialDialog.Builder(requireContext())
.customView(binding.getRoot(), false)
.build();
}
// This part is necessary even if you don't use onCreateView?
@Override
public void onDestroyView() {
binding = null;
super.onDestroyView();
}
}
`

Yes, Of course you need to clean the memory ( from variable that reference the binding).
Reason: Because you instantiate the variable binding, by fragment being destroyed you need to free it ( assign it null ).

can i work on this issu ?
this is my first contribution


[FLOC-2769] Test instructions for client installed using pip

This PR uses testable tasks for the pip installation of Flocker CLI provided for "other operating systems".
Although these instructions are a starting point for users on other OS's, we only test the instructions on CerntOS 7 (unsupported for clients) and Ubuntu 15.04 (a supported client system).  This is to check one YUM-based system, and one APT-based system, using the existing test resources.
The admin/run-client-tests command is modified to provide a --pip flag to install using pip instead of using packages.
For example, the command
./admin/run-client-tests --distribution=ubuntu-15.04 --flocker-version=1.0.3 --config-file=config.yml
installs the client using 1.0.3 packages.
The command
./admin/run-client-tests --pip --distribution=ubuntu-15.04 --flocker-version=1.0.3 --config-file=config.yml
installs the client using 1.0.3 wheel.
Note, for pip, using a non-release version number will use the previous production or dev release. This is necessary, since the wheel file is not published for each branch.
Note, there is another sub-issue to add this test to Buildbot (probably by combining it with the existing client tests).

Thanks @jongiddy
Couple of sentences to restructure, but no other changes required to the doc file.

Thanks for getting to this. It looks like a really useful thing to have.
I think a couple of things need to be renamed now that we've got more than one way of installing things. Also, I suspect the new pre_command will come back to byte us later. I've suggested a couple of alternative approaches.
Please go through them and resubmit for review.

I will get back to this PR once the fate of #1827 is known. That PR will allow this PR to use a cleaner solution than adding the pre_command parameter to the Run intent.

Tests now run in a Docker container, and do not need the pre_command attribute.
Moved the really basic setup required for Docker images (e.g. install sudo) into a separate piece of code which does not appear in the docs. Instead, the docs now mention that sudo is a requirement.  This keeps the instructions a bit less verbose, and we expect that most people will already have sudo, so it's a no-op anyway.
Incidentally, the client docs still had an intro referring to the overall structure of CLI and nodes, so I moved that to the top-level installation page.
To handle some escaped commands within commands (su -c 'command') I rewrote the shell escaping to allow nested lists for internal commands.
Pip installation can now be tested on Debian, Fedora, CentOS, and Ubuntu.  Plan is to create a single test in Buildbot that can run through all these systems in one test.

Thanks, LGTM. I've made an optional suggestion for a relatively large change. Bounce back to me if you decide to go for it. Likewise if you have to do anything major to fix tests.
Please feel free to land when the tests are all green.

Thanks for the review.
I have added the comment to FLOC-1670, since this has been discussed before for distribution-specific code, and I'd rather do it for the whole file as a consistent change. However, there doesn't seem to be much love for refactoring flocker.provision right now.


Cannot upgrade to the latest Kubernetes orchestrator using the latest acs-engine (0.26.0)

Is this a request for help?:
NO
Is this an ISSUE or FEATURE REQUEST? (choose one):
ISSUE
What version of acs-engine?:
0.26.0

Orchestrator and version (e.g. Kubernetes, DC/OS, Swarm)
Kubernetes 1.10.2
What happened:
I cannot upgrade our acs-engine deployed clusters to version 1.10.11.
What you expected to happen:
If I run
acs-engine orchestrators --orchestrator Kubernetes --version 1.10.2
I should get either "1.10.11" or "1.11.5", both not appearing in the above upgrade path.
How to reproduce it (as minimally and precisely as possible):
If I run
acs-engine orchestrators --orchestrator Kubernetes --version 1.10.2
I get:
{
  "orchestrators": [
    {
      "orchestratorType": "Kubernetes",
      "orchestratorVersion": "1.10.2",
      "upgrades": [
        {
          "orchestratorType": "",
          "orchestratorVersion": "1.10.8"
        },
        {
          "orchestratorType": "",
          "orchestratorVersion": "1.10.9"
        },
        {
          "orchestratorType": "",
          "orchestratorVersion": "1.11.3"
        },
        {
          "orchestratorType": "",
          "orchestratorVersion": "1.11.4"
        }
      ]
    }
  ]
}

Anything else we need to know:
Following this security vulnerability discovery, we need to upgrade our clusters to the latest version.
https://groups.google.com/forum/#!topic/kubernetes-announce/GVllWCg6L88
https://github.com/kubernetes/kubernetes/issues/71411

Depending on your threat model

The second method lets an unauthenticated user access the API to create unapproved services (https://github.com/kubernetes/kubernetes/issues/71411)

might be the much more important issue at the moment (it is for us).
However, at least when using acs-engine, this already seems to be the default: --anonymous-auth (see docs/clusterdefinition.md)
So from my understanding, anonymous access will not be possible when setting up a cluster with acs-engine (provided default options are used). The other issues of CVE-2018-1002105 are unaffected from this, though!

@pascalgn is correct, acs-engine clusters have --anonymous-auth=false which means they are not affected (that value is not user-configurable).
That being said, we will have a patch release containing 1.11.5 coming shortly (ETA today).

https://github.com/Azure/acs-engine/releases/tag/v0.26.1


Slovak and czech translations

I added Slovak and Czech translations, both are working properly.

Coverage increased (+0.07%) to 99.02% when pulling 32a65db5e5ec735a43e8d0ee2ba370b3648aace3 on CylonSK:slovak-czech-translation into 0733a49ab833886e7011974e69ce5560732c016f on jenssegers:master.

Thanks!


Add to Home Row experiment #3

Task/Issue URL:

https://app.asana.com/0/856498667320406/1154159749265353
https://app.asana.com/0/414235014887631/1156443180176857

Description:
Added:

Onboarding flow for Add to Home Row CTA (with video).
Custom alert flow for Add to Home Row CTA (with video).
Pixel in case WebKit process terminates.

Steps to test this PR:
All flows:

Onboarding screen should look good after layout and color tweaks.
set_version script should work after recent tweaks.
Home Row reminder should be shown after day 3 in case video is not played to the end and user does not visit Instructions in settings.

Control variant:

Ensure unified CTA (with video) is displayed after onboarding within the Home Screen (inside Tab) and it looks good.

Alert variant:

Ensure Alert-style CTA (with video) is displayed after onboarding above Main Screen.

Onboarding variant:

Ensure 2nd onboarding screen is displayed instead of CTA.

Internal references:
Software Engineering Expectations
Technical Design Template

Thanks @brindy!


Restore-DbaDatabase does not apply new diff backups

Before submitting a bug report:

[X] Ensure you are able to reproduce it on the latest released version (we release often)
[X] Verified this bug is not already reported in an issue
[X] Verified errors are not related to permissions
[X] Can reproduce in a clean PowerShell session (clean = powershell -NoProfile)

Steps to Reproduce

Restore a Full Backup
Restore-DbaDatabase -SqlInstance inote215\sql17 -Path c:\temp\bkp -NoRecovery

Apply Diff Backup
Restore-DbaDatabase -SqlInstance inote215\sql17 -Path c:\temp\bkp -NoRecovery -continue

Try to apply one more diff backup
Restore-DbaDatabase -SqlInstance inote215\sql17 -Path c:\temp\bkp -NoRecovery -continue

Expected Behavior
Was expecting the new diff backups to be applied.
Actual Behavior
First diff backup is applied.
Second time running to apply a new Diff backup doesn't do anything.
Running with -verbose:
VERBOSE: [13:29:05][Read-DbaBackupHeader] Scanning file
c:\temp\bkp\AdventureWorks2017_201808291651.bak.
VERBOSE: [13:29:06][Restore-DbaDatabase] Processing DatabaseName -
VERBOSE: [13:29:06][Format-DbaBackupInformation] Starting
VERBOSE: [13:29:06][Format-DbaBackupInformation] String passed in for DB rename
VERBOSE: [13:29:06][Select-DbaBackupInformation] ContinuePoints provided so setting up for a continue
VERBOSE: [13:29:06][Select-DbaBackupInformation] Filtering by DatabaseName
VERBOSE: [13:29:06][Select-DbaBackupInformation] AdventureWorks2017 in ContinuePoints, will attmept to
continue
VERBOSE: [13:29:06][Select-DbaBackupInformation] No full or diff, so attempting to pull from Continue
informmation
VERBOSE: [13:29:06][Restore-DbaDatabase] VerifyOnly = False
VERBOSE: [13:29:06][Get-DbaDbPhysicalFile] Connecting to INOTE215\SQL17
VERBOSE: [13:29:06][Restore-DbaDatabase]  passed testing
VERBOSE: [13:29:06][Restore-DbaDatabase] Passing in to restore
Environmental data

PowerShell:
PSVersion                      5.1.17134.165
PSEdition                      Desktop
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0...}
BuildVersion                   10.0.17134.165
CLRVersion                     4.0.30319.42000
WSManStackVersion              3.0
PSRemotingProtocolVersion      2.3
SerializationVersion           <IP_ADDRESS>

SQL Server:
Microsoft SQL Server 2017 (RTM-CU9) (KB4341265) - 14.0.3030.27 (X64)

Unfortunately Diffs don't work like that I'm afraid.
You can restore 1 and only one on top of a full. Then it's t logs only.
That's a sql server thing we can't work around.
On Fri, 31 Aug 2018 at 17:41, laoki<EMAIL_ADDRESS>wrote:

Before submitting a bug report:

Ensure you are able to reproduce it on the latest released version (we
release often)
Verified this bug is not already reported in an issue
Verified errors are not related to permissions
Can reproduce in a clean PowerShell session (clean = powershell
-NoProfile)

Steps to Reproduce
Restore a Full BackupRestore-DbaDatabase -SqlInstance inote215\sql17 -Path c:\temp\bkp -NoRecovery
Apply Diff BackupRestore-DbaDatabase -SqlInstance inote215\sql17 -Path c:\temp\bkp -NoRecovery -continue
Try to apply one more diff backupRestore-DbaDatabase -SqlInstance inote215\sql17 -Path c:\temp\bkp -NoRecovery -continue
Expected Behavior
Was expecting the new diff backups to be applied.
Actual Behavior
First diff backup is applied.
Second time running to apply a new Diff backup doesn't do anything.
Running with -verbose:
VERBOSE: [13:29:05][Read-DbaBackupHeader] Scanning file
c:\temp\bkp\AdventureWorks2017_201808291651.bak.
VERBOSE: [13:29:06][Restore-DbaDatabase] Processing DatabaseName -
VERBOSE: [13:29:06][Format-DbaBackupInformation] Starting
VERBOSE: [13:29:06][Format-DbaBackupInformation] String passed in for DB
rename
VERBOSE: [13:29:06][Select-DbaBackupInformation] ContinuePoints provided
so setting up for a continue
VERBOSE: [13:29:06][Select-DbaBackupInformation] Filtering by DatabaseName
VERBOSE: [13:29:06][Select-DbaBackupInformation] AdventureWorks2017 in
ContinuePoints, will attmept to
continue
VERBOSE: [13:29:06][Select-DbaBackupInformation] No full or diff, so
attempting to pull from Continue
informmation
VERBOSE: [13:29:06][Restore-DbaDatabase] VerifyOnly = False
VERBOSE: [13:29:06][Get-DbaDbPhysicalFile] Connecting to INOTE215\SQL17
VERBOSE: [13:29:06][Restore-DbaDatabase] passed testing
VERBOSE: [13:29:06][Restore-DbaDatabase] Passing in to restore
Environmental data

PowerShell:
PSVersion 5.1.17134.165
PSEdition Desktop
PSCompatibleVersions {1.0, 2.0, 3.0, 4.0...}
BuildVersion 10.0.17134.165
CLRVersion 4.0.30319.42000
WSManStackVersion 3.0
PSRemotingProtocolVersion 2.3
SerializationVersion <IP_ADDRESS>
  - SQL Server:
  Microsoft SQL Server 2017 (RTM-CU9) (KB4341265) - 14.0.3030.27 (X64)

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/sqlcollaborative/dbatools/issues/3958, or mute the
thread
https://github.com/notifications/unsubscribe-auth/AFWoZkYqb95Ewqr8JvJUYd0o7T6F8eBuks5uWWdPgaJpZM4WVh5k
.

Stuart,
I was able to restore the additional file using SSMS.
This is the result using get-dbarestorehistory after restoring the file using SSMS:

So you can. Show you where the phrase about assume comes from.
But, you don't need to. Diffs are based off a full backup and contain all
the changed pages since that backup. The last one contains the first so
you're repeating yourself restoring multiples. Just restore the latest and
save yourself a restore.
So there's no need to support this as if you'd fed all the backups in we'd
have Skipped the first diff anyway
On Fri, 31 Aug 2018 at 21:11, laoki<EMAIL_ADDRESS>wrote:

Stuart,
I was able to restore the additional file using SSMS.
This is the result using get-dbarestorehistory after restoring the file
using SSMS:
[image: image]
https://user-images.githubusercontent.com/25819430/44933801-c89c5180-ad40-11e8-81f4-c95b2548651f.png
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/sqlcollaborative/dbatools/issues/3958#issuecomment-417776732,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AFWoZtTt7MopiW6RON2DwznCejFaNz0Jks5uWZhWgaJpZM4WVh5k
.

+1 I'd like to have this, not sure how much effort will be involved though.

It's done. I'm just trying to replicate another issue to put in the same
pr. If I can't do that tonight I'll push up the fix anyway for tomorrow
morning.
On Thu, 6 Sep 2018 at 17:33, garethn<EMAIL_ADDRESS>wrote:

+1 I'd like to have this, not sure how much effort will be involved though.
—
You are receiving this because you were assigned.
Reply to this email directly, view it on GitHub
https://github.com/sqlcollaborative/dbatools/issues/3958#issuecomment-419159354,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AFWoZrQACVDf2wqjB2HxxESHn30ZHe1Qks5uYU4_gaJpZM4WVh5k
.

amazing, thanks Stuart,


Implement voice verification options in verify policy. Implement new voice phrase and voice phrase content resources.

Change Description

resource/pingone_verify_policy: Now supports voice configuration option enabling voice verification.
resource/pingone_voice_phrase: New resource enabling management of voice_phrase, a prerequisite and counterpart to voice configuration within a pingone_verify_policy.
resource/pingone_voice_phrase_content: New resource associated with pingone_voice_phrase used to define the voice enrollment or verification requirements associated with a verify_policy.
datasource/pingone_voice_phrase: New datasource to find voice phrase by voice_phrase_id or name.
datasource/pingone_voice_phrase_content: New datasource to find voice phrase content by voice_phrase_content_id.
datasource/pingone_voice_phrase_contents: New datasource to retrieve a list of voice phrase contents by voice_phrase_content_id.


Make Bubble chart radius scalable without changing the input value

Feature Proposal

At the moment if a value for radius is set, the scriptable radius function for the dataset or in the option is not called.
Also when i use the function, i need to remove the radius from the data and the label on hover will show undefined
Feature Use Case

I want to make bubble chart radius scalable, but still show the orignal value in the label
Possible Implementation

I had a short look in the code, maybe it would be enough to change the order how the radius is retrieved.
See:
https://github.com/chartjs/Chart.js/blob/release-3.x/src/controllers/controller.bubble.js#L157
# At the moment
values.radius += resolve([
	parsed && parsed._custom,
	me._config.radius,
	chart.options.elements.point.radius
], context, index);

# Suggestion:
values.radius += resolve([
       chart.options.elements.point.radius,
	me._config.radius,
	parsed && parsed._custom
], context, index);

With the change of order, i can keep the radius in the data, and will be displayed in the label, but the radius can be scaled with a custom scriptable function.
I can make a PR, if the solution is okay.

I think it would be confusing to change the order of resolution because users expect the more specific options specifications to override the more general specifications. Also, we resolve options in the same order throughout the codebase, so you'd have to change it not just here but in all chart types, which probably wouldn't make sense.

I don't think we should change the resolution order. The easiest way to do this would be to store the original value using a new property key. Then the tooltip label callback can be overridden to show the original value. https://jsfiddle.net/6jbgo02m/


#181 Implement possibilities to create load balancer with multiple pools by single command

@idrabenia done, please check. Also implemented #182


⚠ Bofrost.de has degraded performance

In ce54f5b, Bofrost.de (https://www.bofrost.de) experienced degraded performance:

HTTP code: 200
Response time: 888 ms

Resolved: Bofrost.de performance has improved in 85a30b1 after 8 minutes.


Questions about tracer and gravity

I am using the "tracer" to simulate the displacement of two fluids. How can I use the "tracer" to modify the density and rheological constants to depend on the "tracer" value.
If I define the gravity in more than one axis, the computation is aborted in the method "set_background_pressure". Is there any way to simulate gravity force in several axis?
If someone can help me I would be very grateful

Cesar --
Sorry not to get back to you earlier!
Currently the tracer is just a passively advected scalar, it has no
particular physical meaning.   But you can certainly use it to define
density and viscosity.  Note however that the interface between the two
fluids will end up getting "smeared" due to numerical diffusion.   If you
want a sharp interface you would need to use something like level sets
and/or volume-of-fluid approaches.  But this is not a bad start.
For computing density from tracer, for example, it could be as simple as
updating rho^{n+1] from tracer^{n+1} at line 312 in
src/incflo_apply_predictor.cpp, e.g. adding:
                amrex::ParallelFor(bx, [=] AMREX_GPU_DEVICE (int i, int

j, int k) noexcept
{
rho_new(i,j,k) = rho_1 * tra(i,j,k,n)  + rho_2 *
(1.0 - tra(i,j,k,n))
rho_nph(i,j,k) = 0.5 * (rho_old + rho);
}
You would want to make the same change in the corrector of course.  In the
above example rho_1 and rho_2 are just constants that you have specified
somewhere.
For the rheological constants you can add tracer as an argument to pass
into compute_viscosity (defined in src/rheology/incflo_rheology.cpp)
Re the gp0 -- if you want to define gravity not aligned with a coordinate
axis you'll need to disable the gp0 stuff -- I would just comment out the
call to set_background_pressure in incflo.cpp
Hope this helps!
Ann
On Wed, May 27, 2020 at 9:05 AM cesarcalvorincon<EMAIL_ADDRESS>wrote:

I am using the "tracer" to simulate the displacement of two fluids. How
can I use the "tracer" to modify the density and rheological constants to
depend on the "tracer" value.
If I define the gravity in more than one axis, the computation is aborted
in the method "set_background_pressure". Is there any way to simulate
gravity force in several axis?
If someone can help me I would be very grateful
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/AMReX-Codes/incflo/issues/40, or unsubscribe
https://github.com/notifications/unsubscribe-auth/ACRE6YW4JNJXAFXPAKVWUW3RTU24RANCNFSM4NMIXMNQ
.

--
Ann Almgren
Senior Scientist; CCSE Group Lead


Support generating data with only SNOMED "Global Patient Set" (or the new "IPS" beta refset)

Requested Feature
Currently, Synthea includes the following in its NOTICES file:

This material contains content from SNOMED CT and constitutes a fair use of such
copyrighted material as provided for in section 107 of the US Copyright Law for
the purposes of research and nonprofit educational purposes.
...
Use of SNOMED CT is subject to the IHTSDO Affiliate license provisions and is
free in IHTSDO Member territories including the United States, in low income
countries, and for Qualifying Research Projects in any country. To learn more,
please see the IHTSDO SNOMED CT and Licensing page
(https://www.snomed.org/snomed-ct/get-snomed-ct).

I want to store some synthea data on a public s3 bucket or a public FHIR server, but
our legal team was always nervous about violating the SNOMED CT terms (since it could be accessed by anyone).
Recently I saw the following post from SNOMED International about their efforts with IPS: https://www.snomed.org/news-and-events/articles/beta-release-IPS-terminology

The IPS Terminology is the next evolution of the HL7 IPS free set, providing advanced terminology features for non-Affiliates to use in their IPS implementations.

I believe MITRE is involved in IPS efforts as well and so maybe this feature already exists, but what I was hoping for was a config setting that ensures that only codes from this "free set" end up in the generated data.
Admittedly, I have no idea how limiting this set is at this point... let me know what you think.

This project is not associated with IPS.
In order to only use the IPS or GPS codes (which the IPS codes are a part of), we would need access to the codes to filter against.
That could be a local copy, or possibly a terminology server. If it is a local copy, that would require users to either register and download their own copy, or for us to redistribute it.
It appears to be licensed until Creative Commons 4.0, so technically we could redistribute it.
TBD.

It appears to be licensed until Creative Commons 4.0, so technically we could redistribute it.

That was basically my thought...include it right in this repo and use it conditionally.
Then, if some new exporter.restrictSnomedCodes config prop is set to true, check each code in the output and, if a given code doesn't exist in this subset, omit the Coding and use the preferred term in the CodeableConcept.text.
It could definitely be done in post-processing, but I wanted to see if there was appetite for such a feature in Synthea proper.


Adds commonly used go compilers to default compiler logic

As of 0.17.0 (with the introduction of the checks for compiler() function usage), the integration tests for conda-recipe-manager showed some failures with go projects in conda-forge:
 ╭─ Finding outputs from recipe
 │
 ╰─────────────────── (took 0 seconds)
Error:   × Failed to parse recipe

Error:   × Parsing: failed to render Jinja expression: undefined value: No compiler found for language: go-nocgo
  │ You should add `go-nocgo_compiler` to your variant config file. (in <string>:1)
    ╭─[22:7]
 21 │   build:
 22 │     - ${{ compiler('go-nocgo') }}
    ·       ─────────────┬─────────────
    ·                    ╰─┤ undefined value: No compiler found for language: go-nocgo
    ·                      │ You should add `go-nocgo_compiler` to your variant config file.
 23 │     - if: unix
    ╰────

This PR attempts to address this issue by adding default compilers for golang.
I verified this locally. I am able to dry-run build recipe files that use compiler('go') and compiler('go-nocgo') with these edits.

Seems like there is a lotnof repetition in this code per platform type. Perhaps we could refactor that a little. Not perse required for this PR! But if you wanna give that a go, that might be nice!

Seems like there is a lotnof repetition in this code per platform type. Perhaps we could refactor that a little. Not perse required for this PR! But if you wanna give that a go, that might be nice!

Agreed. Thought about that, but didn't want to be too aggressive in my first rattler PR :P

@baszalmstra I'll give it a quick shot.

I am also a big fan of the cleanup, but I am unsure with regards to adding more defaults. I think conda-build does not ship these by default, does it?

I am also a big fan of the cleanup, but I am unsure with regards to adding more defaults. I think conda-build does not ship these by default, does it?

To be fair, conda-build doesn't support rust as a default either: https://github.com/conda/conda-build/blob/4457362847b002ed4f6ce5c77a3f05f9325b449f/conda_build/variants.py#L61
I would argue both rust and go are popular enough to warrant inclusion, and, as far as I know, there aren't many (if any) mainstream alternative compilers for these languages.
At the end of the day though, all I care about it is that recipes that use compiler('go') pass the dry-run build, so if there's another way to address this issue, we can go another route.

Regarding rust - point taken!
I think we can do either:

add go compilers
add a default "compiler-name" forward behavior, so that rust => rust and go => go etc.

I would say let's add go for now and see how many more languages show up. If it's a lot, the forwarding idea is probably worth it as this list will be a pain to maintain. If it isn't a lot, then we provide some amount of validation/typo-protection to the user.
As a quick search in the 13k recipes in conda-recipe-manager-test-data, I'm seeing about 44 instances of compiler("rust") and about 37 instances of compiler("go")/compiler("go-nocgo"). Anything that isn't already covered looks like a one-off and there aren't all that many one-offs.


Must quit/restart app (or remove/add key) after renaming key to see new name under Available apps.

E.g.
If you rename a new "Yubikey NEO" under "Devices/Yubikey NEO" to "Yubkey NEO #2", the name under Devices is updated. However, if you then navigate any subitem under Available apps, the drop down list of NEO key names continues to show the original name.
Temporary workaround: removed/insert the NEO or quit/restart the app after renaming.

Thanks!


Assertion containsDocument isn't working correctly with not: true

version 0.3.2
Test autoscaling_test.yaml:
  - it: has no ScaledObject when autoscaling is disabled (default)
    set:
      autoscaling:
        enabled: false
    asserts:
      - containsDocument:
          kind: ScaledObject
          apiVersion: keda.sh/v1alpha1
        # invert the assertion
        not: true

Template:
{{- if .Values.autoscaling.enabled }}
{{- with .Values.autoscaling }}
apiVersion: keda.sh/v1alpha1
kind: ScaledObject
[object definition here, but it's disabled]
---
apiVersion: keda.sh/v1alpha1
kind: TriggerAuthentication
[another object, but again, the whole file is disabled]
{{- end -}}
{{- end -}}

Result:
 FAIL  test autoscaling configuration   tests/autoscaling_test.yaml
        - has no ScaledObject when autoscaling is disabled (default)

                - asserts[0] NOT `containsDocument` fail
                        Template:       terminus-service/templates/autoscaling.yaml
                        DocumentIndex:  0
                        Expected NOT to contain document:
                                Kind = ScaledObject, apiVersion = keda.sh/v1alpha1

Expectation:  should pass due to the file being rendered empty
Further information:
This is the same failure I receive if I remove the not: true.  Here that is, for completeness:
 FAIL  test autoscaling configuration   tests/autoscaling_test.yaml
        - has no ScaledObject when autoscaling is disabled (default)

                - asserts[0] `containsDocument` fail
                        Template:       terminus-service/templates/autoscaling.yaml
                        DocumentIndex:  0
                        Expected to contain document:
                                Kind = ScaledObject, apiVersion = keda.sh/v1alpha1

@quintush are you able to reproduce this?

Hello @jcogilvie,
Did create additional tests to identify the rootcause.
Have created a branch with the fix.
Hope to create a release by the end of the week (still trying fix some other bugs and add some additional functionaltity)
Greetings,
@quintush

Hello @quintush : I encountered the same problem on 0.3.3 - so I looked through the code a bit and I manage to fix it by reversing successful status when context is negative:
        if context.Negative {
                validateSuccess = !validateSuccess
        }

But maybe there's a better way to fix it - I don't understand completely the code.


docs: Use .mjs extension for library ESM bundle

As explained in #7609, when importing an ES module in Node.js, either its package needs to have "type": "module" set in its package.json, or its file extension needs to be .mjs. Otherwise the file will be interpreted as CommonJS and the import will fail.
The Library section of the Vite docs documents how to publish a library and also recommends to add an exports section to package.json. As far as I am aware, this section tells Node.js which file to import, although I believe some frontend bundlers are also adding support for it these days. The current documentation encourages developers to publish their ESM bundles with a .es.js extension, which will make the package impossible to be imported from an ESM Node.js project. Since not many Node.js projects use ESM yet, many developers are not aware of this problem.
This pull request changes the documentation to recommend the use of the .mjs extension for the generated bundle. This way the library bundle can be successfully used both in Node.js and in frontend bundlers.
What is the purpose of this pull request?

[ ] Bug fix
[ ] New Feature
[X] Documentation update
[ ] Other

See https://github.com/vitejs/vite/pull/6827, we are going to merge it as part of Vite v3 because it has a potential breaking change. I think we should update the docs together with that change in Vite (that is already part of the PR)
Thanks for looking into this!


CRM457-2198: Pricing

Description of change

Rather than do our own calculations that duplicate what the provider does, let them be done by the gem
Rather than trust provider-submitted blob to find out the relevant rates, use the gem

Link to relevant ticket

is it just not needed in the test but needed for the gem's input?

@ivanELEC  So our tests need to use data that matches the schema, but now there are a bunch of "deprecated" fields in the schema - i.e. places where we have been putting things like pricing, even though now we don't want to be reading those values from the blob (and when we introduce a v2 schema we'll remove them entirely). By having technically-valid-but-absolutely-loopy values like -1 in those fields in our test data, it allowed me to verify that we weren't naughtily continuing to use those values in the code - if we were, the tests would have blown up with negative figures.


Debian 8.6

That was a bit fast. Why is it closed?

typo in commit message. I just closed this one and started a new PR #1100


Mark Debian Bookworm as the default stable

Debian Bookworm is now stable and has been made available on Dockerhub:
Ref: https://github.com/docker-library/official-images/pull/14832
This PR marks it as the main stable distribution for our Debian images too.
PS: Prettier formatted the YAML file. Maybe not a bad change? Otherwise, I'm happy to soft reset and save without formatting. The only actual changes are: setting DEBIAN_LATEST to bookworm and adjusted the readme.

CI Failure is unrelated.


Tidy up docs for from_borrowed_ptr methods

The release pool doesn't exist for borrowed objects any more, so just tidied these docs up.

Good catch, thank you!


Ability to export symbols to be used via DLL

If someone writes DLL that uses easylogging++, we should export symbols to make various features accessible via application using this DLL

Hi, I had some problems with using easyloggingpp via dll (Windows), v 9.80.
To fix the problem with linker, i just add ELPP_EXPORT for s_currentUser and s_currentHost variables on line 1548, 1549.
Thanks


Unable to host in IIS on Windows 10 as an application

I am unable to get Blazor working using the Blazor (ASP.NET Core hosted) template while hosting the application as an IIS application on my local Windows 10 machine.

File, New Project, ASP.NET Core Web Application
Name: BlazorDotNetHosted, click OK
Select Blazor (ASP.NET Core hosted)
Right-click BlazorDotNetHosted.Server and select Publish
Select Folder, note it's going to bin\Release\netcoreapp2.1\publish\, click Publish
Create local folder at D:\apps\web\BlazorDotNetHosted
Copy+paste contents at bin\Release\netcoreapp2.1\publish\ to D:\apps\web\BlazorDotNetHosted
Open IIS, navigate to Default Web Site
Right-click Default Web Site and select Add Application
Alias: BlazorDotNetHosted, Application Pool: DefaultAppPool, Physical path: D:\apps\web\BlazorDotNetHosted, click OK
Click Browse.. to view the app at http://localhost/BlazorDotNetHosted/ and note that the page just says Loading...

Things I've tried:
Update the app base path as suggested here by opening the index.html at D:\apps\web\BlazorDotNetHosted\BlazorDotNetHosted.Client\dist\index.html and edit the base element to add the path:
<base href="/BlazorDotNetHosted/" />

This does allow the application to load.  However the links don't work as the navbar-brand, Counter, and Fetch Data links are localhost, localhost/counter, and localhost/fetchdata.  I even tried installing the URL Rewrite Module as suggested here.
If I manually navigate to localhost/BlazorDotNetHosted/counter that page works.
If I manually navigate to http://localhost/BlazorDotNetHosted/fetchdata it loads the page but the api call in Chrome Dev tools shows 404 not found on http://localhost/api/SampleData/WeatherForecasts.
If I hit the api at http://localhost/BlazorDotNetHosted/api/SampleData/WeatherForecasts that returns data successfully.
I feel like I'm very close but I'm unsure of how to get it to respect the base element.  Am I doing something wrong or is this not supported?  Does it have to be deployed to the root of a web server or hosted in app service at the root url?

For future reference if someone stumbles along this post, my work-around for now is to create it as its own website.  Perhaps this is the correct way to do it? /shrug

Open IIS, right-click Sites, select Add Website
Site name: BlazorDotNetHosted
Physical path: D:\apps\web\BlazorDotNetHosted
Port: 8082

It's now accessible and works at http://localhost:8082.

@rglos Take a look at https://blazor.net/docs/host-and-deploy/index.html#iis. I suspect you might be missing the URL Rewrite Module, which is a separate install.
/cc @guardrex

@danroth27 thanks for the reply.  I in fact do have the that module installed.  I know my post was verbose but I did mention it in the Things I've tried :(

I even tried installing the URL Rewrite Module as suggested here.

My bad! Let me take another looks at this.

@guardrex Feel free to chime in if you already have thoughts on this one.

I believe this ...

<base href="/BlazorDotNetHosted/" />

was the correct approach. Add /BlazorDotNetHosted/ to every NavLink (including the Home link, which will become href="/BlazorDotNetHosted/"). It should work 🤞.
I ran across the same thing when I was looking at how to host Blazor in Azure Storage/CDN. TL;DR Yes, that's what I ended up doing, and I believe you had the correct approach there for your scenario. https://github.com/aspnet/Blazor/issues/413

Add /BlazorDotNetHosted/ to every NavLink (including the Home link, which will become href="/BlazorDotNetHosted/"). It should work

I'm surprised that is necessary. @SteveSandersonMS Shouldn't adding a base path be enough?

It might be enough for Blazor to create links and manage internal navigation; however, links hard-coded into the markup seem not to be modified on build/publish. Those asset locations are interpreted by the browser to exist directly on the root path (IIRC that's what happened when I was playing with the Azure Storage/CDN scenario).

OK, I dug in this a bit more and I believe the issue is that the nav links and HttpClient URL link used in the templates are absolute paths with a leading slash instead of relative paths (#845). Also, the HttpClient base address reflects the app's base path, but without the trailing slash (#844).
To work around these issues;

Update your nav links and the fetch data URL used by the HttpClient to be relative paths (no leading slash). For the Home nav link you can use href="."
Update the HttpClient base address to add back the trailing slash if it isn't there.

Let me know if this works for you.

i have successfully hosted a Blazor app on IIS with Win 10.
Have a look at this article http://ankitsharmablogs.com/deploying-a-blazor-application-on-iis/

That fixes the navigational links but the api call still fails.
What I did:

Updated the links in NavMenu.cshtml to remove the leading slash.  For the navbar-brand and home, I changed the href to be href="."
Updated the base in index.html to be <base href="/BlazorDotNetHosted/" />
Update the FetchData.cshtml api url to remove the leading slash forecasts = await Http.GetJsonAsync<WeatherForecast[]>("api/SampleData/WeatherForecasts");

The console in Chrome still shows the api not respecting the base - GET http://localhost/api/SampleData/WeatherForecasts 404 (Not Found).
Did I miss a step?  I'm happy to help.
However, I didn't even try to see what this did for F5 development... I think for now I'm going to stick with the work around of making it a root site/app.  Otherwise I'd have to have it configured one way for development and then change a bunch of things before deploying it...

@AnkitSharma-007 you're creating that as a SITE not an APPLICATION under an existing site.  The work-around I mentioned is doing what you are doing.

@rglos The step you missed is you need to work around an issue with the HttpClient base address (#844).. The base address should have the trailing slash from the app's base path, but Blazor is trimming it off. You need to add the trailing slash back to the HttpClient's base path.


feat: accept extra props on DatePicker to pass down

Currently the DatePicker component type definition doesn't allow custom props to be passed down, even though the code would allow it.
From what I understand (correct me if I'm wrong here), simply adding this to the arguments type definition:
[key: string]: any;

would allow to pass props to the DatePicker component, which would then be passed to the react-datepicker
The reason for doing this is simple, if someone wants to customise the datepicker component, currently they have to duplicate the whole DatePicker component. Ideally, with this change, it would allow to customise only the Edit component, like this:
import React from 'react'

import { DatePicker, Label, FormGroup, FormMessage } from 'admin-bro'

const Edit = (props) => {
  const { property, onChange, record } = props
  const value = (record.params && record.params[property.name]) || ''
  const error = record.errors && record.errors[property.name]

  return (
    <FormGroup error={!!error}>
      <Label
        htmlFor={property.name}
        required={property.isRequired}
      >
        {property.label}
      </Label>
      <DatePicker
        value={value}
        disabled={property.isDisabled}
        onChange={(data) => onChange(property.name, data)}
        showYearPicker
        dateFormat="yyyy"
      />
      <FormMessage>{error && error.message}</FormMessage>
    </FormGroup>
  )
}

export default Edit

This adds showYearPicker and dateFormat="yyyy" for example.
An even better way to do this would be to accept custom properties on the original Edit component. Something like this perhaps:
      <DatePicker
        value={value}
        disabled={property.isDisabled}
        onChange={(data: string): void => onChange(property.name, data)}
        showYearDropdown
        {...property.custom}
      />

Let me know the preferred approach, and I will amend the code or send another PR if necessary

yes, this is correct - simply add {...property.custom} as you described and I will merge.


Wall-clock time plots

Optimizers can have very different runtimes per iteration, especially 2nd-order ones.
This means that sometimes, despite promises of "faster" convergence, the wall-clock time taken to converge is disappointingly larger.
Is there any chance DeepOBS could implement wall-clock time plots, in addition to per-epoch ones? (E.g. X axis in minutes or hours.)

Hi,
we thought about this, but decided against it.
First of all, measurements of wall-clock times can be very noisy and sensitive to the hardware, other processes running in parallel etc. It is very hard to reproduce wall-clock timings.
Secondly, it would defeat parts of the purpose of DeepOBS since everyone would need to re-run the baselines. In order to create wall-clock time plots, I would need to run all experiments on the same hardware. So if you come up with a new second-order optimizer, you would need to re-run the baselines of SGD, Adam & co. on your hardware.
However, we totally agree that wall-clock performance is highly relevant. At the end, this is what matters. So with DeepOBS we provide the option to estimate the per-epoch overtime that one optimizer requires compared to SGD.
You can check out the estimate_runtime script in the main repo (https://github.com/fsschneider/DeepOBS/blob/master/deepobs/scripts/deepobs_estimate_runtime.py). It basically allows you to estimate how much longer each epoch takes for your optimizer compared to SGD. This should help to mentally transform the "per-epoch" plots into a wall-clock time.
You can also check out section 3.5 of our paper (https://openreview.net/pdf?id=rJg6ssC5Y7)

Thanks, the "equivalent wall-clock time" seems like a reasonable compromise!
It seems like it's missing just the next logical step to allow comparing 1st and 2nd order solvers -- using this equivalent time as the X-axis instead of iterations or epochs; or put another way, applying the multiplier over SGD to the X-axis of each optimizer.
This multiplier will depend on the dataset and architecture, so it would be useful to have your computations of it not just for an MLP on MNIST.
Otherwise, as long as a user of DeepOBS is willing to rerun all the benchmarks on a dedicated machine (as I am!), the timings should be fair and comparable.

I agree that it would be a nice optional feature. However, it is currently not very high on our to-do list.
I also want to note one thing: There are two different "timings" that are both relevant for deep learning optimizers. The first is the actual wall-clock time now. This would behave exactly like you mentioned and the logical step would be indeed to plot all optimizers on join "wall-clock X-axis".
The second timing could be called "optimal wall-clock". The deep learning frameworks we currently use are very optimized for first-order methods. It is super easy to extract the gradient, but getting the individual gradients is already a huge pain. Well,theoretically this is easy and super cheap, but practically is quite hard (our group tackled the issue with this package https://backpack.pt/).
In this second case, it would be rather unfair to compare "wall-clock" time as it is severely limited by the current framework (I would, however, agree that "wall-clock" time is still interesting since it describes what a user can expect "right now" rather than in some optimal limit).
This is why we decided to go for this "hybrid approach". Plot using iterations, but always report "equivalent wall-clock time". Ideally, this would be coupled with a discussion in the paper of the theoretically optimal run-time.
By the way, you can do this "runtime overhead computation" for any test problem you want. MLP on MNIST is just the default. You can specify the test problem, the batch size and the epochs in order to get a fair evaluation (e.g. some optimizer might have a high initial cost that amortizes over time).

The second timing could be called "optimal wall-clock". The deep learning frameworks we currently use are very optimized for first-order methods. It is super easy to extract the gradient, but getting the individual gradients is already a huge pain. Well,theoretically this is easy and super cheap, but practically is quite hard (our group tackled the issue with this package https://backpack.pt/).

This is true, this affects for example CurveBall (as can be seen in the note in the PyTorch port's readme) -- different frameworks have very different runtimes (PyTorch currently being the worst unfortunately).
I guess using the "number of passes through the network" as a proxy for runtime could be another option, close to the theoretically-optimal time.
But for someone who just wants to use optimizers, this distinction can be deeply disappointing when they actually run it. Talking to other practitioners this is a common complaint and that's why I'm trying to run DeepOBS with a bit more focus on the timings; I'll see about implementing some of these ideas.
Also, thanks for your group's hard work on backpack, it's really good!

We are always interested in ways to improve it and discussions like these are exactly the way to achieve this.

My pleasure!


logdtl method can not find 'amulog.alg.logdtl' module

(.venv) robert@web-arc-lab:~/arclog/.log_out/test_upf_leaf1/amulog_run$ time python -m amulog db-make -c test.conf
Traceback (most recent call last):
File "/usr/lib/python3.10/runpy.py", line 196, in _run_module_as_main
return _run_code(code, main_globals, None,
File "/usr/lib/python3.10/runpy.py", line 86, in _run_code
exec(code, run_globals)
File "/home/robert/arclog/.venv/lib/python3.10/site-packages/amulog/main.py", line 635, in
main()
File "/home/robert/arclog/.venv/lib/python3.10/site-packages/amulog/main.py", line 631, in main
cli.main(DICT_ARGSET, ALIASES, SUBLIB)
File "/home/robert/arclog/.venv/lib/python3.10/site-packages/amulog/cli.py", line 60, in main
func(ns)
File "/home/robert/arclog/.venv/lib/python3.10/site-packages/amulog/main.py", line 109, in db_make
manager.process_files_online(conf, targets, True)
File "/home/robert/arclog/.venv/lib/python3.10/site-packages/amulog/manager.py", line 546, in process_files_online
ltm = LTManager(conf, ld.db, ld.lttable, reset_db=reset_db)
File "/home/robert/arclog/.venv/lib/python3.10/site-packages/amulog/manager.py", line 65, in init
self._ltgen = init_ltgen_methods(self._conf, self._table)
File "/home/robert/arclog/.venv/lib/python3.10/site-packages/amulog/manager.py", line 349, in init_ltgen_methods
return init_ltgen(conf, table, lt_methods[0], shuffle)
File "/home/robert/arclog/.venv/lib/python3.10/site-packages/amulog/manager.py", line 375, in init_ltgen
alg_module = import_module(modname)
File "/usr/lib/python3.10/importlib/init.py", line 126, in import_module
return _bootstrap._gcd_import(name[level:], package, level)
File "", line 1050, in _gcd_import
File "", line 1027, in _find_and_load
File "", line 1004, in _find_and_load_unlocked
ModuleNotFoundError: No module named 'amulog.alg.logdtl'

Sorry, the development of logdtl on amulog has been discontinued and this is a remnant of that work.
Last year I tried to port LogDTL (https://github.com/fukuda-lab/LogDTL) to amulog, but for various reasons I had to give up.
I will clean up the invalid functions in next updates.


Feature/exe 1354

Adding following plot functions that are already implemented in PixelatorR:

scatter_umi_per_upia_vs_tau
edge_rank_plot
cell_count_plot
plot_2d_graph
plot_3d_graph
plot_colocalization_heatmap
plot_colocalization_diff_heatmap:

Type of change

[x] New feature (non-breaking change which adds functionality)
[x] This change requires a documentation update

How Has This Been Tested?
Snapshot tests for each plot are added to the unit tests.
PR checklist:

[ ] This comment contains a description of changes (with reason).
[ ] My code follows the style guidelines of this project
[ ] Make sure your code lints, is well-formatted and type checks
[ ] I have performed a self-review of my own code
[ ] I have commented my code, particularly in hard-to-understand areas
[ ] I have made corresponding changes to the documentation
[ ] My changes generate no new warnings
[ ] I have added tests that prove my fix is effective or that my feature works
[ ] If you've added a new stage - have you followed the pipeline CLI conventions in the USAGE guide
[ ] README.md is updated
[ ] If a new tool or package is included, update poetry.lock, the conda recipe and cited it properly
[ ] Include any new authors/contributors
[ ] New and existing unit tests pass locally with my changes
[ ] Any dependent changes have been merged and published in downstream modules
[ ] I have checked my code and documentation and corrected any misspellings
[ ] Usage Documentation is updated
[ ] If you are doing a release, or a significant change to the code, update CHANGELOG.md

The assert_match fails for test_plot_3d_graph even though the plotly versions match. I have commented the assertion for now and just check if it returns a plotly figure. It might be the OS difference causing this and since it's an interactive plot we cannot really do an approximate match checking as we do for the 2d plots.


Windows install problem version 0.0.89

I tried to install version 0.0.89 Windows environment and i got this error :
gyp ERR! build error
│ gyp ERR! stack Error: C:\Program Files (x86)\Microsoft Visual Studio\2017\BuildTools\MSBuild\15.0\Bin\MSBuild.exe failed with exit code: 1
│ gyp ERR! stack     at ChildProcess.onExit (C:\Users\Mati\AppData\Local\node\corepack\pnpm\8.5.1\dist\node_modules\node-gyp\lib\build.js:203:23)
│ gyp ERR! stack     at ChildProcess.emit (node:events:513:28)
│ gyp ERR! stack     at ChildProcess._handle.onexit (node:internal/child_process:291:12)
│ gyp ERR! System Windows_NT 10.0.22621
│ gyp ERR! command "C:\Program Files\nodejs\node.exe" "C:\Users\Mati\AppData\Local\node\corepack\pnpm\8.5.1\dist\node_modules\node-gyp\bin\node-gyp.js" "rebuild"
│ gyp ERR! cwd<EMAIL_ADDRESS>│ gyp ERR! node -v v18.16.1
│ gyp ERR! node-gyp -v v9.3.1
│ gyp ERR! not ok
It's related to<EMAIL_ADDRESS>lib. I installed 0.0.88 and i didn't have any problem!

Have published a new version replacing the dependency that was breaking all windows installs. Could you check with version 0.0.90 and let me know if your issue is resolved?

Closing this issue as the fix is expected to work. Please reopen / create a new issue if required.


Reorganize projects to be able to test functions

As discussed in #85, most of the platform features are not tested yet. In order to solve this, we should move all non-frontend operations to a python folder for testing purposes.
Basically splitting the project into backend & frontend:

backend: reading, creating, manipulating data
frontend: displaying them

Thanks for the idea, it would indeed be great to test more systematically the logic in this repository! I wanted to discuss this in an issue before implementation to make sure I understand how to organise this.
Should the "python folder" that you mention look like the services sub-folder? We would have an __init__.py file in it, as well as another Python script storing the functions. Then, this sort of local package would be imported in main.py or in the other files. Is this correct?
Sorry for the maybe simple questions, but I probably lack some basic notions and I still need this kind of clarifications 😊

More or so, yes ! I think we could have something like this in the source folder:

"backend" all ops not related to display
"frontend"
"main.py" that would the only python script wth args to run the app (so a much lighter script than the current one which has both backend & frontend operations)

(of course the naming of folders can be changed)

I understand the need of testing and reshaping the project-tree to do so.
But splitting back and front isn't that easy as dash mix both (as you said @frgfm the actual main.py gathers py function that triggers dash objects for frontends purposes.
So the solution would be to create a brand new test folder with a test flask app + a new test.py that maps actual main.py ?

Oh so you don't think there are functions we could disentangle from dash main.py ?
I thought we could, but if that's not possible, I might have been wrong with this suggestion :sweat_smile:


Add colors prop to ButtonSolid(Link)

Who is this for?
Designers
What is it doing for them?
Giving them independent control over border, background and text colour for a button.
The colors prop is optional and if it isn't passed in, buttons will appear as they always have, via default values added to the theme config. I think there might be a nicer way to handle this with an enum, but it's too hot.
I think if we want to go with this, it should quickly unlock the ability to get rid of the ButtonOutlined and ButtonOutlinedLink components because I think those only differ from ButtonSolid(Link) in terms of these three colours.
This wasn't previously possible:

The :hover/:focus logic currently looks for the dark variant of the background colour and applies that with a transition. We haven't yet set dark variants for a lot of the colours (including white as in the example above) so there won't be a change on hover at the moment, but I didn't think it was worth adding those immediately, since instances where they won't currently appear are not publicly accessible.

Ooh this is interesting; I wanted to maybe tweak this component to decide where the icon could be placed (before/after copy) as part of the Concepts work... Might jump off the back of this to do it sooner than I thought.


[FLINK-10693] [Scala API] Fix incorrect duplication in EitherSerializer

What is the purpose of the change / Brief change log
Fixes the duplication of the Scala EitherSerialzer that never deep copies, even though the nested serializers might require it.
Verifying this change

Adds a self-contained unit test

Does this pull request potentially affect one of the following parts:

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

Documentation

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

CI test failure is unrelated:
FlinkKafkaProducerITCase.testFlinkKafkaProducer10FailTransactionCoordinatorBeforeNotify -Timeout

I'll backport this PR to release-1.5 and release-1.6. If Travis passes, then I'll merge it.


Visual indicator for that one can switch to the pen mode by clicking the bucket icon when the fill mode is active

In case this is implemented as an extra pen tool button, please also with an active indicator as stated here for the bucket tool.


Create fallback HTML file when prerendering is disabled

Fixes #4441. With prerendering.enabled = false the fallback HTML file was not created.
Please don't delete this checklist! Before submitting the PR, please make sure you do the following:

[X] It's really useful if your PR references an issue where it is discussed ahead of time. In many cases, features are absent for a reason. For large changes, please create an RFC: https://github.com/sveltejs/rfcs
[X] This message body should clearly illustrate what problems it solves.
[ ] Ideally, include a test that fails without this PR but passes with it.

Wasn't quite sure of the best way to test this. Looks like it would require creating a new sample app in the prerendering test directory with this configuration and a single test that the fallback file is written. Should I do that?
Tests

[X] Run the tests with pnpm test and lint the project with pnpm lint and pnpm check

Changesets

[X] If your PR makes a change that should be noted in one or more packages' changelogs, generate a changeset by running pnpx changeset and following the prompts. All changesets should be patch until SvelteKit 1.0

Thank you!