instagram.py

Hii

Hiii

Hi
On Mon, Jan 6, 2020, 10:34 PM vj-anu<EMAIL_ADDRESS>wrote:

Hiii
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/Pure-L0G1C/Instagram/pull/118?email_source=notifications&email_token=ANZDHWS6VRIQFLE7YE6UHMTQ4OIUHA5CNFSM4JGHCP62YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEIGWH5I#issuecomment-571302901,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ANZDHWTBS2RFQXZQCDRPU53Q4OIUHANCNFSM4JGHCP6Q
.


Implement callbacks

Provides special implementation for most APIs taking a callback.
Fixes #11 .

All fixed. I think this is ready now.


Textfiled have a onTapOutside func, I override this func to unfocus textfiled but not work

Is there an existing issue for this?

[X] I have searched the existing issues
[X] I have read the guide to filing a bug

Steps to reproduce
this is my textfiled:
TextField(
                        controller: _textController,
                        cursorColor: getThemeColorOnPrimaryContainer(context),
                        decoration: InputDecoration(
                            isCollapsed: true,
                            border: InputBorder.none,
                            hintText: "Messages..."),
                        focusNode: _inputFocusNode,
                        keyboardType: TextInputType.multiline,
                        textInputAction: widget.textInputAction,
                        maxLines: 5,
                        minLines: 1,
                        onSubmitted:
                            widget.textInputAction == TextInputAction.go
                                ? _handleSendPressedString
                                : null,
                        onChanged: widget.options.onTextChanged,
                        style: TextStyle(
                            color: getThemeColorOnPrimaryContainer(context)),
                        onTap: widget.options.onTextFieldTap,
                        onTapOutside: _handleTapInputOutside,
                        textCapitalization: TextCapitalization.sentences,
                      ),

the onTapOutside function is really annoying, I wannt textfiled tapped to pop up softkeyboard, but not the outside of textfiled,
so I override it, but it still keeps pops up soft keyboard
  void _handleTapInputOutside(PointerDownEvent e) {
    // widget.options.onTextFieldTap!();
    debugPrint("tap outside do nothing?");
    FocusScope.of(context).unfocus();
  }

Expected results
I need textfiled onTapOutside do not popup keyboard
Actual results
no
Code sample
Code sample
[Paste your code here]

Screenshots or Video

Screenshots / Video demonstration
[Upload media here]

Logs
Logs
[Paste your logs here]

Flutter Doctor output
Doctor output
[Paste your output here]

Hi,
I just tried and it works as intended, you need to use _inputFocusNode and in your method do  _focusNode.unfocus();
That's all :)

@luohao123 There are several ways to handle this. You can use above solution as @superciccio mentioned. Or wrap your parent widget (outside area) with a GestureDetector and request focus when tapping on it.
Closing this issue since it works as intended. Your question is best suited for support channels like StackOverflow, so please ask the same there for solutions if any. Thanks!


feat: decode percent-encoded path in getPath

#2672
This PR contains #2688 + https://github.com/honojs/hono/pull/2688#discussion_r1605780997
Specification Changes
There are no major release-level changes, but there are some minor changes as follows
Symbols and multibyte characters can be included in the static string of the routing definition
When you define a routing as follows, it will now match, whereas before it did not match because the percent encoding for static strings was not taken into account when routing.
app.get('/🔥', (c) => c.text(`I'm hono`)

http://example.com/%F0%9F%94%A5

Requests made with a URL that are encoded more than necessary are now matched with a decoded URL
Suppose we have a routing definition like this,
app.get('/static', (c) => c.text('static)

Even if unreserved characters are extra encoded, they are now decoded and matched.
http://example.com/%73tatic // %73 is 's'

Regular expressions for path parameters are now tested against decoded characters
We do not think that this will break any applications, but applications that use regular expressions in path parameters should check when updating to see if they are affected.
Suppose we have a routing definition like this,
app.get('/about/:product{🔥|Hono}', (c) => c.text(`Hono is a framework`)

The following URLs match
http://example.com/about/%F0%9F%94%A5

The author should do the following, if applicable

[x] Add tests
[x] Run tests
[x] bun denoify to generate files for Deno
[x] bun run format:fix && bun run lint:fix to format the code

@usualoma
Thanks! I'll include this in the next minor release and merge it into the next branch later.


[Event Request] Codeunit 10140 Deposit Post - OnAfterPostBalancingEntry

Please add the following event:
Window.Update(4, Text007);
if not GenJnlTemplate."Force Doc. Balance" then begin
PostBalancingEntry(Rec, TotalAmountLCY);
** OnAfterPostBalancingEntry(GenJnlLine, GLRegisterNo);**

Thanks for reporting this. We agree, and we’ll publish a fix asap, either in an update for the current version or in the next major release. We will update this issue with information about availability. Please do not reply to this, as we do not monitor closed issues. If you have follow-up questions or requests, please create a new issue where you reference this one.

Thanks for reporting this. We agree, and we’ll publish a fix asap, either in an update for the current version or in the next major release. We will update this issue with information about availability. Please do not reply to this, as we do not monitor closed issues. If you have follow-up questions or requests, please create a new issue where you reference this one.


[New Feature] Compatibility with OpenSearch version 2.3.0

Create a Querqy plugin version for OpenSearch v2.3.0

[ ] Update OpenSearch dependency
[ ] Deal with rewriter configurations > 32k. ES v8.2  started constraining keyword field length to this limit due to an underlying Lucene constraint. We've handled this in querqy-elasticsearch by splitting the config string and make it a multi-valued field (https://github.com/querqy/querqy-elasticsearch/commit/f28482e876c90d0a43437f1704b85b253b6f8e08#diff-4df2f4a9444dba31b05fec9e95c89ece96ff12ce0c0f4806142232066b38055e and https://github.com/querqy/querqy-elasticsearch/commit/f28482e876c90d0a43437f1704b85b253b6f8e08#diff-32be4fd4b3f6e7fdd2bad5997fd60c60b5f3e2237c3855d4e7dd1d18b5d8602d ). The issue was revealed in this integration test: https://github.com/querqy/querqy-elasticsearch/blob/d1bece60a5779f89fcd2f2f860444614d1e1d58f/src/test/java/querqy/elasticsearch/RewriterIntegrationTest.java#L103

@renekrie I've created a PR #27  to handle rewriter configurations > 32k based on your changes in ES plugin. The OS plugin already had the integ test for large query config: here. Do you know why was this not caught before?

I think I wasn't precise enough in my description: ES introduced a check to prevent a potential issue in Lucene keyword fields. So the test triggered an exception in ES which we might not see in OS. It could be that there might just be an inconsistency at the Lucene level that we will not reveal with the test. Anyway, I thought that it would still be good to proactively deal with it. (I'll try to remember the place in ES where this was checked)


High Performance Computing: CUDA and GCP

Use Cases
Collatz

https://en.wikipedia.org/wiki/Collatz_conjecture
http://www.ericr.nl/wondrous/delrecs.html

Implementation

https://github.com/ObrienlabsDev/blog/wiki/High-Performance-Computing
Turn off organization policies compute.vmExternalIpAccess and compute.requireShieldedVm before - see https://github.com/GoogleCloudPlatform/pubsec-declarative-toolkit/issues/426 and https://github.com/GoogleCloudPlatform/pbmm-on-gcp-onboarding/issues/252 for details

-tc tensor cores on dual 4090
michael@13900b MINGW64 /c/wse_github/gpu-burn
$ docker images list
REPOSITORY   TAG       IMAGE ID   CREATED   SIZE
https://developer.nvidia.com/ngc/nvidia-deep-learning-container-license

A copy of this license is made available in this container at /NGC-DL-CONTAINER-LICENSE for your convenience.

GPU 0: NVIDIA GeForce RTX 4090 (UUID: GPU-8c7dc11e-6825-08c1-f05d-5cff6d4ad6db)
GPU 1: NVIDIA GeForce RTX 4090 (UUID: GPU-511a0768-717f-2b3b-0133-b49b7d315929)
Using compare file: compare.ptx
Burning for 120 seconds.
10.8%  proc'd: 1463 (153538 Gflop/s) - 1540 (153827 Gflop/s)   errors: 0 - 0   temps: 58 C - 55 C
        Summary at:   Thu Aug 24 03:49:31 UTC 2023

21.7%  proc'd: 3311 (153176 Gflop/s) - 3388 (153534 Gflop/s)   errors: 0 - 0   temps: 58 C - 53 C
        Summary at:   Thu Aug 24 03:49:44 UTC 2023

32.5%  proc'd: 5159 (141268 Gflop/s) - 5159 (153899 Gflop/s)   errors: 0 - 0   temps: 55 C - 56 C
        Summary at:   Thu Aug 24 03:49:57 UTC 2023

43.3%  proc'd: 6930 (153622 Gflop/s) - 7007 (153653 Gflop/s)   errors: 0 - 0   temps: 59 C - 57 C
        Summary at:   Thu Aug 24 03:50:10 UTC 2023

53.3%  proc'd: 8624 (153068 Gflop/s) - 8701 (153686 Gflop/s)   errors: 0 - 0   temps: 60 C - 58 C
        Summary at:   Thu Aug 24 03:50:22 UTC 2023

64.2%  proc'd: 10472 (153347 Gflop/s) - 10472 (153499 Gflop/s)   errors: 0 - 0   temps: 61 C - 58 C
        Summary at:   Thu Aug 24 03:50:35 UTC 2023

75.0%  proc'd: 12243 (153239 Gflop/s) - 12320 (153441 Gflop/s)   errors: 0 - 0   temps: 61 C - 59 C
        Summary at:   Thu Aug 24 03:50:48 UTC 2023

85.8%  proc'd: 14091 (152801 Gflop/s) - 14091 (153219 Gflop/s)   errors: 0 - 0   temps: 61 C - 59 C
        Summary at:   Thu Aug 24 03:51:01 UTC 2023

96.7%  proc'd: 15862 (153500 Gflop/s) - 15939 (153400 Gflop/s)   errors: 0 - 0   temps: 56 C - 59 C
        Summary at:   Thu Aug 24 03:51:14 UTC 2023

100.0%  proc'd: 16555 (153201 Gflop/s) - 16632 (153399 Gflop/s)   errors: 0 - 0   temps: 61 C - 59 C
Killing processes with SIGTERM (soft kill)
Using compare file: compare.ptx
Burning for 120 seconds.
Initialized device 0 with 24563 MB of memory (22646 MB available, using 20381 MB of it), using FLOATS, using Tensor Cores
Results are 268435456 bytes each, thus performing 77 iterations
Freed memory for dev 0
Uninitted cublas
Using compare file: compare.ptx
Burning for 120 seconds.
Initialized device 1 with 24563 MB of memory (22646 MB available, using 20381 MB of it), using FLOATS, using Tensor Cores
Results are 268435456 bytes each, thus performing 77 iterations
Freed memory for dev 1
Uninitted cublas
done

Tested 2 GPUs:
        GPU 0: OK
        GPU 1: OK

RTX-A4000

micha@13900a MINGW64 /c/wse_github/gpu-burn (master)
$ docker run --rm --gpus all gpu-burn

==========
== CUDA ==
==========

CUDA Version 11.8.0

Container image Copyright (c) 2016-2023, NVIDIA CORPORATION & AFFILIATES. All rights reserved.

This container image and its contents are governed by the NVIDIA Deep Learning Container License.
By pulling and using the container, you accept the terms and conditions of this license:
https://developer.nvidia.com/ngc/nvidia-deep-learning-container-license

A copy of this license is made available in this container at /NGC-DL-CONTAINER-LICENSE for your convenience.

GPU 0: NVIDIA RTX A4000 (UUID: GPU-c585959e-3209-a20e-2522-e9420f268bc8)
Using compare file: compare.ptx
Burning for 120 seconds.
12.5%  proc'd: 100 (11643 Gflop/s)   errors: 0   temps: 47 C
        Summary at:   Wed Aug 23 00:34:50 UTC 2023

25.0%  proc'd: 300 (11103 Gflop/s)   errors: 0   temps: 60 C
        Summary at:   Wed Aug 23 00:35:05 UTC 2023

37.5%  proc'd: 450 (10962 Gflop/s)   errors: 0   temps: 69 C
        Summary at:   Wed Aug 23 00:35:20 UTC 2023

50.0%  proc'd: 550 (10682 Gflop/s)   errors: 0   temps: 75 C
        Summary at:   Wed Aug 23 00:35:35 UTC 2023

62.5%  proc'd: 700 (10404 Gflop/s)   errors: 0   temps: 78 C
        Summary at:   Wed Aug 23 00:35:50 UTC 2023

75.0%  proc'd: 850 (10254 Gflop/s)   errors: 0   temps: 79 C
        Summary at:   Wed Aug 23 00:36:05 UTC 2023

85.8%  proc'd: 1000 (10183 Gflop/s)   errors: 0   temps: 80 C
        Summary at:   Wed Aug 23 00:36:18 UTC 2023

100.0%  proc'd: 1150 (10105 Gflop/s)   errors: 0   temps: 81 C
        Summary at:   Wed Aug 23 00:36:35 UTC 2023

100.0%  proc'd: 1200 (10082 Gflop/s)   errors: 0   temps: 81 C
Killing processes with SIGTERM (soft kill)
Using compare file: compare.ptx
Burning for 120 seconds.
Initialized device 0 with 16375 MB of memory (14897 MB available, using 13407 MB of it), using FLOATS
Results are 268435456 bytes each, thus performing 50 iterations
Freed memory for dev 0
Uninitted cublas
done

Tested 1 GPUs:
        GPU 0: OK

micha@13900a MINGW64 /c/wse_github/gpu-burn (master)
$ vi Dockerfile

micha@13900a MINGW64 /c/wse_github/gpu-burn (master)
$ docker build -t gpu-burn .
[+] Building 2.0s (14/14) FINISHED                                                                                docker:default
 => [internal] load build definition from Dockerfile                                                                                0.0s
 => => transferring dockerfile: 413B                                                                                0.0s
 => [internal] load .dockerignore                                                                                0.0s
 => => transferring context: 2B                                                                                0.0s
 => [internal] load metadata for docker.io/nvidia/cuda:11.8.0-runtime-ubi8                                                          0.5s
 => [internal] load metadata for docker.io/nvidia/cuda:11.8.0-devel-ubi8                                                            0.6s
 => [builder 1/4] FROM docker.io/nvidia/cuda:11.8.0-devel-ubi8@sha256:c135690bac108cafde387faf5bd4f3007bd7c2f21db9099b573b472941d8  0.0s
 => [stage-1 1/4] FROM docker.io/nvidia/cuda:11.8.0-runtime-ubi8@sha256:3f05c79f4d11badbb70a26a08bd95b6019be501d670da05977e382b040  0.0s
 => [internal] load build context                                                                                0.0s
 => => transferring context: 2.59kB                                                                                0.0s
 => CACHED [builder 2/4] WORKDIR /build                                                                                0.0s
 => [builder 3/4] COPY . /build/                                                                                0.1s
 => [builder 4/4] RUN make                                                                                1.1s
 => CACHED [stage-1 2/4] COPY --from=builder /build/gpu_burn /app/                                                                  0.0s
 => CACHED [stage-1 3/4] COPY --from=builder /build/compare.ptx /app/                                                               0.0s
 => CACHED [stage-1 4/4] WORKDIR /app                                                                                0.0s
 => exporting to image                                                                                0.0s
 => => exporting layers                                                                                0.0s
 => => writing image sha256:727a7010d092c01d806b4975d2159754510066eb6da744ad512c9dd92df7fed8                                        0.0s
 => => naming to docker.io/library/gpu-burn                                                                                0.0s

What's Next?
  View summary of image vulnerabilities and recommendations → docker scout quickview

micha@13900a MINGW64 /c/wse_github/gpu-burn (master)
$ docker run --rm --gpus all gpu-burn

==========
== CUDA ==
==========

CUDA Version 11.8.0

Container image Copyright (c) 2016-2023, NVIDIA CORPORATION & AFFILIATES. All rights reserved.

This container image and its contents are governed by the NVIDIA Deep Learning Container License.
By pulling and using the container, you accept the terms and conditions of this license:
https://developer.nvidia.com/ngc/nvidia-deep-learning-container-license

A copy of this license is made available in this container at /NGC-DL-CONTAINER-LICENSE for your convenience.

GPU 0: NVIDIA RTX A4000 (UUID: GPU-c585959e-3209-a20e-2522-e9420f268bc8)
Using compare file: compare.ptx
Burning for 120 seconds.
71.7%  proc'd: 24 (306 Gflop/s)   errors: 0   temps: 65 C
        Summary at:   Wed Aug 23 00:48:26 UTC 2023

83.3%  proc'd: 24 (306 Gflop/s)   errors: 0   temps: 66 C
        Summary at:   Wed Aug 23 00:48:40 UTC 2023

95.8%  proc'd: 24 (306 Gflop/s)   errors: 0   temps: 68 C
        Summary at:   Wed Aug 23 00:48:55 UTC 2023

100.0%  proc'd: 24 (306 Gflop/s)   errors: 0   temps: 69 C
Killing processes with SIGTERM (soft kill)

Killing processes with SIGKILL (force kill)
done

Tested 1 GPUs:
        GPU 0: OK

micha@13900a MINGW64 /c/wse_github/gpu-burn (master)
$ vi Dockerfile

micha@13900a MINGW64 /c/wse_github/gpu-burn (master)
$ docker build -t gpu-burn .
[+] Building 1.5s (14/14) FINISHED                                                                                docker:default
 => [internal] load .dockerignore                                                                                0.0s
 => => transferring context: 2B                                                                                0.0s
 => [internal] load build definition from Dockerfile                                                                                0.0s
 => => transferring dockerfile: 448B                                                                                0.0s
 => [internal] load metadata for docker.io/nvidia/cuda:11.8.0-runtime-ubi8                                                          0.3s
 => [internal] load metadata for docker.io/nvidia/cuda:11.8.0-devel-ubi8                                                            0.3s
 => [builder 1/4] FROM docker.io/nvidia/cuda:11.8.0-devel-ubi8@sha256:c135690bac108cafde387faf5bd4f3007bd7c2f21db9099b573b472941d8  0.0s
 => [stage-1 1/4] FROM docker.io/nvidia/cuda:11.8.0-runtime-ubi8@sha256:3f05c79f4d11badbb70a26a08bd95b6019be501d670da05977e382b040  0.0s
 => [internal] load build context                                                                                0.0s
 => => transferring context: 2.62kB                                                                                0.0s
 => CACHED [builder 2/4] WORKDIR /build                                                                                0.0s
 => [builder 3/4] COPY . /build/                                                                                0.0s
 => [builder 4/4] RUN make                                                                                1.1s
 => CACHED [stage-1 2/4] COPY --from=builder /build/gpu_burn /app/                                                                  0.0s
 => CACHED [stage-1 3/4] COPY --from=builder /build/compare.ptx /app/                                                               0.0s
 => CACHED [stage-1 4/4] WORKDIR /app                                                                                0.0s
 => exporting to image                                                                                0.0s
 => => exporting layers                                                                                0.0s
 => => writing image sha256:6b5d365fd9cd38a493e55b2226fbb4b5f9960fa47b1717d95c6bf553d8fc6f74                                        0.0s
 => => naming to docker.io/library/gpu-burn                                                                                0.0s

What's Next?
  View summary of image vulnerabilities and recommendations → docker scout quickview

micha@13900a MINGW64 /c/wse_github/gpu-burn (master)
$ docker run --rm --gpus all gpu-burn

==========
== CUDA ==
==========

CUDA Version 11.8.0

Container image Copyright (c) 2016-2023, NVIDIA CORPORATION & AFFILIATES. All rights reserved.

This container image and its contents are governed by the NVIDIA Deep Learning Container License.
By pulling and using the container, you accept the terms and conditions of this license:
https://developer.nvidia.com/ngc/nvidia-deep-learning-container-license

A copy of this license is made available in this container at /NGC-DL-CONTAINER-LICENSE for your convenience.

GPU 0: NVIDIA RTX A4000 (UUID: GPU-c585959e-3209-a20e-2522-e9420f268bc8)
Using compare file: compare.ptx
Burning for 120 seconds.
10.8%  proc'd: 400 (40001 Gflop/s)   errors: 0   temps: 55 C
        Summary at:   Wed Aug 23 00:51:28 UTC 2023

21.7%  proc'd: 850 (38789 Gflop/s)   errors: 0   temps: 66 C
        Summary at:   Wed Aug 23 00:51:41 UTC 2023

32.5%  proc'd: 1300 (38000 Gflop/s)   errors: 0   temps: 71 C
        Summary at:   Wed Aug 23 00:51:54 UTC 2023

43.3%  proc'd: 1750 (36969 Gflop/s)   errors: 0   temps: 77 C
        Summary at:   Wed Aug 23 00:52:07 UTC 2023

53.3%  proc'd: 2150 (36430 Gflop/s)   errors: 0   temps: 78 C
        Summary at:   Wed Aug 23 00:52:19 UTC 2023

64.2%  proc'd: 2600 (36109 Gflop/s)   errors: 0   temps: 80 C
        Summary at:   Wed Aug 23 00:52:32 UTC 2023

75.0%  proc'd: 3000 (35894 Gflop/s)   errors: 0   temps: 80 C
        Summary at:   Wed Aug 23 00:52:45 UTC 2023

86.7%  proc'd: 3450 (35780 Gflop/s)   errors: 0   temps: 81 C
        Summary at:   Wed Aug 23 00:52:59 UTC 2023

97.5%  proc'd: 3900 (35670 Gflop/s)   errors: 0   temps: 81 C
        Summary at:   Wed Aug 23 00:53:12 UTC 2023

100.0%  proc'd: 4050 (35502 Gflop/s)   errors: 0   temps: 81 C
Killing processes with SIGTERM (soft kill)
Using compare file: compare.ptx
Burning for 120 seconds.
Initialized device 0 with 16375 MB of memory (14897 MB available, using 13407 MB of it), using FLOATS, using Tensor Cores
Results are 268435456 bytes each, thus performing 50 iterations
Freed memory for dev 0
Uninitted cublas
done

Tested 1 GPUs:
        GPU 0: OK

micha@13900a MINGW64 /c/wse_github/gpu-burn (master)
$ vi Dockerfile

micha@13900a MINGW64 /c/wse_github/gpu-burn (master)
$ docker build -t gpu-burn .
[+] Building 1.8s (14/14) FINISHED                                                                                docker:default
 => [internal] load .dockerignore                                                                                0.0s
 => => transferring context: 2B                                                                                0.0s
 => [internal] load build definition from Dockerfile                                                                                0.0s
 => => transferring dockerfile: 447B                                                                                0.0s
 => [internal] load metadata for docker.io/nvidia/cuda:11.8.0-runtime-ubi8                                                          0.5s
 => [internal] load metadata for docker.io/nvidia/cuda:11.8.0-devel-ubi8                                                            0.5s
 => [builder 1/4] FROM docker.io/nvidia/cuda:11.8.0-devel-ubi8@sha256:c135690bac108cafde387faf5bd4f3007bd7c2f21db9099b573b472941d8  0.0s
 => [stage-1 1/4] FROM docker.io/nvidia/cuda:11.8.0-runtime-ubi8@sha256:3f05c79f4d11badbb70a26a08bd95b6019be501d670da05977e382b040  0.0s
 => [internal] load build context                                                                                0.0s
 => => transferring context: 2.62kB                                                                                0.0s
 => CACHED [builder 2/4] WORKDIR /build                                                                                0.0s
 => [builder 3/4] COPY . /build/                                                                                0.0s
 => [builder 4/4] RUN make                                                                                1.1s
 => CACHED [stage-1 2/4] COPY --from=builder /build/gpu_burn /app/                                                                  0.0s
 => CACHED [stage-1 3/4] COPY --from=builder /build/compare.ptx /app/                                                               0.0s
 => CACHED [stage-1 4/4] WORKDIR /app                                                                                0.0s
 => exporting to image                                                                                0.0s
 => => exporting layers                                                                                0.0s
 => => writing image sha256:c2251b27fe14d1aa8b4da51bcb4051c3c1ffabacf1e626e90579b13adb5833c4                                        0.0s
 => => naming to docker.io/library/gpu-burn                                                                                0.0s

What's Next?
  View summary of image vulnerabilities and recommendations → docker scout quickview

micha@13900a MINGW64 /c/wse_github/gpu-burn (master)
$ docker run --rm --gpus all gpu-burn

==========
== CUDA ==
==========

CUDA Version 11.8.0

Container image Copyright (c) 2016-2023, NVIDIA CORPORATION & AFFILIATES. All rights reserved.

This container image and its contents are governed by the NVIDIA Deep Learning Container License.
By pulling and using the container, you accept the terms and conditions of this license:
https://developer.nvidia.com/ngc/nvidia-deep-learning-container-license

A copy of this license is made available in this container at /NGC-DL-CONTAINER-LICENSE for your convenience.

GPU 0: NVIDIA RTX A4000 (UUID: GPU-c585959e-3209-a20e-2522-e9420f268bc8)
Using compare file: compare.ptx
Burning for 120 seconds.
71.7%  proc'd: 24 (305 Gflop/s)   errors: 0   temps: 71 C
        Summary at:   Wed Aug 23 00:56:10 UTC 2023

83.3%  proc'd: 24 (305 Gflop/s)   errors: 0   temps: 72 C
        Summary at:   Wed Aug 23 00:56:24 UTC 2023

95.8%  proc'd: 24 (305 Gflop/s)   errors: 0   temps: 72 C
        Summary at:   Wed Aug 23 00:56:39 UTC 2023

100.0%  proc'd: 24 (305 Gflop/s)   errors: 0   temps: 72 C
Killing processes with SIGTERM (soft kill)

Killing processes with SIGKILL (force kill)
done

Tested 1 GPUs:
        GPU 0: OK

micha@13900a MINGW64 /c/wse_github/gpu-burn (master)
$ docker run --rm --gpus all gpu-burn

NVIDIA TX-A4500 single PCIe-x16 13900K 1600W PSU - 128G DDR5

micha@13900a MINGW64 /c/wse_github/gpu-burn (master)
$ docker run --rm --gpus all gpu-burn

==========
== CUDA ==
==========

CUDA Version 11.8.0

Container image Copyright (c) 2016-2023, NVIDIA CORPORATION & AFFILIATES. All rights reserved.

This container image and its contents are governed by the NVIDIA Deep Learning Container License.
By pulling and using the container, you accept the terms and conditions of this license:
https://developer.nvidia.com/ngc/nvidia-deep-learning-container-license

A copy of this license is made available in this container at /NGC-DL-CONTAINER-LICENSE for your convenience.

GPU 0: NVIDIA RTX A4500 (UUID: GPU-898f04be-4440-1d50-e748-afe4f4f8abd0)
Using compare file: compare.ptx
Burning for 120 seconds.
81.7%  proc'd: 31 (349 Gflop/s)   errors: 0   temps: 51 C
        Summary at:   Fri Aug 25 01:56:03 UTC 2023

91.7%  proc'd: 31 (349 Gflop/s)   errors: 0   temps: 53 C
        Summary at:   Fri Aug 25 01:56:15 UTC 2023

100.0%  proc'd: 31 (349 Gflop/s)   errors: 0   temps: 54 C
Killing processes with SIGTERM (soft kill)

Killing processes with SIGKILL (force kill)
done

Tested 1 GPUs:
        GPU 0: OK

micha@13900a MINGW64 /c/wse_github/gpu-burn (master)
$ vi Dockerfile

micha@13900a MINGW64 /c/wse_github/gpu-burn (master)
$ docker build -t gpu-burn .
[+] Building 2.0s (14/14) FINISHED                                                                                docker:default
 => [internal] load build definition from Dockerfile                                                                                0.0s
 => => transferring dockerfile: 441B                                                                                0.0s
 => [internal] load .dockerignore                                                                                0.0s
 => => transferring context: 2B                                                                                0.0s
 => [internal] load metadata for docker.io/nvidia/cuda:11.8.0-runtime-ubi8                                                                              0.6s
 => [internal] load metadata for docker.io/nvidia/cuda:11.8.0-devel-ubi8                                                                                0.5s
 => [builder 1/4] FROM docker.io/nvidia/cuda:11.8.0-devel-ubi8@sha256:c135690bac108cafde387faf5bd4f3007bd7c2f21db9099b573b472941d8148c                  0.0s
 => [stage-1 1/4] FROM docker.io/nvidia/cuda:11.8.0-runtime-ubi8@sha256:3f05c79f4d11badbb70a26a08bd95b6019be501d670da05977e382b04023b30e                0.0s
 => [internal] load build context                                                                                0.0s
 => => transferring context: 2.62kB                                                                                0.0s
 => CACHED [builder 2/4] WORKDIR /build                                                                                0.0s
 => [builder 3/4] COPY . /build/                                                                                0.0s
 => [builder 4/4] RUN make                                                                                1.2s
 => CACHED [stage-1 2/4] COPY --from=builder /build/gpu_burn /app/                                                                                0.0s
 => CACHED [stage-1 3/4] COPY --from=builder /build/compare.ptx /app/                                                                                0.0s
 => CACHED [stage-1 4/4] WORKDIR /app                                                                                0.0s
 => exporting to image                                                                                0.0s
 => => exporting layers                                                                                0.0s
 => => writing image sha256:d79438766981c3c94306c18a225e4c873f36f05d7614a2d147016eb9947132f1                                                            0.0s
 => => naming to docker.io/library/gpu-burn                                                                                0.0s

What's Next?
  View summary of image vulnerabilities and recommendations → docker scout quickview

micha@13900a MINGW64 /c/wse_github/gpu-burn (master)
$ cat Dockerfile
ARG CUDA_VERSION=11.8.0
ARG IMAGE_DISTRO=ubi8

FROM nvidia/cuda:${CUDA_VERSION}-devel-${IMAGE_DISTRO} AS builder

WORKDIR /build

COPY . /build/

RUN make

FROM nvidia/cuda:${CUDA_VERSION}-runtime-${IMAGE_DISTRO}

COPY --from=builder /build/gpu_burn /app/
COPY --from=builder /build/compare.ptx /app/

WORKDIR /app

CMD ["./gpu_burn", "120"]
#CMD ["./gpu_burn", "-d", "-tc", "120"]

micha@13900a MINGW64 /c/wse_github/gpu-burn (master)
$ docker run --rm --gpus all gpu-burn

==========
== CUDA ==
==========

CUDA Version 11.8.0

Container image Copyright (c) 2016-2023, NVIDIA CORPORATION & AFFILIATES. All rights reserved.

This container image and its contents are governed by the NVIDIA Deep Learning Container License.
By pulling and using the container, you accept the terms and conditions of this license:
https://developer.nvidia.com/ngc/nvidia-deep-learning-container-license

A copy of this license is made available in this container at /NGC-DL-CONTAINER-LICENSE for your convenience.

GPU 0: NVIDIA RTX A4500 (UUID: GPU-898f04be-4440-1d50-e748-afe4f4f8abd0)
Using compare file: compare.ptx
Burning for 120 seconds.
12.5%  proc'd: 128 (14575 Gflop/s)   errors: 0   temps: 58 C
        Summary at:   Fri Aug 25 01:57:46 UTC 2023

25.0%  proc'd: 320 (14430 Gflop/s)   errors: 0   temps: 63 C
        Summary at:   Fri Aug 25 01:58:01 UTC 2023

37.5%  proc'd: 512 (14276 Gflop/s)   errors: 0   temps: 68 C
        Summary at:   Fri Aug 25 01:58:16 UTC 2023

50.0%  proc'd: 704 (14178 Gflop/s)   errors: 0   temps: 70 C
        Summary at:   Fri Aug 25 01:58:31 UTC 2023

62.5%  proc'd: 896 (14103 Gflop/s)   errors: 0   temps: 72 C
        Summary at:   Fri Aug 25 01:58:46 UTC 2023

75.0%  proc'd: 1088 (14026 Gflop/s)   errors: 0   temps: 73 C
        Summary at:   Fri Aug 25 01:59:01 UTC 2023

87.5%  proc'd: 1280 (14007 Gflop/s)   errors: 0   temps: 73 C
        Summary at:   Fri Aug 25 01:59:16 UTC 2023

100.0%  proc'd: 1472 (13981 Gflop/s)   errors: 0   temps: 74 C
        Summary at:   Fri Aug 25 01:59:31 UTC 2023

100.0%  proc'd: 1536 (13988 Gflop/s)   errors: 0   temps: 74 C
Killing processes with SIGTERM (soft kill)
Using compare file: compare.ptx
Burning for 120 seconds.
Initialized device 0 with 20469 MB of memory (18956 MB available, using 17060 MB of it), using FLOATS
Results are 268435456 bytes each, thus performing 64 iterations
Freed memory for dev 0
Uninitted cublas
done

Tested 1 GPUs:
        GPU 0: OK

micha@13900a MINGW64 /c/wse_github/gpu-burn (master)
$ vi Dockerfile

micha@13900a MINGW64 /c/wse_github/gpu-burn (master)
$ cat Dockerfile
ARG CUDA_VERSION=11.8.0
ARG IMAGE_DISTRO=ubi8

FROM nvidia/cuda:${CUDA_VERSION}-devel-${IMAGE_DISTRO} AS builder

WORKDIR /build

COPY . /build/

RUN make

FROM nvidia/cuda:${CUDA_VERSION}-runtime-${IMAGE_DISTRO}

COPY --from=builder /build/gpu_burn /app/
COPY --from=builder /build/compare.ptx /app/

WORKDIR /app

CMD ["./gpu_burn", "-tc", "120"]
#CMD ["./gpu_burn", "-d", "-tc", "120"]

micha@13900a MINGW64 /c/wse_github/gpu-burn (master)
$ docker build -t gpu-burn .
[+] Building 0.4s (14/14) FINISHED                                                                                docker:default
 => [internal] load build definition from Dockerfile                                                                                0.0s
 => => transferring dockerfile: 448B                                                                                0.0s
 => [internal] load .dockerignore                                                                                0.0s
 => => transferring context: 2B                                                                                0.0s
 => [internal] load metadata for docker.io/nvidia/cuda:11.8.0-runtime-ubi8                                                                              0.3s
 => [internal] load metadata for docker.io/nvidia/cuda:11.8.0-devel-ubi8                                                                                0.3s
 => [builder 1/4] FROM docker.io/nvidia/cuda:11.8.0-devel-ubi8@sha256:c135690bac108cafde387faf5bd4f3007bd7c2f21db9099b573b472941d8148c                  0.0s
 => [internal] load build context                                                                                0.0s
 => => transferring context: 2.62kB                                                                                0.0s
 => [stage-1 1/4] FROM docker.io/nvidia/cuda:11.8.0-runtime-ubi8@sha256:3f05c79f4d11badbb70a26a08bd95b6019be501d670da05977e382b04023b30e                0.0s
 => CACHED [builder 2/4] WORKDIR /build                                                                                0.0s
 => CACHED [builder 3/4] COPY . /build/                                                                                0.0s
 => CACHED [builder 4/4] RUN make                                                                                0.0s
 => CACHED [stage-1 2/4] COPY --from=builder /build/gpu_burn /app/                                                                                0.0s
 => CACHED [stage-1 3/4] COPY --from=builder /build/compare.ptx /app/                                                                                0.0s
 => CACHED [stage-1 4/4] WORKDIR /app                                                                                0.0s
 => exporting to image                                                                                0.0s
 => => exporting layers                                                                                0.0s
 => => writing image sha256:6b5d365fd9cd38a493e55b2226fbb4b5f9960fa47b1717d95c6bf553d8fc6f74                                                            0.0s
 => => naming to docker.io/library/gpu-burn                                                                                0.0s

What's Next?
  View summary of image vulnerabilities and recommendations → docker scout quickview

micha@13900a MINGW64 /c/wse_github/gpu-burn (master)
$ docker run --rm --gpus all gpu-burn

==========
== CUDA ==
==========

CUDA Version 11.8.0

Container image Copyright (c) 2016-2023, NVIDIA CORPORATION & AFFILIATES. All rights reserved.

This container image and its contents are governed by the NVIDIA Deep Learning Container License.
By pulling and using the container, you accept the terms and conditions of this license:
https://developer.nvidia.com/ngc/nvidia-deep-learning-container-license

A copy of this license is made available in this container at /NGC-DL-CONTAINER-LICENSE for your convenience.

GPU 0: NVIDIA RTX A4500 (UUID: GPU-898f04be-4440-1d50-e748-afe4f4f8abd0)
Using compare file: compare.ptx
Burning for 120 seconds.
11.7%  proc'd: 576 (52795 Gflop/s)   errors: 0   temps: 53 C
        Summary at:   Fri Aug 25 02:01:49 UTC 2023

22.5%  proc'd: 1216 (52087 Gflop/s)   errors: 0   temps: 60 C
        Summary at:   Fri Aug 25 02:02:02 UTC 2023

33.3%  proc'd: 1792 (51904 Gflop/s)   errors: 0   temps: 64 C
        Summary at:   Fri Aug 25 02:02:15 UTC 2023

44.2%  proc'd: 2432 (51441 Gflop/s)   errors: 0   temps: 68 C
        Summary at:   Fri Aug 25 02:02:28 UTC 2023

55.8%  proc'd: 3072 (51009 Gflop/s)   errors: 0   temps: 71 C
        Summary at:   Fri Aug 25 02:02:42 UTC 2023

65.8%  proc'd: 3648 (51027 Gflop/s)   errors: 0   temps: 72 C
        Summary at:   Fri Aug 25 02:02:54 UTC 2023

77.5%  proc'd: 4288 (50850 Gflop/s)   errors: 0   temps: 73 C
        Summary at:   Fri Aug 25 02:03:08 UTC 2023

89.2%  proc'd: 4928 (50397 Gflop/s)   errors: 0   temps: 74 C
        Summary at:   Fri Aug 25 02:03:22 UTC 2023

100.0%  proc'd: 5504 (50467 Gflop/s)   errors: 0   temps: 74 C
        Summary at:   Fri Aug 25 02:03:35 UTC 2023

100.0%  proc'd: 5568 (50563 Gflop/s)   errors: 0   temps: 74 C
Killing processes with SIGTERM (soft kill)
Using compare file: compare.ptx
Burning for 120 seconds.
Initialized device 0 with 20469 MB of memory (18956 MB available, using 17060 MB of it), using FLOATS, using Tensor Cores
Results are 268435456 bytes each, thus performing 64 iterations
Freed memory for dev 0
Uninitted cublas
done

Tested 1 GPUs:
        GPU 0: OK

micha@13900a MINGW64 /c/wse_github/gpu-burn (master)

dual RTX-A4500 and RTX-A4000
micha@13900a MINGW64 /c/wse_github/gpu-burn (master)
$ docker run --rm --gpus all gpu-burn

==========
== CUDA ==
==========

CUDA Version 11.8.0

Container image Copyright (c) 2016-2023, NVIDIA CORPORATION & AFFILIATES. All rights reserved.

This container image and its contents are governed by the NVIDIA Deep Learning Container License.
By pulling and using the container, you accept the terms and conditions of this license:
https://developer.nvidia.com/ngc/nvidia-deep-learning-container-license

A copy of this license is made available in this container at /NGC-DL-CONTAINER-LICENSE for your convenience.

GPU 0: NVIDIA RTX A4500 (UUID: GPU-898f04be-4440-1d50-e748-afe4f4f8abd0)
GPU 1: NVIDIA RTX A4000 (UUID: GPU-c585959e-3209-a20e-2522-e9420f268bc8)
Using compare file: compare.ptx
Burning for 120 seconds.
71.7%  proc'd: 0 (0 Gflop/s) - 24 (306 Gflop/s)   errors: 0 - 0   temps: 56 C - 67 C
        Summary at:   Fri Aug 25 02:24:51 UTC 2023

83.3%  proc'd: 31 (350 Gflop/s) - 24 (306 Gflop/s)   errors: 0 - 0   temps: 57 C - 69 C
        Summary at:   Fri Aug 25 02:25:05 UTC 2023

95.8%  proc'd: 31 (350 Gflop/s) - 24 (306 Gflop/s)   errors: 0 - 0   temps: 59 C - 70 C
        Summary at:   Fri Aug 25 02:25:20 UTC 2023

100.0%  proc'd: 31 (350 Gflop/s) - 24 (306 Gflop/s)   errors: 0 - 0   temps: 60 C - 71 C
Killing processes with SIGTERM (soft kill)

Killing processes with SIGKILL (force kill)
done

Tested 2 GPUs:
        GPU 0: OK
        GPU 1: OK

micha@13900a MINGW64 /c/wse_github/gpu-burn (master)
$ vi Dockerfile

micha@13900a MINGW64 /c/wse_github/gpu-burn (master)
$ docker build -t gpu-burn .
[+] Building 0.4s (14/14) FINISHED                                                                                docker:default
 => [internal] load build definition from Dockerfile                                                                                0.0s
 => => transferring dockerfile: 448B                                                                                0.0s
 => [internal] load .dockerignore                                                                                0.0s
 => => transferring context: 2B                                                                                0.0s
 => [internal] load metadata for docker.io/nvidia/cuda:11.8.0-runtime-ubi8                                                              0.3s
 => [internal] load metadata for docker.io/nvidia/cuda:11.8.0-devel-ubi8                                                                0.3s
 => [builder 1/4] FROM docker.io/nvidia/cuda:11.8.0-devel-ubi8@sha256:c135690bac108cafde387faf5bd4f3007bd7c2f21db9099b573b472941d8148c  0.0s
 => [stage-1 1/4] FROM docker.io/nvidia/cuda:11.8.0-runtime-ubi8@sha256:3f05c79f4d11badbb70a26a08bd95b6019be501d670da05977e382b04023b3  0.0s
 => [internal] load build context                                                                                0.0s
 => => transferring context: 2.62kB                                                                                0.0s
 => CACHED [builder 2/4] WORKDIR /build                                                                                0.0s
 => CACHED [builder 3/4] COPY . /build/                                                                                0.0s
 => CACHED [builder 4/4] RUN make                                                                                0.0s
 => CACHED [stage-1 2/4] COPY --from=builder /build/gpu_burn /app/                                                                      0.0s
 => CACHED [stage-1 3/4] COPY --from=builder /build/compare.ptx /app/                                                                   0.0s
 => CACHED [stage-1 4/4] WORKDIR /app                                                                                0.0s
 => exporting to image                                                                                0.0s
 => => exporting layers                                                                                0.0s
 => => writing image sha256:6b5d365fd9cd38a493e55b2226fbb4b5f9960fa47b1717d95c6bf553d8fc6f74                                            0.0s
 => => naming to docker.io/library/gpu-burn                                                                                0.0s

What's Next?
  View summary of image vulnerabilities and recommendations → docker scout quickview

micha@13900a MINGW64 /c/wse_github/gpu-burn (master)
$ docker run --rm --gpus all gpu-burn

==========
== CUDA ==
==========

CUDA Version 11.8.0

Container image Copyright (c) 2016-2023, NVIDIA CORPORATION & AFFILIATES. All rights reserved.

This container image and its contents are governed by the NVIDIA Deep Learning Container License.
By pulling and using the container, you accept the terms and conditions of this license:
https://developer.nvidia.com/ngc/nvidia-deep-learning-container-license

A copy of this license is made available in this container at /NGC-DL-CONTAINER-LICENSE for your convenience.

GPU 0: NVIDIA RTX A4500 (UUID: GPU-898f04be-4440-1d50-e748-afe4f4f8abd0)
GPU 1: NVIDIA RTX A4000 (UUID: GPU-c585959e-3209-a20e-2522-e9420f268bc8)
Using compare file: compare.ptx
Burning for 120 seconds.
10.8%  proc'd: 576 (51886 Gflop/s) - 400 (39447 Gflop/s)   errors: 0 - 0   temps: 64 C - 68 C
        Summary at:   Fri Aug 25 02:26:35 UTC 2023

21.7%  proc'd: 1152 (51415 Gflop/s) - 850 (38560 Gflop/s)   errors: 0 - 0   temps: 69 C - 76 C
        Summary at:   Fri Aug 25 02:26:48 UTC 2023

32.5%  proc'd: 1728 (50876 Gflop/s) - 1350 (37509 Gflop/s)   errors: 0 - 0   temps: 72 C - 79 C
        Summary at:   Fri Aug 25 02:27:01 UTC 2023

43.3%  proc'd: 2368 (50651 Gflop/s) - 1750 (37019 Gflop/s)   errors: 0 - 0   temps: 74 C - 81 C
        Summary at:   Fri Aug 25 02:27:14 UTC 2023

53.3%  proc'd: 2944 (50475 Gflop/s) - 2150 (36643 Gflop/s)   errors: 0 - 0   temps: 75 C - 82 C
        Summary at:   Fri Aug 25 02:27:26 UTC 2023

64.2%  proc'd: 3456 (50342 Gflop/s) - 2600 (36328 Gflop/s)   errors: 0 - 0   temps: 76 C - 83 C
        Summary at:   Fri Aug 25 02:27:39 UTC 2023

75.0%  proc'd: 4096 (50140 Gflop/s) - 3000 (36168 Gflop/s)   errors: 0 - 0   temps: 76 C - 83 C
        Summary at:   Fri Aug 25 02:27:52 UTC 2023

86.7%  proc'd: 4736 (49901 Gflop/s) - 3450 (36048 Gflop/s)   errors: 0 - 0   temps: 77 C - 84 C
        Summary at:   Fri Aug 25 02:28:06 UTC 2023

98.3%  proc'd: 5312 (49996 Gflop/s) - 3950 (35941 Gflop/s)   errors: 0 - 0   temps: 77 C - 84 C
        Summary at:   Fri Aug 25 02:28:20 UTC 2023

100.0%  proc'd: 5504 (49930 Gflop/s) - 4000 (35931 Gflop/s)   errors: 0 - 0   temps: 77 C - 84 C
Killing processes with SIGTERM (soft kill)
Using compare file: compare.ptx
Burning for 120 seconds.
Initialized device 1 with 16375 MB of memory (14897 MB available, using 13407 MB of it), using FLOATS, using Tensor Cores
Results are 268435456 bytes each, thus performing 50 iterations
Freed memory for dev 1
Uninitted cublas
Using compare file: compare.ptx
Burning for 120 seconds.
Initialized device 0 with 20469 MB of memory (18956 MB available, using 17060 MB of it), using FLOATS, using Tensor Cores
Results are 268435456 bytes each, thus performing 64 iterations
Freed memory for dev 0
Uninitted cublas
done

Tested 2 GPUs:
        GPU 0: OK
        GPU 1: OK

micha@13900a MINGW64 /c/wse_github/gpu-burn (master)
$ vi Dockerfile

micha@13900a MINGW64 /c/wse_github/gpu-burn (master)
$ docker build -t gpu-burn .
[+] Building 0.7s (14/14) FINISHED                                                                                docker:default
 => [internal] load .dockerignore                                                                                0.0s
 => => transferring context: 2B                                                                                0.0s
 => [internal] load build definition from Dockerfile                                                                                0.0s
 => => transferring dockerfile: 441B                                                                                0.0s
 => [internal] load metadata for docker.io/nvidia/cuda:11.8.0-runtime-ubi8                                                              0.5s
 => [internal] load metadata for docker.io/nvidia/cuda:11.8.0-devel-ubi8                                                                0.6s
 => [builder 1/4] FROM docker.io/nvidia/cuda:11.8.0-devel-ubi8@sha256:c135690bac108cafde387faf5bd4f3007bd7c2f21db9099b573b472941d8148c  0.0s
 => [stage-1 1/4] FROM docker.io/nvidia/cuda:11.8.0-runtime-ubi8@sha256:3f05c79f4d11badbb70a26a08bd95b6019be501d670da05977e382b04023b3  0.0s
 => [internal] load build context                                                                                0.0s
 => => transferring context: 2.62kB                                                                                0.0s
 => CACHED [builder 2/4] WORKDIR /build                                                                                0.0s
 => CACHED [builder 3/4] COPY . /build/                                                                                0.0s
 => CACHED [builder 4/4] RUN make                                                                                0.0s
 => CACHED [stage-1 2/4] COPY --from=builder /build/gpu_burn /app/                                                                      0.0s
 => CACHED [stage-1 3/4] COPY --from=builder /build/compare.ptx /app/                                                                   0.0s
 => CACHED [stage-1 4/4] WORKDIR /app                                                                                0.0s
 => exporting to image                                                                                0.0s
 => => exporting layers                                                                                0.0s
 => => writing image sha256:d79438766981c3c94306c18a225e4c873f36f05d7614a2d147016eb9947132f1                                            0.0s
 => => naming to docker.io/library/gpu-burn                                                                                0.0s

What's Next?
  View summary of image vulnerabilities and recommendations → docker scout quickview

micha@13900a MINGW64 /c/wse_github/gpu-burn (master)
$ docker run --rm --gpus all gpu-burn

==========
== CUDA ==
==========

CUDA Version 11.8.0

Container image Copyright (c) 2016-2023, NVIDIA CORPORATION & AFFILIATES. All rights reserved.

This container image and its contents are governed by the NVIDIA Deep Learning Container License.
By pulling and using the container, you accept the terms and conditions of this license:
https://developer.nvidia.com/ngc/nvidia-deep-learning-container-license

A copy of this license is made available in this container at /NGC-DL-CONTAINER-LICENSE for your convenience.

GPU 0: NVIDIA RTX A4500 (UUID: GPU-898f04be-4440-1d50-e748-afe4f4f8abd0)
GPU 1: NVIDIA RTX A4000 (UUID: GPU-c585959e-3209-a20e-2522-e9420f268bc8)
Using compare file: compare.ptx
Burning for 120 seconds.
12.5%  proc'd: 128 (14803 Gflop/s) - 100 (11846 Gflop/s)   errors: 0 - 0   temps: 44 C - 46 C
        Summary at:   Fri Aug 25 03:09:09 UTC 2023

24.2%  proc'd: 320 (14745 Gflop/s) - 300 (11604 Gflop/s)   errors: 0 - 0   temps: 53 C - 60 C
        Summary at:   Fri Aug 25 03:09:23 UTC 2023

36.7%  proc'd: 512 (14578 Gflop/s) - 450 (11177 Gflop/s)   errors: 0 - 0   temps: 60 C - 69 C
        Summary at:   Fri Aug 25 03:09:38 UTC 2023

49.2%  proc'd: 704 (14425 Gflop/s) - 600 (10972 Gflop/s)   errors: 0 - 0   temps: 65 C - 75 C
        Summary at:   Fri Aug 25 03:09:53 UTC 2023

61.7%  proc'd: 960 (14229 Gflop/s) - 700 (10754 Gflop/s)   errors: 0 - 0   temps: 69 C - 78 C
        Summary at:   Fri Aug 25 03:10:08 UTC 2023

74.2%  proc'd: 1152 (14075 Gflop/s) - 850 (10549 Gflop/s)   errors: 0 - 0   temps: 72 C - 80 C
        Summary at:   Fri Aug 25 03:10:23 UTC 2023

86.7%  proc'd: 1344 (14003 Gflop/s) - 1000 (10429 Gflop/s)   errors: 0 - 0   temps: 74 C - 81 C
        Summary at:   Fri Aug 25 03:10:38 UTC 2023

99.2%  proc'd: 1536 (13938 Gflop/s) - 1150 (10339 Gflop/s)   errors: 0 - 0   temps: 75 C - 82 C
        Summary at:   Fri Aug 25 03:10:53 UTC 2023

100.0%  proc'd: 1536 (13938 Gflop/s) - 1200 (10314 Gflop/s)   errors: 0 - 0   temps: 75 C - 83 C
Killing processes with SIGTERM (soft kill)
Using compare file: compare.ptx
Burning for 120 seconds.
Initialized device 0 with 20469 MB of memory (18956 MB available, using 17060 MB of it), using FLOATS
Results are 268435456 bytes each, thus performing 64 iterations
Freed memory for dev 0
Uninitted cublas
Using compare file: compare.ptx
Burning for 120 seconds.
Initialized device 1 with 16375 MB of memory (14897 MB available, using 13407 MB of it), using FLOATS
Results are 268435456 bytes each, thus performing 50 iterations
Freed memory for dev 1
Uninitted cublas
done

Tested 2 GPUs:
        GPU 0: OK
        GPU 1: OK

add dual RTX-4500
add single RTX-3500 on lenovo P1 Gen 6

micha@p1gen6 MINGW64 /c/wse_github/gpu-burn (master)
$ nvidia-smi
Mon Oct 30 19:48:43 2023
+---------------------------------------------------------------------------------------+
| NVIDIA-SMI 545.84                 Driver Version: 545.84       CUDA Version: 12.3     |
|-----------------------------------------+----------------------+----------------------+
| GPU  Name                     TCC/WDDM  | Bus-Id        Disp.A | Volatile Uncorr. ECC |
| Fan  Temp   Perf          Pwr:Usage/Cap |         Memory-Usage | GPU-Util  Compute M. |
|                                         |                      |               MIG M. |
|=========================================+======================+======================|
|   0  NVIDIA RTX 3500 Ada Gene...  WDDM  | 00000000:01:00.0 Off |                  Off |
| N/A   51C    P8               7W / 102W |    122MiB / 12282MiB |      0%      Default |
|                                         |                      |                  N/A |
+-----------------------------------------+----------------------+----------------------+

+---------------------------------------------------------------------------------------+

micha@p1gen6 MINGW64 /c/wse_github/gpu-burn (master)
$ docker run --rm --gpus all gpu_burn

==========
== CUDA ==
==========

CUDA Version 11.8.0

Container image Copyright (c) 2016-2023, NVIDIA CORPORATION & AFFILIATES. All rights reserved.

This container image and its contents are governed by the NVIDIA Deep Learning Container License.
By pulling and using the container, you accept the terms and conditions of this license:
https://developer.nvidia.com/ngc/nvidia-deep-learning-container-license

A copy of this license is made available in this container at /NGC-DL-CONTAINER-LICENSE for your convenience.

GPU 0: NVIDIA RTX 3500 Ada Generation Laptop GPU (UUID: GPU-25326b0f-ad93-c319-7027-b0029d4aee8e)
Using compare file: compare.ptx
Burning for 60 seconds.
13.3%  proc'd: 74 (11539 Gflop/s)   errors: 0   temps: 77 C
        Summary at:   Mon Oct 30 23:44:52 UTC 2023

25.0%  proc'd: 111 (11484 Gflop/s)   errors: 0   temps: 80 C
        Summary at:   Mon Oct 30 23:44:59 UTC 2023

36.7%  proc'd: 222 (11651 Gflop/s)   errors: 0   temps: 81 C
        Summary at:   Mon Oct 30 23:45:06 UTC 2023

48.3%  proc'd: 296 (11519 Gflop/s)   errors: 0   temps: 81 C
        Summary at:   Mon Oct 30 23:45:13 UTC 2023

61.7%  proc'd: 370 (11379 Gflop/s)   errors: 0   temps: 83 C
        Summary at:   Mon Oct 30 23:45:21 UTC 2023

75.0%  proc'd: 444 (12958 Gflop/s)   errors: 0   temps: 85 C
        Summary at:   Mon Oct 30 23:45:29 UTC 2023

86.7%  proc'd: 555 (12996 Gflop/s)   errors: 0   temps: 85 C
        Summary at:   Mon Oct 30 23:45:36 UTC 2023

100.0%  proc'd: 629 (13163 Gflop/s)   errors: 0   temps: 85 C
        Summary at:   Mon Oct 30 23:45:44 UTC 2023

100.0%  proc'd: 666 (13124 Gflop/s)   errors: 0   temps: 85 C
Killing processes with SIGTERM (soft kill)
Using compare file: compare.ptx
Burning for 60 seconds.
Initialized device 0 with 12281 MB of memory (11119 MB available, using 10007 MB of it), using FLOATS
Results are 268435456 bytes each, thus performing 37 iterations
Freed memory for dev 0
Uninitted cublas
done

Tested 1 GPUs:
        GPU 0: OK

running with -d

micha@p1gen6 MINGW64 /c/wse_github/gpu-burn (master)
$ docker run --rm --gpus all gpu_burn

==========
== CUDA ==
==========

CUDA Version 11.8.0

Container image Copyright (c) 2016-2023, NVIDIA CORPORATION & AFFILIATES. All rights reserved.

This container image and its contents are governed by the NVIDIA Deep Learning Container License.
By pulling and using the container, you accept the terms and conditions of this license:
https://developer.nvidia.com/ngc/nvidia-deep-learning-container-license

A copy of this license is made available in this container at /NGC-DL-CONTAINER-LICENSE for your convenience.

GPU 0: NVIDIA RTX 3500 Ada Generation Laptop GPU (UUID: GPU-25326b0f-ad93-c319-7027-b0029d4aee8e)
Using compare file: compare.ptx
Burning for 60 seconds.

Killing processes with SIGTERM (soft kill)

Killing processes with SIGKILL (force kill)
done

running with -tc tensor cores

GPU 0: NVIDIA RTX 3500 Ada Generation Laptop GPU (UUID: GPU-25326b0f-ad93-c319-7027-b0029d4aee8e)
Using compare file: compare.ptx
Burning for 120 seconds.
10.8%  proc'd: 444 (39682 Gflop/s)   errors: 0   temps: 74 C
        Summary at:   Tue Oct 31 00:03:17 UTC 2023

21.7%  proc'd: 888 (39301 Gflop/s)   errors: 0   temps: 78 C
        Summary at:   Tue Oct 31 00:03:30 UTC 2023

32.5%  proc'd: 1369 (38544 Gflop/s)   errors: 0   temps: 81 C
        Summary at:   Tue Oct 31 00:03:43 UTC 2023

43.3%  proc'd: 1813 (38330 Gflop/s)   errors: 0   temps: 83 C
        Summary at:   Tue Oct 31 00:03:56 UTC 2023

53.3%  proc'd: 2257 (40833 Gflop/s)   errors: 0   temps: 82 C
        Summary at:   Tue Oct 31 00:04:08 UTC 2023

64.2%  proc'd: 2738 (45627 Gflop/s)   errors: 0   temps: 83 C
        Summary at:   Tue Oct 31 00:04:21 UTC 2023

75.0%  proc'd: 3256 (44635 Gflop/s)   errors: 0   temps: 82 C
        Summary at:   Tue Oct 31 00:04:34 UTC 2023

85.8%  proc'd: 3811 (45740 Gflop/s)   errors: 0   temps: 82 C
        Summary at:   Tue Oct 31 00:04:47 UTC 2023

96.7%  proc'd: 4329 (46204 Gflop/s)   errors: 0   temps: 83 C
        Summary at:   Tue Oct 31 00:05:00 UTC 2023

100.0%  proc'd: 4551 (45895 Gflop/s)   errors: 0   temps: 82 C
Killing processes with SIGTERM (soft kill)
Using compare file: compare.ptx
Burning for 120 seconds.
Initialized device 0 with 12281 MB of memory (11119 MB available, using 10007 MB of it), using FLOATS, using Tensor Cores
Results are 268435456 bytes each, thus performing 37 iterations
Freed memory for dev 0
Uninitted cublas
done

Tested 1 GPUs:
        GPU 0: OK


MEC028 (wais) v2.1.10 update and StaDataRate subscription

MEC028 update with 2.1.10 data structures and endpoints

compile previous code and report notification as it used to
need a follow-up update to have the notification matching the new subscription triggers and threshold (subscription behavior changed'
added staDataRate subscription

SBI updates to track apps under a UE
update to the code to get the downlink and uplink traffic from the metric store
storage of the downlink and uplink metrics
notification based on updates to the scenario (same as assocStaNotification). Valid but missing the periodic trigger (to be done as part of the assocSta update - same periodic trigger)

testing

scenario using wifi POAs, notification generated as expected based on triggers
ran the current system test (passed).

Code update

lots of file changed caused by the new yaml file being generated
real changes limited to :
go-apps/meep-wais/sbi/wais-sbi.go
go-apps/meep-wais/server/wais.go
go-apps/meep-wais/server/wais_test.go
go-apps/meep-wais/server/convert.go
go-apps/meep-wais/api/swagger.yaml
test/system/wais_test.go

Also, please rebase this branch to the tip of develop.


ghcHEAD: bump to 8.11.20200403

Motivation for this change
Things done

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

[x] NixOS
[x] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
[ ] Tested execution of all binary files (usually in ./result/bin/)
[ ] Determined the impact on package closure size (by running nix path-info -S before and after)
[ ] Ensured that relevant documentation is up to date
[x] Fits CONTRIBUTING.md.

@GrahamcOfBorg build haskell.compiler.ghcHEAD

@GrahamcOfBorg build ocaml-ng.ocamlPackages_4_09

@ggreif Is this ready to be merged in?

@cdepillabout I guess so. We can iterate if something is missing.


when I run I get this error

ModuleNotFoundError: No module named 'requests
running python 3.7.3

pip install requests should resolve your problem for now. You'll probably need websocket-client module as well.
The issue with not downloading dependencies during pip install was fixed in #2, but an older version is on the pypi. @lucien2k could you publish a new one?

Should be fixed with the new release


AUTHORS.md link broken in TRG2.03

The AUTHORS.md example file referenced in release guideline TRG2.03 link is broken. It points to a .md file, but the file itself is present as .txt

Inthink that @carslen already fixed the Typo

Typo was fixed, but the link is broken, True.


containerapp-preview fix validate and register provider

This checklist is used to make sure that common guidelines for a pull request are followed.

For new extensions:

[ ] My extension description/summary conforms to the Extension Summary Guidelines.

About Extension Publish
There is a pipeline to automatically build, upload and publish extension wheels.
Once your pull request is merged into main branch, a new pull request will be created to update src/index.json automatically.
You only need to update the version information in file setup.py and historical information in file HISTORY.rst in your PR but do not modify src/index.json.

Thank you for your contribution! We will review the pull request and get back to you soon.

Hi @zhoxing-ms
Could you help to review and merge this small PR? Thanks.


Add grype to arkade get

Signed-off-by: Maria Kotlyarevskaya<EMAIL_ADDRESS>
Description

add grype to arkade get
Motivation and Context

[x] I have raised an issue to propose this change, which has been given a label of design/approved by a maintainer (required)
fixes #839

How Has This Been Tested?

./hack/test-tool.sh grype
+ go build
+ ./arkade get grype --arch arm64 --os darwin --quiet
+ file /Users/mariarti/.arkade/bin/grype
/Users/mariarti/.arkade/bin/grype: Mach-O 64-bit executable arm64
+ rm /Users/mariarti/.arkade/bin/grype
+ ./arkade get grype --arch x86_64 --os darwin --quiet
+ file /Users/mariarti/.arkade/bin/grype
/Users/mariarti/.arkade/bin/grype: Mach-O 64-bit executable x86_64
+ rm /Users/mariarti/.arkade/bin/grype
+ ./arkade get grype --arch x86_64 --os linux --quiet
+ file /Users/mariarti/.arkade/bin/grype
/Users/mariarti/.arkade/bin/grype: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), statically linked, Go BuildID=VvVEZ6t7dqTR2KRdYfl9/cfJ7_Cvox1A57purDE24/j140wad_3vn-lly4MwQO/DN8lLgIFt99ypL_SpR-s, stripped
+ rm /Users/mariarti/.arkade/bin/grype
+ ./arkade get grype --arch arm64 --os linux --quiet
+ file /Users/mariarti/.arkade/bin/grype
/Users/mariarti/.arkade/bin/grype: ELF 64-bit LSB executable, ARM aarch64, version 1 (SYSV), statically linked, Go BuildID=cJly8Cb_3Je_-kkJdces/HWPDE-5idR3v3QkaXAYx/aD8_QtFYTWuOsnteFnVr/XEQrbeh9aojEMue3IJaT, stripped
+ rm /Users/mariarti/.arkade/bin/grype
+ ./arkade get grype --arch x86_64 --os ming --quiet
+ file /Users/mariarti/.arkade/bin/grype
/Users/mariarti/.arkade/bin/grype: ELF 64-bit LSB executable, ARM aarch64, version 1 (SYSV), statically linked, Go BuildID=cJly8Cb_3Je_-kkJdces/HWPDE-5idR3v3QkaXAYx/aD8_QtFYTWuOsnteFnVr/XEQrbeh9aojEMue3IJaT, stripped
+ rm /Users/mariarti/.arkade/bin/grype

Are you a GitHub Sponsor yet (Yes/No?)

[ ] Yes
[x] No

Types of changes

[ ] Bug fix (non-breaking change which fixes an issue)
[x] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to change)

Documentation

[x] I have updated the list of tools in README.md if (required) with ./arkade get -o markdown
[ ] I have updated the list of apps in README.md if (required) with ./arkade install --help

Checklist:

[x] My code follows the code style of this project.
[x] My change requires a change to the documentation.
[x] I have updated the documentation accordingly.
[x] I've read the CONTRIBUTION guide
[x] I have signed-off my commits with git commit -s

[x] I have tested this on arm, or have added code to prevent deployment

Lgtm. For some reason I thought they didn't have a Windows binary for grype.


Add Scan and UnmarshalWKB methods

Scan implements the sql.Scanner interface allowing points, lines, point sets and paths to be passed into rows.Scan(…interface{}) calls. This simplifies working with the database a long.
Basically allows you to do stuff like
row := db.QueryRow("SELECT AsBinary(point_column) FROM table")

var p *geo.Point
row.Scan(&p)

Note that you need to wrap the column in AsBinary
@mlerner

I'm currently debating if the .Scan methods are useful or confusing since you have to wrap the stuff in AsBinary. Also, unmarshal is pretty annoying since you have to make sure the stuff isn't nil. An alternate approach:
row, _ := db.Query("SELECT point_column FROM table")
row.Next()
defer row.Close()

var raw sql.RawData
row.Scan(&raw)
p, _ := geo.NewPointFromWKB(raw[4:])

Updated as discussed in the previous comment. There are now NewPointFromWKB, NewLineFromWKB, etc. methods.
Scan now supports WKB or mysqls SRID+WKB encoding. See the updates to the readme for more details.


Conversation window textarea should be submittable with keyboard

Right now, you have to press "Ask" using the mouse. Would be nice if you can press enter to send the message, and use shift+enter to add new lines, just like the message box on chat.openai.com works.
Another suggestion is to keep the current behavior but send the message using shift+enter.

@alexanderzinolidis thanks for the valuable feedbacks! Much appreciated. I released a new version with Enter to submit question, Shift+Enter to grow into a new line. Check out v1.1.3 on store, it's rolling out!


Training example command for NYU Depth v2

Dear author:
Could you provide the example commond to train the model on NYU Depth v2 like KITTI.
like :
$ python main.py --dir_data datta_path --data_name KITTIDC --split_json ../data_json/kitti_dp.json
--patch_height 352 --patch_width 906 --gpus 0,1,2,3 --loss 1.0L1+1.0L2+1.0*DDIM --epochs 30
--batch_size 8 --max_depth 88.0 --save NAME_TO_SAVE
--model_name Diffusion_DCbase_ --backbone_module swin --backbone_name swin_large_naive_l4w722422k --head_specify DDIMDepthEstimate_Swin_ADDHAHI
Thank you!

Hi, sorry for the late reply due to busy days.
You might be interested in https://github.com/duanyiqun/DiffusionDepth/issues/9 for this issue I think the command is ok. But still, I recommend implementing it on Kitti first as it is more stable.


name 'Ngrams' is not defined

I can't replicate the code. When I tried to run !bash scripts/run_AMI.sh, it throws the following error:

Does anyone know why this happens? Thanks :)

solved
#2

Solved by looking at previous issues.


Increment version for monitor releases

Increment package version after release of Azure.ResourceManager.Monitor

API change check
API changes are not detected in this pull request.

Failures are unrelated to these changes; merging.


Explore structured editor for Marlowe

Explore the feasibility of a structured editor for Marlowe that is half-way between plan text and blockly, and that supports function definitions and automated refactorings.

Explored


Support id_token grant flow

Feature request
Is your feature request related to a problem? Please describe.
A new way of signing users in via OAuth was introduced with this PR of gotrue. It would be nice if we could add a way of utilizing this endpoint with this library so that native apps built with react native could utilize it.
Describe the solution you'd like
OAuth sign in flow on native apps should use POST /token?grant_type=id_token end point to sign in.
Describe alternatives you've considered
Currently OAuth sign in is possible by redirecting the user to web view from a native app.
Additional context
N/A

@dshukertjr Hi Tyler, do you know when this feature will be integrated? or do you have a rough timeline? thanks in advance, Andy

@megacherry Great question!
@kiwicopple Now that the backend is ready for this, do we have anything else that needs to be in place before we add this feature to the client?

cc @kangmingtay

@dshukertjr Do you have any new information about this issue? :)

