[main_samview] fail to read the header from "test_example.slow5".

Here is the file:
The error ("fail to read header") is a bit unhelpful in diagnosing the problem. I also have a larger example that was failing as well, I'll put it at the bottom.
The simple example failing:
#slow5_version	0.2.0
#num_read_groups	1
@asic_id<PHONE_NUMBER>
#char*	uint32_t	double	double	double	double	uint64_t	int16_t*	uint64_t	int32_t	uint8_t	double	enum{unknown,partial,mux_change,unblock_mux_change,data_service_unblock_mux_change,signal_positive,signal_negative}	char*
#read_id	read_group	digitisation	offset	range	sampling_rate	len_raw_signal	raw_signal	start_time	read_number	start_mux	median_before	end_reason	channel_number
0026631e-33a3-49ab-aa22-3ab157d71f8b	0	8192	16	1489.52832	4000	5347	430,472,463	8318394	5383	1	219.133423	5	10

The full example failing:
#slow5_version	0.2.0
#num_read_groups	1
@asic_id<PHONE_NUMBER>
@asic_id_eeprom	5910407
@asic_temp	31.649540
@asic_version	IA02D
@auto_update	0
@auto_update_source	https://mirror.oxfordnanoportal.com/software/MinKNOW/
@barcoding_enabled	0
@basecall_config_filename	dna_r9.4.1_450bps_sup.cfg
@bream_is_standard	0
@configuration_version	4.3.11
@device_id	MN33517
@device_type	minion
@distribution_status	stable
@distribution_version	21.06.10
@exp_script_name	sequencing/sequencing_MIN106_DNA:FLO-FLG001:SQK-LSK109
@exp_script_purpose	sequencing_run
@exp_start_time	2021-10-25T16:34:06.237443-07:00
@experiment_duration_set	1440
@experiment_type	genomic_dna
@file_type	multi-read
@file_version	2.3
@flongle_adapter_id	FA-02253
@flow_cell_id	AEI279
@flow_cell_product_code	FLO-FLG001
@guppy_version	5.0.13+bbad52987
@heatsink_temp	35.003906
@host_product_code	unknown
@host_product_serial_number	.
@hostname	trilo
@installation_type	nc
@local_basecalling	1
@local_firmware_file	1
@operating_system	ubuntu 18.04
@package	bream4
@package_version	6.2.6
@pore_type	not_set
@protocol_group_id	op_1
@protocol_run_id	ebe410af-7ff2-4117-9bff-f1bbae5be87d
@protocol_start_time	2021-10-25T16:33:39.151434-07:00
@protocols_version	6.2.6
@run_id	521e7966d4fd3d8fd57e3c264b9babd253db4c96
@sample_frequency	4000
@sample_id	no_sample
@sequencing_kit	sqk-lsk109
@usb_config	MinION_fx3_1.1.1_ONT#MinION_fpga_1.1.0#bulk#Auto
@version	4.3.12
#char*	uint32_t	double	double	double	double	uint64_t	int16_t*	uint64_t	int32_t	uint8_t	double	enum{unknown,partial,mux_change,unblock_mux_change,data_service_unblock_mux_change,signal_positive,signal_negative}	char*
#read_id	read_group	digitisation	offset	range	sampling_rate	len_raw_signal	raw_signal	start_time	read_number	start_mux	median_before	end_reason	channel_number
0026631e-33a3-49ab-aa22-3ab157d71f8b	0	8192	16	1489.52832	4000	5347	430,472,463,467,454,465,463,450,450,449,449,391,402,412,420,407,414,423,423,412,401,408,407,432,393,417,411,404,414,408,412,405,411,422,427,372,376,404,411,423,395,419,418,411,405,408,408,419,427,411,419,405,409,439,416,424,402,439,416,411,426,391,393,414,402,413,396,404,420,419,426,393,415,423,407,423,406,412,426,412,390,410,408,421,434,407,417,417,420,410,434,427,425,429,421,424,438,412,433,414,406,415,403,415,420,409,418,413,441,411,406,413,412,394,421,417,417,442,411,417,418,413,410,421,408,428,410,434,403,419,413,422,412,435,434,421,427,432,418,425,417,410,414,413,412,414,424,420,416,408,430,406,424,420,419,431,421,439,435,416,424,401,443,427,406,415,423,430,418,418,417,421,425,434,427,434,405,428,428,423,427,409,411,403,412,406,423,409,427,421,437,424,411,422,408,414,421,409,405,416,425,431,437,427,423,426,428,425,427,430,411,420,414,416,432,426,414,405,415,404,400,410,420,409,408,432,417,412,423,421,424,411,423,413,430,420,427,421,430,405,417,415,430,416,419,430,425,415,421,433,418,415,413,417,409,422,417,412,420,426,427,433,430,429,432,414,409,434,438,422,416,405,424,411,425,431,434,434,415,423,421,426,414,421,411,420,416,411,437,437,423,423,420,414,436,410,423,419,427,417,411,411,430,423,423,421,407,414,420,419,413,413,413,407,421,432,434,440,432,426,427,432,409,417,417,423,417,406,412,426,421,426,430,421,418,420,420,422,419,423,415,424,413,414,432,430,405,398,411,411,409,408,424,425,409,417,420,411,439,428,436,433,411,399,402,409,424,408,415,416,414,400,408,416,419,402,424,435,410,401,414,429,411,406,418,423,433,410,420,422,428,428,410,406,409,430,397,442,401,422,414,399,419,428,433,424,417,413,416,410,420,427,422,428,435,416,431,426,420,432,413,390,432,418,413,433,421,402,404,414,420,427,423,413,420,410,424,413,418,407,420,441,418,419,412,414,435,418,433,439,414,420,438,423,417,434,431,424,439,438,423,420,422,421,445,415,424,421,425,437,415,430,416,425,435,426,432,414,424,413,425,415,401,429,413,432,431,425,419,425,434,428,431,415,411,411,412,409,424,437,406,418,420,415,397,410,411,410,418,407,408,414,408,407,416,426,419,413,407,411,435,397,431,415,408,418,430,409,418,414,415,427,419,419,420,426,428,426,426,430,417,427,410,422,419,409,429,410,416,412,410,412,422,428,425,432,419,412,430,433,425,425,406,408,413,411,422,418,432,411,421,411,417,430,415,405,412,421,426,425,410,424,419,407,430,417,431,417,421,430,402,413,420,426,419,414,429,430,425,428,424,417,420,403,416,420,426,412,416,425,424,414,414,412,430,406,432,409,427,397,413,431,414,415,426,407,435,425,425,431,437,434,404,421,432,414,434,424,429,425,424,428,411,419,430,425,414,437,431,425,448,406,410,399,407,409,431,407,425,418,413,411,432,415,423,430,415,437,410,420,431,440,422,424,427,409,434,425,434,434,419,423,440,425,416,444,436,423,427,419,422,420,437,425,410,416,422,420,429,427,410,427,415,435,397,402,422,415,407,419,412,420,411,432,427,415,419,425,430,425,411,428,424,414,434,420,417,413,429,400,411,412,420,410,428,412,426,424,432,432,420,415,421,428,415,428,432,414,420,428,436,416,427,424,420,433,414,420,419,414,443,412,427,411,417,413,426,425,417,416,423,445,431,435,425,414,421,421,422,420,436,414,414,422,418,414,433,429,412,430,415,408,428,418,428,427,405,425,435,416,415,416,421,434,425,442,407,427,430,433,423,418,419,407,417,406,423,417,421,408,423,431,432,414,425,421,409,391,402,421,410,413,424,425,415,435,415,450,425,426,416,437,427,424,411,434,438,415,434,422,425,414,432,422,421,438,423,430,432,434,421,425,435,423,432,423,431,423,409,425,407,423,419,430,414,440,406,429,417,440,420,444,434,415,419,430,417,414,427,430,426,403,420,441,422,429,436,410,424,445,427,435,411,439,422,425,430,429,434,430,421,434,425,417,432,431,439,418,423,429,430,416,435,437,413,421,430,419,426,422,415,432,429,437,415,422,418,420,413,416,433,409,417,417,431,430,423,432,415,437,418,429,414,399,422,416,426,422,418,414,412,420,407,436,433,419,435,431,430,426,418,410,423,426,420,409,434,425,435,435,421,410,416,425,425,426,442,434,423,419,431,427,421,436,431,422,426,418,420,416,420,417,424,405,432,399,425,418,421,433,428,426,421,415,419,430,422,438,419,428,433,437,431,419,430,434,416,431,425,409,431,431,428,436,439,425,426,418,425,406,416,411,421,434,421,415,416,416,417,411,421,413,418,406,403,436,409,431,418,436,432,421,433,423,431,424,408,418,421,414,430,426,402,407,424,444,425,432,426,424,437,437,424,415,425,421,426,412,444,425,423,420,417,431,427,404,409,411,423,404,421,419,425,407,409,413,425,423,411,413,395,417,417,433,419,432,413,422,408,404,398,423,416,426,418,427,434,428,414,428,413,433,417,415,413,435,416,421,416,399,414,423,415,409,424,408,411,418,424,426,418,438,412,420,421,407,416,430,417,426,412,424,407,423,412,405,417,408,422,416,408,406,406,424,418,415,408,425,430,416,430,396,409,410,410,411,412,422,396,415,412,409,408,407,424,423,410,410,427,422,427,396,409,414,431,421,403,422,410,422,408,417,421,411,406,415,418,405,403,427,435,402,399,407,420,401,408,422,445,406,407,426,400,402,398,422,414,413,417,421,389,414,418,409,425,419,431,417,413,427,418,405,409,405,410,411,387,388,383,387,383,386,409,389,387,381,396,429,452,474,462,469,474,448,455,450,462,456,431,495,489,620,675,660,664,680,683,674,689,680,703,675,668,672,671,672,668,692,677,675,689,673,661,690,695,717,713,673,700,684,687,686,669,674,690,694,675,658,648,669,689,666,670,672,674,706,675,667,674,666,674,678,679,683,679,622,652,674,663,628,631,626,627,644,623,627,621,631,589,559,589,631,633,619,620,629,629,625,613,624,626,620,633,633,632,634,618,624,630,563,524,513,487,504,367,328,343,327,353,336,356,347,341,331,358,343,357,338,369,349,354,344,348,340,347,349,343,360,340,338,355,348,339,347,324,333,343,339,351,344,344,346,363,366,354,350,350,348,357,344,328,340,340,333,338,341,343,345,345,346,335,348,365,350,359,343,347,339,341,328,351,358,349,333,347,332,331,320,320,319,333,348,342,327,329,316,321,324,320,305,331,332,321,322,307,468,462,473,462,468,444,447,457,444,456,468,439,459,364,356,357,374,373,474,482,479,484,490,466,475,479,485,461,473,475,482,486,468,491,480,497,505,479,484,492,501,487,489,485,485,491,489,496,485,484,463,493,491,491,486,508,469,491,488,474,488,484,487,495,470,506,490,455,481,488,473,440,466,442,416,403,398,409,403,409,414,424,427,403,395,415,420,414,396,397,411,388,375,375,381,365,371,390,436,449,460,455,458,479,450,466,452,459,443,459,472,435,456,471,473,454,460,456,460,454,452,465,446,451,465,476,464,462,468,458,447,461,432,447,489,504,501,490,486,497,511,491,492,500,502,508,493,500,499,499,501,500,501,503,489,509,480,510,450,449,415,433,439,426,457,446,448,442,455,443,451,430,447,443,440,426,453,433,437,434,437,437,426,443,429,439,454,449,462,450,459,481,455,438,431,463,512,469,481,459,438,435,450,455,437,462,435,449,448,432,444,449,444,434,434,450,441,435,446,444,453,456,449,446,447,437,437,455,441,451,455,432,459,466,459,454,444,453,437,457,455,458,454,453,439,448,432,309,266,279,268,266,243,276,270,272,257,288,297,279,282,288,248,263,269,271,279,272,265,268,276,265,268,265,268,275,266,263,265,270,277,269,266,272,298,462,421,447,430,428,445,447,416,426,437,438,434,443,428,436,462,521,522,520,506,510,496,513,505,520,529,524,518,513,500,530,519,518,517,491,444,462,471,464,469,475,457,466,464,460,454,464,465,455,458,462,453,454,458,457,455,459,462,467,460,468,459,469,452,444,457,471,365,356,336,347,351,354,349,349,359,364,354,363,341,347,354,356,368,347,355,354,354,355,357,353,346,356,354,358,353,345,349,347,355,346,353,355,329,357,364,316,263,272,266,297,472,473,463,484,471,476,462,465,477,473,492,488,457,495,480,485,463,477,481,483,464,497,451,466,488,457,453,461,472,468,472,463,466,470,465,457,478,453,460,479,438,418,418,418,418,435,432,422,438,420,425,444,444,444,448,458,454,455,458,468,451,470,459,448,456,443,450,458,444,434,449,453,444,451,440,464,439,441,418,449,460,431,437,445,458,449,457,455,419,443,454,454,457,439,452,433,373,350,334,338,352,379,417,492,519,520,496,480,516,485,463,514,494,505,507,505,477,488,485,470,483,457,461,445,455,460,450,458,356,351,352,354,354,355,357,352,354,357,341,356,362,362,353,359,371,345,354,358,341,335,475,467,473,476,463,459,492,480,479,463,473,474,473,453,475,479,472,501,477,483,471,475,486,487,480,464,470,470,432,399,387,393,387,389,385,396,428,524,533,527,525,524,529,523,504,531,537,513,550,522,511,550,539,483,489,495,473,371,378,382,373,372,382,394,382,379,362,385,384,394,396,389,395,378,375,368,378,382,374,422,385,388,372,349,348,334,339,351,342,352,347,352,346,335,338,348,347,346,339,335,349,367,563,578,569,588,570,549,499,512,475,485,478,480,498,489,488,472,376,369,375,363,367,383,359,483,479,489,476,419,357,375,364,338,336,274,269,247,267,260,263,270,255,238,260,249,241,246,254,258,256,257,252,262,277,344,292,265,252,246,255,264,258,251,262,266,255,272,242,269,253,246,393,428,421,442,415,416,434,418,418,438,410,402,405,427,430,410,416,415,427,418,418,430,404,439,406,413,368,426,446,464,460,450,449,438,441,439,426,438,445,442,449,450,438,438,423,440,444,438,441,444,428,450,437,450,435,444,443,452,442,409,378,367,358,361,365,372,360,366,420,438,459,440,451,445,431,441,448,438,447,420,434,421,417,447,444,446,431,450,432,453,467,451,441,451,437,457,432,438,443,443,454,479,478,484,492,472,464,464,451,469,477,464,473,477,461,490,485,469,480,481,476,471,472,461,469,459,477,471,454,485,490,478,479,464,489,490,480,480,443,382,374,381,384,388,391,389,376,374,389,371,370,374,370,383,390,387,385,387,394,454,445,461,451,462,464,475,454,466,430,470,456,472,455,452,473,453,485,449,432,454,444,449,412,359,432,344,369,372,349,360,360,356,363,353,357,368,368,359,347,378,362,362,358,363,366,354,358,370,357,370,360,359,366,365,368,359,347,363,360,360,359,366,341,360,338,348,347,349,357,355,373,378,381,375,355,379,371,379,391,371,359,368,357,366,367,386,378,466,488,476,468,471,481,469,468,462,475,465,469,460,492,474,465,488,491,468,466,471,460,468,480,472,469,470,471,493,419,406,388,392,406,415,385,391,391,384,396,388,418,392,390,391,388,366,359,374,362,348,355,342,356,346,344,372,364,383,328,324,330,337,344,340,347,308,309,294,284,299,296,294,311,304,295,323,291,326,325,329,326,329,316,330,304,329,333,295,338,337,352,323,335,363,359,408,473,445,471,497,511,477,510,522,507,511,412,362,406,410,415,454,362,379,390,410,438,438,455,446,431,451,440,451,449,446,431,438,444,432,416,438,453,434,433,447,443,433,432,430,436,442,444,448,441,470,462,488,486,507,512,512,495,513,498,494,492,491,480,451,439,424,428,429,437,429,407,395,392,401,388,397,389,396,392,398,395,402,401,391,404,387,392,388,388,404,395,395,397,390,401,405,369,406,477,497,494,494,444,449,450,420,456,435,447,449,449,457,430,427,446,437,453,452,453,432,449,446,429,448,402,389,368,381,375,363,347,377,391,372,379,384,389,384,373,379,368,392,380,359,376,364,377,350,370,344,374,374,573,580,586,587,549,558,570,572,560,584,580,550,582,590,576,590,576,561,563,568,569,578,584,576,549,560,579,585,586,591,596,576,574,569,573,579,578,580,584,550,578,587,589,579,586,589,599,579,564,595,584,587,580,586,566,578,553,570,541,584,580,582,568,560,558,581,564,568,564,576,566,572,546,601,575,566,569,564,577,586,589,570,557,569,586,591,564,541,473,494,490,505,473,518,488,483,465,481,485,491,483,478,484,493,512,480,515,496,488,497,503,477,510,503,496,500,505,491,498,498,496,502,498,481,486,488,500,497,465,492,506,482,489,494,484,488,484,465,481,484,506,486,457,481,476,374,367,350,366,365,381,377,360,356,370,371,373,363,352,356,366,350,368,364,364,355,376,366,379,374,359,369,367,388,365,362,349,363,357,366,357,360,362,361,355,369,342,361,332,333,348,349,359,267,250,261,259,262,256,239,237,250,251,260,434,447,461,458,440,458,452,444,442,426,445,457,452,447,449,455,450,444,533,528,523,536,516,529,523,527,532,514,532,522,523,526,526,520,537,534,543,545,546,526,493,478,467,449,468,473,429,431,480,487,474,487,471,486,464,447,463,468,458,486,463,465,460,463,450,476,464,467,467,470,469,476,468,376,379,390,398,376,372,389,375,392,390,382,390,382,373,387,384,383,384,399,387,397,393,396,372,366,405,384,396,393,357,373,377,344,365,367,377,382,418,386,395,393,396,387,405,392,390,400,439,504,504,492,492,495,495,504,509,485,492,491,500,412,380,392,408,406,380,388,385,395,380,388,389,411,386,386,388,384,381,397,374,379,348,378,322,320,315,324,315,314,338,312,348,372,359,351,341,350,363,361,417,419,332,356,341,348,365,348,369,400,386,401,395,397,396,399,413,398,401,381,415,389,391,386,397,395,395,392,395,404,397,404,397,399,402,407,427,446,468,442,433,448,439,434,445,440,425,439,441,449,461,450,425,453,429,435,409,424,408,427,420,437,423,432,441,424,407,422,426,428,417,408,410,427,429,435,429,424,445,469,458,470,498,504,502,491,485,510,499,489,509,513,496,487,484,477,510,464,387,353,362,352,353,368,353,350,343,358,371,346,359,346,349,363,355,368,353,360,341,348,354,377,341,346,342,358,336,335,358,339,341,346,359,349,338,352,333,345,341,356,341,333,328,360,352,395,381,352,326,335,484,504,520,505,492,506,485,483,500,493,520,506,518,515,491,505,492,504,507,488,500,509,484,481,473,454,470,459,471,469,465,490,472,478,475,479,481,483,477,470,473,489,481,475,484,346,338,335,338,334,344,332,356,334,355,352,350,325,319,341,357,336,334,343,363,315,351,354,343,362,359,366,330,349,337,333,318,328,327,345,330,330,344,363,364,360,372,364,348,362,343,374,343,358,375,359,370,366,360,359,359,356,359,361,367,363,380,369,379,373,356,376,366,369,373,399,489,476,484,499,492,500,494,493,503,488,497,490,500,494,491,488,495,494,495,495,496,483,473,487,482,498,472,503,482,488,495,503,483,497,482,478,459,496,491,480,471,494,481,410,361,363,450,493,469,496,482,472,484,502,479,479,504,426,425,415,413,457,518,514,479,479,499,462,434,413,427,431,422,421,429,427,419,423,424,436,447,432,444,430,426,444,435,434,430,455,438,416,442,441,446,429,428,438,448,457,437,439,435,450,428,454,444,435,430,418,455,477,477,484,475,497,494,485,478,468,454,486,490,477,478,492,495,485,489,463,492,479,478,484,491,493,496,471,470,466,469,480,465,490,485,489,499,470,393,369,351,346,353,349,358,359,344,354,337,360,352,362,351,365,337,334,353,341,348,344,351,353,352,354,363,350,353,372,364,356,351,349,373,342,358,353,354,351,344,351,354,354,344,359,295,258,279,271,250,257,240,244,280,263,271,284,266,265,249,262,276,263,270,265,245,271,258,249,254,255,259,254,247,249,247,249,366,431,425,416,435,420,439,437,427,430,430,443,432,441,431,448,441,439,442,454,446,442,448,414,439,436,451,446,427,429,426,418,430,446,407,419,425,426,419,436,447,406,418,422,441,416,440,415,423,437,420,410,405,412,394,413,421,406,427,429,414,417,412,414,429,423,416,414,414,416,449,436,448,442,433,451,436,440,433,453,444,450,435,447,428,436,444,443,428,440,437,425,464,436,425,436,436,428,442,461,505,545,515,511,503,511,521,539,503,501,512,509,535,520,525,526,466,461,471,478,472,476,464,455,466,461,455,465,464,404,378,386,407,406,401,389,390,372,389,398,367,378,370,377,363,372,348,320,333,337,332,340,327,317,339,352,335,361,333,335,326,343,336,343,326,343,364,361,336,332,343,337,345,329,329,342,330,326,345,345,323,325,350,351,347,331,324,317,317,292,315,316,311,283,286,302,308,286,297,290,303,310,293,290,283,314,292,295,307,306,287,287,280,294,304,367,578,568,536,568,565,565,580,565,578,559,559,411,397,373,377,394,383,398,389,395,378,390,400,399,388,408,390,416,396,396,395,397,429,444,431,452,435,451,440,455,452,472,464,435,441,441,447,440,433,437,429,448,447,448,454,433,445,442,430,444,446,449,455,441,430,427,419,443,440,483,484,465,484,479,473,498,489,478,461,478,483,487,478,487,484,489,495,476,490,480,487,493,495,469,487,481,476,481,484,489,489,487,495,465,461,481,489,483,493,486,459,482,471,462,459,451,410,384,394,425,410,405,418,410,406,439,415,421,395,404,401,388,402,414,411,413,401,415,420,410,412,395,388,409,413,405,417,426,421,407,416,400,417,405,425,395,403,404,392,400,405,418,402,401,409,494,527,537,545,547,526,512,527,540,530,544,546,513,539,548,560,527,523,529,538,524,530,534,521,534,534,532,540,398,394,405,393,415,450,393,413,406,406,405,403,416,395,414,417,403,413,401,400,501,490,488,484,491,491,490,477,478,494,465,482,478,498,490,495,482,508,507,483,495,495,496,495,481,502,496,508,505,507,510,507,490,487,493,471,479,495,485,484,511,484,493,479,477,477,522,495,479,491,461,491,469,485,482,500,499,490,495,495,463,477,473,464,446,468,479,461,477,465,479,480,467,472,453,464,470,468,476,465,483,476,472,479,475,474,491,483,477,474,471,467,469,466,486,489,484,475,472,482,468,441,469,449,460,495,482,475,464,473,468,478,471,468,473,466,328,328,340,356,353,337,333,346,332,333,324,333,334,330,313,306,328,345,315,336,316,324,329,306,312,305,318,311,312,303,315,304,314,315,304,317,318,333,326,317,320,313,313,305,302,317,314,326,343,319,339,331,314,317,327,315,309,308,314,306,308,321,322,315,310,316,304,293,295,311,322,317,333,324,422,506,512,540,522,506,524,533,532,523,519,533,519,508,519,488,523,521,556,520,538,527,521,519,510,515,553,532,530,509,523,522,496,526,518,528,514,502,508,497,504,528,513,523,514,524,518,516,510,517,501,508,518,527,509,538,512,414,375,371,364,387,383,389,385,363,380,367,360,375,375,344,406,560,544,546,543,520,510,532,518,539,528,519,532,534,502,526,521,533,506,513,455,372,373,351,389,364,385,389,386,378,387,371,372,442,452,426,441,433,439,437,429,416,422,445,439,421,445,434,441,440,412,433,408,428,448,416,429,447,453,446,442,458,433,452,464,428,468,448,454,451,483,507,475,481,489,493,483,474,481,375,317,326,334,324,334,329,322,328,318,326,301,326,340,323,333,329,333,332,328,315,313,325,343,325,318,326,324,331,323,317,329,341,332,337,326,329,423,461,480,467,486,467,483,489,481,467,467,479,471,474,490,478,475,478,492,484,469,470,483,460,473,469,454,487,422,390,389,396,384,343,309,315,319,335,334,332,343,336,354,332,328,331,343,316,250,254,254,256,259,254,246,258,246,263,253,258,241,251,422,463,461,470,432,450,472,466,455,448,462,476,459,448,453,478,471,468,454,469,472,458,471,461,466,456,467,459,450,463,454,450,442,462,478,469,465,456,470,455,461,460,470,443,449,462,469,458,448,456,458,478,459,451,456,456,446,454,433,447,469,456,462,458,465,470,435,518,532,492,502,515,516,532,527,517,498,526,509,517,502,520,500,512,514,518,515,512,498,512,513,497,457,373,380,383,376,380,376,390,379,397,382,392,370,406,405,376,377,403,393,374,365,388,375,379,372,370,372,387,382,357,379,366,373,367,436,453,468,455,462,460,446,459,471,436,473,466,467,458,429,474,515,491,506,489,506,500,483,498,484,500,486,487,489,496,491,507,498,500,496,511,501,501,413,412,411,429,433,434,420,489,550,543,546,548,548,572,573,539,545,555,557,571,573,560,552,548,562,559,551,544,525,536,548,537,467,457,454,441,429,439,443,340,340,321,332,325,330,345,322,352,334,348,344,333,332,324,340,331,338,358,346,368,341,342,329,331,341,343,358,359,326,340,339,338,340,344,339,346,316,317,372,459,461,474,491,470,463,473,483,454,483,482,467,495,456,466,464,478,479,460,454,450,467,448,453,459,459,469,476,477,462,481,477,490,514,500,510,497,498,488,493,501,487,484,496,492,513,499,498,481,381,392,397,395,406,393,357,378,313,291,286,289,279,289,293,306,288,264,268,284,299,289,287,269,279,275,284,272,282,271,266,274,438,461,473,487,471,488,476,506,453,488,480,489,493,481,477,473,467,484,460,490,528,529,504,523,522,514,527,521,526,529,541,511,530,487,480,475,473,485,471,470,460,439,495,534,528,525,502,513,493,455,458,473,467,474,479,458,447,471,464,473,460,451,476,456,453,382,339,323,331,358,323,325,321,317,320,336,331,320,318,327,303,305,330,315,310,319,307,315,321,330,322,311,314,324,322,331,317,327,318,305,317,317,315,324,328,325,303,319,320,319,335,316,338,301,328,322,331,411,537,537,544,517,528,516,534,535,530,523,531,546,538,508,522,526,528,533,540,551,529,512,513,543,536,528,542,536,524,522,534,529,537,547,535,560,546,520,528,544,537,531,491,511,546,554,527,544,518,504,503,483,503,506,492,409,373,377,355,374,364,378,380,380,378,372,359,372,370,381,377,376,392,384,468,545,547,558,544,549,556,548,542,554,554,555,555,567,546,535,513,546,374,391,380,400,398,402,375,398,384,371,383,388,382,369,370,374,351,403,461,456,448,454,464,464,443,462,451,444,453,453,450,456,457,444,464,445,451,463,436,501,507,503,508,490,505,483,497,478,484,498,502,509,521,492,503,498,511,509,495,523,490,469,461,470,473,470,480,480,456,466,473,458,473,481,482,479,470,472,471,459,473,464,471,450,478,475,459,471,465,485,484,475,481,468,482,477,476,477,468,490,464,506,483,487,467,467,485,465,481,462,470,497,477,478,475,474,474,481,478,485,484,482,481,479,484,450,471,477,476,481,489,486,492,478,469,465,469,455,480,479,465,480,464,462,477,470,469,452,482,463,470,467,481,475,479,471,469,470,465,484,460,473,475,473,475,473,474,468,473,453,458,481,467,481,482,475,470,483,470,475,470,477,476,464,436,399,376,376,386,382,386,328,310,285,319,338,299,312,318,310,294,289,293,280,284,270,275,269,266,275,274,292,268,292,273,278,271,297,277,281,277,280,278,288,272,271,267,271,271,269,253,266,278,280,267,277,315,337,343,340,330,459,553,542,574,537,541,521,565,552,544,543,552,534,529,544,526,510,546,543,524,536,540,526,524,534,541,531,538,540,543,558,525,554,542,543,554,545,545,538,527,550,527,529,540,517,498,526,531,519,511,419,371,350,377,369,363,337,370,336,357,360,349,352,336,358,359,343,365,345,359,368,340,349,341,329,351,342,328,314,435,442,443,449,429,447,431,442,434,424,421,433,438,426,428,432,443,434,442,419,429,424,438,419,414,440,446,442,445,427,408,451,436,453,431,462,444,437,438,420,446,442,458,452,464,454,460,461,430,438,441,435,428,414,432,442,428,441,421,457,436,453,434,446,457,470,439,470,469,453,452,456,459,461,448,455,412	8318394	5383	1	219.133423	5	10

