Add Extras to 3DTile and 3DTileset

This resolves https://github.com/AnalyticalGraphicsInc/cesium/issues/6490.  It reads the extras dictionary from tileset.json and from all tiles, and makes it accessible via a read only .extras property.
I tested it by modifying the SampleData/Cesium3DTiles/Tilesets/Tileset/tileset.json to add extras fields and checking them:
var tileset = new Cesium.Cesium3DTileset({
    url: '../../SampleData/Cesium3DTiles/Tilesets/Tileset/tileset.json'
});

tileset.readyPromise.then(function(tileset) {
    console.log(tileset.extras); // Prints { value: 12 }
    for(var child of tileset.root.children){
        console.log(child.extras); // Prints undefined for all except the tile that has the `extras`.
    }
}

I also added a test. It's basically just checking a getter, so it can easily be combined in another test instead of being its own.
I'm not sure if there's much we can do with extensions right now aside from just making it accessible in the API. Perhaps it's best to do that until more use cases arise? @lilleyse please review when you get a chance.

Thanks for the pull request @OmarShehata!

:heavy_check_mark: Signed CLA found.
:grey_question: CHANGES.md was not updated.

If this change updates the public API in any way, please add a bullet point to CHANGES.md.

Reviewers, don't forget to make sure that:

[ ] Cesium Viewer works.
[ ] Works in 2D/CV.
[ ] Works (or fails gracefully) in IE11.

I am a bot who helps you make Cesium awesome! Contributions to my configuration are welcome.
:earth_africa: :earth_americas: :earth_asia:

I'm not sure if there's much we can do with extensions right now aside from just making it accessible in the API. Perhaps it's best to do that until more use cases arise?

Yeah fine with me, I don't think we have a good use case yet for needing to expose tileset extensions to the API.

Also... add this change to CHANGES.md

Also... add this change to CHANGES.md

Just did! (https://github.com/AnalyticalGraphicsInc/cesium/pull/6974/commits/0a0af0fb64fda5aa56f919053abaf2fe0b064c66)
Regenerating the tileset.json seems to change the b3dm files as well, which I've included. (I opened the PR here https://github.com/AnalyticalGraphicsInc/cesium/pull/6974)
But now there's also this warning?
WARN LOG: 'This tileset JSON uses the "content.url" property which has been deprecated. Use "content.uri" instead.'

I'm not sure if I regenerated them incorrectly.
In the new test/spec, I loop over all the children to count the ones with an extras because it seems like the order they are in tileset.json isn't necessarily the order I get them in. I'm open to feedback if there's a better way to test this.

Sorry, I forgot that https://github.com/AnalyticalGraphicsInc/3d-tiles-tools/pull/139 was still open. If you branch https://github.com/AnalyticalGraphicsInc/3d-tiles-tools/pull/152 off of that branch most of those problems will go away.

In the new test/spec, I loop over all the children to count the ones with an extras because it seems like the order they are in tileset.json isn't necessarily the order I get them in. I'm open to feedback if there's a better way to test this.

Ah yeah, that's due to the traversal code sorting the children based on distance from camera. The way you're testing it is fine.

Thanks for the detailed feedback @lilleyse ! Should be all good now.
Actually, one issue, I noticed is when using the @exception {DeveloperError} it only shows up in the docs if it's used on a function, not on a property. The docs don't say anything about it working for properties. So even though I added it here https://github.com/AnalyticalGraphicsInc/cesium/pull/6974/commits/d4c90e36392dafe4061b39213b1760abb5ace429 it doesn't actually show up in the docs. Same for asset and other properties.
Should we remove @exception tags from properties and maybe embed it in the description? I couldn't find if there was an easy way to add exception tags to properties in jsdoc.

Should we remove @exception tags from properties and maybe embed it in the description? I couldn't find if there was an easy way to add exception tags to properties in jsdoc.

In general, properties shouldn't throw exceptions, but if there's a good reason to that's fine; just leave it as it is for now.  #832 was written a long time ago to eventually make sure they work (feel free to tackle that if you want :smile: )

Thanks @OmarShehata!


proposal: x/tools/go/analysis: change singlechecker/multichecker to allow customization of package loading

Background
The existing singlechecker.Main and multichecker.Main are simple:
they take package patterns string args (e.g. ./...), loaded them with a hard-coded go/packages.Config, and applied analyzers on the loaded packages. They also hand flags common across many analyzers, and handle error parsing, etc.
They are convenient, but not flexible enough to support analyzers that need special setup, more involved go/packages.Config (e.g. excluding tests, loading modules, applying overlays). An example analyzer I want to write:

It needs to initialize its state based on the module information loadable with go/packages.NeedModules load mode. Current APIs don't use NeedModules nor expose the loaded packages.

The initialization needs to access the loaded packages - e.g. this loads vulnerability info from a remote DB, and the loaded go/packages.Package and their modules are needed to retrieve only relevant info.

Since singlechecker.Main and multichecker.Main handle flag parsing, attempting to parse flags or command arguments before them will clobber their flag parsing logic.

Potential workaround is either to load the packages twice or to write the analyzer in a way that the very first call of its Run triggers the remaining initialization work. , which isn't ideal.
I propose we introduce a new API that provides hooks and potential customization options. With the change users can

Use a different load mode, configuration, or even filter/fake the packages.
Inject an extra initialization logic that requires loaded packages before running analysis.

Option 1: A new Run that takes a Config parameter:
package singlechecker

type Config = checker.Config

func Run(cfg Config, analyzers ...*analysis.Analyzer) { ... }

func Main(analyzers ...*analysis.Analyzer) {
  Run(Config{}, analyzers...)
}

package checker // golang.org/x/tools/go/analysis/internal/checker

type Config struct {
   // Load is called once at the start of Run to load packages specified by patterns.
   Load func(mode packages.LoadMode, patterns []string) ([]*packages.Package, error)
}

Option 2: A package-level global variable for stubbing:
We can consider a package-level global Load or Config variable that affects the existing Main's functionality.
package multichecker

// Load is a load function used by Main when loading packages to analyze.
// This is exported so users can inject their custom package load logic.
var Load = func(mode packages.LoadMode, patterns []string) ([]*packages.Package, error) { /* default load */ }

// Main uses Loader to load packages.
func Main(analyzers... *analysis.Analyzer) { ... }

Since singlechecker and multichecker are used as the 'main' of an analysis tool and already made use of many process-wide global variables, I expect the introduction of a global, exported variable is not too bad.
cc @golang/tools-team @adonovan @timothy-king

It needs to initialize its state based on the module information loadable with go/packages.NeedModules load mode.

We can forward information from *packages.Modules to the *Pass when a flag is set on the Analyzer (like RunDespiteErrors). This would still be per *Package, but it would be more information. Would that suffice? If this would help, that should probably be its own proposal. (I vaguely recall this being discussed before. I did not find it.)

expose the loaded packages

I don't think I know what this means. Can you be more specific about the API?

The initialization needs to access the loaded packages - e.g. this loads vulnerability info from a remote DB, and the loaded go/packages.Package and their modules are needed to retrieve only relevant info.

It is not yet clear to me whether this will fit into the {single,multichecker} framework yet. Config will need to make sense within unitchecker mode and split across processes. Not clear if this is compatible with your goals or not yet.
Also the checkers cache on *Pass, which are conceptually (*Analyzer, *Package) pairs. For a remote db, it will need to be possible to invalidate a *Pass based on an external source of data while in  unitchecker mode.
We can potentially expose a different part of internal/analysis too. Examples include a different Main function in another package or a more direct Run function that does not support unitchecker mode (or uses it differently). I am not sure I understand the requirements well enough to know if this would be compatible with your goals.

Option 2: A package-level global variable for stubbing:

2cents: I am not seeing an advantage of doing Option 2 over Option 1 yet. One could just pass Load as parameter.

I'm not convinced that either of these options is actually the best solution to the specific problem at hand (that we discussed in person), which is that you have an analysis (similar to https://go-review.googlesource.com/c/tools/+/408715) you wish to apply to all the packages of a program in topological order, but your analysis also needs global information about the program (a set of vulndb entries) that forces you to call packages.Load before doing the analysis. I think this indicates that the analysis simply isn't an instance of the kind of modular analysis that the go/analysis framework was designed to support. It would be relatively straightforward to modify the analysis to perform its own parallel depth-first traversal over the go/packages.Package graph. It wouldn't need to use Facts because it could assume a single address space. (Indeed, I developed the sketch in the CL above using go/packages directly and then converted it to go/analysis once it was working. It wasn't a difficult change and it would be easy to undo.)
An alternative approach would be to design an interface to the vulndb that allows each go/analysis Pass to query the database piecemeal as it encounters the need. This would of course make more calls to the database (one per package, or perhaps as few as one per package on the critical path) but they could be cached in the local file system to avoid repeat calls from developer machines.

@adonovan and I had a chat and we decided to explore a different approach
where the analyzer takes the input from local source specified with analyzer-specific
flags, and initializes within the Run if necessary.
https://go-review.googlesource.com/c/tools/+/410126
is an attempt to demonstrate this approach.
I think we can optimize the local source format further.

I think it would be reasonable to expose an API for running analyzers on a whole program loaded using go/packages, that allows the client to parse flags, load the program, and analyze it under its control, and to process the results without necessarily printing them. The underlying code would be shared with singlechecker and multichecker. Some care is required to ensure that the program is loaded using a configuration that is acceptable to the analysis that follows. And the Analyzer / Pass API should never depend on go/packages.
It would also be ok to expose go/packages configuration options through the single/multichecker CLI, such as the -test flag you added today. But single/multichecker are really not intended to be used as anything other than the main function of a standalone program.

+1 to everything Alan said (except calling it "whole program"). I think it is reasonable to expose what is effectively a lower level API for Run() from a different package than {single,multi}checker. As an example a check.Run(, []analysis.Analyzers, []*packages.Package) could produce a ([]Facts, Result, []Diagnostics) for each provided top level package. Essentially generate the actions+passes needed from preload packages, execute those actions, and then expose the results of the directly requested passes. There are a number of details to debate for such an API so this not a real suggestion yet. But it would solve the problem I am seeing in https://go-review.googlesource.com/c/tools/+/410125/1 and https://go-review.googlesource.com/c/tools/+/410126. What this would likely need to give up is providing a modular mode that is compatible with go vet -vettool=....

FWIW a hack you could do shove this into a modular analyzer is to split into 2 processes that:

fetch the remote db, determine if an update happened compared to the last run (likely with manually managed files), and generate a flag value --timestamp representing the last update, and
run a {single,multi}checker with the externally computed --timestamp flag.

This should force the modular analysis machinery to discard all of the previous results. The resulting analyzer would be tricky to run from command line but this may not be an issue for you. This does not solve custom loading.

I think exposing part of checker API addresses many issues that were closed without actually being addressed
https://github.com/golang/go/issues/30231
https://github.com/golang/go/issues/30219
https://github.com/golang/go/issues/31007
https://github.com/golang/go/issues/31897
https://github.com/golang/go/issues/50265
https://github.com/golang/go/issues/53063
...
We've seen many lint-like tools came up with their own solutions and copying of checker package internals (which I think is totally fine).
Re: https://github.com/golang/go/issues/53215#issuecomment-1147893924 That is what https://go-review.googlesource.com/c/tools/+/410126 is already doing - except --timestamp is an implementation detail specific to the type of analyzers and I think it's out of scope.

What is the current proposal?  Thanks.

I suspect both of these should be deprecated in favor of a better package.
I couldn't use them the last time I tried, and forking them was a pain due to use of internal packages.

A sketch of a new API of components for building go/packages-based analysis drivers can be found in https://go.dev/cl/411907.
This CL contains an Analyze function that takes an extensible Input struct, initially listing packages and analyzers, and returns an extensible Output struct, initially containing the roots of the action graph. An action is a step of work done by the checker, identified by the pair (analyzer, package). The rest of the action graph can be found by chasing pointers, analogous to go/packages. Each action exposes its analyzer, package, error, result, diagnostics, and facts.
The API in that CL is still not sufficient to implement all of multichecker. We still need functions for:

flag parsing
printing diagnostics as text and JSON
applying suggested fixes
testing analyzers

(It is possible to test most analyzers today with analysistest, but it too is a monolith that could be broken into reusable chunks of functionality--to load packages, run the checkers, verify the expectations, verify the suggested fixes--while also allowing ad hoc test logic to access all of the result data structures that are currently encapsulated.)
I have not sketched the API for these four features yet. My initial instinct was to publish a set of functions similar in form to the existing ones, but @hyangah raised the possibility that several of these operations might usefully be considered instances of a general post-processing interface, perhaps similar to the one in golangci-lint, which is used for a range of tasks including:
filtering diagnostics:

skip diagnostics in generated files
adjust cgo file names and skip some fishy cgo diagnostics
skip diagnostics with //nolint annotations
limit the number of diagnostics from a given analyzer or file
deduplicate diagnostics
discard diagnostics of low severity
skip diagnostics in certain files or directories

transforming diagnostics:

add a prefix to each file name
retrofit quotation marks around %s portions of specific diagnostics that should have been %q
remove unnecessary prefix from each file name
sort
attach text of source line to each diagnostic

and side effects:

apply quick fixes

It's not obvious to me that we need the full generality of another extensible plug-in mechanism, but clearly the question warrants more thought.
At this stage, the main questions to decide are:

is the initial API sketched in the CL acceptable?
should we proceed with it, or first produce a complete proposal for the other features listed above?

FWIW, I recently stumbled on what I believe is a good use case of this: in a server environment, run vet checkers and store the results in a database. I believe this could be accomplished using this driver: use packages.Load to load the packages, run vet analyzers on it, and in the post-processing step save the results to the db.

That does seem like a totally reasonable program to want to write, but the way I would write it today without the checker API is by fork+execing the multichecker executable and saving its JSON output. The overheads of process startup compared to everything else are negligible.

but the way I would write it today without the checker API is by fork+execing the multichecker executable and saving its JSON output.

This is a fair point. But it does impose some complexity on users. Most likely in the form of bundling an extra executable. Not insurmountable, but comparatively inconvenient.

I'm confused as to what happened here.  This was a proposal that had not yet been accepted, and it got closed by https://go.dev/cl/411907.  Did this not need to be a proposal?  Or was the idea just replaced by a different one?  Thanks.

@ianlancetaylor the idea was superseded by #61324.


Extension handling and type fixes

We faced an issue which was (probably) caused by a Windows update which automatically added an extension ("credProtect") during the registration process.
We were therefore unable to read the CredentialPublicKey because an error was thrown. The cause of the error lies in the cbor-x package, whose "decode" function can only decode ONE cbor value and throws an error if other unprocessed cbor values are detected in the buffer (= extensions).
This PullRequest fixes this problem, the CredentialPublicKey can now be read if there are extensions. In addition, extensions are now also processed and returned as cbor-decoded objects (array).
Furthermore, we have fixed the type definition. Two properties were incorrectly named and could not be used in a Typescript project

Codecov Report

Merging #105 (051d7fc) into master (f0290e9) will decrease coverage by 0.14%.
The diff coverage is 58.62%.

@@            Coverage Diff             @@
##           master     #105      +/-   ##
==========================================
- Coverage   92.86%   92.72%   -0.15%
==========================================
  Files          16       16
  Lines        5943     5963      +20
==========================================
+ Hits         5519     5529      +10
- Misses        424      434      +10

Impacted Files
Coverage Δ

lib/parser.js
86.21% <7.69%> (-2.22%)
:arrow_down:

lib/keyUtils.js
96.02% <100.00%> (+0.05%)
:arrow_up:

lib/main.js
96.69% <100.00%> (ø)

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

Thanks for the PR! Can you add tests for those parts, so that coverage also doesn't decrease? 👍

Looks good! Another thing that could improve is to revert the files in /dist (main.js and main.cjs). That's made automatically by the build pipeline.

I cleaned the dist directory. Sorry, I accidentally linked issues with my commits (I'm relatively new to GitHub)

Thanks, dist is removed now - can you also take care of test coverage? As hundreds of projects rely on this library, we should make sure that everything keeps working in the future 👍

Thanks, dist is removed now - can you also take care of test coverage? As hundreds of projects rely on this library, we should make sure that everything keeps working in the future 👍

I'm working on it. It's a bit difficult to understand the test setup and the other non-extension code parts

Deno test is still failing after a retry - do you need some help with the error you're receiving?

@JamesCullum yes, please help! I don't know how to reproduce this error on my local system because the code tests (lib + dist) work. I've investigated the error and know what's (theoretically) going wrong, but it doesn't make sense to me. The added extension object is processed as a public key in the "fromCose". This can only happen if the AT flag is set but no COSE-Key/PublicKey exists in the attestationCredentialData. I thought that the COSE_key is mandatory/required in the attestationCredentialData

@HSMDBC It seems like the problem was internal in<EMAIL_ADDRESS>updating to 1.4.0 fixes the problem in Deno.
I've opened a pull request to your master branch, which should fix it in this PR if merged.
https://github.com/HSMDBC/fido2-lib/pull/2
Changes:

Revert package name to fido2-lib (was fork-fido2-lib)
Update various dependencies in both node and deno lockfile

does the coverage have to be triggered manually?

Guess @JamesCullum has to trigger coverage manually (?), besides that - LGTM 👍


Trace id length - setting

Hi, AFAICS there is no setting for length of ids. Is there a good reason to set it to 64 bits and not to change it (sure, such constant helps in many ways, but why not to allow to change it "only if you are really sure"?)

You can use either 128bit or 64bit number and that is configurable. We want to be Zipkin compatible that's why we're preparing those kind of numbers. With the newest release of Sleuth you'll be able to tweak it by registering a couple of beans. However we do suggest that you reconsider this and stay with the suggested defaults.
What kind of a problem are you trying to fix by changing the length of the ids ?

Thanks for super fast answer. It is not about a serious problem, rather willingness to make it shorter, if I know the risk of collisions is low (because of amount of requests for example). It could also help on local dev envs, if you use logs a lot, to minimize the "boring" part of the log line (sure, it can be changed in other ways too).
Since it is addressed in incoming version, im closing the issue, thanks.

You can also change the logging pattern for devs and trim the id.

Hi, I have two questions about id length and log format.

In your previous comment, you said it is possible to tweak the id length by registering a couple of beans. How to achieve that? I didn't find any information in the doc. Could you provide more detailed description?
Currently, the default log format produced by Sleuth is "[application_name, traice_id, span_id, is_exported]". Is it possible to change this format? For example, I want the format to be space separated without square brackets like "application_name trace_id span_id is exported".
Thank you!

Ad. 1)
By default we generate the 64 bit value of the id. You can change it to 128 here https://github.com/spring-cloud/spring-cloud-sleuth/blob/24f6827a4a968440bf286228edb085be9d00dfe5/spring-cloud-sleuth-core/src/main/java/org/springframework/cloud/sleuth/autoconfig/SleuthProperties.java#L31 . Maybe you could elaborate more on what you're trying to achieve?
Ad. 2)
You have to change the logging.pattern.level. The default is set to https://github.com/spring-cloud/spring-cloud-sleuth/blob/master/spring-cloud-sleuth-core/src/main/java/org/springframework/cloud/sleuth/autoconfig/TraceEnvironmentPostProcessor.java#L56

