TypeError: Cannot read properties of undefined (reading 'withConfig')

Environment
System:

OS: macOS 13.2
CPU: (10) arm64 Apple M1 Pro
Memory: 2.16 GB / 32.00 GB
Shell: 5.8.1 - /bin/zsh

Binaries:

Node: 18.13.0 - ~/.nvm/versions/node/v18.13.0/bin/node
Yarn: 3.3.1 - ~/.nvm/versions/node/v18.13.0/bin/yarn
npm: 8.19.3 - ~/.nvm/versions/node/v18.13.0/bin/npm

npmPackages:

styled-components: ^5.3.6 => 5.3.6

Reproduction
I'm making a ui library (including Flex, Stack, etc.) that wraps styled-components called @jsxcss/styled-components. This library works fine with create-react-app.
However, in the Next.js environment, Server Error It doesn't work well with the error TypeError: Cannot read properties of undefined (reading 'withConfig').
This link reproduces this error situation.
You can see the code of @jsxcss/styled-components at this link.

Steps to reproduce

You can clone repository in This link reproduces this error situation.
npm install
npm run dev
check error in http://localhost:3000

Expected Behavior
No server error.
Actual Behavior
Error like that picture

I ran into a very similar issue: theme is undefined but ThemeProvider is definitely being passed a non-empty theme.
In my case, the issue was that ThemeProvider was created in a separate package from where the theme was being referenced, and the packages were using different versions of react-dom!
// package A, using react-dom@18
const App = () => (
  <ThemeProvider theme={theme}>
    <GlobalStyle />

hello

  </ThemeProvider>
);

// package B, using react-dom@17 implicitly
const GlobalStyle = createGlobalStyle`
  body {
    font-family: ${props => props.theme.fontFamily};
  }
`

After explicitly adding react-dom@18 to package B's package.json, the issue was magically fixed.
I'm guessing your issue is somewhat related. Maybe the places where you're setting and referencing the theme have different views of the DOM, or are using different react-dom versions?

@manudeli I see you're using Rollup. I just ran into the same issue with my library while upgrading from Rollup v2 to v3.
In my case I had to add the output.interop option and set it to "auto":
// rollup.config.js
export default {
  // ...
  output: {
    interop: 'auto',
  },
};

@manudeli I see you're using Rollup. I just ran into the same issue with my library while upgrading from Rollup v2 to v3.
In my case I had to add the output.interop option and set it to "auto":
// rollup.config.js
export default {
  // ...
  output: {
    interop: 'auto',
  },
};

They changed some defaults in v3 as outlined in the migration guide. By the way, "compat" also seems to work.

2 days of time wasted only to find this one setting fixed the issues with styled components immediately for nextjs libraries

@manudeli I see you're using Rollup. I just ran into the same issue with my library while upgrading from Rollup v2 to v3.
In my case I had to add the output.interop option and set it to "auto":
// rollup.config.js
export default {
  // ...
  output: {
    interop: 'auto',
  },
};

They changed some defaults in v3 as outlined in the migration guide. By the way, "compat" also seems to work.

I encountered this problem too, but after adding interop: "auto" to the bundle, the changes from babel-plugin-styled-components, which are necessary to support SSR, are no longer made. How did you solve this problem?

I'm having the same problem but only after i upgraded NextJs to 14+, my project is using a ui library built with vite but even after upgrading the vite version and changing the output.interop option to auto it did not fix my problem :(

I have this problem  but i do not use styled-components library

I have a similar issue but not using nextjs
Do I need to set something inside vite.config.mts instead?

Does someone found a solution to this? changing interop does nothing here. I have that problem online in vites SSR build. Not in the website build.