I'm specifically trying to create blow5 files to implement and test a blow5 parser in Golang, on top of / complementing the existing slow5 parser. I'd appreciate knowing what is going wrong in those headers, so I can make the two code-bases a bit more compatible!

Hello @Koeng101
Could you please attach the first example as a file here so I can investigate? When I copy-paste, the content, it seems the header is fine.
The error I get is not relevant to the header:
#slow5_version  0.2.0
#num_read_groups        1
@asic_id<PHONE_NUMBER>
#char*  uint32_t        double  double  double  double  uint64_t        int16_t*        uint64_t        int32_t uint8_tdouble   enum{unknown,partial,mux_change,unblock_mux_change,data_service_unblock_mux_change,signal_positive,signal_negative}     char*
#read_id        read_group      digitisation    offset  range   sampling_rate   len_raw_signal  raw_signal      start_time      read_number     start_mux       median_before   end_reason      channel_number
[slow5_rec_parse::ERROR] Raw signal length '5347' does not match the number of signals parsed '3'. Raw signal is potentially truncated. At src/slow5.c:2770
[slow5_rec_parse::ERROR] Missing auxiliary fields in record, but present in header. At src/slow5.c:2793
[slow5_rec_depress_parse::ERROR] Record parsing failed. At src/slow5.c:2600

Uh, I actually can't attach them, because github doesn't like the file extension. Here are where the files are.
I haven't implemented any checks yet, like with auxiliary fields or len_raw_signal.

I'm closing this because I got the command working. I have no idea what I was doing wrong, but sorry about the low quality issue! My apologies!


[zh] Update basic-stateful-set.md

Sync content/zh-cn/docs/tutorials/stateful-application/basic-stateful-set.md referring to PR #37224.
By the way, I cleanup typo which made in PR #37706.

/approve

Thanks.
/lgtm


Set profile to have custom number of terminals at the same time by default

Whenever I use VScode for my projects, I always open 3 separate terminals in the editor itself, and change the color, name and icon to be able to differentiate one from the other quickly.
One for commands (Zsh), one to have a Ruby console (irb) and one for the server (puma). Each of them with a different color and icon.

This feature request is now a candidate for our backlog. The community has 60 days to upvote the issue. If it receives 20 upvotes we will move it to our backlog. If not, we will close it. To learn more about how we handle feature requests, please see our documentation.
Happy Coding!

:slightly_smiling_face: This feature request received a sufficient number of community upvotes and we moved it to our backlog. To learn more about how we handle feature requests, please see our documentation.
Happy Coding!


Split out model binding from EditHandler.bind_to (EditHandler rewrite)

Aims to avoid some of the inconsistency around the order that binding happens in, and which items are expected to be bound before calling certain EditHandler methods - as well as bringing things a bit closer to standard Django forms framework idioms.
The model argument of EditHandler.bind_to is now split out into its own bind_to_model method. The sequence of actions performed by view code is now:

Retrieves the EditHandler instance for a given model
Call bind_to_model on the EditHandler
Call get_form_class, which constructs a form class based on the results of get_form_options from all child panels
Instantiate the form class, passing for_user=request.user along with the standard form kwargs
Call bind_to(instance, request, form)

Note that this means get_form_options must be able to return a valid result when only the model is bound - it is no longer legal to vary the form class based on the request / user.

Merged via #8123


use an sprintf implementation which supports JSON (%j)

format doesn't support JSON (%j). sprintf-js does and also has some other useful features e.g. argument swapping and named arguments.

Looks good! Actually this is something I already had on my todo list, but didn't have time to work on. Thank you!!

Any chance you could release this? (The version on NPM (0.1.0) still uses format :-)


Merge TypeScript into next branch

Closes #88
Closes #87
Closes #86
Closes #38
New, simpler structure. Replaced Flow with TypeScript. Some breaking changes.

👍

👍


Chacha8 Encryption?

Whats the difference between XXTEA and Chacha8 encryption algorithm?
In the guide is only mentions XXTEA

It is generally faster than XXTEA.
Reducing the number of rounds in XXTEA can make it faster than ChaCha, but at the cost of less security, so it's a good choice depending on the performance of the avatar you're targeting.


Check for class expressions in inspectDeclarator

Currently inspectDeclarator only checks for (arrow)function expressions, but it should also check for class expressions in the form of:
/*@ngInject*/
let MyClass = class MyClass { // or as unnamed class
  constructor (myService) {
  }
};

and
let MyClass = class MyClass { // or as unnamed class

  /*@ngInject*/
  constructor (myService) {
  }
};

If you enter the above code in the testpage WITHOUT compiling to ES5 the injection tokens won't be added.

Damned, I did the same https://github.com/schmod/babel-plugin-angularjs-annotate/pull/55
but also added a test case

Closing in favour of #55


Browser rendering of markdown file

Comparing the GitHub readme file and this hosted site of the same, one can get an idea that there is something wrong with the code.
This is a known issue and to date, I haven't found a fix for that.
The reason being, both use different markdown rendering engines as there is currently no set standard for this.
Github in-page previews use Redcarpet, rather than kramdown
More clarity in this article.
Any help is appreciated!

Could you update the link for the hosted site? Github returns a 404.

done, it should work now.


Manually Changing Parameters

in 0.11 I cannot longer find where to change the moses.ini parameters.
This files do not included the weights.
# find engines/|grep ini
engines/default/runtime/moses.ini
engines/default/engine.ini
engines/default/data/moses.ini

@davidecaroselli where is now the file?
If the file was removed on purpose, I think we should put back the opportunity to change them manually.

If you need to change the moses.ini parameters, except for weights, you can modify the template file engines/default/data/moses.ini.
If you want to change the decoder weights, you find them in file engines/default/engine.ini.
The file engines/default/runtime/moses.ini is dynamically generated so its changes won't be loaded or stored anywhere.
To apply your changes please remember to restart all your MMT nodes.
I close this issue, if you any further questions please re-open it.


[SPARK-23603][SQL]When the length of the json is in a range,get_json_object will result in missing tail data

What changes were proposed in this pull request?
Replace writeRaw(char[] text, int offset, int len) with writeRaw(String text)
Although using writeRaw(String text) will lose some performance
spark-shell:
val value = "x" * 3000
val json = s"""{"big": "$value"}"""
spark.sql("select length(get_json_object(\'"+json+"\','$.big'))" ).collect
res0: Array[org.apache.spark.sql.Row] = Array([2991])

expect result : 3000
actual  result : 2991

public abstract void writeRaw(char[] text,int offset,int len) throws IOException
Method that will force generator to copy input text verbatim with no modifications (including that no escaping is done and no separators are added even if context [array, object] would otherwise require such). If such separators are desired, use writeRawValue(String) instead.

public abstract void writeRaw(String text) throws IOException
Method that will force generator to copy input text verbatim with no modifications (including that no escaping is done and no separators are added even if context [array, object] would otherwise require such). If such separators are desired, use writeRawValue(String) instead.

Jackson(>=2.7.7) fixes the possibility of missing tail data when the length of the value is in a range
https://github.com/FasterXML/jackson/wiki/Jackson-Release-2.7.7
https://github.com/FasterXML/jackson-core/issues/30
How was this patch tested?
org.apache.spark.sql.catalyst.expressions.JsonExpressionsSuite
test("some big value")

Can one of the admins verify this patch?

Can one of the admins verify this patch?

Another solution:
#20738

Can one of the admins verify this patch?


”Neaua”, ”Ghinești”, ”Rigmani”, ”Sânsimion”, ”Vădaș” are listed in the drop-down menu

Description:
When user writes ”Neaua”, ”Ghinești”, ”Rigmani”, ”Sânsimion”, ”Vădaș” the locations appear in the drop-down menu next to the comune and the county which is a part according to the law.
Precondition:
The website is up an running.

Step 1
Write in the search bar "Neaua"

Expected results
The location appears in the drop-down menu as "Sat Neaua, MUREȘ (Neaua)".

Step 2
Press "x" button.

Expected results
The location was deleted from the search bar.

Step 3
Write in the search bar "Ghinești"

Expected results
The location appears in the drop-down menu as "Sat Ghinești, MUREȘ (Neaua)".

Step 4
Press "x" button.

Expected results
The location was deleted from the search bar.

Step 5
Write in the search bar "Rigmani"

Expected results
The location appears in the drop-down menu as "Sat Rigmani, MUREȘ (Neaua)".

Step 6
Press "x" button.

Expected results
The location was deleted from the search bar.

Step 7
Write in the search bar "Sânsimion"

Expected results
The location appears in the drop-down menu as "Sat Sânsimion, MUREȘ (Neaua)".

Step 8
Press "x" button.

Expected results
The location was deleted from the search bar.

Step 9
Write in the search bar "Vădaș"

Expected results
The location appears in the drop-down menu as "Sat Vădaș, MUREȘ (Neaua)".


Update registry.d with a REGSAM.KEY_ALL_ACCESS example...

Adding example from<EMAIL_ADDRESS>

I think this should go into the module documentation, or that of REGSAM, or that of getKey, but certainly not this particular overload of setValue which accepts string arguments.

