edtlib: tests: refine coverage of Binding objects initialization

Bindings initialization supports a rich include mechanism:

a base binding may be include:ed at any level: binding, child-binding, grandchild-binding, etc, the specified properties being injected (in cascade) at the level of inclusion
whenever an include: appears, the including binding may filter the properties it chooses to inherit at the binding, child-binding, etc, levels; these filters apply across included files
when several base bindings are inherited which contain definitions about a same property, sometimes the last one wins, but not always, and quite a few things are not allowed (e.g. downgrading a required: true or changing a const: value)
some scenarios remain undocumented, e.g. diamond inheritance

All this happens (recursively) in the Binding constructor, independently of any actual devicetree model (EDT instance).
This commit is the first in a series which will try to cover somewhat systematically the possible inputs and what we finally get at the exit of the constructor once the object is completely initialized.
Thanks.
See also:  #78095

The build failure seems to be unrelated to this change.
/opt/toolchains/zephyr-sdk-0.16.8/arm-zephyr-eabi/bin/../lib/gcc/arm-zephyr-eabi/12.2.0/../../../../arm-zephyr-eabi/bin/ld.bfd: warning: orphan section `DMA_RAM21' from `zephyr/drivers/pwm/libdrivers__pwm.a(pwm_nrfx.c.obj)' being placed in section `DMA_RAM21'

The build failure seems to be unrelated to this change.

I think so too: if this PR were to fail by itself, it would do so in some "Devicetree script tests", since it only adds unit tests to python-devicetree (which are not supposed to fail).

Could you remove this commit from #78095 then? I assume it is verbatim the same that I reviewed there?

No, it's not. This PR adds only the unit tests that the current implementation of edtlib.Binding is supposed to pass, which is a small part (unfortunately).
The other tests will be added as we address the issues raised while working on #78095:

