Best practice for multiple IPs?

It seems multiple IPs can be implemented in two ways:

Single NIC with multiple IPs
One per NIC (multiple NICs)

It would be good if the doc could be clearer about what the recommended best approach is, and why. For example, does using multiple NICs with only a single IP per NIC remove the need to configure IP settings within the VM OS? (Those settings sound like an operational nightmare...)
Also, it looks like the doc dates from 2016, is it still accurate?
Thanks!

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: b3b4d2d7-88a3-c493-68f9-39c89fbbcf96
Version Independent ID: 6dff4842-197d-9e60-3c80-b34cc6aaab3e
Content: Multiple IP addresses for Azure virtual machines - Portal
Content Source: articles/virtual-network/virtual-network-multiple-ip-addresses-portal.md
Service: virtual-network
GitHub Login: @anavinahar
Microsoft Alias: anavin

Thanks for the quick response Travis. Sorry, perhaps I wasn't clear. I'm not talking about public IPs at all. I'm just talking about private IPs. It seems there's two ways to have multiple private IPs (multi-NIC vs single NIC), and I'm asking if the multi-NIC approach, with one private IP per NIC, also requires the IP to be configured in the guest OS.

Nope, the primary IP (first IP) on the NIC (multi-NIC or not) doesn't require this.

That's what I thought, thanks for confirming. Please do drop a few words into the doc to clarify this point so others also benefit.

#reassign: @brianlehr

#reassign: @asudbring

Thanks for providing feedback that helps improve our documentation.
We've added some notes to our documentation here to advise customer on whether a multi-NIC  vs multi-IP config option makes the most sense for a given usecase.
https://docs.microsoft.com/en-us/azure/virtual-machines/windows/multiple-nics
https://docs.microsoft.com/en-us/azure/virtual-network/ip-services/virtual-network-multiple-ip-addresses-portal
#please-close


Missing documentation.

:smiley:
btw, nice work!!

@abr4xas 😊Here you go: https://designrevision.com/docs/shards-vue/

Thanks dude!!


x/tools/gopls: improve handling for build tags

We need to handle build tags correctly in the LSP. If a user is on Linux, they should still see completions, diagnostics, etc. for files tagged with any other OS.

Bitten by this also, lost an hour trying to figure out why after migrating to gopls basic functionalities didn't work...no import-organize, no format, no nothing. Afterwards I found that it's was working properly for everything except for files with build tags as mentioned in #31286.

I'm wondering whether this is the right issue to become the umbrella issue for our long-running discussion about context?

This is killing me with integration tests that have build tags. Any workarounds known?

@sjdweb current workaround I'm using is to set the GOFLAGS environment variable. This is the configuration I'm using in VS Code:
"gopls.env": {
        "GOFLAGS": "-tags=test"
    },

This was brought up on Tuesday's golang-tools call.
@christiankiely - the "editor level" GOFLAGS approach your describe works in some cases, but not all. Because setting the flag in that way sets the flag for all modules and packages, i.e. for the gopls instance used by the editor.
In discussions we've had thus far it seems for a complete solution we need to be able to define the sets of valid build flags at various levels:

Editor level (i.e. throughout editor)
Module level
Package (tree) level
File level

We also need:

the ability to specify, from within the editor, which build flags are in operation, because for a given file/package/module there might be multiple valid options
the ability to then pass this choice on a per request basis to gopls

The conclusion on Tuesday's call was broadly that there are other higher priority issues right now; add to that, a solution that doesn't involve LSP spec changes isn't exactly jumping out at us.
cc @ianthehat @dominikh

This was brought up on Tuesday's golang-tools call.
@christiankiely - the "editor level" GOFLAGS approach your describe works in some cases, but not all. Because setting the flag in that way sets the flag for all modules and packages, i.e. for the gopls instance used by the editor.
In discussions we've had thus far it seems for a complete solution we need to be able to define the sets of valid build flags at various levels:

Editor level (i.e. throughout editor)
Module level
Package (tree) level
File level

We also need:

the ability to specify, from within the editor, which build flags are in operation, because for a given file/package/module there might be multiple valid options
the ability to then pass this choice on a per request basis to gopls

The conclusion on Tuesday's call was broadly that there are other higher priority issues right now; add to that, a solution that doesn't involve LSP spec changes isn't exactly jumping out at us.
cc @ianthehat @dominikh

Bitten by this as well. I use build tags to distinguish between normal builds and debug builds. Now VSCode reports logError redeclared in this block error and the file is constantly marked as having errors.

Another populate use case: when using wire, there are two copies of the initializers:

The template in a file with a build tag that never gets compiled
The real one generated by wire with no build tags

gopls highlights them as duplicate definitions because it ignores build tags.
Is there a short term workaround in this simpler use case? Some way to make gopls ignore files with the wireinject build tag?

Thank you for sharing this info. We realize that this is an issue that affects a lot of people, so we're trying to come up with a viable solution. It's a complicated problem, but to start, I think we can try to disable diagnostics on files that would be excluded given your GOOS/GOARCH.

As a data point, I'm experiencing this today in any package that picks up os/user because it uses build tags to decide how to wire in OS user lookup. In my case, it's that analysis fails because cgoLookupHost isn't defined as files aren't being evaluated.
I understand that you'd like for gopls to allow for reading and analysis of files intended for a different GOOS that the one that the editor is on, but given how packages are structured, you'd having to perform analysis on the matrix of build tags. That seems.... time consuming at best. Plumbing through a default tag set seems like an easy way to at least get folks moving again.
I'm happy to look into how to do that if need be! Please just let me know.

Looks like it's also firing from net looking like:
/usr/local/Cellar/go/1.12/libexec/src/net/lookup_unix.go:81:24: undeclared name: cgoLookupHost

@evanphx I also found this issue.
The workaround is launch gopls use CGO_ENABLED=0 or something. Note that might be vscode can't that workaround AFAIK. Also not solved if set CGO_ENABLED=0 to env. Because it is late to place.
https://github.com/golang/go/issues/29202#issuecomment-488469829
Now I develop the client side for IDE written in Go, it's implemented set some env to launch gopls binary using set to exec.Command.Env. I did solve the use it.
Anyway, We should including CGO_ENABLED=0 to gopls send Build info.

@zchee Ah! That makes a lot of sense, I'll start it with CGO_ENABLED=0 and see how it works.

@evanphx
Also, I was send CL for support build tags.
https://go-review.googlesource.com/c/tools/+/178782

@evanphx
FYI, ref for your issue root cause:
https://github.com/golang/go/issues/31705

@stamblerre
Can we close this issue by below CL?
https://github.com/golang/tools/commit/70bf279967a6c40a5e75fb4a31ec8273089700f8

I think we will still need special handling for build tags so that users don't need special configurations to get gopls features in files tagged for different build systems.

@stamblerre
I see, totally agreed.

@sjdweb current workaround I'm using is to set the GOFLAGS environment variable. This is the configuration I'm using in VS Code:
"gopls.env": {
        "GOFLAGS": "-tags=test"
    },

This incurs an Unknown configuration setting error in VS Code 1.36.1 with gopls v0.1.3, and instead I have to use the configuration below to make it work.
"go.toolsEnvVars": {
    "GOFLAGS": "-tags=functional"
},

I recently opened https://github.com/golang/go/issues/33389 to get a better sense of the use cases for build tags. Please add your own use cases if they are not yet listed in this issue - it will help us better understand how to solve this issue.

+1
I'm having issues with VSCode flagging my different function implementations for different versions of go as duplications

RS: You probably already know this, gopls does not handle mutually exclusive build tags at all.  I have one file with '// +build debug', and an almost identical file in the same folder with '// +build !debug'.  gopls flagged every constant, variable and function as being redefined between the two files.  Good luck with the fix.

https://github.com/golang/go/issues/39005 might be of interest to the people following this thread. It's an attempt at defining a build-system-agnostic list of build configurations for a project, in a way that can be consumed by many tools like staticcheck and gopls.

For anyone having issues with wire + VSCode flagging auto generated function implementations as duplications, edit the project settings json and put this:
"go.buildTags": "wireinject"

This solved for me. Have a downside that now your wire.go file will not have any code completion and validation, but you  can just uncomment the build flag when developing to get those back.

in coc.nvim+coc-go, for wire inject, add:
  "go.goplsOptions": {
    "buildFlags": ["-tags=wireinject"]
  },

Is there any timeline on releasing support for build tags in gopls, and consequently in vscode?

We will not add any new behavior to improve build tag handling before gopls/v1.0. For now, the best way to work with gopls and build tags is by using the configurations suggested above.

@stamblerre What's the exact property that needs to be set in settings.json (vscode) to switch build tags?

I would suggest the work-around described in this comment: https://github.com/golang/go/issues/29202#issuecomment-488469829.

for a variable being overwritten based on build constraints,  I tried every suggested config in this thread. it doesn't work.
here is the overwritten case:

when edit a file, such as internal/lsp/lsprpc/lsprpc.go ,
you see a  statement in line 289, "func connectToRemote":
"network, address = autoNetworkAddress(goplsPath, inAddr)",
now, to find the autoNetworkAddress func, you send a 'definition' query to the gopls server.
in current implementation,  'definition' query will return the internal/lsp/lsprpc/autostart_default.go result. and the editor jump to that file directly. this implementation will mislead the developer. i checked the code several times and finally notice the 'build tags'

the propose is to return the internal/lsp/lsprpc/autostart_posix.go , the behavior of 'definition' query should consider the 'build tags', in this case, it is "// +build darwin dragonfly freebsd linux netbsd openbsd solaris".
any suggestion on this case? @stamblerre

To be able to edit windows-specific golang code ("xxx_windows.go") requiring windows-only golang packages on my OSX machine, I had to add this to my VSCode settings:
"go.toolsEnvVars": {
    "GOOS": "windows"
 }

"gopls.env": {
        "GOFLAGS": "-tags=test"
    },

Where does this go? I tried settings.json and I get:

Unknown Configuration Setting

@Merrit: That's correct--the unknown configuration setting message is a warning, but it will still work.

I see. Am I misunderstanding the purpose then?
For example in one of my _linux.go files I am still getting No packages found for open file, unable to access functions from this file, etc.
If I add // +build windows everything works as expected.

Are you working on Windows / adding the Windows tag to the Linux file? OS-specific tags are detected based on your OS, so unless you set GOFLAGS to -tags=linux, you won't get editor features working for the _linux.go files.

Yes, currently working on Windows & having issues working with *_linux.go files. Not sure why I would want to be unable to reference or work on Linux files just because I am on Windows, or vice versa.
Setting this in settings.json seems to have it working, so far:
  "gopls.env": {
    "GOFLAGS": "-tags=linux"
  },

Thank you!

Spoke too soon.
Editor features work fine, but it then fails to run / debug.
undefined: funcFromLinuxFile
I tried adding "buildFlags": "-tags=linux" to launch.json, but that makes it try to compile the linux version which fails quite spectacularly. :)
Also tried "buildFlags": "-tags=test", "buildFlags": "-tags=!linux" and "buildFlags": "-tags '!linux test'".
Only solution so far is to just stop naming things with the *_os.go scheme, which I was given to understand was the preference for conditional compilation. FYI, naming the files featureLinux.go and leaving it be works just fine. Adding // +build linux to that same file breaks things the same as using the *_linux.go naming scheme.

Not sure why I would want to be unable to reference or work on Linux files just because I am on Windows, or vice versa.

This is a current limitation of gopls, and this issue is tracking improving that behavior.

I tried adding "buildFlags": "-tags=linux" to launch.json, but that makes it try to compile the linux version which fails quite spectacularly. :)

You won't actually be able to run code meant for Linux on Windows--my suggestion was just to get editor features for development purposes.

Right, I don't want to run or compile anything meant for a different OS. Just mentioning what I had tried to resolve my issue.
Ideally what I would like is:

Name files by OS to take advantage of conditional compilation, ie feature_windows.go & feature_linux.go
Editor features still work, eg it recognizes the packages, doesn't complain about undeclared variables or functions, etc just because those variables/functions are in a feature_linux.go when I am on Windows, or vice versa.
Still be able to use VSCode's run/debug features (for the code related to the OS I am on).

Currently I can only get 2 & 3 on my list by not naming files by OS nor using the // +build _____ -- which I understand means no conditional compilation.

Wanted to be able to use go generate in a directory to get a go run gen.go called and found gopls doesn't seem to work on the gen.go file because of a mix of build flags in other local files. Can I work around this by invoking vim on gen.go with an environment variable set to something for the benefit of gopls or is moving the gen.go into its own directory my best option?
gopls definition does work from a file that has an ignore build tag, but not if a plain go file in the same directory exists.
$ cat -n gen.go
     1	// +build ignore
     2
     3	package main
     4
     5	import (
     6		"fmt"
     7	)
     8
     9	func main() {
    10		fmt.Println("Hello world!")
    11	}
$ gopls definition gen.go:10:10
gopls: /<snip>/gen.go:10:10: no packages returned: packages.Load error
$ rm config.go
$ gopls definition gen.go:10:10
/<snip>/go1.15.5/src/fmt/print.go:273:6-13: defined here as func fmt.Println<snip>

The command line doesn't really give you much configurability, but you can set the GOFLAGS environment variable before running the gopls command. Otherwise, you can configure gopls.buildFlags or GOFLAGS as described in the examples above.

I am facing this issue as well, appending settings.json with "gopls.env": {             "GOFLAGS": "-tags=debug"           },does not resolve the issue for me.
In my case I have two files thermal.go and thermal_mock.go, with build tags // +build !debug and // +build debug respectively, so I can mock target HW specific functions.
My biggest issue is that Intellisense completely stopped working in the _mock version, and the gopls.env in settings.json didn't help either.
Go 1.15.5, gopls v0.6.0
Any follow up on the issue?

In my case I have two files thermal.go and thermal_mock.go, with build tags // +build !debug and // +build debug respectively, so I can mock target HW specific functions.
My biggest issue is that Intellisense completely stopped working in the _mock version (as in, worked the other day, next day poof) , and the gopls.env in settings.json didn't help either.

Would be happy to help investigate this, but please file a new issue with the following information: https://github.com/golang/tools/blob/master/gopls/doc/troubleshooting.md.

Note for VSCode settings.json in case it's helpful. Before upgrading to 0.6.2 I used to use GOFLAGS.
"gopls": {
  "env": {
    "GOFLAGS": "-tags=<tag1>,<tag2>"
  },
},

After upgrading I started getting No packages found for open file... errors. I switched go.buildFlags and no longer use GOFLAGS without issue it seems.
go.buildFlags: "<tag1>,<tag2>",

Note for VSCode settings.json in case it's helpful. Before upgrading to 0.6.2 I used to use GOFLAGS.
"gopls": {
  "env": {
    "GOFLAGS": "-tags=<tag1>,<tag2>"
  },
},

After upgrading I started getting No packages found for open file... errors. I switched go.buildFlags and no longer use GOFLAGS without issue it seems.
go.buildFlags: "<tag1>,<tag2>",

The fixes here didn't work for me.
I found
env GOOS="openbsd" code
Worked for me at the editor level
P.s. Irrelevant tip: if you also set HISTFILE and open a project folder after "code" then you can have dedicated terminal history and a project folder opened together.

Hello,
I'm facing this issue on linux using emacs. Have tried suggestions above and the one that is working is to delete and re-adding build tag line.
I also tried using VS Code with the same result.

I was finally able to get this working in VS Code by using the following and restarting VS Code.
{
    "go.buildTags": "tag1,tag2"
}

I think gopls shouldn't care about build constraints, or it only cares about the file I'm editing, which I call "constraint aware".

This and #49657 were the only relevant results for my internet searches, so, for historical reasons, my solution for emacs is to use setenv at the global scope and modify GOFLAGS. This isn't perfect but has worked for me:
(setenv "GOFLAGS" "-tags=linux,windows")

