Issue with producing  and  in grobid version 0.7.1

Hi,

I tried training FULLTEXT model for list and item tags in Grobid 0.7.1-SNAPSHOT version which worked perfectly and produced the corresponding tags in the output of processFullText request.

Now, I tried implementing the same again for the stable realese 0.7.1 but was unable to get the tags. Same issue occured for the 0.7.2-SNAPSHOT

-For predicting the item and list tags, here is a sample annotation in the training.tei.xml file:

-Any clues on why this might be happening? Since the java code also seems to be exactly same for both versions 0.7.1 and 0.7.1-snapshot

Hi @kermitt2 , I fixed the issue by uncommenting couple of lines in the file TEIFullltextSaxParser.java in grobid-trainer directory.

No worries, although I am getting a great accuracy for  since I am using more data for training the fulltext model.

Ah I see ! Good to know thanks.
Let's keep the issue open until someone can find the time to come back to the list in the public training data :)


operator project-quay (3.9.0-nightly.2022.12.11)

Add 3.9.0-nightly.2022.12.11 to community operators

@quay-devel can you use sever instead of nightly-2022-12-09?

/merge possible

/merge possible


Style guide additions

More things to be added to the style guide:

in shell scripts, indent 2 spaces. (Takes less horizontal space than 4, which is good for the docs)
Prefer long options for shell script flags, as they are more readable

Another idea: always give sub-headings a sensible anchor name.


The README states docker must be run with --privileged

The README file states that a docker container of device-bluetooth-c must be run via the following command:
docker run
-v /var/run/dbus/system_bus_socket:/var/run/dbus/system_bus_socket
--privileged -p 49971:49971 device-bluetooth
In general, we should avoid use of the "--privileged" option as it basically disables confinement. Ideally docker should be run with the minimum extra options that allow the device service to function.
Why is use of --privileged required?

@anonymouse64 I would appreciate your help with writing an AppArmor policy. I've run the Docker container without --privileged, followed by the journalctl -e --no-pager | grep command.
Sep 13 10:38:42 dell audit[985]: USER_AVC pid=985 uid=106 auid=4294967295 ses=4294967295 msg='apparmor="DENIED" operation="dbus_method_call"  bus="system" path="/org/freedesktop/DBus" interface="org.freedesktop.DBus" member="Hello" mask="send" name="org.freedesktop.DBus" pid=12768 label="docker-default" peer_label="unconfined" Sep 13 10:38:42 dell kernel: audit: type=1107 audit(1568367522.859:50): pid=985 uid=106 auid=4294967295 ses=4294967295 msg='apparmor="DENIED" operation="dbus_method_call"  bus="system" path="/org/freedesktop/DBus" interface="org.freedesktop.DBus" member="Hello" mask="send" name="org.freedesktop.DBus" pid=12768 label="docker-default" peer_label="unconfined"

So that snippet you posted is actually the same denial being logged twice (from apparmor and from the kernel), the relevant bits are:
operation="dbus_method_call"
bus="system"
path="/org/freedesktop/DBus"
interface="org.freedesktop.DBus"
member="Hello"
mask="send"
name="org.freedesktop.DBus"
label="docker-default"
peer_label="unconfined"

which effectively means that a process running under the label docker-default (i.e. your container) tried to send a message to the system bus via DBus with path /org/freedesktop/DBus on member Hello with interface org.freedesktop.DBus. If you applied the apparmor rules I have at the bottom that would probably allow this Hello to continue, however you will run into further denials after this Hello is allowed, since the Hello is really just to see if DBus is allowed or not (in this case it was not so it didn't try the real accesses it needed).
I'll post again in a bit with an example command line option to docker to apply this

I think you should just add a disclaimer to the top-level README that says it's only possible to run this device service fully confined on distros with AppArmor enabled (maybe listing a few), and that at this time, this device service is not supported on any distro with SE Linux enabled by default (I actually wonder if anyone has done a full test of EdgeX on SE Linux?). I'd also file a bug specifically for the issue that the service can't be run on an SE Linux enabled distro (even with --priviledged specified), and close this issue.

Closing this as it's been addressed in the latest update to the README.


Use ScrollView for login container

Workaround issues described in https://keybase.atlassian.net/browse/DESKTOP-3250
Use ScrollView for mobile form container. This allows the view to be scrollable if keyboard is up on Android.
Also updating signup success view to use form container. Double checked the other views all used the form container as well.
Also removing ScrollView from the dumb sheet container so we can test that these views would scroll properly on mobile with Android keyboard.

@keybase/react-hackers


Add Gitea as a provider

Gitea supports acting as an OAuth2 provider to allow third party applications to access its resources with the user’s consent. This feature is available since Gitea release 1.8.0.

[ ] Check, can gitea used with the generic OIDC provider, if this is the case then please submit docs for this.

If the generic OIDC provider can't be used:

[ ] Add new provider under providers/
[ ] Add documentation
[ ] Add changelog entry

fwiw, not a sure a new provider implementation is needed, I managed to use Gitea by pretending to be Github, using these settings:
provider = "github"
redirect_url = "https://<< host running opauth2_proxy >>/oauth2/callback"
provider_display_name = "Gitea"
client_id = "<< client_id as generated by Gitea >>"
client_secret = "<< client_secret as generated by Gitea >>"
login_url="https://<< your gitea host >>/login/oauth/authorize"
redeem_url="https://<< your gitea host >>/login/oauth/access_token"
validate_url="https://<< your gitea host >>/api/v1"

If there is a working provider implementation using the GitHub provider, perhaps we could just add docs for doing that instead of adding a new provider?

I think that makes sense. Let me see if I can find some time in the next few days and I'll open a PR to add this to the docs.

fwiw, not a sure a new provider implementation is needed, I managed to use Gitea by pretending to be Github, using these settings:
provider = "github"
redirect_url = "https://<< host running opauth2_proxy >>/oauth2/callback"
provider_display_name = "Gitea"
client_id = "<< client_id as generated by Gitea >>"
client_secret = "<< client_secret as generated by Gitea >>"
login_url="https://<< your gitea host >>/login/oauth/authorize"
redeem_url="https://<< your gitea host >>/login/oauth/access_token"
validate_url="https://<< your gitea host >>/api/v1"

how to work with traefik docker swarm?
# 版本
version: "3.7"

# 服务
services:

  # 暂不支持设置时区
  traefik:
    image: traefik:v2.1.1
    ports:
      - 22:22
      - 80:80
      - 443:443
#      - 8080
    networks:
      - net # traefik_net
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock:ro
      - ../../dev-ops-repo/traefik/acme:/etc/traefik/acme
#    environment:
#      - TZ=${TIME_ZONE:-Asia/Shanghai}
    command:
#      - "--log.level=DEBUG"
      - "--api.insecure=true"
      - "--providers.docker=true"
      - "--providers.docker.swarmmode=true"
      - "--providers.docker.exposedbydefault=false"
      - "--entrypoints.ssh.address=:22"
      - "--entrypoints.http.address=:80"
      - "--entrypoints.https.address=:443"
      - "--certificatesresolvers.letsencrypt.acme.httpchallenge=true"
      - "--certificatesresolvers.letsencrypt.acme.httpchallenge.entrypoint=http"
#      - "--certificatesresolvers.letsencrypt.acme.caserver=https://acme-staging-v02.api.letsencrypt.org/directory"
      -<EMAIL_ADDRESS>      - "--certificatesresolvers.letsencrypt.acme.storage=/etc/traefik/acme/acme-v2.json"
#      - "--certificatesresolvers.letsencrypt.acme.storage=/etc/traefik/acme/acme-staging-v2.json"
    deploy:
      mode: global
      placement:
        constraints:
          - node.role == manager # 部署位置，只在管理节点部署
      update_config:
        parallelism: 1
        delay: 10s
      restart_policy:
        condition: on-failure
      labels:
        - "traefik.enable=true"
        - "traefik.docker.network=traefik_net"
        - "traefik.docker.lbswarm=true"
        - "traefik.http.services.traefik.loadbalancer.server.port=8080"
        - "traefik.http.routers.traefik.service=traefik"
        - "traefik.http.routers.traefik.rule=Host(`traefik.${SERVER_DOMAIN:-localhost}`)"
        - "traefik.http.routers.traefik.entrypoints=http"
        - "traefik.http.routers.traefik.middlewares=redirecttls"
        - "traefik.http.middlewares.redirecttls.redirectscheme.scheme=https"
        - "traefik.http.routers.traefiktls.service=traefik"
        - "traefik.http.routers.traefiktls.rule=Host(`traefik.${SERVER_DOMAIN:-localhost}`)"
        - "traefik.http.routers.traefiktls.entrypoints=https"
        - "traefik.http.routers.traefiktls.tls.certresolver=letsencrypt"
        - "traefik.http.routers.traefiktls.middlewares=auth"
        - "traefik.http.middlewares.auth.basicauth.users=${TRAEFIK_AUTH_BASIC}"

networks:
  # docker stack deploy -c <(docker-compose -f docker-swarm.yml config) traefik
  # Creating network traefik_net
  # 外部引用 "traefik_net"
  net:
    driver: overlay
    attachable: true

# 版本
version: "3.7"

# 服务
services:

  # https://github.com/v7lin/traefik-oauth2-proxy/blob/master/docker-compose.yml
  oauth:
    image: pusher/oauth2_proxy:latest
#    ports:
#      - 4180
    networks:
      - traefik_net
    environment:
      - TZ=${TIME_ZONE:-Asia/Shanghai}
      - OAUTH2_PROXY_CLIENT_ID=${OAUTH2_PROXY_CLIENT_ID?err}
      - OAUTH2_PROXY_CLIENT_SECRET=${OAUTH2_PROXY_CLIENT_SECRET?err}
      - OAUTH2_PROXY_COOKIE_DOMAIN=.${SERVER_DOMAIN:-localhost}
      - OAUTH2_PROXY_COOKIE_REFRESH=1h
      - OAUTH2_PROXY_COOKIE_SECURE=true
      - OAUTH2_PROXY_COOKIE_SECRET=${OAUTH2_PROXY_COOKIE_SECRET?err}
      - OAUTH2_PROXY_FOOTER=-
      - OAUTH2_PROXY_HTTP_ADDRESS=<IP_ADDRESS>:4180
      - OAUTH2_PROXY_PASS_BASIC_AUTH=false
      - OAUTH2_PROXY_PASS_USER_HEADERS=true
      - OAUTH2_PROXY_PROVIDER=${OAUTH2_PROXY_PROVIDER?err}
      - OAUTH2_PROXY_REVERSE_PROXY=true
      - OAUTH2_PROXY_SET_AUTHORIZATION_HEADER=true
      - OAUTH2_PROXY_SET_XAUTHREQUEST=true
      - OAUTH2_PROXY_WHITELIST_DOMAIN=.${SERVER_DOMAIN:-localhost}
    deploy:
      mode: global
      placement:
        constraints:
          - node.role == manager
      update_config:
        parallelism: 1
        delay: 10s
      restart_policy:
        condition: on-failure
      labels:
        - "traefik.enable=true"
        - "traefik.docker.network=traefik_net"
        - "traefik.docker.lbswarm=true"
        - "traefik.http.middlewares.oauth-verify.forwardAuth.address=http://oauth:4180/oauth2/auth"
        - "traefik.http.middlewares.oauth-verify.forwardAuth.trustForwardHeader=true"
        - "traefik.http.middlewares.oauth-verify.forwardAuth.authResponseHeaders=X-Auth-Request-User,Set-Cookie"
        - "traefik.http.middlewares.oauth-signin.errors.service=oauth@docker"
        - "traefik.http.middlewares.oauth-signin.errors.status=401"
        - "traefik.http.middlewares.oauth-signin.errors.query=/oauth2/sign_in"
        - "traefik.http.services.oauth.loadbalancer.server.port=4180"
        - "traefik.http.routers.oauthtls.service=oauth"
        - "traefik.http.routers.oauthtls.rule=Host(`oauth.${SERVER_DOMAIN:-localhost}`) || PathPrefix(`/oauth2`)"
        - "traefik.http.routers.oauthtls.entrypoints=https"
        - "traefik.http.routers.oauthtls.tls.certResolver=letsencrypt"

networks:
  traefik_net:
    external: true

If there is a working provider implementation using the GitHub provider, perhaps we could just add docs for doing that instead of adding a new provider?

Why not just add a wrapper implemtnation that reuses the same logic?

What value would adding the wrapper provide?

Re-looking at how the configuration of "fake Github" works proably none. Maybe we should just document it ? :)

