Unable to attach alb to nodes autoscaling group

Description
Using aws_autoscaling_attachment to attach alb target group arn with out autoscaling group for the nodes in the eks
only works on every other apply. The apply is successful but the attachment is removed on every other apply.

[x] ✋ I have searched the open/closed issues and my issue is not listed.

Versions

Module version [Required]: 4.6.2

Reproduction Code [Required]
module "eks_blueprints" {
  source = "github.com/aws-ia/terraform-aws-eks-blueprints?ref=v4.6.2"

  cluster_version    = "1.21"
  vpc_id             = var.vpc_id
  private_subnet_ids = var.subnet_ids
  cluster_name       = "somecluster-eks"

  self_managed_node_groups = {
    self_mg5 = {
      node_group_name    = "self_mg5"
      instance_type      = "m5.large"
      launch_template_os = "amazonlinux2eks"
      subnet_ids         = var.worker_subnet_ids
      public_ip          = true
      # This is an invalid argument at the moment
      # target_group_arns  = [var.aws_lb_target_group_arn]
  }
}

resource "aws_autoscaling_attachment" "asg_attachment_bar" {
  autoscaling_group_name = module.eks_blueprints.self_managed_node_group_autoscaling_groups[0]
  alb_target_group_arn   = var.aws_lb_target_group_arn
}

Expected behavior
Expect new nodes need be be part of our target group
The autoscaling group in the eks cluster needs to be aware of the target group so that new nodes are part of it
Actual behavior
When we first apply, the attachment is made and things work fine.
But in our subsequent apply, the eks_blueprint notices an attachment that isn't defined in the blueprint so it removes it.

@olibenni out of curiosity, what is your use-case to attach an ALB directly to the ASG this way?

Good question, I wanted to add a loadbalancer for the ArgoCD server, exposing the ArgoCD web ui.
Open to alternatives.

Gotcha. What you are trying to do will certainly work but its more common to use an Ingress configuration for such purposes. An Ingress controller such as AWS Load Balancer Controller makes it easier to manage Elastic Load Balancers for a Kubernetes cluster from within the cluster. Checkout our example which shows you can configure a complete Ingress path with a combination of ingress-nginx, LBC, external-dns. You can repurpose this example for serving of the ArgoCD UI.

Thanks for the tip! Will check this out better tomorrow (working on UTC time).

closed in #855


Remove dataproc from MakeSiteOnlyVcf

This pull request aims to address concerns regarding the dependency on Dataproc for the MakeSiteOnlyVcf stage of large cohort processing. See this Slack thread here.
Moving this job away from non-preemptible machines within Dataproc to pre-emptible machines in QoB raises concerns about the risk of process failure due to the potentially extended processing times for large datasets. Nonetheless, it seems possible to remove dataproc from this stage.
Note: An alternative is to move towards Hail's ability to conduct parallel exports during VCF merging that would help nullify the pre-emption issue. Although integrating parallel exports into the pipeline may be complex, it could significantly optimise the process and eliminate the need for Dataproc.
Update: @MattWellie has created a proof-of-concept for this approach #629 !

Note: The output Hail Tables of dataproc (dp) vs. no-dataproc (no-dp) are different. The AS_FS field appears to be different between dp and no-dp. At first it was thought that this was due to a stochastic nature of the FisherStrand variable however, when comparing two no-dp site_only.ht files (see screenshot below cell [4]) there appears to be no difference (the no_path_no_dp_site_only_ht was a result of a second no-dp test to test whether Path or str variables had to be passed - turns out str variables are required!).

I've included the full output of the comparison as a txt file
MakeSiteOnlyVcf_dp_vs_nodp_comparison.txt

Running again to check if same inputs generate different outputs. This is to check if the AS_FS field has a random component.
Two batches here:
https://batch.hail.populationgenomics.org.au/batches/438609/jobs/1

https://batch.hail.populationgenomics.org.au/batches/438612/jobs/1

The output of the above batches are the same, suggesting that the AS_FS field does not change due to randomness and the change in output detected is likely due to Dataproc and non-Dataproc usage.

(Note: both run2_no_dp_siteonly and run2_no_dp_siteonly2 use the same inputs, also note that these outputs are the same as gs://cpg-bioheart-test/large_cohort/3-0/no_dp_site_only.ht)

We are content with the current differences between using Dataproc and not using Dataproc. The difference seems to be due to the way math is happening (see Zulip chat here). This change can be merged


fix: address review comments on SplitIO

The type of this PR is: Bugfix

This PR resolves []
Description

Fix app crash
Use sessionState for isReady

PR Checklist (tick all before merging)

[ ] I have included screenshots or videos to illustrate my changes, or I have not changed anything that impacts the UI.
[ ] I have tested my changes on iOS and Android.
[ ] I have added tests/stories for my changes, or my changes don't require testing/stories, or I have included a link to a separate Jira ticket covering the tests.
[ ] I have added a feature flag, or my changes don't require a feature flag. (How do I add one?)
[ ] I have documented any follow-up work that this PR will require, or it does not require any.
[ ] I have added an app state migration, or my changes do not require one. (What are migrations?)
[ ] I have added a changelog entry below or my changes do not require one.

To the reviewers 👀

[ ] I would like at least one of the reviewers to run this PR on the simulator or device.

Changelog updates
Changelog updates

Cross-platform user-facing changes

iOS user-facing changes

Android user-facing changes

Dev changes

Warnings

:warning:

❌ An error occurred while validating your changelog, please make sure you provided a valid changelog.

  Generated by :no_entry_sign: dangerJS against 4b793821ac7d85c7eb5c034aa5e4ae228222f772

I'll check this one out locally now and play around.


v4.0.0

Fix issue while handling URLs

Coverage remained the same at 92.757% when pulling a93fca68c532419ef1cbabd51615742f0f03f789 on dev into 7e4b018aaaf68a49aa3f5d76f2bbb59bd0d8f3df on master.


Baoyuan Wang link is invalid

404 error

Thanks for letting me know - I talked to Baoyuan and he says that he does not have a working homepage temporarily. I will just let the link be it.


hover effects project added

Related Issue
hover effects project added
Closes: #1547
Describe the changes you've made
A clear and concise description of what you have done to successfully close your assigned issue. Any new files? or anything you feel to let us know!
Describe if there is any unusual behaviour of your code(Write NA if there isn't)
NA
Checklist:

[x ] My code follows the style guidelines of this project.
[x ] I have performed a self-review of my own code.
[ x] I have commented my code, particularly in hard-to-understand areas.
[ x] I have made corresponding changes to the documentation.
[ x] New and existing unit tests pass locally with my changes.

Screenshots
Put any screenshot(s) of the project here.

https://user-images.githubusercontent.com/67833077/119250657-32c74580-bbbf-11eb-89b3-5198c6271579.mp4

@Vishal-raj-1 @ridsuteri Sir Please review my PR .

@Vishal-raj-1 @ridsuteri Sir Please review my  PR .


fix: Update default VM size micro->medium

Looks fine, this is the necessary size for the ec2 instance at the moment. The Terraform check failed because I hadn't updated the version in .github/workflows/terraform.yaml but I've done that now and it's on the main branch. I don't know why the terraform-docs check failed, i'll take a look.


Getting "partial message" error on http_client_async

Hi,
I modified the example code in http_client_async to create multiple sessions and download multiple files.
So on main(), I did something like:
// Launch the asynchronous operation
for (int n=0; n<10; ++n)
{
  std::ostringstream os;
  os << target
     << "test"
     << n+1
     << "_20M.csv";
  std::make_shared<session>(ioc)->run(host, port, os.str().c_str(), version);
}

Each one of the sessions then start to download "some_target/testN_20M.csv". However, some, if not all, of the sessions end with an error: "read: partial message". Hope you can help.

Hi @esamson33 , can you link to a github repo containing the complete program you have modified, including build instructions?
Just to be sure we're on the same page.

@madmongo1 please see this link

I suspected that the timeout set before the last operation was still effective even on subsequent operations. I tried tcp_stream::expires_never() prior to reading the header and the partial message error disappears.

If there was a timeout you should get beast::error::timeout not partial_message

I reduced the timeout to 10 secs to make sure that it gets hit. Without tcp_stream::expires_never() I always get partial_message and no beast::error::timeout.
A sample run below:
96881,30001,32660,91145,72555,1591,34374,7682,25read body: read bodypartial message
: partial message
read body: partial message
read body: partial message
read body: partial message
read body: partial message
read body: partial message

real	0m10.049s
user	0m3.189s
sys	0m2.615s

@madmongo1 if correct, this is a bug

👀

Unable to replicate:
https://github.com/test-scenarios/http_client_async
command line used:
$ ./http_client_async localhost 8000 / 2>&1 | tr -d 'aa'

No error output produced.

Why do you get this output: 96881,30001,32660,91145,72555,1591,34374,7682 while I get the content of the test files?

@madmongo1 yes that's from the sample data

@madmongo1 using the server included I needed to reduce the timeout to 1sec to make sure it kicks in and also comment out tcp_stream::expires_never() to bring out at least a few partial message errors.

@esamson33
OK, it's starting to make sense now.
The timeout represents the maximum time allowed to send the request and receive the complete response. I.e. each intermediate async_read_some does not reset the timer. The larger the payload and slower the network, the more likely a timeout will occur.
I would say that the error you are seeing is because the timeout is ocurring.
Vinnie and I have discussed a different kind of basic_stream, in which a timeout can be applied to each underlying async_read_some. i.e. it would detect an unresponsive peer rather than representing an overall time cap on receiving the document.
Is that more what you are looking for?

> I would say that the error you are seeing is because the timeout is interrupting the read.
Right. And the way I addressed is to reset the timeout using tcp_stream::expires_never().
Running $ ./build/http_client_async localhost 8000 / 2>&1 | grep -E "partial|timeout" | tr -d 'aa', I get
red body: prtil messge
red heder: The socket ws closed due to  timeout
red heder: The socket ws closed due to  timeout
red heder: The socket ws closed due to  timeout
red heder: The socket ws closed due to  timeout
red heder: The socket ws closed due to  timeout
red heder: The socket ws closed due to  timeout
red heder: red bodyred heder: The socket ws closed due to  timeout
The socket ws closed due to  timeout
: prtil messge

where 2 of 10 are "partial message".
On the chance that the reading of the responses reach the body and the timeout kicks in, the error becomes "partial message" instead of the more obvious "timeout". Still makes sense though but not obvious.
With a 30 secs timeout, the files hosted on a network, and with sizes of 2G each, I see errors to be all partial message rather than timeout.

I would say that the error you are seeing is because the timeout is interrupting the read.

Then the error should be error::timeout not partial_message. The partial_message is only returned when the end-of-file is reached on the stream, clearly not happening here.

Understood.
The error is converted here:
https://github.com/boostorg/beast/blob/0b68ed651b6bc7b681cf440ed6a220089e21473f/include/boost/beast/http/impl/read.hpp#L57
EOF is left unchanged but any other error is converted to partial_message.
@vinniefalco Was this the intent?

@esamson33
OK, we have agreement that the behaviour you're seeing is a bug.
I'll need to think about what the correct behaviour should be.

ping

Has the problem been resolved?

Not through beast, but you could do that yourself by declaring your own timer and setting it.

Got it. Thank you!


chore: Generate MMHOOK DLLs at runtime

Look into how we can generate the MMHOOK publicized assemblies at runtime, when Jotunn is loaded. This way, we won't need to ship the DLLs with the library, and they'll always be up-to-date for users. Additionally, it should be less cumbersome for users to deal with installing our library if there's less DLLs for them to fetch,

Hookgen is exactly the process of generating hooks at runtime. We can not do better than this, nor fody weave it into the plugin as the generated dll's are a dependency of our plugin, and must be run during patcher init rather than plugin init.
However, we can pre-package MMHOOK folder alongside our plugin to ensure that at the very least the user has a version of mmhook, even if it is not the latest. We would also keep the hookgen dependency and folder structure in this scenario such that hookgen will overwrite any stale dll's during init.
One possible issue I can see with this, is there will exist some users who benefit from this implementation because they were lazy/ignorant of the hookgen dependency, who will continue running using MMHOOK's without a hookgen in place, incorrectly assuming it will work forever. It will not. Eventually method signatures will change, and eventually one which a plugin depends on will change, and then suddenly "the update broke the game! Mr. plugin dev please fix your plugin, it doesn't work!".
The end result of this will that plugin dev's will potentially take the brunt of feedback and bug reports instead of either us or mmhook. When these issues arrise, they will no longer be our issues to fix.

Resolution is to package HookGen side by side with lib to allow for greater interoperability with few perceived downsides. Issue closed.


Add palette-from-image

[ ] Project URL:
[ ] Update contents.json instead of README
[ ] One project per pull request
[ ] Screenshot included
[ ] Avoid iOS or open-source in description as it is assumed
[ ] Use this commit title format if applicable: Add app-name by @github-username
[ ] Use approved format for your entry

Thank you @chuongtrh ! Could you make a small change I requested and resolve the conflict 🙏


Summary
Add new chain IotaEVM
Chain ID
8822
Chain detail URL
https://chainlist.org/chain/8822
RPC URL
https://json-rpc.evm.iotaledger.net
Blockscout Client URL
https://iota-evm.blockscout.com/graphiql
Etherscan Client URL
No response
Etherscan Client API URL
No response
Version
1.3.0
Address (Master copy)
0x69f4D1788e39c87893C980c06EdF4b7f686e2938
Deployment Tx hash (Master copy)
0xe3e081b942f7c83a29c329d95ac93531a10861eb582343aefaf53db2392b3ccd
Block explorer URL (Master copy)
https://iota-evm.blockscout.com/address/0x69f4D1788e39c87893C980c06EdF4b7f686e2938
Address (Proxy factory)
0xC22834581EbC8527d974F8a1c97E1bEA4EF910BC
Deployment Tx hash (Proxy factory)
0x0c1279068b9a46e946e9b9d39a8973490ad7c49af3bb506e83132687d124402c
Block explorer URL (Proxy factory)
https://iota-evm.blockscout.com/address/0xC22834581EbC8527d974F8a1c97E1bEA4EF910BC

@Vaphen The blockscout client url is not correct, please update the issue with the correct  https://iota-evm.blockscout.com/graphiql. Thanks

@falvaradorodriguez Done!

/execute


Description doesn't fit to the json snippet.

"autoRenewTimeout" refers to the Functions 1.x version while in 2.x this property is named "maxAutoRenewDuration".
Name used in the json snippet is valid, while in the description not.

Thanks, @Mikoleusz for the contribution!
#sign-off


new shape Snkey

It would be nice to have https://github.com/d3/d3-sankey shape

Take a look here and the linked codesandboxes. https://github.com/hshoff/vx/issues/190


View remapping doesn't work

I'm trying to implemented nested Render Textures.
As I develop 2d engine, we have a very basic scene graph. Our views ids are splitted this way:
We work with 0...189 for FBO rendering and 190...255 for backbuffer rendering.
My renderer is stack-based, so every-time I draw a new level of render texture, I simply push currentViewID into stack, create new view (+1 from previous) and render it.
So pseudo-code would be:
renderer.beginRenderTexture(self)
self.sortAllChildren()
for child in children {
    child.visit(renderer, parentTransform: _projection)
}
renderer.endRenderTexture()
self.draw(renderer, transform: transform)

The idea is that we submit all children to current view and then submit the node itself to the parent one.
For RT (0) that has two children RT (1 and 2) pipieline is like this:
push RT, currentView is: 0
  Draw **GREEN** geometry into 0
  push RT, currentView is: 1
    Draw **WHITE** geometry into 1
  pop RT, currentView is 0
  Render texture 1 will draw itself into 0
  push RT, currentView is: 2
    Draw **WHITE** geometry into 2
  pop RT, currentView is 0
  Render texture 2 will draw itself into 0
pop RT, currentView is 190
Render texture 0 will draw itself into 190

Important details: view 0 has red clear color and draw green geometry, 1 and 2 has gray clear color and white geometry.
After all draw calls are submitted, I'm trying to get views drawn in this order: 1 2 0. As we need to draw children first, then draw result into parent.
All views are sequental.
To achieve this effect, I'm trying two different maps:

1 2 0 -- basically new remap order
2 0 1 -- this is the map, where (firstViewID + index) == newViewID
What really happens:

1 2 0
We can see that view order is correct. This gets drawn first:

Then gray (child FBO) view recieves all the parent draw calls: green (parent geometry) and two FBO contents draw calls. This is incorrect.

Then red (parent FBO) recieves white (child geometry), which is incorrect

Conclusion: view order is correct, but draw calls called in wrong sequence
2 0 1
As we can see view order is incorrect now.  First, this gets drawn:
So white (child geometry) gets drawn into gray (child) FBO, seems correct so far

Then white (child geometry) gets drawn into red (parent) FBO, this is incorrect

Then gray (child) FBO recieves all the draw calls, that are meant to be in parent one. It gets green (parent geometry) and two draw calls with FBO contents:

Conclusion: view order is incorrect, but draw calls are called in correct order

I just added it here, and it works as expected with GL:
https://github.com/bkaradzic/bgfx/commit/334d5358285026926b2c3c4b955e835dff4121b7
My guess is that this is Metal specific?

Probably, I also think this is related to Metal somehow. I can't test any other backend yet.

I bet the second map is correct, according to your example, so basically FBOs are not being swapped.

09-hdr example wouldn't work if something is wrong. I intentionally picked first and last pass and swapped them. In 09-hdr example if skybox rendered last you wouldn't see bunny.

I will take a look at the Metal implementation

I looked at it, and it seems everything works correctly.

@bkaradzic
I double checked if it's me or not. This is what happens If comment single line - setting new map.

So basically everything works correct, but this is what I am trying to avoid. Parent draws first, hence it draws two nested RT with one frame lag. Once I do remap, draw calls are remapped correctly but FBOs are not.

The best way to resolve this is if you believe there is a bug to reproduce it in examples, that way I can look at it, and figure out is it a bug or incorrect use.
Or just create simple example from scratch that reproduces the bug, and I could debug it... These screenshots from your app are not really useful since it might be bug in your code too.

Uhhh, I didn't use C++ for quite a while.. Okay, I will try.

You can make it inside 25-c99 example: https://github.com/bkaradzic/bgfx/blob/master/examples/25-c99/helloworld.c

@bkaradzic I see black screen in 09-hdr with this view remap setup. (I got back to default order and forced Metal backend) https://github.com/s1ddok/bgfx/commit/eaa926611834567c727e0579f8a88638de8f502d

I have tried 09-hdr from @bkaradzic repo and it works on iOS/OSX for me with metal renderer.
@s1ddok's example doesn't work on Metal and! OpenGL renderer on my Mac. (Black screen)
I have tried a different order ( uint8_t remap[] = { 1, 2, 0, 3, 4, 5, 6, 7, 8, 9 }; )
This is not correct either, but the result is the same on Metal and OpenGL.

I reprod it...

Fixed now


bpf: Enforce symmetric routing for endpoints with parent interfaces

In certain setups, such as AWS ENI, it is expected that non-masqueraded
traffic from an endpoint always egresses via a designated interface.
We call this interface its parent interface.
Normally, this is taken care of by routes and assumptions. We have
routes that direct traffic to the parent interface, for pod-to-pod and
CIDRs in the non-masquerade list.
However, there are cases such as when the AWS NLB is configured to run
in "target type: ip" (balance traffic directly to pod IPs) and
with the preserve_client_ip option enabled (do not SNAT the source IP)
that the route based approach breaks down. In this case, Cilium sees
world traffic directly to pod IPs, which normally can't happen, except
for the NLB transparent traffic modifications. For ingress traffic
this is not an issue, but return traffic does not hit any of the routes
that would direct it to the parent interface. Nor can we make a route
since every possible public IP can be a source.
As a fix, this PR adds logic to the snat/fwd path to check if we
see reply traffic from an endpoint with a parent interface egressing out
of any interface other than the parent interface. If we do we redirect
the traffic to the parent interface. The location of this logic is
chosen so that its compatible with proxied traffic as well.

/test

/test

/test

/test

fyi, looks like the PR picked up a conflict that needs rebasing.

/test

/test


unexpected states when parsing information for tally lights

I'm submitting a ...
[ ] bug report
[ ] feature request
[ ] question about the decisions made in the repository
[x] question about how to use this project

Summary
I am building a dmx tally light solution for atem switchers. When I just cut between two cameras there is one state transmitted which has previous preview as program so preview and program are identical for one state. This results in the previous program tally switching off before switching to green again. (flickering)
In this example I am only showing camera 1 tally information to make it easier to understand:

Is there any way to catch this case or directly extract tally light information for example for one input with the atem-connection library?
Thank you all in advance for your help and this awesome open source library!
Kind regards
@lukas-runge

Other information
To get the Tally light information I am parsing the state object to extract tally information out of it. (using listVisibleInputs() on the switcher object) and some ways to prevent weird states messing up my readout.

Here is my current code 🔽

image created with Polacode for Visual Studio Code

copy/paste code
this.switcher.on('stateChanged', (state: any) => {
    // State does not always contain ME video data; Return if necessary data is missing.
    if(!state || !state.video || !state.video.ME || !state.video.ME[0])
        return;

    // There is some weird state change after a transition that I am able to catch with my glitch variable here
    if (state.video.ME[0].inTransition) {
        state.video.ME[0].transitionPosition == 0 || state.video.ME[0].transitionPosition == 10000 ? glitch = true : null;
    } else {
        glitch = false;
    }

    // checking out current preview and program information
    let new_preview = this.switcher.listVisibleInputs("preview", 0)
    let new_program = this.switcher.listVisibleInputs("program", 0)

    // comparing to old preview information, updating if changed
    if (_.isEqual(this.preview, new_preview) == false && glitch == false) {
        console.log(`PREVIEW: ${new_preview}`)
        this.preview = new_preview
        update_now = true
    }

    // comparing to old program information, updating if changed
    if (_.isEqual(this.program, new_program) == false && glitch == false) {
        console.log(`PROGRAM: ${new_program}`)
        this.program = new_program
        update_now = true
    }

    // notifing tallys ("Inputs") if there are changes
    if (update_now == true) {
        this.notifyInputs();
        update_now = false
    }
});

I think this is a known limitation of the v1 releases. The way we parse commands from the atem means that we emit a stateChanged for every single thing it sends, even thought they are batched. This will be better in v2, but there are some bugs there that are blocking its release (eg #76)
As a workaround, you could try adding a simple debounce to stateChanged, so that you wait for a gap in commands before doing this, but I dont know if that will play well with transitions..
I dont have any better ideas right now, not without modifying the library to expose some more data

Hi @Julusian,
thank you for your ultra fast response.
Your idea sounds like a solution that would work for me. I should be able to catch the case in which i am dealing with a transition to only apply the function in the other cases. 👌 I am not that experienced in coding tho, so i'll have to first learn how to write a debounce function in typescript. But I'll try to do my best. Thank you very much for your assessment on my challenge.
Other than that: When do you think we can expect v2?
Kind regards
@lukas-runge

There is no concrete timescale on v2. It is waiting for either me to have the time and motivation to look into the issues which were reported, or for nrk to want to upgrade to it and provide the time needed.
It does mostly work, I think it is just some bugs in edge case conditions, or functionality used less often

Appreciate the work and time you guys are putting into this. Thank you very much! I would love to test v2 to see if it works without issues in my usecase. So I could just clone the current state of the master branch, build it and copy it into the node_modules folder to test v2 myself, right?
Kind regards
@lukas-runge

The easiest way to install it is via npm install atem-connection@nightly
There are some small api differences, but as you are using typescript, it should report anything

Awesome! Just tried it with the nightly build. Works like a charm in my usecase 😎 Even enabled me to make my code much simpler cuz' all of the weired in between states are gone now 😍👌

Thank you @Julusian your fast help on my challenge and huge thanks to all maintainers of this library for enabling me to do my project at all - thank you guys!
Kind regards
@lukas-runge
Here is my new code 🔽

image created with Polacode for Visual Studio Code

copy/paste code
constructor (ip: string) {
    this.ip = ip
    this.switcher = new AtemSwitcher()

    this.switcher.on('connected', (state: any) => {
        console.log(`Connected to ${this.ip}.`);

        let update_now: boolean = true;
        update_now = this.parseNewState(update_now)

        this.switcher.on('stateChanged', (state: any) => {
            update_now = this.parseNewState(update_now)
        });

    })

    this.switcher.on('disconnected', () => {
        console.log(`Disconnected from ${this.ip}.`);
        this.connect();
    })

}

parseNewState(update_now: boolean):boolean {

    // checking out current preview and program information
    let new_preview = this.switcher.listVisibleInputs("preview", 0)
    let new_program = this.switcher.listVisibleInputs("program", 0)

    // comparing to old preview information, updating if changed
    if (_.isEqual(this.preview, new_preview) == false) {
        console.log(`PREVIEW: ${new_preview}`)
        this.preview = new_preview
        update_now = true
    }

    // comparing to old program information, updating if changed
    if (_.isEqual(this.program, new_program) == false) {
        console.log(`PROGRAM: ${new_program}`)
        this.program = new_program
        update_now = true
    }

    // notifing tallys ("Inputs") if there are changes
    if (update_now == true) {
        this.notifyInputs();
        update_now = false
    }

    // return update_now: boolean to track if
    // information has changed compared to previous state
    return update_now
}

connect () {
    console.log(`Connecting to ${this.ip}...`);
    this.switcher.connect(this.ip)
}

Hi everyone,
finally finished & published my tally light tool 🎉
Thank you @Julusian for your fast help on during development and huge thanks to all maintainers of this library for enabling me to do my project at all - thank you guys!
Now I am very excited to see how people are going to use my new atem-tools library:
https://www.npmjs.com/package/atem-tools
Kind regards
@lukas-runge


Allowing multiple font sizes to resize from/to?

I've read some of your other comments on this subject but I thought i would ask. How difficult would it be to add a second parameter to the mixin?
this isn't exactly like the mobile first suggestion someone else mentioned, this would just allow you to control you min/max sizes for each element you're trying to style.
For example:
@include font-size(24px,135px);
The first argument is for the minimum breakpoint's font size (being able to configure this like the max would be awesome) and the 2nd argument is for the maximum breakpoint's font size (what you already have, ie, 1200px).
Right now i'm just overriding the @include font-size(135px); with a mobile only mixin i use:
.h2 {
    @include font-size(135px);

    @include mobile-only {
        font-size: 43px;
    }

}
Kinda dirty but it works well enought. It breaks the responsive nature of RFS on mobile but it's a compromise I'm willing to live with for now. Just checking to see if you have a better solution.

The purpose of RFS is to automate the rescaling. If this feature is added, some people will use it, while others stick to the way RFS is meant to work.
I don't want people will start using the min/max way over the automated way just because it feels more natural to what they are used to work with.

So what alternatives do we have?

RFS is supported within media queries, so with the example above you could do something like:

.h2 {
    @include font-size(135px);

    @include mobile-only {
	    @include font-size(43px);
    }
}

Watch out: v9 switched to a mobile-first approach using min-width instead of max-width, so you might need to switch the mode to "max-media-query"
https://github.com/twbs/rfs/blob/bad76be6ab73e476b6f91199405362e17bac21da/scss.scss#L37-L38

RFS is configurable, by tweaking the factor you can achieve the rescaling you want
If none of these solutions fits your needs, you might have a look at this article which uses a mixin what does exactly what you describe: https://css-tricks.com/snippets/css/fluid-typography/#article-header-id-0

@MartijnCuppens thanks for the response! I like the min-width change, had to disable bootstraps RFS import and use your standalone version.
I've tried your alternative solution, but it didnt do what i had hoped it would.
I've also tried tweaking the factor option but since im going from a huge font like 135px down to a small font such as 43 i couldn't get it to go down that low automatically even with a factor of 1000.
i'll just stick to my hacky way for now.. all the designers i work with insist i have exact font sizes on mobile so all my attempts to get factor all i could get was something like 60ish px. Your mixin will save me tons of time sizing out the tablet views.
thanks for your work on this!


Prep 1.0.0rc2

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

Project coverage is 100.00%. Comparing base (c12426a) to head (023d4d5).

:white_check_mark: All tests successful. No failed tests found.
Additional details and impacted files
@@            Coverage Diff            @@
##              main       #28   +/-   ##
=========================================
  Coverage   100.00%   100.00%
=========================================
  Files            4         4
  Lines          251       251
  Branches        17        17
=========================================
  Hits           251       251

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


NTR - metabolism: [S-adenosyl-L-methionine:S-adenosyl-L-homocysteine antiporter activity]

Please provide as much information as you can:

Suggested term label:
S-adenosyl-L-methionine:S-adenosyl-L-homocysteine antiporter activity

ChEBI ID and label of the substance:
CHEBI:57856
CHEBI:59789

Definition (free text)
Catalysis of the reaction: S-adenosyl-L-homocysteine(out) + S-adenosyl-L-methionine(in) = S-adenosyl-L-homocysteine(in) + S-adenosyl-L-methionine(out).

Reference, in format PMID:#######
PubMed:14674884
PMID:34375635

Gene product name and ID to be annotated to this term

Parent term(s)
GO:0015297  antiporter activity
GO:0000095 S-adenosyl-L-methionine transmembrane transporter activity

Synonym(s) (please specify, EXACT, BROAD, NARROW or RELATED)
Other than the standard synonyms below

Children terms (if applicable) Should any existing terms that should be moved underneath this new proposed term?

Cross-references

MetaCyc or KEGG pathways, can also provide Wikipedia or other links.
Not yet public:
Reaction=S-adenosyl-L-homocysteine(out) + S-adenosyl-L-methionine(in) = S-adenosyl-L-homocysteine(in) + S-adenosyl-L-methionine(out) [Rhea:75479]

Any other information

FOR ONTOLOGY EDITOR

Logical definition

substance metabolic process:
'metabolic process'
and ('has primary input or output' some [substance]

substance biosynthetic process:
'biosynthetic process'
and ('has primary output' some [substance].

substance catabolic process:
'catabolic process'
and ('has primary output' some [substance]

Standard synonyms

substance metabolic process:

EXACT: substance metabolism

substance biosynthetic process:

EXACT: substance anabolism

EXACT: substance biosynthesis

EXACT: substance formation

EXACT: substance synthesis

substance catabolic process:

EXACT: substance breakdown

EXACT: substance catabolism

EXACT: substance degradation

Added with logical def
'antiporter activity'
and ('has primary input' some 'S-adenosyl-L-homocysteine zwitterion')
and ('has primary input' some 'S-adenosyl-L-methionine zwitterion')
For db_xrefs I added Rhea:75479
If you can provide KEGG, MetaCyc etc I will add them later.

Hi Val, I could not find them.


Travis/Build: Remove ccache from depends and Travis builds on Ubuntu 18.04 and Docker

Major changes in this PR:

Remove ccache from the depends and have it use the OS's ccache if installed
Update Travis builds to use Ubuntu 18.04 and have them run on Docker
Big cleanup to the Travis file to make it easier to read and understand

Travis builds have successfully passed, will merge.


Test syft.js main file

The syft.js project could use a lot of help refining our current test suite.
We need to test the syft.js file as it currently stands. This issue is a bit non-descript, so if you're interested in helping to write tests, please contact me (@cereallarceny) on Slack and I'll get you started!

I would like to contribute to this issue.

Main file is going to be changed to line up with federated learning roadmap. I think it's better to wait a bit on this one

Yes, let's wait for a few more weeks.
On Tue, Feb 25, 2020 at 8:48 PM Vova Manannikov<EMAIL_ADDRESS>wrote:

Main file is going to be changed to line up with federated learning
roadmap. I think it's better to wait a bit on this one
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/OpenMined/syft.js/issues/60?email_source=notifications&email_token=AAJ44CTVAPHHEKLTQNJDDBLREV7YBA5CNFSM4JV5TFE2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEM5OBOA#issuecomment-591061176,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAJ44CS22Z2ZFXTYOVXT2QDREV7YBANCNFSM4JV5TFEQ
.

I like to contribute to this issue.

We're waiting until the API has matured. Please wait to work on this issue until at least May.


Squished Aspect Ratio

I created an image that's 256x128 pixels. The logo was composed of mainly a big circle. When booting up, it's squished in the vertical or expanded in the horizontal.
These different settings in config.txt were used: resolution: 0x0, -1x-1 and 256x128. None of them produce the image with the proper aspect ratio for the circle logo.
I've tried splash.bmp images with larger dimensions like 600x600 and the default Windows logo showed instead.
What is the max resolution for the splash.bmp image?

GPU graphic card is AMD Radeon WX 9100 with ViewSonic VP3268-4K monitor.
Since the graphic card driver isn't loaded yet during boot, it uses the default resolution.
I drew a circle in the included splash.bmp image and the aspect ratio is also distorted during boot up.

My normal desktop screen resolution is 3840x2160. I drew the logo in that resolution.
It turned out the boot-up screen resolution had an aspect ratio of 4:3. I changed my screen size to 1200x900 and scaled my image until the circle was not squished. Ran HackBGRT again and installed the 4:3 aspect ratio image. When it boot up, it looked right.
Images with size greater than 256 pixels in width or 128 pixels in height wouldn't get shown. Instead, the default Windows logo was shown. The default Windows logo looked much bigger than those maximum dimensions though.
I hope this helped someone.

guten Abend alle zusammen ich hätte gerne mal gewusst wie das richtige Auflösungs Verhältnis ist bei (HackBGRT) um das Windows boot-logo bzw Bild 1 zu 1 zu tauchen mit einem anderen Bild /danke

wäre sehr wichtig danke


Sagemaker Notebooks are accessible from any IP

[Security Bug]
Version of Service Workbench :
I figured this bug on a version of Service Workbench associated to commit 81c60ef537cb45b55dc701b7d0a0dfbfbb26c81c
I used the Sagemaker Notebook workspace type coming out-of-the-box from Service Workbench.
Description :
Even after specifying a CIDR block for a new Sagemaker notebook, the resulting Security Group has no inbound rule, and the sagemaker notebook is accessible from any IP.
Reproduce the bug :

Go on the 'Workspace' tab and create a Sagemaker Notebook workspaces. Specify <IP adress>/32 as CIDR block
Launch the workspaces
--> Once it is deployed, assess that you can access it even when using a VPN (Use Duckduck Go web browser to change your IP for example)
--> On the AWS console, assess that the Security Group associated with the Sagemaker Notebook instance has no inbound rule

Thanks for letting us know about this Ludo. I was able to reproduce the bug. I'll write up a ticket for it, and will discuss with the team about prioritizing this ticket.

NOTE: With this new commit existing users will need to re-import the newest version for SageMaker workspace type to get the added CIDR benefit.


Reproduction Issue

Dear Authors,
thank you for your nice work and providing the code repository.
Can you please provide more detail on how to reproduce your results?

can you please provide the checkpoint of the colBERT you used in your paper? becasue ColBERT did not have official released checkpoint. If you train your own checkpoint, could you provide a url toward the checkpoint?
can you please provide the bash file you used for creating ColBERT FAISS index? I guess parameters to be used for indexing can influence search performance.
and could you please also include some details about how you create indeces?

Thank you,
Dayu

Hi Dayu,
I emailed you the link to the checkpoint I used, since I don't have a good storage place rn.
I can't recall the exact parameters I used for creating the FAISS index, I can check for any logs tonight/tomorrow, but no promises there..
My best guess is that I used what's described here
PS: In case you are simply looking to compare/do analysis with ZeCo2 rankings and don't need a full reproduction, you can simply download the rankings provided in data/rankings/

I also just uploaded the checkpoint at HF modelhub:
https://huggingface.co/uva-irlab/ZeCo2


linkify-labels-on-dashboard is broken

Please ensure:

[X] The bug is caused by Refined GitHub. It doesn't happen if I disable the extension.

Description
From https://github.com/sindresorhus/refined-github/issues/4491#issuecomment-864557196
Screenshot

Console errors
No response
Example URL
https://github.com/
Browser(s) used
Chrome

@kidonng I think your screen shot is incorrect. The feature made the following clickabe.

@yakov116 The "Recent activity" used to be on top of "All activities" and has labels in it which is also linkified by Refined GitHub. I've never actually noticed a label appearing in "All activity" so I thought about the case in the screenshot.
However I think if we can linkify the labels in the popup that would also be awesome

But that has nothing to do with the dashboard. I think that would be a new feature request.

-> https://github.com/sindresorhus/refined-github/issues/4643

But that has nothing to do with the dashboard.

I think that's incorrect and this feature request is right:
https://github.com/sindresorhus/refined-github/blob/c201bf251385f36d756438329ca5dfe2109c1883/source/features/linkify-labels-on-dashboard.tsx#L14

[ ] Fix feature
[ ] Drop references to Recent activity
[ ] Update screenshot

I see that there was a screenshot in the first post and the removal of it confused me a bit at first. Sorry for the noise 😃


"pac paportal download" downloads non adx... table

Hi team,
While downloading a Portal using the CLI, I noticed a non adx table (Note [annotation]) was downloaded together with the rest of the contents.
See below

This presents a challenge for scenarios when a customer wants to download the config of a PROD portal in order to move this to a DEV environment as part of setting up an ALM process.
Could this unexpected behavior be investigated

The thought behind including annotations is to not end up breaking adx_webfile records, the tool will not download all annotation but only those which are related to the webfiles of the current website. If we skip downloading all annotation and a user uploads this data to a different org, this destination org will be missing the required annotations (css, images etc) and the portal will not function properly

Hi @adekola, I hope the previous comment answers your query. I am closing this case, please feel free to re-open or log another case in case there are any more queries.


chore(refactor): separate responsibilities for API and file-based git access

Overview
GitRepoApi
for API access
-> BitbucketGitRepoApiAdapter
-> GithubGitRepoApiAdapter
GitRepoApiFactory
creates GithubGitRepoApiAdapter or BitbucketGitRepoApiAdapter depending on config
GitRepo
For 'classic' file-based git operations. Uses GitRepoApi to get clone url from API etc.

@christiansiegel @niiku
Question regarding our repo names
we have "app_git_repo" and "root_git_repo"
Should maybe rename "root_git_repo" to "team_config_git_repo" or "team_deployment_git_repo"?

@christiansiegel @niiku
Question regarding our repo names
we have "app_git_repo" and "root_git_repo"
Should maybe rename "root_git_repo" to "team_config_git_repo" or "team_deployment_git_repo"?

root_git_repo is the argocd root
app_git_repo would then be the team_config_git_repo.

root_git_repo is the argocd root
app_git_repo would then be the team_config_git_repo.

What about: root_config_git_repo and team_config_git_repo?

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

v4.2.2
GitHub release

Your semantic-release bot :package::rocket:


Move Linear Model to Master Branch

These commits get rid of the entire "mode" system, and also all of the graph semantics. Variants in this model are straightforward string replacements that occur at linear coordinate positions.
The architecture of Sequences, Segments, and References are all still around, but Joins, Paths, and Alleles are gone.
Since master has, while this was in development, acquired an Allele annotation branch, some manual integration will be required to adjust what's on master now to the non-existence of the Allele object. Perhaps the Allele annotation stuff would be better housed on the refVar-graph-unary branch, where Alleles are alive and well?

This looks good, but I'm struggling to understand what's been reverted and what's new. Would it be possible to get a quick summary of how this differs from 0.5.1 (minus the GA prefix noise)?

I second @jeromekelleher 's comments.  It would be good to get a list of backwards-incompatible changes that have been introduced since 0.5.1.

@adamnovak - I see what you mean about the Allele Annotation schema. I've sent a PR through to the refVar-linear branch with the graph dependent parts removed. Let me know if there's a better way to do it!

I've now merged @sarahhunt 's stuff into this PR and gotten this able to be merged with the master branch.
There's an interactive diff from 0.5.1 available at: https://github.com/ga4gh/schemas/compare/v0.5.1...refVar-linear
In addition to all the build system changes, Travcis stuff, the addition of test code, and so on, there are a number of new APIs (Allele Annotations, G2P, Metadata, SequenceAnnotation). There are also many changes to Beacon. References to bases by reference name have been phased out in favor of sequence ID pointers, and we have Sequences, Strands, Segments, Sides, and Positions added and used pervasively. Some new search criteria have been added to existing methods, and new methods have been added to support the new objects.

Everybody on the call seemed to like the "alpha topic branches" idea for splitting features like graphs out until they're implemented in the reference server. What's still in the way of merging this?

It's still not clear what's changing here @adamnovak --- can you try to break this down and explain what's going on please? This is a big change and people need to be able to understand clearly what's happening before they can vote for it.

(Jerome and I are, it should be said, very much in favor of the spirit of this change -- that is, getting the master schemas branch down to the minimum needed to run the non-graph server.)

Relative to the current master, the following has changed:

Graphs and graph mode have been removed.

The Graph Mode FAQ has been removed.
The introduction to side graphs at the top of common.avdl has been removed.
The /mode/{mode}/ endpoint has been removed.
The Join object has been removed.
The /joins/search endpoint has been removed.
ReferenceSets can no longer include Joins (since they are removed).
The Path and Region objects have been removed, with uses replaced by Segments.
The GraphAlignment has been removed from the Reads API.
The subgraph search endpoints (/subgraph/segments and /subgraph/joins) have been removed.

Alleles have been removed, in favor of the traditional edit-based Variants.

The Allele object has been removed.
The /alleles/search and /alleles/{id} endpoints have been removed.
The AlleleAnnotation and references to it have been removed.
The /alleleannotations/search endpoint has been removed.
The AlleleCall object has been removed.
The alleleIds field of Variant has been removed.
Consequently, the referenceBases and alternateBases fields of Variant are now required.

Segments have been standardized as the way to refer to areas of the genome.

The sequenceId, start, and length fields on Reference have been replaced with a Segment.
The referenceId, start, and end fields on SearchVariantsRequest have been replaced with a Segment.
The referenceName, start, and end fields on Variant have been removed and replaced by a Segment.

IDs have been standardized as the way to refer to Sequences and CallSets.

The referenceName field of Position has been removed. Positions must now point to Sequences by ID.
The Sequence Annotations API now identify locations with Segments instead of Paths.
The referenceName field on SearchVariantsRequest has been removed.
The callSetName field has been removed from Calls; they should now use the callSetId field instead.

Calls have been revised.

Calls now have an id field.
The variantId field has been removed from Calls. Calls are to be contained in Variants and cannot be retrieved independently.
The phaseSet of a Call can now only be null or a string, not an array of strings.

Other miscellaneous changes

The sourceAccessions field on Reference is now required to include a version number.
Features now include a Strand.
VariantSets can no longer contain Sequences, and /variantsets/{id}/sequences/search and /variantsets/{id}/sequences/{id} have been removed. The correct way to augment an existing ReferenceSet is to create a new ReferenceSet that inherits from it.

I don't think it's correct to try and prepare a whole changelog from the last release here. We might want that document when we actually do the release (maybe we should keep it in the repository and update it when we make changes?), but most of those changes have nothing to do with this pull request, and involve the additions of other API features that we're wanting to strip out anyway, or things that are already merged into master.

+1 This needs to be merged asap, in my view.

+1 this is holding up a lot of development.

Thanks for the summary @adamnovak, this makes it much easier. I'm happy with the vast majority of the changes, as I think they are good forwards-compatible ideas.
I'm not quite sure I follow what's happened to Calls though. Is this a straightforward revert to non-graph behaviour, or is there new stuff? The id field looks new to me --- why is this here?

@dglazer @calbach  Any comments here? This PR, and subsequent PRs to strip down master to what is implemented in the reference server should get us within spitting distance of implementing https://github.com/ga4gh/schemas/pull/353

Process note: This is massive. Is this an accumulation of changes from many unrelated PRs to the refvar topic branch which have already been individually reviewed? This is problematic as reviewing the actual code in this PR reduces to me having to reread almost the entirety of every avro file in the repo (in many cases without a diff). I will just review the change summary to start.

Graphs and graph mode have been removed.
The Allele object has been removed.

I'm in favor of this.

The sequenceId, start, and length fields on Reference have been replaced with a Segment.
The referenceId, start, and end fields on SearchVariantsRequest have been replaced with a Segment.
The referenceName, start, and end fields on Variant have been removed and replaced by a Segment.

Is there justification for these changes beyond laying the framework for future graph changes? These are pretty significant breaking changes so there should be a tangible benefit.
Also, I need to come back to this point and look through the code, but I'm not sure about the reference+sequence relationship. IIRC, a reference ID is also a sequence ID. In the linear branch though, all sequences are references, right? I guess the goal might also be to lay a framework for the future graph changes?

IDs have been standardized as the way to refer to Sequences and CallSets.
The referenceName field of Position has been removed. Positions must now point to Sequences by ID.
The referenceName field on SearchVariantsRequest has been removed.
The callSetName field has been removed from Calls; they should now use the callSetId field instead.

I'd say I'm +0 on this. It's cleaner from a programming perspective, but removal of referenceName and callsetName (i.e. sampleId) functionality will be a barrier to clients when switching from files -> API.

Calls now have an id field.

-1 for performance reasons without hearing some very compelling argument. This is a good example of a case where we should have a separate PR which clearly explains the rationale.

The variantId field has been removed from Calls. Calls are to be contained in Variants and cannot be retrieved independently.

Sounds reasonable.

The phaseSet of a Call can now only be null or a string, not an array of strings.

This seems like another breaking change which needs justification. It may be fine - I just don't have the context.

@calbach the phaseSet of a Call being a null or string is a simple reversion to pre-graph behavior. Array of strings was specifically introduced to support graphs.

+1 modulo removing the id field from  Call .

OK, I've removed IDs in Calls, since they didn't really make all that much sense, seeing as nothing else was using them. That's in #366 onto the refVar-linear branch, and should show up here when that's done with CI and can be merged.
Also Maciek is right about the phase sets; we added an array of strings as an option for a phase set so that we could talk about phasing by assigning individual instances of Alleles to the same molecules as other instances of Alleles. With Alleles gone, it makes no sense to have that kind of a phase set; it's sufficient to phase Calls as a whole with each other, like we were doing before the graph stuff went in.
I think the Segment-ization and removal of name references is worth doing, even if it breaks backward compatibility. Removal of Path, for example, meant I had to replace one location with a Segment, and then it seemed very obviously inconsistent to use Segments to talk about some kinds of locations and groups of three fields to talk about others.
As for References and Sequences, a Sequence basically defines the string and coordinate space, while a Reference brings part of that sequence/coordinate space into one or more ReferenceSets. A Sequence may share an ID with an associated Reference, but it is not required to. I don't think that that assertion means anything in practice, since any two objects of different types can share an ID.

-1 on replacing (refName,start,end) with Segment. Segment has an extra strand field, which makes little sense in VCF. In addition, Segment is a complex object: Segment->Side->{Strand,Position}. I don't see we need this level of complexity if all we want is (name,start,end).
Re reference vs. sequence: it is also my impression that in the linear API, every sequence is a reference sequence. There was no "sequence" object in 0.5.1. This PR is changing our reference model which deserves more discussions. I prefer the v0.5.1 version.

Some other small differences in comparison to v0.5.1:

v0.5.1 Reference doesn't have an isPrimary field.
v0.5.1 Variant.alternateBases and calls default to empty arrays.
v0.5.1 ReferenceSet doesn't have includedReferenceSets.
Position is defined differently: one with strand and the other without strand.

I have only briefly checked common.avdl, references.avdl and ariant.avdl. I could have missed some differences. As @calbach said, it would be good to make the new linear branch largely compatible with v0.5.1 unless there is a compelling reason against 0.5.1.

I don't think our goal for this should be to revert entirely to 0.5.1, otherwise we lose essentially a year's worth of work. I think it's inevitable that we'll have some breaking changes (many of which have already been discussed, debated and voted on) when we get to the next release. However, these should be well defined and minimised where possible.
To me, the point of this PR is to back out of the graph changes as simply as we can, and get a version of the schemas in master that we can iterate on to move towards the next release. Perhaps this PR isn't the place to make structural changes like adding Segments and changing reference models and so on. It would certainly be easier to review and discuss Segments if they were added in a follow up PR on master.

My point is that 0.5.1 is an agreed and well discussed linear model, but the current model is not. When we have doubts, we should stay close to 0.5.1. On the differences between 0.5.1 and this branch, I see 0.5.1 is mostly better.

Phasesets

OK, great - I did not realize this was a graph by-product. Also I see that it removes a union type, so I'm definitely in favor.

Segment-ization

I agree that we should be consistent. As @lh3 points out, the existing convention in 0.5.1 would be to not have segments or sequences. Note that I'm not saying we need to maintain 0.5.1 at all costs - I'm mainly concerned that Segments and Sequences were added to support the graph model (or the hybrid model) and I'm not convinced they are adding value in a linear-only version of the API. I also think we'll need to make a large number of breaking changes when we switch to the graph model down the road (I believe we're no longer planning to have an intermediate hybrid model), so I think it makes sense to favor usability of the linear API over setting ourselves up for future graph API changes.
Per today's call I think the plan is to revert back further (to something closer to 0.5.1), and then propose the segment/sequence changes from a topic branch on top of that. I think this is more-or-less the suggestion in @jeromekelleher's comment.
Also thanks @adamnovak for putting the PR together.

@lh3 and @calbach (and averyone else), have a look at #367. In there, I wind back to something a bit closer to 0.5.1, which is as close to what the server is currently implementing as I think I can get it with respect to the things that the graph changes touch. I do indeed remove Segments and Sequences, and go back to pointing to things by Reference ID. I also undid a bunch of small syntactic changes on the relevant objects that the server never implemented.
With this, the server shouldn't have to do anything else to get in sync with the schemas for the core references, reads, and variants APIs (although a strict compliance test will still probably turn up some bugs).
If we merge that into this PR, and then this PR into master, we can then go ahead and a topic branch for the reintroduction of Sequences and Segments, and the replacement of name references with guaranteed-to-be-unique ID references, and the other syntactic improvements that I think we can mostly agree are actually improvements---but this time with a corresponding server branch in which it is implemented, so the server doesn't get left behind again.

CH Albach<EMAIL_ADDRESS>writes:

I'd say I'm +0 on this. It's cleaner from a programming perspective, but
removal of referenceName and callsetName (i.e. sampleId) functionality will be
a barrier to clients when switching from files -> API.

I believe it's a far better approach to address simplifying use
of the API via have more sophisticated queries rather than have
a more complex data model.
For example, there would be a query that takes referenceName
converts to referenceId and return the reference sequence
without having to explicit store referenceName along with
referenceId.

OK, @lh3 et al., come have a look at it now. I've pared the synatx back to what is currently supported by the server, modulo a couple of things that @jeromekelleher wanted me to leave in because the server is (presumably) about to adopt them.
Additional changelog:

Removed Segments.
Replaced Segments with triples of a Reference name, start, and length.
Removed Sequences, and all methods thereof.
Changed references to Sequence IDs to use Reference names instead.
Removed Sides.
Added Strand back to Position.
Removed sequenceIds and referenceNames from SearchReferencesRequest.
Removed isPrimary from Reference.
Removed ReferenceSet inheritance and the includedReferenceSets field.
Replaced SearchVariantsRequest's name with the old variantName.
Added callSetName back to Call.
Fixed a couple arrays to default to empty.

Thanks Adam. Do you know if there's an easy way to see diffs against 0.5.1?
I think we're going from San Francisco to San Jose by way of New York,
which makes it hard to review carefully. ( sorry if I missed it somewhere -
on a phone now.)
On Jul 23, 2015 10:04 PM, "adamnovak"<EMAIL_ADDRESS>wrote:

OK, @lh3 https://github.com/lh3 et al., come have a look at it now.
I've pared the synatx back to what is currently supported by the server,
modulo a couple of things that @jeromekelleher
https://github.com/jeromekelleher wanted me to leave in because the
server is (presumably) about to adopt them.
Additional changelog:

Removed Segments.
Replaced Segments with triples of a Reference name, start, and
length.
Removed Sequences, and all methods thereof.
Changed references to Sequence IDs to use Reference names instead.
Removed Sides.
Added Strand back to Position.
Removed sequenceIds and referenceNames from SearchReferencesRequest.
Removed isPrimary from Reference.
Removed ReferenceSet inheritance and the includedReferenceSets field.
Replaced SearchVariantsRequest's name with the old variantName.
Added callSetName back to Call.
Fixed a couple arrays to default to empty.

—
Reply to this email directly or view it on GitHub
https://github.com/ga4gh/schemas/pull/352#issuecomment-124251276.

SourceTree is a usefu app to review and understand changes
https://www.sourcetreeapp.com/
https://answers.atlassian.com/questions/26552/sourcetree-equivalent-of-git-diff-master-feature
David Glazer<EMAIL_ADDRESS>writes:

Thanks Adam. Do you know if there's an easy way to see diffs against 0.5.1?
I think we're going from San Francisco to San Jose by way of New York,
which makes it hard to review carefully. ( sorry if I missed it somewhere -
on a phone now.)
On Jul 23, 2015 10:04 PM, "adamnovak"<EMAIL_ADDRESS>wrote:

OK, @lh3 https://github.com/lh3 et al., come have a look at it now.
I've pared the synatx back to what is currently supported by the server,
modulo a couple of things that @jeromekelleher
https://github.com/jeromekelleher wanted me to leave in because the
server is (presumably) about to adopt them.
Additional changelog:

Removed Segments.
Replaced Segments with triples of a Reference name, start, and
length.
Removed Sequences, and all methods thereof.
Changed references to Sequence IDs to use Reference names instead.
Removed Sides.
Added Strand back to Position.
Removed sequenceIds and referenceNames from SearchReferencesRequest.
Removed isPrimary from Reference.
Removed ReferenceSet inheritance and the includedReferenceSets field.
Replaced SearchVariantsRequest's name with the old variantName.
Added callSetName back to Call.
Fixed a couple arrays to default to empty.

—
Reply to this email directly or view it on GitHub
https://github.com/ga4gh/schemas/pull/352#issuecomment-124251276.

—
Reply to this email directly or view it on GitHub.*

I was mainly worrying about Segment and the reference model. As these are closer now, I am +1 to this PR. The changes requested by @jeromekelleher in #367 are reasonable.

+1. Please also take a look at a few minor inline comments I added. Thanks!

It seems like everyone is happy now. Are there any other comments? Did I miss something? Or does someone want to merge this?

@dglazer Github will give you the diff here: https://github.com/ga4gh/schemas/compare/v0.5.1...refVar-linear
We should probably wait for your comment before merging this, actually.

+1.
Thanks @adamnovak for pulling this together, and for the link to diffs from 0.5.1. I didn't look at all the changes carefully, but I very much like the goal of getting our schemas and implementations back in sync, and this PR is a big step in the right direction. Notes below on some of the details.

Changes to 0.5.1 Features (9 files)

I think these edits are the most important part of the cleanup, and they look good, especially since @jeromekelleher and @calbach, who know the most about existing implementations, are happy. More comments below, but nothing blocking.
reads.avdl: per discussion late in #259, I don't think the Fragment record adds any value as is (since without Fragment queries you can't use it for anything, and it's not clear Fragment queries are worth implementing). It's easy to ignore, so doesn't hurt much, but I'd be tempted to pull it out either as part of this general cleanup, or in a subsequent smaller PR.
beacon.avdl: it doesn't seem stylistically consistent with the rest of the schema, and I don't know if the reference server has support. But I haven't been following the Beacon conversation, so don't have a strong opinion.

Changes to 0.5.1 WIP Features (3 files)

I don't know enough to have an opinion here. These edits promote metadata support from WIP to top-level. I know there's been lots of work on metadata, but I haven't been following it closely -- does making it top-level imply that the reference server now supports metadata, and we think the objects/methods are stable enough to lean on? (In all cases we now have moved some common objects into /metadata, so should probably keep it as is for now, and then do a separate cleanup PR if needed.)

New Features (9 files)

-0 for process reasons. The point of this PR is to get the reference server and schema back in sync, and I don't think the reference server has imminent plans to support the annotations or g2p features introduced here. (That's not a comment on the substance of those changes of course, just on the process we're moving towards. If others are comfortable, I don't object strongly.)

Modified Infra (6 files)

+0 -- all seem like good changes, but I've only skimmed.

New Infra (12 files)

+0 -- all seem like good changes, but I've only skimmed. (I was a little surprised to see 23,000 lines of presumably-generated UML here, but assuming people have discussed that, not a problem.)


doc(vue-cycle): usage documentation

VueCycle
A Vue plugin for injecting Cycle.js apps, batteries included.
Features

A vue-rx style directive for DOM events
A custom, testable DOM source for Vue components
Injected helper methods that make writing Cycle-style components easier

Usage
VueCycle is currently not published on npm as it is still considered beta,
and APIs may change over time. Consider it as /dev/null for now.
Installing plugin
VueCycle is available as a global plugin with very minimal configuration:
import VueCycle from '/dev/null'

Vue.use(VueCycle, {
  directive: 'xstream'
})

Composing VueCycle
If you do not want to install VueCycle as a global plugin, you can compose
and use parts of the plugin you want instead:
import { VueCycleDOMMixin, VueCycleRunMixin, VueCycleDomDirective } from '/dev/null'

export default {
  mixins: [VueCycleDOMMixin, VueCycleRunMixin],
  directives: {
    xstream: VueCycleDomDirective
  }
}

Writing VueCycle Components
The jist of what VueCycle does is that it injects a DOM driver, and a few
convenience methods that makes writing Cycle-styled components possible.
<template>

Current value is: {{ value }}

  <button v-xstream:click="{ name: 'increment', data: count + 1 }">
    Increment
  </button>
</template>

VueCycle injects a custom xstream directive that is used for identifying
events on the custom DOM driver. See the directive documentation for more
information.
The methods $_cycle_app and $_cycle_run are a core part of VueCycle
where $_cycle_app if where you can define your primary component logic
and $_cycle_run is where you perform the side-effects. You can here make
use of HOCs that do not inject to the DOM, such as cycle-onionify.
API
VueCycle consists of multiple components:

VueCycleDOMMixin mixin
VueCycleRunMixin mixin
VueCycleDomDirective directive
fromCustomEvent injected method
watchProp injected method

VueCycleDOMMixin
Injects the $domDriver instance to the Vue component on created.
$domDriver
The injected DOM driver instance
on(eventName)
Params:

string eventName - Source event name

Return:

Stream Injected stream from xstream directive

VueCycleRunMixin
Runs the $_cycle_run function with injected $_cycle_app on mounted.

VueCycleDomDirective
The VueCycle xstream directive
The directive can be used the following ways:

v-xstream:$event="'$sourceName'"
v-xstream:$event="{ name: '$sourceName', data: 'some_value' }"

Where $event is the name of the DOM or Vue custom event, and $sourceName
being the name of the event that will be used for filtering in the DOM driver.

fromCustomEvent(eventName)
An xstream wrapper for vm.$on events
Params:

string eventName - Name of the custom event

Return:

Stream xstream instance of custom event

watchProp(propName)
An xstream wrapper for vm.$watch events
Params:

string propName - Name of property to observe

Return:

Stream xstream instance of watched property


Random fixes for HTML media and EME

At work, we found a couple of incorrect and/or missing types while dealing with HTML media elements and EME. This PR fixes some of these types.

We don't want to add new vendor-prefixed APIs, so I would exclude them here.

Fair enough. I'll remove that commit.


Automated Package Upgrade

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

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


Why is navigation malfunctioning when obstacles are installed in certain locations?

xxx.obj was created without the concept of height and used temporary obstacle mode when creating navigation.
Three obstacles were installed at specific locations and a route test was performed.
like the picture
Depending on the direction, the result will be different.

Evgeny
Sent from my iPhone

On Jul 5, 2021, at 19:58, onegi79 @.***> wrote:

xxx.obj was created without the concept of height and used temporary obstacle mode when creating navigation.
Three obstacles were installed at specific locations and a route test was performed.
like the picture
Depending on the direction, the result will be different.
It's an area you can go to, but you're judging it's crash
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or unsubscribe.

Do you mind sharing the xxx.obj? Evgeny
…
Sent from my iPhone
On Jul 5, 2021, at 19:58, onegi79 @.***> wrote:  xxx.obj was created without the concept of height and used temporary obstacle mode when creating navigation. Three obstacles were installed at specific locations and a route test was performed. like the picture Depending on the direction, the result will be different. It's an area you can go to, but you're judging it's crash — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or unsubscribe.

hello adamenkov
thanks for test
sent you an email

I just reproed the bug, it looks curious.

The problem can be better highlighted if instead of "Raycast" you use "Pathfind Follow": inter-tile connection gets messed up in the presence of (dynamic) obstacles.
I unfortunately don't know every bit of Recast & Detour but as far as I can tell obstacles create regions of area 0 - file DetourFileCache.cpp, line 687
In Sample of type "Solo Mesh" this would be considered a "hole" in the navmesh and would be addressed (cut) in function rcBuildContours, here:
	// Merge holes if needed.
	if (cset.nconts > 0)
	{
		...

I can't see a corresponding hole-cutting code in dtBuildTileCacheContours.
So I suspect that it doesn't handle holes (made by your obstacles) in dtBuildTileCacheContours.
DISCLAIMER: I can totally be wrong, it's not a professional advice, no responsibility assumed, yada yada

Thank you. Let's check what you said.

The problem for this is 2 fold:

The tile cache code should remove the extra vertices along the tile seams, but for some reason it cannot
https://github.com/recastnavigation/recastnavigation/blob/master/DetourTileCache/Source/DetourTileCacheBuilder.cpp#L1926

Each tile has predefined number of links allocated along with it, which are used to link the polygons together. Portal edges (edges between tiles), 2 additional edges are allocated to account for the odd cases where extra vertices are along the edges:
https://github.com/recastnavigation/recastnavigation/blob/master/Detour/Source/DetourNavMeshBuilder.cpp#L385

This makes sense, if you look at the test cases. Path find from the long edge to the smaller edges fails, because not all of the edges are linked.
The solution is to fix the vertex removal, if you have a solid repro it should be possible to figure out why the remove fails.

@onegi79, is it ok to share your xxx.obj?

Yes, it is okay to share the file.
Thank you.

@onegi79 - actually, I can't share it - I can't attach it to this message, sorry.
You'll probably want to upload the xxx.obj to your own GitHub repository (or DropBox, or Google Drive etc.) and provide a link (links are permitted here).

for test share file.
https://drive.google.com/file/d/1gMbk5UBV_BqzW-Yh5nySSf2emam2cjXW/view?usp=sharing

sorry i reshare file

I have the same issue using tile cache, in that one direction is fine but a different direction causes collision. While I have read of @memononen solution I don't get how to go about accomplishing it. Any help on this matter would be very appreciated, thank you!


[Elasticsearch] User not created when enabling security

Chart version:
v7.3.2
Kubernetes version:
1.17.4
Kubernetes provider: E.g. GKE (Google Kubernetes Engine)
Custom
Helm Version:
3.1.2
helm get release output
NAME: sec-elasticsearch-group-master
LAST DEPLOYED: Mon Apr 20 10:13:41 2020
NAMESPACE: environment-1-platform
STATUS: deployed
REVISION: 4
USER-SUPPLIED VALUES:
antiAffinity: hard
antiAffinityTopologyKey: kubernetes.io/hostname
clusterHealthCheckParams: wait_for_status=green&timeout=1s
clusterName: sec-easier-elasticsearch
esConfig:
elasticsearch.yml: |
path.repo: "/backup/easier-data/" # to allow data backup
xpack.security.enabled: true
xpack.security.transport.ssl.enabled: true
xpack.security.transport.ssl.verification_mode: certificate
xpack.security.transport.ssl.keystore.path: /usr/share/elasticsearch/config/certs/elk-cert.p12
xpack.security.transport.ssl.truststore.path: /usr/share/elasticsearch/config/certs/elk-cert.p12
xpack.security.http.ssl.enabled: true
xpack.security.http.ssl.truststore.path: /usr/share/elasticsearch/config/certs/elk-cert.p12
xpack.security.http.ssl.keystore.path: /usr/share/elasticsearch/config/certs/elk-cert.p12
esJavaOpts: -Xmx1g -Xms1g
esMajorVersion: ""
extraEnvs:

name: ELASTIC_PASSWORD
valueFrom:
secretKeyRef:
key: password
name: elastic-credentials
name: ELASTIC_USERNAME
valueFrom:
secretKeyRef:
key: username
name: elastic-credentials
extraInitContainers: ""
extraVolumeMounts: |

name: backup-volume
mountPath: /backup/easier-data/
extraVolumes: |
name: backup-volume
persistentVolumeClaim:
claimName: pvc-elasticsearch-backup # existing PVC to be shared y all nodes to make the backup
fsGroup: ""
fullnameOverride: ""
httpPort: 9200
image: docker.elastic.co/elasticsearch/elasticsearch
imagePullPolicy: IfNotPresent
imagePullSecrets: []
imageTag: 7.3.2
ingress:
annotations: {}
enabled: false
hosts:
chart-example.local
path: /
tls: []
initResources: {}
keystore: []
labels: {}
lifecycle: {}
masterService: ""
masterTerminationFix: false
maxUnavailable: 1
minimumMasterNodes: 1
nameOverride: ""
networkHost: <IP_ADDRESS>
nodeAffinity: {}
nodeGroup: master
nodeSelector: {}
persistence:
annotations: {}
enabled: true
podAnnotations: {}
podManagementPolicy: Parallel
podSecurityContext:
fsGroup: 1000
runAsUser: 1000
podSecurityPolicy:
create: false
name: ""
spec:
fsGroup:
rule: RunAsAny
privileged: true
runAsUser:
rule: RunAsAny
seLinux:
rule: RunAsAny
supplementalGroups:
rule: RunAsAny
volumes:

secret
configMap
persistentVolumeClaim
priorityClassName: ""
protocol: https
rbac:
create: false
serviceAccountName: ""
readinessProbe:
failureThreshold: 3
initialDelaySeconds: 10
periodSeconds: 10
successThreshold: 3
timeoutSeconds: 5
replicas: 2
resources:
limits:
cpu: 1000m
memory: 2Gi
requests:
cpu: 100m
memory: 2Gi
roles:
data: "false"
ingest: "false"
master: "true"
schedulerName: ""
secretMounts:

name: elastic-certificates
path: /usr/share/elasticsearch/config/certs
secretName: elk-certificates-p12
securityContext:
capabilities:
drop:

ALL
runAsNonRoot: true
runAsUser: 1000
service:
annotations: {}
httpPortName: http
nodePort: null
transportPortName: transport
type: ClusterIP
sidecarResources: {}
sysctlInitContainer:
enabled: true
sysctlVmMaxMapCount: 262144
terminationGracePeriod: 120
tolerations: []
transportPort: 9300
updateStrategy: RollingUpdate
volumeClaimTemplate:
accessModes:
ReadWriteOnce
resources:
requests:
storage: 300Gi

Describe the bug:
The cluster starts the creation but never ends. Looking into the logs, there seems to exist a problem retrieving the user "easier" in my case.
"level": "ERROR", "component": "o.e.x.s.a.e.NativeUsersStore", "cluster.name": "sec-easier-elasticsearch", "node.name": "sec-easier-elasticsearch-master-1", "cluster.uuid": "8xY15pq0SGiSdiF366INZA", "node.id": "AaszF7y3TdWX7Lv-1ESKzw",  "message": "security index is unavailable. short circuiting retrieval of user [easier]"  }
Even if in my values.yaml I have the lines for the user/password and the secrets created in my cluster:
extraEnvs:
  - name: ELASTIC_PASSWORD
    valueFrom:
      secretKeyRef:
        name: elastic-credentials
        key: password
  - name: ELASTIC_USERNAME
    valueFrom:
      secretKeyRef:
        name: elastic-credentials
        key: username

If I connect manually to the cluster, node by node, creating the user/password manually:
bin/x-pack/users useradd admin -r superuser -p CHANGE-ME

Steps to reproduce:
1.helm install sec-elasticsearch-group-master -v values-master-secure.yaml ./
2.two nodes are created
3.look for the error in one of the nodes
Expected behavior:
The cluster is created with user and password from values.yaml and secrets.

by the way... internally in the container, I can see the two ENV Variables passed:
ELASTIC_USERNAME=easier
ELASTIC_PASSWORD=CHANGEME
by the way, is it secure to have user/password clear in ENV variables?

Yes, having them in the container is fine, they get mounted by K8's secret.  You should setup rbac, so that unauthorized people can't exec into the container.
I had the exact same problem -- had to exec into the container and run
./elasticsearch-setup-passwords interactive -u https://[name].[namespace].svc.cluster.local:9200
After this
curl -k -u $ELASTIC_USERNAME:$ELASTIC_PASSWORD 'https://[name].[namespace].svc.cluster.local:9200/'
worked -- should not return an error but a valid json

The chart should probably be patched to handle this -- in the short term, it would be good to at least put info into the NOTES.txt to let people know that they need to do this.  In the longer term, the chart (stateful set.yaml?) should be patched to do this automatically.

Yes, having them in the container is fine, they get mounted by K8's secret. You should setup rbac, so that unauthorized people can't exec into the container.
I had the exact same problem -- had to exec into the container and run
./elasticsearch-setup-passwords interactive -u https://[name].[namespace].svc.cluster.local:9200
After this
curl -k -u $ELASTIC_USERNAME:$ELASTIC_PASSWORD 'https://[name].[namespace].svc.cluster.local:9200/'
worked -- should not return an error but a valid json

I'm running into a similar issue. Everything works with the default username:password but when I exec into the container to change the password, I am getting Failed to establish SSL connection error. any ideas?

I don't believe this issue to be resolved, but it was closed by the bot. Sigh.

Have the same problem...

also experiencing this issue, I moved past it by creating the secret by hand and injecting the user pass and ENV vars.


Add ability to compile less and sass files

Adds ability to compile less and sass files in one go,
mix.less('resources/assets/less/style.less', 'public/assets/css/less.css')
   .less('resources/assets/less/style2.less', 'public/assets/css/less2.css')
   .sass('resources/assets/sass/style2.scss', 'public/assets/css')
   .sass('resources/assets/sass/style.scss', 'public/assets/css');

I need this in one go too! I write my styles in less, but I need bootstrap 12/24-col grid system! (Which is in sass/scss)

possible solution https://github.com/JeffreyWay/laravel-mix/issues/184#issuecomment-275385555

Thanks for the PR! There were a few naming things here that didn't gel well, so I pushed a commit to add support just now. It'll be tagged later today.

No problem, now I can compile both and it's all that matters :)


How to change backgroundColor of Toast

How to change backgroundColor of Toast?

Changing background color is not yet implemented
will be do it in next release


support linked npm modules

It seems like esbuild isn't consuming linked npm modules. The directory structure seems to be correctly layed out but esbuild fails.
Example: https://github.com/jbedard/rules_esbuild/tree/npm-link-package/e2e/npm-links

Actually that branch isn't reproducing it atm. Will close until I can confirm it's an esbuild and not ts issue


Check if .env can get out of version control for security reasons

Is your feature request related to a problem? Please describe.
Currently .env is version-controlled, but it contains secrets; accidentally overwriting it by a fresh install vs. accidently pushing to git are risks. Therefore, we need to check how to handle this properly, e.g., pushing this too in local_configs.
Describe the solution you'd like
Check a possible solution to the location problem and the writing of secrets on disk.
Describe alternatives you've considered
N/A
Additional context
https://github.com/docker/compose/issues/6170

Would be nice to move the auth/secrets to another file in local_config perhaps, so there is less risk of overwriting existing values on upgrades/reinstalls.
We also have requirements internally that we are not allowed to check any configs into our internal git server with saved credentials or shared keys. So we will endup storing most of that data in a vault-like remote storage facility and accessing as needed. I think we would access and then write them to the linux environment, then have artemis read from that?

unfortunately we can't move the .env file to other folder because it is still an ongoing issue to support external .env files in the docker-compose repository
https://github.com/docker/compose/issues/6170
because we have to do with environment variables you can delete the .env file and actually import them through another script that is located somewhere else.

You can copy the .env file to another directory and point to it from inside the docker-compose file.
https://docs.docker.com/compose/environment-variables/
The “env_file” configuration option
You can pass multiple environment variables from an external file through to a service’s containers with the ‘env_file’ option, just like with docker run --env-file=FILE ...:
web:
  env_file:
    - web-variables.env

Closing this issue


ADD: nodestats data syncstatus and p2pstatus

Data for wiring syncstatus (#601) and p2pstatus on controls page

curl needs to be installed on setup


feat: allow twitter profile

What kind of change does this PR introduce?
New feature: typescript support for already-existing Twitter social sign in button
What is the current behavior?
Get TS / ES lint errors and breaks builds in vercel when you use twitter profile in supabase-ui auth component, eg:
        <Auth.UserContextProvider supabaseClient={supabase}>
            {/* this is fine: <Auth providers={['github', 'google']} supabaseClient={supabase} /> */}
            <Auth providers={['github', 'google', 'twitter']} supabaseClient={supabase} />
        </Auth.UserContextProvider>

What is the new behavior?
stuff is good

wow, no automated tests...? 🤔🤔

The automated tests aren't run due to Github's recent workflow changes. I have approved the Action now. Thanks for the PR 😃


Errors flashing STM32 using ARMDebug

Hello,
first of all: Thank you for this project! It has helped me a lot on my first deepdive into the world of microcontrollers.
I am trying to flash an STM32 ARM microcontroller from an ESP32 and your ARMDebug Class has gotten me quite far.
I can connect, unlock the flash, mass erase and I can programm individual parts of the flash.
But when I try to write a whole 32KB of Firmware the flash process fails after a while and I have not found a way to recover from that.
I was hoping that maybe you could give me a hint what I should be looking for in the documentation or to debug the code, even though this is not about the MC you are using in your project.
This is the main loop that writes to the flash:
  for (size_t i = 0; i < bufferSize; i +=4) {
    waitbusy();
    writePG1();
    uint32_t data = *((uint32_t*)(buffer + i));
    Serial.println(String(i) + " writing: 0x" + String(FLASH_OFFSET + i, HEX)+":0x"+String(data, HEX));
    memStore(FLASH_OFFSET + i, data);
    waitbusy();
    uint32_t temp;
    memLoad(FLASH_OFFSET + i, temp);
    if(temp!=data){
      handleFault();
      Serial.println(String(i) + " verify failed. expected: 0x" + String(data, HEX) + " read: " + String(temp,HEX) + " retrying");
      i-=4;
    }
  }

in the beginning the write and verify succeeds. After ~2000 operations I am occasionally getting parity errors:
PARITY ERROR during read (addr=0 APnDP=1 data=63000052)
ARMDebug: Error while waiting for memory port
those seem to be resolved by the retry mechanism.
But shortly after (~2500 operations in) I am endlessly getting errors like:
PROTOCOL ERROR response during read (ack=3 addr=c APnDP=0)
ARMDebug: Error while waiting for memory port
Retrying obviously does not solve the issue the STM has at that point.
Do you have any idea how I can find out whats blocking the flash operations at this point and how it can be resolved?
Best regards
Ier

Short update:
I basically tried to ignore every possible error for now and perform a full reinitialization of the SWD whenever a verificytion step fails.
This way I get through the wholeflash process and the verification I do with an ST-Link afterwards confirms that the whole firmware has been written corretly.
I am sure the errorhandling can be further improved so it only reconnects when the client stops driving the line (as suggested in the SWD specification).
But I have another problem:
I own a couple of the mainboards that contain the STM32 and although they seem like they are the same hardware they behave different.
One out of three can be flashed using my code. The others fail on the very first attempt to unlock the flash because the FLASH_SR register indicates hat the flash is already unlocked although it seems its not.
I tracked down the differences and the only one I can find ist that MEM_IDR is 0x24770011 on the chip that works and 0x14770011 on the one that doesnt.
No idea what that means

Find your chip's programming specs, implement its programming protocol. This was never intended to be a universal programmer out of the box.

I am sorry, I never meant to offend you and of course I did not expect your code to support flashing of totally different MCs.
Quite the opposite: I am impressed how well the ARMDebug class works for other ARM controllers like the one I have.
But even though I had already gone through the programming guide several times while building my MC specific subclass your comment made me look again more closely.
I actually made the mistake of writing to flash in 32Bit blocks and that did work on the board that is equipped with a GD32F103. The other boards are equipped with STM32F103. Obviously the GD supports 32bit flashing while the STM requires 16Bit.
Using the memWriteHalf method your class provides made hat an easy fix.
Best regards
Ier

No offense taken, just trying to clearly state the path forward and the reason without offering much energy toward a project I haven't cared about in many years :) glad you got it working! If you do add more CPU-specific programmer classes I wouldn't mind a merge request.


How do I change the size other than normal , mini

This library hasn't been updated in 5 years. Consider using ExpandableFab to achieve your desired functionality.
The ExpandableFab allows you to use Normal, Mini, Auto, or a custom size that you specify.
It actually comes with an example app that shows how to do this easily. See this layout file.
Let me know if you try out ExpandableFab and have any questions.


propagate to add two stochastic triples together

Hello!
I'm trying to use the propagate function to extract derivatives from some Monte Carlo simulations. However, I noticed that the function does not behave as I would expect in even some simple use cases. A minimal example is given by simply adding two stochastic triples together:
using StochasticAD

function add(x::Real, y)
    x + y
end

function add(x::StochasticAD.StochasticTriple, y)
    StochasticAD.propagate(add, x, y; keep_deltas=true)
end

# x = 1
x = stochastic_triple(1)
y = stochastic_triple(5)

add(x, y)  # 6 + 0ϵ
x + y  # 6 + 2ϵ
add(x, y) == x + y  # false

I expected that propagate would automatically ensure that this simple function would correctly propagate the perturbations but this does not seem to be the case. Am I doing something wrong or is this a bug?
Thanks!

At quick glance, I think it's because you need keep_deltas = Val(true), not just true. Although we should definitely catch the latter case and error.

At quick glance, I think it's because you need keep_deltas = Val(true), not just true. Although we should definitely catch the latter case and error.

Many thanks for the quick reply and catching that silly mistake on my end! However I don't think replacing true with Val(true) fixes the issue. Moreover, I noticed that it persists even when one of the numbers is not a stochastic triple:
using StochasticAD

function add(x, y)
    x + y
end

function add(x::StochasticAD.StochasticTriple, y)
    StochasticAD.propagate(add, x, y; keep_deltas=Val(true))
end

x = stochastic_triple(1)
y = 5

add(x, y)  # 6 + 0ϵ
x + y  # 6 + 1ϵ
add(x, y) == x + y  # false

Just a hunch: can you try writing stochastic_triple(1.0)?

Just a hunch: can you try writing stochastic_triple(1.0)?

Thanks, that does the trick! Any idea why the behavior for triples for floats is different than that for triples of ints?

Well, an integer shouldn't really be able to possess continuous perturbations. But again, there definitely shouldn't be a silent error here, I need to fix that!


Build 0.15 docs from Scala 2.12

Fixes the 0.15 part of #1061.

Codecov Report

Merging #1063 into release-0.15.x will decrease coverage by 0.55%.
The diff coverage is n/a.

@@                Coverage Diff                 @@
##           release-0.15.x    #1063      +/-   ##
==================================================
- Coverage           69.45%   68.89%   -0.56%
==================================================
  Files                 212      211       -1
  Lines                4658     4427     -231
  Branches              451      448       -3
==================================================
- Hits                 3235     3050     -185
+ Misses               1423     1377      -46

Impacted Files
Coverage Δ

.../scala/org/http4s/testing/ArbitraryInstances.scala
64.7% <0%> (-14.89%)
:arrow_down:

...scala/org/http4s/headers/Content-Disposition.scala
66.66% <0%> (-8.34%)
:arrow_down:

core/src/main/scala/org/http4s/HttpVersion.scala
87.5% <0%> (-6.25%)
:arrow_down:

...ain/scala/org/http4s/headers/X-Forwarded-For.scala
66.66% <0%> (-4.77%)
:arrow_down:

...scala/org/http4s/server/tomcat/TomcatBuilder.scala
27.69% <0%> (-3.2%)
:arrow_down:

...n/scala/org/http4s/server/jetty/JettyBuilder.scala
35% <0%> (-3.1%)
:arrow_down:

core/src/main/scala/org/http4s/Query.scala
86.04% <0%> (-1.96%)
:arrow_down:

core/src/main/scala/org/http4s/Cookie.scala
44.73% <0%> (-1.42%)
:arrow_down:

.../src/main/scala/org/http4s/client/blaze/bits.scala
81.25% <0%> (-1.11%)
:arrow_down:

dsl/src/main/scala/org/http4s/dsl/Path.scala
71.42% <0%> (-0.99%)
:arrow_down:

... and 11 more

Continue to review full report at Codecov.

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


can't stop location service when bring service from background

Hi, when I take a running service to background by press back button and press notification icon to bring service to foreground , I found can't stop location service even I execute "BackgroundLocator.unRegisterLocationUpdate" serval times.
anyone has same problem?
it occurs in android Emulator

Hi @tranice
Thank you for opening an issue;
Are you testing the example app? if not please share some code;

Hi @mehdok  I test the example app in Android Emulator - Pixel_2_XL_API_28 and Nokia 7 plus , both  occurs.

Thank you @tranice.
I can reproduce this problem, so it is officially a bug;)
Thanks for reporting, will notif you when it is fixed.

@mehdok you are welcome, thanks for your effort ！

hi @mehdok , is this already fixed? thank you so much!

@olryts
Sadly no, it is not fixed yet;

Hello i am facing an issue and i need your help. I want to get location once in a every 15 secs. Both IOS and Android. I can make it with interval settings in Android but i couldn't find a way for IOS. Is there a way to do this ?

Hi @FLavenNA
It is better if you could open a new issue for your problem.
But short answer, there is no way to force iOS to use the interval to send location updates, iOS will send you updates whenever it receives one.


support dmg format.

fixed #288 .

[x] passed unit tests successfully.
[x] no issues when running rubocop.

Thanks for this fix - I noticed it won't allow installs of the new beta that causes this problem, since the Xcode 10 beta 3 .dmg contains a file calledXcodeXIP.xip instead of the Xcode.app that has been present before Apple made this change. I imagine if you tried installing 10b3,source = Dir.glob(File.join(mount_dir, 'Xcode*.app')).first would make source nil and you'd get
No `Xcode.app` found in DMG. Please remove #{dmg_path} if you suspect a corrupted download or run `xcversion update` to see if the version you tried to install has been pulled by Apple. If none of this is true, please open a new GH issue.
This would be good to unblock other installs of Xcode, though. Thanks!

@KrauseFx
Not released version 2.4.2 as gem yet?
https://rubygems.org/gems/xcode-install

Whops, sorry, publishing now

Live now 👍

I confirmed it. Thanks!


put "..." behind the verse quote ?

since it's from the end of the verse, to let people know it was cut, maybe put "..." behind the text ?

Jazzaka Lahu khairan, it is true that putting it just like this, it might make people think that it is the whole verse. I've changed it locally, inshaAllah I'll push the changes soon and close the issue.

Fixed with this https://github.com/DBChoco/Muezzin/commit/4ba09484388d298ff636eeb020d7802edb0f64ad
Jazzaka  Lahu khairan


Load items in "loaded" order

Hello. Why the items are shown in opposite order which are loaded?
I explain. When the array data below is loaded:
[0:{name: "first", path: "1", size: 1},
1:{name: "second", path: "2", size: 2},
2:{name: "third", path: "3", size: 3},]

the items are appended like:

third

second

first

and i must to set showFileCounter = false due to is assiged:
1) to element
third
, 2) to element
second
 and 3) to
first

There is no way to implement any option in order to set the loaded elements order like asc/desc?

there is already an option for that.
uploadQueueOrder:'top'
uploadQueueOrder:'bottom'

It is not in the documentation. Please, document uploadQueueOrder and add the "pd" parameter on downloadCallback. Thanks for that!


[.(full-sex-video,,!!).] Balthazar 400 Videos Original Equatorial Guinea Baltasar Ebang Engonga Trending on Social Media Twitter x

31 seconds ago
L𝚎aked Video Balthazar Baltasar Ebang Engonga  Original Video Viral Video L𝚎aked on X Twitter Telegram
Baltasar Engonga videos: Equatorial Guinea President Obiang sack Baltasar Ebang Engonga over viral leaked video
Leaked Video Viral On facebook Media.Viral xxx,xnxx Leaked Video Viral On facebook Media.Viral xxx,xnxx Leaked Video Viral On facebook Media.
Balthazar Baltasar Ebang Engonga  Original Video video took the internet by storm and amazed viewers on various social media platforms.  Balthazar Baltasar Ebang Engonga  , a young and talented digital creator, recently became famous thanks to this interesting video.
L𝚎aked Video  Balthazar Baltasar Ebang Engonga  Original Video Viral Video L𝚎aked on X Twitter
Balthazar Baltasar Ebang Engonga  Original Video video oficial twitter
L𝚎aked Video  Balthazar Baltasar Ebang Engonga  Original Video Viral Video L𝚎aked on X Twitter.

ghgh

hjhjh