Thank you for the quick response. This is very helpful.


ArduPilot SITL : SIGSEGV Sending message 76

Hi,
I am trying the SDK again starting a new project.
I have a simulation environment running gazebo/ardu sitl/ros2 and i have an issue when creating System.
Ardu version : Copter-4.5.7
MAVSDK : 2.12.10
Running logs are
[03:15:53|Info ] MAVSDK version: v2.12.10 (mavsdk_impl.cpp:26)
[03:15:53|Info ] New system on: <IP_ADDRESS>:33815 (with system ID: 1) (udp_connection.cpp:178)
[03:15:53|Debug] New system ID: 1 Comp ID: 1 (mavsdk_impl.cpp:750)
[03:15:53|Debug] Component Autopilot (1) added. (system_impl.cpp:366)
[03:15:53|Warn ] Vehicle type changed (new type: 2, old type: 0) (system_impl.cpp:217)
[03:15:53|Debug] Discovered 1 component(s) (system_impl.cpp:509)

Sometimes it stops there and no crashes happens.
But other times i have
[03:15:53|Debug] Sending message 76 from 176/224 to 1/1 (mavsdk_impl.cpp:444)
and it crash immediately.
The backtrace is :
#0  0x00007ffff621afe0 in main_arena () from /lib/x86_64-linux-gnu/libc.so.6
#1  0x00007ffff73ac8bb in std::function<bool (__mavlink_message&)>::operator()(__mavlink_message&) const (this=0x7ffff621afd8 <main_arena+856>, __args#0=...) at /usr/include/c++/11/bits/std_function.h:590
#2  0x00007ffff73a1949 in mavsdk::MavsdkImpl::send_message (this=0x7ffff621ace0 <main_arena+96>, message=...) at MAVSDK/src/mavsdk/core/mavsdk_impl.cpp:453
#3  0x00007ffff7476e0b in mavsdk::ServerComponentImpl::queue_message(std::function<__mavlink_message (MavlinkAddress, unsigned char)>) (this=0x555555a084c0, fun=...) at MAVSDK/src/mavsdk/core/server_component_impl.cpp:170
#4  0x00007ffff7375878 in mavsdk::SystemImpl::queue_message(std::function<__mavlink_message (MavlinkAddress, unsigned char)>) (this=0x7fffbc000e50, fun=...) at MAVSDK/src/mavsdk/core/system_impl.cpp:469
#5  0x00007ffff73c9849 in mavsdk::MavlinkCommandSender::send_mavlink_message (this=0x7fffbc001020, command=std::variant [index 1] = {...}) at MAVSDK/src/mavsdk/core/mavlink_command_sender.cpp:461
#6  0x00007ffff73c8ff2 in mavsdk::MavlinkCommandSender::do_work (this=0x7fffbc001020) at MAVSDK/src/mavsdk/core/mavlink_command_sender.cpp:401
#7  0x00007ffff737483d in mavsdk::SystemImpl::system_thread (this=0x7fffbc000e50) at MAVSDK/src/mavsdk/core/system_impl.cpp:280
#8  0x00007ffff739a7ca in std::__invoke_impl<void, void (mavsdk::SystemImpl::*)(), mavsdk::SystemImpl*> (__f=@0x7fffbc001dd0: (void (mavsdk::SystemImpl::*)(mavsdk::SystemImpl * const)) 0x7ffff7374762 <mavsdk::SystemImpl::system_thread()>, __t=@0x7fffbc001dc8: 0x7fffbc000e50) at /usr/include/c++/11/bits/invoke.h:74
#9  0x00007ffff739a71d in std::__invoke<void (mavsdk::SystemImpl::*)(), mavsdk::SystemImpl*> (__fn=@0x7fffbc001dd0: (void (mavsdk::SystemImpl::*)(mavsdk::SystemImpl * const)) 0x7ffff7374762 <mavsdk::SystemImpl::system_thread()>) at /usr/include/c++/11/bits/invoke.h:96
#10 0x00007ffff739a67d in std::thread::_Invoker<std::tuple<void (mavsdk::SystemImpl::*)(), mavsdk::SystemImpl*> >::_M_invoke<0ul, 1ul> (this=0x7fffbc001dc8) at /usr/include/c++/11/bits/std_thread.h:259
#11 0x00007ffff739a632 in std::thread::_Invoker<std::tuple<void (mavsdk::SystemImpl::*)(), mavsdk::SystemImpl*> >::operator() (this=0x7fffbc001dc8) at /usr/include/c++/11/bits/std_thread.h:266
#12 0x00007ffff739a612 in std::thread::_State_impl<std::thread::_Invoker<std::tuple<void (mavsdk::SystemImpl::*)(), mavsdk::SystemImpl*> > >::_M_run (this=0x7fffbc001dc0) at /usr/include/c++/11/bits/std_thread.h:211
#13 0x00007ffff64dc253 in ?? () from /lib/x86_64-linux-gnu/libstdc++.so.6
#14 0x00007ffff6094ac3 in start_thread (arg=<optimized out>) at ./nptl/pthread_create.c:442
#15 0x00007ffff6126850 in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81