Is there a plan to make something like this a permanent in gopls? Is there some problem with just specifying multiple platform tags by default? It hasn't seemed to cause any problems for me specifically. It doesn't make much sense to me that gopls would care about the platform, and simply failing for platform-tagged files breaks the entire workflow of developing cross-platform applications. This is almost certainly an undocumented bug in gopls, unless I missed some documentation some where (which I'd be happy if someone shared :smile:).

@calebstewart That's insteresting. gopls heavily depends on go list and other go commands to parse go code, and by your setting -tags=linux,windows, the flag is passed to all the go commands gopls uses. If you see gopls and so go commands work with -tags=linux,windows, that's by accident, not intentional.
And, more puzzling thing is that AFAIK platform (os/arch) are special and go commands select them based on GOOS/GOARCH environment variables, not based on the -tags flag in most cases. So, I am not sure what's working and what's not working with specifying OSes using -tags.

for vscode users, update your PROJECT_ROOT/.vscode/settings.json like below my resolve this problem:
{
  "go.toolsEnvVars": {
    "GOOS": "js",
    "GOARCH": "wasm"
  }
}

@hyangah interesting, it could have been some configuration specific to this project (it's a work project, and I'm not the one who configured it), then, but that seemed to be the best approximation of the suggestions I was seeing online. Admittedly, I'm not exactly sure why it worked for me either, but all I can say is that it did. :eyes:

I have a similar problem, I have separate files (source_windows.go, linux_windows.go, darwin_windows.go) for setting platform-specific configs, and by default, I don't get any code completion on Windows or darwin codes (I'm using VSCode on Linux) and it shows the following message:
No packages found for open file /home/amir/projects/Memor/memor/pkg/config/config_darwin.go: <nil>.
If this file contains build tags, try adding "-tags=<build tag>" to your gopls "buildFlags" configuration (see (https://github.com/golang/tools/blob/master/gopls/doc/settings.md#buildflags-string).
Otherwise, see the troubleshooting guidelines for help investigating (https://github.com/golang/tools/blob/master/gopls/doc/troubleshooting.md).go list

after adding the following tags I'll get a duplicate declaration error on these files because I'm declaring the same things in these 3 files.
"gopls": {
  "build.buildFlags": ["-tags=linux,windows,darwin"],
}

@Michael-F-Ellis you should be able to work on xmain OR ymain by setting just one of those two build tags, the same as you do when you run go build -tags xmain. As described in https://github.com/golang/go/issues/49104#issuecomment-1008314902, go vet and go build have the same limitations as gopls: only one set of build tags can be active at a given time.
The critical missing feature for gopls is the ability to edit using multiple sets of build tags simultaneously.

Bump

Hello,
Is this topic still in progress or should we not expect any improvement regarding this limitation?
Thanks,
Best regards

Hi all, this issue deserves an update (and sorry @alexgille for missing your inquiry above). Let me summarize the current state of things:
We know that support for multiple sets of build tags is one of the most wanted features. Unfortunately, build tags pose a fundamental problem that we can't fix without changing many other things about gopls. Because many of gopls' algorithms rely on having an active graph of go/types.Packages in memory, and go/types relies on the canonical identity of its objects, gopls can't simply process multiple sets of build tags without maintaining two copies of the package graph (because ~everything will at some point in its transitive imports depend on a package for which there are multiple definitions based on build tags). The package graph drives most of gopls' memory usage, so maintaining N copies of the package graph corresponds to approximately an N-fold increase in memory and performance. Given that memory usage is a huge pain point for our users, a solution that depends on throwing memory at the problem will probably not be viable for many users.
Even if that solution is acceptable for some users with small workspaces, it poses a significant burden on the code in an area where we have historically had a lot of bugs: package metadata tracking and package invalidation. I am currently trying to refactor that area of gopls and fix all the bugs. In<EMAIL_ADDRESS>the representation of metadata was refactored, which contributed to the performance improvements observed in that release. In<EMAIL_ADDRESS>I'm trying to fix all the outstanding bugs we know about related to metadata. So here also, we are hesitant to throw more complexity at the problem.
Longer term, an even higher priority for us is to make gopls scale better and load faster. In order to achieve this, we will inevitably need to break our dependence on the package graph. The first step toward this is rewriting key algorithms to be based on data structures that can be incrementally updated at the package level. Once we do this, the problem of handling multiple sets of build tags becomes tractable.
So resolving this issue can't realistically happen soon, but is part of our longer terms goals for gopls.
In the meantime, I think we can still improve the status-quo. For example:

we can make it easier to switch the set of active build tags (through better handling of configuration changes, and code lenses on build constraints, for example)
we can resolve #49657, making it easier to work with packages defined by a single build tag (e.g. ignore or mage).

For nvim-lspconfig users (with nvim-lsp-installer) following settings worked for me:
lspconfig.gopls.setup {
    settings = {
        gopls = {
            env = {
                GOFLAGS = "-tags=windows,linux,unittest"
            }
        }
    }
}

with files looking like
thing_test.go:
//go:build unittest

package thing_test

and thing.go
package thing

all lsp features work.

Cross-posting from https://github.com/golang/vscode-go/issues/1799:
Is there an alternative without relying on setting env variable in VS code settings?
VS code doesn't support nesting settings so it's annoying when you mix go server code and go wasm code or more broadly different architecture.
Maybe a top-level comment in the file? This seems to have been mentioned at the begging of this thread: https://github.com/golang/go/issues/29202#issuecomment-488590710, https://github.com/golang/go/issues/29202#issuecomment-498926547
(there are many messages, sorry if it has already been mentioned/answered)

@eric-burel as a workaround you can open projects in different VS Code instances. WASM client code can be placed somewhere in project dir and can have it's own workspace settings in .vscode/settings.json. I'm using it this way for many years already.

For emacs and eglot users:
(setq-default eglot-workspace-configuration
              '((:gopls
                 (:ui.completion.usePlaceholders . t)
                 (:ui.diagnostic.staticcheck . t)
                 (:build.buildFlags . ["-tags=wireinject"]))))

Has there been any update on this?  Trying to build wasm plugins for my go program and this is obnoxious to deal with.

This problem is still there, att least a more friendly diagnose tip should be given.

@Torwalt
This still gives a compiler: TestFunc redeclared in this block (see details) [DuplicateDecl] , but I guess it's an improvement :smile:
Also I can not get this to work with //go:build windows in one file and //go:build !windows in another. (I guess this makes sense because these can't both be true at the same time...)
You can also use this instead of the env, which I find a bit cleaner:
settings = {
    gopls = {
        buildFlags = { "-tags=!windows,windows,darwin" },
    },
},

I currently work in a repo that uses build tags for test files VS Code throws following (inaccurate) error about workspaces when a build flag is present. Setting the tags in the env variables sent to gopls does work around it, I just wanted to inform of another instance of this issue.
This file is within module ".", which is not included in your workspace.
To fix this problem, you can add a go.work file that uses this directory.
See the documentation for more information on setting up your workspace:
https://github.com/golang/tools/blob/master/gopls/doc/workspace.md.go list

@mxygem can you say more about how you're using build tags in test files? Which build tags, and how are you using them?

Omg @Torwalt thank you!!

Hi folks! I'm working on landing improvements to build tag support for<EMAIL_ADDRESS> Specifically, https://go.dev/cl/551897 added logic so that when you open a file constrained by GOOS or GOARCH, gopls will try to find a GOOS/GOARCH combination that includes that file, and will start tracking a build for the new configuration.  This means that most gopls functionality will Just Work when, for example, you open up a *_darwin.go file while working on linux.
If you're interested in being an early tester, you can install the first prerelease:
go install<EMAIL_ADDRESS>
In the workaround suggested above (https://github.com/golang/go/issues/29202#issuecomment-1233042513), gopls loads only one build configuration, modified to include files for both linux and windows, but this will often lead to spurious build errors for duplicate declarations.  Now that it supports multiplexing across multiple builds (#57979), gopls can finally support multiple GOOS/GOARCH combinations simultaneously. If you are testing out the prerelease, please remove any buildFlags configuration from your settings.
If you encounter problems, please let me know and revert to gopls@latest. This is a rather large change to the way gopls operates, and so will require some time to polish before it can be released. Among the potential new bugs, we may encounter new performance edge cases, or possibly conflicting diagnostics from different builds (though I have tried to mitigate both). Additionally, we may require additional UX improvements to make it clearer which build configuration is being used for a given file.
One other area where we could improve build tag support is by automatically handling go version constraints (e.g. //go:build !go1.20). After consulting with the team and Go command experts such as @bcmills and @matloob, we think it is too complex and potentially problematic to support dynamic builds at different Go versions. We also expect that this is an order of magnitude less important than GOOS/GOARCH support -- let us know if you disagree.

@findleyr re:

@mxygem can you say more about how you're using build tags in test files? Which build tags, and how are you using them?

I may have a similar scenario to what @mxygem described here.
I have a number of exercises for students, where I provide a template to ensure that our tests are compatible with a student submitted solution. Here is an example:
Template provided to students (rot13.go):
//go:build !solution   // This line is actually removed before we provide it to students.

package cipher

type rot13Reader struct{ r io.Reader }

func (r rot13Reader) Read(p []byte) (n int, err error) {
	return 0, nil
}

Test provided to students (rot13_test.go):
func TestRot13(t *testing.T) { ... }

We also have a solution file (rot13_sol.go) that we don't provide to students:
//go:build solution

package cipher

These files are in the same folder like this:
cipher/
├── rot13.go
├── rot13_sol.go
└── rot13_test.go

From the command line I can test that the template version fails because the solution tag is not set:
% go test
--- FAIL: TestRot13 (0.00s)
    rot13_test.go:33: rot13.Read("Go programming is fun."): (-want +got):
...

And similarly, that the rot13_sol.go version passes the tests because the solution tag is set:
% go test -tags solution
PASS
ok  	dat520/lab1/gointro/cipher	0.280s

This approach is convenient because I can keep the template, test, and the solution in same folder.
With VSCode, I can do:
    "gopls": {
        "buildFlags": [
            "-tags=solution"
        ]
    },

To enable compilation of the rot13_sol.go file, and switch to -tags=!solution to enable compilation of the rot13.go file.
However, I'm unaware of any solution to avoid the error:
No packages found for open file ... /lab1/gointro/cipher/rot13.go.
This file may be excluded due to its build tags; try adding "-tags=<build tag>" to your gopls "buildFlags" configuration
See the documentation for more information on working with build tags:
https://github.com/golang/tools/blob/master/gopls/doc/settings.md#buildflags-string.

Apologies for the long message, and the fact that I didn't take the time to read through the entire issue history. Anyway, I hope this can serve as another example of how tags are being used; I suspect others use it similarly.

@meling thanks for explaining your use-case. Indeed, there's no way to avoid the error you report in whichever file is excluded by the current configured build tags. In general, there's nothing we can do about this automatically, since it's not possible to guess the set(s) of build tags to use.
Theoretically, since we now support multiple builds per folder, we could accept something like
    "gopls": {
        "buildFlags": [
            [],
            ["-tags=solution"]
        ]
    },

I.e., overload the "buildFlags" setting to accept multiple sets of flags.  I'd really like to avoid this if possible, because it complicates the configuration significantly. I wonder how many others would be interested in configurations like this.

@findleyr is there any point in using "gopls.BuildFlags" instead of "go.buildTags"?

@inliquid I believe "gopls.buildFlags" affects only gopls, whereas "build.buildFlags" affects all functionality (gopls, test, linter, debugger, etc.), which may or may not be desirable.  "go.buildTags" is an older configuration mechanism that was generalized to "buildFlags".

@findleyr thanks for your reply.
For my "simple" use-case where there is a binary choice, would it be possible to recognize the tag of the current editor window and just remove the error from source files whose tag is the negation? And then switch if the active editor window changes to the negated tag.
It is not clear to me if dynamically "guessing" based on active editor window is possible.

@meling you're right, we could do that if there is only one build tag, though probably not anything more complicated. For example, we do have support for tags that are used to isolate scripts, such as //go:build ignore, via the "standaloneTags" configuration, and that looks for files with a build constraint consisting of a single tag.

@findleyr thanks for the pointer. Would it be possible to lift the restriction: Gopls considers a file to be a standalone main file if and only if it has package name "main" ?? Maybe then my use case would work. Or would it be preferable to support my use case via a separate configuration option?
Either way I appreciate the work you are doing to improve the plugin and gopls. Thank you so much!

@findleyr I am trying out the new gopls and it seems to work perfectly.
The only thing that I'm wondering is if I'm using go to definition on a function that is both declared in a file with a Windows and Linux build flag it goes to the Linux implementation (which makes sense, I'm on Linux).
Is it meant to show both definitions (similar to go to implementation) or is this expected behaviour?

@arnevm123 thanks for testing, and regarding your question this is expected behavior.  For each open file there is one "default" build, which is first and foremost the default build on your system, followed by the first match from here. This ordering is somewhat arbitrary, though first class ports are preferred. We do need a fixed order for determinism.
I'd prefer if we could return all definitions, but unfortunately for technical reasons this is really intractable. Note that a file without any build constraints matches all ports. We can't feasibly return every single definition across any port, because this would be much more expensive for little value in the common case. Note that the toolchain (Notably go list and the type checker) only operates on one build context at a time, so to answer questions about multiple build contexts we need to do additional work for each.  It is infeasible to do 50x the work (there are around 50 supported ports), so we'd have to try to be smarter by e.g. looking at ignored files in the same directory as the definition to see if there are other declarations of the same symbol. At that point our heuristic is liable to be flaky and/or buggy, and is tightly coupled to the go command (taking us even farther from supporting other build systems). Still, it may be worth pursuing at some point.
For now, I think we should keep it simple. We're going from gopls completely not working to mostly working, albeit with some surprises. Of course we'd greatly appreciate any alternative suggestions, or ways that we could make the current behavior more transparent.

@meling

Gopls considers a file to be a standalone main file if and only if it has package name "main" ?? Maybe then my use case would work.

I think there's a fundamental difference between scripts, for which there may be many in the same directory, each consisting of a single file, and your use case, for which you want to have at most two versions of your package in the directory. In your use case, I assume you want gopls to resolve packages declarations contained in other unconstrained files in the same directory (for example a common.go file that is shared by both the solution and !solution builds).

@meling I think the problem is that we could perhaps make //go:build solution work automatically by creating a new build with -tags=solution overlaid, but then users may be confused when opening a file tagged //go:build (solution || experiment) doesn't work automatically, and we don't want to get into the business of solving constraint equations.  The special handling for //go:build ignore, is justifiable because it's an extremely common pattern for scripts.
If enough users want this, we can reconsider. But for now, for the same reasons as https://github.com/golang/go/issues/29202#issuecomment-1889625558, let's keep it simple.
(and thanks again for the feedback!)

<EMAIL_ADDRESS>will be released soon (likely next week) containing the improvements discussed above. If you're interested to try it out, please install the latest prerelease, which is the release candidate:
go install<EMAIL_ADDRESS>
(this differs from -pre.3 by just one minor CL)
With this release, I think working on multiple GOOS and GOARCH combinations is much better, though still not perfect. To follow up, I filed:

#65755
#65757
#65758

This is in addition to @meling's:

#65089

I think we're ready to close this issue in favor of the more specific follow-up items above. Please try out the release and let us know if you have feedback, either by commenting on or :+1:'ing one of the issues above, or filing a new issue describing the improvement you'd like to see (or bug you observe). Thanks!

To clarify one point: the issue title "improve handling for build tags" could certainly be interpreted as also referring to better support for custom build tags, in addition to multiple GOOS/GOARCH. However, the issue description specifically mentions "completions, diagnostics, etc. for files tagged with any other OS", and I think we've achieved that in the v0.15.0 release.
I think better support for user-defined tags is covered by these two issues specifically:

https://go.dev/issue/65089
https://go.dev/issue/65757

Those issues both address ways that gopls could support working on multiple sets of user-defined tags. In #65089, it is proposed that gopls could automatically detect when there is one tag that separates files in a package. In #65757, it is proposed that users could explicitly configure multiple sets of tags.


How do i remove windows credentials using this?

Hello i need help with deleting a windows credentials with the name "x".

I tried using this.
Simple.CredentialManager.Credential cred;
how should i use "cred" variable

I deleted the generic ones. But i could not delete the windows credentials is it not possible?

Load() and Delete() an Credential instance to remove it from the Windows Credential Store.


Run linting and tests for the dev branch

Hmm, apparently the test still fails, due to a stop token being included when calculating the peptide mass. Considering that this PR doesn't change any of the Casanovo code and the previous commit on dev passed all tests, is this possibly due to a change that meanwhile happened in DepthCharge @wfondrie (despite pinning to version 0.2.x)?


Support for Typescript 2

It would be nice if this project would support the include property in the tsconfig.json file which is introduced by Typescript 2.

duplicated #48


Following downloaded images bug

What steps will reproduce the problem?
Download a batch of images first and after that download it again. You see that it will not follow the downloaded images when they are skipped like in the previous versions.
What is the expected behavior? What do you get instead?
Following the images even when they are skipped because they already exist
How often does this problem occur? On which sources?
Always and I guess on every source (tried with konachan)
What version of the program are you using? On what operating system?
using the latest version 6.0.0 with windows 10
Please provide any additional information below

Indeed, only actual downloads are currently being "followed", instead of also following errors and skipped images (from blacklisting or already existing).
I pushed a fix, and I'll release v6.0.1 tonight, thanks for the report! 👍


Provide option to generate client certificates with ECDSA keys

Elliptic curve cryptography has been fully supported in OpenVPN since 2.4.0 (~2014) and is much less computationally intensive than RSA - ideal for client certificates going on mobile phones. There was a commit in 2013 in the easy-RSA changelog adding ECDSA support, so it's already built-in there too. Hopefully, this option can be provided for pivpn as well.

not sure what exactly would have to be done.  I'd have to research.  already set to tls min 1.2 so you surely aren't using any weak ciphers at this point.

have to see what this entails.  the protocol already set to tls min v 1.2 so no bad ciphers are being used.  I'd have to research how to get easy rsa to use a specific cipher.  and I don't want it to break any clients either.

This isn't supported in Easy-RSA 2.0. :(

Copying relevant paragraph from above link, yeah requires Easy-RSA 3.0:
"Support for generating an ECDSA certificate chain is available in EasyRSA (in
spite of it's name) since EasyRSA 3.0. The parameters you're looking for are
'--use-algo=ec' and '--curve=<curve_name>'. See the EasyRSA documentation for
more details on generating ECDSA certificates."

hmm so should this be an option or if implemented simply used?  I don't want to present too many options especially why would someone not want to use this?

@arikalfus I started this.  It won't be an option, we'll just do it.
We'll use our own pivpn releases of easy-rsa to accomplish:
https://github.com/pivpn/easy-rsa/releases/tag/3.0.1-pivpn

So the auto update will cover this in existing installs? Where does one check if it has been updated?

Sorry the the delay in responding. Re: why would someone be want an ECDSA key - can't think of a reason.
Cloudflare has a good article from a few years ago on why ECDSA keys are 'better' than RSA keys. https://blog.cloudflare.com/ecdsa-the-digital-signature-algorithm-of-a-better-internet/
TLDR quote: "Why is ECDSA the algorithm of choice for new protocols when RSA is available and has been the gold standard for asymmetric cryptography since 1977? It boils down to the fact that we are better at breaking RSA than we are at breaking ECC."
An ECC-256 key is generally equivalent to an RSA 2048-bit key, and an ECC-512 bit key is equivalent to RSS 4096-bits. If you're going to choose just one, go with ECC-512 I'd say.

@0-kaladin: Are you currently working on this? If not, can I give it a try?

@redfast00 it was next on my list to do over next couple days but I don't mind deferring to you if you want to take a stab at it.
The only thing i did so far was add this var in the install.sh
easyrsaRel="https://github.com/pivpn/easy-rsa/releases/download/3.0.1-pivpn/EasyRSA-3.0.1-pivpn.tgz"
basically, don't install easy-rsa from apt.  instead wget that.  extract to easy-rsa then should have the ECDSA options.
I just updated the test branch with master if you want to work from there.

@0-kaladin: what editor are you using? Every time you change a line, there is a trailing white space, and this results in weird diff's when comparing code.

Vi. Or vim .  I can ensure that doesn't happen in the future.
On Thu, Nov 24, 2016, 13:52 redfast00<EMAIL_ADDRESS>wrote:

@0-kaladin https://github.com/0-kaladin: what editor are you using?
Every time you change a line, there is a trailing white space, and this
results in weird diff's when comparing code.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/pivpn/pivpn/issues/53#issuecomment-262831847, or mute
the thread
https://github.com/notifications/unsubscribe-auth/ADc_mDgyTr0Nmfht6wPHdYQuKMkYYHlsks5rBdzwgaJpZM4JOPEU
.

Don't worry too much about it. (BTW, you can use :%s/\s\+$//e to strip all trailing whitespaces in vim.)

I can't get easyrsa3 to generate ECDSA keys. I have set the env variables $EASYRSA_ALGO and $EASYRSA_CURVE to respectively ec and secp256r1. Both with the ./easyrsa build-ca and the ./easyrsa build-client-full, it says it's using RSA 2048 bits.
This will also be a lot of effort to rewrite the install script and the pivpn script. Also, mandatory XKCD. It would be cool to have ECDSA, but I don't really see the added value for home users and this might introduce new bugs. I don't know if ECDSA is supported on all clients we currently support.

Let me take a look and see what is involved.
On Thu, Nov 24, 2016, 15:21 redfast00<EMAIL_ADDRESS>wrote:

I can't get easyrsa3 to generate ECDSA keys. I have set the env variables
$EASYRSA_ALGO and $EASYRSA_CURVE to respectively ec and secp256r1. Both
with the ./easyrsa build-ca and the ./easyrsa build-client-full, it says
it's using RSA 2048 bits.
This will also be a lot of effort to rewrite the install script and the
pivpn script. Also, mandatory XKCD https://xkcd.com/538/. It would be
cool to have ECDSA, but I don't really see the added value for home users
and this might introduce new bugs. I don't know if ECDSA is supported on
all clients we currently support.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/pivpn/pivpn/issues/53#issuecomment-262840430, or mute
the thread
https://github.com/notifications/unsubscribe-auth/ADc_mLPgwRD-JKbnZicw5vOihmrhP5ZYks5rBfGvgaJpZM4JOPEU
.

The value is in the reduced computational intensity (for me, this allows me to run a VPN on my mobile phone sacrificing much less battery power). However, the point about supporting all client is a good one - I'm not sure what the cutoff is, but there are some "old" clients that won't support it. That was the reason behind my original request for it to be an added option, as opposed to replacing the keys. Whether the power/speed savings are worth it vs. the necessary refactoring I'd have to leave to you guys to determine.
Here's an article comparing the speed and computational efficiency of RSA vs ECC: https://securitypitfalls.wordpress.com/2014/10/06/rsa-and-ecdsa-performance/
Summary: ECDHE and  ECDSA with 256 bit curves is 2.7 times faster than 2048 bit RSA with 256 bit ECDHE and 3.4 times faster than 3072 bit RSA alone.

I got it going:
root@raspberrypi:/etc/openvpn/easy-rsa/easyrsa3# ./easyrsa build-ca

Note: using Easy-RSA configuration from: ./vars
Generating a 384 bit EC private key
writing new private key to '/pki/private/ca.key.eoNTzv7aeX'
Enter PEM pass phrase:
Verifying - Enter PEM pass phrase:

let me play around with it a bit, might not be too hard.  easy-rsa3 seems to simplify a few things.
I'm not sure clients will be an issue, Note that i have tls 1.2 as a parameter already for clients which no old clients would support.
I suspect anyone using this is installing on their android, iphone, windows, linux, or mac.  All have modern clients supporting the latest.  I just don't see old clients coming into play here but it'd be revealed in my testing if any of the current ones break.

I haven't had a ton of free time.  just pushed first set of changes up to test branch.
that covers the core server changes.  next up server.conf adjustments then the pivpn side for clients.

@arikalfus @redfast00
almost done.  just working on pivpn add, pivpn list (done), pivpn revoke now.
Will you guys have any time to test before I push to master?  I've been unit testing a ton but the more the merrier.

I'm preparing for my exams and won't have any time to test it out. Will definitely check it out after they're done.

@0-kaladin I could test this when it's ready. On Raspbian and Ubuntu, which I don't have a doubt you're covering, but for an extra 👍 that it's working.

It is ready from the testing branch now. Wiki has the curl for getting from
that branch. Thanks.
I still have more testing myself before I push to master.
On Tue, Dec 6, 2016, 18:49 Ari Kalfus<EMAIL_ADDRESS>wrote:

@0-kaladin https://github.com/0-kaladin I could test this when it's
ready. On Raspbian and Ubuntu, which I don't have a doubt you're covering,
but for an extra 👍 that it's working.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/pivpn/pivpn/issues/53#issuecomment-265311017, or mute
the thread
https://github.com/notifications/unsubscribe-auth/ADc_mKHW8GGFbq4hGYfAuIhDTUb2AbBZks5rFfSSgaJpZM4JOPEU
.

Short Story
EC needs openvpn 2.4 on the server, which we can't get reliably install + it is only RC1 at this time.  I've merged all my modifications anyway as easyrsa3 is better, easier, and now we can trivially go to EC if/when it is prudent.
Long Story
So all the changes I've merged made a ton of little improvements, but of course the effort was switching everything to use easyrsa3.  This (unlike openvpn 2.4) has been out for a while and doesn't get frequent updates to source.  So I have a fork of it here in the pivpn org where i can merge any changes they make and cut our own releases from it.  This is a good setup for easy-rsa due to what I mentioned above but not something I'd like to do for openvpn itself.  I'd prefer to get that from a deb or package etc and there is no openvpn 2.4 I see for the arm architecture.
The benefits of merging everything except the EC piece (I moved that back to RSA), is that with easyrsa3 there is a cn-only mode.  IE we don't need to supply country, org etc all the stuff that doesn't matter in these types of certificates.  You also don't source vars it just reads the file with options.  Generally just using easyrsa3 is a bit easier and cleaner IMO.
I'll close this issue and we can continue to discuss EC with openvpn 2.4 in the new issue I created that is referenced above.


Errors when running with node 8.11

/Users/merickson/Documents/code/node/test-signale/node_modules/signale/signale.js:149
signale.push(chalktype.color);
^
TypeError: type.badge.padEnd is not a function
at Signale._buildSignale (/Users/merickson/Documents/code/node/test-signale/node_modules/signale/signale.js:149:49)
at Signale._logger (/Users/merickson/Documents/code/node/test-signale/node_modules/signale/signale.js:79:20)
at Object. (/Users/merickson/Documents/code/node/test-signale/index.js:3:9)
at Module._compile (module.js:570:32)
at Object.Module._extensions..js (module.js:579:10)
at Module.load (module.js:487:32)
at tryModuleLoad (module.js:446:12)
at Function.Module._load (module.js:438:3)
at Module.runMain (module.js:604:10)
at run (bootstrap_node.js:389:7)
To Reproduce
Using node 8.11, I have a simple index.js calling the same routes that you do in the demo
Expected behavior
Expect to see output as shown in demo
Screenshots

Technical Info (please complete the following information)

OS: macOS 10.12.6

Signale Version: 1.0.1

Node.js Version: 8.11

Additional context
I have tested with node 8.9 and newer node versions and all seems to work just fine (seems to be node 8.11 issue -- which is important for us as it is the latest 8.x LTS)

Well, I am not quite sure what happened, but after posting this error (you can see it is indeed an error based on the screenshot) all seems to be working now?   Not quite sure what changed.


simplify retrieval of activation instances

See VAL-423
A couple of remarks

Thomas' work of resetting the context stack perhaps resulted in (I think) a more easy and robust retrieval of the first layer of instances out of the stack.
Instead of filtering out None, we can keep the None in. It was mentioned before that the difficulty with this would be to distinquish between 'None because no result is found' and 'None as a result'. I'm still unsure how to handle this generically in validation_handling. Especially this line might give us some trouble

            if inst is None:
                return

Great! This is more or less what I was trying to write in Jira as well. But maybe we can do the same in the given handling branch. Instead of ever executing a given statement on None, just immediately propagate it to None in the stack/context.instances.
I see quite some cases of "Attribute not found" in the tabulate outcome. I think even if we previously filtered out top level Nones in context.instances. We don't filter out [None,None] or even [None]. Which we would get in the case of multiple indirections of aggregates such as Product>ProductDefinionShape.
After deployment we can work on our own NoneType sibling that we can use to indicate the difference between NotApplicable/EmptyValueInModel.

But maybe we can do the same in the given handling branch. Instead of ever executing a given statement on None, just immediately propgate it to None in the stack/context.instances

Done this in given default Nonetype output . In case of None, it doesn't execute the statement but just returns None (therefore we don't get the errors that occur when executing something on inst=None).

Which we would get in the case of multiple indirections of aggregates such as Product>ProductDefinionShape.

I'm not sure this would be a problem. How I see it currently: in map_sate, we recursively go over the list until we get an item that is not a sequence. So, instead of calling apply_operation (which in turn calls the given implementation) on [None, None] oncee, we'd call apply_operation twice, once for each None in that list. With the latest commit [None, None] will therefore output [None, None].
The exception for this is the depth=1 cases. This will call the step_imp function on on [None, None]. However, only current implementation is 'Its final segment', selecting the last element in the list. This should, again, just return None.
Or do you still get the same errors? So far I'm not, but I'll still be running some files in the gherkin repository this afternoon.

After deployment we can work on our own NoneType sibling that we can use to indicate the difference between NotApplicable/EmptyValueInModel.

Agree. I think it's a good example of what you stated

it's mostly just making fully explicit all our implicit understanding

I'm not sure this would be a problem

No it's not a problem. It's just an observation. We recursively go into context.instances potentially returning None. So in addition to context.instances = [None, None] we could have something like context.instances = [[None, None], [None, None]]. But we only filtered context.instances = list(filter(None, context.instances)). So after that filtering, in the first case, we would end up with context.instances = []. In the second case we would retain context.instances = [[None, None], [None, None]]. At least that's my interpretation.
Anyway, I'm really in favour of this PR. +7 -34 is really a good sign. I think this again greatly simplifies things.

But let's wait until monday to see how we proceed with this. I think in the last couple of days we've been working on a much better mental model behind how we execute our steps. It's just a bit unfortunate that all of this comes now. At some point we said "let's just merge in the decorator branch, because anyway it's better than what we have now", but we never really tied up all the loose ends after that.


running issue

I installed Tfold and ran it. But I got the following issue. Can you let me know how to solve it? Thank you.
$ ./run_alphafold.sh
2024-07-16 10:13:16.461777: I tensorflow/stream_executor/platform/default/dso_loader.cc:53] Successfully opened dynamic library libcudart.so.11.0
:219: RuntimeWarning: scipy._lib.messagestream.MessageStream size changed, may indicate binary incompatibility. Expected 56 from C header, got 64 from PyObject
I0716 10:13:17.528547<PHONE_NUMBER>41792 tfold_run_alphafold.py:151] processing 15 inputs...
I0716 10:13:17.684368<PHONE_NUMBER>41792 xla_bridge.py:231] Unable to initialize backend 'tpu_driver': Not found: Unable to find driver in registry given worker:
I0716 10:13:17.799987<PHONE_NUMBER>41792 xla_bridge.py:231] Unable to initialize backend 'tpu': Invalid argument: TpuPlatform is not available.
I0716 10:13:19.274816<PHONE_NUMBER>41792 tfold_run_alphafold.py:172] Have 1 models: ['model_1']
I0716 10:13:19.274942<PHONE_NUMBER>41792 tfold_run_alphafold.py:176] Using random seed<PHONE_NUMBER>09738379 for the data pipeline
I0716 10:13:19.275121<PHONE_NUMBER>41792 tfold_run_alphafold.py:87] Predicting for id 0
Traceback (most recent call last):
File "/storage/Binh/MHC-pep-binding-predcition/dataset/TFold/tfold-release/tfold_run_alphafold.py", line 196, in
app.run(main)
File "/home/tbnguyen/miniconda3/envs/tfold-env/lib/python3.8/site-packages/absl/app.py", line 312, in run
_run_main(main, args)
File "/home/tbnguyen/miniconda3/envs/tfold-env/lib/python3.8/site-packages/absl/app.py", line 258, in _run_main
sys.exit(main(argv))
File "/storage/Binh/MHC-pep-binding-predcition/dataset/TFold/tfold-release/tfold_run_alphafold.py", line 186, in main
predict_structure(sequences=sequences,msas=msas,template_hits=template_hits,renumber_list=renumber_list,
File "/storage/Binh/MHC-pep-binding-predcition/dataset/TFold/tfold-release/tfold_run_alphafold.py", line 92, in predict_structure
feature_dict=data_pipeline.process(sequences,msas,template_hits)
File "/storage/Binh/MHC-pep-binding-predcition/dataset/TFold/tfold-release/tfold_patch/tfold_pipeline.py", line 135, in process
msa_features=make_msa_features(msas)
File "/storage/Binh/MHC-pep-binding-predcition/dataset/TFold/tfold-release/tfold_patch/tfold_pipeline.py", line 106, in make_msa_features
for sequence_index, sequence in enumerate(msa.sequences):
AttributeError: 'tuple' object has no attribute 'sequences'

Hi there! Which version of AlphaFold are you using? If it is >2.1.0, that's probably the issue. You can get v2.1.0 here: https://github.com/google-deepmind/alphafold/releases/tag/v2.1.0

Thank you, Victor, for your prompt reply. I reinstalled Alphafold 2.1, but I got the following error
$ ./model_pmhcs.sh
MHC loading from MHC.pckl. To update the pickle file, set use_pickle to False
loaded 26122 MHC sequences in  1.3 s
2024-07-16 13:13:15.374743: I tensorflow/stream_executor/platform/default/dso_loader.cc:53] Successfully opened dynamic library libcudart.so.11.0
usage: model_pmhcs.py [-h] [--date_cutoff DATE_CUTOFF] input working_dir
model_pmhcs.py: error: the following arguments are required: input, working_dir
2024-07-16 13:13:17.756661: I tensorflow/stream_executor/platform/default/dso_loader.cc:53] Successfully opened dynamic library libcudart.so.11.0
:219: RuntimeWarning: scipy._lib.messagestream.MessageStream size changed, may indicate binary incompatibility. Expected 56 from C header, got 64 from PyObject
Traceback (most recent call last):
File "tfold_run_alphafold.py", line 196, in
app.run(main)
File "/home/tbnguyen/miniconda3/envs/tfold-env/lib/python3.8/site-packages/absl/app.py", line 312, in run
_run_main(main, args)
File "/home/tbnguyen/miniconda3/envs/tfold-env/lib/python3.8/site-packages/absl/app.py", line 258, in _run_main
sys.exit(main(argv))
File "tfold_run_alphafold.py", line 146, in main
with open(FLAGS.inputs,'rb') as f:
FileNotFoundError: [Errno 2] No such file or directory: '/inputs/input.pckl'
usage: collect_results.py [-h] working_dir
collect_results.py: error: the following arguments are required: working_dir
(tfold-env) tbnguyen@baker:/storage/Binh/MHC-pep-binding-predcition/dataset/AF2.1/alphafold-2.1.0/tfold-release$
(tfold-env) tbnguyen@baker:/storage/Binh/MHC-pep-binding-predcition/dataset/AF2.1/alphafold-2.1.0/tfold-release$ /storage/Binh/MHC-pep-binding-predcition/dataset/AF2.1/alphafold-2.1.0/tfold-release/tmp/modeling/run_alphafold.sh
2024-07-16 13:14:36.940493: I tensorflow/stream_executor/platform/default/dso_loader.cc:53] Successfully opened dynamic library libcudart.so.11.0
:219: RuntimeWarning: scipy._lib.messagestream.MessageStream size changed, may indicate binary incompatibility. Expected 56 from C header, got 64 from PyObject
I0716 13:14:38.102266<PHONE_NUMBER>88576 tfold_run_alphafold.py:151] processing 15 inputs...
I0716 13:14:38.267307<PHONE_NUMBER>88576 xla_bridge.py:231] Unable to initialize backend 'tpu_driver': Not found: Unable to find driver in registry given worker:
I0716 13:14:38.389492<PHONE_NUMBER>88576 xla_bridge.py:231] Unable to initialize backend 'tpu': Invalid argument: TpuPlatform is not available.
I0716 13:14:39.908838<PHONE_NUMBER>88576 tfold_run_alphafold.py:172] Have 1 models: ['model_1']
I0716 13:14:39.909023<PHONE_NUMBER>88576 tfold_run_alphafold.py:176] Using random seed<PHONE_NUMBER>243092519 for the data pipeline
I0716 13:14:39.909242<PHONE_NUMBER>88576 tfold_run_alphafold.py:87] Predicting for id 0
I0716 13:14:40.357227<PHONE_NUMBER>88576 templates.py:878] Searching for template for: NYNYLYRLFGSHSMRYFSTSVSRPGRGEPRFIAVGYVDDTQFVRFDSDAASQRMEPRAPWIEQEGPEYWDEETGKVKAHSQTDRENLRIALRYYNQSEAGSHTLQMMFGCDVGSDGRFLRGYHQYAYDGKDYIALKEDLRSWTAADMAAQITKRKWEAAHVAEQQRAYLEGTCVDGLRRYLENGKETLQRT
I0716 13:14:40.404983<PHONE_NUMBER>88576 templates.py:267] Found an exact template match 3wlb_0_A.
I0716 13:14:40.458794<PHONE_NUMBER>88576 templates.py:267] Found an exact template match 4f7t_0_A.
I0716 13:14:40.648298<PHONE_NUMBER>88576 templates.py:267] Found an exact template match 3vxs_0_A.
I0716 13:14:40.709346<PHONE_NUMBER>88576 templates.py:267] Found an exact template match 5wwi_0_A.
I0716 13:14:40.716603<PHONE_NUMBER>88576 tfold_pipeline.py:142] Final (deduplicated) MSA size: 8163 sequences.
I0716 13:14:40.716830<PHONE_NUMBER>88576 tfold_pipeline.py:143] Total number of templates (NB: this can include bad templates and is later filtered to top 4): 4.
I0716 13:14:40.720921<PHONE_NUMBER>88576 tfold_run_alphafold.py:97] Running model model_1 on 0
2024-07-16 13:14:42.548886: I tensorflow/stream_executor/platform/default/dso_loader.cc:53] Successfully opened dynamic library libcuda.so.1
2024-07-16 13:14:42.549331: I tensorflow/core/common_runtime/gpu/gpu_device.cc:1733] Found device 0 with properties:
pciBusID: 0000:65:00.0 name: Quadro P5000 computeCapability: 6.1
coreClock: 1.7335GHz coreCount: 20 deviceMemorySize: 15.88GiB deviceMemoryBandwidth: 269.00GiB/s
2024-07-16 13:14:42.549363: I tensorflow/stream_executor/platform/default/dso_loader.cc:53] Successfully opened dynamic library libcudart.so.11.0
2024-07-16 13:14:42.551009: I tensorflow/stream_executor/platform/default/dso_loader.cc:53] Successfully opened dynamic library libcublas.so.11
2024-07-16 13:14:42.551099: I tensorflow/stream_executor/platform/default/dso_loader.cc:53] Successfully opened dynamic library libcublasLt.so.11
2024-07-16 13:14:42.551816: I tensorflow/stream_executor/platform/default/dso_loader.cc:53] Successfully opened dynamic library libcufft.so.10
2024-07-16 13:14:42.552057: I tensorflow/stream_executor/platform/default/dso_loader.cc:53] Successfully opened dynamic library libcurand.so.10
2024-07-16 13:14:42.552321: W tensorflow/stream_executor/platform/default/dso_loader.cc:64] Could not load dynamic library 'libcusolver.so.11'; dlerror: libcusolver.so.11: cannot open shared object file: No such file or directory
2024-07-16 13:14:42.552688: I tensorflow/stream_executor/platform/default/dso_loader.cc:53] Successfully opened dynamic library libcusparse.so.11
2024-07-16 13:14:42.552812: I tensorflow/stream_executor/platform/default/dso_loader.cc:53] Successfully opened dynamic library libcudnn.so.8
2024-07-16 13:14:42.552825: W tensorflow/core/common_runtime/gpu/gpu_device.cc:1766] Cannot dlopen some GPU libraries. Please make sure the missing libraries mentioned above are installed properly if you would like to use GPU. Follow the guide at https://www.tensorflow.org/install/gpu for how to download and setup the required libraries for your platform.
Skipping registering GPU devices...
2024-07-16 13:14:42.598302: I tensorflow/core/platform/cpu_feature_guard.cc:142] This TensorFlow binary is optimized with oneAPI Deep Neural Network Library (oneDNN) to use the following CPU instructions in performance-critical operations:  AVX2 AVX512F FMA
To enable them in other operations, rebuild TensorFlow with the appropriate compiler flags.
2024-07-16 13:14:42.599416: I tensorflow/core/common_runtime/gpu/gpu_device.cc:1258] Device interconnect StreamExecutor with strength 1 edge matrix:
2024-07-16 13:14:42.599448: I tensorflow/core/common_runtime/gpu/gpu_device.cc:1264]
2024-07-16 13:14:42.700153: I tensorflow/core/platform/profile_utils/cpu_utils.cc:114] CPU Frequency:<PHONE_NUMBER> Hz
I0716 13:14:43.594188<PHONE_NUMBER>88576 model.py:165] Running predict with shape(feat) = {'aatype': (4, 191), 'residue_index': (4, 191), 'seq_length': (4,), 'template_aatype': (4, 4, 191), 'template_all_atom_masks': (4, 4, 191, 37), 'template_all_atom_positions': (4, 4, 191, 37, 3), 'template_sum_probs': (4, 4, 1), 'is_distillation': (4,), 'seq_mask': (4, 191), 'msa_mask': (4, 508, 191), 'msa_row_mask': (4, 508), 'random_crop_to_size_seed': (4, 2), 'template_mask': (4, 4), 'template_pseudo_beta': (4, 4, 191, 3), 'template_pseudo_beta_mask': (4, 4, 191), 'atom14_atom_exists': (4, 191, 14), 'residx_atom14_to_atom37': (4, 191, 14), 'residx_atom37_to_atom14': (4, 191, 37), 'atom37_atom_exists': (4, 191, 37), 'extra_msa': (4, 5120, 191), 'extra_msa_mask': (4, 5120, 191), 'extra_msa_row_mask': (4, 5120), 'bert_mask': (4, 508, 191), 'true_msa': (4, 508, 191), 'extra_has_deletion': (4, 5120, 191), 'extra_deletion_value': (4, 5120, 191), 'msa_feat': (4, 508, 191, 49), 'target_feat': (4, 191, 22)}
2024-07-16 13:15:16.782891: W external/org_tensorflow/tensorflow/stream_executor/platform/default/dso_loader.cc:64] Could not load dynamic library 'libcusolver.so.11'; dlerror: libcusolver.so.11: cannot open shared object file: No such file or directory
Traceback (most recent call last):
File "/storage/Binh/MHC-pep-binding-predcition/dataset/AF2.1/alphafold-2.1.0/tfold-release/tfold_run_alphafold.py", line 196, in
app.run(main)
File "/home/tbnguyen/miniconda3/envs/tfold-env/lib/python3.8/site-packages/absl/app.py", line 312, in run
_run_main(main, args)
File "/home/tbnguyen/miniconda3/envs/tfold-env/lib/python3.8/site-packages/absl/app.py", line 258, in _run_main
sys.exit(main(argv))
File "/storage/Binh/MHC-pep-binding-predcition/dataset/AF2.1/alphafold-2.1.0/tfold-release/tfold_run_alphafold.py", line 186, in main
predict_structure(sequences=sequences,msas=msas,template_hits=template_hits,renumber_list=renumber_list,
File "/storage/Binh/MHC-pep-binding-predcition/dataset/AF2.1/alphafold-2.1.0/tfold-release/tfold_run_alphafold.py", line 103, in predict_structure
prediction_result=model_runner.predict(processed_feature_dict,random_seed=model_random_seed)
File "/storage/Binh/MHC-pep-binding-predcition/dataset/AF2.1/alphafold-2.1.0/alphafold/model/model.py", line 167, in predict
result = self.apply(self.params, jax.random.PRNGKey(random_seed), feat)
File "/home/tbnguyen/miniconda3/envs/tfold-env/lib/python3.8/site-packages/haiku/_src/transform.py", line 125, in apply_fn
out, state = f.apply(params, {}, *args, **kwargs)
File "/home/tbnguyen/miniconda3/envs/tfold-env/lib/python3.8/site-packages/haiku/_src/transform.py", line 313, in apply_fn
out = f(*args, **kwargs)
File "/storage/Binh/MHC-pep-binding-predcition/dataset/AF2.1/alphafold-2.1.0/alphafold/model/model.py", line 83, in _forward_fn
return model(
File "/home/tbnguyen/miniconda3/envs/tfold-env/lib/python3.8/site-packages/haiku/_src/module.py", line 428, in wrapped
out = f(*args, **kwargs)
File "/home/tbnguyen/miniconda3/envs/tfold-env/lib/python3.8/site-packages/haiku/_src/module.py", line 279, in run_interceptors
return bound_method(*args, **kwargs)
File "/storage/Binh/MHC-pep-binding-predcition/dataset/AF2.1/alphafold-2.1.0/alphafold/model/modules.py", line 376, in call
_, prev = hk.while_loop(
File "/home/tbnguyen/miniconda3/envs/tfold-env/lib/python3.8/site-packages/haiku/_src/stateful.py", line 610, in while_loop
val, state = jax.lax.while_loop(pure_cond_fun, pure_body_fun, init_val)
File "/home/tbnguyen/miniconda3/envs/tfold-env/lib/python3.8/site-packages/haiku/_src/stateful.py", line 605, in pure_body_fun
val = body_fun(val)
File "/storage/Binh/MHC-pep-binding-predcition/dataset/AF2.1/alphafold-2.1.0/alphafold/model/modules.py", line 369, in
get_prev(do_call(x[1], recycle_idx=x[0],
File "/storage/Binh/MHC-pep-binding-predcition/dataset/AF2.1/alphafold-2.1.0/alphafold/model/modules.py", line 337, in do_call
return impl(
File "/home/tbnguyen/miniconda3/envs/tfold-env/lib/python3.8/site-packages/haiku/_src/module.py", line 428, in wrapped
out = f(*args, **kwargs)
File "/home/tbnguyen/miniconda3/envs/tfold-env/lib/python3.8/site-packages/haiku/_src/module.py", line 279, in run_interceptors
return bound_method(*args, **kwargs)
File "/storage/Binh/MHC-pep-binding-predcition/dataset/AF2.1/alphafold-2.1.0/alphafold/model/modules.py", line 161, in call
representations = evoformer_module(batch0, is_training)
File "/home/tbnguyen/miniconda3/envs/tfold-env/lib/python3.8/site-packages/haiku/_src/module.py", line 428, in wrapped
out = f(*args, **kwargs)
File "/home/tbnguyen/miniconda3/envs/tfold-env/lib/python3.8/site-packages/haiku/_src/module.py", line 279, in run_interceptors
return bound_method(*args, **kwargs)
File "/storage/Binh/MHC-pep-binding-predcition/dataset/AF2.1/alphafold-2.1.0/alphafold/model/modules.py", line 1778, in call
template_pair_representation = TemplateEmbedding(c.template, gc)(
File "/home/tbnguyen/miniconda3/envs/tfold-env/lib/python3.8/site-packages/haiku/_src/module.py", line 428, in wrapped
out = f(*args, **kwargs)
File "/home/tbnguyen/miniconda3/envs/tfold-env/lib/python3.8/site-packages/haiku/_src/module.py", line 279, in run_interceptors
return bound_method(*args, **kwargs)
File "/storage/Binh/MHC-pep-binding-predcition/dataset/AF2.1/alphafold-2.1.0/alphafold/model/modules.py", line 2073, in call
template_pair_representation = mapping.sharded_map(map_fn, in_axes=0)(
File "/storage/Binh/MHC-pep-binding-predcition/dataset/AF2.1/alphafold-2.1.0/alphafold/model/mapping.py", line 182, in mapped_fn
outputs, _ = hk.scan(scan_iteration, outputs, slice_starts)
File "/home/tbnguyen/miniconda3/envs/tfold-env/lib/python3.8/site-packages/haiku/_src/stateful.py", line 504, in scan
(carry, state), ys = jax.lax.scan(
File "/home/tbnguyen/miniconda3/envs/tfold-env/lib/python3.8/site-packages/haiku/_src/stateful.py", line 487, in stateful_fun
carry, out = f(carry, x)
File "/storage/Binh/MHC-pep-binding-predcition/dataset/AF2.1/alphafold-2.1.0/alphafold/model/mapping.py", line 171, in scan_iteration
new_outputs = compute_shard(outputs, i, shard_size)
File "/storage/Binh/MHC-pep-binding-predcition/dataset/AF2.1/alphafold-2.1.0/alphafold/model/mapping.py", line 165, in compute_shard
slice_out = apply_fun_to_slice(slice_start, slice_size)
File "/storage/Binh/MHC-pep-binding-predcition/dataset/AF2.1/alphafold-2.1.0/alphafold/model/mapping.py", line 138, in apply_fun_to_slice
return fun(*input_slice)
File "/home/tbnguyen/miniconda3/envs/tfold-env/lib/python3.8/site-packages/haiku/_src/stateful.py", line 567, in mapped_fun
out, state = mapped_pure_fun(args, state)
File "/home/tbnguyen/miniconda3/envs/tfold-env/lib/python3.8/site-packages/haiku/_src/stateful.py", line 558, in pure_fun
out = fun(*args)
File "/storage/Binh/MHC-pep-binding-predcition/dataset/AF2.1/alphafold-2.1.0/alphafold/model/modules.py", line 2071, in map_fn
return template_embedder(query_embedding, batch, mask_2d, is_training)
File "/home/tbnguyen/miniconda3/envs/tfold-env/lib/python3.8/site-packages/haiku/_src/module.py", line 428, in wrapped
out = f(*args, **kwargs)
File "/home/tbnguyen/miniconda3/envs/tfold-env/lib/python3.8/site-packages/haiku/_src/module.py", line 279, in run_interceptors
return bound_method(*args, **kwargs)
File "/storage/Binh/MHC-pep-binding-predcition/dataset/AF2.1/alphafold-2.1.0/alphafold/model/modules.py", line 1977, in call
quaternion=quat_affine.rot_to_quat(rot, unstack_inputs=True),
File "/storage/Binh/MHC-pep-binding-predcition/dataset/AF2.1/alphafold-2.1.0/alphafold/model/quat_affine.py", line 113, in rot_to_quat
_, qs = jnp.linalg.eigh(k)
File "/home/tbnguyen/miniconda3/envs/tfold-env/lib/python3.8/site-packages/jax/_src/numpy/linalg.py", line 313, in eigh
v, w = lax_linalg.eigh(a, lower=lower, symmetrize_input=symmetrize_input)
jax._src.source_info_util.JaxStackTraceBeforeTransformation: RuntimeError: cuSolver internal error
The preceding stack trace is the source of the JAX operation that, once transformed by JAX, triggered the following exception.

The above exception was the direct cause of the following exception:
Traceback (most recent call last):
File "/storage/Binh/MHC-pep-binding-predcition/dataset/AF2.1/alphafold-2.1.0/tfold-release/tfold_run_alphafold.py", line 196, in
app.run(main)
File "/home/tbnguyen/miniconda3/envs/tfold-env/lib/python3.8/site-packages/absl/app.py", line 312, in run
_run_main(main, args)
File "/home/tbnguyen/miniconda3/envs/tfold-env/lib/python3.8/site-packages/absl/app.py", line 258, in _run_main
sys.exit(main(argv))
File "/storage/Binh/MHC-pep-binding-predcition/dataset/AF2.1/alphafold-2.1.0/tfold-release/tfold_run_alphafold.py", line 186, in main
predict_structure(sequences=sequences,msas=msas,template_hits=template_hits,renumber_list=renumber_list,
File "/storage/Binh/MHC-pep-binding-predcition/dataset/AF2.1/alphafold-2.1.0/tfold-release/tfold_run_alphafold.py", line 103, in predict_structure
prediction_result=model_runner.predict(processed_feature_dict,random_seed=model_random_seed)
File "/storage/Binh/MHC-pep-binding-predcition/dataset/AF2.1/alphafold-2.1.0/alphafold/model/model.py", line 167, in predict
result = self.apply(self.params, jax.random.PRNGKey(random_seed), feat)
File "/home/tbnguyen/miniconda3/envs/tfold-env/lib/python3.8/site-packages/jax/_src/traceback_util.py", line 162, in reraise_with_filtered_traceback
return fun(*args, **kwargs)
File "/home/tbnguyen/miniconda3/envs/tfold-env/lib/python3.8/site-packages/jax/_src/api.py", line 416, in cache_miss
out_flat = xla.xla_call(
File "/home/tbnguyen/miniconda3/envs/tfold-env/lib/python3.8/site-packages/jax/core.py", line 1632, in bind
return call_bind(self, fun, *args, **params)
File "/home/tbnguyen/miniconda3/envs/tfold-env/lib/python3.8/site-packages/jax/core.py", line 1623, in call_bind
outs = primitive.process(top_trace, fun, tracers, params)
File "/home/tbnguyen/miniconda3/envs/tfold-env/lib/python3.8/site-packages/jax/core.py", line 1635, in process
return trace.process_call(self, fun, tracers, params)
File "/home/tbnguyen/miniconda3/envs/tfold-env/lib/python3.8/site-packages/jax/core.py", line 627, in process_call
return primitive.impl(f, *tracers, **params)
File "/home/tbnguyen/miniconda3/envs/tfold-env/lib/python3.8/site-packages/jax/interpreters/xla.py", line 581, in _xla_call_impl
compiled_fun = _xla_callable(fun, device, backend, name, donated_invars,
File "/home/tbnguyen/miniconda3/envs/tfold-env/lib/python3.8/site-packages/jax/linear_util.py", line 263, in memoized_fun
ans = call(fun, *args)
File "/home/tbnguyen/miniconda3/envs/tfold-env/lib/python3.8/site-packages/jax/interpreters/xla.py", line 653, in _xla_callable_uncached
return lower_xla_callable(fun, device, backend, name, donated_invars,
File "/home/tbnguyen/miniconda3/envs/tfold-env/lib/python3.8/site-packages/jax/interpreters/xla.py", line 723, in lower_xla_callable
out_nodes = jaxpr_subcomp(ctx, jaxpr, xla_consts, *xla_args)
File "/home/tbnguyen/miniconda3/envs/tfold-env/lib/python3.8/site-packages/jax/interpreters/xla.py", line 471, in jaxpr_subcomp
ans = rule(ctx, map(aval, eqn.invars), map(aval, eqn.outvars),
File "/home/tbnguyen/miniconda3/envs/tfold-env/lib/python3.8/site-packages/jax/_src/lax/control_flow.py", line 360, in _while_loop_translation_rule
new_z = xla.jaxpr_subcomp(
File "/home/tbnguyen/miniconda3/envs/tfold-env/lib/python3.8/site-packages/jax/interpreters/xla.py", line 471, in jaxpr_subcomp
ans = rule(ctx, map(aval, eqn.invars), map(aval, eqn.outvars),
File "/home/tbnguyen/miniconda3/envs/tfold-env/lib/python3.8/site-packages/jax/interpreters/xla.py", line 1217, in f_new
return jaxpr_subcomp(ctx, jaxpr, _xla_consts(ctx.builder, consts),
File "/home/tbnguyen/miniconda3/envs/tfold-env/lib/python3.8/site-packages/jax/interpreters/xla.py", line 471, in jaxpr_subcomp
ans = rule(ctx, map(aval, eqn.invars), map(aval, eqn.outvars),
File "/home/tbnguyen/miniconda3/envs/tfold-env/lib/python3.8/site-packages/jax/_src/lax/control_flow.py", line 360, in _while_loop_translation_rule
new_z = xla.jaxpr_subcomp(
File "/home/tbnguyen/miniconda3/envs/tfold-env/lib/python3.8/site-packages/jax/interpreters/xla.py", line 471, in jaxpr_subcomp
ans = rule(ctx, map(aval, eqn.invars), map(aval, eqn.outvars),
File "/home/tbnguyen/miniconda3/envs/tfold-env/lib/python3.8/site-packages/jax/interpreters/xla.py", line 1064, in _xla_call_translation_rule
out_nodes = jaxpr_subcomp(sub_ctx, call_jaxpr, (), *args)
File "/home/tbnguyen/miniconda3/envs/tfold-env/lib/python3.8/site-packages/jax/interpreters/xla.py", line 471, in jaxpr_subcomp
ans = rule(ctx, map(aval, eqn.invars), map(aval, eqn.outvars),
File "/home/tbnguyen/miniconda3/envs/tfold-env/lib/python3.8/site-packages/jax/interpreters/xla.py", line 1138, in wrapped
ans = f(ctx.builder, *args, **kw)
File "/home/tbnguyen/miniconda3/envs/tfold-env/lib/python3.8/site-packages/jax/_src/lax/linalg.py", line 504, in _eigh_cpu_gpu_translation_rule
v, w, info = syevd_impl(c, operand, lower=lower)
File "/home/tbnguyen/miniconda3/envs/tfold-env/lib/python3.8/site-packages/jaxlib/cusolver.py", line 281, in syevd
lwork, opaque = cusolver_kernels.build_syevj_descriptor(
jax._src.traceback_util.UnfilteredStackTrace: RuntimeError: cuSolver internal error
The stack trace below excludes JAX-internal frames.
The preceding is the original exception that occurred, unmodified.

The above exception was the direct cause of the following exception:
Traceback (most recent call last):
File "/storage/Binh/MHC-pep-binding-predcition/dataset/AF2.1/alphafold-2.1.0/tfold-release/tfold_run_alphafold.py", line 196, in
app.run(main)
File "/home/tbnguyen/miniconda3/envs/tfold-env/lib/python3.8/site-packages/absl/app.py", line 312, in run
_run_main(main, args)
File "/home/tbnguyen/miniconda3/envs/tfold-env/lib/python3.8/site-packages/absl/app.py", line 258, in _run_main
sys.exit(main(argv))
File "/storage/Binh/MHC-pep-binding-predcition/dataset/AF2.1/alphafold-2.1.0/tfold-release/tfold_run_alphafold.py", line 186, in main
predict_structure(sequences=sequences,msas=msas,template_hits=template_hits,renumber_list=renumber_list,
File "/storage/Binh/MHC-pep-binding-predcition/dataset/AF2.1/alphafold-2.1.0/tfold-release/tfold_run_alphafold.py", line 103, in predict_structure
prediction_result=model_runner.predict(processed_feature_dict,random_seed=model_random_seed)
File "/storage/Binh/MHC-pep-binding-predcition/dataset/AF2.1/alphafold-2.1.0/alphafold/model/model.py", line 167, in predict
result = self.apply(self.params, jax.random.PRNGKey(random_seed), feat)
File "/home/tbnguyen/miniconda3/envs/tfold-env/lib/python3.8/site-packages/jaxlib/cusolver.py", line 281, in syevd
lwork, opaque = cusolver_kernels.build_syevj_descriptor(
RuntimeError: cuSolver internal error

This is an AlphaFold problem not related to the TFold wrapper. It could be caused by some combination of GPU, CUDA driver, and conda dependencies (e.g. cudatoolkit). Google suggests that "cuSolver has not been initialized" is caused by OOM (https://github.com/google/jax/issues/5259, https://jax.readthedocs.io/en/latest/gpu_memory_allocation.html) and indeed your GPU gets connected as ~1Gb despite having 16Gb, dunno if that is the problem:
2024-07-16 13:32:36.844382: I tensorflow/core/common_runtime/gpu/gpu_device.cc:1418] Created TensorFlow device (/job:localhost/replica:0/task:0/device:GPU:0 with 1140 MB memory) -> physical GPU (device: 0, name: Quadro P5000, pci bus id: 0000:65:00.0, compute capability: 6.1)
Unfortunately, getting AlphaFold to run can be tricky and I might not be able to help with that.

Thank you very much for your clarification. I will try to get AlphaFold to run.


Spotify playlists don't appear in HA Media Browser

What version of Music Assistant has the issue?
2022.8.4
The problem
Spotify playlists available in the Music Assistant sidebar menu do not show up on HA's Media Browser
on Music Assistant:

on Media Browser:

How to reproduce
Link an Spotify account that has playlists to Music Assistant
Relevant log output
No response
Additional information
No response
What version of Home Assistant Core are your running
2022.8.6
What type of installation are you running?
Home Assistant Supervised
On what type of hardware are you running?
Generic x86-64 (e.g. Intel NUC)

I might be missing something but why do you think they should show up there?

Only favorited playlists will show up in HA's own media browser. It doesn't have any filter or sorting options like MA's frontend has.

Only favorited playlists will show up in HA's own media browser. It doesn't have any filter or sorting options like MA's frontend has.

That was it! Thank you!
Idk if that's documented somewhere, but it should probably be more visible


Fix extension of DataTypes by Declared types

This closes #559 by adding a new function getExplicitRuleTypeName that returns the names of DataTypes and modifying the function getExplicitRuleType to return the correct type for DataTypes which in turn fixes the extension of DataTypes by Declared types and the AST generation.
Having:
interface R1 {
    val: DT
}

R1 returns R1: 'r1' val=DT;
DT returns string: 'dt';

now returns the expected AST:
export type DT = string;

export interface R1 extends AstNode { val: DT }

This is also the same behavior as if (in this case R1) would be inferred

I agree we should rather work to reduce the code in grammar-util.ts rather than add more to it.
@claaspetersen simple solution: move the dataType case to its usage:
export function getTypeName(type: ast.AbstractType | ast.InferredType): string {
    if (ast.isParserRule(type)) {
        if (rule.dataType) {
            return rule.name;
        }
        return getExplicitRuleType(type) ?? type.name;
    } else ...


Help with usb to RS485 - SH-U11

I'm attempting to run mbusd on a openwrt device using a SH-U11 usb to RS485.
I have tested the SH-U11 with a windows machine and it works.
The goal is to get the RS485 data from my Solar Inverter served up by mbusd on the openwrt machine and accessed by a different machine running home assistant.   I have stumbled on others doing a similar setup and it seems to be a good fit in what I want to accomplish.
The log below shows my start up parameters, running mbusb,  and a connection being made by the HA machine (local address <IP_ADDRESS>).  It is unclear to me if mbusd is working. Hopefully the log will tell the story to someone who understands it.    I'm not receiving data on the HA machine.  I have also been unsuccessful trying to connect with windows (running modpoll).   I have also notice that when connected, the SH-U11 does not have blinking data  LEDs for RX/TX.  I believe it did when using windows/modpoll.
Appreciate the suggestions,
log below:
root@OpenWrt:~# mbusd -L/tmp/mbusd.log -s 9600 -T 1000 -P 502 -d -v9
02 Apr 2023 06:31:44 mbusd-0.5.0 started...
02 Apr 2023 06:31:44 tty: trying to open /dev/ttyS0 (speed 9600 mode 8N1)
02 Apr 2023 06:31:44 tty: state now is TTY_PAUSE
02 Apr 2023 06:31:44 conn_loop(): select(): max_sd = 4, t_out = 217673204:000000
02 Apr 2023 06:31:44 conn_loop(): select() returns 0
02 Apr 2023 06:31:44 tty: state now is TTY_READY
02 Apr 2023 06:31:44 conn_loop(): select(): max_sd = 4, t_out = 243484302:000000
02 Apr 2023 06:32:00 conn_loop(): select() returns 1
02 Apr 2023 06:32:00 conn_open(): accepting connection from <IP_ADDRESS>
02 Apr 2023 06:32:00 queue_new_elem(): length now is 1
02 Apr 2023 06:32:00 conn[<IP_ADDRESS>]: state now is CONN_HEADER
02 Apr 2023 06:32:00 conn_loop(): select(): max_sd = 5, t_out = 14618308:000000
02 Apr 2023 06:32:00 conn_loop(): select() returns 1
02 Apr 2023 06:32:00 conn[<IP_ADDRESS>]: state now is CONN_RQST_FUNC
02 Apr 2023 06:32:00 conn_loop(): select(): max_sd = 5, t_out = 15173046:000000
02 Apr 2023 06:32:00 conn_loop(): select() returns 1
02 Apr 2023 06:32:00 conn[<IP_ADDRESS>]: read request fc 3
02 Apr 2023 06:32:00 conn[<IP_ADDRESS>]: state now is CONN_RQST_TAIL
02 Apr 2023 06:32:00 conn[<IP_ADDRESS>]: request: [01][03][00][03][00][05]
02 Apr 2023 06:32:00 conn[<IP_ADDRESS>]: state now is CONN_TTY
02 Apr 2023 06:32:00 tty: state now is TTY_RQST
02 Apr 2023 06:32:00 conn_loop(): select(): max_sd = 4, t_out = 17534273:000000
02 Apr 2023 06:32:00 conn_loop(): select() returns 1
02 Apr 2023 06:32:00 tty: written 8 bytes
02 Apr 2023 06:32:00 tty: request written (total 8 bytes)
02 Apr 2023 06:32:00 tty: state now is TTY_RESP
02 Apr 2023 06:32:00 tty: estimated 15 bytes, waiting 523958 usec
02 Apr 2023 06:32:00 conn_loop(): select(): max_sd = 4, t_out = 19122927:000000
02 Apr 2023 06:32:00 conn_loop(): select() returns 0
02 Apr 2023 06:32:00 tty: response timeout
02 Apr 2023 06:32:00 tty: attempt to retry request (1 of 3)
02 Apr 2023 06:32:00 tty: state now is TTY_RQST
02 Apr 2023 06:32:00 tty: written 8 bytes
02 Apr 2023 06:32:00 tty: request written (total 8 bytes)
02 Apr 2023 06:32:00 tty: state now is TTY_RESP
02 Apr 2023 06:32:00 tty: estimated 15 bytes, waiting 523958 usec
02 Apr 2023 06:32:00 conn_loop(): select(): max_sd = 4, t_out = 152089299:000000
02 Apr 2023 06:32:01 conn_loop(): select() returns 0
02 Apr 2023 06:32:01 tty: response timeout
02 Apr 2023 06:32:01 tty: attempt to retry request (2 of 3)
02 Apr 2023 06:32:01 tty: state now is TTY_RQST
02 Apr 2023 06:32:01 tty: written 8 bytes
02 Apr 2023 06:32:01 tty: request written (total 8 bytes)
02 Apr 2023 06:32:01 tty: state now is TTY_RESP
02 Apr 2023 06:32:01 tty: estimated 15 bytes, waiting 523958 usec
02 Apr 2023 06:32:01 conn_loop(): select(): max_sd = 4, t_out = 35013825:000000
02 Apr 2023 06:32:01 conn_loop(): select() returns 0
02 Apr 2023 06:32:01 tty: response timeout
02 Apr 2023 06:32:01 tty: attempt to retry request (3 of 3)
02 Apr 2023 06:32:01 tty: state now is TTY_RQST
02 Apr 2023 06:32:01 tty: written 8 bytes
02 Apr 2023 06:32:01 tty: request written (total 8 bytes)
02 Apr 2023 06:32:01 tty: state now is TTY_RESP
02 Apr 2023 06:32:01 tty: estimated 15 bytes, waiting 523958 usec
02 Apr 2023 06:32:01 conn_loop(): select(): max_sd = 4, t_out = 168449085:000000
^C02 Apr 2023 06:32:02 conn_loop(): select() returns -1
02 Apr 2023 06:32:02 conn_loop(): error in select() (Invalid argument)
02 Apr 2023 06:32:02 conn_open(): error in accept() (Resource temporarily unavailable)
02 Apr 2023 06:32:02 tty: error in read() (Resource temporarily unavailable)
02 Apr 2023 06:32:02 trying to re-open tty...
02 Apr 2023 06:32:02 tty re-opening...
02 Apr 2023 06:32:02 tty: trying to open /dev/ttyS0 (speed 9600 mode 8N1)
02 Apr 2023 06:32:02 tty: state now is TTY_PAUSE
02 Apr 2023 06:32:02 tty re-opened.
02 Apr 2023 06:32:02 tty: read -1 bytes
02 Apr 2023 06:32:02 tty: read 255 bytes of 15, offset 0
02 Apr 2023 06:32:02 Terminated by signal: SIGINT
root@OpenWrt:~#

I was able to get it going by installing kmod-usb-serial-ftdi.  Now my U11 has a ttyUSB0 address and things are working.


rewrite roomFindAll()

#1249
should complete the roomFindAll()

Good news: there will be not necessary to implement roomFindAll() for a puppet for now.
You need to implement roomList() instead, should return all roomId as a string[].

Done. Please close this issue if all is ok.

all is ok, thanks!