Ping

ping
The autotester is failing. Please fix?

first, sorry, I'm a bit lost with this...

the autotester gives an "Error - file 'std/windows/registry.d' contains trailing whitespace at line 1067" i.e. here: https://auto-tester.puremagic.com/show-run.ghtml?projectid=1&runid=1970417&isPull=true

but if I look into https://github.com/notna123/phobos/blob/b78b7f85416070142b251a3249d0db1d33a24a91/std/windows/registry.d there is no "trailing whitespace" at all in line 1067, only some "leading" ones --> "                .getKey("Run", REGSAM.KEY_ALL_ACCESS)"

It's actually the next line, 1068. It contains nothing but whitespace (thus you could say that it has both leading and trailing whitespace). Probably the whitespace check program counts lines from 0.

yes, looks like it's the blank line (1068) that needs to be trimmed so that there are no trailing spaces.

I concur - comment should be a general example at the top of the module

Hi there.
So whats next now? Do you need anything else from my side? If not, could you merge that one so I can remove it on my end?!
Thanks & regards

See my & Dmitry's comment.

I don't get your point, sorry. I've just added an example because Walter tries to encourage ppl to do so and Dlang does really need many more of those...
If you think this example is added in the wring please, feel free to add it yourself and/or accept the merge and move it afterward to whatever place you think it belongs better. I don't care, as long as Dlangs gets more and better documentation and (best case copy-paste) examples...
Bye...


Remote timestamp

I think this is now ready for review/merging. It now supports cross-platform as well as remote operation, opening the door to Raspberry Pi or similar applications. I have run the test programs in the remote directory under CPython and MicroPython.
The docs are hopefully complete.

If @belm0 is happy, I would go ahead and merge this.
I read through it and found no problems, but I haven't tested and I'm not deeply familiar with the codebase.

This just failed my own design review :)
I have simplified it by omitting the expect_ts constructor arg. If the user passes a time differencing function it then expects a timestamp with the data. In the case where both devices run MicroPython a simple lambda is passed. I've pushed an updated to the code and docs.
I think this set of changes has opened up interesting possibilities like running data acquisition and fusion on a Raspberry Pi. Whether the realtime performance would be adequate (given an OS in the background) for balancing robots or drones is a moot point.


#0 366.6 Cannot read properties of undefined (reading 'slice')

Hi Developer,
I try to run the docker build to create the image, it shows this error. I don't know how to fix it. Could you help?
My env. Ubuntu
docker --version
Docker version 20.10.17, build 100c701
lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 20.04.4 LTS
Release:        20.04
Codename:       focal
Best,
Michael Qi
...

[ghcr.io/pkuhpc/scow/portal-web-portal:latest builder 19/20] RUN pnpm run build:
#0 5.845
#0 5.845 > scow@ build /app
#0 5.845 > pnpm run -r build
#0 5.845
#0 9.468 Scope: 4 of 5 workspace projects
#0 9.498 libs/auth build$ rimraf build && tsc -p tsconfig.build.json && tsc-alias -p tsconfig.build.json
#0 9.501 libs/config build$ rimraf build && tsc -p tsconfig.build.json && tsc-alias -p tsconfig.build.json
#0 9.503 libs/decimal build$ rimraf build && tsc -p tsconfig.build.json
#0 42.40 libs/decimal build: Done
#0 45.34 libs/auth build: Done
#0 47.46 libs/config build: Done
#0 47.56 apps/portal-web build$ pnpm prepareDev && npm run build:nogen
#0 50.36 apps/portal-web build: ><EMAIL_ADDRESS>prepareDev /app/apps/portal-web
#0 50.36 apps/portal-web build: > pnpm protos && ntar schema
#0 52.75 apps/portal-web build: ><EMAIL_ADDRESS>protos /app/apps/portal-web
#0 52.75 apps/portal-web build: > tsgrpc-cli protos
#0 53.40 apps/portal-web build: [tsgrpc-cli] Using binPath /app/node_modules/.bin
#0 53.41 apps/portal-web build: [tsgrpc-cli] Generating protobuf files ../../protos/common/job.proto in path ../../protos. Resolved 1 files.
#0 77.47 apps/portal-web build: ><EMAIL_ADDRESS>build:nogen
#0 77.47 apps/portal-web build: > next build
#0 80.62 apps/portal-web build: warn  - Invalid next.config.js options detected:
#0 80.62 apps/portal-web build: [
#0 80.63 apps/portal-web build:   {
#0 80.64 apps/portal-web build:     "instancePath": "",
#0 80.64 apps/portal-web build:     "schemaPath": "#/additionalProperties",
#0 80.64 apps/portal-web build:     "keyword": "additionalProperties",
#0 80.64 apps/portal-web build:     "params": {
#0 80.64 apps/portal-web build:       "additionalProperty": "webpackDevMiddleware"
#0 80.65 apps/portal-web build:     },
#0 80.65 apps/portal-web build:     "message": "must NOT have additional properties"
#0 80.65 apps/portal-web build:   },
#0 80.66 apps/portal-web build:   {
#0 80.66 apps/portal-web build:     "instancePath": "",
#0 80.66 apps/portal-web build:     "schemaPath": "#/additionalProperties",
#0 80.66 apps/portal-web build:     "keyword": "additionalProperties",
#0 80.67 apps/portal-web build:     "params": {
#0 80.68 apps/portal-web build:       "additionalProperty": "configOrigin"
#0 80.68 apps/portal-web build:     },
#0 80.68 apps/portal-web build:     "message": "must NOT have additional properties"
#0 80.69 apps/portal-web build:   },
#0 80.70 apps/portal-web build:   {
#0 80.70 apps/portal-web build:     "instancePath": "",
#0 80.70 apps/portal-web build:     "schemaPath": "#/additionalProperties",
#0 80.70 apps/portal-web build:     "keyword": "additionalProperties",
#0 80.71 apps/portal-web build:     "params": {
#0 80.71 apps/portal-web build:       "additionalProperty": "target"
#0 80.71 apps/portal-web build:     },
#0 80.71 apps/portal-web build:     "message": "must NOT have additional properties"
#0 80.71 apps/portal-web build:   },
#0 80.72 apps/portal-web build:   {
#0 80.72 apps/portal-web build:     "instancePath": "",
#0 80.72 apps/portal-web build:     "schemaPath": "#/additionalProperties",
#0 80.72 apps/portal-web build:     "keyword": "additionalProperties",
#0 80.72 apps/portal-web build:     "params": {
#0 80.73 apps/portal-web build:       "additionalProperty": "analyticsId"
#0 80.73 apps/portal-web build:     },
#0 80.73 apps/portal-web build:     "message": "must NOT have additional properties"
#0 80.73 apps/portal-web build:   },
#0 80.73 apps/portal-web build:   {
#0 80.73 apps/portal-web build:     "instancePath": "",
#0 80.73 apps/portal-web build:     "schemaPath": "#/additionalProperties",
#0 80.74 apps/portal-web build:     "keyword": "additionalProperties",
#0 80.74 apps/portal-web build:     "params": {
#0 80.74 apps/portal-web build:       "additionalProperty": "webpack5"
#0 80.74 apps/portal-web build:     },
#0 80.74 apps/portal-web build:     "message": "must NOT have additional properties"
#0 80.75 apps/portal-web build:   },
#0 80.75 apps/portal-web build:   {
#0 80.75 apps/portal-web build:     "instancePath": "",
#0 80.75 apps/portal-web build:     "schemaPath": "#/additionalProperties",
#0 80.75 apps/portal-web build:     "keyword": "additionalProperties",
#0 80.75 apps/portal-web build:     "params": {
#0 80.75 apps/portal-web build:       "additionalProperty": "svgrOptions"
#0 80.75 apps/portal-web build:     },
#0 80.75 apps/portal-web build:     "message": "must NOT have additional properties"
#0 80.75 apps/portal-web build:   },
#0 80.75 apps/portal-web build:   {
#0 80.75 apps/portal-web build:     "instancePath": "/amp/canonicalBase",
#0 80.75 apps/portal-web build:     "schemaPath": "#/properties/amp/properties/canonicalBase/minLength",
#0 80.75 apps/portal-web build:     "keyword": "minLength",
#0 80.76 apps/portal-web build:     "params": {
#0 80.76 apps/portal-web build:       "limit": 1
#0 80.76 apps/portal-web build:     },
#0 80.76 apps/portal-web build:     "message": "must NOT have fewer than 1 characters"
#0 80.76 apps/portal-web build:   },
#0 80.76 apps/portal-web build:   {
#0 80.77 apps/portal-web build:     "instancePath": "/assetPrefix",
#0 80.77 apps/portal-web build:     "schemaPath": "#/properties/assetPrefix/minLength",
#0 80.77 apps/portal-web build:     "keyword": "minLength",
#0 80.77 apps/portal-web build:     "params": {
#0 80.77 apps/portal-web build:       "limit": 1
#0 80.77 apps/portal-web build:     },
#0 80.77 apps/portal-web build:     "message": "must NOT have fewer than 1 characters"
#0 80.77 apps/portal-web build:   },
#0 80.77 apps/portal-web build:   {
#0 80.78 apps/portal-web build:     "instancePath": "/experimental/outputFileTracingRoot",
#0 80.78 apps/portal-web build:     "schemaPath": "#/properties/experimental/properties/outputFileTracingRoot/minLength",
#0 80.78 apps/portal-web build:     "keyword": "minLength",
#0 80.78 apps/portal-web build:     "params": {
#0 80.78 apps/portal-web build:       "limit": 1
#0 80.78 apps/portal-web build:     },
#0 80.78 apps/portal-web build:     "message": "must NOT have fewer than 1 characters"
#0 80.78 apps/portal-web build:   },
#0 80.78 apps/portal-web build:   {
#0 80.78 apps/portal-web build:     "instancePath": "/generateEtags",
#0 80.78 apps/portal-web build:     "schemaPath": "#/properties/generateEtags/isFunction",
#0 80.78 apps/portal-web build:     "keyword": "isFunction",
#0 80.78 apps/portal-web build:     "params": {},
#0 80.78 apps/portal-web build:     "message": "must pass "isFunction" keyword validation"
#0 80.78 apps/portal-web build:   },
#0 80.79 apps/portal-web build:   {
#0 80.79 apps/portal-web build:     "instancePath": "/i18n",
#0 80.79 apps/portal-web build:     "schemaPath": "#/properties/i18n/type",
#0 80.80 apps/portal-web build:     "keyword": "type",
#0 80.80 apps/portal-web build:     "params": {
#0 80.80 apps/portal-web build:       "type": "object"
#0 80.80 apps/portal-web build:     },
#0 80.80 apps/portal-web build:     "message": "must be object"
#0 80.80 apps/portal-web build:   }
#0 80.80 apps/portal-web build: ]
#0 80.80 apps/portal-web build: See more info here: https://nextjs.org/docs/messages/invalid-next-config
#0 80.80 apps/portal-web build: Attention: Next.js now collects completely anonymous telemetry regarding usage.
#0 80.80 apps/portal-web build: This information is used to shape Next.js' roadmap and prioritize features.
#0 80.80 apps/portal-web build: You can learn more, including how to opt-out if you'd not like to participate in this anonymous program, by visiting the following URL:
#0 80.80 apps/portal-web build: https://nextjs.org/telemetry
#0 82.06 apps/portal-web build: info  - Linting and checking validity of types...
#0 93.46 apps/portal-web build: warn  - The Next.js plugin was not detected in your ESLint configuration. See https://nextjs.org/docs/basic-features/eslint#migrating-existing-config
#0 93.83 apps/portal-web build: Warning: React version not specified in eslint-plugin-react settings. See https://github.com/jsx-eslint/eslint-plugin-react#configuration .
#0 166.1 apps/portal-web build: info  - Creating an optimized production build...
#0 189.3 apps/portal-web build:  [webpack.cache.PackFileCacheStrategy/webpack.FileSystemInfo] Resolving 'undici/lib/llhttp/llhttp_simd.wasm' in<EMAIL_ADDRESS>for build dependencies doesn't lead to expected result<EMAIL_ADDRESS>but to<EMAIL_ADDRESS>instead. Resolving dependencies are ignored for this path.
#0 189.3 apps/portal-web build:   at unknown 4 undici/lib/llhttp/llhttp_simd.wasm
#0 189.3 apps/portal-web build:   at file dependencies<EMAIL_ADDRESS>#0 189.3 apps/portal-web build:   at file<EMAIL_ADDRESS>#0 189.3 apps/portal-web build:   at file dependencies<EMAIL_ADDRESS>#0 189.3 apps/portal-web build:   at file<EMAIL_ADDRESS>#0 189.3 apps/portal-web build:   at file dependencies<EMAIL_ADDRESS>#0 189.3 apps/portal-web build:   at file<EMAIL_ADDRESS>#0 189.3 apps/portal-web build:   at file dependencies<EMAIL_ADDRESS>#0 189.3 apps/portal-web build:   at file<EMAIL_ADDRESS>#0 189.3 apps/portal-web build:   at file dependencies /app/libs/auth/build/validateToken.js
#0 189.3 apps/portal-web build:   at file /app/libs/auth/build/validateToken.js
#0 189.3 apps/portal-web build:   at file dependencies /app/libs/auth/build/index.js
#0 189.3 apps/portal-web build:   at file /app/libs/auth/build/index.js
#0 189.3 apps/portal-web build:   at file dependencies /app/apps/portal-web/config.js
#0 189.3 apps/portal-web build:   at file /app/apps/portal-web/config.js
#0 189.3 apps/portal-web build:   at file dependencies /app/apps/portal-web/next.config.js
#0 189.3 apps/portal-web build:   at file /app/apps/portal-web/next.config.js
#0 189.3 apps/portal-web build:   at resolve commonjs /app/apps/portal-web/next.config.js
#0 366.6 Cannot read properties of undefined (reading 'slice')
#0 368.8  ELIFECYCLE  Command failed with exit code 1.

