SAMPLE*_MULTI docstrings are incorrect

See also #1801.  Let's view the internal documentation (docstrings) for the SAMPLE*_MULTI functions:
 	NOAA/PMEL TMAP
 	FERRET v7.44 (optimized)
 	Linux 2.6.32-696.30.1.el6.x86_64 64-bit - 12/10/18
 	 3-Apr-19 13:52

yes? sho fun sample*_multi
SAMPLEI_MULTI(I_INDICES,DAT_TO_SAMPLE)
    Returns data sampled according to I indices which may vary in JKL
    I_INDICES: indices upon which to sample
    DAT_TO_SAMPLE: data to sample using I indices
SAMPLEJ_MULTI(J_INDICES,DAT_TO_SAMPLE)
    Returns data sampled according to J indices which may vary in IKL
    J_INDICES: ordered indices
    DAT_TO_SAMPLE: data to sample using J indices
SAMPLEK_MULTI(K_INDICES,DAT_TO_SAMPLE)
    Returns data sampled according to K indices which may vary in IJL
    K_INDICES: ordered indices
    DAT_TO_SAMPLE: data to sample using K indices
SAMPLEL_MULTI(L_INDICES,DAT_TO_SAMPLE)
    Returns data sampled according to L indices which may vary in IJK
    L_INDICES: ordered indices
    DAT_TO_SAMPLE: data to sample using L indices
SAMPLEM_MULTI(DAT_TO_SAMPLE,M_INDICES)
    Returns data sampled according to M indices which may be function of IJKLN
    DAT_TO_SAMPLE: data to sample using L indices
    M_INDICES: ordered indices
SAMPLEN_MULTI(DAT_TO_SAMPLE,N_INDICES)
    Returns data sampled according to N indices which may be function of IJKLM
    DAT_TO_SAMPLE: data to sample using L indices
    N_INDICES: ordered indices

There are several issues here:

The arguments are reversed in SAMPLE{M,N}_MULTI.  Is this a documentation bug, or do these functions really have the args in a different order from SAMPLE{I,J,K,L}_MULTI?

In SAMPLE{M,N}_MULTI under DAT_TO_SAMPLE, it says "using L indices" rather than M, N.

In SAMPLE{I,J,K,L}_MULTI, the "may vary in ..." should include M & N, correct?  Are these indeed 6d-compatible functions?

