Data lose after restart HA

Not sure if this is expected. Everytime restart HA, all data from bodymiscale will lose and status will become problem.

Je ne sais pas si cela est attendu. À chaque redémarrage de HA, toutes les données de bodymiscale seront perdues et le statut deviendra un problème.

Yes this is normal, the component reads the sensor (s). To compensate, I put in place a node red.
https://community.home-assistant.io/t/exemple-xiaomi-miscale-select-the-person-who-weighs-himself-notif-action/299321

this can be solved in a simple way:
go to integrations, choose "configure" on the Bluetooth Low Energy Monitor integration, check if "Restore state" is activated, otherwise activate it.
Now, after every restart of HA, the last State is shown

Bluetooth Low Energy Monitor integration,

There is no Bluetooth Low Energy Monitor integration under Configure->intergrations.

are you using esphome or Passive BLE monitor integration?

are you using esphome or Passive BLE monitor integration?
if you are using esphome, I don´t have a solution, but on passive BLE monitor it is working fine
unfortunately I using esphome.

Would it be possible to select for the weight and impedance sensors a helper?  i have an automation already setup to store the last recorded weight and impedance into a number helper (which gets restored at start time) so this would alleviate this regardless of ble integration or esphome.

Indeed, it could be simpler if it would be possible to specify an input_number helper as inputs for the integration.
Otherwise it is necessary to add extra template sensors as a workaround to bypass helpers' values like this:
template:
  - sensor:
    - name: "Weight (last value)"
      unique_id: weight_last
      unit_of_measurement: "Kg"
      icon: "mdi:weight-kilogram"
      state: "{{ states('input_number.weight_last') }}"

    - name: "Impedance (last value)"
      unique_id: impedance_last
      unit_of_measurement: "Omh"
      icon: "mdi:omega"
      state: "{{ states('input_number.impedance_last') }}"

For completeness, input number helpers:
input_number:
  weight_last:
    name: "Weight (last value)"
    min: 0
    max: 100
    step: 0.01
    unit_of_measurement: "Kg"
    icon: "mdi:weight-kilogram"
    mode: box

  impedance_last:
    name: "Impedance (last value)"
    min: 0
    max: 1000
    step: 1
    unit_of_measurement: "Omh"
    icon: "mdi:omega"
    mode: box

Automations to update input number helpers when sensor values obtained from ESPHome change:
- id: '1663000060470'
  alias: Save weight
  description: ''
  trigger:
  - platform: state
    entity_id:
    - sensor.weight
  condition: []
  action:
  - service: input_number.set_value
    data:
      value: '{{ states(''sensor.weight'') | float }}'
    target:
      entity_id: input_number.weight_last
  mode: single
- id: '1663000498790'
  alias: Save impedance
  description: ''
  trigger:
  - platform: state
    entity_id:
    - sensor.impedance
  condition: []
  action:
  - service: input_number.set_value
    data:
      value: '{{ states(''sensor.impedance'') | float }}'
    target:
      entity_id: input_number.impedance_last
  mode: single

That's almost exactly what Im doing now as well.  Just a bummer that the other values from the integration won't get updated till the next weigh in.  which is why I had wondered if we could just modify the selection from just those sensor values to just selecting the entity you want (in this case it would be the helpers)

Hello everyone, I follow your comments, have you looked at my proposal to go through node red and Node Red Companion.
With this solution no problem after a reboot but given are stored in each sensor node red companions
https://community.home-assistant.io/t/exemple-xiaomi-miscale-select-the-person-who-weighs-himself-notif-action/299321

Sorry, I'm new to HA, and I'm not familiar with Node Red yet.

I don't use node red, nor have any plans to.  So to do node red would add a full layer of something new just for this.  Just curious (from a developer perspective) what is the concern with allowing the selection of a helper entity?  please note, i have done 0 HA development, so I have no idea how involved any of that is :)

I forgot to specify following one of the last updates. Can you check your sensors normally each attribute has its own sensor this one must keep your data after the restart? Can you confirm it for me because my card currently uses the attributes and not the sensors? If this is ok for you then I should revise my card accordingly.

Which update?  I am on 3.0.3 and I still show all the sensors as unknown until i get on the scale after a restart.

input_number:
weight_last:
name: "Weight (last value)"
min: 0
max: 100
step: 0.01
unit_of_measurement: "Kg"
icon: "mdi:weight-kilogram"
mode: box
impedance_last:
name: "Impedance (last value)"
min: 0
max: 1000
step: 1
unit_of_measurement: "Omh"
icon: "mdi:omega"
mode: box

Can you please elaborate where to implement this solution as I'm a noob noobie?
Thank you in adnvance!

@grego1981 input_number section which you quoted has to be added to configuration.yaml file. After it is added you need to restart HA: Developer tools -> Check configuration and if the result is green -> Restart.
Or as a simpler approach, you could do the same via HA web interface without modifying configuration.yaml.
Just go to Settings -> Devices & Services -> Helpers tab -> Create helper -> Number -> Fill the fields with appropriate values -> Create
According to the https://github.com/dckiller51/bodymiscale/releases/tag/v3.0.4 with the very recent version of the plugin it is no longer necessary to create template sensors (the first code snippet in my post). And it should be possible to use input number helpers directly in the plugin.
And automations (the third code snippet) are created via Services -> Automations & Scenes -> Create Automation.

I updated and switched to the helpers.  On HA restart though, Im not sure if the integration is triggering before the helpers restore.  But in my situation, all the sensors for bodymiscale still show as unknown.  BUT, without having to get on the scale, if i wait a bit and then hit reload, it does recalculate everything.  What is the trigger mechanism that does the calculations?

Confirmed.  Not pointing to the sensors, but only pointing to the input_number helpers.  both have valid values.

Thank you. Then I'm out of ideas so far.

check if "Restore state"

Just wanted to confirm that checking "restore state" in BLE instantly solved this for me.

this can be solved in a simple way (when using BLE monitor for Homeassistant):
go to integrations, choose "configure" on the Bluetooth Low Energy Monitor integration, check if "Restore state" is activated, otherwise activate it. Now, after every restart of HA, the last State is shown
Maybe dckiller51 can put that hint into the readme.md

