Check .pli file loaded

The check on the .pli file loaded is performed only partially: instead of checking both its extension and its existence, only the latter is actually checked. Each of such checks is implemented into a dedicated method: the two resulting methods are associated to the same event, that is triggered when the Entry widget loses its focus. This results in triggering only the lastly called method.
In addition, if the .pli file path is entered manually, the initial and output folders are not extracted. This results in an erroneous folder where any next .pli selection window is opened. Think about merging the ways the entered .pli file is managed.

So far the EntryVariable class used a fixed validation procedure, implemented directly within the class itself.
In 4f12e94 it has been modified by giving the user the possibility to define the validation function to use at the instantiation of the EntryVariable class. The validation is now triggered each time a text is inserted in the entry widget.
The validation consists of the two required steps, first by checking the extension, second by checking the file existence.
If the validation passes, a new event has been declared so to trigger the method for retrieving the information from the input .pli file.
Within this last method, the initial and output folders are updated accordingly, no matter the .pli file path is entered manually or not.

The bugs related to the .pli entry validation have been solved.


Strategies *_BRANCH_MAJOR_X should always increment minor

This is related to #121.
This time, when using nebula-release and a branch release/2.x, the first version is 2.0.0, the second version build on that branch 2.1.0.
But when doing the same with vanilla gradle-git, the result will be 2.0.0 for the first release, and 2.0.1 for the second release.
I think when the branch matches the *_BRANCH_MAJOR_X strategy, the plugin should always increment the minor. With #121 applied, to get the current behaviour, one would have to name the branch to match MAJOR_MINOR_X.
With this change, one could have major-branches using the MAJOR_X pattern (e.g. release/2.x, release/3.x) to implement new features, but if for some reason someone needs a bugfix based on an earlier version, a new branch release/2.3.x can be created based on the tag v2.3.0 to cherry-pick some bugfix and create a version 2.3.1.
As I said, once #121 is applied, this is already possible with nebula-release, but might not be possible with vanilla gradle-git without changing the default fallback to useScope(MINOR) like nebula-release does.
I think this, in conjunction with #121, would better reflect the expected behaviour when using release branches with these patterns.

I am currently implementing a semantic-release plugin based on the ideas from https://github.com/semantic-release/semantic-release. It will be based on gradle-git and I plan on using *_BRANCH_MAJOR_X and *_BRANCH_MAJOR_MINOR_X in addition to my own strategy.
Using MAJOR_MINOR_X is a no-brainer: When the strategy incremented the patch level, but the commits indicate a minor or even major level upgrade, the release should fail.
But using MAJOR_X in combination with my strategy would only work if the current behaviour of the MAJOR_X strategy is left unchanged.
Maybe it is best to keep the MAJOR_X stragegy as it is now, and introduce two new MAJOR_X_0 strategies:
static final PartialSemVerStrategy ENFORCE_GITFLOW_BRANCH_MAJOR_X_0 = one(fromBranchPattern(~/^release(?:\/|-)(\d+)\.x\.0$/), useScope(ChangeScope.MINOR))

static final PartialSemVerStrategy ENFORCE_BRANCH_MAJOR_X_0 = one(fromBranchPattern(~/^(\d+)\.x\.0$/), useScope(ChangeScope.MINOR))

That way one could use following branch pattern:

