cld2/internal/cld_generated_cjk_uni_prop_80.cc:7089:1: error: narrowing conversion of â-1â from âintâ to âCLD2::uint8 {aka unsigned char}â inside { } [-Wnarrowing]
    cld2/internal/cld_generated_cjk_uni_prop_80.cc:7089:1: error: narrowing conversion of â-12â from âintâ to âCLD2::uint8 {aka unsigned char}â inside { } [-Wnarrowing]
    cld2/internal/cld_generated_cjk_uni_prop_80.cc:7089:1: error: narrowing conversion of â-11â from âintâ to âCLD2::uint8 {aka unsigned char}â inside { } [-Wnarrowing]
    cld2/internal/cld_generated_cjk_uni_prop_80.cc:7089:1: error: narrowing conversion of â-10â from âintâ to âCLD2::uint8 {aka unsigned char}â inside { } [-Wnarrowing]
    cld2/internal/cld_generated_cjk_uni_prop_80.cc:7089:1: error: narrowing conversion of â-9â from âintâ to âCLD2::uint8 {aka unsigned char}â inside { } [-Wnarrowing]
    cld2/internal/cld_generated_cjk_uni_prop_80.cc:7089:1: error: narrowing conversion of â-8â from âintâ to âCLD2::uint8 {aka unsigned char}â inside { } [-Wnarrowing]
    cld2/internal/cld_generated_cjk_uni_prop_80.cc:7089:1: error: narrowing conversion of â-7â from âintâ to âCLD2::uint8 {aka unsigned char}â inside { } [-Wnarrowing]
    cld2/internal/cld_generated_cjk_uni_prop_80.cc:7089:1: error: narrowing conversion of â-6â from âintâ to âCLD2::uint8 {aka unsigned char}â inside { } [-Wnarrowing]
    cld2/internal/cld_generated_cjk_uni_prop_80.cc:7089:1: error: narrowing conversion of â-5â from âintâ to âCLD2::uint8 {aka unsigned char}â inside { } [-Wnarrowing]
    cld2/internal/cld_generated_cjk_uni_prop_80.cc:7089:1: error: narrowing conversion of â-4â from âintâ to âCLD2::uint8 {aka unsigned char}â inside { } [-Wnarrowing]
    cld2/internal/cld_generated_cjk_uni_prop_80.cc:7089:1: error: narrowing conversion of â-3â from âintâ to âCLD2::uint8 {aka unsigned char}â inside { } [-Wnarrowing]
    cld2/internal/cld_generated_cjk_uni_prop_80.cc:7089:1: error: narrowing conversion of â-2â from âintâ to âCLD2::uint8 {aka unsigned char}â inside { } [-Wnarrowing]
    cld2/internal/cld_generated_cjk_uni_prop_80.cc:7089:1: error: narrowing conversion of â-1â from âintâ to âCLD2::uint8 {aka unsigned char}â inside { } [-Wnarrowing]
    cld2/internal/cld_generated_cjk_uni_prop_80.cc:7089:1: error: narrowing conversion of â-11â from âintâ to âCLD2::uint8 {aka unsigned char}â inside { } [-Wnarrowing]
    cld2/internal/cld_generated_cjk_uni_prop_80.cc:7089:1: error: narrowing conversion of â-10â from âintâ to âCLD2::uint8 {aka unsigned char}â inside { } [-Wnarrowing]
    cld2/internal/cld_generated_cjk_uni_prop_80.cc:7089:1: error: narrowing conversion of â-9â from âintâ to âCLD2::uint8 {aka unsigned char}â inside { } [-Wnarrowing]
    cld2/internal/cld_generated_cjk_uni_prop_80.cc:7089:1: error: narrowing conversion of â-8â from âintâ to âCLD2::uint8 {aka unsigned char}â inside { } [-Wnarrowing]
    cld2/internal/cld_generated_cjk_uni_prop_80.cc:7089:1: error: narrowing conversion of â-7â from âintâ to âCLD2::uint8 {aka unsigned char}â inside { } [-Wnarrowing]
    cld2/internal/cld_generated_cjk_uni_prop_80.cc:7089:1: error: narrowing conversion of â-6â from âintâ to âCLD2::uint8 {aka unsigned char}â inside { } [-Wnarrowing]
    cld2/internal/cld_generated_cjk_uni_prop_80.cc:7089:1: error: narrowing conversion of â-5â from âintâ to âCLD2::uint8 {aka unsigned char}â inside { } [-Wnarrowing]
    cld2/internal/cld_generated_cjk_uni_prop_80.cc:7089:1: error: narrowing conversion of â-4â from âintâ to âCLD2::uint8 {aka unsigned char}â inside { } [-Wnarrowing]
    cld2/internal/cld_generated_cjk_uni_prop_80.cc:7089:1: error: narrowing conversion of â-3â from âintâ to âCLD2::uint8 {aka unsigned char}â inside { } [-Wnarrowing]
    cld2/internal/cld_generated_cjk_uni_prop_80.cc:7089:1: error: narrowing conversion of â-2â from âintâ to âCLD2::uint8 {aka unsigned char}â inside { } [-Wnarrowing]
    cld2/internal/cld_generated_cjk_uni_prop_80.cc:7089:1: error: narrowing conversion of â-1â from âintâ to âCLD2::uint8 {aka unsigned char}â inside { } [-Wnarrowing]
    cld2/internal/cld_generated_cjk_uni_prop_80.cc:7089:1: error: narrowing conversion of â-10â from âintâ to âCLD2::uint8 {aka unsigned char}â inside { } [-Wnarrowing]
    cld2/internal/cld_generated_cjk_uni_prop_80.cc:7089:1: error: narrowing conversion of â-9â from âintâ to âCLD2::uint8 {aka unsigned char}â inside { } [-Wnarrowing]
    cld2/internal/cld_generated_cjk_uni_prop_80.cc:7089:1: error: narrowing conversion of â-8â from âintâ to âCLD2::uint8 {aka unsigned char}â inside { } [-Wnarrowing]
    cld2/internal/cld_generated_cjk_uni_prop_80.cc:7089:1: error: narrowing conversion of â-7â from âintâ to âCLD2::uint8 {aka unsigned char}â inside { } [-Wnarrowing]
    cld2/internal/cld_generated_cjk_uni_prop_80.cc:7089:1: error: narrowing conversion of â-6â from âintâ to âCLD2::uint8 {aka unsigned char}â inside { } [-Wnarrowing]
    cld2/internal/cld_generated_cjk_uni_prop_80.cc:7089:1: error: narrowing conversion of â-5â from âintâ to âCLD2::uint8 {aka unsigned char}â inside { } [-Wnarrowing]
    cld2/internal/cld_generated_cjk_uni_prop_80.cc:7089:1: error: narrowing conversion of â-4â from âintâ to âCLD2::uint8 {aka unsigned char}â inside { } [-Wnarrowing]
    cld2/internal/cld_generated_cjk_uni_prop_80.cc:7089:1: error: narrowing conversion of â-3â from âintâ to âCLD2::uint8 {aka unsigned char}â inside { } [-Wnarrowing]
    cld2/internal/cld_generated_cjk_uni_prop_80.cc:7089:1: error: narrowing conversion of â-2â from âintâ to âCLD2::uint8 {aka unsigned char}â inside { } [-Wnarrowing]
    cld2/internal/cld_generated_cjk_uni_prop_80.cc:7089:1: error: narrowing conversion of â-1â from âintâ to âCLD2::uint8 {aka unsigned char}â inside { } [-Wnarrowing]
    cld2/internal/cld_generated_cjk_uni_prop_80.cc:7089:1: error: narrowing conversion of â-9â from âintâ to âCLD2::uint8 {aka unsigned char}â inside { } [-Wnarrowing]
    cld2/internal/cld_generated_cjk_uni_prop_80.cc:7089:1: error: narrowing conversion of â-8â from âintâ to âCLD2::uint8 {aka unsigned char}â inside { } [-Wnarrowing]
    cld2/internal/cld_generated_cjk_uni_prop_80.cc:7089:1: error: narrowing conversion of â-7â from âintâ to âCLD2::uint8 {aka unsigned char}â inside { } [-Wnarrowing]
    cld2/internal/cld_generated_cjk_uni_prop_80.cc:7089:1: error: narrowing conversion of â-6â from âintâ to âCLD2::uint8 {aka unsigned char}â inside { } [-Wnarrowing]
    cld2/internal/cld_generated_cjk_uni_prop_80.cc:7089:1: error: narrowing conversion of â-5â from âintâ to âCLD2::uint8 {aka unsigned char}â inside { } [-Wnarrowing]
    cld2/internal/cld_generated_cjk_uni_prop_80.cc:7089:1: error: narrowing conversion of â-4â from âintâ to âCLD2::uint8 {aka unsigned char}â inside { } [-Wnarrowing]
    cld2/internal/cld_generated_cjk_uni_prop_80.cc:7089:1: error: narrowing conversion of â-3â from âintâ to âCLD2::uint8 {aka unsigned char}â inside { } [-Wnarrowing]
    cld2/internal/cld_generated_cjk_uni_prop_80.cc:7089:1: error: narrowing conversion of â-2â from âintâ to âCLD2::uint8 {aka unsigned char}â inside { } [-Wnarrowing]
    cld2/internal/cld_generated_cjk_uni_prop_80.cc:7089:1: error: narrowing conversion of â-1â from âintâ to âCLD2::uint8 {aka unsigned char}â inside { } [-Wnarrowing]
    cld2/internal/cld_generated_cjk_uni_prop_80.cc:7089:1: error: narrowing conversion of â-8â from âintâ to âCLD2::uint8 {aka unsigned char}â inside { } [-Wnarrowing]
    cld2/internal/cld_generated_cjk_uni_prop_80.cc:7089:1: error: narrowing conversion of â-7â from âintâ to âCLD2::uint8 {aka unsigned char}â inside { } [-Wnarrowing]
    cld2/internal/cld_generated_cjk_uni_prop_80.cc:7089:1: error: narrowing conversion of â-6â from âintâ to âCLD2::uint8 {aka unsigned char}â inside { } [-Wnarrowing]
    cld2/internal/cld_generated_cjk_uni_prop_80.cc:7089:1: error: narrowing conversion of â-5â from âintâ to âCLD2::uint8 {aka unsigned char}â inside { } [-Wnarrowing]
    cld2/internal/cld_generated_cjk_uni_prop_80.cc:7089:1: error: narrowing conversion of â-4â from âintâ to âCLD2::uint8 {aka unsigned char}â inside { } [-Wnarrowing]
    cld2/internal/cld_generated_cjk_uni_prop_80.cc:7089:1: error: narrowing conversion of â-3â from âintâ to âCLD2::uint8 {aka unsigned char}â inside { } [-Wnarrowing]
    cld2/internal/cld_generated_cjk_uni_prop_80.cc:7089:1: error: narrowing conversion of â-2â from âintâ to âCLD2::uint8 {aka unsigned char}â inside { } [-Wnarrowing]
    cld2/internal/cld_generated_cjk_uni_prop_80.cc:7089:1: error: narrowing conversion of â-1â from âintâ to âCLD2::uint8 {aka unsigned char}â inside { } [-Wnarrowing]
    cld2/internal/cld_generated_cjk_uni_prop_80.cc:7089:1: error: narrowing conversion of â-7â from âintâ to âCLD2::uint8 {aka unsigned char}â inside { } [-Wnarrowing]
    cld2/internal/cld_generated_cjk_uni_prop_80.cc:7089:1: error: narrowing conversion of â-6â from âintâ to âCLD2::uint8 {aka unsigned char}â inside { } [-Wnarrowing]
    cld2/internal/cld_generated_cjk_uni_prop_80.cc:7089:1: error: narrowing conversion of â-5â from âintâ to âCLD2::uint8 {aka unsigned char}â inside { } [-Wnarrowing]
    cld2/internal/cld_generated_cjk_uni_prop_80.cc:7089:1: error: narrowing conversion of â-4â from âintâ to âCLD2::uint8 {aka unsigned char}â inside { } [-Wnarrowing]
    cld2/internal/cld_generated_cjk_uni_prop_80.cc:7089:1: error: narrowing conversion of â-3â from âintâ to âCLD2::uint8 {aka unsigned char}â inside { } [-Wnarrowing]
    cld2/internal/cld_generated_cjk_uni_prop_80.cc:7089:1: error: narrowing conversion of â-2â from âintâ to âCLD2::uint8 {aka unsigned char}â inside { } [-Wnarrowing]
    cld2/internal/cld_generated_cjk_uni_prop_80.cc:7089:1: error: narrowing conversion of â-1â from âintâ to âCLD2::uint8 {aka unsigned char}â inside { } [-Wnarrowing]
    cld2/internal/cld_generated_cjk_uni_prop_80.cc:7089:1: error: narrowing conversion of â-9â from âintâ to âCLD2::uint8 {aka unsigned char}â inside { } [-Wnarrowing]
    cld2/internal/cld_generated_cjk_uni_prop_80.cc:7089:1: error: narrowing conversion of â-9â from âintâ to âCLD2::uint8 {aka unsigned char}â inside { } [-Wnarrowing]
    cld2/internal/cld_generated_cjk_uni_prop_80.cc:7089:1: error: narrowing conversion of â-9â from âintâ to âCLD2::uint8 {aka unsigned char}â inside { } [-Wnarrowing]
    cld2/internal/cld_generated_cjk_uni_prop_80.cc:7089:1: error: narrowing conversion of â-9â from âintâ to âCLD2::uint8 {aka unsigned char}â inside { } [-Wnarrowing]
    cld2/internal/cld_generated_cjk_uni_prop_80.cc:7089:1: error: narrowing conversion of â-9â from âintâ to âCLD2::uint8 {aka unsigned char}â inside { } [-Wnarrowing]
    cld2/internal/cld_generated_cjk_uni_prop_80.cc:7089:1: error: narrowing conversion of â-9â from âintâ to âCLD2::uint8 {aka unsigned char}â inside { } [-Wnarrowing]
    cld2/internal/cld_generated_cjk_uni_prop_80.cc:7089:1: error: narrowing conversion of â-9â from âintâ to âCLD2::uint8 {aka unsigned char}â inside { } [-Wnarrowing]
    cld2/internal/cld_generated_cjk_uni_prop_80.cc:7089:1: error: narrowing conversion of â-9â from âintâ to âCLD2::uint8 {aka unsigned char}â inside { } [-Wnarrowing]
    cld2/internal/cld_generated_cjk_uni_prop_80.cc:7089:1: error: narrowing conversion of â-9â from âintâ to âCLD2::uint8 {aka unsigned char}â inside { } [-Wnarrowing]
    cld2/internal/cld_generated_cjk_uni_prop_80.cc:7089:1: error: narrowing conversion of â-9â from âintâ to âCLD2::uint8 {aka unsigned char}â inside { } [-Wnarrowing]
    cld2/internal/cld_generated_cjk_uni_prop_80.cc:7089:1: error: narrowing conversion of â-9â from âintâ to âCLD2::uint8 {aka unsigned char}â inside { } [-Wnarrowing]
    cld2/internal/cld_generated_cjk_uni_prop_80.cc:7089:1: error: narrowing conversion of â-9â from âintâ to âCLD2::uint8 {aka unsigned char}â inside { } [-Wnarrowing]
    cld2/internal/cld_generated_cjk_uni_prop_80.cc:7089:1: error: narrowing conversion of â-9â from âintâ to âCLD2::uint8 {aka unsigned char}â inside { } [-Wnarrowing]
    cld2/internal/cld_generated_cjk_uni_prop_80.cc:7089:1: error: narrowing conversion of â-9â from âintâ to âCLD2::uint8 {aka unsigned char}â inside { } [-Wnarrowing]
    cld2/internal/cld_generated_cjk_uni_prop_80.cc:7089:1: error: narrowing conversion of â-9â from âintâ to âCLD2::uint8 {aka unsigned char}â inside { } [-Wnarrowing]
    cld2/internal/cld_generated_cjk_uni_prop_80.cc:7089:1: error: narrowing conversion of â-9â from âintâ to âCLD2::uint8 {aka unsigned char}â inside { } [-Wnarrowing]
    cld2/internal/cld_generated_cjk_uni_prop_80.cc:7089:1: error: narrowing conversion of â-9â from âintâ to âCLD2::uint8 {aka unsigned char}â inside { } [-Wnarrowing]
    cld2/internal/cld_generated_cjk_uni_prop_80.cc:7089:1: error: narrowing conversion of â-9â from âintâ to âCLD2::uint8 {aka unsigned char}â inside { } [-Wnarrowing]
    cld2/internal/cld_generated_cjk_uni_prop_80.cc:7089:1: error: narrowing conversion of â-9â from âintâ to âCLD2::uint8 {aka unsigned char}â inside { } [-Wnarrowing]
    cld2/internal/cld_generated_cjk_uni_prop_80.cc:7089:1: error: narrowing conversion of â-9â from âintâ to âCLD2::uint8 {aka unsigned char}â inside { } [-Wnarrowing]
    cld2/internal/cld_generated_cjk_uni_prop_80.cc:7089:1: error: narrowing conversion of â-9â from âintâ to âCLD2::uint8 {aka unsigned char}â inside { } [-Wnarrowing]
    cld2/internal/cld_generated_cjk_uni_prop_80.cc:7089:1: error: narrowing conversion of â-9â from âintâ to âCLD2::uint8 {aka unsigned char}â inside { } [-Wnarrowing]
    cld2/internal/cld_generated_cjk_uni_prop_80.cc:7089:1: error: narrowing conversion of â-9â from âintâ to âCLD2::uint8 {aka unsigned char}â inside { } [-Wnarrowing]
    cld2/internal/cld_generated_cjk_uni_prop_80.cc:7089:1: error: narrowing conversion of â-9â from âintâ to âCLD2::uint8 {aka unsigned char}â inside { } [-Wnarrowing]
    cld2/internal/cld_generated_cjk_uni_prop_80.cc:7089:1: error: narrowing conversion of â-9â from âintâ to âCLD2::uint8 {aka unsigned char}â inside { } [-Wnarrowing]
    cld2/internal/cld_generated_cjk_uni_prop_80.cc:7089:1: error: narrowing conversion of â-9â from âintâ to âCLD2::uint8 {aka unsigned char}â inside { } [-Wnarrowing]
    cld2/internal/cld_generated_cjk_uni_prop_80.cc:7089:1: error: narrowing conversion of â-9â from âintâ to âCLD2::uint8 {aka unsigned char}â inside { } [-Wnarrowing]
    cld2/internal/cld_generated_cjk_uni_prop_80.cc:7089:1: error: narrowing conversion of â-9â from âintâ to âCLD2::uint8 {aka unsigned char}â inside { } [-Wnarrowing]
    cld2/internal/cld_generated_cjk_uni_prop_80.cc:7089:1: error: narrowing conversion of â-9â from âintâ to âCLD2::uint8 {aka unsigned char}â inside { } [-Wnarrowing]
    cld2/internal/cld_generated_cjk_uni_prop_80.cc:7089:1: error: narrowing conversion of â-9â from âintâ to âCLD2::uint8 {aka unsigned char}â inside { } [-Wnarrowing]
    cld2/internal/cld_generated_cjk_uni_prop_80.cc:7089:1: error: narrowing conversion of â-9â from âintâ to âCLD2::uint8 {aka unsigned char}â inside { } [-Wnarrowing]
    cld2/internal/cld_generated_cjk_uni_prop_80.cc:7089:1: error: narrowing conversion of â-9â from âintâ to âCLD2::uint8 {aka unsigned char}â inside { } [-Wnarrowing]
    cld2/internal/cld_generated_cjk_uni_prop_80.cc:7089:1: error: narrowing conversion of â-8â from âintâ to âCLD2::uint8 {aka unsigned char}â inside { } [-Wnarrowing]
    cld2/internal/cld_generated_cjk_uni_prop_80.cc:7089:1: error: narrowing conversion of â-7â from âintâ to âCLD2::uint8 {aka unsigned char}â inside { } [-Wnarrowing]
    cld2/internal/cld_generated_cjk_uni_prop_80.cc:7089:1: error: narrowing conversion of â-6â from âintâ to âCLD2::uint8 {aka unsigned char}â inside { } [-Wnarrowing]
    cld2/internal/cld_generated_cjk_uni_prop_80.cc:7089:1: error: narrowing conversion of â-5â from âintâ to âCLD2::uint8 {aka unsigned char}â inside { } [-Wnarrowing]
    cld2/internal/cld_generated_cjk_uni_prop_80.cc:7089:1: error: narrowing conversion of â-4â from âintâ to âCLD2::uint8 {aka unsigned char}â inside { } [-Wnarrowing]
    cld2/internal/cld_generated_cjk_uni_prop_80.cc:7089:1: error: narrowing conversion of â-3â from âintâ to âCLD2::uint8 {aka unsigned char}â inside { } [-Wnarrowing]
    cld2/internal/cld_generated_cjk_uni_prop_80.cc:7089:1: error: narrowing conversion of â-2â from âintâ to âCLD2::uint8 {aka unsigned char}â inside { } [-Wnarrowing]
    cld2/internal/cld_generated_cjk_uni_prop_80.cc:7089:1: error: narrowing conversion of â-1â from âintâ to âCLD2::uint8 {aka unsigned char}â inside { } [-Wnarrowing]
    cld2/internal/cld_generated_cjk_uni_prop_80.cc:7089:1: error: narrowing conversion of â-9â from âintâ to âCLD2::uint8 {aka unsigned char}â inside { } [-Wnarrowing]
    cld2/internal/cld_generated_cjk_uni_prop_80.cc:7089:1: error: narrowing conversion of â-9â from âintâ to âCLD2::uint8 {aka unsigned char}â inside { } [-Wnarrowing]
    cld2/internal/cld_generated_cjk_uni_prop_80.cc:7089:1: error: narrowing conversion of â-9â from âintâ to âCLD2::uint8 {aka unsigned char}â inside { } [-Wnarrowing]
    cld2/internal/cld_generated_cjk_uni_prop_80.cc:7089:1: error: narrowing conversion of â-9â from âintâ to âCLD2::uint8 {aka unsigned char}â inside { } [-Wnarrowing]
    cld2/internal/cld_generated_cjk_uni_prop_80.cc:7089:1: error: narrowing conversion of â-9â from âintâ to âCLD2::uint8 {aka unsigned char}â inside { } [-Wnarrowing]
    cld2/internal/cld_generated_cjk_uni_prop_80.cc:7089:1: error: narrowing conversion of â-9â from âintâ to âCLD2::uint8 {aka unsigned char}â inside { } [-Wnarrowing]
    cld2/internal/cld_generated_cjk_uni_prop_80.cc:7089:1: error: narrowing conversion of â-9â from âintâ to âCLD2::uint8 {aka unsigned char}â inside { } [-Wnarrowing]
    cld2/internal/cld_generated_cjk_uni_prop_80.cc:7089:1: error: narrowing conversion of â-9â from âintâ to âCLD2::uint8 {aka unsigned char}â inside { } [-Wnarrowing]
    cld2/internal/cld_generated_cjk_uni_prop_80.cc:7089:1: error: narrowing conversion of â-9â from âintâ to âCLD2::uint8 {aka unsigned char}â inside { } [-Wnarrowing]
    cld2/internal/cld_generated_cjk_uni_prop_80.cc:7089:1: error: narrowing conversion of â-9â from âintâ to âCLD2::uint8 {aka unsigned char}â inside { } [-Wnarrowing]
    cld2/internal/cld_generated_cjk_uni_prop_80.cc:7089:1: error: narrowing conversion of â-9â from âintâ to âCLD2::uint8 {aka unsigned char}â inside { } [-Wnarrowing]
    cld2/internal/cld_generated_cjk_uni_prop_80.cc:7089:1: error: narrowing conversion of â-9â from âintâ to âCLD2::uint8 {aka unsigned char}â inside { } [-Wnarrowing]
    cld2/internal/cld_generated_cjk_uni_prop_80.cc:7089:1: error: narrowing conversion of â-9â from âintâ to âCLD2::uint8 {aka unsigned char}â inside { } [-Wnarrowing]
    cld2/internal/cld_generated_cjk_uni_prop_80.cc:7089:1: error: narrowing conversion of â-9â from âintâ to âCLD2::uint8 {aka unsigned char}â inside { } [-Wnarrowing]
    cld2/internal/cld_generated_cjk_uni_prop_80.cc:7089:1: error: narrowing conversion of â-9â from âintâ to âCLD2::uint8 {aka unsigned char}â inside { } [-Wnarrowing]
    cld2/internal/cld_generated_cjk_uni_prop_80.cc:7089:1: error: narrowing conversion of â-9â from âintâ to âCLD2::uint8 {aka unsigned char}â inside { } [-Wnarrowing]
    cld2/internal/cld_generated_cjk_uni_prop_80.cc:7089:1: error: narrowing conversion of â-9â from âintâ to âCLD2::uint8 {aka unsigned char}â inside { } [-Wnarrowing]
    cld2/internal/cld_generated_cjk_uni_prop_80.cc:7089:1: error: narrowing conversion of â-9â from âintâ to âCLD2::uint8 {aka unsigned char}â inside { } [-Wnarrowing]
    cld2/internal/cld_generated_cjk_uni_prop_80.cc:7089:1: error: narrowing conversion of â-9â from âintâ to âCLD2::uint8 {aka unsigned char}â inside { } [-Wnarrowing]
    cld2/internal/cld_generated_cjk_uni_prop_80.cc:7089:1: error: narrowing conversion of â-9â from âintâ to âCLD2::uint8 {aka unsigned char}â inside { } [-Wnarrowing]
    cld2/internal/cld_generated_cjk_uni_prop_80.cc:7089:1: error: narrowing conversion of â-9â from âintâ to âCLD2::uint8 {aka unsigned char}â inside { } [-Wnarrowing]
    cld2/internal/cld_generated_cjk_uni_prop_80.cc:7089:1: error: narrowing conversion of â-9â from âintâ to âCLD2::uint8 {aka unsigned char}â inside { } [-Wnarrowing]
    cld2/internal/cld_generated_cjk_uni_prop_80.cc:7089:1: error: narrowing conversion of â-9â from âintâ to âCLD2::uint8 {aka unsigned char}â inside { } [-Wnarrowing]
    /usr/lib/python3.5/site-packages/Cython/Distutils/old_build_ext.py:30: UserWarning: Cython.Distutils.old_build_ext does not properly handle dependencies and is deprecated.
      "Cython.Distutils.old_build_ext does not properly handle dependencies "
    Traceback (most recent call last):
      File "/usr/lib/python3.5/distutils/unixccompiler.py", line 118, in _compile
        extra_postargs)
      File "/usr/lib/python3.5/distutils/ccompiler.py", line 909, in spawn
        spawn(cmd, dry_run=self.dry_run)
      File "/usr/lib/python3.5/distutils/spawn.py", line 36, in spawn
        _spawn_posix(cmd, search_path, dry_run=dry_run)
      File "/usr/lib/python3.5/distutils/spawn.py", line 159, in _spawn_posix
        % (cmd, exit_status))
    distutils.errors.DistutilsExecError: command 'gcc' failed with exit status 1

    During handling of the above exception, another exception occurred:

    Traceback (most recent call last):
      File "/usr/lib/python3.5/site-packages/cffi/ffiplatform.py", line 58, in _build
        dist.run_command('build_ext')
      File "/usr/lib/python3.5/distutils/dist.py", line 974, in run_command
        cmd_obj.run()
      File "/usr/lib/python3.5/site-packages/setuptools/command/build_ext.py", line 75, in run
        _build_ext.run(self)
      File "/usr/lib/python3.5/site-packages/Cython/Distutils/old_build_ext.py", line 179, in run
        _build_ext.build_ext.run(self)
      File "/usr/lib/python3.5/distutils/command/build_ext.py", line 338, in run
        self.build_extensions()
      File "/usr/lib/python3.5/site-packages/Cython/Distutils/old_build_ext.py", line 187, in build_extensions
        self.build_extension(ext)
      File "/usr/lib/python3.5/site-packages/setuptools/command/build_ext.py", line 196, in build_extension
        _build_ext.build_extension(self, ext)
      File "/usr/lib/python3.5/distutils/command/build_ext.py", line 532, in build_extension
        depends=ext.depends)
      File "/usr/lib/python3.5/distutils/ccompiler.py", line 574, in compile
        self._compile(obj, src, ext, cc_args, extra_postargs, pp_opts)
      File "/usr/lib/python3.5/distutils/unixccompiler.py", line 120, in _compile
        raise CompileError(msg)
    distutils.errors.CompileError: command 'gcc' failed with exit status 1

    During handling of the above exception, another exception occurred:

    Traceback (most recent call last):
      File "<string>", line 1, in <module>
      File "/tmp/pip-build-gbcebap_/cld2-cffi/setup.py", line 191, in <module>
        'Topic :: Text Processing :: Linguistic'
      File "/usr/lib/python3.5/distutils/core.py", line 148, in setup
        dist.run_commands()
      File "/usr/lib/python3.5/distutils/dist.py", line 955, in run_commands
        self.run_command(cmd)
      File "/usr/lib/python3.5/distutils/dist.py", line 974, in run_command
        cmd_obj.run()
      File "/usr/lib/python3.5/site-packages/setuptools/command/egg_info.py", line 279, in run
        self.find_sources()
      File "/usr/lib/python3.5/site-packages/setuptools/command/egg_info.py", line 306, in find_sources
        mm.run()
      File "/usr/lib/python3.5/site-packages/setuptools/command/egg_info.py", line 533, in run
        self.add_defaults()
      File "/usr/lib/python3.5/site-packages/setuptools/command/egg_info.py", line 562, in add_defaults
        sdist.add_defaults(self)
      File "/usr/lib/python3.5/site-packages/setuptools/command/py36compat.py", line 34, in add_defaults
        self._add_defaults_python()
      File "/usr/lib/python3.5/site-packages/setuptools/command/sdist.py", line 133, in _add_defaults_python
        build_py = self.get_finalized_command('build_py')
      File "/usr/lib/python3.5/distutils/cmd.py", line 299, in get_finalized_command
        cmd_obj.ensure_finalized()
      File "/usr/lib/python3.5/distutils/cmd.py", line 107, in ensure_finalized
        self.finalize_options()
      File "/usr/lib/python3.5/site-packages/setuptools/command/build_py.py", line 34, in finalize_options
        orig.build_py.finalize_options(self)
      File "/usr/lib/python3.5/distutils/command/build_py.py", line 45, in finalize_options
        ('force', 'force'))
      File "/usr/lib/python3.5/distutils/cmd.py", line 287, in set_undefined_options
        src_cmd_obj.ensure_finalized()
      File "/usr/lib/python3.5/distutils/cmd.py", line 107, in ensure_finalized
        self.finalize_options()
      File "/tmp/pip-build-gbcebap_/cld2-cffi/setup.py", line 143, in finalize_options
        self.distribution.ext_modules = get_ext_modules()
      File "/tmp/pip-build-gbcebap_/cld2-cffi/setup.py", line 128, in get_ext_modules
        import cld2
      File "/tmp/pip-build-gbcebap_/cld2-cffi/cld2/__init__.py", line 190, in <module>
        extra_compile_args=_COMPILER_ARGS)
      File "/usr/lib/python3.5/site-packages/cffi/api.py", line 437, in verify
        lib = self.verifier.load_library()
      File "/usr/lib/python3.5/site-packages/cffi/verifier.py", line 113, in load_library
        self._compile_module()
      File "/usr/lib/python3.5/site-packages/cffi/verifier.py", line 210, in _compile_module
        outputfilename = ffiplatform.compile(tmpdir, self.get_extension())
      File "/usr/lib/python3.5/site-packages/cffi/ffiplatform.py", line 29, in compile
        outputfilename = _build(tmpdir, ext, compiler_verbose, debug)
      File "/usr/lib/python3.5/site-packages/cffi/ffiplatform.py", line 65, in _build
        raise VerificationError('%s: %s' % (e.__class__.__name__, e))
    cffi.ffiplatform.VerificationError: CompileError: command 'gcc' failed with exit status 1

Humm is that compiling with clang? And where dies cython come into the mix (we use cffi)

All I'm doing is running the above commands to try to install cld2-cffi using pip. I'm not running cython or any other command. I'd be happy to test compiling with clang, but I don't know how that would work, since I've never used it.

Can you send me
uname -a
gcc --version

thanks

.... Nevermind
$ for prog in python pip gcc; do $prog --version; done
Python 3.5.2
pip 9.0.1 from /usr/lib/python3.5/site-packages (python 3.5)
gcc (GCC) 6.2.1 20160830

That is a very very very new compiler, but let me see what can be done with it.

So I am thinking the best solution to this is to get round to implementing #11, then you wont have to compile

FWIW, here's uname -a, too:
Linux jon-laptop 4.8.11-1-ARCH #1 SMP PREEMPT Sun Nov 27 09:26:14 CET 2016 x86_64 GNU/Linux

BTW, it does look like this is a compiler issue--I was able to successfully compile the cfd2-cffi with an old GCC, using sudo env CC=/usr/bin/gcc-5 pip install -U cld2-cffi.

I am guessing that GCC 6 is more strict with narrowed strings (notice
that is the error)
I dont have the time to look into it right now, but I will try to figure
out how to cope with gcc6.
On Tue, Dec 6, 2016, at 05:06 PM, Jonathan Reeve wrote:

BTW, it does look like this is a compiler issue--I was able to
successfully compile the cfd2-cffi with an old GCC, using sudo env CC=/usr/bin/gcc-
5 pip install -U cld2-cffi.
— You are receiving this because you commented. Reply to this email
directly, view it on GitHub[1], or mute the thread[2].

Links:

https://github.com/GregBowyer/cld2-cffi/issues/12#issuecomment-265324306
https://github.com/notifications/unsubscribe-auth/AAHr77kNs_DIP6zzKPrauXkv_Rdu4K71ks5rFgaAgaJpZM4LDYVN

I just ran into this error with GCC 6 also.
As a workaround I did a CFLAGS="-Wno-narrowing" pip install cld2-cffi which allowed it to build and install. I assume there must be some way to add that compiler flag to the setup.py/build process to allow it to build for everyone (if the flag is also accepted by GCC 5).

The following worked for me:
pip install --upgrade 'git+https://github.com/GregBowyer/cld2-cffi.git@d048c5fa98066bdb130f1c7e52641a0645aef5ac'

gcc (Gentoo 8.3.0-r1 p1.1) 8.3.0

I had the same installation issue. The fix in branch Fix-21 worked for me.


Small fixes

Changes:

Removed unused icon images no longer needed since WP 4.3 (missed in #784).
Corrected typo in comment FontAwesome comment.
Changed img to images in gulp watch task path in gulpfile.babel.js (Missed in #1155).
Removed unnecessary echoes in front of the_post_thumbnail_url function.
Removed unnecessary/invalid fourth parameter in remove_action calls in library/cleanup.php.

@emaia congratulations on your first FoundationPress contribution(s)! All look good to me.
For future reference, please add a description to your pull requests outlining the changes. I did it for you on this one.
Thanks for the PR!

@colin-marshall I'm happy to contribute with the FP. Thanks for add a description. I will do this in the next PR.

Looks good 👌 Thanks, @emaia and @colin-marshall !


PANIC: runtime error: invalid memory address or nil pointer dereference

Installed on Kubernetes v1.16.2
jx version
Version        2.1.149
Commit         a5c2cb9
Build date     2020-09-21T11:50:59Z
Go version     1.13.8
Git tree state clean
Stack trace when I try to open logs for a pipeline run:
PANIC: runtime error: invalid memory address or nil pointer dereference goroutine 2172 [running]: github.com/urfave/negroni/v2.(*Recovery).ServeHTTP.func1(0x7fbc56c33a60, 0xc000b2e7f8, 0xc000ddcf00, 0xc000de0f50) 	/home/runner/work/jx-pipelines-visualizer/jx-pipelines-visualizer/vendor/github.com/urfave/negroni/v2/recovery.go:168 +0x166 panic(0x261f9a0, 0x409a390) 	/opt/hostedtoolcache/go/1.15.2/x64/src/runtime/panic.go:969 +0x175 github.com/jenkins-x/jx/v2/pkg/cloud/buckets.ReadHTTPURL(0xc00068e420, 0xa1, 0x0, 0x6fc23ac00, 0x0, 0x1e00, 0xc000dd5da0, 0x10) 	/home/runner/work/jx-pipelines-visualizer/jx-pipelines-visualizer/vendor/github.com/jenkins-x/jx/v2/pkg/cloud/buckets/buckets.go:79 +0xfa github.com/jenkins-x/jx/v2/pkg/cloud/buckets.ReadURL(0xc00068e420, 0xa1, 0x6fc23ac00, 0x0, 0x0, 0x0, 0x0, 0x0) 	/home/runner/work/jx-pipelines-visualizer/jx-pipelines-visualizer/vendor/github.com/jenkins-x/jx/v2/pkg/cloud/buckets/buckets.go:65 +0xb4 github.com/dailymotion/jx-pipelines-visualizer/web/handlers.(*LogsHandler).ServeHTTP(0xc000dcb8e0, 0x7fbc56c33a60, 0xc000b2e7f8, 0xc000ddd100) 	/home/runner/work/jx-pipelines-visualizer/jx-pipelines-visualizer/web/handlers/logs.go:58 +0x398 github.com/gorilla/mux.(*Router).ServeHTTP(0xc000d15ec0, 0x7fbc56c33a60, 0xc000b2e7f8, 0xc000ddcf00) 	/home/runner/work/jx-pipelines-visualizer/jx-pipelines-visualizer/vendor/github.com/gorilla/mux/mux.go:210 +0xd3 github.com/urfave/negroni/v2.Wrap.func1(0x7fbc56c33a60, 0xc000b2e7f8, 0xc000ddcf00, 0xc000dcbf60) 	/home/runner/work/jx-pipelines-visualizer/jx-pipelines-visualizer/vendor/github.com/urfave/negroni/v2/negroni.go:55 +0x4d github.com/urfave/negroni/v2.HandlerFunc.ServeHTTP(0xc000dcbf20, 0x7fbc56c33a60, 0xc000b2e7f8, 0xc000ddcf00, 0xc000dcbf60) 	/home/runner/work/jx-pipelines-visualizer/jx-pipelines-visualizer/vendor/github.com/urfave/negroni/v2/negroni.go:29 +0x4e github.com/urfave/negroni/v2.middleware.ServeHTTP(...) 	/home/runner/work/jx-pipelines-visualizer/jx-pipelines-visualizer/vendor/github.com/urfave/negroni/v2/negroni.go:47 github.com/urfave/negroni/v2.(*Static).ServeHTTP(0xc000dfc450, 0x7fbc56c33a60, 0xc000b2e7f8, 0xc000ddcf00, 0xc000dcbf80) 	/home/runner/work/jx-pipelines-visualizer/jx-pipelines-visualizer/vendor/github.com/urfave/negroni/v2/static.go:41 +0xf9 github.com/urfave/negroni/v2.middleware.ServeHTTP(...) 	/home/runner/work/jx-pipelines-visualizer/jx-pipelines-visualizer/vendor/github.com/urfave/negroni/v2/negroni.go:47 github.com/urfave/negroni/v2.(*Recovery).ServeHTTP(0xc000de0f50, 0x7fbc56c33a60, 0xc000b2e7f8, 0xc000ddcf00, 0xc000dcbfa0) 	/home/runner/work/jx-pipelines-visualizer/jx-pipelines-visualizer/vendor/github.com/urfave/negroni/v2/recovery.go:210 +0x8c github.com/urfave/negroni/v2.middleware.ServeHTTP(...) 	/home/runner/work/jx-pipelines-visualizer/jx-pipelines-visualizer/vendor/github.com/urfave/negroni/v2/negroni.go:47 github.com/urfave/negroni/v2.(*Negroni).ServeHTTP(0xc000dfc4b0, 0x2e10560, 0xc000afe0e0, 0xc000ddcf00) 	/home/runner/work/jx-pipelines-visualizer/jx-pipelines-visualizer/vendor/github.com/urfave/negroni/v2/negroni.go:107 +0xfb net/http.(*ServeMux).ServeHTTP(0x40cb7a0, 0x2e10560, 0xc000afe0e0, 0xc000ddcf00) 	/opt/hostedtoolcache/go/1.15.2/x64/src/net/http/server.go:2417 +0x1ad net/http.serverHandler.ServeHTTP(0xc000dea0e0, 0x2e10560, 0xc000afe0e0, 0xc000ddcf00) 	/opt/hostedtoolcache/go/1.15.2/x64/src/net/http/server.go:2843 +0xa3 net/http.(*conn).serve(0xc000df6780, 0x2e18820, 0xc000db3c00) 	/opt/hostedtoolcache/go/1.15.2/x64/src/net/http/server.go:1925 +0x8ad created by net/http.(*Server).Serve 	/opt/hostedtoolcache/go/1.15.2/x64/src/net/http/server.go:2969 +0x36c

thanks for the bug report. It seems you're not storing your logs in a GCS bucket. Can you please share where are stored your logs? the storage.logs section of your jx-requirements.yml file. thanks

Actually I'm not storing logs anywhere. I didn't realize it was a requirement.
I'm on on-prem Kubernetes. Would it be feasible to store them on a PVC instead of a remote storage bucket?

it's not a requirement to store your logs, but if you don't do it, you won't be able to read logs from deleted containers. So it's highly recommended.
you can create an issue in the jx project to ask for the ability to store the logs in a PVC


Changes to "Set up the Route" page

See attached screen shot to adjust two things:

Change header from "Set up the route" to "Driver's Destination"
Remove "Avoid Tolls" and "Avoid Highways" boxes.

I fixed both!


Enable the new model serialization for synapse

Contributing to the Azure SDK
Please see our CONTRIBUTING.md if you are not familiar with contributing to this repository or have questions.
For specific information about pull request etiquette and best practices, see this section.

API change check
APIView has identified API level changes in this PR and created following API reviews.
Azure.ResourceManager.Synapse


Stratux making more EMI than it used to

Stratux version: 1.2r1-0360e

Stratux config:
SDR

[ ] single
[X ] dual

GPS

[X ] yes
[ ] no
type: VK-162

AHRS

[ ] yes
[X] no

power source: Anker E5
usb cable: Anker

EFB app and version: iFly v9.8.7
EFB platform: Andrioid KK
EFB hardware: Asus Zenpad

Description of your issue:

This isn't a code issue, per se. But something changed in the Stratux code that is making more RFI now. (I'm gonna guess it's the faster psuedo-AHRS.)
About a month ago, the squelches on both our COMMs (King KX-165 and KX-155) started "breaking." (That is, started letting noise thru.) We noticed it on Tower (118.4 MHz), Ground Freq (121.8 MHz), Guard (121.5 MHz) and Unicom (122.8). Whether it does it in the 130's, I don't know.
Tonight I had the brainstorm to reboot the Stratux in flight. As soon as I hit the reboot command, the noise in the COMM stopped! When the Stratux came back on line, so did the noise.
This started in early February. So that would be coincident with the Feb 3 sh updates.
This is a Pi 3. No copper foil shielding like I had on my old Pi 2. Aside from the software, nothing has changed in my config. The Stratux is where it's always been. The antennas and SDR's have been where they've always been, etc.
I don't think that the developers can really code around EMI. More like the Project might start thinking about shielding the box if others report similar problems with their COMMs.

I do think this may have to do with CPU load.
https://github.com/cyoung/stratux/blob/master/docs/RPi3/RA-029073-45-00B - part1.pdf
page. 22
A number of users have reported similar issues and it seems to be worse (according to reports) at ~125.0 MHz.
We were never able to figure out the source exactly, but it may be the time to start working on this.

Interesting. I quickly skimmed the report and I see the spike at COM freqs. (Correlates with what I happened on.) But I didn't see what they had the Pi doing for the test. Just powered up? Running Jessie? Calculating Primes?
If it's the CPU radiating, then we ought to be able to shield some of this down. I've got copper foil at the hangar. But will be a least a week until I'm able to get out there again.
Actually, this sounds like something right up @Axtel4's alley.

Probably unrelated but I was getting similar noise on certain comm freqs, and finally narrowed it down to the 12v power cable leading to my iFly 740.  A trip to Radio Shack for a small choke fixed the problem.  They're cheap enough; might be worth a try.

I've got two simultaneous threads going on this issue (one here and one in Slack). In the Slack thread, I mentioned that, since I'm running my Stratux on an Anker, this particular problem is radiated. BUT, that doesn't mean that the Stratux isn't also conducting RF into ship's power for those who are hooked up.
Did you tell iFly about the conducted EMI from the 740? They should have chokes internally on the power.
Years ago I had to put a choke (also from Radio Shack) on an HID power supply in the Glasair.
Since then I thought Radio Shack declared bankruptcy. Are there still stores around?

It was AP that told me to try a choke.  Interference occurred both with ship's power and 12v portable battery.    It's been a few months since I've been to one, but the shelves were was pretty sad.

Interesting that a choke on ship's power fixed the problem even when you had the problem with battery power. Might point to what Chris found today, that moving his power wires around changed the squelch brake, So that might be telling us that the power cable is acting as an antenna.
I've got a clip on choke from a computer cable I will put in my flight bag to test next time I'm at the hangar. Would be an easy fix that everyone could do. (Easier than soldering on a copper shield.)

If anyone else is experiencing this, give this config.txt a try (replace /boot/config.txt with the file, reboot). I'll be testing this further this week.
config.txt

By the way, you can access the "boot" partition on a Windows/Mac/Linux and modify the config.txt file that way.

Yeah, I remember. I leave the Stratux in the plane nowadays, so have to SSH in there. I especially don't want to move anything until I've got a better handle on the RFI.

I did some testing in the hangar today with Comm 2 (King KX-155) on 125.0 MHz. I made a video.
You can hear the squelch breaks in the video as I do some "hands on" testing.
There is a difference in the tone of the radiated RFI for the two different config.txt's. But the new config.txt does not solve the problem. The problem is radiated RFI, and it seems to be coming mostly from the controller chip. (Followed by the CPU and then something by the SD card.)
Here's the video: https://vid.me/gpZw
Jump to 3:20 for the final solution.
I didn't get a chance to fly it with the shielding today. But given how quite it is now, I'll be surprised if I have any more problems.
Note that this was with an Anker battery. (As opposed to ship's power.) I tried a clip-on choke first on the power lead. No difference that I noticed. (I'm gonna guess that, being battery based, the impedance looking into the Anker is very low.) Someone who uses ship's power should check for conducted EMI after they shield their Stratux.

In my testing with the new config.txt, the 125 MHz EMI was still present but there were less emissions at other COMM freqs. See the peaks around the left and right of 125 MHz here, these were eliminated on my setup. They appeared as the CPU frequency changed from 600 MHz to 1.2 GHz depending on CPU load. Raspbian is configured by default to use only these two frequency steps.
As noted on Slack, your test raises the question as to how the aluminum heat sinks that some users put on the LAN chip change the EMI situation.

Here is a summary of the config.txt used over all releases. Most notable was the switch back to a floating CPU frequency with v0.8r2 (Jessie).
I suspect that this is related to #451.

File
Date
Comment
Config
Config Ident
CPU

stratux-pre-8b4fea41f2-08252015.img.config.txt
8/25/15
Wheezy. RPi2 only
7dfb47e91e8a4b507f3f4921ec9c97a0
A
floating

stratux-pre-a408a8cf13-08152015.img.config.txt
8/15/15
Wheezy. RPi2 only
7dfb47e91e8a4b507f3f4921ec9c97a0
A
floating

stratux-pre-e17c0a5302-08312015.img.config.txt
8/31/15
Wheezy. RPi2 only
8aaf2de4fcf2c7f43bebc7a798663cfd
B
floating

stratux-v.0.1-08072015.img.config.txt
8/7/15
Wheezy. RPi2 only
7dfb47e91e8a4b507f3f4921ec9c97a0
A
floating

stratux-v0.2r1-f47a224c1d-09042015.img.config.txt
9/4/15
Wheezy. RPi2 only
8aaf2de4fcf2c7f43bebc7a798663cfd
B
floating

stratux-v0.3b1-7e61c7556a-09112015.img.config.txt
9/11/15
Wheezy. RPi2 only
8aaf2de4fcf2c7f43bebc7a798663cfd
B
floating

stratux-v0.3b2-5a568e27ce-09162015.img.config.txt
9/16/15
Wheezy. RPi2 only
8aaf2de4fcf2c7f43bebc7a798663cfd
B
floating

stratux-v0.3b3-c3e6d41ebe-09192015.img.config.txt
9/19/15
Wheezy. RPi2 only
8aaf2de4fcf2c7f43bebc7a798663cfd
B
floating

stratux-v0.3b4-75f60562af-09242015.img.config.txt
9/24/15
Wheezy. RPi2 only
773ea70f6708ceeff741ab812092621f
C
floating

stratux-v0.4r1-34f55beb04-10052015.img.config.txt
10/5/15
Wheezy. RPi2 only
773ea70f6708ceeff741ab812092621f
C
floating

stratux-v0.4r2-a2a7b11494-10072015.img.config.txt
10/7/15
Wheezy. RPi2 only
773ea70f6708ceeff741ab812092621f
C
floating

stratux-v0.4r3-6f5f69b-10202015.img.config.txt
10/20/15
Wheezy. RPi2 only
773ea70f6708ceeff741ab812092621f
C
floating

stratux-v0.4r4-293d0e74a8-10222015.img.config.txt
10/22/15
Wheezy. RPi2 only
773ea70f6708ceeff741ab812092621f
C
floating

stratux-v0.5b1-ab889fb116-11212015.img.config.txt
11/21/15
Wheezy. RPi2 only
773ea70f6708ceeff741ab812092621f
C
floating

stratux-v0.5b2-e6ad9aa830-12212015.img.config.txt
12/21/15
Wheezy. RPi2 only
773ea70f6708ceeff741ab812092621f
C
floating

stratux-v0.5b3-680284ee1e.img.config.txt
12/27/15
Wheezy. RPi2 only
773ea70f6708ceeff741ab812092621f
C
floating

stratux-v0.5b4-d682bb5cf0.img.config.txt
1/1/16
Wheezy. RPi2 only
773ea70f6708ceeff741ab812092621f
C
floating

stratux-v0.5b5-cfd1541708.img.config.txt
1/7/16
Wheezy. RPi2 only
773ea70f6708ceeff741ab812092621f
C
floating

stratux-v0.5b6-1be927e672.img.config.txt
1/26/16
Wheezy. RPi2 only
1d76ea8d7359baf024a9a0fd951177b8
D
900MHz

stratux-v0.6r1-bbbcd3bbe1.img.config.txt
1/29/16
Wheezy. RPi2 only
1d76ea8d7359baf024a9a0fd951177b8
D
900MHz

stratux-v0.7b1-02bf2251d8.img.config.txt
2/15/16
Wheezy. RPi2 only
1d76ea8d7359baf024a9a0fd951177b8
D
900MHz

stratux-v0.8r1-796d0a2632.img.config.txt
3/7/16
Wheezy. RPi2 only
1d76ea8d7359baf024a9a0fd951177b8
D
900MHz

stratux-v0.8r2-db130aab76.img.config.txt
3/21/16
Jessie. RPi2+3
7b1933cfa3adf9b9dfe68afebfd97476
E
floating

stratux-v0.9b1-89107818b8.img.config.txt
5/27/16
Jessie. RPi2+4
d26f0c1655c39904674ed33f95975982
F
floating

stratux-v0.9b2-64710fe60d.img.config.txt
6/21/16
Jessie. RPi2+5
d26f0c1655c39904674ed33f95975982
F
floating

stratux-v1.0r1-945c8bf6bc.img.config.txt
7/13/16
Jessie. RPi2+6
d26f0c1655c39904674ed33f95975982
F
floating

stratux-v1.1b1-0107b59010.img.config.txt
12/12/16
Jessie. RPi2+7
794ca6d7ac129bbe22dd7d25075fd4de
G
floating

stratux-v1.2r1-9ee46170ff.img.config.txt
1/29/17
Jessie. RPi2+8
794ca6d7ac129bbe22dd7d25075fd4de
G
floating

My solutions for EMI and power success:
First of all, thanks Chris and other contributors for the Stratux project.  I’m one of the happy beneficiaries.
I’m a newby, not sure if any of this is new to the group.
Conclusion:
EMI was brought under control by grounding the RPi heat sinks and also adding a ‘rat’s nest’ grounded random wire bundle over the Pi board.
Power supply is with a dual port usb car charger, Aukey CC-S7, and powered hub, Anker Ultra Slim USB hub w/USB charger.  The Pi goes to one port of the charger while the hub gets power from the other port.
Story:
My objective is to not use a battery supply.
Adequate power for the Pi with the car chargers was a problem with peripherals attached (VK-62 and one SDR).  The Pi was running at the low end (red light blinking) using various power sources.  I tried:

Cheap dual port car usb charger, DC/DC converter but inefficient and put noise on Pi carrier
Cheap adjustable DC/DC converter board.  Provided good power but very noisy.
Made a linear supply.  Clean but hot.
Anker car charger.  Clean, Aukey slightly higher output under load.
Aukey car charger.  Clean, power adequate but marginal, about 4.7 v on Pi bus.
Added Anker powered usb hub for peripherals.  4.9 v on Pi bus.

Occasionally I suffered SD card corruption during shutdown with the marginal PS’s, so I had to re-image the card a few times.  Haven’t had that problem lately.
EMI problems were from two sources.  One is the 125.0 carrier from the Pi.  Other is information being impressed on the Pi’s carrier by noisy power supplies.  With enough modulation and a strong carrier, all communications were being impacted by Stratux.  Using a clean PS eliminated the transmitted noise information, and grounding the Pi’s heat sinks brought the Pi’s carrier power down enough to avoid spurious breaks of com squelch.
My testing on the bench was crude, just used a handheld radio.  The results provided enough contrast that I didn’t bother putting any components on a scope.
Discovered by accident that a 3’ piece of loose signal wire attached to the ethernet can and the cpu heat sink also attenuated the Pi carrier.  Tried wrapping board in metal screen and using longer wire but no gain was noticed over just jumbling the 3’ wire on top of the Pi.
I also observed noise from the SDR on 120.0, however, it wasn’t strong enough to trip my squelch.  I don’t know if that would interfere with a 120.0 com channel.
My setup is old, analog King KY-197 com’s, RPi3, VK-62 GPS, and thumb drive size SDR (from Vilros, summer of 2016).  My screen is a Windows laptop running the Ifly app.

3 foot or 3 inch? Got any photos?

3 feet.  I’ll try to remember to get some pix Wed.  Can you put pix on Github or do you put them on another site?
From: Ergonomicmike<EMAIL_ADDRESS>Sent: Monday, September 25, 2017 12:28 PM
To: cyoung/stratux<EMAIL_ADDRESS>Cc: merricke<EMAIL_ADDRESS>Comment<EMAIL_ADDRESS>Subject: Re: [cyoung/stratux] Stratux making more EMI than it used to (#573)
3 foot or 3 inch? Got any photos?
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub https://github.com/cyoung/stratux/issues/573#issuecomment-331936664 , or mute the thread https://github.com/notifications/unsubscribe-auth/AZFZ5-056g0kMG4PhrRQ-lfMjezt4iogks5sl9SWgaJpZM4MaFl4 .

I've left images before. I think you just click on "Attach files" below.

Pix of the grounded heat sinks & jumbled wire (emi shield).
I used solid hookup wire which is 'haywire twisted' to one heat sink and deformed to make sufficient mechanical contact with the other heat sink.
The gray wire is 28ga stranded wire.

Interesting. I expect that the grounded shields are coupling the EMI from the chips to ground. (Earlier, in a video somewhere, I had put my finger over the chips (without heat sinks) and found that my finger radiated away energy, making more noise.) If so, then it might be that short braid would also do the trick too.

Depending on where you're doing your tests, your body may be adding 60 Hz noise to the system.  Try using clip leads to ground the heat shields to the USB or Ethernet cans to see if you get similar results to mine.
I think it's a 2 step process:
-reduce the Pi's 125.0 carrier strength with EMI shielding (grounding the heat sinks & the 'wire cage')
-reduce modulated information (below 8 KHz for my KY197) on the carrier that opens the squelch circuit by using a clean power supply.
I'm assuming battery supplies also use DC/DC converters so they may not necessarily be noise free.  I didn't test with any battery supplies.   And adding your own filters (capacitors or chokes) my alter the output characteristics of the converter instead of smoothing the current.

As a new Stratux owner I've been browsing some of the old discussions.  I found this one interesting so I ran an EMI current probe over my unit.  I found a signal at 125.01 MHz with the probe centered over the micro SD card (marker 1).  There were also signals at 115.25 MHz and 120.08 MHz when the probe was over the NooElec RTL receivers (markers 2 and 3).    I don't know yet if these signals will cause any problems with my aircraft radios.  I didn't find any other signals as strong as these.
In the images the yellow trace is with Stratus powered down.  The magenta trace is with the current probe over the micro SD card.  The cyan trace is with the current probe  above the  NooElec RTLs.

That's good info, and it concurs with my crude tests just using a handheld radio.
I'm wondering, at 120 I was getting a high pitch squeal, maybe from the 2 carriers?

Very cool @GitUser275 ! The 115.25 MHz explains the noise I'm getting on 116.0 MHz. Next time I do a video (below) I'll go down to 115.25.
Can you also scan into the 300 to 400 MHz? We're beginning to wonder about GS frequencies. And since there's no way to listen to what's being received on the GS, it would be good to know what's there at fundamental frequencies. Also, please scan from 130 up to 300 - might be something in the 160's who's harmonic could interfere with GS.
In the meantime, I found that some of this noise is being conducted into the power cord and then radiated out. See my video at https://vid.me/ADfa2
I'm in the process of putting braid over the power cord and also the USB cable for the 1090 SDR.

For the spectrum traces shown above both SDR were active (RX 978 and RX 1090).   I tried unplugging one to see which one was causing which frequency but I don't have a capture.   I'll run some more tests and report back.
Snap on ferrite beads can be quite effective at suppressing spurious VHF signals on power and signal cables. Put them as close to the source as possible.
Are you at DVT?  I recognized the frequencies in the first post of this thread.

@GitUser275 Yes, DVT. Per the video, tried a snap on bead. I couldn't tell a difference.(Maybe I don't have the right ones for the freqs we're talking about. @cyoung reports success with his.

Also, doing testing in a Glasair. Not having a metal shell for any shielding, ours is the Worst Case airplane for EMI problems.

DVT, Mike, and a Glassair?  Maybe I know you.  J3 at Sunburst and flight review 6/19/2007??
Andy

That's me. (Pretty scary, huh?) I keep track of time nowadays by the Glasair. So, we finished it 1995. I thought that Sunburst had been forced to shut down some time back then. (As opposed to only 10 years ago in 2007.)

it's a long time ago but you checked me out to solo in Jim's J3 at Sunburst and much later in 2007, long after Sunburst had closed, I gave you a flight review in your bird.  If you think heel brakes were bad - I think I went grey instructing in the right seat of an Aeronca Chief.  No brakes on that side.
It's a small world.  Good to hook up again in a new area of interest.

Ahhh. So Andy D? (of Glider fame?)

Yes, that's me.  Moving back on topic I made the requested sweep using the EMI current probe.
For 300-400 MHz I only found very weak signals near the micro SD card slot:

For 130-300 MHz the significant signals were in the vicinity of the two RTL SDR:

In both cases the yellow trace is a baseline with Stratux unpowered.  These traces use power average sampling with 100 sample average.  Note that the amplitude scale is not the same as for the earlier traces.

Are you doing this at work? Or do you have your own analyzer? If the latter, and if you're still around DVT, maybe we can sniff out my unit in the plane?

My retirement hobby was to renew my interest in amateur radio and the spectrum analyzer was bought for that.   Sure, we could meet some time at your hangar.  Is your aol email still valid?

Yep.
I sold my old Heathkit HF equipment at a yard sale for $100 a few years ago. (Obsolete I guess, since they didn't have the new HF bands that came in later.)

GU275, can you run the scans with some test leads grounding the heat sinks to the board ground?  I'm wondering if you'll get more definitive results than I did at 125.0.

As I said earlier - " I found a signal at 125.01 MHz with the probe centered over the micro SD card (marker 1). "   If I move my 1.5 inch diameter probe away from the card holder the 125.01 MHz signal is very quickly attenuated.   I detected no significant signals with the  probe centered over either heat sink.
Later I'll see if the 125.01 peak is influenced by grounding the heat  sinks but it may be tricky to get good contact.  They appear to be anodized aluminium which is not conductive unless the anodizing is removed.
The probe I'm using is a home brew 1.5 inch diameter shielded magnetic field probe.

I looked again with the probe close to each heat sink and I find no strong signals there.  There is a very strong 250 MHz signal with the probe centered over the RAM chip which is other side of the board.   Here are a couple more screen captures.
Centered on RAM:

(marker table not captured)
Centered on micro SD card holder:

@GitUser275 - regarding the 115.25 MHz and 120.08 MHz signals, do these vary with input voltage (to the Pi)?

@GitUser275 , I'm wondering

the area of noise around 103 MHz on both sides of the board
the periodic spikes about every 42 MHz
would the signal at 125 over the SD card drop off if the heat sinks are grounded (mine aren't alodined and are easy to connect to with test leads).  My way of checking signal strength was to check squelch requirements at differing distances with my handheld radio (done at home but improvement there matched improvement in the plane).

While flying yesterday, ran thru the NAV channels.
This is not an exhaustive list, but to my surprise, found noise on:
108.00 (Some kind of Intermod. Could hear talking. Might not be Stratux.)
108.55
109.25
109.40
110.00
110.15
110.70
111.15
111.95
112.00
112.05
112.85
112.90
112.95
113.75
114.60
114.65
114.70
115.20 (Solid, like a carrier. None of that repetitive noise associated with the SDR.)
115.60
116.40
116.45
117.30
117.35

I made a much smaller probe.  This one has a loop diameter about 0.5 inch.  Using it I was able to explore the processor side of the board.   I found the strongest signals in the are equidistant between each heat sink and and the header, an area with no large devices.   I'll do more more later in the week.

It'd be nice if someone could line their case with copper tape and see if it reduces the noise.
https://www.amazon.com/dp/B07663WM7D/ref=sspa_dk_detail_3?psc=1&pd_rd_i=B07663WM7D&pd_rd_wg=EpeiX&pd_rd_r=BX062CXSD8E3WZ0NK9M6&pd_rd_w=az1aW

Re - voltage influence
What range of voltage would be of interest.   I'm running off a bench supply but via a small adjustable regulator board that has been carefully tweaked to 5.25 V.  I did that so I can't overvolt the Pi.

4.65V - 5.25V or thereabouts.

My frequency notes, I'm only using 978 SDR, not 1090
108.35- static, localizer
115.20- carrier, VOR, from SDR, matches with GU275
115.52- static
120.00- carrier w/high pitch noise, ATC, from SDR, matches w/GU275
125.00- carrier, ATC, RPi, matches w/GU275
129.60- carrier w/static, from SDR
129.87 to 129.95- static
131.12 to 131.15- static
131.60 to 131.70- static

I set out to see if the levels of the 115 and 120 MHz signal were voltage dependent but was distracted by something else.
The 115 and 120 Mhz signal pair is localized to the RTL SDR dongles.  This pair is present when either RTL is plugged in and when both are plugged in.   The pair first appears after power application just before the fan test runs.   These levels are shown in the amber trace.  1 minute and 42 seconds after power application the  level of the 115 MHz signal rises as shown in the magenta trace.
What causes this change in signal level?

There is a 90 sec delay for the R-Pi start up to the activation of the SDRs to give the GPS a chance to lock.  Does the SRD levels return to the lower value when they are turned off in the WebUI?

@merricke Is that data with or without your "spaghetti" fix?

"Does the SRD levels return to the lower value when they are turned off in the WebUI?"
No, the levels stay constant at the high level when both 1090 and 978 are selected to off.  However, if Stratux is re-booted with both selected off, the 115.2 MHz signal stays at the low level. The level rises at each  SDR when that SDR is later selected to on.

@GitUser275 Interesting that it stays the same level when the SDR is turned off in the IU.  I suspect the 115.2 MHz signal is the forth harmonic of the 28.8 MHz SDR master clock.  The 125 MHz signal is the clock frequency of the USB/Ethernet chip on the Raspberry Pi.

It is possible that turning the SDR off disables only part of the device and the master oscillator may remain on. You could physically remove the SDR to find out.
Also know that a good DC ground is not necessarily a good RF ground. I would provide a ground wire (grounding braid is best) 14g or better if there is no metal airframe to use.
I’ve seen many noise issues with, for example, handi-talkies greatly improved with a good ground.
Rick  Hole

@Axtel4 Without the wire cage.  I concentrated on getting the Pi's 125 carrier attenuated, never made a comprehensive test later.  I saw a significant improvement when grounding the heat sinks and another drop with the wire rat's nest.  My plane's radios are back to normal, not breaking squelch and no extraneous noise on the freq's I use.
The early power supplies I had were a main source of noise, I believe.  With the better power supplies I haven't experienced any noise problems.

"No, the levels stay constant at the high level when both 1090 and 978 are selected to off."
I repeated the test this morning.  I see that the signal at the 978 SDR reduces when it is selected off with the GUI.  The signal at the 1090 SDR does not reduce when it is selected off with the GUI.    I did repeat the test several times this morning, with and without a GPS connected, and the results are consistent.  978 signal is controlled by UI on/off but 1090 signal is not controlled by UI on/off.
As observed yesterday - if both are selected off, then the Stratux is booted, the low level signal is seen at both SDR.
I suspect my observations of yesterday were invalid because the GPS USB connector prevented close positioning of the probe over 978 SDR.  In today's test I moved the GPS to a different USB port to allow close contact of the probe with either SDR.

@GitUser275  Have you happened to connect the SA directly to the SDR antenna port and swept the frequency band?  Also tried connecting the SA to the antenna port through a directional coupler and a Sig gen to the coupled port with injecting an in band signal and sweep the frequency band?

"Have you happened to connect the SA directly to the SDR antenna port and swept the frequency band? Also tried connecting the SA to the antenna port through a directional coupler and a Sig gen to the coupled port with injecting an in band signal and sweep the frequency band?"
Simple answer to both - No.
I'm willing to investigate what is transmitted by each SDR but you'd need to specify what frequency range you are interested it.
I don't understand your proposed use of the directional coupler.  Typically an SA with TG and directional coupler are used to characterize S11 of an antenna system and I have made such measurements on my station antennas.  Why would you want to connect the coupler to the SDR antenna port?  What are you expecting to measure?

Here's a sweep up to 3.2 GHz with the SA connected directly to the antenna ports, as suggested by @Axtel4. v1.4r3, dual band unit with internal GPS, in the white ABS case ("pre-built" configuration). This is important since the pre-built config has the antenna feed looped over the top of the Pi, so there may be some noise coupled onto the antenna feed from that (maybe the Wi-Fi stuff).
Magenta is baseline (Stratux off, SA input not connected to Stratux). Blue is peak hold while connected to the port and Stratux on (with uptime 2 minutes+). There's a peak at 345.6 MHz from something outside of Stratux, not sure what.
1090 port:
Peaks at
85.33 MHz @ -85.83 dBm
115.20 MHz @ -84.95 dBm
230.40 MHz @ -81.82 dBm
345.60 MHz @ -78.71 dBm (external noise)
1540.27 MHz @ -79.82 dBm
1902.93 MHz @ -80.04 dBm
2184.53 MHz @ -69.04 dBm
2410.67 MHz @ -65.25 dBm

978 port:
85.33 MHz @ -85.83 dBm
115.20 MHz @ -84.77 dBm
230.40 MHz @ -81.82 dBm
345.60 MHz @ -78.71 dBm (external noise)
1540.27 MHz @ -79.57 dBm
1902.34 MHz @ -80.04 dBm
1958.40 MHz @ -75.69 dBm
2184.53 MHz @ -69.04 dBm
2410.67 MHz @ -65.25 dBm

@GitUser275
Looking at the output of the SDR antenna port will show if there is any LO leakage or oscillations being emitted from the SDR.  Stray signals radiating for the antenna port would require other mitigation efforts that shielding the SDR.
Using the directional coupler and the external generator allows the measurement of the generation of intermod products at the front end of the SDR in the presence of strong nearby signals.  For example, if the SDR has ESD clamping diodes at the antenna port, a strong signal entering the antenna port could cause the creation of intermod distortion across the PN junction of the clamping diode.  I've also seen radiated intermod products created at the output of receiver preamps in the presence of strong signals.
A better method would be to inject the signal though a circulator, but most home labs don't have one available so a directional coupler is substituted.

@cyoung
Thanks.  That is an interesting look.  As stated above, one of the potential interference sources is unintentional radiated emissions from the antenna port.  The 115.2 MHz signal appears to be a reoccurring theme.  I wonder if the received noise at that frequency is affected if a dummy load is placed on the SDR antenna port?

@Axtel4
I understood why you wanted the antenna port scan but was not aware of that technique for evaluation of front end intermod.   I'll try to find some references.   Maybe you can point me to some?
I don't think  I want to send my time evaluating RTL based receivers though.  I don't expect much for $15.

@GitUser275 Dirty world we live in; my wifi router puts out a carrier at 120.
Interesting that your grounding of the heat sinks had different results from mine: puzzling.
Which components seem to benefit from the 'finger' grounding?

(Cross posted this in Slack.)
I did the (mostly) shielded Ammo Box text yesterday. Yes, there is noise being radiated from the antennas. That was the best case test for a Stratux. Everything in the box (Pi, battery, SDR's) with only 978, 1090 and GPS antenna outside.
BTW, it seems that the GPS cable is conducting and then radiating noise. So I might have to braid that.
Otherwise, with the braid on my power cable and most of the 1090 SDR, most of the COM noise is gone.
Now that the noise floor has dropped a bit, I'm finding that the 978 SDR is causing trouble. So am going to copper foil that today before flying tomorrow.

I wonder if the new pi.3.+ with a faster processor speed and a metal cap over the chip might attenuate or move the interference out of our band.

Another fix was found when a monitor was turned off. In this case an hdmi, the -380 pulse dissapeared.
If I have entered this discussion in error, I apologize.


Issue with ansible code in main.yml when creating tcp options

OKIt v 0.8.0
When: Create a diagram with security list having ingress or egress rule with tcp options. After exporting this into ansible, the main.yml shows max and min variables without quotes.  This is causing issues with parsing yaml. Once i put them in quotes the issue gets resolved.
For example:
+--------------------------------------+
tcp_options:
destination_port_range:
min: {{ Okit_Sl002_ingress_rule_01_tcp_dst_min }}
max: {{ Okit_Sl002_ingress_rule_01_tcp_dst_max }}
# Required
- protocol: "{{ Okit_Sl002_ingress_rule_02_protocol }}"
source: "{{ Okit_Sl002_ingress_rule_02_source }}"
# Optional
source_type: "{{ Okit_Sl002_ingress_rule_02_source_type }}"
tcp_options:
destination_port_range:
min: {{ Okit_Sl002_ingress_rule_02_tcp_dst_min }}
max: {{ Okit_Sl002_ingress_rule_02_tcp_dst_max }}
# Optional
+--------------------------------------+

Fixed in 0.9.0 odd though given they are integer values


Use the same output rules for both meshed and not meshed networks

closes #2255
According to -m owner --gid-owner {gid} -p tcp -j RETURN rule the agent traffic should be unaffected and -o lo should limit to localhost requests only.
Looks working =]

Checked with sidecars and everything worked as expected


Topic Detection (Read) supported

new param topics added for topic detection for /readrequests

See Beta Docs for more information on how this API will operate.

PR https://github.com/deepgram/deepgram-dotnet-sdk/pull/217 merged. Closing.


SliverFillRemaining does not fill overscroll even with fillOverscroll option

https://gist.github.com/radroot1/20e9ddb183f638c83258fadf92dfb093
[✓] Flutter (Channel stable, v1.9.1+hotfix.6, on Mac OS X 10.15.1 19B88, locale en-RU)
[✓] Android toolchain - develop for Android devices (Android SDK version 29.0.2)
[✓] Xcode - develop for iOS and macOS (Xcode 11.1)
[✓] Android Studio (version 3.5)
[✓] IntelliJ IDEA Ultimate Edition (version 2019.1)
[✓] VS Code (version 1.35.1)
[✓] Connected device (2 available)

It was normal in previous version of flutter. I do not remember which, but in the gist I attached code of SliverFillRemaining that worked

/cc @Piinks

Hi @radroot1, thanks for filing this issue.
It looks like in the gist you have provided, the white Container that is a child of SliverFillRemaining has no size on its own, and in the gif, the extent to which you have scrolled in your list is beyond the size of the screen. In this case SliverFillRemaining has no 'remaining' space to fill, so it defaults to the child's size, which in this case is nothing. I think this is why there is nothing showing up at the end of your list. I also think this is the expected behavior as laid out in the API documentation for SliverFillRemaining.
You mentioned it working in a previous version of Flutter, would that previous version have included fillOverscroll? Or did that previous version not have the fillOverscroll option? I noticed in your gist you have a CustomSliverFillRemaining that uses an older implementation which does not have the fillOverscroll option. This will help identify the earlier version you referenced.

Hello.
Yes, it did not had that option. Hmm, I just found old log file, I believe it was 1.7.8+hotfix.4

Great! Thanks for that.
It looks likes that is correct. The fillOverscroll property was introduced in #35810 and was first tagged in v1.8.3.
The previous implementation of SliverFillRemaining had a bug where it provided enough space to fill the entire screen - rather than the 'remaining' space. Is this the behavior you are expecting?

Hmm, I am looking the way to fill overscroll not exactly the sceen, but it seems that this bug is what I need    :)

Ok! Can you describe the behavior you would like to see?

The intent is to have a background overscroll different from overall background.
For example If we have transparency effect in the header part, but we want to keep the color of overscroll to color of the content, this is useful. But right now there is no way to do that through standard components

Hm, fillOverscroll seems to be working when I have child container with Align and not zero height like in example, this is weirdly specific

You are right! It is very specific. The concept of filling the 'remaining' space in a scroll view is tricky. Scroll views can scroll on infinitely, so setting rules for defining 'remaining' space are strict.
In the examples you mentioned from the API docs, while the container may not have an explicitly set size, its child does (like an Icon or a Button). This is the size that informs the enclosing sliver.
I like your idea of being able to use this sliver for just customizing the overscroll area separate from the background, without an actual child to draw otherwise in the scroll view. I'll see if this is something I can adjust to make possible. :)

OK, thanks :)

#45121 has been closed in favor of refactoring this widget for better read/review-ability.
I don't anticipate that delaying this fix for too long, but will keep this updated as the fix gets closer to landing. :)


Change device_test from integration test to unit test

file location: core/clients/metadataclients/device_test.go
cc @tsconn23 and @drasko
claim it~

not at this time


Create a DriveSubsystem and Start Controlling Motors

Create a new subsystem for controlling the drive, and get the robot (barely) moving.

Create a new subsystem, either by deleting or renaming the ExampleSubsystem.
Add dummy methods to the subsystem for controlling both sets of motors.
Add the Pheonixv5 vendor library in order to create motor controller objects.
Create motor controller objects and implement the dummy methods to set voltage to them. Remember that there are two motors connected to each gearbox, so be careful to spin them in the same direction. You should then combine them in MotorControllerGroup objects, as we will need that later.
Instantiate the subsystem in RobotContainer, and add button bindings to run the motors.

Does it build?  Does the robot move? Ask someone for help if you get stuck or it seems like you're breaking the robot.
Also, be sure to make a commit to git often, with a message describing what you've done since your last one. We need to go over pull requests soon, but for now, just make sure you push at the end of the day. You shouldn't need to track down a specific laptop every time shop meets.

All work is done in this ticket except for RobotContainer work. This is being carried forward in #14. Closing this ticket


The 22.3 version introduces bug with dataset.pushData([{...}, {...}])

Describe the bug
If you try to push an array of data to a dataset locally, a json file is created containing whole array. Previously it created a json file for each of the objects in the array. Downgrading to ^0.21.10 solved my problem.
To Reproduce
On 22.3 version:
const dataset = await Apify.openDataset('test');
dataset.pushData([{a:'a1'}, {a: 'a2'}]);

This creates:
[{a:'a1'}, {a: 'a2'}]

Expected behavior
I expect two json files to be createdL
{a:'a1'}

{a: 'a2'}

System information:

OS: windows 10
Node.js version v12.5.0
Apify SDK version 0.22.3

Confirmed, will fix today. Thanks for the report.

Confirmed, will fix today. Thanks for the report.

Fixed in 0.22.4

Fixed in 0.22.4


Using Illuminate\Support\Carbon for dates will help data marshalling

Using laravel's extension of Carbon will help serialization control as per Date Serialization.
https://github.com/Maatwebsite/Laravel-Excel/blob/a8baf7de1030d261318f90fa5c273a47ef616b59/src/Maatwebsite/Excel/Parsers/ExcelParser.php#L3
Ideally, something like this should somehow work:
new Carbon(json_decode(json_encode(Carbon::now(), true), true));

Can it be this simple?
On a related note: https://github.com/briannesbitt/Carbon/pull/673

This is not something I can change in 2.1 anymore. I'll look into changing it in 3.1


[Missing SNMP Polling Profile] Moxa NPort 5650-8

Device Vendor: Moxa
Device Model: NPort 5650-8
System Object Identifier (SysOID): .<IP_ADDRESS>.4.1.8691.2.7
List of critical metrics that you expect in the profile (does not need to be all-inclusive, just a general idea of your expectations):

CPU stats
Power supply status
Interface status

If there is a New Relic technical support case related to this request, please provide the case number:
Please provide a public gist with a sanitized (sensitive information removed) SNMP walk of the device. Providing MIB files is not a substitute for an SNMP walk and failure to provide one here will result in delays for closing this issue. The output of these commands shows the "true story" of what a device will respond to in SNMP and is used to ensure that our profiles are efficient and accurate for your devices.
Gist Link: https://gist.github.com/cstoli-92/d484c5431e98288a2045def4553e5123

Example SNMP walk commands:
# v2c example
snmpwalk -v 2c -t 10 -On -c $COMMUNITY_STRING $IP_ADDRESS . >> snmp_walk.out

# v3 example
snmpwalk -v3 -t 10 -l authPriv -u $USERNAME -a MD5|SHA -A $AUTH_PASS -x DES|AES -X $PRIV_PASS -ObentU -Cc $IP_ADDRESS . >> snmp_walk.out

@cstoli-92 - your provided SNMP walk looks to have timed out in the middle of the SNMPv2-MIB
.<IP_ADDRESS>.<IP_ADDRESS>.0 = Counter32: 0

We expect a fully completed walk to have much more information, and the majority of devices will have their most valuable performance metrics in the private side of the MIB tree (.<IP_ADDRESS>.4.*)
Can you try again and increase the timeout value please?
# v2c example
snmpwalk -v 2c -t 30 -On -c $COMMUNITY_STRING $IP_ADDRESS . >> snmp_walk.out

# v3 example
snmpwalk -v3 -t 30 -l authPriv -u $USERNAME -a MD5|SHA -A $AUTH_PASS -x DES|AES -X $PRIV_PASS -ObentU -Cc $IP_ADDRESS . >> snmp_walk.out

If that doesn't work, you can try targeting the private MIB space directly:
# v2c example
snmpwalk -v 2c -t 30 -On -c $COMMUNITY_STRING $IP_ADDRESS .<IP_ADDRESS>.4 >> snmp_walk.out

# v3 example
snmpwalk -v3 -t 30 -l authPriv -u $USERNAME -a MD5|SHA -A $AUTH_PASS -x DES|AES -X $PRIV_PASS -ObentU -Cc $IP_ADDRESS .<IP_ADDRESS>.4 >> snmp_walk.out

I've updated the gist with the new contents. Although I don't think it's any different. The second option you provided has even less results.

@cstoli-92 I did some poking around on the internet and these Moxa serial adapters don't appear expose any resource utilization metrics at all, just the IF-MIB and the TCP-MIB.  Our default profile already contains the IF-MIB and we have opted not to include the TCP MIB in most profiles because it has a very poor signal to noise ratio, lots of data but it doesn't really help our users troubleshoot problems to justify the expense of storing it all.  These devices do not need a special profile as there is nothing that they offer in SNMP that we don't already get from the base.


Make stats update concurrent

Setting hive.collect-column-statistics-on-write = false causes queries to be stuck in the finishing state due to synchronization in updatePartitionStatistics. Setting this property is necessary with large number of concurrent queries (10+) and large number of partitions (1500 + ).
Stats update could be improve by:

making it concurrent of possible
avoid fetching/updating column stats if these are not being updated

An alternate stop-gap approach would be to introduce a property that disables stats update completely.
For more detail, see https://prestosql.slack.com/archives/CGB0QHWSW/p1574880608345400

causes queries to be stuck in the finishing state due to synchronization in updatePartitionStatistics

@JamesRTaylor did you see https://github.com/prestosql/presto/pull/2154?

Thanks, @findepi. I’ll close this one as a duplicate.


Expose app name of ledger devices

Requirement for #158.

I'm not sure that it is useful to expose this information. I think it would be better if we just didn't enumerate a device if it wasn't in the Bitcoin or Bitcoin Testnet apps.

@achow101 ok, so just ensure app matches the command network and fail otherwise?

For mainnet, make sure it only matches "Bitcoin". For testnet, I think it should match both "Bitcoin" and "Bitcoin Test" (for testing, sometimes it's easier to just use the mainnet app with --testnet).

I wouldn't mind it throwing an error if the app name isn't what's expected. Right now it's semi mysterious at points.

Superseded by #473


I've tried your prj-tensorrt,but my GPU compute version is different from you.Could you upload an origin model so that I can convert id by my self.

_No description provided.

Onnx original model is in the models directory.


create-user-provided-service failing when creating a service of the same name in different spaces within a single org

I have 2 spaces (staging and prod) within a single organization:
My pipeline creates a user defined service in each of these spaces using the same service name in each space.  The service is created without issue in the first space, but fails when creating the service in the second space stating that a service with the same name already exists.  I have verified that the service does not exist in the second space, and the correct space name is being used when creating the service in the second space.  NOTE: it may not matter, but the services are created in 2 separated jobs within the pipeline.
Staging Space
[INFO] Executing create-user-provided-service: luna
api endpoint:   https://api.sys.prod.us-west-2.cernercf.io
api version:    2.98.0
user:
org:            CernerDirect
space:          staging
Creating user provided service luna in org CernerDirect / space staging as cernerdirect-bot...
OK
Prod Space
[INFO] Executing create-user-provided-service: luna
api endpoint:   https://api.sys.prod.us-west-2.cernercf.io
api version:    2.98.0
user:
org:            CernerDirect
space:          prod
[INFO] Service luna already exists
This can be easily reproduced by creating 2 spaces in an org and attempting to create a user defined service of the same name in the two different spaces.

Can you share a snippet of your pipeline.yml with the important bits?
On Fri, Feb 16, 2018 at 12:53 PM Greg Meyer<EMAIL_ADDRESS>wrote:

I have 2 spaces (staging and prod) within a single organization:
My pipeline creates a user defined service in each of these spaces using
the same service name in each space. The service is created without issue
in the first space, but fails when creating the service in the second space
stating that a service with the same name already exists. I have verified
that the service does not exist in the second space, and the correct space
name is being used when creating the service in the second space. NOTE: it
may not matter, but the services are created in 2 separated jobs within the
pipeline.
Staging Space
[INFO] Executing create-user-provided-service: luna api endpoint:
https://api.sys.prod.us-west-2.cernercf.io
https://api.sys.prod.us-west-2.cernercf.io api version: 2.98.0 user:
cernerdirect-bot org: CernerDirect space: staging Creating user provided
service luna in org CernerDirect / space staging as cernerdirect-bot... OK
Prod Space
[INFO] Executing create-user-provided-service: luna api endpoint:
https://api.sys.prod.us-west-2.cernercf.io
https://api.sys.prod.us-west-2.cernercf.io api version: 2.98.0 user:
cernerdirect-bot org: CernerDirect space: prod [INFO] Service luna already
exists
This can be easily reproduced by creating 2 spaces in an org and
attempting to create a user defined service of the same name in the two
different spaces.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/patrickcrocker/cf-cli-resource/issues/20, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAigjf1-dY-mEQzprpten81Jl_gC-Klzks5tVeq7gaJpZM4SI6Ph
.

Let me know if you need more:
resource_types:

name: cf-cli-resource
type: docker-image
source:
repository: pivotalpa/cf-cli-resource
tag: latest

resources:
.
.
.
PCF resource for performing tasks in dev cloud foundry instance

name: cf-cli-prod
type: cf-cli-resource
source:
api: ((cf-prod-api))
username: ((cf-prod-username))
password: ((cf-prod-password))
skip_cert_check: true
.
.
.
jobs:

name: pave-staging-space
build_logs_to_retain: 10
plan:

put: create-staging-services
resource: cf-cli-prod
params:
commands:

command: create-user-provided-service
org: ((cf-org))
space: ((cf-space-staging))
credentials: ((cf-staging-luna-config))
service_instance: luna
.
.
.

name: pave-prod-space
build_logs_to_retain: 10
plan:

put: create-staging-services
resource: cf-cli-prod
params:
commands:

command: create-user-provided-service
org: ((cf-org))
space: ((cf-space-prod))
credentials: ((cf-prod-luna-config))
service_instance: luna

Got it.  I can reproduce this.  I should have a fix out in the next couple of days.

OK, I lied... this fix is simple and is being built in the CI pipeline now:
https://wings.concourse.ci/teams/sme-pcf-concourse/pipelines/cf-cli-resource/jobs/build/builds/22
Once this passes the integration tests, I'll cut a release later today :-)

Outstanding.  Thank you.

Fixed in v2.4.3/latest


[11.x] Add Guard Parameter Support to Authentication Redirection Logic

This PR enhances the RedirectIfAuthenticated and Authenticate middleware by introducing support for guard parameters in the redirection logic.
These additions allow for more granular control over the redirection process based on the guard used during authentication. It modifies the handle method to accept variable guard(s) parameters and adjusts the redirectTo method to utilize these guards when determining the appropriate redirect path.
This feature is particularly useful in applications with multiple guards, enabling distinct redirection paths for different types of authenticated or unauthenticated users.
Key Changes:

Modified the handle method to accept various guard parameters and process them accordingly.
Updated the redirectTo  method to include an optional guard parameter, allowing for guard-specific redirection logic.
Modified the unauthenticated method in Authenticate  to pass the guards array to the redirectTo method, ensuring that redirection logic can be customized based on the guards involved in the authentication attempt

Benefits:

Increased flexibility in handling post-authentication redirects for applications using multiple guards.
Allows for customized redirection paths based on the type of authenticated user, improving the user experience.
Provides a more dynamic and context-sensitive redirection strategy for unauthenticated users, improving the overall user experience.
Enhances the middleware's capability to support applications with complex authentication requirements, including those using multiple guards.
Allows developers to implement guard-specific redirection logic, offering a higher degree of customization for application routing.

This is a BC break. Even if the methods are protected, almost everyone extends these middleware.

@itxshakil please attempt master, thanks.

@driesvints
For backward compatibility, we can additional method that can have a guard-aware redirect.
    /**
     * The callback that should be used to generate the authentication redirect path for guard.
     */
    protected static $redirectToCallbackGuard;

    /**
     * Handle an incoming request.
     *
     * @param  \Closure(\Illuminate\Http\Request): (\Symfony\Component\HttpFoundation\Response)  $next
     */
    public function handle(Request $request, Closure $next, string ...$guards): Response
    {
        $guards = empty($guards) ? [null] : $guards;

        foreach ($guards as $guard) {
            if (Auth::guard($guard)->check()) {

                if (static::$redirectToCallbackGuard) {
                    return redirect(call_user_func(static::$redirectToCallbackGuard, $request, $guard));
                }

                return redirect($this->redirectTo($request));
            }
        }

        return $next($request);
    }

    /**
     * Specify the callback that should be used to generate the redirect path for guard.
     *
     * @param callable $redirectToCallback
     * @return void
     */
    public static function redirectUsingGuard(callable $redirectToCallbackGuard)
    {
        static::$redirectToCallbackGuard = $redirectToCallbackGuard;
    }
}


Can't replicate results

Hi, I'm trying to replicate the results reported in the README. So far, without changing anything except the paths, I got 14.25 BLEU in the 12th epoch instead of the 23.25 that you get in the README. Is there something I have to change from the code to reach that part? I have checked and it used Adam with the recommended learning rate.
Thanks in advance

The problem is with the imgread. If you import it from another package, it will load the images in the scale [0,1]. Therefore, you need to multiply them by 255 or store them as a float in the HDF5 file.

Where is imgread being used? I am facing the exact same issue


feat(build): concat all src files into app.js and transpile them as SystemJS

Now, source files all get concatenated as app.js in the dist folder, and that gets loaded in the index.html.
We will do the same thing for vendors, concatenated as vendor.js.

:+1:


Images For Being referenced

This is not an actual issue, it is just a hack to let me link to this images elsewhere in the repository


Split aprinter to run on two processors?

Hi Ambroz,
congratulation to that code!. It shows me that C++ is usable again and really good on controllers (I dropped that language before it hat good templates).
My Idea is to run a firmware an two processors: a simple and cheap one does the real-time part (mostly do steps, measure temperatures, switch heaters). The other one does complex calculations like coordinate transforms for delta with bed level corrections, etc. A powerful processor could even do 3d-splines to correct some bad hardware geometry. It should also run the PIDs for temperature control (the is no really hard timing requirement). A little bit tricky will be endstops - should be real time or?
The low-level processor can be a cheap avr board like ramps+atmega328.
The high-level processor could be a rasberry, an arduino-tablet or even an old android-phone. Cool would be an esp8266. It has al lot of computing power and (program-)memory compared to avr and cost nearly nothing...
aprinter seems to be a good starting point due to it's modularity. Were would You put a binary interface? I would do serial communication over uarts in first step.

Hi,
Thank you for interest in my software.
I have to admit that I'm not that fond of separating functions into a secondary processor. On the one hand, one typically needs this only to achieve high performance not many people may need, and on the other hand when done, it restricts the future design of the software, and may be highly coupled to specific hardware. So please understand that I prefer to work on features where you stay in a single processor.
I agree that my firmware may be more suitable to implement this due to the modularity and abstractions. But those abstractions were designed with one processor in mind. So while it may look like you could replace the AxisDriver component (responsible for step timing) with something that communicates with another processor, this is not so easy because AxisDriver relies on something else (MotionPlanner) to provide a buffer of commands in memory, and it only asks for the "next command" when one is finished.
It may be easier to use a coprocessor with shared memory. The LPC processor that Smoothieware v2 uses has this, with a primary M4 code and secondary M0 core, which one may use for stepping. Anyway I definitely think using an AVR is a bad idea, due to its slowness.
Regards,
Ambroz

Hi,
sorry, forgot that issue. I was in a completely different context for a while...
Thank You for detailed answer. You are right. Looking at chip prices, AVR is totally obsolete.
But my Idea is giving existing printers a push. AVR is not too slow in things it can do best: switching ports and calculating variables of type int16 or smaller. Executing steps is no problem. What stops me for now is doing acceleration because I want to avoid divsion (timer delay ~ 1/speed). Maybe a piecewise linear approximation of timer delays can do it. That can be easily calculated with bresenham.
For now I'll push that idea to attic.
Regards,
Jörg


Example cases: heat exchangers

Reported by fcasella on 2 Jun 2008 22:06 UTC
Develop example cases for different heat exchangers.
Geometry: shell&tube, plate, others (co-current, counter-current, cross-flow)
Fluids: gas-gas, gas-liquid, liquid-liquid.

Migrated-From: https://trac.modelica.org/Modelica/ticket/327

Modified by fcasella on 19 Nov 2008 10:49 UTC

Modified by fcasella on 19 Nov 2008 13:57 UTC

Comment by msielemann on 26 May 2009 13:59 UTC
Discussed at the Design Meeting 62 in Lund:
Kilian Link volunteered.

Comment by msielemann on 23 Mar 2010 10:57 UTC
Design Meeting 66 (Hamburg): Creating tests has higher priority than creating examples.

Comment by msielemann on 23 Mar 2010 10:57 UTC
moved from https://trac.modelica.org/Modelica_Fluid/ticket/14

Comment by dietmarw on 27 Jan 2011 12:43 UTC
Milestone Modelica_Fluid 1.0 w/ more examples deleted

Modified by ahaumer on 6 Mar 2012 16:31 UTC


feat: hello world

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

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


Select between ._fit() of .fit() depending on the sklearn version used

Scikit-learn changed their API between versions 1.2.2 and 1.3.0, replacing BaseDecisionTree.fit() with BaseDecisionTree._fit().
I check the sklearn.version field before calling one or the other.

Thanks @lccatala !
Although your code does the trick, it would probably be more readable/maintainable to rely on Version. I suggest that you add the two following constants at the top of the file instead :
from packaging.version import Version

SKLEARN_VERSION = Version(sklearn.__version__)
SKLEARN13_OR_GREATER = SKLEARN_VERSION >= Version("1.3.0")

Then you can use SKLEARN13_OR_GREATER in your if test in place of the variable you had created from the version tuple
Thanks !

Also, can you please add a new changelog section 0.3.2 - Fixed compliance with sklearn 1.3.0 containing a single entry with your contribution ? Please look at the previous entries for an example.
Thanks again !

from packaging.version import Version

SKLEARN_VERSION = Version(sklearn.__version__)
SKLEARN13_OR_GREATER = SKLEARN_VERSION >= Version("1.3.0")

Didn't know that existed, thanks!

Release is now available. Thanks a lot !


Set Position Independent Code ON

This was needed in order to build the created static library in a way that it can be linked to dynamically loaded libraries (e.g. a nodelet).
FYI @hamalMarino

Reminder: before merging we need to make sure this is compiling in the Android app, as we are merging against the branch used to build TangoApps.

Will merge it, as the CMakeLists.txt file should not be used for building the library with Android (which was the concern here).