failed to solve: executor failed running [/bin/sh -c pnpm run build]: exit code: 1

Hello!
We have a dev/docker-compose.build.yml to build the project. Would you like to build images using the file by running the following command and see if the error persists?
docker compose -f dev/docker-compose.build.yml build

BTW I am doing a refactor for the project right now, which may involve the docker image build process. I will comment here again when the refactor is done, and you might try again at that time.

Hi Junda,
I will try later. The command I used is the one you suggested.
Best,
Michael
On Tue, Jul 26, 2022 at 9:42 AM Chen Junda @.***> wrote:

Hello!
We have a dev/docker-compose.build.yml to build the project. Would you
like to build images using the file by running the following command and
see if the error persists?
docker compose -f dev/docker-compose.build.yml build
BTW I am doing a refactor for the project right now, which may involve the
docker image build process. I will comment here again when the refactor is
done, and you might try again at that time.
—
Reply to this email directly, view it on GitHub
https://github.com/PKUHPC/SCOW/issues/151#issuecomment-1194873558, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/ABBOKT6E74E3I2OUTYLCOWTVV47ADANCNFSM54UDVYDA
.
You are receiving this because you authored the thread.Message ID:
@.***>

Hello. Please try building the project again. I have tested the build on an exactly identical environment (ubuntu 20.04 and docker 20.10.17) with a clean clone and it works fine.

Hi Junda,
Thanks for your reply.
But I got this error message, the blue line are the commands:
git clone https://github.com/PKUHPC/SCOW.git
Cloning into 'SCOW'...
remote: Enumerating objects: 10753, done.
remote: Counting objects: 100% (501/501), done.
remote: Compressing objects: 100% (252/252), done.
remote: Total 10753 (delta 251), reused 434 (delta 232), pack-reused 10252
Receiving objects: 100% (10753/10753), 7.13 MiB | 6.60 MiB/s, done.
Resolving deltas: 100% (7194/7194), done.
cd SCOW/
ls
README.md  commitlint.config.js  dockerfiles  libs          pnpm-lock.yaml
protos         tsconfig.json
apps       dev                   docs         package.json
pnpm-workspace.yaml  renovate.json
export IMAGE_BASE=ghcr.io/pkuhpc/scow
export TAG=latest
docker compose -f dev/docker-compose.build.yml build
[+] Building 6.8s (57/236)
=> [ghcr.io/pkuhpc/scow/mis-web-mis:latest internal] load build definition
from Dockerfile.mis-web                     0.0s
=> => transferring dockerfile: 2.27kB
0.0s
=> [ghcr.io/pkuhpc/scow/mis-server:latest internal] load build definition
from Dockerfile.mis-server                   0.0s
=> => transferring dockerfile: 2.10kB
0.0s
=> [ghcr.io/pkuhpc/scow/mis-web-root:latest internal] load build
definition from Dockerfile.mis-web                    0.1s
=> => transferring dockerfile: 2.27kB
0.0s
=> [ghcr.io/pkuhpc/scow/portal-web-root:latest internal] load build
definition from Dockerfile.portal-web              0.1s
=> => transferring dockerfile: 2.67kB
0.0s
=> [ghcr.io/pkuhpc/scow/portal-web-portal:latest internal] load build
definition from Dockerfile.portal-web            0.1s
=> => transferring dockerfile: 2.67kB
0.0s
=> [ghcr.io/pkuhpc/scow/auth:latest internal] load build definition from
Dockerfile.auth                               0.3s
=> => transferring dockerfile: 1.30kB
0.0s
=> [ghcr.io/pkuhpc/scow/gateway:latest internal] load build definition
from Dockerfile.gateway                         0.2s
=> => transferring dockerfile: 735B
0.0s
=> [ghcr.io/pkuhpc/scow/mis-web-mis:latest internal] load .dockerignore
0.1s
=> => transferring context: 102B
0.0s
=> [ghcr.io/pkuhpc/scow/mis-server:latest internal] load .dockerignore
0.1s
=> => transferring context: 102B
0.0s
=> [ghcr.io/pkuhpc/scow/mis-web-root:latest internal] load .dockerignore
0.2s
=> => transferring context: 102B
0.0s
=> [ghcr.io/pkuhpc/scow/portal-web-root:latest internal] load
.dockerignore                                            0.3s
=> => transferring context: 102B
0.0s
=> [ghcr.io/pkuhpc/scow/gateway:latest internal] load .dockerignore
0.2s
=> => transferring context: 102B
0.0s
=> [ghcr.io/pkuhpc/scow/portal-web-portal:latest internal] load
.dockerignore                                          0.2s
=> => transferring context: 102B
0.0s
=> [ghcr.io/pkuhpc/scow/auth:latest internal] load .dockerignore
0.3s
=> => transferring context: 102B
0.0s
=> [ghcr.io/pkuhpc/scow/auth:latest internal] load metadata for
@.:19085641  6.6s
=> [ghcr.io/pkuhpc/scow/mis-web-mis:latest internal] load build context
0.2s
=> => transferring context: 1.23MB
0.1s
=> [ghcr.io/pkuhpc/scow/portal-web-root:latest runner  1/20] FROM
@.:190856  0.1s
=> => resolve
@.:1908564153449b1c46b329e6ce2307e226bc566294f822f11c5a8bcef4
0.0s
=> [ghcr.io/pkuhpc/scow/mis-server:latest internal] load build context
0.1s
=> => transferring context: 941.41kB
0.1s
=> [ghcr.io/pkuhpc/scow/mis-web-root:latest internal] load build context
0.2s
=> => transferring context: 1.23MB
0.1s
=> [ghcr.io/pkuhpc/scow/gateway:latest internal] load metadata for
@.:9c2030e1ff2c  0.0s
=> [ghcr.io/pkuhpc/scow/portal-web-portal:latest internal] load build
context                                          0.2s
=> => transferring context: 1.21MB
0.1s
=> CACHED [ghcr.io/pkuhpc/scow/portal-web-root:latest runner  2/25] RUN
apk add --no-cache openssh-client              0.0s
=> CACHED [ghcr.io/pkuhpc/scow/portal-web-root:latest runner  3/25]
WORKDIR /app                                       0.0s
=> [ghcr.io/pkuhpc/scow/gateway:latest 1/4] FROM
@.:9c2030e1ff2c3fef7440a7fb694755  0.0s
=> => resolve
@.:9c2030e1ff2c3fef7440a7fb69475553e548b9685683bdbf669ac0829b889d5f
0.0s
=> [ghcr.io/pkuhpc/scow/gateway:latest internal] load build context
0.1s
=> => transferring context: 1.54kB
0.0s
=> [ghcr.io/pkuhpc/scow/auth:latest internal] load build context
0.1s
=> => transferring context: 3.61MB
0.0s
=> [ghcr.io/pkuhpc/scow/portal-web-root:latest internal] load build
context                                            0.1s
=> => transferring context: 1.21MB
0.0s
=> CACHED [ghcr.io/pkuhpc/scow/gateway:latest 2/4] RUN sed -i "1
i\load_module /etc/nginx/modules/ngx_http_js_module.  0.0s
=> CACHED [ghcr.io/pkuhpc/scow/gateway:latest 3/4] COPY
apps/gateway/includes /etc/nginx/includes                      0.0s
=> CACHED [ghcr.io/pkuhpc/scow/gateway:latest 4/4] COPY
apps/gateway/nginx.conf /etc/nginx/templates/default.conf.tem  0.0s
=> CACHED [ghcr.io/pkuhpc/scow/auth:latest builder  2/18] RUN apk update
&& apk add libc6-compat python3 make gcc g++  0.0s
=> CACHED [ghcr.io/pkuhpc/scow/auth:latest builder  3/18] RUN corepack
enable                                          0.0s
=> CACHED [ghcr.io/pkuhpc/scow/auth:latest builder  4/18] WORKDIR /app
0.0s
=> CACHED [ghcr.io/pkuhpc/scow/mis-web-mis:latest builder  5/18] COPY
package.json pnpm-lock.yaml pnpm-workspace.yaml  0.0s
=> CACHED [ghcr.io/pkuhpc/scow/mis-web-mis:latest builder  6/18] COPY
libs/auth/package.json ./libs/auth/              0.0s
=> CACHED [ghcr.io/pkuhpc/scow/mis-web-mis:latest builder  7/18] COPY
libs/config/package.json ./libs/config/          0.0s
=> CACHED [ghcr.io/pkuhpc/scow/mis-web-mis:latest builder  8/18] COPY
libs/decimal/package.json ./libs/decimal/        0.0s
=> CACHED [ghcr.io/pkuhpc/scow/mis-web-mis:latest builder  9/18] COPY
apps/mis-web/package.json apps/mis-web/          0.0s
=> ERROR [ghcr.io/pkuhpc/scow/mis-web-mis:latest builder 10/18] RUN pnpm i
--frozen-lockfile                           5.9s
=> [ghcr.io/pkuhpc/scow/gateway:latest] exporting to image
0.2s
=> => exporting layers
0.0s
=> => writing image
sha256:6184a1faae1e6fa88b665cce7c285effce3e3bd1a9fde808039f7ef7246d03de
0.0s
=> => naming to ghcr.io/pkuhpc/scow/gateway:latest
0.0s
=> CACHED [ghcr.io/pkuhpc/scow/mis-server:latest builder  5/20] COPY
package.json pnpm-lock.yaml pnpm-workspace.yaml   0.0s
=> CACHED [ghcr.io/pkuhpc/scow/mis-server:latest builder  6/20] COPY
libs/config/package.json ./libs/config/           0.0s
=> CACHED [ghcr.io/pkuhpc/scow/mis-server:latest builder  7/20] COPY
libs/auth/package.json ./libs/auth/               0.0s
=> CACHED [ghcr.io/pkuhpc/scow/mis-server:latest builder  8/20] COPY
libs/decimal/package.json ./libs/decimal/         0.0s
=> CACHED [ghcr.io/pkuhpc/scow/mis-server:latest builder  9/20] COPY
libs/ssh/package.json ./libs/ssh/                 0.0s
=> CACHED [ghcr.io/pkuhpc/scow/mis-server:latest builder 10/20] COPY
apps/mis-server/package.json ./apps/mis-server/   0.0s
=> CACHED [ghcr.io/pkuhpc/scow/portal-web-portal:latest builder  5/22]
COPY package.json pnpm-lock.yaml pnpm-workspac  0.0s
=> CACHED [ghcr.io/pkuhpc/scow/portal-web-portal:latest builder  6/22]
COPY libs/auth/package.json ./libs/auth/        0.0s
=> CACHED [ghcr.io/pkuhpc/scow/portal-web-portal:latest builder  7/22]
COPY libs/config/package.json ./libs/config/    0.0s
=> CACHED [ghcr.io/pkuhpc/scow/portal-web-portal:latest builder  8/22]
COPY libs/decimal/package.json ./libs/decimal/  0.0s
=> CACHED [ghcr.io/pkuhpc/scow/portal-web-portal:latest builder  9/22]
COPY libs/ssh/package.json ./libs/ssh/          0.0s
=> CACHED [ghcr.io/pkuhpc/scow/portal-web-portal:latest builder 10/22]
COPY apps/portal-web/package.json ./apps/porta  0.0s
=> CANCELED [ghcr.io/pkuhpc/scow/portal-web-portal:latest builder 11/22]
RUN pnpm i --frozen-lockfile                  5.7s
=> CANCELED [ghcr.io/pkuhpc/scow/mis-server:latest builder 11/20] RUN pnpm
i --frozen-lockfile                         5.9s
=> CACHED [ghcr.io/pkuhpc/scow/auth:latest builder  5/14] COPY
package.json pnpm-lock.yaml pnpm-workspace.yaml .npmrc  0.0s
=> CACHED [ghcr.io/pkuhpc/scow/auth:latest builder  6/14] COPY
libs/config/package.json ./libs/config/                 0.0s
=> CACHED [ghcr.io/pkuhpc/scow/auth:latest builder  7/14] COPY
apps/auth/package.json ./apps/auth/                     0.0s
=> CANCELED [ghcr.io/pkuhpc/scow/auth:latest builder  8/14] RUN pnpm i
--frozen-lockfile                               5.9s

