MF-417 - Implement SDK tests

What does this do?
Implement tests for Go SDK
Which issue(s) does this PR fix/relate to?
Resolves #417

Codecov Report

Merging #438 into master will decrease coverage by 14.57%.
The diff coverage is n/a.

@@             Coverage Diff             @@
##           master     #438       +/-   ##
===========================================
- Coverage   91.09%   76.51%   -14.58%
===========================================
  Files          46       52        +6
  Lines        1706     2074      +368
===========================================
+ Hits         1554     1587       +33
- Misses        103      435      +332
- Partials       49       52        +3

Impacted Files
Coverage Δ

sdk/go/sdk.go
95.83% <0%> (ø)

sdk/go/version.go
0% <0%> (ø)

sdk/go/message.go
0% <0%> (ø)

sdk/go/channels.go
8.84% <0%> (ø)

sdk/go/things.go
0% <0%> (ø)

sdk/go/users.go
0% <0%> (ø)

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 d6755e4...544b91b. Read the comment docs.

@blokovi this looks good - just try to raise the coverage if possible.


Error while installing IHaskell on MacOS Monterey 12.0.1

magic               > Configuring magic-1.1...
magic               > Cabal-simple_mPHDZzAJ_<IP_ADDRESS>_ghc-8.10.7: Missing dependency on a foreign
magic               > library:
magic               > * Missing (or bad) C library: magic
magic               > This problem can usually be solved by installing the system package that
magic               > provides this library (you may need the "-dev" version). If the library is
magic               > already installed but in a non-standard location then you can use the flags
magic               > --extra-include-dirs= and --extra-lib-dirs= to specify where it is.If the
magic               > library file does exist, it may contain errors that are caught by the C
magic               > compiler at the preprocessing stage. In this case you can re-run configure
magic               > with the verbosity flag -v3 to see the error messages.
with libmagic already installed using brew.

I was surprised to find this closed without any other info.
Here's the correct command if others come here looking for a fix on an arm64 Apple machine:
stack install --fast --extra-include-dirs=${HOMEBREW_PREFIX}/include --extra-lib-dirs=${HOMEBREW_PREFIX}/lib

The instructions at https://github.com/gibiansky/IHaskell/blob/master/README.md#mac are somewhat imprecise.
Ideally, the installation should be fixed to support these directories by default. Homebrew's decision to use /opt/homebrew for Apple Silicon is both permanent and the default. I would not call it a "custom location".

Ideally, the installation should be fixed to support these directories by default.

As far as I can tell, this is a stack issue and not something we are able to fix on our end. I've gone ahead and updated the instructions in https://github.com/gibiansky/IHaskell/commit/618a315bbd8b2def4928a72ef7024b7e5fbcbc39, but if you have suggestions for a more permanent solution I'm happy to take them on board.


Renderer memory optimizations

The renderer currently can have many copies of certain data in memory at once. This should be fixed to reduce memory usage. It's required for chunk rendering due to the larger amounts of data they have. This caused memory usage issues on the C++ version when chunks were added. It's safe to have one copy of this data shared by many objects since its read-only. 6802158f53fe5a3830119aef235e9d74c4b765c6 fixed this for textures.

[ ] Measure peak RAM usage, final RAM usage, and final VRAM usage before and after the changes.
[ ] Fix duplication of MeshDataBlock. Will likely want to create a NF equivalent class and convert MeshDataBlock to it on import, with one copy per mesh definition.
[ ] Fix duplication of index and vertex buffers for meshes. Might be best to attach them to the NF version of MeshDataBlock.

Before optimizations:
Peak RAM:   507MB
Final RAM:   59.5MB
Final VRAM: 531MB

After optimizations:
Peak RAM: 589MB
Final RAM: 47.2MB
Final VRAM: 363MB
Don't know why the peak ram usage went up. It's possible that it varies run to run. I should've done several runs and taken the average. Not gonna worry about redoing it since I'm satisfied with the changes. They improved memory usage and made the code cleaner by encapulating mesh data that's used by several classes into one ProjectMesh class.
Closed by<PHONE_NUMBER>2264074d0e9c5e51da3d8796b3fa34


Case Insensitivity on MLeap Models

By default, if you train a PySparkML model with a dataframe that has uppercase column names, and then try to run an inference with the same column names but in lowercase, the prediction will fail. Is there a parameter or way to set case insensitivity on inference?
I see this checking for a strict vs relaxed select of the leapframe which I assume is what I'm looking for. How can I set that when serializing a PySpark Model to an MLeap Bundle?
Thanks!
Edit: I see that my second question was wrong - It comes from the transform function, not embedded into the Bundle itself. So when I call model.transform(frame) is there documentation on how to pass in the relaxedSelect option?
Edit: It seems like I'm incorrect on what relaxedSelect does. It seems to just "not throw an error on columns that don't exist" instead of being case insensitive. Is there a case insensitivity option?

hey @Ben-Epstein thanks for the question, there isn't a case insensitivity option available at the moment.
i am not sure if this should be added to mleap itself, or if it's something that can be handled in the service that calls mleap for scoring?

hey @Ben-Epstein thanks for the question, there isn't a case insensitivity option available at the moment.
i am not sure if this should be added to mleap itself, or if it's something that can be handled in the service that calls mleap for scoring?

@ancasarb thanks for the reply. The issue I am getting is that I don't necessarily know if the model was trained (and saved) with a dataframe with uppercase columns, lowercase columns or mixed columns. So at deployment, I run into issues where sometimes the case is wrong so the model fails. Spark actually has the same issue (although sklearn does not). It would be great if mleap supported that flexibility

@ancasarb thanks for the reply. The issue I am getting is that I don't necessarily know if the model was trained (and saved) with a dataframe with uppercase columns, lowercase columns or mixed columns. So at deployment, I run into issues where sometimes the case is wrong so the model fails. Spark actually has the same issue (although sklearn does not). It would be great if mleap supported that flexibility

Maybe you can add an option to "force lower" or "force upper"? During serialization you simply force all columns in the schema lower/upper and then do the same at transform time?

Maybe you can add an option to "force lower" or "force upper"? During serialization you simply force all columns in the schema lower/upper and then do the same at transform time?


Build system for platform dependent initialization, changes to UDP and DHCP

@fwsGonzo please review - lots of changes to your code here.
@ingve please review - Unik platform injection going upstream

Can confirm that autoregistration with the UniK instance listener works.
Used unmodified demo service from current dev. Added PLATFORM=unik to Makefile. Built and run using UniK CLI. IP address is correctly reported by UniK, and instance is available and returns HTML output on said IP address.

retest please

Yeah, I just restarted all the pull request machines which seems to have cleared up some of the issues we were having with the network interface.


Is Azure Stack HCI 23H2 supporting HyperV Replica?

[Enter feedback here]
Hello Microsoft,
Azure Stack HCI 23H2 is not mentioned on the page - is HyperV Replication supported between

Azure Stack HCI 21H2 and Azure Stack HCI 23H2
Azure Stack HCI 22H2 and Azure Stack HCI 23H2
Azure Stack HCI 23H2 and Azure Stack HCI 23H2

I do understand that HyperV Replication in NOT supportet between Windows Server HyperV (Server 2019, Server 2022) and Azure Stack HCI HyperV.
Thanks for a clarification.

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

ID: f6c70745-b594-09c8-5e68-b256c5716f72
Version Independent ID: c6fa4b5a-0208-c236-720e-c106c3c9a515
Content: Set up Hyper-V Replica
Content Source: WindowsServerDocs/virtualization/hyper-v/manage/Set-up-Hyper-V-Replica.md
Service: windows-server
Sub-service: hyper-v
GitHub Login: @BenjaminArmstrong
Microsoft Alias: benarm

We hugely appreciate your contribution, feedback, and support to our technical documentation.
We’ve phased out GitHub Issues on this repository as the feedback mechanism for content and have replaced it with a new feedback system. For more information see, Content User Feedback. As part of this rollout, we are migrating your issue where our team will use your comments to improve the documentation experience. Unfortunately, this does mean you won't be able to access this issue after the migration is complete.
All issues will be migrated by Thursday 29th August 2024.
Once again, thank you for your valuable feedback, we hope you’ll continue to contribute using our new feedback system.


add info about two last members of the group

Checklists
General Checks

[ ] the branch is up to date with main/master
[ ] the code works when pulled and run locally
[ ] All CI checks pass
[ ] all conflicts are resolved (if any)
[ ] PR has a descriptive title
[ ] PR has appropriate labels and milestones for easy identification
[ ] PR it is assigned to the owner
[ ] reviewers are assigned
[ ] the PR contributes only one focused change
[ ] It is in the appropriate column in the project board (if necessary)
[ ] has short and clear description
[ ] is linked to an issue (if it is related)
[ ] feedback is addressed (if any and if it is appropriate feedback.)

Markdown

[ ] the markdown source is formatted
[ ] spelling and grammar is correct in all text
[ ] The markdown looks correct when you preview the file
[ ] all links and images work

It says you're 25 commits behind master. So you'll have to first pull and merge with master and then creat e your own PR


reward fills more than cancels or self trades

Do you know under what circumstances it would be more profitable to take yourself (and pay the 1bp net fee)? I worry this will make all our volume stats a little bit more suspicious to people.

hourly volume in MNGO terms < 10**4 MNGO / hour


[ci] Add Github action to check for unused imports

Fixes #1557

Codecov Report

Merging #1622 (2c49e06) into master (e8f9253) will decrease coverage by 0.00%.
The diff coverage is 100.00%.

@@            Coverage Diff             @@
##           master    #1622      +/-   ##
==========================================
- Coverage   87.66%   87.66%   -0.01%
==========================================
  Files          44       44
  Lines        7283     7281       -2
==========================================
- Hits         6385     6383       -2
  Misses        898      898

Impacted Files
Coverage Δ

reframe/frontend/cli.py
76.63% <ø> (-0.06%)
:arrow_down:

reframe/frontend/loader.py
92.50% <100.00%> (-0.07%)
:arrow_down:

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 e8f9253...2c49e06. Read the comment docs.


Network handling for services with podman failing since 4.50.0

Minimal .gitlab-ci.yml illustrating the issue
job:
  services:
    - name: docker.io/library/busybox
  script:
      - echo "Heya"

Expected behavior
$ gitlab-ci-local --version
4.49.0

$ gitlab-ci-local --container-executable podman
parsing and downloads finished in 36 ms
job starting shell (test)
job started service image: docker.io/library/busybox:latest with aliases: docker.io-library-busybox, docker.io__library__busybox in 230 ms
job Could not find exposed tcp ports docker.io/library/busybox:latest
job $ echo "Heya"
job > Heya
job finished in 386 ms

 PASS  job
pipeline finished in 483 ms

Host information
Fedora 39 (podman out of the box)
gitlab-ci-local 4.49.0 (working)
gitlab-ci-local 4.50.0 and later (not working)
Containerd binary
podman (rootless)
$ podman --version
podman version 4.9.4

Additional context
Probably related to this PR:
https://github.com/firecow/gitlab-ci-local/pull/1226
Searching for this error it seems that this happens when trying to connect a "slirp4netns" network with other networks (bridged).
Error with 4.50.0:
$ gitlab-ci-local-4.50.0 --version
4.50.0

