Marginal improvement by pipelining loads

The ld1{4 reg} variant saves us instructions
and only adds 3 cycles of latency to load 3
more neon/asimd registers worth of data.
Before:
 Tool: minigzip   Levels: 0-9
 Runs: 100        Trim worst: 40

 Level   Comp   Comptime min/avg/max/stddev  Decomptime min/avg/max/stddev  Compressed size
 0    100.008%      0.040/0.083/0.102/0.014        0.099/0.143/0.162/0.017      211,973,953
 1     44.414%      2.875/2.919/2.945/0.020        0.930/1.004/1.040/0.025       94,139,819
 2     35.521%      4.949/5.072/5.108/0.030        0.977/1.037/1.068/0.023       75,289,481
 3     33.882%      6.610/6.683/6.715/0.026        0.913/0.997/1.039/0.033       71,815,574
 4     33.175%      7.811/7.881/7.915/0.025        0.907/0.968/0.996/0.021       70,317,604
 5     32.661%      8.361/8.439/8.471/0.024        0.864/0.949/0.984/0.028       69,227,371
 6     32.507%   10.167/10.259/10.291/0.028        0.887/0.951/0.979/0.021       68,902,008
 7     32.255%   14.870/14.949/14.982/0.026        0.840/0.931/0.967/0.030       68,366,928
 8     32.167%   21.945/21.996/22.032/0.023        0.853/0.936/0.959/0.023       68,180,702
 9     31.887%   22.258/22.306/22.338/0.021        0.872/0.951/0.982/0.022       67,586,442

 avg1  40.848%                       10.059                          0.887
 avg2  45.386%                       11.176                          0.985
 tot                               6035.267                        532.020      865,799,882

After:
 Tool: minigzip   Levels: 0-9
 Runs: 100        Trim worst: 40

 Level   Comp   Comptime min/avg/max/stddev  Decomptime min/avg/max/stddev  Compressed size
 0    100.008%      0.020/0.081/0.108/0.019        0.091/0.143/0.168/0.018      211,973,953
 1     44.414%      2.782/2.879/2.914/0.027        0.940/1.000/1.028/0.019       94,139,819
 2     35.521%      4.987/5.037/5.069/0.021        0.958/1.032/1.067/0.025       75,289,481
 3     33.882%      6.522/6.631/6.664/0.032        0.906/0.992/1.027/0.032       71,815,574
 4     33.175%      7.690/7.835/7.866/0.031        0.897/0.957/0.993/0.026       70,317,604
 5     32.661%      8.313/8.386/8.420/0.027        0.866/0.948/0.976/0.022       69,227,371
 6     32.507%   10.144/10.217/10.253/0.027        0.865/0.936/0.973/0.025       68,902,008
 7     32.255%   14.853/14.904/14.931/0.020        0.873/0.933/0.964/0.022       68,366,928
 8     32.167%   21.899/21.957/21.992/0.023        0.877/0.936/0.962/0.019       68,180,702
 9     31.887%   22.193/22.278/22.321/0.029        0.887/0.952/0.984/0.026       67,586,442

 avg1  40.848%                       10.021                          0.883
 avg2  45.386%                       11.134                          0.981
 tot                               6012.416                        529.747      865,799,882

Tested this on an odroid n2

Ugh, yet another intrinsic not supported until way too late with GCC.  I guess we can do a compiler check to see if this is supported and fall back to single loads?

Maybe just ifdef check for older GCC version?

Maybe just ifdef check for older GCC version?

Yeah I probably could but that might leave clang behind.  Given Apple's newest direction, we should probably generically detect this intrinsic pre-build.  Seems silly that we have to, but when gcc 9.3.x is too old I think it might be necessary.

Configure time check is what we have done before for most optional features... Benefit is that we don't have to do separate checks for gcc and clang as already mentioned. For some devices gcc 6.5 is still the latest usable version due to incompatibility issues in gcc 7.x series and later. For same reason Ubuntu 16.04 is latest usable version for some devices and 18.04 for others.

I'll probably get to this before too long, but it'll probably give us better resolution if I wait until after the benchmark PR goes through, since I can independently assess the functions that are doing this 64 byte load independently.

