sysl openapi spec importer behaviour assumes query params of different endpoints with the same name have the same schema, and non-deterministically picks a schema for them both to use

Description
sysl openapi spec importer behaviour assumes query params of different endpoints with the same name have the same schema, and non-determinstically picks a schema for them both to use
Steps to Reproduce
The following example is hand-minimised from a real API spec.

Create files specs/poc2.sysl and specs/items.yaml as follows:

$ cat specs/poc2.sysl
import items.yaml as ItemCatalog

SomeEnterprise :: SomePlatform :: SomeService:
    @package="itembroker"

    DoSomething:
        ItemCatalog <- GET /items
        return ok <: string

$ cat specs/items.yaml
swagger: '2.0'
info:
  title: Item Catalog
  version: v1
basePath: '/'
schemes:
  - http
paths:
  /items:
    get:
      operationId: Get ALL Items
      consumes:
        - application/json
      produces:
        - application/json
      parameters:
        - name: include
          required: false
          in: query
          type: array
          items:
            $ref: '#/definitions/edible_items'
      responses:
        '200':
          description: payload
          schema:
            $ref: '#/definitions/payload'
  '/items/{itemCode}':
    get:
      operationId: Get Specific Item
      consumes:
        - application/json
      produces:
        - application/json
      parameters:
        - name: itemCode
          required: true
          in: path
          type: string
        - name: include
          required: false
          in: query
          type: array
          items:
            $ref: '#/definitions/topological_items'
      responses:
        '200':
          description: payload
          schema:
            $ref: '#/definitions/payload'
definitions:
  edible_items:
    description: edible item types
    enum:
      - sour
      - sweet
      - cheesy
      - salty
      - spicy
    type: string
  payload:
    title: successful response payload
    type: object
    properties:
      matching_items:
        type: array
        items:
          type: object
          additionalProperties: true
  topological_items:
    description: topological item types
    enum:
      - sphere
      - donut
      - pretzel
      - lobster_pot
    type: string

observe that the Item Catalog API spec defines two endpoints -- each has a query parameter named "include" with a different schema.

generate a sysl model.json a bunch of times using the importer:

$ sysl pb --mode json --root . specs/poc2.sysl --output z0.json
$ sysl pb --mode json --root . specs/poc2.sysl --output z1.json
$ sysl pb --mode json --root . specs/poc2.sysl --output z2.json
$ sysl pb --mode json --root . specs/poc2.sysl --output z3.json
$ sysl pb --mode json --root . specs/poc2.sysl --output z4.json
$ sysl pb --mode json --root . specs/poc2.sysl --output z5.json

see if any outputs have different content (they should all be same if the importer was deterministic) and if so, diff a pair of them:

$ md5sum z*.jzon

eee186b9a8a0c791c532d13eda411951  z0.json
f3b8d71c4b8ad26aca138d3a619bb254  z1.json
17b33e2ff2470749f09c4905ca8d5b56  z2.json
f3b8d71c4b8ad26aca138d3a619bb254  z3.json
f3b8d71c4b8ad26aca138d3a619bb254  z4.json
f3b8d71c4b8ad26aca138d3a619bb254  z5.json

$ diff -U 5 --unified z0.json z2.json
--- z0.json 2021-03-03 16:43:14.000000000 +1100
+++ z2.json 2021-03-03 16:43:19.000000000 +1100
@@ -242,11 +242,11 @@
          "include"
         ]
        },
        "ref": {
         "path": [
-         "topological_items"
+         "edible_items"
         ]
        }
       },
       "sourceContext": {
        "file": "specs/items.yaml",
@@ -443,6 +443,6 @@
      "col": 34
     }
    }
   }
  }
-}
+}
\ No newline at end of file

Caveat -- issue with above example
according to swagger editor, the items.yaml spec isn't a valid swagger 2.0 document, there are two errors:
Structural error at paths./items.get.parameters.0.items
should NOT have additional properties
additionalProperty: $ref
Jump to line 21

Structural error at paths./items/{itemCode}.get.parameters.1.items
should NOT have additional properties
additionalProperty: $ref
Jump to line 44

Expected behavior

sysl importer output is deterministic
output model.json uses correct items schema for each endpoint

Actual behavior

sysl importer output is nondeterministic
output model.json incorrectly uses a single arbitrarily-chosen items schema for both endpoints

Your Environment
$ sysl info
Build:
  Version      : v0.254.0
  Git Commit   : a5a64cd82c67781f94fe5dd75b846b6446b2783c
  Date         : 2020-10-25T23:53:41Z
  Go Version   : go1.14.8 darwin/amd64
  OS           : darwin/amd64

note: this problem appears present with sysl-go 0.175.0 and sysl-go 0.180.0, which internally use sysl version 0.258.0

Same problem is reproducible where the input swagger 2 spec is a valid swagger 2 spec according to swagger editor.
here is a cleaned up sample spec that reproduces the issue:
swagger: '2.0'
info:
  title: Item Catalog
  version: v1
basePath: '/'
schemes:
  - http
paths:
  /items:
    get:
      operationId: Get ALL Items
      consumes:
        - application/json
      produces:
        - application/json
      parameters:
        - name: x
          in: query
          required: false
          type: array
          items:
            type: string
      responses:
        '200':
          description: payload
          schema:
            $ref: '#/definitions/payload'
  '/items/{itemCode}':
    get:
      operationId: Get Specific Item
      consumes:
        - application/json
      produces:
        - application/json
      parameters:
        - name: itemCode
          required: true
          in: path
          type: string
        - name: x
          in: query
          required: false
          type: array
          items:
            type: number
      responses:
        '200':
          description: payload
          schema:
            $ref: '#/definitions/payload'
definitions:
  payload:
    title: successful response payload
    type: object
    properties:
      matching_items:
        type: array
        items:
          type: object
          additionalProperties: true

