Add webcam support for mac

Add support for MacOS webcams to the new Hardware Devices view.

NOTE:
Needs testing on Windows and Linux in case the installation of pyobjc breaks things there

Builds in non Mac systems fail, try dynamically installing the pyobjc library?
``import pip
def install(package):
if hasattr(pip, 'main'):
pip.main(['install', package])
else:
pip._internal.main(['install', package])
Example
if name == 'main':
install('argh') ``


Bottom toolbar has low readability in light themes

The bottom toolbar has very low readability in both light themes.
Light:

Ash:

For reference, this is how it looks like in Dark:

Oh that's not good. Thanks for reporting it!

The new version I just published (0.7) fixes this issue and comes with a few other improvements to the readability and colorization of light themes.


build(deps): bump github.com/influxdata/flux

bump github.com/influxdata/flux from v0.171.0 to v0.191.0
Fixes #2769
There are also newer releases that could be used: https://github.com/influxdata/flux/releases
Required checklist

[ ] Sample config files updated (both /etc folder and NewDemoConfig methods) (influxdb and plutonium)
[ ] openapi swagger.yml updated (if modified API) - link openapi PR
[ ] Signed CLA (if not already signed)

Description
1-3 sentences describing the PR (or link to well written issue)
Context
Why was this added? What value does it add? What are risks/best practices?
Affected areas (if applicable):
List of user-visible changes. As a user, what would I need to see in docs?
Examples:
CLI commands, subcommands, and flags
API changes
Configuration (sample config blocks)
Severity (optional)
i.e., ("recommend to upgrade immediately", "upgrade at your leasure", etc.)
Note for reviewers:
Check the semantic commit type:

Feat: a feature with user-visible changes
Fix: a bug fix that we might tell a user “upgrade to get this fix for your issue”
Chore: version bumps, internal doc (e.g. README) changes, code comment updates, code formatting fixes… must not be user facing (except dependency version changes)
Build: build script changes, CI config changes, build tool updates
Refactor: non-user-visible refactoring
Check the PR title: we should be able to put this as a one-liner in the release notes

@stefanb maybe let's try including this patch and upgrading kapacitor to 1.7.1 on the homebrew side? what do you think?

Not sure, the CI didn't pass here.

fix pr, https://github.com/influxdata/kapacitor/pull/2811


Segmentation fault

I have been processing a file which is 81GB of newline-delimited JSON. I have processed it a couple of times successfully on this machine. Just now I changed the parameters slightly:
tippecanoe --output=mbtiles/parcels.mbtiles --force --read-parallel --minimum-zoom=13 --maximum-zoom=15 --generate-ids --simplification=10 --detect-shared-borders --simplify-only-low-zooms --attribute-type='ATTOM ID:int' --include='ATTOM ID' --include=APN --include=CountyFIPS --coalesce-smallest-as-needed --base-zoom=14 --accumulate-attribute=APN:comma --accumulate-attribute='ATTOM ID:comma' --layer=parcels data/parcels.json

and got a seg fault:
...
Going to try keeping the biggest 19.34% of the features to make it fit
tile 13/2352/3121 size is 502684 with detail 12, >500000
Going to try keeping the biggest 17.31% of the features to make it fit
Segmentation fault (core dumped)

Now, following this I'll try running it again to actually get the core dump, which seems to not be written by default.
The changes between "worked" and "crashed" are:
// worked:
                    minimumZoom: 13,
                    maximumZoom: 15,
                    generateIds: true,
                    simplification:10,
                    filename: `${options.datapath}/parcels${options.suffix}.json`,
                    detectSharedBorders: true,
                    dropSmallestAsNeeded: true,
                    simplifyOnlyLowZooms: true,
                    attributeType: 'ATTOM ID:int',
                    include: ['ATTOM ID', 'APN','CountyFIPS'],

// crashed (all the above, plus these:)
                    dropSmallestAsNeeded: false,
                    coalesceSmallestAsNeeded: true,
                    baseZoom: 14,
                    accumulateAttribute: ['APN:comma', 'ATTOM ID:comma'],

Somewhere in the log I also noticed there was one tile that tippecanoe couldn't make small enough. What does it actually do in that situation? Previously I thought I had seen it abort altogether.
I have also managed to process a subset of this dataset successfully, with these exact settings.
I'm not sure how to share the source file with you, given its size. Any ideas?
tippecanoe v1.32.12

Slightly different output but still crashed:
Going to try keeping the biggest 17.31% of the features to make it fit
Segmentation fault080

@stevage thanks for reporting and helping narrow this down. Getting a backtrace out of the core dump would be ideal, since it should show where the crash is happening. That way we might be able to fix without replicating.
https://jvns.ca/blog/2018/04/28/debugging-a-segfault-on-linux/ looks good, but skip the valgrind step since that will slow down the program so much it might not be tenable. Also, you could use https://github.com/mapbox/logbt which does all the things in that blog post automatically.

Ah, great. Ok, I'm trying the logbt option.
$ ~/logbt/logbt -- ./4-make-tiles.js parcels
[logbt] using corefile location: /tmp/logbt-coredumps
[logbt] using core_pattern: core.%p.%E
4: Generating vector tiles
tippecanoe --output=mbtiles/parcels.mbtiles --force --read-parallel --minimum-zoom=13 --maximum-zoom=15 --generate-ids --simplification=10 --simplify-only-low-zooms --attribute-type='ATTOM ID:int' --include='ATTOM ID' --include=APN --include=CountyFIPS --coalesce-smallest-as-needed --base-zoom=14 --accumulate-attribute=APN:comma --accumulate-attribute='ATTOM ID:comma' --layer=parcels data/parcels.json
Read 1.64 million features

Ok, I have emailed you the dump.