release/1.2.x to build what it says, 1.2.0, 1.2.1, 1.2.2, 1.2.3, ... (#121)
release/1.x.0 to build what it says, 1.0.0, 1.1.0, 1.2.0, 1.3.0, ...
release/1.x in combination with other strategies (using StrategyUtil.one()) to let the other strategies decide

If you think this is OK, I can prepare a pull request.

Unless someone defaults to MAJOR (which is unlikely), I think the current behavior is appropriate. For your new MAJOR_X_0 strategies, I would lean towards you including those in your new plugin. If someone uses MINOR as their default scope, they would get the same result from the existing strategy.
Side point, possibly relevent to your plugin, I'm also working on a more general replacement for the version inference in semver-vcs. Not sure how far off it is from being usable, but I am specifically aiming to better address the implications branches have on versioning.


Multi instance increase test coverage

What?
We've added two more tests to ensure that using multiple instances of beams in the same app won't interfere.
...
Why?
We want to ensure that people who do use multiple instances don't have any issues
...

CC @pusher/mobile

Codecov Report

Merging #140 into feature-multi-instance will increase coverage by 0.33%.
The diff coverage is 100%.

@@                    Coverage Diff                     @@
##           feature-multi-instance     #140      +/-   ##
==========================================================
+ Coverage                   89.89%   90.22%   +0.33%
==========================================================
  Files                          56       56
  Lines                        3186     3243      +57
==========================================================
+ Hits                         2864     2926      +62
+ Misses                        322      317       -5

Impacted Files
Coverage Δ

...IntegrationTests/MultipleInstanceSupportTest.swift
100% <100%> (ø)
:arrow_up:

Sources/ServerSyncJob.swift
66.31% <0%> (+5.26%)
:arrow_up:

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 9f9b91a...d76c8c6. Read the comment docs.


redirect uri mismatch

on loging in with google saying, redirect uri mismatch not able to log in with google

in your console give redirect uri as https://localhost: and https://localhost


proposal: testing: run tests in parallel by default

The testing framework of go is powerful, one of it's strong points is it's natural ability to run tests in parallel.
I assert that most tests should be able to run in parallel, and if not - a detailed explanation should be given why this test should run on its own. I can gather several reasons for this proposal:

Faster tests: running all possible tests in parallel will result in shorter test time.
Explicitly: Having a programmer write an explicit reason for the test not to be able run in parallel: t.Serial("Modifies a database which is used by several tests").
Bugs detection: running tests in parallel is one of the ways to detect bugs in program design, which might be hidden in a serial invocation of the tests.
Less code/ Programmer friendlier: almost every test deceleration takes two lines of code: the test function deceleration and a following line t.Parallel(). It is a common case to see only the first, and the main reason for that is the the programmer forgot to type the second.

I can propose two ways to accept this change:

Breaking change: save it to Go2, since Go1 is good enough as it is. :smile:
Can add an additional flag for the test command that sets the default behavior to parallel, unless the Serial function was called on a test.

(See also #17751 and the attached boilerplate "parallelize" changes.)

It would be very difficult to make this change with the existing testing package, as that would be certain to break many existing tests.
Writing t.Parallel() is not hard.
This might be something to consider in a new testing package, but I don't see any path from the current package to a place where tests are run in parallel by default.
I could imagine permitting people to say t.AllParallel() in their TestMain function, but  that ought to be a separate proposal.
Closing this issue.

Writing t.Parallel() is not hard.

Right, but as said in the proposal: one might forget it. and it is the same line wring over and over again. Also, when not used, race detection are less likely to happened.

This might be something to consider in a new testing package, but I don't see any path from the current package to a place where tests are run in parallel by default.

What do you mean by "new testing package"?

I could imagine permitting people to say t.AllParallel() in their TestMain function, but that ought to be a separate proposal.

What is TestMain function?

Closing this issue.

Closing this means it won't be considered to what is called "Go2"?
Thanks!

What is TestMain function?

https://golang.org/pkg/testing/#hdr-Main

What do you mean by "new testing package"?

For Go 2 it is possible that we could create a new testing package under a different import name.  However, there are no current plans to do so.

Closing this means it won't be considered to what is called "Go2"?

Yes.  Sorry.
  It can only break compatibility where necessary. This benefit of this change is not high enough.

OK, thanks @ianlancetaylor .
One last question, sorry about your time. What about an additional flag to go test, as proposed in no. 2 in the proposal? It is not breaking anything as far as I can see, and I am willing to implement it if it is acceptable.

An additional flag seems possible and doesn't break compatibility.  Why don't open a separate proposal for that and we can see what the proposal review committee thinks.  Thanks.


Feature: add an audit rule for using actions that include themselves unpinned dependencies

Pre-submission checks

[X] I am not reporting a bug (crash, false positive/negative, etc). These must be filed via the bug report template.
[X] I have looked through the open issues for a duplicate request.

What's the problem this feature will solve?
So its not easy to figure out yourself if the action you are using uses itself some transitive dependencies.
For that reason we worked on a tool that allows you to audit actions easily: https://github.com/eclipse-csi/octopin
Describe the solution you'd like
It would be great if there would be a similar audit rule in zizmor that would indicate if some of the actions uses unpinned dependencies itself. There is no easy fix for that ofc, but at least you know and probably can remove or replace that action in your workflow.
Additional context
No response

Thanks for the issue @netomi!
Correct me if I'm wrong, but I think this request is for a composition of two separate features: composite action auditing (which is tracked in https://github.com/woodruffw/zizmor/issues/173) and the unpinned-uses audit (which is already implemented).
Given that, I'm inclined to track this with #173 -- once composite actions are supported more generally, it'll be trivial to lift existing audits like unpinned-uses onto them.

I did not make the connection to #173 but it makes sense to track it in this issue.
There are cases where there is a further traversal, e.g. composite action -> local action -> docker ....
One example is the slsa generic generator workflows, but there might be other cases as well. Feel free organize as needed.

There are cases where there is a further traversal, e.g. composite action -> local action -> docker ....

Yeah, long term the plan is to be fully general here: if the user passes a --recurse or similar flag, zizmor will walk the actions/workflows until it visits all of them.
I'll track this with #173.


[Bug]: [Notebook]The picture is gone in the example of image_animation

Is there an existing issue for this?

[X] I have searched the existing issues

Current Behavior
The picture is gone in the example of image_animation.
https://github.com/towhee-io/examples/blob/main/image/image_animation/example.ipynb

Expected Behavior
add the picture
Steps To Reproduce
No response
Environment
- Towhee version(e.g. v0.1.3 or 8b23a93):0.9.1.dev55
- OS(Ubuntu or CentOS):
- CPU/Memory:
- GPU:
- Others:

Anything else?
No response

@NicoYuan1986 Fixed by https://github.com/towhee-io/examples/pull/162. Please re-check.

Fixed.


Support non json formats + file encryption

This PR adds support for non JSON formats in getFile and putFile, specifically "text/plain" and "application/octet-stream" content types. It also adds support for encryption and decryption of data. Finally, it solves a bug that was surfaced while testing this feature where files cannot be shared between a web app and corresponding iOS app due to mismatched Gaia addresses.
It will solve issues #12, #16, #21, #39, and #44.

@yknl Submitted tests 👍🏾.

Gaia__without_encryption__for_text_content__can_upload_and_retrieve
Gaia__without_encryption__for_bytes_content__can_upload_and_retrieve
Gaia__with_encryption__can_upload_and_retrieve
Gaia__with_encryption__fails_retrieve_without_decrypt

They cover all content types (json, plain text, bytes) and encryption/no encryption cases.

@larrysalibra done! Comments + sample app update. The sample app still needs more work to look like Android's, but that is tracked elsewhere (#46 ) and is outside the scope of this PR.

I tested this out by modifying the example to store bytes instead of a string and make sure that I could read it back.


Add backtrace to 'failed to save message' log

I think this would be useful to include in future releases. Specifically, it will help to diagnose errors such as those reported in #40 and #42.

Thanks for the PR.


Fix syntax of README.md

There was a lot of malformed markdown there, this makes it much more readable.

Can one of the admins verify this patch?

ok to test

retest this please


Geometry Test Dataset Size

Hello! I have a question regarding the Geometry test results mentioned in the paper. Could you please provide details on the size of the test dataset used? Specifically, Is it  all the images found in the tasks folder of the code files?

yes there are 54 questions. All in the tasks folder


Permission problem

Description
When I create a repository and add role to repository_read_write_access_arns that role doesn't have access to repository.
I need create role policy to add access to repository. Looks like ECR policy is omitted. Also when I create IAM role for access to repo looks like ECR policy doesn't restrict access. I think default DENY policy is missing, or I'm doing sth wrong.

[X] ✋ I have searched the open/closed issues and my issue is not listed.

Versions

Module version [Required]:

Terraform version: 1.5.1

Provider version(s):

Reproduction Code [Required]

Steps to reproduce the behavior:
Create repository and add role arn to repository_read_write_access_arns.
Role doesn't have configured policy other than stsAssumeRole.
Permission denied when access to registry.
Expected behavior

Access to registry to roles provides to repository_read_write_access_arns
Actual behavior
Permission denied for role.

we will need some code to be able to troubleshoot and reproduce what you are claiming

Ok, my inputs to module (I'm using terragrunt)
inputs = {
  repository_name = "repo"

  create_lifecycle_policy = false

  repository_read_write_access_arns = [
    dependency.ecr-write-role.outputs.ecr_write_role_arn, # write role for github actions
    ]
  repository_read_access_arns = [
    "arn:aws:iam::dsadssdasda:role/eks-node-group-1",
    "arn:aws:iam::dsadsadsadsas:role/eks-cluster2",
  ]
}

dependency.ecr-write-role.outputs.ecr_write_role_arn is an ARN for role. I don't have any permission attached to role. In this case I don't have access to ECR. For access I need to configure permissions in dependency.ecr-write-role.outputs.ecr_write_role_arn role.

you can use the example(s) provided by the project to create a reproduction that is deployable https://github.com/terraform-aws-modules/terraform-aws-ecr/blob/master/examples/complete/main.tf


Fix size of donation widget section for medium sized screens

Here an example how it currently looks like on a 14'' screen.

Fixed in #30


Fix add_transaction_tracer ruby 3 deprecation warning

Overview
Use ruby2_keywords to add ruby 3 support to NewRelic::Agent::Instrumentation::ControllerInstrumentation.add_transaction_tracer method, as recommended in this article.
Related Github Issue
#671
Reviewer Checklist

[ ] Perform code review
[ ] Add performance label
[ ] Perform appropriate level of performance testing
[ ] Confirm all checks passed
[ ] Add version label prior to acceptance

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

Thank you so much for your kind words and reactivity @tannalynn!


Issue #301 Fix MySQL quote issue for table options

Fixed quoting MySQL vendor params on tables which caused syntax error problems
Issue #301

Nice fix, please fix your code, and I'll be glad to merge your PR :)

Ping @rncain

Merged, thanks. Can you port this patch on Propel2?


add  reg

@JuliaRegistrator register()

@JuliaRegistrator register()

Error while trying to register: "Pre-release version not allowed"

@JuliaRegistrator register()

Registration pull request created: JuliaRegistries/General/98936
Tip: Release Notes
Did you know you can add release notes too? Just add markdown formatted text underneath the comment after the text
"Release notes:" and it will be added to the registry PR, and if TagBot is installed it will also be added to the
release that TagBot creates. i.e.
@JuliaRegistrator register

Release notes:

## Breaking changes

- blah

To add them here just re-invoke and the PR will be updated.
Tagging
After the above pull request is merged, it is recommended that a tag is created on this repository for the registered package version.
This will be done automatically if the Julia TagBot GitHub Action is installed, or can be done manually through the github interface, or via:
git tag -a v1.0.0 -m "<description of version>" 1d528332042dcf807a86cc13c837ea4203860031
git push origin v1.0.0


arangodb s3 bucket name compatibility

What problem are we solving?
arangodb collection name restrictions are not the same as s3 bucket names. this causes some bucket names (those using "." or starting with a number) to break.
How are we solving the problem?
this introduces special character sets 'xN--' which is prepended to the collection name if starts with number, and 'xP--'  used to replace all '.' characters. since bucket names must not contain upper case letters, this should be 100% compatible with s3 bucket name rules. this is only in the storage layer and should be transparent to any user.
I'm not sure if this is an issue for buckets for other filers, but this hack could be used for them as well if it is.
additional changes
this also adds a defer to properly close the context used to initialize the arangodb connection, and properly escapes collection names in the AQL queries

Is it possible to just replace . with underscore?

that would cause bucket names foo.bar and foo_bar to point towards the same bucket, which makes it incompatible with s3

For current code, what problem it will cause?

Ah sorry, I guess the person who is my seaweed fs instance is using underscores, when S3 actually does not permit it.
I don't mind forcing them to rename. I can edit the PR to replace . -> _ tomorrow


Parallel Quicksort

Hey everybody,
I have an algorithm in mind and would like to describe it as best I could to get your feedback on how to get started.
The algorithm works by spiting up an array into bins.  The bins are split among the number of actors. So it would look like
|0|1|2|0|1|2|0|1|2|0|1|2|
A single pivot is used.  This organization of bins means that each Actor will find the pivot in a different bin that each other. So then might have this arrangement of found pivots denoted by {}.
|0|1|2|0|1|2|{0}|{1}|{2}|0|1|2|
We are now guaranteed that every bin to the left of {0}' is now less than the pivot and vice versa for {2}.` Then each actor sorts the bin with the pivot and the results are merged.  This last step could be simply to find the new pivot but it helps take advantage more the parallelism. We could also send the found pivots to each other actor, which I think is not to expensive in your world.
The types as I see them now are:

Sorter actors that are each address a copy of the corresponding bin object.

Bin object overwrites the the + operator such that we can use the existing sequential version. While traversing the array correctly.

Another optimization we will learn through experimentation is how small the input is before we transition to a different sorting algorithm.
This is my day four with Pony and I have to thank everyone for making an awesome peace of technology.
Best,
Willem

Hi @willemneal.
The proper forum for this would be the user mailing list.
https://pony.groups.io/g/user

@SeanTAllen - If we're not going to field general questions in issue tickets, it might be worth clarifying this in the README, where I think the current format doesn't do a good job of distinguishing what kinds of "getting help" are appropriate in each forum.

@jemc i thought that was gone. I could have sworn I removed that. But apparently I didn't.


'Contains' for check against lists

I plan to support a list of groups, which a user can have in loginsrv.
It would be cool to also have support for that in caddy-jwt. I could think of a syntax like:
allow claim > value
deny claim > value

Where claim may be an json array of strings.
What do you think about that?
Should I implement this and do a PR?
Any objections or better ideas about the syntax?

Sebastian,
I appreciate the contributions but I'm not too crazy about this one.  I
think it adds a lot of complexity and the possibility of bugs by relying
on JSON parsing.  It would be better if you could just list multiple
allow values for each claim.
For example:

allow group users

allow group admin

I believe this works now, but there might not be a test to cover this
case.  If people have so many groups that they can't list them out on
multiple lines, then something is wrong with the way their system is
designed or their use-case is so advanced that they should be dealing
with authorization on their own.
I'd rather keep this plugin simple because I don't have the time to
support users with advanced use cases.  They should be doing that stuff
on their own.
On Tue, Dec 13, 2016, at 04:36 AM, Sebastian Mancke wrote:

I plan to support a list of groups, which a user can have in
loginsrv[1].
It would be cool to also have support for that in caddy-jwt. I could
think of a syntax like:

allow claim > value deny claim > value
Where claim may be an json array of strings.

What do you think about that?

Should I implement this and do a PR?

Any objections or better ideas about the syntax?

— You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub[2], or mute the
thread[3].

Links:

https://github.com/tarent/loginsrv
https://github.com/BTBurke/caddy-jwt/issues/14
https://github.com/notifications/unsubscribe-auth/AAZThzOi3jxay5oBWGqr6UPwY1bLbHuVks5rHbBegaJpZM4LK_v-

Hi Bryan,
yes, this one is not so obvious, so I'm talking about this first, before doing a PR ;-)
I think, you have misunderstood, my objective. I don't want a simple syntax for multiple rules.
What I want to implement is the support for list types within the JWT claim. In my case, a user can be part of multiple groups. And I want to check, if the user is at least part of one group.
e.g.
{
  "sub": "bob",
  "groups": ["admin", "user", "operator"]
}

If I read you comment, I think for the configuration part it would be the best, not to introduce any special syntax for lists, but just use the given syntax and do a contains check in the cases, where the claim is a list. e.g.
ALLOW groups admin

This way, the configuration would stay pretty simple.

Hi Bryan,
I continued with implementing this, because I'll now need this for a project of mine. Looks fine for me.
For me, it looks very understandable and straight forward. What do you think about it?
It adds up in PR #13, because I did not separate both things in branches. If you prefer, I can separate both commits.

Merged.  Thanks for the contribution.


hover dropdown menu no longer supported in v2?

Thanks for the great work on picocss and exciting v2.
Describe the issue
it seems the hover-activated dropdown menu in v1 is gone in v2
Current Behavior
only click to open dropdown menu is supported
Expected Behavior
restore ability to activate dropdown menu by mouse hover, or provide documentation to help achieve this
Reproduction URL
https://v2.picocss.com/docs/dropdown
Environment
Any

@alphatownsman,
Yes, it's gone:

We also removed the experimental syntax that allowed dropdowns in the nav using nested lists.

See here:
https://picocss.com/docs/v2#breaking-changes
Because it was too hacky, and I wanted to avoid an invalid href="#".
Also, the new dropdown can be used inside a nav:
https://picocss.com/docs/dropdown#usage-with-nav
Note the old docs are here:
https://picocss.com/docs/v1/dropdowns
I can reconsider it if anyone finds an elegant way to implement it.


upgrade image to alpine 3.17

fixes #1814
Thanks for contribution! Please go through following checklist before sending PR.
PR Branch Destination

For Azurite V3, please send PR to main branch.
For legacy Azurite V2, please send PR to legacy-dev branch.

Always Add Test Cases
Make sure test cases are added to cover the code change.
Add Change Log
Add change log for the code change in Upcoming Release section in ChangeLog.md.
Development Guideline
Please go to CONTRIBUTION.md for steps about setting up development environment and recommended Visual Studio Code extensions.

Thanks for the feedback and letting me know what the next steps are.
Just for your information, the version I chose is almost the same, as the one used before.
ENV NODE_VERSION=14.17.0
https://hub.docker.com/layers/library/node/lts-alpine3.10/images/sha256-f9cba6817f3dee4a9b8545e4abf77b91b7f25ec381f4231741be2c06b5e25920?context=explore
ENV NODE_VERSION=14.21.3
https://hub.docker.com/layers/library/node/14-alpine3.17/images/sha256-4e84c956cd276af9ed14a8b2939a734364c2b0042485e90e1b97175e73dfd548?context=explore


Is there a way to force close all open growl notifications?

We're using turbolinks on rails, and it seems the growl's show up for a split second before turbolinks wipes them out on the new page load. Force closing all open growl notifications via Jquery on page change should solve the split second appearing issue. Is there a quick way to do it?

There may be an official way to do this, but a quick+dirty workaround is to switch them off using $("#growls").hide();

Needed this behavior and used the following: $(".growl-close").click();. Hope it helps.


SIG: Add base events that modules can subscribe to

Types of events that are being added:

NetworkChanged: NetworkChanged is called when a remote network was added or removed from the configuration.
SigChanged: SigChanged is called when a remote SIG is was added or removed from the configuration. Note, this event does not get generated yet.
RemoteHealthChanged: RemoteHealthChanged is called when the reachability status of a remote AS changed.

This change is

Reviewed 2 of 2 files at r1.
Review status: all files reviewed at latest revision, all discussions resolved.

go/sig/base/as.go, line 292 at r1 (raw file):

			break Top
		case <-ticker.C:
			ae.RLock()

I'm a bit concerned about this. If this go routine somehow exits/panics while holding this lock, the SIG will break. It might be worth putting the contents of this case into a separate function, that can then use Rlock; defer RUnlock.

Comments from Reviewable

Review status: 1 of 2 files reviewed at latest revision, 1 unresolved discussion.

go/sig/base/as.go, line 292 at r1 (raw file):
Previously, kormat (Stephen Shirley) wrote…
I'm a bit concerned about this. If this go routine somehow exits/panics while holding this lock, the SIG will break. It might be worth putting the contents of this case into a separate function, that can then use Rlock; defer RUnlock.

Good catch! Done.

Comments from Reviewable

Reviewed 1 of 1 files at r2.
Review status: all files reviewed at latest revision, all discussions resolved.

Comments from Reviewable


Signing my app blocks my app from accessing the web

After using electron-osx-sign with these two entitlements I cannot use my app to access the internet, which it has to do, in order to work.
I'm guessing its my entitlement that I need to add to, in order for it to work.
parent.plist:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
	<key>com.apple.security.app-sandbox</key>
	<true/>
</dict>
</plist>

child.plist
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
  <dict>
    <key>com.apple.security.app-sandbox</key>
    <true/>
    <key>com.apple.security.inherit</key>
    <true/>
  </dict>
</plist>

@AhadCove I would recommend adding the following in your parent.plist so your app may access the network.
<key>com.apple.security.network.client</key>
<true/>

Other entitlement keys please refer to: https://developer.apple.com/library/content/documentation/Miscellaneous/Reference/EntitlementKeyReference/Chapters/EnablingAppSandbox.html


[terra-dev-site] Added clinical lowlight theme

Summary

Added clinical lowlight theme to "terra-dev-site",
Values are ported from the internal clinical lowlight theme repo : https://github.cerner.com/terra-incubator/ti-clinical-lowlight-theme/blob/master/themes/ti-clinical-lowlight-theme/_dev-site.scss
Additional Details

Updated the wdio screenshots to reflect the changes from the release of "terra-action-header"

Updated the wdio screenshots as well to reflect the changes from the release of "terra-action-header"


Freeze version of installed python modules in Docker file

If one rebuild the docker image using the Dockerfile, it installs a version of pybids which is too new for this app. I would suggest to freeze the version of pip installed modules, like:
RUN pip install nibabel==2.2.0
RUN pip install pybids==0.3 grabbit==0.0.8
RUN pip install duecredit==0.6.3

Thanks for reporting this. I'll fix this after #14

closed by #15


How to use proxies in this?

I can't use proxies since the library itself is apparently negligencing it's own settings.
Cannot use 'playwright.BrowserTypeLaunchOptionsProxy{Server: playwright.String("my.proxy.ip:port")}' (type playwright.BrowserTypeLaunchOptionsProxy) as the type *BrowserTypeLaunchOptionsProxy
I'm pretty "new" to Golang, and I'm having no issues with any other headless browser managers when it comes to proxy settings, at all. I hope it's a failure from me, not from the project, since I like everything I saw in the lib.

It seems you should use pointer type of playwright.BrowserTypeLaunchOptionsProxy, so please try adding & prefix like &playwright.BrowserTypeLaunchOptionsProxy{Server: ...} to pass the pointer.

Oh, thank you. It worked fine.


Remove account from xcconfig

This was previously used to support the compiled in Mapbox account code. It's not longer in the project but this search path does remain.

Maybe this code is a left-over from #7

Maybe this code is a left-over from #7

possibly


Add optional composer flags

Adds --no-dev if not in DEVELOPMENT_MODE, though you can influence it at a higher image level by declaring COMPOSER_INSTALL_FLAGS.
This can be used by the symfony image for example, to disable the update parameters plugin.

I'm going to test this now as I need to disable the plugins on a project

works as expected

That is not ideal for the remote development... I believe we should opt-out.

That is not ideal for the remote development... I believe we should make this optionable using an environment variable.

It is, DEVELOPMENT_MODE :)

What I mean is that by default, it is not using --no-dev.


macapype: segmentation to mesh pipeline

Project info
Title:
macapype: segmentation to mesh pipeline.
Project lead and collaborators:
David Meunier @davidmeunier79
Bastien Cagna @BastienCagna
Kep Kee Loh @kepkeeloh
Registered Brainhack Global 2020 Event:
BrainHack Marseille 2-4 Dec 2020:
https://mattermost.brainhack.org/brainhack/channels/bhg20-marseille
https://brainhack-marseille.github.io/
Description:
Macapype is an open source python package based on the nipype framework. Dedicated to the processing of NHP MRI data, Macapype brings together existing tools from popular neuroimaging softwares (e.g. FSL, ANTs, SPM, AFNI etc), and the wraps of specialised scripts for NHP MRI data processing. Currently, Macapype also provides predefined pipelines for the preprocessing, brain extraction, and segmentation of NHP MRI data that are easy to use, and customizable to various input file types (T1w or T1w/T2w). These segmentation pipelines have been successfully adapted to MR images from various NHP species, including the macaques, baboons and marmosets.
External links :
github : https://github.com/Macatools/macapype
documentation : https://macatools.github.io/macapype/index.html
mattermost user forum: https://framateam.org/macapype-users/channels/town-square (requires a framateam account)
Goals for Brainhack Marseille
In this brainhack, we would like to expand the existing pipelines of Macapype to allow the generation of surface meshes following the segmentation of the MR images. So far, macapype users have been performing the above process (i.e. surface mesh generation) by first, using a set of customised scripts to import Macapype-generated segmentations into Brainvisa, and second, to manually (point-and-click) generate surface meshes via the Morphologist Toolbox in Brainvisa. We aim to incorporate these two steps as an additional module in Macapype, which will enable the generation of surface meshes directly from the segmentations produced by Macapype. The final result would be a powerful pipeline that takes raw NHP structural MR scans as input, and generating tissue segmentation masks and surface meshes as outputs.
Skills:

python programming (20-100%)
nipype coding and wrapping (0-100%)
MRI data processing (50-100%)
anyone that has NHP data to process (0-100%)

Tools/Software/Methods to Use:
Related softwares : brainvisa, freesurfer, nipype

Project labels

Type of project:
coding_methods, data_management, #documentation, method_development,
#pipeline_development, tutorial_recording, visualization

Project development status:
0_concept_no_content, 1_basic structure, #2_releases_existing

Topic of the projet:
Bayesian_approaches, causality, connectome, data_visualisation, deep_learning,
diffusion, diversity_inclusivity_equality, EEG_EventRelatedResponseModelling,
EEG_source_modelling, Granger_causality, hypothesis_testing, ICA, information_theory,
machine_learning, #MR_methodologies, neural_decoding, neural_encoding, neural_networks,
PCA, physiology, reinforcement_learning, reproducible_scientific_methods, single_neuron_models,
statistical_modelling, systems_neuroscience, tractography

Tools used in the project:
#AFNI, #ANTs, #BIDS, Brainstorm, #CPAC, Datalad, DIPY, FieldTrip, fMRIPrep, #Freesurfer,
#FSL, Jupyter, MNE, MRtrix, #Nipype, NWB, #SPM

Tools skill level required to enter the project (more than one possible):
#comfortable, #expert, #familiar, #no_skills_required

Programming language used in the project:
no_programming_involved, C++, #containerization, #documentation, Java, Julia, #Matlab,
#Python, R, shell_scripting, #Unix_command_line, Web, #workflows

Modalities involved in the project (if any):
behavioral, DWI, ECG, ECOG, EEG, eye_tracking, fMRI, fNIRS, MEG, #MRI, PET, TDCS, TMS

Git skills reuired to enter the project (more than one possible):
0_no_git_skills, 1_commit_push, #2_branches_PRs, 3_continuous_integration

[x] I added all of the labels I want an associate to my project

Project Submission
Submission checklist
Once the issue is submitted, please check items in this list as you add under ‘Additional project info’

[x] Link to your project: could be a code repository, a shared document, etc.
[x] Goals for Brainhack Global 2020: describe what you want to achieve during this brainhack.
[x] Flesh out at least 2 “good first issues”: those are tasks that do not require any prior knowledge about your project, could be defined as issues in a GitHub repository, or in a shared document.
[x] Skills: list skills that would be particularly suitable for your project. We ask you to include at least one non-coding skill. Use the issue labels for this purpose.
[x] Chat channel: A link to a chat channel that will be used during the Brainhack Global 2020 event. This can be an existing channel or a new one. We recommend using the Brainhack space on Mattermost.

Optionally, you can also include information about:

[ ] Number of participants required.
[x] Twitter-sized summary of your project pitch.
NeuroDesk - A flexible, scalable, and easy to use data analysis environment for reproducible neuroimaging
[x] Provide an image of your project for the Brainhack Global 2020 website.

We would like to think about how you will credit and onboard new members to your project. If you’d like to share your thoughts with future project participants, you can include information about:

[x] Specify how you will acknowledge contributions (e.g. listing members on a contributing page).
contribution page + paper co-authorship once in a publishable state
[ ] Provide links to onboarding documents if you have some:

Dear @davidmeunier79 Thank you very much for your project submission. Your issue looks all ready for publishing. I will merge it with the webpage! 🎉


Cant load the module in Windows64

By adding in the modulmanager sdr++ is freezing.....
SDR++ V1.2.0 running in Adminmode
greetings
Martin

See https://github.com/dbdexter-dev/sdrpp_radiosonde/issues/27


Update machine-learning-recommendation-api-documentation.md

Update build status descriptions.

Hi @LuisCabrer, I'm your friendly neighborhood Azure Pull Request Bot (You can call me AZPRBOT). Thanks for your contribution!

It looks like you're working at Microsoft (luisca). If you're full-time, we DON'T require a contribution license agreement.

If you are a vendor, or work for Microsoft Open Technologies, DO please sign the electronic contribution license agreement. It will take 2 minutes and there's no faxing! https://cla.azure.com.

TTYL, AZPRBOT;


fix: Fix rollup.config.js for Windows

I'm not sure exactly why this stopped working, but sometime late last year this started resulting in an error message on Windows machines:
.vdiff\.report\temp\index.html → .vdiff\.report...
[!] Error: Could not find any HTML files for pattern: .vdiff\.report\temp\index.html

/home/runner/work/testing/testing/src/server/rollup.config.js
Error:   7:14  error  'process' is not defined  no-undef

Should we have separate eslint configs or the browser versus the server folders? Or just add node: true to the main config?

/home/runner/work/testing/testing/src/server/rollup.config.js
Error:   7:14  error  'process' is not defined  no-undef

Should we have separate eslint configs or the browser versus the server folders? Or just add node: true to the main config?

I thought we had created separate configs early on 🤔

We definitely talked about it

Thank you @svanherk 🥳


VSTS nuget task. Unable to set 'externalFeedCredentials' for multiple feeds

From @Roraa
Details about Problem
NuGet product used: VSTS build task 'NuGet' (YML build)
NuGet version: 4.4.1
Nuget task configuration
- task: NuGetCommand@2
  displayName: NuGet restore
  inputs:
    feedsToUse: config
    nugetConfigPath: 'NuGet.config'
    externalFeedCredentials: *tried all sorts of values here...*
    noCache: true

Issue
When creating a (normal) VSTS build and adding a nuget task, with the restore command selected, we get an option Credentials for feeds outside this account/collection which allows us to set multiple feed credentials.
When using the same task in a YML VSTS build, the corresponding property externalFeedCredentials only accepts 1 feed credential.
Expected behavior
externalFeedCredentials should be an array, if externalFeedCredentials already accepts a serialized array as a string it should be documented so.
Detailed repro steps so we can see the same problem

Create a YML build in vsts
Add the nuget task as configured above
Notice that you can only define 1 externalFeedCredential and not multiple

Update; it seems that a CSV string with GUIDs do work. Follow the following steps to get this string:

Create a normal build (non yml)
Configure nuget restore with the credentials as you would in your yml build
Export the build defenition to JSON
Copy the value of 'externalEndpoints' (this is an alias of 'externalFeedCredentials')
Use the copied value in your yml build

@Roraa The externalFeedCredentials value is not exported in the View YAML button, which is not very helpful

@bergmeister correct, I had to export the build definition to json to retrieve the correct value

@Roraa Thanks for the tip. :-)

Thanks for letting us know! This is a bug on the server (not this repo) and would repro for any task with comma separated endpoints. I'm going to close the issue here. We are tracking the issue internally (internal work item 1272614)

Note, you should also be able to set the friendly names in YAML (comma separated).

Nevermind, leaving this open here for now

Just hit this too, very unexpected. Thanks for the JSON export tip.

Closing this as the associated work item from Eric was completed around August of 2018 and we haven't heard any other issues since then.


[freerdp] ld: library not found for -lwinpr-tools on macOS

@dg0yt  I see ports/freerdp/vcpkg.json. winpr-tools is !ios. Why?
"winpr-tools": {
  "description": "Build winpr tools",
  "supports": "!android & !ios & !uwp"
},

The following error appears on macOS:
[ 80%] Building CXX object build_plugins/FreeRDP/Client/CMakeFiles/PluginClientFreeRDP.dir/DlgGetUserPasswordFreeRDP.cpp.o
[ 80%] Building CXX object build_plugins/FreeRDP/Client/CMakeFiles/PluginClientFreeRDP.dir/DlgDesktopSize.cpp.o
[ 80%] Building CXX object build_plugins/FreeRDP/Client/CMakeFiles/PluginClientFreeRDP.dir/PluginClientFreeRDP_autogen/EJRQKI7XPS/qrc_translations_FreeRDP.cpp.o
[ 81%] Linking CXX shared library ../../../plugins/Client/libPluginClientFreeRDP_d.dylib
ld: library not found for -lwinpr-tools
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make[2]: *** [plugins/Client/libPluginClientFreeRDP_d.0.0.26-75-g24432233.dylib] Error 1
make[1]: *** [build_plugins/FreeRDP/Client/CMakeFiles/PluginClientFreeRDP.dir/all] Error 2
make: *** [all] Error 2
Detail see: https://github.com/KangLin/RabbitRemoteControl/actions/runs/8368726585/job/22913291207#step:14:1495

ios: The feature is meant to control winpr-tools executables, not libs. But probably this is coupled at the moment. I didn't expect the tools lib to be used outside freerdp's own tools.
osx: So you want to use the winpr-tools library. It is installed as libwinpr-tools3.a, according to the CI logs. Note the 3.
But AFAICS the CMake config provided by port freerdp doesn't offer a target winpr-tools. The target  would encode the exact lib location. And that's a problem because other freerdp targets refer to winpr-tool via interface link libraries.
This is a port bug. The build directory has export files at least when winpr-tools is enabled.
(That's the downside of not using target namespaces: Poor diagnostics.)

ios: The feature is meant to control winpr-tools executables, not libs. But probably this is coupled at the moment. I didn't expect the tools lib to be used outside freerdp's own tools.

No, the libs are always built. We just lack the cmake config. PR is coming.

No, the libs are always built. We just lack the cmake config. PR is coming.

No, I mixed it up again: You don't get the winpr-tools lib without actually building tools (winpr-hash, winpr-makecert). I won't change this aspect: It needs patching or upstream changes.
You can still test the feature on ios by modifying the manifest locally, or by using --allow-unsupported. If it builds successfully, we can relax the condition.

@dg0yt Thank you.

It is not fixed until https://github.com/microsoft/vcpkg/pull/37589 is merged.

It is not fixed until #37589 is merged.

The is not bug. I am modify. please close #37589 . thank you!

@JonLiu1993 Why reopend?

It is not fixed until https://github.com/microsoft/vcpkg/pull/37589 is merged.

It is not bug. I am modify. please close #37589 . thank you!

There is a BIG FAT port bug. CMake config is incomplete, not providing all targets as cross-referenced.

ld: library not found for -lwinpr-tools

This should never appear. The lack of the winpr-tools CMake target should already stop the CMake configuration of your project, not letting you proceed to the build.
If the target would be named FreeRDP::winpr-tools, it would be obvious.
If the project used target_link_libraries main private $<TARGET_NAME:winpr-tools>), you would get a similar effect even without a namespace prefix.

It is not bug. I am modify. please close #37589 . thank you!

There is a BIG FAT port bug. CMake config is incomplete, not providing all targets as cross-referenced.

It's better to file a new bug. It is not the main cause of this PR.

It's better to file a new bug. It is not the main cause of this PR.

It is, as explained in https://github.com/microsoft/vcpkg/issues/37581#issuecomment-2011539338.
Please don't close the bug again. It is destructive.

Error message in title and original post:

This is the result of my forgetting find_package(winpr-tools)

Error message in title and original post:

ld: library not found for -lwinpr-tools

This should never appear. The lack of the winpr-tools CMake target should already stop the CMake configuration of your project, not letting you proceed to the build. If the target would be named FreeRDP::winpr-tools, it would be obvious. If the project used target_link_libraries main private $<TARGET_NAME:winpr-tools>), you would get a similar effect even without a namespace prefix.

