How to predict protein structure using Diffdock-pp？

The inferred results of the Diffdock-PP model provide information solely about the positions of the C-alpha atoms in the protein backbone. Could you please provide me with detailed information on how to obtain the positional information of other atoms, as demonstrated in the file 1AVX-ligand-full.pdb?

Thanks for your question!
Since our task setting is rigid protein-protein docking, the transformation of C-alpha atoms can be applied to other atoms straightforwardly. To be specific, for unbound positions of ligand ($x_{0c}$ for C-alpha atoms and $x_{0}$ for all atoms) and receptor ($x_{1c}$ for C-alpha atoms and $x_{1}$ for all atoms), if DiffDock-PP predicts the $\mathrm{SE}(3)$ transformation $(R,t)$ based on $x_{0c}$ and $x_{1c}$, then the docked positions of all atoms can ben obtained by $Rx_{0}+t$.

Thank you for your quick reply! I would like to ask if you could provide a Python file or any other file that generates the positions of all atoms based on the given C-alpha atoms

You can try this python script, where the inputs are the unbound positions of all atoms with shape $(N, 3)$, the bounded positions of C-alpha atoms with shape $(N_c, 3)$, and the indices of all C-alpha atoms with shape $(N,)$.
import numpy as np

def kabsch_numpy(P: np.ndarray, Q: np.ndarray):
    P = P.astype(np.float64)
    Q = Q.astype(np.float64)

    PC = np.mean(P, axis=0)
    QC = np.mean(Q, axis=0)

    UP = P - PC
    UQ = Q - QC

    C = UP.T @ UQ
    V, S, W = np.linalg.svd(C)

    d = (np.linalg.det(V) * np.linalg.det(W)) < 0.0

    if d:
        V[:, -1] = -V[:, -1]

    R: np.ndarray = V @ W

    t = QC - PC @ R # (3,)

    return (UP @ R + QC).astype(np.float32), R.astype(np.float32), t.astype(np.float32)

def ca_to_all_atom_transformation(unbound_pos, bound_pos_ca, ca_index):
    """
    :param unbound_pos: unbound positions of all atoms, (N, 3)
    :param bound_pos_ca: bounded positions of CA atoms, (Nc, 3)
    :param ca_index: the indices of CA atoms, (N,)
    :return: bounded position of all atoms, (N, 3)
    """
    unbound_pos_ca = unbound_pos[ca_index]
    _, R, t = kabsch_numpy(unbound_pos_ca, bound_pos_ca)
    bound_pos = unbound_pos @ R + t
    return bound_pos


TypeVariable(Field) does not behave like Field when being cast

Aim
Had to cast a Field to a u32, but it ultimately came from generics, minimal reproducer:

Viable workaround: First assigning this to a let x: Field. Low priority as a result.
Expected Behavior
This cast should be allowed
Bug
This seems to be due to this technically being a TypeVariable in the compiler, but should act the same for the user.
To Reproduce
See above screenshot.
Installation Method
None
Nargo Version
No response
Additional Context
No response
Would you like to submit a PR for this Issue?
No
Support Needs
No response

@jfecher what is the status of this issue?


Make 'toxin transport' GO:1901998 do-not-annotate (or obsolete it)

"toxin transport" is very vague. There is no mechanism or direction specified. I think it should be in the do not annotate subset (or even obsoleted).
it should always be possible to have a more specific activity, e.g.
GO:0000269 ! toxin export channel activity
GO:0019534 ! toxin transmembrane transporter activity
There are 26 experimental direct annotations to it https://amigo.geneontology.org/amigo/term/GO:1901998
Many any ARUK-UCL where the transmembrane part is implicit in extensions
has target start location external side of plasma membrane
has target end location cytoplasmic side of plasma membrane
For others like the E coli, it's obvious this is transmembrane
See also

#4618.

There is also regulation of toxin transport, but this has a single annotation
https://amigo.geneontology.org/amigo/term/GO:1902007
This seems to be (inter-organism) regulating import (and the direction should be positive)
https://www.ncbi.nlm.nih.gov/pmc/articles/PMC167169/
Although this doesn't seem to be the evolved function - the mutants don't import the toxin - so more likely a mechanism that has been hijacked

This term could probably be replaced by 'GO:1990748 cellular detoxification'

@pgaudet Is the recommendation to obsolete?

Yes

I think this is ready for obsoletion.


Feature request: Allow to skip label from field completely

{% bootstrap_field field show_label=False %}

currently still renders the label, but with class="sr-only". This is great for most cases, but it is actually a bad idea if the users manually adds the label separately. In that case, both labels will be associated with the form field and the computed aria-label will be "{label} {label}".

I agree on this. Can you propose an API for this using a pull request?

A straigtforward API would be show_label=True|False|'sr-only', but that would be a breaking change.
Maybe show_label='default'|'sr-only'|'hidden' where True maps to 'default' and False maps to 'sr-only'  for backwards compatibility.

Not sure about 'hidden' since it implies the current False to me...

What about True|False|None
True = show
False = hide with sr-only
None = nothing at all

Op 5 sep. 2018, om 22:07 heeft Jan Pieter Waagmeester<EMAIL_ADDRESS>het volgende geschreven:
Not sure about 'hidden' since it implies the current False to me...
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub https://github.com/zostera/django-bootstrap4/issues/115#issuecomment-418864114, or mute the thread https://github.com/notifications/unsubscribe-auth/AAFBiyUwZRmLTlNBCdKMt6DB2dWYcCNOks5uYC7lgaJpZM4WRbH4.

I think False/None are not very descriptive. That's why I would prefer to go with strings.

Or as specific extra option aria_support=True|False?
class="sr-only" is not an aria-attribute, but it does fall under aria support I'd say.

Op 6 sep. 2018, om 07:27 heeft Tobias Bengfort<EMAIL_ADDRESS>het volgende geschreven:
I think False/None are not very descriptive. That's why I would prefer to go with strings.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub https://github.com/zostera/django-bootstrap4/issues/115#issuecomment-418968933, or mute the thread https://github.com/notifications/unsubscribe-auth/AAFBi8UibLhxBP9rrubUY3pEtdA86TK3ks5uYLI4gaJpZM4WRbH4.

I also thought about it and concluded that it is more confusing than helpful.
Can you explain what is wrong with the current approach (note that I changed 'hidden' to 'skip' in the pull request) and why you think the other ideas are better? That could help me to understand the direction you want to go.

Thanks all, good discussion.
After re-reading, I come to this first question.
Do we want to keep True = show label and False = hide label but generate it with sr-only?*
If we were to do a breaking change and allow False = no label at all, we could introduce a new setting "sr-only" which would be quite obvious. What we would lose is the automatic generation of labels for screen readers that we now have, and somehow it feels as if we're doing people that use screen readers a disservice.
Let's tackle this question first.

@dyve can you please checkout #117? The approach I took there is this:

Introduce new values 'sr-only' and 'skip' to be explicit
Map False to 'sr-only' for backwards compatibility.


Use os.UserConfigDir() to store config file

We should use the standard library to get the config directory: https://golang.org/pkg/os/

@rkpattnaik780 found this last night in the Go library, we can eventually remove the third part library which does this :)

This will simplify things a lot :)
I can pick this up.


document.body issue

I am using this polyfill with my c# app. I am loading it under my babel polyfill.
In IE && FF I am getting an error.
document.body.appendChild(this.container)
Unhandled exception at line 1, column 17790 in http://localhost/GEOConnect/node_modules/date-input-polyfill/date-input-polyfill.dist.js
0x800a138f - JavaScript runtime error: Unable to get property 'appendChild' of undefined or null reference occurred
That is what Visual Studio is reporting.
In the console it says:
TypeError: document.body is null
I am loading this in the head of the project. Should this be in the bottom of the body?

I want to report that moving the scripts to the bottom of the body removed the error.
Although, it does not work in Firefox still.


Added doPostActionWithCookie for MM-10516, actions in ephemeral messages

Summary
Added new functions (action, and client method) augmenting doPostAction to
include the "cookie" value. The old functions should no longer be used,
but I wasn't sure if it's safe to deprecate them, thus new additions.
An upcoming mattermost-server PR will have a better write-up on the use-case and the overall flow.
Ticket Link
https://mattermost.atlassian.net/browse/MM-10516
Checklist
[Place an '[x]' (no spaces) in all applicable fields. Please remove unrelated fields.]

[X] Ran make check-style to check for style errors (required for all pull requests)
[X] Ran make test to ensure unit tests passed
[X] Ran make flow to ensure type checking passed
[X] Added or updated unit tests (required for all new features)

@crspeller done


Update introduction.md

The book does look clean, however I think a possible improvement would have been to add "next page" and "prev page" buttons to make navigation easier. Additionally if you were to do this project again and want different specs, it may be beneficial to write a small app (or use an app you previously wrote) and explain what the app does in extreme detail using the git book. Just a fun idea if you want to redo this project in another way in the future or just as a fun experience on the side.


Flask request.url is wrong when making requests to the amazonaws.com endpoint

