If it ok to update an expired SSL Certificate using Chef?

Hi Pavel:
Our SSL domain Certificate just expired.  We started to update certificates by hand for IIS, Portal (via portaladmin) and Server (via server/admin).
Can we just update by modifying the Chef json to point at the new certificate and password?
Would we need to define a cert_alias?
I noticed that our DEV Portal json used a cert_alias but I hadn't done that in the Test and Prod portals.
The default cert_alias is the FQDN of the host, correct?
So a new cert would probably need a different cert_alias in order to install without a conflict?
My SSL Cert knowledge is limited...
I tried doing this on our 10.4.1 Test Portal and it looks like it ran ok but thought I'd verify if this is an appropriate use of Chef
Appreciate all your work!

Hi Paul,
The certificate on IIS is updated if node['iis']['replace_https_binding'] attribute is set to true.
Chef does not upload/update SSL certificates on server and portal if the cert aliases of the installed certificates are equal to the aliases specified in the JSON file. The default alias for server is node['arcgis']['server']['domain_name'], for portal is node['arcgis']['portal']['domain_name'], and the default domain_name is FQDN of the host. So yes, you would need to change cert_alias attribute for server and portal.
Regards,
Pavel

Thanks Pavel....
I've run Chef with server, portal, etc... running before but it just occurred to me, should I be turning off those services before running Chef?

Stopping server and portal windows services is not required to update the SSL settings. There services must be running for the update to work (they will be started if they are in stopped state).

Once again, you've saved me a lot of work!
Setting the 'iis']['replace_https_binding'] attribute to true was useful.
I think it was renaming the cert_alias did the trick in some cases.


simulation of hdl_nvme_example: timeout writing into flash

With action=hdl_nvme_example, I am trying to write 4kB into flash with snap_cblk -n1 -t1 -b1 --write asc.in -v and get timeout after 3x60sec. CBLK_REQTIMEOUT is set to 60sec.
sim output is:
NVMe device has 209715200 blocks of each 4096 bytes; 819200 MiB (MAX 0xc800000 blocks) @ 1 threads
Writing NVMe from asc.in
[check_req_timeouts] err: req[ 0]: WRITING 60/61 sec LBA=0 TIMEOUT
[check_req_timeouts] err: req[ 0]: WRITING 60/61 sec LBA=0 TIMEOUT
[check_req_timeouts] err: req[ 0]: WRITING 60/62 sec LBA=0 TIMEOUT
The sim.log counts tags from 0 to 1f and gets the responses from PSLSE
I tried with fastest.parms (strict order, no PAGED, no extra R/W activity) and it still fails.
Has this ever been simulated ? If yes, what timeout do you expect ?
Do you need a data file with 4096B including or excluding the EOF ?
Results and AET are in /afs/bb/proj/fpga/framework/jkayser/snap_testlist_updates/hardware/sim/ies/20171211_174448

When running with SNAP_TRACE=0xF2, I get following msgs from snap_cblk:
R   hw_snap_mmio_read32(0x19b8010, f04c, 0) 0
R   hw_snap_mmio_read32(0x19b8010, f04c, 0) 0
R   hw_snap_mmio_read32(0x19b8010, f04c, 0) 0
R   hw_snap_mmio_read32(0x19b8010, f04c, 0) 0
R   hw_snap_mmio_read32(0x19b8010, f04c, 10) 0
B 0000469a.000046b3<PHONE_NUMBER>627618     [completion_status] HW WRITE_COMPLETED 00000010 slot: 0 LBA=0
B 0000469a.000046b3<PHONE_NUMBER>627630   [completion_thread] waking up slot 0 LBA=0
B 0000469a.000046b3<PHONE_NUMBER>628284 [completion_thread_cleanup] tid=18099 tidy up ...
B 0000469a.0000469a<PHONE_NUMBER>628352 [cblk_close] id=0 req_status=IDLE work_in_flight=0 now:<PHONE_NUMBER> sec 628346 usec ...
R   hw_snap_mmio_write64(0x19b8010, 1010, 2)
Formatting of 4096 bytes took 25775846 usec @ 0.000 MiB/sec
Here the simulation hangs, until I cancel snap_cblk.
Timeout values are not recognized.
Can you please investigate your MUTEX ?

please start investigating @ snap_cblk.c line 798, which produces the last trace msg:
printf(stdout, "Formatting of %lld bytes took %lld usec @ %.3f MiB/sec\n",
(long long)num_lba * lba_size, (long long)diff_usec, mib_sec);
This is followed by rqueue_init, which contains pthread_mutex_init....... any sign of deadlock ?

Formating should happen in --rw or in --format. Not in --write. When using --write you need to offer a file of the appropriate size. A block is 4KiB. So it needs exactly to be 4096 bytes (ls -l data.bin).
The code you mention is the --rw test. The mutex should not be problematic, it is used to determine the next block to read or write and each block is just read/written one time here. You have -n1 such that there should be only 1 block, with -t1 only one thread. Did you try something like -n16 yet?

The test pgm initializes with snap_nvme_init, and this runs fine
The error is in snap_cblk --format or snap_cblk --write, unrelated to the content of the input file
options="-n1 -t1"
for blk in 1 2;do p8=$((blk8)); p4k=$((blk4096));
echo "generate data for $blk blocks, $p8 pages, $p4k bytes"
step "snap_nvme_init -d0 -v"
step "snap_cblk $options -b${blk} --format --pattern INC -v"
step "snap_cblk $options -b${blk} --write asc.in         -v"
  done

The files are generated with
dd if=/dev/urandom of=rnd.in count=${p8} bs=512 2>/dev/null  # random data
head -c $p4k </dev/zero|tr '\0' 'x' >asc.in                                      # same char mult times

The blocksize for the snap_cblk application is not 512 bytes, but 4KiB. So we need bs=4096. Or is your  printout above not showing the * correctly?

Just talked to Sven, he said a brock write needs more than 3 min, so the timeout needs for sim e.g. to be 5min. He reviewed our code and found that this might be reduced a little bit by shifting the position in the code where we take the time for the timeout measurement. But I claim that this will not do more than increasing the overall timeout.
Here is what he suggested:
static void req_start(struct cblk_req *req, struct cblk_dev *c)
{
	uint8_t action_code = req->action & 0x00ff;
	int slot = req->slot;

	req->tries++;
	block_trace("    [%s] HW %s memcpy_%x(slot=%u dest=0x%llx, "
		"src=0x%llx n=%lld bytes) LBA=%ld attempts=%d\n",
		__func__, action_name[action_code % ACTION_CONFIG_MAX],
		req->action, slot, (long long)req->dst, (long long)req->src,
		(long long)req->size, req->lba, req->tries);

       /* Sven suggested to move the gettimeofday() calls to this position, since the simulator polls of the status register take a lot of time during the previous mmios which eats already quite an amount of timeout ticking */

	pthread_mutex_lock(&c->dev_lock);
	gettimeofday(&req->stime, NULL);
	gettimeofday(&req->h_stime, NULL);

	__cblk_write(c, ACTION_CONFIG,    req->action);
	__cblk_write(c, ACTION_DEST_LOW,  (uint32_t)(req->dst & 0xffffffff));
	__cblk_write(c, ACTION_DEST_HIGH, (uint32_t)(req->dst >> 32));
	__cblk_write(c, ACTION_SRC_LOW,   (uint32_t)(req->src & 0xffffffff));
	__cblk_write(c, ACTION_SRC_HIGH,  (uint32_t)(req->src >> 32));
	__cblk_write(c, ACTION_CNT,       req->size);

	/* Wait for Action to go back to Idle */
	snap_action_start(c->act);

	/*
	 * Update statistics under device lock.
	 * Otherwise it might be off a little bit.
	 */
	req->tries++;
	if (action_code == ACTION_CONFIG_COPY_HN) {
		c->hw_block_writes++;
		c->wbytes_total += req->size;
	} else {
		c->hw_block_reads++;
		c->rbytes_total += req->size;
	}

	pthread_mutex_unlock(&c->dev_lock);
}

I increased the timeout to 6min and started snap_cblk. It got stuck at the same place and hung for one hour, before I killed the app. Please advise

I checked if the real-world application works with the parameters you have set, to exclude of-by-one errors in the software.
haver@tul3eth3:~/snap/actions/hdl_nvme_example/sw$ time ./snap_cblk -C0 --format -b1 -n 0x1
NVMe device has 209715200 blocks of each 4096 bytes; 819200 MiB (MAX 0xc800000 blocks) @ 1 threads
Formatting NVMe drive 4 KiB with pattern ff ...
Formatting of 4096 bytes took 139 usec @ 29.468 MiB/sec

real	0m0.003s
user	0m0.000s
sys	0m0.000s

haver@tul3eth3:~/snap/actions/hdl_nvme_example/sw$ ./snap_cblk -n1 -t1 -b1 --format
NVMe device has 209715200 blocks of each 4096 bytes; 819200 MiB (MAX 0xc800000 blocks) @ 1 threads
Formatting NVMe drive 4 KiB with pattern ff ...
Formatting of 4096 bytes took 156 usec @ 26.256 MiB/sec

Mhm, well. It works there nicely.

Let us enable all the debugging with SNAP_TRACE=0xfff to see how far we come here. I am curious how much of the statistic printouts we get since those are done in the library destructor.

Tested again with branch=RC_hdl_nvme_fix and got the hang situation with SNAP_TRACE=0xFF
see /afs/bb/proj/fpga/framework/jkayser/snap_nvme/hardware/sim/ies/20171219_135525

http://bencane.com/2011/09/22/kill-creating-a-core-dump/
Can we automatically create a core dump by setting ulimits -c unlimited and sending a kill -3 $pid?
And at the same time set SNAP_TRACE=0xfff to get some more debug printout?

https://github.com/open-power/snap/tree/SIM_improve_thread_safety should fix the issue.

fixed and merged into master


Rewrite GsonSubType to allow for greater flexibility

Currently the @GsonSubType annotation is very restrictive (it only works with String, Ints and Booleans) you can also only use a single field to decide what the type should be.
This works well when it's a fairly standard type field in the json. However in the situations where there may be multiple fields in different combinations that decide what type should be used, @GsonSubType does not meet the requirements.
To do this via annotations would create a mess of annotations that are not understandable. Therefore the proposed solution is to completely rework the existing solution.
Instead of doing the following:
@GsonSubtype(
        subTypeKey = "type",
        stringValueSubtypes = {
                @GsonSubtype.StringValueSubtype(value = "type1", subtype = Type.Type1.class),
                @GsonSubtype.StringValueSubtype(value = "type2", subtype = Type.Type2.class),
                @GsonSubtype.StringValueSubtype(value = "type3", subtype = Type.Type3.class),
                @GsonSubtype.StringValueSubtype(value = GsonSubtype.StringValueSubtype.NULL_STRING, subtype = Type.TypeNull.class)
        }
)
public abstract class Type {
    String type;
    String name;

    @AutoGsonAdapter
    public static class Type1 extends Type {
        int intTest;
    }

    @AutoGsonAdapter
    public static class Type2 extends Type {
        double doubleTest;
    }

    @AutoGsonAdapter
    public static class Type3 extends Type {
        String stringTest;
    }

    @AutoGsonAdapter
    public static class TypeNull extends Type {
    }
}

It would be replaced with the following:
@GsonSubtype(
        jsonKeys = {"type"}
)
public abstract class Type {

    @GsonSubtypeGetter
    static Class<? extends Type> getSubType(@Nullable String type) {
        if (type == null) {
            return TypeNull.class;
        }
        switch (type) {
            case "type1":
                return Type1.class;
            case "type2":
                return Type2.class;
            case "type3":
                return Type3.class;
        }
        return null;
    }

    String type;
    String name;

    @AutoGsonAdapter
    public static class Type1 extends Type {
        int intTest;
    }

    @AutoGsonAdapter
    public static class Type2 extends Type {
        double doubleTest;
    }

    @AutoGsonAdapter
    public static class Type3 extends Type {
        String stringTest;
    }

    @AutoGsonAdapter
    public static class TypeNull extends Type {
    }
}

The replacement code will have many new features that the old solution could not support. The jsonKeys field in the annotation takes multiple arguments, and the method annotated with @GsonSubtypeGetter takes specifies the type (and nullability) of the value. If the type or nullability is incorrect, it will throw a helpful error.
The new solution allows developers to write more complicated logic to determine the correct code.

This was released in 3.5.0


Support other backends than Redis

Memcache comes to mind for distributed locks and it'd be nice to use that instead of Redis if it's more likely to be available than Redis

This would be a really nice extension. Currently the code is very coupled to redis.
Creating a plugin backend's structure would be the way to go (docker-swarm is an good example of extendable backends).
Seems the backend would need two main functions...

raise_or_lock
clear_lock

I'm willing to give this a try, but I have no knowledge of memcache's API. @jezdez, if I provide a way to support it by implementing a MemcacheBackend (or similar) class implementing the API described earlier, could you take car of the memcache specifics?

@brouberol Sure, I can take a stab at a Memcache backend next week!

@jezdez Awesome! My proposal for multiple backend support is currenly waiting for a green light from @cameronmaske. I guess you can build on the existing code, and I'll take care of any change if any API change is required.

@brouberol Sounds good to me, depending if @cameronmaske likes the API I'll either send a PR to you or this repo.. :)

@jezdez Yup, the API looks great! I'm gonna attempt to get @brouberol PR merged in to a 1.0rc branch by the end of this weekend. But, feel free to pass your memcache support off the API paradigm!

@brouberol Modification made! See #21. The docs just need updating, which I'll hopefully be able to get to later this week.
@jezdez If you have a PR, could you base if off and point it towards the 1.0-rc branch? If it's helpful here is a draft on the backend contributing guide

Long overdue, but this is now in master.
See: https://github.com/cameronmaske/celery-once/blob/master/BACKEND_GUIDE.rst for a guide to adding custom backends.

Great! Cheers :)
--
B
On Tue, Jun 6, 2017, at 05:44 PM, Cameron Maske wrote:

Long overdue, but this is now in master.
See:
https://github.com/cameronmaske/celery-once/blob/master/BACKEND_GUIDE.rst
for a guide to adding custom backends.> — You are receiving this because you were mentioned. Reply to this
email directly, view it on GitHub[1], or mute the thread[2].>

Links:

https://github.com/cameronmaske/celery-once/issues/5#issuecomment-306528391
https://github.com/notifications/unsubscribe-auth/AAdTg7IYihS6fBO81WKwW1nVgtpDunFuks5sBXPugaJpZM4Dcz4F


Compilation fails

I've tried to compile the LS – but gave up eventually because of all these errors (see attached console outputs) as I wasn't exactly sure where to start. My first guess is version incompatibilities?
1st-try_compilation-unchanged_console-output.txt
2nd-try_deps-latest_console-output.txt

Hmm, seems like a problem in mochiweb dependency.

Ah yes, replacing all deps versions with the current ones and adding {mochiweb, "3.2.2"} explicitly to the deps fixed the issue(s). It Compiles :)

Compilation seems to work without issues:
~/erlang/lfe-ls [master] λ rebar3 lfe compile
===> Fetching rebar3_lfe v0.4.11
===> Analyzing applications...
===> Compiling rebar3_lfe
===> Fetching rebar3_lfe v0.4.11
===> Fetching lfe v2.1.5
===> Analyzing applications...
===> Compiling lfe
===> Compiling rebar3_lfe
===> Verifying dependencies...
===> Fetching getopt v1.0.3
===> Fetching jsx v3.1.0
===> Fetching lfe v2.1.5
===> Fetching ljson (from {git,"https://github.com/mdbergmann/ljson.git","master"})
===> WARNING: It is recommended to use {branch, Name}, {tag, Tag} or {ref, Ref}, otherwise updating the dep may not work as expected.
===> Fetching logjam v1.2.4
===> Fetching ltest v0.13.9
===> Fetching mochiweb v3.2.2
===> Fetching color v1.0.0
===> Skipping jsx (from {git,"https://github.com/talentdeficit/jsx.git",{tag,"v2.9.0"}}) as an app of the same name has already been fetched
===> Fetching lutil (from {git,"https://github.com/lfex/lutil.git",
                 {branch,"release/0.13.x"}})
===> Skipping mochiweb (from {git,"https://github.com/mochi/mochiweb.git",{tag,"v2.19.0"}}) as an app of the same name has already been fetched
===> Skipping lfe v2.1.2 as an app of the same name has already been fetched
===> Analyzing applications...
===> Compiling mochiweb
===> Compiling lfe
===> Compiling lutil
===> Compiling jsx
===> Compiling json
===> Compiling color
===> Compiling ltest
===> Compiling logjam
===> Compiling getopt
===> Analyzing applications...
===> Compiling lfe-ls

Well, some errors occur during the release build, and I'm not quite sure why (maybe some paths have changed due to the updated versions?).
~/erlang/lfe-ls [master] λ rebar3 as prod do clean,release,escriptize
===> Cleaning out lfe-ls...
===> Verifying dependencies...
===> Analyzing applications...
===> Compiling lfe-ls
===> Assembling release 'lfe-ls'-0.2.0...
===> Warnings generating release:
*WARNING* Missing application sasl. Can not upgrade with this release
*WARNING* kernel: Object code (code) out of date
*WARNING* stdlib: Object code (filename) out of date
*WARNING* compiler: Object code (compile) out of date
*WARNING* lfe: Source code not found: cl.erl
*WARNING* lfe: Source code not found: clj.erl
*WARNING* public_key: Object code (pubkey_os_cacerts) out of date
*WARNING* ljson: Source code not found: 'ljson-util'.erl
*WARNING* ljson: Source code not found: ljson.erl
*WARNING* 'lfe-ls': Source code not found: 'code-util'.erl
*WARNING* 'lfe-ls': Source code not found: 'compile-util'.erl
*WARNING* 'lfe-ls': Source code not found: 'completion-util'.erl
*WARNING* 'lfe-ls': Source code not found: 'hover-util'.erl
*WARNING* 'lfe-ls': Source code not found: 'lfe-ls-app'.erl
*WARNING* 'lfe-ls': Source code not found: 'lfe-ls-tcp-sup'.erl
*WARNING* 'lfe-ls': Source code not found: 'lfe-ls-tcp'.erl
*WARNING* 'lfe-ls': Source code not found: 'lfe-ls'.erl
*WARNING* 'lfe-ls': Source code not found: 'lsp-proc'.erl
*WARNING* 'lfe-ls': Source code not found: 'lsp-util'.erl
*WARNING* 'lfe-ls': Source code not found: 'response-sender'.erl
===> Release successfully assembled: _build/prod/rel/lfe-ls
===> Verifying dependencies...
===> Analyzing applications...
===> Compiling lfe-ls
===> Building escript for lfe-ls...

... Even though building the release produces the _build/prod/bin/lfe-ls binary as expected, the app doesn't run in the shell. The log "/Users/dee/Library/Logs/lfe-ls/lfe-ls.log" stays empty.
~/erlang/lfe-ls [master] λ ./_build/prod/bin/lfe-ls
Args: []
port: {ok,10567}
Logging to: "/Users/dee/Library/Logs/lfe-ls/lfe-ls.log"
Removing logger: default
Starting app failed!

