Animation shown in a wrong position on iOS with 6.1.0

Description
With version 6.1.0 the animation is shown in a wrong position on iOS when the parent view has alignItems: 'center' and / or justifyContent: 'center'.
Steps to Reproduce
<View style={{ flex: 1, alignItems: 'center', justifyContent: 'center' }}>
  <LottieView
    style={{ width: 100, aspectRatio: 1, backgroundColor: 'red' }}
    source={require('./path/to/animation.json')}
    autoPlay={true}
    loop={true}
  />
</View>

Expected behavior: animation shown in the red box
Actual behavior: animation shown outside the red box
Works fine in version 6.0.1
Minimal reproduction
See the snippet above.
React Native Environment
Bare React Native project (0.72.3)
Versions
{
  'my-app': '0.0.0-development',
  npm: '9.5.1',
  node: '18.16.0',
  acorn: '8.8.2',
  ada: '1.0.4',
  ares: '1.19.0',
  brotli: '1.0.9',
  cldr: '42.0',
  icu: '72.1',
  llhttp: '6.0.10',
  modules: '108',
  napi: '8',
  nghttp2: '1.52.0',
  nghttp3: '0.7.0',
  ngtcp2: '0.8.1',
  openssl: '3.0.8+quic',
  simdutf: '3.2.2',
  tz: '2022g',
  undici: '5.21.0',
  unicode: '15.0',
  uv: '1.44.2',
  uvwasi: '0.0.15',
  v8: '<IP_ADDRESS>-node.26',
  zlib: '1.2.13'
}

@matinzd  It probably doesn't matter since I tried with 2 different animations and it behaved the same, but I'll try to make a repro.

I could not reproduce it with the animations I have all of them are working properly.
https://github.com/lottie-react-native/lottie-react-native/assets/24797481/d69b9f65-9767-4c44-9386-d75b92616b11

@matinzd I am not able to reproduce in a new project either, so there must be something more needed for reproducing it. I'll try to debug it and come back with details later if I find something. Thank you for looking into this.

I am not able to reproduce this again... probably I had something in a weird state or something. I am closing it.

