Dynamickademlia

Main goal of this PR is having Kademlia check against dynamic Bee cluster.
Also, several other features had to be developed before this kind of check was possible.
Therefore, new things introduced in this PR are listed bellow:

Kadmelia check is rewritten to support dynamic cluster
type Node is introduced in the pkg/bee to allow better code structure and management (Bee Client type is part of Node)
type NodeGroup is now collection of Nodes (not Clients anymore); also, new methods are added to support stopping/starting/adding/removing nodes from the node group (and hence from the cluster)
pkg/k8s/statefulset is improved to support stopping/starting/adding/removing nodes
multiple options are added to the start cluster and start node commands to improve usability
several functions are renamed due to code readability

There are some things in the Kadmelia check that seem redundant. Those things can be treated as legacy, and I left them in to keep support for cluster started by Helm. Changing this would require changing tests on all places in CI/CD. Once we migrate all tests to the new approach, those things can be rewritten and code will become cleaner.
NOTE: Kademlia check is failing during dynamic test. Maybe check itself needs to be updated - I am guessing that conditions are not viable anymore. But, also we might have some issue with topology inside Bee.
Anyways, please try to run test to replicate the issue, and afterwards we should discuss about updating this check and do further investigation in Bee if needed.
Command for running test is:
./dist/beekeeper check kademlia --dynamic --start-cluster -b 2 -c 15

nice work @svetomir.
I have a few general comments:

There's a lot of type translation being done, which introduces duplicates of existing types which are already scattered around beekeeper, and I'm not sure what is the reason for that
Errors annotation should be unified across the codebase. Some use %s, some %w, some %v. We should use %w everywhere
Dynamic kademlia test should be in a separate file in the kademlia folder
I would even go as far as separating it from the kademlia command too, just in the same way that the different checks for pinning are done in different commands. It would make the code in the command folder more readable
I would personally abstract the actual handling of kademlia.Actions to something like scenario.Step, which is a more generalised approach in which other tests could make use of the same types and same underlying logic that actually does the whole k8s heavy lifting (i.e. start/stop/add/remove then execute a generic condition that must pass on every Step). Until we have this pulled out to a separate package, all new tests will have to either duplicate this logic or reference the kademlia package

You are right about it. Problem complexity and pkg design lead to this. If time allows us, we should discuss whether and how this should be mitigated.
I fixed all of these things I found across whole code base.
I moved it into separate file as it makes more sense now. But, as static test is just a subset of a dynamic test, once we have proper pkg for dynamic actions this will all become just one method with options.
I think we should redesign our CLI structure. This can be done at that time.
Good point. Already planned it in one of the future PRs.

nice work @svetomir.
I have a few general comments:

There's a lot of type translation being done, which introduces duplicates of existing types which are already scattered around beekeeper, and I'm not sure what is the reason for that
Errors annotation should be unified across the codebase. Some use %s, some %w, some %v. We should use %w everywhere
Dynamic kademlia test should be in a separate file in the kademlia folder
I would even go as far as separating it from the kademlia command too, just in the same way that the different checks for pinning are done in different commands. It would make the code in the command folder more readable
I would personally abstract the actual handling of kademlia.Actions to something like scenario.Step, which is a more generalised approach in which other tests could make use of the same types and same underlying logic that actually does the whole k8s heavy lifting (i.e. start/stop/add/remove then execute a generic condition that must pass on every Step). Until we have this pulled out to a separate package, all new tests will have to either duplicate this logic or reference the kademlia package

You are right about it. Problem complexity and pkg design lead to this. If time allows us, we should discuss whether and how this should be mitigated.
I fixed all of these things I found across whole code base.
I moved it into separate file as it makes more sense now. But, as static test is just a subset of a dynamic test, once we have proper pkg for dynamic actions this will all become just one method with options.
I think we should redesign our CLI structure. This can be done at that time.
Good point. Already planned it in one of the future PRs.

@acud @janos Thank you both for detailed reviews, they were very helpful.
I pushed changes that are in correlation with your reviews. Please check my commits and answers.
I also made a TODO list for future PRs which we'll discuss in the next meeting about Beekeeper.

@acud @janos Thank you both for detailed reviews, they were very helpful.
I pushed changes that are in correlation with your reviews. Please check my commits and answers.
I also made a TODO list for future PRs which we'll discuss in the next meeting about Beekeeper.


Command "gauge init ts" returns 404

Log output:
gauge init ts
Initializing template from https://github.com/getgauge/template-ts/releases/latest/download/ts.zip
Error ----------------------------------

[Gauge]
Failed to initialize project. Error downloading file: https://github.com/getgauge/template-ts/releases/latest/download/ts.zip.
404 Not Found. Please use a valid Gauge template URI or check network connection

Get Support ----------------------------
        Docs:          https://docs.gauge.org
        Bugs:          https://github.com/getgauge/gauge/issues
        Chat:          https://github.com/getgauge/gauge/discussions

Your Environment Information -----------
        linux, 1.5.1, bdc0f73
        js (2.4.0), ts (0.1.0)

Hi, I encountered the same problem as you. My observation is that something went wrong during the build and file ts.zip is missing in latest template version. I manually downloaded ts.zip from the previous version (0.0.8) and initialised the project from the .zip file. As I see now you can provide URL address of template .zip file so you can skip file download and point gauge to the correct .zip file from the previous release.

@Ionicson @uniconstructor The release has been fixed and gauge init ts should work now.


[Templating] Adaptive card templating is not working for Boolean fields like wrap, isVisible, Same happening with .net core SDK

Adaptive card templating for boolean fields like wrap, IsVisible is not working.

In Dotnet core, boolean value(false) is replacing with False and JSON parsing is failing because of that.

Great find - thank you! We'll look into this

@SubbaReddi
Can you post your template and data?
So I can repro?

Facing the same issue. Any update on the fix here please?
Sample template:
{
"type": "AdaptiveCard",
"body": [
{
"type": "TextBlock",
"size": "Medium",
"text": "Title is ${title != ''}"
}
],
"$schema": "http://adaptivecards.io/schemas/adaptive-card.json",
"version": "1.5"
}
Sample Data:
"title": ""
Output is coming as "Title is False" instead of "Title is false"

This has been broken for a while now, downgrading to 1.2.1 of AdaptiveCards.Templating seems to fix the problem.  Is there any idea of when this will be fixed so we can stay up to date with the newest features?


9.3 Unable to resolve service for type 'Microsoft.Extensions.Options.IOptions'

I am trying to run this demo on Sitecore 9.3. Made the appropriate changes following the instructions and get this error. (Log attached)
Unable to resolve service for type 'Microsoft.Extensions.Options.IOptions`1[ProcessingEngineDemo.Common.SpotifyMusicRecommenderOptions]
xconnect-log-RPATWARI-PK-Processing-20200426.txt

There's a bit of a mismatch between the configuration of the console app and the Cortex processing engine which I started to try and fix, but got distracted. Update the constructor of the SpotifyMusicRecommender to accept an IConfiguration and do the options binding in there. Here's an example:
    public SpotifyMusicRecommender(IConfiguration configuration)
    {
        if (configuration == null)
            throw new ArgumentNullException(nameof(configuration));

        var options = new SpotifyMusicRecommenderOptions();
        var configSection = configuration.GetSection("spotify");
        configSection.Bind(options);

        _options = options;
    }

This however will break the console app. But if you don't want to test the spotify recommender from the console, that's probably fine.

Thanks! Will give it a try.


Update SQL Injection vulnerability list item in README file

Change "SQLi Injection" to "SQL Injection" in the README.md file, because having both the "i" and "Injection" is redundant.

I will have to close this as for a change of a single character you have made more changes to the readme.md file. Will update the typo during the next commit.
Thank you for pointing it out.


bump active resource version

bump allowed Active Resource version to the latest version activeresource (6.1.0)

would be nice if this could be merged.  not seeing any changes from 6.0 to 6.1 that would break this.

Thanks @Fivell !


lint: Enable check for replace in go.mod

Use the linter to make sure go.mod doesn't include a replace directive.

Please ignore Tests / edge-ami-9 and Tests / edge-ami-cs9. They needs PR https://github.com/osbuild/osbuild-composer/pull/3542.


attempt to gracefully stop a node results in an infinite hang

