Happa RO - Create a blog and publish

Happa RO is now available as a new feature, we will provide a blog for users so that they can start using the feature.
We will mention dex and rbac-bootstrap to show a complete implementation of SSO.

Hii @morotki ,
We are preparing for a blog and would like to have a nice Generic Image in the header, in line with GiantSwarm look and feel.
The user story:
As a readonly user I can login in with Google, GitHub, Azure AD and can access only a few resources (one cluster for example)
Those accessible are colorful and the rest are not grayed
A representation like:
https://www.lonimbus.com/assets/images/arch1.png
or
https://miro.medium.com/max/700/0*z7U342X85WxY1gFf.
Should be fine. But should should the user accessing only one cluster/box and not all.
Let me know if this request is feasible.
Thanks.

Template to follow for the blog post: https://docs.google.com/document/d/1h2tN4etf67tDTuqybikG3pPHEzmGswR1rfo0UR-TBBk/edit

Writing the article draft here: https://docs.google.com/document/d/1snr8mTi8Gre4fVN-8ahhi1K8ABSbwQ4R6doBKYyTeG4/edit#

@PrashantR31 @marians thanks, do you have any ideas for the image? Normally Heather shares a little heads-up for me of what the image could look like / general idea. But if you don't have one it's also fine, we can do a more generic tech image showing the technology / application etc.

@HelloHeatherC The team has reviewed the draft. Now to you: do you have anything we should improve? (Feel free to edit style etc. directly. I trust you!)

@marians great minds! I was just about to ask you if I could start reviewing! Thanks for the trust, I'll leave suggestions if there are. ;-)

Hi @marians you're such a natural writer, kudos! I've made mostly minor suggestions, feel free to accept/reject/query. I just ask for a chance to read again when there aren't my suggestions there as it's hard to give a final read with suggestions still there. Thanks!

Thanks for the kind words! I applied all suggestions and also fixed the author bio :)
Next:

Header image (Marat maybe)
Screenshots (Marian)
Maybe screen recording of the access control UI (Marian)

Hi! Here's the preview for your review: https://www.giantswarm.io/blog/welcoming-more-users-to-our-web-interface-giant-swarm?hs_preview=mlZgoOge-67629692523
Please could you assist with the correct link for "Authorization in the Management API" in the sentence:
For more detailed instructions on how to set up permissions for scenarios like these, check our new article Authorization in the Management API.
Please let me know if you have any other changes and also please share the screenshots that are missing.

Here is the blog post: https://www.giantswarm.io/blog/welcoming-more-users-to-our-web-interface-giant-swarm


git: 2.31.1 -> 2.32.0

Motivation for this change
Things done

[ ] Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS linux)
Built on platform(s)

[ ] NixOS
[ ] macOS
[x] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
[x] Tested execution of all binary files (usually in ./result/bin/)
21.11 Release Notes

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[x] Fits CONTRIBUTING.md.

This update is already in staging: https://github.com/NixOS/nixpkgs/pull/125956

This update is already in staging: #125956

thanks!


Regarding the Asset Library submission

I got here while moderating you submission to Godot's Asset Library. The issue is that this repository contains a whole project and not only a plugin.
If the intention is to have this as a template, change the category in the submission to Template (you can edit it). Otherwise remove everything from the repository that is project related. You may leave a demo scene if you want, but without project files, especially without the .import folder. You also may create a new repository for your demo.
You can ping me here after you made the changes (or before if you have any doubts). Thanks!

Oh, I didn't know, there wasn't much documentation about how the submission should be structured, what it should include/exclude.
Should I also remove any files ending in .import as well? I'm assuming these aren't needed so long as none of the import parameters were changed, right?
I think I might end up separating the demos in a new repo. I'll @ you when it's done.

Yeah, we really need to document the submission process.
You don't need to delete the *.import files, it's okay to have the import options stored even if it's the default.

Okay I have separated the plugin from the demos and modified the info on the asset submission.
Regarding the documentation I see there aren't any issues open about this on godot-docs, at least not that I can find. Do you know if anyone is working on this? Should I open an issue? I'd like to help if I can.

I remember a few discussion, but not sure if it was on GitHub or not. If you can't find an issue about it, feel free to open one. I don't think there's anyone working on this right now, but it's good to remind.
I approved the in the Asset Library so it should be available now: https://godotengine.org/asset-library/asset/194. Thanks!


feat: for the hedera-network Helm chart set the minimum Kubernetes server version

Description
This pull request changes the following:

for the hedera-network Helm chart set the minimum Kubernetes server version

Related Issues

Closes #217

:tada: This PR is included in version 0.5.0 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:


Publicly expose loadingState of PaywallController and add a proper delegate method

Changes in this pull request

Adds the loadingStateDidChange capability on the PaywallViewControllerDelegate to be notified when the loading state of the presented PaywallViewController did change.
Adds a published property loadingStatePublisher on the PaywallViewController to be notified when the loading state of the presented PaywallViewController did change.

Checklist

[x] All unit tests pass.
[x] All UI tests pass.
[x] Demo project builds and runs.
[x] I added/updated tests or detailed why my change isn't tested.
[x] I added an entry to the CHANGELOG.md for any breaking changes, enhancements, or bug fixes.
[ ] I have run swiftlint in the main directory and fixed any issues.
[x] I have updated the SDK documentation as well as the online docs.
[x] I have reviewed the contributing guide

@yusuftor @jakemor @anglinb

Hey, thanks for this! Sorry it's taken a while to get round to this. I have some changes to push before merging, can you enable Allow edits from maintainers on the PR? Thanks!

Ok @yusuftor, I close the PR and you can push your changes on the new one => #246

Ok @yusuftor, I close the PR and you can push your changes on the new one => https://github.com/superwall/Superwall-iOS/pull/246


Add visit_simple to LLIL, MLIL, and HLIL

This has been coming up in the last couple training classes....
The normal visitor API is hard to use and has some information in it most people don't want/need. This attempts to provide a easier interface by only requiring a single parameter, and allows the visitor to be more versatile by allowing user defined parameters and return values.
This enables extracting more complex information without needing to use a global variable.
I think this would be a good replacement for the existing visitors, but properly deprecating them would be a bit messier given all the type signature changes.

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

In interest of getting this merged, I rebased this branch and hopefully quelled the discussion about what to name the new function by properly deprecating the old one and auto-dispatching to the new one.
Limitations of this implementation include:

You can't have a new visitor with exactly four parameters (any introspection that's more in-depth I believe relies on type annotations, which we can't assume are there)
You can't use the names parent nor name as a parameter in new visitors.

I can probably fix that second limitation if you like this new approach, please let me know!

Changes were made. Should be good to merge now. Thank you!


Use env and annotations from values file

This change will enable users to pass arbitrary env variables to deployment or daemonset during installation instead of editing deployment object afterward.
Same goes for custom pod annotations.

PR looks good to me.
@osnagovskyi If you could add something to the README indicating the added functionality that would be great.


MXML_MINOR_VERSION is still set to 2

I already noted it on a similar, but old and closed issue, but I figured it's probably best to note it on a brand new, open issue to make sure it's seen.
MXML_MINOR_VERSION is again out of sync. Per CHANGES.md's latest entry # Changes in Mini-XML 3.3.2, the most current version is 3.3.2 whereas .h file still reflects it as 3.2.
In fact, it's kinda a bit funny how this issue's fix of updating it to 3.2 is referenced as fix released in 3.3 release 😆, making it already outdated on that release 😂.

and this is fixed in master for 4.0. Not doing another 3.x release.


[Tooltip] Cannot use fixed position in IE

Bug, feature request, or proposal:
bug
What is the expected behavior?
tooltip with fixed position should work in IE, like in Chrome
What is the current behavior?
tooltip is not displayed in IE 11
What are the steps to reproduce?
https://plnkr.co/edit/CwWB1uxM1GgTNMafxNyw?p=preview
What is the use-case or motivation for changing an existing behavior?
Normal tooltip feature.  Want to control the placement of the tooltip.
Which versions of Angular, Material, OS, TypeScript, browsers are affected?
Latest versions from the current tooltip example in plunker
Is there anything else we should know?
It's not working in IE Edge either

I just tried the latest version on IE11 and the positioning seems to work correctly as far as I can tell in all cases. Feel free to open a new issue if there's a reproduction with v11+


sign_in(:user, store: false, bypass: true) stores the serialized user object in the session

I ran into this bug while using the following gem:
https://github.com/lynndylanhurley/devise_token_auth/blob/master/app/controllers/devise_token_auth/concerns/set_user_by_token.rb#L59
Calling both store: false, bypass: true causes the user object to be serialized into the session even though store is false.

You can see here that when bypass is true, the options variable is completely ignored.
https://github.com/plataformatec/devise/blob/7df57d5081f9884849ca15e4fde179ef164a575f/lib/devise/controllers/sign_in_out.rb

@mgwidmann Thank you for your report.
The options argument is ignored because the Warden::SessionSerializer#store doest no accept this argument.
In the Devise bypass option documentation says it will "bypass warden callbacks and stores the user straight in session". When you use bypass you want to store in the session, and it has more precedence than store: false.

@ulissesalmeida all im suggesting is perhaps warn or raise an error for those who attempt to use both, as it won't do what the user expects...

@mgwidmann It may be a good idea. Other approach is separate in two methods, one bypass method  that doest not have the options argument and a method that don't know how to bypass. I think it is more clear. What do you think?

seems fine to me


253 iiif broken links

Separating out the maintenance work from #261

When deployed, iiif links were no longer broken in the library search results page, e.g.:
https://test-derrida.cdh.princeton.edu/library/aristotle-organon-categories-de-linterpretation-1959/


WIP: script for routine evaluation

The generateNML.py utility script creates custom namelists based on existing namelists and the available data.
This PR shall not be merged until the WIP mark is removed

For now code will be used in temporary branch in private repo. Closing now

@bjoernbroetz Can this branch be deleted?

Yes, of cause. I will delete it.


fix: grpc logger ignore log level from config

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 79.9%

Totals

Change from base Build<PHONE_NUMBER>:
0.0%

Covered Lines:
4484

Relevant Lines:
5612

💛  - Coveralls


Option Flow not working

The option flow is not working (doesn't load current values, can't save) because the passed ConfigEntry does contain no options.
No idea why.

Because I only set up config_entry.data and not config_entry.options...


Update oekaki.py

Mostly working but it's a different "WORKING" - it's sort of back and forth again, working on some optimizations.


JobHost ServicePointManager settings in .NET Core?

The section on ServicePointManager settings explicitly mentions .NET Framework.  Does this apply to .NET Core projects as well?

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

ID: a4500b14-64b4-4d1b-aae3-f0fd4dde85f2
Version Independent ID: 8fb75741-37b9-b45f-c0ca-9948ddaf1c06
Content: How to use the WebJobs SDK for event-driven background processing - Azure
Content Source: articles/app-service/webjobs-sdk-how-to.md
Service: app-service-web
GitHub Login: @tdykstra
Microsoft Alias: tdykstra

@codecadwallader From what I have seen with our documentation, ServicePointManager is now included in .NET Core starting with version 2.0. As long as you're using 2.0 or 2.1 .NET Core, you should be fine.
We will now proceed to close this thread. If there are further questions regarding this matter, please reopen it and tag me in your reply. We will gladly continue the discussion.

@BryanTrach-MSFT Thanks Bryan for the response.  I have seen that ServicePointManager is included in .NET Core, but I've also seen information suggesting that maybe WinHttpHandler is the effective control for the number of concurrent limitations?  https://stackoverflow.com/questions/36398474/servicepointmanager-defaultconnectionlimit-in-net-core  Do you know for WebJobs specifically which one applies?

