Allow explicit control of setting attributes vs properties

Compiling template syntaxes that allow users to specify whether an attribute or property is to be set, like Polymer or Angular 2, requires wrapping all primitive values in objects to force property setting. It'd be a lot friendlier of an API to just accept attributes and properties separately in elementOpen.

The problem is that you would need to have an API that is something like:
elementOpen(tagName, key, statics, attrsLength,
  attrName, attrValue,
  attrNameTwo, attrValueTwo,
  ...
  propertyName, propertyValue,
  ...)

We could definitely add a function that applies just attributes or just properties. It might look something like:
elementOpen(tagName, key, statics);
applyAttributes(attrName, attrValue, ....);
applyProperties(propertyName, propertyValue, ...);

Well... I think taking attribute name/value pairs as alternating varargs is a bit of an odd API. Why not just take an array of key values pairs (I suggest this in #115).

That would cause memory allocation for each element call on each render pass, which we are purposefully trying to avoid. If that is really an API that you need, you could just create a small wrapper that does an .apply to the elementOpen, applyAttributes and applyProperties functions.

Hmm... I'd be very careful about assuming the allocation behavior of VMs these days, especially in cases like this where you're accessing arguments in the receiver.
It's possible that a similar allocation has to be made for large argument lists and/or when you access them via arguments, and/or that allocation sinking (which V8's had for a while now, not sure about other VMs) would elide the list because it never escapes the stack. I can ask at least some of the V8 team how it handles cases like this.
Did you measure that the argument list API result in less GC pauses or faster render?

Before getting too far into discussing the name/value pair API, we recently landed an attribute mutator API that'll allow you to define how to set certain attribute/props. Would this suit your purposes?
iDOM.mutators.attributes.attrName = function(el, name, value) {
  el.setAttribute(name, value);
};

iDOM.mutators.attributes.propName = function(el, name, value) {
  el[name] = value;
};

In fact, we even expose the default applyAttr and applyProp, so you all you'd need is:
iDOM.mutators.attributes.attrName = iDOM.defaults.attributes.applyAttr;
iDOM.mutators.attributes.propName = iDOM.defaults.attributes.applyProp;

I can't immediately see how to use that API, who makes the decision whether to call attrName or propName? How would I translate elementOpen('x-foo', null, null, ['id', 'a'], ['foo', bar]) (where the first list is attributes and the second is properties)?

These are defined beforehand. IE, if you know you always want to set id as a property, you're able to define a function mutators.attribute.id that does it:
mutators.attribute.id = function(element, name, value) {
  // Here, `name` = 'id'
  element.id = value;
};

The same goes for foo, or any other attribute. Moreover, there's a special __all mutator that'll be called for any attribute that doesn't have a specific attribute:
mutators.attributes.__all = function(element, name, value) {
  if (shouldSetAsProp(element, name, value)) {
    element[name] = value;
  } else {
    element.setAttribute(name, value);
  }
};

Tangent: If you wanted to get really crazy, you define a "separator" that separates the properties from the attribute in the arguments:
elementOpen('div', 'key', statics, 'attr', 'value1', separator, separator, 'prop', 'value2');

Since iDOM will call __all with (<div>, separator, separator), you could determine attributes and props based on that.

In these templates we only know per source attribute whether you want to assign to an attribute or property. In Polymer attributes are suffixed with a $, properties use a plain name. Angular 2 uses parens and brackets. Polymer example:
<input value$="a"></input><x-foo value="{{bar}}"></x-foo>