+100 for just adding documentation if possible :)

@oliver006 Since you successfully got this working with a custom config that faked being Github -- Can you put up a PR that documents how you did this?

Yeah, my apologies, I meant to do that but then life got in the way. I'll see that I can cobble together a PR for an update to the docs by the end of the week. In the meantime, see my comment here for what config settings I used to get it to work.

Opened #510 for adding Gitea to the docs - let me know what you think.


Do not build with gtsam develop in example Dockerfile

Thank you @Wallbraker !

Thank you for merging :)


httpSourceSelector is not a function

Hi, I'm running the following code:
window.videojs = require('video.js/dist/video.min');

require('dashjs');
require('videojs-contrib-dash');
require('videojs-contrib-quality-levels');
require('videojs-http-source-selector');

(function(window, videojs) {
    var player = window.player = videojs('d6f7dff8a0edc4aed76c98c27a626ddd');
    player.httpSourceSelector();
}(window, window.videojs));

but I keep getting: Uncaught TypeError: player.httpSourceSelector is not a function
Any ideas?

Add jquery and that should fix it


WSL 2 DNS not working

Windows build number:  10.0.19041.21
I know it sounds like previous DNS problem reports, but this one is a bit different...
If I use IP addresses and not network address names, the network works fine. But network addresses are not resolved into IP addresses.
On a WSL 2 Ubuntu command prompt, i query for an IP address:
$ nslookup google.com <IP_ADDRESS>`

I can ping the <IP_ADDRESS> DNS Server. I can also get ping out to google.com:
$ ping -c 1 <IP_ADDRESS>
PING <IP_ADDRESS> (<IP_ADDRESS>) 56(84) bytes of data.
64 bytes from <IP_ADDRESS>: icmp_seq=1 ttl=123 time=1.06 ms

I was expecting to get the IP address of google.com, but instead i got the following:
;; connection timed out; no servers could be reached

Wireshark capture show that the following took place:
1. 00:15:5d:50:51:ac -> 00:15:5d:50:57:89 : ARP : Who has <IP_ADDRESS>? Tell <IP_ADDRESS>
2. 00:15:5d:50:57:89 -> 00:15:5d:50:51:ac : ARP : <IP_ADDRESS> is at 00:15:5d:50:57:89

And that's it. Silence. The DNS query did not go on its way.
If I switch the distribution back to wsl 1, I get the proper response:
$ nslookup google.com <IP_ADDRESS>
Server:         <IP_ADDRESS>
Address:        <IP_ADDRESS>#53

Non-authoritative answer:
Name:   google.com
Address: <IP_ADDRESS>
Name:   google.com
Address: 2a00:1450:400e:80a::200e

The wireshark capture in this case looks like this:
1. <IP_ADDRESS> -> <IP_ADDRESS> : DNS : Standard query 0x4a95 A google.com
2. <IP_ADDRESS> -> <IP_ADDRESS> : DNS : Standard query response 0x4a95 A google.com A <IP_ADDRESS>
3.  <IP_ADDRESS> -> <IP_ADDRESS> : DNS : Standard query 0x3a5 AAAA google.com
4. <IP_ADDRESS> -> <IP_ADDRESS> : DNS : Standard query response 0x3a5 AAAA google.com 2a00:1450:400e:80a::200e

Please don't suggest anything related to /etc/resolv.conf. It doesn't help.

Is anyone from Microsoft listening? If no, where can a defect report be submitted?

I found the problem in my case: Firewall. If I disable my mcafee End Point Security Firewall, DNS works on my WSL 2.0 box:
$ nslookup google.com
Server:         <IP_ADDRESS>
Address:        <IP_ADDRESS>#53

Non-authoritative answer:
Name:   google.com
Address: <IP_ADDRESS>
Name:   google.com
Address: <IP_ADDRESS>
Name:   google.com
Address: <IP_ADDRESS>
Name:   google.com
Address: <IP_ADDRESS>
Name:   google.com
Address: <IP_ADDRESS>
Name:   google.com
Address: <IP_ADDRESS>
Name:   google.com
Address: 2404:6800:4003:c03::71

Adding a Rule in Firewall that allows UDP port 53 (domain port) solves the problem too

Perhaps related: I just noticed that something has being creating tons and tons of inbound rules at the Windows Firewall configuration relative to port 53 (DNS):

They are all of two types:
HNS Container Networking - ICS DNS (TCP-In), associated to svchost.exe.
HNS Container Networking - DNS (UDP-In), for any program.
I'm at Windows 10 Pro build 19564 with WSL2, using regularly Ubuntu 18.04.4 LTS and Docker CE 19.03.6 (from the Ubuntu packages provided by Docker [1], not the new experimental Docker for Windows that uses WSL2).
[1] https://docs.docker.com/install/linux/docker-ce/ubuntu/
If they're inbound rules, my first guess is that these are created by WSL2 for a local DNS server used on things like localhost resolution to the ip address of the WSL2 network interface.
It concerns me that so many rules have being created at the firewall, and I'm unsure about removing them, but could it be related that this registration process somehow fails, or it works but the addition of so many rules delays the actual DNS responses?

It works in my evaluation copy of 2004. Additional info:

I use WiFi adapter exclusively. 2. Bypass my ISP DNS. Windows firewall uses Norton provider in which I let network utilities to go outside because they are not enabled by default.

The only case when it fails is nslookup from inside docker-desktop ddstro:
C:\Users\Pavel>wsl nslookup -d docker-desktop www.google.com
;; Connection to 2a00:1450:4001:818::2004#53(2a00:1450:4001:818::2004) for docker-desktop failed: connection refused. I blame Norton firewall. I had all such "connection refused" for most of network uti;ities.
Oh sorry! it works too:
C:\Users\Pavel>wsl -d docker-desktop nslookup www.google.com
nslookup: can't resolve '(null)': Name does not resolve
Name:      www.google.com
Address 1: <IP_ADDRESS> fra15s24-in-f228.1e100.net
Address 2: 2a00:1450:4001:800::2004 fra07s27-in-x2004.1e100.net
By my knowledge this is the "correct Google" for me

Doing the following worked for me
Windows Features - Disable WSL
Reboot
Windows Feature - Enable WSL
Reboot

I finally found a solution and I must say I didn't think of it.  This came from another thread on Stack Overflow.  I installed Ubuntu 18.04 AFTER uninstalling docker so it must leave all sorts of turds around for you to try and find - not exactly user friendly I would say!
"I checked /etc/hosts file. I had following in first line:
<IP_ADDRESS> localhost
I had to remove that and adding the following in the /etc/hosts solved the problem for me
<IP_ADDRESS> ip-XXX-XX-XX-XXX"
answered May 20 '19 at 0:40
Nabin
9,12666 gold badges5656 silver badges89

This will solve your issue..
https://gist.github.com/sivinnguyen/8bc0125b274250683a97e149cf270040

This was related to my firewall as well.  I have simplewall turned on and it was blocking incoming UDP port 53 packets from the 192.168.x.x block.  I enabled port 53 inbound and DNS immediately worked in WSL again.

Doing the following worked for me
Windows Features - Disable WSL
Reboot
Windows Feature - Enable WSL
Reboot

That also fixed the issue for me. WSL/Ubuntu files still exist too.

I've got the same issue. On my side it was due to Windows FW. An easy lookup for it is to disable the FW globally or only for the WLS2 vEthernet adapter, then try to make a DNS query from WSL2; if it works the issue is bound to Windows FW configuration.
In that case, you can either take the time to analyse your FW rules or if you don't mind (as me), you can globally allow DNS queries by adding a new inbound/outbound rule for it:

The problem is the VPN Ethernet Adaptor's DNS server settings are not taken by the WSL.
These steps worked for me to add these settings manually: https://gist.github.com/akshayhiremath/1b3bff527b3eca6cd41cf60ce88f3a56/8570f9fb4dbd681fc7aabcc817fa18cbab5f1e86#file-fix-wsl2-dns-resolution

Open a PowerShell with adminitrative privileges and run:
New-NetFirewallRule -DisplayName "WSL" -Direction Inbound  -InterfaceAlias "vEthernet (WSL)"  -Action Allow
Thats all. You can keep using your windows host as DNS relay instead of modifying DNS servers in /etc/resolv.conf
More info

Open a PowerShell with adminitrative privileges and run: New-NetFirewallRule -DisplayName "WSL" -Direction Inbound -InterfaceAlias "vEthernet (WSL)" -Action Allow
Thats all. You can keep using your windows host as DNS relay instead of modifying DNS servers in /etc/resolv.conf
More info

It doesn't work for me

Doing the following worked for me
Windows Features - Disable WSL Reboot Windows Feature - Enable WSL Reboot

I was facing same issue (started just after "wsl --update") , that fixed it for me too..
Thanks

@stratmm that worked. To clarify though

Control Pannel > Programs and features > Turn windows features on or off > Uncheck "Windows sub system for linux"
Reboot
Control Pannel > Programs and features > Turn windows features on or off > check "Windows sub system for linux"
Reboot


Add Dask and Koalas Accessors

Allows Dask and Koalas DataFrames and Series' to use the ww namespace for accessors.
Involves adding any additional Koalas and Dask tests or validation that might be necessary with the new API.

In checking _is_valid_schema, we check that all they dtypes for each column match. We should make sure to use the backup dtype for koalas dataframes.

In checking _is_valid_schema, we check that all they dtypes for each column match. We should make sure to use the backup dtype for koalas dataframes.

The ks.set_option('compute.ops_on_diff_frames', True) line will need to be added to table_accessor.py in a way that works in accordance with #543--so likely in the WoodworkTableAccessor.init method.

When adding support for Koalas, the function _is_valid_latlong_value will need to be updated to account for the need to use lists instead of tuples for latlong values in Koalas.

Closed by #652


More docs on adding dependencies

Adds build step changes and merlin changes when adding a dependency.

cc @chenglou

Great, thanks!


Pull latest cargokit and add script

How do you think that integrate update cargokit script to CI program

Actually, those are intended to be done with automate/__main__.py file, so that we can use python automate bridge-gen or other commands. What do you think about writing the automation script of integrating newest cargokit in that file? I think that Python file's content would be easy for a talented coder like you to understand :)

Actually, those are intended to be done with automate/__main__.py file, so that we can use python automate bridge-gen or other commands. What do you think about writing the automation script of integrating newest cargokit in that file? I think that Python file's content would be easy for a talented coder like you to understand :)
Maybe we can have a new command python automate cargokit-update.

yeah! It's a great idea to put automated scripts together.
But I still doubt whether it is necessary for python to implement scripts. After all, it makes the runing environment a little more demanding than bash scripts.
Is there any special reason to choose python?

Yeah, for mainly two reasons:

We can write once, use it on all windows, macos and Linux. bat or sh files are not qualified for that. This is also CI-friendly.
It's easy to manipulate strings, numbers with methods and regexes. Manipulating files can also be done in a platform-agnostic way.

There are some repositories using shell commands, but I saw many of those becoming a barrier between users between platforms 😂

Great :) does this work as expected, updating cargokit with some #Different from upstream on your machine?

Yeah, for mainly two reasons:

We can write once, use it on all windows, macos and Linux. bat or sh files are not qualified for that. This is very CI-friendly.
It's easy to manipulate strings, numbers with methods and regex. Manipulating files can also be done in a platform-agnostic way.

There are some repositories using shell commands, but I saw many of those becoming a barrier between users between platforms 😂

Thank you for your patient reply. I understand your idea.
I did ignore the script running problem of the non-*nix platform.
Python is indeed an excellent os-independent script actuator.

I'm happy that we have a consensus, thank you for respecting this :D

Great :) does this work as expected, updating cargokit with some #Different from upstream on your machine?

In my experience, the command git subtree pull  won't change the code on the line commented with #Different from upstream.

Oh, that's very interesting. Then I think this system does make a lot of sense 👍

Is it possible to integrate the automation scripts that RIF developers and RIF users will use?
RIF developers: bridge-gen, cargokit-update
RIF users: message, wasm, template

Good morning :)
There are reasons why scripts for 'US' has been splitted from scripts for 'USERS'. If you take a look at .pubignore file, you can see that some files and folders are excluded from being published to pub.dev, including our ./automate folder. This was because I thought scripts for 'US' should never be exposed to the RIF 'USERS', since these are just related to the maintenance of this framework and has nothing to do with developing the app.
Of course, we could write the script in ./bin folder as dart files, but then those scripts only for 'US' will be published to RIF 'USERS' which would be not ideal. That's why I thought using a totally separate, but universal language would be ideal for maintaining this repository, which was Python.

Good morning :)
There are reasons why scripts for 'US' have been splitted from scripts for 'USERS'. If you take a look at .pubignore file, you can see that some files and folders are excluded from being published to pub.dev, and that our ./automate folder is one of them. This was because I thought scripts for 'US' should never be exposed to the RIF 'USERS', since these are just related to the maintenance of this framework and has nothing to do with developing the app.
Of course, we could write the script in ./bin folder as dart files, but then those scripts only for 'US' will be published to RIF 'USERS' which would be not ideal. That's why I thought using a totally separate, but universal language would be ideal for maintaining this repository, which was Python.

Thanks for your detailed introduction, my understanding is deeper.
It is necessary to separate maintainers and users scripts.
It is also necessary for multiple scripts to use the same language.


Explicitly specify undefined symbols

I don't know whether this is something of interest, but with wasm-ld you can explicitly specify which symbols are undefined (using --allow-undedined-file=<value>).
This allows the following:

Code that uses random undefined symbols does not compile
Only symbols specified in include/wasm.syms are allowed to be undefined

This however requires the developer to not only define the signature of the function in a header, but also paste the function name into includr/wasm.syms to allow that function to remain undefined.

ae

Nah, sorry. The whole point was that the program compiles no matter what, but fails at runtime so it's easier for us to iterate and implement things that are not implemented yet, but needed for the game execution.

If possible, make it warn?


Add more score tests

Enable the *[0..-1] tests
Add tests for all comparisons
Check the score explicitly where known.
I also changed the result of the "Disjunction" test. I think it was incorrect before.

Ready to merge?


Issue when using custom page url

When configuring a custom page URL  (tested with Mx 6.10.10) the reloading of the styles via browser-sync fail to use the proper path instead of using the root it becomes something like:
/p/homedeveloper/css/custom/custom.css
while it should be
/css/custom/custom.css
Not sure if this has been resolved in later versions of Mx but if not it might be wise to fix it in the scripts available.
Thanks!

I haven't been able to get this fixed, but we did add a troubleshooting tip.

Closing issue as we have addressed this in the documentation


Simplify handling if no TCP mux is configured

Fixes #555

Pseudo-approval from me - I see no issues with the provided code. However, not able to approve myself


Lock the report thread, so that it's only unarchivable by mods

Unarchiving a thread shows the unarchiver in the audit log, which leads to identity leak if (accidentally?) performed by a user.
While there is seldom a reason to unarchive the report thread, so this situation is fairly rare, it is still nice to programmatically enforce this kind of problem never arises.

Sorry I forgot about this PR 🙈


Add support for returning different futures from branches?

Current futures do not support different futures (types) from branches
fetch_data().and_then(|maybe_data| {
  match maybe_data {
    // error because `Ok` and `Join` are different types
    None => ok(None),
    Some(data) => fetch_more().join(Ok(data)),
  }
})

current solution is to use Box and create a trait object. It let us return different types.
However, It also introduces dynamic dispatch, which isn't zero-cost.
Thus I suggest a new branch API, which looks like
fetch_data().and_then(|maybe_data| {
  match maybe_data {
    // both arm of branch returns `Branch<Ok, Join<_, _>>`
    None => ok(None).branch().first(),
    Some(data) => fetch_more().join(Ok(data)).branch().second(),
  }
})

FYI the same API have already implemented to transaction-rs (and source is here).

How do you like this? I'll implement up to Branch5 and submit a PR if you like.

Thanks for the report! This sounds similar to https://github.com/alexcrichton/futures-rs/pull/356 perhaps? I think we've having Either types up to EitherN (or something like that) although adding dedicated methods hasn't gotten off the ground yet.

There were discussion in Rust RFCs repo about anonymous enums once upon a time, which sound like the ideal solution in the long term.  It might look like -> enum Future return type instead of -> impl Future, along with maybe enum [expression] inside that handles the negative reasoning of mapping form types to variants.  An Either approach might look like -> Either3<impl Future, impl Future, impl Future> with at best some either! procedural macro inside for the negative reasoning.

@alexcrichton

This sounds similar to #356 perhaps?

Exactly. I scanned issues before reporting this issue but not PRs so I missed it, sorry.

although adding dedicated methods hasn't gotten off the ground yet.

Then, I think this builder approach is one option.

An Either approach might look like -> Either3<impl Future, impl Future, impl Future>

Isn't it sufficient that implementing Future for Either3<F1, F2, F3> where F1, F2, F3 is a Future (or, IntoFuture)? I think there are no overwrapping problem because tuples are already IntoFuture.

closing as duplicated. I'll join the discussion at #356 .


fix inkscape plugin for recent inkscape installations

Thanks Liam! Which version is this fix for?

no clue about which version starts to have problems, but it's necessary for debian11-backports's version of inkscape, so roughly 1.2.2
the only thing to fix was to make the inx file capable of finding the python script

...I was mistaken on that, I'll need to check on monday
the PC in front of me does have 1.2.2 and it doesn't work, let me fix that.

looking at the right PC, this fix is for inkscape 1.0.2
I have a couple other fixes ready for 1.2.2 as well on my home PC, but for now they are mixed with a lot of refactoring and an (incomplete) attempt to add other bond-creation methods to have long-range bonds not take half of each bubble

Thanks!
Yeah, it doesn't work for 1.2.x, but I never had time to fix it...


Can't activate

activate doesn't seem to be working for me. I'm trying to use it with Brave 1.57.64 Chromium: 116.0.5845.188 on Mac Ventura 13.5.2. How can I troubleshoot this, any ideas?

Same issue here with Chrome Version 118.0.5993.70 - activate does not seem to have any effect.

Likewise with Chrome v. 118.0.5993.117.

Activate works for me.
Are you using the latest chrome-cli (1.9.3)? That one fixes the problem with the id's changing.

Mine's on the latest. Still doesn't seem to work. Tab IDs are also stable.

Also on 1.9.3 and activate doesn't work.

This is happening consistently for me. I just updated via homebrew, and it didn't change anything. For what it's worth, this was happening before I updated to macOS Sonoma and also before I updated chrome-cli, so it's not specific to the versions of the software that I'm using. I wish I had thought to capture the behavior before I updated stuff so that it was clearer the range of versions that were misbehaving.
I hadn't looked at this project in a while, and I want to give a shout-out to the JSON output mode, it's great to work with! Thanks for that.
Below is an example of the issue with versions of all of the software that seem like they could be relevant. Let me know if there is any other info that might be useful for debugging.
macOS Version 14.7 (23H124)
; /Applications/Google\ Chrome.app/Contents/MacOS/Google\ Chrome --version
Google Chrome 129.0.6668.91
; chrome-cli version
1.9.3
; OUTPUT_FORMAT=json chrome-cli info
{
  "id" : "1076280841",
  "loading" : false,
  "title" : "ChatGPT",
  "url" : "https://chatgpt.com/?model=gpt-4o",
  "windowId" : "1076280837"
}
; OUTPUT_FORMAT=json chrome-cli list tabs | jq '.tabs|map(select(.title|contains("Issue #86")))'
[
  {
    "id": "1076281114",
    "title": "Can't activate · Issue #86 · prasmussen/chrome-cli",
    "url": "https://github.com/prasmussen/chrome-cli/issues/86",
    "windowId": "1076280837",
    "windowName": "ChatGPT"
  }
]
; chrome-cli activate -t<PHONE_NUMBER>
; OUTPUT_FORMAT=json chrome-cli info
{
  "id" : "1076280841",
  "loading" : false,
  "title" : "ChatGPT",
  "url" : "https://chatgpt.com/?model=gpt-4o",
  "windowId" : "1076280837"
}

Note that the active tab is not the one that that the chrome-cli activate command attempted to activate.


result text requirement

Hi
I am in the process of plotting the ACC/DP curve. Could you please share your result text file with me? Thanks

The tracking results have been uploaded to Baidu Netdisk.
https://pan.baidu.com/s/1nwFSK0SDFRwTE3XSjFUpSQ (code: eugd)


CARDS-1918: .token.html ignores the configured token expiry setting

This is a PR for CARDS-1918
To test:

start with -P prems,
make a visit information form with the visit time sometime in the past 30 days (per prems configuration, the token should be valid for 30 days)
generate the token by going to /Subjects/PATIENT_UUID/VISIT_UUID.token.html
sign out as admin (or switch to a different browser)
go to /Survey.html?auth_token=THE_GENERATED_TOKEN and check that it lets you fill in the form (not telling you the link has expired)

tested after the merge


Locality based routing not working after Istio 1.19 upgrade

Is this the right place to submit this?

[X] This is not a security vulnerability or a crashing bug
[X] This is not a question about how to use Istio

Bug Description
Recently we upgraded Istio control plane from 1.18.5 to 1.19.3. After the upgrade we noticed that locality based routing is not working. After much debugging, we found that our client was missing service object. Once we create client service, locality based routing started working.
In 1.18.5, we don't need to have client service dependency. Locality based routing is working without client service object in 1.18.5.
Version
$ istioctl version
istiod version: 1.19.3
data plane version: 1.19.3 (24 proxies)

$ kubectl version
Client Version: v1.28.1
Kustomize Version: v5.0.4-0.20230601165947-6ce0bf390ce3
Server Version: v1.27.7-eks-4f4795d

Additional Information
Destination Rule
apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
  name: helloworld-1-19
  namespace: istio-1-19-test
spec:
  host: helloworld-1-19
  trafficPolicy:
    loadBalancer:
      localityLbSetting:
        failoverPriority:
        - topology.istio.io/network
        - topology.kubernetes.io/region
        - topology.kubernetes.io/zone
        - topology.istio.io/subzone
    outlierDetection:
      baseEjectionTime: 3s
      consecutiveGatewayErrors: 10
      interval: 30s
      maxEjectionPercent: 30
      minHealthPercent: 50

Pod details
curlpods are clients and helloworld pods are our application services.
$ k get pods -owide
NAME                               READY   STATUS    RESTARTS   AGE    IP               NODE                                           NOMINATED NODE   READINESS GATES
curlpod-1-19-74b9477f4b-7w654      2/2     Running   0          115s   <IP_ADDRESS>    ip-100-64-60-225.us-west-2.compute.internal    <none>           <none>
curlpod-1-19-74b9477f4b-brttx      2/2     Running   0          115s   <IP_ADDRESS>     ip-100-64-127-126.us-west-2.compute.internal   <none>           <none>
curlpod-1-19-74b9477f4b-fn85x      2/2     Running   0          115s   <IP_ADDRESS>   ip-100-64-190-43.us-west-2.compute.internal    <none>           <none>
helloworld-1-19-567f7f58cb-j6z8x   2/2     Running   0          115s   <IP_ADDRESS>    ip-100-64-60-225.us-west-2.compute.internal    <none>           <none>
helloworld-1-19-567f7f58cb-whk75   2/2     Running   0          115s   <IP_ADDRESS>   ip-100-64-190-43.us-west-2.compute.internal    <none>           <none>
helloworld-1-19-567f7f58cb-zwbcb   2/2     Running   0          115s   <IP_ADDRESS>     ip-100-64-127-126.us-west-2.compute.internal   <none>           <none>

Service
kubectl get svc -owide -n istio-1-19-test

NAME              TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)   AGE    SELECTOR
helloworld-1-19   ClusterIP   <IP_ADDRESS>   <none>        80/TCP    113m   app=helloworld-1-19

Test with first client curlpod
With locality based routing we were expecting the traffic from curlpod-1-19-74b9477f4b-7w654 (running on ip-100-64-60-225.us-west-2.compute.internal) should go to the helloworld-1-19-567f7f58cb-j6z8x pod which is also running on the same node. But it was sending traffic to another pod.
$ kubectl exec curlpod-1-19-74b9477f4b-7w654 -- /bin/sh -c "while true; do curl -s helloworld-1-19/hello; done"
Hello version: v2, instance: helloworld-1-19-567f7f58cb-zwbcb
Hello version: v2, instance: helloworld-1-19-567f7f58cb-zwbcb
Hello version: v2, instance: helloworld-1-19-567f7f58cb-zwbcb
Hello version: v2, instance: helloworld-1-19-567f7f58cb-zwbcb
Hello version: v2, instance: helloworld-1-19-567f7f58cb-zwbcb
Hello version: v2, instance: helloworld-1-19-567f7f58cb-zwbcb
Hello version: v2, instance: helloworld-1-19-567f7f58cb-zwbcb
Hello version: v2, instance: helloworld-1-19-567f7f58cb-zwbcb
Hello version: v2, instance: helloworld-1-19-567f7f58cb-zwbcb
Hello version: v2, instance: helloworld-1-19-567f7f58cb-zwbcb
Hello version: v2, instance: helloworld-1-19-567f7f58cb-zwbcb
Hello version: v2, instance: helloworld-1-19-567f7f58cb-zwbcb
Hello version: v2, instance: helloworld-1-19-567f7f58cb-zwbcb

Test with second client curlpod
curlpod-1-19-74b9477f4b-fn85x running on ip-100-64-190-43.us-west-2.compute.internal should send traffic to helloworld-1-19-567f7f58cb-whk75 pod  which is running on same node. But it wasn't the case.
$ kubectl exec curlpod-1-19-74b9477f4b-fn85x -- /bin/sh -c "while true; do curl -s helloworld-1-19/hello; done"
Hello version: v2, instance: helloworld-1-19-567f7f58cb-zwbcb
Hello version: v2, instance: helloworld-1-19-567f7f58cb-zwbcb
Hello version: v2, instance: helloworld-1-19-567f7f58cb-zwbcb
Hello version: v2, instance: helloworld-1-19-567f7f58cb-zwbcb
Hello version: v2, instance: helloworld-1-19-567f7f58cb-zwbcb
Hello version: v2, instance: helloworld-1-19-567f7f58cb-zwbcb
Hello version: v2, instance: helloworld-1-19-567f7f58cb-zwbcb
Hello version: v2, instance: helloworld-1-19-567f7f58cb-zwbcb
Hello version: v2, instance: helloworld-1-19-567f7f58cb-zwbcb
Hello version: v2, instance: helloworld-1-19-567f7f58cb-zwbcb
Hello version: v2, instance: helloworld-1-19-567f7f58cb-zwbcb
Hello version: v2, instance: helloworld-1-19-567f7f58cb-zwbcb

Test with third client curlpod
curlpod-1-19-74b9477f4b-brttx  running on ip-100-64-127-126.us-west-2.compute.internal was sending traffic helloworld-1-19-567f7f58cb-zwbcb pod running on the same node.
$ kubectl exec curlpod-1-19-74b9477f4b-brttx -- /bin/sh -c "while true; do curl -s helloworld-1-19/hello; done"
Hello version: v2, instance: helloworld-1-19-567f7f58cb-zwbcb
Hello version: v2, instance: helloworld-1-19-567f7f58cb-zwbcb
Hello version: v2, instance: helloworld-1-19-567f7f58cb-zwbcb
Hello version: v2, instance: helloworld-1-19-567f7f58cb-zwbcb
Hello version: v2, instance: helloworld-1-19-567f7f58cb-zwbcb
Hello version: v2, instance: helloworld-1-19-567f7f58cb-zwbcb
Hello version: v2, instance: helloworld-1-19-567f7f58cb-zwbcb
Hello version: v2, instance: helloworld-1-19-567f7f58cb-zwbcb
Hello version: v2, instance: helloworld-1-19-567f7f58cb-zwbcb
Hello version: v2, instance: helloworld-1-19-567f7f58cb-zwbcb
Hello version: v2, instance: helloworld-1-19-567f7f58cb-zwbcb

If you notice here, istio-proxy is always sending traffic to the same pod from all proxies. Interesting thing here is it's the first entry from cluster endpoints. And Istio-proxy always sends traffic to the same proxy.
As soon as we add client service and rollout the pods, locality based routing starts working in 1.19.3. This doesn't happen in Istio 1.18.5. Currently we run several workloads and these clients don't have service object and locality based routing works fine.
This looks like a bug in Istio 1.19 version.

This was only intentionally (afaik) fixed in 1.20 by https://github.com/istio/istio/pull/46295. Not sure how it accidentally got fixed in 1.18, then re-broken in 1.19 (it has been "broken" for ~ever).
Note first line of https://istio.io/v1.19/docs/ops/deployment/requirements/#pod-requirements vs https://istio.io/latest/docs/ops/deployment/requirements/.
So overall, I wouldn't consider "locality LB requires client service in 1.19" to be a bug really. Given the behavior changes from 1.18 it may be a sign there is something else going on unexpected, though.
In any case, i would recommend upgrading to 1.20 personally

I doubt there is some regression on proxy labels, can you check if this is caused by missing locality labels in proxcy?
curl istiod /debug/adsz, it will list the labels


fails to run in Docker on CPU

Hello , i tried to run keras-centernet , on Docker with cpu . I built Docker image from Ros -melodic docker image. but it gives me following error
Segmentation fault (core dumped)

Full log
Using TensorFlow backend.
2019-12-06 07:22:42.321627: I tensorflow/core/platform/cpu_feature_guard.cc:142] Your CPU supports instructions that this TensorFlow binary was not compiled to use: AVX2 FMA
2019-12-06 07:22:42.370633: I tensorflow/core/platform/profile_utils/cpu_utils.cc:94] CPU Frequency:<PHONE_NUMBER> Hz
2019-12-06 07:22:42.376540: I tensorflow/compiler/xla/service/service.cc:168] XLA service 0x4622120 executing computations on platform Host. Devices:
2019-12-06 07:22:42.376592: I tensorflow/compiler/xla/service/service.cc:175]   StreamExecutor device (0): <undefined>, <undefined>
2019-12-06 07:22:42.399679: W tensorflow/compiler/jit/mark_for_compilation_pass.cc:1412] (One-time warning): Not using XLA:CPU for cluster because envvar TF_XLA_FLAGS=--tf_xla_cpu_global_jit was not set.  If you want XLA:CPU, either set that envvar, or use experimental_jit_scope to enable XLA:CPU.  To confirm that XLA is active, pass --vmodule=xla_compilation_cache=1 (as a proper command-line flag, not via TF_XLA_FLAGS) or set the envvar XLA_FLAGS=--xla_hlo_profile.
Segmentation fault (core dumped)

Probably outdated but can't reproduce without you providing more information.


Improve table headers detection

When upserting a table we usually tries to detect the headers by taking the first non empty row. This is often inefficient, as the headers can be on another row.
We could use a dustapp to detect more accurately the headers.
discussion here : https://dust4ai.slack.com/archives/C050SM8NSPK/p1723817681344219
example dust app : https://dust.tt/w/0ec9852c2f/a/phqtuUSqcy

The main issue with a dust app is that it does not contain any lib to handle CSV parsing properly. So the question is how good models are to find headers?

The main issue with a dust app is that it does not contain any lib to handle CSV parsing properly. So the question is how good models are to find headers?

Actually it does not receive csv but json. I will add more examples in the dataset, but it already works well in finding or guessing headers : https://dust.tt/w/78bda07b39/a/OJSd3KpoDU .


Password recommendations

How come the microsoft recommendations for passwords are not included on this page? Please add the guidance from https://www.microsoft.com/en-us/research/publication/password-guidance/ to this page

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

ID: ed24fd26-b126-c171-7edd-9f6713f23ab5
Version Independent ID: 1e240640-ff8c-8183-bd28-ebe3aa4674ff
Content: Azure identity & access security best practices
Content Source: articles/security/fundamentals/identity-management-best-practices.md
Service: security
Sub-service: security-fundamentals
GitHub Login: @barclayn
Microsoft Alias: barclayn

Hi @DeanGross Thanks for your feedback. We will review and update as appropriate.

@barclayn Can content from the book be incorporated or a new document be formed in this regard ?

#reassign:terrylan Assigning to Terry for her to consider the issue when updating the article.

terrylan is not a valid GitHub ID, or is not a collaborator on this repo.

#reassign:terrylanfear

@DeanGross - Thank you for your feedback. To present a consistent set of recommendations, the Azure security best practices will align to the Azure Security Benchmark program (https://docs.microsoft.com/azure/security/benchmarks/introduction). This program includes a collection of security recommendations you can use to help secure the services you use in Azure. The Azure Security Benchmark also aligns with the more recently published Microsoft Security Best Practices (https://docs.microsoft.com/security/compass/identity).
#please-close


Branch cordova plugin

I have similar plugins for both Mixpanel Cordova and Intercom Cordova. Before I submit the others, would someone mind reviewing this and letting me know if there is anything I need to add or improve upon in this PR? I am successfully using this plugin within my app.

Yes, I would be happy to make the changes recommended above and submit them to a new repo that you create. Please let me know when angulartics/angulartics-branch-cordova exists and also please create angulartics/angulartics-mixpanel-cordova and angulartics/angulartics-intercom-cordova as I will be submitting all 3.

Thanks @giltotherescue these have been created and you are a collaborator on all 3
https://github.com/angulartics

@giltotherescue need any help moving this over?
https://github.com/angulartics/angulartics-branch-cordova
https://github.com/angulartics/angulartics-mixpanel-cordova
https://github.com/angulartics/angulartics-intercom-cordova

Sorry, just got super busy. I can work on it sometime next week. Haven't
forgotten about it. If you'd like to help please feel free.
On Wednesday, October 5, 2016, Tim Elfelt<EMAIL_ADDRESS>wrote:

@giltotherescue https://github.com/giltotherescue need any help moving
this over?
https://github.com/angulartics/angulartics-branch-cordova
https://github.com/angulartics/angulartics-mixpanel-cordova
https://github.com/angulartics/angulartics-intercom-cordova
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/angulartics/angulartics/pull/515#issuecomment-251739348,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAWqMv5MMAsB75rcq8-df3C6YIfspm3Vks5qw9u4gaJpZM4KHO4T
.

Hi Tim, I'm so sorry that I never got around to implementing this. I would
very much like to contribute, however my startup is pretty much all
consuming.
That said, I do have quite a few Angulartics cordova implementations in
production that I would like to share (now incl. FB and Firebase). I am
attaching the source files in a zip in case you happen to have time to
implement. All of these are running successfully in production in my mobile
app.
https://cl.ly/341R363I2g18
Hope this helps!
On Wed, Oct 5, 2016 at 12:28 PM, Gil Hildebrand<EMAIL_ADDRESS>wrote:

Sorry, just got super busy. I can work on it sometime next week. Haven't
forgotten about it. If you'd like to help please feel free.
On Wednesday, October 5, 2016, Tim Elfelt<EMAIL_ADDRESS>wrote:

@giltotherescue https://github.com/giltotherescue need any help moving
this over?
https://github.com/angulartics/angulartics-branch-cordova
https://github.com/angulartics/angulartics-mixpanel-cordova
https://github.com/angulartics/angulartics-intercom-cordova
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/angulartics/angulartics/pull/515#issuecomment-251739348,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAWqMv5MMAsB75rcq8-df3C6YIfspm3Vks5qw9u4gaJpZM4KHO4T
.


Remove inference_tox21.py and relevant code from the Tox21 example

This PR removes inference_tox21.py which is an old script for inference in the Tox21. Currently we have two prediction code in the Tox21 example: one that implements custom inference loop (inference_tox21.py), and the other using Classifier (predict_tox21_with_classifier.py). It is confusing for users that there are two examples that essentially do same things. Using Classifier is a recommended way for prediction, so we keep the latter (and newer) one.
This PR also removes code that is no longer used if we remove inference_tox21.py

Codecov Report

Merging #184 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master     #184   +/-   ##
=======================================
  Coverage   76.64%   76.64%
=======================================
  Files          87       87
  Lines        3712     3712
=======================================
  Hits         2845     2845
  Misses        867      867

lgtm


Best way to color text the secondary color of current theme?

Material design has a concept of a secondary text color: https://www.google.com/design/spec/style/color.html#color-text-background-colors
I can access this color in flutter using the very verbose: Theme.of(context).textTheme.caption.color. I don't want any of the extra styling (weight, fontSize) from from caption or display[1-4]. Using Colors.black54 directly is not ideal since it wouldn't adapt to theme changes. Is there a less verbose way for me to get the secondary text color of the current theme? Currently I made a package level function but it feels like there should be a better way:
Color secondary(BuildContext context) =>
  Theme.of(context).textTheme.caption.color;

This allows me to say
new TextStyle(color: secondary(context))
instead of
new TextStyle(color: Theme.of(context).textTheme.caption.color)

@Hixie Sounds like ThemeData should have a field for this.

Agreed.

The secondary color is the accent color. There's a field on ThemeData for the accent color; we should point to it from the TextStyle docs or some such.

Maybe a bit late... but you can use this:
ThemeData(
primaryTextTheme: Typography(platform: TargetPlatform.iOS).white,
textTheme: Typography(platform: TargetPlatform.iOS).white,
)
https://icetutor.com/question/how-to-change-the-entire-themes-text-color-in-flutter


feat(worker_watcher): Add stack tests

This PR adds tests for the worker watcher Stack public methods. And also:

Fix critical issue with incorrect calculation actual and initial number of workers at the Destroy stage.
Fix CI coverage reports (coverpkg).
Add make test_coverage target to the Makefile to generate summary.out with whole codebase coverage report which can be used with Goland IDE (Run ->Show coverage data and then press + to add summary.out)

linked #368


Fix aica-docker installation for Mac

Description

This PR addresses the problem with the aica-docker installation on Mac. So far, we added autoload bashcompinit; bashcompinit which might not be a known command if you use zsh and should rather be enabled by the user itself on another line of the bashrc file. In other words, if the user didn't enable autocomplete in general yet, aica-docker is not going to change that.
Supporting information
Would be nice if you could test that @eeberhard
Review guidelines

Estimated Time of Review: 5 minutes

Nice, thanks for testing


Missing defines related to RFC8260

The declaration of I-DATA related defines are missing in usrsctp.h:
SCTP_INTERLEAVING_SUPPORTED
SCTP_STREAM_SCHEDULER
SCTP_STREAM_SCHEDULER_VALUE

Oh, okay. I see that is producing the I-DATA chunks anyways. And works, in the sense that it transports the data. I have load balancing for the streams on app level too, probably that's what saves the day.

So, does it just use the I-DATA chunks but not do any kind of interleaving when applying this workaround?

@shiretu No, I was just wondering what happens in that case. :slightly_smiling_face:

Just to be clear: The usage of I-DATA channels should be fine. What is missing is the interleaving feature of the stream schedulers. But I want to get the non-interleaving DATA and I-DATA handling stable at the receiver side before enabling the new feature on the sender side.

We are using it in an environment where e we push data over many channels. Stream-like data. So far works without problems


[Snyk] Security upgrade omniauth-saml from 2.1.1 to 2.2.0

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

Gemfile

⚠ Warning
Failed to update the Gemfile.lock, please update manually before merging.

Vulnerabilities that will be fixed with an upgrade:

Issue

Improper Verification of Cryptographic Signature SNYK-RUBY-OMNIAUTHSAML-7930878

[!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:
🦉 Learn about vulnerability in an interactive lesson of Snyk Learn.

Addressed elsewhere


Bad axis scale for power (cycling) in Recent Efforts est. power graph

Fixes the issue of power axis scale in Recent Efforts est. power graph wrong when HR data were missing for the last ride.

:)


Update dependencies

Coverage remained the same at 98.155% when pulling c9b5db683d90ba658837fa6bc052856fecc29c8d on update-dependencies into c21a890fdcd371569734e7756c2ad97de26affa4 on master.


Text overlaps in "File history"

GitLens Version: 101.2.2

VSCode Version: 1.47.2
OS Version: Windows 10

Steps to Reproduce:
1.Have repository with commits that go far back in time
Mousing over the text makes it show correctly.

Inspecting the element and setting the display to none reveals that the element that overlaps is placed incorrectly as it should be placed further down

I get a similar issue in the Repositories section with long commit histories, whether branches are collapsed or expanded.

If anyone is still seeing issues like this -- they are bugs in VS Code itself and should be reported there. Thanks!


Fixes for PHP 7.2 compatibility

Q
A

Is bugfix?
yes

New feature?
no

Breaks BC?
no

Tests pass?
no, but will

Fixed issues
#14489

There are still issues with session_cache_limiter()
https://github.com/yiisoft/yii2/blob/5a8c3d537ba14dbff02b2adee9072d381b9eb6b7/framework/filters/HttpCache.php#L192
And with session_set_cookie_params()
https://github.com/yiisoft/yii2/blob/5a8c3d537ba14dbff02b2adee9072d381b9eb6b7/framework/web/Session.php#L381
They work correctly on PHP 7.1, but not on 7.2. Is seems that PHPUnit does not restore environment after tests correctly. Maybe it is fixed in PHPUnit 6.*, but it requires PHP 7 or higher.
I would not like to skip these tests on PHP 7.2, but I don't have a clue how to fix it. I will be happy to hear some suggestions @yiisoft/reviewers @yiisoft/core-developers

Checked with PHPUnit 6.4.1 on PHP 7.2 – the problem is still present.

There is a issue about session_cache_limiter(): https://github.com/yiisoft/yii2/issues/14811

Assuming our rare releases schedule, I'd prefer to put 7.2 compatibility fixes in 2.0.13

When headers are already sent and try to set new INI values, session_name(),
session_module_name(), session_save_path(), session_cache_limiter() and
session_cache_expire() are no longer works. Older PHPs accepts new values even
if new values will not be effective.
This new corrected behavior may affect command line mode CLI scripts that manage
sessions. Use output buffer just like web applications to resolve problems on
CLI scripts.

From PHP 7.2 upgrade notes

This new corrected behavior may affect command line mode CLI scripts that manage
sessions. Use output buffer just like web applications to resolve problems on
CLI scripts.

This is only sessions, not headers?
We need change it?
https://github.com/yiisoft/yii2/blob/277468a7aa7c182ca7a686d3d82a2e38d897a980/framework/base/ErrorHandler.php#L100-L104

Partially fixed, but there is a mess with date parsing. Don't have enough time to check it now. If anybody can - it will be good

Reported 2 regressions in PHP core:
https://bugs.php.net/bug.php?id=75378
https://bugs.php.net/bug.php?id=75380
All tests except DB are passing now.

Fixed all remaining tests. Ready for review and merge. @yiisoft/reviewers

Thanks, Carsten. Fixed.

how and why was this working before?

I was surprised as well.

That was big! Thank you for patience. Now we're 7.2 ready! Yay!

We have fix in php-7.2.0RC5
75378

Already encountered in https://github.com/yiisoft/yii2/commit/336404e0b992406732d80bb239ecf3780dda4359


fla, shn, aif, aifc and vro

.fla
https://xiph.org/flac/documentation_tools_flac.html#usage
https://en.wikipedia.org/wiki/ISO_9660#Limitations
.aif and .aifc
https://en.wikipedia.org/wiki/Audio_Interchange_File_Format
Sample: ima4.aifc.txt
.vro
https://fr.wikipedia.org/wiki/Video_Recording_Object_file
Sample: https://www.dropbox.com/s/adl1q8mcvru972b/VR_MOVIE.VRO
.shn
https://en.wikipedia.org/wiki/Shorten_(file_format)
Sample: luckynight.shn.txt
This PR will have its complement on MediaInfoLib.

bad .vro link.

Well, it was still valid when i posted an issue here some months ago so i didn't verified. As the file is more than 800 MB i do note liké thé idea of uploading it on my low speed upload connection...

Sorry being late on the issues. Would you mind upload few MB of the file? I don't need the complete file.

No worry ;)
Well, i finally forced myself to upload it but it will not be available before some hours.
As i thought that you already downloaded this file some months ago i didn't expected to have to.
But as it is also related to an issue you should have the full file IMO.

http://www.rapidshare.space/zKPtVSm


json_schema is not a named validator type

I am trying to follow the test example from here to validate my schema. But I am getting an error
ValueError: Name json_schema is not a named validator type!```

