feat: ✨ Improve events export in framework wrapper

Pull Request
📖 Description
To make the framework wrapper better maintainable, the exports of the components events will be unified and done in the index.ts
🎫 Issues
Closes #303
👩💻 Reviewer Notes
📑 Test Plan
✅ DoD

[ ] I have tested my changes manually.
[ ] I have added automatic tests for my changes (unit- and visual regression tests).
[ ] I have updated the project documentation to reflect my changes (e.g. CHANGELOG, Storybook, ...).
[ ] I have made sure to follow the projects coding and contribution guides.
[ ] I have made sure that the bundle size has changed appropriately.
[ ] I have validated that there are no accessibility errors.
[ ] I have used design tokens instead of fix css values

I think we have a problem with our exports, details see in comments. We should get this clear before releasing something that may be broken. Main problem stems from the fact that we reexport all types from @components, but packages may also export things with the same name, which may lead to confusion (e.g. type SynInput vs SynInput React component).

We decided to not export all events in the index.ts file. It would be much cleaner to not export the events at all in the wrappers, so the types are only used / exported from the components package.
Both of this variants (exporting in index.ts and not exporting the events at all in the wrappers) would lead to a major release.
Because of that we have decided to do neither of those two possibilities.
The only thing which will be done in this PR now, is to unify the handling of the events exports by exporting all used events in the component itself (was missing in the vue wrapper).


Error from server (NotFound): deployments.apps "jupyternotebook-elastic" not found

Hi, do you know how to resolve this issue?
eugene@Eugenes-Mac-mini elastic-jupyter-operator % kubectl port-forward deploy/jupyternotebook-elastic 8888:8888
Error from server (NotFound): deployments.apps "jupyternotebook-elastic" not found

All steps
eugene@Eugenes-Mac-mini elastic-jupyter-operator % minikube start
😄  minikube v1.24.0 on Darwin 12.1 (arm64)
✨  Automatically selected the docker driver
👍  Starting control plane node minikube in cluster minikube
🚜  Pulling base image ...
🔥  Creating docker container (CPUs=2, Memory=4000MB) ...
🐳  Preparing Kubernetes v1.22.3 on Docker 20.10.8 ...
    ▪ Generating certificates and keys ...
    ▪ Booting up control plane ...
    ▪ Configuring RBAC rules ...
🔎  Verifying Kubernetes components...
    ▪ Using image gcr.io/k8s-minikube/storage-provisioner:v5
🌟  Enabled addons: storage-provisioner, default-storageclass
🏄  Done! kubectl is now configured to use "minikube" cluster and "default" namespace by default

eugene@Eugenes-Mac-mini elastic-jupyter-operator % kubectl apply -f ./hack/enterprise_gateway/prepare.yaml
namespace/enterprise-gateway created
serviceaccount/enterprise-gateway-sa created
clusterrole.rbac.authorization.k8s.io/enterprise-gateway-controller created
clusterrole.rbac.authorization.k8s.io/kernel-controller created
clusterrolebinding.rbac.authorization.k8s.io/enterprise-gateway-controller created

eugene@Eugenes-Mac-mini elastic-jupyter-operator % make deploy
go: creating new go.mod: module tmp
go get: installing executables with 'go get' in module mode is deprecated.
  To adjust and download dependencies of the current module, use 'go get -d'.
  To install using requirements of the current module, use 'go install'.
  To install ignoring the current module, use 'go install' with a version,
  like 'go install example.com/cmd@latest'.
   output:crd:artifacts:config=config/crd/bases
go: creating new go.mod: module tmp
go get: installing executables with 'go get' in module mode is deprecated.
  To adjust and download dependencies of the current module, use 'go get -d'.
  To install using requirements of the current module, use 'go install'.
  To install ignoring the current module, use 'go install' with a version,
  like 'go install example.com/cmd@latest'.

I think the operator is not running.

@gaocegege I am working on Apple M1. It's ARM64 chip. You support only amd64 arch.
I've tested it on linux/intel server and all is ok.
When I use M1 arm64 I have a issue:
eugene@Eugenes-Mac-mini elastic-jupyter-operator % kubectl get pods --all-namespaces
NAMESPACE                         NAME                                                           READY   STATUS              RESTARTS   AGE
elastic-jupyter-operator-system   elastic-jupyter-operator-controller-manager-64fffc97d7-cg4np   0/1     ContainerCreating   0          18s
kube-system                       coredns-78fcd69978-nzpk7                                       1/1     Running             0          35s
kube-system                       etcd-minikube                                                  1/1     Running             0          48s
kube-system                       kube-apiserver-minikube                                        1/1     Running             0          50s
kube-system                       kube-controller-manager-minikube                               1/1     Running             0          48s
kube-system                       kube-proxy-b92g7                                               1/1     Running             0          35s
kube-system                       kube-scheduler-minikube                                        1/1     Running             0          48s
kube-system                       storage-provisioner                                            1/1     Running             0          47s

eugene@Eugenes-Mac-mini elastic-jupyter-operator % kubectl get pods --all-namespaces
NAMESPACE                         NAME                                                           READY   STATUS    RESTARTS      AGE
elastic-jupyter-operator-system   elastic-jupyter-operator-controller-manager-64fffc97d7-cg4np   0/1     Error     1 (14s ago)   54s
kube-system                       coredns-78fcd69978-nzpk7                                       1/1     Running   0             71s
kube-system                       etcd-minikube                                                  1/1     Running   0             84s
kube-system                       kube-apiserver-minikube                                        1/1     Running   0             86s
kube-system                       kube-controller-manager-minikube                               1/1     Running   0             84s
kube-system                       kube-proxy-b92g7                                               1/1     Running   0             71s
kube-system                       kube-scheduler-minikube                                        1/1     Running   0             84s
kube-system                       storage-provisioner                                            1/1     Running   0             83s

eugene@Eugenes-Mac-mini elastic-jupyter-operator % kubectl get pods --all-namespaces
NAMESPACE                         NAME                                                           READY   STATUS             RESTARTS      AGE
elastic-jupyter-operator-system   elastic-jupyter-operator-controller-manager-64fffc97d7-cg4np   0/1     CrashLoopBackOff   1 (12s ago)   60s
kube-system                       coredns-78fcd69978-nzpk7                                       1/1     Running            0             77s
kube-system                       etcd-minikube                                                  1/1     Running            0             90s
kube-system                       kube-apiserver-minikube                                        1/1     Running            0             92s
kube-system                       kube-controller-manager-minikube                               1/1     Running            0             90s
kube-system                       kube-proxy-b92g7                                               1/1     Running            0             77s
kube-system                       kube-scheduler-minikube                                        1/1     Running            0             90s
kube-system                       storage-provisioner                                            1/1     Running            0             89s

I will create a new issue related to Support ARM64 architecture.

Interesting. I do not have a ARM64 machine here. Could you please show the logs of the elastic-jupyter-operator-controller-manager-64fffc97d7-cg4np?
Maybe this command kubectl logs -n elastic-jupyter-operator-system logs -p elastic-jupyter-operator-controller-manager-64fffc97d7-cg4np

@gaocegege Back-off restarting failed container
eugene@Eugenes-Mac-mini elastic-jupyter-operator % kubectl get event -n elastic-jupyter-operator-system
LAST SEEN   TYPE      REASON              OBJECT                                                              MESSAGE
2m44s       Normal    Scheduled           pod/elastic-jupyter-operator-controller-manager-64fffc97d7-s7kdr    Successfully assigned elastic-jupyter-operator-system/elastic-jupyter-operator-controller-manager-64fffc97d7-s7kdr to minikube
29s         Normal    Pulling             pod/elastic-jupyter-operator-controller-manager-64fffc97d7-s7kdr    Pulling image "ccr.ccs.tencentyun.com/kubeflow-oteam/elastic-jupyter-operator:latest"
95s         Normal    Pulled              pod/elastic-jupyter-operator-controller-manager-64fffc97d7-s7kdr    Successfully pulled image "ccr.ccs.tencentyun.com/kubeflow-oteam/elastic-jupyter-operator:latest" in 1m7.989985864s
24s         Normal    Created             pod/elastic-jupyter-operator-controller-manager-64fffc97d7-s7kdr    Created container manager
24s         Normal    Started             pod/elastic-jupyter-operator-controller-manager-64fffc97d7-s7kdr    Started container manager
83s         Normal    Pulled              pod/elastic-jupyter-operator-controller-manager-64fffc97d7-s7kdr    Successfully pulled image "ccr.ccs.tencentyun.com/kubeflow-oteam/elastic-jupyter-operator:latest" in 7.805613796s
5s          Warning   BackOff             pod/elastic-jupyter-operator-controller-manager-64fffc97d7-s7kdr    Back-off restarting failed container
61s         Normal    Pulled              pod/elastic-jupyter-operator-controller-manager-64fffc97d7-s7kdr    Successfully pulled image "ccr.ccs.tencentyun.com/kubeflow-oteam/elastic-jupyter-operator:latest" in 5.947165502s
24s         Normal    Pulled              pod/elastic-jupyter-operator-controller-manager-64fffc97d7-s7kdr    Successfully pulled image "ccr.ccs.tencentyun.com/kubeflow-oteam/elastic-jupyter-operator:latest" in 4.720454502s
2m44s       Normal    SuccessfulCreate    replicaset/elastic-jupyter-operator-controller-manager-64fffc97d7   Created pod: elastic-jupyter-operator-controller-manager-64fffc97d7-s7kdr
2m44s       Normal    ScalingReplicaSet   deployment/elastic-jupyter-operator-controller-manager              Scaled up replica set elastic-jupyter-operator-controller-manager-64fffc97d7 to 1

Can you get the log? kubectl logs -n elastic-jupyter-operator-system logs -p elastic-jupyter-operator-controller-manager-64fffc97d7-cg4np

eugene@Eugenes-Mac-mini elastic-jupyter-operator % kubectl get pods --all-namespaces
NAMESPACE                         NAME                                                           READY   STATUS             RESTARTS      AGE
elastic-jupyter-operator-system   elastic-jupyter-operator-controller-manager-64fffc97d7-s7kdr   0/1     CrashLoopBackOff   7 (62s ago)   14m
kube-system                       coredns-78fcd69978-crw4p                                       1/1     Running            0             15m
kube-system                       etcd-minikube                                                  1/1     Running            0             15m
kube-system                       kube-apiserver-minikube                                        1/1     Running            0             15m
kube-system                       kube-controller-manager-minikube                               1/1     Running            0             15m
kube-system                       kube-proxy-brv2b                                               1/1     Running            0             15m
kube-system                       kube-scheduler-minikube                                        1/1     Running            0             15m
kube-system                       storage-provisioner                                            1/1     Running            0             15m

eugene@Eugenes-Mac-mini elastic-jupyter-operator % kubectl logs -n elastic-jupyter-operator-system logs -p elastic-jupyter-operator-controller-manager-64fffc97d7-s7kdr
Error from server (NotFound): pods "logs" not found

Sorry, the command should be kubectl -n elastic-jupyter-operator-system logs -p elastic-jupyter-operator-controller-manager-64fffc97d7-cg4np

eugene@Eugenes-Mac-mini elastic-jupyter-operator % kubectl -n elastic-jupyter-operator-system logs -p elastic-jupyter-operator-controller-manager-64fffc97d7-s7kdr
eugene@Eugenes-Mac-mini elastic-jupyter-operator % kubectl -n elastic-jupyter-operator-system logs -p elastic-jupyter-operator-controller-manager-64fffc97d7-s7kdr
eugene@Eugenes-Mac-mini elastic-jupyter-operator %

Maybe there are no logs for this pod

Sure, thanks. Can you please show the exit code of the pod?

https://www.alibabacloud.com/press-room/alibaba-cloud-unveils-new-server-chips-to-optimize-cloud-computing-services

Built upon advanced 5nm process technology, Yitian 710 is powered by 128 Arm cores with 3.2GHz top clock speed to deliver exceptional performance and excellent energy efficiency. Each processor chip has 60 billion integrated transistors. Yitian 710 is the first server processor that is compatible with the latest Armv9 architecture and includes 8 DDR5 channels and 96-lane PCIe 5.0, providing high memory and I/O bandwidth.

@gaocegege Can we create a small arm64 server with minikube and test it?

@EugeneTorap I am not sure if minikube supports it.

@gaocegege I wrote about it in discord

Gotcha, I replied there.


Change the API due to consistency principle

Closes #36
This PR intends to improve the Euneus API by changing some weird things about the v1. That means many code changes, so a new major version (v2) must be released.

[!WARNING]
This is a draft PR and is under development.

Plugins
Plugins are now called codecs:

A codec is a device or computer program that encodes or decodes a data stream or signal.

So, renaming the plugins option to codecs and the euneus_plugin behavior to euneus_codec makes much sense to me.
The codecs (AKA plugins) now accept arguments that need to be parsed before the encoding and decoding. Arguments are any term and are defined by passing a tuple of two elements to the codecs list, where the first element is the name of a built-in codec or the module name of a custom one, and the second is the arguments, e.g.:
% {Name :: atom() | module(), Arguments :: term()}.
euneus:encode(<<"foo">>, #{binary => #{codecs => [{euneus_foo_codec, [foo_as_bar]}]}}).

% If just the name of the codec is passed to the codecs list, the arguments will be an empty list (`[]`):
euneus:encode(<<"foo">>, #{binary => #{codecs => [euneus_foo_codec]}}).

To remove the need to always normalize these arguments, a new callback init/0 is introduced in euneus_codec (AKA euneus_plugin) and must return {ok, term()}.
So, the euneus_codec behavior have now these callbacks:
-callback init(term()) -> {ok, term()}.

-callback encode(Input, CodecOpts, EncodeSettings) -> Output when
    Input :: term(),
    CodecOpts :: term(),
    EncodeSettings :: encode_settings(),
    Output :: encode(Input).

-callback decode(Input, CodecOpts, DecodeSettings) -> Output when
    Input :: term(),
    CodecOpts :: term(),
    DecodeSettings :: decode_settings(),
    Output :: decode(Input).

Encode
Encode options
The nulls option is now called null_values and its default is now [null, undefined] instead of just [undefined], e.g.:
1> euneus:encode_to_binary([null, undefined]).
{ok,<<"[null,null]">>}

This is more concise with the Javascript result:
> JSON.stringify([null, undefined])
'[null,null]'

Elixir uses :nil to represent null, so you must override the default to get the same result:
1> euneus:encode_to_binary([nil, undefined], #{null_values => [nil, undefined]}).
{ok,<<"[null,null]">>}

The drop_nulls plugin does not exist anymore in Euneus. We now have a skip_values option for maps that drop keys that values are on this list and its default is [undefined], e.g.:
1> euneus:encode_to_binary(#{a => null, b => undefined}, #{}).
{ok,<<"{\"a\":null}">>}

In Javascript:
> JSON.stringify({a: null, b: undefined})
'{"a":null}'

To disable this behavior, the skip_values option must be overridden:
1> euneus:encode_to_binary(#{a => null, b => undefined}, #{map => #{skip_values => []}}).
{ok,<<"{\"a\":null,\"b\":null}">>}

Encode term types
tuple, pid, port, and reference are now encoded by default via:

tuple: tuple_to_list/1;
pid: pid_to_list/1;
port: port_to_list/1;
reference: ref_to_list/1.

In v1, these types are encoded via codecs (AKA plugins).
Encode options spec
-type options() :: #{
    null_values => [null()],
    binary => #{
        encode => encode_fun(binary()),
        codecs => [codec(binary())]
    },
    atom => #{
        encode => encode_fun(atom()),
        codecs => [codec(atom())]
    },
    integer => #{
        encode => encode_fun(integer()),
        codecs => [codec(integer())],
        base => integer_base()
    },
    float => #{
        encode => encode_fun(float()),
        codecs => [codec(float())],
        to_binary_options => float_to_binary_options()
    },
    list => #{
        encode => encode_fun(list()),
        codecs => [proplist | codec(list())]
    },
    map => #{
        encode => encode_fun(map()),
        codecs => [codec(map())],
        skip_values => [term()]
    },
    tuple => #{
        encode => encode_fun(tuple()),
        codecs => [ datetime
                  | timestamp
                  | ipv4
                  | ipv6
                  % TODO: {record, Opts}
                  | codec(tuple()) ]
    },
    pid => #{
        encode => encode_fun(pid()),
        codecs => [codec(pid())]
    },
    port => #{
        encode => encode_fun(port()),
        codecs => [codec(port())]
    },
    reference => #{
        encode => encode_fun(reference()),
        codecs => [codec(reference())]
    },
    escape => json
            | html
            | javascript
            | unicode
            | escape_fun(binary()),
    handle_error => handle_error_fun()
}.

[!NOTE]
This is not the end of the description of this PR.
Suggestions welcome.
TODO:

[ ] More encoding explanation
[ ] Decode

[ ] Options explanation
[ ] Options spec

[ ] Benchmark

[ ] Encode
[ ] Decode

[ ] Update docs

I haven't had much time the last few weeks to look into this in depth, but not that I have, I think this looks really great!

Thanks, @asabil! I do not have too much time in the last month to look at these changes and finish the PR. I hope to finish it next month.

Closing this PR in favor of #43


Reinforce sec attr existence

I know we're under a bit of a time crunch because staging is broken but I would like this to be thought out before we push a fix.

I updated the getSubmission function to return the SecurityAttribute otherwise it would have always defaulted to "Unclassified".  The rest of the changes that I pushed were automatic Prettier changes on the code.
This should now be ready to merge.


Handle WebSockets Across App & Refactor Frontend State

Currently, a WebSocket connection is established in the Terminal component. This is problematic because WebSocket messages will be used to update the frontend for all types of messages (including chat, code editor, browser, and planner), not just the terminal as per https://github.com/OpenDevin/OpenDevin/issues/44.
This PR moves the WebSocket connection outside of the Terminal component so that all WebSocket messages can be propagated appropriately. To handle state changes from WebSocket messages, component state is moved into a Redux store. This also makes component files leaner and achieves better separation of the data layer from the view layer.
TLDR: this PR adds Redux and refactors the frontend so that all components can make use of a shared WebSocket.

I suggest we avoid using Redux for state management as it introduces unnecessary complexity. Instead, we should opt for a simpler and more case-appropriate solution like Jotai.

@suryavirkapur Can you give an example of unnecessary complexity in this commit?
I chose Redux for several reasons:

Standardization: Redux is the de facto standard for state management. Most frontend developers are familiar with Redux. There are numerous competing frameworks like MobX, Jotai, Recoil, etc. but it's most productive to use something everyone already knows.
Simplicity: Redux has been streamlined by the development of Redux Toolkit. Redux used to involve a lot of boilerplate in the past, but Redux Toolkit has eliminated that boilerplate.
 This includes development tools (e.g., time travel debugger), other libraries that extend its functionality, and overall community support.
Scalability: This project will grow more complex over time as we add logging, error handling, more complex WebSocket communication and API calls, etc. Redux Middleware allows us to easily extend the store to handle this, and the design of Redux allows us to easily reason about complex state management scenarios.

I prefer not using Jotai because a lot of its usage patterns encourage tightly coupling state to components, which makes test cases more cumbersome to write, involving many complex mocks and fixtures.
I want to avoid this becoming a framework debate though because it's unproductive. I've used Redux for a similar project and it worked well for the reasons above. Overall I think we should move forward unless there are major reservations.

@yimothysu Your argument is sound. I feel that Redux and Redux Toolkit might be overkill for this project. I suggest exploring this implementation, which is more straightforward and analogous to using useState in React. Moreover, Jotai also boasts a well-established ecosystem and offers a simpler approach.

This seems like a strong improvement over the current state, so let's get it in. Worth having the discussion re: Redux, maybe in the #frontend channel on Slack.


400 Bad Request when using with R2

Hey Tim,
I'm getting an error when trying to use the lib with R2 for some reason. I have tested my config & endpoint using Bruno ( Postman alternative) and that works properly, but I'm getting bad request with next-upload.
Have you ever tested it with R2?
Error:

This is my config:
export const config: NextUploadConfig = {
    maxSize: '3mb',
    bucket: '<bucket_name>',
    client: {
        region: 'auto',
        endpoint: env.R2_BUCKET_ENDPOINT,
        credentials: {
            secretAccessKey: env.R2_SECRET_KEY,
            accessKeyId: env.R2_ACCESS_KEY,
        },
    },
};

Thank you,
-8x4

Let me reproduce this locally with r2. I'll get back to you in 24hrs or so.