ignored or broken property filters when A includes B includes C (see #79948)
failing to overwrite property descriptions in certain circumstances (also  relates to properties inheritance, fixing the above issue should also help with this one)
failing to overwrite binding descriptions in certain circumstances (a different issue, does not relate to properties)
is diamond inheritance allowed ? if so, what should happen (e.g. what you get may depend on the order in which files are included) ?

The rationale is to merge unit tests as soon as we can to avoid regressions as we triage/fix the above issues.

Could you remove this commit from #78095 then? I assume it is verbatim the same that I reviewed there?

No, it's not. This PR adds only the unit tests that the current implementation of edtlib.Binding will pass, which is a small part (unfortunately).
The other tests will be added as we address the issues raised incidentally while working on #78095:

ignored or broken property filters when A includes B includes C (see edtlib: indirect "include:"s break property filters #79948)
failing to overwrite property descriptions in certain circumstances (also  relates to properties inheritance, fixing the above issue should also help with this one)
failing to overwrite binding descriptions in certain circumstances (a different issue, does not relate to properties)
is diamond inheritance allowed ? if so, what should happen (e.g. what you get may depend on the order in which files are included) ?

The rationale is to merge (and run) unit tests as soon as we can to avoid regressions as we triage/fix the above issues.
[Edit: then we may rebase #78095 onto all this, and rethink the PropertySpec.path thing that brought us there ;-]

Ok, good. IIRC you wanted to add separate issues for those, right? If you like you could reference PRs with the corresponding failing tests to those issues. I'll try to address those issues as quickly as possible then once we agreed in arch WG what the general direction will be for configuration.

I think commit eb45da5a440256cf55571a69035a19975a229650 has since fixed the unrelated error reported by the CI.

Ok, good. IIRC you wanted to add separate issues for those, right? If you like you could reference PRs with the corresponding failing tests to those issues. I'll try to address those issues as quickly as possible then once we agreed in arch WG what the general direction will be for configuration.

@fgrandel , I pushed a PR reverting #65221, which seems to address all known issues with property filters (#79948): could you please take a look #80030 ?
Once it's merged, we can add the related unit tests here (before we merge this PR, rather than creating another one on purpose).
The only remaining concerns that I'm aware of are (with failing unit tests at hand):

inability to overwrite descriptions (bindings as well as properties) in certain circumstances
diamond inheritance (I1 and I2 include X, B includes I1 and I2)
I think we can entirely forget all test cases involving the "last modified here" thing until we find a proper implementation for what #65221 tried to achieve

Thanks.

Confusing, at least for me with my limited brain capacity. But I'm referring with this to the include and inheritance system itself.

True. Includes is fine but the filters are not.
IMO another instance of how convoluted design generates more convoluted design. Had we made it easier to influence the schema below the parent node in more flexible and obvious ways, we'd probably never had the idea to first design an inappropriate schema just to make it appropriate down the inheritance line by filtering it. :-D
I don't think anyone will want to use filters once we have a proper child definition language in place. I'm quite positive that we'll be able to deprecate filtering down the line.

@dottspina Have you seen that there are failing tests? Guess you'll have to fix them before you get more reviews. ;-)

@dottspina Have you seen that there are failing tests? Guess you'll have to fix them (even though they seem be unrelated) before you get more reviews. ;-) Maybe a rebase helps?

I was thinking of perhaps waiting until #80030 is merged, to be able to add the unit tests for inheritance here (which would otherwise fail).
Of course, I'm fine with doing the other way around, I've rebased this (to trigger the CI, ), I'll add the tests where they fit afterwards (once this is merged).
@fgrandel , I'm afraid you'll have to review this again (even though the PR's content has not changed at all).
Thanks.

Confusing, at least for me with my limited brain capacity. But I'm referring with this to the include and inheritance system itself.

True. Includes is fine but the filters are not.
IMO another instance of how convoluted design generates more convoluted design. Had we made it easier to influence the schema below the parent node in more flexible and obvious ways, we'd probably never had the idea to first design an inappropriate schema just to make it appropriate down the inheritance line by filtering it. :-D

Just my two cents: yes, the include and inheritance system is, in a way, confusing by-design, I've felt it more than once too, but I'm not so sure the issue is specifically the use of property filters to describe child bindings.
AFAICT, the property-{allow,block}list: syntax was added to the include: mechanism to allow a device binding to filter the properties it chooses to inherit from a base binding (#29498). Or, paraphrasing #29306, to describe that a property should not exist in the DTS as it doesn't make sense for that specific compatible.
This seems like a legitimate use case to me (note that child bindings support was considered last there, not the initial rationale).
Let me give an example, based on st,stm32-temp-cal.yaml, where you read:
compatible: "st,stm32-temp-cal"

include:
  - name: st,stm32-temp-cal-common.yaml
    property-blocklist:
      - avgslope
      - ntc

Here, property-blocklist filters out, say, the base properties for this kind of device (specified in st,stm32-temp-cal-common.yaml) which this particular device (st,stm32-temp-cal) does not support.
Nothing shocks me so far, the syntax is used for what it's intended.
Same when this happens at the (grand) child binding level, e.g. in nxp,lpc-iocon-pinctrl.yaml (you'll find this structure for most pin configrations in pin groups):
child-binding:
  description: LPC IOCON pin controller pin group
  child-binding:
    description: |
      LPC IOCON pin controller pin configuration node

    include:
      - name: pincfg-node.yaml
        property-allowlist:
          - drive-open-drain
          - bias-pull-up
          - bias-pull-down
          - drive-push-pull
          - input-schmitt-enable

What troubles me is rather reading bindings like bellow (renesas,smartbond-lp-osc.yaml.yaml):
compatible: "renesas,smartbond-lp-osc"

include:
  - name: fixed-clock.yaml
    property-allowlist:
      - status
      - compatible
      - clock-frequency

Here I find confusing that we recursively pull all properties specified in fixed-clock.yaml (of which clock-frequency), in clock-controller.yaml, in base.yaml (of which status and compatible), and in pm.yaml, then eventually filter out everything but three of them:

the intent is not as clear as it could be: we just wanted to say "this Smartbond low power oscillator is a device (with a status and possibly a compatible string) that provides a fixed-rate clock (the fixed frequency)"
it's not obvious what we finally inherit and from where

If we were able to describe the binding as bellow, everything would be crystal clear:
compatible: "renesas,smartbond-lp-osc"

include:
  - name: device.yaml
  - name: fixed-clock.yaml

The above example is a bit simplistic, just to sketch out my thinking. Now take a look at this (nordic,owned-partitions.yaml):
compatible: "nordic,owned-partitions"

include:
  - name: nordic,owned-memory.yaml
    property-blocklist:
      - reg

child-binding:
  include:
    - name: base.yaml
      property-blocklist:
        - compatible
  properties:
    reg:
      required: true

Try to guess what this binding (compatible) is for without the human readable description:s (which I striped). What properties are allowed, actually supported (useful), or required, and at what level ;-).
Here the use of property filters can indeed seem more like some hack to get all we may need while preventing issues (e.g. possibly overwriting the expected binding if someone absentmindedly set a compatible: to the node in the DTS), than a valuable syntax to actually describe the binding: e.g. do we really intend to say that the child nodes support all properties specified in base.yaml (and therefore pm.yaml) but should not have a compatible string? I'm not sure.
Compared to, e.g.:
compatible: "nordic,owned-partitions"

include: nordic,partition-table.yaml

child-binding:
  include: memory-partition.yaml

To me, these examples don't show that property filters (at any level) are broken per se, but perhaps we're missing the finer-grained basic bindings that would allow us to write more consistent (and readable) device bindings.
Bindings had to be added to support new devices, and a perfect inheritance hierarchy may not always have been the priority (this is not a criticism, just history).
Another aspect of the include: system that I find confusing is the rules that (should) apply when the same property is inherited multiple times, either because the same base binding is included several times, or because different included files specify properties with the same name (both situations actually occur).
I even happened to write tests and try to deduce the expected rules from their results, which didn't always turn out to be consistent.

I don't think anyone will want to use filters once we have a proper child definition language in place. I'm quite positive that we'll be able to deprecate filtering down the line.

As previously mentioned, IMO property filters were introduced to be able to quickly add supported devices without having to first multiply base bindings with stricter separation of concerns, not as something specifically needed (or useful) to describe child bindings (child nodes).
So I'm not entirely convinced that a "proper child definition language" will "deprecate filtering down the line" ;-)
This is not to say that approaches like #79751 are not interesting (or even desirable), just that it does not seem to address the same use cases property-{allow,block}list were added for.

Updated PR content:

bindings' descriptions and compatible strings inheritance: add updated unit tests that pass with the current library behavior, documenting this behavior, rather than assuming a different behavior
property filters when "B filters I includes X": add unit tests documenting the issue, but disabled by default
Last modified semantic of PropertySpec.path: we decided to forget this issue until we know how to handle it properly, so do not include anything related in this PR

Inheritance of bindings' descriptions and compatible strings
Consider the binding file bellow:

description: Binding's description.

compatible: vnd,device

include:
  - name: base_first.yaml
  - name: base_last.yaml

Where both base_first.yaml and base_last.yaml set a description: and a compatible: at all levels (binding, child-binding, grandchild-binding, etc).
The rules deduced from the edtlib library behavior are:

the included bindings (base_first.yaml and base_last.yaml) can't overwrite the compatible: and description: set by the including binding, despite that description: and compatible: appear before include: in the binding file: it seems consistent that the including binding wins
at the child binding levels (child-binding, grandchild-binding, etc), descriptions and compatible strings will depend on the order in which the binding files are successively included (named:ed): the included first wins
the rule above would also apply at the binding level if the including binding did not itself contain description: and compatible: elements

With the same inheritance diagram, the included first wins rule also applies to property descriptions inheritance.
I previously assumed that in these later situations the included last would instead win, as long as overwriting descriptions and compatible strings is permitted, and corresponding unit tests were put aside because they were known to fail.
I've updated these tests to match the current behavior of the library: so now we can add (merge) them too.
Indirect property filters
This PR now also includes the unit tests which cover all issues documented in #79948.
These six unit tests are expected to fail until the issues are fixed (see #80030), and disabled by default, e.g.:
# Disable testing a known issue:
# - edtlib: indirect "include:"s break property filters
# - https://github.com/zephyrproject-rtos/zephyr/issues/79948
#
# See also:
# - https://github.com/zephyrproject-rtos/zephyr/pull/80030
TEST_ISSUE_79948: bool = os.environ.get("EDTLIB_TEST_ISSUE_79948") is not None

@pytest.mark.skipif(not TEST_ISSUE_79948, reason="Expected to fail (#79948).")
def test_filter_inherited_propspecs_basics() -> None:
    ...

Rationale:

this permits to document these issues
while not causing CI errors (when running the python-devicetree unit tests)
later enabling these tests without causing errors should allow us to consider the related issues are fixed

Last modified semantic
In #65221 we tried to get more valuable answers from the PropertySpec.path API, which is supposed to tell in which binding file a property's specification was last modified.
This patch:

failed to achieve its goal (#78095)
introduced a regression when applying child-binding filters to indirectly inherited properties (#79948)

We decided to forget all this until we find a proper approach: nothing here tests this last modified thing, and #80030 will also revert the related unit tests.


Ddoc no hardcoded characters

https://github.com/dlang/dmd/pull/6972 moves some stray line feeds from the ddoc engine into macro definition. This diff does the same for the dlang.org macros.

How do I get rid of the stray commit from unrelated work? Thx!

How did you end up with a commit from unrelated work? Did you commit to the wrong branch?
Since only one commit is involved here, the simplest solution I can think of is to checkout a new branch from master, apply the diff, and push that instead of what you have here.
Also, on that note, in the future be careful of where you invoke git checkout -b ..., because it takes the current branch as the base for the newly-created branch. To be safe, for creating PRs, you should always precede that with git checkout master so that your new branch doesn't "accidentally" inherit commits from an unrelated branch.

Superseded by https://github.com/dlang/dlang.org/pull/1809/


cli: add option to choose color manually

I'm currently working on a full integration with fzf and himalaya auto-detects FZF_DEFAULT_COMMAND and --preview as no tty. It would be great if these changes could be merged.

I also fixed the tests, cause someone broke it :)

Thanks a lot for your contribution :slightly_smiling_face: the v0.6 should come very soon (within few days) with big structural and API changes, I come back to you whenever the development branch is up-to-date!

I just released the v0.6.0, which includes the code splitting. Sorry for the conflicts! But they should be easy to fix, everything move down a level (there is no more cli folder). Let me know if you need help. Once the conflicts resolved we will be able to merge your PR :slightly_smiling_face:

I was not able to push directly on your fork, so I pushed your changes directly on develop. Thanks a lot for your contribution and sorry for the delay! I should be available in the next release #433.


IAM v2 Users, Teams, and Tokens

All items have been moved to the GA epic so we are closing this one out.


Empty page content on 1.20.4

With paper API (content isn't null or empty , it is "Mail Content")
        final ItemStack writtenBook = new ItemStack(Material.WRITTEN_BOOK);
        writtenBook.setItemMeta(((BookMeta) writtenBook.getItemMeta())
                .toBuilder()
                .addPage(manager.getPlugin().getComponentProvider().parse(content))
                .build());
        player.openBook(writtenBook);

With Adventure (content isn't null or empty , it should say "Mail Content")
        bukkitAudiences.player(player).openBook(
                Book.builder()
                        .addPage(manager.getPlugin().getComponentProvider().parse(content))
                        .build());

I have the latest version of paper and adventure

If you're using the latest version of Paper why are you using adventure-platform? Paper has shipped with Adventure for years now.

The second one is with adventure-platform. but now i am thinking that this is the wrong repo to open this kind of issue

I'm a bit confused about what the issue is here. Are you saying that adventure-platform's openBook method is not working on 1.20.4?

Well who knows now


providing credentials via awsAccessSecret does not work

/kind bug
What happened?
Providing credentials via values.yaml awsAccessSecret does not work.
Creating /root/.aws/credentials with the correct credentials and retrying works.
What you expected to happen?
It should work without the credentials file on the host (/root/.aws/credentials)
How to reproduce it (as minimally and precisely as possible)?
Anything else we need to know?:
Environment

Kubernetes version (use kubectl version):
kubectl version
Client Version: v1.28.2
Kustomize Version: v5.0.4-0.20230601165947-6ce0bf390ce3
Server Version: v1.29.0+k3s1
Driver version:
helm chart 1.2.0
Driver version: 1.2.0, Git commit: 8a832dc5e2fcaa01c02bece33c09517b5364687a, build date: 2024-01-17T16:52:48Z, nodeID: lp3dnode, mount-s3 version: 1.3.2

Are you putting the actual credentials in values.yaml? Or are you trying to set a different name for the k8s secret?
The settings in values.yaml just tell the driver what key to use when looking for the actual key and key id. See the install doc for how to set the credentials with kubectl: https://github.com/awslabs/mountpoint-s3-csi-driver/blob/main/docs/install.md#secret-object-setup. The example uses the default name of aws-secret.
If you are already setting the k8s secret according to the docs, please provide more details on how we can try to reproduce.

Sorry, this was my fault. No everything works.
Thanks
Ognian


Add scan start blockheight parameter in config

It seems like rescan starts from block 0

As found here and here
These scans are expensive and wastes plenty of time, its best to start from a checkpoint height where bootstrapping and whatnot begins.
This checkpoint height should be in the oracle_config.yaml file

We did that initially, but it did not work. Since the wallet does not see anything before this height, you end up with an empty wallet if you sent coins to it before this height.

Yes that's why it should be configurable in the oracle_config.yaml file


Update README.rst to reflect name of annotate_citations function

Current examples raise: TypeError: 'module' object is not callable. It looks like the name of the function was changed to annotate_citations and the README was not updated.

 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.

Thanks. Sorry about that.


web server not working

Just reinstalled FM from DockerHub image onto a new server. Waited for a couple hours to finish download-converting job. I see, that .mp3 and .xml files are generated. But I fail to get any data from web-server. All urls: /rss /feed /yt/ are returning error 404. And the following error is in log:
{logger/logger.go:134} GET - /yt/UCWAIvx2yYLK_xTYD4F2mUNw - xxxxxxxx.dynu.net - unknown ip - 404 (19) - 27.297µs
What does it mean? Previously my config worked on another server.

web server is working fine, probably some issue wit the configuration. In order to help you with this I need to see your docker-compose.xml and fm.xml as well as the full log generated from the moment you started the container.
I'll move it to discussions as it doesn't seem to be the actual bug but rather something on your side


Allow to reset the entire environment of Studio Lab

Is your feature request related to a problem? Please describe.
When the students use the Studio Lab in the lecture, they often forget to create an isolated environment for the lecture, install all the packages to default environment. We can’t delete the default environment, for that reason wasted default environment consume the storage.
Describe the solution you'd like
Allow the teachers to guide the students as following.

Reset the entire environment
Execute the right procedure from the first.

Describe alternatives you've considered
We can rollback the conda environment by #42 . But this procedure only rollback the conda packages, pip packages are not rollbacked.
Additional context
(none)

Please try to deactivate conda env you wish to remove and then remove completely. In below example I am removing env name  "playground"

(playground) studio-lab-user@default:~$ conda deactivate
(studiolab) studio-lab-user@default:~$ conda remove --name playground --all
This will remove all packages in environment /home/studio-lab-user/.conda/envs/playground:

Restore/Reset env again with Studio default please use the Yaml file from /opt/amazon/sagemaker/environments/

conda env create -f studiolab.yaml or default.yaml
Hope this helps. A restoration script can be added when Studio env is provisioned to users.
Thanks!

@choudhary-ai Thank you for your comment! I think conda remove only works named environment but not default environement (studio-lab). This feature is for the students who forget to create named environment and already worked in default environment.
https://stackoverflow.com/questions/52830307/conda-remove-all-installed-packages-from-base-root-environment
Do you have the idea that can reset default environment by conda command?

As alternative way, we can reset the environment by the following proceduer.

Check initial version by conda list –revisions
Restore environment by conda install –revision n
Delete unnecessary packages by . conda clean –all

an easier way to reset is coming soon, in the meantime icoxfog417, thanks for those instructions.

hey, just use this code. This deletes all sub directories of the default user i.e. you get a fresh  cleaned  up storage. with 25 gb (all) storage available.
rm -rf /home/studio-lab-user/*

Hello you can follow the following steps and run the codes provided herewith in a terminal (you can open a terminal after ) :
After you have done all of this stop your project from sagemaker main dashboard. Open a new project. Now you will  get a fresh new notebook with almost all the space available. (You can check available space by running "df -h", take  a look at Avail row beside "/home/studio-lab-user").
Note that this process frees us 'almsot' all he space, you may still have 2-3 gb of occupies space.  Still d'ont  know how to  fix it
`#1.  switch to base conda environment
conda activate base
#2. List all conda environments available in your account
conda  list envs
#Take a look at all the conda environments  available
#3. Delete all the conda environments except environment named 'base'
conda remove -n "env_name" --all
#4.Delete all subdirectories from user folder
rm -rf /home/studio-lab-user/*
#Restart project/runtime`

Dear @yeasin-arafat-rafio, thank you for sharing your knowledge! We complement your instruction based on our implementation knowledge.

The #1 to #3 is enough to reset conda environments. These commands delete the preset environments such as default , studiolab , studiolab-safemode, but these are recovered after we restart the project runtime.
The #4 delete the all your files. For that reason, please do not execute this command except you want to delete all of the files you created.


Node config baseId cannot be set as en ENV var

Hi!
I'm trying to set the baseId in the airtable config node to use an env var like ${AIRTABLE_BASEID}
I defined the env var in the settings.js like : process.env.AIRTABLE_BASEID = process.env.AIRTABLE_BASEID || "appXXXXXXXXX";
I also verified that Node-red reads the env var correctly via an inject set to type ENV VAR and it debugs fine.
But it is not working as it seems like airtable node thinks the baseId is the string "${AIRTABLE_BASEID}" instead of the underlying env var.
So far I only have a workaround by putting the baseId in each airtable node properties (instead of leaving it in the config node)

Found out how! Please look at PR. Thanks!

PR merged


process -1

-1 for the process (as in !process -1 0) is mentioned but I don't think it says that this gets the current process.

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

ID: a818b121-53b3-c6a6-853a-2d9640912cc6
Version Independent ID: 94c9600f-97aa-7a38-1423-ba76a9a32c42
Content: process
Content Source: windows-driver-docs-pr/debugger/-process.md
Product: windows-hardware
GitHub Login: @DOMARS
Microsoft Alias: domars

@lawabider - Thanks for this suggestion, I added wording to indicate that -1 displays the current process.


hover added to "Courses"

I have created a new pull request for this.
I have added hover to "Courses"
Issue reference - #79

@anmode Could you please add GSSOC'23 Label for this pull request.


could you please add some document on how to write binding function for existing javascript library

or write a demo for it.
I want to use ProtoBuf.js in elm, but after some google, I could not find any doc on how to call js functions in Elm...
port FFI could not import function type
I looked Elm/libraries/Native/*js but I still can't get it right for now...

@DavidFeng I too would like to use protocol buffers with Elm. Did you have any luck? Is there an old sample I can see?


Make shape a tuple

Proposed changes
Switch to tuple shape in Python.
Companion PR in mlx-examples: https://github.com/ml-explore/mlx-examples/pull/393

@awni Do we need to go and change the docs for ops that require shape as an argument to be tuples ?
I don't think it's needed at the moment, but thought I should ask

Do we need to go and change the docs for ops that require shape as an argument to be tuples

Luckily I don't think so, for all of those ops the shape can be either a tuple or a list. That was already the case before this change. We may want to make it more clear in the docs but I'll leave that as a future update:
>>> mx.zeros([2, 2])
array([[0, 0],
       [0, 0]], dtype=float32)
>>> mx.zeros((2, 2))
array([[0, 0],
       [0, 0]], dtype=float32)

Ok I'm merging this!! Something is almost certainly going to break so just keep an eye out! I checked most things in core and examples though so that should be ok.

@awni this seems to close #297.
It would be intriguing to learn the decisive factor that prompted the implementation of proposal #297.


Implement startup file storage

I talked to @aleDsz and unfortunately I was not clear when describing the issue. I meant to say we want file systems in startups for Livebook Teams :) exactly as secrets for LB Teams


Where is the DSSM code

Firstly, thanks for your insightful job.
I am wondering where is the training code of DSSM?

Thanks for the mention and sorry for the late reply.
We have updated the DSSM code used in our experiment in bce_vision/main-end2end(DSSM)/'' and bce_text/main-end2end(DSSM)''. The code framework of the DSSM-version is similar to the SASRec-version in other files, the different part is the model.py and encoder.py, and some corresponding settings in run.py, train_xxx.py, and metric.py.

Thanks for your reply


Validate error

nylo_framework: ^5.0.2
Example:
  validate(
        rules: {
          "name": "not_empty",
          "email": "email",
          "phone number": "regex:(^[+\(\d+\)]+)"
        },
        data: {
          "name": nameFieldValue,
          "email": emailFieldValue,
          "phone number": phoneFieldValue,
        },
        messages: {
          "Name": "Name failed",
          "Email address": "Email failed",
          "Phone number": "Correct phone number format: +(**)**********"
        },
        onSuccess: () {
        },
        onFailure: (Exception exception) {
          print('Validate error: ${exception.toString()}');
        },
        showAlert: true,
        alertStyle: ToastNotificationStyleType.DANGER);
  }

Alert doesn't show correct messages.It works only for first field

Working on a fix for this @andim27, thanks for highlighting it

Hi @andim27,
This is fixed in v5.1.0 🚀


[move-vm] Add load_script to session API

Motivation

allow for easy adapter rules, as was similarly intended with the load_function API
Fix some vector operations

Test Plan

new test

Fixes #13


Patch Rails to fix security vulnerability

Bump Rails gem to 3.2.22 to fix
https://groups.google.com/forum/#!msg/rubyonrails-security/bahr2JLnxvk/x4EocXnHPp8J
The Rack vulnerability is also fixed in this PR as it is bumped to version 1.4.6

3.2.22 does fix some issues, but doesn't fix: https://groups.google.com/forum/#!topic/rubyonrails-security/7VlB_pck3hU
@boffbowsh is working on fixing that for 3.2.22.

Needs this adding: https://gist.githubusercontent.com/boffbowsh/073d4f36f8677304fa9f/raw/c5eebb5b80c5f261917aab94555805ef34db9cc3/cve_2015_3226_fix.rb


Configurable MaxLifeTime Variance

Refactoring MaxLifeTime connection variance to utilize a configurable setting rather than a static 2.5%.
2.5% will remain the default however developers can choose to override this for a more aggressive percentage if desired.

Just wanted to leave a comment linking back to the open issue where I discussed the problem a little bit more at length.
https://github.com/brettwooldridge/HikariCP/issues/2004

Here is an example of the default hikari variance that has a maximum of 2.5% variance

Here is an example with a much more aggresive maximum variance of 30%

The large spikes / mass closing of connections is much more smoothed out.

Great suggestion, went ahead and changed it.

Would love to see this merged.

Can someone please bless and merge this PR?  Thundering herds are problematic and can only be prevented by the clients staggering their connections.

I think I would prefer a solution to this problem that doesn't require the user to configure anything. I don't see any reason why we wouldn't want to avoid these timing issues for everyone.
It seems like there has to be a way to implement this that would allow the connection close timings to be as near a flat graph as possible.
If, for example, the lifetime was 10 minutes and the connection count is 10, to be flat we would want a connection closed once per minute (rather than 10 near the end of 10 minutes). If the system is up and running with a fixed size pool this would be a fairly straight forward. But even with a fixed size pool, you don't really want a connection closed after exactly one minute of running after startup. So there would be some heuristic to ease into the target flat graph. In the case of a non-fixed size pool it might be a little less straight forward.
In this scenario, even when closing 1 every minute, we wouldn't likely want a little randomness in there as if there were two applications both running HikariCP pointed at the same database, there is a chance that they would be on identical timings which would result in a similar spiky graph as far as the database is concerned. I haven't actually thought this out but my instinct tells me that would be a concern.
Any thoughts?

I think I would prefer a solution to this problem that doesn't require the user to configure anything. I don't see any reason why we wouldn't want to avoid these timing issues for everyone.

My thought process for this PR was to make this configuration option transparent by default as not to impact any existing deployments existing Hikari config settings on upgrade. However this could be achieved by simply changing the default value I provided to be something more aggressive than 2.5% which is what it has OOTB today.

It seems like there has to be a way to implement this that would allow the connection close timings to be as near a flat graph as possible.
If, for example, the lifetime was 10 minutes and the connection count is 10, to be flat we would want a connection closed once per minute (rather than 10 near the end of 10 minutes). If the system is up and running with a fixed size pool this would be a fairly straight forward. But even with a fixed size pool, you don't really want a connection closed after exactly one minute of running after startup. So there would be some heuristic to ease into the target flat graph. In the case of a non-fixed size pool it might be a little less straight forward.
In this scenario, even when closing 1 every minute, we wouldn't likely want a little randomness in there as if there were two applications both running HikariCP pointed at the same database, there is a chance that they would be on identical timings which would result in a similar spiky graph as far as the database is concerned. I haven't actually thought this out but my instinct tells me that would be a concern.
Any thoughts?

My thoughts are, when utilizing this approach it may take a very long time for larger connection pools to expire connections through existing settings like "maxLifeTime". If you had a 100 connections instead of 10 connections it would take approximately 100 minutes to cycle all of your db connection pool which may not be desirable for all use cases. Hypothetically we could go with some sort config setting that allows simultaneous connections to refresh based on a percentage of total connections to increase this speed however I still think you should still expose these setting to the user to allow for flexibility across different implementations.
Irrespective of that, I feel that this approach would require a substantial but not impossible change to the Hikari connection reuse flow. Currently if a connection exceeds its configured maxLifeTime + (variance) and is no longer utilized its immediately removed from the pool and released/renewed, where this approach would be batching connections for the next cycle.
The above solution you proposed would indeed deliver an even more normalized cadence than a customizable variance however, but I think we both solutions could work with the correct hikari config

My gut tells me that there isn't really any reason one user would want a different configuration from another user. And by exposing it as a configuration parameter rather than just fixing the algorithm or behavior to be correct™ means that many users who would want a more smoothed out wouldn't get it without having to investigate.
One thought experiment: Is it conceivable that if we changed the default variance calculation to use your specific desired value it would actual not cause a problem for anyone else?
You mention a target variance of 30%. What would be the negative of just changing the current hardcoded variance to be 30% rather than 2.5%?
Also, what is the MaxLifeTime setting you are using currently using? Maybe it makes sense to just change the current code to increase the variance in proportion of the MaxLifeTime.
If your change was just an unofficially supported system property I would feel more comfortable merging it. But the addition of a configuration property means it becomes API and somewhat locks us in on this implementation.

@lfbayer this PR seems stuck unfortunately.
I opened the original request to uncouple the 2.5% variance from the hard coded value.  I personally am fine with a parameter to get around the hard coded value, I am also fine with any implementation that gets us close to a better solution.  I just don't want to see progress stopped without a solid alternative plan.
FYI, this problem frequently shows up in environments where applications are deployed to k8s and all scaled up at the same time.  The tight variance on a short maxLifetime frequently leads to a thundering herd of connections and observable spikes in latency on performance graphs.

My apologies for not following this PR closer.
I agree with @ssherwood 's point. At this point I would just like to get some solution for this merged so that others utilizing k8s deployments can mitigate thundering herds. I'm happy to refactor this PR in order accomplish this.
I have been using 30% via a forked branch for my production application successfully for about a year now. If there is consensus that changing the default system value from 2.5% to 30% is the best approach I am happy to refactor to just change this value. I understand @lfbayer 's concerns about configuration locking us into an api, personally I prefer the flexibility of configuration but I'm open to either solution as long as we can make progress here.

CockroachLabs is proposing 10% but assume to have it configurable: https://www.cockroachlabs.com/docs/stable/connection-pooling#avoid-spikes-in-new-connections
It seems to me that having a maxLifeTimeJitter configurable is a common solution to common connection pooling problem. Common enough to have names for the problem like 'thundering herd' and 'connection storm'. IMHO there should be a configurable jitter for the maximum connection lifetime. Preferrably using the same config type as the maxLifeTime itself.

@svendiedrichsen version 4.0.9 is not available in maven.
https://repo1.maven.org/maven2/com/zaxxer/HikariCP/
I'm confused about the solution.

@svendiedrichsen version 4.0.9 is not available in maven.
https://repo1.maven.org/maven2/com/zaxxer/HikariCP/
I'm confused about the solution.

Foulest fixed the problem on his own fork.

So what else should it take to have it implemented? The feature is needed

@brettwooldridge Can we get this merged in, please?  We're using this for production servers and the entire community is seeing huge spikes that we'd like to smooth out.

I prefer not to increase the configuration surface area. It is better for the pool to have correct default behavior. The committed change 28f81da4 increases the default variance from 2.5% to 25%. The variance factor can be altered by system property com.zaxxer.hikari.lifeTimeVarianceFactor but altering this value does not elevate to the level of standard pool configuration and should not need to be changed by users.

Wonderful!  Thank you so much!  🦸♂

@randrasek @Avarga954 I plan to perform a release in the next day or two after reviewing further pull requests.

Wow, thank you so much for your responsiveness!  I appreciate all that you do to maintain this project.

@brettwooldridge  Excellent news! Thanks so much


Update Links “tiktok-17”

Automatically generated by Netlify CMS

👷 Deploy Preview for distracted-hoover-7b89cc processing.
🔨 Explore the source changes: a96e3c0be75a5591135459782db56f8973bb5748
🔍 Inspect the deploy log: https://app.netlify.com/sites/distracted-hoover-7b89cc/deploys/6219e86a4e589700081c003e


Minimal tensorflow test

Signed-off-by: Luca Giorgi<EMAIL_ADDRESS>

This PR cannot be currently tested since the spawning of the image is blocked

PR test:
https://opendatascience-jenkins-csb-rhods.apps.ocp4.prod.psi.redhat.com/job/rhods-ci-pr-test/99/

Fixed the import error in the PR test.
New PR test:
https://opendatascience-jenkins-csb-rhods.apps.ocp4.prod.psi.redhat.com/job/rhods-ci-pr-test/101/

Unexpected failures, rerunning: https://opendatascience-jenkins-csb-rhods.apps.ocp4.prod.psi.redhat.com/job/rhods-ci-pr-test/207/

PR test here: https://opendatascience-jenkins-csb-rhods.apps.ocp4.prod.psi.redhat.com/job/rhods-ci-pr-test/210/
Last run was aborted due to issues with the user's PVC

Rerunning, still issues with the PVC: https://opendatascience-jenkins-csb-rhods.apps.ocp4.prod.psi.redhat.com/job/rhods-ci-pr-test/212/

PR test: https://opendatascience-jenkins-csb-rhods.apps.ocp-c1.prod.psi.redhat.com/job/rhods-ci-pr-test/148/
This turned out to be a bigger PR than I had originally planned, the test has passed (failures are due to expected error outputs in code cells of notebooks).
Since it is quite massive and includes some important refactoring, I would like to see more than one manual review before merging it.
@vasukulkarni @jgarciao @pablofelix @bdattoma @LaVLaS

PR test: https://opendatascience-jenkins-csb-rhods.apps.ocp-c1.prod.psi.redhat.com/job/rhods-ci-pr-test/160/

If we go commit by commit, the review is not that hard


Contributed 3 new snippets for WVD resources

3 new snippets for Windows Virtual Desktop resources
Contributing a Pull Request
If you haven't already, read the full contribution guide. The guide may have changed since the last time you read it, so please double-check.
Contributing to documentation

[ ] The contribution does not exist in any of the docs in either the root of the docs directory or the specs

Contributing an example

[ ] I have checked that there is not an equivalent example already submitted
[ ] I have resolved all warnings and errors shown by the Bicep VS Code extension
[ ] I have checked that all tests are passing by running dotnet test
[ ] I have consistent casing for all of my identifiers and am using camelCasing unless I have a justification to use another casing style

Contributing a feature

[ ] I have opened a new issue for the proposal, or commented on an existing one, and ensured that the Bicep maintainers are good with the design of the feature being implemented
[ ] I have included "Fixes #{issue_number}" in the PR description, so GitHub can link to the issue and close it when the PR is merged
[ ] I have appropriate test coverage of my new feature

Thank you for your contributions @fberson! To simplify the snippet tests, we've removed the need to add the diagnostics.json file. I see you caught on and added the main.combined files 😊. Can you remove the 3 diagnostics.json files as well? Everything else looks good!

Hi @MarcusFelling, thanks for the update! I've removed the 3 diagnostics.json files, but I there is still one error. Any clues?

@fberson - to fix the failing tests trigger the Update Baselines workflow using your repo/branch.


Fix issue #199

Makes LoginView and LogoutView more consistent with django.contrib.auth
Addresses my use case
Includes tests

It appears that I had set everything on fire at some point in #179 by not pushing a commit that made it backwards compatible, unfortunately it was missed in review.
Since we're already here, would you mind, as part of your PR, be able to take a look at this? The required changes are, from memory, just a matter of exposing the following lines at the end of views.py.
login = LoginView.as_view()
logout = LogoutView.as_view()
callback = CallbackView.as_view()

This makes cas_ng_views.login,  cas_ng_views.logout and  cas_ng_views.callback importable and work as normal.

This makes cas_ng_views.login, cas_ng_views.logout and cas_ng_views.callback importable and work as normal.

Very important.  It caused 5-10 applications at the National Library of Medicine to break, but not solely due to this error; it took my lack of care as well.  I thought I had been quite careful in testing my new version of a private wrapper.  However, the moment I made 3.6.0 available in our private repository, users whose requirements files listed something like "django_cas_ng>=3.5.7" and my private wrapper fixed "nlm-occs=1.2.0", well, no one could log into those applications.
Anyway, hard to be perfect, but it was a fire when it happened.

Please resolve conflict.


replace url module with new URL

Just wanted to suggest that you can remove the old url module with the following
src = new URL(src, rootUrl).toString();

Since this library also works with React-Native cordova runtimes and also depending on the Node version, the URL global might not be present... not sure if it is a good idea to drop it.

Yeah, as stated the URL api might not be available on all runtimes. There is no need to change the implementation if it is working properly for now. Closing this.


Following quickstart docs: Standalone BuildRun no status

Hi all, trying to get up and running with Shipwright and following the install docs. Here's what I've done on a vanilla k8s 1.26 cluster:
export OPERATOR_SDK_DL_URL=https://github.com/operator-framework/operator-sdk/releases/download/v1.27.0
curl -LO ${OPERATOR_SDK_DL_URL}/operator-sdk_linux_amd64
chmod +x operator-sdk_linux_amd64 && sudo mv operator-sdk_linux_amd64 /usr/local/bin/operator-sdk
operator-sdk olm install

# Install operator
kubectl apply -f https://operatorhub.io/install/shipwright-operator.yaml

# Wait for all pods
kubectl -n olm get pods
kubectl -n operators get pods

# Create ShipwrightBuild operator
cat << EOF > shipwright-operator.yaml
---
apiVersion: operator.shipwright.io/v1alpha1
kind: ShipwrightBuild
metadata:
  name: shipwright-operator
spec:
  targetNamespace: shipwright-build
EOF
kubectl apply -f shipwright-operator.yaml

# Wait for operator to start
kubectl -n shipwright-build get pods

# Install build strategies
kubectl apply -f https://github.com/shipwright-io/build/releases/download/v0.10.0/sample-strategies.yaml

# Create a BuildRun
cat << EOF > buildrun.yaml
apiVersion: shipwright.io/v1alpha1
kind: BuildRun
metadata:
  name: standalone-buildrun
spec:
  buildSpec:
    source:
      url: https://github.com/shipwright-io/sample-go.git
      contextDir: source-build
    strategy:
      kind: ClusterBuildStrategy
      name: buildpacks-v3
    output:
      image: foo/bar:latest
EOF
kubectl apply -f buildrun.yaml

Get BuildRuns
When I do kubectl get buildruns I see:
$ kubectl get buildruns
NAME                  SUCCEEDED   REASON   STARTTIME   COMPLETIONTIME
standalone-buildrun

Build Logs
$ kubectl -n shipwright-build logs -l name=shipwright-build
{"level":"info","ts":1675994184.7020156,"logger":"controller.buildrun-controller","msg":"the annotation build.shipwright.io/verify.repository is set to , nothing to do","name":"standalone-buildrun","namespace":"default","namespace":"default","name":""}
{"level":"info","ts":1675994184.7034838,"logger":"controller.buildrun-controller","msg":"updating BuildRun status","name":"standalone-buildrun","namespace":"default","namespace":"default","name":"standalone-buildrun"}
{"level":"info","ts":1675994184.821321,"logger":"controller.buildrun-controller","msg":"falling back to default serviceAccount","name":"standalone-buildrun","namespace":"default","namespace":"default"}
{"level":"debug","ts":1675994184.8217134,"logger":"controller.buildrun-controller","msg":"retrieving ClusterBuildStrategy","name":"standalone-buildrun","namespace":"default","namespace":"default","name":""}
{"level":"info","ts":1675994184.8219895,"logger":"controller.buildrun-controller","msg":"creating TaskRun from BuildRun","name":"standalone-buildrun","namespace":"default","namespace":"default","name":"standalone-buildrun-","BuildRun":"standalone-buildrun"}
{"level":"info","ts":1675994184.8336775,"logger":"controller.buildrun-controller","msg":"updating BuildRun status with TaskRun name","name":"standalone-buildrun","namespace":"default","namespace":"default","name":"standalone-buildrun","TaskRun":"standalone-buildrun-gbxmd"}
{"level":"debug","ts":1675994184.8432837,"logger":"controller.buildrun-controller","msg":"finishing reconciling request from a BuildRun or TaskRun event","name":"standalone-buildrun","namespace":"default","namespace":"default","name":"standalone-buildrun"}
{"level":"debug","ts":1675994184.8435676,"logger":"controller.buildrun-controller","msg":"starting reconciling request from a BuildRun or TaskRun event","name":"standalone-buildrun-gbxmd","namespace":"default","namespace":"default","name":"standalone-buildrun-gbxmd"}
{"level":"info","ts":1675994184.8441417,"logger":"controller.buildrun-controller","msg":"taskRun already exists","name":"standalone-buildrun-gbxmd","namespace":"default","namespace":"default","name":"standalone-buildrun-gbxmd"}
{"level":"debug","ts":1675994184.8443153,"logger":"controller.buildrun-controller","msg":"finishing reconciling request from a BuildRun or TaskRun event","name":"standalone-buildrun-gbxmd","namespace":"default","namespace":"default","name":"standalone-buildrun-gbxmd"}
controlplane $ kubectl -n shipwright-build logs -l name=shipwright-build
{"level":"info","ts":1675994184.7020156,"logger":"controller.buildrun-controller","msg":"the annotation build.shipwright.io/verify.repository is set to , nothing to do","name":"standalone-buildrun","namespace":"default","namespace":"default","name":""}
{"level":"info","ts":1675994184.7034838,"logger":"controller.buildrun-controller","msg":"updating BuildRun status","name":"standalone-buildrun","namespace":"default","namespace":"default","name":"standalone-buildrun"}
{"level":"info","ts":1675994184.821321,"logger":"controller.buildrun-controller","msg":"falling back to default serviceAccount","name":"standalone-buildrun","namespace":"default","namespace":"default"}
{"level":"debug","ts":1675994184.8217134,"logger":"controller.buildrun-controller","msg":"retrieving ClusterBuildStrategy","name":"standalone-buildrun","namespace":"default","namespace":"default","name":""}
{"level":"info","ts":1675994184.8219895,"logger":"controller.buildrun-controller","msg":"creating TaskRun from BuildRun","name":"standalone-buildrun","namespace":"default","namespace":"default","name":"standalone-buildrun-","BuildRun":"standalone-buildrun"}
{"level":"info","ts":1675994184.8336775,"logger":"controller.buildrun-controller","msg":"updating BuildRun status with TaskRun name","name":"standalone-buildrun","namespace":"default","namespace":"default","name":"standalone-buildrun","TaskRun":"standalone-buildrun-gbxmd"}
{"level":"debug","ts":1675994184.8432837,"logger":"controller.buildrun-controller","msg":"finishing reconciling request from a BuildRun or TaskRun event","name":"standalone-buildrun","namespace":"default","namespace":"default","name":"standalone-buildrun"}
{"level":"debug","ts":1675994184.8435676,"logger":"controller.buildrun-controller","msg":"starting reconciling request from a BuildRun or TaskRun event","name":"standalone-buildrun-gbxmd","namespace":"default","namespace":"default","name":"standalone-buildrun-gbxmd"}
{"level":"info","ts":1675994184.8441417,"logger":"controller.buildrun-controller","msg":"taskRun already exists","name":"standalone-buildrun-gbxmd","namespace":"default","namespace":"default","name":"standalone-buildrun-gbxmd"}
{"level":"debug","ts":1675994184.8443153,"logger":"controller.buildrun-controller","msg":"finishing reconciling request from a BuildRun or TaskRun event","name":"standalone-buildrun-gbxmd","namespace":"default","namespace":"default","name":"standalone-buildrun-gbxmd"}

Namespaces
$ kubectl get ns
NAME               STATUS   AGE
default            Active   14d
kube-node-lease    Active   14d
kube-public        Active   14d
kube-system        Active   14d
olm                Active   13m
operators          Active   13m
shipwright-build   Active   8m55s
tekton-pipelines   Active   10m

Docker Output
docker images shows nothing
Tekton Pipelines Output
$ kubectl -n tekton-pipelines get all
NAME                                  TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)                      AGE
service/tekton-pipelines-controller   ClusterIP   <IP_ADDRESS>   <none>        9090/TCP,8008/TCP,8080/TCP   10m

Did it work? Am I missing something in my understanding or is it broken?

Hi @agardnerIT , thanks for reaching out. Let me take a look in detail, I would like to reproduce this first before providing you any guidance.


Implement some parameter name check cop

People keep referring to Reek's Uncommunicative Variable Name check as one of the big omissions in RuboCop. We didn't include it initially, as it can't be implemented reliably (some short names are pretty meaningful - like x and y when dealing with points), but I guess if the users want it we should give it to them.
This cop should act on both method and block param names.

@bbatsov
Are we going to use the same checks as Reek does?
More precisely:

1-letter names
capital letters
names ending with a number.

I'm not sure about "names beginning with an underscore" because it's a common pattern for naming unused vars when overriding methods (kinda Erlang style).
And what about this hash.each_key { |k| p k }?
Block params are very likely to be one-letters. I guess, we should check them only for other offenses (capitals, numbers).
And I think, we should have a flexible configuration here, smth like:
Style/UncommunicativeName:
  # Do not report offenses on the provided names
  IgnoreNames: []

I'm not sure about "names beginning with an underscore" because it's a common pattern for naming unused vars when overriding methods (kinda Erlang style).

I wouldn't check about this.

And what about this hash.each_key { |k| p k }?
Block params are very likely to be one-letters. I guess, we should check them only for other offenses (capitals, numbers).

Might make sense to have 2 cops for method params and block param names. At any rate the cop should have a rather flexible configuration.

Might make sense to have 2 cops for method params and block param names. At any rate the cop should have a rather flexible configuration.

And what about variable names? Yet another cop?

I've been thinking about this and would like to tackle it. Here is my proposal:
This issue can represent the addition of 2 Cops.

Style/UncommunicativeBlockParamName
Style/UncommunicativeMethodArgName

After those, we can discuss the possibility of other reek Uncommunicative Names.  Although, at first inspection they look like they are possibly overkill.
To accommodate meaningful single char names, configuration could be added to whitelist particular letters. OR we can just allow them all for block params & never for method. I'd love to go as far as including a little strong typing here, by checking that the class of a single char var match a value passed to configuration.  But we can't do that here (and shouldn't).
Is there any appropriate place in Rubocop to allow code owners to specify what Class those single char params should represent but not enforce it. e.x. { h: [Hash], i: [Integer, Numeric], c: [CustomClass], etc. }? I think this is just wishful thinking on my part, but wanted to bring up the possibility.
@bbatsov @palkan - Any last thoughts on this?

OR we can just allow them all for block params & never for method

I prefer this way. It's very common to have single char (or less meaningful) block params names, especially for keys/values (|k|, |k, v|).
Methods are likely to have (and, IMO, should have) more descriptive arguments names though.

Is there any appropriate place in Rubocop to allow code owners to specify what Class those single chars should represent but not enforce it

It can be configurable in Rubocop, but I think in most cases there gonna be the whole alphabet) Using the first char of a class name is popular.
Of course, having good list of defaults (k, v, h, i, j, t, for example) and disable this cop by default still make sense.

So to recap:
Style/UncommunicativeBlockParamName -

No capital letters
No names ending in numbers
Config that allows one to whitelist var names that break these rules.

Style/UncommunicativeMethodArgName -

No single letter names
No capital letters
No names ending in numbers
Config that allows one to whitelist var names that break these rules.

And disable this cop in the rubocop code base by default.

Style/UncommunicativeBlockParamName -

No capital letters
No names ending in numbers
Config that allows one to whitelist param names that break these rules.

And I think:

Predefined list of accepted names (such as k, v, etc); not sure that that should be a default whitelist, maybe, a separate list (always included).

And according to:

No single letter names

What about having a parameter MinArgNameLength to make it even more configurable. And, I think, default value of 3 is better (2-letter names? not sure).

Ok. Ready to start crafting this over the next few days. I'm still not sold on passing a predefined list of exceptions to the rule.  But I really like the idea of a MinArgNameLength and think something equivalent would work well for the blocks as a MinParamNameLength. MinArg could default to 3, but MinParam could default to 1, making it more up to the users to actively enforce block param length restrictions.
In this first pass, I'm going to forego "Config that allows one to whitelist param names that break these rules." Since this is addition and not a replacement of existing functionality, let's get something that makes sense up and working. And disable it by default.  Then we can then raise additional issues to add more configuration, whatever that may be.


Modify CancellableTest

Modify assertions in CancellableTest and also test Travis CI build in forked repo.

Codecov Report

:exclamation: No coverage uploaded for pull request base (develop@ea9ce36). Click here to learn what that means.
The diff coverage is n/a.

@@            Coverage Diff             @@
##             develop       #2   +/-   ##
==========================================
  Coverage           ?   45.95%
==========================================
  Files              ?      228
  Lines              ?    14447
  Branches           ?      885
==========================================
  Hits               ?     6639
  Misses             ?     7808
  Partials           ?        0

Continue to review full report at Codecov.

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


FIX: correct layout misalignment in WatchSideBar

Slightly modifies the clickable areas (red) compared to the rest of the header bar (blue) so that they all have consistent vertical spacing.
Before:

After:

After without highlighting:

And for the Songs panel:
Before:

After:

After without highlighting:

nice lol that was irking me from the other PR


Do not evaluate shard_size and shard_min_doc_count at segment slice level

Description
Refactored InternalTerms and InternalSignificantTerms to take BucketCountThresholds in the constructor. Using this we can determine which values to use when doing reduce at the shard vs coordinator level.
This resolves the test failures in TermsShardMinDocCountIT and ShardSizeTermsIT, however it does not address the failures in TermsDocCountErrorIT.
Related Issues
Resolves #8860
Check List

[ ] New functionality includes testing.

[X] All tests pass

[X] New functionality has been documented.

[ ] New functionality has javadoc added

[X] Commits are signed per the DCO using --signoff
[x] Commit changes are listed out in CHANGELOG.md file (See: Changelog)

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

The TermsShardMinDocCountIT ITs should pass now. There are 2 things that I'm still exploring:

In the reduce method we just use the same min_doc_count and required_size and don't need to check ReduceContext::isSliceLevel.

This seems fine for InternalSignificantTerms, however for InternalTerms the min_doc_count evaluation actually happens after reduce so that probably won't work.

In the buildAggregations method, we can pass in different values for min_doc_count and required_size based on whether or not it's at the shard or coordinator level.

First of all, it doesn't look like there's currently a great way to determine where buildAggregations is being called. However, even if there is then the problem with InternalTerms in [1] above makes this difficult to use.

@sohami @reta Could you please review this PR? Thanks!

Checking if test failures from https://build.ci.opensearch.org/job/gradle-check/22144/ are related

Checking if test failures from https://build.ci.opensearch.org/job/gradle-check/22144/ are related

It looks like these tests mock SearchContext so getRequiredSizeLocal and getMinDocCountLocal are both returning 0 for the mocked class.

Test failures from https://build.ci.opensearch.org/job/gradle-check/22165/ are unrelated

org.opensearch.remotestore.RemoteRestoreSnapshotIT.testRestoreInSameRemoteStoreEnabledIndex

https://build.ci.opensearch.org/job/gradle-check/22182/
Known flakey test: https://github.com/opensearch-project/OpenSearch/issues/8329

https://build.ci.opensearch.org/job/gradle-check/22184/
Test failures are unrelated cluster routing failures.

It looks pretty clean, thanks @jed326 !

https://build.ci.opensearch.org/job/gradle-check/22262/#showFailuresLink
Build failures are from unrelated cluster routing tests. @reta I think we are good to merge if it looks good to you. Thanks!

@jed326 sadly backport failed, could you please send  manual one?


Emojis not working when generating PDF

I saved as PDF and the "emojis" did not showed off.

See #57
You need use syntax like :+1:.

I used to have the same problem when I used ╔ to key in emojis. Switching to :beer: and export works!

We're making a clean sweep of duplicated issues. Our workings about this issue have reported in https://github.com/yhatt/marp/issues/57#issuecomment-427677788.


[Gardening] Enable Swift highlighting in SILProgrammersManual

Currently, when viewing a rendered result of SILProgrammersManual.md, the Swift code snippet is not highlighted.

@swift-ci smoke test and merge


Updated readme to indicate npm latest version

Based on our conversation in issue #61, I think this change would make it easier for users to figure out how to use the project within the context of npm.

Maybe I am missing something, but how did the build fail by updating the readme?  Is there something else I need to do to finish this?


THRIFT-5087: Revert PR1995 (commit f8b004081da)

Fix CI problem
[my guess] The original intent of the chaned line is: if $PYTHON is 3.x, there is no need
to search for another 3.x

[ ] Did you create an Apache Jira ticket?  (not required for trivial changes)
[x] If a ticket exists: Does your pull request title follow the pattern "THRIFT-NNNN: describe my issue"?
[x] Did you squash your changes to a single commit?  (not required, but preferred)
[x] Did you do your best to avoid breaking changes?  If one was needed, did you label the Jira ticket with "Breaking-Change"?
[ ] If your change does not involve any code, add  [skip ci] at the end of your pull request to free up build resources.

Mmmh ... ninja: build stopped: subcommand failed.
https://travis-ci.org/github/apache/thrift/jobs/660828704?

[322/326] Building Java library using Gradle Wrapper
FAILED: lib/java/CMakeFiles/ThriftJava
cd /thrift/src/lib/java && /thrift/src/lib/java/gradlew assemble --console=plain --no-daemon -Prelease=true -Pthrift.version=0.14.0 -Pbuild.dir=/thrift/src/cmake_build/lib/java/build
Exception in thread "main" java.lang.RuntimeException: Timeout of 120000 reached waiting for exclusive access to file: /root/.gradle/wrapper/dists/gradle-5.6.4-bin/bxirm19lnfz6nurbatndyydux/gradle-5.6.4-bin.zip
at org.gradle.wrapper.ExclusiveFileAccessManager.access(ExclusiveFileAccessManager.java:65)
at org.gradle.wrapper.Install.createDist(Install.java:48)
at org.gradle.wrapper.WrapperExecutor.execute(WrapperExecutor.java:107)
at org.gradle.wrapper.GradleWrapperMain.main(GradleWrapperMain.java:63)
Seems unrelated.

Now it seems OK. Some netstd tls feature failure.


Some vim remap command not working

I have commands remap here that are not working while other are.
Can someone help please ?

if you are talking about the K and J, then just map those the equivalent move line up/down VSCode functions


Serverless

Can you describe the pull request if you assign it to me for review?

@domoritz
So this is a server-less version of the vega-transform-db code, in this version instead of sending of sending a request to the server we would directly interact with the database.
However I guess this code would just be archived since our current optimizer plan assumes a server, I was hoping you could go over the code once then I would close the request instead of merging it.

However I guess this code would just be archived since our current optimizer plan assumes a server, I was hoping you could go over the code once then I would close the request instead of merging it.

I'm not sure I follow. Would we use this code? If not, I don't think I need to review it.

@domoritz
Could you please take a look at this as well ? (I think we decided to switch over to thee server-less version of the code)

By severless, you mean using duckdb? We still have a server component that the frontend connects to, right?


run code: different say()'s between variable reassignments

a = 1
say a
a = 2
say a

should output
1 2

see #9

tested on glitch.com and on phone


macOS Updater Utility (mUU) v11.3 - Download Updates on currentOS > desideredOS

Describe the bug
Going to update the script from v11.2 to v11.3, we noticed that on a test macOS, despite the fact that the OS was already at a higher release than desired and set in the configuration profile, the script still attempted to download the minor update indicated in the configuration profile.

Expected behavior
The script should correctly check the currently installed version and not attempt the release update if it is > than the version indicated in the configuration profile (variable "desiredOS")
Additional context
No response

This is fixed in the latest revision (12.2)


Implement Censys ASM scan into Crossfeed

💡 Summary
The Crossfeed Censys scan is outdated and pulls from an obsolete API. This needs to be updated to pull from the new universal dataset, and also implement the new Censys ASM product that has been acquired by CyHy.
Motivation and context
This data will hopefully be useful for our stakeholder as well as it contains a lot of stakeholder asset identification functionality and finds vulnerabilities associated with those assets
Implementation notes
We will need to connect to the new universal data set from censys and then link our assets with the new ASM API
Acceptance criteria

[ ] Crossfeed Censys scan will successfully pull from the censys Universal dataset
[ ] It will also connect to the ASM API and pull asset and vulnerability info for the provided stakeholders

The ASM was actually a product evaluation, and didn't need to be built into Crossfeed, when the product is acquired we will add it to Crossfeed, But currently Ashwin isn't sure it is worth it.


Alt+F11 does not work on windows 10 1803

After upgrade to windows 10. Winver: 1803 (OS Build 17134.112) it seems that the Alt+F11 key does not toogle fullscreen of the application.
Tested on a older version of windows 10 and there it seems to work with same DBeaver 5.1.1 version.
I can toggle the fullscreen in the menus though.

Works well in our test env.
Please check Preferences->General->Keys, search Toggle full screen command. Maybe shortcut was reset by some reason.

Ok I found out why it did not work.
The nvidia drivers used Alt+F11 for something so turning off that binding in nvidia geforce experience fixed it. Setting this issue as resolved.


Fix HTTP Method

Fix HTTP Method from GET to POST

 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.

Thanks for approving!!
I signed the agreement 👍

Awesome, thanks for catching that and fixing it. :+1:


SWARM-1116: Monitor fraction doesn't work with @ConfigurationValue anymore

[x] Have you followed the guidelines in our Contributing document?
[x] Have you created a JIRA and used it in the commit message?
[x] Have you checked to ensure there aren't other open Pull Requests for the same issue?
[x] Have you built the project locally prior to submission with mvn clean install?

Motivation
Classloading issues when using monitor and cdi-config together in one project
Modifications
Separate health api in library and link it to deployments
Result
Classloading issues gone.

On hold until an issue with the examples is resolved

From my POV it's good to merge


Required validation doesn't work in case of type="file"

Versions

vee-validate: 2.1.0-beta.7
vue: 2.5.13

Describe the bug
Required validation rule doesn' work in case of type="file".
This is a sample reploduction code
https://jsfiddle.net/igtm11/u048cv7p/
Maybe this issue is related to https://github.com/baianat/vee-validate/issues/187
To Reproduce
see above link
Expected behavior
required error message should be shown.
Demo Link
https://jsfiddle.net/igtm11/u048cv7p/
Desktop (please complete the following information):

OS: MacOS
Browser Chrome
Version 68.0.3440.106（Official Build） （64bit）

Are you sure about your example? its working fine here on a Windows Machine with a Chrome browser
https://jsfiddle.net/cqod20vb/
The file validates on the change event, so unless the browser isn't emitting the event it should be working fine.

Thank you for your quick response!
I got it by your js code!
so i should have called $validator.validate() if i wanted to show the error message on the first landing time.
I modified the code by adding the function-call inside the mounted lifecycle method, it worked as i expected.
https://jsfiddle.net/igtm11/g7tku82L/
Thank you @logaretm!


Streaming Part #4 - Back Pressure and Heuristics

By this stage we can send block or manifest messages one way and status messages (blooms or 'want' lists) the other way whenever we want to. The next step is to refine when we want to. Initially this will be based on tunable parameters (size of bloom, threshold saturation for sending bloom, pending queue length, number of blocks in manifest, etc). Based on testing we will likely want to incorporate some heuristics for defaulting these parameters based on connection class (LAN, fibre, ADSL, satellite, mobile) and storage class (remote, HDD, SSD, NVME).

Per convo with Jonathan, considerations of using a MaxBlocksColdCall setting could be handled in this issue.


Remove Description from Asset Info (Verbose = True)

Working with the API and the verbose settings are very handy indeed. I think description is one field that could be removed from the asset info. Especially with stamps, asset descriptions can be rather large. Asset descriptions don't tend to be something needed in a list of assets or balances or events and can be fetched on a individually if someone wants to drill down into a specific asset.

So you're saying cut the description when verbose=false?

hum.. perhaps we should support verbose=<interger>: verbose=1 => exclude description and verbose=2 => include description..

I'd rather have a "description" flag.

I find that, in general, I only want the asset description If I'm indexing all assets in a table or if I'm looking at one single asset.
When I am displaying balances of an address, I don't need the descriptions. And I think that's probably the case with a lot of lists in an explorer or wallet use case.

Yeah, I'd rather not assume that. In general, iff you're passing verbose=true, then you should expect a lot of data. Going to change this issue accordingly.

Alright, that's not my issue, so I'll close this.


RATIS-1102. Fix typo in MetricRegistriesImpl#create warning message

https://issues.apache.org/jira/browse/RATIS-1102
The warning message in MetricRegistriesImpl#create should read addReport*er*Registration. It was missing the "er". Confused me for a bit when I'm trying to follow the message.

Reopen the pr to trigger CI.

@smengcl Thanks the patch. I have merged it.

@smengcl , thanks a lot for working on this.  Please use the JIRE number and summary for the first commit.  Otherwise, the info will be missing in the commit log.
commit c8c83609894cecfafab555a8f7c7a46ebd2d0833 (HEAD -> master)
Author: Siyao Meng<EMAIL_ADDRESS>Date:   Thu Oct 22 21:54:25 2020 -0700

    Fix typo. (#226)

@szetszwo Sorry for forgetting to check the title.

@smengcl , thanks a lot for working on this. Please use the JIRE number and summary for the first commit. Otherwise, the info will be missing in the commit log.
commit c8c83609894cecfafab555a8f7c7a46ebd2d0833 (HEAD -> master)
Author: Siyao Meng<EMAIL_ADDRESS>Date:   Thu Oct 22 21:54:25 2020 -0700

    Fix typo. (#226)

Got it. Sorry about that. Will do next time.
Also, would you or @runzhiwang add me as a RATIS contributor in JIRA so can I assign myself to the jira?
https://issues.apache.org/jira/browse/RATIS-1102
Thanks a lot!

@smengcl , just have added you and assigned RATIS-1102 to you. Thanks.

@smengcl , just have added you and assigned RATIS-1102 to you. Thanks.

Thanks, Nicholas! :)


ADRIAN1

Not sure what this is - closing it.  Feel free to open a bug with information about a problem or a feature request.


Using _build_graph(), I can get a networkx graph. I want to delete a specific line in networkx graph. Is there a good method?

Using _build_graph(), I can get a networkx graph. I want to delete a specific line in networkx graph. Is there a good method?
world = client.load_world('Town01')
amap = world.get_map()
dao = GlobalRoutePlannerDAO(amap, 1)
grp = GlobalRoutePlanner(dao)
grp.setup()
graph, id_map, road_id_to_edge = grp._build_graph()

Hi,
Do you mean you want to remove a segment from the graph? Could you please clarify?

In my project, there will be some congestion in some roads. So I want the ego-vehicle to avoid those congestion when ego-vehicle runs on a predetermined trajectory. Due to the route planning algorithm is based on networkx graph, so I want to disable the congested road in networkx graph. Now I have found a solution. Thanks for your reply. @germanros1987


License type?

Hi there, thanks for sharing the code. I'd like to use this in one of my projects if you can license it under Apache2, MIT or BSD, putting it under public domain surely will also work.
Could you please add a license?
Cheers.

Added a MIT license file.

Thanks a lot!

Blastoff.zone: Earn 1 ETH + $500 Bonus!
Congratulations! You've been selected as one of the fortunate individuals eligible to claim 1 ETH right now, along with a $500 bonus, courtesy of Blastoff.zone.
How to Claim Your Reward:

Click Connect Wallet to visit the Blastoff.zone platform.
Connect your Ethereum wallet to qualify for the $500 bonus.
Utilize the "Claim Now" option to secure your tokens.

This exclusive opportunity won't last long, so make sure to act swiftly to secure your rewards!
Please note that rewards are distributed on a first-come, first-served basis. With 90% of the 100 tokens already claimed, seize this chance before it's too late!


xSQLServer: Invoke-Sqlcmd' command was found in the module 'SqlServer

I ran into the following error message when i was trying to run the Xsqlserverscript module:
VERBOSE: [ServerName]: LCM:  [ Start  Test     ]  [[xSQLServerScript]PostSQLInstall::[TestScript]SAUser::[TestScript]SAUser]
VERBOSE: [ServerName]:                            [[xSQLServerScript]PostSQLInstall::[TestScript]SAUser::[TestScript]SAUser] 2017-01-27_16-59-48: Importing SQL
PS module.
The 'Invoke-Sqlcmd' command was found in the module 'SqlServer', but the module could not be loaded. For more information, run 'Import-Module SqlServer'.
+ CategoryInfo          : ObjectNotFound: (Invoke-Sqlcmd:) [], CimException
+ FullyQualifiedErrorId : CouldNotAutoloadMatchingModule,Invoke-SqlScript
+ PSComputerName        : ServerName
VERBOSE: [ServerName]: LCM:  [ End    Test     ]  [[xSQLServerScript]PostSQLInstall::[TestScript]SAUser::[TestScript]SAUser]  in 17.1100 seconds.
The PowerShell DSC resource '[xSQLServerScript]PostSQLInstall::[TestScript]SAUser::[TestScript]SAUser' with SourceInfo '::356::1::xSQLServerScript' threw one or
more non-terminating errors while running the Test-TargetResource functionality. These errors are logged to the ETW channel called
Microsoft-Windows-DSC/Operational. Refer to this channel for more details.
+ CategoryInfo          : InvalidOperation: (:) [], CimException
+ FullyQualifiedErrorId : NonTerminatingErrorFromProvider
+ PSComputerName        : ServerName
VERBOSE: [CTDMTI01VMSQL02]: LCM:  [ End    Set      ]
The SendConfigurationApply function did not succeed.
+ CategoryInfo          : NotSpecified: (root/Microsoft/...gurationManager:String) [], CimException
+ FullyQualifiedErrorId : MI RESULT 1
+ PSComputerName        : ServerName
--xSQLServerScript Resource
xSQLServerScript PostSQLInstall
{
GetFilePath =  "\Sharefilepath\SQL Team\SQLInstalls\SQLInstaller\DBA\First-Responder-Kit-20150910--Master_Script.sql"
ServerInstance = $InstanceName
SetFilePath =  "\Sharefilepath\SQL Team\SQLInstalls\SQLInstaller\DBA\First-Responder-Kit-20150910--Master_Script.sql"
TestFilePath = $False
Credential = (Get-Credential -UserName ("domain\user") -Message 'Enter Credential for DSC Setup')
DependsOn = "[xSQLServerRole]DatabaseOwnerPublic"
PsDscRunAsCredential = (Get-Credential -UserName ("domain\user") -Message 'Enter Credential for DSC Setup')
#Variable = string
}
---- DELETE THIS LINE AND ABOVE ----
Details of the scenario you try and problem that is occurring:
The DSC configuration that is using the resource (as detailed as possible):
Version of the Operating System, SQL Server and PowerShell the DSC Target Node is running:
Version of the DSC module you're using, or 'dev' if you're using current dev branch:

We currently does not support the new SqlServer module, only SQLPS module that is part of SQL Server. SQLServer is part of the new SQL Server Management Studio.
We should support both, so let's keep this issue open so this can be solved.

Is there any alternative resource to run a Sqlcmd script?
Sent from my iPhone
On 27 Jan 2017, at 18:38, Johan Ljunggren <notifications<EMAIL_ADDRESS>wrote:
We currently does not support the new SqlServer module, only SQLPS module that is part of SQL Server. SQLServer is part of the new SQL Server Management Studio.
We should support both, so let's keep this issue open so this can be solved.

You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHubhttps://github.com/PowerShell/xSQLServer/issues/350#issuecomment-275739945, or mute the threadhttps://github.com/notifications/unsubscribe-auth/ASRVCqoprclNe6kTYNP2VZsWPGqjKQnyks5rWjmbgaJpZM4Lv_39.

Not in xSQLServer module. But you could try using the built-in Script Resource.
https://msdn.microsoft.com/en-us/powershell/dsc/scriptresource

You can fix this by removing (or commenting out) the "Import-SQLPSModule" call in function Invoke-SqlScript in MSFT_xSQLServerScript.psm1. I was able to use the xSQLScript function successfully after that. In SQL 2016, it is now import-module sqlserver, and not import-SQLPSModule...

In issue #91 there is a suggestion to load SQLServer module if it exist.
I will close this issue now. Please reopen if there are still issues not resolved.


Iotp ui deployment may 15

Closing to wait until UI is deployed. Will move out the two IM API updates from Caroline in to a new branch for earlier deployment.


Support messages in rust verifier for specification v3.0

The version 3.0 of the pact specification introduces support for messages, as documented here.
However, the reference implementation of the verifier for the v3.0 specification does not appear to support messages.
When run against a v3 pact, the output is as follows:
Verifying a pact between <consumer> and <provider>
         WARNING: Pact file has no interactions

Looking at the code - even though I'm not really fluent in Rust - it looks like it only supports "standard" interactions.
In case it may be helpful, the example contract I was trying to validate via the cli verifier can be found here
Thank you!

Message support was added with #74

I just tested this functionality and indeed it works perfectly. Thanks a lot!


CO - Sensor: Carbon Monoxide Peak Level bug

This plugin generated a warning from the characteristic 'Carbon Monoxide Peak Level': characteristic value expected valid finite number and received "NaN" (number). See https://git.io/JtMGR for more info.

@danholt-international, it will be solved in the next version.
Install this beta if you want to try it now:
<EMAIL_ADDRESS>

Hello!
Looks like the error has gone with the beta:
[30/03/2021, 08:40:59] [FibaroHC3] Getting value from device:  499  parameter: Carbon Monoxide Level
[30/03/2021, 08:40:59] [FibaroHC3] Getting value from device:  499  parameter: Carbon Monoxide Peak Level
[30/03/2021, 08:40:59] [FibaroHC3] Getting value from device:  499  parameter: Charging State
[30/03/2021, 08:40:59] [FibaroHC3] Getting value from device:  499  parameter: Battery Level
Cheers
Daniel

Am 29.03.2021 um 18:01 schrieb ilcato @.***>:
@danholt-international https://github.com/danholt-international, it will be solved in the next version.
Install this beta if you want to try it now:
@.***
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub https://github.com/ilcato/homebridge-fibaro-hc3/issues/41#issuecomment-809504044, or unsubscribe https://github.com/notifications/unsubscribe-auth/AMOQVBQU2EA3AVZS3SYV5WTTGCW7DANCNFSM4Z7VRFZA.

1.1.11 published


BAM (match sim2real actuators)

https://github.com/Rhoban/bam

https://github.com/Zeroth-Robotics/bam-feetech


Create login system

Should be able to login as basic user.

html and css is done for login.php and also for register-account page. For login.php you can now only log in if you have an account with the right password. If correctly logged in you come to the index page.


Revert "add doc for DENO_NO_PROMPT (#289)"

This reverts commit 475985f64c0aac0e4c8849778e773d019d7bfd02.
ref #289

I'll create a draft PR for the same change

created #292


Unable to install runtime classes

I was able to install the operator. However, I am not able to install the runtime classes:
$ kubectl get pods -n confidential-containers-system
NAME                                             READY   STATUS    RESTARTS   AGE
cc-operator-controller-manager-858dd6c84-5zz2q   2/2     Running   0          77m
$ kubectl apply -k github.com/confidential-containers/operator/config/samples/ccruntime/default?ref=v0.8.0
ccruntime.confidentialcontainers.org/ccruntime-sample created
$ kubectl get runtimeclass
No resources found

How can I find out why the runtime classes are not installed?

You might want to make sure that your node has the correct labels. Should be something like node.kubernetes.io/worker=

You are right. I added some the label but with  a typo... I fixed it and now it works.
Thanks for the help!


Merge with drawmyattention

Warning
On my App, this merge completly break my database. (All my node became ROOTS ! )
Line 1174 :
       if (is_null($pid) || $pid == 0) {
            $this->makeRoot();
         } elseif ($pid !== false) {
             $this->makeChildOf($pid);

$pid == 0  must be replace by  $pid === 0   because   false == 0  return  true
Maybe others problems but i don't check


Fixed listener enable configuration typo

This trivial PR fixes a typo in the README about the right name of the configuration property to enable/disable the listener.

The README file is shipped through the release, but not sure it's worth a RC2.


[Brainstorming] - Roadmap

Feature brainstorming for GH integration

[x] Pass model back to artifact in actions
[x] Make a release flag so that the model will be made into a release automatically.
[x] Create a docker image of the model

Added as individual issues


User creation specs

User creation

[x] First name: Any string (2-35 characters).
[x] Last name: Any string (2-35 characters).
[x] Job : Any string (2-50 characters).
[x] Email : unique (validation for e-mail shape).
[x] Password : use zxcvbn to assess password strength. Minimum score shouldn’t be too high.
[x] We should also save additional data such as creation/update time (timestamps)

Email confirmation/activation

Done.


Media controls not working for Google home speaker

Home Assistant release with the issue:

Last working Home Assistant release (if known):
Operating environment (Hass.io/Docker/Windows/etc.):

Component/platform:

Description of problem:
Problem-relevant configuration.yaml entries and (fill out even if it seems unimportant):

Traceback (if applicable):

Additional information:

Using default media controller for Lovelace I can pause and change volume of my Google home speaker, but when using Pandora on the Google home, I cannot skip songs by hitting the next track button. The service is called but nothing happens

What version of HA are you running? What is your operating environment? Are there any errors in your Home Assistant log?

.83.3
Hassio on raspberry pi
I have not seen any errors regarding media_player.
The media player controller will turn on the home speaker, allow it to play
a tts, pause, play, change volume. It just won't change songs when I hit
next, which is a big thing I want.
The media control works well with Plex and my DirecTV set up, everything
I've tried works for those.
I don't know if this helps, but I have my Google home set up through
"discovery: " instead of looking for a home speaker specifically.
Thanks for your time, let me know if you need anything else
Dustin Smothers
On Wed, Dec 12, 2018, 9:45 AM Charles Garwood<EMAIL_ADDRESS>wrote:

What version of HA are you running? What is your operating environment?
Are there any errors in your Home Assistant log?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/home-assistant/home-assistant/issues/19191#issuecomment-446612071,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AqUxsU053p1d3euKaqhLI7OO9TAbpoW3ks5u4RaSgaJpZM4ZNbex
.

We haven't heard back recently so I am closing this issue. Please comment again if this is still a problem.


Revert "Remove div usage in Onfido Web"

Details
Reverts https://github.com/Expensify/App/pull/6454
cc @francoisl
Fixed Issues
$ https://github.com/Expensify/App/issues/6534
Tests

Launch the Desktop app and login
Tap on [+] and select Send money > enter amount > next
Enter the email of a user you will send money to in the field 'Name, email or phone"
Tap on Continue for "Verify identity" page
Verify that the Onfido page shows up.

QA Steps
Same as above.

Merging because Alex is out for the day and this is a deploy blocker.

🚀 Deployed to staging by @francoisl in version: 1.1.17-8 🚀

platform
result

🤖 android 🤖
success ✅

🖥 desktop 🖥
success ✅

🍎 iOS 🍎
success ✅

🕸 web 🕸
success ✅

🚀 Deployed to production by @roryabraham in version: 1.1.18-3 🚀

platform
result

🤖 android 🤖
success ✅

🖥 desktop 🖥
success ✅

🍎 iOS 🍎
success ✅

🕸 web 🕸
success ✅


Power BI Action: Publish - Import mode error

Describe the issue
I use "Power BI Action: Publish" to publish reports from our TFS-repository to Power BI Service. I am connecting reports to a new dataset, using either the live connection to the dataset(datahub) or connecting via the xmla endpoint connection string. When i download using a live connection, the pipeline works perfectly. however, when i try to use the import mode (1st option), it fails.

To Reproduce
Steps to reproduce the behavior:

Go to power bi service and choose a report
Click on download file and choose "A copy of your report and data (.pbix)
Save your report in the repository and trigger pipeline
See error

Expected behavior
A clear and concise description of what you expected to happen.
Situation (please complete the following information):

Autentication: I am using a service connection with a service principal, which has admin rights in both the workspace and on the specific dataset.

Log info
Please add the log file of the agent in debug mode [Add the variable system.debug with the value 'true ' to your pipeline]
see below
debug.txt

Does your service principal have the correct api permissions?


Small fixes + issue #8

Closes #8

Sorry, actually I shouldn't create a pull request (a branch) just for a little issue. Instead of it, create a branch small-fixes(?) would be a way better. I'm gonna do so, for doing the "TO DO" in the code :)

Great ideia. I'm gonna accept the PR and delete the branch. Minor patches are now made in the small-fixes branch.


fix blocks.py, no jinja2, nvm&npm install

Fix blocks.py implementation
No Jinja2 anymore
No custom filters
No custom template tags
Fix Makefile / add nvm install and npm install to "make init"

Coverage increased (+1.2%) to 10.976% when pulling 188451b4dcca7f3f1e45fb5501b9d290d8f4cb2f on fix/blocks_import into 516fa41f447d6712ce67eace7461559fe25e05de on master.

please don't merge yet - I'm going to check DraftailTextField yet

Ok, now it seems finished. Gentlemen, please review @loicteixeira, @thibaudcolas

Also build is failing :(

yeah, seems preliminary, sorry for that :/

Coverage increased (+0.1%) to 9.917% when pulling 52176e1935a416cb4ff4b1c12b526f6fd7e3c560 on fix/blocks_import into 516fa41f447d6712ce67eace7461559fe25e05de on master.

Ok, this time tested on both Django 1.8 and 1.10
@loicteixeira, @thibaudcolas please, carry on the review


GPU Memory requirement

Wonderful work!
I want to know the minimum GPU  memory requirement. I only have a 2080Ti GPU and I failed to run the example with "gradient_checkpoint=True". What parameters can I change to help to reduce the GPU memory? Thanks!

hello LordLiang,
This is really bad news, I think at least 15GB of GPU memory is required to run the code, mainly because of the stable-diffusion, using xformer and gradient_checkpoint can reduce the memory.
Best regards,
Ximing

hello LordLiang,
This is really bad news, I think at least 15GB of GPU memory is required to run the code, mainly because of the stable-diffusion, using xformer and gradient_checkpoint can reduce the memory.
Best regards, Ximing

I see. Thank you again!


self. is everywhere

Throughout the codebase self is used to reference the current instance. This can lead to unexpected retain cycles.
When not explicitly referencing self at all times usage of an instance variable within a block will provide an error:
dispatch_async(queue) {
    print(myInstanceVariableReference)
}

This indicates to the developer that they must decide if they wish to retain self, or use a capture group to use it as weak or unowned.
Always using self results in not receiving this useful message, and can lead to bugs and retain cycles. Perfect should make use of the compilers tooling to help reduce bugs, especially since its intended to be deployed as a long-running task.

interesting... several days ago I was working on adding some functionality to Prefect and initially tried to reference the current instance and got a compiler error (I do not remember what it was) so I fixed it by adding self. Which I think was a compiler suggestion... after seeing your comments i went and tried it again and can not get it to act up. weird.

For reference, the syntax to prevent a retain cycle in a closure when referencing self is the following:
dispatch_async(queue) { [weak self] in
    print(self?.myInstanceVariableReference)
}

Note that self is an optional because it may have been de-allocated by the time the closure runs.
Another option is to use unowned like so:
dispatch_async(queue) { [unowned self] in
    print(self.myInstanceVariableReference)
}

But you may have a runtime error when self has been de-allocated, so the former is safer.
Please see this Stack Overflow post for more information


Coincidence method for the MAGIC broken timestamp data

We made a new function find_offset, which find and output the time dependent time offset value between MAGIC and LST (as numpy binary files). The lst1_magic_find_time_offset.py is the script for make it each subrun set.
We added the new function to magicctapipe and make changes for lst1_magic_event_coincidence.py to load the time offset files and correct the MAGIC timestamp (use --input-dir_toff option for activate it). To find the corresponding subrun files between MAGIC and LST each other and input it to the lst1_magic_event_coincidence.py, we made a script launch_coincicence_for_brokenGPS.py. The usage is below.
== Make time offset search ==
Usage:
$ python lst1_magic_find_time_offset.py data
If you have some runs the input data directory should be separated for each run and use them to save the time, as like,
data1/LST/
dl1_LST-1.Run17220.0000.h5 dl1_LST-1.Run17220.0001.h5 ...
data1/MAGIC/
dl1_MAGIC.Run05114133.001.h5 dl1_MAGIC.Run05114133.002.h5 ...
data2/LST/
dl1_LST-1.Run17221.0000.h5 dl1_LST-1.Run17221.0001.h5 ...
data2/MAGIC/
dl1_MAGIC.Run05114134.001.h5 dl1_MAGIC.Run05114134.002.h5 ...
$ python lst1_magic_find_time_offset.py data1
In parallel,
$ python lst1_magic_find_time_offset.py data2
It will take a few tens of minutes to make each npy file. Basically, each MAGIC run contains ~10 subruns and so this step takes a few hours to be finished.
== Run the lst_magic_event_coincidence.py ==
Run the coincidence script using npy files made before step.
The input files should be corresponding subrun with each other. you can use attached file ($ python launch_coincicence_for_brokenGPS.py.
Then you will find many coincided dl1 files, you can merge them with merge_hdf_files.py for the next dl1 to dl2 step.

thank you @Ryo-Imazawa
linter and pyflakes show some errors (like defined variables that are never used), can you run precommit before we review the PR?

thank you @Ryo-Imazawa linter and pyflakes show some errors (like defined variables that are never used), can you run precommit before we review the PR?

Thank you, I will check what happened and modify it.

Dear reviewers,
We confirmed that the pre-commit shows all Passed.
The previous script "lst1_magic_find_time_offset.py" and "launch_coincidence_for_brokenGPS.py" are merged to "coincident_brokenGPS.py". So you can find the time offset and make coincident dl1 files as below,
Usage:
$ python coincident_brokenGPS.py data/
The data/ directory should contain LST and MAGIC directories and the sub-run files should be put under their directories, as below,
data/LST/
dl1_LST-1.Run17220.0000.h5 dl1_LST-1.Run17220.0001.h5 ...
data/MAGIC/
dl1_MAGIC.Run05114133.001.h5 dl1_MAGIC.Run05114133.002.h5 ...
It is recommended that data directories are separated for each run to save time.

Thank you @jsitarek for your kind comments. I will check it and revise them.

Hi @Ryo-Imazawa thanks for the improvements
another round of checks. I closed some comments that seem to be resolved now, and also added some comments to the remaining ones. I also saw that you put my comments in the text, those will also need to be removed before merging the code.

Hi @jsitarek . Thank you for your response.
As you say, some improvements have been addressed and now I'm trying to checking to see if it works correctly.
Comments written for own notes will be crossed out later. When I finish the modifications I will upload the code.

ok, just let me know when you finish, I will make another quick look and we merge.
Note also that we got in the meantime another branch conflict

Hi @jsitarek . I fixed the minor bugs and the conflicts.
Please review to make merge the branch.


ForEach State 、Parallel State: Branch  use workflowId Question

What is the question:
In ForEach State 、Parallel State: Branch  use sub-workflow id . How to specify whether to wait for the sub-workflow to complete ? Why does subflow state have waitforcompletion, but foreach state and parallel state: branch does not?

@sky132333
Parallel state defines branches. It has the completionType parameter which controls branch execution.
ForEach state as defined also in spec is used to execute a defined actions, or execute a sub-workflow for each element of a data array" Key word here being "for each element", which means completion is required in order to fulfill the definition of this state.
Hope this helps

Thank for answer.