input/value is an attribute, but x-foo/value is a property.
Interpreting this requires code like this:
    if (node.nodeType === Node.ELEMENT_NODE) {
      let attributes = getAttributes(node); // gets all attributes ending in '$'
      let properties = getProperties(node); // gets all attributes not ending in '$'
      idom.elementOpen(node.tagName, null, null, ???);

Maybe I can do something with __all:
mutators.attributes.__all = function(element, name, value) {
  if (name.endsWith('$') {
    element.setAttribute(name.substring(0, name.length-1), value);
  } else {
    element[name] = value;
  }
};

I'll try this, however it seems like a complicated and hard to grok API to me.

Maybe I can do something with __all:

That was one of the reasons for __all :wink:.

I'll try this, however it seems like a complicated and hard to grok API to me.

Is it the mutator interface? Or the name/value pairs? I'd love suggestions to make it easier to understand.

Another option might be something like:
elementOpen('div', 'key', statics, 'attributes', [...], 'properties', [...]);

mutators.attributes.attributes = function(element, name, value) {
  // value is an array
}

mutators.attributes.properties = function(element, name, value) {
  // value is an array
}

Though you would want to check for a diff yourself before trying to apply it.

Another option might be something like:

Ah, I didn't even think of that!

On second thought, not a good idea since we would hold on to the arrays when we do our caching when checking for diffs.

Is it the mutator interface? Or the name/value pairs? I'd love suggestions to make it easier to understand.

It's not local. I know at the point I'm calling elementOpen() whether I want to write a property or attribute. Going through an indirection setup in a configuration object is not obvious. The elementOpen, elementClose, text API is very easy to understand. Additional functions in this vein would be easy as well.

I'm not sure in what template syntaxes the attribute / property distinction is known globally. The ones I'm familiar with don't, and I don't see how it would work. I don't think you can always just set known HTML attributes as attributes because in some built-in cases you need to set properties. Neither can you assume unknown or custom element attributes should be properties, since sometimes you need to write attributes for styling and selection. In general the idea of globally pre-configuring attribute vs property just doesn't seem useful to me.

It looks like a global configuration. What happens when two template libraries in the same context are both using incremental-dom and have conflicting configurations? In the upcoming web components world, and seeing as incremental-dom is a compile target, I have to assume this will be common.

If it really is that much of an impact to allocate Arrays, then I think a function-based API like attr() would work, say... prop().
If micro-optimizations are important, it's even possible that in some limited cases that inlining and loop-unrolling could remove some of the cost of the extra function calls (maybe the same types of cases that hopefully kick in when you're iterating over arguments). Speaking of, are there benchmarks we can try out?

Another need on the properties side is to be able to declare static properties. In the templates I deal with, attribute vs property and static vs dynamic are completely orthogonal.

The elementOpen, elementClose, text API is very easy to understand. Additional functions in this vein would be easy as well.

I'm not sure I like this direction, as it would require changes to consider attributes and properties fundamentally different. With the current configuration step, anything from Polymers attr$ declaration to Angular's awkward [bind] syntax can be supported.
But, it does have merits. This would allow formatters with attributes and properties, since we can extend the attr API (the elementOpen API is too limited currently).

I'm not sure in what template syntaxes the attribute / property distinction is known globally

My hope was this would be used to properly support setting/unsetting id as a property, syncing form inputs, etc.

It looks like a global configuration. What happens when two template libraries in the same context are both using incremental-dom and have conflicting configurations?

They are global. We could potentially create iDOM instances, each being able to specify their own configuration.

If it really is that much of an impact to allocate Arrays

I'd actually be really supportive of attribute maps (or arrays). It'll allow us to unwind the method inlining.

Speaking of, are there benchmarks we can try out?

I've been using http://jridgewell.github.io/js-repaint-perfs/incremental-dom/ locally. We should definitely look into automatic benchmark testing.

I'm not sure I like this direction, as it would require changes to consider attributes and properties fundamentally different.

I don't understand the specific objection. The difference between attribute and properties only how they're set and read. You just need a single extra bit to flow with the name/value pair:
set(node, name, value, isProperty) {
  if (isProperty) {
    node[name] = value;
  } else {
    node.setAttribute(name, value);
}

Yes, they are different in how they are set, but whether they are "fundamentally" different I guess is for you to decide. As I mentioned I think I can already get the effect I want by wrapping primitives in objects (and making sure I unbox Strings that I want as attributes?). This means there is a code path from elementOpen to where attributes are set that I can use to force property setting, it's just ungainly and requires unfortunate wrapping.

With the current configuration step, anything from Polymers attr$ declaration to Angular's awkward [bind] syntax can be supported.

The syntax of the template doesn't really matter at all though. The attribute name in the template will be decoded to a target attribute name or property name. I don't see any reason to pass it down to incremental-dom APIs, unless names are really the only to get per-call attribute/property differentiation. Even then, there's no reason to use the template languages particular naming scheme, you could just as easily prefix attributes with something like "--attr--".
Still, going through the configuration function is a few steps to many, and requires this encoding, when it doesn't seem necessary.
idom.patch(node, function() {
  while (node = nextNode()) {
    if (node.nodeType === Node.ELEMENT_NODE) {
      idom.elementOpen(node.tagName);
      for (let attr in getAttributeNames(node)) {
        if (isProperty(attr) {
         idom.property(attr.name, attr.value);
        } else {
         idom.attribute(attr.name, attr.value);
        }
      }
      idom.elementClose(node.tagName);
  }
}.bind(this));

My question about the configuration API is what exactly is gained by putting the if(isProperty(attr)) logic somewhere else, especially somewhere global? What if the logic changes over time (as with different template syntaxes in the same context)? Should I be doing logic like this when setting the configuration:
if (mutators.attributes.__all) {
  throw "Conflicting incremental-dom usage!";
}
mutators.attributes.__all = ...;

Another way I think about this is the orthogonal attributes of attributes:

Static
Dynamic

Attribute
elementOpen() arg 3
elementOpen() varargs

Property
none?
intercept via mutators.attributes.__all

As an API user I find that hard to grok (even if incremental-dom is a compile target, I still need to write the compiler or interpreter).

It can be done, but it would require some fairly substantial changes. In order to tell what attributes have disappeared, we need a full view of the attributes/properties. Even if you aren't doing arbitrary logic in the attributes declaration like for-loops and switches, you can still end up with cases where 'disappearing' attributes need to be removed. For example:
if (condition) {
  elementVoid('div', null, null, 'attrOne', 'value');
} else {
  elementVoid('div', null, null, 'attrTwo', 'value');
}

As far as Incremental DOM is concerned, it can't tell what happened other than then attributes are now different, so it needs to strip attrOne and add attrTwo. If you want to have control with such an API you would basically be doing something along the lines of what elementOpenStart, attr and elementOpenEnd do, which currently comes at a rather large performance cost.

Yes, they are different in how they are set, but whether they are "fundamentally" different I guess is for you to decide.

I was talking more about having different code paths to support both. That we'd be splitting the API into (nodeName, key, statics, attributes, props) (or attr and prop) functions implies that attributes and properties are different, vs the current API that treats them much like the DOM does (node.id = 'test' is the same as node.setAttribute('id', 'test')).

This means there is a code path from elementOpen to where attributes are set that I can use to force property setting, it's just ungainly and requires unfortunate wrapping.

Oh, absolutely. The current property setting was intended only for passing Objects around and event listeners. It's definitely ungainly for forcing property setting.

My question about the configuration API is what exactly is gained by putting the if(isProperty(attr)) logic somewhere else...

The main downside I see is doubling up the logic for attributes and properties. Things like caching, the list of currently set (so that we can unset missing as @sparhami highlighted). Speed would also be an issue, but it wouldn't be significantly worse than if we adopted attribute maps/arrays (taking away the var_args stuff).

... especially somewhere global?

That it's global is definitely a downside, no argument there.

As an API user I find that hard to grok (even if incremental-dom is a compile target, I still need to write the compiler or interpreter).

I think I'm starting to see the issue here, thanks for the table. To iDOM, properties are just attributes. We treat Objects and functions a bit differently during setting, since no one wants those coerced to strings. But, mutators.attributes are called for both properties and attributes (properties are attributes).

Static
Dynamic

Attribute
elementOpen() arg 3
elementOpen() varargs

Property
elementOpen() arg 3
elementOpen() varargs

Additionally, if you want to intercept static or dynamic attributes/properties, providing the appropriate mutators.attributes mutator will do the trick. Or, __all to intercept any attributes/properties.

FWIW:

They are global. We could potentially create iDOM instances, each being able to specify their own configuration.

We absolutely require this be possible. See https://github.com/google/incremental-dom/issues/254#issuecomment-218242391.
If this is something that helps achieve the goal in this issue, then 2 birds, 1 stone etc. However, it seems that can be done separately to this. Should I raise an issue for that or convert my question into an issue for that (just not sure what workflow you prefer)?


Buffered download display

(Needs Chase's pr to be merged first, is based on that)
Because Git doesn't show proper diff with the newly created classes; YouTubeDownloader has 2 new methods, being waitForQueueReduction and addToBufferedDisplay which are used when instantReplay is set to true.
I also check if the videofile for buffered reading already exists to not download it again (uses VideoTitleUtils).
DisplayTask basically does the same as before, just with the abstract method getCurrentFrame (moved over to FileDisplayTask unchanged; BufferedDisplayTask is new).

Will rebase again later

Rebased


ponzu add

Reference issue #85. As discussed, this adds a ponzu add command to the CLI. It fetches the addon from its URI by wrapping go get then copies it to the projects local ./addons directory.
There is no switch for automatically installing. Based on the issue discussion that feature needs more thought, so has been omitted.
I've updated the README to include documentation on the command.
It's been tested as per the approach in the README.

This is what I had in mind for GOPATH resolution
// resolve GOPATH. In 1.8 can be default, or custom. A custom GOPATH can
// also contain multiple paths, in which case 'go get' uses the first
func getGOPATH() (string, error) {
	var gopath string
	gopath = os.Getenv("GOPATH")
	if gopath == "" {
		// not set, find the default
		usr, err := user.Current()
		if err != nil {
			return gopath, err
		}
		gopath = filepath.Join(usr.HomeDir, "go")
	} else {
		// parse out in case of multiple, retain first
		gopaths := strings.Split(gopath, ":") // Linux
		gopath = gopaths[0]
		gopaths = strings.Split(gopath, ";") // Windows
		gopath = gopaths[0]
	}
	return gopath, nil
}

@olliephillips That script could have the same problem I commented you in the code.

@Sirikon - could you link me to the comment / line in the code you mention? I can't find it.

@nilslice https://github.com/ponzu-cms/ponzu/pull/87/files/88dc9b4d26022aeda295e03690c4eb4398e40487#diff-88cf37571f8025a3c6cc4fa53928c999R62

@Sirikon - sorry, I meant the link to your comment that you left about:

That script could have the same problem I commented you in the code.

I don't see any comment there, maybe I'm just missing it..

@nilslice This one you mean? https://github.com/ponzu-cms/ponzu/pull/87/files#r103056524

@Sirikon - odd, this is what I see when clicking your link. No comment from you on the whole PR..

Would you mind copying the comment you made and the line # you're referencing so I can understand what the issue is?
Thanks & sorry for the inconvenience.. really not sure why I can't see the comment

For god sake Github X_X.
Sorry guys, here it is: Line 62-69 of file add.go

The rest of the script seems perfect for me :)

Needed an OS check in end.  Hopefully, this should reliably get GOPATH or the default. At least for Windows/Linux/Mac. If agreed I'll update the PR.
// resolve GOPATH. In 1.8 can be default, or custom. A custom GOPATH can
// also contain multiple paths, in which case 'go get' uses the first
func getGOPATH() (string, error) {
	var gopath string
	gopath = os.Getenv("GOPATH")
	if gopath == "" {
		// not set, find the default
		usr, err := user.Current()
		if err != nil {
			return gopath, err
		}
		gopath = filepath.Join(usr.HomeDir, "go")
	} else {
		// parse out in case of multiple, retain first
		if runtime.GOOS == "windows" {
			gopaths := strings.Split(gopath, ";")
			gopath = gopaths[0]
		} else {
			gopaths := strings.Split(gopath, ":")
			gopath = gopaths[0]
		}
	}
	return gopath, nil
}

Seems okay for me :)

@sirikon - thank you for adding that, sorry it was pending.. not sure how to approve those things
@olliephillips - that looks good to me, go ahead and update the PR at your convenience.
Thanks!

@nilslice That has been added to the PR. I've run through the ponzu build process again and seems ok to me

@olliephillips, thank you for adding this. I think it will be a really big help to make addons a major component of Ponzu systems.
@Sirikon, thank you for your continued involvement and testing!
I really appreciate all of your help.


Add JSXHint handler

This adds a jsxhint handler for Farcy.
I don't want to merge it because it feels like a hack:

I had to overwrite _process because I wanted to provide command line arguments. Duplicating code in the process.
I had to overwrite assert_usable because jsxhint outputs the version string to STDERR.
version_callback does no error checking

I wonder if I should restructure ExtHandler and the other handlers to allow certain pieces of code to be more easily reused or stay with the code duplication.

It looks like if regex_parse was modified to take additional arguments to pass as part of the array to execute, then the problem will be solved pretty easily with respect to overwriting _process.

assert_usable could probably just always redirect stderr to stdout.

version_callback does no error checking

What do you mean?

Fixed all the comments.
With version_callback does no error checking I meant the JSXhint one.


show correct fields at employee request view

Changes Unknown when pulling 9becd9d722e6c344805515f849950ffa9f54fcf5 on fix_employee_request_view into ** on master**.


Milestone #2: decorate a class

Milestone #2: decorate a class 🤓
In this project, I used the Decorator design pattern to correct the names of people.
Summary

Create a class Nameable ✅
Prepare base Decorator✅
Prepare CapitalizeDecorator and TrimmerDecorator✅
Check the functionalities "main.rb"✅

Changes applied
🟢


improve connection and disconnection handling

fix the case where disconnect events
check connection state before handling ACL
add unit tests to connection manager

/test


First weekday and week scope

Setting the first weekday to Monday and using the week scope, the next week will still be showed on Sunday. I'm using the latest versions and this also happens in the demo project.
To make things a little clearer, I have attached a screenshot.

I have also getting same Error.

Hello guys
I'm having the same issue, did you find any solution for this problem?

I have also getting same Error.

The time zone is different

Hi guys, no solution yet ?. I'm having the same issue


fix(aws): check for default named profile

Description
The AWS extension does not properly handle default named profile.
Checklist

[ ] I read the extension guidelines
[ ] I read the documentation about publishing
[ ] I ran npm run build and tested this distribution build in Raycast
[ ] I checked that files in the assets folder are used by the extension itself
[ ] I checked that assets used by the README are placed outside of the metadata folder

relates to: https://github.com/raycast/extensions/issues/4941 and https://github.com/raycast/extensions/issues/4953

Thank you for tackling this! 👏
I could reproduce your issue by using Leapp. Your changes seem to fix the issue. 👍
However, I believe these changes will cause different problems, as the isDefaultProfile ? 'default' : selectedProfile basically overwrites the profile selection setting.
I think the problem rather laid in the const profileOptions definition. This was not accounting for the fact that configFile is an empty object when it doesn't exist (as opposed to undefined).
So I suggest reverting the isDefaultProfile-changes and introducing a change like this:
const { data: configs = { configFile: {}, credentialsFile: {} } } = useCachedPromise(loadSharedConfigFiles);
const { configFile, credentialsFile } = configs;
const profileOptions = Object.keys(configFile).length > 0 ? Object.keys(configFile) : Object.keys(credentialsFile);

This will let profileOptions be a list of profiles even when the configFile is empty or non-existent. In the case of a simple Leapp-setup, that would be ['default'].
Unrelated to the bug, I think we could also make the use effect more robust, like so:
useEffect(() => {
  const isSelectedProfileInvalid = selectedProfile && !profileOptions.includes(selectedProfile);

  if (!selectedProfile || isSelectedProfileInvalid) {
    setSelectedProfile(profileOptions[0]);
  }
}, [profileOptions]);

Looking forward to hear what you think and see if these changes work for you.

Hi @boringContributor 👋
Did you see comments from @JonathanWbn

Hi @pernielsentikaer ,
jip I saw the comments thanks for the input 🙏🏽 However, this won't fix the use of default profiles. I'm pretty busy this week and i'll have a look this weekend though :)


[RFC] New module for thread synchronization.

This gathers some useful thread synchronization primitives gathered from various sources. It includes:

SpinLock implementation, based on https://rigtorp.se/spinlock/
Barrier, translated from glibc source
Semaphore from nim's own sources
RwMonitor (also known as RwLock) from blog post
Arc pointer type, it's the same as fusion/smartptrs SharedPtr
Once @xflywind's patch to the stdlib

Todo:

A test file for each
Documentation and examples

Missing:
ConstPtr, should it be added?
Any kind of queue, for example rust provides a MPSC queue in its library. I have a Nim port of a SPMC queue based on Chase-Lev algorithm. I think it's better to have separate modules for queues.

Maybe each thing in a separate file can look more simple and easy to understand (?), but everything else looks really good.

For now I updated my (module)[https://github.com/planetis-m/sync] because its easier. I still think this belongs to the stdlib. If anyone wants to help by reviewing or contributing /code/tests and benchmarks is very welcome to do so. Please leave this PR open for more visibility.


Better project organisation

For now, it's just some files in one folder - how the heck can someone find the desired extension? I suggest Adding the Class+Extensions/Feature.swift convention to files or for example multiple files like UIView+ToImage,  UIView+FadeAnimations etc. Now it's super complicated to find what you desire. I suggest to add Folder structure like this:

UIKit

UILabel

ULabel+EstimatedSize etc

Foundation

UserDefaults

UserDefaults+Date etc

Interesting thought. I do not particularly like the + convention, since that would bloat up the number of files based on the number of methods that are present. Instead a straightforward UIKit and Foundation split seems more appropriate.
Technically there are two facets to this problem. One is discovery by the user (application programmer who uses this). They wont have any marginal benefit, since they would most probably use their IDE's autocomplete anyways (Xcode, AppCode etc). The other is discoverability for the developer of the framework. In there I see the utility, but I would let the other maintainers chime in on the level of granularity we should have for our folder structure. @lfarah @goktugyil Any comments?

+1 truth the user won't have any benefit, but the developer could be clear. Also I guess it would be better to remove the Extension word from the files since it is obvious that these are Extensions from the name of project ^^

Good point. I will wait for one more maintainer to pitch in before making the changes.

I agree on @Khalian 's comments.
Where are you trying to find the extension from? Github or Xcode?
The extension keyword helps you differentiate from the original file, while using quick open etc.. But it could be shorter like: ext maybe?

Well, if you don't wanna have better organization and rely on jump to definition function in Xcode, I guess it is to keep the chaos as is. So I'll close this issue now. Merry Christmas!


can't figure out how to login

I'm running on arch, the installation was successful and I can launch Bin/Hearthstone.x86_64
but the games kicks me out cause I was not able to login through the blizzard services.
I tried running the login executable (both in the /hearthstone and in the /login folder) but it does nothing, without any errors or outputs.
I also tried to login in manually as per the README file. But the link I followed goes to a website that doesn't load and I can't login in through that either.

Does https://battle.net/login/?app=wtcg work for you? The login app should only pop up a small window and display this page asking for username and password and save the login token after logging in.

Unfortunately not. I'm greeted with a blank page and nothing pops up. Could this be a problem with my tiling manager (qtile)? Perhaps it loads but doesn't appear on screen? Truth is I'm a new linux user so please be patient with me.

So the page is not reachable even through your normal webbrowser? If not, something else must be wrong I think.. Does logging into battle.net/login work?

Yeah, I tried it through firefox. I am able to login to battlenet (the web page).

If you are already logged in when trying to visit https://battle.net/login/?app=wtcg, you should get this immediate redirect as described in the README with the token in the address bar. Otherwise you could also try to open that page without cookies in incognito mode.

I opened it in a private window and finally saw the login page in the browser, not a popup. I entered my credentials but it's been 5 minutes and it's still loading. I believe my connection works just fine.
Maybe a dumb question, but am I supposed to have the battlenet client downloaded or something similar?

I was using chromium... I just tested with firefox and it seems to behave differently, it does not follow the redirect. But you can still get the redirect url if you open dev tools (F12) and go to the network tab, then login and find it in the response headers in the location field. Or since it sets a cookie, look for the gs-hs cookie in storage tab

I opened it with chromium and generated my token :+1: . Now when I open the hearthstone app I get an unable to connect, check your internet connection message.
I'm so sad, I thought I had it this time.

If you created the token with mono token.exe <token> and it said "Created token", then it should be fine. You probably only need to move the created file token into the hearthstone directory.

yep, now it works. Thanks so much

Cool, I'm glad that it works for you now :) However, not sure why the login app does not work for you, it should make it easier.


fix: use openapi global default security settings if given

Current dependencies on/for this PR:

main

PR #9   👈

This comment was auto-generated by Graphite.


Uploading Image through DRF

Hi how I can upload image / file though api ?

can you please show how to upload a file via DRF
Thank you


Add sparse_y param to BiLSTM and CNN that streams sparse Y

Description
Fixes #138
Solves the problem of tensorflow not working with sparse Y vectors like the ones we have for MeSH by introducing a param sparse_y which forces the data to be streamed and converts to dense as per needed which is more memory friendly than densifying the entire Y.
Checklist

[x] Added link to Github issue or Trello card
[x] Added tests

Codecov Report

Merging #137 into master will increase coverage by 0.62%.
The diff coverage is 100.00%.

@@            Coverage Diff             @@
##           master     #137      +/-   ##
==========================================
+ Coverage   78.15%   78.77%   +0.62%
==========================================
  Files          39       39
  Lines        1845     1899      +54
==========================================
+ Hits         1442     1496      +54
  Misses        403      403

Impacted Files
Coverage Δ

wellcomeml/ml/bilstm.py
94.11% <100.00%> (+2.11%)
:arrow_up:

wellcomeml/ml/cnn.py
94.49% <100.00%> (+1.81%)
:arrow_up:

Continue to review full report at Codecov.

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


Show the type of each proxy

When we create a pure proxy, it's by default an "Any" proxy.
Now any account can create other types of proxies. This is also supported by Multix, but it's not displayed anywhere.
E.g you can watch a signatory of DCZyhphXsRLcW84G9WmWEXtAA8DKGtVGSFZLJYty8Ajjyfa on Kusama (this is the ChaosDAO pure proxy) like CrbJuFZWjY3yft424EMTY9hdbWoU878DFs74v3a8nNDeKJD and you will see that there are 2 multisigs behind the pure proxy, one of which has the type "Any", the other "Governance".
The information regarding the type of proxy is available on the indexer in the ProxyAccount type.
https://github.com/ChainSafe/Multix/blob/main/squid/schema.graphql#L32

Now that we have a new design, we can show this info in the multisig details, e.g

Hi, I will pick this up if it's still an issue?

Are there information on the expected behavior of the Proxy Type? At what point during the setup process is the Proxy Type being selected?
On the ticket, I found one place where the proxy type needs to be added in the codebase. In this file exactly, I will open a pull request to add it in.

Hey, I'm not sure what you mean by expected behavior of the proxy type. You never select the proxy type. If any, then it's been set externally.
That's right, you found the place where it should be displayed :+1:

I am trying to figure out how to create the multisig such that the proxy type is  Governance, or Staking or any other type.
It would be good to test how the other values display also. How does the ProxyType get set externally?

I'd like to inroduce a mapping of the ProxyType to String text. This is for readability, we can define
enum ProxyType {
  Any
  Governance
  NonTransfer
  IdentityJudgement
  CancelProxy
  Auction
  Staking
  SudoBalances
  NominationPools
  Society
  Unknown
}

ProxyEnumToString = {
  NonTransfer: "Non Transfer"
  IdentityJudgement: "Identity Judgement"
  CancelProxy: "Cancel Proxy"
  SudoBalances: "Sudo Balances"
  NominationPools: "Nomination Pools"
}

The single string types will remain as is.

The type of proxy can change unexpectedly, so I think we should only replace the string on the fly, rather than try to support them all.
You can use a util function such that does something like the following
str.replace(/[A-Z]/g, function(match, index) {return index === 0 ? match : ` ${match}`})`

effectively adding a space before any non starting upper case.
To create different types of proxy to test, you can follow this guide but I would simply advise to watch accounts that have proxies such as the ones mentioned in the first post

I understand what you are saying. We need to make sure the conversion is future proof.
I'll review the mapping logic I had for the proxy type values. Thank you also for the separation logic, that will be useful too

Is there a default value for the Proxy Type @Tbaut ? For addresses that do not have a proxy, should the proxy type field be hidden?
Without Proxy

With Proxy

yes, it shouldn't be there if it's not a proxy


Dynamic public path output

When running npm run build the index.html is compiled with prefixed / for the asset links. node_modules/react-scripts/config/webpack.config.prod.js  shows me, that the / is currently hardcoded, but when I read the create-react-app source files (config/webpack.config.prod.js) the prefix is built dynamically. So where does the "hard" prefix come from and how to use the homepage property in my local package.json?

So where does the "hard" prefix come from and how to use the homepage property in my local package.json?

From https://github.com/facebookincubator/create-react-app/blob/master/template/README.md#deploy-to-github-pages:

Note: this feature is available with<EMAIL_ADDRESS>and higher.

0.2.0 has not been released yet. So you can’t do it yet.

You can try 0.2.0 alpha now, it handles homepage and contains GH Pages deployment instructions. https://github.com/facebookincubator/create-react-app/pull/190


Shellcheck fixes and prtester doc move

Fixes shellchecker linter issues inside super linter job
Moves the pr tester documentation out of redundant pipelines dir

Fixes: #2530 , #2542
Signed-off-by: Morgan Davies<EMAIL_ADDRESS>

Please do not merge if any checks fail as I would like to validate that my changes did not cause them

Checks look good but seeing as @sxa said he was reviewing this PR in Slack I will hold off merging until that review is in

Will wait for checks to complete then merge


First version of geneIdToName

Both the NCBI RefSeq and Ensemble conversion tables are within the .go file so that issue is solved. Fully functional, I have used it.
To do / options:

Write testing
name to id
option to only keep lines that had a successful conversion
make a web app (?)
open to other suggestions

Here is the code without the explicitley defined NCBI / ENSEMBL maps:
`func makeMap(gnt string) map[string]string {
mp := make(map[string]string)
file := fileio.Read(gnt)
for _, i := range file {
	columns := strings.Split(i, "\t")
	mp[columns[0]] = columns[1]
}
return mp

}
func geneIdToName(geneNameTable string, inFile string, outFile string, ncbi bool, ensembl bool) {
var found bool
var a, name string
var err error
found = false
in := fileio.Read(inFile)
out := fileio.EasyCreate(outFile)

var mp map[string]string

if ncbi {
	mp = makeNcbiMap()
} else if ensembl {
	mp = makeEnsemblMap()
} else {
	mp = makeMap(geneNameTable)
}

var z, x int
for _, i := range in {
	found = false
	columns := strings.Split(i, "\t")
	for j := range columns {
		name, found = mp[columns[j]]
		if found {
			z++
			columns[j] = name
		}
	}
	if !found {
		x++
	}
	a = strings.Join(columns, "\t")
	fileio.WriteToFileHandle(out, a)
}
fmt.Printf("geneIDs lifted: %d\n", z)
fmt.Printf("geneIDs not found: %d\n", x)
err = out.Close()
exception.PanicOnErr(err)

}
func usage() {
fmt.Print("geneIdToName - finds and replaces gene IDs with gene names according to an input table \n" +
"All files must be tab delimited. \n" +
"The input table must be in the format geneID -tab- geneName \n" +
"If a geneID in the input file is not in the inputTable if will remain unchanged in the output\n" +
"Usage:\n" +
"geneIdToName inputTable.txt in.txt out.txt\n" +
"or\n" +
"geneIdToName -ncbi/ensembl in.txt out.txt\n")
flag.PrintDefaults()
}
func main() {
var ncbi *bool = flag.Bool("ncbi", false, "Use the preset NCBI RefSeq ID to Gene Name conversion table (hg38).")
var ensembl *bool = flag.Bool("ensembl", false, "Use the preset ENSEMBL ID to Gene Name conversion table (hg38).")
var expectedNumArgs int
flag.Usage = usage
log.SetFlags(log.Ldate | log.Ltime)
flag.Parse()

if *ncbi || *ensembl {
	expectedNumArgs = 2
} else {
	expectedNumArgs = 3
}

if len(flag.Args()) != expectedNumArgs {
	flag.Usage()
	log.Fatalf("Error: expecting %d arguments, but got %d\n\n", expectedNumArgs, len(flag.Args()))
}
var inputTable, in, out string
if *ncbi || *ensembl {
	in = flag.Arg(0)
	out = flag.Arg(1)
} else {
	inputTable = flag.Arg(0)
	in = flag.Arg(1)
	out = flag.Arg(2)
}
geneIdToName(inputTable, in, out, *ncbi, *ensembl)

}`

Instead of adding the map to the .go file, you might consider using the embed functionality of go (see https://pkg.go.dev/embed).
That was you can keep the file separate so it is a lot easier to maintain (and can be gzipped).

I think the function name "makeMap" should be more explicit considering our map usage and the existing Go function make. Maybe something like makeGeneNamMap.
I think to make this more useable we should at the very least move the makeMap function out to a package and then command would just be geneIdToName, but we can also make a wrapper for that to use as the command and make geneIdToName a package function that we can use throughout the codebase
having the option to not specify ncbi and ensembl and give an alternate gene name table is excellent good job with that!
in usage you have [options] notation for how to write out the program but you also write out the options as if they are required inputs which makes the instructions confusing. I would change this to:
geneIdToNae [options] in.txt out.txt
and then the flag that you have just below that will automatically write out what you've written in the main function for each option.


Arrange params

Final verification of all parameters!
We had some choices to make:

call each parameter explicitly everywhere. That can be long, because we have a LOT of parameters! ex:

dataset = MultisubjectDataset(arg1=arg1, arg2=arg2, .......)
sampler = BatchSampler(arg1=arg1, arg2=arg2).....
model = Model(arg1=arg1, arg2=arg2)....
trainer = Trainer(arg1=arg1, arg2=arg2)...

send the dictionary of parameters:

dataset = MultisubjectDataset(**all_args)
sampler = BatchSampler(**all_args).....
model = Model(**all_args)....
trainer = Trainer(**all_args)...

The code looks nicer, but if some parameters are optional, an error in the dictionary key will not be easy to catch, and variables will be set to default.
We chose to keep option 2, but all parameters are now mandatory (most can be set to None to be ignored).

Hello @EmmaRenauld! Thanks for opening this PR.

In the file dwi_ml/experiment/checks_for_experiment_parameters.py:

Line 256:9: E123 closing bracket does not match indentation of opening bracket's line

In the file dwi_ml/model/batch_samplers.py:

Line 479:53: E127 continuation line over-indented for visual indent
Line 589:80: E501 line too long (82 > 79 characters)

In the file dwi_ml/training/trainers.py:

Line 432:25: E131 continuation line unaligned for hanging indent

In the file dwi_ml/utils.py:

Line 29:59: E226 missing whitespace around arithmetic operator

Do see the PEP 8 -- Style Guide for Python Code


U+16FE4 KHITAN SMALL SCRIPT FILLER should not have InSC=Virama

U+16FE4 KHITAN SMALL SCRIPT FILLER is overridden to Indic_Syllabic_Category=Virama, but that is wrong. Also, it is not useful.
By default, a sequence of Khitan small script letters is rendered as a cluster (similar to a Hangul syllable block) with two letters per row. U+16FE4 forces the preceding letter to be on a row by itself and pushes the following letter onto the next row. U+16FE4 separates letters, whereas a virama joins them, so the override is wrong.
Each KSS letter has USE class BASE. One KSS cluster therefore corresponds to multiple USE clusters (one USE cluster per letter). That makes USE clustering not particularly useful for KSS. Having U+16FE4 put the two surrounding letters in the same USE cluster will still not put the whole KSS cluster into a single USE cluster, so the override is not useful.

Fixed, thank you!


[POC] support dashboard controller per namespace

Proof of concept for supporting a list of namespaces to watch for dashboards.
This adds a new flag --namespaces to the operator which accepts a comma separated list of namespaces. It is mutually exclusive with the --scan-all flag.
If provided, the operator will only watch the listed namespaces for dashboards.
If not provided it will by default watch in its own namespace, or, if --scan-all is set in all namespaces.
This works by creating a separate manager and dashboard controller per namespace.
Requires the cluster roles to be created.
ping @david-martin

creating a separate manager and dashboard controller per namespace

@pb82 Is there a limitation of the operator sdk that's influencing this decision?
Are there any concerns about memory usage if there are a lot of namespaces?
Also, how is the use case of 'all' namespaces handled with this change

@david-martin The limitation is that the operator-sdk (and OS4 itself) only allow watching either one or all namespaces. This solution is also more or less what the Prometheus operator implements (watch per namespace) only that we create a whole controller for every namespace. I don't think there will be an issue with memory usage, the dashbord controller does not use many resources. But I can do some tests how it scales.
The all case is still handled separately: with one controller that watches all namespaces as before. The two flags (namespaces and scan-all) are noth supported both mutually exlcusive (you can't set them both).


Adjust tests to use updated pandas syntax for offsets

[x] Closes #4535 (somewhat)
[x] Tests added
[ ] Passes isort . && black . && mypy . && flake8
[ ] User visible changes (including notable bug fixes) are documented in whats-new.rst

For review

Hello @max-sixty! Thanks for updating this PR. We checked the lines you've touched for PEP 8 issues, and found:

In the file xarray/tests/test_dataarray.py:

Line 10:1: F401 'pandas.testing.assert_index_equal' imported but unused

Hello @max-sixty! Thanks for updating this PR. We checked the lines you've touched for PEP 8 issues, and found:

In the file xarray/tests/test_dataarray.py:

Line 10:1: F401 'pandas.testing.assert_index_equal' imported but unused

@max-sixty, now that CI passes: should we merge this?

LGTM. Thanks @max-sixty & @keewis


sampleRate from dd-trace-js is not taken into account in statistics

Output of the info page (if this is a bug)
Getting the status from the agent.

2020-10-13 18:03:10 UTC | CORE | DEBUG | (pkg/util/log/log.go:473 in func1) | cloud_provider_metadata is set to [aws gcp azure alibaba] in agent configuration, trying endpoints for AWS Cloud Provider
2020-10-13 18:03:10 UTC | CORE | DEBUG | (pkg/util/log/log.go:473 in func1) | cloud_provider_metadata is set to [aws gcp azure alibaba] in agent configuration, trying endpoints for AWS Cloud Provider
===============
Agent (v7.22.1)
===============

  Status date: 2020-10-13 18:03:10.106111 UTC
  Agent start: 2020-10-02 03:15:54.198392 UTC
  Pid: 383
  Go Version: go1.13.11
  Python Version: 3.8.5
  Build arch: amd64
  Agent flavor: agent
  Check Runners: 4
  Log Level: debug

  Paths
  =====
    Config File: /etc/datadog-agent/datadog.yaml
    conf.d: /etc/datadog-agent/conf.d
    checks.d: /etc/datadog-agent/checks.d

  Clocks
  ======
    NTP offset: -2.713ms
    System UTC time: 2020-10-13 18:03:10.106111 UTC

  Host Info
  =========
    bootTime: 2020-09-24 13:11:48.000000 UTC
    kernelArch: x86_64
    kernelVersion: 4.4.0-1101-aws
    os: linux
    platform: debian
    platformFamily: debian
    platformVersion: bullseye/sid
    procs: 555
    uptime: 182h4m13s
    virtualizationRole: guest
    virtualizationSystem: xen

  Hostnames
  =========
    ec2-hostname: ip-10-10-3-92.ec2.internal
    host_aliases: [ip-10-10-3-92.ec2.internal]
    hostname: ip-10-10-3-92.ec2.internal
    instance-id: i-0a3254cd1fb05093a
    socket-fqdn: dd-agent-lsbx2
    socket-hostname: dd-agent-lsbx2
    host tags:
      kubernetescluster:sandbox.k8s.centrio.com
      cluster_name:sandbox.k8s.centrio.com
      environment:sandbox
      cluster_type:kubernetes
      kube_node_role:node
    hostname provider: configuration

  Metadata
  ========
    cloud_provider: AWS
    hostname_source: configuration

=========
Collector
=========

  Running Checks
  ==============

    cpu
    ---
      Instance ID: cpu [OK]
      Configuration Source: file:/etc/datadog-agent/conf.d/cpu.d/conf.yaml.default
      Total Runs: 66,909
      Metric Samples: Last Run: 7, Total: 468,357
      Events: Last Run: 0, Total: 0
      Service Checks: Last Run: 0, Total: 0
      Average Execution Time : 0s
      Last Execution Date : 2020-10-13 18:03:00.000000 UTC
      Last Successful Execution Date : 2020-10-13 18:03:00.000000 UTC

    disk (2.10.1)
    -------------
      Instance ID: disk:e5dffb8bef24336f [OK]
      Configuration Source: file:/etc/datadog-agent/conf.d/disk.d/conf.yaml.default
      Total Runs: 66,909
      Metric Samples: Last Run: 286, Total: 19,143,170
      Events: Last Run: 0, Total: 0
      Service Checks: Last Run: 0, Total: 0
      Average Execution Time : 55ms
      Last Execution Date : 2020-10-13 18:03:07.000000 UTC
      Last Successful Execution Date : 2020-10-13 18:03:07.000000 UTC

    docker
    ------
      Instance ID: docker [OK]
      Configuration Source: file:/etc/datadog-agent/conf.d/docker.d/conf.yaml.default
      Total Runs: 66,908
      Metric Samples: Last Run: 3,042, Total: 168,953,779
      Events: Last Run: 0, Total: 4,971
      Service Checks: Last Run: 1, Total: 66,908
      Average Execution Time : 1.358s
      Last Execution Date : 2020-10-13 18:03:00.000000 UTC
      Last Successful Execution Date : 2020-10-13 18:03:00.000000 UTC

    etcd (2.4.1)
    ------------
      Instance ID: etcd:e6cc2959f8f11055 [OK]
      Configuration Source: kubelet:docker://2e8bbfe98827f98f6a944ac127d5dc788d5ac939bf891f2670d953568609c586
      Total Runs: 66,909
      Metric Samples: Last Run: 1,053, Total: 70,455,177
      Events: Last Run: 0, Total: 0
      Service Checks: Last Run: 1, Total: 66,909
      Average Execution Time : 268ms
      Last Execution Date : 2020-10-13 18:03:01.000000 UTC
      Last Successful Execution Date : 2020-10-13 18:03:01.000000 UTC
      metadata:
        version.major: 3
        version.minor: 3
        version.patch: 1
        version.raw: 3.3.1
        version.scheme: semver

    file_handle
    -----------
      Instance ID: file_handle [OK]
      Configuration Source: file:/etc/datadog-agent/conf.d/file_handle.d/conf.yaml.default
      Total Runs: 66,909
      Metric Samples: Last Run: 5, Total: 334,545
      Events: Last Run: 0, Total: 0
      Service Checks: Last Run: 0, Total: 0
      Average Execution Time : 0s
      Last Execution Date : 2020-10-13 18:03:06.000000 UTC
      Last Successful Execution Date : 2020-10-13 18:03:06.000000 UTC

    fluentd (1.9.1)
    ---------------
      Instance ID: fluentd:2323b6cd70c8e638 [OK]
      Configuration Source: kubelet:docker://122b0dcc018208c5f16519e50d236d5755bbf7d16c4ebd9d45f720c8dd0ae998
      Total Runs: 66,909
      Metric Samples: Last Run: 5, Total: 334,545
      Events: Last Run: 0, Total: 0
      Service Checks: Last Run: 1, Total: 66,909
      Average Execution Time : 46ms
      Last Execution Date : 2020-10-13 18:03:09.000000 UTC
      Last Successful Execution Date : 2020-10-13 18:03:09.000000 UTC
      metadata:
        version.major: 1
        version.minor: 11
        version.patch: 2
        version.raw: 1.11.2
        version.scheme: semver

    http_check (4.10.0)
    -------------------
      Instance ID: http_check:etcd:555f04d8819efe8d [OK]
      Configuration Source: file:/etc/datadog-agent/conf.d/http_check.yaml
      Total Runs: 66,908
      Metric Samples: Last Run: 5, Total: 334,540
      Events: Last Run: 0, Total: 0
      Service Checks: Last Run: 2, Total: 133,816
      Average Execution Time : 121ms
      Last Execution Date : 2020-10-13 18:02:59.000000 UTC
      Last Successful Execution Date : 2020-10-13 18:02:59.000000 UTC

      Instance ID: http_check:registry:70f468b5e2e82a72 [OK]
      Configuration Source: file:/etc/datadog-agent/conf.d/http_check.yaml
      Total Runs: 66,909
      Metric Samples: Last Run: 5, Total: 334,545
      Events: Last Run: 0, Total: 0
      Service Checks: Last Run: 2, Total: 133,818
      Average Execution Time : 82ms
      Last Execution Date : 2020-10-13 18:03:00.000000 UTC
      Last Successful Execution Date : 2020-10-13 18:03:00.000000 UTC

      Instance ID: http_check:vault:78f6fdb97c23bf67 [OK]
      Configuration Source: file:/etc/datadog-agent/conf.d/http_check.yaml
      Total Runs: 66,909
      Metric Samples: Last Run: 5, Total: 334,545
      Events: Last Run: 0, Total: 0
      Service Checks: Last Run: 2, Total: 133,818
      Average Execution Time : 32ms
      Last Execution Date : 2020-10-13 18:03:07.000000 UTC
      Last Successful Execution Date : 2020-10-13 18:03:07.000000 UTC

    io
    --
      Instance ID: io [OK]
      Configuration Source: file:/etc/datadog-agent/conf.d/io.d/conf.yaml.default
      Total Runs: 66,908
      Metric Samples: Last Run: 104, Total: 7,005,138
      Events: Last Run: 0, Total: 0
      Service Checks: Last Run: 0, Total: 0
      Average Execution Time : 1ms
      Last Execution Date : 2020-10-13 18:02:58.000000 UTC
      Last Successful Execution Date : 2020-10-13 18:02:58.000000 UTC

    istio (3.5.0)
    -------------
      Instance ID: istio:24171b3af241dcac [OK]
      Configuration Source: file:/etc/datadog-agent/conf.d/istio.d/auto_conf.yaml
      Total Runs: 4,924
      Metric Samples: Last Run: 266, Total: 1,278,506
      Events: Last Run: 0, Total: 0
      Service Checks: Last Run: 0, Total: 0
      Average Execution Time : 314ms
      Last Execution Date : 2020-10-13 18:03:09.000000 UTC
      Last Successful Execution Date : 2020-10-13 18:03:09.000000 UTC

      Instance ID: istio:2eafd24a193bbdad [OK]
      Configuration Source: file:/etc/datadog-agent/conf.d/istio.d/auto_conf.yaml
      Total Runs: 61,808
      Metric Samples: Last Run: 136, Total: 8,405,376
      Events: Last Run: 0, Total: 0
      Service Checks: Last Run: 0, Total: 0
      Average Execution Time : 277ms
      Last Execution Date : 2020-10-13 18:03:01.000000 UTC
      Last Successful Execution Date : 2020-10-13 18:03:01.000000 UTC

      Instance ID: istio:4987ffa6a81cb879 [OK]
      Configuration Source: file:/etc/datadog-agent/conf.d/istio.d/auto_conf.yaml
      Total Runs: 4,926
      Metric Samples: Last Run: 266, Total: 1,278,648
      Events: Last Run: 0, Total: 0
      Service Checks: Last Run: 0, Total: 0
      Average Execution Time : 219ms
      Last Execution Date : 2020-10-13 18:02:55.000000 UTC
      Last Successful Execution Date : 2020-10-13 18:02:55.000000 UTC

      Instance ID: istio:54f741acc44bba44 [OK]
      Configuration Source: file:/etc/datadog-agent/conf.d/istio.d/auto_conf.yaml
      Total Runs: 66,908
      Metric Samples: Last Run: 266, Total: 17,662,518
      Events: Last Run: 0, Total: 0
      Service Checks: Last Run: 0, Total: 0
      Average Execution Time : 175ms
      Last Execution Date : 2020-10-13 18:02:58.000000 UTC
      Last Successful Execution Date : 2020-10-13 18:02:58.000000 UTC

      Instance ID: istio:551564bf368b27c8 [OK]
      Configuration Source: file:/etc/datadog-agent/conf.d/istio.d/auto_conf.yaml
      Total Runs: 12
      Metric Samples: Last Run: 128, Total: 1,536
      Events: Last Run: 0, Total: 0
      Service Checks: Last Run: 0, Total: 0
      Average Execution Time : 99ms
      Last Execution Date : 2020-10-13 18:03:04.000000 UTC
      Last Successful Execution Date : 2020-10-13 18:03:04.000000 UTC

      Instance ID: istio:5883e5729525841f [OK]
      Configuration Source: file:/etc/datadog-agent/conf.d/istio.d/auto_conf.yaml
      Total Runs: 61,809
      Metric Samples: Last Run: 136, Total: 8,405,384
      Events: Last Run: 0, Total: 0
      Service Checks: Last Run: 0, Total: 0
      Average Execution Time : 304ms
      Last Execution Date : 2020-10-13 18:03:09.000000 UTC
      Last Successful Execution Date : 2020-10-13 18:03:09.000000 UTC

      Instance ID: istio:5a7d66fad1b0c7a1 [OK]
      Configuration Source: file:/etc/datadog-agent/conf.d/istio.d/auto_conf.yaml
      Total Runs: 689
      Metric Samples: Last Run: 8, Total: 5,512
      Events: Last Run: 0, Total: 0
      Service Checks: Last Run: 0, Total: 0
      Average Execution Time : 76ms
      Last Execution Date : 2020-10-13 18:03:02.000000 UTC
      Last Successful Execution Date : 2020-10-13 18:03:02.000000 UTC

      Instance ID: istio:60d02d654582df26 [OK]
      Configuration Source: file:/etc/datadog-agent/conf.d/istio.d/auto_conf.yaml
      Total Runs: 692
      Metric Samples: Last Run: 8, Total: 5,536
      Events: Last Run: 0, Total: 0
      Service Checks: Last Run: 0, Total: 0
      Average Execution Time : 147ms
      Last Execution Date : 2020-10-13 18:02:55.000000 UTC
      Last Successful Execution Date : 2020-10-13 18:02:55.000000 UTC

      Instance ID: istio:6eabd3d89f43ec89 [OK]
      Configuration Source: file:/etc/datadog-agent/conf.d/istio.d/auto_conf.yaml
      Total Runs: 66,909
      Metric Samples: Last Run: 128, Total: 8,564,352
      Events: Last Run: 0, Total: 0
      Service Checks: Last Run: 0, Total: 0
      Average Execution Time : 180ms
      Last Execution Date : 2020-10-13 18:03:05.000000 UTC
      Last Successful Execution Date : 2020-10-13 18:03:05.000000 UTC

      Instance ID: istio:947b2c27fbf4d79b [OK]
      Configuration Source: file:/etc/datadog-agent/conf.d/istio.d/auto_conf.yaml
      Total Runs: 66,908
      Metric Samples: Last Run: 142, Total: 9,500,936
      Events: Last Run: 0, Total: 0
      Service Checks: Last Run: 0, Total: 0
      Average Execution Time : 126ms
      Last Execution Date : 2020-10-13 18:02:57.000000 UTC
      Last Successful Execution Date : 2020-10-13 18:02:57.000000 UTC

      Instance ID: istio:9ed3860d14bfc6f [OK]
      Configuration Source: file:/etc/datadog-agent/conf.d/istio.d/auto_conf.yaml
      Total Runs: 66,909
      Metric Samples: Last Run: 142, Total: 9,501,078
      Events: Last Run: 0, Total: 0
      Service Checks: Last Run: 0, Total: 0
      Average Execution Time : 310ms
      Last Execution Date : 2020-10-13 18:03:01.000000 UTC
      Last Successful Execution Date : 2020-10-13 18:03:01.000000 UTC

      Instance ID: istio:aea0971ba1098ee0 [OK]
      Configuration Source: file:/etc/datadog-agent/conf.d/istio.d/auto_conf.yaml
      Total Runs: 66,908
      Metric Samples: Last Run: 0, Total: 0
      Events: Last Run: 0, Total: 0
      Service Checks: Last Run: 0, Total: 0
      Average Execution Time : 94ms
      Last Execution Date : 2020-10-13 18:02:56.000000 UTC
      Last Successful Execution Date : 2020-10-13 18:02:56.000000 UTC

      Instance ID: istio:dd86f29b714c010e [OK]
      Configuration Source: file:/etc/datadog-agent/conf.d/istio.d/auto_conf.yaml
      Total Runs: 23,024
      Metric Samples: Last Run: 190, Total: 7,286,640
      Events: Last Run: 0, Total: 0
      Service Checks: Last Run: 0, Total: 0
      Average Execution Time : 359ms
      Last Execution Date : 2020-10-13 18:03:09.000000 UTC
      Last Successful Execution Date : 2020-10-13 18:03:09.000000 UTC

      Instance ID: istio:f297d5631c71a9db [OK]
      Configuration Source: file:/etc/datadog-agent/conf.d/istio.d/auto_conf.yaml
      Total Runs: 23,009
      Metric Samples: Last Run: 190, Total: 7,283,620
      Events: Last Run: 0, Total: 0
      Service Checks: Last Run: 0, Total: 0
      Average Execution Time : 171ms
      Last Execution Date : 2020-10-13 18:02:59.000000 UTC
      Last Successful Execution Date : 2020-10-13 18:02:59.000000 UTC

    kubelet (4.1.1)
    ---------------
      Instance ID: kubelet:d884b5186b651429 [OK]
      Configuration Source: file:/etc/datadog-agent/conf.d/kubelet.d/conf.yaml.default
      Total Runs: 66,901
      Metric Samples: Last Run: 2,710, Total: 151,295,704
      Events: Last Run: 0, Total: 0
      Service Checks: Last Run: 4, Total: 267,604
      Average Execution Time : 1.048s
      Last Execution Date : 2020-10-13 18:03:06.000000 UTC
      Last Successful Execution Date : 2020-10-13 18:03:06.000000 UTC

    load
    ----
      Instance ID: load [OK]
      Configuration Source: file:/etc/datadog-agent/conf.d/load.d/conf.yaml.default
      Total Runs: 66,908
      Metric Samples: Last Run: 6, Total: 401,448
      Events: Last Run: 0, Total: 0
      Service Checks: Last Run: 0, Total: 0
      Average Execution Time : 0s
      Last Execution Date : 2020-10-13 18:02:57.000000 UTC
      Last Successful Execution Date : 2020-10-13 18:02:57.000000 UTC

    memory
    ------
      Instance ID: memory [OK]
      Configuration Source: file:/etc/datadog-agent/conf.d/memory.d/conf.yaml.default
      Total Runs: 66,909
      Metric Samples: Last Run: 18, Total: 1,204,362
      Events: Last Run: 0, Total: 0
      Service Checks: Last Run: 0, Total: 0
      Average Execution Time : 0s
      Last Execution Date : 2020-10-13 18:03:04.000000 UTC
      Last Successful Execution Date : 2020-10-13 18:03:04.000000 UTC

    network (1.17.0)
    ----------------
      Instance ID: network:5c571333f400457d [OK]
      Configuration Source: file:/etc/datadog-agent/conf.d/network.d/conf.yaml.default
      Total Runs: 66,908
      Metric Samples: Last Run: 31, Total: 2,074,148
      Events: Last Run: 0, Total: 0
      Service Checks: Last Run: 0, Total: 0
      Average Execution Time : 9ms
      Last Execution Date : 2020-10-13 18:02:56.000000 UTC
      Last Successful Execution Date : 2020-10-13 18:02:56.000000 UTC

    nginx (3.8.1)
    -------------
      Instance ID: nginx:bc19242fd3bdbe8d [OK]
      Configuration Source: file:/etc/datadog-agent/conf.d/nginx.yaml
      Total Runs: 66,909
      Metric Samples: Last Run: 7, Total: 468,363
      Events: Last Run: 0, Total: 0
      Service Checks: Last Run: 1, Total: 66,909
      Average Execution Time : 12ms
      Last Execution Date : 2020-10-13 18:03:08.000000 UTC
      Last Successful Execution Date : 2020-10-13 18:03:08.000000 UTC
      metadata:
        version.major: 1
        version.minor: 15
        version.patch: 8
        version.raw: 1.15.8
        version.scheme: semver

    ntp
    ---
      Instance ID: ntp:d884b5186b651429 [OK]
      Configuration Source: file:/etc/datadog-agent/conf.d/ntp.d/conf.yaml.default
      Total Runs: 1,116
      Metric Samples: Last Run: 1, Total: 1,116
      Events: Last Run: 0, Total: 0
      Service Checks: Last Run: 1, Total: 1,116
      Average Execution Time : 859ms
      Last Execution Date : 2020-10-13 18:01:01.000000 UTC
      Last Successful Execution Date : 2020-10-13 18:01:01.000000 UTC

    openmetrics (1.9.0)
    -------------------
      Instance ID: openmetrics:node_exporter:d2f022cea06294a5 [OK]
      Configuration Source: kubelet:docker://aef8dc9dc234c6a99fc5a75cc075f67b0554b113cd994daea86ab1fbb1159476
      Total Runs: 66,909
      Metric Samples: Last Run: 6, Total: 401,454
      Events: Last Run: 0, Total: 0
      Service Checks: Last Run: 1, Total: 66,909
      Average Execution Time : 136ms
      Last Execution Date : 2020-10-13 18:03:02.000000 UTC
      Last Successful Execution Date : 2020-10-13 18:03:02.000000 UTC

    prometheus (3.3.0)
    ------------------
      Instance ID: prometheus:calico:4f701ba9713d0d8 [OK]
      Configuration Source: kubelet:docker://64f5befc751e6900f8c8646b0e6b5b87326a7ac8f8e3e84668497bee23d3522b
      Total Runs: 66,908
      Metric Samples: Last Run: 148, Total: 9,611,384
      Events: Last Run: 0, Total: 0
      Service Checks: Last Run: 1, Total: 66,908
      Average Execution Time : 60ms
      Last Execution Date : 2020-10-13 18:02:55.000000 UTC
      Last Successful Execution Date : 2020-10-13 18:02:55.000000 UTC

    uptime
    ------
      Instance ID: uptime [OK]
      Configuration Source: file:/etc/datadog-agent/conf.d/uptime.d/conf.yaml.default
      Total Runs: 66,909
      Metric Samples: Last Run: 1, Total: 66,909
      Events: Last Run: 0, Total: 0
      Service Checks: Last Run: 0, Total: 0
      Average Execution Time : 0s
      Last Execution Date : 2020-10-13 18:03:03.000000 UTC
      Last Successful Execution Date : 2020-10-13 18:03:03.000000 UTC

  Check Initialization Errors
  ===========================

      etcd (2.4.1)
      ------------

      instance 0:

        could not invoke 'etcd' python check constructor. New constructor API returned:
Traceback (most recent call last):
  File "/opt/datadog-agent/embedded/lib/python3.8/site-packages/datadog_checks/etcd/etcd.py", line 86, in __init__
    super(Etcd, self).__init__(
  File "/opt/datadog-agent/embedded/lib/python3.8/site-packages/datadog_checks/base/checks/openmetrics/base_check.py", line 100, in __init__
    self.get_scraper_config(instance)
  File "/opt/datadog-agent/embedded/lib/python3.8/site-packages/datadog_checks/base/checks/openmetrics/base_check.py", line 122, in get_scraper_config
    raise CheckException("Unable to find prometheus URL in config file.")
datadog_checks.base.errors.CheckException: Unable to find prometheus URL in config file.
Deprecated constructor API returned:
__init__() got an unexpected keyword argument 'agentConfig'
  Loading Errors
  ==============
    etcd
    ----
      Core Check Loader:
        Check etcd not found in Catalog

      JMX Check Loader:
        check is not a jmx check, or unable to determine if it's so

      Python Check Loader:
        could not configure check instance for python check etcd: could not invoke 'etcd' python check constructor. New constructor API returned:
Traceback (most recent call last):
  File "/opt/datadog-agent/embedded/lib/python3.8/site-packages/datadog_checks/etcd/etcd.py", line 86, in __init__
    super(Etcd, self).__init__(
  File "/opt/datadog-agent/embedded/lib/python3.8/site-packages/datadog_checks/base/checks/openmetrics/base_check.py", line 100, in __init__
    self.get_scraper_config(instance)
  File "/opt/datadog-agent/embedded/lib/python3.8/site-packages/datadog_checks/base/checks/openmetrics/base_check.py", line 122, in get_scraper_config
    raise CheckException("Unable to find prometheus URL in config file.")
datadog_checks.base.errors.CheckException: Unable to find prometheus URL in config file.
Deprecated constructor API returned:
__init__() got an unexpected keyword argument 'agentConfig'

========
JMXFetch
========

  Initialized checks
  ==================
    no checks

  Failed checks
  =============
    no checks

=========
Forwarder
=========

  Transactions
  ============
    CheckRunsV1: 66,909
    Connections: 0
    Containers: 0
    Deployments: 0
    Dropped: 0
    DroppedOnInput: 0
    Events: 0
    HostMetadata: 0
    IntakeV1: 10,368
    Metadata: 0
    Pods: 0
    Processes: 0
    RTContainers: 0
    RTProcesses: 0
    ReplicaSets: 0
    Requeued: 2
    Retried: 2
    RetryQueueSize: 0
    Series: 0
    ServiceChecks: 0
    Services: 0
    SketchSeries: 0
    Success: 275,022
    TimeseriesV1: 66,909

  Transaction Errors
  ==================
    Total number: 1
    Errors By Type:

  API Keys status
  ===============
    API key ending with 05c5f: API Key valid

==========
Endpoints
==========
  https://app.datadoghq.com - API Key ending with:
      - 05c5f

==========
Logs Agent
==========

  Logs Agent is not running

=========
APM Agent
=========
  Status: Running
  Pid: 386
  Uptime: 1.003636e+06 seconds
  Mem alloc: 42,797,264 bytes
  Hostname: ip-10-10-3-92.ec2.internal
  Receiver: <IP_ADDRESS>:8126
  Endpoints:
    https://trace.agent.datadoghq.com

  Receiver (previous minute)
  ==========================
    From go 1.14.7 (gc-amd64-linux), client v1.5.0
      Traces received: 13 (6,655 bytes)
      Spans received: 19

    From nodejs v12.14.1 (v8), client 0.20.3
      Traces received: 365 (3,488,319 bytes)
      Spans received: 7277

    From go 1.14.6 (gc-amd64-linux), client v1.2
      Traces received: 282 (115,761 bytes)
      Spans received: 289

    From go 1.14.7 (gc-amd64-linux), client v1.20.1
      Traces received: 864 (436,837 bytes)
      Spans received: 864

    From go 1.15.2 (gc-amd64-linux), client v1.2
      Traces received: 357 (256,525 bytes)
      Spans received: 613

    From nodejs v12.13.1 (v8), client 0.20.3
      Traces received: 226 (866,516 bytes)
      Spans received: 1562

    From nodejs v12.14.1 (v8), client 0.15.4
      Traces received: 39 (89,636 bytes)
      Spans received: 345

    Default priority sampling rate: 9.5%
    Priority sampling rate for 'service:blend-backend-http-client,env:sandbox': 100.0%
    Priority sampling rate for 'service:blend-backend-mongodb,env:sandbox': 100.0%
    Priority sampling rate for 'service:blend-backend-tcp,env:sandbox': 100.0%
    Priority sampling rate for 'service:blend-express,env:sandbox': 100.0%
    Priority sampling rate for 'service:blend-highpriority-aws-sqs,env:sandbox': 100.0%
    Priority sampling rate for 'service:blend-highpriority-http-client,env:sandbox': 100.0%
    Priority sampling rate for 'service:blend-highpriority-mongodb,env:sandbox': 100.0%
    Priority sampling rate for 'service:blend-highpriority-tcp,env:sandbox': 100.0%
    Priority sampling rate for 'service:blend-highresource-aws-sqs,env:sandbox': 100.0%
    Priority sampling rate for 'service:blend-highresource-http-client,env:sandbox': 100.0%
    Priority sampling rate for 'service:blend-highresource-mongodb,env:sandbox': 100.0%
    Priority sampling rate for 'service:blend-mediumpriority-http-client,env:sandbox': 100.0%
    Priority sampling rate for 'service:blend-mediumpriority-mongodb,env:sandbox': 100.0%
    Priority sampling rate for 'service:blend-mediumpriority-tcp,env:sandbox': 100.0%
    Priority sampling rate for 'service:blend-retry-aws-sqs,env:sandbox': 100.0%
    Priority sampling rate for 'service:blend-retry-http-client,env:sandbox': 100.0%
    Priority sampling rate for 'service:blend-retry-mongodb,env:sandbox': 100.0%
    Priority sampling rate for 'service:blend-retry-tcp,env:sandbox': 100.0%
    Priority sampling rate for 'service:borrower-sync-express,env:sandbox': 100.0%
    Priority sampling rate for 'service:borrower-sync-http-client,env:sandbox': 100.0%
    Priority sampling rate for 'service:chantest-proxy,env:sandbox': 100.0%
    Priority sampling rate for 'service:coordinate-organizer-express,env:sandbox': 100.0%
    Priority sampling rate for 'service:coordinate-organizer-proxy,env:sandbox': 100.0%
    Priority sampling rate for 'service:disclosures-worker-high-priority-aws-sqs,env:sandbox': 100.0%
    Priority sampling rate for 'service:files-worker,env:sandbox': 100.0%
    Priority sampling rate for 'service:files-worker-aws-sqs,env:sandbox': 100.0%
    Priority sampling rate for 'service:files-worker-http-client,env:sandbox': 100.0%
    Priority sampling rate for 'service:files-worker-mongodb,env:sandbox': 100.0%
    Priority sampling rate for 'service:home-insurance-custom-workflow-proxy,env:sandbox': 100.0%
    Priority sampling rate for 'service:movement-fees-express,env:sandbox': 100.0%
    Priority sampling rate for 'service:orgchart-dns,env:sandbox': 100.0%
    Priority sampling rate for 'service:orgchart-express,env:sandbox': 100.0%
    Priority sampling rate for 'service:orgchart-tcp,env:sandbox': 100.0%
    Priority sampling rate for 'service:osquery-fleet-proxy,env:sandbox': 13.2%

  Writer (previous minute)
  ========================
    Traces: 0 payloads, 0 traces, 0 events, 0 bytes
    Stats: 0 payloads, 0 stats buckets, 0 bytes

=========
Aggregator
=========
  Checks Metric Sample: 585,893,449
  Dogstatsd Metric Sample: 382,416,336
  Event: 6,137
  Events Flushed: 6,137
  Number Of Flushes: 66,909
  Series Flushed: 654,396,032
  Service Check: 3,330,579
  Service Checks Flushed: 3,397,488

=========
DogStatsD
=========
  Event Packets: 1,165
  Event Parse Errors: 37
  Metric Packets: 382,416,335
  Metric Parse Errors: 39
  Service Check Packets: 0
  Service Check Parse Errors: 0
  Udp Bytes: 27,264,962,121
  Udp Packet Reading Errors: 0
  Udp Packets: 66,836,310
  Uds Bytes: 36,193,786,796
  Uds Origin Detection Errors: 0
  Uds Packet Reading Errors: 0
  Uds Packets: 31,058,713

=====================
Datadog Cluster Agent
=====================

  - Datadog Cluster Agent endpoint detected: https://<IP_ADDRESS>:5005
  Successfully connected to the Datadog Cluster Agent.
  - Running: 1.8.0+commit.934d5c5

Describe what happened:
The number of hits registered by APM increased by a factor of four when the sample rate was decreased by a factor of four, even though there was no change to traffic pattern of the service.

Describe what you expected:
There should not have been a change to the number of hits (within error).  With sampleRate: 0.25, the service should be sending 25% the spans and the agent should adjust the statistics appropriately and there should not be a cliff visible like above (either upwards or downwards).
Steps to reproduce the issue:

Send traces from dd-trace-js with sampleRate: 1
Reduce the sampleRate by a factor of 4: sampleRate: 0.25

Additional environment details (Operating System, Cloud provider, etc):

@millerick did you find out what is going on here, I am observing something similar and would like to understand more 🤓


chore: Regarding the restrictions on package imports, consider introducing linting or documentation.

I've noticed in several PRs that there are reviews mentioning not to import runtime-core or compiler-core into vapor.
Indeed, it seems this isn't written anywhere, so we should compile the constraints and either lint the imports or include them in the contribution guide.
Even if we introduce linting, I think it might not be clear how to address it, so documentation is probably better. (Something along the lines of 'please implement by copying').

@LittleSound
Thanks! https://github.com/vuejs/core-vapor/commit/c82ed7d8a1522ab6d7f8747ca09760eaccb97f72


basicAuthentication support for ElasticsearchServiceProvider

Codecov Report

Merging #210 (ee71b0f) into master (2677c4d) will decrease coverage by 0.52%.
The diff coverage is 62.50%.

@@             Coverage Diff              @@
##             master     #210      +/-   ##
============================================
- Coverage     95.68%   95.16%   -0.53%
- Complexity      178      181       +3
============================================
  Files            34       34
  Lines           510      517       +7
============================================
+ Hits            488      492       +4
- Misses           22       25       +3

Impacted Files
Coverage Δ

src/ElasticSearch/Config/Storage.php
85.71% <50.00%> (-14.29%)
:arrow_down:

src/ElasticSearchServiceProvider.php
92.30% <75.00%> (-7.70%)
:arrow_down:

Continue to review full report at Codecov.

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

Do you think it will work with multiple hosts? What will happen if hosts have different credentials?

Let me think about it. You are right. I will do a better solution.

Maybe some guard to multiple hosts? But single credentials for many hosts looks like valid case as well, so guard can be overkill.

İn any case I'm  ok even with configuration with single credentials. I think it make sense to have basic config with auth

On official client, we need to use one credential for all hosts :
$client = ClientBuilder::create()
    ->setHosts(['https://localhost:9200'])
    ->setBasicAuthentication('elastic', 'password copied during Elasticsearch start')
    ->setCABundle('path/to/http_ca.crt')
    ->build();

Then looks like we're safe) could you update change log?

Sure, also, I need to fix the coverage. I will handle it at the end of the business hour.

Great job 🙏 I'm going to merge. is there something that you want to finish before

👍  as a next iteration we can check CA bundle also.


[BUG] can't upgrade engine if a volume was created in Longhorn v1.0 and the volume.spec.dataLocality is ""

Describe the bug
can't upgrade engine if a volume was created in Longhorn v1.0 and its volume.spec.dataLocality ""

v1.0 does not have the dataLocality parameter, and the value is not handled in the upgrade path (v1.0->v1.1 and v1.1->v1.2) and always keeps an empty sting, so users might hit this issue while upgrading to v1.3.x if the volume was created in v1.0.
To Reproduce
Steps to reproduce the behavior:

Deploy Longhorn v1.0
Create a volume
Upgrade Longhorn to v1.2.x and then upgrade the volume's engine
Upgrade Longhorn to v1.3.x. Then, you might hit

Error: UPGRADE FAILED: cannot patch "engineimages.longhorn.io" with kind CustomResourceDefinition: CustomResourceDefinition.apiextensions.k8s.io "engineimages.longhorn.io" is invalid: spec.conversion.strategy: Invalid value: "Webhook": must be None if spec.preserveUnknownFields is true && cannot patch "nodes.longhorn.io" with kind CustomResourceDefinition: CustomResourceDefinition.apiextensions.k8s.io "nodes.longhorn.io" is invalid: spec.conversion.strategy: Invalid value: "Webhook": must be None if spec.preserveUnknownFields is true && cannot patch "volumes.longhorn.io" with kind CustomResourceDefinition: CustomResourceDefinition.apiextensions.k8s.io "volumes.longhorn.io" is invalid: spec.conversion.strategy: Invalid value: "Webhook": must be None if spec.preserveUnknownFields is true

Workaround: https://github.com/longhorn/longhorn/issues/4340#issuecomment-1201287027

After upgrade to v1.3.x, upgrade the volume's engine. The issue will be hit while upgrading the engine.

Expected behavior
Can upgrade engine successfully
Log or Support bundle
If applicable, add the Longhorn managers' log or support bundle when the issue happens.
You can generate a Support Bundle using the link at the footer of the Longhorn UI.
Environment

Longhorn version:
Installation method (e.g. Rancher Catalog App/Helm/Kubectl):
Kubernetes distro (e.g. RKE/K3s/EKS/OpenShift) and version:

Number of management node in the cluster:
Number of worker node in the cluster:

Node config

OS type and version:
CPU per node:
Memory per node:
Disk type(e.g. SSD/NVMe):
Network bandwidth between the nodes:

Underlying Infrastructure (e.g. on AWS/GCE, EKS/GKE, VMWare/KVM, Baremetal):
Number of Longhorn volumes in the cluster:

Additional context
https://github.com/longhorn/longhorn/issues/4387
Workaround
Set volume.spec.dataLocality from "" to disabled manually

Verified on longhorn manager master-head d7d200
Result pass
Test steps

Can reproduced on v1.3.1
Volume engine image can upgrade to master-head when volume was created in v1.0.0 and longhorn was upgraded from v1.0.0 -> v1.2.x(upgrade engine) -> master-head


Rename everything from PushJet to PushFish

Readme should also be updated

Can I work on this?

Thanks to @nish-d in https://github.com/PushFish/pushfish-android/pull/8 we can call this completed.

It's worth note, the current application uses io.pushfish.api when the organization domain is push.fish... We will likely have the api.push.fish subdomain and need to change the pkg to fit fish.push.api to fit naming convention

@jsonvillanueva good to note, I imagine that we shouldn't have that hardcoded for any reason anyways.  May be a good GitLab issue to post @jsonvillanueva

This is not done yet, there's still a lot of pushjet mentions:
https://github.com/PushFish/pushfish-android/search?q=pushjet&unscoped_q=pushjet
Also it should point to api.push.fish as default.
@Leopere can you reopen this, I cant for some reason...


Add config option to prevent multi account users

Allow staying compatible with old user management.

Coverage increased (+0.01%) to 99.147% when pulling b347ae354d92de260826d60fcfcbd91eb7855085 on tf:allow-multiaccount-users-explicitly-3 into 2ef9fd97072de89d6a349ebf052b66da4a67ae11 on codevise:master.


⚠ Bofrost.at has degraded performance

In 17cef01, Bofrost.at (https://www.bofrost.at) experienced degraded performance:

HTTP code: 200
Response time: 972 ms

Resolved: Bofrost.at performance has improved in 6e04343 after 6 minutes.


make test-e2e leaves behind garbage directories.

We are leaking some e2e directories. Let's find why we are not cleaning them.
For now, as a workaround, we added gitignore entry. (https://github.com/thanos-io/thanos/pull/2552)
This only fixes the outcome, not the root cause.

When we call s.Close() on a scenario, we clean the garbage directories(ideally this should happen).
But the problem here is with the ownership of files inside these garbage directories.

As seen above, all the files under  e2e_integration_test206010889/data/prometheus/ha1/ directory are with ownership root:root where as the directory e2e_integration_test206010889/data/prometheus/ha1  is user:user.
ha1 is the --tsdb.path argument passed to  sidecar service which  is started inside docker.
I think the issue is that the user is set to root here and here(default user is also root). This is the reason why directories are created with root:root permission.
May be we can set --user $(id -u) to fix this?

Let's try this why not. This might mean a contribution to Cortex e2e framework

I tried this: receiver.SetUser(strconv.Itoa(os.Getuid())) and likewise for other services. I came across an issue with this approach while running e2e tests. relevant log line below:
receive-1: level=info name=receive-1 ts=2020-05-14T14:58:24.81110881Z caller=http.go:81 component=receive service=http/server component=receive
msg="internal server shutdown" err="serve HTTP and metrics: listen tcp :80: bind: permission denied"

receiver tries to bind to port 80. But as ports below 1024 can be opened only by root and I set user as non-root, it causes out error.

do we need http service on port 80 or is it configurable?

Fixed by https://github.com/thanos-io/thanos/pull/2755


Unexpected types in type error in case expression

Running the code
strangeError : List Float -> List Float -> Maybe Float
strangeError xs ys = case (xs, ys) of
  ([], _) -> Nothing
  ((x::xs), ys) ->
    case strangeError x ys of
      Just match -> Just match
      Nothing -> strangeError xs ys

gives the error message
The 1st argument to function `strangeError` is causing a mismatch.

7│                  strangeError xs ys
                                 ^^
Function `strangeError` is expecting the 1st argument to be:

    List Float

But it is:

    List (List Float)

The error is due to the incorrect call strangeError x ys with a Float and a List Float instead of two List Floats.
I expect an error like
The 1st argument to function `strangeError` is causing a mismatch.

5│                  strangeError x ys
                                 ^
Function `strangeError` is expecting the 1st argument to be:

    List Float

But it is:

    Float

It seems like the compiler is assuming that the arguments in the call strangeError x ys are correct, which leads it to think that xs is of type List (List Float). This surprises me, since it knows the matched xs in the case expression is of type List Float, so it should know that the shadowing xs in the matching expression is also of type List Float.
Let me know if you need anything else from me.

I think I just ran into the same issue.
Made up example to illustrate:
test : { foo : List String } -> List String
test model =
  let
    l = floor model.foo
   in
   List.reverse model.foo

leads to:
TYPE MISMATCH
The argument to function `reverse` is causing a mismatch.

7|    List.reverse model.foo
Function `reverse` is expecting the argument to be:

    List a

But it is:

    Float

I'd expect that the compiler infers the type of model.foo from the type declaration and tell me that I can not pass a List String to floor.

Ouch, this second example is really frustrating. I'm not sure whether this issue should be here or in the https://github.com/elm-lang/error-message-catalog repository. Because I'm not sure this is a compiler error per se.
@evancz, what do you think?

I originally filed it here because it seemed that typechecking was throwing away type information when trying to unify.

@jvoigtlaender It look to me this could be reported there already as https://github.com/elm-lang/error-message-catalog/issues/71

Right. I hadn't made the connection, though I had seen that other issue. But yes, it might be the same thing.
But I must say the concrete problematic example shown here is the most hurting one. It almost defeats what the 0.16 announcement post says about the helpfulness of "expected vs. actual" type hints. The example can even be brought down to a more minimal one:
test : List String -> List String
test list =
  let
    l = floor list
  in
    List.reverse list

I'll add that over there.

Definitely for the error message catalog. Type inference checks the body of a definition before trying to unify it with a type annotation. There is definitely an issue on the error message catalog about this already.


[BUG] Auto discover not working for EVM chains

Describe the bug
Auto discover not working properly on EVM chains
["jsonrpc": "2.0", "id": 1, "method": "alchemy_getTokenBalances", "params": ["0x65854a137c02FC9afEB7f6D570064446925B3546"]]
The operation couldn’t be completed. (VultisigApp.RpcServiceError error 0.)
Error fetching tokens: rpcError(code: -1, message: "Invalid JSON for alchemy_getTokenBalances")

To Reproduce
Steps to reproduce the behavior:

REmove chain
add chain
See error

Expected behavior
Able to fetch token balances automatically
System:

Version main branch

I believe this might related to the network , I just tested it locally , it works fine

@johnnyluo I switched networks but its the same.
For ETH works well, nor EVM not at all...

yup, I am a bit confused , you mean ETH works , and other EVM doesn't ?


Stuck on loading when trying to make a new world

tried this on Quest 2 via Air Link

Will look into

Closing it because I restarted from the begging on this project.


Add the "Codal.ir".

Thanks, but I was able to access this website with a non-Iranian IP. Can you check again?

It's true, the website itself is accessible via foreign IP, the data though is not.
To be more precise the main functionality of the website is announcing specific news about market stocks as you can see in the image below.

This is the data that is not accessible with a non-Iranian IP as shown in the image below.

Thanks, but I was able to access this website with a non-Iranian IP. Can you check again?

Thank you so much. I apologize for the delay in merging.


Discord RPC

Describe your suggested feature
Discord Rich Presence for reading manga, navigating the app, etc
Other details
not really a useful feature but rather a cool one, just recently discorvered that Kuukiyomi has it, it's an aniyomi fork but I think it's pretty possible since it still uses Tachiyomi/Mihon as the base
Acknowledgements

[X] I have searched the existing issues and this is a new ticket, NOT a duplicate or related to another open issue.
[X] I have written a short but informative title.
[X] If this is an request for a feature in the original Tachiyomi, I am opening because multiple versions of Yōkai have been released without this feature.
[X] If this is an issue with an extension, or a request for an extension, I should be contacting the extensions repository's maintainer/support for help.
[X] I have updated the app to version <IP_ADDRESS>.
[X] I have checked through the app settings for my feature.
[ ] I have admitted that I am a clown by having checked this box, as I have not read these acknowledgements.
[X] I will fill out all of the requested information in this form.

Unfortunately Discord mobile doesn't support RPC. What that fork did is self-bot, which is against Discord TOS.
Unless Discord finally added RPC support for mobile (knowing Discord and Android, probably never), I won't be adding that feature.


adds rake task to index hathi-csv file #679

closes #679

I triggered on bibdata-staging a indexing a hathi file with 10000 lines. the documents will be less because there are some duplicates. https://catalog-staging.princeton.edu/

Coverage remained the same at 79.811% when pulling d9852930270df72ec45efff568b8d5682711c1f6 on rake-task-index-hathi-csv into e10e6d9a7b226e7393e38b3110771160b3a48958 on i664-index-hathi.


.github/workflows: keep the test container when test fails

Signed-off-by: Shirong Hao<EMAIL_ADDRESS>

@haosanzi associated with https://github.com/alibaba/inclavare-containers/issues/429？


Research webhook support for Github status support

So you can see a link to a Precog view from inside a Github PR.

Did some experimenting on this. It’s going to require an addition to the config with a mapping from repository to Github token and shared secret. The shared secret goes into the Github webhook configuration to prevent drive-by calls, and the token will be used to authenticate calls back to the status API. We can’t use the token of an OAuth’ed user because it’s unavailable to the webhook HTTP request.
The message back to the status API will be a simple “success!” with URL for that specific commit preview in Precog.


Extract Data does not export Loan or Liability account transactions

When I run the Extract Account register transactions function...

...wide open, with no filters...

...none of the transactions associated with Loan or Liability accounts are exported--only Asset, Bank, and Credit card

This is on MacOS...

Running this version of MD...

And this version of Extract Data...

I’ll take a look.
Regards Stuart
On 3 Apr 2022, at 20:07, Michael Thompson @.***> wrote:

When I run the Extract Account register transactions function...
...wide open, with no filters...
...none of the transactions associated with Loan or Liability accounts are exported--only Asset, Bank, and Credit card
This is on MacOS...
Running this version of MD...
And this version of Extract Data...
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.

You’re right. The code says:
if not (acct.getAccountType() == Account.AccountType.BANK
or acct.getAccountType() == Account.AccountType.CREDIT_CARD
or acct.getAccountType() == Account.AccountType.ASSET):
return False
On 3 Apr 2022, at 20:07, Michael Thompson @.***> wrote:

When I run the Extract Account register transactions function...
...wide open, with no filters...
...none of the transactions associated with Loan or Liability accounts are exported--only Asset, Bank, and Credit card
This is on MacOS...
Running this version of MD...
And this version of Extract Data...
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.

OK, I have now included LIABILITY & LOAN accounts. Latest uploaded here:
https://github.com/yogi1967/MoneydancePythonScripts/raw/master/extract_data.zip
Can you take a look and confirm? Thanks

That works!  Thanks for the quick turnaround.  I have another enhancement that I will post under a different thread.


[mesheryctl] Correction - Issue with mesheryctl update script version matching

This PR fixes #2542

[x] Yes, I signed my commits.

Problem
version matching fails as the latest contains v as a prefix in version thus matching always fails.
A new release of mesheryctl is available: 0.5.0-rc-5 → v0.5.0-rc-5
https://github.com/layer5io/meshery/releases/tag/v0.5.0-rc-5
Check https://docs.meshery.io/guides/upgrade#upgrading-meshery-cli for instructions on how to update mesheryctl ```

Solution
Reformat the version with adding "v" as a prefix and then compare both latest and version

@leecalcote @ramrodo review please :star_struck:!

@piyushsingariya Is this the fix mentioned in this PR made by @aneeshnema
// @leecalcote

@navendu-pottekkat Yeah, I think multiple issues were opened for the same problem, and seems like it is already resolved. I should close this one.


Memory leak in SubscribeTo

Hey!
I noticed that my server memory grows linearly:

then created two snapshots of the heap and visualized their difference:

And think that the problem in the code(in the SubscribeTo method):
 ctx = context.WithValue(ctx, extensions.ContextKeyIsBrokerMessage, acknowledgeableBrokerMessage.String())

First of all, why do you serialize full message? The message could be 8 mb and it seems that if we do not a debug, we don't need it.
And second point, that I don't understand why the sub context has not finished, also there are no deadlines for it. I thought may be problem in my code that it holds the context, but as you can see the problem also in a ping handler(the server gets about 3000 ping every minute), it almost empty without logic

Hello @nuttert ! Thanks for taking time to fill in an issue :)
Arf, the serialization was intended for debug purposes if someone wanted to log the message content.
I was expecting the context to just be garbage collected after the call.
I'll add a deadline to it. Thanks for pointing this !
Feel free to give more info if you stumble on anything else !


Universidad Autonoma de San Luis Potosi added

Official website: https://www.uaslp.mx/
IT career: https://www.ingenieria.uaslp.mx/CienciasComputacion/Paginas/Oferta-Academica/4456#gsc.tab=0

@vdcastillo Please provide us with a proof, which shows that the school recognizes the domain you are submitting as an official email domain for the students.
You can provide us with any of the following as the proof:

A copy of instruction (a hard-copy or electronic one) given to you by the school that tells you to use an email address in this email domain
An URL of a page at the official school website that says that students use this email domain
A reference to a recognized journal where an article was published by someone from the school, with explicit affiliation to the school, and e-mail address from the email domain
A WHOIS data that link the email domain to the school somehow
A copy of official letter from the school representative saying that the school provides e-mail addresses in this domain to the students
Anything else that can prove this fact in similar way, i.e. can be verified independently.

Hi,
The official site for students is: https://estudiantes.uaslp.mx/
There you can find the instructions about the subdomain for email addresses.
Hope this can help you.

Hi @philipto
Yes I do, please add alumnos.uaslp.edu.mx and then I'll do a second request for alumnos.uaslp.mx.

@vdcastillo Thank you for the clarification. Regrettably, I see no proof for alumnos.uaslp.edu.mx to be an officially recognized by the university.
Please provide us with a proof, which shows that the school recognizes the domain you are submitting as an official email domain for the students.
You can provide us with any of the following:

A copy of instruction (a hard-copy or electronic one) given to you by the school that tells you to use an email address in this email domain
An URL of a page at the official school website that says that students use this email domain
A reference to a recognized journal where an article was published by someone from the school, with explicit affiliation to the school, and e-mail address from the email domain
A WHOIS data that link the email domain to the school somehow
A copy of official letter from the school representative saying that the school provides e-mail addresses in this domain to the students
Anything else that can prove this fact in similar way, i.e. can be verified independently.

@philipto
here is the whois
https://www.whois.com/whois/uaslp.edu.mx

@vdcastillo  Thank you for the clarifications and your patience while waiting for a review and processing your request. Pull request merged.


Fix failing Python Requirements Upgrade jobs in multiple repos

Description

Latest versions of pip-tools>=6.13.0 needs pip>23.1 to successfully run the make upgrade job.
Conflicting versions are causing the Python Requirements Upgrade jobs to fail in multiple repos.

TODO

[ ] Create a list of all the repos (under arch-bom or arbi-bom ownership) where the upgrade build is failing.
[ ] Create fix PRs in all the repos to fix the failing job.

Steps to fix

Manually update the pip-tools package version in the pip-tools.txt file to pip-tools==6.13.0
Run make upgrade command to update all requirement files.
Create PR in the repo and merge after getting one approval from @edx/arbi-bom.

Possible Tip

See if we can run a bulk job on all repos to fix the failure at once using the bulk repo update workflow.

Following repos do not have pip.txt files updated in them when script was run through the bulk repo update job.
We'll need to update following repos manually:
xblock-sql-grader
repo-tools
pytest-warnings-report
edx-django-utils

Updated all the failing repos and merged the PRs to fix the failure.


fix: "Convert named imports to namespace import" adds redundant underscore suffix

Fixes #44267

Thanks for your contribution. I investigated the related issue and came up with a fix PR that I think addresses with more special cases (#45019), so I will close this PR now, but we appreciate your contribution.


dlib Enum Naming Conflicts in CBLAS when using caffe

Hi,
I am trying to use caffe and dlib together at the same time. However, whenever I wish to compile using the example "cmake" style. I came to this enum error in the matrix_lu and also several other places.
In file included from /home/yxing1/proj/dlib/dlib/../dlib/svm/../matrix/matrix_lu.h:11:0,
from /home/yxing1/proj/dlib/dlib/../dlib/svm/../matrix/matrix_la.h:13,
from /home/yxing1/proj/dlib/dlib/../dlib/svm/../matrix.h:11,
from /home/yxing1/proj/dlib/dlib/../dlib/svm/ranking_tools.h:9,
from /home/yxing1/proj/dlib/dlib/../dlib/svm/svm_rank_trainer.h:8,
from /home/yxing1/proj/dlib/dlib/../dlib/svm.h:11,
from /home/yxing1/proj/GOTURN_MDNet/src/helper/bounding_box_regressor.h:6,
from /home/yxing1/proj/GOTURN_MDNet/src/tracker/tracker_gmd.h:13,
from /home/yxing1/proj/GOTURN_MDNet/src/tracker/tracker_gmd.cpp:1:
/home/yxing1/proj/dlib/dlib/../dlib/svm/../matrix/matrix_trsm.h:153:24: error: using typedef-name ‘CBLAS_ORDER’ after ‘enum’
             const enum CBLAS_ORDER Order,                         ^
In file included from /home/yxing1/install/caffe-fast-rcnn/include/caffe/util/mkl_alternate.hpp:11:0,
from /home/yxing1/install/caffe-fast-rcnn/include/caffe/util/math_functions.hpp:11,
from /home/yxing1/install/caffe-fast-rcnn/include/caffe/filler.hpp:13,
from /home/yxing1/install/caffe-fast-rcnn/include/caffe/caffe.hpp:9,
from /home/yxing1/proj/GOTURN_MDNet/src/network/regressor.h:4,
from /home/yxing1/proj/GOTURN_MDNet/src/tracker/tracker.h:10,
from /home/yxing1/proj/GOTURN_MDNet/src/tracker/tracker_gmd.h:4,
from /home/yxing1/proj/GOTURN_MDNet/src/tracker/tracker_gmd.cpp:1:
/usr/include/cblas.h:25:22: note: ‘CBLAS_ORDER’ has a previous declaration here
 typedef CBLAS_LAYOUT CBLAS_ORDER; /* this for backward compatibility with CBLAS_ORDER */                       ^
In file included from /home/yxing1/proj/dlib/dlib/../dlib/svm/../matrix/matrix_lu.h:11:0,
from /home/yxing1/proj/dlib/dlib/../dlib/svm/../matrix/matrix_la.h:13,
from /home/yxing1/proj/dlib/dlib/../dlib/svm/../matrix.h:11,
from /home/yxing1/proj/dlib/dlib/../dlib/svm/ranking_tools.h:9,
from /home/yxing1/proj/dlib/dlib/../dlib/svm/svm_rank_trainer.h:8,
from /home/yxing1/proj/dlib/dlib/../dlib/svm.h:11,
from /home/yxing1/proj/GOTURN_MDNet/src/helper/bounding_box_regressor.h:6,
from /home/yxing1/proj/GOTURN_MDNet/src/tracker/tracker_gmd.h:13,
from /home/yxing1/proj/GOTURN_MDNet/src/tracker/tracker_gmd.cpp:1:
/home/yxing1/proj/dlib/dlib/../dlib/svm/../matrix/matrix_trsm.h:154:18: error: using typedef-name ‘CBLAS_SIDE’ after ‘enum’
             enum CBLAS_SIDE Side,                   ^
In file included from /home/yxing1/install/caffe-fast-rcnn/include/caffe/util/mkl_alternate.hpp:11:0,
from /home/yxing1/install/caffe-fast-rcnn/include/caffe/util/math_functions.hpp:11,
from /home/yxing1/install/caffe-fast-rcnn/include/caffe/filler.hpp:13,
from /home/yxing1/install/caffe-fast-rcnn/include/caffe/caffe.hpp:9,
from /home/yxing1/proj/GOTURN_MDNet/src/network/regressor.h:4,
from /home/yxing1/proj/GOTURN_MDNet/src/tracker/tracker.h:10,
from /home/yxing1/proj/GOTURN_MDNet/src/tracker/tracker_gmd.h:4,
from /home/yxing1/proj/GOTURN_MDNet/src/tracker/tracker_gmd.cpp:1:
/usr/include/cblas.h:23:46: note: ‘CBLAS_SIDE’ has a previous declaration here
 typedef enum {CblasLeft=141, CblasRight=142} CBLAS_SIDE;
May I know what exactly is causing this problem? I am able to build the given examples in dlib though.
And how do I resolve this, should I go ahead and change all the source files that have this enum issue?
Thanks!

Well, there should be a nice permanent solution.  Maybe it's just to take the word enum out from the dlib header files so it doesn't complain about this inconsistent cblas API coming in here and causing this conflict.  I don't get this error on any of my systems so it's hard for me to test it.

Thanks! That works! May I know what is the use of explicitly declare enum before those variables? As I believe the types of CBLAS_SIDE etc. are defined internally in dlib.

That's just how the syntax for enum usage is in C.  I don't really think this should be a compiler error, but maybe C++ allows this to be parsed as ambiguous, I'm not sure.  In any case, can you submit the change you made as a pull request? :)

I see. Sure!