Bug: Poor performance for HypreBoomerAMG with Ordering::byNODES

Bug Report
If HypreBoomerAMG is used with Ordering::byNODES, then the number of PCG iterations needed for a simple elasticity problem is increased by a factor of 3-5. For comparison, I used the examples/ex2p.cpp example.
At least for this example, the performance degradation is only seen when using the HyperBoomerAMG::SetElasticityOptions function. However, this bug was originally noted in Serac, where the difference is present when using either the  HyperBoomerAMG::SetElasticityOptions or HyperBoomerAMG::SetSystemsOptions functions (see LLNL/serac#1175).
Ordering::byVDIM results
Run options:
mpirun -np 4 ex2p -m ../data/beam-hex.mesh -elast -vdim

The number of PCG iterations is 28 and the wall clock time is 0.193745 seconds. Full output is given below

Options used:
   --mesh mfem/data/beam-hex.mesh
   --order 1
   --amg-for-elasticity
   --no-static-condensation
   --visualization
   --by-vdim
   --device cpu
Device configuration: cpu
Memory configuration: host-std
Number of finite element unknowns: 15795
Assembling: r.h.s. ... matrix ... done.
Size of linear system: 15795

 Num MPI tasks = 4

 Num OpenMP threads = 1

BoomerAMG SETUP PARAMETERS:

 Max levels = 25
 Num levels = 7

 Strength Threshold = 0.500000
 Interpolation Truncation Factor = 0.000000
 Maximum Row Sum Threshold for Dependency Weakening = 0.900000

 Coarsening Type = HMIS
 measures are determined locally

 No global partition option chosen.

 Interpolation = extended+i interpolation

Operator Matrix Information:

             nonzero            entries/row          row sums
lev    rows  entries sparse   min  max     avg      min         max
======================================================================
  0   15795  1085625  0.004    24   81    68.7  -2.105e-14   1.875e+01
  1    7824  2486036  0.041    92  624   317.7  -6.756e+00   2.893e+01
  2    1890   680308  0.190    96  552   360.0  -9.728e+00   3.449e+01
  3     288    38096  0.459    58  201   132.3  -3.187e+01   6.649e+01
  4      30      900  1.000    30   30    30.0  -4.937e+01   1.008e+02
  5      12      144  1.000    12   12    12.0  -1.147e+01   1.031e+02
  6       6       36  1.000     6    6     6.0  -1.183e+01   1.035e+02

Interpolation Matrix Information:
                    entries/row        min        max            row sums
lev  rows x cols  min  max  avgW     weight      weight       min         max
================================================================================
  0 15795 x 7824    0   12  15.5  -7.156e-01   1.063e+00  -4.312e-01   1.250e+00
  1  7824 x 1890    0   12   7.7  -1.428e+00   2.424e+00  -4.327e-01   3.240e+00
  2  1890 x 288     0   12   7.5  -3.867e+00   4.431e+00  -4.979e-01   2.105e+00
  3   288 x 30      0   12   4.0  -9.830e-01   1.000e+00  -3.900e-01   2.370e+00
  4    30 x 12      0    6   2.2  -2.992e+00   1.646e+00  -1.976e+00   2.998e+00
  5    12 x 6       0    3   1.7  -3.551e+00   3.530e+00  -2.057e+00   3.770e+00

     Complexity:    grid = 1.636277
                operator = 3.952695
                memory = 4.130289

BoomerAMG SOLVER PARAMETERS:

  Maximum number of cycles:         1
  Stopping Tolerance:               0.000000e+00
  Cycle type (1 = V, 2 = W, etc.):  1

  Relaxation Parameters:
   Visiting Grid:                     down   up  coarse
            Number of sweeps:            1    1     1
   Type 0=Jac, 3=hGS, 6=hSGS, 9=GE:      8    8     8
   Point types, partial sweeps (1=C, -1=F):
                  Pre-CG relaxation (down):   0
                   Post-CG relaxation (up):   0
                             Coarsest grid:   0

=============================================
Setup phase times:
=============================================
PCG Setup:
  wall clock time = 0.110436 seconds
  wall MFLOPS     = 0.000000
  cpu clock time  = 0.109974 seconds
  cpu MFLOPS      = 0.000000

<C*b,b>: 4.770840e-04

Iters       ||r||_C     conv.rate  ||r||_C/||b||_C
-----    ------------    ---------  ------------
    1    3.928342e-02    1.798506    1.798506e+00
    2    3.010079e-02    0.766247    1.378099e+00
    3    1.479262e-02    0.491436    6.772481e-01
    4    6.511921e-03    0.440214    2.981341e-01
    5    2.755099e-03    0.423085    1.261362e-01
    6    2.396935e-03    0.870000    1.097385e-01
    7    1.987926e-03    0.829362    9.101288e-02
    8    1.033667e-03    0.519972    4.732417e-02
    9    6.627327e-04    0.641147    3.034177e-02
   10    3.736817e-04    0.563850    1.710820e-02
   11    2.503621e-04    0.669988    1.146229e-02
   12    1.727431e-04    0.689973    7.908669e-03
   13    2.117631e-04    1.225884    9.695112e-03
   14    1.144711e-04    0.540562    5.240811e-03
   15    4.477617e-05    0.391157    2.049980e-03
   16    3.050331e-05    0.681240    1.396528e-03
   17    1.775814e-05    0.582171    8.130179e-04
   18    1.806086e-05    1.017047    8.268771e-04
   19    7.589884e-06    0.420239    3.474863e-04
   20    3.800416e-06    0.500721    1.739938e-04
   21    1.302926e-06    0.342838    5.965161e-05
   22    4.135177e-07    0.317376    1.893201e-05
   23    1.205287e-07    0.291472    5.518146e-06
   24    4.649062e-08    0.385722    2.128472e-06
   25    1.367644e-08    0.294176    6.261460e-07
   26    2.758539e-09    0.201700    1.262937e-07
   27    6.849848e-10    0.248314    3.136054e-08
   28    1.030533e-10    0.150446    4.718072e-09

=============================================
Solve phase times:
=============================================
PCG Solve:
  wall clock time = 0.193745 seconds
  wall MFLOPS     = 0.000000
  cpu clock time  = 0.190707 seconds
  cpu MFLOPS      = 0.000000

PCG Iterations = 28
Final PCG Relative Residual Norm = 4.71807e-09

Ordering::byNODES results
Run options:
mpirun -np 4 ex2p -m ../data/beam-hex.mesh -elast -nodes

The number of PCG iterations is 162 and the wall clock time is 0.616807 seconds. Full output is given below

Options used:
   --mesh mfem/data/beam-hex.mesh
   --order 1
   --amg-for-elasticity
   --no-static-condensation
   --visualization
   --by-nodes
   --device cpu
Device configuration: cpu
Memory configuration: host-std
Number of finite element unknowns: 15795
Assembling: r.h.s. ... matrix ... done.
Size of linear system: 15795

 Num MPI tasks = 4

 Num OpenMP threads = 1

BoomerAMG SETUP PARAMETERS:

 Max levels = 25
 Num levels = 7

 Strength Threshold = 0.500000
 Interpolation Truncation Factor = 0.000000
 Maximum Row Sum Threshold for Dependency Weakening = 0.900000

 Coarsening Type = HMIS
 measures are determined locally

 No global partition option chosen.

 Interpolation = extended+i interpolation

Operator Matrix Information:

             nonzero            entries/row          row sums
lev    rows  entries sparse   min  max     avg      min         max
======================================================================
  0   15795  1085625  0.004    24   81    68.7  -2.105e-14   1.875e+01
  1    7656  1300680  0.022     1  588   169.9  -1.047e+02   5.043e+02
  2    1824   295154  0.089     1  390   161.8  -5.542e+29   2.940e+31
  3     312    23514  0.242    11  142    75.4  -4.945e+29   2.940e+31
  4      48      868  0.377     9   24    18.1  -1.176e+16   2.939e+31
  5      12      108  0.750     6   12     9.0  -1.176e+16   2.939e+31
  6       6       36  1.000     6    6     6.0  -1.176e+16   2.939e+31

Interpolation Matrix Information:
                    entries/row        min        max            row sums
lev  rows x cols  min  max  avgW     weight      weight       min         max
================================================================================
  0 15795 x 7656    0   15   4.6  -9.000e+00   7.500e+00  -1.187e+01   1.575e+01
  1  7656 x 1824    0   16   1.7  -1.293e+17   3.485e+17  -1.293e+17   3.485e+17
  2  1824 x 312     0   12   1.2  -2.627e+13   3.431e+15  -2.627e+13   3.431e+15
  3   312 x 48      0    7   1.0  -6.378e+00   9.215e+10  -6.000e+00   9.215e+10
  4    48 x 12      0    4   1.1  -7.375e+00   2.875e+00  -7.250e+00   2.000e+00
  5    12 x 6       0    1   0.2   2.417e-35   2.417e-35   0.000e+00   1.000e+00

     Complexity:    grid = 1.624122
                operator = 2.492560
                memory = 2.546757

BoomerAMG SOLVER PARAMETERS:

  Maximum number of cycles:         1
  Stopping Tolerance:               0.000000e+00
  Cycle type (1 = V, 2 = W, etc.):  1

  Relaxation Parameters:
   Visiting Grid:                     down   up  coarse
            Number of sweeps:            1    1     1
   Type 0=Jac, 3=hGS, 6=hSGS, 9=GE:      8    8     8
   Point types, partial sweeps (1=C, -1=F):
                  Pre-CG relaxation (down):   0
                   Post-CG relaxation (up):   0
                             Coarsest grid:   0

=============================================
Setup phase times:
=============================================
PCG Setup:
  wall clock time = 0.046780 seconds
  wall MFLOPS     = 0.000000
  cpu clock time  = 0.045841 seconds
  cpu MFLOPS      = 0.000000

<C*b,b>: 1.635386e-05

Iters       ||r||_C     conv.rate  ||r||_C/||b||_C
-----    ------------    ---------  ------------
    1    3.427763e-03    0.847619    8.476190e-01
    2    4.626211e-03    1.349630    1.143972e+00
    3    5.819511e-03    1.257943    1.439052e+00
    4    5.672679e-03    0.974769    1.402743e+00
    5    5.622712e-03    0.991192    1.390387e+00
    6    6.761773e-03    1.202582    1.672055e+00
    7    6.934473e-03    1.025541    1.714760e+00
    8    6.905494e-03    0.995821    1.707594e+00
    9    7.413967e-03    1.073633    1.833330e+00
   10    7.167698e-03    0.966783    1.772432e+00
   11    7.591442e-03    1.059119    1.877216e+00
   12    7.301626e-03    0.961823    1.805550e+00
   13    7.168101e-03    0.981713    1.772532e+00
   14    7.296312e-03    1.017886    1.804236e+00
   15    5.913727e-03    0.810509    1.462350e+00
   16    4.375678e-03    0.739919    1.082020e+00
   17    6.292031e-03    1.437956    1.555897e+00
   18    1.100648e-02    1.749273    2.721688e+00
   19    1.618628e-02    1.470613    4.002551e+00
   20    1.735969e-02    1.072494    4.292712e+00
   21    1.295650e-02    0.746356    3.203891e+00
   22    1.259144e-02    0.971824    3.113617e+00
   23    1.316006e-02    1.045160    3.254227e+00
   24    1.096962e-02    0.833554    2.712574e+00
   25    8.706963e-03    0.793734    2.153062e+00
   26    8.571999e-03    0.984499    2.119688e+00
   27    7.642967e-03    0.891620    1.889957e+00
   28    6.801277e-03    0.889874    1.681823e+00
   29    6.613880e-03    0.972447    1.635484e+00
   30    5.301978e-03    0.801644    1.311076e+00
   31    4.392970e-03    0.828553    1.086296e+00
   32    4.497335e-03    1.023757    1.112103e+00
   33    4.861421e-03    1.080956    1.202135e+00
   34    6.354051e-03    1.307036    1.571233e+00
   35    8.445002e-03    1.329074    2.088284e+00
   36    7.559789e-03    0.895179    1.869389e+00
   37    3.766719e-03    0.498257    9.314361e-01
   38    1.825633e-03    0.484675    4.514435e-01
   39    1.166833e-03    0.639139    2.885350e-01
   40    1.160023e-03    0.994164    2.868511e-01
   41    1.215876e-03    1.048148    3.006624e-01
   42    1.248594e-03    1.026909    3.087529e-01
   43    1.296311e-03    1.038216    3.205524e-01
   44    1.754694e-03    1.353606    4.339016e-01
   45    3.209816e-03    1.829274    7.937249e-01
   46    5.515813e-03    1.718420    1.363953e+00
   47    6.522968e-03    1.182594    1.613003e+00
   48    5.306013e-03    0.813435    1.312074e+00
   49    4.557954e-03    0.859017    1.127093e+00
   50    4.639401e-03    1.017869    1.147233e+00
   51    4.708707e-03    1.014939    1.164372e+00
   52    4.453323e-03    0.945763    1.101220e+00
   53    5.020622e-03    1.127388    1.241502e+00
   54    4.967291e-03    0.989378    1.228314e+00
   55    3.749726e-03    0.754883    9.272341e-01
   56    3.285491e-03    0.876195    8.124378e-01
   57    3.189066e-03    0.970651    7.885938e-01
   58    3.179360e-03    0.996957    7.861937e-01
   59    2.822002e-03    0.887601    6.978262e-01
   60    2.538912e-03    0.899685    6.278235e-01
   61    2.670893e-03    1.051984    6.604599e-01
   62    3.055873e-03    1.144139    7.556579e-01
   63    2.767548e-03    0.905649    6.843608e-01
   64    1.657906e-03    0.599052    4.099678e-01
   65    8.892601e-04    0.536376    2.198967e-01
   66    6.569345e-04    0.738743    1.624471e-01
   67    7.294546e-04    1.110392    1.803799e-01
   68    9.405830e-04    1.289433    2.325879e-01
   69    8.539592e-04    0.907904    2.111675e-01
   70    6.139685e-04    0.718967    1.518224e-01
   71    5.319762e-04    0.866455    1.315474e-01
   72    5.705848e-04    1.072576    1.410945e-01
   73    6.476844e-04    1.135124    1.601597e-01
   74    6.444918e-04    0.995071    1.593703e-01
   75    5.872131e-04    0.911126    1.452064e-01
   76    5.201482e-04    0.885791    1.286225e-01
   77    5.007679e-04    0.962741    1.238301e-01
   78    4.713052e-04    0.941165    1.165446e-01
   79    3.183220e-04    0.675405    7.871482e-02
   80    2.113566e-04    0.663971    5.226436e-02
   81    2.064717e-04    0.976888    5.105644e-02
   82    2.701979e-04    1.308644    6.681467e-02
   83    3.382492e-04    1.251857    8.364244e-02
   84    3.622039e-04    1.070820    8.956597e-02
   85    3.063490e-04    0.845792    7.575414e-02
   86    2.353704e-04    0.768308    5.820252e-02
   87    1.826247e-04    0.775903    4.515953e-02
   88    1.903772e-04    1.042450    4.707657e-02
   89    1.944019e-04    1.021141    4.807180e-02
   90    1.939195e-04    0.997518    4.795250e-02
   91    1.604543e-04    0.827428    3.967723e-02
   92    9.151549e-05    0.570352    2.263000e-02
   93    5.843188e-05    0.638492    1.444907e-02
   94    4.041724e-05    0.691698    9.994397e-03
   95    3.714297e-05    0.918988    9.184734e-03
   96    3.203927e-05    0.862593    7.922688e-03
   97    2.805461e-05    0.875632    6.937359e-03
   98    2.603854e-05    0.928137    6.438822e-03
   99    3.328793e-05    1.278410    8.231456e-03
  100    4.872824e-05    1.463841    1.204954e-02
  101    6.544331e-05    1.343026    1.618286e-02
  102    5.482430e-05    0.837737    1.355698e-02
  103    2.652137e-05    0.483752    6.558218e-03
  104    1.205323e-05    0.454472    2.980529e-03
  105    6.146482e-06    0.509945    1.519905e-03
  106    4.073934e-06    0.662807    1.007404e-03
  107    2.982548e-06    0.732105    7.375261e-04
  108    2.995564e-06    1.004364    7.407446e-04
  109    2.927599e-06    0.977312    7.239383e-04
  110    2.369314e-06    0.809303    5.858852e-04
  111    1.969558e-06    0.831278    4.870332e-04
  112    1.995850e-06    1.013349    4.935347e-04
  113    1.835586e-06    0.919701    4.539046e-04
  114    1.851376e-06    1.008602    4.578093e-04
  115    2.148967e-06    1.160740    5.313977e-04
  116    2.177935e-06    1.013480    5.385610e-04
  117    2.402639e-06    1.103173    5.941259e-04
  118    3.130981e-06    1.303143    7.742307e-04
  119    4.635370e-06    1.480485    1.146237e-03
  120    4.691439e-06    1.012096    1.160101e-03
  121    3.022072e-06    0.644167    7.472994e-04
  122    1.968967e-06    0.651529    4.868871e-04
  123    1.498696e-06    0.761158    3.705982e-04
  124    1.751585e-06    1.168740    4.331329e-04
  125    2.927771e-06    1.671498    7.239806e-04
  126    4.867678e-06    1.662589    1.203682e-03
  127    5.344851e-06    1.098029    1.321678e-03
  128    5.256341e-06    0.983440    1.299791e-03
  129    6.168965e-06    1.173623    1.525465e-03
  130    6.839685e-06    1.108725    1.691321e-03
  131    4.703117e-06    0.687622    1.162989e-03
  132    2.463254e-06    0.523749    6.091148e-04
  133    1.417473e-06    0.575447    3.505134e-04
  134    1.089488e-06    0.768613    2.694091e-04
  135    1.056142e-06    0.969394    2.611635e-04
  136    1.333225e-06    1.262353    3.296805e-04
  137    1.776750e-06    1.332671    4.393557e-04
  138    2.075086e-06    1.167911    5.131284e-04
  139    1.961597e-06    0.945309    4.850648e-04
  140    1.208893e-06    0.616280    2.989357e-04
  141    5.963222e-07    0.493280    1.474589e-04
  142    2.781944e-07    0.466517    6.879205e-05
  143    2.029210e-07    0.729421    5.017840e-05
  144    2.819280e-07    1.389349    6.971529e-05
  145    5.539044e-07    1.964702    1.369698e-04
  146    1.157805e-06    2.090262    2.863027e-04
  147    2.349269e-06    2.029071    5.809284e-04
  148    3.406379e-06    1.449974    8.423312e-04
  149    2.728815e-06    0.801090    6.747828e-04
  150    1.329768e-06    0.487306    3.288257e-04
  151    5.387322e-07    0.405133    1.332180e-04
  152    1.978795e-07    0.367306    4.893175e-05
  153    7.575288e-08    0.382823    1.873221e-05
  154    3.174400e-08    0.419047    7.849672e-06
  155    1.396222e-08    0.439838    3.452585e-06
  156    6.781540e-09    0.485706    1.676943e-06
  157    3.237426e-09    0.477388    8.005523e-07
  158    1.233442e-09    0.380995    3.050062e-07
  159    4.551153e-10    0.368980    1.125412e-07
  160    1.713708e-10    0.376544    4.237667e-08
  161    6.869889e-11    0.400879    1.698790e-08
  162    3.019790e-11    0.439569    7.467352e-09

=============================================
Solve phase times:
=============================================
PCG Solve:
  wall clock time = 0.616807 seconds
  wall MFLOPS     = 0.000000
  cpu clock time  = 0.607428 seconds
  cpu MFLOPS      = 0.000000

PCG Iterations = 162
Final PCG Relative Residual Norm = 7.46735e-09

Possible Causes
The most likely issue is that the permutation/DOF function defined in HyperBoomerAMG::SetSystemsOptions is wrong, leading to incorrectly built rigid-body mode vectors.
Alternatively, the permutation is correct, but is not propagated to coarsened meshes.

What happens without -elast?

If you use the -elast option, SetSystemsOptions is ignored.

I wonder if the elasticity solver (with option -elast) works only with Ordering::byVDIM and the changes in this PR need to be augmented: https://github.com/mfem/mfem/pull/3772/files

I was curious and tried comparing -nodes vs -vdim without -elast and it is about the same # of cg iterations.
mpirun -np 4 ./ex2p -m ../data/beam-hex.mesh -vdim

=============================================
Solve phase times:
=============================================
PCG Solve:
  wall clock time = 0.177536 seconds
  wall MFLOPS     = 0.000000
  cpu clock time  = 0.177494 seconds
  cpu MFLOPS      = 0.000000

PCG Iterations = 35
Final PCG Relative Residual Norm = 8.63456e-09

mpirun -np 4 ./ex2p -m ../data/beam-hex.mesh -nodes

=============================================
Solve phase times:
=============================================
PCG Solve:
  wall clock time = 0.152169 seconds
  wall MFLOPS     = 0.000000
  cpu clock time  = 0.152169 seconds
  cpu MFLOPS      = 0.000000

PCG Iterations = 36
Final PCG Relative Residual Norm = 1.79992e-09

Regarding the slack thread about seeing differences in performance between bynodes vs byvdim, both when called using SetSystemOptions, it seems like in this example -elast  also changes the fespace constructor. Maybe that is another thing to check?

Regarding the slack thread about seeing differences in performance between bynodes vs byvdim, both when called using SetSystemOptions, it seems like in this example -elast also changes the fespace constructor. Maybe that is another thing to check?

I think that it only changes the constructor if we are using a NURBS mesh (which the beam-hex.mesh mesh isn't. Am I missing something?

You're right, I could have worded that better. My point is: in this example, when the options are called using SetSystemOptions the performance is similar. If you are seeing differences in serac and also using SetSystemOptions, my hunch would be to look at the constructor (in this example, the constructor is also changed when using the nodes vs vdim flag).

I need to dig in the hypre code to provide more details, but I believe the -elast -nodes option is not really valid and probably shouldn't be allowed (that was the behavior before https://github.com/mfem/mfem/pull/3772/files).
The three options that make sense to me are:
1. System AMG with ordering by VDIM (default)
mpirun -np 4 ex2p -m ../data/beam-hex.mesh

or
mpirun -np 4 ex2p -m ../data/beam-hex.mesh -vdim

2. System AMG with ordering by NODES
mpirun -np 4 ex2p -m ../data/beam-hex.mesh -nodes

3. Elasticity-AMG solver, implying and only working for ordering by VDIM
mpirun -np 4 ex2p -m ../data/beam-hex.mesh -elast

I would expect options 1 and 2 to have similar performance and option 3 to be more expensive and setup and iteration time, but potentially requiring fewer iterations (depending on the problem).
Any comments or additional suggestions?
cc: @ulrikeyang, @liruipeng

Looking more carefully at the hypre sources

https://github.com/hypre-space/hypre/blob/master/src/parcsr_ls/par_sv_interp.c#L197
https://github.com/hypre-space/hypre/blob/master/src/parcsr_ls/par_sv_interp_ln.c#L27

and this comment in https://doi.org/10.1002/nla.688:

We refer to the combination of a node-based coarsening with an unknown-based interpolation as a ‘hybrid’ approach. The two new methods for extending AMG interpolation operators that wepresent in Sections 4 and 5 are based on this hybrid approach.

I think it is safe to assume that the "Elasticity" version of BoomerAMG (enabled in MFEM with SetElasticityOptions) does require a nodal ordering of the matrix, which in MFEM means Ordering::byVDIM.
I suggest that we revert https://github.com/mfem/mfem/pull/3772 except for this change and instead give a warning if the ordering of the provided space is not byVDIM.
We can also perform a similar check in Example 2p.
@zatkins-work, @samuelpmishLLNL and @jamiebramwell -- will the above change be acceptable for you?

@zatkins-work, @samuelpmishLLNL and @jamiebramwell -- will the above change be acceptable for you?

Sounds good to me.

I suggest that we ... give a warning if the ordering of the provided space is not byVDIM.

:+1:  for the warning, but let's also document this requirement in the Doxygen entry for that function.

I agree with @samuelpmishLLNL

Fix proposed in #4412, please take a look and comment there.


Check on all jobs pages for broken images

Description: You must check on all jobs pages for broken images.
Precondition: The website is up and running.

Step 1: Check on all jobs pages for broken images.

Expected result: All images from all jobs pages should be displayed.

Step 2: Check on all jobs pages for broken images on your mobile.

Expected result: All images from all jobs pages should be displayed on your mobile.


#1573 - Ability to assert page title

Proposed changes
Implemented feature, requested by https://github.com/selenide/selenide/issues/1573
Checklist

[X] Checkstyle and unit tests are passed locally with my changes by running gradlew check chrome_headless firefox_headless command
[X] I have added tests that prove my fix is effective or that my feature works
[X] I have added necessary documentation (if appropriate)

Perhaps then just leave the exact option without the possibility to check against partial match?

@ervuks yes, I like the exact match.


Create Product

When I install pip install -r requirements.txt  not install en red:
Collecting importlib-metadata>=0.18; python_version < "3.8" (from kombu==4.6.7->-r requirements.txt (line 210))
In --require-hashes mode, all requirements must have their versions pinned with ==. These do not:
importlib-metadata>=0.18; python_version < "3.8" from https://files.pythonhosted.org/packages/e9/71/1a1e0ed0981bb6a67bce55a210f168126b7ebd2065958673797ea66489ca/importlib_metadata-1.3.0-py2.py3-none-any.whl#sha256=d95141fbfa7ef2ec65cfd945e2af7e5a6ddbd7c8d9a25e66ff3be8e3daf9f60f (from kombu==4.6.7->-r requirements.txt (line 210))

same case with a different error, python 3.6.8, ubuntu 18.10
In --require-hashes mode, all requirements must have their versions pinned with ==. These do not:
importlib-metadata>=0.18; python_version < "3.8" from https://files.pythonhosted.org/packages/e9/71/1a1e0ed0981bb6a67bce55a210f168126b7ebd2065958673797ea66489ca/importlib_metadata-1.3.0-py2.py3-none-any.whl#sha256=d95141fbfa7ef2ec65cfd945e2af7e5a6ddbd7c8d9a25e66ff3be8e3daf9f60f (from kombu==4.6.7->-r requirements.txt (line 210))

Hello @Varghese-Thomas , I solved it by installing a virtual environment pyenv 3.80 and it worked my best regards

@joelunmsm2003 Hi Joel! First, run this command to create requirements file without hashes: poetry export --without-hashes -f requirements.txt -o requirements.txt.
And then run again pip-install command.

@joelunmsm2003 I'm happy to hear that you found a solution. If you have any more questions, let us know.
Best


Error when starting up, cork command does not exist

I am looking to migrate to cork from plug.kak, but I am experiencing an error when trying to use it:
Debug buffer:
/home/rai/.local/bin/cork: cork: line 7: syntax error near unexpected token `newline'
/home/rai/.local/bin/cork: cork: line 7: `<!DOCTYPE html>'

The cork command will not work either.
kakrc:
evaluate-commands %sh{
    kcr init kakoune
    cork init
    kak-lsp --kakoune -s $kak_session
}

Distro: Manjaro Gnome (but I'm using QTile now).

Oh, that explains it. The curl command on the readme downloads the actual webpage, not the source of the file.
It should be https://raw.githubusercontent.com/topisani/cork.kak/master/cork.sh.


Not work with WPGraphQL for Advanced Custom Fields

Hey, i looking for custom field and i am use this plugin, but it didn't save json field in GraphQL

Hey hey, also encountered this issue myself. Any progress made on having JSON fields come back in WPGraphQL?


add the new column and three rows of mockup properties

merge the new sql file

add the new column


How to remove sample from snake?

I have removed the samples in /var/db/snake, but somehow it still displays on the web interface.

How to delete the sample from snake properly?

Ah well this is a huge oversight in Snake Skin. I guess as we never delete samples through the UI we must have forgotten to add it! i'll try and add it in when I get a free moment.
What you can do in the interim is to delete the sample using the API:
curl http://localhost:5000/file/3ea002bead53f6bdf7fade8568285eb14146a7244f631570af55ee08ecef78f3 -XDELETE

Ah well this is a huge oversight in Snake Skin. I guess as we never delete samples through the UI we must have forgotten to add it! i'll try and add it in when I get a free moment.
What you can do in the interim is to delete the sample using the API:
curl http://localhost:5000/file/3ea002bead53f6bdf7fade8568285eb14146a7244f631570af55ee08ecef78f3 -XDELETE

Alright, thanks alex!

Alright, thanks alex!


Create labels for semver-{major,minor,patch}

The Node.js library repos should have semver-{major,minor,patch} labels so that it is easier to identify the semver impact of any given PR.

@GoogleCloudPlatform/yoshi  any thoughts on this one?  I'm generally in favor of adding these and using them, but I have a very nodejs centric view of the world :)

I'm -1. More labels is not better. We'll just forget to apply these unless we write a bot to enforce them.

-1, this would be moot in Go since we never "backport" any changes.

I'm also -1, as it's not clear what benefit it gives us for the cost of more labels and process. Are we trying to automate updating the version number based on this?
Note that different language communities do have different approaches to semver. The Ruby team, for example, tends to avoid semver-major changes like the plague, to avoid diamond dependency issues.

Python is similar, and no semver major changes in any language can occur
without my signoff.
As we get Node.js and Ruby moved over to the releasetool used by Python,
the release engineer will be prompted to pick the version change after
compiling a changelog. While having releasetool show these labels might be
helpful, ultimately it's up to the engineer to make the choice based on the
changes since the previous release. I'm happy to demonstrate this to anyone
who's curious, and me and @crwilcox are working to get this done within the
next few weeks (barring priority interrupts).
On Tue, Jun 12, 2018, 4:43 PM Daniel Azuma<EMAIL_ADDRESS>wrote:

I'm also -1, as it's not clear what benefit it gives us for the cost of
more labels and process. Are we trying to automate updating the version
number based on this?
Note that different language communities do have different approaches to
semver. The Ruby team, for example, tends to avoid semver-major changes
like the plague, to avoid diamond dependency issues.
—
You are receiving this because you are on a team that was mentioned.
Reply to this email directly, view it on GitHub
https://github.com/GoogleCloudPlatform/google-cloud-node/issues/2827#issuecomment-396768607,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAPUc77j1WAbPYdm1LI6MjYjp6bd4oBDks5t8FI9gaJpZM4UlS-d
.

I'm only asking for Node.js. I don't have opinions on whether other languages should have the labels.
To ensure accuracy, I would impose a simple requirement: No change can land unless it has a semver label.

and no semver major changes in any language can occur without my signoff.

Having these labels will get these changes onto your radar. I think these might be sneaking past you  at present 😃.

As we get Node.js and Ruby moved over to the releasetool used by Python

I would like the semver impact to be determined before the change lands – not at release time.

Note that different language communities do have different approaches to semver.

Yes language communities are different, and I think it makes sense to have semver labels in the Node.js repos if we are to match expectations of the community.

The Ruby team, for example, tends to avoid semver-major changes like the plague, to avoid diamond dependency issues.

Diamond dependency isn't a problem in the Node.js ecosystem.
In the Node.js community, semver is a means of communication of changes.  Semver major are expected and sometimes unavoidable (e.g. when a downstream package drops support for a Node.js major version.) in the Node.js ecosystem.


nodegit doesn't return control to the calling application

I have the following code
var cloneOptions = {};
cloneOptions.remoteCallbacks = {
    credentials: function(url, userName) {
        return NodeGit.Cred.sshKeyFromAgent(userName);
    }
};
logger.info('Cloning snapshot repo');
var getMostRecentCommit = function(repository) {
    return repository.getBranchCommit('master');
};

var getCommitMessage = function(commit) {
    return commit.message();
};
NodeGit.Clone(remoteRepo, path.join('_deployments',deployFolderName), cloneOptions )
    .then(getMostRecentCommit, function() { logger.error('error %o', arguments);})
    .then(getCommitMessage, function() { logger.error('error %o', arguments);})
    .then(function(message) {
        return logger.info(message);
    }, function() { logger.error('error %o', arguments);});

This is largely copypasta from your site.
The NodeGit.* chain is working fine; the repo is being cloned and I'm getting the right commit message.
However, my application then just sits and waits. There's no indication in the nodegit docs that I need to manually resolve the Promise or anything like in order for my application to complete.
What am I missing here? Or is this a nodegit bug?

How is it being used? Run that code in a single file and it'll exit just fine.  Is your application hanging, because it's a server or something?

How large is your repository? Have you set up any progress callbacks?

@johnhaley81 the repo isn't that large and it's progressing fine (I added the callback to confirm).
The commit message is being reported, so we're getting that far. It's just that the application isn't closing.

@tbranyen it's a CLI app and, when I remove the NodeGit chain, it completes without any problems.

@dancrumb can you confirm if you run that code standalone on the CLI it exits?

@dancrumb can you add a .done on the end of the chain?

I ran the script at https://gist.github.com/dancrumb/1b437d2d1da8b88ea62b and got the output:
$ node test.js
[DEBUG]: Remote stash repo: ssh://git@stash.vodori.com:2121/ps/pepper-demo-site.git
[DEBUG]: Cloning into _deployments/test
[INFO]: Cloning snapshot repo
[INFO]: v3.12.3

[INFO]: Donezo

where it just waits

@dancrumb unfortunately that test case uses a logging tool that could be causing a problem:
here is a reduced test case I used that worked perfectly:
var path    =  require('path');
var NodeGit = require('./nodegit');

// create tmp folder
var deployFolderName = 'test';

// clone into tmp folder
var remoteRepo = 'git@github.com:nodegit/test';
var cloneOptions = {};
cloneOptions.remoteCallbacks = {
    credentials: function(url, userName) {
        return NodeGit.Cred.sshKeyFromAgent(userName);
    },
    transferProgress: function(info) {
      return console.log(info);
    }
};
var getMostRecentCommit = function(repository) {
    return repository.getBranchCommit('master');
};

var getCommitMessage = function(commit) {
    return commit.message();
};
NodeGit.Clone(remoteRepo, path.join('_deployments',deployFolderName), cloneOptions )
    .then(getMostRecentCommit, function() { console.log('error %o', arguments);})
    .then(getCommitMessage, function() { console.log('error %o', arguments);})
    .then(function(message) {
        return console.log(message);
    }, function() { console.log('error %o', arguments);})
    .done(function() {
        console.log('Donezo');
    });

Whoops, sorry about that, absentmindedly clicked that.

I ran
var path    =  require('path');
var NodeGit = require('nodegit');

// create tmp folder
var deployFolderName = 'test';

// clone into tmp folder
var remoteRepo = 'ssh://git@stash.vodori.com:2121/ps/pepper-demo-site.git';
console.log('Remote stash repo: %s', remoteRepo);
console.log('Cloning into %s', path.join('_deployments',deployFolderName));
var cloneOptions = {};
cloneOptions.remoteCallbacks = {
    credentials: function(url, userName) {
        return NodeGit.Cred.sshKeyFromAgent(userName);
    }
};
console.log('Cloning snapshot repo');
var getMostRecentCommit = function(repository) {
    return repository.getBranchCommit('master');
};

var getCommitMessage = function(commit) {
    return commit.message();
};
NodeGit.Clone(remoteRepo, path.join('_deployments',deployFolderName), cloneOptions )
    .then(getMostRecentCommit, function() { console.log('error %o', arguments);})
    .then(getCommitMessage, function() {console.log('error %o', arguments);})
    .then(function(message) {
        return console.log(message);
    }, function() { console.log('error %o', arguments);})
    .done(function() {
        console.log('Donezo');
    });

and see the same behaviour.
I'm on Mint Linux, in a zshell on node 0.10.33
What are you on?

I also checked with git@github.com:nodegit/test... same problem (which is what I expected, but figured was worth checking)

Also seen on a Mac, zshell, node 0.11.14

I'm getting the same behavior as @dancrumb. It just hangs. Looking into it more.

Just to close the loop, I just confirmed this in a Bash shell as well (on my Linux box)

I've narrowed it down to
var cloneOptions = {};
cloneOptions.remoteCallbacks = {
    credentials: function(url, userName) {
        return NodeGit.Cred.sshKeyFromAgent(userName);
    }
};

If the callback is removed and you try to clone from a public repo it will work.
Try this @dancrumb:
var path    =  require('path');
var NodeGit = require('nodegit');

// create tmp folder
var deployFolderName = 'test';

// clone into tmp folder
var remoteRepo = 'git@github.com:nodegit/test';
console.log('Remote stash repo: %s', remoteRepo);
console.log('Cloning into %s', path.join('_deployments',deployFolderName));
var cloneOptions = {};

console.log('Cloning snapshot repo');
var getMostRecentCommit = function(repository) {
    return repository.getBranchCommit('master');
};

var getCommitMessage = function(commit) {
    return commit.message();
};
NodeGit.Clone(remoteRepo, path.join('_deployments',deployFolderName), cloneOptions )
    .then(getMostRecentCommit, function() { console.log('error %o', arguments);})
    .then(getCommitMessage, function() {console.log('error %o', arguments);})
    .then(function(message) {
        return console.log(message);
    }, function() { console.log('error %o', arguments);})
    .done(function() {
        console.log('Donezo');
    });

Yeah, but then it won't actually clone it?

It will for a public repo. This is just a test to confirm what I'm seeing.

If my hypothesis is correct then I'm lead to believe that the queueing of the callbacks via uv_async_init and uv_async_send is causing the main node loop to never get the kill signal.
This might be related to #438

So it clones it for me but not on other machines. I must have some agent authenticating the connection or something. Well change it to our http test repo (http://git.tbranyen.com/smart/site-content) and try that.

As I'm seeing this issue as-well, the result I get from executing @johnhaley81's code:
Remote stash repo: git@github.com:nodegit/test
Cloning into _deployments/test
Cloning snapshot repo
error %o { '0': [Error: authentication required but no callback set] }
error %o { '0': [TypeError: Cannot read property 'message' of undefined] }
Donezo

@amitaibu did you try setting var remoteRepo = 'http://git.tbranyen.com/smart/site-content';?

Did now, and it worked fine:
Remote stash repo: http://git.tbranyen.com/smart/site-content
Cloning into _deployments/test
Cloning snapshot repo
Marked as lesser importance

Donezo

This seems like a bug in our library. I'll mark it as such and we'll try to figure it out.
In the meantime, you could put process.exit() in the .done method.

In the case of this happening in the context of a long-running process (i.e. express server) do you think the hang would be a problem?  A little concerned that maybe it's hanging onto some kind of open connection and that over time this might cause problems...

@JediMindtrick I seriously doubt it's hanging on to any kind of connection, @johnhaley81 is usually right about his hunches: https://github.com/nodegit/nodegit/issues/497#issuecomment-83754567

@tbranyen well I've definitely been wrong before :)
@JediMindtrick if you want to try it out write a quick script that uses callback functions in the processing of a call that does open any connections. Nodegit.Status.foreach would do the trick. It should still hang after your script is finished processing.
I'm definitely looking into this more but at least we have a sort of work-around for right now.

The handles that were created for callback's being executed on the main thread needed to be cleaned up via uv_close. That's about to get merged into master which should fix this.

@johnhaley81 suggestion https://github.com/nodegit/nodegit/issues/497#issuecomment-83798391 definetly worked

@juanbrujo this will be fixed in the next release FYI.

@johnhaley81  Thanks for fixing this.

In the meantime, you could put process.exit() in the .done method.

You're probably better off open up a new issue with your failing choice

Also, @kevindashgit you offered no additional information necessary for us to assist you. Can you provide OS, Node version, NodeGit version, prebuilt or built from source, and the script that is failing?
No need to open a new issue, but if you want more rapid help, drop into our Gitter

More info:

More Info:
OS: OSX El Capitan v10.11.1
Node Version: <IP_ADDRESS>
NodeGit Version: ^0.11.9 (prebuilt)
Script:
cloneOptions.fetchOpts = {
      callbacks: {
        certificateCheck: function() { return 1; },
        credentials: function(GITLAB_URL, userName) {
          console.log('help im stuck in an infinite loop');
          return NodeGit.Cred.sshKeyFromAgent(userName);
        },
        transferProgress: function(info) {
          return console.log(info);
        }
      }
    };

    var getMostRecentCommit = function(repository) {
        return repository.getBranchCommit('master');
    };

    var getCommitMessage = function(commit) {
        return commit.message();
    };
    NodeGit.Clone(siteUrl, path.join(__dirname, 'sites', test.name), cloneOptions)
        .then(getMostRecentCommit, function() { console.log('error %o', arguments);})
        .then(getCommitMessage, function() { console.log('error %o', arguments);})
        .then(function(message) {
            return console.log(message);
        }, function() { console.log('error %o', arguments);})
        .done(function() {
            console.log('Donezo');
            process.exit();
        });

Thanks so much for updating us with some more information, I'm probably not the best one to diagnose, but I'll try and reproduce locally to at least verify.
Ping @johnhaley81 who can assist, or know who best to assist.

@kevindashgit you're giving back wrong credentials and NodeGit will ask you for creds until you either pass back one that works or pass back NodeGit.Cred.defaultNew()


add fasvg 0.1.0

I am submitting

[x] a new package

Description: Explain what the package does and why it's useful.
fasvg is an offline fontawesome binding for typst. Unlike the fontawesome package which uses unicode, fasvg uses the SVG icon files, which means

it can be used in online and offline Typst projects without being affected by the unicode support problems.
it can be more easily tweaked and customized (e.g. height, width, color).

I have read and followed the submission guidelines and, in particular, I

[x] selected a name that isn't the most obvious or canonical name for what the package does
[x] added a typst.toml file with all required keys
[x] added a README.md with documentation for my package
[x] have chosen a license and added a LICENSE file or linked one in my README.md
[x] tested my package locally on my system and it worked
[x] excluded PDFs or README images, if any, but not the LICENSE

This many files in a package is a bit of uncharted territory. From the submission guidelines:

Packages should not contain large files or a large number of files. This will be judged on a case-by-case basis, but if it needs more than ten files, it should be well-motivated.

Yes, it has more than 2000 svg files. I am not sure if there is any work around. It's okay to close the PR.

I would close this then.

I think, since all icons are the same files except viewBox and path, it's possible to store those data in dict, and construct svgs from this:
#let data = (
    brand-amazon-pay: (view: "0 0 640 512", path: "M14 325.3c2.3-4.2 5.2-4.9 ..."),
)

#let i = data.brand-amazon-pay
#image.decode("<svg xmlns= ... viewBox\"" + i.view + "\" ... <path d=\"" + i.path + "\"/></svg>", format: "svg")

That's still a lot of data, though.


[Feature] Add country flag beside country codes in Currency Calculator

Description
I can add a feature in currency calculator which also displays the country's flag of the country selected in both from and to countries.

Screenshots
No response
Checklist

[X] I have checked the existing issues.
[X] I follow Contributing Guidelines of this project.
[X] I am a GSSOC'24 contributor.
[ ] I am a IWOC'24 contributor.
[ ] I am a JWOC'24 contributor.
[ ] I am a SWOC'24 contributor.

Code of Conduct

[X] I agree to follow this project's "Code of Conduct".

Go ahead @meetarora10

I wanted to work on this issue. @Rakesh9100 Please assign me this issue.

Go ahead @PDBharadwaj


Swift Promise & REST API Delegate?

I'm struggling to create a Swift class that fetches data from the Salesforce REST API. The class conforms to Salesforce's REST API delegate protocol, and implements callback methods - so I need to fulfill or reject the promise from those methods, but don't know how. Thanks in advance for any help.
import Foundation
import PromiseKit

class SalesforceObjectFetcher: NSObject, SFRestDelegate {

    var promise: Promise<SalesforceObject>!

    func fetch (request: SFRestRequest) -> Promise<SalesforceObject> {
        SFRestAPI.sharedInstance().send(request, delegate: self)
        promise = Promise<SalesforceObject>({ (fulfill, reject) -> Void in
            //TODO
        })
        return promise
    }

}

//MARK: SFRestDelegate compliance
extension SalesforceObjectFetcher {

    func request(request: SFRestRequest!, didFailLoadWithError error: NSError!) {
        //TODO: need to reject promise from here...
    }

    func request(request: SFRestRequest!, didLoadResponse dataResponse: AnyObject!) {
        //TODO: need to fulfill promise from here after converting NSDictionary response to model objects...
    }

    func requestDidCancelLoad(request: SFRestRequest!) {
        //TODO: need to reject promise from here...
    }

    func requestDidTimeout(request: SFRestRequest!) {
        //TODO: need to reject promise from here...
    }
}

I found an example in UIAlertView+Promise.swift - but also read the warning in the docs against combining promises and delegates, so closing this. Would still welcome any examples or suggestions how to do this better. Thanks.

import Foundation
import PromiseKit

class SalesforceObjectFetcher: NSObject, SFRestDelegate {

    // the type of the promise might be different, see fulfill usage to decide
    var deferred: = Promise<SalesforceObject>.defer()

    func fetch (request: SFRestRequest) -> Promise<SalesforceObject> {
        SFRestAPI.sharedInstance().send(request, delegate: self)
        PMKRetain(self) // YUCK!
        return deferred.promise
    }
}

//MARK: SFRestDelegate compliance
extension SalesforceObjectFetcher {

    func request(request: SFRestRequest!, didFailLoadWithError error: NSError!) {
        deferred.reject(error)
    }

    func request(request: SFRestRequest!, didLoadResponse dataResponse: AnyObject!) {
        deferred.fulfill(dataResponse as SalesforceObject)
    }

    func requestDidCancelLoad(request: SFRestRequest!) {
        let error = NSError(…)  // make a code and domain to represent this error state
        deferred.reject(error)
    }

    func requestDidTimeout(request: SFRestRequest!) {
        let error = NSError(…)
        deferred.reject(error)
    }
}

Thank you!

@mxcl - I'm curious: why the println(self) to force a retain vs. PMKRetain( ) and PMKRelease( ) ?
Thanks

PMKRetain is better, I didn't suggest it because the suggestion is easier to understand, but if you understand the macros, use them!

I don't see PMKRetain / PMKRelease in the current release. Was it renamed at some time?

They were never public API. So they gone. But there's other ways to achieve the same.


Video doesn't play after unlocking/switching apps

When a video is playing and then if I pause and  do nothing for screen timeout (let TV automatically locks itself), when I unlock the TV and play back the video doesn't play. Not only when locking and unlocking the TV let's say if I go to the home by pressing the home button in the remote and then again going back anime TV app the playback doesn't play.
For the time being to solve the problem I am currently force stopping the app and then restart it, fixes the issue and plays very well no issues.

Same problem here in my android TV , when returning from sleep mode,  return to a black screen and the video won't play even if i ext the app and return i need to force stop it from the setting.

It known issue, but the fix will not available soon. It already on the plan list for dev from scratch.


about dataset:"data/epfl"

Hello, I want ask you some questions about "dataset:"data/epfl"" in eval.py. I'd like to ask if the paths are auto-generated or locally available. I would appreciate it if you could reply.


On ne change pas by Céline Dion unsupported.

Check if issue with swaglyrics or whether song lyrics unavailable on Genius.

stripper -> Celine-Dion-On-ne-change-pas

Not on Genius :(

lyrics added to Genius


sdlog2: checks and warnings to make sure there is space left on the SD card

Adresses #1535.
Tested on bench.

Cool! So you've tested with a full microSD?

@LorenzMeier Yes I have, I just filled it with other stuff.

We should also check as part of this PR check the return values here and err out (= calling close() on the fp) if fputs fails here:
https://github.com/PX4/Firmware/blob/master/src/modules/mavlink/mavlink_messages.cpp#L373-L375

@LorenzMeier Do these fputs cause any trouble? Or will they just fail silently? I don't the latter would be an issue.

We have seen people report erratic behavior of the main loop if the FS is full. I suspect timing changes, se we need to stop trying if things have gone south already. It should not cause trouble, but still does.

Hm, but if it only fails to write once, we don't necessarily want to bail out already. We should rather have the same free_space_check() available? I could move it to a lib place?

I’d like to avoid to call the statfs API on too many places. I don’t trust its timing. I think its safer to increment an error counter and bail out if e.g. 5 consecutive writes fail. In this particular setup its actually nice, because the mavlink text log will write the full SD card to file and log the important events even if sdlog2 bailed out already. We probably want the event log to run as long as possible.

I have pushed the MAVLink logging changes on top of your branch here: https://github.com/PX4/Firmware/tree/sd_full

Closing in favor of extended PR.

Thanking for continuing this!


Interval control on Exchange

https://github.com/bitshares/bitshares-ui/issues/2145
Before starting this, please familiarize yourself with TradingView and get back to me to discuss options.

@sschiessl-bcp  I have started this task.

I asked tradingview team to grant access to their repository

I researched and found that features can be disabled in https://github.com/blockchainprojects/bitshares-ui/blob/develop/app/components/Exchange/TradingViewPriceChart.jsx#L33
For adding new dates should be added new resolutions to supported_resolutions.
Now I am searching for how to add new buttons to the widget`s header

The Header should not be within TradingView, but rendered above it since the header will also allow to switch the chart (such that TradingView might not be present anymore).


1 year limit for CalendarView (timeframe)

Hello,
I post here because I can't find solutions.
Well I am retrieving all events from 2012 to 2015 with :
$request->CalendarView->StartDate = strtotime('2012-01-01');
$request->CalendarView->EndDate = strtotime('2015-12-31');
but the request don't understand after current date + 1 year
for example if i set $request->CalendarView->EndDate = strtotime('2014-10-29'); it works
I want to see events more than 1 year from current date, is there a trick in order to avoid this limit ?
All the best

This issue is over three years old. If you are still having trouble with the latest version from master, please open a new issue.


Feature Request: prune specific directories

What version of dep are you using (dep version)?
0.5.0
What dep command did you run?
dep ensure -update
What do you want?
I would like to be able to prune a sub-directory of a specific repo.
The files in this sub-directory are unnecessary to the project (mostly test related files), but they break git on windows and cause me tons of problems.
The existing prune options are not enough for me, because I want to keep the non-go files in other directories of this project/repo.
Example:
[prune]
  non-go = true

  [[prune.project]]
    name = "github.com/project/name"
    go-tests = true
    non-go = false
    directories = ["github.com/project/name/bad-files", "github.com/project/name/more-bad-files"]

Can you use build tags to filter out the project you don't want on builds that make it fail? Or build tags that ensure the dependency you don't want isn't imported? If it's not imported anywhere it should be pruned.
I might also suggest wrapping "dep ensure" in a script that always removes the directories you don't want.

Its not golang builds that fail.  It is actually git that doesn't like the files.
In any case, that is just one possible reason why this feature would be good.
Some use-cases I can imagine:

Directory contains unnecessary files that break other tools you use (ie: git, etc).
Directory contains large files that you don't wish to commit to your repo.
Directory contains code in other languages you are not using, that you'd rather not commit.
Directory contains out of date generated code, and you want other people in the company who are using your repo to use the generated code in a different package/path, but their ide's keep selecting the old generated package first when auto-filling imports.
There are probably other uses cases.

Reasons why existing features are not enough:
prune non-go is not sufficient, because in my case I wish to keep non-go files in some other directories.
prune go-tests is not sufficient, because the directory I wish to remove may contain non-go files (in my case this is true).
ignored is not sufficient, because right now it still keeps non-go files.  (If this is changed, it would solve my problem: https://github.com/golang/dep/issues/2105 ).
Lastly, I would rather not create a new script and wrap dep in it, as it would be one more thing for everyone who uses the project to have to know about.  As people join and leave the team, someone is just going to start running regular dep ensure, because that is what we do everywhere for all golang projects.  This is a useful feature to have, and it should be baked into dep.

Dep was officially deprecated earlier this year, and the proposal to archive this repository was accepted. As such, I'm closing outstanding issues before archiving the repository. For any further comments, please use the proposal thread on the Go issue tracker. Thanks!


Fix filesystem paths for Windows

Some test cases failed on Windows because of C:\path\to\file naming semantics. This PR implements normalizes the use of paths to pseudo-Posix style pathing (namely the use of / as the file separator), either by use of path.posix.join() or manually splitting and rejoining the path with the posix file separator.

I also did the extra test cleanup, and fixed a failure in the check binding directory test where the returned dependency order was sometimes different from expected. If you'd like me to slide those into a new PR, we can

Ope, looks like one flaky test (at least), whish is probably the same sporadic ordering cause. Will take another look tomorrow

Closing in place of #14 which has more internal fixes


mpu6000 driver:Investigate if 'test' function causes register checking to find a false faults

While developing  https://github.com/PX4/Firmware/commit/51a7a51d9f0ed290596030d31b16e37ba4fd323d
I noticed the the register checking fails on a test command.
This needs to be debugged

Still an issue?

I have not tested it on latest master.

@dagar - yet it was. See https://github.com/PX4/Firmware/pull/7024

Was mpu9250 copied from mpu6000. Any overlap here? https://github.com/PX4/Firmware/issues/5446

@dagar - yes - I would think it is the same issue. I did a pass on the 9250 in the PR, but I am not set up to test it. I asked @pkocmoud if he could give it a go. Do you have HW with the 9250 you can check it on?

@dagar, @LorenzMeier
One more thing. The root cause was not the test. It was the reset after the test. Now there is a drop out of collecting samples during the test for ~30 ms. Will that be an issue?

Yes, I have a pixhawk 2.1 I could use for testing.


Add an example of RSA signature

Description
Please include a summary of the change and which issue is fixed. Please also include relevant motivation and context.
Fixes # (issue)
Type of change (select or add applied and delete the others)

[ ] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
[ ] API change with a documentation update
[ ] Additional test coverage
[ ] Code cleanup or just sync with upstream third-party crates

How has this been tested?
Checklist

[ ] Fork the repo and create your branch from master.
[ ] If you've added code that should be tested, add tests.
[ ] If you've changed APIs, update the documentation.
[ ] Ensure the tests pass (see CI results).
[ ] Make sure your code lints/format.

Merged, thanks. I made some minor changes on the name, and rebase to the latest master to fixed conflicts.


[proposal] Use Poetry as the Python management tool

I just noticed that we already have pyproject.toml inside the Python projects.
Should we consider to use Poetry as the Python build tool?
The benefits will be:

More stable dependencies management, such as lock file.
Built-in virtual env supports
Integrate with lint/format/unittest tolls, such as pytest, black, isort, and others
More easier to add custom build scripts
More easier to link local package as dependency

Thank you, it's a great tool, we will keep an eye on it. However, it's not the best time to replace the dependency management system now, as our main focus is on new features and user-friendly improvement. It may be introduced in a future release.
Thank you again for your proposal!

However, it's not the best time to replace the dependency management system now, as our main focus is on new features and user-friendly improvement. It may be introduced in a future release.

Of course, agreed totally. This is not something worth a high priority.


Controller: Get Access to ReconcileReason

Would you like to work on this feature?
probably
What problem are you trying to solve?
Unless I'm missing something, there currently doesn't seem to be a way to access ReconcileReason in the reconcile callback.
That's important for knowing what actually changed, and what to do about it.
Describe the solution you'd like
The Controller::run reconcile callback should probably look like impl FnMut(Arc<K>, reason: ReconcileReason, Context<T>) -> ReconcilerFut.
Describe alternatives you've considered
n/a
Documentation, Adoption, Migration Strategy
No response
Target crate for feature
kube-runtime

This is an intentional design choice. ReconcileReason only tells you why the reconciliation was started, not what needs to be done to fix it. It's only meant as an aid to help you get out of infinite reconciliation loops.

That's important for knowing what actually changed, and what to do about it.

You always need to do a full cluster inspection to see what needs to be done. If that's too expensive then you should consider caching via a reflector (and arguably we should do a better job in assisting this caching for owned objects and the like).
Why?

We deduplicate reconciliation requests, so that there is at most one running and one pending reconciliation per object per Controller(/applier). If (non-trivial) reconciliations are triggered in short succession due to reasons X, Y, and Z then reconcile(obj, X) will start running immediately, reconcile(obj, Y) will be scheduled for when X is done, and Z will be dropped (since Y is already pending). Any logic that depends on observing a difference between Y and Z would be broken here.
Events may be lost, for example due to the controller restarting, or a connection issue to the cluster.

I see, that makes sense.

and arguably we should do a better job in assisting this caching for owned objects and the like

My specific issue is exactly the owned resource case.
I guess I can use applier to prevent a second redundant watcher.

Yeah, for now I'd drop down to applier for that use case.
Closing this as a WONTFIX then.