kbmulti - auto lowercase

@sir-indy @thyttan what do you think of something like this in kbmulti? When the setting's on, it'll auto-lowercase the next character, when the user's in caps mode
(I've also made a little tweak to two displayText() calls, hope that's ok)

Sounds like it could be useful - don't know if I'll use it or not. 👍
I seem to remember someone have a stance on auto case. I think that time they were against it. But I don't even know which one of the keyboards it was.

Thanks! Yeah thought I'd better make it an option just in case, although I don't type all that often on my watch to be fair

If you think having it enabled is the better default maybe you should do it like that 🤔🙂

Yeah that's a good point, we can always flip the default back too if a lot of people prefer it that way - thanks

Great, cheers for your response and glad to hear too. I've popped my name in the readme as well - thanks!

Thanks!


[SPEC] Apply trait duplicate rules on apply_trait

Is your request related to a problem? Please describe.
Currently applying a trait adds it to a vector.
The Smithy spec says...
From trait conflict resolution:

Trait conflict resolution is used when the same trait is applied multiple times to a shape. Duplicate traits applied to shapes are allowed in the following cases:

If the trait is a list or set shape, then the conflicting trait values are concatenated into a single trait value.
If both values are exactly equal, then the conflict is ignored.

All other instances of trait collisions are prohibited.

Additional context
Add any other context or screenshots about the feature request here.

Completed


Add the bindaddress configuration option for chronyd.

Pull Request (PR) description

This Pull Request (PR) fixes the following issues

Looks like this needs more work, I'll come back with a fixed version later.


help request: undefined reference to static_assert

Hi~
I meet a error when I exec build-apisix-base-debug-centos7.sh:
objs/addon/vm/wasmtime.o: In function `assertions':
/tmp/tmp.QtyXQINVJz/openresty-<IP_ADDRESS>/../wasm-nginx-module-main/wasmtime-c-api/include/wasm.h:30: undefined reference to `static_assert'
/tmp/tmp.QtyXQINVJz/openresty-<IP_ADDRESS>/../wasm-nginx-module-main/wasmtime-c-api/include/wasm.h:31: undefined reference to `static_assert'
/tmp/tmp.QtyXQINVJz/openresty-<IP_ADDRESS>/../wasm-nginx-module-main/wasmtime-c-api/include/wasm.h:32: undefined reference to `static_assert'
collect2: error: ld returned 1 exit status

It seems that my environment does not have static_assert:
✗ uname -a
Linux apisix 3.10.0-862.el7.x86_64 #1 SMP Fri Apr 20 16:44:24 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux

✗ gcc --version
gcc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-44)
Copyright (C) 2015 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

But I do not how to solve it.
Would some one help me, Thanks~

Please use a higher version of gcc to compile. I use 8 or 9.


[API Proposal] Numeric Commands

INCR
Syntax
    INCR cluster  key

Increments the number stored at key by one. If the key does not exist, it is set to 0 before performing the operation.
Resp Reply:
Integer reply: the value of the key after the increment.
INCRBY
Syntax
    INCRBY cluster  key increment

Increments the number stored at key by the value of the parameter increment. If the key does not exist, it is set to 0 before performing the operation.
Resp Reply
Integer reply: the value of the key after the increment.
DECR
Syntax
    DECR cluster key

Decrements the number stored at key by one. If the key does not exist, it is set to 0 before performing the operation. An error is returned if the key contains a value of the wrong type or contains a string that can not be represented as integer.
RESP Reply
Integer reply: the value of the key after decrementing it.
DECRBY
Syntax
    DECRBY cluster  key decrement

Decrements the number stored at key by the value of parameter decrement. If the key does not exist, it is set to 0 before performing the operation. An error is returned if the key contains a value of the wrong type or contains a string that can not be represented as integer.
Resp Reply
Integer reply: the value of the key after decrementing it.

in progress I will adding this to application


GitHub diff links "squeezes" triple-dot button

Actual:

With

gives

Hi @stdedos!
Thanks for reporting this problem. It's just been fixed.


Add javadoc action

This builds javadoc on main and publishes it to the latest subdir
vX.Y tags also get built and published to a tag subdirectory
The top level index points to stable/index.html, and stable is a symlink pointing to a tag subdirectory. Currently 0.1.4.
I've only published the 0.1.4, I was gonna build the rest but seems pointless for now.
For new tags, the second job in the action updates the stable link to point to the docs for the current tag. Maybe a problem if we ever publish versions out of order (eg we publish 0.6.0, but find a critical bug in 0.5.3 so publish 0.5.4), but we shouldn't do that often, so I think it's fine
Output is here: https://alanocallaghan.github.io/qupath-fxtras
Absolutely not merging this on a Friday at 5pm, so will revisit next week and probably update https://github.com/qupath/javadoc/ as well... or maybe scrap this and try to do a big merged javadoc. Will see

Much delayed but I think this should work fine


fixing eslint issues and adjustments to rule chart

The charting is not quite accurate yet, but the base logic is there.

@C-Carter10 This is still waiting for your review


Enhance Makefile to be able to specify build targets

Is your feature request related to a problem? Please describe.
Recently I've built an application with make build and tried to deploy it to CloudFoundry as binary.
During deployment however I received the following error message:
Cannot execute binary file: Exec format error
It took a while to realize that I was working on an ARM Mac locally and therefor my executable was built for the wrong architecture.
Describe the solution you'd like
Can the Makefile be enhanced in a way that we can specify the build targets through the use of the vars GOOS and GOARCH?
Describe alternatives you've considered
An alternative that I used and which works is to simply issue the go build command manually and setting above mentioned variables.
Search

[X] I did search for other open and closed issues before opening this.

Code of Conduct

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

Additional context
No response

Hi, thanks for the feedback. Great idea, we'll look into it!


[Feature Request]: Support markdown or json as the input file type

Do you need to file an issue?

[X] I have searched the existing issues and this feature is not already filed.
[ ] My model is hosted on OpenAI or Azure. If not, please look at the "model providers" issue and don't file a new one here.
[X] I believe this is a legitimate feature request, not just a question. If this is a question, please use the Discussions area.

Is your feature request related to a problem? Please describe.
No response
Describe the solution you'd like
No response
Additional context
No response

Markdown is supported as far as I know. You can simply change the file pattern to search for .md files instead of .txt files

Markdown is supported as far as I know. You can simply change the file pattern to search for .md files instead of .txt files

Not Ture;
Tables in markdown are not extracted well.


Adapt library so that it distinguishes between numeral and number.

Also:
Adapt README.rst to match and add a remark about character digits.
Compute the value of a numeral more efficiently in numeral_to_number.
Use Python 3 '//' in case this is used in Python 3.
Check for base that exceed maximum allowed.
Adapt some tests appropriately, and add a few more.
Signed-off-by: mulhern<EMAIL_ADDRESS>

Hi!
These changes I would definitely recommend. The first change is a matter of correctness, and the speedup from the other change is significant.


Add ability to coexist with another websocket server

Hello @thetutlage,
This is a small merge request to allow a second websocket server to coexist with yours.
I know this is an edge case you probably wouldn't want to support but I sadly need this functionality in one of my project.
In this project, I use 2 ws servers, one for a spa and another for inter server communication.
The other server is sadly not written in nodejs thus I'm unable to use your front library.
The test are passing and you can find a working project example there
Its not really an inter server communication but an extends of your websocket example with the necessary modification to start both server.
It goes without saying that if this merge request is included, i would be glad to make the necessary change in your documentation.
As always thanks for your hard work and for providing such a fantastic tool !

I believe running multiple servers should be fine. Websocket doesn't block you from starting an independent server.
Can you share some code on what exactly you are trying to do and also what limitations you have hit

Hi @thetutlage,
Yes starting multiple websocket server sharing the same http server is possible with websockets/ws packages.
But the initialisation sequence is different when you start more than one. The problem lies in the upgrade request, as the http server does not know which server the upgrade request is addressed to.
This pr is based on what you can see in the ws library documentation.
and here, you can find the differences.
it goes from
const https = require('http');
const WebSocket = require('ws');

const server = new https.createServer();
const wss = new WebSocket.Server({ server });

wss.on('connection', function connection(ws) {
...
});

server.listen(8080);

to
const http = require('http');
const WebSocket = require('ws');

const server = http.createServer();
const wss1 = new WebSocket.Server({ noServer: true });
const wss2 = new WebSocket.Server({ noServer: true });

wss1.on('connection', function connection(ws) {
  // ...
});

wss2.on('connection', function connection(ws) {
  // ...
});

server.on('upgrade', function upgrade(request, socket, head) {
  const pathname = url.parse(request.url).pathname;

  if (pathname === '/foo') {
    wss1.handleUpgrade(request, socket, head, function done(ws) {
      wss1.emit('connection', ws, request);
    });
  } else if (pathname === '/bar') {
    wss2.handleUpgrade(request, socket, head, function done(ws) {
      wss2.emit('connection', ws, request);
    });
  } else {
    socket.destroy();
  }
});

server.listen(8080);

As you can see you have to initialize the websocket with noServer: true in place of passing the http server directly and handle the upgrade Request outside of it.
I've tested to start a second websocket server without these changes but both websocket servers (yours and the second one) didn't work properly.
Strangly enough using uws for the second server didn't pose any problem. But i would rather use the same library for both server.

For the code example, sadly i can't share the whole project. As this the company I'm working at property. but i have recreated a sample in repo you to seed what i have in mind. https://github.com/Goopil/adonisjs-websocket-dual-ws-server-demo
Its really simple, just to illustrate the dual ws server start and the event propagation from the first to the second. Nothing fancy.

Hello !
Any news on this pr ?
Do you have other questions o needs before merging it ?
thanks in advance !
best regards


feat: add advisor preview

Add advisor score to vscode extension
Score will show for packages with vulnerabilities, as shown in the following image:

To see this feature in action, use a package.json file with a package that known to have a score lower then 70, then hover with your mouse over the Advisor Score text with the mouse to see the advisor score details.
Example dependencies:
    "axios": "^0.20.0",
    "express": "^4.17.1",
    "firebase": "^5.8.2",
    "lodash": "^4.17.11",
    "numeral": "^2.0.6", # lower then 70
    "vue": "^2.5.21",
    "vue-router": "^3.0.6",
    "chino": "0.0.0", # lower then 70
    "vuejs": "3.0.1" # lower then 70

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.

As discussed offline, I'll be taking this PR over and merging it afterwards.

Thank you for your work on it @sangress 👏

Thank you for your work on it @sangress 👏

Thanks @michelkaporin for mentioning.
It's good to see it live; it was my longest PR ever, but I did enjoy working on it.
Good luck with future features :)


Store multireducer key in context

One of the options - store multireducer key in react context, here is my experiment for this
https://github.com/me6iaton/multireducer/commit/a15f58620580d254e6197c34a493c64055e95f67

What's the benefit to store reducer key in context?

config reducer key in root router component, once, and use connectMultireducer in deep components with the same key

Seems your commit is based on the version 2, connectMultireducer  has been removed in version 3. If you want pass reducer key down to the child components, you can create context by yourself in version 3:
class ListComponent extends Component {
  static propTypes = {
    as: PropTypes.string.isRequired
  }

  static childContextTypes = {
    as: PropTypes.string.isRequired
  }

  getChildContext() {
    return { as: this.props.as }
  }

  render() {
    return (
      <div>
        <Item />
      </div>
    );
  }
}

BTW, you can find migration guide here.

i see, thanks


Check for UnicodeEncodeError when printing the success message

Hi,
Thanks for your great work!
There exists an issue I've encountered in several environments with printing "👍".
The problem is that we get "Validation failed!" trying to print "Validation success! 👍" which is both funny and incorrect.
The issue can be reproduced in ubuntu docker, but it is not limited to docker in my experience.
I prefer to keep the original message when possible, which dictates the try ... except approach in the PR.

Hi, thanks for your interest in Yamale!
Can you provide some recreation steps? I ran Yamale within an Ubuntu docker container and the "Validation success! 👍" message prints without error.

Can you provide some recreation steps? I ran Yamale within an Ubuntu docker container and the "Validation success! 👍" message prints without error.

To clarify, the issue is image-dependent if we talk about Docker (e.g. generating locale can be a hot-fix).
Please check the following Dockerfile to reproduce it:
FROM ubuntu:18.04

RUN apt-get update && apt-get upgrade -y && apt-get clean
RUN apt-get install -y python3-pip
RUN pip3 install yamale

Build an image and run yamale:
docker build -t unicode-fail-image .
docker run unicode-fail-image yamale

Expected result:
Validation failed!
'ascii' codec can't encode character '\U0001f44d' in position 20: ordinal not in range(128)

Well that's unfortunate, I'm surprised it took 5 years for someone to have an issue with that. Thanks for the recreation steps.

Your fix is in release 4.0.3, thanks for the contribution!

Your fix is in release 4.0.3, thanks for the contribution!

Thanks!


fix(card/banner/toast): align components

BREAKING: The subheader prop was removed from the Card component.
Describe pull-request
Aligns the slots in the card, banner and toast components.
Instead of props they all use a slot for subheader.
The card keeps the card-bottom slot and the toast/banner keeps their {component}-link slot. This is due to the different use cases for the slots.
Solving issue
Fixes: #
How to test

Go to storybook
Check in Components -> Card/Toast/Banner
Check the API and the subheader slot in particular.

Why do we need to conditionally render the slots? Might be a good idea, might not

Because the padding/margins and such differ if the slots are present or not. And we don't conditionally render them we will get elements in the DOM that are only there for the slots.

Instead of removing the subheader prop, could we keep both prop and slot to chose from? Prop for convenience, slot for flexibility?
Seems more user friendly

Agree, but then I'll do the same on the other component (toast/banner)

Also, for the storybook controls - I think that, for example, the "subheader text" should just contain the content, not the slot itself.
I guess if the text is null or an empty string we could conditionally skip adding the slot.

I gave this a second thought and I am a bit worried we might make confusion for us and users. I am a bit more for either/or slot approach, but not both + making standard when we use a prop and when we use a slot. For example, should a slot be there for any kind of content injection, where the prop is for changing the type/feature/size/variation/state of a component? Let's talk about it on Monday, I will set up something.
The second thing is to prefer PR per component - just to make it easier for review.

Sure thing, let's discuss it. I just want to emphasise that I think there is great value in offering both a slot and a prop. For the subheader for instance a prop can ONLY be text. If we also open up the flexibility in user adding text + icon in the subheader. I feel like this is important, since we can't calculate for every use case and with this, atleast we leave it up to the users that need it to actually achieve it.

Closing this PR and opening one PR per component instead.


  I have verified there are images there that match tag policies.
Here's one of our image policies:
apiVersion: image.toolkit.fluxcd.io/v1beta1
kind: ImagePolicy
metadata:
  annotations:
    kubectl.kubernetes.io/last-applied-configuration: |
      {"apiVersion":"image.toolkit.fluxcd.io/v1alpha2","kind":"ImagePolicy","metadata":{"annotations":{"kustomize.toolkit.fluxcd.io/checksum":"20847e561e520d3f3379a96ea1544fbd6ce61573"},"labels":{"kustomize.toolkit.fluxcd.io/name":"image-automation","kustomize.toolkit.fluxcd.io/namespace":"flux-system"},"name":"posapi-image-policy","namespace":"flux-system"},"spec":{"filterTags":{"extract":"$timestamp","pattern":"^master-(?P\u003ctimestamp\u003e.*)+-[a-fA-F0-9]"},"imageRepositoryRef":{"name":"posapi"},"policy":{"numerical":{"order":"asc"}}}}
    kustomize.toolkit.fluxcd.io/checksum: 20847e561e520d3f3379a96ea1544fbd6ce61573
  creationTimestamp: "2021-05-26T21:53:07Z"
  generation: 3
  labels:
    kustomize.toolkit.fluxcd.io/name: image-automation
    kustomize.toolkit.fluxcd.io/namespace: flux-system
  name: posapi-image-policy
  namespace: flux-system
  resourceVersion: "235375908"
  uid: 3b003ed8-10fb-4f79-ae3c-beed622c623a
spec:
  filterTags:
    extract: $timestamp
    pattern: ^master-(?P<timestamp>.*)-[a-fA-F0-9]
  imageRepositoryRef:
    name: posapi
  policy:
    numerical:
      order: asc
status:
  conditions:
  - lastTransitionTime: "2021-11-23T21:26:06Z"
    message: 'Latest image tag for '[REDACTED].amazonaws.com/nabpos/posapi''
      resolved to: master-1637636434-5ba81ca3'
    reason: ReconciliationSucceeded
    status: "True"
    type: Ready
  latestImage: [REDACTED].amazonaws.com/nabpos/posapi:master-1637636434-5ba81ca3
  observedGeneration: 3

The latestImage identified above is indeed the most recent image in the repo, but yet flux won't deploy it for some reason.
Log line for this image policy in reflector logs:
{"level":"info","ts":"2021-11-23T21:48:12.017Z","logger":"controller-runtime.manager.controller.imagerepository","msg":"reconciliation finished in 244.534603ms, next run in 1m0s","reconciler group":"image.toolkit.fluxcd.io","reconciler kind":"ImageRepository","name":"posapi","namespace":"flux-system"}

However, the pod deployment descriptor does not match:
Containers:
   posapi:
    Image:      [REDACTED].amazonaws.com/nabpos/posapi:master-1636066867-87bb7ef9
    Port:       8080/TCP
    Host Port:  0/TCP

I'm not seeing a ton of errors in flux controller logs that relate to any of this.  I've tried to scale the image-* controllers down and back up.  I've tried deleting my deployment and then doing:
flux reconcile kustomization <name> --with-source and it re-creates the deployment with the stale image (which has since been deleted so we just get ErrImagePull`
The image-update-automation-controller seems to be working as it has tagged the appropriate file in our github repo with the latest image
      containers:
        - name: posapi
          image:<PHONE_NUMBER>35.dkr.ecr.us-east-1.amazonaws.com/nabpos/posapi:master-1637636434-5ba81ca3 # {"$imagepolicy": "flux-system:posapi-image-policy"}

➜ kc -n flux-system logs image-automation-controller-b4db5559c-6bpjh
{"level":"info","ts":"2021-11-23T21:16:00.064Z","logger":"controller-runtime.metrics","msg":"metrics server is starting to listen","addr":":8080"}
{"level":"info","ts":"2021-11-23T21:16:00.065Z","logger":"setup","msg":"starting manager"}
{"level":"info","ts":"2021-11-23T21:16:00.066Z","logger":"controller-runtime.manager","msg":"starting metrics server","path":"/metrics"}
I1123 21:16:00.066197       1 leaderelection.go:243] attempting to acquire leader lease flux-system/image-automation-controller-leader-election...
I1123 21:16:00.098989       1 leaderelection.go:253] successfully acquired lease flux-system/image-automation-controller-leader-election
{"level":"info","ts":"2021-11-23T21:16:00.166Z","logger":"controller-runtime.manager.controller.imageupdateautomation","msg":"Starting EventSource","reconciler group":"image.toolkit.fluxcd.io","reconciler kind":"ImageUpdateAutomation","source":"kind source: /, Kind="}
{"level":"info","ts":"2021-11-23T21:16:00.167Z","logger":"controller-runtime.manager.controller.imageupdateautomation","msg":"Starting EventSource","reconciler group":"image.toolkit.fluxcd.io","reconciler kind":"ImageUpdateAutomation","source":"kind source: /, Kind="}
{"level":"info","ts":"2021-11-23T21:16:00.167Z","logger":"controller-runtime.manager.controller.imageupdateautomation","msg":"Starting EventSource","reconciler group":"image.toolkit.fluxcd.io","reconciler kind":"ImageUpdateAutomation","source":"kind source: /, Kind="}
{"level":"info","ts":"2021-11-23T21:16:00.167Z","logger":"controller-runtime.manager.controller.imageupdateautomation","msg":"Starting Controller","reconciler group":"image.toolkit.fluxcd.io","reconciler kind":"ImageUpdateAutomation"}
{"level":"info","ts":"2021-11-23T21:16:00.268Z","logger":"controller-runtime.manager.controller.imageupdateautomation","msg":"Starting workers","reconciler group":"image.toolkit.fluxcd.io","reconciler kind":"ImageUpdateAutomation","worker count":4}

I'm at a bit of a loss on how to proceed?  How can I get image automation working again?
➜ flux get image all
NAME                             	READY	MESSAGE                      	LAST SCAN                	SUSPENDED
imagerepository/authz            	True 	successful scan, found 4 tags	2021-11-23T16:54:11-05:00	False
imagerepository/authz-migrations 	True 	successful scan, found 2 tags	2021-11-23T16:54:12-05:00	False
imagerepository/posapi           	True 	successful scan, found 3 tags	2021-11-23T16:54:13-05:00	False
imagerepository/posapi-migrations	True 	successful scan, found 3 tags	2021-11-23T16:54:13-05:00	False
imagerepository/postools         	True 	successful scan, found 3 tags	2021-11-23T16:54:13-05:00	False

NAME                                      	READY	MESSAGE                                                                                LATEST IMAGE
imagepolicy/authz-image-policy            	True 	Latest image tag for '[REDACTED].amazonaws.com/nabpos/authz' resolved to: master-1633964677-6f1132c             	[REDACTED].amazonaws.com/nabpos/authz:master-1633964677-6f1132c
imagepolicy/authz-migrations-image-policy 	True 	Latest image tag for '[REDACTED].amazonaws.com/nabpos/graphdb-migrations' resolved to: master-1633965047-6f1132c	[REDACTED].amazonaws.com/nabpos/graphdb-migrations:master-1633965047-6f1132c
imagepolicy/posapi-image-policy           	True 	Latest image tag for '[REDACTED].amazonaws.com/nabpos/posapi' resolved to: master-1637636434-5ba81ca3           	[REDACTED].amazonaws.com/nabpos/posapi:master-1637636434-5ba81ca3
imagepolicy/posapi-migrations-image-policy	True 	Latest image tag for '[REDACTED].amazonaws.com/nabpos/posapi-migrations' resolved to: master-1637636577-5ba81ca3	[REDACTED].amazonaws.com/nabpos/posapi-migrations:master-1637636577-5ba81ca3
imagepolicy/postools-image-policy         	True 	Latest image tag for '[REDACTED].amazonaws.com/nabpos/postools' resolved to: master-1637636585-5ba81ca3         	[REDACTED].amazonaws.com/nabpos/postools:master-1637636585-5ba81ca3

NAME                             	READY	MESSAGE                                                     	LAST RUN                 	SUSPENDED
imageupdateautomation/flux-system	True 	no updates made; last commit 2191734 at 2021-11-23T20:16:18Z	2021-11-23T16:54:58-05:00	False

Hello @davisford,
This is definitely not an issue with the IRC or the IAC since everything works as expected as far as their responsibility boundaries are concerned, but it does sound like it might be an issue with the Kustomization resource that is applying the respective manifests to the cluster. Could you please check that and see if there's anything relevant reported there?

@relu is the kustomization controller responsible for pulling and deploying the images?
I do have one kustomization error.  It involves the ingress spec:
➜ flux get kustomizations
NAME                   	READY	MESSAGE                                                                                REVISION                                     	SUSPENDED
bridge                 	True 	Applied revision: main/42ca2072d98fc4809499d04a4943a931e88dc55b                                                                                main/42ca2072d98fc4809499d04a4943a931e88dc55b	False
bridge-crd             	True 	Applied revision: main/42ca2072d98fc4809499d04a4943a931e88dc55b                                                                                main/42ca2072d98fc4809499d04a4943a931e88dc55b	False
cluster-autoscaler     	True 	Applied revision: main/42ca2072d98fc4809499d04a4943a931e88dc55b                                                                                main/42ca2072d98fc4809499d04a4943a931e88dc55b	False
davis                  	True 	Applied revision: main/42ca2072d98fc4809499d04a4943a931e88dc55b                                                                                main/42ca2072d98fc4809499d04a4943a931e88dc55b	False
davis-crd              	True 	Applied revision: main/42ca2072d98fc4809499d04a4943a931e88dc55b                                                                                main/42ca2072d98fc4809499d04a4943a931e88dc55b	False
ecr-credentials-sync   	True 	Applied revision: main/42ca2072d98fc4809499d04a4943a931e88dc55b                                                                                main/42ca2072d98fc4809499d04a4943a931e88dc55b	False
external-dns           	True 	Applied revision: main/42ca2072d98fc4809499d04a4943a931e88dc55b                                                                                main/42ca2072d98fc4809499d04a4943a931e88dc55b	False
flux-system            	True 	Applied revision: main/42ca2072d98fc4809499d04a4943a931e88dc55b                                                                                main/42ca2072d98fc4809499d04a4943a931e88dc55b	False
hideki                 	True 	Applied revision: main/42ca2072d98fc4809499d04a4943a931e88dc55b                                                                                main/42ca2072d98fc4809499d04a4943a931e88dc55b	False
hideki-crd             	True 	Applied revision: main/42ca2072d98fc4809499d04a4943a931e88dc55b                                                                                main/42ca2072d98fc4809499d04a4943a931e88dc55b	False
image-automation       	True 	Applied revision: main/42ca2072d98fc4809499d04a4943a931e88dc55b                                                                                main/42ca2072d98fc4809499d04a4943a931e88dc55b	False
ingress-nginx          	False	Deployment/ingress-nginx/ingress-nginx-controller dry-run failed, error: failed to create manager for existing fields: failed to convert new object (apps/v1, Kind=Deployment) to smd typed: .spec.template.spec.containers[name="controller"].ports: duplicate entries for key [containerPort=80,protocol="TCP"]	main/5f7e56ed5328481798d7feff415036e220d32178	False

jenkins01              	True 	Applied revision: main/42ca2072d98fc4809499d04a4943a931e88dc55b                                                                                main/42ca2072d98fc4809499d04a4943a931e88dc55b	False
jenkins01-crd          	True 	Applied revision: main/42ca2072d98fc4809499d04a4943a931e88dc55b                                                                                main/42ca2072d98fc4809499d04a4943a931e88dc55b	False
jenkins02              	True 	Applied revision: main/42ca2072d98fc4809499d04a4943a931e88dc55b                                                                                main/42ca2072d98fc4809499d04a4943a931e88dc55b	False
jenkins02-crd          	True 	Applied revision: main/42ca2072d98fc4809499d04a4943a931e88dc55b                                                                                main/42ca2072d98fc4809499d04a4943a931e88dc55b	False
justin                 	True 	Applied revision: main/42ca2072d98fc4809499d04a4943a931e88dc55b                                                                                main/42ca2072d98fc4809499d04a4943a931e88dc55b	False
justin-crd             	True 	Applied revision: main/42ca2072d98fc4809499d04a4943a931e88dc55b                                                                                main/42ca2072d98fc4809499d04a4943a931e88dc55b	False
mauricio               	True 	Applied revision: main/42ca2072d98fc4809499d04a4943a931e88dc55b                                                                                main/42ca2072d98fc4809499d04a4943a931e88dc55b	False
mauricio-crd           	True 	Applied revision: main/42ca2072d98fc4809499d04a4943a931e88dc55b                                                                                main/42ca2072d98fc4809499d04a4943a931e88dc55b	False
monitoring             	True 	Applied revision: main/42ca2072d98fc4809499d04a4943a931e88dc55b                                                                                main/42ca2072d98fc4809499d04a4943a931e88dc55b	False
nats                   	True 	Applied revision: main/42ca2072d98fc4809499d04a4943a931e88dc55b                                                                                main/42ca2072d98fc4809499d04a4943a931e88dc55b	False
notification-controller	True 	Applied revision: main/42ca2072d98fc4809499d04a4943a931e88dc55b                                                                                main/42ca2072d98fc4809499d04a4943a931e88dc55b	False
oleg                   	True 	Applied revision: main/42ca2072d98fc4809499d04a4943a931e88dc55b                                                                                main/42ca2072d98fc4809499d04a4943a931e88dc55b	False
oleg-crd               	True 	Applied revision: main/42ca2072d98fc4809499d04a4943a931e88dc55b                                                                                main/42ca2072d98fc4809499d04a4943a931e88dc55b	False
patrick                	True 	Applied revision: main/42ca2072d98fc4809499d04a4943a931e88dc55b                                                                                main/42ca2072d98fc4809499d04a4943a931e88dc55b	False
patrick-crd            	True 	Applied revision: main/42ca2072d98fc4809499d04a4943a931e88dc55b                                                                                main/42ca2072d98fc4809499d04a4943a931e88dc55b	False
portworx               	True 	Applied revision: main/42ca2072d98fc4809499d04a4943a931e88dc55b                                                                                main/42ca2072d98fc4809499d04a4943a931e88dc55b	False
pos                    	True 	Applied revision: main/42ca2072d98fc4809499d04a4943a931e88dc55b                                                                                main/42ca2072d98fc4809499d04a4943a931e88dc55b	False
pos-crd                	True 	Applied revision: main/42ca2072d98fc4809499d04a4943a931e88dc55b                                                                                main/42ca2072d98fc4809499d04a4943a931e88dc55b	False
postgres               	True 	Applied revision: main/42ca2072d98fc4809499d04a4943a931e88dc55b                                                                                main/42ca2072d98fc4809499d04a4943a931e88dc55b	False
prometheus             	True 	Applied revision: main/42ca2072d98fc4809499d04a4943a931e88dc55b                                                                                main/42ca2072d98fc4809499d04a4943a931e88dc55b	False
shaun                  	True 	Applied revision: main/42ca2072d98fc4809499d04a4943a931e88dc55b                                                                                main/42ca2072d98fc4809499d04a4943a931e88dc55b	False
shaun-crd              	True 	Applied revision: main/42ca2072d98fc4809499d04a4943a931e88dc55b                                                                                main/42ca2072d98fc4809499d04a4943a931e88dc55b	False
shayna                 	True 	Applied revision: main/42ca2072d98fc4809499d04a4943a931e88dc55b                                                                                main/42ca2072d98fc4809499d04a4943a931e88dc55b	False
shayna-crd             	True 	Applied revision: main/42ca2072d98fc4809499d04a4943a931e88dc55b                                                                                main/42ca2072d98fc4809499d04a4943a931e88dc55b	False
staging                	True 	Applied revision: main/42ca2072d98fc4809499d04a4943a931e88dc55b                                                                                main/42ca2072d98fc4809499d04a4943a931e88dc55b	False
staging-crd            	True 	Applied revision: main/42ca2072d98fc4809499d04a4943a931e88dc55b                                                                                main/42ca2072d98fc4809499d04a4943a931e88dc55b	False

After the last flux upgrade, they mentioned the duplicate yaml keys issue which I thought might be relevant here.
➜ flux get kustomization ingress-nginx
NAME         	READY	MESSAGE                                                                                REVISION                                     SUSPENDED
ingress-nginx	False	Deployment/ingress-nginx/ingress-nginx-controller dry-run failed, error: failed to create manager for existing fields: failed to convert new object (apps/v1, Kind=Deployment) to smd typed: .spec.template.spec.containers[name="controller"].ports: duplicate entries for key [containerPort=80,protocol="TCP"]	main/5f7e56ed5328481798d7feff415036e220d32178False

I went down this path but it seems to not be related and more of k8s issue
I'm deploying the ingress-nginx spec right out of the box, just replacing some vars for ELB endpoint and cert and such.  To redirect port 80 back to port 443, this is how their spec wants it.
I still don't have a resolution for that, but I'm not sure this is the root cause of this issue?  All my other kustomizations seem to deploy just fine.
I'm happy to provide any other info.  Thanks!

FYI: that ingress failure only started when I upgraded to a newer flux version.

is the kustomization controller responsible for pulling and deploying the images?

No, that would be Kubernetes itself once the workload resource (Deployment, StatefulSet etc.) is updated. The KC will only apply the manifest changes from your git repository, which are pulled in by the source controller.
Can you check the following:

Your GitOps repo's main branch HEAD is indeed at 42ca2072d98fc4809499d04a4943a931e88dc55b
The Flux GitRepository resource is reconciled correctly (there are no errors, check with flux get source git)
Your kustomization overlay does indeed apply the patches (maybe you can reveal a bit more of your kustomization patch)

The ingress-nginx issue you have is likely not related.

Thanks @relu
➜ git pull && git log -n 1
Already up to date.
commit 42ca2072d98fc4809499d04a4943a931e88dc55b (HEAD -> main, origin/main, origin/HEAD)
Author: Davis Ford<EMAIL_ADDRESS>Date:   Tue Nov 23 16:24:40 2021 -0500

➜ flux get source git
NAME       	READY	MESSAGE                                                        	REVISION                                     	SUSPENDED
flux-system	True 	Fetched revision: main/42ca2072d98fc4809499d04a4943a931e88dc55b	main/42ca2072d98fc4809499d04a4943a931e88dc55b	False

Regarding #3 -- I found the issue.  A few days back, we pushed a PR because of the breaking changes listed in v1beta1, specifically, this:

.spec.patchesStrategicMerge deprecated in favour of .spec.patches

Our kustomizations that involved image patching had a separate image-patch.yaml file, that contained snippets like the following:
apiVersion: apps/v1
kind: Deployment
metadata:
  name: posapi
spec:
  replicas: 2
  template:
    spec:
      initContainers:
        - name: init
          image: governmentpaas/psql:main
        - name: migrations
          image: [REDACTED].amazonaws.com/nabpos/posapi-migrations:master-1637636577-5ba81ca3 # {"$imagepolicy": "flux-system:posapi-migrations-image-policy"}
      containers:
        - name: posapi
          image: [REDACTED].amazonaws.com/nabpos/posapi:master-1637636434-5ba81ca3 # {"$imagepolicy": "flux-system:posapi-image-policy"}

...and in the kustomization.yaml file:
patchesStrategicMerge:
  - ./image-patch.yaml

Because of the deprecation for patchesStrategicMerge we pushed it up as this instead directly in the kustomization.yaml:
patches:
  - patch: |-
      apiVersion: apps/v1
      kind: Deployment
      metadata:
        name: posapi
      spec:
        replicas: 2
        template:
          spec:
            initContainers:
              - name: init
                image: governmentpaas/psql:main
              - name: migrations
                image: [REDACTED].amazonaws.com/nabpos/posapi-migrations:master-1636067058-87bb7ef9 # {"$imagepolicy": "flux-system:posapi-migrations-image-policy"}
            containers:
              - name: posapi
                image: [REDACTED].amazonaws.com/nabpos/posapi:master-1636066867-87bb7ef9 # {"$imagepolicy": "flux-system:posapi-image-policy"}

However, flux was still updating the image-patch.yaml file -- updating it with the most recent tags, but it wasn't touching this inline patch.  When I reverted it back to use patchesStrategicMerge everything started working again.
It appears flux cannot update / annotate or understand the inline patches here, or else there is some state that is kept so when one migrates it doesn't understand how to deal with it.
I realize this is a complex scenario and hard to setup for a test case, but if you have advice on how to proceed with the patches field, we understand we'll eventually be forced to adopt it and remove patchesStrategicMerge
Thanks!

Feel free to close this issue, as I found the root cause, but I would still like to know how to get it to work with the new patches field

Glad you found the issue, @davisford.
You can use the following format:
patches:
- path: patch.yaml

And it will yield the same result as with patchesStrategicMerge.
The kyaml markers will not be recognized if it's part of a multi-line string, they needs to be a valid YAML comment.

Thanks @relu -- will test it out shortly.  Appreciate your prompt responses.


:seedling: Included cron data when using KO

@imjasonh Does this look good for including the data files?

@imjasonh Does this look good for including the data files?

Unfortunately this won't do what it looks like.
When ko publish is run, it looks for a directory under the importpath being build called kodata/ (there's no renaming this directory). ko will bundle up everything in that directory into a new layer in your image, at some path, and expose that path to your code as KO_DATA_PATH -- that env var is available at runtime, not at build-time.
So the change you'd need is to:

create a directory cron/controller/kodata, which either contains the data currently in cron/data, or is a symlink to that directory (ko will chase symlinks when creating the kodata layer).
have your code load that data from filepath.Join(os.Getenv("KO_DATA_PATH"), projects.release.csv), instead of taking the location as arg[0] (as here).

This won't shuffle the data like you seem to be doing, I'm not sure why you do that, or if not doing it would cause problems.


chore: use webpack to build

Changes

Uses Webpack as the bundler
Inline package code instead of alternate entry points

Advantages

Now should be able to add babeliser
Smaller package thanks to minification + sourcemap
Should be compatible in Node + Browser

Disadvantages

None?

@Sembauke @Nirajn2311 will this work with the mobile app? The main change is that it's all distributed in a single bundle, now. It's no-longer possible to import specific files.


Add more introductory pages (and update "create custom environment")

Description
In reviewing the website, I realised that we currently have a pretty bad set of introductory pages for new users.
Therefore, this PR adds several key pages that I believe will be very helpful for new users:

basic usage - Same as before just updated and addresses https://github.com/Farama-Foundation/Gymnasium/issues/735
training an agent - Most users will be interested in using a built-in gymnasium environment to train a basic RL agents to begin with. The easiest solution is to move the "Solving blackjack using Q-learning" tutorial with minor changes. We should look to add tutorials for training agents to play Atari and Mujoco environments.
create a custom environment - The second most common thing for users should be creating their own custom environment. The easiest solution again is to move the "Creating a custom environment" tutorial but this tutorial needs large scale changes (@kir0ul is working on this). We should look to add a section at the end linking to third-party environments.
Recording agents - While uncommon, I think having a page about recording data on agents during training and evaluation is helpful. In particular how to use the RecordVideo and RecordEpisodeStatistics.
Speeding up environments - A bit more niche but critical is using vector environments. I think "speeding up environment" is more helpful to new users than "how to use vector environments" and we can note other techniques that can be used.
Compatibility with OpenAI Gym - Same as before (show be updated for v1.0.0)
Migration guide - Same as before but should include updating to v1.0.0

Todo

[ ] Add compiling from python to rst (we support this for tutorials but we don't want the gallery aspect)
[ ] Finish "Recording agents"
[ ] Modify "Speeding up the environment" to add an explanation of vector environments
[ ] Update training an agent to be more introductory

closed for #791


How to disable call to 'byebug' from code?

How to disable call to 'byebug' from code just like disable breakpoints?

Hi @cheunghy
The idea is that you have to remove the line or move it somewhere else (note that there's some issues with it, see https://github.com/deivid-rodriguez/byebug/issues/120). If you don't want to call byebug from code at all, you can run your program through byebug's runner (byebug your_program.rb).


Fix issue for not properly display star badge

Hi,
I found that star badge of some github repo was not properly displayed, and the root cause is that the URL contains trailing slash

Wohoo! Nice find!
Just a minor little remark. We can commit it like so, but maybe we can fix it anyway.

I found that github repo under "Multiple languages" and "Other" also not displaying star badge, so I edited data/render/templates/README.md

Thanks @AristoChen 🍪


Comment when /lgtm or /approve are unauthorized

When someone tries to use /lgtm or /approve, but they are not authorized to perform that action, log the error but also comment back on the pull request so that they know that their slash command didn't work.
Screenshot below shows what the comments look like when you aren't in the OWNERS file, or if there isn't an OWNERS file, for /lgtm and /approve.

Oops submitted this with my test account I was using to validate the action was working. I'll close and resubmit.


updated stenbock resuslts to 0.16.0

I updated the Steinbock output by running the steinbock.sh script. All files seem to have changed. Checked some masks and crops, they seem fine.

Sorry for getting back to this so super late. I think it would be great to finish this PR. Please have a look at the comments. Also please have a look if the ilastik/CellProfiler segmentation approach works.

I'm closing this as the data have been updated in #9. Feel free to open a new PR to further update the data


Add a shell utility to modify and review KCL properties

I think this utility is in a good state, but we should also have a manual page for it.

I've renamed the file to zbm-kcl. I don't want to add edit in there because it's also useful just to query: zbm-kcl will just dump the KCL for the current root right to the console.


cdb: debug tool to read raw extent data from store

Coverage increased (+0.03%) to 68.644% when pulling f82b56aaa817a18c887906a3de52b3ad4b0b72df on cdb into 6442730afadee8048645c368f1fa5856607bc5d7 on master.


No confirmation on closing a modified .sql file

If you open an .sql file from disk, modify it and then close it, the file is automatically saved.
I have accidentally overwritten several common queries i had stored for repeated use this way.
Could you add a confirmation dialog when closing a modified file (Save/Discard/Cancel)?

Hello @Condor70,
Perhaps you have this option enabled?

You are completely correct. No idea how this option got activated.
Or is auto-saving the default option? That would be bad!

No, it's turned off by default. Call the Ghostbusters!


Prophet version

What does this implement/fix? Explain your changes.
Changed fbprophet to prophet as this is the new Python package with a new release.
Does your contribution introduce a new dependency? If yes, which one?
prophet

Martin Walter<EMAIL_ADDRESS>Mercedes-Benz AG on behalf of Daimler TSS GmbH.
https://github.com/Daimler/daimler-foss/blob/master/LEGAL_IMPRINT.md

appveyor breaks with AttributeError: 'Prophet' object has no attribute 'stan_backend' - not sure what that is, but it's clearly related to prophet.

Thx, I will check, maybe the params of prophet changed

I dont know why its breaking just appveyor.
@ChuliangXiao maybe you want to look into it? I think you are interested in having prophet in sktime? 😄

Martin Walter<EMAIL_ADDRESS>Mercedes-Benz AG on behalf of Daimler TSS GmbH.
https://github.com/Daimler/daimler-foss/blob/master/LEGAL_IMPRINT.md

FYI, I think I get the same issue when trying to install the old fbprophet using pip and not conda under windows. I never understood what caused the issue, but it just couldn't be installed... see also #666

hi @aiwalter I'm trying to cut down the number of open PRs. This is conflicted and has been inactive for a while. Can you close it if no longer relevant? ta


add timeout notification stamp msgs

rm std_msgs
ros2 node info /emergency_handler
/emergency_handler
  Subscribers:
    /autoware/driving_capability: autoware_system_msgs/msg/DrivingCapability
    /autoware/state: autoware_system_msgs/msg/AutowareState
    /control/current_gate_mode: autoware_control_msgs/msg/GateMode
    /control/vehicle_cmd: autoware_vehicle_msgs/msg/VehicleCommand
    /is_state_timeout: autoware_system_msgs/msg/TimeoutNotificationStamped
    /localization/twist: geometry_msgs/msg/TwistStamped
    /parameter_events: rcl_interfaces/msg/ParameterEvent
  Publishers:
    /diagnostics_err: diagnostic_msgs/msg/DiagnosticArray
    /parameter_events: rcl_interfaces/msg/ParameterEvent
    /rosout: rcl_interfaces/msg/Log
    /system/emergency/control_cmd: autoware_control_msgs/msg/ControlCommandStamped
    /system/emergency/hazard_status: autoware_system_msgs/msg/HazardStatusStamped
    /system/emergency/is_emergency: autoware_control_msgs/msg/EmergencyMode
    /system/emergency/shift_cmd: autoware_vehicle_msgs/msg/ShiftStamped
    /system/emergency/turn_signal_cmd: autoware_vehicle_msgs/msg/TurnSignal
  Service Servers:
    /emergency_handler/describe_parameters: rcl_interfaces/srv/DescribeParameters
    /emergency_handler/get_parameter_types: rcl_interfaces/srv/GetParameterTypes
    /emergency_handler/get_parameters: rcl_interfaces/srv/GetParameters
    /emergency_handler/list_parameters: rcl_interfaces/srv/ListParameters
    /emergency_handler/set_parameters: rcl_interfaces/srv/SetParameters
    /emergency_handler/set_parameters_atomically: rcl_interfaces/srv/SetParamete

Is it better to change simply TimeoutNotification.msg as following and delete TimeoutNotificationStamped.msg?
TimeoutNotification.msg
builtin_interfaces/Time stamp
bool is_timeout

(Ref. https://github.com/tier4/AutowareArchitectureProposal.iv/blob/ros2-v0.8.0-beta/common/msgs/autoware_vehicle_msgs/msg/Engage.msg )

@tkimura4 We need non-stamped msgs when including msgs in autoware_api_msgs. So I think it's okay we always have non-stamped and stamped msg.
What do you think?

We need non-stamped msgs when including msgs in autoware_api_msgs.

OK. Then, these msgs are fine.

However, actually, this msg is only for internal uses. So I've changed my idea, this msg doesn't need to have a separated-stamped type.
@taikitanaka3 I'm sorry but could remove this, please...?

What do you mean "this msg doesn't need to have a separated-stamped" ?
Could you describe more details?

@taikitanaka3 I meant "we should delete TimeoutNotificationStamped.msg".

Could you change TimeoutNotifiction.msg as the following link?
https://github.com/tier4/AutowareArchitectureProposal.iv/pull/363#issuecomment-786450162


UI/UX need to be fixed.

There are several issues related to UI/UX that need to be fixed.
-Home Screen views are not properly arranged. The "Checkout" and "Add" buttons are taking up extra space, which can be reduced to create a cleaner look.
-The dialogue box for adding items does not match the app’s UI and needs to be redesigned.
-Users attempting to add an item without a Name or Amount should be notified to ensure proper input.
@yuvrajsinghgmx Please assign it to me and add relevant labels for GSSOC/Hactoberfest, I would love to fix it.

I have fixed the issue.
-Now the Home Screen looks cleaner and more interactive.

-The "Add Dialog" pop-up has been improved to better align with the app's overall design.

-Users are now notified when attempting to add an item without providing a name or amount.

Please assign the issue to me so I can proceed with submitting a pull request.


Upgrade nuget package reference from Humanizr to Humanizr.Core v2.0.0

This update removes the Nuget package for Humanizr 1.37.7 (with all its localization) and adds the package Humanizr.Core 2.0.0 along with its dependencies.
I ran the NUnit tests and everything still passes.

@sgwatgit Good to know about Humanizr.Core and thanks for the contribution :+1:


[FEATURE] Environment check script for Longhorn with SPDK

Is your feature request related to a problem? Please describe (👍 if you like this request)
The script will check

OS distro
Kernel module
Dependent packages
SPDK

Describe the solution you'd like
A clear and concise description of what you want to happen
Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.
Additional context
Add any other context or screenshots about the feature request here.

Assigned @yangchiu as well to make this support in the SLE micro setup provisioning.
cc @longhorn/qa

Verified pass in longhorn master(longhorn 15a73c)
In 3 nodes cluster, setup environment with instructions and run environment check script, did not encounter problem in below distro

Ubuntu AMD64
Ubuntu ARM64
SLES AMD64
SLES ARM64

AMD64 output
No VM guests are running outdated hypervisor (qemu) binaries on this host.
root@ip-172-31-21-42:/home/ubuntu# bash -c "$(curl -sfL https://raw.githubusercontent.com/longhorn/longhorn/master/scripts/environment_check.sh)" -s -s
[INFO]  Required dependencies 'kubectl jq mktemp' are installed.
[INFO]  All nodes have unique hostnames.
[INFO]  Waiting for longhorn-environment-check pods to become ready (0/3)...
[INFO]  All longhorn-environment-check pods are ready (3/3).
[INFO]  MountPropagation is enabled
[INFO]  Checking iscsid...
[INFO]  Checking multipathd...
[INFO]  Checking packages...
[INFO]  Checking nfs client...
[INFO]  Checking x86-64 SSE4.2 instruction set...
[INFO]  Checking nvme-cli...
[INFO]  Checking kernel module nvme_tcp...
[INFO]  Checking kernel module uio_pci_generic...
[INFO]  Checking hugepage...
[INFO]  Cleaning up longhorn-environment-check pods...
[INFO]  Cleanup completed.

ARM64
[INFO]  Required dependencies 'kubectl jq mktemp' are installed.
[INFO]  All nodes have unique hostnames.
[INFO]  Waiting for longhorn-environment-check pods to become ready (0/3)...
[INFO]  All longhorn-environment-check pods are ready (3/3).
[INFO]  MountPropagation is enabled
[INFO]  Checking iscsid...
[INFO]  Checking multipathd...
[INFO]  Checking packages...
[INFO]  Checking nfs client...
[INFO]  Checking x86-64 SSE4.2 instruction set...
[WARN]  Skip SSE4.2 instruction set check on node ip-172-31-17-204 because it is not x86_64
[WARN]  Skip SSE4.2 instruction set check on node ip-172-31-31-34 because it is not x86_64
[WARN]  Skip SSE4.2 instruction set check on node ip-172-31-19-50 because it is not x86_64
[INFO]  Checking nvme-cli...
[INFO]  Checking kernel module nvme_tcp...
[INFO]  Checking kernel module uio_pci_generic...
[INFO]  Checking hugepage...
[INFO]  Cleaning up longhorn-environment-check pods...
[INFO]  Cleanup completed.


Error => Could not find module with name '@electron-forge/maker-squirrel'

Pre-flight checklist

[X] I have read the contribution documentation for this project.
[X] I agree to follow the code of conduct that this project uses.
[X] I have searched the issue tracker for a bug that matches the one I want to file, without success.

Electron Forge version
7.2.0
Electron version
18.3.15
Operating system
Windows 10
Last known working Electron Forge version
No response
Expected behavior
"npm run make" should run without errors
Actual behavior
Error with lastest version and after some research since v6.0.0-beta.55
=> Could not find module with name '@electron-forge/maker-squirrel'
with Version v6.0.0-beta.33 => maker.ensureExternalBinariesExist is not a function
with Version v6.0.0-beta.54 => maker.clone is not a function
Steps to reproduce
must be a problem of my "code" or PC
because other people seems not to have that problem
Additional information
which change in the code between beta54 and beta55 could be responsible for the "could not find module" problem??

Can you share your package.json and forge.config?

files.zip
@erikian here the 2 files
and I only added the dependency for pdf viewer
the rest is original from the electron example app and the forge commands ...

any one found a fix for this?


New Dockerfile wit Python3.8 and PyInstaller4.9

For the report: I just used this with success. I think it should be merged.


Question/Docs/Readme: how do packs fit into things?

I'm not sure if this is the right place to post this (please close this issue if it's out of place) but after walking through the Readme, Topshot contract, and Market contract, it's not clear to me how/where packs are implemented. Since this is a core aspect of NBA topshots I thought it might make sense to shed more light on them in the readme, but I definitely could be wrong, I'm just getting into things.
Are moments minted before a pack actually sells? Or does purchasing a pack trigger a random selection of moments to be minted?
Does the process of buying a pack fall under the Topshot Market contract (ie would Market.MomentPurchase events include pack purchases?)
I did see one of the lib/go files, there was a reference to PackNFT, but I couldn't find any references to PackNFT anywhere else.

Hello Renschler. Thanks for posting this issue. Packs are off-chain in NBA Top Shot. I will update the readme with this info, but let me answer your questions specifically. NFL-All-Day did an onchain pack implementation if you are looking for a reference.
Are moments minted before a pack actually sells? Or does purchasing a pack trigger a random selection of moments to be minted?
Moments are minted prior to the pack sale. They are not minted on-demand. The packing process randomizes moments into packs. The purchase path randomizes which pack a collector receives when they purchase.
Does the process of buying a pack fall under the Topshot Market contract (ie would Market.MomentPurchase events include pack purchases?)
Packs are entirely off-chain on NBA Top Shot. They are a collection of moments which are on-chain.
I did see one of the lib/go files, there was a reference to PackNFT, but I couldn't find any references to PackNFT anywhere else.
I will take a look at this, am not familiar off the top of my head. We have experimented with on-chain packs, but this experimentation has yet to make its way into product.

thanks @HouseOfHufflepuff


Fixing RealWorldFilesIT (#132)

Fixes https://github.com/disq-bio/disq/issues/132
There was a bug in BcftoolsTestUtil which counted empty vcfs as having 1 record.
An empty vcf was added to the GATK test files which we test against which then caused our tests to fail.
This fixes the problem by correctly counting empty vcfs as having 0 records when testing with Bcftools.

@heuermh This should fix the failure in master.

Ok.. this time I must have done everything right...

Good catch, @lbergelson!


proposal: chans: new package with chans.Seq

Proposal Details
#61899 would add iteration related functions to slices, and #61900 does the same for maps. There should also be a package with channel iteration helpers. I propose adding package chans with chans.Seq:
package chans

import "iter"

// Seq returns an iterator that yields the values of ch until it is closed.
func Seq[T any](ch <-chan T) iter.Seq[T] {
    return func(yield func(T) bool) {
        for v := range ch {
            if !yield(v) {
                return
            }
        }
    }
}

An example use would be s := slices.Collect(chans.Seq(ch)) as a convenient way to collect all values from a channel into a slice.

 To supplement the simpler OfChan() function that it provides that does this, I also added a RecvContext() function that can use a context to cancel the iterator, as well as a SendContext() function that does the same in reverse, sending sequence values to a channel until a context is canceled.

chans.Seq seems definitely necessary. I was thinking we might also want the reverse, which would be like SendContext minus the context part. Putting it together, maybe it should be these four functions to start with:
func Seq[T any](<-chan T) iter.Seq[T]
func SeqContext[T any](context.Context, <-chan T) iter.Seq[T]
func FromSeq[T any](iter.Seq[T]) <-chan T
func FromSeqContext[T any](context.Context, iter.Seq[T]) <-chan T

There was also talk about having helpers like FanIn and FanOut back when generics were still experimental, but those can be a separate proposal.

FromSeq() is wrong. It should be
func FromSeq[T any](chan<- T, iter.Seq[T])

rather than returning a channel.

That makes sense. You can reuse an existing channel and you get better type inference.

Other names for chans.FromSeq[Context] might be chans.Send or chans.Copy.

For the two variants that take a context.Context:
I'm accustomed to seeing functions that take a context return an error because an operation being cancelled (or, equivalently, hitting a deadline) is usually modeled as a kind of failure. These functions don't do that, and of course they cannot because the current iterator design only supports infallible iterators.
I can imagine having the caller use ctx.Err() once the iterator stops yielding to see if the iteration might have been terminated early due to cancellation or deadline. It presumably can't know for sure, because the cancellation might have happened between the last call to the iterator and the ctx.Err() call. That edge case probably doesn't matter in practical programs.
s := slices.Collect(chans.SeqContext(ctx, ch))
if ctx.Err() != nil {
    // s may not be complete, then
}

Overall this reminds me of the bufio.Scanner design where users are expected to call Err on the scanner after Scan returns false, to distinguish between a successful full scan vs. early termination due to an error. I remember in one of the earlier iterator proposals some participants worrying that this design was easy to accidentally use incorrectly. That concern would presumably apply to this situation too.
Overall I don't feel super worried about either of these details myself. They certainly don't seem disqualifying, and I raise them largely just for the sake of discussion.
(The non-context versions seem uncontroversial to me; they are pretty obvious implications of the iterators design.)

You could have func SeqContext(context.Context, <-chan T) iter.Seq2[T, error] return the ctx.Err().

func FromSeqContext(context.Context, iter.Seq[T], chan<- T) error is possible, too.

Just a note that the main reason I haven't proposed a chans package is exactly the question of how to handle contexts.

How about treating contexts like log/slog did? That would be most consistent and easy to teach.

How about treating contexts like log/slog did? That would be most consistent and easy to teach.

Where slog evolved to omit contexts, I'm not sure the lessons analogize well with iterators; it contrasts with other places the standard library includes contexts.
slogexplored a number of approaches with contexts and eventually decided to maximally push the complexity out. Contexts are in theHandlerinterface, but are never observed inslog`'s implementations - neither for control flow nor as value stores. The driving questions concerned contexts as value stores, rather than contexts as cancellation in control flows.
Where contexts are used elsewhere in the standard library tends to be domain-specific: net dialing, database/sql queries, http requests, os/exec commands, trace regions and tasks, etc. In each of these cases, there is a pretty useful notion of cancellation that arises in solutions for the domain.
There's undoubtedly a useful notion of cancellation here with chans; also I wonder how often we'd have a more domain-specific iterator, e.g. over the results of a database query, that doesn't already have context cancellation baked in.

To get around having a dependency on context, there could be variants that take <-chan struct{} as a cancel channel. It could also be made generic against <-chan struct{} and <-chan time.Time, so it could accept a time.Timer.C.

You could have func SeqContext(context.Context, <-chan T) iter.Seq2[T, error] return the ctx.Err() as the second iterator parameter.

This is my favorite proposal. What are the arguments against it?


Payment -The error is displayed in English after changing the account language to Spanish

If you haven’t already, check out our contributing guidelines for onboarding and email<EMAIL_ADDRESS>to request to join our Slack channel!

Action Performed:
Precondition: The account language should be changed to Spanish and the account must have minimum 2 payment methods

Go to URL https://staging.new.expensify.com/
Login with any account
Go to Settings -> Payment
Click on the bank account that doesn't have the "default" label
Enter a incorrect password and confirm

Expected Result:
The error message is displayed in Spanish
Actual Result:
The error is displayed in English after changing the account language to Spanish
Workaround:
Unknown
Platforms:

Which of our officially supported platforms is this issue occurring on?

[ ] Android / native
[ ] Android / Chrome
[ ] iOS / native
[ ] iOS / Safari
[ ] MacOS / Chrome / Safari
[ ] MacOS / Desktop

Version Number: <IP_ADDRESS>
Reproducible in staging?: Yes
Reproducible in production?: Yes
Email or phone of affected tester (no customers):
Logs: https://stackoverflow.com/c/expensify/questions/4856
Notes/Photos/Videos: Any additional supporting documentation|

https://user-images.githubusercontent.com/93399543/210386975-90b6ace0-407e-4e36-83a7-431590786760.mp4
Expensify/Expensify Issue URL:
Issue reported by: Applause - Internal Team
Slack conversation:
View all open jobs on GitHub

This is because that error message isn't a localized error message generated in the front-end; rather it is actually returned from the back-end here. We actually have a number of error messages that are the same that we're not fixing since IIRC we're not supporting localization anymore.
Gonna confirm once more in Slack, but I think we should be good to close this out.

Got confirmation that we can close this out!


Adafruit NXP Precision Support

Relying solely on gyro is not recommended due to excess drift (Unsure if this is fixable)

Clarification on proper formatting?

I'd prefer if you actually spelled out Adafruit in the sensor and class name.

Updated formatting


how is the perfermance when inference？if it cost much time, may a smaller model reach a good result?

We haven't benchmarked inference time since it depends on the hardware used (especially CPU vs. GPU vs. TPU), as well as a lot of other factors (batch size, sequence length, etc).
Our primary focus has been maximizing accuracy, with the idea that other techniques (such as Knowledge Distillation/semi-supervised learning) can be used when it's time to create a production model.
We show in the Table 6 of the paper that smaller models do significantly worse. For example, a 6-layer version of BERT loses about 3% absolute compared to the 12-layer version, and 5% compared to the 24-layer version on MultiNLI. Of course, the inference speed of the 6-layer version will be about 2x faster than the 12-layer version.
I could upload some of the smaller models (e.g., the 3-layer and 6-layer models from the paper), but this would be English-only.
My suggestion would be to run speed benchmarks in TensorFlow (which you can approximate by just creating a new BertModel creating a loop to feed it fake data), and then train the largest model that runs in a time you find acceptable on the hardware you plan to use.

@jacobdevlin-google please upload these smaller models 👍 , that would help a lot in comparing inference time by our side. Thanks a lot.

For extracting features, I'm getting 75 samples/s on Tesla M40 24GB with BERT pretrained-Chinese model (12 Layers, max_seq_len=200, batch_size=256)
Surely not fast enough for production.

@elyase @loretoparisi I optimized the feature extraction part and wrapped it into a standalone service. On single Tesla M40 24GB with BERT pretrained-Chinese model (12 Layers, max_seq_len=40), the speed is ~2000sample/s
please check it out: https://github.com/hanxiao/bert-as-service

@hanxiao that's amazing! can't wait to try it out.

@hanxiao that looks great! What speed do you get with batch_size = 1?

@hanxiao , just had it chance to try it myself. On a V100, inference with one sample at a time I am getting 135 samples / s which is a lot faster than what I got with the Pytorch version. Is not exactly the same test as I was testing a classifier (so a couple more ops) but still it doesn't explain the big difference. On closer look I think I made mistake and didn't use torch.no_grad() in my benchmark. Gotta repeat the tests and post if I find something.

Hi there, I am trying to use pretrained multilingual model. in modeling function I send is_training=False. So it didn't take that much memory from GPU. But While running the code bert is taking a lot of memory. Last I checked I used google cloud 50 GB RAM with 16 CPU and 16 GB V100 GPU and failed.   I there anything I am doing wrong. Note though BERT model is not trainable, I have sent BERT representation to an LSTM which is pretty small.
@hanxiao @loretoparisi

Update: At first I was using  tf1.5. After updating to tf1.12 the problem solves.


Core :: Read secrets from a volume and not from Env Var

Goal
Mount secrets in core services as volume instead of Env Var.
Technical details
From #9327, we have several core services that mount secrets as EnvVars.
We should switch to mount them as Volume since env var are prone to be printed and could leak important data.
K8s doc: https://kubernetes.io/docs/concepts/configuration/secret/#using-secrets-as-files-from-a-pod

Hello @thisthat , Can you please assign me this issue !!

Hey @lavakush07 thanks! I've assigned to you🚀


lodash: changed _.chunk() method

https://lodash.com/docs#chunk
https://lodash.com/docs#_ (description of the chainable wrapper)

thanks mate!


Difference between AnimateDiff and Hotshot

Hi, thanks for sharing this great work. I just wonder what the difference is between AnimateDiff and Hotshot. Both models train a temporal attention module and freeze the original SD. It seems that the training pipeline shares a lot of similarities.

Hi!
In terms of OS t2v models, Modelscope, AnimateDiff, & Hotshot are all using a double self attention architecture. Modelscope is trained as a full text-to-video model, AnimateDiff & Hotshot are built on top of text-to-image models because those are already trained on billions of images + a video is just a series of images. Building on top of existing text-to-image models is advantageous because it's super hard to find/create good video data & HQ image data is much more abundant for all the world's different concepts/language. You can read more about another approach to building on top of a t2i model here: https://arxiv.org/abs/2304.08818
AnimateDiff is a model trained from scratch based on SD 1.5
Hotshot is a different model trained from scratch based on SDXL
AnimateDiff was trained on a dataset called webvid from Shutterstock (lots of slow motion stock video + full shutterstock watermarks)
Hotshot was trained on a different dataset. IMO, in conjunction w SDXL this is what makes the motion/language understanding much better


Consider returning to 1.63.0 MSRV

Recently, ahash bumped their MSRV to 1.72.0 in a patch release, which is really unfortunate.
It seems that hashbrown followed a similar pattern in #502 and silently bumped the rustc version in CI to 1.72.0.
Rather than also bumping MSRV (let alone in a patch release), it would be great if hashbrown could revert to a 1.63.0 MSRV, find a workaround, and make recommendations to downstream users that may or may not pin the violating ahash dependency.
It would be great if this path could at least be considered.

There's nothing that can be done in hashbrown itself, only in ahash. You could try submitting a PR to restore 1.63 compatibility there by using a build script to detect the rustc version.


Merge current v0.3.0-alpha branch into master

There have been major changes to the release branch, merging early/often will make sure our work on master doesn't get disrupted.

Note I'm not deleting the release branch after this - just keeping master up to date with the fixes

I checked the PR numbers and not the contents and this looks correct. It's more complicated as we have merges going in both directions. In future, I don't think we should branch until we believe we're absolutely done.

LGTM

Yes, you're right about branching late.
We do need to think about what to do with features we don't want in the release though...


Metadata API: Remove Signed.bump_expiration() method

Fixes #1727
Description of the changes being introduced by the pull request:
Remove bump_expiration() method, which is unlikely to be used as is, i.e. bump to "current expiration date plus delta". A more realistic use case is to bump to "now plus delta" (see #1727 for details).
Moreover, bump_expiration can either way easily be replaced by a one-liner expression using the 'datetime' module. A corresponding code snippet is added to the expires property's docstring.
Note: expires became a property with a millisec-removing setter (for spec conformance) in  #1712, which further reduces the need for a convenience bump_expiration method.
This patch also

removes a related unit test and updates another one, and
updates rtd/sphinx config to display inherited members, most notably the expires property with said code snippet (see e.g. Root.expires)

Please verify and check that the pull request fulfills the following
requirements:

[ ] The code follows the Code Style Guidelines
[ ] Tests have been added for the bug fix or new feature
[ ] Docs have been added for the bug fix or new feature

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

1 of 1 (100.0%)  changed or added relevant line in 1 file are covered.
No unchanged relevant lines lost coverage.
Overall coverage decreased (-0.0008%) to 97.701%

Totals

Change from base Build<PHONE_NUMBER>:
-0.0008%

Covered Lines:
4093

Relevant Lines:
4173

💛  - Coveralls


ROS message type "std_msgs/String" has no field named "StrSys"

ROS message type "std_msgs/String" has no field named "StrSys"
But I can't find "StrSys" on the Internet

You're probably trying to convert a dictionary that has the key StrSys into a ROS message of type std_msgs/String. As the error message already says, this will not work. Your dictionary should only have the field data:
http://docs.ros.org/en/noetic/api/std_msgs/html/msg/String.html


Prevent miss sounds from playing when rewinding

https://github.com/TeamFluXis/fluXis/assets/75596775/8abaa64f-4916-40ed-84b2-15fe5a548ef2
Volume Warning!

Fixed with f65defc


LPAL-21 Zend to Laminas upgrade

Purpose
LPAL-21 Upgrade zend to laminas
Approach

Ran the automatic migration script from Zend to Laminas.
In composer.json for the various components, Changed php to 7.4 upgraded a handful of components missed by the migrator, brought versions more up to date and closer to Use's version, added the zend-laminas-bridge component which maps namespaces.
ZfcRbac was renamed to LmcRbacMvc, so updated many files by hand to reflect this.
Twig components were renamed.
Had to isolate some Twig code which didn't play well wth Mockery due to a class declared as final
ZendPdf is left at original version because this is the one that currently works with this setup.

_
Learning
Any tips and tricks, blog posts or tools which helped you. Plus anything notable you've discovered about the LPA service
Checklist

[x] I have performed a self-review of my own code
[ ] I have updated documentation (Confluence/GitHub wiki/tech debt doc) where relevant
[ ] I have added tests to prove my work
[ ] The product team have tested these changes

🏆  🎖 🥇


Error: group Root in path Root/test/test not found

Hi I keep getting the error: Error: group Root in path Root/test/test not found, although the correct database structure is there. One thing to note, I created my database in Windows 10 and now I am trying to run terraform on it using a remote linux server. Is there any way to see which path list that the keepass provider understands?
I am using the example in the terraform/github docs
data "keepass_entry" "test" {
  path = "Root/test/test"
}

Any idea what the issue could be?

Hi, sorry for the late response.
In your screenshot the test entry is directly in Root, not in the test directory.
So the correct path should be "Root/test"


fix: Additional focus border displays on range filters in staging (#2069)

Reviewers
Functional:
@tihuan

Changes

Removal of focus border display on range filter.

Good news, @frano-m !
We can just change focus to focus-visible 🚀 !
https://css-tricks.com/keyboard-only-focus-styles/
SDS example: https://github.com/chanzuckerberg/sci-components/pull/137/files
Thanks so much 😄 !

Hey @tihuan that's a great suggestion (I'll pocket that for another time)! It looks like Mui Slider already has an equivalent classname focusVisible for keyboard interaction. The style applied when using the keyboard is a box-shadow. Here is a video of the interaction. The :focus css rule in my PR does not affect this keyboard focus style (because I've targeted the outline style). @tihuan are you ok to proceed with the interaction as per the video?

Ooh that's a great point! Yeah if there's already focus-visible style in place then nuking focus outlines SGTM! Thank you!!


[ErrorException] symlink(): File exists

I'm trying to set this up and I'm getting the following error:
[ErrorException]
 symlink(): File exists

The package is actually downloaded and placed in the vendor-shared folder.
This is my composer.json:
{
  "name": "website/test",
  "description": "xxxx",
  "license": "proprietary",
  "min-stability": "dev",

  "require-dev": {
    "raulferras/sepia": "dev-feature/sepia6",
    "letudiant/composer-shared-package-plugin": "2.0.0"
  },

  "extra": {
    "shared-package": {
      "vendor-dir": "vendor-shared",
      "package-list": [
        "raulferras/sepia"
      ]
    }
  },
  "repositories": [
    {
      "type": "vcs",
      "url": "xxxxxxxxxxxx.git"
    }
  ]
}

Nevermind, I miss read documentation.
The problem was I was specifying the same path this plugin uses to create symlink for downloading shared packages.
{
  "name": "website/test",
  "description": "xxxx",
  "license": "proprietary",
  "min-stability": "dev",

  "require-dev": {
    "raulferras/sepia": "dev-feature/sepia6",
    "letudiant/composer-shared-package-plugin": "2.0.0"
  },

  "extra": {
    "shared-package": {
      "vendor-dir": "../vendor-shared",
      "package-list": [
        "raulferras/sepia"
      ]
    }
  },
  "repositories": [
    {
      "type": "vcs",
      "url": "xxxxxxxxxxxx.git"
    }
  ]
}

See https://github.com/Letudiant/composer-shared-package-plugin/blob/master/docs/all-available-configurations.md for more options.


How can I disable the "X" button from close the window?

This is the button I want to disable
this button, print: http://prntscr.com/odr94p

To clarify, do you want to hide the button completely, change its appearance (e.g. grey tint), or simply ignore the user's request to close the window?

@Tenebroso1337 Can this issue be closed? You can try asking over on the forums https://discourse.glfw.org/.


GH-3010 improve binary rdf format

GitHub issue resolved: #3010
Briefly describe the changes proposed in this PR:
Added a parser and writer second version of the binary RDF format with backwards compatibility with version 1. Notable changes in this version are the default use of UTF-8, variable length integers for string lengths and value identifiers and a larger default statement queue.

PR Author Checklist (see the contributor guidelines for more details):

[x] my pull request is self-contained
[x] I've added tests for the changes I made
[x] I've applied code formatting (you can use mvn process-resources to format from the command line)
[x] I've squashed my commits where necessary
[x] every commit message starts with the issue number (GH-xxxx) followed by a meaningful description of the change

Note that tests for V1 compatibility are missing.

This is looking really good @frensjan , thanks! I've got some comments on a first read-through, most of it is small things / organizational stuff though.

Thanks @jeenbroekstra. I'll dig into your comments!

The build is failing on a perceived incompatibility - I think I may have overlooked one of our build plugins (animal-sniffer) when updating our minimal Java version. I'll take a look and fix.

@frensjan the develop branch has been updated with some tweaks to the build plugins. Could you rebase this so we check that it now passes?

Could you rebase this

Done. I don't I can trigger builds, right?

Could you rebase this

Done. I don't I can trigger builds, right?

Yeah that's a new thing with GitHub. I've started it for you though, and once you have at least one PR merged any following ones should automatically go through

Thanks for the fix on develop @jeenbroekstra, all checks have now passed.
Let me know if there are any issues you want resolved / desirable changes to be made.

Thanks @jeenbroekstra, good to contribute here.


Add edit mode instructions for autocomplection & more

Could be based on swift-sh edit, which didn't work for me on first try though. More investigation needed.

Dropping in favor of #39.


refactoring of CIVL refinement code

This PR refactors the file CivlRefinement.cs into a collection of smaller files.

split out the instrumentation for refinement checking and yield checking into separate classes.
split out the transformation of an implementation into a separate file.
Extraneous "using" clauses are deleted in a few other files.

I have done the renaming.


[WIP] Fix the worker hang issue

Fixes #13255

Codecov Report

Merging #13282 (ffdd20e) into master (6f18745) will decrease coverage by 26.51%.
The diff coverage is 0.00%.

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

WIP again, thinking that we should only have one blockreader for reading chunks inside one thread. That reader should be in factory level instead of creating one for reading each chunk

@apc999 Move the createBlockReader back to factory, PTAL.
I am considering should we reuse the blockReader for all readChunks?
Otherwise we keep creating new BlockReader for each  readChunk

@apc999 Added the unit test for BlockWorkerDataReader, cover the close() and general readChunk(), PTAL, thanks!

Addressed the comments, PTAL, thanks! @apc999

How about creating a DefaultBlockWorker instance, and pass it to  BlockWorkerDataReader.Factory. in order to do so, you probably need to make this test class in core/server/worker module rather than core/client/fs module.  To setup a instance  of DefaultBlockWorker, you can check out alluxio/worker/block/DefaultBlockWorkerTest.java
After having a real and working DefaultBlockWorker, you can simply check basic behavior, as well as creating/destroying BlockWorkerDataReader and make sure it is not hanging.

For the test side, we want to avoid things like the bug happening again. The best practice is adding a test similar to the bug behavior. Like using actual Fuse on worker and read data through the mount point. I will add this part in our AbstractFuseIntegrationTest. In this way, we don't test any internal logics but test the desire behavior we want.
I couldn't think of a good way to do what we want to test in unit test without touching internal logics.
Our DefaultBlockWorkerTest is a disaster.... it internally contains a lot of PowerMockito logics. So it's not a real DefaultBlockWorker. It uses the Mockito.spy(BlockStore) so it will not reach the actually code to create 1000 block read locks.
Agree that i change the MockIito.mock(BlockWorker.class) to a class extending NoopBlockWorker.

Changed Mockito.mock(BlockWorker) to use MockBlockWorker extends NoopBlockWorker.
WIP adding integration test for reading large files with WorkerFuse

alluxio-bot, merge this please


Build and test project with GitHub actions

Configures the default GitHub actions Maven workflow

You can check the Checks tab above between Commits and Files changed


How to detect other objects by using DetectNet

Hello,
I want to use DetectNet to detect my own objects like animals (cats, dogs, horses ...)
Is it possible to define labels for my objects and change the class mapping table for my object-detection task ?
Thanks,

Sure, refer to this section of the doc:
https://github.com/NVIDIA/DIGITS/tree/digits-5.0/digits/extensions/data/objectDetection#custom-class-mappings

Oh, I see the "Custom class" field, I will try it later.
Thanks a lot~!!!


Automatically Create Homebrew-Cask Bump PR on Release

This potentially uses GitHub Actions to automatically create a bump PR on
the Cask whenever we push a new semantic version tag.
It's currently untested and is meant mainly to ask for feedback on whether
it's desired or not.
Thoughts?
Related:

https://github.com/Homebrew/homebrew-cask/pull/121662/
https://github.com/quicksilver/Quicksilver/issues/2727

Thanks for bringing up the conversation! I've been using homebrew for a long time. I'm a little on the fence about this.
QS has its own update mechanism; aside from the recent <2.0.3 update glitch, it's worked well for a long time. Even if the brew-available version lags, QS should prompt them to update with minimal hassle.
https://github.com/dawidd6/action-homebrew-bump-formula seems to have a pretty low bus factor, and looks like the only commit in the last year was a README update; perhaps that's because it's stable and doesn't need anything, but it would be silly if it became unmaintained in 6 months and we just removed this process (and risk breaking workflows people had built around it in the meantime).
I don't really want to commit to maintaining a tap under the QS org; it looks like one can remove all of the Optional configuration and have it just submit a PR to homebrew/core? Is that your understanding?
Most of the work seems to be automated, which is great, not a huge loss if it doesn't work out, add some convenience for homebrew users if it does. If we merged this and the Actions dependency subsequently breaks or is deprecated, I'd probably recommend ripping it out over fixing it.
Strong feelings either way @skurfer @pjrobertson ?

Homebrew shouldn't replace our built-in updater, that's for sure. We need the ability to send out developer, pre-release and release builds, and a way for non-tech-savvy users to update.
I'm fine with us 'bumping' the homebrew project when we make a new release - like a notification. But as @n8henrie said - we unfortunately don't have the capacity to maintain it ourselves.
If all this PR is doing is making that 'bump', and not expecting anything else, then I'm fine with this being merged.
My only other concern is that we give the homebrew guys too much noise as we create/delete tags.

SGTM

I don't really want to commit to maintaining a tap under the QS org; it looks like one can remove all of the Optional configuration and have it just submit a PR to homebrew/core? Is that your understanding?

@timvisher if confirmed, would you mind removing all the optional config, and I'll figure out adding an access token.

custom GitHub access token with the 'public_repo' and 'workflow' scopes

I don't see an option for access tokens at the organization level; should this be an access token generated from my personal account? (https://github.com/settings/tokens)

bump @timvisher

@n8henrie Thanks for the bump. This is in my todo list and I do really want to get to it but I've got a lot going on at the moment. If you'd like we can just close it and I'll reopen if I find a few spare cycles or we can leave it open. Sorry it's taking me so long. :\


Adding polling to all node readiness

#10622
cc @quinton-hoole

From the current PR builder running right now:
INFO: Waiting up to 1m0s for all nodes to be ready
INFO: Node pull-e2e-3-minion-pwnk condition 1/1: type: Ready, status: True, reason: "kubelet is posting ready status", message: "", last transistion time: 2015-07-09 11:47:34 -0700 PDT
INFO: Successfully found node pull-e2e-3-minion-pwnk readiness to be true
INFO: Node pull-e2e-3-minion-zlm9 condition 1/1: type: Ready, status: True, reason: "kubelet is posting ready status", message: "", last transistion time: 2015-07-09 11:47:34 -0700 PDT
INFO: Successfully found node pull-e2e-3-minion-zlm9 readiness to be true

LGTM.

Fixes #10622

LGTM barring comments.  Let me know when addressed, and we can mark ok-to-merge.

Oh, and we'll want a clean Jenkins e2e test run before merging.

@quinton-hoole
The e2e did pass, but it failed to upload the test artifacts. heh...

SUCCESS! -- 54 Passed | 0 Failed | 2 Pending | 41 Skipped

@k8s-bot test this please
Another timeout

@quinton-hoole Please take another look

LGTM.  ok-to-merge.
This is exclusively test code.

Flake averted on job 3124 on e2e-gce-parallel:
INFO: Waiting up to 1m0s for all nodes to be ready
INFO: Node e2e-test-parallel-minion-iqg7 condition 1/1: type: Ready, status: False, reason: "network not configured correctly", message: "", last transistion time: 2015-07-09 16:03:37 -0700 PDT
... snip ...
INFO: Node e2e-test-parallel-minion-iqg7 condition 1/1: type: Ready, status: True, reason: "kubelet is posting ready status", message: "", last transistion time: 2015-07-09 16:04:08 -0700 PDT
INFO: Successfully found node e2e-test-parallel-minion-iqg7 readiness to be true


Visual selection is almost invisible

In the screenshot the first offset is visually selected.  However it's almost impossible to see.

Please could you make it clearer?

Would you tell me your environment (OS, Vim version, terminal, etc.)?
Here is selection in my environment and it seems to be clearer:

OS: macOS 10.12.4
Vim: MacVim 8.0.596 (KaoriYa 20170512)

OS X 10.11.6
MacVim 8.0.586  via Homebrew

Sorry for the late reply :bow:
Hmm, I checked it in my several environments and displays but I can see the selection clearly. It seems to be caused by your environment... You can make it clearer by editing the line of iceberg.vim/colors/iceberg.vim:
hi! Visual ctermbg=236 guibg=#363d5c

Ah, thank you.  I checked my vimrc and realised I had hi! link Visual CursorLine which I added for solarized-dark.  Commenting that out made all the difference.
Thanks!

Oh, I didn't notice the cause. Thank you for your report!

hi! Visual ctermbg=236 guibg=#363d5c
Can we make this default? On my macOS 10.15.6 (alacritty terminal) I can barely see the visual as well and I don't override anything in the color scheme.

You can add the line to your .vimrc like this:
colorscheme iceberg

" Mofify color definitions after setting color scheme
hi Visual ctermbg=236 guibg=#363d5c

I realize this issue is closed, but IMO the above should be the default -- the current selection background is almost imperceptible.


Retrieve dict of branch names and types for an existing tree

Basically, I'd like to use uproot to copy TTrees, because I have some TTrees that are each one giant cluster, and I'd like to split them into multiple clusters.
To create a new tree with the same branches as an existing one, a TTreeMethods method that provided the branch dict needed would be helpful.

That would be a good convenience function. Since Uproot can only write non-jagged numeric type branches, should such a function skip or complain about branches that don't fit that description?

I would go with warn and skip as a default, with the ability to choose to make it an error (as with numerical errors in NumPy, for instance).

How about this (for some TTree named tree; can become self).?
{n: x.interpretation.todtype for n, x in tree.allitems() if isinstance(x.interpretation, uproot.asdtype)}

or
{n: x.interpretation.todtype.type for n, x in tree.allitems() if isinstance(x.interpretation, uproot.asdtype)}

I think that's fine, thanks.

In fact, Uproot 4 has this:
>>> import uproot4
>>> t = uproot4.open("../uproot/tests/samples/sample-6.16.00-uncompressed.root:sample")

>>> t.typenames()
{'n': 'int32_t', 'b': 'bool', 'ab': 'bool[]', 'Ab': 'bool[]', 'i1': 'int8_t', 'ai1': 'int8_t[]', 'Ai1': 'int8_t[]', 'u1': 'uint8_t', 'au1': 'uint8_t[]', 'Au1': 'uint8_t[]', 'i2': 'int16_t', 'ai2': 'int16_t[]', 'Ai2': 'int16_t[]', 'u2': 'uint16_t', 'au2': 'uint16_t[]', 'Au2': 'uint16_t[]', 'i4': 'int32_t', 'ai4': 'int32_t[]', 'Ai4': 'int32_t[]', 'u4': 'uint32_t', 'au4': 'uint32_t[]', 'Au4': 'uint32_t[]', 'i8': 'int64_t', 'ai8': 'int64_t[]', 'Ai8': 'int64_t[]', 'u8': 'uint64_t', 'au8': 'uint64_t[]', 'Au8': 'uint64_t[]', 'f4': 'float', 'af4': 'float[]', 'Af4': 'float[]', 'f8': 'double', 'af8': 'double[]', 'Af8': 'double[]', 'str': 'char*'}

>>> t.typenames(filter_name=["Ai*", "Af*"])
{'Ai1': 'int8_t[]', 'Ai2': 'int16_t[]', 'Ai4': 'int32_t[]', 'Ai8': 'int64_t[]', 'Af4': 'float[]', 'Af8': 'double[]'}

Equivalent to file.classnames(filter_name=...) on TDirectories.


[Registration] Failure to present suggestion of names while the name is typed in

[Actual Outcome]: When the Name is typed in the System is not suggesting possible names that may match the name being typed.
[Expected Outcome]: As the user types in the first name the user is presented with some suggestions that may match the name he/she is typing in.
[Steps to Reproduce]:

Add a New Patient: Registration -> Add New Patient(Click Plus button)
On the Identifier section Fill the NID field and click Next
On the Name section type in the name on the Name field

@ynurmahomed we had this feature working, we borrowed from Bahmni, since that we don't have any bahmni dependency at this point, the feature is not working any more. I think that we have to create our our POC API module and include this service there. Thoughts?

Can we use typeahead and /patient endpoint?


Generate Wavefront Coordinates at __init__ Time.

Hi all,
The wavefront.pixel_coordinates method is regenerating the coordinates grid every time it is accessed. I see no reason we cannot just make the coordinates a property of the wavefront.
Let me know your thoughts,
Jordan

It needs to be generated at run time because the properties of the wavefront change throughout the propagation so the coordinates are changing too.
It similarly prevents cluttering of the wavefront class when examining, and prevents having multiple parameters track the same value (ie pixelscale and npix are entirely equivalent to the coordinate system)

Pain in the arse that.