scale parameters in bayesian and nlm models

thanks @robohall for info that scaling parameters should help hugely in convergence and time to convergence in Stan (e.g., https://github.com/stan-dev/stan/wiki/Prior-Choice-Recommendations, https://groups.google.com/forum/#!topic/stan-users/w-h5A8UbjMs)
thanks @Arroita for pointing out that scaling helps in nlm models, too

Parameter scaling for b_np_oi_pm_plrckm.
Lessons:

GPP_daily_sigma, etc. at 4 rather than 10 doesn't make much difference. probably 1 vs 4 doesn't either
err_obs_sigma_rate can be 0.2 or 2 or 0.02 and the faster version works just as fast. same-named parameter at 1 or 1000 is 25% slower than 10 or 100 for the old version
the new version ("b_np_oi_pm_plrckm_faster.stan") is about twice as fast; 17 seconds for new version, 36 for old
so priors don't matter much, but something about this change really helps. maybe it's the switch from gamma to normal?

Test code:
  library(streamMetabolizer)
  library(dplyr)
  # faster stan oi model
  dat <- data_metab('10', res='10')
  mmb <- mm_name('bayes', err_proc_acor=FALSE, err_proc_iid=FALSE, engine='stan')
  sp <- specs(mmb, n_chains=3, n_cores=3, burnin_steps=300, saved_steps=100, verbose=TRUE, keep_mcmcs=TRUE,
              GPP_daily_sigma=4, ER_daily_sigma=4, K600_daily_sigma=4)
              #GPP_daily_sigma=10, ER_daily_sigma=10, K600_daily_sigma=10)
  mm_slow <- metab(specs=replace(sp, 'err_obs_iid_sigma_rate', 10), data=dat) # 75 sec w/ new compilation, 36-42 sec w/ daily sigmas at 4, 38-40 sec w/ daily sigmas at 10, 48 w/ err_obs_iid_sigma_rate=1 or 1000, 35 w/ err_obs_iid_sigma_rate=100 or 10
  sp$err_obs_iid_sigma_rate <- 0.2 # need to adjust because we're using the 'rate' as a lognormal scaling parameter now
  sp$model_name <- 'inst/models/b_np_oi_pm_plrckm_faster.stan'
  mm_fast <- metab(specs=replace(sp, 'err_obs_iid_sigma_rate', 0.02), data=dat) # 51 sec w/ new compilation, 16-17 sec w/ err_obs_sigma_rate at 0.2 or 2 or 0.02

Old model:
// b_np_oi_pm_plrckm.stan

data {
  // Parameters of priors on metabolism
  real GPP_daily_mu;
  real GPP_daily_sigma;
  real ER_daily_mu;
  real ER_daily_sigma;
  real K600_daily_mu;
  real K600_daily_sigma;

  // Error distributions
  real err_obs_iid_sigma_shape;
  real err_obs_iid_sigma_rate;

  // Data dimensions
  int<lower=1> d; # number of dates
  int<lower=1> n; # number of observations per date

  // Daily data
  vector[d] DO_obs_1;

  // Data
  vector[d] DO_obs[n];
  vector[d] DO_sat[n];
  vector[d] frac_GPP[n];
  vector[d] frac_ER[n];
  vector[d] frac_D[n];
  vector[d] depth[n];
  vector[d] KO2_conv[n];
}

transformed data {
  vector[d] coef_GPP[n-1];
  vector[d] coef_ER[n-1];
  vector[d] coef_K600_part[n-1];
  vector[d] DO_sat_pairmean[n-1];

  for(i in 1:(n-1)) {
    // Coefficients by pairmeans (e.g., mean(frac_GPP[i:(i+1)]) applies to the DO step from i to i+1)
    coef_GPP[i]  <- (frac_GPP[i] + frac_GPP[i+1])/2.0 ./ ((depth[i] + depth[i+1])/2.0);
    coef_ER[i]   <- (frac_ER[i] + frac_ER[i+1])/2.0 ./ ((depth[i] + depth[i+1])/2.0);
    coef_K600_part[i] <- (KO2_conv[i] + KO2_conv[i+1])/2.0 .* (frac_D[i] + frac_D[i+1])/2.0;
    DO_sat_pairmean[i] <- (DO_sat[i] + DO_sat[i+1])/2.0;
  }
}

parameters {
  vector[d] GPP_daily;
  vector[d] ER_daily;
  vector[d] K600_daily;

  real err_obs_iid_sigma;
}

transformed parameters {
  vector[d] DO_mod[n];

  // Model DO time series
  // * pairmeans version
  // * observation error
  // * no process error
  // * reaeration depends on DO_mod

  // DO model
  DO_mod[1] <- DO_obs_1;
  for(i in 1:(n-1)) {
    DO_mod[i+1] <- (
      DO_mod[i] +
      GPP_daily .* coef_GPP[i] +
      ER_daily .* coef_ER[i] +
      K600_daily .* coef_K600_part[i] .* (DO_sat_pairmean[i] - DO_mod[i]/2.0)
    ) ./ (1.0 + K600_daily .* coef_K600_part[i] / 2.0);
  }
}

model {
  // Independent, identically distributed observation error
  for(i in 1:n) {
    DO_obs[i] ~ normal(DO_mod[i], err_obs_iid_sigma);
  }
  // SD (sigma) of the observation errors
  err_obs_iid_sigma ~ gamma(err_obs_iid_sigma_shape, err_obs_iid_sigma_rate);

  // Daily metabolism priors
  GPP_daily ~ normal(GPP_daily_mu, GPP_daily_sigma);
  ER_daily ~ normal(ER_daily_mu, ER_daily_sigma);
  K600_daily ~ normal(K600_daily_mu, K600_daily_sigma);
}

New model
// b_np_oi_pm_plrckm.stan

data {
  // Parameters of priors on metabolism
  real GPP_daily_mu;
  real GPP_daily_sigma;
  real ER_daily_mu;
  real ER_daily_sigma;
  real K600_daily_mu;
  real K600_daily_sigma;

  // Error distributions
  //real err_obs_iid_sigma_shape;
  real err_obs_iid_sigma_rate; # using as a lognormal scaling factor now

  // Data dimensions
  int<lower=1> d; # number of dates
  int<lower=1> n; # number of observations per date

  // Daily data
  vector[d] DO_obs_1;

  // Data
  vector[d] DO_obs[n];
  vector[d] DO_sat[n];
  vector[d] frac_GPP[n];
  vector[d] frac_ER[n];
  vector[d] frac_D[n];
  vector[d] depth[n];
  vector[d] KO2_conv[n];
}

transformed data {
  vector[d] coef_GPP[n-1];
  vector[d] coef_ER[n-1];
  vector[d] coef_K600_part[n-1];
  vector[d] DO_sat_pairmean[n-1];

  for(i in 1:(n-1)) {
    // Coefficients by pairmeans (e.g., mean(frac_GPP[i:(i+1)]) applies to the DO step from i to i+1)
    coef_GPP[i]  <- (frac_GPP[i] + frac_GPP[i+1])/2.0 ./ ((depth[i] + depth[i+1])/2.0);
    coef_ER[i]   <- (frac_ER[i] + frac_ER[i+1])/2.0 ./ ((depth[i] + depth[i+1])/2.0);
    coef_K600_part[i] <- (KO2_conv[i] + KO2_conv[i+1])/2.0 .* (frac_D[i] + frac_D[i+1])/2.0;
    DO_sat_pairmean[i] <- (DO_sat[i] + DO_sat[i+1])/2.0;
  }
}

parameters {
  vector[d] GPP_daily_scaled;
  vector[d] ER_daily_scaled;
  vector[d] K600_daily_scaled;

  real err_obs_iid_sigma_scaled;
}

transformed parameters {
  vector[d] GPP_daily;
  vector[d] ER_daily;
  vector<lower=0>[d] K600_daily;
  real<lower=0> err_obs_iid_sigma;
  vector[d] DO_mod[n];

  // Scaled parameters
  GPP_daily <- GPP_daily_mu + (GPP_daily_sigma * GPP_daily_scaled);
  ER_daily <- ER_daily_mu + (ER_daily_sigma * ER_daily_scaled);
  K600_daily <- K600_daily_mu + (K600_daily_sigma * K600_daily_scaled);
  err_obs_iid_sigma <- err_obs_iid_sigma_rate * exp(err_obs_iid_sigma_scaled);

  // Model DO time series
  // * pairmeans version
  // * observation error
  // * no process error
  // * reaeration depends on DO_mod

  // DO model
  DO_mod[1] <- DO_obs_1;
  for(i in 1:(n-1)) {
    DO_mod[i+1] <- (
      DO_mod[i] +
        GPP_daily .* coef_GPP[i] +
        ER_daily .* coef_ER[i] +
        K600_daily .* coef_K600_part[i] .* (DO_sat_pairmean[i] - DO_mod[i]/2.0)
    ) ./ (1.0 + K600_daily .* coef_K600_part[i] / 2.0);
  }
}

model {
  // Independent, identically distributed observation error
  for(i in 2:n) {
    DO_obs[i] ~ normal(DO_mod[i], err_obs_iid_sigma);
  }
  // SD (sigma) of the observation errors
  err_obs_iid_sigma_scaled ~ normal(0, 1);

  // Daily metabolism priors
  GPP_daily_scaled ~ normal(0, 1);
  ER_daily_scaled ~ normal(0, 1);
  K600_daily_scaled ~ normal(0, 1);
}

Now tackling b_Kl_oi_pm_plrckm.stan.

at first, K600_daily_pred <- K600_daily_beta[1] + K600_daily_beta[2] * ln_discharge_daily; seemed to be much faster than K600_daily_pred <- exp(K600_daily_beta[1] + K600_daily_beta[2] * ln_discharge_daily);...now i think it's not much slower but does require a good choice of priors so the K preds don't skyrocket when exponentiated from the linear equation
scaling GPP, ER, and K600 seems to keep things slow, or maybe just not help
scaling the sigmas matters a lot, as long as it's not done in combination with scaling GPP,ER,K

b_Kl_oi_pm_plrckm.stan - the original
b_Kl_oi_pm_plrckm_sfs.stan.txt - everything (5 params) scaled. about as fast as the original
b_Kl_oi_pm_plrckm_sfsloglog.stan - loglog with everything scaled (very slow)
b_Kl_oi_pm_plrckm_sfs2.stan - linlog with only err_obs_iid_sigma and k600_daily_sigma scaled (fast!)
b_Kl_oi_pm_plrckm_sfs2loglog.stan - loglog with only err_obs_iid_sigma and k600_daily_sigma scaled (equally fast!)
  # faster stan Kl model?
  dat <- mutate(data_metab('10', res='10'), discharge=3)
  sp <- specs("b_Kl_oi_pm_plrckm.stan", n_chains=3, n_cores=3, burnin_steps=300, saved_steps=100, verbose=TRUE, keep_mcmcs=TRUE)
  mm_old <- metab(
    specs=replace(sp, 'model_name', 'inst/models/b_Kl_oi_pm_plrckm.stan'),
    data=dat) # 48,41,53 sec - baseline
  mm_new <- metab(
    specs=sp %>%
      replace('model_name', 'inst/models/b_Kl_oi_pm_plrckm_sfs.stan') %>%
      replace('K600_daily_beta_mu', list(c(intercept=1, slope=2.3))) %>%
      replace('K600_daily_beta_sigma', list(c(intercept=0.3, slope=0.3))),
    data=dat) # 44,31,40,36 sec - faster than no scaling but by precious little
  mm_newb <- metab(
    specs=sp %>%
      replace('model_name', 'inst/models/b_Kl_oi_pm_plrckm_sfs.stan') %>%
      replace('K600_daily_beta_mu', list(c(intercept=10, slope=3))) %>%
      replace('K600_daily_beta_sigma', list(c(intercept=8, slope=2))),
    data=dat) # 53,49,52,41 sec - slightly slower than above b/c of parameters
  mm_loglog <- metab(
    specs=sp %>%
      replace('model_name', 'inst/models/b_Kl_oi_pm_plrckm_sfsloglog.stan') %>%
      replace('K600_daily_beta_mu', list(c(intercept=1, slope=2.3))) %>%
      replace('K600_daily_beta_sigma', list(c(intercept=0.3, slope=0.3))),
    data=dat) # 1:19, 1:22, 1:32 sec - log-log is definitely slow
  mm_new2 <- metab(
    specs=sp %>%
      replace('model_name', 'inst/models/b_Kl_oi_pm_plrckm_sfs2.stan') %>%
      replace('K600_daily_beta_mu', list(c(intercept=10, slope=3))) %>%
      replace('K600_daily_beta_sigma', list(c(intercept=8, slope=2))),
    data=dat) # 22,21 sec. where have you been all this time?
  mm_new2loglog <- metab(
    specs=sp %>%
      replace('model_name', 'inst/models/b_Kl_oi_pm_plrckm_sfs2loglog.stan') %>%
      replace('K600_daily_beta_mu', list(c(intercept=1, slope=2.3))) %>%
      replace('K600_daily_beta_sigma', list(c(intercept=0.3, slope=0.3))),
    data=dat) # 18,20 sec. so log-log isn't slow after all??
  mm_new2loglogb <- metab(
    specs=sp %>%
      replace('model_name', 'inst/models/b_Kl_oi_pm_plrckm_sfs2loglog.stan') %>%
      replace('K600_daily_beta_mu', list(c(intercept=10, slope=3))) %>%
      replace('K600_daily_beta_sigma', list(c(intercept=8, slope=2))),
    data=dat) # 45 sec. so good priors do matter

have now done scaling for several manually-modified stan models; need to extend to all autogenerated models for stan & jags.

for sigmas, a half normal is probably better than a log normal. we want highest probabilities at 0.

or gamma.

bob identified this minimal, reproducible example of a failing model:
# french data with default gives K of 200 - totally not right
dat <- data_metab('3','10')
mm <- mm_name('bayes', pool_K600 = 'none', err_obs_iid=TRUE, err_proc_iid=TRUE) %>%
  specs(K600_daily_mu = 80, K600_daily_sigma = 50) %>%
  metab(data=dat)
traceplot(get_mcmc(mm))
# works fine with the defaults, but that shouldn't be what makes the difference
mm <- mm_name('bayes', pool_K600 = 'none', err_obs_iid=TRUE, err_proc_iid=TRUE) %>%
  specs() %>%
  metab(data=dat) # these values are also suspiciously similar to one another - might all be bounded by the priors and converging on that boundary

we think the problem is that the prior on err_obs_iid_sigma is currently a lognormal with very little weight on small values in the range where err_obs_iid_sigma probably should be.

Priorities for getting the priors and parameter scaling right:

get the range of probable values correct
do enough scaling to make Stan happy

Confirming that the current code is doing poorly with scaling err_obs_iid and err_proc_iid, and specifically is driving posteriors to very close to (and always greater than?) 1:
dat <- data_metab('10', res='10')
sp <- specs(mm_name('bayes', pool_K600='none'))
mm <- metab(sp, dat)
plot_distribs(mm, 'err_obs_iid_sigma')

plot_distribs(mm, 'err_proc_iid_sigma')

Note that the priors here are based on dlnorm calls in plot_distribs, not on whatever is being seen by the Stan model. So it could be that I'm transforming wrong to generate the prior and/or using the wrong value or in the wrong way to enforce the err_x_iid distributions

I've checked and rechecked the equations for scaling a standard normal to a lognormal, and I still can't get my rescaled prior equation to reproduce the straight dlnorm density.
plot_distribs(specs('bayes', err_obs_iid_sigma_location = 0, err_obs_iid_sigma_scale = 2), parname='err_obs_iid_sigma')

With several combinations of location and scale parameters, the prior_rescaled distrib seems always (1) to intersect with the prior distrib at 1 and (2) to peak at 1. 1 is curious; 2 probably explains why models are generating posteriors centered on 1.

OK, definitive proof that I don't understand the relationship between ddist and rdist functions in R:
meanlog=2
sdlog=0.4
# 3 methods of computing distribution using rnorm
plot(density(exp(rnorm(100000, meanlog, sdlog))), col='red', xlim=c(0,200))
lines(density(exp(meanlog + sdlog*rnorm(100000, 0, 1))), col='blue')
lines(density(exp(meanlog)*exp(rnorm(100000, 0, 1))^sdlog), col='gold')
# 1 method using rlnorm
lines(density(rlnorm(100000, meanlog, sdlog)), col='purple', lty=2)
# 1 method using dlnorm (this is the odd one out)
lines(dlnorm(seq(0.1,200,by=0.1), meanlog, sdlog), col='springgreen3')

These should all overlap. I've shown myself that several methods of simulating from rnorm are all equal to one another and to a method for simulating from rlnorm. But they all differ from the density given by dlnorm.

Oh, for heaven's sake (and thank you, Andy). dlnorm returns a vector, not a data.frame. Replace the last line above with this one:
lines(x=seq(0.1,200,by=0.1), y=dlnorm(seq(0.1,200,by=0.1), meanlog, sdlog), col='springgreen3')

and you get something much nicer:

So there. I can correctly scale a standard normal distribution to a lognormal distribution of arbitrary meanlog and sdlog (which I still believe can be fairly called 'location' and 'scale'). Now the only question is why this doesn't work in my Stan models.

And confirming that these parameters match those given in the Stan manual:

meanlog=2
sdlog=0.4
# 3 methods of computing distribution using rnorm
plot(density(exp(rnorm(100000, meanlog, sdlog))), col='red', xlim=c(0,200))
lines(density(exp(meanlog + sdlog*rnorm(100000, 0, 1))), col='blue')
lines(density(exp(meanlog)*exp(rnorm(100000, 0, 1))^sdlog), col='gold')
# 1 method using rlnorm
lines(density(rlnorm(100000, meanlog, sdlog)), col='purple', lty=2)
# 1 method using dlnorm
lines(x=seq(0.1,200,by=0.1), y=dlnorm(seq(0.1,200,by=0.1), meanlog, sdlog), col='springgreen3')
# 1 method using equation
x=seq(0.1,200,by=0.1); lines(x=x, y=(1/(x*sdlog*sqrt(2*pi)))*exp(-(log(x)-meanlog)^2/(2*sdlog^2)), col='brown')

Precision does vary with the parameters, though:
meanlog=0.1
sdlog=2
# 3 methods of computing distribution using rnorm
plot(density(exp(rnorm(100000, meanlog, sdlog))), col='red', xlim=c(0,5), ylim=c(0,1.2))
lines(density(exp(meanlog + sdlog*rnorm(100000, 0, 1))), col='blue')
lines(density(exp(meanlog)*exp(rnorm(100000, 0, 1))^sdlog), col='gold')
# 1 method using rlnorm
lines(density(rlnorm(100000, meanlog, sdlog)), col='purple', lty=2)
# 1 method using dlnorm
lines(x=seq(0.1,200,by=0.1), y=dlnorm(seq(0.1,200,by=0.1), meanlog, sdlog), col='springgreen3')
# 1 method using equation
x=seq(0.1,200,by=0.1); lines(x=x, y=(1/(x*sdlog*sqrt(2*pi)))*exp(-(log(x)-meanlog)^2/(2*sdlog^2)), col='brown', lty=2)

meanlog=0.1
sdlog=2
# 3 methods of computing distribution using rnorm
plot(density(exp(rnorm(100000, meanlog, sdlog))), col='red', xlim=c(0,5), ylim=c(0,1.2))
lines(density(exp(meanlog + sdlog*rnorm(100000, 0, 1))), col='blue')
lines(density(exp(meanlog)*exp(rnorm(100000, 0, 1))^sdlog), col='gold')
# 1 method using rlnorm
lines(density(rlnorm(100000, meanlog, sdlog)), col='purple', lty=2)
# 1 method using dlnorm
lines(x=seq(0.1,200,by=0.1), y=dlnorm(seq(0.1,200,by=0.1), meanlog, sdlog), col='springgreen3')
# 1 method using equation
x=seq(0.1,200,by=0.1); lines(x=x, y=(1/(x*sdlog*sqrt(2*pi)))*exp(-(log(x)-meanlog)^2/(2*sdlog^2)), col='brown', lty=2)

Here and for larger sdlogs, the equations (dlnorm and algebra) greatly outperform the rnorm/rlnorm-derived densities:

I think what I've learned is that the interesting part of a lognormal distribution is rarely drawn in simulations, regardless of whether you draw from a normal (rnorm) or lognormal (rlnorm) distribution. At least, this is true for the types of values I had hoped to simulate with lognormals: SDs often in the range of 0.01 to 0.0001. Depending on how the MCMC algorithm selects its initial values, I can imagine those values often starting way outside the probable range, impeding gradient descent. Seems like another distribution would be more appropriate.
And hey, just stumbled across this article: http://www.stat.columbia.edu/~gelman/research/published/taumain.pdf. There Gelman advocates trying these prior distributions in order, only stepping up as needed for sufficient constraint: uniform, wide half-normal, half-Cauchy. He says inverse-gammas are a bad idea.
Some examples in the Stan manual also use half-Cauchy for sds. They look like this, where the first arg to cauchy() (location on Wikipedia, or mu in Stan) must always be 0 to split it down the middle:
real<lower=0> sigma_alpha;
sigma_alpha ~ cauchy(0,5);

The second argument (scale/gamma on Wikipedia, sigma in Stan) is the half-width at half-maximum (HWHM) - sounds like it should be easily scalable, just like a half-normal, but I'll need to try that out.
Cauchy distributions are cool because they have no defined mean and variance. (https://en.wikipedia.org/wiki/Cauchy_distribution) That doesn't seem to be a problem for this application.

These two produce the same shapes (on different x and y scales), which I take as confirmation that scaling Cauchy distributions is a matter of multiplying:
scale=0.1; x=seq(0,0.4,0.01); y=dnorm(x, 0, scale)/sqrt(dgamma(0.5, 0.5)); plot(x=x, y=y)
scale=0.5; x=seq(0,2,0.01); y=dnorm(x, 0, scale)/sqrt(dgamma(0.5, 0.5)); plot(x=x, y=y)

implemented half-Cauchy distributions for all sigmas. Retrying bob's minimal, reproducible example to see where we've arrived. It's...so so...
> dat <- data_metab('3','10')
> mm <- mm_name('bayes', pool_K600 = 'none', err_obs_iid=TRUE, err_proc_iid=TRUE) %>%
+     specs(K600_daily_mu = 80, K600_daily_sigma = 50) %>%
+     metab(data=dat)
> mm
metab_model of type metab_bayes
streamMetabolizer version 0.9.15
Specifications:
  model_name               b_np_oipi_tr_plrckm.stan
  engine                   stan
  split_dates              FALSE
  keep_mcmcs               TRUE
  keep_mcmc_data           FALSE
  day_start                4
  day_end                  28
  day_tests                full_day, even_timesteps, complete_data
  GPP_daily_mu             10
  GPP_daily_sigma          10
  ER_daily_mu              -10
  ER_daily_sigma           10
  K600_daily_mu            80
  K600_daily_sigma         50
  err_obs_iid_sigma_scale  0.1
  err_proc_iid_sigma_scale 0.1
  params_in                GPP_daily_mu, GPP_daily_sigma, ER_daily_mu, ER_daily_sigma, K600_daily_mu, K600...
  params_out               GPP_daily, ER_daily, K600_daily, err_obs_iid_sigma, err_proc_iid, err_proc_iid_...
  n_chains                 4
  n_cores                  4
  burnin_steps             500
  saved_steps              500
  thin_steps               1
  verbose                  FALSE
  model_path               C:/Users/aappling/Documents/R/win-library/3.3/streamMetabolizer/models/b_np_oip...
Fitting time: 290.51 secs elapsed
Parameters (3 dates):
        date GPP.daily GPP.daily.lower GPP.daily.upper    ER.daily ER.daily.lower ER.daily.upper K600.daily
1 2012-09-18 1.231250       -0.4024146        2.864915 -0.9308041       -2.096724      0.2351159  15.08567
2 2012-09-19 1.837421        1.4623788        2.212463 -1.3468435       -1.719149     -0.9745385  20.14213
3 2012-09-20 1.782635        1.3948713        2.170399 -1.1568900       -1.452055     -0.8617254  20.96433
  K600.daily.lower K600.daily.upper msgs.fit
1        -2.263132         32.43447  w
2        16.792018         23.49225  w
3        17.032194         24.89646  w
Fitting warnings:
  There were 106 divergent transitions after warmup. Increasing adapt_delta above 0.8 may help.
  Examine the pairs() plot to diagnose sampling problems
  3 dates: overall warnings
Predictions (3 dates):
        date      GPP  GPP.lower GPP.upper        ER  ER.lower   ER.upper msgs.fit msgs.pred
1 2012-09-18 1.616853 -0.2456719  2.049953 -1.193698 -1.580887  0.1110020  w
2 2012-09-19 1.833043  1.5061073  2.204614 -1.335040 -1.661224 -0.9827837  w
3 2012-09-20 1.779000  1.4100788  2.169484 -1.160718 -1.489752 -0.8638437  w
> traceplot(get_mcmc(mm), pars=c('GPP_daily','ER_daily','K600_daily'))

traceplot(get_mcmc(mm), pars=c('err_obs_iid_sigma','err_proc_iid_sigma'))

plot_distribs(mm, 'err_obs_iid_sigma')

plot_distribs(mm, 'err_proc_iid_sigma')

with default specs
> mm <- mm_name('bayes', pool_K600 = 'none', err_obs_iid=TRUE, err_proc_iid=TRUE) %>%
+     specs() %>%
+     metab(data=dat)
> mm
metab_model of type metab_bayes
streamMetabolizer version 0.9.15
Specifications:
  model_name               b_np_oipi_tr_plrckm.stan
  engine                   stan
  split_dates              FALSE
  keep_mcmcs               TRUE
  keep_mcmc_data           FALSE
  day_start                4
  day_end                  28
  day_tests                full_day, even_timesteps, complete_data
  GPP_daily_mu             10
  GPP_daily_sigma          10
  ER_daily_mu              -10
  ER_daily_sigma           10
  K600_daily_mu            30
  K600_daily_sigma         30
  err_obs_iid_sigma_scale  0.1
  err_proc_iid_sigma_scale 0.1
  params_in                GPP_daily_mu, GPP_daily_sigma, ER_daily_mu, ER_daily_sigma, K600_daily_mu, K600...
  params_out               GPP_daily, ER_daily, K600_daily, err_obs_iid_sigma, err_proc_iid, err_proc_iid_...
  n_chains                 4
  n_cores                  4
  burnin_steps             500
  saved_steps              500
  thin_steps               1
  verbose                  FALSE
  model_path               C:/Users/aappling/Documents/R/win-library/3.3/streamMetabolizer/models/b_np_oip...
Fitting time: 285.9 secs elapsed
Parameters (3 dates):
        date GPP.daily GPP.daily.lower GPP.daily.upper   ER.daily ER.daily.lower ER.daily.upper K600.daily
1 2012-09-18 1.623522         1.229228        2.017816 -1.194027       -1.490962     -0.8970930  19.39247
2 2012-09-19 1.920339         1.596256        2.244422 -1.390199       -1.658109     -1.1222897  20.94280
3 2012-09-20 1.697993         1.352229        2.043758 -1.106144       -1.365389     -0.8469001  19.94359
  K600.daily.lower K600.daily.upper msgs.fit
1         15.51596         23.26899  w
2         17.81874         24.06686  w
3         16.71711         23.17006  w
Fitting warnings:
  There were 58 divergent transitions after warmup. Increasing adapt_delta above 0.8 may help.
  Examine the pairs() plot to diagnose sampling problems
  3 dates: overall warnings
Predictions (3 dates):
        date      GPP GPP.lower GPP.upper        ER  ER.lower   ER.upper msgs.fit msgs.pred
1 2012-09-18 1.623878  1.211278  1.987140 -1.190518 -1.530144 -0.9179317  w
2 2012-09-19 1.916740  1.615383  2.265045 -1.395304 -1.667812 -1.1574600  w
3 2012-09-20 1.687975  1.377388  2.139196 -1.117426 -1.364146 -0.8727695  w
> plot_distribs(mm, 'err_obs_iid_sigma')
> plot_distribs(mm, 'err_proc_iid_sigma')

as of 915dc80d83, we have cauchy distributions with parameter scaling for all the error sigmas and (when present) K600_daily_sigma. For now, and maybe forever, there are many parameters that are not being scaled, some of which i'm more confident in than others:
GPP_dailiy, ER_daily, K600_daily - early tests showed that scaling these often only increased runtime. They typically take on values between 0.5 and 100 (or -0.5 and -20 for ER), so maybe that's fine forever.
err_proc_acor_phi - has a beta distribution, which puts it between 0 and 1 but perhaps very close to one or the other for a specific set of parameters. so far not scaling it at all...maybe that's fine? maybe not?
err_proc_iid, err_proc_acor_inc - the actual error terms should be about as close to 0 as their sigmas. Should they be scaled? could do the rescaling on these terms rather than on their sigmas, actually...but i'd like to wait until i've finished #264 and know better how the code surrounding these error terms will look.
K600_daily_mu, K600_daily_beta as K-pooling terms - will take another look at these at resolution of #224 and during debugging of all pool_K600 models. (binned in particular works horribly right now)


Copying measures

This is potentially a limitation on the Power BI side. So, this is just to confirm: Tabular Editor allows copying of measures. When you do this with two Power BI sources (as opposed to SSAS) TE initially allows it but on saving the model the attached error message comes up.

This behaviour seems to have changed in a recent update of Power BI, as it was certainly possible to do before (although unsupported by Microsoft...)
It looks like the issue arises when copying a measure that has an annotation - specifically the "Format" annotation used by Power BI. I tried removing the annotations from measures I had copied into the PBI model, and that allowed me to save the model. The measures appeared in PBI after I saved the .pbix file and restarted PBI Desktop.
Until I find a workaround in Tabular Editor (or until Microsoft decides to support TOM changes on the diagnostics port), you can use the following script to remove annotations from measures:
Selected.Measures.ForEach(m => m.RemoveAnnotation("Format"));

Save this script as a custom action for easy reuse.

Could you provide some more details on how to reproduce this? Are you copying that measure, then running the script to remove the annotations, then saving it, or am I missing something? Thanks!

I ran the script. For most measures it works but for the one shown in the screen shot above I get the message. I am not quite sure what "extended properties" are and where you can manage them.

I just discovered that most of the objects in the TOM have an ExtendedProperties property, which is not documented anywhere, and apparently is only used for models of compatibility level 1400+:

My guess is that Power BI attaches some additional information for internal housekeeping as ExtendedProperties, which could explain the error you're seeing. Indeed, if you create a quick measure and copy it from Tabular Editor into a text editor, you'll see the following:
{
  "InstanceID": "c2e02c1e-72f7-454d-85ef-5a5e685c97a5",
  "measures": [
    {
  "name": "SalesAmount plus Freight",
  "expression": "\nSUM('FactInternetSales'[SalesAmount]) + SUM('FactInternetSales'[Freight])",
  "formatString": "\\$#,0.###############;(\\$#,0.###############);\\$#,0.###############",
  "dataType": "decimal",
  "modifiedTime": "2018-09-14T06:30:23.136667",
  "structureModifiedTime": "2018-09-14T06:30:22.463333",
  "extendedProperties": [
    {
      "type": "json",
      "name": "MeasureTemplate",
      "value": {
        "version": 0,
        "daxTemplateName": "MathematicalAddition"
      },
      "modifiedTime": "2018-09-14T06:30:22.463333"
    }
  ],
  "annotations": [
    {
      "name": "Format",
      "value": "<Format Format=\"CurrencyGeneral\" ThousandSeparator=\"True\"><Currency LCID=\"1033\" DisplayName=\"$ English (United States)\" Symbol=\"$\" PositivePattern=\"0\" NegativePattern=\"0\" /></Format>",
      "modifiedTime": "2018-09-14T06:30:23.136667"
    }
  ]
}
  ]
}

I will see if I can gain some more knowledge about how Power BI uses the ExtendedProperties structure, and consider whether it would make sense to expose it in Tabular Editor. As a workaround when copying measures, you could simply remove the extendedProperties and annotations sections from the JSON above, before pasting it into your target model, and then I think everything should work.

Instead of manually editing the JSON through a text editor, I managed to brew up the following Tabular Editor script, that will clear the extended properties and annotations of all currently selected measures. Use it instead of the script I provided above, and you should be good to go:
var extProp = typeof(Measure).GetProperties(
    System.Reflection.BindingFlags.Instance |
    System.Reflection.BindingFlags.NonPublic
    ).FirstOrDefault(p => p.PropertyType.Name == "Measure" && p.Name == "MetadataObject");

foreach(var m in Selected.Measures)
{
    m.RemoveAnnotation("Format");
    var tomObject = (Microsoft.AnalysisServices.Tabular.Measure)extProp.GetValue(m);
    tomObject.ExtendedProperties.Clear();
}

Sorry for the late reply on this. Seems like some stuff was changed recently (within the last 3 months), in the Power BI model metadata, that makes it difficult to add/remove/modify measures and calculated tables.
There's not much we can do about it at this point. Version 2.8 of Tabular Editor adds support for Extended Properties, which may help a little bit, but it doesn't solve all the scenarios listed above.
Hopefully, Power BI will have better support for AMO/TOM changes in the future - especially once the XMLA endpoints of the Power BI service are opened up.


Failed assertion: line 5235 pos 12: '_history.isNotEmpty': is not true.

Got this message:

'package:flutter/src/widgets/navigator.dart': Failed assertion: line 5235 pos 12: '_history.isNotEmpty': is not true.
Either the assertion indicates an error in the framework itself, or we should provide substantially more information in this error message to help you determine and fix the underlying cause.
In either case, please report this assertion by filing a bug on GitHub:

I was validating a list with the method "isNotEmpty" in another list with this:
(filesAttach.isNotEmpty
                  ? [
                      Container(
                        width: 30,
                        height: 30,
                        alignment: Alignment.topRight,
                        child: Container(
                          width: 15,
                          height: 15,
                          decoration: BoxDecoration(
                              shape: BoxShape.circle,
                              color: const Color(0xffc32c37),
                              border:
                                  Border.all(color: Colors.white, width: 1)),
                          child: Padding(
                            padding: const EdgeInsets.all(0.0),
                            child: Center(
                              child: Text(
                                filesAttach.length.toString(),
                                style: const TextStyle(fontSize: 10),
                              ),
                            ),
                          ),
                        ),
                      )
                    ]
                  : [])

I use parenthesis to append this element to another list when conditional is True, I don't know why it's happening this error.

Trying another ways, I discovered that when I use my item builder like this, the error doesn't happen:
itemBuilder: (BuildContext bc) {
        return [
          PopupMenuItem(
            onTap: () => openFileView(filesAttach),
            child: Text('file.attach'.tr()),
          )
        ];
      },

Calling the method openFileView like above example, I got the error,
but calling directly doesn't raises error messages:
// For some reason this works, but calls my method in the moment where I tap the PopupMenuButton, so it's not working for me
          PopupMenuItem(
            onTap: openFileView(filesAttach),
            child: Text('file.attach'.tr()),
          )

Sorry for my bad english, I hope it works

Navigator.of(context).pushReplacement(MaterialPageRoute())

Hi @maucoder-ingeint,
It seems your question is best suited for support channels like StackOverflow, so please ask the same there for solutions if any.
If you are proposing a change, please use the appropriate new issue template and fill out the requested details so that we can address this issue properly.
Closing for now.

I think it was an flutter error for the log message, sorry for that and thanks for reply


Wow & Flutter?

Description
When listening to Ultra High quality 24-bit / 96 kHz streaming FLAC streaming music (and lower), the pitch of the music sounds varies like the old analog wow and flutter from analog tapes.
Steps to Reproduce

stream music
listen
run processor-intensive activity
listen

Expected Behavior
I expect the pitch of the music to remain untouched.
Setup Information:

Audio device used for playback: Klipsch 2.1 THX System
Audio transmission interface: 3.5mm Analog Jack
macOS Version: 13.0 Beta (22A5331f)
eqMac Version: 1.6.1
eqMac Driver: 2.2.0
eqMac UI Version: 4.2.0
Network: gigabit Ethernet

What app are you using to stream the Music?

Amazon.
Eric
On September 5, 2022 at 2:52:58 AM, Roman Kisil @.@.)) wrote:

