PR: Add Markdown syntax highlighter.

As a part of the development of https://github.com/spyder-ide/spyder-reports is necessary to add markdown support to the editor

Thanks a lot for this @rlaverde!! Could you post a screenshot of a Markdown file with code blocks? Thanks!

@ccordoba12

I think this is kinda ready,
Although I've run into an issue: there isn't and standard way (maybe an api) to extend BaseSH, and different languages need different keys, styles for that keys
i.e.:

python have: keyword, string, number, builtin, definition...
md have: titles, links, strike-through, italic, bold, code, lists...

I'd to do an workaround to add new keys-styles, but that's styles aren't fully configurable
cc @goanpeca

there isn't and standard way (maybe an api) to extend BaseSH

I think Markdown is a special case, so let's leave things as they are for now.

In your screenshot, the last line is not highlighted correctly: but is in green when it should be in black.

I think Markdown is a special case

I don't think so, It'll happen with other markup languages (html, rest), or config files (ini, yaml), also with some frameworks (jinja), also with other programming languages that aren't python-like.

so let's leave things as they are for now.

yes, but maybe we could improve this for spyder4
In your screenshot, the last line is not highlighted correctly: but is in green when it should be in black.
Thanks, I didn't notice, I fixed the regex 😄

It'll happen with other markup languages (html, rest), or config files (ini, yaml), also with some frameworks (jinja)

We already have support for all those formats (except Jinja). But the main idea is that Markdown is a special case because there's no Pygments support for it.

yes, but maybe we could improve this for spyder4

Maybe for 4.1, for now let's focus on getting this merged ;-)

Please merge with 3.x to fix CircleCI, and then I'll merge.

This is ready (and I haven't noticed, sorry :-). Merging.


Support for better error trace log

Hi @mballance
I am creating this issue to have a better error trace for pyvsc errors.
Sometimes it is difficult to understand the error and from where it is originating.
I don't have a proper test case for it but sometimes program execution takes an undesirable long time to execute.
For eg.

If some variable is not defined as pyvsc types, we won't get any warning/error for it for a constraint (Which never works as expected) and the program goes on an infinite loop.
Sometimes by looking at the current error log. It is difficult to point out from where it is originating (In a few cases).

Can you provide a proper error tracing for pyvsc?

Hi @aneels3,
Thanks for raising this issue. As you note, this isn't a straight-forward bug that we can fix based on a testcase. It will require more investigation and design to reach a solution.
From your note, it sounds like slow performance (ie a 'hang') is the most user-visible aspect of an issue that requires debugging. Do you know whether the hang is within the PyVSC solver itself or within the RISCV-DV generator? Depending on where you tend to experience slow performance/hangs I'll focusing logging and debug aids differently.
You mention that referencing variables of non-pyvsc type tends to create problems. How frequently does your code do this intentionally? If the classes you randomize are not intended to contain fields of non-pyvsc type, we could add a check for these.
On your second point (identifying problems based on the error log), are you referring specifically to solve failures? If so, would more information tying a solve failure back to a source location help? Would better analysis to identify the conflicting variables help? Something else?
It will be important to get some testcases collected at some point. Please give some thought to what would be helpful here. They certainly don't need to be minimized. They could, for example, take the form of a set of changes to make to the RISCV-DV code that provokes a hang, difficult-to-understand solve failure, etc.
Look forward to working with you on this!
Best Regards,
Matthew

Okay,
I think I got some examples where I think PyVSC needs some enhancement for better error log messages to debug and correct the issue faster.
Test 1:
import vsc

@vsc.randobj
class error_test:
    def __init__(self):
        self.a = vsc.rand_int_t()
        self.b = vsc.rand_bit_t(1)

    @vsc.constraint
    def error_constraint(self):
            self.a == 1
            self.b == 2  # This should be either 0 or 1

er_inst = error_test()
for i in range(5):
    er_inst.randomize()
    print("a = ", er_inst.a, "b = ", er_inst.b)

Output:
Problem Constraints:
Constraint 1:
(b == 2);
(b == 2);

Traceback (most recent call last):
  File "error_test1.py", line 17, in <module>
    er_inst.randomize()
  File "/home/anil/.local/lib/python3.6/site-packages/vsc/rand_obj.py", line 135, in randomize
    raise e
  File "/home/anil/.local/lib/python3.6/site-packages/vsc/rand_obj.py", line 132, in randomize
    debug=debug)
  File "/home/anil/.local/lib/python3.6/site-packages/vsc/model/randomizer.py", line 703, in do_randomize
    r.randomize(ri, bounds_v.bound_m)
  File "/home/anil/.local/lib/python3.6/site-packages/vsc/model/randomizer.py", line 195, in randomize
    self.create_diagnostics(active_randsets))
vsc.model.solve_failure.SolveFailure: solve failure

The above test is pretty simple and it's quite obvious that the self.b can hold the values 0 and 1 only.
So, Instead of the Problem Constraints: message, If it says something like, self.b is of 1-bit length but the value provided in the constraint is out of range along with the constraint_name from where it has generated the error and the corresponding line number. What do you think about this?
I think this will trigger the user to check for the declaration of the variable (Like data_type, bit length, etc) in the constructor function and resolve the issue.
When the constraint is complex, the user gets multiple problem constraint messages.
I think this would help the user to debug efficiently in those cases.
I will post the other example in the next comment.
Regards,
Anil

Hi @aneels3,
I like the idea of performing some static checks on the constraints to catch cases like you show above. I've added the domain check suggested by the example above, and will build on that as other similar cases emerge.
I've also reworked the solve-failure diagnostics a bit, and I feel the results are much better. Release 0.5.1 contains the changes.
The updated code analyzes the group of constraints that failed to identify:

single constraints that fail
pairs of constraints that fail
triples of constraints that fail

Here's an example and the output:
        @vsc.randobj
        class my_c(object):

            def __init__(self):
                self.a = vsc.rand_uint8_t()
                self.b = vsc.rand_uint8_t()
                self.c = vsc.rand_uint8_t()
                self.d = vsc.rand_uint8_t()

            @vsc.constraint
            def abcd_c(self):
                self.c > self.b
                self.a < self.b
                self.c < self.a
                self.c < 10
                self.a > 0
                self.b <= 20

        it = my_c()

        try:
            it.randomize()
            self.fail("Expected a solve failure")
        except vsc.SolveFailure as e:
            print("Exception: " + str(e.diagnostics))

Output:
Problem Set: 3 constraints
  /project/fun/pyvsc/pyvsc-lint/ve/unit/test_solve_failure.py:57:
    (c > b);
  /project/fun/pyvsc/pyvsc-lint/ve/unit/test_solve_failure.py:58:
    (a < b);
  /project/fun/pyvsc/pyvsc-lint/ve/unit/test_solve_failure.py:59:
    (c < a);

Note that the source file/line number is reported.
Look forward to your feedback.
Best Regards,
Matthew

Hi @mballance
This looks really good for now.
Thanks a lot!
I will provide you with some more test-case for further enhancement.
Regards,
Anil

Closing this out for now. Please raise new issues as further enhancements are needed.


Eliminate compile-time warnings in Picard packages

With the migration of the last of the Picard tools came many new compile-time warnings (we went from about 4 warnings up to 100). We should eliminate these.

i think the compiler caps it at 100. there may be more

splitting this into picard vs non-picard and marking accordingly. non-picard is in https://github.com/broadinstitute/hellbender/issues/377
@nh13 please track this ticket - lower prio than tests

@droazen I think I know why, but could you articulate why you want no compile time warnings, rather than stating "it is known".

For one, it makes it easier to see actual problems in the build because they're not drowned out by tons of warning messages.

I know that when I download code and build it, I don't find it comforting to see page after page of warnings.

That's my thinking too, I would just like to hear why in your own words when we have issues.

Comments above by @mattsooknah and @lbergelson reflect my views as well -- allowing lots of warnings to accumulate can hide actual problems. I'll add that @SuppressWarnings is a perfectly acceptable approach to dealing with warnings that we've examined and confirmed to be innocuous.

@edwardk this one is for you!

@edwardkw this one is for you!


Add arch linux package

Hi! A friend of mine shared me your tweet! That's a very nice tool!
I just released an AUR package which relies on the .tar.gz in your Release page.
Cheers!

Wow, Arch linux users are the best!
I just released/tweeted 2760 seconds ago and there is already an Arch Linux package ;-)
I hope someone would come like previously with rgb-tui and git-tui. Thank you!

This LGTM! I have read:
https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=json-tui-bin
and this is indeed looking good!
To support more architecture, I am wondering if this wouldn't be better to also support building using cmake like we did previously:
https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=rgb-tui-git
Anyway, if someone needs it, we can do it later. This patch is a clear improvement.

Hi @Drarig29
I fixed major bugs recently (parsing float and big numbers), performance issue.
I would like to update the package to v1.1.0 with this patch:
From 57111b7b5f122cdb55ecb56d32e2312ddbc6cfdd Mon Sep 17 00:00:00 2001
From: ArthurSonzogni<EMAIL_ADDRESS>Date: Mon, 10 Jan 2022 21:06:57 +0100
Subject: [PATCH] Add v1.1.0

---
 PKGBUILD | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/PKGBUILD b/PKGBUILD
index b43f6f8..a3e8506 100644
--- a/PKGBUILD
+++ b/PKGBUILD
@@ -1,7 +1,7 @@
 # Maintainer: drarig29<EMAIL_ADDRESS>
 pkgname=json-tui-bin
-pkgver=1.0.3
+pkgver=1.1.0
 pkgrel=1
 pkgdesc="A JSON terminal UI made in C++"
 arch=("x86_64")
@@ -10,7 +10,7 @@ license=("MIT")
 provides=("json-tui")
 conflicts=("json-tui")
 source=("https://github.com/ArthurSonzogni/json-tui/releases/download/v${pkgver}/json-tui-${pkgver}-Linux.tar.gz")