[ghcr.io/pkuhpc/scow/mis-web-mis:latest builder 10/18] RUN pnpm i
--frozen-lockfile:
#0 5.747 Internal Error: Error when performing the request
#0 5.747     at ClientRequest.
(/usr/local/lib/node_modules/corepack/dist/corepack.js:3937:20)
#0 5.747     at ClientRequest.emit (node:events:527:28)
#0 5.747     at TLSSocket.socketErrorListener (node:_http_client:454:9)
#0 5.747     at TLSSocket.emit (node:events:527:28)
#0 5.747     at emitErrorNT (node:internal/streams/destroy:157:8)
#0 5.747     at emitErrorCloseNT (node:internal/streams/destroy:122:3)
#0 5.747     at processTicksAndRejections
(node:internal/process/task_queues:83:21)

failed to solve: executor failed running [/bin/sh -c pnpm i
--frozen-lockfile]: exit code: 1
Best,
Michael
On Mon, Aug 1, 2022 at 10:19 AM Chen Junda @.***> wrote:

Hello. Please try building the project again. I have tested the build on
an exactly identical environment (ubuntu 20.04 and docker 20.10.17) with a
clean clone and it works fine.
—
Reply to this email directly, view it on GitHub
https://github.com/PKUHPC/SCOW/issues/151#issuecomment-1200609149, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/ABBOKT3JELYNIVQMKO3ECCTVW4X2LANCNFSM54UDVYDA
.
You are receiving this because you authored the thread.Message ID:
@.***>

This should be a network issue. Please try again.
BTW, we do have built images hosted on github and aliyun CR. You can send an email to me<EMAIL_ADDRESS>and tell me whether you can in China Mainland or not to request access to these images.

We have CI setup to test image build process. The build should be fine. Closing the issue.


VRS integration into genomicVariations  default schema

This is an attempt to allow the use of VRS variation classes, while also keeping an updated version of the current Beacon schema (using VRS location, which was agreed upon) as an option. This proposal tries to address feedback from the PRC process.
All the additional properties beyond the definition of the variant itself (annotations, caseLevel data etc.) are kept in place.
The change here introduces the root level variation property but other options could be possible.

Hi Michael, just getting into this now...there are terms in VRS.location" that are easily transferable (e.g., interval or type), but what about others such as sequence_id?

@mrueda VRS does not require computed identifiers, only that CURIEs are being used. See e.g. https://vrs.ga4gh.org/en/stable/impl-guide/example.html . So sequenceId should usually be a refseq id, which then also obviates the need for the definition of a genome edition ("sequenceId": "refseq:NC_000001.10" for chr1, GRCh37).

As discussed today (and in several conversations, also with @ahwagner) this seems to be the best way to go ATM. I'm +1 on merge, but leave the step to @jrambla / @MrRobb .

I believe that this is a good change that has to be made in one form or another, I'll wait to see what @jrambla says before approving this PR though but I can't see any problems with it currently.
I echo the sentiments made by @mrueda about the mapping of current beacon terms onto VRS. Almost all of these are 1-1 mappings but as pointed out sequence_id is created by a combination of current fields.
I think it's worth taking some time to make a document with all VRS fields and then how these are created from the current beacon fields. Not only will this ensure we are all happy that everything that beacon offers can be handled by VRS it also makes the life of implementers, who need to make the changes, easier as they wont have to do the mappings themselves. This document might also be useful as part of the re-submission to show how Beacon has been changed to better align with external standards.

Do we also need to think about the beacons which use different names/identifiers for chromosomes? Some people wont store the refseq id of chromosomes, instead just stating they use (chr)1 of GrCH3X which could be turned into a CURIE along the lines of `chr:1` or `chromosome:1` or `grch37:1`. This causes no problems when querying a single beacon instance from a interface designed to query that beacon but as soon as you start querying across multiple beacons this becomes an issue.

I would recommend the inclusion of a statement such as:

> Beacon recommends the use of refseq for identifying chromosomes.

This problem will likely appear in more places than just chromosome.

Beacon has done something before, in beacon v1 genomic positions were denoted in 0 based half closed (or something similar) notation and this was stated in the documentation so implementers were aware they would need to do some form of conversion to fit the query to their data.

If anyone agrees with this then we should split this off into another issue but if it's not of concern then I'm happy to leave it here.

@Tom-Shorter Thanks for the elaboration - indeed, this is a "we have to be more prescriptive due to alignment with external standards" issue. But this is on the model side, so supporting clean data delivery... I would argue that we should recommend & document the CURIE-format refseq-id or alternative ga4gh/VRS identifier use.
(The alternative would be to keep the Position object in its previous form for the LegacyVariation while keeping the suggested  change to a oneOf root variation => It probably would have made sense to keep the 2 changes for separate discussion.)

+1 to the mapping documentation wisely suggested by Tom.
Part of the conversation above lies in the fundamental design decision on:
As Beacon is a discovery but also an entry tool for GA4GH and data sharing, to which end of the "easy vs standard" (or "easy entry vs. precise discovery") continuum it must be shifting.
So far, I'd favored "easy" as I believe that using powerful standards comes naturally once you have started to share.
Of course that is having a cost on the fostering (enforcing?) standards end of the continuum.
Beacon has plenty of such "debates" as it is in a centric position.
They are welcome for that reason ;-)

@mbaudis, naive question: SequenceState is to be deprecated in VRS2.0.
Have we discussed that already?


About KITTI Pose

To evaluate VO in KITTI, I first predicted poses of Sequences 09 when cfg.PRED_POSE_GT_SCALE = True. After that, I multiplied relative poses between frames with the current pose to get the absolute pose of the frame, and use the KITTI odometry evaluation toolbox mentioned in README.md. However, the result is not so good.  The translational error is 4.182%, the rotational error is 1.352 deg/100m, and ATE is as large as 62.991m.
sequence_09.pdf
Did I make a mistake or miss any steps? @jytime

Hi,
The flag cfg.PRED_POSE_GT_SCALE was only used for the ablation study `Oracle Scale'  in Table 6 of the paper, and not for VO evaluation.
For a quick look, here are some dirty codes for VO evaluation (not carefully checked now). `pose_rel_our' is the relative pose predicted by our method.
Best

Btw, I was wondering if you can reproduce the depth results, or encounter a similar situation to @longyangqi as in issue #6? Several people have reported that they can reproduce the results in their machines. I am thinking if the situation of @longyangqi may result from some env settings like the CUDA version.

Btw, I was wondering if you can reproduce the depth results, or encounter a similar situation to @longyangqi as in issue #6? Several people have reported that they can reproduce the results in their machines. I am thinking if the situation of @longyangqi may result from some env settings like the CUDA version.

Thank you for mentioning my issue!
I think I have followed the instructions in README as CUDA=10.1, while Torch==1.7.0, opencv-contrib-python==<IP_ADDRESS> with Python==3.6. I also wonder if @Zero314159 can reproduce the depth results.

@jytime Thank you very much for your reply!! In my view, what your codes for VO evaluation do is totally the same as the codes below cfg.PRED_POSE_GT_SCALE to multiply real scale factors to normalized t produced before. And the results are quite similar.
@longyangqi And I reproduced the depth results.
abs_rel 0.08760373986765764 sq_rel 0.5988171511467337 rmse 3.729680877932517 rmse_log 0.1704294506294741 a1 0.9101663537063548 a2 0.960042136150853 a3 0.9790024025015921 l1_inv 0.008641085914053962 sc_inv 0.16769501271860468

It is weird. It seems the compiled RANSAC module of you still does not work correctly. But even the reproduced depth results of you two are very different....
I may re-compile the codes in a new machine and evaluate the results next week, to check if something is wrong.
btw, did you download the data from the official website of KITTI, the latest version?

I downloaded the raw data from the official website of KITTI, and got the sequence data from someone who downloaded it before. But it seems that there are no updates about the data we use.

hello, friends   @longyangqi @Zero314159 , i confused  about downloading the raw data,i went to this the official website of KITTI , but many web links show that they cannot be opened (vpn has been hung up).Could you tell me Click what  link to download the data format required by the project . I download calibration as a part of raw data from yun.baidu.com ,but it seems no  calib_cam_to_cam.txt , so run KITTI Depth evaluation cause errors,could you tell me right way or Share with me the  raw data ink that fits the project format , ### thanks!!!

I downloaded the raw data from the official website of KITTI, and got the sequence data from someone who downloaded it before. But it seems that there are no updates about the data we use.

hello, friends @longyangqi @Zero314159 , i confused about downloading the raw data,i went to this the official website of KITTI , but many web links show that they cannot be opened (vpn has been hung up).Could you tell me Click what link to download the data format required by the project . I download calibration as a part of raw data from yun.baidu.com ,but it seems no calib_cam_to_cam.txt , so run KITTI Depth evaluation cause errors,could you tell me right way or Share with me the raw data ink that fits the project format , ### thanks!!!

I downloaded the raw data from the official website of KITTI, and got the sequence data from someone who downloaded it before. But it seems that there are no updates about the data we use.

Just the official links in README of this project.
As for calib,  I think it may be not necessary for for depth evaluation. As in:
https://github.com/jytime/Deep-SfM-Revisited/blob/ba0651b1f2e582016f2ea8474dde86a4263cdbcd/KITTI_loader.py#L303
What's your errors?

@Zero314159  Wath's your  the raw data from the official website of KITTI ? The raw velodyne_points (.bin) in KITTI RAW data, the projected velodyne_raw (.png) or the groundtruth (.png) in 14GB official depth maps?
My results in #6  are producted by the groundtruth of 14GB if available, as stated in #7 .
I think the different results may caused by using different data.

@longyangqi ,thank you. I  do according to the test_iles.txt and try to download calib.txt , so i could run this KITTI depth  evaluation . @jytime   I am confused  about this sentence “Please generate poses by sequence, and evaluate the results correspondingly.”  in README.md , i  don't  find the  py document for generating  predicted_pose , could you  tell me the corresponding implementation or the location about  predicted_pose corresponding interface ? Thanks

@3196887235 Could you share the results of the depth evaluation?


'Pending' submission status

Upon submission, a problem's status automatically goes to 'Compiling'. However, this may not be accurate if the server is actually handling several submissions. Perhaps the default should really be Pending and then update to Compiling when the judge is actually compiling the program.
It would add another socket transaction, but shouldn't be too big of a deal.

This is a duplicate of #18


index 'i' exceeds class_indices[i]

In the file train_tripletloss.py there is a function def sample_people inside which there is a while loop with the following code class_index = class_indices[i]. I have only two classes and 3000 images per class (3000 in the first and 2999 in the second). I realized that no matter how much I change the variables (people_per_batch,batch_size,images_per_person) . I get the same error which is
File "train_tripletloss.py", line 332, in sample_people
class_index = class_indices[i]
IndexError: index 2 is out of bounds for axis 0 with size 2
I can realize that the issue is because I have only two classes nrof_classes=2 and I append them with the np.arange(nrof_classes). But the while loop runs for more than 2 iterations and obviously since the classes are only 2 in the 3rd iteration the code breaks.
I checked in a similar issue here which as far as I can see does not solve the issue.
Could you provide me with some help?
My Stacktrace is :
Traceback (most recent call last):
  File "train_tripletloss.py", line 491, in <module>
   main(parse_arguments(sys.argv[1:]))
 File "train_tripletloss.py", line 191, in main
  args.embedding_size, anchor, positive, negative, triplet_loss)
 File "train_tripletloss.py", line 217, in train
   image_paths, num_per_class = sample_people(dataset, args.people_per_batch, args.images_per_person)
  File "train_tripletloss.py", line 332, in sample_people
   class_index = class_indices[i]
IndexError: index 2 is out of bounds for axis 0 with size 2

hey @hanybo !
I have the same problem and I can't find a solution.
If you found a fix to it. I would be grateful if you help me about it.
thank you in advance.

Hey, I'm very late to this but, I am running into the same error, and I find the wording too vague, could you explain, like am I supposed to change the --people_per_batch I'm not sure what is being asked. Thank you in advance!


clarify the SW availability

Currently the rule says:
2.3. System and framework must be available
If you are measuring the performance of a publicly available and widely-used system or framework, you must use publicly available and widely-used versions of the system or framework.
If you are measuring the performance of an experimental framework or system, you must make the system and framework you use available upon demand for replication.
--
In training, we allowed PRs to frameworks to be allowed. How shall we reflect this in the rules?
How about closed source code and binaries? Do we require them to be on an official site? What defines to be an official site?

In training, we allowed PRs to frameworks to be allowed.

Is that correct? I thought there was some carefully negotiated verbiage about tagged releases?

Condition for available systems:

Identified version. SW available upon purchase or rental or for download. we need these versions information to be public and officially supported for all customers.
if use main framework (e.g. TF, PyTorch), any branch is ok, optionally to add a public PR from submitter

to be updated in the inference submission rules doc.

updated in the submission doc, to be uploaded by @petermattson


Regression by PhasedLSTM with a gradient explosion

Hello,
When I used PhasedLSTM (PLSTM) to perform the regression (to find the correlation between an input sequence and an output sequence), I got "nan" in the weight , also the loss in the beginning of the first epoch, even I used gradient clipping.
The generated data for training: (little modified from https://fairyonice.github.io/Extract-weights-from-Keras's-LSTM-and-calcualte-hidden-and-cell-states.html)

The optimizer is as follows:
model.compile(loss="mean_squared_error",                   sample_weight_mode="temporal",                   optimizer = keras.optimizers.Adam(lr=0.01, beta_1=0.9, beta_2=0.999, epsilon=1e-08, decay=0.0))
After checked the weights in PLSTM layer, I found the values of timegate-kernel getting larger and larger, then the weights get to "nan".  (The first two rows)

I changed to standard LSTM (other settings and learning rate [still 0.01] the same), the loss converges. Therefore, I traced the source code of PLSTM, considering the initialization of timegate_kernel matters, but stuck for a long time, having little progress.
I am wondering if anyone has the similar issue? Any suggestions to find the reason why the gradient get exploded is appreciated. The relevant code is at the link:
https://github.com/hnchang/Regression-with-PhasedLSTM/blob/master/reg_plstm.py
Much thanks,
James

Hey James,
I am having a similar issue here. Two things that have worked for me:

Reduce the learning rate (on schedule or manually)
Use clipping gradients to prevent them from exploding https://machinelearningmastery.com/how-to-avoid-exploding-gradients-in-neural-networks-with-gradient-clipping/

I hope this helps.


helm template --output-dir: failure to render non-hook resources if a hook resource is part of the template

# prepare chart for testing
cd /tmp
helm create test && cd test && rm -rf templates/*

cat <<EOF > templates/mixed.yaml
---
apiVersion: v1
kind: ConfigMap
metadata:
  name: not-a-hook-in-mixed-template
---
apiVersion: v1
kind: ConfigMap
metadata:
  name: a-hook-in-mixed-template
  annotations:
    # what matters seem to be that "helm.sh/hook" is specified at all
    "helm.sh/hook": pre-install,pre-upgrade
EOF

# verify bug, this currently finds only a single
# manifest rendered, but two should be around
helm template . --output-dir rendered
cd rendered/test/templates
grep "name:" *

# RESULT: one manifest, the hook resource independent of ordering
# not both as we would get and expect if the template file had only hooks
# or only non-hooks.
#
#   name: a-hook-in-mixed-template
#

Output of helm version:
version.BuildInfo{Version:"v3.9.0", GitCommit:"7ceeda6c585217a19a1131663d8cd1f7d641b2a7", GitTreeState:"clean", GoVersion:"go1.17.5"}

I'm not sure what the expected behaviour is here. AFAICT Helm relies on the fact that one file == one manifest. Putting multiple manifests in a "mixed" template seems like an odd edge case.

I recall reading it as a best practice to not render multiple resources from a single YAML template, but that helm requires that would be a surprise to me as a user who has read the helm docs multiple times since version 2 and onwards.
I think that unless this is a bug, and its accepted to have this buggy behavior when multiple resources are rendered from the same template file, helm lint or helm lint --strict should not accept this without a warning at least.
@bacongobbler I invest significant time to report clear and reproducible bugs when I find them, and to me, this issue is a clear bug or undocumented assumption. Maybe it isn't important to resolve, I can get that as it is a seldom occurring situation, I'd be fine with a "wontfix" resolution to this issue, but to see this considered a support question makes me a bit sad. I have not opened this issue looking for help for my own gain, but to help this project even though I don't know Golang well enough to contribute as a code contributor.
Thank you for your work on this project, and I also understand the workload of triaging issues etc, it is a lot of work. That is why I care about providing clear reproducible and tightly scoped issues.


Reusable steps with response from an async function

Hi, thank you so much for this great package! 🎉
I’m facing a problem, that I can’t wrap my head around.
My current setup requires a testRunner function provided by the backend framework that I’m using, see this link.
The runner function takes an async function as a parameter and returns a promise like this:
const runner: (testFn: (testArgs: TestArgs) => Promise<void>) => () => Promise<void>

I want to share the testArgs across step definitions because they include a context object that I need to interact with the database.
I can easily do this:
defineFeature(feature, test => {
  test('...', async ({ given, when, then }) => {
    let user = {}
    let context

    given('the database is reset', async () => {
      await runner(async ({ context: runnerContext }) => {
        context = runnerContext
      })()
    })

    given('I am the test user', async () => {
      const response = await createUser({
        context,
        variables: { data: { ...testUser } },
      })
      user = response.data.createUser
    })
...

But I really would love to separate out these as reusable steps and import them because I will need them in a lot of tests. But then of course context will always be undefined when I pass it down to the imported functions because it’s undefined in the test scope when these functions are initialized.
Do you have any recommendations on how to deal with this?
Thank you so much in advance!

I found a solution, with a function exposing a getState and setState function, similar to useState in React.

@felixbuchholz can you explain a bit more how you solved this? I am facing the same problem with reusable steps and async behavior.

@tsargent sorry for the late reply. This was in a project while back and I was a bit busy this week.
Here’s how I implemented the getState (called state in the example) and setState functions. It’s not super sophisticated, but did the trick:
testState.ts:
export type GetState<T> = () => T
export type SetState<T> = (newVal: T) => void

export const testState = <T>(initialValue: T): [GetState<T>, SetState<T>] => {
  let _val = initialValue // local
  const state = (): T => {
    // closure
    return _val // _val from outer function scope
  }
  const setState = (newVal: T): void => {
    _val = newVal
  }
  return [state, setState]
}

I’m using those functions as parameters for wrapper functions that define my individual steps. For setting up my context for example, stepDefinitions/common/givenTheDatabaseIsReset.ts:
import { GetState, SetState } from '../../utils/testState'

import { DefineStepFunction } from 'jest-cucumber'
import { KeystoneContext } from '@keystone-6/core/types'
import config from '../../../keystone'
import { setupTestEnv, TestEnv } from '@keystone-6/core/testing'

type Params = {
  given: DefineStepFunction
  getContext: GetState<KeystoneContext & { testEnv: TestEnv }>
  setContext: SetState<KeystoneContext & { testEnv: TestEnv }>
}

export const givenTheDatabaseIsReset = async ({
  given,
  getContext,
  setContext,
}: Params): Promise<void> => {
  given('the database is reset', async () => {
    const prevTestEnv = getContext()?.testEnv
    if (prevTestEnv) {
      await prevTestEnv.disconnect()
    }
    const testEnv = await setupTestEnv({ config })
    const context = { ...testEnv.testArgs.context, testEnv }
    setContext(context)
  })
}

Then I can reuse the context by calling getContext().
stepDefinitions/common/givenIAmTheTestUser.ts:
import {
  CreateUserMutation,
  createUser,
} from '../../../codegen/generated/generatedCucumber'

import { DefineStepFunction } from 'jest-cucumber'
import { KeystoneContext } from '@keystone-6/core/types'
import { SetState } from '../../utils/testState'

export const testUser = {
  // ...
}

export type Params = {
  given: DefineStepFunction
  getContext: () => KeystoneContext
  setTestUser?: SetState<CreateUserMutation['createUser']>
}

export const givenIAmTheTestUser = ({
  given,
  getContext,
  setTestUser,
}: Params): void => {
  given('I am the test user', async () => {
    const response = await createUser({
      context: getContext(),
      variables: { data: { ...testUser } },
    })
    if (setTestUser) {
      setTestUser(response.data.createUser)
    }
  })
}

Does this help?

Maybe two more pointers:
I’m using the autobind-feature, jest-cucumber/stepDefinitions/cucumber.steps.ts:
import { autoBindSteps, loadFeatures } from 'jest-cucumber'
import { allSteps } from '../../codegen/generated/generatedCucumber'

const features = loadFeatures('jest-cucumber/features/**/*.feature')
autoBindSteps(features, [allSteps])

and I have set up a script to create functions based on my feature-files that collects them in a file,
generatedCucumber.ts:
const [getContext, setContext] = testState<
  KeystoneContext & { testEnv: TestEnv }
>(null)
const [getTestResponse, setTestResponse] = testState<any>(null)

export const allSteps: StepDefinitions = ({ given, when, then }) => {
  givenIAmTheUser({ given, getContext })
  givenTheDatabaseIsReset({ given, getContext, setContext })

  // ...
}

Thank you @felixbuchholz !


Path components with URI-encoded $ in them aren't correctly decoded

router.transitionTo("foo", { component: encodeURIComponent("{foo$bar") })

results in the URI http://host/foo/%7Bfoo%24bar. Subsequently calling router.getCurrentParams().component returns "{foo%24bar", which is half-decoded. This appears to be related to the decodeURI call in getCurrentPath.

@nornagon Can you please verify this is fixed on current master? Should we add a test for it?

I made a pull request #1727 with a test case showing it is fixed in the current version of master.

Thanks, @elpete !


warning: field 0 is never read

There are several warnings from clippy when running cargo test for the project:
warning: field `0` is never read
  --> examples/readme_test.rs:80:16
   |
80 |     Filesystem(embedded_sdmmc::Error<embedded_sdmmc::SdCardError>),
   |     ---------- ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   |     |
   |     field in this variant
   |
   = note: `#[warn(dead_code)]` on by default
help: consider changing the field to be of unit type to suppress this warning while preserving the field numbering, or remove the field
   |
80 |     Filesystem(()),
   |                ~~

warning: field `0` is never read
  --> examples/readme_test.rs:81:10
   |
81 |     Disk(embedded_sdmmc::SdCardError),
   |     ---- ^^^^^^^^^^^^^^^^^^^^^^^^^^^
   |     |
   |     field in this variant
   |
help: consider changing the field to be of unit type to suppress this warning while preserving the field numbering, or remove the field
   |
81 |     Disk(()),
   |          ~~

warning: field `0` is never read
  --> tests/utils/mod.rs:46:8
   |
46 |     Io(std::io::Error),
   |     -- ^^^^^^^^^^^^^^
   |     |
   |     field in this variant
   |
   = note: `#[warn(dead_code)]` on by default
help: consider changing the field to be of unit type to suppress this warning while preserving the field numbering, or remove the field
   |
46 |     Io(()),
   |        ~~

warning: field `0` is never read
  --> tests/utils/mod.rs:48:12
   |
48 |     Decode(flate2::DecompressError),
   |     ------ ^^^^^^^^^^^^^^^^^^^^^^^
   |     |
   |     field in this variant
   |
help: consider changing the field to be of unit type to suppress this warning while preserving the field numbering, or remove the field
   |
48 |     Decode(()),
   |            ~~

warning: field `0` is never read
  --> tests/utils/mod.rs:50:17
   |
50 |     OutOfBounds(BlockIdx),
   |     ----------- ^^^^^^^^
   |     |
   |     field in this variant
   |
help: consider changing the field to be of unit type to suppress this warning while preserving the field numbering, or remove the field
   |
50 |     OutOfBounds(()),
   |                 ~~

warning: `embedded-sdmmc` (example "readme_test") generated 2 warnings
warning: `embedded-sdmmc` (test "open_files") generated 3 warnings (3 duplicates)
warning: `embedded-sdmmc` (test "write_file") generated 3 warnings
warning: `embedded-sdmmc` (test "volume") generated 3 warnings (3 duplicates)
warning: `embedded-sdmmc` (test "directories") generated 3 warnings (3 duplicates)
warning: `embedded-sdmmc` (test "read_file") generated 3 warnings (3 duplicates)

Do you have special clippy rules or perhaps are you using nightly? I can't work out how to get some of those errors.

or perhaps are you using nightly

Turns out I do!
$ cargo --version
cargo 1.79.0-nightly (74fd5bc73 2024-04-10)

$ rustc --version
rustc 1.79.0-nightly (a07f3eb43 2024-04-11)

Ok so for the test code I think I will just allow unused values, because they might be useful debug info if a test fails and I'm not sure the unused analysis pays attention to debug impls.


Add unit tests for add_env_vars kwarg

As the title.

Closing this because:

Checking the existance/update of the process env vars can be delegated to subprocess package.
I will require to read env vars using mapdl.sys, which although achievable, it is not a high priority, nor needed for any other issue.


allow non-nag parsing #217

Hey, this is my first attempt to this, and my first experience with scala-parser-combinators.  I’d welcome some feedback.

What bugs are we fixing here?

See #217 for an example. It's not a bug, strictly speaking, because those PGNs are not following the standard, but nice to have.
If something like this lands, we should revisit the glyphs at the end of https://github.com/ornicar/scalachess/blob/2dda24b22b171a987b2c0f901f4f46b1a2dc9565/src/main/scala/format/pgn/Parser.scala#L112.

I wasn't allowed to push on the pull request branch, so I made mine: https://github.com/ornicar/scalachess/commits/tdgs-allow_non_nag_parsing
What makes you think that regex should be changed? from what I see it's not meant to match these symbols: moveRegex ~ nagGlyphs https://github.com/ornicar/scalachess/blob/cff1c38a40ca8809158ceafb082bb2ec8c91fe1c/src/main/scala/format/pgn/Parser.scala#L117

I didn't look into this deeply, so maybe I am misunderstanding. I mean that nagGlyphs should probably handle suffixes like e4? now. It currently matches as move e4? without glyph, when it should be e4 with glyph ?.

From what I could gather, the nagGlyphs was handling things like $123, but not things like ⩱.

I just rebased on top of the current master.


Reset map

We should have a reset map button.
This would put the map back to the original zoom and coordinates.
Only need to appear once we zoom in a bit.
Could be a yellow button in the top centre
@dantravers for you to think about how to prioritize this.

I would be inclined to wait and see if we need this.   I find with maps usually you can scroll and zoom around easily enough to get to where you want, and I'm also not sure if people would like it reset to our defaults - they may have their own defaults.
I would suggest a good one to collect some user feedback on before we add another button.


integration not visible in configuration

After following the instructions the Vaillant integration is not visible.
HACS does not give any problems. In my custom_components folder there is a vaillant-vsmart folder with content.
Despite that I can not find the integration when I want to add it.
ANy idea what can be the reason? There are no loggings related to vaillant. only logging I have is:
Logger: homeassistant.setup
Source: /usr/local/lib/python3.9/asyncio/events.py:80
First occurred: 11:16:50 AM (1 occurrences)
Last logged: 11:16:50 AM
Setup of input_boolean is taking over 10 seconds.

issue resolved by clearing cache. Then the integration was visible


Data has no return type when using geojson()

Bug report

[x] I confirm this is a bug with Supabase, not with my own application.
[x] I confirm I have searched the Docs, GitHub Discussions, and Discord.

Describe the bug
When using const {data, error} = await supabase         .from('table')         .select()         .geojson(); it returns data with type Record<string, unknown> | null. I expect it to return a GeoJson object with data of the correct type.
To Reproduce
Run the query const {data, error} = await supabase         .from('table')         .select()         .geojson();
Expected behavior
I expect it to return a GeoJson object with data of the correct type.
Screenshots
System information

OS: macOS
Browser (if applies): React Native (iOS)
Version of supabase-js: 2.42.4
Version of Node.js: 20.5.1

Additional context

could you provide how your data looks like


Tags: added index on ContentTagRecord table.

Added index on field TagsPartRecord_Id in table ContentTagRecord for performance enhancement.
See issue #7590.

Is the actual query on this field only or the two fields of this table. Can you point to the line of code that does the query?
If it's using the two of them (as I would expect) then we need to include both fields in the index. We might also need two indexes btw.

I enabled SQL logging in log4net.config file:
<!-- Enable SQL Query Log. -->
<logger name="NHibernate.SQL">
  <priority value="DEBUG" />
</logger>

Then I edited a ContentItem containing tags and I got the following SQL query in my log:
SELECT tags0_.TagsPartRecord_id as TagsPart3_2_, tags0_.Id as Id2_, tags0_.Id as Id561_1_,
tags0_.TagRecord_id as TagRecord2_561_1_, tags0_.TagsPartRecord_id as TagsPart3_561_1_,
tagrecord1_.Id as Id562_0_, tagrecord1_.TagName as TagName562_0_
FROM Orchard_Tags_ContentTagRecord tags0_
left outer join Orchard_Tags_TagRecord tagrecord1_ on tags0_.TagRecord_id=tagrecord1_.Id
WHERE tags0_.TagsPartRecord_id=@p0;
@p0 = 1837 [Type: Int32 (0)]
Here the only where condition is on field TagsPartRecord_id.


[SPARK-48222][INFRA][DOCS] Sync Ruby Bundler to 2.4.22 and refresh Gem lock file

What changes were proposed in this pull request?
Sync the version of Bundler that we are using across various scripts and documentation. Also refresh the Gem lock file.
Why are the changes needed?
We are seeing inconsistent build behavior, likely due to the inconsistent Bundler versions.
Does this PR introduce any user-facing change?
No.
How was this patch tested?
CI + the preview release process.
Was this patch authored or co-authored using generative AI tooling?
No.

Thank you, @nchammas .
cc @cloud-fan although I'm sure he is testing this PR already. 😄

thanks, merging to master! (it's easier for me to test after merging it)

the Bundler issue is resolved, but I hit a new issue for generating pyspark docs
Configuration error:
There is a programmable error in your configuration file:

Traceback (most recent call last):
  File "/usr/local/lib/python3.8/dist-packages/sphinx/config.py", line 332, in eval_config_file
    exec(code, namespace)
  File "/opt/spark-rm/output/spark/python/docs/source/conf.py", line 27, in <module>
    from pyspark.pandas.supported_api_gen import generate_supported_api
  File "/opt/spark-rm/output/spark/python/pyspark/__init__.py", line 53, in <module>
    from pyspark.util import is_remote_only
  File "/opt/spark-rm/output/spark/python/pyspark/util.py", line 33, in <module>
    from pyspark.errors import PySparkRuntimeError
  File "/opt/spark-rm/output/spark/python/pyspark/errors/__init__.py", line 21, in <module>
    from pyspark.errors.exceptions.base import (  # noqa: F401
  File "/opt/spark-rm/output/spark/python/pyspark/errors/exceptions/base.py", line 21, in <module>
    from pyspark.errors.utils import ErrorClassesReader
  File "/opt/spark-rm/output/spark/python/pyspark/errors/utils.py", line 23, in <module>
    from pyspark.errors.error_classes import ERROR_CLASSES_MAP
  File "/opt/spark-rm/output/spark/python/pyspark/errors/error_classes.py", line 26, in <module>
    importlib.resources
AttributeError: module 'importlib.resources' has no attribute 'files'

maybe there is some python library version inconsistency between Github Action and release docker

cc @HyukjinKwon

It seems that files attribute is added at Python 3.9, but the running python version is Python 3.8, @cloud-fan .

https://importlib-resources.readthedocs.io/en/latest/using.html#migrating-from-legacy

Yes, and we dropped support for Python 3.8 in #46228.

Ya, as @nchammas mentioned, it seems that we missed to bump Python to 3.9 in spark-rm in the following PR.

#46228

I see, I'll install python 3.9 on the release docker image.


importing ProfileReport seems to interfere with matplotlib plotting  in jupyter notebook #837

Describe the bug
if you import matplotlib in jupyter notebook and run
import numpy as np
import numpy as np
import matplotlib as mpl
import matplotlib.pyplot as plt

# Silly example data
bp_x = np.linspace(0, 2*np.pi, num=40, endpoint=True)
bp_y = np.sin(bp_x)

# Make the plot
plt.plot(bp_x, bp_y, linewidth=3, linestyle="--",
         color="blue", label=r"Legend label $\sin(x)$")
plt.xlabel(r"Description of $x$ coordinate (units)")
plt.ylabel(r"Description of $y$ coordinate (units)")
plt.title(r"Title here (remove for papers)")
plt.xlim(0, 2*np.pi)
plt.ylim(-1.1, 1.1)
plt.legend(loc="lower left")
plt.show()

You get a plot.
if you import pandas profiling > 3.0.0 ( for example 3.1.0)
it breaks matplot lib.
from pandas_profiling import ProfileReport

* run code to plot again*
* no plot appears *

To Reproduce
We would need to reproduce your scenario before being able to resolve it.
Version information:
Version information is essential in reproducing and resolving bugs. Please report:
_Python version_: 3.7.11
 _Environment_:  Jupyter Notebook  local (python debian buster docker image

pip freeze:
keras==2.6.0
sklearn==0.0
jupyter==1.0.0
ipykernel==6.4.1
bash_kernel==0.7.2
kotlin-jupyter-kernel==<IP_ADDRESS>
scipy==1.7.1
simpy==4.0.1
matplotlib==3.4.3
numpy==1.21.2
pandas==1.3.3
requests==2.26.0
plotly==5.3.1
sympy==1.8
Pillow==8.3.2
h5py==3.4.0
google-api-python-client==2.23.0
tornado==6.0.3
papermill==2.3.3
notebook==6.0.2
pandas_profiling==3.1.0

Might come from setting the backend, could you check?
https://github.com/pandas-profiling/pandas-profiling/blob/develop/src/pandas_profiling/config.py#L8

yeah can confirm that setting that backend to agg breaks plotting in jupyter notebooks...
the default appears to be
mpl.get_backend() :  'module://matplotlib_inline.backend_inline'
maybe also related to #837 ?
Given that so many use jupyter for datascience/pandas stuff, maybe it could resolve the environment to see if ipython/jupyter is being used and if so set a different backend?

@jodom961 Yes, we should do this. Would you be interested in contributing a PR?

For sure.. will do shortly.


Edit by selecting shapes "inherit" the shape

I encountered a problem when working with multiple shapes. When I edit a shape and select a second shape to edit, the second shape changes to the same shape as the previous shape I edited.
GoShape - Master repo
Godot - 4 beta 1

Ok, sorry for that, i dont know make unique not working on my project, make new one and trying and works fine!

I've made this the default behaviour in 1.1.2, released just now.


[PE-D][Tester A] Phone number with + sign is not supported

Cannot have the phone number to include '+' sign(which is for indicating phone region number).

Labels: severity.Low type.FeatureFlaw
original: Mr-Teal/ped#4

i believe that "should only contain numbers" is clear enough that + cannot be used.


Secure key storage

Issue To Be Solved
Private keys are currently stored as plaintext fields in flow.json 👎 👎
While we have support for external signing solutions (e.g. Google KMS), we should still make it more secure to sign locally with the CLI. For example, it's common for developers to use the CLI to interact with testnet.
We should explore options to store private keys securely outside of flow.json.
Suggest A Solution
Ideas that come to mind:

Add option to load private key from environment variable
Add option to store private key in local OS keychain (is this possible?)
Add option to store private key in separate file

What about something like https://ssh-vault.com/ / https://github.com/ssh-vault/ssh-vault
Crazy?

Found a 'bash script' version of the same idea:
https://github.com/S2-/sshenc.sh

Is this really needed after we add support for keys as envvars or a sepearte private flow json file?

I don't think so. @psiemens since you opened this issue, does private config files and env variables solve all you had in mind opening this?

Solved in #101 #82 #82 and #100


ebook2cw: fix darwin build

Motivation for this change
ZHF: #122042
cc @NixOS/nixos-release-managers
Hydra failure: https://hydra.nixos.org/build/141984333/log
Things done

[ ] Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS linux)
Built on platform(s)

[ ] NixOS
[x] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
[x] Tested execution of all binary files (usually in ./result/bin/)
[ ] Determined the impact on package closure size (by running nix path-info -S before and after)
[ ] Ensured that relevant documentation is up to date
[ ] Fits CONTRIBUTING.md.

nixpkgs-review happy for me, macos 10.15, nixos x86_64.

I added an upgrade to 0.8.4, because that allows us to fetchpatch from upstream. (It doesn't apply to 0.8.3.)


[folding] Allow us to know if a region is folded or not

Type: Feature Request
I am developping a folding related extension (not published yet).
I often run into cases when I would need to know if a certain region is folded or not.
For example, when you perform a search with ctrl+f, if one of your search result is located within a folded region,
VS Code will automatically unfold this region to show the match.
So basically, in a just a few searches, the Search feature can very quickly unfold all the regions that the user took time to carefully fold when organizing is document.
So what I would like to do is when the user as finished his/her search allow him/her to put everything back to how it was before the Search feature unfolds everything.
For this, i need to regularly check which regions are folded or unfolded (ideally it would be super cool to be able to track each time the user folds or unfolds a region!)
If the API could allow us to do that, it would be great.
Do I make any sens?
Thank you for your help.
VS Code version: Code 1.75.1 (441438abd1ac652551dbe4d408dfcec8a499b8bf, 2023-02-08T21:32:34.589Z)
OS version: Windows_NT x64 10.0.19044
Modes:
Sandboxed: No

This comes up in a a lot of cases. For example, if I want to outline a range of text I need to know if the range is folded for the outline to be correct (does the outline go around the entire range, or only the first line).


README: Remove trailing whitespace

With:
$ sed -i 's/[[:space:]]*$//' README.md

fixing some trailing whitespace that snuck in with ca0803d1
(Additional language for conformance statement, 2016-04-06, #374).
Future occurrences should be caught by git-validation, which checks
for whitespace issues now.

LGTM

LGTM