@kiwicopple @kangmingtay @phamhieu @dshukertjr @megacherry
I have created a pull request that resolves this issue.
Please review and merge.

It looks like your pr was merged in ? Should this be closed now?
@koba-ninkigumi

Closing as this is already supported.


Dist by env tagging issue fix

Dist by env tagging issue fix

 Thank you for your submission, we really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.Kanchana seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account.You have signed the CLA already but the status is still pending? Let us recheck it.

this has merge conflict , please fix.

this has merge conflict , please fix.

Done!!


Block forge should check for pending future blocks in ChainDB

The ChainDB only processes blocks it set aside as future blocks the next time a block is added. From the report:

In a way, calls to addBlock are how the chain database sees time advance.

Suppose we receive a block B that is slightly in the future, then idle long enough for B to no longer be in the future, and then forge a new block. Since we didn't receive any blocks after idling, we will not forge on top of B.
Since leadership opportunities are precious, we wouldn't want to squander one like that: forging on top of B would have made a more competitive block.

I think we can let this be closed by #525 :+1:, as this scenario will not arise anymore.

Closing. Yeah, PR 525 should prevent this.


IProtocol abstraction / Application facing interface

is there a common pattern to express HttpApplication, MqttApplication and others?
for me it is about transforming  IDuplexPipe to IProtocol. What I think of is:
public interface IProtocol<TRequest,TResponse>
  {
    ChannelReader<TRequest> Input { get; }
    ChannelWriter<TResponse> Output { get; }
  }

