[BUG] Deadlock for RWX volume if an error occurs in its share-manager pod

Describe the bug (🐛 if you encounter this issue)
This is a regression introduced by https://github.com/longhorn/longhorn-manager/pull/2294 (for https://github.com/longhorn/longhorn/issues/7106).
When an error occurs in a share-manager pod, its phase transitions to completed. The share-manager controller is unable to restart the pod or update the status of the ShareManager CR because it continuously fails to contact the share manager process to attempt a remount.
Before https://github.com/longhorn/longhorn-manager/pull/2294, the share-manager controller did not attempt to contact the dead share manager process, so there was no deadlock.
To Reproduce

Install Longhorn v1.6.0-dev.
Deploy the example NGINX deployment (examples/rwx/rwx-nginx-deployment.yaml in the longhorn/longhorn repo).
Identify the share manager pod.
Kill NFS-Ganesha inside the share-manager pod:
kubectl exec -n longhorn-system share-manager-pvc-9216f564-379e-4fd8-861b-e335ccbe8211 -- pkill ganesha.nfsd
The share-manager pod remains in the completed phase and is not restarted.NAME                                                     READY   STATUS      RESTARTS   AGE
share-manager-pvc-9216f564-379e-4fd8-861b-e335ccbe8211   0/1     Completed   0          12m

The longhorn-manager pod repeatedly logs a failure to sync the share-manager.[longhorn-manager-nf4lv] W1122 17:36:53.403245       1 logging.go:59] [core] [Channel #727 SubChannel #728] grpc: addrConn.createTransport failed to connect to {Addr: "<IP_ADDRESS>:9600", ServerName: "<IP_ADDRESS>:9600", }. Err: connection error: desc = "transport: Error while dialing: dial tcp <IP_ADDRESS>:9600: i/o timeout"
[longhorn-manager-nf4lv] time="2023-11-22T17:36:53Z" level=error msg="Failed to sync Longhorn share manager" func=controller.handleReconcileErrorLogging file="utils.go:72" ShareManager=longhorn-system/pvc-9216f564-379e-4fd8-861b-e335ccbe8211 controller=longhorn-share-manager error="failed to sync longhorn-system/pvc-9216f564-379e-4fd8-861b-e335ccbe8211: failed to mount share manager pod share-manager-pvc-9216f564-379e-4fd8-861b-e335ccbe8211: rpc error: code = Unavailable desc = connection error: desc = \"transport: Error while dialing: dial tcp <IP_ADDRESS>:9600: i/o timeout\"" node=eweber-v125-worker-e472db53-9kz5b

The ShareManager CR's status is not updated. It still shows as running.NAME                                       STATE     NODE                                AGE
pvc-9216f564-379e-4fd8-861b-e335ccbe8211   running   eweber-v125-worker-e472db53-9kz5b   16m

Expected behavior
Before https://github.com/longhorn/longhorn-manager/pull/2294, the share-manager pod would be successfully restarted.
Support bundle for troubleshooting
There is a support bundle in the related CNCF Slack thread:
https://cloud-native.slack.com/archives/CNVPEL9U3/p1700618585865019
There are other issues in that support bundle as well, so the reproduce may be a bit easier to work with.
Additional context
After https://github.com/longhorn/longhorn-manager/pull/2294, in the share-manager controller, we always attempt a gRPC call to the share-manager pod to do a remount if status.state == running in the ShareManager CR.
https://github.com/longhorn/longhorn-manager/blob/3a66afaa7ec086f7f6ec6ebb10fd6797ac30830d/controller/share_manager_controller.go#L543-L545
However, we do not update the status.state of the ShareManager CR until AFTER this point in the reconcile loop.
https://github.com/longhorn/longhorn-manager/blob/3a66afaa7ec086f7f6ec6ebb10fd6797ac30830d/controller/share_manager_controller.go#L688-L711
So we indefinitely reconcile. We cannot do a remount because the share-manager pod is dead, and we cannot learn the share-manager pod is dead because we error out while attempting to reconcile.

A workaround is to manually update the status of the share manager resource to error.
kubectl -n longhorn-system patch lhsm pvc-b08581d7-f48c-4b27-8083-7f24b89ba4ea --type=merge --subresource status --patch 'status: {state: error}'

@derekbit let's add this issue to https://github.com/longhorn/longhorn/wiki/Outstanding-Known-Issues-of-Releases.

Verified pass on longhorn master(longhorn-manager 23a995) with test steps
Kill NFS-Ganesha inside the share-manager pod, share manager pod will restart and RWX volume worked well after share manager pod ready.

So is this being fixed in the NEXT bugfix release?

@voarsh2 Yes.

Good thing I didn't upgrade to this version (mostly, because I couldn't, because it takes you weeks to get the Helm Chart updated), so I guess I wait another month or so for you to upgrade the Helm Chart twice..........)

Should we expect a quick release of 1.5.4 with this fix like we got for 1.5.3?

We will not have a quick release 1.5.4 following 1.5.3, because this scenario will only occur rarely, and also there is a workaround provided by @derekbit .  1.5.4 is still planned and will follow the regular release cadence, which is scheduled after 1.6.0.

Is it better to stay on 1.5.2 instead if we don't use the encrypted volumes?

Is it better to stay on 1.5.2 instead if we don't use the encrypted volumes?

That's what I want to know.......

We will not have a quick release 1.5.4 following 1.5.3, because this scenario will only occur rarely in a specific case, and also there is a workaround provided by @derekbit . 1.5.4 is still planned and will follow the regular release cadence, which is scheduled after the upcoming 1.6.0.

I'm confused, is https://github.com/longhorn/longhorn-manager/pull/2312 merged into 1.6.x then?
I don't know about you, but RXW workloads have given me hell in the past, and they sure do crash, so I'm thinking the 1.5.3 error that I might get, is more than probable......... ? So I shouldn't upgrade to 1.5.3 and wait 6 months for 1.6.x? (Just a guess, because I don't know your release schedule)

v1.6.0 is on the roadmap for Q4 2023: https://github.com/longhorn/longhorn/wiki/Roadmap#longhorn-v16-q4-2023.
It may not drop before the end of the year, but it is definitely coming sooner than later.

v1.6.0 is on the roadmap for Q4 2023: https://github.com/longhorn/longhorn/wiki/Roadmap#longhorn-v16-q4-2023.
It may not drop before the end of the year, but it is definitely coming sooner than later.

Ah yes, I think I'll wait then. :)
Don't want any more RXW related problems.

I added an alerting simple alerting rule for kube-prometheus-stack
---
apiVersion: monitoring.coreos.com/v1
kind: PrometheusRule
metadata:
  name: longhorn-issue-7183
  namespace: longhorn-system
spec:
  groups:
  - name: longhorn.rules
    rules:
    - alert: LonghornShareManagerOff
      annotations:
        description: Longhorn share manager count is off by {{$value}}. This is likely due to a recent bug in Longhorn. https://github.com/longhorn/longhorn/issues/7183#issuecomment-1823715359
        summary: Longhorn share manager count is off by {{$value}} for 5m.
      expr: count(sum by (namespace, persistentvolumeclaim) (kube_persistentvolumeclaim_access_mode{access_mode="ReadWriteMany"}) * on (namespace, persistentvolumeclaim) group_right kube_persistentvolumeclaim_info{storageclass=~"longhorn.*"}) - sum(kube_pod_info{namespace="longhorn-system", pod=~"share-manager-.*"}) > 0
      for: 5m
      labels:
        issue: Longhorn share manager count is off by {{$value}} for 5m.
        severity: critical

It simply counts the number of share-manager pods and the amount of PVCs with longhorn storage class and RWX access mode. This should alert most relevant cases. (Might be useful to explicitly check for state running, but I might add that later on.)

Given the (understandable) lack of releases in the past few days, I decided to add a little additional mitigation to the problem:
apiVersion: batch/v1
kind: CronJob
metadata:
  name: longhorn-hotfix-7183
spec:
  jobTemplate:
    spec:
      template:
        spec:
          serviceAccountName: longhorn-hotfix-7183
          containers:
          - image: docker.io/bitnami/kubectl:1.28
            name: longhorn-hotfix
            resources:
              requests:
                cpu: 10m
                memory: 128Mi
              limits:
                cpu: "1"
                memory: 256Mi
            command:
              - /bin/bash
            args:
              - -c
              - |
                for i in $(kubectl get lhsm -n longhorn-system --no-headers -o custom-columns=NAME:metadata.name); do
                  if kubectl get pods --no-headers -n longhorn-system "share-manager-$i" | grep -v Running; then
                    kubectl patch lhsm -n longhorn-system --type=merge --subresource status --patch 'status: {state: error}' $i
                  fi
                done
          restartPolicy: OnFailure
  schedule: '*/5 * * * *'
---
apiVersion: v1
kind: ServiceAccount
metadata:
  name: longhorn-hotfix-7183
---
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: longhorn-hotfix-7183
rules:
- apiGroups:
  - ""
  resources:
  - pods
  verbs:
  - get
- apiGroups:
  - "longhorn.io"
  resources:
  - sharemanagers
  - sharemanagers/status
  verbs:
  - patch
  - get
  - list
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: longhorn-hotfix-7183
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: longhorn-hotfix-7183
subjects:
- kind: ServiceAccount
  name: longhorn-hotfix-7183

This cronjob checks for running share-manager pods for each sharemanager object (assuming that all RWX shares are supposed to be mounted) and patch them as errored if this isn't the case.
It's not perfect and I didn't test it too much yet, but it's basically what I did for the alert above manually, now it's automated. :)
You can just kubectl apply -n longhorn-system -f [./path/to/above.yaml](https://git.shivering-isles.com/shivering-isles/infrastructure-gitops/-/raw/b230eb310e9f27e53d8dfba3fbaa9581a797795d/infrastructure/longhorn/hotfix-7183.yaml). Of course, use at your own risk.


Question: could not determine the dependencies of task ':app:mergeDebugAssets.'

I have been trying to run this application in android environment and keep getting this issue. Please help. This application was originally made for iOS and I am trying to optimize it for Android also.

Hey did you got any solution?


DA-4560: Dockerize the git connector

add dockerfile

Signed-off-by: linonymous<EMAIL_ADDRESS>

This is a bit unsecure approach as we need to add up the private key to fetch private packages to build the code inside container. Other possible way is to directly add up the binary file into the container & use the same.

I would go with the binary, also this repo is public, so I don't know what needs to be private in Dockerfile? Why not just build git, gitops and copy detect_removed_commits.sh into the smallest possible base image, like Alpine linux?

@lukaszgryglicki this repo is dependent upon lfx-events-schema which is a private repo & cant be built with go mod without github auth. So is the case. Building binary seems simple approach & would be a pretty light weight container.

So I would build on top of alpine linux - putting only required binaries and nothing more.

So I would build on top of alpine linux - putting only required binaries and nothing more.

yes, added it up.


Provider error logs not visibile

What problem are you facing?
Currently, the only way to identify if there are any operational errors that crossplane aws provider facing is to turn on DEBUG logging. Debug logging is verbose and is in non-json format.
Debug is off

Debug is On for same provider

For some reason cannot create only visible when debug flag is set, when clearly it should be an Error.
My understanding, by design Debug logs do support only plain text, as well as not something that should be used in production.

How could Crossplane help solve your problem?

Messages like cannot create and similar to be visible and have correct Error log level
Errors visible without --debug flag
Errors without --debug to be in json format by default

think you can see the error in events on the resource level ?

I might be missing something. Is this a feature e.g. not to stdout error logs? On which resource I should be able to see this error e.g. what the kubectl command by any chance and why debug and info level logging have such a different behaviour?

think you can see the error in events on the resource level ?

@haarchri Most of the times we see errors in resource level events, however sometimes if the managed resource object itself is not created by provider-aws/crossplane for some reason, then we cannot see such resource level events because no resource exists yet. For example, our composite resource should create, among others, an AWS KMS Key Alias as a managed resource, however for some unknown (yet) reasons, we don't see a resource in our K8s cluster under alias.kms.aws.crossplane.io resource types. There are no events related to this to indicate why crossplane/provider-aws couldn't create it, not even in the associated composite resource (or claim).
There are no logs in provider-aws indicating successful or failed attempts. I think the only way to know in this scenario is to enable debug logging in provider-aws.

Then you need crossplane core debug If the resources is created out of compositions not provider level

Yes thank you, debug logs of provider-aws did not indicate any problem I mentioned in my previous comment, but those of crossplane core did in fact show my problem. However, the original point in this issue probably still holds true - that debug logging had to be enabled to get a failure/error message.

^ Correct. This is fundamentally wrong behaviour. info level logging should not swallow any error level logging. Debug level is way too noisy and every log ingestion do cost resources.


Fix DynamicIndex implementation

Hello @JonathanMagnan,
Can you or a developer please take a look at this PR ?
This PR solves issue #448 but in order to fix that I had to remove the DynamicIndex logic which was introduced in 1.1.8 and use the original implementation (with a small change) to make sure that #397 keeps working correctly.
For that, I did enable the unittest again:
https://github.com/zzzprojects/System.Linq.Dynamic.Core/pull/480/files#diff-8c64d2f034f0d47405c4723ad04680f885cd71c73a5b0f498d04e95949789348L95
Please review the changes.

@StefH with following implementation I was able to get a robust solution for my problem as well as un-comment ExpressionTests_Select_DynamicObjects test
internal class DynamicGetMemberBinder : GetMemberBinder
{
    private static readonly Type DynamicWrapperType = typeof(DynamicWrapper);
    private static readonly ConstructorInfo DynamicWrapperConstructor = DynamicWrapperType.GetConstructor(new[] {typeof(object)});
    private static readonly PropertyInfo DynamicWrapperTypeIndexer = DynamicWrapperType.GetProperty("Item");

    public DynamicGetMemberBinder(string name, [CanBeNull] ParsingConfig config) : base(name, !(config?.IsCaseSensitive == true))
    {
    }

    public override DynamicMetaObject FallbackGetMember(DynamicMetaObject target, DynamicMetaObject errorSuggestion)
    {
        var instance = Expression.New(DynamicWrapperConstructor, target.Expression);
        var indexExpression = Expression.MakeIndex(instance, DynamicWrapperTypeIndexer, new Expression[] {Expression.Constant(Name)});
        return DynamicMetaObject.Create(target.Value, indexExpression);
    }

    private class DynamicWrapper
    {
        private readonly object _item;
        private readonly Dictionary<string, PropertyInfo> _properties;

        public DynamicWrapper(object item)
        {
            _item = item;
            if (item != null && !(item is IDictionary<string, object>))
            {
                _properties = item.GetType().GetProperties()
                    .ToDictionary(p => p.Name, d => d);
            }
        }

        public object this[string value]
        {
            get
            {
                if (_item is null)
                    throw new NullReferenceException();

                if (_item is IDictionary<string, object> dictionary)
                    return dictionary[value];

                if (_properties.TryGetValue(value, out var property))
                    return property.GetValue(_item, null);

                throw new InvalidOperationException();
            }
        }
    }
}

Hello @StefH ,
The PR looks good to me.


Pass Traceparent Header in custom http requests in lua scripts

I have opentelemetry configured in all my services.
Before every request goes to backend in krakend, I need to call an api A. Currently I am using lua script to call A, but traceid for that call A is different from rest of that flow. Upon banging my head for hours, I am unable to pass traceparent header to the request. I can pass traceparent header, if it is in the original request, though it is not my use case.
I want to access trace-id in lua scipt.

I have experience in c++, java, python, js, though little experience in go. But I need this urgently, please guide me, how to contribute and setup and find the relevant files to make this change.

Plugins have access to traceIds. E.g.:
ctx := req.Context()
spanCtx := trace.SpanContextFromContext(ctx)
logger.Debug("trace_id:", spanCtx.TraceID())


Register guards only for http requests

Guards should not be registered for CLI applications

Not sure if this is mergeable, I think ZfcRbac guards are also usable in CLI env.
Ping @bakura10

But right now if any guard is set, for any cli applications we have "Don't have permission" error

@thestanislav You can solve this by authenticating some identity (e.g. some worker) when running the application from CLI or overriding ZfcRbac\Guards service factory to return an empty array.
If I merge this one, I could break some applications that relies on ZfcRbac to protect their CLI.

This is definitely a BC break.
As danizord say, one option would be to authenticate your CLI requests. If you are using oauth token for instance, you could pass the key as part of your CLI requests to authenticate it.
As a side note, this is a reason why I prefer not to use guard, and only protect my controller directly. If you use guard or protect services, you run into this problem.
If you protect your controllers (which are the entry point of an API most of the time), then management become easier (as you'll have different controllers for console routes, where you can remove the check).
I'm therefore closing for now.


prototypejs: Init at <IP_ADDRESS>

Motivation for this change
I'm currently packaging FusionDirectory, and this is a dependency.
Things done

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

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

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

Failing check unrelated

@GrahamcOfBorg eval

@GrahamcOfBorg eval

Since you're not really building but just downloading a single file here, an alternative is to use fetchurl as a derivation directly:
{ stdenv, fetchurl, ... }:
let
  version = "<IP_ADDRESS>";
in
  fetchurl {
    name = "prototypejs-${version}.js";
    url = "https://ajax.googleapis.com/ajax/libs/prototype/${version}/prototype.js";
    sha256 = "...";
    meta = with stdenv.lib; { ... };
  }

Building this puts the downloaded file directly in the nix store under name. Just showing you this so you know about it. The way you did it is fine as well.

@xeji Thanks for that great hint! I rewrote and rebased it

@GrahamcOfBorg build prototypejs

Success on x86_64-darwin (full log)
Attempted: prototypejs
Partial log (click to expand)
these derivations will be built:
  /nix/store/ykky7r1v1wxjgfa8zldz10kyvcr1h380-prototype-<IP_ADDRESS>.js.drv
building '/nix/store/ykky7r1v1wxjgfa8zldz10kyvcr1h380-prototype-<IP_ADDRESS>.js.drv'...

trying https://ajax.googleapis.com/ajax/libs/prototype/<IP_ADDRESS>/prototype.js
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100  195k    0  195k    0     0   661k      0 --:--:-- --:--:-- --:--:--  661k
/nix/store/i91h5jak998m7kdbjbpfjvv7z4mwpxfa-prototype-<IP_ADDRESS>.js

Success on aarch64-linux (full log)
Attempted: prototypejs
Partial log (click to expand)
these derivations will be built:
  /nix/store/195i19192a8jxwaza761q16q1pqzxihr-prototype-<IP_ADDRESS>.js.drv
building '/nix/store/195i19192a8jxwaza761q16q1pqzxihr-prototype-<IP_ADDRESS>.js.drv'...

trying https://ajax.googleapis.com/ajax/libs/prototype/<IP_ADDRESS>/prototype.js
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100  195k    0  195k    0     0  3198k      0 --:--:-- --:--:-- --:--:-- 3198k
/nix/store/i91h5jak998m7kdbjbpfjvv7z4mwpxfa-prototype-<IP_ADDRESS>.js

Thank you.


Add bulk indexing script

What
This PR implements the following

Add bulk indexing script
Increment dp elastic search version  to v3.0.0-alpha.2
Change the api and service to use the new elasticsearch alpha version. (Please note: Currently the api is directly depending on the v2 package of the elasticsearch client directly, this is to support the injection of aws signer roundtripper. This will soon be fixed at the dp elasticsearch version and will be changed accordingly.)

How to review
The bulk indexing script is already tested in develop.
Who can review
Anyone except me (but would be better if @nshumoogum can review as he is familiar with the context)

Pushing comments up to cmd/reindex/main.go line 87; I will continue my review next week

Done. Please feel free to add more


Fixing an issue with branch grouping due to substring matching

I noticed that if one branches name exists within another branch, its commits are included in both branches, this is because the AngularJS "filter" filter defaults to a substring match rather than a strict equality comparison. Simply specifying the comparator explicitly resolves the issue.
https://docs.angularjs.org/api/ng/filter/filter

:+1:

awesome! that was bothering me as well


Fix: Fixed icon in preview build

Resolved / Related Issues
Items resolved / related issues by this PR.

Closes #11235...

Validation
How did you test these changes?

[x] Built and ran the app
[x] Tested the changes for accessibility

Screenshots (optional)
Add screenshots here.

I suspected it was something like that lol


Validate that containers run as non-root

How to categorize this PR?

/area security quality
/kind enhancement
What this PR does / why we need it:
This PR enhances the securityContext of pods that already run as non-root with the runAsNonRoot field set to true. This will force the kubelet to validate that the containers in a pod are started with a non-root user.
This PR also modifies fluent-operator to run as nonroot user & group 65532 (id of nonroot user in distroless images ref). Aiming to adhere to the principles of least privilege and reduce potential attack surface.
Which issue(s) this PR fixes:
Fixes #7157
Special notes for your reviewer:
Release note:

Containers, configured to run as `non-root`, are now validated to start with `non-root` user by the `kubelet`.

The `fluent-operator` component now runs as `nonroot` user and group `65532`.

/lgtm

Thanks 😄
/approve


Discord role based priority

Now your can manage your queue priority via your discord role. No need to add everytime in config file. just add role to give priority and remove role to remove priority

Closed for some more update added. so need to push again


tracing withnot-root-span

I dont't know how to resolv it

Hi
This would occur if your trace started in a previous service, but the
tracing data from that service was not reported. In this situation, the
root span (i.e. the initial span for the trace instance) is not available
when constructing the trace instance in the UI.
Regards
Gary
On Tue, Apr 7, 2020 at 8:36 AM fujianan<EMAIL_ADDRESS>wrote:

[image: image]
https://user-images.githubusercontent.com/22000011/78642564-85736e80-78e5-11ea-861e-02bf4288311b.png
I dont't know how to resolv it
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/istio/istio/issues/22766, or unsubscribe
https://github.com/notifications/unsubscribe-auth/AABIFUWME23GHCP4SYNVK23RLLJZHANCNFSM4MC4IMIA
.


Move bevy_math Reflect impls

Objective
Fixes #13456
Solution
Moved bevy_math's Reflect impls from bevy_reflect to bevy_math.
Quick note
I accidentally used the same commit message while resolving a merge conflict (first time I had to resolve a conflict). Sorry about that.

Oops, forgot to actually update the code after removing the feature. my bad.

Alright, ready for review now @MrGVSV @alice-i-cecile. sorry for the many issues with my commits, was very tired but wanted to finish this anyway.

Also, the reason I didn't derive the traits on things like Arc2d is that it wasn't manually implemented before my changes either, so I wanted to ask it here if there was a reason for that or if that was a mistake (and should be corrected).

Also, the reason I didn't derive the traits on things like Arc2d is that it wasn't manually implemented before my changes either, so I wanted to ask it here if there was a reason for that or if that was a mistake (and should be corrected).

I'm pretty sure that's just because those are very new and never had Reflect implemented anywhere. Adding them would be fine!

Also, the reason I didn't derive the traits on things like Arc2d is that it wasn't manually implemented before my changes either, so I wanted to ask it here if there was a reason for that or if that was a mistake (and should be corrected).

I'm pretty sure that's just because those are very new and never had Reflect implemented anywhere. Adding them would be fine!

Should I simply implement it for all math types? Even older types like Ray2d didn't have it yet.

Should I simply implement it for all math types? Even older types like Ray2d didn't have it yet. IMO that should be a follow up PR.

Doing it in a follow-up probably makes more sense, yeah.

I'll open an issue for implementing the reflect traits for all math types. I'll work on it when this gets merged.


Why does the PLIC not support interrupt masking?

Why does the PLIC not support interrupt masking? Interrupts can only be enabled/disabled or claimed and completed. It would be nice to have an explanation why explicit masking is not needed and/or implementing this discouraged. It is a trade-off to reduce gate count because it should happen in software?

I am not clear about the original design concept of PLIC. But what do you mean exactly regarding the interrupt masking? I thought to disable an interrupt is sort of masking it out, no?

Masking and disabling are different things. When you disable an interrupt in the PLIC, any interrupts from that source will be ignored - so interrupts are lost effectively. If you mask an interrupt, it remains enabled, but will not be reported as pending external interrupt to the core. It can also not be claimed. It should be visible in the pending register for manual polling (and debugging purposes) . Now when you unmask that interrupt and it is pending, it should immediately assert the external interrupt to the core.
It seems you could achieve masking by using the priorities. If the priority is below the threshold, it it masked (but still enabled), if the priority is above the threshold, it is unmasked. However, I am not sure what the PLIC spec intends to say about what happens when changing the priority for a pending interrupt. I would like to see a clar statement that If the priority is change to a value euals or belopw below the threshold, this also deassert the external interrupt (and claiming will no longer happen) . Vice versa, if the priority of a pending interrupt is changed to a value above the threshold, will this immediately assert the external interrupt and one of the the next claim request may yield.

@axel-h
I agree that there is something not clearly defined in the PLIC spec. The PLIC spec here is copied from the one published in RISC-V Privileged Spec v1.9 (Removed from v1.11). We need a PLIC spec for the RVM-CSI platform defined in RISC-V platform spec. We are going to have a public review of PLIC spec soon and please give your comments against the public review email.

I guess that you can implement a "mask-like" behavior with two or more PLIC contexts. In this way, you can use one context for only enabling all the interrupts in your system. This context will never claim/complete an interrupt. Then, the other context(s) can enable/disable dynamically their interrupts and act accordingly. Am I wrong?


Roll engine 0d749933bcc6..6925b2aae3a4 (1 commits)

git@github.com:flutter/engine.git/compare/0d749933bcc6...6925b2aae3a4
git log 0d749933bcc6..6925b2aae3a4 --no-merges --oneline
2019-10-09<EMAIL_ADDRESS>Roll fuchsia/sdk/core/mac-amd64 from wuAtw... to u0JpE... (flutter/engine#13018)
If this roll has caused a breakage, revert this CL and stop the roller
using the controls here:
https://autoroll.skia.org/r/flutter-engine-flutter-autoroll
Please CC<EMAIL_ADDRESS>on the revert to ensure that a human
is aware of the problem.
To report a problem with the AutoRoller itself, please file a bug:
https://bugs.chromium.org/p/skia/issues/entry?template=Autoroller+Bug
Documentation for the AutoRoller is here:
https://skia.googlesource.com/buildbot/+/master/autoroll/README.md

AutoRoller is stopped; closing the active roll.


Create platform independent publishing option

The software solution currently does not have a good method for creating a distributable package. Ideally it should be possible to publish the software for both Windows and Linux from the same solution.

This was added in commit 1c568d4
The ReleasePublish build configuration creates a publish directory and copies all the needed files and directories over there. The copy mechanism is built into MSBuild so should work cross-platform (although this has not been tested).


Port<EMAIL_ADDRESS>to cross-platform docker images

Use<EMAIL_ADDRESS>as a reference.

[x] - Create docker.io/jackcviers/cp-kafka
[x] - Add make rules for building, testing, manifesting, and publishing cp-kafka for amd64 and arm64.
[ ] - Implement make rules for building, testing, manifesting, and publishing cp-kafka for amd64 and arm64.

Blocked by #61


macOS - No executable found matching command “dotnet-watch”

I am using the dotnet cli with macOS Sierra 10.12.6
I have typed this command:
dotnet new web
dotnet run
So far so good.
When I have change:
app.Run(async (context) =>
            {
                await context.Response.WriteAsync("Hello World");
            });

as per: https://www.youtube.com/watch?v=aIkpVzqLuhA
and refresh the browser, nothing happens. I thought that this might need the watch package, so typed:
dotnet add package Microsoft.DotNet.Watcher.Tools --version 2.0.0
Which installs successfully; csproj contains:
 <ItemGroup>
    <PackageReference Include="Microsoft.AspNetCore.All" Version="2.0.5" />
    <PackageReference Include="Microsoft.DotNet.Watcher.Tools" Version="2.0.0" />
  </ItemGroup>

when I try to run dotnet watch or dotnet watch run, I get the error:
No executable found matching command "dotnet-watch"

You need to use DotNetCliToolReference, not PackageReference. See https://github.com/aspnet/DotNetTools/blob/release/2.0/README.md#how-to-install for instructions on how to install.

Hi @natemcmaster can you please elaborate as the link you provided looks good, but lacks information as to how to actually resolve the issue / install properly so that dotnet watch actually runs


Get-SQLRegisteredServerName and Groups again

Get-SQLRegisteredServerName not accepting groups again. well, it does but it doesnt work

I've found the issue and getting a PR to resolve


Calling GraphQL API From a Lambda function

Note: If your question is regarding the AWS Amplify Console service, please log it in the
AWS Amplify Console repository

Which Category is your question related to?
GraphQL API, Lambda Function, Rest API
Amplify CLI Version
v9.0.0
You can use amplify -v to check the amplify cli version on your system
What AWS Services are you utilizing?
AppSync, Lambda
Provide additional details e.g. code snippets. Be sure to remove any sensitive data.
I referred to this link - https://docs.amplify.aws/guides/functions/graphql-from-lambda/q/platform/js/  to Call GraphQL API From a Lambda function.
Steps that I Followed

amplify init

amplify add api
=>created a GraphQL api of todo template

amplify push --y

amplify add api

? Select from one of the below mentioned services: REST
√ Provide a friendly name for your resource to be used as a label for this category in the project: · ybGraphqlLambda
√ Provide a path (e.g., /book/{isbn}): · /items
Only one option for [Choose a Lambda source]. Selecting [Create a new Lambda function].
? Provide an AWS Lambda function name: ybGraphqlLambda
? Choose the runtime that you want to use: NodeJS
? Choose the function template that you want to use: Serverless ExpressJS function (Integration with API Gateway)
Available advanced settings:

Resource access permissions
Scheduled recurring invocation
Lambda layers configuration
Environment variables configuration
Secret values configuration

? Do you want to configure advanced settings? Yes
? Do you want to access other resources in this project from your Lambda function? Yes
? Select the categories you want this function to have access to. api, function
? Select the operations you want to permit on testgraphqllambda Query, Mutation, Subscription
No resources found for function
You can access the following resource attributes as environment variables from your Lambda function
API_TESTGRAPHQLLAMBDA_GRAPHQLAPIENDPOINTOUTPUT
API_TESTGRAPHQLLAMBDA_GRAPHQLAPIIDOUTPUT
API_TESTGRAPHQLLAMBDA_GRAPHQLAPIKEYOUTPUT
ENV
REGION
? Do you want to invoke this function on a recurring schedule? No
? Do you want to enable Lambda layers for this function? No
? Do you want to configure environment variables for this function? No
? Do you want to configure secret values this function can access? No
? Do you want to edit the local lambda function now? No
Successfully added resource ybGraphqlLambda locally.

amplify push --y

Edited index.js file with code below

import crypto from '@aws-crypto/sha256-js';
import { defaultProvider } from '@aws-sdk/credential-provider-node';
import { SignatureV4 } from '@aws-sdk/signature-v4';
import { HttpRequest } from '@aws-sdk/protocol-http';
import { default as fetch, Request } from 'node-fetch';

const { Sha256 } = crypto;
const GRAPHQL_ENDPOINT = process.env.API_<YOUR_API_NAME>_GRAPHQLAPIENDPOINTOUTPUT;
const AWS_REGION = process.env.AWS_REGION || 'us-east-1';

const query = /* GraphQL */ `
  query LIST_TODOS {
    listTodos {
      items {
        id
        name
        description
      }
    }
  }
`;

/**
 * @type {import('@types/aws-lambda').APIGatewayProxyHandler}
 */
export const handler = async (event) => {
  console.log(`EVENT: ${JSON.stringify(event)}`);

  const endpoint = new URL(GRAPHQL_ENDPOINT);

  const signer = new SignatureV4({
    credentials: defaultProvider(),
    region: AWS_REGION,
    service: 'appsync',
    sha256: Sha256
  });

  const requestToBeSigned = new HttpRequest({
    method: 'POST',
    headers: {
      'Content-Type': 'application/json',
      host: endpoint.host
    },
    hostname: endpoint.host,
    body: JSON.stringify({ query }),
    path: endpoint.pathname
  });

  const signed = await signer.sign(requestToBeSigned);
  const request = new Request(endpoint, signed);

  let statusCode = 200;
  let body;
  let response;

  try {
    response = await fetch(request);
    body = await response.json();
    if (body.errors) statusCode = 400;
  } catch (error) {
    statusCode = 500;
    body = {
      errors: [
        {
          message: error.message
        }
      ]
    };
  }

  return {
    statusCode,
    headers: {
          "Access-Control-Allow-Headers" : "Content-Type",
          "Access-Control-Allow-Origin": "*",
          "Access-Control-Allow-Methods": "OPTIONS,POST,GET"
        },
    body: JSON.stringify(body)
  };
};

Deployed the function and sent a req to the endpoint with /items from the client side and got the response. Successfully working.

=>But, When I run Command amplify mock function I'm getting an error,
stack: 'Error: Could not load lambda handler function due to Error [ERR_REQUIRE_ESM]: Must use import to load ES Module
=>And in the function/funcName/src directory, there is a file app.js why it is created and where it is used.

Hello @yashBrahma, Thank you for reaching out. amplify mock function does not support ES modules. A feature request is currently open for this: https://github.com/aws-amplify/amplify-cli/issues/10432. To test mock functionality we will need to import fetch v2 version instead of v3 which utilizes require statement instead of import statements.
Please refer to the comment https://github.com/aws-amplify/amplify-cli/issues/10432#issuecomment-1184647915 providing an example.

And in the function/funcName/src directory, there is a file app.js why it is created and where it is used

when utilizing a express based Lambda function the aws-serverless-express package is utilized to configure a simple proxy API from a app.js file.
From the code example provided in the issue I understand that you would like a Lambda function without the need for a express package.
I would suggest utilizing the Hello world template instead of Serverless ExpressJS function (Integration with API Gateway) template as this will not add the additional file and packages.
Additionally, please do note that you may run into a Unauthorized when performing a mock locally, to test this locally you may need to pass the credentials manually. Please refer to this comment for additional information: https://github.com/aws-amplify/amplify-category-api/issues/140#issuecomment-1129353951

Hello @ykethan, Thanks for your response.
For calling one query, I think Hello world template is good but what if I want to call more than one query. So, I used the Serverless ExpressJS function (Integration with API Gateway)  template, Where I can pass diff paths like /listTodo,
/createTodo.
So, I tried editing the app.js file as below, and I got a network error when I send a request from the frontend
Error
Access to XMLHttpRequest at 'https://3dddzada-api.ap-south-1.amazonaws.com/dev/items' from origin 'http://localhost:3000' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource.
import crypto from '@aws-crypto/sha256-js';
import { defaultProvider } from '@aws-sdk/credential-provider-node';
import { SignatureV4 } from '@aws-sdk/signature-v4';
import { HttpRequest } from '@aws-sdk/protocol-http';
import { default as fetch, Request } from 'node-fetch';

const { Sha256 } = crypto;
const GRAPHQL_ENDPOINT = process.env.API_TESTGRAPHQLLAMBDA_GRAPHQLAPIENDPOINTOUTPUT;
const AWS_REGION = process.env.AWS_REGION || 'ap-south-1';

const express = require('express')
const bodyParser = require('body-parser')
const awsServerlessExpressMiddleware = require('aws-serverless-express/middleware')

// declare a new express app
const app = express()
app.use(bodyParser.json())
app.use(awsServerlessExpressMiddleware.eventContext())

// Enable CORS for all methods
app.use(function(req, res, next) {
  res.header("Access-Control-Allow-Origin", "*")
  res.header("Access-Control-Allow-Headers", "*")
  res.header("Access-Control-Allow-Methods","OPTIONS,POST,GET")
  next()
});

app.get('/items',async function(req, res) {
  // Add your code here
  // const event = req.apiGateway.event
  // const context = req.apiGateway.context;

  const query = /* GraphQL */ `
           query LIST_TODOS {
             listTodos {
                  items {
                     id
                     name
                      description
                 }
              }
         }
       `;

  const endpoint = new URL(GRAPHQL_ENDPOINT);

  const signer = new SignatureV4({
    credentials: defaultProvider(),
    region: AWS_REGION,
    service: 'appsync',
    sha256: Sha256
  });

  const requestToBeSigned = new HttpRequest({
    method: 'POST',
    headers: {
      'Content-Type': 'application/json',
      host: endpoint.host
    },
    hostname: endpoint.host,
    body: JSON.stringify({ query }),
    path: endpoint.pathname
  });

  const signed = await signer.sign(requestToBeSigned);
  const request = new Request(endpoint, signed);

  let statusCode = 200;
  let body;
  let response;

  try {
    response = await fetch(request);
    body = await response
    if (body.errors) statusCode = 400;
  } catch (error) {
    statusCode = 500;
    body = {
      errors: [
        {
          message: error.message
        }
      ]
    };
  }
 res.json({body})
});

app.listen(3000, function() {
    console.log("App started")
});

module.exports = app

Hello @yashBrahma, could you please check the Lambda function logs and see if there may be any errors currently being logged.
If the API gateway method response contains only 200 HTTP status this can cause the browser to interpret as a cors error for other responses. I was able to replicate the error by adding a syntax error in my Lambda code.
Could you also please try using the Firefox browser as the Chrome browser may be hiding the additional parameters.


Need to Shrink Data Logger Code to Have Room for Serial1

Not going to be able to get it small enough.


Access to MessageInfo.fields

Hello
Would you consider making the fields field in MessageInfo public, or proving a method to list the available fields and/or field numbers?
My use case is exporting a protobuf message for use in an embedded scripting language, so I need to iterate over its fields to export each value to the scripting engine.
I’m currently doing this with fields from MesageValue, but this can be incomplete is the message has fields with default values.

I'll try coming up with a solution for this on the upcoming week! I'm sure there's no reason to keep that private (or to avoid a method exposing the fields) - just didn't have a use case for that myself so missed it in the API.
Don't remember the structure off the top of my head so can't comment whether a pub field vs method makes more sense now.

Sorry, got busy over the week. Should be done now.
The MessageInfo has iter_fields method. I thought of exposing the fields field, but due to its BTreeMap data type and ties to the fields_by_name field, I wanted the option to change those data types in the future, the iter_fields should remain forward compatible.
(Ended up also incrementing the version from 0.4.x to 0.5.0 as there were some version compatibility breaking changes on the main branch.)

Thanks!

Hi
I think you forgot to merge the fields branch onto main.

Uh.. maybe. :x
Done now, published 0.5.1. This time it should actually have the changes too!

Thanks again :)


Failed to replace PagedAttentionWithRoPE.

In my test.py, I intend to test and enhance the model's performance with longer input sequences. To achieve this, I need to modify the ModelConfig and PagedAttentionWithRoPE. However, I've encountered difficulties only when trying to modify the PagedAttentionWithRoPE component. More specifically:
from vllm import LLM, SamplingParams
from vllm.model_executor.layers.attention import PagedAttentionWithRoPE, PagedAttention
from vllm.config import ModelConfig, _get_and_verify_dtype
import torch
from typing import List, Optional
from vllm.transformers_utils.config import get_config
import pdb

ratio = 4
def __Configinit__(
        self,
        model: str,
        tokenizer: str,
        tokenizer_mode: str,
        trust_remote_code: bool,
        download_dir: Optional[str],
        use_np_weights: bool,
        use_dummy_weights: bool,
        dtype: str,
        seed: int,
    ) -> None:
        pdb.set_trace()

        self.model = model
        self.tokenizer = tokenizer
        self.tokenizer_mode = tokenizer_mode
        self.trust_remote_code = trust_remote_code
        self.download_dir = download_dir
        self.use_np_weights = use_np_weights
        self.use_dummy_weights = use_dummy_weights
        self.seed = seed

        self.hf_config = get_config(model, trust_remote_code)
        self.dtype = _get_and_verify_dtype(self.hf_config, dtype)
        self._verify_tokenizer_mode()
ModelConfig.__init__ = __Configinit__

def __Ropeinit__(
        self,
        num_heads: int,
        head_size: int,
        scale: float,
        rotary_dim: int,
        max_position: int = 8192,
        base: int = 10000,
        num_kv_heads: Optional[int] = None,
    ) -> None:
        super(PagedAttention, self).__init__(num_heads, head_size, scale, num_kv_heads)

        pdb.set_trace()

        # Create the cos and sin cache.
        inv_freq = 1.0 / (base**(torch.arange(0, rotary_dim, 2) / rotary_dim))
        t = torch.arange(max_position).float()
        freqs = torch.einsum("i,j -> ij", t, inv_freq.float())
        cos = freqs.cos()
        sin = freqs.sin()
        cache = torch.cat((cos, sin), dim=-1)
        # FIXME(woosuk): This assumes that we configure the default dtype when
        # initializing the model.
        # TODO(woosuk): Make it more robust.
        torch_dtype = torch.get_default_dtype()
        cache = cache.to(torch_dtype)
        # Embedding size: [max_position, rotary_dim]
        self.register_buffer("cos_sin_cache", cache, persistent=False)
PagedAttentionWithRoPE.__init__ = __Ropeinit__

llm = LLM(model="OpenBuddy/openbuddy-openllama-7b-v5-fp16",tensor_parallel_size=4,
max_num_batched_tokens=2048*ratio)
sample = SamplingParams(
    max_tokens=128
)
output = llm.generate(prompt + "\nAssistant:", sampling_params=sample)

After executing the aforementioned code, it successfully reaches the breakpoint I set within the Configinit function, but it doesn't enter the breakpoint within the Ropeinit function. Instead, it continues to enter the PagedAttentionWithRoPE.init function. I'm unsure about how I should proceed with the necessary modifications.

they are working on this PR
https://github.com/vllm-project/vllm/issues/674#issuecomment-1666383693

they are working on this PR #674 (comment)

Thanks.


🍒 Cherry pick PR #6381 to staging 🍒

🍒 Cherry pick https://github.com/Expensify/App/pull/6381 to staging 🍒

🚀 Cherry-picked to staging by @AndrewGable in version: 1.1.15-15 🚀

platform
result

🤖 android 🤖
success ✅

🖥 desktop 🖥
success ✅

🍎 iOS 🍎
success ✅

🕸 web 🕸
success ✅

@Expensify/applauseleads please QA this PR and check it off on the deploy checklist if it passes.

🚀 Deployed to production by @AndrewGable in version: 1.1.15-15 🚀

platform
result

🤖 android 🤖
success ✅

🖥 desktop 🖥
success ✅

🍎 iOS 🍎
success ✅

🕸 web 🕸
success ✅


add deletion orphan for mch manifests and fix acm detection

Signed-off-by: Zhiwei Yin<EMAIL_ADDRESS>tasks:
https://github.com/stolostron/backlog/issues/26299
https://github.com/stolostron/backlog/issues/26467

/assign @clyang82
/assign @morvencao
/assign @yanmxa


RTL support

(+) RTL/LTR Or Auto Text Direction
REPORTED: https://wordpress.org/support/topic/custom-image-field-and-few-useful-suggestions/

RTL support was added


Rework module to replace Rational.Str ?

Would you be ok if I used your module as a base to rework as an alternative Rational.Str in a PR?

Absolutely.

Ok, will do that tomorrow...  :-)

For the record: I've come to the conclusion that losing about 15% of performance to get digit support in Rational.Str is not going to be worth it.  So I will rework this into explicit support for Rationals in the new Formatter class, which will be the base of the new sprintf and .fmt functionality.


Encoding issue while writing into csv

Calling a field which is

"name": {
                        "type": "keyword"
                     },

Command that i ran:
es2csv -i index -D type -f name --verify-certs -u https://userwithurl -q '*' -o database.csv
And the error that was showing was :

Traceback (most recent call last):
File "/home/ubuntu/anaconda3/bin/es2csv", line 11, in
load_entry_point('es2csv==5.2.1', 'console_scripts', 'es2csv')()
File "/home/ubuntu/anaconda3/lib/python3.5/site-packages/es2csv.py", line 284, in main
es.write_to_csv()
File "/home/ubuntu/anaconda3/lib/python3.5/site-packages/es2csv.py", line 237, in write_to_csv
line_dict_utf8 = {k: v.encode('utf8') if isinstance(v, unicode) else v for k, v in line_as_dict.items()}
File "/home/ubuntu/anaconda3/lib/python3.5/site-packages/es2csv.py", line 237, in
line_dict_utf8 = {k: v.encode('utf8') if isinstance(v, unicode) else v for k, v in line_as_dict.items()}
NameError: name 'unicode' is not defined

python3.5 is not supported at the moment. Please use python 2.7.

Why not just make it str instead.
@taraslayshchuk

@taraslayshchuk I'm using es2csv with Python 2.7 yet I'm getting this unicode-related error:
Traceback (most recent call last):
  File "/home/ubuntu/.local/bin/es2csv", line 11, in <module>
    sys.exit(main())
  File "/home/ubuntu/.local/lib/python2.7/site-packages/es2csv.py", line 284, in main
    es.write_to_csv()
  File "/home/ubuntu/.local/lib/python2.7/site-packages/es2csv.py", line 221, in write_to_csv
    csv_writer.writeheader()
  File "/usr/lib/python2.7/csv.py", line 141, in writeheader
    self.writerow(header)
  File "/usr/lib/python2.7/csv.py", line 152, in writerow
    return self.writer.writerow(self._dict_to_list(rowdict))
UnicodeEncodeError: 'ascii' codec can't encode character u'\xe5' in position 8: ordinal not in range(128)

So I guess using 2.x is not a solution for the problem. I'm not sure what document is problematic, but \xe5 is å.

I solved it by using unidecodecsv instead of csv:
diff --git a/es2csv.py b/es2csv.py
index b948843..509e5ea 100755
--- a/es2csv.py
+++ b/es2csv.py
@@ -16,7 +16,7 @@ import sys
 import time
 import argparse
 import json
-import csv
+import unicodecsv as csv
 import elasticsearch
 import progressbar
 from functools import wraps

@abdrmdn Answer for you question is in  @katafrakt comment. [More details],(https://docs.python.org/2/howto/unicode.html) that's why we should use such methods.

Hello @katafrakt you have definitely another error. Looks like you have unicode naming in document, to be precise it is in key name and that is not expected by this tool.

Since this is already resolved, I'll close the issue.

Fixed in 5.5.2.


smali code highlighting is basically perfect

smali highlight is here
#1105
Follow-up to make some improvements to the color matching

@MartinKayJr great work!
Several questions:

why you don't want to include original jflex file? It will be easier to change/fix token types later
did you copy jflex file from somewhere or write it yourself? Just trying to check copyright :)
can we use different types of instructions and type names, like use identifier for instructions? Because now whole line have same color and hard to read:

@skylot hey bro
1.I don’t know where the jflex file should be placed. I put it in the resource directory of the gui in the first submission.
2.This jflex took me 11 consecutive hours to complete and was completed by myself.
3.Regarding the color, I think the RSTA reference manual and the preset Token are not suitable for the smali language, so I am going to optimize the color matching in the follow-up

In my recent submission, I transferred the jflex file to config/jflex and provided a simple shell script for reference to generate SmaliTokenMarker.java.
I tried to use Token.identifier for the instructions , but there was no color, so I changed the fully qualified class name to DATA_TYPE.

@MartinKayJr thanks! Looks good.
Although, I think, I will rewrite your shell script using gradle and jflex plugin to make it environment independent.


ImageTexture.create(..) creates also an Image so that get_data() will…

… not return null.
closes https://github.com/godotengine/godot/issues/20701

I don't really see any point in this. It makes the whole engine more inefficient when loading images. If this is not clear, it should be added to the documentation, not worked around.

Can you explain why it will slow down the engine? Where is it used? It is not like ImageTexture.create() is called on .new() and most of the time ImageTexture.create_from_image() is used.
The point is simple when I create and ImageTexture I expect a valid object this means get_data() should not be null.

You are putting the goal of another function inside this one as a mandatory step, which will allocate on CPU behind the scenes everytime, even when the user doesn't want this. You should just be using create_from_image instead, or at least not force this allocation.


Running mamba with v100 succeeded, but failed running mamba2

Thanks for the support to Mamba2, but I met problems running classification task using mamba2 on v100 gpus.
my env:

torch 1.12.1+cu116
triton 2.1.0

config for mamba2 is copied from function vmamba_small_m2() in file vmamba.py:
`MODEL:
TYPE: vssm
NAME: mamba2_s
DROP_PATH_RATE: 0.3
NUM_CLASSES: 1000
VSSM:
EMBED_DIM: 96
DEPTHS: [ 2, 2, 20, 2]
PATCH_SIZE: 4
IN_CHANS: 3
SSM_D_STATE: 64
SSM_DT_RANK: "auto"
SSM_RATIO: 1.0
SSM_ACT_LAYER: "gelu"
SSM_CONV: 3
SSM_CONV_BIAS: false
SSM_DROP_RATE: 0.0
SSM_INIT: "v2"
SSM_FORWARDTYPE: "m0_noz"
MLP_RATIO: 4.0
MLP_DROP_RATE: 0.0
GMLP: False
PATCH_NORM: True
DOWNSAMPLE: "v3"
PATCHEMBED: "v2"
NORM_LAYER: "ln"
POSEMBED: False
TRAIN:
USE_CHECKPOINT: False
DATA:
IMG_SIZE: 224`
and the error log is:
python: /project/lib/Analysis/Allocation.cpp:40: std::pair<llvm::SmallVector<unsigned int>, llvm::SmallVector<unsigned int> > mlir::triton::getCvtOrder(mlir::Attribute, mlir::Attribute): Assertion !(srcMmaLayout && dstMmaLayout) && "Unexpected mma -> mma layout conversion"' failed.
WARNING:torch.distributed.elastic.multiprocessing.api:Sending process 22025 closing signal SIGTERM
/opt/conda/lib/python3.8/multiprocessing/resource_tracker.py:216: UserWarning: resource_tracker: There appear to be 32 leaked semaphore objects to clean up at shutdown
warnings.warn('resource_tracker: There appear to be %d '`
I searched for the error and found others met the same problem using v100.
Is it mamba2's problem?

yes I think the problem is related to triton.

I also had this problem on v100, which can be avoided by using torch instead of triton. But another problem arises, after training several epochs, it reports error loss is nan. So how to solve it? Are you encountering this problem? I have not seen this problem when I use Mamba1.

I used the torch version of mamba2 and ran for 7 epochs on Tesla T4 GPU; everything is all right till now. I have not met the Nan loss. Did you set an improper learning rate?


update(ChatMessages): Change chat messages function to a Stream

Description
1. Change Timer Periodic to call chat messages for Stream with while loop
a. In functionality nothing changes, but stream is better to work and prepare it to use with warp-dart
b. More clean code on chat bloc

2. Chat bloc more organized

a. Transform is restartable, because if it start a new event, it cancel past event

b. Transform data on Bloc now, instead in remote datasource

3. Transform data now on ChatMessage entity

4. ChatRoomPage
a. Now when chat room page is closed, it send a command to break while loop on stream

Type of Change

[x] 🧹 Code refactor

Hi Lucas! I'm testing with two separate real devices and having some issues, it seems if User A goes to chat with User B and User B is online then the app will crash when User A enters chat. If User B is offline then User A can go into chat and send messages without it crashing
https://user-images.githubusercontent.com/93608357/197612845-2111d411-754d-4cf4-9ed0-bb5ac90ead50.mp4


Banner not showing in Android

Banner not showing in Android , even I have change the market://details  to http://details also trired changing to http://play.google.com/store/apps/details ..  But still Its not working.  Working fine for IOS...   Please help

@sanjivpnf You've not provided anyone with enough information to reproduce the issue.  You're going to need to provide more details.


UART DMA Rework and UART MIDI improvements/refactoring

Summary
Extends and supersedes @stephenhensley's work from #557:

[Breaking Change] UART peripheral to add DMA "listen" mode with idle interrupts to supersede older FIFO approach
Factor out MidiParser to a dedicated class separate from (but used by) MidiHandler

For backwards compatibility and maintaining existing tests, MidiHandler still has a publicly avialable Parse(uint8_t byte) method.

Change MidiUartTransport to use new UART DMA mode
Change MidiUartTransport to accept a "parse callback" function and context pointer when starting Rx

Callback is called every time the DMA Rx callback fires with new received bytes.
Bytes are immediately parsed into FIFO owned by MidiHandler rather than waiting for application - as evidenced from testing, this drastically improves practical performance of UART MIDI (e.g. dropped messages)
Minor changes to USB transport implementation to conform to the same signature, for MidiHandler transport template parameter. USB transport also uses parse callback in a similar way.

Add option to provide DMA buffer for UART MIDI byte rx in the transport config struct, with sensible defaults

Enables this new approach to work correctly for Daisy Bootloader app types
(Theoretically) enables applications with multiple MIDI UART inputs on different peripherals, using separate MidiUartHandler instances, provided application code provides separate DMA rx buffers for each.

Minor automatic formatting changes (trim whitespace, add trailing newline to files, etc)

The only breaking changes should be in UartHandler. Most existing applications using UART MIDI should not require changes.
Testing Notes
I tested this using the following setup:

Seed running a 24-voice MIDI polysynth application example with internal end-of-chain reverb.
Repeating 8-voice 16th note chords sent to seed over UART MIDI at 120 BPM, with real-time MIDI clock in the stream as well

From Bitwig Studio + USB Focusrite interface translating USB MIDI to UART/DIN
From Keystep Pro via UART/DIN MIDI output

Stress tested with randomly automated CC streams in addition to the above

At some point the MIDI bus gets overloaded when doing this from the Bitwig setup

This setup was tested across app types (internal flash + daisy bootloader SRAM/QSPI) using default libDaisy linker scripts as well as via USB MIDI directly for regression testing purposes.

I just pushed a new unit test that confirms one of the remaining bugs with MIDI.
It tests the parser by running a full note-on message, followed by several clock messages (system real time), and then the two data bytes for a 0-velocity note on (note off) message.
This seems to be how the Elektron boxes function (specifically the Octatrack), and currently causes note-off messages to get missed.
@beserge is going to add a fix to the newly relocated midi parser on this branch.
Once that fix is applied, the unit test should pass, and I think this PR will be ready to merge.

Alright!
@ndonald2 @beserge thanks for getting this where it is!
I think at this point the things we set to do are accomplished, and we got a few other things fixed as well.
In addition to the UART rework, and moving parsing into the actual interrupt process we caught, and resolved a bug with the parser that had to do with SystemRealtime messages improperly invalidating the running status byte.
This PR has been tested with several configurations.
All three built-in linker/application types (flash, SRAM, and QSPI) were tested.
The rxbuffer was tested at many sizes (down to two bytes, which is not recommended as it will result in a lot of stuck notes/missing data), and memory sections (uncached d2 ram, AXI SRAM, SDRAM, and heap allocated via malloc).
Performance is much better than the current master branch.
This is approved! 🚀


Fix Python.h include order

Let's see if this squashes the very last build warnings.

--Werror isn't happy about a standard header:
/usr/include/x86_64-linux-gnu/bits/mathcalls.h:79:1: error: expected ‘;’ before ‘extern’
   79 | __MATHDECL_VEC (void,sincos,,

Giving up on adding --werror due to the mathcalls.h warning; it's quite common and there's no solution I've seen on any of the bug reports.

All but one include order changes merged upstream, so closing. Will open a new PR to add -Werror to the CI job.


In renderdoc 1.13, I use TextureSave to save R8G8, but it's not work!

Description
In renderdoc 1.13, I use TextureSave to save R8G8, but it's not work! The saved picture is black.
Steps to reproduce
In renderdoc 1.13
` texsave.alpha = rd.AlphaMapping.BlendToCheckerboard
texsave.mip = 0
texsave.slice.sliceIndex = 0
texsave.resourceId = sd.textures[0].resourceId
texsave.destType = rd.FileType.PNG
texsave.comp.blackPoint = 0.0
texsave.comp.whitePoint = 1.0
filename = "./capture/" + os.path.basename(sys.argv[1]).split('.')[0] + ""
controller.SaveTexture(texsave, filename + "_0.png")`
'
Environment

RenderDoc version: 1.13
Operating System:  Windows 10 企业版
Graphics API: no

Please do not open multiple copies of the same issue, this amounts to spam and makes it harder to help with any problems people are having.


Change atom.sh not to spawn a sleep process every second on --wait

Description of the Change
As sleep(1) is not a bash builtin, every second a new process is spawed.
To  prevent this, the POSIX read can be used instead.

In case stdin is e.g. /dev/null for whatever reason (this would break EDITOR=nano), sleep is still kept to prevent a tight loop.
Alternate Designs

a longer sleep interval: this would require job management as sleep would keep running even if bash is killed and thus cause huge delays

Why Should This Be In Core?
not possible otherwise
Benefits
Those sleep processes can be annoying in e.g. execsnoop or even htop
Possible Drawbacks
e: does consume stdin, though I don't see how that is a problem
Verification Process

edited my distributions /usr/bin/atom accordingly (Archlinux, Atom 1.27) (this file hasn't changed since)
opened a file using /usr/bin/atom --wait file and verified that it exited upon closing the tab

Applicable Issues

As sleep(1) is not a bash builtin, every second a new process is spawned.

Great point; thanks for bringing this up.
Rather than reading from stdin, what do you think about actually creating a pipe with mkfifo and reading from that?

Another benefit of this PR is that the atom.sh process exits instantly after you close the waited buffers, instead of waiting for up to one second for the sleep to complete.

Version 1.28.2 of atom (which doesn't have this change) works fine as my git commit editor.  Version 1.29.0 does not - git commit hangs indefinitely waiting for the editor to finish.  I am not convinced this change is what causes the problem - but it does seem the most likely point to start looking.
What diagnostics would be useful to identify what is causing the problem?

What's your operating system?
What are your EDITOR/VISUAL/GIT_EDITOR environment variables / core.editor setting?
How did you install Atom?

Also, belated  thanks to @maxbrunsfeld for fixing my mistake completely breaking platforms other than linux.

Sorry for the belated reply.  The problem is on my work computer, and the weekend got in the way.
Operating system is Ubuntu 14.04.  uname -a says:
Linux [redacted] 4.4.0-139-generic #165~14.04.1-Ubuntu SMP Wed Oct 31 10:55:11 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux

None of the environment variables are set.  core.editor is atom --wait
I installed atom with sudo apt-get atom=1.28.2.  dpkg -s shows:
Package: atom
Status: install ok installed
Priority: optional
Section: devel
Installed-Size: 562156
Maintainer: GitHub<EMAIL_ADDRESS>Architecture: amd64
Version: 1.28.2
Depends: git, gconf2, gconf-service, libgtk2.0-0, libudev0 | libudev1, libgcrypt11 | libgcrypt20, libnotify4, libxtst6, libnss3 (>= 2:3.22), python, gvfs-bin, xdg-utils, libcap2, libx11-xcb1, libxss1, libasound2 (>= 1.0.16), libxkbfile1
Recommends: lsb-release
Suggests: libsecret-1-0, gir1.2-gnomekeyring-1.0
Description: A hackable text editor for the 21st Century.
 Atom is a free and open source text editor that is modern, approachable, and hackable to the core.

apt-cache policy atom suggests I am getting the package from https://packagecloud.io/AtomEditor/atom/any/
I can get you the corresponding output for atom 1.29.0 if that would be helpful.

I finally came around to installing a VM on Ubuntu 14.04 and I can indeed replicate this with Atom 1.29.0...
Fiddling around with /usr/bin/atom seems to indicate that is this PR that caused it:
Removing read < "$WAIT_FIFO" fixes it
and so does read <> "$WAIT_FIFO".
It seems this is due to a change in behavior in bash.

Ah HA!  Brilliant thanks.  I can patch that in no problem.
Martin
On Sun, 2 Dec 2018 at 00:09, lllusion3418<EMAIL_ADDRESS>wrote:

I finally came around to installing a VM on Ubuntu 14.04 and I can indeed
replicate this with Atom 1.29.0...
Fiddling around with /usr/bin/atom seems to indicate that is this PR that
caused it:
Removing read < "$WAIT_FIFO" fixes it
and so does read <> "$WAIT_FIFO".
It seems this is due to a change in behavior in bash.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/atom/atom/pull/17403#issuecomment-443466199, or mute
the thread
https://github.com/notifications/unsubscribe-auth/APK5U98QDvsF5fLfh1hScXEFZIXHYkf_ks5u0wwLgaJpZM4UMR9J
.

Edited version of my deleted comment:

I finally came around to installing Ubuntu 14.04 in a VM and I can indeed replicate this with Atom 1.29.0...
Fiddling around with /usr/bin/atom seems to indicate that this PR caused it:
Removing read < "$WAIT_FIFO" fixes it

though it kind of goes against the point of this PR

and so does read <> "$WAIT_FIFO".

the version I would prefer, though I don't know why it works.
It does not, in fact, seem to have anything to do with bash:
Even with a manually compiled (just make install) bash on master branch it doesn't work on Ubuntu 14.04.
I don't really want to create a PR to fix this as long as I don't know what causes this.

I still don't get why this is happening, but:

read < "$WAIT_FIFO" blocks, not because of read(2), but at the  open(2) syscall before calling read, so any builtin could be used, even true and the result would be the same
with read <> "$WAIT_FIFO" it is important that read is used because here it is read(2) that blocks since now the FIFO can actually be opened (requires a reader and a writer)
on Ubuntu 14.04, for some reason, (only) with read < "$WAIT_FIFO" the signal handler doesn't get called and the program resumes where it stopped - at open(2)

It's this bash commit that fixed it


Clean up README and incorporate suggestions

Started this PR based on suggestions from https://github.com/twilio-infra-as-code/examples/pull/1#issuecomment-795895052 but also added my proposed cleanup, and linked to our blog post.
@vernig please have a look. Thanks!

@bermudezmt how about adding a link to the Twilio CLI Plugin (https://github.com/twilio-infra-as-code/plugin-twilio-infra). Implicitly we may be doing that already referencing the blogpost. But maybe we can have a direct link here as well. @kaiquelupo what you think?

Great idea. Added bdd80407230aab61fcd850b15712f0eed3821c77 based on your suggestion to link to the plugin.

Looks really good to me @bermudezmt ! Thanks. If you can just fix the typo on line 54, then I think we are good to go and I'm going to merge. @kaiquelupo feel free to add you review

LGTM! Thanks @bermudezmt 🥇


Format code and organize imports

Intelli-J conf :
Settings → Editor → General → Auto Import → Java → Optimize imports on the fly
Code → Reformat code


Add onChange function

Add onChangeText props. So parent component have more control on components value.

You can use a fork without this problem
https://github.com/retyui/react-native-confirmation-code-field


Mention in the readme that there's no support for sha256 git repositories

As the title says, mention somewhere that due to libgit2 limitations, sha256 repositories are not yet supported. Those are becoming more common and at least Forgejo/Codeberg seems to offer repository support already with the modern hashing algorithm.

Thanks, addressed in https://github.com/klandergren/jekyll-last-commit/commit/ba3834cbc347198ed0f9e8316e09399f47f3e49e


PRTG - VEEAM Powershell Script Problems

Hello,
we would like to use PRTG to monitor Veeam B&R Enterprise Version 9.5 Up3 (PRTG is installed on Windows 2012 R2 Server).
We found some Powershell scripts to realize this issue:
Example:
https://kb.paessler.com/en/topic/72030-monitoring-veeam-backup-replication-without-veeam-enterprise-manager
https://mycloudrevolution.com/2016/03/21/veeam-prtg-sensor-reloaded/
We install the Veeam Powershell Extension on PRTG Server. Listing Veeam Command Applets modules in Powershell was successfull. Modules load automatically after example: rebooting the server.
Installation Process:
Set-Alias installutil $env:windir\Microsoft.NET\Framework64\v4.0.30319\installutil.exe
installutil "C:\Program Files\Veeam\Backup and Replication\Backup\Veeam.Backup.PowerShell.dll"
add-pssnapin VeeamPSSnapIn
Get-Command -Module VeeamPSSnapIn
The plugins get automatically reloaded after rebooting the server.
We Download the Tool PSx64.exe http://prtgtoolsfamily.com/downloads/sensors
and copy the file to:
C:\Program Files (x86)\PRTG Network Monitor\Custom Sensors\EXEXML
We download the PRTG-VeeamBRStats.ps1 and store it on same directory
We create a sensor as described (see documentatation) and get the following error message, located in PRTG Log File
Connect-VBRServer : Veeam PowerShell snap-in was loaded from an incorrect location.
At C:\Program Files (x86)\PRTG Network Monitor\custom sensors\EXEXML\PRTG-VeeamBRStats.ps1:
Connect-VBRServer -Server $BRHost
CategoryInfo          : InvalidOperation: (:) [Connect-VBRServer], Exception
FullyQualifiedErrorId : InstallationCheckerErrorId,Veeam.Backup.PowerShell.
Cmdlets.ConnectVBRServer

C:\Program Files (x86)\PRTG Network Monitor\custom sensors\EXEXML\PRTG-VeeamBRStats.ps1

Error: BRHost Connection Failed At line:1 char:1 &'C:\Program Files (x86)\PRTG Network Monitor\custom
sensors\EXEXML\PRTG-VeeamBR ...

CategoryInfo          : NotSpecified: (:) [Write-Error], WriteErrorException
FullyQualifiedErrorId : Microsoft.PowerShell.Commands.WriteErrorException,
PRTG-VeeamBRStats.ps1

Starting to Process Connection to -BRHOST vde.dasi03.local.vde.com ... Connecting BRHost...

I am testing the script on a simple command prompt:
PSx64.exe -f="PRTG-VeeamBRStats.ps1" -p="-BRHOST=VDE-DASI03.local.vde.com"
Error still the same:

Veeam PowerShell snap-in was loaded from an incorrect location.

I think there is something wrong with PSx64.exe.

Did someone have a good idea to fix the problem
Thanks and best regards
Jürgen

Hello @jhillenb1961,
What's the reason for not installing the full console?
Best regards
Markus

Hello Markus,
you want to say, why I dont install VEEAM Backup Console to PRTG Server ? Right?
Best Regards Jürgen

Right.

Thank you - that fix the problem !!!

I'm really pleased.


add lme4, MuMIn, and multcomp

add packages for https://github.com/NESCent/popgenInfo/pull/182

Seems to build successfully: https://hub.docker.com/r/hlapp/rpopgen/builds/b5mg4regt8tjafh4uf5lzzh/
I'm thus going to merge.


TypeError: Cannot read property 'get' of undefined

Describe the bug
To Reproduce
Expected behavior
Screenshots
Applicable Versions:

Netlify CMS version<EMAIL_ADDRESS>Git provider: github
Browser version: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/89.0.4389.90 Safari/537.36

CMS configuration
publish_mode: simple
slug:
  encoding: unicode
  clean_accents: false
  sanitize_replacement: "-"
backend:
  name: github
  repo: trawlbens/trawlbens
media_folder: content/posts/images
public_folder: content/posts/images
collections:
  - sortable_fields:
      - commit_date
      - title
      - date
      - commit_author
      - description
    view_filters: []
    canonical_url: false
    meta: {}
    name: posts
    slug: "{{slug}}"
    folder: content/posts
    published: true
    publish: true
    publish_mode: editorial_workflow
    label: Posts
    series: false
    fields:
      - label: Title
        name: title
        widget: string
      - label: Components
        name: components
        widget: list
        field:
          label: Components
          name: components
          widget: relation
          collection: components
          search_fields:
            - name
          value_field: name
          display_fields:
            - "{{name}}"
          default: []
      - label: Date
        name: date
        widget: date
      - label: Writer
        name: writer
        widget: string
      - label: Tags
        name: tags
        widget: list
        field:
          name: tags
          label: Tags
          widget: string
      - label: Keywords
        name: keywords
        widget: list
      - label: Thumbnail
        name: cover_image
        widget: image
      - label: Description
        name: description
        widget: string
      - label: Content
        name: body
        widget: markdown
    create: true
  - sortable_fields:
      - commit_date
      - title
      - commit_author
      - description
    view_filters: []
    canonical_url: false
    meta: {}
    name: updates
    slug: "{{slug}}"
    folder: content/updates
    published: true
    publish: true
    publish_mode: editorial_workflow
    label: Updates
    series: false
    fields:
      - label: Title
        name: title
        widget: string
      - label: Image
        name: image
        widget: image
      - label: YoutubeUrl
        name: youtubeUrl
        widget: string
      - label: Description
        name: description
        widget: markdown
      - label: Tags
        name: tags
        widget: list
        field:
          name: tags
          label: Tags
          widget: string
      - label: CtaButton
        name: ctaButton
        widget: string
    create: true
  - sortable_fields:
      - commit_date
      - name
      - name
    view_filters: []
    canonical_url: false
    meta: {}
    name: components
    slug: "{{slug}}"
    folder: content/components
    published: true
    publish: true
    publish_mode: editorial_workflow
    label: Components
    series: false
    fields:
      - label: Name
        name: name
        widget: string
    create: true

Additional context

Hi @trawlbens can you provide a full reproduction for the issue?

For @trawlbens and anybody else that sees this error message pop up...
I just had this happening myself for a while, though it didn't seem to affect the functionality of the CMS at all and I wasn't sure what was going on.
I eventually realised it was because I had a demo collection in the CMS that I was playing around with before I created the proper collections that I'm now using. I had an open pull request and active branch for a change on the demo collection, but had then deleted the collection from the CMS config without realising this.
Even though I was working on other collections. and could no longer see anything to do with the demo collection in the CMS, it seems as though it was still detecting the old demo changes in the background and failing to link them to anything in the CMS which caused the error.


Extend .fire_event to allow for additional parameters needed for new html5 events

I propose that in order to better support level3 events such as wheel and mouse events, that we enhance the fire_event method to accept an optional hash in addition to the event name.  The hash could contain needed parameter name, value pairs that need to be populated for the proper firing of events like onwheel
Background / additional info:
New 'level3'  events relating to mouse wheel scrolling (http://www.w3.org/TR/DOM-Level-3-Events/#events-wheelevents) need 'delta' parameters provided to indicate the direction and amount of movement of the mouse wheel.  Without being able to provide this parameter, firing a 'wheel' event has basically zero effect as the JS code receiving the event needs the parameter to make sense of the event.  The 'standard' event is now defined as 'wheel' (onwheel) and is documented pretty well by mozilla here https://developer.mozilla.org/en-US/docs/Web/Events/wheel.  As you can see it allows for multiple parameters to indicate the scrolling movement of the wheel (x,y,z,unit)
The Wheel event replaces some older events (different in different browsers) documented reasonably well at http://www.javascriptkit.com/javatutors/onmousewheel.shtml (which has a nice little inline demo) While only having one or two parameters, even these older deprecated events basically don't work without being able to provide the 'delta', and folks testing for browser compatibility with older browsers may still need to be able to fire these events and include parameters when doing so.
In addition to wheel events where we need to indicate direction+distance along at least one axis, there are also level3 mouse events which have parameters for things like alt, ctrl, shift keys being held down, which button(s) are pressed, etc.  Being able to include those parameters allows us to easily accommodate creating mouse events such as a drag and drop with a key like ctrl or alt held down, or something strange like a shift-left-mousedown.
One reason users need to be able to fire such events are Custom scrollbox controlls like the jQuery "slimScroll" control (see  http://rocha.la/jQuery-slimScroll for live examples you can try to script against) These controls are mainly manipulated by wheel events, or drag and drop of a div that is rendered as a scrollbar.  In some cases accessing the scrollbar div is very difficult (if autohide is enabled) and it would be far simpler to be able to just fire mousewheel events instead dragging the dammed bar.  However this is not currently possible because fire_event does not allow for any additional parameters to indicate the 'delta' value(s).

I know some of this would be 'easier' by creating some kind of method specifically to simulate scrolling the mouse wheel etc, but even so, there is always going to be a need to be able to fire specific events with specific parameters, so even if we made special mouse_scroll methods, I think we still ought to make this change to fire_event

I'm personally against this due to the following reasons:

The event should happen upon user interaction, not explicit #fire_event call.
If event can only be triggered using #fire_event, then the test is not correct (i.e. does not work through user interaction) or this is something that should be handled by AdvancedUserInteractions in selenium-webdriver.

That's pretty much the same reason why selenium-webdriver lacks #fire_event method.
@titusfortner @zeljkofilipin Your thoughts?

I do not really have an opinion about this, sorry. :)

Perhaps I am confused, how using watir-webdriver do we simulate the 'interaction' of a user moving their mouse over a given element and scrolling the mouse wheel down three ticks? (Causing a wheel event to be fired).  What does the code for that look like?  Go to the site I linked that has the inline example where scrolling the mouse wheel when over the image causes the images to change.  Show me how you code a test that validates scrolling the wheel causes the image to change.

I completely agree that encouraging the use of javascript to do things that a user can't do (force something to be visible, or take an action on a non-visible element) is a bad thing.
That being said, using a scroll wheel *is a frequently used user interaction, and one that Selenium doesn't directly support. The w3c spec for webdriver doesn't mention mouse wheel specifically, but has several descriptions of correct scrolling behvaior.
So, while I'm not opposed to the idea of fire event support for this, I'm not sure I understand why the current scrolling implementations are inadequate.
@Chuckv do you have an example for where this is necessary as opposed to the webdriver call for - element.wd.location_once_scrolled_into_view
What I see on the site you linked responds to the above command just fine.

So titus, on the page at http://www.javascriptkit.com/javatutors/onmousewheel.shtml you were able to cause the slideshow to change between showing the different seasonal images?  Can you share the code?  What about scrolling the scroll boxes at http://rocha.la/jQuery-slimScroll to change which paragraphs of text are in view?

I've already said there isn't a way to handle mouse wheel actions. I also don't think the example site that demos the availability of a function is a sufficient use case to warrant supporting non-webdriver interactions.
The real issue is whether you can scroll, and yes, the line of code I wrote in my last message will move the paragraphs into view so you can get the text from them.
first_p = browser.div(id: 'slimtest1').p
last_p =  browser.div(id: 'slimtest1).ps.last
first_p.text  => 'ipso lorem mumbo jumbo, etc...'
last_p.text => ''
last_p.wd.location_once_scrolled_into_view
first_p.text => ''
last_p.text => 'ipso lorem mumbo jumbo, etc...'

So, there is a mouse.atom that includes wheel interactions - https://github.com/SeleniumHQ/selenium/blob/master/javascript/atoms/mouse.js
I'm not certain how to build it or this is one that gets built, or the interface we'd need to provide to use it. @p0deje do you know how we would do this? Otherwise we can ping Simon or Jim about it.

I have no idea how to call atoms from within Watir. I'm not even sure they will be available in all the drivers.


Pandas.DataFrame class support part 3

Origin
Ran 95 tests in 16.922s
FAILED (failures=3, errors=59, skipped=14)

This PR
Ran 95 tests in 47.460s
FAILED (errors=25, skipped=14)

I will address an issue with median() in separate PR

Hello @shssf! Thanks for opening this PR. We checked the lines you've touched for PEP 8 issues, and found:

In the file hpat/__init__.py:

Line 81:121: E501 line too long (126 > 120 characters)

In the file hpat/datatypes/hpat_pandas_dataframe_pass.py:

Line 68:1: E302 expected 2 blank lines, found 1


Introduce goreleaser for provider versioning and github releases

Hey Ricardo, I saw your project on Mastodon and I appreciate your efforts in this regard. Good examples of what to do with the new framework are hard to come by!
This PR introduces goreleaser to the project.
The project will still continue to build in the usual way, but when the project is tagged (git tag vX.X.X)  and goreleaser is run (see comments at the top of .goreleaser.yml - this operation requires a GPG key and github API token), goreleaser will:

build binaries for various OS/architecture combinations
package those binaries with a manifest file, suitable for consumption by the terraform registry
sign the packaged binaries (required by the terraform registry)
upload the results to the github releases page like this. This is where the registry expects to find the provider.

goreleaser also populates tag and commit variables which get carried around by the provider struct. These can be useful for diagnostics, and are used to set provider.MetadataResponse.Version in provider.Metadata().

The shortCommit() and version() functions at the bottom of provider.go choose between the globals (populated by goreleaser's ldFlags options) and the constants (devel and 0.0.0), then stash the selected value in the provider struct.

So, the flow is:
goreleser populates global variables commit and tag in the buildonaws package.
https://github.com/chrismarget/custom-provider-with-terraform-plugin-framework/blob/87a97242e6e7279f18306220c86ef6376650c7d3/.goreleaser.yml#L20
The provider's New() method invokes version() and shortCommit() functions when creating the provider object.
https://github.com/chrismarget/custom-provider-with-terraform-plugin-framework/blob/87a97242e6e7279f18306220c86ef6376650c7d3/buildonaws/provider.go#L31
version() and shortCommit() consider the gobal variables and their backups (constants), return strings representing the version.
https://github.com/chrismarget/custom-provider-with-terraform-plugin-framework/blob/87a97242e6e7279f18306220c86ef6376650c7d3/buildonaws/provider.go#L135
As it stands now, buildOnAWSProvider.commit isn't doing anything. Maybe use it in some debugs, or maybe change the version string to something like "v0.0.0_"... I dunno. I included it b/c it seemed useful, and not obvious how to get it out of goreleaser.

Understood. Is it possible to add support for the .goreleaser without changing the implementation of the provider? As in, do we actually need to have the information about the commit + version in the provider's struct so the goreleaser work?

I only included the build version stuff (ld flags, extra payload in the provider structure, etc...) so that the provider's Metadata() method could populate the version field in the response.
https://github.com/chrismarget/custom-provider-with-terraform-plugin-framework/blob/87a97242e6e7279f18306220c86ef6376650c7d3/buildonaws/provider.go#L45
It's not needed.

Got it. I think it makes sense to keep it them as they seem to represent a best practice, and I would like to showcase as much best practices as possible in this repo. With that said, could you please:

Rename the function shortCommit() to just commit()?
Move the functions commit() and version() to right above the New() function?

Thanks,

commit() will collide with var commit, I think. That's how I wound up with "short" and "tag" (vs version).
Those functions could be eliminated altogether... just put their logic in New().


K8SPXC-269 Use correct env variables for xbcloud authentication

Test name
Status

storage
passed

recreate
passed

scaling
passed

init-deploy
passed

big-data
passed

self-healing
passed

scaling-proxysql
passed

limits
passed

monitoring
passed

upgrade
failed

restore-to-encrypted-cluster
passed

self-healing-advanced
failed

monitoring-2-0
passed

operator-self-healing
passed

upgrade-consistency
passed

affinity
passed

security-context
passed

one-pod
failed

demand-backup
passed

auto-tuning
passed

proxysql-sidecar-res-limits
passed

scheduled-backup
failed

demand-backup-encrypted-with-tls
failed

Test name
Status

big-data
passed

scaling
passed

init-deploy
passed

scaling-proxysql
passed

limits
passed

upgrade
passed

monitoring
passed

monitoring-2-0
passed

affinity
passed

one-pod
passed

recreate
passed

restore-to-encrypted-cluster
passed

demand-backup
passed

scheduled-backup
failed

storage
passed

self-healing
passed

self-healing-advanced
passed

auto-tuning
passed

proxysql-sidecar-res-limits
passed

upgrade-consistency
passed

security-context
passed

operator-self-healing
passed

demand-backup-encrypted-with-tls
failed

Test name
Status

big-data
passed

init-deploy
passed

limits
passed

storage
passed

monitoring
passed

self-healing
passed

monitoring-2-0
passed

self-healing-advanced
passed

affinity
passed

operator-self-healing
passed

recreate
passed

one-pod
passed

restore-to-encrypted-cluster
passed

auto-tuning
passed

demand-backup
passed

proxysql-sidecar-res-limits
passed

scheduled-backup
failed

scaling
passed

scaling-proxysql
passed

upgrade
passed

upgrade-consistency
passed

security-context
passed

demand-backup-encrypted-with-tls
failed

Test name
Status

recreate
passed

restore-to-encrypted-cluster
passed

demand-backup
passed

scheduled-backup
failed

storage
passed

scaling
passed

self-healing
passed

scaling-proxysql
passed

self-healing-advanced
passed

upgrade
passed

operator-self-healing
passed

upgrade-consistency
passed

security-context
passed

init-deploy
passed

limits
passed

monitoring
passed

monitoring-2-0
passed

affinity
passed

one-pod
passed

auto-tuning
passed

proxysql-sidecar-res-limits
passed

big-data
passed

demand-backup-encrypted-with-tls
failed

Test name
Status

storage
passed

scaling
passed

big-data
passed

self-healing
passed

scaling-proxysql
passed

upgrade
passed

self-healing-advanced
passed

operator-self-healing
passed

upgrade-consistency
passed

init-deploy
passed

recreate
passed

security-context
passed

limits
passed

restore-to-encrypted-cluster
passed

monitoring
passed

monitoring-2-0
passed

demand-backup
passed

affinity
passed

scheduled-backup
failed

one-pod
passed

auto-tuning
passed

proxysql-sidecar-res-limits
passed

demand-backup-encrypted-with-tls
failed


[RFC] Add default options

Adds default options as discussed in #35
defaults didn't seem like a plugin-able action to me, so I wrote it as a special case.

I like it! Let's leave the discussion open for a little bit before merging so we can get feedback from others like @casey who were involved in the discussion about this.
Once that's done, we should add to the documentation in the readme as well, and we should probably add a test case.

@anishathalye sounds good!

Looks good!
I added a comment about doing some extra validation on the defaults object. It would be a good opportunity to print a helpful error message, and hopefully make it easier for users to debug config files, for example if they misspell a directive.
It looks like with this implementation we support multiple defaults blocks, with the semantics that each defaults block overrides the previous one. I think this is reasonable, but we should definitely call that out in the readme so that people know that order matters.
Another thing to think about is that, currently, plugins are able to implement the "can_handle(action)" method, which gives them considerable flexibility in which actions they can handle. They could, for example, handle any action that matches a regex, for example "remote-shell-[a-z0-9]+" and then run a command on a remote host with that name. I don't think anyone is taking advantage of this, but the possibility is there.
Given that, there's a little bit of a mismatch between how defaults get passed to plugins. self._defaults.get(action, {})) will do exact string matching, so a plugin that accepts patterns will only get the defaults value which matches the exact string that it is currently handling.
I don't think this really matters, since no plugin I know of actually accepts patterns, but it's good to keep in mind.

@casey Yeah, I was actually thinking that passing defaults in to handle() seemed a little too restrictive. For example, what if some particular plugin wanted to reference defaults from another plugin? The way I set it up in this PR wouldn't allow for that.
I think a better solution might be to pass a reference to a global plugin_defaults dict when we __init__ each plugin in _load_plugins. This would solve both the problem @casey poses and the one I just mentioned. As an added precaution, we could make plugin_defaults immutable for plugins. It would only be mutable through the special defaults directive handled by the Dispatcher.
@anishathalye Thoughts? This would be a slight restructure to the plugin interface.

Random thought -- I don't know if this is actually a problem, but this will break old plugins (function arity mismatch). Not sure if we consider the current plugin interface stable (can this not land in v1.x / do we need a major version bump because we're breaking backwards compatibility).
I like supporting multiple - defaults directive (it seems more reasonable than having a somewhat arbitrary restriction that it can be done only once). Every time we specify another defaults set, we could either update (merge dicts) or replace. I like the idea of building a solution that allows for plugins to peek at the entire defaults dictionary for the reason that @casey mentioned.
Not sure exactly how the design should look (additional arg vs reference to global plugin_defaults dict). Another way is to add some object to manage this using a new Context object. So like the Plugin's current ivar base_directory would instead be accessed through a reference to a context object that the plugin has, self.context.base_directory(), and we could also have a method to get defaults like self.context.defaults(). Just another way of doing it.
I'm not sure if this is actually a good design. I'm kinda sleep-deprived at the moment, so I'll think about it again tomorrow when I'm more awake.

I think between merging subsequent defaults blocks and replacing them, I like replacing better, just because it's easier to keep track of, and there will probably be fewer surprises for users.

Okay, makes sense, +1 for replacing rather than updating.

Okay, I implemented a modified version of @aykamko's contribution: https://github.com/anishathalye/dotbot/commit/4f8a1cd6b7e8e1385489174695f9927954416a6e (with documentation and tests; credits in commit message).
It's currently on the develop branch, not merged into master.
How does it look?

@casey thanks for the quick feedback on the patch!
I'll merge this in a day or two if there's no other feedback from anyone.
(I realize that this is slightly breaking the plugin API but I don't think it's a big deal, I don't think anyone is actually using plugins, and if they are, it should be a one minute fix.)

Ok, made some finishing touches and merged in f52bbd1eec0d6fb103c5fcbb75c03ca223fffdb7.
If there's anything else that needs to be changed, the change can be applied on top.


Add logging and/or error messages.

Generally we want to log to console.
Consider supporting different logging levels.
Consider supporting --quiet for no output.


build --release is failing in webpack

cordova build android

is successfuly building in platforms/android/build/outputs/apk/android-debug.apk
But when I want to build a release with
cordova build android --release

webpack build is failing with :
Before deploy hook started...
Checking is node modules installed...
Node modules already installed.
Starting webpack build...
Error happened when webpack build: Error: Command failed: /home/emak/code/portrait/node_modules/.bin/webpack --env.release
fallbackLoader option has been deprecated - replace with "fallback"
loader option has been deprecated - replace with "use"
clean-webpack-plugin: /home/emak/code/portrait/www has been removed.
(node:16644) DeprecationWarning: loaderUtils.parseQuery() received a non-string value which can be problematic, see https://github.com/webpack/loader-utils/is
sues/56                                                                                parseQuery() will be replaced with getOptions() in the next major version of loader-utils.

Webpack build completed to www folder successfully!
Error happened on main chain:
Error: Error happened when webpack build: Error: Command failed: /home/emak/code/portrait/node_modules/.bin/webpack --env.release
fallbackLoader option has been deprecated - replace with "fallback"
loader option has been deprecated - replace with "use"
clean-webpack-plugin: /home/emak/code/portrait/www has been removed.
(node:16644) DeprecationWarning: loaderUtils.parseQuery() received a non-string value which can be problematic, see https://github.com/webpack/loader-utils/is
sues/56                                                                                parseQuery() will be replaced with getOptions() in the next major version of loader-utils.

    at exec (/home/emak/code/portrait/hooks/hookers.js:171:19)
    at ChildProcess.exithandler (child_process.js:218:5)
    at emitTwo (events.js:106:13)
    at ChildProcess.emit (events.js:191:7)
    at maybeClose (internal/child_process.js:885:16)
    at Process.ChildProcess._handle.onexit (internal/child_process.js:226:5)
Error: Error happened when webpack build: Error: Command failed: /home/emak/code/portrait/node_modules/.bin/webpack --env.release
fallbackLoader option has been deprecated - replace with "fallback"
loader option has been deprecated - replace with "use"
clean-webpack-plugin: /home/emak/code/portrait/www has been removed.
(node:16644) DeprecationWarning: loaderUtils.parseQuery() received a non-string value which can be problematic, see https://github.com/webpack/loader-utils/is
sues/56                                                                                parseQuery() will be replaced with getOptions() in the next major version of loader-utils.

I tried to change webpack.config.js:L77-78 according to this messages without success.
fallbackLoader option has been deprecated - replace with "fallback"
loader option has been deprecated - replace with "use"

My current workaround is to launch
cordova prepare
then
cordova compile android --release
so that webpack compiles as usual without the release flag. The outputed JS may not be optimal but it runs.

Are you using latest version of template?

No, I am running 1.0.6
I will upgrade to the latest version and keep you posted. Is there another way than manually updating the files that changed since 1.0.6 to upgrade ?

replace your project's
webpack/
hooks/

directories and

package.json
webpack.config.js

files with current version's. (check template_src folder)

Is problem fixed?

Hello @Em-AK;
I updated the dependencies and tested in my local. Please check one more time.
Have a great day!

Hi @Em-AK I've been seeing similar error output when running a build release.
In my case I found running the webpack process on it's own
./node_modules/.bin/webpack --env.release
gave a more verbose error report, and the problems turned out to be Uglifyjs finding syntax errors in my vue components.

@coedycode I updated the template, can you test with latest update?
Thank you so much 😃

@centrual  I've updated my copy to the latest webpack config and hookers, with the .bablerc removed I get  similar error messages to before, but with .bablerc there the build works fine.
Thanks for this great build tool btw, it's really helped me get started with phonegap.

Hello Richard;
I changed uglifyjs plugin to another one. Also, i updated dependencies. So please create new project and move your project files inside it.
Have a great Day!
16 Mar 2017 12:50 tarihinde Richard Creek<EMAIL_ADDRESS>yazdı:
@centrualhttps://github.com/centrual I've updated my copy to the latest webpack config and hookers, with the .bablerc removed I get similar error messages to before, but with .bablerc there the build works fine.
Thanks for this great build tool btw, it's really helped me get started with phonegap.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://github.com/centrual/cordova-template-framework7-vue-webpack/issues/18#issuecomment-287007445, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AB6KEAMrEIlf2z6F1S0em_Wg0PSDhl6gks5rmQX0gaJpZM4MSZhp.

I tested the latest version, because of that i closing the issue.

Is problem fixed?