So I looked up the `validators.py` file but I couldn't find anything for `json_schema` ? Could you tell me how we can do the schema tests??

Where is the code for json_schema ? the below code is from `validators.py` file

register_extractor('jsonpath_mini', MiniJsonExtractor.parse)
register_extractor('header', HeaderExtractor.parse)
register_extractor('raw_body', RawBodyExtractor.parse)
register_validator('comparator', ComparatorValidator.parse)
register_validator('compare', ComparatorValidator.parse)
register_validator('assertEqual', ComparatorValidator.parse)
register_validator('extract_test', ExtractTestValidator.parse)
register_validator('assertTrue', ExtractTestValidator.parse)```

nevermind, seems like I was missing a library jsonschema :)

Hi @rsukla-handy -  do you have the jsonschema library installed and available to python, per the docs ?

please close it, the issue is resolved.


[5.9] Fixes isDirty() for MySQL JSON cast columns

As per @taylorotwell, resubmitting laravel/framework#29208 to Master branch with correct spacing in originalIsEquivalent()

Currently, isDirty() would return true for JSON cast columns with equal key-value pairs that are input in an order other than their random stored order. The reason for this false positive is because of MySQL's behavior with JSON column types:
From the MySQL docs:

To make lookups more efficient, it also sorts the keys of a JSON object. You should be aware that the result of this ordering is subject to change and not guaranteed to be consistent across releases.

In plain English, this means that the array keys will often not be stored in the same order that they are input.
Behavior without the fix:
$model->jsonAttribute = [
    'foo' => 1,
    'bar' => 2,
    'baz' => 3,
];

$model->syncOriginal();

$model->jsonAttribute = [
    'baz' => 3,
    'foo' => 1,
    'bar' => 2,
];

$model->isDirty('jsonAttribute'); // true

The fix corrects this by checking for an empty result of array_diff_assoc() on JSON cast columns in originalIsEquivalent(). It also will fix the behavior for getChanges() (and naturally all other methods that depend on getDirty()).

This doesn't work if you remove keys from the array:
$user = User::create([
    'options' => ['a' => 'b', 'c' => 'd'],
]);

$user->update([
    'options' => ['a' => 'b'],
]);

dd($user->refresh()->options); // ['a' => 'b', 'c' => 'd']

@staudenmeir Good catch, closing for now to rework

It also doesn't work with nested arrays:
$user = Use::create([
    'options' => ['a' => ['b' => 'c']],
]);

$user->update([
    'options' => ['a' => ['b' => 'c', 'd' => 'e']],
]);

This throws an exception:

Array to string conversion

@staudenmeir Correct, see above comment

@staudenmeir I've made some changes by adding an Arr::diff() helper method. It instead of recursively comparing associative/multi-dimensional arrays, it is using the dot helper to flatten them before running array_diff_assoc().
https://github.com/distinctm/framework/commit/78e34f874837b8a8a5090485790152943a58453e
I do feel that it might add too much overhead, but am open to suggestions. I'm also not a big fan of the Arr::diff() helper returning differences in "dot" notation.
Additional tests have been implemented by adding a JSON specific model stub.
I'd love to hear your feedback on this approach. Again, it'd be nice to have support for isDirty() on JSON columns.

The dot notation is ambiguous:
$a = ['a.b' => 'c'];
$b = ['a' => ['b' => 'c']];
dd(Arr::diff($a, $b)); // []

Meaning if you had array keys utilizing dots? ['a.b', 'h.k', 'm.n', ...]
Then yes, it would present an issue. Although I do feel it's a bit of an edge case, I also am not 100% behind using flattened dot-arrays for comparison (although it is more elegant than a loop).
I'm open to any suggestions, I'll keep working on this as time permits. Feel free to reach out to me directly if you'd like to work on it together.

I do feel it's a bit of an edge case

It may be, but that doesn't matter here. We can't introduce new code that no longer detects certain changes.
I don't think there's a simple solution for this issue. Any approach would have to traverse both arrays.

@staudenmeir I agree on both counts.
The following passes the Arr:diff tests (so far), but isn't very pretty or easy to understand.
    /**
     * Returns bi-directional differences of two indexed, associative or multi-dimensional arrays.
     *
     * @param  array  $array1
     * @param  array  $array2
     * @return array
     */
    public static function diff(array $array1, array $array2)
    {
        if(!static::isAssoc($array1) && !static::isAssoc($array2)) {
            return array_merge(
                array_diff($array1, $array2),
                array_diff($array2, $array1)
            );
        }

        $keys = array_keys($array1);

        $items = array_map(function($value, $key) use ($array2) {
            if (is_array($value)) {
                if (!array_key_exists($key, $array2) || !is_array($array2[$key])) {
                    return $value;
                }

                return static::diff($value, $array2[$key]);
            }

            if (!array_key_exists($key, $array2) || $array2[$key] !== $value) {
                return $value;
            }
        }, $array1, $keys);

        return array_filter(
            array_combine($keys, $items)
        );
    }

A foreach loop instead of the array_map could improve readability slightly
    /**
     * Returns bi-directional differences of two indexed, associative or multi-dimensional arrays.
     *
     * @param  array  $array1
     * @param  array  $array2
     * @return array
     */
    public static function diff(array $array1, array $array2)
    {
        if(!static::isAssoc($array1) && !static::isAssoc($array2)) {
            return array_merge(
                array_diff($array1, $array2),
                array_diff($array2, $array1)
            );
        }

        $results = [];

        foreach ($array1 as $key => $value) {
            if (is_array($value)) {
                if (!array_key_exists($key, $array2) || !is_array($array2[$key])) {
                    $results[$key] = $value;
                } else {
                    $results[$key] = static::diff($value, $array2[$key]);
                }
            }

            if (!array_key_exists($key, $array2) || $array2[$key] !== $value) {
                $results[$key] = $value;
            }
        }

        return array_filter($results);
    }

Cases that don't work:
Arr::diff([[]], [[]]); // exception
Arr::diff(['a' => []], ['b' => []]); // []

@staudenmeir Thanks for catching those, adding them to the tests. Looks like I'll need to remove array_filtering for the second one.

Wouldn't the recursive iterator iterator be of help here?
Then you could just manually compare the keys in the traversal and exit early if something doesn't match you don't need to check if it's associative or sequential as they would have the same key values pairs in all cases
It would be performant and prevent other mentionned issues

@Tofandel I haven't utilized RecursiveIteratorIterator previously, but will explore it some as time allows. It would be nice to resolve this (though I have to admit I have not dug deep to see if any under-the-hood changes in the new releases of Laravel help address it). Thanks for sharing your thoughts.


How to correct disconnect multiple consumers?

I have some trouble with disconnecting multiple consumers I have started with different groupId's.
Hopefully you can help me.
This is my code for disconnecting...
/**
 * Service stopped lifecycle event handler
 */
async stopped() {

    await Promise.all(this.subscriptions.map(async (subscription) => {
        try {
            await subscription.consumer.pause( [ { topic: subscription.topic } ]);
            this.logger.info(`Consumer for subscription ${subscription.id} paused`);
        } catch(err) {
            this.logger.warn(`Pause consumer for subscription ${subscription.id} failed`);
        }
        Promise.resolve();
    }));
    await Promise.all(this.subscriptions.map(async (subscription) => {
        try {
            await subscription.consumer.disconnect();
            this.logger.info(`Consumer for subscription ${subscription.id} disconnected`);
        } catch(err) {
            this.logger.warn(`Disconnecting consumer for subscription ${subscription.id} failed`);
        }
        Promise.resolve();
    }));
    this.logger.info(`All consumers disconnected`);

}
`
I'm getting the following log:
`
  console.log lib\flow.subscriber.js:139
    ConsumerGroup INFO Pausing fetching from 1 topics { timestamp: '2018-05-29T19:10:29.954Z',
      logger: 'kafkajs',
      message: 'Pausing fetching from 1 topics',
      topics: [ 'events' ] }

  console.log lib\flow.subscriber.js:139
    ConsumerGroup INFO Pausing fetching from 1 topics { timestamp: '2018-05-29T19:10:29.959Z',
      logger: 'kafkajs',
      message: 'Pausing fetching from 1 topics',
      topics: [ 'events' ] }
  console.log lib\flow.subscriber.js:139
    Runner DEBUG stop consumer group { timestamp: '2018-05-29T19:10:29.965Z',
      logger: 'kafkajs',
      message: 'stop consumer group',
      groupId: 'f0c54a7b-1cbd-4248-8471-ae788c3566db',
      memberId: 'flow.subscriber1527621028637-9bef2c45-b84f-40f5-b670-c8b687240b51' }

  console.log lib\flow.subscriber.js:139
    Runner DEBUG stop consumer group { timestamp: '2018-05-29T19:10:29.981Z',
      logger: 'kafkajs',
      message: 'stop consumer group',
      groupId: '6bb861e2-e250-4f79-af08-3e9acecd2d45',
      memberId: 'flow.subscriber1527621028637-80fc7d53-6b5f-471c-b9de-504d750e8804' }

  console.log lib\flow.subscriber.js:139
    Connection DEBUG Request LeaveGroup(key: 13, version: 0) { timestamp: '2018-05-29T19:10:29.983Z',
      logger: 'kafkajs',
      message: 'Request LeaveGroup(key: 13, version: 0)',
      broker: '<IP_ADDRESS>:9092',
      clientId: 'flow.subscriber1527621028637',
      correlationId: 12,
      size: 147 }

  console.log lib\flow.subscriber.js:139
    Connection DEBUG Request LeaveGroup(key: 13, version: 0) { timestamp: '2018-05-29T19:10:29.985Z',
      logger: 'kafkajs',
      message: 'Request LeaveGroup(key: 13, version: 0)',
      broker: '<IP_ADDRESS>:9092',
      clientId: 'flow.subscriber1527621028637',
      correlationId: 12,
      size: 147 }

  console.info node_modules\moleculer\src\logger.js:112
    [2018-05-29T19:10:29.987Z] INFO  nbtpt510-al-7796/FLOW.PUBLISHER: Producer disconnectied

  console.log lib\flow.subscriber.js:139
    Connection DEBUG Response Fetch(key: 1, version: 2) { timestamp: '2018-05-29T19:10:34.452Z',
      logger: 'kafkajs',
      message: 'Response Fetch(key: 1, version: 2)',
      broker: '<IP_ADDRESS>:9092',
      clientId: 'flow.subscriber1527621028637',
      correlationId: 11,
      size: 42,
      data: '[filtered]' }

  console.log lib\flow.subscriber.js:139
    Connection DEBUG Request Heartbeat(key: 12, version: 0) { timestamp: '2018-05-29T19:10:34.481Z',
      logger: 'kafkajs',
      message: 'Request Heartbeat(key: 12, version: 0)',
      broker: '<IP_ADDRESS>:9092',
      clientId: 'flow.subscriber1527621028637',
      correlationId: 13,
      size: 151 }

  console.log lib\flow.subscriber.js:139
    Connection DEBUG Response LeaveGroup(key: 13, version: 0) { timestamp: '2018-05-29T19:10:34.487Z',
      logger: 'kafkajs',
      message: 'Response LeaveGroup(key: 13, version: 0)',
      broker: '<IP_ADDRESS>:9092',
      clientId: 'flow.subscriber1527621028637',
      correlationId: 12,
      size: 6,
      data: { errorCode: 0 } }

  console.log lib\flow.subscriber.js:139
    Consumer DEBUG consumer has stopped, disconnecting { timestamp: '2018-05-29T19:10:34.491Z',
      logger: 'kafkajs',
      message: 'consumer has stopped, disconnecting',
      groupId: 'f0c54a7b-1cbd-4248-8471-ae788c3566db' }

  console.log lib\flow.subscriber.js:139
    Connection DEBUG disconnecting... { timestamp: '2018-05-29T19:10:34.495Z',
      logger: 'kafkajs',
      message: 'disconnecting...',
      broker: '<IP_ADDRESS>:9092',
      clientId: 'flow.subscriber1527621028637' }

  console.log lib\flow.subscriber.js:139
    Connection DEBUG disconnected { timestamp: '2018-05-29T19:10:34.499Z',
      logger: 'kafkajs',
      message: 'disconnected',
      broker: '<IP_ADDRESS>:9092',
      clientId: 'flow.subscriber1527621028637' }

  console.log lib\flow.subscriber.js:139
    Consumer INFO Stopped { timestamp: '2018-05-29T19:10:34.500Z',
      logger: 'kafkajs',
      message: 'Stopped',
      groupId: 'f0c54a7b-1cbd-4248-8471-ae788c3566db' }

  console.info node_modules\moleculer\src\logger.js:112
    [2018-05-29T19:10:34.502Z] INFO  nbtpt510-al-7796/FLOW.SUBSCRIBER: Consumer for subscription f0c54a7b-1cbd-4248-8471-ae788c3566db disconnected

  console.log lib\flow.subscriber.js:139
    Connection DEBUG Response Fetch(key: 1, version: 2) { timestamp: '2018-05-29T19:10:34.503Z',
      logger: 'kafkajs',
      message: 'Response Fetch(key: 1, version: 2)',
      broker: '<IP_ADDRESS>:9092',
      clientId: 'flow.subscriber1527621028637',
      correlationId: 11,
      size: 42,
      data: '[filtered]' }

  console.log lib\flow.subscriber.js:139
    Connection DEBUG Request Heartbeat(key: 12, version: 0) { timestamp: '2018-05-29T19:10:34.505Z',
      logger: 'kafkajs',
      message: 'Request Heartbeat(key: 12, version: 0)',
      broker: '<IP_ADDRESS>:9092',
      clientId: 'flow.subscriber1527621028637',
      correlationId: 13,
      size: 151 }
`
now somthing went wrong...