public interface IProtocol<TMsg> : IProtocol<TMsg,TMsg>
  {
  }

or maybe

@JanEggers you're onto something there and I've had ideas about this for a while. Do you want to help spike this idea?
public interface IProtocol<TRequest, TResponse>
{
    ChannelReader<TRequest> Input { get; }
    ChannelWriter<TResponse> Output { get; }
}

We should spike some implementations to see how that interface holds up against some real protocols.

Do you want to help spike this idea?

sure

Some things to think about:

If we use Channels, are they bounded (they need to be).
With this model, you have to allocate request object before reading and a response type object before writing (they would be hard to pool as well because it's hard to know when you're done with it).
Do you lose the connection object or is it still around? (If not, how do you abort or get access to other features etc).

With this model, you have to allocate request object before reading and a response type object before writing (they would be hard to pool as well because it's hard to know when you're done with it).

More general how should request and response be implemented? right now in mqttnet they are regular classes with strings and and possilbly nested object Properties. so there are also allocations inside the msg not just the msg itself. And there is some cpu wasted for string encoding even if it is not sure if the user code needs to have that data as a string.
If you aim for zero allocations the messages need to be ref structs that just slices up the spans.
And with that approach we cannot use channels because ref structs dont like async.
Another issue at least for mqtt are var int encoded parts of the header and in v5 also in the body, so during write I have to write the body before knowing the length, so I cannot directly write the response in the pipe but have to use intermidiate buffers.