I was able to reproduce it. I'll figure out the fix and publish it over the weekend.

Thank you so much for the quick turn-around!
and yes, from what I've gathered, it does respect contenth-length headers :)

Update: I have R2 support working, you can see the PR here, https://github.com/TimMikeladze/next-upload/pull/58
Interesting thing I found when implementing this is that R2 needs to have a CORS config applied onto the bucket, which S3 does not.
All I have left to do is:

[ ] content-length headers
[ ] Update documentation

Will get to it in the next day or so, apologies for the delay. If you need support urgently just build a package off of my PR and it should work as long as you provide service: "r2" in the configuration object when instantiating NextUpload.

This is awesome!
Thank you so much for the quick turnaround! Will test it in a day or so :)

I also tested with BackBlaze B2, seems to have similar issue with Cloudflare R2


Add page on how to retire a gem

https://trello.com/c/1IWOqO4r/2980-decide-how-to-properly-archive-a-gem-and-document-it-2

Thanks for all the comments, @ChrisBAshton and @nicholsj , I've made the suggested changes.


Images on dockerhub and github registry not the same

Code of Conduct

[X] I agree to follow this project's Code of Conduct.

Submission validity

[X] This is not a personal support request, that should be posted on discussions community.
[X] I checked current issues and this request isn't a duplicate of an existing issue, opened or closed.

Self troubleshooting

[X] I've read the documentation and made sure to follow it.
[X] I've read the troubleshooting first steps guide.

Version
1.8.2
Description
I noticed that the fix 4fe274d482243febfbe107557d22857941ab319f is not present in the image I pulled from dockerhub docker pull yourls:1.8.2, but it is present in the image I pulled from github registry docker pull ghcr.io/yourls/yourls:1.8.2.
Docker shows "updated 5 days ago" (20.11.2021), Github shows "updated 6 days ago". The fix was integrated 26 days ago so it should be present in both images.
I have not looked into how the images are created or deployed, so I have no idea about the reason for this discrepancy.
Expectation
I expect that images on Github and Dockerhub have the same content.
Reproduction steps
To see that both images are not the same:
docker run yourls:1.8.2 shows the error message "chown: cannot access 'wp-config.php': No such file or directory"
docker run ghcr.io/yourls/yourls:1.8.2 does not show the error message.
Context
No response

Thanks for opening this issue @akleber.
That said the behavior described is actually the one expected.
As mentioned on the README, there may be a delay between in-repo status and Docker Hub available image.
YOURLS' image on Docker Hub is build by a Docker-official building farm which is completely independent of YOURLS.
This explains the current status:

Last commit in this repo was 6 days ago, so is the image pushed on the YOURLS org registry.
Last change of the ref from official images repo is about a month ago or something, meaning the very latest YOURLS/docker commits are not used.
Official images are regularly recompiled to make sure they used latest upstream images, which explains the 5 days old build.

As of today, YOURLS org' images can be seen as nightly builds from YOURLS/docker perspective, even if this might change a bit in the future to provide more granularity around Docker images.
Do you need one of the latest commit for your usage? I can trigger an ref update, let me know.

Thanks for your explanation I appreciate it. It's clear for me now.
I can use the YOURLS org image so an update is not needed from my side.


The distribute version is on the repo?

Hey @ngokevin
I open this because I saw a user complaining about master being not syncronized with npm.
The potentiall issue could be that master is bug-free meanwhile the registry could have some bug (related with a-asset-items or others...) If it's true.
For now I only can see that there's no diff between
diff
https://raw.githubusercontent.com/ngokevin/aframe-react/master/dist/index.js
vs
<EMAIL_ADDRESS>

unpkg is a cdn of the npm registry

Well... going back to the issue, I would like to have the dist out of the repo basically for have the distribute version in a CDN and atomic (be able to re-create the dist version), as well we would have cleaner PRs.
I can see the benefit of having the dist in the repo as a shareable URL, but since there's options like unpkg, we can provide this URLs as a direct asset.
Thanks!
PS: I didn't express very well on this issue :(

OK!

Well, the dist/ is the package.json main, where it's already compiled. It's not for distribution, just where it's generated.

Will close since dist/ is the built version (with Babel) that npm points to.


[BUG] SUMBT MultiWOZ_zh results are not reproducible

Describe the bug
I have downloaded the Chinese Bert model and the pre-trained model for MultiWOZ_zh. There is a mismatch in the joint accuracy.
To Reproduce
Steps to reproduce the behavior:

Clone the repository. Complete the installation
Download pre-trained model chinese-bert-wwm-ext for MultiWOZ-zh and store under ./pre-trained-models
Download translation-train model for MultiWOZ-zh and store under ./convlab2/dst/sumbt/multiwoz_zh/pre-trained/pytorch_model.bin
Run python3 evaluate.py MultiWOZ-zh sumbt val
Output as follows:
{'Joint Acc': 0.3455532926001358, 'Turn Acc': 0.9451874481406302, 'Joint F1': 0.8130141242520675}

Expected behavior
The reported joint accuracy is 45.1% for MultiWOZ-zh while the code produces 34.5% instead.
Additional information
I have tried to reproduce the experiment and my numbers are in the range of 35% too. I have reproduced the experiment for English MultiWOZ and the joint accuracy for the same is similar to the one posted on the README.
Thanks

Thanks! We are checking this.

Hi, thanks for point it out! Now the issue has been fixed with the PR above.
BTW, this script is only used for checking the performance of the baseline. The official evaluation script used in DSTC9 are eval_file.py and eval_model.py under convlab/dst/dstc9. You may also want to check these two files.
Feel free to tell us if you have any other questions.

Could you give an overview of how to run the evaluation scripts eval_file.py and eval_model.py?
Using python3 evaluate.py MultiWOZ-zh sumbt val is straightforward.
Is there a similar way to use the eval_file.py or eval_model.py?
I do not understand the directory structure while using eval_model.py

We use eval_file.py and eval_model.py for DSTC-9 evaluation, see https://github.com/ConvLab/ConvLab-2 for details.

Thanks for the reply.
As far as I understand, the gold standard output and the predicted output should be in the format of the state for the dataset. Then eval_file.py can be run on these files.
Is there an example script to convert the outputs from the SUMBT model into the format for eval_file.py?

Hi
I am able to reproduce the results with the evaluate.py file.
Thank you for looking into this!


Initial chatbot (untrained)

https://github.com/user-attachments/assets/10aef8e2-3df4-4df6-9a3b-977fc63c7e33

original search is commented out for now


This resolves desk stuttering during movement

This fixes a long-standing issue, see https://github.com/rhyst/linak-controller/issues/48
Tested on Windows 10:
await asyncio.sleep(0.5) // stuttering
await asyncio.sleep(0.46) // stuttering
await asyncio.sleep(0.45) // no stuttering

I chose 0.4 in this PR as a safe option.

Amazing! Thank you.


HHH-9244 Using collection owner name in exception message

@sebersole, @dreab8: Also came across this NPE reported in HHH-9244 in the course of updating OGM to the latest ORM CR. I believe the owner entity type should be used in that exception, which fixes the NPE.
I am not sure though why null is passed for collectionEntity in the one-to-many case and whether that's actually correct. Maybe it should be associatedClass instead of null?

Rebased and applied.
@sebersole, I took a look at the related things we discussed but ended up leaving those as is:

The outer AnnotationException refers to the specific property name which I think is not available at the place where the wrapped exception is raised
colValue and collectionEntity both being passed: the latter is the type of the referenced entity not the owner entity type (at least that is what's passed in the ManyToMany case)

As you say, the entire code could need some love, but that'd take a bit more time.


BluetoolFixup broken on macOS Sonoma and Ventura 13.4+

Due to a regression in BluetoolFixup, Bluetooth may be broken on later versions of Ventura and macOS Sonoma.
The below NVRAM patch is required for BluetoolFixup on 13.4+
# Ventura 13.4 fix for BluetoolFixup
NVRAM:
  Add:
    7C436110-AB2A-4BBB-A880-FE41995C9F82:
      bluetoothInternalControllerInfo: Data | 00000000 00000000 00000000 0000
      bluetoothExternalDongleFailed:   Data | 00

(Fix originally contributed by @qcTimb3rlandqc in IntelBluetoothFirmware#435)
Alternatively, an updated binary is provided by @zxystd here, which should also be applicable for users updating to macOS Sonoma.

@Qonfused They updated the BluetoolFixup:
https://github.com/acidanthera/BrcmPatchRAM/releases


Mention GitHub Sponsors as a way for people to seek funding for open source contributions

It is likely this has been overlooked but it's also likely that it wasn't added to prevent any sort of muddying up a guide meant to only serve with marketing content, and if it's the latter feel free to close!
Can we add a section or mention for GitHub Sponsors as a way for open source contributors to get paid for their work? I would love to add a mention or even a few user stories, but I'm not sure how to gather user stories the same way we did when we created this content. I'd love any guidance if this seems like something worth mentioning 😄

I lobe thee idea..

set

Must it be that ones anyone markets the github he or she will be paid?

I'm new to this.. but I love the idea and very willing to learn😁

Social easing or social engineering liaisons or reality to interactive conversion's consulting firm
First start with government grants and local law or religious establishments to acquire donation for nonprofit united life reinvestment act digitally and personally.    One sentence to one release.          For word progress: ?

It is likely this has been overlooked but it's also likely that it wasn't added to prevent any sort of muddying up a guide meant to only serve with marketing content, and if it's the latter feel free to close!
Can we add a section or mention for GitHub Sponsors as a way for open source contributors to get paid for their work? I would love to add a mention or even a few user stories, but I'm not sure how to gather user stories the same way we did when we created this content. I'd love any guidance if this seems like something worth mentioning 😄

I am hoping so for that after more than 10 years of work experience on GitHub... Lol

Beautiful pic

book/02-git-basics/sections/undoing.asc

book/02-git-basics/sections/undoing.asc

Show

Im really a newbie here and didn't even know what ive been doing hope someone will guide me and I'm really open if i did something wrong..hope you guys understand me


Unsafe Constant Initialization

In ignition::math::Color the color constants are defined like public: static const Color Cyan;. While the resulting interface is nice to use, it could cause static initialization order fiasco as C++ makes no guarantee that global variables in this form is going to be initialized in usage order. In other words, another global variable could use Color::Cyan and be initialized first.
A simple fix is to convert to a function form like the following:
public: const Color& Cyan() { static auto *c = new Color(0, 1, 1, 1); return *c; }
Another solution is more involved but it could retain the ability to refer to constants without parentheses.

Add a constexpr constructor to the class.
In another class, say, ColorConstants, use public: static constexpr Color Cyan = {0, 1, 1, 1};

Both solutions represent a API/ABI change, so I would like to hear some feedback first before sending out PRs.
The Vector classes might be affected by this too.

The Vector classes might be affected by this too.

Yes, I believe that Vector3<T>::UnitX etc. could all affected, at least in theory.  (Some compilers will optimize away the problematic portions, in practice.)
The full list of static const globals on the default branch seems to be: Angle, Color, Material, Matrix3, Matrix4, Pose3, Quaternion, Vector2, Vector3, Vector4.
Note that Material::Predefined() is particularly problematic, because it returns to the user a reference to std::map, which always implies a heap allocation and thus will always be leaked anytime the library is loaded and then unloaded.  Similarly for kMaterialData in src/MaterialType.hh.  Even if those collection types are fixed to be heapless, the class Material has a name which is required to always be on the heap.
Also note that both construction and destruction order are in play here.  As library code, I'd argue that ign-math should have no global constructors nor global destructors registered at all.
For cross-reference, see also https://github.com/ignitionrobotics/sdformat/issues/552.

A simple fix is ...

A third option (similar to the first option in the OP) would be use function-local static std::aligned_storage, which still keeps the data in static global storage, instead of on the heap.  Once example is Drake's never_destroyed implementation.  This can be useful if the constructor is complicated enough that it cannot be made constexpr.  For this option as well as the first one, the function-local static requires the compiler to emit a lock guard instruction and storage for the boolean lock, so that the constant will be latch-initialized upon first use.  This is useful for complicated globals, but is overkill for the simple structs such as vector, color, quaternion, etc.
A fourth option (similar to the second option in the OP) is to keep the member fields static, but instead mark them constexpr at the definition.  See PR #283 for one example.  This is ABI-breaking but not API-breaking.
Therefore, my suggestion is to use:

option (4) for the simple numeric constants (angle, vector3, vector4, pose, quaternion, color) as in PR #283;
either option (1) or option (3) for any global data that is const but cannot be constexpr (material);

Hopefully, there are no cases of mutable global data.

@scpeters, @mjcarroll, and I had a discussion and our preference is to use option (4) as in #283 for the simple numeric constants and option (3) for the rest. To that end, NeverDestroyed has been added to ign-utils in https://github.com/ignitionrobotics/ign-utils/pull/31.

Note that Material::Predefined() is particularly problematic, because it returns to the user a reference to std::map, which always implies a heap allocation and thus will always be leaked anytime the library is loaded and then unloaded. Similarly for kMaterialData in src/MaterialType.hh. Even if those collection types are fixed to be heapless, the class Material has a name which is required to always be on the heap.

(Possibly) related to this - I'm seeing a unit test failure on Fedora rawhide where it appears that the kMaterialData map in src/MaterialType.hh isn't being properly initialized before being used in src/Material.cc.  The UNIT_Material_TEST fails with the following output (full log here):
        Start  35: UNIT_Material_TEST
 34/102 Test  #35: UNIT_Material_TEST .....................***Failed    0.01 sec
Running main() from gtest_main.cc
[==========] Running 3 tests from 1 test case.
[----------] Global test environment set-up.
[----------] 3 tests from MaterialTest
[ RUN      ] MaterialTest.Init
/builddir/build/BUILD/ignition-math-6.9.2/src/Material_TEST.cc:52: Failure
Expected: (mats.find(static_cast<MaterialType>(i))->second.Density()) > (0.0), actual: 0 vs 0
/builddir/build/BUILD/ignition-math-6.9.2/src/Material_TEST.cc:52: Failure
Expected: (mats.find(static_cast<MaterialType>(i))->second.Density()) > (0.0), actual: 0 vs 0
/builddir/build/BUILD/ignition-math-6.9.2/src/Material_TEST.cc:52: Failure
Expected: (mats.find(static_cast<MaterialType>(i))->second.Density()) > (0.0), actual: 0 vs 0
/builddir/build/BUILD/ignition-math-6.9.2/src/Material_TEST.cc:52: Failure
Expected: (mats.find(static_cast<MaterialType>(i))->second.Density()) > (0.0), actual: 0 vs 0
[  FAILED  ] MaterialTest.Init (0 ms)
[ RUN      ] MaterialTest.Comparison
[       OK ] MaterialTest.Comparison (0 ms)
[ RUN      ] MaterialTest.Accessors
/builddir/build/BUILD/ignition-math-6.9.2/src/Material_TEST.cc:95: Failure
Expected equality of these values:
  2700.0
    Which is: 2700
  mat.Density()
    Which is: 3.1620201333839779e-322
/builddir/build/BUILD/ignition-math-6.9.2/src/Material_TEST.cc:123: Failure
Expected equality of these values:
  MaterialType::TUNGSTEN
    Which is: 4-byte object <0C-00 00-00>
  material.Type()
    Which is: 4-byte object <00-00 00-00>
/builddir/build/BUILD/ignition-math-6.9.2/src/Material_TEST.cc:124: Failure
Expected equality of these values:
  19300.0
    Which is: 19300
  material.Density()
    Which is: 6.924653541527823e-310
/builddir/build/BUILD/ignition-math-6.9.2/src/Material_TEST.cc:136: Failure
Expected equality of these values:
  MaterialType::TUNGSTEN
    Which is: 4-byte object <0C-00 00-00>
  material.Type()
    Which is: 4-byte object <00-00 00-00>
/builddir/build/BUILD/ignition-math-6.9.2/src/Material_TEST.cc:137: Failure
Expected equality of these values:
  19300
  material.Density()
    Which is: 6.924653541527823e-310
[  FAILED  ] MaterialTest.Accessors (0 ms)
[----------] 3 tests from MaterialTest (0 ms total)
[----------] Global test environment tear-down
[==========] 3 tests from 1 test case ran. (0 ms total)
[  PASSED  ] 1 test.
[  FAILED  ] 2 tests, listed below:
[  FAILED  ] MaterialTest.Init
[  FAILED  ] MaterialTest.Accessors
 2 FAILED TESTS

I did a little tracing/printing, and the density values for each of the kMaterialData map entries all contain garbage data when the kMaterials map is assembled in src/Material.cc.  I wasn't able to track down the root cause - it could be static initialization issues, or it could be a bug in gcc-12 which was just introduced into the Fedora buildroot.
If I modify the initialization of kMaterialData per this patch, the density values are initialized correctly.

FYI recently https://github.com/ignitionrobotics/ign-math/pull/290 fixed this issue (with respect to the Material map), for the main branch.

Thanks, I probably should have noticed that PR in the thread above...  I'm working on ign-math6 because gazebo-11 seems to be version locked to it, so I'll continue building the fedora package with my linked patch.  Feel free to pull it into ign-math6 if other distros start to have issues.

I see some new instances of potentially unsafe constant initialization in #388, #390, and #393. They almost follow the pattern of #283 but are not constexpr. Perhaps for these new classes, it would be better to define the static variables inside of a const method rather than as static member variables?

I believe this was fixed by #283 and #290

There are still some constructor+destructor fiascos:
./include/gz/math/graph/Vertex.hh:57:    public: static Vertex<V> NullVertex;
./include/gz/math/graph/Edge.hh:208:    public: static UndirectedEdge<E> NullEdge;
./include/gz/math/graph/Edge.hh:271:    public: static DirectedEdge<E> NullEdge;

There are still some destructor-only fiascos.  Hopefully the compiler optimizes it away, but I don't think its guaranteed:
./include/gz/math/Line2.hh:183:        static math::Vector2<T> ignore;
./include/gz/math/Line3.hh:266:        static math::Vector3<T> ignore;

Thanks. I'll reopen it since we'll be bumping the major version of gz-math soon. It would be good to fix these then.

#606 has been reverted due to test failures in gz-sim


Update Calculator folder

Update README.md in Calculator Folder

Cool, go on with it.

Is this done?

I created PR please have a look


How to use cssnano in this loader?

Hello. I'm new in webpack. Could you describe how to use cssnano in this loader? Where is minimize option?
Is this possible to make use of queries to setup most common options like compression?
Thanks

Just add a cssnext entry to your config like in the README and use this option http://cssnext.io/usage/#compress

cssnext: {
    minimize: true
  },

so? It didn't help for me

Do you even read my previous message? Its COMPRESS


Ability to halt testing and wait for developer to come up at the very point of exception handler

We have huge amount of tests running in azure devops. We are using C#, C++ and C++/cli and test applications are mostly written in C#.
Some of tests are flaky, so they persists with some probability - for example 20%.
This basically means that test works 4 times out of 5.
It takes time to run tests, so it could be so that reaching of problematic point could take 1-4 minutes.
Trying to reproduce a problem would mean to run same tests 5 times which expands waiting time to 5-20 minutes.
If you attach a debugger - there is also a possibility that execution of tests will slow down just enough, so that problem will not be reproducible after this.
vstest.console.exe could have some additional command line argument to halt the execution if any of tests fail.
Moreover to this - develop should be able to stop at exception point, not in catch block, so it's possible that test host application could override AppDomain.CurrentDomain.FirstChanceException or similar to catch exception before it occurs.

Brief analysis of vstest.console.exe functionality versus azure devops tells me that it's possible also to create a custom command line executable and fully override vstest.console.exe behavior. This can be done by responding to /ListFullyQualifiedTests and similar kind of command line arguments from here:
https://github.com/microsoft/azure-pipelines-tasks/blob/master/Tasks/VsTestV2/vstest.ts#L330
To be able to list tests in assembly.
And to respond to plain test execution, for example:
vstest.console mydll.dll /logger:trx.
Used by azure devops  - command line:
https://github.com/microsoft/azure-pipelines-tasks/blob/master/Tasks/VsTestV2/vstest.ts#L155
Used by azure devops  - usage of trx to publish the results:
https://github.com/microsoft/azure-pipelines-tasks/blob/master/Tasks/VsTestV2/vstest.ts#L638
Test console should be able to generate trx xml file, for which it's possible for example to reuse functionality from trx2unit tool (MIT license), https://github.com/gfoidl/trx2junit/blob/master/source/trx2junit/Internal/junit2trx/TrxTestResultXmlBuilder.cs
Self made test host executable or test runner is of course one alternative as such. Please let me know if anyone will try something like this.

Meanwhile - would it be possible for vstest platform to provide this functionality as built-in in vstest.console.exe ?
I think if necessary this ticket could be splitted into two - one for C# support, another for C++ support. But it's important to assume that test application can be in C#, but invokes C++ code, and vice versa - C++ code, but invoking C#.
All 3 types of libraries could be used - native C++ dll, mixed mode C++/cli dll, managed C# dll.

So would this work roughly?
$> vstest.console tests.dll --wait-for-debugger-on-exception

Running tests....
test1 Passed
test2 Passed
Attach debugger to process testhost (19723)...

I am not sure we'd be able to do that in all code. But if you are willing to PR it we can help you get that to work.

This could be good starting point at least. What means "willing to PR" ?

Here is a prototype how you could possibly modify your tests to attach a debugger in VS when something fails. But it requires changes to your test code and does not work for just any exception. https://github.com/nohwnd/vstest-examples/tree/main/attach-debugger-to-vs
But other than that there is not a good way to do this. VS can stop at exception because it attaches a debugger. Without debugger we cannot peek into the code. And implementing the debugger would just duplicate what you can do in VS natively.
I think the best way for you is to use the standard tools to debug flaky issues. As adding a better logging, or triggering a dump on failure.


Learn MERN tech stack for development

All team members must learn the MERN tech stack, as this is what we will be using for development.
Here are some helpful videos:
Tutorial Playlist:
https://www.youtube.com/playlist?list=PL4cUxeGkcC9iJ_KkrkBZWZRHVwnzLIoUE
Complete Guide:
https://youtu.be/4nKWREmCvsE?si=unjqXTeR3uelRIGN
This issue will be closed when all members verify that they understand MERN.

All team members have completed and uploaded projects used to learn MERN.


CLI Unit tests could cover more (all?) CLI options

Hi,
Issue 1325 highlighted that a bug introduced in PR 1310  could have been easily caught with a more comprehensive CLI unit test. We have CLI unit tests, but don't cover all the options - just one column validation CLI test.
Let us make a CLI unit test will the documented options.
Thanks.
Sundar Mudupalli

i'd like to do this
may you assign me?

Hi @safe049, assignment done! Thank you for you collaboration!


Minor debugger (and other) cleanups

Summary of changes:

Debugger cleanups for callstack level changes, add ability to test callstack level using JSON proxy
Debugger cleanups for Detaching notify
String hash declaration warning fix (declared but not defined when dense string hash not in used)
-Wcast-qual fix for duk_debug_fixedbuffer.c
Releases entry for Detaching notify

Tasks:

[ ] Review changes
[ ] Decide whether to implement callstack level support into debugger web UI in this pull

For the Detaching message, would it be better to have a string description as specified in the doc right now, or just have multiple reason codes?  A reason code would be easier to parse for the client, and could easily be converted to a localized error string by the client.

Do you mean adding a second reason code in addition to the existing one (and maybe renaming the existing "reason" field to "isError"?). Or adding more reason codes to the existing field?
With respect to the message, my hunch would be to use a string message for details, similarly to how thrown errors work in Ecmascript. There are quite many error sources so that updating an enumeration might be tedious (and often in such situations people, me included, tend to map slightly different errors to existing enumeration values to avoid adding a new code ;-).
Further, I can see the debugger code going inside a setjmp catch point later on, and at that point the easiest approach would be to handle an error by detaching and converting the error thrown (an internal error) into a string for the detach reason. Converting a thrown error to an enumeration isn't currently possible because errors don't carry a numeric reason or other programmatic information to distinguish errors reliably.

All that said, what level of detail were you thinking of for a detach reason?

I just meant to expand the existing "is_error" field to an enumeration - 0 for orderly detach, nonzero for error cases.  Code that just needs to know whether it's an error doesn't have to change this way - just compare against zero.
I guess we could leave the string message in with this setup as well.

Hmm, but it's already specified as a "reason" field right now?
Format::

    NFY <int: 6> <int: reason> [<str: msg>] EOM

Example::

    NFY 6 1 "error parsing dvalue" EOM

Reason is one of:

* 0x00: normal detach

* 0x01: detaching due to stream error

I thought it was intended to be open ended already :)

The code uses "is_err" though, so maybe rename that internally to "reason" too to make it clearer it maps directly to this detach reason field.

Haha, I guess I already had that in mind when I wrote the docs then.  So it's just some code trivia then, that's easy to fix.

Yeah I think we changed the field at least once. I'll change the macro argument naming to match.

While you're at it you also might want to change the reason code type to duk_int_t (it's currently a bool).