I plan to get back to this some time this weekend, but I rebased and ran the benchmarks.  It takes quite a few repetitions on my odroid-n2 to have a reasonable P value.  This seems to be the case in pretty much everything I optimized on this SBC, though, so that's nothing new.  There seems to be a consistent, ever so slight gain here:
Comparing slide_hash/neon (from ./benchmark_zlib) to slide_hash/neon (from ./benchmark_zlib_new)
Benchmark                                                            Time             CPU      Time Old      Time New       CPU Old       CPU New
-------------------------------------------------------------------------------------------------------------------------------------------------
[slide_hash/neon vs. slide_hash/neon]/1024                        -0.0219         -0.0215         20321         19876         20136         19704
[slide_hash/neon vs. slide_hash/neon]/1024                        -0.0275         -0.0296         20219         19663         20085         19490
[slide_hash/neon vs. slide_hash/neon]/1024                        -0.0199         -0.0182         20205         19803         20001         19637
[slide_hash/neon vs. slide_hash/neon]/1024                        -0.0570         -0.0544         20382         19220         20194         19095
[slide_hash/neon vs. slide_hash/neon]/1024                        -0.0051         -0.0060         19792         19692         19637         19519
[slide_hash/neon vs. slide_hash/neon]/1024                        -0.0509         -0.0491         20502         19458         20293         19296
[slide_hash/neon vs. slide_hash/neon]/1024                        -0.0275         -0.0232         20546         19981         20337         19865
[slide_hash/neon vs. slide_hash/neon]/1024                        -0.0072         -0.0070         19999         19856         19819         19680
[slide_hash/neon vs. slide_hash/neon]/1024                        -0.0459         -0.0467         20183         19257         20041         19105
[slide_hash/neon vs. slide_hash/neon]/1024                        -0.0401         -0.0365         20442         19622         20254         19515
[slide_hash/neon vs. slide_hash/neon]/1024                        +0.0085         +0.0100         20917         21095         20707         20914
[slide_hash/neon vs. slide_hash/neon]/1024                        -0.0167         -0.0173         20039         19705         19878         19533
[slide_hash/neon vs. slide_hash/neon]/1024                        -0.0245         -0.0246         20283         19786         20118         19622
[slide_hash/neon vs. slide_hash/neon]/1024                        -0.0029         -0.0011         20226         20167         20024         20002
[slide_hash/neon vs. slide_hash/neon]/1024                        -0.0340         -0.0331         20297         19606         20098         19433
[slide_hash/neon vs. slide_hash/neon]/1024_pvalue                  0.0002          0.0003      U Test, Repetitions: 15 vs 15
[slide_hash/neon vs. slide_hash/neon]/1024_mean                   -0.0249         -0.0239         20290         19786         20108         19627
[slide_hash/neon vs. slide_hash/neon]/1024_median                 -0.0285         -0.0281         20283         19705         20098         19533
[slide_hash/neon vs. slide_hash/neon]/1024_stddev                 +0.6795         +0.7483           262           440           247           433
[slide_hash/neon vs. slide_hash/neon]/2048                        -0.0212         -0.0210         20372         19940         20181         19756
[slide_hash/neon vs. slide_hash/neon]/2048                        -0.0197         -0.0194         20255         19856         20074         19685
[slide_hash/neon vs. slide_hash/neon]/2048                        -0.0534         -0.0483         20598         19498         20356         19372
[slide_hash/neon vs. slide_hash/neon]/2048                        -0.0247         -0.0231         20628         20119         20421         19949
[slide_hash/neon vs. slide_hash/neon]/2048                        -0.0105         -0.0093         20301         20088         20113         19927
[slide_hash/neon vs. slide_hash/neon]/2048                        -0.0325         -0.0334         20742         20067         20592         19904
[slide_hash/neon vs. slide_hash/neon]/2048                        -0.0446         -0.0417         20386         19477         20183         19342
[slide_hash/neon vs. slide_hash/neon]/2048                        -0.0507         -0.0497         20949         19886         20743         19712
[slide_hash/neon vs. slide_hash/neon]/2048                        -0.0250         -0.0263         20669         20153         20509         19969
[slide_hash/neon vs. slide_hash/neon]/2048                        -0.0364         -0.0370         20788         20032         20599         19836
[slide_hash/neon vs. slide_hash/neon]/2048                        -0.0102         -0.0072         20463         20254         20259         20114
[slide_hash/neon vs. slide_hash/neon]/2048                        -0.0077         -0.0086         20444         20286         20261         20087
[slide_hash/neon vs. slide_hash/neon]/2048                        -0.0100         -0.0116         20379         20176         20225         19991
[slide_hash/neon vs. slide_hash/neon]/2048                        -0.0218         -0.0214         20589         20140         20402         19966
[slide_hash/neon vs. slide_hash/neon]/2048                        -0.0236         -0.0202         20618         20131         20403         19991
[slide_hash/neon vs. slide_hash/neon]/2048_pvalue                  0.0000          0.0000      U Test, Repetitions: 15 vs 15
[slide_hash/neon vs. slide_hash/neon]/2048_mean                   -0.0262         -0.0253         20545         20007         20355         19840
[slide_hash/neon vs. slide_hash/neon]/2048_median                 -0.0243         -0.0211         20589         20088         20356         19927
[slide_hash/neon vs. slide_hash/neon]/2048_stddev                 +0.2410         +0.1907           196           243           195           232
[slide_hash/neon vs. slide_hash/neon]/4096                        -0.0346         -0.0307         20911         20187         20687         20052
[slide_hash/neon vs. slide_hash/neon]/4096                        -0.0336         -0.0353         21404         20685         21213         20463
[slide_hash/neon vs. slide_hash/neon]/4096                        -0.0342         -0.0351         20931         20214         20766         20037
[slide_hash/neon vs. slide_hash/neon]/4096                        -0.0637         -0.0604         21349         19988         21122         19845
[slide_hash/neon vs. slide_hash/neon]/4096                        -0.0374         -0.0384         20953         20170         20765         19968
[slide_hash/neon vs. slide_hash/neon]/4096                        -0.0388         -0.0395         21015         20199         20827         20005
[slide_hash/neon vs. slide_hash/neon]/4096                        -0.0404         -0.0371         20983         20136         20768         19997
[slide_hash/neon vs. slide_hash/neon]/4096                        -0.0530         -0.0538         21379         20246         21175         20036
[slide_hash/neon vs. slide_hash/neon]/4096                        -0.0495         -0.0493         21459         20398         21249         20201
[slide_hash/neon vs. slide_hash/neon]/4096                        -0.0410         -0.0426         20948         20090         20798         19913
[slide_hash/neon vs. slide_hash/neon]/4096                        -0.0515         -0.0485         20963         19882         20739         19734
[slide_hash/neon vs. slide_hash/neon]/4096                        -0.0379         -0.0377         21272         20466         21071         20276
[slide_hash/neon vs. slide_hash/neon]/4096                        -0.0300         -0.0297         20961         20332         20760         20143
[slide_hash/neon vs. slide_hash/neon]/4096                        -0.0559         -0.0555         21392         20195         21222         20044
[slide_hash/neon vs. slide_hash/neon]/4096                        -0.0478         -0.0488         21456         20430         21261         20224
[slide_hash/neon vs. slide_hash/neon]/4096_pvalue                  0.0000          0.0000      U Test, Repetitions: 15 vs 15
[slide_hash/neon vs. slide_hash/neon]/4096_mean                   -0.0433         -0.0429         21158         20241         20961         20062
[slide_hash/neon vs. slide_hash/neon]/4096_median                 -0.0388         -0.0379         21015         20199         20827         20037
[slide_hash/neon vs. slide_hash/neon]/4096_stddev                 -0.1207         -0.2011           227           199           225           180
[slide_hash/neon vs. slide_hash/neon]/8192                        -0.0269         -0.0264         22174         21576         21929         21351
[slide_hash/neon vs. slide_hash/neon]/8192                        -0.0346         -0.0327         22302         21530         22053         21333
[slide_hash/neon vs. slide_hash/neon]/8192                        -0.0380         -0.0374         22310         21462         22137         21308
[slide_hash/neon vs. slide_hash/neon]/8192                        -0.0117         -0.0114         22236         21976         22007         21756
[slide_hash/neon vs. slide_hash/neon]/8192                        -0.0516         -0.0490         22667         21498         22397         21299
[slide_hash/neon vs. slide_hash/neon]/8192                        -0.0631         -0.0599         22716         21283         22497         21149
[slide_hash/neon vs. slide_hash/neon]/8192                        -0.0111         -0.0123         22136         21890         21965         21694
[slide_hash/neon vs. slide_hash/neon]/8192                        -0.0376         -0.0375         22645         21794         22418         21577
[slide_hash/neon vs. slide_hash/neon]/8192                        -0.0470         -0.0468         22445         21390         22233         21193
[slide_hash/neon vs. slide_hash/neon]/8192                        -0.0182         -0.0177         22565         22155         22380         21983
[slide_hash/neon vs. slide_hash/neon]/8192                        -0.0106         -0.0089         21970         21736         21730         21536
[slide_hash/neon vs. slide_hash/neon]/8192                        -0.0622         -0.0615         22805         21387         22579         21190
[slide_hash/neon vs. slide_hash/neon]/8192                        -0.0216         -0.0202         22278         21798         22091         21644
[slide_hash/neon vs. slide_hash/neon]/8192                        -0.0342         -0.0324         22385         21619         22132         21415
[slide_hash/neon vs. slide_hash/neon]/8192                        -0.0453         -0.0445         22319         21309         22093         21110
[slide_hash/neon vs. slide_hash/neon]/8192_pvalue                  0.0000          0.0000      U Test, Repetitions: 15 vs 15
[slide_hash/neon vs. slide_hash/neon]/8192_mean                   -0.0344         -0.0334         22397         21627         22176         21436
[slide_hash/neon vs. slide_hash/neon]/8192_median                 -0.0333         -0.0353         22319         21576         22132         21351
[slide_hash/neon vs. slide_hash/neon]/8192_stddev                 +0.0790         +0.0746           239           257           237           254
[slide_hash/neon vs. slide_hash/neon]/16384                       -0.0242         -0.0205         25175         24566         24862         24353
[slide_hash/neon vs. slide_hash/neon]/16384                       -0.0292         -0.0264         24463         23748         24236         23596
[slide_hash/neon vs. slide_hash/neon]/16384                       -0.0370         -0.0363         24894         23973         24696         23799
[slide_hash/neon vs. slide_hash/neon]/16384                       -0.0280         -0.0260         25086         24383         24809         24165
[slide_hash/neon vs. slide_hash/neon]/16384                       -0.0238         -0.0190         24950         24356         24682         24214
[slide_hash/neon vs. slide_hash/neon]/16384                       -0.0384         -0.0401         25163         24198         24963         23963
[slide_hash/neon vs. slide_hash/neon]/16384                       -0.0018         +0.0005         24631         24588         24349         24361
[slide_hash/neon vs. slide_hash/neon]/16384                       -0.0430         -0.0416         25180         24097         24927         23891
[slide_hash/neon vs. slide_hash/neon]/16384                       -0.0513         -0.0479         24986         23703         24714         23530
[slide_hash/neon vs. slide_hash/neon]/16384                       -0.0049         -0.0068         24485         24365         24299         24134
[slide_hash/neon vs. slide_hash/neon]/16384                       -0.0093         -0.0060         25163         24929         24871         24722
[slide_hash/neon vs. slide_hash/neon]/16384                       -0.0342         -0.0305         25057         24201         24783         24027
[slide_hash/neon vs. slide_hash/neon]/16384                       -0.0087         -0.0085         24547         24334         24329         24121
[slide_hash/neon vs. slide_hash/neon]/16384                       -0.0208         -0.0194         24999         24478         24738         24258
[slide_hash/neon vs. slide_hash/neon]/16384                       -0.0019         +0.0009         24737         24690         24450         24472
[slide_hash/neon vs. slide_hash/neon]/16384_pvalue                 0.0001          0.0002      U Test, Repetitions: 15 vs 15
[slide_hash/neon vs. slide_hash/neon]/16384_mean                  -0.0238         -0.0219         24901         24307         24647         24107
[slide_hash/neon vs. slide_hash/neon]/16384_median                -0.0252         -0.0234         24986         24356         24714         24134
[slide_hash/neon vs. slide_hash/neon]/16384_stddev                +0.2832         +0.2967           262           336           247           320
[slide_hash/neon vs. slide_hash/neon]/32768                       -0.0447         -0.0434         30004         28663         29694         28403
[slide_hash/neon vs. slide_hash/neon]/32768                       -0.0280         -0.0265         29730         28897         29485         28704
[slide_hash/neon vs. slide_hash/neon]/32768                       -0.0395         -0.0372         30369         29169         30023         28906
[slide_hash/neon vs. slide_hash/neon]/32768                       +0.0074         +0.0108         30030         30251         29645         29966
[slide_hash/neon vs. slide_hash/neon]/32768                       +0.0068         +0.0078         29966         30170         29700         29932
[slide_hash/neon vs. slide_hash/neon]/32768                       -0.0413         -0.0402         30156         28911         29838         28638
[slide_hash/neon vs. slide_hash/neon]/32768                       +0.0110         +0.0094         29781         30109         29548         29826
[slide_hash/neon vs. slide_hash/neon]/32768                       -0.0403         -0.0388         30802         29562         30426         29244
[slide_hash/neon vs. slide_hash/neon]/32768                       -0.0327         -0.0302         30694         29689         30382         29466
[slide_hash/neon vs. slide_hash/neon]/32768                       -0.0053         -0.0067         29909         29752         29675         29476
[slide_hash/neon vs. slide_hash/neon]/32768                       -0.0126         -0.0119         30287         29904         29948         29590
[slide_hash/neon vs. slide_hash/neon]/32768                       -0.0083         -0.0093         29690         29444         29442         29168
[slide_hash/neon vs. slide_hash/neon]/32768                       -0.0317         -0.0283         29765         28821         29438         28606
[slide_hash/neon vs. slide_hash/neon]/32768                       -0.0154         -0.0156         30202         29737         29913         29448
[slide_hash/neon vs. slide_hash/neon]/32768                       +0.0067         +0.0066         29487         29685         29210         29402
[slide_hash/neon vs. slide_hash/neon]/32768_pvalue                 0.0048          0.0079      U Test, Repetitions: 15 vs 15
[slide_hash/neon vs. slide_hash/neon]/32768_mean                  -0.0180         -0.0170         30058         29518         29758         29252
[slide_hash/neon vs. slide_hash/neon]/32768_median                -0.0107         -0.0098         30004         29685         29694         29402
[slide_hash/neon vs. slide_hash/neon]/32768_stddev                +0.3977         +0.4720           369           515           340           501
OVERALL_GEOMEAN                                                   -0.0285         -0.0275             0             0             0             0

I think that should work?  We'll see what CI says.  The main issue is that I'm not 100% sure that the 4 register variant of ld1 is supported outside of aarch64, but I suspect that the compiler will still emulate the neon data structures and type definitions when dealing with 4xwide types.

Oh fun stuff - the types aren't defined, either.  Ugh...well, I guess I'll emulate them in lieu of a great way to do this even with assembly (the compiler needs cooperation because it requires participation from the register allocator).  I suppose with the proper extended asm it could be done (using the right keywords and mnemonics that it mapped args directly to registers) but I don't want to do it for MSVC.

Apparently we just bypass any sort of configure / cmake for the nmake CI?  It seems that MSVC supports these intrinsics (at least for the versions being used here), so maybe this isn't a huge deal.  Their arm support hasn't even existed all that long, so maybe they've even always had them?

Aaaand gcc 9 has the type definition for uint16x8x4 but not the load and store functions.  Ugh, compilers really can be a complicated mess.

The clang debug failure (on x86) is not a result of this commit but one of undefined behavior for the upper 3/4's of a zmm register when aliased from an XMM register. This should be fixed after rebasing against my pull request for avx512 improvements.