Code is basic
auto conf = Mavsdk::Configuration{Mavsdk::ComponentType::CompanionComputer};
Mavsdk mavsdk{conf};
auto con_result = mavsdk.add_udp_connection("<IP_ADDRESS>", 14550);
if (con_result != ConnectionResult::Success) {
  return false;
}

auto systemOpt = mavsdk.first_autopilot(3.0);
if (!systemOpt.has_value()) {
  return false;
}

Not sure what to do at this point.
Thanks for any advices

Can you share the example, so I can reproduce it myself?
And maybe you can also share the stacktrace of all threads, in gdb it's thread apply all bt.
And you could also run it using valgrind, that sometimes tells you more.

Of course.
For some reason, doing an example with only code inside main never triggers the message sending. Doing it in a class method does it.
I also have a runloop (ros2 in my case) but it happens with anything that waits so i just put a sleep.
#include <mavsdk/mavsdk.h>
#include <unistd.h>

using namespace mavsdk;

class Runtime {
private:
    std::shared_ptr<mavsdk::System> system;

public:
    bool init() {
        auto conf = Mavsdk::Configuration{Mavsdk::ComponentType::CompanionComputer};

        Mavsdk mavsdk{conf};
        auto con_result = mavsdk.add_udp_connection("<IP_ADDRESS>", 14550);

        if (con_result != ConnectionResult::Success) {
            return false;
        }

        auto systemOpt = mavsdk.first_autopilot(3.0);
        if (!systemOpt.has_value()) {
            return false;
        }

        this->system = systemOpt.value();
        return true;
    }
};