to reproduce: start a few parallel load tasks (tpch). try to finish one of the database nodes.
Current KQP shutdown state: spent 0 seconds, not started yet
2024-11-06T06:05:09.482383Z :TENANT_POOL NOTICE: Forward drain node to local.
2024-11-06T06:05:09.482414Z :LOCAL NOTICE: Forward drain node to local, hive id:<PHONE_NUMBER>7968897
2024-11-06T06:05:09.482423Z :LOCAL NOTICE: Send drain node to hive:<PHONE_NUMBER>7968897. Online tablets: 0
2024-11-06T06:05:09.489927Z :LOCAL NOTICE: Drain node result received. Online tablets: 0
^[[ACurrent KQP shutdown state: spent 3.002927 seconds, not started yet
Current KQP shutdown state: spent 6.005855 seconds, not started yet
Current KQP shutdown state: spent 9.008864 seconds, not started yet
Current KQP shutdown state: spent 12.011981 seconds, not started yet
2024-11-06T06:05:24.482586Z :LOCAL NOTICE: Drain node result received: timeout. Online tablets: 0
Current KQP shutdown state: spent 15.014917 seconds, not started yet
Current KQP shutdown state: spent 18.017859 seconds, not started yet
Current KQP shutdown state: spent 21.02111 seconds, not started yet
Current KQP shutdown state: spent 24.024046 seconds, not started yet
Current KQP shutdown state: spent 27.027211 seconds, not started yet
Failed to gracefully shutdown KQP after 30 seconds: spent 30.030259 seconds, 0 sessions to shutdown left
Drain completed.
2024-11-06T06:05:39.519722Z :BS_NODE ERROR: {NW42@node_warden_pipe.cpp:55} Handle(TEvTabletPipe::TEvClientDestroyed) ClientId# [50016:7432291146339591378:16] ServerId# [7:7432291146843470689:1572] TabletId#<PHONE_NUMBER>7932033 PipeClientId# [50016:7432291146339591378:16]
GRpc shutdown warning: left infly: 7, spent: 3.025221 sec
GRpc shutdown warning: left infly: 7, spent: 6.054668 sec
GRpc shutdown warning: left infly: 7, spent: 9.083688 sec
GRpc shutdown warning: left infly: 7, spent: 12.10871 sec
GRpc shutdown warning: left infly: 7, spent: 15.136049 sec
GRpc shutdown warning: left infly: 7, spent: 18.16558 sec
GRpc shutdown warning: left infly: 7, spent: 21.191074 sec
GRpc shutdown warning: left infly: 7, spent: 24.216498 sec
GRpc shutdown warning: left infly: 7, spent: 27.246033 sec
GRpc shutdown warning: failed to shutdown all connections, left infly: 7, spent: 30.005969 sec
^[[1;5A^C^C^C^C^C^C^C^C
^C^C^C^C^C

0x00007ffff7f94cd7 in __pthread_clockjoin_ex () from /lib/x86_64-linux-gnu/libpthread.so.0
(gdb) bt
#0  0x00007ffff7f94cd7 in __pthread_clockjoin_ex () from /lib/x86_64-linux-gnu/libpthread.so.0
#1  0x000000000e25d43e in (anonymous namespace)::TPosixThread::Join (this=<optimized out>) at /home/xenoxeno/work/ydb/util/system/thread.cpp:198
#2  TThread::Join (this=0x5555fd491f88) at /home/xenoxeno/work/ydb/util/system/thread.cpp:319
#3  0x000000000ee9d6ac in NActors::TBasicExecutorPool::Shutdown (this=0x5555ff792000) at /home/xenoxeno/work/ydb/ydb/library/actors/core/executor_pool_basic.cpp:500
#4  0x000000000ee929b1 in NActors::TCpuManager::Shutdown (this=0x5555fe36f400) at /home/xenoxeno/work/ydb/ydb/library/actors/core/cpu_manager.cpp:97
#5  0x000000000ee903c0 in NActors::TActorSystem::Stop (this=0x5555ff8ae170) at /home/xenoxeno/work/ydb/ydb/library/actors/core/actorsystem.cpp:330
#6  0x0000000017e3b36a in NKikimr::TKikimrRunner::KikimrStop (this=0x5555ffd7cc30, graceful=<optimized out>) at /home/xenoxeno/work/ydb/ydb/core/driver_lib/run/run.cpp:1839
#7  0x000000001793056c in NKikimr::MainRun (runConfig=..., factories=...) at /home/xenoxeno/work/ydb/ydb/core/driver_lib/run/main.cpp:50
#8  0x0000000017de710c in NKikimr::NDriverClient::TClientCommandServer::Run (this=0x5555ffb85b00, config=...) at /home/xenoxeno/work/ydb/ydb/core/driver_lib/cli_utils/cli_cmds_server.cpp:51
#9  0x0000000017965ac3 in NKikimr::NDriverClient::NewClient (argc=argc@entry=16, argv=argv@entry=0x7fffffffe158, factories=...) at /home/xenoxeno/work/ydb/ydb/core/driver_lib/cli_utils/cli_cmds_root.cpp:72
#10 0x0000000017932043 in NKikimr::Main (argc=<optimized out>, argc@entry=16, argv=0x7fffffffe160, argv@entry=0x7fffffffe158, factories=...) at /home/xenoxeno/work/ydb/ydb/core/driver_lib/run/main.cpp:148
#11 0x0000000017932ffa in ParameterizedMain (argc=-474514992, argc@entry=16, argv=0x0, argv@entry=0x7fffffffe158, factories=...) at /home/xenoxeno/work/ydb/ydb/core/driver_lib/run/main.cpp:196
#12 0x000000000e1ab75b in main (argc=16, argv=0x7fffffffe158) at /home/xenoxeno/work/ydb/ydb/apps/ydbd/main.cpp:24
(gdb)

full stack
text (3).txt


Allow int types in MapClaims validations

This will allow the MapClaims validators to be used with Unix timestamps generated like time.Now().Unix(). Prior to this PR, only json.Number and float64 types were allowed.
This will allow the validation to pass when supplying int values as well.
The following types were added as allowed:

int (architecture dependent)
int64 (non-architecture dependent)

How will a MapClaims object be created that has int values?  The reason we look at json.Number and float64 is that those are the two possible types returned from the json parser.

Ok, an example :)
We have an API that was constructed with jwt-go 2.7.0. To not break any APIs, we simply made the following to be able to utilize the validators in v3.0.0 (map_claims.go) in a smart manner:
example.go
// .... package + imports skipped
type ExtJWT struct {
	// ...not complete claims set, there are more claims in real struct...
	ExpiresAt time.Time
	Extra     map[string]interface{}
}
func (e *ExtJWT) ToTest() jwt.MapClaims {
	test := make(map[string]interface{}, len(e.Extra))
	for k, v := range e.Extra {
		test[k] = v
	}

	test["exp"] = e.ExpiresAt.Unix()              // <-- This will not work, wrong type
	//test["exp"] = float64(e.ExpiresAt.Unix())   // <-- This will work, correct type

	return test
}

example_test.go
// .... package + imports skipped
func TestToTest(t *testing.T) {
	// This should be OK. It is.... Sort of...
	err := (&ExtJWT{ExpiresAt: time.Now().Add(time.Hour)}).
		ToTest().Valid()
	fmt.Println(err)
	if err != nil {
		t.Errorf("expected nil")
	}
	// This should fail! But it does not! Err == nil!
	err = (&ExtJWT{ExpiresAt: time.Now().Add(-2 * time.Hour)}).
		ToTest().Valid()
	if err == nil {
		t.Errorf("expected not nil")
	}
}

Since we have to do this to not break any internal (or external) structures, we will have the ability to test our implementations as well with wrong types.. Of course, after jwt.New -> jwt.Parse() the types will be correct, but for certain internal tests BEFORE we actually create a token (and regular testing), the validators will fail, since the values have not been marshalled yet. I know, this is a super rare condition and probably "the wrong way" of doing this, but we like being more safe than sorry ;)

In the spirit of being safe, would you add some unit tests to this?

It would help me understand your example test if there was a before and after of what the change unbreaks. What went from red to green?

Sorry for the delay.  I've been on vacation.
@johnlockwood-wf I don't understand your question about the example test.

@dgrijalva In the example @leetal posted, I want to understand what part is broken before this code change and thus what is fixed after. Maybe if he shows the output of go test before and after.

I'm sort of on the fence about it.  There's no real harm in adding extra tests, however, I expect I'll get support tickets from people who are confused by this.  The number type thing is already a source of confusion for users of this library.

I do think this change would add confusion.

Oh.  The issue is, the MapClaims types expects numbers to be either float64 or json.Number.  If you make a token by hand (vs parsing one), you can put int numbers in there and it will not validate correctly.

I don't understand the need to have the number anything but float64 or json.Number.

Adding support of some arbitrary other number types to this lib doesn't make sense.

Actually @johnlockwood-wf. It would make sense if you used the MapClaims type internally BEFORE actually sending it to the marshaller. Since by using the MapClaims reduces the need for some internal struct i many cases. An example is OAuth2/OpenID Connect implementations where you have to do lots of work on the claims BEFORE actually creating the token. Thus, this change would benefit such cases. And in reality, a type assertion should not confuse a GO developer that much. This is such a mere change that wouldn't break a thing. It would benefit cases where you actually have to work with the claims internally (thus using timestamps as Unix-time int64´s for example). That's where i'm standing. But i think that if @dgrijalva thinks this will confuse people more, we'll just have to cast all of our internal timestamps to float64. It just feels more ugly to do that, than add an extra type assertion in jwt-go.

@leetal I have been looking at the Valid method as if it is exclusively used for validating what has been unmarshalled from JSON. But, you're using it to validate a MapClaims before it has been marshalled.

@johnlockwood-wf Yes, i must use it prior to marshalling the token since that will solve lots of issues later on, especially due to the nature of OAuth2/OpenID Connect. Actually there is no need to do extra cpu-cycles just to marshal when i actually can validate the claims prior to marshalling them into the token. Perhaps i'm misusing the library, but i thought it was far more giving (in my case at least) to validate the claims prior to marshal.

My opinion on this as a user of the library is that types and their associated functions should work the same no matter how they were created. It can be very disconcerting to manually create a MapClaims object, for a variety of purposes, only to realize that it actually only fully works if it was created by parsing a JWT.
This is a byproduct of using a map[string]interface{} as a data structure. If the structure can store anything-- it does allow storing interface{} after all-- it is pretty harsh to say to users, "Actually, I didn't mean it could be anything... I really mean it depends on what the types the Json parser generates...". 🤕  As a new user to the library, I can empathize with the intent of this PR, as I have seen the same in my experience with claims in general. Users are given a very long rope with which to hang themselves.
Barring a redesign of MapClaims, I think it would be wise to embrace the dynamic nature of the type and put up guard rails for users. Certainly testability should not be disregarded as that will only make things better for users in the long run.
A data structure should be designed to maintain it's integrity, so that all preconditions for any functions  operating on this data are valid. Basically, users should not be able to create a MapClaims object that the associated functions fail to work on. At a minimum, placing some panics and explaining what went wrong would be helpful to guide users to using the library correctly.

For me, storing an int in the Claims is being retrieved as a float64
tokenString, _ := jwt.NewWithClaims(jwt.SigningMethodHS256, jwt.MapClaims{"id": 5}).SignedString(JWTSecret)

token, _ := jwt.Parse(tokenString, func(token *jwt.Token) (interface{}, error) {
	return JWTSecret, nil
})

_, ok := token.Claims.(jwt.MapClaims)["id"].(int)
if !ok {
	fmt.Println("not an int")
}

_, ok = token.Claims.(jwt.MapClaims)["id"].(float64)
if ok {
	fmt.Println("is a float64")
}

Is that solved with this PR? Or is there a way within the existing library to store and retrieve ints in the JWT without type conversion?

@everdev this is a side effect of how the standard library JSON parser works.  You can use the JSONNumber flag to use that library's number type, which is more flexible.  Alternatively, you can define a struct type for your claims and follow that path.

I would also love if this could get merged. For all the reasons mentioned above. But even more. In OIDC setting, now we have to make claims be float to pass validation done by this library, but then if we use same claims to make a JSON, sometimes those floats can be encoded in their exponential form. Which does not work well with some consumers which assume those numbers will always be represented as integers. See here for similar issue. Yes, exponential form is valid JSON number but it is still better to not do it if it is not necessary. So that outputs are more compatible.


Validate random activity peers support keysend

#113 did not include validation that destination node support keysend. We should add this in.

I'm already adding that on the rebase for #103


[#134342643]export_framework_applicant_details dos2 followup

This fixes the logic related to story https://www.pivotaltracker.com/story/show/134342643 in two main ways:

Includes failed services in the service counts
Switches the on_framework column to the more general pass_fail which can take on the values pass, fail, discretionary, pass_with_failed_services, discretionary_with_failed_services.

Other than that it's a tidyup reducing unnecessary dict copying and adding a note that this script is under-tested. I feel I should move on to other items in the backlog rather than spending days writing tests for this (case in point note the fairly major behaviour changes in this PR that only required one tiny test change).

@andrewchong might want to look at this too.

I'm parking this story/PR. I suggest we take a look at it once people are all back in the office. I think it has become confused what the respective responsibilities are for this and @TheDoubleK 's "reasons" script. I have a feeling the last 5 additions & back-and-forth changes I've been making here are to accommodate data missing from that script.

I've rebased this to bring it up to date and will merge once tests pass.


Disable this automation until we can convert it into an SDM

Currently, this functionality is duplicated (not quite as elaborately, but it's less off) via sample-sdm, so we should disable this one rather than fix it.
Target architecture: tslint-automation can be an SDM which implements an autofix goal. or be in the same SDM. I'd like to port the better error formatting (and fixing options) from here to there, and use it for all review comments.

This has beej disabled


Write a resume writing guide

What exactly are you looking for in a resume writing guide? I have some old notes I'd be happy to organize into something a bit more generally useful for you. There's this old data based article that I've personally used as reference for quite a while.
Here's a gist I've recently been sharing with some friends who ask for tips: https://gist.github.com/zenware/59999e36cac8529e6e928c7e684cf452

I don't know specifically, but a guide with fundamental stuff that everyone agrees on would be nice to have in RenderCV's docs. Feel free to submit a PR if you would like to contribute a guide to the docs.


python print() keyword not recognized when followed by parentheses

In python3, the print() function requires parenthesis. hljs should highlight the "print" keyword, regardless of whether or not it's followed by parentheses, however it does not.

The source commit that caused this for future lookup.

@yyyc514 Can we reopen this issue? I don't want to open a new issue addressing the same stuff as I do wanna ask if this is possible to enable highlighting the print keyword for Python 3.
For example, the print keyword is highlighted on VSCode

Whereas the HighlightJS library doesn't:

Cheers!

I can see the justfication for this (that is, when used as a function, it's technically no longer a keyword)

This made sense to me.  But I see it both ways.
Can we get any more Python people to weigh in here?

If isagalaev added it I'm including to keep it unless a bunch of Python people tell me otherwise.

Long-term Python people here: print is a keyword in all uses in Python 2, regardless of the presence of parentheses, UNLESS from __future__ import print_function is present at the top of that file, in which case it’s treated as function and must be followed by parentheses. For consistency though print should probably always highlight as a keyword in Python 2.
In Python 3, however, print is, definitely, NOT a keyword, and should be highlighted as per any other function. This is true of exec too, it also ceased to be a keyword. VSCode is incorrect here, and should not be highlighting print as a keyword, as the user can freely overload or shadow it like any other function.
Those are the only two keywords to be removed in the 2 to 3 transition.
Note that new keywords are also added occasionally... the values None, True and False became keywords in Python 3 — though they perform like literal values in all respects as they did previously, except no longer being considered valid, assignable identifiers (True, False = False, True used to work). The nonlocal was added to Python 3 as well. And more recently both async and await were added as of 3.7.

Thanks for the refresher. The sounds vaguely familiar.

In Python 3, however, print is, definitely, NOT a keyword, and should be highlighted as per any other function.

This makes sense to me and since we only have a SINGLE Python grammar I believe it makes sense to go with the newer Python 3 semantics, therefore NO highlighting. @KingDarBoja
If someone wanted to build and release their own Python 2 grammar it seems highlighting print as a keyword would be the correct choice, but that is not where we are here.

Thanks for the explanation, I am glad that yawpitch provided source files to look at.
Everyday I learn something and this was definitely the case, didn't know VSCode was wrong with the highlight until I saw the keyword list on Python 3.
So I do better stick with it as this is the correct behaviour after all.
Cheers!

I don't think VSCode is highlighting print as a keyword? In the code samples provided def, or, None, and class are keywords and they are highlighted in blue. print, however, is highlighted in yellow similarly to @requires_authentication and somefunc, both of which are functions but not keywords.
Personally, I would vote for highlighting print similarly to other functions. The code snippet does not show calling other functions, but I would guess the HighlightJS sample above would use blue?

HLJS generally does not highlight function dispatch, only function definition.

I don't think VSCode is highlighting print as a keyword?

Your right, it doesn't appear to me.


Fix Swinject Dependency now fixed at 2.7.1 and update test spec

This PR:

Removes the Quick/Nimble dependencies at the SPM Package Spec
Gets the Swinject version pinned to 2.7.1 instead on relying on ~> 2.7, which is currently not compatible with this branch
Generates a new LinuxMain which is compatible with XCTest

Obs: I had to keep the LinuxMain.swift because test discoverability was only introduced to Linux at Swift 5.1.

Looks great, thanks for the PR

Thanks!😃


allow removing RBD mirror from a node

Add a playbook that lets users remove RBD mirror from a node and add a test for it.

jenkins test dev-centos-non_container-shrink_rbdmirror

jenkins test dev-centos-container-shrink_mds

jenkins test dev-centos-container-shrink_rbdmirror

please, avoid using this syntax when it's not really required

Personally, I like to go with the standard: wrap text at 80. Anyways, I'll get rid if it.

please, avoid using this syntax when it's not really required

Personally, I like to go with the standard: wrap text at 80. Anyways, I'll get rid if it.

IMO, wrapping text at 80 chars was useful back in the '90s, even if there are still good reasons to wrap like this, it doesn't really apply here (ceph-ansible), by the way, I think today your screen resolution is good enough to support more than 80 chars

please, avoid using this syntax when it's not really required

Personally, I like to go with the standard: wrap text at 80. Anyways, I'll get rid if it.

IMO, wrapping text at 80 chars was useful back in the '90s, even if there are still good reasons to wrap like this, it doesn't really apply here (ceph-ansible), by the way, I think today your screen resolution is good enough to support more than 80 chars

That's true. But today, wrapping is more about reading ergonomics, AFAIK. I suppose this is why most guildlines around Python coding style and Git still recommend it.
Anyways, it's only a convention. I am OK with whatever a project prefers.

please, avoid using this syntax when it's not really required

Personally, I like to go with the standard: wrap text at 80. Anyways, I'll get rid if it.

IMO, wrapping text at 80 chars was useful back in the '90s, even if there are still good reasons to wrap like this, it doesn't really apply here (ceph-ansible), by the way, I think today your screen resolution is good enough to support more than 80 chars

That's true. But today, wrapping is more about reading ergonomics, AFAIK. I suppose this is why most guildlines around Python coding style and Git still recommend it.

Yes, this is why I said:

even if there are still good reasons to wrap like this, it doesn't really apply here (ceph-ansible)

Anyways, it's only a convention. I am OK with whatever a project prefers.

When having a really long and complex command in ceph-ansible, I agree, it's fine to wrap like this.
I think a good compromise would be to keep wrapping but only at 110/120chars, although it could be less according to the command to be wrapped (for instance, if lot of complexity).

@guits the pipeline completed running successfully.

@rishabh-d-dave IRC? :smile:

@rishabh-d-dave we are still missing something in this playbook I think, we must check if the daemon has been actually removed.

jenkins test dev-centos-container-shrink_rbdmirror

jenkins test dev-centos-container-shrink_rbdmirror

jenkins test dev-centos-container-shrink_rbdmirror

jenkins test dev-centos-container-shrink_rbdmirror

jenkins test dev-centos-container-shrink_rbdmirror

jenkins test dev-centos-container-shrink_rbdmirror

jenkins test dev-centos-container-shrink_rbdmirror

jenkins test dev-centos-container-shrink_rbdmirror

jenkins test dev-centos-non_container-shrink_rbdmirror


iOS Consume & Update ACS from Cocoapods

https://github.com/mariusu-msft/Xamarin.AzureCommunicationCalling/tree/use-cocoapods
I've added support to use ACS from Cocoapods here. It may be desirable to checking in the libs directly, since it allows for easy update to latest.
Let me know if I should create a pull request.

Nice, thank you @mariusu-msft ! Would appreciate a pull request! Ill try to get it merged as soon as possible.
P.S. I saw you referenced ios 13 in the Podfile, the minimum sdk version should be 12.0 shouldnt it?

@mariusu-msft Just tried installing from cocoa pods and it works very well! A minor detail is that Info.plist of AzureCommunicationCalling has some strange values: minimumosversion=10, should be 12, right? Also, BunleVersionShort is "1.0.0-beta.4" which doesnt fly with iTunes Connect: https://developer.apple.com/documentation/bundleresources/information_property_list/cfbundleshortversionstring

Closing this. Will send a new PR to update to 1.0.0-beta.5 fix the minOSVer

@mariusu-msft @tompi i made a last minute fix for this issue, so 1.0.0-beta.5 already has the proper short version in info.plist

Hey. No need. I already figured out the correct git shas for beta 5 for the
other libs. Should be updated now
On Thu, 19 Nov 2020 at 18:56, Marius U<EMAIL_ADDRESS>wrote:

Closing this. Will send a new PR to update to 1.0.0-beta.5 fix the minOSVer
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/Laerdal/Xamarin.AzureCommunicationCalling/issues/8#issuecomment-730540014,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AABYSJKOIKRKB6HA6ULQR3LSQVL47ANCNFSM4TX6H4SA
.

--
<EMAIL_ADDRESS>90786985

We are going to be publishing to Trunk CocoaPods in next couple of days. I’ll send a PR for that when it will be available.
Get Outlook for iOShttps://aka.ms/o0ukef

From: Thomas Haukland<EMAIL_ADDRESS>Sent: Thursday, November 19, 2020 10:15:42 AM
To: Laerdal/Xamarin.AzureCommunicationCalling<EMAIL_ADDRESS>Cc: Marius Ungureanu<EMAIL_ADDRESS>Mention<EMAIL_ADDRESS>Subject: Re: [Laerdal/Xamarin.AzureCommunicationCalling] iOS Consume & Update ACS from Cocoapods (#8)
Hey. No need. I already figured out the correct git shas for beta 5 for the
other libs. Should be updated now
On Thu, 19 Nov 2020 at 18:56, Marius U<EMAIL_ADDRESS>wrote:

Closing this. Will send a new PR to update to 1.0.0-beta.5 fix the minOSVer
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/Laerdal/Xamarin.AzureCommunicationCalling/issues/8#issuecomment-730540014,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AABYSJKOIKRKB6HA6ULQR3LSQVL47ANCNFSM4TX6H4SA
.

--
<EMAIL_ADDRESS>90786985
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FLaerdal%2FXamarin.AzureCommunicationCalling%2Fissues%2F8%23issuecomment-730550191&data=04|01|mariusu%40microsoft.com|c693d8bc47204bde9fe208d88cb720f2|72f988bf86f141af91ab2d7cd011db47|1|0|637414065482670848|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|1000&sdata=MN2E59UE144idf4p86L2mtczbOl6myjqxOWG6UCiPtM%3D&reserved=0, or unsubscribehttps://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAOATQRD45CQWCXSHZU5AG3LSQVOE5ANCNFSM4TX6H4SA&data=04|01|mariusu%40microsoft.com|c693d8bc47204bde9fe208d88cb720f2|72f988bf86f141af91ab2d7cd011db47|1|0|637414065482680839|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|1000&sdata=CGQvKxmrnEuMuGKQKX2j2zjvrhs3RpFxgBeynhAL5KI%3D&reserved=0.


foundry hud weblate

hi, is it possible to add your mods to foundry hud weblate for us to translate or update the translation faster? https://weblate.foundryvtt-hub.com/

I have previously submitted my other module Tokenizer to the project, some months ago and have had no response, so don't hold your breath.


Allow for plot_kde and plot_boxplot to plot log-odds, not probabilities

I'd actually like to get your expert opinion on this question and answer: https://stats.stackexchange.com/questions/378876/why-is-it-easier-and-just-as-valid-to-assess-overlap-with-logit-propensities/
With that in mind, should we allow users to set if they want raw probabilities or log-odds?

Generally, these plots are for diagnosing gross positivity violations. So if you look at a density plot like here, the overlap seems generally acceptable.
For an extreme violation, you can imagine the same plot as above but instead there is a bump in the blue plot around 0.7. Essentially, what this would tell me is that there is something fundamentally different about a subgroup of the treated versus the untreated. Once you identify that, you can dive into the issue. For example, maybe that subgroup was all age >50, but there were no individuals in the untreated group above age < 45. The plot is particularly useful for diagnostics in high dimensional models, since the subgroup maybe something more complicated (e.g., males, age > 50, and white were always treated).
I haven't thought too deeply about propensity vs logit plots, so these are my first thoughts. Your examples provided raise an issue more for propensity score matching (PSM), not the diagnostic necessarily. So the diagnostics purpose is to identify these positivity violations within our data (like above). Not necessarily distinguishing between 0.998 and 0.999
As I currently see it:
positivity violations - IPTW.plot_kde() IPTW.plot_boxplot()
weight behavior - IPTW.positivity()
...although maybe these labels are not ideal since the positivity() is misleading. I chose that name based on Cole Hernan 2008.
However, your example does demonstrate one of the reasons to use IPTW over PSM. PSM may match 0.500 to 0.501 and 0.998 to 0.999, despite there being substantial differences between the probablities. IPTW allows these substantial differences ot occur (much like the coin flip examples you provided).
Much of my understanding comes from Cole Hernan 2008 but they don't specifically address this issue. I will ask around

Having said all that, I don't have an issue with allowing users to specify a log-odds plot instead. I would advocate for the default to be predicted probabilities though


Easily set up new conferences

Currently setting up a conference is a pain. You have to manually populate seed files and associate tracks, audience levels and session types. Files need to be dropped into version control and mistakes cause the conference's page to break completely.
It would be much better to have a nice interface to handle that.
As of now, I've been using the following script to replicate conferences and submissions with minor changes:

confs = Conference.where('id > 1').all
conf = Conference.first
def clean_copy_of(model)
  copy = model.class.new
  model.attributes.
    reject{|k,v| ['id', 'conference_id', 'created_at', 'updated_at'].include? k}.
    each do |k,v|
      copy.send("#{k}=", v)
    end
  copy
end
confs.each do |c|
  conf.tracks.each do |t|
    copy = clean_copy_of(t)
    copy.conference_id = c.id
    copy.save
  end
  conf.audience_levels.each do |l|
    copy = clean_copy_of(l)
    copy.conference_id = c.id
    copy.save
  end
  conf.session_types.each do |t|
    copy = clean_copy_of(t)
    copy.conference_id = c.id
    copy.save
  end
end
s = Session.first
confs.map do |c|
  copy = clean_copy_of(s)
  copy.conference_id = c.id
  copy.track_id = Track.for_conference(c).where('title = ?', s.track.title).first.id
  copy.audience_level_id = AudienceLevel.for_conference(c).where('title = ?', s.audience_level.title).first.id
  copy.session_type_id = SessionType.for_conference(c).where('title = ?', s.session_type.title).first.id
  copy.duration_mins = s.duration_mins
  copy.keyword_list = s.keywords.map(&:name).join(', ')
  if copy.save
    copy
  else
    [copy, copy.errors.full_messages]
  end
end
os = Organizer.all
confs.map do |c|
  os.each do |o|
    copy = clean_copy_of(o)
    copy.conference_id = c.id
    copy.track_id = Track.for_conference(c).where('title = ?', o.track.title).first.id
    copy.save
  end
end

Lots of commits were making this doable. Starting from the oldest:
https://github.com/agile-alliance-brazil/submissions/commit/54e12cb63734a0a0797ed014d7edd2bc144814af
https://github.com/agile-alliance-brazil/submissions/commit/5ba149e98b5a3141c1f6feb51c23526bf662f26a
https://github.com/agile-alliance-brazil/submissions/commit/29955f728463da0c36bc8049b615fb8544e63928
https://github.com/agile-alliance-brazil/submissions/commit/d8dbd6ac8eb78f50699934cc9a8e18003ec95d4f
https://github.com/agile-alliance-brazil/submissions/commit/3c04b53b1bd0e8f8b19b59b168f905cb9362686a
https://github.com/agile-alliance-brazil/submissions/commit/33e18f2183a293b8aec2db3c31871053b4c0eb15
https://github.com/agile-alliance-brazil/submissions/commit/0d656d076e039a3e3990ce4f0d2e995fae99ac54
https://github.com/agile-alliance-brazil/submissions/commit/6e5fc855152a4b9b4d8e1d05a4deb5ef0368c912
https://github.com/agile-alliance-brazil/submissions/commit/cec3f7373fe17f6aafc37894ddc25ee2da7ca029
https://github.com/agile-alliance-brazil/submissions/commit/94a56e411f9b4e230c33db7390aec28ac9aadd17
https://github.com/agile-alliance-brazil/submissions/commit/6a7fb58ad97148e0ac42036ad18a26d5d629a2ea
https://github.com/agile-alliance-brazil/submissions/commit/a3dee08ca5576da4d10eaa0def6167e38cd3a1d6
https://github.com/agile-alliance-brazil/submissions/commit/5b3680a6e36baecf99c3680fd32bc96992ae654c
https://github.com/agile-alliance-brazil/submissions/commit/97ef2dddc2f882da1a688722e70b32bcd15c5e52
https://github.com/agile-alliance-brazil/submissions/commit/971f135e10387d410d437678086dd094452068ea
https://github.com/agile-alliance-brazil/submissions/commit/85fb696acec22bc4417bbba9a5d10073c7da66aa
https://github.com/agile-alliance-brazil/submissions/commit/93976347f426eba9ce8934ae30cd275159390127
https://github.com/agile-alliance-brazil/submissions/commit/22591e7180e97be2f94fe73dc417a8c6f6da4c1e
https://github.com/agile-alliance-brazil/submissions/commit/c57e0f6a5e9873df893594d7aee560c62018d37e
https://github.com/agile-alliance-brazil/submissions/commit/62df339fccd0de65862f18c445b6393bbed01bd9
https://github.com/agile-alliance-brazil/submissions/commit/a9c7cf786e31121b7026450924c3a0e16ca22e45
https://github.com/agile-alliance-brazil/submissions/commit/635252e39e6f862be65d933d116df8d7d15c6ce4
https://github.com/agile-alliance-brazil/submissions/commit/63a9ab08ff7ee9712f4dc62727c44693007d8cb2
https://github.com/agile-alliance-brazil/submissions/commit/435a514d785be4eb63fb56bade93daa9cc136a57
https://github.com/agile-alliance-brazil/submissions/commit/4a47e260f5fa04df418cd83ab4d4989c8bb66a07
https://github.com/agile-alliance-brazil/submissions/commit/047ba31e45c0a500844d7e9b8ff19d8aef576d38
https://github.com/agile-alliance-brazil/submissions/commit/e0ab5adaec686401581c97f8354d2262dc0d0308
https://github.com/agile-alliance-brazil/submissions/commit/530d7cbaed5e10a4ff137f18381aa9d48ec1d14d
https://github.com/agile-alliance-brazil/submissions/commit/ab5599b61895308fdfc8312b00c44034df332fe5
https://github.com/agile-alliance-brazil/submissions/commit/00145224023d92bbe1ef02963b6803ee09eadbf3
https://github.com/agile-alliance-brazil/submissions/commit/43abc158334300633b94f6078efc587a25e0e17a
https://github.com/agile-alliance-brazil/submissions/commit/2447c9af5cdcdd5d2b2291ea565a8f2b0dff9d48
https://github.com/agile-alliance-brazil/submissions/commit/ecab503cca71e4353b2857d376c4a0c233d67e02
https://github.com/agile-alliance-brazil/submissions/commit/fddefbe66693e4b328406955a7fbc628e28b459f
https://github.com/agile-alliance-brazil/submissions/commit/b33608ed99141044f58bd45c115927f55c0eeb97
https://github.com/agile-alliance-brazil/submissions/commit/cf4fc87122bc67610009d882ccab0c3254f2c50c
https://github.com/agile-alliance-brazil/submissions/commit/3042d663a2fe78fc930107a094d2059ecc6779cc
https://github.com/agile-alliance-brazil/submissions/commit/ef9607e43edd0868ae5e6955c8744f3b56558a79
https://github.com/agile-alliance-brazil/submissions/commit/4a574ba20d3548531e2549d8d4566a5cc2f65c36
https://github.com/agile-alliance-brazil/submissions/commit/6dbe6d425f14f9a0df09aef0ad2cd27d6da22def
https://github.com/agile-alliance-brazil/submissions/commit/daca9c01564b27e33d91c437188fab2bd80c380e
https://github.com/agile-alliance-brazil/submissions/commit/7e97c7bbc17cd3341d5b9959d592ff536677b3d6
https://github.com/agile-alliance-brazil/submissions/commit/40d4c157cdd6fca538698e133756910b15055f1c
https://github.com/agile-alliance-brazil/submissions/commit/69734bfebdeac83a70b99654f3241b52578efa0c
https://github.com/agile-alliance-brazil/submissions/commit/bb32c818c89a8f1da7dcff24226c5e63732dc8e6
https://github.com/agile-alliance-brazil/submissions/commit/80449312bdb6fc95022285d99944f820e16e43cc
https://github.com/agile-alliance-brazil/submissions/commit/8b6d6cd5a5c117127c0ca83615edc1b307a95170
https://github.com/agile-alliance-brazil/submissions/commit/460306bad520b14222cdd794c5eb3ce7bea40260
https://github.com/agile-alliance-brazil/submissions/commit/85f81b922c3809658c11031b16132de305b177c1
https://github.com/agile-alliance-brazil/submissions/commit/a64fba20592f754d05775486d0efbe646aee7bb3
https://github.com/agile-alliance-brazil/submissions/commit/8648eb96913f9e8da900b0b237391fda6b5d2498
https://github.com/agile-alliance-brazil/submissions/commit/e8610dedd57aa51cdd359b88d3ec0086c1b51915
https://github.com/agile-alliance-brazil/submissions/commit/24f481c3cb921c566ce84bb3d46736988c396171
https://github.com/agile-alliance-brazil/submissions/commit/46f407e1718476d6f59e33f6af028591895f6129
https://github.com/agile-alliance-brazil/submissions/commit/a3ab8dc495fbfcbbf22d9767f430187b6ba5110c

And I consider this now to be done. There are some more clean ups to do but feature wise, this is good enough.


Lint and correctly attribute deprecations from local config files

This is an attempt at fixing https://github.com/atom/deprecation-cop/issues/18 and also fixing how deprecations from init.coffee are attributed.

b0ccfe2 adds a check to see if a filename in the deprecation stack matches the init script, and sets the package name to "your local init.coffee file" if it does

86dcf76 adds linting for the user's local keymap and styles files, and makes deprecations from those files be attributed to "your local keymap.cson file" and "your local styles.less file"

af79721 makes selector deprecation messages render in markdown

What do you think of this direction, @kevinsawicki? I'd still need to think about adding tests for this, but just wanted to ask if this makes sense?
Before :camera: (notice that the deprecation from init.coffee is attributed to atom core, and that the selector deprecation message is not rendered in markdown):

After :camera: (notice that the init.coffee deprecation is correctly attributed, markdown rendering in selector deprecation messages, and that deprecations were found in keymap.cson and styles.less):

Thanks @kevinsawicki and @maxbrunsfeld! I pushed https://github.com/atom/deprecation-cop/compare/af79721df25d555dd74417a2747e5f3f71105c89...4abd53837937c39e850cdf025a4a7e8662b62020 to address those comments.
Also, https://github.com/atom/deprecation-cop/compare/4abd53837937c39e850cdf025a4a7e8662b62020...c0ef0c7b5df2b6692cbdddd8954a64d359ad0128 adds support for updating the status bar view and deprecation cop view when local config files change.
Question: The current approach for updating the deprecation cop view when deprecations change is that a button is shown to refresh the view. I used the same approach for updates from local config files. However, the status bar view uses a different approach -- it refreshes automatically (no user interaction needed). So, when new deprecations change -- the status bar view updates automatically, but the deprecation cop view needs a click on the "refresh" button (if it's already open). What do you think about refreshing the deprecation cop view automatically as well and removing those "refresh" buttons and the need to click them? Wondering if there's some problem with that approach which I'm missing... :thought_balloon:

What do you think about refreshing the deprecation cop view automatically as well and removing those "refresh" buttons and the need to click them?

Sounds good to me.

Wondering if there's some problem with that approach which I'm missing

Nothing I can remember.

Merging this so it goes out in the next release, thanks so much for adding it!
Travis builds seem stalled but I ran the specs locally and everything was :green_apple:
I think removing the refresh button and making the view "live" still sounds like something worth doing in a follow-up pull request.


RS Uploader: move the cron setting out of function.json and make it a configuration variable

Background
Part of the response to the 1/28-1/30 incident. During that incident, the diagnosis and fix were identified fairly quickly but it took a long time to deploy an update to the cron job. Having that cron variable be part of the configuration would enable us to make quick changes when necessary.
Proposed solution
Move the cron config to be part of the configuration file, instead of function.json.

Fixed; this is part of our CI/CD pipeline


Add delta outbound user sync

Resolves [TASK] #434

Create queue_outbound_complete changelog table in rethinkdb
Add user and group outbound filters for AAD
Add listener to queue_outbound
Add POST request header support to ./rbac/providers/azure/aad_auth.py
Add event loops to prevent crashing when the daemon comes up before rethink
Run black to format python

Signed-off-by: jbobo<EMAIL_ADDRESS>

Please Resolve Conflicts @jbobo

@nadiabahrami @kthblmfld made changes


GCVE Monitoring VM in MIG for autohealing and generalize examples

Fixes #12

It's a good idea to open an issue first for discussion.

[x] Tests pass
[x] Appropriate changes to README are included in PR

Thanks @rawanbadawi for your contribution! Confirming the points that Leandro pointed out. Otherwise, should be good to be merged once these minor points are addressed.

@KonradSchieban @leandrocarracedo I resolved the review, please check again


OmniSharp Org meeting?

Seems like it's a good time to have another meeting, it's been many months since we had the last one!
Agenda items?

OmniSharp using csi
scaffolding?
generators?
vscode plugin?
Make a recurring meeting?

perhaps once a month?
How do we best handle various time zones of all the individuals involved?

cc @OmniSharp/owners  @OmniSharp/generator-aspnet-team-push @OmniSharp/scaffolding-admins @OmniSharp/omnisharp-vim @OmniSharp/gen-csharp-dev

How do we best handle various time zones of all the individuals involved?

Publish agenda before as issue with e.g. todo checklists, so people could make statements before meeting in proper place (e.g. gists or online docs). For example I do really have a short time window to get involved in any online discussion properly - excepts of weekends.
https://github.com/blog/1825-task-lists-in-all-markdown-documents
IO.js routines: https://github.com/nodejs/node/issues/112 https://github.com/nodejs/node/issues/211
Reuse Gitter OmniSharp channel
Thanks!

I think that meeting would be great. I'm on vacation until 12/1, can we do it after that? If not I can catch the next one. For time zones its best effort. If it's recurring we can find two slots and alternate.

I am on the west coast with most of MS, so I should be fairly easy to work with -- also, I rarely sleep, so any time is mostly good for me.

What time was it last time? I think I'm the furthest away from the rest of
you guys, and the time was okay for me for the last meeting.
2015-11-21 22:44 GMT+02:00 Deavon M. McCaffery<EMAIL_ADDRESS>
I am on the west coast with most of MS, so I should be fairly easy to work
with -- also, I rarely sleep, so any time is mostly good for me.
—
Reply to this email directly or view it on GitHub
https://github.com/OmniSharp/OmniSharp/issues/1#issuecomment-158679735.

Sorry, left out the perhaps non-obvious fact that I'm UTC+2 here in Finland
right now. :)
2015-11-22 8:20 GMT+02:00 Mika Vilpas<EMAIL_ADDRESS>
What time was it last time? I think I'm the furthest away from the rest of
you guys, and the time was okay for me for the last meeting.
2015-11-21 22:44 GMT+02:00 Deavon M. McCaffery<EMAIL_ADDRESS>
I am on the west coast with most of MS, so I should be fairly easy to
work with -- also, I rarely sleep, so any time is mostly good for me.
—
Reply to this email directly or view it on GitHub
https://github.com/OmniSharp/OmniSharp/issues/1#issuecomment-158679735.

Count me in!

I'm in, EST here

The last meeting was at 11 AM PT.

+1

Sorry, I've been kind of busy the last week or so.
@peterblazejewicz I'll see if I can start working on an agenda in the next day or so.  I agree that we should have some form of notes, and history of what we've said / done.

I'm EST, but have no problem with early morning / late evening / weekends.
So we have UTC-8 (PST), UTC-5 (EST), UTC+1 (Poland), UTC+2 (Finland), I've also added Sydney to the list, because I know we have some Aussies as well, not sure if they are looking to participate or not (please do chime in if you want to!).
That leaves us a window of approximately 8 hours if we were to have a phone conversation as well as note taking.  I would prefer to include everyone we possibly can, which is why I even added in the night times for those of us in North America (I know the EST ones are rough, but I'm willing to try and do what I can).
Let me know if I'm missing something with this list.

PST (UTC-8)
EST (UTC-5)
UTC
UTC+1
UTC+2
Sydney (UTC+11)

08:00 am
11:00 am
16:00
17:00
18:00
03:00

09:00 am
12:00 pm
17:00
18:00
19:00
04:00

10:00 am
01:00 pm
18:00
19:00
20:00
05:00

11:00 am
02:00 pm
19:00
20:00
21:00
06:00

12:00 pm
03:00 pm
20:00
21:00
22:00
07:00

01:00 pm
04:00 pm
22:00
22:00
23:00
08:00

10:00 pm
01:00 am
06:00
07:00
08:00
17:00

11:00 pm
02:00 am
07:00
08:00
09:00
18:00

Sign me up too, UTC+1

I can't speak for @davidfowl (who works insane hours) but I'm always in around 07:00 PST (UTC-8).

If we want @davidfowl to join it will need to be after 10:30 AM PT.

Someone needs to build an app where everyone selects the time(s) that work for them, and the one with the most votes wins... :8ball:

We could use a google hangout, or similar, to record the meeting for others to watch later if they can't make it as well. Like the ASP.NET Community Standup -- just a thought... Not sure if anyone wants to see my ugly face, or all of the cans of red bull stacked on my desk. :sob:

If someone else runs the hangout that's fine, I haven't gotten it to work for me.

I'd be happy to host the hangout, just have to figure out how it works first.  I'm going to make some agenda items tonight, and pick 2 times from the list above and we can just vote on those.
This week is thanksgiving for these crazy Americans (everyone knows thanksgiving is in October, he says as he's living in the states).  I figure we can target sometime next week?
@peterblazejewicz mentioned weekends might be better, does anyone else have a preferred day that works out for their schedule better?

Availability: Any day of the week
Preferred Time: Anytime
Preferred Day: Wednesday

Next week works for me. I'll do my best to clear my schedule for whatever slot we pick.

Next week works better for me too

I'm in UTC +11 (Melbourne).
Based on initial discussions in the #omnisharp channel on jabbr, would something around 21:00-22:00 UTC work?

Also in UTC+11 and agree with ~21:00. Would put it early morning for Australia, Late-ish, but still reasonable for UK, and middle of the day for USA people?

That starts to kick out the times for @peterblazejewicz, @sp3ctum, @Mpdreamz, @jrieken, etc
Would these times work for everyone?

PST (UTC-8)
EST (UTC-5)
London (UTC)
Zürich (UTC+1)
Helsinki (UTC+2)
Sydney (UTC+11)

1:00 PM
4:00 PM
9:00 PM
10:00 PM
11:00 PM
8:00 AM

:+1:

:+1:
Now we just need a day.

Works for me

For day I was thinking Wednesday December 2nd @ 21:00 UTC
That's just my selfish choice, I'm open other days as well. :smile:

And of course... I  can do any day, but Dec 2 :crying_cat_face:

well for you it would be December 3rd wouldn't it?

Wednesday works for me. Normally that's the C# language design meeting, but I think we're on hiatus for a bit while @MadsTorgersen is out of town. I'll also be bringing @MattWarr and @CyrusNajmabadi along as well if that's OK. We'd love to get on the agenda to talk about the C# team's ambitions (and why @MattWarr has been prototyping stuff over on his repo).

:+1: For Thursday, December 3rd at 8am AEST (UTC+11)

I've added the first draft of the agenda in #2, time is currently tentative pending feedback from everyone else.

Either the 2nd or 3rd December at 2300 UTC+2 will work for me. Though I'd
prefer an hour earlier if it's all right with people. I realize setting a
time is pretty difficult since people are spread so widely around the globe
:)
2015-11-25 5:45 GMT+02:00 David Driscoll<EMAIL_ADDRESS>
I've added the first draft of the agenda in #2
https://github.com/OmniSharp/OmniSharp/issues/2, time is currently
tentative pending feedback from everyone else.
—
Reply to this email directly or view it on GitHub
https://github.com/OmniSharp/OmniSharp/issues/1#issuecomment-159481396.

I can make Dec 2nd at 9pm utc, doubt I will have much to say but I can chime in a bit about brackets if @mat-mcloughlin can't make it.

I have marked #2 as no longer tentative, if anyone has any more questions, or feels we need to meet a different day or time, let us know asap!

Apparently the original issue didn't cc everyone, so I've added a new cc list.
FYI incase you haven't seen this issue cc @OmniSharp/all

gonna be there!

+1

:+1:


[TCES-56][DRAFT]: Create Custom Job Type Chips

Description
This pull request is for the implementation of the job type chips component.

Linear.app Link: https://linear.app/tces/issue/TCES-56/create-custom-job-type-chips
Issue #TCES-56
Type of change
Please delete options that are not relevant.

[X] New feature (non-breaking change which adds functionality)

Checklist
Please delete options that are not applicable.

[ ] My code follows the style guidelines of this project (required)
[ ] I have performed a self-review of my code (required)
[ ] I have linted and formatted my code (required)
[ ] New and existing unit tests pass locally with my changes (required)
[ ] I have commented my code, particularly in hard-to-understand areas
[ ] I have made corresponding changes to the documentation
[ ] My changes generate no new warnings
[ ] I have added tests that prove my fix is effective or that my feature works

Hi! I'm using CodeSandBox.io to test the component and it looks like this:

Let me know if there is anything you would like me to change.
William.

I updated the component to better match the given image.

Hope that helps!
William.

This looks great so far William, thank you for your work! I just updated the linear ticket with an image with hex codes for the various colours (including the border colours) for each of the bubbles.
Would it also be possible to use the Roboto font to match the MUI components we are using? Thank you!
Let me know if you need anything else!

Hi! I updated the code to better match the Job Type Chips image that was uploaded onto the linear.app issue.


Graduate the MountHostCADirectories feature gate

/area control-plane
/kind enhancement
/priority 3
What would you like to be added:
MountHostCADirectories feature gate was introduced ~9 months ago with https://github.com/gardener/gardener/pull/2852. Its main purpose was to preserve the backwards-compatibility between Gardener and several provider extensions.
The compatibility notes on the provider extensions side are:

https://github.com/gardener/gardener-extension-provider-aws/tree/v1.25.0#compatibility
https://github.com/gardener/gardener-extension-provider-openstack/tree/v1.19.1#compatibility

provider-aws <= v1.15.0 and provider-openstack < v1.12.0 are already too old versions and they are kind of out of support.
We can now proceed with the enablement and promotion of this feature gate as the backwards-compatibility concern is no longer present because the corresponding provider-aws and provider-openstack versions are out of support.

/cc @danielfoehrKn


changes to work with winrt

winrt doesn't have a Serializable attribute and reflection calls have changed slightly.

Closed due to inactivity.


Add ReflectVisitor and ResolvedReferences

Laying the groundwork for resolving arbitrary cross resource references.

Codecov Report

Merging #443 (fa1321c) into master (eb475b7) will increase coverage by 0.03%.
The diff coverage is 67.61%.

:exclamation: Current head fa1321c differs from pull request most recent head 3505577. Consider uploading reports for the commit 3505577 to get more accurate results

@@            Coverage Diff             @@
##           master     #443      +/-   ##
==========================================
+ Coverage   62.58%   62.62%   +0.03%
==========================================
  Files         147      149       +2
  Lines       10038    10137      +99
==========================================
+ Hits         6282     6348      +66
- Misses       3198     3220      +22
- Partials      558      569      +11

Impacted Files
Coverage Δ

hack/generated/pkg/genruntime/arm_transformer.go
0.00% <ø> (ø)

hack/generated/pkg/genruntime/resolver.go
71.18% <33.33%> (-4.29%)
:arrow_down:

...ck/generated/pkg/reflecthelpers/reflect_helpers.go
55.67% <45.00%> (-3.31%)
:arrow_down:

...sources/v1alpha1api20200601/resourcegroup_types.go
43.47% <50.00%> (ø)

...ck/generated/pkg/genruntime/resolved_references.go
50.00% <50.00%> (ø)

...ck/generated/pkg/reflecthelpers/reflect_visitor.go
75.00% <75.00%> (ø)

...l/armconversion/convert_to_arm_function_builder.go
92.03% <100.00%> (+0.26%)
: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 eb475b7...3505577. Read the comment docs.


Investigation: Inconsistencies in transfer list between name and address of accounts in the context of account aliases (both Android and iOS)

Bug Description

In transfer list of a sender account with an alias, the sender is called with the name of the canonical account while the address is the alias address, even though the alias is in the address book. For the receiver address, the name is the name of the alias of the receiver account and its address.
In transfer list of a receiver account with an alias, the receiver is called with the name of the canonical account while the address is the alias address, even though the alias is in the address book. For the sender address, the name is the name of the alias of the sender account and its address.

e.g.

Simple transfer from A to alias of B:

In transfer list of A
-- from name: A
-- from address: A
-- to name: alias of B
-- to address: alias of B

In transfer list of B
-- from name: A
-- from address: A
-- to name: B
-- to address: alias of B

Simple transfer from alias of A to alias of B:

In transfer list of A
-- from name: A
-- from address: alias of A
-- to name: alias of B
-- to address: alias of B

In transfer list of B
-- from name: alias of A
-- from address: alias of A
-- to name: B
-- to address: alias of B

Steps to Reproduce

create accounts with aliases (concordium-client)
send from alias account (concordium-client)
send to alias account (after adding alias address to address book)
inspect transfer list of sender and receiver account

Expected Result
Name and address of account alias match.
Actual Result
Name and address of account alias do not match in all cases.
Versions

both ccd apps iOS 1.0.25 and Android 1.0.16

@concordium-cl, I'm quite sure this works as intended now.


Serializer to create human-friendly representation for .txt test cases

Currently there are 2 types of "serialization": the official one (if I can say that) implemented a few weeks ago use and the one that it is used to translate a test case FormulaValue result into a human readable value. The idea is to unify both result formats into a single one, provided by the official serializer.
Looking for suggestions/comments. Things that are still under consideration:

How to represent ErrorValues? Currently there are mainly 4 formats depending on the case:

Microsoft.PowerFx.Types.ErrorValue
#Error
#Error(Kind=InvalidArgument) or #Error(Kind=InvalidArgument, Div0)
Errors: Error 0-11: The function 'Boolean' has some invalid arguments.|Error 8-10: Invalid schema, expected a one-column table. (This format most probably will remain since it display useful information)

Single column table type is now serialized and displayed as Table({Value:1}, {Value:2}, ..., {Value:N})
Empty single column table is now serialized and displayed as Table()

There are still a few errors to cover.

Regarding the different types of errors that you mentioned in your description: the first three represent runtime errors, while the last one represents a compile-time error. There is no need to serialize the last one (since there is no object to serialize).

:heavy_check_mark: No Binary Compatibility issues for Microsoft.PowerFx.Connectors.dll
:heavy_check_mark: No Binary Compatibility issues for Microsoft.PowerFx.Core.dll
:heavy_check_mark: No Binary Compatibility issues for Microsoft.PowerFx.Interpreter.dll
:heavy_check_mark: No Binary Compatibility issues for Microsoft.PowerFx.LanguageServerProtocol.dll
:heavy_check_mark: No Binary Compatibility issues for Microsoft.PowerFx.Transport.Attributes.dll

:heavy_check_mark: No Binary Compatibility issues for Microsoft.PowerFx.Connectors.dll
:heavy_check_mark: No Binary Compatibility issues for Microsoft.PowerFx.Core.dll
:heavy_check_mark: No Binary Compatibility issues for Microsoft.PowerFx.Interpreter.dll
:heavy_check_mark: No Binary Compatibility issues for Microsoft.PowerFx.LanguageServerProtocol.dll
:heavy_check_mark: No Binary Compatibility issues for Microsoft.PowerFx.Transport.Attributes.dll

:heavy_check_mark: No Binary Compatibility issues for Microsoft.PowerFx.Connectors.dll
:heavy_check_mark: No Binary Compatibility issues for Microsoft.PowerFx.Core.dll
:heavy_check_mark: No Binary Compatibility issues for Microsoft.PowerFx.Interpreter.dll
:heavy_check_mark: No Binary Compatibility issues for Microsoft.PowerFx.LanguageServerProtocol.dll
:heavy_check_mark: No Binary Compatibility issues for Microsoft.PowerFx.Transport.Attributes.dll

Adding Breaking tag since this will likely require an update to the .txt in PA client.
But no product updates to PowerApps required.

:heavy_check_mark: No Binary Compatibility issues for Microsoft.PowerFx.Connectors.dll
:heavy_check_mark: No Binary Compatibility issues for Microsoft.PowerFx.Core.dll
:heavy_check_mark: No Binary Compatibility issues for Microsoft.PowerFx.Interpreter.dll
:heavy_check_mark: No Binary Compatibility issues for Microsoft.PowerFx.LanguageServerProtocol.dll
:heavy_check_mark: No Binary Compatibility issues for Microsoft.PowerFx.Transport.Attributes.dll

:heavy_check_mark: No Binary Compatibility issues for Microsoft.PowerFx.Connectors.dll
:heavy_check_mark: No Binary Compatibility issues for Microsoft.PowerFx.Core.dll
:heavy_check_mark: No Binary Compatibility issues for Microsoft.PowerFx.Interpreter.dll
:heavy_check_mark: No Binary Compatibility issues for Microsoft.PowerFx.LanguageServerProtocol.dll
:heavy_check_mark: No Binary Compatibility issues for Microsoft.PowerFx.Transport.Attributes.dll

:heavy_check_mark: No Binary Compatibility issues for Microsoft.PowerFx.Connectors.dll
:heavy_check_mark: No Binary Compatibility issues for Microsoft.PowerFx.Core.dll
:heavy_check_mark: No Binary Compatibility issues for Microsoft.PowerFx.Interpreter.dll
:heavy_check_mark: No Binary Compatibility issues for Microsoft.PowerFx.LanguageServerProtocol.dll
:heavy_check_mark: No Binary Compatibility issues for Microsoft.PowerFx.Transport.Attributes.dll

:heavy_check_mark: No Binary Compatibility issues for Microsoft.PowerFx.Connectors.dll
:heavy_check_mark: No Binary Compatibility issues for Microsoft.PowerFx.Core.dll
:heavy_check_mark: No Binary Compatibility issues for Microsoft.PowerFx.Interpreter.dll
:heavy_check_mark: No Binary Compatibility issues for Microsoft.PowerFx.LanguageServerProtocol.dll
:heavy_check_mark: No Binary Compatibility issues for Microsoft.PowerFx.Transport.Attributes.dll

:heavy_check_mark: No Binary Compatibility issues for Microsoft.PowerFx.Connectors.dll
:heavy_check_mark: No Binary Compatibility issues for Microsoft.PowerFx.Core.dll
:heavy_check_mark: No Binary Compatibility issues for Microsoft.PowerFx.Interpreter.dll
:heavy_check_mark: No Binary Compatibility issues for Microsoft.PowerFx.LanguageServerProtocol.dll
:heavy_check_mark: No Binary Compatibility issues for Microsoft.PowerFx.Transport.Attributes.dll

:heavy_check_mark: No Binary Compatibility issues for Microsoft.PowerFx.Connectors.dll
:heavy_check_mark: No Binary Compatibility issues for Microsoft.PowerFx.Core.dll
:heavy_check_mark: No Binary Compatibility issues for Microsoft.PowerFx.Interpreter.dll
:heavy_check_mark: No Binary Compatibility issues for Microsoft.PowerFx.LanguageServerProtocol.dll
:heavy_check_mark: No Binary Compatibility issues for Microsoft.PowerFx.Transport.Attributes.dll

:heavy_check_mark: No Binary Compatibility issues for Microsoft.PowerFx.Connectors.dll
:heavy_check_mark: No Binary Compatibility issues for Microsoft.PowerFx.Core.dll
:heavy_check_mark: No Binary Compatibility issues for Microsoft.PowerFx.Interpreter.dll
:heavy_check_mark: No Binary Compatibility issues for Microsoft.PowerFx.LanguageServerProtocol.dll
:heavy_check_mark: No Binary Compatibility issues for Microsoft.PowerFx.Transport.Attributes.dll

:heavy_check_mark: No Binary Compatibility issues for Microsoft.PowerFx.Connectors.dll
:heavy_check_mark: No Binary Compatibility issues for Microsoft.PowerFx.Core.dll
:heavy_check_mark: No Binary Compatibility issues for Microsoft.PowerFx.Interpreter.dll
:heavy_check_mark: No Binary Compatibility issues for Microsoft.PowerFx.LanguageServerProtocol.dll
:heavy_check_mark: No Binary Compatibility issues for Microsoft.PowerFx.Transport.Attributes.dll

:heavy_check_mark: No Binary Compatibility issues for Microsoft.PowerFx.Connectors.dll
:heavy_check_mark: No Binary Compatibility issues for Microsoft.PowerFx.Core.dll
:heavy_check_mark: No Binary Compatibility issues for Microsoft.PowerFx.Interpreter.dll
:heavy_check_mark: No Binary Compatibility issues for Microsoft.PowerFx.LanguageServerProtocol.dll
:heavy_check_mark: No Binary Compatibility issues for Microsoft.PowerFx.Transport.Attributes.dll

:heavy_check_mark: No Binary Compatibility issues for Microsoft.PowerFx.Connectors.dll
:heavy_check_mark: No Binary Compatibility issues for Microsoft.PowerFx.Core.dll
:heavy_check_mark: No Binary Compatibility issues for Microsoft.PowerFx.Interpreter.dll
:heavy_check_mark: No Binary Compatibility issues for Microsoft.PowerFx.LanguageServerProtocol.dll
:heavy_check_mark: No Binary Compatibility issues for Microsoft.PowerFx.Transport.Attributes.dll


Document Export - USX

AIM should support the export of documents in USX format. This would allow users to transfer their adapted documents to Paratext for further processing.

Is this needed for version 1.0? Would saving/export as usfm not work,
followed by conversion on the pc to any desired format? Such tools
probably already exist. Is format conversion on the mobile device truly
required for an initial release? Was it part of the documented AIM
specification?
Jonathan
--
Jonathan Marsden<EMAIL_ADDRESS>On Sat, Apr 11, 2015, at 10:15, Erik Brommers wrote:

AIM should support the export of documents in USX format. This would
allow users to transfer their adapted documents to Paratext for
further processing.

— Reply to this email directly or view it on GitHub[1].

Links:

https://github.com/adapt-it/adapt-it-mobile/issues/67

Export development work should be considered complete with this past checkin. Problems with the USX export can be dealt with via new issues.


⚠ Jenkins Plugins Artifactory has degraded performance

In b11b546, Jenkins Plugins Artifactory (https://get.jenkins.io/plugins/artifactory/) experienced degraded performance:

HTTP code: 200
Response time: 1110 ms

Resolved: Jenkins Plugins Artifactory performance has improved in 94f8095 after 12 minutes.


KAFKA-7031 : Connect API shouldn't depend on jersey

Connect API currently depends on Jersey API as a side-effect of KIP-285. It should only depend on the JAX RS API.
Committer Checklist (excluded from commit message)

[ ] Verify design and implementation
[ ] Verify test coverage and CI build status
[ ] Verify documentation (including upgrade notes)

@rhauch This should fix the issue KAFKA-7031. Please let me know your thoughts.

@ewencp can you please take a look at this.

@mageshn also, just a nit and in this case it worked out fine, but generally we prefer filing against trunk and, if things don't cherry pick cleanly, only then do we file follow ups on older branches. not critical, just a nice thing to help standardize committer workflow.

Thaks @ewencp  and sure will follow the guideline going forward.


Clean up relational operators

Clean up relational operators.  …

Convert all member operators to free functions.
Fix a bug in operator== for CommonMetadata (it wasn't checking owner)
Standardize on using std::rel_ops
Move 'friend' declarations to class private sections.

In cases where I was able to implement the operators using the existing
public API I did so, otherwise I preferred making them friends over adding
to the API.
I left PaginationIterator operators defined inline in the class because
all the verbiage necessary (forward declaration, friend declaration,
then definition) to make them friends makes it less readable IMO.

This change is

It looks like you pulled in some unnecessary commits. Can you rebase your changes?


Update quick start guide

https://deploy-preview-141--vcluster-docs-site.netlify.app/docs/get-started
Updated quick start guide to streamline it

Re-do structure to show table of contents (right side)
Since it's quick start, only show option to download vcluster CLI and deploy/manage cluster using CLI
Put explore features section into collapsible sections

Fixes DOC-172

Fixes Doc-143


Project settings for C# solution directory and project directory not working correctly

Godot version
3.5.1.stable.mono.official, 4.0.beta4.mono.official
System information
Windows 10, VS 2022 Community, dotNet CLI and MSBuild (VS)
Issue description
I'm attempting to use project settings "Mono->Project->Solution Directory" and "Mono->Project->C# Project Directory" to get .sln and .csproj files to be created in, or used from, specified subdirectories, rather than the Godot project root (see this proposal and the pulls resolving it).  In 4.0-beta4, these settings are relabeled Dotnet->Project->... and require the "Advanced Settings" toggle to be turned on.
On my machine (W10/VS2022/VS MSBuild or dotNet CLI), however, Godot 3.5.1 and 4.0-beta4 ignore these settings or encounter project-breaking bugs when they are used. This is both for initially creating the .sln and .csproj files, and when populating the settings and moving the .sln and .csproj files after initial creation. Failure modes include creating solution files in the wrong directory, re-creating solution files in the wrong directory, and build and/or runtime errors depending on version.
Steps to reproduce
To reproduce initial creation of the files in the wrong directory:

Create a new Godot project.
Create a subdirectory for the solution and a sub-subdirectory for the C# project.
Open Project Settings and edit the "Solution Directory" and "C# Project Directory" settings to indicate the subdirectories you created.
Create a basic scene and set it as the project's main scene. Attach a C# script and place it in the C# project sub-subdirectory.

Expected behavior: Godot will create .sln and .csproj files in the indicated subdirectories.
Observed: Godot will create .sln and .csproj files in the project root directory, instead of the indicated subdirectories.
To reproduce re-creation of files in the wrong directory:

Follow steps above, populating the project settings for "Solution Directory"  and "C# Project Directory" either before or after initial creation of the C# script.
Close Visual Studio if open.
Without closing Godot, move the .sln and .csproj files to the correct directories.
In Godot, press the "Build" button.

Expected behavior: Godot will read the .sln and .csproj files from the indicated directories.
Observed: Godot creates new .sln and .csproj files in the project root. Additionally, there is an output message reading "scene/gui/popup_menu.cpp:1191 - Index p_idx = -1 is out of bounds (items.size() = 0)." (In 4.0-beta4, the indicated line number in popup_menu.cpp is 1723.)
To reproduce build errors after moving .sln and .csproj files:

Follow steps above to create a project, attach a C# script, and populate project settings for solution and C# project directories.
Close Visual Studio and Godot.
Move the .sln and .csproj files to the correct directories.
Reopen Godot, open the project, and press the "Build" button.

Expected behavior: Godot will read the .sln and .csproj files from the indicated directories.
Observed: Godot fails to build the C# solution, apparently looking for the .csproj file in the same directory as the .sln file (possibly because the .sln file was created referring to a .csproj file in the same directory and has not been updated to reflect that they are in different directories?). The full error (in my 3.5.1 test project) reads:

C:\Users\Mark\Documents\Godot\DirectoriesBug6\src\DirectoriesBug6.sln" (Restore target) (1) ->
(_FilterRestoreGraphProjectInputItems target) ->
C:\Program Files\dotnet\sdk\6.0.402\NuGet.targets(369,5): error MSB3202: The project file "C:\Users\Mark\Documents\Godot\DirectoriesBug6\src\DirectoriesBug6.csproj" was not found. [C:\Users\Mark\Documents\Godot\DirectoriesBug6\src\DirectoriesBug6.sln]

To reproduce build/runtime errors after updating .sln file to point to correct .csproj location:
Note, this bug displays different behaviors in 3.5.1 and 4.0-beta4.

Follow steps above to create a project, attach a C# script, and populate project settings for solution and C# project directories.
Close Visual Studio and Godot.
Move the .sln and .csproj files to the correct directories.
Open the .sln file in Visual Studio. It will complain that the .csproj was not found. Remove the outdated reference to the .csproj and use "Add Existing Project" to add it back at its new location.

At this point, 3.5.1 and 4.0-beta4 diverge in their behavior. 3.5.1 continues to experience build errors, while 4.0-beta4 encounters a runtime error.
Expected behavior: Visual Studio and Godot build the solution from the correct location.
Observed, 3.5.1: At this point, Godot sees and reads the relocated .sln file, but neither Visual Studio nor Godot will build the project without errors. Visual Studio shows broken dependencies on the GodotSharp assemblies and throws build errors indicating "type or namespace not found" for Godot dependencies:

Godot will show the same errors:

Observed, 4.0-beta4: Visual Studio initially flags the GodotSharp packages as broken when the .csproj is added from its new location, but it corrects them and successfully builds the solution:

Godot also successfully builds the project. However, when the Godot project runs, although it does not crash, Godot's debugger displays the following error, and nothing in the script is executed (e.g., a GD.Print("Hello world"); in _Ready() does not produce output):

E 0:00:01:0793   can_instantiate: Cannot instance script because the associated class could not be found. Script: 'res://src/DirectoriesBug4-v4/Root.cs'.
<C++ Error>    Method/function failed. Returning: false
<C++ Source>   modules/mono/csharp_script.cpp:2288 @ can_instantiate()

Additional troubleshooting attempts/information for 3.5.1 after updating the .sln to point to the new location for the .csproj:

From Godot, using the "Clean Solution" option from the Build menu produces an error indicating that Godot is trying to read the node's script file from the project root, despite the node's properties correctly pointing to the C# file in the subdirectory. The same build errors as above persist on the next build attempt:

As a naive attempt with no real understanding of the internals, I'm able to get Visual Studio to build the solution by copying the .mono directory from the project root into the solution directory. However, this doesn't resolve build errors within Godot (output is identical to the post-clean errors showing incorrect script location, as in the previous bullet), so I'm guessing that folder copy can't actually function as a fix and there are other things that need to be adjusted.

Minimal reproduction project
"DirectoriesBug1" is a v3.5.1 project with the correct configuration to reproduce the bug in initial creation of sln and csproj files -- it has a basic main scene, subdirectories to contain the C# solution and project, and the settings to place the solution and project configured. Adding a C# script to the "Root" scene will cause the .sln and .csproj files to be populated in the project root; moving them and attempting to build while leaving Godot open will cause the files to be re-created at the project root.
"DirectoriesBug2" is the same, but after adding the C# script and moving the sln/csproj files to the correct locations, but without manually updating the sln to point to the csproj. The script, sln, and csproj files are in the correct locations with respect to the Godot project settings, but attempting to build in Godot will give the error that the csproj file is not found (looking in the sln directory).
"DirectoriesBug3" is the same, but with the .sln and .csproj files moved to the correct subdirectories and the .sln file updated with the new .csproj location. Godot 3.5.1 will see the .sln file in its new location but it will not build the project correctly, showing errors about missing Godot assemblies.
"DirectoriesBug3Beta" is the same as DirectoriesBug3, but for v4.0-beta4. It will build correctly in VS or Godot, but will show a runtime error in the debugger about instancing a script (see above in "Steps to reproduce"), and will not execute the print statement in the main scene's _Ready() method.
DirectoriesBug1.zip
DirectoriesBug2.zip
DirectoriesBug3.zip
DirectoriesBug3Beta.zip

I did not notice any issues with leaving the solution file in the root and moving the csproj, other than the godot.project issue (#69045) I was fixing in #69047.
I take it from the change in #69391 now you can still move the solution but not the csproj? Which seems fairly pointless


Twig: Expand Tests

this ticket is a stub for expanding tests in the Twig package. Right now, they're mostly just checking to see if the component renders, but now we should add tests for variants and edge cases.
@Shashika6 our first job here is to expand this ticket and determine a reasonable scope for another round of adding tickets. Please embelish this ticket with a scope describing what level of additional tests you think we should add and which components those tests should be applied to.

Scope for tests.

We have to refactor all tests to use the new endpoint exposed that allows us to pass custom field values/variant.

@justintemps Small question here :- 1. Can we use the default preview values for some components that do not have things features like additional variants.
http://localhost:8081/pattern-preview?id=button&fields=%7b%0a%22label%22%3a%20%22Button%22%2c%0a%22type%22%3a%20%22primary%22%2c%0a%22kind%22%3a%20%22button%22%2c%0a%22size%22%3a%20%22medium%22%0a%7d

Expand tests to check functionality of components. Eg :- Action events.

Where available use the variant endpoint to render and test out key features of variants as well.

@Shashika6 IMO it is better to explicitly pass the values to each components so that the behavior being tested is fixed.
But it should be alright even if you rely on the defaults. If they change, the tests should fail 😉.

Also @Shashika6 , I think it would be good if you create a cypress command that takes the props and constructs the page URL - instead of having it hardcoded in the tests.

Thats the plan @bashlk :')


UI breaks on rendering after enable new architecture

Description
Used bottom sheet as parent, screen is inside the createStackNavigator (react-navigation version 4.4.4). UI breaks on rendering after enable new architecture.
React Native Version
0.72.3
Output of npx react-native info
System:
OS: macOS 13.3.1
CPU: (8) arm64 Apple M1
Memory: 78.75 MB / 8.00 GB
Shell:
version: "5.9"
path: /bin/zsh
Binaries:
Node:
version: 16.13.2
path: ~/.nvm/versions/node/v16.13.2/bin/node
Yarn:
version: 1.22.18
path: /usr/local/bin/yarn
npm:
version: 8.1.2
path: ~/.nvm/versions/node/v16.13.2/bin/npm
Watchman: Not Found
Managers:
CocoaPods:
version: 1.12.1
path: /Users/abc/.rvm/rubies/ruby-3.0.0/bin/pod
SDKs:
iOS SDK:
Platforms:
- DriverKit 22.4
- iOS 16.4
- macOS 13.3
- tvOS 16.4
- watchOS 9.4
Android SDK:
API Levels:
- "23"
- "28"
- "29"
- "30"
- "31"
- "32"
- "33"
Build Tools:
- 28.0.3
- 29.0.2
- 30.0.2
- 30.0.3
- 31.0.0
- 32.0.0
- 33.0.0
- 34.0.0
System Images:
- android-32 | Google APIs ARM 64 v8a
Android NDK: Not Found
IDEs:
Android Studio: 2022.1 AI-221.6008.13.2211.9619390
Xcode:
version: 14.3/14E222b
path: /usr/bin/xcodebuild
Languages:
Java:
version: 17.0.2
path: /usr/bin/javac
Ruby:
version: 3.0.0
path: /Users/abc/.rvm/rubies/ruby-3.0.0/bin/ruby
npmPackages:
"@react-native-community/cli": Not Found
react:
installed: 18.2.0
wanted: ^18.2.0
react-native:
installed: 0.72.3
wanted: ^0.72.3
react-native-macos: Not Found
npmGlobalPackages:
"react-native": Not Found
Android:
hermesEnabled: true
newArchEnabled: true
iOS:
hermesEnabled: true
newArchEnabled: true
Steps to reproduce
Open layout multiple times and UI breaks.
Snack, code example, screenshot, or link to a repository
https://github.com/facebook/react-native/assets/140066955/c76a7464-a48c-40d0-aa35-c56fe51a586d

Used bottom sheet as parent, screen is inside the createStackNavigator (react-navigation version 4.4.4)

Can you open this issue against react-navigation as well?

@cortinico , Trying with removing the createStackNavigator but still getting same issue.

@cortinico , Trying with removing the createStackNavigator but still facing same issue.

@meghvarse are you still facing the issue?
Could you provide a reproducer using this template?

@meghvarse are you still facing the issue? Could you provide a reproducer using this template?

Closing as we got no response.
Please provide a reproducer and we can help you further


Allow refining Self

Updates the Generics type to include Self as base for trait, so the following now works:
#[flux::generics(Self as base)]
pub trait MyTrait {
    #[flux::sig(fn<refine p: Self -> bool>(&Self{v: p(v)}) -> Self{v: p(v)})]
    fn foo(&self) -> Self;
}

#[flux::sig(fn<T as base, refine q: T -> bool> (&T{v:q(v)}) -> T{v: q(v)})]
pub fn bar<T: MyTrait>(x: &T) -> T {
    x.foo()
}

@nilehmann I think I've addressed the issues would be good to take a look

I'm going to merge this myself because I have some big changes that are going to conflict.

thanks!


enrich existing PR template to smooth the review process

As discussed with @ValarDragon, currently Osmosis's existing pr template is a bit over simplified with only "Description" field required.
I'd like propose adding a bit more templating to help smooth the review process, as well as fostering a engineering habit of emphasizing documentations, e.g. when a new feature released or user-facing behavior changed, PR submitters should always keep in mind updating the docs at the same time in https://github.com/osmosis-labs/docs.

on the other hand, the template should not be overcomplicated like the one in cosmos SDK, which has too many checkboxes that makes it unreadable and thus no one taking it seriously anymore

this should be a very similar one to which I proposed in osmosis's doc repo https://github.com/osmosis-labs/docs/pull/68


Can no longer go back to convo after clicking image in chat.

I have to hard exit the program via the tray icon if I click an image that I'm sent. Only started doing this last night.
By the way, I have 'Open links in the browser' checked. If I uncheck it, and then click an image, it directs me to a Facebook error page.

It seems better now. I'll close this.


Add README and maven wrapper

I also suggest adding a LICENSE file. An open source project is useless if its license is not stated explicitly.

Thanks for your suggestion. The Apache License is added to the repository.


@7.9.1 - devdep updates, provenance

Pull Request Test Coverage Report for Build<PHONE_NUMBER>3
Details

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

Totals

Change from base Build<PHONE_NUMBER>0:
0.0%

Covered Lines:
67

Relevant Lines:
67

💛  - Coveralls

Pull Request Test Coverage Report for Build<PHONE_NUMBER>3
Details

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

Totals

Change from base Build<PHONE_NUMBER>0:
0.0%

Covered Lines:
67

Relevant Lines:
67

💛  - Coveralls


Image background colour

Currently the background on an image is a dull grey. Since the background of the body is white, shouldn't the image background be transparent or at least white?

Like Sam says, the JavaScript that handled this was removed when I ported the theme over.
I think the best course of action here (if you still looking to contribute @jbrooksuk ?) is to just remove any code related to the loading of images.


Create empty My Profile and Nav (PR)

In this milestone:

Create empty my profile
Create nav links

Hi @Doheera-kosi  👋
Status: Approved ✔
👍 Professional repo, with a good commit message and PR title, keep up the good work 💪
👍 The project looks good. Well Done.
Your project is complete! , there is nothing else to say other than it's time to merge it.
Congratulations! 🎉


Allow to define host restriction for clickjacking protection

This adds a small feature that allows to define a list of hosts (as regular expression) on which the X-Frame-Options header should be set.
I built it in correspondence to the hosts restriction of CSP and Forced SSL. So it is a whitelist and only if the host matches, the path will be checked before setting the header.
Furthermore, I fixed #71 which requested that the header should not be set / overwritten if it is is already set.

any plan to finish/merge/release this? this is a great feature for all multisite applications ;)

@digilist @sstok anything i can do to make progress on this? have time to contribute and would be glad to do it. build seems to fail on memory issue for php version < 7

I am not sure about the memory issue, because it's happening when dependencies should be installed with composer. So I do not think, this is related to my changes. Apart from that, the feature is ready to be merged (as far as I remember, I am not that much into these changes right now, it's been some time).

Codecov Report

Merging #187 (ee20136) into master (d87faa2) will increase coverage by 0.03%.
The diff coverage is 100.00%.

@@             Coverage Diff              @@
##             master     #187      +/-   ##
============================================
+ Coverage     95.74%   95.78%   +0.03%
- Complexity      419      424       +5
============================================
  Files            55       55
  Lines          1387     1399      +12
============================================
+ Hits           1328     1340      +12
  Misses           59       59

Impacted Files
Coverage Δ

src/DependencyInjection/Configuration.php
99.19% <100.00%> (+0.01%)
:arrow_up:

...rc/DependencyInjection/NelmioSecurityExtension.php
99.00% <100.00%> (+<0.01%)
:arrow_up:

src/EventListener/ClickjackingListener.php
100.00% <100.00%> (ø)

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 d87faa2...ee20136. Read the comment docs.


Embedding fonts at compile time

I think there should be a proc macro or a const fn or something we can use to embed a Font directly in the binary such that error handling doesn't have to be performed at runtime (no possibility of a panic). Would be nice for embedded applications

You can embed a font with include_bytes!. But, indeed, it will need to be parsed at runtime. ttf-parser doesn't provide const fn to parse fonts, though perhaps that's possible. ttf-parser already avoids allocation by parsing stuff on the fly during the various method calls anyway, so I'm not sure there would be too much benefit in avoiding the initial bit.


blog: Detroit Economic Club – Trump

test of Jekyll include

Liquid Exception: Could not locate the included file 'DetroitEconomicClub/20241010DetroitEconomicClub.md' in any of ["/home/runner/work/blog/blog/_posts"]. Ensure it exists in one of those directories and, if it is a symlink, does not point outside your site source. in /home/runner/work/blog/blog/_posts/2024-10-16-Dementia6RamblingSpeechDEC.md


使用该库，无法出效果

What kind of issue is this?

[ ] Question. This issue tracker is not the place for questions. If you want to ask how to do
something, or to understand why something isn't working the way you expect it to, use Stack
Overflow. https://stackoverflow.com/questions/tagged/MultiType

[ ] Bug report. If you’ve found a bug, spend the time to write a failing test. Please provide
      your device name, device OS version, and describe the reproduction steps.

[ ] Feature Request. Start by telling us what problem you’re trying to solve. Often a solution
already exists! Don’t send pull requests to implement new features without first getting our
support. Sometimes we leave features out on purpose to keep the project small.

Info:

MultiType version:
Device OS version:
Device Name:

Description:
Reproduction Steps:
My thoughts:
What did I do:

请提供复现程序，这个 issue 没有任何有效信息，无法给你解答，将关闭这个 issue。
如果页面没有内容，你应该首要检查，你是否把 adapter 设置给 RecyclerView。

问题已解决，我忘记给RecyclerView添加布局管理器，比如LinearLayoutManager。
另外，能否要下你的微信？
Drakeet<EMAIL_ADDRESS>于2019年5月5日周日 上午10:30写道：

Closed #268 https://github.com/drakeet/MultiType/issues/268.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/drakeet/MultiType/issues/268#event-2319341704, or mute
the thread
https://github.com/notifications/unsubscribe-auth/ALQJ2TERZIJBKEGH676LTNTPTZBENANCNFSM4HKY5KIA
.


Issue/1888 add dedicated doc page for config requirements (#7313)

Pull request opened by the merge tool on behalf of #7313

Merged into branches iso7 in d54c3f13cc0cf1a07df3ff33c882f4d542128fca


Adding morgan

I was trying to make https://github.com/howdyai/botkit/blob/master/examples/slackbutton_bot.js works as an app. The oauth was not working. It took a while to find out what was going on. In general it is not a bad idea to be able to see what hit the express endpoints. morgan helps to log that.

For logging purposes please follow the README section Logging

I think you refer to https://github.com/howdyai/botkit#writing-your-own-logging-module
It seems that that is how to use different logger instead of console.log, BTW, I realize that you can only use it for the botkit.log but not for botkit.debug.
But anyway, morgan is actually adding extra information that you currently botkit does not log. In particular, morgan, will log when something hit an express end point like (/login, /oauth, etc).

Thank you for your response.
I am not quite sure if this feature should be optional or should exist inside the Botkit itself.
What do you guys think? @benbrown @RafaelCosman

@ChrisCinelli, thanks for submitting this pull request! @anonrig, this sounds pretty useful to me. I'm inclined to include it.

You can change where it logs thought the stream option. See https://github.com/expressjs/morgan#single-file for an example. You can create a stream and output the output  to a handler that call botkit.log or botkit.debug. I would have done it, but it is not clear which of the 2 functions should be used (See also #96)


documentation of posix.stat

Looking at http://luaposix.github.io/luaposix/modules/posix.sys.stat.html and comparing to the use of this function in the LuaRocks codebase, where there is a posix.stat(filename, "mode"), it seems that the documentation for the stat() function is incomplete, lacking the description of the second argument.
More notably, the results I get with the table results don't match the description of the PosixStat table:
Lua 5.3.3  Copyright (C) 1994-2016 Lua.org, PUC-Rio
> posix = require ("posix")
> for k,v in pairs(posix.stat("xfce.txt")) do print(k,v) end
uid	1000
size	358
mtime<PHONE_NUMBER>
type	regular
ino	3806959
nlink	1
dev	2052
ctime<PHONE_NUMBER>
atime<PHONE_NUMBER>
gid	100
mode	rw-r--r--

Notably, keys don't have a st_ prefix as documented, and they are not all "int" (mode and type are strings, and type is not documented in PosixStat, so I don't know what are the possible values.
This is running the latest version:
33.4.0-1

posix.stat is the lua wrapper for posix.sys.stat.stat; where the latter is the new thin C only module that calls stat(2) and doesn't do any mangling of arguments or return values except as necessary to fit the Lua C API... and the former is a Lua wrapper for the latter to maintain legacy luaposix API compatibility.
The two are supposed to be different, but the LDocs do seem out of sync, thanks. I'll push a patch as soon as I get back to my computer.

Ah, thanks! I had just realized that posix.sys.stat.stat exists and behaves as documented. The documentation in the main module misled me to think it was a copy:

In addition to the convenience functions documented in this module, all APIs from submodules are copied into the return table for convenience and backwards compatibility.


Improving code documentation for functions in data_transform.py

This links to improving code documentation in https://github.com/ONSdigital/SDG_11.2.1/issues/158.
The function bin_pop_ages requires a return (even if it is just saying it returns the dataframe). A summary is also required for _calc_proprtn_srvd_unsrved.

I am looking to use the Napoleon extension in Sphinx which requires code documentation to be in a certain style/format: either Google or NumPy. I think we mostly follow Google but can all functions be checked to ensure they follow this format?
Example of code documentation in Google format:
def func(arg1, arg2):
    """Summary line.

    Extended description of function.

    Args:
        arg1 (int): Description of arg1
        arg2 (str): Description of arg2

    Returns:
        bool: Description of return value

    """
    return True