When starting lfe-ls via eglot, things look a bit different though. Here's lfe-ls.log:
2024-12-05T15:59:14.569212+08:00 info: Application: getopt. Started at: nonode@nohost.
2024-12-05T15:59:14.577171+08:00 info: Application: compiler. Started at: nonode@nohost.
2024-12-05T15:59:14.577293+08:00 info: Application: lfe. Started at: nonode@nohost.
2024-12-05T15:59:14.582535+08:00 info: Application: crypto. Started at: nonode@nohost.
2024-12-05T15:59:14.599841+08:00 info: Supervisor: {local,httpc_profile_sup}. Started: id=httpc_manager,pid=<0.91.0>.
2024-12-05T15:59:14.600011+08:00 info: Supervisor: {local,httpc_sup}. Started: id=httpc_profile_sup,pid=<0.90.0>.
2024-12-05T15:59:14.600794+08:00 info: Supervisor: {local,httpc_sup}. Started: id=httpc_handler_sup,pid=<0.92.0>.
2024-12-05T15:59:14.600930+08:00 info: Supervisor: {local,inets_sup}. Started: id=httpc_sup,pid=<0.89.0>.
2024-12-05T15:59:14.601743+08:00 info: Supervisor: {local,inets_sup}. Started: id=httpd_sup,pid=<0.93.0>.
2024-12-05T15:59:14.601887+08:00 info: Application: inets. Started at: nonode@nohost.
2024-12-05T15:59:14.612681+08:00 info: Application: asn1. Started at: nonode@nohost.
2024-12-05T15:59:14.612826+08:00 info: Application: public_key. Started at: nonode@nohost.
2024-12-05T15:59:14.614633+08:00 debug: Supervisor: {local,logger_sup}. Started: id=ssl_handler,pid=<0.97.0>.
2024-12-05T15:59:14.619070+08:00 info: Supervisor: {local,ssl_admin_sup}. Started: id=ssl_pem_cache,pid=<0.101.0>.
2024-12-05T15:59:14.622279+08:00 info: Supervisor: {local,ssl_admin_sup}. Started: id=ssl_manager,pid=<0.102.0>.
2024-12-05T15:59:14.623225+08:00 info: Supervisor: {local,ssl_admin_sup}. Started: id=tls_client_ticket_store,pid=<0.103.0>.
2024-12-05T15:59:14.623361+08:00 info: Supervisor: {local,ssl_sup}. Started: id=ssl_admin_sup,pid=<0.100.0>.
2024-12-05T15:59:14.625250+08:00 info: Supervisor: {local,tls_sup}. Started: id=tls_connection_sup,pid=<0.106.0>.
2024-12-05T15:59:14.626666+08:00 info: Supervisor: {local,tls_server_sup}. Started: id=ssl_listen_tracker_sup,pid=<0.108.0>.
2024-12-05T15:59:14.627378+08:00 info: Supervisor: {local,tls_server_sup}. Started: id=tls_server_session_ticket,pid=<0.109.0>.
2024-12-05T15:59:14.628023+08:00 info: Supervisor: {local,tls_server_sup}. Started: id=ssl_server_session_cache_sup,pid=<0.110.0>.
2024-12-05T15:59:14.628735+08:00 info: Supervisor: {local,tls_server_sup}. Started: id=ssl_upgrade_server_session_cache_sup,pid=<0.111.0>.
2024-12-05T15:59:14.628870+08:00 info: Supervisor: {local,tls_sup}. Started: id=tls_server_sup,pid=<0.107.0>.
2024-12-05T15:59:14.629001+08:00 info: Supervisor: {local,ssl_connection_sup}. Started: id=tls_sup,pid=<0.105.0>.
2024-12-05T15:59:14.630337+08:00 info: Supervisor: {local,dtls_sup}. Started: id=dtls_connection_sup,pid=<0.113.0>.
2024-12-05T15:59:14.631716+08:00 info: Supervisor: {local,dtls_server_sup}. Started: id=dtls_listener_sup,pid=<0.115.0>.
2024-12-05T15:59:14.632441+08:00 info: Supervisor: {local,dtls_server_sup}. Started: id=dtls_server_session_cache_sup,pid=<0.116.0>.
2024-12-05T15:59:14.632568+08:00 info: Supervisor: {local,dtls_sup}. Started: id=dtls_server_sup,pid=<0.114.0>.
2024-12-05T15:59:14.632691+08:00 info: Supervisor: {local,ssl_connection_sup}. Started: id=dtls_sup,pid=<0.112.0>.
2024-12-05T15:59:14.632824+08:00 info: Supervisor: {local,ssl_sup}. Started: id=ssl_connection_sup,pid=<0.104.0>.
2024-12-05T15:59:14.632968+08:00 info: Application: ssl. Started at: nonode@nohost.
2024-12-05T15:59:14.635086+08:00 info: Application: xmerl. Started at: nonode@nohost.
2024-12-05T15:59:14.637454+08:00 info: Application: syntax_tools. Started at: nonode@nohost.
2024-12-05T15:59:14.637625+08:00 info: Application: mochiweb. Started at: nonode@nohost.
2024-12-05T15:59:14.639374+08:00 info: Application: jsx. Started at: nonode@nohost.
2024-12-05T15:59:14.640360+08:00 info: Application: ljson. Started at: nonode@nohost.
2024-12-05T15:59:14.641173+08:00 info: Starting lfe-ls application ...
2024-12-05T15:59:14.641249+08:00 info: Port already set.
2024-12-05T15:59:14.641889+08:00 debug: start_link (tcp-sup)
2024-12-05T15:59:14.641979+08:00 debug: init (tcp-sup)
2024-12-05T15:59:14.643800+08:00 info: Starting on port: 49831
2024-12-05T15:59:14.643901+08:00 debug: listen (tcp-sup) ok
2024-12-05T15:59:14.643985+08:00 debug: mod: 'lfe-ls-tcp', fun: start_link, args: [#Port<0.3>]
2024-12-05T15:59:14.644931+08:00 info: start_link (lfe-ls-tcp)
2024-12-05T15:59:14.645027+08:00 info: init (lfe-ls-tcp)
2024-12-05T15:59:14.645136+08:00 info: Supervisor: {local,'lfe-ls-tcp-sup'}. Started: id='lfe-ls-tcp',pid=<0.120.0>.
2024-12-05T15:59:14.645094+08:00 debug: waiting for connection...
2024-12-05T15:59:14.645344+08:00 info: Application: 'lfe-ls'. Started at: nonode@nohost.
2024-12-05T15:59:14.645569+08:00 info: Application started.
2024-12-05T15:59:14.716353+08:00 notice: connection accepted (lfe-ls)
2024-12-05T15:59:14.716464+08:00 debug: start-socket (tcp-sup)
2024-12-05T15:59:14.716603+08:00 debug: Spawned reader: <0.121.0>
2024-12-05T15:59:14.716691+08:00 debug: Reading request...
2024-12-05T15:59:14.718947+08:00 debug: Received partial-msg len: 27
2024-12-05T15:59:14.738543+08:00 debug: handle-new-req...
2024-12-05T15:59:14.738637+08:00 debug: msg: <<"2503\r\n\r\n{\"j">>
2024-12-05T15:59:14.738742+08:00 debug: New req content-len: 2503
2024-12-05T15:59:14.738840+08:00 debug: rest-len: 3, len-diff: 2500
2024-12-05T15:59:14.738954+08:00 debug: complete-req: <<"{\"jsonrpc\":\"2.0\",\"id\":1,\"method\":\"initialize\",\"params\":{\"processId\":null,\"clientInfo\":{\"name\":\"Eglot\"},\"rootPath\":\"/Users/dee/erlang/learnlfe/\",\"rootUri\":\"file:///Users/dee/erlang/learnlfe\",\"initializationOptions\":{},\"capabilities\":{\"workspace\":{\"applyEdit\":true,\"executeCommand\":{\"dynamicRegistration\":false},\"workspaceEdit\":{\"documentChanges\":true},\"didChangeWatchedFiles\":{\"dynamicRegistration\":true},\"symbol\":{\"dynamicRegistration\":false},\"configuration\":true,\"workspaceFolders\":true},\"textDocument\":{\"synchronization\":{\"dynamicRegistration\":false,\"willSave\":true,\"willSaveWaitUntil\":true,\"didSave\":true},\"completion\":{\"dynamicRegistration\":false,\"completionItem\":{\"snippetSupport\":true,\"deprecatedSupport\":true,\"resolveSupport\":{\"properties\":[\"documentation\",\"details\",\"additionalTextEdits\"]},\"tagSupport\":{\"valueSet\":[1]}},\"contextSupport\":true},\"hover\":{\"dynamicRegistration\":false,\"contentFormat\":[\"markdown\",\"plaintext\"]},\"signatureHelp\":{\"dynamicRegistration\":false,\"signatureInformation\":{\"parameterInformation\":{\"labelOffsetSupport\":true},\"documentationFormat\":[\"markdown\",\"plaintext\"],\"activeParameterSupport\":true}},\"references\":{\"dynamicRegistration\":false},\"definition\":{\"dynamicRegistration\":false,\"linkSupport\":true},\"declaration\":{\"dynamicRegistration\":false,\"linkSupport\":true},\"implementation\":{\"dynamicRegistration\":false,\"linkSupport\":true},\"typeDefinition\":{\"dynamicRegistration\":false,\"linkSupport\":true},\"documentSymbol\":{\"dynamicRegistration\":false,\"hierarchicalDocumentSymbolSupport\":true,\"symbolKind\":{\"valueSet\":[1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26]}},\"documentHighlight\":{\"dynamicRegistration\":false},\"codeAction\":{\"dynamicRegistration\":false,\"resolveSupport\":{\"properties\":[\"edit\",\"command\"]},\"dataSupport\":true,\"codeActionLiteralSupport\":{\"codeActionKind\":{\"valueSet\":[\"quickfix\",\"refactor\",\"refactor.extract\",\"refactor.inline\",\"refactor.rewrite\",\"source\",\"source.organizeImports\"]}},\"isPreferredSupport\":true},\"formatting\":{\"dynamicRegistration\":false},\"rangeFormatting\":{\"dynamicRegistration\":false},\"rename\":{\"dynamicRegistration\":false},\"inlayHint\":{\"dynamicRegistration\":false},\"publishDiagnostics\":{\"relatedInformation\":false,\"codeDescriptionSupport\":false,\"tagSupport\":{\"valueSet\":[1,2]}}},\"window\":{\"showDocument\":{\"support\":true},\"workDoneProgress\":true},\"general\":{\"positionEncodings\":[\"utf-32\",\"utf-8\",\"utf-16\"]},\"experimental\":{}},\"workspaceFolders\":[{\"uri\":\"file:///Users/dee/erlang/learnlfe\",\"name\":\"~/erlang/learnlfe/\"}]}}">>
2024-12-05T15:59:14.739500+08:00 info: Complete request of size: 2503
2024-12-05T15:59:14.744699+08:00 debug: json-input: #{<<"id">> => 1,<<"jsonrpc">> => <<"2.0">>,<<"method">> => <<"initialize">>,<<"params">> => #{<<"capabilities">> => #{<<"experimental">> => #{},<<"general">> => #{<<"positionEncodings">> => [<<"utf-32">>,<<"utf-8">>,<<"utf-16">>]},<<"textDocument">> => #{<<"codeAction">> => #{<<"codeActionLiteralSupport">> => #{<<"codeActionKind">> => #{<<"valueSet">> => [<<"quickfix">>,<<"refactor">>,<<"refactor.extract">>,<<"refactor.inline">>,<<"refactor.rewrite">>,<<"source">>,<<"source.organizeImports">>]}},<<"dataSupport">> => true,<<"dynamicRegistration">> => false,<<"isPreferredSupport">> => true,<<"resolveSupport">> => #{<<"properties">> => [<<"edit">>,<<"command">>]}},<<"completion">> => #{<<"completionItem">> => #{<<"deprecatedSupport">> => true,<<"resolveSupport">> => #{<<"properties">> => [<<"documentation">>,<<"details">>,<<"additionalTextEdits">>]},<<"snippetSupport">> => true,<<"tagSupport">> => #{<<"valueSet">> => [1]}},<<"contextSupport">> => true,<<"dynamicRegistration">> => false},<<"declaration">> => #{<<"dynamicRegistration">> => false,<<"linkSupport">> => true},<<"definition">> => #{<<"dynamicRegistration">> => false,<<"linkSupport">> => true},<<"documentHighlight">> => #{<<"dynamicRegistration">> => false},<<"documentSymbol">> => #{<<"dynamicRegistration">> => false,<<"hierarchicalDocumentSymbolSupport">> => true,<<"symbolKind">> => #{<<"valueSet">> => [1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26]}},<<"formatting">> => #{<<"dynamicRegistration">> => false},<<"hover">> => #{<<"contentFormat">> => [<<"markdown">>,<<"plaintext">>],<<"dynamicRegistration">> => false},<<"implementation">> => #{<<"dynamicRegistration">> => false,<<"linkSupport">> => true},<<"inlayHint">> => #{<<"dynamicRegistration">> => false},<<"publishDiagnostics">> => #{<<"codeDescriptionSupport">> => false,<<"relatedInformation">> => false,<<"tagSupport">> => #{<<"valueSet">> => [1,2]}},<<"rangeFormatting">> => #{<<"dynamicRegistration">> => false},<<"references">> => #{<<"dynamicRegistration">> => false},<<"rename">> => #{<<"dynamicRegistration">> => false},<<"signatureHelp">> => #{<<"dynamicRegistration">> => false,<<"signatureInformation">> => #{<<"activeParameterSupport">> => true,<<"documentationFormat">> => [<<"markdown">>,<<"plaintext">>],<<"parameterInformation">> => #{<<"labelOffsetSupport">> => true}}},<<"synchronization">> => #{<<"didSave">> => true,<<"dynamicRegistration">> => false,<<"willSave">> => true,<<"willSaveWaitUntil">> => true},<<"typeDefinition">> => #{<<"dynamicRegistration">> => false,<<"linkSupport">> => true}},<<"window">> => #{<<"showDocument">> => #{<<"support">> => true},<<"workDoneProgress">> => true},<<"workspace">> => #{<<"applyEdit">> => true,<<"configuration">> => true,<<"didChangeWatchedFiles">> => #{<<"dynamicRegistration">> => true},<<"executeCommand">> => #{<<"dynamicRegistration">> => false},<<"symbol">> => #{<<"dynamicRegistration">> => false},<<"workspaceEdit">> => #{<<"documentChanges">> => true},<<"workspaceFolders">> => true}},<<"clientInfo">> => #{<<"name">> => <<"Eglot">>},<<"initializationOptions">> => #{},<<"processId">> => null,<<"rootPath">> => <<"/Users/dee/erlang/learnlfe/">>,<<"rootUri">> => <<"file:///Users/dee/erlang/learnlfe">>,<<"workspaceFolders">> => [#{<<"name">> => <<"~/erlang/learnlfe/">>,<<"uri">> => <<"file:///Users/dee/erlang/learnlfe">>}]}}
2024-12-05T15:59:14.746724+08:00 warning: Error: [{cl,'-lfe-find-if/2-local-find-if-loop/2-0-',[#Fun<lsp-proc.5.26430133>,#{<<"id">> => 1,<<"jsonrpc">> => <<"2.0">>,<<"method">> => <<"initialize">>,<<"params">> => #{<<"capabilities">> => #{<<"experimental">> => #{},<<"general">> => #{<<"positionEncodings">> => [<<"utf-32">>,<<"utf-8">>,<<"utf-16">>]},<<"textDocument">> => #{<<"codeAction">> => #{<<"codeActionLiteralSupport">> => #{<<"codeActionKind">> => #{<<"valueSet">> => [<<"quickfix">>,<<"refactor">>,<<"refactor.extract">>,<<"refactor.inline">>,<<"refactor.rewrite">>,<<"source">>,<<"source.organizeImports">>]}},<<"dataSupport">> => true,<<"dynamicRegistration">> => false,<<"isPreferredSupport">> => true,<<"resolveSupport">> => #{<<"properties">> => [<<"edit">>,<<"command">>]}},<<"completion">> => #{<<"completionItem">> => #{<<"deprecatedSupport">> => true,<<"resolveSupport">> => #{<<"properties">> => [<<"documentation">>,<<"details">>,<<"additionalTextEdits">>]},<<"snippetSupport">> => true,<<"tagSupport">> => #{<<"valueSet">> => [1]}},<<"contextSupport">> => true,<<"dynamicRegistration">> => false},<<"declaration">> => #{<<"dynamicRegistration">> => false,<<"linkSupport">> => true},<<"definition">> => #{<<"dynamicRegistration">> => false,<<"linkSupport">> => true},<<"documentHighlight">> => #{<<"dynamicRegistration">> => false},<<"documentSymbol">> => #{<<"dynamicRegistration">> => false,<<"hierarchicalDocumentSymbolSupport">> => true,<<"symbolKind">> => #{<<"valueSet">> => [1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26]}},<<"formatting">> => #{<<"dynamicRegistration">> => false},<<"hover">> => #{<<"contentFormat">> => [<<"markdown">>,<<"plaintext">>],<<"dynamicRegistration">> => false},<<"implementation">> => #{<<"dynamicRegistration">> => false,<<"linkSupport">> => true},<<"inlayHint">> => #{<<"dynamicRegistration">> => false},<<"publishDiagnostics">> => #{<<"codeDescriptionSupport">> => false,<<"relatedInformation">> => false,<<"tagSupport">> => #{<<"valueSet">> => [1,2]}},<<"rangeFormatting">> => #{<<"dynamicRegistration">> => false},<<"references">> => #{<<"dynamicRegistration">> => false},<<"rename">> => #{<<"dynamicRegistration">> => false},<<"signatureHelp">> => #{<<"dynamicRegistration">> => false,<<"signatureInformation">> => #{<<"activeParameterSupport">> => true,<<"documentationFormat">> => [<<"markdown">>,<<"plaintext">>],<<"parameterInformation">> => #{<<"labelOffsetSupport">> => true}}},<<"synchronization">> => #{<<"didSave">> => true,<<"dynamicRegistration">> => false,<<"willSave">> => true,<<"willSaveWaitUntil">> => true},<<"typeDefinition">> => #{<<"dynamicRegistration">> => false,<<"linkSupport">> => true}},<<"window">> => #{<<"showDocument">> => #{<<"support">> => true},<<"workDoneProgress">> => true},<<"workspace">> => #{<<"applyEdit">> => true,<<"configuration">> => true,<<"didChangeWatchedFiles">> => #{<<"dynamicRegistration">> => true},<<"executeCommand">> => #{<<"dynamicRegistration">> => false},<<"symbol">> => #{<<"dynamicRegistration">> => false},<<"workspaceEdit">> => #{<<"documentChanges">> => true},<<"workspaceFolders">> => true}},<<"clientInfo">> => #{<<"name">> => <<"Eglot">>},<<"initializationOptions">> => #{},<<"processId">> => null,<<"rootPath">> => <<"/Users/dee/erlang/learnlfe/">>,<<"rootUri">> => <<"file:///Users/dee/erlang/learnlfe">>,<<"workspaceFolders">> => [#{<<"name">> => <<"~/erlang/learnlfe/">>,<<"uri">> => <<"file:///Users/dee/erlang/learnlfe">>}]}}],[{file,"src/cl.lfe"},{line,391}]},{'lsp-proc','process-input',3,[{file,"/Users/dee/erlang/lfe-ls/apps/lfe-ls/src/lsp-proc.lfe"},{line,8}]},{'lfe-ls-tcp','%on-tcp-receive',2,[{file,"/Users/dee/erlang/lfe-ls/apps/lfe-ls/src/lfe-ls-tcp.lfe"},{line,87}]},{'lfe-ls-tcp','read-request',1,[{file,"/Users/dee/erlang/lfe-ls/apps/lfe-ls/src/lfe-ls-tcp.lfe"},{line,76}]}], type: error, value: function_clause
2024-12-05T15:59:14.750777+08:00 debug: Sending response via: fun 'lfe-ls-tcp':send/2
2024-12-05T15:59:14.751018+08:00 debug: Response sent!
2024-12-05T15:59:14.751085+08:00 debug: Reading request...

Messages buffer:
[jsonrpc] Attempting to start ‘~/erlang/lfe-ls/_build/prod/bin/lfe-ls --transport tcp --port 49831’
[jsonrpc] Started.  Trying to connect to localhost:49831 (attempt 1)
[jsonrpc] Trying to connect to localhost:49831 (attempt 2)
[jsonrpc] Trying to connect to localhost:49831 (attempt 3)
[jsonrpc] Trying to connect to localhost:49831 (attempt 4)
[jsonrpc] Done, connected to 49831!
[jsonrpc] (warning) Sentinel for autostart (EGLOT (learnlfe/(lfe-mode))) still hasn't run, deleting it!
[jsonrpc] Server exited with status 0
Error running timer: (error "[eglot] Timed out after 60 seconds")

EGLOT (...) events buffer:
[inferior] Args: ["--transport","tcp","--port","49831"]
[inferior] port: {ok,49831}
[inferior] Logging to: "/Users/dee/Library/Logs/lfe-ls/lfe-ls.log"
[inferior] Removing logger: default
[inferior] App started.
[inferior] nil

----------b---y---e---b---y---e----------
[inferior] foo
[inferior] foo
[inferior] nil
[inferior] nil
[inferior] Process inferior (EGLOT (learnlfe/(lfe-mode))) killed: 9

Hmm. Weird stuff. I'll have to check, but seems like there is a parser error around here:
2024-12-05T15:59:14.744699+08:00 debug: json-input: #{<<"id">> => 1,<<"jsonrpc">> => <<"2.0">>,<<"method">> => <<"initialize">>,<<"params">> => #{<<"capabilities">> => #{<<"experimental">> => #{},<<"general">> => #{<<"positionEncodings">> => [<<"utf-32">>,<<"utf-8">>,<<"utf-16">>]},<<"textDocument">> => #{<<"codeAction">> => #{<<"codeActionLiteralSupport">> => #{<<"codeActionKind">> => #{<<"valueSet">> => [<<"quickfix">>,<<"refactor">>,<<"refactor.extract">>,<<"refactor.inline">>,<<"refactor.rewrite">>,<<"source">>,<<"source.organizeImports">>]}},<<"dataSupport">> => true,<<"dynamicRegistration">> => false,<<"isPreferredSupport">> => true,<<"resolveSupport">> => #{<<"properties">> => [<<"edit">>,<<"command">>]}},<<"completion">> => #{<<"completionItem">> => #{<<"deprecatedSupport">> => true,<<"resolveSupport">> => #{<<"properties">> => [<<"documentation">>,<<"details">>,<<"additionalTextEdits">>]},<<"snippetSupport">> => true,<<"tagSupport">> => #{<<"valueSet">> => [1]}},<<"contextSupport">> => true,<<"dynamicRegistration">> => false},<<"declaration">> => #{<<"dynamicRegistration">> => false,<<"linkSupport">> => true},<<"definition">> => #{<<"dynamicRegistration">> => false,<<"linkSupport">> => true},<<"documentHighlight">> => #{<<"dynamicRegistration">> => false},<<"documentSymbol">> => #{<<"dynamicRegistration">> => false,<<"hierarchicalDocumentSymbolSupport">> => true,<<"symbolKind">> => #{<<"valueSet">> => [1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26]}},<<"formatting">> => #{<<"dynamicRegistration">> => false},<<"hover">> => #{<<"contentFormat">> => [<<"markdown">>,<<"plaintext">>],<<"dynamicRegistration">> => false},<<"implementation">> => #{<<"dynamicRegistration">> => false,<<"linkSupport">> => true},<<"inlayHint">> => #{<<"dynamicRegistration">> => false},<<"publishDiagnostics">> => #{<<"codeDescriptionSupport">> => false,<<"relatedInformation">> => false,<<"tagSupport">> => #{<<"valueSet">> => [1,2]}},<<"rangeFormatting">> => #{<<"dynamicRegistration">> => false},<<"references">> => #{<<"dynamicRegistration">> => false},<<"rename">> => #{<<"dynamicRegistration">> => false},<<"signatureHelp">> => #{<<"dynamicRegistration">> => false,<<"signatureInformation">> => #{<<"activeParameterSupport">> => true,<<"documentationFormat">> => [<<"markdown">>,<<"plaintext">>],<<"parameterInformation">> => #{<<"labelOffsetSupport">> => true}}},<<"synchronization">> => #{<<"didSave">> => true,<<"dynamicRegistration">> => false,<<"willSave">> => true,<<"willSaveWaitUntil">> => true},<<"typeDefinition">> => #{<<"dynamicRegistration">> => false,<<"linkSupport">> => true}},<<"window">> => #{<<"showDocument">> => #{<<"support">> => true},<<"workDoneProgress">> => true},<<"workspace">> => #{<<"applyEdit">> => true,<<"configuration">> => true,<<"didChangeWatchedFiles">> => #{<<"dynamicRegistration">> => true},<<"executeCommand">> => #{<<"dynamicRegistration">> => false},<<"symbol">> => #{<<"dynamicRegistration">> => false},<<"workspaceEdit">> => #{<<"documentChanges">> => true},<<"workspaceFolders">> => true}},<<"clientInfo">> => #{<<"name">> => <<"Eglot">>},<<"initializationOptions">> => #{},<<"processId">> => null,<<"rootPath">> => <<"/Users/dee/erlang/learnlfe/">>,<<"rootUri">> => <<"file:///Users/dee/erlang/learnlfe">>,<<"workspaceFolders">> => [#{<<"name">> => <<"~/erlang/learnlfe/">>,<<"uri">> => <<"file:///Users/dee/erlang/learnlfe">>}]}}
2024-12-05T15:59:14.746724+08:00 warning: Error: [{cl,'-lfe-find-if/2-local-find-if-loop/2-0-',[#Fun<lsp-proc.5.26430133>,#{<<"id">> => 1,<<"jsonrpc">> => <<"2.0">>,<<"method">> => <<"initialize">>,<<"params">> => #{<<"capabilities">> => #{<<"experimental">> => #{},<<"general">> => #{<<"positionEncodings">> => [<<"utf-32">>,<<"utf-8">>,<<"utf-16">>]},<<"textDocument">> => #{<<"codeAction">> => #{<<"codeActionLiteralSupport">> => #{<<"codeActionKind">> => #{<<"valueSet">> => [<<"quickfix">>,<<"refactor">>,<<"refactor.extract">>,<<"refactor.inline">>,<<"refactor.rewrite">>,<<"source">>,<<"source.organizeImports">>]}},<<"dataSupport">> => true,<<"dynamicRegistration">> => false,<<"isPreferredSupport">> => true,<<"resolveSupport">> => #{<<"properties">> => [<<"edit">>,<<"command">>]}},<<"completion">> => #{<<"completionItem">> => #{<<"deprecatedSupport">> => true,<<"resolveSupport">> => #{<<"properties">> => [<<"documentation">>,<<"details">>,<<"additionalTextEdits">>]},<<"snippetSupport">> => true,<<"tagSupport">> => #{<<"valueSet">> => [1]}},<<"contextSupport">> => true,<<"dynamicRegistration">> => false},<<"declaration">> => #{<<"dynamicRegistration">> => false,<<"linkSupport">> => true},<<"definition">> => #{<<"dynamicRegistration">> => false,<<"linkSupport">> => true},<<"documentHighlight">> => #{<<"dynamicRegistration">> => false},<<"documentSymbol">> => #{<<"dynamicRegistration">> => false,<<"hierarchicalDocumentSymbolSupport">> => true,<<"symbolKind">> => #{<<"valueSet">> => [1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26]}},<<"formatting">> => #{<<"dynamicRegistration">> => false},<<"hover">> => #{<<"contentFormat">> => [<<"markdown">>,<<"plaintext">>],<<"dynamicRegistration">> => false},<<"implementation">> => #{<<"dynamicRegistration">> => false,<<"linkSupport">> => true},<<"inlayHint">> => #{<<"dynamicRegistration">> => false},<<"publishDiagnostics">> => #{<<"codeDescriptionSupport">> => false,<<"relatedInformation">> => false,<<"tagSupport">> => #{<<"valueSet">> => [1,2]}},<<"rangeFormatting">> => #{<<"dynamicRegistration">> => false},<<"references">> => #{<<"dynamicRegistration">> => false},<<"rename">> => #{<<"dynamicRegistration">> => false},<<"signatureHelp">> => #{<<"dynamicRegistration">> => false,<<"signatureInformation">> => #{<<"activeParameterSupport">> => true,<<"documentationFormat">> => [<<"markdown">>,<<"plaintext">>],<<"parameterInformation">> => #{<<"labelOffsetSupport">> => true}}},<<"synchronization">> => #{<<"didSave">> => true,<<"dynamicRegistration">> => false,<<"willSave">> => true,<<"willSaveWaitUntil">> => true},<<"typeDefinition">> => #{<<"dynamicRegistration">> => false,<<"linkSupport">> => true}},<<"window">> => #{<<"showDocument">> => #{<<"support">> => true},<<"workDoneProgress">> => true},<<"workspace">> => #{<<"applyEdit">> => true,<<"configuration">> => true,<<"didChangeWatchedFiles">> => #{<<"dynamicRegistration">> => true},<<"executeCommand">> => #{<<"dynamicRegistration">> => false},<<"symbol">> => #{<<"dynamicRegistration">> => false},<<"workspaceEdit">> => #{<<"documentChanges">> => true},<<"workspaceFolders">> => true}},<<"clientInfo">> => #{<<"name">> => <<"Eglot">>},<<"initializationOptions">> => #{},<<"processId">> => null,<<"rootPath">> => <<"/Users/dee/erlang/learnlfe/">>,<<"rootUri">> => <<"file:///Users/dee/erlang/learnlfe">>,<<"workspaceFolders">> => [#{<<"name">> => <<"~/erlang/learnlfe/">>,<<"uri">> => <<"file:///Users/dee/erlang/learnlfe">>}]}}],[{file,"src/cl.lfe"},{line,391}]},{'lsp-proc','process-input',3,[{file,"/Users/dee/erlang/lfe-ls/apps/lfe-ls/src/lsp-proc.lfe"},{line,8}]},{'lfe-ls-tcp','%on-tcp-receive',2,[{file,"/Users/dee/erlang/lfe-ls/apps/lfe-ls/src/lfe-ls-tcp.lfe"},{line,87}]},{'lfe-ls-tcp','read-request',1,[{file,"/Users/dee/erlang/lfe-ls/apps/lfe-ls/src/lfe-ls-tcp.lfe"},{line,76}]}], type: error, value: function_clause

I find it extreme strange that when not touching a project for a year it doesn't work anymore. IMO doesn't shed a good light on Erlang dev tooling I must say.

I find it extreme strange that when not touching a project for a year it doesn't work anymore. IMO doesn't shed a good light on Erlang dev tooling I must say.

Well, to be fair that might be because of carelessly updating the dependencies (I'm guilty of that) instead of version pinning; the dependencies' APIs may have changed significantly since lfe-ls has been written and running successfully.
But on the other hand – if that means to keep around several versions of Erlang/OTP installed plus LFE plus libraries known to work together – well, that isn't ideal either. Stack(age) solves this kind of problem for Haskell, and Common Lisp is frozen in time anyway.

and Common Lisp is frozen in time anyway

That's what I kind of like about it. Though slow paced improvements would be worthwhile.
But there is change in the libraries, ASDF for example, even if slow which possibly gives you some incompatibilities over time.

it sits in a sweet spot

Yeah, that was also the reason for me to have look at it.
Maybe we should revert and go slower. Have a closer look at what was the problem. Why was there a problem with mochaweb, etc. I suppose the Erlang/OTP and LFE version have increased since last year and we're trying to compile that one year old code with newer compilers.
In the current code running the tests (rebar3 eunit) I get a lot of warnings with katana_code (what's that?) and there is a problem with lutil.
===> Compiling _build/default/lib/lutil/src/lutil.lfe failed
/Users/mbergmann/Development/lfe-ls/_build/default/lib/lutil/src/lutil.lfe:53: illegal list code

I can probably dedicate some time over the weekend.

Well I might be a bit under-qualified to grasp the full extend, but anyway – do you have that rebar.config around (or can you reproduce it via git) from when everything still worked? For instance, when you created these GIFs showing off auto-completion?

Well, I think it was either 93465197f872dfeccc09338b3f283b161e4ea323 or c83eccdf611f00517b9a394755297d8e6d42ebba (the commit from garlic0x1).
I'm testing the stuff before I commit something, so 93465197f872dfeccc09338b3f283b161e4ea323 did definitely work. Didn't check c83eccdf611f00517b9a394755297d8e6d42ebba explicitly.

Was was wondering about it. I'm not using mochiweb directly. I think it's needed by ljson which now is deprecated. One should use jsx directly they say. So I think the whole json parsing and construction should be adapted to jsx then. mochiweb is then actually not needed at all anymore.

So, course of action should be:

remove ljson dependency
remove mochiweb dependency
add and pin jsx dependency
rework json parsing and construction using jsx

Unfortunately I don't even have a working version myself (:/). But I think it could still be possible to compile the thing with a version of mochiweb that doesn't use maybe yet. Seems like maybe is new in Erlang.

Do you know why these warnings appear, and why .erl files? I don't get it – most of these files are in fact .lfe files within the src directory (?)

Hmm, could be the LFE compiler generating some Erlang code? Not sure.

Hmm, could be the LFE compiler generating some Erlang code? Not sure.

I wondered about that too, since LFE seems to compile to Core Erlang (afaik?), but I wouldn't expect that to come up like this during the build process. Well, trying to fix that thing might be a nice (and useful) opportunity to learn more about LFE/Erlang though 🧐

Probably. There is a Discord channel, do you know?


Remove Instruction::DATA()

This no longer makes sense in the face now that we have bytecode sections.

Overall, I have decided to keep this instruction only for legacy bytecode.  In most cases, it should not be needed.  But, potentially, in a very small number of cases (e.g. handwritten bytecode) it might be.


pnpm recursive link / workspace

This pull request tries to add support for pnpm's workspace functionality - that is the recursive link command and the shrinkwraps it creates.
Previously the local packages code looked at the specifiers for a given package - this works when the link: syntax is used in the package.json. The recursive link command does however maintain the package versions in the specifiers and it is only in the dependencies where the linking is declared.
The attempted solution for this is to resolve the link: description and read the package.json for the package it points to - to the be able to build a specifiers set.
Some notes,
I had to add an empty shrinkwrap.yaml to tests/recursive-link/packages/c because of https://github.com/adisbladis/pnpm2nix/issues/4
I tried to make package c depended on b and b on c. This does not work however - it seems the handling of circular dependencies doesn't work correctly for this case. I am unsure if this is because of the different approach in resolving or if it's unrelated and a new bug to be filed.

Thanks and sorry for taking a while to merge!
The circular dependency issue is because link: packages are handled in a very special manner: https://github.com/adisbladis/pnpm2nix/blob/3f11af5924694812581ee29e3cb7d45a825a915f/default.nix#L118.
I did it this way because link: dependencies do not have their dependency graph in shrinkwrap.yaml so we can't know what the link: dependency will pull in.
It's would be possible to change the behaviour to import the link: dependency's shrinkwrap.yaml during graph rewriting (shrinkwrap.nix) and merge everything into the same graph.

pnpm 3 did an overhaul of workspaces and it's not at all the same anymore.
The entire dependency graph is now embedded in the same "shrinkwrap" (this changed name to lock) but with some special semantics for workspace local packages.
I'm considering different solutions to this..
@functorism Opinions?


Tag revisions for autoland for ongoing builds

This change adds uber.differential.autoland-if-building config option.
If option is set to true on arc land operation if revision has ongoing builds the process will add autoland tag only instead of pushing revision to SubmitQueue.

Will this require all builds? What about non-blocking (experimental) builds which weren't blocked before?

Will this require all builds? What about non-blocking (experimental) builds which weren't blocked before?

I think we'd have to test this out, but it might be good if the diff is tagged with autoland anyway. My understanding however is that arc land only checks if the compulsory buildables have passed.
Yeap, you can mark builds as blocking land (asks for approval), @pawka mentioned that you want to tackle those cases where people still say - yes let's land anyway

Yeap, you can mark builds as blocking land (asks for approval), @Pawka mentioned that you want to tackle those cases where people still say - yes let's land anyway

That's right. So based on our buildables (specifically experimental) being non-blocking, this workflow should only come active if a blocking buildable is still in progress. But I would still like to test it out once we get this change in regardless.

I have merged this PR so you could test it easily (by default this flow is disabled).
Testing flow:

Run arc upgrade to receive recent version of arcanist
Add "uber.differential.autoland-if-building": true to your local ~/.arcrc file to enable the feature. Don't forget to remove this setting later after testing.

Example of file:
$ cat ~/.arcrc
{
  "config": {
    "default": "https://.../",
    "uber.differential.autoland-if-building": true
  },
  "hosts": {
    ...
  }
}

Will this require all builds? What about non-blocking (experimental) builds which weren't blocked before?

@tyvsmith There is separate parameter on buildplans named "Warn When Landing" which can be configured.


Any instructions on how to contribute or where to chat (Discord)?

I would love to see if I could contribute to this project. If there is no chat setup maybe I could setup Discord server, config, and update readme? @joshavanier

I'm not a fan of Discord but you can contact me on Twitter if you found bugs or have ideas for improvements :)

Twitter is really inappropriate for sharing code snippets given the character limitation and no code highlighting. Especially when people have questions and want answers to their issues. I am happy to do slack or anything else of the same type if you have recommendations you like. Generally speaking though I tend to not concentrate on what I like but rather what others WILL find user friendly to ultimately contribute and use the product. The more people join, the more likely things to grow and be useful to a wider range of audience.
Also rather then just telling you about the ideas and filling up your time with more work, hoping flawlessly for you to do it, I figured I can just write the code and submit pull requests. This project has potential. I really like the simple user interface design. Input via scripts and output via gui. Brilliant.

I created a Slack workspace for this purpose and have sent you an invite (used the email on your GitHub profile). We'll see how it goes but for the meantime we can continue correspondence then.
I'm looking forward to hearing your thoughts on this. This project was one of my very first OSS projects and it's still a bit of a mess behind the scenes lol.

This is for reference if anyone looks at this issue. https://discord.gg/Ger4sFs
Please make sure to join the conversation if you have any questions.


Too early compiler choice

With the below configuration
" vim-test
let test#strategy = 'dispatch'

" vim-dispatch
let g:dispatch_compilers = {}
let g:dispatch_compilers.phpunit = 'phpunit2'

when I run, for example, :TestNearest, then :Dispatch gets ./vendor/bin/phpunit into the first argument so phpunit compiler is ignored.
Although I found a workaround by set this argument manually
let test#php#phpunit#executable = 'phpunit'

I think that test#php#phpunit#executable() first should get the proper value from the compiler definition if that exist and if it make sense. It seems that searching the executable should be the responsibility of a particular compiler.
Maybe this issue is more generic - not specific for phpunit and independent of vim-dispatch.

The thing is that test.vim isn't generally related to Vim compilers. You can use a strategy that uses compilers under the hood (dispatch.vim), or a strategy which doesn't use them at all.
The reason why test.vim cannot utilize compilers is because: (a) it would have to re-implement searching trough compiler (because it cannot rely on dispatch.vim being installed), and (b) even if it did, using the command declared by the compiler isn't necessarily what users want to be run.
For example, I'm assuming that running phpunit isn't equivalent to running ./vendor/bin/phpunit. If test.vim would choose the compiler command, users wouldn't be able to choose to run ./vendor/bin/phpunit and still use the phpunit2 compiler.
However, you can still configure dispatch.vim to use the phpunit2 compiler without changing anything in test.vim. The g:dispatch_compilers dictionary has a double functionality: in addition to the dictionary value being a compiler name, it can also be a blank string, and then dispatch.vim will treat the key as a prefix that should be subtracted, and continue the compiler lookup without that prefix.
In your case you want to ignore ./vendor/bin/ from the command, so you can specify:
let g:dispatch_compilers = {}
let g:dispatch_compilers['./vendor/bin/'] = ''
let g:dispatch_compilers['phpunit'] = 'phpunit2'

Then ./vendor/bin/phpunit ... command should be transformed into phpunit ..., which should then activate the phpunit2 compiler.


fix: the rating widget breaking on dropping issue

Description
fix Rating widget appears broken on dropping into canvas
Fixes #13612
Type of change

Bug fix (non-breaking change which fixes an issue)

Checklist:

[x] My code follows the style guidelines of this project
[x] I have performed a self-review of my own code
[ ] I have commented my code, particularly in hard-to-understand areas
[ ] I have made corresponding changes to the documentation
[x] My changes generate no new warnings
[ ] I have added tests that prove my fix is effective or that my feature works
[x] New and existing unit tests pass locally with my changes

/ok-to-test sha=4a14dd2

/ok-to-test sha=2bb7f6a

/ok-to-test sha=9b2fe81


Removal of extra dead code and using COPCORE_CUDA_CHECK for RT example.

A bit more cleanup in the ray tracer example

Can we also remove RenderTiledImage and RenderTile?

Cannot remove RenderTiledImage and RenderTile since this is used with the flag use_tiles=1

Cannot remove RenderTiledImage and RenderTile since this is used with the flag use_tiles=1

Yes I know, but does it make sense to keep this flag?


docs(tracking): update refer links to other docs with utm_source

i have backedup the OSS version, will close this PR because we'll not work on this branch anymore.


Profanity

Merging to master after successful tests on staging with new GS changes.

This should require a new version of game-test.js build.

I will be keeping this branch open for future modifications.


[feature request] Derive all transforms classes from nn.Module?

🚀 The feature
Currently it's already the case for most transform classes, except T.Compose / T.RandomChoice (these could probably be derived from nn.Sequential / nn.ModuleList). This also would not break any compat, and improve consistency and composability (sometimes only nn.Modules are accepted as parts of other existing models)
Motivation, pitch
N/A
Alternatives
No response
Additional context
No response
cc @vfdev-5 @datumbox @bjuncek

@vadimkantorov You are right to say that. There is a handful of them that don't derive from it and the reason is mainly that they might not be JIT-scriptable and that might break BC. I think there is a lot of merit to make all classes inherit from nn.Module. The new Transforms API is the place to address it (see here).

T.Compose probably is scriptable, the rest probably too if we migrate from random. to using torch random functions?

@vadimkantorov have you seen discussion from this PR (https://github.com/pytorch/vision/pull/2645), why classes like T.Compose were not derived from nn.Module etc ? TLDR, keep BC with previous versions.

Thanks for the reference! I tried to understand why deriving from nn.Sequential would existing some code, but I couldn't since the discussion is quite dispersed there.

Thanks for the reference! I tried to understand why deriving from nn.Sequential would existing some code, but I couldn't since the discussion is quite dispersed there.

First point is that we can not do basic thing like: T.Compose([T.Resize(200), lambda x: x * 0.5, my_transform_plain_function]) as lambda functions are not nn.Module and then T.Compose being inherited from nn.Module or nn.Sequential wont accept that.
To solve this we have to wrap all callables non-nn-modules with something from torchvision.
Next, if we wrap these custom functions by something then user can lose the access to its possible attributes etc. Imagine,
t = T.Compose([T.Resize(200), MyCustomTransform(*args, **kwargs)]) and t.transforms[1].call_custom_method(...). This wont be possible if we do not do some __getattr__ magic...

Thanks for explaining! Now I see!
My proposal would be:

support https://github.com/pytorch/pytorch/issues/51782 for core
support https://github.com/pytorch/pytorch/issues/55457 or introduce a separate TupleSequential (hopefully in core :))
update examples / docs for old-style examples to use TupleSequential instead of Compose
deprecate Compose at the same time of when new-style data pipes (using dicts instead of tuples) are mature and recommended

Maybe RandomChoice is more safe for conversion to nn.ModuleList, as it's not as old class

Is there now a nn.Sequential/nn.ModuleList-derived TupleSequential? Or what is the format of instances in proto? Are they now all dicts? Is there now also a nn.Module-derived T.Lambda wrapper?


Memory leak while running zqlandmarker

The ultraface seems to be leaking memory when run on 2 or more number of threads. It seems to be OK, when only 1 thread is used.
https://github.com/MirrorYuChen/mnn_example/blob/d95563833ee9dec8773485464e003c604aea83f2/src/face/detecter/ultraface/ultraface.cpp#L35
For the ZQLandmarker it leaks memory even with default 1 thread configuration.
Can you please check and confirm this at your end? By running the ZQLandmarker number of times in loop.

啥平台测试的啊？MNN库本身是否存在这个问题？

坐等官方人员回复吧，应该不是我的锅~

没有在android上测试过。

@MirrorYuChen I have posted an error thread on official MNN github. Yes, the error is observed in android, I haven't setup MNN on my PC. If you can confirm whether you observe it the same at your end, may be on PC, it will help.

没时间弄~

Closing as I have raised the issue with MNN team.

@xuguozhi

老哥有时间帮忙看一下~

Fine

I have posted android test app on https://github.com/alibaba/MNN/issues/888

有docker 的环境可模拟Android 吗？
我也想复现在手机上找問題

你这里new完之后，没有delete掉，可以再写一个析构函数，用来释放内存。

你这里new完之后，没有delete掉，可以再写一个析构函数，用来释放内存。

应该是这里

有docker 的环境可模拟Android 吗？
我也想复现在手机上找問題

用模拟器吧，读视频文件

你可以参考我写的test程序：

感觉我有时间得自己学一下android。

delete之前判断下是否为nullptr
粗略看下jni这里 :
static inline JNI_FACEDETECT *jniFaceDetect = NULL;
jniFaceDetect = new JNI_FACEDETECT; 也没有手动删除

Before deleting , determine whether it is nullptr. Look
at jni here:
static inline JNI_FACEDETECT *jniFaceDetect = NULL;
jniFaceDetect = new JNI_FACEDETECT;there is no manual deletion.

Yes, but in this case it won't matter much as the jniFaceDetect is only created once, so there should not be any continuous memory leak.
```

void LoadJniFaceDetect(JNIEnv *env) {
    **if (jniFaceDetect != NULL)
        return;**

    jniFaceDetect = new JNI_FACEDETECT;

After you finish new here, there is no delete, you can write another destructor to release memory.

I reuse the same object again and again. Yes, I should put the delete in the DestroyEngine code but currently there should not be any memory leak because of this. You can disable the landmark generation part and make the ultra face detection thread count to 1 and there won't be any more memory leak.
m_hEngineHandle = PeopleCountingEngine.CreateEngine(jszPath_Detecter_Ultraface, detecterNumThreads, jszPath_Landmarker, landmarkerNumThreads);

Yes, I should put the delete in the DestroyEngine code but currently there should not be any memory leak because of this. You can disable the landmark generation part and make the ultra face detection thread count to 1 and there won't be an

have you ever try video Camera as input data and check the memory status?

Yes, I should put the delete in the DestroyEngine code but currently there should not be any memory leak because of this. You can disable the landmark generation part and make the ultra face detection thread count to 1 and there won't be an

have you ever try video Camera as input data and check the memory status?

Yes, there is still memory leak.

@xuguozhi I have changed the numThreads for ultraface detection to 1 and disabled the landmark detection in the attached code. You can see there is no more leak, if you build the app.
MNNMemoryLeakTest.zip

Solved it on my own.

Solved it on my own.

Is there anything you want to share with us?

如何解决的能否说明一下？

I did 3 changes, but I believe 2nd one helped remove the bug.

resizeSession has to be used post resizeTensor, according to MNN docs.

        zq_interpreter_->resizeTensor(input_tensor_, {1, 3, inputSize_.height, inputSize_.width});
        zq_interpreter_->resizeSession(zq_sess_);

Do not use GetImage rather convert the image data in following way to tensor.

       cv::resize(img_face, img_resized, inputSize_);
       //     uint8_t *data_ptr = GetImage(img_resized);
       pretreat_->convert(img_resized.data, inputSize_.width, inputSize_.height, 0, input_tensor_);

Now it works correctly with sourceFormat as RGB and doesn't with previous RGBA or as the original image format (if you are using BGR mat, then use BGR).

        img_config.sourceFormat = MNN::CV::RGB;
        img_config.destFormat = MNN::CV::RGB;

好的，我这周的周末处理一下。

https://github.com/MirrorYuChen/mnn_example/issues/9

找到原因了，这个地方要释放掉内存：delete pImg

convert之后要释放掉申请的内存。

@MirrorYuChen
https://github.com/MirrorYuChen/mnn_example/blob/master/src/common/common.cpp#L10
uchar* data_ptr = new uchar[img_src.total() * 4]; new的data_ptr 要手动delete吧

嗯嗯，太麻烦了，这周周末修一下，把GetImage接口剔除掉。

嗯嗯，太麻烦了，这周周末修一下，把GetImage接口剔除掉。

用这句替换吧pretreat_->convert(img_resized.data, inputSize_.width, inputSize_.height, 0, input_tensor_); 但是用到GetImage的地方比较多，改过后要回归测试一边效果，应该问题不大

已经修了~


Updating link to CONTRIBUTING.md

DCO 1.1 Signed-off-by: Narine Cholakyan<EMAIL_ADDRESS>

Hi narinearraul,
Thanks for submitting this pull request!
Please add a comment with a DCO1.1 Signed-off-by statement in order to allow us to process your pull request.
dco-bot


Make ToProperty work properly on Indexers

In order for Data Bindings to work properly, we need to signal the right property name, in the case of indexers.

This is targeting rxui6 rather than rxui7. Is this intentional?

Yeah, I wanted to fix rxui6 first and then it can be forwardported (cherry picked) on rxui7 as well. I can do the rxui7 branch fix also.

@paulcbetts  You mentioned in the RxUI 7 TODO list:

Figure out how to make ToProperty fast but also not troll people

I think this PR will help towards the "not troll people" direction, together with the PR for rxui7: https://github.com/reactiveui/ReactiveUI/pull/1084

@kentcb Can we have this merged in rxui6 as well? Thanks!

@timotei RxUI6 is EOL, i.e there won't be any more releases. If you retarget this onto RxUI7, we can merge it

@timotei Nevermind, I just saw that you've created a separate PR for RxUI7 that already got merged

OK then. I'll close this.


Rustfmt discards newlines between #[doc] attributes and other attributes

Input
//! Some docs here
#![cfg_attr(bootstrap, doc = "xxx")]

#![cfg_attr(debug_assertions, stable(feature = "rust1", since = "1.0.0"))]

Output
//! Some docs here
#![cfg_attr(bootstrap, doc = "xxx")]
#![cfg_attr(debug_assertions, stable(feature = "rust1", since = "1.0.0"))]

Expected output
//! Some docs here
#![cfg_attr(bootstrap, doc = "xxx")]

#![cfg_attr(debug_assertions, stable(feature = "rust1", since = "1.0.0"))]

I see here why rustfmt did this - it thinks that all cfg_attr attributes should be grouped together. But this doesn't make sense in the semantic context of the program: cfg_attr(doc) is a doc-comment and should be grouped with other doc-comments. See https://github.com/rust-lang/rust/pull/80181#issuecomment-748487592 for a more realistic example.
Is there a way to disable this behavior?
Meta

rustfmt version: rustfmt 1.4.24-stable (eb894d5 2020-11-05)
From where did you install rustfmt?: rustup

Going to close as a duplicate of #4082. The context here around doc comments is helpful as additional reference cases/motivation, but fundamentally relates to the same lack of support (default or opt-in) for newlines between attrs

Is there a way to disable this behavior?

Not categorically, but #[rustfmt::skip] and/or #[rustfmt::skip::attributes(cfg_attr)] could potentially be of use


Single Menu Bar Items Enhancements

This commit targets items that act as single children items within a menu bar list, and enhances the styling so that they look and behave as items with a menu dropdown associated with them. It checks for the "aria-haspopup" attribute set to false and applies the styles.
As I read the code, I found that some CSS rules clash with other rules if I use color variables for states like hover and focus, or if I try to look for a common styles ruleset and I add a selector for it.
I believe what I added is not a good practice and does not follow a pattern because the code base became complicated to debug. In this case, I decided to inherit some styles and apply them to my selectors as I think it's a safe approach.
Looking for the author opinion before merging.
Fixes #26

Looks good! Thank you :)


View state should be accessed per-element?

I feel like this is a source of confusion with D3 3.x, in that in 3.x, the zoom behavior stores state internally on the behavior (view = {x: 0, y: 0, k: 1}) and on each selected element (this.__chart__ = view), though the latter only occurs when you apply a transition or call zoom.event. Related d3/d3#1515.
Is the zoom behavior intended to be applied to a selection of multiple elements, or just a single element? If you apply it to multiple elements, presumably you’d want their views to be independent, which necessitates storing the view state on each element independently, rather than storing it inside the behavior.
The d3-drag API seems more reasonable in this regard, in that it has accessors for determining the state of the targeted element at the beginning of a drag gesture. Could d3-zoom do something similar, where you have accessors for determining state (scale, translate) at the beginning of a zoom gesture?
I’m not totally sure how this would extend to zoom transitions. The idea would be that the zoom behavior would report the new state, but not directly modify the data or the DOM. Though presumably you could always use d3.interpolateZoom to do zoom transitions.

Some counterpoint. The d3-axis component isn’t configurable per-element, so if you apply it to a selection with multiple elements, you get the same axis in each. The d3-axis component doesn’t need to explicitly track state for transitions, however, because that state is inferred from the DOM.
So perhaps the 3.x approach is reasonable and simpler. The state on the selected element (this.__chart__) is the applied state of the zoom behavior, and is updated whenever the zoom behavior is applied to a selection via selection.call or upon interaction. The internal state of the behavior can temporarily differ if it is set programmatically before the behavior is then re-applied to the selection.

Also, d3-axis does store some stack on the elements: this.__axis.

Okay, sticking with the 3.x pattern.

So I think we will actually need per-element state, primarily because of transitions. With transitions, you set the desired target view, and then the element transitions towards that view over some time. In D3 3.x, I used a hacky solution in that the zoom behavior’s view (the “target” view) is reset to the transitioning element’s current view at the start of the transition, and then interpolates to the target view assuming the transition proceeds normally. I’m pretty sure this approach doesn’t work if the selection has multiple elements, but also it’s potentially confusing: if the transition is interrupted, say because of interaction during the transition, then the zoom behavior’s view reflects the element’s view. I suppose that’s correct, but it’s a little weird.
Anyway, I’ve implemented the new zoom behavior so that it retrieves the elements current view from element.__zoom before doing interaction or transitions. This works well, but it raises some issues related to #4, which I think we should fold into this issue: How do set the view programmatically? And how do you query the view programmatically?
Option 1 is to set the view on the zoom behavior (pass a number to zoom.scale) and then apply the zoom behavior to the selection (pass zoom to selection.call). But this doesn’t work for getting the view, because the view on the elements can subsequently change due to interaction, so the zoom behavior’s view won’t match the elements’ view.
Option 2 is to have some global methods for getting and setting the view on a per-node basis. Say, d3.zoomScale(node) returns the node’s scale, and d3.zoomScale(node, scale) sets it. But then you’d also have to use transition.call(zoom) to initiate a transition… but not if you just wanted to set it instantly on a selection? Also, what if you hypothetically wanted multiple zoom behaviors on the same element?
Option 3 is to have local methods for getting and setting the view on a per-node basis. Say, zoom.scale(node) and zoom.scale(node, scale). You’d have to use transition.call(zoom) to initiate a transition, again. If you wanted multiple zoom behaviors, we could give them different names, similar to transition namespaces (e.g., element.__zoom_foo).
Option 4 is to have local methods for getting and setting the view on selection basis. Say zoom.scale(selection) and zoom.scale(selection, scale). That’s nice because you could use selection.call to update the view, and then maybe transition.call to initiate the transition?
selection
    .call(zoom.scale, 2)
  .transition()
    .call(zoom);

Though, it’s a little weird to retrieve the scale for a given node, say on interaction, since you have to first select the node to pass it to zoom.scale. But since you’ll need the selection for updating the node’s view anyway, and chances are you already have a selection, maybe that’s reasonable.

Option 5 is to not have any getters, and require you to listen to zoom events to track an element’s state. That seems a bit lame, though, since the state is easily queried from element.__zoom.

Option 6 is to have a single local method for setting the scale and translate, say zoom.view(selection[, view]) where view is an object with scale and translate properties (like a zoom event). The nice thing about putting it in a single method is that you wouldn’t have to separately invoke transition.call for starting a transition. You could just say:
selection.transition()
    .call(zoom.view, {scale: 2});

I guess in the above example if you don’t specify a translate, you mean to preserve the current center of the viewport (as inferred from zoom.size, or as set explicitly by zoom.center), similar to double-clicking in the center or a programmatic zoom-in or -out.

Option 7 is like option 6 but somehow retains separate local methods. I’m not sure exactly how the implementation would work—it’d need to inspect the registered zoom:zoom tween and replace it?
selection.transition()
    .call(zoom.scale, 2)
    .call(zoom.translate, [0, 0]);

A related question is whether selection.call(zoom.scale) and the like should dispatch zoom events, similar to zoom.event in D3 3.x.

I need to think about how this will interact with d3-brush: does this mean that the brush component is stateless too, i.e., the brush state is stored exclusively on the element you apply the brush too? That could be nice, but it means we’ll need something equivalent to the d3.zoomTransform(node) method in this repository for inspecting the brush state of a given element, and likewise a brush.extent(selection, extent) method for setting the brush state.


Interface design of simple unified access to json, xml, yaml, etc.

Interface design of simple unified access to json, xml, yaml, etc.

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.Huiba Li seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account.You have signed the CLA already but the status is still pending? Let us recheck it.


Alarm Clock Extension

Is your feature request related to a problem? Please describe.
Alarm Clock is very essential Tool for every Student as well as professional..So I want to add a Alarm Clock Extension in this repo.
Describe the solution you'd like.
It will be made using HTML,CSS,JS and must be tested by uploading into Chrome Web Store.
Describe alternatives you've considered.
NA
Add any other context or screenshots about the feature request here.
It's not only set alarm clock it also show time ..so it also works as a digital Clock

@praniti111 @ridsuteri , please assign it to me.

will this work in the background, bcz else it would be of not much use?

any updates @Mrjoy832 ?


Don’t require global keys for Input, fixes #1828

LGTM

@collinjackson Has this change landed in the hackathon branch? If not, please cherry-pick to that branch.

Before we start cherry-picking to the hackathon branch, we should talk about whether we just want to update the hackathon branch to master tomorrow morning.


train issues

WARNING [10/15 22:01:14 fvcore.common.checkpoint]: The checkpoint state_dict contains keys that are not used by the model:
fc1000.{bias, weight}
stem.conv1.bias
[10/15 22:01:14 d2.engine.train_loop]: Starting training from iteration 0
ERROR [10/15 22:01:15 d2.engine.train_loop]: Exception during training:
Traceback (most recent call last):
File "/home/chuan/code/detectron2/detectron2/engine/train_loop.py", line 149, in train
self.run_step()
File "/home/chuan/code/detectron2/detectron2/engine/defaults.py", line 494, in run_step
self._trainer.run_step()
File "/home/chuan/code/detectron2/detectron2/engine/train_loop.py", line 273, in run_step
loss_dict = self.model(data)
File "/home/chuan/anaconda3/envs/bcnet2/lib/python3.8/site-packages/torch/nn/modules/module.py", line 1102, in _call_impl
return forward_call(*input, **kwargs)
File "/home/chuan/code/detectron2/detectron2/modeling/meta_arch/fcos.py", line 172, in forward
return self._forward_train(
File "/home/chuan/code/detectron2/detectron2/modeling/meta_arch/fcos.py", line 199, in _forward_train
loss_mask, loss_mask_bo, loss_boundary, loss_boundary_bo = self._forward_mask(features_list, proposals)
File "/home/chuan/code/detectron2/detectron2/modeling/meta_arch/fcos.py", line 251, in _forward_mask
return mask_rcnn_loss(mask_logits, boundary, proposals, bo_masks, bo_bound)
File "/home/chuan/code/detectron2/detectron2/modeling/roi_heads/mask_head.py", line 77, in mask_rcnn_loss
gt_bo_masks_per_image = instances_per_image.gt_bo_masks.crop_and_resize(
File "/home/chuan/code/detectron2/detectron2/structures/instances.py", line 65, in getattr
raise AttributeError("Cannot find field '{}' in the given Instances!".format(name))
AttributeError: Cannot find field 'gt_bo_masks' in the given Instances!
[10/15 22:01:15 d2.engine.hooks]: Total training time: 0:00:00 (0:00:00 on hooks)
[10/15 22:01:15 d2.utils.events]:  iter: 0    lr: N/A  max_mem: 962M
/home/chuan/anaconda3/envs/bcnet2/lib/python3.8/site-packages/torch/functional.py:445: UserWarning: torch.meshgrid: in an upcoming release, it will be required to pass the indexing argument. (Triggered internally at  ../aten/src/ATen/native/TensorShape.cpp:2157.)
return _VF.meshgrid(tensors, **kwargs)  # type: ignore[attr-defined]
Traceback (most recent call last):
File "tools/train_net.py", line 156, in
launch(
File "/home/chuan/code/detectron2/detectron2/engine/launch.py", line 82, in launch
main_func(*args)
File "tools/train_net.py", line 150, in main
return trainer.train()
File "/home/chuan/code/detectron2/detectron2/engine/defaults.py", line 484, in train
super().train(self.start_iter, self.max_iter)
File "/home/chuan/code/detectron2/detectron2/engine/train_loop.py", line 149, in train
self.run_step()
File "/home/chuan/code/detectron2/detectron2/engine/defaults.py", line 494, in run_step
self._trainer.run_step()
File "/home/chuan/code/detectron2/detectron2/engine/train_loop.py", line 273, in run_step
loss_dict = self.model(data)
File "/home/chuan/anaconda3/envs/bcnet2/lib/python3.8/site-packages/torch/nn/modules/module.py", line 1102, in _call_impl
return forward_call(*input, **kwargs)
File "/home/chuan/code/detectron2/detectron2/modeling/meta_arch/fcos.py", line 172, in forward
return self._forward_train(
File "/home/chuan/code/detectron2/detectron2/modeling/meta_arch/fcos.py", line 199, in _forward_train
loss_mask, loss_mask_bo, loss_boundary, loss_boundary_bo = self._forward_mask(features_list, proposals)
File "/home/chuan/code/detectron2/detectron2/modeling/meta_arch/fcos.py", line 251, in _forward_mask
return mask_rcnn_loss(mask_logits, boundary, proposals, bo_masks, bo_bound)
File "/home/chuan/code/detectron2/detectron2/modeling/roi_heads/mask_head.py", line 77, in mask_rcnn_loss
gt_bo_masks_per_image = instances_per_image.gt_bo_masks.crop_and_resize(
File "/home/chuan/code/detectron2/detectron2/structures/instances.py", line 65, in getattr
raise AttributeError("Cannot find field '{}' in the given Instances!".format(name))
AttributeError: Cannot find field 'gt_bo_masks' in the given Instances!
 How to solve this problem？
3Q

Have you addressed this issue? I met the same problem...

This error occurs because detectron2 does not read the 'bg_object_segmentation' fields in the JSON file generated by process.sh when reading the data, we can modify some codes in detectron2/data/detection_utils.py
In annotations_to_instances function,
`    if len(annos) and "segmentation" in annos[0]:
segms = [obj["segmentation"] for obj in annos]
if len(annos) and "bg_object_segmentation" in annos[0]:
bo_segms = [obj["bg_object_segmentation"] for obj in annos]
    if mask_format == "polygon":
        try:
            masks = PolygonMasks(segms)
            bo_masks = PolygonMasks(bo_segms)
        except ValueError as e:
            raise ValueError(
                "Failed to use mask_format=='polygon' from the given annotations!"
            ) from e
    else:
        assert mask_format == "bitmask", mask_format
        masks = []
        for segm in segms:
            if isinstance(segm, list):
                # polygon
                masks.append(polygons_to_bitmask(segm, *image_size))
            elif isinstance(segm, dict):
                # COCO RLE
                masks.append(mask_util.decode(segm))
            elif isinstance(segm, np.ndarray):
                assert segm.ndim == 2, "Expect segmentation of 2 dimensions, got {}.".format(
                    segm.ndim
                )
                # mask array
                masks.append(segm)
            else:
                raise ValueError(
                    "Cannot convert segmentation of type '{}' to BitMasks!"
                    "Supported types are: polygons as list[list[float] or ndarray],"
                    " COCO-style RLE as a dict, or a binary segmentation mask "
                    " in a 2D numpy array of shape HxW.".format(type(segm))
                )
        # torch.from_numpy does not support array with negative stride.
        masks = BitMasks(
            torch.stack([torch.from_numpy(np.ascontiguousarray(x)) for x in masks])
        )
    target.gt_masks = masks
    target.gt_bo_masks = bo_masks`


major improvements to nanovdb

Signed-off-by: Ken<EMAIL_ADDRESS>New features:

Added nanovdb::IndexGrid that allows for arbitrary voxel values and even multiple channels to be associated with NanoVDB grids. They are more flexible and memory efficient than regular grids at a small cost of random-access performance. IndexGrids are constructed with the IndexGridBuilder and accessed with the new ChannelAccessor.
Added iterators to tree node classes for visiting active values and child nodes
NanoVDB.h now includes standalone implementations of reading and writing uncompressed nanovdb grids buffers.
Added Stats::getExtrema, which computes the min/max values of all voxels in a NanoVDB grid that intersects with a user-defined bounding-box.

Improvements:

Added a new much improved nanovdb::NodeManager, that is both faster and more memory efficient, and that works on both the CPU and GPU. Note, it uses an handle for allocation (just like nanovdb::Grid) and replaces the old nanovdb::LeafManager which is now deprecated.
NanoToOpenVDB now works with grids templated on Fp4, Fp8, Fp16, FpN, bool and ValueMask
Numerous new member methods and utility functions were added, e.g. Mask::countOn(int) which is essential to the new IndexGrid
PNanoVDB.h (a C99 port of NanoVDB.h) has been updated

Bug fixes

Fixed a bug in nanovdb::HostBuffer that could produce crashes due to misaligned CPU memory allocations.
Fixed bug related to uninitialized memory in nanovdb::Grid which could confuse CRC32 checksum validation.
Fixed bugs related to the use of intrinsic functions for fast bit-counting

The OSX builds consistently fails and I have a strong suspicion it has to do with the failure to create a directory named "data" before the unit tests (testNanoVDB and testOpenVDB) are run. Who configured the OSX CI ? Does anyone know how to check/fix this?

The OSX builds consistently fails and I have a strong suspicion it has to do with the failure to create a directory named "data" before the unit tests (testNanoVDB and testOpenVDB) are run. Who configured the OSX CI ? Does anyone know how to check/fix this?

You can see the Mac CI configuration in .github/workflows/nanovdb.yml. Look for the macos-nanovdb job. It's extremely basic and it's passing on master. As far as I can tell you didn't change anything with this 'data' directory - why do you think this is the cause?
Ideally you should be responsible for the nanovdb CI - please take a moment to try and familirise yourself with it and have a go at debuging

fixed


not working in ios promise rejection error [Error: Error occured during initiating recorder]

Please fill the template to help you out. Also, please try the Example project compare before submiting the issue when you have certain issue with your project setup.

Version of react-native-audio-recorder-player
Version of React Native
Platforms you faced the error (IOS or Android or both?)
Expected behavior
Actual behavior
Steps to reproduce the behabior

Same issue!

https://github.com/hyochan/react-native-audio-recorder-player/issues/442
Could you check on real device?


group for menus is not intuitive

re https://github.com/Microsoft/vscode/issues/27467
At the beginning I didn't know the meaning of groups for commands in title bar, so I didn't use them at all.
After adding 3 commands, I found them all in drop down list, which is not what I want. So I add icons for all commands, I still didn't see them take effect. After playing with it for a while, I thought group navigation really mean something.
Maybe we should put it clearly in documentation about the meaning of groups here.

Groups in menu actions are not new, these exists from beginning. So actions in tree views also follow the same. navigation to be primary and others to be secondary.
@jrieken Is there a documentation for this which can be referred to?

Yeah, there is doc: https://code.visualstudio.com/docs/extensionAPI/extension-points#_sorting-of-groups.
@rebornix Were you missing the doc above or do think it's misleading/incomplete?