Just rebased.  It seems there are waaay fewer CI's being launched.  Did something change?

CI looks good to me, maybe it got fixed after you pushed more commits.
Btw, if you rebase now, you'll get the fix for the pigz nothreads CI failure as well.
I only did a very cursory review of this today, and it looks a lot better now. I'd prefer it if you squashed the commits though, since there isn't really any benefit to keeping them separate.

That's all I got. Nice work so far.

Could you perhaps mention Neon in the first line of the commit message? That makes it easier to identify what the commit touches.
I want to do a benchmark of this before merging

Could you perhaps mention Neon in the first line of the commit message? That makes it easier to identify what the commit touches.
I want to do a benchmark of this before merging

Done.  I suggest doing the slide_hash/neon benchmark before and after the commit.  On my SBC at least, I had to do several benchmark repetitions for it to not fail the null test with a highish P value (there was a lot of variance).  It was a consistent performance win though, and it definitely moves the mean lower.  It's not a huge gain because the disparate loads were overlapping some on my A72's pipeline, but the latency wasn't entirely folded like it was with the 4 register variant that loads to a sequential range.
You also need a compiler that supports vld1_u16_x4 or it will just fall back to using 4 disparate loads.  For me, this required gcc 10.

@Dead2 Just curious, what hardware did you plan on benchmarking this on?

RPI 3, aarch64, GCC 10
Baseline 88f331e6a64653b533721a645f8253b78e7f391a
 Tool: minigzip   Levels: 0-9
 Runs: 32         Trim worst: 18

 Level   Comp   Comptime min/avg/max/stddev  Decomptime min/avg/max/stddev  Compressed size
 0    100.008%      0.008/0.015/0.020/0.003        0.016/0.034/0.044/0.008       15,737,543
 1     54.165%      0.535/0.548/0.555/0.007        0.188/0.201/0.208/0.006        8,523,602
 2     43.877%      0.904/0.921/0.936/0.010        0.184/0.199/0.210/0.008        6,904,649
 3     42.389%      1.202/1.225/1.241/0.011        0.166/0.194/0.205/0.011        6,670,476
 4     41.647%      1.358/1.372/1.380/0.007        0.168/0.187/0.197/0.009        6,553,763
 5     41.217%      1.474/1.498/1.517/0.016        0.181/0.190/0.199/0.007        6,485,981
 6     41.037%      1.740/1.757/1.765/0.008        0.172/0.187/0.195/0.008        6,457,780
 7     40.778%      2.405/2.417/2.427/0.007        0.167/0.176/0.187/0.007        6,416,924
 8     40.704%      2.938/2.949/2.955/0.005        0.168/0.181/0.194/0.007        6,405,244
 9     40.409%      3.302/3.328/3.341/0.011        0.178/0.193/0.200/0.007        6,358,951

 avg1  48.623%                        1.603                          0.174
 avg2  54.026%                        1.781                          0.194
 tot                                224.415                         24.390       76,514,913

   text    data     bss     dec     hex filename
 116566    1664      16  118246   1cde6 libz-ng.so.2

PR #1074 9e45f15cd7d3ff7bd734ceb205ff7d514d4a5182
 Tool: minigzip   Levels: 0-9
 Runs: 32         Trim worst: 18

 Level   Comp   Comptime min/avg/max/stddev  Decomptime min/avg/max/stddev  Compressed size
 0    100.008%      0.008/0.016/0.020/0.004        0.024/0.038/0.044/0.006       15,737,543
 1     54.165%      0.533/0.542/0.548/0.005        0.191/0.203/0.210/0.005        8,523,602
 2     43.877%      0.900/0.925/0.933/0.009        0.187/0.200/0.210/0.008        6,904,649
 3     42.389%      1.199/1.222/1.237/0.013        0.177/0.197/0.207/0.007        6,670,476
 4     41.647%      1.356/1.376/1.386/0.009        0.178/0.190/0.199/0.006        6,553,763
 5     41.217%      1.492/1.504/1.516/0.007        0.178/0.192/0.201/0.007        6,485,981
 6     41.037%      1.741/1.757/1.767/0.009        0.164/0.184/0.192/0.007        6,457,780
 7     40.778%      2.405/2.419/2.435/0.009        0.164/0.175/0.184/0.005        6,416,924
 8     40.704%      2.943/2.950/2.956/0.004        0.164/0.177/0.191/0.008        6,405,244
 9     40.409%      3.297/3.321/3.331/0.009        0.174/0.186/0.200/0.009        6,358,951

 avg1  48.623%                        1.603                          0.174
 avg2  54.026%                        1.781                          0.193
 tot                                224.467                         24.379       76,514,913

 Level   Comp   Comptime min/avg/max/stddev  Decomptime min/avg/max/stddev  Compressed size
 0    100.008%      0.008/0.017/0.020/0.004        0.016/0.034/0.040/0.007       15,737,543
 1     54.165%      0.528/0.542/0.550/0.007        0.190/0.204/0.212/0.006        8,523,602
 2     43.877%      0.902/0.918/0.932/0.009        0.184/0.198/0.206/0.007        6,904,649
 3     42.389%      1.210/1.231/1.239/0.008        0.189/0.197/0.204/0.005        6,670,476
 4     41.647%      1.355/1.374/1.385/0.009        0.174/0.191/0.200/0.007        6,553,763
 5     41.217%      1.489/1.508/1.522/0.010        0.175/0.187/0.193/0.005        6,485,981
 6     41.037%      1.753/1.759/1.765/0.004        0.163/0.182/0.193/0.009        6,457,780
 7     40.778%      2.397/2.416/2.425/0.007        0.164/0.179/0.189/0.006        6,416,924
 8     40.704%      2.940/2.950/2.960/0.006        0.161/0.175/0.188/0.008        6,405,244
 9     40.409%      3.317/3.327/3.341/0.009        0.183/0.195/0.203/0.006        6,358,951

 avg1  48.623%                        1.604                          0.174
 avg2  54.026%                        1.783                          0.193
 tot                                224.600                         24.367       76,514,913

   text    data     bss     dec     hex filename
 116590    1664      16  118270   1cdfe libz-ng.so.2

RPI 1B, arm6l, GCC 8.3
Fails to compile with this PR
[  3%] Building C object CMakeFiles/zlib.dir/compare256.c.o
/usr/lib/ccache/cc -DARM_ASM_HWCAP -DARM_AUXV_HAS_CRC32 -DARM_AUXV_HAS_NEON -DARM_FEATURES -DARM_NEON_ADLER32 -DARM_NEON_CHUNKSET -DARM_NEON_SLIDEHASH -DHAVE_BUILTIN_CTZ -DHAVE_BUILTIN_CTZLL -DHAVE_POSIX_MEMALIGN -DHAVE_VISIBILITY_HIDDEN -DHAVE_VISIBILITY_INTERNAL -DWITH_GZFILEOP -DZLIB_DLL -D_LARGEFILE64_SOURCE=1 -D__USE_LARGEFILE64 -I/root/github/zlib-ng  -Wall -Wpedantic -falign-functions=64 -O2 -DNDEBUG -fPIC   -fno-semantic-interposition -mfloat-abi=hard -Wall -Wextra -Wpedantic -Wno-implicit-fallthrough -std=c11 -o CMakeFiles/zlib.dir/compare256.c.o   -c /root/github/zlib-ng/compare256.c
In file included from /root/github/zlib-ng/compare256.c:7:
/root/github/zlib-ng/fallback_builtins.h:91:16: error: redefinition of ‘struct uint16x8x4_t’
 typedef struct uint16x8x4_t {
                ^~~~~~~~~~~~
In file included from /root/github/zlib-ng/fallback_builtins.h:84,
                 from /root/github/zlib-ng/compare256.c:7:
/usr/lib/gcc/arm-linux-gnueabihf/8/include/arm_neon.h:429:16: note: originally defined here
 typedef struct uint16x8x4_t
                ^~~~~~~~~~~~
In file included from /root/github/zlib-ng/compare256.c:7:
/root/github/zlib-ng/fallback_builtins.h:93:3: error: conflicting types for ‘uint16x8x4_t’
 } uint16x8x4_t;
   ^~~~~~~~~~~~
In file included from /root/github/zlib-ng/fallback_builtins.h:84,
                 from /root/github/zlib-ng/compare256.c:7:
/usr/lib/gcc/arm-linux-gnueabihf/8/include/arm_neon.h:432:3: note: previous declaration of ‘uint16x8x4_t’ was here
 } uint16x8x4_t;
   ^~~~~~~~~~~~
make[2]: *** [CMakeFiles/zlib.dir/build.make:92: CMakeFiles/zlib.dir/compare256.c.o] Error 1