Context
When Zappa is running for a project which has a settings.DOMAIN set the Flask request is always created without a script name. This is the correct behaviour for requests which were received on the domain (e.g. GET https://mydomain.com/api) but is the incorrect behaviour for requests which were received on the Amazon AWS url (e.g. https://blahblahblah.execute-api.us-east-1.amazonaws.com/dev/api).
This is a bug because it means that anyone using request.url inside their Flask code will see the URL without the stage for the requests received on the AWS url (e.g. request.url == 'https://blahblahblah.execute-api.us-east-1.amazonaws.com/api').
Possible Fix
Decide the script_name dynamically based on the request, rather than just based on the Zappa settings.
Steps to Reproduce
$ http https://yrclxq7qw0.execute-api.eu-west-1.amazonaws.com/dev/info
HTTP/1.1 200 OK
Connection: keep-alive
Content-Length: 79
Content-Type: text/html; charset=utf-8
Date: Mon, 24 Jul 2017 11:39:35 GMT
Via: 1.1 a87358124376a016816b92e640349672.cloudfront.net (CloudFront)
X-Amz-Cf-Id: AGDtqDA8WcZh0KjQr-CVSSEdFiKqBV0in555tJEOIf8BHe8uoPf4fA==
X-Amzn-Trace-Id: sampled=0;root=1-5975dc77-0036a6f483e8dcb741fd275c
X-Cache: Miss from cloudfront
x-amzn-Remapped-Content-Length: 79
x-amzn-RequestId: c4c14366-7064-11e7-ae38-cd0b527c41b7

{'request.url': u'https://yrclxq7qw0.execute-api.eu-west-1.amazonaws.com/info'}

Here's the code for the relevant view:
from flask import Flask
from flask import request

the_app = Flask(__name__)

@the_app.route('/info')
def return_info():
    return str({'request.url': request.url})

Full lambda code is available at
Your Environment

Zappa version used: 0.43.1
Operating System and Python version: Python 2.7
The output of pip freeze:

appdirs==1.4.3
appnope==0.1.0
argcomplete==1.8.2
asn1crypto==0.22.0
awacs==0.6.2
awscli==1.11.123
backports.functools-lru-cache==1.4
backports.shutil-get-terminal-size==1.0.0
backports.tempfile==1.0rc1
backports.weakref==1.0rc1
base58==0.2.4
bbm-wrench==2.42.1
bcrypt==3.1.3
boto3==1.4.4
botocore==1.5.86
bravado==9.0.7
bravado-core==4.8.0
bson==0.4.8
cachetools==2.0.0
certifi==2017.4.17
cffi==1.10.0
chardet==3.0.4
click==6.7
clickclick==1.2.2
colorama==0.3.7
connexion==1.1.12
cryptography==2.0
decorator==4.1.2
docutils==0.13.1
durationpy==0.4
enum34==1.1.6
Fabric3==1.13.1.post1
Flask==0.12.2
Flask-HAL==1.0.4
formic==0.9b8
funcsigs==1.0.2
functools32==3.2.3.post2
future==0.16.0
futures==3.1.1
hjson==2.0.7
idna==2.5
inflection==0.3.1
ipaddress==1.0.18
ipdb==0.10.3
ipython==5.4.1
ipython-genutils==0.2.0
isodate==0.5.4
itsdangerous==0.24
Jinja2==2.9.6
jmespath==0.9.3
jsonpatch==1.16
jsonpointer==1.10
jsonschema==2.6.0
kappa==0.6.0
lambda-packages==0.16.1
MarkupSafe==1.0
mock==2.0.0
mongoengine==0.13.0
packaging==16.8
paramiko==2.2.1
pathlib==1.0.1
pathlib2==2.3.0
pbr==3.1.1
pexpect==4.2.1
pickleshare==0.7.4
pkginfo==1.4.1
placebo==0.8.1
pprintpp==0.3.0
prompt-toolkit==1.0.14
ptyprocess==0.5.2
pyasn1==0.2.3
pycparser==2.18
Pygments==2.2.0
pymongo==3.4.0
PyNaCl==1.1.2
pyOpenSSL==17.2.0
pyparsing==2.2.0
python-dateutil==2.6.1
python-dotenv==0.6.4
python-slugify==1.2.4
python-string-utils==0.6.0
pytz==2017.2
PyYAML==3.12
requests==2.18.1
rsa==3.4.2
s3pypi==0.4.0
s3transfer==0.1.10
scandir==1.5
simplegeneric==0.8.1
simplejson==3.11.1
six==1.10.0
stacker==1.0.4
swagger-spec-validator==2.1.0
tabulate==0.7.7
toml==0.9.2
tqdm==4.14.0
traitlets==4.3.2
troposphere==1.9.4
typing==3.6.1
Unidecode==0.4.21
urllib3==1.21.1
wcwidth==0.1.7
Werkzeug==0.12
wsgi-request-logger==0.4.6
WTForms==2.1
zappa==0.43.1

Link to your project (optional): https://github.com/jakul/zappa-request-path-problem
Your zappa_settings.py:

dev:
  app_function: app.wsgi.the_app
  aws_region: eu-west-1
  domain: api.example.com
  keep_warm: false
  manage_roles: false
  project_name: zappa-request-path-problem
  role_name: zappa-execution-role-dev
  s3_bucket: zappa-uploads-dev

@Miserlou I have the same issue. When are you planning to release this fix? Thanks!


encoding/asn1: accepts non-minimal OID encoding

go version go1.13.4 linux/amd64

Does this issue reproduce with the latest release?
Yes
What operating system and processor architecture are you using (go env)?
go env Output
$ go env
GO111MODULE=""
GOARCH="amd64"
GOBIN=""
GOCACHE="/home/jsha/.cache/go-build"
GOENV="/home/jsha/.config/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GONOPROXY=""
GONOSUMDB=""
GOOS="linux"
GOPATH="/home/jsha/go"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/home/jsha/go1.13"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/home/jsha/go1.13/pkg/tool/linux_amd64"
GCCGO="gccgo"
AR="ar"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD=""
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build221529794=/tmp/go-build -gno-record-gcc-switches"

What did you do?
Passed an invalidly-encoded OID to asn1.Unmarshal
What did you expect to see?
Parse error.
What did you see instead?
Successful parse.
Here's an example program demonstrating the problem, along with a reference to the ASN.1 spec:
https://play.golang.org/p/ETqZ6Kxz16G
package main

import (
	"encoding/asn1"
	"encoding/hex"
	"fmt"
	"log"
)

func main() {
	var o asn1.ObjectIdentifier
	// Correct encoding; each component of the ObjectIdentifier is encoded
	// minimally.
	s, err := hex.DecodeString("06092a864886f70d01010b")
	if err != nil {
		log.Fatal(err)
	}
	_, err = asn1.Unmarshal(s, &o)
	if err != nil {
		log.Fatal(err)
	}
	fmt.Println(o)
	// Incorrect encoding; the 0x80 byte encodes a zero prefix in base 128, which
	// violate's X.690's requirement to minimally-encode OIDs (which applies
	// to both BER and DER). Ref: X.690 2015, §8.19.2 "The subidentifier shall be
	// encoded in the fewest possible octets, that is, the leading octet of the
	// subidentifier shall not have the value [0x80]"
	s, err = hex.DecodeString("060a2a80864886f70d01010b")
	if err != nil {
		log.Fatal(err)
	}
	_, err = asn1.Unmarshal(s, &o)
	if err != nil {
		log.Fatal(err)
	}
	fmt.Println(o)
}

/cc @FiloSottile @agl

Do we know of frequent occurrences of this in the wild? (Trying to understand if we'll cause breakage.)

I haven't seen this in the wild, but I also haven't looked. Just occurred to me to try out Go's behavior when I read that section of the spec.

Let's fix this early so it has time to bake. I'd take a CL for it!

@rolandshoemaker @FiloSottile could we perhaps send a release note documenting this update? It is a new change that'll surprise some folks.

Yup, will do.


clang-format style for Objective-C (.mm) files

The current clang-format rules are not correct for Objective-C / .mm files.
We should either protect those files with /* clang-format off */ comments to avoid having them changed by a too eager clang-format call, or (better) fix the rules so that they're properly styled and included in our scripts.
There are some ObjC-specific options in the clang-format documentation: http://releases.llvm.org/3.9.1/tools/clang/docs/ClangFormatStyleOptions.html

Actually clang-format handles Obj-C/C++ files pretty well, so after some manual improvements by @BastiaanOlij, I could apply clang-format and add .m and .mm files to our hooks.
Fixed with a27876d and 3fd10ff.


Absolute paths to values files do not work

The following part of a helmfile (which is contained inside helmfile.d)
environments:
  myenv:
    values:
      - "/absolute/path/to/values.yaml"

fails to load the values file, because apparently the absolute path is appended to the path to the helmfile.d directory, giving /path/to/helmfile.d/absolute/path/to/values.yaml which is obviously not what was intended.

Thanks for your response!
About the use-case: the helmfile is stored in a repo together with some files with "fixed" values for the helm charts, representing a curated set of applications and integrations between them. Besides these values that we provide, there are some values that have to be set "from the outside", by our users. Those external values are mounted into the docker container  at a fixed location, so they have a well-known absolute path. The helmfile is in another part of that container, and a relative path from there to the external values file would first go four or five levels up, then a few more down. It's possible, but not natural, and I'd say more likely to break, though the absolute path could change at some point as well of course.
Using a relative path instead is a straight-forward workaround, so this bug is no dealbreaker, but at least a better error message would be a welcome improvement.
This is part of a project to allow organisations to easily self-host cloud services (see our project website). The helmfile project is really useful for us, so thanks!

@ariep Not sure if you're still using helmfile, but anyway... This is finally resolved as part of #549 and #610 :)


Deployment for newly generated project does not work on heroku

The included deployment (well, the assembly plugin) does not work against heroku. In short, heroku expects to call stage and the shipped plugin uses assembly:
I made a few changes to get it working:

Added the native packager plugin to project/plugins.sbt
 addSbtPlugin("com.typesafe.sbt" % "sbt-native-packager" % "0.8.0-RC1")

Removed the assembly_plugin.sbt file.

Added the necessary references to build.sbt
 import NativePackagerKeys._
 packageArchetype.java_application

Changed procfile as follows:
 web: target/universal/stage/bin/<appname> -Dcom.twitter.finatra.config.env=$ENV -Dcom.twitter.finatra.config.adminPort=$ADMIN_PORT -Dcom.twitter.finatra.config.port=:$PORT

Notes.

I added the $ADMIN_PORT environment variable so I can run formate start on the local command line to have the app boot via the Procfile.

I added $ENV for the same reason, so that the development or whatever environment can be passed locally while still using the production style startup process.

These require a .env file with those parameters defined as follows:
 PORT=7070
 ADMIN_PORT=:9990
 ENV=development

See https://github.com/twitter/finatra/tree/master/examples/finatra-hello-world-heroku for deploying an application to Heroku.


Minor quirk with "Eta reduce": position-range exceeds actual refactor-suggestion range

(Not sure whether this is only-for-Eta-reduce or only-for-top-level-definitions, but the example should be enough to repro if interested.)
By "position-range" I mean the span between StartLine/StartColumn and EndLine/EndColumn in --json output. By "refactor-suggestion range" I mean the span of text actually captured by the From/To fields. Here's the picture story.
The Eta reduce suggestions typically span sub-expressions (let/where) in terms of position-range:

However, their From snippet (in the tooltip, "current code") doesn't:

This means if one were to naively apply the suggestion without sanitizing the range to match the From length..

..one could lose the sub-expressions!

Client code could work around this by ditching the EndLine/EndColumn info and recompute these based on the length of From (if the editor API assists in translating txtlen-vs-poscol-pairs --- right now I'll skip this entirely as it's just not a constantly recurring use-case in reality ;)  --- but been wondering about this since pretty much nigh-all other hlint suggestions, far as I can tell so far, seem to readily provide a To/From pairing properly consistent with the given start-to-end position-range

Fixed in HEAD.

Fixed indeed! Much obliged =)


RuleSelector Extending

What did you do?
Create cluster role to be able to watch/list/get configmaps
What did you expect to see?
Expectation is to select rules across all cluster not just namespace in which prometheus resides
What did you see instead? Under which circumstances?
Configmaps with labels are not detected in other namespaces

Kubernetes version information:

Client Version: version.Info{Major:"1", Minor:"9", GitVersion:"v1.9.2", GitCommit:"5fa2db2bd46ac79e5e00a4e6ed24191080aa463b", GitTreeState:"archive", BuildDate:"2018-02-07T07:49:13Z", GoVersion:"go1.9.2", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"9", GitVersion:"v1.9.2+coreos.0", GitCommit:"b427929b2982726eeb64e985bc1ebb41aaa5e095", GitTreeState:"clean", BuildDate:"2018-01-18T22:56:14Z", GoVersion:"go1.9.2", Compiler:"gc", Platform:"linux/amd64"}

Kubernetes cluster kind:
kubespray

Manifests:

apiVersion: monitoring.coreos.com/v1
kind: Prometheus
metadata:
  name: app-metrics
  namespace: default
  labels:
    prometheus: app-metrics
spec:
  version: v2.2.0
  logLevel: debug
  serviceAccountName: prometheus
  serviceMonitorSelector:
    matchLabels:
      tier: frontend
  resources:
    requests:
      # 2Gi is default, but won't schedule if you don't have a node with >2Gi
      # memory. Modify based on your target and time-series count for
      # production use. This value is mainly meant for demonstration/testing
      # purposes.
      memory: 2Gi
  alerting:
    alertmanagers:
    - namespace: monitoring
      name: alertmanager-main
      port: 9093
  ruleSelector:
    matchLabels:
      role: alert-rules
      prometheus: app-metrics

apiVersion: rbac.authorization.k8s.io/v1beta1
kind: ClusterRole
metadata:
  name: prometheus
rules:
- apiGroups: [""]
  resources:
  - services
  - endpoints
  - pods
  verbs: ["get", "list", "watch"]
- apiGroups: [""]
  resources:
  - configmaps
  verbs: ["get", "list", "watch"]
- nonResourceURLs: ["/metrics"]
  verbs: ["get"]

Now that we have #1227, we only missing this one to have a fully functionnal solution if we want a unique Prometheus for a multi-namespaces setup.

@gmauleon I will be working on this next.

Hey @mxinden, any love given to this yet? ;)

