MacOS and time machine

When time machine runs on the couchdb data folder the compaction failed and couchdb shutdown:
I added couch_log to see why, this gives me the path "/Volumes/Time"!!!!!:
abs_path(Path0) ->
    couch_log:debug("-------------------- abs_path ~p", [Path0]),
    {ok, Info} = file:read_link_info(Path0),
    case Info#file_info.type of
        symlink ->
            {ok, Path} = file:read_link(Path0),
            abs_path(Path);
        _ ->
            abs_path2(Path0)
    end.

and gives:
[debug] 2017-08-01T08:24:39.917976Z couchdb@localhost <0.2442.0> -------- Supervisor couch_secondary_services started couch_compaction_daemon:start_link() at pid <0.2682.0>
[debug] 2017-08-01T08:24:39.926015Z couchdb@localhost <0.2684.0> -------- Fragmentation for database `_dbs` is 0%, estimated space for compaction is 28864 bytes.
[debug] 2017-08-01T08:24:39.926312Z couchdb@localhost <0.2684.0> -------- Fragmentation for database `_nodes` is 0%, estimated space for compaction is 8372 bytes.
[debug] 2017-08-01T08:24:39.926747Z couchdb@localhost <0.2684.0> -------- Fragmentation for database `_replicator` is 0%, estimated space for compaction is 8378 bytes.
[debug] 2017-08-01T08:24:39.927227Z couchdb@localhost <0.2684.0> -------- Fragmentation for view group `_replicator` (database `_replicator`) is 0%, estimated space for compaction is 51 bytes.
[debug] 2017-08-01T08:24:39.927522Z couchdb@localhost <0.2684.0> -------- Fragmentation for database `_users` is 0%, estimated space for compaction is 8378 bytes.
[debug] 2017-08-01T08:24:39.927944Z couchdb@localhost <0.2684.0> -------- Fragmentation for view group `_auth` (database `_users`) is 0%, estimated space for compaction is 51 bytes.
[debug] 2017-08-01T08:24:39.928793Z couchdb@localhost <0.2684.0> -------- Fragmentation for database `shards/00000000-1fffffff/_global_changes.1501572189` is 98%, estimated space for compaction is 13246 bytes.
[debug] 2017-08-01T08:24:39.928851Z couchdb@localhost <0.2684.0> -------- -------------------- abs_path "./data"
[debug] 2017-08-01T08:24:39.928991Z couchdb@localhost <0.2684.0> -------- -------------------- abs_path "/Volumes/Time"
[error] 2017-08-01T08:24:39.929252Z couchdb@localhost emulator -------- Error in process <0.2684.0> on node couchdb@localhost with exit value:
{{badmatch,{error,enoent}},[{couch_compaction_daemon,abs_path,1,[{file,"src/couch_compaction_daemon.erl"},{line,527}]},{couch_compaction_daemon,free_space_rec,2,[{file,"src/couch_compaction_daemon.erl"},{line,517}]},{couch_compaction_daemon,can_db_compact,2,[{file,"src/couch_compaction_daemon.erl"},{line,327}]},{couch_compaction_daemon,maybe_compact_db,3,[{file,"src/couch_compaction_daemon.erl"},{line,164}]},{couch_compaction_daemon,'-compact_loop/1-fun-0-',3,[{file,"src/couch_compaction_daemon.erl"},{line,141}]},{couch_server,'-all_databases/2-fun-0-',4,[{file,"src/couch_server.erl"},{line,273}]},{filelib,do_fold_files2,8,[{file,"filelib.erl"},{line,185}]},{filelib,do_fold_files2,8,[{file,"filelib.erl"},{line,195}]}]}

Can you please provide which version of CouchDB you are using, your local.ini file, the path to where you installed CouchDB? Thanks.

I build it with the latest master(10 hours ago): couch-2.1.0-RC1-4-gf8cb6f97c
Path is rel/couchdb where it is after make release
local.ini:

; CouchDB Configuration Settings
; Custom settings should be made in this file. They will override settings
; in default.ini, but unlike changes made to default.ini, this file won't be
; overwritten on server upgrade.
[couchdb]
;max_document_size =<PHONE_NUMBER> ; bytes
;os_process_timeout = 5000
uuid = 039e269bb0d0bec878ad366eb24b37b1
[couch_peruser]
; If enabled, couch_peruser ensures that a private per-user database
; exists for each document in _users. These databases are writable only
; by the corresponding user. Databases are in the following form:
; userdb-{hex encoded username}
;enable = true
; If set to true and a user is deleted, the respective database gets
; deleted as well.
;delete_dbs = true
[chttpd]
port = 5983
;bind_address = <IP_ADDRESS>
; Options for the MochiWeb HTTP server.
;server_options = [{backlog, 128}, {acceptor_pool_size, 16}]
; For more socket options, consult Erlang's module 'inet' man page.
;socket_options = [{recbuf, 262144}, {sndbuf, 262144}, {nodelay, true}]
bind_address = <IP_ADDRESS>
require_valid_user = true
proxy_use_secret = true
authentication_handler =
authentication_handlers = {chttpd_auth, cookie_authentication_handler}, {chttpd_auth, default_authentication_handler},{couch_httpd_auth, proxy_authentication_handler}
[httpd]
port = 5982
; NOTE that this only configures the "backend" node-local port, not the
; "frontend" clustered port. You probably don't want to change anything in
; this section.
; Uncomment next line to trigger basic-auth popup on unauthorized requests.
;WWW-Authenticate = Basic realm="administrator"
; Uncomment next line to set the configuration modification whitelist. Only
; whitelisted values may be changed via the /_config URLs. To allow the admin
; to change this value over HTTP, remember to include {httpd,config_whitelist}
; itself. Excluding it from the list would require editing this file to update
; the whitelist.
;config_whitelist = [{httpd,config_whitelist}, {log,level}, {etc,etc}]
authentication_handlers = {couch_httpd_auth, cookie_authentication_handler}, {couch_httpd_auth, default_authentication_handler},{couch_httpd_auth, proxy_authentication_handler}
[query_servers]
;nodejs = /usr/local/bin/couchjs-node /path/to/couchdb/share/server/main.js
[httpd_global_handlers]
;_google = {couch_httpd_proxy, handle_proxy_req, <<"http://www.google.com">>}
[couch_httpd_auth]
; If you set this to true, you should also uncomment the WWW-Authenticate line
; above. If you don't configure a WWW-Authenticate header, CouchDB will send
; Basic realm="server" in order to prevent you getting logged out.
; require_valid_user = false
secret = 59edb32b73e57cda6be862966548e535
require_valid_user = true
proxy_use_secret = true
[os_daemons]
; For any commands listed here, CouchDB will attempt to ensure that
; the process remains alive. Daemons should monitor their environment
; to know when to exit. This can most easily be accomplished by exiting
; when stdin is closed.
;foo = /path/to/command -with args
[daemons]
; enable SSL support by uncommenting the following line and supply the PEM's below.
; the default ssl port CouchDB listens on is 6984
; httpsd = {chttpd, start_link, [https]}
[ssl]
;cert_file = /full/path/to/server_cert.pem
;key_file = /full/path/to/server_key.pem
;password = somepassword
; set to true to validate peer certificates
;verify_ssl_certificates = false
; Set to true to fail if the client does not send a certificate. Only used if verify_ssl_certificates is true.
;fail_if_no_peer_cert = false
; Path to file containing PEM encoded CA certificates (trusted
; certificates used for verifying a peer certificate). May be omitted if
; you do not want to verify the peer.
;cacert_file = /full/path/to/cacertf
; The verification fun (optional) if not specified, the default
; verification fun will be used.
;verify_fun = {Module, VerifyFun}
; maximum peer certificate depth
;ssl_certificate_max_depth = 1
;
; Reject renegotiations that do not live up to RFC 5746.
;secure_renegotiate = true
; The cipher suites that should be supported.
; Can be specified in erlang format "{ecdhe_ecdsa,aes_128_cbc,sha256}"
; or in OpenSSL format "ECDHE-ECDSA-AES128-SHA256".
;ciphers = ["ECDHE-ECDSA-AES128-SHA256", "ECDHE-ECDSA-AES128-SHA"]
; The SSL/TLS versions to support
;tls_versions = [tlsv1, 'tlsv1.1', 'tlsv1.2']
; To enable Virtual Hosts in CouchDB, add a vhost = path directive. All requests to
; the Virual Host will be redirected to the path. In the example below all requests
; to http://example.com/ are redirected to /database.
; If you run CouchDB on a specific port, include the port number in the vhost:
; example.com:5984 = /database
[vhosts]
;example.com = /database/
[update_notification]
;unique notifier name=/full/path/to/exe -with "cmd line arg"
; To create an admin account uncomment the '[admins]' section below and add a
; line in the format 'username = password'. When you next start CouchDB, it
; will change the password to a hash (so that your passwords don't linger
; around in plain-text files). You can add more admin accounts with more
; 'username = password' lines. Don't forget to restart CouchDB after
; changing this.
[admins]
;admin = mysecretpassword
admin = -pbkdf2-516d1745da6a942e0075ce147bd8fbee59143d56,93424e9d5f2013197d02b47acdd18e29,10
[cluster]
n = 1
[native_query_servers]
erlang = {couch_native_process, start_link, []}
[vendor]
[log]
level = debug
[compactions]
data = [{db_fragmentation, "70%"}, {view_fragmentation, "60%"}, {from, "23:00"}, {to, "04:00"}]
client = [{db_fragmentation, "70%"}, {view_fragmentation, "60%"}, {from, "23:00"}, {to, "04:00"}]
chat = [{db_fragmentation, "70%"}, {view_fragmentation, "60%"}, {from, "23:00"}, {to, "04:00"}]
[replicator]
max_replication_retry_count = infinity

Here is my temporarily workaround!
abs_path(Path0) ->
% if we get an error use abs_path2
case file:read_link_info(Path0) of
{ok, Info} -> case Info#file_info.type of
symlink ->
{ok, Path} = file:read_link(Path0),
abs_path(Path);
_ ->
abs_path2(Path0)
end;
{error,_Reason} -> abs_path2(Path0)
end.

The ini doesn’t sure the database_dir and view_index_dir directives.

in fact, can you dump /_node/<name>/_config here as well. And share ps ax | grep beam.

Dirs from default.ini:
database_dir = ./data
view_index_dir = ./data

single node therefore no /_node/...

77462 s006  S+   153:01.58 /Users/obi458/devel/couchdb_latest/rel/dev1/couchdb/bin/../erts-8.3/bin/beam.smp -K true -A 16 -Bd -- -root /Users/obi458/devel/couchdb_latest/rel/dev1/couchdb/bin/.. -progname couchdb -- -home /Users/obi458 -- -boot /Users/obi458/devel/couchdb_latest/rel/dev1/couchdb/bin/../releases/2.1.0/couchdb -name<EMAIL_ADDRESS>-setcookie monster -kernel error_logger silent -sasl sasl_error_logger false -noshell -noinput -config /Users/obi458/devel/couchdb_latest/rel/dev1/couchdb/bin/../releases/2.1.0/sys.config

I guess this is a race, race between get_disk_data() and free_space_rec(abs_path(Path), DiskData) cause
get_disk_data()(From Help): The function is asynchronous in the sense that it does not invoke a disk check, but returns the latest available value.
file:read_link_info(Name): Name must exists!!