This is the result of my forgetting find_package(winpr-tools)

I'm glad that you found that you don't need it, because it resolves the ios aspect.
find_package(winpr-tools) only works when the port bug is fixed. And the port bug must be fixed to resolve the cross references in exported targets. And so I'm glad that your error report quickly put us on the right track. I used the chance to look for more missing configs, and fixed them, too.
(Maybe I also need to check that there are find_dependency calls as needed...)

@dg0yt Good luck :)


[efs-provisioner] Fails to delete "saved" volume

Using efs-provisioner v2.4.0 on Kubernetes 1.15.10, I noticed it fails to delete the storage for a PersistentVolume if the PersistentVolume was previously "saved" after being deleted externally.
Using efs StorageClass with
reclaimPolicy: Delete
volumeBindingMode: Immediate

When a PersistentVolumeClaim (pvc) is created using the efs storage class, efs-provisioner creates a PersistentVolume (pv) and stores the data on the EFS file system in a directory named /efs-provisioner/{pvc-name}-{pv-name}. When the PersistentVolumeClaim is deleted and the reclaimPolicy is "Delete", efs-provisioner deletes its PersistentVolume and removes the /efs-provisioner/{pvc-name}-{pv-name} directory and all the data in it from the EFS file system.
If the PersistentVolume Kubernetes resource is deleted, for example via kubectl delete, efs-provisioner will attempt to "save" it and the logs will show something like:
Trying to save persistentvolume "pvc-bbe5e4fa-d9e3-4a43-aed7-d9f3a4f31cfe"
persistentvolume "pvc-bbe5e4fa-d9e3-4a43-aed7-d9f3a4f31cfe" saved

