go/parser: non-contiguous comments grouped together

What version of Go are you using (go version)?

$ go version
go version devel +adcb2b1e7a Wed Jul 3 23:08:27 2019 +0000 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="on"
GOARCH="amd64"
GOBIN=""
GOCACHE="/home/myitcv/.cache/go-build"
GOENV="/home/myitcv/.config/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GONOPROXY=""
GONOSUMDB=""
GOOS="linux"
GOPATH="/home/myitcv/gostuff"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/home/myitcv/gos"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/home/myitcv/gos/pkg/tool/linux_amd64"
GCCGO="gccgo"
AR="ar"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD="/home/myitcv/gostuff/src/github.com/myitcv/playground/go.mod"
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-build876576551=/tmp/go-build -gno-record-gcc-switches"

What did you do?
Consider the following:
package main

import (
	"go/ast"
	"go/parser"
	"go/token"
)

func main() {
	src := `
package p

type S struct {
	// First comment

	// Second comment

	Name string
}
`
	fset := token.NewFileSet()
	f, err := parser.ParseFile(fset, "", src, parser.ParseComments)
	if err != nil {
		panic(err)
	}
	ast.Print(fset, f.Comments)
}

Under go1.12.6 this prints:
     0  []*ast.CommentGroup (len = 2) {
     1  .  0: *ast.CommentGroup {
     2  .  .  List: []*ast.Comment (len = 1) {
     3  .  .  .  0: *ast.Comment {
     4  .  .  .  .  Slash: 5:2
     5  .  .  .  .  Text: "// First comment"
     6  .  .  .  }
     7  .  .  }
     8  .  }
     9  .  1: *ast.CommentGroup {
    10  .  .  List: []*ast.Comment (len = 1) {
    11  .  .  .  0: *ast.Comment {
    12  .  .  .  .  Slash: 7:2
    13  .  .  .  .  Text: "// Second comment"
    14  .  .  .  }
    15  .  .  }
    16  .  }
    17  }

On tip this shows:
     0  []*ast.CommentGroup (len = 1) {
     1  .  0: *ast.CommentGroup {
     2  .  .  List: []*ast.Comment (len = 2) {
     3  .  .  .  0: *ast.Comment {
     4  .  .  .  .  Slash: 5:2
     5  .  .  .  .  Text: "// First comment"
     6  .  .  .  }
     7  .  .  .  1: *ast.Comment {
     8  .  .  .  .  Slash: 7:2
     9  .  .  .  .  Text: "// Second comment"
    10  .  .  .  }
    11  .  .  }
    12  .  }
    13  }

What did you expect to see?
Non-contiguous comments not to be grouped.
What did you see instead?
Non-contiguous comments grouped.

This seems to be a direct consequence of CL 161177 to fix issue #10858.
However, issue #10858 was about godoc not displaying the entire documentation of structs, and I think it should be fixed inside godoc, not by changing go/parser to treat a comment separated by a blank line as part of a comment group.
go/ast.CommentGroup is clearly documented (emphasis mine):

A CommentGroup represents a sequence of comments with no other tokens and no empty lines between.

Unless I'm mistaken, this is too big of a change to low-level primitives like go/parser and go/ast to fix a minor godoc issue that I imagine can be fixed in godoc itself (but I haven't looked into this yet). I suspect many tools may depend on the current meaning of ast.CommentGroup and we should not change it. But I will defer to @griesemer on this.
Based on my current understanding, I think we should roll back CL 161177 and try to fix #10858 in a less disruptive way.

I see. The CommentGroup thing is indeed an issue. However, the go doc output seems to be more accurate to me, since that was the whole point of #10858. Would you not expect // Hello to be printed ?
In any case, up to @griesemer to take a call.

cc @andybons as an FYI from a release perspective

I'm conscious of the fact that we're likely rapidly approaching beta2.
@agnivade - I think it makes sense to create a CL to revert this change in anticipation of @griesemer's decision. That way, at least, we're ready to hit "submit" (try bots having run etc) and not hold things up any more. Would you agree?
cc @mvdan

Looking at this again, I believe @dmitshur is correct; this should perhaps be fixed in godoc. In retrospective, we should not have changed the parser for this. My apologies, I should not have missed this.
@agnivade Thanks for providing the rollback CL.

A bit more on this subject:

Changing the parser - while it fixed the godoc issue with a relatively minor change - broke the more fundamental assumption about comment groups documented explicitly. We don't know what other tools/packages make the assumptions that comment groups have no empty lines.

It may be harder to fix issue #10858 in go doc, but that is probably the right place. Generally, it's not always 100% clear which comments belong together; so we should make that decision in a place with fewer dependencies (i.e., godoc rather than go/parser), so we can adjust it more easily as needed.

Thank you everyone for helping resolve this issue. I considered sending a CL to add a test so this ast.CommentGroup behavior doesn't regress without us noticing, but then I realized it would have to be a very specific test (comments separated by a blank line within a type declaration) and decided it wouldn't be as helpful as I originally thought. I can still send it if people think it'd be helpful.
I've added issue #10858 to a list of godoc-related issues I'm tracking and will be on the lookout for a way to resolve it in the future.


System.Reactive (3.1.0) forces dependency on NETStandard.Library

I am not sure if that is the intention, but we cannot use System.Reactive (3.1.0) in .NET 4.5
There seems to be a dependency on NETStandard.Library.1.6.0 and other .NETCore libraries.

Is there a way we can install 3.1.0 without these dependencies? Or are we stuck with 3.0.0?

+1

I am also running into an issue w/ <IP_ADDRESS>, where the identity continues to be <IP_ADDRESS>?  Additionally, it appears the dll in .NETStandard is versioned 3.0.1000.0, and the net45 version is <IP_ADDRESS>.  This is not only confusing me greatly, but is confusing my poor tests which are now breaking because of this. 😛  I will rollback until I get more clarity around this.

cc @onovotny for :eyes:

Two separate issues:

Dependency on NETStandard.Library for all projects. This was done to ensure all referenced assemblies are correctly unified against all of the framework versions. It's possible that the net4x versions may be able to do without that and we can investigate that for the next release. In the interim, that should not block anything as using NETStandard.Library is fully supported for net45. My recommendation would be to use project.json for your NuGet packages instead of packages.config as it provides a huge number of benefits, including transitive dependencies. My blog shows you how: https://oren.codes/2016/02/08/project-json-all-the-things/ and there's a converter add-in here: https://marketplace.visualstudio.com/items?itemName=TaylorSouthwickMSFT.NuGetPackagetoProjectjsonConverter

Version numbers. Those are correct as per #205. You can see the logic implemented in the GlobalAssemblyVersion.cs file in Ix.NET\Source. System.Interactive cross-compiles for netstandard1.0 and net45. Thus, a desktop .NET app will see a 3.0.1000.0 version while other project types will see the <IP_ADDRESS> version. This is inline with the API versioning mentioned in #205 discussion. For desktop .NET Projects, the build system should generate binding redirects automatically that unify this.

Ahhh thank you @onovotny for the explanation!  I am using NuGet3 which doesn't generate those redirects, unfortunately (captured in https://github.com/NuGet/Home/issues/3372 please upvote :) ).  I will get in the habit of installing a package in an empty class library (NuGetv2 ) and see if it generates anything there before dropping complaints in a repo. 😄

@Mike-EEE For the binding redirects, it should not be NuGet that's doing it...it's done as part of the build now.
For older projects, they may not have AutoGenerateBindingRedirects set though:
https://msdn.microsoft.com/en-us/library/2fc472t2(v=vs.110).aspx

We can fix this for desktop .NET for Ix and Rx. Note that for all other platforms, the full NETStandard.Library references will still be needed.

Ah @onovotny I have another layer of complexity in my solution that might be causing my problems in this case.  That is, I am running PostSharp and it runs in its own AppDomain during build.  It also does not yet support NuGet3.0 so it requires specific configuration to work property.  After a bunch of trial and error I was able to get everything configured and working properly again. 👍

