pyftsubset: problem with SVG table subsetting

I tested pyftsubset’s SVG-table-subsetting capabilities with Noto Emoji SVG, and found an issue:
pyftsubset NotoColorEmoji-SVG.otf --unicodes=U+1F600,U+1F601,U+1F602,U+1F603,U+1F604,U+1F605,U+1F606,U+1F607,U+1F608,U+1F609,U+1F60A,U+1F60B,U+1F60C,U+1F60D

(subset to contain only a few emoji)
The resulting SVG table looks like this:
  <SVG>
    <svgDoc endGlyphID="1" startGlyphID="1">
      <![CDATA[<svg xmlns="http://www.w3.org/2000/svg" id="glyph1712" viewBox="-4<PHONE_NUMBER>3333333<PHONE_NUMBER>6666667<PHONE_NUMBER>6666667"><g id="facial_expressions"><radialGradient id="face_1_" cx="63.22" cy="216.9" gradientTransform="matrix(1 0 0 1 0 -154)" gradientUnits="userSpaceOnUse" r="56.9597"><stop offset="0.5" stop-color="#FDE030"/><stop offset="0.92" stop-color="#F7C02B"/><stop offset="1" stop-color="#F4A223"/></radialGradient><path id="face" d="M63.22,118.8c-27.9,0-58-17.5-58-55.9S35.32,7,63.22,7c15.5,0,29.8,5.1,40.4,14.4 c11.5,10.2,17.6,24.6,17.6,41.5s-6.1,31.2-17.6,41.4C93,113.6,78.62,118.8,63.22,118.8z" fill="url(#face_1_)"/><path d="M44,40.94L44,40.94c-4.19,0-8,3.54-8,9.42s3.81,9.41,8,9.41l0,0c4.2,0,8-3.54,8-9.41 S48.24,40.94,44,40.94z" fill="#422B0D"/><g id="peepers"><path d="M43.65,44.87L43.65,44.87c-1.42-0.68-3.13-0.08-3.82,1.34c-0.53,1.11-0.29,2.44,0.6,3.3l0,0 c1.42,0.68,3.13,0.08,3.82-1.34C44.78,47.06,44.54,45.73,43.65,44.87z" fill="#896024"/></g><path d="M82.4,40.94L82.4,40.94c-4.19,0-8,3.54-8,9.42s3.81,9.41,8,9.41l0,0c4.19,0,8-3.54,8-9.41 S86.59,40.94,82.4,40.94z" fill="#422B0D"/><g id="peepers-2"><path d="M82,44.87L82,44.87c-1.42-0.68-3.13-0.08-3.82,1.34c-0.53,1.11-0.29,2.44,0.6,3.3l0,0 c1.42,0.68,3.13,0.08,3.82-1.34C83.13,47.06,82.89,45.73,82,44.87z" fill="#896024"/></g><path d="M111.49,29.67c5.33,8.6,8.11,18.84,8.11,30.23c0,16.9-6.1,31.2-17.6,41.4 c-10.6,9.3-25,14.5-40.4,14.5c-18.06,0-37-7.35-48.18-22.94c10.76,17.66,31,25.94,50.18,25.94c15.4,0,29.8-5.2,40.4-14.5 c11.5-10.2,17.6-24.5,17.6-41.4C121.6,50.16,118.13,38.84,111.49,29.67z" fill="#EB8F00"/><path d="M63.43,100.73" fill="#422B0D"/><path d="M63.43,100.73" fill="#422B0D"/><path d="M63.43,101" fill="#422B0D"/><path d="M63.49,74.66" fill="#422B0D"/><path d="M63.49,74.66" fill="#422B0D"/><path d="M63.43,101" fill="#422B0D"/><path d="M102.07,71.62c-1.4-2.53-4.44-3.64-7.14-2.62c-10.26,2.99-20.9,4.48-31.59,4.43 C52.65,73.48,42.01,71.99,31.75,69c-2.69-1.02-5.73,0.08-7.13,2.6c-1.36,2.51-0.38,5.42,0.77,7.93 c6.42,14.1,20.57,22.54,37.87,22.59h0.16c17.3,0,31.45-8.49,37.88-22.59C102.44,77,103.43,74.13,102.07,71.62z" fill="#422B0D"/><path d="M63.42,100.89" fill="#422B0D"/><path d="M63.49,74.7" fill="#422B0D"/><path d="M63.49,74.7" fill="#422B0D"/><path d="M63.42,100.89" fill="#422B0D"/><path d="M79.35,98.14c-0.37-0.34-0.75-0.65-1.13-1c-4.08-3.59-9.36-5.52-14.8-5.41 C57.82,91.64,52.37,93.5,48,97c-0.38,0.31-0.78,0.61-1.15,1s-0.57,0.67-0.81,1c5.5,2.15,11.36,3.25,17.27,3.22h0.16 c5.66,0,11.27-1.01,16.57-3C79.84,98.84,79.61,98.48,79.35,98.14z" fill="#ED7770"/><path d="M94.93,69c-10.26,2.99-20.9,4.48-31.59,4.43C52.65,73.48,42.01,71.99,31.75,69 c-2.69-1.02-5.73,0.08-7.13,2.6c-0.2,0.38-0.36,0.78-0.46,1.19c0.33,0.17,0.71,0.34,1.16,0.52c12.04,6.03,25.35,9.09,38.81,8.93 c12.91,0.15,25.67-2.66,37.33-8.2c0.47-0.2,0.86-0.39,1.21-0.57c-0.08-0.65-0.29-1.29-0.6-1.87C100.67,69.08,97.63,67.97,94.93,69z " fill="#FFFFFF"/><path d="M102.11,71.63c-1.42-2.53-4.47-3.65-7.19-2.63c-10.26,2.99-20.9,4.48-31.58,4.43 C52.65,73.48,42.01,71.99,31.75,69c-2.69-1.02-5.73,0.08-7.13,2.6c-1.36,2.51-0.38,5.42,0.77,7.93c0.51,1.13,1.08,2.24,1.71,3.31 c0,0-2.1-7.78-0.28-10.04c0.62-0.96,1.66-1.56,2.8-1.62c0.47,0,0.93,0.08,1.38,0.22c10.44,3.07,21.27,4.62,32.16,4.6h0.35 c10.89,0.02,21.72-1.53,32.16-4.6c0.45-0.14,0.91-0.22,1.38-0.22c1.14,0.06,2.19,0.66,2.81,1.62c1.85,2.26-0.28,10.07-0.28,10.07 c0.62-1.07,1.24-2.17,1.76-3.31C102.48,77.05,103.47,74.15,102.11,71.63z" fill="#EB8F00"/></g></svg>]]>
    </svgDoc>
    <svgDoc endGlyphID="2" startGlyphID="2">
      <![CDATA[<svg xmlns="http://www.w3.org/2000/svg" id="glyph1713" viewBox="-4<PHONE_NUMBER>3333333<PHONE_NUMBER>6666667<PHONE_NUMBER>6666667"><g id="gold"><radialGradient id="face_1_" cx="63.6" cy="216.9" gradientTransform="matrix(1 0 0 1 0 -154)" gradientUnits="userSpaceOnUse" r="56.9597"><stop offset="0.5" stop-color="#FDE030"/><stop offset="0.92" stop-color="#F7C02B"/><stop offset="1" stop-color="#F4A223"/></radialGradient><path id="face" d="M63.6,118.8c-27.9,0-58-17.5-58-55.9S35.7,7,63.6,7c15.5,0,29.8,5.1,40.4,14.4 c11.5,10.2,17.6,24.6,17.6,41.5s-6.1,31.2-17.6,41.4C93.4,113.6,79,118.8,63.6,118.8z" fill="url(#face_1_)"/><path d="M111.49,29.67c5.33,8.6,8.11,18.84,8.11,30.23c0,16.9-6.1,31.2-17.6,41.4 c-10.6,9.3-25,14.5-40.4,14.5c-18.06,0-37-7.35-48.18-22.94c10.76,17.66,31,25.94,50.18,25.94c15.4,0,29.8-5.2,40.4-14.5 c11.5-10.2,17.6-24.5,17.6-41.4C121.6,50.16,118.13,38.84,111.49,29.67z" fill="#EB8F00"/></g><g id="facial_expressions"><path d="M101.7,72.21c-1.4-2.52-4.44-3.63-7.14-2.6c-9,2.8-20,3.83-31.08,3.84 C52.79,73.49,42.15,72,31.89,69c-2.7-1.03-5.74,0.08-7.14,2.6c-1.36,2.51-0.37,5.42,0.77,7.93C32,93.65,46.1,102.09,63.4,102.14 h0.16c17.3,0,30.94-7.9,37.37-22C102.07,77.63,103.06,74.72,101.7,72.21z" fill="#FFFFFF"/><g id="smiling-eyes-grinning-face"><g id="eyes"><path d="M49,56.89l-0.15-0.2l-0.43-0.55l-0.53-0.57c-0.22-0.25-0.48-0.49-0.73-0.75s-0.56-0.51-0.84-0.72 c-0.26-0.2-0.54-0.39-0.84-0.54c-0.2-0.11-0.42-0.2-0.65-0.25c-0.07-0.01-0.14-0.01-0.21,0c0,0-0.06,0-0.09,0h-0.08 c0.12,0-0.27,0,0.27,0h-0.55c-0.15,0-0.05,0,0,0h0.08c0.08,0,0,0,0,0h-0.11c-0.23,0.05-0.45,0.13-0.66,0.25 c-0.29,0.16-0.58,0.34-0.84,0.54c-0.29,0.22-0.57,0.46-0.83,0.72c-0.53,0.51-1,1-1.3,1.39l-0.52,0.6l-0.23,0.27 c-1.44,1.61-3.87,1.87-5.62,0.61c-1.12-0.78-1.69-2.13-1.47-3.48c0,0,0.07-0.4,0.26-1.11c0.3-1.01,0.72-1.99,1.25-2.91 c0.85-1.5,2-2.81,3.38-3.85c0.91-0.7,1.92-1.26,3-1.65c0.3-0.12,0.61-0.21,0.92-0.29c0.33-0.1,0.66-0.17,1-0.23l0.61-0.09 l0.51-0.06h0.55h0.79h0.51c0.34,0,0.67,0.09,1,0.14c0.64,0.11,1.28,0.28,1.89,0.51c1.08,0.39,2.09,0.95,3,1.65 c1.38,1.04,2.53,2.35,3.38,3.85c0.31,0.52,0.58,1.07,0.8,1.63c0.19,0.45,0.35,0.9,0.48,1.37c0.07,0.24,0.13,0.48,0.16,0.72v0.25 c0.3,2.04-1.12,3.94-3.16,4.24c-0.05,0.01-0.1,0.01-0.15,0.02C51.39,58.61,49.93,58.03,49,56.89z" fill="#422B0D"/><path d="M88.46,56.89l-0.16-0.2l-0.43-0.55l-0.53-0.57c-0.22-0.25-0.48-0.49-0.73-0.75 s-0.56-0.51-0.84-0.72c-0.26-0.2-0.54-0.39-0.84-0.54c-0.2-0.11-0.42-0.2-0.65-0.25c-0.07-0.01-0.14-0.01-0.21,0 c0,0-0.06,0-0.09,0H83.9c0.12,0-0.27,0,0.27,0h-0.55c-0.15,0-0.05,0,0,0h0.08c0.08,0,0,0,0,0h-0.11 c-0.23,0.05-0.45,0.13-0.66,0.25c-0.29,0.15-0.57,0.34-0.83,0.54c-0.3,0.22-0.58,0.46-0.84,0.72c-0.53,0.51-1,1-1.3,1.39 l-0.52,0.6l-0.22,0.27c-1.45,1.61-3.87,1.87-5.63,0.61c-1.12-0.78-1.69-2.13-1.47-3.48c0,0,0.07-0.4,0.27-1.11 c0.3-1.02,0.71-2,1.25-2.91c0.85-1.5,1.99-2.81,3.37-3.85c0.91-0.7,1.92-1.26,3-1.65c0.3-0.12,0.61-0.21,0.92-0.29 c0.33-0.1,0.66-0.17,1-0.23l0.62-0.09l0.5-0.06h0.55h0.79h0.51c0.34,0,0.67,0.09,1,0.14c0.65,0.11,1.28,0.28,1.89,0.51 c1.08,0.39,2.09,0.95,3,1.65c1.38,1.04,2.53,2.35,3.38,3.85c0.31,0.52,0.58,1.07,0.8,1.63c0.19,0.44,0.35,0.89,0.48,1.35 c0.07,0.24,0.13,0.48,0.16,0.72v0.25c0.32,2.04-1.08,3.95-3.12,4.27c-0.03,0-0.06,0.01-0.09,0.01 C90.91,58.65,89.4,58.07,88.46,56.89z" fill="#422B0D"/></g></g><path d="M62.84,74.7" fill="#422B0D"/><path d="M62.84,74.7" fill="#422B0D"/><path d="M63.42,100.89" fill="#422B0D"/><path d="M63.49,74.7" fill="#422B0D"/><path d="M63.49,74.7" fill="#422B0D"/><path d="M63.42,100.89" fill="#422B0D"/></g><path d="M100.89,75.83c-0.09,0.06-6.2,4.63-17.69,7.59v-11.3c-1.31,0.2-2.65,0.37-4,0.52v11.68 c-4.65,0.92-9.38,1.43-14.12,1.53V73.43H63.5c-0.81,0-1.61,0-2.42,0v12.42c0.43,0.01,0.43,0.02,0,0.02l-0.02-0.02 c-4.63-0.08-9.24-0.52-13.8-1.33V72.33c-1.36-0.18-2.69-0.39-4-0.62v11.97c-11.82-2.81-17.76-7.3-17.84-7.37 c-0.33-0.26-0.74-0.41-1.16-0.42c0.28,1.26,0.7,2.49,1.26,3.66c0.35,0.77,0.73,1.51,1.13,2.25c5.23,2.77,10.82,4.79,16.61,6v0.02 v9.84c1.3,0.63,2.64,1.2,4,1.69V88.6c4.56,0.76,9.18,1.18,13.8,1.25l0.02,0.02c-0.01,0-0.01,0-0.02,0v12.21 c0.77,0,1.55,0.08,2.34,0.08h0.16c0.51,0,1,0,1.5,0V89.85l-0.06,0l0.06,0c4.74-0.09,9.47-0.57,14.14-1.43v11.21 c1.36-0.46,2.7-1,4-1.61V87.57c6.1-1.4,11.97-3.69,17.41-6.79c0.1-0.22,0.22-0.42,0.32-0.64c0.73-1.48,1.21-3.07,1.4-4.71 C101.82,75.37,101.3,75.52,100.89,75.83z" fill="#B3B3B3"/><path d="M102.11,71.63c-1.42-2.53-4.47-3.65-7.19-2.63c-10.26,2.99-20.9,4.48-31.58,4.43 C52.65,73.48,42.01,71.99,31.75,69c-2.69-1.02-5.73,0.08-7.13,2.6c-1.36,2.51-0.38,5.42,0.77,7.93c0.51,1.13,1.08,2.24,1.71,3.31 c0,0-2.1-7.78-0.28-10.04c0.62-0.96,1.66-1.56,2.8-1.62c0.47,0,0.93,0.08,1.38,0.22c10.44,3.07,21.27,4.62,32.16,4.6h0.35 c10.89,0.02,21.72-1.53,32.16-4.6c0.45-0.14,0.91-0.22,1.38-0.22c1.14,0.06,2.19,0.66,2.81,1.62c1.85,2.26-0.28,10.07-0.28,10.07 c0.62-1.07,1.24-2.17,1.76-3.31C102.48,77.05,103.47,74.15,102.11,71.63z" fill="#EB8F00"/></svg>]]>
    </svgDoc>
    <svgDoc endGlyphID="3" startGlyphID="3">
      <![CDATA[<svg xmlns="http://www.w3.org/2000/svg" id="glyph1714" viewBox="-4<PHONE_NUMBER>3333333<PHONE_NUMBER>6666667<PHONE_NUMBER>6666667"><g id="facial_expressions"><radialGradient id="face_1_" cx="63.6" cy="216.9" gradientTransform="matrix(1 0 0 1 0 -154)" gradientUnits="userSpaceOnUse" r="56.9597"><stop offset="0.5" stop-color="#FDE030"/><stop offset="0.92" stop-color="#F7C02B"/><stop offset="1" stop-color="#F4A223"/></radialGradient><path id="face" d="M63.6,118.8c-27.9,0-58-17.5-58-55.9S35.7,7,63.6,7c15.5,0,29.8,5.1,40.4,14.4 c11.5,10.2,17.6,24.6,17.6,41.5s-6.1,31.2-17.6,41.4C93.4,113.6,79,118.8,63.6,118.8z" fill="url(#face_1_)"/><path d="M111.49,29.67c5.33,8.6,8.11,18.84,8.11,30.23c0,16.9-6.1,31.2-17.6,41.4 c-10.6,9.3-25,14.5-40.4,14.5c-18.06,0-37-7.35-48.18-22.94c10.76,17.66,31,25.94,50.18,25.94c15.4,0,29.8-5.2,40.4-14.5 c11.5-10.2,17.6-24.5,17.6-41.4C121.6,50.16,118.13,38.84,111.49,29.67z" fill="#EB8F00"/><path id="left-eyebrow" d="M39.44,31.21C39,30.15,37.8,29.61,36.72,30c-1.62,0.53-3.18,1.22-4.67,2.05 c-3.96,2.18-7.35,5.27-9.89,9c-0.7,0.95-0.52,2.28,0.41,3c0.49,0.41,1.13,0.61,1.77,0.53c0.48-0.07,0.92-0.3,1.26-0.65 c3.84-3.76,8.14-7.02,12.79-9.7l0.11-0.06C39.56,33.6,39.98,32.29,39.44,31.21z" fill="#422B0D"/><path id="left-eyebrow-2" d="M90.69,30.21c0.44-1.06,1.64-1.6,2.72-1.21c1.61,0.52,3.17,1.19,4.66,2 c3.96,2.18,7.35,5.26,9.9,9c0.69,0.95,0.51,2.27-0.41,3c-0.49,0.41-1.13,0.6-1.77,0.53c-0.48-0.07-0.92-0.3-1.26-0.65 c-3.84-3.76-8.14-7.02-12.79-9.7l-0.11-0.06C90.6,32.55,90.18,31.28,90.69,30.21z" fill="#422B0D"/><path d="M63.49,74.7" fill="#422B0D"/><path d="M63.49,74.7" fill="#422B0D"/><path d="M102.07,71.62c-1.4-2.53-4.44-3.64-7.14-2.62c-10.26,2.99-20.9,4.48-31.59,4.43 C52.65,73.48,42.01,71.99,31.75,69c-2.69-1.02-5.73,0.08-7.13,2.6c-1.36,2.51-0.38,5.42,0.77,7.93 c6.42,14.1,20.57,22.54,37.87,22.59h0.16c17.3,0,31.45-8.49,37.88-22.59C102.44,77,103.43,74.13,102.07,71.62z" fill="#422B0D"/><path d="M63.42,100.89" fill="#422B0D"/><path d="M63.49,74.7" fill="#422B0D"/><path d="M63.49,74.7" fill="#422B0D"/><path d="M63.42,100.89" fill="#422B0D"/><path d="M79.35,98.14c-0.37-0.34-0.75-0.65-1.13-1c-4.08-3.59-9.36-5.52-14.8-5.41 C57.82,91.64,52.37,93.5,48,97c-0.38,0.31-0.78,0.61-1.15,1s-0.57,0.67-0.81,1c5.5,2.15,11.36,3.25,17.27,3.22h0.16 c5.66,0,11.27-1.01,16.57-3C79.84,98.84,79.61,98.48,79.35,98.14z" fill="#ED7770"/><path d="M94.93,69c-10.26,2.99-20.9,4.48-31.59,4.43C52.65,73.48,42.01,71.99,31.75,69 c-2.69-1.02-5.73,0.08-7.13,2.6c-0.2,0.38-0.36,0.78-0.46,1.19c0.33,0.17,0.71,0.34,1.16,0.52c12.04,6.03,25.35,9.09,38.81,8.93 c12.91,0.15,25.67-2.66,37.33-8.2c0.47-0.2,0.86-0.39,1.21-0.57c-0.08-0.65-0.29-1.29-0.6-1.87C100.67,69.08,97.63,67.97,94.93,69z " fill="#FFFFFF"/><path d="M102.11,71.63c-1.42-2.53-4.47-3.65-7.19-2.63c-10.26,2.99-20.9,4.48-31.58,4.43 C52.65,73.48,42.01,71.99,31.75,69c-2.69-1.02-5.73,0.08-7.13,2.6c-1.36,2.51-0.38,5.42,0.77,7.93c0.51,1.13,1.08,2.24,1.71,3.31 c0,0-2.1-7.78-0.28-10.04c0.62-0.96,1.66-1.56,2.8-1.62c0.47,0,0.93,0.08,1.38,0.22c10.44,3.07,21.27,4.62,32.16,4.6h0.35 c10.89,0.02,21.72-1.53,32.16-4.6c0.45-0.14,0.91-0.22,1.38-0.22c1.14,0.06,2.19,0.66,2.81,1.62c1.85,2.26-0.28,10.07-0.28,10.07 c0.62-1.07,1.24-2.17,1.76-3.31C102.48,77.05,103.47,74.15,102.11,71.63z" fill="#EB8F00"/><g id="tears-of-joy"><g id="eyes"><path d="M100.69,57.09c0,0,17,0.47,23.79,13c2.84,5.26,3,14-2.88,17.19c-7.11,3.91-13.78-1.64-14.63-7.56 C104.68,63.66,100.69,57.09,100.69,57.09z" fill="#29B6F6"/><path d="M123.26,81.27c-0.67,1.22-2.14,1.75-3.43,1.24c-1.15-0.61-1.46-2.08-1.64-3.37l-0.55-4 c-0.23-1.59-1.85-6.74-0.15-7.58c1.35-0.66,3.94,1.16,4.7,2.21C123.86,72.15,124.65,78.93,123.26,81.27z" fill="#81D4FA"/><path d="M117.49,67.61c1.35-0.66,3.94,1.16,4.7,2.21c1.67,2.33,2.46,9.11,1.07,11.45 c-0.67,1.22-2.14,1.75-3.43,1.24c-1.15-0.61-1.46-2.08-1.64-3.37l-0.55-4" fill="#81D4FA"/><path d="M27.31,57.09c0,0-17,0.47-23.79,13C0.68,75.3,0.57,84,6.4,87.23c7.11,3.91,13.78-1.64,14.63-7.56 C23.32,63.66,27.31,57.09,27.31,57.09z" fill="#29B6F6"/><path d="M4.74,81.27c0.67,1.22,2.14,1.75,3.43,1.24c1.15-0.61,1.46-2.08,1.64-3.37l0.55-4 c0.23-1.59,1.85-6.74,0.15-7.58c-1.35-0.66-3.94,1.16-4.7,2.21C4.14,72.15,3.35,78.93,4.74,81.27z" fill="#81D4FA"/><path d="M48.15,55.87L48,55.65l-0.21-0.27c-0.08-0.11-0.16-0.2-0.26-0.29l-0.61-0.62 c-0.26-0.26-0.55-0.52-0.87-0.79c-0.66-0.57-1.4-1.03-2.2-1.39c-0.77-0.34-1.61-0.52-2.45-0.52c0.35,0,0.09,0,0.17,0H41 c-0.1-0.01-0.19-0.01-0.29,0c-0.18,0.02-0.36,0.05-0.54,0.09c-0.41,0.1-0.82,0.23-1.21,0.39c-0.8,0.35-1.54,0.82-2.2,1.39 c-0.54,0.45-1.05,0.94-1.52,1.47l-0.57,0.64l-0.3,0.34c-1.21,1.38-3.3,1.52-4.68,0.32c-1.03-0.9-1.4-2.35-0.94-3.64l0.11-0.32 c0.09-0.21,0.17-0.53,0.36-0.91c0.46-1.08,1.06-2.11,1.78-3.04c1.75-2.31,4.21-3.99,7-4.79c0.57-0.15,1.15-0.26,1.74-0.34 c0.3,0,0.74-0.09,0.87-0.09h0.76c1.13,0.02,2.26,0.18,3.36,0.46c1.05,0.29,2.05,0.71,3,1.25c1.55,0.91,2.91,2.11,4,3.54 c0.74,0.97,1.37,2.02,1.86,3.14c0.08,0.16,0.15,0.32,0.19,0.49c0.05,0.13,0.08,0.24,0.11,0.33l0.09,0.27 c0.57,1.77-0.4,3.67-2.17,4.24c-1.33,0.43-2.8-0.01-3.67-1.1L48.15,55.87z" fill="#422B0D"/><path d="M93.48,55.87l-0.18-0.22l-0.21-0.27c-0.08-0.11-0.16-0.2-0.26-0.29l-0.62-0.62 c-0.27-0.28-0.56-0.54-0.86-0.79c-0.66-0.57-1.4-1.03-2.2-1.39c-0.77-0.34-1.61-0.52-2.45-0.52c0.35,0,0.09,0,0.17,0h-0.58 c-0.1-0.01-0.19-0.01-0.29,0c-0.18,0.02-0.36,0.05-0.54,0.09c-0.41,0.1-0.82,0.23-1.21,0.39c-0.81,0.37-1.57,0.85-2.25,1.43 c-0.54,0.46-1.04,0.95-1.51,1.47l-0.57,0.64l-0.3,0.34c-1.21,1.38-3.3,1.52-4.68,0.32c-1.03-0.9-1.4-2.35-0.94-3.64l0.11-0.32 c0.09-0.21,0.17-0.53,0.35-0.91c0.48-1.1,1.09-2.13,1.83-3.08c1.75-2.31,4.21-3.99,7-4.79c0.57-0.15,1.15-0.26,1.74-0.34 c0.3,0,0.74-0.09,0.87-0.09h0.76c1.13,0.02,2.26,0.18,3.36,0.46c1.04,0.3,2.04,0.72,2.98,1.26c1.55,0.9,2.91,2.11,4,3.54 c0.42,0.54,0.79,1.11,1.13,1.7c0.27,0.47,0.51,0.95,0.73,1.44c0.08,0.16,0.14,0.32,0.19,0.49c0,0.13,0.08,0.24,0.11,0.33 l0.09,0.27c0.57,1.77-0.4,3.67-2.17,4.24c-1.33,0.43-2.8-0.01-3.67-1.1L93.48,55.87z" fill="#422B0D"/></g></g></g></svg>]]>
    </svgDoc>