`
  console.log lib\flow.subscriber.js:139
    Connection ERROR Response Heartbeat(key: 12, version: 0) { timestamp: '2018-05-29T19:10:34.508Z',
      logger: 'kafkajs',
      message: 'Response Heartbeat(key: 12, version: 0)',
      broker: '<IP_ADDRESS>:9092',
      clientId: 'flow.subscriber1527621028637',
      error: 'The coordinator is not aware of this member',
      correlationId: 13,
      size: 6 }

  console.log lib\flow.subscriber.js:139
    Connection DEBUG Response Heartbeat(key: 12, version: 0) { timestamp: '2018-05-29T19:10:34.511Z',
      logger: 'kafkajs',
      message: 'Response Heartbeat(key: 12, version: 0)',
      broker: '<IP_ADDRESS>:9092',
      clientId: 'flow.subscriber1527621028637',
      error: 'The coordinator is not aware of this member',
      correlationId: 13,
      payload: <Buffer 00 19> }

  console.log lib\flow.subscriber.js:139
    Runner ERROR The coordinator is not aware of this member, re-joining the group { timestamp: '2018-05-29T19:10:34.515Z',
      logger: 'kafkajs',
      message: 'The coordinator is not aware of this member, re-joining the group',
      groupId: 'f0c54a7b-1cbd-4248-8471-ae788c3566db',
      memberId: 'flow.subscriber1527621028637-9bef2c45-b84f-40f5-b670-c8b687240b51',
      error: 'The coordinator is not aware of this member',
      retryCount: 0,
      retryTime: 51 }
`