What app are you using to stream the Music?
—
Reply to this email directly, view it on GitHub(https://github.com/bitgapp/eqMac/issues/724#issuecomment-1236785114), or unsubscribe(https://github.com/notifications/unsubscribe-auth/AI62YORBGJKM47VRJ4YNOOTV4W7HVANCNFSM6AAAAAAQEOWOYE).
You are receiving this because you authored the thread.Message ID: @.***>


MPU flash write

This is a rebase of #205. This is needed to even enable the flash driver on NXP without faulting.

Thanks for picking this back up!
This LGTM; one minor question is about the discussion in #205 on whether MPU_ALLOW_FLASH_WRITE should be 'default y if FLASH', or if the user should need to know about it and turn it on.
You've noted that the changed configuration is required on NXP just to enable the flash driver -- regardless of whether flash_erase() or flash_write() are called. I wonder if a better name for it would be MPU_ALLOW_FLASH_ACCESS, and make it default y if flash.

It might be easiest to bring this in without changing the default, and a future patch could do that if we agree. Right now, without this patch, the flash drivers aren't useful, with it as is, it at least can be enabled.

You've noted that the changed configuration is required on NXP just to enable the flash driver -- regardless of whether flash_erase() or flash_write() are called. I wonder if a better name for it would be MPU_ALLOW_FLASH_ACCESS, and make it default y if flash.

We need more than just flash write access though, we also need sram execute, and I think enabling sram execute should be explicit. The reason we fault when enabling the nxp flash driver is that the driver init actually tries to execute from ram. The problem code is under the shim, in ext/hal/nxp/mcux/drivers/fsl_flash.c:2695:
/* Workround for some devices which doesn't need this function */
callFlashCommonBitOperation((FTFx_REG32_ACCESS_TYPE)0, 0, 0, 0)

I'm not quite sure yet why the driver does this.

I have stumbled upon the problem with MPU and mcux flash driver while playing with #542 and usb dfu class sample.
As Maureen already described, it can be fixed by something like this:
+#ifdef CONFIG_SOC_FLASH_MCUX
+#define MPU_REGION_EXEC_FROM_RAM       MPU_REGION_EXEC
+#else
+#define MPU_REGION_EXEC_FROM_RAM       0
+#endif
+
 /* Super User Attributes */
 #define MPU_REGION_SU   ((SM_SAME_AS_UM << BM0_SM_SHIFT) | \
                          (SM_SAME_AS_UM << BM1_SM_SHIFT) | \
@@ -77,6 +83,7 @@
 /* Some helper defines for common regions */
 #define REGION_RAM_ATTR          (MPU_REGION_READ | \
                           MPU_REGION_WRITE | \
+                          MPU_REGION_EXEC_FROM_RAM | \
                           MPU_REGION_SU)

The driver uses the InRamFunctions when it executes from flash. K64F Reference Manual was not really helpful, I only found a note in Chapter 29.4.7: "The MCU must not read from the flash memory while commands are running...".  Anyway, I think permanent permission to execute the code from the RAM is not a good solution.

I'm not quite sure yet why the driver does this.

The way the NXP controller is implemented the entire contents of flash go away while performing flash operations. This is fairly common among lots of NOR controllers. It generally takes extra hardware to be able to read/execute from FLASH that do allow reads of the parts that aren't being programmed.

Anyway, I think permanent permission to execute the code from the RAM is not a good solution.

Is the concern here with rogue code making it into RAM, and then some kind of pointer fault causing it to execute at this address? Yes this is a concern, but I don't think it is a particularly common exploit. One of the things we're going to have to face here is that the MPU isn't going to be able to protect everything, and we need to figure out what is most important to protect.
We can certainly make this dynamic, but it adds complexity and additional functionality, not really intended.
I fear we are going to end up bikeshedding this patch series to death, and never get it in. As it is, the MPU is completely useless for any code that needs to write to flash. On NXP, it is worse, and the MPU prevents boot entirely if the flash driver is even enabled. An MPU that protects some things is better than having to disable it entirely.

Instead of adding more configuration files prj_XXX.conf which are platform specific I would prefer to document the options instead or add them to the original config file and disable them and document that they need to be enabled.

Wouldn't this also mean that they won't get tested, either?
I'm beginning to lean toward the correct solution here being to not have these config options, but just a few settings that get selected according to what other features are enabled:

enabling CONFIG_FLASH causes CONFIG_MPU_ALLOW_FLASH_WRITE to be selected.
enabling both CONFIG_FLASH and the NXP CONFIG_SOC_FLASH_MCUX will enable CONFIG_MPU_ALLOW_RAM_EXECUTE.

I'll give a little time for feedback on this proposal, and then rework the patches to do this.

I fear we are going to end up bikeshedding this patch series to death, and never get it in

Guilty :(. Let me get out of your way...

Need to address @dbkinder doc comments.
Need @nashif to re-visit his review.
Substance of patch LGTM I think we should proceed, I think we all have an understanding that the memory protection features are going to be subject to iterative refinement over the next 6 months or so, we can tinker with this down the line if we need to.

New patches. Addressed @nashif comments by eliminating new config files, and adding commented out (and described) lines in the main prj.conf file. This also addresses @dbkinder comments by simplifying what is written in the docs.

Ping @dbkinder, I believe I've addressed your concern.


Result of .compute() operation exceeds memory limits

Hey dask contributors, sometimes it's difficult to anticipate whether the result of a .compute() operation will end up exceeding memory limits.
I'm creating an issue because there's potential for dask to be able to help out here, for example by issuing a warning when a user tries to create a very large result.
Or, it might be useful to provide a way to inspect a partially-computed dask array for the purpose of determining whether the results are desirable; perhaps this would be easier.

I see two things here:
Dask.array.compute could warn when .nbytes would return a value greater than total memory (as determined by an optional call to psutil.virtual_memory().total.  NumPy does this sometimes.
@gbrener you can partially compute a dask.array by computing a slice:
x[:10].compute()

That's an interesting idea. A few caveats:

We'd only be able to do that in array.compute (and maybe if we hacked it into dask.compute, but I'd be slightly against that).
It would only be able to catch cases where the output was large, not the intermediates.

If these are acceptable, then adding that check seems fine to me.

Since this is hard to do generally (can't tell if intermediates will overflow), and a partial solution may be confusing to users (dask didn't error, but more memory was still used), I'm closing for now. Feel free to reopen if desired.


HADOOP-19360. Disable releases for apache.snapshots repo

What changes were proposed in this pull request?
The Apache snapshot repository should be enabled only for snapshots.
Downloading from apache.snapshots.https: https://repository.apache.org/content/repositories/snapshots/com/google/protobuf/protobuf-java/3.25.5/protobuf-java-3.25.5.pom

https://github.com/apache/hadoop-thirdparty/actions/runs/11588886714/job/32263341813#step:4:9755
https://issues.apache.org/jira/browse/HADOOP-19360
How was this patch tested?
local build

Thanks @ayushtkn for the review.


Allow different bundling technique for schemas below draft 2019-09

Because the compound schema and bundling behavior was not finalized until draft 2019-09 it's not really possible to dictate behavior and instead I will suggest leaving it up to the user which technique to use.
The two I see are:

The main default one, compound schema as is.
Absolute references to definitions instead of keeping the old references

I know there are arguments to be made that reference libraries SHOULD be able to understand the compound schemas, reality is that we are going to be with a leg in each camp until the tools mature, and until then, options 2 will make it possible to all tools to understand the schemas because it's the basic premise they operate on.
For context, we encountered this problem with vscode https://github.com/asyncapi/spec-json-schemas/issues/247 and we have to adapt the bundling of the AsyncAPI schema files. The best scenario would be to enable this on a library level instead of us having to build our own custom solution.
cc @derberg

Although bundling wasn't mentioned in the spec until 2019-09, the mechanism it uses has existed since draft-03. The problem isn't that VSCode hasn't gotten around to supporting bundling yet. The problem is that VSCode has a bug. It doesn't make sense for me to implement workarounds for every implementation that won't fix their bugs, even if it is VSCode.
But even if I did want to work around VSCode's bugs, there are problems with your proposal that make it a no-go. It's not as easy as just rewriting external references. If you don't bundle using $id (or ignore $id), you change how those bundled schemas behave. You have to not just rewrite the external reference, you have to rewrite every reference in the referred to schema. You also have to deal with conflicts in $anchors in any of the schemas being bundled. These are much more complex problems to solve than this implementation is designed to deal with. It couldn't be a simple config option. I'd have to reimplement with a different approach. In fact, the whole reason I wrote this implementation in the first place was to show that it's unnecessary to solve those problems.
I sympathize with your problem and I understand why AsyncAPI would want to be able to work around VSCode's bugs, but it doesn't make sense for this library to do that even if there was a way I could feasibly provide what you need. I'll be looking into filing an bug report with VSCode if there isn't one already.

compound schemas will only work in some libraries

That's not true. This has been required functionality since draft-03. It's not new or optional. There are always a few outliers that choose not to fix their known bugs, but this works properly in the vast majority of implementations.


steam-tui: 0.1.0 -> 0.3.0

Description of changes
Updated steam-tui to most recent release. Closes https://github.com/dmadisetti/steam-tui/issues/70
Things done

Update to 0.3.0

Add dmadisetti as maintainer

Exclude "impure" tests explicitly as done in the flake.

ran nixfmt

Built on platform(s)

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

For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)

[ ] sandbox = relaxed
[ ] sandbox = true

[x] Tested, as applicable:

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

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage

[x] Tested basic functionality of all binary files (usually in ./result/bin/)

24.11 Release Notes (or backporting 23.11 and 24.05 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[x] Fits CONTRIBUTING.md.

Add a :+1: reaction to pull requests you find important.

Result of nixpkgs-review pr 323851 run on x86_64-linux 1

1 package built:

steam-tui


Discover observability needs

Thoughts:

Scheduled check that confirms index page returns a 200 status
Cloudwatch alerts:

High number of 404 for specific url
Any 500 responses


Check out cool no-unsafe-code intrusive-style dlist

@pythonesque showed this to me on IRC: https://gist.github.com/pythonesque/5943252fb464b49123fa#file-dlist-rs
It's a fascinating approach to implementing a DList that requires no unsafe code - instead of having an overarching handle to the head and tail, you instead access one node at a time, similar to a cursor or zipper over the structure, and it then safely patches itself up as you move around.
This seems like a killer justification for the use of Zippers/Cursors and/or Traversals and is also really darn cool.

It's a cool idea, but iteration required mutation, which seems like a Rust non-starter.

@Gankro I see it being useful in some contexts but it will always be a specialized solution.

Definitely logging it in my design bank though, if only as a funner answer to "how do I implement a doubly linked list in Rust?"


Spyder hangs "Loading Code Analysis" when starting from console in Linux

Update to v6.0.0 and launch "spyder &" from the console. The result is always the same when using the fork "&" operator. When launching spyder without forking a new process, the IDE starts flawlessly.
This is the output when running  "spyder --debug-info verbose &"
[...]
2024-09-06 16:35:50,336 [INFO] [spyder.app.mainwindow] -> Loading Code Analysis...
2024-09-06 16:35:50,346 [INFO] [spyder.app.mainwindow] -> Loading pylint...
2024-09-06 16:35:50,376 [INFO] [spyder.app.mainwindow] -> Registering shortcuts for pylint...
2024-09-06 16:35:50,376 [DEBUG] [spyder.api.plugin_registration.registry] -> Plugin preferences has already loaded
2024-09-06 16:35:50,376 [DEBUG] [spyder.api.plugin_registration.mixins] -> Calling <bound method Pylint.on_preferences_available of <spyder.plugins.pylint.plugin.Pylint object at 0x7f18b8026200>>
2024-09-06 16:35:50,376 [DEBUG] [spyder.api.plugin_registration.registry] -> Plugin editor has already loaded
2024-09-06 16:35:50,376 [DEBUG] [spyder.api.plugin_registration.mixins] -> Calling <bound method Pylint.on_editor_available of <spyder.plugins.pylint.plugin.Pylint object at 0x7f18b8026200>>
2024-09-06 16:35:50,377 [DEBUG] [spyder.api.plugin_registration.registry] -> Plugin project_explorer has already loaded
2024-09-06 16:35:50,377 [DEBUG] [spyder.api.plugin_registration.mixins] -> Calling <bound method Pylint.on_projects_available of <spyder.plugins.pylint.plugin.Pylint object at 0x7f18b8026200>>
2024-09-06 16:35:50,377 [DEBUG] [spyder.api.plugin_registration.registry] -> Plugin mainmenu has already loaded
2024-09-06 16:35:50,377 [DEBUG] [spyder.api.plugin_registration.registry] -> Registering plugin pythonpath_manager - <class 'spyder.plugins.pythonpath.plugin.PythonpathManager'>
2024-09-06 16:35:50,377 [DEBUG] [spyder.api.plugin_registration.mixins] -> Method on_main_menu_available is watching plugin mainmenu
2024-09-06 16:35:50,377 [DEBUG] [spyder.api.plugin_registration.mixins] -> Method on_main_menu_teardown will handle plugin teardown for mainmenu
2024-09-06 16:35:50,377 [DEBUG] [spyder.api.plugin_registration.mixins] -> Method on_projects_available is watching plugin project_explorer
2024-09-06 16:35:50,377 [DEBUG] [spyder.api.plugin_registration.mixins] -> Method on_projects_teardown will handle plugin teardown for project_explorer
2024-09-06 16:35:50,377 [DEBUG] [spyder.api.plugin_registration.mixins] -> Method on_toolbar_available is watching plugin toolbar
2024-09-06 16:35:50,378 [DEBUG] [spyder.api.plugin_registration.mixins] -> Method on_toolbar_teardown will handle plugin teardown for toolbar
2024-09-06 16:35:50,378 [DEBUG] [spyder.api.plugin_registration.mixins] -> Method on_main_menu_available is watching plugin mainmenu
2024-09-06 16:35:50,378 [DEBUG] [spyder.api.plugin_registration.mixins] -> Method on_main_menu_teardown will handle plugin teardown for mainmenu
2024-09-06 16:35:50,378 [DEBUG] [spyder.api.plugin_registration.mixins] -> Method on_projects_available is watching plugin project_explorer
2024-09-06 16:35:50,378 [DEBUG] [spyder.api.plugin_registration.mixins] -> Method on_projects_teardown will handle plugin teardown for project_explorer
2024-09-06 16:35:50,378 [DEBUG] [spyder.api.plugin_registration.mixins] -> Method on_toolbar_available is watching plugin toolbar
2024-09-06 16:35:50,378 [DEBUG] [spyder.api.plugin_registration.mixins] -> Method on_toolbar_teardown will handle plugin teardown for toolbar
[Here it hangs...]

Hey @marianux, thanks for reporting. This is a duplicate of issue #22415, so I'm going to close it in favor of that.
You can also find there some workarounds to deal with that problem while we fix it.


fix errors for combineNER

fix errors when a compound word consists of two words and appears at the end of a sentence

谢谢！


Render hyperlinks and paragraphs in text testimony

When displaying testimony, we should render hyperlinks as clickable links, and add spacing between paragraphs.

Use https://github.com/gregjacobs/Autolinker.js/ to add clickable links. We should convert links, emails, and phone numbers. We should also truncate links after, say, 20 characters for readability
Split testimony into paragraphs using a regex, and wrap each paragraph in  tags.

Can we change the limit from 20 chars to 32 for example? here's how it looks and I think 20 is not enough
20

vs 32

How do we define paragraphs in testimony? As it's just a plain text, what should we look for in regex? Empty lines?

Answer - new line

Remove www


Simple unit tests are very slow compared to other frameworks

I want to migrate from a different unit testing framework to TUnit. I created a copy of one of my simple unit tests with TUnit, but the results were not what I expected. The unit test can be optimized from a code perspective but I didn't do it because I wanted to test the performance of the frameworks without code optimizations. Maybe I am doing something wrong it will be good if you give me feedback.
The results:
I am using Visual Studio Community 2022 Preview (17.12.0 Preview 5) I run the tests with both frameworks with .NET 8 and .NET 9 in Release.

The test projects with 'New' inside the name are with TUnit.
Old framework code:

TUnit code:

What's the other framework you were using?

Found it, Machine.Specifications
Your problem is that they're not reporting you a correct time.
Here's an example:
using System.Threading;
using Machine.Specifications;

namespace Tests
{
    [Subject("Test")]
    public class When__Testing_Time
    {
        class When_Wait_5_Seconds
        {
            Because of = () => Thread.Sleep(5000);
            private It should_report_5_seconds = () => { };
        }
    }
}

You see I've got a 5 second Thread.Sleep in there.
But it's telling me it took 1ms:

TUnit is giving you the accurate time.

Hmm, maybe you are right.
Thank you!


Animation

A question: how can I add transition and keyframes animation? Is that possible?
Thanks.

@7h3und34d  You can define animations using the keyframes api from @fower/core, and use it in css animation: https://fower.vercel.app/docs/keyframes.

Awesome!
Thanks @forsigner


Adding flatbuffers

Please add the following dependency to the rosdep database.
Package name:
flatbuffers
Package Upstream Source:
https://github.com/google/flatbuffers
Purpose of using this:
it is needed to decode the fbl logfiles of https://github.com/BehaviorTree/BehaviorTree.CPP
Distro packaging links:
Links to Distribution Packages

Ubuntu
from jammy: https://packages.ubuntu.com/jammy/python3-flatbuffers
Debian
In debian 11 there is https://packages.debian.org/bullseye/python3-flatbuffers

There are no other distro packages available, so I propose to use https://pypi.org/project/flatbuffers/

Sorry for that, @tfoote. My yaml formatter must have a different idea about yaml formatting ;)


tsterinfo -b fails to calculate parameters due to undefined DeliverySystem

Bug description:
tsterinfo -b fails to calculate modulation parameters given a specific bitrate on latest master.
The call to theoreticalBitrate() always returns 0 due to DeliverySystem argument not being set in tsterinfo.cpp and thereby defaults to DS_UNDEFINED. This causes the switch statement to skip computation of the theoretical bitrate, and prints every possible combination as having a bitrate of zero.
How to reproduce:

git clone https://github.com/tsduck/tsduck.git && cd tsduck
make -j 10
./bin/*/tsterinfo -b 18,096,256

Expected behavior:
Expected was the closest DVB-T parameters being printed.
Errors and logs:
None.
Environment:

OS: Linux
OS version: Ubuntu 18.04
TSDuck full version: 3.24-2067
Installation type: rebuilt binary from latest master

Additional information:

Hi @Foorack
Thanks for reporting this and sorry for the inconvenience. This is of course a bug, a regression which was introduced some time ago when there was some substantial refactoring on modulation parameters when ISDB was added. Unfortunately, there was no non-regression test on this specific feature.
I fixed this is commit 71f60eead055d1ddada94b3f84971bb147d3664f and also added a non-regression test to make sure it will never reappear.

Verified fixed. ✅ Thank you. Closing.


 I just want to auto edit videos, so i got github, and ive been trying to figure out how to use for like the past 45 mins. Please help. This is how far I've got...   V

watch the video

https://github.com/carykh/jumpcutter/issues/114#issuecomment-501682890 maybe these instructions can help

watch the video

https://youtu.be/DQ8orIurGxw?t=600


Toggle blocking of tor nodes

Just some simple command that will toggle blocking all connections from IPs that were specified per line in some ASCII file.

Do it in your own fork

Yeah, it sounds like these are good ideas, but I think they would be better in a new fork, so I'd encourage you to give that a try. And right now, I wouldn't even have enough time to review PRs.

No need to fork, we already have some other place that works well. But as a moderator it would be nice to at least have some control to handle such situations - at the moment the ban system feels like it could even be removed completely as it'd not make any difference.

Although I'd look silly saying "banana time" if I couldn't ban right after

just check out that mass spam happening a lot recently https://www.0x17.de/hackchat/issue2.png https://www.0x17.de/hackchat/issue3.png

I guess now the point is moot. No chat => no spammers


[Task]: add github tag to project

Task description.
On app build, fetch project latest tag and add to version file. Display version in footer.

I close this issue since it seems duplicated


I haven't personally tried it, but the extension at https://marketplace.visualstudio.com/items?itemName=pdconsec.vscode-print looks like it might help you.

I haven't personally tried it, but the extension at https://marketplace.visualstudio.com/items?itemName=pdconsec.vscode-print looks like it might help you.
Originally posted by @gjsjohnmurray in https://github.com/microsoft/vscode/issues/73693#issuecomment-491980129
It will. This is a scenario that is expressly supported. In order to support any markdown extensions you might also be using, I hijack the rendering pipeline that vscode uses internally. So for example if you use KaTeX to put LaTeX equations in a markdown document, the equations will print correctly.

Whoops that was supposed to be a comment.


Updated terraform script to use patched version

This partially patches CVE-2016-5195 (http://dirtycow.ninja/). Services
boxes should be updated manually.

IGYB


Cancel editing or creating content leads to wrong url

No matter if you create a new content or edit an existing content:
After clicking the "Cancel" Button you get to a non existing page:
"Hey! Have you seen my ball?"
The URL is
"/bludit-2.0_a3/admin/manage-posts"
but it should be
"/bludit-2.0_a3/admin/pages"

Fixed, thanks !


MQTT client won't initialize

Describe the bug
MQTT client won't initialize, please check settings
To Reproduce
Steps to reproduce the behavior:
Fresh install of the latest APK on galaxy tab A8. Settings, setup home assistant addon mqtt details. Tried variius combinations, no luck repeatedly get same error
Smartphone (please complete the following information):

Device: Samsung Galaxy tab A8
OS: Android 13
Applicaiton version: Wallpanel v0.12.0 build 0

Bump

Same for me. Came from v0.9.6 and tried to upgrade one of my two tablets.
Connection to ioBrokers built in MQTT broker does not work with the latest Play Store version of this app.
With Protocol 5.x : "MQTT client won't initialize, please check settings".
With older 3.x protocol selected the app goes in a furious crash loop and must be uninstalled to break out of it.
I tried every possible constellation of settings and ruled out everything on my side. It is this app version.
I am switching back to an old non-Play Store version of this app. 0.9.6-beta.0 is still working fine and MQTT is working there. Link

I had exactly the same problem from a similar scenario - upgrading from thanksmister version to thetimewalker version (from playstore). After trying every combination of settings it occurred to me I'd installed the latest version alongside the old version, and only then deleted the old version.  Thinking there may have been some sort of conflict, I uninstalled the latest version (so no wallpanel installed at all), rebooted fire tablet and reinstalled thetimewalker version again from playstore.  Problems disappeared and worked immediately. YMMV.

I'm using the playstore version and have ben unable to get this to work


Fails to deserialize hasMany relationship when empty

Hi, first thanks for your work.
I'm having some trouble with a hasMany relationship which actually has no records.
I have a JSON like that :
{
  "data": [
    {
      "type": "articles",
      "id": "1",
      "attributes": {
        "title": "My Title",
      },
      "relationships": {
        "comments": {
          "data": null
        }
      }
    }
  ],
}

My model is like that
@JsonApi(type = "article")
public class Article extends UpdatableResource {
  public String title;
  public HasMany<Comment> comments;
}

I'm getting this error :
com.squareup.moshi.JsonDataException: Expected BEGIN_ARRAY but was NULL at path $.data[0].relationships.comments.data
I'm using this converter for retrofit

Released by 3.4.0 :tada:


[BUG] the first loading in ubuntu take so long time

Describe the bug
why the loading in ubuntu take so long time?
To Reproduce
Steps to reproduce the behavior:

Start simple project in ubuntu
You will see the fist initail loading take too much time

Expected behavior
Fast loading as like in mac
I also attached the part that take too much time to load

@w3nder,
why do you thumb down?
When i load the bail eyes lib is take very long time in linux

@w3nder, why do you thumb down?
When i load the bail eyes lib is take very long time in linux

This problem is not with Baileys, but with your code.

but when i run the same code in mac, it load in sec..

I run my APIs on Ubuntu servers without any problems, this problem is with you, node version, poorly written code.

Hi,
What is your version of node?
What do you mean poorly code? I tried also run the default example,
I think the problem is that I compile the to. While running. So at Mac is
fast cause I have high cou and memory and Ubuntu is small vps.
Can you please share the command you start your Nodejs app?
Thanks
בתאריך יום ג׳, 10 בספט׳ 2024 ב-21:54 מאת Wender Teixeira <
@.***>:

I run my APIs on Ubuntu servers without any problems, this problem is with
you, node version, poorly written code.
—
Reply to this email directly, view it on GitHub
https://github.com/WhiskeySockets/Baileys/issues/1028#issuecomment-2341778107,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ABXZDOVXVRHNCPXPMXWUUNDZV457PAVCNFSM6AAAAABNTYW7Z2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGNBRG43TQMJQG4
.
You are receiving this because you authored the thread.Message ID:
@.***>


OperationalData mosaic dataset references invalid data paths

Mosaic data on data file server Data\MAoW07072015\Geodatabase\OperationalWeather.gdb\OperationalData references local paths instead of UNC paths; also references paths that do not exist.

@joebayles

Data is legacy data and has been deleted so issue can be closed.

Verified that folder Data\MAoW07072015 no longer exists. Closing issue.


[Feature] Optimizers with LR multipliers

This PR implements optimizers with learning rate multipliers, which can be used to apply different learning rates for different layers. For example:
optimizer = MultiSGD(multipliers={'dense_1': 0.8})

In this example, parameter multipliers indicates that layers whose name contain dense_1 have a learning rate multiplier of 0.8 with respect to global learning rate.
Related issue
#728

Codecov Report

Merging #729 into 2.2-dev will decrease coverage by 0.15%.
The diff coverage is 92.62%.

@@             Coverage Diff             @@
##           2.2-dev     #729      +/-   ##
===========================================
- Coverage    94.09%   93.93%   -0.16%
===========================================
  Files           91       99       +8
  Lines         3115     3481     +366
===========================================
+ Hits          2931     3270     +339
- Misses         184      211      +27

Impacted Files
Coverage Δ

matchzoo/optimizers/multi_optimizer.py
87.5% <87.5%> (ø)

matchzoo/optimizers/multi_adam.py
88.13% <88.13%> (ø)

matchzoo/optimizers/multi_sgd.py
91.11% <91.11%> (ø)

matchzoo/optimizers/multi_adagrad.py
93.18% <93.18%> (ø)

matchzoo/optimizers/multi_rmsprop.py
93.18% <93.18%> (ø)

matchzoo/optimizers/multi_adadelta.py
93.87% <93.87%> (ø)

matchzoo/optimizers/multi_adamax.py
94.23% <94.23%> (ø)

matchzoo/optimizers/multi_nadam.py
96.49% <96.49%> (ø)

... and 6 more

Continue to review full report at Codecov.

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

should be a pr to keras rather than matchzoo.


Next/Previous Track buttons not showing

Hi,
I hadn't updated my SmartIR/ home assistant for a while as I was in the middle of a major home network overhaul - I have updated now, and I no longer have next/previous track buttons visible on the media player card in the lovelace UI.
For reference:-
HA Core 2021.4.1 OS5.13
Smart IR 1.16.0
I am using Broadlink IR blasters.
The next/previous track works if I manually call up the service/entity using developer tools, I just don't get the buttons on the UI. I am 99% sure I previously had the buttons on there. The relevant config is:-
#Living Room TV Ping switch to determine if on
binary_sensor 10:

platform: ping
host: <IP_ADDRESS>
scan_interval: 5
name: living_room_tv_power

#Living Room TV controls thru broadlink 1063.json is code file
media_player 10:

platform: smartir
name: Living room TV
unique_id: living_room_tv
device_code: 1063
controller_data: remote.livingroom_remote
power_sensor: binary_sensor.living_room_tv_power

The code file is my own.

These options were removed from Home Assistant. There is an open request in HA repo to restore them.

Well that would explain the issue. Thanks mate, appreciate the response, and all the work you've done on this integration.


Prediction Bug

InteractionPredictor::CollisionWithEgoVehicleCost
the while is a endless loop , how should i modify this code?

How to update the remained_s variable ?

@HongyiSun
@kechxu
How to update the remained_s variable ?

@wanggujin The judgment condition of while is as follows
https://github.com/ApolloAuto/apollo/blob/514e23a19561307513af91ad3d3fe2ab23c5a5d3/modules/prediction/predictor/interaction/interaction_predictor.cc#L313
I don't understand where is the problem?


[BUG] "TypeError: metaclass conflict: the metaclass of a derived class must be a (non-strict) subclass of the metaclasses of all its bases" when building envpool from sources

Importing envpool fails since about two days with the error message:
"TypeError: metaclass conflict: the metaclass of a derived class must be a (non-strict) subclass of the metaclasses of all its bases"
It did not do this before July 13th (date is not very precise).
I verified that the problem occurs after building and pip installing envpool from the freshly generated wheel on:

A Ubuntu 20.04.2 installation (python 3.8.10, gcc 9.3.0-17ubuntu~20.04)
On a Google Colab installation (afer installing bazel), Python 3.7.13, gcc (Ubuntu 9.4.0-1ubuntu1~18.04) 9.4.0

The issue did not occur before on both platforms!
Code to reproduce the issue:
import envpool
Detailed error message:
---------------------------------------------------------------------------
TypeError                                 Traceback (most recent call last)
[<ipython-input-15-a0a27c8e85d7>](https://localhost:8080/#) in <module>()
----> 1 import envpool as envpool
      2 import numpy as np
      3
      4 # make gym env
      5 env = envpool.make("Pong-v5", env_type="gym", num_envs=100)

5 frames
[/usr/local/lib/python3.7/dist-packages/envpool/__init__.py](https://localhost:8080/#) in <module>()
     14 """EnvPool package for efficient RL environment simulation."""
     15
---> 16 import envpool.entry  # noqa: F401
     17 from envpool.registration import (
     18   list_all_envs,

[/usr/local/lib/python3.7/dist-packages/envpool/entry.py](https://localhost:8080/#) in <module>()
     14 """Entry point for all envs' registration."""
     15
---> 16 import envpool.atari.registration  # noqa: F401
     17 import envpool.box2d.registration  # noqa: F401
     18 import envpool.classic_control.registration  # noqa: F401

[/usr/local/lib/python3.7/dist-packages/envpool/atari/__init__.py](https://localhost:8080/#) in <module>()
     20
     21 AtariEnvSpec, AtariDMEnvPool, AtariGymEnvPool = py_env(
---> 22   _AtariEnvSpec, _AtariEnvPool
     23 )
     24

[/content/envpool/envpool/python/api.py](https://localhost:8080/#) in py_env(envspec, envpool)
     32     EnvSpecMeta(spec_name, (envspec,), {}),  # type: ignore[return-value]
     33     DMEnvPoolMeta(pool_name.replace("EnvPool", "DMEnvPool"), (envpool,), {}),
---> 34     GymEnvPoolMeta(pool_name.replace("EnvPool", "GymEnvPool"), (envpool,), {}),
     35   )

[/content/envpool/envpool/python/gym_envpool.py](https://localhost:8080/#) in __new__(cls, name, parents, attrs)
     84
     85     attrs["_to"] = _to_gym
---> 86     subcls = super().__new__(cls, name, parents, attrs)
     87
     88     @no_type_check

[/usr/lib/python3.7/abc.py](https://localhost:8080/#) in __new__(mcls, name, bases, namespace, **kwargs)
    124         """
    125         def __new__(mcls, name, bases, namespace, **kwargs):
--> 126             cls = super().__new__(mcls, name, bases, namespace, **kwargs)
    127             _abc_init(cls)
    128             return cls

TypeError: metaclass conflict: the metaclass of a derived class must be a (non-strict) subclass of the metaclasses of all its bases

It does not seem to be dependent on the Python package versions of the other dependencies (numpy, gym). The package from pip.  does not exhibit the problem.  I checked the version I compiled from source against the official pip release in envpool==0.6.2.post2.  envpool==0.6.2.post2 does not exhibit the problem, while the version I compiled from source does. My working assumption is that the problem is related on the C++ side, either compiler version or somewhere inside pybind11.

Duplicated as #166. It has been fixed in #167.


Updated composer from v1.6.5 to v1.7.0

See v1.7.0 release notes here:
https://github.com/composer/composer/releases/tag/1.7.0

Could not review pull request. It may be too large, or contain no reviewable changes.


HDWallet creation thread-safe

Description
HDWallet creation is not thread-safe, calling simultaneously from multiple threads may result in invalid recovery phrases, and thus error.
Fix this by making the underlying Trezor lib methods -- mnemonic_generate() and mnemonic_from_data() -- thread safe, by using user-supplied output buffer instead of a common global variable.
Note that this PR is based on #1527 ar/hdwallet-error-fix, it should come after it; diff should be looked relative to that.
(Continuation of #1505 )
Testing instructions
Unit tests, esp.HDWallet.MultipleThreads.
Types of changes

Bug fix (non-breaking change which fixes an issue)

Checklist

[x] Prefix PR title with [WIP] if necessary.
[x] Add tests to cover changes as needed.
[x] Update documentation as needed.
[x] I have read the guidelines for adding a new blockchain
[x] If there is a related Issue, mention it in the description (e.g. Fixes #<issue_number> ).

Squashed commits, cleaned history

Good


Update addPoint Function

Updated the point function to check if the animation is still on progress. This prevents the animation to bug if you spam the button!

beautiful


Multiselect on categories

It would be great if you could multiselect values on category fields. Currently you can only select one category to filter on.
Any interest in this? I don't mind taking a crack at it.

we would definitely be open to a PR on this, thanks!

@Wattenberger would you be able to give me permissions to make PRs 🙏?

@nikodraca do you mind forking the repo and creating a PR from there? Similar to this PR:
https://github.com/githubocto/flat-ui/pull/10

@Wattenberger revisiting this now that I have a better understanding of the codebase - I think the first item of work is multiselect on category fields. I believe this will be doable with Downshift (though I don't have any experience with it).
The second item of work, which I think requires a larger discussion, is about filtering on array fields:

is filtering by array fields a feature you/others would want? Personally I have a use case where I'd like to be able to filter on multiple items of an array (ie. give me all rows where the array includes X or Y)
is there a reason to display X item(s) in the cell vs something like a stringified array for array fields?
I can't quite figure out the difference between a short-array and array, could you explain this to me?

Excited to contribute 😄

is filtering by array fields a feature you/others would want? Personally I have a use case where I'd like to be able to filter on multiple items of an array (ie. give me all rows where the array includes X or Y)

I bet we'll be able to add multiselect in a way that doesn't detract from the single-select use case. If so, I bet a lot of people would find it useful!

is there a reason to display X item(s) in the cell vs something like a stringified array for array fields?
I can't quite figure out the difference between a short-array and array, could you explain this to me?

I think these questions are related. We're differentiating between columns where the contents are usually one item in an array (short-array) and other arrays (array). This is so we can display shorter array values in a more readable fashion, whereas longer arrays are potentially easier to "read" & compare if we just display the number of items in each array.
https://github.com/githubocto/flat-ui/blob/main/src/store.ts#L813-L831
Let me know if any of that didn't make sense!

So if I understand correctly the idea was that arrays really meant to be filtered by length and less by the contents?
Follow up q: couldn't we consolidate categories and short-arrays?

hmm, potentially. They wouldn't automatically be categories, but could be passed further down and treated the same as columns of strings: https://github.com/githubocto/flat-ui/blob/main/src/store.ts#L688
I'm a bit hesitant to do more "magic" handling of data, though! The farther we get from the raw data, the less reliable the table view gets. There is the possibility to treat items within array values are rendered as pills, similar to category values, which is perhaps what you're getting at. In that case, I think the path forward would be to have a multiselect filter, and to change the render component for arrays.

Ok cool, thanks for answering all my questions 😄

Hey @Wattenberger 👋  wanted to share some progress and get some feedback:
https://user-images.githubusercontent.com/3537270/154796985-ab232baa-1a24-4cef-991b-7c06208c6794.mov
What's New:

Categories filters are now arrays
Input is now multiselect (using Downshift's [useMultipleSelection](https://www.downshift-js.com/use-multiple-selection)
Column header shows current selection with option to remove

Questions:

Wasn't sure what the UX for displaying/removing current selection should be. I opted for displaying them in a row and making that scrollable. Any thoughts on this?
You might notice in the screencast that when filtering on the second category it shows the count as 0 (cool (0)). This is because a row can only have 1 category, but category filters apply to the entire dataset, not just the filtered subset. I'm thinking of instead counting how many rows have that category from originalData instead of filteredData. Does that make sense?

Hey @Wattenberger 😄 just wanted to check in on this, really eager to get the ball rolling!

Hey @Wattenberger sorry to bother again, I'd love to get some eyes on this! Is there someone on the team you could put me in touch with?

hey Niko! sorry about the delay! I was moving cross-country and now the team is heads-down on a launch. I'll try to get to this within the next week!

No worries at all! Hope the move went well 😄

okay! this is looks great, thanks for the progress! A few tiny suggestions:

it might be nice to have the input/prompt centered vertically when there are no active filters, to match the other headers
I think the horizontal list is a good route, since we don't want to change the height of the header cell. Might be worth bumping the font-size down for the pills, decreasing the horizontal spacing, and adding some vertical padding around the list. You could also expand the list on hover, similar to what we do for cells with long text content.
probably also worth removing the circle around the :x: icons, to decrease visual noise
you could also make the "dropdown" overlay taller, skinnier, and add some vertical padding

I'm thinking of instead counting how many rows have that category from originalData instead of filteredData. Does that make sense?
Makes total sense!

great progress so far!

Ah super frustrating! Good luck re-building those changes!


add aria-label to c-button

What's New
Added aria-label for icon only buttons that puts the name of the icon

Coverage increased (+0.4%) to 72.603% when pulling 24ca8af6287feab07085214f724655317c539d2f on aria-label-buttons into 9e32bee173a685ca2bc25c24c12983c3aec893da on master.


Adding self to contributors list

Just adding myself to the contributors list!

Well deserved!

Hey @oyeanuj, have you added you on the readme file?

@sergiokopplin thank you! I wasn't sure about the README file, if that was just pulling from the contributors file or I have to add in both places?

Might be both places man! Not sure, sorry hahaha

I think I got your back on the next branch already. Definitely well deserved @oyeanuj! Really appreciate your continuous involvement. ❤

@ctrlplusb thank you, appreciate it!


chore(deps): upgrade dependencies

Upgrades project dependencies. See details in workflow run.

Automatically created by projen via the "upgrade-k8s-23-main" workflow

⚪ Backport skipped
The pull request was not backported as there were no branches to backport to. If this is a mistake, please apply the desired version labels or run the backport tool manually.
Manual backport
To create the backport manually run:
backport --pr 1012

Questions ?
Please refer to the Backport tool documentation


[ZEPPELIN-4360] Always use Scala 2.11 for Ignite

also bump dependencies & update docs
What is this PR for?
Ignite interpreter uses Scala interface to Ignite that is built only with Scala 2.11, while inside Zeppelin it was compiled with global Scala dependency (Scala 2.10 by default), so it didn't work out of box. Also, the Ignite dependency was updated to the latest version.
What type of PR is it?
Bug Fix
What is the Jira issue?
https://issues.apache.org/jira/browse/ZEPPELIN-4360
How should this be tested?
unit tests + manual tests were done

LGTM

@alexott There's some conflict after I merge #3474 , could you help fix that ? Thanks

@zjffdu I rebased the changes on top of master

@alexott  Could you paste the travis build link here ? Need to make sure CI pass before merging.

https://travis-ci.org/alexott/zeppelin/builds/595481396 - it's failing in PythonDocker code


Pass pinia options in model

Hi!
I'm currently working on a project in which I have to migrate from Vue2 with Vuex-ORM into Vue3 with Pinia-ORM. One of the requirements of the project is to persist the store during page reloads (which I try to accomplish with the pinia-plugin-persistedstate plugin). To configure this plugin I have to add an option to my store description.
The issue I'm facing is that I can't figure out how to access this store description inside of a Model. I can imagine that other plugins will work the same way (options in the store description), so it might be an interesting addition to the package!
My proposed solution is to add a static field to the Model in which you could add options that are inserted (with a spread operator) into the store description. Maybe something like static piniaOptions = {}?

But i think the persist thing will be your least problem if you want to move from vuex-orm to pinia-orm, because this is based on vuex-orm-next. So maybe some relation functions which are maybe used in your project arent yet there.

@JochemVanIterson In fact where is already a way implemented:
the second argument of useRepo, takes a pinia store definition.
export function useRepo(
  modelOrRepository: any,
  storeGenerator?: (id: string) => StoreDefinition,
  connection?: string
)

but i defently will be moving pinia store defenitions to the model.

Cool! Thanks a lot!

But i think the persist thing will be your least problem if you want to move from vuex-orm to pinia-orm, because this is based on vuex-orm-next. So maybe some relation functions which are maybe used in your project arent yet there.

Yes, I'm also using the vuex-orm-axios and graphql plugins, but these are definitely broken on the new version (haven't tested them though). It's going to be a long transition I imagine!


Switching to conda-eda feed.

I've logged the failure in https://github.com/SymbiFlow/sphinxcontrib-hdl-diagrams/issues/85


picker with preview - always open in home dir.

Using picker - 'tmux new-session nnn -P u' always starts in home directory.
Expected result:  nnn picker should open in current file dir.
Changing back to cmd='nnn -G -C  will open nnn in current file dir (or is it project dir) .
I hope someone can confirm.

Also - when using nnn without preview - q will close picker with poupu. But with picker enabled I have to press q twice - once to close main window, then to close preview, then ctrl+d to kill/close the  nnn popup.

To start nnn in the directory of the current directory, run with %:p:h as argument i.e. NnnPicker %:p:h (see README).

Also - when using nnn without preview - q will close picker with poupu. But with picker enabled I have to press q twice - once to close main window, then to close preview, then ctrl+d to kill/close the nnn popup.

This is due to a race condition described in https://github.com/jarun/nnn/pull/1189#issuecomment-933029985.
You can try if adding a small sleep to the beginning of winch_handler() in preview-tui helps, I think sleep 0.4 fixed it in my case but you might be able to go lower depending on your system.
Of course adding this sleep to winch_handler will delay resizing image previews which is why I hadn't pushed it yet, still looking for a proper fix.

Ok I think I got it to work. Just note for other people facing similar issues. Lua mapping:
vim.api.nvim_set_keymap( "n", "<F4>", "<Cmd>NnnPicker %:p:h<CR>", { noremap = true, silent = true} )

Wont work on directories that contain space in name (nnn will just blink). For 'normal' folder it will display nnn - with preview.
Using vim.cmd works ok though  (with preview and in folder with spaces too):
 vim.cmd([[nnoremap <F4> <cmd>NnnPicker<CR>]])

Also interesting - I'm using system shortcut key for running nvim in terminal ( alacritty -e sh -c "sleep 0.1 && nvim") , this makes nnn preview missing (even if using vim.cmd() mapping - and adding sleep to winch_handler() ) .
The optimal way to run nnn with preview is to use vim.cmd() for mapping, and running  nvim manually from command line. Then nnn will work in folders with spaces, and it will show previews, and q-key will close nnn popup correctly.

Please check if https://github.com/luukvbaal/nnn.nvim/commit/6e6b690accf8cdc7d560b032ada60cc4bdd06fbf fixes your issues with directories containing spaces.

I'm not sure I understand the problem you're describing with your system shortcut key.
What does nnn preview missing mean?

The spaces in file path issue is solved - I can see nnn even when running nvim from hotkey.    About missing previews.
Running nnn when  nvim was opened from system shorcut:

Running nnn when nvim was opened manually  (first open terminal, then type in 'nvim'):n

I'm not sure why the UI style is so different  between running nnn  'manually' and from shortcut.

Now I think I may have two versions in nnn installed, and each of them is executed - depending on how nvim was started. I will check it out.

 Probably NNN_PLUG is not set in your sh environment, but is set in your regular shell environment.

sleep  supposed to  help make nvim window size match alacritty terminal size when running from hotkey. Otherwise often nvim would take half screen of terminal size.
Ok i can see that :!env  | grep NNN is empty when executed from nvim that what started from hotkey (nvim started manually can see NNN env variables) . I'm not sure where should  I setup additional NNN variables.
I tried:

maybe missing NNN variables in local tmux  is the source of problem?  Sorry for so many questions, and thanks for your time.

Please check if https://github.com/luukvbaal/nnn.nvim/commit/5e4cb0fdc4802106deea61d77f4196abff27aa96 fixes your terminal size issue without the sleep (and sh -c).

@luukvbaal Maybe I was not clear  - the sleep in alacritty -e sh -c "sleep 0.1 && nvim" has nothing to do with nnn picker.  It is workaround for nvim window not taking full space of alacrity terminal window.
It just so happens, that when running nvim using above command from system shortcut,  then opening  nnn picker does now give previews  (but is caused by missing env variables as you pointed out).
Somehow nvim sees or does not see env variables, depending on how it was started.

Alright, there was a bug in the win_resized function though so picker window resizing was not working in general.
Regarding your env, I would try to use the -c flag of your regular shell. So instead of sh -c '...', zsh -c '...' or bash -c.

Thanks - changing sh - zsh did the trick. Weird since I had defined  NNN variables in both zsh and bash, but whatever works.
Closing

@JoseConseco with https://github.com/jarun/nnn/pull/1226 merged you should be able to remove the sleep from winch_handler.
Test it out and confirm if you can

All works great.  Btw after yesterday fight with env vars   tmux envs  were reset.  I'm not sure why they wont save correctly after restart. But command works:
picker={ cmd="tmux new-session -e NNN_FIFO=/tmp/nnn.fifo.preview -e NNN_PLUG='p:preview-tui;f:fzcd;o:fzopen;d:diffs' nnn -Pp -G -C -d " }, -- with -G git, -d details

-e   -> lets you set env variable for session.

Thanks for confirming.
Yeah that is a weird way to set your environment but whatever works for you 🤷🏻♂


Logger should not iterate over a string context

The serializeContext() function in lodestar-utils/src/logger/format.ts iterates over strings. While running the validator there was a network error that produced this output
0=N, 1=o, 2= , 3=r, 4=e, 5=s, 6=p, 7=o, 8=n, 9=s, 10=e, 11= , 12=r, 13=e, 14=t, 15=u, 16=r, 17=n, 18=e, 19=d, 20= , 21=f, 22=o, 23=r, 24= , 25=m, 26=e, 27=t, 28=h, 29=o, 30=d, 31= , 32=g, 33=o, 34=o, 35=d, 36=b, 37=y, 38=e, 39=., 40= , 41=r, 42=e, 43=q, 44=u, 45=e, 46=s, 47=t, 48==, 49=f, 50=6, 51=e, 52=9, 53=b, 54=4, 55=3, 56=e, 57=a, 58=8, 59=0, 60=1, 61=2, 62=a, 63=0, 64=1

This PR checks the context type and returns early if it's of type string

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.

Can you track on which line was logger called with "string" as context? Because it should throw type error when type checking if we sent string as second argument to long error.

Can you track on which line was logger called with "string" as context? Because it should throw type error when type checking if we sent string as second argument to long error.

Unfortunately, I lost the container from within I run that instance of lodestar. I'll try to capture the origin if it happens again

decoding the split string: "No response returned for method goodbye. request=blah"


make LuaTable, LuaCoroutine, LuaFunction and LuaUserdata constructible

Theres no way to new these things, and it might be irritating to people.

c++0x issue. Constructors cannot be delegated yet until c++11! Well, I guess this means a little bit of duplicated code.


Does not clean up after failing tests

When the tests run without issues, cf-openstack-validator cleans up OpenStack properly, but if some tests fail, at least in the early stages, the vms, volumes and similar do not get cleaned up so they accumulate over time.
We had this issue with version 2.4 and also with the latest 2.5.
It should be quite easy to reproduce by letting some tests fail. If not I will debug it further if this happens only for some failures.

Thanks @thardeck,
we should have coding in place to specifically avoid this: https://github.com/cloudfoundry-incubator/cf-openstack-validator/blob/master/lib/validator/api/resource_tracker.rb
If you can provide more information which tests leave resources behind, this would be very helpful. A stacktracke/an error message is also appreciated.
Thanks!

This is the output when the path to the cpi.json is wrong. The log is longer but it repeats itself basically.
The vm 7a1819c1-6001-4804-8604-70f1a32e78a6 is not cleaned up in this case.
Your OpenStack
  API
    rate limit
      is high enough... passed
    Security groups
      has ingress rule for SSH... passed
      has egress rule for HTTP... passed
      has egress rule for DNS... passed
  using the CPI
    verifying that the CPI is executable... failed
    against OpenStack
      can save a stemcell... failed
      can create a VM... skipped: No stemcell available
      has VM cid... skipped: No VM to check
      can set VM metadata... skipped: No VM to set metadata for
      can create a disk in same AZ as VM... skipped: No VM to create disk for
      has disk cid... skipped: No disk to check
      can set disk metadata... skipped: No disk to check
      can attach the disk to the VM... skipped: No VM to attach disk to
      can detach the disk from the VM... skipped: No VM to detach disk from
      can take a snapshot... skipped: No disk to create snapshot from
      can delete a snapshot... skipped: No snapshot to delete
      can delete the disk... skipped: No disk to delete
      can delete the VM... skipped: No vm to delete
      can attach floating IP to a VM... skipped: No stemcell to create VM from
      can SSH into VM... skipped: No VM to use
      can access the internet... skipped: No VM to use
      can save and retrieve user-data from metadata service... skipped: No VM to use
      can save and retrieve user-data from config_drive... skipped: `config_drive` is not configured in validator.yml.
      allows a VM to reach the configured NTP server... skipped: No VM to use
      allows one VM to reach port 22 of another VM within the same network... skipped: No VM to use
      can create a VM with static IP... skipped: No stemcell to create VM from
      allows one VM to reach port 22 of another VM with static IP within the same network... skipped: No VM with floating IP to use
      can create large disk... failed
      can delete large disk... skipped: No large disk to delete
      has configured MTU size... skipped: No VM with floating IP to use
      can delete a stemcell... skipped: No stemcell to delete

Failures:

  1) Your OpenStack using the CPI verifying that the CPI is executable
     CPI could not be called OpenStack error: Invalid CPI response - ParserError - 751: unexpected token at 'bundler: failed to load command: /usr/lib64/bosh-openstack-cpi-release/bosh_openstack_cpi/bin/openstack_cpi (/usr/lib64/bosh-openstack-cpi-release/bosh_openstack_cpi/bin/openstack_cpi)
     '

  2) Your OpenStack using the CPI against OpenStack can save a stemcell
     Stemcell could not be uploaded OpenStack error: Invalid CPI response - ParserError - 751: unexpected token at 'bundler: failed to load command: /usr/lib64/bosh-openstack-cpi-release/bosh_openstack_cpi/bin/openstack_cpi (/usr/lib64/bosh-openstack-cpi-release/bosh_openstack_cpi/bin/openstack_cpi)
     '

  3) Your OpenStack using the CPI against OpenStack can create large disk
     Large disk could not be created.
     Hint: If you are using DevStack, you need to manually set a larger backing file size in your localrc. OpenStack error: Invalid CPI response - ParserError - 751: unexpected token at 'bundler: failed to load command: /usr/lib64/bosh-openstack-cpi-release/bosh_openstack_cpi/bin/openstack_cpi (/usr/lib64/bosh-openstack-cpi-release/bosh_openstack_cpi/bin/openstack_cpi)
     '

Finished in 1 minute 10.17 seconds (files took 0.39732 seconds to load)
31 examples, 3 failures, 24 pending
Resources: The following resources might not have been cleaned up:
  VMs:
    - Name: validator-test-vm
      UUID: 7a1819c1-6001-4804-8604-70f1a32e78a6
      Created by test: Your OpenStack API rate limit is high enough

You can find more information in the logs at /root/.cf-openstack-validator/logs/testsuite.log

Error: Running 'RSpec::Core::Runner.run' with arguments '["--order", "defined", "--color", "--tty", "--require", "/usr/lib64/cf-openstack-validator/lib/validator/formatter.rb", "--format", "Validator::TestsuiteFormatter", "src/specs/cpi_lifecycle_spec.rb", "src/specs/extension_spec.rb", "src/specs/openstack_api_spec.rb", "src/specs/spec_helper.rb"]' failed

More details can be found in /root/.cf-openstack-validator/logs/testsuite.log
testsuite.log output:
D, [2017-11-14T17:10:31.750514 #17] DEBUG -- : External CPI sending request: {"method":"info","arguments":[],"context":{"director_uuid":"validator","request_id":"614262"}} with command: /usr/bin/bosh_openstack_cpi
D, [2017-11-14T17:10:32.577619 #17] DEBUG -- : External CPI got response: bundler: failed to load command: /usr/lib64/bosh-openstack-cpi-release/bosh_openstack_cpi/bin/openstack_cpi (/usr/lib64/bosh-openstack-cpi-release/bosh_openstack_cpi/bin/openstack_cpi)
, err: Errno::ENOENT: No such file or directory @ rb_sysopen - /root/.cf-openstack-validator/cpi.json
  /usr/lib64/bosh-openstack-cpi-release/ruby_openstack_cpi/lib/ruby/2.4.0/psych.rb:472:in `initialize'
  /usr/lib64/bosh-openstack-cpi-release/ruby_openstack_cpi/lib/ruby/2.4.0/psych.rb:472:in `open'
  /usr/lib64/bosh-openstack-cpi-release/ruby_openstack_cpi/lib/ruby/2.4.0/psych.rb:472:in `load_file'
  /usr/lib64/bosh-openstack-cpi-release/bosh_openstack_cpi/bin/openstack_cpi:9:in `<top (required)>'
, exit_status: pid 25 exit 1

I think the cleanup with 2.4 failed when we accidentally were using the new bosh-openstack-cpi which volume api was different so the volume related tests failed.

The CPI needs its configuration to clean up the VM. In these cases, you indeed end up with resources in your IaaS. At least the validator tells you that this is the case:


Feature Request: command line options to load additional files at boot

From @ZeroByteOrg:

Talking to MooingLemur last night, I had an idea that might make for a good enhancement (if my understanding of official R39 behavior now works)...
It's my understanding that HostFS now takes on the same speed (more or less) as SDimage due to the fact that the hook is now on ACPTR / MACPTR and not LOAD / SAVE
If that's the case, then it might be nice to add a commandline option to bootstrap-load additional files than just -prg
pglewis is doing that dancing baby demo, and was saying how each time he runs the program to test a change, it takes a while to load all the graphics and sound. So I thought a bootstrap load for arbitrary files to arbitrary locations in memory at startup might be a nice feature to speed up this sort of thing....
like -load file,addr -load file,addr -vload file,addr

Note that Box16 is still hooking LOAD and SAVE, it should probably hook ACPTR and MACPTR the way x16emu does now.

This seems like it should be relatively simple to implement similarly to how multiple cartridges are handled.


apds-9930 proximity sensor not working

I know that this is a duplicate but I am creating this in hope that some will explain in detail why some apds-9930 proximity sensor doesn't work even though ambient light does work
Answers I have seen:
Led is not getting any current -> how should it be powered then?
There is a pin to power the led -> can you not just say which one?

depends on your breakout board.
some have jumpers to select from where the LED anode should be powered.
choices are:

the Vcc pin also powering the chip (3.3V) or
a separate VL pin (max. 4.5V).


feat: deprecate event liquidity

Changes proposed in this pull request

moves toLocale() date conversions in frontend from server to client https://github.com/interledger/rafiki/pull/2318/commits/c8952eaee6f18a0498534af3ffeb0127030bb7ad
All the other changes were reviewed in the PR's for the subtasks here https://github.com/interledger/rafiki/issues/1697

Main changes:

depositEventLiquidity and withdrawEventLiquidity resolvers have been marked as deprecated and added new withdrawOutgoingPaymentLiquidity, withdrawIncomingPaymentLiquidity, and depositOutgoingPaymentLiquidity resolvers that should be used instead
liquidity fields were added to incoming/outgoing payments and wallet addresses
Breaking changes:

Renamed addAssetLiquidity resolver to depositAssetLiquidity
Renamed addPeerLiquidity resolver to depositPeerLiquidity
Renamed addedLiquidity field to liquidityToDeposit on graphql CreateOrUpdatePeerByUrlInput

Context

fixes https://github.com/interledger/rafiki/issues/1697
Checklist

[ ] Related issues linked using fixes #number
[ ] Tests added/updated
[ ] Documentation added
[ ] Make sure that all checks pass
[ ] Postman collection updated

@BlairCurrey maybe we can also make the dates in the General Information section of the admin UI be local as well. Otherwise, UI side of things looks good

@BlairCurrey maybe we can also make the dates in the General Information section of the admin UI be local as well. Otherwise, UI side of things looks good

yeah that makes sense. updated all of those and one in the asset fee history page.

@BlairCurrey
Something I noticed: if we create an outgoing payment for more than what a user has on their account (and the status of the payment is FUNDING), if we click "Deposit" payment, we should display the DebitAmount we need to cover the payment instead of $0:


.wait_for_press() not working as expected

Operating system: Raspbian Stretch
Pi model:  Pi 3 Model B
GPIO Zero version: 1.4.1
Pin factory used: GPIOZERO_PIN_FACTORY=pigpio
Using remote gpio from vscode (Windows)
My problem is that print("Button green(25) Pressed") is never printed.
Earlier when I used GPIO.wait_for_edge()  it was working ok, so I think it is bug in gpiozero
import time
import datetime
from gpiozero import LED, Button
from time import sleep

def main():

    global i
    global stop

    bRed = Button(24)
    bGreen = Button(25)

    def bRedPressed():
        print("Button red(24) pressed!")
        global stop
        global i
        i = 0
        stop = True
        bGreen.wait_for_press()  # waits for click, but stops here, although I click many times
        print("Button green(25) Pressed")  # never printed !
        i = 60*60
        stop = False
    bRed.when_pressed = bRedPressed

#script starts here
    bGreen.wait_for_press() # waits for click,  button is working, when I click it goes to next line

    i = 60*60
    stop = False
    while True:
        time.sleep(1)
        if not stop:
            i += 1
        print(str(i))

if __name__ == '__main__':
    main()

Generally speaking, if someone reports that a single commonly used function does not work, I expect the report to be as minimal as possible. If you found that wait_for_press doesn't work I want to see the smallest possible example that shows it does not work as expected, e.g:
from gpiozero import Button
btn = Button(2)
print("waiting for press")
btn.wait_for_press()
print("pressed")

I would expect this to print "waiting for press", then print "pressed" once I pressed the button. If that works, but your code doesn't, then it's not wait_for_press that doesn't work, it's something in your code.
I would try to reduce your problem down as much as possible. Start from my simple example, and work towards what you want, feature by feature. When you get to a point where it stops doing what you expected, then investigate this change.
It's hard to tell what you're trying to do - you're mixing paradigms. Please be aware that callbacks are threaded and dealing with this kind of logic inside threaded code can lead to unexpected behaviour.

Thank you for very informative answers! I will check code and will let you know :-)