Hint, just called:
18> os_mon:call(disksup, get_disk_data, infinity).
[{"/",3033388032,38},{"/Volumes/Time",2927833480,100}]
19> file:read_link_info("/Volumes/Time").
{error,enoent}

You say "single node therefore no /_node" but that's not true. There is always a /_node/<name>@<host>/_config endpoint. Check your vm.args file for the node's default name; it's something like<EMAIL_ADDRESS>or noname@nohost.

Can not find<EMAIL_ADDRESS>what does it mean absolute relative path or something else, i don't know?

OK, you mean http://...
Here:
{"native_query_servers":{"erlang":"{couch_native_process, start_link, []}","query":"{mango_native_proc, start_link, []}"},"httpd_design_handlers":{"_compact":"{couch_mrview_http, handle_compact_req}","_info":"{couch_mrview_http, handle_info_req}","_list":"{couch_mrview_show, handle_view_list_req}","_rewrite":"{couch_httpd_rewrite, handle_rewrite_req}","_show":"{couch_mrview_show, handle_doc_show_req}","_update":"{couch_mrview_show, handle_doc_update_req}","_view":"{couch_mrview_http, handle_view_req}","_view_changes":"{couch_mrview_http, handle_view_changes_req}"},"uuids":{"algorithm":"sequential","max_count":"1000"},"cluster":{"n":"1","q":"8"},"cors":{"credentials":"false"},"chttpd":{"authentication_handlers":"{chttpd_auth, cookie_authentication_handler}, {chttpd_auth, default_authentication_handler},{couch_httpd_auth, proxy_authentication_handler}","backlog":"512","bind_address":"<IP_ADDRESS>","docroot":"./share/www","port":"5983","proxy_use_secret":"true","require_valid_user":"true","socket_options":"[{recbuf, 262144}, {sndbuf, 262144}, {nodelay, true}]"},"httpd_global_handlers":{"/":"{couch_httpd_misc_handlers, handle_welcome_req, <<"Welcome">>}","_active_tasks":"{couch_httpd_misc_handlers, handle_task_status_req}","_all_dbs":"{couch_httpd_misc_handlers, handle_all_dbs_req}","_config":"{couch_httpd_misc_handlers, handle_config_req}","_plugins":"{couch_plugins_httpd, handle_req}","_replicate":"{couch_replicator_httpd, handle_req}","_restart":"{couch_httpd_misc_handlers, handle_restart_req}","_session":"{couch_httpd_auth, handle_session_req}","_stats":"{couch_stats_httpd, handle_stats_req}","_system":"{chttpd_misc, handle_system_req}","_utils":"{couch_httpd_misc_handlers, handle_utils_dir_req, "./share/www"}","_uuids":"{couch_httpd_misc_handlers, handle_uuids_req}","favicon.ico":"{couch_httpd_misc_handlers, handle_favicon_req, "./share/www"}"},"attachments":{"compressible_types":"text/*, application/javascript, application/json, application/xml","compression_level":"8"},"admins":{"admin":"-pbkdf2-e2f272537f56b0254d1397e37425d73f94cd3979,7a54c5ca3cb97898aba94a4e689a4eaf,10"},"query_server_config":{"os_process_limit":"100","reduce_limit":"true"},"vendor":{"name":"The Apache Software Foundation"},"replicator":{"connection_timeout":"30000","http_connections":"20","interval":"60000","max_churn":"20","max_jobs":"500","max_replication_retry_count":"infinity","retries_per_request":"10","socket_options":"[{keepalive, true}, {nodelay, false}]","ssl_certificate_max_depth":"3","startup_jitter":"5000","verify_ssl_certificates":"false","worker_batch_size":"500","worker_processes":"4"},"ssl":{"port":"6984"},"log":{"level":"error","writer":"stderr"},"indexers":{"couch_mrview":"true"},"view_compaction":{"keyvalue_buffer_size":"2097152"},"query_servers":{"coffeescript":"./bin/couchjs ./share/server/main-coffee.js","javascript":"./bin/couchjs ./share/server/main.js"},"features":{"scheduler":"true"},"daemons":{"auth_cache":"{couch_auth_cache, start_link, []}","compaction_daemon":"{couch_compaction_daemon, start_link, []}","couch_peruser":"{couch_peruser, start_link, []}","external_manager":"{couch_external_manager, start_link, []}","httpd":"{couch_httpd, start_link, []}","index_server":"{couch_index_server, start_link, []}","os_daemons":"{couch_os_daemons, start_link, []}","query_servers":"{couch_proc_manager, start_link, []}","uuids":"{couch_uuids, start, []}","vhosts":"{couch_httpd_vhost, start_link, []}"},"couch_peruser":{"delete_dbs":"false","enable":"false"},"httpd":{"allow_jsonp":"false","authentication_handlers":"{couch_httpd_auth, cookie_authentication_handler}, {couch_httpd_auth, default_authentication_handler},{couch_httpd_auth, proxy_authentication_handler}","bind_address":"<IP_ADDRESS>","default_handler":"{couch_httpd_db, handle_request}","enable_cors":"false","enable_xframe_options":"false","max_http_request_size":"67108864","port":"5982","secure_rewrites":"true","socket_options":"[{recbuf, 262144}, {sndbuf, 262144}]","vhost_global_handlers":"_utils, _uuids, _session, _users"},"httpd_db_handlers":{"_all_docs":"{couch_mrview_http, handle_all_docs_req}","_changes":"{couch_httpd_db, handle_db_changes_req}","_compact":"{couch_httpd_db, handle_compact_req}","_design":"{couch_httpd_db, handle_design_req}","_design_docs":"{couch_mrview_http, handle_design_docs_req}","_local_docs":"{couch_mrview_http, handle_local_docs_req}","_temp_view":"{couch_mrview_http, handle_temp_view_req}","_view_cleanup":"{couch_mrview_http, handle_cleanup_req}"},"database_compaction":{"checkpoint_after":"5242880","doc_buffer_size":"524288"},"csp":{"enable":"true"},"couch_httpd_auth":{"allow_persistent_cookies":"false","auth_cache_size":"50","authentication_db":"_users","authentication_redirect":"/_utils/session.html","iterations":"10","proxy_use_secret":"true","require_valid_user":"true","secret":"59edb32b73e57cda6be862966548e535","timeout":"600"},"couchdb":{"attachment_stream_buffer_size":"4096","changes_doc_ids_optimization_threshold":"100","database_dir":"./data","default_security":"admin_local","delayed_commits":"false","file_compression":"snappy","max_dbs_open":"500","os_process_timeout":"5000","uuid":"039e269bb0d0bec878ad366eb24b37b1","view_index_dir":"./data"},"compactions":{"_default":"[{db_fragmentation, "70%"}, {view_fragmentation, "60%"}]","bi_chat":"[{db_fragmentation, "70%"}, {view_fragmentation, "60%"}, {from, "23:00"}, {to, "04:00"}]","bi_client_info":"[{db_fragmentation, "70%"}, {view_fragmentation, "60%"}, {from, "23:00"}, {to, "04:00"}]","bi_data":"[{db_fragmentation, "70%"}, {view_fragmentation, "60%"}, {from, "23:00"}, {to, "04:00"}]","chat":"[{db_fragmentation, "70%"}, {view_fragmentation, "60%"}, {from, "23:00"}, {to, "04:00"}]","client":"[{db_fragmentation, "70%"}, {view_fragmentation, "60%"}, {from, "23:00"}, {to, "04:00"}]","data":"[{db_fragmentation, "70%"}, {view_fragmentation, "60%"}, {from, "23:00"}, {to, "04:00"}]"},"compaction_daemon":{"check_interval":"300","min_file_size":"131072"}}

maybe it’s the disk space monitor tripping up on volume paths with spaces in them? Do you get the error when the TM volume is not mounted?

TM with spaces, yes: /Volumes/Time Machine Backups/
No error if not mounted, TM mounts every 1 hour, for backups, therefore each 1 hour couchdb goes down

For those watching this issue, we have 2 workarounds right now:

Disable Time Machine on your Mac
Disable the compaction daemon in CouchDB

We'll be looking at this issue in closer detail in the coming days.