int main(int argc, char **argv) {
    Runtime runtime;
    runtime.init();
    sleep(10);
    return EXIT_SUCCESS;
}

Full stack does not give anything more. There's no other thread in the stacktrace (other than the sleep)

Ok, I see the problem. You need to keep Mavsdk alive. You can put it in a std::shared_ptr or std::unique_ptr. In your current implementation it goes out of scope and is destructed.
Also see this comment:
https://github.com/mavlink/MAVSDK/blob/v2.12/src/mavsdk/core/include/mavsdk/mavsdk.h#L35-L36
It might not be the best wording. Probably should be something like:
 * An instance of this class must be created and kept alive in order to use the library.
 * The instance can be destroyed after use in order to break connections and release all resources.


Fix drift between SDKs in chainable utils feature

Closes #3885
Why?
This was already implemented in all non-experimental SDKs, but with slight differences. This change puts them in the same footing.
Type selection
Go was the most conservative, where With only existed in Container and Directory, manually. Python was the least one, with a generic, which applied to all object types. Node.js only excluded Query.
I think the most simple and logical “rule of thumb” to add this method is on types that have any field that return the field’s own parent type (e.g., Container.withEnvVariable: Container!). This includes Client (e.g., Query.pipeline(...): Query!), but not CacheVolume or Port.
Compatibility
The change in Go is only additive. In Python it was an inherited method, not exported in the reference docs so some users didn’t know about it from the IDE alone. In either case, I don’t expect any user to be using this method in any of the types where it was removed. If that turns out to be wrong, I’m curious to know the use case. That's why I'm not considering this a breaking change (in v0).
Docstrings
I removed the examples in the docstrings because each type’s usage is different and I think it’s weird to give a Container example in a Directory type, for example.
However, this feature will have it’s own guide, or at least a cookbook entry:

https://github.com/dagger/dagger/issues/5236

Tests
I took the opportunity to change the tests so the API calls end up the same for maximum cache reuse. But the main intent was to simplify for readability, which allows using the test cases as documentation using a simple callable and a factory, while also being able to compare how it’s implemented in the different SDKs. I chose WithSecretVariable for simplest (common) case of needing the client in a factory.
I also moved the Go test from core/integration to sdk/go because it's an SDK only feature.

@helderco I like the new rule. Definitely a good choice. Everything seems pretty straightforward, beyond the (currently) failing tests.

Needed to update node.js test fixtures again:
❯ go test ./codegen/generator/nodejs/templates/src -args -test.update-fixtures=true

@jlongtine, it's ready to review 🙂


Link to external article explaining this is broken

The link to Yahuda Katz's article explaining this seems to broken. I am not sure if this is temporary but I have managed to find a Google's cached copy of the article.

Fixes #

This seems like a small (but important) contribution, so no Contribution License Agreement is required at this point. We will now review your pull request.
Thanks,
Microsoft Pull Request Bot

the link seems to be working fine for me. keeping it unless other users are running into the same issue.


Add basic security headers

Acrarium should set a few security related HTTP headers. By default the score of acrarium tested with tools like https://securityheaders.com isn't great.
We should at least set the following ones:

x-frame-options to prevent clickjacking
Content-Security-Policy to prevent XSS attacks

We could also replace the metatag introduced in #311 with the x-robots-tag header which is also supported by Google.

Strict-Transport-Security would be nice but we would need to make sure that Acrarium is really accessed via HTTPS. Maybe as an opt-in via config flag?

Sure, I can improve the defaults, but you should be able to set headers using spring security config https://docs.spring.io/spring-boot/docs/1.0.2.RELEASE/reference/html/common-application-properties.html

Closing with 3a31975.

Strict-Transport-Security will be set based on the already existing spring property security.require-ssl
Content-Security-Policy cannot be set due to vaadin bootstrapping.


Fix ADFS token caching

#451 assumed "Bearer" is always the token_type of bearer tokens. It turns out some hosts return "bearer" instead, so that assumption broke token caching in some cases. I went with the easiest solution here--compare token types case-insensitively--but if that isn't safe in general I suppose we'll have to special-case [Bb]earer.

@bgavril integration tests fail due to an invalid value of LAB_APP_CLIENT_SECRET (one of this repo's Actions secrets). The debug logs imply value is non-empty so I guess the secret has expired.

I'm going to merge this, as the failing test is not relevant for this fix.


chore(deps): update module github.com/terraform-ibm-modules/ibmcloud-terratest-wrapper to v1.10.1

This PR contains the following updates:

Package
Type
Update
Change

github.com/terraform-ibm-modules/ibmcloud-terratest-wrapper
require
patch
v1.10.0 -> v1.10.1

Release Notes

terraform-ibm-modules/ibmcloud-terratest-wrapper
v1.10.1
Compare Source
Bug Fixes

deps: update gomod (#556) (f9691fe)

Configuration
📅 Schedule: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined).
🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.
♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.
👻 Immortal: This PR will be recreated if closed unmerged. Get config help if that's undesired.

[ ] If you want to rebase/retry this PR, check this box

This PR has been generated by Renovate Bot.

/run pipeline


[RAML to code] resource method response array type generates invalid List return type

For the RAML below:
#%RAML 1.0
title: Users
mediaType: application/json
baseUri: /api
types:
  User:
    properties:
      firstName: string
      lastName: string

/users:
  get:
    responses:
      200:
        body: User[]
  post:
    body: User
    responses:
      201:
        body:
          application/json:
            type: User

I get the following invalid controller code:
/**
 * No description
 * (Generated with springmvc-raml-parser v.0.10.5)
 *
 */
@RestController
@RequestMapping(value = "/api/users", produces = "application/json")
@Validated
public class UserController {

    /**
     * No description
     *
     */
    @RequestMapping(value = "", method = RequestMethod.GET)
    public List<User, ?> getUsers() {
        return null; //TODO Autogenerated Method Stub. Implement me please.
    }

    /**
     * No description
     *
     */
    @RequestMapping(value = "", method = RequestMethod.POST)
    public User createUser(
        @Valid
        @RequestBody
        User user) {
        return null; //TODO Autogenerated Method Stub. Implement me please.
    }

}

Note the getUsers method.

Thanks for getting in touch.
Can you please share your plugin configuration from your pom.xml?

I believe I resolved the issue.
Please check.
If you still have problems feel free to reopen this issue.

Yes, it works! Thanks for the quick turnaround!


KYLIN-4394 Fix NoSuchMethod in spark build job after update guava

Proposed changes
Describe the big picture of your changes here to communicate to the maintainers why we should accept this pull request. If it fixes a bug or resolves a feature request, be sure to link to that issue.
Types of changes
What types of changes does your code introduce to Kylin?
Put an x in the boxes that apply

[x] Bugfix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
[ ] Documentation Update (if none of the other choices apply)

Checklist
Put an x in the boxes that apply. You can also fill these out after creating the PR. If you're unsure about any of them, don't hesitate to ask. We're here to help! This is simply a reminder of what we are going to look for before merging your code.

[x] I have create an issue on Kylin's jira, and have described the bug/feature there in detail
[x] Commit messages in my PR start with the related jira ID, like "KYLIN-0000 Make Kylin project open-source"
[ ] Compiling and unit tests pass locally with my changes
[ ] I have added tests that prove my fix is effective or that my feature works
[ ] If this change need a document change, I will prepare another pr against the document branch
[ ] Any dependent changes have been merged

Further comments
If this is a relatively large or complex change, kick off the discussion at user@kylin or dev@kylin by explaining why you chose the solution you did and what alternatives you considered, etc...

Reproduce in EMR
20/06/10 10:21:20 INFO MemoryStore: Block broadcast_2 stored as values in memory (estimated size 216.5 KB, free 1028.3 MB)
20/06/10 10:21:20 ERROR KylinKryoRegistrator: failed to load class
java.lang.ClassNotFoundException: org.apache.kylin.shaded.com.google.common.collect.EmptyImmutableList
	at java.net.URLClassLoader.findClass(URLClassLoader.java:382)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:418)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:351)
	at java.lang.Class.forName0(Native Method)
	at java.lang.Class.forName(Class.java:264)
	at org.apache.kylin.engine.spark.KylinKryoRegistrator.addClassQuitely(KylinKryoRegistrator.java:322)
	at org.apache.kylin.engine.spark.KylinKryoRegistrator.registerClasses(KylinKryoRegistrator.java:110)
	at org.apache.spark.serializer.KryoSerializer$$anonfun$newKryo$6.apply(KryoSerializer.scala:137)
	at org.apache.spark.serializer.KryoSerializer$$anonfun$newKryo$6.apply(KryoSerializer.scala:137)
	at scala.collection.IndexedSeqOptimized$class.foreach(IndexedSeqOptimized.scala:33)
	at scala.collection.mutable.ArrayOps$ofRef.foreach(ArrayOps.scala:186)
	at org.apache.spark.serializer.KryoSerializer.newKryo(KryoSerializer.scala:137)
	at org.apache.spark.serializer.KryoSerializerInstance.borrowKryo(KryoSerializer.scala:329)
	at org.apache.spark.serializer.KryoSerializerInstance.<init>(KryoSerializer.scala:314)
	at org.apache.spark.serializer.KryoSerializer.newInstance(KryoSerializer.scala:223)
	at org.apache.spark.broadcast.TorrentBroadcast$.blockifyObject(TorrentBroadcast.scala:288)
	at org.apache.spark.broadcast.TorrentBroadcast.writeBlocks(TorrentBroadcast.scala:127)
	at org.apache.spark.broadcast.TorrentBroadcast.<init>(TorrentBroadcast.scala:88)
	at org.apache.spark.broadcast.TorrentBroadcastFactory.newBroadcast(TorrentBroadcastFactory.scala:34)
	at org.apache.spark.broadcast.BroadcastManager.newBroadcast(BroadcastManager.scala:62)
	at org.apache.spark.SparkContext.broadcast(SparkContext.scala:1489)
	at org.apache.spark.scheduler.DAGScheduler.submitMissingTasks(DAGScheduler.scala:1203)
	at org.apache.spark.scheduler.DAGScheduler.org$apache$spark$scheduler$DAGScheduler$$submitStage(DAGScheduler.scala:1111)
	at org.apache.spark.scheduler.DAGScheduler$$anonfun$submitWaitingChildStages$6.apply(DAGScheduler.scala:924)
	at org.apache.spark.scheduler.DAGScheduler$$anonfun$submitWaitingChildStages$6.apply(DAGScheduler.scala:923)
	at scala.collection.IndexedSeqOptimized$class.foreach(IndexedSeqOptimized.scala:33)
	at scala.collection.mutable.ArrayOps$ofRef.foreach(ArrayOps.scala:186)
	at org.apache.spark.scheduler.DAGScheduler.submitWaitingChildStages(DAGScheduler.scala:923)
	at org.apache.spark.scheduler.DAGScheduler.handleTaskCompletion(DAGScheduler.scala:1472)
	at org.apache.spark.scheduler.DAGSchedulerEventProcessLoop.doOnReceive(DAGScheduler.scala:2261)
	at org.apache.spark.scheduler.DAGSchedulerEventProcessLoop.onReceive(DAGScheduler.scala:2213)
	at org.apache.spark.scheduler.DAGSchedulerEventProcessLoop.onReceive(DAGScheduler.scala:2202)
	at org.apache.spark.util.EventLoop$$anon$1.run(EventLoop.scala:49)