The bug is that after saving a PersistentVolume this way, if you then immediately (and maybe later) delete the PersistentVolumeClaim, efs-provisioner deletes the PersistentVolume Kubernetes resource, but it does not remove the data from EFS. It is abandoned there and difficult to notice or clean up using standard Kubernetes tools. Since EFS storage is relatively expensive, this can be a significant problem.

/remove-lifecycle stale
Can someone please look into this?

Thanks for reporting the issue!
This repo is no longer being maintained and we are in the process of archiving this repo. Please see https://github.com/kubernetes/org/issues/1563 for more details.
If your issue relates to nfs provisioners, please create a new issue in https://github.com/kubernetes-sigs/nfs-ganesha-server-and-external-provisioner or https://github.com/kubernetes-sigs/nfs-subdir-external-provisioner.
Going to close this issue in order to archive this repo. Apologies for the churn and thanks for your patience! :pray:


Cypress code revision for advanced functionalities

Ran cypress/integration/advanced-functionalities/index.js file and see which tests fail and fix them.

https://github.com/cortezaproject/corteza-e2e-cypress/pull/70

for today: resolve mebers bug  and continue with  role revisioning


fix code that reverts screen mode change

fixes an issue where attempting to change into a screen mode the VDP has insufficient RAM to display would result in being left in the faulty/dodgy screen mode
addresses the "missing rows" corruption described in #75