Ok, finally got there.
Going to try keeping the biggest 20.25% of the features to make it fit
Segmentation fault (core dumped)
Tiles for parcels:parcels failed in 4.02 h.
[logbt] saw './4-make-tiles.js' exit with code:139 (SEGV)
[logbt] Found corefile (non-tracked) at /tmp/logbt-coredumps/core.28612.!home!steve_bennett_cherre_com!tippecanoe!tippecanoe
[logbt] Processing cores...
[New LWP 30669]
[New LWP 30671]
[New LWP 30670]
[New LWP 30675]
[New LWP 30672]
[New LWP 30676]
[New LWP 30673]
[New LWP 30674]
[New LWP 28612]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Core was generated by `tippecanoe --output=mbtiles/parcels.mbtiles --force --read-parallel --minimum-z'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  deserialize_ulong_long (zigzag=<synthetic pointer>, f=<synthetic pointer>) at serial.cpp:97
97                      if ((**f & 0x80) == 0) {
[Current thread is 1 (Thread 0x7fc3a6d8a700 (LWP 30669))]

Thread 9 (Thread 0x7fc479cdbb80 (LWP 28612)):
#0  0x00007fc479386d2d in __GI___pthread_timedjoin_ex (threadid=140478294566656, thread_return=thread_return@entry=0x7ffe69de6bd8, abstime=abstime@entry=0x0, block=block@entry=true) at pthread_join_common.c:89
#1  0x00007fc479386b5c in __pthread_join (threadid=<optimized out>, thread_return=thread_return@entry=0x7ffe69de6bd8) at pthread_join.c:24
#2  0x00005645c7c7a394 in traverse_zooms (geomfd=<optimized out>, geom_size=<optimized out>, metabase=<optimized out>, stringpool=<optimized out>, midx=<optimized out>, midy=<optimized out>, maxzoom=<optimized out>, minzoom=<optimized out>, outdb=<optimized out>, outdir=<optimized out>, buffer=<optimized out>, fname=<optimized out>, tmpdir=<optimized out>, gamma=<optimized out>, full_detail=<optimized out>, low_detail=<optimized out>, min_detail=<optimized out>, meta_off=<optimized out>, pool_off=<optimized out>, initial_x=<optimized out>, initial_y=<optimized out>, simplification=<optimized out>, layermaps=..., prefilter=<optimized out>, postfilter=<optimized out>, attribute_accum=<optimized out>, filter=<optimized out>) at tile.cpp:2857
#3  0x00005645c7cdf1f4 in read_input (sources=..., fname=<optimized out>, maxzoom=<optimized out>, minzoom=<optimized out>, basezoom=<optimized out>, basezoom_marker_width=<optimized out>, outdb=<optimized out>, outdir=<optimized out>, exclude=<optimized out>, include=<optimized out>, exclude_all=<optimized out>, filter=<optimized out>, droprate=<optimized out>, buffer=<optimized out>, tmpdir=<optimized out>, gamma=<optimized out>, read_parallel=<optimized out>, forcetable=<optimized out>, attribution=<optimized out>, uses_gamma=<optimized out>, file_bbox=<optimized out>, prefilter=<optimized out>, postfilter=<optimized out>, description=<optimized out>, guess_maxzoom=<optimized out>, attribute_types=<optimized out>, pgm=<optimized out>, attribute_accum=<optimized out>, attribute_descriptions=..., commandline=...) at main.cpp:2270
#4  0x00005645c7c6aa1e in main (argc=<optimized out>, argv=0x7ffe69de8de8) at main.cpp:3183

Thread 8 (Thread 0x7fc3a858d700 (LWP 30674)):
#0  0x00007fc4798a9050 in ?? () from /lib/x86_64-linux-gnu/libz.so.1
#1  0x00007fc4798aaf98 in ?? () from /lib/x86_64-linux-gnu/libz.so.1
#2  0x00007fc4798ac1ed in deflate () from /lib/x86_64-linux-gnu/libz.so.1
#3  0x00005645c7ccae78 in compress (input="\032\357\333\027x\002\n\aparcels(\200 \032\nCountyFIPS\032\bATTOM ID\032\003APN\"\a\n\005\061\067\060\063\061\"\324\003\n\321\003\061\067\065\063\071\067\071\071\070,175398001,38953317,175397945,175397946,175394271,175403029,176078222,175908302,155105428,39004835,174897369,174897370,174897371,49"..., output="\037\213\b\000\000\000\000\000\002\003l\275}\350\377\313r\037\304\071\347\236s\356\375\334$7\017m-\027J\313\347/ů\272\063\263\217\224\326\304\346\201H\215\001\373O\251\bR\202\265\212\212\017\324\374W\255\210P\020\305H\244 b\251\004\n\202i\323H\203QӦ-\242\064\066\372\207R\005\021\"\221j[\251\264\330bug\037f\367\065\357{\370q\276\063\237\367>\314\316\356\316\316\316\316\316~\363\257\374ſ\343_\376\364\365\345?\367\217\377\363\277\373\307\376\351\177\341\357\374\375\277雯\337\366\317\376K\377̿\370\343?\370\303?\372\217|\363\253\337\367;~\307?\374\017\375\246\037\376\376o~\366}?\372#\357/_\237S\tB"...) at mvt.cpp:100
#4  0x00005645c7c83e27 in write_tile (geoms=geoms@entry=0x7fb02800fb70, geompos_in=geompos_in@entry=0x7fc3a858ceb0, metabase=<optimized out>, stringpool=<optimized out>, z=<optimized out>, tx=<optimized out>, ty=<optimized out>, detail=<optimized out>, min_detail=<optimized out>, outdb=<optimized out>, outdir=<optimized out>, buffer=<optimized out>, fname=<optimized out>, geomfile=<optimized out>, minzoom=<optimized out>, maxzoom=<optimized out>, todo=<optimized out>, along=<optimized out>, alongminus=<optimized out>, gamma=<optimized out>, child_shards=<optimized out>, meta_off=<optimized out>, pool_off=<optimized out>, initial_x=<optimized out>, initial_y=<optimized out>, running=<optimized out>, simplification=<optimized out>, layermaps=<optimized out>, layer_unmaps=<optimized out>, tiling_seg=<optimized out>, pass=<optimized out>, passes=<optimized out>, mingap=<optimized out>, minextent=<optimized out>, fraction=<optimized out>, prefilter=<optimized out>, postfilter=<optimized out>, filter=<optimized out>, arg=<optimized out>) at tile.cpp:2422
#5  0x00005645c7c86046 in run_thread (vargs=0x5645c8dc9cb0) at tile.cpp:2585
#6  0x00007fc4793856db in start_thread (arg=0x7fc3a858d700) at pthread_create.c:463
#7  0x00007fc47876f88f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Thread 7 (Thread 0x7fc3a8d8e700 (LWP 30673)):
#0  0x00007fc4786e520a in tcache_get (tc_idx=28) at malloc.c:2943
#1  __GI___libc_malloc (bytes=464) at malloc.c:3050
#2  0x00007fc479088258 in operator new(unsigned long) () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#3  0x00005645c7c86ecb in __gnu_cxx::new_allocator<draw>::allocate (this=0x7fb034537148, __n=29) at /usr/include/c++/7/ext/new_allocator.h:111
#4  std::allocator_traits<std::allocator<draw> >::allocate (__a=..., __n=29) at /usr/include/c++/7/bits/alloc_traits.h:436
#5  std::_Vector_base<draw, std::allocator<draw> >::_M_allocate (this=0x7fb034537148, __n=29) at /usr/include/c++/7/bits/stl_vector.h:172
#6  std::_Vector_base<draw, std::allocator<draw> >::_M_create_storage (__n=<optimized out>, this=0x7fb034537148) at /usr/include/c++/7/bits/stl_vector.h:187
#7  std::_Vector_base<draw, std::allocator<draw> >::_Vector_base (__a=..., __n=<optimized out>, this=0x7fb034537148) at /usr/include/c++/7/bits/stl_vector.h:138
#8  std::vector<draw, std::allocator<draw> >::vector (this=0x7fb034537148, __x=std::vector of length 29, capacity 29 = {...}) at /usr/include/c++/7/bits/stl_vector.h:328
#9  0x00005645c7c8d7b8 in coalesce::coalesce (this=0x7fb0345370e0) at tile.cpp:84
#10 0x00005645c7c8205c in __gnu_cxx::new_allocator<coalesce>::construct<coalesce, coalesce const&> (this=0x7fb034007000, __p=<optimized out>) at /usr/include/c++/7/ext/new_allocator.h:136
#11 std::allocator_traits<std::allocator<coalesce> >::construct<coalesce, coalesce const&> (__a=..., __p=<optimized out>) at /usr/include/c++/7/bits/alloc_traits.h:475
#12 std::vector<coalesce, std::allocator<coalesce> >::push_back (__x=..., this=0x7fb034007000) at /usr/include/c++/7/bits/stl_vector.h:943
#13 write_tile (geoms=geoms@entry=0x7fb0341fb4a0, geompos_in=geompos_in@entry=0x7fc3a8d8deb0, metabase=<optimized out>, stringpool=<optimized out>, z=<optimized out>, tx=<optimized out>, ty=<optimized out>, detail=<optimized out>, min_detail=<optimized out>, outdb=<optimized out>, outdir=<optimized out>, buffer=<optimized out>, fname=<optimized out>, geomfile=<optimized out>, minzoom=<optimized out>, maxzoom=<optimized out>, todo=<optimized out>, along=<optimized out>, alongminus=<optimized out>, gamma=<optimized out>, child_shards=<optimized out>, meta_off=<optimized out>, pool_off=<optimized out>, initial_x=<optimized out>, initial_y=<optimized out>, running=<optimized out>, simplification=<optimized out>, layermaps=<optimized out>, layer_unmaps=<optimized out>, tiling_seg=<optimized out>, pass=<optimized out>, passes=<optimized out>, mingap=<optimized out>, minextent=<optimized out>, fraction=<optimized out>, prefilter=<optimized out>, postfilter=<optimized out>, filter=<optimized out>, arg=<optimized out>) at tile.cpp:2169
#14 0x00005645c7c86046 in run_thread (vargs=0x5645c8dc9b50) at tile.cpp:2585
#15 0x00007fc4793856db in start_thread (arg=0x7fc3a8d8e700) at pthread_create.c:463
#16 0x00007fc47876f88f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Thread 6 (Thread 0x7fc3a5d88700 (LWP 30676)):
#0  0x00005645c7cb745e in std::__adjacent_find<__gnu_cxx::__normal_iterator<long long*, std::vector<long long, std::allocator<long long> > >, __gnu_cxx::__ops::_Iter_equal_to_iter> (__last=..., __first=63, __binary_pred=...) at /usr/include/c++/7/bits/stl_algo.h:953
#1  std::__unique<__gnu_cxx::__normal_iterator<long long*, std::vector<long long, std::allocator<long long> > >, __gnu_cxx::__ops::_Iter_equal_to_iter> (__binary_pred=..., __last=681, __first=31) at /usr/include/c++/7/bits/stl_algo.h:966
#2  std::unique<__gnu_cxx::__normal_iterator<long long*, std::vector<long long, std::allocator<long long> > > > (__last=..., __first=...) at /usr/include/c++/7/bits/stl_algo.h:1005
#3  mapbox::geometry::wagyu::pop_from_scanbeam<long long> (Y=@0x7fc3a5d86cc0: 668, scanbeam=std::vector of length 74, capacity 256 = {...}) at ./mapbox/geometry/wagyu/scanbeam.hpp:21
#4  0x00005645c7cbdeb2 in mapbox::geometry::wagyu::build_hot_pixels<long long> (minima_list=std::deque with 156 elements = {...}, manager=...) at ./mapbox/geometry/wagyu/snap_rounding.hpp:181
#5  0x00005645c7ca3c5b in mapbox::geometry::wagyu::wagyu<long long>::execute<long long> (clip_fill_type=mapbox::geometry::wagyu::fill_type_positive, subject_fill_type=mapbox::geometry::wagyu::fill_type_positive, solution=..., cliptype=mapbox::geometry::wagyu::clip_type_union, this=0x7fc3a5d86e20) at ./mapbox/geometry/wagyu/wagyu.hpp:128
#6  clean_or_clip_poly (geom=std::vector of length 791, capacity 1024 = {...}, z=z@entry=0, buffer=buffer@entry=0, clip=clip@entry=false) at geometry.cpp:272
#7  0x00005645c7c7658c in partial_feature_worker (v=0x7fb01c0a84f0) at tile.cpp:501
#8  0x00005645c7c844ee in write_tile (geoms=geoms@entry=0x7fb01c03a2e0, geompos_in=geompos_in@entry=0x7fc3a5d87eb0, metabase=<optimized out>, stringpool=<optimized out>, z=<optimized out>, tx=<optimized out>, ty=<optimized out>, detail=<optimized out>, min_detail=<optimized out>, outdb=<optimized out>, outdir=<optimized out>, buffer=<optimized out>, fname=<optimized out>, geomfile=<optimized out>, minzoom=<optimized out>, maxzoom=<optimized out>, todo=<optimized out>, along=<optimized out>, alongminus=<optimized out>, gamma=<optimized out>, child_shards=<optimized out>, meta_off=<optimized out>, pool_off=<optimized out>, initial_x=<optimized out>, initial_y=<optimized out>, running=<optimized out>, simplification=<optimized out>, layermaps=<optimized out>, layer_unmaps=<optimized out>, tiling_seg=<optimized out>, pass=<optimized out>, passes=<optimized out>, mingap=<optimized out>, minextent=<optimized out>, fraction=<optimized out>, prefilter=<optimized out>, postfilter=<optimized out>, filter=<optimized out>, arg=<optimized out>) at tile.cpp:2115
#9  0x00005645c7c86046 in run_thread (vargs=0x5645c8dc9f70) at tile.cpp:2585
#10 0x00007fc4793856db in start_thread (arg=0x7fc3a5d88700) at pthread_create.c:463
#11 0x00007fc47876f88f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Thread 5 (Thread 0x7fc3a958f700 (LWP 30672)):
#0  0x00005645c7caf95a in mapbox::geometry::wagyu::round_towards_min<long long> (val=1132.8500000000211) at ./mapbox/geometry/wagyu/ring_util.hpp:91
#1  mapbox::geometry::wagyu::get_edge_min_x<long long> (current_y=2974, edge=...) at ./mapbox/geometry/wagyu/ring_util.hpp:126
#2  mapbox::geometry::wagyu::hot_pixel_set_left_to_right<long long> (add_end_point=false, end=<synthetic pointer>{x = 954, y = 3299}, itr=Python Exception <class 'gdb.error'> value has been optimized out:
<synthetic pointer>, rings=..., bnd=..., end_x=1154, start_x=731, y=2974) at ./mapbox/geometry/wagyu/ring_util.hpp:171
#3  mapbox::geometry::wagyu::insert_hot_pixels_in_path<long long> (bnd=..., end_pt=..., rings=..., add_end_point=add_end_point@entry=false) at ./mapbox/geometry/wagyu/ring_util.hpp:296
#4  0x00005645c7cafc74 in mapbox::geometry::wagyu::add_point_to_ring<long long> (bnd=..., pt=..., rings=...) at ./mapbox/geometry/wagyu/ring_util.hpp:327
#5  0x00005645c7cbe985 in mapbox::geometry::wagyu::add_point<long long> (bnd=..., active_bounds=std::vector of length 2, capacity 4 = {...}, pt=..., rings=...) at ./mapbox/geometry/wagyu/ring_util.hpp:352
#6  0x00005645c7cbebb8 in mapbox::geometry::wagyu::add_local_maximum_point<long long> (b1=..., b2=..., pt=..., rings=..., active_bounds=std::vector of length 2, capacity 4 = {...}) at ./mapbox/geometry/wagyu/ring_util.hpp:623
#7  0x00005645c7cc0c7c in mapbox::geometry::wagyu::do_maxima<long long> (active_bounds=std::vector of length 2, capacity 4 = {...}, manager=..., clip_fill_type=mapbox::geometry::wagyu::fill_type_positive, subject_fill_type=mapbox::geometry::wagyu::fill_type_positive, cliptype=mapbox::geometry::wagyu::clip_type_union, bndMaxPair=Python Exception <class 'gdb.error'> value has been optimized out:
<synthetic pointer>, bnd=0x7fb02c01d920) at ./mapbox/geometry/wagyu/process_maxima.hpp:44
#8  mapbox::geometry::wagyu::process_edges_at_top_of_scanbeam<long long> (top_y=<optimized out>, active_bounds=std::vector of length 2, capacity 4 = {...}, scanbeam=std::vector of length 0, capacity 8, minima_sorted=std::vector of length 4, capacity 4 = {...}, current_lm=0xc040b33333333333, manager=..., cliptype=mapbox::geometry::wagyu::clip_type_union, subject_fill_type=mapbox::geometry::wagyu::fill_type_positive, clip_fill_type=mapbox::geometry::wagyu::fill_type_positive) at ./mapbox/geometry/wagyu/process_maxima.hpp:84
#9  0x00005645c7cc1016 in mapbox::geometry::wagyu::execute_vatti<long long> (minima_list=std::deque with 4 elements = {...}, manager=..., cliptype=cliptype@entry=mapbox::geometry::wagyu::clip_type_union, subject_fill_type=subject_fill_type@entry=mapbox::geometry::wagyu::fill_type_positive, clip_fill_type=clip_fill_type@entry=mapbox::geometry::wagyu::fill_type_positive) at ./mapbox/geometry/wagyu/vatti.hpp:53
#10 0x00005645c7ca3c7d in mapbox::geometry::wagyu::wagyu<long long>::execute<long long> (clip_fill_type=mapbox::geometry::wagyu::fill_type_positive, subject_fill_type=mapbox::geometry::wagyu::fill_type_positive, solution=..., cliptype=mapbox::geometry::wagyu::clip_type_union, this=0x7fc3a958de20) at ./mapbox/geometry/wagyu/wagyu.hpp:130
#11 clean_or_clip_poly (geom=std::vector of length 24, capacity 32 = {...}, z=z@entry=0, buffer=buffer@entry=0, clip=clip@entry=false) at geometry.cpp:272
#12 0x00005645c7c7658c in partial_feature_worker (v=0x7fb02c056b00) at tile.cpp:501
#13 0x00005645c7c844ee in write_tile (geoms=geoms@entry=0x7fb02c09b9c0, geompos_in=geompos_in@entry=0x7fc3a958eeb0, metabase=<optimized out>, stringpool=<optimized out>, z=<optimized out>, tx=<optimized out>, ty=<optimized out>, detail=<optimized out>, min_detail=<optimized out>, outdb=<optimized out>, outdir=<optimized out>, buffer=<optimized out>, fname=<optimized out>, geomfile=<optimized out>, minzoom=<optimized out>, maxzoom=<optimized out>, todo=<optimized out>, along=<optimized out>, alongminus=<optimized out>, gamma=<optimized out>, child_shards=<optimized out>, meta_off=<optimized out>, pool_off=<optimized out>, initial_x=<optimized out>, initial_y=<optimized out>, running=<optimized out>, simplification=<optimized out>, layermaps=<optimized out>, layer_unmaps=<optimized out>, tiling_seg=<optimized out>, pass=<optimized out>, passes=<optimized out>, mingap=<optimized out>, minextent=<optimized out>, fraction=<optimized out>, prefilter=<optimized out>, postfilter=<optimized out>, filter=<optimized out>, arg=<optimized out>) at tile.cpp:2115
#14 0x00005645c7c86046 in run_thread (vargs=0x5645c8dc99f0) at tile.cpp:2585
#15 0x00007fc4793856db in start_thread (arg=0x7fc3a958f700) at pthread_create.c:463
#16 0x00007fc47876f88f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Thread 4 (Thread 0x7fc3a6589700 (LWP 30675)):
#0  std::__move_merge_adaptive_backward<__gnu_cxx::__normal_iterator<mapbox::geometry::wagyu::local_minimum<long long>**, std::vector<mapbox::geometry::wagyu::local_minimum<long long>*, std::allocator<mapbox::geometry::wagyu::local_minimum<long long>*> > >, mapbox::geometry::wagyu::local_minimum<long long>**, __gnu_cxx::__normal_iterator<mapbox::geometry::wagyu::local_minimum<long long>**, std::vector<mapbox::geometry::wagyu::local_minimum<long long>*, std::allocator<mapbox::geometry::wagyu::local_minimum<long long>*> > >, __gnu_cxx::__ops::_Iter_comp_iter<mapbox::geometry::wagyu::local_minimum_sorter<long long> > > (__comp=..., __result=0x7fb03c9ece80, __last2=0x7fb03c3c61a0, __first2=0x7fb03c3c6190, __last1=0x7fb03c1bbf60, __first1=...) at /usr/include/c++/7/bits/stl_algo.h:2362
#1  std::__merge_adaptive<__gnu_cxx::__normal_iterator<mapbox::geometry::wagyu::local_minimum<long long>**, std::vector<mapbox::geometry::wagyu::local_minimum<long long>*, std::allocator<mapbox::geometry::wagyu::local_minimum<long long>*> > >, long, mapbox::geometry::wagyu::local_minimum<long long>**, __gnu_cxx::__ops::_Iter_comp_iter<mapbox::geometry::wagyu::local_minimum_sorter<long long> > > (__first=0x7fb03c3c5680, __middle=..., __last=0x7fb03c223610, __len1=<optimized out>, __len2=12, __buffer=0x7fb03c3c6190, __buffer_size=25, __comp=...) at /usr/include/c++/7/bits/stl_algo.h:2431
#2  0x00005645c7cb2add in std::__stable_sort_adaptive<__gnu_cxx::__normal_iterator<mapbox::geometry::wagyu::local_minimum<long long>**, std::vector<mapbox::geometry::wagyu::local_minimum<long long>*, std::allocator<mapbox::geometry::wagyu::local_minimum<long long>*> > >, mapbox::geometry::wagyu::local_minimum<long long>**, long, __gnu_cxx::__ops::_Iter_comp_iter<mapbox::geometry::wagyu::local_minimum_sorter<long long> > > (__first=0x7fb03c9ece80, __last=<error reading variable: Cannot access memory at address 0x770>, __last@entry=0x7fb03c223610, __buffer=__buffer@entry=0x7fb03c3c6190, __buffer_size=__buffer_size@entry=25, __comp=...) at /usr/include/c++/7/bits/stl_algo.h:2751
#3  0x00005645c7cc18a8 in std::__stable_sort<__gnu_cxx::__normal_iterator<mapbox::geometry::wagyu::local_minimum<long long>**, std::vector<mapbox::geometry::wagyu::local_minimum<long long>*, std::allocator<mapbox::geometry::wagyu::local_minimum<long long>*> > >, __gnu_cxx::__ops::_Iter_comp_iter<mapbox::geometry::wagyu::local_minimum_sorter<long long> > > (__comp=..., __last=..., __first=...) at /usr/include/c++/7/bits/stl_algo.h:5008
#4  std::stable_sort<__gnu_cxx::__normal_iterator<mapbox::geometry::wagyu::local_minimum<long long>**, std::vector<mapbox::geometry::wagyu::local_minimum<long long>*, std::allocator<mapbox::geometry::wagyu::local_minimum<long long>*> > >, mapbox::geometry::wagyu::local_minimum_sorter<long long> > (__last=..., __first=..., __comp=...) at /usr/include/c++/7/bits/stl_algo.h:5077
#5  mapbox::geometry::wagyu::execute_vatti<long long> (minima_list=std::deque with 25 elements = {...}, manager=..., cliptype=cliptype@entry=mapbox::geometry::wagyu::clip_type_union, subject_fill_type=subject_fill_type@entry=mapbox::geometry::wagyu::fill_type_positive, clip_fill_type=clip_fill_type@entry=mapbox::geometry::wagyu::fill_type_positive) at ./mapbox/geometry/wagyu/vatti.hpp:36
#6  0x00005645c7ca3c7d in mapbox::geometry::wagyu::wagyu<long long>::execute<long long> (clip_fill_type=mapbox::geometry::wagyu::fill_type_positive, subject_fill_type=mapbox::geometry::wagyu::fill_type_positive, solution=..., cliptype=mapbox::geometry::wagyu::clip_type_union, this=0x7fc3a6587e20) at ./mapbox/geometry/wagyu/wagyu.hpp:130
#7  clean_or_clip_poly (geom=std::vector of length 120, capacity 128 = {...}, z=z@entry=0, buffer=buffer@entry=0, clip=clip@entry=false) at geometry.cpp:272
#8  0x00005645c7c7658c in partial_feature_worker (v=0x7fb03d494b70) at tile.cpp:501
#9  0x00005645c7c844ee in write_tile (geoms=geoms@entry=0x7fb03c27c710, geompos_in=geompos_in@entry=0x7fc3a6588eb0, metabase=<optimized out>, stringpool=<optimized out>, z=<optimized out>, tx=<optimized out>, ty=<optimized out>, detail=<optimized out>, min_detail=<optimized out>, outdb=<optimized out>, outdir=<optimized out>, buffer=<optimized out>, fname=<optimized out>, geomfile=<optimized out>, minzoom=<optimized out>, maxzoom=<optimized out>, todo=<optimized out>, along=<optimized out>, alongminus=<optimized out>, gamma=<optimized out>, child_shards=<optimized out>, meta_off=<optimized out>, pool_off=<optimized out>, initial_x=<optimized out>, initial_y=<optimized out>, running=<optimized out>, simplification=<optimized out>, layermaps=<optimized out>, layer_unmaps=<optimized out>, tiling_seg=<optimized out>, pass=<optimized out>, passes=<optimized out>, mingap=<optimized out>, minextent=<optimized out>, fraction=<optimized out>, prefilter=<optimized out>, postfilter=<optimized out>, filter=<optimized out>, arg=<optimized out>) at tile.cpp:2115
#10 0x00005645c7c86046 in run_thread (vargs=0x5645c8dc9e10) at tile.cpp:2585
#11 0x00007fc4793856db in start_thread (arg=0x7fc3a6589700) at pthread_create.c:463
#12 0x00007fc47876f88f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Thread 3 (Thread 0x7fc3a758b700 (LWP 30670)):
#0  0x00007fc4798a907c in ?? () from /lib/x86_64-linux-gnu/libz.so.1
#1  0x00007fc4798aaf98 in ?? () from /lib/x86_64-linux-gnu/libz.so.1
#2  0x00007fc4798ac1ed in deflate () from /lib/x86_64-linux-gnu/libz.so.1
#3  0x00005645c7ccae78 in compress (input="\032\224\315\021x\002\n\aparcels(\200 \032\nCountyFIPS\032\bATTOM ID\032\003APN\"\a\n\005\064\070\063\067\065\"[\nY165089343,244128855,164887659,166242411,244128854,244569663,245221457,167882610,251930128\"\177\n}R065162012000,R065162011900,R065162045680,R065162"..., output="\037\213\b\000\000\000\000\000\002\003d\275K\250\377\301\222\330\005wfr\357=\367\225;w&\213\001\061\234\225\342Ytw\365s\031\024!\213h\320lĕ\210;Q\361\001\272\020EA\204\370\b\030P\f1&DF\006$\032\334J$\v%\276 00\340#F\207Ġ\213HF\023#\001\355\252\356\256\356\317?gq~]\337~W\277\252\252\253\252\177\345\017\376\267?\375g\277\363\361\335\177\342\037\372'\377\341\177\344\037\375\247\376\266\177\361w\376\312\307\337\371\217\377\063\377\330?\375\317\375ݿ\373\367\376\375\277\362\275\337\365\373~\337\337\373{~\347\357\376\273~\345\347~\327\357\375{>\277\373\361\v\271K+\237\377\340\307?\020k\t"...) at mvt.cpp:100
#4  0x00005645c7c83e27 in write_tile (geoms=geoms@entry=0x7fb0384ba820, geompos_in=geompos_in@entry=0x7fc3a758aeb0, metabase=<optimized out>, stringpool=<optimized out>, z=<optimized out>, tx=<optimized out>, ty=<optimized out>, detail=<optimized out>, min_detail=<optimized out>, outdb=<optimized out>, outdir=<optimized out>, buffer=<optimized out>, fname=<optimized out>, geomfile=<optimized out>, minzoom=<optimized out>, maxzoom=<optimized out>, todo=<optimized out>, along=<optimized out>, alongminus=<optimized out>, gamma=<optimized out>, child_shards=<optimized out>, meta_off=<optimized out>, pool_off=<optimized out>, initial_x=<optimized out>, initial_y=<optimized out>, running=<optimized out>, simplification=<optimized out>, layermaps=<optimized out>, layer_unmaps=<optimized out>, tiling_seg=<optimized out>, pass=<optimized out>, passes=<optimized out>, mingap=<optimized out>, minextent=<optimized out>, fraction=<optimized out>, prefilter=<optimized out>, postfilter=<optimized out>, filter=<optimized out>, arg=<optimized out>) at tile.cpp:2422
#5  0x00005645c7c86046 in run_thread (vargs=0x5645c8dc9730) at tile.cpp:2585
#6  0x00007fc4793856db in start_thread (arg=0x7fc3a758b700) at pthread_create.c:463
#7  0x00007fc47876f88f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Thread 2 (Thread 0x7fc3a7d8c700 (LWP 30671)):
#0  0x00007fc4786d5df2 in _IO_getc (fp=0x7fb0300737e0) at getc.c:39
#1  0x00005645c7cd3592 in deserialize_ulong_long_io (geompos=0x7fc3a7d8beb0, zigzag=<synthetic pointer>, f=0x7fb0300737e0) at serial.cpp:132
#2  deserialize_long_long_io (f=f@entry=0x7fb0300737e0, n=n@entry=0x7fc3a7d8aba0, geompos=geompos@entry=0x7fc3a7d8beb0) at serial.cpp:122
#3  0x00005645c7c9e4e8 in decode_geometry (meta=meta@entry=0x7fb0300737e0, geompos=geompos@entry=0x7fc3a7d8beb0, z=z@entry=13, tx=tx@entry=2401, ty=ty@entry=3076, bbox=0x7fc3a7d8afd8, initial_x=733864672, initial_y=1714676128) at geometry.cpp:51
#4  0x00005645c7cd4370 in deserialize_feature (geoms=0x7fb0300737e0, geompos_in=0x7fc3a7d8beb0, metabase=0x7fc477f7f000 <error: Cannot access memory at address 0x7fc477f7f000>, meta_off=0x7ffe69de6ff0, z=13, tx=2401, ty=3076, initial_x=0x7ffe69de7160, initial_y=0x7ffe69de7110) at serial.cpp:279
#5  0x00005645c7c76c0f in next_feature (geoms=geoms@entry=0x7fb0300737e0, geompos_in=geompos_in@entry=0x7fc3a7d8beb0, metabase=metabase@entry=0x7fc477f7f000 <error: Cannot access memory at address 0x7fc477f7f000>, meta_off=meta_off@entry=0x7ffe69de6ff0, z=z@entry=13, tx=<optimized out>, ty=<optimized out>, initial_x=<optimized out>, initial_y=<optimized out>, original_features=<optimized out>, unclipped_features=<optimized out>, nextzoom=<optimized out>, maxzoom=<optimized out>, minzoom=<optimized out>, max_zoom_increment=<optimized out>, pass=<optimized out>, passes=<optimized out>, along=<optimized out>, alongminus=<optimized out>, buffer=<optimized out>, within=<optimized out>, first_time=<optimized out>, geomfile=<optimized out>, geompos=<optimized out>, oprogress=<optimized out>, todo=todo@entry=12998412398, fname=<optimized out>, child_shards=<optimized out>, filter=<optimized out>, stringpool=<optimized out>, pool_off=<optimized out>, layer_unmaps=<optimized out>) at tile.cpp:1317
#6  0x00005645c7c80c8d in write_tile (geoms=geoms@entry=0x7fb0300737e0, geompos_in=geompos_in@entry=0x7fc3a7d8beb0, metabase=<optimized out>, stringpool=<optimized out>, z=<optimized out>, tx=<optimized out>, ty=<optimized out>, detail=<optimized out>, min_detail=<optimized out>, outdb=<optimized out>, outdir=<optimized out>, buffer=<optimized out>, fname=<optimized out>, geomfile=<optimized out>, minzoom=<optimized out>, maxzoom=<optimized out>, todo=<optimized out>, along=<optimized out>, alongminus=<optimized out>, gamma=<optimized out>, child_shards=<optimized out>, meta_off=<optimized out>, pool_off=<optimized out>, initial_x=<optimized out>, initial_y=<optimized out>, running=<optimized out>, simplification=<optimized out>, layermaps=<optimized out>, layer_unmaps=<optimized out>, tiling_seg=<optimized out>, pass=<optimized out>, passes=<optimized out>, mingap=<optimized out>, minextent=<optimized out>, fraction=<optimized out>, prefilter=<optimized out>, postfilter=<optimized out>, filter=<optimized out>, arg=<optimized out>) at tile.cpp:1861
#7  0x00005645c7c86046 in run_thread (vargs=0x5645c8dc9890) at tile.cpp:2585
#8  0x00007fc4793856db in start_thread (arg=0x7fc3a7d8c700) at pthread_create.c:463
#9  0x00007fc47876f88f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Thread 1 (Thread 0x7fc3a6d8a700 (LWP 30669)):
#0  deserialize_ulong_long (zigzag=<synthetic pointer>, f=<synthetic pointer>) at serial.cpp:97
#1  deserialize_long_long (n=<synthetic pointer>, f=<synthetic pointer>) at serial.cpp:88
#2  deserialize_feature (geoms=0x7fb024138d70, geompos_in=0x7fc3a6d89eb0, metabase=0x7fc477f7f000 <error: Cannot access memory at address 0x7fc477f7f000>, meta_off=0x7ffe69de6ff0, z=4294967249, tx=2197946775, ty=33667841, initial_x=0x7ffe69de7160, initial_y=0x7ffe69de7110) at serial.cpp:295
#3  0x00005645c7c76c0f in next_feature (geoms=geoms@entry=0x7fb024138d70, geompos_in=geompos_in@entry=0x7fc3a6d89eb0, metabase=metabase@entry=0x7fc477f7f000 <error: Cannot access memory at address 0x7fc477f7f000>, meta_off=meta_off@entry=0x7ffe69de6ff0, z=z@entry=-47, tx=<optimized out>, ty=<optimized out>, initial_x=<optimized out>, initial_y=<optimized out>, original_features=<optimized out>, unclipped_features=<optimized out>, nextzoom=<optimized out>, maxzoom=<optimized out>, minzoom=<optimized out>, max_zoom_increment=<optimized out>, pass=<optimized out>, passes=<optimized out>, along=<optimized out>, alongminus=<optimized out>, buffer=<optimized out>, within=<optimized out>, first_time=<optimized out>, geomfile=<optimized out>, geompos=<optimized out>, oprogress=<optimized out>, todo=todo@entry=12998412398, fname=<optimized out>, child_shards=<optimized out>, filter=<optimized out>, stringpool=<optimized out>, pool_off=<optimized out>, layer_unmaps=<optimized out>) at tile.cpp:1317
#4  0x00005645c7c80c8d in write_tile (geoms=geoms@entry=0x7fb024138d70, geompos_in=geompos_in@entry=0x7fc3a6d89eb0, metabase=<optimized out>, stringpool=<optimized out>, z=<optimized out>, tx=<optimized out>, ty=<optimized out>, detail=<optimized out>, min_detail=<optimized out>, outdb=<optimized out>, outdir=<optimized out>, buffer=<optimized out>, fname=<optimized out>, geomfile=<optimized out>, minzoom=<optimized out>, maxzoom=<optimized out>, todo=<optimized out>, along=<optimized out>, alongminus=<optimized out>, gamma=<optimized out>, child_shards=<optimized out>, meta_off=<optimized out>, pool_off=<optimized out>, initial_x=<optimized out>, initial_y=<optimized out>, running=<optimized out>, simplification=<optimized out>, layermaps=<optimized out>, layer_unmaps=<optimized out>, tiling_seg=<optimized out>, pass=<optimized out>, passes=<optimized out>, mingap=<optimized out>, minextent=<optimized out>, fraction=<optimized out>, prefilter=<optimized out>, postfilter=<optimized out>, filter=<optimized out>, arg=<optimized out>) at tile.cpp:1861
#5  0x00005645c7c86046 in run_thread (vargs=0x5645c8dc95d0) at tile.cpp:2585
#6  0x00007fc4793856db in start_thread (arg=0x7fc3a6d8a700) at pthread_create.c:463
#7  0x00007fc47876f88f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
s

Thanks @stevage - this is the key line that appears to be causing the segfault:

deserialize_ulong_long (zigzag=, f=) at serial.cpp:97

@ericfischer any idea how to fix this?

I'd also be interested to hear any possible workarounds.

Thanks. This must be indexing off the end of the buffer that encodes a variable-length number, either because it was encoded wrong in the first place, or because the metadata pointer is pointing to the wrong place.
I wish I had a workaround to offer immediately, but it looks like it's not as easy as I thought to substitute a different representation for serialized numbers. I'll keep investigating.

The workaround seems to be to insert inline_meta = true before this check:
https://github.com/mapbox/tippecanoe/blob/ddb79937d932f753edd5fba994b23281ff45f19c/serial.cpp#L654
but I'm still not sure what is causing the externalized metadata to be misencoded.

Is there anything more I can do to help?

OIC. I'll try patching that and see if it prevents the crash.
Sorry for the dumb question, but will there be side-effects from that change? I'm not really sure what "externalized metadata" is.

Sorry to be unclear. The "separate metadata" file is basically a holdover from an older version of Tippecanoe in which most of the characteristics of a feature were stored in a separate file so they wouldn't have to be duplicated across temporary files when a feature was clipped into many sub-features in different tiles. I gradually moved more and more things into the "geometry" file, so all it has in it now is a table of indices of key/value attribute pairs into the attribute pool, and is only populated when a feature is expected to span a large number of tiles.
I should probably just get rid of it, since it doesn't seem to work reliably and is another thing that has to be handled as a special case when it exists.

Could you please try https://github.com/mapbox/tippecanoe/pull/845 and see if it fixes the problem for you?

It crashed as before:
Going to try keeping the biggest 20.25% of the features to make it fit
Segmentation fault073035818/2695646785
Tiles for parcels:parcels failed in 4.14 h.

I forgot to use logbt, so will do that now.

Hmm, so much for that idea. Any chance you could share your data file so I can try to reproduce the exact circumstances?

Trying to find a way to do that. It's 81GB uncompressed, and also subject to licensing rules which I'm trying to get clarity on.
In the meantime, here's logbt:
mfile=0x7fff97437b60, fname=0x7fff9743bfda "mbtiles/parcels.mbtiles", t=<optimized out>, layer=<optimized out>, feature_minzoom=<optimized out>, child_shards=<optimized out>, max_zoom_increment=<optimized out>, seq=0, tippecanoe_minzoom=<optimized out>, tippecanoe_maxzoom=<optimized out>, segment=<optimized out>, initial_x=0x7fff97438240, initial_y=0x7fff974381f0, metakeys=std::vector of length 3, capacity 4 = {...}, metavals=std::vector of length 3, capacity 4 = {...}, has_id=true, id=21697592808, index=0, extent=9824) at tile.cpp:348
#6  0x00005594d9a1fa35 in next_feature (geoms=geoms@entry=0x7f41245b7100, geompos_in=geompos_in@entry=0x7f54a5ae2eb0, z=z@entry=13, tx=tx@entry=1416, ty=ty@entry=3285, initial_x=<optimized out>, initial_y=<optimized out>, original_features=<optimized out>, unclipped_features=<optimized out>, nextzoom=<optimized out>, maxzoom=<optimized out>, minzoom=<optimized out>, max_zoom_increment=<optimized out>, pass=<optimized out>, passes=<optimized out>, along=<optimized out>, alongminus=<optimized out>, buffer=<optimized out>, within=<optimized out>, first_time=<optimized out>, geomfile=<optimized out>, geompos=<optimized out>, oprogress=<optimized out>, todo=todo@entry=12849808566, fname=<optimized out>, child_shards=<optimized out>, filter=<optimized out>, stringpool=<optimized out>, pool_off=<optimized out>, layer_unmaps=<optimized out>) at tile.cpp:1343
#7  0x00005594d9a28930 in write_tile (geoms=geoms@entry=0x7f41245b7100, geompos_in=geompos_in@entry=0x7f54a5ae2eb0, stringpool=<optimized out>, z=<optimized out>, tx=<optimized out>, ty=<optimized out>, detail=<optimized out>, min_detail=<optimized out>, outdb=<optimized out>, outdir=<optimized out>, buffer=<optimized out>, fname=<optimized out>, geomfile=<optimized out>, minzoom=<optimized out>, maxzoom=<optimized out>, todo=<optimized out>, along=<optimized out>, alongminus=<optimized out>, gamma=<optimized out>, child_shards=<optimized out>, pool_off=<optimized out>, initial_x=<optimized out>, initial_y=<optimized out>, running=<optimized out>, simplification=<optimized out>, layermaps=<optimized out>, layer_unmaps=<optimized out>, tiling_seg=<optimized out>, pass=<optimized out>, passes=<optimized out>, mingap=<optimized out>, minextent=<optimized out>, fraction=<optimized out>, prefilter=<optimized out>, postfilter=<optimized out>, filter=<optimized out>, arg=<optimized out>) at tile.cpp:1852
#8  0x00005594d9a2dd6a in run_thread (vargs=0x5594dad981d0) at tile.cpp:2576
#9  0x00007f5575c0f6db in start_thread (arg=0x7f54a5ae3700) at pthread_create.c:463
#10 0x00007f5574ff988f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Thread 2 (Thread 0x7f54a32de700 (LWP 7280)):
#0  serialize_ulong_long (out=out@entry=0x5594dad96d50, zigzag=<optimized out>, fpos=fpos@entry=0x7f54a32dd330, fname=fname@entry=0x7fff9743bfda "mbtiles/parcels.mbtiles") at serial.cpp:68
#1  0x00005594d9a7bb46 in serialize_long_long (fname=0x7fff9743bfda "mbtiles/parcels.mbtiles", fpos=0x7f54a32dd330, n=<optimized out>, out=0x5594dad96d50) at serial.cpp:45
#2  write_geometry (wy=51470034, wx=38823941, fname=0x7fff9743bfda "mbtiles/parcels.mbtiles", out=0x5594dad96d50, fpos=0x7f54a32dd330, dv=std::vector of length 16, capacity 16 = {...}) at serial.cpp:180
#3  serialize_feature (geomfile=0x5594dad96d50, sf=sf@entry=0x7f54a32dccc0, geompos=geompos@entry=0x7f54a32dd330, fname=fname@entry=0x7fff9743bfda "mbtiles/parcels.mbtiles", wx=<optimized out>, wy=<optimized out>, include_minzoom=true) at serial.cpp:219
#4  0x00005594d9a1de65 in rewrite (geom=std::vector of length 16, capacity 16 = {...}, z=z@entry=13, nextzoom=14, maxzoom=<optimized out>, bbox=bbox@entry=0x7f54a32dd1a0, tx=tx@entry=2369, ty=<optimized out>, buffer=<optimized out>, within=0x7f54a32dd350, geompos=0x7f54a32dd320, geomfile=0x7fff97437ba0, fname=0x7fff9743bfda "mbtiles/parcels.mbtiles", t=<optimized out>, layer=<optimized out>, feature_minzoom=<optimized out>, child_shards=<optimized out>, max_zoom_increment=<optimized out>, seq=0, tippecanoe_minzoom=<optimized out>, tippecanoe_maxzoom=<optimized out>, segment=<optimized out>, initial_x=0x7fff97438240, initial_y=0x7fff974381f0, metakeys=std::vector of length 3, capacity 4 = {...}, metavals=std::vector of length 3, capacity 4 = {...}, has_id=true, id=10857074377, index=0, extent=42052) at tile.cpp:348
#5  0x00005594d9a1fa35 in next_feature (geoms=geoms@entry=0x7f41300084a0, geompos_in=geompos_in@entry=0x7f54a32ddeb0, z=z@entry=13, tx=tx@entry=2369, ty=ty@entry=3141, initial_x=<optimized out>, initial_y=<optimized out>, original_features=<optimized out>, unclipped_features=<optimized out>, nextzoom=<optimized out>, maxzoom=<optimized out>, minzoom=<optimized out>, max_zoom_increment=<optimized out>, pass=<optimized out>, passes=<optimized out>, along=<optimized out>, alongminus=<optimized out>, buffer=<optimized out>, within=<optimized out>, first_time=<optimized out>, geomfile=<optimized out>, geompos=<optimized out>, oprogress=<optimized out>, todo=todo@entry=12849808566, fname=<optimized out>, child_shards=<optimized out>, filter=<optimized out>, stringpool=<optimized out>, pool_off=<optimized out>, layer_unmaps=<optimized out>) at tile.cpp:1343
#6  0x00005594d9a28930 in write_tile (geoms=geoms@entry=0x7f41300084a0, geompos_in=geompos_in@entry=0x7f54a32ddeb0, stringpool=<optimized out>, z=<optimized out>, tx=<optimized out>, ty=<optimized out>, detail=<optimized out>, min_detail=<optimized out>, outdb=<optimized out>, outdir=<optimized out>, buffer=<optimized out>, fname=<optimized out>, geomfile=<optimized out>, minzoom=<optimized out>, maxzoom=<optimized out>, todo=<optimized out>, along=<optimized out>, alongminus=<optimized out>, gamma=<optimized out>, child_shards=<optimized out>, pool_off=<optimized out>, initial_x=<optimized out>, initial_y=<optimized out>, running=<optimized out>, simplification=<optimized out>, layermaps=<optimized out>, layer_unmaps=<optimized out>, tiling_seg=<optimized out>, pass=<optimized out>, passes=<optimized out>, mingap=<optimized out>, minextent=<optimized out>, fraction=<optimized out>, prefilter=<optimized out>, postfilter=<optimized out>, filter=<optimized out>, arg=<optimized out>) at tile.cpp:1852
#7  0x00005594d9a2dd6a in run_thread (vargs=0x5594dad98470) at tile.cpp:2576
#8  0x00007f5575c0f6db in start_thread (arg=0x7f54a32de700) at pthread_create.c:463
#9  0x00007f5574ff988f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Thread 1 (Thread 0x7f54a3adf700 (LWP 7274)):
#0  0x00005594d9a7c531 in deserialize_feature (geoms=0x7f41181e4650, geompos_in=0x7f54a3adeeb0, z=4294967292, tx=2736259840, ty=3397699503, initial_x=0x7fff97438240, initial_y=0x7fff974381f0) at serial.cpp:275
#1  0x00005594d9a1ebb6 in next_feature (geoms=geoms@entry=0x7f41181e4650, geompos_in=geompos_in@entry=0x7f54a3adeeb0, z=z@entry=-4, tx=tx@entry=2736259840, ty=ty@entry=3397699503, initial_x=<optimized out>, initial_y=<optimized out>, original_features=<optimized out>, unclipped_features=<optimized out>, nextzoom=<optimized out>, maxzoom=<optimized out>, minzoom=<optimized out>, max_zoom_increment=<optimized out>, pass=<optimized out>, passes=<optimized out>, along=<optimized out>, alongminus=<optimized out>, buffer=<optimized out>, within=<optimized out>, first_time=<optimized out>, geomfile=<optimized out>, geompos=<optimized out>, oprogress=<optimized out>, todo=todo@entry=12849808566, fname=<optimized out>, child_shards=<optimized out>, filter=<optimized out>, stringpool=<optimized out>, pool_off=<optimized out>, layer_unmaps=<optimized out>) at tile.cpp:1318
#2  0x00005594d9a28930 in write_tile (geoms=geoms@entry=0x7f41181e4650, geompos_in=geompos_in@entry=0x7f54a3adeeb0, stringpool=<optimized out>, z=<optimized out>, tx=<optimized out>, ty=<optimized out>, detail=<optimized out>, min_detail=<optimized out>, outdb=<optimized out>, outdir=<optimized out>, buffer=<optimized out>, fname=<optimized out>, geomfile=<optimized out>, minzoom=<optimized out>, maxzoom=<optimized out>, todo=<optimized out>, along=<optimized out>, alongminus=<optimized out>, gamma=<optimized out>, child_shards=<optimized out>, pool_off=<optimized out>, initial_x=<optimized out>, initial_y=<optimized out>, running=<optimized out>, simplification=<optimized out>, layermaps=<optimized out>, layer_unmaps=<optimized out>, tiling_seg=<optimized out>, pass=<optimized out>, passes=<optimized out>, mingap=<optimized out>, minextent=<optimized out>, fraction=<optimized out>, prefilter=<optimized out>, postfilter=<optimized out>, filter=<optimized out>, arg=<optimized out>) at tile.cpp:1852
#3  0x00005594d9a2dd6a in run_thread (vargs=0x5594dad97c90) at tile.cpp:2576
#4  0x00007f5575c0f6db in start_thread (arg=0x7f54a3adf700) at pthread_create.c:463
#5  0x00007f5574ff988f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

@ericfischer Were you able to make any progress with the file I sent back in Feb? I emailed it to the address on your Github profile page.

@stevage I am facing the exact problem. Did you get a solution over the past year and half now?


Fix Binary Tree Paths titles and links

Rename Bnary to Binary and fix link to solution

Great catch! Thanks for the help!


Activity update: EndedActivityUpdate(activityId: "Some ID") as soon as i create an activity i get this log for some reason using the default app sample widget

problem was solved make sure to make app group id capability on all modes

@OmerTrainer  I got the same error any help?

just make sure the main runner app is configured correctly with the app-group id capability

@OmerTrainer I got the same error any help?

just make sure the main runner app is configured correctly with the app-group id capability

@OmerTrainer I got the same error any help?

I make sure that are the same group id what else should I see
I want to show the default view only now

the problem i had is that i wrongfully added App Groups  capability not to my main app runner i can't tell if you did that by the screenshot that you provided but if you configured it right then the problem should be somewhere else

@OmerTrainer  can we get a quick meeting if you have a time ?

problem was solved make sure to make app group id capability on all modes

yes, but i would prefer to help you in this thread so everyone that encounters this can enjoy the solution.

make sure "All" is selected when you add the capability both on the main runner app and the live activity extenstion

problem was solved make sure to make app group id capability on all modes

yes, but i would prefer to help you in this thread so everyone that encounters this can enjoy the solution.

yes I will make sure I write the solution after solve it
can you connect me at<EMAIL_ADDRESS>

flutter: F0821F95-CCAD-43F2-A073-329811474699
flutter: Activity update: EndedActivityUpdate(activityId: F0821F95-CCAD-43F2-A073-329811474699)
final activityId = await _liveActivitiesPlugin .createActivity({});
@OmerTrainer

<EMAIL_ADDRESS>
why are you passing an empty map "{}" as a paremeter when creating an activity ? make sure first you can run the sample project see if it works correctly

<EMAIL_ADDRESS>
why are you passing an empty map "{}" as a paremeter when creating an activity ? make sure first you can run the sample project see if it works correctly

I want to show only the default view

<EMAIL_ADDRESS>
why are you passing an empty map "{}" as a paremeter when creating an activity ? make sure first you can run the sample project see if it works correctly

I want to show only the default view

The "Default" view also requires some params.... Look at the "Content-State" in the liveactivity extension to see what params you need to pass

<EMAIL_ADDRESS>
why are you passing an empty map "{}" as a paremeter when creating an activity ? make sure first you can run the sample project see if it works correctly

I want to show only the default view

The "Default" view also requires some params.... Look at the "Content-State" in the liveactivity extension to see what params you need to pass

this is my liveactivity

<EMAIL_ADDRESS>
why are you passing an empty map "{}" as a paremeter when creating an activity ? make sure first you can run the sample project see if it works correctly

I want to show only the default view

The "Default" view also requires some params.... Look at the "Content-State" in the liveactivity extension to see what params you need to pass

this is my live activity @OmerTrainer

you need to provide "emoji" and "name" or just delete all the fields and make an hard coded view that doesn't relay on the params

<EMAIL_ADDRESS>
why are you passing an empty map "{}" as a paremeter when creating an activity ? make sure first you can run the sample project see if it works correctly

I want to show only the default view

The "Default" view also requires some params.... Look at the "Content-State" in the liveactivity extension to see what params you need to pass

this is my live activity @OmerTrainer

you need to provide "emoji" and "name" or just delete all the fields and make an hard coded view that doesn't relay on the params

how to provide them please?

<EMAIL_ADDRESS>
why are you passing an empty map "{}" as a paremeter when creating an activity ? make sure first you can run the sample project see if it works correctly

I want to show only the default view

The "Default" view also requires some params.... Look at the "Content-State" in the liveactivity extension to see what params you need to pass

this is my live activity @OmerTrainer

you need to provide "emoji" and "name" or just delete all the fields and make an hard coded view that doesn't relay on the params

how to provide them please?

await _liveActivitiesPlugin .createActivity({"emoji": "sample","name": "sampleName"});

same result no changes

 same result no changes @OmerTrainer

you might consider researching a bit more on how it works before trying to implement it. first try to build the sample project that is provided with the package

 same result no changes @OmerTrainer

you might consider researching a bit more on how it works before trying to implement it. first try to build the sample project that is provided with the package

I really tried many times don't know what is the real issue if you have some time please connect me at<EMAIL_ADDRESS>

 same result no changes @OmerTrainer

you might consider researching a bit more on how it works before trying to implement it. first try to build the sample project that is provided with the package

I really tried many times don't know what is the real issue if you have some time please connect me at<EMAIL_ADDRESS>
you can reach me out at<EMAIL_ADDRESS>i will try to do my best to help :)

[ERROR:flutter/shell/common/shell.cc(1055)] The 'live_activities/activity_status' channel sent a message from native to Flutter on a non-platform thread. Platform channel messages must be sent on the platform thread. Failure to do so may result in data loss or crashes, and must be fixed in the plugin or application code creating that channel.
See https://docs.flutter.dev/platform-integration/platform-channels#channels-and-platform-threading for more information.
@OmerTrainer  new error


How to handle group permissions?

We have a root based app that is using a large number of dangerous group permissions. So it seem quite unfeasible to implement every single permission by itself from these groups.

What is the best way to deal with this?
Can PD handle these?

The particular permissions from each group are these:
Group           Permission (we need)
-----------------------------------------------------------------------
LOCATION        ACCESS_FINE_LOCATION, ACCESS_COARSE_LOCATION
PHONE           READ_PHONE_STATE, CALL_PHONE, USE_SIP, PROCESS_OUTGOING_CALLS
SMS             SEND_SMS, RECEIVE_SMS, READ_SMS, RECEIVE_WAP_PUSH, RECEIVE_MMS
STORAGE         READ_EXTERNAL_STORAGE, WRITE_EXTERNAL_STORAGE

Have you tried listing them? like @NeedsPermission({Manifest.permission.ACCESS_FINE_LOCATION, Manifest.permission.ACCESS_COARSE_LOCATION, ...})

Hi thanks for ultra-rapid feedback!

Have you tried listing them?
I'm sure that works. But it would be more user friendly, if we could also write:

@NeedsPermission({Manifest.permission-group.LOCATION, Manifest.permission-group.PHONE, ...})

What do you mean in terms of "user"?

@shiraji Sorry, I'm not trying to be a PITA here, just that the code would look much better and easier to read, if one doesn't have to list up every single permission, if one already knows what group they belong to.  If you think my case is too trivial, then please disregard my issus, but do add the question in a future FAQ or in your README as its not obvious how to best do this.
So given your response, the conclusion is that currently PD does not handle groups as separate entities (in case someone else is wondering about this.)

Yes. PD doesn't support grouping. By the way, do you know AOSP support the "grouping"? (AFAIK, grouping only appear on the documentation, not in the code.) If so, PD will support it as soon as possible.

I also think that the classification of permissions in "groups" is merely a cosmetic one, and that you can't use them for framework-level Runtime Permissions. If I find time, I'll do a quick POC for that to check & verify, because it would be nice to support if you could actually do that.

do you know AOSP support the "grouping"?

IDK. But I do know, if you on a AOS 6.0+ device, go to Settings > apps > "some app" > permissions, then what you see are these groups.

I don't think this is cosmetic at all. Look here. But the way they are included into the AndroidManifest is non-trivial...
android:permissionGroup="android.permission-group.LOCATION"
android:permissionGroup="android.permission-group.PHONE"
android:permissionGroup="android.permission-group.SMS"
android:permissionGroup="android.permission-group.STORAGE"

By something like this:
<uses-permission android:name="android.permission.INTERACT_ACROSS_USERS_FULL"
                     android:permissionGroup="android.permission-group.STORAGE"
                     android:protectionLevel="dangerous" />

After a quick exercise in Google-fu, I found Mark Murphy's take on this, which may be outdated at this point, but it makes a strong argument about the framework's Runtime Permissions model only handling Manifest.permission.*, as opposed to Manifest.permission-group.* as well. Since that seems to be the case, PermissionsDispatcher can't work around that.

@E3V3A Thx for your report.
In your case I suppose it's not bad to just asking one permission per each group. I know it's tricky but it can't be helped as that's the specification of Android Framework. And please make sure to asking each permission when it's actually needed(ref).
About PermissionsDispatcher, we just generate handling code at compile time and delegate the work to it so I'm not for addressing permission-group constants. It might be handy in short run but  in the long run it will increase the maintenance cost of the app since user have to look into the library code when they encounter the problem.

@hotchemi, @aurae  and @shiraji  Again, thanks a lot for your support and explanations.

NP!

Reading the developer notes again:

If an app requests a dangerous permission listed in its manifest, and the app already has another dangerous permission in the same permission group, the system immediately grants the [other] permission without any interaction with the user. For example, if an app had previously requested and been granted the READ_CONTACTS permission, and it then requests WRITE_CONTACTS, the system immediately grants that permission.

So I'm back to 4!


How to handle new RequestTypes?

As it is right now the ask-sdk from Amazon can easily handle new types of alexa requests without necesarilly running too deep into the Framework code. As an example, to support the new SessionResumedRequest for Skill Connections it's only needed to implement a simple request handler:
    canHandle(handlerInput) {
        const request = handlerInput.requestEnvelope.request;
        return request.type === 'SessionResumedRequest';
   }

Right now there's no documentation at all as to achieving something like that in Voxa, checking the code seems like we could extend the AlexaPlatform class with something like
class CustomAlexaPlatform extends AlexaPlatform {
  public getPlatformRequests() {
    return Array.prototype.concat(
        super().getPlatformRequests(),
        'SessionResumedRequest'
    )
  }
}

We need to figure out if there's any changes required to support a "Better Way (tm)" or if this is sufficient. After that we need to document the accepted solution

@armonge check this other issue and give us your thoughts #246


Add iSpy

          1 Warning

:warning:
Found 3 link issues

Link issues by awesome_bot

Line
Status
Link

53
404
https://apps.apple.com/app/layer-player/id949768742

245
404
https://apps.apple.com/app/formant-analyzer/id799183655

246
404
https://apps.apple.com/app/8-ball-answer/id995732766

Link issues by awesome_bot

Line
Status
Link

2352
Error
https://gitee.com/existorlive/exist-or-live-pic/raw/master/IMG_4245.PNG  Failed to open TCP connection to gitee.com:443 (Connection timed out - connect(2) for "gitee.com" port 443)

2353
Error
https://gitee.com/existorlive/exist-or-live-pic/raw/master/IMG_3785.JPG  Failed to open TCP connection to gitee.com:443 (Connection timed out - connect(2) for "gitee.com" port 443)

2354
Error
https://gitee.com/existorlive/exist-or-live-pic/raw/master/IMG_3789.JPG  Failed to open TCP connection to gitee.com:443 (Connection timed out - connect(2) for "gitee.com" port 443)

  Generated by :no_entry_sign: Danger


Node memory capacity incorrect on graph

Describe the bug
The value for the overall capacity of memory of all kubernetes nodes is not correct on some cases. This only applies to the graph itself, in the table below the graph, the 'Capacity' is correct.
To Reproduce
I don't know how you can reproduce the problem, I only get it on one of my 4 clusters.
Expected behavior
For lens to show the correct memory capacity graph for a kubernetes node.
Screenshots

As you can see, the graph and the tooltip show about 94 GB of available memory for that node, which is wrong, as you can see in the table below the graph.
Environment (please complete the following information):

Lens Version:
OS: OSX
Installation method: Image from Github

Same here and on the cluster View too.
Its on CPU Requests, CPU Limits and CPU Capacity, Memory Requested, Memory Limits, Memory Capacity.
It,s always factor 3, but not for CPU/Memory usage.
Environment:
OS: Windows
Version: 3.3.1
Cluster: Kubernetes on Azure (AKS), Version 1.5.7

@TweetyHH yes, you are right. the capacity on cluster view is incorrect for me as well. my total available cluster resources should be
72 cpu
141 GB ram
330 Pods
but is:

so only cpu is correct for me. ram and pods should be only a third of the given value. (i guess divided by the amount of available nodes?)

@geruetzel I don't thinks its about number of the cluster nodes (worker). We have here 7 or 8 nodes. The same issue is on the diagrams of a pod.
Additional Question: Would it be possible to show the current usage of cpu/memory the pod view. On the node view is an indication of the current cpu/memory usage.

I am seeing something similar on pod resource requests/limits; if set. It's off by a factor of 3. I see this on one of my clusters, but not the others. Lens will display a different value than what kubectl will report.

@geruetzel @TweetyHH @matthewhembree could you check if prometheus has collected duplicate data (via Prometheus web UI or similar)?

@jakolehm It looks like there is some kind of tripple data in the lens prometheus instance. In our setup we have our own prometheus/monitoring stack running, but additionally installed the lens prometheus/monitoring stack. I think they should work independently.
Here a screenshot for one node of kube_node_status_allocatable_cpu_cores

I dont know related my problem to this or not, but i have wrong memory capacity at nodes list, annoys me a lot.

But on memory usage prometheus view everything is fine.

Lens 5.1.1-latest.20210716.1
MacOS Big Sur

Having the same issue, however besides node metrics, pod/container metrics are affected as well. There are no duplicates in Prometheus, however this is what happens in Lens:

As you can see, at first requests and limits are displayed correctly, however the next data point comes multiplies by 2.


example_sdl2.py has unstable FPS because it lacks completion fence/semaphores

This is probably related to Bug #55
In my instance, vkAcquireNextImageKHR burns through a handful of buffers at max speed, and then settles down to 60Hz (1 buffer every 16.6666666 ms).  I suspect that this would put a 10-15 frame latency in things I do if this were an active application rather than an example.
I'm on Windows 10, a Microsoft Surface Pro, with Intel UHD Graphics 620 via the external Surface dock to an LG 32UD99-W monitor via mini-Displayport and Vulkan SDK <IP_ADDRESS>
The synchronization primitives used in the example don't seem to be sufficient to get stable and repeatable results on hardware.
I also did a grubby port to glfw to see if there was an SDL issue, GLFW exhibits the same behavior.
Thanks.
main.py.zip

Hello @buzmeg, I will take a look at your issue.
Thanks for submitting.

Hello, the test is just a sample to show it works. The developer then has to take care of utilization in order to get the maximum performance of Vulkan.


loading html string

I couldn't find a way to load html string in the webview, is there any workaround for that ?

Hi @murad1981
That's a great idea - I completely overlooked it.
You can use the web view configuration to do it, but I'll add another initializer to make it easier.

This is now available in the newly released 0.3. 🙌


RFC: Associated type defaults

🖼 Rendered
📝 Summary
Resolve the design of associated type defaults, first introduced in RFC 192, such that provided methods and other items may not assume type defaults. This applies equally to default with respect to specialization. Finally, dyn Trait will assume provided defaults and allow those to be elided.
💖 Thanks
To @aturon for their work on RFC 192 and RFC 1210 upon which this RFC builds.
To @kennytm, @Havvy, @ubsan, @varkor, @alexreg, and @scottmcm for reviewing the draft version of this RFC.

What a great RFC, thanks!
You already list many examples where the default group feature as proposed is super useful, but to give another one: I think with this (and specialization), it would be possible to implement something like C++'s std::remove_reference (related StackOverflow question).

I just wanted to throw another idea out there:
Trait items can never "depend" on a method, i.e. never depend on a specific method implementation, right? So in that case, we could just say "if you override one thing in a default group, you have to override everything -- except methods: you can override these without needing to override anything else in the default group." Of course, that makes the rule more complicated. But I'd rather have this than an unnecessary restriction.
However, I'm not sure if this will be considered legal in the future:
trait Foo {
    const fn size() -> usize { 3 }
    type ARR = [u8; Self::size()];
}

If that's the case, other trait items could depend on specific implementations on methods and the modified rule wouldn't work.

Also, I think that "letting the compiler infer all dependencies between trait items" (which you only mentioned briefly) is not that bad of an idea. Sure, the dangers of implicitness strike again, but I think it would have many benefits.
Dependencies between trait items are a directed graph. The default groups as proposed here make it possible to form cliques (fully connected parts of the graph) from some items. Put like that, that sounds rather limiting. To have the most expressive power (let's assume we want that), the compiler has to know about the exact dependency graph (without adding unnecessary edges). The compiler could infer this graph, so that's not the problem.
To solve the "implicitness-problem" one could:

go for full explicitness with something like #[depends_on(Bar, BAZ)] fn foo() -> Self::Bar { ... }, or
annotate that items depend on something, without explicitly mentioning what they depend on (#[depending] fn foo() { ... }), or
don't do anything because it might not be that big of a problem.

@daboross

The "if you override one, you override all" concept seems easy to understand, teach, and write.

Very much agree with this sentiment :)

How open would you be to having default inside a default group and nested default groups indicate this?

I'm open :) It seems natural.
In this scheme, the way we can understand default $item is by a desugaring to default { $item }.
The type checking rule, if I understand it correctly from your example, is that a sub-group acts as an atomic unit itself and can be overridden independently of its parent but if anything in the parent is overridden, then the sub-group must be as well.  On the face of it, I think this scheme would be sound; but I would encourage everyone to double check this.
This seems a bit more complex than "if you override one, you override all", but not by much. It also adds flexibility and value to nesting which was previously lacking.

@LukasKalbertodt

You already list many examples where the default group feature as proposed is super useful, but to give another one: I think with this (and specialization), it would be possible to implement something like C++'s std::remove_reference (related StackOverflow question).

Interesting :) If you have the time, could you perhaps encode this in the style of this RFC so that I can include it?

So in that case, we could just say "if you override one thing in a default group, you have to override everything -- except methods: you can override these without needing to override anything else in the default group."

This seems sound; however, I see some drawbacks:

It is now impossible to enforce that two methods must be overridden together;
While that is not necessary for soundness, it is a useful ability to give to users when they have two or more methods that are unusually co-dependent and not implementing them together will usually lead to logic bugs.

It is not a particularly uniform treatment of items; instead, methods are treated specially.
You do note this increase in complexity yourself. :)

It forces an interpretation of fn where the body can't be exposed which you also note.
In the past, we have considered such schemes for const fn and I think it would be a shame to give that interpretation up.
AIUI, the mechanism as proposed in the RFC can also be weakened in the future to be compatible with your model (please double check this).

All in all, my view here is that needing to see the underlying type of an associated type won't be too common; in particular, I don't think it will be common to need to see the underlying type and have many methods at the same time. Given this conjecture, I think that the special casing of methods is not particularly justified here and that @daboross's amended mechanism of default groups should cover the needs of users.

Also, I think that "letting the compiler infer all dependencies between trait items" (which you only mentioned briefly) is not that bad of an idea. Sure, the dangers of implicitness strike again, but I think it would have many benefits.

So the reason I haven't gone into greater detail here is because the semantics of this inference have not yet been well defined and because it was only mentioned in passing in https://github.com/rust-lang/rust/issues/29661#issuecomment-176489784.

Dependencies between trait items are a directed graph. The default groups as proposed here make it possible to form cliques (fully connected parts of the graph) from some items.

Does not @daboross's amendment change this? It should be possible to define more refined sub-graphs this way?

To have the most expressive power (let's assume we want that), the compiler has to know about the exact dependency graph (without adding unnecessary edges).

This seems backwards compatible with this RFC in the sense that if you don't use default { .. }, then inferring dependencies will accept strictly more programs and will allow you to use the given definitions where before you could not.

The compiler could infer this graph, so that's not the problem.

I think this is true; but I would like to see a more elaborate argument for why this is the case and how complex such inference would be.

To solve the "implicitness-problem" one could:

First a few words about why implicitness is a problem in the first place. I think here, the problem is not so much that readability would suffer from implicitness, but rather that intuiting the dependencies for a human could be non-trivial wherefore it would be difficult to see what implications a change has for semantic versioning. The fear here is that the user would accidentally make a change that requires upstream users to provide definitions they previously didn't need to.

go for full explicitness with something like #[depends_on(Bar, BAZ)] fn foo() -> Self::Bar { ... },

I assume this would also be checked by the compiler?
Ostensibly, one could use default(Bar, BAZ) { .. } as a surface syntax here.
However; I think overly fine-grained graphs would be too complex for many users to deal with.

annotate that items depend on something, without explicitly mentioning what they depend on (#[depending] fn foo() { ... }),

This doesn't seem to notably solve the semver problem; the crate author still has to scan the code to reconstruct the graph in their head.

don't do anything because it might not be that big of a problem.

I think this is highly likely to be the case. If it turns out to be a big problem (it is not in the Haskell community) then we can solve that problem in the future.

Does not @daboross's amendment change this? It should be possible to define more refined sub-graphs this way?

Yes, now that I read their comment again, I think it's actually very powerful. Let's use this slightly modified version (I added quux):
trait Bar {
    default {
        type Foo = &'static str;
        fn quux() -> Self::Foo { "quux" }
        default const MY_FOO: Self::Foo = "Bar's foo";
        default fn get_fooa() -> Self::Foo { "Foo A" }
        default fn get_foob() -> Self::Foo { "Foo B" }
        default {
            fn get_c() -> Self::Foo { "C" }
            fn get_d() -> Self::Foo { "D" }
        }
    }
}

The above code would result in the following tree (each node representing one default group):

As far as I understand (please correct me if I'm wrong): an item can depend on items in the same node and on items in any ancestor nodes (up the tree). This has the consequence that if an impl block overrides one item $x, it also has to override all items in the same node as $x and all items in all all nodes descendant from the node with $x (down the tree).
The "can depend on" rule sounds exactly like the rule we use to determine if a non-pub item in a module tree is accessible. Which is cool, since then programmers are already familiar with it.
In terms of the dependency graph I was talking about, this would mean that the programmer can define ... "a tree of cliques" if that makes any sense. This looks really powerful to me. I'm not sure if there are actually useful situations where one would need a more powerful system. So I'm all :+1: for that idea!

This seems backwards compatible with this RFC in the sense that if you don't use default { .. }, then inferring dependencies will accept strictly more programs and will allow you to use the given definitions where before you could not.

True. That's always good.

I think this is true; but I would like to see a more elaborate argument for why this is the case and how complex such inference would be.

I assumed it's possible, because that knowledge is already needed to emit compiler errors, right? To check if the trait is well-formed, the compiler has to check that there aren't any items depending on another item.

However; I think overly fine-grained graphs would be too complex for many users to deal with.
[...]
This doesn't seem to notably solve the semver problem; the crate author still has to scan the code to reconstruct the graph in their head.
[...]
This seems sound; however, I see some drawbacks:

Yip, I agree with all of those. In particular, I also dislike special casing methods.

Interesting :) If you have the time, could you perhaps encode this in the style of this RFC so that I can include it?

Mhhh, I'm not quite sure what you mean. But let me just explain some details.

My original motivation was to write something like this:
fn print<T>(x: T)
where
    <T as RemoveRef>::WithoutRef: fmt::Display,
{
    println!("{}", x.single_ref());
}

Of course, for Display this boilerplate is not necessary, because impl<T: Display> Display for &T. But I wanted to avoid writing these kinds of blanket impls for references. So in that case RemoveRef is useful.
To have something like C++'s std::remove_reference we need a trait with an associated type. To be able to obtain an instance of the reference-removed type, a method is necessary. So my idea was to write:
trait RemoveRef {
    type WithoutRef;
    fn single_ref(&self) -> &Self::WithoutRef;
}

default impl<T> RemoveRef for T {
    type WithoutRef = T;
    fn single_ref(&self) -> &Self::WithoutRef {
        self
    }
}

impl<'a, T: RemoveRef> RemoveRef for &'a T {
    type WithoutRef = T::WithoutRef;
    fn single_ref(&self) -> &Self::WithoutRef {
        T::single_ref(*self)
    }
}

But this doesn't work since single_ref can't assume a specific type for WithoutRef (Playground). Wrapping the type and method in a default group would solve this problem and make this trait possible.

@LukasKalbertodt

The above code would result in the following tree (each node representing one default group):

Yep; that seems right. (Also, nicely done on including a tree; I should integrate a similar thing in the RFC eventually).

As far as I understand (please correct me if I'm wrong): an item can depend on items in the same node and on items in any ancestor nodes (up the tree). This has the consequence that if an impl block overrides one item $x, it also has to override all items in the same node as $x and all items in all all nodes descendant from the node with $x (down the tree).

This seems exactly right :)

The "can depend on" rule sounds exactly like the rule we use to determine if a non-pub item in a module tree is accessible. Which is cool, since then programmers are already familiar with it.

That's perfect!

In terms of the dependency graph I was talking about, this would mean that the programmer can define ... "a tree of cliques" if that makes any sense. This looks really powerful to me. I'm not sure if there are actually useful situations where one would need a more powerful system. So I'm all 👍 for that idea!

I think a "tree of cliques" makes perfect sense; and I agree that this should be more than enough power to do anything you need.
I would like to triple-check the soundness implications of @daboross's amendment for a bit.
But I think I'm going to integrate @daboross's idea in the main proposal soon.

I assumed it's possible, because that knowledge is already needed to emit compiler errors, right? To check if the trait is well-formed, the compiler has to check that there aren't any items depending on another item.

Hmm... It might be that to scan a trait definition to infer all dependencies, you must chase some indirections if items don't depend on each other directly. However, I haven't given it much thought.

But let me just explain some details.

Cool :)
Aside: With #2289 you could write:
fn print(x: impl RemoveRef<WithoutRef: fmt::Display>) {
    println!("{}", x.single_ref());
}

Wrapping the type and method in a default group would solve this problem and make this trait possible.

So you would then write:
trait RemoveRef {
    type WithoutRef;
    fn single_ref(&self) -> &Self::WithoutRef;
}

impl<T> RemoveRef for T {
    default {
        type WithoutRef = T;
        fn single_ref(&self) -> &Self::WithoutRef { self }
    }
}

impl<'a, T: RemoveRef> RemoveRef for &'a T {
    default {
        type WithoutRef = T::WithoutRef;
        fn single_ref(&self) -> &Self::WithoutRef { T::single_ref(*self) }
    }
}

Off the top of my head, nested default groups seems like a good idea — however, I also think that we should ask whether functions deserve special treatment or not.
From the point-of-view of "would things compile", I think that (at least with the lang as it is today) overriding a function can't cause any problems.
But it might lead to semantic breakage. e.g., perhaps there is an associated type that is somehow "tied" to the details of what the fn does, and when those details change, a different type would be more appropriate, even though the older type would still compile.
One can  easily see this with some sort of associated constant. e.g., you might have a constant like const HAS_SIDE_EFFECTS: bool = false -- and when you override the fn, you might introduce side-effects, without altering the value of this constant.
Using nested groups, we can express the difference, which is good, but of course the notation sort of "defaults" the wrong way -- most of the time we don't need such strict dependencies, right?
(I haven't had time to read the RFC in detail yet, I'm not sure if it discusses any such examples.)

Hmm... It might be that to scan a trait definition to infer all dependencies, you must chase some indirections if items don't depend on each other directly. However, I haven't given it much thought.

Me neither and I'm far to unfamiliar with the compiler internals to say how feasible this would be. Anyway, I guess the majority of the community would dislike this completely implicit version anyway.

Aside: With #2289 you could write:

I'm already subscribed to the tracking issue and hope that I can play with it on nightly soon ;-)

So you would then write:

Exactly. That's what I meant. I think this should work.

Using nested groups, we can express the difference, which is good, but of course the notation sort of "defaults" the wrong way -- most of the time we don't need such strict dependencies, right?

But if you don't want those strict dependencies, you just don't use a default group, right?
And as I read the RFC, the meaning of default impl ... isn't changed. That is, it still desugars to an impl with default in front of every item and not to impl { default { ... } }.

@nikomatsakis

But it might lead to semantic breakage. e.g., perhaps there is an associated type that is somehow "tied" to the details of what the fn does, and when those details change, a different type would be more appropriate, even though the older type would still compile.

I think that's exactly right; It doesn't even have to be an fn and a type; It could just be two fns which the one who has defined the trait want all users to always define together because they are particularly easy to get wrong if you don't define them together. So my preference at this stage is to not give fns special treatment and give all items more uniform treatment.

Using nested groups, we can express the difference, which is good, but of course the notation sort of "defaults" the wrong way -- most of the time we don't need such strict dependencies, right?

I think most of the time, you won't need to assume the underlying definition of an item at all, and just the signature will be sufficient; i.e. I think most cases will be like the Arbitrary trait in the RFC. In other words, I think most cases will have 0-deep nesting.
When the underlying type is needed to be assumed for some set of items, I think 1-deep will be the next most likely thing.
Having two nest default groups (2+-deep) will probably be even less needed.
Perhaps the most common use case for a 2-deep nesting is @daboross's example with one associated type and a bunch of different methods.
My conjecture about depth here is that the usage of depth decreases exponentially with the depth.

(I haven't had time to read the RFC in detail yet, I'm not sure if it discusses any such examples.)

There is one example in the reference, but it is not a real world example.
I think @daboross's note:

If I have a bunch of default methods all relying on the same associated type default, I would want users to be able to override some default methods without overriding others.

would be the most common real world scenario for a 2-deep nesting.
@LukasKalbertodt

Anyway, I guess the majority of the community would dislike this completely implicit version anyway.

Hehe, yes; I think so.

I'm already subscribed to the tracking issue and hope that I can play with it on nightly soon ;-)

Feel free to implement it =P

Exactly. That's what I meant. I think this should work.

Cool; I'll include it in the RFC as an example at some point ^.^

And as I read the RFC, the meaning of default impl ... isn't changed.

Yep; that's correct.

That is, it still desugars to an impl with default in front of every item and not to impl { default { ... } }.

My understanding from https://github.com/rust-lang/rfcs/pull/1210 was that default impl ... was a sort of "partial implementation" that is not yet a full impl; that is, this is what provided items in traits would desugar to.

Am I correct that everything here could be expressed with partial impls?  And thus default { .. } is just sugar?  If so, that makes this a fairly minor change, right?
default impl<T> RemoveRef for T {
    type WithoutRef = T;
    fn single_ref(&self) -> &Self::WithoutRef { self }
}
default impl<'a, T: RemoveRef> RemoveRef for &'a T {
    type WithoutRef = T::WithoutRef;
    fn single_ref(&self) -> &Self::WithoutRef { T::single_ref(*self) }
}

@burdges

Am I correct that everything here could be expressed with partial impls?
And thus default { .. } is just sugar?

No, you are incorrect. It is not sugar but adds a fundamental capability to the language that AFAIK can't be decomposed into anything else. default impl (partial implementations -- because they do not actually constitute an implementation even if you define all items inside) won't let you assume that WithoutRef == T::WithoutRef inside single_ref. To do that, you need to put things into a default { .. } group inside default impl ....

I see.  I should've said an #[all_or_nothing] feature looks equivalent:
#[all_or_nothing]
default impl<T> RemoveRef for T {
    type WithoutRef = T;
    fn single_ref(&self) -> &Self::WithoutRef { self }
}
#[all_or_nothing]
default impl<'a, T: RemoveRef> RemoveRef for &'a T {
    type WithoutRef = T::WithoutRef;
    fn single_ref(&self) -> &Self::WithoutRef { T::single_ref(*self) }
}

If partial impls need to be finalized for some cases, then we do so generically, assuming that works, ala impl<T> RemoveRef for T { }.

@alexreg I haven't even had time to make all the updates necessary to reflect the recent discussions. This RFC makes non-trivial changes to the type system for which the soundness implications must be carefully considered; so it shouldn't be rushed ;) But I appreciate that you like my RFC(s) =P. I won't propose FCP for this as I don't with any of the RFCs I've written and leave that up to other T-lang members.

Updates:

Due to "popular demand" I've resolved the question re. nested groups in favor of keeping them.
The RFC now uses @daboross's tree-of-cliques idea using @LukasKalbertodt's formulation.
I've made the RFC more detailed and more exactly specified in various ways.

What a fantastic RFC! It was a joy to read.
I'm very happy with this direction, and especially the prospect of doing away with "partial impls" in favor of where clauses on default groups; the idea of providing more specialized defaults in an impl rather than the trait itself always seemed confusing. This RFC also puts me at ease about the use of the default keyword in specialization.
More generally, this proposal strikes me as a solid unification of several existing mechanism in a way that is quite easy to grasp. In particular, this approach makes specialization easier to understand, as a natural extension of defaults in traits to defaults in impls. Kudos for improving uniformity, expressivity, and learnability in one stroke!
One thing I don't think you say explicitly, but seems worth calling out: in trait definitions, items with definitions are implicitly singleton default groups (assuming that they are not in the scope of some default group already). I think we should consider ultimately linting against such definitions and requiring explicit use of the default keyword, to make the grouping more clear and the experience more consistent.

The Lang Team discussed this RFC at some length in our meeting today. I'm going to try to summarize some of the points that were raised; we didn't reach any overall conclusions or consensus.

There was general agreement about the motivation and desire to solve this problem
@withoutboats raised the question of typical/best practices around this feature. In particular, for cases where you have a single defaulted associated type, and several methods that depend on it (but not meaningfully on each other), the "right" thing to do is to use two levels of nesting:trait Foo {
    default {
        type Assoc = SomeType;
        default fn method1() -> Self::Assoc { .. }
        default fn method2() -> Self::Assoc { .. }
        // etc
    }
}

This allows the most flexibility for downstream code. If we believe this kind of case is a common one, it seems problematic that the syntax doesn't naturally guide you toward the "best practice" definition -- and moreover that the best practice version is a little hairy.
@nikomatsakis voiced discomfort with items occurring at different nesting levels while being bound at the same lexical scope.
@nikomatsakis and @cramertj also voiced concern that it can be difficult to quickly grasp the "dependency graph" with this syntax.
@aturon raised an additional alternative syntax, similar to one mentioned in Alternatives: continue to treat default purely as a item-level qualifier (not a scope), but allow it to be further qualified by a list of dependencies, i.e. default(Assoc) fn method1() -> Self::Assoc.

Pro: nudges you more toward "best practices", i.e. giving as few dependencies as possible
Pro: avoids nesting and associated issues with that
Pro: allows for more expressive dependency graphs (DAGs rather than trees)
Con: requires more repetition in cases where many items share a common dependency
Con: eliminates the potential future work of removing the need for "partial impls"

@joshtriplett pointed out that this kind of alternative could be supplemented with elision to determine a default set of dependencies, if we wanted to do so.

@aturon pointed out that we should think about the relationship to "bare" default methods (in Rust today) for any such elision rule.

It'd be nice to have a bit more examples of where people might want to use this in practice, to help us observe what the expected patterns are.

All of my use cases I can remember have been to try to specialize a single method with a single associated type. Doing something like this, where its a no-op by default, is the most common thing I think:
trait Foo {
    type Assoc;
    fn foo(self) -> Self::Assoc;
}

impl<T> Foo for T {
    default {
       type Assoc = T;
       fn foo(self) -> Self::Assoc {
           self
       }
    }
}

My intuitive inclination (which could be overriden by reason) is to express these relationships by enumerating dependencies in the signature somehow, not by grouping. One thing I considered, since default() seems kind of unpleasant, was to add some sort of "using clause" similar to the way where clauses work:
impl<T> Foo for T {
    default type Assoc = T;
    default fn foo(self) -> Self::Assoc
        using Self::Assoc
    {
      self
    }
}

Has there been any progress on this lately? Are we ready to FCP it?

Has there been any progress on this lately? Are we ready to FCP it?

Haven't had time to process the recent discussion after our first meeting; I think we may want to scale the RFC back to just drop the groups and postpone that for a future discussion thereby making incremental progress.

@Centril Yes, possibly. I am happy with the concept of groups as it stands, personally, but if it speeds things up, then lets either mark it as an "unresolved question", or fork it out into a separate RFC.

@alexreg

@Centril Yes, possibly. I am happy with the concept of groups as it stands, personally, but if it speeds things up, then lets either mark it as an "unresolved question", or fork it out into a separate RFC (RFC addendum?).

I'd just move it to future possibilities for the time being. ;)

@rfcbot reviewed

expected associated type, found u8
note: expected type <Self as Foo>::Bar, found type u8

Shall compiler error message mention that the thing after = is a mere default, not an actual type? Associated type defaults syntax is very similar to just type alias syntax that is used outside of the trait, so I expect users to mistakenly trying to create associated type in a trait when they meant just a type alias.
For example, something like this could be added:
note: `u8` is a default associated type and may be overridden in implementor without necessary overriding this function.

Shall compiler error message when trying to use trait Q { type A = OtherTrait; } instead of trait Q { type A : OtherTrait; } be explicitly checked for novice-friendliness?
Currently:
#![feature(associated_type_defaults)]

trait Lol {
    type Q = std::fmt::Debug;
    fn ror(&self, q : Self::Q)  {
        println!("{:?}",q);
    }
}

<Self as Lol>::Q` doesn't implement `std::fmt::Debug
  = help: the trait `std::fmt::Debug` is not implemented for `<Self as Lol>::Q`
  = help: consider adding a `where <Self as Lol>::Q: std::fmt::Debug` bound
  = note: required by `std::fmt::Debug::fmt`

Nothing here hints me that I am actually triggered the associated type default feature.

P.S. Are compiler error messages and their novice-friendliness on-topic for RFC threads?

P.S. Are compiler error messages and their novice-friendliness on-topic for RFC threads?

We usually figure that out during implementation. :)

🎉 RFC 2532 is now merged as associated_type_defaults 🎉
Tracking issue: https://github.com/rust-lang/rust/issues/29661 (note, this is the old issue).


Do not mark peers as bad if they cannot redeem themselves

This disables marking peers as bad if the redemption interval is 0. High values can still be used to get the same effect.

bors r+


DISCUSS: Show watermark files only? Convert from quicktime?

@Muraszko @AlisonCSmith @mccalluc
Two issues here:
1. Sony Ci Proxies are roughly the same size as SD originals.
If this implies that they are also roughtly the same quality, then that's a problem, b/c people can download for free (with a little effort) the thing we're trying to license.
One solution would be to only allow playback of watermarked videos everywhere. This seems to be an acceptable standard among competitors.
however.. this brings us to issue number 2...
2. Watermarked proxies from current site do not play as-is.
@mccalluc reports that attempting to play them prompts you to install the quicktime player.
This is reminiscent of the issue we had with Openvault, where our solutions was to convert as much as we could to webm, which is adequately browser friendly. Not sure what kind of tricks the current site is using to get around this.
First we should confirm this is what is actually going on, i.e. the videos being served are being recognized by browsers as requiring the quicktime plugin.
If that's the case, then we're looking at converting all of the watermarked files to webm before they are usable. And if we're doing this, then we may be able to throw money at a big EC2 box in AWS to do it faster than we could do in house. Just a thought.

@afred @mccalluc @AlisonCSmith
I don't think 1. is true. SD clips are 720x480 or 640x480.  Ci creates 480x360 and 360x270 versions for 720x480 source.
Chuck, you said you would try having the clip playback use the 360x270 small proxy version, but scaled up to whatever the player size was on the page.  Is that working for you?  I only get errors on the demo site when I try.
For 2. the watermarked videos are in a Motion Jpeg codec Quicktime MOV wrapper.  It's not uncommon, but not really a format people use for streaming video.  The watermarked videos are intended to be delivered only as file downloads for users to view and create rough edits in their video editing programs, they are fine.  There is no need to convert these to webm because they are download only.

From developer documentation:
‘video-3g’	480x270, 200kbps, h264 codec, mp4 container.
‘video-sd’	640x360, 560kbps, h264 codec, mp4 container.
‘video-sdplus’	960x540, 1650kbps, h264 codec, mp4 container.

3g proxies are deployed: a little grainy, but good enough.


Update scio-core, scio-test to 0.14.0-dev1

About this PR
📦 Updates

com.spotify:scio-core
com.spotify:scio-test

from 0.10.4 to 0.14.0-dev1
📜 GitHub Release Notes - Version Diff
Usage
✅ Please merge!
I'll automatically update this PR to resolve conflicts as long as you don't change it yourself.
If you'd like to skip this version, you can just close this PR. If you have any feedback, just mention me in the comments below.
Configure Scala Steward for your repository with a .scala-steward.conf file.
Have a fantastic day writing Scala!

⚙ Adjust future updates
Add this to your .scala-steward.conf file to ignore future updates of this dependency:
updates.ignore = [ { groupId = "com.spotify" } ]

Or, add this to slow down future updates of this dependency:
dependencyOverrides = [{
  pullRequests = { frequency = "30 days" },
  dependency = { groupId = "com.spotify" }
}]

labels: library-update, early-semver-major, semver-spec-minor, commit-count:1

Superseded by #289.


option to not run query by default with Select Top 1000

Issue Type: Feature Request
I use "Select Top 1000" and "Edit Data" a lot in ADS.  However, the amount of times that I want the results of the default query that ADS gives me is about 1% of the time.
This means that the database has been queried needlessly 99% of the time I am using ADS. if there was an option in the configuration to not send the default query command when I select these options, I would definitely enable that option.
I would like to request some configuration option (because I know not everybody will want to enable it) to turn off the sending of these default queries. If this configuration option is enabled, then I would be able to "Select Top 1000" or "Edit Data" and the query editor would come up with the query, but the query would not have been sent to the server yet. This gives me a chance to edit the query the way that I need to and then run the query when I am ready.
Azure Data Studio version: azuredatastudio 1.15.1 (83544eba2504f564d785534cc780d2073feec2cc, 2020-02-15T05:03:16.545Z)
OS version: Windows_NT x64 10.0.18363

Closing - duplicate of #4043