$ gitlab-ci-local-4.50.0 --container-executable podman
parsing and downloads finished in 39 ms
json schema validated in 127 ms
job starting shell (test)
Error: Command failed with exit code 125: podman network connect --alias docker.io-library-busybox --alias docker.io__library__busybox gitlab-ci-local-612717 c1fd44cf33acccf90f7fb65ccdb4522038061c7bc8202c14632a04e5952cace1
Error: "slirp4netns" is not supported: invalid network mode
    at makeError (/snapshot/firecow-gitlab-ci-local/node_modules/execa/lib/error.js:60:11)
    at handlePromise (/snapshot/firecow-gitlab-ci-local/node_modules/execa/index.js:118:26)
    at processTicksAndRejections (node:internal/process/task_queues:95:5)
    at Job.startService (/snapshot/firecow-gitlab-ci-local/src/job.ts:1214:9)
    at /snapshot/firecow-gitlab-ci-local/src/job.ts:492:48
    at async Promise.all (index 0)
    at Job.start (/snapshot/firecow-gitlab-ci-local/src/job.ts:488:13)
    at /snapshot/firecow-gitlab-ci-local/node_modules/p-map/index.js:57:22

Error with 4.52.1:
$ gitlab-ci-local-4.52.1 --version
4.52.1

$ gitlab-ci-local-4.52.1 --container-executable podman
parsing and downloads finished in 36 ms.
json schema validated in 124 ms
job starting shell (test)
Error: Command failed with exit code 125: podman network connect --alias docker.io-library-busybox --alias docker.io__library__busybox gitlab-ci-local-987234 d7494b584648b6abf7af4e883d8f5c5713069ddcbba0b8e2d8b023e44b314501
Error: "slirp4netns" is not supported: invalid network mode
    at makeError (/snapshot/firecow-gitlab-ci-local/node_modules/execa/lib/error.js:60:11)
    at handlePromise (/snapshot/firecow-gitlab-ci-local/node_modules/execa/index.js:118:26)
    at processTicksAndRejections (node:internal/process/task_queues:95:5)
    at Job.startService (/snapshot/firecow-gitlab-ci-local/src/job.ts:1226:9)
    at /snapshot/firecow-gitlab-ci-local/src/job.ts:502:48
    at async Promise.all (index 0)
    at Job.start (/snapshot/firecow-gitlab-ci-local/src/job.ts:498:13)
    at /snapshot/firecow-gitlab-ci-local/node_modules/p-map/index.js:57:22

Also happens when explicitly specifying a network via --network:
$ podman network ls
NETWORK ID    NAME                    DRIVER
fe4352b37add  gitlab-ci-local-175683  bridge
3b01fc9b2ad0  gitlab-ci-local-250057  bridge
6606a433a279  gitlab-ci-local-300890  bridge
2f259bab93aa  podman                  bridge

$ gitlab-ci-local-4.52.1 --container-executable podman --network podman
parsing and downloads finished in 32 ms.
json schema validated in 127 ms
job starting shell (test)
Error: Command failed with exit code 125: podman network connect --alias docker.io-library-busybox --alias docker.io__library__busybox gitlab-ci-local-621822 d3da19d43938d09c10313d83b9f4b5f15eae6ec9396b7c2e093b183b81bb44f1
Error: "slirp4netns" is not supported: invalid network mode
    at makeError (/snapshot/firecow-gitlab-ci-local/node_modules/execa/lib/error.js:60:11)
    at handlePromise (/snapshot/firecow-gitlab-ci-local/node_modules/execa/index.js:118:26)
    at processTicksAndRejections (node:internal/process/task_queues:95:5)
    at Job.startService (/snapshot/firecow-gitlab-ci-local/src/job.ts:1226:9)
    at /snapshot/firecow-gitlab-ci-local/src/job.ts:502:48
    at async Promise.all (index 0)
    at Job.start (/snapshot/firecow-gitlab-ci-local/src/job.ts:498:13)
    at /snapshot/firecow-gitlab-ci-local/node_modules/p-map/index.js:57:22

Having a quick look at the code changes, can it be that the actual service container is not started as part of the gitlab-ci-local-${this.jobId} network?
https://github.com/firecow/gitlab-ci-local/pull/1226/files#diff-a66bffdb979d130e04df61edb944cc04d2fdedf8117ca2732cb6d119d5f5e7b2L1131-R1141

For debugging, essentially the following steps happen
$ podman network create gitlab-ci-local-323838
$ podman create --interactive docker.io/library/busybox:latest
db9f7658884862197303c4249ce008e52264de4a30bf95e0284a491b4a662cb0
$ podman network connect --alias docker.io-library-busybox --alias docker.io__library__busybox gitlab-ci-local-323838 db9f7658884862197303c4249ce008e52264de4a30bf95e0284a491b4a662cb0

I will take a look, but I recall that the last time I looked at this (the changeset you linked above) there might be some differences between docker and podman in how they handle networks.

I did a quick test locally. If I re-add --network gitlab-ci-local-${this.jobId} to the startService -> let dockerCmd instructions and build the binary it works again.

Looking at https://github.com/containers/podman/issues/19577, the issue seems to be that the service container is created with the default network mode (in your case slirp4netns, when reproducing this locally my network mode is pasta). It seems the fix is to start the service container in bridge mode or by directly connecting to the gitlab-ci-local-323838 network.

And that was the behavour before, right?
Was there a specific reason to not create the job container within the "gitlab-ci-local-.." network?

I don't recall exactly, but I think the reason is that you cannot use user defined networks if you also specify host network for example.
I will push a fix in a minute, but let me gather some documentation so that in the future I don't have to remember why I did things the way I did.

Docker
$ docker --version
Docker version 24.0.9, build v24.0.9
$ docker network create gitlab-ci-local-123

Without --network
$ docker create --interactive --name without-network docker.io/library/busybox:latest
$ docker network connect --alias docker.io-library-busybox gitlab-ci-local-123 without-network

With --network=bridge
$ docker create --interactive --name with-network-bridge --network=bridge docker.io/library/busybox:latest
$ docker network connect --alias docker.io-library-busybox gitlab-ci-local-123 with-network-bridge

With --network=bridge, --network=gitlab-ci-local-123
$ docker create --interactive --network=bridge --network=gitlab-ci-local-123 docker.io/library/busybox:latest
docker: conflicting options: cannot attach both user-defined and non-user-defined network-modes.
See 'docker create --help'.

Podman
$ podman --version
podman version 5.0.3
$ podman network create gitlab-ci-local-123

Without --network
$ podman create --interactive --name without-network docker.io/library/busybox:latest
$ podman network connect --alias docker.io-library-busybox gitlab-ci-local-123 without-network
Error: "pasta" is not supported: invalid network mode

With --network=bridge
$ podman create --interactive --name with-network-bridge --network=bridge docker.io/library/busybox:latest
$ podman network connect --alias docker.io-library-busybox gitlab-ci-local-123 with-network-bridge

With --network=bridge, --network=gitlab-ci-local-123
$ podman create --interactive --network=bridge --network=gitlab-ci-local-123 docker.io/library/busybox:latest

@skuethe can you check if https://github.com/firecow/gitlab-ci-local/pull/1301 fixes the problem for you?

can you check if #1301 fixes the problem for you?

It does fix the problem! Thank you for the quick feedback and fix:
$ ~/git/github/firecow/gitlab-ci-local/bin/linux/gitlab-ci-local --container-executable podman
parsing and downloads finished in 37 ms.
json schema validated in 141 ms
job starting shell (test)
job started service image: docker.io/library/busybox:latest with aliases: docker.io-library-busybox, docker.io__library__busybox in 225 ms
job Could not find exposed tcp ports docker.io/library/busybox:latest
job $ echo "Heya"
job > Heya
job finished in 383 ms

 PASS  job
pipeline finished in 631 ms

One workaround that should work for you without any patches for now is to run with --network bridge

This actually does not work. I tried doing that, but it still breaks:
$ gitlab-ci-local-4.52.1 --container-executable podman --network bridge
parsing and downloads finished in 44 ms.
json schema validated in 128 ms
job starting shell (test)
Error: Command failed with exit code 125: podman network connect --alias docker.io-library-busybox --alias docker.io__library__busybox gitlab-ci-local-916989 e52d3c427e0b0cb2e7d3333e8ccfa4c396341a358b521d0792d1d31f31363bb7
Error: "slirp4netns" is not supported: invalid network mode
    at makeError (/snapshot/firecow-gitlab-ci-local/node_modules/execa/lib/error.js:60:11)
    at handlePromise (/snapshot/firecow-gitlab-ci-local/node_modules/execa/index.js:118:26)
    at processTicksAndRejections (node:internal/process/task_queues:95:5)
    at Job.startService (/snapshot/firecow-gitlab-ci-local/src/job.ts:1226:9)
    at /snapshot/firecow-gitlab-ci-local/src/job.ts:502:48
    at async Promise.all (index 0)
    at Job.start (/snapshot/firecow-gitlab-ci-local/src/job.ts:498:13)
    at /snapshot/firecow-gitlab-ci-local/node_modules/p-map/index.js:57:22


Spint

[ ] The justification for this PR is: Update contrib index to include glm and dependencies. This also incorporates a number of merges that happened post the original PR.

I didn't even realize I had the spintW tests in #847 but not in #861! Two updates for the contrib index...there is no dependency on pandas in spint anymore and the glm ships with everything it needs so no dependency on statsmodels or patsy (doesn't current support formulas).

I'm still seeing dependencies in the glm directory:
contrib/glm - [spint] » grep -n 'import statsmodels' *.py
base.py:412:        >>> import statsmodels.api as sm
base.py:528:        >>> import statsmodels.api as sm
base.py:834:        >>> import statsmodels.api as sm
contrib/glm - [spint] » grep -n 'import patsy' *.py
contrib/glm - [spint] » grep -n 'patsy' *.py
base.py:51:            from patsy import dmatrix
base.py:446:        patsy.DesignInfo.linear_constraint
base.py:448:        from patsy import DesignInfo
base.py:565:        patsy.DesignInfo.linear_constraint
base.py:616:        patsy.DesignInfo.linear_constraint
base.py:629:        from patsy import DesignInfo

Ahh, I see it now. It's the inline examples for some of the methods from the LikelihoodModelResults class. I will change with for the methods that I currently test against, such as con_int() but will remove the methods that I am not currently testing =, such as t_test() and wald_test() These will be useful int the future but not imperative to the framework for spint.

I believe I've made all the necessary deletions/edits so there should no longer be unexpected dependencies.


NMS.GEN.LOC.004 - Method for end user to update location data

The NMS system shall provide means to correct details of location data through a web interface via CSV upload or MDS UI.
It should be possible to do changes in spelling or other details of location

This should hopefully just work through MDS UI, should be validated as part of Sprint 3 UAT.

Is the correct way for me to check this issue off:

install motech + NMS
use the MDS UI
confirm I can change a district's name (for example)

?

Didn't we decide that we'd use CSV upload for all updates, rather than MDS
UI?
On Thu, Jun 4, 2015 at 10:15 AM, Frank Huster<EMAIL_ADDRESS>wrote:

Is the correct way for me to check this issue off:

install motech + NMS
use the MDS UI
confirm I can change a district's name (for example)

?
—
Reply to this email directly or view it on GitHub
https://github.com/motech-implementations/mim/issues/100#issuecomment-108979630
.

--
Lauren Lavoie
Software Development Manager, Mobile Health Innovations
Grameen Foundation
2101 4th Ave | Suite 1550 | Seattle, WA 98121
206-325-6690 ext 254
<EMAIL_ADDRESS>| Skype:laurenlavoie
Facebook http://www.facebook.com/StopPovertyNow│Twitter
http://twitter.com/grameenfdn│YouTube
http://www.youtube.com/user/grameen?blend=6&ob=5 | www.motechsuite.org
Connecting the World's Poor to Their Potential

