nixos/rss2email: remove unnecessary cfg file indirection to fix test

Description of changes
Before this, the NixOS test very often fails due to
server # [    7.098331] rss2email-pre-start[844]: cp: cannot create regular file '/var/rss2email/conf.cfg': Permission denied

https://hydra.nixos.org/build/197922377/nixlog/1
I think this is due to the config file being read-only after being copied from the Nix store. Usually, systemd-tmpfiles will correct this, but due to the short restart interval in the rss2email NixOS test, this is often not the case.
ZHF https://github.com/NixOS/nixpkgs/issues/199919
Things done

Built on platform(s)

[x] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[x] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[ ] Tested basic functionality of all binary files (usually in ./result/bin/)
22.11 Release Notes (or backporting 22.05 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module
[ ] (Release notes changes) Ran nixos/doc/manual/md-to-db.sh to update generated release notes

[x] Fits CONTRIBUTING.md.

rss2email used to require a mutable config file in order to execute properly, so the config file needed to be outside the store at the time.
Did you manually check that everything still works fine with this change?

rss2email used to require a mutable config file in order to execute properly, so the config file needed to be outside the store at the time.

Ah, your upstream issue has been resolved, and it is part of rss2email 3.14: https://github.com/rss2email/rss2email/issues/110

Did you manually check that everything still works fine with this change?

Yes, the NixOS test here in nixpkgs still works fine, and I also tested it with my private rss2email setup.

Uhhh welp I had completely forgot this issue had been fixed, shame on me.
Thank you for the PR!

@ofborg build nixosTests.rss2email


Modified

A version running with the following changes:

trains with images without labels since I have only one label that I am interested in, and it seems to work with --use-train-aug
added customizable caching to speed up, and adding persistent workers and pre-fetching, which on my laptop speeds up training from 17 sek/iteration to 4.5-5.5 sek/iteration
Also it loads any of specified image types (previously, it only loaded *.jpg

OK, I am running it on both Ubuntu and Windows without any problem.
I will check if I can understand the problems.

Update: I have downloaded the Aquarium Combined.v2-raw-1024.voc from roboflow and I have no problem running the script. Have you tried looking at the missing file: '../../input/Aquarium Combined.v2-raw-1024.voc/train\IMG_2274_jpeg_jpg.rf.2f319e949748145fb22dcb52bb325a0c.xml' ? It seems to mix linux and windows seperators.
I have a Geforce RTX 3070 with 8GB, and my computer has 32GB RAM.

Thanks for the update. Yes, the dataset issue may be caused by path separators.
My Windows system is Windows 11 + GTX 1060 laptop GPU. I will test with less number of workers. And yes, maybe we can make the persistent workers optional. Because without it, the code in master branch works.
Further, if you can take a look at the mosaic augmentation merging black pixels, maybe I can merge the PR as soon as you can fix that.

I have misunderstood how the augmentation works. I have more or less reverted back to your original code so it works now but the I am not sure how to do the caching. I would like to cache calls to load_image_and_labels but it returns both the original image and the resized image. If I cache the original image the cache becomes too large. However, if I understand correctly, the original image is never used, only resized after load_image_and_labels, is that correct? Then if I remove the returned original image it will only cache the resized image, which in my case is much better.

OK, I have now removed permanent workers, prefetch and caching. Only allowed unlabelled images. I also fixed a bug that torchinfo is always run on cuda:0 so added device to summary call. Also added possibility to entirely disable wandb since it was interfering with starting script in background. However these should not affect anything else. To enable mosaic augmentation I needed to remove that it repeats until there is at least one label.

Also, I notice that it works quite well without caching and the other additions. The issue I had in the beginning seem not to be a problem on my Ubuntu server.

@tolsicsse
PR merged. Thank you for this useful contribution.


[FLINK-9002] [e2e] Add operators with input type that goes through Avro serialization

What is the purpose of the change
This PR extends coverage of our all-round DataStream end-to-end test job to have operators with input types that goes through Avro serialization (both for Avro specific / generic records).
Verifying this change
All end-to-end tests should still pass with the change.
Does this pull request potentially affect one of the following parts:

Dependencies (does it add or upgrade a dependency): (yes / no)
The public API, i.e., is any changed class annotated with @Public(Evolving): (yes / no)
The serializers: (yes / no / don't know)
The runtime per-record code paths (performance sensitive): (yes / no / don't know)
Anything that affects deployment or recovery: JobManager (and its components), Checkpointing, Yarn/Mesos, ZooKeeper: (yes / no / don't know)
The S3 file system connector: (yes / no / don't know)

There's a typo in the commit message: tyoe-> type

@zentol Thanks, will remember to fix the typo when merging.
@dawidwys I addressed your comments. Could you have another look?

This PR seems to be abandoned.


Option for background connection attempts

Provides Background(ctx context.Context) option for asynchronous connection process, making Options.Connect() non-blocking and always return nil error.

Thanks for the PR, I don't think that we should add a Background context state to the client right now for the connection attempts, I would expect a background state to mean for example that the client will be connected for as long as the context is valid and disconnect from NATS when the context is canceled.
Also we don't currently support reconnection attempts for when establishing the connection on the first attempt (see: https://github.com/nats-io/go-nats/issues/195)
On the other hand, good news is that you could still implement your own custom logic using a custom dialer, and also make use of APIs like DialContext part of the standard library which support connection tracing, sharing a couple of examples below:
type customDialer struct {
	ctx context.Context
}

func (cd *customDialer) Dial(network, address string) (net.Conn, error) {
	d := &net.Dialer{}

	for lastAttempt := time.Now(); ; lastAttempt = time.Now() {
		select {
		case <-cd.ctx.Done():
			return nil, cd.ctx.Err()
		default:
			if conn, err := d.DialContext(cd.ctx, network, address); err == nil {
				return conn, nil
			}
		}

		sleepTime := time.Duration(0)
		if time.Since(lastAttempt) < 2*time.Second {
			sleepTime = 2*time.Second - time.Since(lastAttempt)
		}
		if sleepTime <= 0 {
			runtime.Gosched()
		} else {
			time.Sleep(sleepTime)
		}
	}
}

func main() {
	ctx, cancel := context.WithDeadline(context.Background(), time.Now().Add(5*time.Second))
	defer cancel()

	cd := &customDialer{
		ctx: ctx,
	}
	var err error
	var nc *nats.Conn
	opts := []nats.Option{nats.SetCustomDialer(cd), nats.ReconnectWait(2 * time.Second)}
	go func() {
		nc, err = nats.Connect("<IP_ADDRESS>:4222", opts...)
	}()
	// ...

Or enabling trace borrowing httptrace package hooks:
	trace := &httptrace.ClientTrace{
		ConnectStart: func(network, addr string) {
			log.Println("Connection attempt...")
		},
		ConnectDone: func(network, addr string, err error) {
			if err == nil {
				log.Println("Established TCP connection!")
				cancel()
			}
		},
	}
	ctx = httptrace.WithClientTrace(ctx, trace)
	cd := &customDialer{
		ctx: ctx,
	}

	var err error
	var nc *nats.Conn
	opts := []nats.Option{nats.SetCustomDialer(cd), nats.ReconnectWait(2 * time.Second)}

Thanks a lot! Custom dialer solution looks much cleaner!
On Tue, Sep 4, 2018, 8:08 PM Waldemar Quevedo<EMAIL_ADDRESS>wrote:

Thanks for the PR, I don't think that we should add a Background context
state to the client right now for the connection attempts, I would expect a
background state to mean for example that the client will be connected for
as long as the context is valid and disconnect from NATS when the context
is canceled.
Also we don't currently support reconnection attempts for when
establishing the connection on the first attempt (see: #195
https://github.com/nats-io/go-nats/issues/195)
On the other hand, good news is that you could still implement your own
custom logic using a custom dialer, and also make use of APIs like
DialContext part of the standard library which support connection
tracing, sharing a couple of examples below:
type customDialer struct {
ctx context.Context
}
func (cd *customDialer) Dial(network, address string) (net.Conn, error) {
d := &net.Dialer{}
for lastAttempt := time.Now(); ; lastAttempt = time.Now() {
select {
case <-cd.ctx.Done():
return nil, cd.ctx.Err()
default:
if conn, err := d.DialContext(cd.ctx, network, address); err == nil {
return conn, nil
}
}
  sleepTime := time.Duration(0)
  if time.Since(lastAttempt) < 2*time.Second {
  	sleepTime = 2*time.Second - time.Since(lastAttempt)
  }
  if sleepTime <= 0 {
  	runtime.Gosched()
  } else {
  	time.Sleep(sleepTime)
  }

}
}
func main() {
ctx, cancel := context.WithDeadline(context.Background(), time.Now().Add(5*time.Second))
defer cancel()
cd := &customDialer{
ctx: ctx,
}
var err error
var nc *nats.Conn
opts := []nats.Option{nats.SetCustomDialer(cd), nats.ReconnectWait(2 * time.Second)}
go func() {
nc, err = nats.Connect("<IP_ADDRESS>:4222", opts...)
}()
// ...
Or enabling trace borrowing httptrace package hooks:
trace := &httptrace.ClientTrace{
ConnectStart: func(network, addr string) {
log.Println("Connection attempt...")
},
ConnectDone: func(network, addr string, err error) {
if err == nil {
log.Println("Established TCP connection!")
cancel()
}
},
}
ctx = httptrace.WithClientTrace(ctx, trace)
cd := &customDialer{
ctx: ctx,
}
var err error
var nc *nats.Conn
opts := []nats.Option{nats.SetCustomDialer(cd), nats.ReconnectWait(2 * time.Second)}
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/nats-io/go-nats/pull/390#issuecomment-418464687, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AE_mfYtXzL64NIlWt2W7jphpx1f8cHZ4ks5uXsGKgaJpZM4WZEuU
.

no problem :) ok closing this one for now

Added full example on a gist here: https://gist.github.com/wallyqs/2cf37ed3b19517e16e466461376fd53b

@wallyqs The one problem i see is that it is not possible to connect in non-blocking way, is there any way to achieve this?

@shaxbee I am curious what the use case is for non blocking backgrounded connect? If you want to do message processing in the background just start the worker code in a go routine?

@ripienaar This is same as #195 - in cloud system i'd like service to start even if nats is unavailable momentarily for example due to restart or any other issue, similarly to what happens in database/sql - calling sql.Open() doesn't block even if destination host is unreachable.

You can still start - just handle your routine that connects and process data in a go routine?
go thing.Run(ctx, wg)

// continue startup

wg.Wait()

this way your main loop that might potentially block on the network initial connection doesnt hold up the startup loop.  It's a very common pattern in Go and I think NATS not reinventing this wheel is just fine.


onFocus and onBlur are acting weird

I have tried to control picker by myself, because i had to add third way to open/close the calendar.
So i've followed the docs and connected prop "open" to my state, onFocus was setting the prop open:true, but calendar didn't appear.
The same with onBlur, when i tried change value open onBlur, there is no change.
EDIT:
After 5h of looking for proper way to control open prop i have found the workaround.
class DatePicker extends Component {
    constructor(props) {
        super(props);

        this.state = {
            open: undefined
        }
    }

    handleFocus = () => {
        this.setState(Object.assign({}, this.state, {
            open: true
        }));
    }

    handleClose = () => {
        this.setState(Object.assign({}, this.state, {
            open: false
        }));
    }

    renderDay = (props, currentDate) => {
        return (
            <td
                {...props}
                onDoubleClick={this.handleClose}
            >
                {currentDate.date()}
            </td>
        );
    }

    render() {
        const {open} = this.state;
        return (<Datetime
            className={open && "rdtOpen"}
            onFocus={this.handleFocus}
            onBlur={this.handleClose}
            renderDay={this.renderDay}
            {...this.props}
        />)
    }
}

It is whole example of my wrapper - i just wanted to hide dropdown when doubleClick on day.

After 5h of looking for proper way to control open prop i have found the workaround.
render() {
        const {open} = this.state;
        return (<Datetime
            className={open && "rdtOpen"}
            onFocus={this.handleFocus}
            renderDay={this.renderDay}
            {...this.props}
        />)
    }

facing the same. Noticed that onBlur doesn't fire at all!

onBlur and onFocus must be passed within inputProps like this:
return (<Datetime
className={open && "rdtOpen"}
inputProps:{
onFocus: this.handleFocus,
onBlur: this.handleClose
}
renderDay={this.renderDay}
{...this.props}
/>)

So i believe it is a issue of documentation, right? OnFocus&OnBlur are with inputProps on the same level in table describing properties.

@damianprzygodzki I'll do some investigation tonight when I get home about this. Sounds fishy. It should definitely specify in the docs if this is how it works.
@hazboun thanks a lot!

@simeg thanks for that.
Some new clues found after lot of investigation.
onBlur is working (outside the inputProps) but there is no date parameter described in doc. onBlur and onFocus in the inputProps do not return the date described in doc.

@damianprzygodzki does merging #164 affect this issue you are having? Besides the documentation potentially being wrong (I'll have to investigate on that).

@simeg yeah, now it is working stable and (watch out!) properly with documentation! So i think what @hazboun said is true - but completely different case - these are native input events.


Feat: New option for export data - group by article_id

What's changed:

backend/data_export/pipeline/writers.py: added new writer - JsonArticleWriter to groupby the dataframe by article_id before writting its records to json file
backend/data_export/pipeline/factories.py: added new mapping for exportation with the new writer
backend/data_export/pipeline/catalog.py: registered new option for exportation in catalog
backend/data_export/pipeline/examples/affective_annotation/article_example.json: added new example file for new type of data export

Screenshots:
New export option:

Exported result from new option:

Hi, I just tested it and everything works perfectly fine. Thank you for the excellent work!
There is just one very minor comment, in the example file backend/data_export/pipeline/examples/affective_annotation/article_example.json there is no field for "label" (i.e. for the data from table labels_textlabel), only "scale". This is not really an issue because when I tested the data exportation, we do get the textlabel data, and I see in the code that the textlabel exportation mapping is handled by TextQuestions. sweat_smile
Approved for merging!

Haha yeahh XD I was lazy then I copied paste and missed that field XD Added :laughing:


Regression in 12.8.2: Function IAM auth broken by recent resolver changes

How did you install the Amplify CLI?
npm
If applicable, what version of Node.js are you using?
9.6.5
Amplify CLI Version
12.8.2
What operating system are you using?
Mac
Did you make any manual changes to the cloud resources managed by Amplify? Please describe the changes made.
No manual changes applicable
Describe the bug
The resolver changes in https://github.com/aws-amplify/amplify-category-api/pull/1919 moved the definition of adminRoles from the auth function request mapping template into the resolver's stash context.
The definition of adminRoles was added to the stash context in amplify-graphql-transformer-core here: https://github.com/aws-amplify/amplify-category-api/commit/9297fa5cd#diff-b3129bb53f056565ba11ca27f5846ebb888f0f8bdd643238e2621cd44cd365bdR397
However, it was not added in amplify-graphql-function-transformer/src/graphql-function-transformer.ts. It may also need to be added to amplify-graphql-http-transformer/src/graphql-http-transformer.ts.
The auth function mapping template for a function now expects adminRoles to be present on the stash context, but it is missing, which breaks function auth.
Expected behavior
$ctx.stash.adminRoles should be populated in the resolver stash context if it is expected to be read by the function request mapping template.
Reproduction steps
Have something like this in schema.graphql:
Query {
  myFunction(userId: ID!): SomeObject
    @function(name: "myFunc-${env}")
    @auth(rules: [{ allow: private, provider: iam }])
}

Give access to another lambda to call the API.
In amplify 12.7.1, the call is successful. The "before" mapping template for the resolver looks like this:
## [Start] Stash resolver specific context.. **
$util.qr($ctx.stash.put("typeName", "Query"))
$util.qr($ctx.stash.put("fieldName", "myFunction"))
$util.qr($ctx.stash.put("authRole", "(trimmed)"))
$util.qr($ctx.stash.put("unauthRole", "(trimmed)"))
{}
## [End] Stash resolver specific context.. **

And the QueryMyFunctionAuthFN Request Mapping Template looks like this:
## [Start] Field Authorization Steps. **
#set( $isAuthorized = false )
#if( $util.authType() == "IAM Authorization" )
  #set( $adminRoles = ["myfunc1","myfunc2","myfunc3","myadminuser"] )
...

In 12.8.2, it fails with "Not Authorized to access myFunction on type Query". Looking at the appsync configuration, the QueryMyFunctionAuthFN Request Mapping Template now looks like this:
## [Start] Field Authorization Steps. **
#set( $isAuthorized = false )
#if( $util.authType() == "IAM Authorization" )
  #set( $adminRoles = $ctx.stash.adminRoles )
...

but the "before" mapping template is unchanged from 12.7.1 -- $ctx.stash.adminRoles is not defined.
Project Identifier
No response
Log output
No response
Additional information
No response
Before submitting, please confirm:

[X] I have done my best to include a minimal, self-contained set of instructions for consistently reproducing the issue.
[X] I have removed any sensitive information from my code snippets and submission.

yeah, get same issue.

Just wanted to add...I'm not using Amplify CLI, but rather the @aws-amplify/graphql-api-construct within AWS CDK.  The fix from #2062 solved my issue where my adminRole was being assumed by an EC2 instance or an IAM user and resulting in "Not Authorized" errors.  After updating everything is working as I thought it would/should originally.


Can you make this a livery for the Cessna 172 Skyhawk

sure

give me a closer look on whats on the door

I will start it July 5th

when will the livery be available

Soon
On Thu, Jul 11, 2024 at 5:29 PM BoeingAviationYT @.***>
wrote:

when will the livery be available
—
Reply to this email directly, view it on GitHub
https://github.com/kolos26/GEOFS-LiverySelector/issues/681#issuecomment-2223969587,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/A642O5SZK6SZLTXKDRQTJQ3ZL32JXAVCNFSM6AAAAABJ6HRN36VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDEMRTHE3DSNJYG4
.
You are receiving this because you commented.Message ID:
@.***>

Can i have a date when its going to be available


Code not working

Godot version:
3.2.3
OS/device including version:
Windows 10
Issue description:
I downloaded Godot, then I started using a tutorial but then the code did not work, so then I copied the entire thing, and that did not work at it had a error
E 0:00:12.325   instance_create: Script inherits from native type 'KinematicBody2D', so it can't be instanced in object of type 'Node2D'.
<C++ Error>   Method failed. Returning: __null
<C++ Source>  modules/gdscript/gdscript.cpp:325 @ instance_create()
than I followed a tutorial on a offical website of godot, copied it, did not work as it always said the error  above, than I downloaded a project saw it worked copied a project files, did not work, Please help me

You need to provide a reproduction project so the developers are able to tell if it's a problem with the engine or not.
If it turns out not to be a problem with the engine, then GitHub issues it not the place you're looking for; there are plenty of ways of getting help on how to use Godot. :slightly_smiling_face:

I downloaded Godot, then I started using a tutorial

Which tutorial? Consider opening an issue at https://github.com/godotengine/godot-docs.

You're assigning a script with extends KinematicBody2D to a node of type Node2D. That's not allowed, hence the error.
Either the tutorial is wrong (in which case see previous comments) or you made a mistake.

how do you make the node kinematicbody2d


New Resource: github_organization_project

Hi, this PR adds the ability to manage organization projects to this provider as described in https://developer.github.com/v3/projects/#create-an-organization-project. This is my first time working with Terraform provider, please let me know if I miss anything. Thank you.

It seems that there is conflict. Would you like me to rebase?

@shihanng yes, I merged a few PRs lately and I'm going through others, including this one. I'm going to review it regardless, but rebasing would be incredibly helpful.
Thanks!

@radeksimko, thank you for the reviews. I've addressed some comments in code, and also the rest as comments. Could you please take another look. Thank you.

Thank you so much 😄! I will work on #115 later on and ping you again when it is ready.


Don't Merge! PR real time test for source branch full build

Docs Build status updates of commit 21e4c10:
:clock10: Pending: waiting for processors (19 builds ahead of you)
:warning: Docs Build is busy, currently there are 19 builds ahead of this one, for more information you can view the Build queue graph on the Docs Portal.

Docs Build status updates of commit 21e4c10:
:clock10: Full build: the average full build time is 6 min(s) 47 sec(s), this is based on the last 30 build(s) for this repository.

Docs Build status updates of commit 21e4c10:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

docfx.json
:white_check_mark:Succeeded

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


container start HostConfig breaks container configuration

As noted in #1258, the Docker remote API allows the HostConfig attributes to be set when starting a container. (They are supposed to be set when creating)
The specific case there (Kubernetes) uses --net=container:(another container), so is fixed by #1314, but if someone did the same thing and specified --net=host in the start request then weavewait would hang because there is no ethwe interface.

--net=(another container) is fixed by #1314

...iff another container is attached to weave.

specified --net=host

or --net=(another container that is not attached to weave)

We've just had a user run into this. Specifically, their client is posting the following
POST /v1.15/containers/f1e8b4e4c692e70b4cae1c2aa6afe22f10c3550af7da340a2f623a58d582555f/start HTTP/1.1
Host: <IP_ADDRESS>:12375
User-Agent: Go 1.1 package http
Content-Length: 632
Content-Type: application/json
Accept-Encoding: gzip

{"Binds":["769f6375-b847-4182-bd5e-c0ed9430c5fb:/root"],"ContainerIDFile":"","LxcConf":null,"Memory":0,"MemorySwap":0,"CpuShares":0,"CpuPeriod":0,"CpusetCpus":"","CpusetMems":"","CpuQuota":0,"BlkioWeight":0,"OomKillDisable":false,"Privileged":false,"PortBindings":null,"Links":[],"PublishAllPorts":false,"Dns":null,"DnsSearch":null,"ExtraHosts":null,"VolumesFrom":null,"Devices":null,"NetworkMode":"","IpcMode":"","PidMode":"","UTSMode":"","CapAdd":null,"CapDrop":null,"RestartPolicy":{"Name":"","MaximumRetryCount":0},"SecurityOpt":null,"ReadonlyRootfs":false,"Ulimits":null,"LogConfig":{"type":"","config":null},"CgroupParent":""}

Note in particular the null values for Dns and DnsSearch. These end up stomping on the values injected by the proxy on container creation; a subsequent inspect of the container returns the null values.

TBH, I am not that bothered about the --net issue. I suggest we don't worry about it unless some users bump into it.
The issue with DNS settings needs fixing. And should be easy to fix too. Presumably the weavewait volume mount can get stomped on too. I wonder why that didn't cause any problems for the user. Perhaps Docker only pays attention to some fields in a 'start' HostConfig? Or has some merge semantics for some of them?

Binds in HostConfig are merged.

Fixing in 1.2, as the /start handler has changed quite a bit from 1.1 to 1.2, and I don't want to do it twice.


update from upstream/make it work for go1.23

Right now there is an error with go1.23
../../../go/pkg/mod/fortio.org/testscript@v0.3.1/exe_go118.go:11:27: cannot use nopTestDeps{} (value of type nopTestDeps) as testing.testDeps value in argument to testing.MainStart: nopTestDeps does not implement testing.testDeps (missing method InitRuntimeCoverage)

fixed in #8


Is this app on Apple Store?

Hi KyleKun, thanks for the work! I am wondering is this app available on apple store? I see there is an ios folder. Thank you very much!

Hi KyleKun, thanks for the work! I am wondering is this app available on apple store? I see there is an ios folder. Thank you very much!

Hi, thanks! Unfortunately not yet, please see my previous answer here: https://github.com/KyleKun/one_second_diary/discussions/65#discussioncomment-4892521


please allow DatePicker to parse keyboard input

Instead of making the input readonly and disallowing keyboard input, it would be good if the dialog would open in such a way as to not obscure the field, the user could type in a date string, and DatePicker would parse it (see here for how) and update the dialog selection in real time.
This would be good for accessibility reasons as well as just user-friendliness.

This would be awesome. Just imagine someone selecting a birthdate in the current dialog...
I was thinking about it with a simple masked input, like most date choosers out there, but using something like SugarJS date parsing is even nicer.
I think this can be achieved currently using a custom Input with the undocumented DatePickerDialog. So, as an alternative option, a better DatePickerDialog documentation could be used to show it with a custom Input.

@renato -- can you elaborate on how it could be accomplished today? A workaround would be amazing!

WRT selecting a birth date, see also: #402

Sorry @jeffreywescott, DatePickerDialog needs to be changed before a workaround is possible.
It currently sets its state.date from props.value only one time, so my test didn't work out of the box.
After mounting, DatePickerDialog.state.date keeps the selected date, even if you dismiss the dialog. On reopening, the selected date is the same, no matter what is the DatePickerDialog.props.value.
I tried something just to show what I thought was possible, without any validation, just dirty JSON.stringify/parse. Looking at DatePicker.jsx, we needed to handle the dialog opening/dismissing and date selection.
export default class DirtyTest extends React.Component {
  state = {active: false}

  handleDismiss = () => this.setState({active: false})
  handleClick = () => this.setState({active: true})
  handleSelect = (value) => this.setState({active: false, date: value})
  handleChange = (value) => this.setState({date: new Date(JSON.parse(value))})

  render() {
    return (
      <div>
        <Input
          icon='date_range'
          label='Birthdate'
          value={JSON.stringify(this.state.date)}
          onChange={this.handleChange.bind(this)} />
        <IconButton icon='arrow_drop_down' onClick={this.handleClick} />
        <DatePickerDialog
          active={this.state.active}
          onDismiss={this.handleDismiss}
          onSelect={this.handleSelect}
          value={this.state.date}
          />
      </div>
    );
  }
}

When the date is selected in the dialog, the Input gets the JSON.stringified date. When we change the date in the input, our this.state.date is changed as well but it doesn't match the selected date in the dialog when you open it.
So, finally, in order to DatePickerDialog to use the date we set in the Input, I think the best solution would be to get rid of its date state, using only props.value/props.onChange to handle the selected date.
For my little test, it worked with a simple addition to DatePickerDialog.jsx:
  componentWillReceiveProps = (newProps) => {
  	this.setState({date: newProps.value})
  }

Again, this is just a test, it's not how I think it should be done.
And, of course, the Input being editable, we need to validate minDate/maxDate and the date format, which can be a 'MM-DD-YYYY'-like mask set by the user or, as you suggested, SugarJS dates.

I've begun working on this feature, but it is my first open source contribution, so bear with me if it isn't the most efficient fix, haha.
Currently, my solution adds the following features:

Opens date picker dialog on focus, so you can tab from one input field to a date picker and it automatically bring the calendar up.

Once calendar is active, an 'on-board' input box is auto-focused and ready to parse user input. As soon as the user provides a valid date (/(\d{1,2})(?:\/?|\s*)(\d{1,2})(?:\/?|\s*)(\d{4})/) then the year, day, and month on the calendar will update to match.

In the case that the user clicks a different day/month or changes the year, the input field is changed to reflect the new date picked.

The new date input field listens for the enter key to submit the calendar and return the date to the original date picker.

A few issues I am still battling with are:

My algorithm for changing the month to match the input sometimes misses by.. a year, haha.

I could not get any custom styles to apply to my new input box. I feel like it could use some adjustments because it currently looks very out of place.

Figuring out how to return focus back to the date picker (when the user presses enter to close the calendar) without re-firing the onFocus event on the date picker, causing the calendar to automatically pop back up. I need to return focus to the date picker so that the user can tab to the next one.

I am also working to figure out how to allow input in the date picker input, itself.
Like I said, this is my first open source contribution, and although I have used it a bit, I am not the most well versed in React, either. My current work is available here. Feel free to give me advice or constructive criticism!

Some thoughts (maybe I'm missing something you guys commented up there):
This is even more complicated if we add localization support. Also, providing feedback to the user is not easy because if you open a Dialog to show the picker and then start typing, the input would be hidden. You should be able to see some kind of feedback of what you are actually typing but this is not possible without violating the MD visual guidelines.
You can always keep like an "in-memory" input but without giving visual feedback it would be quite obscure. I agree it would be nice but I don't see a way to do this without breaking the rules

@javivelasco I see your point with localization, but we could just have different date parse functions for each locale. We could even add an attribute that would allow users to pass-in their own date parsing function.
WRT user input, I think it should just behave like a plain text field, and when the input loses focus, it calls the date parse function, updates the UI (if the parse succeeds), and highlights the mistake otherwise. Would that be a violation of the visual guidelines? Which one, specifically?

I don't know if it will help, but here is a short demonstration of what I had accomplished at the time of my post above. I'd love to take this requested feature and make it a reality, so any guidance or support would be greatly appreciated.
https://drive.google.com/file/d/0B4YUcg2HBSIvTXpmRC0yaHJHZ2c/view?pref=2&pli=1

@colshacol I think it's very nice and also it's useful. I'm sure we can make the parsing work out of the Calendar component allowing to compose some smaller components to create the Picker with parsing options.
My only concern with this is that I've never saw before this kind of component in Material Design but it will definitively fit into a complements repository/submodule for react-toolbox. Great work!

Closed in favor of #626

PR #704 and PR #705 allow keyboard to be used with the date picker. Both to enter dates and to navigate the calendar.
Not sure if they will get merged in but our project needed something and this covers us for that need. Anyone feel free to use/copy the changes.

I think those PRs are a good start. I would give a deeper thought at the code but I think they could be merged without a problem :)


[2] Prepare a list of user facing API:s

Go through the projects in apps and determine which ones contain user facing API:s Create a nice list with this info in the docs folder, where it can be used as reference when preparing customer changelogs and upgrade recommendations.

@lucianvlad can we take this in the arch meeting?

@crssnd Thanks for giving this issue TLC. :smile:
I thought the topic is kind-of closed, given that we have a mature ToS and public docs. However, I'd like to hear other opinions too. The arch meeting feels like the right forum for this.


Fixed new line and prioritise blurOnSubmit in multiline text input

Motivation (required)
What existing problem does the pull request solve?
this fixes #13506 and #12717 where:

there are some issues when pressing enter with some keyboard
blurOnSubmit is not working with multiline

I think this should be in stable branch as this is pretty critical, isn't it?
Test Plan (required)

just create a TextInput with multiline and press enter with samsung keyboard
before, it won't create a new line, now it will.

just create a TextInput with multiline and blurOnSubmit true and press enter
before, it won't blur, and wont create a new line (on some keyboard, it will create a new line), now it will blur only

i dont really understand how to create the unit test, can someone help me please?

Merge this please! We have the same problem! @kevinluvian I would specify also that this is on Android only :)

@henrikra does this work for you?

@superandrew213 How can I test this PR? I tried to and that piece of code to my RN installation under node_modules but it did not work

@henrikra you have to build from source https://facebook.github.io/react-native/docs/android-building-from-source.html

hopefully this will get merged soon, will this take care of the scroll issue as well?

Tried this on 0.44. It works.

@kevinluvian Awesome! Have you tested this solution with all combination of keyboards, blurOnSubmit, and isMultiline?

i don't understand why the travis keep failing

@kevinluvian I change the above code,  I cannot create newlines

you need to compile the react native from source
https://facebook.github.io/react-native/docs/android-building-from-source.html

I recompile after the change in the source code, and I can't create a new line

Oh, I see

@kevinluvian  Have compiled, and I always compile errors

So does that mean the issue should be fixed now? Will updating to the latest version on Github resolve the problem then?

Yes, I hope this issue is fixed now.

@kevinluvian @shergin   Has the above method been validated? Is that settled?

@shergin I upgraded my version of React Native to the most recent version using react-native-git-upgrade, and the issue persists while using the Samsung keyboard. The Google Gboard works (as I believe it always has) as expected.

@thejacobseely What version of React Native did you upgrade to? This fix isn't yet included in any releases of React Native. It is only included in the master branch. If you want to use this change before it makes it into a release, you'll need to consume and build React Native from source (rather than as a binary). Here are instructions for doing that: http://facebook.github.io/react-native/releases/0.46/docs/android-building-from-source.html#building-react-native-from-source

@rigdern Thank you, as you can tell I'm a little new to GitHub, I thought everything in the master branch was automatically included in the release, but I realize now how problematic that would be.
I will try that, thanks for your help.

In which release of React Native this changes would be applied?
I have 0.46.3 but still facing the same issue
my code is
<TextInput
     placeholder={'Add Message (250 words)'}
     multiline={true}
     blurOnSubmit={false}
     onChangeText={(text) => this.setState({
        messageText: text
     })}
     value={this.state.messageText}
     />

@rajsuvariya As can be seen by looking at the commit details on GitHub, this commit is currently only in the master branch and so it's not yet included in any release of React Native.

If you'd like to try this change before it's included in an official release, see my earlier comment for details.

@rigdern Actually it's a live project so don't want to take risk of changing the environment. Will wait for the stable release

What is the status on this? I'm still seeing this issue.

@superandrew213 Using the technique mentioned in my previous post, you can see this commit has been included in React Native since version 0.48.0. What version of React Native are you using?


Reduce memory usage of SkipListWriter

Description

Currently, we always use the size Lucene99PostingsFormat.MAX_SKIP_LEVELS to initialize the array fields of SkipListWriter. However, we have already calculated the maximum possible skip levels upfront in MultiLevelSkipListWriter.

@jpountz @mikemccand could you take a look when you get a chance

This looks correct to me too -- we know the max number of skip levels for this particular segment and should size the arrays based on that, not based on the global worst case max ever for the worst case segment.
But, we are now moving away from the multi-level skip lists to inlined double level skip lists (https://github.com/apache/lucene/pull/13585)...

@mikemccand  ok, I will close this PR. Btw, I think when we can do the same optimization for the skip reader, and we usually need to read old indices.  I want to know if I should optimize the old skip reader, or if I just need to close #13623?"

Closing this PR as discussed above. We could fix heap usage on the reader side, though I haven't seen any complaints about it.


[T4A5][W10-B4] Karen Ang

Good work @karenang
Some comments added. Please close the PR after reading comments.

Noted, thank you!


Fix obsolute setting about default storage

Use django.core.files.storage.FileSystemStorage. The previous
dbbackup.storage.filesystem_storage no longer exists.

Coverage decreased (-0.5%) to 95.291% when pulling f4cc0673b588d73f8648ca41dbf12406ce6bbe35 on AgriConnect:master into a2ec00ccce4399646dd7432e0e731e005affc4bb on django-dbbackup:master.

Thanks a lot and sorry for my latency


uploads: Skip the outgoing proxy if S3_KEY is unset.

When the credentials are provided by dint of being run on an EC2
instance with an assigned Role, we must be able to fetch the instance
metadata from IMDS -- which is precisely the type of internal-IP
request that Smokescreen denies.
While botocore supports a proxies argument to the Config object,
this is not actually respected when making the IMDS queries; only the
environment variables are read from.  See
https://github.com/boto/botocore/issues/2644
As such, implement S3_SKIP_PROXY by monkey-patching the
botocore.utils.should_bypass_proxies function, to allow requests to
IMDS to be made without Smokescreen impeding them.
Fixes #20715.
Testing plan: Deployed to a host on S3 with a role which grants write access to the S3 buckets.

This is great, merged, thanks @alexmv!


calculate_sat_point could be updated to account for surface stats

When regspace=='fsaverage' the stat_temp file is not in z units; since the max z-value is calculated via calculate_sat_point() before any conversion to z, I think the units should probably be adjusted before determining max(3.71, np.percentile(data,98)) in this function?

Steph.

I need more context for what you're talking about.

Oops, I meant to say this was in surface_snapshots.py.
When the group analyses are done on the surface, the function calculate_sat_point() doesn't adjust for the fact that the stat file is in -10log(p). I think this ends up being roughly equivalent to z-stats, but might be a little off unless the data is converted to z-stats before determining if the 98th percentile is greater than 3.71.

I can take a shot at fixing this if you want, but just wanted to double check that it's actually an issue (even if super minor) and I'm not missing something.

That's just a default point for the upper range of the colormap (i.e. the point at which the colormap saturates). It's true that the corresponding p value will be slightly different (0.00019 for a -log10(p) value and 0.0001 for a z statistic) but it should not really matter. Colormaps for zstats and -log10(p) values are already incommensurate because the nonlinearities are different.
In any case, surface_snapshots is just a way of quickly generating some summary files, not anything you should use to make figures for a publication.

Closing as there is no more surface_snapshots.py


PAM8403 filter

I have been playing with the frequency generator and the PAM8403. Do you add any low pass filtering  to the PAM8403 Class D before feeding the ultrasonic transducer?  Also, like other contributors I am having difficulty finding a 25kHz  transducer, do you believe 40kHz will work? Any changes to the design as a result?
thanks /liam

Personally, I didn't get very good results with a 40khz transducer. I haven't received my 25khz transducers yet so I can't really compare the two.
All I can say is that with a 3W amplifier at max volume I get a little less than 1 meter of range.
I can't say if my transducer is already running at more than 100db (which could cause permanent hearing loss btw) or if it's actually only running at 60db and I just need a bigger amplifier.
You might wanna read through this issue: https://github.com/y-x-c/wearable-microphone-jamming/issues/6
I'm also currently working on a simpler design that doesn't require an external signal generator. You can find the wiring diagram, parts list and code here: https://github.com/T-vK/alexa-jammer#how-to-use-the-mic-jammer


Update copyright to 2018 and new corporate form

The purpose of this pull request
Updated all copyright hints to 2018 and our new corporate form.
No changes in code besides the generation script for the documentation.
Checklist
Only one code change in the documentation generation script.
No actual application code was touched.

[ ] make test executed successfully
[ ] unit test provided
[ ] integration test provided
[ ] docs updated

👍


Follow upstream changes of libvirt-xml-go

Virtlet uses a patch to adjust libvirt-xml-go domain definition. But due to changes in libvirt-xml-go upstream it's no longer possible to apply the patch. With this commit we update the patch so that it now follows the upstream. Also, some changes were conflicting therefore we needed to modify the Virtlet code that relies on those changes.
Namely, virtlet's patch suggested following struct for providing bootcmd:
DomainCMDLine
|-> Args: []QemuArg
|-> Envs: []QemuEnv

but the upstream code now provides following struct:
DomainQEMUCommandline
|-> Args: []DomainQEMUCommandlineArg
|-> Envs: []DomainQEMUCommandlineEnv

So we had to enforce such naming also in Virtlet code.
Fixes https://github.com/Mirantis/virtlet/issues/375

This change is

I'm wondering how it's possible that this issue has occurred even if we're using glide. I mean, with Glide we have libvirt-go-xml locked at commit cc4025ea01eee7c73a7c75b4211b07125a8119ae where the patch should be possible to apply.
Anyway, I've prepared a PR where I both update the glide.yaml to use current latest commit and update the patch to fit on it. I'm looking forward to be hearing your opinion and possible explanation*!
* Note that the error occured on a clean development machine with all Docker images and containers purged and with latest Virtlet master checked out.

Hi, thanks for the PR. Concerning the explanation -- I still don't understand it myself, need to take a closer look. Concerning CI failure: we now have golden master tests, you need to run tests locally (in this case in pkg/libvirttools) and then include changed json files like pkg/libvirttools/TestContainerLifecycle.json in your commit.

I've added a new commit with golden master tests updated which turned Travis green. But I'm not sure why "circleCI" is failing, the error seems to be unrelated to the changes.

Review status: 0 of 15 files reviewed at latest revision, all discussions resolved, some commit checks failed.

Comments from Reviewable

@miha-plesko that's some flake caused by (perhaps) CirrOS server glitch, restarting the build

May I ask, out of curiosity, what is the rationale to use both, TravisCI and CircleCI? I'm not familiar with CircleCI, but a quick googling shows me the post that claims:
Travis CI and CircleCI are almost the same.

https://hackernoon.com/continuous-integration-circleci-vs-travis-ci-vs-jenkins-41a1c2bd95f5
Just being curious here, not trying to persuade you anything.

Review status: 0 of 15 files reviewed at latest revision, all discussions resolved, some commit checks broke.

Comments from Reviewable

The plan is to completely switch to CircleCI, because of Travis flackiness, especially on network bound operations.

@miha-plesko besides being generally less flaky for us, CircleCI provides secure ssh access to build VMs which is quite important at times. In case of Travis it's also possible because we requested debug mode from Travis, but it's insecure (anyone can connect to the VM after looking at the build log) and inconvenient (need to use curl to trigger it). We're going to revamp our image builds at some point so that images are built on our CI too -- docker cloud has it's own share of problems and we would like to stop using it, in which case we'll need to use some secrets, which makes Travis debug builds a non-option for us (secrets can be leaked).

@miha-plesko another thing we want to use in CircleCI is Workflows

Reviewed 4 of 4 files at r1, 11 of 11 files at r2.
Review status: all files reviewed at latest revision, all discussions resolved.

Comments from Reviewable

Review status: all files reviewed at latest revision, all discussions resolved.

Comments from Reviewable

@miha-plesko thanks for the PR, merged!


Add new rebus

Associated Issue: #14
Please get familiar with the contributing guide before submitting a PR.
Summary of Changes

Add a simple rebus

Pull Request Test Coverage Report for Build 48

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 89.231%

Totals

Change from base Build 47:
0.0%

Covered Lines:
87

Relevant Lines:
99

💛  - Coveralls

Awesome, thank you!


Contributing fixes to tour website

I found a few mistakes while going through the tour, but I don't see a way to report issues specific to the website, or a repo where I could submit a PR directly. You might consider making the website repo public and adding a link.
Cool demo though! 👍

@lblackstone Mmm, that's an interesting point, thanks for bringing it up. cc @abiogenesis-now, @bryanl.
In the meantime, do you mind sharing those mistakes?

Yeah certainly, wasn't sure if this was the right place for it.

https://ksonnet.io/tour/params - Under number 1, path should be environments/default/params.libsonnet
The list mentioned in https://ksonnet.io/tour/component-3 wasn't visible in my code window (top right), even after scrolling all the way down. I was able to see it after resizing that pane, so the scrollbar seems to be cutting off early.

Cut off

Resized pane

https://ksonnet.io/tour/jsonnet - The instructions At the end of the appDeployment definition, add .withReplicas(5) are probably not explicit enough. https://ksonnet.io/tour/modify-1 mentions that the user should remove the ; and paste the following, which is less ambiguous.
https://ksonnet.io/tour/modify-2 - Might want to provide a little explanation or a link to some docs for the mapContainers function. That bit of code will probably be confusing to a user that isn't familiar with functional programming.
https://ksonnet.io/tour/paramfiles - The quoted line
local params = std.extVar("__ksonnet/params").components["demo"];
doesn't exactly match the actual file text
local params = std.extVar("__ksonnet/params").components.demo;.

Thank you @lblackstone for noting these issues! We'll fix them ASAP, and also discuss either open-sourcing the ksonnet site itself, or having a clearer channel for feedback.

Forgot to close out this issue--these particular issues were fixed!


SANS DFIR Prague Summit (@sansforensics #DFIRSummitPrague) - 2018.10.1 - Prague, Czech Republic

thanks


Add ability to set portHeader in tomcat's server.xml

If UAA receives a request from a proxy/load balancer where a port mapping is happening, any redirect from UAA will pick the default port number (443 if https), which is the wrong port where that proxy/load balancer is listening to and doing the ssl termination. This commit updates the tomcat
server config file server.xml to get the port from X-Forwarded-Port if it is specified. This header should be set by the proxy/load balancer.

Is anyone looking at this please ?

I see you've rebased! Thanks.
But it looks like you haven't run the tests, they're failing. I see this step is missing from the README, I'll add it.
If you could run the test suite and ensure the tests pass that would be best. It's an rspec test suite so you'll need ruby. To run them:
gem install bundler
bundle install
bundle exec rake

Thanks @shamus, it should be OK now


6proxy is using a different http client for forwarding and feed status checks

Feed status checks were implemented with Jersey client with the SSL configuration done in dropwizard.  Forwarding is done with the stock http client however.  We need to bring them together so we can have one set of ssl configuration.

The jersey client is not a good fit for the existing proxy forwarding code.  We need a client that can provide us with an outputstream to write to as we are dealing with huge files.  Will raise a new issue to implement configurable ssl config for the existing HttpUrlConnection code.


Package Expat: Vulnerable outdated inofficial source

Hi!
It came to my attention that cmake/projects/Expat/hunter.cmake packages outdated version 2.1.0 from unofficial source https://github.com/alamaison/expat. Is there a chance that you could update it to 2.2.6 from official source https://github.com/libexpat/libexpat/releases ?
Thanks and best, Sebastian

PS: Noticed the -hunter.tar.gz bits in hunter.cmake only now. Should I ask for an update over at  alamaison/expat, first? Please advise. Thank you!

Is there a chance that you could update it to 2.2.6 from official source https://github.com/libexpat/libexpat/releases ?

As far as I can see the fork vs upstream difference is only one commit:

https://github.com/alamaison/expat/commit/35fe113c38e84a6297111894da889b948a944dab

If this change was already applied to upstream, then probably fork is no longer needed. Please check this instructions for updating package:

https://docs.hunter.sh/en/latest/creating-new/update.html

Closing inactive discussion.


Upgrade to latest reaction

fixing https://artsyproduct.atlassian.net/browse/AR-213

closing in favor of 2215


[move source language] Fix spec context bugs

Fixed #7387. Spec blocks should not be allowed in a spec context.
Fixed #7385. Expansion needs to check for module accesses after resolving lvalue names. Caused by alias refactor.
Some other unrelated formatting changes

Motivation

bugs are bad

Test Plan

new tests

:exclamation: Invalid command

Bors help and documentation

Bors is a Github App used to manage merging of PRs in order to ensure that CI is always green. It does so by maintaining a Merge Queue. Once a PR reaches the head of the Merge Queue it is rebased on top of the latest version of the PR's base-branch (generally master) and then triggers CI. If CI comes back green the PR is then merged into the base-branch. Regardless of the outcome, the next PR is the queue is then processed.
General

This project's Merge Queue can be found here.
This project requires PRs to be Reviewed and Approved before they can be queued for merging.
Before PR's can be merged they must be configured with "Allow edits from maintainers" enabled. This is needed for Bors to be able to update PR's in-place so that Github can properly recognize and mark them as "merged" once they've been merged into the upstream branch.

Commands
Bors actions can be triggered by posting a comment which includes a line of the form /<action>.

Command
Action
Description

Land
land, merge
attempt to land or merge a PR

Canary
canary, try
canary a PR by performing all checks without merging

Cancel
cancel, stop
stop an in-progress land

Cherry Pick
cherry-pick <target>
cherry-pick a PR into <target> branch

Priority
priority
set the priority level for a PR (high, normal, low)

Help
help, h
show this help message

Options
Options for Pull Requests are configured through the application of labels.

          Option
Description

Indicates that the PR is high-priority. When queued the PR will be placed at the head of the merge queue.

Indicates that the PR is low-priority. When queued the PR will be placed at the back of the merge queue.

Before merging the PR will be squashed down to a single commit, only retaining the commit message of the first commit in the PR.

/land

/land

@tnowacki :bulb: This PR is already queued for landing


Rename setupProxy.js to setupProxy.cjs

With the next major version of CRA releasing soon, we have the opportunity to introduce a low-impact breaking change in order to close https://github.com/facebook/create-react-app/issues/8046#issuecomment-947803258:

If you use  setupProxy.js, rename it to setupProxy.cjs.

This is an alternative to the arguably better but more complicated PR which has been stuck for a while https://github.com/facebook/create-react-app/pull/10228.

Any way to get a 👍🏻 or 👎🏻 on this idea?


[Auto-generated] Update dependencies

Update dependencies
Automatically created PR from ci/dependabot-updates.
The PR is based on the 'CI - Update dependencies PR' workflow in SINTEF/ci-cd.
To do

[ ] Check that the diff is sensible, and that tests and builds pass with the new dependency versions.
[ ] Make sure that the PR is squash merged, with a sensible commit message.

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

Comparison is base (765528a) 82.25% compared to head (f7bdb4f) 82.17%.

:exclamation: Your organization needs to install the Codecov GitHub app to enable full functionality.
Additional details and impacted files
@@            Coverage Diff             @@
##           master     #394      +/-   ##
==========================================
- Coverage   82.25%   82.17%   -0.08%
==========================================
  Files          44       44
  Lines        1257     1257
==========================================
- Hits         1034     1033       -1
- Misses        223      224       +1

Flag
Coverage Δ

linux
82.17% <ø> (ø)

linux-strategies
84.50% <ø> (ø)

windows
?

windows-strategies
?

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

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


Add web frontend plugin

Short Description:
This adds WebSocket support and removes the need to run python -m SimpleHTTPServer 8000.
Changes:

Move to Flask for web server.
Adds a logging event that passes two arguments, output with the line output and color with the output color.
Begin implementation of Flask-SocketIO event handlers to expose data to web frontend.

@OpenPoGo/maintainers

Is this ready to be reviewed?

:+1:

Works for me, but do we want it to be a commandline/config option? --web perhaps? In case people don't want to spend the resources on it if they won't use it?

no, I'm creating a new issue for this.

I'm going to approve this, but ultimately @wchill should merge it.
:+1:


Try header parsing even if protocol is missing

Fixes #2619

This patch is not perfect as you can evade by splitting the packets, ie putting the headers in a packet after the request line.
But I wrote it this way, so as to have a decision made right away in case of real HTTP 0.9


[BEAM-5356] Co group by key load test

This PR adds the CoGroupByKey test and refactores out some common code that's useful in all tests of this kind.
@aaltay could you take a look?
Follow this checklist to help us incorporate your contribution quickly and easily:

[x] 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

---

---
---
---

CC: @pabloem

This appears to be the most likely culprit for Nexmark tests all timing out.

Follow up at https://issues.apache.org/jira/browse/BEAM-6002


gradlew test fails with "Unresolved reference: HiltTestActivity"

Relevant log output:
> Task :app:compileReleaseUnitTestKotlin FAILED
e: /Users/donturner/Code/workspace-android/architecture-samples/app/src/sharedTest/java/com/example/android/architecture/blueprints/todoapp/addedittask/AddEditTaskScreenTest.kt: (32, 60): Unresolved reference: HiltTestActivity

This is because HiltTestActivity is defined only for the debug source set so is not available for release builds.

Discussed with Jose, agreed that the test task should only run testDebug (not testRelease)


Build Error (ember-cli 0.2.2 & ember-cli-sass)

Maybe I'm just tripping on something, but I'm seeing this error render in a brand new ember-cli 0.2.2 app with ember-cli-sass and ember-cli-bootstrap-sassy addons.
Build error

/home/brosas/ember/project-sputnik/tmp/tree_merger-tmp_dest_dir-j7QYq1tK.tmp/app/styles/bootstrap/_forms.scss, line 189

You may not @extend an outer selector from within @media.
You may only @extend selectors within the same directive.
From "@extend .input-sm" on line 48 of tmp/tree_merger-tmp_dest_dir-j7QYq1tK.tmp/app/styles/bootstrap/_input-groups.scss
Error: You may not @extend an outer selector from within @media.
You may only @extend selectors within the same directive.
From "@extend .input-sm" on line 48 of tmp/tree_merger-tmp_dest_dir-j7QYq1tK.tmp/app/styles/bootstrap/_input-groups.scss

    at options.error (/home/brosas/ember/project-sputnik/node_modules/ember-cli-sass/node_modules/broccoli-sass-source-maps/node_modules/node-sass/lib/index.js:261:32)

I also wonder if this is an upstream issue (broccoli-sass, or even just bootstrap's own syntax)

Yup. I probably shouldn't have closed a previous issue that explained what was happening here ... but long story short it's not an issue with ember-cli-bootstrap-sassy but rather with ember-cli-sass and the later beta's of the compiler. Although underlying it all is actually a Bootstrap issue I believe too but in the past the compiler was more robust in handling this issue.
The work-around is to use ember-cli-sass version 3.1.0.

Out of interest, did you install using npm install ... or ember install:addon ...?

You refer to https://github.com/lifegadget/ember-cli-bootstrap-sassy/issues/14 for more details.

oh. Thanks for that. I did ember install:addon.
I will swim upstream (ember-cli-sass, bootstrap...) :fish:


fix remount iso

What type of PR is this?

/kind bug
What this PR does / why we need it:

able to re-mount iso when perform import_iso.sh

Which issue(s) this PR fixes:

https://github.com/kubean-io/kubean/issues/574

Fixes #
Special notes for your reviewer:

the result of pr test:

/lgtm

/lgtm


Drop vendor dependencies from cis-operator

Drop vendor dir in cis-operator and bump the go version

Can release with  https://github.com/rancher/cis-operator/issues/81

This fix is only bumping go version and dropping vendor from cis-operator. Only tests needed is functional sanity testing, no new functionality added.

I tested on v2.5-head (4115dee) with dev-2.5 chart, it deployed successfully.
Tested on custom cluster (3 ubuntu aws nodes created by jenkins job).
Test took few minutes to start, probably because of requeuing.
Installed apps:

rancher-cis-benchmark:1.0.400-rc01
rancher-cis-benchmark-crd:1.0.400-rc01

Created deployment:

rancher/cis-operator:v1.0.4-rc1

~ kubectl logs -n cis-operator-system cis-operator-6bf6d4949f-pxcqt
time="2021-04-07T11:04:22Z" level=info msg="Starting CIS-Operator"
time="2021-04-07T11:04:22Z" level=info msg="ClusterProvider detected rke"
time="2021-04-07T11:04:22Z" level=info msg="KubernetesVersion detected v1.20.5"
time="2021-04-07T11:04:23Z" level=info msg="Starting cis.cattle.io/v1, Kind=ClusterScan controller"
time="2021-04-07T11:04:23Z" level=info msg="Starting /v1, Kind=ConfigMap controller"
time="2021-04-07T11:04:23Z" level=info msg="Starting /v1, Kind=Service controller"
time="2021-04-07T11:04:23Z" level=info msg="Starting /v1, Kind=Pod controller"
time="2021-04-07T11:04:23Z" level=info msg="Starting batch/v1, Kind=Job controller"
time="2021-04-07T11:11:58Z" level=info msg="Launching a new on demand Job for scan scan-tlc7l to run cis using profile rke-profile-permissive-1.6"
time="2021-04-07T11:11:58Z" level=error msg="error syncing 'scan-tlc7l': handler cis-operator: Retrying ClusterScan scan-tlc7l since got error: A rancher-cis-benchmark scan runner job is already running , requeuing"
time="2021-04-07T11:12:30Z" level=info msg="Marking ClusterScanConditionRunCompleted for scan: scan-tlc7l"
time="2021-04-07T11:12:30Z" level=info msg="Marking ClusterScanConditionComplete for scan: scan-tlc7l"
time="2021-04-07T11:12:30Z" level=info msg="Marking ClusterScanConditionAlerted for scan: scan-tlc7l"

Can you confirm the error is ok and can be ignored?
In that case I can close this card, everything else worked fine.
error syncing 'scan-tlc7l': handler cis-operator: Retrying ClusterScan scan-tlc7l since got error:
A rancher-cis-benchmark scan runner job is already running , requeuing

Can you confirm the error is ok and can be ignored?

Yes this is ok, it is not an issue. It is printed since another scan is already running, so this scan has to retry.
Will test on master-head after https://github.com/rancher/rancher/issues/31964 is fixed before closing

Blocked on https://github.com/rancher/rancher/issues/31964

Tracking master validations here - https://github.com/rancher/cis-operator/issues/91. closing this issue.


Update README.md to include HTTPS info

Follow up to https://github.com/near/near-wallet/pull/1786

Closing in favor of https://github.com/near/near-wallet/pull/1790 which resolves the recurring nags by providing stable dev certificates that won't change even when you destroy the .cache directory


Error Compiling

AzerothCore rev. f06f5a1334c4 2022-09-18
commit f06f5a1334c40e010abe47488bb2847f21f54696

Everything compiles fine without this in the mix.

There must be a conflict with another module. I just compiled this with clean source by itself and it went just fine.


Use DefaultBufferAllocators in Delimiters

Motivation:
Old implementation created new allocators on every call and never closed them
Modifications:

Replace BufferAllocator#onHeapUnpooled with DefaultBufferAllocators#onHeapAllocator

Result:
DefaultBufferAllocators is used. No unnecessary objects are created.

Thanks!


Backslash \true, \false and \null

This should be added too

Actually, not only those constants, but all.
https://3v4l.org/h3EvJ

https://github.com/nilportugues/php_backslasher/commit/4e1b8f9b9c43faae6233fb23a3a1876ca8b40de7


Error on MDN profile page: Sub menu not visible upon hover at viewport widths larger than 1024px

I noticed this issue on my profile page at /en-US/profiles/username where the sub menu column is only 50% visible as its content is overflowing the parent container.
Within the
 container, when I hover over <button id="advanced-menu">..</button> the submenu-column container appears but the second
 item isn't visible since the content overflows and does not provide a scroll option.
The scrolling mechanism is disabled for the underlying parent container
..
 since it has overflow: hidden; declared.
After I added overflow: auto or overflow-y:auto to .user-head the content from the dropdown menu could be viewed after scrolling down a bit to uncover the second dropdown item "Email Addresses".
Here is a screenshot of the issue, reproduced for viewports > 1024px.

The dropdown menu works fine for viewports smaller than 1024px. After the media query happens at 1024px and the layout shifts, both of the drop down buttons are visible but the second item is a bit cut off at the bottom.
Potential Fixes:

Remove overflow: hidden from .user-head class to allow the .submenu-column container to have a scrolling mechanism so both the
 items can be viewed/accessed.
OR Allow the .user-head container to grow and accommodate the space created by .submenu-column. That way each list item from the drop down will be visible when hovering the "settings" button in .user-cards. But then there will be some unwanted space under the profile picture since .user-head would indeed be increasing in height to make room for both the list items in the dropdown.

Note: I couldn't find a template issue for MDN Profiles at /en-US/Profiles/ so I created a blank issue. Thanks!

Issue moved to mdn/kuma #7620 via ZenHub


Enable simple use of Concourse inputs for om creds

I know we've had some slack discussion of this, and I'd like to get us on the same page.
We (the team known as NORM for reasons that I assume seemed sufficient at the time to the people naming it) are working to make it easy and repeatable to deploy Ops Manager with automation. Our approach so far has been to wrap calls to om in an executable of our own.
This is turning out to be a comparatively expensive approach, and I'd like to revisit our reasons for it.
A major factor is that we're interested in making invocations of om in CI and dojo environments as simple as possible.
When using Ops Manager in CI, we'd like to consume auth as an input. There are a variety of reasons that this makes sense for us. So, our wrapper currently uses a --auth-file argument. It takes the bit of yaml in that file and then shells out to om with the --target, --user, and --password flags set appropriately.
It would be much better for us, and eliminate tons of code, if om --auth-file was directly supported.
My understanding of how this has cashed out in previous discussions is that y'all are reluctant to add a feature that encourages users to put credentials on disk, backed by a general customer mandate to avoid writing creds to disk.
I am unaware of any model by which creds can be made available as an input in Concourse without hitting the disk. Inputs in Concourse are made available on the file system, case closed.
Not using inputs is also an option, of course - we could require that credentials be set as parameters in the Concourse Tasks, using om's existing support for env vars. However, this increases the complexity of using the Concourse tasks and requires credentials to be controlled by setting the pipeline, rather than by updating a resource. Similarly, we could add a bit of code in front of our invocations of om to export said env vars with values from a file. Again, though, this adds complexity to our tooling - we're also trying to make the Concourse tasks so bone simple that they're an effective model for those trying to use om in other CI systems.
So. Would y'all take a PR to add this, and if not, why not? If nothing else, I'm hoping we can get to a persistent/reference-able articulation of the positions on the table here.

Thanks for the responses, @zachgersh. I'm trying to have a legible conversation about the trade-offs here, so I'm going to try and structure some of the back-and-forth here. My overall theme is "it's good to support and afford not writing the creds to the disk, but creds will be on disk sometimes and it's wrong to make that so painful."
"Use Credhub"
On the topic of Credhub, and I hope to not litigate this much, it is not available in all contexts. Especially not in the context of bootstraps and dojos, both of which are core for us. I'm going to discuss everything else assuming that while Credhub (and LastPass, and Vault) are good options much of the time, it's also necessary to provide good solutions in their absence. I'll stipulate that it's important for any such solution to afford easy transition to using a credential management system.
Credhub does not work for our first targeted context.
"Use Resources"
There's two ways to use resources to solve this problem. The first is to have a resource that consumes the credential to accomplish work. This requires that resource consume its variables at set-pipeline time. (Please remember we're assuming the absence of Credhub or a similar service.)
The second is to have a resource fetch the credentials to be made available to a task. This allows creds to be updated without reconfiguring the pipeline. The resource interface is the filesystem. Credentials made available to tasks as resources are written to disk, where the task must read them. This is a feature we find important, especially in the presence of processes (again, please remember, not including in this specific case external credential management services) that may automatically generate, update, or rotate credentials.
Using Concourse Resources to handle credentials requires we either accept the pipeline must be set with each change, or requires writing them to disk.
"Use env vars"
There's two ways to use Env Vars to solve this problem in Concourse. One is to set the env vars as params on the task. This requires the pipeline be updated in order to change credentials. The second is to have some extra complexity that reads variables into the environment out of a file from an input. This could be shell, or it could be a binary the sole purpose of which is to work around a tool that's made painful choices.
Env vars as a solution either require us to accept the pipeline must be set with each change, or requires writing them to disk.
Some Final Notes

every time I say that the pipeline must be updated when credentials are, please recall that the most likely thing that will happen here is that a user will write the creds to their own disk and then load them with -l. While they can of course use -v, that becomes onerous very quickly as the number of creds grow, and actively works against the goal of easy-to-describe-and-repeat workflows for the purpose of dojos and bootstrapping systems.
similarly, a problem we've become very familiar with is that with productized CI, the parameters become an interface surface. Anywhere we can avoid having a giant list of parameters, that's a substantial win from the perspective of trying to support a legible CI approach as a product consumed outside the company.
we have considered what we are doing. We understand and agree with a preference to enable stronger and more audit-able patterns. We would be fine with setting an env-var that's sufficiently discouraging like ENABLE_CREDENTIALS_FROM_DISK_AGAINST_THE_WISHES_OF_THE_BEST_PRACTICE_LORDS=true
to enable this feature.
We are writing a tool to work around this because of its importance to our user's experience. We are qualified to make determinations about our users needs. Having a separate tool to handle reading a file is friction in the long-play of having om be the Schelling point around which users, internal and external, align to manage Ops Manager with automation.

user/pass. We have a future story for saml support.
Here's the tool. We're also using it to prototype other things we'd like in OM, and to manage some VM creation: https://github.com/pivotal-cf/pcf-installer
My desire to come back and litigate this again came out of two days of banging our heads against figuring out how to generically wrap calls to om so that we can give target and auth arguments from files. We got there, but it made me decide talking about this again was probably worth the engineering and product time from all involved.

Thanks @anEXPer.
Given the current state of the world, why not just have the yml file in your tool be something the "just uses env vars" to set those values on your environment and then have your tasks directly call om?
maybe there are a few flags like --skip-ssl-validation and --target that we could take as env vars as well to help with that workflow?

Thanks for having a look.
Using env vars for the call is a possible improvement for our current solution. Indeed, it's the approach I personally would have taken, as it mostly closely mimics what I'd do in the shell, presented with this problem.
The two flags you mention would be necessary additions to the set of env vars, and are probably a good idea regardless.
I regret the existence of our current solution, and would prefer not to spend too much effort discussing it. In addition to all the points I've already laid out, I'll add this:
## "Just wrap existing features"
Indeed, this is what we've chosen to do. A credible alternative is to fork the upstream recalcitrant.
There is a strong reason not to do this, and it's not maintenance, etc, at least not directly. Our environment contains several fragmented and failed attempts to solve this problem. "Pipelines for Ops Manager" is something lots of people are throwing lots of time at, and solutions and approaches have evolved over time. This is evidence that any given effort is at least somewhat likely to fail or be deprecated - the ecosystem is difficult, and I absolutely do not hold NORM as an exception to the factors that make it so. The risk mitigation is to push every possible improvement into a focal point (or "Schelling Point"), so that other fractured efforts, past, current and future, also stand to benefit, even if we ourselves don't crack it. om is my bet. Forking om would add confusion and illegibility to our efforts, and reduce the chance that this problem gets enduringly solved within our broader system.
This compelling reason to avoid forks is also the reason to avoid wrappers, but at least wrappers can make it very explicit what we are working around, and give us a place we can control from which to iterate on the problem, and offer some proof-of-work to demonstrate that we're invested in the problem without contributing as much to the incoherence of the space.
We want very simple, communicable, CI-system-portable patterns for initial automation of PCF environments. We want to solve this for onboarding, etc, but we also want to get to - and as a company, existentially require - continuous delivery to the data center. Getting to the latter requires cracking the former. Cracking the bootstapping problem is easier to the extent that simple, editable files and simple, visible commands do the work while people are becoming familiar with the system and are at a minimum level of general sophistication, conceptual understanding, and tooling access.
Wrappers and workarounds make problems solvable in software into people/coordination/communication problems, in an environment where that class of problems have been the specific reason for several failed efforts. Direct use and improvement of a visible tool makes long-term success more likely.

Agreed that ensuring creds are never written to disk is difficult / maybe impossible due to how concourse tasks and resource work. My opinion is that we should encourage users of our tools to use credentials stores like Credhub rather than checking secrets into Git repos. It's unfortunate that your users can't use Credhub, but I don't think that should change our position.
If we were to add support for environment variables for a few additional flags (e.g. OM_SKIP_SSL_VALIDATION), you could write a small bash helper function:
source ./helpers.sh
set_om_target "environment/config.json"
...
set_om_target() {
  export OM_USERNAME="$( jq -r .username $1 )"
  ...
}

I understand you would rather not have to do this, but would this be an acceptable middle ground? Long-term an om concourse resource would be ideal but I don't know when we'll find the time to prioritize that...

another idea: what if we added support for something like:
OM_CONFIG='{ "some": {"structured": "data", "for": "configuration", "and": "authentication"}}'

Please take a step back and think "why am I working so hard to not allow people to read creds from disk, where they are definitely going to be, in the face of so many reasonable arguments and customer needs?"
bosh create-env uses creds on disk. GCP cred downloads put creds on disk. Setting concourse pipelines with -l has creds on disk. "It is unfortunate that users have this problem, but I don't think we should change" is just... not an acceptable answer from a product perspective. Pure adherence to a dubious "best practice" is not a higher good than making the onramp to automated Ops Man management smooth - especially given that this is the onramp that can then take users towards stronger security practices.
We want to do what's right.
If it doesn't work, it's not the right thing.
If it's not kind, it doesn't work.
The structured data thing still requires us to do some incantation to export the structured data to an environment variable. I want to give bare om commands to people and have them work. The goal is to empower users to have direct fluency in the tools. Razor-sharp legibility! Ownership-grade understanding of their own automation! The harder we can pound that down to one layer of abstraction, the better off we are in terms of enabling our customers.

@anEXPer brought a quote from this article that's been going around recently to our attention:

And config files are great for declaring verbose configs, as well as being the most secure way to get secrets into a program. (Flags can be inspected by other users of the system, and env vars can easily be set and forgotten.)

@anEXPer, duly noted re: the comment above, but I'd still like to move forward with phase 1 first, personally:

Let's introduce environment variables for any flags that are missing them as an initial solution to this problem.

Doesn't look like we've done that yet for OM_TARGET or OM_SKIP_SSL_VALIDATION:
Usage: om [options] <command> [<args>]
  --client-id, -c            string  Client ID for the Ops Manager VM (not required for unauthenticated commands, $OM_CLIENT_ID)
  --client-secret, -s        string  Client Secret for the Ops Manager VM (not required for unauthenticated commands, $OM_CLIENT_SECRET)
  --connect-timeout, -o      int     timeout in seconds to make TCP connections (default: 5)
  --format, -f               string  Format to print as (options: table,json) (default: table)
  --help, -h                 bool    prints this usage information (default: false)
  --password, -p             string  admin password for the Ops Manager VM (not required for unauthenticated commands, $OM_PASSWORD)
  --request-timeout, -r      int     timeout in seconds for HTTP requests to Ops Manager (default: 1800)
  --skip-ssl-validation, -k  bool    skip ssl certificate validation during http requests (default: false)
  --target, -t               string  location of the Ops Manager VM
  --trace, -tr               bool    prints HTTP requests and response payloads
  --username, -u             string  admin username for the Ops Manager VM (not required for unauthenticated commands, $OM_USERNAME)
  --version, -v              bool    prints the om release version (default: false)

@mcwumbly Adding comments from slack thread.  The ask her is about having a common user experience using the installer as we are leveraging templated yml file for ways to pass all information into om.  With this design we have authorization and target information in the configuration file auth.yml.  There have been scenarios where using environment variable and changing contexts where you accidentally can target the wrong environment when we have engineers managing multiple environments.  Ideally this will primarily be ran in a containerized environment where these this isn't as much of a issue but wanting to make sure this is not a requirement.  So less about a debate of which mode is more secure but more about a common UX.  Also, the other scenario we have seen is where pairing with and using flags to set these values on cli(s) the information is commonly shared on the screen or if bash -x is enabled they are in logs of tools like concourse.  So there are scenarios where env vars/flags have potential to leak credentials vs files that need to be accessed and queried.  At end feels like there are compelling reasons to do both so would like to propose we enable the added of an auth file flag like what is proposed above but also allow for overriding the value that are provided by the flags/environment variable to allow for both options to be be leveraged and let the consumer determine which approach meets their ux/security needs.

I like the idea of an .omconfig of whatever we name the file that can set the following:

opsman host name (the target)
opsman user id / pwd or opsman clientId / secret
skip ssl validation
connect timeout
format of payload
request timeout
trace

So basically allow setting up all the pre-command options in this file that is in the current working directory but then flag / env variables would override these if specified.

could consider also later adding an om config command to view / mutate the config (a la git config). and that command could redact creds by default.

Our teams recently had a conversation about this. To summarize:

we've agreed to use om directly in our concourse tasks, rather than wrap the om commands (for the things that are om's job)
in order to do the above, om will optionally take environment files (so that om knows which OpsMan to talk to)
there will likely be additional things that we need to do in om, but this will handle the majority of the use cases at the moment.

We just submitted a new issue to address this. Happy to close this current issue.

closing this issue in favor of the new one. thanks @nbconklin !

For what it's worth, this thread caught my eye today.  I think it's fine to continue with adding support via a file given the current state of the world, but I did think it was worth sharing here.


Search performance issues (probably due to newly introduced index locking) after upgrading from 1.15.5 to 1.16.0

I upgraded to a version 1.16.0 and the Weaviate DB became very unresponsive, Aggregate as well as Get queries started to take up to tens of seconds (sometimes they timeout).
I went through the changes between 15.5 and 16.0 and I think the source of the problem is the newly introduced index locking in the BatchPutObjects function: https://github.com/semi-technologies/weaviate/pull/2288:
https://github.com/semi-technologies/weaviate/blob/d58eec498c4f720885165adae040dc40eca6bc36/adapters/repos/db/batch.go#L28-L31
In my opinion, it is not possible to concurrently insert items into the index and perform a search:
https://github.com/semi-technologies/weaviate/blob/a443443c80a00779c4b29e80b987906f2154493e/adapters/repos/db/search.go#L119-L129
But maybe I'm completely wrong, I'm not a Go programmer, so I'm just guessing.
In my case, I update Weaviate (relatively large batches) and at the same time the user performs a Search:

After downgrading to 15.5 everything runs OK again.
👉 My environment is the same as in this issue: https://github.com/semi-technologies/weaviate/issues/1897.

Thanks for the report, we'll look into it.

By the way, amazing investigation, this will save us a ton of time. And it really looks like you're on to something 🙏

Can reproduce. Here's a simple experiment with querying while importing.
v1.16.0 has occasional "blocked" queries:

v1.15.0 does not show this issue:

This should be fairly straight-forward to fix. Hope we can release v1.16.1 later today.

Fixed in #2352, about to be released in v1.16.1. I'll keep the issue open until the release is ready.

Thanks for the quick fix. I upgraded to version 1.16.1 and everything looks good so far. 👍

Thanks for the confirmation.


Error when using GeometryCollection

I have a geoJson object with a geometry typed GeometryCollection. If I try to calculate the extent it fails saying: [Error: Unknown Geometry Type]. Should this be supported?
var turf = require('turf');

var fc = {
    "type": "FeatureCollection",
    "features": [
        {
            "geometry": {
                "geometries": [
                    {
                        "coordinates": [
                            [
                                3.548000000000002,
                                -0.4170000000000038
                            ],
                            [
                                3.580000000000012,
                                -0.4170000000000038
                            ]
                        ],
                        "type": "LineString"
                    },
                    {
                        "coordinates": [
                            [
                                3.548000000000002,
                                -1.149080830487037e-14
                            ],
                            [
                                3.56700000000001,
                                -1.149080830487037e-14
                            ]
                        ],
                        "type": "LineString"
                    }
                ],
                "type": "GeometryCollection"
            },
            "type": "Feature",
            "properties": {
                "name": "M_Fixed:4835mm x 2420mm:4835mm x 2420mm:145788"
            }
        },
        {
            "geometry": {
                "geometries": [
                    {
                        "coordinates": [
                            [
                                5.251999999999997,
                                -17.382999999999996
                            ],
                            [
                                5.219999999999986,
                                -17.382999999999996
                            ]
                        ],
                        "type": "LineString"
                    },
                    {
                        "coordinates": [
                            [
                                5.251999999999997,
                                -17.79999999999999
                            ],
                            [
                                5.232999999999988,
                                -17.79999999999999
                            ]
                        ],
                        "type": "LineString"
                    }
                ],
                "type": "GeometryCollection"
            },
            "type": "Feature",
            "properties": {
                "name": "M_Fixed:4835mm x 2420mm:4835mm x 2420mm:146016"
            }
        }
    ]
}

var bbox = turf.extent(fc);

console.log(bbox);

What version is your turf dependency at? If you are using < 1.4.0, GeometryCollections won't work with extent / envelope

Works with current release.


[dart2wasm] Incorrect num.round compilation

Repro:
void main() {
  print((2.5).round());
}

JIT output: 3
dart2wasm output: 2

We currently use f64.nearest for round. Comparing the f64.nearest spec with Dart double.round documentation, I think the difference is f64.nearest returns the even number when the larger and smaller value are equally near, while Dart double.round round away from zero:

Else return the integral value that is nearest to ; if two values are equally near, return the even one.

Rounds away from zero when there is no closest integer

I also checked JIT/AOT implementation of double.round.

double.round implementation: https://github.com/dart-lang/sdk/blob/843cd8e43f7a7a0dc40eb7ccc86a8590f46da698/sdk/lib/_internal/vm/lib/double.dart#L196
roundToDouble is implemented in https://github.com/dart-lang/sdk/blob/843cd8e43f7a7a0dc40eb7ccc86a8590f46da698/runtime/lib/double.cc#L137
toInt is implemented in https://github.com/dart-lang/sdk/blob/843cd8e43f7a7a0dc40eb7ccc86a8590f46da698/runtime/vm/double_conversion.cc#L178-L193

For the case where the rounded double is representable as int64 this does (int64_t)round(d). I tried compiling that expression to Wasm with emcc (optimized) and it generated 82 lines of wat.
So we will probably want to implement this as a function rather than inlined.
It might be helpful if we could have C/C++ code (like AOT/JIT runtime system) that we can include with Wasm binaries.

We also don't implement this part:

Throws an UnsupportedError if this number is not finite (NaN or an infinity).

Throwing UnsupportedError was implemented in 9e168a2eab34.
Rounding was fixed with e65467c0562.


Remove all the legacy handlers

Description

This PR is implementation of  #566.
Closes #566.
Checklist

[x] Targeted PR against correct branch.
[x] Linked to Github issue with discussion and accepted design OR link to spec that describes this work.
[ ] Wrote unit tests.
[ ] Wrote integration tests (simulation & CLI).
[ ] Updated the documentation.
[ ] Added an entry to the CHANGELOG.md file.
[ ] Re-reviewed Files changed in the Github PR explorer.

Sim tests will be solve once this PR is out.
Currently, message still pass via legacy route since the current message doesn't implement ServiceMsg struct to get the method name for msgServiceRouter.Handler(), In addition, the struct will be deprecated in the next version.

Closing as it's referring to old code that is no longer there


Fix NPE in WriteBufferManager.addRecord

What changes were proposed in this pull request?

Fix NPE:
22/11/03 03:36:08 ERROR Executor: Exception in task 4.0 in stage 1.0 (TID 5)
java.lang.NullPointerException
	at org.apache.spark.shuffle.writer.WriteBufferManager.addRecord(WriteBufferManager.java:116)
	at org.apache.spark.shuffle.writer.RssShuffleWriter.write(RssShuffleWriter.java:152)
	at org.apache.spark.shuffle.ShuffleWriteProcessor.write(ShuffleWriteProcessor.scala:59)
	at org.apache.spark.scheduler.ShuffleMapTask.runTask(ShuffleMapTask.scala:99)
	at org.apache.spark.scheduler.ShuffleMapTask.runTask(ShuffleMapTask.scala:52)
	at org.apache.spark.scheduler.Task.run(Task.scala:131)
	at org.apache.spark.executor.Executor$TaskRunner.$anonfun$run$3(Executor.scala:497)
	at org.apache.spark.util.Utils$.tryWithSafeFinally(Utils.scala:1439)
	at org.apache.spark.executor.Executor$TaskRunner.run(Executor.scala:500)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
	at java.lang.Thread.run(Thread.java:748)

Why are the changes needed?

Does this PR introduce any user-facing change?

How was this patch tested?

Codecov Report

Merging #296 (fad6cd6) into master (0935af2) will decrease coverage by 0.01%.
The diff coverage is 100.00%.

@@             Coverage Diff              @@
##             master     #296      +/-   ##
============================================
- Coverage     60.10%   60.09%   -0.02%
  Complexity     1413     1413
============================================
  Files           175      175
  Lines          9082     9084       +2
  Branches        872      873       +1
============================================
  Hits           5459     5459
- Misses         3331     3332       +1
- Partials        292      293       +1

Impacted Files
Coverage Δ

...pache/spark/shuffle/writer/WriteBufferManager.java
83.82% <100.00%> (+0.24%)
:arrow_up:

...pache/hadoop/mapreduce/task/reduce/RssFetcher.java
89.39% <0.00%> (-1.52%)
:arrow_down:

:mega: We’re building smart automated test selection to slash your CI/CD build times. Learn more


Feature request: ability to run the script in non-interactive mode

Hi UncloSocks,
I love your script and would like to use it without interaction.
This enables automation and better handling of passwords.
I have made a pull request. Please consider it.
Kind regards,
Jan

Hey Jan,
I just added your requested feature to the main branch. You should now be able to run 'onyx.py' without any arguments and assess multiple routers in one go.
I opted to use a JSON file (target.json) where you can specify the following:

IP Address
Username
Password
Enable Secret/Password
[Optional] Cisco Device Type
[Optional] Cisco Version

I included sample entries on target.json. I've also added a new argument to trigger the interactive mode, using '-i' (--interactive).
Thank you, Jan.
Best regards.


Bug Report: Cant Press 2 Button

When I Add Double Notes To My Mods There Is A Problem With The Up And Right Key If I Press Them At The Same Time Nothing Happens It Doesn't Know If You Are Pressing Them Instead It Will Only Register The Right Key

Can you send a chart where this bug happens?


Use git ls-remote to fetch the latest tag

Using the GITHUB_TOKEN secret didn't work, since that access token
is scoped to the repository running the workflow. So, retrieving tags
from other repositories might still exceed the rate limit of GitHub's
Rest API.

Commit 925b78586b842d4d60c37d026d706a427f40d141 was also needed on Alpine-based containers to ensure the correct version sort order:
$ docker run -it alpine:3.11 sh -c "printf '2.0.3\nv4.0.3\n' | sort -V"
v4.0.3
2.0.3
$ docker run -it alpine:3.11 sh -c "\
    apk add coreutils && \
    printf '2.0.3\nv4.0.3\n' | sort -V"
2.0.3
v4.0.3

Otherwise, it would fail with:
mozjpeg version 4.0.3 has been superseded by 2.0.3

This is a much better approach, thanks Kleis.


Lazy loading

I tested your library and it works great for small lists, but when I try to load a significant amount of data (I tested it with 10,000 rows, the application crashes), which could be solved with a lazy load
Taking advantage of the question, is there any way to explicitly define to use table instead of list?

+1

Yes we need lazy load feature

Yes we need lazy load feature

null safety was merged


Improve handling of errors from worker/client threads

Retrieve exceptions from threads and report them
This ensures that there are workers alive in gather_candidates, and
handles exceptions from the worker threads (especially ServerError).
This will display the following error:

[deoplete] Error when loading source jedi: All workers have crashed.  First exception: Server exited with 1., stderr=[]. Ignoring.

With #177 it will display:

[[deoplete] Error when loading source jedi: All workers have crashed.  First exception: Server exited with 1., stderr=[
2018-07-06 02:26:27,470 ERROR    [30059] (deoplete.jedi.server) Server Exception.  Shutting down.
Traceback (most recent call last):
File "/home/user/.vim/plugged/deoplete-jedi/rplugin/python3/deoplete/sources/deoplete_jedi/server.py", line 225, in run
self._loop()
File "/home/user/.vim/plugged/deoplete-jedi/rplugin/python3/deoplete/sources/deoplete_jedi/server.py", line 159, in _loop
from jedi.evaluate.sys_path import _get_venv_sitepackages
ImportError: cannot import name '_get_venv_sitepackages'
]. Ignoring.

Merged.


adding 0 check -177

What happened
There is no value checking for parameter hbase.regionserver.logroll.multiplier when hbase.wal.provider is set to multiwal. This may cause improper calculations and crashes the system like division by 0.
Buggy code
In AbstractFSWAL.java, there is no value checking for logRollSize  and this variable is directly used while calculating the value of maxLogFiles in the method calculateMaxLogFiles. When logRollSize  is mistakenly set to 0, the code would cause division by 0 and throw ArithmeticException to crash the system.
     private int calculateMaxLogFiles(Configuration conf, long logRollSize) {
    Pair<Long, MemoryType> globalMemstoreSize = MemorySizeUtil.getGlobalMemStoreSize(conf);
    return (int) ((globalMemstoreSize.getFirst() * 2) / logRollSize);
  }

So we added checking for logRollSize.

Thanks for preparing PRs!
For those non-checking bugs, can you also check the value should not be negative? i.e var <= 0.

I left some comments on the other two PRs. The same applies here.


Re-enable Contribute button for v1.1 projects set to 100% reserved rate

_
Acceptance checklist

[x] I have evaluated the Approval Guidelines for this PR.
[x] I have tested this PR in all supported browsers.

perfect, thanks @johnnyd-eth! just one comment 😘