Yes, the arguments to M_ and N functions are reversed relative to those in SAMPLEI_MULTI etc.  The comment at the start of the code says, "Reverse the order of arguments to be consistent with the SAMPLEL etc functions."  (Were we making a start on #1801 and hadn't resolved the mismatch?)

Cut-and-paste error, so that's easily fixed.

All of the functions are 6-D.  I have added MN to  the argument descripions "which may vary in..."

yes? sho func/detail samplel_multi
SAMPLEL_MULTI(L_INDICES,DAT_TO_SAMPLE)
    Returns data sampled according to L indices which may vary in IJK
        Axes of result:
          X: inherited from argument(s)
          Y: inherited from argument(s)
          Z: inherited from argument(s)
          T: ABSTRACT (result will occupy indices 1...N)
          E: NORMAL (no axis)
          F: NORMAL (no axis)
    L_INDICES: ordered indices (FLOAT)
        Influence on output axes:
          X: passed to result grid
          Y: passed to result grid
          Z: passed to result grid
          T: no influence (indicate argument limits with "[]")
          E: no influence (indicate argument limits with "[]")
          F: no influence (indicate argument limits with "[]")
    DAT_TO_SAMPLE: data to sample using L indices (FLOAT)
        Influence on output axes:
          X: passed to result grid
          Y: passed to result grid
          Z: passed to result grid
          T: no influence (indicate argument limits with "[]")
          E: no influence (indicate argument limits with "[]")
          F: no influence (indicate argument limits with "[]")

So, the remaining question for discussion:  In light of 1801, shall we change all these SAMPLE*_MULTI functions to have the same order of arguments as SAMPLEI, SAMPLEJ, etc,
SAMPLEI(TO_BE_SAMPLED,X_INDICES)  And issue a NOTE when they run?
Andrew, Karl, your opinions?

Shouldn't the E and F descriptions match the other non-sampled dimensions?  (ie, results grid inherits from arguments)

I would think all of the functions in each group need to be consistent with each other.  If the MULTI group is still a new-enough addition, then seems like they should be made consistent with the non-MULTI versions.

Karl, in your first comment, you;re right.  In fact the I,J,K,L functions are NOT 6D.
We should go to a consistent set of calls for sure.  If we follow through with having the code from the MULTI versions of the sample functions replace the SAMPLEI, SAMPLEJ, etc functions then the order should be that of the long-established and well-used  SAMPLEI, SAMPLEJ ones.
I'm actually somewhat reluctant to do #1801.  Those functions are in the heart of Ferret code, not implemented as external functions.  The MULTI ones are written in the external function framework and therefore have some of the inflexibilities of EF's.
I will make the I,J,K,L functions 6d, and will make SAMPLEM_MULTI and SAMPLEN_MULTI match SAMPLEI_MULTI in their argument ordering.  And we can go from there.

I agree that SAMPLE*_MULTI() ought to have a consistent argument order, namely that which is already in SAMPLE*().  (In #1801 I had suggested eventually replacing SAMPLE* with SAMPLE*_MULTI, for which identical the axis ordering would be key for backwards compatibility.  But we can defer that merger for now.)
My understanding is that we actually need to swap the argument order of SAMPLE{I,J,K,L}_MULTI, not SAMPLE{M,N}_MULTI, to achieve consistency with the present implementation of SAMPLE*.
As for axis influence, here's how I think it should work, if possible.  Consider the post-swap SAMPLEL_MULTI(TO_BE_SAMPLED, L_INDICES):

The result L-axis should always be inherited from L_INDICES.  TO_BE_SAMPLED should have no influence on the L-axis.

If L_INDICES has a Q-axis (where Q is any one of IJKMN), then the result inherits the Q-axis of L_INDICES (and also TO_BE_SAMPLED, if and only if it has a Q-axis, which if present must match the Q-axis of L_INDICES).

If L_INDICES does not have a Q-axis, then the result inherits its Q-axis from TO_BE_SAMPLED (if and only if TO_BE_SAMPLED has a Q-axis).

Here's what the results would look like.  Shorthand: A=DAT_TO_SAMPLE, B=L_INDICES.
SAMPLEL_MULTI(A,B)

where A=DAT_TO_SAMPLE, B=L_INDICES

A   B     result axes
-------------------------------------
L   L     L from B.  Just sample A using each of the L-indices in B.
L   Q     Q from B.  At each Q-point in B, return the single A[L=B]
L   LQ    LQ from B.  At each Q-point in B, return the several A[L=B].

LQ  L     L from B, Q from A.  At each Q-point in A, return the several A[L=B].
LQ  Q     Q from AB.  At each Q-point in AB, return the single A[L=B].
LQ  LQ    L from B, Q from AB.  At each Q-point in AB, return the several A[L=B].

An A with no L-axis is simply a degenerate case of the LQ-shaped A above,
just with an L-axis of size 1.  Valid values will only be returned where B=1,
otherwise return the missing value.

OK.  I'd thought to leave the older existing multi functions alone and make the newer M, N ones match those, but I'm happy to make ALL the SAMPLE functions match.  Sometimes we get a bit too hung up on backwards compatibility with no real need.
(DATA_TO_SAMPLE, INDICES)
As to inheritance, what I understand you to have said here is the way the function evaluation structure does work.  On return, the result has the grid of the dat-to-sample, but with the sample-direction axis  (L for SSAMPLEL) replaced by a simple ABSTRACT axis index-list in that direction of the length of the list of indices, but  it could in fact inherit the L-axis of the index list. The functions assume that the index list is on a simple list in the L direction, but it shouldn't have to.  I'll make it inherit the index-axis from argument 2.
The grid of the sample_indices determines the result in that direction (e.g.  L) and any further dimensions in the grid of that argument must match the grid of the dat-to-sample.

Here are some test cases.  Let's examine the Ferret v7.44 implementation of SAMPLEM_MULTI(), using the rows of the table above.  First define some test data:
 	NOAA/PMEL TMAP
 	FERRET v7.44 (optimized)
 	Linux 2.6.32-696.30.1.el6.x86_64 64-bit - 12/10/18
 	 3-Apr-19 18:47

yes? def ax/e=11:15:1 eax_a; def ax/e=1:4:1 eax_b; def ax/x=0:1:1 xax
yes? let a_m = _e[ge=eax_a]^2; let a_i = (4-x[gx=xax])^2; let a_mi = a_m + a_i
yes? let b_m = 5-_e[ge=eax_b]; let b_i = 1+x[gx=xax]; let b_mi = b_m + b_i - 1

Test 1:
yes? list/noh/p=1 a_m
 11   / 1:  121.
 12   / 2:  144.
 13   / 3:  169.
 14   / 4:  196.
 15   / 5:  225.
yes? list/noh/p=1 b_m
 1   / 1:  4.
 2   / 2:  3.
 3   / 3:  2.
 4   / 4:  1.
yes? list/noh/p=1 samplem_multi(a_m, b_m)
 1   / 1:  196.
 2   / 2:  169.
 3   / 3:  144.
 4   / 4:  121.

This is correct, except that the E-axis should've been inherited from b_m, not an abstract axis.
Test 2:
yes? list/noh/p=1 a_m
 11   / 1:  121.
 12   / 2:  144.
 13   / 3:  169.
 14   / 4:  196.
 15   / 5:  225.
yes? list/noh/p=1 b_i
 0   / 1:  1.
 1   / 2:  2.
yes? list/noh/p=1 samplem_multi(a_m, b_i)
 1   / 1:  121.
 2   / 2:  144.

Correct, except X-axis should've been inherited from b_i.
Test 3:
yes? list/noh/p=1 a_m
 11   / 1:  121.
 12   / 2:  144.
 13   / 3:  169.
 14   / 4:  196.
 15   / 5:  225.
yes? list/noh/p=1 b_mi
 1   / 1:  4.  5.
 2   / 2:  3.  4.
 3   / 3:  2.  3.
 4   / 4:  1.  2.
yes? list/noh/p=1 samplem_multi(a_m, b_mi)

Here we'd expect a result on the grid of b_mi, with {196,169,144,121} at x=0 and {225,196,169,144} at x=1.  But instead we get an error:
Bailing out of external function "samplem_multi":
	Argument 2 has no E axis. If it has >1 dimension, E axis is the sample dimension.
 **ERROR:

The error is befuddling, and incorrect since argument 2 actually does have an E axis.
Test 4:
yes? list/noh/p=1 a_mi
 11   / 1:  137.  130.
 12   / 2:  160.  153.
 13   / 3:  185.  178.
 14   / 4:  212.  205.
 15   / 5:  241.  234.
yes? list/noh/p=1 b_m
 1   / 1:  4.
 2   / 2:  3.
 3   / 3:  2.
 4   / 4:  1.
yes? list/noh/p=1 samplem_multi(a_mi, b_m)
 1   / 1:  212.  205.
 2   / 2:  185.  178.
 3   / 3:  160.  153.
 4   / 4:  137.  130.

This result is correct, except that the E-axis should've been inherited from b_m, rather than abstract.
Test 5:
yes? list/noh/p=1 a_mi
 11   / 1:  137.  130.
 12   / 2:  160.  153.
 13   / 3:  185.  178.
 14   / 4:  212.  205.
 15   / 5:  241.  234.
yes? list/noh/p=1 b_i
 0   / 1:  1.
 1   / 2:  2.
yes? list/noh/p=1 samplem_multi(a_mi, b_i)
 1   / 1:  137.  130.
 2   / 2:  160.  153.

This is not right at all.  The result should be the 1-dimensional {137, 153} on the X-axis of b_i.
Test 6:
yes? list/noh/p=1 a_mi
 11   / 1:  137.  130.
 12   / 2:  160.  153.
 13   / 3:  185.  178.
 14   / 4:  212.  205.
 15   / 5:  241.  234.
yes? list/noh/p=1 b_mi
 1   / 1:  4.  5.
 2   / 2:  3.  4.
 3   / 3:  2.  3.
 4   / 4:  1.  2.
yes? list/noh/p=1 samplem_multi(a_mi, b_mi)
 1   / 1:  212.  234.
 2   / 2:  185.  205.
 3   / 3:  160.  178.
 4   / 4:  137.  153.

This is correct, except that the E-axis should have been inherited from b_mi.
It'd also be good to add tests for the degenerate cases, for which b can only be 1 (otherwise result is missing):
samplem_multi(a_i, b_m)
samplem_multi(a_i, b_i)
samplem_multi(a_i, b_mi)

but I'm getting tired.
Bonus test: Try to index outside the m-range of a_m:
yes? list/noh samplem_multi(a_m, esequence(6))

Bailing out of external function "samplem_multi":
	 Sampling index 6 in ARG1 is outside the range of L indices for ARG2 (-999:-999)
 **ERROR: error in external function

For consistency with the longstanding SAMPLE() functions, any out-of-range indices should return "missing" for that result point, not an error.  Also note that the error message indicates the wrong index (L instead of M) -- probably a copy-paste error in the code.

Changing my mind on one detail of axis inheritance.  Again for consistency with the longstanding  SAMPLE() functions, the second argument should be able to be a 1D list on any axis, so you can do
let sampled_data = SAMPLEJ(my_var, {2, 5, 12})
without that second argument having to be on a Y axis.  This means that contrary to what I said in a comment above, the grid of the result in the index-direction will be abstract instead of being inherited from the second argument.  The length of the L axis of SAMPLEL_MULTI is set by the length of the L axis of the second argument, or the length of any 1-D list sent in as the second argument.

I'd interpret the example
let sampled_data = SAMPLEJ(my_var, {2, 5, 12})

where MY_VAR is a Y-vector, as analogous to my Test #2 above.  The result would be on an (abstract?) X-oriented axis, and consist of samples from the 2nd, 5th, and 12th elements of MY_VAR.
If the user wanted a Y-oriented result, they could just do:
let sampled_data = SAMPLEJ(my_var, ysequence({2, 5, 12}))

In example 2, the expression
samplem(a_m, b_i)
is a subset of the E-direction variable a_m, sampled at two points of its E-axis, and the result is on an abstract E-axis.
A SAMPLEJ result will always be returned with the sample operation done along the Y direction and returned along the Y axis.  The function's axis inheritance - how the result grid is defined - is a property of the function, not the arguments sent to it (** with a few exceptions, see below).   SAMPLEJ cannot sometimes return the list along an abstract Y axis and other times return it along an X axis.
The axis influence - how the arguments contribute to the result - can be either that the axis is passed to the result grid, or when the result axis is ABSTRACT or CUSTOM, can be computed from the axis of one or more arguments.  Here we could use the ABSTRACT axis or define a CUSTOM axis that's 1, 2, ..., nsample.
yes? show function/details samplej
SAMPLEJ(TO_BE_SAMPLED,Y_INDICES)
    sample a field at a list of Y indices
        Axes of result:
          X: inherited from argument(s)
          Y: ABSTRACT (result will occupy indices 1...N)
          Z: inherited from argument(s)
          T: inherited from argument(s)
          E: inherited from argument(s)
          F: inherited from argument(s)
    TO_BE_SAMPLED: data to sample at list of Y indices supplied (FLOAT)
        Influence on output axes:
          X: passed to result grid
          Y: no influence (indicate argument limits with "[]")
          Z: passed to result grid
          T: passed to result grid
          E: passed to result grid
          F: passed to result grid
    Y_INDICES: list of Y indices at which to sample (FLOAT)
        Influence on output axes:
          X: no influence (indicate argument limits with "[]")
          Y: no influence (indicate argument limits with "[]")
          Z: no influence (indicate argument limits with "[]")
          T: no influence (indicate argument limits with "[]")
          E: no influence (indicate argument limits with "[]")
          F: no influence (indicate argument limits with "[]")

** We do have a class of direction-changing functions for some operations, the dot-product, transpose.

Yes, for SAMPLE*_MULTI() I'm proposing a slightly different axis inheritance from what's in SAMPLE*().
Would the following be possible?  Dream session:
yes? show function/details samplej_multi
SAMPLEJ_MULTI(TO_BE_SAMPLED,Y_INDICES)
    sample a field at a list of Y indices
        Axes of result:
          X: inherited from argument(s)
          Y: inherited from argument(s)
          Z: inherited from argument(s)
          T: inherited from argument(s)
          E: inherited from argument(s)
          F: inherited from argument(s)
    TO_BE_SAMPLED: data to sample at list of Y indices supplied (FLOAT)
        Influence on output axes:
          X: passed to result grid
          Y: no influence (indicate argument limits with "[]")
          Z: passed to result grid
          T: passed to result grid
          E: passed to result grid
          F: passed to result grid
    Y_INDICES: list of Y indices at which to sample (FLOAT)
        Influence on output axes:
          X: passed to result grid
          Y: passed to result grid
          Z: passed to result grid
          T: passed to result grid
          E: passed to result grid
          F: passed to result grid

On entry, the function would check whether Y_INDICES has X,Z,T,E,F axes.  For each of those, check whether TO_BE_SAMPLED has a similarly-directed axis that differs from Y_INDICES, and if so raise an error.  Otherwise pass any existing X,Z,T,E,F axes through from Y_INDICES to the RESULT.  Lastly, for any of X,Z,T,E,F that don't exist in Y_INDICES, inherit from TO_BE_SAMPLED.  Is all that dynamic checking possible?
If not, then maybe we could just specify the inheritance as in the above table, and make the user do any axis-casting before calling the function.  E.g. say that TO_BE_SAMPLED has shape XYT and Y_INDICES has shape YTE.  Then we could just do:
yes? list samplej_multi(to_be_sampled+0*_e[ge=y_indices], y_indices+0*x[gx=to_be_sampled])

Maybe, I'll think it through.  If we have inheritance from two arguments then those axes need to be conformable.  If the axis exists in both then they need to agree.  If an axis exists in just one then it contributes to the grid - so long as the code then knows how to fill in that grid, and I'm having a hard time wrapping my head around that.  You're saying in example 5
yes? list/noh/p=1 a_mi
 11   / 1:  137.  130.
 12   / 2:  160.  153.
 13   / 3:  185.  178.
 14   / 4:  212.  205.
 15   / 5:  241.  234.
yes? list/noh/p=1 b_i
 0   / 1:  1.
 1   / 2:  2.
yes? list/noh/p=1 samplem_multi(a_mi, b_i)
 1   / 1:  137.  130.
 2   / 2:  160.  153.

that the result should consist of the values at (i=1,m=1)  and (i=2,m=2).   Why?  What if the data-to-sample is 3-D?
If we do this then the idea in ticket #1801 is kaput,  if the results for 1-D index lists are not to be the same as they are now:
yes? list/noh/p=1 samplem(a_mi, b_i)
 1   / 1:  137.  130.
 2   / 2:  160.  153.

yes? list/noh/p=1 samplem_multi(a_mi, b_i)
 1   / 1:  137.  130.
 2   / 2:  160.  153.

The concept was originally just to be able to pick out data at a set of index values that changes, say with depth or time.

In Test 5 the a_mi and b_i share the same X-axis, so
samplem_multi(a_mi, b_i)

should say, "At each longitude, return the b'th ensemble member."  So the result would be two values: one at each longitude.
Instead the present implementation returns all the source longitudes for the b'th ensemble member.  I'd argue that the call for that should be:
samplem_multi(a_mi, b_m)

where b_m is M-directed, e.g. esequence(b_i).

This sounds a bit more like a masking operation.  The function machinery for inheriting grids from the arguments aren't this flexible. The rules of conformability expand grids rather than shrinking them, as we'd need to do here.
I'll finish cleaning up the functions as-is and let these ideas marinate a bit.

In Test 5, both a_mi and b_i share the same X-axis, so there'd be no shrinking along that axis; the result would just inherit the grid from b_i.  Sorry if I'm not communicating clearly!  It seems clear in my head...

Oh, I'm not being that clear myself.  I believe I see the idea but it doesn't fit the machinery.
I was thinking not about shrinking an axis, but shrinking the grid.  The problem is in saying that sometimes the result would have an E axis and sometimes not.   If the result is going to get its axes from the first argument, except that the the E direction will be created from argument 2, then that's what needs to happen.  The result needs to be number-of-E-elements long, where that's the size of the the E axis of argument 2, or we can fudge that (as the simpler SAMPLEM function does) and say if there's any 1-D list in the second arg, then make an E axis that long. I think you're saying don't do that fudging but instead (something like) treat the E axis of argument 2 as if it's of length 0, and continue.  This just doesn't work in the function setup.

Oh, wow.  Once I wrote that, I tried it.  If argument 2 has no E axis, then the abstract axis can be defined as an axis from M=1:1 and then,

yes? list samplem_multi(a_mi, b_i)
             VARIABLE : SAMPLEM_MULTI(A_MI, B_I)
             SUBSET   : 2 points (X)
             E        : 1
 0   / 1:  137.0
 1   / 2:  130.0

The grid does have to have some kind of 1-point axis. I kind of think that instead of the ABSTRACT axis here, we could define a "custom" axis for all of these results.  It's clearer to see an axis of length 1 than  an ABSTRACT axis of length  99999999 in a "show grid" output.

yes? let var =  samplem_multi(a_mi, b_i)
yes? list var
             VARIABLE : SAMPLEM_MULTI(A_MI, B_I)
             SUBSET   : 2 points (X)
             E (Index): 1
 0   / 1:  137.0
 1   / 2:  130.0
yes? show grid
yes? show grid var
    GRID (G006)
 name       axis              # pts   start                end                 subset
 XAX       X                    2 r   0                    1                   full
 normal    Y
 normal    Z
 normal    T
 (AX002)   E (Index)            1 r   1                    1                   (axis from grid-changing func)
 normal    F

I'll get this done next week and we can get you a copy to try out , plus the other recent fix for 1916/ 1922.

Just clarifying that for
yes? def ax/e=11:15:1 eax_a; def ax/x=0:1:1 xax
yes? let a_mi = _e[ge=eax_a]^2 + (4-x[gx=xax])^2
yes? let b_i = 1+x[gx=xax]
yes? list/noh/p=1 a_mi
 11   / 1:  137.  130.
 12   / 2:  160.  153.
 13   / 3:  185.  178.
 14   / 4:  212.  205.
 15   / 5:  241.  234.
yes? list/noh/p=1 b_i
 0   / 1:  1.
 1   / 2:  2.

the desired answer to
yes? samplem_multi(a_mi, b_i)

is the 1-dimensional {137, 153} on the axis XAX.  At longitude 0 the result is a_mi[x=0, m=1] = 137.  At longitude 1 the result is a_mi[x=1, m=2] = 153.

Yes, I agree. That's what we'll return.
How about this.  The same initial definitions, looking at the multi-sample in the I direction:

yes? def ax/e=11:15:1 eax_a; def ax/e=1:4:1 eax_b; def ax/x=0:1:1 xax
yes? let a_m = _e[ge=eax_a]^2; let a_i = (4-x[gx=xax])^2; let a_mi = a_m + a_i
yes? let b_m = 5-_e[ge=eax_b]; let b_i = 1+x[gx=xax]; let b_mi = b_m + b_i - 1

yes? list a_mi
             VARIABLE : A_M + A_I
             SUBSET   : 2 by 5 points (X-E)
             0     1
              1     2
 11   / 1:  137.  130.
 12   / 2:  160.  153.
 13   / 3:  185.  178.
 14   / 4:  212.  205.
 15   / 5:  241.  234.

yes? list b_mi
             VARIABLE : B_M + B_I - 1
             SUBSET   : 2 by 4 points (X-E)
           0   1
            1   2
 1   / 1:  4.  5.
 2   / 2:  3.  4.
 3   / 3:  2.  3.
 4   / 4:  1.  2.

yes? list samplei_multi(a_mi, b_mi)
             VARIABLE : SAMPLEI_MULTI(A_MI, B_MI)
             SUBSET   : 2 by 5 points (X (Index)-E)
             1     2
              1     2
 11   / 1:  ....  ....
 12   / 2:  ....  ....
 13   / 3:  178.  ....
 14   / 4:  212.  205.
 15   / 5:  ....  ....

To spell it out, what's happening is:
All index-data in b_mi of 3, 4, 5 return missing-result, as the X-direction of a_mi has indices 1, 2. Otherwise:
  b_mi  (m,i)         contains index value     --> a_mi at (m,i) location is     fcn  returns
            3,1                    2                                    3,2                             178
            4,1                    1                                    4,1                             212
            4,2                    2                                    4,2                             205

but looking at your "dream session" in comment 3, maybe I need to reverse the inheritance.  I'll fiddle with that, but we're getting there.

Note that my Test 3 showed the dream result for SAMPLEM_MULTI, not SAMPLEI_MULTI.  For SAMPLEM_MULTI the dream result was (on the grid of b_mi):
yes? list samplem_multi(a_mi, b_mi)
             VARIABLE : SAMPLEI_MULTI(A_MI, B_MI)
            0     1
            1     2
 1   / 1:  212.  234.
 2   / 2:  185.  205.
 3   / 3:  160.  178.
 4   / 4:  137.  153.

In contrast, SAMPLEI_MULTI should return an error, since the non-I part of the grid (namely the M-axis) isn't conformable between a_mi and b_mi.  In this instance the "rule 2" above would read:
"If I_INDICES has an M-axis, then the result inherits the M-axis of I_INDICES (and also TO_BE_SAMPLED, if and only if it has an M-axis, which if present must match the M-axis of I_INDICES)."
The M-axes don't match, so we should get an error for SAMPLEI_MULTI.

I came up with that example thinking about testing error conditions.
So, you're we really want the grids to match in length. I don't know that we're talking about actual conformability here, but maybe just axis length.  Certainly along the sample-direction, that's just a list of indices so it doesn't have world coordinates or units.
On entry, the function would check whether Y_INDICES has X,Z,T,E,F axes. For
each of those, check whether TO_BE_SAMPLED has a similarly-directed axis that
differs from Y_INDICES, and if so raise an error. Otherwise pass any existing
X,Z,T,E,F axes through from Y_INDICES to the RESULT. Lastly, for any of X,Z,T,E,F
that don't exist in Y_INDICES, inherit from TO_BE_SAMPLED.
This seems to say that Y_INDICES might an axis in some direction that TO_BE SAMPLED does not have?  What would that mean?  Instead is it this?
On entry, the function would check whether Y_INDICES has X,Z,T,E,F axes. For each of those, check whether TO_BE_SAMPLED has a similarly-directed axis in other than the Y direction, whose length differs from Y_INDICES, and if so raise an error. For any of X,Z,T,E,F that don't exist in Y_INDICES, inherit from TO_BE_SAMPLED.
I think we can do this, by having the grid inherited from TO_BE_SAMPLED except for the sample-direction.

Yes, INDICES could have one or more axes in directions that TO_BE_SAMPLED does not have.  (See for example my Test 3 above.)  A sample use case would be generating an XY field of random samples drawn from a 1-d distribution:
yes? let m_indices = 1+int(99*randu(x[gx=1:130:1]+y[gy=1:20:1]))
yes? let distribution = exp(0-(_e[ge=1:100:1]-50)^2 / 300)
yes? shade samplem_multi(distribution, m_indices)

I'm on the fence about whether the axis-matching should be exact, or just have the same length.  I'm leaning towards requiring an identical Ferret axis name (XAXIS_1 or whatever), since that'd help prevent mistakes by the user.  If needed, the user could just @ASN their indices onto the needed axes.
I've just edited the rules in my comment way up above, trying to make them clearer.  Copied here for convenience:
For SAMPLEM_MULTI(TO_BE_SAMPLED, M_INDICES):

The result M-axis should always be inherited from M_INDICES.  TO_BE_SAMPLED should have no influence on the result M-axis.

If M_INDICES has any Q-axes (where Q is any one of IJKLN), then the result also inherits those Q-axes of M_INDICES.  If TO_BE_SAMPLED has any of these same Q-axes, then they must match the corresponding Q-axes of M_INDICES; otherwise raise an error.

If TO_BE_SAMPLED has any Q-axes that are "normal" to the grid of M_INDICES, then the result will inherit those Q-axes from TO_BE_SAMPLED.  The result will be the same as if M_INDICES had been expanded by copying along those extra Q-axes of TO_BE_SAMPLED.

We could simplify the coding by just dropping rule (3), and raising an error if TO_BE_SAMPLED has any axes normal to M_INDICES.  Then we could just inherit everything from M_INDICES.  The user would just need to expand M_INDICES prior to calling the function, e.g. with:
yes? list samplem_multi(to_be_sampled, m_indices + 0*x[gx=to_be_sampled])

ok, this sounds good.
We do not have a good way to do both rule 2, inheriting from M_INDICES and also rule 3, inheriting any further axes from TO_BE_SAMPLED. Let's set the inheritance from argument 2.  If this is a major nuisance, we might be able to think of something else, but we do have Ferret syntax to define the expanded variables, and some good examples should take care of making this easy to use.
It turns out that we do not have to have a 1-point axis in the sample direction for the cases like
samplem_multi(a_mi, b_i)  were b_i is in the X direction and we're sampling in the E direction. The sampling action loops over the result axes that ARE present, and the indices of the second arguments and so it just works as we'd like:
yes?  sh func/details samplem_multi
SAMPLEM_MULTI(DAT_TO_SAMPLE,M_INDICES)
Returns data sampled according to M indices which may vary in IJKLN
Axes of result:
X: inherited from argument(s)
Y: inherited from argument(s)
Z: inherited from argument(s)
T: inherited from argument(s)
E: inherited from argument(s)
F: inherited from argument(s)
DAT_TO_SAMPLE: data to sample using M indices (FLOAT)
Influence on output axes:
X: no influence (indicate argument limits with "[]")
Y: no influence (indicate argument limits with "[]")
Z: no influence (indicate argument limits with "[]")
T: no influence (indicate argument limits with "[]")
E: no influence (indicate argument limits with "[]")
F: no influence (indicate argument limits with "[]")
M_INDICES: ordered indices (FLOAT)
Influence on output axes:
X: passed to result grid
Y: passed to result grid
Z: passed to result grid
T: passed to result grid
E: passed to result grid
F: passed to result grid
yes? set list/prec=0
yes? list a_2d
VARIABLE : A_1 + A_2
SUBSET   : 2 by 5 points (X-E)
0     1
1     2
11   / 1:  137.  130.
12   / 2:  160.  153.
13   / 3:  185.  178.
14   / 4:  212.  205.
15   / 5:  241.  234.
yes? list b_2
VARIABLE : 1+X[GX=SAX]
SUBSET   : 2 points (X)
0   / 1:  1.
1   / 2:  2.
yes? list  samplem_multi(a_2d, b_2)
VARIABLE : SAMPLEM_MULTI(A_2D, B_2)
SUBSET   : 2 points (X)
0   / 1:  137.
1   / 2:  153.
yes? show grid samplem_multi(a_2d, b_2)
GRID (G001)
name       axis              # pts   start                end                 subset
SAX       X                    2 r   0                    1                   full
normal    Y
normal    Z
normal    T

and, the sampling example where the grids don't match:

yes? list a_mi
VARIABLE : A_M + A_I
SUBSET   : 2 by 5 points (X-E)
0     1
1     2
11   / 1:  137.  130.
12   / 2:  160.  153.
13   / 3:  185.  178.
14   / 4:  212.  205.
15   / 5:  241.  234.
yes? list b_mi
VARIABLE : B_M + B_I - 1
SUBSET   : 2 by 4 points (X-E)
0   1
1   2
1   / 1:  4.  5.
2   / 2:  3.  4.
3   / 3:  2.  3.
4   / 4:  1.  2.
yes?  list samplei_multi(a_mi, b_mi)
Bailing out of external function "samplei_multi":
Grid of INDEX data must be subset of the grid of DATA_TO_SAMPLE. Arg-2 mismatch in E direction.
**ERROR: error in external function

Fantastic!  Just one thing: the SHOW FUNCTION in your example says
    DAT_TO_SAMPLE: data to sample using M indices (FLOAT)
        Influence on output axes:
          X: no influence (indicate argument limits with "[]")
          Y: no influence (indicate argument limits with "[]")
          Z: no influence (indicate argument limits with "[]")
          T: no influence (indicate argument limits with "[]")
          E: no influence (indicate argument limits with "[]")
          F: no influence (indicate argument limits with "[]")

But wouldn't we want the following, to ensure that any axes normal to M must be the same for both arguments?
    DAT_TO_SAMPLE: data to sample using M indices (FLOAT)
        Influence on output axes:
          X: passed to result grid
          Y: passed to result grid
          Z: passed to result grid
          T: passed to result grid
          E: no influence (indicate argument limits with "[]")
          F: passed to result grid

OK.  Actually if we inherit the grid from both variables and leave it up to Ferret to assemble the arguments, it will not enforce the requirement to have axes match, where present, from both grids. It will make the coordinates match, but look at this output.
Going back to the definitions from examples way above,
yes? def ax/e=11:15:1 eax_a; def ax/e=1:4:1 eax_b; def ax/x=0:1:1 xax
yes? let a_m = _e[ge=eax_a]^2; let a_i = (4-x[gx=xax])^2; let a_mi = a_m + a_i
yes? let b_m = 5-_e[ge=eax_b]; let b_i = 1+x[gx=xax]; let b_mi = b_m + b_i - 1

! define another axis that's too long,
yes? define axis/x=0:3:1 bigax
yes? let c_i = x[gx=bigax]
yes? let c_mi = b_m + c_i - 1

yes? list c_mi
             VARIABLE : B_M + C_I - 1
             SUBSET   : 4 by 4 points (X-E)
             0      1      2      3
             1      2      3      4
 1   / 1:  3.000  4.000  5.000  6.000
 2   / 2:  2.000  3.000  4.000  5.000
 3   / 3:  1.000  2.000  3.000  4.000
 4   / 4:  0.000  1.000  2.000  3.000
yes? list samplem_multi(a_mi, c_mi)
           *** NOTE: Ambiguous coordinates on X axis: SAMPLEM_MULTI(A_MI, C_MI)
             VARIABLE : SAMPLEM_MULTI(A_MI, C_MI)
             SUBSET   : 2 by 4 points (X-E)
             0      1
             1      2
 1   / 1:  185.0  205.0
 2   / 2:  160.0  178.0
 3   / 3:  137.0  153.0
 4   / 4:   ....  130.0

What's happened when it reports the "ambiguous coordinates", is that it's sent as ARG-2 the portion of the data whose coordinates match, as if it's a function on  x=0:1
so to enforce that the axes are the same, set the axes to be inherited only from the second argument, and the function will do the check to enforce that the axes are the same.
I am also working on the ability to expand data into the result as in the monte-carlo. That's doable but also doesn't just fall out of the standard looping we do in these functions.

Thank you!  Now I see -- I wasn't aware of how the dual-inheritance worked.  The default coordinate-matching behavior might be fine -- though I'd be a little worried about users calling the function with the wrong grid orientations or axis lengths, and getting an answer that they didn't expect.  We could try whichever way you think is best.

I'm going to go ahead and have the inheritance come from both DAT_TO_SAMPLE and INDICES.  Ferret can apply its test, and that includes making sure the coordinate data is consistent.  The functions check whether we're asking to do operations with completely wrong grids, such as a SAMPLEM_MULTI of a a X-Z variable in the T direction.
The use-case of generating Monte Carlo resamples of a dataset works great, and looks to be really cool.  I'm curious to hear how that works out.
Closing this and we'll get you a test version soon.

I'm testing the new implementation in v<IP_ADDRESS> and it's working quite well!  Just a few corner cases still left to fix.  First the setup, same as before:
 	NOAA/PMEL TMAP
 	FERRET v7.443 (optimized)
 	Linux 2.6.32-696.30.1.el6.x86_64 64-bit - 04/10/19
 	10-Apr-19 20:08

yes? def ax/e=11:15:1 eax_a; def ax/e=1:4:1 eax_b; def ax/x=0:1:1 xax
yes? let a_m = _e[ge=eax_a]^2; let a_i = (4-x[gx=xax])^2; let a_mi = a_m + a_i
yes? let b_m = 5-_e[ge=eax_b]; let b_i = 1+x[gx=xax]; let b_mi = b_m + b_i - 1

There's a set of degenerate cases for which A is normal to the sampling axis, so that the elements of b can only be 1 (otherwise the result should be missing).  Here they are...
Test 7:
yes? list/noh/p=1 a_i
 0   / 1:  16.
 1   / 2:   9.
yes? list/noh/p=1 b_m
 1   / 1:  4.
 2   / 2:  3.
 3   / 3:  2.
 4   / 4:  1.
yes? list samplem_multi(a_i, b_m)
             VARIABLE : SAMPLEM_MULTI(A_I, B_M)
             SUBSET   : 2 by 4 points (X-E)
               0          1
               1          2
 1   / 1:  2.368-310  2.368-310
 2   / 2:  2.609-321  1.581-322
 3   / 3:  6.713-316  0.000E+00
 4   / 4:  6.713-316  1.630-322

Here the result instead ought to be on the grid of a_i+b_m:
               0          1
               1          2
 1   / 1:    ....       ....
 2   / 2:    ....       ....
 3   / 3:    ....       ....
 4   / 4:     16.         9.

If the axis inheritance is an issue here, then we should just issue an error for Test 7, and ask the user to instead do the following (which works fine in v<IP_ADDRESS>):
yes? yes? list samplem_multi(a_i+esequence(0), b_m)
             VARIABLE : SAMPLEM_MULTI(A_I+ESEQUENCE(0), B_M)
             SUBSET   : 2 by 4 points (X-E)
             0      1
             1      2
 1   / 1:   ....   ....
 2   / 2:   ....   ....
 3   / 3:   ....   ....
 4   / 4:  16.00   9.00

Test 8:
yes? list/noh/p=1 a_i
 0   / 1:  16.
 1   / 2:   9.
yes? list/noh/p=1 b_i
 0   / 1:  1.
 1   / 2:  2.
yes? list/noh/p=1 samplem_multi(a_i,b_i)
 0   / 1:  16.
 1   / 2:   9.

But this is SAMPLEM_MULTI, not SAMPLEI_MULTI -- so instead the result ought to be:
 0   / 1:  16.
 1   / 2: ....

Again if the axis inheritance is a problem, then raise an error and ask the user to instead do:
yes? list/noh/p=1 samplem_multi(a_i+esequence(0),b_i)
 0   / 1:  16.
 1   / 2: ....

which also works fine in v<IP_ADDRESS>.
Test 9:
yes? list/noh/p=1 a_i
 0   / 1:  16.
 1   / 2:   9.
yes? list/noh/p=1 b_mi
 1   / 1:  4.  5.
 2   / 2:  3.  4.
 3   / 3:  2.  3.
 4   / 4:  1.  2.
yes? list/noh/p=1 samplem_multi(a_i,b_mi)
 1   / 1:   0.   0.
 2   / 2:   0.   0.
 3   / 3:   9.   0.
 4   / 4:  16.   9.

Instead the result should be:
 1   / 1: .... ....
 2   / 2: .... ....
 3   / 3: .... ....
 4   / 4:  16. ....

If axis inheritance is an issue then raise an error, and ask the user to instead do:
yes? list/noh/p=1 samplem_multi(a_i+esequence(0),b_mi)
 1   / 1: .... ....
 2   / 2: .... ....
 3   / 3: .... ....
 4   / 4:  16. ....

Test 10:
yes? list/noh/p=1 b_m
 1   / 1:  4.
 2   / 2:  3.
 3   / 3:  2.
 4   / 4:  1.
yes? list/noh/p=1 samplem_multi(1,b_m)
 1   / 1:  2.-310
 2   / 2:  2.-310
 3   / 3:  6.-317
 4   / 4:  6.-317

But the result instead ought to be:
 1   / 1:  ....
 2   / 2:  ....
 3   / 3:  ....
 4   / 4:  1.

If axis inheritance doesn't allow this, then raise an error and ask user to instead do:
yes? list/noh/p=1 samplem_multi(1+esequence(0),b_m)
 1   / 1:....
 2   / 2:....
 3   / 3:....
 4   / 4:  1.

Well, I can't see the logic behind sampling an X-variable {16, 9} using E coordinates {4,3,2,1} and having the result be
               0          1
               1          2
 1   / 1:    ....       ....
 2   / 2:    ....       ....
 3   / 3:    ....       ....
 4   / 4:     16.         9.

Why would it not be,
               0          1
               1          2
 1   / 1:    ....       ....
 2   / 2:    ....       ....
 3   / 3:    ....        9.
 4   / 4:     16.       ....

or this?,
            0     1
             1     2
 1   / 1:  ....  ....
 2   / 2:  ....  ....
 3   / 3:   9.   9.
 4   / 4:  16.  16.

This last is what my code is currently doing...
Can you say it  in words to help me see the operation?  "Sampling the x-variable onto the e axis by choosing ... "

In Test 7 we're sampling the M-indices of an I-variable (A_I).  Admittedly it's kinda dumb, but it might come up in a scripting context when  working with grids of arbitrary shape, so we should handle it consistently.
A_I is normal to the M-axis.  This is like there's only 1 valid M-index (M=1) along the M-direction of A_I, so that the only M-index that should produce a valid result is M=1.
So at x=0 (i=1) we're asking for M-indices {4, 3, 2, 1}, and the result is {..., ..., ..., 16}, directed along the M-axis of b_m.
At x=1 (i=2) we're asking for M-indices {4, 3, 2, 1}, so the result is {..., ..., ..., 9}, directed along the M-axis of b_m.
Does that make sense?

Hmm, I think so,  If it's this sampling,
yes? list/noh/p=1 a_i
 0   / 1:  16.
 1   / 2:   9.
yes? list/noh/p=1 b_m
 1   / 1:  4.
 2   / 2:  1.
 3   / 3:  2.
 4   / 4:  3.

the result would appear where the M index hits the value 1,
               0          1
               1          2
 1   / 1:    ....       ....
 2   / 2:     16.         9.
 3   / 3:    ....       ....
 4   / 4:    ....       ....

Exactly, that was my interpretation.
But now I'm wondering if that's the right interpretation.  An alternative would be that sampling along a "normal" axis could instead be valid for any index (not just 1), so that the result would be
yes? list/noh/p=1 a_i
 0   / 1:  16.
 1   / 2:   9.
yes? list/noh/p=1 b_m
 1   / 1:  4.
 2   / 2:  3.
 3   / 3:  2.
 4   / 4:  1.
yes? list samplem_multi(a_i, b_m)
             VARIABLE : SAMPLEM_MULTI(A_I, B_M)
             SUBSET   : 2 by 4 points (X-E)
               0          1
               1          2
 1   / 1:   16.   9.
 2   / 2:   16.   9.
 3   / 3:   16.   9.
 4   / 4:   16.   9.

That would seem to be more consistent with the existing Ferret behavior for sampling along a normal axis:
yes? list a_i[m=4]
             VARIABLE : {16,9}
             SUBSET   : 2 points (X)
 1   / 1:  16.00
 2   / 2:   9.00

What do you think?

I was going to say we'd need to do the alternative of forcing the user to spell it out,
list samplem_multi(a_i+esequence(0), b_m)
it just doesn't make sense in the way functions are computed to have it handle this gracefully.  Having it fill in the whole grid would be easier, maybe, but is it worth making the code more complex.
yes? list samplem_multi(a_i, b_m)

Bailing out of external function "samplem_multi":
        Add an E axis to ARG1
 **ERROR: error in external function

yes?  list samplem_multi(a_i+esequence(0), b_m)
             VARIABLE : SAMPLEM_MULTI(A_I+ESEQUENCE(0), B_M)
             SUBSET   : 2 by 4 points (X-E)
            0    1
            1    2
 1   / 1: .... ....
 2   / 2: .... ....
 3   / 3: .... ....
 4   / 4:  16.   9.

yes?  list samplem_multi(a_i+0*b_m, b_m)
             VARIABLE : SAMPLEM_MULTI(A_I+0*B_M, B_M)
             SUBSET   : 2 by 4 points (X-E)
            0    1
            1    2
 1   / 1:  16.   9.
 2   / 2:  16.   9.
 3   / 3:  16.   9.
 4   / 4:  16.   9.

I agree, it's probably best to have the user spell it out explicitly.  So Ferret can just issue an error for Tests 7-10 -- preferably in a way that educates the user on how to address it.

Yes, if these are cases where we don't know what makes sense, and they might just stem from somebody making a mistake in the call, then get them to say what they want to do.  The error messages say,
Bailing out of external function "samplem_multi":
        ARG1 has no E-axis. Add E dimension to ARG1, e.g.  DAT_TO_SAMPLE + 0*var_on_e

We can also have examples in the docs.
By the way the example above of the monte-carlo simulation is sampling in E from an X, (or XYZ  or whatnot) grid that doesn't have E.  There, the E axis is the same length as an axis of the grid so it's clear what to do.  I just find the first axis whose length agrees.
This is done and yet more tests added.

That error message looks great, thanks.
As for the Monte Carlo example: "guessing" an axis based just on length would be too risky, since two or more axes could easily have the same length.  Better to keep it simple and foolproof.
And besides, I've just realized that for the Monte Carlo example the user could have gotten the desired result by simply using SAMPLEI_MULTI instead of SAMPLEM_MULTI.  So that actually eliminates the use case that I had suggested for INDICES having one or more axes in directions that TO_BE_SAMPLED does not have.  I've also fixed some formulation errors in that example, and made a plot:
yes? let data = {5,9,2,3,7,4,8,9,1,0,3,6,4,8,8,2}
yes? let ni = `data,r=isize`; let nm = 1e5; let mvals = _m[m=1:`nm`]
yes? let i_indices = 1 + int(ni * randu(x[gx=data,i=1:`ni`]+mvals))
yes? let bootstrap_resamples = samplei_multi(data+0*i_indices, i_indices)
yes? let bootstrap_means = bootstrap_resamples[i=@ave]
yes? plot/vs/line (mvals-1)/(nm-1), samplem(bootstrap_means,sortm(bootstrap_means))
yes? plot/ov/vs/line=2 {0,`nm`}, data[i=@ave]*{1,1}
yes? list/noh data[i=@ave], bootstrap_means[m=@ave]

The LIST shows that the mean-of-sample-means matches the original mean.  The plot shows the "quantile function" (inverse of the cumulative distribution function) for the mean; this is the ranked set of possible means (horizontal stairsteps) obtained by 100,000 random resamples of the original dataset.

That's much better if we can insist that the DAT_TO_SAMPLE has an axis in the direction of INDICES.  It makes the code cleaner, and it'll be easy to write clear documentation.  I'll make that change.

Ok, this is all done.  The functions require that both arguments have a grid with an axis in the sample-direction.


Markup failure for org.openrewrite.maven.AddRuntimeConfig generation

https://docs.openrewrite.org/recipes/maven/addruntimeconfig doesn't correctly render the separator options:

Thanks for the report! Fixed and docs re-generated with the fix.


fixup: pip default version in pip module

Took me a while that i needed a flake lock --override-input dream2nix  ofc, as the invalidationHash does include pipVersion.


Cannot run perception_lowcost_vis.sh.

Hello, and thanks for all the great work done on this framework.
I am trying to implement perception_lowcost_vis.sh.
I took the content from perception.sh as an example and ended up with:
cyber_launch start /apollo/modules/transform/launch/static_transform.launch &
cyber_launch start /apollo/modules/drivers/tools/image_decompress/launch/image_decompress.launch &
cyber_launch start /apollo/modules/perception/production/launch/perception_lowcost.launch &
The content of  perception_lowcost.launch is the following:

cyber modules list config
1.0.0

perception_camera
/apollo/modules/perception/production/dag/dag_streaming_perception_camera.dag
perception
1.0.0

<module>
    <name>perception_lane</name>
    <dag_conf>/apollo/modules/perception/production/dag/dag_streaming_perception_lane.dag</dag_conf>
    <process_name>perception_lane</process_name>
    <version>1.0.0</version>
</module>

<module>
    <name>perception_traffic_light</name>
    <dag_conf>/apollo/modules/perception/production/dag/dag_streaming_perception_trafficlights.dag</dag_conf>
    <process_name>perception_trafficlights</process_name>
    <version>1.0.0</version>
</module>

<module>
    <name>motion_service</name>
    <dag_conf>/apollo/modules/perception/production/dag/dag_motion_service.dag</dag_conf>
    <!-- if not set, use default process -->
    <process_name>motion_service</process_name>
    <version>1.0.0</version>
</module>

When running, I can see the lane detection working but I also got an error:
[perception_lane]  E0715 15:47:34.780052 12105 debug_info.cc:299] [mainboard] Failed to query camera to ground height and pitch.
I tried debugging it with gdb by running:
$ gdb mainboard
(gdb) run -d /apollo/modules/perception/production/dag/dag_streaming_perception_camera.dag -p perception -s CYBER_DEFAULT
I ended up with the following error which I don't know how to solve:
mainboard: cudnnBuilder2.cpp:1006: nvinfer1::cudnn::Engine* nvinfer1::builder::buildEngine(nvinfer1::CudaEngineBuildConfig&, const nvinfer1::cudnn::HardwareContext&, const nvinfer1::Network&): Assertion `it != tensorScales.end()' failed.
I just started to learn how this framework. Do you have any idea on what I am doing wrong?
Thanks!

Solved the problem by using:

perception_camera
/apollo/modules/perception/production/dag/dag_streaming_perception_camera.dag
perception
1.0.0

instead of dag_streaming_perception_lane (I found out that the functionality is included in dag_streaming_perception_camera alongside obstacle detection).
I also change in config.pt from "modules/perception/production/data/perception/camera/params"
model_type: "CaffeNet".
For some reason, the default quantized int8 networks using tensorRT triggers the error above.

Closed due to inactivity. If the problem persists, pls feel free to reopen it or create a new one and refer to it.


Return throwing native validation issue for Chrome

When pressing "return" on the keyboard, instead of submitting the form the element is showing this: http://drop.subbly.co/0e3e3R053B24
Any ideas what we can do, it's jarring in the UX. The input is correct because when I manually trigger the token generation it works. And I've tried multiple times.

Hi @jez it seems to be unpredictable.
When I opened dev tools and put it into mobile responsive mode this is what happened:
http://drop.subbly.co/3u3Y3U0X0Q1z
Works fine in non-mobile responsive mode

It looks like this is an issue with your particular checkout form. In particular, I imagine you're setting a required attribute on the HTML element, but without seeing the source, it's hard to tell for sure.
If you need help debugging what's up, definitely reach out to our support team!

https://support.stripe.com/email, or
#stripe on freenode

Since this repo is for examples of Elements usage and bugs in these particular examples, I'm going to close this.


⚠ Living Word Church has degraded performance

In 318f8a9, Living Word Church (https://livingword.org.au) experienced degraded performance:

HTTP code: 404
Response time: 12333 ms

Resolved: Living Word Church performance has improved in 47f4f32 after 2 hours.


Data resurrection when recreating formerly destroyed index

After index destruction, the data in corresponding keyspace and tables are kept.
While recreating the index, former data is restored.
Expected behaviours, only the new data is available.
Note: Elassandra is used as an Elasticsearch implementation.
Script to reproduce:
https://gist.github.com/jxerome/f8244f5eaa9725e0629f18b43ad5eaad

Hi,
This is the default expected behavior, cassandra is your persistent primary data storage.
If you want to delete cassandra keyspace/table when deleting an Elasticsearch index (to use Elassandra as an Elasticsearch implementation), set the drop_on_delete_index parameter at the cluster or index level, as described in Elassandra doc.
Thanks.

OK, I don't see how I can easily set that parameter when strating the docker container.

Maybe you can run elassandra with the JVM option -Des.drop_on_delete_index=true ?

Le 11 août 2017 à 15:07, Jérôme Mainaud<EMAIL_ADDRESS>a écrit :
OK, I don't see how I can easily set that parameter when strating the docker container.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub https://github.com/strapdata/elassandra/issues/108#issuecomment-321807312, or mute the thread https://github.com/notifications/unsubscribe-auth/AJzHmd3d78YjyJvv_WfchGfa5rFK7Zahks5sXFH2gaJpZM4O0mwC.

Yes, the exact command is :
docker run -d -P -e "JVM_OPTS=-Des.drop_on_delete_index=true" strapdata/elassandra


breaking: InterestManagement part 1 - untangling

Interest Management preview for internal discussion.
=> NetworkIdentity.observers remains
=> Everything else untangled and moved into InterestManagement component
Note that this is part 1.
After untangling, we can consider inverting the broadcasting logic from pushing all entities to all player connections, to pulling all entities from all player connections.
Benefits:

We can finally support spatial hashing (aka grid checker) properly
Spatial hashing is a LOT faster than Mirror's built in (30x in an old test years ago)
Works fine in 'x' branch & dotsnet.
Note that we lose the guarantee that all observers are spawned when OnStartClient is called. This never worked 100% and it doesn't make sense to begin with. After starting, things spawn and despawn in no particular order constantly anyway.

When reviewing:

See how NetworkIdentity Rebuild insanity was finally removed. This was arguably the worst part of Mirror.
Notice InterestManagement.cs - the base class with helper functions and RebuildAll()
Notice BruteForceInterestManagement = our previous method, just cleaner
Notice SpatialHashingInterestManagement = grid checker

Work in progress.

need to support host mode
need to add tests for new interest management, grid2d, etc.
need to adjust examples' custom checkers like rooms
need to rename 'observersx' to 'observers' again later

It'd be good if the proximity checker itself could provide which observers are new/removed (which is pretty simple with a grid-style checker), saves iterating over observers twice if the proximity checker supports it
Another thing the api should have is a way for the proximity checker to work async and provide results at a later time (for example: launch a proximity check job, get results next frame)

Solid start.
Here is some feedback

Some objects are global and should be seen by everyone,  for example,  consider an in-app purchase system that networks the store, or maybe a chatroom object. In the current system, you do that by not adding a NetworkProximityChecker.  In the new system... how do you do that?
I really like the fact that you don't keep the grid as a singleton, the code is clean, testable, and easy to understand
add some tests?
maybe later we can do incremental updates? in areas where everyone is together this algorithm is still O(n^2) every few seconds,  If we do incremental updates we can make it so in any particular frame the worst case is O(n).  No rush,  this can be done in other prs.
Tests are failing

TODO remake match and scene checker before merging

I've made a little proof of concept of a lazy updating spatial hashing system, its a bit rough around the edges still (see "Improvements" below), but should get the point across
What does it do?
Tracks in what grid tile entities are in and updates observers on both sides (what entities it sees and connections seeing it) if it's grid position changes
Check it out here in the AOIBenchmark example (you'll likely have to setup the transport): https://github.com/imerr/Mirror/tree/interestmanagement_part1_untangle
Changes: https://github.com/imerr/Mirror/commit/f597bef63895708277b75e4d34fd26933cd14502
The benchmark setup consists of a flat world, where monsters and players are spawned across randomly within a specified range
They move randomly and change their move directions randomly (all server side)
100 players, 5000 mobs, -1000 to +1000 xz range, 100 vis range (~50 mobs/player):
EDITOR ORIGINAL ~14ms https://share.dl.je/2021/01/2021-01-04_08-11-36_C9ZUTf2aZs.png
EDITOR MINE ~4ms https://share.dl.je/2021/01/2021-01-04_08-07-04_0ADvtW05a0.png
BUILD ORIGINAL ~5ms https://share.dl.je/2021/01/2021-01-04_08-14-25_KhSrY8i3fT.png
BUILD MINE ~1ms https://share.dl.je/2021/01/2021-01-04_08-09-35_ylSJylT5yc.png
100 players, 10k mobs, -500 to +500 xz range, 100 vis range:
EDITOR ORIGINAL ~52ms https://share.dl.je/2021/01/2021-01-04_08-01-23_bsDcAVBhEs.png
EDITOR MINE ~15ms https://share.dl.je/2021/01/2021-01-04_07-57-59_aawNClEsM9.png
BUILD ORIGINAL ~15ms https://share.dl.je/2021/01/2021-01-04_08-03-30_VdnxAtDF2r.png
BUILD MINE ~4ms https://share.dl.je/2021/01/2021-01-04_08-05-48_iDdh8yuSWp.png
So that's a ~3.5x improvement across the board, with less players the numbers are slightly worse, still seeing a ~2.5x improvement with 10 players (last benchmark) though
Improvements:
InterestManagement should inform the inherited class about new/removed networked objects so we don't need external components to track state
External InterestManagement.RebuildAll should be removed and instead be called with specific methods mentioned above (its currently only called externally when players are removed)
Benchmark the choice of containers more thouroughly
I probably haven't followed all the code style mirror uses, didn't really want to learn that for a quick mock-up
It might be faster to have two lists per tile, one for objects and one for connections - would need profiling though
NetworkIdentity.rebuild shouldn't be part of the NetworkIdentity, but live on the InterestManagement if needed (although this isnt exactly related)

I've made a little proof of concept of a lazy updating spatial hashing system, its a bit rough around the edges still (see "Improvements" below), but should get the point across
What does it do?
Tracks in what grid tile entities are in and updates observers on both sides (what entities it sees and connections seeing it) if it's grid position changes
Check it out here in the AOIBenchmark example (you'll likely have to setup the transport): https://github.com/imerr/Mirror/tree/interestmanagement_part1_untangle
Changes: https://github.com/imerr/Mirror/commit/f597bef63895708277b75e4d34fd26933cd14502
The benchmark setup consists of a flat world, where monsters and players are spawned across randomly within a specified range
They move randomly and change their move directions randomly (all server side)
100 players, 5000 mobs, -1000 to +1000 xz range, 100 vis range (~50 mobs/player):
EDITOR ORIGINAL ~14ms https://share.dl.je/2021/01/2021-01-04_08-11-36_C9ZUTf2aZs.png
EDITOR MINE ~4ms https://share.dl.je/2021/01/2021-01-04_08-07-04_0ADvtW05a0.png
BUILD ORIGINAL ~5ms https://share.dl.je/2021/01/2021-01-04_08-14-25_KhSrY8i3fT.png
BUILD MINE ~1ms https://share.dl.je/2021/01/2021-01-04_08-09-35_ylSJylT5yc.png
100 players, 10k mobs, -500 to +500 xz range, 100 vis range:
EDITOR ORIGINAL ~52ms https://share.dl.je/2021/01/2021-01-04_08-01-23_bsDcAVBhEs.png
EDITOR MINE ~15ms https://share.dl.je/2021/01/2021-01-04_07-57-59_aawNClEsM9.png
BUILD ORIGINAL ~15ms https://share.dl.je/2021/01/2021-01-04_08-03-30_VdnxAtDF2r.png
BUILD MINE ~4ms https://share.dl.je/2021/01/2021-01-04_08-05-48_iDdh8yuSWp.png
So that's a ~3.5x improvement across the board, with less players the numbers are slightly worse, still seeing a ~2.5x improvement with 10 players (last benchmark) though
Improvements:
InterestManagement should inform the inherited class about new/removed networked objects so we don't need external components to track state
External InterestManagement.RebuildAll should be removed and instead be called with specific methods mentioned above (its currently only called externally when players are removed)
Benchmark the choice of containers more thouroughly
I probably haven't followed all the code style mirror uses, didn't really want to learn that for a quick mock-up
It might be faster to have two lists per tile, one for objects and one for connections - would need profiling though
NetworkIdentity.rebuild shouldn't be part of the NetworkIdentity, but live on the InterestManagement if needed (although this isnt exactly related)

status update for this PR:

we should definitely not do this for LTS
for 2021 version we might, or might not. the built in system isn't so bad all things considered, because it allows local rebuilds. closing this for now.

status update for this PR:

we should definitely not do this for LTS
for 2021 version we might, or might not. the built in system isn't so bad all things considered, because it allows local rebuilds. closing this for now.


File List Epic

The Issue
All file list related issues. Depending on the upcoming file list discussion, some of these may fall out.
System Configuration

LBRY Daemon version:
LBRY App version:
LBRY Installation ID:
Operating system:

Anything Else

Screenshots

Internal Use
Acceptance Criteria

Definition of Done

[ ]  Tested against acceptance criteria
[ ] Tested against the assumptions of user story
[ ] The project builds without errors
[ ] Unit tests are written and passing
[ ] Tests on devices/browsers listed in the issue have passed
[ ] QA performed & issues resolved
[ ] Refactoring completed
[ ] Any configuration or build changes documented
[ ] Documentation updated
[ ] Peer Code Review performed

@shyba pointed out that storing the files in memory is expensive and time-consuming, is this something we would want to look into?


Supporting Ruby 3.1 and Rails 7.x

Hi,
I'm trying to upgrade a Ruby on Rails application from 2.x to 3.1. As a result of this upgrade I also need to upgrade Rails to 7.x (see https://gist.github.com/yahonda/2776d8d7b6ea7045359f38c10449937b#rails-70z or https://www.fastruby.io/blog/ruby/rails/versions/compatibility-table.html).
My current problem is that devise_security_extension supports rails up to version 6.0.3 (by depending on railties 6.0.3).
Is there a plan to support higher versions of ruby/rails?

moved to work with https://github.com/devise-security/devise-security

Hi @AryeShemesh, now need to replace with gem 'devise-security'?

@AryeShemesh ok


Mistral ollama function calling not supported warning

my config is using the filesystem mcp server distributed officially via their github:
{
  "mcpServers": {
    "filesystem": {
      "command": "npx",
      "args": [
        "-y",
        "@modelcontextprotocol/server-filesystem",
        "/tmp"
      ]
    }
  }
}

the interaction is as follows (I entered /tools and /servers)
 ~/source/prac/MCP/mcp-golang  base  130 ❯ mcphost ollama --model mistral --config ./mcphost-config.json
2024/12/19 18:41:13 INFO Initializing server... name=filesystem

Warning: Model mistral does not support function calling. Tools will be disabled.

    Tools are currently disabled for this model.

      # filesystem

      Command npx

      Arguments -y @modelcontextprotocol/server-filesystem /tmp

┃ Enter your prompt (Type /help for commands, Ctrl+C to quit)
┃
┃
┃
┃
┃
┃

alt+enter / ctrl+j new line • ctrl+e open editor • enter submit

the model being mistral:7b https://ollama.com/library/mistral:7b

did you find a good model?

Try granite3.1-dense:

still facing the same issue

I tried a similar tool https://github.com/chrishayuk/mcp-cli with ollama:llama3.2 and it works

Not sure what I might be missing with mcp-host


Unsubscribe in onDestroy()

I think the code hides a potential issue that might appear with a minor change to the requirements.
It calls Butterknife.unbind() in onDestroyView(). Also it calls view methods from Subscriber and unsubscribes in onDestroy(). If one of Subscriber's callbacks is called between onDestroy() and onDestroyView() we will get a NPE.
I think it's not possible to reproduce the issue in this particular sample. Howerver, in a more complicated application that is using fragments' backstack it might be a problem.

you are welcome to push a PR for these matters.

@Trikke I wanted to know first if the author had any reasons to implement it like this

I think the code hides a potential issue that might appear with a minor change to the requirements.

My requirements were those so I didn't want to overthink here. Also there is no NPE.

I think it's not possible to reproduce the issue in this particular sample. Howerver, in a more complicated application that is using fragments' backstack it might be a problem.

If we cannot reproduce the problem, it does not make sense to fix something that does not exist right? If you can give an example, maybe we can work it out. Also as @Trikke suggested, any PR is very welcome.

@android10, I believe that it's a complicated issue that must be discussed before any PR.
People use this repository as a base for their own projects and it would be good to keep it as general as possible.
The easiest way to have NPE that comes to my mind is to use fragments-backstack (sometimes you just have to use it):

Open fragment
Subscribe on an observable that is performing a web-request
Open another fragment and put the current to the backstack.
Now the system can call onDestroyView() in the first fragment. If so, Butterknife.unbind() is called inside it and all views' references are null now.
The web-request is completed and onNext() is called. It wants to update the views but they are null. NPE is thrown.

I believe there're other situations when onDestroyView() is called not followed by onDestroy(), e.g. detaching the fragment manually. So in general you can't rely on the fact that onDestroyView() and onDestroy() are always called together.
If this architecutre is designed to be used only with "one activity - one fragment" approach, then it would be great to write it somewhere.

@shchurov I agree!

@shchurov I understand, that is why PRs are welcome. This example was not meant to cover everyone's needs and approaches, it was mainly for learning purpose and discussions. For instance if you consider there is a path for improvement, I encourage you to move forward and send a PR so we can review it.  :smiley:

i'll just make a small comment here, unrelated to this possible PR. But it's something i've seen come up a lot on this issue tracker.
I'd like to point out that you shouldn't base your own projects entirely on this repository. By which i mean that this repository should be seen as an example from @android10 on how to implement the Clean Architecture principles into your own work. I think it's wrong to go about copy-pasting this repository, remove some of @android10's app logic that you don't need and move on with your own code from there.
Of course this example repository won't cover everyone's use cases and every edge case out there. And i doubt the creator has the time to factor in ever little detail. It is just an example to showcase the architecture, not some holy codebase that screams "this is how it is done and stick to it".
Your own implementation and codebase could (and probably should) end up to be a whole lot different depending on your own scope. But the overarching principles should be the same. If you create your own project based on these, i should be able to understand it immediatly. But it could incorporate entirely different things and take care of edge cases that matter to you.


DBZ-7830 Debezium JDBC Sink not handle order of record correctly

@DLT1412 Thanks for the PR. COuld you please update the commit message as it does not have any title but Jira identifier. It should be like DBZ-7830 Text...


Feature/toolbar hide

Codecov Report

Merging #6 into master will decrease coverage by 0.02%.
The diff coverage is 0%.

@@            Coverage Diff            @@
##           master      #6      +/-   ##
=========================================
- Coverage    1.61%   1.58%   -0.03%
=========================================
  Files          11      11
  Lines          62      63       +1
  Branches        6       6
=========================================
  Hits            1       1
- Misses         59      60       +1
  Partials        2       2

Impacted Files
Coverage Δ

src/pages/Login.vue
0% <0%> (ø)
:arrow_up:

src/App.vue
0% <0%> (ø)
:arrow_up:

Continue to review full report at Codecov.

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


0.10.3 compatibility

Looking at its release date (7th of February), it seems that release 0.10.3 and next are compatible with node 0.12.0 (released 6th of February) because they don't work anymore with node 0.10.0 to me.
Is it the proper behavior?
Can it be documented to avoid confusion?
Thanks.

We should still be compatible with node 0.10. Could you be a little more specific in what is not working? Thanks.

@yamsellem The tests pass for 0.10.37 so we know that much at least :) (https://travis-ci.org/rvagg/node-leveldown#L225)

@yamsellem Please post the output of: node -v and npm -v and the error output you get.

@ralphtheninja sorry for the delay. I've test it again and do not encountered any issue. I should have been wrong then (and I cursed myself for the absolute lack of detail of my first post). I'll post here if I find more.

:+1:


Multistep form : validation only on a subset of fields

Hi
I have a multi step form created using hide and show of div tags. On click of the next button on the first step, I want to validate only the fields that are present on that step.
Right now, teh validations are working but the user can progress to the next step without entering all the values in the step.
Is that possible using client_side_validations?
Thanks
Neha

Hi,
I have used:
$('form#new_reply[data-validate]:textarea').isValid(new_reply.validators);
in order to not have the validation of my textarea until a click on a link to display the corresponding fields of the form.
new_reply iis the id of the form.
Thx a lot


[tracking] Change team name in insights-results-aggregator-utils repository

Change team name in insights-results-aggregator-utils repository

Updated via https://github.com/RedHatInsights/insights-results-aggregator-utils/pull/218


[5.1] Fixed aggregate queries

Can you describe whats going on here?

I like that you try to do something with my earlier comments in #14781 but really doubt if we should go this way. Has there been any practical issues with aggregate how it always behaved?

Yeh, it'll break if you have strict types turned on and you were expecting a float instead of a string without these changes.

Ah, in a PHP 7 context that makes sense. With formattedAggregate having been changed to numericalAggregate this is then okay with me.

I might have posted a comment in the wrong place.
I have issues since this change with the min and max method. I am trying to get the maximum value if a date time field like 2016-08-24 00:00:00, but the max() method only returns 2016. Is this the expected behavior and if so, how to get the min and max values of a date time field?

Basically reverted this.


dependency_overrides cannot be used in tests as expected, documentation lacking

Describe the bug
Without fastapi-versioning, dependency_overrides can easily be specified on the app contained in the TestClient a la (pytest fixture like pseudo code):
before = client.app.dependency_overrides
client.app.dependency_overrides = dict(overrides)
try:
    yield
finally:
    client.app.dependency_overrides = before

With the internal use of sub application mounts, this doesn't work anymore and the override never reaches one of the versioned sub applications.
To Reproduce
Steps to reproduce the behavior:
from fastapi import APIRouter, Depends, FastAPI
from fastapi.testclient import TestClient
from fastapi_versioning import versioned_api_route, VersionedFastAPI

app = FastAPI(title="test-app")
router = APIRouter(route_class=versioned_api_route(1, 0))

def dependency() -> str:
    return "original"

@router.get("/test")
def get_test(dep: str = Depends(dependency)) -> str:
    return dep

app.include_router(router)
app = VersionedFastAPI(app)

def test_this() -> None:
    client = TestClient(app)
    client.app.dependency_overrides = {dependency: lambda: "patched"}
    assert client.get("/v1_0/test").json() == "patched"

This test will fail
Expected behavior
It should at least be documented how to access the correct sub application for providing the dependency_overrides.

Hello there...
Having the same issue here. Spent literally two days of trying to make tests work, to realize it's because of VersionedAPI... :(
Anyone managed to find a workaround? It's basically impossible to attach a test database for testing purposes.
Thanks!

I was running into the same issue and realized it's caused by the order of operations:

You create a FastAPI app
You add routes with dependencies
You create a VersionedFastAPI from the original app
VersionedFastAPI creates a whole new FastAPI app (the versioned app) and for each version number, it takes all the routes from your original app that match that version number and attaches them to a new sub-app mounted on the versioned app
You get back the versioned app
You make a request to the versioned app

The issue is when you create the routes in step 2, they are "compiled" and still reference the original FastAPI app from step 1 even when the dependencies are resolved when you make a request in step 6, so you have to add the dependency overrides to the original app:
from fastapi import APIRouter, Depends, FastAPI
from fastapi.testclient import TestClient
from fastapi_versioning import versioned_api_route, VersionedFastAPI

original_app = FastAPI(title="test-app")
router = APIRouter(route_class=versioned_api_route(1, 0))

def dependency() -> str:
    return "original"

@router.get("/test")
def get_test(dep: str = Depends(dependency)) -> str:
    return dep

original_app.include_router(router)
app = VersionedFastAPI(original_app)

def test_this() -> None:
    client = TestClient(app)
    original_app.dependency_overrides = {dependency: lambda: "patched"}
    assert client.get("/v1_0/test").json() == "patched"


Rewrite match loop communicator unit test to gtest.

@geirst : please review

I am not sure it makes sense to rewrite this as multi-threaded tests with TEST_MT_F() is simpler with the old test framework. @havardpe please take a look.


Support for pathlib.Path in datasets 2.19.0

Describe the bug
After the recent update of datasets, Dataset.save_to_disk does not accept a pathlib.Path anymore. It was supported in 2.18.0 and previous versions. Is this intentional? Was it supported before only because of a Python dusk-typing miracle?
Steps to reproduce the bug
from datasets import Dataset
import pathlib

path = pathlib.Path("./my_out_path")
Dataset.from_dict(
    {"text": ["hello world"], "label": [777], "split": ["train"]}
.save_to_disk(path)

This results in an error when using datasets 2.19:
Traceback (most recent call last):
  File "<stdin>", line 3, in <module>
  File "/Users/jb/scratch/venv/lib/python3.11/site-packages/datasets/arrow_dataset.py", line 1515, in save_to_disk
    fs, _ = url_to_fs(dataset_path, **(storage_options or {}))
            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/Users/jb/scratch/venv/lib/python3.11/site-packages/fsspec/core.py", line 383, in url_to_fs
    chain = _un_chain(url, kwargs)
            ^^^^^^^^^^^^^^^^^^^^^^
  File "/Users/jb/scratch/venv/lib/python3.11/site-packages/fsspec/core.py", line 323, in _un_chain
    if "::" in path
       ^^^^^^^^^^^^
TypeError: argument of type 'PosixPath' is not iterable

Converting to str works, however.
Dataset.from_dict(
     {"text": ["hello world"], "label": [777], "split": ["train"]}
).save_to_disk(str(path))

Expected behavior
My dataset gets saved to disk without an error.
Environment info
aiohttp==3.9.5
aiosignal==1.3.1
attrs==23.2.0
certifi==2024.2.2
charset-normalizer==3.3.2
datasets==2.19.0
dill==0.3.8
filelock==3.14.0
frozenlist==1.4.1
fsspec==2024.3.1
huggingface-hub==0.23.2
idna==3.7
multidict==6.0.5
multiprocess==0.70.16
numpy==1.26.4
packaging==24.0
pandas==2.2.2
pyarrow==16.1.0
pyarrow-hotfix==0.6
python-dateutil==2.9.0.post0
pytz==2024.1
PyYAML==6.0.1
requests==2.32.3
six==1.16.0
tqdm==4.66.4
typing_extensions==4.12.0
tzdata==2024.1
urllib3==2.2.1
xxhash==3.4.1
yarl==1.9.4

+1 I just noticed this when I tried to update datasets today.


Get Profile Image

@jasonash I used your form  at http://strabospot.org/profileimageupload to upload a profile image however when it directs me to http://strabospot.org/db/profileimage I get
{
Error: "ID must be provided. "
}

I am unable to duplicate the error. Have you tried visiting this link in a browser? It seems to work correctly for me.
From: Jessica Good <notifications<EMAIL_ADDRESS>Reply-To: StraboSpot/strabo-server <reply<EMAIL_ADDRESS>Date: Tuesday, March 1, 2016 at 4:41 PM
To: StraboSpot/strabo-server <strabo-server<EMAIL_ADDRESS>Cc: Jason Ash <jasonash<EMAIL_ADDRESS>Subject: [strabo-server] Get Profile Image (#29)
@jasonashhttps://github.com/jasonash I used your form at http://strabospot.org/profileimageupload to upload a profile image however when it directs me to http://strabospot.org/db/profileimage I get
{
Error: "ID must be provided. "
}

Reply to this email directly or view it on GitHubhttps://github.com/StraboSpot/strabo-server/issues/29.

Fixed by @jasonash


Set option 'arm_64bit' in config.txt

When I worked on lesson1, I installed Raspbian Buster(release date 2019-09-26). There are 3 kernel image under boot partition: kernel.img(32bit older RPI), kernel7.img(32bit RPI2&3) and kernel7l.img(32-bit RPI4).
After I deleted kernel7.img, copy kernel8.img, modified config.txt according to the tutorial and boot my Pi 3b, no UART message was printed. However, when I deleted all kernel*.img except kernel8.img, it worked. I searched the Internet for a while and couldn't figure out why. Maybe the latest firmware has changed the boot sequence?
Then I saw the arm_64bit option in the official document.

arm_64bit
If set to non-zero, forces the kernel loading system to assume a 64-bit kernel, starts the processors up in 64-bit mode, and sets kernel8.img to be the kernel image loaded, unless there is an explicit kernel option defined in which case that is used instead. Defaults to 0 on all platforms. NOTE: 64-bit kernels must be uncompressed image files.
Note that the 64-bit kernel will only work on the Pi4, Pi3, and Pi2B rev1.2 boards with latest firmware.

I tried it and it worked well without deleting any other kernel*.img.  Maybe setting arm_64bit option is a better choice for current firmware?

Thanks, @legendlc for reporting this.
I made a fix in this commit.
I prefer to add instructions to delete all 'kernel*img' files rather than use the arm_64bit option because I am not sure how this option is going to work with different versions of Raspberry Pi boards as well as different firmware versions. Deleting all kernel*.img files looks like a more reliable way to me. Also, default config.txt is used in a lot of different places (source of all lessons, exercises, translations, etc) and updating all of them could be painful


Library name change request

Library repository URL
https://github.com/hardmax/ADS1232

Hi @hardmax. I am confirming your request.
Unlike submissions, this type of request is still handled manually. The Library Manager index maintainer occasionally comes through to clear all the outstanding requests. They will close this issue when it is done. You will get a notification from GitHub at that time.
After that, you can monitor the indexing of the library via its dedicated logs web page.
Information about that here:
https://github.com/arduino/library-registry/blob/main/FAQ.md#can-i-check-on-library-releases-being-added-to-library-manager

solved in https://github.com/arduino/library-registry/pull/1548#issuecomment-1178707394


Center nvy window on startup

Center nvy window on startup
Modify several consecutive spaces to tab

I don't think centering should be the default and I would prefer to rely on the default Windows positioning. I suppose if it is a desired feature we can make it a startup flag. Feel free to make a PR that does so, I will merge it. And sorry for the very long response time.


Update Retrieve-Alert-data.yml

Docs Build status updates of commit ceceec5:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

docs-ref-autogen/operationsmanager/Data/Retrieve-Alert-data.yml
:white_check_mark:Succeeded

For more details, please refer to the build report.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
For any questions, please:Try searching the docs.microsoft.com contributor guidesPost your question in the Docs support channel

#sign-off

Docs Build status updates of commit ceceec5:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

docs-ref-autogen/operationsmanager/Data/Retrieve-Alert-data.yml
:white_check_mark:Succeeded

For more details, please refer to the build report.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
For any questions, please:Try searching the docs.microsoft.com contributor guidesPost your question in the Docs support channel


BlockingQueue implementation and other interfaces

I quickly build a BlockingQueue<byte[]> (gist here) based on the QueueFile for a project where I intend to use tape as an offline buffer/resend queue in case the uplink goes down. I could have just build the minimal wrapper I needed, but I though "why not just implement BlockingQueue and see if someone else thinks it's useful?"
This made me wonder why none of Java's standard queuing interfaces have implementations here. Is there a specific reason for that?
If this is need interesting I can submit a PR for the BlockingQueue and implementations of Queue as well.

The main reason is that the queue is not safe for concurrent interaction. A quick glance at the BlockingQueue docs and your gist makes it seem like you are not fulfilling the contract of the interface:

BlockingQueue implementations are thread-safe.

All operations to the backing QueueFile are synchronized, so there is no concurrent access to the QueueFile (unless of course someone shares the QueueFile instances to other places). This is similar to the ArrayBlockingQueue which synchronizes every operation to the backing array.
I've missed the locking in the add() method, but that's fixed locally.

Ah, haha. The add method was the only one I looked at!
I don't think I'm opposed to adding this if you're willing to send a PR and write tests.


link command created

Creates a hardlink with a given name to the target file when -h flag is given Creates a softlink with a given name to the target file when -s flag is given

give @vihar-s1 75 points


Update Dockerfiles to Ubuntu 20.04

This seemed to mostly work locally, so I'm making this change to see if
our automation will pick it up and succeed. This also updates the
container Python version to one newer than 3.6 and the CUDA version to
11.2.
One notable new requirement is that users must run ldconfig after the
image starts to pick up libraries that are mounted by nvidia-docker. If
the automation is successful, then I'll look into updating the Docker
Hub page.
Working with this system is getting to be quite the hassle, so I'm glad
to be able to drop it in the future.

FYI @bhack

I had some extra commit at the old https://github.com/tensorflow/tensorflow/pull/48371 but I suppose that are for the next devel generation.
If the "next-gen" will be too far in the future I suggest to recover at least clang-format and pylint availability in the devel images.

P.s. also in my PR there was a diff in https://github.com/bhack/tensorflow/blob/master/tensorflow/tools/dockerfiles/spec.yml.
Why we don't see any diffs on this file here?

I had some extra commit at the old #48371 but I suppose that they are for the next tensorflow:devel generation.
If the "next-gen" will be too far in the future I suggest to recover at least clang-format and pylint availability in the devel images.

Good idea, I added clang-format but not pylint since it can be installed quickly to match the GitHub Action.

P.s. also in my PR there was a diff in https://github.com/bhack/tensorflow/blob/master/tensorflow/tools/dockerfiles/spec.yml. Why we don't see any diffs on this file here?

I didn't include the precommit stuff from your PR (which is one reason why I split this into a new one), which is one part of the spec.yml changes, and I changed the UBUNTU_VERSION variable in-place, which covers both of the changes to spec.yml.

but not pylint since it can be installed quickly to match the GitHub Action.

I think that this is an expectation with a very low probability. I don't think that contributors will care to install the right pylint version that match the Github Action. Who is going by default to check the Github Action log details or source code?
It is why some month ago I've requested to run the linting action with exactly the same tesnorflow:devel image so that we was exactly on the same page, locally and GithubAction, with a very little effort.

I changed the UBUNTU_VERSION variable in-place, which covers both of the changes to spec.yml

But do you have still used the scripts to generate this PR/diff or with the in-place change you have manually edited all the Dockerfiles?

Thanks


fix: put totals behind flag

Realized that we were passing the flag to the keyboard handler for totals, that totals is not behind flag. This should fix that

getting some new code climate complaints. They will be solved when we remove the flag


Improve CMS Detection

Changes this pull request makes :
This PR modify the CMS Detection feature so now it reads the payloads from payloads/detect_cms in order to detect the CMS of a website.
Checklist :

[x] I have added the relevant documentation.
[x] My branch is up-to-date with the upstream master branch.
[x] I have fully tested the changes locally.

Development environment
OS: Linux
Python Version: 3.4.6

I don't know why, but it looks like Codacy didn't check this pull request.