OK, so that issue is an actual dev work item that we can start on after your initial commit, right?

It shouldn't be blocked on my work (I'm working on MCTS beneficiary upload). Kamil's changes for location import were merged a while back.

Doh, I mistakenly thought you were working on initial CSV stuff.
So I could start working on that using Kamil's stuff, right?
On Thu, Jun 4, 2015 at 10:40 AM, Lauren Lavoie<EMAIL_ADDRESS>wrote:

It shouldn't be blocked on my work (I'm working on MCTS beneficiary
upload). Kamil's changes for location import were merged a while back.
—
Reply to this email directly or view it on GitHub
https://github.com/motech-implementations/mim/issues/100#issuecomment-108987421
.

--
Frank Huster
Mobile Health Innovations
Grameen Foundation
+1.206.325.6690 x201

Actually, @larubbio corrected me on this ticket -- he thinks we can use MDS UI for this one (so perhaps no work to do). And all location stuff should be on hold right now because he's working on removing language location code.

We were given a file for this:
https://gist.github.com/llavoie/0263a5e6f290685fc460

Looking over the file it isn't sufficient to implement this issue.

it doesn't contain all elements of the hierarchy (i.e. no taluka)
it is unclear why some lines are repeated
it is unclear what to do when status is invalid and their are FLWs or beneficiaries in that location.
we need clear guidance on what "other details of location" is

This was discussed on the monday night call, but I forget the resolution.  I'll see if John remembers.

John is out, but Pankaj might recall?
On Wed, Jul 8, 2015 at 10:20 AM, Rob LaRubbio<EMAIL_ADDRESS>wrote:

This was discussed on the monday night call, but I forget the resolution.
I'll see if John remembers.
—
Reply to this email directly or view it on GitHub
https://github.com/motech-implementations/mim/issues/100#issuecomment-119669304
.

--
Lauren Lavoie
Software Development Manager, Mobile Health Innovations
Grameen Foundation
2101 4th Ave | Suite 1550 | Seattle, WA 98121
206-325-6690 ext 254
<EMAIL_ADDRESS>| Skype:laurenlavoie
Facebook http://www.facebook.com/StopPovertyNow│Twitter
http://twitter.com/grameenfdn│YouTube
http://www.youtube.com/user/grameen?blend=6&ob=5 | www.motechsuite.org
Connecting the World's Poor to Their Potential

I think the resolution was that the csv file with updates would match the original.  So I think changing the implementation from strictly creating records to creating or updating records will resolve this.
We will not support deletion, or moving a child to a new parent (in that case a new child would be created)

Yes. It will be done through CSV uploads and format will be same as data availability from MCTS.
Regards,
Pankaj Nagpal
+91<PHONE_NUMBER>
From: Rob LaRubbio<EMAIL_ADDRESS>Sent: Thursday, July 9, 2015 5:27
To: motech-implementations/mim
Subject: Re: [mim] NMS.GEN.LOC.004 - Method for end user to update location data (#100)
I think the resolution was that the csv file with updates would match the original. So I think changing the implementation from strictly creating records to creating or updating records will resolve this.
We will not support deletion, or moving a child to a new parent (in that case a new child would be created)
—
Reply to this email directly or view it on GitHub https://github.com/motech-implementations/mim/issues/100#issuecomment-119762328 .  https://github.com/notifications/beacon/ALimuHOkTNE-P1yETpbUN_8jzLgLqKYZks5obbBegaJpZM4EItr6.gif


Add Fishtown Logo

Add Fishtown Logo

can you put this under assets/fishtown ? we already have logos in this repository.

this should be ready! (I couldn't figure out how to add from the command line originally but it should now be in the correct location!)
I need this to add to the handbook


Updating Code Tutorial

Hello,
I am trying to update my current system with your new updates but not sure how to go about this. Any help would be greatly appreciated. (Would be nice to see this in the readme but mostly just because I'm a beginner lol)

I do agree, what would be common commands to run to make sure we are running the latest versions of docker, inventory-hunter, etc....  I am glad to be up and running and thanks to everyone for your help.  Now lets hope they release some gpu's for once.

Awesome Thank you! Keep up the good work!

Big thanks to @thecyberbutler for updating the documentation!


(storybook-vite-source-loader-plugin) was used to transform files, but didn't generate a sourcemap for the transformation.

After updating to  0.1.6, I'm seeing a bunch of these messages when I build storybook:
Sourcemap is likely to be incorrect: a plugin (storybook-vite-source-loader-plugin) was used to transform files, but didn't generate a sourcemap for the transformation. Consult the plugin documentation for help

I believe this is due to https://github.com/eirslett/storybook-builder-vite/pull/147/files#diff-a2d57598d88761951c261c618791586a6bfae721ad14099e08fba7d81d05aa30R20, which does not return a map.

@simenbrekken we might have to construct a source map of some sort here


issue with parcels execution on HPC

I have some parcels code that run fine within a notebook on a jupyter server running on the HPC system at my university (with CentOS 7.6 and bash shell). Yet the same code does not run on a login node or computing node of the same HPC system. A test version of the same code runs fine on my macOS laptop. When executing the parcels kernel, some temporary .so files are not found. I have read issue #487 and I am able to change the location of the temporary files to my scratch space on the HPC (instead of the default /tmp) yet this does not solve the issue. I am copying the relevant error output below. I am wondering if it has to do with some different environment variables between the interactive node running the jupyter server and the computing node? In both cases I am printing out the paths and the (very long) list of environment variables. Is there a specific environment variable I should be looking out for that is used by parcels processes? Something to do with permissions perhaps?
INFO: Compiled ArraySampleParticleInitZeroSample ==> /scratch/tidaldrift/parcels-3477/lib52c065219fa2a3bbd21461bbfd44b8a6_0.so
Traceback (most recent call last):
  File "/home/selipot/pra-drifters/particles_na.py", line 109, in <module>
    pset.execute(sample_kernel, dt=0)
File "/home/selipot/miniconda3/envs/py3_parcels/lib/python3.8/site-packages/parcels-2.3.1.dev129+g65e5d595-py3.8.egg/parcels/particleset/baseparticleset.py", line 341, in execute
    self.kernel.load_lib()
  File "/home/selipot/miniconda3/envs/py3_parcels/lib/python3.8/site-packages/parcels-2.3.1.dev129+g65e5d595-py3.8.egg/parcels/kernel/basekernel.py", line 260, in load_lib
    self._lib = npct.load_library(self.lib_file, '.')
  File "/home/selipot/miniconda3/envs/py3_parcels/lib/python3.8/site-packages/numpy/ctypeslib.py", line 148, in load_library
    return ctypes.cdll[libpath]
  File "/home/selipot/miniconda3/envs/py3_parcels/lib/python3.8/ctypes/__init__.py", line 448, in __getitem__
    return getattr(self, name)
  File "/home/selipot/miniconda3/envs/py3_parcels/lib/python3.8/ctypes/__init__.py", line 443, in __getattr__
    dll = self._dlltype(name)
  File "/home/selipot/miniconda3/envs/py3_parcels/lib/python3.8/ctypes/__init__.py", line 373, in __init__
    self._handle = _dlopen(self._name, mode)

    OSError: /scratch/tidaldrift/parcels-3477/lib52c065219fa2a3bbd21461bbfd44b8a6_0.so: cannot open shared object file: No such file or directory

(ed: add one more backtick)

Hmm, I don't know how to fix this I'm afraid. Perhaps @willirath (or @ckehl?), who have more experience with HPC, have an idea?

Not sure. Sounds like a permission error to me. Guesses:

Is /scratch/tidaldrift/ the right location to point to? As tidaldrift sounds like either a group name or a name of a compute cluster, I'd guess there might be a subdirectory either belonging to your user or related to a job id or something? For further diagnosis, I'd probably run an env | grep -i scratch and env | grep -i tmp and look for how paths under /scratch are handled in the job.

If it's not the above: Does /scratch/tidaldrift/parcels-3477/ exist? (The last dir is generated by Parcels and I'd expect any permission error to show up here first.) If it does not exist, can you create it on the command line? (mkdir -p /scratch/tidaldrift/parcels-3477/)

The path /scratch/tidaldrift/parcels-3477/ should have been created here: https://github.com/OceanParcels/parcels/blob/ecda521bf34645742a0762d781c95bf25641aa51/parcels/tools/global_statics.py#L33 I guess if this didn't throw an error yet, write permissions might not be an issue. But maybe, @selipot, you can try and check if the desired tmp dir location in /scratch/tidaldrift actually is followed by tempfile.gettempdir()? A shell one-liner like python -c "from tempfile import gettempdir; print(gettempdir());" could help revealing if your shell env is leading to the intended behaviour.

Possibly related (@CKehl) I'm a little confused about this line
https://github.com/OceanParcels/parcels/blob/ecda521bf34645742a0762d781c95bf25641aa51/parcels/kernel/basekernel.py#L260
It tries loading the library from the current dir . but then uses a full path which is in self.lib_file.

Not sure. Sounds like a permission error to me. Guesses:

Is /scratch/tidaldrift/ the right location to point to? As tidaldrift sounds like either a group name or a name of a compute cluster, I'd guess there might be a subdirectory either belonging to your user or related to a job id or something? For further diagnosis, I'd probably run an env | grep -i scratch and env | grep -i tmp and look for how paths under /scratch are handled in the job.

/scratch/tidaldrift/ is my personal scratch space for my tidaldrift project. I had specified to use this folder by setting the tempdir folder in an attempt to understand if this was indeed a permission issue. The same issue exist when I use the default /tmp folder for temporary files.

If it's not the above: Does /scratch/tidaldrift/parcels-3477/ exist? (The last dir is generated by Parcels and I'd expect any permission error to show up here first.) If it does not exist, can you create it on the command line? (mkdir -p /scratch/tidaldrift/parcels-3477/)

Yes, /scratch/tidaldrift/parcels-3477/ does exist but after the attempted execution I can see that this folder is empty. The .so files are not present there.

The path /scratch/tidaldrift/parcels-3477/ should have been created here: https://github.com/OceanParcels/parcels/blob/ecda521bf34645742a0762d781c95bf25641aa51/parcels/tools/global_statics.py#L33
I guess if this didn't throw an error yet, write permissions might not be an issue. But maybe, @selipot, you can try and check if the desired tmp dir location in /scratch/tidaldrift actually is followed by tempfile.gettempdir()? A shell one-liner like python -c "from tempfile import gettempdir; print(gettempdir());" could help revealing if your shell env is leading to the intended behaviour.

I don't think it's an issue with the creation of that folder. What process writes the .so files?

In summary, if I let parcels does its thing and do not change the temporary folder location I get the same issue. The /tmp/parcels-3477/ folder is created but not populated and creates the error that the .so file is not found. I am wondering if I might need to load a compiler module that is needed by parcels?

I don't think it's an issue with the creation of that folder. What process writes the .so files?

This should be
https://github.com/OceanParcels/parcels/blob/ecda521bf34645742a0762d781c95bf25641aa51/parcels/kernel/basekernel.py#L237
which is called from here
https://github.com/OceanParcels/parcels/blob/ecda521bf34645742a0762d781c95bf25641aa51/parcels/particleset/baseparticleset.py#L340
The behaviour of the compiler should be in here: https://github.com/OceanParcels/parcels/blob/ecda521bf34645742a0762d781c95bf25641aa51/parcels/particleset/baseparticleset.py#L340

I am wondering if I might need to load a compiler module that is needed by parcels?

In principle, the dependencies of the Conda package should be self sufficient. The logic of overriding compiler configs with environment vars in Linux is, however, very confusing.
If I'm not mistaken, we've narrowed down the problem to the .so files not being created or (less likely IMO) not being created in the desired place. This could be due to a non-functional compiler config, which in turn might come from an improper activation of the conda environment. Conda's activation process is sometimes buggy on non-interactive shells.
If the env works in an interactive session but not in a non-interactive shell, you can try and explicitly activate with:
. /home/selipot/miniconda3/bin/activate base
conda activate py3_parcels

Ah. Means we’re almost there. Here’s what we do on our university cluster for running jupyterlab on compute nodes:
https://git.geomar.de/python/jupyter_on_HPC_setup_guide/-/blob/master/job-scripts/jupyterlab-slurm.sh#L88
The comment below the linked line could work:
source "${HOME}"/miniconda3/etc/profile.d/conda.sh

Dr. Willi Rath
Ozeandynamik
GEOMAR
Helmholtz-Zentrum für Ozeanforschung Kiel
Duesternbrooker Weg 20, Raum 425
24105 Kiel, Germany
Tel. +49-431-600-4010
@.***
www.geomar.de
Pers. Meeting Room: https://geomar-de.zoom.us/j/2378402733?pwd=NFBaNnRIMVdoS3F1WDVBV01ZcmU2QT09

Am 18.10.2022 um 18:00 schrieb Shane Elipot @.***>:

Trying that but the activation of the conda environment on the computing node fails because it requires the shell "properly configured to use conda activate" ... but a conda init bash initialization also fails. I am communicating with the help desk of my HPC to get some help/feedback. I will keep you updated here. Thanks!
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you were mentioned.

I have tried again to do things properly: 1) from the native anaconda software of my HPC, I have re-created a parcels environment from the environment file for linux, and 2) I am properly activating this environment with the job file sent to the scheduler (as advised by the helpdesk) before executing my code.
Despite this, I am getting the same error (.so file missing). I am noting that I do need to change the temporary directory from the default /tmp to my scratch space, otherwise the temporary folder (parcels-3477 above) does not even get written, despite what I said earlier (it must have been a remnant from running the code in jupyter hub).
Not sure where to go from here? I am wondering if the package dependencies in the linux environment file for parcels are adequate for my HPC (like gcc_linux-64?). I'll try to investigate.