-- Using CMake version 3.16.3
-- ZLIB_HEADER_VERSION: 1.2.11
-- ZLIBNG_HEADER_VERSION: 2.1.0.devel
-- The C compiler identification is GNU 8.3.0
-- Check for working C compiler: /usr/lib/ccache/cc
-- Check for working C compiler: /usr/lib/ccache/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Arch detected: 'armv6'
-- Basearch of 'armv6' has been detected as: 'arm'
-- Performing Test HAVE_FLOATABI_SOFTFP
-- Performing Test HAVE_FLOATABI_SOFTFP - Failed
-- Performing Test HAVE_FLOATABI_HARD
-- Performing Test HAVE_FLOATABI_HARD - Success
-- ARM floating point arch: -mfloat-abi=hard
-- Performing Test FNO_LTO_AVAILABLE
-- Performing Test FNO_LTO_AVAILABLE - Success
-- Looking for sys/sdt.h
-- Looking for sys/sdt.h - not found
-- Looking for unistd.h
-- Looking for unistd.h - found
-- Looking for sys/types.h
-- Looking for sys/types.h - found
-- Looking for stdint.h
-- Looking for stdint.h - found
-- Looking for stddef.h
-- Looking for stddef.h - found
-- Check size of off64_t
-- Check size of off64_t - done
-- Looking for fseeko
-- Looking for fseeko - found
-- Looking for strerror
-- Looking for strerror - found
-- Looking for posix_memalign
-- Looking for posix_memalign - found
-- Performing Test HAVE_NO_INTERPOSITION
-- Performing Test HAVE_NO_INTERPOSITION - Success
-- Performing Test HAVE_ATTRIBUTE_VISIBILITY_HIDDEN
-- Performing Test HAVE_ATTRIBUTE_VISIBILITY_HIDDEN - Success
-- Performing Test HAVE_ATTRIBUTE_VISIBILITY_INTERNAL
-- Performing Test HAVE_ATTRIBUTE_VISIBILITY_INTERNAL - Success
-- Performing Test HAVE_BUILTIN_CTZ
-- Performing Test HAVE_BUILTIN_CTZ - Success
-- Performing Test HAVE_BUILTIN_CTZLL
-- Performing Test HAVE_BUILTIN_CTZLL - Success
-- Performing Test HAVE_PTRDIFF_T
-- Performing Test HAVE_PTRDIFF_T - Success
-- Performing Test ARM_AUXV_HAS_CRC32
-- Performing Test ARM_AUXV_HAS_CRC32 - Failed
-- Performing Test ARM_HWCAP_HAS_CRC32
-- Performing Test ARM_HWCAP_HAS_CRC32 - Success
-- Performing Test ARM_AUXV_HAS_NEON
-- Performing Test ARM_AUXV_HAS_NEON - Success
-- Performing Test MFPU_NEON_AVAILABLE
-- Performing Test MFPU_NEON_AVAILABLE - Success
-- Performing Test NEON_HAS_LD4
-- Performing Test NEON_HAS_LD4 - Failed
-- Architecture-specific source files: arch/arm/armfeature.c;arch/arm/adler32_neon.c;arch/arm/chunkset_neon.c;arch/arm/slide_hash_neon.c
-- The following features have been enabled:

 * CMAKE_BUILD_TYPE, Build type: Release (default)
 * NEON_ADLER32, Support NEON instructions in adler32, using "-mfpu=neon"
 * NEON_SLIDEHASH, Support NEON instructions in slide_hash, using "-mfpu=neon"
 * WITH_GZFILEOP, Compile with support for gzFile related functions
 * ZLIB_ENABLE_TESTS, Build test binaries
 * WITH_SANITIZER, Enable sanitizer support
 * WITH_OPTIM, Build with optimisation
 * WITH_NEW_STRATEGIES, Use new strategies
 * WITH_MAINTAINER_WARNINGS, Build with project maintainer warnings
 * WITH_NEON, Build with NEON intrinsics

-- The following features have been disabled:

 * ZLIB_SYMBOL_PREFIX, Publicly exported symbols DO NOT have a custom prefix
 * ZLIB_COMPAT, Compile with zlib compatible API
 * ZLIB_DUAL_LINK, Dual link tests against system zlib
 * WITH_FUZZERS, Build test/fuzz
 * WITH_BENCHMARKS, Build test/benchmarks
 * WITH_NATIVE_INSTRUCTIONS, Instruct the compiler to use the full instruction set on this host (gcc/clang -march=native)
 * WITH_CODE_COVERAGE, Enable code coverage reporting
 * WITH_INFLATE_STRICT, Build with strict inflate distance checking
 * WITH_INFLATE_ALLOW_INVALID_DIST, Build with zero fill for inflate invalid distances
 * WITH_UNALIGNED, Support unaligned reads on platforms that support it
 * WITH_UNALIGNED64, Support unaligned 64-bit reads on platforms that support it
 * WITH_ACLE, Build with ACLE
 * INSTALL_UTILS, Copy minigzip and minideflate during install

-- Configuring done
-- Generating done

Hmm, interesting, so GCC 8 also defines that type.  I wonder how far back we need to go before it doesn't.

@Dead2 So I found that typedef definition as far back as GCC4.  I think they were always there, but more for transposing loads.  This obviously does a straight load in memory order.  Go ahead and try to compile now.
A note: you will not see this benefit at all on GCC 8, you need 10 or newer, I don't know why GCC took years to expose this instruction as an intrinsic, it's been there from the beginning.  For compilers that can't emit this instruction, our intrinsic simply emulates the behavior (the loads are put into the struct as though they were loaded with a single instruction).
So, if benchmarking, at least test it with 10 in addition to 8.  The inline assembly necessary to generate this intrinsic may not be very easily expressible to do it a better way (it requires a contiguous range of available registers and so it needs some cooperation from the register allocator).

RPI 3, aarch64, GCC 10
Baseline 88f331e
 Tool: minigzip   Levels: 0-9
 Runs: 32         Trim worst: 18

 Level   Comp   Comptime min/avg/max/stddev  Decomptime min/avg/max/stddev  Compressed size
 0    100.008%      0.008/0.015/0.020/0.003        0.016/0.034/0.044/0.008       15,737,543
 1     54.165%      0.535/0.548/0.555/0.007        0.188/0.201/0.208/0.006        8,523,602
 2     43.877%      0.904/0.921/0.936/0.010        0.184/0.199/0.210/0.008        6,904,649
 3     42.389%      1.202/1.225/1.241/0.011        0.166/0.194/0.205/0.011        6,670,476
 4     41.647%      1.358/1.372/1.380/0.007        0.168/0.187/0.197/0.009        6,553,763
 5     41.217%      1.474/1.498/1.517/0.016        0.181/0.190/0.199/0.007        6,485,981
 6     41.037%      1.740/1.757/1.765/0.008        0.172/0.187/0.195/0.008        6,457,780
 7     40.778%      2.405/2.417/2.427/0.007        0.167/0.176/0.187/0.007        6,416,924
 8     40.704%      2.938/2.949/2.955/0.005        0.168/0.181/0.194/0.007        6,405,244
 9     40.409%      3.302/3.328/3.341/0.011        0.178/0.193/0.200/0.007        6,358,951

 avg1  48.623%                        1.603                          0.174
 avg2  54.026%                        1.781                          0.194
 tot                                224.415                         24.390       76,514,913

   text    data     bss     dec     hex filename
 116566    1664      16  118246   1cde6 libz-ng.so.2

PR #1074 9e45f15
 Tool: minigzip   Levels: 0-9
 Runs: 32         Trim worst: 18

 Level   Comp   Comptime min/avg/max/stddev  Decomptime min/avg/max/stddev  Compressed size
 0    100.008%      0.008/0.016/0.020/0.004        0.024/0.038/0.044/0.006       15,737,543
 1     54.165%      0.533/0.542/0.548/0.005        0.191/0.203/0.210/0.005        8,523,602
 2     43.877%      0.900/0.925/0.933/0.009        0.187/0.200/0.210/0.008        6,904,649
 3     42.389%      1.199/1.222/1.237/0.013        0.177/0.197/0.207/0.007        6,670,476
 4     41.647%      1.356/1.376/1.386/0.009        0.178/0.190/0.199/0.006        6,553,763
 5     41.217%      1.492/1.504/1.516/0.007        0.178/0.192/0.201/0.007        6,485,981
 6     41.037%      1.741/1.757/1.767/0.009        0.164/0.184/0.192/0.007        6,457,780
 7     40.778%      2.405/2.419/2.435/0.009        0.164/0.175/0.184/0.005        6,416,924
 8     40.704%      2.943/2.950/2.956/0.004        0.164/0.177/0.191/0.008        6,405,244
 9     40.409%      3.297/3.321/3.331/0.009        0.174/0.186/0.200/0.009        6,358,951

 avg1  48.623%                        1.603                          0.174
 avg2  54.026%                        1.781                          0.193
 tot                                224.467                         24.379       76,514,913

 Level   Comp   Comptime min/avg/max/stddev  Decomptime min/avg/max/stddev  Compressed size
 0    100.008%      0.008/0.017/0.020/0.004        0.016/0.034/0.040/0.007       15,737,543
 1     54.165%      0.528/0.542/0.550/0.007        0.190/0.204/0.212/0.006        8,523,602
 2     43.877%      0.902/0.918/0.932/0.009        0.184/0.198/0.206/0.007        6,904,649
 3     42.389%      1.210/1.231/1.239/0.008        0.189/0.197/0.204/0.005        6,670,476
 4     41.647%      1.355/1.374/1.385/0.009        0.174/0.191/0.200/0.007        6,553,763
 5     41.217%      1.489/1.508/1.522/0.010        0.175/0.187/0.193/0.005        6,485,981
 6     41.037%      1.753/1.759/1.765/0.004        0.163/0.182/0.193/0.009        6,457,780
 7     40.778%      2.397/2.416/2.425/0.007        0.164/0.179/0.189/0.006        6,416,924
 8     40.704%      2.940/2.950/2.960/0.006        0.161/0.175/0.188/0.008        6,405,244
 9     40.409%      3.317/3.327/3.341/0.009        0.183/0.195/0.203/0.006        6,358,951

 avg1  48.623%                        1.604                          0.174
 avg2  54.026%                        1.783                          0.193
 tot                                224.600                         24.367       76,514,913

   text    data     bss     dec     hex filename
 116590    1664      16  118270   1cdfe libz-ng.so.2

Right, so the benefits are going to be hard to measure, especially given how small an impact it has over the overall process.  A better, more concentrated look would be to run the slide_hash benchmarks.
Try:
benchmark_zlib --benchmark_filter=slide_hash/neon  --benchmark_repetitions=20
Try that for both before and after the PR.  Google benchmark also has some python scripts that'll use scipy's prob & stats capabilities to given you a good idea of how much the distribution is moved and the probability of it being a NULL test, but it requires grabbing some python from their repos to get that.  It's what I'm running above with compare.py.

Just as important as measuring the speedup is checking for regressions, such as yesterdays bug.
Things looks good now though.

Heh, well, anything on the RPi1 was going to be noise or just alignment changes in code blocks because it doesn't even use this slide hash implementation.  But it's good we caught a compiler issue.


Ceylon implementation of Whole - for review and planning

For https://github.com/ceylon/ceylon-sdk/issues/306
I think this is in pretty good shape, and I’d like to start working towards a reasonable stopping point - either merging or releasing as a separate module on github or Herd.
A few items remain, that to some degree depend on the path forward:

Cleanup and improve tests. Remove test dependency on Random.
Test on JavaScript. I’ve done very little of this, although I think my testing with 16-bit words on the JVM has probably been a decent approximation.
Decide on LongArray or Array<Integer>, based on whether this is released for JS.
Final API decisions, such as naming for quotientAndRemainder, and a decision on satisfies Binary and rightLogicalShift.
Sanity checks on performance for bitwise operations, modPower, and modInverse.

I haven’t put a ton of thought into it, but I’m a bit cold on the idea of having Whole, Decimal, Long, etc., split into separate modules, for two main reasons: 1. performance and convenience benefits made possible by sharing of implementation details, and 2. allowing for API conveniences like Whole.long and Long.whole.
At this point, my preference is to merge into ceylon.math, but I certainly understand the rational for putting this off as well, since there would be little external benefit beyond the additional API methods (which could also easily be added to the existing BigInteger wrapper.)
Finally, I also have an implementation of Long for 64-bit signed integers on JavaScript. It is largely independent, but does use Whole for division. As discussed on the mailing list, I think this will be useful on its own for JavaScript, but to be really useful for cross platform development, it will need to be erased in some way to Integer/long on the JVM.

@jvasileff let's chat on IRC tomorrow?

Sure.
On Jan 7, 2015, at 7:16 PM, Gavin King <notifications<EMAIL_ADDRESS>wrote:
@jvasileffhttps://github.com/jvasileff let's chat on IRC tomorrow?
—
Reply to this email directly or view it on GitHubhttps://github.com/ceylon/ceylon-sdk/pull/336#issuecomment-69116467.

Closing as I've decided to package Whole and Long in a separate cross platform math module - https://github.com/jvasileff/ceylon-xmath.
That code can of course be copied/merged into the SDK whenever.

Yes, I think we had decided to do a split like this anyway, right?

Well, ultimately I think there are advantages to having the various number types be able to work with each other. And there may be additional considerations if there's interest in adding support for random number generators and utils. But yeah, at least for now, I'm not sure what other options are available that would support JS.
Regardless, I'm happy to apply any of this however you determine is best.


Bracket consume lot of cpu when open it

am using brackets 1.4 but since i move to 1.4 it consumes upto 80% of my cpu usage.
am on lenovo T420 intel i5 2.5 processor
my ram is 8gb with 360 ssd drive
my OS is debian jessie

Tagging @abose

Can you try debug>reload without extensions and see if that helps.
Also i have seen this issue in windows rarely, the browser processes takes up lots of cpu. Restarting usually fixed the problem for me.

after doing that brackets uses less than 5% of cpu. whats the posible cause?

It might be some extensions that is consuming lots of cpu. You could go into extension manager and disable each plugins utill you find the extension causing the problem. Please post back your findings for tracking this issue.

am able to narrow it down is the theme am using, will add issue to the theme developer but he doesnt allow post of issues.
the theme am using is delkos dark theme

Please raise the issue with the extension developer as that is not under brackets domain.
There are several alternative dark themes available. Check it out :+1:
Closing as extension issue.


Error: unknown service lnrpc.Lightning

I'm getting the following error while trying to run npm run dev while running lnd:
[0] error:  { Error: unknown service lnrpc.Lightning
[0]     at ClientReadableStream._emitStatusIfDone (/Users/zubin/open_source/zap-desktop/app/node_modules/grpc/src/client.js:255:19)
[0]     at ClientReadableStream._receiveStatus (/Users/zubin/open_source/zap-desktop/app/node_modules/grpc/src/client.js:233:8)
[0]     at /Users/zubin/open_source/zap-desktop/app/node_modules/grpc/src/client.js:705:12 code: 12, metadata: Metadata { _internal_repr: {} } }
[0] TRANSACTION STATUS:  { code: 12,
[0]   details: 'unknown service lnrpc.Lightning',
[0]   metadata: Metadata { _internal_repr: {} } }

May I know the OS?
Did you install grpc ?

@joaodealmeida this was fixed with the help of @janis in the slack channel.
I think I was running lnd wrong. I moved the binary to the resources folder and this fixed my problems. Going to close this issue now.
Looking forward to trying to help here!


Add more skills

Add a better skill set to the list

Add more skills to the list

CznI get assigned , tell me how to proceed ?


Source Detail page: Filtering by Century could be improved

I just got an email from Debra:
A suggestion has come in that I think will improve the use of the pull-down list for century for CantusDB sources.

I'm on this page:
https://cantusdatabase.org/sources/?segment=4063
Would it be possible to have "Century" just as: "9th century", "10th century", etc. up to "17th century" in the pull-down list, and then have 2 additional fields with this for one: "1st half", "2nd half", and then this for the next: "1st quarter", "2nd quarter", "3rd quarter," "4th quarter."
(no year dates are needed, then)
The pull-down lists will be shorter and easier to manage (see screenshot).
I know this changes the search programming, which you currently have matching all of the same century (I think) no matter which part of the century is selected. (So, this is already great, that it pulls up all sources of the same century even if some have a more detailed specification.)
Does this make it more streamlined or more difficult on the back end? For me, I can see it being more streamlined for the user, because I can specify the century if I know it, and then if I know which half I can choose that, and if I know even more I can continue to the quarter and specify that (or I can leave it blank at whatever point I am unsure).
But, if it splits up the data too much and you can't attach "1st half" because it's not 'century-specific' then I understand the difficulty. In my description, above, "1st half" would be in a separate pull-down and would be applied whenever the user wanted that, based on their selection of the "century" field - but there wouldn't be a different "1st half" option for each century --- instead, just one that would rely on the previous field for context.  If you know what I mean.
Also, there is a 9th and a 09th in the current list that should be cleaned up, regardless of what happens to this Century field(s).

This would be a nice thing to implement, and I can see how it would improve user experience.
This entails two main tasks:

[x] Merging all "9th Century" sources into the "09th Century" (update: the "9th Century" was actually "9th century (875-900)" - I renamed it to "09th century (875-900)", so we haven't lost any information on which quarter-century this Century object represented)
[ ] Adapting the Century model to allow filtering by half- and quarter-century, and update Source List page to implement this filtering.

We have options for the second of these points. I'll create a comment below this one and start recording some of the thoughts I have.

For the Century model:

If we wanted, we could not change the model at all, and we could just do this with pattern matching:

If someone wants sources from the second quarter of the 10th Century, we search for Centuries that contain 10th Century, intersection those that contain 25, intersection those that contain 50. If someone wants sources from the first half of the 11th Century, we search for Centuries that contain 11th Century, intersection those that end with 50
This solution depends on the names of all Centuries being entered correctly, and I foresee the code being a bit fiddly.

We could update the Century model

we could give it a century property (integer: 9, 10, 11, etc.), a quarter property (optional integer: 0-3 inclusive), and a half property (optional integer: 0-1).

If a person is searching for a particular quarter-century, we filter by century and by quarter, and similarly for half-centuries
this approach is probably simplest for the time being, but less elegant than the following approach because it involves adding 3 new properties to the Century model, rather than just 2.

we could give it a century property, and a quarters property (set or list: one or more of {0, 1, 2, 3}). A full century will have all four possible quarters; a half-century will have two of the possible quarters, and a quarter-century will have just one.

If a person searches for the third quarter of the 12th Century, we filter by century == 12, and then by those centuries where quarter not in {0,1,3}.
If a person searches for the second half of the 13th Century, we filter by century==13 and quarter not in {0, 1} (thus also catching sources from the first and second quarters of the 13th Century too)
This approach could also allow us to do similar matching on Source Detail pages in a simple way, by checking for other centuries whose quarters are a sub/superset of the current century's quarters: for the "14th Century" page, we could include sources from other centuries where century == 14, and provide links to child and parent centuries, allowing users to narrow/broaden the list of sources they see.

After additional discussion with Debra + Jennifer, the hope is to just remove the quarter century options... and have the half and full century options work as expected.


[FEAT] Add NocoDB support

Is your feature request related to a problem? Please describe.
Refine looks awesome, but I'd love to be able to connect it with NocoDB (open-source Airtable clone).
Describe alternatives you've considered
Migrating to Airtable, but we're already fairly invested into NocoDB.
Additional context
No response
Describe the thing to improve
Adding NocoDB as a data source.

Hey @SkyfallWasTaken thanks for the issue. Core team isn't adding new data provider integrations but we are open to contributions from the community.
You can check our tutorial on creating a data provider https://refine.dev/tutorial/essentials/data-fetching/intro/#creating-a-data-provider
Basically, you can swizzle the simple-rest data provider and modify it according to your needs. https://refine.dev/docs/data/packages/simple-rest/#customizing-the-data-provider-

Hey @erkanercan assigned issue to you. You can duplicate one of the data providers as a starting point and replace values in package.json, refine.config.js. The most recently updated one is graphql data provider.

We don't accept new data/auth provider integrations at the moment to this repository.
If you create an integration on your own repository and publish as a separate npm package, feel free to create a PR here. We'd be more than happy to feature integrations in our documentation and website.


Apotheosis - Bosses rarity will not change in the Overworld.

Hello!
I am running a private server and I am hoping you all can help! Currently in the Overworld, only uncommon, rare, and epic mob bosses are spawning. I went into the config file and changed the odds for Mythic to spawn(deadly config), and included Mythic as able to spawn in the overworld.
Any idea what I can do to get mythic to spawn?
I am including a screenshot of the relevant adventure config and deadly config.

Just to be clear, I am running 1.19.2 and forge 43.2.8

The config does not control boss rarities.  For those, you need to make a datapack which overrides the existing overworld boss entries to be able to spawn as epic+, and also provide stats for those rarities.


Ethereum optimism develop

Codecov Report

Merging #32 (a874eee) into develop (58e75b9) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff            @@
##           develop      #32   +/-   ##
========================================
  Coverage    80.55%   80.55%
========================================
  Files           49       49
  Lines         1934     1934
  Branches       311      311
========================================
  Hits          1558     1558
  Misses         376      376

Continue to review full report at Codecov.

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


lint: Clean up conditionals in misc UI components

As is generally the case for my PRs, since I don't really use the UI components outside raidboss, raidemulator, and oopsy, these changes should probably have extra scrutiny/testing.

@Echoring With regards to the other comments/concerns:

mpTicker - The removed false-y check was against const mpTicker = TimerBar.create() which always returns a valid object (TimerBar extends HTMLElement)
leftBuffDiv - The arguments to the constructor here are checked for valid values before being passed in, hence why the constructor's parameters aren't optional/nullable. See ui/jobs/components/index.ts:233.
Component - ComponentMap has all jobs defined and mapped to a valid component object, so the check for Component to be valid is redundant. Record<Job, typeof BaseComponent> requires that all jobs have an entry in the map.

This looks good to me.  @Echoring, @MaikoTan did y'all want to take another look at these changes?

Looks good to me. Thanks!

AggressionStatus is added in this PR, what's it's type?

As with most questions like this, the answer is upstream in OverlayPlugin.
https://github.com/OverlayPlugin/OverlayPlugin/blob/5416039b970a3ea986f7ed52c63d6f7084b8f899/OverlayPlugin.Core/MemoryProcessors/EnmityMemoryCommon.cs#L82-L96


PR-16294: Fix for selectize#1594, optgroup may be undefined while sorting

Merges in this commit: https://github.com/selectize/selectize.js/commit/e65e7ce01ef8c586fbffe1022161fb386a1b9ef6

cc @timvasil


Add BUILD_SHARED_LIBS support to OpenSSL 1.1+ Windows

Updated.

Testing:

https://ci.appveyor.com/project/ingenue/hunter/build/1.0.2730
https://travis-ci.org/ingenue/hunter/builds/300068201?utm_source=github_status&utm_medium=notification

Uploading:

https://ci.appveyor.com/project/ingenue/hunter/build/1.0.2733
https://travis-ci.org/ingenue/hunter/builds/300124728?utm_source=github_status&utm_medium=notification

Released: https://github.com/ruslo/hunter/releases/tag/v0.19.147


Feature request: Not being able to select and send other files while transfering other files

Is your feature request related to a problem? Please describe.
While transfering other files, it is not possible to select and add other files to the list or queue
Describe the solution you'd like
Adding a selef more buttom to the transfering page would be really nice
Describe alternatives you've considered
No response
Additional context
Using android 12 Samsung S10+

This is expected as the receiver explicitly only accepts the given files.
It is also unlikely to support this feature as the protocol does not support this.


go panic with plugin downloader

Today I saw that helm does support downloader plugins. -> https://helm.sh/docs/topics/plugins/#downloader-plugins
The documentation of helm described how it works together with charts.
Looking at source, downloader plugins should also able to work with value files, but they don't:
jkr@joe-nb helm-secrets % helm template test -f sops:///tests/assets/values/sops/secrets.yaml
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x8 pc=0x22a1867]

goroutine 1 [running]:
bytes.(*Buffer).Bytes(...)
        /usr/local/Cellar/go/1.15.2/libexec/src/bytes/buffer.go:54
helm.sh/helm/v3/pkg/cli/values.readFile(0xc000044840, 0x2d, 0xc00099a340, 0x2, 0x2, 0x3854108, 0x0, 0x1, 0xc00038e470, 0xc000493da0)
        /private/tmp/helm-20200923-64956-rldbbk/pkg/cli/values/options.go:120 +0x167
helm.sh/helm/v3/pkg/cli/values.(*Options).MergeValues(0xc0006b0a80, 0xc00099a340, 0x2, 0x2, 0x1, 0x1, 0x1)
        /private/tmp/helm-20200923-64956-rldbbk/pkg/cli/values/options.go:48 +0x115
main.runInstall(0xc0003a26c0, 0x1, 0x3, 0xc0002aa640, 0xc0006b0a80, 0x28942a0, 0xc000130008, 0xc00053da88, 0x11, 0x33cfbb8)
        /private/tmp/helm-20200923-64956-rldbbk/cmd/helm/install.go:192 +0x325
main.newTemplateCmd.func2(0xc0006a8dc0, 0xc0003a26c0, 0x1, 0x3, 0x0, 0x0)
        /private/tmp/helm-20200923-64956-rldbbk/cmd/helm/template.go:70 +0x12b
github.com/spf13/cobra.(*Command).execute(0xc0006a8dc0, 0xc0003a2690, 0x3, 0x3, 0xc0006a8dc0, 0xc0003a2690)
        /Users/brew/Library/Caches/Homebrew/go_mod_cache/pkg/mod/github.com/spf13/cobra@v1.0.0/command.go:842 +0x47c
github.com/spf13/cobra.(*Command).ExecuteC(0xc0002cf600, 0xc000130e90, 0x1, 0xc000939f60)
        /Users/brew/Library/Caches/Homebrew/go_mod_cache/pkg/mod/github.com/spf13/cobra@v1.0.0/command.go:950 +0x375
github.com/spf13/cobra.(*Command).Execute(...)
        /Users/brew/Library/Caches/Homebrew/go_mod_cache/pkg/mod/github.com/spf13/cobra@v1.0.0/command.go:887
main.main()
        /private/tmp/helm-20200923-64956-rldbbk/cmd/helm/helm.go:93 +0x24d

Note: Chart doesn't matter. In this case, I create test via helm create test.
Plugin Code:
https://github.com/jkroepke/helm-secrets/tree/downloader (Branch: downloader)
Source Code: https://github.com/helm/helm/blob/9b42702a4bced339ff424a78ad68dd6be6e1a80a/pkg/cli/values/options.go#L107-L121
I would like to use this to hook into reading value files without creating a whole wrapper for the helm command.
Output of helm version:
helm version
version.BuildInfo{Version:"v3.3.4", GitCommit:"a61ce5633af99708171414353ed49547cf05013d", GitTreeState:"dirty", GoVersion:"go1.15.2"}

There is a bug here because there should not be a panic if there is an issue working with the downloader.
The reason for the panic is because of an error in the plugin. There are two issues right now...

In the plugin.yaml the section on downloaders should be...

downloaders:
  - command: "scripts/downloader.sh"
    protocols:
      - "sops"
      - "secret"

The wrong location was causing an underlying error of:
fork/exec /path/to/helm/plugins/helm-secrets/$scripts/downloader.sh: no such file or directory

downloader.sh isn't working. Not for the passed in location.

Thanks for figure out my bugs. that helps a lot. I couldn't see them since helm just panic here. I guess report a panic is always valid.
Like you said, this issue is just about the panic.

HELM_PLUGIN_DIR should be available for install hooks. https://github.com/helm/helm/blob/82f739072cb3c94f26e3103e4524a1f74526342d/cmd/helm/plugin.go#L63

If you find an issue, PRs and bugfixes with test cases are always welcome.

this line may be causing the issue where plugin settings are not being passed to the downloader plugin.
https://github.com/helm/helm/blob/9b42702a4bced339ff424a78ad68dd6be6e1a80a/pkg/getter/plugingetter.go#L73-L74
Feel free to write a unit test surrounding pluginGetter.Get() to verify this issue.

Right now everything works fine in my enviroment except the plugin raises an error. Then helm will panic as initial described.

Is anyone already following up? If not, I am willing to fix

nope, feel free

Unstale

Unstale


Why num_class is 3?

masked
unmasked
background
is it right?
thank you!

background, masked, unmasked is right.


"ArgumentError: uncaught throw :breakout_nav" when trying to up

Here is an example where this is failing.
#Gemfile
source "https://rubygems.org"

gem 'pry'
gem 'pry-byebug'
gem 'pry-rescue'
gem 'pry-stack_explorer'

#code
def make_fail
  raise "an error"
  puts "boo"
end

make_fail

puts "yay"

When I run bundle exec rescue test.rb and try to run up to get up the stack, and I get:
ArgumentError: uncaught throw :breakout_nav from /home/WilliamSnyders/.rbenv/versions/2.1.5/lib/ruby/gems/2.1.0/gems/pry-byebug-3.1.0/lib/pry/commands/frames.rb:73:in 'throw'
I've had some issues tracking this down, cause pry warn's on the error somewhere and I can't seem to get the full stacktrace for it (probably didn't try hard enough). Though I do think I might see why this is happening.
For whatever reason, pry is getting called here with a hash:
# from ->  pry-rescue/lib/pry-rescue.rb
...
    def enter_exception_context(exception)
      ...
        if defined?(PryStackExplorer)
          pry :call_stack => bindings,
              :hooks => pry_hooks(exception),
              :initial_frame => initial_frame(bindings)
        else
          ...

https://github.com/ConradIrwin/pry-rescue/blob/master/lib/pry-rescue.rb#L58
Calling with the hash will call Pry with PryRescue instead of the binding of where the rescue happened
# from  ->   pry/lib/pry/core_extensions.rb
  def pry(object=nil, hash={})
    if object.nil? || Hash === object
      Pry.start(self, object || {})
    else
      Pry.start(object, hash)
    end
  end

https://github.com/pry/pry/blob/master/lib/pry/core_extensions.rb#L41-L47
And doing that means that pry-byebug thinks it should not involved (only wants to work with Bindings)
# from ->   pry-byebug/lib/pry-byebug/pry_ext.rb
class << Pry
  alias_method :start_without_pry_byebug, :start
  attr_reader :processor

  def start_with_pry_byebug(target = TOPLEVEL_BINDING, options = {})
    @processor ||= Byebug::PryProcessor.new

    if target.is_a?(Binding) && PryByebug.file_context?(target)
      # Wrap processor around the usual Pry.start to catch navigation commands
      @processor.start
    else
      # No need for the tracer unless we have a file context to step through
      start_without_pry_byebug(target, options)
    end
  end
  alias_method :start, :start_with_pry_byebug
end

https://github.com/deivid-rodriguez/pry-byebug/blob/master/lib/pry-byebug/pry_ext.rb#L7-L17
Which means we miss out on all the goodies of pry-byebug (like the catch for the :breakout_nav https://github.com/deivid-rodriguez/pry-byebug/blob/master/lib/byebug/processors/pry_processor.rb#L41)
Not sure why it was done this way, so didn't try to fix it myself.
May be causing/related to deivid-rodriguez/pry-byebug#2

Sorry, this actually seems to be a compatability thing with pry-byebug and pry-stack_explorer

This started with deivid-rodriguez/pry-byebug#55. pry-byebug now wants to handle moving around the frames now, but pry-rescue tries to go around pry-byebug. This could be solved by calling pry like below instead so pry-byebug knows to pick this up
pry bindings[initial_frame(bindings)],
    :call_stack => bindings,
    :hooks => pry_hooks(exception),
    :initial_frame => initial_frame(bindings)


Fix rust lint

A new update of rustfmt broke the rust lint tests.
This PR:

Updates bin/run_lint_rust and bin/run_lint_validator to correctly run rustfmt
Fix all new lint errors

Do we know why this wasn't being linted previously?

It seems that rustfmt is not working? It's breaking the rust lint tests.
I'm getting this error:  Unrecognized option: 'write-mode' . (there's a build in Jenkins that also failed with this error)
On the file bin/run_lint_rust on line 42 diff=$(cargo fmt -- --write-mode=diff). It seems that now instead of  --write-mode=diffit should be --check. But that is not working on my local machine either.
Source about write-mode and check: https://github.com/rust-lang-nursery/rustfmt#checking-style-on-a-ci-server

@eloaverona from chat


Error - Unable to download image

not able to download any images for boot to docker

@sundeep23 Can you provide more information? Thanks.

@sundeep23 closing this due to lack of clarification.


cannot use fail2ban out of the box

Even though fail2ban ships with a ssh jail configured, there is no way to enable it, at least that I could figure out.  I had to add the following to my configuration.nix to get it working:
     services.fail2ban.jails.ssh-iptables =
      ''
        enabled  = true
        filter   = sshd
        action   = iptables[name=SSH, port=ssh, protocol=tcp]
        maxretry = 5
      '';

The only difference between this and what is shipped is the enabled = true line.  It would be awesome to add a configuration option to enable this, perhaps something like services.fail2ban.jails.ssh-iptables.enable = true that would add that line for you.
It seems pointless to ship it as is, if what you have to do to use a configuration for ssh is to repeat what is already being put in the jails.conf file.

There is a shorter method to enable the jail. This is definitely non-obvious tho. The module I use to enable fail2ban and the ssh-iptables jail contains
services.fail2ban.enable = true;
services.fail2ban.jails.ssh-iptables = "enabled = true";

The configuration option for jails uses the lines type. This will append, with a newline, the values all modules add to the same config. In this case the "enabled = true" config lines for ssh-iptables jail will be appended to the ssh-iptables jail config defined within the fail2ban module. This will result in the jail config:
[ssh-iptables]
enabled = true
filter   = sshd
action   = iptables[name=SSH, port=ssh, protocol=tcp]
maxretry = 5

If this method makes sense and sounds reasonable then I think updating the docs would suffice. Otherwise I think the "enable" config option of a jail should be partitioned from the config option for the configuration text of the jail.

When I filed the bug, I was new to NixOS and didn't realize the append nature of lines types.  I just tried this and it works great.  Perhaps some indication of this in the documentation would then be sufficient.

This is still not clear and should be documented or enabled by default. Glad I found this ticket though.

In fact, if you search around Github for services.fail2ban.enable = true;, you'll find that just about everyone is assuming that fail2ban is actually working with just that.

Is this fixed by https://github.com/NixOS/nixpkgs/pull/11958 ?

Yes, it appears so


TestSuiteSourceCreationComponent

What's done:

[x] Added TestSuiteSourceCreationComponent
[x] Added endpoint to save new TestSuitesSource
[x] Improved SelectForm
[x] Improved ValidationRegularExpressions

The point is that now only entity in database is created, no preprocessing is run.
@nulls need your help here


Can't get i2c interrupt working on core1.

Hello,
I have have a pico working as a i2c slave, using i2c interupts.
I have tried to let core1 do the i2c communication but it seems as if core1 doesn't receive the interrupts.
I have a simplified version of the code below.
#include <iostream>
#include <stdio.h>

#include "pico/stdlib.h"
#include "pico/multicore.h"
#include "hardware/i2c.h"
#include "hardware/irq.h"
#include "hardware/uart.h"

#define I2C0_SLAVE_ADDR 0x04

#define GPIO_SDA0 0
#define GPIO_SCK0 1

#define I2C_INTR_MASK_RX_FULL 0x00000004
#define I2C_INTR_MASK_READ_REQ 0x00000020

volatile uint32_t *const I2C0_DATA_CMD
    = reinterpret_cast<uint32_t *const>(I2C0_BASE + 0x10);
volatile uint32_t *const I2C0_INTR_STAT
    = reinterpret_cast<uint32_t *const>(I2C0_BASE + 0x2C);
volatile uint32_t *const I2C0_INTR_MASK
    = reinterpret_cast<uint32_t *const>(I2C0_BASE + 0x30);
volatile uint32_t *const I2C0_CLR_RD_REQ
    = reinterpret_cast<uint32_t *const>(I2C0_BASE + 0x50);

void i2c0_irq_handler() {
    std::cout << "test" << std::endl;
}

void core1_entry() {
    i2c_init(i2c0, 100 * 1000);
    i2c_set_slave_mode(i2c0, true, I2C0_SLAVE_ADDR);

    gpio_set_function(GPIO_SDA0, GPIO_FUNC_I2C);
    gpio_set_function(GPIO_SCK0, GPIO_FUNC_I2C);
    gpio_pull_up(GPIO_SDA0);
    gpio_pull_up(GPIO_SCK0);

    /* Enable the interrupts we want. */
    *I2C0_INTR_MASK = (I2C_INTR_MASK_READ_REQ | I2C_INTR_MASK_RX_FULL);

    /* Set up the interrupt handlers. */
    irq_set_exclusive_handler(I2C0_IRQ, i2c0_irq_handler);
    /* Enable I2C interrupts. */
    irq_set_enabled(I2C0_IRQ, true);

    while (true) {
        tight_loop_contents();
    }
}

int main() {
    stdio_init_all();

    //multicore_launch_core1(&core1_entry);
    core1_entry();

    while (true) {
        tight_loop_contents();
    }
}

When I let core0 run the function core1_entry, 'test' is printed a couple of times when the i2c master tries to communicate.
But when I use multicore_launch_core1(&core1_entry); instead of core1_entry, in the main function, nothing gets printed.
Am I using the multicore function wrong or is there some other reason i2c0_irq_handler doesn't get called?

it would be worth checking whether the problem is with the printing or the I2C IRQ - perhaps try toggling a LED to check?

I tried turning on the LED on GPIO25 and I got the same result.
Works fine on core0 but not on core1.

On an unrelated side-note, the constants that you use here:
volatile uint32_t *const I2C0_DATA_CMD
    = reinterpret_cast<uint32_t *const>(I2C0_BASE + 0x10);
volatile uint32_t *const I2C0_INTR_STAT
    = reinterpret_cast<uint32_t *const>(I2C0_BASE + 0x2C);
volatile uint32_t *const I2C0_INTR_MASK
    = reinterpret_cast<uint32_t *const>(I2C0_BASE + 0x30);
volatile uint32_t *const I2C0_CLR_RD_REQ
    = reinterpret_cast<uint32_t *const>(I2C0_BASE + 0x50);

can also be found in https://github.com/raspberrypi/pico-sdk/blob/master/src/rp2040/hardware_regs/include/hardware/regs/i2c.h
#define I2C_IC_DATA_CMD_OFFSET _u(0x00000010)
#define I2C_IC_INTR_STAT_OFFSET _u(0x0000002c)
#define I2C_IC_INTR_MASK_OFFSET _u(0x00000030)
#define I2C_IC_CLR_RD_REQ_OFFSET _u(0x00000050)

Alternatively, you may prefer to use i2c0_hw from https://github.com/raspberrypi/pico-sdk/blob/master/src/rp2040/hardware_structs/include/hardware/structs/i2c.h

Thanks, i2c0_hw looks a lot easier to use than what I have now.

Note also feel free to open an issue for any missing helper functions in i2c.h (seems like we are missing some IRQ setup related ones, that we generally have for other h/w)

It's true that there aren't many helper functions for i2c slave operations, so I might do just that.

I tried turning on the LED on GPIO25 and I got the same result.
Works fine on core0 but not on core1.

just double checking on that one that you did the gpio_init for the LED pin from core1 when you did that?

I did, I put both gpio_init and gpio_set_dir in the core1_entry function.

It seems the problem only appears when I upload the .elf binary using the SWD port (using a raspberry pi 4).
Uploading the .uf2 binary using usb mass storage transfer gives no problems.
The problem is probably related to #386.
@kilograham mentioned there that you must do a monitor reset init everytime beforehand, and that does seem to work as well in my case.
Can that however be reduced to a single command? I have been using
openocd -f "interface/raspberrypi-swd.cfg" -f "target/rp2040.cfg" -c "program multicore.elf verify reset exit"
this whole time, and that alone does not seem to work.


Make hrefs on links appear in output.

Resolved by:
https://github.com/ryanAllMad/js-job-helper/commit/c1003567b9c62b9a58a7468b0a600d7666900fd0


python 2.7 support!

Correct me if I'm wrong (as I've never used Python 2.7), but I think the default wrapper should work with it. As long as you don't use the async wrapper, there shouldn't be a problem.


Add a global setting for user to choose whether they want Longhorn todelete workload pod automatically when the volume is detached unexpectly

longhorn/longhorn#1719

My bad.
I updated the default-settings.yaml
Updated document
Resolved conflix


[pigeon] StandardFileSystem only supports file:* and data:* URIs

E:\Program\AndroidStudio\Flutter\basics>flutter pub run pigeon ^
More? --input pigeons/message.dart ^
More? --dart_out lib/pigeon.dart ^
More? --objc_header_out ios/Runner/pigeon.h ^
More? --objc_source_out ios/Runner/pigeon.m ^
More? --java_out ./android/app/src/main/java/dev/flutter/pigeon/Pigeon.java ^
More? --java_package "mine.pigeon"
Unhandled exception:
IsolateSpawnException: Unable to spawn isolate: /C:/Users/ADMINI~1/AppData/Local/Temp/ee87bb06/_pigeon_temp_.dart:1:8: Error: Error when reading 'e
:ProgramAndroidStudioFlutter%08asicspigeonsmessage.dart': StandardFileSystem only supports file:* and data:* URIs
import 'E:\Program\AndroidStudio\Flutter\basics\pigeons\message.dart';
       ^
pub finished with exit code 255

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
the code created is incorrect
`import 'E:\Program\AndroidStudio\Flutter\basics\pigeons\message.dart';`

Hi @ipipip1735
Can you please provide your flutter doctor -v and flutter run --verbose logs, and a minimal complete reproducible code sample?
Thank you

flutter doctor -v
[√] Flutter (Channel stable, 1.20.4, on Microsoft Windows [Version 10.0.18362.1139], locale zh-CN)
    • Flutter version 1.20.4 at D:\SoftWare\Flutter\flutter-1.20.4
    • Framework revision fba99f6cf9 (4 weeks ago), 2020-09-14 15:32:52 -0700
    • Engine revision d1bc06f032
    • Dart version 2.9.2

[!] Android toolchain - develop for Android devices (Android SDK version 29.0.3)
    • Android SDK at D:\SoftWare\Android\SDK
    • Platform android-29, build-tools 29.0.3
    • Java binary at: D:\SoftWare\Android\AndroidStudio\jre\bin\java
    • Java version OpenJDK Runtime Environment (build 1.8.0_242-release-1644-b01)
    X Android license status unknown.
      Try re-installing or updating your Android SDK Manager.
      See https://developer.android.com/studio/#downloads or visit https://flutter.dev/docs/get-started/install/windows#android-setup for detailed
      instructions.

[√] Android Studio (version 4.0)
    • Android Studio at D:\SoftWare\Android\AndroidStudio
    • Flutter plugin version 50.0.1
    • Dart plugin version 193.7547
    • Java version OpenJDK Runtime Environment (build 1.8.0_242-release-1644-b01)

[!] Connected device
    ! No devices available

! Doctor found issues in 2 categories.

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
[code sample]
pigeons/message.dart
import 'package:pigeon/pigeon.dart';

class SearchRequest {
  String query;
}

class SearchReply {
  String result;
}

@HostApi()
abstract class Api {
  SearchReply search(SearchRequest request);
}

[Reproducible Example]
https://github.com/ipipip1735/one.git
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
[Error]
flutter pub run pigeon ^
  --input pigeons/message.dart ^
  --dart_out lib/pigeon.dart ^
  --objc_header_out ios/Runner/pigeon.h ^
  --objc_source_out ios/Runner/pigeon.m ^
  --java_out ./android/app/src/main/java/dev/flutter/pigeon/Pigeon.java ^
  --java_package "dev.flutter.pigeon"

E:\Program\Flutter\one>flutter pub run pigeon ^
More?   --input pigeons/message.dart ^
More?   --dart_out lib/pigeon.dart ^
More?   --objc_header_out ios/Runner/pigeon.h ^
More?   --objc_source_out ios/Runner/pigeon.m ^
More?   --java_out ./android/app/src/main/java/dev/flutter/pigeon/Pigeon.java ^
More?   --java_package "dev.flutter.pigeon"
Unhandled exception:
IsolateSpawnException: Unable to spawn isolate: /C:/Users/ADMINI~1/AppData/Local/Temp/5d0452a4/_pigeon_temp_.dart:1:8: Error: Error when reading 'e
:ProgramFlutteronepigeonsmessage.dart': StandardFileSystem only supports file:* and data:* URIs
import 'E:\Program\Flutter\one\pigeons\message.dart';
       ^
pub finished with exit code 255

Hi @ipipip1735
Looks like you have a special character in your path

Can you please change your path and try again?
I am not getting the same error using your code repository

Create flutter plugin

Declare  dart API  for  platform(Android / iOS) in  .dart file

there is an error using flutter pub run pigeon.
in windows 10, flutter pub run pigeon creates a .dart file in Windows's temporary directory.
it seems that import absolute path is incorrect syntax in temp .dart created.
compiler says StandardFileSystem only supports file:* and data:* URIs
there is no example using import absolute path in doc
i try to use / as Path Delimiter, but it doesn't work.

in youtube, i find no video about making API files for android/iOS with pigeon. it seems that pigeon isn't a well-known plugin.

Trying on WIndows, I am getting the following error with your  project
C:\Users\Taha\AndroidStudioProjects\one>flutters pub run pigeon ^ --input ./pigeons/message.dart ^ --dart_out lib/pigeon.dart ^ --objc_header_out ios/Runner/pigeon.h ^ --objc_source_out ios/Runner/pigeon.m ^ --
java_out ./android/app/src/main/java/dev/flutter/pigeon/Pigeon.java ^ --java_package "dev.flutter.pigeon"
Unhandled exception:
IsolateSpawnException: Unable to spawn isolate: ../../AppData/Local/Temp/9d5269b2/_pigeon_temp_.dart:1:8: Error: Error when reading '../../AppData/Local/Temp/9d5269b2/........AndroidStudioProjectsonepigeonsmess
age.dart': The system cannot find the file specified.

import '..\..\..\..\AndroidStudioProjects\one\pigeons\message.dart';
       ^
pub finished with exit code 255

Same as here https://github.com/flutter/flutter/issues/67227#issuecomment-711196865
CC @gaaclarke

I am wondering if I introduced this 🤔
I find it strange that the implementation was working for me on Windows when I made #216, however, now I also see this error.

@creativecreatorormaybenot don't worry about it, we need to get Windows CI tests at some point.  Not your fault we don't have those yet.  I'll get a windows machine setup later today, I'm sure it's something silly.

PR is up for review that fixes this.  It turns out that Dart on windows didn't like import statements that use backslashes.  I would have expected that to work.  It might be that different versions of dart behave differently.

published fix in 0.1.13

if the same issue still exists when you update the lastest pigeon, also try to the following way.
1.locate pigeon.dart.
on windows:
Your FlutterSDK\.pub-cache\hosted\pub.dartlang.org\pigeon-0.1.13\bin\pigeon.dart
2.modify pigeon.dart to with hard code.
from:
  final String code = """$importLine
import 'dart:io';
import 'dart:isolate';
import 'package:pigeon/pigeon_lib.dart';

void main(List<String> args, SendPort sendPort) async {
  sendPort.send(await Pigeon.run(args));
}
""";

to:
final String code = """
import '/E:/Program/AndroidStudio/Flutter/FTA/flutter_plugin_one/pigeons/message.dart';
import 'dart:io';
import 'dart:isolate';
import 'package:pigeon/pigeon_lib.dart';

void main(List<String> args, SendPort sendPort) async {
  sendPort.send(await Pigeon.run(args));
}
""";

here, absolute path begins with /. such as:
import '/E:/Program/AndroidStudio/Flutter/FTA/flutter_plugin_one/pigeons/message.dart';

run flutter clean

re-add  dependency in pubspec.yaml, then flutter pub get

dev_dependencies:
  flutter_test:
    sdk: flutter
  pigeon: ^0.1.13

if ios/Runner/  and ./android/app/ doesn't exist in skeleton files, make folders.
iOS: ios/Runner
Android: android/src/main/java/dev/flutter/pigeon/

run the following command:

flutter pub run pigeon \
  --input pigeons/message.dart \
  --dart_out lib/pigeon.dart \
  --objc_header_out ios/Runner/pigeon.h \
  --objc_source_out ios/Runner/pigeon.m \
  --java_out ./android/src/main/java/dev/flutter/pigeon/Pigeon.java \
  --java_package "dev.flutter.pigeon"

updateing to 0.1.13 doesn't work for me, so i have to use hard code.
hope this is helpful to you.

@ipipip1735 I think there were 2 issues, only one got fixed.

Dart doesn't like import statements with backslashes (fixed)
Windows can't do relative paths between drives (not verified, not fixed, I think this is your current issue)

Can you verify that pigeon works if the input file is on the same drive as your temp directory (probably c:)?  We have an issue for that here https://github.com/flutter/flutter/issues/68583


Replace ContainerAddress with a regular string

per https://github.com/dagger/dagger/pull/3219#discussion_r987337784
We generally use scalars for opaque values that pass through the client without ever being modified or constructed directly. ContainerAddress on the other hand is a user-provided string, and having to cast it to this special type is a little weird.
Also, we currently use regular strings for paths (e.g. withNewFile(path: String!)), so it seems a little inconsistent to opt for a scalar type for image addresses but not paths.

No opinion on this.

This is why I did this:

So 👍 to this.


chore: 0.0.7-release

https://github.com/census-instrumentation/opencensus-web/releases/tag/untagged-82cf6c6f5fc8a02cef1f

Codecov Report

Merging #177 into master will not change coverage.
The diff coverage is n/a.

@@          Coverage Diff           @@
##           master    #177   +/-   ##
======================================
  Coverage    95.7%   95.7%
======================================
  Files          32      32
  Lines         909     909
  Branches      162     162
======================================
  Hits          870     870
  Misses         39      39

Continue to review full report at Codecov.

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


Fix duplicate sensors being created #25

Fix for duplicate sensor setup as described in #25.
If one has both electricity and gas from Zonneplan, one will have two connections in the response. The electricity connection contains all relevant data, such as electricity and gas prices. The gas connection lacks a lot of information, but is still getting setup:
https://github.com/fsaris/home-assistant-zonneplan-one/blob/main/custom_components/zonneplan_one/coordinator.py#L87-L90
This PR first tries to use the electricity connection to poll for the summary data and if successful skips retrieving the summary data for the gas connection.
If you are affected by this bug, follow these steps:

Update the Zonneplan component through HACS
Restart Home Assistant
In Home Assistant click on Configuration and click on Integrations
Remove Zonneplan, and then re-add Zonneplan

Likely introduced in https://github.com/fsaris/home-assistant-zonneplan-one/commit/11e9adb22e4594d5f30e7354232cb9e309d0d05d
Fixes https://github.com/fsaris/home-assistant-zonneplan-one/issues/25

Tnx for the PR. Nice find