@codecadwallader In the example that you provided, the customer was working with an early version of .NET Core that did not support ServicePointManager, which is why they suggested using WinHttpHandler.
As far as I am aware, WebJobs will not be the limiting factor. As long as the framework supports WinHttpHandler or ServicePointManager, either should work with the web jobs product. With that being said, I can find examples of ServicePointManager being using with Web Jobs and I can't find anything to share with you internally or externally about WinHttpHandler being used within a Web Job.
ServicePointManager with WebJobs: https://github.com/Azure/azure-webjobs-sdk/wiki/ServicePointManager-settings-for-WebJobs

@BryanTrach-MSFT thanks Bryan, I appreciate the follow-up and information.


Render function is getting called twice

I'm using the render function on columns object but I'm notice when something changes on the data, the render function is being call twice per row
on the screenshot below you will see the render function has been called twice:

this is the code sandbox where you can replicate the error
https://codesandbox.io/s/renderfunction-fx5h7
Open the console
Click on the button to change the data
Check function was called twice per row
I'm using version 4.3.10

It looks like sandbox is using an older version of material-ui. Per the error message, would you mind upgrading the version of material-ui (NOT @material-table/core) and trying again?

As far as each row rendering twice, I need to dig into why that is happening. @Domino987 any ideas?

I have been doing some research:

In this little example, (which is the same @edgar-pozadas-by  provided but with one row) I got MuiTableCell called 6 times (twice 3) and the MuiTable row is called 2 times (twice 1)
I do not know if i explain myself :(
Then i go to the materia-table itself, and i saw that the componentDidUpdate was called twice. I added a small code snippet to check why it was called twice:
at src/material-table.js
  componentDidUpdate(prevProps, prevState) {
    console.log('componentUpdated on material-table component');
    Object.entries(this.props).forEach(
      ([key, val]) =>
        prevProps[key] !== val && console.log(`Prop '${key}' changed`)
    );
    if (this.state) {
      Object.entries(this.state).forEach(
        ([key, val]) =>
          prevState[key] !== val && console.log(`State '${key}' changed`)
      );
    }

And i got this:

just a little visual help in order to describe what i think is the issue

Could this be caused by the react dev mode where every component is called twice?

Sorry what do you mean with dev mode? running on local or react dev tools?

Running on local with strict mode

@edgar-arroyo-by thank you for your research on this issue! There are def some kinks that need to be worked out as far as rerenders. However we handle it, it won't be a quick easy fix.
Perhaps separating provided options with internal state could help?

@oze4 is there any update on this issue?

@oze4 Is there any ETA or plans to address this anytime soon? This one is impacting one of our customers and they are having poor performance on their table


High level Modify interaction events

Related to the desired feature as discussed in #2946.
I think this PR needs test cases if the event is to be marked as stable. Also, events are currently triggered without checking for actual changes in the features(s) which probably should be avoided.

Check for change introduced in 8ef1550d7a6c2de0ec35bbd7b83b8a74be9fdf6c but it might be useless, there is no case where the geometry would not be modified. In the current master clicks on line segments will raise the geometry revision but no vertex will be created but this is undesirable and should be changed so that vertexes are created on single clicks.
The modify interaction does not currently have any meaningful testcases so this PR will remain untested. Initial testcases should be created as a separate PR.

To clarify the state of this PR I think 8ef1550 should be removed and the behaviour change as described above. I've made tests for the current behavour with #3630 but unfortuneatly it's not trivial to change the behaviour but I intend to try in the near future.

Rebased and squashed without 8ef1550 since I've been able to change the mentioned behaviour with #3635.

Would be nice if this gets merged.

@bjornharrtell could you add @fires as in #3740 so it appears in api docs

Added @fires, rebased and squashed.

I've been thinking about this specifically for implementing a crude split for linestrings. As mentioned in #1165 you could use turfjs to split at an existing vertex. If the vertex at which you want to split doesn't exist, you could add it with the modify interaction, and could then split the line at this new point. But, even if this PR is merged so an app is notified that a change has taken place, the app has no way of knowing which is the new vertex, other than by storing the original list of coordinates and comparing them with the new list - yuk. So I'm thinking that this PR should be changed like interaction.Select to include the mapBrowserEvent, so you know at which pixel/coordinate the new vertex was added.

alternatively, of course, modify could pass the modified vertex along with a add/change/delete type code

I think it makes sense to add mapBrowserEvent in the same manner as was done for ol.interaction.Select in #3757.

So, I have added mapBrowserPointerEvent as a property to ModifyEvent. Noted that ol.interaction.Modify uses the more specific MapBrowserPointerEvent instead of MapBrowserEvent that is used for ol.interaction.Select and ol.interaction.Draw. Don't know yet if there is a good reason for this or not. @probins, please review if possible.

Anybody up for reviewing this today? So it could go in the 3.7 release?

I think it's fair enough that Modify uses the Pointer event: AIUI, the Pointer event separates mouse down and up (and drag), which you need with Modify, but don't need with Draw; with Draw, you just need the drawn feature, and if you need the start/end coordinate, you can get those from the Geometry.
However, I think the Modify event here needs to include the feature that's being modified. I don't need this myself, as I use it together with Select, and only have 1 feature at a time. But in principle the Modify interaction can have any number of features in the collection, and in this case the app has no way of knowing which feature is being operated on.
That could however be in a separate PR.

I put some review comments in just now

Thanks for the review @bartvde and @probins. I agree that this should be experimental api and have fixed the plural/singular typo.

thanks @bjornharrtell I'll merge once Travis gives the okay

I think the Modify event here needs to include the feature that's being modified

though there is another way of handling this, namely by adding listeners for change:geometry to the features.

I've just been testing this in the real world as opposed to simple test data, and find that there is an issue with the pixel/coordinate from the browser event. As said before, you need the coords of the newly created/modified vertex, but because of snapping/tolerance, this probably won't be the same as the coordinate the user clicked: if adding a vertex on a linestring, for example, it's unlikely that the user will click exactly on the line, so any new point will probably not be created at the browser event coord/pixel.
So I'm not sure the browser event is much use here. What the modify event should return is the vertexfeature that's been created/moved/deleted. Should I create a separate issue for this?

and another issue here is the timing of the events. At the moment, start is before drag but after creating the new vertex. If you are, though, adding a vertex with a click, which you can do now with #3635, there is no drag, so there's effectively little difference between start and end. ISTM in this case you want a start notification at the beginning of the handleDown function, so you get the feature/geometry 'before' modification and then the end event 'after' modification.
When deleting a vertex on the other hand, it looks like the end event is fired before the geometry has been changed.

any new point will probably not be created at the browser event coord/pixel

as an aside to this, I thought I might be able to use getClosestPoint(browserEvent.coordinate) to get the new vertex, but found that this was a similar but not identical value, so coordinates.indexOf(...) didn't find a match. Shouldn't this be the same? Shouldn't creating a new vertex use getClosestPoint()?


added feature inspection crawler

Found a few instances where the extracted features did not align with the content of the DB. In particular the number of features was not the same as the number of points for that image. So wrote this crawler to inspect how common this is.

@StephenChan : thanks for the unicode, reminder (again!). Please drop me a line once the code is updated on master.

@beijbom This is available in production now.


How to continue training with new settings?

After training a model, is there any way to do a new training run, starting from the result of the previous run?  I know I can use the load_model option, but that resumes an existing run from a checkpoint with exactly the same settings used before.  Here are the sorts of things I'd like to be able to do:

Train on one dataset, then fine tune on another dataset.
Initially train just on energies, then fine tune with forces as well.
Train in reduced precision (half or TF32), then fine tune in full precision.

If you load a checkpoint using the --load-model arg you can simply also specify a config file through --config or add command line arguments directly, which will overwrite the args from the checkpoint file. Of course adapting architectural hyperparameters will break the training as loading the checkpoint's state dict wouldn't work. The arguments you listed should work perfectly fine though.

That's what I had expected, but I can't get it to work.  For example, a training run stopped earlier than I wanted it to.  So I increased early_stopping_patience and decreased lr_min and tried to resume.  But it didn't make a difference.  It still stopped training after just a few epochs, at the same point it had on the original training run.

Here is another example.  I just trained a model on energies.  Now I'm trying to fine tune it including forces as well.  When I tell it to load from the checkpoint, it ignores the learning rate in the configuration file and instead starts from the final learning rate at the end of the original training run.

Ah right, pytorch-lightning stores information about optimizer state, current lr and so on in the checkpoint. I just added a new argument to train.py to reset the trainer state when loading a model. You can simply add reset_trainer: true to your config file. Let me know if this resolves it.

Thanks!  That seems to work.


gnn_link.py issues after refactoring

python gnn_link.py --dataset=rel-amazon --task=user-item-purchase --epochs 100 --eval_epochs_interval 1
Traceback (most recent call last):
  File "/workspace/relbench/examples/gnn_link.py", line 64, in <module>
    data, col_stats_dict = make_pkey_fkey_graph(
  File "/usr/local/lib/python3.10/dist-packages/relbench/external/graph.py", line 93, in make_pkey_fkey_graph
    dataset = Dataset(
  File "/usr/local/lib/python3.10/dist-packages/torch_frame/data/dataset.py", line 594, in materialize
    self._col_stats[col] = compute_col_stats(
  File "/usr/local/lib/python3.10/dist-packages/torch_frame/data/stats.py", line 166, in compute_col_stats
    raise TypeError("Numerical series contains invalid entries. "
TypeError: Numerical series contains invalid entries. Please make sure your numerical series contains only numerical values or nans.

python gnn_link.py --use_shallow  --dataset=rel-stack --task=post-post-related --epochs 2
Traceback (most recent call last):
  File "/workspace/relbench/examples/gnn_link.py", line 64, in <module>
    data, col_stats_dict = make_pkey_fkey_graph(
  File "/usr/local/lib/python3.10/dist-packages/relbench/external/graph.py", line 118, in make_pkey_fkey_graph
    assert (pkey_index < len(db.table_dict[pkey_table_name])).all()
AssertionError

@rishabh-ranjan

These should be fixed now.


Reg:Dalli Client

I have pushed the binary memcache branch still while connection Dalli is throughing following error
Dalli::RingError: No server available
from /Users/user/.rvm/gems/ruby-2.1.5@rails3/gems/dalli-2.7.0/lib/dalli/ring.rb:45:in server_for_key' 	from /Users/user/.rvm/gems/ruby-2.1.5@rails3/gems/dalli-2.7.0/lib/dalli/client.rb:322:in perform'
from /Users/user/.rvm/gems/ruby-2.1.5@rails3/gems/dalli-2.7.0/lib/dalli/client.rb:103:in set' 	from (irb):6 	from /Users/user/.rvm/gems/ruby-2.1.5@rails3/gems/railties-3.2.18/lib/rails/commands/console.rb:47:in start'
from /Users/user/.rvm/gems/ruby-2.1.5@rails3/gems/railties-3.2.18/lib/rails/commands/console.rb:8:in start' 	from /Users/user/.rvm/gems/ruby-2.1.5@rails3/gems/railties-3.2.18/lib/rails/commands.rb:41:in <top (required)>'
from script/rails:6:in require' 	from script/rails:6:in '
Regards,
Priyanka

no idea what the issue is


Commands Update

Updated some commands;
Fixed a bug on data loading when Group config file dont contains the default or spadmin group.

Nice update


Idea: about the grey question mark icon in Google Play Music

Grey question mark icon in Google Play Music
I think that this grey icon in Google Play Music inappropriate, as there are official names of the tracks and scrobbling the logic must go at once, without the confirmation of artist and title song.
With ❤ from 🇷🇺

The logic of song recognition is common for all connector. I don't think that separate logic for different connectors is a good idea.
As alternative, I'm planning to add new option; if this one is enabled, songs will be recognized by the extension even if they are unknown by Last.fm.

good idea, look forward to, thanks


MINOR: Bump Gradle version to 5.0

Gradle 5.0 was released on 26 November. See the release notes for enhancements and fixes: https://docs.gradle.org/5.0/release-notes.html.
A notable bugfix ensures that Javadoc artifacts are cleaned between builds.
The upgraded wrapper was spot-checked against the commands in the README.
Committer Checklist (excluded from commit message)

[ ] Verify design and implementation
[ ] Verify test coverage and CI build status
[ ] Verify documentation (including upgrade notes)

@colinhicks Thanks for the PR. I pushed a couple of additional commits. Let me know what you think.

@ijuma Thanks for the review and edits. I should have noticed that the deprecated single test commands actually cause all the tests to run. I verified that your edits work as documented.
In taking a pass at the commands using Java 11, I noticed that ./gradlew aggregatedJavadoc fails against Java 11, yet succeeds using Java 8. However this does not appear related to the Gradle update, as I see the same behavior against trunk (fails in 11; succeeds in 8). Would you advise filing a separate bug?

I had filed a JIRA about the aggregatedJavadoc thing but I think someone closed it. It may be worth reopening.

Using from breaks bootstrapping with older Gradle versions so we should remove that commit for now.


Forwarder priority documentation

Type of change

Documentation

Description
Documentation for the ability to specify a forwarder's priority.
Checklist

[ ] Update/write design documentation in ./documentation/design
[ ] Write tests and make sure they pass
[ ] Update documentation
[ ] Check RBAC rights for Kubernetes / OpenShift roles
[ ] Try your changes from Pod inside your Kubernetes and OpenShift cluster, not just locally
[ ] Reference relevant issue(s) and close them after merging
[ ] Update CHANGELOG.md

Release-0.33 branch was renamed to master: Please re-create PR against master branch.


Pushing new version fails in repositories with protected branches

Possible solution would be to use release/x-y-z branches for new releases.

These (automated) steps should do the trick:

create dedicated release branch (implemented in #4)
create PR
add GH Action to merge any release/* branch


from ..parent_package import something don't work in jupyter notebook cell of vs code

there is no way to launch python code in cell as run python -m

Thank you for filing this issue, and sorry you are running into this.
However I do not understand the problem you are running into
Please can you provide step by step instructions used to replicate this issue,
E.gl. open a notebook file, add a cell and run the cell..
Also please can you add screenshots as that would help me get a better idea of the problem

Closing this issue as its been over 4 weeks, since the information was requested.
We'll be happy to reopen the issue when the requested information has been provided.


Update examples in Sync/Keycloak getting started

@maleck13 Would you mind taking a look? I'm not sure about the difference between setup and getting started or if they're both needed. I've updated the getting started section. Can remove things/split things if needed
I've kept the format of the core SDK as it was exactly the same as my starting point for it.

looks ok. Needs merge / rebase

Ooh I need to update this


Will's design

I made a mistake at submitting file. I deleted the wrong file and submit the correct one.

I couldn't pass the GDS/OAS file check for some reason

@WillChen9193
could you please move this repo to be in your own account, rather than SiEPIC?
thanks

Is that better? Sorry I made a mistake

Thank you!


Aspect ratio

First of all thanks very much for the great work. This is exactly what I was looking for, I’m building a project that involves a lot of animations and I didn’t want to be fighting with auto layout.
I did have a question. What is the best way to handle aspect ratios? Specially for UIImageViews. I’m using percent for a lot of sizing, but this makes it difficult to preserve aspect ratios.
Any suggestions?

Hi @Sully73, thanks for the great comment, it's appreciated 👍
The support of aspectRatio is on my todo list.
What will be implemented:

Add a method aspectRatio(:CGFloat). If the width or the height has been set, the aspectRatio value will be used to compute the other dimension. If neither dimension (width/height) or both have been specified, aspectRatio won't be applied and a warning will be displayed.
Add a method aspectRatio() that will only work with UIImageView. This method will use the UIImageView's image aspect ratio.

I should be able to play with this week.
For the time being the only option I see is to layout your UIImageView in two operations:
let imageSize = myImageView.image!.size
let imageRatio = imageSize.width / imageSize.height

// Layout the UIImageView without specifiying the height.
myImageView.pin.top(20).left(20).width(50%)
// then adjust the height
myImageView.pin.height(myImageView.frame.width / imageRatio)

Soon you'll be able to do:
myImageView.top(20).left(20).width(50%).aspectRatio()

If you have any comment on my aspectRatio proposition just let me know 🙂

What your proposing sounds great. That will handle all of my needs. Thanks

Hi @Sully73, I've completed the implementation of aspectRatio, check the release 1.3.2:  https://github.com/mirego/PinLayout/releases/tag/1.3.2

Thanks very much!


Add @Searge to code-mode

What type of PR is this? (check all applicable)

[x] 🚀 Added Name
[ ] ✨ Feature
[x] ✅ Joined Community
[ ] 🌟 ed the repo
[ ] 🐛 Grammatical Error
[ ] 📝 Documentation Update
[ ] 🚩 Other

Description
Added a link to Serhii Boremchuk's GitHub profile.
Add Link of GitHub Profile
https://github.com/Searge

Hello, @abhisheknaiidu
Could you merge this?


remove incorrect character from changelog

While using airbnb/react-sketchapp I was faced by this error from dependecy skpm, there's a slash that crash's the app.

@mathieudutour could help a little to integrate this PR?


cd -P in wrapper to handle being with non-terminal symlinks

Context
Currently, I get (Debian 4.4.1-18, so /bin -> /usr/bin; /usr/bin/gradle -> ../share/gradle/bin/gradle)
$ gradle
/bin/gradle: 23: cd: can't cd to /bin/../share/gradle/bin/..
openjdk version "17.0.10" 2024-01-16
OpenJDK Runtime Environment (build 17.0.10+7-Debian-1deb12u1)
OpenJDK 64-Bit Server VM (build 17.0.10+7-Debian-1deb12u1, mixed mode, sharing)
Error: Could not find or load main class org.gradle.launcher.GradleMain
Caused by: java.lang.ClassNotFoundException: org.gradle.launcher.GradleMain

this corresponds to the first cd here:
SAVED="`pwd`"
cd "`dirname \"$PRG\"`/.." >/dev/null
APP_HOME="`pwd -P`"
cd "$SAVED" >/dev/null

note that pwd has -P, but the cd doesn't; per POSIX, the default cd mode is -L, which transforms /bin/../share/gradle/bin/.. to /share/gradle before giving it to chdir(2). This obviously doesn't exist.
cd -P instead executes chdir("/bin/../share/gradle/bin/..") which works as expected.
In this version (with app_path=/bin/gradle overridden), the issue manifests as
$ ./gradlew
./gradlew: 88: cd: can't cd to /bin/../share/gradle/bin/

and indeed correcting it to cd -P fixes it as well.
Additionally, rather than invoking pwd -P, we can now just use out $PWD, which (POSIX, XCU, cd, DESCRIPTION, 10, ll. 88190-88191):

If the −P option is in effect, the PWD environment variable shall be set to the string that would be output by pwd −P.

Contributor Checklist

[x] Review Contribution Guidelines.
[x] Make sure that all commits are signed off to indicate that you agree to the terms of Developer Certificate of Origin.
[x] Make sure all contributed code can be distributed under the terms of the Apache License 2.0, e.g. the code was written by yourself or the original code is licensed under a license compatible to Apache License 2.0.
[x] Check "Allow edit from maintainers" option in pull request so that additional changes can be pushed by Gradle team.
[ ] Provide integration tests (under <subproject>/src/integTest) to verify changes from a user perspective. – idk how that would happen really
[ ] Provide unit tests (under <subproject>/src/test) to verify logic. – likewise
[x] Update User Guide, DSL Reference, and Javadoc for public-facing changes.
[x] Ensure that tests pass sanity check: ./gradlew sanityCheck.
[x] Ensure that tests pass locally: ./gradlew <changed-subproject>:quickTest.

Thank you for your contribution!
The DCO check is failing, please look into that as we can't accept the PR otherwise.

Additionally, this change should be done in the template.

Thanks; updated, looks like DCO passes too.

This PR is complete and simple enough, it will be merged immediately.


events: move into sub-package, wrap all http.ResponseWriters

Codecov Report

Merging #336 into master will decrease coverage by 4.47%.
The diff coverage is 41.89%.

@@            Coverage Diff             @@
##           master     #336      +/-   ##
==========================================
- Coverage   61.35%   56.87%   -4.48%
==========================================
  Files          54       57       +3
  Lines        5731     5781      +50
==========================================
- Hits         3516     3288     -228
- Misses       1528     1860     +332
+ Partials      687      633      -54

Impacted Files
Coverage Δ

internal/database/mysql.go
10.66% <ø> (-50.67%)
:arrow_down:

internal/database/sqlite.go
56.86% <ø> (ø)
:arrow_up:

internal/http.go
66.66% <0%> (-8.34%)
:arrow_down:

internal/events/test_repository.go
0% <0%> (ø)

cmd/server/main.go
20.68% <0%> (ø)
:arrow_up:

internal/depository/admin.go
70.96% <100%> (ø)
:arrow_up:

internal/microdeposit/admin.go
68.18% <100%> (ø)
:arrow_up:

internal/events/routes.go
24.32% <24.32%> (ø)

internal/route/route.go
26.82% <26.82%> (ø)

internal/receivers.go
50.53% <30.5%> (+1.56%)
:arrow_up:

... and 18 more

Continue to review full report at Codecov.

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


Put in the exchange for staging/prod

Coverage remained the same at 100.0% when pulling 91a8f22dfd2a78ef084eb5cb6d1006696038a166 on fix_config into 864c9e10380fe10fb9c675918dce326d3eb1dd0b on master.


(1164/1294b) Add audiences back to seed data

Context

After recent changes to the seed data, all endpoints except those related to referral summaries were working
Changes in this PR
Temporarily revert removal of audience-related table data from seeds
Release checklist
Release process documentation
As part of our continuous deployment strategy we must ensure that this work is
ready to be released once merged.
Pre-merge

[ ] There are changes required to the Accredited Programmes UI for this change to work...

[ ] ... and they been released to production already

Post-merge

[ ] Manually approve release to preprod
[ ] Manually approve release to prod

 Read referable from an Offering rather than a Course (S)

 Read singular "audience" value from API (M)


Support for ST7701S display driver (IDFGH-10449)

Is your feature request related to a problem?
Nowadays, it has become increasingly popular to include a touch display for various projects. This allows consumer/user to control and monitor the device much more easily.
I think it would be very beneficial to support as many of the popular displays as possible to give developers freedom to choose display for their particular application.
Currently, I do not think esp-idf support any of the LCD round displays.
Describe the solution you'd like.
We have recently gone through some issues to get the 1.9" touch display from LilyGo to work properly.
I think it would also be very cool to get the 2.1" Round display from LilyGo to work on esp-idf:
https://www.lilygo.cc/products/t-rgb?variant=42503165673653
This display is based on ST7701S TFT LCD display and CST820 touch chip.
Describe alternatives you've considered.
Using different displays such as ST7789/ILI9341 but these driver chips does not seem to support round displays.
Additional context.
Please consider this. I think it will be very useful for esp community :)

Currently, I do not think esp-idf support any of the LCD round displays.

We do have round display support, e.g. https://components.espressif.com/components/espressif/esp_lcd_gc9a01
We're maintaining LCD display and touch driver in our bsp repo. You can ask for feature requests there in the future.


ResourceLimiter is now used from a ClientInterceptor.

AsyncExecutor and BulkMutator shouldn't have to know about ResourceLimiter directly.

Most of the comments were addressed.  PTAL

I addressed the comments.  PTAL.


Large day numbers of the Calendar plugin

Is the bug present when using the default Obsidian theme?
No
Is the bug present when snippets and plugins are disabled?
Yes
Minimal theme version
6.3.5
Describe the bug
After the recent upgrade to 6.3.4 or 6.3.5 minimal theme version, the day numbers of the popular Calendar plugin became much bigger:

Would it be possible to revert this size change, as it is for example in the Default Obsidian theme?
Debug info
SYSTEM INFO:
	Obsidian version: v1.3.5
	Installer version: v1.3.5
	Operating system: Darwin Kernel Version 22.5.0: Mon Apr 24 20:53:19 PDT 2023; root:xnu-8796.121.2~5/RELEASE_ARM64_T6020 22.5.0
	Login status: logged in
	Catalyst license: vip
	Insider build toggle: off
	Live preview: on
	Legacy editor: off
	Base theme: dark
	Community theme: Minimal v6.3.5
	Snippets enabled: 0
	Restricted mode: off
	Plugins installed: 18
	Plugins enabled: 18
		1: Text Snippets v0.1.2
		2: Templater v1.16.0
		3: Style Settings v1.0.6
		4: Minimal Theme Settings v6.3.1
		5: Latex Suite v1.7.2
		6: Icon Folder v2.1.2
		7: Execute Code v1.8.1
		8: Emoji Shortcodes v2.2.0
		9: Copy Block Link v1.0.4
		10: Filename Heading Sync v1.9.0
		11: Natural Language Dates v0.6.1
		12: Find orphaned files and broken links v1.9.0
		13: Recent Files v1.3.6
		14: Linter v1.15.2
		15: Smart Typography v1.0.18
		16: Paste URL into selection v1.7.0
		17: Advanced Tables v0.18.1
		18: Calendar v1.5.10

RECOMMENDATIONS:
	Custom theme and snippets: for cosmetic issues, please first try updating your theme and disabling your snippets. If still not fixed, please try to make the issue happen in the Sandbox Vault or disable community theme and snippets.
	Community plugins: for bugs, please first try updating all your plugins to latest. If still not fixed, please try to make the issue happen in the Sandbox Vault or disable community plugins.

closed in 6.3.6

Unfortunately, it looks like the issue continues to occur in 6.3.8, and is also reported here: https://github.com/kepano/obsidian-minimal/issues/580

Fixed in 6.3.9


How to get all transaction records of a wallet address？？

name: Bug Report
about: Using AlphaWallet, but it's not working as you expect?

Describe the bug
A clear and concise description of what the bug is.
Steps to reproduce (REQUIRED)
Steps to reproduce the behavior

Tap Wallet tab
Tap ...
Tap ...
Wait ...
Tap ...

Expect
6a. ...
Observed
6b. ...
Screenshots
If applicable, screenshots (preferred to video) to help explain your problem, a wallet address or transaction hash if applicable/possible
Version or build number number
Version number (if app store), build number (if TestFlight)
Additional context (Error Messages, etc.)
Add any other context about the problem here.

@tinaxiu2014 can you clarify if you downloaded the app from the app store and want to access the transactions in the Activity tab or are you trying to customise the app/code or if it's something else?

yes,in the Activity tab, i can see  some send transaction records, but can't see received transaction records.

like this picture.

I see. Let me rope in my colleague to help. (I might help you but they will be able to do it faster).

ok。please reply as soon as possible

Hi @tinaxiu2014, can I confirm:

Android or iOS ?
version --> navigate to [Settings] scroll to very bottom eg. Android will say v. 3.33 (158) if it is the latest release
Could you please provide your wallet address? I will try to see if I can replicate your issue.

Thank you

iOS , version is 1.0.0（2）, my wallet address ：0xc25761Ac06b71A06b329dcEDAaD3e350d814B2C6  , wait reply . thanks .

iOS , version is 1.0.0（2）, my wallet address ：0xc25761Ac06b71A06b329dcEDAaD3e350d814B2C6 , wait reply . thanks .

please reply as soon as possible

iOS , version is 1.0.0（2）, my wallet address ：0xc25761Ac06b71A06b329dcEDAaD3e350d814B2C6 , wait reply . thanks .

There is no transactions on POA network for the given wallet address. Did you share the correct wallet address?
https://blockscout.com/poa/core/address/0xc25761Ac06b71A06b329dcEDAaD3e350d814B2C6/transactions

@tinaxiu2014, also sharing the link from the transactions details page as show below would help us make sure that we are all looking at the correct place.

yeah,my wallet address ：0xc25761Ac06b71A06b329dcEDAaD3e350d814B2C6  ，it is in my custom RPC network.

yeah,my wallet address ：0xc25761Ac06b71A06b329dcEDAaD3e350d814B2C6 ，it is in my custom RPC network.
now i can't see received transaction records.

Could you please provide the MSC token contract address please? Three of us have been unable to replicate using the  wallet address , nor can we find on any blockexplorers...


[MM-42886] Introduce weekly digest

Summary
Introduces a weekly digest, similar to the daily one.

Currently users would receive weekly digest if the daily digest is enabled.
What's left:

[x] Introduce a enable/disable weekly digest flag
[x] The above flag should default to the current daily digest setting
~- [ ] Add a feature flag, as this is a user-facing feature and includes refactoring~
~- [ ] Add more tests for corner cases around sending daily/weekly digests~

Ticket Link
Weekly Digest
Checklist

[x] Telemetry updated
[x] Gated by experimental feature flag
[x] Unit tests updated

Hello @batebobo,
Thanks for your pull request! A Core Committer will review your pull request soon. For code contributions, you can learn more about the review process here.

Hey @batebobo! I'd love to have @crspeller take a look at this review -- should we wait until it leaves draft status?

Hi @lieut-data! Yesterday I re-requested a review from @mkraft and GitHub automatically removed @crspeller :( I'd also like another person to review the task!

No worries! That's weird behaviour on GitHub's part -- fixed :)

Thanks for re-requesting @Phrynobatrachus! I didn't mean to remove you, but rather to re-request review from @crspeller :(

No worries, it's a Github bug I've seen a few times recently.

Hey @Phrynobatrachus! Thanks for the comment and the screenshots! It seems that the timestamp is from a while ago (~30 years), so it definitely doesn't make sense to receive a daily digest. I'll take a look and let you know

Hey again @Phrynobatrachus! There was still code left to change with regard to the difference between daily digest, weekly digest and /playbook todo. I pushsed the necessary changes and tested it with the following cases:

Didn't send any digest because of no data to show
/playbook todo still showed everything (even with 0s all around)
Added 5 playbooks and 1 run with tasks assigned to me. Weekly digest was sent (all sections, even the ones with 0s)
Daily digest was sent (not showing the 0 overdue tasks)
/playbook todo still works with all the data

Let me know if anything else comes up :)

Apologies for the delay, once we sort out
https://github.com/mattermost/mattermost-plugin-playbooks/pull/1509#discussion_r1016979222
this should be good, everything else appears to be working after the updates.

Hi @Phrynobatrachus! Thanks for the feedback! I'll check the case with the daily/weekly flags later today and let you know :)

It looks like another pull request won the migration race for the name 0.61.


Updated output struct fields

Removed unnecessary annotations from output sample struct.

Thanks for the feedback @lfrancioli !

you should filter_cols(hl.is_defined(mt.cram)) instead of filering for it in your  expr.

This makes sense and I've moved it to the same filter as release-able samples

for males in get_expr_for_hemi, you  should think whether you want to reduce the dp_threshold to half  since they are haploid.

I did address this but I'm not thrilled with my approach, feedback welcome.

you should use gnomad_qc.vv3.resources instead of redifining any  path to resources. In particular:
-get_full_mt instead mt = hl.read_matrix_table(args.variant_mt_path).key_rows_by("locus", "alleles") as it avoids passing through the data to verify sort order.

This makes sense and I've adjusted the metadata table as well

the cram_paths would be good to add to the gnomad_qc v3 repo

These are going to be deleted so I can add this to the repo but they will not be relevant at the end of the month.

remove densify

👍

you compute adj but never use it  --remove

👍

use filter_entries((mt.GQ >= gq_threshold) & (mt.DP >= dp_threshold) (possibly with a difference for male at non-PAR for the dp_threshold and remove from your expressions' right now you're computing them 3x/entry

Used this instead but again I dont love the dp threshold expr approach. Thanks for including why this is a bad move with the 3x explanation!

only run the hemi logic on X/Y non-PAR. (otherwise return missing)

This makes sense!

Do you need to produce a single list samples with the var_type? It would likely be better to produce 3 separate lists of samples and forgo the addition of a string for each GT.

This was a request of @bw2 . I believe his pipeline needs them?

This is likely a small thing, but it you need the single list, it' s probably better to add that var_type after the take (I'd add it in the last select when you join the lists together)
You forgot to add the hemi vars in the last select

I'm not sure I understand here, the hemi array is the last extend?
ht = ht.select(
        samples=ht.samples_w_het_var.extend(
            ht.samples_w_hom_var.extend(ht.samples_w_hemi_var)
        )
    )

@bw2 : Can you  confirm that you need a single annotation with an array with elements of type struct{s, GQ, var_type (het, hom, hemi)} and not 3 annotations het, hom, hemi each with an array with elements of type struct{s, GQ}.

@lfrancioli I wanted the single array of struct{s, GQ, var_type (het, hom, hemi)} because I was thinking the last step afterward would be to explode the table on that array, and write out the ~1.05 billion records to many tsv's (ideally in a  way where each tsv has all the records from variants with pos % N == k where N = 20,000 - so 20,000 tsv per chromosome).
I have no idea if hail can handle that currently? or if you guys can think of a better way to send this info into cromwell/Terra?

I see! I think Hail should be able to handle this -- that said you don't need the single array to explode; you can just combine them on the fly in an annotate before explode. If we're going to keep the Hail Table for future reference, I think it'd make more sense to leave them as 3 arrays since it saves space and potentially is easier to query.

Thanks @lfrancioli! @bw2 , are you fine with the three list approach and annotating variant type and creating the single array in the next steps to avoid storing the extra string per struct entry?

Thanks @lfrancioli! @bw2 , are you fine with the three list approach and annotating variant type and creating the single array in the next steps to avoid storing the extra string per struct entry?

Storing 3 arrays and computing the single array afterward sounds good to me.

@Laurent, would you mind taking one last look as we went with the 3 array solution? Thanks!


JWT and Windows mixed authentication. IISOptions.AutomaticAuthentication configuration not working.

Describe the bug
Assembly: Microsoft.AspNetCore.Server.IISIntegration
The  "AutomaticAuthentication" boolean property of the "Microsoft.AspNetCore.Builder.IISOptions" class is not behaving as expected. When set to false the configured "AuthenticationScheme" is ignored and "WWW-Authenticate" response headers are sent back with "Negotiate" and "NTLM". This eventually makes the browser prompt for credentials.

Note that you have to enable "Windows Authentication" in your project properties or in IIS.

https://docs.microsoft.com/en-us/aspnet/core/security/authentication/windowsauth?view=aspnetcore-2.1

https://docs.microsoft.com/en-us/aspnet/core/host-and-deploy/iis/?view=aspnetcore-2.1

//The following is my "**ConfigureServices**" implementation.
public void ConfigureServices(IServiceCollection services)
        {
            services.AddCors();

            services.Configure<IISOptions>(o =>
            {
                o.AutomaticAuthentication = false;
                o.ForwardClientCertificate = true;
            });

            services.AddMvc(config =>
                {
                    //Secure all controllers
                    var policy = new AuthorizationPolicyBuilder()
                    .RequireAuthenticatedUser()
                    .Build();

                    config.Filters.Add(new AuthorizeFilter(policy));

                }).SetCompatibilityVersion(CompatibilityVersion.Version_2_1);

            // In production, the Angular files will be served from this directory
            services.AddSpaStaticFiles(configuration =>
            {
                configuration.RootPath = "ClientApp/dist";
            });

            var jwtTokenSettings = Configuration.GetSection("JwtToken");
            var signKey = new SymmetricSecurityKey(Encoding.UTF8.GetBytes(jwtTokenSettings.GetValue<string>("SignKey")));
            var encryptKey = new SymmetricSecurityKey(Encoding.UTF8.GetBytes(jwtTokenSettings.GetValue<string>("EncryptKey")));

            services.AddAuthentication(o =>
            {
                o.DefaultChallengeScheme = JwtBearerDefaults.AuthenticationScheme;
                o.DefaultScheme = IISDefaults.AuthenticationScheme;
            })
            .AddJwtBearer(options =>
            {
                options.TokenValidationParameters = new TokenValidationParameters
                {
                    ValidateIssuer = true,
                    ValidateAudience = true,
                    ValidateLifetime = true,
                    RequireExpirationTime = true,
                    ValidateIssuerSigningKey = true,
                    ValidIssuer = jwtTokenSettings.GetValue<string>("ValidIssuer"),
                    ValidAudience = jwtTokenSettings.GetValue<string>("ValidAudience"),
                    IssuerSigningKey = signKey,
                    TokenDecryptionKey = encryptKey,
                };
            });

[Route("api/[controller]")]
    [ApiController]
    public class ValuesController : ControllerBase
    {
        // The Authorize attribute with the "Bearer" AuthenticationScheme
        [HttpGet]
        [Authorize(AuthenticationSchemes = JwtBearerDefaults.AuthenticationScheme)]
        public ActionResult<IEnumerable<string>> Get()
        {
            return new string[] { "value1", "value2" };
        }
}

Expected behavior
Windows Authentication should not be automatically challenged when an "AuthenticationScheme" is configured for a different scheme.
Additional context
The good news is that I was able to find a workaround.
I've enabled IIS "Feature Delegation" for Windows authentication and added a "web.config" to the root of my project. The following configuration will only enable Windows authentication for the specified location path.

<location path="api" >
    <system.webServer>
      <security>
        <authentication>
          <windowsAuthentication enabled="false" />
        </authentication>
      </security>
    </system.webServer>
  </location>

  <location path="api/account/login/windows">
    <system.webServer>
      <security>
        <authentication>
          <windowsAuthentication enabled="true" />
        </authentication>
      </security>
    </system.webServer>
  </location>

There's another thread on this I'll have to find. IIS Windows Auth does not compose well with others. 401 responses will have auth headers added automatically. This is the first workaround I've seen, good job.

We periodically close 'discussion' issues that have not been updated in a long period of time.
We apologize if this causes any inconvenience. We ask that if you are still encountering an issue, please log a new issue with updated information and we will investigate.


Parameters of the focal functional groups for which it is not reasonable to define a default value

@jhpoelen
This issue is somehow related to #114
For all of the following parameters - It is not reasonable to specify a default value for all the fish and invertebrates recorded in FishBase and SeaLifeBase:
(1) predation.accessibility.stage.threshold.sp*;
(2) predation.predPrey.stage.threshold.sp*;
(3) species.K.sp*;
(4) species.length2weight.allometric.power.sp*;
(5) species.length2weight.condition.factor.sp*;
(6) species.lifespan.sp*;
(7) species.lInf.sp*;
(8) species.maturity.size.sp*;
(9) species.maturity.age.sp*;
(10) species.relativefecundity.sp*;
(11) species.t0.sp*.
Therefore, the default values specified for the 11 abovementioned parameters in the “fishbase-mapping.csv” file should not be used by the API.
Here is what I would like you to implement when estimates are not available for all the species of a given focal functional group to derive a value for one of the 11 abovementioned parameters:
(1) Implementing a rule of thumb in the API such that the API uses information for the other species belonging to the genuses, families and orders to which the species of the focal functional group belong. (These other species can be found anywhere across the globe).
For the parameter of interest, the API would apply the “data richness” rules we discussed with Skit in #59  to produce an estimate for the focal functional group under consideration.
(2) If the API does not manage to obtain an estimate for the parameter of interest after having considered all the species belonging to the genuses, families and orders to which the species of the focal functional group belong -> Setting the value of the  parameter of interest to “NA” (not available).
Sorry, this issue is a little bit hard to formulate, so please let me know if anything here is unclear.
Many thanks for everything.

If I understand it correctly, you'd like to (a) extend the trait finding
algorithm and (b) introduce a way to explicitly state when values are
not available using "NA" (or some other "magic" value to identify a
value that is unavailable).
Item (b) can be introduced independent of (a).
About (a) - currently, ordered speccodes (species ids) are passed from
the wizard to the api. The api then retrieves relevant fishbase trait
archives and attempts to retrieve desired traits. If I understand it
correctly, you'd like to extend the ordered list (by decreasing
richness) for a functional group to include all speccode that shares a
genus, family or order with the species included in the functional
group. This extended list of speccodes can then be used to retrieve a
reasonable parameter value for a specific functional group.
Let's say that a functional group contains 20 species. Each of these
species have about 5 sibling species in genus, 20 in family, and 200 in
the order. Assuming that these counts are reasonable, and no taxononic
overlap between species exist, the list of species would turn to 20 * (5

20 + 200) ~ 5k speccodes per functional group (probably a conservative
estimate). With 10 functional groups, this would be 50k speccodes to be
scanned and examined in the worst case scenario.

Before I continue to thinking about ways to implement this, please
confirm that we are on the same page.

Note that currently, the api attempts to retrieve values associated to speccodes provided by UI in order. So, if the UI appends some more speccodes beyond the species explicitly mentioned in the functional group, the API should work as usual.

@jhpoelen
Here is what I think we could do.
Let’s say we are dealing with a functional group called “smallpelagics” and the parameter “relative fecundity”.
(1) For that “smallpelagics” functional group, the UI has identified, say, 20 species.
(2) Before passing information to the API, the UI appends to these 20 species: all the species that belong to the genuses, families and orders of the 20 species. Let’s say that this results in a list of 500 species in total (20 species + 480 appended species).
(3) When the API receives the list of 500 species from the UI, it first considers only the 20 species that belong to the “smallpelagics” functional group.
-> (i) Case 1: data are available to derive a value for the parameter “relative fecundity” for some of the 20 species that belong to the “smallpelagics” functional group. In that case, the “data richness” rule described in #59 is applied to derive a parameter estimate for the parameter “relative fecundity” for the “smallpelagics” functional group.
-> (ii) Case 2: data are not available to derive a value for the parameter “relative fecundity” for none of the 20 species that belong to the “smallpelagics” functional group. In that case, the API will consider the 480 appended species to see if it can derive a value for the parameter “relative fecundity”.
(4) If we have faced Case 2 above, then:
-> Case 1: data are available to derive a value for the parameter “relative fecundity” for some of the 480 appended species. In that case, the “data richness” rule described in #59 is applied to the list of 480 appended species to derive a parameter estimate for the parameter “relative fecundity” for the “smallpelagics” functional group.
-> (ii) Case 2: data are not available to derive a value for the parameter “relative fecundity” for none of the 480 appended species. In that case, the API will provide the value NA for the parameter “relative fecundity” for the “smallpelagics” functional group.
Does this sound good to you?
If so, could you please interact with Casey and Skit to implement what is described above?

@agruss2 Sounds good. As far as I am concerned, no changes are needed in the API - the API gets an ordered list of species for the specific groups and will work down the list until a specific parameter has been found.
@FIN-JBarile @FIN-casey suggest to extend the list of species in a functional group to include the species as described above by @agruss2 . Please let me know if you have any thoughts on this.

@FIN-casey @FIN-JBarile Please implement what is described above; and let me know when you think this issue has been solved so that I can run a new test with the bridge between FishBase/SeaLifeBase and OSMOSE. Many thanks.

Hi, @agruss2 , I would like to clarify some things. Shouldn't we have a maximum number of species for the extended list for every functional group? And how do we separate the list of species from the actual list and the extended list? I am planning to add the extended list in the json data before passing it to the API. The nodes of the functional group would be "name","type","taxa", and "othertaxa". The "othertaxa" will be the extended species list listing the name and the url of each of the species just like the format of the "taxa" node.
@jhpoelen, The above implementation requires some modification of the API. Please tell me if you think of a better implementation.

@FIN-casey
Here are my answers to your comments:
(1) I think that it would be better not to have a maximum number of species for the extended list for every functional group; this way, we would maximize the probability to obtain a value for parameters.
However, I guess that, for computional and practical reasons, you may want me to decide of a maximum number of species for the extended list for every functional group. Is this the case? If so, then please let me know and I'll provide you with a maximum number.
(2) You are right that we should think of a way to distinguish between the original list of species and the list of additional species. I think that distinguishing between "taxa" and "othertaxa" is an excellent idea. This way, the API will be able to work first with "taxa" only; and will then consider "othertaxa", if need be.
@jhpoelen Please see my comments above.
Could you please make sure that the "functional_groups.csv" file that is provided in the "osmose_config.zip" file lists only "taxa" (and, therefore, does not provide any information about "othertaxa").

@FIN-casey Rather than introducing othertaxa I'd like to suggest to introduce an attribute (or property) in the taxon object.
Currently, we have:
{
  ...
  "groups": [
    {
      "name": "Amberjacks",
      "type": "focal",
      "taxa": [
        {
          "name": "Seriola dumerili",
          "url": "http://fishbase.org/summary/1005"
        },
        {
          "name": "Seriola fasciata",
          "url": "http://fishbase.org/summary/1006"
        }
      ]
    }
    ...

For taxa related to the explicitly mentioned species in the functional groups, I'd label the taxon object with an optional property like "selectionCriteria" and value "implicit", "inferred" or "same genus". The (omitted) default value for "selectionCriteria" would be "exact".
So, including a related species by genus like Seriolina nigrofasciata (same genus, not exact match), would produce something like:
{
  ...
  "groups": [
    {
      "name": "Amberjacks",
      "type": "focal",
      "taxa": [
        {
          "name": "Seriola dumerili",
          "url": "http://fishbase.org/summary/1005"
        },
        {
          "name": "Seriola fasciata",
          "url": "http://fishbase.org/summary/1006"
        },
        {
          "name": "Seriolina nigrofasciata",
          "url": "http://fishbase.org/summary/1962",
          "selectionCriteria": "implicit"
        }
      ]
    }
    ...

This solution would make it easy to filter or otherwise transform/group taxa by their selection criteria and would require minimal changes to existing code.

@FIN-casey The order of the taxa in the group definition would determine the order in which they are considered. So, if you'd like to make sure to consider the implicitly selected taxa, then add them after the explicitly selected taxa.
Please confirm that this works for you.

On creating an osmose configuration for Iceland Shelf/Sea, I noticed that none of the extended taxa seem to make it into the request from the UI to the API (see below).
I've attached the resulting osmose config here: osmose_config (6).zip
@FIN-casey is there any thing the API needs to do to get access to the extended taxon list? If this is not yet implemented, I'd strongly suggest to use the method I suggested in https://github.com/jhpoelen/fb-osmose-bridge/issues/115#issuecomment-311122588 .
Please let me know if there's anything I missed.
This is what got sent from UI to API:
{
  "timeStepsPerYear": "12",
  "groups": [
    {
      "name": "fishpelagicsm",
      "type": "focal",
      "taxa": [
        {
          "name": "Mallotus villosus",
          "url": "http://fishbase.org/summary/252"
        },
        {
          "name": "Benthosema glaciale",
          "url": "http://fishbase.org/summary/21"
        },
        {
          "name": "Notoscopelus kroyeri",
          "url": "http://fishbase.org/summary/27753"
        }
      ]
    },
    {
      "name": "fishpelagicmd",
      "type": "focal",
      "taxa": [
        {
          "name": "Scomber scombrus",
          "url": "http://fishbase.org/summary/118"
        },
        {
          "name": "Sardina pilchardus",
          "url": "http://fishbase.org/summary/1350"
        },
        {
          "name": "Alosa fallax",
          "url": "http://fishbase.org/summary/5355"
        },
        {
          "name": "Trachurus trachurus",
          "url": "http://fishbase.org/summary/1365"
        },
        {
          "name": "Scomberesox saurus",
          "url": "http://fishbase.org/summary/1084"
        },
        {
          "name": "Schedophilus medusophagus",
          "url": "http://fishbase.org/summary/1721"
        }
      ]
    },
    {
      "name": "fishpelagiclg",
      "type": "focal",
      "taxa": [
        {
          "name": "Salmo trutta",
          "url": "http://fishbase.org/summary/238"
        },
        {
          "name": "Sebastes norvegicus",
          "url": "http://fishbase.org/summary/501"
        },
        {
          "name": "Belone belone",
          "url": "http://fishbase.org/summary/47"
        },
        {
          "name": "Brama brama",
          "url": "http://fishbase.org/summary/391"
        },
        {
          "name": "Mola mola",
          "url": "http://fishbase.org/summary/1732"
        },
        {
          "name": "Regalecus glesne",
          "url": "http://fishbase.org/summary/3267"
        }
      ]
    },
    {
      "name": "fishdemersalsm",
      "type": "focal",
      "taxa": [
        {
          "name": "Agonus cataphractus",
          "url": "http://fishbase.org/summary/36"
        },
        {
          "name": "Ammodytes tobianus",
          "url": "http://fishbase.org/summary/38"
        },
        {
          "name": "Liparis liparis",
          "url": "http://fishbase.org/summary/1378"
        },
        {
          "name": "Callionymus maculatus",
          "url": "http://fishbase.org/summary/1807"
        },
        {
          "name": "Ciliata mustela",
          "url": "http://fishbase.org/summary/1290"
        },
        {
          "name": "Ciliata septentrionalis",
          "url": "http://fishbase.org/summary/1873"
        },
        {
          "name": "Triglops murrayi",
          "url": "http://fishbase.org/summary/4146"
        },
        {
          "name": "Liparis montagui",
          "url": "http://fishbase.org/summary/1379"
        },
        {
          "name": "Micrenophrys lilljeborgii",
          "url": "http://fishbase.org/summary/9198"
        }
      ]
    },
    {
      "name": "fishdemersalmd",
      "type": "focal",
      "taxa": [
        {
          "name": "Eutrigla gurnardus",
          "url": "http://fishbase.org/summary/68"
        },
        {
          "name": "Callionymus lyra",
          "url": "http://fishbase.org/summary/23"
        },
        {
          "name": "Myoxocephalus scorpius",
          "url": "http://fishbase.org/summary/1329"
        },
        {
          "name": "Pholis gunnellus",
          "url": "http://fishbase.org/summary/3804"
        },
        {
          "name": "Lumpenus lampretaeformis",
          "url": "http://fishbase.org/summary/1380"
        },
        {
          "name": "Boreogadus saida",
          "url": "http://fishbase.org/summary/319"
        },
        {
          "name": "Enchelyopus cimbrius",
          "url": "http://fishbase.org/summary/1874"
        },
        {
          "name": "Hyperoplus lanceolatus",
          "url": "http://fishbase.org/summary/1374"
        },
        {
          "name": "Sebastes viviparus",
          "url": "http://fishbase.org/summary/1352"
        },
        {
          "name": "Entelurus aequoreus",
          "url": "http://fishbase.org/summary/67"
        },
        {
          "name": "Myxine glutinosa",
          "url": "http://fishbase.org/summary/2513"
        }
      ]
    },
    {
      "name": "fishdemersallg",
      "type": "focal",
      "taxa": [
        {
          "name": "Dicentrarchus labrax",
          "url": "http://fishbase.org/summary/63"
        },
        {
          "name": "Melanogrammus aeglefinus",
          "url": "http://fishbase.org/summary/1381"
        },
        {
          "name": "Pollachius virens",
          "url": "http://fishbase.org/summary/1343"
        },
        {
          "name": "Chelon labrosus",
          "url": "http://fishbase.org/summary/2499"
        },
        {
          "name": "Merluccius merluccius",
          "url": "http://fishbase.org/summary/30"
        },
        {
          "name": "Molva molva",
          "url": "http://fishbase.org/summary/33"
        },
        {
          "name": "Brosme brosme",
          "url": "http://fishbase.org/summary/51"
        },
        {
          "name": "Polyprion americanus",
          "url": "http://fishbase.org/summary/349"
        },
        {
          "name": "Petromyzon marinus",
          "url": "http://fishbase.org/summary/2530"
        },
        {
          "name": "Molva dypterygia",
          "url": "http://fishbase.org/summary/1383"
        },
        {
          "name": "Anarhichas lupus",
          "url": "http://fishbase.org/summary/2501"
        },
        {
          "name": "Conger conger",
          "url": "http://fishbase.org/summary/301"
        },
        {
          "name": "Anarhichas minor",
          "url": "http://fishbase.org/summary/3811"
        }
      ]
    },
    {
      "name": "fishbathypelagicsm",
      "type": "focal",
      "taxa": [
        {
          "name": "Myctophum punctatum",
          "url": "http://fishbase.org/summary/1328"
        },
        {
          "name": "Maurolicus muelleri",
          "url": "http://fishbase.org/summary/754"
        },
        {
          "name": "Argyropelecus hemigymnus",
          "url": "http://fishbase.org/summary/6968"
        },
        {
          "name": "Argyropelecus olfersii",
          "url": "http://fishbase.org/summary/5097"
        }
      ]
    },
    {
      "name": "fishbathypelagicmd",
      "type": "focal",
      "taxa": [
        {
          "name": "Hoplostethus atlanticus",
          "url": "http://fishbase.org/summary/334"
        },
        {
          "name": "Micromesistius poutassou",
          "url": "http://fishbase.org/summary/31"
        },
        {
          "name": "Sebastes mentella",
          "url": "http://fishbase.org/summary/505"
        },
        {
          "name": "Coryphaenoides mediterraneus",
          "url": "http://fishbase.org/summary/8175"
        },
        {
          "name": "Coryphaenoides brevibarbis",
          "url": "http://fishbase.org/summary/27726"
        }
      ]
    },
    {
      "name": "fishbathypelagiclg",
      "type": "focal",
      "taxa": [
        {
          "name": "Aphanopus carbo",
          "url": "http://fishbase.org/summary/646"
        },
        {
          "name": "Coryphaenoides rupestris",
          "url": "http://fishbase.org/summary/332"
        },
        {
          "name": "Lampris guttatus",
          "url": "http://fishbase.org/summary/1072"
        },
        {
          "name": "Trachipterus arcticus",
          "url": "http://fishbase.org/summary/3265"
        },
        {
          "name": "Centrolophus niger",
          "url": "http://fishbase.org/summary/249"
        },
        {
          "name": "Nemichthys scolopaceus",
          "url": "http://fishbase.org/summary/2660"
        },
        {
          "name": "Coryphaenoides armatus",
          "url": "http://fishbase.org/summary/5127"
        }
      ]
    },
    {
      "name": "fishbathydemersalmd",
      "type": "focal",
      "taxa": [
        {
          "name": "Argentina silus",
          "url": "http://fishbase.org/summary/2700"
        },
        {
          "name": "Argentina sphyraena",
          "url": "http://fishbase.org/summary/20"
        },
        {
          "name": "Coryphaenoides guentheri",
          "url": "http://fishbase.org/summary/8176"
        },
        {
          "name": "Echiodon drummondii",
          "url": "http://fishbase.org/summary/65"
        },
        {
          "name": "Careproctus reinhardti",
          "url": "http://fishbase.org/summary/15500"
        },
        {
          "name": "Bathysaurus ferox",
          "url": "http://fishbase.org/summary/11841"
        }
      ]
    },
    {
      "name": "fishbathydemersallg",
      "type": "focal",
      "taxa": [
        {
          "name": "Lophius piscatorius",
          "url": "http://fishbase.org/summary/716"
        },
        {
          "name": "Alepocephalus bairdii",
          "url": "http://fishbase.org/summary/230"
        },
        {
          "name": "Beryx decadactylus",
          "url": "http://fishbase.org/summary/1319"
        },
        {
          "name": "Chimaera monstrosa",
          "url": "http://fishbase.org/summary/2503"
        },
        {
          "name": "Synaphobranchus kaupii",
          "url": "http://fishbase.org/summary/9104"
        }
      ]
    },
    {
      "name": "fishbenthopelagicsm",
      "type": "focal",
      "taxa": [
        {
          "name": "Gasterosteus aculeatus",
          "url": "http://fishbase.org/summary/2420"
        },
        {
          "name": "Ammodytes marinus",
          "url": "http://fishbase.org/summary/37"
        }
      ]
    },
    {
      "name": "fishbenthopelagicmd",
      "type": "focal",
      "taxa": [
        {
          "name": "Clupea harengus",
          "url": "http://fishbase.org/summary/24"
        },
        {
          "name": "Merlangius merlangus",
          "url": "http://fishbase.org/summary/29"
        },
        {
          "name": "Pagellus bogaraveo",
          "url": "http://fishbase.org/summary/890"
        },
        {
          "name": "Trisopterus esmarkii",
          "url": "http://fishbase.org/summary/1023"
        },
        {
          "name": "Cyclopterus lumpus",
          "url": "http://fishbase.org/summary/62"
        },
        {
          "name": "Coelorinchus caelorhincus",
          "url": "http://fishbase.org/summary/1726"
        }
      ]
    },
    {
      "name": "fishbenthopelagiclg",
      "type": "focal",
      "taxa": [
        {
          "name": "Gadus morhua",
          "url": "http://fishbase.org/summary/69"
        },
        {
          "name": "Salmo salar",
          "url": "http://fishbase.org/summary/236"
        },
        {
          "name": "Salvelinus alpinus",
          "url": "http://sealifebase.org/summary/alpinus"
        },
        {
          "name": "Macrourus berglax",
          "url": "http://fishbase.org/summary/331"
        },
        {
          "name": "Pollachius pollachius",
          "url": "http://fishbase.org/summary/34"
        },
        {
          "name": "Phycis blennoides",
          "url": "http://fishbase.org/summary/1340"
        },
        {
          "name": "Anarhichas denticulatus",
          "url": "http://fishbase.org/summary/3810"
        },
        {
          "name": "Argyrosomus regius",
          "url": "http://fishbase.org/summary/418"
        },
        {
          "name": "Notacanthus chemnitzii",
          "url": "http://fishbase.org/summary/2661"
        }
      ]
    },
    {
      "name": "fishreefassociatedsm",
      "type": "focal",
      "taxa": [
        {
          "name": "Lebetus scorpioides",
          "url": "http://fishbase.org/summary/456"
        }
      ]
    },
    {
      "name": "fishsharksmmd",
      "type": "focal",
      "taxa": [
        {
          "name": "Etmopterus princeps",
          "url": "http://fishbase.org/summary/683"
        },
        {
          "name": "Etmopterus spinax",
          "url": "http://fishbase.org/summary/687"
        }
      ]
    },
    {
      "name": "fishsharklg",
      "type": "focal",
      "taxa": [
        {
          "name": "Lamna nasus",
          "url": "http://fishbase.org/summary/88"
        },
        {
          "name": "Squalus acanthias",
          "url": "http://fishbase.org/summary/139"
        },
        {
          "name": "Galeorhinus galeus",
          "url": "http://fishbase.org/summary/4642"
        },
        {
          "name": "Centrophorus squamosus",
          "url": "http://fishbase.org/summary/653"
        },
        {
          "name": "Cetorhinus maximus",
          "url": "http://fishbase.org/summary/90"
        },
        {
          "name": "Deania calcea",
          "url": "http://fishbase.org/summary/670"
        },
        {
          "name": "Somniosus microcephalus",
          "url": "http://fishbase.org/summary/138"
        },
        {
          "name": "Centroscymnus coelolepis",
          "url": "http://fishbase.org/summary/662"
        },
        {
          "name": "Centroscymnus crepidater",
          "url": "http://fishbase.org/summary/663"
        },
        {
          "name": "Dalatias licha",
          "url": "http://fishbase.org/summary/669"
        },
        {
          "name": "Hexanchus griseus",
          "url": "http://fishbase.org/summary/637"
        },
        {
          "name": "Centroscyllium fabricii",
          "url": "http://fishbase.org/summary/656"
        }
      ]
    },
    {
      "name": "fishraylg",
      "type": "focal",
      "taxa": [
        {
          "name": "Amblyraja radiata",
          "url": "http://fishbase.org/summary/2565"
        },
        {
          "name": "Dipturus batis",
          "url": "http://fishbase.org/summary/2058"
        },
        {
          "name": "Raja clavata",
          "url": "http://fishbase.org/summary/2059"
        },
        {
          "name": "Rajella lintea",
          "url": "http://fishbase.org/summary/6422"
        }
      ]
    },
    {
      "name": "fishflatfishsmmd",
      "type": "focal",
      "taxa": [
        {
          "name": "Hippoglossoides platessoides",
          "url": "http://fishbase.org/summary/4239"
        },
        {
          "name": "Glyptocephalus cynoglossus",
          "url": "http://fishbase.org/summary/26"
        },
        {
          "name": "Lepidorhombus whiffiagonis",
          "url": "http://fishbase.org/summary/28"
        },
        {
          "name": "Phrynorhombus norvegicus",
          "url": "http://fishbase.org/summary/2360"
        }
      ]
    },
    {
      "name": "fishflatfishlg",
      "type": "focal",
      "taxa": [
        {
          "name": "Pleuronectes platessa",
          "url": "http://fishbase.org/summary/1342"
        },
        {
          "name": "Scophthalmus maximus",
          "url": "http://fishbase.org/summary/1348"
        },
        {
          "name": "Hippoglossus hippoglossus",
          "url": "http://fishbase.org/summary/1371"
        },
        {
          "name": "Reinhardtius hippoglossoides",
          "url": "http://fishbase.org/summary/516"
        }
      ]
    },
    {
      "name": "cephalopods",
      "type": "focal",
      "taxa": [
        {
          "name": "Todarodes sagittatus",
          "url": "http://fishbase.org/summary/57559"
        },
        {
          "name": "Rossia macrosoma",
          "url": "http://fishbase.org/summary/57462"
        },
        {
          "name": "Sepiola atlantica",
          "url": "http://fishbase.org/summary/57471"
        },
        {
          "name": "Neorossia caroli",
          "url": "http://fishbase.org/summary/57324"
        }
      ]
    },
    {
      "name": "zooplankton",
      "type": "background",
      "taxa": []
    },
    {
      "name": "phytoplankton",
      "type": "background",
      "taxa": []
    }
  ]
}

@jhpoelen The inclusion of the extended list is not yet implemented. I
would follow your suggestion in implementing this. Hopefully we won't
encounter any limitation issues due to the large amount of data.
On Aug 16, 2017 5:53 AM, "Jorrit Poelen"<EMAIL_ADDRESS>wrote:

On creating an osmose configuration for Iceland Shelf/Sea, I noticed that
none of the extended taxa seem to make it into the request from the UI to
the API (see below).
I've attached the resulting osmose config here: osmose_config (6).zip
https://github.com/jhpoelen/fb-osmose-bridge/files/1226555/osmose_config.6.zip
@FIN-casey https://github.com/fin-casey is there any thing the API
needs to do to get access to the extended taxon list? If this is not yet
implemented, I'd strongly suggest to use the method I suggested in #115
(comment)
https://github.com/jhpoelen/fb-osmose-bridge/issues/115#issuecomment-311122588
.
Please let me know if there's anything I missed.
This is what got sent from UI to API:
{
"timeStepsPerYear": "12",
"groups": [
{
"name": "fishpelagicsm",
"type": "focal",
"taxa": [
{
"name": "Mallotus villosus",
"url": "http://fishbase.org/summary/252"
},
{
"name": "Benthosema glaciale",
"url": "http://fishbase.org/summary/21"
},
{
"name": "Notoscopelus kroyeri",
"url": "http://fishbase.org/summary/27753"
}
]
},
{
"name": "fishpelagicmd",
"type": "focal",
"taxa": [
{
"name": "Scomber scombrus",
"url": "http://fishbase.org/summary/118"
},
{
"name": "Sardina pilchardus",
"url": "http://fishbase.org/summary/1350"
},
{
"name": "Alosa fallax",
"url": "http://fishbase.org/summary/5355"
},
{
"name": "Trachurus trachurus",
"url": "http://fishbase.org/summary/1365"
},
{
"name": "Scomberesox saurus",
"url": "http://fishbase.org/summary/1084"
},
{
"name": "Schedophilus medusophagus",
"url": "http://fishbase.org/summary/1721"
}
]
},
{
"name": "fishpelagiclg",
"type": "focal",
"taxa": [
{
"name": "Salmo trutta",
"url": "http://fishbase.org/summary/238"
},
{
"name": "Sebastes norvegicus",
"url": "http://fishbase.org/summary/501"
},
{
"name": "Belone belone",
"url": "http://fishbase.org/summary/47"
},
{
"name": "Brama brama",
"url": "http://fishbase.org/summary/391"
},
{
"name": "Mola mola",
"url": "http://fishbase.org/summary/1732"
},
{
"name": "Regalecus glesne",
"url": "http://fishbase.org/summary/3267"
}
]
},
{
"name": "fishdemersalsm",
"type": "focal",
"taxa": [
{
"name": "Agonus cataphractus",
"url": "http://fishbase.org/summary/36"
},
{
"name": "Ammodytes tobianus",
"url": "http://fishbase.org/summary/38"
},
{
"name": "Liparis liparis",
"url": "http://fishbase.org/summary/1378"
},
{
"name": "Callionymus maculatus",
"url": "http://fishbase.org/summary/1807"
},
{
"name": "Ciliata mustela",
"url": "http://fishbase.org/summary/1290"
},
{
"name": "Ciliata septentrionalis",
"url": "http://fishbase.org/summary/1873"
},
{
"name": "Triglops murrayi",
"url": "http://fishbase.org/summary/4146"
},
{
"name": "Liparis montagui",
"url": "http://fishbase.org/summary/1379"
},
{
"name": "Micrenophrys lilljeborgii",
"url": "http://fishbase.org/summary/9198"
}
]
},
{
"name": "fishdemersalmd",
"type": "focal",
"taxa": [
{
"name": "Eutrigla gurnardus",
"url": "http://fishbase.org/summary/68"
},
{
"name": "Callionymus lyra",
"url": "http://fishbase.org/summary/23"
},
{
"name": "Myoxocephalus scorpius",
"url": "http://fishbase.org/summary/1329"
},
{
"name": "Pholis gunnellus",
"url": "http://fishbase.org/summary/3804"
},
{
"name": "Lumpenus lampretaeformis",
"url": "http://fishbase.org/summary/1380"
},
{
"name": "Boreogadus saida",
"url": "http://fishbase.org/summary/319"
},
{
"name": "Enchelyopus cimbrius",
"url": "http://fishbase.org/summary/1874"
},
{
"name": "Hyperoplus lanceolatus",
"url": "http://fishbase.org/summary/1374"
},
{
"name": "Sebastes viviparus",
"url": "http://fishbase.org/summary/1352"
},
{
"name": "Entelurus aequoreus",
"url": "http://fishbase.org/summary/67"
},
{
"name": "Myxine glutinosa",
"url": "http://fishbase.org/summary/2513"
}
]
},
{
"name": "fishdemersallg",
"type": "focal",
"taxa": [
{
"name": "Dicentrarchus labrax",
"url": "http://fishbase.org/summary/63"
},
{
"name": "Melanogrammus aeglefinus",
"url": "http://fishbase.org/summary/1381"
},
{
"name": "Pollachius virens",
"url": "http://fishbase.org/summary/1343"
},
{
"name": "Chelon labrosus",
"url": "http://fishbase.org/summary/2499"
},
{
"name": "Merluccius merluccius",
"url": "http://fishbase.org/summary/30"
},
{
"name": "Molva molva",
"url": "http://fishbase.org/summary/33"
},
{
"name": "Brosme brosme",
"url": "http://fishbase.org/summary/51"
},
{
"name": "Polyprion americanus",
"url": "http://fishbase.org/summary/349"
},
{
"name": "Petromyzon marinus",
"url": "http://fishbase.org/summary/2530"
},
{
"name": "Molva dypterygia",
"url": "http://fishbase.org/summary/1383"
},
{
"name": "Anarhichas lupus",
"url": "http://fishbase.org/summary/2501"
},
{
"name": "Conger conger",
"url": "http://fishbase.org/summary/301"
},
{
"name": "Anarhichas minor",
"url": "http://fishbase.org/summary/3811"
}
]
},
{
"name": "fishbathypelagicsm",
"type": "focal",
"taxa": [
{
"name": "Myctophum punctatum",
"url": "http://fishbase.org/summary/1328"
},
{
"name": "Maurolicus muelleri",
"url": "http://fishbase.org/summary/754"
},
{
"name": "Argyropelecus hemigymnus",
"url": "http://fishbase.org/summary/6968"
},
{
"name": "Argyropelecus olfersii",
"url": "http://fishbase.org/summary/5097"
}
]
},
{
"name": "fishbathypelagicmd",
"type": "focal",
"taxa": [
{
"name": "Hoplostethus atlanticus",
"url": "http://fishbase.org/summary/334"
},
{
"name": "Micromesistius poutassou",
"url": "http://fishbase.org/summary/31"
},
{
"name": "Sebastes mentella",
"url": "http://fishbase.org/summary/505"
},
{
"name": "Coryphaenoides mediterraneus",
"url": "http://fishbase.org/summary/8175"
},
{
"name": "Coryphaenoides brevibarbis",
"url": "http://fishbase.org/summary/27726"
}
]
},
{
"name": "fishbathypelagiclg",
"type": "focal",
"taxa": [
{
"name": "Aphanopus carbo",
"url": "http://fishbase.org/summary/646"
},
{
"name": "Coryphaenoides rupestris",
"url": "http://fishbase.org/summary/332"
},
{
"name": "Lampris guttatus",
"url": "http://fishbase.org/summary/1072"
},
{
"name": "Trachipterus arcticus",
"url": "http://fishbase.org/summary/3265"
},
{
"name": "Centrolophus niger",
"url": "http://fishbase.org/summary/249"
},
{
"name": "Nemichthys scolopaceus",
"url": "http://fishbase.org/summary/2660"
},
{
"name": "Coryphaenoides armatus",
"url": "http://fishbase.org/summary/5127"
}
]
},
{
"name": "fishbathydemersalmd",
"type": "focal",
"taxa": [
{
"name": "Argentina silus",
"url": "http://fishbase.org/summary/2700"
},
{
"name": "Argentina sphyraena",
"url": "http://fishbase.org/summary/20"
},
{
"name": "Coryphaenoides guentheri",
"url": "http://fishbase.org/summary/8176"
},
{
"name": "Echiodon drummondii",
"url": "http://fishbase.org/summary/65"
},
{
"name": "Careproctus reinhardti",
"url": "http://fishbase.org/summary/15500"
},
{
"name": "Bathysaurus ferox",
"url": "http://fishbase.org/summary/11841"
}
]
},
{
"name": "fishbathydemersallg",
"type": "focal",
"taxa": [
{
"name": "Lophius piscatorius",
"url": "http://fishbase.org/summary/716"
},
{
"name": "Alepocephalus bairdii",
"url": "http://fishbase.org/summary/230"
},
{
"name": "Beryx decadactylus",
"url": "http://fishbase.org/summary/1319"
},
{
"name": "Chimaera monstrosa",
"url": "http://fishbase.org/summary/2503"
},
{
"name": "Synaphobranchus kaupii",
"url": "http://fishbase.org/summary/9104"
}
]
},
{
"name": "fishbenthopelagicsm",
"type": "focal",
"taxa": [
{
"name": "Gasterosteus aculeatus",
"url": "http://fishbase.org/summary/2420"
},
{
"name": "Ammodytes marinus",
"url": "http://fishbase.org/summary/37"
}
]
},
{
"name": "fishbenthopelagicmd",
"type": "focal",
"taxa": [
{
"name": "Clupea harengus",
"url": "http://fishbase.org/summary/24"
},
{
"name": "Merlangius merlangus",
"url": "http://fishbase.org/summary/29"
},
{
"name": "Pagellus bogaraveo",
"url": "http://fishbase.org/summary/890"
},
{
"name": "Trisopterus esmarkii",
"url": "http://fishbase.org/summary/1023"
},
{
"name": "Cyclopterus lumpus",
"url": "http://fishbase.org/summary/62"
},
{
"name": "Coelorinchus caelorhincus",
"url": "http://fishbase.org/summary/1726"
}
]
},
{
"name": "fishbenthopelagiclg",
"type": "focal",
"taxa": [
{
"name": "Gadus morhua",
"url": "http://fishbase.org/summary/69"
},
{
"name": "Salmo salar",
"url": "http://fishbase.org/summary/236"
},
{
"name": "Salvelinus alpinus",
"url": "http://sealifebase.org/summary/alpinus"
},
{
"name": "Macrourus berglax",
"url": "http://fishbase.org/summary/331"
},
{
"name": "Pollachius pollachius",
"url": "http://fishbase.org/summary/34"
},
{
"name": "Phycis blennoides",
"url": "http://fishbase.org/summary/1340"
},
{
"name": "Anarhichas denticulatus",
"url": "http://fishbase.org/summary/3810"
},
{
"name": "Argyrosomus regius",
"url": "http://fishbase.org/summary/418"
},
{
"name": "Notacanthus chemnitzii",
"url": "http://fishbase.org/summary/2661"
}
]
},
{
"name": "fishreefassociatedsm",
"type": "focal",
"taxa": [
{
"name": "Lebetus scorpioides",
"url": "http://fishbase.org/summary/456"
}
]
},
{
"name": "fishsharksmmd",
"type": "focal",
"taxa": [
{
"name": "Etmopterus princeps",
"url": "http://fishbase.org/summary/683"
},
{
"name": "Etmopterus spinax",
"url": "http://fishbase.org/summary/687"
}
]
},
{
"name": "fishsharklg",
"type": "focal",
"taxa": [
{
"name": "Lamna nasus",
"url": "http://fishbase.org/summary/88"
},
{
"name": "Squalus acanthias",
"url": "http://fishbase.org/summary/139"
},
{
"name": "Galeorhinus galeus",
"url": "http://fishbase.org/summary/4642"
},
{
"name": "Centrophorus squamosus",
"url": "http://fishbase.org/summary/653"
},
{
"name": "Cetorhinus maximus",
"url": "http://fishbase.org/summary/90"
},
{
"name": "Deania calcea",
"url": "http://fishbase.org/summary/670"
},
{
"name": "Somniosus microcephalus",
"url": "http://fishbase.org/summary/138"
},
{
"name": "Centroscymnus coelolepis",
"url": "http://fishbase.org/summary/662"
},
{
"name": "Centroscymnus crepidater",
"url": "http://fishbase.org/summary/663"
},
{
"name": "Dalatias licha",
"url": "http://fishbase.org/summary/669"
},
{
"name": "Hexanchus griseus",
"url": "http://fishbase.org/summary/637"
},
{
"name": "Centroscyllium fabricii",
"url": "http://fishbase.org/summary/656"
}
]
},
{
"name": "fishraylg",
"type": "focal",
"taxa": [
{
"name": "Amblyraja radiata",
"url": "http://fishbase.org/summary/2565"
},
{
"name": "Dipturus batis",
"url": "http://fishbase.org/summary/2058"
},
{
"name": "Raja clavata",
"url": "http://fishbase.org/summary/2059"
},
{
"name": "Rajella lintea",
"url": "http://fishbase.org/summary/6422"
}
]
},
{
"name": "fishflatfishsmmd",
"type": "focal",
"taxa": [
{
"name": "Hippoglossoides platessoides",
"url": "http://fishbase.org/summary/4239"
},
{
"name": "Glyptocephalus cynoglossus",
"url": "http://fishbase.org/summary/26"
},
{
"name": "Lepidorhombus whiffiagonis",
"url": "http://fishbase.org/summary/28"
},
{
"name": "Phrynorhombus norvegicus",
"url": "http://fishbase.org/summary/2360"
}
]
},
{
"name": "fishflatfishlg",
"type": "focal",
"taxa": [
{
"name": "Pleuronectes platessa",
"url": "http://fishbase.org/summary/1342"
},
{
"name": "Scophthalmus maximus",
"url": "http://fishbase.org/summary/1348"
},
{
"name": "Hippoglossus hippoglossus",
"url": "http://fishbase.org/summary/1371"
},
{
"name": "Reinhardtius hippoglossoides",
"url": "http://fishbase.org/summary/516"
}
]
},
{
"name": "cephalopods",
"type": "focal",
"taxa": [
{
"name": "Todarodes sagittatus",
"url": "http://fishbase.org/summary/57559"
},
{
"name": "Rossia macrosoma",
"url": "http://fishbase.org/summary/57462"
},
{
"name": "Sepiola atlantica",
"url": "http://fishbase.org/summary/57471"
},
{
"name": "Neorossia caroli",
"url": "http://fishbase.org/summary/57324"
}
]
},
{
"name": "zooplankton",
"type": "background",
"taxa": []
},
{
"name": "phytoplankton",
"type": "background",
"taxa": []
}
]
}
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/jhpoelen/fb-osmose-bridge/issues/115#issuecomment-322600357,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AReVf3fQBSpslBUkaUwbJ1knzFOxnoLXks5sYhNEgaJpZM4Nm9A2
.

@FIN-casey Thanks for your comment that helps explain why @agruss2 does not see the expected behavior. Assigning issue to you.

@agruss2 @jhpoelen , I implemented the inclusion of "implicit" species in the  data sent to the API. The implementation is now in the wizard. Can you please verify and test the changes?
Thanks.
Please take note that there is a delay in showing the message "Preparing configuration..." after clicking Submit.

@FIN-casey @jhpoelen I just ran a test and I can confirm that the implementation is successful; many thanks Casey! Therefore, I am going to close the present issue.
However, please note that I see some potential areas of improvement. Therefore, I will soon create new GitHub issues to address some minor problems.

@FIN-casey @agruss2 good the hear that the parameter estimation using the implicit groups is now working as expected. Thanks for fixing and testing!

@jhpoelen @FIN-casey
I am reopening this issue, because I am still having a few NAs here and there for focal functional groups.
Therefore, I think that, for each functional group, we should increase the number of species that the bridge between FishBase/SeaLifeBase and OSMOSE considers in addition to the species making up the functional groups.
How many additional species does the bridge currently consider for each focal functional group?
How much could we increase that number without making the bridge crash?
Many thanks.

@agruss2 the API does not control the amount of taxa that are associated with focal/background functional groups. This is why I consider this a UI issue.
Same applies to #114 .


Update to Astro 3.3

Closing issues
Closes FRONT-4353
Description
Updates Astro to 3.3.2 (currently on 2.10.15). This requires our deployment server to be running at least Node 18.14.1.

Found a bug with global style files not being included on build specifically, working on fixing now

Having trouble using ViewTransition because the AI search styling breaks for some unknown reason


Cannot open merge conflicted file

Does this issue occur when all extensions are disabled?: Yes/No

VS Code Version: <IP_ADDRESS>
OS Version: macOS 12.01

Steps to Reproduce:

select a branch to merge from
perform merge
some files cannot be opened with following error:

Cannot read property 'scheme' of null: TypeError: Cannot read property 'scheme' of null
at yi.resolveEditor (vscode-file://vscode-app/Applications/Visual%20Studio%20Code.app/Contents/Resources/app/out/vs/workbench/workbench.desktop.main.js:1482:5955)
at M.openEditor (vscode-file://vscode-app/Applications/Visual%20Studio%20Code.app/Contents/Resources/app/out/vs/workbench/workbench.desktop.main.js:2360:24395)
at vscode-file://vscode-app/Applications/Visual%20Studio%20Code.app/Contents/Resources/app/out/vs/workbench/workbench.desktop.main.js:2323:55747
at y.invokeFunction (vscode-file://vscode-app/Applications/Visual%20Studio%20Code.app/Contents/Resources/app/out/vs/workbench/workbench.desktop.main.js:574:319)
at y._tryExecuteCommand (vscode-file://vscode-app/Applications/Visual%20Studio%20Code.app/Contents/Resources/app/out/vs/workbench/workbench.desktop.main.js:1482:3496)
at vscode-file://vscode-app/Applications/Visual%20Studio%20Code.app/Contents/Resources/app/out/vs/workbench/workbench.desktop.main.js:1482:3245
at async Tt.open (vscode-file://vscode-app/Applications/Visual%20Studio%20Code.app/Contents/Resources/app/out/vs/workbench/workbench.desktop.main.js:2331:50361) - log.ts.313

Does this issue occur when all extensions are disabled?: Yes/No

/needsMoreInfo