Do you lose the connection object or is it still around? (If not, how do you abort or get access to other features etc).

I think the connection object is very usefull so it should stick around. I was thinking that just adding a Protocol Property that exposes the interface should be fine.

More general how should request and response be implemented? right now in mqttnet they are regular classes with strings and and possilbly nested object Properties. so there are also allocations inside the msg not just the msg itself. And there is some cpu wasted for string encoding even if it is not sure if the user code needs to have that data as a string.

That's a choice of a specific Request/Response type.

If you aim for zero allocations the messages need to be ref structs that just slices up the spans.
And with that approach we cannot use channels because ref structs dont like async.

Not zero allocations , but zero allocations amortized. So the ability to pool and reuse objects is important even if the default implementation doesn't do that. It might be possible by adding a dispose to the Request/Response object.

Another issue at least for mqtt are var int encoded parts of the header and in v5 also in the body, so during write I have to write the body before knowing the length, so I cannot directly write the response in the pipe but have to use intermidiate buffers.

This is a solution to that https://github.com/AArnott/Nerdbank.Streams/blob/9d1df2ab1d3699988a23183913dfdaf19eaf3891/doc/PrefixingBufferWriter.md.

I think the connection object is very usefull so it should stick around. I was thinking that just adding a Protocol Property that exposes the interface should be fine.