Just wanted to confirm that checking "restore state" in BLE instantly solved this for me (didn't even need a restart).

I had the same issue when using ESPHome and the HA API. I noticed that commenting out api: and adding the following did the trick (requires MQTT though). No other adjustments necessary. It now seems to survive both esp32 and ha reboots without loosing the calculated values.
mqtt:
  topic_prefix: bodymiscale
  discovery: true
  broker: <IP_ADDRESS>
  port: 1883
  username: mqtt_user
  password: Pa$$w0rd
  discovery_prefix: homeassistant


docs: Update Reserved ENIs description

Fixes #N/A
Description
How was this change tested?
Does this change impact docs?

[ ] Yes, PR includes docs updates
[ ] Yes, issue opened: #
[x] No

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

Anything wrong with the contents of the change?


Fix git related issues found in release testing

Don't show git api keys when deploying an application

In the application env var
In the jetstream log if the clone fails

TO FIX

In helm/kube deployment gitlab projects fail to fetch due to mangled project name
Echo context reports c.Param(*) as projects/richardcox/my-private-repo instead of projects/richardcox%2Fmy-private-repo
This needs a separate fix to one implemented earlier where url.String() was mangling the path/project name

Also fixed the helm chart note's ClusterIP instructions

Codecov Report

Merging #4850 (173848b) into master (01e8abf) will decrease coverage by 25.36%.
The diff coverage is n/a.

@@             Coverage Diff             @@
##           master    #4850       +/-   ##
===========================================
- Coverage   52.91%   27.55%   -25.37%
===========================================
  Files        1141       60     -1081
  Lines       40149     4693    -35456
  Branches     5122        0     -5122
===========================================
- Hits        21246     1293    -19953
+ Misses      18719     3216    -15503
  Partials      184      184


Using --github-org only returns 25 repositories

Last time I used git-xargs was in May of this year, with the v0.0.14. And everything was fine.
I recently upgraded all my brew packages and nothing seems to works with the v0.0.16.
Describe the bug
When using --github-org to scan my company's org, git-xargs resolves only 25 of the few hundreds we have.
$ git-xargs --version
git-xargs version v0.0.16

$ git-xargs --loglevel DEBUG \
            --pull-request-title "Some title" \
            --commit-message "Doing things" \
            --branch-name "fix/my-things" \
            --max-concurrent-repos 1 \
            --github-org <ORG> --skip-archived-repos --dry-run touch helloworld.txt

[git-xargs] INFO[2022-07-20T16:56:14+02:00] git-xargs running...
[git-xargs] INFO[2022-07-20T16:56:14+02:00] Dry run setting enabled. No local branches will be pushed and no PRs will be opened in Github
[git-xargs] DEBU[2022-07-20T16:56:15+02:00] Skipping archived repository                  Name=<ORG>/***
[git-xargs] DEBU[2022-07-20T16:56:15+02:00] Skipping archived repository                  Name=<ORG>/***
[git-xargs] DEBU[2022-07-20T16:56:15+02:00] Skipping archived repository                  Name=<ORG>/***
[git-xargs] DEBU[2022-07-20T16:56:15+02:00] Fetched repos from Github organization: <ORG>  Repo count=25
[git-xargs] DEBU[2022-07-20T16:56:15+02:00] Using Github org: <ORG> as source of repositories. Paging through Github API for repos.
[...]
*****************************************************************
  GIT-XARGS RUN SUMMARY @ 2022-07-20 15:07:32.722381 +0000 UTC
  Runtime in seconds: 51
*****************************************************************

COMMAND SUPPLIED

[touch helloworld.txt]

REPO SELECTION METHOD USED FOR THIS RUN - (see README.md for more information)

github-org

 REPOS SUCCESSFULLY FETCHED VIA GITHUB API
| REPO NAME (22)          | REPO URL                                          |
|-------------------------|---------------------------------------------------|

To Reproduce

Generate Personal Token

With repo:*, read:org, write:org, and read:project

Execute git-xargs with the --github-org flag

Expected behavior
For git-xargs to actually follow up on the API pagination.
Nice to have

[x] Terminal output
[ ] Screenshots

Additional context

Edit: ℹ This one was coming from an improper permission set on the token
I also tried supplying a list via --repos but every call ends up in a 404.

$ cat repos.txt | wc -l
      81
$ git-xargs --loglevel DEBUG \
            --pull-request-title "Some title" \
            --commit-message "Doing things" \
            --branch-name "fix/my-things" \
            --max-concurrent-repos 1 \
            --repos repos.txt --skip-archived-repos --dry-run touch helloworld.txt
[git-xargs] INFO[2022-07-20T17:17:02+02:00] git-xargs running...
[git-xargs] INFO[2022-07-20T17:17:02+02:00] Dry run setting enabled. No local branches will be pushed and no PRs will be opened in Github
[...]
[git-xargs] DEBU[2022-07-20T17:17:02+02:00] Looking up filename provided repo             Name=documents Organization=<ORG>
[git-xargs] DEBU[2022-07-20T17:17:04+02:00] error getting single repo                     AllowedRepoName=documents AllowedRepoOwner=PayFit Error="GET https://api.github.com/repos/<ORG>/documents: 404 Not Found []" Response Status Code=404
[...]

$ gh repo view <ORG>/documents
<ORG>/documents

[SHOWS THE README]

Hi, it's possible this is a duplicate of #77 - could you please give #85 a shot and see if that branch resolves your issue?
Thanks!

Hi @zackproser,
I tested master and v0.0.14 alternatively with the same results.
Which led me to have a look at the token's permissions, and the issue lied there. Bad configuration from my end.
With a correctly setup token everything works fine 👌
Apologies for the noise 🙇

Roger - thanks for closing the loop and no worries :+1:


[type:fix] remove log

Codecov Report

Merging #105 (c35fc3c) into main (1f20cce) will increase coverage by 3.52%.
The diff coverage is 0.00%.

:exclamation: Current head c35fc3c differs from pull request most recent head b80cc68. Consider uploading reports for the commit b80cc68 to get more accurate results

@@            Coverage Diff             @@
##             main     #105      +/-   ##
==========================================
+ Coverage   86.15%   89.68%   +3.52%
==========================================
  Files          30       27       -3
  Lines        1040      853     -187
==========================================
- Hits          896      765     -131
+ Misses        108       64      -44
+ Partials       36       24      -12

Impacted Files
Coverage Δ

core/lang/snowflake.go
91.07% <0.00%> (ø)

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 1f20cce...b80cc68. Read the comment docs.


fix: invalid annotation name exceptions

Purpose
Fixes #185.
Approach
Sanitises the data by stripping all properties starting with @ before sending it to the Web API.
TODOs

[x] Automated test coverage for new code
[x] Documentation updated (if required)
[x] Build and tests successful

/azp run

/azp run

/azp run

/azp run

/azp run


liron's ButteredBread fixes

for #119 i've implemented the simple solution but you could also just make sure you've iterated over all users and that way you don't need to pass an array of users to update and don't need to keep scaling factor per user in the contract or to sync voting weights.
for #117 i've just added a warning, as decided by @RonTuretzky

added custom errors, note that if you upgrade your solidity version  you can use the nicer require(bool, error) pattern :)


Windows build

Hi,
Is it possible to add support for Windows build?
Thank you!

I would also be interested in this!
I made a quick proof-of-concept in a fork and it seems to boil down to just these changes:

Add windows-latest to the os-matrix in build-and-release.yml
Add windows-amd64 to the PLATFORM_LIST in the Makefile
Adding a windows-% build step in the Makefile

See the diff here
https://github.com/knight42/krelay/compare/main...helmuthb:krelay:main
for a proof of concept (I changed "knight42" to "helmuthb" just because I wanted to see the published files) and https://github.com/helmuthb/krelay/releases for the files built.
Not sure whether installing from krew would work (maybe some details have to be adjusted) but after renaming the file contained in kubectl-relay_v0.0.6_windows-amd64.tar.gz to have the .exe-suffix and manually putting it into the krew-folder I can now use kubectl relay from my windows client.

I made a quick proof-of-concept in a fork and it seems to boil down to just these changes:

Thanks for your work, really appreciate it! The changes LGTM, please feel free to file a PR.

Thanks for your work, really appreciate it! The changes LGTM, please feel free to file a PR.

I tried to make a clean PR with only the needed changes. I also added changes which create a kubectl-relay.exe instead of kubectl-relay for Windows, and also added a change to use the kubectl-relay.exe when creating the windows version of the .tar.gz file.
For the last change I use a case-statement in the Makefile - let me know if you prefer a different approach instead and I'll rework it accordingly.

Thank you!


Add security scheme for OAuth2.

Sorry for pinging. Any news about this? I have several other commits in the queue. :)

No worries, thanks a lot!


fix: ALTER TABLE result output

fwiw, I'm attempting to use fakesnow to test alembic migrations of snowflake 😬.
You already have a test for alter table, but sqlalchemy (versus the raw cursor) always calls .description on the results of queries and it was hitting similar issues to issues you've already solved with e.g. CREATE TABLE etc.
I deviated from the pattern a little bit because AlterTable constructs returned ALTERTABLE as the cmd. It seemed somewhat unfortunate to compare exactly against that, but also seemed very likely that other ALTER statements would have the same generic output.

Thanks for this. I've moved the test into test_description_create_alter_drop_table with the related tests, rather than make it as sqlalchemy specific thing.


Deploying Pixie fails for Minikube v1.12.0+

Bug Fix Status: the vizier release later today will contain the fix.
Workaround (until vizier release lands later today):
kubectl scale deployment --replicas=2 coredns -n kube-system

This bug was fixed in Vizier version 0.5.15 (released 12/9/20).


Incorrect indentation with data declaration

If I start with this file:

And I hit <Enter>, <Comma>, <Space>, I get this:

However, I was expecting to get this:

This does not seem correct. I have confirmed that if I remove the Plug 'neovimhaskell/haskell-vim' line from my .vimrc file, the problem does not exist.

I'm seeing this behavior too.
I git bisected it and it appears to be caused by commit e6937cb8fbb95c.
For the time being, using haskell-vim at commit 27cbc4b758f5 (which is the direct parent of commit e6937cb8fb) appears to mitigate this problem.

Hmm, using commit 27cbc4b seems to have some problems of its own.
Also, it looks like @raichoo is collecting bad examples of indentation at #73.  The information on this thread can probably be moved to there.  Then this thread can be closed.

I current can't reproduce this with recent neovim and my setup (which is pretty minimal in terms of plugins).

I'm currently using haskell-vim in regular vim, not neovim.
I haven't tested in neovim, but I'm guessing that there is some difference in how either the indentation stuff works, or the results of the vim-provided built-in functions.

My usual guess is that some other plugin might be interfering. It sort of became a reflex to think that but it happened to be the case surprisingly often.

Thanks for the tip!  I'll have to try disabling some of my other haskell-related plugins and see if I can determine which one is to blame.

@cdepillabout Did you ever pinpoint what it was. I am seeing this behavior in neovim.

@raichoo Also similar to @centromere if I remove Plug 'neovimhaskell/haskell-vim' then I see the expected indentation.

@codedmart Sorry, I haven't had time yet to try to pinpoint the reason.

@raichoo Any guess as to what would be interferring? WIth 'neovimhaskell/haskell-vim' I see the indentation issue. Without 'neovimhaskell/haskell-vim' I don't see the issue anymore.

I've played around with this and it seems like the culprit is probably haskell-vim.  I've tried disabling all my other plugins, as well as most of my other vim options, and nothing fixes this.
However, if I disable haskell-vim and just use the normal indentation for vim from Haskell, indentation works correctly.  I'm going to look at the haskell-vim source code and try to figure out what is going wrong.

I've also now tried neovim, and it seems like the problem doesn't improve.
Just to make sure we're all on the same page, here is a complete description of the problem I am seeing:

Imagine I am writing a data declaration.  I start by writing something like the following:
data Foobar = Foobar
  { foo :: Int

My cursor is right after the t in Int.

Here, I press enter to go to the next line.  The cursor is correctly lined up under the open bracket {:
data Foobar = Foobar
  { foo :: Int
  _

From here, I press , to insert a comma, and then space.  Right after I press space, haskell-vim changes the indentation to the following:
data Foobar = Foobar
  { foo :: Int
    , _

You can see that the comma has been indented two spaces when it should not be.

If you manually go in and de-dent the comma, then when you go to the next line it will be indented correctly.
For example, if I have the following:
data Foobar = Foobar
  { foo :: Int
  , bar :: Char_

My cursor is right after the r in Char.   If I press enter here, the next line will be indented correctly.  It will not do an extra indent after pressing ,.

The above problem also happens with any sort of tuple, lists, etc.

I believe that the offending code is the following:
https://github.com/neovimhaskell/haskell-vim/blob/b1ac46807835423c4a4dd063df6d5b613d89c731/indent/haskell.vim#L160-L188
My guess is that this somehow plays poorly with autoindent (which I have on).

Commenting out these lines fixes this for me:
https://github.com/neovimhaskell/haskell-vim/blob/master/indent/haskell.vim#L182-L186


Not getting notifications if you are just a contributor of a kata

I have been discussing this for a time with others of the most active users and I think we could boost a lot the quality of the CW experience if we built a system that allowed users to directly contact the author/translator of a given version of the kata to report bugs, suggest improvements or (why not) request clarifications.
Currently this is not directly possible (I either find some issue re-checking an old kata or get contacted via mail, hangout or twitter by the author himself), but I think an improvement in that way shouldn't take too many resources and would help in making us all feel more like an unique community.
A bug reporter could also get some small reward (like 1pt of honour if there was an actual bug, which seems fine as we get 2pts for just doing a beta kata) and, to prevent abuse, you could limit the number of times an user can ask for help on a specific kata by something like 1+1/100pts. Users like bkaes, jolaf or ChristianECooper (just to name the very first few that come to my mind) provided me and other authors with tons of useful tips and suggestions, so they surely did something good for CW.
Conversely you could also think of rewarding an author/contributor which actively checks and fixes his/her kata, but this could be a bit more debatable (if I did all perfectly working from the beginning, I get no reward, but that could be checked and thus rewarded too).

Are you sure the issue's title matches its contents? Either way, I think a "Watch" option similarly to the github function would be great, a way to manually (un-)subscribe to a discussion.

Mh, it seems to me the title addresses the main part of it, yeah: do you feel it ambigous? And how much is this "while"? Because I didn't get notification after a few days I did a translation and posted about it.

And how much is this "while"?

Well, in this particular case I'm talking about the manual (un-)subscribe method, something that isn't implemented at all. Also, I think that directly contacting a contributor might lead to a dead end. It's still a good way to get things done, but a more general flag system might make things even better. That way, you could flag a kata for author/translator/moderator attention. I think my feature request about that is still visible in the FR forum, but I'm not completely sure.
Other than that, I like your overall approach, reminds me of StackOverflow's review queues and edit reputation.

Kata authors are always sent email notifications about new discussions within their kata, unless they have notifications completely turned off. Currently, translators do not get these by default. We have an auto-unsubscribe system that stops sending you notifications on a thread you were active on after 3 days of inactivity.
I think ideally @GiacomoSorbi style user links could be used to trigger a notification to a specific user.

My initial idea was more on the spirit of bkaes-senpai comment, but I know it would be a bit more complex to implement: ideally when user X has an issue on kata Y, he/she could submit a comment and that comment is pushed to everyone which is interested (author, translators and other contributors): I click there, see if anyone has already flagged that he/she is taking care of it and, if not and if it something I can do, I flag it and try to fix it. If I cannot fix it, I can deflag it and the ball is put on the centre of the field again.
To make things even smoother, a power-user could be allowed to edit even approved kata he didn't contribute to (which is now is still returning a 500 error, if I am not wrong) and to browse a list of current issues, sortable/filtered by both language and solved/all categories.
The flag goes away when either X or at least two among author and contributors agree that it is solved; power-users (again: possibly with a small reward) or admin could only have to check for very old or disputed (X and a sole contributor disagree on it being solved) flags.
This would help solve (or at least greatly reduce) the problem that we are facing as we are growing bigger and bigger (which, per se, is surely good): right now, on a side there are lots of kata which could be fixed with very small fatigue (and we surely have a good number codewarriors willing and able to do a thorough job about it); on the other, there are lots of very old issues still open even if they are apparently solved, possibly because the original user is no longer active or simply didn't bother checking the issue as solved.
Final note of this long rant: implementing a more complex rewarding system, possibly with more gamification and differentiation in terms of achievements, would surely follow CW spirit of giving coders a training ground to improve and show their skills.
I see a small part of my points comes from an obscure "achievements" section, not sure about it, but I think it would be cool to differentiate a bit more and get badges (or even, better yet, weapons, scrolls or anything more in line with the feudal Japan theme) for specific tasks. I.e.: a guy solving 500 problems is good as he is one fixing 100 katas, but they could have different skills/mindsets/attitudes and it could prove of interest to both fellow codewarriors and external head hunters to be able to differentiate them at a glance.
Just my 0.02€ and I am really enjoying what CW is currently offering me and I can't stop encouraging others to come here and give it a shot; it is just that while I may be a rather poor coder, I should have grown some more aptitude to see things more from a marketing/user experience point of view. And there you always have room for further improvement.

OK I'm finally getting to this. I'm making it so that if the author hasn't been active within 3 days then all coauthors (including translators) + the author get the notification. Hopefully this doesn't become too annoying for some power users.

Hmm, I'm also going to only notify coauthors/translators when a new issue is added, not any comment (to reduce noise)


Remove ZMQ version related code

I noticed quite a bit of code for handling old ZMQ versions. Since we bundle ZMQ 4.1.5 we could remove it.
Should we do this?

I'm certainly a fan. What happens when we want to support the coming 4.2 release?
I'd be curious to hear @minrk's thoughts.

If you always bundle or build libzmq, there's no need to keep that stuff. You will want to keep something like that if you want to support linking libzmq installed on the system. This can be a useful fallback so you don't have to ensure that your scripts build libzmq on every platform. It comes up at pyzmq for things like AIX, Solaris, POWER, where the bundled libzmq isn't helpful.
There's very little to do to support most of 4.2. It's mainly a few extra socket types, and some implementations of poller functionality that isn't particularly relevant for higher level bindings.

Closed by #76


Added support for bone-exclusion and multiple child-bones

Fixed an issue where only the first child of a root bone would be accounted for in AddParticle
Added the ability to exclude certain children of root bones

This is a good idea, but for AkBoneDynamics.cs, the Constraint search part (void InitializeConstraints()) also needs to be edited.
AkBoneDynamicsLight.cs is Constaraint have been removed, so the problem does not arise.


Update load travel times to include j2000

Overview
The travel times files pxp_tt has 2 separate structures, which is stored in another file called pxp_tt_j2k. This file already has the time component as J2000 epoch time float and need to be handled. This update come about after conversation with @johnbdesanto yesterday. The change included in this PR is having an is_j2k flag, so that if this is True it means that we are expecting the pxp_tt_j2k file rather than the pxp_tt.

Looks like it's missing new tests?

I have yet to make tests for these loaders.. coming soon to your local github repo 😉


Fix various issues related to vertical spacing

Partially fixes #6291
form-group's screenshot

The styling was actually correct for the alerts, however, the dismiss button was rendered as last element, hence the css selector of disabling padding didn't work. Rearranging the order of components fixes it.

Regarding the last point in the issue, the admin page uses external css library and doesn't seem to be appropriate to create a css/scss file just to fix that. Maybe worth opening an issue in the upstream library AdminLTE (https://github.com/ColorlibHQ/AdminLTE).

I'll let @nlhkabu review this, but LGTM.

Thank you @ip4368 !


Suggestion to avoid port/address bind issues , like Error starting userland proxy: listen tcp <IP_ADDRESS>:80: bind: address already in use

in case of use of many different laradocks setups for different projects there a lot of such issues as by default laradock configured to use <IP_ADDRESS> as primary IP
docker-compose provides custom networks which can be used as workaround of bind problems
also seems '.env' already part of project so it might be useful to employ custom networks in some way like
http://oleksii-prudkyi.blogspot.com/2016/09/docker-compose-error-starting-userland.html
i.e. have
>cat .env
GATEWAY_IP=<IP_ADDRESS>
SUBNET=<IP_ADDRESS>/24

>cat docker-compose.yml
networks:
  export:
    driver: bridge
    ipam:
      driver: default
      config:
      - subnet: "${SUBNET}"
        gateway: "${GATEWAY_IP}"

as well every service should have updated ports and networks, like
services:
  nginx:
    image: nginx:latest
    ports:
      - "${GATEWAY_IP}:80:80"
    networks:
      - export

while implementing of this is relatively simple , it may affect current users

/etc/hosts should be updated to point to new IPs
projects settings should be updated as well, because ports will be available on new IP (and not on localhost)

so it can be added to docs instead

To use Laradock I definitely need to be able to set the IP of the local server, thank you for this post @oprudkyi.
Unfortunately I wasn't yet able to make it work: after changing the configuration according to those instructions and running docker-compose up -d nginx I get:
ERROR: for nginx  Cannot start service nginx: driver failed programming external connectivity on endpoint laradock_nginx_1 (831f12dce64d4355386e5bc671e945ab5bdf98741dab447b93b7cd5b268d529b): Error starting userland proxy: listen tcp <IP_ADDRESS>:443: bind: cannot assign requested address
Encountered errors while bringing up the project.

I am not sure where to add the networks definition. I included it only to the nginx block and then to nginx, workspace, php-fpm. In both cases I get the same error.


Problem starting serialmidi.py on mac os

Hi,
i'm trying run python serialmidi.py --serial_name=/dev/cu.usbmodem1444201 --midi_in_name="IAC Bus 1" --midi_out_name="IAC Bus 2"
But, i'm receiving erro:
MIDI IN Device name is incorrect. Please use listed device name.
MIDI OUT Device name is incorrect. Please use listed device name.

Could you run it without MIDI device name and copy the output here?
serialmidi.py --serial_name=[serial_port] --baud=[baud]
It will show the list of MIDI devices

I assume the issue is solved? I will close this, please reopen it if you still have issues.

I am having the same problem. When I run:-
python3 serialmidi.py --serial_name=["/dev/cu.usbmodem14201"] --baud=[115200]
with or without quotes on the device name then I get:-
/usr/local/Cellar/python/3.6.5/Frameworks/Python.framework/Versions/3.6/Resources/Python.app/Contents/MacOS/Python
I have tried putting serialmidi.py in this location to no avail.
Sorry but I have not had much experience with Python on the Mac, but I have worked a lot with it on the Raspberry Pi.
I am running this on Moajve if this matters, although I am having similar difficulties running your code on my iMac running OS Sonoma 14.2 .


Color Palette always selects bbr instead of bw

For all my scans the images are displayed with the bbr color palette instead of the usual bw.

The color palette is chosen based on the min value of the nifti file.
https://github.com/anibalsolon/vscode-neuro-viewer/blob/main/webview/nifti/index.ts#L24-L26
I would either like to see the standard bw scale being used or a button to switch the color palette.

hey @Linus4world thank you! Would you mind generating a histogram of the image please? I'm planning to be able to adjust the scale, to increase contrast, but a palette picker should be faster for now.

Here is a histogram of the ct scan. Note that there are some extreme outliers so I also attached a text file with all the values and their respective frequency.
hist_values.txt

Interesting! Yes, this scenario only thresholding can solve. Maybe it can do something more intelligent about it in the future, to identify these outliers. Please bear with me! 🔜
As a workaround, you can highlight some of the data using the right histogram, by selecting a range there with the cursor (click and move).

Great thanks for your support!
Yes, however, even if I select a range, I have no control over the color. It will either be displayed in blue, black, red or yellow

Yes indeed- I've added two new options: a color picker and a fine-tuner. The color picker is a bit obvious, but the fine-tuner allows you to adjust the color range for the distribution of your data. In the example, the image has a long tail from outliers, so I adjusted the white thumb to a more reasonable place in the image distribution. LMK what you think and if it helps in your case.

Yes perfect! That is exactly what I wanted. Thank you!
It would also be great if the extension could automatically save my preferences for the color palette so that I do not have to select it manually for every new sample.

Yeah, that would be great indeed. I'll have to think better about the settings, and what would be the most user friendly solution. Other than global options, an option is to record the choices in the file using Nifti extensions (a XML-like payload stored in the end of the file).
I've opened an issue to track this: https://github.com/anibalsolon/vscode-neuro-viewer/issues/18
Thank again for the feedback!


Bug report - Not presence/motion detection Tuya/Loginovo 24G Zigbee ceiling version

Describe the bug
Clear and detailed bug explained here with screenshots: https://community.homey.app/t/app-pro-tuya-zigbee-app/26439/4620?u=roberto2391
To Reproduce
Steps to reproduce the behavior:

Go to the device
Click on radar device sensor
No updates related to presence/motion

Expected behavior
It is expected to detect presence/motion sensor but nothing happens, on the other hand the luminance is working fine.

App and Homey version

What Homey version are you running? 10.3.0
What version of Homey firmware do you use? 18.19.0
What version of the Tuya Zigbee App are you using? 0.2.25

Screenshots
Added here in the following comment->
(https://community.homey.app/t/app-pro-tuya-zigbee-app/26439/4620?u=roberto2391)
Additional context
My zigbee device is on ceiling mount 2,5 meters height.
Interview made to this zigbee device:
“ids”: {
“modelId”: “TS0601”,
“manufacturerName”: “_TZE204_ijxvkhd0”
},
“endpoints”: {
“ieeeAddress”: “a4:c1:38:30:1b:0d:d2:26”,
“networkAddress”: 57820,
“modelId”: “TS0601”,
“manufacturerName”: “_TZE204_ijxvkhd0”,
“endpointDescriptors”: [
{
“status”: “SUCCESS”,
“nwkAddrOfInterest”: 57820,
“_reserved”: 20,
“endpointId”: 1,
“applicationProfileId”: 260,
“applicationDeviceId”: 81,
“applicationDeviceVersion”: 0,
“_reserved1”: 1,
“inputClusters”: [
4,
5,
61184,
0
],
“outputClusters”: [
25,
10
]
},
{
“status”: “SUCCESS”,
“nwkAddrOfInterest”: 57820,
“_reserved”: 10,
“endpointId”: 242,
“applicationProfileId”: 41440,
“applicationDeviceId”: 97,
“applicationDeviceVersion”: 0,
“_reserved1”: 0,
“inputClusters”: ,
“outputClusters”: [
33
]
}
],
“deviceType”: “router”,
“receiveWhenIdle”: true,
“capabilities”: {
“alternatePANCoordinator”: false,
“deviceType”: true,
“powerSourceMains”: true,
“receiveWhenIdle”: true,
“security”: false,
“allocateAddress”: true
},
“extendedEndpointDescriptors”: {
“1”: {
“clusters”: {
“groups”: {
“attributes”: [
{
“acl”: [
“readable”,
“reportable”
],
“id”: 0,
“name”: “nameSupport”,
“value”: {
“type”: “Buffer”,
“data”: [
0
]
},
“reportingConfiguration”: {
“status”: “NOT_FOUND”,
“direction”: “reported”
}
},
{
“acl”: [
“readable”,
“reportable”
],
“id”: 65533,
“name”: “clusterRevision”,
“value”: 2,
“reportingConfiguration”: {
“status”: “NOT_FOUND”,
“direction”: “reported”
}
}
]
},
“scenes”: {
“attributes”: [
{
“acl”: [
“readable”,
“reportable”
],
“id”: 0,
“reportingConfiguration”: {
“status”: “NOT_FOUND”,
“direction”: “reported”
}
},
{
“acl”: [
“readable”,
“reportable”
],
“id”: 1,
“reportingConfiguration”: {
“status”: “NOT_FOUND”,
“direction”: “reported”
}
},
{
“acl”: [
“readable”,
“reportable”
],
“id”: 2,
“reportingConfiguration”: {
“status”: “NOT_FOUND”,
“direction”: “reported”
}
},
{
“acl”: [
“readable”,
“reportable”
],
“id”: 3,
“reportingConfiguration”: {
“status”: “NOT_FOUND”,
“direction”: “reported”
}
},
{
“acl”: [
“readable”,
“reportable”
],
“id”: 4,
“reportingConfiguration”: {
“status”: “NOT_FOUND”,
“direction”: “reported”
}
},
{
“acl”: [
“readable”,
“reportable”
],
“id”: 65533,
“name”: “clusterRevision”,
“value”: 2,
“reportingConfiguration”: {
“status”: “NOT_FOUND”,
“direction”: “reported”
}
}
]
},
“basic”: {
“attributes”: [
{
“acl”: [
“readable”,
“reportable”
],
“id”: 0,
“name”: “zclVersion”,
“value”: 3
},
{
“acl”: [
“readable”,
“reportable”
],
“id”: 1,
“name”: “appVersion”,
“value”: 74
},
{
“acl”: [
“readable”,
“reportable”
],
“id”: 2,
“name”: “stackVersion”,
“value”: 0
},
{
“acl”: [
“readable”,
“reportable”
],
“id”: 3,
“name”: “hwVersion”,
“value”: 1
},
{
“acl”: [
“readable”,
“reportable”
],
“id”: 4,
“name”: “manufacturerName”,
“value”: “_TZE204_ijxvkhd0”
},
{
“acl”: [
“readable”,
“reportable”
],
“id”: 5,
“name”: “modelId”,
“value”: “TS0601”
},
{
“acl”: [
“readable”,
“reportable”
],
“id”: 6,
“name”: “dateCode”,
“value”: “”
},
{
“acl”: [
“readable”,
“reportable”
],
“id”: 7,
“name”: “powerSource”,
“value”: “mains”
},
{
“acl”: [
“readable”,
“writable”,
“reportable”
],
“id”: 65502
},
{
“acl”: [
“readable”,
“reportable”
],
“id”: 65533,
“name”: “clusterRevision”,
“value”: 2
},
{
“acl”: [
“readable”,
“reportable”
],
“id”: 65534,
“name”: “attributeReportingStatus”,
“value”: “PENDING”
},
{
“acl”: [
“readable”,
“reportable”
],
“id”: 65506
},
{
“acl”: [
“readable”,
“reportable”
],
“id”: 65507
}
]
}
},
“bindings”: {
“ota”: {},
“time”: {
“attributes”: [
{
“acl”: [
“readable”
],
“id”: 65533,
“name”: “clusterRevision”,
“value”: 1
}
]
}
}
},
“242”: {
“clusters”: {},
“bindings”: {}
}
}
}

https://github.com/shaarkys/com.tuya.zigbee/commit/976d3c716ee235a9a93e658136fd55cbb88cc8d5

I don't.

so, please could you share how to fix from my side with your solution now?

Yes, I did already.

so, could you update a new test tuya zigbee app version with the solution provided for my device as radar sensor 2? thanks

nope, I can't (not developer) + as you can see, there are 400 issues to be updated.
The fastest and easiest solution has been already offered to you - if you are not okay with that, then please wait until developer (Johan) will push the updates. In the meantime, you can maybe take a look on the Paypal link for Johan and send him your wishes
Note : I will be not answering on any other non relevant question, thank you.

Bug fixed, thanks!

shaarkys@976d3c7


Allow Core library to managed as dependency

As of now, I need to copy the Core library to /usr/local/core in order to get picked up by other libraries.
Instead, I'd like to have an explicit dependency in manifest.savi about the version of Core (and the Savi compiler version, too).

As of now, I need to copy the Core library to /usr/local/core in order to get picked up by other libraries.

For whatever it's worth (mainly for others reading along) Savi does not require the savi binary or the core library to be installed in any particular place on your system - it can be installed anywhere as long as the relative paths among the pieces of the distribution are maintained relative to one another. So it's only true that you need to put the core library at /usr/local/core if you chose to put the savi binary at /usr/local/bin/savi. I don't recommend this pattern.
Instead I recommend putting the entire distribution of Savi in an isolated folder somewhere, and adding that folder's bin subdirectory to your PATH.

the version of Core (and the Savi compiler version, too).

I think we won't be able to cleanly version the core library version separately from the Savi compiler version because they are fairly entangled (via compiler intrinsics in the internal implementation details of the core library). So I think we need to treat the two as having one version, which represents the version of the language and the core data types available in the language.
I think we should call this the Savi version in the manifest.

Marking this as being part of the 1.0 milestone because we definitely need to answer that question before 1.0 stabilization.


Modified docker-compose.test.yml [Acl-Apd]

This pull request contains the following changes:

Modified docker-compose.test.yml

Can one of the admins verify this patch?

ok to test

Build finished.


DOC: start function docstring with 1-liner, fix typos, add some periods.

Making sure all functions start with a one linear, as per numpydoc standards, and some typos and periods added here and there.

Thanks man!


import and export yolov5 datasets with confidence (optional), update tests and docs

What changes are proposed in this pull request?
YOLOv4 and YOLOv5 import/export with confidence. Issue
How is this patch tested? If it is not, please explain why.
Assert equal detection confidence bounds between base and after export/import.
Updated tests in tests/unittests/import_export_tests.py to handle default include_confidence=False
and non-default include_confidence=True cases in test_yolov4_dataset and test_yolov5_dataset
Release Notes
Is this a user-facing change that should be mentioned in the release notes?

[ ] No. You can skip the rest of this section.
[x] Yes. Give a description of this change to be included in the release
notes for FiftyOne users.

Set include_confidence=False when exporting a dataset in YOLOv4/YOLOv5 formats to include confidence.
Importing datasets in YOLOv4/YOLOv5 formats automatically loads confidence if it's present in a txt file with detections.
What areas of FiftyOne does this PR affect?

[ ] App: FiftyOne application changes
[ ] Build: Build and test infrastructure changes
[x] Core: Core fiftyone Python library changes
[x] Documentation: FiftyOne documentation changes
[ ] Other

any updates on this one?

thanks for merging it!


Disable google analytics

https://github.com/vega/vega-lite-ui/issues/78

Done in polestar and voyager.

See https://github.com/vega/polestar/pull/342


Reshape cannot infer the missing input size for an empty tensor unless all specified

I train on coco dataset, when iter =11410, it appears a problem:
image: COCO_train2014_000000076146.jpg iter: 11410 / 200000, total loss: 3.3490, rpn_loss_cls: 0.7608, rpn_loss_box: 1.0145, loss_cls: 0.7640, loss_box: 0.8098, lr: 0.001000
speed: 0.327s / iter
2017-06-08 22:59:42.143627: W tensorflow/core/framework/op_kernel.cc:1152] Invalid argument: Reshape cannot infer the missing input size for an empty tensor unless all specified input sizes are non-zero
[[Node: gradients/TopKV2_grad/Reshape = Reshape[T=DT_INT32, Tshape=DT_INT32, _device="/job:localhost/replica:0/task:0/gpu:0"](TopKV2/_131, gradients/TopKV2_grad/stack)]]
2017-06-08 22:59:42.143670: W tensorflow/core/framework/op_kernel.cc:1152] Invalid argument: Reshape cannot infer the missing input size for an empty tensor unless all specified input sizes are non-zero
[[Node: gradients/TopKV2_grad/Reshape = Reshape[T=DT_INT32, Tshape=DT_INT32, _device="/job:localhost/replica:0/task:0/gpu:0"](TopKV2/_131, gradients/TopKV2_grad/stack)]]
2017-06-08 22:59:42.143965: W tensorflow/core/framework/op_kernel.cc:1152] Invalid argument: Reshape cannot infer the missing input size for an empty tensor unless all specified input sizes are non-zero
[[Node: gradients/TopKV2_grad/Reshape = Reshape[T=DT_INT32, Tshape=DT_INT32, _device="/job:localhost/replica:0/task:0/gpu:0"](TopKV2/_131, gradients/TopKV2_grad/stack)]]
2017-06-08 22:59:42.144042: W tensorflow/core/framework/op_kernel.cc:1152] Invalid argument: Reshape cannot infer the missing input size for an empty tensor unless all specified input sizes are non-zero
[[Node: gradients/TopKV2_grad/Reshape = Reshape[T=DT_INT32, Tshape=DT_INT32, _device="/job:localhost/replica:0/task:0/gpu:0"](TopKV2/_131, gradients/TopKV2_grad/stack)]]
2017-06-08 22:59:42.145758: W tensorflow/core/framework/op_kernel.cc:1152] Invalid argument: Reshape cannot infer the missing input size for an empty tensor unless all specified input sizes are non-zero
[[Node: gradients/TopKV2_grad/Reshape = Reshape[T=DT_INT32, Tshape=DT_INT32, _device="/job:localhost/replica:0/task:0/gpu:0"](TopKV2/_131, gradients/TopKV2_grad/stack)]]
Traceback (most recent call last):
File "/home/yanchao/TFFRCNN/faster_rcnn/train_net.py", line 132, in
restore=bool(int(args.restore)))
File "/home/yanchao/TFFRCNN/faster_rcnn/../lib/fast_rcnn/train.py", line 400, in train_net
sw.train_model(sess, max_iters, restore=restore)
File "/home/yanchao/TFFRCNN/faster_rcnn/../lib/fast_rcnn/train.py", line 255, in train_model
cls_prob, bbox_pred, rois =  sess.run(fetches=fetch_list, feed_dict=feed_dict)
File "/home/yanchao/anaconda2/lib/python2.7/site-packages/tensorflow/python/client/session.py", line 778, in run
run_metadata_ptr)
File "/home/yanchao/anaconda2/lib/python2.7/site-packages/tensorflow/python/client/session.py", line 982, in _run
feed_dict_string, options, run_metadata)
File "/home/yanchao/anaconda2/lib/python2.7/site-packages/tensorflow/python/client/session.py", line 1032, in _do_run
target_list, options, run_metadata)
File "/home/yanchao/anaconda2/lib/python2.7/site-packages/tensorflow/python/client/session.py", line 1052, in _do_call
raise type(e)(node_def, op, message)
tensorflow.python.framework.errors_impl.InvalidArgumentError: Reshape cannot infer the missing input size for an empty tensor unless all specified input sizes are non-zero
[[Node: gradients/TopKV2_grad/Reshape = Reshape[T=DT_INT32, Tshape=DT_INT32, _device="/job:localhost/replica:0/task:0/gpu:0"](TopKV2/_131, gradients/TopKV2_grad/stack)]]
Caused by op u'gradients/TopKV2_grad/Reshape', defined at:
File "/home/yanchao/TFFRCNN/faster_rcnn/train_net.py", line 132, in
restore=bool(int(args.restore)))
File "/home/yanchao/TFFRCNN/faster_rcnn/../lib/fast_rcnn/train.py", line 400, in train_net
sw.train_model(sess, max_iters, restore=restore)
File "/home/yanchao/TFFRCNN/faster_rcnn/../lib/fast_rcnn/train.py", line 142, in train_model
grads, norm = tf.clip_by_global_norm(tf.gradients(loss, tvars), 10.0)
File "/home/yanchao/anaconda2/lib/python2.7/site-packages/tensorflow/python/ops/gradients_impl.py", line 560, in gradients
grad_scope, op, func_call, lambda: grad_fn(op, *out_grads))
File "/home/yanchao/anaconda2/lib/python2.7/site-packages/tensorflow/python/ops/gradients_impl.py", line 368, in _MaybeCompile
return grad_fn()  # Exit early
File "/home/yanchao/anaconda2/lib/python2.7/site-packages/tensorflow/python/ops/gradients_impl.py", line 560, in
grad_scope, op, func_call, lambda: grad_fn(op, *out_grads))
File "/home/yanchao/anaconda2/lib/python2.7/site-packages/tensorflow/python/ops/nn_grad.py", line 577, in _TopKGrad
ind_2d = array_ops.reshape(op.outputs[1], array_ops.stack([-1, ind_lastdim]))
File "/home/yanchao/anaconda2/lib/python2.7/site-packages/tensorflow/python/ops/gen_array_ops.py", line 2510, in reshape
name=name)
File "/home/yanchao/anaconda2/lib/python2.7/site-packages/tensorflow/python/framework/op_def_library.py", line 768, in apply_op
op_def=op_def)
File "/home/yanchao/anaconda2/lib/python2.7/site-packages/tensorflow/python/framework/ops.py", line 2336, in create_op
original_op=self._default_original_op, op_def=op_def)
File "/home/yanchao/anaconda2/lib/python2.7/site-packages/tensorflow/python/framework/ops.py", line 1228, in init
self._traceback = _extract_stack()
...which was originally created as op u'TopKV2', defined at:
File "/home/yanchao/TFFRCNN/faster_rcnn/train_net.py", line 132, in
restore=bool(int(args.restore)))
[elided 0 identical lines from previous traceback]
File "/home/yanchao/TFFRCNN/faster_rcnn/../lib/fast_rcnn/train.py", line 400, in train_net
sw.train_model(sess, max_iters, restore=restore)
File "/home/yanchao/TFFRCNN/faster_rcnn/../lib/fast_rcnn/train.py", line 112, in train_model
self.net.build_loss(ohem=cfg.TRAIN.OHEM)
File "/home/yanchao/TFFRCNN/faster_rcnn/../lib/networks/network.py", line 643, in build_loss
rpn_cross_entropy_n_neg, _ = tf.nn.top_k(rpn_cross_entropy_n_neg, k=top_k)
File "/home/yanchao/anaconda2/lib/python2.7/site-packages/tensorflow/python/ops/nn_ops.py", line 1998, in top_k
return gen_nn_ops._top_kv2(input, k=k, sorted=sorted, name=name)
File "/home/yanchao/anaconda2/lib/python2.7/site-packages/tensorflow/python/ops/gen_nn_ops.py", line 2502, in _top_kv2
name=name)
File "/home/yanchao/anaconda2/lib/python2.7/site-packages/tensorflow/python/framework/op_def_library.py", line 768, in apply_op
op_def=op_def)
File "/home/yanchao/anaconda2/lib/python2.7/site-packages/tensorflow/python/framework/ops.py", line 2336, in create_op
original_op=self._default_original_op, op_def=op_def)
File "/home/yanchao/anaconda2/lib/python2.7/site-packages/tensorflow/python/framework/ops.py", line 1228, in init
self._traceback = _extract_stack()
InvalidArgumentError (see above for traceback): Reshape cannot infer the missing input size for an empty tensor unless all specified input sizes are non-zero
[[Node: gradients/TopKV2_grad/Reshape = Reshape[T=DT_INT32, Tshape=DT_INT32, _device="/job:localhost/replica:0/task:0/gpu:0"](TopKV2/_131, gradients/TopKV2_grad/stack)]]
Process finished with exit code 1
Does anyone meet the same things? This is really a strange problem.

I found the image (its=443427.jpg) when this interruptted, but when I skip the step(from 11410 to 11420), the net could train again. Very strange phenomenon is that I have found the same image(443427) when iter is 25840, but it can be trained! So why training on coco dataset when iter is about 11410 will be   @@interrupted?

looks like it is not my code? closing.


agent_json with type "options" is not supported

Prerequisites

[X] I checked the documentation and found no answer to my problem
[X] I checked the existing issues and made sure there are no similar bug reports

Category
Bug (unexpected behavior)
Expected Behavior
No response
Observed Behavior
I was working on a react app using the SDK and the app would crash and print and UNKOWN JSON error that I have traced back to ai-engine-sdk-js/src/index.ts line 218. And by checking the network reponse I see it is because our agent sends a agent-json of type "options" which isn't supported by the SDK
looking at network tab and realised this issue

but it also occurs with example
send options but it doesnt take it

To Reproduce
No response
Version
0.1.0
Environment Details (Optional)
No response
Failure Logs (Optional)
No response
Additional Information (Optional)
No response

This is caused by our agent:
from uagents import Agent, Model, Context, Protocol
from ai_engine import UAgentResponse, UAgentResponseType

LearningAgent = Agent()

class LearningRequest(Model):
    subject : str
    answer: str

LearningAgent_Protocol = Protocol('Learning Agent protocol')

@LearningAgent_Protocol.on_message(model=LearningRequest, replies=UAgentResponse)
async def on_youtube_request(ctx: Context, sender: str, msg: LearningRequest):
    ctx.logger.info(f"Received Request from {sender} with subject request")
    ctx.logger.info(msg.subject)

LearningAgent.include(LearningAgent_Protocol)

LearningAgent.run()

The code I used was very similar to the simple.ts example:
import * as readline from "node:readline";

import {
  AiEngine,
  isAgentMessage,
  isAiEngineMessage,
  isConfirmationMessage,
  isStopMessage,
  isTaskSelectionMessage,
} from "@fetchai/ai-engine-sdk";

const apiKey = process.env["AV_API_KEY"] ?? "";
console.log("api key: "+ apiKey);

const snooze = (ms: number) =>
  new Promise((resolve) => setTimeout(resolve, ms));

const main = async () => {
  const rl = readline.promises.createInterface({
    input: process.stdin,
    output: process.stdout,
  });

  const aiEngine = new AiEngine(apiKey);

  const functionGroups = await aiEngine.getFunctionGroups();
  const publicGroup = functionGroups.find((g) => g.name === "My Functions");
  if (publicGroup === undefined) {
    throw new Error('Could not find "Public" function group.');
  }

  const session = await aiEngine.createSession(publicGroup.uuid);
  await session.start(await rl.question("What is your objective: "));

  try {
    let emptyCount = 0;
    let sessionEnded = false;
    while (emptyCount < 12) {
      const messages = await session.getMessages();
      if (messages.length === 0) {
        emptyCount++;
      } else {
        emptyCount = 0;
      }

      for (const message of messages) {
        if (isTaskSelectionMessage(message)) {
          console.log("Please select a task from the list below:");
          console.log("");
          for (const option of message.options) {
            console.log(`${option.key}: ${option.title}`);
          }

          const optionIndex = parseInt(
            await rl.question("\nEnter task number: "),
          );

          // check the index
          if (optionIndex < 0 || optionIndex >= message.options.length) {
            throw new Error("Invalid task number");
          }

          await session.submitTaskSelection(message, [
            message.options[optionIndex]!,
          ]);
        } else if (isAgentMessage(message)) {
          console.log("Agent: ", message.text);

          const response = await rl.question("User (enter to skip): ");
          if (response === "exit") {
            break;
          }

          if (response !== "") {
            await session.submitResponse(message, response);
          }
        } else if (isAiEngineMessage(message)) {
          console.log("Engine:", message.text);
        } else if (isConfirmationMessage(message)) {
          console.log("Confirm:", message.payload);

          const response = await rl.question(
            "\nPress enter to confirm, otherwise explain issue:\n",
          );

          if (response === "") {
            console.log("Sending confirmation...");
            await session.submitConfirmation(message);
          } else {
            await session.rejectConfirmation(message, response);
          }
        } else if (isStopMessage(message)) {
          console.log("\nSession has ended");
          sessionEnded = true;
          break;
        } else {
          console.error("???", message);
        }
      }

      // if the session has concluded then break
      if (sessionEnded) {
        break;
      }

      await snooze(1200);
    }
  } catch (e) {
    console.error("Error", e);
  } finally {
    // clean up the session
    await session.delete();

    // stop the readline interface
    rl.close();
  }
};

main();


TypeError: pad_center() takes 1 positional argument but 2 were given

  File "/content/mlp-singer/inference.py", line 101, in <module>
    main(args)
  File "/usr/local/lib/python3.10/dist-packages/torch/utils/_contextlib.py", line 115, in decorate_context
    return func(*args, **kwargs)
  File "/content/mlp-singer/inference.py", line 25, in main
    preprocessor = Preprocessor(preprocessor_config)
  File "/content/mlp-singer/data/preprocess.py", line 14, in __init__
    self.stft = TacotronSTFT(
  File "/content/mlp-singer/data/dsp/core.py", line 26, in __init__
    self.stft_fn = STFT(filter_length, hop_length, win_length)
  File "/content/mlp-singer/data/dsp/stft.py", line 66, in __init__
    fft_window = pad_center(fft_window, filter_length)
TypeError: pad_center() takes 1 positional argument but 2 were given```

In your code snippet, you can update the line fft_window = pad_center(fft_window, filter_length) to correctly call the pad_center function with the required arguments. For example, you can change it to fft_window = pad_center(fft_window, size=filter_length) to specify the target size. If you want to pad along a specific axis, you can also provide the axis argument.

I hope this helps! Let me know if you have any further questions.```

The error message you are seeing indicates that the mel function from the librosa.filters module is being called with 5 positional arguments, but it only takes keyword arguments. You can update the line mel_basis = librosa_mel_fn(sampling_rate, filter_length, n_mel_channels, mel_fmin, mel_fmax) to correctly call the mel function with the required keyword arguments. For example, you can change it to mel_basis = librosa_mel_fn(sr=sampling_rate, n_fft=filter_length, n_mels=n_mel_channels, fmin=mel_fmin, fmax=mel_fmax) to specify the required arguments using their keyword names.


match html tags

VSCode Version:
OS Version:

It is a problem in big html files, match the tags, I really love VSCode...

Are you trying to find the matching tag or are you saying that it is not auto completing the matching tag? And what version/os?

1.4 I ment to see the matching tag.  Autocomplete is doing fine with the
Tab.
El 22 ago. 2016 6:36 PM, "AnthonyMichaelc"<EMAIL_ADDRESS>escribió:

Are you trying to find the matching tag or are you saying that it is not
auto completing the matching tag? And what version/os?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/Microsoft/vscode/issues/10808#issuecomment-241583600,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AMbl4Un-aK9VFr529wX1RbjUZXV4Vc61ks5qijKUgaJpZM4JqUh3
.

From my experience it is a little tricky at first to see but to test if you put a div or p or any tag in a small space and then put the cursor before the tag and arrow over you will see it will highlight the inside of the start and ending tag. Would be nicer if they had a feature that underlined or bright color highlight but there is a slight highlight color at the moment. I hope that helps you a little.

Thanks. I will check it.
Have a nice day.
El 22 ago. 2016 6:45 PM, "AnthonyMichaelc"<EMAIL_ADDRESS>escribió:

From my experience it is a little tricky at first to see but to test if
you put a div or p or any tag in a small space and then put the cursor
before the tag and arrow over you will see it will highlight the inside of
the start and ending tag. Would be nicer if they had a feature that
underlined or bright color highlight but there is a slight highlight color
at the moment. I hope that helps you a little.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/Microsoft/vscode/issues/10808#issuecomment-241584967,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AMbl4TxXwsl-fiubutOJX8AKlhNkhSzwks5qijR9gaJpZM4JqUh3
.

No problem, give feedback if it does not work.
You to.

@AnthonyMichaelc Thanks for pitching in and helping out.
@FructuosoRobles Please let us know if your issue is solved otherwise open the issue with what you are expecting
Thanks.


Refactoring & Pull Data from Past End of Timerange

This branch performs refactoring on the changes introduced by #60. The most important change is pulling from beyond the end of the timerange as in #62.
@jeeyoungk @achow

LGTM


storage slots missing from stateDiff tracer

Describe the bug
Some of the storage slots that are displayed by eth_createAccessList are not present in the stateDiff trace filter.
trace_callMany input
curl http://<IP_ADDRESS>:8545 \
  -X POST \
  -H "Content-Type: application/json" \
  --data '{
    "id": 1,
    "jsonrpc": "2.0",
    "method": "trace_callMany",
    "params": [
        [
            [
                {
                  "from": "0x435771A144fba8e20734693C50C6a34FB0e5bcEc",
                  "to": "0x7a250d5630B4cF539739dF2C5dAcb4c659F2488D",
                  "gas": "0x3f2f2",
                  "gasPrice": "0x169872c07a",
                  "value": "0x16345785d8a0000",
                  "data": "0xb6f9de95000000000000000000000000000000000000000000000000000017860baba69c0000000000000000000000000000000000000000000000000000000000000080000000000000000000000000435771a144fba8e20734693c50c6a34fb0e5bcec00000000000000000000000000000000000000000000000000000000651598840000000000000000000000000000000000000000000000000000000000000002000000000000000000000000c02aaa39b223fe8d0a0e5c4f27ead9083c756cc200000000000000000000000048a4fb7b60540ea4cea9a90b23be9ae2ae0b661c"
                },
                [
                    "stateDiff"
                ]
            ]
        ],
        "0x1163ea9"
    ]
}' | jq

trace_callMany output
{
  "jsonrpc": "2.0",
  "id": 1,
  "result": [
    {
      "output": "0x",
      "stateDiff": {
        "0x435771a144fba8e20734693c50c6a34fb0e5bcec": {
          "balance": {
            "*": {
              "from": "0x373f0cb05fa0d8f",
              "to": "0x1d9f7d9736b7489"
            }
          },
          "code": "=",
          "nonce": {
            "*": {
              "from": "0x7c",
              "to": "0x7d"
            }
          },
          "storage": {}
        },
        "0x48a4fb7b60540ea4cea9a90b23be9ae2ae0b661c": {
          "balance": "=",
          "code": "=",
          "nonce": "=",
          "storage": {
            "0x0000000000000000000000000000000000000000000000000000000000000000": {
              "+": "0x00000000000000000000000079a6862e4f7c7dd0f0e0dcb84fbfd9439aced870"
            },
            "0x0000000000000000000000000000000000000000000000000000000000000005": {
              "+": "0x0000000000000000000000000000000000000000000000000000000001163e7c"
            },
            "0x0000000000000000000000000000000000000000000000000000000000000008": {
              "+": "0x0000000000000000000000000000000000000000000000000000000000000005"
            },
            "0x000000000000000000000000000000000000000000000000000000000000000a": {
              "+": "0x0000000000000000000000000000000000000000000000000000000000000014"
            },
            "0x000000000000000000000000000000000000000000000000000000000000000d": {
              "*": {
                "from": "0x0000000000000000000000000000000000000000000000000000000000000065",
                "to": "0x0000000000000000000000000000000000000000000000000000000000000066"
              }
            },
            "0x000000000000000000000000000000000000000000000000000000000000000e": {
              "+": "0x000000000000000000000000000000000000000000000000002386f26fc10000"
            },
            "0x000000000000000000000000000000000000000000000000000000000000000f": {
              "+": "0x000000000000000000000000000000000000000000000000002386f26fc10000"
            },
            "0x0000000000000000000000000000000000000000000000000000000000000012": {
              "+": "0x0000000000000000000000007a250d5630b4cf539739df2c5dacb4c659f2488d"
            },
            "0x0000000000000000000000000000000000000000000000000000000000000013": {
              "+": "0x000000000000000000010001772917fc690a42e9d9f6a68a16ffbea477350c5e"
            },
            "0x354e5b427d437c6aeba55ccb312b481b7f0f69b641d71b4136ba5b3ca26477af": {
              "+": "0x0000000000000000000000000000000000000000000000000000000000000000"
            },
            "0x5625085f6c7a220ee8bea389481e7bb3b2756b86aa84a0ef8f1fe7516913527d": {
              "*": {
                "from": "0x0000000000000000000000000000000000000000000000000002f2e1dd25bc51",
                "to": "0x0000000000000000000000000000000000000000000000000002f79645e1aa70"
              }
            },
            "0xd3794d13fe3c995630a46c102c2f4b4274377878738ede3455514c2d54b1a5b9": {
              "*": {
                "from": "0x0000000000000000000000000000000000000000000000000009f447293a5738",
                "to": "0x0000000000000000000000000000000000000000000000000009962efa8bbcc5"
              }
            }
          }
        },
        "0x772917fc690a42e9d9f6a68a16ffbea477350c5e": {
          "balance": "=",
          "code": "=",
          "nonce": "=",
          "storage": {
            "0x0000000000000000000000000000000000000000000000000000000000000006": {
              "+": "0x00000000000000000000000048a4fb7b60540ea4cea9a90b23be9ae2ae0b661c"
            },
            "0x0000000000000000000000000000000000000000000000000000000000000008": {
              "*": {
                "from": "0x651597fb00000000000024166ef782a4639e0000000000000009f447293a5738",
                "to": "0x651598070000000000002579b46fe02e639e0000000000000009962efa8bbcc5"
              }
            },
            "0x0000000000000000000000000000000000000000000000000000000000000009": {
              "*": {
                "from": "0x00000000000000000000000000000007f9a49bd94e45acb6fb98dba5748206f8",
                "to": "0x000000000000000000000000000000082525b991189c478a4fe483570be7a564"
              }
            },
            "0x000000000000000000000000000000000000000000000000000000000000000a": {
              "*": {
                "from": "0x000000000000000000000000000000000000c652db04e5f480aaf023b0ee0f8c",
                "to": "0x000000000000000000000000000000000000c9a238096de133732e1a723bc9e4"
              }
            },
            "0x000000000000000000000000000000000000000000000000000000000000000c": {
              "*": {
                "from": "0x0000000000000000000000000000000000000000000000000000000000000001",
                "to": "0x0000000000000000000000000000000000000000000000000000000000000000"
              }
            }
          }
        },
        "0x7a250d5630b4cf539739df2c5dacb4c659f2488d": {
          "balance": "=",
          "code": "=",
          "nonce": "=",
          "storage": {}
        },
        "0x95222290dd7278aa3ddd389cc1e1d165cc4bafe5": {
          "balance": {
            "*": {
              "from": "0x63c72bdb9815638b",
              "to": "0x63f1a217cc7e1cee"
            }
          },
          "code": "=",
          "nonce": "=",
          "storage": {}
        },
        "0xc02aaa39b223fe8d0a0e5c4f27ead9083c756cc2": {
          "balance": {
            "*": {
              "from": "0x28feff9d2e212c4babea3",
              "to": "0x28feffb36278b2244bea3"
            }
          },
          "code": "=",
          "nonce": "=",
          "storage": {
            "0x5efe3cf2c21ba6ef683844c1a9770ff19813a6adb2d94366fdd4111d916cd4a1": {
              "+": "0x00000000000000000000000000000000000000000000000024166ef782a4639e"
            },
            "0xfb19a963956c9cb662dd3ae48988c4b90766df71ea130109840abe0a1b23dba8": {
              "+": "0x0000000000000000000000000000000000000000000000000000000000000000"
            }
          }
        }
      },
      "trace": [],
      "vmTrace": null
    }
  ]
}

eth_createAccessList input
curl --request POST \
     --url http://<IP_ADDRESS>:8545 \
     --header 'accept: application/json' \
     --header 'content-type: application/json' \
     --data '
{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "eth_createAccessList",
  "params": [
    {
      "from": "0x435771A144fba8e20734693C50C6a34FB0e5bcEc",
      "to": "0x7a250d5630B4cF539739dF2C5dAcb4c659F2488D",
      "gas": "0x3f2f2",
      "gasPrice": "0x169872c07a",
      "value": "0x16345785d8a0000",
      "data": "0xb6f9de95000000000000000000000000000000000000000000000000000017860baba69c0000000000000000000000000000000000000000000000000000000000000080000000000000000000000000435771a144fba8e20734693c50c6a34fb0e5bcec00000000000000000000000000000000000000000000000000000000651598840000000000000000000000000000000000000000000000000000000000000002000000000000000000000000c02aaa39b223fe8d0a0e5c4f27ead9083c756cc200000000000000000000000048a4fb7b60540ea4cea9a90b23be9ae2ae0b661c"
    },
    "0x1163ea9"
  ]
}
' | jq

eth_createAccessList output
{
  "jsonrpc": "2.0",
  "result": {
    "accessList": [
      {
        "address": "0xc02aaa39b223fe8d0a0e5c4f27ead9083c756cc2",
        "storageKeys": [
          "0x5efe3cf2c21ba6ef683844c1a9770ff19813a6adb2d94366fdd4111d916cd4a1",
          "0xfb19a963956c9cb662dd3ae48988c4b90766df71ea130109840abe0a1b23dba8"
        ]
      },
      {
        "address": "0x772917fc690a42e9d9f6a68a16ffbea477350c5e",
        "storageKeys": [
          "0x0000000000000000000000000000000000000000000000000000000000000006",
          "0x0000000000000000000000000000000000000000000000000000000000000007", <- missing from statediff tracer
          "0x0000000000000000000000000000000000000000000000000000000000000008",
          "0x0000000000000000000000000000000000000000000000000000000000000009",
          "0x000000000000000000000000000000000000000000000000000000000000000a",
          "0x000000000000000000000000000000000000000000000000000000000000000c"
        ]
      },
      {
        "address": "0x48a4fb7b60540ea4cea9a90b23be9ae2ae0b661c",
        "storageKeys": [
          "0x0000000000000000000000000000000000000000000000000000000000000000",
          "0x0000000000000000000000000000000000000000000000000000000000000005",
          "0x0000000000000000000000000000000000000000000000000000000000000008",
          "0x000000000000000000000000000000000000000000000000000000000000000a",
          "0x000000000000000000000000000000000000000000000000000000000000000d",
          "0x000000000000000000000000000000000000000000000000000000000000000e",
          "0x000000000000000000000000000000000000000000000000000000000000000f",
          "0x0000000000000000000000000000000000000000000000000000000000000012",
          "0x0000000000000000000000000000000000000000000000000000000000000013",
          "0x354e5b427d437c6aeba55ccb312b481b7f0f69b641d71b4136ba5b3ca26477af",
          "0x5625085f6c7a220ee8bea389481e7bb3b2756b86aa84a0ef8f1fe7516913527d",
          "0x641d491e097d16553297a31fe0fb3106bdc026b56b88ccabd1020a24348c6d7e", <- missing from statediff tracer
          "0xd3794d13fe3c995630a46c102c2f4b4274377878738ede3455514c2d54b1a5b9"
        ]
      }
    ],
    "gasUsed": "0x2c148"
  },
  "id": 1
}

You can see that slots 0x0000000000000000000000000000000000000000000000000000000000000007 and 0x641d491e097d16553297a31fe0fb3106bdc026b56b88ccabd1020a24348c6d7e are missing from the trace_callMany output.
It can be related to the bug mentioned in issue #4731.
The issue also applies to debug_traceCallMany, not just trace_callMany.
Platform(s)
Linux (x86)
What version/commit are you on?
reth Version: 0.1.0-alpha.10
Commit SHA: 8e9937bb
Build Timestamp: 2023-09-28T07:30:55.921950228Z
Build Features: default,jemalloc
Build Profile: maxperf

What database version are you on?
Current database version: 1
Local database version: 1

If you've built Reth from source, provide the full command you used
LD_PRELOAD=/usr/local/lib/libjemalloc.so RUSTFLAGS="-C target-cpu=native" cargo build --profile maxperf --features jemalloc

Code of Conduct

[X] I agree to follow the Code of Conduct

If those slots' value are unchanged post transaction, they are not included in stateDiff tracer (For ex, a storage for re-entrance protection)

@azertyuiopvnx is correct, those two slots are missing because that is the intended behavior of the method - it only includes slots that were modified in some capacity, whereas access lists are supposed to include storage keys that are either read or written to.


write tests for tools scripts folder

Reason/Context
Covering unit tests for the scripts folder , the files that are involved here in the tools folder , I have mocked the api requests and have added mocked Response
Description
Please try answering few of those questions

Introduced testing with cypress
No this is not a breaking change

still relevant

@sambhavgupta0705
Isn't it the part of GSOC?

Closing this issue as it has been now included in GSOC 2024 idea
#https://github.com/asyncapi/website/issues/2626


Add Scheduled Jobs to Check Certificates Daily

To check certificates daily scheduled jobs will added in the next releases

With this commit all certificates will be checked everyday at 00:05 UTC


Misuses of cryptographic APIs

Hi
The following lines have cryptographic API misuses.  File name => dubbo-common/src/main/java/org/apache/dubbo/common/io/Bytes.java: Line number => 875: API name => MessageDigest:Unexpected call to method <java.security.MessageDigest: byte[] digest()> on object of type java.security.MessageDigest. Expect a call to one of the following methods <java.security.MessageDigest: void update(byte[])>,<java.security.MessageDigest: void update(byte[],int,int)>,<java.security.MessageDigest: byte[] digest(byte[])>,<java.security.MessageDigest: void update(java.nio.ByteBuffer)>,<java.security.MessageDigest: void update(byte)> File name => dubbo-common/src/main/java/org/apache/dubbo/common/io/Bytes.java: Line number => 797: API name => MessageDigest: File name => dubbo-common/src/main/java/org/apache/dubbo/common/io/Bytes.java: Line number => 868: API name => MessageDigest: File name => dubbo-common/src/main/java/org/apache/dubbo/common/io/Bytes.java: Line number => 797: API name => MessageDigest:

The code is not readable, Can you format this code ? Please tell us how to produce this issue also.

Hi,
Thanks for your attention.
I reported the cryptographic misuses due to my recent research on how developers employ Java Cryptography Architecture (JCA) APIs in Java applications. I utilized some static analysis tools intended for checking cryptographic practices. The aforementioned misuses in those files were obtained from the results of the tools. The severity of the bug is relative. For instance, Even though MD5 is listed on Java documentation, MD5 is not recommended to use in any language anymore as it is considered insecure. An attacker can try billions of candidate passwords per second on a single GPU. Nevertheless, depending on the scenario the same hash algorithm may not be a problem for file integrity purpose.
There are several instances of cryptographic misuses which could lead to a security vulnerability:
*Do not use ECB mode for encryption.
*Do not use a non-random IV for CBC encryption
*Do not use constant encryption keys.
*Do not use constant salts for PBE.
*Do not use fewer than 1,000 iterations for PBE.
*Do not use static seeds to seed SecureRandom(·)
You can try using either CryptoLint or CogniCrypt to check your code from a cryptographic point of view


[Improvement Suggestion] Device Handling - Reduce CPU-GPU Overhead

Hi!
I noticed that in several places of the code, e.g. in the conditional_mnist.ipynb tutorial, there's a slight CPU-GPU overhead. For example, the line
torch.randn(100, 1, 28, 28).to(device)

first creates the tensor on the CPU and then copies it onto the GPU (in case device is cuda:0).
It is possible to directly create the tensor on the specified device via
torch.randn(100, 1, 28, 28, device=device)

which is more memory-efficient, since there's no CPU-GPU overhead.

Hello,
You are right. It would be indeed more efficient to create tensors this way. I do not mind the current implementation as the purpose of tutorials is to show how we can train flow matching methods. I will check for cifar10 training but that will have to wait a bit.

train_cifar10.py is indirectly affected by this, since utils_cifar.py has some CPU-GPU overhead, e.g. in L37 in the generate_samples() function. Some other Python scripts are affected by this as well.
I am actually currently working on fixing this, I can open a draft PR once I am finished.

That's great, yep a simple improvement. I was never too worried about this, as I was pretty sure that it didn't matter with most of the time in the Unet. Would be very curious if you notice a speedup! Regardless slightly better and welcome the PR.

I performed some tests by running train_cifar10.py with the same flags specified in the README (except the number of training steps and the number of steps at which samples are generated, which I reduced to 1000 and 500 respectively), I did not notice a speedup (some minor fluctuations only). What surprises me is that the memory consumption, which I logged via torch.cuda.max_memory_allocated(), remained the same :thinking:
Will open a PR shortly.


ToC AST parsing

Description
Refactors approach to parsing table of contents (ToC) headings.

Removed excessive reliance on RegEx pattern matching
Introduces remarkInferToc custom rehype plugin
Within plugin, toc.ts methods are used to remap the list of items into the needed format
Uses a callback function to produce a side-effect during getStaticProps in [...slug].tsx. This side-effect contains the table of contents items which are then passed as tocItems for our table of content components

Hitting issues when syntax trees skip heading levels, ie /staking/solo we jump from an h2 (##) to h4s (####)... this produced an undefined set of items for the h2 looking for h3s to nest which don't exist. Investigating.

This also updates many markdown files that were not following appropriate syntax tree format...
The serialize function being utilized will break if the syntax tree skips heading levels, ie. All h2's should be proceeded by an h2 or h3, but should not jumnp to an h4. This leaves an undefined value in the tree which throws an error inside serialize
I have gone through and updated all instances where this rule was broken and causing build errors. Should be good to go now.


Remove null-check to more-closely mirror original functionality

We encountered a minor incompatibility when switching from the existing UserStore to the MultitenantUserStore.  In the default UserStore, a search for a blank name or email would return a null.  In the MultitenanctUserStore it throws an exception.  I've modified the MultiTenantUserStore to mirror the functionality from the default.

@JakeStevenson Thanks for your contribution :+1:

@JakeStevenson this is now been published to NuGet, under Release v1.2.1.


[NTR] Overgrowth syndrome and/or cerebral malformations due to abnormalities in MTOR pathway genes

Preferred term label:
Overgrowth syndrome and/or cerebral malformations due to abnormalities in MTOR pathway genes
Synonyms
Definition (free text, please give PubMed ID, if applicable, in format PMID:#######)
The disease caused by mosaic gain-of-function (GoF) several genes in the MTOR pathway (MTOR, PIK3CA, PIK3R2 and AKT3) are functionally the same despite significant phenotypic variability. These GoF variants result in overgrowth due to an over-activation of key genes in this pathway (PMID: 27860216). The phenotypic variability is generally attributed to the mosaic fraction and affected tissue types. For example, macrocephaly is noted if the variant is identified in the brain, but non symmetric overgrowth of that limb is noted when the variant is only present in the affected limb. The pathologies of the affected tissue often reveal similar characteristics such as cellular overgrowth. However, this is not always the case especially with focal cortical dysplasia. At times the characteristics pathologies are not present in the tissue but sampling biases are an issue. FCD resections often involve a very small area and so a very small amount of tissue is available for pathology and it is not guaranteed that lesional tissue is sent. Therefore, having a single disease term which can encompass the phenotypic variability yet provide a unifying molecular diagnosis name makes sense given the common functional mechanism. PMID: 22729224, PMID: 31441589, PMID: 22729223, PMID: 30349109
Parent term (use OLS, or your favorite ontology browser)
Disease or Disorder
Congenital abnormality
Developmental defect during embryogenesis
overgrowth/obesity syndrome
AND
Disease or Disorder
Congenital abnormality
Developmental defect during embryogenesis
Central Nervous system malformation
Children terms (if applicable) Should any existing terms that should be moved underneath this new proposed term?
megalencephaly-polymicrogyria-postaxial polydactyly-hydrocephalus syndrome MONDO:0019375
megalencephaly-capillary malformation-polymicrogyria syndrome MONDO:0011240
macrocephaly-intellectual disability-neurodevelopmental disorder-small thorax syndrome MONDO:0014716
isolated focal cortical dysplasia MONDO:0019009
hemimegalencephaly MONDO:0020492
Your nano-attribution (ORCID)
If you don't have an ORCID, you can sign up for one here
Brain Malformation Curation Expert Panel

Thanks @abbe-Lai I'll work on this asap

Thanks @abbe-Lai I'll work on this asap

@abbe-Lai is CCND2 included in the MTOR pathway? This disease ('megalencephaly-polymicrogyria-polydactyly-hydrocephalus syndrome 3') would be a child of this proposed new term.
Also TSC1 and TSC2, these genes would be classified under this proposed new term (see https://omim.org/entry/607341).
Thank you for checking!

@abbe-Lai is CCND2 included in the MTOR pathway? This disease ('megalencephaly-polymicrogyria-polydactyly-hydrocephalus syndrome 3') would be a child of this proposed new term.
Also TSC1 and TSC2, these genes would be classified under this proposed new term (see https://omim.org/entry/607341).
Thank you for checking!

Hello,
Hello CCND2 most definitely would be appropriate for this term. MPPH3 would be the child term as well. However, for TSC1 and TSC2 this would likely be just one of the branches for these genes since they have other risks like cancer associated with TS.
We have not curated these genes yet though so before we make a finalized decision we will plan to curate these genes first? Would that be okay?
Best,
Abbe Lai, MS, CGC
Licensed Genetic Counselor
Coordinator, Brain Development and Genetics Clinic
Research Coordinator, Walsh Laboratory
Abbe.lai<EMAIL_ADDRESS>617-919-4371 | fax<PHONE_NUMBER> www.walshlab.orghttp://www.walshlab.org/
From: Nicole Vasilevsky<EMAIL_ADDRESS>Reply-To: monarch-initiative/mondo<EMAIL_ADDRESS>Date: Wednesday, January 27, 2021 at 8:26 PM
To: monarch-initiative/mondo<EMAIL_ADDRESS>Cc: "Lai, Abbe"<EMAIL_ADDRESS>Mention<EMAIL_ADDRESS>Subject: Re: [monarch-initiative/mondo] [NTR] (#2547) [EXTERNAL]

External Email - Caution *

@abbe-Laihttps://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_abbe-2DLai&d=DwMCaQ&c=qS4goWBT7poplM69zy_3xhKwEW14JZMSdioCoppxeFU&r=KR5yAFgzBYcGok2X41Irv5_RYq6gTQUTB2ejIsIeaF4&m=ANf9Br4UFHdGfpfArJPGttBLRv13f1vh8EHvKO_CYwQ&s=nBEZQBZJUdwoRNcY4W0hX-zcH03uXX-heMUUYE_ZNhU&e= is CCND2 included in the MTOR pathway? This disease ('megalencephaly-polymicrogyria-polydactyly-hydrocephalus syndrome 3') would be a child of this proposed new term.
Also TSC1 and TSC2, these genes would be classified under this proposed new term (see https://omim.org/entry/607341https://urldefense.proofpoint.com/v2/url?u=https-3A__omim.org_entry_607341&d=DwMCaQ&c=qS4goWBT7poplM69zy_3xhKwEW14JZMSdioCoppxeFU&r=KR5yAFgzBYcGok2X41Irv5_RYq6gTQUTB2ejIsIeaF4&m=ANf9Br4UFHdGfpfArJPGttBLRv13f1vh8EHvKO_CYwQ&s=hi4NzWoSTXUI167OiQ9wHm6RxD8kIaQ3tbDNzr4tc8A&e=).
Thank you for checking!
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_monarch-2Dinitiative_mondo_issues_2547-23issuecomment-2D768693342&d=DwMCaQ&c=qS4goWBT7poplM69zy_3xhKwEW14JZMSdioCoppxeFU&r=KR5yAFgzBYcGok2X41Irv5_RYq6gTQUTB2ejIsIeaF4&m=ANf9Br4UFHdGfpfArJPGttBLRv13f1vh8EHvKO_CYwQ&s=YQY7CrgvUWGUp1qHK5--_3mjkyLYHcScIOkAuf04Ky0&e=, or unsubscribehttps://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_notifications_unsubscribe-2Dauth_AO5W5QBNGFJDZ2GZMBLOGP3S4C4L3ANCNFSM4WSGLN2Q&d=DwMCaQ&c=qS4goWBT7poplM69zy_3xhKwEW14JZMSdioCoppxeFU&r=KR5yAFgzBYcGok2X41Irv5_RYq6gTQUTB2ejIsIeaF4&m=ANf9Br4UFHdGfpfArJPGttBLRv13f1vh8EHvKO_CYwQ&s=RDjx8bSQkT83ua0pA98OQsjEny5tRMSYHeoQk0SfGK4&e=.

Hi @abbe-Lai - of course, take all the time you need. Please let me know when you are ready to proceed.

Hello Nicole,
We discussed this at our meeting today.
This disease term does apply to CCND2.
For TSC1 and TSC2 we felt that one of the branches for the tree could be this term. Given there are known cortical malformations in some of these patients and hemimegalencephaly has been seen for these cases in the mosaic state it makes sense.
best,
Abbe Lai, MS, CGC
Licensed Genetic Counselor
Coordinator, Brain Development and Genetics Clinic
Research Coordinator, Walsh Laboratory
Abbe.lai<EMAIL_ADDRESS>617-919-4371 | fax<PHONE_NUMBER> www.walshlab.orghttp://www.walshlab.org/
From: Nicole Vasilevsky<EMAIL_ADDRESS>Reply-To: monarch-initiative/mondo<EMAIL_ADDRESS>Date: Wednesday, February 10, 2021 at 7:02 PM
To: monarch-initiative/mondo<EMAIL_ADDRESS>Cc: "Lai, Abbe"<EMAIL_ADDRESS>Mention<EMAIL_ADDRESS>Subject: Re: [monarch-initiative/mondo] [NTR] (#2547) [EXTERNAL]

External Email - Caution *

Hi @abbe-Laihttps://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_abbe-2DLai&d=DwMCaQ&c=qS4goWBT7poplM69zy_3xhKwEW14JZMSdioCoppxeFU&r=KR5yAFgzBYcGok2X41Irv5_RYq6gTQUTB2ejIsIeaF4&m=oAgxas7LnBzTZySVxV-K8zcVe3yFEUK3hrb0oSxdxxk&s=mjir7tdsNQisoqiE1_MSw1NKG3GtR0e8pc_SxR2XqOE&e= - of course, take all the time you need. Please let me know when you are ready to proceed.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_monarch-2Dinitiative_mondo_issues_2547-23issuecomment-2D777122135&d=DwMCaQ&c=qS4goWBT7poplM69zy_3xhKwEW14JZMSdioCoppxeFU&r=KR5yAFgzBYcGok2X41Irv5_RYq6gTQUTB2ejIsIeaF4&m=oAgxas7LnBzTZySVxV-K8zcVe3yFEUK3hrb0oSxdxxk&s=-qXdiXYw-MA6bTmZ7oPaKtwx0cHZtFMAS6Bc4eN6EsM&e=, or unsubscribehttps://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_notifications_unsubscribe-2Dauth_AO5W5QEADO2KDDQRKCUXBRLS6MM5BANCNFSM4WSGLN2Q&d=DwMCaQ&c=qS4goWBT7poplM69zy_3xhKwEW14JZMSdioCoppxeFU&r=KR5yAFgzBYcGok2X41Irv5_RYq6gTQUTB2ejIsIeaF4&m=oAgxas7LnBzTZySVxV-K8zcVe3yFEUK3hrb0oSxdxxk&s=bnD3hgBwxRwE_LHDFFR4UU4E6C94U7oNnX1dlyQpVCs&e=.

thanks! I'll work on this asap

@abbe-Lai I'm not totally sure if I follow. The hierarchy you proposed is displayed below

'isolated focal cortical dysplasia type II' is equivalent to OMIM:607341, which includes mutations in MTOR and TSC1 and TSC2.
Is this okay?

@abbe-Lai I'm happy to have a call if that is easier!

Hello Nicole,
My apologies I completely missed this email. We do want isolated FCD do be under this term as well. We would not want to remove the association from MTOR TSC1 and TSC2 though. Is it okay to have this as a child term but still have it associated with those genes?
Best,
Abbe Lai
From: Nicole Vasilevsky @.>
Reply-To: monarch-initiative/mondo @.>
Date: Tuesday, February 23, 2021 at 11:59 PM
To: monarch-initiative/mondo @.>
Cc: "Lai, Abbe" @.>, Mention @.***>
Subject: Re: [monarch-initiative/mondo] [NTR] Overgrowth syndrome and/or cerebral malformations due to abnormalities in MTOR pathway genes (#2547) [EXTERNAL]

External Email - Caution *

@abbe-Laihttps://urldefense.com/v3/__https:/github.com/abbe-Lai__;!!NZvER7FxgEiBAiR_!4EQ5cv6ktjwZQtS3F-lyzYyjWSUoiq6gFKyez2YxBYmUpab1frLVnqyYKT1aWUCBbnniic9unw$ I'm happy to have a call if that is easier!
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://urldefense.com/v3/__https:/github.com/monarch-initiative/mondo/issues/2547*issuecomment-784762580__;Iw!!NZvER7FxgEiBAiR_!4EQ5cv6ktjwZQtS3F-lyzYyjWSUoiq6gFKyez2YxBYmUpab1frLVnqyYKT1aWUCBbnl2ImLXPQ$, or unsubscribehttps://urldefense.com/v3/__https:/github.com/notifications/unsubscribe-auth/AO5W5QBO5HL3BFI6TV2TQLTTASBRPANCNFSM4WSGLN2Q__;!!NZvER7FxgEiBAiR_!4EQ5cv6ktjwZQtS3F-lyzYyjWSUoiq6gFKyez2YxBYmUpab1frLVnqyYKT1aWUCBbnnD6zXpoA$.

Thankss @abbe-Lai. I haven't had a chance to look at this closely yet, but I will do asap. :)

Hello Nichole,
I just wanted to follow up on this chain and see if there has been any updates on this?
Was there something you are missing from me?
Best,
Abbe Lai
From: Nicole Vasilevsky @.>
Reply-To: monarch-initiative/mondo @.>
Date: Friday, March 26, 2021 at 8:40 PM
To: monarch-initiative/mondo @.>
Cc: "Lai, Abbe" @.>, Mention @.***>
Subject: Re: [monarch-initiative/mondo] [NTR] Overgrowth syndrome and/or cerebral malformations due to abnormalities in MTOR pathway genes (#2547) [EXTERNAL]

External Email - Caution *

Thankss @abbe-Laihttps://urldefense.com/v3/__https:/github.com/abbe-Lai__;!!NZvER7FxgEiBAiR_!6UGiNLKMY4MPqvSP3RVJBSzQFhUMY7rL3JPFamIwLkemv4uLXp0upROiYGkLHMwmXvtQI9KsUQ$. I haven't had a chance to look at this closely yet, but I will do asap. :)
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://urldefense.com/v3/__https:/github.com/monarch-initiative/mondo/issues/2547*issuecomment-808605618__;Iw!!NZvER7FxgEiBAiR_!6UGiNLKMY4MPqvSP3RVJBSzQFhUMY7rL3JPFamIwLkemv4uLXp0upROiYGkLHMwmXvvlztbbaQ$, or unsubscribehttps://urldefense.com/v3/__https:/github.com/notifications/unsubscribe-auth/AO5W5QBJMCUYEV5TBTWQTZ3TFUSQRANCNFSM4WSGLN2Q__;!!NZvER7FxgEiBAiR_!6UGiNLKMY4MPqvSP3RVJBSzQFhUMY7rL3JPFamIwLkemv4uLXp0upROiYGkLHMwmXvvMt7RjXg$.

Hi @abbe-Lai My apologies for the delay. I haven't had a chance to look at this yet but I will move it to the top of my priority list and try to get this in for the next release.
I don't think I'm waiting on you, I need to review this ticket again and will follow up with any questions, should they arise.
Thanks so much for your patience! :)

@abbe-Lai - I just looked at this. If I am understanding correctly, this new term and hierarchy are correct, yes?

Let me know if any other changes are needed, if not, I'll merge in these changes and they will be available in the next release at the end of the month/begnning of next month.

Hello,
That hierarchy looks good. What is the term that this one is under though? I do not see that on the image, is it congenital malformations?
Best,
Abbe Lai
From: Nicole Vasilevsky @.>
Reply-To: monarch-initiative/mondo @.>
Date: Tuesday, May 18, 2021 at 7:25 PM
To: monarch-initiative/mondo @.>
Cc: "Lai, Abbe" @.>, Mention @.***>
Subject: Re: [monarch-initiative/mondo] [NTR] Overgrowth syndrome and/or cerebral malformations due to abnormalities in MTOR pathway genes (#2547) [EXTERNAL]

External Email - Caution *

@abbe-Laihttps://urldefense.com/v3/__https:/github.com/abbe-Lai__;!!NZvER7FxgEiBAiR_!_PyqqvCZ1Z2pRJAk0kg2Vf2dwy-sMXZ-BKTk68QsSQN1AEbJCyWdMPbipACn3-JyK2uaJqLRJQ$ - I just looked at this. If I am understanding correctly, this new term and hierarchy are correct, yes?
[Image removed by sender. image]https://urldefense.com/v3/__https:/user-images.githubusercontent.com/6722114/118735530-7b64b480-b7f5-11eb-9994-5da33e82e13f.png__;!!NZvER7FxgEiBAiR_!_PyqqvCZ1Z2pRJAk0kg2Vf2dwy-sMXZ-BKTk68QsSQN1AEbJCyWdMPbipACn3-JyK2ueVXxFRQ$
Let me know if any other changes are needed, if not, I'll merge in these changes and they will be available in the next release at the end of the month/begnning of next month.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://urldefense.com/v3/__https:/github.com/monarch-initiative/mondo/issues/2547*issuecomment-843631444__;Iw!!NZvER7FxgEiBAiR_!_PyqqvCZ1Z2pRJAk0kg2Vf2dwy-sMXZ-BKTk68QsSQN1AEbJCyWdMPbipACn3-JyK2uKKPY_QA$, or unsubscribehttps://urldefense.com/v3/__https:/github.com/notifications/unsubscribe-auth/AO5W5QANR557TCAPTJRBCSLTOLZMZANCNFSM4WSGLN2Q__;!!NZvER7FxgEiBAiR_!_PyqqvCZ1Z2pRJAk0kg2Vf2dwy-sMXZ-BKTk68QsSQN1AEbJCyWdMPbipACn3-JyK2sQZ27ldQ$.

Hi @abbe-Lai - this term has 4 parents, per your request above:

I'll go ahead and merge this in, but I can still make additional changes if needed before the release. Thank you so much for all your input and patience. :)

Hello,
That is perfect! Thank you so much.
Best,
Abbe Lai
On May 19, 2021, at 10:58, Nicole Vasilevsky @.***> wrote:

External Email - Caution *

Closed #2547https://urldefense.com/v3/__https://github.com/monarch-initiative/mondo/issues/2547__;!!NZvER7FxgEiBAiR_!_DP_RcBndqCR0_Tl_n6O_p3CeDumPobo0lGUxsjG9WQ_VLLAqLIHmKhzzCl8ALeJ9QDAVPpdwQ$ via #2712https://urldefense.com/v3/__https://github.com/monarch-initiative/mondo/pull/2712__;!!NZvER7FxgEiBAiR_!_DP_RcBndqCR0_Tl_n6O_p3CeDumPobo0lGUxsjG9WQ_VLLAqLIHmKhzzCl8ALeJ9QBv5wDzQg$.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://urldefense.com/v3/__https://github.com/monarch-initiative/mondo/issues/2547*event-4767366339__;Iw!!NZvER7FxgEiBAiR_!_DP_RcBndqCR0_Tl_n6O_p3CeDumPobo0lGUxsjG9WQ_VLLAqLIHmKhzzCl8ALeJ9QCRAWBwyA$, or unsubscribehttps://urldefense.com/v3/__https://github.com/notifications/unsubscribe-auth/AO5W5QFIKE6CB2F3HYUN5BLTOPGZRANCNFSM4WSGLN2Q__;!!NZvER7FxgEiBAiR_!_DP_RcBndqCR0_Tl_n6O_p3CeDumPobo0lGUxsjG9WQ_VLLAqLIHmKhzzCl8ALeJ9QBdl6xp0g$.

Hello Nichole,
I just wanted to check in and see if the Mondo term has been made for these genes yet?
Best,
Abbe Lai
From: Nicole Vasilevsky @.>
Reply-To: monarch-initiative/mondo @.>
Date: Wednesday, May 19, 2021 at 10:58 AM
To: monarch-initiative/mondo @.>
Cc: "Lai, Abbe" @.>, Mention @.***>
Subject: Re: [monarch-initiative/mondo] [NTR] Overgrowth syndrome and/or cerebral malformations due to abnormalities in MTOR pathway genes (#2547) [EXTERNAL]

External Email - Caution *

Closed #2547https://urldefense.com/v3/__https:/github.com/monarch-initiative/mondo/issues/2547__;!!NZvER7FxgEiBAiR_!_DP_RcBndqCR0_Tl_n6O_p3CeDumPobo0lGUxsjG9WQ_VLLAqLIHmKhzzCl8ALeJ9QDAVPpdwQ$ via #2712https://urldefense.com/v3/__https:/github.com/monarch-initiative/mondo/pull/2712__;!!NZvER7FxgEiBAiR_!_DP_RcBndqCR0_Tl_n6O_p3CeDumPobo0lGUxsjG9WQ_VLLAqLIHmKhzzCl8ALeJ9QBv5wDzQg$.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://urldefense.com/v3/__https:/github.com/monarch-initiative/mondo/issues/2547*event-4767366339__;Iw!!NZvER7FxgEiBAiR_!_DP_RcBndqCR0_Tl_n6O_p3CeDumPobo0lGUxsjG9WQ_VLLAqLIHmKhzzCl8ALeJ9QCRAWBwyA$, or unsubscribehttps://urldefense.com/v3/__https:/github.com/notifications/unsubscribe-auth/AO5W5QFIKE6CB2F3HYUN5BLTOPGZRANCNFSM4WSGLN2Q__;!!NZvER7FxgEiBAiR_!_DP_RcBndqCR0_Tl_n6O_p3CeDumPobo0lGUxsjG9WQ_VLLAqLIHmKhzzCl8ALeJ9QBdl6xp0g$.

Hi @abbe-Lai is this the term you are inquiring about:
https://www.ebi.ac.uk/ols/ontologies/mondo/terms?iri=http%3A%2F%2Fpurl.obolibrary.org%2Fobo%2FMONDO_0100283
Or was there something else needed?
Thanks!

That was the term!
Thank you so much. I was not able to find it.
Best,
Abbe lai
From: Nicole Vasilevsky @.>
Reply-To: monarch-initiative/mondo @.>
Date: Wednesday, June 16, 2021 at 12:04 AM
To: monarch-initiative/mondo @.>
Cc: "Lai, Abbe" @.>, Mention @.***>
Subject: Re: [monarch-initiative/mondo] [NTR] Overgrowth syndrome and/or cerebral malformations due to abnormalities in MTOR pathway genes (#2547) [EXTERNAL]

External Email - Caution *

Hi @abbe-Laihttps://urldefense.com/v3/__https:/github.com/abbe-Lai__;!!NZvER7FxgEiBAiR_!4LtoUr5Ps-EtK50U9jGViBKEg8xo3gMcneOFdKvcBMPdX8Ah1dI1K_cV7b2avq7mOwowpZYyZw$ is this the term you are inquiring about:
https://www.ebi.ac.uk/ols/ontologies/mondo/terms?iri=http%3A%2F%2Fpurl.obolibrary.org%2Fobo%2FMONDO_0100283https://urldefense.com/v3/__https:/www.ebi.ac.uk/ols/ontologies/mondo/terms?iri=http*3A*2F*2Fpurl.obolibrary.org*2Fobo*2FMONDO_0100283__;JSUlJSU!!NZvER7FxgEiBAiR_!4LtoUr5Ps-EtK50U9jGViBKEg8xo3gMcneOFdKvcBMPdX8Ah1dI1K_cV7b2avq7mOwqI8kW2sA$
Or was there something else needed?
Thanks!
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://urldefense.com/v3/__https:/github.com/monarch-initiative/mondo/issues/2547*issuecomment-862020867__;Iw!!NZvER7FxgEiBAiR_!4LtoUr5Ps-EtK50U9jGViBKEg8xo3gMcneOFdKvcBMPdX8Ah1dI1K_cV7b2avq7mOwqtAwys3A$, or unsubscribehttps://urldefense.com/v3/__https:/github.com/notifications/unsubscribe-auth/AO5W5QB4WEKOCJTI6FYBUZ3TTAPGNANCNFSM4WSGLN2Q__;!!NZvER7FxgEiBAiR_!4LtoUr5Ps-EtK50U9jGViBKEg8xo3gMcneOFdKvcBMPdX8Ah1dI1K_cV7b2avq7mOwqshnS2Ow$.

Great!


Update the rdkit implementation for getting the fingerprints

AllChem.GetMorganFingerprint is deprecated in the most recent version of rdkit and returns a warning that is painful to the eyes, so updated the newer implementation

Hi, thanks for fixing it! It was annoying me too, but I just used a quick workaround by turning off the logs, haha.
Please bump the version to 1.1 in the pyproject.toml at line 7, and add a lower bound for the RDKit version in the dependencies (something like rdkit>=20xx.xx.xx). It should be the version when the generators were introduced. It looks like it's 2022.09.01 (https://greglandrum.github.io/rdkit-blog/posts/2023-01-18-fingerprint-generator-tutorial.html), but please double-check it.

Checked and yes, it is 2022.09.01, fixed both of them

Thanks! I'll update the pip package


Malformed Configuration Options

It should be possible to report a syntax error of some kind for a malformed input file.  For example, when a dependency version does not confirm (e.g. 3.x.0).  This requires some kind of validator as part of the configuration schema.

Approach:

Add Configuration.REGEX_STRING() which accepts a regex.