I think I have succeeded! My steps were:

git clone the parcels repo
load the native anaconda software module for my HPC
using conda, proceed to conduct the developer installation of parcels using the linux environment file but without the gcc_linux-64 package (conda install parcels fails because it does not seem to be available for the HPC architecture.)
load the native gcc compiler module for my HPC
run the python setup.py install for parcels
make sure to include in my job script the loading of the HPC anaconda and gcc module

And that worked! But since I had to git clone the latest repo I had to modify my code for the zarr output instead of netcdf ... But I can't read the zarr output with xarray! Arg, what do I need to change???

For zarr, try the following https://nbviewer.org/github/OceanParcels/parcels/blob/master/parcels/examples/documentation_MPI.ipynb

ok crisis averted I needed to install zarr in my environments for analysis. So in the end a shorter test worked! Thank you so much @willirath and @erikvansebille for helping me through this issue! So how does one read the output before the full completion of the execution? We used to be able to generate the netcdf file from the output before the complete execution.


feat(cli): add option to include pipeline

test: multiline shell cmd in readme
feat(cli): add option to include pipeline
chore: fmt

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

54 of 54 (100.0%)  changed or added relevant lines in 3 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage increased (+1.8%) to 93.651%

Totals

Change from base Build<PHONE_NUMBER>:
1.8%

Covered Lines:
220

Relevant Lines:
234

💛  - Coveralls


module: Add sched module

This module is a collection of scheduler data getters.
There's quite a few places in LISA where we re-implement these (mostly capacity getters), so I figured this would be the best place to bunch it up.
I'm a bit conflicted about the handling of the EAS energy model - we have a ~1000 line file that handles everything energy model related, and some of it could be moved here. However I don't think it's a simple task, so for now the handling of energy model data done in this module is trivial.
Also, I should make sure this runs fine on Python3 to get it in line with the other modules, but I figured I could collect some comments first :)

I think I addressed every comment, the major ones being:

Added a test in probe to see if the sched domain procfs entries are there
Changed the setattr bizz to a dyn_attrs dict + __getattr__()
Added a strict flag for KernelConfig.get() (False by default)

Oh and before I forget - I still need to properly test this out with Python3

I got it to run with either Python2 or Python3. I'll start tweaking a scheduler test in LISA using this module to validate the interface is sane or if it's missing something before releasing it into the wild.

So, turns out if you have a test that wants to go through all of the cpus' sched domain data, it takes quite some time (one read_tree_value per CPU). So I changed things to make it possible to do it all in one read_tree_value call, which led me to restructure the whole  SchedProcFSNode thing.
A simple changeset would be:

Changed the current get_sd_info into get_cpu_sd_info
Added a new get_sd_info method (for all CPUs)
Added a target kernel version check at probe time to warn if it's too old compared to the version used to create the module

Is this now good to be merged, or are you still testing, @valschneider ?

@setrofim If you're happy with it I think it's good to go. The "only" contentious point so far is this module has some knowledge of the energy model, which could live in a module/class of its own. Thing is, it's a bit more work to get that in a good shape, so I think for now I'll stick with the current implementation and just make it query the EM class/module when I'll have more bandwidth.


NoSuchMethod DataFrameReader.parquet

This error occured while Iwas trying to comapact all snappy.parquet files which were generated in Spark2.1 with DataFrames.
Is there any work around? Maybe to try with RDDs but how eficient it is
Can we expect improvement in near future? :)
17/08/16 10:56:33 ERROR ApplicationMaster: User class threw exception: java.lang.NoSuchMethodError: org.apache.spark.sql.DataFrameReader.parquet([Ljava/lang/String;)Lorg/apache/spark/sql/DataFrame;
java.lang.NoSuchMethodError: org.apache.spark.sql.DataFrameReader.parquet([Ljava/lang/String;)Lorg/apache/spark/sql/DataFrame;
	at com.github.KeithSSmith.spark_compaction.Compact.compact(Compact.java:210)
	at com.github.KeithSSmith.spark_compaction.Compact.main(Compact.java:227)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:497)
	at org.apache.spark.deploy.yarn.ApplicationMaster$$anon$2.run(ApplicationMaster.scala:637)

Sent from my Lge LG-H850 using FastHub

@iMajna
This library is not updated for Spark2. It was built with 1.5.2
https://github.com/KeithSSmith/spark-compaction/blob/master/pom.xml#L148
DataFrameReader.parquet(String string) was added in Spark 2.

Yes, I got that thats why I asked can we expect any improvement :)
Do you know any replacement or how to deal with lofs of parquets?

I was looking at this to handle Avro.
The solution would be to fork it and rewrite all the RDD usage into the Dataset API


setting grad None after training to avoid memory leak

Hi,
during training I've observed a memory leak, when training several models after another. I've used your example code from the Readme to create an example, see below. I'm using Python 3.7 and PyTorch 1.13.1. Per training run I observe an increase of about 10MiB concerning memory usage. This is especially an issue when training larger models, resulting in an out of memory error.
The memory leak is discussed in https://github.com/pytorch/pytorch/issues/82528. In your code there is already a begin method in the Optimizable class which sets the param.grad to None. However, it seems there is also a need to set param.grad=None at the end of training a model to avoid memory leakage over several training runs. Hence, I suggest to add an end method which is called at the end of each training run.
import math
import torch
import torch.nn as nn
import torch.nn.functional as F

class MNIST_FullyConnected(nn.Module):
    """
    A fully-connected NN for the MNIST task. This is Optimizable but not itself
    an optimizer.
    """
    def __init__(self, num_inp, num_hid, num_out):
        super(MNIST_FullyConnected, self).__init__()
        self.layer1 = nn.Linear(num_inp, num_hid)
        self.layer2 = nn.Linear(num_hid, num_out)

    def initialize(self):
        nn.init.kaiming_uniform_(self.layer1.weight, a=math.sqrt(5))
        nn.init.kaiming_uniform_(self.layer2.weight, a=math.sqrt(5))

    def forward(self, x):
        """Compute a prediction."""
        x = self.layer1(x)
        x = torch.tanh(x)
        x = self.layer2(x)
        x = torch.tanh(x)
        x = F.log_softmax(x, dim=1)
        return x

def train_model(model_wrapper, train_data):
    for i in range(1, EPOCHS + 1):
        running_loss = 0.0
        for j, (features_, labels_) in enumerate(train_data):
            model_wrapper.begin()  # call this before each step, enables gradient tracking on desired params
            features, labels = torch.reshape(features_, (-1, 28 * 28)).to(
                DEVICE
            ), labels_.to(DEVICE)
            pred = model_wrapper.forward(features)
            loss = F.nll_loss(pred, labels)
            model_wrapper.zero_grad()
            loss.backward(create_graph=True)  # important! use create_graph=True
            # loss.backward(create_graph=False) # important! use create_graph=True
            model_wrapper.step()
            running_loss += loss.item() * features_.size(0)
        train_loss = running_loss / len(train_data.dataset)
        print("EPOCH: {}, TRAIN LOSS: {}".format(i, train_loss))

if __name__ == "__main__":
    import torchvision
    from gradient_descent_the_ultimate_optimizer import gdtuo

    BATCH_SIZE = 256
    EPOCHS = 2
    N_RUNS = 50
    DEVICE = "cuda" if torch.cuda.is_available() else "cpu"
    for i_run in range(N_RUNS):
        print(f"Run: {i_run}")
        mnist_train = torchvision.datasets.MNIST(
            "./data",
            train=True,
            download=True,
            transform=torchvision.transforms.ToTensor(),
        )
        dl_train = torch.utils.data.DataLoader(
            mnist_train, batch_size=BATCH_SIZE, shuffle=True
        )
        model = MNIST_FullyConnected(28 * 28, 128, 10).to(DEVICE)
        optim = gdtuo.Adam(optimizer=gdtuo.SGD(1e-5))

        mw = gdtuo.ModuleWrapper(model, optimizer=optim)
        mw.initialize()
        train_model(mw, dl_train)

Hi there— thank you for writing! I'm not sure I fully understand where this leak comes from, but it looks from your proposed code change that you could equivalently just call mw.begin() at the end of each training loop. Could you try that and see if it works?
(We would like to keep this repo as a frozen archive of the code from the paper, and will not be updating it unless there are severe issues without plausible workarounds.)
Thanks!

While calling mw.begin() after a training run also solves the issue since param.grad = None is set, it seems not intuitive to call a method named "begin" after a training run. Moreover, the method contains further functionalities which are not required to resolve the initial problem of resetting the gradients so gc can do its magic.
Nevertheless, I understand that you would like to avoid making changes to the code. However, I would still encourage you to update the README with a hint concerning calling the begin method at the end of a training run, when training several models.  This would help future users greatly to successfully and quickly apply your code, without wondering where the out of memory error comes from.

Hi everyone,
Thank you Kartik Chandra for creating this great repository.
I have been using this code for a simple FNN and it works great, and there seems to be no memory leak. However, when switching to a simple RNN, memory increases drastically after each training batch, and at some point I am getting an out-of-memory error.
As described above, this issue is caused by setting loss.backward(create_graph=True). I have tried both described solutions for this: 1) set param.grad=None at the end of training by calling the end() method created by kaloeffler. 2) calling mw.begin() at the end of each training loop.
Both solutions did not work in my case. Also, it seems that the high increase in memory is cause by retaining the graph, as retain_graph is automatically set to True when creating the graph.
As I only have this issue when training an RNN model, and since an RNN model has been trained using the ultimate optimizer in your paper, I was wondering if you had a similar issue and another fix for it?
Thank you!


feat(locale): add Spanish locale

This builds on #1105, and basically rebases 72ddf83d210fba6b11e6bd2cb7ece32dd1ee6345 on the latest main (af9d6083467fed80fe5a7e361691743cda770b7d at the time of writing).
In addition to the initial work by @ohmmolina, I fixed a type mismatch in __tests__/es-{Es,MX}.test.ts, adapted to the plural/singular form added in 5c34a6a423a933a88cec948c6bfa3d0f24210e9a, as well as an attempt to address the distinction between the numeral 'uno' immediately prior to a masculine noun (shortened to 'un') and ones trailing (regular 'uno').
Obviously this is a bit awkward with the recursion, but I believe I solved it by passing trailing: true in certain cases. If trailing is true and the exactWordsMapping is of the tuple type [string, string], the latter entry of the mapping is used instead of the former.
If there is a better solution that didn't occur to me please let me know and I'd be down to try and fix it in such a manner instead as this only further complicates the algorithm, but I did have a look at French (as that's the only other romance language) but didn't have much luck since one is literally just 'un' everywhere.

Thank you for your contribution @s1gtrap!


Invoke database.commit only if needed

Impact

[X] Bug fix (non-breaking change which fixes expected existing functionality)
[ ] Enhancement/New feature (adds functionality without impacting existing logic)
[ ] Breaking change (fix or feature that would cause existing functionality to change)

Description
Invoke database.commit only if something was executed
When running over large changesets , every commit means a request and for cloud databases it means a new request to the cloud that can take up some time.

@filipelautert Can we write some tests to test this scenario?


Apply ux placeholder guidelines (Team Atlas)

What does this PR do?
This PR applies the UX guidelines for placeholders as discussed in https://github.com/giantswarm/roadmap/issues/991 to the documents owned by team atlas.
Any background context you can provide?
closes https://github.com/giantswarm/roadmap/issues/1032
What is needed from the reviewers?
Please confirm that these changes do not break the correctness of the explanations.

Thank you @hervenicol
I fixed it :)


GPR curation for Transport reactions (3)

Current behavior:

40 genes are discovered to be uncorrelated with their corresponding reactions in Transport reactions.

Gene
UniProtID
Reaction
GPR
Correlation
Manually check

ENSG00000003989
P52569
MAR05091: threonine --> threonine
(ENSG00000092068 and ENSG00000168003) or ENSG00000003989 or ENSG00000103257 or ENSG00000123643 or ENSG00000130876 or ENSG00000139514 or ENSG00000149150 or ENSG00000155465 or ENSG00000165349 or ENSG00000167703
Pending No, the gene is not relevant to the reaction provided. Analysis and explanation: The gene ENSG00000003989 encodes for a permease involved in the transport of specific cationic amino acids such as L-arginine, L-lysine, L-ornithine, and L-homoarginine across cell membranes. Its function is annotated with catalytic activities facilitating the transport of these specific amino acids in and out of the cell. However, the provided reaction involves threonine, which is not mentioned as a substrate for the permease encoded by ENSG00000003989. Therefore, this gene is not relevant to the threonine-related reaction.
No

ENSG00000165349
Q8WY07
MAR05092: isoleucine <=> isoleucine
(ENSG00000092068 and ENSG00000168003) or ENSG00000003989 or ENSG00000103257 or ENSG00000123643 or ENSG00000139514 or ENSG00000149150 or ENSG00000155465 or ENSG00000165349 or ENSG00000167703
Pending No, the gene is not relevant to the reaction provided. Analysis and explanation: The gene ENSG00000165349 functions as a uniporter that specifically mediates the uptake of cationic L-amino acids like L-arginine, L-lysine, and L-ornithine. The catalytic activities listed for this gene involve the transport of these specific amino acids across the membrane. The reaction given, which is the interconversion of isoleucine, is not mediated by the gene according to its annotated function and catalytic activities. Therefore, the gene ENSG00000165349 does not have a relevant role in the isoleucine reaction.
No

ENSG00000139514
P30825
MAR05092: isoleucine <=> isoleucine
(ENSG00000092068 and ENSG00000168003) or ENSG00000003989 or ENSG00000103257 or ENSG00000123643 or ENSG00000139514 or ENSG00000149150 or ENSG00000155465 or ENSG00000165349 or ENSG00000167703
Pending No, the gene is not relevant to the reaction provided. Analysis and explanation: The gene ENSG00000139514 is involved in the high-affinity, low-capacity transport of cationic amino acids such as arginine, lysine, and ornithine in non-hepatic tissues, as well as homoarginine. However, the reaction provided involves isoleucine, which is not a cationic amino acid and is not mentioned within the transport activity of the given gene. Hence, there is no relation between the gene and the isoleucine-related reaction.
No

ENSG00000003989
P52569
MAR05092: isoleucine <=> isoleucine
(ENSG00000092068 and ENSG00000168003) or ENSG00000003989 or ENSG00000103257 or ENSG00000123643 or ENSG00000139514 or ENSG00000149150 or ENSG00000155465 or ENSG00000165349 or ENSG00000167703
Pending No, the gene is not relevant to the reaction provided. Analysis and explanation: The gene ENSG00000003989 encodes a permease involved in the transport of specific cationic amino acids such as L-arginine, L-lysine, L-ornithine, and L-homoarginine, as shown by its various isoforms. The described reactions facilitated by this gene include the transport of these amino acids across membranes. However, the provided reaction involves isoleucine, which is not a substrate mentioned within the gene's functional annotation. Therefore, the gene is not relevant to the isoleucine-related reaction.
No

ENSG00000139514
P30825
MAR05305: alanine + Na+ --> alanine + Na+
ENSG00000003989 or ENSG00000072041 or ENSG00000105281 or ENSG00000111371 or ENSG00000115902 or ENSG00000134294 or ENSG00000139209 or ENSG00000139514 or ENSG00000165349 or ENSG00000174358
Pending No, the gene is not relevant to the reaction provided. Analysis and explanation: The gene ENSG00000139514 encodes a high-affinity, low-capacity permease involved in the transport of cationic amino acids like arginine, lysine, and ornithine in non-hepatic tissues, as evidenced by various studies. The described catalytic activities are specific to the transport of L-arginine, L-lysine, L-ornithine, and L-homoarginine. However, the provided reaction involves the transport of alanine along with sodium (Na+), which is not mentioned as a substrate or product in the annotated functions of the gene. Therefore, the gene is not relevant to the alanine and sodium transport reaction.
No

ENSG00000003989
P52569
MAR05305: alanine + Na+ --> alanine + Na+
ENSG00000003989 or ENSG00000072041 or ENSG00000105281 or ENSG00000111371 or ENSG00000115902 or ENSG00000134294 or ENSG00000139209 or ENSG00000139514 or ENSG00000165349 or ENSG00000174358
Pending No, the gene is not relevant to the reaction provided. Analysis and explanation: The gene ENSG00000003989 functions as a permease involved in the transport of specific cationic amino acids, such as L-arginine, L-lysine, L-ornithine, and L-homoarginine. The catalytic activities described for this gene involve the transport of these amino acids across membranes. However, the reaction provided, "alanine + Na+ --> alanine + Na+," involves the amino acid alanine and sodium ions, which are not substrates or interactions indicated in the gene's function or catalytic activities according to the provided annotations. Thus, there is no relevant connection between the gene's described functions and the specified reaction.
No

ENSG00000165349
Q8WY07
MAR05315: leucine + Na+ --> leucine + Na+
ENSG00000003989 or ENSG00000072041 or ENSG00000111371 or ENSG00000134294 or ENSG00000139209 or ENSG00000139514 or ENSG00000165349 or ENSG00000168003 or ENSG00000174358
Pending No, the gene is not relevant to the reaction provided. Analysis and explanation: The gene ENSG00000165349 is involved in the transport of cationic L-amino acids such as L-arginine, L-lysine, and L-ornithine based on passive diffusion and is sodium- and pH-independent. The provided reaction involves leucine and sodium (Na+), which does not align with the specific cationic L-amino acids mediated by the gene ENSG00000165349.
No

ENSG00000139514
P30825
MAR05315: leucine + Na+ --> leucine + Na+
ENSG00000003989 or ENSG00000072041 or ENSG00000111371 or ENSG00000134294 or ENSG00000139209 or ENSG00000139514 or ENSG00000165349 or ENSG00000168003 or ENSG00000174358
Pending No, the gene is not relevant to the reaction provided. Analysis and explanation. The gene ENSG00000139514 is involved in the high-affinity, low capacity transport of the cationic amino acids arginine, lysine, ornithine, and homoarginine as indicated by its annotated functions and catalytic activities. However, the given reaction involves leucine transport in association with sodium (Na+), which is not one of the amino acids specified in the gene's documented activities. Therefore, the gene and the provided reaction are not related.
No

ENSG00000003989
P52569
MAR05315: leucine + Na+ --> leucine + Na+
ENSG00000003989 or ENSG00000072041 or ENSG00000111371 or ENSG00000134294 or ENSG00000139209 or ENSG00000139514 or ENSG00000165349 or ENSG00000168003 or ENSG00000174358
Pending No, the gene is not relevant to the reaction provided. Analysis and explanation: The gene ENSG00000003989 is annotated to function as a permease involved in the transport of cationic amino acids, specifically L-arginine, L-lysine, L-ornithine, and L-homoarginine, and exhibits catalytic activities for their transport. However, the reaction described (leucine + Na+ --> leucine + Na+) involves the transport of leucine and sodium, which are not substrates of the permease encoded by this gene. Therefore, the gene is not related to the reaction provided.
No

ENSG00000165349
Q8WY07
MAR05319: Na+ + phenylalanine --> Na+ + phenylalanine
ENSG00000003989 or ENSG00000111371 or ENSG00000134294 or ENSG00000139209 or ENSG00000139514 or ENSG00000165349 or ENSG00000174358
Pending No, the gene is not relevant to the reaction provided. Analysis and explanation: The gene ENSG00000165349 encodes a uniporter that mediates the uptake of cationic L-amino acids such as L-arginine, L-lysine, and L-ornithine via passive diffusion, which is sodium ions- and pH-independent. The reaction provided involves the transport of phenylalanine in the presence of sodium ions, which is not the function of the gene mentioned. Therefore, the gene is not relevant to the given reaction.
No

ENSG00000139514
P30825
MAR05319: Na+ + phenylalanine --> Na+ + phenylalanine
ENSG00000003989 or ENSG00000111371 or ENSG00000134294 or ENSG00000139209 or ENSG00000139514 or ENSG00000165349 or ENSG00000174358
Pending No, the gene is not relevant to the reaction provided. Analysis and explanation. The gene ENSG00000139514 is involved in the high-affinity, low-capacity transport of cationic amino acids such as arginine, lysine, and ornithine across cellular membranes. The reactions it catalyzes include the transport of L-arginine, L-lysine, L-ornithine, and L-homoarginine, but not phenylalanine. The reaction provided involves the transport of phenylalanine, which is not one of the substrates associated with the gene's annotated function. Hence, the gene and the reaction are not related.
No

ENSG00000003989
P52569
MAR05319: Na+ + phenylalanine --> Na+ + phenylalanine
ENSG00000003989 or ENSG00000111371 or ENSG00000134294 or ENSG00000139209 or ENSG00000139514 or ENSG00000165349 or ENSG00000174358
Pending No, the gene is not relevant to the reaction provided. Analysis and explanation: The gene ENCODES a permease involved in the transport of cationic amino acids such as L-arginine, L-lysine, L-ornithine, and L-homoarginine. It does not transport phenylalanine, making it unrelated to the reaction Na+ + phenylalanine --> Na+ + phenylalanine.
No

ENSG00000174358
Q695T7
MAR05330: glutamate + Na+ --> glutamate + Na+
ENSG00000079215 or ENSG00000105143 or ENSG00000106688 or ENSG00000110436 or ENSG00000162383 or ENSG00000174358 or ENSG00000178537
Pending No, the gene is not relevant to the reaction provided. Analysis and explanation: The gene ENSG00000174358 functions as a sodium-dependent transporter responsible for the resorption of neutral amino acids across renal and intestinal epithelial cells. It mediates the transport of several specific amino acids, including L-alanine, L-cysteine, L-glutamine, glycine, L-isoleucine, L-leucine, L-methionine, L-phenylalanine, L-serine, L-tryptophan, L-tyrosine, and L-valine, but does not have any documented catalytic activity for transporting glutamate. The provided reaction involves the transport of glutamate with sodium, for which there is no evidence of involvement of ENSG00000174358 based on the gene's annotation.
No

ENSG00000178537
O43772
MAR05330: glutamate + Na+ --> glutamate + Na+
ENSG00000079215 or ENSG00000105143 or ENSG00000106688 or ENSG00000110436 or ENSG00000162383 or ENSG00000174358 or ENSG00000178537
Pending No, the gene is not relevant to the reaction provided. Analysis and explanation: The gene ENSG00000178537 is involved in the transport of acylcarnitines and carnitine across the mitochondrial inner membrane, aiding in mitochondrial fatty acid beta-oxidation. It catalyzes the exchange of various forms of carnitine, including O-acyl-(R)-carnitine and O-acetyl-(R)-carnitine, but does not play a role in the transport of glutamate associated with Na+ ions. The provided reaction involving glutamate and Na+ is not related to the function of this gene.
No

ENSG00000149150
O75387
MAR05441: homoserine <=> homoserine
ENSG00000149150
Pending No, the gene is not relevant to the reaction provided. Analysis and explanation: The gene ENSG00000149150 mediates the transport of neutral amino acids such as L-leucine, L-isoleucine, L-valine, L-phenylalanine, and L-methionine through facilitated diffusion and is involved in sodium ions-independent electroneutral transport. However, the reaction provided (homoserine <=> homoserine) involving homoserine does not relate to these activities. The gene's function and its catalyzed reactions do not include or mention homoserine, indicating no relevance to the reaction provided.
Yes, homoserine belongs to neutral amino acids which can be transported by this enzyme.

ENSG00000148942
Q1EHB4
MAR05450: glucose + Na+ --> glucose + Na+
ENSG00000117834 or ENSG00000140675 or ENSG00000148942 or ENSG00000154025 or ENSG00000158865
Pending No, the gene is not relevant to the reaction provided. Analysis and explanation. The gene ENSG00000148942 functions as a sodium-dependent solute transporter and catalyzes the transport of monocarboxylates such as lactate, pyruvate, nicotinate, propionate, butyrate, and beta-D-hydroxybutyrate across the plasma membrane. The provided reaction, "glucose + Na+ --> glucose + Na+," involves glucose transport, which is not within the substrates mentioned in the gene's annotated functions and catalytic activities. Therefore, the gene and the reaction are not related.
No

ENSG00000165029
O95477
MAR05528: asparagine + tryptophan <=> asparagine + tryptophan
ENSG00000103257 or ENSG00000165029
Pending No, the gene is not relevant to the reaction provided. Analysis and explanation: The gene ENSG00000165029 encodes a protein that primarily functions as an ATP-dependent translocator of specific phospholipids and cholesterol across membrane leaflets, which is not related to the reaction involving asparagine and tryptophan. The catalytic activities described for the gene involve different substrates and processes (such as phosphatidylcholine, phosphatidylserine, sphingomyelin, and cholesterol), none of which are related to the transformation of asparagine and tryptophan. Therefore, the gene's function does not correspond to the reaction provided.
No

ENSG00000165029
O95477
MAR05529: tryptophan + valine <=> tryptophan + valine
ENSG00000103257 or ENSG00000165029
Pending No, the gene is not relevant to the reaction provided. Analysis and explanation: The gene ENSG00000165029 encodes a protein that catalyzes the translocation of specific phospholipids and cholesterol across membranes using ATP hydrolysis. The provided reaction, tryptophan + valine <=> tryptophan + valine, does not involve phospholipid or cholesterol translocation, nor does it require ATP hydrolysis, which are the primary activities associated with the gene product. Therefore, the gene and the reaction are not related.
No

ENSG00000165029
O95477
MAR05530: threonine + tryptophan <=> threonine + tryptophan
ENSG00000103257 or ENSG00000165029
Pending No, the gene is not relevant to the reaction provided. Analysis and explanation. The gene ENSG00000165029 encodes a protein that catalyzes the translocation of specific phospholipids, such as phosphatidylcholine and phosphatidylserine, as well as sphingomyelin and cholesterol, using ATP hydrolysis. The provided reaction involves an exchange between threonine and tryptophan, which is unrelated to the gene's function in phospholipid and cholesterol transport. Additionally, there is no mention of threonine or tryptophan in the gene¡¯s annotated functions or catalytic activities. Thus, the gene and the reaction are not related.
No

ENSG00000165029
O95477
MAR05531: homoserine + tryptophan <=> homoserine + tryptophan
ENSG00000103257 or ENSG00000165029
Pending No, the gene is not relevant to the reaction provided. Analysis and explanation: The gene ENSG00000165029 involves the translocation of specific phospholipids and cholesterol across membranes, catalyzed by the hydrolysis of ATP. It participates in the formation of nascent high density lipoproteins (HDLs) and prefers phosphatidylcholine and phosphatidylserine as substrates, along with sphingomyelin and cholesterol. The provided reaction, which involves homoserine and tryptophan, does not align with the gene's function or catalytic activities involving phospholipids and cholesterol. Therefore, the gene is not related to the reaction.
No

ENSG00000165029
O95477
MAR05532: isoleucine + tryptophan <=> isoleucine + tryptophan
ENSG00000103257 or ENSG00000165029
Pending No, the gene is not relevant to the reaction provided. Analysis and explanation: The gene ENSG00000165029 encodes a protein involved in the ATP-dependent translocation of specific phospholipids and cholesterol across membranes, aiding the formation of high density lipoproteins (HDLs). The cited catalytic activities describe reactions involving phospholipids, cholesterol, ATP, and related molecules, but none mention a reaction involving isoleucine and tryptophan. The provided reaction "isoleucine + tryptophan <=> isoleucine + tryptophan" does not align with the gene's phospholipid and cholesterol translocation functions. Therefore, the gene is not relevant to the reaction.
No

ENSG00000165029
O95477
MAR05534: cysteine + phenylalanine <=> cysteine + phenylalanine
ENSG00000103257 or ENSG00000165029
Pending No, the gene is not relevant to the reaction provided. Analysis and explanation: The gene ENSG00000165029 codes for a protein involved in the translocation of specific phospholipids and cholesterol across membranes, coupled with ATP hydrolysis. It functions in the formation of high density lipoproteins (HDLs) and preferentially transports phosphatidylcholine, phosphatidylserine, sphingomyelin, and cholesterol. The catalytic activities defined for this gene are specific to these substrates and do not include the reaction where cysteine and phenylalanine interconvert. Therefore, the gene is not relevant to the reaction involving cysteine and phenylalanine.
No

ENSG00000165029
O95477
MAR05535: leucine + phenylalanine <=> leucine + phenylalanine
ENSG00000103257 or ENSG00000165029
Pending No, the gene is not relevant to the reaction provided. Analysis and explanation: The gene ENSG00000165029 is involved in the translocation of specific phospholipids and possibly cholesterol across membranes, coupled with the hydrolysis of ATP. The reactions it catalyzes involve phospholipids such as phosphatidylcholine, phosphatidylserine, and sphingomyelin, as well as cholesterol. In contrast, the provided reaction involves the equilibrium between leucine and phenylalanine, which are amino acids. There is no indication from the gene's function or catalytic activities that it plays any role in amino acid reactions, making it unrelated to the leucine-phenylalanine interchange.
No

ENSG00000165029
O95477
MAR05536: phenylalanine + proline <=> phenylalanine + proline
ENSG00000103257 or ENSG00000165029
Pending No, the gene is not relevant to the reaction provided. Analysis and explanation: The gene ENSG00000165029 codes for a protein that catalyzes the translocation of specific phospholipids and cholesterol across membranes, utilizing ATP hydrolysis. The reactions it catalyzes involve substrates such as phosphatidylcholine, phosphatidylserine, sphingomyelin, and cholesterol, but not amino acids. The provided reaction involves phenylalanine and proline, which are unrelated to the gene's annotated functions involving lipid transport and ATPase activity. Therefore, the gene and the reaction are not related.
No

ENSG00000165029
O95477
MAR05537: asparagine + phenylalanine <=> asparagine + phenylalanine
ENSG00000103257 or ENSG00000165029
Pending No, the gene is not relevant to the reaction provided. Analysis and explanation: The gene ENSG00000165029 is involved in the translocation of specific phospholipids and cholesterol across the membrane coupled to ATP hydrolysis. It has catalytic activities related to phosphatidylcholine, phosphatidylserine, sphingomyelin, and cholesterol transport, as detailed in several referenced studies. However, the reaction provided involves the interconversion of asparagine and phenylalanine, which is not related to the functions and catalytic activities of the gene described in the annotation.
No

ENSG00000165029
O95477
MAR05538: phenylalanine + valine <=> phenylalanine + valine
ENSG00000103257 or ENSG00000165029
Pending No, the gene is not relevant to the reaction provided. Analysis and explanation. The gene ENSG00000165029 encodes for a protein that catalyzes the translocation of specific phospholipids and cholesterol across membranes, utilizing ATP hydrolysis. However, the reaction "phenylalanine + valine <=> phenylalanine + valine" involves amino acids phenylalanine and valine, and does not involve phospholipids, cholesterol, or ATP hydrolysis. Therefore, the gene's function does not relate to this reaction.
No

ENSG00000165029
O95477
MAR05539: phenylalanine + threonine <=> phenylalanine + threonine
ENSG00000103257 or ENSG00000165029
Pending No, the gene is not relevant to the reaction provided. Analysis and explanation. The gene ENSG00000165029 encodes a protein that functions as a transporter of specific phospholipids and cholesterol across cellular membranes, facilitating their movement from the cytoplasmic side to the extracellular or lumenal side, which is coupled with ATP hydrolysis. It is involved in processes such as the formation of high-density lipoproteins (HDLs) by transferring phospholipids to apolipoproteins. The gene exhibits catalytic activity for reactions involving phospholipids and cholesterol, but does not relate to the reaction involving phenylalanine and threonine. Therefore, based on the gene's function and catalytic activities, it is not relevant to the reaction phenylalanine + threonine <=> phenylalanine + threonine.
No