The issue is that the  id="glyph1713" string in the SVG header is not updated to reflect the new glyph ID in font context. This means that the SVG table is not properly formed, and I b/w glyphs will be shown (macOS 12.1, Safari 15.2, Chrome  99.0).
Manually updating the SVG table will produce the desired (colored) glyphs:
  <SVG>
    <svgDoc endGlyphID="1" startGlyphID="1">
      <![CDATA[<svg xmlns="http://www.w3.org/2000/svg" id="glyph1" viewBox="-4<PHONE_NUMBER>3333333<PHONE_NUMBER>6666667<PHONE_NUMBER>6666667"><g id="facial_expressions"><radialGradient id="face_1_" cx="63.22" cy="216.9" gradientTransform="matrix(1 0 0 1 0 -154)" gradientUnits="userSpaceOnUse" r="56.9597"><stop offset="0.5" stop-color="#FDE030"/><stop offset="0.92" stop-color="#F7C02B"/><stop offset="1" stop-color="#F4A223"/></radialGradient><path id="face" d="M63.22,118.8c-27.9,0-58-17.5-58-55.9S35.32,7,63.22,7c15.5,0,29.8,5.1,40.4,14.4 c11.5,10.2,17.6,24.6,17.6,41.5s-6.1,31.2-17.6,41.4C93,113.6,78.62,118.8,63.22,118.8z" fill="url(#face_1_)"/><path d="M44,40.94L44,40.94c-4.19,0-8,3.54-8,9.42s3.81,9.41,8,9.41l0,0c4.2,0,8-3.54,8-9.41 S48.24,40.94,44,40.94z" fill="#422B0D"/><g id="peepers"><path d="M43.65,44.87L43.65,44.87c-1.42-0.68-3.13-0.08-3.82,1.34c-0.53,1.11-0.29,2.44,0.6,3.3l0,0 c1.42,0.68,3.13,0.08,3.82-1.34C44.78,47.06,44.54,45.73,43.65,44.87z" fill="#896024"/></g><path d="M82.4,40.94L82.4,40.94c-4.19,0-8,3.54-8,9.42s3.81,9.41,8,9.41l0,0c4.19,0,8-3.54,8-9.41 S86.59,40.94,82.4,40.94z" fill="#422B0D"/><g id="peepers-2"><path d="M82,44.87L82,44.87c-1.42-0.68-3.13-0.08-3.82,1.34c-0.53,1.11-0.29,2.44,0.6,3.3l0,0 c1.42,0.68,3.13,0.08,3.82-1.34C83.13,47.06,82.89,45.73,82,44.87z" fill="#896024"/></g><path d="M111.49,29.67c5.33,8.6,8.11,18.84,8.11,30.23c0,16.9-6.1,31.2-17.6,41.4 c-10.6,9.3-25,14.5-40.4,14.5c-18.06,0-37-7.35-48.18-22.94c10.76,17.66,31,25.94,50.18,25.94c15.4,0,29.8-5.2,40.4-14.5 c11.5-10.2,17.6-24.5,17.6-41.4C121.6,50.16,118.13,38.84,111.49,29.67z" fill="#EB8F00"/><path d="M63.43,100.73" fill="#422B0D"/><path d="M63.43,100.73" fill="#422B0D"/><path d="M63.43,101" fill="#422B0D"/><path d="M63.49,74.66" fill="#422B0D"/><path d="M63.49,74.66" fill="#422B0D"/><path d="M63.43,101" fill="#422B0D"/><path d="M102.07,71.62c-1.4-2.53-4.44-3.64-7.14-2.62c-10.26,2.99-20.9,4.48-31.59,4.43 C52.65,73.48,42.01,71.99,31.75,69c-2.69-1.02-5.73,0.08-7.13,2.6c-1.36,2.51-0.38,5.42,0.77,7.93 c6.42,14.1,20.57,22.54,37.87,22.59h0.16c17.3,0,31.45-8.49,37.88-22.59C102.44,77,103.43,74.13,102.07,71.62z" fill="#422B0D"/><path d="M63.42,100.89" fill="#422B0D"/><path d="M63.49,74.7" fill="#422B0D"/><path d="M63.49,74.7" fill="#422B0D"/><path d="M63.42,100.89" fill="#422B0D"/><path d="M79.35,98.14c-0.37-0.34-0.75-0.65-1.13-1c-4.08-3.59-9.36-5.52-14.8-5.41 C57.82,91.64,52.37,93.5,48,97c-0.38,0.31-0.78,0.61-1.15,1s-0.57,0.67-0.81,1c5.5,2.15,11.36,3.25,17.27,3.22h0.16 c5.66,0,11.27-1.01,16.57-3C79.84,98.84,79.61,98.48,79.35,98.14z" fill="#ED7770"/><path d="M94.93,69c-10.26,2.99-20.9,4.48-31.59,4.43C52.65,73.48,42.01,71.99,31.75,69 c-2.69-1.02-5.73,0.08-7.13,2.6c-0.2,0.38-0.36,0.78-0.46,1.19c0.33,0.17,0.71,0.34,1.16,0.52c12.04,6.03,25.35,9.09,38.81,8.93 c12.91,0.15,25.67-2.66,37.33-8.2c0.47-0.2,0.86-0.39,1.21-0.57c-0.08-0.65-0.29-1.29-0.6-1.87C100.67,69.08,97.63,67.97,94.93,69z " fill="#FFFFFF"/><path d="M102.11,71.63c-1.42-2.53-4.47-3.65-7.19-2.63c-10.26,2.99-20.9,4.48-31.58,4.43 C52.65,73.48,42.01,71.99,31.75,69c-2.69-1.02-5.73,0.08-7.13,2.6c-1.36,2.51-0.38,5.42,0.77,7.93c0.51,1.13,1.08,2.24,1.71,3.31 c0,0-2.1-7.78-0.28-10.04c0.62-0.96,1.66-1.56,2.8-1.62c0.47,0,0.93,0.08,1.38,0.22c10.44,3.07,21.27,4.62,32.16,4.6h0.35 c10.89,0.02,21.72-1.53,32.16-4.6c0.45-0.14,0.91-0.22,1.38-0.22c1.14,0.06,2.19,0.66,2.81,1.62c1.85,2.26-0.28,10.07-0.28,10.07 c0.62-1.07,1.24-2.17,1.76-3.31C102.48,77.05,103.47,74.15,102.11,71.63z" fill="#EB8F00"/></g></svg>]]>
    </svgDoc>
    <svgDoc endGlyphID="2" startGlyphID="2">
      <![CDATA[<svg xmlns="http://www.w3.org/2000/svg" id="glyph2" viewBox="-4<PHONE_NUMBER>3333333<PHONE_NUMBER>6666667<PHONE_NUMBER>6666667"><g id="gold"><radialGradient id="face_1_" cx="63.6" cy="216.9" gradientTransform="matrix(1 0 0 1 0 -154)" gradientUnits="userSpaceOnUse" r="56.9597"><stop offset="0.5" stop-color="#FDE030"/><stop offset="0.92" stop-color="#F7C02B"/><stop offset="1" stop-color="#F4A223"/></radialGradient><path id="face" d="M63.6,118.8c-27.9,0-58-17.5-58-55.9S35.7,7,63.6,7c15.5,0,29.8,5.1,40.4,14.4 c11.5,10.2,17.6,24.6,17.6,41.5s-6.1,31.2-17.6,41.4C93.4,113.6,79,118.8,63.6,118.8z" fill="url(#face_1_)"/><path d="M111.49,29.67c5.33,8.6,8.11,18.84,8.11,30.23c0,16.9-6.1,31.2-17.6,41.4 c-10.6,9.3-25,14.5-40.4,14.5c-18.06,0-37-7.35-48.18-22.94c10.76,17.66,31,25.94,50.18,25.94c15.4,0,29.8-5.2,40.4-14.5 c11.5-10.2,17.6-24.5,17.6-41.4C121.6,50.16,118.13,38.84,111.49,29.67z" fill="#EB8F00"/></g><g id="facial_expressions"><path d="M101.7,72.21c-1.4-2.52-4.44-3.63-7.14-2.6c-9,2.8-20,3.83-31.08,3.84 C52.79,73.49,42.15,72,31.89,69c-2.7-1.03-5.74,0.08-7.14,2.6c-1.36,2.51-0.37,5.42,0.77,7.93C32,93.65,46.1,102.09,63.4,102.14 h0.16c17.3,0,30.94-7.9,37.37-22C102.07,77.63,103.06,74.72,101.7,72.21z" fill="#FFFFFF"/><g id="smiling-eyes-grinning-face"><g id="eyes"><path d="M49,56.89l-0.15-0.2l-0.43-0.55l-0.53-0.57c-0.22-0.25-0.48-0.49-0.73-0.75s-0.56-0.51-0.84-0.72 c-0.26-0.2-0.54-0.39-0.84-0.54c-0.2-0.11-0.42-0.2-0.65-0.25c-0.07-0.01-0.14-0.01-0.21,0c0,0-0.06,0-0.09,0h-0.08 c0.12,0-0.27,0,0.27,0h-0.55c-0.15,0-0.05,0,0,0h0.08c0.08,0,0,0,0,0h-0.11c-0.23,0.05-0.45,0.13-0.66,0.25 c-0.29,0.16-0.58,0.34-0.84,0.54c-0.29,0.22-0.57,0.46-0.83,0.72c-0.53,0.51-1,1-1.3,1.39l-0.52,0.6l-0.23,0.27 c-1.44,1.61-3.87,1.87-5.62,0.61c-1.12-0.78-1.69-2.13-1.47-3.48c0,0,0.07-0.4,0.26-1.11c0.3-1.01,0.72-1.99,1.25-2.91 c0.85-1.5,2-2.81,3.38-3.85c0.91-0.7,1.92-1.26,3-1.65c0.3-0.12,0.61-0.21,0.92-0.29c0.33-0.1,0.66-0.17,1-0.23l0.61-0.09 l0.51-0.06h0.55h0.79h0.51c0.34,0,0.67,0.09,1,0.14c0.64,0.11,1.28,0.28,1.89,0.51c1.08,0.39,2.09,0.95,3,1.65 c1.38,1.04,2.53,2.35,3.38,3.85c0.31,0.52,0.58,1.07,0.8,1.63c0.19,0.45,0.35,0.9,0.48,1.37c0.07,0.24,0.13,0.48,0.16,0.72v0.25 c0.3,2.04-1.12,3.94-3.16,4.24c-0.05,0.01-0.1,0.01-0.15,0.02C51.39,58.61,49.93,58.03,49,56.89z" fill="#422B0D"/><path d="M88.46,56.89l-0.16-0.2l-0.43-0.55l-0.53-0.57c-0.22-0.25-0.48-0.49-0.73-0.75 s-0.56-0.51-0.84-0.72c-0.26-0.2-0.54-0.39-0.84-0.54c-0.2-0.11-0.42-0.2-0.65-0.25c-0.07-0.01-0.14-0.01-0.21,0 c0,0-0.06,0-0.09,0H83.9c0.12,0-0.27,0,0.27,0h-0.55c-0.15,0-0.05,0,0,0h0.08c0.08,0,0,0,0,0h-0.11 c-0.23,0.05-0.45,0.13-0.66,0.25c-0.29,0.15-0.57,0.34-0.83,0.54c-0.3,0.22-0.58,0.46-0.84,0.72c-0.53,0.51-1,1-1.3,1.39 l-0.52,0.6l-0.22,0.27c-1.45,1.61-3.87,1.87-5.63,0.61c-1.12-0.78-1.69-2.13-1.47-3.48c0,0,0.07-0.4,0.27-1.11 c0.3-1.02,0.71-2,1.25-2.91c0.85-1.5,1.99-2.81,3.37-3.85c0.91-0.7,1.92-1.26,3-1.65c0.3-0.12,0.61-0.21,0.92-0.29 c0.33-0.1,0.66-0.17,1-0.23l0.62-0.09l0.5-0.06h0.55h0.79h0.51c0.34,0,0.67,0.09,1,0.14c0.65,0.11,1.28,0.28,1.89,0.51 c1.08,0.39,2.09,0.95,3,1.65c1.38,1.04,2.53,2.35,3.38,3.85c0.31,0.52,0.58,1.07,0.8,1.63c0.19,0.44,0.35,0.89,0.48,1.35 c0.07,0.24,0.13,0.48,0.16,0.72v0.25c0.32,2.04-1.08,3.95-3.12,4.27c-0.03,0-0.06,0.01-0.09,0.01 C90.91,58.65,89.4,58.07,88.46,56.89z" fill="#422B0D"/></g></g><path d="M62.84,74.7" fill="#422B0D"/><path d="M62.84,74.7" fill="#422B0D"/><path d="M63.42,100.89" fill="#422B0D"/><path d="M63.49,74.7" fill="#422B0D"/><path d="M63.49,74.7" fill="#422B0D"/><path d="M63.42,100.89" fill="#422B0D"/></g><path d="M100.89,75.83c-0.09,0.06-6.2,4.63-17.69,7.59v-11.3c-1.31,0.2-2.65,0.37-4,0.52v11.68 c-4.65,0.92-9.38,1.43-14.12,1.53V73.43H63.5c-0.81,0-1.61,0-2.42,0v12.42c0.43,0.01,0.43,0.02,0,0.02l-0.02-0.02 c-4.63-0.08-9.24-0.52-13.8-1.33V72.33c-1.36-0.18-2.69-0.39-4-0.62v11.97c-11.82-2.81-17.76-7.3-17.84-7.37 c-0.33-0.26-0.74-0.41-1.16-0.42c0.28,1.26,0.7,2.49,1.26,3.66c0.35,0.77,0.73,1.51,1.13,2.25c5.23,2.77,10.82,4.79,16.61,6v0.02 v9.84c1.3,0.63,2.64,1.2,4,1.69V88.6c4.56,0.76,9.18,1.18,13.8,1.25l0.02,0.02c-0.01,0-0.01,0-0.02,0v12.21 c0.77,0,1.55,0.08,2.34,0.08h0.16c0.51,0,1,0,1.5,0V89.85l-0.06,0l0.06,0c4.74-0.09,9.47-0.57,14.14-1.43v11.21 c1.36-0.46,2.7-1,4-1.61V87.57c6.1-1.4,11.97-3.69,17.41-6.79c0.1-0.22,0.22-0.42,0.32-0.64c0.73-1.48,1.21-3.07,1.4-4.71 C101.82,75.37,101.3,75.52,100.89,75.83z" fill="#B3B3B3"/><path d="M102.11,71.63c-1.42-2.53-4.47-3.65-7.19-2.63c-10.26,2.99-20.9,4.48-31.58,4.43 C52.65,73.48,42.01,71.99,31.75,69c-2.69-1.02-5.73,0.08-7.13,2.6c-1.36,2.51-0.38,5.42,0.77,7.93c0.51,1.13,1.08,2.24,1.71,3.31 c0,0-2.1-7.78-0.28-10.04c0.62-0.96,1.66-1.56,2.8-1.62c0.47,0,0.93,0.08,1.38,0.22c10.44,3.07,21.27,4.62,32.16,4.6h0.35 c10.89,0.02,21.72-1.53,32.16-4.6c0.45-0.14,0.91-0.22,1.38-0.22c1.14,0.06,2.19,0.66,2.81,1.62c1.85,2.26-0.28,10.07-0.28,10.07 c0.62-1.07,1.24-2.17,1.76-3.31C102.48,77.05,103.47,74.15,102.11,71.63z" fill="#EB8F00"/></svg>]]>
    </svgDoc>
    <svgDoc endGlyphID="3" startGlyphID="3">
      <![CDATA[<svg xmlns="http://www.w3.org/2000/svg" id="glyph3" viewBox="-4<PHONE_NUMBER>3333333<PHONE_NUMBER>6666667<PHONE_NUMBER>6666667"><g id="facial_expressions"><radialGradient id="face_1_" cx="63.6" cy="216.9" gradientTransform="matrix(1 0 0 1 0 -154)" gradientUnits="userSpaceOnUse" r="56.9597"><stop offset="0.5" stop-color="#FDE030"/><stop offset="0.92" stop-color="#F7C02B"/><stop offset="1" stop-color="#F4A223"/></radialGradient><path id="face" d="M63.6,118.8c-27.9,0-58-17.5-58-55.9S35.7,7,63.6,7c15.5,0,29.8,5.1,40.4,14.4 c11.5,10.2,17.6,24.6,17.6,41.5s-6.1,31.2-17.6,41.4C93.4,113.6,79,118.8,63.6,118.8z" fill="url(#face_1_)"/><path d="M111.49,29.67c5.33,8.6,8.11,18.84,8.11,30.23c0,16.9-6.1,31.2-17.6,41.4 c-10.6,9.3-25,14.5-40.4,14.5c-18.06,0-37-7.35-48.18-22.94c10.76,17.66,31,25.94,50.18,25.94c15.4,0,29.8-5.2,40.4-14.5 c11.5-10.2,17.6-24.5,17.6-41.4C121.6,50.16,118.13,38.84,111.49,29.67z" fill="#EB8F00"/><path id="left-eyebrow" d="M39.44,31.21C39,30.15,37.8,29.61,36.72,30c-1.62,0.53-3.18,1.22-4.67,2.05 c-3.96,2.18-7.35,5.27-9.89,9c-0.7,0.95-0.52,2.28,0.41,3c0.49,0.41,1.13,0.61,1.77,0.53c0.48-0.07,0.92-0.3,1.26-0.65 c3.84-3.76,8.14-7.02,12.79-9.7l0.11-0.06C39.56,33.6,39.98,32.29,39.44,31.21z" fill="#422B0D"/><path id="left-eyebrow-2" d="M90.69,30.21c0.44-1.06,1.64-1.6,2.72-1.21c1.61,0.52,3.17,1.19,4.66,2 c3.96,2.18,7.35,5.26,9.9,9c0.69,0.95,0.51,2.27-0.41,3c-0.49,0.41-1.13,0.6-1.77,0.53c-0.48-0.07-0.92-0.3-1.26-0.65 c-3.84-3.76-8.14-7.02-12.79-9.7l-0.11-0.06C90.6,32.55,90.18,31.28,90.69,30.21z" fill="#422B0D"/><path d="M63.49,74.7" fill="#422B0D"/><path d="M63.49,74.7" fill="#422B0D"/><path d="M102.07,71.62c-1.4-2.53-4.44-3.64-7.14-2.62c-10.26,2.99-20.9,4.48-31.59,4.43 C52.65,73.48,42.01,71.99,31.75,69c-2.69-1.02-5.73,0.08-7.13,2.6c-1.36,2.51-0.38,5.42,0.77,7.93 c6.42,14.1,20.57,22.54,37.87,22.59h0.16c17.3,0,31.45-8.49,37.88-22.59C102.44,77,103.43,74.13,102.07,71.62z" fill="#422B0D"/><path d="M63.42,100.89" fill="#422B0D"/><path d="M63.49,74.7" fill="#422B0D"/><path d="M63.49,74.7" fill="#422B0D"/><path d="M63.42,100.89" fill="#422B0D"/><path d="M79.35,98.14c-0.37-0.34-0.75-0.65-1.13-1c-4.08-3.59-9.36-5.52-14.8-5.41 C57.82,91.64,52.37,93.5,48,97c-0.38,0.31-0.78,0.61-1.15,1s-0.57,0.67-0.81,1c5.5,2.15,11.36,3.25,17.27,3.22h0.16 c5.66,0,11.27-1.01,16.57-3C79.84,98.84,79.61,98.48,79.35,98.14z" fill="#ED7770"/><path d="M94.93,69c-10.26,2.99-20.9,4.48-31.59,4.43C52.65,73.48,42.01,71.99,31.75,69 c-2.69-1.02-5.73,0.08-7.13,2.6c-0.2,0.38-0.36,0.78-0.46,1.19c0.33,0.17,0.71,0.34,1.16,0.52c12.04,6.03,25.35,9.09,38.81,8.93 c12.91,0.15,25.67-2.66,37.33-8.2c0.47-0.2,0.86-0.39,1.21-0.57c-0.08-0.65-0.29-1.29-0.6-1.87C100.67,69.08,97.63,67.97,94.93,69z " fill="#FFFFFF"/><path d="M102.11,71.63c-1.42-2.53-4.47-3.65-7.19-2.63c-10.26,2.99-20.9,4.48-31.58,4.43 C52.65,73.48,42.01,71.99,31.75,69c-2.69-1.02-5.73,0.08-7.13,2.6c-1.36,2.51-0.38,5.42,0.77,7.93c0.51,1.13,1.08,2.24,1.71,3.31 c0,0-2.1-7.78-0.28-10.04c0.62-0.96,1.66-1.56,2.8-1.62c0.47,0,0.93,0.08,1.38,0.22c10.44,3.07,21.27,4.62,32.16,4.6h0.35 c10.89,0.02,21.72-1.53,32.16-4.6c0.45-0.14,0.91-0.22,1.38-0.22c1.14,0.06,2.19,0.66,2.81,1.62c1.85,2.26-0.28,10.07-0.28,10.07 c0.62-1.07,1.24-2.17,1.76-3.31C102.48,77.05,103.47,74.15,102.11,71.63z" fill="#EB8F00"/><g id="tears-of-joy"><g id="eyes"><path d="M100.69,57.09c0,0,17,0.47,23.79,13c2.84,5.26,3,14-2.88,17.19c-7.11,3.91-13.78-1.64-14.63-7.56 C104.68,63.66,100.69,57.09,100.69,57.09z" fill="#29B6F6"/><path d="M123.26,81.27c-0.67,1.22-2.14,1.75-3.43,1.24c-1.15-0.61-1.46-2.08-1.64-3.37l-0.55-4 c-0.23-1.59-1.85-6.74-0.15-7.58c1.35-0.66,3.94,1.16,4.7,2.21C123.86,72.15,124.65,78.93,123.26,81.27z" fill="#81D4FA"/><path d="M117.49,67.61c1.35-0.66,3.94,1.16,4.7,2.21c1.67,2.33,2.46,9.11,1.07,11.45 c-0.67,1.22-2.14,1.75-3.43,1.24c-1.15-0.61-1.46-2.08-1.64-3.37l-0.55-4" fill="#81D4FA"/><path d="M27.31,57.09c0,0-17,0.47-23.79,13C0.68,75.3,0.57,84,6.4,87.23c7.11,3.91,13.78-1.64,14.63-7.56 C23.32,63.66,27.31,57.09,27.31,57.09z" fill="#29B6F6"/><path d="M4.74,81.27c0.67,1.22,2.14,1.75,3.43,1.24c1.15-0.61,1.46-2.08,1.64-3.37l0.55-4 c0.23-1.59,1.85-6.74,0.15-7.58c-1.35-0.66-3.94,1.16-4.7,2.21C4.14,72.15,3.35,78.93,4.74,81.27z" fill="#81D4FA"/><path d="M48.15,55.87L48,55.65l-0.21-0.27c-0.08-0.11-0.16-0.2-0.26-0.29l-0.61-0.62 c-0.26-0.26-0.55-0.52-0.87-0.79c-0.66-0.57-1.4-1.03-2.2-1.39c-0.77-0.34-1.61-0.52-2.45-0.52c0.35,0,0.09,0,0.17,0H41 c-0.1-0.01-0.19-0.01-0.29,0c-0.18,0.02-0.36,0.05-0.54,0.09c-0.41,0.1-0.82,0.23-1.21,0.39c-0.8,0.35-1.54,0.82-2.2,1.39 c-0.54,0.45-1.05,0.94-1.52,1.47l-0.57,0.64l-0.3,0.34c-1.21,1.38-3.3,1.52-4.68,0.32c-1.03-0.9-1.4-2.35-0.94-3.64l0.11-0.32 c0.09-0.21,0.17-0.53,0.36-0.91c0.46-1.08,1.06-2.11,1.78-3.04c1.75-2.31,4.21-3.99,7-4.79c0.57-0.15,1.15-0.26,1.74-0.34 c0.3,0,0.74-0.09,0.87-0.09h0.76c1.13,0.02,2.26,0.18,3.36,0.46c1.05,0.29,2.05,0.71,3,1.25c1.55,0.91,2.91,2.11,4,3.54 c0.74,0.97,1.37,2.02,1.86,3.14c0.08,0.16,0.15,0.32,0.19,0.49c0.05,0.13,0.08,0.24,0.11,0.33l0.09,0.27 c0.57,1.77-0.4,3.67-2.17,4.24c-1.33,0.43-2.8-0.01-3.67-1.1L48.15,55.87z" fill="#422B0D"/><path d="M93.48,55.87l-0.18-0.22l-0.21-0.27c-0.08-0.11-0.16-0.2-0.26-0.29l-0.62-0.62 c-0.27-0.28-0.56-0.54-0.86-0.79c-0.66-0.57-1.4-1.03-2.2-1.39c-0.77-0.34-1.61-0.52-2.45-0.52c0.35,0,0.09,0,0.17,0h-0.58 c-0.1-0.01-0.19-0.01-0.29,0c-0.18,0.02-0.36,0.05-0.54,0.09c-0.41,0.1-0.82,0.23-1.21,0.39c-0.81,0.37-1.57,0.85-2.25,1.43 c-0.54,0.46-1.04,0.95-1.51,1.47l-0.57,0.64l-0.3,0.34c-1.21,1.38-3.3,1.52-4.68,0.32c-1.03-0.9-1.4-2.35-0.94-3.64l0.11-0.32 c0.09-0.21,0.17-0.53,0.35-0.91c0.48-1.1,1.09-2.13,1.83-3.08c1.75-2.31,4.21-3.99,7-4.79c0.57-0.15,1.15-0.26,1.74-0.34 c0.3,0,0.74-0.09,0.87-0.09h0.76c1.13,0.02,2.26,0.18,3.36,0.46c1.04,0.3,2.04,0.72,2.98,1.26c1.55,0.9,2.91,2.11,4,3.54 c0.42,0.54,0.79,1.11,1.13,1.7c0.27,0.47,0.51,0.95,0.73,1.44c0.08,0.16,0.14,0.32,0.19,0.49c0,0.13,0.08,0.24,0.11,0.33 l0.09,0.27c0.57,1.77-0.4,3.67-2.17,4.24c-1.33,0.43-2.8-0.01-3.67-1.1L93.48,55.87z" fill="#422B0D"/></g></g></g></svg>]]>
    </svgDoc>