👍

This is a solution to that https://github.com/AArnott/Nerdbank.Streams/blob/9d1df2ab1d3699988a23183913dfdaf19eaf3891/doc/PrefixingBufferWriter.md.

that is a fixed int prefix mqtt has var int
http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/os/mqtt-v3.1.1-os.html#_Table_2.4_Size

@davidfowl hi I pulled in your bits into mqttnet, and the Protocol & tcp client work like a charm:
https://github.com/JanEggers/MQTTnet/tree/aspnetcore3/Source/MQTTnet.AspnetCore
I had some issues in the process:

I used the mqtt connection handler from the server in the client that deadlocked connect.
also using the handler returned the builder as IConnectionBuilder so Build returned a connectiondelegate => maybe rename Client.Build() to Client.BuildClient() or factor that different.

Great! That looks awesome!

Hey @JanEggers I pushed this to a nuget feed so you can avoid using the project reference for now https://github.com/davidfowl/BedrockFramework#using-ci-builds.

thx for letting me know. and have nice holidays

nice move on moving it to nuget, I'm using it in a project I just started a couple of weeks ago
https://github.com/MithrilMan/MithrilShards
specifical implementation at https://github.com/MithrilMan/MithrilShards/tree/master/src/MithrilShards.Network.Bedrock
As a note, I think would be nice to have an explicit method to override from ConnectionHandler to catch peer disconnection, so other than
public abstract Task OnConnectedAsync(ConnectionContext connection);
we should have a public abstract Task OnDisconnectedAsync(ConnectionContext connection, Exception ex);
not sure if the exception should be there or in ConnectionContext, but the logic is that at application level I should be able to catch connection exception caused by the other part that dropped the connection in order to handle such case (I could catch it probably in OnConnectAsync but to me it doesn't sounds the right place
P.S.
good job on this library, is it planned to be merged into next dotnet core release somehow?

nice move on moving it to nuget, I'm using it in a project I just started a couple of weeks ago
https://github.com/MithrilMan/MithrilShards
specifical implementation at https://github.com/MithrilMan/MithrilShards/tree/master/src/MithrilShards.Network.Bedrock

Nice!! I need to iterate on the interface a bit since it forces allocations today. There needs to be a protocol reader interface that either returns a disposable or has an Advance method on it. I hope to get feedback for this.

As a note, I think would be nice to have an explicit method to override from ConnectionHandler to catch peer disconnection, so other than
public abstract Task OnConnectedAsync(ConnectionContext connection);
we should have a public abstract Task OnDisconnectedAsync(ConnectionContext connection, Exception ex);

This could be built on top. Right now the lowest level is basically a single call and when that task completes.

good job on this library, is it planned to be merged into next dotnet core release somehow?

Thanks! This is my playground to figure out what is useful to people. I'm not sure if all of it will make it into .NET Core but hopefully some of the core abstractions will at some point.


Error upgrading DataTable with Vite from 1.7.17 to 7.5.1

Describe the bug
I updated Mantine-DataTable from 1.7.17 to 7.5.1 I have the following error
Error: @mantine/core: MantineProvider was not found in component tree, make sure you have it in your app
at useMantineTheme (http://localhost:5173/node_modules/.vite/deps/mantine-datatable.js?v=af5e2253:3067:11)
at http://localhost:5173/node_modules/.vite/deps/mantine-datatable.js?v=af5e2253:4293:19
at renderWithHooks (http://localhost:5173/node_modules/.vite/deps/chunk-GVSLPJMJ.js?v=af5e2253:12171:26)
at updateForwardRef (http://localhost:5173/node_modules/.vite/deps/chunk-GVSLPJMJ.js?v=af5e2253:14327:28)
at beginWork (http://localhost:5173/node_modules/.vite/deps/chunk-GVSLPJMJ.js?v=af5e2253:15934:22)
at beginWork$1 (http://localhost:5173/node_modules/.vite/deps/chunk-GVSLPJMJ.js?v=af5e2253:19749:22)
at performUnitOfWork (http://localhost:5173/node_modules/.vite/deps/chunk-GVSLPJMJ.js?v=af5e2253:19194:20)
at workLoopSync (http://localhost:5173/node_modules/.vite/deps/chunk-GVSLPJMJ.js?v=af5e2253:19133:13)
at renderRootSync (http://localhost:5173/node_modules/.vite/deps/chunk-GVSLPJMJ.js?v=af5e2253:19112:15)
at recoverFromConcurrentError (http://localhost:5173/node_modules/.vite/deps/chunk-GVSLPJMJ.js?v=af5e2253:18732:28)
To Reproduce
Steps to reproduce the behavior:
Upgrade from 1.7.17 to 7.5.1
Project was working but I upgrade to the new one

Go to '...'
Click on '....'
Scroll down to '....'
See error

OS: MacOS Sonoma
Browser Chrome
Version latest

Additional context
Using a template Vristo

Please feel free to reopen if you can come up with a reproduction.
Thanks.


2-minute intro video front screen has typo

The intro video you get when you first connect to mldb Community edition says "Notebook Interfacd".
I know - really minor bug - but first impressions are important!

Good catch. Fixed on youtube. It'll take a few hours to take effect due to caching.


Downplay cost of calling between JS <--> wasm

In https://rustwasm.github.io/book/game-of-life/implementing.html#interfacing-rust-and-javascript we describe calling between wasm and JS as something that is potentially expensive and that one should try and minimize. My understanding is that this may be unnecessary now, and that all engines have low-overhead paths for these calls.
@bnjbvr, maybe you can say a little more about this and confirm/deny it? Do you have any suggested edits to point (3) in the section linked above? Thanks!

It's an old caveat that doesn't quite apply today, at least in Chrome and Firefox. I haven't tested recently in Edge nor Safari. For instance on Firefox, recent work has made most calls from JS to wasm as well as the other direction fast enough in most cases (from Firefox 60). While there's still room for relative improvement (monomorphic optimizations, cross-world inlining which is harder to accomplish), we're in a better place and I don't think we should recommend to limit those calls anymore. If there's a case where the calls are very slow, it is likely to be a bug.

Mentoring Instructions:

Identify every place mentioning JS <-> wasm calls
Remove them
Smooth out wording in surrounding areas so that the flow of the article doesn't feel off.

Point 3 is likely the hardest part and the easiest way to do so is to reread the article after 2 is completed and smoothing over any part that feels off

As mentioned in the pull comments, 3) didn't seem like a problem if the offending paragraphs were removed. Also, couldn't find anymore mentions that seemed related.

Perfect thanks @alfiedotwtf! I think we can consider this closed and if there's anything unclear we can open up separate issues.

Thanks for enlightening us @bnjbvr :)


mp_init autocorrect option

The autocorrect option set in the mp_init macro is set to allow misspellings when the intent is to prevent this correction.

Goodness gracious - quite right!  We have options autocorrect when in fact options noautocorrect was the intent.  Thanks for raising!
Sticking the ref to the docs here:  https://support.sas.com/documentation/cdl/en/lesysoptsref/64892/HTML/default/viewer.htm#p0mzulmnthqs2bn1cuqm5eqlvgi8.htm

:tada: This issue has been resolved in version 2.58.3 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


Can't build 4.8-20200211-windowsservercore-ltsc2019 with provided Dockerfile

Steps to reproduce the issue

Download the 4.8-20200211-windowsservercore-ltsc2019 docker file provided on https://hub.docker.com/_/microsoft-dotnet-framework-sdk/
docker build . -t test

Expected behavior
Builds the image
Actual behavior
Fails with
The system cannot find the path specified.

The 1909 docker image from the same page builds fine on the same Win10 machine, both with process- and HyperV isolation.
Output of docker version
On LTSC server;
Client: Docker Engine - Enterprise
Version:           19.03.5
API version:       1.40
Go version:        go1.12.12
Git commit:        2ee0c57608
Built:             11/13/2019 08:00:16
OS/Arch:           windows/amd64
Experimental:      false
Server: Docker Engine - Enterprise
Engine:
Version:          19.03.5
API version:      1.40 (minimum version 1.24)
Go version:       go1.12.12
Git commit:       2ee0c57608
Built:            11/13/2019 07:58:51
OS/Arch:          windows/amd64
Experimental:     false
Output of docker info
Client:
Debug Mode: false
Plugins:
cluster: Manage Docker clusters (Docker Inc., v1.2.0)
Server:
Containers: 1
Running: 0
Paused: 0
Stopped: 1
Images: 12
Server Version: 19.03.5
Storage Driver: windowsfilter
Windows:
Logging Driver: json-file
Plugins:
Volume: local
Network: ics internal l2bridge l2tunnel nat null overlay private transparent
Log: awslogs etwlogs fluentd gcplogs gelf json-file local logentries splunk syslog
Swarm: inactive
Default Isolation: process
Kernel Version: 10.0 17763 (17763.1.amd64fre.rs5_release.180914-1434)
Operating System: Windows Server 2019 Datacenter Version 1809 (OS Build 17763.1039)
OSType: windows
Architecture: x86_64
CPUs: 2
Total Memory: 8GiB
Name: dhbuildagent
ID: R3LH:OBL2:RCLG:SH6C:A74U:OVJP:XTIM:PPKP:MBLN:PVZK:4TYV:GUHW
Docker Root Dir: C:\ProgramData\docker
Debug Mode: false
Registry: https://index.docker.io/v1/
Labels:
Experimental: false
Insecure Registries:
<IP_ADDRESS>/8
Live Restore Enabled: false

I just copied that Dockerfile to a new 2019 server VM in Azure and it's building fine for me.  Have you tried splitting out that RUN command into separate statements to isolate which command is actually causing the error?

Tested with a local host server and an azure host server, both ltsc and both failed. When both were patched up to current, the local machine can now build the dockerfile without a problem while the azure machine still can't. Odd.

Nevertheless, it seems the patch level of the host has at least some effect, so I'll close this since the problem does not seem to be in the Dockerfile itself. I have some research to do to before possibly getting back with more info :)

This was the problem;
https://support.microsoft.com/en-us/help/4542617/you-might-encounter-issues-when-using-windows-server-containers-with-t


Code flow  and automatic refresh token

I have been banging my head against this for many hours now and would appreciate some direction.
The setup:

issuer: IdentityServer4
client: Angular9 app
back end API: many containerized, mostly .NET webapi core

Config excerpt:
responseType: 'code',
scope: 'openid profile email roles offline_access [...some more private]',

configure method:
private configure() {
    this.oauthService.configure(authConfig);
    this.oauthService.tokenValidationHandler = new JwksValidationHandler();
    this.oauthService.loadDiscoveryDocumentAndTryLogin();
    this.oauthService.setupAutomaticSilentRefresh();
  }

Problem
Using code flow and not a problem to login with a user and to actually enforce the authorization both in client and back end by roles.
However, refreshing the token fails always and the behavior is 'strange' in my opinion.
The client tries refreshing with two different refresh tokens consecutively and I receive two responses (see debugging log):
refresh tokenResponse
angular-oauth2-oidc.js:761
Object {id_token: "eyJhbGciOiJSUzI1NiIsImtpZCI6IlV4NE5tOXhBQ0JyNVE0N2…", access_token: "eyJhbGciOiJSUzI1NiIsImtpZCI6IlV4NE5tOXhBQ0JyNVE0N2…", expires_in: 3600, token_type: "Bearer", refresh_token: "SOcPcu1GPcuM08Y1B1udzo3NJKYV4KLBhoqdUmfDWvo", …}
angular-oauth2-oidc.js:761
refresh tokenResponse
angular-oauth2-oidc.js:761
Object {id_token: "eyJhbGciOiJSUzI1NiIsImtpZCI6IlV4NE5tOXhBQ0JyNVE0N2…", access_token: "eyJhbGciOiJSUzI1NiIsImtpZCI6IlV4NE5tOXhBQ0JyNVE0N2…", expires_in: 3600, token_type: "Bearer", refresh_token: "iucZ4iJPKKXMx23zNUqbxEhontiPIXVTJHDf7aOW-5g", …}

The idtoken and the accesstoken are similar but the refresh is not. These request are sent one after the other (straight).
Then, I get two failures in a row:
Failed to load resource: the server responded with a status of 400 (Bad Request) [....omitted...]
Error performing password flow
angular-oauth2-oidc.js:1358
HttpErrorResponse {headers: HttpHeaders, status: 400, statusText: "Bad Request", url: "...omitted...", ok: false, …}
angular-oauth2-oidc.js:1358
Automatic silent refresh did not work
angular-oauth2-oidc.js:761
Failed to load resource: the server responded with a status of 400 (Bad Request) [...omitted...]
Error performing password flow
angular-oauth2-oidc.js:1358
HttpErrorResponse {headers: HttpHeaders, status: 400, statusText: "Bad Request", url: "....omitted...", ok: false, …}
angular-oauth2-oidc.js:1358
Automatic silent refresh did not work

Note the error 'Error performing password flow', which I am not sure is just a funny in the loging or it is actually trying a password flow... because IdentityServer4 is not complaining about the password flow but about the token not existing...
[2020-02-15T13:28:43.2741552+00:00][DBUG][31][IdentityServer4.EntityFramework.Stores.PersistedGrantStore] "zeIPcnCv0o9OAQ8bBK8J0YHKnX5I9JG8lDpRAPwSPyw=" found in database: False
[2020-02-15T13:28:43.2742509+00:00][DBUG][31][IdentityServer4.Stores.DefaultRefreshTokenStore] "refresh_token" grant with value: "iucZ4iJPKKXMx23zNUqbxEhontiPIXVTJHDf7aOW-5g" not found in store.
[2020-02-15T13:28:43.2743632+00:00][WARN][31][IdentityServer4.Validation.TokenValidator] Invalid refresh token
[2020-02-15T13:28:43.2747049+00:00][WARN][31][IdentityServer4.Validation.TokenRequestValidator] Refresh token validation failed.

Which I believe it is in the db.
Finally, at some point, the client will not be able to access the back end with the error ' Token expired'
However, the client is still working fine with the user logged in. If I logout and login again, or simply send a login again (without actually logout), I will have access to the back end again since my new token is fresh.
Please, any advice or lead for me to be able to progress?

As a thought, maybe #682 is related?

@aznarepse
try a different order for your setup sequence. I found a suggestion in another issue that worked for me. I use code flow and identityserver also for a demo and I can see the refresh happening in the console. However this version is still and Angular8 version though.
this.oauthService.configure(authConfig);
this.oauthService.setupAutomaticSilentRefresh();
this.oauthService.tokenValidationHandler = new JwksValidationHandler();
this.oauthService.loadDiscoveryDocumentAndTryLogin()

you can see the refresh token happening in the console for my demo

@jeroenheijmans
Possibly. However, see below as thebaron24 suggestion seems to work around it.
I have it now running in a testing environment (compiles as production) and the messages are more explicit:

The response from the server: {"error":"invalid_grant"}
The error logged in the console: Error performing password flow Md {headers: Ad, status: 400, statusText: "OK", url: ...

Odly, thebaron24's suggestion seems to work... spooky!
@thebaron24
Indeed! Thank you sir! Good for now.

Nice, good to hear you solved things, thanks for sharing!

@jeroenheijmans
Well, it is working.
However, I still think it is a bit odd behavior and the work around a bit voodoo.
I am rather new to Angular but I'll be happy to do some debugging if you lead me in the right direction around the library code to focus on this subject.

Maybe @thebaron24 has some suggestions on that? We could re-open or open a fresh issue if the docs need brushing up, or if we know we should explicitly throw an error under some configuration circumstances....

@aznarepse
I think conceptually it makes sense to set up the refresh flow before you get the discovery document and init the login flow. It looks like the majority of people were using this package in the implicit flow and as things are moving towards the code from with PKCE we are seeing some gaps in the documentation. I had a difficult time setting up a nodejs based server side rendering with universal also because the documentation pointed to an angular 5 version using .net as the server side tech.
However, the source code viewer they have set up was what saved me:
for example the auth service source and people who hover int he issues section are pretty helpful :)
I think the only suggestion I have would be what you already said - update the documentation to reflect this order because anyone who used this would probably want to setup short term token refresh like this.

Ah, that comments helps me see the actual issue 😅. In that case, in my flow I also set up the listener way before I run the initial login sequence with the disco document.

your example was actually a huge help while setting up my project.

With all due respect (to all the amazing hard work put in this project and the people who did it), I think a public API should only expose function members that are commutative. If a public method needs some previous state set by other method, then in my opinion the latter should call the previous.
Again, in my humble opinion, if the previous methods are just setting a state defined by properties, then this 'properties' should be properties and not a function method.
Let's assume a chain of methods to obtain my taxes return. In such case, the chaining of several functions is not commutative since they would affect the result. Assume: F(gross)-F(expense) = net then F(net*0.2) = tax. Clearly, the chain is not commutative since the order matters (F(gross)-F(expense) !=F(expense)-F(gross)). Hence, in my ideal API, I would have setters for the properties gross and expense and then a single call to F(gross,expense,0.2) which would become atomic.
Nonetheless, I am still having some odd failures when renewing the token and the logging is definitely not correct "Error performing password flow" or in any case misleading.
I am working on this implementation heavily and I will very gladly have a look at the code indicated by thebaron24 and will come back with some 'visibility'. (end of week or weekend).
thank you all.

@aznarepse Is it correct to assume that you suggest that calling setupAutomaticSilentRefresh() after the other methods (e.g. loadDisco....AndTryLogin(...)) should

at worst throw a descriptive error to explain that the order is unexpected (instead of some random other error down the line)
at best "just work" with some sensible behavior, if that's possible

does that paraphrasing sound correct?
If so, I think I'd agree, and I'd be tempted to open up a fresh issue for that (linked to this one) so we can focus on those improvements?

@jeroenheijmans
Sorry, have been out of the computer...
Yes, that's what I meant. Definitely written in much clearer way.
I will be very happy to dig in the code and put the time myself and pass it back. The least I can do after using this fantastic lib.


Release 0.17

Hi! Any idea when you will release the 0.17 with ash 0.36 ?

Now! Thanks for the reminder :-)


resourceconnector release

https://github.com/Azure/sdk-release-request/issues/3958

API change check
APIView has identified API level changes in this PR and created following API reviews.
azure-arm-resourceconnector


Account Select shows negative balances when it displays all accounts.

UFRMAccountSelect form shows negative balance when all accounts are displayed.
At the bottom it will currently display:
Accounts: 809770
Balance: -637,024,863,411,494,9000
I have not yet investigated why it shows this. (This is also in my customize client, will have to check in official release to see if problem is there too).
My initial suspicious is:

Either this variable is incorrectly initialized.
or
It's incorrectedly calculated.
or
Somehow it overflows and wraps back to negative ?!? Seems a bit weird...

I tried to reproduce this issue but could not do it, so not yet sure when this happens.


When to release the next version?

Your question is a bit weird, without even knowing what the next version would contain. What are you expecting? What are you currently missing?

I think you have your version plan! This version had some bug, such as black lines, ear next to the texture mapping problem.
I think you'll get this program better than FaceGen!

You're right, this is on my version plan ;-)
There will surely be improvements soon, but I'd hate to make a specific commitment. I'm working on it ;-)

I'm closing this, since it's not really a question with an answer. There will be continuing commits anyway, and some neat improvements in the very near future :-)


fix acsengine build

This change is

@rjtsdl,
Thanks for your contribution as a Microsoft full-time employee or intern. You do not need to sign a CLA.
Thanks,
Microsoft Pull Request Bot

@acs-bot test this please


Update main.yml

In order to run zabbix-web in a standby-alone setup, we have to allow httpd to connect to zabbix.
Description of PR
SeLinux permissions for httpd -> zabbix connections. This is only applicable when you run a zabbix-web installation separated from zabbix-server.
Type of change
Feature Pull Request

Thanks! 👍

Sorry, my bad. I see now this feature was already provided by #82
Can you revert it?

@Vinclame  done!


vcpkg is not update include path

I encountered this problem: after installing some packages in the local VCPKG, I used vs2017 to create a new project, but the new project did not recognize the path of VCPKG, so I had to add the path manually
For example, include path add D:\GitHub\vcpkg\installed\x86-windows\include;D:\GitHub\vcpkg\installed\x86-windows\lib
It's a random problem that I haven't seen on other computers;The problem computer environment is win7, equipped with vc2013 and vs2017

Have you tried to run ./vcpkg integrate install?

I have run the command and remove include/library path from project settings, but encounter a trouble

if I set the library path, it still recognition

ZLIB::ZLIB not working, encountered in many packages
use the file name zlib and zlibd

@fawdlstty, thanks for posting this issue!
I can't reproduce this issue with vs2017 15.9.11 on win7. BTW, VCPKG require Visual Studio 2015 Update 3 or newer (on Windows).
What I tried:

Get VCPKG latest revision
./vcpkg install zlib
./vcpkg integrate install
Open vs2017 and create a console application
Add '#include<zlib.h>' in ConsoleApplication.cpp
Try to build it or you can find zlib.h by 'Open Document <zlib.h>', and check that zlib.h referenced from ./installed/x86-windows/include correctly.

I don't know why. Problem solved

The problem can be reproduced this way:
vcpkg install zlib:x64-windows-static
vcpkg integrate install

Simple console app from https://github.com/Microsoft/vcpkg/issues/6301#issuecomment-490250792 won't compile.
Additional vcpkg install zlib solves the problem.


chore(main): release 1.0.3

:robot: I have created a release beep boop
1.0.3 (2023-02-20)
Bug Fixes

docker: use short ref name for build (f4d634c)

This PR was generated with Release Please. See documentation.

:robot: Release is at https://github.com/bdronneau/memoriesbox/releases/tag/v1.0.3 :sunflower: