[macOS+macports+cmake] tcmalloc does not link on aarch64: Undefined symbols:  _tc_delete_aligned etc.

Something was broken after 2.10 here:
[ 82%] Linking CXX shared library libtcmalloc.dylib
/opt/local/bin/cmake -E cmake_link_script CMakeFiles/tcmalloc.dir/link.txt --verbose=ON
/usr/bin/clang++ -pipe -Os -Wno-deprecated-declarations -Wno-error=unknown-warning-option -Wno-unknown-warning-option -DNDEBUG -I/opt/local/include -stdlib=libc++ -isysroot/Library/Developer/CommandLineTools/SDKs/MacOSX14.sdk -fsized-deallocation -arch arm64 -isysroot /Library/Developer/CommandLineTools/SDKs/MacOSX14.sdk -mmacosx-version-min=14.0 -dynamiclib -Wl,-headerpad_max_install_names -L/opt/local/lib -Wl,-headerpad_max_install_names -Wl,-syslibroot,/Library/Developer/CommandLineTools/SDKs/MacOSX14.sdk -compatibility_version 9.14.5 -current_version 9.14.5 -o libtcmalloc.9.14.5.dylib -install_name @rpath/libtcmalloc.9.14.5.dylib CMakeFiles/tcmalloc.dir/src/tcmalloc.cc.o CMakeFiles/tcmalloc_internal_object.dir/src/common.cc.o CMakeFiles/tcmalloc_internal_object.dir/src/internal_logging.cc.o "CMakeFiles/tcmalloc_internal_object.dir/src/system-alloc.cc.o" CMakeFiles/tcmalloc_internal_object.dir/src/memfs_malloc.cc.o CMakeFiles/tcmalloc_internal_object.dir/src/safe_strerror.cc.o CMakeFiles/tcmalloc_internal_object.dir/src/central_freelist.cc.o CMakeFiles/tcmalloc_internal_object.dir/src/page_heap.cc.o CMakeFiles/tcmalloc_internal_object.dir/src/sampler.cc.o CMakeFiles/tcmalloc_internal_object.dir/src/span.cc.o CMakeFiles/tcmalloc_internal_object.dir/src/stack_trace_table.cc.o CMakeFiles/tcmalloc_internal_object.dir/src/static_vars.cc.o CMakeFiles/tcmalloc_internal_object.dir/src/symbolize.cc.o CMakeFiles/tcmalloc_internal_object.dir/src/thread_cache.cc.o CMakeFiles/tcmalloc_internal_object.dir/src/malloc_hook.cc.o CMakeFiles/tcmalloc_internal_object.dir/src/malloc_extension.cc.o CMakeFiles/tcmalloc_internal_object.dir/src/base/low_level_alloc.cc.o CMakeFiles/tcmalloc_internal_object.dir/src/mmap_hook.cc.o "CMakeFiles/tcmalloc_internal_object.dir/src/heap-profile-table.cc.o" "CMakeFiles/tcmalloc_internal_object.dir/src/heap-profiler.cc.o" CMakeFiles/tcmalloc_internal_object.dir/src/raw_printer.cc.o CMakeFiles/tcmalloc_internal_object.dir/src/emergency_malloc.cc.o CMakeFiles/tcmalloc_internal_object.dir/src/emergency_malloc_for_stacktrace.cc.o CMakeFiles/tcmalloc_internal_object.dir/src/memory_region_map.cc.o CMakeFiles/stacktrace_object.dir/src/stacktrace.cc.o CMakeFiles/stacktrace_object.dir/src/base/elf_mem_image.cc.o CMakeFiles/stacktrace_object.dir/src/base/vdso_support.cc.o  -Wl,-rpath,/opt/local/lib libspinlock.a libsysinfo.a liblogging.a
ld: Undefined symbols:
  _tc_delete_aligned, referenced from:
      operator delete(void*, std::align_val_t) in tcmalloc.cc.o
  _tc_delete_aligned_nothrow, referenced from:
      operator delete(void*, std::align_val_t, std::nothrow_t const&) in tcmalloc.cc.o
  _tc_delete_sized_aligned, referenced from:
      operator delete(void*, unsigned long, std::align_val_t) in tcmalloc.cc.o
  _tc_deletearray_aligned, referenced from:
      operator delete[](void*, std::align_val_t) in tcmalloc.cc.o
  _tc_deletearray_aligned_nothrow, referenced from:
      operator delete[](void*, std::align_val_t, std::nothrow_t const&) in tcmalloc.cc.o
  _tc_deletearray_sized_aligned, referenced from:
      operator delete[](void*, unsigned long, std::align_val_t) in tcmalloc.cc.o
  _tc_new_aligned, referenced from:
      operator new(unsigned long, std::align_val_t) in tcmalloc.cc.o
  _tc_new_aligned_nothrow, referenced from:
      operator new(unsigned long, std::align_val_t, std::nothrow_t const&) in tcmalloc.cc.o
  _tc_newarray_aligned, referenced from:
      operator new[](unsigned long, std::align_val_t) in tcmalloc.cc.o
  _tc_newarray_aligned_nothrow, referenced from:
      operator new[](unsigned long, std::align_val_t, std::nothrow_t const&) in tcmalloc.cc.o
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make[2]: *** [libtcmalloc.9.14.5.dylib] Error 1

Identically fails with LLVM Clang 17.0.5.

I need more details. You're using cmake? What is exact incantation you use ? (BTW you are aware that cmake support is deeply experimental and mostly 'use at your own risk'?) It compiles fine on my osx testing box (m1 macbook air).

@alk I will generate logs and share now. (With and without our patches.)
It is great that you got MBA M1: building via Macports should be reproducible and fast, if you have Sonoma installed. (Ventura will have pre-built ports, but I have no Ventura installation to check gperftools 2.13 build there at the moment.)

@alk So here are logs from trying to build 2.13 on Sonoma/aarch64 (same hardware with yours), with and without patches from my PR (but of those only ARM recognition is relevant, PowerPC stuff is inconsequential here, obviously):
gperftools_2.13_sonoma_xcode_clang_no_patches.txt
gperftools_2.13_sonoma_xcode_clang.txt
This commit updates the portfile: https://github.com/barracuda156/macports-ports/commit/171894f5bd3df73f9bbd0fc10972fdff64b63df7 (it does not build for me atm on Sonoma, as described, so cannot be committed into Macports yet).
sudo port -v install gperftools should build the port; you could manually edit the portfile locally to build 2.13 instead of 2.10 which Macports currently has.

I submitted your proposed changes. Thanks.
As for this specific ticket, I don't promise much attention. This seems specific to osx+cmake and perhaps plus whatever ports stuff you use. On my osx test box cmake nearly builds (there is one odd thing about weak functions that affects malloc_bench only; and somehow only happens with whatever flags or something cmake build does on osex). So your failures, I'd strongly prefer you investigate more yourself. Can we somehow separate those failures from ports stuff ?
Also please be aware of https://github.com/gperftools/gperftools/issues/1462
And finally, I don't approve that ports thingy choosing cmake build. We do have known issues there. And for example plenty of tests fail. If you can affect it somehow, please make it stop doing cmake stuff.
Or perhaps I should consider just amputating our "best but in practice not so good effort" cmake support?

@alk I will try building via auto tools and if that succeeds, try to figure out why CMake build fails.

@alk I will return to this in a couple of days, but as a quick update, the problem does not appear related to macOS version, arch or compiler. Here is the failure from 10.6 PowerPC with gcc13:
:info:build [ 71%] Linking CXX shared library libtcmalloc_minimal.dylib
:info:build /opt/local/bin/cmake -E cmake_link_script CMakeFiles/tcmalloc_minimal.dir/link.txt --verbose=ON
:info:build /opt/local/bin/g++-mp-13 -pipe -Os -DNDEBUG -I/opt/local/include -D_GLIBCXX_USE_CXX11_ABI=0 -Wall -Wwrite-strings -Woverloaded-virtual -Wno-sign-compare -fsized-deallocation -arch ppc -mmacosx-version-min=10.6 -dynamiclib -Wl,-headerpad_max_install_names -L/opt/local/lib -Wl,-headerpad_max_install_names -compatibility_version 9.14.5 -current_version 9.14.5 -o libtcmalloc_minimal.9.14.5.dylib -install_name @rpath/libtcmalloc_minimal.9.14.5.dylib CMakeFiles/tcmalloc_minimal.dir/src/tcmalloc.cc.o CMakeFiles/tcmalloc_minimal_internal_object.dir/src/common.cc.o CMakeFiles/tcmalloc_minimal_internal_object.dir/src/internal_logging.cc.o "CMakeFiles/tcmalloc_minimal_internal_object.dir/src/system-alloc.cc.o" CMakeFiles/tcmalloc_minimal_internal_object.dir/src/memfs_malloc.cc.o CMakeFiles/tcmalloc_minimal_internal_object.dir/src/safe_strerror.cc.o CMakeFiles/tcmalloc_minimal_internal_object.dir/src/central_freelist.cc.o CMakeFiles/tcmalloc_minimal_internal_object.dir/src/page_heap.cc.o CMakeFiles/tcmalloc_minimal_internal_object.dir/src/sampler.cc.o CMakeFiles/tcmalloc_minimal_internal_object.dir/src/span.cc.o CMakeFiles/tcmalloc_minimal_internal_object.dir/src/stack_trace_table.cc.o CMakeFiles/tcmalloc_minimal_internal_object.dir/src/static_vars.cc.o CMakeFiles/tcmalloc_minimal_internal_object.dir/src/symbolize.cc.o CMakeFiles/tcmalloc_minimal_internal_object.dir/src/thread_cache.cc.o CMakeFiles/tcmalloc_minimal_internal_object.dir/src/malloc_hook.cc.o CMakeFiles/tcmalloc_minimal_internal_object.dir/src/malloc_extension.cc.o  -Wl,-rpath,/opt/local/lib libspinlock.a libsysinfo.a liblogging.a
:info:build Undefined symbols:
:info:build   "_tc_deletearray_aligned_nothrow", referenced from:
:info:build       __ZdaPvSt11align_val_tRKSt9nothrow_t in tcmalloc.cc.o
:info:build   "_tc_deletearray_sized_aligned", referenced from:
:info:build       __ZdaPvmSt11align_val_t in tcmalloc.cc.o
:info:build   "_tc_delete_sized_aligned", referenced from:
:info:build       __ZdlPvmSt11align_val_t in tcmalloc.cc.o
:info:build   "_tc_new_aligned_nothrow", referenced from:
:info:build       __ZnwmSt11align_val_tRKSt9nothrow_t in tcmalloc.cc.o
:info:build   "_tc_delete_aligned", referenced from:
:info:build       __ZdlPvSt11align_val_t in tcmalloc.cc.o
:info:build   "_tc_newarray_aligned", referenced from:
:info:build       __ZnamSt11align_val_t in tcmalloc.cc.o
:info:build   "_tc_new_aligned", referenced from:
:info:build       __ZnwmSt11align_val_t in tcmalloc.cc.o
:info:build   "_tc_newarray_aligned_nothrow", referenced from:
:info:build       __ZnamSt11align_val_tRKSt9nothrow_t in tcmalloc.cc.o
:info:build   "_tc_deletearray_aligned", referenced from:
:info:build       __ZdaPvSt11align_val_t in tcmalloc.cc.o
:info:build   "_tc_delete_aligned_nothrow", referenced from:
:info:build       __ZdlPvSt11align_val_tRKSt9nothrow_t in tcmalloc.cc.o
:info:build ld: symbol(s) not found
:info:build collect2: error: ld returned 1 exit status
:info:build make[2]: *** [libtcmalloc_minimal.9.14.5.dylib] Error 1

@alk Sorry for a delay, much stuff in the pipeline.
I can confirm that at least on macOS 14.2.1 gperftools 2.13 builds fine with makefiles and whatever options were picked by default (I did not customize the build, just commented out CMake-specific stuff).
gperftools_makefiles.log

While it still fails on the same OS with CMake:
gperftools_cmake_fail.log

Thanks for update. Perhaps then consider running those same steps manually (check if some of your patches affect stuff; probably not, but who knows). I'd also compare more closely compiler flags.

@alk For sure patches have nothing to do with this. I reran the build, dropping all our patches, and it still failed with CMake the same way:
gperftools_cmake_default.log

Consider checking what symbols are in debugallocation.cc and tcmalloc.cc where it fails to locate functions.
Something like this:
objdump -t src/.libs/libtcmalloc_minimal_la-tcmalloc.o

(No idea if osx has objdump but I think it should)

I'd also compare more closely compiler flags.

@alk Looks like CMake build adds -Dtcmalloc_minimal_debug_EXPORTS and -Dtcmalloc_EXPORTS which are not there in makefiles build. These look suspicious. Perhaps these are breaking it?

No idea. If so why it only breaks it on your system ?

No idea. If so why it only breaks it on your system ?

Given that it is reproducible on two completely different systems (different OS versions, different archs, different compilers, different linkers, different standard library), I do not think it is anything related to a particular system. It could be that Macports CMake is doing something which causes the breakage or otherwise something in the source, or something with choice of options.

@alk So I am sure it is something on the side of CMake build implementation. But it is partly fixed in the master (but broken in 2.13).
Specifically, with tests and benchmarks disabled the build is successful from the master branch 8987d08f792c1c694849a6e779735bfcf50ac8a4
With default setting build fails but on:
[ 54%] Linking CXX executable malloc_bench
/opt/local/bin/cmake -E cmake_link_script CMakeFiles/malloc_bench.dir/link.txt --verbose=ON
/usr/bin/clang++ -pipe -Os -Wno-deprecated-declarations -Wno-error=unknown-warning-option -Wno-unknown-warning-option -DNDEBUG -I/opt/local/include -stdlib=libc++ -isysroot/Library/Developer/CommandLineTools/SDKs/MacOSX14.sdk -fsized-deallocation -arch arm64 -isysroot /Library/Developer/CommandLineTools/SDKs/MacOSX14.sdk -mmacosx-version-min=14.0 -Wl,-search_paths_first -Wl,-headerpad_max_install_names -L/opt/local/lib -Wl,-headerpad_max_install_names -Wl,-syslibroot,/Library/Developer/CommandLineTools/SDKs/MacOSX14.sdk CMakeFiles/malloc_bench.dir/benchmark/malloc_bench.cc.o -o malloc_bench  -Wl,-rpath,/opt/local/lib librun_benchmark.a libtcmalloc_minimal.a libspinlock.a libsysinfo.a liblogging.a
ld: Undefined symbols:
  _tc_delete_sized, referenced from:
      _main in malloc_bench.cc.o
      bench_fastpath_simple_sized(long, unsigned long) in malloc_bench.cc.o
  _tc_memalign, referenced from:
      _main in malloc_bench.cc.o
      bench_fastpath_memalign(long, unsigned long) in malloc_bench.cc.o
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make[2]: *** [malloc_bench] Error 1

Ah, I thought I merged workaround for this. Apple's stuff seemingly has borked weak symbols support.
Just replace ifdef GNUC with something like defined(GNUC) && !defined(APPLE)

I can also confirm that without tests/benchmarks master branch builds on PowerPC as well with CMake.

Things have changed and general shape of cmake support, while is better than before, is still un-supported. If anyone needs better cmake support, contribute (and we already have plenty of "cmake support needs more work" tickets).

I think I switched the port to makefiles back then, and it still should be using that, not CMake, in MacPorts.


Generating type with openapi-gen that includes Quantity, does not succeed to generate entry for infDecAmount

I have some type that looks like
type EmptyDiskSource struct {
	// Capacity of the sparse disk.
	Capacity resource.Quantity `json:"capacity"`
}

when I run openapi-gen on it, I have
"kubevirt.io/kubevirt/pkg/api/v1.EmptyDiskSource": {
			Schema: spec.Schema{
				SchemaProps: spec.SchemaProps{
					Description: "EmptyDisk represents a temporary disk which shares the vmis lifecycle.",
					Properties: map[string]spec.Schema{
						"capacity": {
							SchemaProps: spec.SchemaProps{
								Description: "Capacity of the sparse disk.",
								Ref:         ref("k8s.io/apimachinery/pkg/api/resource.Quantity"),
							},
						},
					},
					Required: []string{"capacity"},
				},
			},
			Dependencies: []string{
				"k8s.io/apimachinery/pkg/api/resource.Quantity"},
		},
...
"k8s.io/apimachinery/pkg/api/resource.Quantity": {
			Schema: spec.Schema{
				SchemaProps: spec.SchemaProps{
					Description: "Quantity is a fixed-point representation of a number. It provides convenient marshaling/unmarshaling in JSON and YAML, in addition to String() and Int64() accessors.\n\nThe serialization format is:\n\n<quantity>        ::= <signedNumber><suffix>\n  (Note that <suffix> may be empty, from the \"\" case in <decimalSI>.)\n<digit>           ::= 0 | 1 | ... | 9 <digits>          ::= <digit> | <digit><digits> <number>          ::= <digits> | <digits>.<digits> | <digits>. | .<digits> <sign>            ::= \"+\" | \"-\" <signedNumber>    ::= <number> | <sign><number> <suffix>          ::= <binarySI> | <decimalExponent> | <decimalSI> <binarySI>        ::= Ki | Mi | Gi | Ti | Pi | Ei\n  (International System of units; See: http://physics.nist.gov/cuu/Units/binary.html)\n<decimalSI>       ::= m | \"\" | k | M | G | T | P | E\n  (Note that 1024 = 1Ki but 1000 = 1k; I didn't choose the capitalization.)\n<decimalExponent> ::= \"e\" <signedNumber> | \"E\" <signedNumber>\n\nNo matter which of the three exponent forms is used, no quantity may represent a number greater than 2^63-1 in magnitude, nor may it have more than 3 decimal places. Numbers larger or more precise will be capped or rounded up. (E.g.: 0.1m will rounded up to 1m.) This may be extended in the future if we require larger or smaller quantities.\n\nWhen a Quantity is parsed from a string, it will remember the type of suffix it had, and will use the same type again when it is serialized.\n\nBefore serializing, Quantity will be put in \"canonical form\". This means that Exponent/suffix will be adjusted up or down (with a corresponding increase or decrease in Mantissa) such that:\n  a. No precision is lost\n  b. No fractional digits will be emitted\n  c. The exponent (or suffix) is as large as possible.\nThe sign will be omitted unless the number is negative.\n\nExamples:\n  1.5 will be serialized as \"1500m\"\n  1.5Gi will be serialized as \"1536Mi\"\n\nNOTE: We reserve the right to amend this canonical format, perhaps to\n  allow 1.5 to be canonical.\n  or after March 2015.\n\nNote that the quantity will NEVER be internally represented by a floating point number. That is the whole point of this exercise.\n\nNon-canonical values will still parse as long as they are well formed, but will be re-emitted in their canonical form. (So always use canonical form, or don't diff.)\n\nThis format is intended to make it difficult to use these numbers without writing some sort of special handling code in the hopes that that will cause implementors to also use a fixed point implementation.",
					Properties: map[string]spec.Schema{
						"i": {
							SchemaProps: spec.SchemaProps{
								Description: "i is the quantity in int64 scaled form, if d.Dec == nil",
								Ref:         ref("k8s.io/apimachinery/pkg/api/resource.int64Amount"),
							},
						},
						"d": {
							SchemaProps: spec.SchemaProps{
								Description: "d is the quantity in inf.Dec form if d.Dec != nil",
								Ref:         ref("k8s.io/apimachinery/pkg/api/resource.infDecAmount"),
							},
						},
						"s": {
							SchemaProps: spec.SchemaProps{
								Description: "s is the generated value of this quantity to avoid recalculation",
								Type:        []string{"string"},
								Format:      "",
							},
						},
						"Format": {
							SchemaProps: spec.SchemaProps{
								Description: "Change Format at will. See the comment for Canonicalize for more details.",
								Type:        []string{"string"},
								Format:      "",
							},
						},
					},
					Required: []string{"i", "d", "s", "Format"},
				},
			},
			Dependencies: []string{
				"k8s.io/apimachinery/pkg/api/resource.infDecAmount", "k8s.io/apimachinery/pkg/api/resource.int64Amount"},
		},
...
"k8s.io/apimachinery/pkg/api/resource.int64Amount": {
			Schema: spec.Schema{
				SchemaProps: spec.SchemaProps{
					Description: "int64Amount represents a fixed precision numerator and arbitrary scale exponent. It is faster than operations on inf.Dec for values that can be represented as int64.",
					Properties: map[string]spec.Schema{
						"value": {
							SchemaProps: spec.SchemaProps{
								Type:   []string{"integer"},
								Format: "int64",
							},
						},
						"scale": {
							SchemaProps: spec.SchemaProps{
								Type:   []string{"integer"},
								Format: "int32",
							},
						},
					},
					Required: []string{"value", "scale"},
				},
			},
			Dependencies: []string{},
		},
...

but I do not have entry for k8s.io/apimachinery/pkg/api/resource.infDecAmount, I think it because that infDecAmount type includes type from go standard library and they can not be auto-generated by openapi-gen. I can set // +k8s:openapi-gen=false on problematic field
// d is the quantity in inf.Dec form if d.Dec != nil
// +k8s:openapi-gen=false
d infDecAmount

,  but I do not sure if it good solution.

that's odd... you shouldn't get all of those internal fields... they are not part of the wire-format and are not exposed externally.
you should get something like this:
"io.k8s.apimachinery.pkg.api.resource.Quantity": {     "description": "Quantity is a fixed-point representation of a number. It provides convenient marshaling/unmarshaling in JSON and YAML, in addition to String() and Int64() accessors.\n\nThe serialization format is:\n\n\u003cquantity\u003e        ::= \u003csignedNumber\u003e\u003csuffix\u003e\n  (Note that \u003csuffix\u003e may be empty, from the \"\" case in \u003cdecimalSI\u003e.)\n\u003cdigit\u003e           ::= 0 | 1 | ... | 9 \u003cdigits\u003e          ::= \u003cdigit\u003e | \u003cdigit\u003e\u003cdigits\u003e \u003cnumber\u003e          ::= \u003cdigits\u003e | \u003cdigits\u003e.\u003cdigits\u003e | \u003cdigits\u003e. | .\u003cdigits\u003e \u003csign\u003e            ::= \"+\" | \"-\" \u003csignedNumber\u003e    ::= \u003cnumber\u003e | \u003csign\u003e\u003cnumber\u003e \u003csuffix\u003e          ::= \u003cbinarySI\u003e | \u003cdecimalExponent\u003e | \u003cdecimalSI\u003e \u003cbinarySI\u003e        ::= Ki | Mi | Gi | Ti | Pi | Ei\n  (International System of units; See: http://physics.nist.gov/cuu/Units/binary.html)\n\u003cdecimalSI\u003e       ::= m | \"\" | k | M | G | T | P | E\n  (Note that 1024 = 1Ki but 1000 = 1k; I didn't choose the capitalization.)\n\u003cdecimalExponent\u003e ::= \"e\" \u003csignedNumber\u003e | \"E\" \u003csignedNumber\u003e\n\nNo matter which of the three exponent forms is used, no quantity may represent a number greater than 2^63-1 in magnitude, nor may it have more than 3 decimal places. Numbers larger or more precise will be capped or rounded up. (E.g.: 0.1m will rounded up to 1m.) This may be extended in the future if we require larger or smaller quantities.\n\nWhen a Quantity is parsed from a string, it will remember the type of suffix it had, and will use the same type again when it is serialized.\n\nBefore serializing, Quantity will be put in \"canonical form\". This means that Exponent/suffix will be adjusted up or down (with a corresponding increase or decrease in Mantissa) such that:\n  a. No precision is lost\n  b. No fractional digits will be emitted\n  c. The exponent (or suffix) is as large as possible.\nThe sign will be omitted unless the number is negative.\n\nExamples:\n  1.5 will be serialized as \"1500m\"\n  1.5Gi will be serialized as \"1536Mi\"\n\nNote that the quantity will NEVER be internally represented by a floating point number. That is the whole point of this exercise.\n\nNon-canonical values will still parse as long as they are well formed, but will be re-emitted in their canonical form. (So always use canonical form, or don't diff.)\n\nThis format is intended to make it difficult to use these numbers without writing some sort of special handling code in the hopes that that will cause implementors to also use a fixed point implementation.",     "type": "string"    },

what version of openapi-gen are you using?

you should get something like this:

Just to be sure do you talk about func GetOpenAPIDefinitions(ref common.ReferenceCallback) map[string]common.OpenAPIDefinition inside openapi_generated.go file, because I can see it includes only a single function.
I used branch release-1.9 to install it, maybe it really the reason, will try some recent branch.

Indeed, version was the source of the problem, after changing the branch from release-1.9 to release-1.10, resource.Quantity looks much better:
		"k8s.io/apimachinery/pkg/api/resource.Quantity": {
			Schema: spec.Schema{
				SchemaProps: spec.SchemaProps{
					Type:   resource.Quantity{}.OpenAPISchemaType(),
					Format: resource.Quantity{}.OpenAPISchemaFormat(),
				},
			},
		}

I close the issue, @liggitt thx for help.


Introduce a validation config for validating operation using rosetta-cli

Fixes # .
Motivation
There are lots of validation rosetta-cli doesn't perform on operation.
Few of them include

validating that deposit and withdraw balances
issuers might want to validate the number of operation for payment or fee

Solution
We introduce a validation config file which an asset issuer can specify and provide as an argument while doing check:data (more to come on how to use)
TODO:

Add more tests
Figure out how to release the package so that it doesn't break existing usage

Open questions

Pull Request Test Coverage Report for Build 14844

58 of 62 (93.55%)  changed or added relevant lines in 3 files are covered.
5 unchanged lines in 1 file lost coverage.
Overall coverage increased (+0.09%) to 77.759%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

asserter/asserter.go
25
27
92.59%

asserter/block.go
32
34
94.12%

Files with Coverage Reduction
New Missed Lines
%

asserter/block.go
5
88.89%

Totals

Change from base Build 14773:
0.09%

Covered Lines:
8489

Relevant Lines:
10917

💛  - Coveralls


Cache the list of xaml and resx headers to speedup VS project generation

Hi!
I've realized that for our huge multi-repository project cmake on Windows runs significantly slower than on Linux.
I've run it in standard VS2015 profiler just to check if there are low-hanging fruits.
Surprisingly GetExpectedResxHeaders and GetExpectedXamlHeaders functions were consuming about 38% of whole CPU time. The reason is that they are triggered for each line when you need to put file inside vcxproj (and check whether it is XAML/RESX header) and they populate a list from scratch.
So I decided to put it in local static var to keep content cached.
For our project the improvement with this change is from 4m44s to 4m12s.
Please let me know if I should use some other approach than static vars.
Regards,
Dmitry

Thanks.  Currently we support C++98 host compilers so please avoid using C++11.  Also, please look at caching in a member rather than a static local.
Please see CONTRIBUTING.rst for the preferred contribution path and submit this as a MR to our GitLab instance instead.

Clear, thanks! What would you recommend for C++98 compatibility? auto_ptr? Raw pointer deleted in destructor?

We use raw pointer deletes in the destructor broadly.  You could try a CM_AUTO_PTR member since cmGeneratorTarget is a non-copyable type.

The change was merged in GitLab: https://gitlab.kitware.com/cmake/cmake/merge_requests/505


piratewallet-lite-v1.0.8 can't sync on the block 2422855

There was an error sending the transaction. The error was:
Error: Error getting client: tonic::transport::Error(Transport, hyper::Error(Connect, Custom { kind: UnexpectedEof, error: "tls handshake eof" }))

Support, Charles Swank here; I have had many issues concerning my account in my lite wallet, one after another and the latest
one is depicted above: piratewallet-lite-v1.0.8 can't sync on the block 2422855 #108
There are over 59.xxxxxxx tokens missing, there should be about 1,038.xxxxxxxx tokens in my account over all. What is the problem? What are the issue's concerning Pirate.Black Lite Wallet. I'm getting nervous. See attachments below.
Please advise,
Charles Swank  (Tracex-sys)
Open
Kinopisk opened this issue 2 weeks ago · 0 comments
There was an error sending the transaction. The error was: Error: Error getting client: tonic::transport::Error(Transport, hyper::Error(Connect, Custom { kind: UnexpectedEof, error: "tls handshake eof" })).

update to the newest version


flutter generated package is causing problems for pub

TLDR: the generate: true behavior prevents pub's up to date check from working when combined with path dependencies. The pub issue is: https://github.com/dart-lang/pub/issues/2806
Short term solutions:

Tell users to disable generate: true
Have pub special case this package

Long-term solutions
Besides removing generate, we could replace the special generate keyword with a path dependency. This would have the same properties as the current generated package, but would work with pub.
pubspec.yaml
flutter:
  generate: true

 dependencies:
   ...

Becomes
flutter:
 dependencies:
   flutter_gen:
     path: .dart_tool/flutter_gen
   ...

The tool can use the presence of that  path dependency to opt in.
cc @jonasfj @zanderso @shihaohong

One issue with the path dependency is that pub will complain until it exists, that will make a chicken-and-egg problem of getting a resolution

One issue with the path dependency is that pub will complain until it exists, that will make a chicken-and-egg problem of getting a resolution

From  a pub perspective, any mutation of package_config.json will likely create scenarios where pub considers the package resolution outdated, and which then break dart run .. (formerly pub run ..), this includes dart test and dart run build_runner.
So to support generated packages like this, we will need some sort of contract with pub.  A crazy idea would be to always have pub add .dart_tool/ to package_config.json, such that package:.dart_tool/<folder>/mylib.dart points to .dart_tool/<folder>/mylib.dart. By convention we could the say that packages should generate files into .dart_tool/<packageName>/.
(Perhaps the naming would have to be a little different, but the gist is some name that is reserved for this purpose).

From  a pub perspective, any mutation of package_config.json will likely create scenarios where pub considers the package resolution outdated, and which then break dart run .. (formerly pub run ..), this includes dart test and dart run build_runner.
So to support generated packages like this, we will need some sort of contract with pub.  A crazy idea would be to always have pub add .dart_tool/ to package_config.json, such that package:.dart_tool/<folder>/mylib.dart points to .dart_tool/<folder>/mylib.dart. By convention we could the say that packages should generate files into .dart_tool/<packageName>/.
(Perhaps the naming would have to be a little different, but the gist is some name that is reserved for this purpose).

It further seems that the code on https://github.com/flutter/flutter/blob/master/packages/flutter_tools/lib/src/dart/pub.dart#L470 ends up relativizing all paths, making it even harder for pub to recognize that the package_config is still up-to-date. (This is hard to avoid with package:package_config. I filed https://github.com/dart-lang/package_config/issues/99, https://github.com/dart-lang/package_config/issues/100)

It further seems that the code on https://github.com/flutter/flutter/blob/master/packages/flutter_tools/lib/src/dart/pub.dart#L470 ends up relativizing all paths, making it even harder for pub to recognize that the package_config is still up-to-date. (This is hard to avoid with package:package_config. I filed https://github.com/dart-lang/package_config/issues/99, https://github.com/dart-lang/package_config/issues/100)

Would it be reasonable for generate: true to not overwrite the .dart_tool/package_config.json file but instead to create a new one .dart_tool/flutter/package_config.json or something along those lines, and then pass that through to everywhere that needs it instead of the default package config? Then it wouldn't be overwriting pubs package config which is always going to be problematic.

Would it be reasonable for generate: true to not overwrite the .dart_tool/package_config.json file but instead to create a new one .dart_tool/flutter/package_config.json or something along those lines, and then pass that through to everywhere that needs it instead of the default package config? Then it wouldn't be overwriting pubs package config which is always going to be problematic.

but instead to create a new one .dart_tool/flutter/package_config.json

If flutter starts to consistently use a different file, I'm not sure we won't just create more avenues for inconsistencies.
Side note: the name flutter_gen isn't a particularly good choice either, since it's already used by package:flutter_gen with 50 likes.
We could make a convention that pub ignores invalid package names in package_config.json. Then injecting a package name like flutter.generated would be less controversial.

but instead to create a new one .dart_tool/flutter/package_config.json

If flutter starts to consistently use a different file, I'm not sure we won't just create more avenues for inconsistencies.
Side note: the name flutter_gen isn't a particularly good choice either, since it's already used by package:flutter_gen with 50 likes.
We could make a convention that pub ignores invalid package names in package_config.json. Then injecting a package name like flutter.generated would be less controversial.

I think the big question would be whether anything other than flutter cares about this flutter_gen dir. Are those files imported in user code, etc. If so then I agree there would be inconsistency issues.
If only flutter needs to see it then I think a custom package config would be pretty reasonable, it should only have to pass the custom config to the top level tools it invokes and that should trickle down through everything else. We use custom package configs a lot in build_runner for instance because need to point at a local version of package deps that include generated files, and it hasn't caused problems.

I think the big question would be whether anything other than flutter cares about this flutter_gen dir. Are those files imported in user code, etc. If so then I agree there would be inconsistency issues.
If only flutter needs to see it then I think a custom package config would be pretty reasonable, it should only have to pass the custom config to the top level tools it invokes and that should trickle down through everything else. We use custom package configs a lot in build_runner for instance because need to point at a local version of package deps that include generated files, and it hasn't caused problems.

I don't think we'd want to wire up a new package config path for flutter. I could only guess as to the bugs that is going to cause in analyzer/IDEs based on project detection or quick edits.
If the path dependency won't completely work without flutter running first, I think we should probably just deprecate and remove this functionality and think of another approach - rather than trying to shoehorn the flutter functionality into pub

I don't think we'd want to wire up a new package config path for flutter. I could only guess as to the bugs that is going to cause in analyzer/IDEs based on project detection or quick edits.
If the path dependency won't completely work without flutter running first, I think we should probably just deprecate and remove this functionality and think of another approach - rather than trying to shoehorn the flutter functionality into pub

I think the big question would be whether anything other than flutter cares about this flutter_gen dir.

As I understand it, the flutter_gen package is to be imported from user-code to initialize l10n: https://flutter.dev/docs/development/accessibility-and-localization/internationalization.
That means everything that wants to analyze imports will care about finding the path to the generated files.

I think the big question would be whether anything other than flutter cares about this flutter_gen dir.

As I understand it, the flutter_gen package is to be imported from user-code to initialize l10n: https://flutter.dev/docs/development/accessibility-and-localization/internationalization.
That means everything that wants to analyze imports will care about finding the path to the generated files.

just deprecate and remove this functionality and think of another approach

Is there a viable alternative already?
One approach might be to generate the files into lib/src/generated/, and have the .gitignore of the flutter template mark that folder as ignored so the files wont be checked in.
Besides not wanting to commit the generated code, is there a reason it has to have its own package.

just deprecate and remove this functionality and think of another approach

Is there a viable alternative already?
One approach might be to generate the files into lib/src/generated/, and have the .gitignore of the flutter template mark that folder as ignored so the files wont be checked in.
Besides not wanting to commit the generated code, is there a reason it has to have its own package.

Generating files into or modifying files in a source directory during the build is not permitted.

Generating files into or modifying files in a source directory during the build is not permitted.

On Fri, Jan 15, 2021 at 2:15 AM Sigurd Meldgaard<EMAIL_ADDRESS>wrote:

just deprecate and remove this functionality and think of another approach
Is there a viable alternative already?
One approach might be to generate the files into lib/src/generated/, and
have the .gitignore of the flutter template mark that folder as ignored
so the files wont be checked in.
Besides not wanting to commit the generated code, is there a reason it has
to have its own package.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/flutter/flutter/issues/73870#issuecomment-760739639,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AQR7RC3S7Z4SDKUOECCZAJ3SZ72RHANCNFSM4WBF3DNA
.

--
Erica K Vance

On Fri, Jan 15, 2021 at 2:15 AM Sigurd Meldgaard<EMAIL_ADDRESS>wrote:

just deprecate and remove this functionality and think of another approach
Is there a viable alternative already?
One approach might be to generate the files into lib/src/generated/, and
have the .gitignore of the flutter template mark that folder as ignored
so the files wont be checked in.
Besides not wanting to commit the generated code, is there a reason it has
to have its own package.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/flutter/flutter/issues/73870#issuecomment-760739639,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AQR7RC3S7Z4SDKUOECCZAJ3SZ72RHANCNFSM4WBF3DNA
.

--
Erica K Vance

Generating files into or modifying files in a source directory during the build is not permitted.

What is the difference here between generating files into a package under .dart_tool/<something> versus lib/src? In both cases a real package which is included in the project is being modified.

Generating files into or modifying files in a source directory during the build is not permitted.

What is the difference here between generating files into a package under .dart_tool/<something> versus lib/src? In both cases a real package which is included in the project is being modified.

Yeah, I think in this case there is no difference/problem caused by where we generate the files

Yeah, I think in this case there is no difference/problem caused by where we generate the files

I'm not sure what you mean by "real package included in the project".
As far as tracking build dependencies between build rules, the tool's build system must be able to assume that nothing under lib/ (the source directory) is modified during the build. This is a bright-line rule that might not make sense in all cases, but I think it does make sense here, and I think we should maintain it to prevent dependency tracking mistakes from creeping in.

I'm not sure what you mean by "real package included in the project".
As far as tracking build dependencies between build rules, the tool's build system must be able to assume that nothing under lib/ (the source directory) is modified during the build. This is a bright-line rule that might not make sense in all cases, but I think it does make sense here, and I think we should maintain it to prevent dependency tracking mistakes from creeping in.

By "real package included in the project" I mean that the packages code is imported by the application and should be taken into account for invalidation. I don't see how it makes a difference to the tool whether the code is in the current package or a dependency in terms of that (or anything else)?
In other words it sounds like the difference is between the package ignoring changes to dependencies or missing changes to the current package, but the outcome is the same. It potentially builds a stale project.
Most likely either way in this case it doesn't matter - my assumption is that these files are generated early on before any compiler sees the files?

By "real package included in the project" I mean that the packages code is imported by the application and should be taken into account for invalidation. I don't see how it makes a difference to the tool whether the code is in the current package or a dependency in terms of that (or anything else)?
In other words it sounds like the difference is between the package ignoring changes to dependencies or missing changes to the current package, but the outcome is the same. It potentially builds a stale project.
Most likely either way in this case it doesn't matter - my assumption is that these files are generated early on before any compiler sees the files?

Most likely either way in this case it doesn't matter - my assumption is that these files are generated early on before any compiler sees the files?

I believe you are correct. These are (currently) generated as part of the flutter pub get process.

Generating files into or modifying files in a source directory during the build is not permitted.