Hi @tulios . That was my first try.
But with the same result.
I think the reason is, that the cluster is also disconnected in the first call.
Would it possible to add a method "stop", which doesn't disconnect the cluster directly?
  /**
   * @return {Promise}
   */
  const disconnect = async () => {
    try {
      if (runner) {
        await runner.stop()
        logger.debug('consumer has stopped, disconnecting', { groupId })
      }
      await cluster.disconnect()
    } catch (e) {}
    logger.info('Stopped', { groupId })
}

Here is my original coding:
	/**
	 * Service stopped lifecycle event handler
	 */
	async stopped() {

        await Promise.all(this.subscriptions.map(async (subscription) => {
            try {
                await subscription.consumer.disconnect();
                this.logger.info(`Consumer for subscription ${subscription.id} stopped`);

            } catch(err) {
                this.logger.warn(`Stopping consumer for subscription ${subscription.id} failed`);
            }
            Promise.resolve();
        }));
        this.logger.info(`All consumers disconnected`);

    }

You can follow issue #67


Should the options for create_message_handler() be required?

Description
Should the options for create_message_handler() be required? Currently it returns an error if None is provided, because client_options are missing then
So either we have some default, or we make it required
Are you planning to do it yourself in a pull request?
Maybe.

Because of the merge with client they should stay optional