I may be having the same issue, as I'm on a Mac and use Time Machine (I also use Arq to backup to the cloud, which covers this directory).
The issue I was having was my CouchDB would randomly start spitting errors over and over that look like this: https://gist.github.com/SCdF/9994ca2afdc727bd39270eaa97abe422
[error] 2017-08-31T08:58:09.717403Z couchdb@localhost emulator -------- Error in process <0.253.0> on node 'couchdb@localhost' with exit value: {{badmatch,{error,enoent}},[{couch_compaction_daemon,abs_path,1,[{file,"src/couch_compaction_daemon.erl"},{line,526}]},{couch_compaction_daemon,free_space_rec,2,[{file,"src/couch_compaction_daemon.erl"},{line,517}]},{couch_compaction_daemon...
[error] 2017-08-31T08:58:09.718157Z couchdb@localhost <0.251.0> -------- gen_server couch_compaction_daemon terminated with reason: {compaction_loop_died,{{badmatch,{error,enoent}},[{couch_compaction_daemon,abs_path,1,[{file,"src/couch_compaction_daemon.erl"},{line,526}]},{couch_compaction_daemon,free_space_rec,2,[{file,"src/couch_compaction_daemon.erl"},{line,517}]},{couch_compaction_daemon,can_db_compact,2,[{file,"src/couch_compaction_daemon.erl"},{line,327}]},{couch_compaction_daemon,maybe_compact_db,3,[{file,"src/couch_compaction_daemon.erl"},{line,164}]},{couch_compaction_daemon,'-compact_loop/1-fun-0-',3,[{file,"s..."},...]},...]}}
  last msg: {'EXIT',<0.253.0>,{{badmatch,{error,enoent}},[{couch_compaction_daemon,abs_path,1,[{file,"src/couch_compaction_daemon.erl"},{line,526}]},{couch_compaction_daemon,free_space_rec,2,[{file,"src/couch_compaction_daemon.erl"},{line,517}]},{couch_compaction_daemon,can_db_compact,2,[{file,"src/couch_compaction_daemon.erl"},{line,327}]},{couch_compaction_daemon,maybe_compact_db,3,[{file,"src/couch_compaction_daemon.erl"},{line,164}]},{couch_compaction_daemon,'-compact_loop/1-fun-0-',3,[{file,"src/couch_compaction_daemon.erl"},{line,141}]},{couch_server,'-all_databases/2-fun-0-',4,[{file,"src/couch_server.erl"},{line,273}]},{filelib,do_fold_files2,8,[{file,"filelib.erl"},{line,184}]},{filelib,do_fold_files2,8,[{file,"filelib.erl"},{line,194}]}]}}
     state: {state,<0.253.0>,[]}
[error] 2017-08-31T08:58:09.718506Z couchdb@localhost <0.251.0> -------- CRASH REPORT Process couch_compaction_daemon (<0.251.0>) with 0 neighbors exited with reason: {compaction_loop_died,{{badmatch,{error,enoent}},[{couch_compaction_daemon,abs_path,1,[{file,"src/couch_compaction_daemon.erl"},{line,526}]},{couch_compaction_daemon,free_space_rec,2,[{file,"src/couch_compaction_daemon.erl"},{line,517}]},{couch_compaction_daemon,can_db_compact,2,[{file,"src/couch_compaction_daemon.erl"},{line,327}]},{couch_compaction_daemon,maybe_compact_db,3,[{file,"src/couch_compaction_daemon.erl"},{line,164}]},{couch_compaction_daemon,'-compact_loop/1-fun-0-',3,[{file,"s..."},...]},...]}} at gen_server:terminate/7(line:804) <= proc_lib:init_p_do_apply/3(line:237); initial_call: {couch_compaction_daemon,init,['Argument__1']}, ancestors: [couch_secondary_services,couch_sup,<0.201.0>], messages: [], links: [<0.210.0>], dictionary: [], trap_exit: true, status: running, heap_size: 987, stack_size: 27, reductions: 2819
[error] 2017-08-31T08:58:09.718956Z couchdb@localhost <0.210.0> -------- Supervisor couch_secondary_services had child compaction_daemon started with couch_compaction_daemon:start_link() at <0.251.0> exit with reason {compaction_loop_died,{{badmatch,{error,enoent}},[{couch_compaction_daemon,abs_path,1,[{file,"src/couch_compaction_daemon.erl"},{line,526}]},{couch_compaction_daemon,free_space_rec,2,[{file,"src/couch_compaction_daemon.erl"},{line,517}]},{couch_compaction_daemon,can_db_compact,2,[{file,"src/couch_compaction_daemon.erl"},{line,327}]},{couch_compaction_daemon,maybe_compact_db,3,[{file,"src/couch_compaction_daemon.erl"},{line,164}]},{couch_compaction_daemon,'-compact_loop/1-fun-0-',3,[{file,"s..."},...]},...]}} in context child_terminated

The only way I could find to fix it was basically delete all shard data and re-configure CouchDB.

Though if we think it's because of devices mounted with spaces in them, then while I don't have that problem with Time Machine, I do have the Recovery HD mounted by default for some reason:
$ ll /Volumes/
total 8
lrwxr-xr-x   1 root  wheel    1 24 Aug 14:01 Burrich -> /
drwxrwxr-x+ 22 root  wheel  816 29 Aug 18:07 External
drwxrwxrwx   0 root  wheel    0 31 Aug 14:56 MobileBackups
drwxr-xr-x   9 root  wheel  374 24 Aug 14:00 Recovery HD
drwxrwxr-x  14 root  wheel  544  1 Jul 19:36 TimeMachine

Ejecting Recovery HD has tentatively fixed the problem for me. I'll report back if that changes.
Is there a reason CouchDB checks for disk space on mounts other than the one it's on?

I ran into a similar issue recently which turned out to be caused by https://bugs.erlang.org/browse/ERL-343.

I ran also into this same problem. I downloaded CouchDB 2.1.0 (2017-08-07) for Mac from the CouchDB Website.
My Time Machine is also every 1 hour active for doing the backups ... in this time the CouchDB is not available and crashes.
[error] 2017-09-07T10:08:59.894213Z couchdb@localhost emulator -------- Error in process <0.2586.0> on node 'couchdb@localhost' with exit value: {{badmatch,{error,enoent}},[{couch_compaction_daemon,abs_path,1,[{file,"src/couch_compaction_daemon.erl"},{line,526}]},{couch_compaction_daemon,free_space_rec,2,[{file,"src/couch_compaction_daemon.erl"},{line,517}]},{couch_compaction_daemon...
[error] 2017-09-07T10:08:59.894478Z couchdb@localhost <0.2584.0> -------- gen_server couch_compaction_daemon terminated with reason: {compaction_loop_died,{{badmatch,{error,enoent}},[{couch_compaction_daemon,abs_path,1,[{file,"src/couch_compaction_daemon.erl"},{line,526}]},{couch_compaction_daemon,free_space_rec,2,[{file,"src/couch_compaction_daemon.erl"},{line,517}]},{couch_compaction_daemon,can_db_compact,2,[{file,"src/couch_compaction_daemon.erl"},{line,327}]},{couch_compaction_daemon,maybe_compact_db,3,[{file,"src/couch_compaction_daemon.erl"},{line,164}]},{couch_compaction_daemon,'-compact_loop/1-fun-0-',3,[{file,"s..."},...]},...]}}
last msg: {'EXIT',<0.2586.0>,{{badmatch,{error,enoent}},[{couch_compaction_daemon,abs_path,1,[{file,"src/couch_compaction_daemon.erl"},{line,526}]},{couch_compaction_daemon,free_space_rec,2,[{file,"src/couch_compaction_daemon.erl"},{line,517}]},{couch_compaction_daemon,can_db_compact,2,[{file,"src/couch_compaction_daemon.erl"},{line,327}]},{couch_compaction_daemon,maybe_compact_db,3,[{file,"src/couch_compaction_daemon.erl"},{line,164}]},{couch_compaction_daemon,'-compact_loop/1-fun-0-',3,[{file,"src/couch_compaction_daemon.erl"},{line,141}]},{couch_server,'-all_databases/2-fun-0-',4,[{file,"src/couch_server.erl"},{line,273}]},{filelib,do_fold_files2,8,[{file,"filelib.erl"},{line,184}]},{filelib,do_fold_files2,8,[{file,"filelib.erl"},{line,194}]}]}}
state: {state,<0.2586.0>,[]}

When will this issue be fixed?

@kinesias The issue is fixed, on 11 Sep. There just hasn't been a CouchDB release yet that includes this fix.
I gave you a workaround for now in the other ticket you commented on.
Spamming our issue tracker actually makes the release process take longer. Please be patient.

Did this issue exist in <IP_ADDRESS>? I am seeing the same problem when running CouchDB <IP_ADDRESS> in a native Windows Docker container with the data directory mounted as a volume into the container.

@drnybble It's a bug in Erlang 19 (will be fixed in Erlang 21) and any CouchDB version prior to 2.1.1 will be susceptible, I think. The fix is to use Erlang 18 or disable the compaction daemon.

@willholley Hmmm, seems that the Windows build of CouchDB is using Erlang 18, so perhaps this is a different problem.

 This is an unsupported configuration for us, but if you can work out what's wrong, good luck.

Sadly updating to 2.1.1 did not fix the issue on Windows.
[error] 2017-11-08T20:48:53.087000Z couchdb@localhost <0.31522.0> -------- gen_server couch_compaction_daemon terminated with reason: {compaction_loop_died,{{badmatch,{error,enoent}},[{couch_compaction_daemon,abs_path,1,[{file,"src/couch_compacti
on_daemon.erl"},{line,538}]},{couch_compaction_daemon,free_space,1,[{file,"src/couch_compaction_daemon.erl"},{line,512}]},{couch_compaction_daemon,can_db_compact,2,[{file,"src/couch_compaction_daemon.erl"},{line,327}]},{couch_compaction_daemon,ma
ybe_compact_db,3,[{file,"src/couch_compaction_daemon.erl"},{line,164}]},{couch_compaction_daemon,'-compact_loop/1-fun-0-',3,[{file,"src/c..."},...]},...]}}
  last msg: {'EXIT',<0.31524.0>,{{badmatch,{error,enoent}},[{couch_compaction_daemon,abs_path,1,[{file,"src/couch_compaction_daemon.erl"},{line,538}]},{couch_compaction_daemon,free_space,1,[{file,"src/couch_compaction_daemon.erl"},{line,512}]},{c
ouch_compaction_daemon,can_db_compact,2,[{file,"src/couch_compaction_daemon.erl"},{line,327}]},{couch_compaction_daemon,maybe_compact_db,3,[{file,"src/couch_compaction_daemon.erl"},{line,164}]},{couch_compaction_daemon,'-compact_loop/1-fun-0-',3,
[{file,"src/couch_compaction_daemon.erl"},{line,141}]},{couch_server,'-all_databases/2-fun-0-',4,[{file,"src/couch_server.erl"},{line,278}]},{filelib,do_fold_files2,8,[{file,"filelib.erl"},{line,185}]},{filelib,do_fold_files2,8,[{file,"filelib.er
l"},{line,195}]}]}}
     state: {state,<0.31524.0>,[]}

As stated in the Windows installer, you must install CouchDB to a path with no spaces and use no spaces in your data directory. We don't have any workaround for this problem at this time.

I don't believe this problem is related to spaces with paths -- I don't see any spaces.
Unfortunately I don't see anything that stands out as an error in Process Monitor when the error occurs.


Added doctest unit test framework

This uses doctest to implement unit testing for the core of godot.

This includes the following:

a very quick test runner of a single test by running the godot executable.
the third party library with license file (MIT) and appropriate documentation in the third party folder.
modifications to SCSub file to make tests part of main executable as linking tests statically can be hard (need a second opinion on this approach too)

Benefits

horrible regressions which we don't want to come back can have unit tests!
Simple to use (https://github.com/godotengine/godot/pull/40148/files#diff-b3c825b8305cec3713d66729d1efcd90)
No boilerplate
headless or non headless possibility
CI integration (https://github.com/onqtam/doctest/blob/master/doc/markdown/reporters.md)

has all the weird and wonderful reporters for various CI tools
CI can be run with headless tests like for string, basis and math checks we do not require a renderer.

Less files
follows KISS principle and supports a lot of other useful features https://blog.jetbrains.com/rscpp/better-ways-testing-with-doctest/
less code per test (because you don't need to copy paste a test harness)

Current test runner can be executed by running ./bin/godot.x11.tools.64 --test string, or by specific test name
Demo with ./godot --test argument

Demo with backward compatibility with other core tests --test math

Articles of supporting info:

https://github.com/onqtam/doctest/blob/master/doc/markdown/benchmarks.md
https://blog.jetbrains.com/rscpp/better-ways-testing-with-doctest/

#30743 - updated doctest for 4.0 fixed conflicts

Current test runner can be executed by running ./bin/godot.x11.tools.64 --test doctest

How would future tests be handled? Would it be --test doctest as an entry point to run all tests, or can we keep using --test string instead, as it's not particularly relevant what framework is used when calling the test?
Once this is merged, I think we should port all other tests to doctest and document the workflow.

Some style issues: https://travis-ci.org/github/godotengine/godot/jobs/705243011
Also make sure to use braces around single-line if or for blocks.
You lost some of @aaronfranke's changes in test_string while rebasing, so it fails building on Clang: https://travis-ci.org/github/godotengine/godot/jobs/705243015
(Be sure to keep the MinGW-specific hack too.)

@akien-mga I have applied the requested changes, but made a slight improvement to the mingw specific section.
I used PRId64 to correct this issue as it handles the platform specific issue here for us, but I need to test this on mingw, so will do this in a bit and if it works would it be okay to keep this?
The fix is based on https://stackoverflow.com/questions/9225567/how-to-print-a-int64-t-type-in-c this article, just so we don't have to duplicate code or do extra casting

Current test runner can be executed by running ./bin/godot.x11.tools.64 --test doctest

How would future tests be handled? Would it be --test doctest as an entry point to run all tests, or can we keep using --test string instead, as it's not particularly relevant what framework is used when calling the test?
Once this is merged, I think we should port all other tests to doctest and document the workflow.

I will write a quick fix for this now, to make it so

OK all points raised should now be sorted, I expanded the run functionality to make it more usable for regression testing too, it's super simple lets you run whatever specific test you would like too, also leaves legacy compatibility in.
demo gif

@aaronfranke can you possibly take a look at the fix I applied here, I think it could be simpler for godot to use this instead, it should remove the need for the preprocessor.
https://github.com/godotengine/godot/pull/40148/commits/1cd932db36a31c1464222bf15086ea9638750040
reference: https://stackoverflow.com/questions/9225567/how-to-print-a-int64-t-type-in-c

After some thought, I think we need to approach testing differently a little.
Our test code should run the 'FIXUP' startup logic if required, and the test_main() needs to start a particular thing it should do it.
Every test like string, basis and fbx can run without the engine running, but only runs the engine due to the startup code.
I believe we should make main(argc,argv) run tests and decouple it entirely from the engine startup logic.
It's going to be much more obvious and allow us to pass arguments in a much simpler way while also giving us the benefit of just running the tests you specify, or all the tests. and also allowing you to supply doctest arguments.
I believe ./godot.linuxbsd.tools --test should override all arguments supplied and pass the rest to doctest's handler.

OK so windows main is fixed, and Linux unit tests are fixed, MacOS unit tests also run.
The system now uses a define to 'inject' before Godot's real main logic, but this is the most elegant approach we can have. I have implemented the 'real raw basics' required to initialize the engine singleton OS properly, and this seems to satisfy the engine enough to run tests heedlessly, and the good thing is the CI is running them too, for each editor build it will run 'unit tests' step, I want to have these as a 'stage' under checks, for now though we can't save binaries, so this is the only option right now.
Android and iOS need looked into, as I didn't really have time to do this.

You need to run clang-format (and squash): https://github.com/godotengine/godot/pull/40148/checks?check_run_id=891900765
And also rebase on master to get the javascript CI fix.

Updated runner to take real arguments, but need to see how portable this solution is
./godot --test --help will return the help for doctest itself now, as I resolved a bug with the wchar_t conversion to char

Fixed portability of the strcpy its now strncpy since this is safer

Ran some more tests and it seems to be functioning normally now and the platform issues seem to be resolved, formatting should be correct.

Nice work, I'll try to test it today.
@vnen @faless You might want to take a look, and see if you like the new format to write some tests for GDScript and networking respectively.

Nice work, I'll try to test it today.
@vnen @Faless You might want to take a look, and see if you like the new format to write some tests for GDScript and networking respectively.

I had to remove the legacy tests unfortunately so we need to port them

I had to remove the legacy tests unfortunately so we need to port them

That's fine, I don't think there was much to salvage in most legacy tests in the first place.
It's better to start cleanly with the new framework, and then port and modernize the tests which were up-to-date enough with the Godot API (like hashmaps and AStar tests).

That's fine, I don't think there was much to salvage in most legacy tests in the first place.
It's better to start cleanly with the new framework, and then port and modernize the tests which were up-to-date enough with the Godot API (like hashmaps and AStar tests).

Cool, so I left the real files in main/tests/ but they do nothing at the moment to clarify that I didn't remove the actual files, just the legacy test runner, so whoever ports them its simpler, I will try to help with this effort and get them across but need to do this after merge, basis, fbx and math will probably be the ones I port after merge

Possibly we need some system for measuring the code coverage later on too.

Needs a rebase after #40556.

Needs a rebase after #40556.

Done, I ensured no extra whitespace.

For Devs:
To use the unit testing PR you can include the header from thirdparty/doctest/doctest.h it's single header only.
In order to make sure your test is built, once you write your test include the header for it in main/tests/test_main.cpp this ensures it is built as part of the same static linkage to godot's test harness.
To run tests you can use ./godot --test after running this will mean that you no longer can use godot's arguments, you must now use doctest arguments.
The basics:
TEST_CASE("some regression test") {
    CHECK(something_worked());
}

Reference guide
https://github.com/onqtam/doctest
Things which wont work
// by design errors a check should be a SINGULAR check.
CHECK(something && something_else);
CHECK(something || something_else);

Thanks a ton!

--test needs to be added to the --help page. Currently  --help | grep test returns nothing.

@aaronfranke I can see it at the end of the text returned by --help:
--test [--help]                  Run unit tests. Use --test --help for more information.

Yes, this was done in #40832, the old tests are inaccessible but are still there, but some of those are resurrected now: #41355. See preliminary documentation about tests and those additional test tools in godotengine/godot-docs#4017.


The 255th number returned by RandomNumericSequenceGenerator is always 255.

I found something else while investigating #407
[Fact]
public void The255thDrawIsAlways255()
{
    // Fixture setup
    var dummyContext = new DelegatingSpecimenContext();
    var sut = new RandomNumericSequenceGenerator(1, 255);
    // Exercise system
    var result = Enumerable
        .Range(0, 256)
        .Select(_ => sut.Create(typeof(long), dummyContext))
        .Cast<long>()
        .ToList();
    // Verify outcome
    Assert.Equal(255, result[254]);
    // Teardown
}

First, notice that GetNextRandom method in RandomNumericSequenceGenerator uses this.random.Next((int)this.lower, (int)this.upper), the upper bound in Random.Next being exclusive - the first 254 will be drawn between 1 and 254.
Next, in the EvaluateRange method, notice that the count check is done on this.upper - this.lower.
private void EvaluateRange()
{
    if (this.count == (this.upper - this.lower))
    {
        this.count = 0;
        this.CreateRange();
    }

    this.count++;
}

When comes the 255th draw, the count is 254 and upper = 255 and lower = 1, so the if is entered, and count is reset and the CreateRange method is called.
private void CreateRange()
{
    var remaining = this.limits.Where(x => x > this.upper - 1).ToArray();
    if (remaining.Any() && this.numbers.Any())
    {
        this.lower = this.upper;
        this.upper = remaining.Min() + 1;
    }
    else
    {
        this.lower = limits[0];
        this.upper = limits[1];
    }

    this.numbers.Clear();
}

The remaining variable will hold only one element: 255 (since it's bigger than upper (255) - 1) and numbers has 254 elements, so the if is entered.
In there, lower is set to upper (255) and upper is set to the minimum in remaining + 1 (256).
Next call to Random.Next will be with 255 and 256, so it'll always be 255.
I think this only happens with the initial lower and upper limits, but I have to check: I will investiage more when time permits. It seems it was discussed in #148 but I didn't have time to read the full discussion yet.

After reading #148, I can that this issue was raised in the past but that no decision was taken on the upper limit being inclusive or exclusive.
However, the current behaviour is not consistent with the "ideal" algorithm described here.

Thank you for reporting this!
Here's some QA that might help addressing this issue.
Does it make the algorithm more predictable?
I think it does. Should we care?
Does it result into test code that is less robust?
I think it doesn't.
Is it a bug, the fact that the 255th number is always the same.
Probably yes, although the guarantee is about the uniqueness, not the exact position. However if the 255th number is always the same, then it's a bug.

As explained in #148, this can actually be extrapolated to
[Theory]
[InlineData(10)]
[InlineData(42)]
[InlineData(255)]
[InlineData(14865)]
public void TheUpperLimitThDrawIsAlwaysUpperLimit(int upper)
{
    // Fixture setup
    var dummyContext = new DelegatingSpecimenContext();
    var sut = new RandomNumericSequenceGenerator(1, upper);
    // Exercise system
    var result = Enumerable
        .Range(0, upper + 1)
        .Select(_ => sut.Create(typeof(long), dummyContext))
        .Cast<long>()
        .ToList();
    // Verify outcome
    Assert.Equal(upper, result[upper - 1]);
    // Teardown
}

Should we care?
I'm not sure. I guess nobody is using AutoFixture as their random number generator for cryptography related stuff :smile:
I think it's a bug according to the specs

Creates a sequence of random, unique, numbers starting at 1.

Since it can be predicted, it is not random.
I think it's a fun problem to think about, but fixing it is probably not going to make a difference, I believe.

Agreed :smiley:

Very thorough analysis, @Pvlerick :+1: I agree that this is a bug; I also think the point is well made that it may not be of the highest priority in terms of the main use case of AutoFixture. Still, it would be best to address it.


Update aws-java-sdk-core to 1.12.595

About this PR
📦 Updates com.amazonaws:aws-java-sdk-core from 1.12.459 to 1.12.595
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.amazonaws", artifactId = "aws-java-sdk-core" } ]

Or, add this to slow down future updates of this dependency:
dependencyOverrides = [{
  pullRequests = { frequency = "30 days" },
  dependency = { groupId = "com.amazonaws", artifactId = "aws-java-sdk-core" }
}]

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

Superseded by #668.


added 2 items in the perl section

Hi, I'm playing word train game. Please add a word at the end of the "wordlist.txt"
https://github.com/imyaman/kkeun-ma-rit-gi/


Make scope take an option hash

It currently takes a long list of ordered arguments, and sometimes some have to be passed in as nil to make it work. Using options would clean this up.

Any roadmap to get it kickstart :)

I do not have any plans of doing this, but would welcome a pull request, provided that it doesn't break backward compatibility.


How to connect camera to Raspberry Pi circuit?

I am ready with Raspberry PI board. I burned android things to Board. As per circuit diagram its really confusing. What will be the complete circuit diagram for Raspberry PI?

@AmlanDwivedy I'll look into getting a schematic specifically for the Pi. In the meantime, the circuit diagram indicates you need to connect to three pins on the Pi: a 3.3V power, a Ground reference, and a GPIO pin. DoorbellActivity expects you to connect to BCM21 for the GPIO.
Referring to our pinout diagram for the Raspberry Pi, there are two 3.3V pins (#1 and #17, use either one), several Ground pins, and  BCM21 is the bottom right (#40).


Tag 2.64.0 is absent in all buildbuddy images

So all latest charts failed with default images.

cc @iain-macdonald and @sluongng
We ran into some issues with a new docker version on this release - which probably explains the missing images.
We'll get this sorted out and ping this issue when it's fixed.

Thanks for the report, farcop! Like Siggi said, we ran into some issues with the 2.64.0 release. I went ahead and cut and pushed a new 2.65.0 release and verified that the container images were tagged and pushed to gcr correctly, so you should be able to use that one. Sorry for the inconvenience!


Chinese Characters Get Cut Off When Using Italics and Background in RichText on Flutter Web

Steps to reproduce
Description:
When using RichText in Flutter Web to render Chinese characters with italic style and a background color, the width of the characters gets cut off. This issue seems to be caused by incorrect width calculations when applying italic fonts, especially for non-Latin scripts like Chinese.
Steps to Reproduce:
Create a RichText or Text widget.
Apply FontStyle.italic in TextStyle.
Set a background color using backgroundColor in TextStyle.
Render the text with Chinese characters on a Flutter Web application.
RichText(
text: TextSpan(
text: '中文示例',
style: TextStyle(
fontStyle: FontStyle.italic,
backgroundColor: Colors.yellow, // Background color
),
),
)
Actual results
Chinese characters should be displayed completely, without any truncation, even when using italic style and background color.
Bug  the width of the Chinese characters is cut off, resulting in incomplete rendering of the text.
Logs

Logs

<!-- Paste your logs here -->

Flutter Doctor output
[√] Flutter (Channel stable, 3.22.3, on Microsoft Windows [版本 10.0.22631.4317], locale zh-CN)
• Flutter version 3.22.3 on channel stable
• Upstream repository https://github.com/flutter/flutter.git
• Framework revision b0850beeb2 (3 months ago), 2024-07-16 21:43:41 -0700
• Engine revision 235db911ba
• Dart version 3.4.4
• DevTools version 2.34.3

This is not specific to Chinese text. This is also being tracked in https://github.com/flutter/flutter/issues/151404
Kindly subscribe to the original issue for updates.
Closing from here as duplicate.
Thank you


feature: component-class-suffix give a list of possible suffixes

Hello,
In our project we use several Suffix for our component depending if they are Component or Simple View (so we use Component and View suffix).
It could be great to propose a list of possible suffix for component-class-suffix.
I have already done some code and ready to do a PR if you think that can be a good idea to add this.
"component-class-suffix": [true, "Component", "View"]

Pierre

Hey @pierre-hilt, we already had a discussion about this. I'm not confident how good idea is it because we're going in a different direction from the official style guide. In the same time we're only expanding the set of features without preventing developers align their codebase to best practices.
I'd love to get a PR with this functionality.

#195

I see that is not compliant with Angular best practices. But I will need to disable completely the rule in my project without this feature.


I18n support

Hi,
I'm looking forward to using this in an upcoming project, but need to support multiple languages. Is there a way to do this out of the box or would it require some work in the code? It seems the community is leaning towards gettext and po files.

I believe it will require a little work. Probably just the Action names, error messages, and the JS messages.

Okay. Let me try and see.
On Mon, May 30, 2016 at 11:00 PM Steve Pallen<EMAIL_ADDRESS>wrote:

I believe it will require a little work. Probably just the Action names,
error messages, and the JS messages.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/smpallen99/ex_admin/issues/136#issuecomment-222510096,
or mute the thread
https://github.com/notifications/unsubscribe/AABGE0pB00a_2QhTcDOEG6gZbELFCSO7ks5qGvuWgaJpZM4Ipl0r
.

@smpallen99 can you assign to me?

@HangingClowns I believe I can only assign issues to core contributors. But no problem. I'll make sure now one tries to start it. I look forward to reviewing your pull request.


Bug: docutils license is not parsed as BSD

Bug

[x] I have read the comment above and have completed each step
[x] I have filled out the system info
[x] I have described the bug, filled in the expected outcome and the actual
outcome including screenshots where appropriate

System info

OS: Linux LAPTOP-VQJVCNH4 <IP_ADDRESS>-microsoft-standard-WSL2
Version: 2023.1.1

Describe the bug
The theme project depends directly on docutils (it's the base of every sphinx related stuff) and it raises an incompatibility issue as it's not identified correctly.
Expected outcome
list of packages
┏━━━━━━━━━━━━┳━━━━━━━━━━━━━━━━━━━━━━━┳━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┓
┃ Compatible ┃ Package               ┃ License(s)                              ┃
┡━━━━━━━━━━━━╇━━━━━━━━━━━━━━━━━━━━━━━╇━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┩
│ ✔          │ docutils              │ BSD License                             │
└────────────┴───────────────────────┴─────────────────────────────────────────┘

Actual outcome
list of packages
┏━━━━━━━━━━━━┳━━━━━━━━━━━━━━━━━━━━━━━┳━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┓
┃ Compatible ┃ Package               ┃ License(s)                              ┃
┡━━━━━━━━━━━━╇━━━━━━━━━━━━━━━━━━━━━━━╇━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┩
│ ✖          │ docutils              │ BSD License;; GNU General Public        │
│            │                       │ License (GPL);; Python Software         │
│            │                       │ Foundation License;; Public Domain      │
└────────────┴───────────────────────┴─────────────────────────────────────────┘

This is intended behaviour as licensecheck may use pypi.org to discover the metadata https://pypi.org/project/docutils/#data or the local package metadata
The license is

License: BSD License, GNU General Public License (GPL), Python Software Foundation License, Public Domain (public domain, Python, 2-Clause BSD, GPL 3 (see COPYING.txt))

Probably best to open this with docutils to get some more clarity on what license they are actually under (may be that pypi.org needs updating)

I checked the referenced copying.txt: https://sourceforge.net/p/docutils/code/HEAD/tree/trunk/docutils/COPYING.txt#l146 and it seems they made a very good work at gathering all the licences of the project ence the complex references. Pypi is accepting this structure as well (LicenseA;; Licence B;; ...), so nothing we can do there.
I opened a ticket on their side but I doubt they will accept to change anything (https://sourceforge.net/p/docutils/bugs/469/) as they embed multiple levels of Licensing.
Then let's change path, would it be possible to ignore a dependeçy ?

user could get rid of poorly set licenses (like docutils)
as it's a manual change user will keep control over what is ignored and not (play at your own risk)

[tools.licensecheck]
ignore=["docutils"]

What would you think ?


Reimplement packing test using wasmi

@NikVolf can you describe this one a bit more?

https://github.com/paritytech/wasm-utils/pull/48/files
there were test which used deprecates interpreter from parity-wasm
worth to restore it using wasmi or completely rework in some other way


Flutter gallery regression on kernel type information missing

With https://github.com/flutter/flutter/commit/541afae45b10a764e46d176ea249c4dc122eb557 Flutter gallery example works fine without kernel, but fails on assert with kernel on seemingly missing type information
[ +236 ms] I/flutter (30542): localizations dynamic, ()
[        ] I/flutter (30542): localizations dynamic, (dynamic)
[  +30 ms] I/flutter (30542): ══╡ EXCEPTION CAUGHT BY WIDGETS LIBRARY
...
[        ] I/flutter (30542): When the exception was thrown, this was the stack:
[  +84 ms] I/flutter (30542): #0      _AssertionError._doThrowNew (dart:core)
[        ] I/flutter (30542): #1      _AssertionError._throwNew (dart:core:2848:5)
[        ] I/flutter (30542): #2      _loadAll (package:flutter/src/widgets/localizations.dart)
[        ] I/flutter (30542): #3      _LocalizationsState.load (package:flutter/src/widgets/localizations.dart:363:62)
[        ] I/flutter (30542): #4      _LocalizationsState.initState (package:flutter/src/widgets/localizations.dart:328:5)

That is with
 print('localizations $type, ${output.keys}');

added to _loadAll before   assert(!output.containsKey(type)); .
It shows that without kernel before and after change types are as expected
[  +92 ms] I/flutter (30059): localizations WidgetsLocalizations, ()
[        ] I/flutter (30059): localizations MaterialLocalizations, (WidgetsLocalizations)

but with kernel after the change types are all resolved to dynamic
[ +253 ms] I/flutter (29612): localizations dynamic, ()
[   +2 ms] I/flutter (29612): localizations dynamic, (dynamic)

@kmillikin  @sigmundch

It seems like newly introduced code relies on template argument type T being available at runtime.
Without kernel it is available, but with kernel it's only available as dynamic.
I don't think this is as expected, but not sure.
@peter-ahe-google @a-siva

Class types are reified at runtime in Dart 1.x (not requiring Kernel), that is:
class FooData extends LocalizationsDelegate<Foo> { ... }

FooData.type will return Foo in Dart 1.x.

Seems like there is an issue with type-variables and constants.
Here is a small repro of the problem:
class A<T> {
  const A();
  Type get type => T;
}

class B extends A<String>{
  const B();
}

main() {
  print(const B().type);
}

If you run it in the VM without the FE, this prints "String", with the FE, this prints "dynamic".

Note that doing new B().type instead of const B().type does print "String".

@mkustermann @jensjoha could you take a look at this? I think this may be a problem on the VM side.

indeed, @peter-ahe-google , the issue seems to be with kernel flow graph builder where https://github.com/dart-lang/sdk/blob/b460a25459fa261fac1c4c548bcf43c4e23a897f/runtime/vm/kernel_binary_flowgraph.cc#L5678 seems to exit const constructor invocation too soon.

You are in luck then, @jensjoha is much faster at fixing bugs than I am ;-)

Thanks all for troubleshooting this!

https://codereview.chromium.org/3007123002/.

Thanks, @jensjoha , it is indeed fixed!


Raster optimisations: clustering of elements

Personally I don't see a downside from this, and so don't see the need for an Execute option for it (though useful for the video example above). Users will just find that the burn takes less time.
Comments (if any) on the code to follow.

Personally I don't see a downside from this, and so don't see the need for an Execute option for it (though useful for the video example above). Users will just find that the burn takes less time.
Comments (if any) on the code to follow.

I am not tied to the specific algorithm and implementation I wrote for 0.7.x and I have no issues with the idea of a different algorithm and different code being written this time around.
However, a quick look at the code suggests that the algorithm is flawed. Because once a cluster is created it is never going to be merged with another cluster even if they overlap - and you can get different results with the same elements in different orders.
Imagine a square frame consisting of 8 slightly overlapping black-filled square boxes - 4 corners and 4 sides.
If the element order starts with a box and goes sequentially around the frame, you will end up with 1 cluster. However, if I read the code correctly...
If the element sequence is the 4 corners first and then the 4 sides (which means that the 4 side boxes are "on top" of the 4 corner boxes), the 4 corners (which do not overlap) will create 4 clusters, and then the sides will be added to the first cluster they overlap with. And you end up with 4 clusters and 4 images - images which overlap and will create a double burn. Or if the corner squares are black-filled, and the sides white-filled and on top, then you will probably get areas burned which should have been masked.
It should be possible to create two SVGs identical except having different element orders and see what happens in the simulation.
Regarding other changes of approach, from memory I think my old code was inserted into the blob phase (because that is where images are created from the raster elements), and this code runs earlier in the preprocess, so I suspect that the change to splitting the groups into separate ops which later get turned into separate images is not in principle going to be materially different from my original algorithm, and indeed because this change is entirely contained in this class and doesn't require changes in the as_cutobjects method of operations (which my code previously did), then it seems to be a better approach.

I think you are right, it needs reiterating the clusters and combining them if needed

It was a couple of years ago now, but I seem to recall that this was why I created single entry groups and then iterated to merge them rather than attempt to create merged groups from the start.

I would also suggest that you implement the advanced version (which iterates inside each group to double check overlap by individual rasters) whilst you are at it.

This should fully cover overlaps within a single raster operation - without any safety margin, so adjacent rectangles with a microscopic gap between them would still be burnt separately.
There's no check across multiple raster operations.

Additionally this isn't in any form or shape numpy optimised, but this example took just a few milliseconds:
[05:59:33]     Optimise op raster finished after 0.01 seconds, inflated 1 operations to 4

The cutplanning steps:
copy: moves the stuff over.
preprocess: figure out all the commands to be run and add everything to the .commands
validate: execute all those functions, just run each function there. (this would better be called process).
blob: convert everything to cutcode.
preopt: figure out all the commands to be run on the cutcode this time around, add that to .commands
optimize: execute all the preopt commands, just run each function there.
spool: send this whole thing to the spooler.

Yeah, I wouldn't really expect numpy to be that much help. I'm pretty sure even with thousands of objects it might still be remarkably fast. But, the current code is non-existing so you have it beat for a feature Sophist really wants back working. If I want to write a numpy-optimized section of it later that reduces the bounding box footprint (make groups out of sets of overlapping bounding boxes regardless of order to identify clusters) and takes even less time than very very little time, that could be written later.
I'm not sure group by by overlap is that useful outside of this functionality, or that this code is hard enough to warrant taking basically no time at all.

The somewhat confusing part was that if you linked 1 and 2 then linked 4 and 5. Then found a bounding box that linked 2 and 4, They all ended up in the same group. And did so without expanding the underlying bounding box.

If they were grouped but the overall bbox was not expanded, then that would have been a bug.

I will note that the technically correct method is actually to put the function of the optimize_rasters() into the self.commands they will all be executed during the process stage which executes all of that data.

If there is going to be a second PR to address my review comments, then I would suggest that this is included.


Is RoCm apex.amp deprecated & behavior mismatch vs NVIDIA APEX

Hi, I am wondering if RoCm apex.amp is deprecated? NVIDIA APEX has some deprecation warnings that are not present in this repo: https://github.com/NVIDIA/apex/pull/1506/files
Moreover, I realize that this code
import torch
import torch.nn as nn
from apex import amp

class MyModule(nn.Module):
    def __init__(self):
        super().__init__()
        self.lin = nn.Linear(3, 4)

    def forward(self, attn_probs, value_states):
        attn_output = torch.bmm(attn_probs, value_states)
        return attn_output

from torch.optim import AdamW

model = MyModule().to("cuda")
optimizer = AdamW(model.parameters())

model, optimizer = amp.initialize(model, optimizer, opt_level="O1")

attn_probs = torch.rand(4, 16, 16).to("cuda")
value_states = torch.rand(4, 16, 2).to(torch.float16).to("cuda")

attn_output = model(attn_probs, value_states)

runs fine with NVIDA APEX but fails on RoCm APEX with the following log:
Traceback (most recent call last):
  File "run_bmm.py", line 26, in <module>
    attn_output = model(attn_probs, value_states)
  File "/opt/conda/envs/py_3.8/lib/python3.8/site-packages/torch/nn/modules/module.py", line 1501, in _call_impl
    return forward_call(*args, **kwargs)
  File "run_bmm.py", line 11, in forward
    attn_output = torch.bmm(attn_probs, value_states)
RuntimeError: expected scalar type Half but found Float

However, using torch.cuda.amp.autocast instead works fine for both RoCm and CUDA-powered devices (with torch 2.0.1).
Thank you!

@fxmarty,
I believe the problem could be happening due to some missing fix in Adam optimizer handling in ROCm apex. Checking on it will get back.


[BUG]: type obtained with $inferInsert is empty

What version of drizzle-orm are you using?
0.32.0
What version of drizzle-kit are you using?
0.23.0
Describe the Bug
I defined a users table in my drizzle schema, and the NewUser type obtained with users.$inferInsert is empty:

Expected behavior
NewUser type should have most of the users table properties.
Environment & setup
Fedora Linux
node-postgres
typescript: 5.5.3

I have the same problem 0.32.0

I encountered the same issue in drizzle-orm version 0.32.0, which was resolved after downgrading to version 0.31.4

Could you please send a schema as code snippet, so I can test with it?

@xegulon Maybe explicitly setting autoincrement on id would help (even though it shouldn't be necessary)?
id: serial('id').autoincrement().primaryKey()
@AndriiSherman, I'm using MySQL and am facing the same/related issue. In my case $inferInsert returns [] when I use Composite Primary Key(on one field only, it has autoincrement), but I guess this is the intended behavior due to implementation complexities and unpractical use of Composite PK? Probably a doc update would suffice for this particular issue.
Important one:
$returningId also doesn't work with BigInts (returns regular ints), and when the value of the primary key exceeds Number.MAX_SAFE_INTEGER  Drizzle stops responding (but this might be a topic for another issue).  I provided reproducible examples with comments, I hope this helps:
Composite Primary Key issue:
`import {mysqlTable, bigint, primaryKey} from "drizzle-orm/mysql-core";
import {DB} from "../initDB.ts";
export const TestModel = mysqlTable("test", {
id: bigint("id", { mode: "number", unsigned: true }).autoincrement(),
}, (table) => {
return {
pk: primaryKey({ columns: [table.id] }),
}
});
export async function insertTest() {
let res = await DB.insert(TestModel).values({}).$returningId();
console.log('res', res);  // res []
}`
Works fine with Primary Key (regular):
`import {mysqlTable, bigint, primaryKey} from "drizzle-orm/mysql-core";
import {DB} from "../initDB.ts";
export const TestModel = mysqlTable("test", {
id: bigint("id", { mode: "number", unsigned: true }).autoincrement().primaryKey(),
});
export async function insertTest() {
let res = await DB.insert(TestModel).values({}).$returningId();
console.log('res', res);  // res [{id: 1}]
}
`
An issue with BigInts (note: mode is set to bigint):
`import {mysqlTable, bigint, primaryKey} from "drizzle-orm/mysql-core";
import {DB} from "../initDB.ts";
export const TestModel = mysqlTable("test", {
id: bigint("id", { mode: "bigint", unsigned: true }).autoincrement().primaryKey(),
}, (table) => {
return {
// pk: primaryKey({ columns: [table.id] }),
}
});
export async function insertTest() {
await DB.insert(TestModel).values({id: BigInt(Number.MAX_SAFE_INTEGER)});
// Here $returningId() doesn't even work, Drizzle stops responding.
// res[0].insertId will return either a string or a regular number (not BigInt), and at some point, as the primary key value grows, starts to return 'random' ints (expected behavior in JS, since numbers don't work with BigInts)
let res = await DB.insert(TestModel).values({});
console.log('res', res[0].insertId);  // returns a string or a regular js int instead of BigInt

}
`
Stack:

Bun
Typescript 5.5.3

Thank you very much!
Let me know if you need anything else.

Could you please send a schema as code snippet, so I can test with it?

import {type InferInsertModel} from 'drizzle-orm';
import {pgTable} from 'drizzle-orm/pg-core';

const Users = pgTable('users', {
  id: serial('id').primaryKey(),
  firstName: text('first_name'),
  lastName: text('last_name'),
  email: text('email'),
});

type NewUserType = InferInsertModel<typeof Users>;

@AndriiSherman the type of NewUserType would be an empty object

Could you please send a schema as code snippet, so I can test with it?

@AndriiSherman
import {
  serial,
  text,
  timestamp,
  pgTable,
  boolean,
  pgEnum,
} from 'drizzle-orm/pg-core';

export const roleEnum = pgEnum('role', ['admin', 'student']);

export const users = pgTable('user', {
  id: serial('id').primaryKey(),
  emailValidated: boolean('email_validated').default(false),
  email: text('email').unique('user_email_unique'),
  firstName: text('first_name'),
  lastName: text('last_name'),
  password: text('password'),
  role: roleEnum('role').default('student'),
  createdAt: timestamp('created_at'),
  updatedAt: timestamp('updated_at'),
});

export type User = typeof users.$inferSelect;

export type NewUser = typeof users.$inferInsert;

Is there an intermediate solution for this other than reducing drizzle-orm version ?

I'm having this issue and then some:

$inferInsert only provides fields that are notNull() or generated by default
$inferSelect does not respect nullability of fields and the type has every field as required

Also on 0.32.0 orm & 0.23.0 kit

I'm trying to add examples for @xegulon and @davieoba to the type tests. I can confirm that I see all the types properly. There might be an issue with the TypeScript setup. Could you share your tsconfig files and TypeScript version so I can reproduce the issue properly?

Sure!
tsconfig below, typescript is version ^5.3.3
{
  "compilerOptions": {
    "outDir": "dist",
    "incremental": true,
    "target": "es2017",
    "module": "commonjs",
    "strict": true,
    "esModuleInterop": true,
    "skipLibCheck": true,
    "forceConsistentCasingInFileNames": true,
    "noImplicitReturns": true,
    "noUnusedLocals": false,
    "noImplicitAny": false,
    "sourceMap": true,
    "lib": ["ESNext"],
    "strictNullChecks": false,
    "inlineSources": true,

    // Set `sourceRoot` to  "/" to strip the build path prefix
    // from generated source code references.
    // This improves issue grouping in Sentry.
    "sourceRoot": "/"
  },
  "compileOnSave": true,
  "include": ["src"]
}

Sure, here it is:
{
  "compilerOptions": {
    "module": "commonjs",
    "declaration": true,
    "removeComments": true,
    "emitDecoratorMetadata": true,
    "experimentalDecorators": true,
    "allowSyntheticDefaultImports": true,
    "target": "ES2021",
    "sourceMap": true,
    "outDir": "./dist",
    "baseUrl": "./",
    "incremental": true,
    "skipLibCheck": true,
    "strictNullChecks": false,
    "noImplicitAny": false,
    "strictBindCallApply": false,
    "forceConsistentCasingInFileNames": false,
    "noFallthroughCasesInSwitch": false
  }
}

And "typescript": "5.5.3".

oh you didn't ask for mine lol sorry. but i have exactly the same issue and there's my setup anyway

Is there an intermediate solution for this other than reducing drizzle-orm version ?

Defining your insert type manually can be a solution maybe?

Agreed. Defining the insert types manually and declaring any type while inserting/updating the records.
db.insert(users).values(userObj as any)
db.update(users).set(userObj as any)

I'm having this issue and then some:
* `$inferInsert` only provides fields that are `notNull()` or generated by default

* `$inferSelect` does not respect nullability of fields and the type has every field as required

Also on 0.32.0 orm & 0.23.0 kit

Hi! I have the same issue described here, and I have a feeling that this is a problem coming from TS, because it's not only affecting drizzle but also affecting others libraries inferring types like elysiajs. The main thing to note is that the issue appeared after I migrated to a NX monorepo. Now, my TS config is split between multiple files that are extending and referencing each others. I tried downgrading TS or drizzle, but the issue is still here.
I will try to make a reproduction repo.

Once I put strict: true in TS config it infers properly... this might be another type of issue that you get when dealing with types null on a codebase that doesn't care about nulls... I'm lucky the codebase is small and I can enable strict stuff, others might not be 😞

It looks like a problem with excluding generated columns without TS strict checking.
https://github.com/drizzle-team/drizzle-orm/blob/main/drizzle-orm/src/operations.ts#L11

@Grohden even with strict: true, I have the same problem.

I'm having this issue and then some:
* `$inferInsert` only provides fields that are `notNull()` or generated by default

* `$inferSelect` does not respect nullability of fields and the type has every field as required

Also on 0.32.0 orm & 0.23.0 kit

Hi! I have the same issue described here, and I have a feeling that this is a problem coming from TS, because it's not only affecting drizzle but also affecting others libraries inferring types like elysiajs. The main thing to note is that the issue appeared after I migrated to a NX monorepo. Now, my TS config is split between multiple files that are extending and referencing each others. I tried downgrading TS or drizzle, but the issue is still here. I will try to make a reproduction repo.

I'm having this issue and then some:
* `$inferInsert` only provides fields that are `notNull()` or generated by default

* `$inferSelect` does not respect nullability of fields and the type has every field as required

Also on 0.32.0 orm & 0.23.0 kit

Hi! I have the same issue described here, and I have a feeling that this is a problem coming from TS, because it's not only affecting drizzle but also affecting others libraries inferring types like elysiajs. The main thing to note is that the issue appeared after I migrated to a NX monorepo. Now, my TS config is split between multiple files that are extending and referencing each others. I tried downgrading TS or drizzle, but the issue is still here. I will try to make a reproduction repo.

Oh, you my hero)
I use something like
`type InferModel<T extends { $inferInsert: any; $inferSelect: any }> =
| T['$inferInsert']
| T['$inferSelect'];
const newUsers: InferModel = {};`

@xegulon did you try strict + strictNullChecks?

is there any solution for this issue?

@Grohden yes I tried, same problem

@xegulon did you try strict + strictNullChecks?

I am having the same issue as well

@AndriiSherman  @Angelelz The issue affecting $inferSelect looks to be the evaluation of OptionalKeyOnly type.
It looks to me like the discriminator evaluating the GeneratedType (recent addition) is expecting to find
T['_']['generated']['type'] as the constant type byDefault a lot more than it is.
For me, I'm consistently seeing the T['_']['generated']['type'] as 'always' | 'byDefault'.
This is the code:
https://github.com/drizzle-team/drizzle-orm/blob/90c4788980ab56c52da8504ef4fad9159c4113b0/drizzle-orm/src/operations.ts#L16-L22
I've modified part of the test from
T['_']['generated']['type'] extends 'byDefault' ? TKey : never

to
T['_']['generated']['type'] extends 'always' ? never: TKey

This seems to be a workable workaround but I've not attempted to examine the broader "generated type" code. Your expertise would be appreciated.

Adding strictNullChecks true works for me too

@AndriiSherman Is strictNullChecks a requirement for Drizzle?

strictNullChecks fixes the type issue but breaks a lot of other code for me. I would be extremely happy about a fix for this. @danielsharvey got a very good finding for this.

Quite sure this is related: https://github.com/drizzle-team/drizzle-orm/issues/2694

I'm having this issue and then some:

$inferInsert only provides fields that are notNull() or generated by default
$inferSelect does not respect nullability of fields and the type has every field as required

Also on 0.32.0 orm & 0.23.0 kit

Only God knows why $inferSelect isn't the type used in the update function

just launching the idea for who might be thinking on fixing drizzle to not care about nulls depending on the flag:
type IsStrictNullEnabled = null extends number ? false : true

const a: IsStrictNullEnabled = true // will complain depending on the flag

ts will basically treat null as any when strict null is off, so you can just ask if null extends anything non any and if it it does, the flag is off

@AndriiSherman @Angelelz The issue affecting $inferSelect looks to be the evaluation of the OptionalKeyOnly type.影响 $inferSelect 的问题似乎是 OptionalKeyOnly 类型的评估。
It looks to me like the discriminator evaluating the GeneratedType type (recent addition) is expecting to find在我看来，评估 GeneratedType 类型（最近添加的）的鉴别器希望找到 T['_']['generated']['type'] as the constant type byDefault a lot more than it is.T['_']['generated']['type'] 作为常量类型 byDefault 的次数要多得多。
For me, I'm consistently seeing the T['_']['generated']['type'] as 'always' | 'byDefault'.对我来说，我一直看到 T['_']['generated']['type'] 是 'always' |'byDefault' 的
This is the code: 这是代码：
https://github.com/drizzle-team/drizzle-orm/blob/90c4788980ab56c52da8504ef4fad9159c4113b0/drizzle-orm/src/operations.ts#L16-L22
I've modified part of the test from我已从
T['_']['generated']['type'] extends 'byDefault' ? TKey : never

to 自
T['_']['generated']['type'] extends 'always' ? never: TKey

This seems to be a workable workaround (for me) but I've not attempted to examine the broader "generated type" code. Your expertise would be appreciated.这似乎是一种可行的解决方法（对我来说），但我还没有尝试检查更广泛的“生成类型”代码。您的专业知识将不胜感激。

does work

In tsconfig having strict properties set to true fixes this.
{
  "strict": true,
  "strictNullChecks": true
}

In tsconfig having strict properties set to true fixes this.
{
  "strict": true,
  "strictNullChecks": true
}

Well, in some code bases you just can’t. It shouldn’t be a prerequisite to properly use drizzle in my opinion.

In tsconfig having strict properties set to true fixes this.
{
  "strict": true,
  "strictNullChecks": true
}

Well, in some code bases you just can’t. It shouldn’t be a prerequisite to properly use drizzle in my opinion.

Can't agree more, this should be fixed at the lib level, should not depend on the external environment configuration.

should not be an issue on latest(drizzle-orm@0.38.0+), if it's still an issue - please reopen

For me the problem is still present even with latest version

I can confirm that this issue still exists as of
{
    "drizzle-orm": "0.38.2",
    "drizzle-kit": "0.30.1",
}


download stuck with no way to restart

Trying to download a course I purchased and got stuck at 73%. No way to continue download available

I have the same issue on a different course.
It is getting stuck downloading an attachment.
Vue JS 2 - The Complete Guide (incl. Vue Router & Vuex)
https://www.dropbox.com/s/zmuz88jdq2uefrq/Capture.PNG?dl=0

I have the same issue. Stuck at 72%, 9KB/s, Attachment.

Trying to download a course I purchased and got stuck at 73%. No way to continue download available

This can be fixed manually, by setting the "Start and End Download" in Setting menu. For example it stucks at 25thfile, then "Start Download" should be 26 or more, and "End Download" is the total files in this course, in your case is 33. Save the setting, then exit Udeler, then open it again and start the download.

@frenicohansen I confirm that this issue exists and it is indeed due to the attachment link not present on some course.  For now we can use the Lecture Start/End option to bypass this.
I had plans to fix this in v2 of Udeler, but unfortunately I got stuck with work from last few months and I hardly get any time to work on this. But I am hopeful in next couple of weeks I will be all set to work on v2 and release it as soon as I can and I am sure it will address most of the issues here.
And moreover I am not able to reply on each issue here, but I know once v2 is ready (hopefully very soon) then I can close all the issue as v2 will address almost all of them.


API for getting the gradients with respect to model parameters

Is there a way to get access to gradients with respect to a mechanism's model parameters like inertia, mass, and center of mass?

Yes there is a way to do this.
This file computes the the gradient of the residual wrt to the mechanism data = (previous state, control input, mass inertia, etc).
https://github.com/dojo-sim/Dojo.jl/blob/main/src/gradients/data.jl

then to get the gradient of the next state wrt to the mass, inertia. You'll need to implement something like get_maximal_gradients
https://github.com/dojo-sim/Dojo.jl/blob/main/src/gradients/state.jl
this means using the Iplicit function theorem i.e. computing d next_state/ d data = -d residual /d next_state ^-1 * d residual / d data

I can help you set this up if you want to work on this!

+1 on this as a desired feature. I'd be willing to help set it up in my spare time.


Correct Missing Type Annotations

resolves #3
submitted for review / comment

submitted with requested changes but forgot to retitle the commit


Can it have different secret to different scope?

I ask this question in stackoverflow, but I don't get an answer.
If a client allows the following scopes, can it have different secret for different scopes (e.g. secret1 for the "opened" and "profile" and secret2 for the "api2")?
"AllowedScopes": [ "openid", "profile", "api2" ],
I mean can it limit the client with secret1 to access the opened" and "profile" scope only, but not the "api2" scope and client with secret2 access the "api2" scope only? If not, what is the right way to achieve it?
From what I have read, the client secret is used to authorize access to the token endpoint. Client with secret1 or secret2 can create token of any of the allowed scopes.
From the IdentityServer doc, it says
This secret can now be assigned to either a Client or a Scope.
But I don't see the Scope class has the Secret field.
From IdentityServer3 doc, it has the ScopeSecrets.  Is it gone in IdenityServer4?
Should I use different client id (for the same application) to allow different scopes?

The docs had a bug -- it should be:
This secret can now be assigned to either a Client or a Scope.
I fixed it.

@brockallen You just type what the current doc has.  Do you mean it had bug and you had fixed it and the current one is correct?   In that case, how to assign secret to the Scope?
Can you also comment about if we can have the same client but different secrets for different scopes?

Sorry, I fixed my typo above. It should be ApiResource.

Do I understand correctly from this thread that it is not possible to give a single client access to different scopes or resources based on which client secret is used? Will I have to define a new client if I want to be able to access a different set scopes/resources?


Leading zero gets truncated in E164 for some German numbers

Country: Germany
Example number(s) and/or range(s): +49016000000001
Number type: mobile (M2M)
Where or whom did you get the number(s) from: I used to own such a number.
Authoritative evidence (e.g. national numbering plan, operator announcement):

Numbering plan for the numbering space for public telecommunications

A zero in brackets means that the zero is not part of the number but must be dialled before the number when calling from a line in Germany. When calling from another country the international prefix applicable in the country (frequently "00" as in Germany) and the country code for Germany (written as "+49") must be dialled instead of the zero.

Link from demo (http://libphonenumber.appspot.com) showing error: E.164 does not have leading zero.

@nogoegst,
Thank you for taking the time to improve libphonenumber!

When calling from another country the international prefix applicable in the country (frequently "00" as in Germany) and the country code for Germany (written as "+49") must be dialled instead of the zero.

As per section you are pointing to in the doc, the E.164 format should have +49 instead of 0. See the demo results are in line with that. See : https://libphonenumber.appspot.com/phonenumberparser?number=%2B49016000000001
When parsing the input number (i.e +49016000000001), 0 is trimmed off in order to successfully parse the number as in goo number of  cases the numbers are represented (like in online pages) in format +49 (0)<PHONE_NUMBER>1. This is to convey to users that national prefix 0 can also be used instead of country code when dialing within the country.
I'll close this as it's not an issue with the library. Please consider joining the discussion group if you'd like to discuss this further.


chore Refactor FunctionSet Initialization for Better Maintainability and Compilation Success

Proposed changes
Issue Number: close #xxx
In this PR, I have refactored the initialization of the FunctionSet. Previously, all the functions were in one large method which led to the generation of Java code that was too long. This posed a problem for the compiler, as the length of the method exceeded the limit imposed by the Java compiler.
To resolve this issue and improve the readability and manageability of our code, I have categorized these functions by type, and created dedicated initialization methods for each type. As such, our code is now not only more readable and understandable, but also each method is of a length that is acceptable to the compiler and can be compiled successfully.
Moreover, this change makes it easier for us to add new functions as we can directly locate the right category and add new functions there.
This is a significant change aimed at enhancing the maintainability and scalability of our code, while ensuring that our code can be successfully compiled.


🚀 [Feature Request] - Password field in mentor registration form

Is your feature request related to a problem ? Please describe. ✍
Mentor registration form should contain password and confirm password field which is not there  now
Describe briefly how you would implement this enhancement.
Add password field in mentor registration form

Additional context or screenshots
Additional context
Are you contributing for a program?
GSSoC2023
Code of Conduct

[X] I have read and agree to the Contributing Guidelines of this project.

This is currently in WIP. Actually we are redesigning it.


Support reading ctag file from tags option

Info

Operating System: Manjaro Linux
Shell: zsh
Terminal: GNOME Terminal
nvim --version: 0.8.1
fzf --version: 0.38.0 (352ea07)

Description
fzf-lua has a configuration option called ctags_file under the tags section which holds a path to a file generated by the ctags. This is an input file to the tags command which is used to search project tags.
While this works without any issues, the path is hard coded into the configuration of the fzf-lua. It would be beneficial if this is read from the Neovim tags option similar to how the original junegunn/fzf.vim does. It will make fzf-lua play nice with other Neovim plugins, like vim-gutentags, that are used to automatically generate tags file.
Seems like fzf-lua is the best Neovim plugin to integrate fzf and I would really love to use the fzf-lua in my setup, but this is the only blocker for me to do so.
A bit of more context as to why this is a deal breaker for me. I am using already mentioned vim-gutentags which provides me with the following:

I don't need to worry about ctags since vim-gutentags automatically generates tags file for me on every change that I do in the files.
I have configure it to not "pollute" a directory for each project and instead generate tags file in my $HOME.

The first point is without a doubt indispensable, but the second point is what is blocking me to use fzf-lua. While I can configure vim-gutentags to generate tags in each project directory (this is actually the default behavior) so that fzf-lua and vim-gutentags play nice, I really much prefer to generate the tags file in my $HOME instead. The problem with such configuration is that the name of the tags file is not static anymore, but rather dynamic (the name of the tags file depends on the project folder name). This obviously means that I can't use ctags_file configuration option to specify a file name. Fortunately, the vim-gutentags (once tags is generated) updates the tags Neovim option with the path to this generated ctags file. So, fzf-lua could actually read the tags option value and use it to open tags file.
I would really like your thoughts on this. I am aware that this is a feature request and probably would have a lower priority then the actual issues or maybe even with any other features you are doing or planning to do. It would be good to know that at least you are not against the feature. I am even open to implement this myself if this is OK for you.

I would really like your thoughts on this. I am aware that this is a feature request and probably would have a lower priority then the actual issues or maybe even with any other features you are doing or planning to do. It would be good to know that at least you are not against the feature. I am even open to implement this myself if this is OK for you.

Ty for the detailed request, I am not against this at all and I’m sure I can accommodate this pretty quick.
I’m not at the computer ATM, which option saves the tag file location?

I’m not at the computer ATM, which option saves the tag file location? Also would be helpful is an example of what the option contains (absolute path, relative? multiple paths?)

Just want to clarify that the tags option and tag functionality in general is part of the Neovim itself. It has nothing to do with the vim-gutentags. It allows user to easily jump all the places instead of a raw searching and hunting for the symbols. vim-gutentags just updates this option with the path to the tags file that it generated so that Neovim can use it to jump places. More about the tags is described in the help tags
Back to your question, Neovim calls this  tags option. It is described in the tags-option section in the Neovim documentation. See help tags-option for more details.

The 'tags' option is a list of file names.  Each of these files is searched
for the tag.  This can be used to use a different tags file than the default
file "tags".  It can also be used to access a common tags file.

tags option contains a list of files separated by comma. An example of tags option value:
:set tags=./tags,tags,/home/user/commontags

See below to give you more info on how my setup works where I use vim-gutentags.
I have a workspace folder which contains all my projects.
$ pwd
/opt/workspace

For example:
$ ll
total 24K
drwxr-xr-x 11 developer developer 4.0K Mar 25 08:04 fzf
drwxr-xr-x 28 developer developer  20K Mar 25 08:05 git

So if I want to work on fzf, I position myself into /opt/workspace/fzf and fire up Neovim which will trigger vim-gutentags to automatically generate tags file for the whole fzf project. The tags, as described in the description of this issue, will be generated in the $HOME folder:
$ ll ~/.cache/vim/ctags/opt-workspace-fzf-tags
-rw-r--r-- 1 developer developer 326K Mar 25 08:13 /home/developer/.cache/vim/ctags/opt-workspace-fzf-tags

Note the name of the tags file opt-workspace-fzf-tags in above listing. The name is a concatenation of the absolute path to the project folder with a dash separator and the project directory itself.
Back to the Neovim, If I now run set tags? I will get the following value:
tags=~/.cache/vim/ctags/opt-workspace-fzf-tags,./tags;,tags

But if I now switch to git project and run set tags? from Neovim I will get:
tags=~/.cache/vim/ctags/opt-workspace-git-tags,./tags;,tags

With such setup, Neovim will always open the right tags file and tag jumping will work as expected.

Tysm for the detailed explanation @hvarga.
One more question @hvargal, in your specific example let’s say for fzf, would it be enough to extract the tags from ~/.cache/vim/ctags/opt-workspace-fzf-tags or do you need to search tags in all 3 files ~/.cache/vim/ctags/opt-workspace-git-tags,./tags;,tags?
Does fzf.vim search the project specific generated file (the first file in tags), or all?

@hvarga, I looked at how fzf.vim does it, it uses the vim function getfiles() to get a list of resolved tag files.
https://github.com/ibhagwan/fzf-lua/commit/ba5950e884f89b58de287ca77a76bc8a92a5de1e - this commit removes the hardcoded tags file and uses the first exisiting file from the tagfiles() command and tags file (hardcoded) as last resort.
I looked into combining the results from all tagfiles but that requires a bigger change as the tags file relies on grep'ing the tags file (one file).
Try it and lmk if this if this solves your issue?

Wow, OK that was quick. I will try this during the day and let you know.

Wow, OK that was quick. I will try this during the day and let you know.

I'm usually faster, this took a day :-)

I am happy to report that your commit is working as expected.

commit removes the hardcoded tags file and uses the first exisiting file from the tagfiles() command and tags file (hardcoded) as last resort.

Good, this is what I as a user, would expect as well.

I looked into combining the results from all tagfiles but that requires a bigger change as the tags file relies on grep'ing the tags file (currently just one file).

No worries about that, at least if you ask me. I don't have a use case that requires "multi-stage" tags files.
I can finally integrate fzf-lua into my hvarga/tuosde-docker. Thanks for this @ibhagwan.

That’s great @hvarga, ty for the update!

@ibhagwan, seems like there is still some hard coded path to a tags file. By using "Regex Search" in the FzfLua tags view, the following error will be shown:
[Fzf-lua] Tags file ('tags') does not exist. Create one with ctags -R

The reason I haven't caught this earlier during the testing of your commit is that I haven't used the regex search.
Can you check this out as well?

Hi @hvarga,
I'm a bit confused where this is coming from, the tags_live_grep (and variants) code uses the exact same code path, there's only one line where hardcoded tags can come from (as fallback of last resort, line 59):
https://github.com/ibhagwan/fzf-lua/blob/11225b76a41ae59bd52307c64862e13b12de50ef/lua/fzf-lua/providers/tags.lua#L49-L60
I just ran mine with debug using :FzfLua tags_live_grep debug=true, you can see the underlying command does use the correct path:

Does this happen when you run tags_live_grep directly or when using ctrl-g to switch back and forth between fuzzy and regex (I tried both, mine seems to work)?

Does this happen when you run tags_live_grep directly or when using ctrl-g to switch back and forth between fuzzy and regex (I tried both, mine seems to work)?

No, not immediately when I run tags_live_grep. Only when I press ctrl-g. Unfortunately, adding debug=true to the command doesn't provide any additional observability. I still end up with only the:
[Fzf-lua] Tags file ('tags') does not exist. Create one with ctags -R

printed at the bottom of my Neovim.

Nope you're not missing anything, and the  messages is very clear, somehow your ctags_file still remains set to tags and given that it works without the ctrl-g I'm a struggling to find the source of this issue...
Pretty sure this isn't the issue but can you confirm your fzf-lua commit hash so we can rule this one out?

Also what happens when you start with tags_live_grep and then press ctrl-g does the same message still appears or can you switch to fuzzy mode?

Actually I think I figured out this issue, with your setup (most probably) calling tagfiles() from the float window returns the wrong (or not a valid tag file in the tags-option), https://github.com/ibhagwan/fzf-lua/commit/02bde5fae96772729004743f0f309c35c5182b83 - this commit stores the resolved ctags_file in between mode changes.
Can you updated to the latest commit and lmk if this solves your issue?

Yes, that did the trick - I can confirm that with your latest commit the switching between regex and fuzzy search now works as expected. Thanks again @ibhagwan for your support.

Hello all, my echo tagfiles() is ['.tags'], a hidden file with . prefix, vim.fn.expand(f) is nil.

prefix, vim.fn.expand(f) is nil.

What do you mean by this? I just tried :lua print(vim.fn.expand(".tags")) and it returns .tags as expected.

In my tests, print(vim.loop.fs_stat(vim.fn.expand('.tags'))) is nil, ENOENT: no such file or directory:  ENOENT

In my tests, print(vim.loop.fs_stat(vim.fn.expand('.tags'))) is nil, ENOENT: no such file or directory: ENOENT

How have you generated the tags?
Does .tags exist in your current directory?
What does :!ls .tags output?

:!ls .tags
.tags

.tags exist in project root.

Very confusing why does fs_stat fail…
Does print(vim.loop.fs_stat('.tags')) work (without expand)?
Does print(vim.loop.fs_stat('/full/path/to/.tags')) work (replace with your path)?

:lua print(vim.fn.expand('.tags')), nothing
:lua print(vim.loop.fs_stat('.tags')), table 0x01025330a0, vim.inspect prints the details
:lua print(vim.loop.fs_stat('/full/path/to/.tags')), works as expected

The main issue is vim.fn.expand('.tags') is nil, can you reproduce this?

:lua print(vim.fn.expand('/Users/fannheyward/.local/share/nvim/plugged/fzf-lua/.tags')), full path, still nothing

The main issue is vim.fn.expand('.tags') is nil, can you reproduce this?

Can’t reproduce, what neovim version are you using? Perhaps an upstream bug?

It seems the result is already expanded anyways, from :help tagfiles():
tagfiles()	Returns a |List| with the file names used to search for tags
		for the current buffer.  This is the 'tags' option expanded.

@ibhagwan sorry for the delay, https://github.com/ibhagwan/fzf-lua/commit/d49f79fbdaf5247ce694637555e8cd503f6fc05f works! Thank you for your work on fzf-lua!

Can’t reproduce, what neovim version are you using

I'm using NVIM v0.9.0-dev-3921+g84027f751


Fields are not noexcept-movable if Allocator is noexcept-movable

basic_fields should conditionally be noexcept movable to enable some container optimizations based on noexcept.

is this still relevant given the other pull request?

The scope changed a little, because I assumed that allocators didn't have to be noexcept-movable (they have to, according to the Allocator requirements).


Are you missing SaveUpdate in UserStore AddClaims,RemoveClaims?

Also in Remove/Add Roles a call to Context.Update(user) is missing.

I have the same question.
Some update are missing or the specific methods are only called from inside an open session which save the user?

The code should be the same as the EF provider. Please provide a repro if you think there's an issue.


how to rotate cell data?

Are you trying to rotate the actual cell text (text rotation) or trying to rotate the entire table (moving cells around / transposition)?

yeah i trying to rotate the actual cell text (text rotation)

yeah i trying to rotate the actual cell text (text rotation)

Did you do it ?
I have same problem

text rotation is a style feature included in our Pro Compendium and we cannot say when it will make its way to the open source


feat: ensure pdfs are in pdf/a-3a

Description
TBD

Some remaining issues with NotoSansSC:

I re-downloaded the TTF font files for Noto Sans Simplified Chinese, and the verification succeeded. These font files are much bigger, but I am not sure if that matters much as we embed a subset of the font into the pdf.

https://avepdf.com/pdfa-validation

https://www.pdf-online.com/osa/validate.aspx
reports an issue:

Foxit PDF Editor


Rename PAF, "Project approval form" to something more generic

Maybe to the generic the "Project form"?
This will make it more clear the form can be used for whatever is needed.

Some UI ideas we've talked about:

Have the information form data be displayed on the project landing page (so you don't have to click into the information)
Have the information entered at project creation as part of that dialog coming from the submission

We're less sure of the second one, as it puts up a potential barrier to someone creating projects, but it would be a nice user experience.