Shutdown and Reboot functions

Added a couple of functions to handle rebooting and shutdown of the PI from the status screen.
This is a first attempt at contributing to a project so I wanted to keep it simple in the hopes that I did this correctly.

Brad, thanks for sending this in. Looks great. Have you tried out the "shutdown" feature?  Does it actually stay "shut down" when you do so?

Thanks for the tip on using the built-in syscall exported constants.  I'm pretty new to go and learning my way around.
I made your suggested changes and updated that in my branch.  Do I need to reissue the pull request?
Chris - yes, I've tested this on my device and the shutdown works (you must disconnect and reconnect power for it to startup again after a shutdown.  Reboot also seems to work as expected.
I always was worried about file system corruption just yanking the power, but it never seemed to cause damage.

Nope, looks like you've got it.

Thanks for the tip on using the built-in syscall exported constants.  I'm pretty new to go and learning my way around.

Np and welcome aboard!

"... the shutdown works (you must disconnect and reconnect power for it to startup again after a shutdown. Reboot also seems to work as expected."
@braddward - welcome! If you need a more elegant solution for startup, break out the soldering iron and wire a momentary switch to connect the "Run" pin to the conveniently adjacent ground.  Shorting "Run" to GND will boot the Pi (if it's off), or perform a hard reset (if it's running).

Is that a hardware reset?  If so, that would be the same as pulling the
power, leaving the file system corrupted.
What would be real nice is a method of gracefully shutting it down on
loss of external power, and a restart upon getting external power.
On 12/20/2015 09:00 PM, AvSquirrel wrote:

/"... the shutdown works (you must disconnect and reconnect power for
it to startup again after a shutdown. Reboot also seems to work as
expected."/
@braddward https://github.com/braddward - welcome! If you need a
more elegant solution for startup, break out the soldering iron and
wire a momentary switch to connect the "Run" pin to the conveniently
adjacent ground. Shorting "Run" to GND will boot the Pi (if it's off),
or perform a hard reset (if it's running).
rpi-2-run-reset
https://cloud.githubusercontent.com/assets/14127245/11922433/78d0c9ca-a75c-11e5-84fb-2c0a86779ca4.jpg
—
Reply to this email directly or view it on GitHub
https://github.com/cyoung/stratux/pull/152#issuecomment-166184545.

This could be a solution.  You could shutdown either via the web interface or by wiring a momentary switch to one of the gpio pins.  The code could monitor for the gpio  being activated and then calling the shutdown function.
http://piplay.org/forum/discussion/564/shutdown-button-using-gpio-pin/p1

As far as power-up and shutdown via GPIO, I highly recommend this:
http://www.mosaic-industries.com/embedded-systems/microcontroller-projects/raspberry-pi/on-off-power-controller
It works quite well.  I typically use it in the auto-off configuration.

I'd posted a gpio solution a while back: "
https://www.reddit.com/r/stratux/comments/3hw2x8/rpi2_power_off_button/"
On Mon, Dec 21, 2015 at 9:38 AM, braddward<EMAIL_ADDRESS>wrote:

This could be a solution. You could shutdown either via the web interface
or by wiring a momentary switch to one of the gpio pins. The code could
monitor for the gpio being activated and then calling the shutdown function.
http://piplay.org/forum/discussion/564/shutdown-button-using-gpio-pin/p1
—
Reply to this email directly or view it on GitHub
https://github.com/cyoung/stratux/pull/152#issuecomment-166332996.

My opinion only, but...
This is all trying to solve the problem the wrong way. Embedded electronics
(even those built on higher-order platforms like the Pi) don't have a
graceful shutdown procedure. I don't have to gracefully power down the King
KLN-94 GPS, the Garmin transponder, the engine monitor, or the ADS-B Out
transmitter. For that matter, think about non-aviation applications: home
routers, Roku / AppleTV set-top boxes, office phones. Many of these run
Linux. None of them have a shutdown process that's required to avoid
corrupting the boot image.
The real solution here is to have Stratux run in read-only mode using a
ramdisk for ephemeral data - DHCP leases, etc. If you want / need to log,
you can either create a separate partition on the uSD card or use a USB
flash drive.
On Mon, Dec 21, 2015 at 9:51 AM, Joseph Poirier<EMAIL_ADDRESS>wrote:

I'd posted a gpio solution a while back: "
https://www.reddit.com/r/stratux/comments/3hw2x8/rpi2_power_off_button/"
On Mon, Dec 21, 2015 at 9:38 AM, braddward<EMAIL_ADDRESS>wrote:

This could be a solution. You could shutdown either via the web interface
or by wiring a momentary switch to one of the gpio pins. The code could
monitor for the gpio being activated and then calling the shutdown
function.
http://piplay.org/forum/discussion/564/shutdown-button-using-gpio-pin/p1
—
Reply to this email directly or view it on GitHub
https://github.com/cyoung/stratux/pull/152#issuecomment-166332996.

—
Reply to this email directly or view it on GitHub
https://github.com/cyoung/stratux/pull/152#issuecomment-166337517.

--
Steven Sokol
408 Camelot Drive
Liberty, MO 64068
mobile: +1<PHONE_NUMBER>
fax: +1<PHONE_NUMBER>

Here are my unsolicited, semirandom thoughts on the subject:
This is <1.0 software and a lot of stuff is still changing.
This is a DIY project that encourages tinkering.
I don't think many, if any, people are getting file system corruption from
simply unplugging.
I got the stratux image booting into read-only a while back.  It was a pain
and I wasn't getting any advantage from it, so I stopped fussing with it.
On Mon, Dec 21, 2015, 10:22 Steven Sokol<EMAIL_ADDRESS>wrote:

My opinion only, but...
This is all trying to solve the problem the wrong way. Embedded electronics
(even those built on higher-order platforms like the Pi) don't have a
graceful shutdown procedure. I don't have to gracefully power down the King
KLN-94 GPS, the Garmin transponder, the engine monitor, or the ADS-B Out
transmitter. For that matter, think about non-aviation applications: home
routers, Roku / AppleTV set-top boxes, office phones. Many of these run
Linux. None of them have a shutdown process that's required to avoid
corrupting the boot image.
The real solution here is to have Stratux run in read-only mode using a
ramdisk for ephemeral data - DHCP leases, etc. If you want / need to log,
you can either create a separate partition on the uSD card or use a USB
flash drive.
On Mon, Dec 21, 2015 at 9:51 AM, Joseph Poirier<EMAIL_ADDRESS>wrote:

I'd posted a gpio solution a while back: "
https://www.reddit.com/r/stratux/comments/3hw2x8/rpi2_power_off_button/"
On Mon, Dec 21, 2015 at 9:38 AM, braddward<EMAIL_ADDRESS>wrote:

This could be a solution. You could shutdown either via the web
interface
or by wiring a momentary switch to one of the gpio pins. The code could
monitor for the gpio being activated and then calling the shutdown
function.

http://piplay.org/forum/discussion/564/shutdown-button-using-gpio-pin/p1

—
Reply to this email directly or view it on GitHub
https://github.com/cyoung/stratux/pull/152#issuecomment-166332996.

—
Reply to this email directly or view it on GitHub
https://github.com/cyoung/stratux/pull/152#issuecomment-166337517.

--
Steven Sokol
408 Camelot Drive
Liberty, MO 64068
mobile: +1<PHONE_NUMBER>
fax: +1<PHONE_NUMBER>
—
Reply to this email directly or view it on GitHub
https://github.com/cyoung/stratux/pull/152#issuecomment-166348455.

You haven't had filesystem corruption yet. It will eventually happen.
Given that Stratux is something that people are using for situational
awareness in flight, I would rather be safe than sorry. Here's a compromise
idea:
Offer a "developer mode" that is fully read / write. Pretty much as things
are now. Also offer a "production mode" which is read only except when
updating the configuration. Default to production mode, but include a
simple UI switch to shift into developer mode.
Perhaps we don't need to do this until we reach the 1.0 mark, but
considering the number of people out there using Stratux in production (the
vast majority of which aren't tinkering) I'm in favor of doing it sooner
rather than later.
On Mon, Dec 21, 2015 at 10:37 AM, Kris Knigga<EMAIL_ADDRESS>wrote:

Here are my unsolicited, semirandom thoughts on the subject:
This is <1.0 software and a lot of stuff is still changing.
This is a DIY project that encourages tinkering.
I don't think many, if any, people are getting file system corruption from
simply unplugging.
I got the stratux image booting into read-only a while back. It was a pain
and I wasn't getting any advantage from it, so I stopped fussing with it.
On Mon, Dec 21, 2015, 10:22 Steven Sokol<EMAIL_ADDRESS>wrote:

My opinion only, but...
This is all trying to solve the problem the wrong way. Embedded
electronics
(even those built on higher-order platforms like the Pi) don't have a
graceful shutdown procedure. I don't have to gracefully power down the
King
KLN-94 GPS, the Garmin transponder, the engine monitor, or the ADS-B Out
transmitter. For that matter, think about non-aviation applications: home
routers, Roku / AppleTV set-top boxes, office phones. Many of these run
Linux. None of them have a shutdown process that's required to avoid
corrupting the boot image.
The real solution here is to have Stratux run in read-only mode using a
ramdisk for ephemeral data - DHCP leases, etc. If you want / need to log,
you can either create a separate partition on the uSD card or use a USB
flash drive.
On Mon, Dec 21, 2015 at 9:51 AM, Joseph Poirier <
<EMAIL_ADDRESS>wrote:

I'd posted a gpio solution a while back: "

https://www.reddit.com/r/stratux/comments/3hw2x8/rpi2_power_off_button/"

On Mon, Dec 21, 2015 at 9:38 AM, braddward<EMAIL_ADDRESS>wrote:

This could be a solution. You could shutdown either via the web
interface
or by wiring a momentary switch to one of the gpio pins. The code
could
monitor for the gpio being activated and then calling the shutdown
function.

http://piplay.org/forum/discussion/564/shutdown-button-using-gpio-pin/p1

—
Reply to this email directly or view it on GitHub
https://github.com/cyoung/stratux/pull/152#issuecomment-166332996.

—
Reply to this email directly or view it on GitHub
https://github.com/cyoung/stratux/pull/152#issuecomment-166337517.

--
Steven Sokol
408 Camelot Drive
Liberty, MO 64068
mobile: +1<PHONE_NUMBER>
fax: +1<PHONE_NUMBER>
—
Reply to this email directly or view it on GitHub
https://github.com/cyoung/stratux/pull/152#issuecomment-166348455.

—
Reply to this email directly or view it on GitHub
https://github.com/cyoung/stratux/pull/152#issuecomment-166353244.

--
Steven Sokol
408 Camelot Drive
Liberty, MO 64068
mobile: +1<PHONE_NUMBER>
fax: +1<PHONE_NUMBER>

The SDR code is pretty stable. Perhaps the group agrees (or not) that we finish stabilizing the SDR code, add any related "nice to have" stuff, and add read-only support and base line the Stratux 1.0 version.
I'm not suggesting we remove the other functionality; just consider that work "beta" and the SDR work "release".
The follow on work would include any bug fixes for SDR support and focus on the GPS/AHRS features.
Does that sound reasonable to others?

My intention is to power my Stratux through the cigar lighter and it will manically lose power when I hit the master. Is that what most envision ? I don't typically do anything elaborate to shutdown my avionics.
-Roberr

On Dec 21, 2015, at 8:22 AM, Steven Sokol<EMAIL_ADDRESS>wrote:
My opinion only, but...
This is all trying to solve the problem the wrong way. Embedded electronics
(even those built on higher-order platforms like the Pi) don't have a
graceful shutdown procedure. I don't have to gracefully power down the King
KLN-94 GPS, the Garmin transponder, the engine monitor, or the ADS-B Out
transmitter. For that matter, think about non-aviation applications: home
routers, Roku / AppleTV set-top boxes, office phones. Many of these run
Linux. None of them have a shutdown process that's required to avoid
corrupting the boot image.
The real solution here is to have Stratux run in read-only mode using a
ramdisk for ephemeral data - DHCP leases, etc. If you want / need to log,
you can either create a separate partition on the uSD card or use a USB
flash drive.
On Mon, Dec 21, 2015 at 9:51 AM, Joseph Poirier<EMAIL_ADDRESS>wrote:

I'd posted a gpio solution a while back: "
https://www.reddit.com/r/stratux/comments/3hw2x8/rpi2_power_off_button/"
On Mon, Dec 21, 2015 at 9:38 AM, braddward<EMAIL_ADDRESS>wrote:

This could be a solution. You could shutdown either via the web interface
or by wiring a momentary switch to one of the gpio pins. The code could
monitor for the gpio being activated and then calling the shutdown
function.
http://piplay.org/forum/discussion/564/shutdown-button-using-gpio-pin/p1
—
Reply to this email directly or view it on GitHub
https://github.com/cyoung/stratux/pull/152#issuecomment-166332996.

—
Reply to this email directly or view it on GitHub
https://github.com/cyoung/stratux/pull/152#issuecomment-166337517.

--
Steven Sokol
408 Camelot Drive
Liberty, MO 64068
mobile: +1<PHONE_NUMBER>
fax: +1<PHONE_NUMBER>
—
Reply to this email directly or view it on GitHub.

Perhaps the group agrees (or not) that we finish stabilizing the SDR code

What sort of things do you have in mind re: this?
Read only should definitely be a "1.0 feature", would rather not fork the releases right now because that will slow us down in a number of ways.

BTW: @kdknigga, I have not looked at your RO implementation but with the exception of DHCP leases, I had an RPi project that was read-only and it was not difficult. It booted as RO and had two command scripts to switchRW and switchRO. The related "switching commands" were used primarily when config file changes were made. eg: switchRW; change conf file; switchRO.
My guess is you had a more robust solution that I did. My solution lost DHCP leases with the reboot since they were mapped to tmp which was in RAM.

@cyoung - I was not suggesting we fork the code; but instead

make a final push on anything needed for SDR support
add read-only support (and make it what happens when the RPi boots)
test
release as 1.0

On Mon, Dec 21, 2015 at 10:56 AM, cyoung<EMAIL_ADDRESS>wrote:

Perhaps the group agrees (or not) that we finish stabilizing the SDR code
What sort of things do you have in mind re: this?
Read only should definitely be a "1.0 feature", would rather not fork the
releases right now because that will slow us down in a number of ways.

I concur that releases, 1.0+,  be read only.

My question would be is if we want to merge everything into a single release image that even beta testers/developers and normal users alike will use, or perhaps cut some features out for the non-developer version. Features like replay logging seem more like a complication on a r/o release for users that likely will never touch it.

@cyoung - I missed that angle to your question. I would rather not fork the code. Instead, I would use a conditional compile flag to cut the developer realted features out of a real release build.

On Mon, Dec 21, 2015 at 11:14 AM, cyoung<EMAIL_ADDRESS>wrote:

My question would be is if we want to merge everything into a single
release image that even beta testers/developers and normal users alike will
use, or perhaps cut some features out for the non-developer version.
Features like replay logging seem more like a complication on a r/o release
for users that likely will never touch it.

My gut feeling is that not having diagnostics on a release is a mistake.
Will the removal of features for a release potentially create a large
enough delta between the beta and the release such that the release isn't
representative of what was tested in beta?

—
Reply to this email directly or view it on GitHub
https://github.com/cyoung/stratux/pull/152#issuecomment-166363048.

On Mon, Dec 21, 2015 at 11:26 AM, bradanlane<EMAIL_ADDRESS>wrote:

@cyoung https://github.com/cyoung - I missed that angle to your
question. I would rather not fork the code. Instead, I would use a
conditional compile flag to cut the developer realted features out of a
real release build.

Are you saying to just disable features from the front end, i.e. the web
ui, so the functionality isn't available? Note that Go doesn't have a
pre-processor and it doesn't support any kind of #ifdef.

I was not aware of that Golang limitation. It would be possible to refactor the code such that the parts were in separate files but that is extra work for little gain. The alternatives are:

to disable capabilities at the UI
runtime flag

FWIW, I've created a number of embedded Linux products that by default have a ro root file system. Diagnostics/logging can be enabled via the user interface with sufficient warnings to discourage use by the novice user. Alternatively, a "standard non-developer release" could simply not provide the option to enable diagnostics and logging. It is generally easier to maintain if you leave all of the code for supporting diagnostics/logging in place.
Also note that a separate writable partition for logs has advantages. If it becomes corrupted the system can still boot up normally and even detect/fix the corrupted partition. Worst case you lose the captured logs. I have been involved in shipping hundreds of thousands of systems that operate this way over more than 10 years. These systems have never had the luxury of a guaranteed orderly shutdown.

From: Joseph Poirier<EMAIL_ADDRESS>Sent: Monday, December 21, 2015 12:33 PM
To: cyoung/stratux
Subject: Re: [stratux] Shutdown and Reboot functions (#152)
On Mon, Dec 21, 2015 at 11:26 AM, bradanlane<EMAIL_ADDRESS>wrote:

@cyoung https://github.com/cyoung - I missed that angle to your
question. I would rather not fork the code. Instead, I would use a
conditional compile flag to cut the developer realted features out of a
real release build.

Are you saying to just disable features from the front end, i.e. the web
ui, so the functionality isn't available? Note that Go doesn't have a
pre-processor and it doesn't support any kind of #ifdef.

Reply to this email directly or view it on GitHubhttps://github.com/cyoung/stratux/pull/152#issuecomment-166367582.
[https://avatars2.githubusercontent.com/u/642781?v=3&s=400]https://github.com/cyoung/stratux/pull/152#issuecomment-166367582
Shutdown and Reboot functions by braddward · Pull Request #152 · cyoung/stratuxhttps://github.com/cyoung/stratux/pull/152#issuecomment-166367582
github.com
Added a couple of functions to handle rebooting and shutdown of the PI from the status screen. This is a first attempt at contributing to a project so I wanted to keep it simple in the hopes that ...

@bradanlane
Getting RO to work wasn't very hard.  Where I was having problems was using
spindle to generate images.  It took me forever to get it working at all,
and even then it was cumbersome and easy to break.
On Mon, Dec 21, 2015, 10:57 bradanlane<EMAIL_ADDRESS>wrote:

BTW: @kdknigga https://github.com/kdknigga, I have not looked at your
RO implementation but with the exception of DHCP leases, I had an RPi
project that was read-only and it was not difficult. It booted as RO and
had two command scripts to switchRW and switchRO. The related "switching
commands" were used primarily when config file changes were made. eg:
switchRW; change conf file; switchRO.
My guess is you had a more robust solution that I did. My solution lost
DHCP leases with the reboot since they were mapped to tmp which was in RAM.
—
Reply to this email directly or view it on GitHub
https://github.com/cyoung/stratux/pull/152#issuecomment-166358827.

On Mon, Dec 21, 2015 at 11:38 AM, bradanlane<EMAIL_ADDRESS>wrote:

I was not aware of that Golang limitation. It would be possible to
refactor the code such that the parts were in separate files but that is
extra work for little gain. The alternatives are:

to disable capabilities at the UI
runtime flag

Just to expound a bit... Go doesn't support any sort of fine grained
pre-compile switch for lines of code but the Go tool itself does support
file level build tags, e.g. // +build linux, 386 darwin, !cgo. But as you
stated, it would probably only be useful if the code was refactored.

—
Reply to this email directly or view it on GitHub
https://github.com/cyoung/stratux/pull/152#issuecomment-166369304.

yes, "spindle" is not the easiest. For my work on the OPi, I created an "update script" that makes all of my necessary changes.

On Mon, Dec 21, 2015 at 12:03 PM, bradanlane<EMAIL_ADDRESS>wrote:

yes, "spindle" is not the easiest. For my work on the OPi, I created an
"update script" that makes all of my necessary changes.

A script that was able to get stratux setup on live system-run script and
reboot-would be nice.

https://www.reddit.com/r/stratux/comments/3xwpiz/ver_05b2_web_ui_issue/
Any idea?

The shutdown button was working properly for me, no idea why it's not
working for others. It might be worth trying exec.Command instead:
cmd = "sudo shutdown -h now"
output, _ := exec.Command("/bin/sh", "-c", cmd).Output()
log.Printf("Shutdown cmd output: %s", output)
On Tue, Dec 22, 2015 at 8:08 PM, cyoung<EMAIL_ADDRESS>wrote:

https://www.reddit.com/r/stratux/comments/3xwpiz/ver_05b2_web_ui_issue/
Any idea?
—
Reply to this email directly or view it on GitHub
https://github.com/cyoung/stratux/pull/152#issuecomment-166783854.

@braddward - https://vid.me/TKwU

There are a few tweaks that will make this new feature better.

Instructions for the buttons need to be added to the context help.
Confirmation would be nice given the functions being enabled
The page redirect needs to happen after conformation and before execution.
The interface is more applicable to the "settings" page rather than the status page.

The design of the buttons could use a little UX love too :-)

Thanks for the feedback and I agree with all of it.
I may need to add a bootstrap plug in to do the confirmations and feedback.   I'm more of a back-end dev than front-end (hmmm - that doesn't sound so good)...

Yes, moving to the settings page.  If you want to restyle feel free and I can merge it in.  Otherwise I was just planning on styling them as plain buttons. N

On Dec 31, 2015, at 5:38 PM, bradanlane<EMAIL_ADDRESS>wrote:
As part of the refactoring, did you move the buttons to the "settings" page? I think that's a better place for them.
I'd like to adjust the styling of the buttons as well but if you're in the middle of changes, I can hold off.
—
Reply to this email directly or view it on GitHub.

Yes, moving to the settings page.  If you want to restyle feel free and I can merge it in.  Otherwise I was just planning on styling them as plain buttons. N

On Dec 31, 2015, at 5:38 PM, bradanlane<EMAIL_ADDRESS>wrote:
As part of the refactoring, did you move the buttons to the "settings" page? I think that's a better place for them.
I'd like to adjust the styling of the buttons as well but if you're in the middle of changes, I can hold off.
—
Reply to this email directly or view it on GitHub.

Thanks @braddward. I'll figure out the design and send you the markup/styling.

Thanks @braddward. I'll figure out the design and send you the markup/styling.

Well @RobertGary1 - you must have been psychic.  Just heard that the DPE we were going to use next week has an issue and is unable to do check rides....   My CFI is looking for alternatives.

Hey, more time to work on Stratux :)
Progress has been amazing. Will be cool to get ahrs working in flight. Not sure if it's a frequency polling limitation or needs a more complex algorithm. I may take a look. It's hard because you can't simulate normal ahrs reaction on the ground.
-Robert

On Jan 2, 2016, at 8:33 AM, braddward<EMAIL_ADDRESS>wrote:
Well @RobertGary1 - you must have been psychic. Just heard that the DPE we were going to use next week has an issue and is unable to do check rides.... My CFI is looking for alternatives.
—
Reply to this email directly or view it on GitHub.

As far as the AHRS goes.  I wonder if Vibration is effecting it.  I found even going into a rather steep climb angle would show a climb and the.   Pretty sure I was not in a "coordinated"  climb.  Since there is no such thing in the pitch angle.
Sent from my iPhone

On Jan 2, 2016, at 10:35 AM, RobertGary1<EMAIL_ADDRESS>wrote:
Hey, more time to work on Stratux :)
Progress has been amazing. Will be cool to get ahrs working in flight. Not sure if it's a frequency polling limitation or needs a more complex algorithm. I may take a look. It's hard because you can't simulate normal ahrs reaction on the ground.
-Robert

On Jan 2, 2016, at 8:33 AM, braddward<EMAIL_ADDRESS>wrote:
Well @RobertGary1 - you must have been psychic. Just heard that the DPE we were going to use next week has an issue and is unable to do check rides.... My CFI is looking for alternatives.
—
Reply to this email directly or view it on GitHub.

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

You can on a motorcycle.  :)
On 01/02/2016 12:35 PM, RobertGary1 wrote:

Hey, more time to work on Stratux :)
Progress has been amazing. Will be cool to get ahrs working in flight.
Not sure if it's a frequency polling limitation or needs a more
complex algorithm. I may take a look. It's hard because you can't
simulate normal ahrs reaction on the ground.
-Robert

On Jan 2, 2016, at 8:33 AM, braddward<EMAIL_ADDRESS>wrote:
Well @RobertGary1 - you must have been psychic. Just heard that the
DPE we were going to use next week has an issue and is unable to do
check rides.... My CFI is looking for alternatives.
—
Reply to this email directly or view it on GitHub.

—
Reply to this email directly or view it on GitHub
https://github.com/cyoung/stratux/pull/152#issuecomment-168415216.


MGMT-15189: remove debug-install flag

The --debug-install flag is now redundant since a public ssh key can now be specified in the config-image (as part of install-config.yaml).

It is out of scope for this PR, but we need a dev (or debug) guide that tells this to users. I know the info probably exists in OpenShift docs.

It is out of scope for this PR, but we need a dev (or debug) guide that tells this to users. I know the info probably exists in OpenShift docs.

RIght, it's part of the install-config: https://docs.openshift.com/container-platform/4.13/installing/installing_with_agent_based_installer/preparing-to-install-with-agent-based-installer.html#installation-bare-metal-agent-installer-config-yaml_preparing-to-install-with-agent-based-installer
We have some reference to it in the readme: https://github.com/openshift/appliance#configuration-iso


Download dataframe from visualization resault

From the visualization node UI, provides a button to download the result as a csv or a json file

We need to implement the export to csv / json file function on runner side.


added pfsense configuration guide

Looks like github just didn't want to built it, manual build was successful


Note on Configuration Documenter Tool

Hello,
This page makes reference to Azure AD Connect configuration documenter, an open source tool with limited support not bundled with AAD Connect product. We may wish to add a note in this regard. Thank you!

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: be523268-53e3-43f1-21ce-c1e7d5210a9c
Version Independent ID: 04b16d87-3a21-aee0-2233-b65f087bd952
Content: Azure AD Connect sync: Operational tasks and considerations
Content Source: articles/active-directory/hybrid/how-to-connect-sync-staging-server.md
Service: active-directory
Sub-service: hybrid
GitHub Login: @billmath
Microsoft Alias: billmath

@josuvil
Thanks for your feedback! We will investigate and update as appropriate.

Thanks! I think this is good feedback. I made a pull request to add a note to the document. https://github.com/MicrosoftDocs/azure-docs-pr/pull/167302


Consolidated and clarified some logic. Added more thorough javadocs.

Pull Request Test Coverage Report for Build 5982

8 of 8 (100.0%)  changed or added relevant lines in 1 file are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 100.0%

Totals

Change from base Build 5979:
0.0%

Covered Lines:
881

Relevant Lines:
881

💛  - Coveralls


Actually address parsing/http errors by sending the appropriate response

Right now we just error! when there is an error. This is bad and we should instead send correct responses, i.e. 413 if a header is too long.

Hi !
I was looking at the issues and this one turned up a question for me: how headers are dealt with?
I kinda had a clue looking at hyper/src/http/h1.rs, but I can't find references to how a a too long header field is dealt with (i.e: a Content-Type with an massive amount of chars as value) and how a massive amount of header fields is dealt with (I kinda crossed my eyes at MAX_HEADERS, but my Rust is not so advanced :c)
Ty for reading !

I tried and failed. Field notes:
Tried to write a test in src/http/h1.rs (after temporarily making MAX_BUFFER_SIZE public).
    #[test]
    fn test_parse_too_large() {
        let mut request : Vec<u8> = b"GET / HTTP/1.1\r\nHost:  ".iter().cloned().collect();
        let mut long_header = vec!(b'X', MAX_BUFFER_SIZE as u8 + 1);
        let mut footer : Vec<u8> = b"\r\n\r\n".iter().cloned().collect();
        request.append(&mut long_header);
        request.append(&mut footer);
        let mut raw = MockStream::with_input(&request[..]);
        let mut buf = BufReader::new(&mut raw);
        println!("{:?}", parse_request(&mut buf));
    }

Was able to get a Err(Header) result, but then wasn't sure whether a) that was correct, or b) what might then map that to a status. I was trying to elicit an Error::TooLarge response from parse method (line 867):
        match try!(rdr.read_into_buf()) {
            0 if rdr.get_buf().is_empty() => {
                return Err(Error::Io(io::Error::new(
                    io::ErrorKind::ConnectionAborted,
                    "Connection closed"
                )))
            },
            0 => return Err(Error::TooLarge),
            _ => ()
        }

BufReader itself won't return an error condition, it does call try!(read) on the internal buffer though. Couldn't figure a way to wire up MockStream to it in a way that would fail properly.
Then I tried a different approach: try to elicit failure with an end-to-end test.
extern crate hyper;

use std::io::Read;

use hyper::Client;
use hyper::header::Connection;
use hyper::header::UserAgent;

fn main() {
    let client = Client::new();

    let res = client.get("http://localhost:3000/")
        .header(Connection::close())
        .header(UserAgent(std::iter::repeat("X").take(1000000).collect::<String>()))
        .send().unwrap();

    println!("{:?}", res.status);
}

This panics on the unwrap:
thread '<main>' panicked at 'called `Result::unwrap()` on an `Err` value: Io(Error { repr: Custom(Custom { kind: ConnectionAborted, error: StringError("Connection closed") }) })',