Added new enemy type "Gremlin"

Nothing much, might add more enemy types if I don't forget, It's basically first open-source I gave a reasonable contribution to, so I guess "Hello World"

Hey, thanks for contributing! Looks like there might be some bugs though if you check the build.

Added the missing comma, should be working now ^^

Greens all across the board. Thanks for chance to contribute

Thanks @HubiKazak! Happy Hacktober :tada:


Update storage-python-how-to-use-blob-storage.md

test!

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

This seems like a small (but important) contribution, so no contribution license agreement is required at this point. Real humans will now evaluate your PR.

TTYL, AZPRBOT;

@benwllms918 We're closing this PR because it appears to have only been a test.  Please comment if we should reopen.


api.office.com endpoint might need to be removed from this article

api.office.com is listed as a required endpoint.
api.office.com does not resolve in DNS. Is this endpoint deprecated?
_PS> test-netconnection api.office.com -port 443
WARNING: Name resolution of api.office.com failed
ComputerName   : api.office.com
RemoteAddress  :
InterfaceAlias :
SourceAddress  :
PingSucceeded  : False
PS> Resolve-DnsName api.office.com
Resolve-DnsName : api.office.com : DNS name does not exist
At line:1 char:1

Resolve-DnsName api.office.com

  + CategoryInfo          : ResourceUnavailable: (api.office.com:String) [Resolve-DnsName], Win32Exception
  + FullyQualifiedErrorId : DNS_ERROR_RCODE_NAME_ERROR,Microsoft.DnsClient.Commands.ResolveDnsName__

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