This is very strange, we do have code to remap the glyph ids, there's also a test that checks that in Tests/subset/svg_test.py
Thanks for the report, I'll take a look tomorrow

I wonder maybe it could be because the id attribute is on the root <svg> element itself whereas the code may assume it can only be on a child element e.g. a <g> contained therein.
https://docs.microsoft.com/en-us/typography/opentype/spec/svg#glyph-identifiers
The spec says the doc must contain elements with glyph ids, not that itself has the id attribute.
But I guess if that is supposed to work, we should support that too. If that is it, it should be an easy fix. I'll confirm tomorrow

I checked again, the spec does have a few examples at the bottom where the glyph id attribute is on the root svg element so it's definitely valid.


[BUG][EKS][2.6/2.7] Unable to view YAML for downstream EKS clusters

Rancher Server Setup

Rancher version: 2.6.10 / 2.7.1
Installation option: Docker
Proxy/Cert Details: N/A

User Information

What is the role of the user logged in: admin

Describe the bug

Can not view the cluster information page after importing EKS cluster into Rancher (k8s version: 1.23, 1.24, etc),
the page shows "Loading..." and the console log shows the error of the eksNodeGroups is null.
To Reproduce

Create an EKS cluster in the AWS console, kube version 1.23/1.24.
Import this cluster into Rancher.
Go to the cluster information page.

