Addition of a new optimizer, LION

If you open a GitHub issue, here is our policy:
It must be a bug, a feature request, or a significant problem with the documentation (for small docs fixes please send a PR instead).
The form below must be filled out.
Here's why we have that policy:.
Keras developers respond to issues. We want to focus on work that benefits the whole community, e.g., fixing bugs and adding features. Support only helps individuals. GitHub also notifies thousands of people when issues are filed. We want them to see you communicating an interesting problem, rather than being redirected to Stack Overflow.
System information.
TensorFlow version (you are using): tf-nightly
Are you willing to contribute it (Yes/No) : Yes
Describe the feature and the current behavior/state.
Google released a new optimizer, LION which is purportedly better than Adam and Adafactor, and is more memory-efficient too.
Will this change the current api? How?
Will a new optimizer essentially tf.keras.optimizers.Lion.
Who will benefit from this feature?
Everyone who uses Keras and is updated with recent developments in the field.

Do you want to contribute a PR? (yes/no): Yes

Src code is released https://github.com/google/automl/tree/master/lion

@xiangning-chen @crazydonkey200 wanted to see if your team would be interested in the implementation of this?

Sure. We will take a look. Since we have shared the TF2 and TF1 implementation in the open source repo, it is also good if other people would like to contribute the implementation and we can help review it.

Since Lion is already in the codebase, is it possible to also add it to the Keras API doc? Currently I don't see it here. @nkovela1 Thank you!

@old-school-kid , Could you please close this issue since the LION optimizer is implemented and merged here https://github.com/keras-team/keras/pull/17605/files. Thanks!


Adding the changes in <IP_ADDRESS> AD FS CH agent

@zhvolosh  Please review the changes.

@kavya-kk : Thanks for your contribution! The author(s) have been notified to review your proposed change. @zhiweiwangmsft

#sign-off

Hi @kavya-kk - Numbered lists should be used only to list sequential steps. This is criteria that blocks merging in the private repository. I've applied the criteria to the new content in the article. Also, Microsoft-internal contributors should use a GitHub account that is linked to their Microsoft account. The steps for linking your accounts are described in the Microsoft-internal contributor guide. Thanks. Merging now with approval from @billmath.

@kavya-kk - Could you sign the Contributor License Agreement (CLA)? Then, we can merge the pull request. Thanks.

@ktoliver  Yes it is good to merge.  Thank you!

Thanks @billmath. We need the CLA signed, then we'll merge.

@kavya-kk Could you sign the Contributor License Agreement (CLA)? Then, we can merge the pull request. Thanks.

@kavya-kk Could you sign the Contributor License Agreement (CLA)? Then, we can merge the pull request. Thanks.

I see the March 2021 summary in the article in master in the private repo, so we'll close this pull request.


Update main.tf

Ran Plan for dir: . workspace: default
Terraform used the selected providers to generate the following execution
plan. Resource actions are indicated with the following symbols:
+ create

Terraform will perform the following actions:

  # null_resource.example will be created
+ resource "null_resource" "example" {
      + id = (known after apply)
    }

Plan: 1 to add, 0 to change, 0 to destroy.

:arrow_forward: To apply this plan, comment:atlantis apply -d .

:put_litter_in_its_place: To delete this plan and lock, click here
:repeat: To plan this project again, comment:atlantis plan -d .

:fast_forward: To apply all unapplied plans from this Pull Request, comment:atlantis apply

:put_litter_in_its_place: To delete all plans and locks from this Pull Request, comment:atlantis unlock

atlantis apply

Ran Apply for dir: . workspace: default
null_resource.example: Creating...
null_resource.example: Provisioning with 'local-exec'...
null_resource.example (local-exec): Executing: ["/bin/sh" "-c" "echo 'Hello, Terraform!'"]
null_resource.example (local-exec): Hello, Terraform!
null_resource.example: Creation complete after 0s [id=8312665845468357274]

Apply complete! Resources: 1 added, 0 changed, 0 destroyed.

Locks and plans deleted for the projects and workspaces modified in this pull request:

dir: . workspace: default


docker images tree view

When i do docker images all images are listed but i think it would be quite useful to see which images are built on which, for example in a tree structure. For example to see which sizes are included in other images.

Dup of #17366


Propose name/location for non-interpolating string type

Proposal: Microsoft.EntityFrameworkCore.RawSqlString
The type...

Is not nested and can be shared between FromSql() and ExecuteSqlCommand()
Conveys an appropriate meaning when it shows up freely in Intellisense under the EFCore namespace
Helps differentiate from the overload that takes FormattableString  when it shows up in Intellisense.
Aligns with the way we currently explain/document both overloads, e.g. for FromSql():

FormattableString overload -> Creates a LINQ query based on an interpolated string SQL query.
RawSqlString overload -> Creates a LINQ query based on a raw SQL query.

@ajcvickers, I talked to @anpete and he won't push back on this proposal. Let me know if you think we should still discuss it in person before he makes the change.

:shipit:

Poaching since @anpete is out today.


Create a cookie cutter for creating scivision model repos

[ ] Create (or modify existing) test data repo under turing github account
[ ] model repo
[ ] Add these repos as submodules within the scivision package (this will allow pinning a particular commit)
[ ] Add documentation that references these examples. Perhaps just in a README for now, can be moved to more comprehensive docs later.

or readthedocs - see #53

This might be a very relevant tasks according to the experience of the Plankton DSG.

We should definitely have a cookiecutter! However, I'm hesitant to do this too early, as we're still working out what the interface needs to look like.

One thing the template should specify is that the predict function should include pre-processing


x/pkgsite: cs.opensource.google does not offer ZIP download

What is the URL of the page with the issue?
https://pkg.go.dev/golang.org/x/tools
What is your user agent?
Mozilla Firefox
What did you do?
if you visit the page, you are presented with this URL:
https://cs.opensource.google/go/x/tools
What did you expect to see?
A link to download ZIP or TAR.GZ
What did you see instead?
for the life of me, I cannot see a method to actually download the repository source code. With GitHub, its very easy. You go here:
https://github.com/golang/tools
click Code, Download ZIP, and you get this:
https://github.com/golang/tools/archive/refs/heads/master.zip
does the opensource.google site really not have a way to download the source code? I think opensource.google should have a method to do this (if it doesnt already) or the documentation should point to GitHub instead.

The site is linked for code searching, the source repositories are the ones from go.googlesource.com
Closing as working as intended.


[Docker] Nothing happens after inserting disk

Description
The server I set this up on has 2 disk drives, I have confirmed they show up as sr0 and sr1. When I insert a disk, nothing happens. The webapp works fine and I can properly edit the settings.
When I run tail -f /var/log/syslog | grep ARM I get:
Apr 21 00:43:25 arm ARM: Entering docker wrapper
Apr 21 00:43:25 arm ARM: No ID_s
Apr 21 00:43:25 arm ARM: xxx
Apr 21 00:43:45 arm ARM: Entering docker wrapper
Apr 21 00:43:45 arm ARM: /opt/arm/scripts/docker_arm_wrapper.sh xxx1 sr0
Apr 21 00:43:45 arm ARM: xxx3
Apr 21 00:43:45 arm ARM: fixing devname

Nothing at all happens when I open or insert a disk in drive 2 (sr1)
Nothing happens after it reaches "fixing devname". Per the wiki (which seems to have either a typo or a missing section when it talks about udev), I have updated and restarted udev. Then I rebooted, same thing.
I have setup the drives in the fstab:
/dev/sr0 /mnt/dev/sr0 udf,iso9660 users,noauto,exec,utf8 0 0
/dev/sr1 /mnt/dev/sr1 udf,iso9660 users,noauto,exec,utf8 0 0

And accounted for both devices in the docker command:
docker run -d \
   -p "8080:8080" \
   -e UID="1000" -e GID="1000" \
   -v "/home/arm:/home/arm" \
   -v "/mnt/media/ARM/Music:/home/arm/Music" \
   -v "/home/arm/config:/home/arm/config" \
   -v "/mnt/media/ARM/logs:/home/arm/logs" \
   -v "/mnt/media/ARM:/home/arm/media" \
   --device="/dev/sr0:/dev/sr0" \
   --device="/dev/sr1:/dev/sr1" \
   --privileged \
   --restart "always" \
   --name "arm-rippers" \
   1337server/automatic-ripping-machine:latest

My nfs share is properly mounting to /mnt/media, so I do not believe it is the cause of the problem.
Environment
Ubuntu 20.04.2 LTS, running in VMWare ESXi 6.7
Log file
None. Also, here is no documentation on how to manually rip when using the Docker setup.

what's the output of lsscsi -g ?

Output:
[2:0:0:0]    cd/dvd NECVMWar VMware SATA CD00 1.00   /dev/sr0   /dev/sg0
[3:0:0:0]    cd/dvd NECVMWar VMware SATA CD00 1.00   /dev/sr1   /dev/sg1
[32:0:0:0]  disk      VMware      Virtual disk                2.0    /dev/sda   /dev/sg2

Really odd behaviour, does the arm user have access to the cdrom group ?
The original error message means it can't find the device /dev/srx so it assumes that it was given srx and tries to add /dev
The only thing i think it could be is a permission issue.