I faced the same issue! on version 6.5.0!
here is the animation I'm using:
{"v":"5.5.5","fr":60,"ip":0,"op":180,"w":200,"h":200,"nm":"Comp 1","ddd":0,"assets":[],"layers":[{"ddd":0,"ind":1,"ty":4,"nm":"03","sr":1,"ks":{"o":{"a":0,"k":100,"ix":11},"r":{"a":0,"k":0,"ix":10},"p":{"a":1,"k":[{"i":{"x":0.833,"y":0.833},"o":{"x":0.167,"y":0.167},"t":0,"s":[100,76.75,0],"to":[0.375,-0.458,0],"ti":[-1,1.167,0]},{"i":{"x":0.833,"y":0.833},"o":{"x":0.167,"y":0.167},"t":5.607,"s":[102.25,74,0],"to":[1,-1.167,0],"ti":[-2.292,1.542,0]},{"i":{"x":0.833,"y":0.833},"o":{"x":0.167,"y":0.167},"t":9.811,"s":[106,69.75,0],"to":[2.292,-1.542,0],"ti":[-2.333,0.625,0]},{"i":{"x":0.833,"y":0.833},"o":{"x":0.167,"y":0.167},"t":14.016,"s":[115.99999999999999,64.75,0],"to":[2.333,-0.625,0],"ti":[-1.167,-0.75,0]},{"i":{"x":0.833,"y":0.833},"o":{"x":0.167,"y":0.167},"t":15.416,"s":[120,66,0],"to":[1.167,0.75,0],"ti":[-0.5,-1.875,0]},{"i":{"x":0.833,"y":0.833},"o":{"x":0.167,"y":0.167},"t":16.82,"s":[123,69.25,0],"to":[0.5,1.875,0],"ti":[0.146,-2.396,0]},{"i":{"x":0.833,"y":0.833},"o":{"x":0.167,"y":0.167},"t":21.023,"s":[123,77.25,0],"to":[-0.146,2.396,0],"ti":[0.542,-1.896,0]},{"i":{"x":0.833,"y":0.833},"o":{"x":0.167,"y":0.167},"t":23.826,"s":[122.125,83.625,0],"to":[-0.542,1.896,0],"ti":[-0.729,-0.875,0]},{"i":{"x":0.833,"y":0.833},"o":{"x":0.167,"y":0.167},"t":29.434,"s":[119.75,88.625,0],"to":[0.729,0.875,0],"ti":[-2.25,-0.354,0]},{"i":{"x":0.833,"y":0.833},"o":{"x":0.167,"y":0.167},"t":37.844,"s":[126.49999999999999,88.875,0],"to":[2.25,0.354,0],"ti":[-1.833,-1.438,0]},{"i":{"x":0.833,"y":0.833},"o":{"x":0.167,"y":0.167},"t":40.646,"s":[133.25,90.75,0],"to":[1.833,1.438,0],"ti":[-0.75,-1.75,0]},{"i":{"x":0.833,"y":0.833},"o":{"x":0.167,"y":0.167},"t":44.85,"s":[137.5,97.5,0],"to":[0.75,1.75,0],"ti":[0.75,-1.667,0]},{"i":{"x":0.833,"y":0.833},"o":{"x":0.167,"y":0.167},"t":46.252,"s":[137.75,101.25,0],"to":[-0.75,1.667,0],"ti":[1.833,-1.417,0]},{"i":{"x":0.833,"y":0.833},"o":{"x":0.167,"y":0.167},"t":49.057,"s":[133,107.5,0],"to":[-1.833,1.417,0],"ti":[2.25,-0.542,0]},{"i":{"x":0.833,"y":0.833},"o":{"x":0.167,"y":0.167},"t":53.26,"s":[126.75,109.74999999999999,0],"to":[-2.25,0.542,0],"ti":[0.708,-1.417,0]},{"i":{"x":0.833,"y":0.833},"o":{"x":0.167,"y":0.167},"t":58.867,"s":[119.5,110.75,0],"to":[-0.708,1.417,0],"ti":[-0.521,-2.438,0]},{"i":{"x":0.833,"y":0.833},"o":{"x":0.167,"y":0.167},"t":67.275,"s":[122.50000000000001,118.25000000000001,0],"to":[0.521,2.438,0],"ti":[0.604,-2.312,0]},{"i":{"x":0.833,"y":0.833},"o":{"x":0.167,"y":0.167},"t":71.48,"s":[122.625,125.37499999999999,0],"to":[-0.604,2.312,0],"ti":[1.833,-1.458,0]},{"i":{"x":0.833,"y":0.833},"o":{"x":0.167,"y":0.167},"t":74.283,"s":[118.875,132.125,0],"to":[-1.833,1.458,0],"ti":[2.25,0.292,0]},{"i":{"x":0.833,"y":0.833},"o":{"x":0.167,"y":0.167},"t":78.486,"s":[111.625,134.125,0],"to":[-2.25,-0.292,0],"ti":[1.583,1.375,0]},{"i":{"x":0.833,"y":0.833},"o":{"x":0.167,"y":0.167},"t":81.291,"s":[105.375,130.375,0],"to":[-1.583,-1.375,0],"ti":[1,1.167,0]},{"i":{"x":0.833,"y":0.833},"o":{"x":0.167,"y":0.167},"t":84.094,"s":[102.125,125.875,0],"to":[-1,-1.167,0],"ti":[1.292,-0.625,0]},{"i":{"x":0.833,"y":0.833},"o":{"x":0.167,"y":0.167},"t":93.906,"s":[99.375,123.37499999999999,0],"to":[-1.292,0.625,0],"ti":[1.875,-1.667,0]},{"i":{"x":0.833,"y":0.833},"o":{"x":0.167,"y":0.167},"t":98.109,"s":[94.375,129.625,0],"to":[-1.875,1.667,0],"ti":[2.333,-0.5,0]},{"i":{"x":0.833,"y":0.833},"o":{"x":0.167,"y":0.167},"t":102.316,"s":[88.125,133.375,0],"to":[-2.333,0.5,0],"ti":[2,1.25,0]},{"i":{"x":0.833,"y":0.833},"o":{"x":0.167,"y":0.167},"t":105.117,"s":[80.375,132.625,0],"to":[-2,-1.25,0],"ti":[0.583,2.292,0]},{"i":{"x":0.833,"y":0.833},"o":{"x":0.167,"y":0.167},"t":107.92,"s":[76.125,125.875,0],"to":[-0.583,-2.292,0],"ti":[-0.625,2.333,0]},{"i":{"x":0.833,"y":0.833},"o":{"x":0.167,"y":0.167},"t":112.127,"s":[76.875,118.875,0],"to":[0.625,-2.333,0],"ti":[0.125,1.417,0]},{"i":{"x":0.833,"y":0.833},"o":{"x":0.167,"y":0.167},"t":116.33,"s":[79.875,111.87499999999999,0],"to":[-0.125,-1.417,0],"ti":[1.667,0.333,0]},{"i":{"x":0.833,"y":0.833},"o":{"x":0.167,"y":0.167},"t":124.74,"s":[76.125,110.375,0],"to":[-1.667,-0.333,0],"ti":[2.125,0.708,0]},{"i":{"x":0.833,"y":0.833},"o":{"x":0.167,"y":0.167},"t":128.943,"s":[69.875,109.87499999999999,0],"to":[-2.125,-0.708,0],"ti":[1.292,1.875,0]},{"i":{"x":0.833,"y":0.833},"o":{"x":0.167,"y":0.167},"t":131.748,"s":[63.375,106.125,0],"to":[-1.292,-1.875,0],"ti":[-0.542,2.25,0]},{"i":{"x":0.833,"y":0.833},"o":{"x":0.167,"y":0.167},"t":134.551,"s":[62.125,98.625,0],"to":[0.542,-2.25,0],"ti":[-1.75,1.542,0]},{"i":{"x":0.833,"y":0.833},"o":{"x":0.167,"y":0.167},"t":138.756,"s":[66.625,92.625,0],"to":[1.75,-1.542,0],"ti":[-2.083,0.625,0]},{"i":{"x":0.833,"y":0.833},"o":{"x":0.167,"y":0.167},"t":141.561,"s":[72.625,89.375,0],"to":[2.083,-0.625,0],"ti":[-0.875,1.333,0]},{"i":{"x":0.833,"y":0.833},"o":{"x":0.167,"y":0.167},"t":147.166,"s":[79.125,88.875,0],"to":[0.875,-1.333,0],"ti":[0.375,2.417,0]},{"i":{"x":0.833,"y":0.833},"o":{"x":0.167,"y":0.167},"t":156.977,"s":[77.875,81.375,0],"to":[-0.375,-2.417,0],"ti":[-0.375,2.333,0]},{"i":{"x":0.833,"y":0.833},"o":{"x":0.167,"y":0.167},"t":161.18,"s":[76.875,74.375,0],"to":[0.375,-2.333,0],"ti":[-1.833,1.458,0]},{"i":{"x":0.833,"y":0.833},"o":{"x":0.167,"y":0.167},"t":163.984,"s":[80.125,67.375,0],"to":[1.833,-1.458,0],"ti":[-2.333,-0.333,0]},{"i":{"x":0.833,"y":0.833},"o":{"x":0.167,"y":0.167},"t":166.787,"s":[87.875,65.625,0],"to":[2.333,0.333,0],"ti":[-1.958,-1.792,0]},{"i":{"x":0.833,"y":0.833},"o":{"x":0.167,"y":0.167},"t":170.992,"s":[94.125,69.375,0],"to":[1.958,1.792,0],"ti":[-0.917,-1.167,0]},{"t":178,"s":[99.625,76.375,0]}],"ix":2},"a":{"a":0,"k":[0,0,0],"ix":1},"s":{"a":0,"k":[3.958,3.958,100],"ix":6}},"ao":0,"shapes":[{"ty":"gr","it":[{"d":1,"ty":"el","s":{"a":0,"k":[600,600],"ix":2},"p":{"a":0,"k":[0,0],"ix":3},"nm":"Ellipse Path 1","mn":"ADBE Vector Shape - Ellipse","hd":false},{"ty":"st","c":{"a":0,"k":[0.9568627450980393,0.2627450980392157,0.21176470588235294,1],"ix":3},"o":{"a":0,"k":100,"ix":4},"w":{"a":0,"k":144,"ix":5},"lc":1,"lj":1,"ml":4,"bm":0,"nm":"Stroke 1","mn":"ADBE Vector Graphic - Stroke","hd":false},{"ty":"fl","c":{"a":0,"k":[0.9568627450980393,0.2627450980392157,0.21176470588235294,1],"ix":4},"o":{"a":0,"k":100,"ix":5},"r":1,"bm":0,"nm":"Fill 1","mn":"ADBE Vector Graphic - Fill","hd":false},{"ty":"tr","p":{"a":0,"k":[0,0],"ix":2},"a":{"a":0,"k":[0,0],"ix":1},"s":{"a":0,"k":[100,100],"ix":3},"r":{"a":0,"k":0,"ix":6},"o":{"a":0,"k":100,"ix":7},"sk":{"a":0,"k":0,"ix":4},"sa":{"a":0,"k":0,"ix":5},"nm":"Transform"}],"nm":"Ellipse 1","np":3,"cix":2,"bm":0,"ix":1,"mn":"ADBE Vector Group","hd":false}],"ip":0,"op":3600,"st":0,"bm":0},{"ddd":0,"ind":2,"ty":4,"nm":"02","sr":1,"ks":{"o":{"a":0,"k":100,"ix":11},"r":{"a":0,"k":0,"ix":10},"p":{"a":1,"k":[{"i":{"x":0.833,"y":0.833},"o":{"x":0.167,"y":0.167},"t":0,"s":[80.5,110.75,0],"to":[-0.375,0.5,0],"ti":[0.75,-1.375,0]},{"i":{"x":0.833,"y":0.833},"o":{"x":0.167,"y":0.167},"t":5.607,"s":[78.25,113.75,0],"to":[-0.75,1.375,0],"ti":[0.208,-2.583,0]},{"i":{"x":0.833,"y":0.833},"o":{"x":0.167,"y":0.167},"t":9.811,"s":[76,119,0],"to":[-0.208,2.583,0],"ti":[-0.75,-2.167,0]},{"i":{"x":0.833,"y":0.833},"o":{"x":0.167,"y":0.167},"t":14.016,"s":[77,129.25,0],"to":[0.75,2.167,0],"ti":[-1.25,-0.542,0]},{"i":{"x":0.833,"y":0.833},"o":{"x":0.167,"y":0.167},"t":15.416,"s":[80.5,132,0],"to":[1.25,0.542,0],"ti":[-1.833,0.25,0]},{"i":{"x":0.833,"y":0.833},"o":{"x":0.167,"y":0.167},"t":16.82,"s":[84.5,132.5,0],"to":[1.833,-0.25,0],"ti":[-2,1,0]},{"i":{"x":0.833,"y":0.833},"o":{"x":0.167,"y":0.167},"t":21.023,"s":[91.5,130.5,0],"to":[2,-1,0],"ti":[-1.396,1.25,0]},{"i":{"x":0.833,"y":0.833},"o":{"x":0.167,"y":0.167},"t":23.826,"s":[96.5,126.49999999999999,0],"to":[1.396,-1.25,0],"ti":[-0.646,1.708,0]},{"i":{"x":0.833,"y":0.833},"o":{"x":0.167,"y":0.167},"t":29.434,"s":[99.875,123,0],"to":[0.646,-1.708,0],"ti":[-0.062,2.292,0]},{"i":{"x":0.833,"y":0.833},"o":{"x":0.167,"y":0.167},"t":37.844,"s":[100.37499999999999,116.25000000000001,0],"to":[0.062,-2.292,0],"ti":[0.021,2.333,0]},{"i":{"x":0.833,"y":0.833},"o":{"x":0.167,"y":0.167},"t":40.646,"s":[100.25,109.25,0],"to":[-0.021,-2.333,0],"ti":[0,1.792,0]},{"i":{"x":0.833,"y":0.833},"o":{"x":0.167,"y":0.167},"t":44.85,"s":[100.25,102.25,0],"to":[0,-1.792,0],"ti":[0,1.917,0]},{"i":{"x":0.833,"y":0.833},"o":{"x":0.167,"y":0.167},"t":46.252,"s":[100.25,98.5,0],"to":[0,-1.917,0],"ti":[0,2.375,0]},{"i":{"x":0.833,"y":0.833},"o":{"x":0.167,"y":0.167},"t":49.057,"s":[100.25,90.75,0],"to":[0,-2.375,0],"ti":[-0.042,2.292,0]},{"i":{"x":0.833,"y":0.833},"o":{"x":0.167,"y":0.167},"t":53.26,"s":[100.25,84.25,0],"to":[0.042,-2.292,0],"ti":[0.958,2.208,0]},{"i":{"x":0.833,"y":0.833},"o":{"x":0.167,"y":0.167},"t":58.867,"s":[100.49999999999999,77,0],"to":[-0.958,-2.208,0],"ti":[1.833,1.604,0]},{"i":{"x":0.833,"y":0.833},"o":{"x":0.167,"y":0.167},"t":67.275,"s":[94.5,71,0],"to":[-1.833,-1.604,0],"ti":[2.042,0.438,0]},{"i":{"x":0.833,"y":0.833},"o":{"x":0.167,"y":0.167},"t":71.48,"s":[89.5,67.375,0],"to":[-2.042,-0.438,0],"ti":[2,-1.125,0]},{"i":{"x":0.833,"y":0.833},"o":{"x":0.167,"y":0.167},"t":74.283,"s":[82.25,68.375,0],"to":[-2,1.125,0],"ti":[0.833,-2.042,0]},{"i":{"x":0.833,"y":0.833},"o":{"x":0.167,"y":0.167},"t":78.486,"s":[77.5,74.125,0],"to":[-0.833,2.042,0],"ti":[-0.25,-1.958,0]},{"i":{"x":0.833,"y":0.833},"o":{"x":0.167,"y":0.167},"t":81.291,"s":[77.25,80.625,0],"to":[0.25,1.958,0],"ti":[-0.792,-1.583,0]},{"i":{"x":0.833,"y":0.833},"o":{"x":0.167,"y":0.167},"t":84.094,"s":[79,85.875,0],"to":[0.792,1.583,0],"ti":[-1.458,-1.417,0]},{"i":{"x":0.833,"y":0.833},"o":{"x":0.167,"y":0.167},"t":93.906,"s":[82,90.125,0],"to":[1.458,1.417,0],"ti":[-1.917,-1.25,0]},{"i":{"x":0.833,"y":0.833},"o":{"x":0.167,"y":0.167},"t":98.109,"s":[87.75,94.375,0],"to":[1.917,1.25,0],"ti":[-2.042,-1.25,0]},{"i":{"x":0.833,"y":0.833},"o":{"x":0.167,"y":0.167},"t":102.316,"s":[93.5,97.625,0],"to":[2.042,1.25,0],"ti":[-2.125,-1.333,0]},{"i":{"x":0.833,"y":0.833},"o":{"x":0.167,"y":0.167},"t":105.117,"s":[100,101.875,0],"to":[2.125,1.333,0],"ti":[-2,-1.083,0]},{"i":{"x":0.833,"y":0.833},"o":{"x":0.167,"y":0.167},"t":107.92,"s":[106.25,105.62499999999999,0],"to":[2,1.083,0],"ti":[-2.083,-0.833,0]},{"i":{"x":0.833,"y":0.833},"o":{"x":0.167,"y":0.167},"t":112.127,"s":[112.00000000000001,108.375,0],"to":[2.083,0.833,0],"ti":[-2.042,-0.333,0]},{"i":{"x":0.833,"y":0.833},"o":{"x":0.167,"y":0.167},"t":116.33,"s":[118.75,110.625,0],"to":[2.042,0.333,0],"ti":[-1.833,0.292,0]},{"i":{"x":0.833,"y":0.833},"o":{"x":0.167,"y":0.167},"t":124.74,"s":[124.25,110.375,0],"to":[1.833,-0.292,0],"ti":[-2,0.875,0]},{"i":{"x":0.833,"y":0.833},"o":{"x":0.167,"y":0.167},"t":128.943,"s":[129.75,108.87500000000001,0],"to":[2,-0.875,0],"ti":[-1.417,1.75,0]},{"i":{"x":0.833,"y":0.833},"o":{"x":0.167,"y":0.167},"t":131.748,"s":[136.25,105.125,0],"to":[1.417,-1.75,0],"ti":[0.417,2.208,0]},{"i":{"x":0.833,"y":0.833},"o":{"x":0.167,"y":0.167},"t":134.551,"s":[138.25,98.375,0],"to":[-0.417,-2.208,0],"ti":[1.875,1.542,0]},{"i":{"x":0.833,"y":0.833},"o":{"x":0.167,"y":0.167},"t":138.756,"s":[133.75,91.875,0],"to":[-1.875,-1.542,0],"ti":[2.167,0.5,0]},{"i":{"x":0.833,"y":0.833},"o":{"x":0.167,"y":0.167},"t":141.561,"s":[127,89.125,0],"to":[-2.167,-0.5,0],"ti":[2.375,-0.542,0]},{"i":{"x":0.833,"y":0.833},"o":{"x":0.167,"y":0.167},"t":147.166,"s":[120.75,88.875,0],"to":[-2.375,0.542,0],"ti":[2.333,-1.083,0]},{"i":{"x":0.833,"y":0.833},"o":{"x":0.167,"y":0.167},"t":156.977,"s":[112.75,92.375,0],"to":[-2.333,1.083,0],"ti":[2.042,-1.083,0]},{"i":{"x":0.833,"y":0.833},"o":{"x":0.167,"y":0.167},"t":161.18,"s":[106.74999999999999,95.375,0],"to":[-2.042,1.083,0],"ti":[2.125,-1.208,0]},{"i":{"x":0.833,"y":0.833},"o":{"x":0.167,"y":0.167},"t":163.984,"s":[100.49999999999999,98.875,0],"to":[-2.125,1.208,0],"ti":[2.083,-1.292,0]},{"i":{"x":0.833,"y":0.833},"o":{"x":0.167,"y":0.167},"t":166.787,"s":[94,102.62500000000001,0],"to":[-2.083,1.292,0],"ti":[2.167,-1.25,0]},{"i":{"x":0.833,"y":0.833},"o":{"x":0.167,"y":0.167},"t":170.992,"s":[88,106.62499999999999,0],"to":[-2.167,1.25,0],"ti":[1.167,-0.583,0]},{"t":178,"s":[81,110.125,0]}],"ix":2},"a":{"a":0,"k":[0,0,0],"ix":1},"s":{"a":0,"k":[3.958,3.958,100],"ix":6}},"ao":0,"shapes":[{"ty":"gr","it":[{"d":1,"ty":"el","s":{"a":0,"k":[600,600],"ix":2},"p":{"a":0,"k":[0,0],"ix":3},"nm":"Ellipse Path 1","mn":"ADBE Vector Shape - Ellipse","hd":false},{"ty":"st","c":{"a":0,"k":[0.9882352941176471,0.8352941176470589,0.21568627450980393,1],"ix":3},"o":{"a":0,"k":100,"ix":4},"w":{"a":0,"k":144,"ix":5},"lc":1,"lj":1,"ml":4,"bm":0,"nm":"Stroke 1","mn":"ADBE Vector Graphic - Stroke","hd":false},{"ty":"fl","c":{"a":0,"k":[0.9882352941176471,0.8352941176470589,0.21568627450980393,1],"ix":4},"o":{"a":0,"k":100,"ix":5},"r":1,"bm":0,"nm":"Fill 1","mn":"ADBE Vector Graphic - Fill","hd":false},{"ty":"tr","p":{"a":0,"k":[0,0],"ix":2},"a":{"a":0,"k":[0,0],"ix":1},"s":{"a":0,"k":[100,100],"ix":3},"r":{"a":0,"k":0,"ix":6},"o":{"a":0,"k":100,"ix":7},"sk":{"a":0,"k":0,"ix":4},"sa":{"a":0,"k":0,"ix":5},"nm":"Transform"}],"nm":"Ellipse 1","np":3,"cix":2,"bm":0,"ix":1,"mn":"ADBE Vector Group","hd":false}],"ip":0,"op":3600,"st":0,"bm":0},{"ddd":0,"ind":3,"ty":4,"nm":"01","sr":1,"ks":{"o":{"a":0,"k":100,"ix":11},"r":{"a":0,"k":0,"ix":10},"p":{"a":1,"k":[{"i":{"x":0.833,"y":0.833},"o":{"x":0.167,"y":0.167},"t":0,"s":[119.5,110.75,0],"to":[-0.417,-0.292,0],"ti":[1.208,0.708,0]},{"i":{"x":0.833,"y":0.833},"o":{"x":0.167,"y":0.167},"t":5.607,"s":[117,109.00000000000001,0],"to":[-1.208,-0.708,0],"ti":[2.292,1.25,0]},{"i":{"x":0.833,"y":0.833},"o":{"x":0.167,"y":0.167},"t":9.811,"s":[112.25,106.5,0],"to":[-2.292,-1.25,0],"ti":[2.083,1.083,0]},{"i":{"x":0.833,"y":0.833},"o":{"x":0.167,"y":0.167},"t":14.016,"s":[103.25,101.49999999999999,0],"to":[-2.083,-1.083,0],"ti":[1.125,0.583,0]},{"i":{"x":0.833,"y":0.833},"o":{"x":0.167,"y":0.167},"t":15.416,"s":[99.75,100,0],"to":[-1.125,-0.583,0],"ti":[1.542,1,0]},{"i":{"x":0.833,"y":0.833},"o":{"x":0.167,"y":0.167},"t":16.82,"s":[96.5,98,0],"to":[-1.542,-1,0],"ti":[1.833,1.083,0]},{"i":{"x":0.833,"y":0.833},"o":{"x":0.167,"y":0.167},"t":21.023,"s":[90.5,94,0],"to":[-1.833,-1.083,0],"ti":[1.542,0.75,0]},{"i":{"x":0.833,"y":0.833},"o":{"x":0.167,"y":0.167},"t":23.826,"s":[85.5,91.5,0],"to":[-1.542,-0.75,0],"ti":[1.958,0.333,0]},{"i":{"x":0.833,"y":0.833},"o":{"x":0.167,"y":0.167},"t":29.434,"s":[81.25,89.5,0],"to":[-1.958,-0.333,0],"ti":[2.271,-0.292,0]},{"i":{"x":0.833,"y":0.833},"o":{"x":0.167,"y":0.167},"t":37.844,"s":[73.75,89.5,0],"to":[-2.271,0.292,0],"ti":[1.896,-1.25,0]},{"i":{"x":0.833,"y":0.833},"o":{"x":0.167,"y":0.167},"t":40.646,"s":[67.625,91.25,0],"to":[-1.896,1.25,0],"ti":[0.875,-1.625,0]},{"i":{"x":0.833,"y":0.833},"o":{"x":0.167,"y":0.167},"t":44.85,"s":[62.375,97,0],"to":[-0.875,1.625,0],"ti":[-0.75,-1.667,0]},{"i":{"x":0.833,"y":0.833},"o":{"x":0.167,"y":0.167},"t":46.252,"s":[62.375,101,0],"to":[0.75,1.667,0],"ti":[-1.792,-1.375,0]},{"i":{"x":0.833,"y":0.833},"o":{"x":0.167,"y":0.167},"t":49.057,"s":[66.875,107,0],"to":[1.792,1.375,0],"ti":[-2.125,-0.625,0]},{"i":{"x":0.833,"y":0.833},"o":{"x":0.167,"y":0.167},"t":53.26,"s":[73.125,109.25,0],"to":[2.125,0.625,0],"ti":[-2.333,0.25,0]},{"i":{"x":0.833,"y":0.833},"o":{"x":0.167,"y":0.167},"t":58.867,"s":[79.625,110.75,0],"to":[2.333,-0.25,0],"ti":[-2.188,0.979,0]},{"i":{"x":0.833,"y":0.833},"o":{"x":0.167,"y":0.167},"t":67.275,"s":[87.125,107.74999999999999,0],"to":[2.188,-0.979,0],"ti":[-2.229,1.146,0]},{"i":{"x":0.833,"y":0.833},"o":{"x":0.167,"y":0.167},"t":71.48,"s":[92.75,104.875,0],"to":[2.229,-1.146,0],"ti":[-2.208,1.333,0]},{"i":{"x":0.833,"y":0.833},"o":{"x":0.167,"y":0.167},"t":74.283,"s":[100.49999999999999,100.875,0],"to":[2.208,-1.333,0],"ti":[-1.917,1.25,0]},{"i":{"x":0.833,"y":0.833},"o":{"x":0.167,"y":0.167},"t":78.486,"s":[106,96.875,0],"to":[1.917,-1.25,0],"ti":[-1.708,1,0]},{"i":{"x":0.833,"y":0.833},"o":{"x":0.167,"y":0.167},"t":81.291,"s":[112.00000000000001,93.375,0],"to":[1.708,-1,0],"ti":[-1.375,0.917,0]},{"i":{"x":0.833,"y":0.833},"o":{"x":0.167,"y":0.167},"t":84.094,"s":[116.25000000000001,90.875,0],"to":[1.375,-0.917,0],"ti":[-1.125,1.625,0]},{"i":{"x":0.833,"y":0.833},"o":{"x":0.167,"y":0.167},"t":93.906,"s":[120.24999999999999,87.875,0],"to":[1.125,-1.625,0],"ti":[-0.5,2.292,0]},{"i":{"x":0.833,"y":0.833},"o":{"x":0.167,"y":0.167},"t":98.109,"s":[123,81.125,0],"to":[0.5,-2.292,0],"ti":[0.708,2.25,0]},{"i":{"x":0.833,"y":0.833},"o":{"x":0.167,"y":0.167},"t":102.316,"s":[123.25,74.125,0],"to":[-0.708,-2.25,0],"ti":[2,1.167,0]},{"i":{"x":0.833,"y":0.833},"o":{"x":0.167,"y":0.167},"t":105.117,"s":[118.75,67.625,0],"to":[-2,-1.167,0],"ti":[2.375,-0.458,0]},{"i":{"x":0.833,"y":0.833},"o":{"x":0.167,"y":0.167},"t":107.92,"s":[111.25,67.125,0],"to":[-2.375,0.458,0],"ti":[1.833,-1.5,0]},{"i":{"x":0.833,"y":0.833},"o":{"x":0.167,"y":0.167},"t":112.127,"s":[104.5,70.375,0],"to":[-1.833,1.5,0],"ti":[0.75,-1.833,0]},{"i":{"x":0.833,"y":0.833},"o":{"x":0.167,"y":0.167},"t":116.33,"s":[100.25,76.125,0],"to":[-0.75,1.833,0],"ti":[0.042,-1.792,0]},{"i":{"x":0.833,"y":0.833},"o":{"x":0.167,"y":0.167},"t":124.74,"s":[100,81.375,0],"to":[-0.042,1.792,0],"ti":[0.125,-2.083,0]},{"i":{"x":0.833,"y":0.833},"o":{"x":0.167,"y":0.167},"t":128.943,"s":[100,86.875,0],"to":[-0.125,2.083,0],"ti":[0.292,-2.458,0]},{"i":{"x":0.833,"y":0.833},"o":{"x":0.167,"y":0.167},"t":131.748,"s":[99.25,93.875,0],"to":[-0.292,2.458,0],"ti":[0.083,-2.625,0]},{"i":{"x":0.833,"y":0.833},"o":{"x":0.167,"y":0.167},"t":134.551,"s":[98.25,101.62500000000001,0],"to":[-0.083,2.625,0],"ti":[-0.083,-2.292,0]},{"i":{"x":0.833,"y":0.833},"o":{"x":0.167,"y":0.167},"t":138.756,"s":[98.75,109.625,0],"to":[0.083,2.292,0],"ti":[-0.208,-2.125,0]},{"i":{"x":0.833,"y":0.833},"o":{"x":0.167,"y":0.167},"t":141.561,"s":[98.75,115.375,0],"to":[0.208,2.125,0],"ti":[-1.083,-2.375,0]},{"i":{"x":0.833,"y":0.833},"o":{"x":0.167,"y":0.167},"t":147.166,"s":[100,122.37499999999999,0],"to":[1.083,2.375,0],"ti":[-1.917,-1.917,0]},{"i":{"x":0.833,"y":0.833},"o":{"x":0.167,"y":0.167},"t":156.977,"s":[105.25,129.625,0],"to":[1.917,1.917,0],"ti":[-2.292,-0.5,0]},{"i":{"x":0.833,"y":0.833},"o":{"x":0.167,"y":0.167},"t":161.18,"s":[111.5,133.875,0],"to":[2.292,0.5,0],"ti":[-2.083,1.167,0]},{"i":{"x":0.833,"y":0.833},"o":{"x":0.167,"y":0.167},"t":163.984,"s":[119,132.625,0],"to":[2.083,-1.167,0],"ti":[-0.833,2.25,0]},{"i":{"x":0.833,"y":0.833},"o":{"x":0.167,"y":0.167},"t":166.787,"s":[124,126.875,0],"to":[0.833,-2.25,0],"ti":[0.75,2.667,0]},{"i":{"x":0.833,"y":0.833},"o":{"x":0.167,"y":0.167},"t":170.992,"s":[124,119.12499999999999,0],"to":[-0.75,-2.667,0],"ti":[0.75,1.375,0]},{"t":178,"s":[119.5,110.87499999999999,0]}],"ix":2},"a":{"a":0,"k":[0,0,0],"ix":1},"s":{"a":0,"k":[3.958,3.958,100],"ix":6}},"ao":0,"shapes":[{"ty":"gr","it":[{"d":1,"ty":"el","s":{"a":0,"k":[600,600],"ix":2},"p":{"a":0,"k":[0,0],"ix":3},"nm":"Ellipse Path 1","mn":"ADBE Vector Shape - Ellipse","hd":false},{"ty":"st","c":{"a":0,"k":[0.9568627450980393,0.2627450980392157,0.21176470588235294,1],"ix":3},"o":{"a":0,"k":100,"ix":4},"w":{"a":0,"k":144,"ix":5},"lc":1,"lj":1,"ml":4,"bm":0,"nm":"Stroke 1","mn":"ADBE Vector Graphic - Stroke","hd":false},{"ty":"fl","c":{"a":0,"k":[0.9568627450980393,0.2627450980392157,0.21176470588235294,1],"ix":4},"o":{"a":0,"k":100,"ix":5},"r":1,"bm":0,"nm":"Fill 1","mn":"ADBE Vector Graphic - Fill","hd":false},{"ty":"tr","p":{"a":0,"k":[0,0],"ix":2},"a":{"a":0,"k":[0,0],"ix":1},"s":{"a":0,"k":[100,100],"ix":3},"r":{"a":0,"k":0,"ix":6},"o":{"a":0,"k":100,"ix":7},"sk":{"a":0,"k":0,"ix":4},"sa":{"a":0,"k":0,"ix":5},"nm":"Transform"}],"nm":"Ellipse 1","np":3,"cix":2,"bm":0,"ix":1,"mn":"ADBE Vector Group","hd":false}],"ip":0,"op":3600,"st":0,"bm":0}],"markers":[]}