Result
The page shows "Loading..." and the console log shows the error of the eksNodeGroups is null.

Follow-up context:

issue NOT seen in 2.6.9
issue seen in 2.6.10 + 2.6-head

As Nancy highlights, this is only affecting standard users.

I am looking into this from an eks-operator point-of-view.

@Josh-Diamond can you split out the RBAC part of this issue from Nancy's comment, team-1 can handle from there: https://github.com/rancher/rancher/issues/40667#issuecomment-1442149800
Both of these issues should be prioritized separately. This EKS part of this problem feels like a bug, not a blocker.

Quick question @Josh-Diamond
The original issue notes 2.6.10 as the version, but the repro steps reference 2.6-head as the version used.
We have a theory on the fix here, but it turns out that the specific version is important here since 2.6.10 references a version of steve that has the fix for the links, but 2.6-head does not yet reference that fixed steve.  We think that we just need to update 2.6-head, but if this problem is in 2.6.10, we may have another problem.

@crobby looking into this now and testing on 2.6.10.. thinking about this more, its possible I commented that this issue was seen on 2.6.10 because the original issue was Cluster Details page not loading, which has since been fixed.
So this EKS View YAML issue (which has since been determined as a separate bug) may very well not be seen on 2.6.10
Will post results and confirm soon 👍

@crobby okay, I can confirm the EKS View YAML issue is NOT seen on 2.6.10 after all.
I believe what happened, is before this issue title changed and was transferred, that comment confirming this was seen on  2.6.10 was in reference to  Cluster Details page won't load for imported EKS.
Updating that comment

With https://github.com/rancher/rancher/pull/40680 merged, I believe this is now ready to test.

Ticket #40667 - Test Results - Pending
With Docker on a single-node instance:
Verified on rancher v2.6-f76a1c515cd12d0bc01e69e747d0734ae18df793-head:

Scenario
Test Case
Result

1.
Rancher provisioned downstream EKS cluster w/ admin + standard user as cluster-owners
✅

2.
Import EKS cluster from EKS Console into rancher server w/ admin + standard user as cluster-owners
✅