Interesting. I was not aware. How does other(any) source-generators work then (think https://pub.dev/packages/json_serializable). They have to put the generated code somewhere?

Most likely either way in this case it doesn't matter - my assumption is that these files are generated early on before any compiler sees the files?

I believe you are correct. These are (currently) generated as part of the flutter pub get process.

Generating files into or modifying files in a source directory during the build is not permitted.

Interesting. I was not aware. How does other(any) source-generators work then (think https://pub.dev/packages/json_serializable). They have to put the generated code somewhere?

So we've identified two issues here:
(A) Flutter uses flutter_gen package name for injecting generated code, and,
(B) Flutter rewrites all absolute path to be relative paths (https://github.com/dart-lang/package_config/issues/99).

So we've identified two issues here:
(A) Flutter uses flutter_gen package name for injecting generated code, and,
(B) Flutter rewrites all absolute path to be relative paths (https://github.com/dart-lang/package_config/issues/99).

I'm going to reopen this (and leave it open), we've worked around flutter_gen in pub :tada:
But long term we need a convention for injection of packages / generated code.

I'm going to reopen this (and leave it open), we've worked around flutter_gen in pub :tada:
But long term we need a convention for injection of packages / generated code.

Hi ✋🏿,
I'm building code gen builder that's using flutter gen-l10n tool, under the hood.
Correct me if i'm wrong but this behavior only happen when the tool is used with --synthetic-package which is the current default.
The gen-l10n tool has a --output-dir or --output-localization-file option, what i don't understand is why just not deprecate the --synthetic-package option and set it false as default and generate the code in the output directory specified by the user.
This should not require flutter to modify any pub related config file.

Will I still experience this error if I don't have generate: true?
My pubspec.yaml:
     name: vepo
    description: The Vepo mobile app.
    publish_to: "none"
    version: 1.0.0+1

    environment:
      sdk: '>=2.12.0 <3.0.0'

    dependencies:
      flutter:
        sdk: flutter
      animate_do: ^2.0.0
      cloud_firestore: ^1.0.1
      dio: ^4.0.0
      enum_to_string: ^2.0.1
      firebase_analytics: ^7.1.1
      firebase_auth: ^1.0.1
      firebase_core: ^1.0.1
      flash: ^1.5.1
      flutter_hooks: ^0.16.0
      flutter_icons: ^1.1.0
      flutter_launcher_icons: ^0.9.0
      flutter_native_splash: ^1.1.7+1
      flutter_riverpod: ^0.13.1+1
      flutter_typeahead: ^3.1.1
      font_awesome_flutter: ^9.0.0
      freezed: ^0.14.1+2
      freezed_annotation: ^0.14.1
      google_fonts: ^2.0.0
      google_maps_webservice: ^0.0.20-nullsafety.2
      hive: ^2.0.2
      hive_flutter: ^1.0.0
      hive_generator: ^1.0.1
      hooks_riverpod: ^0.13.1+1
      http: ^0.13.1
      image_cropper: ^1.4.0
      image_picker: ^0.7.4
      json_annotation: ^4.0.1
      json_serializable: ^4.1.0
      keyboard_avoider: ^0.1.2
      logger: ^1.0.0
      reactive_forms: ^10.0.3
      rxdart: ^0.26.0
      smooth_page_indicator: ^0.2.3
      uuid: ^3.0.3

    dependency_overrides:
      font_awesome_flutter:
        path: /Users/benjaminfarquhar/dev/font_awesome_flutter-master

    dev_dependencies:
      flutter_test:
        sdk: flutter
      build_runner: ^1.11.1
      flutter_gen: ^3.0.2
      pedantic: ^1.11.0

    flutter:
      uses-material-design: true
      fonts:
        - family: VarelaRound
          fonts:
            - asset: assets/fonts/VarelaRound-Regular.ttf
        - family: Hind
          fonts:
            - asset: assets/fonts/Hind-Medium.ttf
      assets:
        - assets/images/

    flutter_gen:
      output: lib/

    flutter_icons:
      image_path: "assets/images/launcher_icon_ios.webp"
      android: false
      ios: true

    flutter_native_splash:
      image: assets/images/splash_screen.png
      color: "#22F2A6"

I've got this question on SO, Is this probably the same issue? What is the short term fix to get my code running, considering my code doesn't have generate: true in it? I have had to delete this part but it causes me to not have the icons I need so is a bad solution:
dependency_overrides:
  font_awesome_flutter:
    path: /Users/benjaminfarquhar/dev/font_awesome_flutter-master

Thanks!

Hi all,
Currently I have the same problem that has been described and the only solution is to put generate: false
flutter pub run build_runner build
Unhandled exception:
Bad state: Unable to generate package graph, no `C:\FlutterPruebas\electroapp\.dart_tool\flutter_gen\pubspec.yaml` found.
#0      _pubspecForPath (package:build_runner_core/src/package_graph/package_graph.dart:232:5)
#1      _parsePackageDependencies (package:build_runner_core/src/package_graph/package_graph.dart:206:21)
#2      PackageGraph.forPath (package:build_runner_core/src/package_graph/package_graph.dart:101:33)
<asynchronous suspension>
#3      main (file:///C:/src/flutter/.pub-cache/hosted/pub.dartlang.org/build_runner-2.1.7/bin/build_runner.dart:27:30)
<asynchronous suspension>
pub finished with exit code 255

flutter doctor
Doctor summary (to see all details, run flutter doctor -v):
[√] Flutter (Channel stable, 2.10.0, on Microsoft Windows [VersiÃ³n 10.0.19043.1466], locale es-ES)
[√] Android toolchain - develop for Android devices (Android SDK version 31.0.0)
[√] Chrome - develop for the web
[√] Visual Studio - develop for Windows (Visual Studio Community 2019 16.11.2)
[√] Android Studio (version 2020.3)
[√] VS Code (version 1.64.0)
[√] Connected device (3 available)
[√] HTTP Host Availability

• No issues found!

Is there any correct solution to solve this problem without having to put generate: false?
Thanks for your help.
Regards,
Jose

We've agreed to work on this, going with the "generate into source" strategy, as part of https://github.com/flutter/flutter/issues/157819.
Closing as a duplicate of https://github.com/flutter/flutter/issues/102983 to track in a single place.


fix: [CHAOS-2639]: Added release notes documentation for 1.21.x

Harness Developer Pull Request
Thanks for helping us make the Developer Hub better. The PR will be looked at
by the maintainers.
What Type of PR is This?

[ ] Issue
[ ] Feature
[ ] Maintenance/Chore

If tied to an Issue, list the Issue(s) here:

Issue(s)

House Keeping
Some items to keep track of. Screen shots of changes are optional but would help the maintainers review quicker.

[ ] Tested Locally
[ ] Optional Screen Shoot.

@deepakbolangady Can you get this merged?

Please check the Execution Link of the Pipeline for the Website Draft URL. This is located in the Preview Step and also is available in #hdh_alerts. E.g Website Draft URL: https://unique-id--harness-developer.netlify.app

Please check the Execution Link of the Pipeline for the Website Draft URL. This is located in the Preview Step and also is available in #hdh_alerts. E.g Website Draft URL: https://unique-id--harness-developer.netlify.app


skip during undo/redo causes history mismatch

I don't remember the exact criteria or repro steps, All I know is that it's some mix of undo, redo, and skipping. Possibly jumping as well.

One method to reproduce:

Open script.
Advance one stmt.
Roll back one stmt.
Roll ahead one stmt.
Advance one stmt.
Observe that the first stmt is now duplicated in the records.

There is still a way for this to trigger but haven't looked into it yet

New repro:

Start game
Advance 1
Rollback 1
Skip 1
Advance 1
Observe that the first stmts are now duplicated in the records.

OK. Pretty sure this is resolved now. Issue came from improperly, partially altering the History data structure. (History.last needed to be switched from records.back() to records.front())


Only clear security parameters on fatal alert

bbc1dab changed behavior even when a fatal alert isn't received.

Clearing the security parameters after the handshake (in all cases) is intended behaviour. If you need to use those parameters at the end of a handshake (typically to export channel bindings or key material), you should override the notifyHandshakeComplete callback. There are examples in the tests.
If you believe that is insufficient for your use-case, please give more details. BTW, I couldn't see the relevance of the commit you linked to.

@brandonweeks Great. In case you are unaware, there are some methods on TlsContext that might do what you are trying to use the master secret for:
exportChannelBinding, with constants in ChannelBinding class (RFC 5929)
exportKeyingMaterial, with labels in ExporterLabel class (RFC 5705)

These cover most usages of the master secret, and IMO should be preferred to making a copy of the master secret and re-implementing the logic externally. If you are implementing some other standard not covered by those, we might be interested in providing the functionality in BC too.


Please support listening on whatever port is available

Currently the Listener will try to get the port that was requested and otherwise will look around trying to find a free port. There are actually race conditions in the current code such that the Listener, when it tests if a port is free, sees that it is but before it can grab it the port can be taken at which point the Listener will fail.
A more robust solution is to set up the Listener to just grab whatever port happens to be free. This feature is supported in Java by specifying the port to listen to as '0'.
Making this work requires a number of changes:

Delete LiteListener.discoverEmptyPort
Change the LiteListener constructor to just take port specified (whatever value it is) and to either open that value or fail (in the case of 0 a failure means there are no free ports anywhere available)
Implement #25 or equivalent and make it available for discovering the port that was selected

@hideki What is the latest plan on android? Pls confirm..

Following document also cover how to change listener port.
http://developer.couchbase.com/documentation/mobile/1.2/develop/guides/couchbase-lite/tech-notes/p2p-replications-ssl/index.html


vagrant: bump all box versions

Same as #14630 but with correct branch name (pr/update-packer-ci-build), see #14630 (review)
These new box images include the updated cri-containerd, Go, pre-pulled
Docker images and updated Cilium images with iproute2 and CNI plugins.
See https://github.com/cilium/packer-ci-build/pull/247 for details.

test-me-please

test-me-please

Passed CI and received two reviews, one of which from @cilium/ci-structure. Marking as ready to merge.

Passed CI and received two reviews, one of which from @cilium/ci-structure. Marking as ready to merge.


Segmentation fault when using appender API

When using the appender API, you can generate a segfault if you break a foreign key constraint.
If you use the insert API, you will get a returned error when you conduct an insert that breaks a foreign key constraint.
The reproduction of the bug is in this repo: https://github.com/jubos/duckdb-sandbox
You can run the following to generate it:
cargo run test.db

could you try reproduce this issue using the c/c++ API? If reproducible means we should report it in duckdb repo

Had a similar thing happen to me when I appended rows with Primary Key values that were already in the table. Instead of returning an error it segfaulted.
Platform is macOS

I'm getting the same, @wangfenjin @Mause, since @jubos has provided a reproduction of the issue, surely this deserves to be investigated as a priority?

I'm getting the same, @wangfenjin @Mause, since @jubos has provided a reproduction of the issue, surely this deserves to be investigated as a priority?

I've investigated it yeah, but as neither myself nor Wang have merge access, our ability to fix it is limited

Sorry to ping you, I assumed since you're the most active contributors, you would have merge access.
To be honest, I think #287 is more problematic as that's (afaik) correct usage causing a memory error.

I have a branch where I've fixed quite a lot of bugs related to complex/nested types but I am waiting few of my changes to be merged before I can proceed. For now I just have a local copy.

That's great news @Swoorup, once you have a PR that you think might fix this or #287, let me know and I can test it with my code.
I'm very keen to use duckdb from Rust lots more, but I'd really like the memory errors to get fixed. We (Pydantic, the company) might be able to sponsor significantly if anyone is willing and able to work through these issues.

I roughly tested this particular issue in my branch and I get, which I assume is correct?
Failed to flush appender: DuckDBFailure(Error { code: Unknown, extended_code: 1 }, Some("Violates foreign key constraint because key \"id: 0\" does not exist in the referenced table"))
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

The issue with generated columns is different though I think. It doesn't segfault but panics on mismatched schema, as my approach is first getting the table schema and validating it against what will be appended.
I don't have time atm to polish it up and is quite deviated from this repo fit to my own purpose. I also removed anything else other than the data chunk and arrow for appending. What kind of sponsorships are we talking about? 😛

What kind of sponsorships are we talking about? 😛

I think we're now looking more at datafusion, but if duckdb becomes a priority again, I'll be in touch.


fix: Fix client.push issue and update README for Slack client verification

Relates to:
No specific issue linked.
Risks
Low. The changes primarily involve bug fixes and documentation updates, which should not affect other parts of the system.
Background
What does this PR do?
This pull request fixes a critical issue in the client initialization process by addressing the clients.push error. It also updates the README for the Slack client to include instructions on verifying event subscriptions.
What kind of change is this?
Bug fixes
Documentation updates
Documentation changes needed?
My changes require a change to the project documentation. The README has been updated accordingly.
Testing
Where should a reviewer start?
Review the changes in agent/src/index.ts for the client initialization fix and the updated README.md in the packages/client-slack directory.
Detailed testing steps
Verify that the client initialization process does not produce errors.
Ensure the Slack client README includes the new section on event subscription verification.

going to make additional fixes after


chore(main): release 0.0.18

:robot: I have created a release beep boop
0.0.18 (2024-06-28)
What's Changed

fix: add init.py by @chloedia in https://github.com/QuivrHQ/MegaParse/pull/54
fix: Update README.md by @chloedia in https://github.com/QuivrHQ/MegaParse/pull/56

Full Changelog: https://github.com/QuivrHQ/MegaParse/compare/v0.0.17...v0.0.18

This PR was generated with Release Please. See documentation.

:robot: Release is at https://github.com/QuivrHQ/MegaParse/releases/tag/v0.0.18 :sunflower:


replace 'problems' key with 'exercises' in config.json

see #18

I forgot to point out that as of exercism/x-api#137, it is safe to remove problems.


Discord and mail button not working

Go ahead, @sahilg861907! All the best and please try and complete both issues soon.

hello @chehak123 . I was Working on another issue of this same project. Now I have moved towards this issue. But couldn't see any page like the one shown in screenshot. After login in and then moving to teammates, choosing specific skills and clicking find teammates button, I should get what is shown in screenshot. But I couldn't.
Can You Please Instruct me how can I get it. or Else if anyone knows about it, please assign it to them.
I will work on another issue.

@chehak123 If no one working on this issue I want to work on this under GSSOC'22.Please assign it to me

go ahead @Shweta597


Minor enhancements to default behavior re: query optimization

Hey! Thank you so much for implementing Substrait support in DuckDB. I've been playing around with it and it's extremely useful.
I ran into some minor hiccups when using the Substrait functions, specifically around how query optimization is handled. This PR contains some enhancements that I hope are not too controversial (happy to make changes based on feedback, though!):

On the producer side, I disabled the in_clause optimization by default. For large IN clauses, this optimization rule generates a "mark join" against a ColumnDataCollection, and the ColumnDataCollection currently cannot be translated to Substrait (it throws this exception: Internal Error: CHUNK_GET). In theory, I think we could create a Virtual Table inside the Substrait plan, but I'm no database expert and have no clue if this optimization actually makes sense outside of DuckDB.

I added documentation for the enable_optimizer option. Since I wasn't aware of this initially, I tried enabling/disabling query optimization at the connection level, and was surprised to see that it had no effect on the Substrait generation functions. I updated these functions to respect the connection-level settings in case enable_optimizer is not explicitly specified. I also added documentation around this new behavior.

I also tried to leave the code cleaner than I found it in some areas:

Ensured that a clearer error message is provided when parsing a substrait::Plan from a JSON string fails.
Reduced some duplication inside substrait_extension.cpp.
Fixed a typo in the README (dificulty -> difficulty).

I ran make format and make test to adhere to the project standards.

In addition, could you also add tests that check the optimizer is properly disabled?

Sure! Should the new tests mainly go under test/sql/, or should I also write any tests for the Python/R/etc. APIs specifically?

SQL tests should suffice :-)

I think I've addressed all of the PR comments, and also added several test cases. Please let me know if you think I missed any test cases or if the tests could be improved!
The reason CI was failing was because disabling the IN clause rewriter uncovered a minor discrepancy caught by substrait-validator. When transforming an IN clause:
https://github.com/duckdb/substrait/blob/870bab8725d1123905296bfb1f35ce737434e0b3/src/to_substrait.cpp#L432-L444
The type of the value and the types of the options can be different. For example, when the expression is of the form column IN ('lit1', 'lit2'), where column is of DuckDB type VARCHAR, column's Substrait type is resolved to VARCHAR<N> (N depends on the column stats):
https://github.com/duckdb/substrait/blob/870bab8725d1123905296bfb1f35ce737434e0b3/src/to_substrait.cpp#L1002-L1017
Whereas the type of the literals are resolved to Substrait type STRING:
https://github.com/duckdb/substrait/blob/870bab8725d1123905296bfb1f35ce737434e0b3/src/to_substrait.cpp#L190-L194
It seems that substrait-validator considers these to be separate types and therefore disallows comparing them. This discrepancy probably wasn't caught before because small IN clauses are optimized to conjunctions of equal, and equal is an extension function whose usage could not be validated by substrait-validator.
I think the simplest solution is to always use the STRING type in Substrait, and this does make all of the existing test cases to pass. I recognize this is not ideal (it loses information gained from the column stats), but would be happy to consider other approaches! I just couldn't think of a better yet generic solution myself.

Thanks for all the work! It looks excellent.
Regarding the validator, IIRC we can disable specific warnings and errors per test, maybe that is something to try out?
I would also consider removing it if it starts to become an issue since the project has unfortunately been abandoned and it is not keeping up with the evolving substrait spec.

Regarding the validator, IIRC we can disable specific warnings and errors per test, maybe that is something to try out?

I would also consider removing it if it starts to become an issue since the project has unfortunately been abandoned and it is not keeping up with the evolving substrait spec.

These are all valid points! I'm very new to Substrait myself, so I'll leave it to your judgment as to what's the best solution here. The only point I'll add is that DuckDB's VARCHAR is semantically equivalent to Substrait's STRING type (i.e. strings of "unbounded" size), whereas Substrait's VARCHAR<N> is bounded in size. From this point alone, I think the changes in this PR are still relevant, and fortunately we don't have to silence any new warnings or anything. Seeing as there is no alternative to substrait-validator at the moment, I do feel it's worth keeping for the time being.
Btw - on an unrelated note, could you shed some light on why the R tests seem to be hanging? I'm not sure if it's related to the changes in this PR. Any tips would be appreciated 🙂

Oh nvm, looks like the R tests have been hanging on main, too.

Thanks! It looks great.

🎉
Btw, if I'd like to make additional contributions to this extension, should I start by opening issues? I saw this note on the DuckDB website in regards to this extension, so I was a bit afraid to make an issue in the first place:

If you have not asked for permission to ask for support, contact us prior to opening an issue. If you open an issue without doing so, we will close it without further review.


CurrReport.NewPage() Deprecated

Hi,
Is the Report.NewPage() a replacement for CurrReport.NewPage()?
I'm on Business Central v13 and it tells me that CurrReport.NewPage() is deprecated.
Unfortunately, Report.NewPage() does not seam to be available in my version...
Thanks

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: 43df8d6d-0fda-4419-6039-091663d86304
Version Independent ID: a41f4c48-db04-b986-0a4e-50f564c5a7ca
Content: NewPage Method - Business Central
Content Source: dev-itpro/developer/methods-auto/report/reportinstance-newpage-method.md
Service: dynamics365-business-central
GitHub Login: @SusanneWindfeldPedersen
Microsoft Alias: solsen

Hello, yes Report.NewPage() is replacing CurrReport.NewPage(). If you get a warning in your version that it will be deprecated, the new option should be available. If it isn't you should still have time to shift, this is only a warning for now. But if this is not so, please file a bug through your usual support channel. I hope this will resolve for you. Thanks.


is there anyway can make Signal has different YAxis and YAxis Arrange from top to bottom

Hi @swharden ,thanks very much for your answer ,I see https://github.com/ScottPlot/ScottPlot/issues/3816 .in that case ,he make 4 ScottPlot in a row .and make them very close to make them look like one table.
in my case i have 64 channel ,so i have 64 Signal in one table ,and i need to zoom them.
so i mean if my 64 sinal can have there own axis and these axis can arrangement from top to bottom .
but our muti axis is like this

i wish it look like this ,but those signal is in one plot .

https://github.com/ScottPlot/ScottPlot/issues/3954#issuecomment-2189034100


fix migration conflicts

Pre-Flight checklist

[ ] Migrations

[ ] Migration is backwards-compatible with current production code

[x] Testing

[x] Code is tested
[x] Changes have been manually tested

What are the relevant tickets?
NA
What's this PR do?
fix migrations conflicts
Screenshots (if appropriate)
(Optional)

Codecov Report

Merging #203 (f262e4d) into main (03e6e44) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##             main     #203   +/-   ##
=======================================
  Coverage   97.04%   97.04%
=======================================
  Files         124      124
  Lines        2811     2811
=======================================
  Hits         2728     2728
  Misses         83       83

Continue to review full report at Codecov.

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


Orderer integration test flake

Failing Stack:
[e][OrdererOrg.orderer1] 2021-12-18 10:24:00.328 UTC 005b INFO [orderer.consensus.etcdraft] catchUp -> Finished syncing with cluster up to and including block [10] channel=systemchannel node=1
[e][OrdererOrg.orderer1] panic: runtime error: invalid memory address or nil pointer dereference
[e][OrdererOrg.orderer1] [signal SIGSEGV: segmentation violation code=0x1 addr=0x0 pc=0xc7230a]
[e][OrdererOrg.orderer1]
[e][OrdererOrg.orderer1] goroutine 89 [running]:
[e][OrdererOrg.orderer1] github.com/hyperledger/fabric/orderer/consensus/etcdraft.(*Chain).apply(0xc00083a000, 0xc000014f78, 0x1, 0x1)
[e][OrdererOrg.orderer1] /home/vsts/work/1/fabric/orderer/consensus/etcdraft/chain.go:1149 +0xa8a
[e][OrdererOrg.orderer1] github.com/hyperledger/fabric/orderer/consensus/etcdraft.(*Chain).run(0xc00083a000)
[e][OrdererOrg.orderer1] /home/vsts/work/1/fabric/orderer/consensus/etcdraft/chain.go:781 +0x978
[e][OrdererOrg.orderer1] created by github.com/hyperledger/fabric/orderer/consensus/etcdraft.(*Chain).Start
[e][OrdererOrg.orderer1] /home/vsts/work/1/fabric/orderer/consensus/etcdraft/chain.go:368 +0x22f

Failing Builds:

https://dev.azure.com/Hyperledger/Fabric/_build/results?buildId=45519&view=logs&j=f2000854-c7fb-5d20-d92e-ea22102e0eb5&t=8c0b343e-a113-5c44-d189-698811f88d80
https://dev.azure.com/Hyperledger/Fabric/_build/results?buildId=44731&view=logs&j=f2000854-c7fb-5d20-d92e-ea22102e0eb5&t=8c0b343e-a113-5c44-d189-698811f88d80

as per stack frame line no. it is failing here:
https://github.com/hyperledger/fabric/blob/752853701709ce1d5d88db572cacf224ed0e4bd8/orderer/consensus/etcdraft/chain.go#L1147
Based on observation,  block data is empty array which could the reason for the SEGV while dereferencing the entry data as block b.Header.Number
[e][OrdererOrg.orderer3] 2021-12-30 11:21:21.537 UTC 0041 INFO [orderer.consensus.etcdraft] apply -> DEBUG block raw data:{Term:5 Index:19 Type:EntryNormal Data:[] XXX_unrecognized:[]} channel=systemchannel node=3

@guoger It is block type of EntryNormal,  can this type of raft entry be empty data & what conditions it can be empty?
In pipeline, it fails randomly. But I see the entry is empty every time with this scenario (ttps://github.com/hyperledger/fabric/blob/752853701709ce1d5d88db572cacf224ed0e4bd8/integration/raft/cft_test.go#L257). This raft entry received just after the orderer restart.
I confirmed through adding few debug statements above if block. like below:
	c.logger.Infof("DEBUG block raw data:%+v", ents[position])
	b := protoutil.UnmarshalBlockOrPanic(ents[position].Data)
	c.logger.Infof("DEBUG %+v\n", b)

	if c.accDataSize >= c.sizeLimit {

Maybe the problem is that c.sizeLimit changes?
The field c.accDataSize only changes when an entry with Data is encountered, so the other suspect would be the other side of the if c.accDataSize >= c.sizeLimit {
The field c.sizeLimit is written only in NewChain and detectConfChange
detectConfChange is called inside commitBlock which is called inside catchUp; that happens when a node syncs with a peer.... maybe it's worth checking the update model there
sizeLimit might have changed outside the apply(), and even though apply() did not encounter a data block (that can happen), the snapshot creation part was triggered?
to protect against that you simply need to augment the if:
if c.accDataSize >= c.sizeLimit && <the data pointed by position is not nil>

@tock-ibm

Maybe the problem is that c.sizeLimit changes?
Sorry, I am not sure on what changes are referenced here. As per my understanding, sizeLimit is fixed value from chain struct/config.

is raft message/entry with empty data array valid? what conditions raft send these messages? is it send by application?
{Term:5 Index:19 Type:EntryNormal Data:[] XXX_unrecognized:[]}

Yes, a raft entry w/o data is valid.
I think a config tx can dynamically change the sizeLimit. Thus, a catchUp with another peer that fetches that config block and brings this into effect during the sync would change that.

I think it is worth checking if that is the case.

I think a config tx can dynamically change the sizeLimit. Thus, a catchUp with another peer that fetches that config block and brings this into effect during the sync would change that.
I think it is worth checking if that is the case.

sizeLimit is not changed in this case.  This is the complete broadcast response msg where SoftState is nil & no. of committedEntries=1(entry’s Data field is empty array)

When the failing orderer restarted, it received initial set of entries from the other orderer(in this case orderer3). In that, there were few data blocks present which got committed. Hence the initial values were appliedIndex:8 sizeLimit:1024 accDataSize:63815 (just after restart, after sync with orderer)
[e][OrdererOrg.orderer1] 2022-01-04 18:33:01.023 UTC 0027 INFO [orderer.consensus.etcdraft] start -> Restarting raft node channel=systemchannel node=1
[e][OrdererOrg.orderer1] 2022-01-04 18:33:01.023 UTC 0028 INFO [orderer.consensus.etcdraft] becomeFollower -> 1 became follower at term 3 channel=systemchannel node=1
[e][OrdererOrg.orderer1] 2022-01-04 18:33:01.037 UTC 002e INFO [orderer.consensus.etcdraft] run -> DEBUG signal apply 8 <nil> {SoftState:<nil> HardState:{Term:3 Vote:1 Commit:8 XXX_unrecognized:[]} ReadStates:[] Entries:[] Snapshot:{Data:[] Metadata:{ConfState:{Nodes:[] Learners:[] XXX_unrecognized:[]} Index:0 Term:0 XXX_unrecognized:[]} XXX_unrecognized:[]} CommittedEntries:[{Term:1 Index:1 Type:EntryConfChange Data:[8 0 16 0 24 1] XXX_unrecognized:[]} {Term:1 Index:2 Type:EntryConfChange Data:[8 0 16 0 24 2] XXX_unrecognized:[]} {Term:1 Index:3 Type:EntryConfChange Data:[8 0 16 0 24 3] XXX_unrecognized:[]} {Term:2 Index:4 Type:EntryNormal Data:[] XXX_unrecognized:[]} {Term:2 Index:5 Type:EntryNormal Data:[ …..
[e][OrdererOrg.orderer1] 2022-01-04 18:33:01.039 UTC 0034 INFO [orderer.consensus.etcdraft] apply -> DEBUG updated value of position=4 and accDataSize:33788 channel=systemchannel node=1
[e][OrdererOrg.orderer1] 2022-01-04 18:33:01.040 UTC 0037 INFO [orderer.consensus.etcdraft] apply -> DEBUG updated value of position=6 and accDataSize:63815 channel=systemchannel node=1

if c.accDataSize >= c.sizeLimit {
select {
case c.gcC <- &gc{index: c.appliedIndex, state: c.confState, data: ents[position].Data}:
c.logger.Infof(“Accumulated %d bytes since last snapshot, exceeding size limit (%d bytes), “+
“taking snapshot at block [%d] (index: %d), last snapshotted block number is %d, current nodes: %+v”,
c.accDataSize, c.sizeLimit, b.Header.Number, c.appliedIndex, c.lastSnapBlockNum, c.confState.Nodes)
c.accDataSize = 0
c.lastSnapBlockNum = b.Header.Number
c.Metrics.SnapshotBlockNumber.Set(float64(b.Header.Number))
default:
c.logger.Warnf(“Snapshotting is in progress, it is very likely that SnapshotIntervalSize is too small”)
}
}

I think the channel c.gcC was not ready, hence default case got executed.
[e][OrdererOrg.orderer1] 2022-01-04 18:33:01.045 UTC 003e WARN [orderer.consensus.etcdraft] apply -> Snapshotting is in progress, it is very likely that SnapshotIntervalSize is too small channel=systemchannel node=1

When next time new block with empty data array received, the channel was ready but the block is not complete hence it resulted into PANIC condition.

[e][OrdererOrg.orderer1] 2022-01-04 18:33:09.534 UTC 0058 INFO [orderer.consensus.etcdraft] run -> DEBUG signal apply 1 <nil> {SoftState:<nil> HardState:{Term:5 Vote:3 Commit:20 XXX_unrecognized:[]} ReadStates:[] Entries:[] Snapshot:{Data:[] Metadata:{ConfState:{Nodes:[] Learners:[] XXX_unrecognized:[]} Index:0 Term:0 XXX_unrecognized:[]} XXX_unrecognized:[]} CommittedEntries:[{Term:5 Index:20 Type:EntryNormal Data:[] XXX_unrecognized:[]}] Messages:[{Type:MsgAppResp To:3 From:1 Term:5 LogTerm:0 Index:20 Entries:[] Commit:0 Snapshot:{Data:[] Metadata:{ConfState:{Nodes:[] Learners:[] XXX_unrecognized:[]} Index:0 Term:0 XXX_unrecognized:[]} XXX_unrecognized:[]} Reject:false RejectHint:0 Context:[] XXX_unrecognized:[]}] MustSync:false} channel=systemchannel node=1

consistently the issue can be reproduced with the testcase if we introduce an delay in snapshot routine startup.

func (c *Chain) gc() {
c.logger.Infof("DEBUG: delaying the snap shotter")
time.Sleep(1000 * time.Millisecond)
c.logger.Infof("DEBUG: the snap shotter is ready to listen")
for {
select {
case g := <-c.gcC:

In the function (c *Chain) apply , this code is not properly protected and can lead to a  segmentation fault, because at position=0, the entry.Type is ambiguous it can be either of {raftpb.EntryNormal, raftpb.EntryConfChange}, but this line tries to unmarshal it , assuming entry Type to be  raftpb.EntryConfChange. So we can prevent a seg fault if we do something like:
isNormalEntry := ents[position].Type == raftpb.EntryNormal
isEmpty := len(ents[position].Data) == 0

if c.accDataSize >= c.sizeLimit && (isNormalEntry && !isEmpty) {
		b := protoutil.UnmarshalBlockOrPanic(ents[position].Data)

So, we need to unmarshal data to a block only in case of raftpb.EntryNormal if position=0.


Move inactive maintainers to emeritus status

The TOC approved a requirement that maintainers
that have not been active in over three to six
months be move to emeritus status.
These maintainers have not been active in over
one year.
hyperledger/toc#32
Signed-off-by: Ry Jones<EMAIL_ADDRESS>

Hey @ryjones. I understand the idea behind the new policy. What changes with the "emeritus status" though? Is the maintainer still able to approve and merge code?
Also, does this policy apply at the repo level or the project level? Alex has been very active in other parts of the project. This particular repo just hasn't had a lot of activity in it in general. In fact, it hasn't had a commit in the last six months. So if we're applying the new rule at the repo level, I guess all the maintainers would now be emeritus? If it's at the project level, Alex is still very active and I don't think his status should be changed.

Sounds good. I have some FireFly repo "housekeeping" like this on my list to do at some point, and I will do that at the same time.


Use GhostUser if needed for TrackedTimes

When getting tracked times out of the db and loading their attributes handle not exist errors in a nicer way. (Also prevent an NPE.)
Fix #22006
Signed-off-by: Andrew Thornton<EMAIL_ADDRESS>

The tracked time loadAttributes code could be quite expensive and may get a lot of things out of the db repeatedly.
This and other places that use this loadAttributes style should really use a local cache.


Rework to fix some issues we had

our main.tsx had importers (which failed the if statement in transform),
so I added a config option
the reloading happened in some cases without it being necessary
the reloading didn't work in some cases

Feel free to accept only parts (or none) as I'm not sure if this works worse in other workflows and situations.
(e.g. the build fix commit)

@tennox thanks for submitting this PR! I am not working on Logseq plugins recently and I may not be able to review this pr very soon. If this fixes your issue, you can continue on your fork.


Merge

https://github.com/J-D-DISPATCH-365/Oneculture365/commit/a873361929787b25f291f819fd5cc8d5cb139b9f

Merge done.


Bing Website Clone

Project title
Bing Website Clone
Project Description
This is a Famous search engine powered by microsoft
Stack:

[x] Html
[x] CSS
[x] JavaScript
[x] ReactJS

/assign

/assign

Assigned u @Sulagna-Dutta-Roy

OHo Sorry don't make a PR we are not accepting😅

@Sulagna-Dutta-Roy


Don't crash on empty JSON strings

This fixes an issue which causes the following error when the edited crystal source file contains no errors:
SyntaxError: Unexpected end of input
  at Object.parse (native)
  at /home/pgkos/.atom/packages/linter-crystal/lib/linter-crystal.js:59:32

Doh! I forgot to test for no error files. Thanks. Will check it out when I
get home.
Also, if you don't mind. And don't feel super obligated to do it, but a
unit test for this scenario would be very helpful.
On Mon, Sep 21, 2015, 7:18 AM pgkos<EMAIL_ADDRESS>wrote:

This fixes an issue which causes the following error when the edited
crystal source file contains no errors:
SyntaxError: Unexpected end of input
at Object.parse (native)
at /home/pgkos/.atom/packages/linter-crystal/lib/linter-crystal.js:59:32

You can view, comment on, or merge this pull request online at:
https://github.com/atom-crystal/linter-crystal/pull/13
Commit Summary

Don't crash on empty strings

File Changes

M lib/linter-crystal.js
https://github.com/atom-crystal/linter-crystal/pull/13/files#diff-0
(22)

Patch Links:

https://github.com/atom-crystal/linter-crystal/pull/13.patch
https://github.com/atom-crystal/linter-crystal/pull/13.diff

—
Reply to this email directly or view it on GitHub
https://github.com/atom-crystal/linter-crystal/pull/13.

I have added a simple spec and squashed all the commits.

Beautiful. Thanks!

I'll publish the patch right now!


Minor changes to help windows installer generation

Copying all "base version sql files" rather than relying on the Makefile variables to only install a single version makes parsing the Makefile quite hard.  It doesn't hurt to have all base versions, so just use a wildcard t here too.  It having all the base versions is a problem they should probably be removed from the repository anyway.
Also don't try to translate the OOM message.  No other message is translated, and there's no translation file anyway.  This also helps generating windows installer as it avoids having to download and install libintl.

Note that with those changes (and additional changes in pg_msvc_generator) I can finally generate the zip and installers for all supported pg version (12 to 16 right now).
I can also add the generation scripts to this repo in a msvc directory if you want, so users could be able to do it themselves if they manage to properly setup their environments (which is surprisingly hard on windows).

Thanks you so much @rjuju


Repo Wheight-Loss

Please provide a summary of the feature
Cyclic has a limit of 250mb for builds. As it stands, we're at roughly 176mb, but I believe there are a few options available to us to explore to slim down the size and give us more clearance for future development.

Instead of importing the entire date-fns library, only import what we do.
Investigate our dependencies and see if you can find anything not being used
Check if tree shaking is functioning properly

Are there any potential issues you foresee with this feature
Pretty easy to break the repo if you pull a required dependency.
Is this feature related to any current or past issues? Please provide the
Additional context
Add any other context or screenshots about the feature request here.
Which Branch should this fix be Pulled into?
PR into Development
If you're interested in working on this feature, please comment so you can be assigned

Very small observation.  Should Repo Wheight-Loss be Repo Weight-Loss?

Very small observation. Should Repo Wheight-Loss be Repo Weight-Loss?
Yes 😂 thank you!

Most significant contributor to the size is mongodb-memory-server, setting MONGOMS_DISABLE_POSTINSTALL to a truthy in the environment variables page eliminates over half of the current bundle size - from 174.91 MB to 67.42 MB!
What this does is disables the postinstall script, which downloads an entire mongodb server instance binary - only used during development to allow developers to start developing without having to pass pre-existing MongoDB credentials to the application, and has no use during production.

Most significant contributor to the size is mongodb-memory-server, setting MONGOMS_DISABLE_POSTINSTALL to a truthy in the environment variables page eliminates over half of the current bundle size - from 174.91 MB to 67.42 MB!
What this does is disables the postinstall script, which downloads an entire mongodb server instance binary - only used during development to allow developers to start developing without having to pass pre-existing MongoDB credentials to the application, and has no use during production.

Cool thank you I will get this implemented.

Reduced size to 61mb


ci: ignore ansible-lint error

upstream issues needs to be reported and fixed
see #118

@ereshetova I disabled ansible-lint because it raises errors that I don't understand, and I suspect there are some bugs that needs to be reported upstream.
You can merge this is that's ok for you.


[Bug Report] CommonJS bundle causes webpack to bundle duplicate copies of some components

Element UI version
2.3.9 and 2.4.0
OS/Browsers version
N/A
Vue version
2.5.16
Reproduction Link
https://github.com/ElementUI/element-starter
Steps to reproduce
(Note: This is not an issue with the webpack config in the starter repository - the code that's shipped in element-ui's NPM package already contains the duplicate code - see below for explanation)

Check out https://github.com/ElementUI/element-starter
(Optional) Run yarn upgrade to update to the latest Element-UI. It doesn't affect the outcome.
Run yarn run build
Open dist/vendor.js in a text editor and search for some text that should only appear once per component, e.g. componentName:"ElSelect"

What is Expected?
Only one instance of that text should be found
What is actually happening?
Two instances of the text are found. It's obvious that there are 2 copies of the source code for this module
From what I could tell when investigating this, the issue is that the compiled element-ui.common.js contains both the source code for ElSelect and also a require("element-ui/lib/select"), which causes the consuming application's webpack to include a 2nd copy of ElSelect. The source code is bundled into element-ui.common.js because src/index.js imports from '../packages/select/index.js' which webpack includes in the bundle, whereas other components such as packages/pagination/src/pagination.js import from  'element-ui/packages/select' which matches one of the "externals" given to Webpack, causing it to translate that import into a require.
I tested 2 solutions locally:

(1) Change build/bin/build-entry.js so that the imports in src/index.js are consistent with everywhere else, causing the Webpack externals to be respected and the component source to not be included in element-ui.common.js - this got rid of the duplicate code but increased my application's minified but non-gzipped bundle size by 64kB. I'm not sure why the bundle size increases.
(2) Change build/config.js to exclude components from the "externals", causing element-ui.common.js to not include any requires to components. This also removed the duplicate code and decreased my minified application bundle size by 80kB.

I haven't made either of these into a PR because (1) seems like it's more in the spirit of how webpack.common.js was intended to function, but a 64kB increase in bundle size is not good. And (2) seems like a hack that would break other bundles, and existing users' who directly import components e.g. from import ElSelect from 'element-ui/lib/select'.

@jikkai Might be something to look at.


Post release automated changes for core releases

Post release automated changes for azure-core-client

API change check
API changes are not detected in this pull request.


Working OCIS binary

The server command starts all extensions
It also fixes displaying the cause of service registration on micro failure.

 Here is an overview of what got changed by this pull request:

Complexity increasing per file
==============================
- pkg/micro/api/api.go  2

See the complete overview on Codacy

 Here is an overview of what got changed by this pull request:

Complexity increasing per file
==============================
- pkg/micro/api/api.go  2

See the complete overview on Codacy

@tboerger I think there is currently no way to disable micro internal logging, so this can be merged with this small annoyance:

 Here is an overview of what got changed by this pull request:

Complexity increasing per file
==============================
- pkg/micro/api/api.go  2

See the complete overview on Codacy

 Here is an overview of what got changed by this pull request:

Complexity increasing per file
==============================
- pkg/micro/api/api.go  2

See the complete overview on Codacy


WCT errors out on Firefox

With this:
Tests failed: Error thrown outside of test function: document.getElementById(...).create is not a function

Reading around seems there were a few old issues with Polymer's test-fixture not upgrading in time that used to cause this, but was apparently fixed ages ago. Similar issues with user elements using test-fixture, like simpla-admin.

I'm assuming you're talking about https://github.com/Polymer/web-component-tester/issues/505? Looked at the commit that fixed it, and looks like that commit was included in the 6.0.0 pre-release, which means 5.0/4.0 that we're using won't get it I'd say. I've gotten similar issues with .restore is not a function, usually re-running the tests in travis will help. Super annoying though.


Work with newer versions of Teensyduino

Newer versions of Teensyduino has SPI as one class not subclasses
Add second example - Optional but I had it on my machine to test using SPI1 instead of SPI

Thanks for the heads up, I'll look into it when I can.


Cannot clear "top" debug console

VS Code Insiders

run cluster sample
terminate all processes
clear console

Observe: nothing happens

switch to another debug console
clear console

Observe: console is cleared

@weinand good catch, thanks! I have verified this works now with the cluster example from here

works fine now.


Trigger workspace init event (floating)

Triggers workspace init event when moving a floating window to a new
workspace.
This is a follow up on #391 which didn't handle floating windows.

Thanks!


Add batch size to avoid rate limits

Avoid Route53 API rate limits when large changes occur in a cluster, using a batch size of 100 as per https://github.com/zalando-incubator/kubernetes-on-aws/pull/2266/files
Related: https://github.com/rancher/rancher/issues/28391

Note that this change will not expose the parameter in Rancher UI though. It will just make sure its set to a lower value when the chart is deployed. To expose in Rancher UI, we will need to change Rancher API https://github.com/rancher/types/blob/e1dd38de6b4a7dd4808b8de4d6d569ff71e2d8e2/apis/management.cattle.io/v3/globaldns_types.go#L54

I'd be happy to backport this for the v2.4.x branch and v2.3.x (chart v0.0.2) if desired.

Closing in favor of other PRs


(qbittorrent) Add support for 64-bit installer

fixes #587

Any reason for not using Get-RemoteFiles ?

Don't work with sourceforge urls

@majkinetor  basically just get the following exception if trying to use the Get-RemoteFiles helper:
Exception calling "DownloadFile" with "2" argument(s): "An exception occurred during a WebClient request."

https://gist.github.com/anonymous/606af1600f8672c76c49e66ea133871f/5835d1742938bf26c6b23d28b2721ee560cf5509

It works for me, see for example:

https://github.com/majkinetor/au-packages/blob/2b47f191dfc281e471a1f0ef59ab9a518015ab88/smplayer/update.ps1#L22
https://github.com/majkinetor/au-packages/blob/f5c41bc2bb862bf09c8e73020b6aef5c768b8ac7/plantuml/update.ps1#L17

not for me on the qbittorrent package, both with and without the -FileNameSkip parameter.

Get-RemoteFiles tries to deduce everything by itself. You need to help it with funky sites like this, as it provides parameters to override everything it does.
In this case, it can't deduce extension so it fails. I should probably handle this a bit better as it takes extension from URL and not the final file name but just adding FileType in Latest solves this issue.

ah, I see. I didn't think setting the FileType property would matter since it was the DownloadFile that failed.
Thanks alot.

Besides that, with suffix (_x32, _x64) you can reduce 6 more lines as you don't need to have replacement in chocolateyInstall.ps1.
chocolateyInstall should be generic with Get-RemoteFiles, only silent args are changed basically.

DownloadFile failed because of invalid file path to save to

Besides that, with suffix (_x32, _x64) you can reduce 6 more lines as you don't need to have replacement in chocolateyInstall.ps1

I know, but I have a preference of being explicit with which files to use.

I see, if you want to add 5 minutes to each package you make, fine by me.
This is my generic embeddable exe installer which always works without any changes except silentArgs.
$toolsDir      = Split-Path $MyInvocation.MyCommand.Definition
$embedded_path = if ((Get-ProcessorBits 64) -and $env:chocolateyForceX86 -ne 'true') {
         Write-Host "Installing 64 bit version"; gi "$toolsDir\*_x64.exe"
} else { Write-Host "Installing 32 bit version"; gi "$toolsDir\*_x32.exe" }

$packageArgs = @{
  packageName    = ''
  fileType       = $fileType
  file           = $embedded_path
  silentArgs     = '/S'
  validExitCodes = @(0, 1223)
}
Install-ChocolateyInstallPackage @packageArgs
rm $toolsDir\*.$fileType -ea 0


Missing gdb/lldb and static gdbserver for target arch

Prebuilt images missing debugging tools. Definitely it needs host gdb and/or lldb for target arch and target arch gdbserver.

Sorry, I'm not interesting in adding debugging tools, it's built for building static Rust programs not run/debug programs in it.


[Feature] Generate Visual Timeline

Initial work to solve for #166.
The code is based on https://github.com/nodejs/lts-schedule with some changes:

Focus on just 2 sections per release (active/security support)
Addition of a "today" line (idea comes from PHP)
Bring year-lines to front (same as PHP)
Changed colors (using https://flatuicolors.com/palette/defo)
Reduced margins, height, and width to better fit
Added titles for accessibility improvements (can be improved)

TODO:

[x] Pick start and end dates automatically
[ ] Work even if releases don't have a start date
[ ] Fix text labels
[ ] Add an image title at top so this can be embedded elsewhere
[ ] Add a label for the "Today" line (have a hover thing on SVG already)
[ ] Style releaseCycle depending on current status
[ ] Sort releases ~using the sortReleasesBy configuration~ as per convention

Previews are functional: https://deploy-preview-285--endoflife-date.netlify.app/centos, though I've enabled it only if we didn't already have an image configured.

Need opinion on how to handle differing color meanings:
We currently use Green/Red/Orange to denote any dates (in the table) as being "Safe/Danger/Warning". So if an EoL date is within a few months, it changes color to Orange.

However, now we have 2 bars for "active/security" support of every release cycle. Currently, I'm using green/orange, but it needs to be shown better. Perhaps different shades of green?
This is current:

Something like this perhaps?

Tried to keep the shades far apart for accessibility, and it seems to work?

You should probably match the colors with what's in the table

Matching is difficult, but you're right - it is awkward if they do not match. I do have some ideas:

splitting the green in table to match the dual green above for one). So the 2 shades of green mean exactly the same thing
Similarly using 2 shades of red for Active/Security support in the table and above. This might make reading the chart harder though?

The yellow we use is difficult since it only shows up around the today line. Maybe we could do this on hover (green changes to yelow if date is approaching soon)?
Will post some options here.

https://www.php.net/supported-versions.php uses:

red: EOL
orange: security only
green: active support

https://nodejs.org/en/about/releases/ uses:

orange: unstable
grey: maintenance
blue: active
green: current

https://python-release-cycle.glitch.me/ (and its derivatives https://jefftriplett.com/django-release-cycle/ and https://hugovk.github.io/drupal-release-cycle/) is similar to PHP and uses:

red: dead/EOL
orange: security
green: bugfix
blue: prerelease

Oh and in general, the charts in this PR are looking good!
I noticed some have newer versions at the top, can they be re-ordered so newer versions are at the bottom, like the other websites tend to have?

https://deploy-preview-285--endoflife-date.netlify.app/bootstrap
https://deploy-preview-285--endoflife-date.netlify.app/python

Some do have newer versions at the bottom:

https://deploy-preview-285--endoflife-date.netlify.app/centos

Ordering is currently based on the sequence in the markdown file. I plan to take sortReleasesBy into account so it's consistent with the tables below.

Need suggestions on how to showcase releases that are currently supported, but end dates are not currently known. I had two ideas:
For products where we know approximate release dates (such as Fedora, where releases will likely last for 13 months) - perhaps we could put a date for eol, but mark it as "approximate: true" and that gets a special shading in the timeline.
Another would be to keep it automatically extended to the next month (or 3 months) with the same shading and text stating: "EoL dates are not known in advance".

The first impression is really good, you are on the right direction. :+1:
I'll do a full review when you have completed all points in the TODO list. Let me know...

@captn3m0 what is the result of this PR ? is there any improvements ?
If this one not done yet , we could add this project/idea to Hacktoberfest ideas.
[ Another thing (not related to this PR : The links about ideas in Hacktoberfest part is not working in :
Click through the following issues to read more.
    Autofocus to search input
    Hide old releases by default
    Add Product Logo in the sidebar

]

Planning to pick this (and the dependabot automation bits) for my hacktoberfest.

WIP Release Image samples
Easier to browse everything in a single place. This comment hotlinks to the deploy website, so will hopefully auto-update on future builds.
Click to Expand

Great progress!
Some are a bit packed, this is the most extreme :)

Don't see a way to fix, so will probably just disable timeline for that page.

Some of products names are cropped :

Would love to see this feature on endoflife.date.
An alternative solution that may be lighter to implement would be to use https://developers.google.com/chart/interactive/docs/gallery/timeline#an-advanced-example. I think it's lighter because:

it does not require to generate images using a python script during the build,
it's just templating.

But it has one drawback : it is not allowed per the Google agreements to embed it. This mean we would have to use the version hosted on Google CDNs (=> privacy concerns).

Let me rework this PR, and I can attempt a variant with Google Charts as well. I don't want to link to Google Charts if at all possible, so maybe we can do offline builds using it instead.

We now have one for Python at https://devguide.python.org/versions/
We started off using Mermaid.js to create one like this: https://github.com/python/devguide/pull/988
At build time we generated a Mermaid .mmd file, and the site loaded the JS which then read the mmd data and rendered it as an SVG.
We've since updated it to generate the SVG directly, using templating, at build time: https://github.com/python/devguide/pull/1034
This means we don't need to load a large JavaScript library, the SVG is available immediately, and the SVG is more responsive.

Let me rework this PR, and I can attempt a variant with Google Charts as well. I don't want to link to Google Charts if at all possible, so maybe we can do offline builds using it instead.

Sure, I just mentioned Google Chart to not forget about it should we need another solution.

We started off using Mermaid.js to create one like this: python/devguide#988

I also tried Mermaid with endoflife.date data but was not convinced by the result.

We've since updated it to generate the SVG directly, using templating, at build time: python/devguide#1034

It is a better alternative than Google Charts, even if it may be more difficult to implement at first, IMHO. Not sure it is that simple, but we could port the template to liquid.


Duplex stream

Hi,
Is it possible to have a duplex stream? A typical use case is sharing a stream and having one side reading from it, while the other is writing to it. Quite similar to Golang's channels.

Yes, you can just implement both interfaces. That's what Socket does in amphp/socket.
Do you want a class that collects all writes and spits those out to the reader again?

I'm going to close this for now. We don't see a need for a combined interface currently.


Create guide docs about specify message come from

Hey! i'll be adding this in the group page soon, thanks for your contribution though


NOISSUE - Trim trailing and leading whitespaces in email at login & register

Signed-off-by: Arvindh<EMAIL_ADDRESS>What does this do?
Trim trailing and leading whitespace in an email at login & register.
Which issue(s) does this PR fix/relate to?
There is no such issue.
List any changes that modify/break current functionality
N/A
Have you included tests for your changes?
N/A
Did you document any new/modified functionality?
N/A
Notes
N/A

Codecov Report

Merging #1687 (ce16a7e) into master (f438d24) will increase coverage by 0.00%.
The diff coverage is 75.00%.

@@           Coverage Diff           @@
##           master    #1687   +/-   ##
=======================================
  Coverage   70.26%   70.26%
=======================================
  Files         148      148
  Lines       11501    11509    +8
=======================================
+ Hits         8081     8087    +6
- Misses       2756     2758    +2
  Partials      664      664

Impacted Files
Coverage Δ

users/users.go
75.60% <0.00%> (-3.88%)
:arrow_down:

users/api/endpoint.go
46.30% <100.00%> (+0.73%)
:arrow_up:

users/api/requests.go
42.42% <100.00%> (+3.71%)
:arrow_up:

:mega: We’re building smart automated test selection to slash your CI/CD build times. Learn more