ENSG00000165029
O95477
MAR05541: isoleucine + phenylalanine <=> isoleucine + phenylalanine
ENSG00000103257 or ENSG00000165029
Pending No, the gene is not relevant to the reaction provided. Analysis and explanation: The function of the gene ENSG00000165029 is primarily involved in the translocation of specific phospholipids and cholesterol across cell membranes, utilizing ATP hydrolysis as part of its catalytic activity. This gene facilitates the transportation of molecules such as phosphatidylcholine, phosphatidylserine, and sphingomyelin, contributing to the formation of high-density lipoproteins (HDLs). In contrast, the provided reaction describes a simple amino acid equilibrium involving isoleucine and phenylalanine, which is unrelated to the phospholipid and cholesterol transport functions of the gene. Therefore, no direct connection exists between the gene's annotated functions and the isoleucine-phenylalanine reaction.
No

ENSG00000188687
Q9BY07
MAR05547: threonine + tyrosine <=> threonine + tyrosine
ENSG00000103257 or ENSG00000188687
Pending No, the gene is not relevant to the reaction provided. Analysis and explanation: The gene ENSG00000188687 encodes a protein that mediates sodium- and bicarbonate-dependent electrogenic sodium bicarbonate cotransport, which involves the transport of sodium ions and bicarbonate ions across cell membranes. The reactions associated with this gene involve the movement of hydrogencarbonate (bicarbonate) and sodium ions. However, the reaction provided (threonine + tyrosine <=> threonine + tyrosine) does not involve sodium or bicarbonate ions and is unrelated to sodium bicarbonate cotransport. Therefore, the gene and the reaction are not related.
No

ENSG00000103257
Q01650
MAR05565: proline + threonine <=> proline + threonine
ENSG00000103257
Pending No, the gene is not relevant to the reaction provided. Analysis and explanation: The provided gene ENSG00000103257 encodes for a transporter involved in the uptake and exchange of large neutral amino acids, thyroid hormones, and other specific molecules across the cell membrane. However, the reaction mentioned (proline + threonine <=> proline + threonine) does not involve the transport or exchange of the amino acids that the gene's product is known to mediate. Therefore, the gene is not related to the described reaction.
No

ENSG00000103257
Q01650
MAR05566: homoserine + proline <=> homoserine + proline
ENSG00000103257
Pending No, the gene is not relevant to the reaction provided. Analysis and explanation: The gene ENSG00000103257 encodes a protein that functions primarily as a sodium-independent, high-affinity transporter involved in the uptake of large neutral amino acids, L-DOPA, thyroid hormones, and nitrosothiols across cell membranes. It is also involved in mTORC1 activation and uptake of toxic methylmercury. The reaction provided (homoserine + proline <=> homoserine + proline) does not involve the transport or exchange of any of these molecules, thus there is no relevance between the gene and the reaction.
No

ENSG00000103064
Q92536
MAR05597: asparagine + glycine + Na+ --> asparagine + glycine + Na+
ENSG00000103064 or ENSG00000103257
Pending No, the gene is not relevant to the reaction provided. Analysis and explanation. The gene ENSG00000103064 functions primarily as an antiporter for exchanging cationic amino acids like L-arginine with various neutral amino acids and sodium ions. The reactions it catalyzes involve the exchange of L-arginine with other amino acids such as L-lysine, L-leucine, L-glutamine, and others. However, the reaction provided: "asparagine + glycine + Na+ --> asparagine + glycine + Na+" does not involve L-arginine or the specific amino acids mentioned in the gene's annotation. Thus, this gene does not participate in the specified reaction.
No

ENSG00000103257
Q01650
MAR05599: glycine + Na+ + threonine --> glycine + Na+ + threonine
ENSG00000103064 or ENSG00000103257
Pending No, the gene is not relevant to the reaction provided. Analysis and explanation: The gene ENSG00000103257 encodes a protein that functions primarily as a transporter for large neutral amino acids and certain thyroid hormones, as well as being involved in L-DOPA transport and activation of mTORC1 signaling. The catalytic activities associated with this gene involve the transport of specific amino acids and thyroid hormones across cell membranes. However, the provided reaction "glycine + Na+ + threonine --> glycine + Na+ + threonine" does not involve the transport of large neutral amino acids or thyroid hormones, nor does it involve L-DOPA transport or mTORC1 signaling activation. Therefore, the activities and functions of the protein encoded by the gene ENSG00000103257 do not match the reaction provided, indicating that the gene is not relevant to this reaction.
No

ENSG00000103064
Q92536
MAR05600: glycine + homoserine + Na+ --> glycine + homoserine + Na+
ENSG00000103064 or ENSG00000103257
Pending No, the gene is not relevant to the reaction provided. Analysis and explanation. The gene ENSG00000103064 encodes a protein that functions primarily as an antiporter involved in the exchange of cationic and neutral amino acids such as L-arginine, L-leucine, and L-glutamine, among others. The described reactions involve L-arginine exchange with several different amino acids and sodium ions. However, the provided reaction is the conversion of glycine and homoserine in the presence of sodium ions, which does not align with the known catalytic activities of the protein encoded by this gene. Therefore, this gene is not related to the reaction involving glycine and homoserine.
No

ENSG00000103064
Q92536
MAR05604: alanine + Na+ + serine --> alanine + Na+ + serine
ENSG00000103064 or ENSG00000105281 or ENSG00000115902
Pending No, the gene is not relevant to the reaction provided. Analysis and explanation. The gene ENSG00000103064 encodes a protein that functions as an antiporter for cationic and neutral amino acids, specifically involving the exchange of L-arginine with other amino acids such as L-lysine, L-leucine, L-glutamine, L-histidine, L-cysteine, and L-methionine, in both sodium-dependent and sodium-independent manners. The provided reaction involves alanine and serine along with sodium ions, which are not substrates or products mentioned in the gene's known catalytic activities. Therefore, based on the gene annotation, the gene ENSG00000103064 is not relevant to the given reaction.
No

ENSG00000103064
Q92536
MAR05605: alanine + methionine + Na+ --> alanine + methionine + Na+
ENSG00000103064 or ENSG00000103257
Pending No, the gene is not relevant to the reaction provided. Analysis and explanation: The gene ENSG00000103064 encodes a protein functioning primarily in the antiport of cationic and neutral amino acids such as L-arginine, L-leucine, L-glutamine, and others, often involving sodium ions. However, the specified reaction involves alanine and methionine, which are not listed among the substrates transported by the gene's product. The gene's function and catalytic activities do not align with the given reaction.
No

ENSG00000103064
Q92536
MAR05607: alanine + Na+ + phenylalanine --> alanine + Na+ + phenylalanine
ENSG00000103064 or ENSG00000103257
Pending No, the gene is not relevant to the reaction provided. Analysis and explanation: The gene ENSG00000103064 encodes a protein that primarily functions as an antiporter for cationic and neutral amino acids such as L-arginine, L-leucine, L-glutamine, and L-lysine, often involving sodium ions. The catalytic activities listed involve specific exchanges between L-arginine and other amino acids. However, the provided reaction involves the exchange of alanine and phenylalanine, which is not mentioned in the gene's annotated functions or catalytic activities. Therefore, the gene ENSG00000103064 is not related to the provided reaction.
No

ENSG00000103064
Q92536
MAR05609: alanine + cysteine + Na+ --> alanine + cysteine + Na+
ENSG00000103064 or ENSG00000105281 or ENSG00000115902
Pending No, the gene is not relevant to the reaction provided. Analysis and explanation: The gene ENSG00000103064 encodes a protein that functions as an antiporter, which primarily facilitates the exchange of L-arginine with other amino acids such as L-leucine, L-glutamine, L-lysine, and others, often involving sodium ions (Na+). The catalytic activities described for this gene do not include the reaction involving alanine and cysteine with sodium. Therefore, there is no relevance between the gene's annotated functions and the reaction provided.
No

ENSG00000103064
Q92536
MAR05610: alanine + leucine + Na+ --> alanine + leucine + Na+
ENSG00000103064 or ENSG00000103257
Pending No, the gene is not relevant to the reaction provided. Analysis and explanation: The gene ENSG00000103064 encodes a protein involved in the antiporter mechanism that exchanges cationic and neutral amino acids such as L-arginine, L-lysine, L-leucine, L-glutamine, and others, primarily in exchange with sodium ions. The specific reactions listed in the gene's function involve L-arginine and various other amino acids. The provided reaction, "alanine + leucine + Na+ --> alanine + leucine + Na+," does not match any of the catalytic activities described for the gene ENSG00000103064, hence it is not relevant.
No

ENSG00000103064
Q92536
MAR05613: alanine + Na+ + valine --> alanine + Na+ + valine
ENSG00000103064 or ENSG00000103257
Pending No, the gene is not relevant to the reaction provided. Analysis and explanation: The gene ENSG00000103064 encodes a protein that functions as an antiporter for cationic and neutral amino acids such as L-arginine, L-lysine, L-leucine, and others, in the presence or absence of sodium ions. The described catalytic activities and reactions involve various amino acids like L-arginine, L-lysine, L-leucine, L-glutamine, L-histidine, L-cysteine, and L-methionine. However, the provided reaction involves alanine, valine, and sodium, which are not substrates documented in the gene's described functions and activities. Therefore, the gene and the reaction are not related.
No

keep ENSG00000149150(Uniport that mediates the transport of neutral amino acids) for MAR05441: homoserine <=> homoserine.

Agree to keep ENSG00000149150 for MAR05441.


Unexpected behavior when configuring settings with .env file and nested settings with settings class inheritance

Checks

[x] I added a descriptive title to this issue
[x] I have searched (google, github) for similar issues and couldn't find anything
[x] I have read and followed the docs and still think this is a bug

Bug
Output of python -c "import pydantic.utils; print(pydantic.utils.version_info())":
             pydantic version: 1.8.1
            pydantic compiled: True
               python version: 3.8.8 (default, Mar 19 2021, 16:09:34)  [Clang 11.0.3 (clang-1<IP_ADDRESS>)]
                     platform: macOS-10.15.7-x86_64-i386-64bit
     optional deps. installed: ['dotenv', 'typing-extensions']

Hello! I'm really enjoying this package, but I've encountered some unexpected behavior that I haven't been able to find a solution for.
Say I have a model structure like so:
import pydantic

class OtherSettings(pydantic.BaseModel):
    apple: str = 'Fiji'
    banana: str = 'yum'

class Settings(pydantic.BaseSettings):
    env: str = pydantic.Field(..., env='my_env')
    other: OtherSettings = OtherSettings()

class SpecificEnvironmentSettings(Settings):
    other: OtherSettings = OtherSettings(apple='Gala')

    class Config:
        env_prefix = 'my_'
        env_file = '/path/to/.env'

def settings_factory():
    if Settings().ENVIRONMENT == 'specific':
        return SpecificEnvironmentSettings()

SETTINGS = settings_factory()
...

There are cases where I'd like to set a field in OtherSettings via the .env file. However, I've found that when I attempt to set a single field in the .env, I get the wrong default values of the other fields. In this example, if I have in my .env:
my_other='{"banana":"gross"}'

And I trigger the use of the SpecificEnvironmentSettings class, instead of the expected apple='Gala', I get the "original" default value of apple='Fiji'.

I should note that an obvious way around this would be to implement more "flattened" settings classes, but I'm hoping to avoid that if I can. We're fans of being able to implement modular settings "sections"