But as @mlazari mentioned before, it doesn't matter which animation we use, it's being rendered outside of the boundary!
Also the animation doesn't work in the Android devices!
View style={styles.container}>
      <LottieView
        autoPlay
        style={styles.animation}
        loop={true}
        renderMode="SOFTWARE"
        source={require("assets/animations/loading.json")}
      />
</View>

const styles = ScaledSheet.create({
  animation: {
    height: "150@ms",
    width: "150@ms",
    backgroundColor: "red",
  },
  container: {
    flex: 1,
    flexGrow: 1,
    alignItems: "center",
    justifyContent: "center",
  },
});


curl: (56) Recv failure: Connection reset by peer

I get curl: (56) Recv failure: Connection reset by peer or curl: (56) Proxy CONNECT aborted errors when I increase the number of tors to be greater than 25.

You can monitor (http://xxxxxx:4444/haproxy?stats) and see what might be causing this. It's most likely TOR itself.

dup #3


Support for JSON mode GPT-4-Turbo

Hi there,
Are you planning to support JSON mode for GPT-4-Turbo?

Cheers

Hi,
Yes, absolutely. It is on my roadmap.

Hi there,
Are you planning to support JSON mode for GPT-4-Turbo?

Cheers

Please check version v1.2.0


Mo tro 151 gown mobile finishing touches

Have something that works for mobile version.  Might need some changes as far as how it is laid out and functions but worth a PR.  Code could probably be cleaned up a bit more but that can be done later.  One thing that will def need to be changed is the GraphQL query, that can be further down the line when it is closer to deployment.

@mdrisco4 - nice work on this one, merged it in. I'm back in the saddle.


M122 iOS staging spec test. run PR

Description

Provide details of the change, and generalize the change in the PR title above.

Testing

Describe how you've tested these changes. Link any manually triggered Integration tests or CPP binary SDK Packaging Github Action workflows, if applicable.

Type of Change
Place an x the applicable box:

[ ] Bug fix. Add the issue # below if applicable.
[ ] New feature. A non-breaking change which adds functionality.
[ ] Other, such as a build process or documentation change.

Notes

Bug fixes and feature changes require an update to the Release Notes section of release_build_files/readme.md.
Read the contribution guidelines CONTRIBUTING.md.
Changes to the public API require an internal API review. If you'd like to help us make Firebase APIs better, please propose your change in a feature request so that we can discuss it together.

If firestore fails to build, try cherry-picking https://github.com/firebase/firebase-cpp-sdk/pull/1097


chore: Build arm64 for macOS in CI wip

Fix #340
Signed-off-by: Ce Gao<EMAIL_ADDRESS>

I think we should postpone the PR since I have no way to test if the PR works well. We need a M1 macOS to verify the wheel can be installed and the envd bin can be run successfully.

I think we should postpone the PR since I have no way to test if the PR works well. We need a M1 macOS to verify the wheel can be installed and the envd bin can be run successfully.

How to test it lol. I can help if possible.

How about this https://veertu.com/?

Will have a look at it. Seems helpful to us.

https://github.blog/changelog/2021-08-16-github-actions-macos-11-big-sur-is-generally-available-on-github-hosted-runners/
This post may be helpful


⚠ TADA Wallet Web has degraded performance

In 58928a5, TADA Wallet Web ($WALLET_WEB_URL) experienced degraded performance:

HTTP code: 200
Response time: 24856 ms

Resolved: TADA Wallet Web performance has improved in 5cce422.


Add configuration bundle for Drydock export

This adds an additional output file to the generate sub-command, which dumps a (nearly) complete collection of configuration documents into a single file without duplicates.  This should be suitable for upload into Drydock.
This is a bigger change than I expected, because I had been a bit sloppy in my mixing of name and alias in the first pass at this development.
I think we should revisit this in the future and structure the metadata more strictly perhaps even using only label selectors.  Then the config queries from templates can do label selection instead of having two kinds of "names".
For now though, the gist is that alias is meant to be like a label selector that can be reused on multiple hosts for different data on each host.  This way the templates don't have to do anything complex in their queries -- they just say things like alias='kubelet'.
Additionally, I had validation in place to check that there were no duplicate values of name per kind.  I think this is good, and I didn't want to remove that.  However, I had again coupled the name field with other data.  In this case it was the CN of the certs.  For most cases, this wasn't a problem, because they embedded the hostname, but for the kube proxy, it actually needs to use the same CN for all hosts.  Maybe the kubernetes authors are expecting it to always be a DaemonSet.
Anyway, I added a specific override for the name in the config.Document when generating a cert, called config_name just to handle the proxy case.

@sh8121att Thanks for looking.  When testing with multi-master this morning, I found some gaps.  Can you take another look & merge if you're happy with it?

Just to validate, when I select which documents to send to a host I should now match the hostname with target and host tags/labels with alias correct?
And agree we will need a normalization effort on schemas for the documents for each UCP service. Probably fits in well w/ Deckhand development.

@sh8121att I think you should only need to look at target right now.
The alias field is used to select, e.g., "proxy" certificate vs "kubelet" certificate once it's already filtered to a given host.  I.e., the alias will be repeated for each host that needs that file.


Fixes deprecation warning in cucumber related to in_current_dir

I was running tests and noticed there was a deprecation warning, as seen here:
https://travis-ci.org/colszowka/simplecov/jobs/78887751
Not sure if this will work in all the rubies, though. Let's see what travis has to say about that.

Still seems good, merging.


Clarify import path.

Fixes #1

I tested if it works by running yarn build in the package folder and copying dist to LiveTL/LiveTL/node_modules/iframe-translator.

no.


Next 14?

I'd like to try out ts-rest/next in a Next 14 project but it looks like it's not yet supported:
{
  "name": "@ts-rest/next",
  "version": "3.30.4",
  "peerDependencies": {
    "next": "^12.0.0 || ^13.0.0",
    "zod": "^3.22.3"
  },

@twobit you can actually get away with using most of TS-rest via the @ts-rest/core package (since most data fetching is done via server actions and server components). Were you planning on using ts-rest in API handlers?
I think we're still thinking of use cases since Nextjs has most data fetching through server components now (13+).

I think we're still thinking of use cases since Nextjs has most data fetching through server components now (13+).
That is if the project adopts that approach. I would wager that most projects do not.
Pages directory is still supported (and they said they have no plan to stop supporting it).
All that to say that there is no reason to not bump next to 14 in peerDeps

I think next 14 doesn't actually breaks any of the existing behavior in the pages router, the major 14 version bump is mostly marketing anyway.
I agree with @ssijak in supporting 14 and it shouldn't break anything.


update pkg go-chassis

Pull Request Test Coverage Report for Build 127

0 of 0   changed or added relevant lines in 0 files are covered.
6 unchanged lines in 2 files lost coverage.
Overall coverage decreased (-0.02%) to 46.05%

Files with Coverage Reduction
New Missed Lines
%

protocol/dubbo/dubbo/request.go
3
0.0%

resolver/source.go
3
0.0%

Totals

Change from base Build 116:
-0.02%

Covered Lines:
1020

Relevant Lines:
2215

💛  - Coveralls


context.payload is any again with typescript ?

Bug Report
Current Behavior
It seems payload is any again, like described in the issue https://github.com/probot/probot/issues/1366, with the latest release (I replied it worked, but now I'm not sure it did, as I am still migrating and have a lot of typescript errors)
// Your code here
module.exports = (app) => {
  app.on(
    'repository.edited',
    async (context) => {
      // context.payload is any
      // context is: (parameter) context: WebhookEvent<EventPayloads.WebhookPayloadRepository> & Context<any>
    };
  );

Expected behavior/code
A clear and concise description of what you expected to happen (or code).
Environment

Probot version(s): v10.9.4
Node/npm version: Node 14 / Yarn 1.22.5
OS: Ubuntu
Typescript: 4.0.3

Possible Solution
I tried to change node_modules/probot/lib/types.d.ts :
-export declare type ProbotWebhooks = Webhooks<WebhookEvent, Context>;
+export declare type ProbotWebhooks = Webhooks<WebhookEvent, Omit<Context, keyof WebhookEvent>>;

And it seems to work: context is now:
(parameter) context: WebhookEvent<EventPayloads.WebhookPayloadRepository> & Pick<Context<any>, "github" | "log" | "event" | "repo" | "issue" | "pullRequest" | "isBot" | "config">

I could make a PR, but should we add a test somehow to make sure it will keep working ?

I would really like to add a test to https://github.com/octokit/webhooks.js/. Got any idea? We do run a typescript validation (https://github.com/octokit/webhooks.js/blob/571d6100f7133f7be5c94f6862c487fbe390f6cd/package.json#L53), but that only gets us so far. What we really need is a verification that a specified type is set given a specified code.

Something like https://github.com/TypeStrong/ts-expect ?
That's cool this typescript-validate thing, that's the thing missing in probot ? event if we start small, we can still add things later on when typescript bugs specific to probot are found ? I can try this weekend

I think the problem really needs to be tested/fixed in https://github.com/octokit/webhooks.js/. A test in there would make sure the problem wouldn't occur again. Without it, the problem would only surface once we update probot to a new version of @octokit/webhooks.
I was recommended to try https://github.com/SamVerschueren/tsd, maybe check that out first?

I think this problem is only in probot, because the fix I made was in probot:
in lib/types.d.ts
-export declare type ProbotWebhooks = Webhooks<WebhookEvent, Context>;
+export declare type ProbotWebhooks = Webhooks<WebhookEvent, Omit<Context, keyof WebhookEvent>>;

Context is a generic and default is any, so Webhooks<WebhookEvent, Context> has { payload: any } because of the Context. That's why omiting all the keys specified  in WebhookEvent fixes it

Ahhh sorry Christophe, now I get it! Okay in this case feel free to add both a test and a fix to Probot. If it works well we can adopt a similar test for @octokit/webhooks to avoid future regressions

it seems like tsd has a better api too !

Actually, the Omit could be in webhooks.js:
-export declare type HandlerFunction<E extends WebhookEvents, U> = (event: EventTypesPayload[E] & U) => any;
+export declare type HandlerFunction<E extends WebhookEvents, U> = (event: EventTypesPayload[E] & Omit<U keyof EventTypesPayload[E]>) => any;

but I'm not sure it feels right


docs(ee/34/aws-deployment) add AWS guide and best practices

NOTE: Please read the CONTRIBUTING.md guidelines before submitting your patch,
and ensure you followed them all:
https://github.com/Kong/docs.konghq.com/blob/master/CONTRIBUTING.md
Summary
Provides a guide to make it easier for AWS customers to use Kong.
Full changelog

Add AWS Deployment guide to Guides and References
Add navigation

Checklist:

[x] Commit message & atomicity checked
[x] Documentation
[ ] Adheres to Kong style guide
[ ] Spellchecked my updates
[ ] Tagged "Team Docs" as reviewers
[ ] Ready to be merged

[x] Internal confirmation
[ ] Format tables

Can only Kong EE users use this?

@levfishbluefish this guide can be referenced for both Kong and Kong Enterprise users.

@p0pr0ck5 here's how the table looks now:

Srry for the review delay - quick question about these:

Is this supposed to be a table?

Thank you, @levfishbluefish , it is. On it.

@levfishbluefish can we safely disregard the Travis breaks now that Node is updated?

Would recommend

@levfishbluefish can we safely disregard the Travis breaks now that Node is updated?

No - Travis should not break

@levfishbluefish , Travis is green.


F231 eslint airbnb

Coverage decreased (-0.2%) to 87.662% when pulling 05bc41c6c8aa8b42e066983cb6fa4feea03b5d48 on f231-eslint-airbnb into 05931de655c0ac8ebc8e6bb3635a8d246543deba on master.


Generate types

Types aren't shipped with the 2.0 release. This PR generates types with vite-plugin-dts instead of with tsc.
npm hoisting points to vite 3 at the monorepo root, so there is a mismatch between Plugin in Vite 3 and Plugin in Vite 4, hence the unknown conversion

Thank you for the PR, @ridem!
And thank you for the quick review, @alexjoverm.


Wrong instance type after update_compute

`` - AWS ParallelCluster version: 3.2.1
I created my cluster with a compute node of type c5.4xlarge
Later I ran
pcluster update-compute-fleet --region us-east-1 --cluster-name XXXX --status STOP_REQUESTED
Then updated the instance type to c5.18xlarge and ran
pcluster update-cluster --cluster-name XXXX --cluster-configuration configs/cluster-config.prod.us-east1a.yaml
Once updated, I restarted the fleet.
In the AWS console I see c5.18x instances.
but sinfo still shows
$ sinfo PARTITION AVAIL  TIMELIMIT  NODES  STATE NODELIST cpu*         up   infinite    999  idle~ cpu-dy-c54xlarge-[2-1000] cpu*         up   infinite      1    mix cpu-dy-c54xlarge-1
Also scontrol show job shows node names as being c54large
Shouldn't the update also update the node names?

Hi,
that is the name of the ComputeResources. In your updated configuration do you have changed the name of the ComputeResources too?

Changed nothing but the instance type. Then I ran pcluster update-cluster

That explains why the name of the nodes are not changed. The instance type should have been changed successfully.
In other words, the name displayed by sinfo is the same as the ComputeResource Name, independent from what InstanceType you choose.

Man I'm so dumb. I forgot about that field. I thought It was dynamically set.
So sorry to have wasted your time, please destroy this whole thread.
Geez now I feel bad :-)


Possible NPE with context going null

Adding a proactive null check for the share link item selected.
@aaustin @EvangelosG

👍


KAFKA-14633: Reduce data copy & buffer allocation during decompression

This covers two JIRAs https://issues.apache.org/jira/browse/KAFKA-14632 and https://issues.apache.org/jira/browse/KAFKA-14633
Background

Currently, we use 2 intermediate buffers while handling decompressed data (one of size 2KB and another of size 16KB). These buffers are (de)allocated once per batch. The decompressed data is first copied to a 16KB buffer and then again copied in chunks to a 2KB buffer.
The impact of this was observed in a flamegraph analysis for a compressed workload where we observed that 75% of CPU during appendAsLeader() is taken up by ValidateMessagesAndAssignOffsets.

Change
With this PR:

we are removing the number of intermediate buffers from 2 to 1. This reduces 1 point of data copy. Note that this removed data copy occurred in chunks of 2kb at a time, multiple times. This is achieved by getting rid of BufferedInputStream and moving to DataInputStream. This change has only been made for zstd and gzip.
we are using thread local buffer pool for both the buffers involved in the process of decompression. This change impacts all compression types.
we pushed the skipping of key/value logic to zstd-jni implementation instead of using the one provided by BufferedInputStream

After the change, the above buffer allocation looks as follows:

Results
After this change, a JMH benchmark for ValidateMessagesAndAssignOffsets demonstrated 10-50% increased throughput across all compression types without any regression. The improvement is prominent when thread cached buffer pools are used with 1-2% regression in some limited scenarios.
When buffer pools are not used (NO_CACHING in the results), we observed GZIP having 10% better performance in some cases with 1-4% regression for some other scenarios. Overall, without using the buffer pools, the upside of this code change is limited to single digit improvements in certain scenarios.
Details results from JMH benchmark are available here: benchmark-jira.xlsx
Testing

Sanity testing using the existing unit test to ensure that we don't impact correctness.
JMH benchmarks for all compression types to ensure that we did not regress other compression types.

One more thing: when it comes to the testing, can we include the case where the batches have a single 10 byte message?

TODO (will update PR in a short while) -

Add benchmark for case when batch contains single 10 byte message
Test consumer performance

@ijuma I have updated this PR by extracting out an interface for the new streams. Please take a look when you get a chance.

This is ready for review. A summary of the changes is provided below.
On the server:

This PR starts using buffer pools to allocate intermediate buffer which is used by the stream that converts compressed to uncompressed data. This is achieved by using new ChunkedBytesStream instead of BufferedInputStream for ZSTD & GZIP. For LZ4 and SNAPPY, which weren't using BufferedInputStream, this is a no op (see point for 2 for changes to them). The impact of allocation on Zstd can be observed from the before & after object allocation flamegraph linked to the JIRA. Please observe how in the after flamegraph, the contribution of allocation by validateMessagesAndAssignOffsets and decreased drastically from 39% to 5%.
This PR reduces the number of buffer pools used during decompression from 2 to 1. Earlier we created a "skip buffer" of size 2KB for ALL compression algorithms and another intermediate buffer created by BufferedInputStream for some of the compression algorithms (ZSTD & GZIP). This PR uses the same intermediate buffer for ZSTD & GZIP, hence reducing the number of allocations to 1 (instead of 2). For LZ4 and SNAPPY, the number of allocations remain same but the 2KB skip buffer is allocated from the buffer pool now.
The skip implementation for some compression algorithms allocated new buffers. As an example, skip implementation of ZSTD-JNI allocates new buffer of different size (from buffer pool) on every skip invocation. This PR uses the intermediate buffer to perform skip instead of pushing it to down to ZSTD-JNI.

The impact of the above two changes on throughput is observed by RecordBatchIterationBenchmark.measureSkipIteratorForVariableBatchSize. You will notice 20-70% improvement there. (see attached benchmark sheet in description)
On the consumer:
The change 1 remains same for consumer and changes 2 & 3 does not impact consumer since it doesn't use a "skip" iterator.
The impact of the above two changes on consumer  throughput is observed by RecordBatchIterationBenchmark. measureStreamingIteratorForVariableBatchSize (note that this a different benchmark that was specified for server, this one doesn't use skipIterator). You will notice mix bag of single digit regression for some compression type to 10-50% improvement for Zstd. The reason that we don't see equivalent gains in consumer is because it copies all uncompressed data in a single buffer and then reads off it. We have not reduced any buffer allocation for consumer scenario(since change 2 & 3 aren't applicable to consumers). There are other optimizations that we can perform for consumer listed below but they are out of scope for this PR.
Future optimisations (out of scope of this PR)

For non-skip iterators (used by consumers), we currently allocate intermediate buffer for decompression and then allocate another buffer for storing key & value. The flow looks like: uncompressed data => intermediate buffer => inputStream => recordByteBuffer. This can be improved to uncompressed data => recordByteBuffer, and hence, we would allocate only 1 byte buffer.
We need to revisit whether we require a skipBuffer for LZ4 and SNAPPY. In the current PR, we wanted to maintain parity with legacy implementation, hence a 2KB intermediate buffer in ChunkedBytesStream is used for them but it could potentially be removed.

Failing tests are unrelated:
Build / JDK 11 and Scala 2.13 / [1] quorum=kraft, isIdempotenceEnabled=true – kafka.api.SaslPlainSslEndToEndAuthorizationTest
14s
Build / JDK 8 and Scala 2.12 / testReplicateSourceDefault() – org.apache.kafka.connect.mirror.integration.MirrorConnectorsIntegrationTransactionsTest
1m 42s
Build / JDK 8 and Scala 2.12 / testReplicateSourceDefault() – org.apache.kafka.connect.mirror.integration.MirrorConnectorsIntegrationTransactionsTest
1m 43s
Build / JDK 8 and Scala 2.12 / testConnectorBoundary – org.apache.kafka.connect.integration.ExactlyOnceSourceIntegrationTest
57s
Build / JDK 8 and Scala 2.12 / shouldFollowLeaderEpochBasicWorkflow() – kafka.server.epoch.EpochDrivenReplicationProtocolAcceptanceWithIbp26Test
12s
Build / JDK 8 and Scala 2.12 / shouldAddNamedTopologyToRunningApplicationWithMultipleNodes() – org.apache.kafka.streams.integration.NamedTopologyIntegrationTest
10s
Build / JDK 8 and Scala 2.12 / testTaskRequestWithOldStartMsGetsUpdated() – org.apache.kafka.trogdor.coordinator.CoordinatorTest

@ijuma , I think this PR is good to be merged now. And @divijvaidya has addressed all your review comments. If you don't have other comments, I'm going to merge it within this week. Thanks.


Teach Linux to use local engine

Description
Copy the linux artifacts!
Related Issues
https://github.com/flutter/flutter/issues/31367

Sorry for the delay on this. I got everything mostly working locally and then noticed buttons weren't working on linux, so I had to take a trip to revert-land.

Updated

I did spend some time investigating moving this to dart, I don't see any big wins yet. File copying constitutes such a big part of the process and yet is so much easier in bash :man_shrugging:

I did spend some time investigating moving this to dart, I don't see any big wins yet.

The big win is not having to then also write it again it batch and then maintaining two ~identical scripts in two different languages for the foreseeable future.

File copying constitutes such a big part of the process and yet is so much easier in bash 🤷♂

An earlier version of this patch did at least the folder copy (and I thought some of the other parts) in Dart, and that code was just a few lines. Is there extra complexity somewhere?

and then maintaining

And keep in mind that we already know we are going to need to make non-trivial changes to the logic here, because re-copying the files on every build is unsustainable; at some point we really need to address the fact that this new build workflow is a significant regression from FDE's due to needlessly thrashing the timestamps of files that are part of the rebuild/relink analysis steps of the native builds. So there is going to be real maintenance cost going forward.
(And we already have a potential solution to that, in the form of re-using the logic from FDE's existing copy script--which is written in Dart.)


PromQL: Add info function MVP

This experimental MVP of the PromQL info function simplifies the implementation by assuming:

Only support for the target_info metric
That target_info's identifying labels are job and instance

info is implemented following the same pattern as traditional join queries, and achieves even (significantly) better performance by only selecting RHS (info) series w/ the correct identifying labels (instance and job). I believe it's possible though to optimize corresponding join queries in the same way, provided that the RHS is a vector selector (the same heuristic should be applicable). The main motivation for following the join query pattern, i.e. perform a second select for corresponding info series and then join, is that info series may be sharded independently of the corresponding non-info series.
Another significant benefit over traditional join queries is that info will resolve conflicts between info series with the same identifying labels, that align to the same timestamp, whereas traditional joins will raise an error for this case. As an example, let's say we have the two following target_info series, both identified by the instance and job labels:

{__name__="target_info", instance="1", job="a", pid="1"}
{__name__="target_info", instance="1", job="a", pid="2"}

If series 1's last sample is at timestamp 1, and series 2's last sample is at timestamp 2, info will need to choose between the two of them for timestamp 2 (since also series 1 is viable for timestamp 2 due to lookback). info picks series 2 since it has the newer sample (timestamp 2 versus timestamp 1).
The info function is disabled by default, and has to be enabled via --enable-feature=promql-experimental-functions.
The below screenshot demonstrates the info function, including three different data labels from target_info (k8s_cluster_name, k8s_container_name and k8s_cronjob_name).

Depends on #14900 (will slim down this PR a bit, once merged).
Usage
Without the info function, to include target_info labels (Prometheus' encoding of OTel resource attributes), you have to write a join query like the following:
sum by (k8s_cluster_name, http_status_code) (
  rate(http_server_request_duration_seconds_count[2m])
  * on (job, instance) group_left (k8s_cluster_name)
  target_info
)

With the info function, you can instead of the above write:
sum by (k8s_cluster_name, http_status_code) (
  info(
    rate(http_server_request_duration_seconds_count[2m]),
    {k8s_cluster_name=~".+"}
  )
)

Known problems

The data label matcher auto completion is imprecise, in that it looks up labels for all time series instead of just relevant info series (by default: target_info)

Maybe this can easily be fixed in the frontend code?

Benchmark results

Benchmark stats for join query vs. info function
✗ benchstat join.txt info.txt
goos: linux
goarch: amd64
pkg: github.com/prometheus/prometheus/promql
cpu: AMD Ryzen 9 3950X 16-Core Processor
                                                                  │   join.txt   │              info.txt              │
                                                                  │    sec/op    │   sec/op     vs base               │
InfoFunction/Joining_info_metrics_with_other_metrics_example_1-32    7.370m ± 6%   2.112m ± 7%  -71.35% (p=0.002 n=6)
InfoFunction/Joining_info_metrics_with_other_metrics_example_2-32   13.278m ± 3%   2.156m ± 3%  -83.76% (p=0.002 n=6)
geomean                                                              9.892m        2.134m       -78.43%

                                                                  │   join.txt   │              info.txt               │
                                                                  │     B/op     │     B/op      vs base               │
InfoFunction/Joining_info_metrics_with_other_metrics_example_1-32   452.3Ki ± 0%   397.2Ki ± 0%  -12.17% (p=0.002 n=6)
InfoFunction/Joining_info_metrics_with_other_metrics_example_2-32   705.7Ki ± 1%   400.6Ki ± 0%  -43.24% (p=0.002 n=6)
geomean                                                             564.9Ki        398.9Ki       -29.39%

                                                                  │  join.txt   │              info.txt              │
                                                                  │  allocs/op  │  allocs/op   vs base               │
InfoFunction/Joining_info_metrics_with_other_metrics_example_1-32   3.474k ± 0%   3.280k ± 0%   -5.60% (p=0.002 n=6)
InfoFunction/Joining_info_metrics_with_other_metrics_example_2-32   5.465k ± 0%   3.322k ± 0%  -39.21% (p=0.002 n=6)
geomean                                                             4.357k        3.301k       -24.24%

@aknuds1 Iiuc the info function implements what is discussed in https://github.com/prometheus/prometheus/issues/13586 for other operators?

@jan--f thanks, I haven't seen that issue. Let me take a look.

@jan--f you mean like the following (linked from #13586)?

When we select node_filesystem_files{ host="$host", mountpoint="/" } - node_filesystem_files_free, we load all the series for node_filesystem_files_free when we could simply select a subset node_filesystem_files_free{ host="$host", mountpoint="/" }

info does optimize versus regular joins in that it only selects target_info series (RHS) with instance/job labels matching the series in the query result (LHS). I didn't know that there were already issues related to this inefficiency.

Played with it, and it seems to do what it should. (I haven't looked at the code.)
Beyond the important restrictions already mentioned above (only works for target_info, not for info metrics in general, however we will define what an info metric is in the future; and only considers job and instance as identifying labels, however we will define what the identifying labels are in the future), we should also mention that a final version should probably accept any PromQL expression returning a vector as the 2nd argument (with the result being used as the superset to pick info metrics from – but which labels to copy can only be restricted if it is a simple label matcher, similar to what the absent function is already doing with guessing labels).

Thanks for the review @beorn7!

we should also mention that a final version should probably accept any PromQL expression returning a vector as the 2nd argument (with the result being used as the superset to pick info metrics from – but which labels to copy can only be restricted if it is a simple label matcher, similar to what the absent function is already doing with guessing labels).

By final version, do you mean a later version than the first experimental one that eventually makes it into main?
I don't think it's been mentioned before that this function should take any PromQL expression returning a vector as the 2nd argument. Assuming it's future functionality, should it just be mentioned in the info documentation?

Minus the comments I put, on the frontend side it looks ok to me.
I am not validating the syntax of the info syntax. This is beyond my knowledge to understand if it doesn't break the PromQL syntax.
I am just validating the frontend code

So this might not work, but intiutively - I would probably evaluate the info function in "populateSeries" by checking if the VectorSelector is under an info function, extract arguments and then just change Series of the VectorSelector. This feels like a nice place to evaluate the info function since at the end - it just changes labels of vector selector thats something we can do when "populating" its series in the first place i think; benefit is that remaining engine is none-the-wiser since we just changed Series and also we dont need to pass the querier around. Ill give it a try if that is a sane suggestion in the afternoon!

We should not use VectorSelector for the second argument in "info", it should be its own AST node.

I'm torn here. On the one hand, I would like to keep it as a normal vector selector so that all the logic applies as usual, even if it isn't helpful in most cases (but no new concept to learn). On the other hand, by creating a new node type, we could also do some fancy stuff, like what people asked at PromCon: OTel resource attributes are often organized with prefixes, e.g. k8s.. It would be cool if we could somehow specify that we want to copy all labels starting with k8s. (but standard label matchers don't have regexp matching on the label name).
Anyway, we can decide that later, once we have seen how this is used in the wild.
(Still planning to look at the documentation part, sorry for the delay.)

We should not use VectorSelector for the second argument in "info", it should be its own AST node.

I'm torn here. On the one hand, I would like to keep it as a normal vector selector so that all the logic applies as usual, even if it isn't helpful in most cases (but no new concept to learn). On the other hand, by creating a new node type, we could also do some fancy stuff, like what people asked at PromCon: OTel resource attributes are often organized with prefixes, e.g. k8s.. It would be cool if we could somehow specify that we want to copy all labels starting with k8s. (but standard label matchers don't have regexp matching on the label name).
Anyway, we can decide that later, once we have seen how this is used in the wild.
(Still planning to look at the documentation part, sorry for the delay.)

I had a shower thought, I think info has some very recursive properties, like info(f(x)) is f(info(x)) i think; i think similar properties hold for aggregations and binary expressions, so that we might be able to assume without loss of generality that info is essentially always just operating on a vector selector ( maybe inside a matrix selector for cases like info(rate(X[2m])) but thats detials ). If that would be the case then we could essentially push it into vector selector node and wouldnt need additonal new AST node for the syntax.

Thank you very much for the updated documentation. It looks much better. Nevertheless, I have come up with suggestions to improve it even more. I don't want to appear picky, but we probably need to explain things quite well, while we also have to cope with the fact that this is reference documentation that cannot be too verbose. (We probably should write a blog post or something about the topic, too.)

Thanks @beorn7, I've applied your feedback. PTAL.

The documentation LGTM now.

@beorn7 could you lift your rejecting review? ;)

Naming
I think it'd be a mistake to call this function info() if it's only applied to target_info and cannot be applied to other info-metrics.
Call it target_info(), same as the metric name?
Or make its signature info(dataseries, infoseries) but require that the info-series be explicitly named, like:
sum by (k8s_cluster_name, http_status_code) (
info(
rate(http_server_request_duration_seconds_count[2m]),
target_info{k8s_cluster_name=~".+"}
)
)
even if it currently just raises an error for info-metric series other than target_info?
It's IMO non-obvious to a reader that info(...) would refer (only) to target_info and not, say kube_pod_info from kube-state-metrics, or other commonly used info-metrics.
Reduce memory use?
Is it possible to avoid loading label value-pairs not needed for the join into memory in the first place, or eagerly discard them, further optimising the memory cost of these info-metric joins?
Conflict handling
The conflict resolution logic can currently be achieved, in cases where the set of enrichment labels has not changed values though other currently unwanted labels on the info-metrics have, with something like:
* on (join_labels)
  group_left(enrichment_labels)
  group by (join_labels, enrichment_labels)

but it's unpleasantly verbose, repetitive, harder to read, and only effective where there has been no change in the labels of interest. So this proposal looks like a great enhancement overall.
However, a similar effect could possibly be achieved in a more general way with a function to pick the labels of the series with the most recent sample timestamp in a matching set. Lets imagine this function is most_recent_labels_by(...):
sum by (k8s_cluster_name, http_status_code) (
    rate(http_server_request_duration_seconds_count[2m]),
    * on (job, instance)
      most_recent_labels_by(
        target_info{k8s_cluster_name=~".+"},   # info-series
        "job,instance",   # cardinal labels which determine series uniqueness
        "pid"   # non-cardinal labels we want to emit into the resulting info-metric series; empty for all labels in the most recent sample
      )
  )
)

It's still a bit verbose and repetitive compared to the way the proposed info(...) knows which label values are cardinal for series. But it could then apply to kube_pod_info etc too e.g.
some_data_metric
* on (uid) most_recent_labels_by(kube_pod_info, "uid", "node,pod_ip")

Just quickly: The plan is to make info work on all info metrics, and to automatically use the actual identifying metrics. The PR here is an MVP to test the functionality and usefulness before investing the significant effort to fully implement the info function.

If this function is not easily generalised in future to work for info-metric series other than target_info in future (due to the requirement that the label pair to match on is job,instance) then should it be called info()? Or would it be better renamed target_info() to reflect the metric it is intended to be used with?

@ringerc as @beorn7 kindly clarified out in the meantime, info is planned to work for all info metrics, not just target_info. I'd like to additionally point out that, even though the identifying labels are indeed hard coded as instance and job, the user can specify other info metrics than the default (via __name__ label matchers).

@ringerc

Is there any intention to allow this function to accept other labels as the cardinal set of labels in future? Otherwise its generic name info seems a bit misleading, as it can only really report on info-metrics that have (job,instance) as their uniquely identifying label set.

By cardinal set of labels, do you mean the identifying labels? I.e., instance and job currently.

It might make sense to have it accept an optional parameter for them

We haven't yet thought of syntax for allowing specification of the identifying labels.

If omitted, it could default to "job,instance". (or ideally a configurable mapping of metric names -> label sets, or one discovered by querying a meta-info series in the tsdb to map a metric name to its canonical set of cardinal labels... but that's feature creep)

I did test the waters with a proposal that included allowing configuring metric names -> identifying label sets, but the implicit nature of this functionality didn't resonate with Prometheus developers.
The idea is that when Prometheus eventually has native support for persisting metadata, info could automatically determine find info metrics and determine which are their identifying labels. The current default info metric (target_info), and hard coded identifying labels (instance and job) would then no longer be the case.

I often don't need, or want, all the labels on an info-metric.
This function's current signature doesn't offer a way to choose only some labels to enrich.

The second argument to info lets you pick which data labels to include though? Please see the third point in the "How" of the proposal.

Why does the function require that an info-metric series be selected using a {name="kube_pod_info"} matcher rather than a concrete metric series identifier like kube_pod_info ?

I believe we actually want to support this syntactic sugar, even though we haven't yet implemented it in the MVP. Implementing the second argument the way we want has proven tricky.

Is it feasible to extract the most-recent-sample selection logic for possible future reuse in another helper function like latest_sample_by(series, "cardinal,labels") that would find the most recent datapoint in series grouped by the label set (cardinal, labels) and return the data-value and its full associated labels? Effectively what this proposed info function is doing, but in a more general form?

I would suggest making the necessary refactoring in an eventual PR for introducing functionality where you'd need it (latest_sample_by?) :)

By cardinal set of labels, do you mean the identifying labels? I.e., instance and job currently.

Right.

We haven't yet thought of syntax for allowing specification of the identifying labels.

That's the point really - whether the function signature needs to change, and whether that can happen easily once it's added (even as experimental).

The second argument to info lets you pick which data labels to include though? Please see the third point in the "How" of the proposal

Ah. I lost track of that when digging into the function. That seems fine.
Using the selector to represent it seems strange in usability terms to me - I would not expect selector labels to directly control what the output of a function that consumes the selector is, only indirectly via which series get matched. So I think it's a bit odd in usability terms.
It would make more sense to me for the selector labels to control the identifying label set, rather than the output label set for enrichment. Then to have a separate argument that's a list of label names to specify labels to propagate to the output.

I would suggest making the necessary refactoring in an eventual PR for introducing functionality where you'd need it (latest_sample_by?) :) It would be easier to evaluate such a refactoring, if it's rooted in a concrete need.

OK, that makes sense, thanks.

WRT how to tell what the identifying labels are: One of the basic ideas is that this information is already present in the TSDB. Ideally, the targets exposing info metrics will already mark what the identifying metrics are (which is something OpenMetrics already allows).
BTW, the discussion here repeats aspects that already got their treatment when the design doc was presented. I recommend to have a look at https://github.com/prometheus/proposals/blob/main/proposals/2024-04-10-native-support-for-info-metrics-metadata.md .

That can be checked at parse time.

@bboreham could you elaborate, please? Not sure what you have in mind :/

/prombench start

/prombench main

After discussing w/ @bboreham today, I've re-targeted the PR on the release-2.55 branch (after rebasing accordingly).

No idea why CI checks fail btw, the PR is based on latest release-2.55.


[Q] Which is the port I should expose in my docker container to use keras Wandbcallback() to log models in wandb?

I am currently logging my Keras weights in my Weights and Biases environment using Wandbcalback(). It works fine when I do it from my local machine.
When I do from a container, that is being used in the GCP cloud provider, the models are never being logged. I belevie I should expose some port in the container and in the machine to allow communication with Weights and Biases platform, but I can not find it in the documentation.

Hi @mathbr10, are you using wandb server when you use GCP? If you are can you make sure that the permissions are properly set up?

Hey @mathbr10, by default our library logs data to our hosted service at https://wandb.ai, this is the simplest way to use wandb and doesn't require any port forwarding.
If you want to run your own private wandb server you'll want to configure a load balancer and DNS then you can configure the SDK to use that server by setting the WANDB_BASE_URL environment variable.

Hello @lesliewandb, no I am only using Wandbcallback() and normal wandb run. I did not set those permission but they are related to wadb server wright?

Hi @vanpelt, yes maybe the port is not the poblem. I want to use your hosted serve in wandb.ai, but when I use keras WandbCallback  (https://docs.wandb.ai/ref/python/integrations/keras/wandbcallback) it does not logs the model in my gcp machine. It logs if I train in my local machine though.

Are you seeing any error messages in the logs?  You still need to call wandb.init before calling model.fit with the callback.  It could be that your containers have firewall rules that prevent access to the internet, but you would see errors in the logs.

Hello @vanpelt yes I am calling it. I am sending attached the output log
output.log. Below I am sending also the callback structure we are using.
earlystopping = EarlyStopping(monitor="val_loss", patience=5, restore_best_weights=True)         # TODO: add schedulers here         self.callbacks = [             earlystopping,             tf.keras.callbacks.ModelCheckpoint(                 "ckpts/weights.{epoch:02d}-{val_accuracy:.5f}.hdf5",                 monitor="val_accuracy",                 verbose=1,                 save_best_only=False,  # save all the checkpoints                 # was showing error because the model's ist parent is tfimm not tf.keras.Model                 save_weights_only=True,                 mode="max",                 save_freq="epoch",             ),             WandbCallback(                 save_model=True,                 monitor="val_accuracy",                 mode="max",                 save_graph=True,                 save_weights_only=True,                 log_weights=True,                 log_gradients=False,             ),         ]

Data is being download from wandb in my pipeline. Where is located the ./wandb/debug-internal.log I cant find it in the logs. Ok I will try this approach and get back to you soon.

@mathbr10 since we haven't heard from you, we are going to close this issue. Feel free to re-open if you still have follow up questions.


Fix regex

Update regex to match new pr label format
Addresses #25

Should we include student name as part of the pattern?
LO number should allow double digits. i.e. W2.10a
more negative test should be included. If students forgot about the format they would likely submit a random string for the title.
first 2 tests can use regex.test.toBe(bool) instead of exec

Student names are not always required. Not sure abt this semester, but in past semesters, sometimes you are required to submit a single PR as a group, which doesnt include the student names
I did not think it would reach 2-digit :p
if you can suggest some examples, would be nice :D
exec with comparison to null is used because that's closer to the actual usage in the code.

OK this im not too sure. I am just reading off the instructions gave to the students
there are. if you look at wk 3, there's w3.10. Anyway it is very easy to make it a bit more robust
any english phrase would do. e.g. PR for week 3 LO, just 1 negative example to capture such impossibility.
should tests be testing against implementations? if they decide to return empty array next time this test would fail though.

Actually empty array would not be the same as null, so it would still be fine as it is.
2, 3 I 'll do some revisions to address them

is there a typo? if empty array is not the same as null toBeNull would fail.

the first set of tests is checking for not.toBeNull


Memleak-ish behavior of PutObjectWithContext

Hi,
I'm uploading a lot of data from a machine that has just couple of Gs of RAM.

I made some experiments end it turns out that if I configure the GC to run more often it seems to work, but it isn't a real solution.
It seems that minio has somewhere a buffer that gets allocated on every read and waits for the GC to be freed. Maybe you could just use one buffer and reuse it?

Please share a full program to show the issue..

So it's something like this. The problem occurs when writeABigFile is called. Minio gets about 14G of data to send and the machine has about 1G of RAM. When I replace minio with the commented loop it works.
	wait := sync.WaitGroup{}
	wait.Add(1)

	pipeReader, pipeWriter := io.Pipe()
	var errWrite error
	go func() {
		defer wait.Done()
		defer pipeWriter.Close()

		zipWriter := zip.NewWriter(pipeWriter)

		errWrite = writeABigFile(ctx, db, zipWriter)
		if errWrite != nil {
			return
		}

		errWrite = zipWriter.Close()
		if errWrite != nil {
			return
		}
	}()

	_, err := minioClient.PutObjectWithContext(ctx, bucket, name, pipeReader, -1, minio.PutObjectOptions{ContentType: "application/octet-stream"})
	if err != nil {
		return
	}

	// If the call to minio is replaced with this there's no problem:
	/*
	buffer := make([]byte, 1024*1024)
	for {
		_, err := pipeReader.Read(buffer)
		if err != nil {
			break
		}
		time.Sleep(time.Second * 5)
	}
	*/
	wait.Wait()

	return errWrite

As a quick workaround, does it help if you set 'PartSize' in the options to, say 128MB?
It does seem like the defaults are a bit wonky, which should be fixed.

It is not a mem-leak if the input size is "-1" minio-go automatically assumes the maximum possible memory size to fit 5TiB - in S3 API content-length is a must either it's multipart or since PutObject()
This is a minio-go only functionality that allows -1 with the pretext that the user perhaps wishes to upload a large file even while still keeping the upper bound of 5TiB. In AWS S3 per multipart, there can be at max 10000 parts so minio-go automatically chooses 512MiB per part size.
This can be definitely reduced by using the PartSize as mentioned by @klauspost so if you did override the auto calculation by specifying a part size - you have to assume that your total upload size automatically reduces based on the part size.
1GiB RAM is generally not a practical scenario of what you are requested @janekolszak minio-go automatically uses 4 go-routines with each 512MiB of RAM - this would easily exceed your arbitrary limit.
if your use-case is that use minimal RAM avoid passing -1 instead pick a proper content-length of the stream.

@harshavardhana It still seems like bad behavior and it appears there was an intent to set a default part size so it isn't infinite.
See the PR, which sets a 128MB default part size. I would say that is pretty reasonable behavior.

I'm not sure the PartSize is the problem. I think that the GO's garbage collector just doesn't free all the buffers in time. I can of course configure GC to run more often (and it works), but it's an overkill - it slows down the app just to fix a bug in minio.
Maybe there should be a callback to run every time a part is sent.
Or better just reuse one buffer instead of creating new ones?

@janekolszak Have you tried setting the PartSize?

@harshavardhana Close?

Closing as per https://github.com/minio/minio-go/issues/1176#issuecomment-546856662

This can be definitely reduced by using the PartSize as mentioned by @klauspost so if you did override the auto calculation by specifying a part size - you have to assume that your total upload size automatically reduces based on the part size.

@harshavardhana so this workaround with custom PartSize should work? I'm getting error with it
t := time.Now().Add(retention)
opts := minio.PutObjectOptions{
    RetainUntilDate: &t,
    ContentType:     "text/csv",
    PartSize:        64 * 1024 * 1024,
}
_, err := client.PutObjectWithContext(ctx, "bucket", "key", reader, -1, opts)
if err {
    log.Fatal(err)
}

Part size * max_parts(10000) is lesser than input objectSize.


Cannot use multiprocessing with cythonized code

Hi
I have a problem with multiprocessing and cythonized code:  methods cannot be pickled and so it fails. The problem comes from the cloudpickle library, that cannot pickle a cython function.
I have made a small demo, just unzip the attached file in a directory and run the commands:
test.tar.gz

Python
python test_dummy.py
Cythonized code

python setup.py build_ext --inplace
python test_dummy.py

There is a pickling error
_pickle.PicklingError: Can't pickle <cyfunction DummyClass.test at 0x10cfa9c80>
For now, my very dirty fix is to overload dask multiprocessing package _dumps method before using it:
dask.multiprocessing._dumps = pickle.dumps

Do you have cloudpickle installed? If not, can you please install it and retry? Thanks.

I have cloudpickle (0.4.0) installed

So I think this is a Cython bug. Issue ( https://github.com/cython/cython/issues/1606 ) in particular seems relevant. That said, it looks like it got fixed at some point.
Would try recompiling with the latest Cython (if you are in a position to do that).
If you are unable to compile the Cython code, might try adding a Python function, which can be pickled, on top of this method call. This second case is a little kludgy, but should help get things working at least.

Any updates on this @hdhoa?

Closing as non-responsive.

Could reasonably be argued to be out of scope as well. Seems it was a pickling issue with Cython functions, which while it may affect Dask use cases, is not itself an issue with Dask.


Add a new param -v to activate verbosity

This PR adds a new param -v that prints the Running jobs, before it was always printing.

I don't know, I think by default it should just run the tests, if you want to know where it get stuck you can run with -v. By default the logs are really hard to read otherwise, cause any test result is interleaved with logs about running process.

Fair enough, I still think that logs in the verbose mode are useful as they show the running jobs but they are useless as to show the success/failure of tests as is all mixed up.


Fix place_on_monitor version

It don't have version in gir https://developer.gnome.org/gtk3/stable/GtkMenu.html#gtk-menu-place-on-monitor

Hum, strange... Thanks!


No property to display all client commands

Currently, there's no property to display all client commands.

there is this.handler.categories which you can iterate over and get the commands through there if that's what you mean?

this.handler.categories is the categories, each category has commands in it.
Additionally, this.handler.modules is a Collection<string, Command>, so I really don't get what you're saying.

What I'm saying is that it's currently possible to display all categories commands, but what if you want to list all of them? You'll need to loop all categories and show the commands. There could be a simple way by adding a Client property and making it array.

You'll need to loop all categories and show the commands.

There could be a simple way by adding a Client property and making it array.

Would not happen.
Command handlers, listener handlers, and inhibitor handlers are all AkairoHandlers, which have a modules property, containing their modules (commands etc.), if you want a client property, add a getter, the "issue" you mentioned, is not an issue.


Fund raise: support Google Places API

One of high rated feature request is supporting Google Places API.

https://developers.google.com/places/
The places API allows you to get the place information, not just latitude/longitude, but also place name, phone number ... etc.
Places Picker

Auto complete

Place details

I can implement the features for both Android and iOS, but it's kind of heavy task.
It means I need to work a lot in my private time.
If you want to implement this feature for this plugin, please donate to this project.
I will start development when the amount is reached to $2,000 USD.
Google Places API has many features. So I will create another plugin for this feature.
That's why $2,000USD for this time. (Generally $1,000USD for one feature implementation)
Since creating new features is stressful work, spending lots of my time, bug fixing...etc.
I appreciate for your understanding, and for your kindness.

The benefits of donors are:

access to the beta test features in advance
(I will notify you when I am ready. )

support your project in private
(during the beta test, and only for the feature)

feature request for the places api

Fundraise amount: $2,000 USD
Minimum donation amount: $100 USD per person (with private support)
From $50 to $100USD, I will let you know the work progress, and access to the beta test in last minutes.
(* The word in last minutes means pre-release version. It is not released yet, but planing very soon)
Less $50 USD, I appreciate for your donation.

Paypal
(Please write a memo for places api when you donate some amount)

Bitcoin
(Please let me know when you donate some Bitcoin. I'm not familiar with Bitcoin actually, so I don't want to miss you)
3LyVAfANZwcitEEnFbsHup3mDJfuqp8QFb

If you have open question, please post here on this thread.

Thank you for your donation, Saud.

@wf9a5m75 are you planning to create Ionic Native wrapper too?

@battika I will determine that after I create the JS version.
If I feel the JS version is too easy, I will create the native wrapper as well without no additional fundraise.
Otherwise, I might consider another fundraise.

I have been considering another option that paid plugin for this development instead of fundraise.
Since the most people are fine with the maps plugin, but some people want to use additional places feature.
Thus, pay additional cost for the people who want to use it. That's another fear style I think.
Of course, I will issue the token for whom pay during this fundraise. These people do not need additional payment.

It looks line nobody is interested in the places API except Saud.

Since the fundraise is not reached to the amount, I put back this fundraise at once. I refund the amount to donors.


Build error

Build error during "Linking CXX executable tuxdump"
Full console output: https://pastebin.com/raw/HeRWhnmL
I think this has something to do with a329696fd4a0729d4d9b386ee7746d045376dc41? libconfig++-dev is installed.

They are probably sort-of related.  My guess is your version of libconfig++ doesn't come with the CMake file, and I forgot to set the pkg-config version when I made the update.  Shouldn't be a tough fix.

Should be working with latest commit... simplified it down to rely on pkg-config only.  Let me know if you run into any issues.

Builds a-okay. Cheers


For YarnApplicationOperation, respect the FinalStatus first and wait the FinalStatus if YarnApplicationState is FINISHED

Why are the changes needed?

We shall respect the final application status first.
Otherwise, the batch state is not consisted with the app state.
FYI:

How was this patch tested?

[ ] Add some test cases that check the changes thoroughly including negative and positive cases if possible

[x] Add screenshots for manual tests if appropriate

[x] Run test locally before make a pull request

cc @ulysses-you @yaooqinn @pan3793

I think it's good for Yarn Cluster mode, but there may some issues on Yarn client mode, see SPARK-36540.

https://github.com/apache/incubator-livy/blob/50faa9f68a6f1c79f605a4cb70e452f9c7f21528/server/src/main/scala/org/apache/livy/utils/SparkYarnApp.scala#L236-L259

I think it's good for Yarn Cluster mode, but there may some issues on Yarn client mode, see SPARK-36540.
It should be fine, we also refer the process.exitValue.

Codecov Report

Merging #3928 (0e251d9) into master (a0fc33c) will decrease coverage by 0.10%.
The diff coverage is 31.81%.

@@             Coverage Diff              @@
##             master    #3928      +/-   ##
============================================
- Coverage     51.91%   51.81%   -0.11%
  Complexity       13       13
============================================
  Files           508      521      +13
  Lines         29019    28772     -247
  Branches       3984     3851     -133
============================================
- Hits          15066    14908     -158
+ Misses        12525    12491      -34
+ Partials       1428     1373      -55

Impacted Files
Coverage Δ

...pache/kyuubi/engine/YarnApplicationOperation.scala
58.73% <31.81%> (-4.24%)
:arrow_down:

.../kyuubi/server/mysql/constant/MySQLErrorCode.scala
13.84% <0.00%> (-6.16%)
:arrow_down:

...ache/kyuubi/server/mysql/MySQLCommandHandler.scala
77.77% <0.00%> (-4.05%)
:arrow_down:

...uubi/plugin/spark/authz/util/SemanticVersion.scala
50.00% <0.00%> (-3.58%)
:arrow_down:

...ache/kyuubi/operation/KyuubiOperationManager.scala
79.45% <0.00%> (-2.74%)
:arrow_down:

...ache/kyuubi/server/mysql/MySQLGenericPackets.scala
76.59% <0.00%> (-2.13%)
:arrow_down:

...rg/apache/kyuubi/ctl/cmd/log/LogBatchCommand.scala
63.93% <0.00%> (-1.64%)
:arrow_down:

.../org/apache/kyuubi/ha/client/DiscoveryClient.scala
34.78% <0.00%> (-1.59%)
:arrow_down:

...he/kyuubi/plugin/spark/authz/IcebergCommands.scala
96.29% <0.00%> (-1.38%)
:arrow_down:

...n/scala/org/apache/kyuubi/engine/ProcBuilder.scala
80.74% <0.00%> (-0.63%)
:arrow_down:

... and 24 more

:mega: We’re building smart automated test selection to slash your CI/CD build times. Learn more


Culture is not supported. (Parameter 'culture'). 8192 (0x2000) is an invalid culture identifier.

Type: Bug
NPE version: <IP_ADDRESS>
OS version: Windows 10 Home 19041.329
Installed from: Microsoft Store

What is the current result?

After choosing Open package from online feed, I get the following dialog:

Culture is not supported. (Parameter 'culture'). 8192 (0x2000) is an invalid culture identifier.
After closing the dialog, the application quits.

Is there a package on Nuget.org which shows the bug?

It doesn't appear related to a specific package.

Do you know the locale settings for your computer? What language is it set to?

English (Israel), I guess, based on Settings -> Region.
Is there somewhere I can find the precise information you're looking for?

After closing the dialog, the application quits.

More precisely, the application doesn't quit right away. But any further interaction with the UI (clicking on buttons, selecting from the package list, clicking on the search textbox, closing the online package selection window) and the entire application shuts down without any further message.

Stack trace here: https://github.com/NuGetPackageExplorer/NuGetPackageExplorer/issues/1057
This is likely a WPF issue and should be filed on dotnet/wpf.

I installed .NET 5 Preview 7, and the issue has been resolved.

Hmm... upgrading to preview7 didn't resolve it for me.
I guess NugetPackageExplorer needs to be re-compiled with preview7 since it includes all the BCL libraries?

@jnyrup I should also add that I downloaded the nightly build of NPE as well.

Ahh, of course.
I thought you meant upgrading to preview7 and running the latest NPE from https://github.com/nugetpackageexplorer/nugetpackageexplorer/releases


Should verify command "ignore" all errors?

See the conversation thread at https://github.com/openssl/openssl/pull/10132#discussion_r361874072
Should verification always try to proceed, to catch and diagnose as many errors as possible?  See the switch at https://github.com/openssl/openssl/blob/master/apps/verify.c#L376

Marking as inactive, will be closed at the end of 3.4 dev barring further input


Correct rmw_take() return value.

A tiny fix. I believe this was introduced in #408, and compilers implicitly casted a bool literal into an rmw_ret_t value.

CI up to rmw_connext_cpp

Linux

Going in.


⚠ CIOOS Pacific ERDDAP dataset ECCC_MSC_BUOYS has degraded performance

In 6f783aa, CIOOS Pacific ERDDAP dataset ECCC_MSC_BUOYS (https://data.cioospacific.ca/erddap/tabledap/ECCC_MSC_BUOYS.htmlTable?wmo_synop_id&time>now-3hours&distinct()) experienced degraded performance:

HTTP code: 503
Response time: 16679 ms

Resolved: CIOOS Pacific ERDDAP dataset ECCC_MSC_BUOYS performance has improved in f87ca3d.


feat!: add options as parameter to constraints

Description
This PR adds options as part of the constraint callbacks so you have direct access to them when the models are being constrained, i.e. for conditionally changing the behavior.
This is only a breaking change if you use the current constraint types in TS integrations.
Related issue(s)
Part of solving https://github.com/asyncapi/modelina/issues/1475

Thanks for the review folks 🙇


Select and tranform json data

In our project, we need to select and transform json data structures. We just discovered a framework called st.js which would fit for our needs very well. What is the easiest way to integrate that in karate js api?

@colameo Karate has JsonPath built-in and you really don't need anything else. Look at the doc and some of these examples.

...hm, I might asked the wrong question ;-) the question is moerw

Karate actually is implemented in Java but can run 'plain' JS. So there is a chance that if you use advanced JS libs it wont work, ES6 and npm modules certainly won't. So I guess the answer is that it is not supported. My point is you have all the power you need already, why would you need anything else. If you do, we can add it to Karate.


[3.1][pipeline-connectors] Add pipeline Sink for Pulsar.

Search before asking

[X] I searched in the issues and found nothing similar.

Motivation
Add pipeline sink  support for pulsar
Solution
No response
Alternatives
No response
Anything else?
No response
Are you willing to submit a PR?

[ ] I'm willing to submit a PR!

Hi, @lvyanquan I am willing to try this task, can you assign this task to me?

@ToJ112 Hi, I don't have the authority to assign, but I raised a pr for Kafka sink(Although there are some details to be determined), You may take it as a reference.

Closing this issue as it has been migrated to Apache Jira.


Only allow NGS 2011

@seanfernandez: Do we even need to present a drop-down for this, or just permanently populate the respective fields (below) with "NGS 2011"?
This is found on the Ellipsoid Height selection for submitted geographic coordinates:

And the Zone and Units section for grid coordinates:

Remove NGS Adjustment completely for Ellipsoidal height.
Only allow NGS 2011 for State Plane. It can either remain in the dropdown as the only option or just be permanently added to the results.

I suggest we add (NGS 2011) next to the ellipsoid height label so they know the format to enter. The single item dropdown is a bit of a UX mistake.

actually it was a mistake to have NGS 2011 as an option for ellipsoid height in the first place (my fault).The ellipsoid height for NAD83 is based on a mathematical ellipse called GRS80, which is for all intents and purposes the same as WGS84, so an NGS adjustment is never applied to the vertical for ellipsoid height.
With that said, please remove any adjustment option or reference to and adjustment for ellipsoid height.

I'll break this into some new issues


Enabled tests by adding opencv_extra as a lazy artifact

Testing on x86 (on ubuntu) was disabled due to a very basic error stemming from just creating a CxxWrap StdString from
img_gray = OpenCV.imread(joinpath(test_dir, "shared", "pic1.png"), OpenCV.IMREAD_GRAYSCALE)

Cf. https://github.com/JuliaImages/OpenCV.jl/actions/runs/5725287556/job/15513486710#step:6:188
Looks like it's this: https://github.com/JuliaInterop/CxxWrap.jl/issues/310


Prevent decompose_blocksub from segfaulting when ALT=.

I experienced segfaults after working with files that had been
processed with bcftools view -a. Regardless, ALT=. is a valid VCF
line and vt should not crash.

I've changed it to:
size_t alt_len = n_allele==1 ? 0 : strlen(allele[1]);
if (aggressive_mode && (ref_len!=alt_len) && (ref_len!=1) && (alt_len>1))


Add additional TF controls

Is your feature request related to a problem? Please describe.
A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]
Describe the solution you'd like
A clear and concise description of what you want to happen.
Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.
Additional context
Add any other context or screenshots about the feature request here.

It will be taken up based on the requirement.


Fix obvious bug in SLF4JLoggerContext (and related typo in LoggerTest)

Yo Log4j maintainers - hope this helps?

Builds failing? I've opened https://issues.apache.org/jira/browse/LOG4J2-3229.
BTW should I be raising a 2nd PR to cherry-pick this to release-2.x from master where I'm submitting this one to, after it's LGTM & merge? Or does that happen automatically? Or do committers do this for PRs from contributors? Just asking to learn how you work in this community. (I'm an Apache committer on other projects.)

Hello @vorburger,
Please base your PR on the branch release-2.x.

It would be helpful to describe what has been resolved rather than using the description fixed bug in ClassName ;-)
I'd appreciate it if you could PR into release-2.x instead of master. The CI system works better on that branch, and it's what we release. I have an issue open with infra to change the default branch on this repo.

Please base your PR on the branch release-2.x.

done

It would be helpful to describe what has been resolved rather than using the description fixed bug in ClassName ;-)

done

I'd appreciate it if you could PR into release-2.x instead of master. The CI system works better on that branch, and it's what we release. I have an issue open with infra to change the default branch on this repo.

Good to know. Perhaps you would like to leave a related comment in https://issues.apache.org/jira/browse/LOG4J2-3229.

BTW just FYI this PR is a result of my staring at this code in the context of LOG4J2-3282 - it seemed like a Good Idea to fix this before copy/pasting this code into a new place... 😄

lgtm, thanks for the contribution! I'll get this merged once tests complete.
I've filed https://issues.apache.org/jira/browse/LOG4J2-3284 for tracking.


chore: Direct tenant service in getting tenand ID

Summary by CodeRabbit

Refactor

Enhanced application data retrieval by integrating tenant-specific services, improving user experience in multi-tenant environments.

Oh freak. Thanks for noticing. I refactored and redid this so many times, I completely missed that. Let me get back. It was supposed to be tenantRepository. 🤦


chore(app): fixing some code smells

:tada: This PR is included in version 1.1.1 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:


Automated Package Upgrade

:tada: This PR is included in version 25.6.83 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


E3D ToolChanger support

Thank you Brendon for your contribution to the Open5x repo. This upgrade significantly reduces overhead allowing simpler, and more efficient conversion of open5x on E3D's tool-chagner hardware


Add eth-objects

Here are the Ethereum objects as I have mapped them so far. While there are only two underlying structures (RLP and Eth-(Secure-)Trie), they interpret the format of the leaf values based on context, which is lost when resolving at the IPLD level. I sketched out some versions that used fewer IPLD formats by employing some cleverness in the path naming conventions. (see here https://github.com/MetaMask/metamask-plugin/issues/719#issuecomment-267528294). The consensus was to be explicit instead of clever, thusly the list of objects as I've proposed.
I'd additionally like to reserve 0x99-0x9f for additional Ethereum objects I may have missed or may be introduced when Ethereum milestone Metropolis is released.

Going to go ahead and merge this, consider 0x99-0x9f reserved :)


Unable to delete files created in rootless mode

rm -rf ~/.local/share/containers fails
~ (aws:rean-gov-sd)(kc)$ find .local/share/containers/ ! -user frezbo -exec ls -l {} \;
total 0
drwxr-xr-x. 2<PHONE_NUMBER>91 6 Aug  9 23:52 leases
drwxr-xr-x. 2<PHONE_NUMBER>91 6 Aug  9 23:52 links
total 0
total 0
total 0
drwxr-xr-x. 2<PHONE_NUMBER>91 6 Aug  9 23:52 leases
drwxr-xr-x. 2<PHONE_NUMBER>91 6 Aug  9 23:52 links
total 0
total 0
~ (aws:rean-gov-sd)(kc)$

Is this expected? I assumed them to be owned by the current user when using usernamespaces

If fhey were created inside of the USERNS but not as Root files, then you will have to enter the USERNS to be able to delete them.
buildah unshare allows you to enter the USERNS and you can delete them. We probably need to create a podman unshare.

@rhatdan thanks that  makes sense and it explains why podman is able to remove them when deleting the image. I will close this.


Only download descriptions

I downloaded a youtube channel but forgot to download the descriptions for the videos! I now know that to download the descriptions we include --write-description in the command, but I don't see how I can download only the descriptions, seeing as I'd rather not download GBs worth of videos all over again just for the descriptions. So, how can I just download the descriptions from each video in a channel? Thank you!

Use --skip-download.


add purge-config loader

Short Description and Why It's Useful

Adds loader that clears properties from config in build. Those properties list can be extended by adding to config.purgeConfig (add properties that are used only for server.ts and related)
Screenshots of Visual Changes before/after (if There Are Any)

Which Environment This Relates To
Check your case. In case of any doubts please read about Release Cycle

[ ] Test version (https://test.storefrontcloud.io) - this is a new feature or improvement for Vue Storefront. I've created branch from develop branch and want to merge it back to develop
[ ] RC version (https://next.storefrontcloud.io) - this is a stabilisation fix for Release Candidate of Vue Storefront. I've created branch from release branch and want to merge it back to release
[x] Stable version (https://demo.storefrontcloud.io) - this is an important fix for current stable version. I've created branch from hotfix or master branch and want to merge it back to hotfix

Upgrade Notes and Changelog

[x] No upgrade steps required (100% backward compatibility and no breaking changes)
[x] I've updated the Upgrade notes and Changelog on how to port existing Vue Storefront sites with this new feature

IMPORTANT NOTICE - Remember to update CHANGELOG.md with description of your change
Contribution and Currently Important Rules Acceptance

[x] I read and followed contribution rules

@gibkigonzo could you please add cloudflare to purgeConfig array in config? I believe it would prevent more people from publishing Cloudflare key unconsciously.

@Fifciu sure, I will add this :ok_hand:


Add tests

Q
A

Is bugfix?
❌

New feature?
❌

Breaks BC?
❌

Fixed issues
#64

Issue #64 already fixed. This PR add tests. + removed unused code from tests

:+1


undefined: readline.NewCancelableStdin

When I try to go build I get this error:
# wmcli/vendor/github.com/manifoldco/promptui
vendor/github.com/manifoldco/promptui/select.go:232:12: undefined: readline.NewCancelableStdin

I'm hitting the same issue, but I suspect this is because my project uses dep for modules and that the tool does not honour the pinned versions for that library.

I'm hitting the same issue, but I suspect this is because my project uses dep for modules and that the tool does not honour the pinned versions for that library.

I have the same problem and i had to move my dep to go modules and now works :/


panningDirection parameter added to InteractiveViewer

It adds a new Axis? parameter to the Interactive Viewer called panningDirection that let's you lock the panning to a certain axis.
Fixes https://github.com/flutter/flutter/issues/108935
Pre-launch Checklist

[x] I read the Contributor Guide and followed the process outlined there for submitting PRs.
[x] I read the Tree Hygiene wiki page, which explains my responsibilities.
[x] I read and followed the Flutter Style Guide, including Features we expect every widget to implement.
[x] I signed the CLA.
[x] I listed at least one issue that this PR fixes in the description above.
[x] I updated/added relevant documentation (doc comments with ///).
[x] I added new tests to check the change I am making, or this PR is test-exempt.
[x] All existing and new tests are passing.

If you need help, consider asking for advice on the #hackers-new channel on Discord.

@NazarenoCavazzon Thanks for the PR!  Overall I think this parameter makes sense, I agree that alignPanAxis doesn't quite do what you want.
It looks like you ran a formatter on these files, though.  Would you be able to undo the formatter changes so that this is easier to review?

Yep, didn't saw it hahahaha, I'll undo it

I have also a question, do I need to update the flutter version or make a document like this one explaining the changes and the tests I added?

@justinmc I reverted the formatting, let me know if you need something

I like more the enum approach, it makes more sense

@justinmc I made the alignPanAxis and Enum.

Everything ready 2 review

Ready 2 review

Thanks for your persistence on this PR and for fixing those last few comments!  This will be merged when the build is green.

Thanks for reviewing it!


chore(Geohash): Fix various warning emitted by elixir v1.17.0

Fixes warnings emitted by the elixir compiler around character lists. The preferred syntax is now to use ~c"" instead of single quotes. There is also an update to how Config is loaded. This PR also updates dependencies to their most recent versions. Finally there is a fix with application loading where subsequent tests would fail to run due to ExUnitProperties not being found.
https://hexdocs.pm/elixir/1.12/Config.html#module-migrating-from-use-mix-config
https://www.amberbit.com/blog/2017/9/22/elixir-applications-vs-extra_applications-guide/

Come to the repo to see if I could fix the warnings and saw there is already a PR. Thanks <3