ID: b383a083-49a6-72b8-46f4-954c96192353
Version Independent ID: 35ab28d5-eddf-181b-c13b-bd7d20164b90
Content: Migration Manager Prerequisites and Endpoints - Migrate to Microsoft 365
Content Source: migration/mm-prerequisites.md
Service: sharepoint-online
Sub-service: sharepoint-migration
GitHub Login: @JoanneHendrickson
Microsoft Alias: jhendr

Hello @JeremyEsposito
I am looking into this.

An update to the article is coming

@get-itips @JeremyEsposito    I have removed this endpoint from the list and the change is now live.  Thanks!   joanne


Enable Linux bridge ProxyArpWifi

This change enables the Linux bridge's ProxyArpWiFi feature eliminating
the need to flood ARP packets. When an endpoint is created the bridge
driver already has the data needed to complete arp and fdb table
entries. Rather than let the kernel discover this information on its own
we populate the arp and fdb tables when the endpoint is configured.  All
other broadcast traffic will pass normal allowing the administrator to
manage it using ebtables.
Linux bridge ProxyArpWifi is enabled with:
--opt com.docker.network.bridge.proxyarp=1
Dependencies:
linux kernel v4.1-rc1 or later(commit 842a9ae08a25671db3d4f689eed68b4d64be15b5)
vishvananda/netlink commit b144143ea1df18e21a08e2ec101ada9a94a9cc85
Signed-off-by: David Wilder<EMAIL_ADDRESS>

Some background on this change:
One obstacle to scaling a bridge network is the management of broadcast packets. To emulate a Ethernet type network the Linux bridge must deliver broadcast packets to every port of the bridge. This is accomplished by cloning and flooding broadcasts to every endpoint.  Each of these cloned packets becomes an ingress packet in the kernel's network stack. If a bridge has 1024 ports one broadcast packets must be process by the kernel 1024 times. We have demonstrated running 10,000 containers on a single bridge network increasing the issue ten fold. Using multiple smaller L3 networks can reduce this overhead but creates additional management problems.
The ARP protocol makes use of broadcast packets when sending who-has requests. In our 10,000 node tests, we will send Arp who-has packets to all 10,000 nodes, this requires the kernel to process 100,000,000 broadcast packets (all but 10k are dropped)!  This can cause the kernel's network ingress queues to overflow resulting in packet drops and connection establishment timeouts. I  have seen this problem with configurations of only a few thousand nodes as well, even when using multiple bridges.  Increasing the size of the ingress queue helps but results in higher latency when the queue is filled with broadcast packets. Brtables can be used to eliminate broadcast traffic or to limit delivery to a small number of endpoints.  However, doing so breaks the Arp protocol as arps relies on broadcast packets. This change enables the Linux bridge's ProxyArpWiFi feature eliminating the need flood ARP packets. All other broadcast traffic will pass normal allowing the administrator to manage it using ebtables.

Question:
This change depends on a recent commit to vishvananda/netlink.  Should I post an update to vendor.conf to reflect this dependency?

Thanks @djlwilder . Yes, please include a second commit in your PR in which you update to the netlink vendoring.

Thanks @aboch, I updated  vendor.conf.  However cI is still failing due to vendoring.  Do I need to do something to fix this?

@djlwilder Modifying the vendor.conf file is only step one, second you need to run the vndr binary to import the new vendored files (instruction here).
Once done, don't forget to add vendor.conf and the new modified/imported files to a specific vendor commit, apart from the commit with the bridge files changes.

Please sign your commits following these rules:
https://github.com/moby/moby/blob/master/CONTRIBUTING.md#sign-your-work
The easiest way to do this is to amend the last commit:
$ git clone -b "Proxyarp" git@github.com:djlwilder/libnetwork.git somewhere
$ cd somewhere
$ git rebase -i HEAD~842353975960
editor opens
change each 'pick' to 'edit'
save the file and quit
$ git commit --amend -s --no-edit
$ git rebase --continue # and repeat the amend for each commit
$ git push -f

Amending updates the existing PR. You DO NOT need to open a new one.

My apologies,  I messed up this pull request.  I am closing it and will try again with a new request. Thanks


Autodetect system theme

Set light or dark theme automatically unless the user has already manually changed that.

This is included as part of #164.


Cleanups and C++ compatibility

That's a large set of patches. The common topics are hardening the code, improving logging and updating the documentation. No new features are added. No user visible changes are expected apart from the logs and the messages in the login window.
The only significant bugfix it preventing a string literal from being freed on exit in xrdp-chansrv.
prog_std.txt suggests compiling the code with a C++ compiler. I was able to do that, both with gcc and clang. Only the straightforward and obviously good results of that effort are included, the rest remains on my devel branch for further work.
The -Wwrite-strings flag has been added to enable detection of incorrect string literal access even with C compilers.
To avoid excessive casts from void* on malloc results, I introduced macros g_new and g_new0, exactly as in glib, and they do the cast automatically. I think g_new0 is very good at showing that zero-initialized memory is requested. If we start using glib, we'll have one thing less to worry about.
If any patch raises questions, please let me know, I'll take it away for separate discussion.
The code has been tested by logging in from Mac clients. That included running xrdp and xrdp-sesman in Valgrind.