both endpoints have an optional query parameter named x. one endpoint requires that x, if given, be an array of string. the other endpoint requires that x, if given, be an array of number.
when sysl importer is run it produces a model.json that arbitrarily picks one of the schemas and uses them for both endpoints, which is both nondeterministic and defective
$ sysl pb --mode json --root . specs/poc2.sysl --output z0.json
$ sysl pb --mode json --root . specs/poc2.sysl --output z1.json
$ sysl pb --mode json --root . specs/poc2.sysl --output z2.json
$ sysl pb --mode json --root . specs/poc2.sysl --output z3.json
$ sysl pb --mode json --root . specs/poc2.sysl --output z4.json
$ sysl pb --mode json --root . specs/poc2.sysl --output z5.json
$ md5sum z*.json
c8854a1487131eafed1e5fd0c1e336e7  z0.json
6524dbd714b1be7b222618b4c69a2add  z1.json
c8854a1487131eafed1e5fd0c1e336e7  z2.json
c8854a1487131eafed1e5fd0c1e336e7  z3.json
6524dbd714b1be7b222618b4c69a2add  z4.json
c8854a1487131eafed1e5fd0c1e336e7  z5.json
$ diff -U 10 --unified z0.json z1.json
--- z0.json 2021-03-03 17:09:46.000000000 +1100
+++ z1.json 2021-03-03 17:09:48.000000000 +1100
@@ -277,21 +277,21 @@
        "col": 4
       },
       "end": {
        "line": 30,
        "col": 4
       }
      }
     },
     "x": {
      "sequence": {
-      "primitive": "FLOAT",
+      "primitive": "STRING",
       "sourceContext": {
        "file": "specs/items.yaml",
        "start": {
         "line": 36,
         "col": 4
        },
        "end": {
         "line": 38
        }
       }


comments: sync doc content

Q
A

Is bugfix?
❌

New feature?
❌

Breaks BC?
❌

Tests pass?
✔

Fixed issues
just update comments

According to the content of the document, update comments, making more meaningful.

Thank you for your suggestion but I think we don't need to provide specific examples for setters.


added script for sms_loc

Pull Request Template
script name -sms_loc.py
Brief about script

This script uses Fast2Sms Services to send sms
Rest information is in README section of this script

Issue no.(must) - #240
Self Check(Tick After Making pull Request)

[x] This issue was assigned to me.
[x] One Change in one Pull Request
[x] My file is in proper folder (Name of folder should be in lowercase with no space in between)
[x] I am following clean code and Documentation and my code is well linted with flake8.
[x] I have added README.md and requirements.txt with my script

If issue was not assigned to you Please don't make a PR. It will marked as invalid.

hey @pawangeek  i dont't know why  i am getting spellcheck error for the changes that i did not make

there is some spellcheck error while making PR for the  " zip_password_cracker '' folder and this script does not belongs to me
what should i do kindly guide @pawangeek

Seems to be perfect @bunnysworld

@all-contrubutors add @bunnysworld for code

@all-contributors add @bunnysworld for code


VariantAnnotationEngine

should be enough for HaplotypeCaller

@droazen please review. this is a minimal annotation engine that should suffice for HC. We will revisit later when we port VariantAnnotator itself

perhaps @ldgauthier can help review this?

@droazen Can you review for good programming style?  I reviewed the big picture stuff, but my Java isn't that great.

So the GATK4 VariantAnnotator hasn't been ported yet right?  @vdauwera and I just had a discussion about barring VariantAnnotator from annotating anything requiring read data in GATK4.

+1. I'm not planning to support the scenario of annotating a VCF by using a BAM as auxiliary file. Unless someone vehemently protests and gives a good rationale.

There may be some legitimate reasons to do it (I will review what we currently enable) but my stance going in is that we should avoid it.

@droazen this is needed for HC. can you review?

@droazen any progress on this? genotyper is blocked by this

@akiezun Will review this one within the next day.

any update here? I'd like to move on the genotyper

Will be reviewed this week.

@akiezun Apologies for the delay on this -- was unexpectedly out of commission last Friday. Will review this now!

First-pass review complete -- back to @akiezun

back to @droazen

ok, done. back to @droazen

Second-pass review complete. Please rebase and merge after addressing this round of comments. Back to @akiezun

as discussed with @droazen, I'm not touching this PR until he's done with his experiment. Reassigning to make it clear that I'm not working on this.

I've backed up the state of these HC branches and have started the process of merging them with my engine work into a runnable tool. Feel free to address to code review comments whenever you like, as it won't affect my work now. Back to @akiezun

Bravo Adam!  That's amazing!


Added webbrowser artifact paths for Windows and Linux

Added paths for Microsoft Edge on Linux

History

Firefox snap path support for Linux
Additional Brave Browser paths for Linux

Cache

Additional paths to ChromiumCache for Windows, and Linux
Additional paths for FirefoxCache for Windows, and Linux
Additional paths for FirefoxCache for snap on Linux

Cookies

Additional paths for ChromeCookies for Windows, and Linux

@kaiqtpi thx for the additions


ModelTransformation -> ItemModelTransformations

This class does not handle block model transformations, and it also is not a single transformation over a model, but rather several possible transformations over an item model depending on context (ModelTransformation.Mode). This class makes the fabric rendering api look much more complicated than it actually is.

Other mappings might benefit from a change as well, such as as UnbakedModel#getTransformation -> UnbakedModel#getItemModelTransformations.

Another mapping that would need changing: net.minecraft.client.model.json.ModelRotation -> net.minecraft.client.model.json.BlockModelTransformation`

Another mapping that would need changing: net.minecraft.client.model.json.ModelRotation -> net.minecraft.client.model.json.BlockModelTransformation`

Another issue related to this: net.minecraft.client.render.model.ModelRotation is called BlockModelRotation in the code, and this also seems to make more sense (It only handles 90 degree rotations)

Another issue related to this: net.minecraft.client.render.model.ModelRotation is called BlockModelRotation in the code, and this also seems to make more sense (It only handles 90 degree rotations)


[🐸 Frogbot] Update version of github.com/cloudflare/circl to 1.3.3

Upgrade github.com/cloudflare/circl to 1.3.3
What is Frogbot?

updated from upstream


Update: Bull Market

A bull market is a term that describes the condition of a financial market in which prices are rising or expected to rise. This term usually refers to the stock market, but can be applied to anything traded. Included are bonds, real estate, commodities, and cryptocurrencies.
Since prices continuously rise and fall during trading, the classification of "bull market" is reserved for extended amounts of time where a large portion of prices are rising.

WOOHOOO!!!!!!! Congrats @kji304 on your first Pull Request!
 Thanks!!


[Fix272] Updating with latest algolia docsearch configs

Search was broken earlier, fixing it with updated docsearch configs

Signed-off-by: Jayesh Kumar<EMAIL_ADDRESS>

https://github.com/algolia/docsearch-configs/blob/master/configs/litmuschaos.json has the default style configs. In case, some customizations are required - we need to send a PR to this file.
https://docsearch.algolia.com/docs/styling/ has the styling guide - not hands on with CSS, so did not touch defaults :) but welcome to improve on it and send PR to above file.

Awesome @k8s-dev !! Have created a new issue for improvements.  Thank you !! 👍


WIP: Generate an ephemeral CA and have it distribute TLS creds.

Signed-off-by: Brian Smith<EMAIL_ADDRESS>

I'm not totally on board with the decision to watch deployment events instead of pod events. It's more complicated, and it's an overall reduction in functionality since we lose support for non-deployment pods. Watching owners feels like an optimization that can implemented more holistically after the fact, but we can get by with pod and replicaset watches for now, and that will clean this up a lot. If you don't mind, I'm going to poke at trying to get this branch to work in that way.

The initial reason I switched to watching pod owners is because I didn't know how to reliably get the pod owner's name starting with the pod object. I know it's possible but my understanding is that you are working on another PR to allow that kind of navigation. If/when we can get the pod owner name from the pod, I think it would probably make sense to watch pods only again.


Updated the doc for the murinae Cactus alignment

Thank you. @nerdstrike or @premanand17, care to hit merge please?


chore: moving unused functions to improve code coverage

There are a lot of functions that are not used in the new NoisePy, from the Jiang and Denolle 2019. I am putting them into an isolated directory at src/noisepy/old so that codecov test is to preformed on these uncovered codes.

This should improve the codecov of noise_module as mentioned in #250.
I am also adding more tests for stack and cross-correlation module.

Could you rename "old" to "functions_2019" .

Yes

Could you explain why iflag is left commented in your PR?

There is a problem here. iflag checks if we got CCF in every component pair. And it checks all 9 components: EE, EN, EZ, NE, NN, NZ, ZE, ZN, ZZ. However, we only save the independent 6 component so that the rest 3 will always be empty, making iflag ending with 0. In the following codes where iflag is used, the rotation is never performed.


Fix ship level display in player utils

This has been a long-standing display glitch, which has shown the levels of owned ships always by 1 lower than they should be.
To clarify: all ship data from the player.json game export as well as the ship_schematics.json start counting levels at 0 (to a maximum of 9 for a 5* ship). This has resulted in ships being shown as level 9 / 9 when they are maxed, but more importantly owned 1 / 10 and un-owned 0 / 10 ships have both been erroneously displayed as 0 / 9.

There are 2 hard problems in computer science: cache invalidation, naming things, and off-by-1 errors.


Also delete post comments when deleting a post

Review your code.
actually, there is no such comment_post_id. you have to solve the issue using foreign keys

I've used this as a reference https://github.com/chaitak-gorai/blogbook/blob/main/databases/import.sql

true, fixed now
On Thu, 7 Oct 2021 at 23:17, Chaitak Gorai @.***> wrote:

The query you have given in mysqli_query function down was wrong. it will
be comments_query
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/chaitak-gorai/blogbook/pull/73#issuecomment-938124078,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ABCKTPASJVHGIQYGFDKGHVDUFX55BANCNFSM5FR4NM6Q
.
Triage notifications on the go with GitHub Mobile for iOS
https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675
or Android
https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.


Correct Bounding Box Issue

YOLOv5 produces output bounding boxes of the format TLWH (top-left, width, height). The bounding boxes deepsort takes as input are of the format XYWH (center x, y, width, height). During the deepsort run() function the bounding boxes' features are determined using the XYWH format, then they are converted to TLWH format. The TLWH format is used to create a Detection object which is updated in the tracker.predict() method. The output boxes are saved as a TLWH format bounding box and then converted to XYWH format bounding box.
The goal of this story will be to not only correct the bounding boxes, but also to ensure that the least number of conversions between boxes are done. Another goal would be to remove unused conversion functions.

Here are some things that I have found in chronological order:

In detections.py, the method 'yolo_predict', I could not figure out the format of the output.
In detections.py the method 'yolo_predict', calls method nm_suppression (defined in general.py), which states that it takes in images of format xywh, converts to xyxy. It then does some computation on xyxy, and outputs in xyxy.
In detections.py in method 'yolo_predict', a method is called that scales the xyxy coordinates.
In detections.py in method 'yolo_predict', WE convert xyxy to tlwh.
In deep_sort/deep_sort.py in method 'update', WE treat the coordinates as though they are in xywh, when they are in tlwh! So we convert remove the xywh to tlwh convesion.
In deep_sort/deep_sort.py in method 'update', WE convert the outputs of the tracker from tlwh to xywh and return them.
In trafficrtracker.py in method 'run', WE convert the outputs of the step 6 (from the update method) to tlwh format.

In the attempt1 branch I just created, I left detections.py alone, but fixed the method 'update' and I remved the useless converion of tlwh-xywh-tlwh ( found in steps 6-7)

Fixed 'update' so that it treats the inputs as though they are in tlwh format.
Made 'update' output in tlwh.
Updated traffictracker.py to treat the outputs of update as though they were in xywh.


add reusable examples

I've built this out somewhat, still missing:

[ ] that it also works on "normal" @examples (no reason it shouldn't just takes the last return)
[ ] passing on @reusableExamples to @examples for all other treatment
[ ] renaming @resuableExamples to @namedExamples which would be more appropriate.

‼ but, more importantly, this is very likely a dead end 😔.

you can't rely on roxygen2 comments when the package is R CMD checked, or tests are otherwise run against an installed version.
Disallowing this / skipping (via testthat::is_checking()) would fundamentally break how tests are supposed to work.
The path weirdness is already showing; not sure you can reliably identify the package source path from all contexts in which a test is run.
And again, this whole thing needs the roxygen2 source to be available.
We could write out the example calls to a separate file (just like *.Rd files get rendered), but that's just more complexity and versioning hell.
Also, the UX is a bit awkward already.
I think a more natural place to create the objects to be tested is inside the testthat/ folder.
the awkwardness already shows in dealing with p


portable SIMD: basic binops

First steps towards https://github.com/rust-lang/miri/issues/1912. Requires https://github.com/rust-lang/rust/pull/90999.

@bors r+

:pushpin: Commit 84027dcd228848e29ce3fa552caa615a9b7d5de5 has been approved by RalfJung

:hourglass: Testing commit 84027dcd228848e29ce3fa552caa615a9b7d5de5 with merge 763a4455ac9f411a336705b1a507a79ccf458913...

:sunny: Test successful - checks-actions
Approved by: RalfJung
Pushing 763a4455ac9f411a336705b1a507a79ccf458913 to master...


Link to 1.6.5 is not working

The link provided to 1.6.5 (https://github.com/stefansl/image-shrinker/releases/download/v1.6.5/image-shrinker-1.6.5.dmg) download is not working.

Where do you see this link? 1.6.4 is the latest version that appears to be available here.


Every flutter command shown "Waiting for another flutter command to release the startup lock...", but none dart process running

Mac OSX 10.15.7, MacBook Pro (Retina, 15-inch, Mid 2015)
Used git clone flutter, stable branch checked commit db747aa1331bd95bc9b3874c842261ca2d302cd5 (HEAD -> stable, tag: 2.10.1, origin/stable, origin/flutter-2.8-candidate.16)
~Upgrade dart version to Dart SDK version: 2.13.0 (stable) (Wed May 12 12:45:49 2021 +0200) on "macos_x64" by brew~
reopen terminal, always shown 'Waiting for another flutter command to release the startup lock...' when any flutter's command executed
flutter's dart used

Logs
None logs file or other info shown
Other

None dart process running
Alway dart --version shown Waiting for another flutter command to release the startup lock...

Hi @mitolH, Thanks for filing the issue. I am unable to reproduce the issue. Does this happen frequently or was this a rare case?
Last login: Mon Feb 14 09:53:21 on console
mahesh@Maheshs-MacBook-Air-M1 ~ % cd ~/Desktop
mahesh@Maheshs-MacBook-Air-M1 Desktop % git clone https://github.com/flutter/flutter.git
Cloning into 'flutter'...
remote: Enumerating objects: 357122, done.
remote: Total 357122 (delta 0), reused 0 (delta 0), pack-reused 357122
Receiving objects: 100% (357122/357122), 178.67 MiB | 187.00 KiB/s, done.
Resolving deltas: 100% (274086/274086), done.
Updating files: 100% (6178/6178), done.
mahesh@Maheshs-MacBook-Air-M1 Desktop % cd flutter
mahesh@Maheshs-MacBook-Air-M1 flutter % git checkout db747aa1331bd95bc9b3874c842261ca2d302cd5
Note: switching to 'db747aa1331bd95bc9b3874c842261ca2d302cd5'.

You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
state without impacting any branches by switching back to a branch.

If you want to create a new branch to retain commits you create, you may
do so (now or later) by using -c with the switch command. Example:

  git switch -c <new-branch-name>

Or undo this operation with:

  git switch -

Turn off this advice by setting config variable advice.detachedHead to false

HEAD is now at db747aa133 [flutter_releases] Flutter stable 2.10.1 Framework Cherrypicks (#98091)
mahesh@Maheshs-MacBook-Air-M1 flutter %

on reopening the terminal
Last login: Mon Feb 14 14:14:15 on ttys002
mahesh@Maheshs-MacBook-Air-M1 ~ % cd ~/Desktop/flutter
mahesh@Maheshs-MacBook-Air-M1 flutter % cd bin
mahesh@Maheshs-MacBook-Air-M1 bin % flutter doctor -v
[✓] Flutter (Channel stable, 2.10.1, on macOS 12.1 21C52 darwin-arm, locale
    en-GB)
    • Flutter version 2.10.1 at /Users/mahesh/Documents/flutter
    • Upstream repository https://github.com/flutter/flutter.git
    • Framework revision db747aa133 (5 days ago), 2022-02-09 13:57:35 -0600
    • Engine revision ab46186b24
    • Dart version 2.16.1
    • DevTools version 2.9.2

[✓] Android toolchain - develop for Android devices (Android SDK version 31.0.0)
    • Android SDK at /Users/mahesh/Library/Android/sdk
    • Platform android-31, build-tools 31.0.0
    • ANDROID_HOME = /Users/mahesh/Library/Android/sdk
    • Java binary at: /Applications/Android Studio.app/Contents/jre/jdk/Contents/Home/bin/java
    • Java version OpenJDK Runtime Environment (build 11.0.8+10-b944.6916264)
    • All Android licenses accepted.

[✓] Xcode - develop for iOS and macOS (Xcode 13.2.1)
    • Xcode at /Applications/Xcode.app/Contents/Developer
    • CocoaPods version 1.10.2

[✓] Chrome - develop for the web
    • Chrome at /Applications/Google Chrome.app/Contents/MacOS/Google Chrome

[✓] Android Studio (version 4.2)
    • Android Studio at /Applications/Android Studio.app/Contents
    • Flutter plugin can be installed from:
      🔨 https://plugins.jetbrains.com/plugin/9212-flutter
    • Dart plugin can be installed from:
      🔨 https://plugins.jetbrains.com/plugin/6351-dart
    • Java version OpenJDK Runtime Environment (build 11.0.8+10-b944.6916264)

[✓] IntelliJ IDEA Community Edition (version 2021.2.1)
    • IntelliJ at /Applications/IntelliJ IDEA CE.app
    • Flutter plugin version 61.2.4
    • Dart plugin version 212.5080.8

[✓] VS Code (version 1.63.2)
    • VS Code at /Applications/Visual Studio Code.app/Contents
    • Flutter extension version 3.34.0

[✓] Connected device (3 available)
    • Redmi K20 Pro (mobile) • <IP_ADDRESS>:5555 • android-arm64  • Android 11 (API 30)
    • macOS (desktop)        • macos            • darwin-arm64   • macOS 12.1 21C52 darwin-arm
    • Chrome (web)           • chrome           • web-javascript • Google Chrome 98.0.4758.80

[✓] HTTP Host Availability
    • All required HTTP hosts are available

• No issues found!


[Question] Deprecating Facebook Login support on Android WebViews

I recently received an email that the facebook sdk will deprecates the android webview. Does this library prepare this issue?
🐛 Bug Report

To Reproduce

Expected Behavior

Code Example

Environment

I also received the email. But I don't know how to solve it.
Here is some info.
https://developers.facebook.com/docs/facebook-login/android/deprecating-webviews

Using SDK 8+? :heavy_check_mark:

https://github.com/thebergamo/react-native-fbsdk-next/blob/b550f106ccf66cbda4480c51a9ec81f58196806b/android/build.gradle#L47

Ensure that you are NOT setting LoginBehavior=WEB_VIEW_ONLY.

We are not?

Ensure that your app has configured support for Custom Tabs properly. [....] You should see a window open in the external browser rather than in a native WebDialog.

It does for me.

If you have already completed steps 1–3 and have released your app to users, users who are on older versions of your application will see the following error message when they attempt to login from a webview, prompting them to upgrade to the newest version of your application.

You must release a new version if you need to do 1-3 above.

If your app is used primarily on devices which are unable to host the login experience in an external browser, we encourage you to integrate Device Login as an alternative login mechanism.

Not in scope for this repository I think.
I do not believe there is anything actionable for this module here? Am I missing something?

I've been testing other things today and I was able to confirm all of my above points.
There is no action for us here, I don't think.


Flush writing list to transport list when destroying the stream

Can one of the admins verify this patch?

Can one of the admins verify this patch?

May not be the right fix. Close for now.


ssh remote url can have custom port

Same as https://github.com/harrisoncramer/gitlab.nvim/pull/220, and add a test case.

Thank you! Can you please target the develop branch instead of main? And is this enough for you to connect to a custom port or is there additional configuration required?
If there are more steps we probably just want to call this out in the README for users.

Thank you! Can you please target the develop branch instead of main? And is this enough for you to connect to a custom port or is there additional configuration required?
Done.
If there are more steps we probably just want to call this out in the README for users.

No additional configuration is needed, I have used the fork version, it works well.


Main Branch Name

Hey there, was the main branch name recently changed from master to main?
I've noticed that while installing the Achilles R package from github, it's failing since it default will pull from branch "master". I know the build worked sometime last week- i'm assuming before any changes recently made.
If it was recently changed- I'm not sure if the better fix is for y'all to change your branch name back, or update the Achilles repo to reference the new branch name.

Not exactly sure what happened, but the branch has been renamed to master, as it should be named, and that should resolve the issue with the reference.  Thanks for pointing that out.


multiuse problem?

I'm using a full-screen dialog to catch mobiscroll-dialogs, so they're displayed in front.
When I open/close one of those, reopening it again seems to fail.
When I change the css for dialogs that are not open from display:none to visibility:hidden, things seem to work fine...

Can you provide a clear repro case?
On 11 August 2017 at 02:34, ray007<EMAIL_ADDRESS>wrote:

I'm using a full-screen dialog to catch mobiscroll-dialogs, so they're
displayed in front.
When I open/close one of those, reopening it again seems to fail.
When I change the css for dialogs that are not open from display:none to
visibility:hidden, things seem to work fine...
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/GoogleChrome/dialog-polyfill/issues/153, or mute the
thread
https://github.com/notifications/unsubscribe-auth/AAHRkMxKSiiq_oQ3lkErHqVKHYXdfR9mks5sXCA8gaJpZM4O0b3H
.


filter with Multiple conditions request

Is your feature request related to a problem? Please describe.
Try to use query method with multiple condition, but fail. only support for single condition filter.
        df2 = df.query({
            "column": "result",
            "is": "!=",
            "to": "A"
        })

Describe the solution you'd like
Like pandas solution df.loc[(df['Salary_in_1000']>=100) & (df['Age']< 60) & (df['FT_Team'].str.startswith('S')),['Name','FT_Team']]
is there alternative method for filter with Multiple conditions?  Thanks in advance.

@jasonwu513 This is not supported yet, but I will add it in the new version. You can track progress here https://github.com/opensource9ja/danfojs/pull/235

Added in latest version v0.3.0


Support Multibyte UART Accesses

Revise the console device handlers in Main.hs to support multibyte read/write requests. Then revise the UART device PMA's to reflect this expanded access.

2d8397e


Double item with first outline

When creating the first outline in the ios app, I generated a title called "Testing" and added a tag called "Test"
Then I added an item to the outline called "Hey jude" which was autocorrected to "Hey Jude".
It then created two items called "Hey Jude"
I cannot reproduce this on subsequent item creations or in subsequent outlines/collections.

I've never been able to recreate this. I think I'm going to chalk it up to early release glitches and address it if we ever see it again.


[DO NOT MERGE] Worked on solving Light DOM race condition on Travis

Jira
https://pegadigitalit.atlassian.net/browse/DS-28
Summary
Debugging the Travis build failures by restructuring the tests
Details
(Explain the changes in enough detail fo reviewers to understand. Raise any questions for reviewers to consider.)

Closing this branch, it was for testing purposes


recipe updates for indigo distribution on 2018-06-07

This pull request updates the recipes to the current versions released on 2018-06-07. This release of the indigo distribution was announced in https://discourse.ros.org/t/new-packages-for-indigo-2018-06-07/5048.

bitbake core-image-ros-world built successfully on this build configuration:
Build Configuration:
BB_VERSION           = "1.37.0"
BUILD_SYS            = "x86_64-linux"
NATIVELSBSTRING      = "ubuntu-16.04"
TARGET_SYS           = "i586-oe-linux"
MACHINE              = "qemux86"
DISTRO               = "nodistro"
DISTRO_VERSION       = "nodistro.0"
TUNE_FEATURES        = "m32 i586"
TARGET_FPU           = ""
meta                 = "master:23f15c63777020f5d43b070a1eb2bcf246c19ff8"
meta-oe
meta-python
meta-multimedia      = "master:bb57bac845f3cd1634862fa9868bc8e294ba74a9"
meta-ros             = "indigo-updates:3d0858491fc3512e09b88fbcfbffd33ef2b77812"

CI ran successfully; I will merge the pull request.


Bin for windows x64 get crash

<IP_ADDRESS> get crash, but <IP_ADDRESS> is OK, I debuged, find out that:
in <IP_ADDRESS>, the rust app call _API.SciterCreateWindow, which is NULL, so the latest ISciterAPI changed?

https://github.com/sciter-sdk/rust-sciter/issues/107

@lynnux Sciter SDK version is <IP_ADDRESS>.
Is it Sciter.JS or Sciter.TIS?
Is it Sciter.Lite?

@pravic I download sciter.dll from https://github.com/c-smile/sciter-js-sdk/blob/main/bin/windows/x64/sciter.dll, and sciter-rs = "0.5.55", It's OK after set sciter-rs = {git="https://github.com/sciter-sdk/rust-sciter.git"}, so your commit are not plublish yet, I should close this issue

Oh, right. Thanks.

Published a release as well.


Issueing a SIGHUP with a failed profile breaks the next SIGHUP

If one issues a SIGHUP to reload profiles and one of the profiles does not parse properly, the handler becomes broken and it's impossible to reload again (and thus fix the error) and the daemon must be restarted.

Fixed in 5e73792


Assigning image to tab, followup.

Currently using pods - 'XLPagerTabStrip', '~> 7.0'  Xcode 8.0 swift 3
Currently experiencing a similar issue with setting the image as mentioned in a previous thread #404
I was confused by the suggested solution being pointing to the latest commit in master branch. How exactly is this done? In my podfile I have it set as it is written above.

hey @davilaeric !
You can do that with pod 'XLPagerTabStrip', :git => 'https://github.com/xmartlabs/XLPagerTabStrip.git', :branch => 'master'
Cheers


Garlicion mining error

This issue tracker is only for technical issues related to garlicoin-core.
General garlicoin questions and/or support requests and are best directed to the garlicointalk.io forums.
For reporting security issues, please contact the Garlicoin developers on the #garlicoin-dev Freenode IRC channel or alternatively you can email us at<EMAIL_ADDRESS>Describe the issue
I have installed the garlicion mining program and I have come across two errors saying "qt/test/test_garlicoin-qt" and
"test/test_garlicoin"
it sends me to these sites
"See src/test-suite.log
Please report to https://github.com/garlicoin-project/garlicoin/issues"
if i go to these addresses nothing comes up showing me how to fix them and i was wondering how to fix these errors

Looks like the links were incorrectly changed - here is the official repo https://github.com/GarlicoinOrg/Garlicoin


Merge pull request #31 from BluNite/BluNite-patch-1

Merge pull request #30 from BluNite/main

blu_nite


Display optimistic fields violations for single expense reports

Details

Fixed Issues

$ https://github.com/Expensify/App/issues/46215
$ https://github.com/Expensify/App/issues/46223
PROPOSAL:
Tests

Create a workspace with Report Fields enabled (Workspaces -> Your workspace -> More features -> Report fields)
Add a List type field with some initial value
Add another field without an initial value
Create a single expense (split, regular or track)
Go to created report and see fields are displayed
See no error for your List field with default value
See the error for your other field without a default value

Offline tests

QA Steps

Create a workspace with Report Fields enabled (Workspaces -> Your workspace -> More features -> Report fields)
Add a List type field with some initial value
Add another field without an initial value
Create a single expense (split, regular or track)
Go to created report and see fields are displayed
See no error for your List field with default value
See the error for your other field without a default value

PR Author Checklist

[x] I linked the correct issue in the ### Fixed Issues section above
[x] I wrote clear testing steps that cover the changes made in this PR

[x] I added steps for local testing in the Tests section
[x] I added steps for the expected offline behavior in the Offline steps section
[x] I added steps for Staging and/or Production testing in the QA steps section
[x] I added steps to cover failure scenarios (i.e. verify an input displays the correct error message if the entered data is not correct)
[x] I turned off my network connection and tested it while offline to ensure it matches the expected behavior (i.e. verify the default avatar icon is displayed if app is offline)
[x] I tested this PR with a High Traffic account against the staging or production API to ensure there are no regressions (e.g. long loading states that impact usability).

[x] I included screenshots or videos for tests on all platforms
[x] I ran the tests on all platforms & verified they passed on:

[x] Android: Native
[x] Android: mWeb Chrome
[x] iOS: Native
[x] iOS: mWeb Safari
[x] MacOS: Chrome / Safari
[x] MacOS: Desktop

[x] I verified there are no console errors (if there's a console error not related to the PR, report it or open an issue for it to be fixed)
[x] I followed proper code patterns (see Reviewing the code)

[x] I verified that any callback methods that were added or modified are named for what the method does and never what callback they handle (i.e. toggleReport and not onIconClick)
[x] I verified that the left part of a conditional rendering a React component is a boolean and NOT a string, e.g. myBool && <MyComponent />.
[x] I verified that comments were added to code that is not self explanatory
[x] I verified that any new or modified comments were clear, correct English, and explained "why" the code was doing something instead of only explaining "what" the code was doing.
[x] I verified any copy / text shown in the product is localized by adding it to src/languages/* files and using the translation method

[x] If any non-english text was added/modified, I verified the translation was requested/reviewed in #expensify-open-source and it was approved by an internal Expensify engineer. Link to Slack message:

[x] I verified all numbers, amounts, dates and phone numbers shown in the product are using the localization methods
[x] I verified any copy / text that was added to the app is grammatically correct in English. It adheres to proper capitalization guidelines (note: only the first word of header/labels should be capitalized), and is either coming verbatim from figma or has been approved by marketing (in order to get marketing approval, ask the Bug Zero team member to add the Waiting for copy label to the issue)
[x] I verified proper file naming conventions were followed for any new files or renamed files. All non-platform specific files are named after what they export and are not named "index.js". All platform-specific files are named for the platform the code supports as outlined in the README.
[x] I verified the JSDocs style guidelines (in STYLE.md) were followed

[x] If a new code pattern is added I verified it was agreed to be used by multiple Expensify engineers
[x] I followed the guidelines as stated in the Review Guidelines
[x] I tested other components that can be impacted by my changes (i.e. if the PR modifies a shared library or component like Avatar, I verified the components using Avatar are working as expected)
[x] I verified all code is DRY (the PR doesn't include any logic written more than once, with the exception of tests)
[x] I verified any variables that can be defined as constants (ie. in CONST.js or at the top of the file that uses the constant) are defined as such
[x] I verified that if a function's arguments changed that all usages have also been updated correctly
[x] If any new file was added I verified that:

[x] The file has a description of what it does and/or why is needed at the top of the file if the code is not self explanatory

[x] If a new CSS style is added I verified that:

[x] A similar style doesn't already exist
[x] The style can't be created with an existing StyleUtils function (i.e. StyleUtils.getBackgroundAndBorderStyle(theme.componentBG))

[x] If the PR modifies code that runs when editing or sending messages, I tested and verified there is no unexpected behavior for all supported markdown - URLs, single line code, code blocks, quotes, headings, bold, strikethrough, and italic.
[x] If the PR modifies a generic component, I tested and verified that those changes do not break usages of that component in the rest of the App (i.e. if a shared library or component like Avatar is modified, I verified that Avatar is working as expected in all cases)
[x] If the PR modifies a component related to any of the existing Storybook stories, I tested and verified all stories for that component are still working as expected.
[x] If the PR modifies a component or page that can be accessed by a direct deeplink, I verified that the code functions as expected when the deeplink is used - from a logged in and logged out account.
[x] If the PR modifies the UI (e.g. new buttons, new UI components, changing the padding/spacing/sizing, moving components, etc) or modifies the form input styles:

[x] I verified that all the inputs inside a form are aligned with each other.
[x] I added Design label and/or tagged @Expensify/design so the design team can review the changes.

[x] If a new page is added, I verified it's using the ScrollView component to make it scrollable when more elements are added to the page.
[x] If the main branch was merged into this PR after a review, I tested again and verified the outcome was still expected according to the Test steps.

Screenshots/Videos

Android: Native

https://github.com/user-attachments/assets/8cc5ee1b-eeb9-4bf7-b951-e445bd9010c9

Android: mWeb Chrome

https://github.com/user-attachments/assets/53b18b83-0d88-4625-85c9-fef2c8d7d67c

iOS: Native

https://github.com/user-attachments/assets/a61f0957-9cf5-4fc1-b474-8c38f34f1f56

iOS: mWeb Safari

https://github.com/user-attachments/assets/d48b2146-5658-4dfb-9428-c2f1fd33f842

MacOS: Chrome / Safari

https://github.com/user-attachments/assets/0e3c9039-5881-4479-bb73-2cb7ef5c39df

MacOS: Desktop

https://github.com/user-attachments/assets/d003261c-3f6b-4037-9cfb-b7d2c53f86f2

Note that I added optimistic field violations to Track expenses because they were missing in this feature

Reviewer Checklist

[ ] I have verified the author checklist is complete (all boxes are checked off).
[ ] I verified the correct issue is linked in the ### Fixed Issues section above
[ ] I verified testing steps are clear and they cover the changes made in this PR

[ ] I verified the steps for local testing are in the Tests section
[ ] I verified the steps for Staging and/or Production testing are in the QA steps section
[ ] I verified the steps cover any possible failure scenarios (i.e. verify an input displays the correct error message if the entered data is not correct)
[ ] I turned off my network connection and tested it while offline to ensure it matches the expected behavior (i.e. verify the default avatar icon is displayed if app is offline)

[ ] I checked that screenshots or videos are included for tests on all platforms
[ ] I included screenshots or videos for tests on all platforms
[ ] I verified tests pass on all platforms & I tested again on:

[ ] Android: Native
[ ] Android: mWeb Chrome
[ ] iOS: Native
[ ] iOS: mWeb Safari
[ ] MacOS: Chrome / Safari
[ ] MacOS: Desktop

[ ] If there are any errors in the console that are unrelated to this PR, I either fixed them (preferred) or linked to where I reported them in Slack
[ ] I verified proper code patterns were followed (see Reviewing the code)

[ ] I verified that any callback methods that were added or modified are named for what the method does and never what callback they handle (i.e. toggleReport and not onIconClick).
[ ] I verified that the left part of a conditional rendering a React component is a boolean and NOT a string, e.g. myBool && <MyComponent />.
[ ] I verified that comments were added to code that is not self explanatory
[ ] I verified that any new or modified comments were clear, correct English, and explained "why" the code was doing something instead of only explaining "what" the code was doing.
[ ] I verified any copy / text shown in the product is localized by adding it to src/languages/* files and using the translation method
[ ] I verified all numbers, amounts, dates and phone numbers shown in the product are using the localization methods
[ ] I verified any copy / text that was added to the app is grammatically correct in English. It adheres to proper capitalization guidelines (note: only the first word of header/labels should be capitalized), and is either coming verbatim from figma or has been approved by marketing (in order to get marketing approval, ask the Bug Zero team member to add the Waiting for copy label to the issue)
[ ] I verified proper file naming conventions were followed for any new files or renamed files. All non-platform specific files are named after what they export and are not named "index.js". All platform-specific files are named for the platform the code supports as outlined in the README.
[ ] I verified the JSDocs style guidelines (in STYLE.md) were followed

[ ] If a new code pattern is added I verified it was agreed to be used by multiple Expensify engineers
[ ] I verified that this PR follows the guidelines as stated in the Review Guidelines
[ ] I verified other components that can be impacted by these changes have been tested, and I retested again (i.e. if the PR modifies a shared library or component like Avatar, I verified the components using Avatar have been tested & I retested again)
[ ] I verified all code is DRY (the PR doesn't include any logic written more than once, with the exception of tests)
[ ] I verified any variables that can be defined as constants (ie. in CONST.js or at the top of the file that uses the constant) are defined as such
[ ] If a new component is created I verified that:

[ ] A similar component doesn't exist in the codebase
[ ] All props are defined accurately and each prop has a /** comment above it */
[ ] The file is named correctly
[ ] The component has a clear name that is non-ambiguous and the purpose of the component can be inferred from the name alone
[ ] The only data being stored in the state is data necessary for rendering and nothing else
[ ] For Class Components, any internal methods passed to components event handlers are bound to this properly so there are no scoping issues (i.e. for onClick={this.submit} the method this.submit should be bound to this in the constructor)
[ ] Any internal methods bound to this are necessary to be bound (i.e. avoid this.submit = this.submit.bind(this); if this.submit is never passed to a component event handler like onClick)
[ ] All JSX used for rendering exists in the render method
[ ] The component has the minimum amount of code necessary for its purpose, and it is broken down into smaller components in order to separate concerns and functions

[ ] If any new file was added I verified that:

[ ] The file has a description of what it does and/or why is needed at the top of the file if the code is not self explanatory

[ ] If a new CSS style is added I verified that:

[ ] A similar style doesn't already exist
[ ] The style can't be created with an existing StyleUtils function (i.e. StyleUtils.getBackgroundAndBorderStyle(theme.componentBG)

[ ] If the PR modifies code that runs when editing or sending messages, I tested and verified there is no unexpected behavior for all supported markdown - URLs, single line code, code blocks, quotes, headings, bold, strikethrough, and italic.
[ ] If the PR modifies a generic component, I tested and verified that those changes do not break usages of that component in the rest of the App (i.e. if a shared library or component like Avatar is modified, I verified that Avatar is working as expected in all cases)
[ ] If the PR modifies a component related to any of the existing Storybook stories, I tested and verified all stories for that component are still working as expected.
[ ] If the PR modifies a component or page that can be accessed by a direct deeplink, I verified that the code functions as expected when the deeplink is used - from a logged in and logged out account.
[ ] If the PR modifies the UI (e.g. new buttons, new UI components, changing the padding/spacing/sizing, moving components, etc) or modifies the form input styles:

[ ] I verified that all the inputs inside a form are aligned with each other.
[ ] I added Design label and/or tagged @Expensify/design so the design team can review the changes.

[ ] If a new page is added, I verified it's using the ScrollView component to make it scrollable when more elements are added to the page.
[ ] If the main branch was merged into this PR after a review, I tested again and verified the outcome was still expected according to the Test steps.
[ ] I have checked off every checkbox in the PR reviewer checklist, including those that don't apply to this PR.

Screenshots/Videos

Android: Native

Android: mWeb Chrome

iOS: Native

iOS: mWeb Safari

MacOS: Chrome / Safari

MacOS: Desktop

@thienlnam comment addressed :) It should be ready to be merged now

:hand: This PR was not deployed to staging yet because QA is ongoing. It will be automatically deployed to staging after the next production release.

FYI I believe this was deployed to prod yesterday, from this checklist - https://github.com/Expensify/App/issues/47219


[bug] Task Names Don't Allow Non-Alphanumeric Characters

Describe the bug
As task name cannot contain non alpha-numeric values? This is a super weird requirement coming from the land of NPM scripts.
Steps to reproduce
tasks:
  'db:migrate':
    command: 'goose -allow-missing=true -dir infra/migrations up'
    envFile: true

Expected behavior
No error, task executes.
Actual Behavior
 ERROR

Failed to validate .moon/tasks.yml configuration file.

  ▪ Must be a valid ID (accepts A-Z, a-z, 0-9, . (periods), - (dashes), _ (underscores), /, and must start with a letter) for key "inheritedTasks.tasks.db:migrate" in ../../.moon/tasks.yml YAML Extended file

Screenshots

Environment
Can't seem to run envinfo on an M2
Additional context
This is particularly unexpected and bothersome coming from NPM package scripts. Filing as a bug because this seems like an omission rather than a feature that needs to be added.

@shellscape Unfortunately : will never be supported because that's a moon specific syntax used by targets: https://moonrepo.dev/docs/concepts/target
We suggest using dashes, slashes, or periods instead.

Isn't the syntax :

We aren't supporting : because we have plans for an additional format like project:task:preset. We wouldn't be able to parse names correctly at that point.

Understood, we can leave it there. Food for thought for the future: it might be [better?] DX to use a flag for something like presets while letting the task name have flexibility.


feat: change api to be functional

Hey there, I noticed that the classes introduced define all the functions as static. Such a thing is a sign of code smell since it is leveraging the class (object) as a bag of functionalities which you can always achieve with import * as AnalyticsBrowser in ESM.
Removing such class definition and exposing the functions will give a cleaner, simple, and most important minifying code that will be shorter since you don't need the full class name.
Downside
Exposing everything from the root is suboptimal (reasons why I had to rename the functions), ideally, you would add two more exposed modules or as many runtime environments. For example:
import * as AnalyticsBrowser from '@segment/analytics-next/browser'
import * as AnalyticsNode from '@segment/analytics-next/node'

Follow up
I can fix the exporting, just wanna showcase what I meant rather than go back and forward on it.
Also fix the integration side, since such a file would probably create an object that mimics the previous behavior. Friendly when people don't import the script as part of their app.

Hey peeps @chrisradek @pooyaj 👋🏻 do you mind helping me with this one?
Just want to know if you are interested at all in the topic of bundle size at the very least.

In theory we can make breaking changes to the npm package as long as the major version bump and the CDN version remains backwards-compatible.

Right, the intention is that we get to optimize the CDN version for CDN reasons, but users like me that are using the package as a dependency get to take advantage of these things in the short and long term.

Did you happen to check what the bundle size delta is with this change?

  // BEFORE
  Size limit: 24.7 kB
  Size:       24.67 kB with all dependencies, minified and gzipped

  // AFTER
  Size limit: 24.7 kB
  Size:       24.57 kB with all dependencies, minified and gzipped

It is not much, but also it is a lot for a simple change and sets the foundation for the future.
Also,
The reason I didn't continue improving things is that I don't know your stand on the subject matter.
I have been working closely with Sentry folks on the topic (https://github.com/getsentry/sentry-javascript/pull/4381) and I know that it will eventually matter, and I noticed that most of these classes aren't really needed but requires a buy-in to make sure it is a goal to have a maintainable code that it is also friendly for customers.
So honestly, I am taking this opportunity to learn about your direction and whatnot, and hopefully, I get to contribute and help since I think I may know how to help a bit.


Add links to acquire each bondable asset

For each bond type, we should have a link on the bond page that takes people directly to the swap or "provide LP" page on the appropriate DEX to provide a better UX
We can just have a mapping from bond type to URL in constants and reference from the bond detail page

@0xAurelius over a year old, still want to keep this around for when bonding comes back online?


Add a README file to the Sphinx docs folder

I have added a README.md file to the docs folder, explaining what needs to be installed and how to build the Sphinx documentation.

Pull Request Test Coverage Report for Build 416065058

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 89.159%

Totals

Change from base Build 415808643:
0.0%

Covered Lines:
5872

Relevant Lines:
6586

💛  - Coveralls

@ahill187 could you please add a brief justification when closing PR without merging? thanks!


Requirements.txt Giving errors

Requirements.txt Giving errors,

This requirement.txt is design for running interminal of python IDE. If you're using notebook, you can try
import numpy as np
pip install opencv-python
pip install. tensorflow

Okay, Thnx; I have figured it put Already
On Sun, 21 Nov 2021 at 15:13, Pham Viet Hoang (Harry) <
@.***> wrote:

This requirement.txt is design for running interminal of python IDE. If
you're using notebook, you can try
import numpy as np
pip install opencv-python
pip install. tensorflow
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/HarryPham0123/YOLOv3-object-detection/issues/2#issuecomment-974784440,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AOOULVZKHAZMSGUG4NOZJG3UNC5K3ANCNFSM5IOCTX3A
.
Triage notifications on the go with GitHub Mobile for iOS
https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675
or Android
https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.


WYSIWYG Editors

Hello, how i can change the standard text to WYSIWYG Editors in todo list?

I see you closed this issue before anyone could respond, but briefly: This feature is not built into django-todo, as there are many wysiwyg editors avaialble out there, lots of tutorials and instructions on how to integrate wysiwyg into Django projects. Pick your favorite and go for it!


Sorting previous/next semantics for weight

The current semantic of prev/next on page seem wrong when looking at weights
Given 3 posts with date [2017-01-01, 2018-01-01, 2019-01-01]. The pages will be sorted in a descending order (2019, 2018, 2017) and the pages will have the following next/prev:

2019 => next = None, previous = 2018
2018 => next = 2019, previous = 2017
2017 => next = 2018, previous = None

The next/previous make sense here since we are talking about the next blog post would be the most recent and the previous as the older one.
Enter order and we get what we would expect:
3 posts with order = [3, 2, 1]
Expectations:

3 => next = None, previous = 2
2 => next = 3, previous = 1
1 => next = 2, previous = None

Lastly, weight:
3 posts with weight = [1, 2. 3]
Expectations:

1 => next = 2, previous = None
2 => next = 3, previous = 1
3 => next = None, previous = 2

Currently, the previous and next are reversed for weight which makes sense since both date/order work that way but weight actually works the other way semantically: it's ascending.
I think it would make sense to inverse setting next/previouswhen weight is used to match the expectations.
2 questions:

am I getting something wrong with my expectations about the weight ordering?
would switching the next/previous for weight make sense to everyone?

cc @codesections

Just to make sure I understand both the current situation and the proposed change, is the table below accurate for 3 posts with weight = [1, 2. 3]?

post title
current previous
current next
proposed previous
proposed next

1
2
--
--
2

2
3
1
1
3

3
--
2
2
--

Assuming that's right, I think that's a good change and would help with the sort of issues that come up in the Book theme: anytime there's a list of content that isn't a blog, it might make sense to talk about the next item in the list as the one below the current item, not the one above it.  The proposed change in the way weight defines previous and next would help address this non-blog use case.
More generally, I find the semantics of "order" and "weight" fairly confusing/non-intuative.  If I say "go to my blog and look at the third entry", I would typically mean the third from the top, not the third from the bottom.  That's even more true if I were talking about a list of products instead of a list of blog posts; I would always think that the "third" product entry was third from the top.  So I'm constantly getting order backwards in my head and having to remember to reverse it.
Similarly, I get weight confused.  There's part of me that thinks of "weight" as "how important something is", and thus expects whatever is given the most importance/weight to be presented first.  So I'm also constantly getting weight backwards, and having to catch myself.
I'm not suggesting that you switch the two—that would not only be extrodinarially confusing for existing users, but would also have its own semantic dificulties (there is a logic to weight "sinking" to the bottom of a list, after all).
But I wonder if the semantics would be improved by using names like assending and decending, and getting away from "order" and "weight" entierly?  (Though potentially leaving order and weight for backwards compatability.)
In my dream world—and I have no idea if this is feasable and don't know enough Rust to implement it myself—here's how it would work:

Users can only set two variables in the .md toml header:

order (a number)
date (a datestring)

Users can then set two variables in the section _index.md toml header:

sort_by: either "date" or ""order"
sort_direction: "assending" or "decending"  (Or just leave this off and let people handle it with Tera's | reverse filter)

If the user selects sort_by = "date", then they would have access to page.date_earlier and a page.date_later objects, and if they select sort_by = "order", then they'd have access to page.order_higher and page.order_lower objects.  And then you woudn't need to worry about the semantics around next and previous and the various different use-cases that make those non-intuative.
But, like I said, that's just a dream implimentation, and it isn't something I could do myself right now.  So, the solution you proposed looks good to me :+1:

The table is correct.
I am tempted to remove one of order or weight to be honest since I'm getting confused from them as well.
You can get the other one by calling the reverse filter on the pages anyway.
I know @phil-opp uses order in his blog: https://github.com/phil-opp/blog_os/tree/master/blog/content/second-edition/posts where it makes sense if we are talking about chapters and just increment a counter as we write, while having the latest ones at the top.
I believe weight could be removed entirely from gutenberg page sorting and be replaced in practice by order, unless I'm missing something. weight of section could be renamed to order as well to remove the weight notion from Gutenberg entirely.

That seems like a good option.  It would still leave the question of what to do with page.previous and page.next.  I could see two options:

Change nothing in the code, but add a note to the documentation to the effect that page.next always refers to the page with the order senquentally after the current page, and page.previous always refers to the page with the order senquentally below the current page.  If we do that, we'd just accept that page.previous and page.next sometimes don't match their intuative "feel" in certain use-cases—but with good docs, that shouldn't be too big of an issue.
Change page.next to page.order_higher and change page.previous to page.order_lower.  This would make that usage a bit more clear, helping people understand that the | reverse filter doesn't have any effect on the variables they have access to (as next and previous might incorrectly suggest).  Even though it uses the word "order", I don't think that the order_lower and order_higher semantics would be confusing for people sorting by date, since dates can be ordered higher and lower as well.

I don't think changing the names previous/next would be wise.
Looking at hugo/jekyll, it seems they actually only use weight so it might be worth looking at how they do things. Using order for the gutenberg documentation for example would require to reverse when wanting to show the list of pages in ascending order like in a menu.

I remember having a very similar discussion some time ago and @phil-opp preferred order.
weight makes more sense to me but I definitely think having both is confusing so one should go away.

(By the way, diving back into the Hugo docs/syntax remind me of how much I prefer Tera's syntax and how greatful I am for your work on this project. So thanks so much for that!)

That's the main reason why I started Tera and Gutenberg later ;)

The more I think about it, the more I think that the solution you articulated in the first post to this issue is best: just flip the behaviour of next/previous in weight but leave everything else the same.  (That is, leave both weight and order in existence.)
This would have a couple of advantages:

No need to pick between weight and order.  As you point out, some people have a preference for one over the other, and—regardless of which way Gutenberg goes—there would be some people who would prefer the other semantics.
(More important:) Better semantics for next and previous.  The result of keeping both and flipping the meaning for next/previous is that people can get any set of sematics that they want.  Do you want pages to be ordered 1, 2, 3, with 3 next from 2?  Ok, then sorty by weight.  Do you want them ordered 1, 2, 3 but to have 1 next from 2?  Then sort by order but use the | reverse filter. (And so on and so forth).  This lets people control exactly where next and previous point to get to the semanitics that make the most sense for their use case.

The (minor) downside to this is that wieght and order can be a bit confusing—the issue that I went into before.  But, the more I think about it, the more I beleive that this can be addressed through documentation, which is the area where I can best contribute now.
If that sounds good, I'd be happy to get to work on a pull request to the docs describing this behavior.

Based on @phil-opp's points and thinking more about all the possible use cases, I actually think that everything in the code should stay exactly the way it currently is, but that the documentation should be updated to more clearly explain how it works.
Here is my logic.  If we set asside sorting by date, the user can currently make two choices: 1) chose to sort by weight or by order and 2) chose to use the reverse filter or not.  By combining these two choices, the user can get whatever set of semantics works best for their use case.
I'll walk through all four options:
The blog sort: Here, the user wants to list posts by the order that they post them (the first-in-time post is 1 (and at the bottom of the list), the second-in-time post is 2, etc.  They also want previous to point to the post that was posted before the current post; that is, they want previous for 2 to be 1.  To get this behaviour, the user sets sort_by = "order" and does not use the | reverse filter.
The book sort: This user wants to write a book, where chapter 1 comes at the top of the list, followed by 2, etc.  Similarly, they want the previous from 2 to be 1.  To get this behaviour, they use sort_by = "order" but use the | reverse filter so that 1 will be the first/top page.
The ecommerce sort: This user wants item 1 to come at the top of the list, followed by the previous item, item 2.  To get this behaviour, they set sort_by = "weight" and don't use | reverse.
Weight-as-importance sort: This user wants to use weight to evaluate the importance of different items on the list, and then have the most important item shown at the top of the list.  previous should then point down the list to the item with the next-most importance.  To get this behavior, they set sort_by = "weight" and use reverse.
I know that some of those use cases might be more common than others.  But it seems to me that the current code can support all possible use cases and—with a bit of documentation work that I'm happy to take on—can be clear enough that users can tell exactly what combination of order/weight and | reverse they need to use to get the desired behavior.
If no one has an objection, I'll work on a pull request to the docs that clarifies how the current system works.  (There will probably be a table!)  If nothing else, it would be good to have an explanation firm enough in my own head that I can stop getting confused the way I did earlier in this thread.

The issue with the book sort is that for example for the book theme, I can use order without reverse for the sidebar but I end up having to do some weird things semantic wise like https://github.com/Keats/book/pull/3/files#diff-11720902627aeb97a05b6bad68f479edR19

@Keats I'm not sure what you mean exactly. Do you want the earliest chapter first or the latest chapter?
@codesections I think the sorting is currently implemented as ascending so that we have to use reverse for the blog sort but not for the book sort.

For my blog_os project, the sorting with order feels pretty natural for me, e.g. getting the latest post. Previous/next also works as expected, i.e. 1 is previous from 2 and 5 is next from 4.
For me it makes sense to think of the posts as array, i.e. the post with the lowest order has the lowest array index and the post with the highest order the highest array index. So to print them ascending (lowest order to highest) I iterate over the array front-to-back and for descending I reverse the array and do the same.

@phil-opp
Seeing things like {% set last_page = subsection.pages | first %} doesn't make much sense to me, I should do last to get the last page, not first. That's only an issue that happens when doing specific things in templates though, so it isn't a big deal

@Keats I took a closer look at your book example and I think the following things lead to confusion:

The pages array is not sorted ascending as one would expect, but descending. So my above comment was wrong about this. I just noticed that I'm creating a local variable with reversed order as a workaround for this issue in blog_os. Reversing the order makes section.pages | first and section.pages | last work as expected.
Sections can be only ordered by weight, not by order. However, it seems like they're treated like an order (i.e. smallest first). Maybe rename the corresponding key to section_order?
Sections are sorted randomly without a weight key. I think there should be at least a warning for any non-deterministic behavior.

Sections can be only ordered by weight, not by order. However, it seems like they're treated like an order (i.e. smallest first). Maybe rename the corresponding key to section_order?
That's how weight is usually treated, isn't it?  We all (including me) keep getting this mixed up, but weight lets the "lightest" item rise to the "top" of the list.  I don't think there's any difference between how weight works for pages and sections.

Sections are sorted randomly without a weight key. I think there should be at least a warning for any non-deterministic behavior.

I agree with this.  I added a warning in the docs (#343) but think it would be better to add a console warning (similar to how Gutenberg warns about pages that aren't being rendered when they lack the relevant front-matter variable).  We discussed this a bit in #335.

In the case of subsections, it's always used for some kind of menu ordering so weight makes more sense (imo) there: 1 at the top, 2 below etc

In the case of subsections, it's always used for some kind of menu ordering so weight makes more sense (imo) there: 1 at the top, 2 below etc

Wouldn't it be the same with order?

In the case of subsections, it's always used for some kind of menu ordering so weight makes more sense (imo) there: 1 at the top, 2 below etc

Wouldn't it be the same with order?

Nope.  With the current implementation, order would put 1 at the bottom.  Consider the following psudo code, where Post_1 is given as having weight = order = 1,:
{% set posts = [Post_1, Post_2, Post_3] | sort_by = "order" %}

{% for post in posts %}

 post

{% endfor %}

That produces

Post_3
Post_2
Post_1

Whereas
{% set posts = [Post_1, Post_2, Post_3] | sort_by = "weight" %}

{% for post in posts %}

 post

{% endfor %}

yields

Post_1
Post_2
Post_3

Oh ok, thanks! And the currently implemented prev/next order of these would be Post_1 -> Post_2 -> Post_3 for order and Post_3 -> Post_2 -> Post_1 for weight? I.e. from bottom to top in both lists? This would explain the reasoning behind the current implementation.
If my assumption is true, it seems like the current semantics for order and weight are based on the assumption that the latest post is always rendered first. I don't think that's a good strategy because it makes book-like sorting very confusing.

Oh ok, thanks! And the currently implemented prev/next order of these would be Post_1 -> Post_2 -> Post_3 for order and Post_3 -> Post_2 -> Post_1 for weight? I.e. from bottom to top in both lists? This would explain the reasoning behind the current implementation.

Subsections don't have prev/next, it's a simple sorted array.
For the pages, i'm not sure what to change to solve the confusion.

Subsections don't have prev/next, it's a simple sorted array.

Is there a reason that they don't or is it just not implemented. I imagine that it could be useful e.g. for linking to the next section in a book.

For the pages, i'm not sure what to change to solve the confusion.

I really like what @codesections proposed in their first comment:

In my dream world—and I have no idea if this is feasable and don't know enough Rust to implement it myself—here's how it would work:

Users can only set two variables in the .md toml header:

order (a number)
date (a datestring)

Users can then set two variables in the section _index.md toml header:

sort_by: either "date" or ""order"
sort_direction: "assending" or "decending" (Or just leave this off and let people handle it with Tera's | reverse filter)

If the user selects sort_by = "date", then they would have access to page.date_earlier and a page.date_later objects, and if they select sort_by = "order", then they'd have access to page.order_higher and page.order_lower objects. And then you woudn't need to worry about the semantics around next and previous and the various different use-cases that make those non-intuative.

We could choose a differerent name for order (e.g. number) and deprecate both order and weight. This would avoid silent breakage and we could even have a warning period that allows users to transition.
We could even implement the same system for sections with new sort_sections_by and section_sort_direction keys in the _index.md of the parent section. Then we would have an uniform and explicit system that works the same for pages and sections.

If my assumption is true, it seems like the current semantics for order and weight are based on the assumption that the latest post is always rendered first. I don't think that's a good strategy because it makes book-like sorting very confusing.

It's not quite as bad for book-like sorting because of the reverse filter in Tera.  So you can do something like the following pseudocode (again, pseudocode because not all of these filters exist; instead, variables have to be set in front matter)
{% for section in sections | sort_by = "weight" %}
   {{ section.title }}
  {% for page in section.pages | sort_by = "order" | reverse }}
     {{ page.title }}
  {% endfor %}
{% endfor %}

This gets everything in the right order, and gets page.next and page.previous pointing in the "right" direction.  I still don't love it, because it requires content creators to switch between giving each section a weight and each page an order.  I'd prefer to keep as much complexity in the template/theme, and keep things simple for the end user.  But it's not quite as bad as you might have been thinking.

I really like what @codesections proposed in their first comment:

The other advantage of moving in this direction would be that it would potentially improve the semantics for date, which we haven't even touched on.  Right now, if pages are sorted by date, then page.next always points to the next older post.  But there's actually considerable difference of opinion about the proper next/previous semantics for blog posts—some bloggers use next to point to the chronologically next-in-time post (i.e., the opposite of the way we do it).  See, e.g. https://ux.stackexchange.com/questions/1773/which-direction-indicates-newer-older.  Explicitly labeling the data as older/newer would avoid this issue as well.

I kind of see older/newer instead of next/previous as a good idea for dates now but I think next/previous makes sense when talking about a normal ordering.
I would keep order or weight as a name though, they are used in other SSG and will be more common.
The main "issue" is that for me weight makes more sense: if I want to add a new page, I just create a new .md with a weight higher than the last post and everything is working is working as expected.
For example:
intro.md -> weight 10
chapter1.md -> weight 20
chapter2.md -> weight 30
chapter3.md -> weight 40

If I want to add chapter 4, I can add a page with a weight of 50 and chapter3 will have next pointing at chapter4. By using reverse, we get the current order back.
We could use heavier/lighter instead of next/previous but that is not really explicit imo

I like the heavier/lighter idea.  That would let someone have a page.html template something like this
{{ page.content | safe}}

 Previous
 Next

That would let pick whichever direction they want for (displayed to user) next/previous links without ever having the odd construction of  Previous
And it wouldn't need to break anything; the existing behavior could stay in, but be deprecated as @phil-opp suggested

Did you have any thoughts regarding @phil-opp's suggestion that "there should be at least a warning for any non-deterministic behavior" from sections that lack a weight?

You mean if other sections at the same level have a weight, warn about the sections missing one? Sounds ok to me.
I would be tempted to do a clean break as the next version already has some big breaking changes, might as well group them in one release.
@codesections do you want to get your feet wet with the code? The changes would be fairly small

I have never programed Rust.  I'm very interested in learning and have blocked off January and February for working through The Rust Programing Language book, but I've literally never coded a line of Rust yet.  (I'm mostly a JavaScript developer, though I've done CS 101 amounts of C and dabbled a bit with Python).
Given all that, if you think it's manageable I'd be happy to take a swing at it if you'll point me in the right direction.

It should be ok!

Wait for @phil-opp feedback

The first bit is to update this enum https://github.com/Keats/gutenberg/blob/next/components/front_matter/src/lib.rs#L30-L39 to remove order (if we decide to go with weight)

Then in https://github.com/Keats/gutenberg/blob/next/components/content/src/page.rs#L240-L273 we remove next/previous when serialising and add older/newer and lighter/heavier. We still need to keep next/previous field of a page struct, it just won't be exposed to the templates.

Next up is fixing the sorting in https://github.com/Keats/gutenberg/blob/next/components/content/src/sorting.rs this is not going to compile at first because of the enum change in 1. The easy way is to fix the code first with cargo check in the content sub-crate and then remove useless tests. Once this is compiling and passing, you can add/tweak tests if needed.

Go to the root and run cargo test --all and fix any compilation errors

Update the documentation

I might have missed a step as it's late here and I'm a bit tired but the compiler should tell you the missing things anyway.

Success! I've updated the book template and semantics are now perfect imo

Awesome!


Changed _queryCache to an ordered list

Proposed changes
The compatibleArchetypes list can become out of order for QueryResults. This makes it skip over entirely valid archetype strings. Changing it from a set to a list can resolve this. Because it already uses the set _entityArchetypeCache to add new archetypes to queryCaches, there's no overhead trying to see if a new archetype has already been added to a queryCache or not.
Related issues
https://discord.com/channels/1234249974959702056/1283058858536992811
(Sorry this isn't a Github Issue, I was expecting to be committing an error myself).
Additional comments
I initially coded this in the current release, which until this worked without issue in my game.
The working version uses a different nextItem() function that in general seems to be erroring for my game, even prior to any changes. I also can't replicate the bug in the new release (but I think this could be due in part to the random erroring); however, the new version of nextItem() still relies on next(compatibleArchetypes) as a set, and it is my intention to resolve this bug and not the other things happening with queryResult.
A potential related issue with the new implementation of nextItem() would be around the removal of optimizeQueries / storage levels:
I may just be misreading the way the storage system is now working, but looking at the new implementation, this would likely happen on the entity level instead of the archetype level as entity archetypes change. E.g. an unordered list of entities {[1] = ..., [8] = ..., [95] = ..., [88] = ...} is not guaranteed to be in order.
This can be seen in use in nextItem() because it uses entityId, entityData = next(storage[currentCompatibleArchetype]). If this data is being modified, I would expect an entity to be removed from the currentCompatibleArchetype and moved to another archetype, causing the ordering next returns to sometimes change randomly.
But this is speculation, and I haven't thoroughly looked into the new storage implementation.

Another comment related to the way the new nextItem is implemented - the new version removes the previous hasSeen set to determine if the next value can be returned, so if a query changes the archetype of an entity, a new archetype could be added at the end of compatibleArchetypes, and the same entity could then be queried again. Again, I don't know if the storage[1] has some additional things going on the background I'm unaware of, but if it's just the active world's storage in general, I would expect this.

Continued in #137.
Thanks for bringing this up!


Pinging but no network connected in Nodepay dashboard.

I see that the ping failed issue has been fixed around 3 hours ago. I re-clone the git and have it run fine but in nodepay dashboard there no connected device/ip except from my own.

same here, script is updated

Same

same pls fix :(

Same heree

have u guys try to disable VPN? i think its because of VPN

Bro what vpn we use proxies

Ah sr bro. I mean proxies hahahaha. Edited alr

I do not use any proxy (direct), but I still have a problem.

fix it please

I think now we need to use static/residential proxy

To me, using chrome + proxy, still not work

same situation with me


Change default error arabic Text message

I want to change this text to my custom text in all form builder validators in the app.

You need set your own string on errorText paramater on each validator that you want


⚠ ClamAV has degraded performance

In bb3aea1, ClamAV (https://spamassassin.apache.org/) experienced degraded performance:

HTTP code: 200
Response time: 201 ms

Resolved: ClamAV performance has improved in 12b493e after 8 minutes.


Update limitation for js

Update limitation for js
Thank you for helping make the Dapr documentation better!
Please follow this checklist before submitting:

[ ] Commits are signed with Developer Certificate of Origin (DCO - learn more)
[ ] Read the contribution guide
[ ] Commands include options for Linux, MacOS, and Windows within codetabs
[ ] New file and folder names are globally unique
[ ] Page references use shortcodes instead of markdown or URL links
[ ] Images use HTML style and have alternative text
[ ] Places where multiple code/command options are given have codetabs

In addition, please fill out the following to help reviewers understand this pull request:
Description

Issue reference

@kaibocai - Ping on the above request.


chore: fixed wrong link to Go site

The second is nodejs, not golang
https://github.com/evcc-io/evcc/blob/6a1b320cf8615fb65f2da9706d2280d5afc1d0b7/README.md?plain=1#L114-L115

Thank you!


docs: fix truncate in 3.4.0 release blog zh-cn

Fixes: #[Add issue number here]
Changes:
Remove "`" from truncate. My fault, should've spotted it during review.
Screenshots of the change:

It was spotted @Yilialinn and we merged the fix just now :) You can close this PR. Thanks.


consider removing the "reason" field in the json configuration

now(soon) that comments are possible, https://github.com/abaplint/abaplint/pull/1029

I have nothing against this, reason was chosen as a simpler alternative to jsonc.


crypto/tls: SNI name with trailing dot (absolute name) fails tls handshake

Note: I don't think this is a bug in Go crypto/tls, but its strict handling may cause interoperability issues.
Go version
go1.21.1, probably earlier too.
What did you do?
Start a crypto/tls-based webserver. Browse to it with a popular browser (firefox, chromium, safari) with a URL that has a trailing dot, e.g. https://www.xmox.nl./
What did you expect to see?
You may expect to see a website.
What did you see instead?
A TLS handshake error.
It looks like the popular browsers do not remove the trailing dot from the SNI name used in their TLS handshake. Crypto/tls correctly (according to the TLS RFC) refuses the connection. See https://github.com/golang/go/blob/go1.21.1/src/crypto/tls/handshake_messages.go#L447
For firefox, see: https://bugzilla.mozilla.org/show_bug.cgi?id=1008120
For chromium, see: https://bugs.chromium.org/p/chromium/issues/detail?id=593952
Curl does strip the trailing dot from SNI, so curl https://www.xmox.nl./ can get to the HTTP response (though in this case the domain with trailing dot is not configured).
For most websites I tried to access with an absolute domain name (that are likely not running a crypto/tls-based HTTPS-webserver) the connections do work, e.g.: https://www.google.com./ https://www.amazon.com./
Some more examples that don't work: https://caddyserver.com./, https://nu.nl./ (appears to use skipper).
From memory (about 6 months ago), I first ran into this when using a crypto/tls-based webserver to offer email account autodiscovery to Microsoft Outlook. The incoming autodiscovery HTTPS connections had a trailing dot in the SNI name, so autodiscovery failed. Outlook seems to have made up the absolute URL itself.
To summarize: I don't think this is a bug in crypto/tls, and I like its correct/strict behaviour, but that may cause interoperability issues. I'm mostly filing this bug for future reference and possible discussion and after a hint from @FiloSottile.

Also RFC 5280:

When the subjectAltName extension contains a domain name system
label, the domain name MUST be stored in the dNSName (an IA5String).
The name MUST be in the "preferred name syntax", as specified by
Section 3.5 of [RFC1034] and as modified by Section 2.1 of
[RFC1123].

It does not allow trailing dots.

@FiloSottile @rolandshoemaker @golang/security per owners


Adding DEBUG Logging troubleshooting section

@Dmitry-Matveev and @debugthings can provide feedback.

@beckylino : Thanks for your contribution to the Azure documentation! The author, @CFreemanwa, has been notified to review your proposed change.

LGTM


Feature request: finer RGB light control

I've noticed some flickering/inconsistency in certain colors, especially in low power mode. I enjoy using the linnstrument in this mode because my eyes are easily blown out by light (astigmatism) which makes small details harder to see near a light. I assume this is also good for making videos depending on the quality of your camera.
I'm assuming this is because of how a row or set of LEDs are wired together and/or because of PWM control of the LEDs. Colors close to a primary seem less affected, which makes sense.
Some colors will likely consume more power than others at a given level, and because of the wavelength require different PWM to appear flicker free.
If my assumptions are right, a good way to mitigate this, and also give the user more control, would be to allow you to hold a color, sending you into a screen where every LED has that color (the inconsistency/flicker seems to be worse when multiple LEDs are lit), and allowing you to set R, G, and B separately for that color by sliding 3 different rows, with maybe a 4th row for overall light level.

+1
I'd love to have the ability to turn down the LED brightness or customize the colors more. I run it on low power mode just to dim them a bit but it doesn't make a huge difference. Ideally I'd be able to set them to be barely visible so I can still tell naturals from sharps/flats, but not so bright that it really stands out.


Use Chartjs update() and rebuild chart only when necessary

This fixes https://github.com/dnsmichi/dashing-icinga2/issues/93
Some of the arguments to circularChart and linearChart are now unused and should maybe also be dropped.

I've already tested it, but ran into a legend on top not right problem with the hosts chart. I need a free slot to dive into this again.

The legend alignment bug is present in your current master HEAD as well.
It is not a side effect of this PR specifically

(this was also mentioned in #93 by the original reporter and confirmed by me, before this PR was born)

Hm strange, I just didn't have that before in my environment, now it is permanent. Thanks for clarifying.