profile
viewpoint
If you are wondering where the data of this site comes from, please visit https://api.github.com/users/atreyasha/events. GitMemory does not store any data, but only uses NGINX to cache data for a period of time. The idea behind GitMemory is simply to give users a better reading experience.

pbrisbin/downgrade 223

Downgrade packages in Arch Linux

atreyasha/deep-generative-models 35

Deep generative models implemented with TensorFlow 2.0: eg. Restricted Boltzmann Machine (RBM), Deep Belief Network (DBN), Deep Boltzmann Machine (DBM), Convolutional Variational Auto-Encoder (CVAE), Convolutional Generative Adversarial Network (CGAN)

atreyasha/mv-temporal-rgan 15

Multivariate recurrent GANs for generating biomedical time-series given consistent dimensionality. Methodology involves drawing symmetries to adversarial image generation

atreyasha/vegetation-monitoring 8

R-based Random Forest Algorithm to classify vegetation cover in Dharamshala Tehsil and conduct vegetation loss detection

atreyasha/sentiment-argument-mining 5

Sentiment analysis and argumentation mining in UNSC Speeches

atreyasha/gee-landsat-filter 3

Google Earth Engine API scripts to help bulk filter and pre-process Landsat 8 SR imagery

atreyasha/i3-balance-workspace 3

Balance windows and workspaces in i3wm

atreyasha/abelianSandpile 2

Python script to visualize and animate the Abelian sandpile cascade effect. Includes python sripts to produce images for the cascade effect and later convert images into a combined gif

atreyasha/clingo-solvers 2

Answer Set Programming (ASP): clingo solvers for NxN Sudoku, Yosenabe, Minotaur and Elevator games

atreyasha/semantic-isometry-nmt 2

Investigating the isometric behaviour of Neural Machine Translation models on binary semantic equivalence spaces

startedninjamuffin99/Funkin

started time in 5 hours

Pull request review commentpbrisbin/downgrade