Running against http://google.com (sorry google) I found a sweet spot at 100000 chars, where I get a PayloadToLarge response, which I can't get from hyper. Bigger than that I get a broken pipe error.
I also tested against a naive Ruby webrick server and wasn't able to get a failure, it just takes longer and longer to parse the request (seems bad).
Back to hyper, maybe the server is explicitly terminating the connection if some buffer size is exceeded? I tried using the server from the README and enabling logging with export RUST_LOG=trace (I see there are trace! calls already), but that only enabled tracing withing cargo and rustc, not my test binary or hyper. I placed a println! and a trace! next to each other right at the hyper entry point and only the println! worked.
Then I gave up :(
Potential next steps for anyone who wants to pick this up:

Figure out how to enable tracing (this should be straightforward...)
Find where (if?) hyper is explicitly closing the connection on large headers, using the test client code above.
Work backwards from there.

To enable logging with RUST_LOG, you need to initialize the logger implementation which reads that environment variable via the env_logger crate. Just add env_logger::init().unwrap() at the top of your main and run with RUST_LOG=hyper=trace to get all logs from hyper only.

Hi @reem @seanmonstar,
I've made some work on this but I'm stuck with a test.
https://github.com/ctjhoa/hyper/commit/d1b4563ada8821df308cbd3ab88696fe854b5a50
In test_check_error_431 the mock return 2 responses and I don't know why.
Can you tell me what am I doing wrong and if the structure meet your expectations?
Thanks.

This will be deferred to the user's Handler, as described in #881


Update on Open-Sourcing Frontend Code

I know there is already issue #47 about this, but I didn't hear back any response, so I was wondering if the frontend is actually going to be open-sourced or not?
Could you please provide an update on the plans and timeline for open-sourcing the frontend code?

Hi @Subashkatel, thank you for your patience. There was a lot of uncertainty around this so I didn't want to communicate anything incorrect w/o some clarity. Currently the expectation is that it is at least 2 months away due to the level of internal only code that we cannot open source. It's effectively a refactor -- so we will open source this eventually. For now I will close this issue as a duplicate and will make this same comment on that issue.

Thank you for the response!


Ars magica

Changes / Comments
-- Minor update to css, trying to fix the problem of styling not applying in the roll20 dropdown version to the repcontrol button.
Roll20 Requests
Comments are very helpful for reviewing the code changes. Please answer the relevant questions below in your comment.

[ ] Does the pull request title have the sheet name(s)? Include each sheet name.
[ ] Is this a bug fix?
[ ] Does this add functional enhancements (new features or extending existing features) ?
[ ] Does this add or change functional aesthetics (such as layout or color scheme) ?
[ ] If changing or removing attributes, what steps have you taken, if any, to preserve player data ?
[ ] If this is a new sheet, did you follow Building Character Sheets standards ?

If you do not know English. Please leave a comment in your native language.

Hello @Medieve the PR looks solid except 'Patreon' is capitalized in the json but it needs to be lower-case 'patreon'

Fixed the P and the conflict


Bad config encountered during initialization Unrecognized flag: '--py'

dta@dta-Inspiron-N5050 ~ $ pip install https://github.com/ipython-contrib/IPython-notebook-extensions/archive/master.zip --user
Collecting https://github.com/ipython-contrib/IPython-notebook-extensions/archive/master.zip
  Downloading https://github.com/ipython-contrib/IPython-notebook-extensions/archive/master.zip
     / 9.5MB 938kB/s
Requirement already satisfied (use --upgrade to upgrade): ipython>=4 in ./anaconda3/lib/python3.5/site-packages (from Python-contrib-nbextensions===alpha)
Requirement already satisfied (use --upgrade to upgrade): jupyter in ./anaconda3/lib/python3.5/site-packages (from Python-contrib-nbextensions===alpha)
Requirement already satisfied (use --upgrade to upgrade): psutil>=2.2.1 in ./anaconda3/lib/python3.5/site-packages (from Python-contrib-nbextensions===alpha)
Requirement already satisfied (use --upgrade to upgrade): pyyaml in ./anaconda3/lib/python3.5/site-packages (from Python-contrib-nbextensions===alpha)
Installing collected packages: Python-contrib-nbextensions
  Running setup.py install for Python-contrib-nbextensions ... done
Successfully installed Python-contrib-nbextensions
dta@dta-Inspiron-N5050 ~ $ jupyter nbextension enable --py --sys-prefix widgetsnbextension
Configure an nbextension to be automatically loaded

Options
-------

Arguments that take values are actually convenience aliases to full
Configurables, whose aliases are listed on the help line. For more information
on full configurables, see '--help-all'.

--generate-config
    generate default config file
-y
    Answer yes to any questions instead of prompting.
--debug
    set log level to logging.DEBUG (maximize logging output)
--section=<Unicode> (EnableNBExtensionApp.section)
    Default: 'notebook'
    Which config section to add the extension to. 'common' will affect all
    pages.

To see all available configurables, use `--help-all`

[EnableNBExtensionApp] CRITICAL | Bad config encountered during initialization:
[EnableNBExtensionApp] CRITICAL | Unrecognized flag: '--py'

This is down to the notebook version you have - the --py flag for the jupyter nbextensions app was added in version 4.2, so you may need to
pip install --upgrade notebook

as you can see above, the requirements are not set correctly then:
Requirement already satisfied (use --upgrade to upgrade): ipython>=4

Except, as I've mentioned before, in #591, widgetsnbextension is provided
by the ipython/ipywidgets repo, and is nothing to do with this repo...
On 4 May 2016 2:55 p.m., "denfromufa"<EMAIL_ADDRESS>wrote:

as you can see above, the requirements are not set correctly then:
Requirement already satisfied (use --upgrade to upgrade): ipython>=4
—
You are receiving this because you commented.
Reply to this email directly or view it on GitHub
https://github.com/ipython-contrib/IPython-notebook-extensions/issues/599#issuecomment-216872218

ok, so let me close this issue then and maybe open new one in ipywidgets, at least the hyper-link is retained now.

Even if it were from this repo, do we advise using jupyter nbextension enable --py anywhere in our docs? If we do, then that might be worth adding warnings to...

this is from uploadfile extension that I'm struggling with:
https://github.com/peteut/ipython-file-upload/issues/7
On Wed, May 4, 2016 at 9:00 AM, Josh Barnes<EMAIL_ADDRESS>wrote:

Even if it were from this repo, do we advise using jupyter nbextension
enable --py anywhere in our docs? If we do, then that might be worth
adding warnings to...
—
You are receiving this because you modified the open/close state.
Reply to this email directly or view it on GitHub
https://github.com/ipython-contrib/IPython-notebook-extensions/issues/599#issuecomment-216874046

Hmm, a quick look at that issue doesn't suggest to me anything obvious... is it ok to close this again, and deal with it over at https://github.com/peteut/ipython-file-upload/issues/7?


Fix type prop issue in conditional exports

Fixes https://github.com/bufbuild/protobuf-es/issues/209
If consumers try to import protobuf-es and configure their tsconfig.json file to use moduleResolution: "NodeNext", they experience issues resolving our declaration files.  This is because we specify conditional exports and the NodeNext module resolution will use this exports map to resolve modules.  Unfortunately, it also uses this to resolve types.  Since we didn't specify a types property there, declaration files couldn't be found.
For more context:

https://github.com/microsoft/TypeScript/issues/48235
https://devblogs.microsoft.com/typescript/announcing-typescript-4-5-beta/#esm-nodejs

In addition, this modifies our TypeScript tests to test against 4.7.4 and 4.8.2 using NodeNext module resolution (usage of this value with anything below 4.7 errors out because it is marked experimental in those versions).

Yep, I am planning to release a patch release today that fixes this.  Just want to test a few things before I do.  I will post here when I do.

@faustbrian We just published v0.1.1 of protobuf-es, so you should be able to install and get support for NodeNext.  Let me know if this fixes your issue.

Can you share the compilerOptions from your tsconfig.json file?  I am able to build with v0.1.1 and NodeNext in my config.

OK, I am able to recreate with your repo and in a sample repo I have here.  The issue seems to be with generating declaration files with a moduleResolution of "NodeNext".  A few different magic incantations of compilerOptions will get around the issue, but obviously that's just a band-aid I think.  For example:

setting noEmit to false will compile successfully.
setting noEmit to true, but declaration and declarationMap to  false will compile successfully.
setting moduleResolution to Node will compile successfully.

I see what the issue is on our side and why this is happening.  What's curious to me is why it's only happening with NodeNext module resolution.  I will discuss the best way forward with our team and keep you posted.  In the meantime, you may have to use one of the above workarounds.  Apologies for the inconvenience.

Alternatively, you could set your target out to be js+dts in your buf.gen.yaml.  This way the TypeScript compiler won't compile the generated protobuf-es code.  This should also work and still allow you to emit declaration files with NodeNext module resolution.


[ldd-img] segment_number allow 0

img:segment_number (part of compression) needs to start at 0 not 1, so please set the range min to 0 instead of 1.
(alternatively we could add one to make it 1-based, but this "feels" more like a 0-based count to me).

update to min=0 in v1800 branch


Adapt FIO lookup to mainnet FIO domains (@trust, ...).

So far only '@fiotestnet' was treated as FIO domain.  Include the following domains to be checked as a FIO name:
@trust
@trustwallet
@binance
@fiomembers
@  // any FIO domain

Note that any 'something@something' address will be assumed to be FIO, no other lookup scheme uses '@' as separator.

can you add FIO public key to test? coin 235


feat: add svelte/Infinite-reactive-loop rule

close: https://github.com/ota-meshi/eslint-plugin-svelte/issues/299

@ota-meshi What do you think about the current specification and implementation? Do you think there are TODOs?

I misunderstood that this PR was still in the work in progress 😓. I will make time to check this PR. So please wait :pray:


Consider creating oneMKL releases

To continue the discussion from https://github.com/oneapi-src/oneMKL/issues/459, I would like to suggest introducing quarterly releases for oneMKL. This would be useful:

for users to know which version is expected to work with a release of the oneAPI base toolkit
for users to be able to download a package of oneMKL

We have a use-case in GROMACS where users would like to download and use pre-built packages
I expect this will be easier than shipping oneMKL interface with the oneAPI base toolkit

for the oneMKL CI, this helps reduce the number of configurations to test

We would only need to test compiler releases with oneMKL releases and compiler nightlies with oneMKL nightlies

There are some releases existing in oneMKL, I don't know if there are any plans to continue these releases quaterly?
I would suggest to start adding a release candidate tag 2025.0.rc0 end of July. If we find bugs in oneMKL we create new release candidate tags on commits fixing them. When oneAPI 2025.0 is released we can use the latest release candidate as a stable release.
I think for now the pre-built packages could be built for Ubuntu 22.04 and include all the domains and backends using MKL, CUDA and ROC libraries. We will need to clarify who is responsible for building and uploading the package to the releases.

@Rbiessy I personally find it ineffective to start and continue a broad discussion like this over github. I would suggest setting up a meeting to bring all key people up to speed with previous discussions and new proposals, and then clear up final details over github.

We have a use-case in GROMACS where users would like to download and use pre-built packages

Ideally, this should be bundled with the main Codeplay plugin (or, as mentioned, oneAPI base toolkit).
The need to install Intel oneAPI and NVIDIA/AMD Plugin is already not ideal. Installing pre-built package is better than building from scratch, but the need to install three packages, on top of the vendor runtime, while making sure all the versions match (and if CUDA/HIP or oneAPI get updated, then the Plugin and the oneMKL will have to be downloaded again) is not very user-friendly.
If bundling stuff together is not possible, another alternative would be to provide an APT and YUM repositories for "desktop" users and a Spack recipe for supercomputer users.

could you explain that bundling stuff together is not possible ?  Thanks.

@Rbiessy I personally find it ineffective to start and continue a broad discussion like this over github. I would suggest setting up a meeting to bring all key people up to speed with previous discussions and new proposals, and then clear up final details over github.

In the interest of open governance it would be great if as much as possible could be discussed in public so that anyone from the community can participate. Can we facilitate meetings through the UXL Foundation groups?


[Bookry.Wavebox version 10.0.542.2] 0x80190194 : Not found (404).

Fixed in https://github.com/microsoft/winget-pkgs/pull/28384.


[Snyk] Security upgrade next from 12.2.4 to 14.2.15

Snyk has created this PR to fix 1 vulnerabilities in the npm dependencies of this project.
Snyk changed the following file(s):

package.json
package-lock.json

Vulnerabilities that will be fixed with an upgrade:

Issue
Score

Missing Authorization SNYK-JS-NEXT-8520073
  696

[!IMPORTANT]

Check the changes in this PR to ensure they won't cause issues with your project.
Max score is 1000. Note that the real score may have changed since the PR was raised.
This PR was automatically created by Snyk using the credentials of a real user.

Note: You are seeing this because you or someone else with access to this repository has authorized Snyk to open fix PRs.
For more information:
🧐 View latest project report
📜 Customise PR templates
🛠 Adjust project settings
📚 Read about Snyk's upgrade logic

Learn how to fix vulnerabilities with free interactive lessons:
🦉 Missing Authorization

👷 Deploy Preview for localhostorange processing.

Name
Link

🔨 Latest commit
8beece20ea82558216d34b6957a2adab4cf0331f

🔍 Latest deploy log
https://app.netlify.com/sites/localhostorange/deploys/6767b0121f084d0008efc4bf


Swap out busybox image to quay.io

This is to ensure fewer rate limit issues via dockerhub.

@thunderboltsid best is use a more official busybox image and not a random one coming from Prom project
we can go with cgr.dev/chainguard/busybox


Test Case: MUTECT2 detects Difficult LINE-1 insertion

@chandrans commented on Mon Apr 18 2016
Feature request/Test Case
Tool(s) involved
MuTect2
Description
A user gave Congratulations because MuTect2 detected this insertion, but other callers did not. Please write a test case so MuTect2 will always detect this Line-1 insertion.
Test Files
/humgen/gsa-scr1/schandra/Bogdan_MuTect2DetectsInsertion/LINE1-insertion-in-TP53
Command
java -jar /humgen/gsa-hpprojects/GATK/bin/current/GenomeAnalysisTK.jar -T MuTect2 -R /humgen/gsa-scr1/schandra/hg38/hg38bundle/Homo_sapiens_assembly38.fasta -I:normal subset_normal_TP53_chr17.7674948-7674948_SPCG-OS040_7G.GRCh38p5M.MD_intervals_hg38_male.interval_list.IR.RC.bam.bam -I:tumor subset_tumor_TP53_chr17.7674948-7674948_SPCG-OS040_8T.GRCh38p5M.MD_intervals_hg38_male.interval_list.IR.RC.bam.bam -L chr17:7674648-7675248 -o Sheila.MuTect2.vcf -bamout Sheila.MuTect2.bam

@takutosato commented on Fri Apr 29 2016
This is an interesting site. I looked at it on IGV with Yossi and Chris. We think there is an insertion but we are less sure that the allele is right. It's probably a long insertion, as reads in the tumor bam show two sets of soft-clipped bases, depending on how the reads 'enter' the insertion. That is, we see both ends of the insertion as two sets of soft clipped reads but we don't observe what's in the middle. HaplotypeCaller seems to pick one end of the insertion somewhat arbitrarily and call that. We should call this insertion but I want to understand why HaplotypeCaller does what it does. Aside: the mates of reads with soft-clipped bases map to a SINE region in chromosome 19.
Two more issues about this test case:

The evidence for the insertion comes exclusively from reverse reads. The brand new M1 strand-bias filter dutifully catches it.
Bam-out comes out garbled and cannot be loaded in IGV.

(top: bam-out. bottom: tumor-bam)

@takutosato commented on Fri Apr 29 2016
java command:
java -jar /$mygatk \
-T MuTect2 \
-R /humgen/gsa-scr1/schandra/hg38/hg38bundle/Homo_sapiens_assembly38.fasta \
-I:normal subset_normal_TP53_chr17.7674948-7674948_SPCG-OS040_7G.GRCh38p5M.MD_intervals_hg38_male.interval_list.IR.RC.bam.bam \
-I:tumor subset_tumor_TP53_chr17.7674948-7674948_SPCG-OS040_8T.GRCh38p5M.MD_intervals_hg38_male.interval_list.IR.RC.bam.bam \
-L chr17:7674648-7675248 \
-o takuto.MuTect2.vcf \
-bamout takuto.MuTect2.bam.out

@yfarjoun commented on Fri Apr 29 2016
I think that this points to interesting possible improvements to the
assembly engine...but first: several questions:

do the mates of reads from btoh alleles map to the same SINE on chr19?
do they map in a reasonable way (i.e. to the two ends of that SINE)?
I see some short "purple" reads at the bottom of your screenshort
(pointing to the right) what's up with those? are the soft-clipped? the
look like they might "want" to give evidence to the other strand, but for
somereason are not counted.

Thanks!!
On Fri, Apr 29, 2016 at 1:57 PM, Takuto Sato<EMAIL_ADDRESS>wrote:

This is an interesting site. I looked at it on IGV with Yossi and Chris.
We think there is an insertion but we are less sure that the allele is
right. It's probably a long insertion, as reads in the tumor bam show two
sets of soft-clipped bases, depending on how the reads 'enter' the
insertion. That is, we see both ends of the insertion as two sets of soft
clipped reads but we don't observe what's in the middle. HaplotypeCaller
seems to pick one end of the insertion somewhat arbitrarily and call that.
We should call this insertion but I want to understand why HaplotypeCaller
does what it does. Aside: the mates of reads with soft-clipped bases map to
a SINE region in chromosome 19.
Two more issues about this test case:

The evidence for the insertion comes exclusively from reverse reads.
The brand new M1 strand-bias filter dutifully catches it.
Bam-out comes out garbled and cannot be loaded in IGV.

(top: bam-out. bottom: tumor-bam)
[image: image]
https://cloud.githubusercontent.com/assets/5185538/14924563/37712e04-0e11-11e6-90dc-540ad77fb2c9.png
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub
https://github.com/broadinstitute/gsa-unstable/issues/1348#issuecomment-215830351

@takutosato commented on Fri Apr 29 2016
We only have the coordinates of the mates because the user only gave us a subset of the bam. But the match between the SINE and our soft-clipped base is pretty good:
-- Insertion called --
TTGTGCCACTGCACTCCAGCCTGGGCGACAGAGCGAGACTCCGTCTCAAAAAAAAAAA
-- SINE --
hg38_rmsk_AluY range=chr19:44963314-44963624 5'pad=0 3'pad=0 strand=- repeatMasking=none
GGCTGGGTGCGGTGGCTCACACCTGTAATCGCAGCACTTTGGGAGGCCAA
GGCAGGCGGATCATGAGGTCAGGAGATAGAGACCATCCTGGCTAACACGG
TGAAACCCCATCTCTACTGAAAATACAAAAAATTAGCCAGGTGTGGTGGC
GGGTGCCTGTAGTCCCAGCTACTCGGGAGGCTGAGGCAGGAGAATGGCGT
GAACCCGGGAGGCGGAGCTTGCAGTGAGCCAAGATTGTGCCACTGCACTC
CAGCCTGGGCGACAGAGCGAGACTCCGTCTCAAAAAAAAAAAAAAATACA
TAAAATAAAAA
-- Match (using Align Sequences Nucliotide BLAST) --

As you can see, our called insertion exactly matches near the end of SINE.
The other set of soft-clipped bases (the one that HaplotypeCaller decided not to call) matches exactly to the SINE too, this time near the middle. See the subject indices in the matches - the soft-clipped reads miss each other by 4 bases!
-- The soft-clipped bases --
GTCCCAGCTACTCGGGAGGCTGAGGCAGGAGAATGGCGTGAACCCGGGAGGCGGAGCTTGCAGTGAGCCA
-- Match --

@takutosato commented on Fri Apr 29 2016
As for the little purple forward reads - they are hard-clipped. I agree with you @yfarjoun, I think those forward reads would've given us evidence for the insertion, and the site would not have been filtered for strand-bias.

@sooheelee commented on Fri Apr 29 2016
You can expect variability from person to person in where retrotransposons are.

@yfarjoun commented on Fri Apr 29 2016
perhaps it makes sense to reach back to the user and ask for the
hard-clipping to be removed...hardclipping is not in our
best-practices...it might be due to incorrect application of aligner or
something like that. Would be interesting to understand what the
hard-clipping is due to, and if we would get better results if these were
soft-clipped instead.
On Fri, Apr 29, 2016 at 3:39 PM, Takuto Sato<EMAIL_ADDRESS>wrote:

As for the little purple forward reads - they are hard-clipped. I agree
with you @yfarjoun https://github.com/yfarjoun, I think those forward
reads would've given us evidence for the insertion, and the site would not
have been filtered for strand-bias.
—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
https://github.com/broadinstitute/gsa-unstable/issues/1348#issuecomment-215857969

@vdauwera commented on Fri Apr 29 2016
I'll ask if we can get the original data.

@sooheelee commented on Fri Apr 29 2016
If we are at the level of being able to resolve transposable elements, given the reference contains such elements, then do we need to add repeat masking to a workflow that wants to resolve these?
Here's a chart of the level of repeats in hg38: http://www.repeatmasker.org/species/hg.html.

@ldgauthier commented on Wed May 04 2016
@takutosato I wonder where it's anchoring the one-sided insertion?  Did you try a graphOut?  They're pretty painful to sift through, but can be very informative.  You can try running again with "-graph output.dot" and open the results in GraphViz.

@vdauwera commented on Mon Nov 14 2016
Hey all, is this still something you're working on/interested in, or can we close the issue? Or should we move it to GATK4?

We have validations now.  Let's not get bogged down with particular cases unless they teach us something.  Seems like this was just a matter of hard clipping.

This case is nice because it's something MuTect2 can do that you can't do with a pileup-based caller on top of BWA. Although A) we didn't do a perfect job (because this isn't the SV tool) and B) I don't expect any code changes short of a dramatic assembly rewrite to break a regression test based on this case.
Although this reminds me that it's on my list to figure out what we want to do when the assembly engine detects a large SV that we know we can't call from the reads in the active region.  It would be nice to have something that says "we are confident there is an event here, but we are not confident we can call it".  Or maybe the solution is just to run the SV tool once it's ready.


[openvr] Update to 1.23.7

Describe the pull request

What does your PR fix?
Updates openvr to 1.23.7

Which triplets are supported/not supported? Have you updated the CI baseline?
As before, Yes

Does your PR follow the maintainer guide?

Yes

Thanks for the update!


Add UrlWrapper/UrlList abstractions

In preparation for introducing a compatibility flag to change the handling of URLs in the fetch implementation to conform to standards, we need an abstraction over both kj::Url and jsg::Url. This adds that abstraction. It does not change anything to use it yet, but it provides the basics. The next step (in a follow up PR) will be to update all of the fetch API code to use it without with the compatibility flag, then finally add the flag and that switches things over to use jsg::Url
This is part of a refactor meant to improve standards compliance and works towards fixing a bug.
Refs: https://github.com/cloudflare/workerd/issues/1957

think before we embark on this we need a better idea of what we're fixing....

There are a handful of subtle ways we are currently non-comformant with the fetch spec and other runtimes.

The leading and trailing whitespace issue described in #1957 is only part of the story there. The spec calls for the input URL to be parsed using a WHATWG compliant URL parser, which means not just handling leading and trailing whitespace a certain way, but ignoring interspersed tabs and newlines, ignoring invalid percent encodings,
Per the spec, the URL is supposed to be parsed in the Request object constructor, meaning that any parse errors are supposed to be processed then. We currently (intentionally) violate that part of the spec and defer parsing till later. As part of aligning our behavior to the spec, browsers, and other runtimes, with the compat flag the URL will start to be parsed in the Request constructor.
On a redirect response, the spec requires that the Location header be parsed using WHATWG URL rules. We currently parse those using kj::Url. With the compat flag it would be updated to follow the spec.

The fetch API implementation does very little with kj::Url. It mainly only parses the URL to verify the scheme is in fact http:// or https://. It also uses kj::Url to compute relative redirects, but is careful to set the parsing options to avoid interpreting percent encodes, which is otherwise the usual source of conformance problems.

Yep.. and the goal here to keep the interaction with that (and jsg::Url) as minimal as possible here. That minimism doesn't change.

kj::Url is also used elsewhere in our codebase and in KJ itself, but in order for this new UrlWrapper class to be able to help, it seems like we have to change a lot of interfaces to pass UrlWrapper instead of a string. In particular, it seems like kj::HttpService and kj::HttpClient interfaces need to be changed to pass this instead of strings. But that would be a very invasive change, and indeed would require putting this code in KJ rather than here... is that what you had in mind?

Certainly not. What I do plan on is adding a method to jsg::Url that will return a kj::Url without the parsing. Something that would allow trivial conversion from one to the other, bypassing parsing. The intent is to use UrlWrapper only within http.h/c++ as a way of abstracting whether or not the new compat flag for fetch spec compliance is in use or not.

But again, I'm not sure that kj::Url is actually causing any problems in those places, since just about everywhere we are careful to use it with the options that avoid problems.

I don't think we really need to change the vast majority of cases where kj::Url is used. This is specifically just to align our handling of the url for fetch, Request, and Response.

The leading and trailing whitespace issue described in Fetch API is inconsistent with the browser/web API for URL starting with whitespaces #1957 is only part of the story there. The spec calls for the input URL to be parsed using a WHATWG compliant URL parser, which means not just handling leading and trailing whitespace a certain way, but ignoring interspersed tabs and newlines, ignoring invalid percent encodings, etc.

We already use options.percentDecode = false which causes the KJ parser to ignore percent encodings.
I was hoping to get some specific examples of what we do wrong here.

Per the spec, the URL is supposed to be parsed in the Request object constructor, meaning that any parse errors are supposed to be processed then. We currently (intentionally) violate that part of the spec and defer parsing till later. As part of aligning our behavior to the spec, browsers, and other runtimes, with the compat flag the URL will start to be parsed in the Request constructor.

This seems like it could be solved by parsing the input URL and re-serializing it in the request constructor itself (if the compat flag is enabled). I'm fine with that, but it seems like a localized change that doesn't require this wrapper class.

On a redirect response, the spec requires that the Location header be parsed using WHATWG URL rules. We currently parse those using kj::Url. With the compat flag it would be updated to follow the spec.

Again, would like to know specifically what kinds of things we're getting wrong here. I ask because historically there were two things we were getting wrong: interpreting percent escapes (standards say you're not supposed to attempt to decode them) and collapsing consecutive slashes. But, we added options to the KJ URL parser to fix both of these specific problems.
Note that I'm pushing on this in part because we've also noticed real-world use cases where using a standard parser would actually have broken things, and we've tweaked our handling over the years to accommodate these. For example, there are real instances in the wild of HTTP requests whose path contains a # character, and such requests need to be able to proxy through Workers correctly even though passing such a URL to fetch() would not work. I'm worried that making a big change to URL handling could re-introduce some of these problems which we'll then have to re-fix. Whereas if the problems with the KJ URL parser are small and fixable, it might be easier to just do that.

Then, of course, there are old outstanding issues like https://community.cloudflare.com/t/worker-fetch-mangles-location-header-url-on-redirect-from-origin/311984 ... in which using kj::Url for redirect resolution introduces bugs.

Thanks, this is a specific example. It appears that tryParseRelative() specifically is not correctly honoring the allowEmpty option here. This should be a one-liner fix. I wish someone had pointed this out to me before...

I was hoping to get some specific examples of what we do wrong here.

I don't understand. I gave specific examples.

We do not handle leading, trailing, or interspersed whitespace correctly
We're not parsing the URL at the correct time (in the Request constructor)
We're not handling redirect resolution correctly...

Even with the ignoring percent decoding option we still aren't completely correct in the handling. For instance, there are odd cases found in the URL web platform tests like https://a%C2%ADb/ that should be parsed and handled as https://ab  (the specific cases like this from the web platform tests are simplified repros of real world examples). In another example from the Web platform tests, the input url https://example.com/\"quoted\" is expected to be parsed as https://example.com/%22quoted%22, kj::Url parses it incorrectly as https://example.com/"quoted".  Weirder examples from the tests like https://x/?#\uFFFFy is likewise mishandled by kj::Urls parsing. It should be https://x/?#%EF%BF%BFy but kj::Url produces, https://x/?#y ... the point here is that with just a cursory scan through only a subset of the standard web platform test URL samples it's trivial to find examples of cases that the kj::Url parser does not handle correctly. I'm certain there are absolutely more. (test cases duplicated here in ada-url test repo: https://github.com/ada-url/ada/blob/main/tests/wpt/urltestdata.json).

This seems like it could be solved by parsing the input URL and re-serializing it in the request constructor itself (if the compat flag is enabled). I'm fine with that, but it seems like a localized change that doesn't require this wrapper class.

That would end up requiring us to parse the URL twice, once with jsg::Url then again with kj::Url ... and that doesn't resolve the redirect location URL handling which is expected to allow follow the WHATWG URL parsing rules. Double parsing doesn't seem to make sense, especially if our intent is to make the standard URL handling the default behavior.