Scenario 1:

Fresh install of rancher v2.6-head
As admin, create a standard user
As admin, provision a downstream EKS cluster w/ k8s 1.23
Once active, add standard user as member of cluster as cluster-owner
As admin, navigate to Cluster Management > View YAML
Verified - View YAML successfully loads YAML page w/ clean console logs
Logout admin, login standard user
As standard user, navigate to Cluster Management > View YAML
Verified - View YAML successfully loads YAML page w/ clean console logs

Scenario 2:

Create an EKS cluster w/ k8s 1.24 from EKS Console
Fresh install of rancher v2.6-head
As admin, create a standard user
As admin, import EKS cluster (created in step 1) into rancher
Once imported cluster is active, add standard user as a cluster-owner member to the cluster
As admin, navigate to Cluster Management > View YAML
Verified - View YAML successfully loads YAML page w/ clean console logs
Logout admin, login standard user
As standard user, navigate to Cluster Management > View YAML

Verified - View YAML successfully loads YAML page w/ clean console logs

I wouldn't expect much of a chance for additional regressions around this.
The actual fix was in Steve https://github.com/rancher/steve/commit/48cf877a80b3a5a5b4aca2759181ee0b9036ae9e
The fix only changes the content of the view/selfLink for this particular resource.
That fix was actually already part of 2.6.10, but the problem was that it never got put back on the 2.6 branch, so it wasn't picked-up by 2.6-head builds.


Renaming split-names to split-names-from-streaming

Part of code for https://github.com/huggingface/datasets-server/issues/755
Since we are going to handle two different sources for split-names, the previous worker/processing step/cache-kind have to be changed to /split-names-from-streaming (There already exist /split-names-from-dataset-info)
TODO: Once this PR is merged, a new PR with changes on docker image/chart should be sent in order to change the WORKER_ONLY_JOB_TYPES param as well

The docs for this PR live here. All of your documentation changes will be reflected on that endpoint.

Codecov Report
Base: 90.34% // Head: 90.05% // Decreases project coverage by -0.30% :warning:

Coverage data is based on head (cad57b5) compared to base (3a27146).
Patch coverage: 65.75% of modified lines in pull request are covered.

Additional details and impacted files
@@            Coverage Diff             @@
##             main     #825      +/-   ##
==========================================
- Coverage   90.34%   90.05%   -0.30%
==========================================
  Files         111      113       +2
  Lines        5894     5940      +46
==========================================
+ Hits         5325     5349      +24
- Misses        569      591      +22

Flag
Coverage Δ

jobs_mongodb_migration
77.29% <50.00%> (-2.81%)
:arrow_down:

libs_libcommon
92.94% <100.00%> (ø)

services_admin
87.32% <ø> (ø)

services_api
89.34% <ø> (ø)

services_worker
91.65% <94.11%> (ø)

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

Impacted Files
Coverage Δ

...s/mongodb_migration/src/mongodb_migration/check.py
34.48% <0.00%> (ø)

libs/libcommon/src/libcommon/config.py
77.96% <ø> (ø)

...20230216141000_queue_split_names_from_streaming.py
46.15% <46.15%> (ø)

...20230216112500_cache_split_names_from_streaming.py
55.55% <55.55%> (ø)

services/worker/src/worker/job_runner_factory.py
89.28% <66.66%> (ø)

...ngodb_migration/src/mongodb_migration/collector.py
100.00% <100.00%> (ø)

libs/libcommon/tests/test_processing_steps.py
100.00% <100.00%> (ø)

...c/worker/job_runners/split_names_from_streaming.py
95.74% <100.00%> (ø)

...sts/job_runners/test_split_names_from_streaming.py
96.72% <100.00%> (ø)

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

:umbrella: View full report at Codecov.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.


tooltip.x wrong on multiple datasets in linecharts

I am trying to display a custom tooltip i a linechart.
The tooltip.x value is correct for single dataset.
Is I add a second dataset the tooltip.x is offset after 50% from the left of the chart.
here is the fiddle: http://jsfiddle.net/delcon/sx36dpkw/. Try and delete one dataset and the tooltip is back where it should.

@delcon what happens is that there are multiple items found and so the tooltip is positioned at the average of their positions.

@etimberg I am referring to the x coordinates. x coordinates should not average between items, they should refer to the corresponding axis. I think the fiddle shows that the custom tooltip currently can not be used as expected.

@delcon agreed that it's an issue. The position is determined here: https://github.com/nnnick/Chart.js/blob/master/src/Chart.Core.js#L1047-L1089
I'd be happy to look over a PR that updates this for custom tooltips.

Hello, today I am closing all issues that are only affecting version 1 of Chart.js as WONTFIX.
If this issue does affect version 2 as well, I apologize for the error. Please create a test case against Chart.js 2 using on of the below websites and we will be happy to reopen the issue and update its classification:

http://jsbin.com/
http://jsfiddle.net/
http://codepen.io/pen/
Premade template: http://codepen.io/pen?template=JXVYzq


Does this repo contain your training code

I wanted to see how you implemented the loss function and back-propogated against it, but i cant find it in the code.  Is the training code available to look at

This repository currently only contains inference code, focusing on a wide-suite of tasks. But we plan to make some training stuff available soon, stay tuned!


Type mismatch in Task Graph examples

The Task Graph page http://www.scala-sbt.org/1.x/docs/Task-Graph.html contains three examples containing the expression ur.allConfigurations.take(3) which all seem broken:
$ cat build.sbt
scalacOptions := {
  val ur = update.value  // update task happens-before scalacOptions
  val x = clean.value    // clean task happens-before scalacOptions
  // ---- scalacOptions begins here ----
  ur.allConfigurations.take(3)
}

$ sbt
[info] Updated file /home/kelemen/temp/sbt-started/project/build.properties: set sbt.version to 1.0.2
[info] Loading project definition from /home/kelemen/temp/sbt-started/project
[info] Updating {file:/home/kelemen/temp/sbt-started/project/}sbt-started-build...
[info] Done updating.
/home/kelemen/temp/sbt-started/build.sbt:5: error: type mismatch;
 found   : scala.collection.immutable.Vector[sbt.librarymanagement.ConfigRef]
 required: Seq[String]
  ur.allConfigurations.take(3)
                           ^
[error] Type error in expression
Project loading failed: (r)etry, (q)uit, (l)ast, or (i)gnore?

Thanks @kelemensanyi.

Hey there, i am new into sbt and was also reading through the tutorial and hit the problem.
I managed to edit the line to make it work, and it seems like that its working how its intented to work.
I changed
ur.allConfigurations.take(3)
to
ur.allConfigurations.take(3).foldLeft[Seq[String]](Nil)((a, b)=>{(b.name::Nil)++:a})
and its running without errors.
When i type
show scalacOptions
i am getting this result, which seems legit
sbt:Hello> show scalacOptions
[info] 123
[info] 456
[info] * test
[info] * runtime
[info] * compile
[success] Total time: 0 s, completed 02.12.2017, 23:59:43

I would like to have confirmation uppon that, because i can't really myself, as i am new into sbt.

ur.allConfigurations.map(_.toString) should be good enough :)
scalacOptions := {
  println(">>>>>>>>>>>>>>>>>>>>")
  var ur =  update.value
  clean.value
  println("<<<<<<<<<<<<<<<<<<<<")
  ur.allConfigurations.map(_.toString)
},

gives then:
[IJ]sbt:work> show scalacOptions
[info] Updating ...
[info] Done updating.

<<<<<<<<<<<<<<<<<<<<
[info] * compile
[info] * runtime
[info] * test
[info] * provided
[info] * optional
[info] * compile-internal
[info] * runtime-internal
[info] * test-internal
[info] * plugin
[info] * pom
[info] * scala-tool
[success] Total time: 1 s, completed Feb 25, 2018 10:42:55 PM
[IJ]sbt:work>


update schema compare to 1.10.0 in RC

build with schema compare vsix: https://mssqltools.visualstudio.com/CrossPlatBuildScripts/_build/results?buildId=99644&view=artifacts&pathAsName=false&type=publishedArtifacts

We are updating SC this time?

@udeeshagautam yup to get the fix for https://github.com/microsoft/azuredatastudio/issues/14957 and https://github.com/microsoft/azuredatastudio/issues/12779

@abist I am assuming the release DRI will merge and publish, right?

Extension uploaded.

@abist did you also upload the extensions-gallery file? I don't see the updated schema compare extension in the RC build yet


Compiling Autoware

Checklist

[X] I've read the contribution guidelines.
[X] I've searched other issues and no duplicate issues were found.
[X] I'm convinced that this is not my fault but a bug.

Description
I am attempting to install Autoware following source installation method but always fail during colcon build.
Expected behavior
Autoware builds without error.
Actual behavior
--- stderr: yabloc_monitor
/home/yuqi/autoware/src/universe/autoware.universe/localization/yabloc/yabloc_monitor/src/yabloc_monitor_core.cpp: In constructor ‘YabLocMonitor::YabLocMonitor()’:
/home/yuqi/autoware/src/universe/autoware.universe/localization/yabloc/yabloc_monitor/src/yabloc_monitor_core.cpp:27:39: error: literal operator suffixes not preceded by ‘_’ are reserved for future standardization [-Werror=literal-suffix]
   using std::chrono_literals::operator""ms;
                                       ^~~~
cc1plus: all warnings being treated as errors
gmake[2]: *** [CMakeFiles/yabloc_monitor.dir/build.make:90: CMakeFiles/yabloc_monitor.dir/src/yabloc_monitor_core.cpp.o] Error 1
gmake[1]: *** [CMakeFiles/Makefile2:137: CMakeFiles/yabloc_monitor.dir/all] Error 2
gmake: *** [Makefile:146: all] Error 2
---
Failed   <<< yabloc_monitor [10.3s, exited with code 2]
Aborted  <<< eagleye_rt [6.91s]
Aborted  <<< mrm_comfortable_stop_operator [7.05s]
Aborted  <<< autoware_external_api_msgs [6.79s]
Aborted  <<< automatic_pose_initializer [6.93s]
Aborted  <<< qp_interface [5.35s]
Aborted  <<< mrm_emergency_stop_operator [6.94s]
Aborted  <<< tier4_hmi_msgs [7.81s]
Aborted  <<< tier4_perception_msgs [10.8s]
Aborted  <<< morai_msgs [14.4s]
Aborted  <<< ad_api_adaptors [9.12s]
Aborted  <<< autoware_auto_vehicle_msgs [13.4s]
Aborted  <<< traffic_light_arbiter [11.0s]
Aborted  <<< livox_tag_filter [12.6s]
Aborted  <<< duplicated_node_checker [13.9s]
Aborted  <<< polar_grid [9.23s]
Aborted  <<< diagnostic_graph_aggregator [14.8s]
Aborted  <<< radar_scan_to_pointcloud2 [8.49s]
Aborted  <<< dummy_infrastructure [18.0s]
Aborted  <<< eagleye_fix2kml [19.0s]
Aborted  <<< map_tf_generator [27.0s]
Aborted  <<< yabloc_common [30.9s]
Aborted  <<< costmap_generator [35.2s]
Aborted  <<< nebula_ros [1min 26s]

Summary: 104 packages finished [1min 30s]
  1 package failed: yabloc_monitor
  23 packages aborted: ad_api_adaptors automatic_pose_initializer autoware_auto_vehicle_msgs autoware_external_api_msgs costmap_generator diagnostic_graph_aggregator dummy_infrastructure duplicated_node_checker eagleye_fix2kml eagleye_rt livox_tag_filter map_tf_generator morai_msgs mrm_comfortable_stop_operator mrm_emergency_stop_operator nebula_ros polar_grid qp_interface radar_scan_to_pointcloud2 tier4_hmi_msgs tier4_perception_msgs traffic_light_arbiter yabloc_common
  6 packages had stderr output: diagnostic_graph_aggregator livox_tag_filter nebula_ros traffic_light_arbiter yabloc_common yabloc_monitor
  206 packages not processed

Steps to reproduce
Followed steps on https://autowarefoundation.github.io/autoware-documentation/main/installation/autoware/source-installation/
Versions

Autoware release v1.0

Possible causes
No response
Additional context
No response

@YuqiHuai Thank you for reporting the issue. However, in my environment, the error does not occur, and the build succeeds.
Could you please provide your OS and PC architecture to help identify the cause?