I only created one user (arm) when I installed the OS. I have confirmed that arm is the only member of cdrom using
getent group cdrom
Why is it looking for srx and not sr0 or sr1? That first error always happens only when I open the dvd tray, so I believe that's normal behaviour. The comments in the udev rule seem to support that
Do I copy that command exactly, or is there a way to get the DVD label?

It does look for sr0 and sr1. I meant that the x in srx would be replaced with an int for each drive you have. So if the udev triggers for sr0 it will look for sr0, etc.
You can get the label from udev, you can see how arm should be getting this info from here .
https://github.com/1337-server/automatic-ripping-machine/blob/3d7db077f1eec5d8ace1134e50398d62c81d911a/scripts/docker_arm_wrapper.sh#L103
You will also need the previous lines most likely from lines 98-106
But this isn't recommended as its not fixing what ever issue you're currently having. And as this happens with both the docker and the main ARM installs this might be your own setup. I'm not familiar with ESXi 6.7, so i can't really be of much help when trying to debug your setup.
Let me know if you need any more info

I think I figured out where the script is breaking.
https://github.com/1337-server/automatic-ripping-machine/blob/3d7db077f1eec5d8ace1134e50398d62c81d911a/scripts/docker_arm_wrapper.sh#L128
If I add echo $container_status | logger -t ARM -s to line 129, it doesn't print anything. Line 128 does not appear to run, or store a value.

I think I figured out where the script is breaking.
https://github.com/1337-server/automatic-ripping-machine/blob/3d7db077f1eec5d8ace1134e50398d62c81d911a/scripts/docker_arm_wrapper.sh#L128
If I add echo $container_status | logger -t ARM -s to line 129, it doesn't print anything. Line 128 does not appear to run, or store a value. Is it failing silently?

Is it possible your arm user doesn't have access to the docker group ? That may cause issues, but i'm not sure.

Huh. Weird. Despite this install (Ubuntu Server 20.04) having been installed with the docker snap, I get usermod: group 'docker' does not exist when I run sudo usermod -a -G docker arm. Will look into this.

Found an answer here, looks like docker installation via snap is not creating a docker user group

Group created and user added. Same thing happens. The script is 777.
I have determined without a doubt that the command:
docker container ls -l -f name="${CONTAINER_NAME}" --format '{{json .Status}}' is either not being run by the script, or returning nothing. This behavior only occurs when these commands are run by the script. Running from the command line successfully returns the status info of the "arm-rippers" container. I have also confirmed that the CONTAINER_NAME is properly set and properly populating within the script.
Code:
echo "aaa1" | logger -t ARM -s
echo "$(docker container ls -l -f name="${CONTAINER_NAME}" --format '{{json .Status}}')" | logger -t ARM -s
echo "aaa2" | logger -t ARM -s
container_status="$(docker container ls -l -f name="${CONTAINER_NAME}" --format '{{json .Status}}')" | logger -t ARM -s
echo $container_status | logger -t ARM -s
echo "aaa3" | logger -t ARM -s

output:
aaa1
aaa2

You could depending on your use case, remove the check for the container running at all.
If you're running the container all the time you can safely remove the check
# start ARM container, if not running, for WebUI
container_status="$(docker container ls -l -f name="${CONTAINER_NAME}" --format '{{json .Status}}')"
case "${container_status//\"}" in
  Up*)
    echo "container '${CONTAINER_NAME}' status: ${container_status}" | logger -t ARM
    ;;
  Exited*)
    startArmContainer
    ;;
  *)
    runArmContainer
    ;;
esac

And then the script will assume the container is always up and running. This leave a huge chunk of unused code, but that shouldn't cause any issues.
If the container isn't running all the time, and you want the script to start or create the container you will need to dig deeper into this.  docker container ls -l -f name="${CONTAINER_NAME}" --format '{{json .Status}}') needs to be working for creating or starting stopped containers.

That works, but then it breaks on the next docker command in startArmRip. Only the docker commands are breaking

If even docker exec isn't working then you probably have a permission issue with docker.
Do the docker exec commands work when you trigger them from a terminal ?

Docker operates as expected when being used from the terminal. could it be an issue with whatever "user" process the udev rule calls the wrapper script from?

Thats what i was thinking, but ill be honest and say I'm not that experienced with docker or ESXi so i didnt want to point you in the wrong direction.
But my first thought that what ever user you have triggering the docker_wrapper doesn't have access to the docker group ? Maybe echo the current user when it runs and then check the groups of that user ?

I totally get that. ESXi is a hypervisor and completely invisible to the OS, so unless Ubuntu wasn't mounting the drives, ESXi isn't a factor. Docker itself isn't broken so at this point it has to be either A) a permissions issue buried in here somewhere, or B) an issue caused by Ubuntu Server 20.04 not coming with something that Ubuntu Desktop 20.04 normally does.
I'm gonna try that next. Once I get this working I'm writing up a tutorial so no one has to deal with figuring all this out again.

 Apparently snap sets up services under itself, rather than under systemd, so a snap-installed docker doesn't appear when running sudo systemctl status docker. Uninstalling the snap and installing docker via the website fixed the problem.
To be clear: DO NOT INSTALL DOCKER VIA SNAP
I'm going to try and script this out, then see if it's working with both drives.

Got a preliminary script done, and it's working. The bigger problem for me is that the docker version does not see the second drive, only the first. It looks like the udev rule is not firing for drive 2 at all.

Did you do sudo mkdir -p /mnt/dev/sr1 and a second fstab entry for it ?

Okay, I physically swapped the drives in the case. Now that it's done, the udev rule fires when I put a disk in sr1, and doesn't fire for sr0. This appears to be a hardware driver issue with my LG WH16NS60 dvd drive.
I'll try a physical repair, but at this point I'd say that this is confirmed working for multiple drives. Which pisses me off because this is the exact drive the original blog post suggests, and that's why I got it.
I'll work on a tutorial for this once I deal with that.

If you're trying to get UHD you may need to follow the firmware flashing guide provided by MakeMKV here
The drive you have requires you to flash the firmware to unlock UHD ripping and even 4 years later (from the original blog post) its still one of the top recommended drives for ARM/MakeMKV

Nope, I was testing that drive with a copy of Snatch (2000). Definitely not a UHD issue
Hmm. sr1 is trying to run, but seems to hang or crash after logging disk is a dvd. It doesn't throw an error in get_cdrom_status, so I don't think it's breaking until at least here:
https://github.com/1337-server/automatic-ripping-machine/blob/3d7db077f1eec5d8ace1134e50398d62c81d911a/arm/ripper/main.py#L493
I've confirmed this happening with multiple dvds

Are there any error if you run the docker exec manually ?

Not sure what you mean by that. Calling the wrapper script outside the rule always returns the NO_ID outcome, regardless of whether or not it's mounted

Hold on. I might be looking at the the wrong branch. The docker container is built from the docker branch, right?

Yes the pre-built docker image is automatically built from the docker branch. It builds a fresh image every time the docker branch receives a new push/commit.

Okay, I was reading through the default branch. How do I start it manually for the docker?

 docker exec -i \
-u "1000" \
"arm-rippers" \
python3 /opt/arm/arm/ripper/main.py \
  -d /dev/sr0 -t ID_CDROM_MEDIA_DVD=1 -l ID_FS_LABEL=MY_DVD_LABEL \
| logger -t ARM

This will trigger a rip inside the docker.

Ah. It was a permissions error. Need to make a note to run chmod -R 775 /home/arm after the setup creates all of the folders. Or else the app won't have write permissions.
Another good idea would be to redirect python's STDERR to the logger, so that we can see an errors via tail -f /var/sys/syslog | grep ARM, rather than having to run it manually. Should be an easy addition in the logger setup.

Is there a discord or irc where people chat about this in real-time?

Glad you got it sorted! Ill look into pushing out errors to the host system.
As for discord/irc - Not currently, I did think about creating a discord for ARM but I'm not part of the ARM org or group so i didn't think it was appropriate for me to create one, and i didn't want to step on anyone's toes.

I don't think you need to push errors in the container out. All you should need to do is tell python to write stderr to logger.error. This may help.
Okay, I made a channel in my server to chat about this outside of endless issue threads. Add me on discord "wolfy#4577", and I'll send you an invite. It doesn't have to be official or anything, but the original repo is pretty dead in terms of actual development and we need a way to communicate.

Ill look into that, and Ill add on discord later today.

Issue seems to be resolved. Ill close this but ping if it needs re-opened


move: enable Move.lock files

Description
Enables Move.lock file generation by setting the lock_file path in BuildConfig along these 3 code components:

all sui move commands
sui client publish
sui client verify-source

Part of https://github.com/MystenLabs/sui/issues/8342
Test Plan
Added a test to check lock file generation for framework build (see inline comment).
Type of Change (Check all that apply)

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

Release notes

[ ] TBD

We should start generating lock files for Move Stdlib and Sui Framework following this change, for indexing purposes.

Can do in a follow up (and wait to merge it if we want this to follow this PR quickly). Thoughts on doing this also for other Move package test fixtures in our repo (like source-verifier or integration tests)?
In the mean time, putting this up for review again now that the test <ahem> works :-)


Create SIP-CI.yml

I have created SIP-CI.yml. Please let me know if you think this is a problem.

I have found a problem. I'm going to close this pull request and start a new one after I fix it.


feat: implement flattened contract verification [APE-1187]

What I did
Implement verification using flattened contract source for non-ethereum ecosystems
fixes: #94
fixes: APE-1089
How I did it
Check for ethereum ecosystem, and otherwise use single-file input format and flattened source.
Also fixed constructor argument parsing.
How to verify it
Deploy contract to testnet with publish=True. I checked contracts with:

no constructor arguments https://mumbai.polygonscan.com/address/0x49959a9af0e54426af8e50e464d303f576692034#code
a single uint256 constructor argument, https://mumbai.polygonscan.com/address/0xf70c5693fb5e86ecfd8c77a23b08a8f11c790c69#code
a uint256 and a string argument, https://mumbai.polygonscan.com/address/0x57b4705460c6ea1994c1d049f85e1395ca3aeabd#code
a uint256 and two string arguments https://mumbai.polygonscan.com/address/0xa97ea1adb8374da5229df49a7a540fbd8db0d2fc#code

Checklist

[ ] Passes all linting checks (pre-commit and CI jobs)
[ ] New test cases have been added and are passing
[ ] Documentation has been updated
[ ] PR title follows Conventional Commit standard (will be automatically included in the changelog)

etherscan link: https://mumbai.polygonscan.com/address/0x130878f92353599955dfa5FFdb999ACF7E10005e#code


Compilation of functors

This PR implements the compilation of functors, through defunctorization. Most notably, functor application is always generative, so not a lot of constructions are supported, but this should be enough for {Set,Map}.Make.

functor application is always generative, so not a lot of constructions are supported

For me applicative vs. generative is mostly a question of whether (generative) datatype definitions are distinct or compatible in two applications. Is there a difference here? My understanding would be that, as we are only using datatypes for representation and not for type-checking, two instances of the same datatype will in fact be interchangeable in the compiled program, so in this sense we are not non-applicative. What kind of incompatibilities do you have in mind?

I've changed the code to add 'MEFunctor, and the result is indeed quite a bit simpler, thanks!
Concerning applicative vs. generative, it is the same concerning datatypes, yes. The incompatibilities I have in mind would happen in the case of a functor like module X(A : sig val x : int end) = struct let r = ref 0 end for instance, where instantiating the functor has side-effects.

I'm not sure which differents you have in mind; I think that dynamically uses of F(A) that are not within types/signatures do result in evaluation in OCaml, even when F is applicative, so they should be the same as in your proposal.

I don't mind merging myself, but would be very happy if you did :). I agree about checking the effects of the argument are not duplicated should be done.

Then I'll wait for the testsuite update (I guess?) and merge.

Done!

Thanks, merged.


Recipe Logbook

Added a base for recipe logbook (modify if needed)
What's missing:
Still does not check if recipe is already in logbook, so it will be duplicated (not tested, but theoretically, it will)

might need designing lmao, its just barebones


Support for light theme

Hello @aslbarnett .
Lovely theme.
Will there be a light theme edition as seen on the vscode implementation?

Hi @bonge-ian, thanks! Yes, there will be - it's currently in progress 😊


Add HackNotts 2020

Add HackNotts 2020

Guess this pretty clearly decides when DurHack’s gonna be then 😛 @ksouthern
Approved

Guess this pretty clearly decides when DurHack’s gonna be then 😛 @ksouthern

I'm thinking the 28th and 29th November 2020 😉


Cmdlet not available

Get-AcceptedDomain cmdlet not available - fyi

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

ID: 39fbe5a2-c138-b566-c094-82ffc3d1b734
Version Independent ID: 4d69ee5d-5a6d-a203-69fe-bf5441a8b5eb
Content: Connect to Exchange Online PowerShell
Content Source: exchange/docs-conceptual/connect-to-exchange-online-powershell.md
Service: exchange-powershell
GitHub Login: @chrisda
Microsoft Alias: chrisda

@JXG2300, it's available to me in my plain Microsoft 365 E5 organization. If it's not visible to you, it could be an RBAC issue.
When I run the following commands:
$Perms = Get-ManagementRole -Cmdlet Get-AcceptedDomain

$Perms | foreach {Get-ManagementRoleAssignment -Role $_.Name -Delegating $false | Format-Table -Auto Role,RoleAssigneeType,RoleAssigneeName}

I get the following output (obviously custom role groups removed):
Role                RoleAssigneeType RoleAssigneeName
----                ---------------- ----------------
Distribution Groups RoleGroup        Organization Management
Distribution Groups RoleGroup        Recipient Management

Role                  RoleAssigneeType       RoleAssigneeName
----                  ----------------       ----------------
O365SupportViewConfig PartnerLinkedRoleGroup O365 Support View Only

Role                 RoleAssigneeType RoleAssigneeName
----                 ---------------- ----------------
Retention Management RoleGroup        Records Management
Retention Management RoleGroup        Compliance Management
Retention Management RoleGroup        Organization Management

Role                RoleAssigneeType RoleAssigneeName
----                ---------------- ----------------
Distribution Groups RoleGroup        Organization Management
Distribution Groups RoleGroup        Recipient Management

Role                  RoleAssigneeType       RoleAssigneeName
----                  ----------------       ----------------
O365SupportViewConfig PartnerLinkedRoleGroup O365 Support View Only

Role                 RoleAssigneeType RoleAssigneeName
----                 ---------------- ----------------
Retention Management RoleGroup        Records Management
Retention Management RoleGroup        Compliance Management
Retention Management RoleGroup        Organization Management

Role                 RoleAssigneeType     RoleAssigneeName
----                 ----------------     ----------------
MyDistributionGroups RoleAssignmentPolicy Default Role Assignment Policy

Role            RoleAssigneeType RoleAssigneeName
----            ---------------- ----------------
Mail Recipients RoleGroup        Recipient Management
Mail Recipients RoleGroup        Organization Management
Mail Recipients RoleGroup        Custom Mail Recipients
Mail Recipients RoleGroup        Test Mail Recipients Only role

Role                    RoleAssigneeType RoleAssigneeName
----                    ---------------- ----------------
View-Only Configuration RoleGroup        Hygiene Management
View-Only Configuration RoleGroup        Organization Management
View-Only Configuration RoleGroup        Compliance Management
View-Only Configuration RoleGroup        View-Only Organization Management

Role                        RoleAssigneeType RoleAssigneeName
----                        ---------------- ----------------
Remote and Accepted Domains RoleGroup        Organization Management

Role                        RoleAssigneeType RoleAssigneeName

MyDistributionGroups RoleAssignmentPolicy Default Role Assignment Policy
Role            RoleAssigneeType RoleAssigneeName

Mail Recipients RoleGroup        Recipient Management
Mail Recipients RoleGroup        Organization Management
Mail Recipients RoleGroup        Custom Mail Recipients
Mail Recipients RoleGroup        Test Mail Recipients Only role
Role                    RoleAssigneeType RoleAssigneeName

View-Only Configuration RoleGroup        Hygiene Management
View-Only Configuration RoleGroup        Organization Management
View-Only Configuration RoleGroup        Compliance Management
View-Only Configuration RoleGroup        View-Only Organization Management
Role                        RoleAssigneeType RoleAssigneeName

Remote and Accepted Domains RoleGroup        Organization Management

Do you see something similar when you run those commands?

@JXG2300 Hope this comment is helpful for you. If you see a documentation update is required, please feel free to open an issue for the same. We proceed here to close it. Thanks for taking out some time to open the issue. Appreciate and encourage you to do the same in future also.


Field level permissions

Is there a recommended approach for field-level permissions?

Unfortunately, there isn't a generic field level solution at the moment. I had an idea of how I want to get it done, but haven't had the time to implement and there hasn't been a ton of demand for it yet.

Understood. +1 for this from me. 😀
Also if you want to send me your thoughts on an approach I might run with it for while...
On May 18, 2016, 13:51 -0700, David<EMAIL_ADDRESS>wrote:

Unfortunately, there isn't a generic field level solution at the moment. I had an idea of how I want to get it done, but haven't had the time to implement and there hasn't been a ton of demand for it yet.
—
You are receiving this because you authored the thread.
Reply to this email directly orview it on GitHub(https://github.com/dbkaplan/dry-rest-permissions/issues/22#issuecomment-220154111)

It might be helpful to list what the use-cases are for this, as this is a little less clear on how to handle generically.  For instance, here are some possible desired workflows:

Request a record without permission for x, return the record, x is null (or missing). HTTP 200

Request a record without permission for x, return the record, but x is set to some other default or dynamic value to be returned instead. HTTP 200

Request a record without permission for x, HTTP 200 but with custom error

Request a record without permissions for x, HTTP 403 (can't think of a concrete example of when you'd want this, but it's possible)

Update a record, attempting to set x, HTTP 403

Update a record, attempting to set x, updates all except x, HTTP 200

I don't know, those are off the top of my head.  I can see use-cases for all of them, so whatever this solution is would probably need some additional coding/configuration by the developer to handle these, it might not be as easy to handle completely generically.
@dbkaplan feel free to correct me, but knowing @dbinetti 's use case could help getd a head start.

Concretely:

Say you have a contest including a number of competitors. The competitors are scored, privately, by a panel of judges. Those scores need to be persisted to each Competitor model and used for all sorts of other processing (ranking, for instance). These private data should be accessible to the judges, or admins, or other authorized users, but not to the public at large. However, we do want to have the Competitor name and other details made available.

Now I could create other models (and have, frankly) to handle this. However, it would be useful to have a field like rank which is permissions-enabled to allow the use case I described above.
I might be running afoul of REST here, since the use case is more on the serializer (rank= INT for authorized, rank=None for unauthorized) but anyway that's the use case....
On May 19, 2016, 09:00 -0700, Jon<EMAIL_ADDRESS>wrote:

It might be helpful to list what the use-cases are for this, as this is a little less clear on how to handle generically. For instance, here are some possible desired workflows:
Request a record without permission forx, return the record,xis null (or missing).HTTP 200
Request a record without permission forx, return the record, butxis set to some other default or dynamic value to be returned instead.HTTP 200
Request a record without permission forx,HTTP 200but with custom error
Request a record without permissions forx,HTTP 403(can't think of a concrete example of when you'd want this, but it's possible)
Update a record, attempting to setx,HTTP 403
Update a record, attempting to setx, updates all exceptx,HTTP 200
I don't know, those are off the top of my head. I can see use-cases for all of them, so whatever this solution is would probably need some additional coding/configuration by the developer to handle these, it might not be as easy to handle completely generically.
@dbkaplan(https://github.com/dbkaplan)feel free to correct me, but knowing@dbinetti(https://github.com/dbinetti)'s use case could help getd a head start.
—
You are receiving this because you were mentioned.
Reply to this email directly orview it on GitHub(https://github.com/dbkaplan/dry-rest-permissions/issues/22#issuecomment-220370760)

I came up with a solution: the fields in question are essentially denormalizations, so I've simply made them into functions which I can protect as actions.  It's a bit more expensive, but it works.

@dbinetti Any chance you could provide some code samples and/or more detail for how you solved this?

as it turns out, making them into functions didn't work; i eventually just created two model serializations: one with public fields, and one with private fields.  i then adjusted permissions accordingly.
this solution (multiple serializations) is probably the best approach even if doesn't seem the DRYest since it keeps the cleanest separation between public/private

@dbinetti Fair enough, what technique are you using in order to use a different serializer depending on permissions? Does this technique work with nested serializers?

I'm not doing any switching, because I am not overlapping the fields. The public model gets the public fields, the private model gets the private fields. The fields are mutually exclusive. I then just check permissions normally. It means that you need to think about your UI in terms of the public and private components.
I have no experience with nested serializers and can't answer that.
On Sep 4, 2016, 05:10 -0700, Jordan Koncz<EMAIL_ADDRESS>wrote:

@dbinetti (https://github.com/dbinetti) Fair enough, what technique are you using in order to use a different serializer depending on permissions? Does this technique work with nested serializers?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub (https://github.com/dbkaplan/dry-rest-permissions/issues/22#issuecomment-244599816), or mute the thread (https://github.com/notifications/unsubscribe-auth/AAJ3uibFEn0Yp6VvRDk2lovrsVpRIhNTks5qmrVQgaJpZM4IhrYj).


Travis fix and more

Now runs only a selected subset of all configurations (all STM32F072), the L073 doesn't compile yet.
Should add it once there is working code.
Added a src_filter to the cloudsolar_03 since L073 does not have CAN.
Maybe there is a better way to do this. Also added libignore for USB
to this environment.
Added memory.map to .gitignore

Hi Martin,
you have  to enable Travis CI for this repository.
Go to https://travis-ci.org/account/repositories and slide the switch for the MPPT-Charger_Software repo to the right (it will become greenish). Next commit or pull request should show it working. You can also somewhere trigger a manual Travis build although I don't rememember exactly how.


Implement clear() and Closeable to Pipeline and Transaction

LGTM!

Marcos merged into master and 2.8, and I merged into 2.7 now.


External CFE message definitions should not depend on values from cfe_platform_cfg.h or osconfig.h

Some structure definitions that define specific ground commands and telemetry messages use array sizes for strings that are either defined in osconfig.h (e.g. OS_MAX_PATH_LEN) or cfe_platform_cfg.h (e.g. CFE_ES_MAX_APPLICATIONS).
However, by definition, these header files contain parameters that are tunable to the specific CPU.  For instance, a resource-constrained CPU may need to reduce CFE_ES_MAX_APPLICATIONS to a small number to save memory.  It is therefore problematic to use these values to define messages that serve as a data definition across processors, particularly in a multi-board setup.
External message definitions must be limited to mission-wide configuration parameters only, such as cfe_mission_cfg.h, where all CPUs as well as the ground system will have the same values.

Imported from trac issue 12.  Created by jphickey on 2014-12-30T21:26:08, last modified: 2019-03-05T14:58:28

Trac comment by jphickey on 2015-05-04 10:11:10:
Will resolve this as part of next change set.
As a related note, {{{cfe_platform_cfg.h}}} should not be available for inclusion by applications.  The values defined within this file are tuning parameters for the CFE core, and should not be used by applications intended to be portable.  This keeps the build simpler, and also allows application binaries to be shared between multiple CPU builds that use the same architecture (i.e. the same binary for application "z" can be loaded onto cpu1 and cpu2 if they both use the same CPU architecture).
Most applications using this header are easily fixed:

Some apps were including it but not using it for anything - so removing it "just works" (probably originally a cut and paste)
The application can be modified to not require the actual value
The value of the parameter can be acquired at run time rather than compile time
The value can become a mission-level compile-time tunable for this application

Trac comment by sduran on 2015-05-15 15:07:13:
Changes look ok for cfe code, but there could be impacts to CFS apps, not to mention existing user apps.  Probably need an apps ticket to assess CFS apps for impacts and update.

Trac comment by jphickey on 2015-05-11 10:00:18:
Pushed commit 2ad6078 for review
EDIT 5/29/15 -- Per feedback - holding off on this commit until a later date. Please see below for updated commit ID for review.

Trac comment by jphickey on 2015-05-18 16:26:27:
Replying to [comment:4 sduran]:

Changes look ok for cfe code, but there could be impacts to CFS apps, not to mention existing user apps.  Probably need an apps ticket to assess CFS apps for impacts and update.

Replying to [comment:5 acudmore]:

I agree with Steve in the comment above. We need to determine the impacts.

Yes - this change is (unfortunately) not transparent to the apps that are currently including platform-specific files.  I have updated all of the CFS applications so they can all be made to work, but there were some minor modifications to do on some of them.

Trac comment by acudmore on 2015-05-18 15:56:38:
I agree with Steve in the comment above. We need to determine the impacts.
I do like the idea of binary compatible apps, and it is a good idea to not define telemetry based on processor specific defines.
We may end up having to split osconfig.h into mission defines for path, file name lengths, and such. The sizes of the OS data structures (such as how many tasks, queues ) could go in a processor config file. We would still have to be careful with the mission wide file system defines, because there still could be a case for different maximum filename lengths on two different processors.

Trac comment by jwilmot on 2015-05-19 10:44:10:
Although I aggree with the rationale, I'm not sure this meets the "ROI" test. The change potentially impact quite a few files and the memory savings is likely small. Maybe add notes in the app developers guide to deprecate app use of cfe_platform_cfg.h?

Trac comment by jphickey on 2015-05-21 15:35:19:
Reworking this change to address some of the issues and feedback

Trac comment by jphickey on 2015-05-29 09:49:22:
This is ready for re-review, as commit [changeset:beea9d3]
The new branch name is "trac-12-separate-api-platform-definitions"
Per feedback - I have pulled out the changes regarding inclusion of {{{cfe_platform_cfg.h}}}.  This can be deferred to a later date, but I would still like to get in the main focus of this trac which is to separate the size definitions within API/Message structures from the platform config.
The new commit focuses specifically on this aspect of separating the message/API binary formats from the platform configuration, but leaves the inclusion paths as-is.  This is an important prerequisite of EDS support but it is relevant/important even if EDS is not used.
DEPENDENCY NOTE: because strings in messages may be a different size than what the local platform/OS defines, this //requires// the fix for #86 to be included as well in order to guarantee things continue to work as expected.  The commit ID listed above is a descendant of the trac #86 fix for this reason.

Trac comment by jphickey on 2015-05-29 09:55:37:
Replying to [comment:7 jwilmot]:

Although I aggree with the rationale, I'm not sure this meets the "ROI" test. The change potentially impact quite a few files and the memory savings is likely small. Maybe add notes in the app developers guide to deprecate app use of cfe_platform_cfg.h?

Additional note - the new commit I just pushed will not affect the ability to include the platform config and therefore does not affect compatibility with existing applications like the previous commit would have.  The new commit accomplishes the main goal of what I needed to do here for EDS support.
I still want to deprecate usage of "cfe_platform_cfg.h" from applications, but this can be deferred to a later build.

Trac comment by jphickey on 2015-07-15 13:54:30:
== REBASED COMMIT ==
This has been rebased to the {{{development}}} branch approved at the 2015-07-14 CCB.
Rebased commit ID: [changeset:b8f8385]
Note that this still depends on #86 -- as of this writing #86 is not yet included in a development merge.

Trac comment by glimes on 2015-07-27 15:00:00:
Approve.

Trac comment by jphickey on 2015-07-27 15:21:35:
Note to reviewers:
Although this does not directly prevent apps from including cfe_platform_cfg.h, this does change the name of certain definitions within that file and as such it does affect compatibility with existing applications.
The name changes are intentional - to give an example, application code might be referencing CFE_ES_MAX_APPLICATIONS.
Depending on the context:

It may be using this macro to interact with the local CFE ES instance.  In general this code should be rewritten to use the public function call API only and not rely on such macros at all.  However in the meantime this could be changed to  CFE_ES_PLATFORM_APPLICATIONS to preserve existing behavior.
It may be using this macro to interpret software bus packets to/from CFE ES. In this case the correct value should be CFE_ES_MSG_MAX_APPLICATIONS

This means that neither definition is "valid" for all use cases.  By //not// preserving the existing name, code that references this value will trigger an error and force some examination to see what context this is being used in so the correct modification can be done.
I have written a corresponding ticket and fix for any issues for all existing cFS applications and those are in the [cfs_apps:] repository.

Trac comment by jphickey on 2015-08-11 13:55:44:
Latest commit: [changeset:11cbd8c]

Trac comment by sstrege on 2015-08-21 18:06:23:
Please identify the ticket numbers in the cfs_apps repository.

Trac comment by sstrege on 2015-08-24 18:06:39:
How is the EDS work affected if this change set is NOT applied?

Trac comment by sstrege on 2015-08-24 18:08:56:
From Joe's email:
It was discussed during the last CCB that the applications would all need some sort of update in order to work with the changes introduced by CFE ticket #43.  Below is a list of tickets that allow all the apps to build using the platform configurations modified as part of CFE ticket #43.
Note - these also fix some other compiler warnings in addition to adapting to the platform config changes.
Also note - not proposing that we necessarily review these in detail at the upcoming CCB, as we probably do not have enough time.  I would rather go through the rest of the tickets on the previous list, possibly deferring #43 again until the 9/8 CCB if necessary until these changes can be reviewed.  The main objective here is to give an idea of the type of fixes that were required to apps in order to correctly build with the modified platform configuration.
#56: Fix MD using CFE_TBL definitions
Branch trac-25-md-sendevent-fix / commit 72d41b7
#57:  Fix HS build errors with strict settings Branch trac-26-fix-hs-build-errors / commit 402591f
#58: Fix HK build with strict settings
Branch trac-27-fix-hk-build-errors / commit 6a940b9
#60: Fix DS verification build error
Branch trac-29-fix-ds-build-error / commit 70e309a
#61: Fix CS build error
Branch trac-30-fix-cs-build-error / commit 4a10d1f
#65: Fix CF build errors
Branch trac-34-fix-cf-build-errors / commit 94f3d50
(#65 contains additional fixes beyond just the platform config related items - may split this up into multiple tickets if necessary)

Trac comment by jphickey on 2015-08-31 11:43:18:
== UPDATED ==
This was discussed at the 2015-08-25 CCB meeting and it was agreed to produce a "reduced" version of this change set that did not change any of the names within cfe_platform_cfg.h.
This is available as commit [changeset:b153c13], branch name trac-12-platform-msg-limits-take2
This cuts the number of affected files from 60 (original commit) to 18.
The remaining changes focus on the following areas:

the cfe_mission_cfg.h now contains mission-scope size definitions telemetry/command objects.
message payload definitions within in the .h files are updated to use the mission-scope definitions.
In places where the messages are sent or received, the code is also adjusted accordingly.  When possible, the sizeof() operator is preferred for this operation so the code does not assume a certain size for the I/O structures.  Additionally, the code is updated to allow different size limits (padding out the I/O structure if it is larger in size than the local platform limit).

Trac comment by glimes on 2015-09-08 10:16:18:
Approve.
I'll need to make sure to get all of the right headers in place in the sample_defs
area in the cfs_test tree when this goes live. This is all worked out correctly now
in the ic-ccb-review branch.

Trac comment by jphickey on 2015-09-08 10:04:48:
Related: Added ticket #142 regarding the naming convention for mission scope vs. platform scope macros.

Trac comment by jphickey on 2015-09-08 12:46:23:
Replying to [comment:21 cdknight]:

A simple example:
cfe_platform_cfg.h:
{{{
...
extern const uint32 CFE_SB_DEFAULT_MSG_LIMIT;
extern const uint32 CFE_SB_BUF_MEMORY_BYTES;
...
extern const char * const CFE_SB_DEFAULT_ROUTING_FILENAME;
...
}}}

Actually this is my preferred method storing tunable configuration items and there is already an existing means to do (essentially) this approach.  To minimize impact on the symbol table, a structure is used (rather than an array) so each element does not need to be the same type.  This is currently instantiated by target_config.c in the CMake build.
The nice thing about this is that it defers resolution of the value to link time (rather than preprocessor) so code is more modular.  It is particularly useful for values that are used by a different module than what defined them, e.g. defined by CFE and used by CFS apps, or defined by PSP and used by CFE, etc.
The biggest issue with this is that it is not possible to declare derived types from them. e.g.
{{{
uint8 MyBuffer[CFE_SB_BUF_MEMORY_BYTES];
}}}
will break.

Trac comment by cdknight on 2015-09-08 12:15:48:
Replying to [comment:1 jphickey]:

...{{{cfe_platform_cfg.h}}} should not be available for inclusion by applications....

The value of the parameter can be acquired at run time rather than compile time

I'd like to retain as much visibility of compile/runtime configuration as possible and require as little re-writing of app code as possible. Global symbols could be used to give everyone access, but will increase the heap size which may be a problem for low-memory environments. Also, adds a memory read to every access. An array could be used to reduce the symbol table impact.
A simple example:
cfe_platform_cfg.h:
{{{
...
extern const uint32 CFE_SB_DEFAULT_MSG_LIMIT;
extern const uint32 CFE_SB_BUF_MEMORY_BYTES;
...
extern const char * const CFE_SB_DEFAULT_ROUTING_FILENAME;
...
}}}
cfe_platform_cfg.c:
{{{
...
const uint32 CFE_SB_DEFAULT_MSG_LIMIT = 4;
const uint32 CFE_SB_BUF_MEMORY_BYTES = 524288;
...
const char * const CFE_SB_DEFAULT_ROUTING_FILENAME = "/ram/cfe_sb_route.dat";
...
}}}

Trac comment by glimes on 2016-11-08 14:17:08:
Current crop of cfe-next are all going into CFE 6.6

Trac comment by jphickey on 2015-10-06 12:33:09:
== UPDATED ==
This ticket was last discussed during the 2015-09-08 CCB meeting, and at that time it was requested that the message-handling changes be further separated from the macro name changes.
Ticket #144 was created to address the message-handling changes, namely removing the explicit references to size macros e.g. OS_MAX_API_NAME where data is copied to/from message buffers and replacing this with sizeof().
The above ticket should be considered a prerequisite to this one, as it allows the message payload to be defined in any way, as long as the string is an array (a requirement for SB payloads), and the runtime code will still work.
Branch trac-12-platform-msg-limits-take2 has been rebased on top of #144 to reflect this.  Commit [changeset:25f11c8] reflects the current proposed update under this ticket, which now consists solely of the macro name changes.

Trac comment by jphickey on 2017-04-27 13:57:46:
== Resurrecting this changeset for CFE 6.6... ==
Fixing this remaining issue will be required before any EDS changes can be brought in.  In addition this causes problems when attempting to build binaries that are not CPU-specific, since commands and telemetry definitions may vary between CPUs
I have pushed a new branch up to babelfish, called trac-12-platform-msg-limits-take3, which is based on today's development branch (2017-04-27).
On this branch there are actually two commits:
[changeset:81c64e0] : rebases the previous 2015-era changeset to the latest development.
[changeset:5099bc5] : fixes up the remaining implicit inclusion of cfe_msgids.h
I kept these as separate commits as they are probably worthy of separate review, and not necessarily tied to one another.

Trac comment by jphickey on 2017-05-16 14:45:04:
Commit [changeset:4dd9d3be] addresses the topics discussed in the 2017-05-16 CCB meeting.

removal of OSAL config includes from message definitions cfe_sb_msg.h.  Also removed osapi.h from cfe_evs_msg.h for the same reason.
removal of CFE_PLATFORM_ES_PERF_MAX_IDS configuration macro and keeping only the mission scope version, to be clear that perf IDS are mission-wide allocations.

The second bullet item required touching several additional files to change references from CFE_PLATFORM_ES_PERF_MAX_IDS to CFE_MISSION_ES_PERF_MAX_IDS

Trac comment by sstrege on 2017-05-16 12:42:52:
Recommend removing the CFE_PLATFORM_ES_PERF_MAX_IDS configuration macro.  Performance IDs should be a mission wide assignment.  Providing a platform configuration for setting the max is misleading.
Other than that I recommend/approve the changesets.

Trac comment by jhageman on 2019-03-05 14:58:28:
Milestone renamed


Overhead on allocations with empty page, again for large buffers

This is related to https://github.com/microsoft/mimalloc/issues/187
Since the commit mentioned in the issue the code has changed, and now the relevant code is on this line.
If I use buffers below MI_MAX_RETIRE_SIZE, which is 4096=4*8*128, performance is good, but as soon as I exceed this size performance drops by 30 times. The workaround of pre-allocating a buffer is not good, because it has to be pre-allocated on every thread, not once.
Also, in my case I use mimalloc as an allocator for a buffer pool in .NET, used for all blittable types to store them off-heap (BTW, I ported full API in .NET here). Since the size of the types could differ a lot, I will need to pre-allocate a thread-static buffer for every type T and every pool bucket size. But there will be overlap of native buffers size in bytes for different buckets of different Ts, e.g. native buffer for byte[4096] is the same as for int[1024]. This already slows down pool implementation and requires lots of unused buffer just as a workaround. If I add some logic to avoid pre-allocating native buffers of the same size the overheads for the hot path might be even more. But, most importantly, this workaround is a hack, not a real solution.
So my questions are:

Could that be fixed for all buffer sizes?
Could I just increase MI_MAX_RETIRE_SIZE in source code e.g. to 1MB and recompile, or something could break somewhere?
Could you expose MI_MAX_RETIRE_SIZE as an environment/CMake option if it's safe to just change its value? Now it's defined here without any checks if it is already defined.

Settings I use for benchmarking:
Mem.OptionSetEnabled(Mem.Option.EagerCommit, true);
Mem.OptionSetEnabled(Mem.Option.LargeOsPages, true);
Mem.OptionSetEnabled(Mem.Option.ResetDecommits, true);
Mem.OptionSetEnabled(Mem.Option.PageReset, true);
Mem.OptionSetEnabled(Mem.Option.SegmentReset, true); // without it memory usage increases up to OOM
Mem.OptionSetEnabled(Mem.Option.AbandonedPageReset, true);
Mem.OptionSetEnabled(Mem.Option.EagerRegionCommit, false);
Mem.OptionSetEnabled(Mem.Option.ReserveHugeOsPages, true);

Mimalloc version 1.6.1.

Ah I see -- this is a thorny problem; generally the goal for mimalloc is to have property to not have edge cases that make it perform much worse suddenly. There are few remaining cases where it does not hold, and this is one of them :-(
It is tricky though: keep a free page around and it can be more performant if it happens to be reused "soon"; or free it right away to allow the memory to be reused by other size-classes or threads?
Best seems to be if all pages are retained for a while (based on allocation rate), and only then freed. Currently it is still a bit too conservative with the MAX_RETIRE_SIZE; maybe it can be done better; let me ponder on it for a bit and get back to you.

Hi @buybackoff , I just pushed a fix (I think) to the dev branch. Let me know how it works for you. Basically using retirement now for all object sizes and keeping a min/max to reduce average scan times.


PyTTa licensing

Right now it is registered within setup.py file that PyTTa is distributed under the MIT license, but still there is no LICENSE file at the repository.
Which license should be used?
The main choices are GPLv3, that ensures all software based on PyTTa must also be distributed under GPLv3, or MIT which is a full permissive license and requires only that the PyTTa package is redistributed under the same license.
In my opinion we can go with MIT.

agree


Cannot create a project

Problem encountered on https://dotnet.microsoft.com/learn/dotnet/hello-world-tutorial/install
Operating System: android(ubuntu environment)
When I tried to create a project this was occurred

I have tried to running other softwares on my android device, Rust, Go and C++ work well on the ubuntu environment, so it might be not something wrong with the environment.
Besides, I think my storage is large enough, which has at least 10GB free.
This is the information

So is there a way to resolve it? Thanks. :)

@leecow @KathleenDollard @timheuer have you seen this issue before? Also, have we tested this scenario before of running dotnet on Ubuntu on an Android device? I don't know if this is a supported scenario or not.

That's an interesting configuration :-) -- the error seems to be about disk space though.  This should be in the @dotnet/sdk path IMO.


fix: display status bar in correct order

This reverts the recent change of the group names which caused the issue in the linked comment.
Related to https://github.com/camunda/camunda-modeler/commit/b79fe1dec26fac603980b2639a46dc8656661dcd#r149356417
Proposed Changes
Use group name starting with Z for the nudge, and old group names for other buttons.

Checklist
To ensure you provided everything we need to look at your PR:

[x] Brief textual description of the changes present
[x] Visual demo attached
[ ] Steps to try out present, i.e. using the @bpmn-io/sr tool
[x] Related issue linked via Closes {LINK_TO_ISSUE} or Related to {LINK_TO_ISSUE}

We will do develop as the changes will be merged tomorrow.


spring容器关闭时，quartz未正常关闭

spring容器关闭时，没有处理quartz的正常关闭，导致项目无法正常关闭，日志如下：
[DEFAULT.simpleJob_Scheduler_QuartzSchedulerThread] but has failed to stop it. This is very likely to create a memory leak.

duplucate with #113

可以认领此任务？

欢迎认领，直接提交pull request即可


Missing DispatcherScheduler for Net Core App 3 (WPF.Core)

Please include System.Reactive.Concurrency.DispatcherScheduler.Current for these kind of projects.
<Project Sdk="Microsoft.NET.Sdk.WindowsDesktop">
  <PropertyGroup>
    <TargetFrameworks>net472;netcoreapp3.0</TargetFrameworks>
    <UseWPF>true</UseWPF>
  </PropertyGroup>
</Project>

Or is there another way to achieve scheduling on this platform specific Dispatcher?

I was using v 4.1.5. It seems that version 4.2 already supports this


[MediaTile] docs - add an example for a single MediaTile

[MediaTile] docs - add an example for a single MediaTile
Originally posted by @QuintonJason in https://github.com/Kajabi/sage-lib/issues/691#issuecomment-896039289

@QuintonJason for clarification on this are you looking for an example of MediaTile on its own rather than inside of SageMediaTiles loop?

Assuming so I'll add a "Kitchen Sink" example of a standalone MediaTile on its own. LMK if this is not what you're wanting.


Fixed typo

:warning: Validation status: warnings

File
Status
Preview URL
Details

msteams-platform/concepts/tabs/tabs-configuration.md
:warning:Warning

Details

msteams-platform/concepts/tabs/tabs-configuration.md

Line 9: [Warning] Invalid file link:(~/concepts/apps/apps-package).
Line 80: [Warning] Invalid file link:(~/resources/general/requirements).
Line 90: [Warning] Invalid file link:(~/concepts/tabs/tabs-context).
Line 90: [Warning] Invalid file link:(~/concepts/authentication).
Line 98: [Warning] Invalid file link:(~/concepts/tabs/tabs-content).
Line 102: [Warning] Invalid file link:(~/concepts/deep-links).
Line 103: [Warning] Invalid file link:(~/concepts/tabs/tabs-content).
Line 103: [Warning] Invalid file link:(~/concepts/tabs/tabs-update-remove).
Line 106: [Warning] Invalid file link:(~/resources/general/cross-domain).
Line 106: [Warning] Invalid file link:(~/resources/schema/manifest-schema).
Line 110: [Warning] Invalid file link:(~/concepts/tabs/tabs-update-remove#removing-a-tab).
Line 122: [Warning] Invalid file link:(~/troubleshoot/troubleshoot).

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.

Thanks - the typo has been fixed in master.  The publishing process discourages changes directly to live, so in the future you can branch master to make your changes.  I'll close this pr without merging because of this, but don't worry - your change has been made and will appear in live the next time master is merged - probably today.


KLogger obscures location info

I am using log4j with a patternlayout that includes class, method, and line number information.  I expect log statements to print in the form below.  This form holds when I manually set val logger: Logger = LoggerFactory.getLogger(this.javaClass).
INFO TEST_CONFIG.<init>(80) - test log

Instead, when I extend a companion object (or any singleton object) with object : KLogging(), the following unhelpful information prints
INFO KLogger.info(?) - test log

The code responsible for picking the location info is here in LocationInfo.  The code sees that KLogger is the immediately logging class on the stack trace and uses KLogger for location info.  It should instead use the class immediately below KLogger in the stack trace.
I'm not sure how to fix it, but there should be some hook in the log4j (ideally, slf4j) library that allows manipulating location info.

I see where the endpoint logging class is set in slf4j: Log4JLoggerAdapter.  It seems that changing the FQCN there would be difficult while staying agnostic to the particular logging framework.
For now I will opt to handle logging without the KLogging library.  Good idea though-- the library came very close to achieving a standardized elegance in Kotlin logging.

Thanks for raising the issue and the detailed explanation. I will try to
find a solution for that.
On Oct 12, 2016 1:26 AM, "Dylan Hutchison"<EMAIL_ADDRESS>wrote:

I see where the endpoint logging class is set in slf4j: Log4JLoggerAdapter
https://github.com/qos-ch/slf4j/blob/master/slf4j-log4j12/src/main/java/org/slf4j/impl/Log4jLoggerAdapter.java#L70.
It seems that changing the FQCN there would be difficult while staying
agnostic to the particular logging framework.
For now I will opt to handle logging without the KLogging library. Good
idea though-- the library came very close to achieving a standardized
elegance in Kotlin logging.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/MicroUtils/kotlin-logging/issues/11#issuecomment-253065441,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ACj0QXDWz96gr_UOH_EAgf8i_8eb8841ks5qzA0AgaJpZM4KUKLT
.

I think I might be able to solve that. Do you have any test or small
project that you can share and reproduce the issue?
On Oct 12, 2016 8:08 AM, "ohad shai"<EMAIL_ADDRESS>wrote:

Thanks for raising the issue and the detailed explanation. I will try to
find a solution for that.
On Oct 12, 2016 1:26 AM, "Dylan Hutchison"<EMAIL_ADDRESS>wrote:

I see where the endpoint logging class is set in slf4j:
Log4JLoggerAdapter
https://github.com/qos-ch/slf4j/blob/master/slf4j-log4j12/src/main/java/org/slf4j/impl/Log4jLoggerAdapter.java#L70.
It seems that changing the FQCN there would be difficult while staying
agnostic to the particular logging framework.
For now I will opt to handle logging without the KLogging library. Good
idea though-- the library came very close to achieving a standardized
elegance in Kotlin logging.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/MicroUtils/kotlin-logging/issues/11#issuecomment-253065441,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ACj0QXDWz96gr_UOH_EAgf8i_8eb8841ks5qzA0AgaJpZM4KUKLT
.

Sorry, I don't have a small project handy at the moment. It should be easy to recreate. Any project that uses slf4j-log4j will run into it.  Here's a log4j.xml you can use
<?xml version="1.0" encoding="UTF-8" ?>
<!DOCTYPE log4j:configuration SYSTEM "http://logging.apache.org/log4j/1.2/apidocs/org/apache/log4j/xml/doc-files/log4j.dtd">
<log4j:configuration>
  <appender name="CONSOLE" class="org.apache.log4j.ConsoleAppender">
    <layout class="org.apache.log4j.PatternLayout">
      <param name="ConversionPattern"
             value="%d{ISO8601} %p %C{1}.%M(%L) - %m%n"/>
    </layout>
  </appender>

  <root>
    <level value="INFO"/>
    <appender-ref ref="CONSOLE"/>
  </root>

</log4j:configuration>

a possible solution is to do something similar to: https://github.com/qos-ch/slf4j/blob/master/slf4j-ext/src/main/java/org/slf4j/ext/LoggerWrapper.java
con's are: methods can't be inlined and all logger interface methods has to be delegated explicitly as opposed to current implementation that delegation is implicit.
inline methods might have advantage on android. see issue #1. a possible solution for that is to have two KLogger flavours with a configuration to select which one to use, but this sounds like interface clutter.

Inlining is fine when the inline functions are extension methods on the
slf4j Logger. That's the solution I am currently using.
On Oct 14, 2016 5:18 AM, "oshai"<EMAIL_ADDRESS>wrote:

a possible solution is to do something similar to:
https://github.com/qos-ch/slf4j/blob/master/slf4j-ext/
src/main/java/org/slf4j/ext/LoggerWrapper.java
con's are: methods can't be inlined and all logger interface methods has
to be delegated explicitly as opposed to current implementation that
delegation is implicit.
inline methods might have advantage on android. see issue #1
https://github.com/MicroUtils/kotlin-logging/issues/1. a possible
solution for that is to have two KLogger flavours with a configuration to
select which one to use, but this sounds like interface clutter.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/MicroUtils/kotlin-logging/issues/11#issuecomment-253784254,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABm-diacwhRviO-DzZahmX1zzl_7pZyfks5qz3L0gaJpZM4KUKLT
.

couple of notes:

from my checks inlined methods do not have line number information. If you can share a different example it will be great.
extension methods are a poor solution for that case in my experience: requires imports which are sometimes not obvious to users.

fixed in 1.4

Nice job! The inline function logging retained information for me, for some reason. Maybe the Kotlin compiler chose not to inline the functions marked inline. It makes sense that that information would be lost.


Adding an icon that indicates the accordion control is open/closed

You can use the css classes in the accordion to achieve this.


Bug in cleaning up verbs resources

There is a bug in cleaning up verbs resources at the very end (program exit). There is a race condition between cleaning up the resources and remote operation, as far as I understand.
This is not critical yet, but should be handled later.

Tests seem to be exiting properly now.


Error on CertUpdate (Old 244)

In gitlab by @A-Lawrence on Aug 31, 2015, 01:08
There's an error on CertUpdate when members don't exist in Cert (i.e. they've been deleted).  The update then fails.

In gitlab by @A-Lawrence on Aug 31, 2015, 01:14
Deletes members who no longer appear in CERT. Resolves #488507 (244)
ÔåÆ <<cset 94e7f0e723ba>>
ALawrence66 - 2015-02-23T23:15:28.140731+00:00

In gitlab by @A-Lawrence on Aug 31, 2015, 01:14
Deletes members who no longer appear in CERT. Resolves #488507 (244)
ÔåÆ <<cset 1d57ddb4fcdf>>
ALawrence66 - 2015-02-23T23:15:27.659324+00:00

In gitlab by @A-Lawrence on Aug 31, 2015, 01:14
Deletes members who no longer appear in CERT. Resolves #488507 (244)
ÔåÆ <<cset 47b645ba5c14>>
NFarrington - 2015-02-22T04:35:04.343711+00:00

In gitlab by @A-Lawrence on Aug 31, 2015, 01:14
Deletes members who no longer appear in CERT. Resolves #488507 (244)
ÔåÆ <<cset 79f4980eb62c>>
NFarrington - 2015-02-22T04:35:04.116270+00:00


Add Ruby 3.3(.0) and drop obsolete patch versions.

Fixes #62.
No YJIT support yet; that's tracked in #65.
Tested: builds locally.

This version list will need updating too: https://github.com/alphagov/govuk-ruby-images/blob/main/.github/workflows/sign.yaml#L16

Ah thanks!

https://github.com/alphagov/govuk_app_config/issues/341 is likely a blocker for pretty much all GOV.UK projects looking to update to Ruby 3.3.


Wrap the Map

Introduce the well-known feature of wrapping. Heading toward one of the sides of the map should lead the snake to the opposite side.

done


Homebridge no longer starts after latest update to homebridge-config-ui-x

(sorry hit post too soon, edited to include details)
Describe The Bug:
After applying the most recent update to homebridge-config-ui-x, Homebridge no longer starts. I have not been able to fix by pulling the newest version of oznu/docker-homebridge:
docker-compose pull
docker-compose up -d
To Reproduce:
Homebridge no longer works. Not sure what I can do to debug/diagnose.

I would like to try reverting to a previous docker image but unsure how to do that. Instructions to do that would be appreciated.
I am on a Raspberry Pi.

Disregard - it came back up on it's own after ~30 minutes.  Never had that happen before!

There was a minor issue which I ended up fixing when debugging: somehow the port for the UI got overwritten. It used to be 80, and it got reset to 8080.


Fix some bad error reporting

currently the macro panic if anything wrong, this makes avery error be reported at the macro call site.
This PR fix that (+ some clippy warnings)

Thanks!


Updated website

I'm getting ready to merge and updating the change log - please @me if any other changes are pushed.


[Snyk] Security upgrade @angular-devkit/build-angular from 0.1000.8 to 13.0.0

Snyk has created this PR to fix 1 vulnerabilities in the npm dependencies of this project.
Snyk changed the following file(s):

frontend/package.json

Vulnerabilities that will be fixed with an upgrade:

Issue
Score

Directory Traversal SNYK-JS-SOURCEMAPSUPPORT-6112477
  170

[!IMPORTANT]

Check the changes in this PR to ensure they won't cause issues with your project.
Max score is 1000. Note that the real score may have changed since the PR was raised.
This PR was automatically created by Snyk using the credentials of a real user.

Note: You are seeing this because you or someone else with access to this repository has authorized Snyk to open fix PRs.
For more information:
🧐 View latest project report
📜 Customise PR templates
🛠 Adjust project settings
📚 Read about Snyk's upgrade logic

Learn how to fix vulnerabilities with free interactive lessons:
🦉 Directory Traversal

:tada: Snyk checks have passed. No issues have been found so far.
:white_check_mark: security/snyk check is complete. No issues have been found. (View Details)
:white_check_mark: license/snyk check is complete. No issues have been found. (View Details)


JSONWebTokenSerializer always return "Unable to log in with provided credentials." when the user is not activated.

My environment as follows:

macOS Sierra 10.12.6
Python 3.6.0
Django 2.0.5
djangorestframework 3.8.2
djangorestframework-jwt 1.11.0

What is expected instead of "Unable to log in with provided credentials."
'User account is disabled.' is expected, I think. In JSONWebTokenSerializer.validate, it seems to be implemented but not working.
How to reproduce
Install django and DRF and DRF-jwt with pip, and just start new app.
$ django-admin startproject myapp

Add rest_framework and rest_framework_jwt into INSTALLED_APPS in settings.py.
Then, myapp.urls edit as follows.
from django.contrib import admin
from django.urls import path
from rest_framework_jwt.views import ObtainJSONWebToken

urlpatterns = [
    path('admin/', admin.site.urls),
    path('jwt/create',  ObtainJSONWebToken.as_view())
]

Execute migration, create superuser and login to admin page.
$ python manage.py makemigration
$ python manage.py migrate
$ python manage.py createsuperuser
$ python manage.py runserver

Then, create new user (for example, username is 'user', password is 'hogefuga') and turn off Activate from admin page. Finally, post credentials to /jwt/create.
$  curl -X POST -d "username=user&password=hogefuga" http://<IP_ADDRESS>:8000/jwt/create
{"non_field_errors":["Unable to log in with provided credentials."]}

In my opinion
In JSONWebTokenSerializer.validate(), User is authenticated using settings.AUTHENTICATION_BACKENDS ('django.contrib.auth.backends.ModelBackend' is used by default). Then, Error handling is executed based on the value which is returned by AUTHENTICATION_BACKENDS.
django.contrib.auth.backends.ModelBackend is return user instance, when

user which has specified username exists

and

the user is activated (is_active == True)

However, if the user is not activated, it returns None instead, now.
So, current implementation of JSONWebTokenSerializer cannot handle 'User account is disabled.' error.
Are there any workaround for this issue? I want to distinguish these two errors.

Problem is:
AUTHENTICATION_BACKENDS = ['django.contrib.auth.backends.ModelBackend']
the default "ModelBackend" authentication backend does not allow users with is_active = False to log in.
so if you want to login with is_active= False, try
AUTHENTICATION_BACKENDS = ['django.contrib.auth.backends.AllowAllUsersModelBackend']
checkout : https://docs.djangoproject.com/en/2.0/ref/contrib/auth/#django.contrib.auth.models.User.is_active
for more detail.

Sorry, I'm confused.
I don't want to allow user with is_active = False to login. I want to know the real reason of refusing login.
This issue is a problem of django-rest-framework-jwt, I think. When user which is not activated try to login, Django refuse by default（'django.contrib.auth.backends.ModelBackend'）. This is because of 'The user is not activated.', not 'Unable to log in with provided credentials.'.
Current implemention of django-rest-framework-jw try to handle this, but it contains a bug , so it return 'Unable to log in with provided credentials.'.

if all(credentials.values()):
user = authenticate(**credentials)
        if user:
            if not user.is_active:
                msg = _('User account is disabled.')
                raise serializers.ValidationError(msg)
               ..............

in this portion ,**authenticate(credentials) will return none when is_active = false because of  'django.contrib.auth.backends.ModelBackend'
due to user = none
if user: is False
so it returns 'Unable to log in with provided credentials.'.
i don't know if django-rest-framework-jwt is aware of it or not ...or i may also be wrong


read: change Bytes methods to return Result

Also use Result more in internal APIs. No change to external API yet.

Coverage decreased (-0.01%) to 55.42% when pulling 0dc4bc5d24f99b8a9049df73b54e8752691dc338 on philipc:error into 74f0f5fbf6041e6a627ec6efe422f22d2e709833 on gimli-rs:master.


Basic TF-IDF classes

This is a very basic port of the TF and TFIDF classes from o.a.m.vectorizer.  There are two commits here.  The first uses the Lucene's DefaultSimilarity to calculate the weights.  The second removes the Lucene dependency and calculates the weights directly.  As noted in the comments,  the Lucene weights are calculated differently than weights using Spark's IDF methods.  The weights are consistent with TF-IDF weights generated using seq2sparse.

I've added a MLlibTFIDF weight for interoperability with MLlib.  I'll push this in the next couple of days if there are no objections.


firebase

Just wondering if it's possible to use firebase as the backend?
Does looking into the clientRest object to return promises that wrap firebase read and write operations make sense?

Sure, you just need to write your own restClient to map Firebase's REST flavor to admin-on-rest.


Add documentation, Default impls & use C structs for structs with ambiguous fields

Hey, thanks for your library ... I made a bunch of changes to make the API more comfortable.
This PR introduces the following breaking changes:

HashMap<String, MetaValue> isn't newtyped anymore since the newtype didn't add anything
no more null methods ... implement std::default::Default instead
use C structs for structs where tuple structs lack clarity (what's that i32? what's that String?)

If you like these changes, please merge them without squashing.

Thanks, appreciate the changes.

Thanks for merging :)
I have a bunch of more changes locally, for which I can also make a PR in the next couple of days, namely:

methods to iterate over the contained blocks in a block
methods to iterate over the contained inlines in a block / inline
methods to stringify an inline or a vector of inlines

Just FYI that you can wait with releasing a new version so that the new version can also incorporate these changes.

Ok, sounds good.


Content is not rendered when it includes new lines

Under some situations, which I have not yet qualified, do not render the contents when it includes new line characters. I have not found out where this is happening and have included several work arounds 👎  to do a String.replace contents, "\n", "" to get around the issue. This needs to be fixed.

@smpallen99 Could you add some examples?

Sure. if you remove this line https://github.com/smpallen99/ex_admin/blob/master/lib/ex_admin/table.ex#L86 and then view the dashboard page in ExAdminDemo, you will see that the last panel does not have any text.
I thought it might be related to markup :nested do but tested Xain directly. We are getting the correct text back from Xain as confirmed with a  pry, but its getting stripped out somewhere laster.

I also has the same issue with this code until I added the String.replace at the end.
    show license do
      panel "License Key"  do
        markup_contents do
          div ".form-group" do
            div ".input-group" do
              Xain.input "#key.form-control", value: license.license
              div ".input-group-addon" do
                span ".input-group-button", "data-toggle": "tooltip", title: "Copy to clipboard" do
                  button ".btn.btnn", type: "button", "data-clipboard-target": "#key", "data-toggle": "copied", title: "Copied!" do
                    img ".clippy", src: "/images/clippy.svg", width: "13", alt: "Copy to clipboard"
                  end
                end
              end
            end
          end
          script("""
              $(function() {
                var clipboard = new Clipboard('.btnn');
                clipboard.on('success', function(e) {
                  $("[data-toggle='tooltip']").tooltip('hide');
                  ...
              });
          """
          |> String.replace("\n", ""))
        end
    ...

Hmm, I tried to call panel macro and other macros from iex, but they have so many external dependencies.. So I guess macros rendering is another target for decoupling and refactoring :-)

Controller test on dashboard should do the trick
Sent from my iPhone

On May 22, 2016, at 3:29 PM, Roman Smirnov<EMAIL_ADDRESS>wrote:
Hmm, I tried to call panel macro and other macros from iex, but they have so many external dependencies.. So I guess macros rendering is another target for decoupling and refactoring :-)
—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub

@smpallen99 Controller tests in Phoenix belong to integration testing. So, it's not the best choice to test internals.

Minimal buggy code:
Xain.markup do
  Xain.p("""
    line1
    line2
    line3
  """)
end
# => {:safe, "<p>  line1\n  </p>"}

str = """
line1
line2
line3
"""
Xain.Helpers.id_and_class_shortcuts(str, [])
{"line1\n  ", []}

Fixed in Xain: https://github.com/smpallen99/xain/pull/4/files


Change Medusa Link

Change medusa link from https://www.medusa-commerce.com/ to https://www.medusajs.com/
Previous link shows a 404 page

@vsifiwe thanks for your fix!
Merging


[ci] Switch from 16MB to 32MB buffer sizes for tiny GHA runners

Issue and/or context: Follow-on from #2685

Full details are present in conversation on #2685


Source/Target version not transformed correctly

patch2-Math-104-Cardumen_98dc9eef38a8a3353d110786ffed93ec83d1cc02
Link to project: https://github.com/ASSERT-KTH/collector-sahab-experiments/tree/patch2-Math-104-Cardumen/Math-104
Stacktrace
[INFO] ---------------------< commons-math:commons-math >----------------------
[INFO] Building Math 1.2-SNAPSHOT
[INFO] --------------------------------[ jar ]---------------------------------
[INFO]
[INFO] --- maven-antrun-plugin:1.3:run (default) @ commons-math ---
[INFO] Executing tasks
     [copy] Copying 2 files to /tmp/Math-104_e5d67a8_98dc9ee_17098011882914025669/left/target/classes/META-INF
[INFO] Executed tasks
[INFO]
[INFO] --- maven-resources-plugin:2.6:resources (default-resources) @ commons-math ---
[WARNING] Using platform encoding (UTF-8 actually) to copy filtered resources, i.e. build is platform dependent!
[INFO] Copying 2 resources to META-INF
[INFO]
[INFO] --- maven-compiler-plugin:3.11.0:compile (default-compile) @ commons-math ---
[INFO] Changes detected - recompiling the module! :source
[WARNING] File encoding has not been set, using platform encoding UTF-8, i.e. build is platform dependent!
[INFO] Compiling 215 source files with javac [debug target 1.3] to target/classes
[INFO] -------------------------------------------------------------
[WARNING] COMPILATION WARNING :
[INFO] -------------------------------------------------------------
[WARNING] bootstrap class path not set in conjunction with -source 1.3
[WARNING] -parameters is not supported for target value 1.3. Use 1.8 or later.
[INFO] 2 warnings
[INFO] -------------------------------------------------------------
[INFO] -------------------------------------------------------------
[ERROR] COMPILATION ERROR :
[INFO] -------------------------------------------------------------
[ERROR] Source option 1.3 is no longer supported. Use 6 or later.
[ERROR] Target option 1.3 is no longer supported. Use 1.6 or later.
[INFO] 2 errors
[INFO] -------------------------------------------------------------
[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time:  0.752 s
[INFO] Finished at: 2023-04-27T00:09:08Z
[INFO] ------------------------------------------------------------------------

Fixed with the patch here.


Streaming mode is handling errors

Currently in stream mode, if you make a request to a 404 endpoint, it will emit the error event with the response body. In callback mode, err will be null.
I noticed this while investigating https://github.com/googleapis/nodejs-storage/issues/720. retry-request uses the response from this library to decide whether a request should be retried: https://github.com/stephenplusplus/retry-request/blob/48a8ec0ce54805ab8ea41edc8c89363a09c886d9/index.js#L168.
The request library doesn't treat a 404 as an error, for example.  Anything else must be parsed by the caller and self-determined to be an error.

cc @JustinBeckwith @bcoe

@stephenplusplus gotcha, so rather than a 404 bubbling to the client immediately, we retry with a backoff? definitely feels like the 404 should be in the errback.

I'm going to work on a PR that gets rid of the error handling in streams, to match the way it works in callback mode.

Thank you!