I do wonder if the check in change_mode to stop the call if the VDP thinks it’s already in the requested mode is actually necessary? Could there be value in removing the check completely and just forcing a mode change, even if it’s to the same mode?
Treating the mode change (even to the same mode) as being an opportunity to refresh/reset the display state would also solve the following issues:
If legacy mode support (added in PR #68) is enabled, it does not currently recognise a mode change if the requested mode is the same number as the currently selected mode. Forcing the mode change would resolve this.
The mode change could could also disable paged scrolling (as per issue #72).
So I can see some advantages in dropping the check, but are there any disadvantages?

My initial gut feel on reading your comment @julianregel was that I kinda like the skipping of the resolution change, as it does feel unnecessary to rip-down and bring back up the underlying fab-gl stuff.  This has however made me think further on this issue tho.
As you point out, swapping to legacy modes is indeed not currently compatible with the code.  That would indeed be fixed by removing the "is this the same mode" check and always refreshing the screen mode.
As it stands, #72 has actually already been fixed in the most recent commit on the main branch.
What the current code saves by skipping the change_resolution call for the same mode is not really all that much IMHO - it avoids some calls to the VGAController that shouldn't do anything, primarily its the ripping down and re-creating of the Canvas object.  Pretty much the rest of the state gets reset outside of that check anyway.  We may even be able to remove the cls call.
In conclusion - yep - let's remove the check. :grin: Having it there isn't really gaining us much of anything.

@julianregel done - this version should fix the legacy modes issue you mentioned too

Whilst this fixes the issues being discussed, there is still a bug, which is related to legacy modes.
For me, new mode 0 (legacy mode 3) fails with an insufficient memory error.
The following sequence breaks things for me:
VDU 23,0,193,1 : REM legacy modes
MODE 0
VDU 23,0,193,0 : REM new modes
MODE 0

If I do that then I get a report of error 2 on restoring mode, and I'm left with the machine in an unusable state.
I think that this may not be a new bug per-se... as it might be possible to reproduce that via a different sequence of modes and swapping to/from legacy.
I wonder if the simplest solution to that bug may not just be to remove support for the "legacy" screen modes?
The upside of the legacy mode support is that entering VDU 23,0,193,1 before trying to run code that used a legacy mode will let it work without needing to change that code.  However one could argue that there is not that much legacy code out there and it's a fairly easy fix to change which screen mode legacy code is trying to use.

Just worked out that removing the CLS leaves sprites behind on mode change...
I have therefore restored the CLS call, and made a further change_mode fallback call in the event of a second mode change error to swap to mode 1.  As mode 1 seems to be safe, whether running in legacy or new modes, that should give a proper fix for the "unusable state" error I mentioned above.  This fixes all issues in my testing.

I wanted to ensure that the new modes were logically ordered, but there were comments in the Facebook group that some were unhappy with the idea of losing the existing modes (and numbering) as a result of the new modes and that it would break code. Hence legacy modes.
I'm not sure how much software would be impacted in reality, but it was a "quick win" to add the support and I did get a message from someone expressing thanks for that feature.
I guess for most use cases, switching to legacy modes would be a one-way operation in order to run a specific piece of existing software. While it’s nice - and theoretically straightforward - to switch back to new modes, the alternative could be to reset the Agon after going into legacy modes.
So one option might be to support switching into legacy modes, but either not support switching back, or leaving it as an undocumented feature (as it may be unreliable)? Not necessarily advocating that approach, but throwing it out there.
I wonder if this bug has the same underlying issue with available memory that you’ve already called out and that getting to the bottom of that will resolve this issue as well?

I did some further analysis on this issue, and made some notes against #75 - https://github.com/breakintoprogram/agon-vdp/issues/75#issuecomment-1703201078
As noted in that comment, there are significant issues with the memory usage related to how screen modes are handled.  Even before the new screen modes were added, some screen modes would effectively only be accessible once.  Legacy mode 3 was a good example of that - on a fresh boot the mode could be used, but change to mode 2 first and you'd be out of luck.
That comment links to a PR on the Console8 VDP codebase which provides a solution to the underlying memory issues, and indeed all of the issues around screen modes.  It achieves this by taking a somewhat different approach to memory management of the VGA controllers.  In my testing, this solution gives significantly more available free internal memory on the VDP without needing to move any memory for screen handling into PSRAM.


Use status code instead of message to detect region change

:loudspeaker: Type of change

[x] Bugfix
[ ] New feature
[ ] Enhancement
[ ] Refactoring

:scroll: Description
Instead of checking whether the S3Exception message matches "PermanentRedirect", just check whether the code is 301 (by definition, permanent redirect).
:bulb: Motivation and Context
The AWS SDK has a null message when the HeadObject operation uses the wrong region, meaning that the existing CrossRegionS3Client implementation doesn't detect it. By using the code instead, the client works on more use cases.
https://github.com/aws/aws-sdk-java-v2/issues/3287
:green_heart: How did you test it?
Run locally in a project which gets the file size prior to actually reading the file, and has failed up until this point.
:pencil: Checklist

[x] I reviewed submitted code
[x] I added tests to verify changes
[ ] I updated reference documentation to reflect the change
[x] All tests passing
[x] No breaking changes

:crystal_ball: Next steps

Well that was interesting. When I ran the tests locally, it reformatted the entire file to replace the tabs with spaces, so i decided not to commit it. This time I used make build` as you suggested and it fixed all the formatting.

@maciejwalkowiak is there anything else needed from me here?


Sling Pouch

THIS REQUIRES A NEW SYSTEM
https://cm-ss13.com/wiki/Marine_Equipment#Sling_Pouch

#762
in Resources/Prototypes/_CM14/Entities/Objects/Clothing/pouches.yml on line 634 with id CMPouchSling
still requires a new system, so will keep this issue open.


Fix bio nickname not saving.


QA: ScanData API

Time category: https://its-pro.ucsd.edu/browse/MA-78
ScanData API V1 & V2 in QA are not working. Investigate and resolve
This is done when:

[ ] ScanData API in QA has been synced from Prod and is operational

ScanData QA API exists, but points to AWS Prod, resulting in Error 401: Unauthorized
RFI - How to proceed in regard to Campus VPC and SAP HANA security groups utilized by postScanData, getScanData Lambda's on AWS Prod for AWS QA env

QA version of ScanData at the DB level is in the works.


docs: fix typo in faq/index.mdx

What is it?

[ ] Feature / enhancement
[ ] Bug
[x] Docs / tests

Description
necesary -> necessary
Checklist:

[ ] My code follows the developer guidelines of this project
[ ] I have performed a self-review of my own code
[ ] I have made corresponding changes to the documentation
[ ] Added new tests to cover the fix / functionality

Thank you so much!


Update Module to official Terraform module spec. Bump Vault and Consul versions.

This PR:

Updates the code to the official Terraform module spec
Bumps Vault and Consul versions to the latest as of today.

Merging now so I can cut a new release. Feedback welcome as always.


Transfer Ownership

Please transfer the project ownership to @Lamassau

@AlKass I was not able to transfer to the org because it was pending the transfer back to you. I canceled your transfer and did it directly to the Org.


Customize button inset and spacing

I can't figure out a combination of buttonPadding, maximumButtonWidth and minimumButtonWidth that will let me accomplish something like this when the buttons are fully visible. In this case the button image is 48 pixels wide and there is no title. Is this possible?
[20 pixels] [Button] [16 pixels] [Button] [16 pixels] [Button] [20 pixels]

Please read the ‘Transition Delegate’ portion of the README. This gives you access to the underlying button that you can tweak the content inset in.

How would I modify the position of the button and its spacing relative to its parent in the transition? Are there any examples of explicitly setting the spacing between buttons this way?

Did you try setting the contentEdgeInsets for the UIButton? Meaning, the for the leading and trailing buttons, u can set their left and right content inset to 4 to achieve your desired spacing effect. This may or may not work, depends on what the button looks like.


chore: CE changes for module input autocomplete

Description
CE Changes for the module input autocomplete feature in this PR - https://github.com/appsmithorg/appsmith-ee/pull/2706

Move flattenDef, generateDef and other utils functions to defCreatorUtils.ts
Add entityDefGeneratorMap that will be extended on EE to support module input entity

PR fixes following issue(s)
EE changes will fix https://github.com/appsmithorg/appsmith-ee/issues/2506
Type of change

Chore (housekeeping or task changes that don't impact user perception)

Testing
How Has This Been Tested?

CI Tests

Checklist:
Dev activity

[x] My code follows the style guidelines of this project
[x] I have performed a self-review of my own code
[ ] I have commented my code, particularly in hard-to-understand areas
[x] I have made corresponding changes to the documentation
[x] My changes generate no new warnings
[ ] I have added tests that prove my fix is effective or that my feature works
[x] New and existing unit tests pass locally with my changes
[ ] PR is being merged under a feature flag

/ok-to-test sha=1a550c5

/ok-to-test sha=eb9b16e


How can I dump DBFs to CSVs faster?

I ran a benchmark dumping a DBF to CSV 1,000 times using dbfread 2.0.7 and Pandas 0.24.1 and comparing it to https://github.com/yellowfeather/dbf2csv.
The file I used was a 1.5 MB DBF in 'FoxBASE+/Dbase III plus, no memory' format with 4,522 records and 40 columns made up of 36 numeric fields, 2 char fields and 2 date fields. I used CPython 2.7.12 for dbfread and I compiled dbf2csv using GCC 5.4.0 and libboost v1.58.0. I ran the test on a t3.2xlarge instance on AWS.
The disk can be written to at 115 MB/s according to:
dd if=/dev/zero of=./test bs=1G count=1 oflag=dsync

dbfread and Pandas managed to write the CSV 1,000 in 26 minutes while dbf2csv took just under 74 seconds, a 21x difference in performance.
These were the steps I took during the benchmark:
$ vi run_1

for i in {1..1000}; do
    ./dbf2csv -c FILE.DBF > FILE.csv
done

$ time bash run_1 # 1m13.699s, 21x faster

$ vi run_2.py

from   dbfread import DBF
import pandas as pd
dbf = DBF('FILE.DBF', encoding='latin-1', char_decode_errors='strict')
pd.DataFrame(iter(dbf)).to_csv('FILE.csv', index=False, encoding='utf-8', mode='w')

$ vi run_2

for i in {1..1000}; do
    python run_2.py
done

$ time bash run_2 # 25m59.877s

The DBF would have sat in the page cache but nonetheless represented 1,489 MB of data read. The resulting CSV represented 638 MB. So this works out to 0.95 MB/s read and 0.41 MB/s written.
Do you know of any way I could see improved performance in this workload using dbfread?

Can you benchmark the imports alone? I presume much of your benchmark is spent import pandas, which is quite a heavy dependency (takes 0.7s, warm, on my machine).
Plus there's a bit of overhead from the non-lazy DataFrame creation, but it's not terrible at 25% using my dummy dataset (1.1 MB, 20 columns, strings and ints).

@kokes Could you give me a quick example of yield from using Python 2.7? I'm not in a position to use Python 3 for this issue.

I ran the following which only imports Pandas and dbfread once and doesn't re-execute Python during each iteration. This wasn't run on Python 2.7.12 due to yield from being used. It was run on Python 3.5 with dbfread 2.0.7 and Pandas 0.24.2. It brought it down to 11m30s. Its a solid improvement.
$ vi run_3.py

from   dbfread import DBF
import pandas as pd

def get_dbf():
    yield from DBF('FILE.DBF', encoding='latin-1', char_decode_errors='strict')

for _ in range(0, 1000):
    pd.DataFrame(get_dbf()).to_csv('FILE.csv', index=False, encoding='utf-8', mode='w')

$ time python3 run_3.py # 11m30.328s

Any more ideas of how we could get this closer to 74 seconds?

yield from can be replaced by
data = DBF(...)
for el in data:
    yield el

Any more ideas of how we could get this closer to 74 seconds?

It comes down to what the limits are. I tried running the three obvious pieces of code:

Pandas materialization and csv export (34.4 seconds)
Streaming into a CSV file using the standard csv package (25.4 seconds)
Streaming through the rows and doing nothing (21.6 seconds)

(I also tried the eager mode in dbfread itself, using load=True, but got pretty much identical results)
This goes to show that the major overhead is this library and unless you change it's changed, you won't get faster than the baseline. So I wouldn't focus on the CSV writer, I'd look at the parsing itself, that is if you really want to go faster.

dbfread author here.
I guess the main reason dbf2cvs is faster is that it's written in C++. A lot of the operations in dbfread are fiddling with little bits of binary data which would be a lot faster in a language closer to the hardware.
That said I'm sure dbfread could be faster and I'd be interested in any suggestions you might have.
@kokes load=True calls the same code as load=False so I wouldn't expect it to be any faster. (It just calls the same generator and wraps the result in a list.) It should even be a little bit slower since it does a second pass to load deleted records:
    def load(self):
        if not self.loaded:
            self._records = list(self._iter_records(b' '))
            self._deleted = list(self._iter_records(b'*'))

@kokes I ran the following which only imports Pandas and dbfread once and doesn't re-execute Python during each iteration. This wasn't run on Python 2.7.12 due to yield from being used. It was run on Python 3.5 with dbfread 2.0.7 and Pandas 0.24.2. It brought it down to 11m30s. It's a solid improvement.
$ vi run_3.py

from   dbfread import DBF
import pandas as pd

def get_dbf():
    yield from DBF('FILE.DBF', encoding='latin-1', char_decode_errors='strict')

for _ in range(0, 1000):
    pd.DataFrame(get_dbf()).to_csv('FILE.csv', index=False, encoding='utf-8', mode='w')

$ time python3 run_3.py # 11m30.328s

Any more ideas of how we could get this closer to 74 seconds?

In the loop you use to save the CSV, you are instantiating a new DataFrame object at every  iteration, this definetly adds up in wasted time. You don't need pandas here. When you iterate over a DBF object, you get an ordered dict. You can write them straight to the CSV file using csv.DictWriter as shown here. On a SSD drive I am getting ~8k lines written per second. And I am writing to a gzipped csv which adds the overhead of compression.

In the loop you use to save the CSV, you are instantiating a new DataFrame object at every iteration, this definetly adds up in wasted time. You don't need pandas here. When you iterate over a DBF object, you get an ordered dict. You can write them straight to the CSV file using csv.DictWriter as shown here. On a SSD drive I am getting ~8k lines written per second. And I am writing to a gzipped csv which adds the overhead of compression.

We've already discussed this above: https://github.com/olemb/dbfread/issues/38#issuecomment-547378974
And since we know how fast the parsing itself is (by not writing anything, in the same post), we know the perf ceiling of this library - and as the author notes, the difference against the other library is primarily due to the language used.
I don't think there's much to add here.

you're welcome.


Squiggly lines on diagnostic are not rendered correctly

The squiggly lines on diagnostics are sometimes rendered with gaps in them, instead of as one continuous squiggly line.

It can also occur that multiple squiggly lines are rendered across each other, when there are squiggly lines from a regular diagnostic and from the custom rendering, such as when a postcondition fails to verify somewhere, and the postcondition also has a wellformedness error:

For the first one I think these are two different errors. One is the failing postcondition, the other is the return path.
For the second one, it's different.

For the first one I think these are two different errors. One is the failing postcondition, the other is the return path.

But even in the failing postcondition, the part before the {, the squiggly lines are not contiguous, they're interrupted at "tall" characters like (, | and [

I close it as won't fix because we have no control over the styling of squiggly bars. The only alternative would be to publish double diagnostics and underline postconditions in red, but I don't think it would result in a good user experience. I am very happy that the two have different colors and slightly different shapes because it helps me distinguish the errors on the well-formedness on the precondition (red) from the postconditions that could not be proven on the body (orange)

I feel this feature is more for power users. I don't understand what it does, so it just looks broken to me. Do we have an option to turn this it off?

What makes you feel this feature is more for power users?
For a novice user, postconditions feel like tests, and not reporting that a test is failing is not a good user experience. We already iterated on that by adding a red rectangle in front of failing postconditions.
No there is no option to turn it off, I don't see any reason to do so except that it looks broken, which isn't, what you see is just a limitation of VSCode's squiggly line styling. One thing that you might want is to switch highlighting a token instead of a range like it was before and for all other errors.
The orange squiggly bars are highlighting postconditions which are failing for at least one return path. They are not reported as diagnostics, as the action point for the diagnostic is the return path. They are only sub-diagnostics, but equally important in verification.
Let me give you an example of when it can be useful. I start writing a lemma, some requires, and some ensures. I have not yet stepped in the body, as Dafny applies induction directly, so for the first ensures, they serve just as a test to ensure things are as expected. Being able to have squiggly lines on them is priceless, because they behave like assertions if they were inline in the body: I can know whether something is not trivial. And when I'm done writing my ensures, I know exactly which ensures I need to turn into assertions that I will prove using rewriting and the weakest precondition calculus.

What makes you feel this feature is more for power users?

Maybe that's not the right term, but for anyone not familiar with what these custom squiggles map to, they can make the IDE look broken. As a VSCode user, I expect the squiggles to map to the diagnostics in the problems view. These squiggles both looks slightly different and
For a novice user, postconditions feel like tests, and not reporting that a test is failing is not a good user experience. We already iterated on that by adding a red rectangle in front of failing postconditions.

No there is no option to turn it off, I don't see any reason to do so except that it looks broken, which isn't, what you see is just a limitation of VSCode's squiggly line styling. One thing that you might want is to switch highlighting a token instead of a range like it was before and for all other errors.
The orange squiggly bars are highlighting postconditions which are failing for at least one return path. They are not reported as diagnostics, as the action point for the diagnostic is the return path. They are only sub-diagnostics, but equally important in verification.
Let me give you an example of when it can be useful. I start writing a lemma, some requires, and some ensures. I have not yet stepped in the body, as Dafny applies induction directly, so for the first ensures, they serve just as a test to ensure things are as expected. Being able to have squiggly lines on them is priceless, because they behave like assertions if they were inline in the body: I can know whether something is not trivial. And when I'm done writing my ensures, I know exactly which ensures I need to turn into assertions that I will prove using rewriting and the weakest precondition calculus.

We can afford this secondary highlight only because the postcondition is part of the same method, hence the same error context. Doing this secondary squiggly line on an unrelated predicate (for postconditions) or function precondition would provide the wrong feeling that verification is not modular.

Makes sense. Thanks!

I had originally planned to dynamically highlight those remote places, i.e.. mark them as error when the user places the caret at a failing postcondition or a failing return point, but it turns out, often these places are screens apart, and according to the numerous customer feedback I have gathered, people don't want to scroll to a place to see what is wrong exactly. They just want the information to be available on hover.

VSCode already shows related location error messages with a jump to link when you hover over an error diagnostic:

What was there to still resolve using hovers?

VSCode already shows related locatio messages with a jump to link when you hover over an error diagnostic:
image
What was there to improve using hovers?

Previously, the message was saying "this is the postcondition that might not hold" and there was just a link, which forced people to actually navigate out of the context of the error to see what the failing postcondition was. That was the thing that I improved, which resulted in the message quoting the postcondition code that you now see. Now, users don't need to navigate to another place in the code to see the failing postcondition.

VSCode already shows related location messages with a jump to link when you hover over an error diagnostic:
image
What was there to improve using hovers?

Previously, the message was saying "this is the postcondition that might not hold" and there was just a link, which forced people to actually navigate out of the context of the error to see what the failing postcondition was. That was the thing that I improved, which resulted in the message quoting the postcondition code that you now see. Now, users don't need to navigate to another place in the code to see the failing postcondition.

Makes sense. I've created a related ticket in the VSCode repo: https://github.com/microsoft/vscode/issues/171401
I think I meant to ask about LSP Hover information though. Sometimes errors are also shown in there, such as here:

Why is that done?

I think I meant to ask about LSP Hover information though. Sometimes errors are also shown in there, such as here:

Why is that done?

To put a link on "Error" that redirect to the page of Verification debugging, which is helpful to fix verification errors
To display the assertion number (useful to determine which assertion is taking too long if :vcs_split_on_every_assert is used),
To display the assertion count, to determine whether it might be worth splitting an assertion batch..
To display the resource count of the assertion batch, and if it is too big, to display a warning with a link to verification debugging when verification is slow.

Have we considered well enough, flipping the ranges of the diagnostic and its related location for postcondition failures? Maybe that would make the related location squiggles obsolete?

Yes, not in this thread, but in offline conversations, we determined that the error's main position should be where the assertion is physically implicitly present. Errors should be where users are typically expected to modify something to fix them.
When postconditions fails, there are typically two fixes:  either fix the specification, or fix the code. We found that the latter one is much much more prevalent.


[ECS] Make exclude_checkers compatible with skip

Current api is confusing at least.
See https://github.com/Symplify/Symplify/issues/1295#issuecomment-451219727
# ecs.yml
parameters:
    exclude_checkers:
        SomeChecker: ~

=
# ecs.yml
parameters:
    skip:
        SomeChecker: ~

Ref: https://github.com/Symplify/Symplify/blob/25a0f02c509a48bc1216aa3bcf2b5dae98736f10/packages/EasyCodingStandard/src/DependencyInjection/CompilerPass/RemoveExcludedCheckersCompilerPass.php

It also in unclear to me what the difference of exclude_checkers and skip is.
To me it reads like being the same thing with two different names.

Exactly. I think it was for compiler vs parameter reasons, but now I know it can be merged to one parameter.


Scissors: Mai

Great work on this project!  With some very minor modifications I was able to get this to pass all of the tests.  This project is green.


[TF-TRT] Adding TF_TRT_OP_FAKELIST env var to allow TF-TRT segmentation experimentation

This PR introduces the env var TF_TRT_OP_FAKELIST=OpName1,OpName2,....
The motivation of this change is to allow to experiment with the impact on graph segmentation of adding converter X, Y or Z.
This API is not designed for users, but rather TF-TRT team to evaluate the importance / impact of the different fearture requests.
It works by intercepting the call to OpConverterRegistry::Impl::LookUp and return the FakeOp converter in case the OpName matches any of the names passed in TF_TRT_OP_FAKELIST.
This is expected to have zero impact on any of the current workflows.

@bixia1 for review

@bixia1 for review

@bixia1 as mentioned during the meeting, ready for review

@DEKHTIARJonathan Can you please check @bixia1's comments and keep us posted ? Thank you!

@bixia1 what is holding back in this PR ? It's been approved and not merged

Closing in order to transition to Trusted Partner Program. Will re-open.


ignite attach followed by ignite add ignite-ir-boilerplate = lots of errors

Using ignite 2.0.0-rc.1 and latest ir-boilerplate released today
On an existing project
ignite attach
ignite add ignite-ir-boilerplate

This adds ignite-ir-boilerplate as a npm dependency but does not create any files in the App folder
then
ignite generate screen LoginScreen

and got this warning during generation
✔ App/Containers/LoginScreen.js
✔ App/Containers/Styles/LoginScreenStyle.js
vvv -----[ DEBUG ]----- vvv
TypeError: print.log is not a function
    at Object.module.exports [as run] (/Volumes/Omitted/com.mydomain.ignited-ir/node_modules/ignite-ir-boilerplate/commands/screen.js:61:11)
    at process._tickCallback (internal/process/next_tick.js:109:7)
    at Module.runMain (module.js:607:11)
    at run (bootstrap_node.js:427:7)
    at startup (bootstrap_node.js:151:9)
    at bootstrap_node.js:542:3
^^^ -----[ DEBUG ]----- ^^^

This command generated two files, including a LoginScreenStyle.js which has this in it
import { ApplicationStyles } from '../../Themes/'

But there is no Themes folder, my /App/ folder is completely empty save for the two files that were just generated
I also generated a saga
ignite generate saga SagaTest

which generated a file that has this
import SagaTestActions from '../Redux/SagaTestRedux'

But again.. there is no Redux folder, and it did not generate the SagaTestRedux
It also mentions that I need to do things in sagas/index.js but that file also doesn't exist
and so on..
Should I just copy the whole contents of the App folder from the node_modules ? But wouldn't that then include a bunch of demo files? What if I just want to use the generators in a clean project

https://github.com/infinitered/ignite-ir-boilerplate/pull/67 fixes the error you're seen.  It'll be included in the next release.
That error was preventing your files from being generated.
Also, you can use the generators separately if you ignite attach to an existing project instead of ignite new NewProject.  You'd then run ignite add ir-boilerplate.  This will bring in the generators, but not do anything to setup the boilerplate directories & files.


CX Incorrect_Permission_Assignment_For_Critical_Resources @ HammerHead.java [master]

Incorrect_Permission_Assignment_For_Critical_Resources issue exists @ HammerHead.java in branch master
A file is created on the file system by out in HammerHead.java at line 525 with potentially dangerous permissions.Similarity ID: -1972554239
Severity: Low
CWE:732
Checkmarx
Training
Recommended Fix
Lines: 525

Code (Line #525):
PrintWriter out = response.getWriter();

Issue still exists.

Issue still exists.

Issue still exists.

Issue still exists.

Issue still exists.

Issue still exists.


Update proper language identifier

:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

docs/setstdhandle.md
:white_check_mark:Succeeded
View

For more details, please refer to the build report.
Note: If you changed an existing file name or deleted a file, broken links in other files to the deleted or renamed file are listed only in the full build report.


contrib: Support prereleases in release prep scripts

Add support for vX.Y.0-rcN and vX.Y.0-snapshotN prereleases into the
start-release.sh and submit-release.sh scripts.

I've been testing these out to generate https://github.com/cilium/cilium/pull/17501 with a standard Cilium release process by just specifying the RC tag version. Will leave at draft until we go through the full process to see if there are missing pieces.

These changes will currently support preparing a vX.Y.0-rc0 release, but if we run it for vX.Y.0-rc1 then it will perform a diff between the latest vX.Y-1 series release rather than putting together a changelog for the vX.Y.0-rc0..vX.Y.0-rc1 changes.

I tested the first commit using instructions similar to those now updated in the .github issue template commit, and prepared v1.11.0-rc0 using those changes. The middle patches I just put together and I've done some initial testing locally to see whether they do roughly the correct thing, but we'll need to go through the -rc1 process to make sure that they work as intended all the way through. The issue template / docs updates, I've just assembled after the process so I think they capture everything that is needed but for those we would also need to follow the release process once more based on these instructions to iron out any bugs or missing steps.


Studio: migrate Working with Entities section

From: https://doc.cuba-platform.com/studio/#data_model_entities
To: I think we should create sub-page of the https://docs.jmix.io/jmix/0.x/data-model/entities.html article.
Add link from Tool Window to this new section.
That section is totally incomplete.
But let's migrate it as is, just adapting to Jmix.
In Jmix there are significant changes in creation dialog, actions (create DTO entity, create JPA entity).

fixed in #361


chore: bdd-sbhg-1586948237 to 0.0.1

chore: Promote bdd-sbhg-1586948237 to version 0.0.1

[APPROVALNOTIFIER] This PR is NOT APPROVED
This pull-request has been approved by:
To fully approve this pull request, please assign additional approvers.
We suggest the following additional approvers:
If they are not already assigned, you can assign the PR to them by writing /assign  in a comment when ready.
The full list of commands accepted by this bot can be found here.
The pull request process is described here

Needs approval from an approver in each of these files:

OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment


chore: fix nodeClaim tests failure

Fixes #N/A
Description
NodeClaim tests are failing because the standalone nodeClaims do not reference any nodePool. While adding the kubelet compatibility hash if this reference is empty, we should not throw an error and rather fall back to nodeClass kubelet config.
How was this change tested?
/karpenter snapshot
Does this change impact docs?

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

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

Pull Request Test Coverage Report for Build<PHONE_NUMBER>
Details

5 of 5 (100.0%)  changed or added relevant lines in 1 file are covered.
1 unchanged line in 1 file lost coverage.
Overall coverage increased (+0.003%) to 79.121%

Files with Coverage Reduction
New Missed Lines
%

pkg/providers/amifamily/ami.go
1
91.67%

Totals

Change from base Build<PHONE_NUMBER>:
0.003%

Covered Lines:
5942

Relevant Lines:
7510

💛  - Coveralls


Moved Resource to PuliResource

Ref: https://github.com/puli/issues/issues/119

The changes to composer.json and the other configuration files seem to be missing here.


Enhance browse-by-title and browse-by-subject functional presentation

When selecting a particular letter from which to start displaying results, e.g. "M", all the letters from A until picked "start-point" (from A until L in the given example) could be marked in lighter color or in other way made clear that they are not included in presentation.

Closing as this is outdated. The letters have been removed from Browse By Title/Subject.


Plugin gui

I was able to create a new study and go from raw data to a biom table using the interface.
I will keep looking at the interface tomorrow to see if there is any other bug due to the changes, but I think I caught all the issues in the study page.

Thanks @josenavas. Notice how there are still failures, I guess fixing those will help to minimize the possible errors.

We should be back on green! I've been able to go form the raw data to an analysis.

A few comments, nothing major. Gonna check the interface ...

Thanks @antgonza
While I was checking the interface yesterday, I had the feeling that split libraries was running faster in my machine that usual - did you had the same impression?

:+1:


Obsolete TestPathUtilities

First step towards completing https://github.com/aspnet/Extensions/issues/1697.
Marking this as obsolete so we can better identify where this used and make updates as described in https://github.com/aspnet/Extensions/issues/1697.
cc @aspnet/build @HaoK  - believe this should help us identify the cause of so many tests that don't work in Helix in the AspNetCore repo.

The other thing you should look for is calls to UseSolutionRelativeContentRoot since we don't typically have a sln on helix, I've been working around those by dropping a dummy sln in the publish directory https://github.com/aspnet/AspNetCore/blob/6a44aca6a204055ed9f18a7ed19634f85d4994db/src/Hosting/TestHost/src/WebHostBuilderExtensions.cs#L78

Updated with PR feedback. Planning to merge soon.
Re: UseSolutionRelativeContentRoot - @HaoK thanks for the tip! This API is probably okay for our customers to use when they are writing tests, but we have unique requirements, like distributed testing, which means the API should probably not be used in our test code.


frontal lisp misgenders women

this has caused an administration issue

owo accent also misgenders women

bothing of these accents combined make it impossible to use correct pronouns for she/her

isn't lisp SUPPOSED to cause problems by making all s letters into a th

Yeah this isn't a bug, it's not like swapping the pronoun its just doing a regex match for a certain consonant and swapping it for a different consonant sound to make it look like a speech impediment sounded out.
Is it also a bug that its "impossible" to say "know" as a dwarf because it will always be swapped for "ken?" no. This is working exactly as intended.


Added a Transform Example Launcher

Looks good, thanks! Will look at the actual example code when ready.


out-default and switch "-transcript"

hello
if i add out-default in middle of this expression it return enexpected result but if i add switch "-transcript" it return the exact result why ? i dont understand the use of this switch
Steps to reproduce

PS C:\> Get-Process -Id $PID

 NPM(K)    PM(M)      WS(M)     CPU(s)      Id  SI ProcessName
 ------    -----      -----     ------      --  -- -----------
     57    27.50      62.77       6.11     368   6 pwsh

PS C:\> Get-Process -Id $PID | Select-Object name,id

Name  Id
----  --
pwsh 368

PS C:\> Get-Process -Id $PID | out-default | Select-Object name,id

 NPM(K)    PM(M)      WS(M)     CPU(s)      Id  SI ProcessName
 ------    -----      -----     ------      --  -- -----------
     58    27.82      63.92       6.64     368   6 pwsh

PS C:\> Get-Process -Id $PID | out-default -Transcript | Select-Object name,id
Name  Id
----  --
pwsh 368

Environment data
> $PSVersionTable

Name                           Value
----                           -----
PSVersion                      6.1.0
PSEdition                      Core
GitCommitId                    6.1.0
OS                             Microsoft Windows 6.3.9600
Platform                       Win32NT
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0...}
PSRemotingProtocolVersion      2.3
SerializationVersion           <IP_ADDRESS>
WSManStackVersion              3.0

thanks

Inserting just Out-Default sends all pipeline input directly to the console, ignoring the remaining pipeline segments - which is expected behavior.
-Transcript is currently undocumented, but, from what I gather, its purpose is to send output just to a transcript (previously started with Start-Transcript), and not also to the host (console/terminal).
The surprising aspect is that it still passes the objects through, unlike without -Transcript, but whether the final pipeline segment still produces host output seemingly depends on whether a cmdlet (yes) or a script block (no) tries to produce output.
For instance, the following does not produce output, due to using a script block in the final segment:
# No output.
Get-Process -Id $PID | out-default -Transcript | ForEach-Object { $_.Name }

Note that the script block still receives the input object, but it cannot produce output, neither implicitly nor with Write-Output - you can, however, write to a different stream; e.g.:
# DOES write to the verbose stream.
Get-Process -Id $PID | out-default -Transcript | ForEach-Object { Write-Verbose -vb $_.Name  }

My sense is that both behaviors are ultimately the manifestation of a bug, because, arguably, Out-Default -Transcript should behave like Out-Default alone and not pass anything on through the pipeline.

thanks for your comments
here another mysterious cases:
PS C:\> # why fast ?
PS C:\> 1..1gb | Out-Default -Transcript | select -First 5
PS C:\> # and why so slow ?
PS C:\> 1..1gb | Out-Default | select -First 5
PS C:\> # No output..obiously
PS C:\> Get-Process -Id $PID | Out-Host -Paging | ForEach-Object { write-host $_.Name  }
PS C:\> # No output..obiously
PS C:\> Get-Process -Id $PID | Out-Default | ForEach-Object { write-host $_.Name  }
PS C:\>
PS C:\> Get-Process -Id $PID | Out-Default -Transcript | ForEach-Object { write-host $_.Name  }
powershell
ps C:\> no output on both case ??
PS C:\> Get-Process -Id $PID | Out-Default -Transcript | ForEach-Object -MemberName name
PS C:\> Get-Process -Id $PID | Out-Default  | ForEach-Object -MemberName name
PS C:\>

@iSazonov given the intended behaviour of Out-Default (output to console, not pipeline) I would be more inclined to think that the fact that adding the -Transcript switch changing that completely is most likely a bug -- unless you or one of the microsoft folks here can speak to what the -Transcript switch is supposed to do (given that it's undocumented).

I peeked at the source code and found this:
https://github.com/PowerShell/PowerShell/blob/e5a41777365d8edc9e2bf5457c2bd6f2a69e5db9/src/System.Management.Automation/FormatAndOutput/out-console/OutConsole.cs#L45-L52
While I don't have the full picture, I infer the following:

The switch is used internally , in the context of using the PowerShell SDK (API), and may never have been meant to be used from PowerShell code.

Passing the objects through is intentional.

Sticking an Out-Default in the middle of a pipeline - with or without  -Transcript - doesn't make much sense in general, given that Out-* cmdlets are usual the final pipeline stage.
Given that, I wonder if the inconsistency we've observed - with -Transcript present, (at least some) cmdlets still producing output while script blocks aren't - is worth fixing at all.
However, there is a potentially useful application for Out-Default -Transcript (as the last pipeline segment) which I've alluded to before, and it's something that @PetSerAl had pointed out to me:
With a transcript ongoing, you can selectively suppress console output for a given command while still sending the output to the transcript.
Given the comments in the source code, this is likely an unintentional feature, however, and, in fact, it is currently buggy:
Start-Transcript t.txt
'foo'   # outputs to console *and* to the transcript
'bar' | Out-Default -Transcript  # outputs to the transcript *only*
Stop-Transcript

In the console, you'll see:
Transcript started, output file is t.txt
foo  # Note how only 'foo' was printed to the console, not 'bar'
Transcript stopped, output file is /path/to/t.txt

In the transcript you'll see:
**********************
PowerShell transcript start
Start time:<PHONE_NUMBER>5404
# ....
**********************
Transcript started, output file is t.txt
foo
bar
bar  # !! bug - 'bar' was written *twice*
**********************
PowerShell transcript end
End time:<PHONE_NUMBER>5404
**********************

It's conceivable that users who have discovered the to-transcript-only behavior are relying on it (the bug notwithstanding), so it's probably worth fixing the bug (and, who knows, perhaps that will implicitly also fix the inconsistent middle-of-the-pipeline behavior).

given that Out-* cmdlets are usual the final pipeline stage.

In middle of pipeline I believe we should use Out-String.


[UNTESTED] fix selection of cinder-volume node

PR #1195 introduced breakage in Jenkins openstack-mkcloud, because it can cause values of cinder_volume such as "d52-54-77-77-77-03.ve1.cloud.suse.de\nd52-54-77-77-77-04.ve1.cloud.suse.de", i.e. multiple hostnames delimited by "\n" rather than comma-separated like is correctly done with the other barclamps above.
So instead we assign to an array breaking on whitespace, so that the first host is correctly picked.
Here's an example failure:
W, [2016-09-08T20:36:56.103076 #8898:0x00000005f37410]  WARN -- Could not recover Chef Crowbar Node on load d52-54-77-77-77-03.ve1.cloud.suse.de
d52-54-77-77-77-04.ve1.cloud.suse.de: #<URI::InvalidURIError: bad URI(is not URI?): http://localhost:4000/nodes/d52-54-77-77-77-03.ve1.cloud.suse.de
d52-54-77-77-77-04.ve1.cloud.suse.de>
I, [2016-09-08T20:36:56.103681 #8898:0x00000005f37410]  INFO -- Completed 500 Internal Server Error in 85ms (ActiveRecord: 8.0ms)
F, [2016-09-08T20:36:56.104726 #8898:0x00000005f37410] FATAL --
NoMethodError (undefined method `[]' for nil:NilClass):
  app/models/service_object.rb:744:in `block (2 levels) in violates_exclude_platform_constraint?'
  app/models/service_object.rb:743:in `each'
  app/models/service_object.rb:743:in `any?'
  app/models/service_object.rb:743:in `block in violates_exclude_platform_constraint?'
  app/models/service_object.rb:739:in `each'
  app/models/service_object.rb:739:in `violates_exclude_platform_constraint?'
  app/models/service_object.rb:805:in `block in validate_proposal_constraints'
  app/models/service_object.rb:778:in `each'
  app/models/service_object.rb:778:in `validate_proposal_constraints'
  app/models/service_object.rb:669:in `validate_proposal_after_save'
  app/models/cinder_service.rb:204:in `validate_proposal_after_save'
  app/models/service_object.rb:547:in `save_proposal!'
  app/models/service_object.rb:871:in `_proposal_update'
  app/models/service_object.rb:526:in `proposal_edit'
  app/controllers/barclamp_controller.rb:563:in `proposal_update'

The problem occurs in this line in
ServiceObject#violates_exclude_platform_constraint?:
    node = NodeObject.find_node_by_name(element)

Chef::Node.load raises the URI::InvalidURIError exception which gets caught, turned into a warning, and then nil is returned for the node, causing the NoMethodError soon after.

 (8) S47P1: Permanent Jenkins Triage

+1

Could this be the reson for this mkcloud failure? https://ci.suse.de/job/openstack-mkcloud/33567/console

@rsalevsky Yes, I think so, good catch!

@rsalevsky It's definitely the reason for that failure.

+1

+1

Maintenance qa is affected by this, I am unable to deploy a ha cloud with GM5+up and GM6+up

Someone (maybe me) needs to verify that this really does the right thing before merging.

Without this fix ha deployment for GM5+up and GM6+up always fails with:
qa_crowbarsetup.sh: line 3032: [: too many arguments
Failed to talk to service proposal edit: 500: {"status":"500","error":"Internal Server Error"}
Error: 'crowbar cinder proposal --file=/root/cinder.default.proposal edit default' failed with exit code: 1
With the fix mkcloud run completes successfully including tempest smoke test run. Side effect is exposing other small problems like:
Starting proposal nova(default) at: Tue Sep 13 10:12:43 UTC 2016
qa_crowbarsetup.sh: line 2866: [: too many arguments
Starting proposal ceilometer(default) at: Tue Sep 13 10:20:33 UTC 2016
qa_crowbarsetup.sh: line 2923: [: too many arguments

@ellisab Thanks for the useful info! Can you share the logs from an mkcloud run where those problems with nova and ceilometer occur?
The gating check for this PR passed, but it ran without hacloud enabled, so it did not test this change.  I have manually triggered a rebuild with hacloud=1.

I would say
qa_crowbarsetup.sh: line 2866: [: too many arguments

is not a small problem, it's a potentially bad bug.

The logs from @ellisab didn't have debug enabled, so although it very much looks like this PR is working, I can't verify 100%.  However the gating run I triggered is providing the required info.

Gate failed but I think I might have messed up the build parameters.

@aspiers Was there some progress? It really creates blockers for C5 and C6.

@rsalevsky @rhafer The gate appears to be failing because get_unclustered_sles12plus_nodes is returning no nodes.  This function was introduced by #1195 (the same one which created the delimiter-related breakage explained above), but I'm having trouble understanding #1195, so I think it makes more sense to hand this to @rhafer who wrote it :-)

@aspiers Thanks. I am currently trying to come up with a more complete fix for this. (AFAICS the same or similar issues are there for ceilometer and nova).

I've created https://github.com/SUSE-Cloud/automation/pull/1255 which is rather similar to this, but also tries to avoid similar issues for ceilometer and nova.
The

qa_crowbarsetup.sh: line 2866: [: too many arguments

error was btw caused by missing quotation in the if [ -z $something ] tests.

@rsalevsky @rhafer The gate appears to be failing because get_unclustered_sles12plus_nodes is returning no nodes.

It's returning no node because there were no unclustered SLE12-SP2 nodes left in the deployment. It was a 4 node setup using HA and ceph. As ceph currently needs two SP1 nodes there's nothing left to deploy cinder-volume, ceilometer-agent and nova-compute to. So the fix would be to either use at least 5 nodes or deploy with want_ceph=0.

@rhafer Thanks a lot for working on this! I guess we can close this in favour of #1255 then.