Hi @KYabuuchi thanks for getting back to me! I noticed build would succeed in the docker container but for some reason fails outside.
I am currently running Intel Core i9-12900K running Ubuntu 22.04.1 (Linux yuqi-MS-7D31 6.5.0-35-generic #35~22.04.1-Ubuntu), cmake version 3.22.1
I am currently trying to develop a Python script that subscribes to different Autoware topics and I wanted to develop this outside of the docker container therefore I attempted to build from source. Considering my purpose and this build issue potentially being specific to myself, would you recommend I stay with using the container image for now?

@YuqiHuai  Thanks for sharing the OS and other info. However, I don't see anything that could be the cause...
I don't know of any solutions right now, so I would recommend using the environment once you are able to compile it. Sorry.

I noticed that literals become warnings in g++7 and earlier. Are you using older g++ in your environment?

reference: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65923#c8

Hi @KYabuuchi , thanks for helping me to do more investigation. Apparently I have
gcc --version
gcc (Ubuntu 11.4.0-1ubuntu1~22.04) 11.4.0

therefore it might be something else :(

Hmm... :cry: I can't provide an immediate solution. Sorry

Sorry for barging in. could you check if you have any non standard environment variables set with  printenv?
As a hotfix, in yout environment you could probably use --cmake-args and -Wno-error=literal-suffix

@KYabuuchi no worries! I guess if this is really just a specific issue on my machine we can close this issue, I should try different ways to figure this myself and maybe provide an update if I am able to figure it out. Currently I will stay with docker installation.
@knzo25 Thank you for barging in! Well, unfortunately I am not too familiary with cmake args and I am not sure what "non standard environment" there could be. I have already gone through many problems because I was using pyenv, I had to totally disable that and use only system Python. This hot fix will likely work and thank you for this suggestion! But for now I am deciding to stay with docker build as I am able to very consistently build Autoware in the container.

Since this seems to be the author-specific issue, I will close the issue.
If anyone has new information, or finds that it is an autoware issue, please feel free to reopen it. :pray:


Fix a11y warning

Fix #198 problem from https://github.com/moroshko/react-autosuggest/issues/198

I don't this we should hard code the tabIndex value. Consumers of the Autowhatever component should provide the tabIndex via itemProps.


Wiki issue with Getting Started

The getting started document (wiki/Getting-Started) contains the following text:
NOTE: This guide assumes you already have Fabric.Identity installed and have the fabric-installer secret. For proper installation documentation see Installing Fabric.Identity.
But the link points back to the same (wiki/Getting-Started) document. It should instead contain two links with one pointing to (wiki/Installing-Fabric.Identity-in-a-Server-environment) and the other to (wiki/Installing-Fabric.Identity-in-a-Development-environment)

Thanks, Andrew. I just updated the documentation to point to the server installation. I did rename it to just installing on windows, and I removed the dev environment installation instructions to simplify things.


Unclear text on Workflow syntax page

Code of Conduct

[X] I have read and agree to the GitHub Docs project's Code of Conduct

What article on docs.github.com is affected?
https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idname
What part(s) of the article would you like to see updated?
There is a typo in the (single) sentence of this section, though it is not entirely clear what this sentence should say:

Use jobs.<job_id>.name to a name for the job, which is displayed on GitHub.

Additional information
No response

@gsrohde Thanks so much for opening an issue! I'll triage this for the team to take a look :eyes:

Thanks for spotting this. I think it can be clarified to say: "[...] to set a name for the job, which is displayed in the GitHub UI."


Table features we need

Using this issue to track the features we need to make sure we have for our table implementation

[ ] Is a table - looks like a table

Selection

[ ] Cell Selection
[ ] Row Selection
[ ] Changable selection model
[ ] Drag selection
[ ] Keyboard navigation

Looks

[ ] Themable for selection, hover, selection row, hover row
[ ] (Optional) hover column, selection column
[ ] Custom Cell renders, multiple per table

Data

[ ] Windowed scrolling
[ ] (Optional) Cacheing
[ ] async data retrieval
[ ] (Optional) pre render number of rows (scroll height)
[ ] (Optional) filtering
[ ] (Optional) Sorting
[ ] (Optional) find

Interaction

[ ] Event driven interaction
[ ] On click
[ ] On right click
[ ] On key press

I'm probably missing some features here.

Going to backlog this since we don't need to immediately anymore

@anthonydresser are you still tracking anything with this issue?  If not, please close it out.  Thanks!

Closing older issues


MintableToken using Roles

[note that this is going into the rbac-migration branch, which will be merged into master once #1146 is considered solved by it]
Depends on #1235: the diff will be a bit messy until that PR is merged and this one rebased.
MintableToken no longer uses RBAC, and instead is implemented with a single Role. This MinterRole contract provides initial assignment, all necessary public methods (query and transfer), an access modifier, and internal methods for extensions (i.e. derived contracts may add or remove minters), while preventing direct access to the Role struct itself. This 'boilerplate' will likely be repeated for every single role that we implement (BurnerRole, PauserRole, etc.): ideally, we'd autogenerate those contracts from a template.

Addressed those, thanks!

@nventuro can you merge master? looks like there are some conflicts

@nventuro This PR shouldn't be targetting master right?

Gah you're right, thanks!

I've decided to add some extra bits to this PR (namely MinterRole tests) - we shouldn't merge yet.

The test behavior should be reusable by all publicly-exposed roles (which I very poorly called PublicRole): the method names are inferred from the role name. A mock has to be created however, exposing the addRole and removeRole methods.

@shrugs @frangio ready for review


fix: config

Proposed changes
Removes single quotes from an env var. The current config makes the default value fail when loading.
Fixes
n/a
Types of changes
What types of changes does your code introduce? (A breaking change is a fix or feature that would cause existing functionality and APIs to not work as expected.)
Put an x in the box that applies

[x] Non-breaking fix (non-breaking change which fixes an issue)
[ ] Breaking fix (breaking change which fixes an issue)
[ ] Non-breaking feature (non-breaking change which adds functionality)
[ ] Breaking feature (breaking change which adds functionality)
[ ] Refactor (non-breaking change which changes implementation)
[ ] Messy (mixture of the above - requires explanation!)

Checklist
Put an x in the boxes that apply.

[x] I have read the CONTRIBUTING doc
[x] I am making a pull request against the main branch (left side). Also you should start your branch off our main.
[x] Lint and unit tests pass locally with my changes
[ ] I have added tests that prove my fix is effective or that my feature works
[ ] I have locally run services that could be impacted and they do not present failures derived from my changes

Further comments
n/a

Codecov Report
Base: 99.92% // Head: 100.00% // Increases project coverage by +0.07% :tada:

Coverage data is based on head (9644f54) compared to base (2032462).
Patch has no changes to coverable lines.

Additional details and impacted files
@@             Coverage Diff             @@
##             main       #88      +/-   ##
===========================================
+ Coverage   99.92%   100.00%   +0.07%
===========================================
  Files          22        22
  Lines        1281      1280       -1
===========================================
  Hits         1280      1280
+ Misses          1         0       -1

Flag
Coverage Δ

unittests
100.00% <ø> (+0.07%)
:arrow_up:

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

Impacted Files
Coverage Δ

...y/skills/dynamic_nft_abci/tests/test_behaviours.py
100.00% <0.00%> (+0.31%)
:arrow_up:

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

:umbrella: View full report at Codecov.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.


6K input OOM on ARC  with VLLM-serving

Faced OOM on Arc with 6k input/512 out with VLLM serving, Mode: ChatGLM3-bB, Qwen1.5-32B on 4 ARC

We have verified 6k input/512 out with VLLM serving with ChatGLM3-bB on 2 ARC,  Qwen1.5-32B on 4 ARC.


Implement anti-aliasing, controller vibration and uncapped framerates?

Is it possible to implement any of these?
Also, would it be possible to for the intro videos to scale to the top of the screen. At the moment, they run with no scaling.
Thanks

Going down the list:
Antialiasing is one I've thought about.  I plan to do some more work on making the D3D initialization a bit better, and this was on the list as something that seems pretty trivial to implement.
Vibration has been brought up before.  It didn't exist in the original version of the game, so the functions used to control vibration are potentially optimized out of the game entirely.  Needs a lot of non-trivial research, but it's on my list to look deeper into.
  The gameplay logic, while it does base most of its calculations on the real time between frames, does still have some framerate dependent behavior.  Some quick examples are long trick point accrual, script run intervals (I think.  THPS4 has this issue but maybe 3 hadn't yet implemented this), and special meter depreciation (based on rounding to an integer, so it's not a trivial "just put delta time in there" modification).  So the solution would have to be to run the gameplay logic at 60hz and apply interpolation to the visuals, another thing that is rather difficult.  I want to experiment with the idea but I'm not sure it's something I'd ever actually include in the mod.
Video scaling is in desperate need of a revisit.    I'd be surprised if there's not a way to scale that to the window dimensions.  If not, I've had rewriting the video player entirely on my list of long shot goals.


Continuum Does Not Save Session After Interval Time

Hello,
I am having an issue where this plugin does not save my session after the desired interval time of five minuets. I have the following settings
## Update the saved session every five minuets.
set -g @continuum-save-interval '5'

## Enable automatic session restoring.
set -g @continuum-restore 'on'

## Load the tmux-conium plugin.
run-shell ~/.config/tmux/plugins/tmux-continuum/continuum.tmux

but I always have to manually save in order for my saved session to be updated.
As a side question, how would I have tmux does run the specified default command only when continuum restores a session? For example, I have tmux run my SHELL every time I start it, but if I am restoring a session with continuum, then I do not want that command executed and simply want my session restored.

Probably #48 also see #99

No, it does save.
My settings:
set -g @plugin 'tmux-plugins/tpm'
set -g @plugin 'tmux-plugins/tmux-sensible'
set -g @plugin 'tmux-plugins/tmux-resurrect'
## set -g @resurrect-dir '~/.local/share/tmux/resurrect'
set -g @plugin 'tmux-plugins/tmux-continuum'
set -g @continuum-save-interval '5'
set -g @continuum-restore 'on'
set -g status-right 'Continuum status: #{continuum_status}'

## ... your other settings

## Required on last
run "~/.config/tmux/plugins/tpm/tpm"

No, it does save.
My settings:
set -g @plugin 'tmux-plugins/tpm'
set -g @plugin 'tmux-plugins/tmux-sensible'
set -g @plugin 'tmux-plugins/tmux-resurrect'
## set -g @resurrect-dir '~/.local/share/tmux/resurrect'
set -g @plugin 'tmux-plugins/tmux-continuum'
set -g @continuum-save-interval '5'
set -g @continuum-restore 'on'
set -g status-right 'Continuum status: #{continuum_status}'

## ... your other settings

## Required on last
run "~/.config/tmux/plugins/tpm/tpm"

I have something similar to this, but am still experiencing this issue. I have my plugin settings and everything set. I am not sure what other information I should be provided, but this simply does not work even when I only load plugins and set nothing else.

Probably #48 also see #99

Sorry for the extremely late reply, I have been busy with university. Is the solution still to use a systemd timer or cron job? I just want to make sure, but nevertheless those are easy to write up. Thank you for your help.

Hey - are you on macos or linux? I've been setting up conttinuum on Ubuntu 21.10 and I had to make some changes to get the automatic systemd service running. https://github.com/tmux-plugins/tmux-continuum/pull/102

Hi, I found that my autosave does not work if set -g status-right is set to a non-default string. Is it dependent on the clock, which is configured as the default?


Regarding spacing

When press the enter key on keyboard, cursor jumps two lines below in editor
How to take care of that

And also kindly help me out in below scenario

How to insert/append any text/letter/word in editor, where cursor positioning currently
In case of copy/paste word  or append/prepend/insert word

I'm terribly sorry.The reply is a little late,  I don't quite understand what you mean.
if you can, I hope to your use GIF to illustrate it.


About slide solutions

Using slides to display albums, 4000 photos slide very slowly, and do you have any good solutions?
my code:
<ion-slides *ngIf="alreadyShowPhoto" initialSlide="{{indexLibraryCurrent}}" >
    <ion-slide *ngFor="let libraryItem of librarySlide">
        <img *ngIf="libraryItem" [src]="libraryItem.photoURL | cdvphotolibrary">
    </ion-slide>
</ion-slides>

Hello! Thanks for opening an issue with us! As this seems like more of a support question I will urge that you ask this question on our forum or on our slack channel. Thanks for using Ionic!


chore(wip): fixes for legacy amino encoding for ledger signing

Description

closes: #XXXX

Before we can merge this PR, please make sure that all the following items have been
checked off. If any of the checklist items are not applicable, please leave them but
write a little note why.

[ ] Targeted PR against correct branch (see CONTRIBUTING.md).
[ ] Linked to Github issue with discussion and accepted design OR link to spec that describes this work.
[ ] Code follows the module structure standards and Go style guide.
[ ] Wrote unit and integration tests.
[ ] Updated relevant documentation (docs/) or specification (x/<module>/spec/).
[ ] Added relevant godoc comments.
[ ] Provide a commit message to be used for the changelog entry in the PR description for review.
[ ] Re-reviewed Files changed in the Github PR explorer.
[ ] Review Codecov Report in the comment section below once CI passes.

Codecov Report

Merging #4812 (8a0ec2e) into main (a2ba6dd) will decrease coverage by 0.05%.
Report is 6 commits behind head on main.
The diff coverage is 20.00%.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #4812      +/-   ##
==========================================
- Coverage   79.86%   79.82%   -0.05%
==========================================
  Files         189      189
  Lines       13248    13242       -6
==========================================
- Hits        10581    10570      -11
- Misses       2242     2247       +5
  Partials      425      425

Files
Coverage Δ

modules/apps/transfer/types/codec.go
86.20% <100.00%> (-1.30%)
:arrow_down:

modules/apps/29-fee/types/codec.go
66.66% <0.00%> (-33.34%)
:arrow_down:

See SDK issue for more details: https://github.com/cosmos/cosmos-sdk/issues/17975
The changes in this PR are still relevant and should be included. The issue is due to the internal proto registries not being populated with ibc types.

Tested local signing using https://github.com/cosmos/cosmos-sdk/pull/17996


404 start code

I keep getting a 404 error when I try to download the starter code on step 2 of  Background Work with WorkManager - Kotlin tutorial

Thanks for reporting, this seems to be a duplicate of https://github.com/googlecodelabs/android-workmanager/issues/217.
For now you can access the codelab with a working link for the starter code from here: https://codelabs.developers.google.com/codelabs/android-workmanager#1.
Alternatively, you can also check out this repo and use the start_kotlin branch.

Thanks for reporting, this seems to be a duplicate of https://github.com/googlecodelabs/android-workmanager/issues/217.
For now you can access the codelab with a working link for the starter code from here: https://codelabs.developers.google.com/codelabs/android-workmanager#1.
Alternatively, you can also check out this repo and use the start_kotlin branch.


[question/suggestion] Link target blank

Hey,
thank you for your work on this plugin, it makes using Strapi way better :)
One question/suggestion: Could you please add the ability to decide if a link has target blank or not?
Thank you very much!

Very good idea!
I just implemented it in 0.6.4, which I have just released now.


Missing usdCycles schema repo ?

Hey guys,
I finally got to compile hdCycles on Windows, it's pretty sweet, and seems pretty responsive already ! I was wondering where the schema's were ? The link on the build instructions points to a usdCycles github repo, but that looks like a dead link.
Thanks !

This feature is coming up very soon. You can test it #122, before it's being merged on main we have to resolve some internal issues.

I am closing this one. usdCycles is generated at build time. You need to have usdGenSchema script available in order for schema to be generated.


Remove python icecream library dependency

The icecream debugging library was required by doth/biquad.py. That file imported icecream so it could not run without the library present. However, aside from importing it, it did not use the library. This commit removes the import statement so that there is one less dependency to install.

Never mind, I should have been looking at https://github.com/schollz/_core and I'll have a harder time there convincing you to do this. :)


Deserialization refactor: introduce new deserialization traits

Refs #961
The new traits
This PR introduces the new deserialization traits, DeserializeValue and DeserializeRow, which are going to replace FromCqlVal and FromRow, respectively.
If a type implements DeserializeValue<'f>, this means that it can take a buffer of lifetime 'f and deserialize itself, treating the contents of the buffer as a CQL value. Analogously, DeserializeRow<'f> allows for deserialization of types that are supposed to represent a whole row returned in the results.
Deserialization is now split into two phases: type checking and actual deserialization. Both traits have two methods: type_check and deserialize. The idea behind this is to validate the column types of the response only once, after the response is received. The deserialize method is then called for each row/value to perform the actual parsing: that method is allowed to assume that type_check was called and may skip some type checking for performance (although it cannot use that assumption to perform unsafe operations, it is not an unsafe method).
The previous framework only supported deserialization of types that exclusively own their data, for example String or Vec<u8>. However, the new framework allows for types that borrow or co-own the frame buffer:
- Types that borrow the buffer are &'f str and &'f [u8]. They just point to the raw data from the serialized response. Rust's lifetime system  makes sure that the the user doesn't deallocate the serialized  response until using the deserialized types that point to the buffer are dropped. Apart from the aforementioned types, a bunch of iterator types have been introduced that allow consuming collections without allocations.
- Serialized frame is represented with bytes::Bytes. It is possible to create a subslice (also of type Bytes) that keep the original alive. The type being deserialized can obtain access to such subslice. Like in the case of e.g. &str vs. String, keeping Bytes  allows to avoid an allocation, but it is also easier to handle as deserialized type doesn't have to be bound by any lifetime. It important to be careful when handling such types as they keep whole serialized frame alive, even if they only point to a subslice. This can lead to a space leak and more memory being used than necessary.
Implementation of the new traits for all supported types
All the previously supported types (i.e. those that could be deserialized using the old framework) are supported now as well.
There is only one exception: CQL List is no longer deserializable into a set (HashSet or BTreeSet), because such conversion could be lossy, which is an unwanted property for deserialization.
Errors
The error framework is analogous to one used in the serialization framework: DeserializationError is added that resembles SerializationError and is type-erased as well.
As the new deserialization framework has separate type_check() and deserialize() function (contrary to the serialization framework, which has only one serialize() method), it makes sense for them to return distinct errors.
That's why a new TypeCheckError is added, too, which is type-erased as well.
Testing
All new types are unit tested.
Additionally, a decent test suite is added to verify compatibility of the old and the new framework.
New errors are tested, too, although not exhaustively. I'd prefer not to bog down too much in testing them thoroughly.
Pre-review checklist

[x] I have split my patch into logically separate commits.
[x] All commit messages clearly explain what they change and why.
[x] I added relevant tests for new features and bug fixes.
[x] All commits compile, pass static checks and pass test.
[x] PR description sums up the changes and reasons why they should be introduced.
[x] I have provided docstrings for the public items that I want to introduce.
[ ] I have adjusted the documentation in ./docs/source/.
[x] I added appropriate Fixes: annotations to PR description.

v2:

addressed most review comments (though DeserializeCql -> DeserializeValue rename has not yet been done),
set up and used an error framework similar to that used in serialization.

While reviewing, please pay attention to the error types used, especially to the use of GenericParseError variant (which I hate, but before errors refactor I can do little about this).

Additional question: do we want to expose all of the iterator types to the users? I'm aware that UdtIterator might be useful to implement deserialization for custom user types. What about other iterators such as ListLikeIterator or MapIterator? Do you see any reason for exposing these?

exposing them might be useful for cpp-rust-driver (but in this aspect it's better to start with private visilibity and make it public only if really needed there),
it's not scylla-cql crate that should control visibility of the exports; it's scylla crate's responsibility to organise exports, just like you've recently done wrt some other exports from scylla-cql. Ideally, only leaf items (e.g. structs, consts, enums, etc.) are re-exported by scylla from scylla-cql, no node items (i.e. modules) - this gives the finest control over visibility.

v3:
- addressed more review comments, including: better names for FrameSlice methods.
- still TODO: DeserializeCql -> DeserializeValue, keep BuiltInTypeCheckError separate for serialization and deserialization for more accurate error messages.

Rebased on main.

v3.1:

replaced assert!(matches!(...)) with assert_matches!(...) codewide.

v3.2:

rebased on main to fix clippy complaints.
an independent prefix of this PR has been sent as #1004 to make this PR a bit smaller.

v4:

type check errors are no longer shared between serialization and deserialization. Entirely different types for BuiltinTypeCheckError are introduced for deserialization.

v4.1:

fully qualify chrono types

v4.2 - fixed outdated docstring that led to CI failing.

Reviewers: is it acceptable for you that DeserializeCql is only renamed to DeserializeValue in one commit at the end of this PR? This saves me a lot of time to rename it in all consecutive commits.

I've got a general comment about DeserializationError. The docstring mentions:
/// As for the impls defined or generated
/// by the driver itself, the following errors can be returned:
/// - [`row::BuiltinDeserializationError`]
/// - [`value::BuiltinDeserializationError`]

In my opinion, that's not entirely true, since there are places where nested DeserializationErrors are created directly from ParseError (see the DeserializationError::new() usages).

I'm glad you noticed that. However, note that all DeserializationError::new() call results are placed inside another BuiltinDeserializationError (can you verify that together with me?). This means that if the user hold a DeserializationError produces by our lib code, then the outermost error there will be always BuiltinDeserializationError. Am I right?

I've got a general comment about DeserializationError. The docstring mentions:
/// As for the impls defined or generated
/// by the driver itself, the following errors can be returned:
/// - [`row::BuiltinDeserializationError`]
/// - [`value::BuiltinDeserializationError`]

In my opinion, that's not entirely true, since there are places where nested DeserializationErrors are created directly from ParseError (see the DeserializationError::new() usages).

I'm glad you noticed that. However, note that all DeserializationError::new() call results are placed inside another BuiltinDeserializationError (can you verify that together with me?). This means that if the user hold a DeserializationError produces by our lib code, then the outermost error there will be always BuiltinDeserializationError. Am I right?

Yes, you are right. That's why I mentioned that only nested errors are created in a way that is not consistent with the docs. I don't think we need to adjust the docs or internal usages of DeserializationError::new() in any way. I just pointed out a small inconsistency, to make sure that we all are aware of it and that it does not affect users.

Reviewers: is it acceptable for you that DeserializeCql is only renamed to DeserializeValue in one commit at the end of this PR? This saves me a lot of time to rename it in all consecutive commits.

Fixed this. Commits now mention DeserializeValue from the very first place.

v4.3:

ditched FrameSlice::new_subslice();
fixed read_cql_bytes() so that they really satisfy their guarantee about not mutating the FrameSlice in case of an error.

v4.4:

added got field to row::BuiltinTypeCheckError, so that error message is richer in CQL column types now. Adjusted tests to check that.

v4.4:

fixed bad tuple index in DeserializeValue impl for tuples.

v4.5:

corrected docstring on FrameSlice::read_cql_bytes(),
renamed TupleDeserializationError::ElementDeserializationFailed to FieldDeserializationFailed,
added TupleTypeCheckError::FieldDeserializationFailed,
fixed tuple DeserializeValue impl to correctly wrap errors,
added tests for tuple errors (passing only after the above changes).

v5.0:

refactored deser_cql_value and deser_rows to use the new deserialization framework. Wins:

less code duplication,
better error messages in the old framework (coming from the new framework).

v5.0:
* refactored `deser_cql_value` and `deser_rows` to use the new deserialization framework. Wins:

  1. less code duplication,
  2. better error messages in the old framework (coming from the new framework).

Keep in mind that now, with those changes introduces, compatibility tests between the new and the old framework and no longer relevant, because the old framework's backbone (deser_cql_value with all the impls) is deleted. Then:

Should we even keep those compatibility tests? They no longer prove anything. After all, they proved what we wanted them to prove, in earlier commits, and now are useless.
Should we perhaps postpone introducing those changes until we delete the whole old framework altogether? Then the tests are still valid.

v5.2: impl_tuple_multiple() macro related changes:

documented the macro;
added a special entry rule to the macro, so now its syntax is cleaner (no longer requires <, > characters to be passed) and the impl for () comes first, not last;
deduplicated the macro by importing it to row.rs from value.rs.

v5.3:

rebased on main.

v5.3.1:

fixes after rebasing on main.

v5.4:

added a convenience function to be used in new tests (not yet pushed)

v6.0:

removed old/new framework compatibility tests, as they no longer test anything;
wrote a suite of ser/de identity tests; they assert that a value after serialization and then deserialization is the same as before.

v6.0.1:

fixed one import not found for MSRV Rust

v6.0.2:

fixed datetime tests

Resolved comments:

fixed size_hint,
tuple element -> field.

v6.0.5:

decreased pub visibility of some functions

v6.0.6:

sprinkled #[inline] over short pub functions.

v6.0.7:

renamed BuiltinTypeCheckErrorKind::ColumnTypeMismatch to ColumnTypeCheckFailed

v6.0.8:

removed exp() test, used for review purposes only.

v6.1:

constrained pub reexports in scylla/lib.rs.

v6.1:
* constrained pub reexports in scylla/lib.rs.

I don't see a push for this change. Did you forget to push it or Github broke displaying somehow?

v6.1:
* constrained pub reexports in scylla/lib.rs.

I don't see a push for this change. Did you forget to push it or Github broke displaying somehow?

If you look above, you'll see scylla lib: constrain pub deserialize reexports. The reason why GH didn't show it is that I added it as a new commit on top of others.

v6.2:

fixes to docstrings.

Rebased on main.

v6.3:

changed UdtIterator Item a bit (will be useful for derive macros in the follow up)
added test cases that checks errors when collections are attempted to be deserialized from null.


#44981 Add link to Minikube in "Install and Set Up kubectl on macOS" in verify-kubectl.md

Linking directly to the Minikube installation guide when it is first
mentioned ensures the user has immediate access at the point
in the kubectl installation when it becomes relevant.

Hi @deadandhallowed, Please sign EasyCLA.

Details and signing procedure can be found in these 2 ( 1, 2) links.

EasyCLA help reviewers to verify and approve legitimate PRs from approved contributors.

fixes - #44981

It would be great If you can also add the issue for which we are creating this PR
Do sign the EasyCLA !

I signed the CLA -- what else could it be missing? Is there another step to get it fully approved?

/retitle Add link to Minikube in "Install and Set Up kubectl on macOS"

I'm unclear on why we should make this change; see https://github.com/kubernetes/website/issues/44981#issuecomment-1922102046 for a related opinion.
/hold

I'm unclear on why we should make this change; see #44981 (comment) for a related opinion.
/hold

If the glossary tooltip is still too much, we don't have to do it. I thought it would be helpful, but I happily defer to your expertise.

The quibble is: why only tell Mac users?

@deadandhallowed, Seems like the issue #44981 is already addressed here in PR #45636 , so you can close this PR.


Light level overlay does not show up

I know I've installed the mod properly as it shows up in the mods list and the chunk boundaries appear when pressing F9 but the F7 key does not do anything for me. I've double checked the config file and everything appears to be enabled.
Edit: the only idea I have is a possible conflict with optifine or fastcraft but I’ve been unable to test

I have the same issue when using Optifine with BSL shaders on MC Eternal modpack (More Overlays version is 1.15.1)


[asset caching] Add cli parameter to pass asset sources

Closing https://discord.com/channels/400588936151433218/687365466422902841/877303084940918814

LGTM, thanks!


Unit tests the sysiphus of coding

Add support for testing installs that do not have the seaborn or matplotlib libraries installed.

Coverage increased (+0.1%) to 95.889% when pulling 69e666ec3d3d7b684169f23ab02b7965a1ad2b8d on unit-tests-the-sysiphus-of-coding into 8e46ffa951d94c948191e6791ddc20732e885eaa on develop.

Coverage increased (+0.1%) to 95.91% when pulling 8723e78f51d1629c0ca510f6fd579b71dc56314c on unit-tests-the-sysiphus-of-coding into 8e46ffa951d94c948191e6791ddc20732e885eaa on develop.

Coverage increased (+0.1%) to 95.91% when pulling 8723e78f51d1629c0ca510f6fd579b71dc56314c on unit-tests-the-sysiphus-of-coding into 8e46ffa951d94c948191e6791ddc20732e885eaa on develop.

Coverage increased (+0.1%) to 95.929% when pulling 06b27c846a1614ddef31bfdb4e1ceed7fa7637d8 on unit-tests-the-sysiphus-of-coding into 8e46ffa951d94c948191e6791ddc20732e885eaa on develop.

Coverage increased (+0.2%) to 95.947% when pulling 06b27c846a1614ddef31bfdb4e1ceed7fa7637d8 on unit-tests-the-sysiphus-of-coding into 8e46ffa951d94c948191e6791ddc20732e885eaa on develop.

Coverage increased (+0.2%) to 95.947% when pulling 06b27c846a1614ddef31bfdb4e1ceed7fa7637d8 on unit-tests-the-sysiphus-of-coding into 8e46ffa951d94c948191e6791ddc20732e885eaa on develop.

I was bored :bowtie:

🆗 🆒 👍


add more "/" in route get 405 Method Not Allowed error

I tried to use zend-expressive-skeleton, apply url /api/ping/ ( more "/" in url ) and got get 405 Method Not Allowed error.
This is an issue that was reported in https://github.com/zendframework/zend-expressive/issues/257

Okay, figured out the issue. In ZendRouter::injectRoute(), we have the following algorithm:

If the route allows any method, we inject only the specified route.
Otherwise, we inject the specified route with two child routes:

one is a Method route, specifying the various HTTP methods allowed
the other is a special "method not allowed" route, which triggers only if the Method route fails, or if the parent route matches, and additional path segments are present.

What's interesting is that the "method not allowed" route is a Regex route matching the pattern #/*$# — i.e., zero or more trailing slashes, matching at the end of the literal path provided to it. Since the route defined is /api/ping, passing the trailing slash inadvertently causes this to match.
I'm going to see if I can find a way to fix it, while keeping the "method not allowed" behavior.

@weierophinney thanks, it works now ;)


Not working within fragment when activity was created already

If you put calendarView inside fragment and put that fragment in an activity and start the activity, it works fine but if you have a drawer activity (say) and it already running and when a navigation drawer item is selected and you replace another fragment with this calendarFragment it does show up at all. It's a bug i think. Help required ASAP please!

Yep, I have the same problem. I think layout height and width isn't calculated as it should be when instantiating view at runtime.

I kinda agree with "I think layout height and width isn't calculated as it should be " but not with " when instantiating view at runtime" coz when you use calendatView inside a fragment that is attached to its activity in onCreate() then there's no problem! Weird!

Basically if the calendarView is instantiated in the onCreate() of an activity whether or not it be in a fragment (fragment attached in onCreate) or not , then there's no issue. If it's not instantiated in onCreate() then calendat does not appear. Although I've noticed that if the activity was restarted forcefully (say by the instant run) then calendar reappears!


chore: nodey206 to 0.0.3

chore: Promote nodey206 to version 0.0.3

[APPROVALNOTIFIER] This PR is NOT APPROVED
This pull-request has been approved by:
To complete the pull request process, please assign
You can assign the PR to them by writing /assign  in a comment when ready.
The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment


An experimental performance test

I did a really basic experiment in the spirit of #688, #741, #692 and following a discussion the Snabb Slack about tuning engine parameters. I am really keen to do performance tuning work based on well-defined repeatable experiments that measure a broad set of applications and workloads. This is a baby step in that direction.
Specifically, this experiment is to see how changing two parameters affects performance as measured by make benchmarks. The first parameter is engine.busywait with values true and false. The second parameter is intel10g.num_descriptors with values 512, 1024, 2048, 4096, 16384, and 32768. There are 12 distinct combinations of parameters and four benchmarks (basic1, packetblaster-*, snabbnfv-loadgen-dpdk). I run this in a loop for a few hours for a total of 179 tests.
Setup
The tests are driven by a shell script that loops through each combination of parameters. Each parameter value is represented by a Git branch that is merged into the test environment, meaning that selecting a parameter value can make an arbitrary code change.
#!/usr/bin/env bash
set -e
n=1
for busy in master busywait; do
  for ndesc in master ndesc/1024 ndesc/2048 ndesc/4096 ndesc/16384 ndesc/32768; do
    echo "run: $n"; n=$[n+1]
    date
    git checkout -B "${busy}+${ndesc}" master
    # grab the '#!/usr/bin/env bash' change for nixos compat
    git cherry-pick 1f83b5cb143a41ea8d6bfa71e9315cd9859a59a8 >/dev/null
    git merge -q --no-edit $busy
    git merge -q --no-edit $ndesc
    make >/dev/null
    make benchmarks
  done
done

Here is a summary of how the parameter branches look:
$ git log --oneline master..busywait
0d04c04 engine: Change default to busywait=true
$ git log --oneline master..ndesc/16384
e95c998 intel10g: Set TX/RX ring size to 16384 packets

and here is the script that I used to create the ndesc/nnn parameter branches:
#!/usr/bin/env bash
set -e
for ndesc in 1024 2048 4096 8192 16384 32768; do
  git checkout -B ndesc/${ndesc} master
  sed -i -e "s/^num_descriptors = .*/num_descriptors = ${ndesc}/" apps/intel/intel10g.lua
  git add apps/intel/intel10g.lua
  git commit -m "intel10g: Set TX/RX ring size to ${ndesc} packets"
done

Data
Data is here: full test log.
Here is an excerpt showing a test result with busywait=true and num_descriptors=1024:
run: 8
Sat Feb  6 10:50:24 UTC 2016
Switched to and reset branch 'busywait+ndesc/1024'
basic1-100e6 32.9 -
packetblaster-64 12.65 -
packetblaster-synth-64 12.80 -
snabbnfv-iperf-1500 0 -
snabbnfv-iperf-jumbo 0 -
snabbnfv-loadgen-dpdk 5.115 -

The data could hopefully be massaged into a suitable format (e.g. CSV) using a suitable tool (e.g. AWK).
The iperf benchmarks were not included because I couldn't get them running on lugano-1. Other applications like ALX, lwAFTR, Lisper are not covered because they are not currently in the master repository or integrated with make benchmarks (for this kind of work it would be great if they were!).
Analysis
I have not analyzed the data. I would love help from somebody who is good at that!
Here are the questions I would like to answer:

How does busywait affect performance, if at all?
How does ndesc affect performance, if at all?
Are the effects of busywait and ndesc independent?
Can we leave busywait=false as default without hurting performance?
How high can we set ndesc without losing performance?
How suitable is the data for answering these questions? (Enough data points? How much background variation? Outliers to explain?)
Anything else interesting in the data?
Anything that should be done differently in the next experiment?

Next steps
This is a very simple experiment. Here are some immediate things I would like to improve:

Control the whole test environment e.g. all software and kernel settings. For example separately test with 2MB and 1GB huge page mode on Linux (switch by rebooting with new grub parameters). Perhaps run the tests via nixops on the support server (eiger.snabb.co)?
Archive everything: the individual parameter branches, the merged parameter combination branches, and the results.
Get a basic workflow for looking at the data (e.g. import into Google Spreadsheet or Torch?).
Include more interesting benchmarks in the results.

cc @domenkozar @eugeneia

I quickly converted this to CSV, uploaded it to Google Drive, and created a simple line chart.
https://docs.google.com/spreadsheets/d/1Guo_iBC5P0i5uAkvJHWirZy_Z9nFxxyzOee9LIrraG4/edit#gid=1289069081
Don't see any significant variation between the branches. A few outliers are due to runs with zero results.
In principle this is something that could be automated using the Drive API, although there may be better ways to to this. There are certainly smarter ways to visualize the results—this is just a quick hack.

@sleinen Cool! This chart shines a light on the data in a pretty interesting way.
First that there is quite a bit of variation in the "basic1" benchmark results. The highest and lowest values differ by around 20% and there is quite a spread in between. It would be interesting to account for this (CPU? OS? JIT?) and control it (eliminate with isolcpus? reduce with longer runs? control by averaging multiple runs?). For the moment the basic1 benchmark seems not that practical for evaluating the performance impact of code changes if indeed the result can vary by 20% due to random chance.
Second that the packetblaster benchmark seems to have around a 3% failure rate. That is high! This may well be caused by an important bug in our software and warrants investigation.
I am surprised that there is so much low hanging fruit in looking at the data. And this is even when the DPDK benchmark results seem to be missing from your visualization, and those are the only ones that I expected to be potentially interesting :).
How do you make charts like that in Google Drive? How might I have made it less bothersome to generate CSV?

packetblaster benchmark seems to have around a 3% failure rate. That is high!

(Out of curiosity I just ran the packetblaster benchmark manually 500 times and didn't see any failures. I wonder what happened in the experimental run. Suggests that we should preserve logs/output!)

Yep, that's an extremely good idea. Nothing like finding a horrifically bad result you can't reproduce and aren't sure if it was an incidental artefact or something real, after all.

@sleinen Oh now I see the "Explore" button on the spreadsheet. That is super convenient!

I also did a Google Sheets import and this time included the DPDK results: https://docs.google.com/spreadsheets/d/165a9OKs5Q3yHxUX15nSrsGvTeLwvwK-U1AyQ7rgskDE/edit?usp=sharing
Anybody knows how to get Google to tell us what is going on there?
The output was a bit of a pain to massage into CSV. I used an Emacs macro but would prefer to use e.g. AWK. I wonder if it would make sense to capture all output, have everything addressable to screen-scraping, but also try to make known-interesting values easy to pick up e.g. with a convention like @parameter foo 42 and @result mybenchmark 96 to make it easy to cherry-pick values for CSV/JSON/etc. Could be handy to include a bunch of "extra" information e.g. syslog entries during each test, etc...

Second that the packetblaster benchmark seems to have around a 3% failure rate. That is high!

Note that your gist also contained two runs that my stupid Emacs query-replace-regexp didn't convert because they contained the unexpected string "Terminated" between the snabbnfv-iperf-jumbo and snabbnfv-loadgen-dpdk results:
run: 12
Sat Feb  6 13:08:39 UTC 2016
Switched to and reset branch 'busywait+ndesc/32768'
basic1-100e6 32.7 -
packetblaster-64 12.65 -
packetblaster-synth-64 12.69 -
snabbnfv-iperf-1500 0 -
snabbnfv-iperf-jumbo 0 -
Terminated
snabbnfv-loadgen-dpdk 0 -
run: 8
Sat Feb  6 13:49:22 UTC 2016
Switched to and reset branch 'busywait+ndesc/1024'
basic1-100e6 31.9 -
packetblaster-64 12.69 -
packetblaster-synth-64 0 -
snabbnfv-iperf-1500 0 -
snabbnfv-iperf-jumbo 0 -
Terminated
snabbnfv-loadgen-dpdk 0 -

...as well as a third ungrokkable entry at the end. I think that one was truncated, as it misses the final snabbnfv-loadgen-dpdk line that all the other entries had.

Anybody knows how to get Google to tell us what is going on there?

Select appropriate region
Menu: Insert -> Chart ->
Type "line chart", play around with options until it looks nice
Maybe use "Recommendations"; this automagically ignores boring columns such as the ones with all-0 results.
Then "Move to separate sheet" the resulting chart using its menu.
I did this to a copy of your spreadsheet:
https://docs.google.com/spreadsheets/d/16pkBveTUa6vFRLSnJle2nqEdmIwVsFZYHjoYdHdoVtw/edit?usp=sharing
Note I also added a row 1 with the benchmark titles, and used them as legend for the graphs.
I could only use column B as the index, so this completely mixes "master" and "busywait".  It would probably be better to combine each pair of a master+busywait row into a single row with separate result columns for master and for busywait, so that the chart then contains separate graphs for these cases.
Probably the even smarter thing to do would be to learn R and statistics and generate publication-quality graphs with the proper statistic metrics on it.  But I don't have time for that now :-)

The R/graphing stuff isn't that hard; I had to do it as an undergrad, and it'd take anyone here an hour or two, tops. Deciding what the proper statistical tools to use are is a bit hairier. :-)

So many different tools available: R, Torch, IPython, gnuplot+awk/guile/perl...
Coolest link I found today is Agile Visualization and its suite of visualization tools based on Pharo Smalltalk. That looks like potentially a convenient way to import/massage data, and do numerical charting like we are here, and also visualize things like LuaJIT trace structures and profiler results. See demo video.
In the past I have started writing bits of code for analyzing LuaJIT trace dumps in Emacs Lisp but that just feels wrong in this day and age :). Still: these are all exotic tools so I am sure it is important to keep our options open by generating simple formats e.g. CSV/JSON/text.


