CEH v12

The PDF is not having all the modules.  Please do the needful.  I am able to get up to 273 pages.

There have 20 modules check correctly then tell me ok.
Sent with Proton Mail secure email.
------- Original Message -------
On Saturday, September 9th, 2023 at 08:02, wiprudu @.***> wrote:

The PDF is not having all the modules. Please do the needful.

—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.[https://mail.proton.me/api/core/v4/images?Url=https%3A%2F%2Fgithub.com%2Fnotifications%2Fbeacon%2FA4V6ON7YN2DDSGKCSNNJEK3XZPIM3A5CNFSM6AAAAAA4REBXUKWGG33NNVSW45C7OR4XAZNFJFZXG5LFVJRW63LNMVXHIX3JMTHHBEHFKE.gif&DryRun=0&UID=ou4qxulkbxxxgxyg4uvnszza6bgg4mmz]

Till now no respond from you. any issue then tell me.
Sent with Proton Mail secure email.
------- Original Message -------
On Saturday, September 9th, 2023 at 08:06, @.*** @.***> wrote:

There have 20 modules check correctly then tell me ok.

Sent with Proton Mail secure email.

------- Original Message -------
On Saturday, September 9th, 2023 at 08:02, wiprudu @.***> wrote:

The PDF is not having all the modules. Please do the needful.

—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.[https://mail.proton.me/api/core/v4/images?Url=https%3A%2F%2Fgithub.com%2Fnotifications%2Fbeacon%2FA4V6ON7YN2DDSGKCSNNJEK3XZPIM3A5CNFSM6AAAAAA4REBXUKWGG33NNVSW45C7OR4XAZNFJFZXG5LFVJRW63LNMVXHIX3JMTHHBEHFKE.gif&DryRun=0&UID=ou4qxulkbxxxgxyg4uvnszza6bgg4mmz]


Cow: Watch doc2lang.com

Cow requests the watch of the watch_keyword doc2lang\.com. See the MS search here and the Stack Exchange search in text, in URLs, and in code.

doc2lang\.com has been seen in 1 true positive, 0 false positives, and 0 NAAs.

Approved by tripleee in Charcoal HQ


Add ability to change the text size for quotes. Also moving the JSON stuff

What?
Adding a size slider for quotes, as sometimes quotes get a little bit too big/long. Not sure how canon-adherent this is, but I frequently do this manually for song quotes (as shown in the testing images).
Also moving quote rendering to common-after and adding some configs to it.
Also moving the JSON parse stuff to common-after in order to enable it across all pages. I should update the fields on this.
Uhhh, I probably should have broken this PR up to two chunks. Oops.
How was this tested?

Reviewers
@Colcoction @alexdarling @Fosuke

Following discussion in discord, moving the quote size slider to Advanced Formatting


support labels for app-groups

Describe the problem/challenge you have
We like to annotate certain apps in order to filter them later for cleanup.
I see that kapp deploy --labels ... is supported, but that flag is not available under kapp app-group deploy.
Background:
We like to run a cronjob that removes test deployments that are older than a week, keeping production deployments.
Devs are able to create preview deployments for acceptance test, but if they forget to clean them up they keep lingering and filling up the cluster. We cannot simply remove the namespace, we need to filter on apps.
So something like an annotation or label I assume could do the trick to mark production type apps, but this is not supported with app-groups
Describe the solution you'd like
adding labels for app-group deployments like it is available for normal deployment
Anything else you would like to add:
Assuming label is applied, what are your steps in finding them (by label and age) and deleting them?

https://kubernetes.slack.com/archives/CH8KCCKA5/p1637229778419800

Two feature set

add label on app-group command (only deploy)
add --filter-label and --filter-age flag for list (kapp ls) command.
Ideally, user should be able to
kapp deploy --labels dev=yes
...
kapp ls --filter-labels dev=yes --filter-age ... --column name | xargs -I{} kapp delete -a {}

Hi @universam1 ,
This looks like a valid ask. We will add it to our unprirotized backlog. However, if you want to take up the issue and submit a PR for the same, we would love to help you out with reviews and pointers for code change!

@cppforlife , do you think it would be a good Idea to add --show-labels flag, on the kapp ls command.
@sethiyash , @rohitagg2020
If yes, then If there are multiple labels, how do show all the labels in the table.

Release v0.46.0


fix(release): use placeholder changelog entry when changelog file does not exist

Fixes an issue where if an extension does not have a CHANGELOG.md file the script would error and exit (example).

Additionally made the following changes (see individual commits):

formatted the script
removed temporary version skipping logic as it's now no longer required as each extension has since had a release.

Testing
Tested all 3 scenarios (release already exists, changelog could not be found, new release):

Testing releases can be seen here: https://github.com/invertase/extensions-release-testing/releases

Codecov Report

Merging #451 into next will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##             next     #451   +/-   ##
=======================================
  Coverage   41.58%   41.58%
=======================================
  Files          30       30
  Lines        1128     1128
  Branches      154      154
=======================================
  Hits          469      469
  Misses        653      653
  Partials        6        6


Query parameters construct like ?message= doesn't work

@app.route('/hello/?message=')
def hello(name, msg):
return "Hello " + name + "! Message is " + msg + "."
the above sample does not work...  knowledgeable people tell me that query parameters construct like ?message= can't be used for that...
documentation on https://flask.palletsprojects.com/en/1.1.x/ also does not mention that.
:-)

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

ID: 7542d51c-4ba4-db5d-cd34-4517779684a8
Version Independent ID: ef7b3a39-814e-9c56-c2e1-6611464aa650
Content: Learn Flask tutorial in Visual Studio step 1, Flask basics
Content Source: docs/python/learn-flask-visual-studio-step-01-project-solution.md
Product: visual-studio-windows
Technology: vs-python
GitHub Login: @JoshuaPartlow
Microsoft Alias: joshuapa

@gjuwindev -- Gjuro, thank you for your feedback.  Please consider these resources as well:

Visual Studio on Q&A
Visual Studio MSDN Forum
Stack Overflow
Reddit


Error when Starting Kong API

Please read the CONTRIBUTING.md guidelines to learn on which channels you can
seek for help and ask general questions:
https://github.com/Kong/kong/blob/master/CONTRIBUTING.md#where-to-seek-for-help
Summary
When I start the kong, it gives me error message below:
SUMMARY_GOES_HERE
ERROR: /usr/local/share/lua/5.1/kong/cmd/utils/nginx_signals.lua:16: attempt to call field 'set' (a nil value)
stack traceback:
[C]: in function 'require'
/usr/local/share/lua/5.1/kong/cmd/utils/prefix_handler.lua:22: in main chunk
[C]: in function 'require'
/usr/local/share/lua/5.1/kong/cmd/start.lua:2: in main chunk
[C]: in function 'require'
/usr/local/share/lua/5.1/kong/cmd/init.lua:55: in function </usr/local/share/lua/5.1/kong/cmd/init.lua:45>
/usr/local/bin/kong:7: in function 'file_gen'
init_worker_by_lua:49: in function <init_worker_by_lua:47>
[C]: in function 'xpcall'
init_worker_by_lua:56: in function <init_worker_by_lua:54>
ANY HELP will be appricated! THANK U GUYS.
Steps To Reproduce

I tried to drop the database and create a new one, but it doesn't work.

Additional Details & Logs

Kong version (1.1.2)
Kong debug-level startup logs ($ kong start --vv)
Kong error logs (<KONG_PREFIX>/logs/error.log)
Kong configuration (the output of a GET request to Kong's Admin port - see
https://docs.konghq.com/latest/admin-api/#retrieve-node-information)
Operating system
ubuntu 18.4

Hi @Danni-Ke,
Could you provide us with more information - the configuration you are using and a step-by-step on how to reproduce the issue? Also, how did you install Kong - was it using our official Ubuntu repository?

Hi @Danni-Ke,
Could you provide us with more information - the configuration you are using and a step-by-step on how to reproduce the issue? Also, how did you install Kong - was it using our official Ubuntu repository?

hi！What I did just start a new database on my vitual machine(Ubuntu), then I download the file on the official page of kong according to my ubuntu version. Then I use the kong.conf.default as the my argument of the database migrations command and start command.

@Danni-Ke,
I'm not able to reproduce the issue.
Check if the user you are running Kong with has write permissions over the Kong prefix (which by default is /usr/local/kong). From the error message it's unlikely that this is the root cause, but worth checking.
Closing the issue, but do feel free to reopen if you have more information.


Event Template Design Review

Objective
Meet with the events team to review content and design
Tasks

[x] Meet with James to ensure event content & design aligns with current content model
[x] Meet with Access events team (Orla)
[x] Meet with General Public events team (Natalie, Val)
[ ] Meet with Library events team (Danny, Ross)
[ ] Meet with Youth events team (Catherine Ayres)
[ ] Summarise findings and update design

Feedback from Access events team

Need to consider for general events with accessibility
Provide more prominence to the booking type (Drop in, Ticketed)
Provide clear messaging for first come/first serve
Prefer to include the access type (BSL, AD, STT) in the event title

Feedback from General Public event team (Natalie and Val)

Reading room events will continue to be announced on the day of the event onsite and won't be publicised on the website
Would like to review event types (Heesoo to send current list)
Location is useful. However, it needs to be optional since they may not have the info upfront.
Not sure about displaying the pricing up front. Explore different treatment.
Would like to see some guidelines around optimal amount and content for event summary and description.
Booking T&C should be either displayed on the page or easy to access
Access to past events and the media can be useful for giving visitors what to expect from an event.
Some events have Facebook page and need to include a link
What's on newsletter will cover more general updates. Need to follow up about the long term plan of the newsletter strategy.

@jamesgorrie Here are the updated version of Youth, Access and General Public events based on our conversation.

@jamesgorrie One thing to consider. Long content makes it harder to discover 'Enquire to Book' CTA especially on mobile. I wonder whether we can explore ways to display the button on the bottom like the sticky nav on digital stories.

@Heesoomoon Or have it at places that are natural i.e. after integral info etc.
Sticky is a bad experience for anyone with a shorter mobile.

@jamesgorrie Let's assess the location of the CTA with the current content as is and define the integral info. FYI, Eventbrite uses sticky button.

Feedback from Youth Programme team

2 types of events: School events which need to be booked by the teacher (Study day) and Youth events
Events are announced in 3 months chunks (15 Study day, 3 Saturday studio and additional student events)
Announce through email and social media
Potentially need to separate into two different event types (School Programme and Youth Programme) and consider revisiting the booking info copy
Need to support ways to display fully booked flag for individual event
Separate email newsletter for School and Youth programme

Feedback from Library team (Danny and Ross)

Library Insights events are publicised online
Library Seminar events will not be promoted online and continue to be emailed to the partner organisations.
No library specific newsletter


hpet: make it support EHL/PSE CPU

Change to 64-bit mode for better usages.
Add Kconfig option to change min_delay and clock period.
Add Kconfig option to set interrupt as level triggered for ARM CPUs
with NVIC, whose DTS interrupts setting has no "sense" cell.
Make the change of HPET comparator register as a weak function, which
could be overwritten by EHL/PSE CPU to implement its special operations.

Signed-off-by: Dong Wang<EMAIL_ADDRESS>

@kwd-doodling could you fix the merge conflicts? They were introduced since the PR from @dcpleung was merged.

I've enabled this driver on both ISH and PSE and made it pass all timer tests.
until now only the comparator_set function is MUST to overwrite.
Timer configuration is WA by configuring only once.
if not doing so, I need to copy all of them into SoC layer.
But I think it's good to keep them still as functions to move into SoC layer when needed.

@tbursztyka @dcpleung can you review again? Thanks.

My previous comment still stands.
@dcpleung experiments on ISH and PSE show that only one of the functions is necessary. if keeping your code, I need to exactly copy all other functions into soc.h. It seems not good.

On which ISH version have you tried?

tried on ISH Chrome code base by switching zephyr to v2.6-branch. I've sent you an email to describe the steps.


Pulsar C++/Python consumer performance issue, if producing message in batch mode, consuming ACK in single mode

Expected behavior
Pulsar C++/Python client consuming  performance should keep at a stable level;
Actual behavior
Pulsar C++/Python client consuming  performance  downgrade obviously;
Steps to reproduce

Producing messages in batch mode (locally with batch count as 1000);
Consuming messages with ACK in single mode (as appose to the cumulative mode) with C++ or Python clients;
Keep the consuming process running for a while (say, with producing message 5000-8000 per second, run at least 15 minutes) and see the consuming messages per seconds, it downgrades very obviously; At the same time, the Pulsar Java client consuming performance could keep in a stable level.
See the attached monitor screen below:

System configuration
org.apache.pulsar:pulsar-client-cpp: 2.2.0

This issue is led by a mistake in pulsar-client-cpp/BatchAcknowledgementTracker.cc.

This is fixed in master https://github.com/apache/pulsar/pull/3618

closed the issue as #3618 fixed it.
@easyfan #3618 would be released as part of 2.3.1 and 2.4.0. you can check it out when 2.3.1 is release. if it happens again, please reopen the issue or create a new one.


Vite Server Headers not Available in Production.

Environment

Operating System: Linux
Node Version:     v20.8.1
Nuxt Version:     3.8.2
CLI Version:      3.10.0
Nitro Version:    2.8.1
Package Manager<EMAIL_ADDRESS>Builder:          -
User Config:      devtools, security, modules, css, app, runtimeConfig, routeRules, vite
Runtime Modules<EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS>Build Modules:    -

Reproduction
Setup a Nuxt project and add the following to your nuxt.config.ts:
vite: {    server: {         headers: {           "Access-Control-Allow-Origin": "*",           "Cross-Origin-Embedder-Policy": "require-corp",           "Cross-Origin-Opener-Policy": "same-origin"         },       },   },
Setup some html files in your public folder that may requires SharedArrayBuffer (it doesn't matter though). As long as you can check their response headers.
Describe the bug
While developing my local resources contained in the public folder provides "Cross-Origin-Embedder-Policy": "require-corp",  "Cross-Origin-Opener-Policy": "same-origin" header responses, but in production the vite config doesn't seem to be applicable as the headers are no longer present.
Additional context
Thanks and if it's a mistake on my part let me know.
Logs
No response

Because there is no vite server running in production ☺
You can use route rules instead!
export default defineNuxtConfig({
  routeRules: {
    '/**': {
      headers: {
        'Access-Control-Allow-Origin': '*',
        'Cross-Origin-Embedder-Policy': 'require-corp',
        'Cross-Origin-Opener-Policy': 'same-origin',
      },
    },
  },
});

Thanks, I tried running it on my local machine earlier it didn't work, I never considered it being a production feature. For now I'll use both the vite.option as well as the routerules for both local and production. Once again thank you.

routeRules should also work locally! 👌🏻


Add variables setup

Description
Supersedes #371
This PR adds a more full featured version of the variables infrastructure. It adds two registries, one containing all the known variables based on the modules that are being used in the simulation and another one for runtime variables that are actually being used by the requested models.
Each variable can be initialised by one single model and can be updated (with a warning) and used by more than one model. Who initialises, updates and use each variable is added to the relevant attributes of each variable.
The availability of the axis each variable requires is also validated.
What is known to be wrong or missing
At the moment, we use the models required_init_vars to decide which variable is initialised by each model, but that is not what required_init_vars represents, but rather what variable needs to be in the data object to be able to initialise the model. So, in reality, they are more like vars_used, a new attribute that needs to be populated for each model. Likewise, the vars_updated might actually be more closely related to what the model is initialising, although maybe not in all cases.
Keeping this confusion aside, all models (including the core ones) will need to define their own variable.py module with the relevant variables. An example for one variable used by the plants model is included to show how that needs to be done. To implement that, it might be easier if each of you create such a variable module for each of your models and open a PR against this one.
Needless to say, tests and docs need to be implemented. That will be done once we are happy with the implementation. Until all the above is sorted, test will fail, naturally.
Fixes # (issue) - partly addresses #371
Type of change

[ ] New feature (non-breaking change which adds functionality)
[ ] Optimization (back-end change that speeds up the code)
[ ] Bug fix (non-breaking change which fixes an issue)
[x] Breaking change

Key checklist

[x] Make sure you've run the pre-commit checks: $ pre-commit run -a
[ ] All tests pass: $ poetry run pytest

Further checks

[x] Code is commented, particularly in hard-to-understand areas
[ ] Tests added that prove fix is effective or that feature works

Ok @davidorme , I've done a few changes following your comments:

ALL existing variables within the models folder are now registered in the KNOWN_VARIABLES registry. This is populated before any configuration takes place.
A function that outputs this registry to a file has also been included. Where/when to run that is up to you. I'm not sure if you want to do it manually from time to time or automatically when docs/source/conf.py is run.
A function has been added that discovers ALL models and pulls from them the different usages of the variables. This MUST NOT be run at runtime since it defeats the purpose of having a way of identifying unfeasible configurations. At the moment is run only when outputting the registry.

There's still the issue of identifying the different types of vars (linked to #349), but it will be good to have your feedback on this.

Ok, I've added a few things. Now the models need to define 4 groups of variables:

Required to be initialised
The ones they initialise
Required to be updated
The ones they update

There is no distinction on where the variables required for initialisation are coming from.
These are all pull into the information for each variable, populating the relevant fields. Additionally, the variables available in the data object just after loading the data are also pulled into the registry before a verification of the consistency of the models based on the variables they require and provide is run.
There might be a few loose ends and I'm sure that some things will fail, but this is just a start.

OK - so we're now at the point where the ve_run tests are failing because the variable registries aren't being populated because the models haven't set up their variables.py files.
So, I think the implementation looks sound and  the next steps are:

[ ] Update each model to create and populate variables.py
[ ] Adapt the model variable attributes to the new system.
[ ] Add output_known_variables to the Sphinx conf.py and get it rendered in the docs.
[ ] Tests... could be a pain because the whole discovery system is so interlinked.

We can't merge until those are done, right?

That's correct - we cannot merge this until all the models are adapted to, at least, populate the variables registry. Using the registry can be done afterwards. I'd suggest each of you take care of writing the variables for their own models to distribute the effort.
I can tackle the last two. I might modify a bit the functions to make them more testable. As you said, dealing with the global state can be a pain.

Apologies for the very late reply.
As far as I can tell, this all makes sense and it does exactly what we asked for.
Could you please give an example for what adding a variable to variable.py should look like, then I will contribute the variables from the abiotic, abiotc_simple, and hydrology model.

Apologies for the very late reply. As far as I can tell, this all makes sense and it does exactly what we asked for. I will contribute the variables from the abiotic, abiotic_simple, and hydrology model soon.

@dalonsoa can I just double check which variables to include here, the ones required for init and update as well as the ones that the model initialises and updates?

Apologies for the very late reply. As far as I can tell, this all makes sense and it does exactly what we asked for. I will contribute the variables from the abiotic, abiotic_simple, and hydrology model soon.

@dalonsoa can I just double check which variables to include here, the ones required for init and update as well as the ones that the model initialises and updates?

Only those the model initialises. Those that the model updates should have been defined somewhere else...

OK, so now the variables are defined all together in a toml file in the root of virtual_ecosystem and the KNOWN_VARIABLES registry is taken from there. The rest is the same.
Following @davidorme list above, the next steps would be:

[ ] Update each model definition with the appropriate variables (required_init_vars, vars_updated, required_update_vars and vars_initialised.
[ ] Adapt the model variable attributes to use the new system.
[ ] Add output_known_variables to the Sphinx conf.py and get it rendered in the docs.
[ ] Tests... could be a pain because the whole discovery system is so interlinked.

Codecov Report
Attention: Patch coverage is 97.48428% with 4 lines in your changes are missing coverage. Please review.

Project coverage is 94.58%. Comparing base (1be161c) to head (b99cb52).

Files
Patch %
Lines

virtual_ecosystem/core/variables.py
97.31%
4 Missing :warning:

Additional details and impacted files
@@             Coverage Diff             @@
##           develop     #388      +/-   ##
===========================================
+ Coverage    94.45%   94.58%   +0.12%
===========================================
  Files           68       69       +1
  Lines         3555     3714     +159
===========================================
+ Hits          3358     3513     +155
- Misses         197      201       +4

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.

OK, so a brief update on this:

I've added the tests - some might need tweaking later on.
Updated the list of variables currently needed by the existing models, but these will need your input/update to provide the right description, units and axis.
Pull the known variables into a file and render it as a table. I think a tabular format makes sense considering the nature of the list, the the rendering is pretty bad as the table is too wide and one neds to scroll sidewise. Any suggestion on this would be most welcomed - as well as to avoid creating the intermediate CSV file.

I must also mention that the instructions to build the documentation are not that robust (they don't work for me in Windows). I'd suggest updating them to:
poetry run sphinx-build docs/source docs/build

I've added this branch to the RTD build list so we can see how it renders:
https://virtual-ecosystem.readthedocs.io/en/variables_1/

Oh god, we really need to figure out how to simplify the auto expanding signatures:
https://virtual-ecosystem.readthedocs.io/en/variables_1/api/core/variables.html#virtual_ecosystem.core.variables.KNOWN_VARIABLES

Wow! how does it know the contents of those dictionaries???

I think this is because sphinx.ext.autodoc is dynamic - it actively has to import the virtual_ecosystem package. I've been idly looking at autodoc2 because it supports MyST in docstrings and that uses a static approach. But I think there must be options.
We get the same kind of spam with the constants classes, so hopefully we can solve both with one setting.

I've implemented an alternative way of displaying the variables, just below the tabular data:
https://virtual-ecosystem.readthedocs.io/en/variables_1/virtual_ecosystem/variables.html#aerodynamic-resistance-surface
Ignore the code to do that - it is quick and dirty - and just check if this form seems more readable and useful.

I don't think we worry too much about the rendering now. The table is a pain because of the scroll bar, so I think that new layout is easier to search. It would be good to add sorting and filtering to allow people to see what variables come with which model, but that's a whole HTML and probably JS interface, but that's a new PR.
I think we could also add a PR to put a new entry point providing a tool that takes a list of models and spits out a data config TOML template with the required input variables for those models and path placeholders to be filled in.

Ok, so I'm going to tidy up the code and then make a list of specific things to do by all of you, contributing to this branch, so we have the models defined in such a way that the the variables registries are populated properly.

The documentation building is failing because of something happening in this block (that I have not touched) but other than that, this is ready to be contributed to.
Next steps:

Branch off the branch of this PR, variables 1.
@davidorme , @vgro , @jacobcook1995 , @TaranRallings : Review the data_variables.toml file and complete the information related to the variables of your models. This include adding the right units, meaningful description, the type of the variable AND the name of the axis they use. If you spot a variable that is no longer relevant, delete it.
Then, review your models and update the contents of required_init_vars, vars_updated, required_update_vars and vars_initialised. They should all be just simple lists and the name of the variables, obviously, should match those of the data_variables.toml.
With those changes, create a PR against this branch.

Once the above is done for all models, I'll strip some unnecessary validation code and, potentially, adapt tests. By that point, VE would not be using the variables registry, yet, but having it would not break the existing functionality, so this would be ready for merging.
After that, is up to you to exploit that functionality.

The documentation building is failing because of something happening in this block (that I have not touched) but other than that, this is ready to be contributed to.
Next steps:
* Branch off the branch of this PR, `variables 1`.

* @davidorme , @vgro , @jacobcook1995 , @TaranRallings : Review the [`data_variables.toml`](https://github.com/ImperialCollegeLondon/virtual_ecosystem/blob/variables_1/virtual_ecosystem/data_variables.toml) file and complete the information related to the variables of your models. This include adding the right units, meaningful description, the type of the variable AND the name of the axis they use. If you spot a variable that is no longer relevant, delete it.

* Then, review your models and update the contents of `required_init_vars`, `vars_updated`, `required_update_vars` and `vars_initialised`. They should all be just simple lists and the name of the variables, obviously, should match those of the `data_variables.toml`.

* With those changes, create a PR against this branch.

Once the above is done for all models, I'll strip some unnecessary validation code and, potentially, adapt tests. By that point, VE would not be using the variables registry, yet, but having it would not break the existing functionality, so this would be ready for merging.
After that, is up to you to exploit that functionality.

Thanks for the instructions on next steps, just a quick question: by type, to you mean float, string, etc?

Yes. In principle, that is one of the required parameters that we were thinking to include. It is not used for computation, so maybe it should be just human-readable type information to guide the user, and not an actual type. Or we can ditch it altogether.

Yes. In principle, that is one of the required parameters that we were thinking to include. It is not used for computation, so maybe it should be just human-readable type information to guide the user, and not an actual type. Or we can ditch it altogether.

oh ok, I'm asking because I thought all variables in the data object were xr.DataArray

@vgro - Yup, they are but I think it is useful to specify the type of the array contents. I suspect the only time it will be actually important is if the variable should be an integer and not a float (string types are very rare?) and most variables can be generically numeric (i.e. float, but doesn't really matter if the inputs are stored as int?).

@dalonsoa At the moment, this retains the original definition of required_init_vars with the format (("var_name", ("axis_name")), but in the convo above I think the intention is to make this a tuple of strings like the other matching attributes?
I think that makes sense because the axis validation can be offloaded into the variable setup process rather than being repeated across models.
https://github.com/ImperialCollegeLondon/virtual_ecosystem/blob/e612fd510698c875414c090d8146dd83b6d2c0ad/virtual_ecosystem/core/base_model.py#L152

OK - wait, that is a logical step but does break the compatibility of this PR with the current state of develop. We should probably restore the original required_init_vars setup and then create new PRs to adopt/shift that part of the variables system. Rather than trying to fix everything here.

OK - wait, that is a logical step but does break the compatibility of this PR with the current state of develop, which is not the strategy you outlined above for adopting this PR.
Although the updated docstrings indicate the intention to reduce required_init_vars to a tuple of names and not the more complex structure, we should probably restore the original required_init_vars setup and then create new PRs to adopt/shift that part of the variables system. Rather than trying to fix everything here.

Implementing this PR will do things differently, but as this PR is not going to be merged until all models have been updated to setup the variables in this new way, offloading the validation to the variables system, there's no breaking of anything.
Restoring the previous required_init_vars will break the current state of this branch, implementing the variables and their validation outside of the models, so I really advise against it. As I said, nothing is to be broken in develop because by the time this is merged, the models would be adapted.

@dalonsoa OK - I was thinking that we would merge this PR in close to its present state (variables all described and registered but models still implement data validation) with then subsequent PRs to hook up the wider utility of the system. In that case, I'd have restored the required_init_vars format because it's a breaking change.
But IIUC, your intention is to hook all that up once we've got the variables definitions sorted out and merged in here. That does make more sense - in my defence, I'm trying to fix my tendency to balloon PRs 😄

Just to note that I'm expecting those pre-commit fails - the incoming changes from variables_1_vgro will update the model structures to apply the new simpler list of strings in BaseModel.required_init_vars.

@dalonsoa We've just talked through the variable process and we think we definitely need to be able to have variables that only appear at update. These are typically internal state variables, that use the Data object as memory. It doesn't really make sense to force all variables to be present after the __init__ stages complete.
Can we allow an explicit populated_by_update variables attribute? It might be worth moving away from the initialised_by terminology to avoid confusion? Maybe something like:populated_by_data, populated_by_init, required_by_init, populated_by_update and required_by_update?

@davidorme , sounds good. I'll allocate time to work on this and leave it ready for merging next Tuesday 18th.

Another thing we might want is a very small  set of core variables (at the moment one)  that are initialised from the configuration before models initalise.
The motivating case is layer_heights, which is initialised by the Plants model at the moment. That makes some sense, since most of it is canopy height, but the actual initial state is all from config and the core components, but it is used by all sorts of models as a central reference for vertical layer heights.
So, we could introduce those core variables - possible as part of the initialisation process of CoreComponents - and maybe flag them as core somehow. I don't think this is part of the variables PR, just something that I'm thinking about right now and wanted to log.

@dalonsoa I currently initialize a few variables in setup, but we agreed that we want to retire the setup from the base model and move all the functionality to init. Would it make sense for me (or you) to move everything that sits in setup to init first? I can list the variables that are meant to be in populated_by_init and populated_by_update.

Happy to do the change myself, and also in relation to the variables need moving.

Happy to do the change myself, and also in relation to the variables need moving.

That would be really nice. I am currently updating the lists and will commit to this branch for you to review

I'm trying to make this work and I'm facing the following problem:
The aerodynamic_resistance_surface is not in the daily_lists dictionary, so things fail in here. Adding it is straight forward - I just made it one of the vars_updated when creating the model - but that does not populate the dictionary entry with any data, so the line above still fails. @vgro how should the aerodynamic_resistance_surface variable be updated in the HydrologyModel.update method?
This is making two tests fail, but otherwise, once that is sorted, this should be ready to go.
@vgro , @jacobcook1995 , I've added aerodynamic_resistance_surface and soil_c_pool_necromass to the variables registry. Please, check that the information there makes sense.

Ups... should those files under jupyter_execute be there? I'll git ignore the folder and remove them if they should not be there.

@dalonsoa I have some unpushed updates on this too - I think this was one of the issues. Will have a look now.

I'm trying to make this work and I'm facing the following problem:
The aerodynamic_resistance_surface is not in the daily_lists dictionary, so things fail in here. Adding it is straight forward - I just made it one of the vars_updated when creating the model - but that does not populate the dictionary entry with any data, so the line above still fails. @vgro how should the aerodynamic_resistance_surface variable be updated in the HydrologyModel.update method?
This is making two tests fail, but otherwise, once that is sorted, this should be ready to go.
@vgro , @jacobcook1995 , I've added aerodynamic_resistance_surface and soil_c_pool_necromass to the variables registry. Please, check that the information there makes sense.

Thanks @dalonsoa . The aerodynamic_resistance_surface is not returned by the function that calculates it here
could you add a line output["aerodynamic_resistance_surface"] = aerodynamic_resistance below, please?
The daily lists are created from vars_updated here,  so if you add the aerodynamic_resistance_surface to vars_updated it will hopefully work.

 Everything seems to be working, but the build of the documentation appears to be failing. However, looking at the logs, there's nothing indicating a failure. might it be because of the warnings at the beginning, @davidorme ?

OK, I managed to find the error. When running this notebook, we get: ValueError: Variable surface_runoff initialised by hydrology already in registry as initialised by data.. This suggest that the example data used by the notebook contains data that was supposed to be initialised by the hydrology model, instead, and not provided as input data.
So, @vgro , @davidorme , what do you suggest to fix this? I don't know the ramifications of just removing the surface_runoff  from the example data.

OK, so removing surface_runoff from the example data doesn't seem to be an issue, but that reveals more issues with that specific notebook.

The first issue is the three variables in the hydrology model populated_by_init_vars that are also in the abiotic model. This is a known issue - the overlap is noted in comments - but the variables system can't run until this is resolved, right @dalonsoa ?

https://github.com/ImperialCollegeLondon/virtual_ecosystem/blob/fd0df0e55bf13bffe09bcd0bfffec785cd81c52f/virtual_ecosystem/models/hydrology/hydrology_model.py#L98-L101

If I comment those three lines out, it then runs but halts at another error:

  File "/Users/dorme/Research/Virtual_Rainforest/virtual_ecosystem/virtual_ecosystem/core/variables.py", line 312, in _collect_updated_by_vars
----- stderr -----
    raise ValueError(
----- stderr -----
ValueError: Variable aerodynamic_resistance_surface required by hydrology is not initialised by any model.

@vgro - I think this is right. aerodynamic_resistance_surface is first populated by HydrologyModel.update but is never initialised. Not quite sure what is going on here.

It's really late in the day to be moaning about this, but I find I constantly stumble over the meanings of the model variable attributes. Does anyone else find this - if so could we switch up the names?
    required_init_vars -> vars_required_for_init
    vars_updated -> vars_updated
    required_update_vars -> vars_required_for_update
    populated_by_init_vars -> vars_populated_by_init
    populated_by_update_vars -> vars_populated_by_first_update

OK -  this has basically been me smacking it with stick. I don't think I've done anything mad but @vgro and @TaranRallings please have a look at the changes to hydrology and animal model files.

Removed surface_runoff from initial input data.
Added a bunch of variables that are populated by the first update but were missing from populated_by_update_vars.
Correct space to spatial in variable axis definitions, added a placeholder time axis validator, moved some more outlandish hypothetical axes into comments in data_variables.toml.
Update the axis testing to expect the new time axis name.

I haven't got my head around why test_ve_run passed, yet basically running the same thing in a notebook failed.

Good morning, you were busy last night!

it is ok to remove the surface_runoff from the input data now, however, it will probably be needed once we introduce some sort of spinup. The idea is that the surface runoff needs to accumulate over a spinup period to read a steady state. I can add it back when we get there.
the aerodynamic_resistance_surface is indeed initialized by the first update
the abiotic variables that are populated in the hydrology here are somewhat optional; it depends on the order of models. If abiotic runs first that is fine, but I thought we wanted to run the hydrology before abiotic?

This conversation definitely highlights the value of your contribution @dalonsoa  , thank you :-)

It's really late in the day to be moaning about this, but I find I constantly stumble over the meanings of the model variable attributes. Does anyone else find this - if so could we switch up the names?
    required_init_vars -> vars_required_for_init
    vars_updated -> vars_updated
    required_update_vars -> vars_required_for_update
    populated_by_init_vars -> vars_populated_by_init
    populated_by_update_vars -> vars_populated_by_first_update

No problem changing the names - just tell me what you want, and I'll change it :)

The first issue is the three variables in the hydrology model populated_by_init_vars that are also in the abiotic model. This is a known issue - the overlap is noted in comments - but the variables system can't run until this is resolved, right @dalonsoa ?

That's right. That's the point of the validation process done in the variables system, to avoid having two models initialising the same variables. It was mentioned in the comments that the adiabatic models were also initialising those, but there was no suggestion of a solution (at lease not one I can implement without knowing the science). The adiabatic models and the hydrology models are not parallel models (like adiabatic and adiabatic_simple that are mutually exclusive), so if they are to coexist, they need to have compatible variable initialisation processes.

It's really late in the day to be moaning about this, but I find I constantly stumble over the meanings of the model variable attributes. Does anyone else find this - if so could we switch up the names?
    required_init_vars -> vars_required_for_init
    vars_updated -> vars_updated
    required_update_vars -> vars_required_for_update
    populated_by_init_vars -> vars_populated_by_init
    populated_by_update_vars -> vars_populated_by_first_update

No problem changing the names - just tell me what you want, and I'll change it :)

The first issue is the three variables in the hydrology model populated_by_init_vars that are also in the abiotic model. This is a known issue - the overlap is noted in comments - but the variables system can't run until this is resolved, right @dalonsoa ?

That's right. That's the point of the validation process done in the variables system, to avoid having two models initialising the same variables. It was mentioned in the comments that the adiabatic models were also initialising those, but there was no suggestion of a solution (at lease not one I can implement without knowing the science). The adiabatic models and the hydrology models are not parallel models (like adiabatic and adiabatic_simple that are mutually exclusive), so if they are to coexist, they need to have compatible variable initialisation processes.

A solution would be to make sure that the abiotic model (whichever is selected) is initialized BEFORE the hydrology, then we can just delete these variables from the initialization of the hydrology model

Could we indicate in the config file that hydrology depends on adiabatic? At the moment, it is the other way around in here, for example:
https://github.com/ImperialCollegeLondon/virtual_ecosystem/blob/68129075e9bd03f77d612eb5b6b2447d49a59aef/virtual_ecosystem/example_data/config/ve_run.toml#L2-L4

Could we indicate in the config file that hydrology depends on adiabatic? At the moment, it is the other way around in here, for example:
https://github.com/ImperialCollegeLondon/virtual_ecosystem/blob/68129075e9bd03f77d612eb5b6b2447d49a59aef/virtual_ecosystem/example_data/config/ve_run.toml#L2-L4

ah, this is what I was looking for. I think we want
init in this order: plants, abiotic_simple, hydrology, others
update in this order: hydrology, abiotic_simple, plants, others
which should look like this:
[hydrology.depends]
init = ['plants', 'abiotic_simple']

[abiotic_simple.depends]
init=['plants']
update=['hydrology']

[plants.depends]
update=['abiotic_simple', 'hydrology']

Also, I just noticed that the infamous aerodynamic_resistance_surface is a required_update_var for the abiotic model. So it would be best to update the hydrology first.
can you confirm this @davidorme ?can you confirm this @davidorme ?

Actually, we don't need to worry about the order. If we indicate correctly what variables are initialised by what model and when, then we can use the information stored in the variables registry to come up with the right sequence for the init and the update. We don't need to indicate that in the config file - and we can completely ditch that part. At least when it comes to the initialisation.

Actually, we don't need to worry about the order. If we indicate correctly what variables are initialised by what model and when, then we can use the information stored in the variables registry to come up with the right sequence for the init and the update. We don't need to indicate that in the config file - and we can completely ditch that part. At least when it comes to the initialisation.

Yeah - this is one of the main advantages of the variables system, I think. It can automatically establish if there is a feasible variable setup sequence for any given suite of models and give meaningful errors about why no sequence can be established.

At least when it comes to the initialisation.

I think the same should be true for the update? Going into update, we know which variables have been loaded from data and populated by the model __init__ methods. So for each model, we can know which variables are missing and then which models populate that variable when they update. That ought to give us the update order.

It's really late in the day to be moaning about this, but I find I constantly stumble over the meanings of the model variable attributes. Does anyone else find this - if so could we switch up the names?
    required_init_vars -> vars_required_for_init
    vars_updated -> vars_updated
    required_update_vars -> vars_required_for_update
    populated_by_init_vars -> vars_populated_by_init
    populated_by_update_vars -> vars_populated_by_first_update

No problem changing the names - just tell me what you want, and I'll change it :)

@jacobcook1995 gave this the thumbs up, so unless anyone else is wildly bothered, I say we go for those switches. It probably makes sense to update the _check_... functions in core.variables to match.

it is ok to remove the surface_runoff from the input data now, however, it will probably be needed once we introduce some sort of spinup. The idea is that the surface runoff needs to accumulate over a spinup period to reach a steady state. I can add it back when we get there.

I've a nasty feeling that we'll need to add to variables system then to track spinup variables and the order of execution of spinup methods... Although if spinup is limited to a very few variables and models, we could just provide external code to estimate the initial values to put in, rather than having to embed it all in the VE code.

It's really late in the day to be moaning about this, but I find I constantly stumble over the meanings of the model variable attributes. Does anyone else find this - if so could we switch up the names?
    required_init_vars -> vars_required_for_init
    vars_updated -> vars_updated
    required_update_vars -> vars_required_for_update
    populated_by_init_vars -> vars_populated_by_init
    populated_by_update_vars -> vars_populated_by_first_update

No problem changing the names - just tell me what you want, and I'll change it :)

@jacobcook1995 gave this the thumbs up, so unless anyone else is wildly bothered, I say we go for those switches. It probably makes sense to update the _check_... functions in core.variables to match.

I'm going to make this change in this PR, right now. Let's see if I don't break anything else...

Do we want to do this in this issue?

No. Nope. Nix. Hard pass.

It's becoming pretty large and I feel it would be best to consolidate what we have before starting to use the new functionality to improve the workflow.

☝ 👆 This.

Yes, please!!! 🙏

yes, go for it 👍

oh you already did, perfect :-) Happy weekend!


class InPlaceABNSync(nn.Module):

How do you use InPlaceABNsYNC in your project? I want train you code with Pytorch1.3! But I dont know how to use InPlaceABNSync and the usefulness of it. could you please tell me?

@tjpulkl
We adopt the implementation of InPlaceABNs from https://github.com/mapillary/inplace_abn. This implementation use leakyrelu as default activation function.
Currently we only release the inference code. To maintain consistency, we use the leaky relu and bn in pytorch in our code.

Hi.
thank you for your reply. would you please answer me a question?
I'm a first year doctor degree student in ajou university. I'm not familiar
with pytorch.
I think you know CE2P. it's original version can be executed on
Pytorch0.4.1.
now I want to transfer it from 0.4.1 to pytorch 1.3. readme of CE2P said
" use Pytorch 1.0, just replace 'libs' with 'modules' in [
https://github.com/mapillary/inplace_abn"
but when I did as it said I encountered compile problems.  I think you know
how to do with that.
will you please give me the concrete steps to use inplace_abn in CE2P?
Thank you very much!
Best Regards!
2019년 12월 19일 (목) 오전 9:16, peike<EMAIL_ADDRESS>작성:

Closed #5
https://github.com/PeikeLi/Self-Correction-Human-Parsing/issues/5.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/PeikeLi/Self-Correction-Human-Parsing/issues/5?email_source=notifications&email_token=ANUDG4MGBR567LB5IA3MQITQZK4NLA5CNFSM4J4DSFJKYY3PNVWWK3TUL52HS4DFWZEXG43VMVCXMZLOORHG65DJMZUWGYLUNFXW5KTDN5WW2ZLOORPWSZGOVSKWDOQ#event-2895471034,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ANUDG4P4PP547SWNUKA7ORDQZK4NLANCNFSM4J4DSFJA
.


Add cert-injection-webhook as an installable package

Feature Request
The cert injection webhook is a controller and webhook configuration that can inject trusted ca certificates into pods that need to communicate with services that have self signed certificates. It can be used with other deployments like kpack to allow builds to push images to self signed registries. The addition of the cert injection webhook package would allow kpack to leverage it, but its consumption wouldn't  have to just be limited to kpack. There is another proposal (#2462 ) to add kpack to TCE.
Describe alternatives you've considered
One alternative would be to include the cert injection webhook as part of the kpack package. We decided against this because there may be cases where you don't have kpack installed, but want to leverage the cert injection webhook, such as a cluster that is running application workloads that communicate with a self signed service. Alternatively, If a user doesn't have a need for self signed cert support, they do not have to deploy an additional controller.
Additional context
kpack proposal - #2462

Thanks Tom, seems sensible, a couple questions we'd like answered in this proposal.

Does kpack depend on this package (or is it optional)?
If this package is independent of kpack and kpack depends on it, what's the plan for ensuring they are deployed together?
Where do you plan to host the source configuration for the [carvel] package(s) representing kpack?
Which team will become the package maintainers of this package long-term?

kpack only depends on this if you want to execute builds against private registries, otherwise it is totally optional
similar to the kpack source config, this one is hosted in a private git repo with the packages pushed to projects.registry.vmware.com/buildservice/cert-injection-webhook/bundle and we will proabbly do the same thing as kpack as far as exposing it to the open source community
Tanzu build service will maintain this long term

@tomkennedy513 sorry we're having the same convo in two places, just want to make sure I don't lose track.
This all sounds great. The last point of contention seems to be holding the package source in a private git.
Would ya'll be open to moving the package source into this repo, until you can procure your own repo. Then vendir down the package source from TCE into any non-opensource project(s). This is what our product TKG does today.

In summary, we're approving this proposal 👍. The conceptual flow would be:

@tomkennedy513 Would this webhook allow these images pushed into a self-signed certificate to be run on the node's containerd? Basically, would this flow support that the image created by kpack be deployed and run on the same node where it was built? Is there any required configuration needed for this case? If so, the package provided would need to have that configurable somehow.
If not, I would recommend that TCE promotes using proper CAs (not self signed) so that every service run in the cluster can be properly secured. Kpack on TCE would still run and be able to push to a registry in the cluster as everything would be properly secured. TCE should promote the use of cert-manager's CA ClusterIssuer for all the services and educate developers how to create a CA they can trust to their personal environment.

@tomkennedy513 is the work planned for a similar timeframe as kpack?
I'd like to figure out what TCE milestone to keep track of it in.


Feature: toBeAccessible()

Would it be possible to create a Jest matcher so checks could read:
expect(() => AccessibilityEngine.check(<Comp/>)).toBeAccessible()

Looks like this was easier than thought:
/* eslint-disable i18next/no-literal-string */
import { ReactElement } from "react"
import AccessibilityEngine from "react-native-accessibility-engine"

declare global {
  namespace jest {
    interface Matchers<R> {
      /**
       * Checks whether a component conforms to Accessibility A11y best practices.
       */
      toBeAccessible(): R
    }
  }
}

expect.extend({
  toBeAccessible(received: ReactElement) {
    try {
      AccessibilityEngine.check(received)
    } catch (error: any) {
      return {
        pass: false,
        message() {
          return error.message
        },
      }
    }
    return {
      pass: true,
      message() {
        return "Component is accessible.\nDoes it make sense to test a component for NOT being accessible?"
      },
    }
  },
})

This could be added as expect-extend.js to the root and configured in jest via
"jest": {
  "setupFilesAfterEnv": ["react-native-accessibility-engine/extend-expect.js"],

}

👏👏👏👏👏
This looks awesome! I tested this out locally and it seems to be working well. A couple of things to note:

A test using our custom jest matcher would actually look a little different from your first comment:
expect(<Button />).toBeAccessible(). I like how direct this is.
Does it make sense to test a lack of accessibility? Probably not, but jest does provide the .not modifier by default, so we'd probably have to consider and test this anyway.

See how the error message is formatted all in gray text? I took a look at this comment on stackoverflow that explains how to use matcher utils to format error messages. Then I took a look at the actual documentation of jest.expect and it turns out that these matcher utils are actually available through this.[util] within the matchers.

Would you like to open a PR? This seems totally doable. 👍🏼

The problem with then '.not' stays the same if we would change the name, wouldn't it?
For other A11y matchers, do you think like contrast ratio or so? Where one could more fine grain the amount of accessibility features to test. Where A11Compliant would check for aria tags and contrast ratio one developer could decide to check for contrast ratio later in the development cycle?

Philosophically speaking 👀 if you're going to test for a lack of accessibility, it might be better to just not test anything at all.
Jest offers a this.isNot helper which we could theoretically use to make a matcher that always fails if you use .not. But that might be excessive. At the very least, it would make for a highly opinionated matcher.
As @pke suggested, a success message along the lines of Does it make sense to test that a component is NOT accessible? could be sufficient warning. Then the final decision on whether or not to use it would fall to the dev.
Thoughts?

@jsamr I get what you mean about interpreting .not.toBeAccessible as not visible to the screen reader.  The same sort of confusion might also happen with the accessible prop: someone might interpret .toBeAccessible() as contains an accessible={true} prop.
But in these cases, I don't believe the problem lies in a confusing matcher API. 🤔 These people would probably be confused about what accessibility actually is.
I believe that React Native's accessible prop, for example, IS confusing because it's using a word with an expansive definition to group elements on screen, which is a super specific thing.
I like .toBeAccessible() for a matcher that would run an element/instance against ALL the engine's rules. That's the closest we can get to testing accessibility as a whole.
But we could also offer both matchers (toBeAccessible and toBeA11yCompliant), and make one an alias of the other, like a few of jest's built-in matchers.
Also I like the idea of the A11y prefix for more fine-grained matchers, similar to @testing-library/react-native's a11y queries. 👍🏼
Thoughts?

@aryella-lacerda The naming is a pretty opinionated thing ^^ If one day we want a matcher to test if an element is invisible to screen readers on both platforms, by checking recursively if at least one parent has importantForAccessibility or accessibilityElementsHidden, then I am not sure which name we could give. toBeA11yHidden?
Another point, one might think toBeAccessible() means to have the accessible prop set to true... I find the name a bit too generic to the point it encompasses very different notions and definitions.

@aryella-lacerda @jsamr PR #126 created. Please comment.

Another point, one might think toBeAccessible() means to have the accessible prop set to true...

Well true, but for that there is the default jest matcher .hasProperty. And since .toBeAccessible needs to be made available via extension you can not accidentally confuse the two. Also there is the README and the code completion (hover help) in VSCode.


[FEATURE] improve landing page and add mobile responsiveness

I will work on this one .

Sure @AdityaPainuli I'm assigning it to you


chore: added vpn connection

:tada: This PR is included in version 2.34.6 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


Codeunit 227 new event on procedure Apply

Hi,
We need a new event on 227 new event on procedure Apply :
...
   PaymentToleranceMgt: Codeunit "Payment Tolerance Management";
    begin
        OnBeforeApply(VendLedgEntry, DocumentNo, ApplicationDate);
        with VendLedgEntry do begin
            // > New Event
            OnApplyOnBeforePmtTolVend(PaymentToleranceMgt);
            // < > New Event
            if not PreviewMode then
                if not PaymentToleranceMgt.PmtTolVend(VendLedgEntry) then
                    exit(false);
            Get("Entry No.");
....

[IntegrationEvent(false, false)]
    local procedure OnApplyOnBeforePmtTolVend(var PaymentToleranceMgt: Codeunit "Payment Tolerance Management");
    begin
    end;

Thanks for reporting this. We agree, and we’ll publish a fix asap, either in an update for the current version or in the next major release. Please do not reply to this, as we do not monitor closed issues. If you have follow-up questions or requests, please create a new issue where you reference this one.


setAnim for Head and Upper_waist

Hi Joe, can you explain why we omit head and upper_waist?
	if (bodyPart.Name.Contains("head") || bodyPart.Name.Contains("upper_waist"))
				setAnim = false;

I think it is because they are child objects and will be set by their parent


chore(*) the year is 2021 (license update)

Summary
I was looking at the license and I noticed a commit from @hbagdi last year updating the year, so I made this quick PR to update it again.

 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.

 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.


How can I scroll particular header with your library

Hello I want to develop this kind of functionality.
when I click on tab layout Item sectioned recycler-view auto scroll to particular header position.

Kindly advise me please, How can I achieved It.
Thanks

Hi @ddpatel2606, thank you for using the library!
To scroll within the RecyclerView you can use one of RecyclerView#scrollToPosition or RecyclerView#smoothScrollToPosition. These methods take as a parameter the global RecyclerView position. To determine it for a specific section, you can use SectionDataManager which implements PositionManager interface.
So, in your case, you have to write something like this:
tabLayout.addOnTabSelectedListener(new TabLayout.OnTabSelectedListener() {
        @Override
        public void onTabSelected(TabLayout.Tab tab) {
             int sectionIndex = tab.getPosition();
             int firstItemPos = sectionDataManager.calcAdapterPos(sectionIndex, 0);
             int headerPos = firstItemPos - 1;
             recyclewView.smoothScrollToPosition(headerPos);
        }
        ...
});

If you need to scroll to the state in which selected section is at the very top and you are using LinearLayoutManager, you can use scrollToPositionWithOffset:
linearLayoutManager.scrollToPositionWithOffset(determinedPos, 0);

The general idea is that you can calculate the global RecyclerView position and then write the same logic as if you were using default RecyclerView adapter.
Let me know if my answer was helpful.

Yes, Its works perfect, You saved my so much time, thank you so much.


Numerous README improvements

This fixes some typos, markdown errors, and other suggested improvements, like using venv in a more convenient way (specifically, in the same root directory as the repo, where most people put it).

Something went wrong with signing commits. I'll close this and try again.


Prepare Core Libraries for November 2022 Release

Prepares the Core libraries for the November 2022 release, plus a few minor additional changes.

Added dependency to com.fasterxml.woodstox:woodstox-core:6.4.0 everywhere a dependency for com.fasterxml.jackson.dataformat:jackson-dataformat-xml exists to resolve the CVE against woodstox-core:6.3.1 (used by jackson-dataformat-xml.
Updated design of HttpHeaderName so it implements ExpandableStringEnum.

API change check
APIView has identified API level changes in this PR and created following API reviews.
azure-core


Make sure the roots for storage_path() and the Storage facade make sense

Why are files in {storage_path()}/app/public in the image in README?

Without tenancy:
>>> storage_path()
=> "/var/www/laravel/test/storage"
>>> Storage::disk('local')->getAdapter()->getPathPrefix()
=> "/var/www/laravel/test/storage/app/"


Not working for facebook social cards

When using the Facebook social debugger, the response code is a 404 and it does not fetch the og:image, og:title, etc.
To Reproduce
Steps to reproduce the behavior:

Deploy the site, copy url
Go to the debugger (link above), paste url and click "debug"
See error

Expected behavior
It should render the card correctly, as it does with twitter
Screenshots

Additional context
Here's the link to my dummy site: https://polo-dev.netlify.app/

Hey @MartinSchere thanks for taking an interest in the project 👍
I'll be honest I personally don't use FB so have never tested it for that, have you tried using it without the FB debugger?
I know sometimes with the Twitter Debugger it can give inconsistent results, that's mainly because I use a serverless function to generate the image.
If that's not the case and it flat out doesn't work I'm happy to listen to any suggestions you have and open to PRs 🙏
Thanks again!

My error was very dumb, I forgot to use the plugin for react-helmet so it wasn't generating anything during pre-render

Yeah, it is in the docs, I did think about adding it as a peer dep but my opinion was that everyone would be using it already 😂
Ok, so cool to close the issue?


captive portal: multiple zones using the same voucher settings

@DokuKaefer asks if this will cause any problems or if the code can handle this ok?

It should work, but your "users" can login at the same time at different zones then.

Good to know, thanks


Add example of how to use your own room ID generation logic

PR as discussed in https://github.com/colyseus/colyseus/pull/404.

Awesome @banool, thanks for this addition! I've made a small change for TypeScript syntax highlighting and included your section under "How to" on the sidebar!


Discord Clone

Project title
Discord Clone
Project Description
A clone for the discord app
Stack:
And in order to tick the check box just but x inside them for example - [x] like this. Please delete options that are not relevant.

[x] Html
[x] CSS
[x] JavaScript
[x] ReactJS

/assign

/assign


Add unit tests for projected volume test

Created func pod.UsesProjectedVolumeServiceAccounts() then used that to write unit tests around.

Going to close this as I'm not sure how to best go about unit testing this while also maintaining the complaint and non-compliant objects.


Getting DeepAR gradients of output w.r.t to inputs (covariates)

Hi,
I am looking to calculate the gradient of the output of DeepAR w.r.t to it's inputs. In more detail, I have a single time series/target and 10 covariates. I would like to get a vector of length 10 which is the gradient of the output of the model w.r.t to each covariate. I have been going through the DeepAR code (network.py and estimator.py) and from what I understand, the RNN model is defined in the DeepARNetwork init function (shown below)

I am new to MxNet and found the grad() function which I think might be useful, but I don't know how to define the "heads" and "variable" input to the grad() function as all the variables are within the RNN API call. This question might be more suited to a MxNet forum than here but I thought I would test my luck if anyone has run into this task before.
A separate question (less important but just curious)
At the same time, I am reading the DeepAR code and in the paper, the distribution parameters are trained as well via a projection layer. For example, the mean of the gaussian distribution is given by an affine transformation of the RNN output via w and b. (shown below). The paper states that in training, the RNN parameters as well as the distribution parameters (w and b) are learnt.  Where in the code is this final projection layer defined and then updated during training?

Thank you for any help or advice regarding these two questions, it is greatly appreciated!

so the linear layer is in the arg_proj of the distribution output class i.e. https://github.com/awslabs/gluon-ts/blob/a37620ffd4100b3762fc85075c35328dd3d62679/src/gluonts/mx/distribution/distribution_output.py#L60-L70
and then the domain mapping happens in each distribution's version of the distribution output i.e. https://github.com/awslabs/gluon-ts/blob/master/src/gluonts/mx/distribution/gaussian.py#L161 for the softplus on the sigma of the gaussian.

I figured it out so closing.

@GabrielDeza Do you have any pointers? I'm having the same issue. The lest specific to DeepAR (and more general), the better.

@GabrielDeza Do you have any pointers? I'm having the same issue. The lest specific to DeepAR (and more general), the better.


[pysmi] mibdump --build-index not automatically updating the index file

After running a command like, mibdump --mib-source . --build-index --generate-mib-texts --destination-directory=\venv1\Outputs\  --destination-format json DS0-MIB, an index.json file is properly generated. However, I was under the belief that as you continue to run mibdump commands, such as mibdump --mib-source . --build-index --generate-mib-texts --destination-directory=\venv1\Outputs\  --destination-format json OSPF-MIB, then the index.json file will automatically update itself.
Am I correct in my understanding of its abilities? If so, are you aware of what could be going wrong? (FYI I am on Windows, so maybe the Windows paths issue is affecting me)

This was purely a problem with the environment I was using.


Leaderboard data of last entry

When we have Force last multiple rule for leaderboard, the title in the column data of last entry is misleading.

each submission on the leaderboard is showing its own date

either we show just the last submission date for all submissions
or we plan something else

How can you tell this is not the date of last entry of the participant?
But yes maybe we should put the date of the given entry instead of date of last entry.

How can you tell this is not the date of last entry of the participant?

Sorry, my mistake. This is indeed the last entry date


Test store invariants

We should

Write down the invariants that the store should have
Test those invariants

This is motivated by the fact that @junjizhi 's integration tests now work, but they don't exhibit consistent behaviour due to the store dropping signatures.

See   https://github.com/statechannels/monorepo/commit/9d57465e6d9645e0dff2819f5df484c4b6bc91cc

See https://github.com/statechannels/monorepo/issues/1456#issuecomment-615520101


Repeatable creation of the demo gif animation

Developed a brand new tool shell-keystroke-animator for creating GIF animations for shell programs, code snippets and more. Here's a recreated version of the joe demo. Admittedly, it doesn't recreate mouse movements/selections. Instead I used view, which highlights comments, and scrolled through the longer .gitignore by glitching some noop-commands.
Good news is that it's super easy to iterate over the animation creation, so please fix it the way you please.
Input:
joe
joe ls
joe java
joe java > .gitignore
cat .gitignore
joe java python osx > .gitignore
view .gitignore
zzzzzzzzLzzzzzzzzzzzzzzzzLzzzzzzzzzzzzzzzzLzzL

Output:

:+1:

Is there a way to set the width and height of the terminal? I would love to add this to the README if it had a shorter height.

@karan: you set the window size yourself before starting the recording. See window size examples on https://github.com/joelpurra/shell-keystroke-animator

Bug?

@karan: no - guess you didn't switch to the "other" window, which is where the recording happens.

Ah.
Not the animate part is stuck for some reason. Probably because there's way too many files?, and read takes a looong time.

@karan: you mean creating the gif from all the png files, or something else? Sure, that takes a while sometimes -- depending on the speed of your computer of course.
What do you mean by read? Did you set a custom keysleep maybe?

I mean the read command used in your source code. I didn't set keysleep.
I think I waiter for ~5 minutes.
Oh well, I'll close this issue for now since it isn't actually an issue and start one in your repo.

@karan: alright, that would work too. Can only confirm that it's working on my machine (as can be seen in the animation in the first post) so feedback would be great!


Would you mind uploading pre-trained models?

@GrayXu
Thanks for your interest.
I have no access to log in  the server my models saved on.
which means I can't  get the models.
However,  there is a repo :
https://github.com/BIGBALLON/ResNet_CIFAR
which support some pre-trained models
(https://github.com/BIGBALLON/pretrained_models)
check it if you want.

thx!


cheatsheet in help

We have a lot keys added to the controls of the views.
It may be good to give an overview in the documentation or in the app itselfs.
@joernu76 what do you think about this?

Mmmh. Not many, which are not pretty standard.
We should go through all the tooltips to make sure, they are correct and offer the shortcut, if available.


SessionStorage throws an error on Mobile Safari 10.0

Hi guys,
We are running "history": "3.0.0", and we are seeing an error on Mobile iOS 10.3.3 - Safari 10.0.
It throws the error "The operation is insecure" when trying to access window.sessionStorage if cookies are disabled.
Click me
Is this expected behaviour?
We're also thinking of a fallback for when users disable cookies -- there's really not much they can do in our app without cookies :).

We ditched session storage in 4.0 because of this limitation. We now only use pushState storage, which works even when cookies are disabled. Please upgrade!


Update binary install document

Description
This commit update binary install document missing which refered in #8562
Test Plan
#pass
Type of Change (Check all that apply)

[x] user-visible impact
[ ] breaking change for a client SDKs
[ ] breaking change for FNs (FN binary must upgrade)
[ ] breaking change for validators or node operators (must upgrade binaries)
[ ] breaking change for on-chain data layout
[ ] necessitate either a data wipe or data migration

Release notes

Thanks @BoynChan for submitting this update!


jm/keybinds

feat: simplify key binding config
feat: simplify key bindings for tab switching

These keybinds came about from just naturally using the app and pressing buttons that seemed like the logical things that should work:

Tab to change tabs
left, right, up, down on the summary page

Moving the crate info to its own tab and decoupling it from the list would simplify the picker keybinds to single section and remove the need for mode switching
Making filter and search submodes of the search page instead of modes of the app would help simplify this too


Revert commits for adding debug metrics and logging

Revert "Update metrics and add logging for activity timeout task (#3030)"
Revert "Add metrics for profiling activity timeout task latency (#3026)"
Revert "check if timer expired first"

Coverage increased (+0.01%) to 67.754% when pulling e3ffff6104e3e4a4a8e5e711bf6668795ceeb31b on yycptt:0.11.x-revert into 6bf637f503425e4a6289067c22a9a8b530a6afcd on uber:0.11.x.


Windows: Add clang-cl pipeline

Commit Message: Enable Windows clang-cl pipeline
Additional Description:
Work around problematic googletests with clang-cl compilation

Solve problematic missing override declarations of mocks by temporarilly
adding -Wno-inconsistent-missing-override for clang. (It appears
googletest on clang-cl isn't handling something that our gcc, clang and
msvc-cl builds all ignore without the warning override.
Workaround THROW tests which googletest with clang-cl are framing as
as -Wdiscard errors.
Workaround nodiscard next() method error
Follow up about discarded results of singleton construction and other
discarded odd or apparently irrelevant function call results.

Activate the clang-cl pipeline with working opt build

Adds a second build clang-cl using the LLVM toolchain
Introduce debugging output for msvc-cl and clang-cl opt binaries in
order to be able to unwind stack traces from windows core files.
(required increasing the available heap on the RBE GCP workers)
Fix lld-link.exe errors caused by unexported destructors
Mark additional tests flaky/fails on windows based on clang-cl build
observed test failures

Tag tests broken due to missing dtor in -c opt --config=clang-cl

Add the broken_clang_cl_dtor tag to tests which cannot compile due
to some windows-specific clang scope or optimization issue.
Issue is observed when the class used is based on a : public virtual foo,
base class, that ~foo() = default; destructor declaration is ignored, and
the linker reports that foo's dtor symbol cannot be resolved at link time.
It appears that when the base is redefined as : public foo the defect goes
away. (The virtual base class may be nested in a non-virtual base class).
It isn't possible to solve this by dropping every virtual class inherited,
due to diamond inheritance patterns.
This may be a compiler bug, or an optimization toggled by /O2 in clang-cl
which they do not enable in -O2 on linux. Tableing this for the time being.

Risk Level: Low (only affects Windows build in clang-cl)
Testing: Verified locally/in CI on Windows
Docs Changes: N/A
Release Notes: N/A
Platform Specific Features: N/A
Fixes #11974

cc @envoyproxy/windows-dev

Currently stalled to pick up clang-cl 11 and reproduce the linkage error.  See https://github.com/bazelbuild/rules_cc/pull/88

rules_cc now addressed, awaiting https://github.com/bazelbuild/bazel/pull/12458 and subsequent bazel release. Still /wait ing

awaiting bazelbuild/bazel #12458 and subsequent bazel release

Ready when Bazel 4.0.0 is released to bump envoy-bazel-build toolchain.

@wrowe we can bump rules_cc without bump bazel version, will just update https://github.com/envoyproxy/envoy/blob/master/bazel/repository_locations.bzl#L535 work?

@wrowe we can bump rules_cc without bump bazel version, will just update https://github.com/envoyproxy/envoy/blob/master/bazel/repository_locations.bzl#L535 work?

Unfortunately combining the new rules_cc for envoy with 3.6.0 bazel always results in these two exceptions... building for msvc-cl;
ERROR: C:/_eb/external/local_config_cc/BUILD:501:24: unterminated string literal at eol
ERROR: C:/_eb/external/local_config_cc/BUILD:502:1: syntax error at 'Target': expected ,
ERROR: C:/_eb/external/local_config_cc/BUILD:502:17: unterminated string literal at eol
ERROR: C:/_eb/external/local_config_cc/BUILD:503:20: unterminated string literal at eol
ERROR: C:/_eb/external/local_config_cc/BUILD:504:22: unterminated string literal at eol
ERROR: C:/_eb/external/local_config_cc/BUILD:517:9: unterminated string literal at eol
ERROR: C:/_eb/external/local_config_cc/BUILD:518:17: unterminated string literal at eol
ERROR: C:/_eb/external/bazel_tools/tools/cpp/BUILD:469:14: Target '@bazel_tools//tools/cpp:compiler' depends on toolchain '@local_config_cc//:cc-compiler-x64_windows', which cannot be found: no such target '@local_config_cc//:cc-compiler-x64_windows': target 'cc-compile
r-x64_windows' not declared in package '' defined by C:/_eb/external/local_config_cc/BUILD'
ERROR: While resolving configuration keys for //test/common/access_log:access_log_manager_impl_test: Analysis failed
ERROR: Analysis of target '//test/common/access_log:access_log_manager_impl_test' failed; build aborted: Analysis failed

and when building for clang-cl;
Starting local Bazel server and connecting to it...
ERROR: C:/_ec/external/local_config_cc/BUILD:209:20: unterminated string literal at eol
ERROR: C:/_ec/external/local_config_cc/BUILD:210:1: syntax error at 'Target': expected ,
ERROR: C:/_ec/external/local_config_cc/BUILD:210:22: unterminated string literal at eol
ERROR: C:/_ec/external/local_config_cc/BUILD:223:9: unterminated string literal at eol
ERROR: C:/_ec/external/local_config_cc/BUILD:224:17: unterminated string literal at eol
ERROR: C:/_ec/external/local_config_cc/BUILD:285:20: unterminated string literal at eol
ERROR: C:/_ec/external/local_config_cc/BUILD:286:22: syntax error at ';': expected expression
ERROR: C:/_ec/external/local_config_cc/BUILD:287:22: unterminated string literal at eol
ERROR: C:/_ec/external/local_config_cc/BUILD:300:9: unterminated string literal at eol
ERROR: C:/_ec/external/local_config_cc/BUILD:301:17: unterminated string literal at eol
ERROR: C:/_ec/external/local_config_cc/BUILD:362:20: unterminated string literal at eol
ERROR: C:/_ec/external/local_config_cc/BUILD:363:22: syntax error at ';': expected expression
ERROR: C:/_ec/external/local_config_cc/BUILD:364:22: unterminated string literal at eol
ERROR: C:/_ec/external/local_config_cc/BUILD:377:9: unterminated string literal at eol
ERROR: C:/_ec/external/local_config_cc/BUILD:378:17: unterminated string literal at eol
ERROR: C:/_ec/external/local_config_cc/BUILD:439:20: unterminated string literal at eol
ERROR: C:/_ec/external/local_config_cc/BUILD:440:22: syntax error at ';': expected expression
ERROR: C:/_ec/external/local_config_cc/BUILD:441:22: unterminated string literal at eol
ERROR: C:/_ec/external/local_config_cc/BUILD:454:9: unterminated string literal at eol
ERROR: C:/_ec/external/local_config_cc/BUILD:455:17: unterminated string literal at eol
ERROR: C:/_ec/external/local_config_cc/BUILD:516:24: unterminated string literal at eol
ERROR: C:/_ec/external/local_config_cc/BUILD:517:17: unterminated string literal at eol
ERROR: C:/_ec/external/local_config_cc/BUILD:518:20: unterminated string literal at eol
ERROR: C:/_ec/external/local_config_cc/BUILD:519:22: syntax error at ';': expected expression
ERROR: C:/_ec/external/local_config_cc/BUILD:520:22: unterminated string literal at eol
ERROR: C:/_ec/external/local_config_cc/BUILD:533:9: unterminated string literal at eol
ERROR: C:/_ec/external/local_config_cc/BUILD:534:17: unterminated string literal at eol
ERROR: C:/_ec/external/local_config_cc/BUILD:535:9: unterminated string literal at eol
ERROR: C:/_ec/external/local_config_cc/BUILD:536:17: unterminated string literal at eol
ERROR: C:/_ec/external/bazel_tools/tools/cpp/BUILD:469:14: Target '@bazel_tools//tools/cpp:compiler' depends on toolchain '@local_config_cc//:cc-compiler-x64_windows', which cannot be found: no such target '@local_config_cc//:cc-compiler-x64_windows': target 'cc-compile
r-x64_windows' not declared in package '' defined by C:/_ec/external/local_config_cc/BUILD'
ERROR: While resolving configuration keys for //test/common/access_log:access_log_manager_impl_test: Analysis failed
ERROR: Analysis of target '//test/common/access_log:access_log_manager_impl_test' failed; build aborted: Analysis failed

Hmm interesting, would be good to see whether 3.7 fixes this or not if we want to be unblocked.

Hmm interesting, would be good to see whether 3.7 fixes this

Indeed, it is interesting, https://github.com/bazelbuild/bazel/issues/12188#issuecomment-729773418 should tell us whether 3.7.1 resolves it. Evaluating rc2 at the moment.

Apologies, had to force-push the DCO I'd missed in the first push.

This is, finally, ready for final review and adoption ahead of integrating LLVM clang-cl in 11.0.0 (https://github.com/envoyproxy/envoy/pull/14135).
We will need to watch in the coming days and mark any newfound exceptions promptly as "flaky_on_windows", but there are future patches in the pipeline to automate this. I'd only ask that we note which specific test(s) fail (or timeout) to make quick progress on diagnosing the last few flakes.

/lgtm deps


Feat/implement-ci-nf-tests

PR checklist

[ ] This comment contains a description of changes (with reason).
[ ] If you've fixed a bug or added code that should be tested, add tests!
[ ] If you've added a new tool - have you followed the pipeline conventions in the contribution docs- [ ] If necessary, also make a PR on the nf-core/rnaseq branch on the nf-core/test-datasets repository.
[ ] Make sure your code lints (nf-core lint).
[ ] Ensure the test suite passes (nextflow run . -profile test,docker --outdir <OUTDIR>).
[ ] Usage Documentation in docs/usage.md is updated.
[ ] Output Documentation in docs/output.md is updated.
[ ] CHANGELOG.md is updated.
[ ] README.md is updated (including new tool citations and authors/contributors).

I notice that all the pre-fetching of the test data has been removed.
:crying_cat_face:
I would very like that to stay.
We had many issue with Nextflow/GHA interaction when getting these files, and that was a very efficient way to solve this issue.
We (Edmund, Phil and I) started doing that in other pipelines as well (methylseq first, sarek obviously).

Will be completed in https://github.com/nf-core/rnaseq/milestone/20


change branding on bottom bar: make a logo

Changed "Jekyll theme Sencilla" to "Sencilla". Enough.


404 - Not found when entered directly into the browser

When I enter the main page it works fine and go into another page it works fine.
But if I enter the another webpage in the url, it dont works. I get a 404 from Spring.
The problem is on the server side. I need to configure this.
I am building a Vue.JS & Spring Boot app which I am running through a docker container. The dist folder for Vue is copied to resources/public path and served through the Spring Boot service.
I have set up routes using vue router, but all of these routes return 404 - Not found when entered directly into the browser (but work fine when accesses through the Vue app).
What is the best solution to fix this? Should I create a .htacccess file?

Never mind. I had to create a redirect controller.
/* Redirects all routes to FrontEnd except: '/', '/index.html', '/api', '/api/**' /
@RequestMapping(value = "{_:^(?!index\.html|api).$}")
public String redirectApi() {
return "forward:/";
}

I think this should be reopened and added to the sample code!

@vikrun @renanleandrof  You're absolutely right - since we use mode: history (see Vue.js docs) now, we also need to forward every other request to the frontend again. Fixing this soon.

Should be fixed now, please have a look @vikrun @renanleandrof :octocat:

I tried it today and the redirect is not working, still showing the 404 using current version of master. How should this be fixed?

Yeah, same here. Tried that and got 404:
https://spring-boot-vuejs.herokuapp.com/callservice
=/

try to add another Controller
package de.jonashackt.springbootvuejs.controller;
import org.springframework.stereotype.Controller;
import org.springframework.web.bind.annotation.GetMapping;
@Controller
public class OtherController {
@GetMapping(value = "{_:^(?!index\.html|api).$}")
public String entry() {
return "index";
}
}

you just create new controller file, example: ForwardController.java
This example I want to path /about can forward to /about in vue.
`@RestController()
@RequestMapping("/")
public class ForwardController {
@RequestMapping(value = "about")
public ModelAndView redirectApi() {
    return new ModelAndView("index.html");
}

}`

@jonashackt This issue should be fixed by #79

Looks still not working. It looks the fix #79 didn't work because it's attached to the requestmapping /api
Anything outside /api will return a 404. I think manage this on a separate controller looks better like @velaan suggest it

I am able to redirect to the home page , but still haven't figured out a way to give control back to vue controller.

I think the current code only works for single-level request forwarding. For example:
/videos would work but /videos/5 would not.
Was able to get the second level working using:
@RequestMapping("{?:(?:(?!api|static|\\.).)*}/**")
but is there a way to not have to keep doing /** to continuously support more levels?

@AdrianLeeElder have you checked https://github.com/jonashackt/spring-boot-vuejs/pull/92? It should fix this issue for good.

@AdrianLeeElder have you checked #92? It should fix this issue for good.

That seems to be working perfectly! A small optimization would be to move the pattern into a static field so we're not recompiling the pattern on each request.


Documentation

Hi,
Can someone answer the following questions for me or preferably point me to documentation that answers questions like these? All the documentation I've been able to find so far has been pretty sparse.
Thanks,

What ranges are short range vs long range modes recommended for?
What is the difference between native and mixed modes?
What are A and B frames?
Are the intrinsics and distortion coefficients in the camera calculated specifically for that unit or is it recommended that we calculate our own coefficients?

Hi @jkablan!
Please find here the answers to some of your questions:

The ranges are associated to modes within the SDK; you can find some of them defined here: ([https://wiki.analog.com/resources/eval/user-guides/eval-adsd3100-nxz#:~:text=3mm depth error-,Modes of Operation,-Mode Index]{Here})

Since we developed the SDK and this part of the eval-board is developed by the firmware team, please address them in a separate mail.

"AB"  is an acronym for Active Brightness. It is similar to the Infra Red image.

Intrinsics and distortion corrections are calculated for each module and stored on the camera's NVM.

Best regards,
Robert Budai


Add support for better-sqlite3 as alternative to standard sqlite

When using sqlite with strapi the dependency of node based better-sqlite3 already persists. To remove the need of installing sqlite on the remote server just to use the sqlite backup, I added the possibility to use the better-sqlite3.backup feature for the database export.
The check for the sqlite executable was extended.
If the executable is not given in the config but better-sqlite3 is available, it will use the better-sqlite3 instead of throwing an error.
The exported file is bigger due to the filetype beeing a binary database file than just the text file of the sqlite.dump.
For me it was about twice the size.

Feedback welcome.

Looks good, this is the new default in Strapi v5 anyways so this makes sense 👍


Storing signature in Sonatype Nexus fails

Description
When attempting to use cosign sign, we get the following error:

cosign sign --key cosign.key onprem.nexus.local/crunchydata/crunchy-postgres:ubi8-14.3-0
Enter password for private key:
Pushing signature to: onprem.nexus.local/crunchydata/crunchy-postgres
Error: signing [onprem.nexus.local/crunchydata/crunchy-postgres:ubi8-14.3-0]: recursively signing: signing digest: POST http://onprem.nexus.local/v2/crunchydata/crunchy-postgres/blobs/uploads/: DENIED: Deploying to groups is a PRO-licensed feature. See https://links.sonatype.com/product-nexus-repository

Using cosign v1.11.0
We are using an on-prem OSS instance of Nexus - 3.28.0-01
@Cajga mentioned that he signed off on this integration. May be we are missing something in this use case?

Update: we identified that the docker tag as pointing to a Nexus group docker registry which is read-only by default.
Switching the docker tag to our hosted registry + ensuring that the docker client (using docker login) is logged to that registry solved the problem for us.
So for a Nexus hosted docker registry, the integration IS working as stated.
Though, we are currently investigating if we can add signatures to a Nexus docker proxy registry - that's a rather special use case.


Python is not allowed (Data Science)

https://learn-linter-ci.herokuapp.com/results/4535

Seconding Miles call out; receiving repeated error messages regarding Python snippets from the Learn Linter.


Nothing other than materials getting scanned

I get insufficient artifact count error for artifacts and so on. What am I doing wrong? I'm not moving mouse and have set window to windowed

This error generates a screenshot in the logging/artifacts/ folder. Please upload that screenshot so that we can help more.

here you go!

Are you positive your resolution was 1280x720? The screenshot is 1600x900.

Are you positive your resolution was 1280x720? The screenshot is 1600x900.

Oh I was just trying out different settings. It didn't work with 720 windows nor 1600x900 windowed. I will try again tomorrow and update


Interaction with github api

@l3r8yJ 2 puzzles #21, #22 are still not solved.

after #22

@l3r8yJ 4 puzzles #21, #24, #25, #26 are still not solved; solved: #22.

@l3r8yJ 4 puzzles #21, #25, #26, #28 are still not solved; solved: #22, #24.

@l3r8yJ 3 puzzles #21, #26, #28 are still not solved; solved: #22, #24, #25.

@l3r8yJ 2 puzzles #21, #28 are still not solved; solved: #22, #24, #25, #26.

@l3r8yJ 3 puzzles #21, #32, #33 are still not solved; solved: #22, #24, #25, #26, #28.

@l3r8yJ 2 puzzles #21, #32 are still not solved; solved: #22, #24, #25, #26, #28, #33.

@l3r8yJ the puzzle #21 is still not solved; solved: #22, #24, #25, #26, #28, #32, #33.


host.fact.command strips lines

Describe the bug
host.fact.command (and actually anything using a command from FactBase?) removes leading and trailing whitespace of every line.  This makes parsing indentation-sensitive output impossible.
To Reproduce
print(host.fact.command('echo "    whitespace   "'))

Expected behavior
it should print ␣␣␣␣whitespace␣␣␣, not "whitespace".
Meta

--> Support information:

    If you are having issues with pyinfra or wish to make feature requests, please
    check out the GitHub issues at https://github.com/Fizzadar/pyinfra/issues .
    When adding an issue, be sure to include the following:

    System: Linux
      Platform: Linux-5.7.7_1-x86_64-with-glibc2.2.5
      Release: 5.7.7_1
      Machine: x86_64
    pyinfra: v1.0.4
    Executable: /usr/bin/pyinfra
    Python: 3.8.4 (CPython, GCC 9.3.0)

Target is a OpenBSD machine, but I don't think this matters.

https://github.com/Fizzadar/pyinfra/pull/396

The fix has now been merged for this! Will be included in 1.1 which I'm aiming to release this/next week.

1.1 is running a little late but I've dropped 1.1.dev0 which makes this accessible!


added additional props, and ability to control layer visibility

Added the name and layerType prop to allow vue2leaflet layer control to add googlemutant layer to layer control menu. Also, added a prop to toggle layer visibility to match vue2leaflet tile layer component. This should close this issue.

thanks! I'll publish it now


logging exceptions should not be controlled by DEBUG and should default to enabled

It would be really good for server to use the syslog (also python logging) conceptual model.  In particular, logging uncaught exceptions would not be controlled by a option called DEBUG.  This is at least level
Error'.  This should default to on'.
see https://en.wikipedia.org/wiki/Syslog#Severity_level
Since logging exceptions is the only thing controlled by `DEBUG',  please change this to default to True until it can be made consistent with syslog.

https://github.com/ga4gh/server/blob/99aafd4b83ac4d65a73b37a152e1851b3be82f70/ga4gh/frontend.py#L343

You can work around this problem by adding the line
DEBUG=True
in the config.py file and restarting apache.

We should do proper logging, following the Flask patterns
Turning on DEBUG by default could have very serious security implications! From the Flask documentaion

Even though the interactive debugger does not work in forking environments (which makes it nearly impossible to use on production servers), it still allows the execution of arbitrary code. This makes it a major security risk and therefore it must never be used on production machines.

So, we need to find another way to work around this problem.

We will be moving away from flask. Python logging, which is
based on syslog, is a far better understood model than flask.
Leave the flask variables for flask stuff and don't mix them
and they will be fine.
The problems seem to be:

DEBUG is not documented in the config file as something the
controls flask, or for for that matter what it controls.
From looking at the code, it appears to only control logging
of exceptions.

Logging of exceptions (except ones reporting a user error),
is vital for a production server.  It shouldn't be controlled
by the DEBUG variable.

Jerome Kelleher<EMAIL_ADDRESS>writes:

We should do proper logging, following the Flask patterns
Turning on DEBUG by default could have very serious security implications! From
the Flask documentaion
Even though the interactive debugger does not work in forking environments
(which makes it nearly impossible to use on production servers), it still
allows the execution of arbitrary code. This makes it a major security risk
and therefore it must never be used on production machines.

So, we need to find another way to work around this problem.
—
You are receiving this because you authored the thread.

However, the server IS a Flask app, for better or worse. We can't ignore the fact that it is, and a administrator can't deploy safely or sensibly without knowing how Flask configuration works and what the overall options are. Pretending Flask isn't there will just end up making things worse. So, for production, we need to understand how Flask works, and  work with it rather than against it.

I am not arguing for pretending it isn't there, only making it
clear that is it and what is flask and what is not.  I just
filed a bug on config.py documentation as it doesn't describe
DEBUG at all, even say `RTFM Flask'
If we have our own logging, it doesn't need to be he tied to
flask, but would be to have a clear model and go through the
python logging API, even if this ends up in the flask log.
In fact, this is a non-issue:
http://flask.pocoo.org/docs/0.10/errorhandling/
"Flask uses the Python builtin logging system,"
so the real problem is we are misusing (and not documenting) the DEBUG
config.py option.

However, the server IS a Flask app, for better or worse. We can't ignore the
fact that it is, and a administrator can't deploy safely or sensibly without
knowing how Flask configuration works and what the overall options are.
Pretending Flask isn't there will just end up making things worse. So, for
production, we need to understand how Flask works, and work with it rather than
against it.
—
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub*

OK, here's our actual manual @diekhans: http://ga4gh-reference-implementation.readthedocs.org/en/stable/configuration.html#configuration-file
We do not attempt to document any of Flask's config variables but instead point the user to the Flask documentation. Note the ..warning block about DEBUG. I think this confusion has been caused by reading the source rather than reading the manual.

RTFM, who, me !?!?!
I am reading the config file!  A pointer back to the doc in the
config file would solve this nicely.
Jerome Kelleher<EMAIL_ADDRESS>writes:

OK, here's our actual manual @diekhans: http://
ga4gh-reference-implementation.readthedocs.org/en/stable/configuration.html#
configuration-file
We do not attempt to document any of Flask's config variables but instead point
the user to the Flask documentation. Note the ..warning block about DEBUG. I
think this confusion has been caused by reading the source rather than reading
the manual.
—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub*