MS-plus: are ZD2 from MS-plus compatible with G1Four/etc, and vice-versa

The immediate answer is NO, it looks like Zoom have jeri-rigged the ID and Groups to be different between the series
$ python3 ../decode_effect.py -s B1_BOMBER.ZD2
0x07000010 : B1_BOMBER.ZD2, Bomber (v1.50 8.45%)

$ python3 ../decode_effect.py -s MS_BOMBER.ZD2
0x09000040 : MS_BOMBER.ZD2, Bomber (v1.10 8.45%)

The symbols listed in the ELF Code segment are very similar, and there are relatively small difference in the hexdump of the Code
$ diff  B1_BOMBER.ZD2.code.sym MS_BOMBER.ZD2.code.sym
28c28
< 0909210
---
> 0348410
39c39
< 0908410
---
> 0536810
70c70
< 0334410
---
> 2108010
105c105
< 0331610
---
> 1780410

These symbol name differences might just be as the ZD2 has been re-compiled. Looking at a 2nd effect (ZNR) it has completely different number symbols too...

There are also some differences in the GroupName, although I am not too sure how these affect the actual operation. Maybe just used for ZT2 and grouping of ZIC in the library (MS-plus).
B1 FOUR/unzipped$ find . -name "*.ZD2.dump" -exec grep groupname {} \; | sort | uniq
    groupname = u'AMP' (total 3)
    groupname = u'CABINET' (total 7)
    groupname = u'DELAY' (total 5)
    groupname = u'DRIVE' (total 5)
    groupname = u'DYNAMICS' (total 8)
    groupname = u'FILTER' (total 6)
    groupname = u'MODULATION' (total 10)
    groupname = u'REVERB' (total 6)
    groupname = u'SFX' (total 3)

ms-60b/decoded$ find . -name "*.ZD2.txt" -exec grep groupname {} \; | sort | uniq    groupname = 'BASS AMP' (total 8)
    groupname = 'DELAY' (total 5)
    groupname = 'DRIVE' (total 5)
    groupname = 'DYNAMICS' (total 8)
    groupname = 'FILTER' (total 6)
    groupname = 'MODULATION' (total 10)
    groupname = 'PITCH SHIFT' (total 11)
    groupname = 'PREAMP' (total 6)
    groupname = 'REVERB' (total 6)
    groupname = 'SFX' (total 3)
    groupname = 'SYNTH' (total 5)

I just added some options which might help us...
$ python3 decode_effect.py --help
...
  --force-id FORCE_ID   Force the ID to a particular value (in Hex)
  --force-name FORCE_NAME
                        Force the Name to a particular string (max 11 chars)
  --force-gname FORCE_GNAME
                        Force the GroupName to a particular string (max 11 chars)
  -o OUTPUT, --output OUTPUT
                        output combined result to FILE

Something like :-)
$ python3 ../decode_effect.py --force-id 0x07000010 -o MOD_BOMBER.ZD2 MS_BOMBER.ZD2
Checksum Recalculated: 0x9966b592
$ python3 ../decode_effect.py -s MOD_BOMBER.ZD2
0x07000010 : MOD_BOMBER.ZD2, Bomber (v1.10 8.45%)

Attempting to install MS effect on my (broken screen) G1Four...
$ python3 ../zoomzt2.py -U BOMBER.ZD2
Uninstalling effect: BOMBER.ZD2

$ cp MOD_BOMBER.ZD2 BOMBER.ZD2

$ python3 ../zoomzt2.py -I BOMBER.ZD2
Installing effect: BOMBER.ZD2
uploading...

$ python3 ../zoomzt2.py -R -w -s FLST_SEQ.ZT2
Group 1 : DYNAMICS
0x01000010 : COMP.ZD2, (v1.40 1)
...
Group 7 : SFX
0x07000020 : AUTOPAN.ZD2, (v1.40 1)
0x07000041 : LPROLL3S.ZD2, (v1.10 1)
0x07000050 : HOTSPICE.ZD2, (v1.30 1)
0x07000010 : BOMBER.ZD2, (v1.10 1)
...

The real question is whether I can actual load it into a patch, which is a little more difficult with the broken screen.
Current patch is empty
$ amidi -p hw:2,0,0 -S 'F0 52 00 6e 64 02 00 09 00 F7' -r temp.bin -t 2

1023 bytes read
$ python3 ../decode_screens.py temp.bin
---
Effect: Bypass (Off)
 :
 :
 :
 :
---
Effect: Bypass (Off)
...

Convert ID to 7-bit hex
>>> a = 0x07000010
>>> print(hex(a & 0x7f))
0x10
>>> print(hex(a >> 7 & 0x7f))
0x0
>>> print(hex(a >> 14 & 0x7f))
0x0
>>> print(hex(a >> 21 & 0x7f))
0x38
>>> print(hex(a >> 28 & 0x7f))
0x0

and install to current patch (slot 0)
$ amidi -p hw:2,0,0 -S 'f0 52 00 6e 64 03 00 00 01 10 00 00 38 00 f7'

Decode screens changes, but does NOT display the name
$ python3 ../decode_screens.py temp.bin | head
---
Effect:  (Off)
 :
 :
 :
 :
---
Effect: Bypass (Off)
...

Downloading current patch does however
$ python3 ../zoomzt2.py -c temp.zptc
$ python3 ../decode_preset.py -s temp.zptc
Name: Empty
Patch Volume: 100
Effect 1: 0x07000010
   Enabled: True
   Param 1: 0
   Param 2: 0
   Param 3: 0
   Param 4: 0
   Param 5: 0
   Param 6: 0
   Param 7: 0
   Param 8: 0

If i revert the effect to the B1Four version, it does show on 'screens'.
$ python3 ../zoomzt2.py -U BOMBER.ZD2
Uninstalling effect: BOMBER.ZD2
$ cp B1_BOMBER.ZD2 BOMBER.ZD2
$ python3 ../zoomzt2.py -I BOMBER.ZD2
Installing effect: BOMBER.ZD2
uploading...

$ amidi -p hw:2,0,0 -S 'F0 52 00 6e 64 02 00 09 00 F7' -r temp.bin -t 2

1023 bytes read
$ python3 ../decode_screens.py temp.bin | head
---
Effect: Bomber (Off)
Decay : 50
Tone : 4
Mix : 30
ON/OFF : TRGGR
---
Effect: Bypass (Off)
 :
 :

This at least means the pedal is not 'broken' by uploading the wrong/MS-plus version.
Note: when forcing the ID, we only changes the number in the header of the ZD2, nothing within the Code segment as altered.

Alternate approach, take the Code from the MS effect and jam it into B1 effect file. This means that all the other segments are 'as-was'...
$ python3 ../decode_effect.py -D MS_BOMBER.ZD2 -C -o MOD_BOMBER.ZD2 B1_BOMBER.ZD2
Checksum Recalculated: 0x438fb019
$ python3 ../decode_effect.py -s MOD_BOMBER.ZD2
0x07000010 : MOD_BOMBER.ZD2, Bomber (v1.50 8.45%)

$ python3 ../zoomzt2.py -U BOMBER.ZD2
Uninstalling effect: BOMBER.ZD2
$ cp MOD_BOMBER.ZD2 BOMBER.ZD2
$ python3 ../zoomzt2.py -I BOMBER.ZD2
Installing effect: BOMBER.ZD2
uploading...

$ python3 ../zoomzt2.py -R -w -s FLST_SEQ.ZT2 | grep -A 5 SFX
Group 7 : SFX
0x07000020 : AUTOPAN.ZD2, (v1.40 1)
0x07000041 : LPROLL3S.ZD2, (v1.10 1)
0x07000050 : HOTSPICE.ZD2, (v1.30 1)
0x07000010 : BOMBER.ZD2, (v1.50 1)
Group 8 : DELAY

'Screens' works, and it even makes sound when triggered...
$ amidi -p hw:2,0,0 -S 'F0 52 00 6e 64 02 00 09 00 F7' -r temp.bin -t 2

1023 bytes read
simon@the-void:~/zoom-zt2-sdw-github/MS_vs_B1Four$ python3 ../decode_screens.py temp.bin | head
---
Effect: Bomber (Off)
Decay : 50
Tone : 4
Mix : 30
ON/OFF : TRIGGER
---
Effect: Bypass (Off)
 :
 :

Now I am doubting myself, did I screw up process or trick myself?
$ md5sum *BOMBER.ZD2
ee15a464cc57161677ca42387c6085f4  B1_BOMBER.ZD2
5c6196b5e155841a44c193f291ac4061  BOMBER.ZD2
5c6196b5e155841a44c193f291ac4061  MOD_BOMBER.ZD2
c0743e090025b1bbd919ad9f3133fdef  MS_BOMBER.ZD2

And a fresh download from pedal
check$ md5sum *.ZD2
5c6196b5e155841a44c193f291ac4061  BOMBER.ZD2

And I even power cycled pedal to confirm that it does/still works after.... it did!
So does this mean that there's something OTHER than the Code segment that's preventing it working?

There's not too much different; first 'ZDLF' segment and the 'final bytes'... I can quickly rule out the final bytes.
$ python3 ../decode_effect.py -D MS_BOMBER.ZD2 -C -F -o MOD_BOMBER.ZD2 B1_BOMBER.ZD2
Checksum Recalculated: 0x438fb019
$ python3 ../zoomzt2.py -U BOMBER.ZD2
Uninstalling effect: BOMBER.ZD2
$ cp MOD_BOMBER.ZD2 BOMBER.ZD2
$ python3 ../zoomzt2.py -I BOMBER.ZD2
Installing effect: BOMBER.ZD2
uploading...

$ python3 ../zoomzt2.py -R -w -s FLST_SEQ.ZT2 | grep -A 5 SFX
Group 7 : SFX
0x07000020 : AUTOPAN.ZD2, (v1.40 1)
0x07000041 : LPROLL3S.ZD2, (v1.10 1)
0x07000050 : HOTSPICE.ZD2, (v1.30 1)
0x07000010 : BOMBER.ZD2, (v1.50 1)
Group 8 : DELAY

$ amidi -p hw:2,0,0 -S 'F0 52 00 6e 64 02 00 09 00 F7' -r temp.bin -t 2

1023 bytes read
$ python3 ../decode_screens.py temp.bin | head
---
Effect: Bomber (Off)
Decay : 50
Tone : 4
Mix : 30
ON/OFF : TRIGGER
---
Effect: Bypass (Off)
 :
 :

So it seems that's its the first segment, which isn't fully parsed by my scripts:

So it looks like the Byte (or ULint32) after the checksum is a 'target pedal'... changing 0xA0 to 0x07 lets the original effect (with altered ID) run on the G1Four.
$ python3 ../decode_effect.py --force-id 0x07000010 -o MOD_BOMBER.ZD2 MS_BOMBER.ZD2
Checksum Recalculated: 0x9966b592
$ hexedit MOD_BOMBER.ZD2

$ python3 ../zoomzt2.py -U BOMBER.ZD2
Uninstalling effect: BOMBER.ZD2
$ cp MOD_BOMBER.ZD2 BOMBER.ZD2
$ python3 ../zoomzt2.py -I BOMBER.ZD2
Installing effect: BOMBER.ZD2
uploading...

$ amidi -p hw:2,0,0 -S 'F0 52 00 6e 64 02 00 09 00 F7' -r temp.bin -t 2

1023 bytes read
$ python3 ../decode_screens.py temp.bin | head
---
Effect: Bomber (Off)
Decay : 50
Tone : 4
Mix : 30
ON/OFF : TRIGGER
---
Effect: Bypass (Off)
 :
 :

check$ hexdump -C BOMBER.ZD2 | head
00000000  5a 44 4c 46 78 00 00 00  92 b5 66 99 07 00 00 00  |ZDLFx.....f.....|
00000010  00 00 00 00 01 00 00 00  00 00 00 00 00 00 00 00  |................|
00000020  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000030  00 00 00 00 00 00 00 00  80 00 00 00 00 00 00 00  |................|
00000040  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000050  00 00 00 00 00 00 00 00  01 31 2e 31 30 00 00 07  |.........1.10...|
00000060  10 00 00 07 42 6f 6d 62  65 72 00 00 39 b6 11 53  |....Bomber..9..S|
00000070  46 58 00 30 00 00 00 f1  b1 59 ff e5 00 00 00 00  |FX.0.....Y......|
00000080  49 43 4f 4e b6 00 00 00  42 4d b6 00 00 00 00 00  |ICON....BM......|
00000090  00 00 3e 00 00 00 28 00  00 00 18 00 00 00 1e 00  |..>...(.........|

Scripted
$ python3 ../decode_effect.py --force-target 0x07 --force-id 0x07000010 -o MOD_BOMBER.ZD2 MS_BOMBER.ZD2

Whole process repeated for MS-plus' ZNR effect
$ python3 ../decode_effect.py --force-target 0x07 --force-id 0x01000040 -o MOD_ZNR.ZD2 MS_ZNR.ZD2
Checksum Recalculated: 0x37a89eee
$ python3 ../decode_effect.py -7 -s MOD_ZNR.ZD2
0x01000040 : MOD_ZNR.ZD2, ZNR (v1.10 4.35%)
40 00 00 08 00

$ python3 ../zoomzt2.py -U ZNR.ZD2
Uninstalling effect: ZNR.ZD2
$ cp MOD_ZNR.ZD2 ZNR.ZD2
$ python3 ../zoomzt2.py -I ZNR.ZD2
Installing effect: ZNR.ZD2
uploading...

$ amidi -p hw:2,0,0 -S 'f0 52 00 6e 64 03 00 01 01 40 00 00 08 00 f7'

$ amidi -p hw:2,0,0 -S 'F0 52 00 6e 64 02 00 09 00 F7' -r temp.bin -t 2

1023 bytes read
$ python3 ../decode_screens.py temp.bin | head -n 15
---
Effect: Bomber (Off)
Decay : 50
Tone : 4
Mix : 30
ON/OFF : TRIGGER
---
Effect: ZNR (On)
Detect : EFXIN
Depth : 100
THRSHLD : 30
Decay : 0
---
Effect: Bypass (Off)
 :

Freaking Awesome!

Did you get the MS+ ZNR effect to run on your G1Four? :-o

Yes, after adaption both MS-plus BOMBER and ZNR ran on my G1Four - it's screen is broken so a little awkward to control...
@thammer I'd be interested what value the MS-75CRD+ and MS-50+ use for the 'target' byte
./OPTCOMP.ZD2
00000000  5a 44 4c 46 78 00 00 00  90 97 bf 62 a0 00 00 00  |ZDLFx......b....|
                                               ^^
./MINIMARK.ZD2
00000000  5a 44 4c 46 78 00 00 00  c0 7e 45 47 80 00 00 00  |ZDLFx....~EG....|

I believe that this is a bit field, and the effects for a single pedal seem to have overlapping values. ie the true value for MS-60B+ is 0x80 and 0xA0 overlaps this.

@thammer
Since you have the MS-50G+ and MS-70CDR+, can you please do a summary ('-s -m') print of the effects on each?
Like
https://github.com/mungewell/zoom-zt2/blob/master/zoom_fx_ms-plus/ms-60b/effects_sort.txt

Here are the summaries for MS-50G+ and MS-70CDR+.
ms50gp_effects_sort.txt
ms70cdrp_effects_sort.txt

Yes, after adaption both MS-plus BOMBER and ZNR ran on my G1Four - it's screen is broken so a little awkward to control...
@thammer I'd be interested what value the MS-75CRD+ and MS-50+ use for the 'target' byte

Here are the first 16 bytes from OPTCOMP.ZD2 from the MS-70CDR+:
5A 44 4C 46 78 00 00 00 81 32 AF 3D 90 00 00 00

... and this is the start of VIBRATO.ZD2 from the MS-50G+:
5A 44 4C 46 78 00 00 00 EF DF 14 57 90 00 00 00

Thanks for the sorted lists, I've uploaded. Looks like IDs between MS-50G+ and MS-70CDR+ roughly match, but there is major 'collision' with MS-60B+ ID's... maybe this is deliberate to make sharing effects (as pedals/patches would be confused with duplicate IDs).
Here are all the ZD2 effects the GL7 knows about. I think that if this 'target' is a bit-field, it may be of required capability (more memory, double screen, expression pedal) rather than particular pedal model. None of these bits overlaps the MS-plus values...
$ find "A1 FOUR" -name "*.ZD2" -exec bash -c "hexdump -C '{}' | head -n1 | cut -c 48-60" \; | sort | uniq
02 00 00 00
03 00 00 00
06 00 00 00
07 00 00 00
$ find "A1X FOUR" -name "*.ZD2" -exec bash -c "hexdump -C '{}' | head -n1 | cut -c 48-60" \; | sort | uniq
02 00 00 00
03 00 00 00
06 00 00 00
07 00 00 00
0f 00 00 00
$ find "B1 FOUR" -name "*.ZD2" -exec bash -c "hexdump -C '{}' | head -n1 | cut -c 48-60" \; | sort | uniq
02 00 00 00
03 00 00 00
06 00 00 00
07 00 00 00
$ find "B1X FOUR" -name "*.ZD2" -exec bash -c "hexdump -C '{}' | head -n1 | cut -c 48-60" \; | sort | uniq
02 00 00 00
03 00 00 00
06 00 00 00
07 00 00 00
0f 00 00 00
$ find "B3n" -name "*.ZD2" -exec bash -c "hexdump -C '{}' | head -n1 | cut -c 48-60" \; | sort | uniq
01 00 00 00
03 00 00 00
05 00 00 00
07 00 00 00
0f 00 00 00
$ find "B6" -name "*.ZD2" -exec bash -c "hexdump -C '{}' | head -n1 | cut -c 48-60" \; | sort | uniq
08 00 00 00
0f 00 00 00
$ find "G11" -name "*.ZD2" -exec bash -c "hexdump -C '{}' | head -n1 | cut -c 48-60" \; | sort | uniq
04 00 00 00
05 00 00 00
07 00 00 00
0f 00 00 00
$ find "G1 FOUR" -name "*.ZD2" -exec bash -c "hexdump -C '{}' | head -n1 | cut -c 48-60" \; | sort | uniq
02 00 00 00
06 00 00 00
07 00 00 00
$ find "G1X FOUR" -name "*.ZD2" -exec bash -c "hexdump -C '{}' | head -n1 | cut -c 48-60" \; | sort | uniq
02 00 00 00
06 00 00 00
07 00 00 00
0f 00 00 00
$ find "G3n" -name "*.ZD2" -exec bash -c "hexdump -C '{}' | head -n1 | cut -c 48-60" \; | sort | uniq
01 00 00 00
05 00 00 00
07 00 00 00
0f 00 00 00
$ find "G3Xn" -name "*.ZD2" -exec bash -c "hexdump -C '{}' | head -n1 | cut -c 48-60" \; | sort | uniq
01 00 00 00
05 00 00 00
07 00 00 00
0f 00 00 00
$ find "G5n" -name "*.ZD2" -exec bash -c "hexdump -C '{}' | head -n1 | cut -c 48-60" \; | sort | uniq
01 00 00 00
05 00 00 00
07 00 00 00
0f 00 00 00
$ find "G6" -name "*.ZD2" -exec bash -c "hexdump -C '{}' | head -n1 | cut -c 48-60" \; | sort | uniq
04 00 00 00
05 00 00 00
06 00 00 00
07 00 00 00
0f 00 00 00
$ find "H8" -name "*.ZD2" -exec bash -c "hexdump -C '{}' | head -n1 | cut -c 48-60" \; | sort | uniq
02 00 00 00
03 00 00 00
06 00 00 00
07 00 00 00
$ find "R20" -name "*.ZD2" -exec bash -c "hexdump -C '{}' | head -n1 | cut -c 48-60" \; | sort | uniq
02 00 00 00
03 00 00 00
06 00 00 00
07 00 00 00

For example does '0x08' (in 0x0f) mean that the effect requires an expression pedal?

'0x0F' seems specifically for 'OUT_VP', other PDL effects are '0x07'
$ find "." -name "*.ZD2.dump" -exec grep -H "target = 15" {} \;
./A1X FOUR/unzipped/OUT_VP.ZD2.dump:    target = 15
./G1X FOUR/unzipped/OUT_VP.ZD2.dump:    target = 15
./G11/unzipped/OUT_VP.ZD2.dump:    target = 15
./B1X FOUR/unzipped/OUT_VP.ZD2.dump:    target = 15
./G3n/unzipped/OUT_VP.ZD2.dump:    target = 15
./B3n/unzipped/OUT_VP.ZD2.dump:    target = 15
./G6/unzipped/OUT_VP.ZD2.dump:    target = 15
./B6/unzipped/OUT_VP.ZD2.dump:    target = 15
./G5n/unzipped/OUT_VP.ZD2.dump:    target = 15
./G3Xn/unzipped/OUT_VP.ZD2.dump:    target = 15

'0x04' is only for G6/G11, so likely the AU output or maybe some other high-capability
$ find "." -name "*.ZD2.dump" -exec grep -H "target = 4" {} \;
./G11/unzipped/AG750_AU.ZD2.dump:    target = 4
./G11/unzipped/SVT_AU.ZD2.dump:    target = 4
./G11/unzipped/MUDDY.ZD2.dump:    target = 4
./G11/unzipped/7_HEAVEN.ZD2.dump:    target = 4
./G11/unzipped/XTSBL_AU.ZD2.dump:    target = 4
./G11/unzipped/MACH30AU.ZD2.dump:    target = 4
./G11/unzipped/MS1959AU.ZD2.dump:    target = 4
./G11/unzipped/UK30A_AU.ZD2.dump:    target = 4
./G11/unzipped/MS800_AU.ZD2.dump:    target = 4
./G11/unzipped/BGMK3_AU.ZD2.dump:    target = 4
./G11/unzipped/DZ_DRVAU.ZD2.dump:    target = 4
./G11/unzipped/HW100_AU.ZD2.dump:    target = 4
./G11/unzipped/FDBMANAU.ZD2.dump:    target = 4
./G11/unzipped/VELVET.ZD2.dump:    target = 4
./G11/unzipped/KRAMPUS.ZD2.dump:    target = 4
./G11/unzipped/RCTORGAU.ZD2.dump:    target = 4
./G11/unzipped/BGMK1_AU.ZD2.dump:    target = 4
./G11/unzipped/MS45OSAU.ZD2.dump:    target = 4
./G11/unzipped/ORG120AU.ZD2.dump:    target = 4
./G11/unzipped/FDDLXRAU.ZD2.dump:    target = 4
./G11/unzipped/POLLEX.ZD2.dump:    target = 4
./G11/unzipped/REDLOOM.ZD2.dump:    target = 4
./G11/unzipped/FDMSTRAU.ZD2.dump:    target = 4
./G11/unzipped/FD_TWRAU.ZD2.dump:    target = 4
./G6/unzipped/MUDDY.ZD2.dump:    target = 4
./G6/unzipped/7_HEAVEN.ZD2.dump:    target = 4
./G6/unzipped/XTSBL_AU.ZD2.dump:    target = 4
./G6/unzipped/MACH30AU.ZD2.dump:    target = 4
./G6/unzipped/MS1959AU.ZD2.dump:    target = 4
./G6/unzipped/UK30A_AU.ZD2.dump:    target = 4
./G6/unzipped/MS800_AU.ZD2.dump:    target = 4
./G6/unzipped/RDCBST1U.ZD2.dump:    target = 4
./G6/unzipped/EGFLTR1U.ZD2.dump:    target = 4
./G6/unzipped/KKFLNG1U.ZD2.dump:    target = 4
./G6/unzipped/BGMK3_AU.ZD2.dump:    target = 4
./G6/unzipped/DZ_DRVAU.ZD2.dump:    target = 4
./G6/unzipped/HW100_AU.ZD2.dump:    target = 4
./G6/unzipped/FDBMANAU.ZD2.dump:    target = 4
./G6/unzipped/VELVET.ZD2.dump:    target = 4
./G6/unzipped/KRAMPUS.ZD2.dump:    target = 4
./G6/unzipped/RCTORGAU.ZD2.dump:    target = 4
./G6/unzipped/SPCHOL1U.ZD2.dump:    target = 4
./G6/unzipped/BGMK1_AU.ZD2.dump:    target = 4
./G6/unzipped/TS_BST1U.ZD2.dump:    target = 4
./G6/unzipped/HLDDLY1U.ZD2.dump:    target = 4
./G6/unzipped/MS45OSAU.ZD2.dump:    target = 4
./G6/unzipped/HLDVRB1U.ZD2.dump:    target = 4
./G6/unzipped/ORG120AU.ZD2.dump:    target = 4
./G6/unzipped/FDDLXRAU.ZD2.dump:    target = 4
./G6/unzipped/POLLEX.ZD2.dump:    target = 4
./G6/unzipped/REDLOOM.ZD2.dump:    target = 4
./G6/unzipped/FDMSTRAU.ZD2.dump:    target = 4
./G6/unzipped/FD_TWRAU.ZD2.dump:    target = 4

You can call me crazy... but I went for it....
Preparing Icon
$ cp ../BLANK.ZIC AUTOPAN.ZIC
$ python3 ../convert_zic.py AUTOPAN.ZIC
Converting: AUTOPAN.ZIC
Writing: icon_0.png
Writing: icon_1.png

$ gimp icon*

$ python3 ../convert_zic.py -r AUTOPAN.ZIC
Converting: AUTOPAN.ZIC

Preparing and uploading AUTOPAN (from the G1Four selection)
$ python3 ../decode_effect.py -s G1
G1Four_AUTOPAN.ZD2  G1_head.txt
$ python3 ../decode_effect.py -s G1Four_AUTOPAN.ZD2
0x07000020 : G1Four_AUTOPAN.ZD2, AutoPan (v1.40 4.10%)
$ python3 ../decode_effect.py --force-target 0xa0 --force-id 0x09000050 -o AUTOPAN.ZD2 G1Four_AUTOPAN.ZD2
Checksum Recalculated: 0x0436a30c
$ python3 ../decode_effect.py -s AUTOPAN.ZD2
0x09000050 : AUTOPAN.ZD2, AutoPan (v1.40 4.10%)

$ python3 ../zoomzt2.py --include-zic -I AUTOPAN.ZD2
Installing effect: AUTOPAN.ZD2
uploading...
Uploading icon: AUTOPAN.ZIC

And... this is the result. The audio function also worked :-)

Note: I strongly recommend caution, and to disable auto-save. You don't want a bad effect to be stored in patch to automatically reload when pedal reboots....

Why not to try using the AUTOPAN.ZD2 included on MS-50G+?

@nomadbyte
Basic answer:

I don't have access to that file (please DO NOT upload).
That's not what the thread is about.

Longer answer:
I seems that Zoom has (deliberately?) made the ID numbers of the MS-plus overlap, which would mean that the user would have to remove another effect to allow AUTOPAN, and if our understanding of target byte is correct this would prevent uploading anyhow.
According to the list that was uploaded, it had the MS-50G+ and MS-75CDR+ using (respectively):
0x07000010 : AUTOPAN.ZD2, AutoPan (v1.10 4.10%), 3a15ff218aa7f084f9a70113accb559a
0x07000011 : AUTOPN_C.ZD2, AutoPan (v1.00 4.10%), 949d6a486e8f5d32000f8b03a3f69001

The 'SFX' group on the MS-60B+ is moved to '0x09', '0x07' is used for 'PITCH SHIFT'
0x07000010 : B_OCTAVE.ZD2, BaOctaver (v1.10 7.46%), bf64c39ef122a091530f58f1896a126e

Yet to be understood how ID's on the MS-200D+ are allocated....
PS. I picked AutoPan to try the process, as there was a question on Reddit about how/if the Compression/Limiter effects worked in stereo, or whether then summed signals to mono first...

I'm not sure if you tried to cross-list the effects from the MS+ series vs. G5n/B3n series to see how much overlap is there. My guess is that ZOOM repackaged majority of the ZD2 effects for use on the G2 FOUR and MS+ series. Exception, of course, is the AMP/CAB and some DRV effects, which now have special handling (the Multi-layered IR and something on the MS-200D+).
My point is that there's more expectations in establishing if the new ZD2 are safely portable across the MS+ series.

All of the effects from the MS-plus and G-Series are listed (just TXT summaries, no ZD2):
https://github.com/mungewell/zoom-zt2/tree/master/zoom_fx_ms-plus
https://github.com/mungewell/zoom-zt2/tree/master/zoom_fx_AllZDL7
I don't have summaries for the G2 and B2... if anyone want to share.
I did some comparison with MS-50G+ to MS-75CDR+ and there's some overlap, but for some reason (memory?) the CDR has 'updated' versions.

If someone (with access to effects) wanted to export all the 'Code' segments, that would clarify whether it's just the wrapper (ID/Groups/etc) changing... or whether these actually are different in operation.
As stated; I think that the target byte (at start of ZD2 file) will prevent the free copying between pedals/series. We can --force-target but that's not particularly user friendly.

The number of parameters are often different for the "same" effect om the MS-50G+ and the MS-70CDR+, as can be seen in the effect list downloadable from the Zoom website for these two pedals. The MS-50G+ versions of the effect tends to have fewer parameters, I think.
For instance, the effect SLICER.ZD2 on the MS-50G+ has 4 parameters, whereas the SLICER_C.ZD2 on the MS-70CDR+ has 5 parameters. The MS-50G+ version lacks the "Balance" parameter.

Regarding the clashing effect IDs - is there anything preventing us from just assigning a different ID to an effect?
We could perhaps start using the unused bits in the middle of the 32 bit ID integer.
So AUTOPAN_C.ZD2 with ID 0x07000011 on the MS-70CDR+ could be assigned the ID 0x09070011 on the MS-60B+, which would place it in the correct group on the MS-60B+, while still having a unique ID
It would make exchanging patches (not effects) between pedals more difficult, though.

The presence of 'balance' param might suggest better operation in the stereo field. Maybe you have information helpful to this Reddit user...
https://www.reddit.com/r/zoommultistomp/comments/1fd1b9n/true_stereo_dynamics_in_ms70cdr_plus/
We can do anything with the power of the command line ;-) I believe that the ID is not actually used within the 'Code' segment, just as a way of the pedal managing effect files and installing the right DLL when the patch is loaded.
I did think about the 'middle' bytes of the ID, perhaps someone (who is NOT this project) might use this to indicate which pedal the ZD2 effect came from (ie byte is good to encode 50, 60, 70 or 200)... their tool could even be smart to zero this out when 'uploading' with the native pedal.

If someone (with access to effects) wanted to export all the 'Code' segments, that would clarify whether it's just the wrapper (ID/Groups/etc) changing... or whether these actually are different in operation.

Here you go:
python .\decode_effect.py .\Everything-ms50gp\AUTOPAN.ZD2 -c autopan.code
python .\decode_effect.py .\Everything-ms70cdrp\AUTOPN_C.ZD2 -c autopn_c.code
du -b *.code
12655   autopan.code
13183   autopn_c.code

So the code segments differ in size. The MS-70CDR+ one is larger.
I converted the code segments to hex strings and did a diff on the resulting files cat autopan.code | hexdump -v -e '/1 "%02x\n"' > autopan.hex. Some similarities and some differences. Large chunks of similarities, though.
I then tried comparing the AUTOPAN.ZD2 (from MS-50G+) code hexdump to a hexdump of the code segment of 160_COMP.ZD2 (from MS-70CDR+). There were less similarities there. I'm not sure if there's anything interesting to be read from this analysis, aside from the fact that the two files differ in size and contents. Someone who understands Texas Instrument assembly might be able to say something more sensible about it by looking at the disassembled code for each.

There are some Linux cross compilers and a 'free' Windows one from TI, but to be honest this is above my level of competence.
The decode_bdl.py script has the ability to list the symbol names, and shows how to pull data out of an elf...
There's the RainSel/RTFM stuff which was done on OG MS pedals, perhaps would be useful if anyone wanted to dig deeper. A Reddit user did a demo video, and comments have links to details.
https://www.reddit.com/r/zoommultistomp/comments/1cz2k0t/i_recorded_a_tutorial_on_how_to_use_div0_and_rtfm/

Is there a compassionate soul out there willing to share the MS60B+'s Clear DRV (LINPRE.ZD2) with me? I don't have an MS+ around to extract it. I'm more than ready to try it in my B1Xfour.


Add Skip & SkipLast Filter

Add Skip & SkipLast Filter
I'm using channel to buffering items in SkipLast.
But I'm wondering if I should use a queue. Could you give me some advice?

Coverage increased (+1.3%) to 73.425% when pulling 9bb6b5cd91d098c9bae73274f4ec96f23a47f734 on pocket7878:skip into 51d692ceb75baafe758b65a6af9d7c65e963402e on jochasinga:master.

@pocket7878 thanks for your active contributions. I will check back asap. Meanwhile, before your next PR, can you open an issue for a feature you'd like to add so we can have some discussions there? Also, it might be a good idea to send your PR to the dev branch so we can keep master clean ;)

@jochasinga That would be fine :)

Coverage increased (+1.2%) to 74.672% when pulling 10ae37ffd87cff26c060345b0377d551b4e0eb93 on pocket7878:skip into e1b20f6e804fcca041a9d90f85a9d7441d9a161b on jochasinga:master.

@pocket7878 can you retract this PR, merge the latest tip back and revise the following:

rest_skip variable name is not following Go's convention, which requires variable names to be in camelCases like restSkip.  However, itself is not descriptive. Can you think of a better variable name that better describe what it holds?

The parameter named skip in both Skip and SkipLast signature is not descriptive. Try nth

func Skip(nth uint) {
        // ...
}

then resubmit the PR again to the dev branch this time? I'd really appreciate this.
p.s. using a channel for buffering is fine, since channels are basically queues.


Scanner: Filter out not applicable license files for packages

The filtering was accidentally applied only to projects.

Merged regardless of the non-related Travis failure.


Binary files

It looks like you pushed some binary files

Thanks, it was a bunch of Vim backup files that I accidentally pushed.


Error after installing

After following the instructions and reloading, the terminal hangs and I see the following error message in the developer tools:
Uncaught Error: Could not call remote function ''. Check that the function signature is correct. Underlying error: Cannot read property 'blue' of undefined
Error: Could not call remote function ''. Check that the function signature is correct. Underlying error: Cannot read property 'blue' of undefined
    at callFunction (/Applications/Hyper.app/Contents/Resources/electron.asar/browser/rpc-server.js:235:11)
    at EventEmitter.<anonymous> (/Applications/Hyper.app/Contents/Resources/electron.asar/browser/rpc-server.js:342:5)
    at emitMany (events.js:127:13)
    at EventEmitter.emit (events.js:201:7)
    at WebContents.<anonymous> (/Applications/Hyper.app/Contents/Resources/electron.asar/browser/api/web-contents.js:231:13)
    at emitTwo (events.js:106:13)
    at WebContents.emit (events.js:191:7)

If I quit Hyper and restart, it never comes up. I'm using Hyper <IP_ADDRESS>4 on macOS 10.12.5.

Apologies. My fault.


Use with monorepos

I have:
/traditional_repo
  file_1
/mono_repo
  file_2
  /packages
    /package
      file_3

Is it practical to configure workspaces.nvim so that:

file_1 belongs to traditional_repo,
file_2 belongs to mono_repo, and
file_3 belongs to package?

You could register traditional_repo mono_repo and package as separate workspaces with this plugin just fine. I'm not sure if that is what you are asking about though!

It is. But related to my other issue, this is something I'd want to control manually.
Also, by default, would file_3 then belong to two workspaces? (mono_repo and package)

Yes file_3 would be in two separate workspaces. All a workspace does is allow you to set the working directory of nvim


[Uk msgs] rm obsolete, correct, fix typo  [skip ci]

@Borales, @vchenin please ping me when it will be ready to be merged.

@samdark already done

@samdark this one is ready

https://github.com/yiisoft/yii2/commit/fc8ff4d08e6027057852152bcedb1c0059a38160 Thanks!


Landing page gradient gets banding on lower quality displays (think TN panel)

I'm not sure if there's much we can do about that but I would thought to raise an issue. Maybe tweaking the gradient curve a notch would make it less noticeable?

I think this will be moot if we move to the darker background as suggested by @patelsky. Once we update the color scheme I'd be happy to help make these changes.

Leaving this open until the landing page updates get done.

The banding is because grey is one of the hardest colors for monitors to reproduce correctly. Switching to a different color might help.

Closing as I believe this was fixed by the new background added in #374.


Missing fees

Hi @laroche,
I love this tool and also the information you compiled about german tax law. Thank you so much, it's really very useful! I was going mad trying to do this in Libre Office.
I have one question regarding the fees. Following the instructions, I downloaded the transaction history on the web site and combined all data in one file. The script runs and finishes successfully. But while the source data has a Fees column with valid values, they are not included in the Ordergebühren column, nor elsewhere.
For my Lynx account I always put the fees in the tax form to be deducted. So my question is - is this intentional?

Order fees are already deducted in the tax statement for each individual trade. Just the extra small cent payments are still kept separat and are not assigned to an individial trade. Original goal was to keep the tax statement small, but maybe I should add again more data and people can reduce again the output if wanted.
(So the trade price is already reduced by all order fees. Please let me know if this is not the case.)
best regards,
Florian La Roche

Yes, I can confirm the fees are processed correctly.
For my excel sheet I used the "2021 Year-to-Date Data Export" that can be downloaded in Account Management > My Account > Tax Center. This export has the fees already included in the COST and PROCEEDS columns.
I used the same currency data as you did.
The result is (almost) identical with that of your script. The end result differs by 0,04 EUR which is the result of rounding differences between the "2021 Year-to-Date Data Export" downloaded from Account Management versus the "Transaction History" downloaded from the web application.
So all good 🙂

Oh good. The tax report uses rounding with 2 digits and I can also see small rounding errors.
Without rounding I can use the numbers with 4 digit precision from Tastyworks and even with 4 years of
data, then end cash result is exactly the same without a cent difference between the script calculations
and comparing the end cash result with the cash sum reported by Tastyworks.
best regards,
Florian La Roche

Oh, you're right, the transaction history does have 4 digit precision. So that makes sense too.


Formatting Support ?

A feature that I deem useful and can be added in future versions if following the purpose of this library is the possibility of passing a formatting function to the field, for example:
sample.model
/*
 * An example data model
 */

Date created
Number id

String name {
  required true // this is a comment
  gt 2 "Must be greater than 2 characters"
  lte 256 "Must be less than or equal to 256 characters"
  formatter  (str)=> str.toUpperCase()
}

String bio "A bio must be a string" {
  lte 140 "A bio must fit into a tweet"
}

Boolean accountType
}

index.js
const Models = require('node-dml')

let model = Models.compile(fs.readFileSync('sample.model', 'utf8'))

let result = model({
  id: 1337,
  created: new Date(),
  name: 'Glen Danzig',
  accountType: 'awesome'
})

Output
{
  data: {
    id: 1337,
    created: '2016-10-02T13:56:44.931Z',
    name: 'GLEN DANZIG', // Formatted in uppercase
    accountType: 'awesome'
  },
  length: 1,
  rules: {
    accountType: [{
      validator: 'type',
      message: 'Expected type [Boolean] but got type [String]'
    }]
  }
}

I like that idea, a pull request would certainly be welcome. It might be tough to find the end of the javascript or parse properly. Another option though, is adding a plugin system, which could be pretty cool. then we could npm install various advanced validators. i had something like this in the back of my mind while i was originally writing this version. this code might help make a plugin system reasonable to implement.

Perfect I'll study your code and see how it works in the background because to be honest I got lost sometimes in it and as much as possible I can check which better option the plugin or add directly to the lib

How did you imagine this system of plugins ?


duplicate enum options

kiota generate --language csharp --openapi https://api.apis.guru/v2/specs/github.com/api.github.com/1.1.4/openapi.json --output './it/csharp/client' --namespace-name 'app.client' -e '/gists' -e '/gists/**' -e '/users/*/gists' -e '/orgs/*/migrations' -e '/orgs/*/migrations/**' -e '/user/migrations' -e '/user/migrations/**' -e '/users/*/gpg_keys' -e '/user/gpg_keys' -e '/user/gpg_keys/**' results in a duplicate entry for reaction_content enum. This is most likely because of the plus and minus signs being stripped when removing special characters

Issue still occuring with Stripe schema - https://github.com/microsoft/kiota/actions/runs/5579540569/jobs/10214588831?pr=2870


Allow Windows Daemonset resource to be created conditionally

#250 was raised as we don't have any need for the Windows Daemonset in our cluster and we would like the option to disable it.
This PR allows it to be disabled via a new customisation option - windowsDaemonset.enabled - defaulting to true for backwards compatibility. In our use case, we can set this to false and not have support for Windows enabled as we don't use it.
The exclude paths helper for Windows is also wrapped in this to allow this to be optional.
I proposed this change to be a patch change as it doesn't change any behaviour unless you explicitly choose to turn off the daemonset, but I am happy to make it a minor change if that is deemed more appropriate.

Thank you for your contribution @chriskurzeja ! We'll review it in the next couple of days :)


[Feature Request] - GPT-Researcher

I think this Tool would be a great addition to LocalAI
:)
It can be configured to use a local LLM and any search engine.
GPT Researcher is an autonomous agent designed for comprehensive online research on a variety of tasks.
The agent can produce detailed, factual and unbiased research reports, with customization options for focusing on relevant resources, outlines, and lessons. Inspired by the recent Plan-and-Solve and RAG papers, GPT Researcher addresses issues of speed, determinism and reliability, offering a more stable performance and increased speed through parallelized agent work, as opposed to synchronous operations.
https://github.com/assafelovic/gpt-researcher

I expect that this is not within the scope of the localai project.
GPT-Researcher it appears can be configured already to make use of self hosted models so this would just be a matter of configuration.
There is usually an OPENAI_BASE_URL variable that can be set to http://localhost:8080/v1 (or the like) in these apps, you can set the api key to dummy and that should work. if you have 'model' issues like i did for chat-dev the workaround is to find the name of the model that the tool is using aka gpt-3.5-turbo-1106 and change the name of the model you want to use in the .yaml file and that should satisfy the tool.
be aware that response time for api queries is also often limited to 60s for these sorts of tools, this should be configurable within the tools source


Don't build for nightly Python 3.7

Since we can't easily get packages of confluent-kafka for nightly Python 3.7.

 Thank you for your submission, we really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.


Random freezes when debugging code-oss using VS Code

I started getting many freezes while debugging code-oss (F5) from our sources, using VS Code. Never saw this before I went on vacation (Dec 10) and I hit this at least 5x per day now. Could be related to Electron 7 update.
The only way I've found to get out of the situation is to run killall code-oss on a terminal twice. The first call is a no-op.
I'm on Linux btw. I haven't found reliable repro steps.
cc @JacksonKearl @aeschli @connor4312 @bpasero

Reliable repro for me on MacOS Mojave:

In Insiders, open vscode repo and run "Launch VS Code" (build step running somewhere in background)
In the spawned window, navigate to the vscode repo.
Reload a couple times. For me, the window freezes on the second reload very reliably.

I haven't been able to repro on any workspace besides vscode. I've tried empty workspaces, small, and chromium. One thing I have noticed is that if I reload in some other workspace a few times, then open vscode, it will either freeze instantly on open, or after only a single reload instead of the usual two.

Given this, should we remove the electron-7-update label to not confuse this with a Electron 7 related issue?

@bpasero I haven't seen this at all since we reverted back to Electron 6.

Not sure if changes have been pushed, but this has been a consistent issue for me across both code and code insiders, installed via snap.

@JacksonKearl can you give more instructions what you do that leads to the freeze? Are you using pwa-debug?
@joaomoreno curious if you also see these freezes if you are NOT using VSCode from Snap.

@bpasero I actually haven't had a single freeze since we moved forward to 7 again. Also, not using new debugger.

Ok then I suggest we wait for feedback from @JacksonKearl and then close this one.

My previous repro no longer repros for me. I'll open a new issue if I get caught again.


WorkloadEntry to support healthStatus and ServiceEntry will exclude Unhealthy WLEs

(This is used to request new product features, please visit https://discuss.istio.io for questions on using Istio)
This is related with https://github.com/istio/istio/issues/36865
Introduce a new spec filed healthStatus in WLE and Healthy/Unknown ones will be selected by SE. For backward compatible, default will be Unknown and only Unhealthy WLEs will not be selected.
apiVersion: networking.istio.io/v1alpha3
kind: WorkloadEntry
metadata:
  name: details-svc
spec:
  serviceAccount: details-legacy
  address: <IP_ADDRESS>
  healthStatus: Healthy/Unknown/Unhealthy
  labels:
    app: details-legacy

According the upstream doc, WorkloadEntry enables operators to describe the properties of a single non-Kubernetes workload such as a VM or a bare metal server as it is onboarded into the mesh, which means WLE actually turns the non-Kubernetes VMs into a Pod.
In k8s, we have below resources correlated:
Service ---> Endpoint ----> Pod

Since there is readinessProbe in Endpoint,  Istio discovery service will eventually discover the healthy pods since they will be in not ready addresses in Endpoint, which means the pod readiness status will eventually be reflected to the Envoy LbEndpoint in the upstream cluster.
And Istio introduced few other CRDs to represent the non-k8s workloads:
ServiceEntry ---> WorkloadGroup ---> WorkloadEntry

However currently if the WorkloadEntry is down, there is no such mechanism to unselect that WLE from the SE since there is no such field to store the healthStatus info and suppose this is a very common request for the WLE traffic management.
Although there is ReadinessProbe in WorkloadGroup, it doesn't work as k8s which is the kubelet to do the readinessProbe against Pod and populate the status to Endpoint and the readinessProbe is coupled with WorkloadGroup so we won't be able to on demand mark down a WLE.
Describe alternatives you've considered
Affected product area (please put an X in all that apply)
[ ] Docs
[ ] Installation
[ ] Networking
[ ] Performance and Scalability
[ ] Extensions and Telemetry
[ ] Security
[ ] Test and Release
[ ] User Experience
[ ] Developer Infrastructure
Affected features (please put an X in all that apply)
[ ] Multi Cluster
[ ] Virtual Machine
[ ] Multi Control Plane
Additional context

Although there is ReadinessProbe in WorkloadGroup, it doesn't work as k8s which is the kubelet to do the readinessProbe against Pod and populate the status to Endpoint and the readinessProbe is coupled with WorkloadGroup so we won't be able to on demand mark down a WLE.

I don't understand how this is different from Pods. In Pod, kubelet does readiness probe and marks it as unhealthy. A user cannot explicitly trigger 'unhealthy' other than making it fail the probe.
In WE, istio-agent does readiness probe and marks it as unhealthy. A user cannot explicitly trigger 'unhealthy' other than making it fail the probe.
So what is the difference? Why is this needed for WE but not Pod?

@howardjohn  One significant difference is for the k8s service without selector, we can have external readiness probe/controller to maintain the healthy and unhealthy addresses, so the service/endpoint is decoupled with the readiness probe and fully leverage on the ip address health status in the endpoint and only the ready addresses will take traffic. With this design, we'll have the flexibility to manage the addresses and endpoint, we can either fail the readiness probe or just change the address to not ready without actually deleting it. However we don't have that capability/flexibility with WLE and SE.
In another word, the requirement here is to enable SE to only select healthy WLE and doesn't matter if there is readiness probe or not, just like the k8s Service without selector to only select ready addresses.

@howardjohn  Sorry for late reply.
The consideration for using WLE instead of Endpoint is because the semantic of WLE is to represent non-k8s workloads, it could be VM or VIP which is exactly our case.
From spec perspective, we would like to capture the intention to not send traffic to a specific endpoint, it could be vm/vip and there are two options like I mentioned in another issue:

Support to set the WLE weight to be really 0 which means istiod will either mark that endpoint as unhealthy or just delete it from envoy cluster.
Introduce a new filed healthStatus in WLE spec which will mark the LbEndpoint to be not healthy, just like the not ready addresses in k8s Endpoint.

Both options will work for us. Deleting the WLE is a workaround to achieve this but the intention of delete and disable is different.

What I still don't understand is:
1, Why does existing health mechanism on WE not satisfying use case
2. Given pod does not enable this, and WE is equivalent to Pod, why is this needed? You said you already manage this with a Service without selector for Pod - why not just do that for WE?

@howardjohn

1, Why does existing health mechanism on WE not satisfying use case

Exiting health mechanism is the active health through istio-agent for pod as I went through the BP Virtual Machine Health Checking. However our case the WLE represents a VIP, it could be a hardware LB VIP or software LB(IPVS) VIP, for that case there is no istio-agent to do the health check.  Another requirement is that, even if we can have another external controller to monitor the WLE health status,  there is a scenario that we want to do VIP exit even if it's healthy for the region exit case.

Given pod does not enable this, and WE is equivalent to Pod, why is this needed? You said you already manage this with a Service without selector for Pod - why not just do that for WE?

As I mentioned, it's VIP in our case and we'd like to decouple the HC with istio-agent. And actually there are two use cases:

Active health check against the VIP,  we can refer to Contour's design https://projectcontour.io/docs/v1.10.0/config/health-checks/ which works better for VIP case.
On demand disable an Endpoint(WLE/VIP) to exit traffic no matter it's healthy or not. If we can't introduce the healthStatus in WLE spec, we are going to put the intention into an annotation and istiod need to mark the corresponding LbEndpoint as unhealthy based on this annotation. If we make this change, can we contribute it back to upstream?

      - apiVersion: networking.istio.io/v1beta1
        kind: WorkloadEntry
        metadata:
           annotations:
             traffic.network.istio.io/disablePorts: 80,443 or * for all ports
          creationTimestamp: null
          name: https-foo-we
        spec:
          address: foo-az01.example.com
          labels:
            app: foo
          weight: 50
          Locality: region01/az01
        status: {}

For case 1 I don't mean using Istio-agent to do health checks I mean to set the Healthy status condition your self. We already have one way to represent health so I do not want to have two.

For case 1 I don't mean using Istio-agent to do health checks I mean to set the Healthy status condition your self. We already have one way to represent health so I do not want to have two.

I see, then it works for case #1 and still need to put the annotation WorkloadEntryHealthCheckAnnotation to WLE and manually update the WLE status but actually no readinessProbe.
// isHealthy checks that the provided WorkloadEntry is healthy. If health checks are not enabled,
// it is assumed to always be healthy
func isHealthy(cfg config.Config) bool {
	if parseHealthAnnotation(cfg.Annotations[status.WorkloadEntryHealthCheckAnnotation]) {
		// We default to false if the condition is not set. This ensures newly created WorkloadEntries
		// are treated as unhealthy until we prove they are healthy by probe success.
		return status.GetBoolConditionFromSpec(cfg, status.ConditionHealthy, false)
	}
	// If health check is not enabled, assume its healthy
	return true
}

And there is still another issue to address, how to disable WLE on specific port and capture the disabled result into WLE status? The port information is in SE and currently there is no port information in WLE status.

If you want to disable on a specific port I would encourage you to make multiple distinct WE for each port. Having a per-port status is likely not something that generalizes beyond your use case so it would be hard to fit into the api

If you want to disable on a specific port I would encourage you to make multiple distinct WE for each port. Having a per-port status is likely not something that generalizes beyond your use case so it would be hard to fit into the api

I just tried out to disable the WLE:
apiVersion: networking.istio.io/v1beta1
kind: WorkloadEntry
metadata:
  annotations:
    proxy.istio.io/health-checks-enabled: "true"
  name: foo
  namespace: foo-ns
spec:
  address: <IP_ADDRESS>
  labels:
    app: foo
  locality: region01/az01
  weight: 50
status:
  conditions:
  - lastProbeTime: "2019-12-26T22:06:34Z"
    lastTransitionTime: "2019-12-26T22:06:34Z"
    message: 'Code 500: VIP Unhealthy'
    reason: unhealthy
    status: "False"
    type: Healthy

Before add the annotation/status:
istioctl pc endpoint -n isito-staging istio-ingressgateway-6cbc9779fc-422kw.istio-staging | grep foo
<IP_ADDRESS>:8082               HEALTHY     OK                outbound|18080||foo.example.com
<IP_ADDRESS>:8082               HEALTHY     OK                outbound|8082||foo.example.com
<IP_ADDRESS>:8082               HEALTHY     OK                outbound|18080||foo.example.com
<IP_ADDRESS>:8082               HEALTHY     OK                outbound|8082||foo.example.com

After add the annotation/status:
istioctl pc endpoint -n isito-staging istio-ingressgateway-6cbc9779fc-422kw.istio-staging | grep foo
<IP_ADDRESS>:8082               HEALTHY     OK                outbound|18080||foo.example.com
<IP_ADDRESS>:8082               HEALTHY     OK                outbound|8082||foo.example.com

We can see the <IP_ADDRESS> WLE got removed from the endpoint with both port 8082/18080. BTW here is the SE spec:
- apiVersion: networking.istio.io/v1beta1
  kind: ServiceEntry
  metadata:
    creationTimestamp: null
    name: foo
  spec:
    hosts:
    - foo.example.com
    ports:
    - name: http-8080
      number: 18080
      protocol: HTTP
    - name: https-8082
      number: 8082
      protocol: HTTPS
    resolution: DNS
    workloadSelector:
      labels:
        app: foo
  status: {}

This is very close to what we need and the only concern is that we are not able to disable WLE at port level since by default it applies for all ports.
Create multiple WLE for each port is a workaround but we'll also need to create multiple SE to select the WLE and it will significantly increase the SE/WLE object number, considering we could have thousands of WLE it might also case performance issue.
Shall we introduce the annotation traffic.network.istio.io/disablePorts: 80,443 or * for all ports in WLE to only disable specific port?  For example if we only disable 8082 for <IP_ADDRESS>,  the expected output is:
istioctl pc endpoint -n isito-staging istio-ingressgateway-6cbc9779fc-422kw.istio-staging | grep foo
<IP_ADDRESS>:8082               HEALTHY     OK                outbound|18080||foo.example.com
<IP_ADDRESS>:8082               HEALTHY     OK                outbound|18080||foo.example.com
<IP_ADDRESS>:8082               HEALTHY     OK                outbound|8082||foo.example.com

I went through the code and the change is servicediscovery to honor the WLE annotation traffic.network.istio.io/disablePorts: 80,443 or * for all ports and delete the corresponding ServiceInstance with the port:
https://github.com/istio/istio/blob/release-1.12/pilot/pkg/serviceregistry/serviceentry/servicediscovery.go#L229.
Through this way we can avoid creating duplicated SE/WLE per port and also support to disable WEL at port level.

Ah I thought you could do this:
apiVersion: networking.istio.io/v1beta1
kind: ServiceEntry
metadata:
  creationTimestamp: null
  name: foo
spec:
  hosts:
  - foo.example.com
  ports:
  - name: http-8080
    number: 18080
    protocol: HTTP
  - name: https-8082
    number: 8082
    protocol: HTTPS
  resolution: DNS
  workloadSelector:
    labels:
      app: foo
---
apiVersion: networking.istio.io/v1beta1
kind: WorkloadEntry
metadata:
  name: foo-1
spec:
  ports:
    http-8080: 18081
  address: <IP_ADDRESS>
  labels:
    app: foo
  locality: region01/az01
  weight: 50

To make WE only apply to one port. But it does not.
I am not in favor of anything like disablePorts. Health is at the workload level, not the port level in Kubernetes and we are trying to mirror that.

Thanks @howardjohn . We'll take the approach to create SE/WLE per port for our case. BTW two more questions:

I tried out the ports in WLE http-8080: 18081 and after I added the port map, data plane is not working. Looks like there is a bug?
The annotation proxy.istio.io/health-checks-enabled: "true" was introduced for VM health check through pilot agent, I wonder how can we support active health check for VIP case?  Will your previous commit help for that case:  https://github.com/howardjohn/istio/commit/4519a02e05cdd242cca7f4b53f7053b7489e88d2. Or just leverage EnvoyFilter for that case？


what is the difference between APT(ICM) and APT(IND)?

how can I reproduce the result of APT in the paper? Thx~

Same question here


React package stability improvements

[ ] Address github issues and discussions
[ ] More tests for hook composition
[ ] Implement contract abi type completion with wagmi
[ ] Address incorrect type issues

No longer relevant as we are using wagmi


Fixed for empty alt value in react-a11y-img-has-alt rule.

For img element,it must has alt attribute, empty alt must has role='presentation' and non-empty alt must has no role='presentation'.

Hi @t-ligu, I'm your friendly neighborhood Microsoft Pull Request Bot (You can call me MSBOT). Thanks for your contribution!

It looks like you're a Microsoft contributor (Liubin Guo). If you're full-time, we DON'T require a Contribution License Agreement. If you are a vendor, please DO sign the electronic Contribution License Agreement. It will take 2 minutes and there's no faxing! https://cla.microsoft.com.

TTYL, MSBOT;


Remove some useless BufReader wrappers around stdin

This fixes #1103, but only in part.
I’m willing to remove the other useless BufReader wrappers, but I am too much of a Rust newbie to know how to do that properly. I need some help.
In, for instance, base32.rs, it’d be easy to do:
     let input = if matches.free.is_empty() || &matches.free[0][..] == "-" {
-        BufReader::new(Box::new(stdin()) as Box<Read>)
+        Box::new(stdin()) as Box<Read>
     } else {
         let path = Path::new(matches.free[0].as_str());
         let file_buf = safe_unwrap!(File::open(&path));
-        BufReader::new(Box::new(file_buf) as Box<Read>)
+        Box::new(BufReader::new(file_buf))
     };

This compiles. But then some repetitive hence excessive mutex locking/unlocking is going to take place.
base32.rs delegates to decode()/encode() in encoding.rs. There, read_to_end() is called.
If I understand https://doc.rust-lang.org/src/std/io/mod.rs.html#365-394 correctly, read_to_end()
calls read(), potentially several times. And each time, the mutex has to be taken then released.

Ugly is one thing, losing the fight with the borrow checker is another.
Take cat.rs. It does not explicitely lock either (but it should). But then if you do:
     if path == "-" {
         let stdin = stdin();
         return Ok(InputHandle {
-            reader: Box::new(stdin) as Box<Read>,
+            reader: Box::new(stdin.lock()) as Box<Read>,
             is_interactive: is_stdin_interactive(),
         });
     }

The compiler is not happy, and I don’t know to please it.
Maybe it’d be better just to wait for non-lexical lifetimes to be implemented?
See https://github.com/rust-lang/rust/issues/33520 https://github.com/rust-lang/rfcs/issues/811 https://github.com/rust-lang/rust/issues/43234
Please let me know what you think.

One way to fix the base32 issue would be to make a generic function that takes something implementing Read and then just moving the rest of the stuff in uumain() into there.  Something like:
fn uumain(/* args */) -> /* return */ {
    // ... snip ...

    if matches.free.is_empty() || &matches.free[0][..] == "-" {
        let stdin_raw = stdin();
        do_stuff(stdin_raw.lock());
    } else {
        let path = Path::new(matches.free[0].as_str());
        let file_buf = safe_unwrap!(File::open(&path));
        do_stuff(BufReader::new(file_buf));
    }

    0
}

fn do_stuff<R: Read>(input: R) {
    // blah
}

Another way is what you suggested, which is also fine but requires allocation (the current code does too).
IIRC the problem with cat is that the open() stuff needs to be restructured to avoid the Box (if we can avoid the Box we can also fairly easily get it to work with locked stdin I believe).  You could maybe store the result of stdin() in the InputHandle struct like Option<Box<Stdin>> or something and then store the locked version of stdin in the struct as well, but that needs two allocations and is kind of hacky.
By the way, the issue you referenced will get closed if I merged this as-is, because you wrote "fixes" right next to the issue number, so it'd probably be better if you change the wording.

I have edited the original PR message so that you can merge it as-is, without closing #1103.
I won’t go further to resolve #1103.
You are right, in base32.rs, one can do:

    let is_decode = matches.opt_present("decode");
    let ignore_garbage = matches.opt_present("ignore-garbage");

    […]

     if matches.free.is_empty() || &matches.free[0][..] == "-" {
        let stdin = stdin();
        do_it(stdin.lock(), is_decode, ignore_garbage, line_wrap);
    } else {
        let path = Path::new(matches.free[0].as_str());
        let file_buf = safe_unwrap!(File::open(&path));
        do_it(BufReader::new(file_buf), is_decode, ignore_garbage, line_wrap);
    };

    […]

fn do_it<R: Read>(input: R, is_decode: bool, ignore_garbage: bool, line_wrap: usize) {
    let mut data = Data::new(input, Format::Base32);

    if is_decode {
        match data.ignore_garbage(ignore_garbage).decode() {
            Ok(s) => print!("{}", String::from_utf8(s).unwrap()),
            Err(_) => crash!(1, "invalid input"),
        }
    } else {
        wrap_print(line_wrap, data.encode());
    }
}

But then the same thing would have to be repeated in base64.rs. Or refactoring would have to take place.
The code of uucore/encoding.rs is only used by base{32,64}.rs, so refactoring sounds feasible. But investigating a little, several problems surface:

ignore_garbage is only used when decoding. On the other hand, line_wrap is only used when encoding. But encoding.rs forces them both to be filled, in its Data structure, no matter which “conversion” is going to take place.

Data::new() initializes such member to default values, only to have base{32,64}.rs overwrites them later (when they call Data::ignore_garbage() & Data::line_wrap()).

there is duplication of the 76 default value for the line wrap. There is also duplication of line_wrap in wrap_print().

etc.

uucore/encoding.rs goal, I guess, is to avoid DRY. Only it fails at that goal, and by the way makes execution inefficient and the codeflow hard-to-understand.  I am not willing to go further into this codebase conundrum.

I've combined the base32 and base64 code.  In terms of your first two points, any effect on performance would be negligible, and I assume the compiler will be able to optimize the default values out as they are never used.  The third point is reasonable as 76 should not be in both encoding.rs and the base32/base64 main functions.  The duplication of line_wrap is not much of an issue either, but I changed it anyway.

Oh, great! Thank you from all programmers that will have to touch this code in the future 😃
The main point was that the code was hard to follow. Performance was a minor concern, more like a side-effect (“the key to performance is elegance”).
Though if uutils/coreutils seriously aims at replacing the default coreutils, then efficiency is going to be of prime importance. Who is going to run a “memory-safe” base64/wc/&c. if it takes 30% more time (and/or 30% more memory) than the theorically unsafe, but battle-tested, alternative? Not me, at least. I already suffer way too much from software getting slower more rapidly than hardware gets faster.

I assume the compiler will be able to optimize the default values out as they are never used.

A quick look at the disassembly (cargo build --release -p base32 && objdump -M intel -d target/release/base32) validates your assumption 👍
But assuming that, in general, the compiler is sufficiently smart is hazardous. See e.g. http://proebsting.cs.arizona.edu/law.html https://cr.yp.to/talks/2015.04.16/slides-djb-20150416-a4.pdf


Problems since 6.58 running in linux terminal for PS5

Not working on PS5 btw. After 2 days.  It's actually quit-worthy. Game's and unplayable stuttery mess without this program.
I seen the opcodes posted somewhere but can anyone explain to me how in the hell I manually update opcodes when running it on a linux terminal?

make a python script, issue is i cant find the correct opcodes, the script is working with the old opcodes

i hate you all


dotnet.exe: remove support for packages.txt and instead specify packages in project file

This tool is superseded by dotnet-cli


Transactions and sessions

Really good initiative! Unfortunately in our case we need support for both transactions (sending messages within a TransactionScope) and sessions. Is this something you'll be implementing at some point?

Thanks! I do not know when I will have the time to look at this, but I understand that RabbitMQ does not support transactions and sessions. This means that to support transactions, we would have to implement ActiveMQ as a backend. The implementation is straightforward for most of it (replace RabbitMQ client library with ActiveMQ one), but it requires some time to write ;) I would be happy to assist if you are willing to contribute some code. Otherwise, I will let you know when and if I get to it myself ;)

not planned atm


Change directory to mudle path to be relative (External exports)

I had troubles including this project through cmake FetchContent_Declare functionality. It was not finding the path to the cmake modules. The change I propose fixes that but I am not a cmake specialist so not 100% sure it would not break something else.

I don't pretend to understand anything about cmake either, but this doesn't seem to cause any problems on my end.
Thank you for your contribution!


[WIP] Implementation of singleton pattern for Jobs

Fixes #1004
Done

Adds celery-singleton as a dependency
The value singleton = True can be set on the inner Meta class of a Job class to enable one and only one copy of that job being ran at any given time.
When calling JobResult.enqueue_job() now, the task_id from the Celery task if it is successfuly published is saved as the JobResult.job_id to creating a 1-to-1 mapping of Nautobot JobResult and Celery AsyncResult.
In the event that a singleton job is executed twice, subsequent attempts to run it will result in a DuplicateTaskError being raised from JobResult.enqueue_job(). This is handled in the JobView handling code to present a user-friendly error message back to the UI
New Celery tasks decorated with @nautobot_task may now optionally pass any extra arguments supported by celery-singleton, the most important of which will be on_unique=["foo", "bar"] where the argument are the names of arguments used to identify task uniqueness for the purpose of generating a idempotent hash key for the unique lock.
Added a new SingletonJob to dummy_plugin.jobs that can be used to test and demonstrate singleton jobs.
A custom subclass of celery_singleton.Singleton base task class has been added at nautobot.core.celery.task.NautobotTask that can conditionally behave as a base Celery Task or as a Singleton when apply_async is called using the really_singleton=True argument.
The Celery application now publishes its internal task_cls as NautobotTask making it the default Celery task class within Nautobot.
The specialized _dumps() method that gets registered with Kombu for the nautobot_json serializer can now take optional kwargs that get passed along to json.dumps() with the encoder.
settings.CELERY_SINGLETON_RAISE_ON_DUPLICATE = True has been set to always result in singleton tasks raising an exception as the default.

Not Done

API/CLI changes (if any)
Unit tests
Integration tests
Documentation

Screenshots
When you try to execute a singleton job multiple times while the initial job is running, you get an error like this in the UI

Looks really promising! For the base issue to be feature complete, I think we want to ensure that both the get_releases task and the pull_git_repository_and_refresh_data task are set up as singletons (with appropriate unique_on constraints). Is that within scope for this PR?

Yes in fact, and good test cases. Thanks for the suggestion.

This looks promising but I'm not sure if this is solving #1004
The initial request was to queue the additional Job and execute them one by one, not raise an exception.
The idea is that in some situation we don't control how the jobs are being created but we want to control how they are being executed etc ..
`

This looks promising but I'm not sure if this is solving #1004
The initial request was to queue the additional Job and execute them one by one, not raise an exception. The idea is that in some situation we don't control how the jobs are being created but we want to control how they are being executed etc ..
`

Yes, thanks, I'm with you! This problem has been quite challenging and I want to first get everything working.
Currently we consider a job to be unique if the args/kwargs are the same. Therefore two executions of the same job with differing arguments would still execute concurrently.
I'm looking into using task signals to prevent a worker from picking up a job in which certain uniqueness/concurrency constraints aren't met, but just not quite there yet.

Still no tests. This body of work has been... challenging.

@jathanism @glennmatthews @lampwins Does it make sense to move this to WIP and/or include this into the future road map?

@glennmatthews @jathanism Will this be done differently after #1411?

@glennmatthews @jathanism Will this be done differently after #1411?

Absolutely. It likely won't take much refactoring, but some will be required.

Closed. Tracking stale PRs in #2812.


App says no internet or slow internet once logged in

Happens on the emulator and on my galaxy note 8. On wifi and cell internet. I have plenty of mb/s, 200+. I don't know if it is the app, but my site works fine any other way when I access. Any help would be appreciated.
Chris

Thank you for letting me know this. I'll look into the issue ASAP.

Thank you for the quick response. I can send over logs or other information when I am back at my home office this evening if that will help at all. When I first access my site, everything flows through correctly. The first page is a login page. Once I have logged in, then I can see the first splash page no problem. I only encounter the error when I subsequently hit the continue page from that splash page and then I am introduced to the "feed" on my site. I think it has something to do with that, but I am not sure what to do because it works just fine when accessing from any where else.
I appreciate your help with this immensely.

Hi.
I just updated the repo., see if that works for you.
If I'm not wrong, the actual problem you were seeing was the second error handler onReceivedError I added for extra security. But it was causing more problem than helping.
Anyway, I ripped it now, update your project and let me know if it's working now.


Cannot read property 'randomBytes' of undefined

getting "Cannot read property 'randomBytes' of undefined"
I think you should mention that this library requires react-native-randombytes to work.
At least this is the case for me using RN 0.59
thanks

@gzcheng Please reopen if the issue still persists on the new version. 👍


Can't find any relevant tags file

This morning i rebuilt my ctags file and since then plugin is telling me "Can't find any relevant tags file".
I tough there is something wrong with tag file but it looks fine and I was despered enought to open the CTAGS python code and did some debug.
I have tags stored in one file. Ctags setings in file CTags.sublime-settings are:
{
	"extra_tag_files": [".gemtags", "tags","h:\\confidential\\cscope\\tags" ]
}

I have put some debug prints found out that function get_alternate_tags_paths responsible to find tags in extra files did not run at all.
I would appreciate any help or advice. Thank you.
I am using sublime 2

I believe my problem might be related to instaling python 3 the day before my problem occured.
I see some errors in console when sublime starts:
Reloading plugin C:\Users\jkoczman\AppData\Roaming\Sublime Text 2\Packages\CTags\test_ctags.py
Traceback (most recent call last):
  File ".\sublime_plugin.py", line 62, in reload_plugin
  File ".\test_ctags.py", line 14, in <module>
    import unittest2 as unittest
ImportError: No module named unittest2
Reloading plugin C:\Users\jkoczman\AppData\Roaming\Sublime Text 2\Packages\CTags\test_ctagsplugin.py
Traceback (most recent call last):
  File ".\sublime_plugin.py", line 62, in reload_plugin
  File ".\test_ctagsplugin.py", line 13, in <module>
    import unittest2 as unittest
ImportError: No module named unittest2

I have managed to get rid of errors from previous post by upgrading from sublime 2 to sublime 3.
However Ctags are still not working.

Heureka!
Long story short: Option extra_tag_files seem not to work at all for me and I had to put ".tags" files inside my project.
Looks like you cannot have .tags file in separate folder for example
C:\project
C:\tags\my_fag_file
Please can someone explain me how to achieve CTags plugin to work with my desired folder structure since it is standard in our company?

I'm having the same issue with "extra_tag_files" but I just started 5 minutes ago with this plugin. I had to change "tag_file" to "tags" (without dot) to find my tags file, while this is already in the "extra_tag_files" field by default.
Is the extra_tag_files not working at the moment or do I not understand it properly (Making it a documentation issue maybe)?

Looking at the code it seems to completely disregard the extra_tag_files in get_alternate_tags_paths() when the "(tags_file)_search_paths" file is not found. I've done a quick hack to make it work in my use case, but I'm not sure if it will break others. I could make a pull request if more people run in this issue.

Could you please share your fix?
 I just removed
ctagsplugin.py:241 "if os.path.exists(tags_paths):"
so it always uses the locations given in extra_tag_files.

I had to explicitly set "tag_file" : "tags" in my CTags.sublime-settings, the extra_tag_files setting appears to have no effect


NMSG replaced_by Science-Full-Reward

Suggest the new fork as an upgrade path.  I'm not sure if this is required or even recommended, but I figured I'll propose it and see what happens.

Sure, why not?


Added matrix field helper

Codecov Report
Attention: 89 lines in your changes are missing coverage. Please review.

Comparison is base (c3c0cba) 91.70% compared to head (219f8ea) 76.70%.

:exclamation: Your organization needs to install the Codecov GitHub app to enable full functionality.
Additional details and impacted files
@@              Coverage Diff              @@
##               main      #33       +/-   ##
=============================================
- Coverage     91.70%   76.70%   -15.00%
- Complexity      185      225       +40
=============================================
  Files            24       25        +1
  Lines           446      541       +95
=============================================
+ Hits            409      415        +6
- Misses           37      126       +89

Files
Coverage Δ

src/Registry/Registry.php
93.75% <0.00%> (-6.25%)
:arrow_down:

src/FieldHelper/MatrixFieldHelper.php
6.45% <6.45%> (ø)

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.


[Feature] add -sw presets for easy fallback to software volume

Add -sw presets for easy fallback to software volume.
For example, if there is a preset named "topping-d10" which specifies hardware volume control, create another preset "topping-d10-sw" without this feature.

Done already. That was intended for mpd-alsa-docker.


Fix advanced weapons being treated as simple instead of martial with certain feats

Fix for https://github.com/foundryvtt/pf2e/issues/16510

Hi there, this turned out to simply be a duplicate processing of "same-as" proficiencies.


Reverse Card Button Doesn't position correctly

Describe the bug
Not a big deal, but when you click the reverse button on the website, the screen goes blank.  You scroll back up and see the image is at the bottom.
Reproduction
https://flowbite-svelte.com/components/card
Flowbite version and System Info
Using Chrome

@jjagielka Can you have a look into this?

The idea of the reverse button is the flip the ordering of items inside a card. So it's as expected that with reverse={true} the image is at the bottom if Card is vertical, and at the right if Card is horizontal.
The blank screen is a bug though. Seems like this happens only in Chrome, as Firefox does not suffer from it.

This Chrome issue is the one already raised: #381 and it concerns as well Card, Alert and few others.

Can be closed.


Hit testing on default time app is returning wrong node.

https://bugs.fuchsia.dev/p/fuchsia/issues/detail?id=53053
/cc @dnfield

Customer is indicating bug still exists. Moving milestone out while we continue to investigate root cause.

Requested a minimal reproduction from customer.

Triage Update: There has been no progress on the reproducible test case.

I've pushed back on this issue to get a reproducible test case, as @dnfield and @iskakaushik indicated that they cannot reproduce this with the steps given due to target hardware/build instability. Leaving as a P1, as a11y is an important issue for the team right now, but there's nothing for the Flutter team to do with this at the moment.

Triage: Nothing to do as there is no reproducible test case.

@iskakaushik, when you get a moment, could you try the use case detailed as comment 21 on https://bugs.fuchsia.dev/p/fuchsia/issues/detail?id=53053 if you have running hardware and comment on the upstream issue? Thanks!

Triage: Still waiting for a reproducible test case. Reducing priority to match upstream prioritization.

Customer is reporting this is fixed upstream.

Suspicion is that the patch I landed that I thought fixed this did fix it, but that it had not rolled in yet last time there was testing.


Typescript need a standalone VM or native compiler. (like JDK or Clang)

I am learn and use type script for years.  thanks for your great works.
I hope typescript have it's own VM or native compiler.
From Typescript => VM running directly.
From Typescript => .exe or elf binaray executable
Gave us the power of TypeScript.  no other depends on.
Do not need nodejs. do not need gcc, clang, or what ever.
It can standalone, like CSharp. Donet .
The similar project  deno can make TypeScript serve a web app server. looks very impressive.
Hope TypeScript has the same ability.
Not just a paper language. (Depends on other tools, language,  vms)

Thanks for the issue, but this is pretty explicitly not a goal of TypeScript.
If it's something you're interested in, check out Static TypeScript which does this.


Artifact is now a typed goal

Instead of ArtifactGoal, Artifact is now a typed goal and self-registers the event handler that triggers the goal fulfillment

Also please fix title and description.

@cdupuis All comments resolved


Update list.json

hi, looks like the .abapgit.xml file is missing in the repository?

hi, looks like the .abapgit.xml file is missing in the repository?

@JackGraus

closing
feel free to open a new pull request when a LICENSE has been added


Fix missing event flags test-disable guards

Add defines to allow selective disabling of tests where they were
missing. Previously, several of the tests in the event flags testsuite
could not be disabled using the TC_TESTNAME_EN macros.

Many thanks for providing this fix!
Apparently CI is not working at the moment, but I've manually verified the changes and looks fine.


Speech Translation Evaluation: CoVoST 2

Idea: use ST as a zero-shot task to evaluate model understanding.

Issue: The current CoVoST 2 dataset on Huggingface is not easy to use. I'm creating a native version.
I'm excluding the train set due to its size at this point.
Code:
subsets = ['de_en', 'es_en', 'ca_en', 'it_en', 'ru_en', 'zh-CN_en', 'pt_en', 'fa_en', 'et_en', 'mn_en', 'nl_en', 'tr_en', 'ar_en', 'sv-SE_en', 'lv_en', 'sl_en', 'ta_en', 'ja_en', 'id_en', 'cy_en']

for subset in subsets:
    ds = datasets.load_dataset('facebook/covost2', subset, data_dir="/home/farzad/common_voice_4_en")
    del ds['train']
    ds.push_to_hub('fixie-ai/covost2', subset, token='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', num_shards={k: 8 for k in ds.keys()})


Roll engine 6c763bb551cb..d59b1583b035 (14 commits)

git@github.com:flutter/engine.git/compare/6c763bb551cb...d59b1583b035
git log 6c763bb551cb..d59b1583b035 --no-merges --oneline
2019-11-06<EMAIL_ADDRESS>Ensure that the device pixel ratio is taken into account with window metrics in physical pixels. (flutter/engine#13708)
2019-11-06<EMAIL_ADDRESS>Fix NPE in splash screen lookup (flutter/engine#13719)
2019-11-06<EMAIL_ADDRESS>Roll src/third_party/skia 6e54a299cce9..6790423f84ef (11 commits) (flutter/engine#13718)
2019-11-06<EMAIL_ADDRESS>Roll src/third_party/dart 24f1f313a2..462a448ac8 (2 commits)
2019-11-06<EMAIL_ADDRESS>Roll src/third_party/dart 80fc4d54e5..24f1f313a2 (5 commits)
2019-11-06<EMAIL_ADDRESS>Roll src/third_party/skia f00524707da7..6e54a299cce9 (1 commits) (flutter/engine#13715)
2019-11-06<EMAIL_ADDRESS>Roll fuchsia/sdk/core/mac-amd64 from bCFtP... to 6Du8E... (flutter/engine#13714)
2019-11-06<EMAIL_ADDRESS>Roll src/third_party/dart 51016532e8..80fc4d54e5 (2 commits)
2019-11-06<EMAIL_ADDRESS>Roll src/third_party/skia cdc0c23f1a2e..f00524707da7 (2 commits) (flutter/engine#13712)
2019-11-06<EMAIL_ADDRESS>Roll src/third_party/dart 8bdca37e98..51016532e8 (21 commits)
2019-11-06<EMAIL_ADDRESS>Roll src/third_party/skia f3d4109a793b..cdc0c23f1a2e (36 commits) (flutter/engine#13707)
2019-11-06<EMAIL_ADDRESS>Fix splash screen lookup. (#44131) (flutter/engine#13660)
2019-11-06<EMAIL_ADDRESS>Fix editing selection and deletion on macOS (flutter/engine#13702)
2019-11-06<EMAIL_ADDRESS>[web] Don't send keyboard events from text fields to flutter (flutter/engine#13699)
If this roll has caused a breakage, revert this CL and stop the roller
using the controls here:
https://autoroll.skia.org/r/flutter-engine-flutter-autoroll
Please CC<EMAIL_ADDRESS>on the revert to ensure that a human
is aware of the problem.
To report a problem with the AutoRoller itself, please file a bug:
https://bugs.chromium.org/p/skia/issues/entry?template=Autoroller+Bug
Documentation for the AutoRoller is here:
https://skia.googlesource.com/buildbot/+/master/autoroll/README.md

Trybots failed. These were the failed builds: https://cirrus-ci.com/task/5214094465957888 , https://cirrus-ci.com/task/6480731861155840

Commit queue failed; closing this roll.


Move io to free functions

This approach has a few advantages:

Less restrictive typing: send and recv can have different
message types.
Simpler registration and io access for hosts.
Opens the door for free functions that allow connecting and
accepting connections.

Did we ever setup CI?

Not yet. Do you have an example I can follow for how tokio repos do it?


unusual performance difference between http.client and python-requests

I originally asked question here, but maybe that's good place to ask as well.
I noticed unusual difference in performance between python-requests and http.client in Python 3.5.2. It puzzles me and I'm really curious what causes this. I have two code samples that do same thing in Python, and one of them (http.client) is significantly faster than other. Why is that?
http.client code:
import http.client

conn = http.client.HTTPConnection("localhost", port=8000)
for i in range(1000):
    conn.request("GET", "/")
    r1 = conn.getresponse()
    body = r1.read()
    print(r1.status)

conn.close()

python-requests
import requests

with requests.Session() as session:
    for i in range(1000):
        r = session.get("http://localhost:8000")
        print(r.status_code)

now if I run both of them, python-requests is always significantly slower.
On my machine client takes:
0.35user 0.10system 0:00.71elapsed 64%CPU

and python-requests:
1.76user 0.10system 0:02.17elapsed 85%CPU

I'm testing with python SimpleHTTPServer (python -m http.server).
Stack Overflow user suggests that performance difference is caused by python-requests not caching hostname lookups properly. I tried to verify this claim but I have not found reasons to support it. When I do cProfile and look at number of ncalls to socket.getaddrinfo I see that both code samples do same amount of calls to getaddrinfo.
# running http.client
~/p/p/requests (master) python -m cProfile cc.py | grep getaddrinfo
     1000    0.003    0.000    0.036    0.000 socket.py:715(getaddrinfo)
     1000    0.021    0.000    0.026    0.000 {built-in method _socket.getaddrinfo}
# running requests
requests ~/p/p/requests (master) python -m cProfile r.py | grep getaddrinfo                                                          09:18:00
     1000    0.003    0.000    0.040    0.000 socket.py:715(getaddrinfo)
     1000    0.026    0.000    0.030    0.000 {built-in method _socket.getaddrinfo}

for some reasons python-requests do spend more time in this function, but I'm not sure if this explains requests slowness.

Stack Overflow user suggests that performance difference is caused by python-requests not caching hostname lookups properly.

That would affect httplib just as much as it affects us. Given that we use httplib for our low-level HTTP, I'd be startled it if was caching hostname lookups and we weren't.
The reason Requests is slower is because it does substantially more than httplib. httplib can be thought of as the bottom layer of the stack: it does the low-level wrangling of sockets. Requests is two layers further up, and adds things like cookies, connection pooling, additional settings, and kinds of other fun things. This is necessarily going to slow things down. We simply have to compute a lot more than httplib does.
You can see this by looking at cProfile results for Requests: there's just way more result than there is for httplib. This is always to be expected with high-level libraries: they add more overhead because they have to do a lot more work.
While we can look at targetted performance improvements, the sheer height of the call stack in all cases is going to hurt our performance markedly. That means that the complaint that "requests is slower than httplib" is always going to be true: it's like complaining that "requests is slower than sending carefully crafted raw bytes down sockets." That's true, and it'll always be true: there's nothing we can do about that.


[rstream] - Accept three functions as arguments in subscribe

It would help with interop with standard Ecmascript observables if the subscribe function used in rstream accepted three functions, the first one for the next value, the second for error handling and the final one to indicate that it's done.  Do you think this would have much of a knock on effect?  Apart from this it looks pretty much compatible with the standard: https://github.com/tc39/proposal-observable

For now I'm wrapping it using this:
const wrapRStream = (s: ISubscribable<any>) => {
  return {
    subscribe: (next, error, done) => {
      const sub = s.subscribe({
        next,
        error,
        done
      });
      return sub;
    }
  };
};

Hey @allforabit - this sounds feasible & I agree that'd be a nice feature, but so far I know close to nothing about that TC39 proposal, so will first have to read up on it... give me a few days! :)

I'm thinking it's probably just as handy to use simple functions to go between observables and rstream so feel free to close this.
Maybe it'd be useful to include these snippets in the wiki to go between rstream and observables?
import { ISubscribable, stream } from<EMAIL_ADDRESS>
export const toObservable = (s: ISubscribable<any>) => {
  return {
    subscribe: (next, error, done) => {
      return s.subscribe({
        next,
        error,
        done
      });
    }
  };
};

export const fromObservable = obs =>
  stream(o => {
    obs.subscribe({
      next(v) {
        o.next(v);
      },
      error(e) {
        o.error(e);
      },
      complete() {
        o.done();
      }
    });
  });

I'm not really sure of the feasibility of making them compatible in any case as observables are expecting the subscribe function to receive the next, error and done callbacks and in rstream a function is assumed to be a transducer.

Closing in favour of https://github.com/thi-ng/umbrella/issues/246


Add provider contains method

Create branch: issue-22-add-provider-contains-method from develop.

Create branch: issue-22-add-provider-contains-method from develop.

Contains made using Entries dictionary.

Contains made using Entries dictionary.