System-level configuration file and minor menu modification

 parse_options() { }  cli() {-  parse_options "$@"+  local conf_args=()++  # Get configuration and command-line arguments and parse everything+  eval "conf_args=($(read_downgrade_conf))"

I think we can consider the eval save by passing the elements through printf '%q' first. Sorry, I had used this trick before and since forgotten. It actually makes things simpler in general, I think (no need for tr or messing with $IFS):

safe_example() {
> cat <<'EOM'
> --foo bar
> --baz
> --bat "a hoy"
> EOM
> }
evil_example() {
cat <<'EOM'
> --foo
> $(ls /etc)
> --bar
> EOM
> }
[patrick@leo ops]$ eval "x=( $(safe_example | xargs printf '%q ') )"
[patrick@leo ops]$ printf '>%s<\n' "${x[@]}"
>--foo<
>bar<
>--baz<
>--bat<
>a hoy<
[patrick@leo ops]$ eval "y=( $(evil_example | xargs printf '%q ') )"
[patrick@leo ops]$ printf '>%s<\n' "${y[@]}"
>--foo<
>$(ls<
>/etc)<
>--bar<
atreyasha

comment created time in 10 hours

Pull request review commentpbrisbin/downgrade

System-level configuration file and minor menu modification

 parse_options() { }  cli() {-  parse_options "$@"+  local conf_args=()++  # Get configuration and command-line arguments and parse everything+  eval "conf_args=($(read_downgrade_conf))"

Happy to look at that code and see, but I wouldn't consider that possibility and immediate reason to change the implementation.

"The code in the conf will be eval-d" isn't itself a vulnerability. It requires that the code in the conf can somehow be attacker-controlled. And if an attacker can change /etc/downgrade.conf on you, I think you have bigger problems, right?

atreyasha

comment created time in 12 hours

Pull request review commentpbrisbin/downgrade

System-level configuration file and minor menu modification

+  $ source "$TESTDIR/../helper.sh"++Check that relevant arrays are made unique if they contain elements, otherwise they should be left as empty arrays

we just replace test/options_sanity/array_uniqueness.t with your second suggestion?

Sure, SGTM.

atreyasha

comment created time in 12 hours

Pull request review commentpbrisbin/downgrade

System-level configuration file and minor menu modification

 search_packages() {     fi      # shellcheck disable=SC2086-    find -L "${PACMAN_CACHE[@]}" -maxdepth "$DOWNGRADE_MAXDEPTH" -regextype posix-extended -regex ".*/$pkgfile_re"+    find -L "${PACMAN_CACHE[@]}" -maxdepth "$DOWNGRADE_MAXDEPTH" \+      -regextype posix-extended -regex ".*/$pkgfile_re" 2>/dev/null

I try not to avoid suppressing errors unless there's a reason. If an end-user made a mistake in --pacman-cache, would it be better to show them what find said about it or hide it? I don't know the answer, but that's the question I'd ask.

as we already did in other cases

This is definitely a case-by-case decision IMO, but if you describe the other cases, maybe there is a generally applicable way to decide for this one.

atreyasha

comment created time in 12 hours

fork galaunay/org-html-themes

How to export Org mode files into awesome HTML in 2 minutes

fork in 15 hours

Pull request review commentpbrisbin/downgrade

System-level configuration file and minor menu modification

+# /etc/xdg/downgrade/downgrade.conf+#+# Configuration file for downgrade+# See downgrade(8) for more information on arguments+# Uncomment and define relevant values 

Take it or leave it, but I might say,

# Defaults are shown, uncomment and define values as desired 
atreyasha

comment created time in a day

Pull request review commentpbrisbin/downgrade

System-level configuration file and minor menu modification

+  $ source "$TESTDIR/../helper.sh"++Check that relevant arrays are made unique if they contain elements, otherwise they should be left as empty arrays

I think it would be clearer to organize these tests such that each test case is only testing one thing, and that we do a suite by function. As they are, the unique assertions and parsing assertions are a bit mixed.

test/parse_options.t

Reads multiple --pacman-cache options into PACMAN_CACHE

  $ parse_options --pacman-cache /home/ --pacman-cache /away/ --pacman-cache /home/ foo 2>/dev/null
  > echo "${PACMAN_CACHE[@]}"
  /home/ /away/ /home/

Reads arguments into terms

  $ parse_options foo bar foo 2>/dev/null
  > echo "${terms[@]}";
  foo bar foo

test/read_unique.t

Sets unique arguments into a variable

  $ read_unique X x y y z y z
  > echo "${X[@]}"
  x y z

WDYT?

atreyasha

comment created time in a day

Pull request review commentpbrisbin/downgrade

System-level configuration file and minor menu modification

 parse_options() { }  cli() {-  parse_options "$@"+  local conf_args=()++  # Get configuration and command-line arguments and parse everything+  eval "conf_args=($(read_downgrade_conf))"

I agree this is probably the only way to do it. I wonder if there are any security concerns with this here.

atreyasha

comment created time in a day

Pull request review commentpbrisbin/downgrade

System-level configuration file and minor menu modification

 search_packages() {     fi      # shellcheck disable=SC2086-    find -L "${PACMAN_CACHE[@]}" -maxdepth "$DOWNGRADE_MAXDEPTH" -regextype posix-extended -regex ".*/$pkgfile_re"+    find -L "${PACMAN_CACHE[@]}" -maxdepth "$DOWNGRADE_MAXDEPTH" \+      -regextype posix-extended -regex ".*/$pkgfile_re" 2>/dev/null

What prompted the 2>/dev/null?

atreyasha

comment created time in a day

Pull request review commentpbrisbin/downgrade

System-level configuration file and minor menu modification

 output_package() {    # Remote or local file   if [[ $path =~ ^/ ]]; then-    location="$(gettext 'local')"+    location="$(dirname "$path")"

:+1:

atreyasha

comment created time in a day

delete branch pbrisbin/downgrade

delete branch : restyled/as/configuration-file

delete time in a day

PR closed pbrisbin/downgrade

Restyle System-level configuration file and minor menu modification

Automated style fixes for #151, created by Restyled.

The following restylers made fixes:

To incorporate these changes, merge this Pull Request into the original. We recommend using the Squash or Rebase strategies.

NOTE: As work continues on the original Pull Request, this process will re-run and update (force-push) this Pull Request with updated style fixes as necessary. If the style is fixed manually at any point (i.e. this process finds no fixes to make), this Pull Request will be closed automatically.

Sorry if this was unexpected. To disable it, see our documentation.

+17 -1

0 comment

2 changed files

restyled-io[bot]

pr closed time in a day

PR opened pbrisbin/downgrade

Restyle System-level configuration file and minor menu modification

Automated style fixes for #151, created by Restyled.

The following restylers made fixes:

To incorporate these changes, merge this Pull Request into the original. We recommend using the Squash or Rebase strategies.

NOTE: As work continues on the original Pull Request, this process will re-run and update (force-push) this Pull Request with updated style fixes as necessary. If the style is fixed manually at any point (i.e. this process finds no fixes to make), this Pull Request will be closed automatically.

Sorry if this was unexpected. To disable it, see our documentation.

+1 -1

0 comment

1 changed file

pr created time in a day

create barnchpbrisbin/downgrade

branch : restyled/as/configuration-file

created branch time in a day

startedadam-mcdaniel/free

started time in 2 days

startedadam-mcdaniel/atom

started time in 2 days

startedXAMPPRocky/tokei

started time in 3 days

Pull request review commentpbrisbin/downgrade

System-level configuration file and minor menu modification

 parse_options() { }  cli() {-  parse_options "$@"+  declare -a system_args

Does declare within a function imply local? I have no idea. I would usually do local system_args=().

I also wonder if configuration_args / conf_args is a better name. I'm not sure there's much meaning in "system" yet.

atreyasha

comment created time in 3 days

Pull request review commentpbrisbin/downgrade

System-level configuration file and minor menu modification

 parse_options() { }  cli() {-  parse_options "$@"+  declare -a system_args++  # get system and command-line arguments and parse everything+  IFS=' ' read -r -a system_args <<<"$(read_downgrade_conf)"+  parse_options "${system_args[@]}" "$@"++  # make arrays unique+  IFS=' ' read -r -a terms <<<"$(printf "%s\n" "${terms[@]}" | uniq | tr '\n' ' ')"+  IFS=' ' read -r -a PACMAN_CACHE <<<"$(printf "%s\n" "${PACMAN_CACHE[@]}" | uniq | tr '\n' ' ')"++  # proceed with rest of workflow   main "${terms[@]}"   pacman -U "${pacman_args[@]}" "${to_install[@]}"   prompt_to_ignore "${to_ignore[@]}" } +# Set script defaults

You dropped the "Up-convert older variables", which is fine, but I think would mean a major version bump?

atreyasha

comment created time in 3 days

Pull request review commentpbrisbin/downgrade

System-level configuration file and minor menu modification

 EOF  read_pacman_conf() { sed '/^#\?'"$1"' *= *\(.*\)$/!d; s//\1/' "$PACMAN_CONF"; } +read_downgrade_conf() { grep -v '^\s*$\|^\s*\#' "$DOWNGRADE_ROOT_CONF" 2>/dev/null | xargs; }

I came up with the following grep -- does it work? I find it easier to reason about, but it could be subjective.

read_downgrade_conf() { grep -E -v '^ *(#.*)?$')  "$DOWNGRADE_ROOT_CONF" 2>/dev/null | xargs; }
atreyasha

comment created time in 4 days

Pull request review commentpbrisbin/downgrade

System-level configuration file and minor menu modification

 parse_options() { }  cli() {-  parse_options "$@"+  declare -a system_args++  # get system and command-line arguments and parse everything+  IFS=' ' read -r -a system_args <<<"$(read_downgrade_conf)"+  parse_options "${system_args[@]}" "$@"++  # make arrays unique+  IFS=' ' read -r -a terms <<<"$(printf "%s\n" "${terms[@]}" | uniq | tr '\n' ' ')"+  IFS=' ' read -r -a PACMAN_CACHE <<<"$(printf "%s\n" "${PACMAN_CACHE[@]}" | uniq | tr '\n' ' ')"
read_unique() {
  local var=$1
  shift

  IFS=$'\n' read -r -a var <<<"$(printf "%s\n" "$@" | uniq)"
}
  read_unique terms "${terms[@]}"
  read_unique PACMAN_CACHE "${PACMAN_CACHE[@]}"
atreyasha

comment created time in 3 days

Pull request review commentpbrisbin/downgrade

System-level configuration file and minor menu modification

 parse_options() { }  cli() {-  parse_options "$@"+  declare -a system_args++  # get system and command-line arguments and parse everything+  IFS=' ' read -r -a system_args <<<"$(read_downgrade_conf)"

Can we add a test suite on this behavior? It's going to be tricky and I'd like to avoid regressions in the future.

I don't think we have any options that accept arguments with spaces in them right now, but if it's not too complicated, I think we should try to write this code to handle that now. In other words:

# Some header comment

# --example option
--actual "Option with spaces"

Should return ["--actual", "Option with spaces"]. I think the code you have would return ["--actual", "Option", "with", "spaces"], right?

atreyasha

comment created time in 3 days

delete branch pbrisbin/downgrade

delete branch : restyled/as/configuration-file

delete time in 4 days

PR closed pbrisbin/downgrade

Restyle System-level configuration file and minor menu modification

Automated style fixes for #151, created by Restyled.

The following restylers made fixes:

To incorporate these changes, merge this Pull Request into the original. We recommend using the Squash or Rebase strategies.

NOTE: As work continues on the original Pull Request, this process will re-run and update (force-push) this Pull Request with updated style fixes as necessary. If the style is fixed manually at any point (i.e. this process finds no fixes to make), this Pull Request will be closed automatically.

Sorry if this was unexpected. To disable it, see our documentation.

+15 -3

0 comment

1 changed file

restyled-io[bot]

pr closed time in 4 days

push eventpbrisbin/downgrade

Atreya Shankar

commit sha 3fdf4f8d2073ceda37794f49959a51f9d5e0ad12

Shift and change key variables Shift definition of important variables to just above of main code execution. Remove all possibilities of supplying environmental variables, such that manipulation is only possible with command line arguments

view details

Atreya Shankar

commit sha 76e6a5d972602fe5e2841db3022d26d29b66fb3b

Addition of sample configuration file

view details

Atreya Shankar

commit sha 908fb0dadb798e53beffd746ab596dfe59adba88

Workflow to read system-level configuration New feature to parse system-level downgrade configuration file

view details

Atreya Shankar

commit sha 33b7c19217f09c77f06914eb39c5fc104ac3f6e0

Make `terms` and `PACMAN_CACHE` arrays unique Minor fix to make interim arrays unique to ensure packages and caches are only visited once during the entire workflow

view details

Atreya Shankar

commit sha cb502897289dedede4cf50d1a16d093e847325e5

Add local cache location to downgrade menu As per #138, we should indicate locations of cached packages so that possible duplicates of packages can be distinguished from one another

view details

Restyled.io

commit sha cdc9fcbc7946481bc992a7e3e9fc3cd4dc74233a

Restyled by shfmt

view details

push time in 4 days

PR opened pbrisbin/downgrade

Restyle System-level configuration file and minor menu modification

Automated style fixes for #151, created by Restyled.

The following restylers made fixes:

To incorporate these changes, merge this Pull Request into the original. We recommend using the Squash or Rebase strategies.

NOTE: As work continues on the original Pull Request, this process will re-run and update (force-push) this Pull Request with updated style fixes as necessary. If the style is fixed manually at any point (i.e. this process finds no fixes to make), this Pull Request will be closed automatically.

Sorry if this was unexpected. To disable it, see our documentation.

+3 -3

0 comment

1 changed file

pr created time in 4 days

create barnchpbrisbin/downgrade

branch : restyled/as/configuration-file

created branch time in 4 days

fork giannou/project_interfaces

Project specific interfaces to REMIND / MAgPIE.

fork in 4 days

issue commentpbrisbin/downgrade

Configuration file for easier customization and modify downgrade execution workflow with assumption (and enforcement) of root permissions

I am thinking of combining points (1) and (2) in this PR, as they seem quite complementary

In any case, I am almost done with coding (1) and now moving on to (2). Am encountering a small issue

Note that there's no need to die release cadence and PR cadence here. Even if you think (1) and (2) should be released in the same version, I'd encourage you to open separate PRs. If (1) is basically done, and you're hitting issues addressing (2), I would prefer reviewing and getting (1) merged so I can focus on (2) in isolation. Unless the code is just so inter-related you don't think that'd be valuable. Up to to you.

As per #144, we made downgrade a root-level operation

Oh geeze, I totally forgot this. I'm actually now on the side that a user-level configuration just doesn't make sense and we shouldn't do it. Is there a really compelling use-case for it?

Alternatively, we could drop (2) and (3) altogether and only permit the use of a single root-level configuration file

atreyasha

comment created time in 5 days