@gmauleon Selecting Prometheus rules across Kubernetes namespaces was introduced by https://github.com/coreos/prometheus-operator/pull/1333. We are currently wrapping everything up for the next release, which will include this.
@Atoms @gmauleon Let me know what you think.

looks promising

Thanks a bunch man!
Commented on the merge tasks with Atoms, a couple of question there.
I (we/everyone I'm sure) really appreciate the time you sink in this.

We just released the features: https://github.com/coreos/prometheus-operator/releases/tag/v0.20.0


10128 style migrations

Several fixes for style migration. Highlights:

In vizjson3, layers.options.sql is now the base query (not wrapped). This is the same as in named maps, and it is what cartodb.js expects.
Creates time-series widget when migrating an animated layer

Fixes #10128

Time to hate on that widget auto-creation thingy. Please CR @juanignaciosl


Continuing the project.

Hi as you may have notice i have made a fork of this project. and this is because i would like to continue this project. and if possible would like to get my hands on the source code as well. is this ok with you?

Yes I am fine, thank you! Thanks for your interest.
Please refer to https://github.com/majianjia/DeepPlankter/issues/1#issuecomment-1369482837 for the current status of this project.
There is still some security info that needs to be cleaned before it can be released, never have a chance to do it.
I will check today.

ok thank you.


Libsecam

Hi, I want to ask about Libsecam. Can you explain how to use it?

Hello. I've just made a new released and added a quick start instruction under secamiz0r directory. Check it out.


[CI/Tests] Fix Pytorch 1.10 autocast failing tests

What does this PR do?
The signature for CPU autocast has also changed, hence we need to update the requirements check to the same as bfloat16. I've also updated a test which seems I missed in the initial integration!
Related https://github.com/PyTorchLightning/pytorch-lightning/issues/9280
cc @daniellepintz
Before submitting

[x] Was this discussed/approved via a GitHub issue? (not for typos and docs)
[x] Did you read the contributor guideline, Pull Request section?
[x] Did you make sure your PR does only one thing, instead of bundling different changes together?
[x] Did you make sure to update the documentation with your changes? (if necessary)
[ ] Did you write any new necessary tests? (not for typos and docs)
[x] Did you verify new and existing tests pass locally with your changes?
[ ] Did you list all the breaking changes introduced by this pull request?
[ ] Did you update the CHANGELOG? (not for typos, docs, test updates, or internal minor changes/refactorings)

PR review
Anyone in the community is welcome to review the PR.
Before you start reviewing make sure you have read Review guidelines. In short, see the following bullet-list:

[x] Is this pull request ready for review? (if not, please submit in draft mode)
[x] Check that all items from Before submitting are resolved
[x] Make sure the title is self-explanatory and the description concisely explains the PR
[x] Add labels and milestones (and optionally projects) to the PR so it can be classified

Did you have fun?
Make sure you had fun coding 🙃

Tests are passing for autocast now, just quantization tests are failing.

thanks for the fix!


Format code with "black"

I recently became aware of black which enforces a code style automatically. Maybe it is a good idea to standardize the code style here? (I'm about to explore some changes to the extractor code, so this may be a preparatory step)
If you don't agree, I can also stick to my human imperfect code style ;)

I'm ok with this.


Updated gradle configuration to work under Java 11.

Updated gradle configuration to work under Java 11. This is needed for the SOAP service to run correctly while running under Java 11. Change was made in maven, but not here.

I didn't need this. What did you do to conclude it was necessary?

I opened an issue in the companion consumer app yesterday since I was getting a JAXB Implementation missing error, and after that was closed decided that I needed to review this app as a "go back to basics" before opening a duplicate ticket there. Long story short, I added the change above and everything started working again.
As far as I can tell you didn't need this because you never tested the application under Java 11 with gradle deploy and were using maven instead, since it already has the glassfish dependency.

I ran the consumer test/run.sh with Java 11 though, and that uses this project, so I think it works for me. What is it that you see specifically that isn't working?

Tried again and it did fail the consumer test (but not this one) with Java 11. Merged this change and it works now.


Add AssemblyName support into XmlnsDefinition attribute

Is your feature request related to a problem? Please describe.
I want to include types into https://github.com/avaloniaui namespace and to do that I want to use XmlnsDefinition but it does not support AssemblyName (you can add AssemblyName when using xmlns inside xaml file e.g. xmlns:sys="clr-namespace:System;assembly=mscorlib")
Describe the solution you'd like
Instead defining each time xmlns in xaml files like xmlns:sys="clr-namespace:System;assembly=mscorlib" I want to include them in Avalonia namespace via XmlnsDefinition
[assembly: XmlnsDefinition("https://github.com/avaloniaui ", "System", AssemblyName = "mscorlib")]

Describe alternatives you've considered
No response
Additional context
Instead:
xmlns:sys="clr-namespace:System;assembly=mscorlib"

<sys:Tuple x:TypeArguments="sys:Int32, sys:String"
           xmlns:sys="clr-namespace:System;assembly=mscorlib"
           xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml">
    <x:Arguments>
        <sys:Int32>42</sys:Int32>
        <sys:String>Hello World</sys:String>
    </x:Arguments>
</sys:Tuple>

we could have clean xaml syntax:
    <Tuple x:Key="Tuple" x:TypeArguments="Int32, String">
      <x:Arguments>
        <Int32>42</Int32>
        <String>Hello World</String>
      </x:Arguments>
    </Tuple>

In Avalonia you can write xmlns:sys="using:System" without specifying any assembly, which I use often for this namespace.
Doesn't the same work for [assembly: XmlnsDefinition("https://github.com/avaloniaui ", "System")] ?

In Avalonia you can write xmlns:sys="using:System" without specifying any assembly, which I use often for this namespace. Doesn't the same work for [assembly: XmlnsDefinition("https://github.com/avaloniaui ", "System")] ?

[assembly: XmlnsDefinition("https://github.com/avaloniaui ", "System")] does not work

Here is my test project https://github.com/wieslawsoltes/TupleDemo


Update queries against epoch_data

#12310 adds a UNIQUE constraint against epoch_data. Existing queries against that table use just the seed and snarked ledger hash id. Those queries should use the other columns, to make sure the result is correct.

All the queries use epoch_data ids, not the column contents


Add alternate Image on Error

Is your feature request related to a problem? Please describe.
So currently at Courses page, images are not showing because of some error on network side or not in media.
Describe the solution you'd like
i would like to add an alternate image on error if image not find.  It will show alternate image if main image of the page not found. So user don't have to face and any problems on website.
Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.
Additional context
Here i have provided error Photo

I want to work on this

Right Now We are accepting, only backend issues
Thanks for issuing but we are not proceeding towards !


performance tip: instead of relying on http sockets (and ssl client certs) mount /run/kopano in containers

Hi,
one thing that I just saw while going through your compose file. You could simplify your setup and increase performance (file sockets have a higher throughput than going through http(s)) by just mounting the same /run/kopano across all containers.

Ok, thank you. This is something that clearly need to be changed. This design decision is from my early docker phase and I have never touched it since then.

fixed through #14


Fix: objc/native tests + enhancements

objc/native timeout option (will be documented soon)
objc/native fixtures + fix the generation
missing fixture file results in failing test (for the fixture) (this
behaviour is the same as before) but prints a nicer failure message
if the fixture file is missing, snippet test will be set to pending to
avoid a double failure
remove done() calls in tests, we are not testing anything asynchronous
improved applciation-form-encoded.json fixture with a new parameter

Closes #7


Added a new JavaScript Project that shows details of all the countries

Added a new JavaScript project in which we can select a country of our choice and then we'll get details for that country.
I'm adding this project as a part of GSSOC'22 contribution.

@TushitaParashar Everything is perfect just update the number to 50 as the 49th project is already there.

@swapnilsparsh updated the project number to 50

@TushitaParashar Thank you for your contribution. Looking forward to more such amazing contributions 🥂


Left menu sub-items

The sub-menu items are not diplaying after merging dev branch. It is due to
.nano > .nano-content
{
position : absolute;
}
Need to see what changed the behavior of this.

Check when there is no blog.

The new left menu fixes this.


LGVISIUM-66: refactor computation of metrics

My first attempt at making everything a bit more coherent.
Through the refactoring, it became apparent that metrics are not computed very consistently.

For layers and depth intervals, we track the macro average of the metrics. I.e. we first compute precision, recall and F1 score for each individual document, and then we take the average of those values.

Moreover, the overall precision is computed based on the macro-averaged precision and macro-averages recall. This can be different from the macro-averaged F1 score (i.e. the average of the F1 scores of the individual documents)! I don't think that this is a very usual metric, and we probably should compute a proper macro-averaged F1 score instead.
For metadata and groundwater, we use the micro average, i.e. we count the TP, FP and FN across all documents, and compute the overall F1, recall and precision metrics based on those counts.

Considering that we are mostly interested in the question "how much work does an expert have to fix any mistaking during quality control", and this effort tends to be larger for documents with a lot of data, I would say that the micro average might be a better metric for us.

However, for now, I've left all the metrics exactly as they were computed previously. The code in the evaluate method in score.py now at least gives a clear overview of how each metric is computed.

@stijnvermeeren-swisstopo while running the code in the main and the LGVISIUM-66 branches, I saw that the results on mlflow are the same but the fields like groundwater_depth_fn do not exist anymore. I am assuming that this change was made on purpose?

@dcleres On purpose, as discussed on Teams ;)


[jvm-packages] add the missing scm urls

for some reason this part was missing in master branch????

Codecov Report

Merging #3589 into master will increase coverage by 0.09%.
The diff coverage is n/a.

@@             Coverage Diff              @@
##             master    #3589      +/-   ##
============================================
+ Coverage     50.04%   50.14%   +0.09%
  Complexity      188      188
============================================
  Files           172      172
  Lines         13877    13877
  Branches        457      457
============================================
+ Hits           6945     6958      +13
+ Misses         6707     6694      -13
  Partials        225      225

Impacted Files
Coverage Δ
Complexity Δ

src/data/sparse_page_dmatrix.cc
92.89% <0%> (+0.59%)
0% <0%> (ø)
:arrow_down:

src/data/sparse_page_raw_format.cc
64.15% <0%> (+22.64%)
0% <0%> (ø)
:arrow_down:

Continue to review full report at Codecov.

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


Implement browse by collection/provider

Implement endpoint for browsing by collection, e.g. /{provider_name}?page=2&pagesize=20.

We didn't actually decide this yet, did we? Given our API strategy...

It's in the list of items we committed to in the sprint. Like the search end point, it will be rate limited to prevent abuse. We can also expose just the first 10,000 works through this API to prevent copying everything. That way, users can still browse to their heart's content (barely anybody/nobody needs more than 100 pages of results) without effectively providing a dump of the entire database through this endpoint.

Ok I like the idea of employing both.
The rate limit would be a technical limit, as would be exposing only the first 10,000 works. Since we're exposing that through our own use of the API, though, the TOS on the API might not cover the end user. Is that a correct reading?
cc: @sarahpearson -- let's discuss which terms (API or general on CC search) would cover this

this discussion was moved to Slack, we'll post an update here once we decide on a course of action.

let's take this off active sprint. there are additional reasons not to do this that we need to discuss.

Confirming this can go ahead, but as a feature for post-summit, and pending final review by myself and Sarah.


hi

Hi @aaudibert-test, thanks for your contribution!
In order for us to evaluate and accept your PR, we ask that you sign a contribution license agreement. It's all electronic and will take just minutes.


Support per-repo (or repo type?) configuration

This is somewhat related to #66 but warrants a new Issue/Thread
Many projects have different repos for different purposes. clomonitor should expand the db schema so repos can be flagged as governance, docs, or code repos.
For example, Knative has several repos:

Community -- A governance repo that holds a lot of policy/procedure info. This should be the primary repo, but it would have a different license (CC 4.0) since it's more of a "Docs" repo. It also is going to fail any sort of "recent release" check since it's not a code repo.
Eventing -- A code repo that should have an Apache 2.0 License and a "recent release" check
Service -- A code repo that should have an Apache 2.0 License and a "recent release" check
Docs -- A docs repo that should have a CC 4.0 License check

If we can decouple the idea of "primary/secondary" repos to instead allow a repo to be flagged as one or more of these categories, I think it will better match many of the projects that exist or will soon be onboarded.

At the moment we support multiple repositories kinds (primary and secondary) and for each kind we run a different set of checks that can be configured separately. Some context about where the primary and secondary repository kinds come from: https://github.com/cncf/clomonitor/issues/15#issuecomment-1034239403, https://github.com/cncf/clomonitor/issues/15#issuecomment-1039368882, https://github.com/cncf/clomonitor/issues/15#issuecomment-1039380473.
We can add more repositories kinds, that's not a problem. However, we need to keep in mind that the more we have with more configurable variants, the more complexity we'll introduce producing reports, scoring them and specially combining repositories scores to produce a project's final score with homogenized results.
I'd suggest we keep track of how often situations like this occur before making important changes that would affect all projects. Once we have collected more feedback and use cases we can decide if it's better going with the kinds we have, we need to add more or we handle this in a completely different way. We'll be happy to refactor whatever is needed 🙂
I think in many cases the problem described in #66 can be addressed nicely with some headers in the README file, which also makes the information more discoverable by users. We also support .github repos for the default community health files. Some projects' repositories may not need to be added to CLOMonitor at all, as with a reference to some key docs from the main one may be enough.
On a side note about KNative, it looks like neither the library we are using to detect licenses nor Github are detecting it properly. Maybe it's because the LICENSE file contains the text of two licenses (CC and Apache), but not sure. CC is not on our list of approved licenses either (that affects the approved license check), but we could change that.

Zoning in on the License issue, that's where things get somewhat complex.
CC4.0 is the license we want projects to use only for their docs
Their code should fall under one of the existing licenses you have already (like Apache 2.0)
Because of this split-brained scenario, I'm personally trying to push for the existence of a LICENSE file as well as a LICENSE-DOCS file.
This has been discussed previously (https://github.com/cncf/project-template/pull/12) and I think it's the ideal path forward. Likewise it should also simplify the license checks.

Because of this split-brained scenario, I'm personally trying to push for the existence of a LICENSE file as well as a LICENSE-DOCS file.

Cool, that'd be nice 👍

Adding my 2 cents: I'd vote for more repo types than just primary and secondary, such as code, docs, and community(?). /cc @nate-double-u

Just brainstorming... but do you want to get into the mode of continually needing to define new repo types as new ones come along? Would it make more sense to simply let the repo owner specify (somehow) that they don't have/need a certain type of artifact? I would think that the most important thing is that the repo owner went thru the thought process about each one and explicitly said "we don't need this for our stuff" rather than trying to fit into CLOMonitor's definition of what type of repo it might be?

You bring up a great point @duglin. Hopefully we'll be able to come up with some kinds that cover most cases. But it could be a problem, you are right.
We actually provide a way to declare checks exemptions per repository, but IMHO it should only be used in some exceptional cases, and not as a way of configuring CLOMonitor. The main problem I see with encouraging projects to go this way is that it could be misused easily and some important checks could be left out, reducing the utility of the tool.

@cynthia-sg and I have started working on this issue today. Depending on the approach we take, quite a few changes may be required and we'd like to get on the right track with this as soon as possible in preparation for an upcoming 1.0 release.
At the moment, we support two repository kinds, primary and secondary, and each repo must use one of them.
We were considering how it would look like switching to three: community, code and docs, as suggested in this issue. However, instead of each repo having a single kind, multiple kinds could be assigned to a repo.
Even though the current model does not fit well in some cases, it's working fine for most projects. Many of them have a single repository that covers all CLOMonitor checks, so in those cases we could flag a single repo as community + code, for example.
A possible distribution of the checks per kind could be:

Kind: code

Documentation / Changelog
Documentation / Contributing
Documentation / Maintainers
Documentation / Readme
License
License / Approved
License / Scanning
Best practices / Artifact Hub badge
Best practices / DCO
Best practices / OpenSSF badge
Best practices / Recent release
Security / SBOM
Security / Policy

Kind: community

Documentation / Adopters
Documentation / Code of conduct
Documentation / Contributing
Documentation / Governance
Documentation / Readme
Documentation / Roadmap
Documentation / Website
Best practices / Community meeting
Best practices / Slack presence
(?) Security / Policy
Legal / Trademark disclaimer

Kind: docs

Documentation / Readme
License
License / Approved

Any thoughts that can help shaping this are very welcome! 🙂
/cc @caniszczyk

Hi! 👋
We've just added support for check sets. Check sets replace the previous primary and secondary kinds. Unlike kinds, multiple check sets can be applied to a single repository. At the moment the following check sets are supported: code, code-lite, community and docs. For more details about what checks are part of each set please see the checks documentation.
All repositories have been updated with their corresponding check sets. If you notice that any of them doesn't have the correct check sets assigned please let us know and we'll gladly update it.
Lots of things have changed internally, including how scores are calculated and merged, so if you find something that's not working as expected please ping us 🙂

I can't seem to find the docs for where to specify the "check" value. Where is that?
Also, should there be a link from the main README ( https://github.com/cncf/clomonitor ) to the docs for how to setup a repo for CLOMonitor? The docs in the README focus on a CLOMonitor dev, not a user.

oh never mind - I see that it's set on your side.
I think my comment about docs for users is still valid though :-)


errors trying to decode with mbart model

🐛 Bug
Thanks for releasing the mbart models! I am trying to decode with the pretrained model for use as a baseline, but am running into a few problems:

Can you clarify where the language codes go?
The paper suggests that something like <en> is appended to the encoder and (at training time) prefixed to the target side. Is this correct?
However, the README implies the code is more like [en_US] or something
How do I translate to a specific language? I would have expected to have to force-decode to the prefix (via --prefix 1 or something) but this isn't clear. Perhaps the language code (-t) is used implicitly in the task?

Furthermore, I cannot run the model to test this. When running with the latest fairseq, I get the following error:
RuntimeError: Error(s) in loading state_dict for BARTModel:
        Unexpected key(s) in state_dict: "encoder.layernorm_embedding.weight", "encoder.layernorm_embedding.bias", "decoder.layernorm_embedding.weight", "decoder.layernorm_embedding.bias".

This suggests to me that I am doing something wrong or that some code was not committed.

Environment

fairseq Version (e.g., 1.0 or master): latest github
PyTorch Version (e.g., 1.0): 1.4.0
OS (e.g., Linux): CentOS 7.5
How you installed fairseq (pip, source): source
Build command you used (if compiling from source): pip install --editable (from within a conda env)
Python version: 3.7.6
CUDA/cuDNN version: 10.1 / 7.6.3
GPU models and configuration: Titan RTX

Update: I do see how the language codes are handled in fairseq/tasks/translation_from_pretrained_bart.py, but I have not been able to figure out the model key error.

Looks like this task only works with the fine-tuned model. Switching to that one (for EN-RO) solved the problem.

I don't understand why you want to generate on MBART pretrained model. It is not a translation model, it is a de-noising model.

Can someone verify that I should be the language code after eos_id?
For en-ro preprocessing, inputs should end with [2, 250020] not [250020, 2], correct?


Consider more nuanced fog install

Maybe something closer to https://github.com/johnbellone/chef-provisioning-cookbook/blob/master/recipes/fog.rb#L19-L25 would be better? You'd fail faster. I'd look at how other cookbooks install fog, and see what the common pattern is. Additionally, I don't see any cookbook on Supermarket that installs the fog gem -- this could totally be a simple community cookbook that you could also write.

Looks like there is a fog_gem cookbook, but may not be actively maintained.


Adding search based on IP Address

Hello,
On the golang version I was able to search an entry based on the IP Address (and may be on any field).
Since I'm on the Rust version, it looks like this behavior isn't copied.
Would it be possible to have it ?
Thanks for your job !

Hello,
Yes also for me.
In my case search an entry based on the IP Address is an essential option.
In version 3.4.0 the last in Go it's possible.


Investigate if spetlr test folder is cleanup up automatically

It is unclear whether the SPETLR submit test job removes the test folder afterwards. Investigate!

This is not prioritized.


Add PR diff comments in order

This PR addresses one of the review comments in https://github.com/alphagov/govuk-frontend/pull/4511#pullrequestreview-1754871951
Posting GitHub diff comments in order
We previously used Promise.allSettled() but the least useful "Other changes" comment often comes first

I wonder if it's worth rethinking the grouping down the line - feels slightly strange to see CSS and SCSS changes split up on #4498 , especially since they directly relate to each other. That could be a whole spiral of work though.

This PR now adds comments in the order they're configured

Whoops, little linting issue before we can merge it seems. Strange that Husky didn't pick it up, but maybe it's because the commits were moved with rebases 🤔


(TypeScript) my_worker_1.default is not a constructor

"typescript": "3.1.6",
"webpack": "4.29.1",
"worker-loader": "2.0.0"
The typescript below compiles to
var my_worker_1 = __webpack_require__('./src/my.worker.ts');
var worker = new my_worker_1.default();

When the app runs, my_worker_1 evaluates to:
ƒ () {
  return new Worker(__webpack_require__.p + "ca60d2657d7fa455bc31.worker.js");
}

An error is therefore thrown: my_worker_1.default is not a constructor
The code should compile to the following, without reference to .default
var my_worker_1 = __webpack_require__('./src/my.worker.ts');
var worker = new my_worker_1();  // Note: no ".default"

my.worker.ts
const ctx: Worker = self as any;
ctx.addEventListener('message', (event) => {
   // do stuff
});

export default null as any;

app.ts
import MyWorker from './my.worker'
// this didn't make any difference: import MyWorker from 'worker-loader!./my.worker';

var worker = new MyWorker();

webpack.config.js
rules: [
      {
        test: /\.worker\.ts$/,
        use: { loader: 'worker-loader' } // does not make any difference: , options: {inline: true} }
      },
      {
        test: /\.tsx?$/,
        use: [
          {loader: 'awesome-typescript-loader'}
        ]
      },
      {
        exclude: [
          //...
          /\.worker\.ts$/
        ],
        loader: 'file-loader',
        options: {
          name: 'static/media/[name].[hash:8].[ext]',
        },
      },

https://stackoverflow.com/questions/50210416/webpack-worker-loader-fails-to-compile-typescript-worker

I can avoid the my_worker_1.default is not a constructor error if I use
import * as MyWorker from 'worker-loader!./my.worker';

but then I get:
bootstrap:1 Uncaught ReferenceError: window is not defined
    at bootstrap:1
    at bootstrap:788

var parentHotUpdateCallback = window["webpackHotUpdate"];
...
// Load entry module and return exports
 	return hotCreateRequire("./node_modules/string-replace-loader/index.js?!" +
                                                "./node_modules/awesome-typescript-loader/dist/entry.js!" +
                                                "./src/my.worker.ts")
                                               (__webpack_require__.s =
                                                 "./node_modules/string-replace-loader/index.js?!" +
                                                 "./node_modules/awesome-typescript-loader/dist/entry.js!" +
                                                 "./src/my.worker.ts");

The fix for this problem is to add globalObject: 'this' to the webpack config as mentioned in #142
...but with the worker-loader! prefix in app.ts the worker code doesn't actually run and there are no errors logged to the console.  The fix - drop the prefix:
import * as MyWorker from './my.worker';

...but even then TypeScript complains about the type of MyWorker:

Cannot use 'new' with an expression whose type lacks a call or construct signature

Solution:
const worker = new (MyWorker as any)();

In tsconfig.json add:
{
  "compilerOptions": {
    "esModuleInterop": true
  }
}

In *.worker.ts:
// Trickery to fix TypeScript since this will be done by "worker-loader"
export default {} as typeof Worker & (new () => Worker);

Now you can use your worker as a normal default import:
import MyWorker from './my.worker.ts';

TypeScript now sees MyWorker as type Worker and you no longer need to import from 'worker-loader!./my.worker.ts';. Instead, set up worker-loader in your webpack config. E.g. in my case this is a drop in for an ejected CRA in the oneOf list where TS_LOADER is defined (basically '@ts-tools/webpack-loader' for me):
{
  test: /\.worker.ts$/,
  use: [
    {
      loader: require.resolve('worker-loader'),
      options: {
        name: 'static/js/[name].js',
        publicPath,
      },
    },
    TS_LOADER,
  ],
},
{
  test: /\.tsx?$/,
  ...TS_LOADER,
},

@bfricka Thank you. It works. Except I don't need esModuleInterop in my tsconfig.json

@steida Yeah, that was an oversight. It's fine since it's a default export. Oops!

Here two problems:

bad typescript documentation
compatibility with webpack-dev-server

So close in favor https://github.com/webpack-contrib/worker-loader/issues/253 and https://github.com/webpack-contrib/worker-loader/issues/174


Blurred rendering

Added two features:

the map renderer can now be initialized with different tile resolutions. By default a tile is 256x256 pixels, but can also be configured as other 2's powers (eg. 512x512 or 1024x1024).
added a layer of gaussian blur to mimic the foggy rendering effect, which make the view less jaggy.

The current gaussian filters are purely CPU-based. GPU based acceleration may be added later.
Comments are welcomed.

Since modifying the rendering will influence many image tests, I will postpone the image testing fix until the rendering improvement is finalized.
I think the rendering looks somehow better now? Maybe an extra layer of blurring is still needed.

Added a new implementation of gauss blur. May be a  little bit slower than previous version.

I hijacked this PR and:

made sure the overlay is always bigger than the screen, so even tho the render is slower now, we won't leak empty gap.
added a minor UI tweak


Markdown Snippet Prefix Does Not Trigger Snippet

VSCode Version: Code 1.12.2 (19222cdc84ce72202478ba1cec5cb557b71163de, 2017-05-10T13:20:36.315Z)
OS Version: Windows_NT ia32 10.0.14393
Extensions:

Extension
Author
Version

plsql
casian
0.0.3

beautify
HookyQR
1.1.1

csharp
ms-vscode
1.10.0

Steps to Reproduce:

Add the following to the markdown.json file:

    {
        "Start a New Day": {
            "prefix": "mdday",
            "body": [
                "## Date: 2017-$1",
                "### Tasks & Activities",
                "- Daily Planning (:30)",
                "- $2"
            ],
            "description": "Create template for new day's activities"
        }
    }

Create a markdown file named "test.md"
Verify that the Language Mode in the bottom right of the editor reads "Markdown"
Type "mdday"

Expected behavior:
Type-ahead functionality would show the portion of the prefix typed, and hitting TAB would enter the code contained in the body of the prefix.
Actual behavior:
Nothing happens as "mdday" is typed, and no code is inserted. The snippet CAN be triggered by the menu path View > Command Palette > Insert Snippet and scrolling to the bottom of the list where the Prefix and Description are listed.
Additional Information:
I have a user snippet file for both HTML and JS files as well, and those snippet files appear to be working as designed. The code snippet shown above is now the only one in my markdown.json file.

I'm unable to reproduce this. Perhaps it is a setting issue? Quick suggestions are disabled by default in markdown files. Can you try setting:
"[markdown]":  {
    "editor.quickSuggestions": true
  }

You may also want to set "editor.snippetSuggestions": "top" so that the snippet always shows up first in the suggestion list

The solution was to enable the Quick Suggestions as suggested by mjbvz. I didn't realize that as some point during an upgrade it had been disabled.


Add Bluesky for Mine (Data Pedagogy)

Hi @mdogucu,
I'm working on adding a Bluesky integration for the R-Ladies bot and saw that you're also on Bluesky. Please let me know

if you agree to add your handle here as well so that the bot can use it to tag you when posting about your posts
if you're also OK to be featured in an R-Ladies starter pack

Thank you ☺

Yes
Yes
Thank you 🙏🏼

Amazing, thank you! :)


Make main keep newest [ V2.5.3]

V2.5.3

Add dashboard, management chart

Fix browser display garbled Chinese problem in some server resource

Fix not found self directory environment in generate process

macos fail: because windows fail, but it is success
windows fail: #13
sonatype-lift: mark success


List related features sample: use correct identify workflow

Description
Original request (CS 2032): Several samples use an identify workflow that is not best practice. We should be using mapView.identifyLayersAsync(...) when identifying across multiple layers or mapView.identifyLayerAsync(...) when we know which layer we need to run the identify on.
For Java the sample needing to be update is List Related Features. I've made what I think is the correct change, but @TADraeseke  if you could check this over first as per your original issue requirements, I can then get it reviewed for merging.
Thanks!

Checklist:

[x] Set target branch to master (current release) or dev (next release)
[x] Request a reviewer
[x] Assign a reviewer
[x] Tag reviewer in comment

@JonLavi @Rachael-E  very small update to list related features sample if you could both take a look, thanks!


Refactoring on dates.

@surli and @bloriot97, from the issue #772, I realized that we always do new Date() to refer to the end of the reproduction, but this is prone to inconsistencies (very difficult to happen, but it could happen) in the db, thus we might refactor that to always record the same exact date, which would be in ReproductionBuggyBuild.getReproductionDateEnd I think (to be precisely checked), WDYT?

I think we should provide in repairnator-core a class DateUtils and use it everywhere we need to work with dates :)
Pretty easy to find all places where we import java.util.Date and to put the right method in a DateUtils.

Refactoring on dates (this issue is not supposed to fix any bug, it's just related to refactorings and minor adjustments):

Create DateUtils for everything related to dates
Replace new Date() to ReproductionBuggyBuild.getReproductionDateEnd to serialize buildReproductionDate
?


Eclips compiler error after copy plugin/gcm folder

I have a working Eclipse project, where I'd like to build in push notificatoins.
After I copy the folders from src/android/com/ to my src/com/, Eclipse is giving me the next error:
[2013-07-24 07:51:28 - Dex Loader] Unable to execute dex: Multiple dex files define Landroid/support/v4/accessibilityservice/AccessibilityServiceInfoCompat$AccessibilityServiceInfoVersionImpl;
[2013-07-24 07:51:28 - MyApp] Conversion to Dalvik format failed: Unable to execute dex: Multiple dex files define Landroid/support/v4/accessibilityservice/AccessibilityServiceInfoCompat$AccessibilityServiceInfoVersionImpl;

Is this a known error, and even better, does anyone know how to solve this?

https://github.com/phonegap-build/PushPlugin/issues/492  Similar issue, the solution is to make sure v13 is being used.


Consider shortened debug output when there is a failure in a macro

Let's say I have something like this that generates quite a bit of code
macro gen_tag_helpers
  {% for tag in [:a, :img, :hr, :div, :many_more_tags] %}
    def {{ tag.id }}(text)
      puts text.upcase
    end
  {% end %}
end

gen_tag_helpers

not_string = 1
# This will blow up because `1` does not implement `upcase`
img(not_string)

The output is this:
Error in macro_errors.cr:12: instantiating 'img(Int32)'

img(not_string)
^~~

in macro_errors.cr:9: expanding macro

gen_tag_helpers
^

in macro 'gen_tag_helpers' /Users/paulcsmith/learning/crystal-playground/macro_errors.cr:1, line 7:

   1.
   2.     def a(text)
   3.       puts text.upcase
   4.     end
   5.
   6.     def img(text)
>  7.       puts text.upcase
   8.     end
   9.
  10.     def hr(text)
  11.       puts text.upcase
  12.     end
  13.
  14.     def div(text)
  15.       puts text.upcase
  16.     end
  17.
+ many many more lines!

undefined method 'upcase' for Int32
Rerun with --error-trace to show a complete error trace.

The problem here is that I would expect this to be last
img(not_string)
^~~

It is super helpful that the compiler prints the macro so you can see what's wrong, but sometimes macros generate a bunch of code so finding the line that's the problem can be quite difficult. I wonder if it could print just some of the code. Maybe the 10 lines around the failure area with a compiler flag for showing everything if it's not enough. In my experience only a few lines of context are needed to see what the problem is.
It may also be helpful to colorize the line as :red so it draws attention, but that may be a separate issue.
Thanks for taking a look. Crystal rocks!

The last line in the error output is:
undefined method 'upcase' for Int32

The compiler always shows the relevant error last, because that's what you immediately see above the prompt. I don't think we'll change this.


[AVRO] Prioritise Avro providers from "extensions/core"

Fixes #25601

Thank you for your contribution! Follow this checklist to help us incorporate your contribution quickly and easily:

[ ] Mention the appropriate issue in your description (for example: addresses #123), if applicable. This will automatically add a link to the pull request in the issue. If you would like the issue to automatically close on merging the pull request, comment fixes #<ISSUE NUMBER> instead.
[ ] Update CHANGES.md with noteworthy changes.
[ ] If this contribution is large, please file an Apache Individual Contributor License Agreement.

See the Contributor Guide for more tips on how to make review process smoother.
To check the build health, please visit https://github.com/apache/beam/blob/master/.test-infra/BUILD_STATUS.md
GitHub Actions Tests Status (on master branch)

See CI.md for more information about GitHub Actions CI.

Run Python3.10 PostCommit

CC: @mosche @Abacn @sclukas77

Run Python 3.10 PostCommit

Run Python 3.10 PostCommit

Run Python 3.10 PostCommit

retest this please

retest this please

Run Python 3.10 PostCommit

Run Python 3.10 PostCommit

Run Java_Examples_Dataflow PreCommit

Run Java_Hadoop_IO_Direct PreCommit

Rerunning flakes impacted by jenkins flakiness (underlying errors were Jenkins errors, not test issues)

Run Java_Examples_Dataflow PreCommit

Run Java_GCP_IO_Direct PreCommit

the affected test passed (seen from log of Python3.10 postcommit):
14:30:45 PASSED                                                                   [ 75%]
14:30:45 apache_beam/io/external/xlang_jdbcio_it_test.py::CrossLanguageJdbcIOTest::test_xlang_jdbc_write_read_1_mysql
14:30:45 -------------------------------- live log call ---------------------------------
14:30:45 INFO     testcontainers.core.container:container.py:53 Pulling image mysql:latest
14:30:47 INFO     testcontainers.core.container:container.py:64 Container started: 22da3809393d
14:30:47 INFO     testcontainers.core.waiting_utils:waiting_utils.py:46 Waiting to be ready...
14:30:47 INFO     testcontainers.core.waiting_utils:waiting_utils.py:46 Waiting to be ready...
14:30:48 INFO     testcontainers.core.waiting_utils:waiting_utils.py:46 Waiting to be ready...
14:30:49 INFO     testcontainers.core.waiting_utils:waiting_utils.py:46 Waiting to be ready...
14:30:50 INFO     testcontainers.core.waiting_utils:waiting_utils.py:46 Waiting to be ready...
14:30:51 INFO     testcontainers.core.waiting_utils:waiting_utils.py:46 Waiting to be ready...
14:30:52 INFO     testcontainers.core.waiting_utils:waiting_utils.py:46 Waiting to be ready...
14:30:53 INFO     testcontainers.core.waiting_utils:waiting_utils.py:46 Waiting to be ready...
14:30:54 INFO     testcontainers.core.waiting_utils:waiting_utils.py:46 Waiting to be ready...
14:30:55 INFO     testcontainers.core.waiting_utils:waiting_utils.py:46 Waiting to be ready...
14:30:56 INFO     testcontainers.core.waiting_utils:waiting_utils.py:46 Waiting to be ready...
14:30:57 INFO     testcontainers.core.waiting_utils:waiting_utils.py:46 Waiting to be ready...
14:30:58


Questions on the patches

Hi Professor,
I'm a little confused about your provided patches. For example, https://github.com/rjust/defects4j/tree/master/framework/projects/Cli/patches. Intuitively I thought they are developer patches. However, when I checked them carefully it seems that you ran the command "diff fixed-version buggy-version" instead of "diff buggy version fixed-version". Does that mean that the patches are used to transfer a fixed version program to its corresponding buggy version? I'm not sure whether you intend that. Sorry for bothering you and thanks for you time!

I believe that you are right. It was mentioned in d4j's original paper that irrelevant modifications was removed and only changes relevant to the specific bugs were preserved.

I believe that you are right. It was mentioned in d4j's original paper that irrelevant modifications were removed and only changes relevant to the specific bugs were preserved.
[https://people.cs.umass.edu/~rjust/publ/defects4j_issta_2014.pdf]

Thanks for your reply! If so, I believe the reverse of patches d4j provided can be regarded as developer patches.

@claudeyj  Hi yj, are you also a researcher trying to use d4j ? I would be happy to add you on wechat :)

@SZTankWang Hi, of course, nice to meet you! My wechat id is wxid_3py9wtnfevtx22 .

@claudeyj Hey, it seems that I cannot reach you using this id. Here's mine, woshiatan2000

Hi @claudeyj,
The patches in Defects4J are not developer patches. They are reverse patches that introduce a bug into working code. This is a similar concept to mutation testing, where a code transformation is applied to break the code. When you "check out" a buggy version in Defects4J, you check out the working code, then apply a patch that introduces a bug into that code.

If so, I believe the reverse of patches d4j provided can be regarded as developer patches.

This is not quite true either. It is a subset of the developer's patch to fix the bug.
When bugs are added to Defects4J, the person adding the bug performs a cleaning process to remove code changes unrelated to the bug from the code. For example, the developer patch may have both fixed a bug and performed unrelated refactoring or made other changes. We remove those changes so that the patch in Defects4J solely relates to the bug itself.

Hi professor @Greg4cr, got it, thank you so much for your help!

No problem, please let us know if you have other questions.


Postcard scene deserialization does not provide readable error for unregistered types.

What you did
I was creating the tests listed in https://github.com/bevyengine/bevy/pull/7336.
During the testing, I was missing one of the .register_type() calls, which made all 4 of the backends fail to deserialize. The error messages were clear, except the one for postcard, which was less helpful.
What went wrong
The output for postcard is this:
Serde Deserialization Error
thread 'components::postcard_roundtrip_equality' panicked at 'Scene failed to deserialize: Serde Deserialization Error', tests/scenes/components.rs:61:37
stack backtrace:

Which is a lot less helpful than the output for ron, bincode, and messagepack:
no registration found for type `(i32, alloc::string::String, f32)`
thread 'components::bincode_roundtrip_equality' panicked at 'Scene failed to deserialize: no registration found for type `(i32, alloc::string::String, f32)`', tests/scenes/components.rs:94:37
stack backtrace:

I'd expect the output for "failing to deserialize because of a missing type registration" to be the same, regardless of the backend.
Additional information
To reproduce, comment out one of the .register_type calls in components.rs from this pull request: https://github.com/bevyengine/bevy/pull/7336. All 4 backends will fail to deserialize, but postcard will have a criptic message.

I could be wrong but I think this is an issue with postcard itself. I think it catches our errors and instead returns its own cryptic error 😅

Ah, that would be unfortunate 😅

Hey, author of Postcard here.
I may in fact be eating your error. If you can make a repro case and open an issue on the postcard repo, I'd be happy to diagnose!
This might be related to:

https://github.com/jamesmunns/postcard/issues/38
https://github.com/jamesmunns/postcard/issues/80
https://github.com/jamesmunns/postcard/pull/81


eslint-plugin-query: skipToken breaks exhaustive queryKeys rule

Describe the bug
Just like reported in a related issue, using the skip token prevents the exhaustive queryKeys rule from working. The linked issue is slightly different and deals with closures, etc. Here, I am interested in the potentially simpler problem of making the linter support skipToken properly.
Your minimal, reproducible example
https://eslint-online-playground.netlify.app/#eNq1VMtu2zAQ/JUFTw7gWHcVaXsofOmpD6CHMgeWWtmyKZJdkkEMQ/+eJaU4NuIkSIJcZFs7OzszS3ovAukKb1XvDS42QdSi672jCHsI287/dlu0c0gBfySkHQzQkutBiq9R2RCV3laESsfL/7ksBUgrbZusjp2zue1nMrhUnQmzC9hLC6Ad90EiA1dMs47Rh7o6KNCulyLDCGOiwlAGz0ovQFUB3npkersCBS0zJ0JYI+EIKDq+466Gv1KQc1GK6/lRaWlrYClXn6HFqNczFnKRywM/h7Pq/zjafoT6kLTGEJ7XztGTeaWBUwu/eItvWcAIa9wyT2Foq0woOj9yM/fjvjyyCPXDeXx6X9nsW/b1LrPvWORr/Yq5wGA6G1m6bbvVyY3dhMPlHEHVJkjxSdqpXqY+vr8j9tKbtOrs/T3OwbLD3NZgq5KJbIVlsPFNmIaHBSEn2KNtsGFnJZuRJtQc/9GMibUun0NJgfhqMay8OUe4KAA2XdBT7lPT9CsH6WJ+wTEjkaOcsxSNS/8MPhyvkSI/rzkNztCzJrXK/3fOcn6FToq489xU87feNTyIycZCgzff0GdVVnesiTGTghdzzGxGscZ8BA49R+s5Cxjrp8VigeMQwx2bxPBa
Steps to reproduce

go to the link above
observe that there is only one eslint error when there ought to be 2

Expected behavior
I expected that there would be two failures instead of one. (The second being when we are missing keys in the skipToken versions)
How often does this bug happen?
Every time
Screenshots or Videos
No response
Platform

Everything

Tanstack Query adapter
None
TanStack Query version
eslint plugin: 5.50.0 (at time of this writing. It is always latest in the repro url)
TypeScript version
No response
Additional context
No response

@Newbie012 can you maybe look at this issue?

I'll look into it

fixed by https://github.com/TanStack/query/pull/7747


Make the Lexer class easier to read and understand

By using StringScanner we can remove some of the code and some of the noise from the scan patterns. I think this makes Lexer easier to understand.
Closes #33.

Nice, that makes it a lot easier to understand. One thing, what do you think about moving the require into lib/regular_expression.rb? I personally like it because it lists all the dependencies in one place, but I know some folks prefer to have it in the files that need it in case those files are required individually.

Oh, fine by me. Done! And rebased in light of #28 and #32.


changed master version to 0.5.0

created 0.4 feature branch. Therefore master needs to be version 0.5

ack


Keep ODB pointers as constant &strs

Most of ODB entries are not used; but maybe it is useful to start adding as constants (probably in the midas module) the ones that I start using.

Remember that some are currently hard coded in alpha-g-alpha16-signal-viewer and alpha-g-padwing-signal-viewer. Just remove them once this issue is fixed.


+default/search-project can only search 1 word

What did you expect to happen?
Previously, SPC s p would let me enter multiple words for searching the whole project.
What actually happened?
After the latest upgrade, typing a word and then a space would make the first word i typed disappear and the search would start over.
Additional details:

Include a link to your private config
https://github.com/rakanalh/dotfiles/tree/master/.doom.d

Steps to reproduce:

Open project
Press SPC s p
type a word and then a space
Observe the first word disappearing and search would start over.

This is still the case. I cannot reproduce this in vanilla Doom. Please check your private config.

Previously, SPC s p would let me enter multiple words for searching the whole project.

This is still the case. I cannot reproduce this in vanilla Doom. Please check your private config.

I don't know what the problem was but now i can see normal behaviour. Thanks!

I don't know what the problem was but now i can see normal behaviour. Thanks!


Expand functionality to fan entities

Will it be possible to expand this front end hac to fan entities as well? I really like the way your slider looks

I'll look into it. I don't have any fans in my setup but I presume it's nothing too complicated


Python 3.10: Allow writing union types as X | Y

What would you like to happen?
Python 3.10 added the support of new syntax as replacement[1] for typing.Union.
[1] https://peps.python.org/pep-0604/
Issue Priority
Priority: 3
Issue Component
Component: sdk-py-core

.take-issue


Adds option to manage miniziti hosts file entries. Adds missing log level

I don't remember if there was a particular reason this approach couldn't work on macOS, and it's unclear whether there's demand for this on macOS. I'd say keep it Linux-only until there's demand.

I don't remember if there was a particular reason this approach couldn't work on macOS, and it's unclear whether there's demand for this on macOS. I'd say keep it Linux-only until there's demand.

I don't have an immediate means or motivation to  set up testing on macOS. Happy to add it as an option if you want it.


SelfCleaningDataSource uses RDD.collect

the collect can use a very large amount of memory here: https://github.com/actionml/PredictionIO/blob/v0.9.6/core/src/main/scala/io/prediction/core/SelfCleaningDataSource.scala#L170
remove should use an RDD to avoid collect.
do we want a removePEvents like we have a wipePEvents?
Also the hard coded timeout seems like a potential problem since it may deal with a very large number of events. As I read it the events must all be removed from HBase in 5 minutes.

added removePEvents, and so removed collect.
Bumped up timeout to an hour.
checked in to master.


Fix pinot-perf annotation processor support

In PR https://github.com/apache/pinot/pull/14185 I changed the way annotation processors are declared in Pinot but I forgot to add the special JMH annotation processors required in pinot-perf. This PR fixes that issue.

cc @bziobrowski

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 0.00%. Comparing base (59551e4) to head (a603dfd).
Report is 1239 commits behind head on master.

:exclamation:  There is a different number of reports uploaded between BASE (59551e4) and HEAD (a603dfd). Click for more details.
HEAD has 53 uploads less than BASE

Flag
BASE (59551e4)
HEAD (a603dfd)

integration
7
1

integration2
3
1

temurin
12
1

java-21
7
1

skip-bytebuffers-true
3
1

skip-bytebuffers-false
7
0

unittests
5
0

unittests1
2
0

java-11
5
0

unittests2
3
0

integration1
2
0

custom-integration1
2
0

Additional details and impacted files
@@              Coverage Diff              @@
##             master   #14306       +/-   ##
=============================================
- Coverage     61.75%    0.00%   -61.76%
=============================================
  Files          2436        3     -2433
  Lines        133233        6   -133227
  Branches      20636        0    -20636
=============================================
- Hits          82274        0    -82274
+ Misses        44911        6    -44905
+ Partials       6048        0     -6048

Flag
Coverage Δ

custom-integration1
?

integration
0.00% <ø> (-0.01%)
:arrow_down:

integration1
?

integration2
0.00% <ø> (ø)

java-11
?

java-21
0.00% <ø> (-61.63%)
:arrow_down:

skip-bytebuffers-false
?

skip-bytebuffers-true
0.00% <ø> (-27.73%)
:arrow_down:

temurin
0.00% <ø> (-61.76%)
:arrow_down:

unittests
?

unittests1
?

unittests2
?

Flags with carried forward coverage won't be shown. Click here to find out more.

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.


Adding the second version of the Ciaone Logo

Please update it. I already sent 1.000 TWT with the memo 1933 in the following transaction:
4DF5E7E78BD63A1230539600D2D88EEADCA506AB71A479DD673D66805B8CF084
Thank you very much.

I still can't see the new logo.. Is there something wrong?


1892 fluid-runner CSV telemetry (#12015)

AB#1892
Needed to unblock OASYS for the eDiscovery work

Add support for choosing to export telemetry as a CSV
Add support for adding additional properties to every telemetry entry

main PR: https://github.com/microsoft/FluidFramework/pull/12015

We need to port this fix in as well don't we https://github.com/microsoft/FluidFramework/pull/12205 to merge this in

Closing this since it is patched to 1.2 which is the only one needed.


Fixes extra line item appearing in distribution form for edit and edit with errors

Resolves #1793
Description
Used the same change as pull request #1805, changed count to size in the edit and update controller actions. Both had an extra line_item appearing on the form previously, and after the changes there are no extra line_items.
Type of change

Bug fix (non-breaking change which fixes an issue)

How Has This Been Tested?
Tested manually. The bug was present whenever we tested before the change, and wasn't present after the change.
Screenshots
Edit page before change:

Edit page after change:

@fosterv2 hey there -- it looks pretty good. I think it would be ready to be merged in after we've addressed the failing tests.


SSO from Redash to Flow

As an IAO analyst or ministry coordinator
I want to single sign on from Redash to Flow
so that when I sign into Redash I am also signed into  Flow automatically

Assumptions & Scope
What are the assumptions for this story?
Single sign on is a configuration of Keycloak
What is IN scope?
Single sign on from Redach to Flow
What is NOT in scope?
Single Sign Out is covered in#1853
Single Sign On from Flow to Redash
Acceptance Criteria
Scenario 1: Sign into Redash
GIVEN a user is signed into Redash
WHEN the user navigates to the Flow app
THEN the the user will already be signed into Flow app too
DOD

[ ] TEST , SSO between FOI FLOW and Redash Reporting App
[ ]  CHECK ON DEV, TEST
[x]  MAKE SURE REDASH use same Keycloack client app
[ ]
[ ]

Scenario 3: xxxxxx
...
Dependencies? What is the impact of this dependency? (If so, link dependency in the ticket, make it visible in a team´s backlog)
Validation Rules? (If yes, list here)
Design
@xxx - please link the Design here
Definition of Ready

[ ] Is there a well articulated User Story?
[ ] Is there Acceptance Criteria that covers all scenarios (happy/sad paths)?
[ ] If there is a user interface, is there a design?
[ ] Does the user story need user research/validation?
[ ] Does this User Story needs stakeholder approval?
[ ] Design / Solution accepted by Product Owner
[ ] Is this user story small enough to be completed in a Sprint? Should it be split?
[ ] Are the dependencies known/ understood? (technical, business, regulatory/policy)
[ ] Has the story been estimated?

Definition of Done

[ ] Passes developer unit tests
[ ] Passes peer code review
[ ] If there's a user interface, passes UX assurance
[ ] Passes QA of Acceptance Criteria with verification in Dev and Test
[ ] Confirm Test cases built and succeeding
[ ] No regression test failures
[ ] Test coverage acceptable by Product Owner
[ ] Ticket ready to be merged to master or story branch
[ ] Developer to list Config changes/ Update documents and designs
[ ] Can be demoed in Sprint Review
[ ] Tagged as part of a Release
[ ] Feature flagged if required
[ ] Change Management activities done?

This is already occurring/resolved in test/prod environments - closing.


What is the role of "FlowModes"?

The number of internal "NetManager._flowModes" in this library is always 0. The AddFlowMode function is also not called。

This is for bandwith control mechanism. It works like in "enet" library. But it tested long time ago. And must be rewritten.
And method AddFlowMode - called by user if needed.


[addon-notes] inaccurate documentation for imported markdown

Describe the bug
In the README for the notes addon it shows this code to load markdown:
import notes from './someMarkdownText.md';

storiesOf('Component', module)
  .add('With Markdown', () => <Component />, { notes });

However this does not actually work to include a markdown file and does not seem to even be the supported method in SB v5 as you can see in the code from the official Storybook Example/addon-notes
To Reproduce
Steps to reproduce the behavior:

Create any new story and a markdown file with some content
Import the markdown file as it shows in the README
Include the notes in the story parameters

The Fix
Import like this instead:
import markdownNotes from './notes/notes.md';

storiesOf('Addons|Notes', module)
  .add('addon notes rendering imported markdown', baseStory, {
    notes: { markdown: markdownNotes },
  });

I've been searching for days. This fix is validated and working.

Thanks for this correction. Is there any chance you can create a small PR for this?

I noticed this as well! Thanks for the correction too!

The fix of jjspace above alas did not work for me with Typescript. Import was complaining that my Markdown file was not found (it was expecting a module). So, my workaround was to convert my markdown file notes.md to a Javascript file notes.md.js:
module.exports = `
# Storybook Notes
This is an example of Storybook Notes in __Markdown__
`

After that I could import it like this:
import markdownNotes from '../notes/notes.md'

and use it like this:
storiesOf('addons|notes', module)
  .add('With Markdown',
    () => <Component />,
    {
      notes: { markdown: markdownNotes }
    }
  )


Experimental support for generating png from html

See example on https://github.com/Karm/dev-null/tree/main/quarkus-openhtmltopdf-java2d

But… this is without any special build item? Just using quarkus-awt?

If we were to create an extension covering openhtml suite of libraries, then there would be buildItems.


GEOMESA-870 CSV deadlock fix

Fixes issues where delimited text convert module deadlocks when processing trailing newlines are found in CSV files (which happens often)
Signed-off-by: Andrew Hulbert<EMAIL_ADDRESS>

:+1:

merged in 0da19baeda18303514f4111694b072e1267dc875


Comparison to Xamarin.Forms.Application.Properties

How does this package compare to the functionality in Xamarin.Forms.Application.Properties?
Some write-up in the readme would be helpful, since the readme implies this package is useful with Xamarin Forms, and yet there seems to be considerable overlap between this package and what's build into Xamarin Forms.

See: https://github.com/jamesmontemagno/SettingsPlugin/issues/56


Update ont diagram to match updated ontology elements

Done in Commit https://github.com/surroundaustralia/fsdf-kg/commit/c6d42967f55834c99dfa3cd7d7476ea2120f1ce5


fix: estimate_gas doesn't reflect changes in mirror-node

Description:

Related issue(s):
Fixes #2379
Notes for reviewer:

Checklist

[ ] Documented (Code comments, README, etc.)
[ ] Tested (unit, integration, etc.)

If possible fix some of the SonarCloud issues


Code Coverage

Issue

There are no unit tests that exist for this project to ensure that all versions are working as intended.
Having code coverage being as high as possible is good practice :)

Solution

Work on creating unit tests for certain events

Logging in (ready.ts)
messageCreate.ts
interactionCreate.ts
etc.

Should look into testing framworks that match typescript and work well with discord bots
Should display that tests are passing in README.md and the code coverage of the codebase

Looked into creating tests using vitest. It does not seem to be useful for now. Will probably look into this later. Typically we will also be testing features before releasing them. Only possibly problem is package deprecation.

Update
Gonna reopen this so we really can have some kind of code coverage for the project to ensure certain parts are working as intended.

We will try to use jest with TypeScript
We also need to make sure we follow this for ECMAScript
Mock Testing will be important
Future thing to consider ---> Redis Testing

Currently we should add these testing dependencies
npm install --save-dev jest @types/jest ts-jest

File Structure Options:

Should the source code for this project be bundled properly for delivery or deployment some where, it would make sense to separate the tests and src directories.
Since we simply listen for specific events, messages, and commands happening in discord (but, don't deploy anything to discord), it is suitable to place any test files within the src directory so they are as close as possible to code that will be tested.

Looked into creating tests using vitest. It does not seem to be useful for now. Will probably look into this later. Typically we will also be testing features before releasing them. Only possibly problem is package deprecation.

Upon further research, it would take more overhead than it is worth to use vitest since we are not using Vite within this project.

Also, let's plan to test the TS source code before it is compiled over to JS. This ensures we are testing the code itself.

Update
Gonna reopen this so we really can have some kind of code coverage for the project to ensure certain parts are working as intended.

We will try to use jest with TypeScript
We also need to make sure we follow this for ECMAScript
Mock Testing will be important
Future thing to consider ---> Redis Testing

Currently we should add these testing dependencies
npm install --save-dev jest @types/jest ts-jest

Mocking with DiscordJS is currently in development with this open-source project called gauntlet

Update

Initial unit testing with vitest for non-discordjs classes, methods, and features started
Testing status (as a whole) now has a badge in the README.md.


Fix Difference of Gaussians prefilter

The panic in the original blockhash gauss_preproc() routine was patched in 2d203d69338ec4a6605af73d87dc6e55d6186ba0 to not panic, copying the behavior of the original code when run in release mode/with overflow assertions disabled.
Both the original code and the patched code are unfortunately not correct and result in very destructive preprocess pass that hurts rather than helps the blockhash algorithm pass (or that of any other image algorithm). The code documents what is supposed to happen with a link to the Wikipedia article on the Difference of Gaussians which describes the purpose of this filter; specifically when using gaussian blur with a ratio of kernels K2:K1 approximately equal to 1.6, you get a fast approximation of a Laplacian of Gaussian transform, used for object detection (in plain English: it gives you edge/outline detection).
The Wikipedia article has an example of what the DoG filter is supposed to look like; here it is reproduced below with the starting image and the image after the DoG filter has been applied:
Original:

Difference of Gaussians Reference:

The idea is that you blur the image twice, the second blur being stronger than the other. Each blur is effectively a low-pass filter that lets low-frequency components (smooth areas of the image) through up to the Gaussian kernel size. Taking the difference of two low-pass filters gives you a band-pass filter that lets through the components of the image that were present in the second image but not the first, and if the kernel value is chosen correctly for the input image, it can be used to approximate areas of certain frequency (what a Laplacian transform would do).
But even all the math aside, if you think about the actual pixel components of the image, you have 0 being black and 255 being white (for a 1-channel greyscale image). If you want the difference between two images, what you really want is to selectively capture something found in one image but not the other. If you perform a wrapping subtraction, you are destroying that information because when something isn't found in one image, you are wrapping around past the zero (which would indicate not found) all the way to 255 (indicating strongly found). So it stands to reason that you can only use an absolute difference or saturating subtraction operation here, never a wrapping one.
Back to the math: the Wikipedia image isn't annotated with what Gaussian kernel values were used, but as an approximation I have run some tests with the different possible implementations of the diff_inplace() using kernel sizes K1=2 and K2=3.2 to demonstrate why a wrapping subtraction does not make sense here, and to show that the correct choice is a saturating subtraction operation.
Wrapping Subtraction (current behavior):

The image above shows the current behavior, normalized to values between 0 and 255, using the following logic:
*lhs = lhs.wrapping_sub(*rhs);

Absolute Difference:

This image shows the inverse of the absolute difference, normalized to values between 0 and 255:
*lhs = 255 - lhs.abs_diff(*rhs);

(Since this is an absolute difference, it does not matter whether you subtract rhs minus lhs or lhs minus rhs.)
Saturating Subtraction (LHS minus RHS):
There are two possible options here, the original code subtracted rhs from lhs (lhs.wrapping_sub(rhs)), so here's what it looks like with the same but using saturating subtraction instead (again, pixel values normalized from 0 to 255 to darken the result):

The code for this is
*lhs = 255 - lhs.saturating_sub(*rhs);

Saturating Subtraction (RHS minus LHS):
The second option, to match the logic above (subtracting the lower Gaussian kernel size image from the higher Gaussian kernel size image), i.e. subtracting lhs from rhs, again normalized to 0-255:

The code for this is what's in the PR:
*lhs = 255 - rhs.saturating_sub(*lhs);

You'll notice that I am always posting the inverse of the operation (255 minus the expression) instead of just the expression. This is because 0 is black and 255 is white, so when you subtract normally you end up with the common area black, but by convention the DoG or Laplacian transform keeps the common area white and the difference in black. Whether you invert the result of the subtraction or not, the subsequent blockhash will work, but if you don't invert then you have the blockhash (or whatever image algorithm, really) of a black image will match the DoG-preprocessed image hash of a white image. It seemed to me that sanity should prevail over performance and a u8 inversion is such a cheap operation compared to the actual image hash algorithm that follows (or any resizing or blurring that takes place beforehand) that I believe it would be stupid not to invert the result.

I hope it is clear from the images above that the original code never handled the Difference of Gaussians preproc filter correctly. As you can see just by looking at the results, the wrapping difference doesn't make any sense to use here even if you ignore the reference Wikipedia image. (Also, I looked for prior art and OpenCV does a saturating subtraction over the pixel values in general for the operation img1 - img2 regardless of the algorithm or filter being applied.)
This is obviously a breaking change, but I think it is fair and I wouldn't even have to think too hard about releasing this in a semver-compatible minor update since the old code was so broken you would never actually get a sane blockhash out of the result (but releasing it as 2.1 probably makes the most sense!). I'm also going to open a separate PR to change the default Gaussian kernel sigma values, as they don't provide the correct ratio to mimic a Laplacian of Gaussian transform.
One final note: as I noted, the images I posted have been normalized to have their pixel values fall between 0 and 255. If you don't do this, some inputs will have lighter overall outlines than other images, but in general the result will be very faint. This does not necessarily affect the subsequent image hash operation because many work on relative values (grey is still darker than the white background), but it is something to consider. The code for normalizing a Greyscale image follows, in case you want to consider applying this normalization as a second step after the Difference of Gaussians:
fn normalize_image(image: &GrayImage) -> GrayImage {
    let (width, height) = image.dimensions();
    let mut normalized_image = GrayImage::new(width, height);

    let (min, max) = image
        .pixels()
        .fold((u8::MAX, u8::MIN), |(min, max), pixel| {
            (pixel[0].min(min), pixel[0].max(max))
        });

    // Avoid division by zero in case all pixels have the same value
    debug_assert!(max >= min);
    if max != min {
        let factor = 255.0 / (max - min) as f32;

        // Normalize the image
        for (x, y, pixel) in image.enumerate_pixels() {
            let value = pixel.channels()[0];
            let normalized = ((value - min) as f32 * factor).round() as u8;
            normalized_image.put_pixel(x, y, Luma([normalized]));
        }
    } else {
        normalized_image = image.clone();
    }

    normalized_image
}

For reference and posterity, here's what the correct algorithm produces when the output isn't normalized:

The changes look sensible, and I was waiting for someone more familiar with it, perhaps criticize it somehow, but nevertheless no one reports anything, so I consider it ok
Thanks!

Thanks for merging. I still need to open the PR to change the default parameters or else it won't be performing this operation - if I get a chance I would like to test out a few different values instead of only the (K1, K2) = (2, 3.2) values used above; particularly to see if there might be a different set of values with the 1:1.6 ratio that reduce the need to normalize the image.


remove beta flag check for v1beta1 object param,results and array result

Changes
This commit removes the beta feature flag check for v1beta1 object param,results and array result. Beta features are considered to be 'stable' for v1beta1 CRDs, so we shouldn't check them.
Related TEP for more context: https://github.com/tektoncd/community/blob/main/teps/0033-tekton-feature-gates.md#new-api-fields
/kind bug
Signed-off-by: Yongxuan Zhang<EMAIL_ADDRESS>
Submitter Checklist
As the author of this PR, please check off the items in this checklist:

[x] Has Docs if any changes are user facing, including updates to minimum requirements e.g. Kubernetes version bumps
[x] Has Tests included if any functionality added or changed
[x] Follows the commit message standard
[x] Meets the Tekton contributor standards (including functionality, content, code)
[x] Has a kind label. You can add one by adding a comment on this PR that contains /kind <type>. Valid types are bug, cleanup, design, documentation, feature, flake, misc, question, tep
[x] Release notes block below has been updated with any user facing changes (API changes, bug fixes, changes requiring upgrade notices or deprecation warnings). See some examples of good release notes.
[ ] Release notes contains the string "action required" if the change requires additional action from users switching to the new release

Release Notes
Remove beta feature flag check for v1beta1 object param, results and array result. Object param, results and array result will be enabled if the  enable-api-fields feature flag is not alpha for v1beta1 CRDs (e.g. Tasks and Pipelines)

@Yongxuanzhang i think there are still some tests sticking around that use "alpha" for object params unnecessarily, e.g. https://github.com/tektoncd/pipeline/blob/ca608f24e722807529a649167e46ecda67df4129/pkg/apis/pipeline/v1beta1/taskrun_validation_test.go#L111. Can you look into this?

/retest

/lgtm

/lgtm

/lgtm

/hold
let me take a look

/retest

/lgtm


Support for Adafruit 1.14" 240x135 Color TFT Display

Utilize the Adafruit 1.14" 240x135 Color TFT Display (https://www.adafruit.com/product/4383) on the Adafruit ESP32-S2 TFT Feather to show provisioning status, connection status, and the last value for any "components" which are sending data to IO.

See: #382


Clarification needed for "Main worker tread count"

In the wiki, it says this:

What do you mean by

and may have an impact on in-game performance.

?
Does it limit the threads the game can use while it's running? That would be quite undesirable and limit performance, wouldn't it?

The main worker executor is used by resource loading, and setting a lower thread count will make loading slower but it does not make the game run slower. What I mean by it affecting in-game performance is that some loading tasks might be ran while the in game, or some mods might use this executor to run stuff. So setting it to a lower number might create more stutters while playing, but it generally shouldn't affect performance that much.


Update repo address

It seems like the repository hosting these releases has changed.

Thanks @parndt, Im going to close this out as we are updating the release flow for the CLI. Thanks for your help!

Awesome, thanks; and it is working today too 😄
porter-dev/porter/porter v0.52.56 -> 0.54.1
==> Fetching porter-dev/porter/porter
==> Downloading https://github.com/porter-dev/cli/releases/download/v0.54.1/porter_0.54.1_darwin_arm64


{AKS} Update the implementation of aks update to adopt the decorator pattern

This checklist is used to make sure that common guidelines for a pull request are followed.
Update the implementation of aks update to adopt the decorator pattern.

For new extensions:

[ ] My extension description/summary conforms to the Extension Summary Guidelines.

About Extension Publish
There is a pipeline to automatically build, upload and publish extension wheels.
Once your PR is merged into master branch, a new PR will be created to update src/index.json automatically.
The precondition is to put your code inside this repo and upgrade the version in the PR but do not modify src/index.json.

AKS

All test cases from azure-cli/acs has passed.
After several retries (run 1, run 2, run 3), only two test cases (test_aks_create_with_http_proxy_config, test_aks_snapshot) from azure-cli-extensions/aks-preview would fail.
After preliminary analysis, the cause of these errors has nothing to do with the change. Will investigate and solve the problems with feature owners.


url can not update automatically

when i edit post title the url should be updated but i found it not
my version is 0.6 and casper 1.25

Closing as a duplicate of #5062