@Mike-EEE Can you please try the latest 3.1.1 version from the CI feed (https://dotnet.myget.org/gallery/rx) and confirm it works as expected for you?
We can get this tagged and pushed publically very soon.

Ah, I didn't see the build number until now, @onovotny.  I was able to install 00002, but that doesn't have any assemblies.  It is also the only build that is available when I connect to that feed (and when I view it here).  Is there another location I should be looking at, perhaps?  Or maybe a permissions issue?

@onovotny Just tried, System.Reactive 3.1.1-build-00002 still pulls the whole .NET Standard with it. I suspect that's because System.Reactive.Interfaces is still NETStandard.Library-only.

Please look at 00006. MyGet's indexing was being slow, should be showing up now.

@onovotny Tried 00006. Now it's much better, but System.Reactive still tries to pull some extra packages:

@krs500 Build 00007 should have that addressed if you can give that a shot.

@onovotny The build 00007 now installs only what is needed 👍

Great, 3.1.1 is on NuGet now.


EasyRPGMaker fails on install

I've flashed the most recent RetroPie onto a Pi0 but am unable to install the EasyRPGMaker from this script.
Fails on "Could not install package(s): libsdl2-mixer-dev libpng12-dev libboost-dev."
Anyone have any insight? Would love to get this running.

Install the packages manual and after install the rpg maker

This repo is not intended for use on a Pi0. If you are not on Pi3/Pi4 with latest OS, all bets are off.


Dynamometer does not support negative block id's

Dynamometer does NOT support negative block id's, which results in blocks with negative id's never being reported by any simulated DataNode.
A change has been made to XMLParser.java in our branch of Dynamometer so that negative block id's are also dealt with.
Due to the change made above, we have to change SimulatedMultiStorageFSDataset.java as well.
In Dynamometer, each DataNode has more than 1 SimulatedStorage to manage, and this following Map is maintained by each SimulatedStorage in a simulated DataNode. Moreover, a SimulatedStorage could be involved in multiple blockpools.
Map<blockpool id, Map<block, block information>>
To access a given block (associated with a blockpool id) on a simulated DataNode, we have to
( i) determine which SimulatedStorage this given block belongs to according to its block id, and then
(ii) use the associated blockpool id to retrive Map<block, block information> corresponding to the block to be accessed.
The SimulatedStorage's managed by a DataNode are arranged on an ArrayList and each SimulatedStorage on the ArrayList could be accessed by a "non-negative" integer upper-bounded by the size of that ArrayList, exclusive. To determine the SimulatedStorage a given block belongs to, the original Dynamometer simply uses (block id % number of simulated storages) as the index to access the ArrayList mentioned above. Hence, once we have a negative block id, an ArrayIndexOutOfBoundsException will be triggered. Some changes have been made in SimulatedMultiStorageFSDataset.java so that a negative block id is properly taken care of.

Will submit a PR on behalf of @fangyurao


Text cutoff in Mermaid diagram

Repro:
flowchart TD
	subgraph 30
    A[30] --> B[3]
    A --> C[10]
    C --> F[2]
    C --> G[5]
    end

  subgraph 75
    J[75] --> K[5]
    J --> L[15]
    L --> M[5 ❌]
    L --> N[3]
   end

The 10, 75 and 15 are all a bit cutoff. The ❌ is only half visible.
It's subject to overflow: hidden which is an attribute in the foreignObject user agent stylesheet. I've tried overriding the overflow value, but can't find a combinator or selector which will allow it in the CSS.

Thank you for trying out this library. I apologize for the delay in my response. I think issue #18 might provide some hints regarding the CSS selectors.
If you'II write like a bellow...
\```mermaid[mermaid image]
flowchart TD
   ....
\``````

(remove backslash)
render like this
<embed title="mermaid image">

Does this support you ?


Giara fails to start: RuntimeError: could not create new GType: giara+giara_clamp+GiaraClamp (subclass of AdwClamp)

Describe the bug
giara fails to start but merely prints a python backtrace.
Steps To Reproduce
Steps to reproduce the behavior:

$ nix-shell -p giara or add "pkgs.giara" to environment.systemPackages
and rebuild the system
$ giara

/nix/store/dixynjprqk0fzbhkryv6j049svkx6b98-python3.9-pygobject-3.42.0/lib/python3.9/site-packages/gi/types.py:217: Warning: cannot derive 'giara+giara_clamp+GiaraClamp' from final parent type 'AdwClamp'
  _gi.type_register(cls, namespace.get('__gtype_name__'))
Traceback (most recent call last):
  File "/nix/store/aqji0xafsdyzsd7yc7jiy33ylckbcc12-giara-1.0/bin/..giara-wrapped-wrapped", line 68, in <module>
    from giara import __main__
  File "/nix/store/aqji0xafsdyzsd7yc7jiy33ylckbcc12-giara-1.0/lib/python3.9/site-packages/giara/__main__.py", line 8, in <module>
    from giara.app_window import AppWindow
  File "/nix/store/aqji0xafsdyzsd7yc7jiy33ylckbcc12-giara-1.0/lib/python3.9/site-packages/giara/app_window.py", line 4, in <module>
    from giara.main_ui import MainUI
  File "/nix/store/aqji0xafsdyzsd7yc7jiy33ylckbcc12-giara-1.0/lib/python3.9/site-packages/giara/main_ui.py", line 4, in <module>
    from giara.main_deck import MainDeck
  File "/nix/store/aqji0xafsdyzsd7yc7jiy33ylckbcc12-giara-1.0/lib/python3.9/site-packages/giara/main_deck.py", line 2, in <module>
    from giara.left_stack import LeftStack
  File "/nix/store/aqji0xafsdyzsd7yc7jiy33ylckbcc12-giara-1.0/lib/python3.9/site-packages/giara/left_stack.py", line 3, in <module>
    from giara.sections import PostListSection
  File "/nix/store/aqji0xafsdyzsd7yc7jiy33ylckbcc12-giara-1.0/lib/python3.9/site-packages/giara/sections.py", line 2, in <module>
    from giara.post_preview_listview import PostPreviewListView
  File "/nix/store/aqji0xafsdyzsd7yc7jiy33ylckbcc12-giara-1.0/lib/python3.9/site-packages/giara/post_preview_listview.py", line 5, in <module>
    from giara.giara_clamp import GiaraClampScrollable
  File "/nix/store/aqji0xafsdyzsd7yc7jiy33ylckbcc12-giara-1.0/lib/python3.9/site-packages/giara/giara_clamp.py", line 4, in <module>
    class GiaraClamp(Adw.Clamp):
  File "/nix/store/dixynjprqk0fzbhkryv6j049svkx6b98-python3.9-pygobject-3.42.0/lib/python3.9/site-packages/gi/types.py", line 226, in __init__
    super(GObjectMeta, cls).__init__(name, bases, dict_)
  File "/nix/store/dixynjprqk0fzbhkryv6j049svkx6b98-python3.9-pygobject-3.42.0/lib/python3.9/site-packages/gi/types.py", line 205, in __init__
    cls._type_register(cls.__dict__)
  File "/nix/store/dixynjprqk0fzbhkryv6j049svkx6b98-python3.9-pygobject-3.42.0/lib/python3.9/site-packages/gi/types.py", line 217, in _type_register
    _gi.type_register(cls, namespace.get('__gtype_name__'))
RuntimeError: could not create new GType: giara+giara_clamp+GiaraClamp (subclass of AdwClamp)

Expected behavior
Start up the graphical reddit client.
Additional context
Add any other context about the problem here.
Notify maintainers
@dasj19
Metadata
 - system: `"x86_64-linux"`
 - host os: `Linux 5.15.32, NixOS, 22.05 (Quokka), 22.05pre368234.fd364d26885`
 - multi-user?: `yes`
 - sandbox: `yes`
 - version: `nix-env (Nix) 2.7.0`
 - channels(root): `"nixos"`
 - channels(kn): `"nixos"`
 - nixpkgs: `/nix/var/nix/profiles/per-user/root/channels/nixos`

Thanks for reporting and sorry for the answering delay.
I have looked into it and there is no easy fix for version 1.0 and version 1.0.1 requires a new dependency which is not yet in nixpkgs. I'll take a second look at it when time allows.

Yeah, the package requires an older version of libadwaita. And 1.0.1 requires https://gitlab.gnome.org/jwestman/blueprint-compiler.


Make sure poison items can't be dropped on furniture

In the poison items haunt, ensure that the location of the item is not on top of furniture.

Place this on low priority. This will require some work.


Balances

Adding in a new semantic type to represent balances.  This will make it much easier for different machine learning techniques and statistical analyses to operate directly on balances.
Note that this will be an important component for the upcoming gneiss release.

Coverage decreased (-2.2%) to 76.768% when pulling 5b741fa123e73d47aa39c0c3dc8f37a1da0c9bab on balances into ff899189f280807f61d98cb4e90ca555e81c2cc2 on master.

For my own edification, what constraints does this new variant-type imply?

This balance type doesn't really have constraints.  Since a single balance refers a log ratio, that log ratio can stretch anywhere from negative infinity or positive infinity.
The main reason I'm hoping to have this in the q2-composition package is to make it easier to pass inputs from various q2 packages easier.  For one, there are a few different R packages that perform similar calculations with balances.  In addition, it would be great if it were possible to directly pass balances into other techniques, such as random forests, logistic regression, PCA, ...

Also, the Balance type can only be generated from a Composition type.
And this can only be done using the ilr transform. We'll have a conversion
function in gneiss shortly after this is merged.
On Mar 30, 2017 11:25 AM, "Evan Bolyen"<EMAIL_ADDRESS>wrote:
For my own edification, what constraints does this new variant-type imply?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/qiime2/q2-composition/pull/34#issuecomment-290482020,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AD_a3ZuSAlFZ2camu6rkW02Mrmp5jlmBks5rq-WEgaJpZM4MtunI
.

Coverage decreased (-2.2%) to 76.768% when pulling af3d9ff2d2689522839b0fdbb9661a5831c696f8 on balances into ff899189f280807f61d98cb4e90ca555e81c2cc2 on master.

I briefly discussed this with @ebolyen .
The main concern with this PR is that this type Balance is not generic enough, and may not differentiate between the different types of balances.
To give a little context, there are two types of balances.  There are the balances that are computed using the ilr transform, which is used by gneiss and phylofactor.  There is another type of balance which is used in philr that can be calculated using the weighted ilr transform, which incorporates branch length.
The standard ilr transform will cover the vast majority of the use cases involving balances.  If we want to add philr to the standard q2 workflow, we can add a WeightedBalance type.  Does this sound like a reasonable plan forward @ebolyen @gregcaporaso ?

This sounds reasonable to me, but I'm interested in what @ebolyen thinks as you and he discussed it.

I think this makes sense, but I don't really understand compositional statistics.
My main concern was whether there would be other transformations which could also be considered a balance. This could be a problem if you used two different transforms, producing two FeatureTable[Balance] artifacts and then tried to merge them (which doesn't seem like a valid operation to do on compositional data anyhow).
After reading a bit and looking at some of slides @mortonjt's shared a while back, it sounds like the balance is what is used to create the basis for the ILR transform, so this term doesn't really apply to other transforms, which don't use the orthonormal basis (how wrong am I here?).
In which case, I think these type names sound great, and WeightedBalance also makes sense for philr I think.

I've updated the type definition to fit in with the new updates.
If there are no objections - do you guys mind if we could merge this in?  This would make the refactoring process in Gneiss much easier.  I'm currently running into import issues because of this new type.

Thanks!
On Tue, May 2, 2017 at 10:44 AM, Evan Bolyen<EMAIL_ADDRESS>wrote:

Merged #34 https://github.com/qiime2/q2-composition/pull/34.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/qiime2/q2-composition/pull/34#event-1066002857, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AD_a3T7EPEKUgftpqWo4ePiAQC2AeXQWks5r12uCgaJpZM4MtunI
.


WIP: Improve protocol test error handling

Changes how errors/exceptions are dealt with in the ProtocolTestBase and the TestController.

ProtocolTestBase now delegates error details to the protocol test job, providing methods that hid this detail.  The reason for this is Krill::Manager eats all exceptions and puts them in the backtrace of the job, so attempting to catch the exception does nothing.
TestController uses the new ProtocolTestBase methods instead of the removed error attribute.
TestController catches Minitest::Assertion to recognize test failure, and StandardError for other test errors.
TestController returns different messages for test errors, protocol errors and assertion failures.

This is a WIP b/c I'm still working on improving error recognition and reporting.

Additional changes to TestController:

Change to catch exceptions for possible errors in test code that are not subclasses of StandardError: SyntaxError and SystemStackError.
Filter stack trace to hide the aquarium stack by looking only for errors within eval.
Add error_type to response to allow more precise templating by Nemo.


Replication lag improvement

WHAT is this pull request doing?
Before this we only counted data written to the follower socket as lag, we didn't count the data in the "action queue" of the follower.
This will change so we count data written to the action queue.
HOW can this pull request be tested?
Run follower specs

hmm @dentarg, cla assistant skipped on my pr here, but not here...

@kickster97 Hmm, I wonder if skipping for COLLABORATOR too would help, reading https://stackoverflow.com/questions/63188674/github-actions-detect-author-association it sounds like it. I can experiment some.

I think (hope) the CLA workflow behaves better now going forward. Closing/re-opening didn't really work as I expected, the workflow only ran on the close event: https://github.com/cloudamqp/lavinmq/actions/workflows/cla.yml?query=branch%3Areplication-lag-improvement – I unlocked this PR with the GitHub CLI and also created https://github.com/cloudamqp/lavinmq/pull/654

This will also count all data that needs to be sent as lag, not only "message data" (i.e. it counts filename length etc too).

This will also count all data that needs to be sent as lag, not only "message data" (i.e. it counts filename length etc too).

Maybe it should be changed to only count message data.

This will also count all data that needs to be sent as lag, not only "message data" (i.e. it counts filename length etc too).

Maybe it should be changed to only count message data.

Is it not more accurate if we count all data? Why would we only want to count message data?


supporting env vars in yaml files under /etc/dd-agent/conf.d

Hi,
A code to run over all of the yaml conf files and replace any env var with it related value.
I actually copy paste most of the code but I tested it locally and it looks fine.
There is also the option to use envsubst, but it was not installed on the image, so I choose to implement it with regex.
Thanks,
Shay

Hi @shayts7, thanks for contributing!
May I ask what your use case is? If the config you want to auto-fill will be used to monitor stuff running in containers we're actually building a service discovery feature that should help. It's still in beta right now but will go out with 5.8 (so in a matter of weeks) and we provide images that embed it using the tags sd-beta and sd-kubernetes-beta (depending on if you run them in kubernetes or not) instead of latest as well as some documentation here: https://github.com/DataDog/dd-agent/wiki/Service-discovery
Let me know if that helps.

Hi @hkaj,
I wanted to monitor etcd, but I wanted to do it like any other application (running in containers) in the host does.
our applications access etcd using the local host ip, so I wanted to push the host ip into datadog configuration. The way I choose doing it is using capability of replacing ENV VARs when datadog agent start running, using this capability the only thing I had to do is to pass the host ip as env var to datadog agent docker container.

I have few questions about the service discovery feature:
From the doc: "if no template is found in the user-supplied configuration store, the Agent will try to match the container image with a list of auto-configurable checks (the simplest ones, mostly)" - do you have a list of the auto-configurable checks?
If for instance I want datadog to monitor my container - is there any protocol I need to applied in my REST API layer? (for instance: I can expose /system-health REST endpoint and configure datadog to monitor it. The question is - what is the payload that my endpoint should return to datadog?)
As for security - assume that my service blocks any API call for non-authorized clients (let's say my service support oauth), how would you recommend to configure the authentication tokens in datadog's service discovery configuration?
What would you recommend me to do if I already have service discovery for my services? (we use DNS round robin using registrator and skydns)
In that case I see advantage for what you suggest and that is that I can be sure that any container in my cluster will be monitored. Using our service discovery only the service as a whole will be monitor but I cannot guarantee that any container composing the service will be monitored.
Thanks,
Shay

Hi @shayts7

do you have a list of the auto-configurable checks?

here is the list of auto-configurable checks and the config options they will have: https://github.com/DataDog/dd-agent/tree/haissam/service-discovery/conf.d/auto_conf

If for instance I want datadog to monitor my container - is there any protocol I need to applied in my REST API layer?

The service discovery feature is actually very simple. It queries the docker daemon API for running containers, compares their images to images for which it has a configuration template (either user-provided - through a configuration store, or embedded in the agent: the auto-conf directory I mention above) and enable agent checks based on these templates.
So if you want the agent to report custom metrics coming from your own containerized app you will need to write your own custom check that can collect these stats from your container (a health API endpoint is indeed a good way to expose this data) and add a config template that enables that check for your custom image in the config store.
Documentation about writing a custom check is available here.
Though before writing a custom check I'd advise looking at existing ones that might meet your needs.
For example the http check may well be enough depending on your use case. If you use java services, the JMX integration could also help, etc.

how would you recommend to configure the authentication tokens in datadog's service discovery configuration?

The current (beta) version of service discovery doesn't provide any additional security layer. Auth tokens, and credentials in general need to be stored in the configuration template (so in etcd or consul). For the next iteration we're considering more secure ways to store these.

What would you recommend me to do if I already have service discovery for my services?

The way service discovery is done in the datadog agent is independent of any other service discovery mechanism you might be using already. It considers docker containers individually and only cares about the image it's running, not the service it's part of. Enabling service discovery for the agent will not change how your other service discovery mechanism works.
My recommendation would be to add the service as a docker label to your containers if possible, this way the agent can pick it up, and add it as a tag which will be valuable when you will want to visualize your infrastructure or graph metrics per service.
Let me know if you have any other question.

Thanks for the detailed info!

closing as this is likely fixed by service discovery.
Feel free to reach out if not.


Import HIV Trace JSON files

HIVTrace produces a JSON file that describes the network that it constructed. There is an object laying out all of the edges, an object laying out each of the nodes, and a third object laying out all of the singleton (i.e., unconnected) nodes.

need to discuss JSOn import in general. Angular is assigning different thresholds than MT DEV at launch. As a result , the loaded network looks different between them both. MT DEV sets a threshold of 7 SNPs, while Angular has the deafult setting as the default for TN93 which is 0.015. As a result it has far fewer links. Once I increase the threshold to 7, the networks match (at least at first glance). But the whole point of JSON input is that the user need to play with threshold settings. Lets discuss at the meeting on 7/27

Tested and it works. There is a tiny difference in the number of nodes between the network built using the HIVTrace JSON (189 nodes, 201 links) and that using FASTA (188 nodes, 199 links). NOt sure why this is and how crucial

WIll check to find discrepant node


Default delays between Tap and Press are weird

I saw in the documentation that nothing seem to happen for tap/press on screen between 200ms and 600ms ?
Is there a specific reason ?
Hammer.js used 250ms max duration for Tap and 251ms min duration for Press.
Maybe it could be good idea to to the same for contact.js ?

Thanks for bringing this up. The main question is if the shorter time of >251ms feels  right for the end-user. If I want to trigger a press on the iPhone home screen, I have to wait longer than 251ms. On the other hand, I can trigger a tap after more than 250ms. The same seems to be the case on my Android test devices home screen. I did a quick research and it seems to be that mobile devices use >=500ms for Press.
I think there should be no gap between tap and press.  Maybe it is good to be consistent with the behavior on mobile devices. That would mean 499 max duration for Tap and 500 min duration for Press.
What are your thoughts on this?

Yeah, it can be a good default values ;) As the author you decide ;)
The point is just to remove the actual default gap between tap and press where nothing happen !


Logistic network items show as unavailable

Describe the Bug
Searching for items that are in the logistics network show as unavailable (red)
To Reproduce
Steps to reproduce the behavior:

Press Ctrl-F
Search for any item that is in the logistics network chests
Item shows up as unavailable (red)

Fixed by re-enabling my personal logistics network in the menu, didn't realize it had turned off somehow.

Fixed by re-enabling my personal logistics network in the menu, didn't realize it had turned off somehow.

Yeah, sometimes that happens to me as well. It's annoying.

Yeah, sometimes that happens to me as well. It's annoying.


Fix the editor path icon when switching from dark to light theme

The icon now switches themes correctly when going from a dark theme to a light theme (or vice versa).
By "editor path icon", I mean the icon at the bottom of this screenshot:

Thanks!


Bevy, on Web and WebGL, doesn't exit winit's Event Loop cleanly after a GPU crash. It panics twice with already borrowed: BorrowMutError

Bevy version
Latest released Bevy atow, which is 0.13.2
This can be reproduced at the Bevy examples posted on the web
Relevant system information
I am able to reproduce this both with Google Chrome and Firefox, both in a M1 Macbook and a Windows 11 laptop
What you did (repro steps)

Open this link: https://bevyengine.org/examples/Application/logs/
Open the JS console on the devtools (you can press F12)
Disable info logs to not clutter your console with the messages that the example logs every frame

Click on the example canvas to gain focus
Press P to panic, as usual
You will see an error like this. This is normal and expected, it's a deliberated panic, part of the example:

Now, let's reproduce the actual issue

Refresh the page, click to gain focus. Now, instead of pressing P:
Write this into the JS console to simulate a GPU crash document.querySelector("#bevy").getContext('webgl2').getExtension("WEBGL_lose_context").loseContext()
The example will crash, this is expected too, it is a known issue. For reference, see:

https://github.com/bevyengine/bevy/issues/12681
https://github.com/bevyengine/bevy/issues/10456

The crash will of course be related to wgpu, glow, and graphics code, like this:

Unexpected behaviour comes here.

Instead of showing only 1 panic: the panic that occurred
FAIL: It shows an additional BorrowMutError panic. See:

wasm_example.js:502 panicked at [...]/winit-0.29.15/src/platform_impl/web/event_loop/runner.rs:625:30: already borrowed: BorrowMutError
What went wrong
- what were you expecting?
I was expecting to see a single crash. This is needed in production environments to uniquely report crashes for analytics and error tracking, and avoiding redundancies.
- what actually happened?
Winit seems to be exiting the event loop in a wrong way, causing yet another panic, which is then handled by the console_error_panic_hook and logged as well
Additional information

As an alternative to simulating a GPU crash by calling the WebGL2 extension, in Google Chrome, we can also write chrome://gpucrash/ in the address bar and press enter to simulate it at a browser level. Same happens
This can't be reproduced on the WebGPU example because WebGPU doesn't crash upon a GPU context loss
I'm opening the issue here instead of on Winit's repo because, since Winit web examples don't use WebGL nor graphics, I couldn't reproduce this on them.
Update: I've tried setting up a minimal Winit loop example that crases when losing the WebGL context, and I haven't been able to reproduce this, which suggests it may be caused by Bevy, or by how Bevy sets up the Winit's loop?

Without diving to deep into this, my assumption is that this is a re-entrancy issue, ergo after a panic you should not re-enter the Wasm module. See https://github.com/rust-lang/rust/issues/117344.
Please let me know if I got this wrong!

Yes, that's exactly what this is. In native it's impossible that a program panics twice. However, in this case something (the event loop? Some browser's animation frame call back?) is calling the WASM module after it has originally crashed.
It is a bit random, and can be influenced by the browser tab being on focus or not. In fact, I have seen the 2nd BorrowMutError panic happen a considerable amount of time after the original panic occurred.
Thankfully, despite of its randomness, I was able to find reliable repro steps to reproduce it with this Bevy example, hence I decided to open the issue to share it.

Just to clarify though, this is not something that can be fixed by Bevy or Winit, at least not properly.
This is a Rust issue (https://github.com/rust-lang/rust/issues/117344) and should be fixed in Rust itself. It could also be fixed in wasm-bindgen (https://github.com/rustwasm/wasm-bindgen/issues/3687), but there are no current plans to do so because it has to be solved in Rust either way.

Just to clarify: this is not something that can be fixed by Bevy or Winit, at least not properly.

Yep indeed, thx!
And, as an update for Bevy side, I was able to reproduce this problem on Winit's minimal web example with this code, which at least discards Bevy as being the culprit.
Because of that, I guess this issue can be closed as not planned to wait for Rustc to fix this in their side. I'll leave that to Bevy maintainers in any case.
@daxpedda, for the same reason, I guess it is not necessary to open the same issue to Winit with these steps to reproduce (the repro steps in the code linked above), right? Let me know if you think otherwise 🙂

Hey @daxpedda, can I make you a question about this?
If I understand it correctly, what is happening here is that the Rust's WASM module panics, but later on "something" calls into it again.
This "something" is, in this case, Winit's event loop. Winit subscribes to a callback from web_sys, and the problem is that, when the app panics, it never has the chance to unsubscribe from it, right? So, when that callback is called next, after the panic, it panics again because of this BorrowMutError (or, in other words, it throws an RuntimeError: unreachable exception).
So, my question is, if I'm correct about this, shouldn't this be handled by Winit, by setting up a panic hook that unsubscribes from this callback?

Your description of the problem is correct.

So, my question is, if I'm correct about this, shouldn't this be handled by Winit, by setting up a panic hook that unsubscribes from this callback?

Panic hooks can only be set by the application, not a library.
For arguments sake, Winit could find a way to unhook all events when at least panicking inside of Winit itself, though this would be difficult and introduce significant code complexity. It doesn't really solve the problem, if the user panics or any other library, it would hit the same issue again. Bevy itself uses other libraries that hook up into events, e.g. Wgpu. If you are using Egui you would also hit similar problems.
It is safe to say that any reasonable solution to this problem has to live in either Rustc or wasm-bindgen.
In the meantime an effective solution has to live in JS and therefor deployed by the user and can't be handled by a Rust library. Alternatively users can set up some sort of application shutdown in side their panic handler when running in the browser.

Panic hooks can only be set by the application, not a library.

You sure? Bevy set ups its own one here:
https://github.com/bevyengine/bevy/blob/aa80e2d658ed1b84787fd512839a8c84238979ef/crates/bevy_log/src/lib.rs#L202-L208
I don't know what happens when user code set ups its own. Is it overriden? They can be chained with update_hook or take_hook

though this would be difficult and introduce significant code complexity

totally true, I gave a quick try to this myself and I wasn't able

if the user panics or any other library, it would hit the same issue again

Oh, really? I didn't know that, I thought a installed panic hook was called for any code panicking in that thread, like being totally global, not per library.

It is safe to say that any reasonable solution to this problem has to live in either Rustc or wasm-bindgen

Yep. There is something I don't still get about that core solution: if the WASM module get poisoned after a panic so that it cannot be accessed further in any way, what will happen when a browser callback calls into it like it's currently happening? Will it throw an exception? If that's the case, from the JS point of view, won't it be the same, just with a different type of exception?
I found this stack overflow answer to what I think is the same issue, but it sounds too easy to be true, just using the parking_lot crate, that Winit already stopped using, I guess for a good reason:

https://github.com/rust-windowing/winit/pull/2423

Panic hooks can only be set by the application, not a library.

You sure? Bevy set ups its own one here:

Apologies, I meant "should".
While it is true that Winit could "update" the panic hook, instead of overwriting it, it would be difficult to remove it again after Winit is finished. If Winit does this, other libraries might want to do the same, registering multiple competing panic hooks which would be difficult to remove/untangle again.
Among other reasons, e.g. users should ultimately be in control of what happens in case of a panic, it is not recommended to set the panic hook in libraries (though I couldn't find that in the Rust API guidelines).

if the user panics or any other library, it would hit the same issue again

Oh, really? I didn't know that, I thought a installed panic hook was called for any code panicking in that thread, like being totally global, not per library.

I meant versus trying to unhook all event listeners when panicking inside of Winit.

It is safe to say that any reasonable solution to this problem has to live in either Rustc or wasm-bindgen

Yep. There is something I don't still get about that core solution: if the WASM module get poisoned after a panic so that it cannot be accessed further in any way, what will happen when a browser callback calls into it like it's currently happening? Will it throw an exception? If that's the case, from the JS point of view, won't it be the same, just with a different type of exception?

It would trap, which in JS land is exposed as an exception. I think you mean to say that this isn't ideal, which I agree to. This will probably only be totally solved when we Rust Wasm moves to the component model :crossed_fingers:, which supports module poisoning.

I found this stack overflow answer to what I think is the same issue, but it sounds too easy to be true, just using the parking_lot crate, that Winit already stopped using, I guess for a good reason:

https://github.com/rust-windowing/winit/pull/2423

I didn't look to closely at this, but I think this was specifically talking about parking_lot types not having a poison state, therefore they remain usable after panicking. This is not the issue we are facing here, because we lack unwinding entirely, the Mutex (or in this case the RefCell) isn't being unlocked in the first place.

ook gotcha, all clear now, thx! 🙂🙏


[Request] Global Before Hooks

First off, great work with this plugin. I'll also have a look at the codebase too at some point and see if I can create a PR for what I'm suggesting...
Currently the common step definitions have removed tons of repetition from the tests we've created. And the Before hooks and tags are also working great. But there's repetition cropping up with the hooks that's a result of the Befores apparently not being available for global use.
Eg, we have many scenarios that require changing the intercepted data for a particular endpoint. So you'd have the below in the feature.ts:
Before({ tags: "@EndpointDataA" }, function () {   // some logic });
But it gets repeated multiple times for other feature files that use this EndpointDataA to switch the data.
A global Before that works like the global/common Steps would result in even less code.
That's my first suggestion, but I was also curious about the potential for tags before Steps. This one I'll admit is probably cucumber sacrilege, so I can understand if it's not doable. But occasionally you have to change the data for the same endpoint that was fired in beginning of the test (as it gets called again after some interaction but requires different data) - the workaround for this at the moment results in somewhat gratuitous steps that are really just cheats/workarounds to have something in place to allow us to change the data at some point.
This is also true for example of cy.wait('@endpointDataA') situations.
Hopefully that all makes sense. Again, really good work on this - even without the above, we've made huge efficiency gains with this plugin, so I'm just throwing this out there in the event that the above is doable without reinventing the wheel. If not, no worries.

But there's repetition cropping up with the hooks that's a result of the Befores apparently not being available for global use.

In don't understand what you're describing here and what this issue is about. Can you elaborate?

That's my first suggestion, but I was also curious about the potential for tags before Steps.

Furthermore, what do you mean by this?

In don't understand what you're describing here and what this issue is about. Can you elaborate?

Currently if you create test.feature file that has a tag @EndpointDataA over Scenario A, you have to create a test.ts to add the below hook:
Before({ tags: "@EndpointDataA" }, function () { // some logic });
So that Before fires only for test.feature.
But I currently have a situation where I have the exact same Before hook being used for multiple feature files.
A step only needs to be added once to step definitions or a common steps directory - and from then on, it's 'globally' available for use in all feature files. But I can't do the same with a Before - it only works if added to a ts file with the same name as the feature file.

Furthermore, what do you mean by this?

This one's probably not possible, but here's an example:
Scenario: The user wants to search car models
Given The user navigates to the car models page
When The user selects a brand from the brands filter
@WaitForModels
Then The car models are loaded

The idea being that I could target the @WaitForModels with a hook in the same way scenarios can be targeted, and I can write cy.wait('@getModelsMock') into the hook without the need of writing it into the step logic.
Why not add it to the step logic?
Because it's not always needed. The phrases we use have keywords, datatables, doc strings that allow one phrase to be used in multiple scenarios - we write no code as a result. We just change the variables in the phrase and the language is still natural to read.
The only thing that's not viable is changing the intercepted data of a mock or waiting for a mock to finish, as we haven't been able to think of variables for the phrase that don't look unnatural when read aloud.
I can provide more detailed examples if that still doesn't make sense.

Here you can see a passing example of a global Before hook. IE. what you're asking of seem to already work like intended.
As for tagged steps, that's a no. You need to find a different solution. Furthermore, the gherkin language isn't actually developer here, this preprocessor is first and foremost a consumer of it.

Interesting about the global Before hook - that example is definitely something I've tried. I'll give it another shot - it could have been conflicting with another similarly named hook. Good enough for me to know it's a feature anyway.
And yeah, I figured tagged steps might not be possible...


Update MD file on new branch 2017-21-14_19-11-36

:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

split/updateTestCon.md
:white_check_mark:Succeeded

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


fix:freeCodeCamp/freeCodeCamp#47257

Checklist:

[x] I have read freeCodeCamp's contribution guidelines.
[x] My pull request has a descriptive title (not a vague title like Update index.md)

closes freeCodeCamp/freeCodeCamp/issues/47257

Thanks for looking into the issue. Your proposed solution does not seem to resolve the issue. I was wondering if it is working on your side?

Yes, I followed the instructions on discourse to test the change. The anchor link headings were not hidden by the nav on my machine. Can you please advise if I miss anything or any additional testing I should do? Thank you.

@ahmadabdolsaheb I just retested the changes using discourse theme creator and theme CLI and looks like they work. Let me know if there is anything else I can do to make this work.
By the way, I also rewrote the code using $--global-nav-height. But for some reasons, syntax like #{$--global-nav-height} + 1em didn't work.

@ahmadabdolsaheb Same logic, but rewrote it using --global-nav-height. Also retested the changes using discourse CLI and theme creator, everything works on my end. Please advise if there is anything else I can do to make this work. Thank you.

This should work. Since the navigation's height doubles on small screens, I would appreciate it if you could make the necessary adjustment in a media query.

@ahmadabdolsaheb Added media query. Please let me know if it works on your side. Thank you.
Just a little thought on the media queries, may be helpful to create global variables for different breakpoints which will be easier to manage.

Thanks for making the adjustments. This pr should be good to go.

Just a little thought on the media queries, may be helpful to create global variables for different breakpoints which will be easier to manage.

That is a good idea. If you are interested in turning to the breakpoints into variables, feel free to create a pr and tag me.

@ahmadabdolsaheb I would like to get your thoughts before making commits to the breakpoints. Please let me know if you would like to create another issue for this topic.
Below are the current media queries breakpoints that I found in the common.scss:
max-width: 400px
min-width: 500px
min-width: 800px
max-width: 850px
min-width: 851px
min-width: 1020px
min-width: 1200px

One option is to create global sass variables which are listed as below:
$screen-xxs-max: 400px;
$screen-xs-min: 401px;
$screen-xs-max: 499px;
$screen-sm-min: 500px;
$screen-sm-max: 799px;
$screen-md-min: 800px;
$screen-md-max: 850px;
$screen-lg-min: 851px;
$screen-lg-max: 1019px;
$screen-xl-min: 1020px;
$screen-xl-max: 1199px;
$screen-xxl-min: 1200px;

The method above is pretty straightforward, but I found another cleaner option which is to write a mixin to manage breakpoints to get the rid of typing min-width and max-width, like this article shows: https://www.sitepoint.com/managing-responsive-breakpoints-sass/#with-a-configurable-mixin.
Please let me know your thoughts on which method we should adopt to manage the breakpoints so it can better fit into our future needs effectively as the platform grow.

@xinwei47, thanks for looking into this. Yes using mixins would be a good idea.


Updated bpython to fix shell_plus error

@ mention of reviewers
@Didayolo @bbearce
Benjamin I deleted the lock file because there was no way to generate the file. Docker build was failing with any change in the toml file.
A brief description of the purpose of the changes contained in this PR.

Deleted poetry.lock file because when we make changes to package versions in pyproject.toml we need to regenerate it
In pyproject.toml updated python version to 3.9  to fix the inconsistency with dockerfile and bpython version to fix shell_plus error
In Dockerfile removed copy poetry.lock command and added poetry lock command to generate lock file

Issues this PR resolves

#1537
#1530

A checklist for hand testing

[ ] rebuild django and site worker and make sure everything is ok in the logs
[ ] run docker-compose exec django ./manage.py shell_plus without any error

Checklist

[x] Code review by me
[x] Hand tested by me
[x] I'm proud of my work
[ ] Code review by reviewer
[ ] Hand tested by reviewer
[x] CircleCi tests are passing
[ ] Ready to merge

We should document the following
How to update packages

Update package version in pyproject.toml
Rebuild django container

docker build --no-cache -f Dockerfile -t codabench-django:latest ./

Rebuild site_worker container

docker build --no-cache -f Dockerfile -t codabench-site_worker:latest ./

NOTE: every time you build these containers, a fresh poetry.lock file is generated in the container which is then used to install packages.

I get this error after running docker compose up -d:
 => [codabench-django 2/9] RUN apt-get update && apt-get install -y gcc build-essential && rm -rf /var/lib/apt/lists/*                                                                                11.2s
 => ERROR [codabench-flower  4/10] RUN curl -sSL https://install.python-poetry.org | python3 -                                                                                81.4s
 => [codabench-django 3/9] RUN curl -sSL https://install.python-poetry.org | python3 -                                                                                64.6s
 => [codabench-site_worker 4/9] RUN poetry config virtualenvs.create false                                                                                0.6s
 => [codabench-django 5/9] RUN poetry config virtualenvs.in-project false                                                                                0.6s
 => [codabench-django 6/9] COPY pyproject.toml ./                                                                                0.0s
 => CANCELED [codabench-django 7/9] RUN poetry lock                                                                                9.1s
------
 > [codabench-flower  4/10] RUN curl -sSL https://install.python-poetry.org | python3 -:
#0 81.21 Retrieving Poetry metadata
#0 81.21
#0 81.21 # Welcome to Poetry!
#0 81.21
#0 81.21 This will download and install the latest version of Poetry,
#0 81.21 a dependency and package manager for Python.
#0 81.21
#0 81.21 It will add the `poetry` command to Poetry's bin directory, located at:
#0 81.21
#0 81.21 /root/.local/bin
#0 81.21
#0 81.21 You can uninstall at any time by executing this script with the --uninstall option,
#0 81.21 and these changes will be reverted.
#0 81.21
#0 81.21 Installing Poetry (1.8.3)
#0 81.21 Installing Poetry (1.8.3): Creating environment
#0 81.21 Installing Poetry (1.8.3): Installing Poetry
#0 81.21 Installing Poetry (1.8.3): An error occurred. Removing partial environment.
#0 81.21 Poetry installation failed.
#0 81.21 See /poetry-installer-error-paxk7uql.log for error logs.
------
failed to solve: executor failed running [/bin/sh -c curl -sSL https://install.python-poetry.org | python3 -]: exit code: 1

I get the following error after running docker compose up -d:
 => CANCELED [codabench-compute_worker 2/9] RUN apt-get update && curl -fsSL https://get.docker.com | sh                                                                                41.1s
 => [codabench-flower  1/10] FROM docker.io/library/python:3.9-alpine@sha256:3beee521e2eec6a3a9ba0c2fdac1bf30969e7f275e379f5b0dd8b45b25f50955                                                          0.0s
 => => resolve docker.io/library/python:3.9-alpine@sha256:3beee521e2eec6a3a9ba0c2fdac1bf30969e7f275e379f5b0dd8b45b25f50955                                                                             0.0s
 => CACHED [codabench-flower  2/10] RUN apk add --no-cache ca-certificates && update-ca-certificates curl                                                                                0.0s
 => CACHED [codabench-flower  3/10] RUN apk add curl                                                                                0.0s
 => ERROR [codabench-flower  4/10] RUN curl -sSL https://install.python-poetry.org | python3 -                                                                                40.5s
------
 > [codabench-flower  4/10] RUN curl -sSL https://install.python-poetry.org | python3 -:
#0 40.37 Retrieving Poetry metadata
#0 40.37
#0 40.37 # Welcome to Poetry!
#0 40.37
#0 40.37 This will download and install the latest version of Poetry,
#0 40.37 a dependency and package manager for Python.
#0 40.37
#0 40.37 It will add the `poetry` command to Poetry's bin directory, located at:
#0 40.37
#0 40.37 /root/.local/bin
#0 40.37
#0 40.37 You can uninstall at any time by executing this script with the --uninstall option,
#0 40.37 and these changes will be reverted.
#0 40.37
#0 40.37 Installing Poetry (1.8.3)
#0 40.37 Installing Poetry (1.8.3): Creating environment
#0 40.37 Installing Poetry (1.8.3): Installing Poetry
#0 40.37 Installing Poetry (1.8.3): An error occurred. Removing partial environment.
#0 40.37 Poetry installation failed.
#0 40.37 See /poetry-installer-error-8ei1b6ej.log for error logs.
------
failed to solve: executor failed running [/bin/sh -c curl -sSL https://install.python-poetry.org | python3 -]: exit code: 1

looks like this is a problem from flower. You need this dockerfile
https://github.com/codalab/codabench/pull/1520

looks like this is a problem from flower. You need this dockerfile: #1520

Oh yeah I did not realize the order of the PR. Thanks.

Working fine!


APPS-120 - Added an option to check for single approver

@duboisp @jonasg-gc @yeungca2 Please review the PR

@duboisp : did you also want to review?

For the record: This is a MINOR change.
\cc @jonasg-gc


Sending alerts to OpsGenie fail with unexpected status code 422

What did you do?
Configured OpsGenie receiver like this:
- name: OpsGenieOperations
  opsgenie_configs:
  - api_key: $OPSGENIE_API_KEY
    teams: Infrastructure

What did you expect to see?
Receive notifications in opsgenie
What did you see instead? Under which circumstances?
An error occurred:
level=error ts=2018-06-29T06:06:50.920889089Z caller=dispatch.go:279 component=dispatcher msg="Notify for alerts failed" num_alerts=1 err="cancelling notify retry for \"opsgenie\" due to unrecoverable error: unexpected status code 422"

Environment

System information:
insert output of uname -srm here

Alertmanager version:

alertmanager, version 0.15.0 (branch: HEAD, revision: 462c969d85cf1a473587754d55e4a3c4a2abc63c)
  build user:       root@bec9939eb862
  build date:       20180622-11:58:41
  go version:       go1.10.3

Prometheus version:

prometheus, version 2.3.1 (branch: HEAD, revision: 188ca45bd85ce843071e768d855722a9d9dabe03)
  build user:       root@82ef94f1b8f7
  build date:       20180619-15:56:22
  go version:       go1.10.3

Alertmanager configuration file:

insert configuration here

Prometheus configuration file:

insert configuration here (if relevant to the issue)

Logs:

insert Prometheus and Alertmanager logs relevant to the issue here

Can you start AlertManager with the --log.level=debug argument and share the full logs? Also I presume that you've replaced $OPSGENIE_API_KEY by your real API key value.

@simonpasquier I also presumed, but in the end it looks like docker configs do not support templating in such an easy way. I specified the key directly, and it works fine, so I am closing. Sorry for the hassle !

@ajardan no problem and thanks for closing the issue!

PS: Should the error reporting be improved, since it would be super easy to figure out what went wrong with a proper error?

@ajardan do I understand correctly that you had a misconfigured api key? In that case, did the error handling not give you any feedback?
In any case, contributions for better error feedback are always very welcome.

But since I am not a very good developer, I am not sure I can contribute much, at least not yet :/

I am more than happy to help. Let us know and thanks for the feedback.

Recently I bumped into a situation when templating error led to silently failing alert sending.
However, it was shown on debug log level. What about changing the log level of templating errors to make them somehow more visible? I'd say, it's a non-critical error or at least a warning.

@Zebradil which version are you using? Any templating error should be logged at the error level.

@simonpasquier Thanks for the quick reply.
I'm using version 0.17.0. I've checked this with the latest docker image (which contains version 0.19.0) — all good, there are error messages in case of templating errors.
So, I just need to update my alertmanager.


[DUOS-1752][risk=no] Step 1 for new data access request application page

Added new route to the request page (all changes take place there instead) - you can see it here: https://local.broadinstitute.org:3000/dar_application_new/746c463d-75d9-4288-ba1d-6e69b0c08e59
Mostly updates form components into our new ones, and then restyles some things.

Have you read Terra's Contributing Guide lately? If not, do that first.

Label PR with a Jira ticket number and include a link to the ticket
Label PR with a security risk modifier [no, low, medium, high]
PR describes scope of changes
Get a minimum of one thumbs worth of review, preferably two if enough team members are available
Get PO sign-off for all non-trivial UI or workflow changes
Verify all tests go green
Test this change deployed correctly and works on dev environment after deployment

Opening up a draft to get some opinions!
I did this UI component first here, but then ... I think I didnt read the description of the ticket thoroughly enough, and I am now at this issue where

All logic for these form elements should follow the same logic we have in the current DAR form. Styling should be updated to reflect that of the mocks.

The logic for the original form is so complex, I'm scared that trying to redo it means I'm going to lose something. I think the proper solution is to trash this effort, and just modify the css / html portions of the original researcher component... However, my concerns with that are that the ticket specifically says to create a new component instead of modify an existing one.
Not sure what to do next? While this draft is up, I'm going to be migrating these component elements back into the original researcher component. Please please let me know if i shouldn't be doing that tho!
Have you read Terra's Contributing Guide lately? If not, do that first.

Label PR with a Jira ticket number and include a link to the ticket
Label PR with a security risk modifier [no, low, medium, high]
PR describes scope of changes
Get a minimum of one thumbs worth of review, preferably two if enough team members are available
Get PO sign-off for all non-trivial UI or workflow changes
Verify all tests go green
Test this change deployed correctly and works on dev environment after deployment

If you think you can keep the existing logic and simply adjust the styling then that's fine. One thing to note though is that the page is now switching to a scrolling model where

The side bar updates the selection as you scroll through the form
Clicking on a step on the side bar will cause the form to scroll to that step.

Also keep in mind that the DAR form is in active use on production as it is the primary action for any researcher in the system. Directly changing the existing DAR Form code could compromise its current functionality if redesigns break already working functionality.
By creating a separate page, route, and sub-components we can avoid breaking a key feature by working on it on dev/local dedicated route. To make that task easier you can make copies of existing components or build new ones from scratch when tackling the UI tickets.
Once the entire UI update is done, it's just a matter of updating the routes to use the new page and removing the old components once we've determined that the new feature works as expected.

closing this pr because it looks like too many changes are necessary

ALRIGHT LET'S DO THIS AGAIN

Currently you cannot enter spaces on any of the fields for the Cloud Provider inputs (name, type, textbox).


creating a baseline after prototyping with db push doesn't work

Bug description
After working for a day with db push, I wanted to create my first migration, this is impossible (happened in multiple different projects and is consistent).
I keep getting a Drift detected when trying to do px prisma migrate dev --name initial-migration --create-only but npx prisma db push returns all is synced. even did and introspect. I don’t have any migrations, I worked only with db push until now.
It just requires me to do a reset, which.. well, no?.. Haha
How to reproduce

work with db push, prototype
Try and create a new initial migration
It will fail....

Expected behavior
The baseline should be created
Prisma information
With any schema it happened... Even after doing an introspect.
Environment & setup

OS:Mac
Database:Postgres
Node.js version: happened with 13-16

Prisma Version
2.26

happened with previous version in the past month as well

Hello
Can you please share an example schema which you are unable to baseline along with the error migrate which migrate throws?
Right now provided information is not enough for reproduction.

It literally doesn't matter. Even the default schema with User, just add any other model and try. It will fail.
It basically never works.

Indeed I can reproduce that. Classified this as confirmed bug.

Note from Harshit

Looks like we are always detecting a drift after a db push execution
Before this screenshot I added Test table to the schema and ran db push.

Internal Slack thread

The problem there is related to how migrate and db push are designed to work.
In this very case, the experience is clearly suboptimal and we should figure out how to improve it (better error messaging, new feature...).
Requalifying as a feature now.

@thebiglabasky Well the main documentation states clearly, start with db push, get to some good structure and then do a baseline.
It makes no sense to start with migrations from the get go, as this means there will be dozens of add column, drop column, change type, add index different migrations in the beginning.
So I find it extremely critical, as this happens just on your baby steps.

Indeed. Hence my point about it being clearly suboptimal: we'll look into prioritizing that along with the other initiatives we're looking at.


Uncaught TypeError: Cannot read property 'electron' of undefined

I got this error message in the console when running this in my node js v10.0.0 vue js app,

index.js?d2af:10 Uncaught TypeError: Cannot read property 'electron' of undefined
at Object.eval (index.js?d2af:10)
at eval (index.js:290)
at Object../node_modules/iohook/index.js (app.js:1457)
at webpack_require (app.js:722)
at fn (app.js:99)
at eval (App.vue?234e:8)
at Module../node_modules/cache-loader/dist/cjs.js??ref--12-0!./node_modules/babel-loader/lib/index.js!./node_modules/vue-loader/lib/index.js??vue-loader-options!./src/App.vue?vue&type=script&lang=js (app.js:848)
at webpack_require (app.js:722)
at fn (app.js:99)
at eval (App.vue?8c0f:1)

It's being caused by this one line of code:
const runtime = process.versions['electron'] ? 'electron' : 'node';

Hi there,
Could you please use our issue template? We'll be happy to help :-).
Cheers


Fix get volume on WebOS 5.0

Fixes #26

@Acrobot thanks! I've updated the get_volume function as well.
@bendavid can you take a look at this? This is breaking the Home Assistant integration, so it would be great if we could merge it ASAP


Change lint tool from standard to eslint

Coverage remained the same at 26.354% when pulling ee310ebd0e75c1e8e0b27c309e16f06e7feaba6d on eslint into 5862449fecd6a02b55b2b6b335297c60f413c308 on master.


RuboCop 0.80 surfaces which unconfigured new cops we have

I noticed this on an app's Dependabot gem bump PR CI failure for rubocop-govuk.
The following cops were added to RuboCop, but are not configured. Please set Enabled to either `true` or `false` in your `.rubocop.yml` file:
 - Style/HashEachMethods (0.80)
 - Style/HashTransformKeys (0.80)
 - Style/HashTransformValues (0.80)

This new informational messaging is a feature which wasn't immediately obvious when dealing with #13 (I was looking for added and removed cops, but not much else).
We should make decisions about whether to include them and bump the gem version again.

👍  from me on including them.
I'm not volunteering to do the work though, and I think @issyl0's probably done enough rubocop for the week 😅


Make it noarch

@conda-forge-admin, please add noarch: python

Hi! This is the friendly automated conda-forge-webservice.
I just wanted to let you know that I made the recipe noarch: python in conda-forge/msg-extractor-feedstock#7.

done in pr #10


New signals

cc @gkoz
cc @EPashkin

+1

Updated.

All EntryCompletion signals seems generated in #315, can you compare it and may be remove?

Or I need add ignore for it

I think it's best for me to remove them. I'll just compare with the generated code before hand.

@EPashkin: I checked, everything seems good so I remove it from this PR. Well done! :D

Forgot trait EntryCompletionSignals

Oh indeed. Fixed.

+1

I forgot disable Editable in Gir.toml :(
@GuillaumeGomez can you do it in this PR?

@EPashkin: Sure.

By way, we need redefine all 3 signals for Editable or can have mix: 2 auto + 1 manual?
IMHO only problems can arise with docs if any.

@EPashkin: Ok for you?

@EPashkin: Hum... I guess it's better to avoid to spread signals implementation everywhere.

Then add Regen and +1 from me.

And remove "Gtk.Editable", in `generate=['

Gir don't allow double-spending :wink:

Sorry for the troubles. ^^'
Updated.

Still no Regen commit.

And done!

Thanks.

cc @gkoz

Do you think you could include a gir update here to fix the gesture build error?

I'll do it tomorrow.

@gkoz: Done.

Thanks

@GuillaumeGomez squash Regens pls

Done.

Sorry, I missed that no "Gir update" commit. Can you add it before Regen?

What "no gir update"?

"Update gir" commit that changes sub-module "gir" version: must be b798f4f to equals to Regen.

I update gir module but didn't switch the two commits. Do you REALLY want this as well?

I prefer update auto in these steps: update gir (if needed), update gir.toml, do some not auto work, do single "Regen",
but if you don't want it, I do not insist

This PR has already been updated a lot of times and it'd force me to rework the two last commits. So if possible, I'd prefer to avoid doing it.

Just to reminder: it part of https://github.com/gtk-rs/gir/issues/234

@GuillaumeGomez Found another forgotten bug:
transmute(gl_area_trampoline_res) without as usize
Don't understand why I don't see it before.

GlArea will be removed after https://github.com/gtk-rs/gir/issues/239, so can be ignored for now.

So... I remove it or not?

IMHO better remove to remove annoying warning.

Hum... What warning? I don't see any from both travis and appveyor.

D:/eap/rust/0/gtk\src\signal.rs:1153:21: 1153:30 warning: `unsafe extern "C" fn(*mut ffi::GtkGLArea, i32, i32, &Box<for<'r> std::ops::Fn(&'r auto::gl_area::GLArea, i32, i32) + 'static>) {signal::gl_area::gl_area_trampoline_res}` is now zero-sized and has to be cast to a pointer before transmuting to `std::option::Option<unsafe extern "C" fn()>`, #[warn(transmute_from_fn_item_types)] on by default
D:/eap/rust/0/gtk\src\signal.rs:1153                     transmute(gl_area_trampoline_res), Box::into_raw(f) as *mut _)
                                                         ^~~~~~~~~
D:/eap/rust/0/gtk\src\signal.rs:1153:21: 1153:30 warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release!
D:/eap/rust/0/gtk\src\signal.rs:1153:21: 1153:30 note: for more information, see issue #19925 <https://github.com/rust-lang/rust/issues/19925>
   Compiling gtk-rs-examples v0.0.1 (file:///D:/eap/rust/0/examples)

It was appear when building examples with gtk_3_16,
It was main reason to mass adding 'as usize` but I missed this function,
I don't understand why I don't see it yesterday.

It's strange we didn't see earlier (well, I'm on gtk 3.10, so normal for me :p).

And done.

Thanks again.

Perfect, thanks!

@GuillaumeGomez You planing adding manual SpinButtonSignals?

I plan to add all missing signals. So if it's in the list, then yes. Don't know when I'll however.

Its part of https://github.com/gtk-rs/gir/issues/234, so we don't plan generate it, so it must be in list ;)


Add Lim's scripts link to popup

I want to add a link to Lims and other scripts, but the problem is I don't want to popularize the bot scripts.

Perhaps add a link to my Reddit thread? I'll be keeping it updated for the foreseeable future, and I only include scripts that I've verified.
https://www.reddit.com/r/mousehunt/comments/avazpr/resource_useful_userscripts/
There's likely no way to stop people from finding and using bot scripts if that's what they've committed to doing, so my strategy is to not even mention them.

Given the latest reasoning in the Opera rejection, settling for a link may be the only option

we can add his scripts in the extension (if lim still approves of me doing that), we just can't load them from remote location.

Added in #39


Ghost devices, even after clean up

During the first config, I named my 2 Tuya outlets "Tuya Outlet 1" and "Tuya Outlet 2".
The world was then full of joy and unicorns... but I changed my mind and I renamed these 2 devices (no more Tuya in the name, I know, I could be more creative).
Though, after a restart, the new devices appeared in the Apple Home app, but the old are still here.
After deleting the persist folder of homebridge (29 devices to reconfigure and all the rules attached...) I was hoping to to see the Tuya Outlet 1 and 2... but they are still here.
Now I have 2 icons in the apple home app for each outlet.
I also have wall dimmer and no problem with these devices...
I use homebridge from 3 years now
Below, and extract from the logs and from my config.json
Note: i changed all the keys and ids by text. Example: IdOutlet1 and KeyOutlet1 instead of the real Id and key.
Logs :
[2019-1-3 14:32:13] [TuyaPlatform] Initializing TuyaPlatform platform... **[2019-1-3 14:32:13] [TuyaPlatform] Configuring cached accessory: [Tuya Outlet 2] undefined 9adb130e-8233-4df3-a815-a7b8ea31f83d [2019-1-3 14:32:13] [TuyaPlatform] Configuring cached accessory: [Tuya Outlet 1] undefined e45a9aab-cea0-4e8a-bddb-fbfadcda4073 [2019-1-3 14:32:13] [TuyaPlatform] Configuring cached accessory: [Outlet 1] undefined 5099aa50-bc53-45d5-8907-bcbd3cd16d4b [2019-1-3 14:32:13] [TuyaPlatform] Configuring cached accessory: [Outlet 2] undefined 6822edc4-2494-4a43-9b38-09de30005b3d** [2019-1-3 14:32:13] [TuyaPlatform] Configuring cached accessory: [Interrupteur Cuisine] IdDimmer2 01962db5-06ea-4eba-b7d0-31df54c205e2 [2019-1-3 14:32:13] [TuyaPlatform] Configuring cached accessory: [Interrupteur Sous-Sol] IdDimmer1 9f46192a-ecbc-4512-8cfd-be92602f74c0 [2019-1-3 14:32:16] [TuyaPlatform] Device IdOutlet1 has IP <IP_ADDRESS> [2019-1-3 14:32:16] [TuyaPlatform] New Device Online: Outlet 1 (IdOutlet1) [2019-1-3 14:32:16] [TuyaPlatform] Adding: Outlet 1 (generic / IdOutlet1) [2019-1-3 14:32:18] [TuyaPlatform] Device IdOutlet2 has IP <IP_ADDRESS> [2019-1-3 14:32:18] [TuyaPlatform] New Device Online: Outlet 2 (IdOutlet2) [2019-1-3 14:32:18] [TuyaPlatform] Adding: Outlet 2 (generic / IdOutlet2) [2019-1-3 14:32:19] [TuyaPlatform] Device IdDimmer2 has IP <IP_ADDRESS> [2019-1-3 14:32:19] [TuyaPlatform] New Device Online: Interrupteur Cuisine (IdDimmer2) [2019-1-3 14:32:19] [TuyaPlatform] Adding: Interrupteur Cuisine (dimmer / IdDimmer2) [2019-1-3 14:32:19] [TuyaPlatform] Existing Accessory found [Interrupteur Cuisine] [IdDimmer2] [01962db5-06ea-4eba-b7d0-31df54c205e2] [2019-1-3 14:32:20] [TuyaPlatform] Device IdDimmer1 has IP <IP_ADDRESS> [2019-1-3 14:32:20] [TuyaPlatform] New Device Online: Interrupteur Sous-Sol (IdDimmer1) [2019-1-3 14:32:20] [TuyaPlatform] Adding: Interrupteur Sous-Sol (dimmer / IdDimmer1) [2019-1-3 14:32:20] [TuyaPlatform] Existing Accessory found [Interrupteur Sous-Sol] [IdDimmer1] [9f46192a-ecbc-4512-8cfd-be92602f74c0]
Config.json
{                         "platform": "TuyaPlatform",                         "name": "TuyaPlatform",                         "devices": [ 				{                                         "name": "Outlet 1",                                         "id": "IdOutlet1",                                         "key": "KeyOutlet1"                                 },                                 {                                         "name": "Outlet 2",                                         "id": "IdOutlet2",                                         "key": "KeyOutlet2"                                 }, 				{ 					"name": "Interrupteur Cuisine", 					"id": "IdDimmer2", 					"key": "KeyDimmer2", 					"type": "dimmer",                                        	"options":                                                  {                                                 "dpsOn": 1,                                                 "dpsBright": 3,                                                 "minVal": 0,                                                 "maxVal": 254                                                 } 				}, 				{ 					"name": "Interrupteur Sous-Sol", 					"id": "IdDimmer1", 					"key": "KeyDimmer1", 					"type": "dimmer", 					"options": 						{       						"dpsOn": 1,       						"dpsBright": 3,       						"minVal": 0,       						"maxVal": 254 						} 				}                         ]                 },
Any idea ?
Not Max.

Did you delete just the persist/ folder, or the accessories/ folder as well?

Just the persist folder. Do you mean I have to delete both folders ?

Yes.
In the past when I've had similar issues deleting both folders resolved them.


WHO source doesn't seem to be collecting monkeypox data anymore, and a map of the new outbreak is hard to come by.

The source linked to in https://ourworldindata.org/mpox is https://extranet.who.int/publicemergency/
However, if you click on the "layers" button, the following appears:
In particular, see:

We are no longer showing monkeypox data in the emergency dashboard. For data related to monkeypox please use the global trends report

Perhaps as a result, some of the charts on https://ourworldindata.org/mpox cut off.
However, the linked global health report seems to be updated monthly.
I would love to see up to date monkeypox graphs, some collaboration with the WHO to make daily data accessible, as this gives a better sense of where we are on the exponential. I don't think I need to make the case that better presented information leads to better decisions to OWID though :)

Hi @NunoSempere
Thanks for getting in touch and highlighting this to us. The source noted in our explorer was out of date, we now use this WHO data source for confirmed cases and deaths. This is also updated monthly and has the same values as the global health report that you shared.
I have now updated the explorer to better reflect the data source we use and will update this repo in the coming days to describe our current data pipeline.
Thanks again,
Fiona

Hey Fiona,
What do you think about trying to find or creating a source that updates faster than monthly? For a disease that is rapidly developing, it seems like this is a pretty slow speed.
Best,
Nuño

Hi Nuño,
Yes that is something that is important for us. We have recently started including data from Africa CDC on suspected cases, which you'll see in the default view of the explorer. This dataset is updated weekly, but the quality is somewhat variable, so we are only using this for suspected cases as this isn't currently provided by our main data source, the WHO.
We are also speaking with Global.health, who are working to pull together a detailed dataset that will be updated more frequently; I expect this will be made public in the next week.
It is also likely that the WHO will increase the cadence of their updates in response to the current situation. We still believe that the WHO is the best source confirmed cases and deaths so we will continue to use this but monitor the situation closely.


aws-smithy-client 0.54.2 breaks athena client

Description of the bug
After running cargo update on one of my project, I had errors coming from aws-smithy-client at runtime.
It has been updated to 0.54.2, and by forcing it back to =0.54.1 everything went well.
How to reproduce
Cargo.toml
[dependencies]
tokio = { version = "*", features = ["full"]}
aws-smithy-client = { version = "=0.54.2" }
aws-sdk-athena = { version = "=0.24.0" }
aws-config = { version =  "0.54.1", default-features = false }

main.rs
use aws_config::retry::RetryConfig;

#[tokio::main]
async fn main() {
    let shared_config = aws_config::load_from_env().await;
    let config = aws_sdk_athena::config::Builder::from(&shared_config)
        .retry_config(RetryConfig::standard())
        .build();
    let client = aws_sdk_athena::Client::from_conf(config);
    let query_execution_id = match client
        .start_query_execution()
        .work_group("primary")
        .query_string("select count(*) from mytable")
        .send()
        .await
    {
        Ok(res) => String::from(res.query_execution_id().unwrap()),
        Err(e) => panic!("{e}"),
    };
    println!("Query running {query_execution_id}");
}

This codes panics with :
thread 'main' panicked at 'failed to construct request', src/main.rs:18:19

But with:
aws-smithy-client = { version = "=0.54.1" }

It works:
Query running ce628d28-b971-4823-87f8-1016ec1d5ed2

Note: I'm not sure if it's relevant but in my local environment, I use AWS_PROFILE environment variable.

I was able to reproduce, but only after setting default-features = true on aws-config. You can add more context to that panic by doing the following:
use aws_sdk_athena::types::DisplayErrorContext;

// --snip --

        Err(e) => panic!("{}", DisplayErrorContext(e)),

That reveals the full error to be:
thread 'main' panicked at 'failed to construct request: could not construct endpoint parameters: a required field was missing: `region` (ConstructionFailure(ConstructionFailure { source: ResolveEndpointError { message: "could not construct endpoint parameters", source: Some(InvalidParams { field: "region" }) } }))', src/main.rs:19:19

Setting the AWS_REGION env var after that led to a different error that indicates an output location is required on the Athena request.


FYI, clean and autoremove

https://github.com/waleedka/modern-deep-learning-docker/blob/36ae632f5b90af34458e196aea52406799139b93/Dockerfile#L133-L134
While it would be great if this reduced the image size, it has zero effect as it is on a different layer. The only way this would be of use is if it is combined with a RUN command where you are actually installing or updating the repository.
In reality you would need to combine all apt-get update and install commands in a single RUN layer where you then clean up at the end of that single command. Considering this is for research and testing it isn't a big deal. Just figured I would point it out.

@sberryman Thank you for pointing this out. You're right, using apt-get clean in a separate layer is useless. I looked into this further, and it turns out the standard Ubuntu image automatically calls clean and autoremove after every install, as mentioned in the official documentation. So I removed my explicit call.
Your second suggestion is correct as well. But instead of calling clean (which is being called automatically anyway), the best practice is to delete apt-get cache using rm -rf /var/lib/apt/lists/*. Adding this line in every RUN is ugly. And according to docker history, the apt-get cache adds 40MB, which is about 1% of the total image size, so it's not worth reducing the readability and flexibility of the code.
I did merge related RUN blocks together, keeping a balance between optimization and readability. I'll keep this issue open for any future suggestions or to correct me if any of my conclusions are wrong. Thanks again for the tips.

Looking a lot better, here are few more things I noticed:

You indicate you are installing tensorflow 1.6.0 on line 46 but are not specifying a version. As of right now you would be installing v1.6, but that is up to google's release schedule. You may be in for a bit of a surprise if you try and build the day they push 1.7 for example. Something more specific like https://storage.googleapis.com/tensorflow/linux/cpu/tensorflow-1.6.0-cp27-none-linux_x86_64.whl would probably be a better idea. This will help ensure a consistent build
Lines 60 and 61 for OpenCV install are pulling from a git branch and on two layers, why not pull down the release tarball? See an example 1 below.
Same thing on line 81 for caffe, pulling master is always risky unless you are looking for a bleeding edge image that will break.
Line 111 you are pulling pytorch via http not https and not validating a hash, while I get this is for research, running this in production (which some people may be doing) leaves you open for an easy man-in-the-middle attack. Example of checking shasum is shown below. The other benefit I've found of using environment variables for build is that it makes it easy to see dependency versions in the built image. A simple docker inspect will show the variables. I've seen a mix of env and checksum in the layer being built or all placed near the top of the Docker file.

 Right now you are updating the registry in basically the first layer. So once you build the image locally each layer is cached. If you make a change at line 13, any successive layers will be rebuilt, however, they will not be using an updated manifest as that is from the cached layer. I haven't come across this being a problem in any production deployments I have but something to be cognizant of.


Large file sizes and missing fields when listing bucket contents

Hey!
I was trying to list the contents of a few buckets, but encountered a couple of problems:

File sizes larger than i32::MAX cause Serde XML to complain about receiving a string instead of i32 (in my case, I had a 6GB file that caused this), so I changed the type of Owner.size to u64.
For some buckets, the fields Owner, NextMarker, Delimiter, Marker, EncodingType, and CommonPrefixes were missing in the API response (again, causing Serde XML to fail), so I made them optional.

These are of course breaking changes since they change public types, but for me they work ;-)

+1 for optional fields :)

@BMeu, sorry completely missed this PR, will merge.


Prevent Delete Nodes and Edges

Describe the Bug
I am using version 10.3.17 react-flow-renderer
i am trying to prevent delete with the Backspace btn. I need this function but i also need to make extra validation before delete. The only way i see now is to use onNodesChange handler and onEdgesChange handler to watch all elements that are need to be removed - but it's reallly not comfortable and not right. Is there way i can do smth to make extra validation before delete?
Your Example Website or App
No response
Steps to Reproduce the Bug or Issue

Try to delete node and to do smth before delete.

Expected behavior

i have special handler - onBeforeDeleteElements
delete happens only if i update nodes and edges intentionally by myself

Screenshots or Videos
No response
Platform

OS: Linux
Browser: Chrome

Additional context
No response

I like the idea of adding an onBeforeDelete handler. We will probably add it with the next major release.

@moklick Hello! but is it possible to do onBeforeDeletle check somehow in 10.3.17 now? The problem i see is to prevent deletion(blinking of node) before any confirmation that i want to delete it.

I have found answer to my question.

Hello @moklick, any chances this feature will appear in future releases?
I've implemented a custom delete with a button and I have a workflow after deleting a node, but users can still delete nodes by pressing Backspace and this is not desirable behavior, because it skips the post-delete workflow.
So either a beforeDelete handler to prevent deletion or a boolean flag like deleteByBackspace (default to true) would be very helpful.

Can you please explain how to prevent delete of specific node types, need to validate before deleting, and also stop blinking of node.

Hello ! Any update ?

In v11, using the onNodesChange prop, you can validate if a node should be delete yourself.
// only allow nodes that are *not* of type `custom` to be removed
function shouldNodeBeRemoved(node: Node) {
  if (node.type !== 'custom') {
    return true;
  }

  return false;
}

const BasicFlow = () => {
  const { getNode } = useReactFlow();
  const [nodes, , onNodesChange] = useNodesState(initialNodes);
  const [edges, setEdges, onEdgesChange] = useEdgesState(initialEdges);
  const onConnect = useCallback(
    (params: Edge | Connection) => setEdges((els) => addEdge(params, els)),
    [setEdges]
  );

  // wrap the `onNodesChange` function, so we can add our validation in there before a node gets removed
  function handleNodesChange(changes: NodeChange[]) {
    const nextChanges = changes.reduce((acc, change) => {
	  // if this change is supposed to remove a node we want to validate it first
      if (change.type === 'remove') {
        const node = getNode(change.id)

        // if the node can be removed, keep the change, otherwise we skip the change and keep the node
        if (shouldNodeBeRemoved(node)) {
          return [...acc, change];
        }

        // change is skipped, node is kept
        return acc;
      }

      // all other change types are just put into the next changes arr
      return [...acc, change];
    }, [] as NodeChange[])

	// apply the changes we kept
    onNodesChange(nextChanges);
  }

  return (
    <ReactFlow
      nodes={nodes}
      edges={edges}
      onNodesChange={handleNodesChange}
      onEdgesChange={onEdgesChange}
      onConnect={onConnect}
      nodeTypes={nodeTypes}
      fitView
    >
      <Background />
    </ReactFlow>
  );
};

Here's an example sandbox.

@moklick Will you still add the "onBeforeDelete" feature? I found an issue with the presented workarround, i can prevent to delete the node but it will delete the edges connected to that node anyways.

The problem with @bcakmakoglu 's solution using onNodesChange is that that callback is called only after the nodes&edges are deleted, so it has a high potential of being buggy (like @dm-candeias elaborated above)
In the absence of a onBeforeDelete callback, the way I ended up doing it is disabling React Flow's deleteKeyCode, adding custom key handler and then handling the logic there. See the solution by @AdamGerthel and my elaboration
cc @dm-candeias  in case you still need a solution

@baibhavbista
Not quite true. onNodesChange is not triggered after the nodes are actually deleted, it is triggered when a "changeset" proposing the removal of the nodes is sent to you at which point you apply those changes to your nodes and then they are deleted.
You basically interrupt the application of these changes for whatever validation etc. you want to do.
Using a custom key handler is completely fine though 😄

Oh @bcakmakoglu sorry, my bad then
I had some weird issues when using that approach, maybe those were due to some other issue then?
Thanks for letting me know. I might try using that approach again!

The onNodesChange answer works for me, but is this a hack, or is it intended to work this way? The onNodesChange documentation isn't clear, and also doesn't mention the ability to intercept / manually apply the changelist.

Use this event handler to add interactivity to a controlled flow. It is called on node drag, select, and move.

The useNodesState docs also don't clearly document this behavior:

A handy callback that can take an array of NodeChanges and update the nodes state accordingly. You'll typically pass this directly to the onNodesChange prop of your  component

I am using the onNodesChange approach and it works for nodes. But the node's edges are still deleted.
I need to prevent specific edges' deletion in a specific case, but allow the same edges to be deleted directly or when other connected nodes are deleted (that are deletable). I don't see how it's possible with onEdgesChange since there is no info on the nodes' deletion context.
Let's say I have nodes A & B.

A should be not deletable.
B should be deletable.
When A is attempted to delete, A -> B edge should stay.
When A -> B edge is deleted directly, it should be deleted.
When B is attempted to delete, it should be deleted and A -> B to be deleted as well.

In other words when a user tries to delete node A, it should stay with all its edges in place. Otherwise, deletion must work as default.
How can I achieve that?
The only idea I have currently is to check if node A is selected currently and prevent its edges deletion in that case.

@kapxapot in my case i filtered the changes to only allow changes of type =  position, this will prevent the node to be selectable and removable (Im using Zustand)
  onNodesChange: (key) => (changes: NodeChange[]) => {
    const positionChanges = changes.filter((change) => change.type === "position");

    set((state) => ({
      nodes: applyNodeChanges(positionChanges, get().nodes),
    }));
  }

@GaMJun Thanks!
I managed to do it using the delete handler override and by tracking selected nodes & edges:
https://github.com/kapxapot/brightwood-builder/blob/master/src/components/flow.tsx#L203-L238

All selected edges are deleted.
If a node can be deleted, it's deleted with all its edges.
If a node can't be deleted, it and its edges don't change.

For anyone still trying to solve this issue, I managed to fix it by adding the  nodesFocusable={false} property to my ReactFlow component. Note that this will also prevent you from using other keyboard shortcuts like the arrow keys for moving the nodes for example.


I can not Sign in after Sign Up

When I sign Up and verify my email address, I try to immediately log in and I am told that I am entering incorrect parameters. This seems to be a glitch in the sign up because I have been trying to do this for days now.
Please help as I would like to start using your service asap. Thanks

@wcaban1206 you have to sigin with your username, not your email


fix(esl-toggleable): improve outside keyboard events handling

:tada: This PR is included in version 3.11.0-beta.3 :tada:
The release is available on:

npm package (@beta dist-tag)
GitHub release

Your semantic-release bot :package::rocket:

:tada: This PR is included in version 3.11.0 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


[#87] Update value for opacity800

Note: Please transform - [ ] into - (NA) in the description when things are not applicable
Related issues
#87
Description

@julien-deramond submtited a PR to update opacity800 (#86)
I checked his branch
I merge into another branch so as to update the CHANGELOG and add a missing unit tests

Motivation & Context
See #87
Types of change

Refactoring (non-breaking change)

Previews

Checklist

Contribution

[x] I have read the contributing guidelines

Accessibility

(N/A) My change follows accessibility good practices

Design

(N/A)  My change respects the design guidelines of Orange Unified Design System

Development

[x] My change follows the developer guide
[x]  I have added unit tests to cover my changes (optional)

Documentation

[x] My change introduces changes to the documentation and/or I have updated the documentation accordingly

Checklist (for Core Team only)

[x] The evolution have been tested and the project builds for iPhones and iPads
[ ] Code review has been done by reviewers according to CODEOWNERS file
(N/A) Design review has been done
(N/A) Accessibiltiy review has been done
(N/A) Q/A team has tested the evolution
[x] Documentation has been updated if relevant
[x] Internal files have been updated if relevant (like CONTRIBUTING, DEVELOP, THIRD_PARTY, CONTRIBUTORS, NOTICE)
[x] CHANGELOG has been updated respecting keep a changelog rules and reference the issues

@ludovic35 It's ready for review :)


Dynamic Library compilation

Everything works great, compilation is smooth and works out-of-the-box.
But now I have a Number Object that takes as much time to compile as Mosaic does, plus it's the same size. (+50Mb !!) Apparently, all symbols are duplicated into the plugin binary.
Did I miss something ?
What are your findings and explorations around this ? I guess there's a reason for this [temporary?] choice ?
I just checked the recently new ofxHotReloader and the plugin is a little over 10Mb, which is about the size of OF, so it probably has the same approach.
Theoretically, there should be a way to simply compile the plugin code in a few bytes, then link that against the symbols included in the Mosaic binary ?
Maybe Mosaic should link with a stand-alone OpenFrameworks.a (.bundle?), then the plugins do the same ?

Yes, everything you're saying is a temporary situation, i had priority in make it work smoothly and easy, now the next step will be optimize, in order to reduce plugin size and compile speed.
Basically, we'll need to reorganize the code in order to have the minimum includes as possible to compile an object ( a plugin in this case ), then everything will be lighter and faster to compile.
Right now, every objects depends on PatchObject class
that needs:
ofxImGui
ofxFontStash
ofxPDSP
ofxXmlSettings
and most of the core/ files in ofxVisualProgramming
then, starting by creating a specific version of ofxVisualProgramming ( maybe call it ofxMosaicPlugin? ) just for plugin compiling, we'll reduce a lot the plugin size and the compile time.
ofxHotReloader is based on the older ofxPlugin, both tested a while ago, but  the smoother and bugless option was the one i used with PUGG, so i stayed on that, but yes, the principle is similar, the plugin carry a lot of unnecessary symbols at runtime, but necessary for compile the dynamic lib.
More optimizations will be possible too, as you suggest, so let's start digging the issue!

Ok, good to hear.
So there seem to be 2 aspects on this issue :

Reduce the plugin includes & dependencies (easy)
Figure out how to make Mosaic and Mosaic-Plugin against the same OF library (and other shared ones?).
2.a Compile OF as a (dynamic/static?) shared library, link both against it.
2.b Link the plugins against the OF contained within Mosaic ?

This will probably also bring changes to the OF API mappings / bridging. (maybe solving the duplicate singletons issue with the renderers ?)
Anyways, there seem to be some half-answered topics around this. [ -1- / -2- / -3- / -4- ]

Fixed point 1!
https://github.com/d3cod3/ofxMosaicPlugin
compile time drastically reduced and binary size at ~= 27% of the previous size, not bad


i got problem in add automatic update google scholar citation  function.

I tried to add my google scholar citation using the format you left but the citation always shows the wrong number, can you help to figure it out? Thank you so much for your help!

Problem solved! Thank you! I forget to change the repository address...

Problem solved! Thank you! I forget to change the repository address...

did you get this problem? could you tell me how to solve it?


Amendment Suggestion

@lukew3 why do we need different generator, one for surface area then one for volume of a solid. Can't we just merge both of them together.

I think that it's best if their kept seperate so that when a user asks for a problem they know exactly what they are going to get. Although surface area and volume are usually taught at the same time, I think that it would still make sense to keep them seperate in case a student needs to practice just one skill and not another.


Fix the vendor inconsistent issue.

Signed-off-by: xuezhaojun<EMAIL_ADDRESS>https://github.com/stolostron/backlog/issues/26269

/test e2e

e2e is affected by cluster-proxy repo, since it's related with a blocker issue Forece merged and fix it latter.