20/06/10 10:21:20 INFO MemoryStore: Block broadcast_2_piece0 stored as bytes in memory (estimated size 45.1 KB, free 1028.3 MB)

Codecov Report

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

@@            Coverage Diff            @@
##             master    #1253   +/-   ##
=========================================
  Coverage     25.71%   25.72%
  Complexity     6626     6626
=========================================
  Files          1484     1484
  Lines         91189    91188    -1
  Branches      12726    12726
=========================================
+ Hits          23447    23454    +7
+ Misses        65439    65433    -6
+ Partials       2303     2301    -2

Impacted Files
Coverage Δ
Complexity Δ

...pache/kylin/engine/spark/KylinKryoRegistrator.java
0.00% <ø> (ø)
0.00 <0.00> (ø)

...a/org/apache/kylin/dict/Number2BytesConverter.java
81.74% <0.00%> (-0.80%)
17.00% <0.00%> (-1.00%)

...rg/apache/kylin/cube/inmemcubing/MemDiskStore.java
70.21% <0.00%> (+0.60%)
7.00% <0.00%> (ø%)

.../apache/kylin/cube/cuboid/TreeCuboidScheduler.java
66.15% <0.00%> (+2.30%)
0.00% <0.00%> (ø%)

...che/kylin/stream/core/storage/CheckPointStore.java
66.66% <0.00%> (+3.03%)
22.00% <0.00%> (+1.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 c170594...68ef5e6. Read the comment docs.

Pull Request Test Coverage Report for Build 6001

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage increased (+0.006%) to 28.247%

Totals

Change from base Build 6000:
0.006%

Covered Lines:
25758

Relevant Lines:
91188

💛  - Coveralls

LGTM


Add version

Very minor, would be convenient to have slacker.__version__ as in https://www.python.org/dev/peps/pep-0396/

Thanks, @zachsnow. I'll add that once I get a chance.

https://github.com/os/slacker/commit/56e42f47232113ffdfb525f5c72923dce17350ef


GDScript: Updating new script template with Indent settings

Honoring the Indent setting for new Script file template for gdscript.

Looks good. Sorry to be annoying, but would you mind amending the commit (git commit --amend and then update the PR with git push --force) to give it a meaningful commit log? What you use as title for the PR is perfect, but it should be the log for that commit too, since that is the one that appears in the changelog/git log.
(I really need to write a letter to GitHub to tell them to fix their bogus online editor with meaningless default commit logs...)

(See https://github.com/godotengine/godot/blob/master/CONTRIBUTING.md#format-your-commit-logs-with-readability-in-mind for details).


feat: vars supports in and ʻip_in` operators

add vars supports in and ip_in operators, allows the plugin's vars rule to meet multiple usage scenarios.
example:
......
{
    "vars": [
           [ "arg_name", "in", ["james","rose"] ]
    ]
},
{
    "vars": [
           [ "http_x_real_ip", "ip_in", ["<IP_ADDRESS>/16", "<IP_ADDRESS>"] ]
    ]
}
......

bad title, please update it and write some use case

show why we need this feature

example:
......
{
    "vars": [
           [ "arg_name", "in", ["james","rose"] ]
    ]
},
{
    "vars": [
           [ "http_x_real_ip", "ip_in", ["<IP_ADDRESS>/16", "<IP_ADDRESS>"] ]
    ]
}
......

Looks like "in" is enough, why need ip_in?

in and ip_in is two feature. you need to create two features

Looks like "in" is enough, why need ip_in?

IP matching is different from string matching.

in and ip_in are two feature. you need to create two features

Ok.

I do not think so.  You can look at the operators of other programming languages, you can automatically determine what type they are.

eg: 192.168.1/24, it can be a string value, and it can be a CIDR IP address too.
they are very different.
if we are using a DSL, we can support this way, here is an example.
But in JSON, we have to use different operators.
# string object
IP ~~ "<IP_ADDRESS>/24"

# IP object
IP ~~ <IP_ADDRESS>/24


Unable to pass device_id as a POST parameter when testing GCMDevice object creation

I'm testing this library using an HTTP Request plug-in for Mozilla (HttpRequester). It works perfectly if I POST to my URL as follows:
csrfmiddlewaretoken=foobar&registration_id=foo
But it never works if I do:
csrfmiddlewaretoken=foobar&registration_id=foo&device_id=1234abcd
Note: I always ensure device_id being POSTED is hex.
I can't seem to guess why the latter case doesn't work while the former works impeccably. Any leads why your library functions like so?

My template is pretty bare bones:

{% csrf_token %}

So is forms.py:
class DeviceForm(forms.ModelForm):
class Meta:
model = GCMDevice
fields = ('registration_id','device_id')

I'm using a simple template to test this:

{% csrf_token %}

Submit

What error are you receiving?

The template merely reloads, no error is thrown (debug is set to TRUE btw).

Can you post the code from views.py that processes the request?

Sure. In case the code doesn't format here properly, the views.py can be seen in this SO question here: http://stackoverflow.com/questions/31536908/unable-to-pass-multiple-post-parameters-from-django-template
Conversely you can view it here too: https://github.com/mhb11/messaging/blob/master/custompusher/views.py#L9

Please try https://github.com/jamaalscarlett/django-push-notifications/tree/bug_update

fixed by #189, dup of #171

Thanks! Will this work if the Android_ID received is erroneously not HEX?

not sure, but you can filter that at the app level, not send the id if it doesnt look right.

I was thinking we ought to patch out that too, but yea I suppose the client can take care of it on its end.

If will fail if the id is not an integer or hex.

Yea, saw that when testing with a non-HEX string for robustness.

I agree with jleclanche, that validation should be handled by your app.

As long as django-push-notifications doesn't crash then it definitely should be app-level validation.


UISegmentedControl iOS 13 tintColor

Hi! Library has problems with new element implementation in latest iOS 13 Beta. Could you please update behavior of theme_tintColor property on it?

No problem, I will support this weekend.


Update DiplomatView.coffee

Humble request to become a member of the diplomat corps.

Coverage remained the same at 56.183% when pulling c44dc966b4c893fd29c31e62fbbf834caeac258b on joca16:patch-2 into 870ee2fd84e596449dfec991c7f79b38e8250f17 on codecombat:master.

Coverage increased (+0.01%) to 56.197% when pulling f8a1b032dc2a7db34815ad3026775957b00e6cce on joca16:patch-2 into 870ee2fd84e596449dfec991c7f79b38e8250f17 on codecombat:master.

Of course. Thanks you for the contribution.


Children still laid out even when outside flMaxRows

With the following setup:
<com.nex3z.flowlayout.FlowLayout
    android:layout_width="match_parent"
    android:layout_height="wrap_content"
    app:flChildSpacing="4dp"
    app:flMaxRows="1"
    app:flRowSpacing="4dp"
    ><!-- children --> </com.nex3z.flowlayout.FlowLayout>

when the children would normally extend to second and further rows, then even though only the first row is drawn, the second row is still laid out and extends outside the FlowLayout. That is, FlowLayout's height is only big enough to fit the first row, but the second row items still appear in the hierarchy outside of that area. This is usually not an issue, unless the parent layout declares clipChildren="false" somwhere, in which case the second row will start rendering and probably overlapping some other views.
Here with the above setup I have the FlowLayout bounds highlighted:

as you can see, some children are laid out outside of it:

I've made a fix in 1.3.2:
implementation 'com.nex3z:flow-layout:1.3.2'

That was quick, thank you :) I confirm the issue is fixed in 1.3.2 🎉

(For tracking purposes) be aware that fix for this in 1.3.2 broke another scenario described in https://github.com/nex3z/FlowLayout/issues/45


Make Prometheus metric names customizable

See: https://github.com/census-instrumentation/opencensus-specs/issues/127
We should support easily adding units to metric names. Unfortunately, I don't think we can safely change the default outright but we can change all the examples and add documentation. Perhaps we can come up with a way to deprecate the current default and replace it with a better default in line with the deprecation policy.
From the specs issue, I suggested something like:
e := prometheus.NewExporter(..)
e.NameFormatter = func(v *view.View) string {
  return fmt.Sprintf("%s_%s", v.Name, v.Unit)
}

We should also provide a recommended out-of-the-b ox NameFormatter that complies with https://prometheus.io/docs/practices/naming/#metric-names

Can we track feature requests like this on the specs repo? It has to be implemented in every language.

The original issue is in the specs repo. This is the Go-specific part.

https://github.com/census-instrumentation/opencensus-specs/issues/127 is only a proposal to add unit names.
If custom metric names are required, there needs a spec issue to track it. When a spec change is just proposed, it doesn't mean it is  accepted. don't open issues on the language repos until a spec is accepted. Other contributors see an issue on this repo and try to contribute a change.

I understand the objection to changing the scope of this to allow complete customization of metric names. I have retitled this to focus on the bug, which is that we currently generate names that are not compatible with the recommended naming conventions in: https://prometheus.io/docs/practices/naming/#metric-names
My suggestion of allowing customization of metric names is only one solution to this problem. I can understand if you think this is too broad a solution. In that case, perhaps a more targeted solution to fix the issue in a backwards-compatible way would be fine. I do think that this is an issue with the Prometheus exporter for Go and so I am reopening.


Remove unused files

Some files are not included into project but still exists in the repo. I think that we don't need them anymore. Some examples:

ConceptIllustrationPage.json.cs
PreviewPage.json

etc. Easy to discover using Visual Studio
cc @aloscha

yeah agreed, should be removed

Changes in #70 Thanks a lot @aloscha!


Store the event initiator in MiqEvent object.

To keep the info about the event initiator in the MiqEvent object.
Includes https://github.com/ManageIQ/manageiq-automation_engine/pull/86.
https://bugzilla.redhat.com/show_bug.cgi?id=1487749
@miq-bot assign @gmcculloug
@miq-bot add_label enhancement

Test failure is due to the dependency on ManageIQ/manageiq-automation_engine#86.


RC test: diffusion 1.0.0-rc.2

@KatieWoe, @arouinfar, @ariel-phet, diffusion/1.0.0-rc.2 is ready for RC testing.
This release is for brand=phet only. PhET-iO and a11y are not included.
Document issues in https://github.com/phetsims/gas-properties/issues (not diffusion) and link to this issue.
@ariel-phet instructed me to assign this to @KatieWoe with "top" priority.

General RC Test

What to Test

Click every single button.
Test all possible forms of input.

Test all mouse/trackpad inputs.
Test all touchscreen inputs.

If there is sound, make sure it works.
Make sure you can't lose anything.
Play with the sim normally.
Try to break the sim.
Test all query parameters on all platforms. (See QA Book for a list of query parameters.)
Download HTML on Chrome and iOS.
Make sure the iFrame version of the simulation is working as intended on all platforms.
Make sure the XHTML version of the simulation is working as intended on all platforms.
Complete the test matrix.
Don't forget to make sure the sim works with Legends of Learning.
Check this LoL spreadsheet and notify AR or AM if it not there.
If this is rc.1 please do a memory test.
When making an issue, check to see if it was in a previously published version
If there is a console available, check for errors and include them in the Problem Description.

Focus and Special Instructions
Diffusion sim consists of the Diffusion screen from Gas Properties, with no changes.  Therefore:

Before testing this RC, complete https://github.com/phetsims/QA/issues/390, testing of Gas Properties 1.0.0-rc.2.
A full test matrix is not necessary. You only need to check the "Issues to Verify" on one platform, to confirm that this version contains the same fixes as Gas Properties 1.0.0-rc.2.

Issues to Verify
The following issues were identified in RC test phetsims/QA#386, and are relevant to Diffusion. They should be verified in this RC.

[x] credits

These issues should have the "status:ready-for-qa" label. Check these issues off and close them if they are fixed. Otherwise, post a comment in the issue saying that it wasn't fixed and link back to this issue. If the label is "status:ready-for-review" or "status:fixed-pending-deploy" then assign back to the developer when done, even if fixed.

Link(s)

Simulation
iFrame
XHTML
Test Matrix (N/A)
Legends of Learning Harness

FAQs for QA Members

There are multiple tests in this issue... Which test should I do first?
Test in order! Test the first thing first, the second thing second, and so on.

How should I format my issue?

We typically assign the developer who opened the issue in the QA repository.

My question isn't in here... What should I do?
You should:

Consult the QA Book.
Google it.
Ask Katie.
Ask a developer.
Google it again.
Cry.

[ ] Win 10 chrome
[ ] Win 10 firefox
[ ] Win 10 edge

[ ] Mac 10.14 chrome
[ ] Mac 10.14 safari

[ ] Win 7 IE
[ ] Mac 10.11 safari

[ ] ChromeOS
[ ] iOS 12

QA is done

Thank you QA! I'll leave this open until 1.0.0-rc.3 is published.

1.0.0-rc.3 is published and being tested in https://github.com/phetsims/QA/issues/400.  Closing.


Small typo fixes

Hello,
Firstly, this software is awesome - I'm a total convert! This PR unfortunately doesn't contribute much; just a couple of typos I noticed in the CLI. The spec has also been updated to match :)

@i-am-tom can you squash commits to one?

Hah, hadn't noticed the merge commit! Should be squashed.

@jails if you ok about this one i'll merge it.

Thanks for the PR @i-am-tom and glad you like Kahlan ! Using the describe/it DSL is probably the paradigm which saved my time the most during tests maintenance.
@m1ome, it's fine for me you can merge on dev :+1:


Fix segmentation violation

Description
This PR fixes the segmentation violation coming due to PVs not attached to any PVC.
GitHub Issues
List the GitHub issues impacted by this PR:

GitHub Issue #

https://github.com/dell/csm/issues/1019

Checklist:

[x] I have performed a self-review of my own code to ensure there are no formatting, vetting, linting, or security issues
[ ] I have verified that new and existing unit tests pass locally with my changes
[ ] I have not allowed coverage numbers to degenerate
[x] I have maintained at least 90% code coverage
[ ] I have inspected the Grafana dashboards to verify the data is displayed properly
[ ] I have commented my code, particularly in hard-to-understand areas
[ ] I have made corresponding changes to the documentation
[ ] I have added tests that prove my fix is effective or that my feature works
[ ] I have maintained backward compatibility

How Has This Been Tested?
Please describe the tests that you ran to verify your changes. Please also list any relevant details for your test configuration

Unit tests:

run e2e test


[Tiny correction of misspelling]

:memo:
Replace webp with web in frameless-window.md .

:+1: Thanks!


changed tmux to install via tar for latest version

Codecov Report

:exclamation: No coverage uploaded for pull request base (add-ci@3352dd5). Click here to learn what that means.
The diff coverage is n/a.

:mega: This organization is not using Codecov’s GitHub App Integration. We recommend you install it so Codecov can continue to function properly for your repositories. Learn more
@@            Coverage Diff            @@
##             add-ci       #4   +/-   ##
=========================================
  Coverage          ?   40.47%
=========================================
  Files             ?        2
  Lines             ?       84
  Branches          ?        0
=========================================
  Hits              ?       34
  Misses            ?       50
  Partials          ?        0

Flag
Coverage Δ

unittests
40.47% <0.00%> (?)

Flags with carried forward coverage won't be shown. Click here to find out more.
Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.


add(chain): Adds ViewingKey and KeyHash types in zebra-chain

Motivation
This PR adds ViewingKey and KeyHash types to zebra-chain as part of #8164.
PR Author Checklist
Check before marking the PR as ready for review:

[ ] Will the PR name make sense to users?
[ ] Does the PR have a priority label?
[ ] Have you added or updated tests?
[ ] Is the documentation up to date?

For significant changes:

[ ] Is there a summary in the CHANGELOG?
[ ] Can these changes be split into multiple PRs?

If a checkbox isn't relevant to the PR, mark it as done.
Complex Code or Requirements
Safely hashing viewing keys may need special attention.
Solution
Adds:

shielded-scan feature to zebra-chain to depend on zcash_client_backend
ViewingKey, KeyHash, and ViewingKeyWithHash types
parse() method to ViewingKey for decoding keys

Testing

Tests that key hashes for a given key match and can be used as identifiers
Tests that key hashes are encoded/decoded correctly

Review
Anyone can review.
Reviewer Checklist
Check before approving the PR:

[ ] Does the PR scope match the ticket?
[ ] Are there enough tests to make sure it works? Do the tests cover the PR motivation?
[ ] Are all the PR blockers dealt with?
PR blockers can be dealt with in new tickets or PRs.

And check the PR Author checklist is complete.

please describe how we are going to use the key hashes?

I added to its docs to say that it's for authorizing access via the gRPC interface, it's so that the client doesn't have to keep re-sending their viewing keys once they're registered in the scanner.

I still struggle to see the advantages of hashing the keys instead of using them directly. What would be worse if we didn't hash the keys?

It could be useful if the private key for the TLS encryption were compromised.


OpenSource : 1. History of free and open-source software

Description 📜
History of free and open-source software (1980 & 1990’s) was created. It consists of the following sub-topics which tells about the history of open-source  - > The Release of the GNU License, World's First OS, Cathedral Bazaar, “Open source” is born, and Commercialisation of open source.
Fixes  #20

Added content on history of open source using google colab

[x] Documentation (Content Creation in the form of codes or tutorials)

Domain of Contribution 📊

[x] Open Source

Checklist ✅

[x] I follow Contributing Guidelines & Code of conduct of this project.
[x] I have performed a self-review of my own code or work.
[x] I have commented my code, particularly in hard-to-understand areas.
[x] My changes generates no new warnings.
[x] I'm GWOC'21 contributor

@Adi7171   Amazing Work 🎉🎉🎉
Once again thanks for working on this 🙌
Looking forward to more contributions from you 😉


[Storage] [WebJobs] Added test for Blob Path for various blob names to check for blob name validation

This is related to https://github.com/Azure/azure-sdk-for-net/pull/44941
This adds tests to ensure that we have correctly taken in blob names and not truncated them. This is dependent on the fix made in Azure.Storage.Blobs.
TODO: update Packages.Data.props Azure.Storage.Blobs version v12.21.0 when it releases, to ensure webjobs will take on this fix as well.
Other changes:
Updated change log to include this fix and also other fixes that occurred between the previous release and the upcoming release.

API change check
API changes are not detected in this pull request.

API change check
API changes are not detected in this pull request.


ESD with lbaas_fallback_persist tag does not apply fallback persistence

Agent Version
9.4.0 (and 10.1.0)
Operating System
CentOS 7
OpenStack Release
Mitaka (tested Newtron too)
Description
Adding an ESD with both lbaas_perist of 'cookie' with lbaas_fallback_persist also set does not implement fallback persistence. This is the required configuration for J2EE applications and is the one of the most common combinations in LTM configurations.
An example ESD:
"dmzmobile": {
"lbaas_ctcp": "tcp-mobile-optimized",
"lbaas_stcp": "tcp-lan-optimized",
"lbaas_cssl_profile": "clientssl-secure",
"lbaas_sssl_profile": "serverssl",
"lbaas_irule": ["server_header_scrub","cve-2017-5638","cve-2015-1635","cve-2013-0156"],
"lbaas_policy": ["dmz"],
"lbaas_persist": "cookie",
"lbaas_fallback_persist": "source_addr"
}
Deployment
Deploy the above ESD (you can leave out the irules and policy. The full BIG-IP object are available if you want them) defining both lbaas_persist and lbaas_fallback_persist tags per the default /Common/cookie and /Common/source_addr profiles on every BIG-IP.
This is what you virtual will look like before the ESD:
ltm virtual prod_5a9850a2-3348-4181-a8e0-7a42db8465c0 {
description test_lb01_listener:
destination prod_16f35d9e-b37a-49e8-96cd-f9e720fb8391:https
ip-protocol tcp
mask <IP_ADDRESS>
partition prod_d303c30a319d422097e5ab0be7b619cd
persist {
/Common/cookie {
default yes
}
}
pool prod_f7be74bc-2f4e-4714-963f-ba536d02c4e2
profiles {
/Common/http { }
/Common/oneconnect { }
/Common/tcp { }
}
source <IP_ADDRESS>%1/0
source-address-translation {
pool prod_d303c30a319d422097e5ab0be7b619cd
type snat
}
translate-address enabled
translate-port enabled
vlans {
tunnel-vxlan-1089
}
vlans-enabled
vs-index 5
}
This is what it will look like after:
ltm virtual prod_5a9850a2-3348-4181-a8e0-7a42db8465c0 {
description test_lb01_listener:
destination prod_16f35d9e-b37a-49e8-96cd-f9e720fb8391:https
ip-protocol tcp
mask <IP_ADDRESS>
partition prod_d303c30a319d422097e5ab0be7b619cd
persist {
/Common/cookie {
default yes
}
}
policies {
/Common/dmz { }
}
pool prod_f7be74bc-2f4e-4714-963f-ba536d02c4e2
profiles {
/Common/clientssl-secure {
context clientside
}
/Common/http { }
/Common/oneconnect { }
/Common/serverssl {
context serverside
}
/Common/tcp-lan-optimized {
context serverside
}
/Common/tcp-mobile-optimized {
context clientside
}
}
rules {
/Common/server_header_scrub
/Common/cve-2017-5638
/Common/cve-2015-1635
/Common/cve-2013-0156
}
source <IP_ADDRESS>%1/0
source-address-translation {
pool prod_d303c30a319d422097e5ab0be7b619cd
type snat
}
translate-address enabled
translate-port enabled
vlans {
tunnel-vxlan-1089
}
vlans-enabled
vs-index 5
}
There is not fallback persistence applied.

Fixed by commit: ffe2b124bb51f10b0eb10d774720d9985507b66b


Fix bug when initial value starts with +

Hello!
If I pass a value like this one:
{ value: '+34 959 127 654' }
The formattedNumber state is: +34<PHONE_NUMBER>4
With this small change fix this kind of situations.

this fix would be super helpful! :octocat:

@alexcastano thanks for the fix.


[BEAM-6058] Adding option for flink configuration directory and setting config in exectution environment

This is needed as when submitting to remote execution environment, client config from the request is used.

Follow this checklist to help us incorporate your contribution quickly and easily:

[ ] Format the pull request title like [BEAM-XXX] Fixes bug in ApproximateQuantiles, where you replace BEAM-XXX with the appropriate JIRA issue, if applicable. This will automatically link the pull request to the issue.
[ ] If this contribution is large, please file an Apache Individual Contributor License Agreement.

It will help us expedite review of your Pull Request if you tag someone (e.g. @username) to look at it.
Post-Commit Tests Status (on master branch)

Lang
SDK
Apex
Dataflow
Flink
Gearpump
Samza
Spark

Go

---
---
---
---
---
---

Java

Python

---

---
---
---

Run Python Flink ValidatesRunner

Run Flink ValidatesRunner

I think this is required to load a custom config for portability. If you submit the "legacy" way, you would have a Flink installation with a custom config which would be automatically discovered.

I think this is required to load a custom config for portability. If you submit the "legacy" way, you would have a Flink installation with a custom config which would be automatically discovered.

Same applies in either case (which is why we need documentation). In portability case the job server replaces the legacy runner and it would discover that configuration (that's how we run the job server in Lyft).

I agree that we should document the reason for changes in JIRA.
How do you let the JobServer discover the config? Via the Java property?

The machine has Flink installed and flink-conf.yaml is same as on every cluster node. No extra properties are required for the job server (other than --flink-master-url or eq pipeline option).

Properties like taskmanager.runtime.large-record-handler are read from the submitted JobGraph and are not read by cluster when using RemoteEnvironment. Hence we need to read and set the properties in the job graph. Many of these properties are not even exposed via ExecutionConfig so we need to read these properties directly.
Reading from a config dir seems be the right way as we are already doing it for parallelism.

Also updated the jira with more details.

@tweise Reminder for review :)

Something that may make sense as part of pipeline options is to let the user provide key value pairs of configuration options and merge those into the configuration object.

Run Python Flink ValidatesRunner

Run Flink ValidatesRunner

I think this needs to be adapted to also use the config in streaming translation. Otherwise it looks fine!

Thanks @mxm .
Updated the PR to pass the parameter in case of streaming as well. I think I missed it earlier.

Is this change now equivalent to setting FLINK_CONF_DIR? If so, it would be good to document that.


Support for v2.021 Beta

Currently having issues like this:

My save:
BreakingTeethwithFingersBakery.txt

2.02 is only in beta.  I only update the beta when it's been on beta for a while because I rather wait for a load of chances before making changes on CM.

Looks like this problems is caused by the new Cookie Dragon aura, everything is fine once I change aura to different one.

Thanks for the tip!

I'll edit the title to show it was the beta.  Kind of low priority now that the live version is out.

It works for me now, thanks for the hotfixes.

You mean the live version works for the beta?  If so, good to know, but why are you playing the beta when the main version is the same or newer?

Oh no, I moved to stable.

Oh, okay.


plot all exported variables

This will make it easier to compare scenarios to each other. Just go to results/prefix/ariadne_comparison and have a look at the thumbnails, e.g.,

maybe we should replace the rule ariadne_all with the plot_comparison rule

Exporting the full dataset "ariadne/exported_variables_full.xlsx" after the plotting rule leads to some plots being empty as they require the full dataset.
I would suggest exporting both the df for upload and the full one in the export_ariadne_variables rule as I have done here: https://github.com/PyPSA/pypsa-ariadne/commit/f4a214c48bdf676b6efd78673fa1bb606b571c66
We should take care of that when merging.
The plotting script looks good. Only one import was missing.


What is a youth?

What is a youth? Impetuous fire
青春是什麼？激烈燃烧的火，
What is a maid? Ice and desire
少女是什麼？冰霜和欲望的结合，
The world wags on
年华如此迁移下去。
A rose will bloom, it then will fade
玫瑰会盛开，然后会凋萎，
So does a youth, so does the fairest maid
青春也是，最美的少女亦复如此。
Comes a time when one's sweet smile
当那时，脸上是甜美的微笑，
Has its season for a while
那就是爱的季节，
Then love's in love with me
我心里充满了依恋。
Some may think only to marry
有人只想到结婚，
Others will tease and tarry
有的人却不屑且犹豫，
Mine is the very best parry
我的藉口最是高超：
Cupid he rules us all
邱比特牵著我们的鼻子走。
Caper the caper, sing me the song
尽管嬉戏去吧，并为我唱一首歌，
Death will come soon to hush us along
死神不久将来临，叫我们都闭住嘴，
Sweeter than honey and bitter as gall
比蜜还甜，比胆还苦，
Love is a past time and never will pall
爱虽磨人，却永不走味，
Sweeter than honey and bitter as gall
比蜜还甜，比胆还苦，
Cupid he rules us all
邱比特牵著我们的鼻子走。
A rose will bloom, it then will fade
玫瑰会盛开，很快就会凋谢，
So does a youth, so does the fairest maid
青春如此，美丽的少女亦如此。

up


Add help tool pages for design commands

This is a good problem to have. There are enough commands now that users are unable to remember all of them and it's time to add help pages. This will probably require new features in Xenon for a help tool and an index service.

Consider using Apache Lucene: https://lucene.apache.org/

Unfortunately Lucene is not Java module compliant and it was too much work to do it for them. Opted to write our own simple indexer and search.


0.3.0 Release

Hello,
Any idea when 0.3.0 might be released? Are there any specific outstanding tasks I could help contribute to push this out?
Thanks,
Dave

Now already 2015, but still there is no release.
@owners, you have a lot of updates, what about publish new version?

I have to use "angular-ui-router": "#master" but once it broke the system. Having versioning would be so easy. Is it so difficult to release every now and then?


Improve button focus handling for accessibility

We are blurring the button following activation as a side-effect of how tooltips are displayed. Ideally, the button should remain focused so that tabbing continues from there rather than resetting on <body>.

If activating the button does not dismiss the current context, then focus typically remains on the button after activation,
—https://www.w3.org/TR/wai-aria-practices/#button

This branch retains focus on the button after activation, either through a mouse click or Space or Enter, and introduces a copied-class attribute for tooltip class names to apply to the button while the tooltip is displayed.

What do you think about removing this title? An element shouldn't have title and aria-label at the same time (when clicked), and this title doesn't seem necessary.

Yeah, this question gets to the root issue of misusing the aria-label attribute for tooltips. I removed the tooltip handling in 93894dba so that the host app can handle the user interface with a copy event.
The old aria-label approach is motivated by using custom tooltips. Switching to native tooltips, via the title attribute, avoids the accessibility issues here. The native tooltip naturally disappears on click so we're not left with text that implies no copy happened.
This could use another review!


jdk1.8.0_152.jdk/Contents/Home/bin/java'' finished with non-zero exit value 255

Dear sir,
My code :
for (Class<? extends Module> module : moduleClasses) {
			log.info("Module will config: {}", module);
                       // module like com.test.apps.hello.module.SomeModule
			try {
				install(module.newInstance());
                          log.info("Configured: {}", module.getName());
			} catch (InstantiationException | IllegalAccessException e) {

				throw Throwables.propagate(e);
			}
		}

public class SomeModule extends Module {

    @Override
    protected void configure() {
        bind(SomClass.class).to(SomClassImp.class);
    }
}

It working fine when i try to install only few class but when many class i got this problem

jdk1.8.0_152.jdk/Contents/Home/bin/java'' finished with non-zero exit value 255

The problem might be frominstall(module.newInstance());
Thanks in advanced.

The problem from i have many bind() But i don't know how to solve.

I'd suggest posting on Stack Overflow or somewhere else, with more information about your problem. It does not appear to be related to Guice. This issue tracker is for reporting bugs with Guice itself.

@dimo414 Thank you so much. Now i can solve this problem by increase maximum memory JVM.


Theme color in manifest.json for each icon

Will you add theme and foreground color for each icon?

The foreground color is always white, but I can see the theme color being useful. PR welcome to add that.

This was added in https://github.com/atomiclabs/cryptocurrency-icons/commit/7be9023fbaea24367cab2b9a5a5f316077bb2309.


Percentile Calculator

Enter calculator name -
Percentile Calculator
Describe calculator functionality -
The calculator determines the position of a given value within a dataset, expressed as a percentage. It does this by counting how many values in the dataset are lower than the specified value and then converting that count into a percentile. This functionality is valuable for understanding the relative ranking of a value within a dataset.
Under which category you wish to place it -

[] Computer Science
[x] Mathematics
[] Physics
[] Chemistry
[] Biology
[] Finance
[] Scientific
[] Health
[] Sports
[x] Let project owner decide
[] Suggest a new category - (Answer here)

hey @SarthakKeshari I would like to work on it.

@SarthakKeshari I am already working on it. Can you please assign it to me?

Hey @Celebi07,
In order to get the issue assigned kindly leave a comment for example - "Kindly assign it to me" or "Hey, I wish to work on this", as per the contribution guidelines.
Happy Contributing!! 🎉

@SarthakKeshari  I have removed the "screenshots" folder