update to use custom JWT email claim

updating claims inserted into JWT for for secure requests using google service credentials.
connects to https://github.com/HumanCellAtlas/data-store/pull/1562

I agree


Blazor: No .NET call dispatcher has been set

Describe the bug
When creating a Blazor server-side app, it is not possible to call DotNet.invokeMethodAsync from HTML JavaScript.
To Reproduce
1: Create a new server-side Blazor app called BlazorApp7.
2: Add the following class
public static class SomeCallback
{
	public static string Status = "Failed";
	[JSInvokable("SayHello")]
	public static void SayHello() => Status = "Called";
}

3: Edit Pages/_Host.cshtml, and below <script src="_framework/blazor.server.js"></script> add the following script
<script>
	(function () {
		if (window.DotNet) {
			console.log("window.DotNet is set");
			if (window.DotNet.invokeMethodAsync) {
				console.log("window.DotNet.invokeMethodAsync is set");
				window.DotNet.invokeMethodAsync("BlazorApp7", "SayHello");
			}
		}
	})();
</script>

Expected behaviour
As window.DotNet is not null, I expect the script to successfully execute the C# in the callback.
Actual behaviour
An exception is thrown "No .NET call dispatcher has been set"
By the time blazor.server.js has executed, window.DotNet has been set but using it will cause the above exception.
This is preventing any start-up script from executing C# code.
The only solution to this at the moment is to use setTimeout, but this results in a laggy user experience when starting up the app (100ms delay succeeded, 50ms failed).
This problem happens when RenderMode is either Server or ServerPrerendered.

This issue may be helping #14011

@mrpmorris Thanks for contacting us.
@soeleman Is right. I would follow the same guidance I provided in here. https://github.com/aspnet/AspNetCore/issues/14011#issuecomment-534757093
It is likely Blazor is not yet fully initialized when you try to call into .NET. Instead of doing what you are doing, check the snippet for manually initializing Blazor.
It returns a promise, so you can chain a then call after it and perform the interop call at the time.
<script src="_framework/blazor.server.js" autostart="false"></script>
    <script>
        function start() {
            Blazor.start({ })
                .then(() => {...});
        }
    </script>

If that doesn't help, feel free to reopen this issue.

@javiercn
I have this
	<script src="~/index.js"></script>
	<script src="_framework/blazor.server.js" autostart="false"></script>

and in index.js I have this
alert('x');
if (window.Blazor) {
	alert('1');
	window.Blazor.start({})
		.then(() => { alert('z'); });
}
alert('y');

I only see alerts X and Y.


Ghost content directory write error deploying with now

Issue Summary
Ghost throws an error when deploying with now.
ERROR: Unable to access Ghost's content path
EACCES: permission denied, open '/home/nowuser/src/content/apps/17e84fd4f8afb461'
Error [Error: Command node index ended with code 235]

Steps to Reproduce

Download a fresh copy of Ghost and cd to directory
Install now with npm install -g now
Deploy with now

See example deploy: https://ghost-wmpodxshwt.now.sh/
This is expected as core/server/utils/startup-test.js tries to write a random file to each subdirectory within the content directory to make sure it has write access.
The now server is not persistent (like heroku), and does not allow write access to any directory apart from /tmp.
As now suggest using external services for writing to file, and Ghost supports using services such as RDS and S3 for storing content, I can't see a reason to force the content directory to be writable (unless I'm missing something?).
I'd suggest adding a config variable contentWritable, that can be set to false if the deploy is using external services to write all content. The content directory writable test will run in core/server/utils/startup-test.js unless contentWritable is set to false. I will add a PR for this behaviour.
Technical details:

Ghost Version: 0.10.1
Node Version: 4.4.5
Browser/OS: OSX
Database: sqlite

@colinmeinke quick question: has deployment using this method worked in the past?
The reason I'm asking is those content path checks were added 2 years ago - and haven't changed since then afaik. There could have been some things that changed in a different place for the theme upload/download feature that broke it somewhere else, but it's unlikely.
The changes you're suggesting sound like a good start - will leave this open though for further review.
/cc @ErisDS

Now is really new, and I've never tried deploying Ghost to it before. From searching their slack channel I'm the only one mentioning Ghost, so I assume nobody else has tried either. It will have never worked if these checks have been around for some time. PR coming right up!

This check is required, and will be until all file writes use storage adapters. Only image files currently use a storage adapter. Other files such as database backups, logs etc. are still written locally. Until a time when we can guarantee no files will be written to the content directory, and the content directory writable check can be turned off, Ghost will not work with now.

Going to close this for now with the same reason as I closed the PR: https://github.com/TryGhost/Ghost/pull/7360 - it's not a bug, but rather there's a larger refactor needed to make anything like this possible.


ActionLogger feature: option to run save of report async

Closed because we don't want the last commits, new branch hotfix/v0.6.9-forMerge for the PR


Updated the SSL certificate change as described in the documentation due to the error "Error: self-signed certificate in certificate chain".

I suggest changing the SSL certificate listed in the documentation from BaltimoreCyberTrustRoot.crt.pem to DigiCertGlobalRootCA.crt.pem
I have tried to connect to Azure Database for MySQL from Node.js according to the following documentation.
https://learn.microsoft.com/ja-jp/azure/mysql/single-server/connect-nodejs
However, I got an error Error: self-signed certificate in certificate chain and could not connect to the database.
Error: self-signed certificate in certificate chain
    at TLSSocket.<anonymous> (/Users/XXX/node_modules/mysql/lib/Connection.js:317:48)
    at TLSSocket.emit (node:events:513:28)
    at TLSSocket._finishInit (node:_tls_wrap:959:8)
    at TLSWrap.ssl.onhandshakedone (node:_tls_wrap:743:12)

I haven't been able to track down the exact cause, but the SSL certificate I downloaded from the Azure Portal "Azure Database for MySQL flexible server -> Networking -> Download SSL Certificate" was DigiCertGlobalRootCA.crt, so I believe this is the correct one.

@savjani
Can you review the proposed changes?
When the changes are ready for publication, add a #sign-off comment to signal that the PR is ready for the review team to merge.
#label:"aq-pr-triaged"
@MicrosoftDocs/public-repo-pr-review-team

#reassign:@code-sidd

#reassign: @code-sidd

Remove the reviewer savjani
i have already approved it to proceed


add serialization support

Hey @jbn! How have you been? Finally got around to this. Tried to keep it simple, I'm flexible on all the design decisions here, just needed a way to write CAR. Lmk what you think!

i'll look this weekend. new startup, way less sidequest time.
(also, if you are interested, i'd transfer github/pypi ownership to you. i've seen you around over the years enough to know you're a good steward for projects like this. obv only if you want though)

Hey, thanks, and no worries! I know how it is.
I don't expect a lot more changes, but I'm happy to take the repo and pypi package if you think it needs more maintenance work than you have bandwidth for. Up to you, I'm ok either way!

I think transferring to you is the right move. Maintenance or extension,   you'll be a better lead than me on this. LMK your pypi name so I can add you as the collaborator to affect a transfer. (DM on discord fine if you don't want to post it for whatever reason.)

Sure! Sounds good. I'm snarfed on pypi.
If you have the time, I'd love your eyes on this change either way! I'm not overly worried about it, but I expect you've spent more time in CAR land than me.

I will!
Heading out now but will take a look and also transfer in AM

LGTM. Def will be a nice feature to have!

pypi owner invite sent

Thanks man!

Thanks for continuing to make bsky cool!
(Also tried to transfer ownership but couldn't because you had a fork and github didn't think about that edge case. Did send collaborator request then I assume it gets easier?)

Hah, funny. I just deleted my fork, nothing else important there, feel free to retry.


feat: release fd

Signed-off-by: Gaius<EMAIL_ADDRESS>
Description

Release fd.
Update submodule.

Related Issue

Motivation and Context

Screenshots (if appropriate):
Types of changes

[x] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to change)
[ ] Documentation Update (if none of the other choices apply)

Checklist:

[x] Code compiles correctly.
[x] My code follows the code style of this project.
[ ] My change requires a change to the documentation.
[ ] I have updated the documentation accordingly.
[x] I have read the CONTRIBUTING document.
[x] I have added tests to cover my changes.
[x] All new and existing tests passed.

Codecov Report

Merging #668 (c49ce5c) into main (c78076b) will increase coverage by 0.11%.
The diff coverage is 0.00%.

@@            Coverage Diff             @@
##             main     #668      +/-   ##
==========================================
+ Coverage   38.61%   38.73%   +0.11%
==========================================
  Files          88       88
  Lines        6976     6979       +3
==========================================
+ Hits         2694     2703       +9
+ Misses       3901     3895       -6
  Partials      381      381

Flag
Coverage Δ

Object-compatibility-e2etests
?

e2etests
?

unittests
38.73% <0.00%> (+0.11%)
:arrow_up:

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files
Coverage Δ

client/daemon/storage/local_storage.go
31.01% <0.00%> (-0.44%)
:arrow_down:

client/daemon/peer/peertask_base.go
34.89% <0.00%> (+1.83%)
:arrow_up:


Fix GitHub action

Fix GitHub action
Description

Category: chore
JIRA issue: none
Research reference: none

Changes and notes
Probably everyone just turns off their email notifications, but this was slightly bothering me. Also, the fact that black and isort hadn't run in a while meant I kept getting extraneous changes in my other branches when I ran them.
The only slightly controversial change here is a very small amount of code duplication from vivarium_cluster_tools to avoid needing that at runtime of the sim. I think this would need to be done anyway if we want the archival version to be runnable by an external person without installing vivarium_cluster_tools.
Verification and Testing
Made sure simulation still runs to completion, including saving results. Tests are passing, obviously 😄

There is actually already a jira ticket for this which was planned for the upcoming sprint: https://jira.ihme.washington.edu/browse/MIC-3660. I've assigned it to you and moved into ready for review


[jts] Remove null data type

Not clear what null data type is for - when would you have a field that was always null and even if you did why not just set it as string and let it always be null.

Agree. I think that null is in fact a value and not a datatype at all, no?

What was the reason we had it in the first place?

@pwalsh I do not know ;-)

I had the same question - https://github.com/dataprotocols/dataprotocols/issues/257


[WIP] Scalafmt

Alright everyone, bikeshed away!  The configuration is in .scalafmt.conf.  Poke around with your favorite files and see how they've been violated.
The exact infrastructure here is being provided by neo-scalafmt, but it is compatible with the various scalafmt incarnations (including the command line tool).  Format on compile is disabled, for reasons discussed in Slack.  Instead, we have a test that things are correctly formatted included in the CI build script, so we will fail-fast on the build if the formatting is not applied.  To apply formatting, use the scalafmt or the test:scalafmt task within SBT. just run the format alias within SBT.
If there is something that really needs to be formatted in a certain way (the parser is a good example) in violation of the rules, then you can do this by using // format: off and // format: on around the code block which you want to manually format.  Just be sure that the indentation of these two comments is the same, otherwise scalafmt will get confused.
Another thing disabled is formatting of .sbt files.  I don't really find the feature to be all that useful, but we could turn it on if desired.
This branch isn't going to land until after next-major does, so I haven't assigned a reviewer.  Enjoy!

As a side note, it looks like there are some bugs in scalafmt (or possibly neo-scalafmt) regarding the formatting tests.  We may have to fiddle with the files in question a bit to get around these issues.

Alright, I removed the "newline before top level definitions" bit and reapplied the formatting (also rebased on top of master).  Additionally, I've added an alias command to sbt, format, which formats both test and main files.

Ok, I reapplied the formatting with newlines.sometimesBeforeColonInMethodReturnType = true and max line width set to 96.

I'm guessing scalafmt is just subtly trying to encourage us to rewrite this code:
  def javascript[T[_[_]]: BirecursiveT: ShowT, M[_]: Applicative](
      implicit merr: MonadError_[M, FileSystemError]): AlgebraM[M, MapFunc[T, ?], JsCore] = {
    import jscore.{
      Add => _,
      In => _,
      Lt => _,
      Lte => _,
      Gt => _,
      Gte => _,
      Eq => _,
      Neq => _,
      And => _,
      Or => _,
      Not => _,
      _
    }

And there's this oddity of just )( on a line that @alissapajer already pointed out:
  def runF[S[_]](
      c: MongoClient
  )(
      implicit
      S0: Task :<: S,
      S1: PhysErr :<: S): Free[S, A] = {
    val mongoErr = Failure.Ops[PhysicalError, S]
    mongoErr.unattempt(free.lift(attemptMongo.run.run(c)).into[S])
  }

Generally looks fine to me.

Currently blocked on finding a workaround for https://github.com/scalameta/scalafmt/issues/1055

Ok, this is getting closer to reality.  Don't want to do anything until after we deliver 4.3, since there will be some disruption, but I think we're ready for a final-pass review and 👍 / 👎
For the record, when this gets applied, basically all outstanding local work is going to get conflicted.  The solution to this will be to cherry-pick the configuration commit and then double-apply scalafmt to the entire local state.  Then, merge with master.  There really isn't a way to make it work with rebasing.

I give :+1:.

@beckyconning this PR was the initial discussion about having automatic code formatting. We had put this off while working on 5.0, but moving forward I'd like to see this prioritized. @djspiewak did the initial work and so could say the effort level to finish this.

The biggest issue I see with landing it is how slow scalafmt is. :-( I keep thinking through how the workflow is going to be, and I can’t come up with good answers. I guess formatting before each commit? I want the standardized auto formatting as well, it just seems like the cost is going to be pretty high.

@djspiewak for quasar, how long does it take to run the formatting once manually locally? We could run it not on every commit but just once for each PR. Personally, given how I rebase before PRing, requiring each commit formatted would be really annoying.
I do agree overall though that if we agree the overhead is too high, we shouldn't land this.

@alissapajer Reformatting all of quasar takes about 3 minutes, if memory serves, starting from master state.  Running the formatter on all of quasar in the case that no files need to be reformatted (and the JVM is already warm) takes 17 seconds.  Some files are still structured such that the reformatting is O(k^n), a problem which can be fixed by not abusing Scala in some specific ways (breaking out subexpressions into vals fixes it almost every time; the issue is usually generated by huge blobs of multi-line function invocations with nested function calls and expressions).

Hm, that's right on the edge. I'd be happy to try landing this, and if the overhead turns out to be too high, disable it.
Thoughts from others?

Closing as we'll open a new PR if we decide to do this. Discussion can continue on the issue qz-3340.


Changes to fix the group sync of OpenLDAP

https://github.com/rancher/rancher/issues/3875
https://github.com/rancher/rancher/issues/5629
Added two new properties to be configured in openldapconfig:
groupDNField
groupMemberUserAttribute
These are for admins to set the appropriate fields so that lookup of user's groups works fine.

about the TFS:
v1 - mysql - failed due to "ClientApiError: Scheduling failed: No healthy hosts with sufficient resources available" - unrelated to the PR
v1 - pgsql - Internal error:
java.lang.NullPointerException: null
at io.cattle.platform.configitem.context.impl.LoadBalancerInfoFactory.populateContext(LoadBalancerInfoFactory.java:116) ~[cattle-config-item-server-0.5.0-SNAPSHOT.jar:na
v2- mysql - ERROR i.c.p.a.sources.LazyJDBCSource - Failed to get connection to database, will retry for 5 minutes - also failed to schedule instances
All above are not related to the PR

@ibuildthecloud @alena1108 @deniseschannon can you merge this one - it is a customer issue and the customer is ready to test it out as soon as the fix is available in the RC

@prachidamle do we do integration tests for auth components? or is it covered by validation?

@alena1108 there are no integration tests for auth components other than schema validation - test_openldap_auth changed here for this fix

@alena1108 addressed your review comments


Samples should not override what spring-boot-starter-parent provides by default

The samples extends from spring-boot-starter-parent to (I suppose) reproduces what would happen with a blank app generated from start.spring.io.
If that's the intend, they shouldn't have override of maven plugin versions and dedicated pluginsManagement.  IMO, this is a bit confusing because the first objective is clearly not achieved so it's not obvious why they inherit from starter-parent. Not doing that would move the checkstyle and findbugs config in the parent, making the sample more succinct and easier to apprehend.

Yes, the intention is to reproduce users' behavior. Earlier all the samples inherited from starter-parent, which saved all the checkstyle and findbugs config. But I think it's more important to consider users' behavior.


Add Project reference for UWP to GoogleMaps.UWP

Added Project Reference for UWP sample to GoogleMaps.UWP. Also changed configuration settings for Android and UWP to deploy

You should not contains Android project file changes.
Because this PR's context is "UWP" project.
Changes should be "atomic" as also @atsushieno said.

I will undo the android project file changes and commit

To be honest, I still don't really know what I'm doing. All the code is there. but Github is so difficult to use compared to TFS

Try to use git extensions as git client

I'm using SourceTree which is best git client for Mac/Windows.
I'll close this PR.
I think you had better retry fork and create branch.
Don't worry, you can try again and again. 👍

My Project wont let me undo those changes to the Android project. Every time I undo it just comes straight back. It must be something on my computer changing it from 6 to 7

If you use Visual Studio git extension or TFS then you had better disable it.
Because I think VS or TFS git extensions are not for beginners.
Alternatively, you can use more better git clients listed bellows:

GitHub Desktop - Simple collaboration from your desktop
SourceTree - A free Git & Mercurial client for Windows or Mac | Atlassian
Or git command line interface

First, You should be careful to which files to commit. You should make only one commit per one reason.
Visual Studio often changes to project/solution and some auto generated files automaticaly.
But these are unrelated for your purpose.
So you should not contains these files to your commit.
Next, You should be careful to not contains unintended file changes before push operation. Push operation can not undo.

If you dont know how to do it create pull request to my branche https://github.com/deextercz/Xamarin.Forms.GoogleMaps/tree/to_merge and I will modify this and create new one to amay0777 repository

@deextercz Have submitted a pull request to your branch. If that works, I will do a similar thing with the rest of my pull requests. Sorry for making such a mess of it

I am using Visual Studio Git extensions. I think perhaps the functionality is very limited. This may be why it is causing so much pain in excluding files from commits.


Can I use tensorrt-llm depoly qwen1.5?

this may you need link

I think Qwen1.5 model architecture is same as llama. Have you tried it.

For TRTLLM-0.9.0, you can refer to https://github.com/Franc-Z/QWen1.5_TensorRT-LLM


callback

Hi, how to use loguru callback function?
i am trying to send error message to another thread.
to use it, i tried to use event queue from mbed-events library.
it seems work fine.
https://github.com/ARMmbed/mbed-events

without "EventQueue" and only with loguru,
how do i use the function?
i just wonder that whether loguru support the functionality or not.

I'm not sure I follow what you're actually asking about.
Loguru invokes the callback in the thread that performs the log_message call. It's up to you to write logic in this synchronous callback to communicate information to some other thread of yours.
Could you please explain what functionality it is you're looking for that could be built into Loguru? What problem are you trying to solve with this?

it would be good if loguru support eventqueue,
i need some callback functionality which take care of getting error messages,
and back to user application.
now i have implemented simple function using mbed-events library,
what i try to say is one tool is enough, two is too much.

as of the result, my use case is like below:
if(error)
{
#if DEBUG
  LOG_ERROR("error message\n");
#else
  function(...);
#endif
}

I understand your desire for an easy way to collect log messages in a queue, but I feel this is outside the scope of Loguru. As @zao pointed out you can rather easily use the log callback functionality in loguru to collect messages and process them as you want.
I prefer making Loguru a library that allows for easy "gluing" like this, rather than one which comes pre-glued with big dependencies.
Or in other words: Loguru's aim is to be a lightweight logging library, not a framework for processing logging messages.


Feat: To Implement the Google Translate Functionality in multiple languages.

Describe the feature
Issue Description:
We need to implement the Google Translate functionality to enable translation across multiple languages on our platform. This will involve using the google-translate-container and the Google Translate gadget to provide a seamless translation experience for users.
Tasks:
Integrate Google Translate Gadget:
Embed the Google Translate gadget within the google-translate-container to provide language translation options for users.
Customize Appearance:
Use Tailwind CSS (or relevant styling frameworks) to customize the visual appearance of the google-translate-container, ensuring it matches the overall design of the application.
Language Support:
Ensure that the gadget supports all target languages as specified.
Test functionality across multiple languages to verify that translations are accurate and the switch between languages is smooth.
Responsive Design:
Ensure that the translation functionality works effectively across different screen sizes (mobile, tablet, and desktop).
Expected Outcome:
Users should be able to select their desired language from the google-translate-container.
The page content should be translated to the chosen language without disrupting the user experience.
The design and layout should remain consistent with the rest of the application.
Add ScreenShots
I want to implement this feature later I will attach some screernshot
Record

[X] I agree to follow this project's Code of Conduct
[X] I'm GSSOC'24 Extd registered Contributor
[X] I'm Hacktoberfest registered Contributor
[X] I want to work on this issue

I have implemented it in some other project

Can we connect on Linkedin so that I can share you how it'll work

You can share the link here or share photos and screenshots
https://www.linkedin.com/in/vanshchaurasiya24

Updated to #21 for FutureScope
Thanks for the idea ✅


Temporary workaround for IBM-Swift/Kitura#1034

Description
This PR introduces an unused variable as the first field of IncomingSocketHandler.  It is a temporary workaround for a rare crash under load while we continue to investigate the issue.
Motivation and Context
This change appears to prevent the second crash detailed in IBM-Swift/Kitura#1034 from occurring.  I believe that the crash is caused by corruption of an IncomingSocketHandler instance, possibly as consequence of a concurrency problem.  Adding a 'sacrificial' field that is not an Object (and thus not retained / released) seems to be sufficient to avoid this crash and has not (in the testing I have done) introduced any further consequences.
How Has This Been Tested?
I ran the 'HelloMiddleware' benchmark a number of times.  It crashes around 5/6ths of the time without this change.  With it, I have not yet seen a crash.

Codecov Report

Merging #211 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master     #211   +/-   ##
=======================================
  Coverage   73.81%   73.81%
=======================================
  Files          30       30
  Lines        4082     4082
=======================================
  Hits         3013     3013
  Misses       1069     1069

Flag
Coverage Δ

#CHTTPParser
56.04% <ø> (ø)
:arrow_up:

#KituraNet
73.81% <ø> (ø)
:arrow_up:

Impacted Files
Coverage Δ

Sources/KituraNet/IncomingSocketHandler.swift
76.99% <ø> (ø)
:arrow_up:

Continue to review full report at Codecov.

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


Allow del key to easily delete items

It would be convenient if you could delete items as easy as you could add them.

Addressed in https://github.com/trompamusic/mei-friend/commit/15eb3ecff5253470580c91a125ac555d3da7a003 for control elements, clef, accid, and artic; the latter two only if encoded as elements.
Currently both BACKSPACE and DELETE work. Any preference for these?

I like both, so I don't mind. Leave it like that until the next one complains.


Charging_Processes table incomplete

Only start_date, car_id, position_id and address_id are being populated in charging_processes. Everything else is left null.
The charges table seems to be populating fully.
I've only started using this but the 3 entries populated so far in charging_processes have the same incomplete entries.

What are the logs showing during that period. Are there any errors?

This is from just now:
07:39:29.933 [info] Start / :asleep
09:33:10.931 [info] Start / :online
09:33:10.939 [info] Charging / 0.0h left
09:33:32.829 [info] Charging / Restart
09:51:19.626 [info] Charging / Complete
The entry for that in the psql database shows:
"5"	"2019-07-29 09:33:11"										"1"	"330"	"1"

I wonder why Charging / Restart happened soon after the charging process started. A few questions:

Do all charging processes show that pattern?
Was there anything special about that particular charging process (e.g. charge limit exceeded)?
Are there any successfully logged charging processes?

No, Not all charging follows that routine. This is what I have from the logs:

07:03:11.172 [info] Charging / 0.0h left
09:33:10.939 [info] Charging / 0.0h left
09:33:32.829 [info] Charging / Restart
09:51:19.626 [info] Charging / Complete
11:28:07.824 [info] Charging / 0.0h left
15:41:10.281 [info] Charging / 0.0h left
15:41:48.466 [info] Charging / Disconnected / 0.0 kWh – 0 min

In fact, the last charging even did actually write correctly to the psql database, however it wasn't a real charging event. I just unplugged at that point and it showed 0kwh added. However at least it worked that time. I'll charge again tonight to see what happens.

What's the logic behind when the service will check the state of the car? I set my car up to charge starting at midnight to take advantage of electric rates. Could the car going from full asleep / offline mode to charging cause a hiccup with capturing the charge?

Could the car going from full asleep / offline mode to charging cause a hiccup with capturing the charge?

Okay, yes, that could cause the problem. Also, I think those long charging sessions are an issue right now. I will look into it.

This is very strange. From last night's charge:
03:09:44.902 [info] Start / :asleep 07:00:35.606 [info] Start / :online 07:00:35.618 [info] Charging / 1.83h left 08:41:39.202 [info] Charging / Complete 08:56:49.508 [info] Suspending logging 09:17:59.881 [info] Start / :asleep
Looks like it should've caught it all and worked fine, yet it's another mostly empty entry in the charging_process table.

Okay, so this is actually intended: the API reports Charging / Complete if the charge limit is reached. Only if you stop charging or unplug the charging process will be considered finished.
However, if another Charging / Restart should show up while the car is charging that would be a bug.

Really? Why not consider it complete if the car says the charging is complete?
I just unplugged my charging cable to see what would happen.

16:10:10.924 [warn] Error / :unknown
16:33:44.372 [info] Start / :online

The entry in charging_process still shows mostly nulls.

Well, we could do that but if the car charges for a longer period e.g. over night Complete does not mean the charging process is actually finished. Every hour or so it will start charging again for a few minutes. Each one of those charging processes would then be logged separately.

The entry in charging_process still shows mostly nulls.

Okay, this is really strange. Since there was a charging process in progress it should have been completed. Does your car have a stable internet connection when parked?

Well, we could do that but if the car charges for a longer period e.g. over night Complete does not mean the charging process is actually finished. Every hour or so it will start charging again for a few minutes. Each one of those charging processes would then be logged separately.

Could you skip writing to the charging_process if the total wh added was less than a certain threshold? Or ignore a charging start if the remaining time is 0.0h? Am I the only one seeing this issue? My typical use of charging is plug it in when I get home. It'll charge at midnight until it's done and leave it plugged in until I leave. I'd have to imagine that isn't unusual use.

Okay, this is really strange. Since there was a charging process in progress it should have been completed. Does your car have a stable internet connection when parked?

Yes, excellent network connection as my primary router is in the room over my garage. 200mbit+ speed tested from inside the car.

Could you skip writing to the charging_process if the total wh added was less than a certain threshold? Or ignore a charging start if the remaining time is 0.0h? Am I the only one seeing this issue? My typical use of charging is plug it in when I get home. It'll charge at midnight until it's done and leave it plugged in until I leave. I'd have to imagine that isn't unusual use.

The downside to this is that the consumption (gross) calculation would then produce slightly wrong results. Let's take a step back – is that really the issue here? To me it looks more like there is this bug you described earlier: when the car is going from asleep / offline mode to charging it somehow does not continue with the charging process and creates a new one instead.
I don't think you're the only one seeing this issue. I just did not run in this bug because in the past I mostly unplugged right after charging.

What I mentioned before was meant to be something like this:

Arrive home after work and plug in, say around 7pm
Car goes to sleep around 7:30pm
Car wakes up and immediately starts charging at 12:00am
Car finishes charging at 2am
Car goes back to sleep at 2:30am
I wake the car up at 9am, unplug, go to work.

Are you suggesting that charging should be recorded as starting from 7pm and ending at 9am the next morning in that scenario? Even though it was only actively charging from 12am to 2am? I'm not sure I understand the goal of capturing how long it was plugged in but not charging?

Sort of ... in general I would prefer matching the reported state of the API. Based on your example:

7pm: either start a charging process or stay in online mode (I don't know yet what the API reports if charging is delayed)
7:30pm: car goes to sleep
12:00am: (start a charging process if that did not already happen earlier and) start writing data  referencing the charging process into the table charges
2am: stop writing data into the table charges since charging_state is Complete
2:30am: car goes back to sleep
2:30am - 9:00am: if the car wakes up in between to charge a few Wh write data referencing the charging process into the table charges
9:00am: finish charging process

There are a few unknowns for me: what happens at 7am and after 2:30am. Depending on that I would prefer recording from 7pm and ending at 9am or from 12am and ending at 2:30am.
Sorry for not fixing it already. I could not yet do a real-world test myself yet.

Hey, no need to apologize. You're donating your time here. :)
I have a Sense monitor hooked up to my house power. It shows energy usage realtime and lets me look at graphs of usage in the past. The Tesla wall charger I use is very easy to detect. 11kw/h load whenever it activates. The charger does click on on occasion while connected but no significant load shown when it does.
If you'd like some help debugging this, let me know. I've got a postman profile setup to query everything manually.

Last night I did a manual charge for 90mins, starting and stopping it via my phone. It showed up perfectly in the charging_process table and chart. Then at midnight the car woke up from sleep, charged the rest of the way and went back to sleep. That entry was missing bits again. Seems like it's definitely scheduled charges that are an issue.

Okay, good to know. Thanks for the info! I'll debug it this weekend.

I could finally test and also reproduce it. The fix will be out tomorrow.

Release v1.4.3 should fix the issue. Let me know how it goes.

Add migration to fix incomplete charging processes

This part definitely worked. The charging table looks like it's repaired. I'll charge after work tonight and report back on the rest but looks good so far! Thank you. 👍

Looks like it worked perfectly! The only thing left that seems amiss is the charge prior to the one last night shows that it took 25 minutes to charge 21kwh giving a charging rate of 50kw/h. That was captured with much older code. I'm thinking you've squashed the bug. :)


[BUG] dockview craches when changing from excalidraw

Describe the bug
When changing focus from a pane containing excalidraw the app crashes. This does not occur when changing between panes where both contain excalidraw.
To Reproduce
https://github.com/antoKeinanen/minimal_example_excalidraw_dockview
Steps to reproduce the behavior:

Create 2 panes

None can contain anything
Other has to contain <Excalidraw/> from @excalidraw/excalidraw

Focus on the page containing excalidraw.
Change the focus to the other pane without excalidraw.
Dockview crashes with logs attached

Logs
[vite] connecting... client.ts:18:8
[vite] connected. client.ts:150:14
Uncaught TypeError: Window.getComputedStyle: Argument 1 is not an object.
    renderScene App.tsx:1365
    componentDidUpdate App.tsx:1290
    React 8
    workLoop scheduler.development.js:266
    flushWork scheduler.development.js:239
    performWorkUntilDeadline scheduler.development.js:533
    js scheduler.development.js:571
    js scheduler.development.js:633
    __require chunk-MYQCFY5U.js:8
    js index.js:6
    __require chunk-MYQCFY5U.js:8
    React 2
    __require chunk-MYQCFY5U.js:8
    js React
    __require chunk-MYQCFY5U.js:8
    js React
    __require chunk-MYQCFY5U.js:8
    <anonymous> react-dom_client.js:37
App.tsx:1365:6
The above error occurred in the <App> component:

App@webpack-internal:///../../components/App.tsx:186:9
InitializeApp@webpack-internal:///../../components/InitializeApp.tsx:24:82
Provider@webpack-internal:///../../../node_modules/jotai/esm/index.js:687:18
ExcalidrawBase@webpack-internal:///./index.tsx:96:464
Excalidraw
excalidraw
ReactComponentBridge@http://localhost:5173/node_modules/.vite/deps/dockview.js?v=d62f2746:6675:36
div
DockviewReact<@http://localhost:5173/node_modules/.vite/deps/dockview.js?v=d62f2746:6955:25
App@http://localhost:5173/src/App.tsx:50:71

Consider adding an error boundary to your tree to customize error handling behavior.
Visit https://reactjs.org/link/error-boundaries to learn more about error boundaries. localhost:5173:2367:25
Uncaught TypeError: Window.getComputedStyle: Argument 1 is not an object.
    renderScene App.tsx:1365
    componentDidUpdate App.tsx:1290
    React 8
    workLoop scheduler.development.js:266
    flushWork scheduler.development.js:239
    performWorkUntilDeadline scheduler.development.js:533
    js scheduler.development.js:571
    js scheduler.development.js:633
    __require chunk-MYQCFY5U.js:8
    js index.js:6
    __require chunk-MYQCFY5U.js:8
    React 2
    __require chunk-MYQCFY5U.js:8
    js React
    __require chunk-MYQCFY5U.js:8
    js React
    __require chunk-MYQCFY5U.js:8
    <anonymous> react-dom_client.js:37
App.tsx:1365:6
[vite] server connection lost. polling for restart... client.ts:105:12

Desktop (please complete the following information):

Browser: Tested on firefox, chrome, and edge.
Version: All latest releases (firefox: 116.0.2, chrome: 115.0.5790.171, edge: 115.0.1901.200)

Additional context
Original repo: https://github.com/SedenionCas/Sedenion/tree/development
Development build of the repo: https://sedenion-git-development-sedenion.vercel.app/

Thanks for the detailed report and demo.
I've ran the demo app and I see the application crash and the error appears to be coming from the excalidraw library as shown in the below screenshots.

Digging into this a bit further it seems the excalidraw error is due to the component trying to access something from the window that doesn't exist.
When you switch tabs in dockview the panel that becomes hidden is removed from the dom but the React component remains active (so that if you was to return to that panel the component would be as left) however this only works if some assumptions are obeyed, one of which being that component doesn't try to access the window because whilst hidden it has been removed from the window and has no access to it.
In this case the excalidraw React component should be destroyed when it's panel is hidden and this can be achieved with a simple wrapper that can be found on the docs website here.
You'll want to then wrap your panel in this RenderWhenVisible wrapper component.
const components = {
  default: () => {
    return
Panel_1
;
  },
  excalidraw: RenderWhenVisible(() => {
    return <Excalidraw />;
  }),
};

If you find that you do not want to destory the component and you want it to remain active even when not visible it may be worth reading how dockview allows you to work with iframes too here since this would allow a particular component to remain attached to the dom even when not visible.

Here is a link to a sandbox based on your example using RenderWhenVisible
https://codesandbox.io/s/excalidraw-render-when-visible-forked-9zvvcn

Thank you this solution worked well. I ended up using it and caching the current canvas to sessionStorage on destroy.

and another link using a similar approach where the panel is absolutely positioned and hidden as required but never removed from the dom, based on the iframe examples found on dockview.dev
https://codesandbox.io/s/excalidraw-absolute-position-panel-forked-csh5wv

This solution would have worked better, but user input did not work for some reason (you couldn't draw any shapes).


chore: Go back to previous return type for loadFile

Change
After reviewing the question described by @nsaunders I think it would be best
to return to the initial return value for loadFile. It would make more sense
since it's an action that doesn't need to return the list of environment variables
loaded. It's main purpose is to load the envs from a file before running another action.

Glad to see this change, thanks again!


[DOC]: Some minor corrections for some of the examples README

How would you describe the priority of this documentation request
Medium
Please provide a link or source to the relevant docs
https://github.com/nv-morpheus/Morpheus/tree/branch-23.11/examples
Describe the problems in the documentation
Some of the docs for the examples assumes a morpheus developer environment but certain paths are not correct inside the runtime container.
https://github.com/nv-morpheus/Morpheus/blob/branch-23.11/examples/abp_nvsmi_detection/README.md?plain=1#L104
Inside the container there is no concept of MORPHEUS_ROOT. It could mean /workspace or /opt/conda/envs/morpheus/lib/python3.10/site-packages/ the latter obviously being counter-intuitive.
https://github.com/nv-morpheus/Morpheus/blob/branch-23.11/examples/digital_fingerprinting/starter/README.md?plain=1#L163 in a few spots in the pipeline CLI.
https://github.com/nv-morpheus/Morpheus/blob/branch-23.11/examples/log_parsing/README.md?plain=1#L66
(Optional) Propose a correction
Possibly just specify that all these files should be read from the models dir.
Code of Conduct

[X] I agree to follow this project's Code of Conduct
[X] I have searched the open documentation issues and have found no duplicates for this bug report

Closing this becauseMORPHEUS_ROOT has since been removed from these examples in subsequent releases.