Big PR, looks good so far.  Still looking.

+1
Also, i think the g_new thing should be changed in one place like in os_calls.c, so diff will be smaller. and merges will be easier.

g_new needs to be a macro. It needs to know the expected type to case the result. So all the invocations flagged by the C++ compilers need to be changed. I cannot make the diff smaller, unless I'm missing something.

Sorry, you're right.
I still didn't review the other changes but seems like a good cleanups here.
Why does cpp compiler warn about the old g_malloc ? Is it about lack of
casting?
בתאריך יום ד׳, 29 ביוני 2016 ב-9:23 מאת Pavel Roskin <
<EMAIL_ADDRESS>
g_new needs to be a macro. It needs to know the expected type to case the
result. So all the invocations flagged by the C++ compilers need to be
changed. I cannot make the diff smaller, unless I'm missing something.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/neutrinolabs/xrdp/pull/390#issuecomment-229267182,
or mute the thread
https://github.com/notifications/unsubscribe/ADTH1AqKHfSonUlSrRh4SuzydQm3AUSRks5qQg9DgaJpZM4I7UUZ
.

Yes. C++ requires explicit cast from void pointer to other pointers. See http://stackoverflow.com/questions/605845/do-i-cast-the-result-of-malloc

I know that , but we did use explicit casts in xrdp code.
בתאריך יום ד׳, 29 ביוני 2016 ב-10:09 מאת Pavel Roskin <
<EMAIL_ADDRESS>
Yes. C++ requires explicit cast from void pointer to other pointers. See
http://stackoverflow.com/questions/605845/do-i-cast-the-result-of-malloc
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/neutrinolabs/xrdp/pull/390#issuecomment-229274645,
or mute the thread
https://github.com/notifications/unsubscribe/ADTH1N3_NDkkekv3emSb8uGA2w03P1vRks5qQho9gaJpZM4I7UUZ
.

xrdp g_malloc calls should be casting but some might not.
In C void* can be assigned to other pointer without a cast.  In C++ you need to cast or you get warning.

Is anything needed on my part?
The reason I introduced g_new() is to avoid new casts where they were missing. Eventually, calls to g_malloc() with casts could be converted to g_new(), but it would be a big change. The point of this branch is to fix C++ errors and warnings without negatively affecting readability.
Also, I have discovered that ''Use g_strdup() for xrdp-chansrv program name, it's freed on exit" is not needed. It fixes a warning, but a better fix would be to use const strings for application and log name and fix all invocations. I think it would be easier to merge this branch as is and then do a cleanup on a separate branch. But if anyone insists, I can remove that patch from the branch.
The reason I work on the warnings is because I want any future fixes to be held against higher coding standards. It's easy to introduce bugs if nobody looks at the warnings. I don't want to add more patches if I don't get feedback.

hi,
i have fellow the whole changes in the last month.. and want say,
they should first clean up bring a new version out, where it is fixed fully (you can maybe help with)
before you make some big changed for have a clean Version for distriebutioning
and then it's this maybe not bad, if you change this whole with g_new() and something
for the next version.. xrdp should bring out/up a next version and come to 1.0 or something ;)
( i be inquisitive how long it's need for 1.0 :) )
best regards
Blacky

I think it's telling that the whole cleanup did not reveal any user-facing issue, apart from documentation and log messages. That g_strdup() in xrdp-chansrv was supposedly one fix, but even that is not fixing a user visible bug, as there is another g_strdup() in log_start_from_param(). The code quality is reasonable. We can release 0.9.1 now, with or without change on this branch. Version 1.0 is a once-in-a-lifetime event, let's do it after the documentation is improved.

@proski : clear if there be no stable and the distriebutions do not obstruct this lil small nice proggy for rdp (which also high usable for Reactos :))))  ) so long it's not installed in the whole distro's ..rdp make the whole WinNT Liux Connectivity really usable and more easily insteat the an bit more technical and complicated vnc. And i bet, with this Xrdp will makes the whole much easyer , i looking forward if it's into the whole Distros include, also OpenMandriva. :+1: yepp

Please don't merge, there is a bug somewhere that affects the login screen. I'll update the branch once I fix it.

I've updated the patch set. It's OK to merge now.
The patch named "Make xrdp_wm_log_msg() log its output" removed an unrelated call accidentally, which broke the log window on login failure. That has been fixed.
Instead of running g_strdup() on program_name, program_name has been made a constant string, so the unnecessary path to use g_strdup() for xrdp-chansrv program name has been removed.
The C++ port is complete now. I have cleaned up and included the remaining patches. That includes a patch that makes it the code compiled with C++ run correctly and load modules.


Default tooltips not working for geom_polygon() on small plots

There are default tooltips that pop up when I use aesthetics. These tooltips do not pop up when geometry is geom_polygon() and my plot is small enough. See the example below:
import numpy as np
import geopandas as gpd
from shapely.geometry import Polygon

from lets_plot import *
LetsPlot.setup_html()

n = 50
r = 1.0
s = .05
phi = np.linspace(0, 2 * np.pi, n + 1)[:-1]
X = r * np.cos(phi)
Y = r * np.sin(phi)
xy = list(zip(X, Y))
geometry = [Polygon([(x - s / 2, y - s / 2), \
                     (x - s / 2, y + s / 2), \
                     (x + s / 2, y + s / 2), \
                     (x + s / 2, y - s / 2)]) \
            for x, y in xy]
gdf = gpd.GeoDataFrame(dict(x=X, y=Y, phi=phi), geometry=geometry)

p1 = ggplot(gdf, aes(x='x', y='y')) + \
    geom_point(aes(color='phi')) + \
    scale_color_gradient(low='red', high='blue') + \
    coord_fixed() + ggtitle('Geometry: geom_point()')
p2 = ggplot() + \
    geom_polygon(aes(fill='phi'), data=gdf) + \
    scale_fill_gradient(low='red', high='blue') + \
    coord_fixed() + ggtitle('Geometry: geom_polygon()')

bunch = GGBunch()
bunch.add_plot(p1, 0, 0, 400, 400)
bunch.add_plot(p1, 400, 50, 300, 300)
bunch.add_plot(p2, 0, 400, 400, 400)
bunch.add_plot(p2, 400, 450, 300, 300)
bunch.show()

There was a restriction on small polygons: area was compared with the constant.
Commit: https://github.com/JetBrains/lets-plot/commit/bd565a21475bc8ce4cbdff81fe30e53b19408ba6


Add clifford circuit name in test_qpy

Summary
Fix Clifford Circuit test case for QPY backwards compatibility.
Details and comments
Added name argument to QuantumCircuit.

This is actually only needed on main, but the normal workflow is to start on main and label the pr as stable-backport-potential so the mergify bot will backport it to the stable branch automatically.

Now that I've got it in the merge queue, here's a bit more detail:

this PR was made from a source branch of stable/0.45 on your repo, which isn't ideal, because that's a stable-tracking branch that will be out-of-sync on your fork now (it's typically best to create a new branch when making a PR, and not to make commits on main, stable/0.45, etc).
this PR was originally targetting stable/0.45, but it's most urgently needed on main, and as Matt explained above, our usual procedure is to merge to the most recent dev branch (main), and then backport to necessary targets

In the future, the easiest way to make a PR targetting a new branch is just to close the existing PR and make a new PR from a source branch that was branched from the correct place, with the changes made on top.  I didn't do that because you'd already made the bug fix, and I wanted it merged ASAP without needing to get another maintainer to review again.
Because this PR was made on your local stable/0.45 branch, which will now be out-of-sync with the real stable/0.45 (it would have been with or without my messing around with it), you'll very likely want to delete your local copy of stable/0.45 (git branch -D stable/0.45), and remake it if you need it again in the future.

For completeness, then, this is what I did to get it re-targetted and to be merged:

I used the "edit" button at the top of the page on GitHub to retarget the PR to main.  This makes it appear like many new commits are also (incorrectly) part of the PR, because it now tries to include backport commits that were on your copy of stable/0.45.
To get rid of the backport PRs, I used git to rebase your stable/0.45 branch so that it actually now is on top of main, rather than stable/0.45, and I selected only the commit that was meant to be in the PR.  To do that, I (writing the commands as you'd run them, which isn't exactly how I did, since I access your fork as an additional git remote):

Checked out your branch locally (git checkout stable/0.45)

Made sure my copy of the Qiskit remote was up-to-date (git fetch origin)

Used an interactive rebase to move commits from your local branch to be on top of Qiskit main (git rebase -i origin/main)

Using git rebase -i ... pops up a text editor that lets us control exactly which commits to apply, and potentially apply additional actions to them.  In this case, the command produced a "todo" file that looked like:
pick 032425d470 Fix bad version checker in "previous versions" documentation (#11066)
pick 33ed1634d9 Prepare 0.45.0 release (#11169)
pick f3fb08990f Collapse release notes for pre-releases (#11224)
pick 5e4fa16aae small typos and spelling issues in passes docs (#11163) (#11237)
pick ff85be703c Fix `Channel.__hash__` in multiprocessing contexts (#11251) (#11255)
pick 4a5982a060 Add support for Python 3.12 (#11262) (#11311)
pick 310c457e5e Pin rust compiler version to 1.73 for wheel builds (#11267)
pick 58f8d24471 Prepare 0.45.1 release (#11331)
pick a2de3517f6 Add Python 3.12 to ASV conf. (#11342) (#11343)
pick ef21b509a6 Pin `z3-solver` on macOS VMs (#11408) (#11409)
pick 695733a510 Remove non-API docs and tutorials (Cherry-pick of #11352) (#11398) (#11420)
pick 9a67d8062c Remove Qiskit Terra 0.25 from release_notes.rst (#11436) (#11457)
pick 7fb6accebe Fix broadcasting of `QuantumCircuit.delay` (#11447) (#11523)
pick 92d589f9ab Fix a bug of missing pulse library entry in PulseQobj parsing (backport #11397) (#11573)
pick 0ab44e3864 Prepare release 0.45.2 (#11590)
pick b371041d07 Fix cibuildwheel config for building 32bit Python 3.12 wheels (#11595)
pick d31ce5d1a4 Add clifford circuit name in test_qpy

All except the last commit are commits that were backported to the 0.45, and should not be included in main, so I deleted those lines.  I wanted the last commit (which was the single commit in this PR), so I left that as a "pick" line, so the end result was the file looked like:
pick d31ce5d1a4 Add clifford circuit name in test_qpy

I saved and quit the editor, and git applied the rebase, so the branch now looked like main, but with one extra commit.

Now I needed to make the remote branch on your fork branch match, but I'd rewritten the history on it, so I couldn't push the changes normally.  Instead, I force-pushed the changes to force git to overwrite the remote copy.  That's git push --force, after the branch is set up.

In general, git rebase and git push --force are dangerous commands when working with git remotes, and they can be tricky to get right, which is one of the major reasons we suggest just opening a new clean PR.  I've tried to explain what I did here, though, so you know.

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage decreased (-0.02%) to 89.481%

Totals

Change from base Build<PHONE_NUMBER>:
-0.02%

Covered Lines:
59461

Relevant Lines:
66451

💛  - Coveralls