-sha256sums=('6d8eacf5d23539d8bbe7b890f26ff58aafdba0ce0e06d5252dff642faf32a6ad')
+sha256sums=('623254ee6e9f974ba7337c365926accd6f32b939bcccb7510396f9a02924a4ac')

 package() {
   install -Dm755 json-tui-${pkgver}-Linux/bin/json-tui -t "$pkgdir/usr/bin"
--
2.30.2

I guess I might need to do it several time. Would it be possible to become the co-maintainer of this package?
My AUR username is "arthursonzogni".
My AUR email is sonzogniarthur at gmail
For now, I get:
git-receive-pack: permission denied: arthursonzogni

Done ☺
Maybe you could add keywords too


Add New Language: Dart

Description
Provide a description of the programming language.

Hi, Can you please assign this to me?

Already fixed with #1


Update prereleases comment (adding C3)

This PR updates the PR prereleases comment, I wanted to add the C3 prerelease there, but since I was at it I made other changes (hopefully improvements 😬)
This is what this PR changes:

removed the automatically updated head installation as it adds noise and it's likely rarely if at all used
put all the packages at the same level (wrangler being the first or course) (i.e. removed the Additional artifacts distinction)
added C3
moved all the packages instructions in a details section so that the comment doesn't add too much noise to PRs (I've been doing this for next-on-pages and it works quite well, see for example this comment )
fixed a small formatting issue in the runtime dependencies message

Closing this as this PR has gotten quite stale and I don't think we manage to get an consensus on how to structure the comment


Install ipvsadm when kube_proxy_mode is ipvs

ipvsadm is used in roles/reset/tasks/main.yml but is never installed

ci check this

@mirwan Is this even required for ipvs mode? As far as I can tell, it's optional

@mattymo It sure is but the fact that ipvsadm is used in a task in the reset role when kube_proxy_mode == 'ipvs' makes it less optional here I guess.
Btw the subsequent reset tasks are not executed when the ipvsadm -C fails, thus it leaves the cluster not properly reset

@mattymo What do you think?

This makes sense to include IMO. Beyond the reset use case, ipvsadm has been useful in debugging ipvs for us.
/approve
/lgtm

@mirwan This is missing the cncf-cla: yes label. Looks like you may need to amend  your commit using the author email you signed the CLA with.

@mirwan I realized this didn't have cncf-cla: no either so I added the label manually, we'll see if the bot likes that. I guess someone accidentally removed the label

@chadswen I wondered why the label hadn't been added... Thanks for that and the approval!


Observed a panic in reconciler: runtime error: invalid memory address or nil pointer dereference error in the controller pod

Bug information
I have observed this error message in the functional test runs of some PRs in the controller pod.
{"severity":"info","timestamp":"2023-11-22T16:40:35.409Z","name":"controller.controller","caller":"controller/controller.go:114","message":"Observed a panic in reconciler: runtime error: invalid memory address or nil pointer dereference","serviceName":"controller","version":"edge","hostName":"controller-84f587c5d6-kqhcf","controller":"deployment","controllerGroup":"apps","controllerKind":"Deployment","Deployment":{"name":"dapr-sts-manual-redis","namespace":"default-daprrp-rs-statestore-manual"},"namespace":"default-daprrp-rs-statestore-manual","name":"dapr-sts-manual-redis","reconcileID":"276efd5d-463d-41b1-8b3c-30c5312ed1fd"}
panic: runtime error: invalid memory address or nil pointer dereference [recovered]
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x18 pc=0x17b5417]
goroutine 133 [running]:
sigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).Reconcile.func1()
/home/runner/go/pkg/mod/sigs.k8s.io/controller-runtime@v0.15.0/pkg/internal/controller/controller.go:115 +0x1e5
panic({0x1974860?, 0x2cda2d0?})
/opt/hostedtoolcache/go/1.21.4/x64/src/runtime/panic.go:914 +0x21f
github.com/radius-project/radius/pkg/controller/reconciler.(*DeploymentReconciler).Reconcile(0xc0000cb100, {0x1ed8998, 0xc000908660}, {{{0xc00095dcb0?, 0x0?}, {0xc000691068?, 0x410745?}}})
/home/runner/work/radius/radius/pkg/controller/reconciler/deployment_reconciler.go:110 +0x3b7
sigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).Reconcile(0x1ed8998?, {0x1ed8998?, 0xc000908660?}, {{{0xc00095dcb0?, 0x18a9e60?}, {0xc000691068?, 0x1ec7010?}}})
/home/runner/go/pkg/mod/sigs.k8s.io/controller-runtime@v0.15.0/pkg/internal/controller/controller.go:118 +0xb7
sigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).reconcileHandler(0xc0001ad040, {0x1ed89d0, 0xc0006ec870}, {0x1a1fb00?, 0xc0005b78c0?})
/home/runner/go/pkg/mod/sigs.k8s.io/controller-runtime@v0.15.0/pkg/internal/controller/controller.go:314 +0x365
sigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).processNextWorkItem(0xc0001ad040, {0x1ed89d0, 0xc0006ec870})
/home/runner/go/pkg/mod/sigs.k8s.io/controller-runtime@v0.15.0/pkg/internal/controller/controller.go:265 +0x1c9
sigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).Start.func2.2()
/home/runner/go/pkg/mod/sigs.k8s.io/controller-runtime@v0.15.0/pkg/internal/controller/controller.go:226 +0x79
created by sigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).Start.func2 in goroutine 101
/home/runner/go/pkg/mod/sigs.k8s.io/controller-runtime@v0.15.0/pkg/internal/controller/controller.go:222 +0x565
Steps to reproduce (required)

Create a PR or run functional tests locally (the latter needs confirmation)
Check controller pod logs
See the panic

Observed behavior (required)
Error in the controller pod.
Desired behavior (required)
No panic
Workaround (optional)
System information
rad Version (required)
PR
Operating system (required)
PR
Additional context
msgrp_container_logs.zip
daprrp_container_logs.zip
AB#10470

Name:             controller-84f587c5d6-kqhcf
Namespace:        radius-system
Priority:         0
Service Account:  controller
Node:             radius-control-plane/<IP_ADDRESS>
Start Time:       Wed, 22 Nov 2023 16:39:57 +0000
Labels:           app.kubernetes.io/name=controller
                  app.kubernetes.io/part-of=radius
                  control-plane=controller
                  pod-template-hash=84f587c5d6
Annotations:      prometheus.io/path: /metrics
                  prometheus.io/port: 9090
                  prometheus.io/scrape: true
Status:           Running
IP:               <IP_ADDRESS>
IPs:
  IP:           <IP_ADDRESS>
Controlled By:  ReplicaSet/controller-84f587c5d6
Containers:
  controller:
    Container ID:  containerd://5ec2d47b0f44f52fa11a9f34eb32c653b238b5576491862ad2745ce9276a61ad
    Image:         ghcr.io/radius-project/dev/controller:pr-b3baf7160c
    Image ID:      ghcr.io/radius-project/dev/controller@sha256:d3316aebcbc7f1dc18d3f634511e166c7ee7c209fa0200407f64fcc3ff230f55
    Ports:         9443/TCP, 9090/TCP
    Host Ports:    0/TCP, 0/TCP
    Args:
      --config-file
      /etc/config/controller-config.yaml
    State:          Waiting
      Reason:       CrashLoopBackOff
    Last State:     Terminated
      Reason:       Error
      Exit Code:    2
      Started:      Wed, 22 Nov 2023 16:41:44 +0000
      Finished:     Wed, 22 Nov 2023 16:41:57 +0000
    Ready:          False
    Restart Count:  3
    Limits:
      memory:  300Mi
    Requests:
      memory:  60Mi
    Environment:
      TLS_CERT_DIR:  /var/tls/cert
      PORT:          9443
    Mounts:
      /etc/config from config-volume (rw)
      /var/run/secrets/kubernetes.io/serviceaccount from kube-api-access-dcfdw (ro)
      /var/tls/cert from cert (ro)
Conditions:
  Type              Status
  Initialized       True
  Ready             False
  ContainersReady   False
  PodScheduled      True
Volumes:
  config-volume:
    Type:      ConfigMap (a volume populated by a ConfigMap)
    Name:      controller-config
    Optional:  false
  cert:
    Type:        Secret (a volume populated by a Secret)
    SecretName:  controller-cert
    Optional:    false
  kube-api-access-dcfdw:
    Type:                    Projected (a volume that contains injected data from multiple sources)
    TokenExpirationSeconds:  3607
    ConfigMapName:           kube-root-ca.crt
    ConfigMapOptional:       <nil>
    DownwardAPI:             true
QoS Class:                   Burstable
Node-Selectors:              <none>
Tolerations:                 node.kubernetes.io/not-ready:NoExecute op=Exists for 300s
                             node.kubernetes.io/unreachable:NoExecute op=Exists for 300s
Events:
  Type     Reason       Age                  From               Message
  ----     ------       ----                 ----               -------
  Normal   Scheduled    2m39s                default-scheduler  Successfully assigned radius-system/controller-84f587c5d6-kqhcf to radius-control-plane
  Warning  FailedMount  2m38s                kubelet            MountVolume.SetUp failed for volume "cert" : failed to sync secret cache: timed out waiting for the condition
  Normal   Pulled       2m34s                kubelet            Successfully pulled image "ghcr.io/radius-project/dev/controller:pr-b3baf7160c" in 933.190868ms (2.290805669s including waiting)
  Normal   Pulled       119s                 kubelet            Successfully pulled image "ghcr.io/radius-project/dev/controller:pr-b3baf7160c" in 136.213657ms (884.795298ms including waiting)
  Normal   Pulled       97s                  kubelet            Successfully pulled image "ghcr.io/radius-project/dev/controller:pr-b3baf7160c" in 160.095171ms (160.127321ms including waiting)
  Normal   Pulling      52s (x4 over 2m37s)  kubelet            Pulling image "ghcr.io/radius-project/dev/controller:pr-b3baf7160c"
  Normal   Created      52s (x4 over 2m34s)  kubelet            Created container controller
  Normal   Started      52s (x4 over 2m34s)  kubelet            Started container controller
  Normal   Pulled       52s                  kubelet            Successfully pulled image "ghcr.io/radius-project/dev/controller:pr-b3baf7160c" in 195.263528ms (195.277203ms including waiting)
  Warning  BackOff      9s (x6 over 110s)    kubelet            Back-off restarting failed container controller in pod controller-84f587c5d6-kqhcf_radius-system(3653a8dd-8c92-4a31-9eac-0e4d4a36ada8)


Fixed attribute capture group for docs-linting

youtube videos with v= are getting flagged for invalid attribute linting.

Fixed attribute capture group for when user has video ?v=PMkxyafY

Codecov Report

Merging #818 (4b0b16b) into master (2c21981) will decrease coverage by 50.71%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master    #818       +/-   ##
==========================================
- Coverage   50.71%   0.00%   -50.72%
==========================================
  Files          81       1       -80
  Lines        5559      56     -5503
  Branches      929      11      -918
==========================================
- Hits         2819       0     -2819
+ Misses       2331      56     -2275
+ Partials      409       0      -409

Impacted Files
Coverage Δ

...down/src/controllers/quick-pick-menu-controller.ts

...docs-markdown/src/controllers/italic-controller.ts

...es/docs-markdown/src/controllers/xref/utilities.ts

.../src/controllers/cleanup/handleMarkdownMetadata.ts

...kdown/src/controllers/links/linkToDocsPageByUrl.ts

...cs-markdown/src/controllers/notebook-controller.ts

.../docs-markdown/src/controllers/media-controller.ts

...docs-markdown/src/controllers/snippet/utilities.ts

.../controllers/cleanup/handleSingleValuedMetadata.ts

...-markdown/src/controllers/yaml/createParentNode.ts

... and 72 more

Continue to review full report at Codecov.

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


fix: add the stable chartmuseum chart

[APPROVALNOTIFIER] This PR is NOT APPROVED
This pull-request has been approved by:
To complete the pull request process, please assign jstrachan
You can assign the PR to them by writing /assign @jstrachan in a comment when ready.
The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@jstrachan: The following test failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

kube
ea1d18061c5af9c0da89ce212ff56a6024668189
link
/test kube

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the jenkins-x/lighthouse repository. I understand the commands that are listed here.

@jstrachan: The following test failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

kube
aedc2fd610fd9e1a3ca0ac2e011d8ba401e8a7ee
link
/test kube

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the jenkins-x/lighthouse repository. I understand the commands that are listed here.

@jstrachan: The following test failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

kube
b57028e85fc567f299d0e4d824fb2e7b0b87f1fd
link
/test kube

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the jenkins-x/lighthouse repository. I understand the commands that are listed here.

@jstrachan: The following tests failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

kube
b57028e85fc567f299d0e4d824fb2e7b0b87f1fd
link
/test kube

gsm
b57028e85fc567f299d0e4d824fb2e7b0b87f1fd
link
/test gsm

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the jenkins-x/lighthouse repository. I understand the commands that are listed here.

@jstrachan: The following tests failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

kube
b57028e85fc567f299d0e4d824fb2e7b0b87f1fd
link
/test kube

gsm
b57028e85fc567f299d0e4d824fb2e7b0b87f1fd
link
/test gsm

vault
b57028e85fc567f299d0e4d824fb2e7b0b87f1fd
link
/test vault

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the jenkins-x/lighthouse repository. I understand the commands that are listed here.

@jstrachan: The following tests failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

gsm
b57028e85fc567f299d0e4d824fb2e7b0b87f1fd
link
/test gsm

kube
dc8e0825e4b0b54572322fad99518b6f7284639a
link
/test kube

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the jenkins-x/lighthouse repository. I understand the commands that are listed here.

@jstrachan: The following tests failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

gsm
b57028e85fc567f299d0e4d824fb2e7b0b87f1fd
link
/test gsm

kube
dc8e0825e4b0b54572322fad99518b6f7284639a
link
/test kube

vault
dc8e0825e4b0b54572322fad99518b6f7284639a
link
/test vault

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the jenkins-x/lighthouse repository. I understand the commands that are listed here.

@jstrachan: The following tests failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

kube
dc8e0825e4b0b54572322fad99518b6f7284639a
link
/test kube

vault
dc8e0825e4b0b54572322fad99518b6f7284639a
link
/test vault

gsm
dc8e0825e4b0b54572322fad99518b6f7284639a
link
/test gsm

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the jenkins-x/lighthouse repository. I understand the commands that are listed here.

@jstrachan: The following tests failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

kube
dc8e0825e4b0b54572322fad99518b6f7284639a
link
/test kube

vault
dc8e0825e4b0b54572322fad99518b6f7284639a
link
/test vault

gsm
ffa4b5c3099c759be8c05f6e773d6893f9b41be4
link
/test gsm

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the jenkins-x/lighthouse repository. I understand the commands that are listed here.

@jstrachan: The following tests failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

kube
dc8e0825e4b0b54572322fad99518b6f7284639a
link
/test kube

gsm
ffa4b5c3099c759be8c05f6e773d6893f9b41be4
link
/test gsm

vault
bc887e6fe418161cae9becb914d708eacaa6dc52
link
/test vault

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the jenkins-x/lighthouse repository. I understand the commands that are listed here.

@jstrachan: The following tests failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

kube
dc8e0825e4b0b54572322fad99518b6f7284639a
link
/test kube

vault
bc887e6fe418161cae9becb914d708eacaa6dc52
link
/test vault

gsm
bc887e6fe418161cae9becb914d708eacaa6dc52
link
/test gsm

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the jenkins-x/lighthouse repository. I understand the commands that are listed here.

/retest

@jstrachan: The following tests failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

gsm
bc887e6fe418161cae9becb914d708eacaa6dc52
link
/test gsm

vault
ffa4b5c3099c759be8c05f6e773d6893f9b41be4
link
/test vault

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the jenkins-x/lighthouse repository. I understand the commands that are listed here.

@jstrachan: The following tests failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

vault
ffa4b5c3099c759be8c05f6e773d6893f9b41be4
link
/test vault

gsm
bc887e6fe418161cae9becb914d708eacaa6dc52
link
/test gsm

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the jenkins-x/lighthouse repository. I understand the commands that are listed here.

@jstrachan: The following tests failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

gsm
bc887e6fe418161cae9becb914d708eacaa6dc52
link
/test gsm

vault
bc887e6fe418161cae9becb914d708eacaa6dc52
link
/test vault

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the jenkins-x/lighthouse repository. I understand the commands that are listed here.

@jstrachan: The following tests failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

gsm
bc887e6fe418161cae9becb914d708eacaa6dc52
link
/test gsm

vault
9910d52c1fa0da5fa3d05b112f71455e48bb4b81
link
/test vault

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the jenkins-x/lighthouse repository. I understand the commands that are listed here.

@jstrachan: The following tests failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

vault
9910d52c1fa0da5fa3d05b112f71455e48bb4b81
link
/test vault

gsm
9910d52c1fa0da5fa3d05b112f71455e48bb4b81
link
/test gsm

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the jenkins-x/lighthouse repository. I understand the commands that are listed here.

/retest

@jstrachan: The following tests failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

vault
9910d52c1fa0da5fa3d05b112f71455e48bb4b81
link
/test vault

gsm
9910d52c1fa0da5fa3d05b112f71455e48bb4b81
link
/test gsm

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the jenkins-x/lighthouse repository. I understand the commands that are listed here.

@jstrachan: The following tests failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

gsm
9910d52c1fa0da5fa3d05b112f71455e48bb4b81
link
/test gsm

vault
9910d52c1fa0da5fa3d05b112f71455e48bb4b81
link
/test vault

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the jenkins-x/lighthouse repository. I understand the commands that are listed here.

retest

/retest

@jstrachan: The following tests failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

gsm
9910d52c1fa0da5fa3d05b112f71455e48bb4b81
link
/test gsm

vault
9910d52c1fa0da5fa3d05b112f71455e48bb4b81
link
/test vault

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the jenkins-x/lighthouse repository. I understand the commands that are listed here.

/test vault

@jstrachan: The following tests failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

vault
9910d52c1fa0da5fa3d05b112f71455e48bb4b81
link
/test vault

gsm
9910d52c1fa0da5fa3d05b112f71455e48bb4b81
link
/test gsm

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the jenkins-x/lighthouse repository. I understand the commands that are listed here.

/test gsm

@jstrachan: The following tests failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

gsm
9910d52c1fa0da5fa3d05b112f71455e48bb4b81
link
/test gsm

vault
9910d52c1fa0da5fa3d05b112f71455e48bb4b81
link
/test vault

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the jenkins-x/lighthouse repository. I understand the commands that are listed here.

@jstrachan: The following tests failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

vault
9910d52c1fa0da5fa3d05b112f71455e48bb4b81
link
/test vault

gsm
9910d52c1fa0da5fa3d05b112f71455e48bb4b81
link
/test gsm

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the jenkins-x/lighthouse repository. I understand the commands that are listed here.

/test gsm

@jstrachan: The following tests failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

vault
9910d52c1fa0da5fa3d05b112f71455e48bb4b81
link
/test vault

gsm
5f6ce9179f8c2b94c99fbee0dac5571a0d7ae83f
link
/test gsm

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the jenkins-x/lighthouse repository. I understand the commands that are listed here.

@jstrachan: The following tests failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

gsm
5f6ce9179f8c2b94c99fbee0dac5571a0d7ae83f
link
/test gsm

vault
5f6ce9179f8c2b94c99fbee0dac5571a0d7ae83f
link
/test vault

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the jenkins-x/lighthouse repository. I understand the commands that are listed here.

@jstrachan: The following tests failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

vault
5f6ce9179f8c2b94c99fbee0dac5571a0d7ae83f
link
/test vault

gsm
5f6ce9179f8c2b94c99fbee0dac5571a0d7ae83f
link
/test gsm

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the jenkins-x/lighthouse repository. I understand the commands that are listed here.

@jstrachan: The following tests failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

gsm
5f6ce9179f8c2b94c99fbee0dac5571a0d7ae83f
link
/test gsm

vault
6354f93ad3e1b3041a6e6f1c484333b6a97908be
link
/test vault

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the jenkins-x/lighthouse repository. I understand the commands that are listed here.

@jstrachan: The following tests failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

vault
6354f93ad3e1b3041a6e6f1c484333b6a97908be
link
/test vault

gsm
6354f93ad3e1b3041a6e6f1c484333b6a97908be
link
/test gsm

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the jenkins-x/lighthouse repository. I understand the commands that are listed here.

@jstrachan: The following tests failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

vault
6354f93ad3e1b3041a6e6f1c484333b6a97908be
link
/test vault

gsm
6354f93ad3e1b3041a6e6f1c484333b6a97908be
link
/test gsm

kube
6354f93ad3e1b3041a6e6f1c484333b6a97908be
link
/test kube

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the jenkins-x/lighthouse repository. I understand the commands that are listed here.

/test gsm

@jstrachan: The following tests failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

vault
6354f93ad3e1b3041a6e6f1c484333b6a97908be
link
/test vault

kube
6354f93ad3e1b3041a6e6f1c484333b6a97908be
link
/test kube

gsm
6354f93ad3e1b3041a6e6f1c484333b6a97908be
link
/test gsm

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the jenkins-x/lighthouse repository. I understand the commands that are listed here.

/test gsm

@jstrachan: The following tests failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

vault
6354f93ad3e1b3041a6e6f1c484333b6a97908be
link
/test vault

kube
6354f93ad3e1b3041a6e6f1c484333b6a97908be
link
/test kube

gsm
6354f93ad3e1b3041a6e6f1c484333b6a97908be
link
/test gsm

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the jenkins-x/lighthouse repository. I understand the commands that are listed here.

@jstrachan: The following tests failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

vault
6354f93ad3e1b3041a6e6f1c484333b6a97908be
link
/test vault

kube
6354f93ad3e1b3041a6e6f1c484333b6a97908be
link
/test kube

gsm
6354f93ad3e1b3041a6e6f1c484333b6a97908be
link
/test gsm

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the jenkins-x/lighthouse repository. I understand the commands that are listed here.


Use Path APIs for proper path construction and display

Choose one: is this a 🐛 bug fix
Before this change I was shown a path like /var/folders/6l/3b74wfrs185cycvzkgz46ymw0000gp/T//report-d522a1a5-de9e-4a67-bee7-7904fbb463d7.toml (see the double-forward slash? It's not wrong, but still weird)
After this change I see the expected path with a single slash.
Checklist
nothing applies

[ ] tests pass
[ ] tests and/or benchmarks are included
[ ] documentation is changed or added

Context

Semver Changes
patch
Addendum: Your Cargo.lock needs an update now that 0.2 is released.

Part of #10


MODFQMMGR-480 Make tenant_id fields ECS-only

Purpose
Describe the purpose of the pull request. Include background information if necessary.
Approach
How does this change fulfill the purpose?
TODOS and Open Questions

[ ] Use GitHub checklists. When solved, check the box and explain the answer.

Learning
Describe the research stage. Add links to blog posts, patterns, libraries or addons used to solve this problem.
Pre-Merge Checklist
If you are adding entity type(s), have you:

[ ] Added the JSON5 definition to the src/main/resources/entity-types directory?
[ ] Ensured that GETing the entity type at /entity-types/{id} works as expected?
[ ] Added translations for all fields, per the translation guidelines? (Check this by ensuring GET /entity-types/{id} does not have mod-fqm-manager.entityType. in the response)
[ ] Added views to liquibase, as applicable?
[ ] Added required interfaces to the module descriptor?
[ ] Checked that querying fields works correctly and all SQL is valid?

If you are changing/removing entity type(s), have you:

[ ] Added migration code for any changes?

LGTM :)


[WFLY-17231] Update HostExcludesTestCase configuration to work with WF28

Jira issue: https://issues.redhat.com/browse/WFLY-17231
We have added some extensions during the WF27 development cycle, the HostExcludesTestCase tracks those forcing us to re-create an additional enum in the test case itself when we move forward to the next release.
It looks like org.wildfly.extension.datasources-agroal was removed in WildFly 14 I think we moved it to WildFly Preview) but we added it back later in WF27 to the standard configuration.

@yersan There was still a failure so I sent up #16247 to get CI passing without needing to rush this.

Ok, thanks @bstansberry , ignoring it is the best, we need to release wildfly-core first to completely fix this one

/retest

Thanks @yersan


Remove use of async in args for python 3.7 support

In 3.7 'async' becomes a reserved keyword.  Rename the variable.
https://docs.python.org/3/whatsnew/3.7.html

Thanks for the contribution.
Our Python 3 tests run under Python 3.6 and that's why I assume they didn't catch it. In addition to that, we don't officially support Python 3 yet and once we will, we will only support Python 3.5 - 3.6 to begin with.
Having said that, this change doesn't break any other thing and it's a good future proofing so it's still good to merge it :+1:

Given the client libraries are incorporated in the codebase, could that restrict the integration of 3rd party applications with Stackstorm, where they only want to make API calls against ST2 using the client library?
Does that suggest a separate package just for the client that could support more versions?

@j3p0uk Yeah that was actually our long term plan (decouple Python client library and the actual CLI tool, but we sadly didn't get to it yet).

In the future, I would also want us to run tests under Python 3.7 in addition to Python 3.6, but that's sadly not feasible right now.
Our build is already quite slow and adding 2 new tasks for Python 3.7 would slow everything down for 20 minutes or so and that's sadly not acceptable.

I know that feeling well!  Travis CI doesn't seem to support python 3.7 at the moment either, I guess I'm just being too eager! :)


detect osd_objectstore set at ceph_conf_overrides

ceph docs recommends setting osd_objectstore to bluestore in ceph conf, if a admin has set the ceph_objectstore in ceph_conf_overrides, ceph-ansible should detect this and should be equivalent to setting it at group_vars/all level.

If osd_objectstore is set in ceph_conf_overrides ceph-ansible will pick it up. I don't understand your concern. Please clarify.

@leseb in the documentation we say it should be set in all.yml instead of ceph_conf_overrrides, is it a doc issue then? or has it to be defined at both level? Also check the RHCS documentation please.
http://docs.ceph.com/ceph-ansible/master/osds/scenarios.html

The doc says Other (optional) supported settings:, this does not mean we have to set that option in all.yml.

OK i missed the optinal part in the above link but the RHCS documentation should also be fixed in this case which has it documented at all.yml level(not optional),  if it doesn't work when set at ceph_conf_overrides I take it as a defect then.

@vasukulkarni if there is an issue downstream then please open a BZ.


Put quotes around aggregate_id search

Add quotes to the aggregate_id search. This prevents it from accidentally picking up incorrect alerts if the _ids share common patterns. Note that this only occurs if the mapping is applied incorrectly, as aggregate_id is supposed to be non-analyzed. However, we may as well preemptively prevent these errors because it's as simple as adding quotes.

Can you resolve conflicts please :)

Can you resolve conflicts please :)


Livereload broken on master

This commit broke Livereload plugin: 936d19cbb3567835fffc4e03abd32370167d688e
C:\workspace>bundle exec middleman server
ansi: 'gem install win32console' to use color on Windows
yarn install v1.3.2
[1/4] Resolving packages...
success Already up-to-date.
Done in 0.61s.
== The Middleman is loading
yarn install v1.3.2
[1/4] Resolving packages...
success Already up-to-date.
Done in 0.60s.
== Executing: `yarn run server`
== External: yarn run v1.3.2
== External: $ node ./node_modules/webpack/bin/webpack.js --env=dev --watch -d --progress --color
 10% building modules 2/2 modules 0 active== External: Webpack is watching the f 10% building modules 3/4 modules 1 active ...ce\ts_home\webpack\javascripts\app. 11% building modules 10/13 modules 3 active ...\node_modules\style-loader\fixUrls.jsC:/ruby24/lib/ruby/gems/2.4.0/gems/middleman-livereload-3.4.6/lib/middleman-livereload/extension_3_1.rb:45:in `block in initialize': undefined local variable or method `files' for #<Middleman::LiveReloadExtension:0x0000000ad99bd0> (NameError)
        from C:/ruby24/lib/ruby/gems/2.4.0/gems/contracts-0.16.0/lib/contracts/call_with.rb:78:in `block in call_with'
        from C:/ruby24/lib/ruby/gems/2.4.0/bundler/gems/middleman-79c39b5d880a/middleman-core/lib/middleman-core/callback_manager.rb:57:in `instance_exec'
        from C:/ruby24/lib/ruby/gems/2.4.0/bundler/gems/middleman-79c39b5d880a/middleman-core/lib/middleman-core/callback_manager.rb:57:in `block in execute'
        from C:/ruby24/lib/ruby/gems/2.4.0/gems/hamster-3.0.0/lib/hamster/vector.rb:1316:in `each'
        from C:/ruby24/lib/ruby/gems/2.4.0/gems/hamster-3.0.0/lib/hamster/vector.rb:1316:in `traverse_depth_first'
        from C:/ruby24/lib/ruby/gems/2.4.0/gems/hamster-3.0.0/lib/hamster/vector.rb:431:in `each'
        from C:/ruby24/lib/ruby/gems/2.4.0/bundler/gems/middleman-79c39b5d880a/middleman-core/lib/middleman-core/callback_manager.rb:57:in `execute'
        from C:/ruby24/lib/ruby/gems/2.4.0/gems/contracts-0.16.0/lib/contracts/method_reference.rb:43:in `send_to'
        from C:/ruby24/lib/ruby/gems/2.4.0/gems/contracts-0.16.0/lib/contracts/call_with.rb:79:in `call_with'

@tdreyno this is still happening and needs to be fixed before 4.3.x can be released.

@tdreyno ?

Confirmed, same behavior

Same here 👍

Also happening here.


Alive documents increase unlimited?

I think this is a bug, but also maybe I miss something in how the rev works, we have an edge collection with around 300k entries now, that is updated continuously from an arango job.
The edge gets huge, and this is how the figures look like:

Why does it keep so many alive versions? Can I prevent it from doing that? The data is not that big, for sure. How can I force some "forget all revisions"?
This edge has only 1 index bucket, but that should have nothing to do with it.
Thank you!

How many documents/edges are in that collection at the moment? A collection.count() should show this. Is that number much deviating from the number shown for Alive?

Yes, I already said, 330.000 items vs 115.000.000 alive.
arangosh [_system]> db.sorter_api_at_product_category_sort.count();
355861

arangosh [_system]> db.sorter_api_at_product_category_sort.figures();
{
  "alive" : {
    "count" : 115439889,
    "size" :<PHONE_NUMBER>4
  },
  "dead" : {
    "count" : 608234,
    "size" : 125399232,
    "deletion" : 425001
  },
  "datafiles" : {
    "count" : 531,
    "fileSize" :<PHONE_NUMBER>4
  },
  "journals" : {
    "count" : 1,
    "fileSize" : 33554432
  },
  "compactors" : {
    "count" : 0,
    "fileSize" : 0
  },
  "shapefiles" : {
    "count" : 0,
    "fileSize" : 0
  },
  "shapes" : {
    "count" : 321,
    "size" : 71256
  },
  "attributes" : {
    "count" : 12,
    "size" : 624
  },
  "indexes" : {
    "count" : 2,
    "size" : 65936560
  },
  "lastTick" : "2386922340267405",
  "uncollectedLogfileEntries" : 0
}

arangosh [_system]>

Sorry, I overlooked the 300k.
115.000.000 alive documents seems way too much. When you say the collection is updated continuously, does that mean you remove and insert documents or really update or replace them? Which method do you use for that (i.e. update(), replace(), AQL...?). Thanks.

Actually this might be the reason, we use the graph module, something like this:
var graphModule = require('org/arangodb/general-graph'),
    db = require('org/arangodb').db,
    categoryGraph = graphModule._graph(collections.GRAPH_PRODUCT_CATEGORY);

var edge = db._collection(collections.EDGE_PRODUCT_CATEGORY).firstExample({
    _from: collections.PRODUCTS + '/' + productId,
    _to: collections.CATEGORIES + '/' + cat
});

if (edge) {
    categoryGraph[collections.EDGE_PRODUCT_CATEGORY].update(edge, {
        updated_at: timeOfUpdate
    });
} else {
    categoryGraph[collections.EDGE_PRODUCT_CATEGORY].save(
            collections.PRODUCTS + '/' + productId,
            collections.CATEGORIES + '/' + cat,
            {
                updated_at: timeOfUpdate
            }
    );
}

I would bet most of the time it gets into the update case, since the edge exists already.

Ok thanks, will try to reproduce this.

Thank you, in the meanwhile is there anything I can do to make it drop those revisions? If I restart it, it can't load them anymore because there is not enough RAM.
@pluma as a suggestion, can you please change all values of Size from the figures tab shown in the screenshot above, so that the right unit is calculated for each row, z.B. MB, GB, TB, since our data is often above 1000 MB and it gets harder to spot anomalies like the one in this ticket.

@razvanphp make sense. I've created a separate ticket for that as it's unrelated: #1597

It seems that at least after a truncate() operation some of the alive documents remain in the datafiles.
After a restart, the collection gets cleaned up properly and the stats will get in order again, but that requires loading the entire collection of course.
Is the compaction enabled for the collection in question? db.sorter_api_at_product_category_sort.properties(); should show a doCompact value of true.

Yes it is. I also don't think we do any truncate on it...
arangosh [_system]> db.sorter_api_at_product_category_sort.properties();
{
  "doCompact" : true,
  "journalSize" : 33554432,
  "isSystem" : false,
  "isVolatile" : false,
  "waitForSync" : false,
  "keyOptions" : {
    "type" : "traditional",
    "allowUserKeys" : true
  },
  "indexBuckets" : 1
}

arangosh [_system]>

Not sure if this is related:
I found that compaction can be blocked by JavaScript objects still pointing to documents in a collection.
For example, if you use a server-side job or Foxx action that fetches a document from a collection and stores it inside a JavaScript variable, this will prevent the datafile the document is contained in from being deleted. This is not a problem if documents are only stored in temporary JavaScript variables or local variables in functions that are left again. It can be a problem if documents are assigned to global JavaScript variables or instance variables if the objects are long-lived. In this case, the reference pointing from the JavaScript variable to the document will prevent the compaction from making progress. Compaction will still run, but it cannot remove old files because JavaScript variables are still pointing into them.
This can also happen when only local JavaScript variables are temporaries point to the documents but garbage collection hasn't run. Once garbage collection has run and no variables point to the documents, everything proceeds and compaction will start removing obsolete files.
Whenever I tried it, I saw the compactor attribute of the figures() command show a value of 1 in its count subattribute. That's the indication for the compaction not making progress. Looking at the figures() output you posted, it seems like that's not what's happening in your case.

Yesterday I used the huge arangodump to restore the data on a new machine. It took the alive documents with it, but after unloading and loading again the collection, all excess edges got into Dead, and they were cleaned after a few minutes as expected.
BTW: maybe I trigger another unexpected thing, I clicked unload, and then load again maybe too fast, and now it does not want to unload anymore. Every time I try it remains in "in the process of being unloaded". If I click on it, I can see the data instantly, so I don't think he tries to unload it anymore. Also the alive documents stay. The edge data files are 1.7 GB.

There are a few subtleties with unloading: if some script or code still has a reference to a document in the collection that is going to be unloaded, then the unload will not happen until the reference to the document goes out of scope or is garbage collected. The collection will only change its status from loaded to in the process of being unloaded and wait there until no references point to it. When the last reference is gone, the actual unload will happen. Another reason for a collection not physically unloading is that data for the collection is still present only in the write-ahead-log, but not in the collection's datafiles. If that happens, the collection will not physically unload until the collection data is transferred from the WAL into the collection's datafiles. The data will be transferred only for full WAL files, and as each is 32 MB by default, it may take a while until a WAL file gets full and the collection can proceed with its unloading.
The currently open WAL file is intentionally not flushed every time a collection is unloaded because that may be expensive.
I understand this is unintuitive because the message in the process of being unloaded suggests there will soon be progress, while the actual status message should rather be waiting for references pointing to the collection to go out of scope and maybe also a WAL flush. I hope this can be improved somehow, and even if only by making the UI or status messages more understandable. But ideally there'd be a way to force the unload somehow. I need to discuss this internally.

Regarding compaction: I have some work in progress regarding compaction. This should address some of its issues and provide better debuggability for cases when its unclear what the compaction status is.
I am currently working in some side branch, but I hope to get the branch ready until the end of the week.

Any updates regarding this one? Can you reproduce this or we need the new version with improved logging to find out? Maybe I can provide the Foxx app that does this.
It gets a little bit tricky, since this eats up all RAM of the server, so I guess it starts to "pseudo-swap", unloading the datafiles from memory.
Luckily it seems that unloading and loading the collection sometimes moves all documents into Dead and they get garbage collected.

Yes, unloading and re-loading the collection will re-assess the number of alive/dead documents. This should enable compaction to remove the dead documents.
The status of this issue is:

there's no additional logging as we currently don't have a good mechanism to turn on/off logging selectively just for some functions or resources such as collections. However, compaction progress and non-progress are now reported by the figures() method for a collection and the web interface. This can be used for debugging compaction problems. This was a substantial change including some API changes, so it is present in the 2.8 and devel branches only.
I can confirm the compaction can stall when an unload request for the collection is made but some later activity happens that requires the collection and implicitly reloads it before the unload request is actually carried out. The fix is included in the 2.8 and devel branches at the moment.

It's unclear to me whether the latter is the root cause for the compaction stall that seems to be happening on your server, but I doubt it. Even if compaction does not make any progress, alive size should not get much higher if documents get only updated.
So this should be further investigated. If you could provide the Foxx app (if it's doing more with the collection than shown in the above code snippet) and the collection definitions (indexes etc.) that would be great, because it may help us finding the root cause.

Potential improvements for this are included in 2.7.4. That version has a garbage collection modification that will collect document references held by V8 in all V8 contexts eventually, which may have been a source for the compaction being stalled. It also contains a fix for the compaction not making any progress when an unload of a collection is attempted and the collection is used again before the unloading starts. That version also allows querying the compaction status via a collection's figures() command, and its output is also shown in the web interface (by the i icon for a collection).

Datafile statistics have been re-implemented in 2.7.5 and 2.8.0-beta8. That means the number of alive (and dead) documents should be much more accurate in the versions, and the number of datafiles should not grow substantially in the long run, provided the number of live documents stays about constant.

I can confirm, the compaction seems to work now, both in 2.8.0-beta8 and 2.7.5, we have them both installed on 2 separate machines.
Thank you!


WIP msglist: Support @-mentions narrow

Early prototype to support @-mentions narrow.
TODO:

Organize the commits
Evaluate ways to support wildcardMetnioned, channelWildcardMentioned and topicWildcardMentioned with backwards/forward compatibility.
Test cases

Fixes #250

Reading this chat thread gives me some background on why we need the topic_wildcard_mentioned flag (which is to provide necessary information to determine if the @topic mention needs to be highlighted for the user).
Looks like we don't support rendering topic mentions yet, but I think we can skip that for now as @-mentions narrow doesn't rely on this feature.

Regarding whether we should support both stream_wildcard_mention and the potential future channel_wildcard_mention at the same time, I think the answer is no if the server is going with this migration strategy. Likely at that point we will add a client capability, but we shouldn't worry about it now.

Looks like we don't support rendering topic mentions yet, but I think we can skip that for now as @-mentions narrow doesn't rely on this feature.

Yeah, it's fine to leave that flag out if it isn't needed for this feature.
If it's easy to include it, though, then it's probably less total work if we include it now than if we add the other flag now and that flag separately later.

Yeah agreed, let's not try to include support for a future channel_wildcard_mention flag at this point.

When working on this, I found exhaustiveness checks useful to covering places that need to be updated when adding a narrow. For addings tests, having each file corresponds to a test file helped, but I also needed to do a sweep by searching for CombinedFeedNarrow.
Bookkeeping comments like "TODO other narrow types: starred, mentioned; searches; arbitrary" will be a lot more helpful if we use them more consistently at places. However, it is understandable that the cases for different narrows can be pretty different. We can't know in advance all the time. We likely won't be adding a lot of narrows, so it should be fine without other actions taken.

I read the comment on the weird corner-case when messages might be absent in mentions, and it appears to me that it wouldn't interfere with this feature change.

For addings tests, having each file corresponds to a test file helped, but I also needed to do a sweep by searching for CombinedFeedNarrow.
Bookkeeping comments like "TODO other narrow types: starred, mentioned; searches; arbitrary" will be a lot more helpful if we use them more consistently at places. However, it is understandable that the cases for different narrows can be pretty different. We can't know in advance all the time.

Yeah, I think it's OK to have to search for existing similar cases (like CombinedFeedNarrow) when adding a new type like this.
That TODO line wasn't meant for the purpose of finding all the different places that different types of narrows will need to be handled. It'd be pretty tough to have such comments comprehensively enough to rely much on them — as you saw, there are a lot of places that need updating. If you run the command git log -p -S 'TODO other' lib/model/narrow.dart (and use my "secret" for reading git log -p output), you can see the history of that line; it was added as part of a very early sketch, and at this point should probably just be deleted in favor of the issues we have for adding more narrow types.
It would be good to make it so that those exhaustiveness checks were a more comprehensive guide. I think that mostly means factoring out all the conditions that look like this:
narrow is CombinedFeedNarrow || narrow is MentionsNarrow
into a method somewhere that says whether we offer a compose box for a narrow, and that is exhaustive by construction.
Probably the most natural home for that is as a static on ComposeBox. That'll mean the one spot in lib/model/ (on autocomplete) can't use it; but that one spot isn't really used right now anyway, and I think once it is it'll naturally involve an exhaustive switch too.

Rebased this atop #808, and extracted the is CombinedNarrow checks to ComposeBox.hasComposeBox.

Rebased to resolve the merge conflicts from the markNarrowAsUnread refactor.

Thanks for the reminder! Added support for parsing the internal links and updated the PR.

Will get back to this next week and complete the update.

Home menu
Mentions page

Updated the PR to

resolve the review comments
take care of some places where "channel" can be used, depending on the context
make the last commit to fix the issue instead

Pushed to address the switch case change. Should be ready once it passes the tests.

Thanks! Looks good — merging, with a couple of tweaks. See the added commit; and I fixed a couple of summary prefixes from "internal" and "internal_links" to "internal_link". ("Internal" sounds like some much more general meaning — like anything internal to the app.)


Use new rescue-related extension methods across all relevant quests

https://github.com/AzerothWarsLR/WarcraftLegacies/pull/139 introduced a useful set of extension methods for dealing with preparing bases for rescue in quests, and for rescuing those bases later. We have:
RectangleExtensions.PrepareForRescue to make a group of units invulnerable and put them into a collection.
and
PlayerExtensions.RescueGroup to rescue those units later when the quest is over.
This ticket is to ensure that these methods are used throughout Quest code where appropriate. E.g. this highlighted block of code in QuestKilsorrow.cs could be replaced with PrepareForRescue:

Closing as stale.


False positive in Style/NegativedIf/Style/NegatedUnless

I'm not sure if this is a bug with Style/NegatedIf/Style/NegatedUnless or this is just how they were designed to work and a new cop/config flag would need added. I like that if !/unless ! gets replaced with the respective unless/if, but I would also like if x != y/unless x != y to also get replaced with the respective unless x == y/if x == y.

Expected behavior
# Bad
if x != y
  # code
end
unless x != y
  # code
end

# Good
unless x == y
  # code
end
if x == y
  # code
end

Actual behavior
Rubocop didn't complain about any of the following
if x != y
  # code
end

unless x != y
  # code
end

unless x == y
  # code
end

if x == y
  # code
end

Steps to reproduce the problem
Create a file with the above conditions and see no rubocop errors from any of them.
Minimal Config:
AllCops:
  NewCops: disable
  TargetRubyVersion: 3.0.1
  ActiveSupportExtensionsEnabled: true

Style/NegatedIf:
  Enabled: true
  EnforcedStyle: both
Style/NegatedUnless:
  Enabled: true
  EnforcedStyle: both

RuboCop version
1.43.0 (using Parser <IP_ADDRESS>, rubocop-ast 1.24.1, running on ruby 3.0.1) [aarch64-linux]
  - rubocop-rails 2.17.4

I tested again with the 1.45.1 release
1.45.1 (using Parser <IP_ADDRESS>, rubocop-ast 1.24.1, running on ruby 3.0.1) [aarch64-linux]
  - rubocop-rails 2.17.4

This would be false negatives, not false positives. The Style/Negated* cops is for detecting unary operator like !foo, not binary operator like foo != bar. Also if foo != bar is allowed because it might be intended. On the other hand, double negation such as unless foo != bar is detected by Style/InvertibleUnlessCondition cop. The cop is disabled by default, so enable it explicitly if needed.
https://github.com/rubocop/rubocop/pull/11432


GitHub Team for maintainers

Having a GitHub team like @warm-metal/maintainers would make it easy for people creating issues or pull requests to tag the maintainers and bring attention to a particular issue/PR.

@kitt1987 I don't have access for creating a team in this organization. Could you please create one for us.

@kitt1987 I don't have access for creating a team in this organization. Could you please create one for us.

Sure. @warm-metal/csi-maintainers is ready for this. You've been invited as the team owner.

@warm-metal/csi-maintainers is ready for this. You've been invited as the team owner.

@kitt1987 could you please check if the permissions are set correctly for this team? Cause I see an error in the PR I raised for updating CODEOWNERS.

I just assigned a Maintain role to the team. I think it should work now.

I just assigned a Maintain role to the team. I think it should work now.

Yep, it seems to be functional now. Don't see any more error from GitHub. Going ahead and merging the PR.


Add BSD to the list of allowed licenses

Needed for postgresql dependency

Looking at these, this change makes sense to me:
https://choosealicense.com/licenses/bsd-2-clause/
https://choosealicense.com/licenses/0bsd/
https://choosealicense.com/licenses/bsd-3-clause-clear/
https://choosealicense.com/licenses/bsd-3-clause/
https://choosealicense.com/licenses/bsd-4-clause/


06/18 Demo Branch

Creating branch for 06/18 demo to show just NM

@NatHillardUSDS I know this is labeled draft and titled "Demo Branch" -- are you planning to close this after today or use this as a base for tackling a future/existing ticket?

yes, only created this to get a ci/cd build / post artifacts remotely. will take learnings here and harden / produce actual mergeable code

Took out more tentative comments, left in-progress work. This can be seen as the first step in addressing https://app.zenhub.com/workspaces/justice40-60993f6e05473d0010ec44e3/issues/usds/justice40-tool/182

With the latest fix for #205 , I'm going to revert back to using ol-mapbox-style instead of native OpenLayers components. I will take / incorporate all the feedback from this PR, but the change to use OLMS is big enough that it probably makes sense to close this branch and address directly in a separate PR


flat buttons color consistency

Not sure If I am goofing up on my code...
if I do color, disabled color on example code both in the Platformflatbutton and the androidflat I should I think get both disabled same color aqs in the example onPress is null...on ios I get color as the button color not disabledColor and if I set the onPress to non null I get no corolor android...not immediate however but something to look at

found my error, in my flat button I should have still cupetinobuttondata while using androidflat data soits a doc not clear not code problem


This repo doesn't have  a go mod file so it will not work in vscode

Go: master
Extension: 0.11.7
vscode: 1.39.2
Installing 17 tools at /Users/gert/go/bin
  gocode
  gopkgs
  go-outline
  go-symbols
  guru
  gorename
  gotests
  gomodifytags
  impl
  fillstruct
  goplay
  godoctor
  dlv
  gocode-gomod
  godef
  goimports
  golint

Installing github.com/mdempsky/gocode SUCCEEDED
Installing github.com/uudashr/gopkgs/cmd/gopkgs SUCCEEDED
Installing github.com/ramya-rao-a/go-outline SUCCEEDED
Installing github.com/acroca/go-symbols SUCCEEDED
Installing golang.org/x/tools/cmd/guru SUCCEEDED
Installing golang.org/x/tools/cmd/gorename SUCCEEDED
Installing github.com/cweill/gotests/... SUCCEEDED
Installing github.com/fatih/gomodifytags SUCCEEDED
Installing github.com/josharian/impl SUCCEEDED
Installing github.com/davidrjenni/reftools/cmd/fillstruct SUCCEEDED
Installing github.com/haya14busa/goplay/cmd/goplay SUCCEEDED
Installing github.com/godoctor/godoctor SUCCEEDED
Installing github.com/go-delve/delve/cmd/dlv SUCCEEDED
Installing github.com/stamblerre/gocode FAILED
Installing github.com/rogpeppe/godef SUCCEEDED
Installing golang.org/x/tools/cmd/goimports SUCCEEDED
Installing golang.org/x/lint/golint SUCCEEDED

1 tools failed to install.

gocode-gomod:
Error: Command failed: /usr/local/go/bin/go build -o /Users/gert/go/bin/gocode-gomod github.com/stamblerre/gocode
can't load package: cannot find module providing package github.com/stamblerre/gocode: working directory is not part of a module

The issue should be fixed in VSCode, but I've added a go.mod to this repository as well.


Content class in Lua, for loading and managing loaded things

Probably needed for loading jpgs, BGM, etc

Not needed currently, moving to backlog


Unable to use existing secret

Kubernetes Version
v1.26.3+k3s1
Helm Chart Version
0.10.0
Helm Chart configuration
---
apiVersion: helm.toolkit.fluxcd.io/v2beta1
kind: HelmRelease
metadata:
  name: ngrok
  namespace: networking
spec:
  install:
    crds: CreateReplace
  interval: 5m
  chart:
    spec:
      chart: kubernetes-ingress-controller
      version: 0.10.0
      sourceRef:
        kind: HelmRepository
        name: ngrok
        namespace: flux-system
      interval: 5m
  values:
    credentials:
      apiKey:
        valueFrom:
          secretKeyRef:
            name: ngrok-secrets
            key: apiKey
      authtoken:
        valueFrom:
          secretKeyRef:
            name: ngrok-secrets
            key: authtoken

What happened
Usually one can use valueFrom to get a key from already existing secret, but it seems that's not supported in the helm chart. Instead it throws an error:
NAME                    REVISION        SUSPENDED       READY   MESSAGE
ngrok                                   False           False   Helm install failed: template: kubernetes-ingress-controller/templates/credentials-secret.yaml:9:83: executing "kubernetes-ingress-controller/templates/credentials-secret.yaml" at <b64enc>: wrong type for value; expected string; got map[string]interface {}

What you think should happen instead
I think it should be a supported configuration to get it from an existing secret, or have an way to tell it properly the existing secret name for the values and not rely on generating it from values.
How to reproduce
Current helm-release can be seen here: https://github.com/samip5/k8s-cluster/blob/f6ebf02927b7d9b7773f05b55226202e95704475/cluster/apps/networking/ngrok/app/helm-release.yaml
There's also the sops secret that's encrypted and decryption is handled by Flux & sops.

@samip5, thanks for reporting the issue. We don't currently support the valuesFrom format you are mentioning for the API Key and Auth Token to pull them from arbitrary keys(would be a good enhancement). The helm chart does support taking them both from a single, existing secret though.
You can create a secret like the following:
apiVersion: v1
kind: Secret
metadata:
  name: your-secret-name
  namespace: <same-namespace-as-ngrok-ingress-controller>
data:
  API_KEY: "YOUR-API-KEY-BASE64"
  AUTHTOKEN: "YOUR-AUTHTOKEN-BASE64"

And then reference the existing secret in the values.yaml like so:
credentials:
  secret:
    name: "your-secret-name"

Seems that indeed works.


Kubernetes

This issue tracks migrating from docker-compose to Kubernetes

This was not needed and had no clear benefits even after implementing it. The advice received to implement this was exaggerated.


Update F# Language Reference for F# 4.1 constructs

Struct stuff

[x] Struct Tuples - https://docs.microsoft.com/en-us/dotnet/articles/fsharp/language-reference/tuples
[ ] Struct Records - https://docs.microsoft.com/en-us/dotnet/articles/fsharp/language-reference/records
[ ] Struct DUs - https://docs.microsoft.com/en-us/dotnet/articles/fsharp/language-reference/discriminated-unions
[ ] Structs (talk about the above and link to them) - https://docs.microsoft.com/en-us/dotnet/articles/fsharp/language-reference/structures

Literals

[ ] Numeric Literals - https://docs.microsoft.com/en-us/dotnet/articles/fsharp/language-reference/values/

Keywords

[ ] fixed support (perhaps new article)- https://docs.microsoft.com/en-us/dotnet/articles/fsharp/language-reference/keyword-reference
[ ] Result (new article)
[ ] namespace rec and module rec - namespaces, modules, and perhaps new article about recursive definitions
[ ] Consuming ref returns - https://docs.microsoft.com/en-us/dotnet/articles/fsharp/language-reference/reference-cells
[ ] Optional Arguments (Optional and DefaultValueParameter attrs) - https://docs.microsoft.com/en-us/dotnet/articles/fsharp/language-reference/functions/ ??
[ ] SRTP (use type name in definition) - https://docs.microsoft.com/en-us/dotnet/articles/fsharp/language-reference/generics/statically-resolved-type-parameters

In the discussion on structs, it might be worth noting when one can, or can not, explicitly control the layout of the struct. This technique is often used when inter-operating with unmanaged code (i.e. Platform/Invoke). It also makes for a very simple binary (de)serializer. From my informal tests, this is mostly a "gotcha" with multiple-case struct unions (as reported in #2647). However, I've not tested single-case struct unions or struct tuples. Meanwhile, struct records and struct classes (is that the correct term?) seem to behave as expected.

#1916

@cartermp is this done? all subtasks are marked as done.

Yup!


Password on prompt

PR with a minor change to prompt for user password instead of providing it in plain text ... is this needed ?

This seems like a small (but important) contribution, so no Contribution License Agreement is required at this point. We will now review your pull request.
Thanks,
Microsoft Pull Request Bot

@amolthacker, thanks for signing the contribution license agreement. We will now validate the agreement and then the pull request.
Thanks, Microsoft Pull Request Bot

I think we should push people to use ssh key more than password but this will make it better anyway. We should change the add-user also to stay consistent

good point @timotheeguerin ... i went back and checked ... I thought the bug was relevant for a couple of test cases .. made a few changes and as suggested have this applicable for add_user too

Fixed by #116


Fabric Server Crashed because of LoadMyChunks mod.

Mod Version
LoadMyChunks-LOADMYCHUNKSVER-MINECRAFTVER
What were you doing before the crash happened?
i downloaded the mods, place them in mod folder and started the server and gave error in load my chunk mod.
**Provide Logs here: (https://api.mclo.gs/1/raw/i6aCfSW) **

This is not your fault, its mine.
Problem is caused by line
"NetworkManager.registerReceiver(NetworkManager.Side.S2C,LagReadingPacket.TYPE,LagReadingPacket.STREAM_CODEC,LagReadingPacket::handleClient);" in main class.
Needs to be moved to client side initialization. Will push an update soon.

Issue is present only in 1.20.6 and 1.21.

Hotfix files uploaded to Curse and Modrinth. Currently under review on curseforge.


peerDependencies warning with latest npm

With npm 2.7.1 I get the following warnings:
npm WARN peerDependencies The peer dependency<EMAIL_ADDRESS>included from grunt-easy-rpm will no
npm WARN peerDependencies longer be automatically installed to fulfill the peerDependency
npm WARN peerDependencies in npm 3+. Your application will need to depend on it explicitly.

This is now removed as of the 1.5.4 release.

thanks


SP-2199 - Patch grpc #minor

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 72.65%. Comparing base (f35d654) to head (3b7aa2c).

Additional details and impacted files
@@           Coverage Diff           @@
##             main     #551   +/-   ##
=======================================
  Coverage   72.65%   72.65%
=======================================
  Files         113      113
  Lines        3862     3862
=======================================
  Hits         2806     2806
  Misses        742      742
  Partials      314      314

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.


fixed URL problems

adoc when seeing a "," in a URL interprets the next "=" - inour case, syntax is not recognized by adoc so the remaining part of the URL is suppressed, making it incomplete. Found no way to substitute silently, therefore an explicit change has been implemented.

Included in the December-26-Updates branch.


Proposed new version of file portfile.cmake

To contain latest release of cppwinrt (this is my first time doing this so please advice)

@juandent,
Thanks for your contribution.
To ensure that the project team has proper rights to use your work, please complete the Contribution License Agreement at https://cla.microsoft.com.
It will cover your contributions to all Microsoft-managed open source projects.
Thanks,
Microsoft Pull Request Bot

@juandent, thanks for signing the contribution license agreement. We will now validate the agreement and then the pull request.
Thanks, Microsoft Pull Request Bot

Thanks for the PR!
In order for your changes to affect the port, you'll need to modify the actual portfile.cmake instead of creating a new one.
Please replace the existing portfile.cmake with your new-portfile.cmake, check that everything builds fine (vcpkg remove cppwinrt then vcpkg install cppwinrt), then push the changes to your patch-1 branch and this PR will be automatically updated.

Closing due to the new PR: #1781


Convert to using service layer

This PR refactors the code to use a new service layer for actors and posts:

Replace direct database access with service methods to improve modularity and separation of concerns.
Remove the repository layer as it's now redundant with the service layer.
Update model definitions to reflect changes in primary keys and fields.
Adjust queue processing to utilize the new service layer for actor and post handling.
Add error handling where necessary and ensure proper logging of errors.

NOTE: This is still very much WIP (doesn't even pass tests as of time of PR creation). I'm simply opening a PR for early feedback

Ok @devanbenz, I think I am done here. There is likely more that can be done, but I think this is "good enough". I do want to add in tests but I will do that in a separate PR so this can get merged in (unless you see something that should get updated)


Fix readme and set connection-test as default

Closes #6
Signed-off-by: Guilherme Campos Camargo<EMAIL_ADDRESS>

Split into two commits.


Your library clashed with Material Drawer, BIG PROBLEM. https://github.com/mikepenz/MaterialDrawer

Your library clashed with Material Drawer, BIG PROBLEM.
https://github.com/mikepenz/MaterialDrawer
To make it simple, there's 2 big problem

If i set your library before MaterialDrawer, your library FAB button doesn't do anything.
If i set Material Drawer then your library, everything works, but your buttons are the one that gets clicked instead of the items in the MaterialDrawer items, it seems your "z-index" items are higher than the items in the materialDrawer.

Great library though, but i can't use it because MaterialDrawer is very important for my project.

and oh, if i press your button fast enough in Lolipop Samsung Note 5, some of the items stayed instead of disappearing. Seems there's a bug in the animation that makes some of the items stay visible instead of "gone"

Thanks for your advice, I will fix it in the next few days.

Nice. Please do this issue first, haha :+1:
Because i really wanted to use it


Create new directory for codes in Dart language.

🚀 Feature
A new folder and some starter codes for Dart programming language.
(A clear and concise description of what the feature is.)
Have you read the Contributing Guidelines on Pull Requests?
Yes
(Write your answer here.)
Motivation
Flutter has gained a lot of popularity and with the coming of Flutter 2, we can use one Flutter codebase for multiple platforms. People starting out in flutter would be benefitted and get to know how the Dart language works.
(Please outline the motivation for the proposal.)
I would like to work on this as a part of GSSOC '21

@iamrajiv @siddharth25pandey can I work on this for GSSOC '21? I am good at Dart so I will start adding algorithms too.


Corrected a response of AcceptOwnershipStatus by adding provisioninState field

Contributing to the Azure SDK
Please see our CONTRIBUTING.md if you are not familiar with contributing to this repository or have questions.
For specific information about pull request etiquette and best practices, see this section.

Closing the PR as long as the track 2 contains what we want to update.


Automatically determine the environment

Hi!
This is a wonderful lib that I use in https://github.com/different-ai/embedbase/tree/main/sdk/embedbase-js
I was wondering if it could be possible to automatically determine the environment and import accordingly (e.g. browser, nextjs, vercel edge, etc)? It would be really great and reduce verbosity. Happy to contribute

Hello @louis030195!
I believe it could be possible through exports field in package.json, where we could specify different entrypoint for a different engine: https://runtime-keys.proposal.wintercg.org/
I do think it does necessitate an API change, exposing a magic init() function which will perform the import() of WASM files when needed (?module suffix for Vercel etc).
At the moment I'm swarmed with a lot of work, but if you want to take a knack at it, would love to help 😃

Interesting, btw do you know how to unit test different environment? Maybe https://edge-runtime.vercel.app/packages/vm?
ATM found this hack somewhere (probably from you) which works both in node and vercel:
export async function getEncoding(
    encoding: TiktokenEncoding,
    options?: {
        signal?: AbortSignal;
        extendedSpecialTokens?: Record<string, number>;
    }
) {
    if (!(encoding in cache)) {
        cache[encoding] =
            getFetch()(`https://tiktoken.pages.dev/js/${encoding}.json`, {
                signal: options?.signal,
            })
                .then((res) => res.json())
                .catch((e) => {
                    delete cache[encoding];
                    throw e;
                });
    }
    const enc = new Tiktoken(await cache[encoding], options?.extendedSpecialTokens);
    // // @ts-ignore
    // const registry = new FinalizationRegistry((heldValue) => {
    //     heldValue.free()
    // });
    // registry.register(enc);
    return enc
}

I'm not 100% sure where the .free() went, bit afraid of memory leaks

Some preliminary work has been done here: https://github.com/dqbd/package-exports-edge, where different dev environments are setup.
The snippet was most likely from the recent PR done on LangChain, where I've swapped the WASM bindings with a JS port instead (js-tiktoken). The rationale was the excessive bundle size and relative complexity to get started with LangchainJS: https://github.com/hwchase17/langchainjs/pull/1239. That is why no .free() is needed 😄
You might want to consider swapping the implementation as well, considering the trade-offs such as worse performance (around 5x slower, although a PR can reduce the difference to just 2.5x slower).


Switch badges for Rockets - Conditional components

### Project Requirement

Add styles classes to buttons.
Implement one more button into the Rockets component to manage the cancel action.
Implement one handler to manage the cancel action.
Apply styles to the button "Reserve Rocket" and the tag "reserved".
Use CSS classes to toggle the presentation of the button in the rockets list.
Add element  previous to the rocket description to show when each rocket is reserved.

Approved 👏
Your project is complete!  There is nothing else to say other than... it's time to merge it :shipit:
Congratulations! 🎉

Cheers and Happy coding!👏👏👏
Feel free to leave any questions or comments in the PR thread if something is not 100% clear.
Please, remember to tag me in your question so I can receive the notification.


Can't rename INBOX

Current master disallows renaming INBOX (here), returning the error NO not rename inbox
This seems to be in conflict with the IMAP standard.
Here is the relevant paragraph from RFC3501:
Renaming INBOX is permitted, and has special behavior.  It moves
all messages in INBOX to a new mailbox with the given name,
leaving INBOX empty.

RIMS ignores a RFC's behavior of renaming an INBOX mailbox.
I think that it brings almost no merit to RIMS.
Therefore I had decided that RIMS disallows removing or deleting an INBOX mailbox to avoid INBOX mailbox lost.
This implementation is more simple and more easy than RFC's behavior.
And it brings merit to me that code and test are easy.

The RFC indicates that the INBOX will always exist during RENAMEs: the contents are simply moved to a new mailbox (and DELETE for INBOX is an error).
I believe RENAME INBOX could be implemented in RIMS without changing any internals - simply by using existing commands (CREATE, COPY, STORE and CLOSE). That would also mean that internals tests would not change - there would only be a change to protocol.rb (and its tests). The advantage would be that RIMS could continue to be compliant to the RFC.
Would you be interested in a pull request that implements this behaviour?

I think the idea of "the contents are simply moved to a new mailbox" is not good.
For example, I assume that there are billion mails in a mailbox.
Renaming the ordinary mailbox that includes billion mails is immediately done.
But renaming INBOX mailbox that includes billion mails is not immediately done.
It may take long time (tens of minutes or several hours or perhaps a day!).
I think that taking long time for the processing that expects that a user will end it immediately is wrong.
Returning an error immediately is better than not returning.

Thanks for your reply.
I think it is important for RIMS to indicate that it does not follow the standard in this aspect, for example in the README, otherwise users may be surpised by non-standard behaviour.


Items to address before publishing in Steampipe Hub

Please add the goreleaser.yaml.  You can copy the one from steampipe-plugin-vault, but edit id the line to say id: "steampipe-gitlab"
Please make sure you test against the cloud version of gitlab as well as your local version.  The plugin should work with both, but the cloud version will reveal some multi-tenant considerations that you must address.
For instance, many APIs return ALL items by default.  While this may be sufficient in a private instance, the scale of the shared cloud version will make paging through all the results unfeasible in any practical way. For example, select * from gitlab_project returns ALL the public projects, in addition to your own private projects.  We have addressed this in the github plugin with the my pattern - you will see that we have split some apis into  2 tables, one which requires a qualifier but will return ANY items, and one that does not that only returns "your" resources.  As an example, the github_repository table can return information about ANY public repo, but you must specify where full_name=, whereas the the github_my_repository  does NOT require a qualifier, but only returns repos that you own or contribute to.  Please try to use this pattern as well - let me know if you have questions.
Paging seems to be broken, at least against the cloud version.  I did not test all tables, but select * from gitlab_project and select * from gitlab_user both return only the first 30 items.

Hi John,
I've added a goreleaser.yml file as requested.
I have looked into the paging issue with the cloud version (gitlab.com) this was due to the way it doesn't calculate total pages and thus omits this header in the response, have adjusted all usages to work with the next page value instead.
I have provided my tables for issues and projects since these two are the ones that will cause issues when searching without qualifiers on cloud. (group, snippets, etc default to be only those associated with the user).
However as a caveat to this I haven't required any qualifiers on the gitlab_issue / gitlab_project / gitlab_user tables, since our use-case requires being able to search across everything within our private instance - I did add comments to the documentation about not recommended to use these tables without qualifiers due to performance reasons.


Add notes for Chocolatey CLI 2.2.1

Description Of Changes
Add release notes for Chocolatey CLI v2.2.1.
Motivation and Context
There is a release coming up, and we need to get this documented.
Testing

[x] I have previewed these changes using the Docker Container or another method before submitting this pull request.

Change Types Made

[ ] Minor documentation fix (typos etc.).
[x] Major documentation change (refactoring, reformatting or adding documentation to existing page).
[ ] New documentation page added.

Change Checklist

[ ] Requires a change to menu structure (top or left hand side)/
[ ] Menu structure has been updated

Related Issue
N/A

@AdmiringWorm @pauby this is ready for review, however, please don't merge once the review is complete.  I will do this when everything else is ready.


Updated xdrip-js, Lookout, and Logger locations

xdrip-js, Lookout, and Logger are now hosted in the xdrip-js organization.

Thanks! This LGTM but keep wanting to ask "BG data is sent to both OpenAPS (via xDripAPS) locally," since we're discontinuing xdripAPS, I think, the references to xdripAPS need removing on this page, too? (@scottleibrand correct me if I'm wrong)

As I understand it, xdripaps will still exist, we just won't upload from the rig to NS (xDrip+ has to do that).

Lookout and Logger should both be good to go with the OpenAPS change. Both upload BG data directly to NS in addition to sending it to OpenAPS via xDripAPS.
Logger supports back filling NS when connectivity is down, and I'm currently testing a branch for Lookout to back fill NS.
@efidoman (Logger) and I (Lookout) are both running oref0-ns-loop instead of the old openaps ns-loop without any issues.


Minor bugfixes

Coverage decreased (-0.2%) to 96.404% when pulling 70109d22df88b0043cf115bcf5d81b0b9da676bb on DASPRiD:feature/data-api-rewrite into f2b25df9177d688e9411387f4ff4d658aa62691e on soliantconsulting:develop.


Generated empty locales file after execute eclint command.

Hi, I think eclint is good tool and useful to me 🎉 . Thank you for developing this tool.
Now, I tried to execute following steps and got error, So I just report it in this issue.

in macOS sierra, and os lang is ja_JP
Error case
$ npm install -g eclint
$ cd path/to/project
$ eclint ( or eclint --help or eclint --version )

After executed above steps,  empty jp_JP.json is generated.
/usr/local/lib/node_modules/eclint/locales/:[]: ls

result
en.json     ja_JP.json  zh_CN.json  zh_TW.json

and that is empty file.
$ wc ja_JP.json
       0       0       0 ja_JP.json

After executed this steps, any commands dump parse errors.
$ eclint
/usr/local/lib/node_modules/eclint/node_modules/y18n/index.js:79
    else throw err
         ^

SyntaxError: syntax error in /usr/local/lib/node_modules/eclint/locales/ja_JP.json
    at JSON.parse (<anonymous>)
    at Y18N._readLocaleFile (/usr/local/lib/node_modules/eclint/node_modules/y18n/index.js:72:25)
    at Y18N.__ (/usr/local/lib/node_modules/eclint/node_modules/y18n/index.js:26:38)
    at Object.<anonymous> (/usr/local/lib/node_modules/eclint/dist/cli.js:187:12)
    at Module._compile (module.js:569:30)
    at Object.Module._extensions..js (module.js:580:10)
    at Module.load (module.js:503:32)
    at tryModuleLoad (module.js:466:12)
    at Function.Module._load (module.js:458:3)
    at Module.require (module.js:513:17)
    at require (internal/module.js:11:18)
    at Object.<anonymous> (/usr/local/lib/node_modules/eclint/bin/eclint.js:3:11)
    at Module._compile (module.js:569:30)
    at Object.Module._extensions..js (module.js:580:10)
    at Module.load (module.js:503:32)
    at tryModuleLoad (module.js:466:12)

Normally case
If execute eclint check command in first, jp_JP.json file is generated that  include en contents.
$ cat ja_JP.json

{
  "Usage: $0 <command> [files...] [options]": "Usage: $0 <command> [files...] [options]",
  "Validate that file(s) adhere to .editorconfig settings": "Validate that file(s) adhere to .editorconfig settings",
  "Fix formatting errors that disobey .editorconfig settings": "Fix formatting errors that disobey .editorconfig settings",
  "Infer .editorconfig settings from one or more files": "Infer .editorconfig settings from one or more files",
  "CommandError: Missing required sub-command.": "CommandError: Missing required sub-command.",
  "Indentation Style": "Indentation Style",
  "Indentation Size (in single-spaced characters)": "Indentation Size (in single-spaced characters)",
  "Width of a single tabstop character": "Width of a single tabstop character",
  "Line ending file format (Unix, DOS, Mac)": "Line ending file format (Unix, DOS, Mac)",
  "File character encoding": "File character encoding",
  "Denotes whether whitespace is allowed at the end of lines": "Denotes whether whitespace is allowed at the end of lines",
  "Denotes whether file should end with a newline": "Denotes whether file should end with a newline",
  "Forces hard line wrapping after the amount of characters specified": "Forces hard line wrapping after the amount of characters specified",
  "Block comments start with": "Block comments start with",
  "Lines in block comment start with": "Lines in block comment start with",
  "Block comments end with": "Block comments end with"
}

After executed eclint check  command in first, Any commands are normally work.
Thanks. 😄

I will work for this.

Upstream bug: yargs/y18n#48

Fixed on PR yargs/y18n#49

@yutakakinjyo Would you like to translate en.json into Japanese?

@yutakakinjyo
Fixed in latest stable version.
Would you please translate en.json into Japanese?


UI: snapshot tree: system generated snapshot should be hidden by default

If Create By User is false, the snapshot should be hidden by default. It should be only revealed if Show System Hidden is chosen.
Once it's revealed, it should be shown different from removed=true snapshots or user-created snapshots. The user won't be allowed to revert to it, but unlike removed snapshot, delete is allowed for the system created snapshots once it's revealed.

Show System Hidden stopped working after page reload,

Steps to reproduce this behavior:

create pod using
kubectl create -f https://raw.githubusercontent.com/rancher/longhorn/master/examples/pvc.yaml
delete replica, to generate a snapshot with Created By User: false,
reload the page.

Result:
Show System Hidden stopped working.

@meldafrawi I followed your steps, but the bug did not recur. May I ask if the version of UI is the latest? This is the address of my project http://<IP_ADDRESS>:32175/volume/pvc-03f90a2c-695b-11e9-85c9-063587d8a228

@smallteeths
I'm using latest longhorn-ui images exited on docker hub
image: rancher/longhorn-ui:241599b

@meldafrawi Can you re-test with the latest Longhorn UI? Just run make with https://github.com/rancher/longhorn-ui to get the latest image built.

I've built a new Longhorn UI image, and re-tested.
The issue is resolved.
I'm closing the issue.


Is it possible to view websocket data(frames) from webui?

Hi @r3verser ,
We're just working on this feature, will be arrived soon.


New date components

Description

Added following components:

Week
Hour
Minute
Second

Changed components prefixed with interval_ to duration
Changed documentation to reflect Changes
Added more unit tests
Added documentation to run tests

@thoroc
Thank you for update the documentation！
I thought about the BC again, maybe we could make just a little adjustment
・keep the original day
・rename the new day based on the calculation of the week to dayofweek, or daybyweek
This will eliminates the BC
What do you think?

The change to the day component was to take the week into account and therefore removing 7 days per week. With that in mind reverting the change and adding a new day component should probably reflect that in the name. It feels that dayofweek or daybyweek doesn't reflect that.
Would mod_days (for modulo days) works?

@thoroc
Looks Great!
Thank you!