same here! ;(

use import statement as:
import {styled} from styled-components;

use import statement as:
import {styled} from styled-components;

But you dont use Typescript, right?

I just solved this issue a second ago after some days of struggle.
My case:
Built a library with vite, that uses styled-components and a design system lib that also uses styled-components.
What solved for me:
in vite.config.ts

set lib.formats: ['es', 'umd']
set rollupOptions.output.interop: 'auto'

now in package.json:
  "main": "./dist/lib.umd.cjs",
  "types": "./dist/lib.d.ts",
  "exports": {
    ".": {
      "import": "./dist/lib.umd.cjs",
      "require": "./dist/lib.umd.cjs"
    }
  }

use import statement as:
import {styled} from styled-components;

Your approach has indeed solved this problem

I am using vite to build a library with the library-mode and seeing empty theme , similar to above issue.
Dev mode works fine.
Tried all approaches mentioned above but no luck

Uninstall unwanted styling npm packages if you install
For Example : i was using  npm i react-better-carsoule ,
when i uninstall this package then i was able to deploy my website

I am using vite to build a library with the library-mode and seeing empty theme , similar to above issue. Dev mode works fine. Tried all approaches mentioned above but no luck

Same problem using rollup for building a library

I was able to solve it by importing my component dynamically and turning off ssr.
In my case:
My application where I was trying to import a vite built component library is using NextJS version 14 and pages router.
import dynamic from 'next/dynamic';

const Component = dynamic(async () => await import('imported-package'), {
  ssr: false,
});

This comes with the cost of rendering the component on the client instead of course.


quick dirty fix for 32bit darwin

On 32bit darwin the syscall.Keven_t.Ident Field is 32bit and thus needs to be uint32. I expect that this is similarly true for other 32bit systems.
There most likely is a cleaner way to abstract this stuff in the poll package.
See  for more jbenet/go-ipfs#828.

LGTM. i think the test failure is a fluke.

There most likely is a cleaner way to abstract this stuff in the poll package.

agreed. any ideas?


Backup database based on container label instead of image name?

Instead of backup container databases basend on image name add an optional label to add a database to the backup?
There are some database images without the database name like "mysql" in the image name. WOuld be nice to add by label rancher-backup=mysql or something else.

Ok, is a good idea, I will try to enhance with that.
First, check label, then check image name

+1 seems like a good idea

You can now use label backup.type' to discover service to be backuped. First, it search on backup.type` label, then it search on image name.

The tool should at the beginning look for a container with a label backup.type set, i.e. backup.type=mongo, right?
I asking because it does not work as described and the tool tries to backup each of my mongo instances from a shared cluster instead of only from the mongos router with backup.type=mongo label.

From README:

First it search on label called backup.type and if doesn't found, it search on image name.

Right, my containers name contains mongo, but it is strange that the name implies backup.
May backup.type=none should be introduced to omit these containers and be backward compatible.


Run linting task on Travis

We have a linting task that lints JS files as of https://github.com/eslint/eslint.github.io/pull/393, but the task doesn't get run automatically for PRs on Travis. I'm not sure how to do this because we already have the language set to ruby in .travis.yml to index the site with algolia, so we would need to set up a separate build to run npm install and npm test for PRs. Someone who knows more about travis config files might be able to do this.

Found this thread/comment: https://github.com/travis-ci/travis-ci/issues/4090#issuecomment-122688955
Maybe we could just invoke nvm as part of the test script (while still using ruby as the language)?

Do we need the Travis task to be in Ruby anymore if we no longer need to call Algolia directly (since we should have switched over to DocSearch by now)?
(cc @ilyavolodin)

I'll see if I can fix this. Travis has been failing since we turned it on (for reasons unrelated to this) and should be fixed by https://github.com/eslint/eslint.github.io/pull/578.

I think we can close it since we have added a lint job workflow. - https://github.com/eslint/website/blob/master/.github/workflows/ci.yml


Title: Add Area Calculator:

Is your feature request related to a problem? Please describe.
It will calculates the area of the any 2D shapes given for example rectangle , triangle , circle and square.
It will be really useful
Describe the solution you'd like.
I want to make a calculator for this
Describe alternatives you've considered.
I haven't considered any yet.
Add any other context or screenshots about the feature request here.
No response

@Anshika14528 Thank you for providing your insight but it is not required as of now


perf: remove duplicate code snippets in AbstractInterfaceConfig

What is the purpose of the change
remove duplicate code snippets in AbstractInterfaceConfig#postProcessAfterScopeModelChanged()
Brief changelog
From 243-245 line In AbstractInterfaceConfig, this is repeated as above 237-239 line.
So remove duplicate code snippets。
Verifying this change

Checklist

[x] Make sure there is a GitHub_issue field for the change (usually before you start working on it). Trivial changes like typos do not require a GitHub issue. Your pull request should address just this issue, without pulling in other changes - one PR resolves one issue.
[ ] Each commit in the pull request should have a meaningful subject line and body.
[ ] Write a pull request description that is detailed enough to understand what the pull request does, how, and why.
[ ] Check if is necessary to patch to Dubbo 3 if you are work on Dubbo 2.7
[ ] Write necessary unit-test to verify your logic correction, more mock a little better when cross module dependency exist. If the new feature or significant change is committed, please remember to add sample in dubbo samples project.
[ ] Add some description to dubbo-website project if you are requesting to add a feature.
[ ] GitHub Actions works fine on your own branch.
[ ] If this contribution is large, please follow the Software Donation Guide.

Codecov Report

Merging #10329 (1ef2a48) into 3.1 (3930843) will decrease coverage by 0.68%.
The diff coverage is n/a.

@@             Coverage Diff              @@
##                3.1   #10329      +/-   ##
============================================
- Coverage     65.57%   64.89%   -0.69%
+ Complexity      319      296      -23
============================================
  Files          1243     1243
  Lines         54186    54177       -9
  Branches       8186     8158      -28
============================================
- Hits          35533    35158     -375
- Misses        14791    15152     +361
- Partials       3862     3867       +5

Impacted Files
Coverage Δ

...g/apache/dubbo/config/AbstractInterfaceConfig.java
80.25% <ø> (+0.50%)
:arrow_up:

...luster/router/script/ScriptStateRouterFactory.java
0.00% <0.00%> (-100.00%)
:arrow_down:

...zookeeper/curator/CuratorZookeeperTransporter.java
0.00% <0.00%> (-100.00%)
:arrow_down:

.../serialize/hessian2/Hessian2SerializerFactory.java
0.00% <0.00%> (-100.00%)
:arrow_down:

...sian2/dubbo/DefaultHessian2FactoryInitializer.java
0.00% <0.00%> (-100.00%)
:arrow_down:

...pc/cluster/router/file/FileStateRouterFactory.java
0.00% <0.00%> (-80.96%)
:arrow_down:

...o/rpc/cluster/router/script/ScriptStateRouter.java
0.00% <0.00%> (-67.31%)
:arrow_down:

...ian2/dubbo/AbstractHessian2FactoryInitializer.java
0.00% <0.00%> (-61.12%)
:arrow_down:

...ize/hessian2/dubbo/Hessian2FactoryInitializer.java
0.00% <0.00%> (-60.00%)
:arrow_down:

...ting/zookeeper/curator/CuratorZookeeperClient.java
15.72% <0.00%> (-56.34%)
:arrow_down:

... and 78 more

Continue to review full report at Codecov.

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


⚠ API (search) has degraded performance

In 37539b6, API (search) (https://api.dev.package-search.services.jetbrains.com/search-packages) experienced degraded performance:

HTTP code: 200
Response time: 8076 ms

Resolved: API (search) performance has improved in 2587914 after 14 minutes.


 Adding a bit of tracing logs to ops.Update, this seems a real bug rather than a test flake (note that the last write operation which shouldn't have occurred based on the test definition):
...
msg="Read sysctl /proc/sys/net/ipv6/conf/all/forwarding: 0 - expected: 1" subsys=sysctl-test sysParamName=net.ipv6.conf.all.forwarding sysParamValue=1
msg="Writing sysctl /proc/sys/net/ipv6/conf/all/forwarding to 1 (read: 0)" subsys=sysctl-test sysParamName=net.ipv6.conf.all.forwarding sysParamValue=1
msg="Read sysctl /proc/sys/net/ipv4/ip_forward: 1 - expected: 2" subsys=sysctl-test sysParamName=net.ipv4.ip_forward sysParamValue=2
msg="Writing sysctl /proc/sys/net/ipv4/ip_forward to 2 (read: 1)" subsys=sysctl-test sysParamName=net.ipv4.ip_forward sysParamValue=2
msg="Read sysctl /proc/sys/net/ipv4/conf/all/forwarding: 1 - expected: 2" subsys=sysctl-test sysParamName=net.ipv4.conf.all.forwarding sysParamValue=2
msg="Writing sysctl /proc/sys/net/ipv4/conf/all/forwarding to 2 (read: 1)" subsys=sysctl-test sysParamName=net.ipv4.conf.all.forwarding sysParamValue=2
msg="Read sysctl /proc/sys/net/ipv6/conf/all/forwarding: 1 - expected: 2" subsys=sysctl-test sysParamName=net.ipv6.conf.all.forwarding sysParamValue=2
msg="Writing sysctl /proc/sys/net/ipv6/conf/all/forwarding to 2 (read: 1)" subsys=sysctl-test sysParamName=net.ipv6.conf.all.forwarding sysParamValue=2
msg="Read sysctl /proc/sys/net/ipv4/conf/all/forwarding: 2 - expected: 1" subsys=sysctl-test sysParamName=net.ipv4.conf.all.forwarding sysParamValue=1
msg="Writing sysctl /proc/sys/net/ipv4/conf/all/forwarding to 1 (read: 2)" subsys=sysctl-test sysParamName=net.ipv4.conf.all.forwarding sysParamValue=1

/cc @pippolo84 @dylandreimerink

I think the error is in the test.
The hive used in TestSysctl includes an Invoke to force the registration of the sysctl reconciler. This starts a first reconciler job for the sysctl table. In fact, Register is thought to be used in all the cases when the reconciler API is not needed and thus it won't be created by the hive.
But in the sysctl test case, the reconciler is needed, since it is a parameter in newReconcilingSysctl. This leads to the creation of another sysctl reconciler.
These two reconcilers race to update the sysctl parameters and to mark the related table entries as StatusKindDone.
Suppose that the test wants to write 1 in a specific sysctl setting, check the value written, then write 2 in the same sysctl setting, the following scenario might happen:
        test                    reconciler1                     reconciler2

        write param=1
                                read param=0
                                                                read param=0
                                                                write param=1
        reconciliation ok
        read param=1 (OK)
        write param=2
                                                                read param=1
                                                                write param=2
                                write param=1
        reconciliation ok
        read param=1 (FAIL)

and the test fails, since value 2 was expected.
This can be proved:

using debug.PrintStack at the beginning of the New function in reconciler.go, to prove that two separate reconcilers are created
adding a debug fmt.Println or similar in incrementalRound[Obj].commit, to check that the CompareAndSwap sometimes is failing (and this shouldn't happen, as we should have a single reconciler that is triggered once after each waitForReconciliation in test).

I'm gonna open a PR to remove the reconciler.Register in the tests (also ipset reconciler tests are affected by this).

Ah cool, the race doesn't indeed reproduce anymore after removing that line. Glad it wasn't a real bug. Thanks!

Do we expect it to be fixed by the same patch?

Yep, I think it is another occurrence of the same issue. :+1:


Running code with Tensorflow GPU

System information

OS Platform and Distribution (e.g., Linux Ubuntu 16.04): Linux Ubuntu 16.04
Mobile device (e.g. iPhone 8, Pixel 2, Samsung Galaxy) if the issue happens on mobile device:
TensorFlow installed from (source or binary): 1.12.0
TensorFlow version: 1.12.0
Python version: 3.6
Installed using virtualenv? pip? conda?: conda
Bazel version (if compiling from source): 0.22.0
GCC/Compiler version (if compiling from source): 5.4.0
CUDA/cuDNN version: cuda=10.0/cudnn=7.4.2
GPU model and memory: RTX 2080

Describe the problem
I installed the everything and ran the tests for cuda and cudnn that were said from and they both passed normally. Running small tests with tensorflow also worked, i.e. a linear regression model. However, I was trying to run a file using keras and doing a more complicated model and it threw errors when it started running an individual epoch. I also just ran the code with only a small portion of the images.
I tensorflow/stream_executor/platform/default/dso_loader.cc:161] successfully opened CUDA library libcudnn.so.7 locally
E tensorflow/stream_executor/cuda/cuda_dnn.cc:482] Could not create cudnn handle: CUDNN_STATUS_INTERNAL_ERROR
E tensorflow/stream_executor/cuda/cuda_dnn.cc:482] Could not create cudnn handle: CUDNN_STATUS_INTERNAL_ERROR

...
...

tensorflow.python.framework.errors_impl.UnknownError: Failed to get convolution algorithm. This is probably because cuDNN failed to initialize, so try looking to see if a warning log message was printed above.
	 [[{{node conv2d/Conv2D}}]]
	 [[conv2d_transpose_2/Shape/_1171]]

Running the code normally with tensorflow works fine, only the gpu version is failing. I tried both building it from source and using tf-nightly-gpu.

duplicate #24828. Please take a look at the workaround used by another user.

Already tried that. Cudnn was installed using the instructions here.
Using conda list cudnn did not list any packages. The cudnn version was also the latest one available, compatible with cuda 10.0. I did try to use both methods since I first tried the debian file, which gave the same error. Later did the unzip to cuda location, still no difference and mnistCUDNN still passed, is there a possibility of conflict?

According to these instructions tensorflow is compatible with cuda 9.0 and, if i'm not mistaken, you have installed version 10.0. Maybe you should try to downgrade, i had a similar issue too

I tried installing cuda 9.0 first, but it also crashed with a different error, saying some compatibility issues. I then read from here that it doesn't support turing architecture.
Only the default tensorflow on pip supports cuda 9.0, but the nightly build supports cuda 10.0. So it's to either build it from source or use the unstable nightly.

@azaks2 Can you PTAL?

@HaoboZ Can you please try installing TF 1.13.0-rc0? It supports cuda 10.0
Also are you able to execute your code in Google Colab successfully using GPU?

Automatically closing due to lack of recent activity. Please update the issue when new information becomes available, and we will reopen the issue. Thanks!

@HaoboZ Did you solve this problem?

Nope, changed the OS to Windows and it worked perfectly fine. That means it's probably not a problem with the hardware.

Solution: Restart the Kernel of Jupyter Notebook. Worked for me every time.


Compute activations other than MLP neurons

FYI: I don't know whether you're open to contributions, but someone might find this helpful.
Modify the activations lib and expgen project to generate exemplars for activations other than MLP neurons -- the residual stream, MLP in/outs, and self-attention outs. These match the Subject collect_acts method, excluding self-attention maps (different shape) and unembed in/outs (no layer index).
Follows the recommendation in project/expgen/README.md by adding to get_activations_computing_func -- specifically, introduces an ActivationType enum which determines access paths for subject -> component and component -> activations.
Adds an activation-type suffix to the exemplars folder name, except when the activation type is "neurons," to preserve current behavior. Similarly, adds a command-line argument to the expgen compute_exemplars.py script with default value "neurons".
Caveat: not tested with the rest of the expgen pipeline yet.

Thank you for implementing this! We are totally open to contributions (it's precisely why we open sourced our code!).
I'll merge the changes in once I test the integration with the expgen pipeline.


blogs not sorted by alphabetical order

the issue
while being alphabetical doesn't matter for inactive blogs after a blog is reopened and put back into the normal blogs category it should be ordered according to alphabetical order, currently, this is not the case with blogs being the lowest in the category once they are re-opened
example
these blogs should be placed back into the category alphabetically with respect to the position of the other blogs.

Fixed in 44c598a394ce642771a3a6dd1de8486d8b195720 and will be a part of next release.

Reopening - while the blogs get sorted in general, it seems to not happen right after blog is activated by someone posting in it.
This is definitely a bug, and needs investigation


There are plenty of useless info in virtlet log.

The ListContainers and ListPodSandbox info in log is useless.
It is more serious when there are many active pods.
We should mask the QUERY info related to ListContainers and ListPodSandbox.
{"log":"filter:\n","stream":"stderr","time":"2018-07-31T01:47:21.62724036Z"}
{"log":"  state:\n","stream":"stderr","time":"2018-07-31T01:47:21.627247948Z"}
{"log":"    state: 1\n","stream":"stderr","time":"2018-07-31T01:47:21.627254817Z"}
{"log":"I0731 01:47:21.627438   16706 grpc.go:117] LEAVE: /runtime.v1alpha2.RuntimeService/ListContainers()\n","stream":"stderr","time":"2018-07-31T01:47:21.627485131Z"}
{"log":"{}\n","stream":"stderr","time":"2018-07-31T01:47:21.627500642Z"}
{"log":"I0731 01:47:21.630957   16706 grpc.go:108] ENTER: /runtime.v1alpha2.RuntimeService/ListPodSandbox():\n","stream":"stderr","time":"2018-07-31T01:47:21.631028224Z"}
{"log":"filter:\n","stream":"stderr","time":"2018-07-31T01:47:21.631053002Z"}
{"log":"  state: {}\n","stream":"stderr","time":"2018-07-31T01:47:21.631061146Z"}
{"log":"I0731 01:47:21.631015   16706 grpc.go:117] LEAVE: /runtime.v1alpha2.RuntimeService/ListPodSandbox()\n","stream":"stderr","time":"2018-07-31T01:47:21.631093453Z"}
{"log":"{}\n","stream":"stderr","time":"2018-07-31T01:47:21.631105845Z"}
{"log":"I0731 01:47:21.633625   16706 grpc.go:108] ENTER: /runtime.v1alpha2.RuntimeService/ListContainers():\n","stream":"stderr","time":"2018-07-31T01:47:21.633742902Z"}
{"log":"filter:\n","stream":"stderr","time":"2018-07-31T01:47:21.633766565Z"}
{"log":"  state:\n","stream":"stderr","time":"2018-07-31T01:47:21.633774304Z"}
{"log":"    state: 1\n","stream":"stderr","time":"2018-07-31T01:47:21.633783764Z"}
{"log":"I0731 01:47:21.633898   16706 grpc.go:117] LEAVE: /runtime.v1alpha2.RuntimeService/ListContainers()\n","stream":"stderr","time":"2018-07-31T01:47:21.633957653Z"}
{"log":"{}\n","stream":"stderr","time":"2018-07-31T01:47:21.633973099Z"}

Can you verify on which log level you have virtlet running? This messages should be visible only on level 4th or bigger, but virtlet in default configuration should be running on 3th log level.

Ok, I can confirm that even if virtlet is started with --v 1 (what is the default on k-d-c) we still have a lot of these "List" ENTER/LEAVE messages, so looks like there is an issue somewhere around: https://github.com/Mirantis/virtlet/blob/master/pkg/manager/grpc.go#L105 or (more probable) loglevel is not properly set during a configuration time of virtlet start.

Yeah.  I deploy virtlet by  deploy/data/virtlet-ds.yaml.    v1.1.2


Define pp.UMVersion helper for pp rules.

Enables writing rules without referring to the rules of encoding in LBSRCE.

Closing the PR as I think it is unclear on future direction. Let's re-open when an implementation exists based on clearer requirements.


404 Error if slash in tag

If a tag name contains a slash, I get an 404 Error when I want to look at the tag
I tried to escape the tag with %2F, but it does not have effect on anything
i.e.
gogs.example.com/mygroup/myrepo/src/taggroup/tag does not work
gogs.example.com/mygroup/myrepo/src/taggroup.tag works

Thanks your feedback!
What is your Gogs version?

Sorry
I am running <IP_ADDRESS>7 Beta on a raspberry

OK, got it, thanks!

Can't reproduce at <IP_ADDRESS>2 Beta

Right, tested on https://try.gogs.io/unknwon/issue-1932/src/tag/with/slash

I just tested it again on your site and on my site again.
It worked on try.gogs.io but still does not work on my site.
I am running gogs behind an apache proxy.
Might this lead to a problem?

Can you upgrade to 0.7.6 first?

I've just upgraded to 0.7.6 and reproduced the error
This is the error I get in the logs:
2015/11/13 17:43:31 [...routers/repo/view.go:61 Home()] [E] GetTreeEntryByPath: GetTreeEntryByPath: error not exist

What i forgot to say: The repository I have a problem with is a mirrored repository!
I just tried it with a not mirrored repository and it works!
The origin is hosted at a gitlab instance and is in a group where i have owner rights.

What i forgot to say: The repository I have a problem with is a mirrored repository!

This helps :D
So does the tag is actually showed in UI but gives you 404 when you try to view?

Exactly.
I just looked at the bare repository on my gogs server and it shows the tag and i can clone the repo and i have the tags, but i cant browse them in the web frontend

The tags itself are listed in the UI correctly

I just looked at the bare repository on my gogs server and it shows the tag and i can clone the repo and i have the tags, but i cant browse them in the web frontend

Can you check repo_root_path/user/repo/refs/tags, are tags all there?

The directory is empty.

That is .... strange..

OK, I tested with mirror repository and empty directory of refs/tags... but view tag with slash and it still works....

The only possible reason I think of at the moment is that it could be a raspberry specific bug.

I might have an expanation for the strange bug:
My tag is named newbranch/tagname.
In my repository there is a branch called newbranch
Now the problem is, that it does not divide branch and tag names.
I tried to add a tag on the master branch which name is the name of a branch in my repository.
It points out that it shows the branch, but in the selection window the tick is in both sections (branches and tags) at the tag-/branch-name
I pushed my tests to https://try.gogs.io/janfred/issue-1932

My tag is named newbranch/tagname.
In my repository there is a branch called newbranch
Now the problem is, that it does not divide branch and tag names.

Your demo seems does not show this?

Example is here: https://try.gogs.io/janfred/issue-1932/src/newbranch/v1

OK, got it.
So the problem is branch and tag have same name?

Yes.
If they have the same name it always takes the branch (Example: https://try.gogs.io/janfred/issue-1932/src/branchtest2)
And if the branch name matches the first part of the tag name i get a 404 (Example in prev. Comment)

I'll take a deep look later see if possible to solve without having break changes. Thanks for following up!

@0maxxam0 has funded $5.00 to this issue. See it on IssueHunt


Add documentation link to Readme

I found it quite hard to find the documentation from the GitHub repo. I think the only link is in the header, and from that page I didn't find the link to documentation easily either. Might be worth adding a link in the Readme?

Thank you!


install_dependencies error

ENV

ubuntu  22.04
anaconda python 3.8
OAK-D Lite

pip install -r requirements.txt
Looking in indexes: https://pypi.org/simple, https://artifacts.luxonis.com/artifactory/luxonis-python-snapshot-local
ERROR: Could not find a version that satisfies the requirement opencv-contrib-python==<IP_ADDRESS> (from versions: <IP_ADDRESS>, <IP_ADDRESS>, <IP_ADDRESS>, <IP_ADDRESS>, <IP_ADDRESS>, <IP_ADDRESS>, <IP_ADDRESS>, <IP_ADDRESS>, <IP_ADDRESS>, <IP_ADDRESS>, <IP_ADDRESS>, <IP_ADDRESS>, <IP_ADDRESS>, <IP_ADDRESS>, <IP_ADDRESS>, <IP_ADDRESS>, <IP_ADDRESS>, <IP_ADDRESS>, <IP_ADDRESS>, <IP_ADDRESS>, <IP_ADDRESS>, <IP_ADDRESS>, <IP_ADDRESS>, <IP_ADDRESS>, <IP_ADDRESS>, <IP_ADDRESS>, <IP_ADDRESS>, <IP_ADDRESS>, <IP_ADDRESS>, <IP_ADDRESS>, <IP_ADDRESS>, <IP_ADDRESS>, <IP_ADDRESS>, <IP_ADDRESS>, <IP_ADDRESS>)
ERROR: No matching distribution found for opencv-contrib-python==<IP_ADDRESS>

python main.py
Traceback (most recent call last):
  File "main.py", line 183, in <module>
    App = getVitalApp(pixel_threshold=args.pixel_thresh)
  File "main.py", line 18, in __init__
    self.processor = HeartrateEstimator(pixel_threshold=pixel_threshold)
  File "/home/dodo/PycharmProjects/depthai/heartrate_estimation/heartrate_estimator.py", line 51, in __init__
    self.ft = cv2.freetype.createFreeType2()
AttributeError: module 'cv2.cv2' has no attribute 'freetype'

I got the same error with a similar setup.

I made it work at the end.
But the accuracy is not well, especially when the people is not stationary.

I made it work at the end. But the accuracy is not well, especially when the people is not stationary.

How did you solve the problem？

It for a while, if memory serves me well, I just command out some code.
Maybe I can check it later(if I still keep it)， If you really need it


Added by_name function to discovery, with test and doc changes

This PR adds a very simple by_name function to discovery that returns a device by its name.
from soco.discovery import by_name
device = by_name("Kitchen")

I don't know why I haven't done this earlier, since the code that it contains, I have been writing by hand a lot of time while testing different things.
Let me know what you think.

Coverage increased (+0.05%) to 60.802% when pulling 05bbb256b75796373e064924371ef0848b31d3de on KennethNielsen:zone_by_name into 1fe61bdf10aa9538f3eca38a0940144d02104c33 on SoCo:master.

So simple and yet so ingenious. 😶

@ghcs27 Thanks.
Can I convince you to do a review? I already spotted a singular/plural "..If none is/are found.." error, that I will correct.

Re "none is/are found": Actually, it seems that even native English speakers couldn't agree on whether "is" or "are" would be correct in this context [link], so it's probably fine either way.
Re by_name(): Tested, works.
Re docs: Grammar/spelling fine, maybe add a full stop at the end of the docstring "sentences"?

Coverage decreased (-0.4%) to 60.357% when pulling f579ac05f7794367f6927b3f5851443492c43843 on KennethNielsen:zone_by_name into 1fe61bdf10aa9538f3eca38a0940144d02104c33 on SoCo:master.

@ghcs27 Thanks. Merged.


fixed issue https://github.com/googlesamples/android-ndk/issues/263:

using standard C++ headers, instead of c headers to fix PRIu64 issue

LGTM.


Properly handle deep reorgs in engine experimental

Describe the feature
In the new version of the engine developed here https://github.com/paradigmxyz/reth/issues/8742 we remove disk writes from the hot path by adding an in-memory data structure that keeps track of the most recent blocks. We need to give this data structure a concrete size to balance the increase in performance by keeping this part of the state in memory with the amount of memory required to do so. At some point, the engine will flush to disk the in-memory state persisting it in static files.
When a reorg happens, it is usually handled very efficiently in the in-memory part of the state. The problem arises when the depth of the reorg exceeds the size of the in-memory data structure, we are returning an error but instead, we should properly handle it and update the in-memory and on-disk parts of the state accordingly.
This is also problematic just by creating a fork starting on a block not present in memory.
This issue has been brought up by executing hive tests against a reth instance with enabled --engine.experimental flag. By default, the number of blocks kept in memory by the engine is 2 and the tests that are failing are exercising reorgs of depth 9 or 10, for instance Invalid Missing Ancestor ReOrg, StateRoot, EmptyTxs=False, Invalid P9 (Cancun) (reth) defined here https://github.com/ethereum/hive/blob/f47eebb89be85cee2c9d3fd2d0afbe209ad3e77e/simulators/ethereum/engine/suites/engine/invalid_ancestor.go
Additional context
No response

closing this because this is now supported


Fix for #266 added index.js and index.d.ts

Fixes #266.

Thank you for time, but I will not merging a PR of this nature at this time. I'm already in the process of shaking this up.


build(linting): Enforce tslint in travis-ci

Executes tslint via npm script to be replaced by ng lint when it matures

allows local execution with "npm run tslint"

Executes in the before_script to fail fast ( approx. 50 seconds for feedback ): Failed Build Example

tslint runs against  "src/*/.ts"

Fixes numerous linting errors, specifics per component are listed in the commit messages

Requires tslint version update to 3.5.0 to take advantage of ignore patterns

resolves #85

Hey! Glad to see this is really close to being done!
The only thing remaining is to squash your commits together into a single commit. You can do this by running:
git rebase -i master

And then picking the first commit you want to keep (might be the first) and squashing all the others.
If you need help I'll be away on gitter but available.

I can squash with the best of them, be done in a sec.

LGTM


Some characters can not be typed into the editor window

Hi,
I tried to write a simple c program with vscode.dev (web version), but the Ampersand (&) and the Greater-than sign (>) can not be typed in my environment.
I am using a Samsung Galaxy S10e phone in DEX docking station and an external USB keyboard (hungarian layout) is attached to it.
I can type the above mentioned characters to the browser e.g.: URL bar (for testing purposes), or outlook.live.com/mail (create new email), however not in the code editor.
Please advise.
Regards,
Attila
Version: 1.67.0
Commit: 57fd6d0195bb9b9d1b49f6da5db789060795de47
User Agent: Mozilla/5.0 (Linux; Android 11; SM-G970F) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/101.0.4951.41 Safari/537.36
Embedder: vscode.dev

It is possible that there is a command bound to that key combination. Could you please try the following:

Run the command Developer: Toggle Keyboard Shortcuts Troubleshooting
This will activate logging of dispatched keyboard shortcuts and will open an output panel with the corresponding log file.
Press exactly the keybinding you desire.
check what VS Code detects and what command is invoked.

If you are having trouble understanding the output, please feel free to paste here and I can try to help.


cell state + fitness setting mathmatical rules

Let´s agree on rules and an amount of states that cealls operate by.

Do we want to start with 2 states (Alive and Dead / 0,1) and add more states later
Do we want to add a 3rd state like suggested eg in https://www.sciencedirect.com/science/article/pii/S0960077920301211#tbl0001
to implement an evolution
What rules create to a state change
Adding a dimension with the fitness of neighboring cells
What neighborhood rule do we use? neighborhood of 9 or 4?

easy:
"strict" ruling:
for sum 9
Li(t) = {1 if sumj oj = 3
{o(t) if sumj oj = 2
{0 otherwise
dynamic ruling:
Li(t) = {1 if oj(t) = 0,  1i(t) + 2i(t) = 3  and  1i(t) > 2i(t)
{2 if oj(t) = 0,  1i(t) + 2i(t) = 3  and  1i(t) < 2i(t)
{o(t) if oj(t) > 0   and      1  <  1i(t) + 2i(t)   <  4
{0 otherwise


rocmPackages.hipfort: 6.0.2 -> 6.2.1

Automatic update generated by nixpkgs-update tools. This update was made based on information from passthru.updateScript.

WARNING: Package has meta.broken=true; Please manually test this package update and remove the broken attribute.

meta.description for rocmPackages.hipfort is: Fortran interfaces for ROCm libraries
meta.homepage for rocmPackages.hipfort is: https://github.com/ROCm/hipfort
Updates performed

Ran passthru.UpdateScript

To inspect upstream changes

Compare changes on GitHub

Impact
Checks done

built on NixOS
The tests defined in passthru.tests, if any, passed
found 6.1.0 in filename of file in /nix/store/i5bk85kfrr67pyhwcfwvyn29r0l7kv2j-hipfort-6.1.0

Rebuild report (if merged into master) (click to expand)

2 total rebuild path(s)

2 package rebuild(s)

First fifty rebuilds by attrpath
rocmPackages.hipfort
rocmPackages_6.hipfort

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/i5bk85kfrr67pyhwcfwvyn29r0l7kv2j-hipfort-6.1.0 \
  --option binary-caches 'https://cache.nixos.org/ https://nix-community.cachix.org/' \
  --option trusted-public-keys '
  nix-community.cachix.org-1:mB9FSh9qf2dCimDSUo8Zy7bkq5CX+/rkCWyvRCYg3Fs=
  cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY=
  '

(The Cachix cache is only trusted for this store-path realization.)
For the Cachix download to work, your user must be in the trusted-users list or you can use sudo since root is effectively trusted.
Or, build yourself:
nix-build -A rocmPackages.hipfort https://github.com/r-ryantm/nixpkgs/archive/9a3f77581ae1572ad3a7feebb12c4452a724bea9.tar.gz

Or:
nix build github:r-ryantm/nixpkgs/9a3f77581ae1572ad3a7feebb12c4452a724bea9#rocmPackages.hipfort

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/i5bk85kfrr67pyhwcfwvyn29r0l7kv2j-hipfort-6.1.0
ls -la /nix/store/i5bk85kfrr67pyhwcfwvyn29r0l7kv2j-hipfort-6.1.0/bin

Pre-merge build results
We have automatically built all packages that will get rebuilt due to
this change.
This gives evidence on whether the upgrade will break dependent packages.
Note sometimes packages show up as failed to build independent of the
change, simply because they are already broken on the target branch.
Result of nixpkgs-review --extra-nixpkgs-config '{ allowInsecurePredicate = x: true; }' run on x86_64-linux 1

1 package marked as broken and skipped:

rocmPackages.hipfort

Maintainer pings
cc @Madouura @Flakebi @mschwaig for testing.

Automatic update generated by nixpkgs-update tools. This update was made based on information from passthru.updateScript.

WARNING: Package has meta.broken=true; Please manually test this package update and remove the broken attribute.

meta.description for rocmPackages.hipfort is: Fortran interfaces for ROCm libraries
meta.homepage for rocmPackages.hipfort is: https://github.com/ROCm/hipfort
Updates performed

Ran passthru.UpdateScript

To inspect upstream changes

Compare changes on GitHub

Impact
Checks done

built on NixOS
The tests defined in passthru.tests, if any, passed
found 6.2.0 in filename of file in /nix/store/3cp26pb6ib585qjf50bdpv7l14f6nqsc-hipfort-6.2.0

Rebuild report (if merged into master) (click to expand)

3 total rebuild path(s)

3 package rebuild(s)

First fifty rebuilds by attrpath

rocmPackages.hipfort
rocmPackages_6.hipfort

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/3cp26pb6ib585qjf50bdpv7l14f6nqsc-hipfort-6.2.0 \
  --option binary-caches 'https://cache.nixos.org/ https://nix-community.cachix.org/' \
  --option trusted-public-keys '
  nix-community.cachix.org-1:mB9FSh9qf2dCimDSUo8Zy7bkq5CX+/rkCWyvRCYg3Fs=
  cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY=
  '

(The Cachix cache is only trusted for this store-path realization.)
For the Cachix download to work, your user must be in the trusted-users list or you can use sudo since root is effectively trusted.
Or, build yourself:
nix-build -A rocmPackages.hipfort https://github.com/r-ryantm/nixpkgs/archive/fdd80e88f7270035642d872a709f1b2017337935.tar.gz

Or:
nix build github:r-ryantm/nixpkgs/fdd80e88f7270035642d872a709f1b2017337935#rocmPackages.hipfort

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/3cp26pb6ib585qjf50bdpv7l14f6nqsc-hipfort-6.2.0
ls -la /nix/store/3cp26pb6ib585qjf50bdpv7l14f6nqsc-hipfort-6.2.0/bin

Pre-merge build results
We have automatically built all packages that will get rebuilt due to
this change.
This gives evidence on whether the upgrade will break dependent packages.
Note sometimes packages show up as failed to build independent of the
change, simply because they are already broken on the target branch.
Result of nixpkgs-review run on x86_64-linux 1

1 package marked as broken and skipped:

rocmPackages.hipfort

Maintainer pings
cc @Madouura @Flakebi @mschwaig for testing.

Automatic update generated by nixpkgs-update tools. This update was made based on information from passthru.updateScript.

WARNING: Package has meta.broken=true; Please manually test this package update and remove the broken attribute.

meta.description for rocmPackages.hipfort is: Fortran interfaces for ROCm libraries
meta.homepage for rocmPackages.hipfort is: https://github.com/ROCm/hipfort
Updates performed

Ran passthru.UpdateScript

To inspect upstream changes

Compare changes on GitHub

Impact
Checks done

built on NixOS
The tests defined in passthru.tests, if any, passed
found 6.2.1 in filename of file in /nix/store/l835n0i4p6irl9b1xxdq7ypvhlfycrsd-hipfort-6.2.1

Rebuild report (if merged into master) (click to expand)

3 total rebuild path(s)

3 package rebuild(s)

First fifty rebuilds by attrpath

rocmPackages.hipfort
rocmPackages_6.hipfort

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/l835n0i4p6irl9b1xxdq7ypvhlfycrsd-hipfort-6.2.1 \
  --option binary-caches 'https://cache.nixos.org/ https://nix-community.cachix.org/' \
  --option trusted-public-keys '
  nix-community.cachix.org-1:mB9FSh9qf2dCimDSUo8Zy7bkq5CX+/rkCWyvRCYg3Fs=
  cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY=
  '

(The Cachix cache is only trusted for this store-path realization.)
For the Cachix download to work, your user must be in the trusted-users list or you can use sudo since root is effectively trusted.
Or, build yourself:
nix-build -A rocmPackages.hipfort https://github.com/r-ryantm/nixpkgs/archive/083bca809a6f3e22c7d979d429bf85456075aa66.tar.gz

Or:
nix build github:r-ryantm/nixpkgs/083bca809a6f3e22c7d979d429bf85456075aa66#rocmPackages.hipfort

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/l835n0i4p6irl9b1xxdq7ypvhlfycrsd-hipfort-6.2.1
ls -la /nix/store/l835n0i4p6irl9b1xxdq7ypvhlfycrsd-hipfort-6.2.1/bin

Pre-merge build results
We have automatically built all packages that will get rebuilt due to
this change.
This gives evidence on whether the upgrade will break dependent packages.
Note sometimes packages show up as failed to build independent of the
change, simply because they are already broken on the target branch.
Result of nixpkgs-review run on x86_64-linux 1

1 package marked as broken and skipped:

rocmPackages.hipfort

Maintainer pings
cc @Madouura @Flakebi @mschwaig for testing.

[!TIP]
As a maintainer, if your package is located under pkgs/by-name/*, you can comment @NixOS/nixpkgs-merge-bot merge to automatically merge this update using the nixpkgs-merge-bot.

Add a :+1: reaction to pull requests you find important.

Automatic update generated by nixpkgs-update tools. This update was made based on information from passthru.updateScript.

WARNING: Package has meta.broken=true; Please manually test this package update and remove the broken attribute.

meta.description for rocmPackages.hipfort is: Fortran interfaces for ROCm libraries
meta.homepage for rocmPackages.hipfort is: https://github.com/ROCm/hipfort
Updates performed

Ran passthru.UpdateScript

To inspect upstream changes

Compare changes on GitHub

Impact
Checks done

built on NixOS
The tests defined in passthru.tests, if any, passed
found 6.2.2 in filename of file in /nix/store/zpfbsjkhg1qjg0bzvrapq0yayfnsanmy-hipfort-6.2.2

Rebuild report (if merged into master) (click to expand)

3 total rebuild path(s)

3 package rebuild(s)

First fifty rebuilds by attrpath

rocmPackages.hipfort
rocmPackages_6.hipfort

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/zpfbsjkhg1qjg0bzvrapq0yayfnsanmy-hipfort-6.2.2 \
  --option binary-caches 'https://cache.nixos.org/ https://nix-community.cachix.org/' \
  --option trusted-public-keys '
  nix-community.cachix.org-1:mB9FSh9qf2dCimDSUo8Zy7bkq5CX+/rkCWyvRCYg3Fs=
  cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY=
  '

(The Cachix cache is only trusted for this store-path realization.)
For the Cachix download to work, your user must be in the trusted-users list or you can use sudo since root is effectively trusted.
Or, build yourself:
nix-build -A rocmPackages.hipfort https://github.com/r-ryantm/nixpkgs/archive/e1df99b7f04f507ff9ca80c76d185fd08359a47f.tar.gz

Or:
nix build github:r-ryantm/nixpkgs/e1df99b7f04f507ff9ca80c76d185fd08359a47f#rocmPackages.hipfort

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/zpfbsjkhg1qjg0bzvrapq0yayfnsanmy-hipfort-6.2.2
ls -la /nix/store/zpfbsjkhg1qjg0bzvrapq0yayfnsanmy-hipfort-6.2.2/bin

Pre-merge build results
We have automatically built all packages that will get rebuilt due to
this change.
This gives evidence on whether the upgrade will break dependent packages.
Note sometimes packages show up as failed to build independent of the
change, simply because they are already broken on the target branch.
Result of nixpkgs-review run on x86_64-linux 1

1 package marked as broken and skipped:

rocmPackages.hipfort

Maintainer pings
cc @Madouura @Flakebi @mschwaig for testing.

[!TIP]
As a maintainer, if your package is located under pkgs/by-name/*, you can comment @NixOS/nixpkgs-merge-bot merge to automatically merge this update using the nixpkgs-merge-bot.

Add a :+1: reaction to pull requests you find important.

Automatic update generated by nixpkgs-update tools. This update was made based on information from passthru.updateScript.

WARNING: Package has meta.broken=true; Please manually test this package update and remove the broken attribute.

meta.description for rocmPackages.hipfort is: Fortran interfaces for ROCm libraries
meta.homepage for rocmPackages.hipfort is: https://github.com/ROCm/hipfort
Updates performed

Ran passthru.UpdateScript

To inspect upstream changes

Compare changes on GitHub

Impact
Checks done

built on NixOS
The tests defined in passthru.tests, if any, passed
found 6.3.0 in filename of file in /nix/store/l96rjn743bwlfw48njpv92q0s7rgbnax-hipfort-6.3.0

Rebuild report (if merged into master) (click to expand)

3 total rebuild path(s)

3 package rebuild(s)

First fifty rebuilds by attrpath

rocmPackages.hipfort
rocmPackages_6.hipfort

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/l96rjn743bwlfw48njpv92q0s7rgbnax-hipfort-6.3.0 \
  --option binary-caches 'https://cache.nixos.org/ https://nix-community.cachix.org/' \
  --option trusted-public-keys '
  nix-community.cachix.org-1:mB9FSh9qf2dCimDSUo8Zy7bkq5CX+/rkCWyvRCYg3Fs=
  cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY=
  '

(The Cachix cache is only trusted for this store-path realization.)
For the Cachix download to work, your user must be in the trusted-users list or you can use sudo since root is effectively trusted.
Or, build yourself:
nix-build -A rocmPackages.hipfort https://github.com/r-ryantm/nixpkgs/archive/f75bd56b0c73e8b3d039aadef77cd65c84616c21.tar.gz

Or:
nix build github:r-ryantm/nixpkgs/f75bd56b0c73e8b3d039aadef77cd65c84616c21#rocmPackages.hipfort

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/l96rjn743bwlfw48njpv92q0s7rgbnax-hipfort-6.3.0
ls -la /nix/store/l96rjn743bwlfw48njpv92q0s7rgbnax-hipfort-6.3.0/bin

Pre-merge build results
We have automatically built all packages that will get rebuilt due to
this change.
This gives evidence on whether the upgrade will break dependent packages.
Note sometimes packages show up as failed to build independent of the
change, simply because they are already broken on the target branch.
nixpkgs-review result
Generated using nixpkgs-review.
Command: nixpkgs-review

x86_64-linux

:fast_forward: 1 package marked as broken and skipped:

rocmPackages.hipfort

Maintainer pings
cc @Madouura @Flakebi @mschwaig for testing.

[!TIP]
As a maintainer, if your package is located under pkgs/by-name/*, you can comment @NixOS/nixpkgs-merge-bot merge to automatically merge this update using the nixpkgs-merge-bot.

Add a :+1: reaction to pull requests you find important.

Automatic update generated by nixpkgs-update tools. This update was made based on information from passthru.updateScript.

WARNING: Package has meta.broken=true; Please manually test this package update and remove the broken attribute.

meta.description for rocmPackages.hipfort is: Fortran interfaces for ROCm libraries
meta.homepage for rocmPackages.hipfort is: https://github.com/ROCm/hipfort
Updates performed

Ran passthru.UpdateScript

To inspect upstream changes

Compare changes on GitHub

Impact
Checks done

built on NixOS
The tests defined in passthru.tests, if any, passed
found 6.3.1 in filename of file in /nix/store/j3slx0fd8p1m2mz2hbk1pnm2h7xlm0k5-hipfort-6.3.1

Rebuild report (if merged into master) (click to expand)

3 total rebuild path(s)

3 package rebuild(s)

First fifty rebuilds by attrpath

rocmPackages.hipfort
rocmPackages_6.hipfort

Instructions to test this update (click to expand)

Either download from the cache:
nix-store -r /nix/store/j3slx0fd8p1m2mz2hbk1pnm2h7xlm0k5-hipfort-6.3.1 \
  --option binary-caches 'https://cache.nixos.org/ https://nixpkgs-update-cache.nix-community.org/' \
  --option trusted-public-keys '
  nixpkgs-update-cache.nix-community.org-1:U8d6wiQecHUPJFSqHN9GSSmNkmdiFW7GW7WNAnHW0SM=
  cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY=
  '

(The nixpkgs-update cache is only trusted for this store-path realization.)
For the cached download to work, your user must be in the trusted-users list or you can use sudo since root is effectively trusted.
Or, build yourself:
nix-build -A rocmPackages.hipfort https://github.com/r-ryantm/nixpkgs/archive/7b0c85711cca0815b85d0948b6e0eadf532187c9.tar.gz

Or:
nix build github:r-ryantm/nixpkgs/7b0c85711cca0815b85d0948b6e0eadf532187c9#rocmPackages.hipfort

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/j3slx0fd8p1m2mz2hbk1pnm2h7xlm0k5-hipfort-6.3.1
ls -la /nix/store/j3slx0fd8p1m2mz2hbk1pnm2h7xlm0k5-hipfort-6.3.1/bin

Pre-merge build results
We have automatically built all packages that will get rebuilt due to
this change.
This gives evidence on whether the upgrade will break dependent packages.
Note sometimes packages show up as failed to build independent of the
change, simply because they are already broken on the target branch.
nixpkgs-review result
Generated using nixpkgs-review.
Command: nixpkgs-review

x86_64-linux

:fast_forward: 1 package marked as broken and skipped:

rocmPackages.hipfort

Maintainer pings
cc @Madouura @Flakebi @mschwaig for testing.

[!TIP]
As a maintainer, if your package is located under pkgs/by-name/*, you can comment @NixOS/nixpkgs-merge-bot merge to automatically merge this update using the nixpkgs-merge-bot.

Add a :+1: reaction to pull requests you find important.


fix(catalog-to-csv): write one statement per CSV row

Types of changes

[ ] Hot fix (emergency fix and release)
[x] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Documentation (change which affects the documentation site)
[ ] Breaking change (fix or feature that would cause existing functionality to change)
[ ] Release (develop -> main)

Quality assurance (all should be covered).

[x] My code follows the code style of this project.
[x] Documentation for my change is up to date?
[ ] My PR meets testing requirements.
[ ] All new and existing tests passed.
[x] All commits are signed-off.

Summary
Modifies the statement level output of the oscal-catalog-to-csv task to output one row for each statement, to an arbitrary depth of sub-statements.
Key links:

Sonar coverage

Before you merge

Ensure it is a 'squash commit' if not a release.
Ensure CI is currently passing
Check sonar. If you are working for a fork a maintainer will reach out, if required.

Sorry for the delayed response, I was OOO until today. I enabled workflow runs...
Existing tests will continue to succeed with respect to this trestle task? Please add to the test cases to cover the new functionality. Should the one statement per csv row be optional or always?


[KeyVault] Adding MSIAuthentication support

Broadening KeyVaultClient crendentials class check to support MSIAuthentication

Codecov Report

Merging #1533 into master will not change coverage.
The diff coverage is 100%.

@@           Coverage Diff           @@
##           master    #1533   +/-   ##
=======================================
  Coverage   54.23%   54.23%
=======================================
  Files        3584     3584
  Lines       88213    88213
=======================================
  Hits        47846    47846
  Misses      40367    40367

Impacted Files
Coverage Δ

...keyvault/azure/keyvault/custom/key_vault_client.py
96.66% <100%> (ø)
:arrow_up:

Continue to review full report at Codecov.

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


hate speech 18 dataset

This is again a PR instead of #1339, because something went wrong there.

The error tests/test_file_utils.py::TempSeedTest::test_tensorflow just appeared because of tensorflow's update.
Once it's fixed on master we'll be free to merge this one

It's fixed on master now :)
merging this once


Creating image for OSL 2022 using aswf-docker - pugixml & pybind11 are missing

When creating an image for OSL using the command aswfdocker build -n aswftesting/ci-osl:2022-clang11.7, the image does not contain the pugixml and pybind11 libraries.
@aloysbaillet @lgritz I report that point not knowing if that's a bug or that was done on purpose. Please close the issue if that's not a bug.

OSL itself just downloads those on demand if not found, and both are tiny source packages that build in a few seconds, so I just never pressed the issue about having them in the docker images. The things that are important for me in docker are the ones that if missing will cause me to chew up 10 minutes of Actions time to build from scratch.
That said, they are dependencies and I would certainly not object to them being in the docker image.

Happy to add pybind11 in ci-ocio, but I don't have a package ready for pugixml though (and I cheat by using OSL's own build_pugixml.bash script to build the OSL package...)
I could also add pybind11 for ci-osl if you want @lgritz ?

It seems that OIIO also brings pugixml along:
docker run -it --rm aswftesting/ci-ocio:2022 ls /usr/local/include/OpenImageIO/detail/pugixml
pugiconfig.hpp  pugixml.cpp  pugixml.hpp

And the newly pushed aswfesting/ci-ocio:2022 now properly contains pybind11.

I don't have strong preferences. My CI tests a lot of different versions of everything. I use what's in the ASWF docker when it happens to align with a set of versions I need to test, but for a significant part of the test matrix, I have to rebuild certain things from scratch. For a tiny package like pugixml or pybind11, getting from the docker container, in the subset of cases where it's even the right version, is a minuscule savings. In comparison, getting something big and expensive to build like llvm or OpenVDB pre-built in the docker is a life saver.

New aswfesting/ci-ocio:2022.1 should now be complete!


[FEAT] Support parameters/options when running shell command

Wanted features:
Support considering parameters/options when specifying a shell program, e.g. to run a command with Shell pwsh, PLUS parameter -NoProfile.
{
    "type": "command",
    "shell": "pwsh -NoProfile",
    "text": "(git --version).Substring(12)",
    "key": "Git"
},

Currently it seems not supported at the moment, because it is not working on my side with fastfetch 2.23.0.
Motivation:
Shells can be started with different options/parameters, which is sometimes even required to control the behavior of the shell in specific situations.

This is 2x faster than using pwsh
@ECHO OFF
REM ~/git_version.bat
FOR /F "delims=" %%i IN ('git version') DO SET "GIT_VERSION=%%i"
ECHO %GIT_VERSION:~12%

{
  "type": "command",
  "text": "%USERPROFILE%\\git_version.bat",
  "key": "Git"
}


Adds a prop to open button links in a new tab

There are already plans to improve how we deal with links in ui-kit (D2IQ-61570), but I'm not sure when that ticket will get worked on.
This is an issue that causes enough headaches that I think this quick fix makes sense.

@mperrotti  perhaps we build in that external icon link shows up by default in such a case but "escape hatch" to potentially turn off in case opening in new tab but not an external link.

We haven't defined any rules around when we do or don't show the OpenExternal icon. I'd rather have us explicitly pass that icon until we know when that "escape hatch" might need to be used


If I only have plex, the app errors out that I didn't set my Jellyfin URL

It should skip Jelly and look for plex.

same here

@r3tr0ananas could you possibly have a look at this, I think this is completely stopping the use of the plex scraper

can't reproduce this issue.

With your jellyfin environment variables unset too?
I just have a suspicion with that this line is causing it because as far as I remember scraper's init functions are executed no matter if you're using that scraper or not and self.__auth just happen to raise an exception if envs are missing.
https://github.com/mov-cli/mov-cli-jellyplex/blob/819780038c4263763c23dbaf421742146a2e0797/mov_cli_jellyplex/jellyfin/scraper.py#L40
sorry that I'm asking you to look into it, I'm just really busy

yep, my jellyfin env is unset and iirc init functions only are executed when you use that scraper.

@joshkerr what command do you use?

I have just started using this plugin this afternoon with the similar error when using the command mov-cli -s jelly "query":
Error: You haven't set the 'JELLY_URL' env!

You need to do: mov-cli -s jelly.plex "query"

That resolved my issue. I would request updating the documentation: Usage

or you can also override the jelly namespace using the config like this:
[mov-cli.scrapers]
jelly = "jellyplex.plex"

[mov-cli.plugins]
jellyplex = "mov-cli-jellyplex"

now -s jelly should point to the plex scraper and you can use this command like normal, but it's up to you:
mov-cli -s jelly "query"

Did not resolve my issue. Its still erroring out for me. I checked that my plex environment variables are set and I do have my mov-cli config loading the plugin into the jelly namespace, but I'm still getting this output:
mov-cli -s jelly.plex ghost
Good Evening, joshkerr.
It's 08:54 PM on a gorgeous Sunday!
[INFO] (mov_cli) - Using 'jelly.plex' scraper...
[INFO] (mov_cli) - Searching for 'ghost'...
[INFO] (mov_cli) - [ATNS] ❌ Error occurred while searching with 'jelly.plex'! Trying the next scraper...

That's the same new error message that I have. I didn't include that because it may be a Plex connection issue and not the original error message.
Get Outlook for Androidhttps://aka.ms/AAb9ysg

From: Josh Kerr @.>
Sent: Sunday, December 8, 2024 6:58:23 PM
To: mov-cli/mov-cli-jellyplex @.>
Cc: rogers1lt @.>; Comment @.>
Subject: Re: [mov-cli/mov-cli-jellyplex] If I only have plex, the app errors out that I didn't set my Jellyfin URL (Issue #6)
Did not resolve my issue. Its still erroring out for me. I checked that my plex environment variables are set and I do have my mov-cli config loading the plugin into the jelly namespace, but I'm still getting this output:
mov-cli -s jelly.plex ghost
Good Evening, joshkerr.
It's 08:54 PM on a gorgeous Sunday!
[INFO] (mov_cli) - Using 'jelly.plex' scraper...
[INFO] (mov_cli) - Searching for 'ghost'...
[INFO] (mov_cli) - [ATNS] ❌ Error occurred while searching with 'jelly.plex'! Trying the next scraper...
—
Reply to this email directly, view it on GitHubhttps://github.com/mov-cli/mov-cli-jellyplex/issues/6#issuecomment-2526701412, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ADD3MU4HAKYTEITPMNMZHL32EUBM7AVCNFSM6AAAAABS7D35MSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKMRWG4YDCNBRGI.
You are receiving this because you commented.Message ID: @.***>

Actually, that did fix my issue. I was working in a terminal that didn't have my env variables set because it wasn't refreshed. Once I did that, it worked fine.

Try turning debug=true in your settings for mov-cli and it will show you why its erroring out. That's how I figured it out.


Add a quick world hop option.

could have it in the side bar.

I didnt mean it like hopping to a friends world. I mean implementing the "world switch" menu into the side bar. Or is that the same concept?

Same issue; can't do it without faking inputs

Duplicate of #1617

Marked this as duplicate of 1617 because it is blocked on same thing and if we ever resolve it we probably also implemented other ways of quick hopping


RevEng: generated props .HasMaxLength(x).HasColumnType("varchar") create varchar(1) columns in DB

The dnx command with the -a option
dnx ef dbcontext scaffold <connection string> EntityFramework.MicrosoftSqlServer -a -c <context name> -o <output dir>
generates incomplete entity properties for the varchar data type in the OnModelCreating method:
for nvarchar(x) it generates .HasMaxLength(x)
but for varchar(x) it generates .HasMaxLength(x).HasColumnType("varchar")
where x is data length
Then, when I call Database.EnsureCreated() from the generated dbcontext, it creates varchar(1) columns in the DB rather then varchar(x).
As a result, the SQL Server throws en exception "String or binary data would be truncated" when trying to write to those castrated columns.

Thanks for reporting this @umu24013. I'll look into it.

Once we have IsUnicode API (https://github.com/aspnet/EntityFramework/issues/3420) the code should be .HasMaxLength(x).IsUnicode(false). In the meantime it should just be ```HasColumnType("varchar(x)"). The HasMaxLength call isn't needed because the length is specified in the datatype... but if it's less work just to leave it in, then that is fine (we'll want it when we swap to IsUnicode anyway).

Fix is checked in with #4348, commit 443c52b.
Details: using both HasColumnType() and HasMaxLength() at the same time doesn't work. Because the column type contains (either implicitly or explicitly) a max length we just ignore the HasMaxLength() call and use the column type defined by HasColumnType(). When scaffolding generated e.g. .HasColumnType("varchar").HasMaxLength(100) it was expecting that migrations would treat that as an underlying data type of varchar(100). What actually happened, as mentioned at the top of this issue, was that the HasMaxLength() call was ignored and migrations assumed a data type of varchar which SQL Server treats as varchar(1).
In addition to that for properties with type string the default SQL Server data type assumed by migrations is nvarchar(max). So if that is the type you intend you can skip defining HasColumnType() altogether. If you skip HasColumnType() then you can and should use HasMaxLength(). But if e.g. you have a string property but the data type you want it to be on SQL Server is varchar(max) you cannot rely on the default mapping, so you must use HasColumnType() which means you must declare the length of the type within that call i.e. HasColumnType("varchar(max)") rather than just HasColumnType("varchar"). Similarly for byte[] properties the default SQL Server type is varbinary(max) and you get similar concerns.
So I updated the scaffolding code to look again at any string and byte[] properties it is generating and make sure that, as listed in the above rules, either HasColumnType() or HasMaxLength() is called, or neither of them, but definitely not both. (And of course that it you specify using annotations then the [MaxLength] annotation will be output instead of a call to HasMaxLength() - however this happens less often now as we often have to call HasColumnType() specifying a length qualification within it - and there is no matching annotation for that).
Lastly, since the big change to use dotnet, dnx commands at the command-line don't work any more. The work to fix that is tracked in #3925. In the meantime the only way to test this is to use Scaffold-DbContext from the Package Manager within VS.

(And of course that it you specify using annotations then the  [MaxLength]  annotation will be output instead of a call to  HasMaxLength()  - however this happens less often now as we often have to call  HasColumnType()  specifying a length qualification within it - and there is no matching annotation for that).

@lajones just to make sure I understand, do we still generate properties of a specific CLR type and either [MaxLenght] or .HasMaxLenght() for the most common store types? Ideally we shouldn't generate .HasColumnType() calls unless it is needed.

@divega Depends what you mean. If the underlying store type is nvarchar(x) or varbinary(x) or any non-string, non-byte[] property then yes. But e.g. varchar(x) is pretty common and we need to generate HasColumnType("varchar(x)") for that.

BTW @divega The [fluent API tests] (https://github.com/aspnet/EntityFramework/blob/dev/test/Microsoft.EntityFrameworkCore.SqlServer.Design.FunctionalTests/ReverseEngineering/ExpectedResults/E2E_AllFluentApi/SqlServerReverseEngineerTestE2EContext.expected#L16) and the [annotations tests] (https://github.com/aspnet/EntityFramework/blob/dev/test/Microsoft.EntityFrameworkCore.SqlServer.Design.FunctionalTests/ReverseEngineering/ExpectedResults/E2E_UseAttributesInsteadOfFluentApi/AttributesContext.expected#L16) have the results for an AllDataTypes table which now has every conceivable data type including synonyms.

Thanks for the links. I see that for something like a column Name of type nvarchar(100) we are already just generating .Property(e => e.Name).HasMaxLenght(100).
I think once we have https://github.com/aspnet/EntityFramework/issues/3420 fixed it should be possible to just use .Property(e => e.Name).HasMaxLenght(100).IsUnicode(false) for varchar(100) as well.

Agreed. See comment from @rowanmiller above.

Got it. Thanks for clarifying.

@divega No worries. BTW are we planning to provide a [Unicode(false)] annotation to go with that?

We could. As a general principle I would be conservative about adding new annotations on our own initiative and wait for customer feedback or PRs instead :smile:


Add Folder To Workspace crashes code

VSCode Version: Version 1.18.0 (1.18.0)
OS Version: MacOs High Sierra

Steps to Reproduce:

Click on Open
While the Open dialog is still open, click on the File menu and select "Add Folder To Workspace"

VS Code becomes nonresponsible will crash soon after you close the open dialog and click on something

@teterovic I might have fixed this for insiders, can you try to reproduce there:
You can give our preview releases a try from: https://code.visualstudio.com/insiders/

@bpasero Seems to be fixed 👍


feat: Add grid and responsive template sizing, resolve #33

PR Checklist

[x] Addresses an existing open issue: fixes #033
[x] That issue was marked as status: accepting prs
[x] Steps in CONTRIBUTING.md were taken

Overview

Update page-grid display from flex to grid. Add responsive column and row scaling by using minmax.

LGTM, thanks!


Added Teams Funsettings list

First try at the Funsettings list command.
I noticed that most of the commands use the GraphCommand GetAllItems. But this is coded in a way that you receive Json that contains "value". But in this case that isn't the case so I just return the Json.
Would it be better if I create a class called TeamSettings (because Team already exists) where all the settings are in like funsettings, membersettings,... And then do a graph call that returns everything and just filter in code to return only the funsettings?
Let me know what you think...

Coverage decreased (-0.06%) to 99.944% when pulling 7b1c4044e487b43ac7f6b875252980d1a508c4bb on RickVanRousselt:master into 001ed310d74a45c557ae4cc5556aebdb00aa6d95 on pnp:dev.

I've been going back and forth on this one. In the CLI we have the naming convention where we use get for one item and list for multiple. In this case we're retrieving multiple settings so I went with list. But the multiple settings can be retrieved via a single API call /teams/<id>/funsettings so there is no need to inherit from the ListCommand base class which is meant for retrieving multiple items via multiple API calls (like users). You can inherit from the generic GraphCommand class and pass to command output the whole result as retrieved from the API.

....which is exactly what you've already done! 😄

I am having a look at member, guest and messaging settings which are very similar to this one.
If I retrieve messaging settings from the Graph using v1.0/teams/<teamId>?$select=messagingSettings and pass to output, I get this:

This is because the graph API returns an object with a single property messagingSettings and then the actual messaging settings as the value of that object.

So what I am proposing to do is to have an optional property messagingSettings in the Team interface
export interface Team {
  id: string;
  displayName: string;
  description: string;
  isArchived: boolean | undefined;
  messagingSettings?: {
    allowUserEditMessages: boolean,
    allowUserDeleteMessages: boolean,
    allowOwnerDeleteMessages: boolean,
    allowTeamMentions: boolean,
    allowChannelMentions: boolean
  }
}

And then log the value of the property from the command:
.then((res: Team): void => {
        cmd.log(res.messagingSettings);
});

Which would then give us the settings in the expected format:

I believe the approach should be common for funSettings, messagingSettings, memberSettings and guestSettings.

Makes perfect sense 👍

Thinking of it @vman, it's not really necessary to specify all properties inside funSettings or other settings objects, because we pass the whole property to the output as-is, so doing something like:
export interface Team {
  id: string;
  displayName: string;
  description: string;
  isArchived: boolean | undefined;
  messagingSettings?: any;
}

would be enough.

Ok fair enough.

Damn that's some code review 👍  Thanks a lot... When looking at them I thought "ow yea... that makes perfect sense... why did I do it differently" ;-) Now on to the next one... This stuff is addictive

You're welcome and thanks again for the PR 👍

Merged manually. Thanks! 👏


Default language-specific settings

Now that we have language specific settings we should consider enabling default language-specific settings to work around some of the annoyances for particular languages:
Markdown: Disable intellisense by default:
"[markdown]": {
"editor.quickSuggestions": false
}

Makefile: Always use tabs for indentation since spaces are invalid (related: https://github.com/Microsoft/vscode/issues/4815)
YAML: Always use spaces for indentation since tabs are invalid.

Python: default to spaces since PEP 8 recommends spaces as the standard Python coding style.
F#: default to spaces since the F# code formatting guidelines forbid using tabs.

@rmunn Python might be going a bit far since it still works with tabs right?

@Tyriar Yes, Python does allow tabs, even though its official style guide recommends spaces. But setting spaces as the default in VS Code wouldn't prevent anyone from overriding them with tabs if they choose. I believe that if a language has an official style guide, then any editor capable of per-language settings should default to following that style guide, so that out of the box, the editor will produce code that complies with the style guide. And for Python, that means space indentation, and 4-space indents (https://www.python.org/dev/peps/pep-0008/#id17). Therefore, that's what VS Code should default to for Python files.

Two questions that will probably come up regarding language-specific defaults:

If the language default specifies space indentation but you open a file that uses tab indentation, which one wins? The language default, or the file's previous indentation?
If the language default specifies one setting but an .editorconfig file in the project folder specifies a different setting (and the user has installed the EditorConfig plugin), which should win?

My personal opinion is that the second answer is obvious: .editorconfig is a way to specify a project-specific set of coding standards, and more specific settings should always override less specific settings. Therefore, the .editorconfig file should trump the language default settings if the two conflict.
The first answer is less obvious, but I think in the case of editing an existing file that does not match the language-specific settings, the file's existing indentation style could be considered a "more specific setting", specific to that file. E.g., if the Python standards say "uses spaces for indentation", but I'm working on someone else's code where the other coder used tabs, the editor should default to using tabs for this one file, because that creates consistent indentation. (This is also in line with what PEP 8 says, which is "Tabs should be used solely to remain consistent with code that is already indented with tabs.")
So I think the following set of rules would be good ones to use regarding language-specific defaults:

If the language-specific settings for indentation conflict with what can easily be autodetected from the file (e.g., spaces vs. tabs), then the file's existing indentation style should trump the language-specific default settings.
If the language-specific settings for indentation conflict with an .editorconfig file in the project folder, then the .editorconfig file should trump the language-specific default settings.

@rmunn Good questions and suggestions.
Agreed that .editorconfig always takes the precedence over defaults/user/workspace settings which is also true currently.
Regarding file specific conflicts, you can always say detect the indentation from the file using the property editor.detectIndentation: true. By setting this, editor will always take the indentation from the file which overrides defaults/user/workspace/editorconfig settings. This would be same for default language based editor settings. With this new feature, language extensions can also register this setting to true which will let indentation from file takes the precedence above all.

Here is how an extension can contribute default language specific editor configurations. A new contribution point configurationDefaults is introduced in extension's package.json.
Sample:
"configurationDefaults": {
	"[markdown]": {
		"editor.wrappingColumn": 0,
	        "editor.quickSuggestions": false
	}
}


If no model defined create model from schema

This is not finished, but I would like to have your opinion @dgeb. Is it something you would be happy with adding? I think it will help folks who want to fetch schema from the backend and use upgrade schema.

[ ] handle schema changes (unload models/factories that not part of schema anymore?)
[ ] share model factories between forks and main stores

I think this could be made much more powerful if we expand schema API with a few atomic methods: defineModel(type: string, model: ModelDefinition), defineAttribute(name: string, attribute: AttributeDefinition), defineRelationship(name: string, attribute: RelationshipDefinition) etc. This would make it relatively straightforward to implement a "inference schema from payload" like in m3

This became a bit more involved than what I expected at first. But I am quite happy with the result.
In the current implementation store.cache holds the identityMap. And store.modelFactory holds modelFactoryMap which is a cache on top of Ember DI. There is one instance of this cache per fork. Since I introduced the ability to dynamically create ModelFactories from schema, I do not want to create a new class for each fork.
New implementation creates an instance of identityMap per store but de-correlated from store.cache. Model resolving is moved into a function modelFor. For now it is a black box and does some "magic". It maintains a cache of lookups/Factory Classes per main source. So any fork will use same Factory Classes.


Return a user-visible error if the project already exists

Summary
This indicates to the user if the project they're trying to provision already exists; which may
prompt them to contact their minder administrators.
Change Type
Mark the type of change your PR introduces:

[ ] Bug fix (resolves an issue without affecting existing features)
[x] Feature (adds new functionality without breaking changes)
[ ] Breaking change (may impact existing functionalities or require documentation updates)
[ ] Documentation (updates or additions to documentation)
[ ] Refactoring or test improvements (no bug fixes or new functionality)

Testing
Outline how the changes were tested, including steps to reproduce and any relevant configurations.
Attach screenshots if helpful.
Review Checklist:

[x] Reviewed my own code for quality and clarity.
[ ] Added comments to complex or tricky code sections.
[ ] Updated any affected documentation.
[ ] Included tests that validate the fix or feature.
[ ] Checked that related changes are merged.

coverage: 47.035% (+0.004%) from 47.031%
when pulling f31591b599b2c05c68160b285ff35011340708bd on project-alreadyexists
into 2944b304a00820b14ea0dd086edc86168fb758b2 on main.


Function not found

Hi, nice work
I am trying to use your Datasets of LEDOV, but neither of your code and original LEDOV code provides the detailed generation of gt_saliency_map. Could you please explain how could I make such map using the fixation data(groups of pixel coordinates in LEDOV dataset)?

I found the generate_gt.m but one function is not included in this repo
https://github.com/juanjo3ns/SalBCE/blob/ac52af743b94961cdb44c5d89774b72fc8acfd3e/src/salgan_ledov/generate_gt.m#L108

#1 Already solved here


Rules run on non-JS imports

We have require.extensions patched to import .hbs files - we also have .json imports in a few places.
Here's what I get in these cases:
  3:36  error  Parse errors in imported module '../path/to/file.hbs': Adjacent JSX elements must be wrapped in an enclosing tag (6:1)  import/no-named-as-default
  3:36  error  Parse errors in imported module '../path/to/file.hbs': Adjacent JSX elements must be wrapped in an enclosing tag (6:1)  import/no-named-as-default-member

---
  3:35  error  Unexpected use of file extension "json" for "../../fixtures/google_v3_geocoder/sf_united_states.json"                                import/extensions
  3:35  error  Parse errors in imported module '../../fixtures/google_v3_geocoder/sf_united_states.json': Unexpected token : (2:14)                 import/no-named-as-default
  3:35  error  Parse errors in imported module '../../fixtures/google_v3_geocoder/sf_united_states.json': Unexpected token : (2:14)                 import/no-named-as-default-member
  4:26  error  Unexpected use of file extension "json" for "../../fixtures/google_v3_geocoder/六本木6_10_3_港区_東京都_106_0032_japan.json"                 import/extensions
  4:26  error  Parse errors in imported module '../../fixtures/google_v3_geocoder/六本木6_10_3_港区_東京都_106_0032_japan.json': Unexpected token : (2:14)  import/no-named-as-default
  4:26  error  Parse errors in imported module '../../fixtures/google_v3_geocoder/六本木6_10_3_港区_東京都_106_0032_japan.json': Unexpected token : (2:14)  import/no-named-as-default-member

We have all these extensions defined in settings → import/resolver → node → extensions, because we want import resolution rules applied on them.
How can we apply resolution rules to these files, without applying JS-specific rules to them?

I was able to fix this in my .eslintrc with:
  "settings": {
    "import/ignore": [
      "node_modules",
      ".(json|css)$"
    ]
  },

by default import/ignore defines node_modules (so it won't complain about validation from legacy packages) so you'll have to add it in if you override.

@evidens yes but then the "resolve" rule won't be able to verify that those files exist, will it?

@ljharb nope, import/ignore does not impact resolution. Just parsing for exports.
You can also specify what extensions to parse via import/extensions. See the README for more details.

It'd be nice if I could specify a whitelist instead of a blacklist - ie, "only parse these extensions" instead of/in addition to "ignore these"

That is what the import/extensions setting is: https://github.com/#importextensions

Hmm - I already had that set to just JS and jsx when the original errors happened. Perhaps they're being overlooked for these rules?

That would be a bug. Can you provide a test case that logs a parse error when the extensions setting is set?

It's possible I was using an older version of the plugin - I'll post repro details here if I can reproduce the issue.

I think I've confirmed that was the case. Sorry to bother.


Drop Python 3.6 support

🚀 Feature
Motivation

Python 3.6 EOL on 2021-12-23: https://devguide.python.org/#branchstatus
Some major ml libraries have already dropped Python 3.6 support.

numpy 1.20.0: https://numpy.org/devdocs/release/1.20.0-notes.html
scikit-learn 1.0: https://github.com/scikit-learn/scikit-learn/issues/20084
PyTorch 1.11: https://github.com/pytorch/pytorch/issues/66462

1.10.X should be the last official PyTorch release to support Python 3.6

Pitch

[ ] Remove all CI using Python 3.6

Additional context

If you enjoy Lightning, check out our other projects! ⚡

Metrics: Machine learning metrics for distributed, scalable PyTorch applications.

Flash: The fastest way to get a Lightning baseline! A collection of tasks for fast prototyping, baselining, finetuning and solving problems with deep learning

Bolts: Pretrained SOTA Deep Learning models, callbacks and more for research and production with PyTorch Lightning and PyTorch

Lightning Transformers: Flexible interface for high performance research using SOTA Transformers leveraging Pytorch Lightning, Transformers, and Hydra.

Hey, I wish to contribute to this if this isn't assigned. Any steps on how I can get started?

@Rajathbharadwaj Hi, thanks for having an interest in contributing! This issue has already been addressed partially in #10269, and there is nothing to do at the moment until Python 3.6 EOL planned on 2021-12-23.

Does the Python version badge need an update too?

Yes. Would you be interested in fixing the badge?

@carmocca After some investigation, I find it unnecessary to do some fix on this. The badge in the Readme refers to the one generated by PyPI based on contents written in setup.py. Currently, it generates the badge from tag 1.5.10, on which Python 3.6 is not dropped. It will update automatically in the next release.
setup.py on tag 1.5.10:
https://github.com/PyTorchLightning/pytorch-lightning/blob/9ebdc52ec631df92ca7cfc1ba852801dd36d3864/setup.py#L108-L112
setup.py on current master branch:
https://github.com/PyTorchLightning/pytorch-lightning/blob/f3c2a1338c08e0ab47cf9ca97de54e59e5f3a31c/setup.py#L105-L108

Good to know! Thank you for your time!


Homepage v3 join

Syncing upstream

gonna do some not-encouraged moves now, since we need to release this and Webistry folks are offline. Plus helix local dev server is acting very weird
Plan:

merge from their fork into our homepage-v3
cleanup the unwanted changes and do a rebase push -f
apply my changes to preferenceStore
QA a bit
update hero animation banner to not animate when reduceMotion is on
fix circle-list overflow with a horizontal scroll
QA
Rebase again and cleanup commit history

Ideally we should only merge a PR when things are done, but it is what it is. Hopefully no one uses this branch during my process


Additional feature request - Oncoplot axis reverse

Hello, many thanks to maftools package maintainer.
Regarding oncoplot and coOncoplot, would it be possible to add an axis reverse feature?
Right now x-axis represents each patient sample, but I think it would be visually helpful if we can draw the same plot with y-axis to represent each sample.
Thank you!

This would require lots of code change. I am swamped with other work at the moment, so it might take a while to implement it.