What is the best approach to extend to-mark markdown renderer?

Summary
We are using the Toast UI editor to implement a product that allows editing pages generated with Static Site Engines. Some of these pages use non-standard markdown syntaxes like Kramdown. We have used your excellent custom HTML renderer API to display correctly these custom markdown features in the WYSIWYG mode.
However, when switching between WYSIWYG and Markdown modes or calling the getMarkdown method, the HTML to Markdown renderer (to-mark) breaks Kramdown features. For example, Kramdown Table of Content syntax is incorrectly escaped:
-{:.no_toc .hidden-md .hidden-lg}
+{:.no\_toc .hidden-md .hidden-lg}

to-mark also escapes other characters like -
-* [**Public Issue Tracker**](https://gitlab.com/gitlab-org/gitlab/issues) - please use
+* [**Public Issue Tracker**](https://gitlab.com/gitlab-org/gitlab/issues) \- please use

We currently understand that the best way of solving this problem is extending the HTML to Markdown converter to handle this case and fallback to the default converter for all other cases. In the Toast UI API, you provide a customConvertor property that allows providing a custom implementation of the HTML to markdown converter, but we don‘t need to replace the entire HTML-to-Markdown converter. We just need to slightly customize text node renderer to properly handle Kramdown syntax.
Our use case could be solved with something very similar to custom HTML renderers, but for Markdown generation.  How do you recommend handling this scenario using Toast UI? Is it in consideration to expose to-mark so we can extend existing renderers?
We would be more than happy to contribute a Pull Request to allow this kind of extensions in to-mark
Context
As a short-term solution, we found a way of extending to-mark GFM renderer by accessing a toMarkOptions property in the editor instance.
const defaultRenderer = editor.toMarkOptions.renderer;
const richContentRenderer = defaultRenderer.constructor.factory(defaultRenderer, {
  TEXT_NODE(node) {
     const kramdownRegex = /(^{:.+}$)/;
     const text = this.trim(this.getSpaceCollapsedText(node.nodeValue));

     if(kramdownRegex.test(text)) {
       return text;
     }

     return defaultRenderer.rules.TEXT_NODE.converter.call(richContentRenderer, node);
 }
});

Object.assign(editor.toMarkOptions, { renderer: richContentRenderer });

We don’t want to rely on this solution because we are using undocumented functionalities. Nonetheless, what do you think about this solution?
Thanks in advance for your help.

@ealcantara-gitlab Sorry for the late response. We were thinking about how to handle this issue. It is correct to extend it using editor.toMarkOptions as you wrote. What we were thinking about was we had to decide whether to support this option as a public API. In conclusion, instead of supporting this option, we decided to guide you the way you used it.
Because we are planning on the next major version of the Editor, the toMark module may be removed and replaced by something else. I'd better use it this way. 👍

Hi @seonim-ryu

We were thinking about how to handle this issue. It is correct to extend it using editor.toMarkOptions as you wrote.

Thanks for validating this approach. It has really helped us to move forward our product goals.

What we were thinking about was we had to decide whether to support this option as a public API. In conclusion, instead of supporting this option, we decided to guide you the way you used it.
Because we are planning on the next major version of the Editor, the toMark module may be removed and replaced by something else. I'd better use it this way.

Makes sense. We will keep and eye on future Toast UI updates and we’ll reach you out for guidance about how to migrate from this approach to one that adapts to the future Toast UI version.
Thanks for all your help 🙇


GROOVY-9447: Add a parse tree viewer to groovy console

See https://issues.apache.org/jira/browse/GROOVY-9447

It looks and works great! +1