text:
Stan produces incorrect result compared to bugs

The following program produces incorrect output on Pystan:
data {
int<lower=0> N;
real data308[N];
real data309[N];
}
parameters{
vector<lower=0>[1] p305;
vector<lower=0>[1] p306;
vector<lower=0>[1] p307;
}
model {
p305 ~ exponential(86.0462799877026);
print(p305);
p306 ~ gamma(76.2977147711839,9.036400327762673);
p307 ~ beta(16.18858216310588,30.844803230953854);
for(i in 1:N){
data309[i] ~ normal(p305*data308[i] + p306,p307);
}

Dataset:
data = {"data308": [13.881384907279525, 88.8576321180826, 13.327534730468448, 31.99216995059834, 2.9343668315910842, 32.55753034773304, 68.27339667028627, 56.09337663815008, 11.873143197831393, 68.75207850372635, 17.677194501454107, 87.10858398455987, 53.73957183167468, 31.983581577892473, 44.806522707431895, 95.58934804301687, 78.7618808148732, 60.12928601208836, 5.18710798773604, 52.11576609245744, 76.83796022796734, 6.651203069325251, 94.83224930634158, 33.10456891768773, 3.2995579105662864, 65.88882495557885, 54.62103231725689, 42.15765232436402, 49.423509149696656, 36.987944914920234, 30.867496465083434, 18.315363964990016, 47.04096459206848, 89.35537056437055, 98.26197625241304, 28.517149434090594, 29.490344103336476, 42.13451425862218, 93.58571395262051, 76.56423123458059, 21.68940707076206, 6.92533577024056, 98.88017358554532, 29.476032212441318, 51.34309485442834, 18.68816752461282, 41.181211848595964, 36.289930378658006, 99.60063712029682, 71.45819698376279, 48.864323393796724, 29.675016385257123, 45.46154583352858, 86.98771942090465, 53.418589651370766, 61.597707971740526, 70.99425502665976, 0.46820021309224025, 73.12784424097225, 71.93457135745, 47.79005648438862, 68.21387134324516, 96.48921053900058, 25.359331570071262, 23.45127269650685, 88.35659808824931, 80.21965858308045, 3.048123286590576, 25.10943320437484, 2.062962669432822, 20.14098226209565, 17.560082522106846, 74.6035267539682, 9.934768240915137, 1.2089294384144633, 49.64401222779657, 23.390892294491806, 77.77405277849027, 84.05770075454019, 59.723516732054414, 60.30977979708937, 98.85925469334873, 24.22906369506319, 77.62250505473493, 39.00365202666363, 80.57746624216635, 34.032531629100085, 32.01686933835683, 84.54795877637171, 2.745351424298592, 4.835019077075364, 79.9863945800936, 49.60743468816198, 81.78784494400307, 5.883448443901573, 2.374113648231535, 68.58695491256047, 97.95254398418693, 26.812087652172945, 17.411330507132426], "data309": [119.05107879638672, 718.861083984375, 114.62027740478516, 263.9373474121094, 31.47493553161621, 268.4602355957031, 554.1871948242188, 456.74700927734375, 102.98514556884766, 558.0166015625, 149.4175567626953, 704.86865234375, 437.91656494140625, 263.86865234375, 366.4521789550781, 772.7147827148438, 638.0950317382812, 489.0343017578125, 49.496864318847656, 424.9261169433594, 622.7036743164062, 61.209625244140625, 766.6580200195312, 272.8365478515625, 34.396461486816406, 535.110595703125, 444.96826171875, 345.26123046875, 403.3880615234375, 303.903564453125, 254.93997192382812, 154.52291870117188, 384.3277282714844, 722.8429565429688, 794.0958251953125, 236.13719177246094, 243.92276000976562, 345.07611083984375, 756.6857299804688, 620.5138549804688, 181.5152587890625, 63.402687072753906, 799.0413818359375, 243.80825805664062, 418.7447509765625, 157.50534057617188, 337.44970703125, 298.3194580078125, 804.8051147460938, 579.6655883789062, 398.9145812988281, 245.40013122558594, 371.6923522949219, 703.9017333984375, 435.3487243652344, 500.78167724609375, 575.9540405273438, 11.745601654052734, 593.0227661132812, 583.4765625, 390.3204650878906, 553.7109985351562, 779.9136962890625, 210.87464904785156, 195.6101837158203, 714.852783203125, 649.7572631835938, 32.384986877441406, 208.87547302246094, 24.50370216369629, 169.1278533935547, 148.4806671142578, 604.8281860351562, 87.4781494140625, 17.671436309814453, 405.152099609375, 195.12713623046875, 630.1924438476562, 680.4616088867188, 485.78814697265625, 490.4782409667969, 798.8740234375, 201.83250427246094, 628.9800415039062, 320.0292053222656, 652.6197509765625, 280.26025390625, 264.13494873046875, 684.3836669921875, 29.962810516357422, 46.680152893066406, 647.8911743164062, 404.8594665527344, 662.302734375, 55.067588806152344, 26.992908477783203, 556.6956176757812, 791.620361328125, 222.4967041015625, 147.2906494140625], "N": 100}

Output:
               mean se_mean     sd   2.5%    25%    50%    75%  97.5%  n_eff   Rhat
p305[0]        1.73    1.59   2.75   0.22   0.24   0.33   1.87   8.42      3   6.34
p306[0]         2.4    1.21   1.71   0.99    1.2   1.65   3.74   5.35      2 294.76

I compared the same model with BUGS. It gives the correct output(7.0) on this:
Model:
model {
    p1 ~ dexp(86.0462799877026)
    p2 ~ dgamma(76.2977147711839,9.036400327762673)
    p3 ~ dbeta(16.18858216310588,30.844803230953854)
    for(i in 1:N){
        tmp1[i] <- p1*x[i] + p2
        Y[i] ~ dnorm(tmp1[i], p3)
    }
}

Output:
		mean	sd	MC_error	val2.5pc	median	val97.5pc	start	sample
	p1	6.999	0.002552	9.459E-5	6.994	6.999	7.004	1001	1000
	p2	5.076	0.4679	0.0337	4.125	5.092	5.929	1001	1000

It seems you've parameterized the BUGS model differently than the Stan model.  In BUGS, dnorm accepts tau = 1/sigma^2 as the second parameter, while Stan's function normal accepts sigma as the second parameter.
Here's your Stan model, rewritten to

be more for efficient by taking advantage of vectorization;
appropriately match scale parameters of the normal distribution.

data {
  int<lower=0> N;
  vector[N] data308;
  vector[N] data309;
}
parameters{
  real<lower=0> p305;
  real<lower=0> p306;
  real<lower=0> p307;
}

model {
  p305 ~ exponential(86.0462799877026);
  p306 ~ gamma(76.2977147711839,9.036400327762673);
  p307 ~ beta(16.18858216310588,30.844803230953854);

  data309 ~ normal(p305*data308 + p306, 1/sqrt(p307));
}

I don't have BUGS, since I'm on a mac, but with JAGS (v4.3.0, via rjags), and your same model, I find
 $p1
 mcarray:
 [1] 7.998337

 Marginalizing over: iteration(100000),chain(1)

 $p2
 mcarray:
 [1] 8.084027

 Marginalizing over: iteration(100000),chain(1)

 $p3
 mcarray:
 [1] 0.678596

 Marginalizing over: iteration(100000),chain(1)

which matches pystan fairly well
1 chains, each with iter=100000; warmup=50000; thin=1;
post-warmup draws per chain=50000, total post-warmup draws=50000.

       mean se_mean     sd   2.5%    25%    50%    75%  97.5%  n_eff   Rhat
p305    8.0  2.5e-5 3.9e-3   7.99    8.0    8.0    8.0   8.01  25289    1.0
p306   8.08  1.5e-3   0.22   7.65   7.93   8.08   8.23   8.52  23092    1.0
p307   0.68  2.8e-4   0.05   0.58   0.65   0.68   0.71   0.77  27344    1.0
lp__ -660.8  9.0e-3   1.23 -664.0 -661.4 -660.5 -659.9 -659.4  18784    1.0

These estimates match to the hundredth decimal place, but I can't figure out how to make pystan print (prettily) more decimal places.
Maybe I've misunderstood something, since I can't recreate your "correct output(7.0)", but I've run many iterations so as to have some faith in these estimates.  Stan does complain at the beginning of the sampling, "The current Metropolis proposal is about to be rejected", but these messages don't continue to appear after warmup.
R session information
 R version 3.4.2 (2017-09-28)
 Platform: x86_64-apple-darwin16.7.0 (64-bit)
 Running under: macOS Sierra 10.12.6

 Matrix products: default
 BLAS: /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.frame\
 work/Versions/A/libBLAS.dylib
 LAPACK: /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.fra\
 mework/Versions/A/libLAPACK.dylib

 locale:
 [1] en_US.UTF-8/en_US.UTF-8/en_US.UTF-8/C/en_US.UTF-8/en_US.UTF-8

 attached base packages:
 [1] stats     graphics  grDevices utils     datasets  methods   base

 other attached packages:
 [1] rjags_4-6   coda_0.19-1

 loaded via a namespace (and not attached):
 [1] compiler_3.4.2  tools_3.4.2     grid_3.4.2      lattice_0.20-35

This was resolved as being due to a different parameterization of gamma.

I corrected the model now. But I still see incorrect results for another values of beta
Stan code:
data {
int<lower=0> N;
vector[N] data308;
vector[N] data309;
}
parameters{
real<lower=0> p305;
real<lower=0> p306;
real<lower=0> p307;
}
model {
p305 ~ exponential(86.0462799877026);
p306 ~ gamma(76.2977147711839,9.036400327762673);
p307 ~ beta(1.0, 1.0);

data309 ~ normal(p305*data308 + p306, 1/sqrt(p307));

}

Output:
       mean se_mean     sd   2.5%    25%    50%    75%  97.5%  n_eff   Rhat
p305   2.01    2.45   3.46 4.9e-4 5.5e-3   0.01   4.43    8.0      2 328.66
p306   8.45    0.18   0.91    6.8   7.92   8.25   8.99  10.53     26   1.04
p307   0.25     0.3   0.43 3.8e-6 4.6e-6 5.2e-6    0.5    1.0      2  53.79
lp__ -596.0    2.51   3.55 -603.9 -600.0 -594.4 -593.3 -592.6      2   2.81

Bugs works the same way though:
model {
    p1 ~ dexp(86.0462799877026)
    p2 ~ dgamma(76.2977147711839,9.036400327762673)
    p3 ~ dbeta(1.0, 1.0)
    for(i in 1:N){
        tmp1[i] <- p1*x[i] + p2
        Y[i] ~ dnorm(tmp1[i], p3)
    }
}

Output:
		mean	sd	MC_error	val2.5pc	median	val97.5pc	start	sample
	p1	7.999	0.003358	2.855E-4	7.993	7.999	8.006	1001	1000
	p2	8.054	0.1909	0.01652	7.68	8.063	8.429	1001	1000
	p3	0.9794	0.01941	0.001005	0.9259	0.9856	0.9994	1001	1000

You're right that Stan seems to be having some issues with the (latest) model you present, but I don't think the results you're getting should be considered an issue.

Stan's summary output is telling you that it fit this model poorly; consider the columns of your Stan output, n_eff and Rhat.  A good description of these quantities is found in sections 30.3 and 30.4 of the Stan reference manual.

I fit the model and Stan produces many warnings about it:

Informational Message: The current Metropolis proposal is about to be rejected because of the following issue:
Exception: beta_lpdf: Random variable is 1.00103, but must be less than or equal to 1  (in 'unknown file name' at line 16)
If this warning occurs sporadically, such as for highly constrained variable types like covariance matrices, then the sampler is fine, but if this warning occurs often then your model may be either severely ill-conditioned or misspecified.

Even if these warnings stop showing up after some sampling time, I bet you could rerun the sampling process and chances are good you'd get an incredibly long output of this message, repeatedly.
The issue is likely about the different support for the beta distribution (0,1) compared to the scale parameter for the normal, > 0.  The transformation 1/sqrt(x) attempts to match the supports, but I believe issues arise at the boundaries.  Try constraining the variable p307 to stay away from the boundaries with
real<lower=1e-5, upper=1-1e-5> p307;
I won't guess as to why Bugs can, so naturally, better handle this model, but it's nice that it can.

p307 needs an upper bound of 1 in addition to the lower bound of 0.
A beta(1, 1) distribution has a mean of 1 / (1 + 1) = 0.5 which is in fact
consistent with the Stan result (within the MCMC standard error) but
extraordinarily inconsistent with the Open BUGS answer.  As Edward
notes the Stan answer should still be taken with a grain of salt due
to the high Rhat which indicates ineffective mixing.
Please post these kinds of modeling questions on the Discourse
forum and not as issues unless you can properly verify that you are
getting an incorrect answer.

On Mar 16, 2018, at 12:23 PM, Edward A. Roualdes notifications@github.com wrote:
You're right that Stan seems to be having some issues with the (latest) model you present, but I don't think the results you're getting should be considered an issue.
Stan's summary output is telling you that it fit this model poorly; consider the columns of your Stan output, n_eff and Rhat. A good description of these quantities is found in sections 30.3 and 30.4 of the Stan reference manual http://mc-stan.org/users/documentation/.
I fit the model and Stan produces many warnings about it:
Informational Message: The current Metropolis proposal is about to be rejected because of the following issue:
Exception: beta_lpdf: Random variable is 1.00103, but must be less than or equal to 1 (in 'unknown file name' at line 16)
If this warning occurs sporadically, such as for highly constrained variable types like covariance matrices, then the sampler is fine, but if this warning occurs often then your model may be either severely ill-conditioned or misspecified.
Even if these warnings stop showing up after some sampling time, I bet you could rerun the sampling process and chances are good you'd get an incredibly long output of this message, repeatedly.
The issue is likely about the different support for the beta distribution (0,1) compared to the scale parameter for the normal, > 0. The transformation 1/sqrt(x) attempts to match the supports, but I believe issues arise at the boundaries. Try constraining the variable p307 to stay away from the boundaries with
real<lower=1e-5, upper=1-1e-5> p307;
I won't guess as to why Bugs can, so naturally, better handle this model, but it's nice that it can.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub https://github.com/stan-dev/stan/issues/2490#issuecomment-373767151, or mute the thread https://github.com/notifications/unsubscribe-auth/ABdNllncCMj_t0oaFbNq05QnV5gf9r6_ks5te-bsgaJpZM4SlP18.

Summary:  The model's ill-specified for the data, so this is just another instance of the folk theorem.
@syclik : BUGS uses the same gamma parameterization, and it's the same as Stan's.
@roulades:  Thanks for looking into this.  The fix you suggest, real<lower=1e-5, upper=1-1e-5> p307; should be a last resort.   The first thing to do is impose the required constraints from the distributions:
data {
  int<lower=0> N;
  vector[N] data308;
  vector[N] data309;
}
parameters{
  real<lower = 0> p305;
  real<lower = 0> p306;
  real<lower = 0, upper = 1> p307;
}
model {
  p305 ~ exponential(86.0462799877026);
  p306 ~ gamma(76.2977147711839,9.036400327762673);
  p307 ~ beta(1.0, 1.0);
  data309 ~ normal(p305*data308 + p306, 1/sqrt(p307));
}

I converted the data to R format:
data308 <- c(13.881384907279525, 88.8576321180826, 13.327534730468448, 31.99216995059834, 2.9343668315910842, 32.55753034773304, 68.27339667028627, 56.09337663815008, 11.873143197831393, 68.75207850372635, 17.677194501454107, 87.10858398455987, 53.73957183167468, 31.983581577892473, 44.806522707431895, 95.58934804301687, 78.7618808148732, 60.12928601208836, 5.18710798773604, 52.11576609245744, 76.83796022796734, 6.651203069325251, 94.83224930634158, 33.10456891768773, 3.2995579105662864, 65.88882495557885, 54.62103231725689, 42.15765232436402, 49.423509149696656, 36.987944914920234, 30.867496465083434, 18.315363964990016, 47.04096459206848, 89.35537056437055, 98.26197625241304, 28.517149434090594, 29.490344103336476, 42.13451425862218, 93.58571395262051, 76.56423123458059, 21.68940707076206, 6.92533577024056, 98.88017358554532, 29.476032212441318, 51.34309485442834, 18.68816752461282, 41.181211848595964, 36.289930378658006, 99.60063712029682, 71.45819698376279, 48.864323393796724, 29.675016385257123, 45.46154583352858, 86.98771942090465, 53.418589651370766, 61.597707971740526, 70.99425502665976, 0.46820021309224025, 73.12784424097225, 71.93457135745, 47.79005648438862, 68.21387134324516, 96.48921053900058, 25.359331570071262, 23.45127269650685, 88.35659808824931, 80.21965858308045, 3.048123286590576, 25.10943320437484, 2.062962669432822, 20.14098226209565, 17.560082522106846, 74.6035267539682, 9.934768240915137, 1.2089294384144633, 49.64401222779657, 23.390892294491806, 77.77405277849027, 84.05770075454019, 59.723516732054414, 60.30977979708937, 98.85925469334873, 24.22906369506319, 77.62250505473493, 39.00365202666363, 80.57746624216635, 34.032531629100085, 32.01686933835683, 84.54795877637171, 2.745351424298592, 4.835019077075364, 79.9863945800936, 49.60743468816198, 81.78784494400307, 5.883448443901573, 2.374113648231535, 68.58695491256047, 97.95254398418693, 26.812087652172945, 17.411330507132426)
data309 <- c(119.05107879638672, 718.861083984375, 114.62027740478516, 263.9373474121094, 31.47493553161621, 268.4602355957031, 554.1871948242188, 456.74700927734375, 102.98514556884766, 558.0166015625, 149.4175567626953, 704.86865234375, 437.91656494140625, 263.86865234375, 366.4521789550781, 772.7147827148438, 638.0950317382812, 489.0343017578125, 49.496864318847656, 424.9261169433594, 622.7036743164062, 61.209625244140625, 766.6580200195312, 272.8365478515625, 34.396461486816406, 535.110595703125, 444.96826171875, 345.26123046875, 403.3880615234375, 303.903564453125, 254.93997192382812, 154.52291870117188, 384.3277282714844, 722.8429565429688, 794.0958251953125, 236.13719177246094, 243.92276000976562, 345.07611083984375, 756.6857299804688, 620.5138549804688, 181.5152587890625, 63.402687072753906, 799.0413818359375, 243.80825805664062, 418.7447509765625, 157.50534057617188, 337.44970703125, 298.3194580078125, 804.8051147460938, 579.6655883789062, 398.9145812988281, 245.40013122558594, 371.6923522949219, 703.9017333984375, 435.3487243652344, 500.78167724609375, 575.9540405273438, 11.745601654052734, 593.0227661132812, 583.4765625, 390.3204650878906, 553.7109985351562, 779.9136962890625, 210.87464904785156, 195.6101837158203, 714.852783203125, 649.7572631835938, 32.384986877441406, 208.87547302246094, 24.50370216369629, 169.1278533935547, 148.4806671142578, 604.8281860351562, 87.4781494140625, 17.671436309814453, 405.152099609375, 195.12713623046875, 630.1924438476562, 680.4616088867188, 485.78814697265625, 490.4782409667969, 798.8740234375, 201.83250427246094, 628.9800415039062, 320.0292053222656, 652.6197509765625, 280.26025390625, 264.13494873046875, 684.3836669921875, 29.962810516357422, 46.680152893066406, 647.8911743164062, 404.8594665527344, 662.302734375, 55.067588806152344, 26.992908477783203, 556.6956176757812, 791.620361328125, 222.4967041015625, 147.2906494140625)
N <- 100

Lo and behold, the data are perfectly linearly related as far as I can tell from the plot:

So the problem you have is that the data is consistent with a standard deviation of zero. I reparameterized with a more standard regression parameterization without constraints on slope and intercept to illustrate:
data {
  int<lower=0> N;
  vector[N] data308;
  vector[N] data309;
}
parameters {
  real p305;
  real p306;
  real<lower = 0> inv_p307;
}
model {
  p305 ~ normal(0, 10);
  p306 ~ normal(0, 10);
  inv_p307 ~ lognormal(0, 2);
  data309 ~ normal(p305 * data308 + p306, inv_p307);
}
generated quantities {
  real<lower = 0> p307 = inv(inv_p307);
}

and here's what Stan gets after a long struggle and low R-hat:
             mean se_mean     sd     2.5%      25%      50%      75%    97.5% n_eff Rhat
p305         8.00    0.00    0.0     8.00     8.00     8.00     8.00     8.00  1972 1.00
p306         8.00    0.00    0.0     8.00     8.00     8.00     8.00     8.00  1585 1.00
inv_p307     0.00    0.00    0.0     0.00     0.00     0.00     0.00     0.00     4 3.22
p307     41145.33 2777.64 5731.9 32547.80 36708.31 41380.76 45572.60 53273.33     4 3.20
lp__      1035.16    5.12   10.5  1017.42  1026.92  1036.56  1043.32  1054.31     4 3.10

This is the "correct" slope and intercept for the data, and that's easy to read off the graph: p305 = 8 and p306 = 8.

And that's with a strong zero-avoiding prior.  Had we used a prior consistent with zero, the model would be better specified for the data, but we can't fit absolute zero parameters as they're -infinity on the unconstrained scale.

authors: betanalpha bob-carpenter lazypanda1 roualdes

repo: stan-dev/stan


text:
Feature/issue 2752 update ess

Submission Checklist

[x] Run unit tests: ./runTests.py src/test/unit
[x] Run cpplint: make cpplint
[x] Declare copyright holder and open-source license: see below

Summary
Re issue https://github.com/stan-dev/stan/issues/2752: update effective sample size calculations, with a small change to the autocovariance function, to use split chains.  A split_chains() functions is added.  This is only part of the requested changes in the original issue.
This PR also adds its own autocovariance function to stan-dev/stan, different than stan-dev/math's by using the biased estimates recommended by Geyer 1992.
Intended Effect
Offer interfaces a unified calculation of the latest versions of ESS and split ESS.
How to Verify
3 tests added:
test/unit/analyze/mcmc/autocovariance_test.cpp, which carries over the same dataset as used in stan-dev/math, namely ar1.csv,
test/unit/analyze/mcmc/split_chains_test.cpp
and tests for compute_split_effective_sample_size added to
test/unit/analyze/mcmc/compute_effective_sample_size_test.cpp
1 test changed:
test/unit/analyze/mcmc/compute_effective_sample_size_test.cpp now has tests based on the biased estimates of the function autocovariance.
Side Effects
The function compute_effective_sample_size() now uses biased estimates of autocovariance, which produces slightly different numbers.
Documentation
Inline.
Copyright and Licensing
Please list the copyright holder for the work you are submitting (this will be you or your assignee, such as a university or company): California State University, Chico
By submitting this pull request, the copyright holder is agreeing to license the submitted work under the following licenses:

Code: BSD 3-clause (https://opensource.org/licenses/BSD-3-Clause)
Documentation: CC-BY 4.0 (https://creativecommons.org/licenses/by/4.0/)

Sorry for the delay.  I’ll take a look at this next week —
hopefully that’ll work for everyone.

On Jun 20, 2019, at 5:24 PM, Edward A. Roualdes notifications@github.com wrote:
Submission Checklist
Run unit tests: ./runTests.py src/test/unit
Run cpplint: make cpplint
Declare copyright holder and open-source license: see below
Summary
Re issue #2752 https://github.com/stan-dev/stan/issues/2752: update effective sample size calculations, with a small change to the autocovariance function, to use split chains. A split_chains() functions is added. This is only part of the requested changes in the original issue.
This PR also adds its own autocovariance function to stan-dev/stan, different than stan-dev/math's by using the biased estimates recommended by Geyer 1992.
Intended Effect
Offer interfaces a unified calculation of the latest versions of ESS and split ESS.
How to Verify
3 tests added:
test/unit/analyze/mcmc/autocovariance_test.cpp, which carries over the same dataset as used in stan-dev/math, namely ar1.csv,
test/unit/analyze/mcmc/split_chains_test.cpp
and tests for compute_split_effective_sample_size added to
test/unit/analyze/mcmc/compute_effective_sample_size_test.cpp
1 test changed:
test/unit/analyze/mcmc/compute_effective_sample_size_test.cpp now has tests based on the biased estimates of the function autocovariance.
Side Effects
The function compute_effective_sample_size() now uses biased estimates of autocovariance, which produces slightly different numbers.
Documentation
Inline.
Copyright and Licensing
Please list the copyright holder for the work you are submitting (this will be you or your assignee, such as a university or company): California State University, Chico
By submitting this pull request, the copyright holder is agreeing to license the submitted work under the following licenses:
Code: BSD 3-clause (https://opensource.org/licenses/BSD-3-Clause https://opensource.org/licenses/BSD-3-Clause)
Documentation: CC-BY 4.0 (https://creativecommons.org/licenses/by/4.0/ https://creativecommons.org/licenses/by/4.0/)
You can view, comment on, or merge this pull request online at:
https://github.com/stan-dev/stan/pull/2774 https://github.com/stan-dev/stan/pull/2774
Commit Summary
proposed functional spec
slight doc changes
essentially zero cost splits; split and ess still separate functions
add documentation
write, and modify to pass, first tests
add tests for compute_split_ess
add split_ess methods in chains.hpp
match compute ess tests with file structure
add biased autocovariance tests
update (not split) compute effective sample size tests from using biased autocovariance
change autocovariance docs to more clearly differentiate from stan-dev/math function of same name
satisfy cpplint
Merge branch 'develop' of https://github.com/stan-dev/stan into feature/issue-2752-update-rhat-ess
File Changes
A src/stan/analyze/mcmc/autocovariance.hpp https://github.com/stan-dev/stan/pull/2774/files#diff-0 (113)
M src/stan/analyze/mcmc/compute_effective_sample_size.hpp https://github.com/stan-dev/stan/pull/2774/files#diff-1 (246)
A src/stan/analyze/mcmc/split_chains.hpp https://github.com/stan-dev/stan/pull/2774/files#diff-2 (72)
M src/stan/mcmc/chains.hpp https://github.com/stan-dev/stan/pull/2774/files#diff-3 (18)
A src/test/unit/analyze/mcmc/ar1.csv https://github.com/stan-dev/stan/pull/2774/files#diff-4 (1000)
A src/test/unit/analyze/mcmc/autocovariance_test.cpp https://github.com/stan-dev/stan/pull/2774/files#diff-5 (61)
M src/test/unit/analyze/mcmc/compute_effective_sample_size_test.cpp https://github.com/stan-dev/stan/pull/2774/files#diff-6 (188)
A src/test/unit/analyze/mcmc/split_chains_test.cpp https://github.com/stan-dev/stan/pull/2774/files#diff-7 (99)
Patch Links:
https://github.com/stan-dev/stan/pull/2774.patch https://github.com/stan-dev/stan/pull/2774.patch
https://github.com/stan-dev/stan/pull/2774.diff https://github.com/stan-dev/stan/pull/2774.diff
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub https://github.com/stan-dev/stan/pull/2774?email_source=notifications&email_token=AALU3FQ6S4N2HGCRECHR7QLP3PYP5A5CNFSM4HZ7CGGKYY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4G22DLIA, or mute the thread https://github.com/notifications/unsubscribe-auth/AALU3FU34S7HIQRQXCF7H3TP3PYP5ANCNFSM4HZ7CGGA.

Thanks for looking at this.  Just so you know, starting tomorrow I'll be on vacation / out of communication until the week of Monday, July 15.

No worries.  I just want to get something reasonably
thorough in before I begin a long string of travel and
speaking engagements next week.  I should have
time to work through the review feedback, though,
in a reasonable amount of time.

On Jul 2, 2019, at 11:39 AM, Edward A. Roualdes notifications@github.com wrote:
Thanks for looking at this. Just so you know, starting tomorrow I'll be on vacation / out of communication until the week of Monday, July 15.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub https://github.com/stan-dev/stan/pull/2774?email_source=notifications&email_token=AALU3FS5YBV7MJXJFGLCNNDP5NZERA5CNFSM4HZ7CGGKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODZBWAWI#issuecomment-507732057, or mute the thread https://github.com/notifications/unsubscribe-auth/AALU3FWVR527ABRVSC7S3HLP5NZERANCNFSM4HZ7CGGA.

I made most of the requested changes and pushed again, without replying to every comment.  Though I did respond to a few comments.

The biggest issue right now is that tests aren't passing on my machine on a fresh clone of the fork.

I believe this is due to my fork of stan-dev/stan not being up to date on the stan-dev/math submodule. My knowledge of git's submodules is lacking. Something like the following should work
git clone --recursive git@github.com:roualdes/stan.git
make math-update
git checkout feature/issue-2752-update-rhat-ess
./runTests.py -j3 src/test/unit/analyze/mcmc/

I was more recently granted write access to stan-dev/stan.  From now on I won't use my fork of stan-dev/stan, so that this issue won't come up again.

Thanks!  There are just a few more changes that I'd like to see implemented.  Let me know if my reasoning for those changes isn't sufficiently clear.

Thanks for your time here.  I just pushed changes based on your last comments.

Ah, got it.  You’re sacrificing one of the last pairs of autocorrelations
to make room for the variance-reducing bias term adding in case of
anti correlations at low lags!

On Jul 16, 2019, at 9:50 PM, Edward A. Roualdes notifications@github.com wrote:
@roualdes commented on this pull request.
In src/stan/analyze/mcmc/compute_effective_sample_size.hpp https://github.com/stan-dev/stan/pull/2774#discussion_r304113461:

double mean_var = chain_var.mean();

double var_plus = mean_var * (num_draws - 1) / num_draws;
if (num_chains > 1)

 var_plus += math::variance(chain_mean);

Eigen::VectorXd rho_hat_s(num_draws);
rho_hat_s.setZero();
Eigen::VectorXd acov_s(num_chains);
for (int chain = 0; chain < num_chains; ++chain)

 acov_s(chain) = acov(chain)(1);

double rho_hat_even = 1.0;
rho_hat_s(0) = rho_hat_even;
double rho_hat_odd = 1 - (mean_var - acov_s.mean()) / var_plus;
rho_hat_s(1) = rho_hat_odd;
// Geyer's initial positive sequence
size_t s = 1;
for (; s < (num_draws - 4) && (rho_hat_even + rho_hat_odd) > 0;
You're right. I looked over this again. It's a bit more annoying than I remembered, for reasons I won't go into unless asked.

The issue comes up in the next code chunk
if (rho_hat_even > 0)
rho_hat_s(max_s + 1) = rho_hat_even;
where rho_hat_s is indexed by essentially the value of s, which just had 2 added to it at the end of the loop, +1. Which is where strictly less than (num_draws - 4) comes from.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub https://github.com/stan-dev/stan/pull/2774?email_source=notifications&email_token=AALU3FXCU7WZ2DSFD6O3WKTP7YYCBA5CNFSM4HZ7CGGKYY3PNVWWK3TUL52HS4DFWFIHK3DMKJSXC5LFON2FEZLWNFSXPKTDN5WW2ZLOORPWSZGOB6UBNSQ#discussion_r304113461, or mute the thread https://github.com/notifications/unsubscribe-auth/AALU3FXKBAA7XPEWAJ4SEYTP7YYCBANCNFSM4HZ7CGGA.

This all looks great -- thanks for your patience!  Could you just add a comment to the now infamous num_draws - 4 line explaining the reasoning?  Feel free to copy what I wrote above to give something like "Loop only until num_draws - 4 to leave the last pair of autocorrelations
for bias term that reduces variance in the  case of antithetical chains."  Once that's in and tests pass I'll merge!

Sorry -- there are some residual conflicts with develop that are blocking the merge.  Can you merge develop into your fork'd branch and clear anything up?  Thanks!

source: gharchive/pull-request

authors: betanalpha roualdes

license_type: permissive

license_source: bigquery


text:
RFC: The Standard Schema spec

Hello all! I wrote up this proposal and would love to get some early feedback from my fellow validation library authors. 🤙
cc @sinclairzx81 @ssalbdivad @fabian-hiller @gcanti @jquense @ianstormtaylor @davidmdm (tag anyone I forgot!)

Thank you Colin for this contribution to the community! I am currently very busy rewriting Valibot. As soon as I find some time, I will give you feedback on everything. For example, I don't think the current definition of path is sufficient. For records and maps it is necessary to know if a path element points to the key or the value. That's why Valibot uses an object with additional info for each path item.
interface PathItem {
  schema: string;
  origin: 'key' | 'value'; // <--
  input: unknown;
  key: string | number | symbol | undefined;
  value: unknown;
}

@decs this might be of interest to you.

Thanks for kickstarting this effort, Colin! We're on the same page that this is something worth solving.
One challenge we had on typeschema was that many validation libraries have schemas without a validate function (i.e. schema.parse(...) doesn't exist). On Valibot, for example, it has to be parse(schema, ...). We solved it by wrapping that logic into another function. A possible solution could be to ask library maintainers who took that route to provide a similar wrapping function that outputs a StandardSchema.
It's also worth considering how async validation should be handled. Should ~validate allow returning a Promise?
Have you considered how StandardSchema can evolve over time? Validation is the base case, but some form libraries also rely on introspection (decs/typeschema#9). So I expect that would be the next feature request.
I ended up writing a very similar spec for interfacing with tRPC. I'm open to replacing that with StandardSchema (once we reach a more stable spec) to help on this migration period. That way, typeschema's wrap(schema) can be an alternative for validation libraries that haven't implemented StandardSchema yet.
Looking forward to making this a reality!

@fabian-hiller A standard like this needs to require only the most essential parts of the API that any validation library would almost have to implement in some form by definition.
There is certainly room to take things further e.g. in terms of error context or introspection as mentioned by @decs, but if they are to be added to the spec, they should be optional so library consumers can appropriately handle those methods/properties being unimplemented.
Potentially, the spec could also provide a type with those enhancements required, and consumers requiring capabilities like introspection could accept a type like IntrospectableSchema from standard-schema which would extend the minimal validation API.

For example, I don't think the current definition of path is sufficient. For objects, records and maps it is necessary to know if a path item points to the key or the value.

Good point. Zod just adds a literal "key" or "value" to the path for ZodMap errors but I certainly see the limits of that. That said, I think a special origin key that only applies to a small subset of schema types isn't ideal. As David says, I think this case may not merit special treatment. You can always clarify the nature of the issue in the message.

@decs this might be of interest to you and typeschema.

Ah of course! Hi @decs!

One challenge we had on typeschema was that many validation libraries have schemas without a validate function (i.e. schema.parse(...) doesn't exist). On Valibot, for example, it has to be parse(schema, ...)

Hm interesting. In the case of valibot this doesn't seem to be a problem. Schemas already have an internal _parse method as in Zod. Plus parsing logic is self-contained within each schema type, so I don't think there are treeshakingn considerations. Obviously @fabian-hiller should chime in if I'm wrong about this.

It's also worth considering how async validation should be handled

Great question. My first thought is that ~validate() should probably return T | Promise<T>. The validation library determines which one it'll be conditional on whether the schema contains any async validation logic, and the consuming library (tRPC, etc) just has to handle both cases. If the consuming library requires a synchronous validator, they can throw an informative runtime error should the schema return a Promise.

Validation is the base case, but some form libraries also rely on introspection

We certainly don't want to design a new serializable schema specification. That way lies madness. I think it would be a huge win if all libraries implemented a standard method for JSON Schema serialization.
interface StandardSchema {
  toJsonSchema(): JsonSchema;
}

But that's a big lift for library authors. There are a lot of implementation-specific nuances w.r.t how to do the conversion, e.g. should an email field be represented with format:email, format:idn-email, or a custom regex? See the Options section for zod-to-json-schema for a sense of the complexity there.
We would also hit against the "no method" problem here. I imagine most schema authors would be resistant to encapsulating toJsonSchema logic inside their schema types for tree shaking reasons.

There is certainly room to take things further e.g. in terms of error context or introspection as mentioned by @decs, but if they are to be added to the spec, they should be optional so library consumers can appropriately handle those methods/properties being unimplemented.
Potentially, the spec could also provide a type with those enhancements required, and consumers requiring capabilities like introspection could accept a type like IntrospectableSchema from standard-schema which would extend the minimal validation API.

+1 to all of this

That said, I think a special origin key that only applies to a small subset of schema types isn't ideal. As David says, I think this case may not merit special treatment. You can always clarify the nature of the issue in the message.

I agree that this probably only applies to a small subset of schemas. Therefore, I understand making a tradeoff here. However, for multiple nested maps or other similar structures, you need to know the origin of each path item to be able to navigate through the datastructure. I just question whether a standard should be limited and in some cases misleading in this regard.

Hm interesting. In the case of valibot this doesn't seem to be a problem. Schemas already have an internal _parse method as in Zod.

I think there might be some problems when Valibots internal _parse (or in the future _run) method needs to apply to '~validate': (data: unknown) => T | ValidationError; because Valibot also needs to track if a value is typed. That's why Valibots use a return type similar to this { typed: boolean; value: Value | unknown; issues?: [Issue, ...Issue[]] }. Adding an additional method just to apply to to spec could be a problem in terms of bundle size.
But as @decs mentioned, a solution for Valibot might be to provide an official adpater that applies to this spec.

That way lies madness

You called? 😄

source: gharchive/issue

authors: StefanTerdell colinhacks decs fabian-hiller ssalbdivad

repo: standard-schema/standard-schema

license: MIT

license_source: github-api


text:
Question Regarding 'Elaborated Box' in Web Service

Hello, Thank you for your valuable work.
I noticed a feature that I can type in extra information to elaborate the purpose of the topic, but I couldn't find the source code for this feature in the repository. And does the text in this box have an impact on article writing?😇

Hi, thanks for your interest in our work.
No, the writing purpose does not affect the writing output. It just serves as user input sanity check and future research purposes.

Ok, Thanks for your quick reply.

repo: stanford-oval/storm


text:
Fix describe of remote programs

Tests included

Pull Request Test Coverage Report for Build 789

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at ?%

Totals

Change from base Build 787:
0.0%

Covered Lines:

Relevant Lines:
0

💛  - Coveralls

authors: coveralls gcampax

repo: stanford-oval/thingtalk


text:
Trust anchor for certificate path not found.

Description
Exception while trying to watch a show.
Reproduction steps
Select SFlix as provider.
Select video to watch
Select "Watch Now"
A toast notification pops up:
java.security.cert.CertPathValidatorException: Trust anchor for certification path not found.
App version
Latest
Operating system
Google TV 12
Logs
java.security.cert.CertPathValidatorException: Trust anchor for certification path not found.

Please confirm the following

[X] I have searched the existing issues and this is a new ticket, NOT a duplicate or related to another open issue.
[X] If related to a provider, I have checked the site and it works, but not the app.

Should be fixed on Release 1.6.12

authors: stantanasi wiredroid

repo: stantanasi/streamflix


text:
Allow user to set annotations and loadBalancerIP property of service

No issue for this change.
In order to set a DNS label on the load balancer in the azure environment I need to be able to set service annotations
To support a public IP address for the load balancer in the Azure environment I need to be able to set the loadBalancerIP property.

Example stanza for values file:
service:
  annotations:
    # sets dns label for the load balancer. Azure will then automatically append a default subnet,
    # such as <location>.cloudapp.azure.com (where location is the region you selected), to the
    # name you provide, to create the fully qualified DNS name.
    service.beta.kubernetes.io/azure-dns-label-name: mydnslabel
  loadBalancerIP: xxx.xxx.xxx.xxx

Resolves https://github.com/stardog-union/helm-charts/issues/46

Looks good to me. Can you create an issue for the release notes? It can be as simple as the PR title, just so I can track what was updated. Thanks!

Done!

repo: stardog-union/helm-charts


text:
总感觉卡顿

第一次打开的时候花了比较长的时间，其次在每次打开的时候都会比较慢，然后在页面点击封面或者切歌的时候都会卡一下，希望可以优化

什么系统呢？

什么系统呢？

mac系统 版本15.1.1

可以录个视频看看吗？我这边的intel Mac 15.1系统，程序打开的时间和其他音乐软件差不多，你说的卡顿现象也没有哦。

这个录了视频
Filmage 2024-12-14_202217.mp4
https://drive.google.com/file/d/1A-vuZg_QO_JsEZCN5YT35pLBXDQdS_Rd/view?usp=drive_web
stark81 @.***> 于2024年11月29日周五 17:58写道：

可以录个视频看看吗？我这边的intel Mac 15.1系统，程序打开的时间和其他音乐软件差不多，你说的卡顿现象也没有哦。
—
Reply to this email directly, view it on GitHub
https://github.com/stark81/VutronMusic/issues/47#issuecomment-2507464240,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/BNGWW3BFX76CD354A3Y23432DA3ELAVCNFSM6AAAAABSN5YCZ6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKMBXGQ3DIMRUGA
.
You are receiving this because you authored the thread.Message ID:
@.***>

挺奇怪的。。是什么处理呢？我自己intel芯片的macos15、windows和ubuntu24都不会出现打开卡这么久的？重装一下看看？

我的是m3芯片  我重装试试

我的是m3芯片 我重装试试

那应该没用。。我这里打包出来的是intel芯片的版本，你那个安装时系统会转换成m芯片，效率是会变低的，可以自己下载代码，自己打包一下m芯片版本的哦。具体可以参考这里：
编译环境相关参数 #31

重新打包了 比之前快很多，其实我都不会跟着chatgpt一步一步来的    你需要这个包吗？我可以通过邮件发给你

重新打包了 比之前快很多，其实我都不会跟着chatgpt一步一步来的 你需要这个包吗？我可以通过邮件发给你

谢谢，但暂时不需要哈，因为你打包的版本和我已经上传版本的代码对不上，功能有差异，体验不一致哈。


text:
Domain gift page

Figma : https://www.figma.com/design/S1UKYgWewNqNHZFAaBUilG/🏝-Starknet-ID?node-id=3277%3A21682&t=dLTJNxOuLo2AclvY-1
This design is inspired by our last Quantum Leap campaign. We've reused the Quantum Leap template and adapted it for this one.
If you want to see what i mean : https://www.figma.com/design/S1UKYgWewNqNHZFAaBUilG/🏝-Starknet-ID?node-id=2474%3A41261&t=dLTJNxOuLo2AclvY-1

the contract to connecit it to https://github.com/starknet-id/domain_gift_contract

authors: Kevils fricoben


text:
feat: remove deprecated http server from gateway + add some tracing

Stack:

#829 ⬅
#828
#827
#806
#804
#810

⚠ Part of a stack created by spr. Do not merge manually using the UI - doing so may have unexpected results.

This change is

Closing pull request: commit has gone away

repo: starkware-libs/sequencer


text:
Revert "Allow the user to restrict the rows to extract"

Reverts starlake-ai/starlake#782

@tiboun could you explain a little bit more =>
The internal boundaries does apply filter in order to compute them. The output is the same but may implies more executed query

Understood. Just made the correction

repo: starlake-ai/starlake


text:
Bug: SessionCookieConfig import DeprecationWarning - suggested import path does not exist

Describe the bug
In Starlite >= 1.47, the statement from starlite.middleware.session.cookie_backend import CookieBackendConfig raises a DeprecationWarning:
DeprecationWarning: Import of deprecated import 'SessionCookieConfig from starlite.middleware.session'.
Deprecated in starlite 1.47.0. This import will be removed in the next major version.
Use "'from startlite.middleware.sessions.cookie_backend import CookieBackendConfig'" instead

The suggested import path does not exist and contains a typo.

Quick searches against the codebase show this also has that typo
https://github.com/starlite-api/starlite/blob/abc0ff41ac917afd8d8af718949de2ea935ca44c/starlite/app.py#L466

Quick searches against the codebase show this also has that startlite typo
https://github.com/starlite-api/starlite/blob/abc0ff41ac917afd8d8af718949de2ea935ca44c/starlite/app.py#L466

This one looks like it only exists on the 2.x branch - there was another one in 1.x though - an easy typo to make!

repo: starlite-api/starlite


text:
docs: rename operationId to operation_id to avoid ambiguity

PR Checklist

[X] Have you followed the guidelines in CONTRIBUTING.rst?
[X] Have you got 100% test coverage on new code?
[X] Have you updated the prose documentation?
[X] Have you updated the reference documentation?

@all-contributors add @ReznikovRoman docs

authors: Goldziher ReznikovRoman


text:
TORCH_CUDA_ARCH_LIST support

Can we support arch list specification with this env as documented in
https://pytorch.org/docs/stable/cpp_extension.html ?

E.g. https://github.com/facebookresearch/xformers/blob/main/setup.py#L271-L296

repo: state-spaces/mamba


text:
Remove mySelectedAddress on ChainWatcher

Sometimes when I load the Web3Torrent app I saw that I would go through the "EnableEthereumWorkflow" again, despite window.ethereum.selectedAddress being defined. I manually attempted to load https://xstate-wallet.statechannels.org and, really quickly, inspect window.ethereum.selectedAddress which sometimes was undefined if I called it fast enough. I suspect what is happening is that there is a race condition between the initialization of ChainWatcher and MetaMask injecting window.ethereum into the app. This change should fix it.

@geoknee yeah good point. I changed this PR to use a different approach. Can you re-check?

repo: statechannels/monorepo


text:
https://github.com/sosy-lab/sv-benchmarks/blob/master/c/loops/ludcmp_false-unreach-call.i

Symbiotic says TRUE.
Without optimizations, it says FALSE
without slicing it says FALSE also

It is some optimization from 'before', if this is just 'after' optimization, it is FALSE

with 'before' optimizations, there's not the assert called at all, but slicer say that it found it...

this was fixed

repo: staticafi/symbiotic

license: mit


text:
Sync doc files, index.md, and mkdocs.yml entries

More details are described here: https://www.notion.so/Sync-doc-files-index-md-and-mkdocs-yml-entries-d457aaa5013a493f8a7a29d47a3604b7

Merged into develop and master.


text:
Refactor and update existing extended base BLAS packages according to current project conventions

This should follow the same process as outlined in https://github.com/stdlib-js/stdlib/issues/788 but for @stdlib/blas/ext/base/*.
Packages needing updating:

[ ] @stdlib/blas/ext/base/dapx
[ ] @stdlib/blas/ext/base/dapxsum
[ ] @stdlib/blas/ext/base/dapxsumkbn
[ ] @stdlib/blas/ext/base/dapxsumkbn2
[ ] @stdlib/blas/ext/base/dapxsumors
[ ] @stdlib/blas/ext/base/dapxsumpw
[ ] @stdlib/blas/ext/base/dasumpw
[ ] @stdlib/blas/ext/base/dcusum
[ ] @stdlib/blas/ext/base/dcusumkbn
[ ] @stdlib/blas/ext/base/dcusumkbn2
[ ] @stdlib/blas/ext/base/dcusumors
[ ] @stdlib/blas/ext/base/dcusumpw
[x] @stdlib/blas/ext/base/dfill
[ ] @stdlib/blas/ext/base/dnanasum
[ ] @stdlib/blas/ext/base/dnanasumors
[ ] @stdlib/blas/ext/base/dnannsum
[ ] @stdlib/blas/ext/base/dnannsumkbn
[ ] @stdlib/blas/ext/base/dnannsumkbn2
[ ] @stdlib/blas/ext/base/dnannsumors
[ ] @stdlib/blas/ext/base/dnannsumpw
[ ] @stdlib/blas/ext/base/dnansum
[ ] @stdlib/blas/ext/base/dnansumkbn
[ ] @stdlib/blas/ext/base/dnansumkbn2
[ ] @stdlib/blas/ext/base/dnansumors
[ ] @stdlib/blas/ext/base/dnansumpw
[ ] @stdlib/blas/ext/base/drev
[ ] @stdlib/blas/ext/base/dsapxsum
[ ] @stdlib/blas/ext/base/dsapxsumpw
[ ] @stdlib/blas/ext/base/dsnannsumors
[ ] @stdlib/blas/ext/base/dsnansum
[ ] @stdlib/blas/ext/base/dsnansumors
[ ] @stdlib/blas/ext/base/dsnansumpw
[ ] @stdlib/blas/ext/base/dsort2hp
[ ] @stdlib/blas/ext/base/dsort2ins
[ ] @stdlib/blas/ext/base/dsort2sh
[ ] @stdlib/blas/ext/base/dsorthp
[ ] @stdlib/blas/ext/base/dsortins
[ ] @stdlib/blas/ext/base/dsortsh
[ ] @stdlib/blas/ext/base/dssum
[ ] @stdlib/blas/ext/base/dssumors
[ ] @stdlib/blas/ext/base/dssumpw
[ ] @stdlib/blas/ext/base/dsum
[ ] @stdlib/blas/ext/base/dsumkbn
[ ] @stdlib/blas/ext/base/dsumkbn2
[ ] @stdlib/blas/ext/base/dsumors
[ ] @stdlib/blas/ext/base/dsumpw
[ ] @stdlib/blas/ext/base/sapx
[ ] @stdlib/blas/ext/base/sapxsum
[ ] @stdlib/blas/ext/base/sapxsumkbn
[ ] @stdlib/blas/ext/base/sapxsumkbn2
[ ] @stdlib/blas/ext/base/sapxsumors
[ ] @stdlib/blas/ext/base/sapxsumpw
[ ] @stdlib/blas/ext/base/sasumpw
[ ] @stdlib/blas/ext/base/scusum
[ ] @stdlib/blas/ext/base/scusumkbn
[ ] @stdlib/blas/ext/base/scusumkbn2
[ ] @stdlib/blas/ext/base/scusumors
[ ] @stdlib/blas/ext/base/scusumpw
[ ] @stdlib/blas/ext/base/sdsapxsum
[ ] @stdlib/blas/ext/base/sdsapxsumpw
[ ] @stdlib/blas/ext/base/sdsnansum
[ ] @stdlib/blas/ext/base/sdsnansumpw
[ ] @stdlib/blas/ext/base/sdssum
[ ] @stdlib/blas/ext/base/sdssumpw
[ ] @stdlib/blas/ext/base/sfill
[ ] @stdlib/blas/ext/base/snansum
[ ] @stdlib/blas/ext/base/snansumkbn
[ ] @stdlib/blas/ext/base/snansumkbn2
[ ] @stdlib/blas/ext/base/snansumors
[ ] @stdlib/blas/ext/base/snansumpw
[x] @stdlib/blas/ext/base/srev
[ ] @stdlib/blas/ext/base/ssort2hp
[ ] @stdlib/blas/ext/base/ssort2ins
[ ] @stdlib/blas/ext/base/ssort2sh
[ ] @stdlib/blas/ext/base/ssorthp
[ ] @stdlib/blas/ext/base/ssortins
[ ] @stdlib/blas/ext/base/ssortsh
[ ] @stdlib/blas/ext/base/ssum
[ ] @stdlib/blas/ext/base/ssumkbn
[ ] @stdlib/blas/ext/base/ssumkbn2
[ ] @stdlib/blas/ext/base/ssumors
[x] @stdlib/blas/ext/base/ssumpw

@kgryte
Can I work on this issue?

@kailash360 Sure. How about you start with @stdlib/blas/ext/base/dapx.

working on @stdlib/blas/ext/base/dapx.

@kailash360 You mind find the various linked commits and PRs in the upstream issue to be good references. For example, https://github.com/stdlib-js/stdlib/commit/91a2badac012efea2c027c515a1c60da7a8797cf, which makes updates to a single-precision API.

...and https://github.com/stdlib-js/stdlib/commit/3c82fe7b6c0f9fd6ef02c86d6e2024d708ac8c14, which makes updates to a complex number API.

Hi @kgryte I have started work on @stdlib/blas/ext/base/sapx

@kailash360 Are you still planning to work on dapx? If so, can you respond on https://github.com/stdlib-js/stdlib/issues/1464?

Hi @kgryte, after working on a few good first issues, I now feel confident and will work on ``blas/ext/base/dsnannsumors`

Is this issue resolved completely? If not which packages are yet to be refactored

@gururaj1512 Double-checked and looks llke almost all are completed. @stdlib/blas/ext/base/snansumkbn2 is the only one that still has to be updated as far as I can tell.

authors: GittyHarsha Planeshifter gururaj1512 kailash360 kgryte rxbryan

repo: stdlib-js/stdlib


text:
Improve handling of at-runtime SteamAudioPlayer destruction

Deleting a SteamAudioPlayer at runtime (by e.g. running queue_free() on a script) may cause the game to crash. There must be improvements to locking on Server::tick() and on the reflection thread in order to reduce that. Something I had tried but didn't work was using std::unique_lock on the destructor and std::shared_lock on _mix, tick, and the reflection thread, which should make the destructor wait for all shared locks to be unlocked before proceeding to destruction... but that doesn't seem to be working.

Closing this after some testing because of #28, which seems to fix these crashes, along with:
https://github.com/stechyo/godot-steam-audio/blob/aa97bf0a51ca2088134c60cee6aa7e396e5df890/src/server.cpp#L226C1-L233C4

repo: stechyo/godot-steam-audio


text:
Fix: Help screen

General overview of the content of the help screen.
Verify that the all needed information is displayed, and that the information is correct.

It's done

It's done


text:
Reduce the number of IMDSv2 token calls

Each of these make a call to get a token from IMDSv2.
https://github.com/stefansundin/bottlerocket-bootstrap-associate-eip/blob/ffce43172716ee2c0efe0169c5865b67d77231da/src/main.rs#L21
https://github.com/stefansundin/bottlerocket-bootstrap-associate-eip/blob/ffce43172716ee2c0efe0169c5865b67d77231da/src/main.rs#L28-L36
https://github.com/stefansundin/bottlerocket-bootstrap-associate-eip/blob/ffce43172716ee2c0efe0169c5865b67d77231da/src/main.rs#L40
The same token can be used for all three purposes, so it would be great if there was a way to easily reuse the token.
In total 7 calls are made to IMDS and this can be reduced to 5 calls if the token can be reused.

Fixed by 6f2fc5fb46baddb68b50d08a67a0e2d28287f7c6.


text:
services/horizon: Use strings.Contains() instead of regex.Match() when populating HAL links.

PR Checklist
PR Structure

[ ] This PR has reasonably narrow scope (if not, break it down into smaller PRs).
[ ] This PR avoids mixing refactoring changes with feature changes (split into two PRs
otherwise).
[ ] This PR's title starts with name of package that is most changed in the PR, ex.
services/friendbot, or all or doc if the changes are broad or impact many
packages.

Thoroughness

[ ] This PR adds tests for the most critical parts of the new functionality or fixes.
[ ] I've updated any docs (developer docs, .md
files, etc... affected by this change). Take a look in the docs folder for a given service,
like this one.

Release planning

[ ] I've updated the relevant CHANGELOG (here for Horizon) if
needed with deprecations, added features, breaking changes, and DB schema changes.
[ ] I've decided if this PR requires a new major/minor version according to
semver, or if it's mainly a patch change. The PR is targeted at the next
release branch if it's not a patch change.

What
Improve the performance of HAL response construction using PopulateTemplated() without involving calling Go regexp package. This improves response performance.
This is an updated version of https://github.com/stellar/go/pull/1582

@oryband I cherry-pick your change from #1582 -- could you sign the CLA https://docs.google.com/forms/d/e/1FAIpQLSdoiChpRJ5vZnqRKK7WsHiUcaTO90hs7nuHIyOb5GDVsgvT8w/viewform  before we merge this? Thanks!

repo: stellar/go


text:
services/horizon: Create stellar/horizon deprecation image

This PR creates a deprecation image for stellar/horizon. Addresses part of #4669
The idea is to (as a one-time-thing) build it and push it to dockerhub.
It works as follows:
$ docker build -f services/horizon/docker/Dockerfile.deprecate-horizon -t stellar/horizon services/horizon/docker
[...]

$ docker run stellar/horizon
WARNING: The stellar/horizon Docker image is outdated deprecated, please use stellar/stellar-horizon instead.
WARNING: The stellar/horizon image will be removed from DockerHub on March 27 2023.
[...]

@jacekn Could you build and push the image? Do you want to proceed in any other (more formal) way?

@2opremio I can do it, no problem

@2opremio image pushed, I also updated description in dockerhub


text:
Revisit pattern for defining if contractimpl is exported

Today we specify if a contractimpl is exported with the export_if attribute which accepts a feature. This requires the contract developer to proactively add a feature to their crate that is used to gate whether the contract impl is exported. If the attribute isn't provided it is assumed to always be exported.
I think we need to revisit this pattern. The pattern is simple to implement for us, and flexible for contract developers, but it has one undesirable quality for contract developers:
It is opt-in. Developers who don't set an export_if always export, which means that their crate is likely never importable by other contracts. Anyone importing their crate will possibly unknowingly re-export their exports, and there is little that the importer can do about it.
Ideally the solution we use for controlling whether the functions are exported is not opt-in, and by default the contractimpl macro sets a contract such that it is importable safely, but when built for itself is always exported.
Ideally the solution would involve automatically detecting if a crate is being built as a dependency or as the primary package.
It's unclear if there is a better solution than what we have now given constraints of rust/cargo, but I think it's worth us having a look to see.

I thought maybe we could use a cfg on crate_type as a way to conditionally compile in the exports so they are only exported for cdylib and not rlib, but that is currently not possible with cargo:

https://github.com/rust-lang/rust/issues/45182
https://github.com/rust-lang/rust/issues/20267.

Going to close this in favor of #409.

repo: stellar/rs-soroban-sdk


text:
[Merge] Merge develop into sdp-multitenant

What
[TODO: Short statement about what is changing.]
Why
[TODO: Why this change is being made. Include any context required to understand the why.]
Known limitations
[TODO or N/A]
Checklist
PR Structure

[ ] This PR has a reasonably narrow scope (if not, break it down into smaller PRs).
[ ] This PR title and description are clear enough for anyone to review it.
[ ] This PR does not mix refactoring changes with feature changes (split into two PRs otherwise).

Thoroughness

[ ] This PR adds tests for the new functionality or fixes.
[ ] This PR contains the link to the Jira ticket it addresses.

Configs and Secrets

[ ] No new CONFIG variables are required -OR- the new required ones were added to the helmchart's values.yaml file.
[ ] No new CONFIG variables are required -OR- the new required ones were added to the deployments (pr-preview, dev, demo, prd).
[ ] No new SECRETS variables are required -OR- the new required ones were mentioned in the helmchart's values.yaml file.
[ ] No new SECRETS variables are required -OR- the new required ones were added to the deployments (pr-preview secrets, dev secrets, demo secrets, prd secrets).

Release

[ ] This is not a breaking change.
[ ] This is ready for production.. If your PR is not ready for production, please consider opening additional complementary PRs using this one as the base. Only merge this into develop or main after it's ready for production!

Deployment

[ ] Does the deployment work after merging?

stellar-disbursement-platform-backend-preview is available here:SDP:      https://sdp-backend-pr190.previews.kube001.services.stellar-ops.com/healthAP:       https://sdp-ap-pr190.previews.kube001.services.stellar-ops.com/healthFrontend: https://sdp-backend-dashboard-pr190.previews.kube001.services.stellar-ops.com

stellar-disbursement-platform-backend-preview is available here:SDP:      https://sdp-backend-pr190.previews.kube001.services.stellar-ops.com/healthAP:       https://sdp-ap-pr190.previews.kube001.services.stellar-ops.com/healthFrontend: https://sdp-backend-dashboard-pr190.previews.kube001.services.stellar-ops.com

stellar-disbursement-platform-backend-preview is available here:SDP:      https://sdp-backend-pr190.previews.kube001.services.stellar-ops.com/healthAP:       https://sdp-ap-pr190.previews.kube001.services.stellar-ops.com/healthFrontend: https://sdp-backend-dashboard-pr190.previews.kube001.services.stellar-ops.com

authors: marwen-abid stellar-jenkins


text:
Update platform p21 versions

Updating more versions, following https://github.com/stellar/stellar-docs/pull/547

Preview is available here:http://developers-pr548.previews.kube001.services.stellar-ops.com

LGTM

authors: anupsdf mollykarcher stellar-jenkins

repo: stellar/stellar-docs


text:
Support 'random' and 'bottom' knowledge graph rank eval strategies

This follows [1] to add two new evaluation strategy for knowledge graphs, particularly focused on how ties are broken when ranking edges.
Recall that our knowledge graph ranking code compares the model's computed score for an edge like E = (s, r, t) (s = source, r = relationship type, t = target) against the scores of corruptions E' = (s, r, n) for all n in the graph and similarly for (n, r, t). The rank of E is the number of corrupted edge E' scores that are greater than E's (ignoring edges in the train, test or validation set for "filtered" mode).
If there's a tie where score of E = score of E' (for one or more E'), this is implicitly ranking E higher than all of those tied E'. [1] shows that this misleading, because an algorithm that gives the same score to every edge (true or corrupted) gets rank = 1 for every edge under this approach.
The paper describes 3 ranking strategies for breaking ties:

Top: the true edge is ranked before all tied corruptions (as described above)
Bottom: the true edge is ranked after all tied corruptions, dramatically penalising ties
Random: the true edge is given a rank somewhere between top and bottom randomly (which averages out across many ties)

The paper describes the "Random" one as fairest/best, and so we default to it.
Changing the strategy makes little difference for "simple" algorithms like ComplEx and DistMult, because ties are rare (in a probabilistic framing, there's a very small chance that two bilinear products of 3 "random" vectors ends up being equal). This is more useful for non-linear/neural-network-based models that use activations functions like RelU, since these make it easy to end up with many (or all) zeros in hidden layers, and thus more quantisation (and more ties) in scores. We may implement them in future.
[1]: Sun, Zhiqing, Shikhar Vashishth, Soumya Sanyal, Partha Talukdar, and Yiming Yang. “A Re-Evaluation of Knowledge Graph Completion Methods.” ArXiv:1911.03903 [Cs], November 10, 2019. http://arxiv.org/abs/1911.03903.
See: #1158

Oh, oops, I haven't pushed the unit test yet, so not quite ready for review.

Ok this is ready for review now; sorry for assigning you too early @kieranricardo.

repo: stellargraph/stellargraph


text:
Mode Changes Erratic

When I change from Comfort to Eco to Off,  it is very slow and erratic.  Often I have to leave the device then return to get the proper status.  Also when I go from Eco to Off, the stat changes mode to off then to Comfort.  Once this happens, I often find the stat no longer responds to mode changes.

Hi Paul,
Could you tell me what is the source of the mode change? From the device or from the SmartThings app?

I am only using the stelpro device driver  mode tile and not an automation. BTW I don't use this thermostat often in the summer but when I replaced my SmartThings to the 2.0 hub and the reduced latency improved the performance. I will test it more completely later. I think the issue was due to a weak signal and latency.
Paul

On Jul 10, 2017, at 1:42 PM, stelpro notifications@github.com wrote:
Hi Paul,
Could you tell me what is the source of the mode change? From the device or from the SmartThings app?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or mute the thread.

Please close this issue.  It was resolved once I replaced my SmartThings to the 2.0 hub and the reduced latency.

authors: paullsoucy stelpro

repo: stelpro/Ki-ZigBee-Thermostat


text:
std::array<char... not working for read_as_json

Code for context from #400
Result<void> RadioTask::ConfigTree::on_get(std::string_view path, io::OutDevice& os) {
    // static std::array<char, 128> b;  // couldn't actually get std::array to work!
    static char b[256];
    memset(b, 0, 256);
    if(glz::write_as_json(radio.cfg_, path, b)) {
        os.write(to_bytes(b, strlen(b)));
        return success();
    }
    return Error::BadArgument;
}

Compiler: arm-none-eabi-gcc-12.2
I tried b and b.data().
with b.data() the compiler error was about it not being an lvalue.

@CrustyAuklet
You can now pass b.data() to write_as_json (#406).
Here's the added unit test:
static std::array<char, 128> b{};
my_struct obj{};
expect(glz::write_as_json(obj, "/i", b.data()));
expect(std::string_view{b.data()} == "287");

Note that if you are calling write multiple times you still need to reset the buffer to zeros. You can just call b.fill(0).

authors: CrustyAuklet stephenberry

repo: stephenberry/glaze


text:
Add custom author provider

added 2 options to the config
the first one author_model will let users change the default author model
and the resources config will let them change or remove resources from the plugin.
the resources config is necessary when users want to use custom author and they need provide a custom author resource

this PR will close https://github.com/stephenjude/filament-blog/issues/15

repo: stephenjude/filament-blog


text:
get_python_api.py is unable to find pyzed installation folder

Preliminary Checks

[X] This issue is not a duplicate. Before opening a new issue, please search existing issues.
[X] This issue is not a question, feature request, or anything other than a bug report directly related to this project.

Description
Hi,
I was trying to install the ZED Python API following this instructions. When running the get_python_api.py script, I got the following error:
C:\Program Files (x86)\ZED SDK>python get_python_api.py
-> Downloading to 'C:\Program Files (x86)\ZED SDK'
Detected platform:
         win
         Python 3.10
         ZED SDK 3.7
-> Checking if https://download.stereolabs.com/zedsdk/3.7/win/py310 exists and is available
-> Found ! Downloading python package into C:\Program Files (x86)\ZED SDK\pyzed-3.7-cp310-cp310-win_amd64.whl
-> Installing necessary dependencies
Requirement already satisfied: numpy in c:\users\[name]\appdata\roaming\python\python310\site-packages (1.23.1)
Processing c:\program files (x86)\zed sdk\pyzed-3.7-cp310-cp310-win_amd64.whl
Collecting cython>=0.28
  Using cached Cython-0.29.32-py2.py3-none-any.whl (986 kB)
Collecting numpy>=1.13
  Using cached numpy-1.23.3-cp310-cp310-win_amd64.whl (14.6 MB)
Installing collected packages: numpy, cython, pyzed
Successfully installed cython-0.29.32 numpy-1.23.3 pyzed-3.7
Done
Installing OpenGL dependencies required to run the samples
-> Downloading PyOpenGL-3.1.6-cp310-cp310-win_amd64.whl
Processing c:\program files (x86)\zed sdk\pyopengl-3.1.6-cp310-cp310-win_amd64.whl
PyOpenGL is already installed with the same version as the provided wheel. Use --force-reinstall to force an installation of the wheel.
-> Downloading PyOpenGL_accelerate-3.1.6-cp310-cp310-win_amd64.whl
Processing c:\program files (x86)\zed sdk\pyopengl_accelerate-3.1.6-cp310-cp310-win_amd64.whl
PyOpenGL-accelerate is already installed with the same version as the provided wheel. Use --force-reinstall to force an installation of the wheel.
ERROR : not a directory
ERROR : Unable to find pyzed installation folder
['Name: pyzed', 'Version: 3.7', 'Summary: Use the ZED SDK with Python', 'Home-page: https://github.com/stereolabs/zed-python-api', 'Author: ', 'Author-email: developers@stereolabs.com', 'License: UNKNOWN', 'Location: c:\\program files\\python310\\lib\\site-packages', 'Requires: cython, numpy', 'Required-by: ']
Traceback (most recent call last):
  File "C:\Program Files (x86)\ZED SDK\get_python_api.py", line 357, in <module>
    shutil.copy(source_dir + file, pyzed_dir + file)
TypeError: unsupported operand type(s) for +: 'NoneType' and 'str'

Looking at the get_python_api.py script I noticed that it is unable to find the pyzed installation folder, stated in the get_pyzed_directory() function. The pyzed installation folder is here:
c:/program files/python310/lib/site-packages/pyzed
The problem is that, to find the pyzed installation folder, you just split the lines from the command pip show pyzed by space character in line 73 which causes the error. It will return a list which on my machine looks like this ['Location:', 'c:\program', 'files\python310\lib\site-packages'] and is of course incorrect when you expect the pyzed installation folder on list-index 1 (line 76).
You can fix it like this:
def get_pyzed_directory():
    try:
        call_list = [sys.executable, "-m", "pip", "show", "pyzed"]
        lines = subprocess.check_output(call_list).decode().splitlines()
        for line in lines:
            key_word = "Location:"
            if line.startswith(key_word):
                directory = line[len(key_word):].strip()
                if os.path.isdir(directory):
                    print("Pyzed directory is " + directory)
                    return directory + "/pyzed"
                else:
                    print("ERROR : not a directory")

        print("ERROR : Unable to find pyzed installation folder")
        print(lines)

    except Exception as e:
        print("ERROR : Unable to find pyzed installation folder.")
        return ""

Steps to Reproduce

Execute pip show pyzed
Have a location with a space character in it (like c:/program files/python310/lib/site-packages/pyzed)
See the error by executing get_python_api.py

Expected Result
C:\Program Files (x86)\ZED SDK>python get_python_api.py
-> Downloading to 'C:\Program Files (x86)\ZED SDK'
Detected platform:
         win
         Python 3.10
         ZED SDK 3.7
-> Checking if https://download.stereolabs.com/zedsdk/3.7/win/py310 exists and is available
-> Found ! Downloading python package into C:\Program Files (x86)\ZED SDK\pyzed-3.7-cp310-cp310-win_amd64.whl
-> Installing necessary dependencies
Requirement already satisfied: numpy in c:\users\[name]\appdata\roaming\python\python310\site-packages (1.23.1)
Processing c:\program files (x86)\zed sdk\pyzed-3.7-cp310-cp310-win_amd64.whl
Collecting cython>=0.28
  Using cached Cython-0.29.32-py2.py3-none-any.whl (986 kB)
Collecting numpy>=1.13
  Using cached numpy-1.23.3-cp310-cp310-win_amd64.whl (14.6 MB)
Installing collected packages: numpy, cython, pyzed
Successfully installed cython-0.29.32 numpy-1.23.3 pyzed-3.7
Done
Installing OpenGL dependencies required to run the samples
-> Downloading PyOpenGL-3.1.6-cp310-cp310-win_amd64.whl
Processing c:\program files (x86)\zed sdk\pyopengl-3.1.6-cp310-cp310-win_amd64.whl
PyOpenGL is already installed with the same version as the provided wheel. Use --force-reinstall to force an installation of the wheel.
-> Downloading PyOpenGL_accelerate-3.1.6-cp310-cp310-win_amd64.whl
Processing c:\program files (x86)\zed sdk\pyopengl_accelerate-3.1.6-cp310-cp310-win_amd64.whl
PyOpenGL-accelerate is already installed with the same version as the provided wheel. Use --force-reinstall to force an installation of the wheel.
Pyzed directory is c:\program files\python310\lib\site-packages
  To install it later or on a different environment run :
 python -m pip install --ignore-installed C:\Program Files (x86)\ZED SDK\pyzed-3.7-cp310-cp310-win_amd64.whl

Actual Result
C:\Program Files (x86)\ZED SDK>python get_python_api.py
-> Downloading to 'C:\Program Files (x86)\ZED SDK'
Detected platform:
         win
         Python 3.10
         ZED SDK 3.7
-> Checking if https://download.stereolabs.com/zedsdk/3.7/win/py310 exists and is available
-> Found ! Downloading python package into C:\Program Files (x86)\ZED SDK\pyzed-3.7-cp310-cp310-win_amd64.whl
-> Installing necessary dependencies
Requirement already satisfied: numpy in c:\users\[name]\appdata\roaming\python\python310\site-packages (1.23.1)
Processing c:\program files (x86)\zed sdk\pyzed-3.7-cp310-cp310-win_amd64.whl
Collecting cython>=0.28
  Using cached Cython-0.29.32-py2.py3-none-any.whl (986 kB)
Collecting numpy>=1.13
  Using cached numpy-1.23.3-cp310-cp310-win_amd64.whl (14.6 MB)
Installing collected packages: numpy, cython, pyzed
Successfully installed cython-0.29.32 numpy-1.23.3 pyzed-3.7
Done
Installing OpenGL dependencies required to run the samples
-> Downloading PyOpenGL-3.1.6-cp310-cp310-win_amd64.whl
Processing c:\program files (x86)\zed sdk\pyopengl-3.1.6-cp310-cp310-win_amd64.whl
PyOpenGL is already installed with the same version as the provided wheel. Use --force-reinstall to force an installation of the wheel.
-> Downloading PyOpenGL_accelerate-3.1.6-cp310-cp310-win_amd64.whl
Processing c:\program files (x86)\zed sdk\pyopengl_accelerate-3.1.6-cp310-cp310-win_amd64.whl
PyOpenGL-accelerate is already installed with the same version as the provided wheel. Use --force-reinstall to force an installation of the wheel.
ERROR : not a directory
ERROR : Unable to find pyzed installation folder
['Name: pyzed', 'Version: 3.7', 'Summary: Use the ZED SDK with Python', 'Home-page: https://github.com/stereolabs/zed-python-api', 'Author: ', 'Author-email: developers@stereolabs.com', 'License: UNKNOWN', 'Location: c:\\program files\\python310\\lib\\site-packages', 'Requires: cython, numpy', 'Required-by: ']
Traceback (most recent call last):
  File "C:\Program Files (x86)\ZED SDK\get_python_api.py", line 357, in <module>
    shutil.copy(source_dir + file, pyzed_dir + file)
TypeError: unsupported operand type(s) for +: 'NoneType' and 'str'

ZED Camera model
ZED2i
Environment
OS: Windows 10 Pro
CPU: AMD Ryzen 9
GPU: NVIDIA RTX 3090
ZED SDK version: v3.7.7

Anything else?
No response

Hi,
Thank you for the detailed report! You're right the current way was too brittle. We'll integrate your fix for the next release

authors: GER-Jani adujardin

repo: stereolabs/zed-python-api


text:
How do I run a file after building?

I am trying to compile and run a C++ file using overseer. I copied the example for building C++ from the README. Building is working fine but what I want to do is to compile and run the compiled file in a floating toggleterm window.
Any help would be highly appreciated.

Two approaches: you could either do compile && run using your shell in the same task. That would look like
cmd = string.format("g++ %s -o a.out && ./a.out", vim.fn.expand("%:p"))

This is the equivalent of running g++ <file>.cpp -o a.out && ./a.out in your terminal.
The other way to do this would be to separate the "run" and "compile" tasks. The "run" task would add a dependency to the "compile" task using the dependencies component. That might look something like this:
-- Note: this is untested so it may require some fiddling
{
  name = "g++ build and run",
  builder = function()
    -- Full path to current file (see :help expand())
    local file = vim.fn.expand("%:p")
    local outfile = vim.fn.expand("%:p:r") .. ".out"
    return {
      cmd = { outfile },
      components = {
        -- Note that since we're using the "raw task parameters" format for the dependency,
        -- we don't have to define a separate build task.
        { "dependencies", task_name = { { cmd = "g++", args = { file, "-o", outfile } } } },
        { "on_output_quickfix", open = true },
        "default"
        },
    }
  end,
  condition = {
    filetype = { "cpp" },
  },
}

Getting the following errors when using the above specified config
Error executing vim.schedule lua callback: ...cker/start/overseer.nvim/lua/overseer/component/init.lua:212: Component 'dependencies' requires param 'task_names'
stack traceback:
        [C]: in function 'error'
        ...cker/start/overseer.nvim/lua/overseer/component/init.lua:212: in function 'validate_params'
        ...cker/start/overseer.nvim/lua/overseer/component/init.lua:253: in function 'instantiate'
        ...cker/start/overseer.nvim/lua/overseer/component/init.lua:293: in function 'load'
        ...te/pack/packer/start/overseer.nvim/lua/overseer/task.lua:252: in function 'add_components'
        ...te/pack/packer/start/overseer.nvim/lua/overseer/task.lua:115: in function 'new_uninitialized'
        ...te/pack/packer/start/overseer.nvim/lua/overseer/task.lua:123: in function 'new'
        ...acker/start/overseer.nvim/lua/overseer/template/init.lua:252: in function 'build_task'
        ...acker/start/overseer.nvim/lua/overseer/template/init.lua:366: in function 'build'
        ...ack/packer/start/overseer.nvim/lua/overseer/commands.lua:290: in function 'handle_tmpl'
        ...ack/packer/start/overseer.nvim/lua/overseer/commands.lua:323: in function 'on_choice'
        .../packer/start/dressing.nvim/lua/dressing/select/init.lua:78: in function ''
        vim/_editor.lua: in function <vim/_editor.lua:0>

Changed the task_name to task_names and it is not giving any errors but still I'm unable to get the file to run at all. Also despite using the toggleterm strategy, I'm not still getting the output  in the Terminal.

Got the toggleterm working by using strategy = "toggleterm", but when the program tries to give me some output, it fails
[ERROR] Task /home/lavish/College/Projects/C++/factors dispatch on_output_quickfix.on_output_lines: ...rseer.nvim/lu
a/overseer/component/on_output_quickfix.lua:30: Invalid window id: 1009

Solved the issue by changing { "on_output_quickfix", open = true },  to { "on_output_quickfix", open = false },

Everything is working as expected but I am still having a small problem. After executing the task,  the output is successfully shown in the toggleterm window but after the execution completes, the toggleterm window remains opened but gets unfocused and displays [Process exited 0]. After focusing the window, I'm unable to close it using my usual toggleterm keybinds. The only way to close it is going into Insert mode and pressing enter.

This is because overseer doesn't have perfect integration with toggleterm. There are a few operations (like the open... actions) that operate directly on the underlying terminal buffers instead of using toggleterm windows. See the discussion on #159 for more details and a link to a potential workaround. I have some ideas for improving this, but no estimate for when I'll be able to get to it.


text:
Support client-sent event webhook (client_event messages)

It seems Slanger doesn't support client_events (https://pusher.com/docs/webhooks#client_events) - I could not find a call to webhook.post for client sent events, although I'm confused because #78 implies it works.
When I tested it, I found it doesn't actually work. I'd love to implement it myself, but I'm not familiar with Ruby and don't know where to start.

I'd guess it is the version of the client library you are using is not
compatible with slanger.
If it's JS you could grab the version from the examples directory
If you fix your issue a documentation improvement PR would be appreciated
On Thu, 28 Jan 2016 at 03:53, Joshua Chaitin-Pollak <
notifications@github.com> wrote:

It seems Slanger doesn't support client_events (
https://pusher.com/docs/webhooks#client_events) - I could not find a call
to webhook.post for client sent events, although I'm confused because #78
https://github.com/stevegraham/slanger/issues/78 implies it works.
When I tested it, I found it doesn't actually work. I'd love to implement
it myself, but I'm not familiar with Ruby and don't know where to start.
—
Reply to this email directly or view it on GitHub
https://github.com/stevegraham/slanger/issues/201.

I'm using the pusher official client side library. I'll take a look at the
examples, but it doesn't look to me like slanger makes webhook calls for
client side events, it just seems to forward them to other clients.
On Thu, Jan 28, 2016, 1:46 AM Mark Burns notifications@github.com wrote:

I'd guess it is the version of the client library you are using is not
compatible with slanger.
If it's JS you could grab the version from the examples directory
If you fix your issue a documentation improvement PR would be appreciated
On Thu, 28 Jan 2016 at 03:53, Joshua Chaitin-Pollak <
notifications@github.com> wrote:

It seems Slanger doesn't support client_events (
https://pusher.com/docs/webhooks#client_events) - I could not find a
call
to webhook.post for client sent events, although I'm confused because #78
https://github.com/stevegraham/slanger/issues/78 implies it works.
When I tested it, I found it doesn't actually work. I'd love to implement
it myself, but I'm not familiar with Ruby and don't know where to start.
—
Reply to this email directly or view it on GitHub
https://github.com/stevegraham/slanger/issues/201.

—
Reply to this email directly or view it on GitHub
https://github.com/stevegraham/slanger/issues/201#issuecomment-176014747
.

Right got you. No it doesn't do a webhook post after receiving a client event. If this is something pusher supports we'd accept a pull request. You may be able to figure it out by copying the pattern from elsewhere that we do that. If you get that far I can help you understand how to test it.
Otherwise this will only get into the elixir rewrite ETA unknown.
Closing because if this continues it can be as a separate pull request.

Ok, I'll take a look

To clarify, yes this is something pusher supports. It sends a message like this to the server via webhook:
{
  "time_ms": 1454039974515,
  "events": [
    {
      "name": "client_event",
      "channel": "private-channel1",
      "event": "client-eventName",
      "data": "jsonStringifiedData",
      "socket_id": "163304.877140"
    }
  ]
}

It seems like the right place to put this functionality would be here:
    # Send a client event to the EventMachine channel.
    # Only events to channels requiring authentication (private or presence)
    # are accepted. Public channels only get events from the API.
    def send_client_message(message)
      Slanger::Redis.publish(message['channel'], Oj.dump(message, mode: :compat)) if authenticated?
    end

    # Send an event received from Redis to the EventMachine channel
    # which will send it to subscribed clients.
    def dispatch(message, channel)
      push(Oj.dump(message, mode: :compat)) unless channel =~ /\Aslanger:/
    end

It seems like adding a line like this to dispatch() would solve this, but I could be way off. Again, I don't know ruby so I might be misunderstanding how this works:
    # Send an event received from Redis to the EventMachine channel
    # which will send it to subscribed clients.
    def dispatch(message, channel)
      push(Oj.dump(message, mode: :compat)) unless channel =~ /\Aslanger:/
      # assemble payload here
      Slanger::Webhook.post payload
    end

If you think I'm on the right track I'll try and assemble the payload object.

Exactly that's right. (Based on memory and reading this email on my phone)
Try and get it working locally then have a look at the tests for the other
webhooks. Remember to restart the slanger server in between edits.
Once you've seen it working on your webhook receiving server, it shouldn't
be much more work to get tests around it.
I'd normally advocate writing the tests first but without a familiarity
with ruby and particularly testing evented code, I'd say that's a bit too
much of a learning curve to expect a good first pull request.
See how you get on. I'd like to see a pull request next too, as email based
code review/tutoring is probably not the most efficient workflow :)
On Fri, 29 Jan 2016 at 04:03, Joshua Chaitin-Pollak <
notifications@github.com> wrote:

To clarify, yes this is something pusher supports. It sends a message like
this to the server via webhook:
{
"time_ms": 1454039974515,
"events": [
{
"name": "client_event",
"channel": "private-channel1",
"event": "client-eventName",
"data": "jsonStringifiedData",
"socket_id": "163304.877140"
}
]
}
It seems like the right place to put this functionality would be here:
# Send a client event to the EventMachine channel.
# Only events to channels requiring authentication (private or presence)
# are accepted. Public channels only get events from the API.
def send_client_message(message)
  Slanger::Redis.publish(message['channel'], Oj.dump(message, mode: :compat)) if authenticated?
end

# Send an event received from Redis to the EventMachine channel
# which will send it to subscribed clients.
def dispatch(message, channel)
  push(Oj.dump(message, mode: :compat)) unless channel =~ /\Aslanger:/
end

It seems like adding a line like this to dispatch() would solve this, but
I could be way off. Again, I don't know ruby so I might be misunderstanding
how this works:
# Send an event received from Redis to the EventMachine channel
# which will send it to subscribed clients.
def dispatch(message, channel)
  push(Oj.dump(message, mode: :compat)) unless channel =~ /\Aslanger:/
  # assemble payload here
  Slanger::Webhook.post payload
end

If you think I'm on the right track I'll try and assemble the payload
object.
—
Reply to this email directly or view it on GitHub
https://github.com/stevegraham/slanger/issues/201#issuecomment-176563556
.

I'm familiar with the general development process, just not Ruby. I'll take
a look at the tests and see if I can make new ones.
I'm just not sure how to actually run the code.
On Thu, Jan 28, 2016, 11:33 PM Mark Burns notifications@github.com wrote:

Exactly that's right. (Based on memory and reading this email on my phone)
Try and get it working locally then have a look at the tests for the other
webhooks. Remember to restart the slanger server in between edits.
Once you've seen it working on your webhook receiving server, it shouldn't
be much more work to get tests around it.
I'd normally advocate writing the tests first but without a familiarity
with ruby and particularly testing evented code, I'd say that's a bit too
much of a learning curve to expect a good first pull request.
See how you get on. I'd like to see a pull request next too, as email based
code review/tutoring is probably not the most efficient workflow :)
On Fri, 29 Jan 2016 at 04:03, Joshua Chaitin-Pollak <
notifications@github.com> wrote:

To clarify, yes this is something pusher supports. It sends a message
like
this to the server via webhook:
{
"time_ms": 1454039974515,
"events": [
{
"name": "client_event",
"channel": "private-channel1",
"event": "client-eventName",
"data": "jsonStringifiedData",
"socket_id": "163304.877140"
}
]
}
It seems like the right place to put this functionality would be here:
Send a client event to the EventMachine channel.
Only events to channels requiring authentication (private or presence)
are accepted. Public channels only get events from the API.
def send_client_message(message)
Slanger::Redis.publish(message['channel'], Oj.dump(message, mode:
:compat)) if authenticated?
end
Send an event received from Redis to the EventMachine channel
which will send it to subscribed clients.
def dispatch(message, channel)
push(Oj.dump(message, mode: :compat)) unless channel =~ /\Aslanger:/
end
It seems like adding a line like this to dispatch() would solve this, but
I could be way off. Again, I don't know ruby so I might be
misunderstanding
how this works:
Send an event received from Redis to the EventMachine channel
which will send it to subscribed clients.
def dispatch(message, channel)
push(Oj.dump(message, mode: :compat)) unless channel =~ /\Aslanger:/
assemble payload here
Slanger::Webhook.post payload
end
If you think I'm on the right track I'll try and assemble the payload
object.
—
Reply to this email directly or view it on GitHub
<
https://github.com/stevegraham/slanger/issues/201#issuecomment-176563556>
.

—
Reply to this email directly or view it on GitHub
https://github.com/stevegraham/slanger/issues/201#issuecomment-176569109
.

Not sure if by code you mean tests or the server itself.
It sounds like you know how to start the server.
bundle exec rspec
^ For tests, google for any further help with issues getting rspec to run
On Fri, 29 Jan 2016 at 04:39, Joshua Chaitin-Pollak <
notifications@github.com> wrote:

I'm familiar with the general development process, just not Ruby. I'll take
a look at the tests and see if I can make new ones.
I'm just not sure how to actually run the code.
On Thu, Jan 28, 2016, 11:33 PM Mark Burns notifications@github.com
wrote:

Exactly that's right. (Based on memory and reading this email on my
phone)
Try and get it working locally then have a look at the tests for the
other
webhooks. Remember to restart the slanger server in between edits.
Once you've seen it working on your webhook receiving server, it
shouldn't
be much more work to get tests around it.
I'd normally advocate writing the tests first but without a familiarity
with ruby and particularly testing evented code, I'd say that's a bit too
much of a learning curve to expect a good first pull request.
See how you get on. I'd like to see a pull request next too, as email
based
code review/tutoring is probably not the most efficient workflow :)
On Fri, 29 Jan 2016 at 04:03, Joshua Chaitin-Pollak <
notifications@github.com> wrote:

To clarify, yes this is something pusher supports. It sends a message
like
this to the server via webhook:
{
"time_ms": 1454039974515,
"events": [
{
"name": "client_event",
"channel": "private-channel1",
"event": "client-eventName",
"data": "jsonStringifiedData",
"socket_id": "163304.877140"
}
]
}
It seems like the right place to put this functionality would be here:
Send a client event to the EventMachine channel.
Only events to channels requiring authentication (private or

presence)

are accepted. Public channels only get events from the API.
def send_client_message(message)
Slanger::Redis.publish(message['channel'], Oj.dump(message, mode:
:compat)) if authenticated?
end
Send an event received from Redis to the EventMachine channel
which will send it to subscribed clients.
def dispatch(message, channel)
push(Oj.dump(message, mode: :compat)) unless channel =~ /\Aslanger:/
end
It seems like adding a line like this to dispatch() would solve this,
but
I could be way off. Again, I don't know ruby so I might be
misunderstanding
how this works:
Send an event received from Redis to the EventMachine channel
which will send it to subscribed clients.
def dispatch(message, channel)
push(Oj.dump(message, mode: :compat)) unless channel =~ /\Aslanger:/
assemble payload here
Slanger::Webhook.post payload
end
If you think I'm on the right track I'll try and assemble the payload
object.
—
Reply to this email directly or view it on GitHub
<
https://github.com/stevegraham/slanger/issues/201#issuecomment-176563556

.

—
Reply to this email directly or view it on GitHub
<
https://github.com/stevegraham/slanger/issues/201#issuecomment-176569109>
.

—
Reply to this email directly or view it on GitHub
https://github.com/stevegraham/slanger/issues/201#issuecomment-176570955
.

Thanks, I'll give it a shot
On Thu, Jan 28, 2016, 11:45 PM Mark Burns notifications@github.com wrote:

Not sure if by code you mean tests or the server itself.
It sounds like you know how to start the server.
bundle exec rspec
^ For tests, google for any further help with issues getting rspec to run
On Fri, 29 Jan 2016 at 04:39, Joshua Chaitin-Pollak <
notifications@github.com> wrote:

I'm familiar with the general development process, just not Ruby. I'll
take
a look at the tests and see if I can make new ones.
I'm just not sure how to actually run the code.
On Thu, Jan 28, 2016, 11:33 PM Mark Burns notifications@github.com
wrote:

Exactly that's right. (Based on memory and reading this email on my
phone)
Try and get it working locally then have a look at the tests for the
other
webhooks. Remember to restart the slanger server in between edits.
Once you've seen it working on your webhook receiving server, it
shouldn't
be much more work to get tests around it.
I'd normally advocate writing the tests first but without a familiarity
with ruby and particularly testing evented code, I'd say that's a bit
too
much of a learning curve to expect a good first pull request.
See how you get on. I'd like to see a pull request next too, as email
based
code review/tutoring is probably not the most efficient workflow :)
On Fri, 29 Jan 2016 at 04:03, Joshua Chaitin-Pollak <
notifications@github.com> wrote:

To clarify, yes this is something pusher supports. It sends a message
like
this to the server via webhook:
{
"time_ms": 1454039974515,
"events": [
{
"name": "client_event",
"channel": "private-channel1",
"event": "client-eventName",
"data": "jsonStringifiedData",
"socket_id": "163304.877140"
}
]
}
It seems like the right place to put this functionality would be
here:
Send a client event to the EventMachine channel.
Only events to channels requiring authentication (private or

presence)

are accepted. Public channels only get events from the API.
def send_client_message(message)
Slanger::Redis.publish(message['channel'], Oj.dump(message, mode:
:compat)) if authenticated?
end
Send an event received from Redis to the EventMachine channel
which will send it to subscribed clients.
def dispatch(message, channel)
push(Oj.dump(message, mode: :compat)) unless channel =~ /\Aslanger:/
end
It seems like adding a line like this to dispatch() would solve this,
but
I could be way off. Again, I don't know ruby so I might be
misunderstanding
how this works:
Send an event received from Redis to the EventMachine channel
which will send it to subscribed clients.
def dispatch(message, channel)
push(Oj.dump(message, mode: :compat)) unless channel =~ /\Aslanger:/
assemble payload here
Slanger::Webhook.post payload
end
If you think I'm on the right track I'll try and assemble the payload
object.
—
Reply to this email directly or view it on GitHub
<

https://github.com/stevegraham/slanger/issues/201#issuecomment-176563556

.

—
Reply to this email directly or view it on GitHub
<
https://github.com/stevegraham/slanger/issues/201#issuecomment-176569109

.

—
Reply to this email directly or view it on GitHub
<
https://github.com/stevegraham/slanger/issues/201#issuecomment-176570955>
.

—
Reply to this email directly or view it on GitHub
https://github.com/stevegraham/slanger/issues/201#issuecomment-176571472
.

authors: jbcpollak markburns

repo: stevegraham/slanger


text:
Create ListReview use case

Create LogOut according to the blueprint and the CA Lab code.
Also, check other lab codes if needed.

Finished ListReview use case.


text:
BUG: fix various bugs with influxdb monitoring scripts

slottifier now only selects hvs with matching storagetype and hosttype to calculate slots on
fix data string formatting for service_status_to_influx.py script

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

Comparison is base (26e82fc) 98.23% compared to head (b666769) 99.02%.

Additional details and impacted files
@@            Coverage Diff             @@
##           master     #130      +/-   ##
==========================================
+ Coverage   98.23%   99.02%   +0.78%
==========================================
  Files          60       10      -50
  Lines        2552      716    -1836
==========================================
- Hits         2507      709    -1798
+ Misses         45        7      -38

Flag
Coverage Δ

rabbit_consumer
?

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

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

authors: anish-mudaraddi codecov-commenter

repo: stfc/SCD-OpenStack-Utils


text:
Add margin notes to articles

Margin notes are a type of footnote or commentary that appear inline or
in the margins of the text close to where they are defined, rather than
at the bottom as regular footnotes do. Margin notes are declared in
Markdown using the just-invented syntax:
[#] This is a margin note.
Two possible use cases:

lol, it actually was true: https://en.wikipedia.org/wiki/Buckethead

I'm wondering, will this replace footnotes?

I'm wondering, will this replace footnotes?

This is an implementation of what I was suggesting in the footnote discussion (#258).

IMO, this is much better than having footnotes.

Did you deploy after merging this?

nope

authors: cristeahub sigvef stianjensen


text:
Allow multiple clients within a same context

The configuration seems to be based on clients so you can only operate using the client you have set for a context:
contexts:
    test-password:
        issuer: http://localhost:8080/realms/test
        client: test-password
        flow: password
        user: test-user
        user-password: test-user-password

As a user, I would like to be able to define a single context where all the clients associated with a given issuer are defined so that I don't have multiple issuer entries pointing to the same URL. The main motivation for this is:

Make it easier to update a context so all users and clients associated with an issuer are grouped. For instance, if I want to change the URL for an issuer I don't need to go over multiple contexts.
Make it easier to read the configuration file when you have multiple issuers and multiple users and clients for each one
Setting context-level configuration settings that apply to all users and clients within a context easier

When executing commands within a context, I would also like to choose a client from the context rather than be forced to switch to a different context.
If the configuration is similar to this:
contexts:
    test:
        issuer: http://localhost:8080/realms/test
        client: client-a
        user: user-a
        users:
            user-a:
                credentials:
                    password: mypassword
            user-b:
                credentials:
                    password: mypassword
        clients:
            flow: password
            client-a:
                 credentials:
                     secret: mysecret
            client-b:
                 credentials:
                     secret: mysecret

I can now run commands like(assuming test context is active):
# Use default client-a and user-a
kct token

# Use a different client
kct token --client client-b

# Use a different user
kct token --user user-b

For testing purposes, I'm also wondering if it makes sense to expose options to override/set the following options when using the token command:

flow (perhaps it should be grant-type because flow in Keycloak is another thing and grant type is easy to map to the specs)
user
user-password

Otherwise, I'm forced to update the context configuration whenever I want to test a new one. Or perhaps #8 is enough to make it easier to set/update a context with additional configuration.
I hope it makes sense.

Ability to re-use issuer-url, client config, and user credentials makes sense, but don't think it'll work in the way you've proposed.
I don't really want to have a ton of config options to the commands, and would rather want just --context. In addition a context is used to associate stored tokens. If you try the latest release you can even do things like get the initial refresh token with a broad scope, then request tokens from that with a smaller scope. With that one thing I'd like to try to achieve is the ability to have a SSO scenario. Where you have one refresh token that is used for multiple purposes, but then each different purpose can get a subset of the scopes.
Need to think about this a little bit, but I could imagine something like:
issuers:
   local-test: http://localhost:8080/realms/test
   remote-test: http://remote/realms/test
users:
  admin:
     user: admin
     password: admin
clients:
 myclient:
    id: myclient
   secret: mysecret
contexts:
  main:
     issuer-ref: local-test
     user-ref: admin
     client-ref: myclient
     scope: foo, bar
  sub:
    context-ref: main
    scope: foo
  custom:
     issuer: http://localhost:8080/realms/something
     client: anotherclient
     flow: device

That allows you to do the straightforward just configure a context, or use re-usable stuff. It does complicate the CRUD commands for config a bit, but may be worth it.

Take two:
issuers:
  local-test:
    url: http://localhost:8080/realms/test
    clients:
      myclient:
        client-id:
        flow: device
    users:
      pedro:
        username: pedro
        password: test

contexts:
  main:
     issuer-ref: local-test
     user-ref: pedro
     client-ref: myclient

authors: pedroigor stianst

repo: stianst/keycloak-tokens-cli


text:
handle redirects to custom schemes

fixes issue #12

Thanks!

authors: nsolter sticksen

repo: sticksen/STKWebKitViewController


text:
literals in logic operators need support

this code:
posit<16,1> p(1);
...
if (p > 0) {
// do stuff when p is positive
} else {
// do stuff when p is negative
}
will require some syntactic love to enable.

Done

repo: stillwater-sc/universal