I've found that I can actually get this to work if I do the following:
Instead of defining subclasses of the base Settings class:
...  # Following the example above

def settings_factory():
    if Settings().ENVIRONMENT == 'specific':
        return SpecificEnvironmentSettings(other=dict(apple='Gala'))

...

Specifically, the merging is successful if I use init variables that are specifically dictionaries rather than overriding the nested "sections". I would imagine that it should also work with an instance of OtherSettings too, but it doesn't.

I think it's the expected behavior. because when you set the my_other='{"banana":"gross"}' environment variable, you are overriding the default value of the other field in the SpecificEnvironmentSettings model and set it to OtherSettings(banana='gross') and as you didn't provide the default value for apple it uses the Fiji which is the default value


Update r7insight_lambdaCW.py

Messages which contain new line are not getting pushed from CloudWatch due to encoding issues.
The new line character is first converted to Unicode. Then the message is appended with a new line before sending to the socket connection.
Sharing the test data for the function to view the difference.
event={'awslogs': {'data': 'H4sIAAAAAAAAAE2QW08bMRCF/4plXorEJr7Et0WViOgWkFIJ2O1L0yjaJhayml0vtkMaIf474wQK9ot95sxnn3nGnY2xfbDNfrC4xN+mzXT5o6rr6VWFz7Df9TaATKiR1AgjtNIgb/zDVfDbASrjdhfHYR3Hro+p7Vd27Fi+xo3fPW5t2B/tdQq27cB/qIIWt3/iKrghOd9/d5tkQ8Tl/FguujaCUGRGAc2xCO3g1qoY9lzixQFYPdk+5ZZn7NbA5ZLJiZJEKcOkIpxTRRmnXBH4ueaCS6EMxFBaMkLAIKgxE53TJAczSG0HcShQqNSUTrSgZ++zAfwJasBVIkYYLYgqKG+IKRktxWQEVk3kr9/9CfoZbbi49jGVKLpu2Lhl8D7NP50X6AKhOSWjvBnTC4Ru1sClhislSIbc5bEt0+E9MSKEaK0QmvnV3zeRZBEWuve7uIwwiBJRdLzZf23negtIYNVVg/6n+/oR7jyXZtVlg+pZVd1+Eafn+GXx8grpQBRCDQIAAA=='}}

@rjacobs-r7  : Thanks for the suggestion. Code looks cleaner now.


Generate licenses summary

Fixes #77. This adds generation of a dependency license summary, listing all of DIDKit's Rust/Cargo dependency packages and their licenses. The resulting file is intended to be included in binary distributions of DIDKit, and may be useful for other applications embedding DIDKit, e.g. https://github.com/spruceid/credible/issues/62.
The cargo tree command is used as the basis for walking the dependency tree and assembling the list of packages.
Getting the dependencies of the Rust runtime (std) is done by running cargo tree in the Rust source repo; the output of that is checked in here (licenses/std.tree) so that having Rust source is not needed when building DIDKit but only when it is desired to update this Rust toolchain dependency info.
I considered using cargo metadata instead of cargo tree, but that command does not have as many options for adjusting the results (to only include "normal" dependencies, not build or dev dependencies, and to show results for all targets) and doesn't seem to offer additional useful info. (The license file field seems to always be empty).
What is currently missing from the resulting generated license summary are the Copyright attribution lines, which are used at the top of form licenses like MIT and required to be preserved. What might need to be done to get this info is to fetch the License files from the source repos, like cargo-license-hound does, and/or include the resulting data in this repo.

[x] List licenses and generate summary.
[ ] Integrate licenses summary into binary packages.
[ ] Add attributions (Copyright lines) to summary.
[ ] Associate Rust std cargo tree output with toolchain version?
[ ] Check for Apache-2.0 NOTICE files in dependencies. (Automatically?)

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

Closing old PRs


Issue 554

This PR adds support to the HTTP client for geo metadata requests.

Actually ignore the PR. Would be better to merge it into whatever branch you're working on for the next release.


Issue/5543 resource file upload should ignore identical files

Description
The stat_file API endpoint now returns a set of files instead of a list.
closes #5543
Self Check:
Strike through any lines that are not applicable (~~line~~) then check the box

[x] Attached issue to pull request
[x] Changelog entry
[x] Type annotations are present
[x] Code is clear and sufficiently documented
[x] No (preventable) type errors (check using make mypy or make mypy-diff)
[ ] Sufficient test cases (reproduces the bug/tests the requested feature)
[ ] Correct, in line with design
[ ] End user documentation is included or an issue is created for end-user documentation (add ref to issue here: )

@bartv FYI

Processing this pull request

Merged into branches master, iso6 in 205a54d113b03cf69ba3b5e87ae8623672cfd086

Processing #5592.


Sass watcher with GenerateAssemblyInfo=false

Sass command not found, not watching for changes.
GetSassCommand() is returning null when Sass watcher was enable and GenerateAssemblyInfo was false.
To Reproduce
Steps to reproduce the behavior:

Set GenerateAssemblyInfo to false in csproj file
Add the Sass watcher to your startup.cs.
Run the application

Expected behavior
The GetSassCommand() method able to find the ../runtimes/.. sass executable instead null.
Additional context
Maybe a better way to locate the sass binary instead using reflection by [SassCompilerAttribute]

I'm also getting this issue on 1.44.0


include Image in runhouse init

made this change so we could call: my_image = rh.Image(...)

#1487  👈 (View in Graphite)
main

This stack of pull requests is managed by Graphite. Learn more about stacking.

can we go ahead and close this PR?


moves validator code into prompting package

This PR moves the validator init code into the prompting package. This facilitates the code to be accessed within the prompting package scope, making in it easy to integrate with pip install @git/prompting (useful for applications built on top of prompting code).

Does this mean that miners will have to build environments to support the entire validator code? I know that currently they have to anyway, but will this make decoupling the requirements impossible in the future?


fix changelog typo

@bacongobbler,
Thanks for your contribution as a Microsoft full-time employee or intern. You do not need to sign a CLA.
Thanks,
Microsoft Pull Request Bot


Attributes not coerced when persisted

class User
  include Lotus::Entity
  attributes :id, :name, :age
end

mapper = Lotus::Model::Mapper.new do
  collection :users do
    entity User

    attribute :id,   String
    attribute :name, String
    attribute :age,  Integer
  end
end.load!

user1 = User.new(name: 'Luca', age: '32')
UserRepository.persist(user1)

When user1 is persisted, the age is not coerced to an Integer before persisting and remains as a string. For dynamic datastores (e.g. RethinkDB), the type is kept intact.
When retrieved from storage, user1.age is coerced to an Integer from a String.
Is this behavior intended? I can see how input should be type-validated before it reaches the persisting method, but defining the type in the mapper should guarantee the type is saved properly.
Is it the job of the adapter to coerce the attributes?

IMHO I think should be coerced before and after, maybe if we coerce the value before, after it doesn't make sense and so the correct value coerced is stored in the database (or another system) with the correct type

The coercion is the job of the Repository. After the repository persist the entity, it does not refresh the entity thus you might see the entity's values are not coerced.
If you look into the DB, the stored values are coerced. And when you use Repository to find the entity, this time the entity values would reflect correctly.
I think it is a good idea to refresh the states of the entity after successful persist operation. Thoughts?

@angeloashmore I'll have further discussion with @jodosha as I try to avoid additional calls. Thanks for reporting.

@angeloashmore What's your use case? Is that database shared from with other services that need a stricter type check on data?
Until know, #to_record doesn't coerce because that information about the Ruby type can be lost while writing on certain databases.
Think of Redis:
[1] pry(main)> require 'redis'
=> true
[2] pry(main)> r = Redis.new
=> #<Redis client v3.2.0 for redis://<IP_ADDRESS>:6379/0>
[3] pry(main)> r.set('x', Integer("1"))
=> "OK"

% redis-cli
<IP_ADDRESS>:6379> get x
"1"

We coerced our input from String ("1") to Integer and then persisted it. Later on, if we introspect the value stored by database, it's a string. Our coercion get lost, because the database doesn't support that type.
From a Lotus::Model perspective, it should guarantee that a value fetched from the database will be coerced into the mapped Ruby type.
It's true, we're lucky enough in SQL world, where database engines will anyway coerce that value into an integer because we have types in schema definitions.
On the other hand, I'm not easy to add a computation overhead for the most common scenarios that don't need it.
What to do then?
Option 1
There is an extension point for adapters when they explicitly ask for database conversion. Sql::Collection is an example: it has a @mapped_collection which is an instance of Mapping::Collection. It's an object that holds the mapping definitions for that collection.
When it needs to create a record, it asks to the @mapped_collection to serialize it. But you can do the opposite:
private
def _serialize(entity)
  MyCoercer.new(entity).coerce
end

Option 2
Add another setting in Model::Configuration to specify a coercer object to pass when the mapper is instantiated. @joneslee85 thoughts on this option?

@angeloashmore There is a different issue about the returned entity from a BookRepository.create operation, and I agree with you: it should return the coerced entity.
book = BookRepository.create(Book.new(price: '10'))
book.price # => "10" WRONG, it should be an integer.

This can be easily fixed.

@jodosha @joneslee85 In my opinion, attributes should be coerced via the mapper before persisting. Is this what you mean with Option 2?
This would allow the adapter and database library to handle any entity/database type differences.
In your Redis example, the Redis library accepted an Integer despite not handling Integer as a type. The library automatically saved a String instead. Let's say in the future the user changes the adapter, for example to RethinkDB. This new database accepts Integers and thus will keep the type.
Persisting to the database

Call Repository#persist
Repository coerces attributes using the mapper before persisting.
Repository persists the entity to the database with the coerced values.

Retrieving from the database

Call Repository#find
Repository gets the database record/document and coerces attributes using the mapper.

This ensures the following:

Adapter recieves all attributes with the correct, expected types
Adapter or DB library handles any type changes if necessary (e.g. unsupported types)
Database methods can run queries in an expected way (e.g. we can now assume :age will always be an Integer in the DB, so we can run #sum)
Retriving using the Repository always returns the correct types

I noticed the issue when running math functions (e.g. #sum, #avg, #max, #min) directly on the database via a Collection object.
The repository was persisting Strings and Integers for the same attribute depending on how the entity was initiated, so the database could not compute the equation due to the type mismatch.
  # raises error if type mismatch on `age` field
  query do
    where { |u| u[:age] > 10 }
  end.sum(:age)

If the database can save arbitrary types and values are only coerced upon deserialization, the equation would need to be computed via Ruby after retrieving all values of the attribute. I would imagine this would be slower (just a guess; I have not actually tested the performance).

@angeloashmore I was wrong, you were right.
I've replied without having the code around, so my thinking was biased by the initial design.
I've put in place coercion before persistence to avoid to hit the database to reload the record.
Can you please give #141 a try and see if it solves your problems? Because this is a blocking issue, once I get your and @joneslee85 go, I'm keen to release a patch version for this.

@jodosha Sorry for the late reply. Just had a chance to test it out. Everything looks good! :+1:

@angeloashmore No worries, expect a patch release soon.

@angeloashmore https://rubygems.org/gems/lotus-model/versions/0.2.2


prevent undefined bitshift

Prevents undefined bitshift described in https://github.com/Esri/lerc/issues/222
Thanks to @setharnold for suggesting assert() which may help identify misuse of library by third parties.

Closing. Please see https://github.com/Esri/lerc/pull/224 instead.