... I ask because historically there were two things we were getting wrong: interpreting percent escapes (standards say you're not supposed to attempt to decode them) and collapsing consecutive slashes. But, we added options to the KJ URL parser to fix both of these specific problems.

As the above specific examples show we're also getting whitespace handling wrong, required percent-encoding of certain characters, and more. These rules apply both during the initial parse in the Request constructor and resolving the redirect location header. That's more than just making sure tryParseRelativesupports allowEmpty since all of the other issues (whitespace, special characters, etc) would still be an issue.

...For example, there are real instances in the wild of HTTP requests whose path contains a # character, and such requests need to be able to proxy through Workers correctly even though passing such a URL to fetch() would not work. I'm worried that making a big change to URL handling could re-introduce some of these problems which we'll then have to re-fix. Whereas if the problems with the KJ URL parser are small and fixable, it might be easier to just do that.

But that's exactly why we have compatibility flags/dates, isn't it? The same issue exists between using the old kj::Url based implementation of URL verses the new compliant implementation. The compat flag in that case seems to be working rather well. We haven't had anyone complain about URL using standard parsing by default now -- but we have had multiple folks complain about the old non-standard behavior and have advised them to update their compat date to get the correct behavior. Existing workers that are handling an invalid # in the URL path today would continue to work so long as their compat date is set before the as-yet-undetermined default on date of the standard parsing. That seems consistent with our overall strategy. For folks with the newer compat date, the # in the path would be handled just like it would be in any other runtime that is implementing fetch, which seems to be the most desirable option. There would be no need to "re-fix" the # in the path issue.
Could we double parse the URLs (once using jsg::Url, followed by serialization, followed by reparsing with kj::Url). Sure. But that doesn't seem ideal. The jsg::Url parser (backed by ada-url) is a bit faster than kj::Url's implementation in most cases, correctly handles 100% of the web platform test URLs, correctly handles all of the various cases defined by the spec, fixes bugs reported by users, aligns our behavior with the browsers, Node.js, deno, etc. Double parsing just so we can keep the existing kj::Url bits in place seems silly to me.
Oh, side note: another thing I noticed that we're not doing correctly currently in the handling of the redirect location. Our handling logic does not validate that the new resulting URL is http or https the way we do in the initial request (that check is located in parseUrl(...) which is not used in the redirect case). We end up with an "internal error" because of a failed assert in kj/compat/http.cc rather than a more useful response code.

But that's exactly why we have compatibility flags/dates, isn't it?

No. The issue I mentioned is not an issue of compatibility with past Worker versions. It's an issue of whether enabling a simple pass-through Worker on your site might break it. It is important that the answer is "no", regardless of the compat date used.
In the wild, we receive HTTP requests with URLs that contain # characters. These are clearly invalid, but nginx doesn't seem to have a problem passing them through. When a simple pass-through worker is applied, it needs to do the same. Note that if the application tries to actually parse/rewrite the URL, that's a different matter -- we can then throw an exception. But if the application simply passes the request on to origin without inspecting the URL, we need to make sure that we don't mess with # characters.
Now, there are a couple things true of such pass-through workers that we can take advantage of here:

They never call the request constructor passing a string URL. The URL value is always inherited from an existing Request object.
They always have redirect: manual, so I suppose we don't have to interpret redirections.

I think the following strategy would work and would keep the code as simple as possible:

Parse/reserialize the URL in the Request constructor in order to catch invalid URLs, normalize escapes and whitespace, etc.

Use old or new parser based on compat flag.
Don't store the parsed URL in the Request object. Just the string.
For requests received off the wire, don't do any parsing of the URL.

Change the code that checks for http/https schema to just do a prefix match, which should always work if we can assume the URL was sanitized first.
If and only if we need to follow a redirect later (rare!), parse the URL again there for that purpose. I'd be OK with us just always using the new parser for this, but we could also choose new or old parser based on compat flag.


adding ability to detect  handlers from super class.

When handler class is annotated with @InheritSubscribers during registration all DECLARED handler methods from super class will be added to subscribers list.  Handled methods from superclass's superclass
will not be added unless it also has @InheritSubscribers annotation.
As this functionality is explicitly requested by the user by placing InheritSubscribers annotation,
user cannot complain on performance and code complexity.

We're just going to enable this for all types by default. Opt-in not necessary. See #135.


find_by accepting a Proc/Lambda?

Hello!
I have models:
class Rating < ActiveRecord::Base
  belongs_to: :user
  belongs_to: :movie
end

class Movie < ActiveRecord::Base
  has_many :ratings
end

It would be nice to load the @rating like
class RatingsController
  load_resource :movie
  load_and_authorize_resource through: :movie, find_by: -> { {user_id: current_user.id} }, singleton: true

  def show; end
end

And find_by: -> {...} should work in the controller scope where I can use methods like current_user.
What do you think?

Hello Ronald,
is this solving your issue? (https://github.com/CanCanCommunity/cancancan/wiki/Authorizing-controller-actions#override-loading)

I think this also should fit your needs: https://github.com/CanCanCommunity/cancancan/wiki/Authorizing-controller-actions#custom-find. Feel free to reopen if I misunderstood your needs.

Hej people! Thanks for your answers :)
Overloading would do the job. Your were right. But I thought it would be more flexible to expand the find_by option to use not only a parameter but a hash, like ActiveRecord does. So it would generate a query like Movie.ratings.find_by(user_id: current_user.id).

I better see your point now. I'd be glad to accept a PR which implements it!


🔧 REFINING THE CLOSING OF UNNECESSARY FILDES

this was open to discuss the issue found here #29. there's nothing to say for now


fix(Tab): Used default outline for active and focused Tabs

Overview
PR Checklist

~[ ] Related to Abstract designs:~ (informal conversation with Yassine)
[x] Related to JIRA ticket: A11Y-283 A11Y-284
[x] I have run this code to verify it works
[x] This PR includes unit tests for the code change

Description
ButtonBase removes the default outline from active/focused buttons, which is not a behavior we want here. The only button style I can tell was being used from it was the white background.

🚀 Styleguide deploy preview ready!https://5f1f049e7ed8d601f7c866d4--gamut-preview.netlify.appDeploy Logs

@codecaaron good call, I'll make a preview environment of the monolith just to be sure...
...once I figure out why this thing isn't publishing 😐

📬Published Alpha Packages:@codecademy/gamut-labs@1.7.53-alpha.0702ff.0<EMAIL_ADDRESS>
🚀 Styleguide deploy preview ready!https://5f1f14c688c3308c71c8fee5--gamut-preview.netlify.appDeploy Logs

@codecaaron it makes them accessible as we'd hope. Happy.


PythonLanguageClient handling workspace folders in non-standard way

This came up in the LSP Weekly Sync meeting today. PythonLanguageClient::OnSendToServer is modifying the LSP initialize message to claim that workspace folders are supported even though VS does not support them. The recommendation was to instead detect that VS does not support workspace folders (based on capabilities?) and react accordingly on the server side.
There's a 2-3 minute discussion about this starting at 8:45 in the meeting recording.
Afterwards they discuss what SendDocumentOpensAsync is doing (also unexpected), which is likely related.

Pylance has a list of client capabilities, so we should be able to detect if we're running in VS or not and run different logic if needed.

For now, I'll go ahead and close this issue since it doesn't seem to be causing any immediate problems in PTVS. If we receive bug reports related to this issue or if we touch this part of the code in the future, we can certainly consider refactoring it in a more standard way.


[Feat][DevInfra] Add test coverage to CI to measure the covering code of unitest and add banner to README (C++)

Reason for this PR

solution to https://github.com/apache/incubator-graphar/issues/189
What changes are included in this PR?

Add test coverage to CI to measure the covering code of unitest and add banner to README
Are these changes tested?

yes
Are there any user-facing changes?

only README

Hi, @Elssky , Thanks for the contribution. I have asked Apache infrastructure team to add GraphAr to codecov[1]. When the jira ticket is addressed, it is ok to merge this change into main.
[1] https://issues.apache.org/jira/projects/INFRA/issues/INFRA-26024

Good PR! I have a comment,
It seems the coverage report only covers cpp code, it would be better if it also contains java/spark code.
(Surely it can be addressed by another issue/PR)
ref: https://about.codecov.io/language/java/

Good PR! I have a comment, It seems the coverage report only covers cpp code, it would be better if it also contains java/spark code. (Surely it can be addressed by another issue/PR)
ref: https://about.codecov.io/language/java/

yes, I will try to get java/spark code coverage info👌


Add composable variant of builtins.path

@ElvishJerricco PTAL

Ugh, this is so ugly, with all the question marks operators, ors, nulls, optionalAttrs, ... Do we really need this?

Yeah, we need composable filtering for callCabal2nix (the original motivation behind cleanSourceWith) and we need to be able to specify the name for nix-illegal paths (the original motivation behind me adding builtins.path).


Introduce Hermes Band Protocol

Background
This fork of Hermes implements the Band Protocol: this introduces delaying a packet by X seconds. It would be nice to be able to configure this per channel for oracle channels.

Seems like a duplicate of https://github.com/informalsystems/hermes/issues/3298, no?

Yep, didn't see that Luca already opened an issue for this.


Release 1.0.1

Codecov Report

Merging #3 into master will not change coverage.
The diff coverage is n/a.

@@          Coverage Diff          @@
##           master     #3   +/-   ##
=====================================
  Coverage     100%   100%
=====================================
  Files           8      8
  Lines          93     93
=====================================
  Hits           93     93

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 ba43998...85953ac. Read the comment docs.


default jenkins master, jnlp tunnel, to no_proxy list

cherry-picked master fix to create 3.6 version fix for https://bugzilla.redhat.com/show_bug.cgi?id=1573648
@openshift/sig-developer-experience ptal
Have tested against 3.6 cluster using the current k8s plugin we ship there, namely v0.10

/lgtm

/approve


Incentives controller changes

Added IncentivesController2.sol:
compared to current IncentivesController, difference is:
new state variables:
address public VE_VMEX;
address public PENALTY_RECIEVER;
upgrade is safe storage wise because new storage slots are added on the end of the existing ones
setVeVmex - changes veVmex address
setPenaltyReciever - changes address where unboosted rewards will go
claimReward function removed - too complex and not much added value
claimAllRewards function changes so that it takes boost into account
added 3 view functions - getAssetRewardsNum, getAssetRewardAddress, getAssetReward
foundry tests:
[PASS] testClaimManyUsersManyRewards() (gas: 16630341)
[PASS] testClaimManyUsersOneReward() (gas: 8334694)
[PASS] testClaimMaxBoost() (gas: 5592227)
[PASS] testClaimMinBoost() (gas: 5093320)
[PASS] testConfigureRewards() (gas: 4587794)
[PASS] testUpgrade() (gas: 4256693)

@mel0ndev @clothic PR updated, added IncentivesController3.sol which has logic that was in Gauge.sol implemented, but instead of beforeTokenTransfer and afterTokenTransfer it handles things in handleAction which is called from aTokens.
Also it uses scaled balance and supply from aToken so that number stays the same with interest paid.
Balance and supply are standardized on 18 decimals, so that boost formula can function well

Need to fix contract size limit
Warning: Contract code size is 24875 bytes and exceeds 24576 bytes (a limit introduced in Spurious Dragon). This contract may not be deployable on Mainnet. Consider enabling the optimizer (with a low "runs" value!), turning off revert strings, or using libraries.
  --> contracts/protocol/incentives/IncentivesController3.sol:26:1:
   |
26 | contract IncentivesController is
   | ^ (Relevant source part starts here and spans across multiple lines).


TP-Link energy monitoring values all wrong

Home Assistant release (hass --version):
0.62.0
Python release (python3 --version):
Python 3.5.3
Component/platform:
platform: tplink
Description of problem:
The values the HA tplink component reports do not match up with the actual values as reported by the tplink app (Kasa).
Here is what the app reports:

Here is what HA reports:
current_power_w: 0.00 v
voltage: 250.2
total_energy_kwh: 1.880 (what is this value supposed to be, as it doesn't match any even closely)
today_energy_kwh: 0.214
current_a: 0.02
expected
I'd expect to see HA values that reflect the same (or at least close) as above, such as:
current_power_w: 0.00 v
voltage: 250.2
current_a: 0.02
30_day_total_energy_kwh: 33.3
7_day_total_energy_kwh: 16.1
1_day_total_energy_kwh: 0.21
30_day_average_energy_kwh: 1.11
7_day_average_energy_kwh: 16.1
Instead the values don't even match closely.
@DanNixon is this working fine for you?

Hi @timdonovanuk ,
based on your description, I can't find any mistake. I see only a feature request to add the 7 and 30 days total and average values.
The expected 1_day_total_energy_kwh is shown in the attribute today_energy_kwh.
total_energy_kwh should show the lifetime consumption.
Maybe I misunderstood the issue. Could you please clarify.
Thx

So today_energy_kwh is fine but total_energy_kwh doesn't match any expected value that the plug reports!
The plug is the source of truth. So why datalog the value in HA and use that to compute total_energy_kwh when the correct value could just be pulled direct from the plug? If HA is down or the plug is not connected to HA for whatever reason, the total_energy_kwh value will always be incorrect.

Maybe I'm wrong, but the ´total_energy_kwh´ is collected from the plug. See here and is not calculated based on the history in HA.

Odd - so as mentioned in my first post, why in my example does the plug show total consumption 33.3 kwh and HA shows total_energy_kwh: 1.880 (a value which doesn't appear to match up to anything the plug reports)?

@timdonovanuk Have you checked the numbers reported in HA against what is reported by pyhs100 (https://github.com/GadgetReactor/pyHS100)? If they match then the issue is with the pyHS100 library (which is used to communicate to the smart plugs/bulbs).
May be worth checking with @rytilahti too as he is an author of that library.

the consumption of 33.3 on the screenshot is for the last 30 days only and not the total consumption.

Thanks @DanNixon I'll have a go with that and report back!
@ReneNulschDE 33.3 > 1.88  so unless I'm misunderstanding you that doesn't many any sense, as lifetime total would always be a higher number than a 30 days rolling total.

You have to check what does pyhs100 report to you, because that's where the homeassistant gets it data from. If the switch reports it as such (incorrectly), there's nothing that the component can do for it.


Fan level: Can't set to 0/off

I'm using a Lenovo ThinkPad L13 Yoga Gen 4 and I can disable the fans completely using echo "level 0" | sudo tee /proc/acpi/ibm/fan
The option 0 is currently not available in the menu of this extension.

Yes, it's not available intentionally. See #12


[Event Request] codeunit 1410 "Doc. Exch. Service Mgt." - OnBeforeSendActivateAppNotification

[IntegrationEvent(false, false)]
local procedure OnBeforeSendActivateAppNotification(var IsHandled: Boolean)
begin
end;

procedure SendActivateAppNotification()
var
    DocExchServiceSetup: Record "Doc. Exch. Service Setup";
    ActivateAppNotification: Notification;
    ClientId: Text;
    Sandbox: Boolean;
    IsHandled: Boolean;
begin
    IsHandled := false;
    OnBeforeSendActivateAppNotification(IsHandled);
    if IsHandled then
        exit;

    if not GuiAllowed() then
        exit;

    if not DocExchServiceSetup.Get() then
        exit;

    Sandbox := IsSandbox(DocExchServiceSetup);
    ClientId := GetClientId(Sandbox);
    if ClientId = '' then
        exit;

    ActivateAppNotification.Id := GetActivateAppNotificationId();
    ActivateAppNotification.Recall();
    ActivateAppNotification.Message := ActivateAppNotificationTxt;
    ActivateAppNotification.Scope := NotificationScope::LocalScope;
    if GetAppUrl(DocExchServiceSetup) <> '' then
        ActivateAppNotification.AddAction(ActivateAppActionTxt, Codeunit::"Doc. Exch. Service Mgt.", 'ActivateApp');
    ActivateAppNotification.Send();
end;

Thanks for reporting this. We agree, and we’ll publish a fix asap, either in an update for the current version or in the next major release. Please do not reply to this, as we do not monitor closed issues. If you have follow-up questions or requests, please create a new issue where you reference this one.
Build ID: 52728.


Load EMPTY_URI lazy in class AlluxioURI

Description
AlluxioURI and URI are depend on each other, becuse AlluxioURI.EMPTY_URI is a static final variable.
Improvement
Adjust EMPTY_URI to lazy load with inner static class.
When other class need AlluxioURI.EMPTY_URI, AlluxioURI will really load EMPTY_URI instance.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/Alluxio-Pull-Request-Builder/4435/
Test PASSed.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/Alluxio-Pull-Request-Builder/4437/
Test PASSed.

@liuzx32 regarding "AlluxioURI and URI are depend on each other, becuse AlluxioURI.EMPTY_URI is a static final variable", can you describe more here? Does this introduce issues in compilation? Typically we prevent cross-module inter-dependency.
Introducing EMPTY_URI as a method like AlluxioURI.EMPTY_URI() is an unusual practice. There are different ways as a workaround like leveraging Suppliers.memoize

@apc999 Thanks for your answer. It's not a big problem, I will close this PR.
Perhaps, we should add a class AlluxioHelper for AlluxioURI which like your consider.


We need a Hall of Fame

Or somewhere we can show off our rockstar coding abilities. What do you think?

I think it would be a good idea to have a single place where we can put a bunch of sample rockstar code... doing actual work :)

I'm still waiting for a rockstar quine...

What do you mean by "quine"? Self replicating programs?

Quine is a program that prints itself.

Every good language should have a good working quine!

Quine is a program that prints itself.

Oh thanks! I didn't know that

Every good language should have a good working quine!

I just tried to write one and realized it needs string interpolation in some form. Is there a way to do this without it or may I open an Issue requesting the functionality?
P is "P is %s\nSay P"
Say P

This is one of those issues that is harder to deal with for implementations without full recursive decent parsers which as far as I know right now, none of the them have. Additionally you might find that it is hard to "rockify" this construct due to essentially necessary punctuation.

Wasn't sure where best to put it... but working on some math functions Rockstar Math Module

@wrenoud
I have created something similar with a bunch more functions: https://github.com/kennethgoodman/rockstar_math/blob/master/math.rock

Having an (un)official rockstar website would be great, both to show off what people are doing with the language, and also to direct people to the spec and different implementations.
Maybe somebody should use rockstar-js and make the site in rockstar with node

The webpiler not has a proper backend (instead of being a static site with some js), so it would be very possible to create a thing where people would be able to upload their rockstar projects to.
That being said, as rockstar can't interact with a database right now...or even have arrays right now, that would be difficult. :)

or even have arrays right now,

Don't we have: Object - a collection of named data properties, as in ECMAScript.

We do have objects right now, but the only kind you can make are function objects. There is no way to make, call, or use any other kind.

The webpiler now has a proper backend (instead of being a static site with some js), so it would be very possible to create a thing where people would be able to upload their rockstar projects to.

@cwfitzgerald How about a GitHub organization? I just created one "We-Rockstar-Developers" and I'm willing to donate it to this programming language. :-)
Just need a nice icon that rocks...


pass asf.geo_search a WKT string, not Polygon

fixes #310

@sssangha can you approve? The circleci fail is in mintpy


Feature requests for bulk edit (or batch selection), default "delete file" selection and pac proxy

Here are some feature requests:

Multiple Check / Delete / Selection, it will be convenient for delete lots of tasks.
When deleting tasks, is there a way to set "Delete files" checked by default?
Is there any way to set a pac rule for proxy?

Batch operations are in the development plan.
Add a shift+click delete button to automatically checked delete the associated file?
You can try using a system proxy to support pac.

@agalwood
Thanks.
For the second, it can also be a preference.

RE: deleting tasks in bulk - A menu-entry may help.

To reveal the menu, uncheck the box in Prefernces/Basic, found as "Hide App Menu (Windows & Linux Only)".
Though, to delete more than 100 failed dowloads (my IP was banned by the server), I deleted the Motrix completely along with its configuration in AppData folder.

Batch operations are in the development plan.
Add a shift+click delete button to automatically checked delete the associated file?
You can try using a system proxy to support pac.

Hello, I'm interested in implementing the pac proxy functionality.


Parsing macros to imagify

First of all, many thanks for this extension!
I am trying to use a macro and a tikzstyle in a TikZ picture but they both seem to fail:

\newcommand{\env}{\mathcal{E}}
\tikzstyle{arrow} = [->, > = Latex, very thick]

I am going to show the problem with tikzstyle only as I suspect the problems to be similar.

Here is the code that works (provided imagify is installed of course):
test_work.qmd:
---
title: "Test"
lang: en-GB
pdf-engine: lualatex
filters:
  - imagify
imagify:
  header-includes: |
    \usepackage{tikz}
    \usetikzlibrary{positioning}
    \usetikzlibrary{arrows.meta}
  pdf-engine: lualatex
format:
  html:
    toc: true
  pdf:
    include-in-header:
      - text: |
          \usepackage{tikz}
          \usetikzlibrary{positioning}
          \usetikzlibrary{arrows.meta}
---

![A test](./testFig_work.tex){#fig-testFig}

testFig_work.tex:
\begin{tikzpicture}
	%% Define nodes
	\node (N0) at (0, 0) {N0};
	\node[right = of N0] (N1) {N1};

	\draw[->, > = Latex, very thick] (N0) -- (N1);
\end{tikzpicture}

Here is the code that does not work:
test_fail.qmd:
---
title: "Test"
lang: en-GB
pdf-engine: lualatex
filters:
  - imagify
imagify:
  header-includes: |
    \usepackage{tikz}
    \usetikzlibrary{positioning}
    \usetikzlibrary{arrows.meta}
    \tikzstyle{arrow} = [->, > = Latex, very thick]
  pdf-engine: lualatex
format:
  html:
    toc: true
  pdf:
    include-in-header:
      - text: |
          \usepackage{tikz}
          \usetikzlibrary{positioning}
          \usetikzlibrary{arrows.meta}
          \tikzstyle{arrow} = [->, > = Latex, very thick]
---

![A test](./testFig_fail.tex){#fig-testFig}

testFig_fail.tex:
\begin{tikzpicture}
	%% Define nodes
	\node (N0) at (0, 0) {N0};
	\node[right = of N0] (N1) {N1};

	\draw[arrow] (N0) -- (N1);
\end{tikzpicture}

I gathered in a zip the four files.
I am doing anything wrong or is there a bug in transmitting the macros and tikzstyle?
test.zip

Note that I also posted on tex stack exchange:
https://tex.stackexchange.com/questions/719168/parsing-macros-and-tikzstyle-in-quarto-imagify-lua-filter

Ok, the error comes from the fact that tikzstyle is outdated and that tikzset should be used instead (see the complete answer on tex.stackexchange).
\tikzset{arrow/.style = {->, > = Latex, very thick}}


PR-usecase

Description
Added Use cases
Issues Resolved
N/A
Check List

[x] New functionality includes testing.

[x] All tests pass ($ rake test).
[ ] New resources and/or actions have are included in the matchers.rb and matchers_spec.

[x] New functionality has been documented in the README if applicable.

[x] New functionality has been thoroughly documented in examples (please include helpful comments).

[x] Changes documented in the CHANGELOG.

you can add more description in your PR for the use cases you have covered and the url which has been removed from the readme.md


Question: Value or nic-mac if ovn-external-gw-config in distributed type

Hi,
in ovn-external-gw-config config map, we have option centrailized or distributed for type directive. If I use distributed option, then what value should I put for nic-mac. In my understand this value should be unique related to NIC for each node.
thanks in advance

The name is misleading, it should be any mac that not in use

@oilbeater what if the node is down where the mac address attached to it. how we mitigate with this situation?


Use ign-utils instead of ign-cmake utilities

🎉 New feature
Summary

ign-cmake's utilities aren't recommended and are deprecated in ign-cmake3. We should use ign-utils instead.
This should help with

https://github.com/ignition-tooling/release-tools/issues/685

Test it

CI should pass.
Checklist

[x] Signed all commits for DCO
[ ] Added tests
[ ] Added example and/or tutorial
[ ] Updated documentation (as needed)
[ ] Updated migration guide (as needed)
[x] codecheck passed (See contributing)
[x] All tests passed (See test coverage)
[x] While waiting for a review on your PR, please help review another open pull request to support the maintainers

Note to maintainers: Remember to use Squash-Merge and edit the commit message to match the pull request summary while retaining Signed-off-by messages.
🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸

Codecov Report

Merging #978 (a571890) into sdf12 (1637dda) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##            sdf12     #978   +/-   ##
=======================================
  Coverage   65.38%   65.38%
=======================================
  Files           2        2
  Lines          26       26
=======================================
  Hits           17       17
  Misses          9        9

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 1637dda...a571890. Read the comment docs.


Feature/lol/verify images

As part of the worker job pipeline, we need to ensure that each tiff has three
bands. We use gdal to test for this. The first Mb of data has enough data to
verify the image bands so we get the first million bytes from the tiff on S3
and store it into a temporary file. This temp file is loaded with gdal and the
bands are counted. We add a new INVALID status to the layer image enum and
update the django model if the image cannot be loaded or three or more bands
are not detected.
Also adds provisioning step to install python dependencies via pip.
Connects #119
To Test

Upload a new image via the UI.
Check that a message for the event was added to your SQS queue.
Run the worker processor. (see https://github.com/azavea/raster-foundry/pull/136)
Check that the image is marked as verified in the database.

I have to download the entire image file to make a thumbnail, so it might not be worth it to go through the extra trouble of just doing the first 1mb. Although, it might be better the way you have it so that it can fail sooner if it's missing 3 bands.

Everytime the status field is updated, we also need to update the timestamp on status_updated_at.

Everytime the status field is updated, we also need to update the timestamp on status_updated_at.

Good call.

I have to download the entire image file to make a thumbnail, so it might not be worth it to go through the extra trouble of just doing the first 1mb. Although, it might be better the way you have it so that it can fail sooner if it's missing 3 bands.

Let's punt on this for now and then deal with streamlining things when all the jobs are in and working.

.png files that have three bands are considered valid. Do we want to check that the files are geotiffs?

+1, tested. I verified that the status eventually goes to failed a few minutes after validation occurs.

png files that have three bands are considered valid. Do we want to check that the files are geotiffs?

Now in #186


Repeat a given section for each element in an array

Describe your idea
Repeat a given section for each element in an array
Ex. https://docxtemplater.com/demo/#/view/loops
How could this be implemented?
Replicating the proposed example
What problem are you trying to solve?
Create a section dinamically

to fix your trouble check this solution click
maybe this will solve your problem.


Try mutual information, GreedyBayes?

Hi Ian,
Instead of using standard correlation tests (Pearson, Spearman and Kendall) have you considered using a normalised variant of mutual information to capture nonlinear relationships between pairs of features? I've used symmetric uncertainty for this in my own work, after first discretising features and using a recipe based on Freedman-Diaconis to choose the number of bins. I used the Miller-Madow asymptotic bias corrected estimator for MI. You might want to check out the GreedyBayes algorithm for using MI to generate a Bayesian network from the feature space; see the paper here:
Jun Zhang et al., PrivBayes: private data release via Bayesian networks. In SIGMOD.

There is also distance correlation, but I never found it useful for my own work because it involves constructing a distance matrix that maxed-out RAM. Something to try if your data is small?

Hey @andrewjohnlowe, thanks for the comments :-) I have no experience with MI, I'd be happy to take a look at the paper down the line, cheers.

Look here: DataResponsibly/DataSynthesizer. Specifically, the lib directory that contains a Python implementation of GreedyBayes and MI calculation from sklearn.

I could contribute a method to calculate Mutual Information between pairs of columns in a DataFrame, if you like.


Update custom-builds.md

Fixes #4351. While I was at it, I also added a note on minimum versions for Node/Java

Oh wait, the main README.md also mentions cloning the repo. Reconsidering.


HTTP routing functions getting passed the route?

Either this is a bug in the code or in the docs. Should the route name be available to the registered function? Right now it's coming out as undefined.
From the docs:
  this.res.writeHead(200, { 'Content-Type': 'text/plain' })
  this.res.end('hello world from (' + route + ')');
}```

When running the demo code and hitting `curl http://localhost:8080/hello`, the print statement comes out as:
```hello world from (undefined)```

The route is not currently passed. We could set it on the thisArg of the function

btw,
What is the syntax to define on
get: helloWorld
to call it with arguments?
cannot figure it out from: (or i'm looking at the wrong piece of code)
https://github.com/flatiron/director/blob/master/lib/director/router.js#L243
thanks

Results from URL matches get passed to route functions. See URL Matching in the README.