not ok 49 - fs_event_error_reporting

While running make check. All test cases except one : Test case no. 49 run.
The following is reported on the screen
not ok 49 - fs_event_error_reporting
exit code 11
Output from process fs_event_error_reporting:
2018-11-07 09:22 run-tests[24834] (FSEvents.framework) FSEventStreamStart: register_with_server: ERROR: f2d_register_rpc() => (null) (-21)
I have downloaded the master of version 2.0.0 and am using OSX Mojave 10.14

Does it happen with v1.x? Does it reproduce consistently or only flakily? Errno 21 is EISDIR, which is a rather unexpected error.

This happens with v 2.0
It happens each time the test is run.
I am running make check on OSX Mojave (10.14).
The build is on a SATA secondary disc
Sudheer

On 07-Nov-2018, at 3:28 PM, Ben Noordhuis<EMAIL_ADDRESS>wrote:
Does it happen with v1.x? Does it reproduce consistently or only flakily? Errno 21 is EISDIR, which is a rather unexpected error.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub https://github.com/libuv/libuv/issues/2071#issuecomment-436569149, or mute the thread https://github.com/notifications/unsubscribe-auth/ARYhI9C2u12NAqeMgc1dq62gIMD0pVh6ks5usq69gaJpZM4YRvvL.

Okay, thanks. Can you check the latest v1.x?

FWIW, @davisjam was looking into this in https://github.com/libuv/libuv/pull/1998 I think.

I also have the same issue on macOS Mojave 10.14.4 that all test cases pass except fs_event_error_reporting.
not ok 47 - fs_event_error_reporting
# exit code 11
# Output from process `fs_event_error_reporting`:
# 2019-04-11 11:40 run-tests[32529] (FSEvents.framework) FSEventStreamStart: register_with_server: ERROR: f2d_register_rpc() => (null) (-21)

Platform: Darwin Mac 18.5.0 Darwin Kernel Version 18.5.0: Mon Mar 11 20:40:32 PDT 2019; root:xnu-4903.251.3~3/RELEASE_X86_64 x86_64
Version: 89a027d862c9b84a20b0316415be169ac25dbf01 (latest version on branch 1.x)

Test Log:
./gyp_uv.py -f make
make -C out
./out/Debug/run-tests

1..358
ok 1 - platform_output
# Output from process `platform_output`:
# uv_get_process_title: /Users/zlargon/Github/libuv/out/Debug/run-tests
# uv_cwd: /Users/zlargon/Github/libuv
# uv_resident_set_memory: 5754880
# uv_uptime: 3011.000000
# uv_getrusage:
#   user: 0 sec 6202 microsec
#   system: 0 sec 3483 microsec
#   page faults: 0
#   maximum resident set size: 5754880
# uv_cpu_info:
#   model: Intel(R) Core(TM) i7-7660U CPU @ 2.50GHz
#   speed: 2500
#   times.sys: 302120
#   times.user: 336690
#   times.idle: 2373550
#   times.irq: 0
#   times.nice: 0
#   model: Intel(R) Core(TM) i7-7660U CPU @ 2.50GHz
#   speed: 2500
#   times.sys: 94640
#   times.user: 180720
#   times.idle: 2736560
#   times.irq: 0
#   times.nice: 0
#   model: Intel(R) Core(TM) i7-7660U CPU @ 2.50GHz
#   speed: 2500
#   times.sys: 199210
#   times.user: 349140
#   times.idle: 2463560
#   times.irq: 0
#   times.nice: 0
#   model: Intel(R) Core(TM) i7-7660U CPU @ 2.50GHz
#   speed: 2500
#   times.sys: 76600
#   times.user: 156530
#   times.idle: 2778780
#   times.irq: 0
#   times.nice: 0
# uv_interface_addresses:
#   name: lo0
#   internal: 1
#   physical address: 00:00:00:00:00:00
#   address: <IP_ADDRESS>
#   netmask: <IP_ADDRESS>
#   name: lo0
#   internal: 1
#   physical address: 00:00:00:00:00:00
#   address: ::1
#   netmask: ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff
#   name: lo0
#   internal: 1
#   physical address: 00:00:00:00:00:00
#   address: fe80::1
#   netmask: ffff:ffff:ffff:ffff::
#   name: en0
#   internal: 0
#   physical address: 8c:85:90:4a:f1:69
#   address: fe80::82:914a:492e:dbf2
#   netmask: ffff:ffff:ffff:ffff::
#   name: en0
#   internal: 0
#   physical address: 8c:85:90:4a:f1:69
#   address: <IP_ADDRESS>
#   netmask: <IP_ADDRESS>
#   name: awdl0
#   internal: 0
#   physical address: f6:69:74:1c:ce:46
#   address: fe80::f469:74ff:fe1c:ce46
#   netmask: ffff:ffff:ffff:ffff::
#   name: utun0
#   internal: 0
#   physical address: 00:00:00:00:00:00
#   address: fe80::eaca:9730:9a80:78cb
#   netmask: ffff:ffff:ffff:ffff::
# uv_os_get_passwd:
#   euid: 501
#   gid: 20
#   username: zlargon
#   shell: /bin/bash
#   home directory: /Users/zlargon
# uv_os_getpid: 32475
# uv_os_getppid: 32474
# uv_os_uname:
#   sysname: Darwin
#   release: 18.5.0
#   version: Darwin Kernel Version 18.5.0: Mon Mar 11 20:40:32 PDT 2019; root:xnu-4903.251.3~3/RELEASE_X86_64
#   machine: x86_64

...

not ok 47 - fs_event_error_reporting
# exit code 11
# Output from process `fs_event_error_reporting`:
# 2019-04-11 11:40 run-tests[32529] (FSEvents.framework) FSEventStreamStart: register_with_server: ERROR: f2d_register_rpc() => (null) (-21)

...


Updating to the latest version of uglifycss

We've encountered a bug with using the css calc method and when the code is minified, it removes all spaces in the calc which causes some inconsistencies in deployed environments. It looks like the latest version of uglifycss has fixed this.

:+1: Thanks for this. I've completely forgot to check new version of uglifycss.


Interfaces table contains ingress twice with two categories

If this is not a mistake, we should rethink the table format, or at least the representation on charmhub.io. Is this going to be a common pattern? I assumed, perhaps incorrectly and without data/conversations to back it up, that interfaces would have a many-to-one relationship with a category.
Either way is fine, just want to make sure we're concrete on expectations :).

They also link to the v0 of the interface, which no longer exists :D


Simplify endpoint role checking

Endpoint role-checking was redundantly applied but FastAPI provides a nice abstraction mechanic...so I applied it.
There should be no logical changes in this code. I did swap some of the HTTP 40X codes to be more appropriate to the situation.
This is mostly an incremental PR that moves things forward while I'm working on the larger authentication rewrite.

😁

I've always said the best PRs are ones which remove more than they add without compromising function.. *chef's kiss*

LGTM, Thanks for the hard work!


Alert component does not close one at a time

Hi,
I am using alert to display notification based on array of data. I have an implementation to store these notifications in db once it is closed. I tried using this code but it will close all of the notifications even I just closed one of the notification. Did I miss something?
<c-alert *ngFor="let data of notifications"
               #alertWithButtonCloseTemplate="cAlert"
               [dismissible]="dismissible"
               [visible]="visible[0]"
               (visibleChange)="onAlertVisibleChange($event)"
               color="info-gradient"
               fade
               variant="solid"
>
  <ng-template  [ngIf]="alertWithButtonCloseTemplate.dismissible" cTemplateId="alertButtonCloseTemplate">
    <button (click)="visible[0]=false" cButtonClose white></button>
  </ng-template>

{{data.header}}

</c-alert>

Thank you

you use prop visible array with index 0 for all your alerts
I'd rather use index variable with *ngFor
<c-alert *ngFor="let data of notifications; index as idx"
               [visible]="visible[idx]"
               ...
>
  <ng-template  [ngIf]="alertWithButtonCloseTemplate.dismissible" cTemplateId="alertButtonCloseTemplate">
    <button (click)="visible[idx]=false" cButtonClose white></button>
  </ng-template>
...
</c-alert>

@xidedix I tried but it will not work. Is this the correct initialization of visible variable. visible = [true,true] ?

@32x0lf
working example: https://stackblitz.com/edit/coreui-angular-smart-table-klshwt-fidpvo?file=src/app/app.component.ts

@xidedix Thanks it works.


Hoverable card in CarouselCardList component

I would like to see gallery card being hoverable in CarouselCardList component (used in NewestList & LatestSales)

How it would look like? Zoom effect?

@yangwao I can work on this once I know what effect to use, zoom or like changing the opacity a little bit?


Ingestion stops after getting the error: "ingestion rejected due to disk limit"

Describe the bug
I am using both the Ingest API and OTLP to ingest documents into a few indices in Quickwit. I'm running the default helm chart with about 10 indexer pods (2 vCPU each, 8G RAM, local attached EBS volume per pod with 250G). Peak throughput can go from ~250 to ~300MB/s, up to 35k docs/sec. Very sporadically (twice in 2 weeks), I see one of the indexer pods rate limiting all ingestion and returning a 4xx to clients. Logs will show the following error continuously:
INFO quickwit_ingest::ingest_api_service: ingestion rejected due to disk limit
INFO quickwit_ingest::ingest_api_service: ingestion rejected due to disk limit

I see no ERRORS or WARNINGs before this state and to recover, I have to clean up the queue directory on the local disk and recycle the pod. Recycling the pod is not enough since (my guess), max_queue_disk_usage (which is set to 32G) is full. Just before the rate limiting kicked in, this indexer was doing 2.3k docs/s, ~25MB/s.
More info:

Looking into the local /quickwit/qwdata EBS volume, I can see that the queues directory has reached 33G (max_disk_usage is set to 32G):
I have no name!@quickwit-indexer-0:/quickwit/qwdata$ du -h queues/
33G     queues/

There are about 257 wal files, a few created every second:
I have no name!@quickwit-indexer-0:/quickwit/qwdata/queues$ ls -al
total 33554524
drwxrwsr-x 2 1005 1005     16384 Nov 13 22:39 .
drwxrwsr-x 7 root 1005      4096 Oct 29 18:04 ..
-rw-rw-r-- 1 1005 1005        43 Jun 21 16:01 partition_id
-rw-r--r-- 1 1005 1005 134217728 Nov 13 22:17 wal-00000000000001055576
-rw-r--r-- 1 1005 1005 134217728 Nov 13 22:17 wal-00000000000001055577
-rw-r--r-- 1 1005 1005 134217728 Nov 13 22:17 wal-00000000000001055578
-rw-r--r-- 1 1005 1005 134217728 Nov 13 22:17 wal-00000000000001055579
-rw-r--r-- 1 1005 1005 134217728 Nov 13 22:17 wal-00000000000001055580
-rw-r--r-- 1 1005 1005 134217728 Nov 13 22:18 wal-00000000000001055581
-rw-r--r-- 1 1005 1005 134217728 Nov 13 22:18 wal-00000000000001055582
-rw-r--r-- 1 1005 1005 134217728 Nov 13 22:18 wal-00000000000001055583
-rw-r--r-- 1 1005 1005 134217728 Nov 13 22:18 wal-00000000000001055584
-rw-r--r-- 1 1005 1005 134217728 Nov 13 22:18 wal-00000000000001055585
-rw-r--r-- 1 1005 1005 134217728 Nov 13 22:18 wal-00000000000001055586
-rw-r--r-- 1 1005 1005 134217728 Nov 13 22:18 wal-00000000000001055587
-rw-r--r-- 1 1005 1005 134217728 Nov 13 22:18 wal-00000000000001055588
-rw-r--r-- 1 1005 1005 134217728 Nov 13 22:18 wal-00000000000001055589
-rw-r--r-- 1 1005 1005 134217728 Nov 13 22:18 wal-00000000000001055590
-rw-r--r-- 1 1005 1005 134217728 Nov 13 22:18 wal-00000000000001055591
[...]

The last wal file has the timestamp matching the first "ingestion rejected due to disk limit" log error.
Expected behavior
I don't know what is the expect behaviour after setting max_queue_disk_usage to 32G. I can see this as a protection to not allow the queue to grow unbounded, thus the rate limiting on client requests. There are 2 issues with this:

Once we get into this state, clients will always be rate limited but since the pod health check stays healthy, this pod will not be marked as unhealthy so it can not be removed from the ALB that sits in front of indexers.
What happens when the queue disk gets full? It seems the root cause might be that for some reason WAL files were not removed after successful ingestion (I assume this but it's just a guess since I didn't see any other errors before this happened and normally /quickwit/qwdata/queues on pods never grows >1G). If the rate limiting kicks in, I would expect it to last until queue disk space is available again, but this never happened.

So far, ingestion has been going on with zero issues for most of the time. I've tried to dig into wal metrics and opened the following bug https://github.com/quickwit-oss/quickwit/issues/5547 .
Thanks for your help!
Any guidance on how max_queue_disk_usage should be set would be also greatly appreciated.
Configuration:
Version: v0.8.2
node.yaml
data_dir: /quickwit/qwdata
default_index_root_uri: s3://prod-<redacted>-quickwit/indexes
gossip_listen_port: 7282
grpc:
  max_message_size: 80 MiB
indexer:
  enable_otlp_endpoint: true
ingest_api:
  max_queue_disk_usage: 32GiB
  max_queue_memory_usage: 4GiB
listen_address: <IP_ADDRESS>
metastore:
  postgres:
    acquire_connection_timeout: 30s
    idle_connection_timeout: 1h
    max_connection_lifetime: 1d
    max_connections: 50
    min_connections: 10
storage:
  s3:
    region: us-east-1
version: 0.8

CPU/Mem usage for the pod during the rate limiting (between 22:40 and 23:30)

Disk usage (%) for the EBS Volume

Long term view for storage (all pods show similar patterns), no problems with available disk space

Thanks @fulmicoton, in the meantime, I've created a quick Prometheus exporter to give me detailed metrics about wal directory usage, I can see we rarely go above ~1.5G (this is the last 24h):

I suspect an edge case may be happening here that could affect the truncation of the WAL?


compilation fail on linux aarch64 ppc64le and s390x because of -Werror=type-limits

See this example log
/usr/bin/g++ -Dloguru_EXPORTS -I/builddir/build/BUILD/loguru-4adaa185883e3c04da25913579c451d3c32cfac1 -O2 -flto=auto -ffat-lto-objects -fexceptions -g -grecord-gcc-switches -pipe -Wall -Werror=format-security -Wp,-U_FORTIFY_SOURCE,-D_FORTIFY_SOURCE=3 -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1  -mbranch-protection=standard -fasynchronous-unwind-tables -fstack-clash-protection -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -DNDEBUG -fPIC -Wall -Wextra -Werror -pedantic -MD -MT CMakeFiles/loguru.dir/loguru.cpp.o -MF CMakeFiles/loguru.dir/loguru.cpp.o.d -o CMakeFiles/loguru.dir/loguru.cpp.o -c /builddir/build/BUILD/loguru-4adaa185883e3c04da25913579c451d3c32cfac1/loguru.cpp
/builddir/build/BUILD/loguru-4adaa185883e3c04da25913579c451d3c32cfac1/loguru.cpp: In function ‘void loguru::escape(std::string&, const std::string&)’:
/builddir/build/BUILD/loguru-4adaa185883e3c04da25913579c451d3c32cfac1/loguru.cpp:571:36: error: comparison is always true due to limited range of data type [-Werror=type-limits]
  571 |                         else if (0 <= c && c < 0x20) { // ASCI control character:
      |                                  ~~^~~~
/builddir/build/BUILD/loguru-4adaa185883e3c04da25913579c451d3c32cfac1/loguru.cpp: In function ‘loguru::Text loguru::ec_to_text(char)’:
/builddir/build/BUILD/loguru-4adaa185883e3c04da25913579c451d3c32cfac1/loguru.cpp:1845:28: error: comparison is always true due to limited range of data type [-Werror=type-limits]
 1845 |                 else if (0 <= c && c < 0x20) {
      |                          ~~^~~~
cc1plus: all warnings being treated as errors

i got the same error under GCC arm-linux-gnueabihf

https://github.com/virtuosonic/loguru/ fixes this

In the new loguru package for Fedora, I’m dealing with this by just removing -Werror, which I think is too strict for downstream packaging in general:
sed -r -i 's/;?-Werror\b//' CMakeLists.txt test/CMakeLists.txt

It’s pretty clear that the warning, while technically correct, is not indicating a real problem here.
The patch https://github.com/virtuosonic/loguru/commit/e1ffdc4149083cc221d44b666a0f7e3ec4a87259 from the fork linked above does look, at a glance, like a correct way to avoid the warning without changing the code’s behavior across architectures and compilers.

The patch https://github.com/virtuosonic/loguru/commit/e1ffdc4149083cc221d44b666a0f7e3ec4a87259 from the fork linked above does look, at a glance, like a correct way to avoid the warning without changing the code’s behavior across architectures and compilers.

Actually there no risk if the variable c in the loops is signed or unsigned because it isn't modified, my next step would be to make it const.

In the new loguru package for Fedora, I’m dealing with this by just removing -Werror, which I think is too strict for downstream packaging in general:

You're probably right, when I originally wrote the CMakeLists.txt file I just added a fairly aggressive block of warning flags to ensure I wasn't breaking anything super obvious. I definitely didn't consider the impact that -Werror would have on package maintainers.
Would it be helpful to add a LOGURU_WARNINGS_AS_ERRORS cache variable, or perhaps a LOGURU_DEVELOPER_MODE cache variable that could be used to conditionally add the warning flags?
In either case, the default out-of-the-box CMakeLists.txt should definitely not have -Werror.

In the new loguru package for Fedora, I’m dealing with this by just removing -Werror, which I think is too strict for downstream packaging in general:

[…] Would it be helpful to add a LOGURU_WARNINGS_AS_ERRORS cache variable, or perhaps a LOGURU_DEVELOPER_MODE cache variable that could be used to conditionally add the warning flags?
In either case, the default out-of-the-box CMakeLists.txt should definitely not have -Werror.

Sure, a CMake option that defaults to disabling -Werror sounds like a reasonable idea. I do definitely support using -Werror in upstream development and CI.

Same issue on Nix/Darwin.

Fixed in nix by adding 2 patche, find the derivation at https://github.com/NixOS/nixpkgs/blob/f6ecda6ad047ca780874895cb98d8643c6890f6f/pkgs/by-name/lo/loguru/package.nix
This builds successfully on Linux and Darwin (macos) on aarch64 and x86_64.
@emilk would it be possible to cherry pick these patctes in the official version?


Update column type does not get reflected into Egeria

Update column type does not get reflected into Egeria. The type was change from string length 20 to string length 25 but the change to not go through to Egeria.
It looks like code in PostgresDatabaseConnector around line 883 should be uncommented then any follow-on issue debugged
                       if (egeriaColumn.getDatabaseColumnProperties().getQualifiedName().equals(postgresColumn.getQualifiedName()))                             {                             /*                             we have found an exact instance to update                              */                                 found = true;                                 //TODO                              //   updateColumn(postgresColumn, egeriaColumn);                                 break;                             }

That doesn't look like the latest release of code @davidradl or it doesn't match my version.

That doesn't look like the latest release of code @davidradl or it doesn't match my version.

See https://github.com/odpi/egeria-database-connectors/blob/main/egeria-connector-postgres/src/main/java/org/odpi/openmetadata/adapters/connectors/integration/postgres/PostgresDatabaseConnector.java . This is the latest in master and matches my comment. Is there more code that you have locally that could help here?

That piece of code looks like it's from when I was unit testing the "addDatabase" branch which makes it at least two major release behind what I have.
I unit tested the update and delete branches after this .
I've just downloaded the latest version from git hub and it's not what your looking at ?
`                  for (DatabaseElement egeriaDatabase : egeriaDatabases)
{
                    String egeriaQN =  egeriaDatabase.getDatabaseProperties().getQualifiedName();
                    String postgresQN = postgresDatabase.getQualifiedName();

                    if (egeriaQN.equals(postgresQN))
                    {
                    /*
                    we have found an exact instance to update
                     */
                        found = true;
                        updateDatabase(postgresDatabase, egeriaDatabase);
                        break;
                    }
                }
                /*
                this is a new database so add it
                 */
                if (!found)
                {
                    addDatabase(postgresDatabase);
                }
            }`

@wbittles I see that code fragment you mentioned in 'UpdateViewColumns' method
The fragment @davidradl mentioned is in 'UpdateTableColumns' method
Can you clarify how the connector/postgres works with respect to tables/columns? Maybe the code is the same, and it's just our misunderstanding (I've not tested that code path myself)

@planetf1 @davidradl  oops , I was looking at the doc for the database not updating
I have no idea why that code is like that , especially as the other call to that method isn't commented out.

I'm using the connector currently, so
Happy to test the change for column update if you plan on updating, or I can try the code change.

Closing - this repository is now being archived.


[Feature Request] rclone mount - allow files to be opened in read/write mode

eg. enable buffer files locally
If you edit file directly on mount it will be destroyed: https://forum.rclone.org/t/rclone-mount-crypt-amazon-drive-filed-destroyed-on-edit-save/645

I think this is probably a duplicate of #711 - what do you think?

Hmm yes regarding cache, but not regarding bug where file gets destroyed ( probably would be best to stick with one issue )


Fix JavaModulePathIT when testing with javassist

Works when executing the tests locally with JDK11 with this command:
./gradlew :hibernate-integrationtest-java-modules:test --stacktrace --info -Dhibernate.bytecode.provider=javassist

Thanks @yrodiere applied to master


Spec out and partially implements events

This PR:

Reorganises protobuf and generation from makefile
Fixes keys service using non-pointer receiver
Fixes keys command checking keys options for nil rather than default values
Adds events service implementing with Subscriptions but otherwise untested
Adds execution events and execution events service
Includes header information with events but currently does not set it

There is some preparatory work for persisting execution events to state, committing now as working base so others can work off the protobuf files.

The introduction of execution event wrapper means bosmarmot will need an upgrade before that integration test can pass

If nowhere else, this needs a close read on execution/state.go and execution/execution.go


Security

Hi there,
I was wondering if the request to Clam AV is in any way secured via SSL or TLS or if its possible to configure this?
Thanks,
David

I don't think so, at least not on its own, but with a little effort most things are possible. I'm looking to do exactly this, and I have a rough idea that might work

Set up a Nginx as a layer 4 (not HTTP) reverse proxy
Hope I can enable TLS-termination even though it's not HTTP, giving TLS in and a clear channel through to ClamAV

Then on my client

Open a TcpClient to the reverse proxy
Get its network stream
Wrap it in an SslStream
Do the client handshake
Pass the SslStream off to NClam, which it then uses as a normal channel to talk to ClamAV, but it's transparently encrypted from this node to the node running Clam and the reverse proxy

Though at the moment, NClam doesn't appear to accept an arbitrary stream. I'm wondering if the maintainers would be open to a pull request to open that up.

Confirmed. This can work - I have a super rough implementation working locally with a fork/PR/PoC coming after I get a chance to do some cleanup.

Okay, the PR is here: https://github.com/tekmaven/nClam/pull/33
The way I solved this was with an application connecting through a reverse proxy to get to clamd. You can think of the reverse proxy as being like an ingress controller (or otherwise just an ingress point) on a host of some kind - in this case, I'm using docker and docker-compose, but Kubernetes or some other orchestrator (or a VM deployment) could get you there as well. The important thing is that external callers don't talk to clam - they talk to the reverse proxy.
You'll need some things to follow along-

Docker
Docker Compose
An SSL certificate your computer considers valid (this can be a self-signed test cert, but you do have to trust its public key - this can be done by adding it to the Trusted People store on Windows, for example.) For simplicity, I'll be using the basic crt and key files generated with openssl, which aren't encrypted or meant for production use. Before considering a production deployment, look into options for certificate management with nginx.

Once you have those, you need an nginx config file. Here's the one I used, plus some comments:
worker_processes 1;

events { worker_connections 1024; }

stream { #layer-4 proxy
    upstream clamav { #defines the back-end for the proxy - the clamav.local service described in the docker-compose file
            server clamav.local:3310;
    }

    server {
        listen  3310 ssl; #listen on clamavd's port and enable TLS
        proxy_pass clamav; #forward traffic received on this port to the clamav backend, after handling TLS

        ssl_certificate        /etc/ssl/certs/server.crt; #the public certificate to use for TLS, loaded from the cert folder in docker-compose
        ssl_certificate_key    /etc/ssl/certs/server.key; #the private key for the certificate for TLS, loaded from the cert folder in docker-compose.
        #Note: this key is NOT ENCRYPTED - Nginx has some support for managing private keys better than this. Look into that before deploying to production.
        ssl_protocols          TLSv1.2 TLSv1.3; #Only allow recent TLS versions
                                                #protocols and cipher suites are pretty configurable, but I was aiming to keep this example simple
    }
}

And a docker-compose file to tell it which services to create and how:
version: '2'
services:
  reverse-proxy:
    image: "nginx" #default nginx image
    ports:
      - "3310:3310" #clamd's port
    volumes:
      - "./cert:/etc/ssl/certs" #My certificate is made up of 'server.crt' and 'server.key' files in a 'cert' folder - this mounts them where nginx can find them
      - "./nginx.conf:/etc/nginx/nginx.conf" #my nginx.conf from above
  clamav.local:
    image: "dinkel/clamavd" #any clam image will do

And finally, run docker-compose up to download/install/configure nginx and clamav on a virtual network, which gives you the ability to create a secure connection on port 3310 and talk to clam as-normal. Now, to do that, we need to inherit from the usual ClamClient class and override the new virtual method made by my pull request above, creating something like this:
public class SecureClamClient : ClamClient
{
   public SecureClamClient(string server, int port = 3310) : base(server, port)
   {
   }
   protected override async Task<Stream> CreateConnection(TcpClient client)
   {
      var stream = await base.CreateConnection(client); //Get the normal stream from the base class
      var secureStream = new SslStream(stream, leaveInnerStreamOpen: false); //Wrap it in a TLS-aware stream

      //Does the TLS handshake with the reverse proxy, setting up a secure channel and forcing the server to prove its identity
      //Could also implement client certificate authentication between client and reverse proxy here to lock clamav down to authorized clients
      await secureStream.AuthenticateAsClientAsync(Server);

      return secureStream; //Give the secure channel back to nClam which will use it as a regular old stream.
      //Because the reverse proxy on the other end terminates TLS, the clamd server also won't know the difference.
   }
}

And then it should work as normal when talking to the virtual network created by docker-compose above. ..I realize this is kind of a lot, but I think it solves the problem in a comprehensive way and doesn't add anything a modern container deployment wouldn't already be using.

This PR is merged!  Thanks!


ekf2: Tighten preflight GPS quality checks

Enables drift checks and reduce thresholds.
Uses ecl version that activates drift checks when vehicle is carried.
Fixes: https://github.com/PX4/Firmware/issues/9549
TESTING
See comments

Thresholds will need to be tuned through further testing.

I'm wondering if this is going to result in additional preflight failure message spam.
PREFLIGHT FAIL: GPS QUALITY POOR

Perhaps it only needs to be reported if arming is requested.

@dagar Makes sense.

It's not clear to me what information is available to a preflight check to tell if arming is being requested.

@priseborough Daniel is talking about this:
https://github.com/PX4/Firmware/blob/d3c169b1e0ee488a98704ab4783346c31e1d3e31/src/modules/commander/PreflightCheck.cpp#L647-L661
Which triggers even if GPS is not used by EKF and if the vehicle is not armed. How do we avoid this triggering regularly now?

How do we avoid this triggering regularly now?

The main reason (guessing) is that the check is disabled by default (COM_ARM_WO_GPS).
If enabled there's a hardcoded time before it starts reporting. https://github.com/PX4/Firmware/blob/d3c169b1e0ee488a98704ab4783346c31e1d3e31/src/modules/commander/PreflightCheck.cpp#L923
For continued discussion - https://github.com/PX4/Firmware/pull/10018

The additional GPS checks enabled checks in the ekf only run when the vehicle is on ground and not being moved. They will not run when in flight/armed or when IMU data detects vehicle movement. The reporting of false positives should  be managed through setting of appropriate threshold levels for the GPS tests set by EKF2_REQ_* and also the is_moving_scaler parameter which at the moment is not user adjustable. The is_moving_scaler parameter controls the sensitivity of the check that looks at IMU disturbance and determines if the user is carrying or otherwise moving the vehicle. When this happens the GPS drift checks are suspended to allow the vehicle to be picked up and relocated or hand carried without causing GPS checks to fail.
If these checks are failing, then the user should be alerted prior to commencement of GPS fusion  because failure will prevent the ekf commencing GPS fusion. We could ignore the bits associated with the drift checks once the EKF has commenced GPS fusion and accept a reduced level of protection.
I will add user adjustment of the is_moving_scaler parameter.

I ran a static test with a Pixhawk4 Autopilot and GPS (Ublox8) with a clear sky view positioned between to buildings and trees with a blockage mask angle between 20 and 45 degrees depending on azimuth. The receiver took 25 seconds to achieve a lock and another 20 seconds for checks to pass. There were no further check failures after that for the duration of the 40 minute test.

I will run additional tests  with periodic autopilot movements.

We also need to establish reasonable value for fixed wing operations that usually do not require the same GPS position accuracy.

Here are some results with the autopilot placed initially on the ground partially obscured by a tree with a mask angle of 85 degrees in the S quadrant, and brick structures with a 45 degree masks angle in the N,E,W quadrants.
There were occasional check failures. This is not a location where a reliable GPS position hold can be achieved.

At 457 seconds the autopilot was picked up and moved to the location with better mask angle that avoided much of the tree blockage.

At 487 seconds it was moved again passing underneath the tree and out into a more open area. Whilst stationary in this more open area there was one short failure of the vertical position drift test controlled by the EKF2_REQ_VDRIFT parameter at 543 seconds. This indicates that the vertical drift test is too strict or there is a problem with the calculation of the filtered drift rate.
At 593 seconds it was picked up and walked around for 40 seconds with no further check failures
I will add some temporary logging of the drift rates used for the tests to determine if  a change to the filtering or thresholds is required.
Logging of the vibe metrics used by the motion test indicates that the test should be simplified to use only the  high frequency gyro and gyro vector length. The high frequency accel metric logged in the estimator_status.vibe[2] message does not have enough margin between resting and moving to be useful:

Whereas the high frequency gyro metric does. The default threshold for this metric should be lowered from the current value of 4.0E4 to 1.0E4

The plot of gyro length indicates that the length threshold of 0.05 rad/sec is adequately detecting when the vehicle is being hand carried.

Ideas for reducing 'message SPAM' suggested so far include:

Only print when arming requested
Don't print once EKF is using GPS

We also need to establish reasonable value for fixed wing operations that usually do not require the same GPS position accuracy.

Do you want to handle that now or after this is merged? The easy short term fix is updating https://github.com/PX4/Firmware/blob/master/ROMFS/px4fmu_common/init.d/rc.fw_defaults, but if we want to properly handle hybrid VTOLs I think we'll probably need to do it dynamically in ekf2.

@dagar Given that the additional GPS checks are only relevant pre-flight in terms of enabling arming and GPS use, I think applicaton differences can be handled by amending  init.d/rc.fw_defaults

I modified the code to log the horizontal drift, vertical drift and horizontal speed using the estimator_status.vibe[0], [1] and [2] messages respectively:

This is from replay of a log recorded in a marginal location between two buildings and overshadowed by a tree. The vertical drift is peaking at 0.2 and the horizontal drift to 0.15
The vehicle was moved at 175 seconds to anclear sky location and then at 280 seconds was moved back to the bad location.
The horizontal drift threshold of 0.1 m/s and vertical drift threshold of 0.2m/s appears to be a OK starting point.
I will add some dedicated log messages to record these drift metrics to help with tuning.

Test on vehicle with noisy GPS at following locations - urban envirnment

in top of a ledge in windy conditions where there was some wind induced movement - see events at 45 and 155 seconds where the drift check is temporarily blocked.

Relocated to a more open environment at 189 seconds. Checks suspend as expected during relocation.

Relocated to a location with more tree and building obstructions at 253 seconds. Checks suspend as expected during relocation. Horizontal drift fails temporarily.

GPS receiver reported speed accuracy is high and fails checks when being relocated because this involved waking underneath a tree canopy

Rebased

Looks good to me, although we need to be aware of file descriptor limits in logger (number of topics actively logged).
Do you have a real flight log I could check quickly?

Will try to get one later today when weather (wind) improves.

I ran into issues with flipping on takeoff that were traced to the board orientation parameter being reset to 0 (no idea how that happened, and then a frsky receiver that was jamming the GPS, but after fixing those issues was able to get a short flight in POSCTL done. When checking results, bear in mind that the quad is a small 150 size vehicle and there were high winds and gusts.
See: https://logs.px4.io/plot_app?log=2a117d0c-85e9-424f-b41a-618710ad7329
The GPS receiver used was a 18x18 mm 'mini 8' and due to its small antenna is the noisiest in my collection, so makes a good receiver to check for false positives. The quad was on slightly uneven ground and due to the strong wind there was some rocking that caused running of the drift checks to be momentarily stopped.

Repeating the test indoors gave values of eph and epv that were just inside limits and a value of s_variance_m_s that was outside:

In this location, GPS position was relatively stable, so calculated drift rates were low example


MergeRecords can  support array.Float64 sort?

MergeRecords function is very useful. Thank you for providing this function. but now not support *array.Float64  sort, can we support it?
Also, could we add a reverse sorting function MergeReverseRecords？

Supporting float64 shouldn't be too difficult to add to the Less function: https://github.com/polarsignals/frostdb/blob/main/pqarrow/arrowutils/merge.go#L95-L142
We'd happily accept if you want to send a Pull Request.
Adding reverse sorting to merging seems possible. We would need to discuss what the API change would look like or if we should add another function like you proposed.
Do you have an example where sorting the records first and then merging the record wouldn't work?


refactoring

PR Checklist
Refactoring PR
Link to relevant issue(s)
Closes #122
How did you address these issues with this PR? What methods did you use?
I created a bunch of new files for structs and other functionalities to keep everything easier to find.

We have the same coverage as before so I think this is fine or can be addressed later.


[Bug] editor.action.toggleHighContrast overrides the user theme

Reproducible in vscode.dev or in VS Code Desktop?

[X] Not reproducible in vscode.dev or VS Code Desktop

Reproducible in the monaco editor playground?

[ ] Not reproducible in the monaco editor playground

Monaco Editor Playground Code
const editor = monaco.editor.create(document.getElementById('container'), {
	value: "function hello() {\n\talert('Hello world!');\n}",
	language: 'javascript'
});

editor.getAction('editor.action.toggleHighContrast').run()
monaco.editor.setTheme('vs-dark')
editor.getAction('editor.action.toggleHighContrast').run()

Actual Behavior
The resulting theme is the default light vs theme
Expected Behavior
The resulting theme should be the vs-dark theme
Additional Context
Some other related issues:

When the high contrast mode is autodetected, there is no way to disable it
If the theme is set while the high contrast mode is active, the high contrast mode is disabled
It seems there is some code referring to a light HC theme, but it doesn't seem it can be used

The toogle command should look at the current theme and toggle based on whether it is high contrast or not. I pushed a fix.
The IGlobalEditorOptions have an option autoDetectHighContrast.
We now also have a light HC light theme, but it's currently not yet used by the toggle command.

Hi @aeschli, I think you are talking about https://github.com/microsoft/vscode/commit/176257ec89695ce97c2933385862b8e68fd8a94d. It probably fix the main issue indeed, but there is a few other issues related to it
What about my PR?

Hi @CGNonofr, thanks for the PR, I didn't see it at the time when I pushed my fix.
IMO the base issue is now fixed in that the toggle action now looks at the current theme.
What your PR adds is awareness of the light HC theme. That would be great to have, so if you are interested on working on that (not just for the toggle action) that would be great. A separate new PR would be the preferred way.


Hide domain details section related with user network prefixes

Adding customer networks should not be mandatory when creating a new domain (this behavior needs to be verified).
Also, on domain details view (visible for the domain administrators) respective section should be hidden from users in order not to cause confusion.
It might be re-enabled again when setting customer networks will be also supported by other components of the system.

Section is hidden but when adding a new domain an SQL constraint exception is thrown on the backend.
When making a POST with new domain details the customerNetworks list should be empty - it seems that now it contains one empty element.


[UI] Add form to create a new mock

Add a new form component which needs to be displayed on clicking the "ADD MOCK" CTA from the dashboard
This form should get the following info from the users to create a new mock

Only make fields mandatory that are required by the API (refer swagger docs)

Mock name
Description
Route (cannot be '/' or '/mimock-ui/', '/api/mimock/, any endpoint that represents internal mimock routes)
HTTP method (Get the list of supported methods from /api/mimock/v1/static-records/http-methods)
Query params (Should load input fields to get the key + value pair on demand)
Request Header (Should load input fields to get the key + value pair on demand)
Radio button to opt for strict request header comparison (Should display a warning message for this)
Request body type (Should accept only json, form data or form-url-encoded as the type)
Request Body (Should load input fields to get the key + value pair on demand)
HTTP status code (100 =< Status code < 600 )
Response content type ( Supported types should be fetched from here /api/mimock/v1/static-records/response-content-types)
If response content type is BINARY_RESPONSE

Show a file input to upload the multipart file

If response content type is TEXTUAL_RESPONSE

Show text field to get response

Response headers (Should load input fields to get the key + value pair on demand)

Note : For input fields that are getting key-value pairs, the user should be given an option to either go for the on-demand text field option or a single text field to get the JSON encoded data. This should work interchangeably
API : Refer this from swagger docs to get the request response schema
Error handling :

Input validation errors must be handled in realtime and error messages must be displayed parallel to the input fields
If the api call fails, show an error modal at the bottom with a generic error message

Testing :

After creating a new mock, try invoking the mock endpoint along with the required parameters (query params / request headers / request body). It should return the correct response with the expected response headers
Should test creation with both binary and text response
Should test with and without request body

@neel1996 / @Nageswari-droid Is this duplicate of https://github.com/arbindo/mimock/issues/153
Let me know the difference.


Provide an Exception-based system whereby ExtensionFilter objects can raise validation errors

Throw a checked exception that stops the chain and is handled (elegantly!) by the controllers.

Merged.


Support distribute, Fixes #178

Fixes #178

This is only an option, if we really need to support Distribute.

@graingert I don't really see the harm in adding this, so I'm inclined to merge. @charlax Do you really care about supporting distribute?

:+1:, I think VCR should support whatever outdated packaging libraries that might be installed on someone's system (within reason) to lower the barrier to entry.

When would you drop support for Distribute?

I'm with @kevin1024 on this one. @graingert I'm not really sure I see a good reason to ever drop support for distribute. It's good to avoid installing extraneous packages, but I think that it's ultimately more important that this libarary works for as many people as possible.

Thanks for landing this! I actually had a similar PR I was going to submit.
I'm not sure why the setup is so outdated on the CI machine I was running this on, but in any case I agree that it's good thing to be as forgiving as possible.


Build fuzzers in dispatcher

This PR primarily completes the functions build_engine and build_benchmark_using; most other changes were bugs found while trying to make everything work.
With this code, begin-experiment.sh all can build almost all binaries and send them to google storage. "Almost all" because I've encountered a couple random builds on specific fengine/bmark combinations; I'm working through these now.

Going over the review, I think all issues have been touched on/corrected


Use unversioned GCC for runtime libraries when required.

[x] Have you followed the guidelines in our Contributing document?
[x] Have you checked to ensure there aren't other open Pull Requests for the same change?
[x] Have you added an explanation of what your changes do and why you'd like us to include them?
[ ] Have you written new tests for your changes? Here's an example.

[x] Have you successfully run brew typecheck with your changes locally?
[ ] Have you successfully run brew tests with your changes locally?

See discussion at Homebrew/homebrew-core#110010.

Review period will end on 2022-09-23 at 08:42:28 UTC.

Review period ended.

I'm a little confused by that, since this is my understanding of the conclusion of our discussion at Homebrew/homebrew-core#110010.
In any case:
This PR does not change the likelihood of needing both gcc and gcc@11 installed. Some users already need both without this change, and this PR does not change anything for them. (Nor does it change anything for users who don't need both installed.)
What this PR does change is the likelihood of needing three different versions of GCC installed. In particular, this PR makes sure that brew never forces you to have three versions installed, whereas not merging this PR will result in some users having three versions of GCC forced on them when GCC 13 comes along.
That said: needing multiple GCCs is not likely at all, at least for users who only use bottles. This is something you can always do in the default prefix (whenever a bottle is available).

I'm a little confused by that, since this is my understanding of the conclusion of our discussion at Homebrew/homebrew-core#110010.

Sorry about that.

What this PR does change is the likelihood of needing three different versions of GCC installed. In particular, this PR makes sure that brew never forces you to have three versions installed, whereas not merging this PR will result in some users having three versions of GCC forced on them when GCC 13 comes along. (This happens, for instance, if you currently need both gcc@11 and gcc@12 without this change, and then gcc is upgraded to GCC 13 and you have a formula with a dependency on gcc.)

Yeh, I'd rather we nailed down what we want to do here unless GCC 13 is landing imminently.
I'm ok with this change if we also consider bumping the compiler to gcc@12 and then ideally do something like allowing either gcc@12 or higher to be installed for folks that only need it at runtime and just gcc@12 for folks that need it from building from source.
I think we share the goal of minimising GCC versions: I think one for both runtime and building from source cases seems ideal.

Ok, here's an idea:
We make the compiler dependency a "soft" dependency, in the sense that brew install will still proceed without it installed (and use the unversioned gcc to compile), but build failures (and maybe brew doctor) will suggest a brew install gcc@11. [*]
This way, we make it a bit easier to make sure that users ever only need one GCC installed, but in the event that they need a second one, we nudge them towards the version we use in CI to maximise the probability of a successful source build.
[*] brew install proceeding and using the unversioned gcc may actually already be the current behaviour.

This way, we make it a bit easier to make sure that users ever only need one GCC installed, but in the event that they need a second one, we nudge them towards the version we use in CI to maximise the probability of a successful source build.

I'm suggesting we use GCC@12 in CI for build, too, given the weird Ubuntu libstdc++/compiler mismatch and the fact that we can just brew install gcc-12 or whatever it is in all our base images.

I'm suggesting we use GCC@12 in CI for build, too, given the weird Ubuntu libstdc++/compiler mismatch and the fact that we can just brew install gcc-12 or whatever it is in all our base images.

I don't want to use brew to install that, but maybe we can just apt install gcc-12 or something.

If we're going to install GCC for runtime libraries only: I don't really care what version it is. If we're going to install GCC for build only: it should be the same we use in CI.

Yes, I agree with this.
However, I think I'd like to punt on making the GCC we build with GCC 12 -- that will require a bit more care and coordination to avoid disruption to Homebrew/core, and I think merging this will unblock Homebrew/actions#308. We need Homebrew/actions#308 to unbreak Homebrew/core -- our publish workflow has broken because brew is not in PATH. https://github.com/Homebrew/homebrew-core/actions/runs/3132629345/jobs/5085168240#step:3:18

I do think we should just move to use GCC 12 to build everything.  There's really no point in using GCC 11 given that the GCC 12 runtime libraries are needed anyway.
I'm ambivalent about using the latest GCC at run time instead of what we use in CI.  Either we should use GCC 12 for building and runtime of C/C++ programs, and the newest GCC for building and runtime of Fortran, or we use the newest version for all runtimes, and install GCC 12 when building C/C++ programs from source.  Both of those solutions mean the user only ever has to have 2 versions of GCC installed, thought the latter choice does mean fewer users will need 2 versions installed.

Having said the above comments, I think we should probably merge this now so that we can fix the existing breakages.

I rebased to make sure tests run against the tip of master, but that turned out to be a bad idea...
Could not find 'brew' command in PATH.

https://github.com/Homebrew/brew/actions/runs/3133106631/jobs/5086140404


Sub Stores

Ability to create stores within stores. https://gist.github.com/amcdnl/6998c0dbad7af5f424dc7719527f9fb8
One idea is to create dot notation with store names like:
@Store({
   name: 'cart'
})
export class CartStore{}

@Store({
   name: 'cart.items'
})
export class CartItemsStore {}

then you hook it up like:
@NgModule({
   imports: [
      NgxsModule.forRoot([CartStore, CartItemsStore])
   ]
})
export class MyModule {}

NgModule misses the providers:[CartStore, CartItemsStore] even though that's not the point here

You dont have to here, we handle the providers for you automatically.

Good point

A more general remark from an ngrx/store guy:
shouldn't the @Store definition doesn't declare a State-like set of propertieS?

You use defaults property to handle this:
@Store({
  name: 'foo',
  defaults: { cart: [] }
})

Ok, then I like the idea :)

I like the idea. I still worry about using strings though

We can't use nested objects like that because we can't traverse them to hook them up as providers in the forRoot/forFeature methods because of AoT tracability.

This would be cool but not doable.
@Store({
   name: 'cart',
   defaults: {
      items: ItemsStore
   }
})
``

Could web make Store a generic as well?
@Store<MyStateModel>({
   name: 'cart',
   defaults: {}, // this would adhere to the model passed in
})

I don't follow how you are defining a sub store there

the only thing I am talking about is when you use strings there is no type safety

This is a tad more verbose but maybe it answers the riddle:
@Store<Cart>({
   state: (state) => state.cart,
   defaults: {}
})
export class Cart {}

@Store<CartList>({
   state: (state) => state.cart.list,
   defaults: {}
})
export class CartList {}

hmmmmmmm. I is intrigued

Essentially treating each store state input like a select. I thought it was clever

state: (state) => state.cart,

It's not completely obvious from what piece of the state it is getting the cart. Is it the app state?

Just to be a bit clear on this, what problem we are trying to solve with sub stores as opposed to having multiple stores are the root level? we should keep in mind that a feature may be lazy loaded / unloaded so it's store (or sub store) may need to be discarded.

What about this:
@Store<Cart>({
   name: 'cart',
   defaults: {},
   children: {
      items: CartList
   }
})
export class Cart {}

@Store<CartList>({
   name: 'list'
   defaults: []
})
export class CartList {}

Similar to what vuex does - https://vuex.vuejs.org/en/modules.html

Proposal:
@State<CartState>({
  selector: (state: AppState) => state.cart,
  defaults: {}
})
export class CartState {
  @Action(Checkout)
  checkout() {
    state.checkedout = true;
  }
}

@State<CartItemsState>({
   selector: (state: AppState) => state.cart.items,
   defaults: {
     moo: true
   }
})
export class CartItemsState {
  @Action(AddtoCart)
  addtocart(item) {
    state.push(item);
  }
}

@amcdnl if someone doesn't care about substates can we make "selector" optional?

The parent will need to define the children as well for tracing the dependencies.
@State<Foo>({
   defaults: {},
   children: [
      FooChild
   ]
})
export class Foo {}

so @state with replace @store?

No, you will always need the selector .
Yes, the store decorator is renamed to state in the coming 2.0

Updated proposal:
Proposal:
@State<CartState>({
  selector: (state: AppState) => state.cart,
  defaults: {},
  children: [CartItemsState]
})
export class CartState {
  @Action(Checkout)
  checkout() {
    state.checkedout = true;
  }
}

@State<CartItemsState>({
   selector: (state: AppState) => state.cart.items,
   defaults: {
     moo: true
   }
})
export class CartItemsState {
  @Action(AddtoCart)
  addtocart(item) {
    state.push(item);
  }
}

This proposal is similar to the above but with the addition of children array on the parent. This is required for state dependency resolution. For example, w/o it I would have no way of knowing that CartItemsState was associated to CartState at runtime and therefore the selector would not be able to init correctly.
Note: The selector attribute would completely replace name.

if we do the children array. do we need the selector? or can we go back to name?

Ok I got this now.... No selector, so keeping name but adding children. This will look similar to routes so it fits nicely.


Error: Cannot find module 'winston'

The problem
When my application runs I am getting Error: Cannot find module 'winston'
and the app continually restart
I ran npm install with no errors
If I run this I get...
$ npm ls winston
<EMAIL_ADDRESS>/home/wwwroot/repos/test-smart-portal-api
└──<EMAIL_ADDRESS>$
What version of Winston presents the issue?
v3.5.1
What version of Node are you using?
v14.19.0
If this worked in a previous version of Winston, which was it?
no previous
Minimum Working Example
No response
Additional information
No response

You'll need to add more detail about the importing code, and are likely to get better response asking on StackOverflow.

Apologies.  This turned out to be an unexpected side effect of a bug in pm2 the was managing the start and stop of the process doing the import

I encountered a similar issue. The main entry is missing the .js extension in package.json. The problem disappears if I provide "main": "./lib/winston.js" instead of "main": "./lib/winston"

Hmm, maybe a PR is in order then

Hmm, maybe a PR is in order then

https://github.com/winstonjs/winston/pull/2177


Better XP Conflict

There appears to be some conflict with Better XP on leaving a moon where you soft lock
console log at time of error

mods used:

Hi, thanks for the reporting the bug ! I will look at that. :)

Hopefully fixed with new version


Add quick fix to add import with prefix

There is a quick fix to add an import for an unknown type name, but when the type name is qualified the only fix suggestion is to define the class (which is not a valid fix and shouldn't be suggested). For example, enter the following code into a Dart file:
class C {
prefix.String s;
}
and place the cursor inside the identifier 'String'. It would be nice if one of the suggested fixes was to add an import (of dart:core, in this case) with the given prefix.

I like this idea.

Related to:

https://github.com/dart-lang/sdk/issues/55863
https://github.com/dart-lang/sdk/issues/41515


[Enhancement] Class defines a computed serialVersionUID that doesn't equate to the calculated value [SubscriptionItem]

Search before asking

[X] I had searched in the issues and found no similar issues.

Enhancement Request

located at:
eventmesh-common/src/main/java/org/apache/eventmesh/common/protocol/SubscriptionItem.java line 27
analysis and explanation:
This serializable class defines a serialVersionUID that appears to be a computed value, however the value does not match the computed value, and thus losses it's value as version indicator.
Describe the solution you'd like
recompute the serialVersionUID using IDE.
Are you willing to submit PR?

[ ] Yes I am willing to submit a PR!

I would like to solve this issue can you let me know how I can go about fixing this issue.

I would like to solve this issue can you let me know how I can go about fixing this issue.

Welcome, just use the IDE to recalculate the serialVersionUID.

If you do not know how to do, you can first delete line 27 of the code, set the UID, Severity default Warning can be, and then put the cursor on the class name, select Add 'serialVersionUID' field to determine.

I would like to contribute. Can you assign to me .

@ibrijesh Of course, you can submit a pr and associate an issue first.


How to restructure our Docs

Questions to Answer?

TODO - Flesh this out with the outcome of the meeting @michaeldboyd

Key Requirements

All code samples must be injected into the docs to ensure that the docs do not go out of date
All code samples should be run nightly to ensure public facing packages do not change public APIs on production
All code samples should be run immediately following a package release to verify new package is deployed
Sample walkthroughs should have tabs by language, as well as links to the relevant sample by language.
Others?

There are tickets for all of these already, I'll have to go find them.

How should the structure and content of our documentation change to best support developers who are going to use Trinsic?
Our current structure is provided from our sidebar menu:
Next steps:
[ ] Improve each SDK language page, prioritizing working code samples.
[ ] create replit sample environments for each language
[ ] Structure documentation to be code-first and language specific - each developer who visits the docs should find themselves learning in the language of their choice
[ ] improve the conceptual content to accurately reflect the v1.4 architecture and concepts

Restructuring our docs

This is a WIP issue describing what will likely become the bulk of our April Goals. Please suggest edits.

Goals: Lower time it takes to get started.

[ ] Share context and training for each person on the team

Create Replit environments @tmarkovski

[ ] Persona: Issuance & Verification portions might be separate. Will be server-side generally. We need more realistic code samples within our docs. Allow cloud and wallet holders to connect to their wallets.
[ ] Persona: Holder / Client-side integration. Verifier app on client-side. note: we need to target the verifier use-case. how to do it now and in the future. Video walkthrough on how to use it using email credential sending.
[ ] Persona: devs integrating custodial wallets on their server.

Reference Docs @lucasamonrc

[ ] Describe the calls clearly in our reference section. Clear descriptions of inputs and outputs
[ ] People LOVE the ability to send requests on the docs site. Convenient when showing clients. People love the interactivity in a demo environment. How do we do this using v2? Just having static examples is not extremely helpful. Replit maybe won't be as helpful on mobile or other configuration. There's a lot of nuance to setting up an android/ios application. If we focus on serverside examples those will be easier to set up. Much simpler to follow. Will replit work well for web client? Will require some setup.
[ ] We should embed our replits on our documentation. Benefit of vaccine demo is that we can see things all in the same place. I'd rather have people implement something on one machine before doing it separately.

Converge v1 to v2 and have a demo @michaeldboyd @MichaelEdwardBlack

[ ] How should we publish v2 on our v1 studio
[ ] Demo landing page on our website. Webinars? Product newsletter update for 1.4.
[ ] Something user facing that is a 5 minute getting started guide. All focus on it to produce a getting started guide to have a completion of our guide. All of us should be involved because we have context into SDK and platform.

CLI Tooling @sethjback

[ ] After people create their ecosystem, we can bootstrap some sample data so that there's something there. trinsic ecosystem create demo. Readme and video walkthrough with replit environment.
[ ] Having people run commands in the CLI and/or a single SDK that is readable. An interactive shell. CLI is very versatile. It is meant to build, test, and manage an ecosystem. We can embed useful scripts and programs within the CLI. It has built in interactivity.
[ ] add logging, events, and testing functionality for developers building ecosystems.

Testing and Release Automation @fundthmcalculus

[ ] Test mobile apps clientside?
All code samples must be injected into the docs to ensure that the docs do not go out of date
All code samples should be run nightly to ensure public facing packages do not change public APIs on production
All code samples should be run immediately following a package release to verify new package is deployed
Sample walkthroughs should have tabs by language, as well as links to the relevant sample by language.

@michaeldboyd I think the hierarchy of the content on the docs site looks very good. A few things I'd add:

Home, Getting Started, What is Trinsic?, Before you Start, Try the Walkthrough. These are 5 clickable things that could really all be 1 (or 2) things. I suggest having a "welcome/introduction" page and a "Quickstart" page. One beginner/informational, the other beginner/hands-on.

Under Key Concepts, I'd add something about verifications, as that is one of the most important concepts and a key metric we'll be tracking in production.

I wonder if there is a way to make the SDK Reference section simpler. Having 8 different sub-pages/services is a little overwhelming. Do I need to educate myself on all these before I get started?

@fundthmcalculus In terms of demos, there are inspirational ones (e.g. trying to help people catch the vision) and there are tactical ones (e.g. I know what I want to build, show me an example of it). In terms of inspirational, we should have a demo like https://www.dwolla.com/resources/interactive-demo/. In terms of tactical, I see 2 primary things our target customers are doing. 1. Creating wallets for users (mobile + web), 2. Creating ecosystems for companies (server + web). We should build both kinds of demos but I think the more important priority in the short-term is the tactical demos.

I wanna copy stripe cli docs verbatim for our cli. It's well organized, practical, and informational.


Portals - Fix UI default

I had forgotten to add a call to update_portal_tools() at the end of the SpatialEditor constructors. This ensures that the portal UI is off by default in normal use without portals.
Notes

Sorry my bad, this was working during production but I must have removed this call at some point. This will have resulted in the 'convert rooms' button showing even if no RoomManager was present.

Thanks!


Dependencies issue with python-coveralls

I tried to clone inventree and hit make install on archlinux. I got an issue with pip installing the dependencies. I then tried to make a Docker file based on python:3. It also failed, to reproduce I did:
FROM python:3
ADD . /inventree
RUN cd /inventree && make install

The error logs is:
ERROR: python-coveralls 2.9.1 has requirement coverage==4.0.3, but you'll have coverage 4.5.4 which is incompatible.

I am testing with v0.0.7-24-g54855da.

HI @nickoe if you change line 16-17 of requirements.txt to:
coverage==4.0.3                 # Unit test coverage
python-coveralls==2.9.1         # Coveralls linking (for Travis)

is the problem fixed?
I really need to make a python virtual-env setup for this, the requirements file has grown pretty big now...

Yes, setting coverage==4.0.3 works.
So we need a specific version of coveralls?
I am no expert here, but I would have expected latest versions of everything to be ok on master.

It is an interdependency issue between coveralls and python-coverage. I have not personally picked those specific versions for my own preference, but due to requirements of other packages. It's annoying, but at least the requirements.txt takes care of it.

Ok, thank you.


follow naming convention

our name should not be mentioned in the filename neither does tasks name. Name should be according to its function.

our name should not be mentioned in the filename neither does tasks name. Name should be according to its function.


December Iteration Plan

After a major effort like the November Beta release the team does need some well deserved decompression. During this decompression period we still want to be responsive to issues raised by the community, but we also want to work on debt reduction, tune our own development process, and do some explorations. This also means that we will not start working on new big rock features, so work on code folding will not start yet, but do not worry, it will come.
For more information about our development process please refer to the development process page.
Dates
The goal is to make the December update available before the holidays

stable channel updated on Dec 18th
insider channel updated on Dec 14th. This enables community members to test a candidate build at the same time as we do. For more information on the insider channel refer to Test Prereleases

Plan Items
Performance
We care a lot about performance...

[ ] Add telemetry to measure startup time #707 @SofianHn

We had a startup performance regression (#335) that required a recovery build. We would like to avoid this in the future.

[ ] Investigate into a fix for the slow loading of files with multi byte characters #94

Investigate into a contribution for atom/node-oniguruma#45 @alexandrudima

Feedback
Issues to address feedback from the community:

[ ] Editor: It is difficult to deal with keybindings when using non-US standard keyboard layout #713 @alexandrudima
[ ] API: Expose more editor commands as API #913 @jrieken
[ ] API: Investigate deactivate() on shutdown call for an extension @alexandrudima

Issues: #113, #941, Microsoft/vscode-go#26

[ ] API: Support to contribute a JSON schema for a file pattern from an extension #489 @aeschli

This enables extensions like jshint or eslint to get JSON validation for their configuration files.
Issue: Microsoft/vscode-jshint#4

[ ] API: Investigate into how we can provide more support for the VIM extensions

Issues: #300, #575, #561,

[x] Gallery: Improve experience when user wants to read the README.md before installing an extension #914 @joaomoreno

Issue: #727

[x] Git: Support git integration when git folder is in a parent folder #863 @joaomoreno

Issue: #863

[x] Git: Add a pull with rebase action to the git viewlet #907 @joaomoreno

Issue: #150

[ ] JS: Simplify using ES6 @jrieken

Issue: #337

[ ] JS Enable ES6 coloring by using the TypeScript textmate grammar @aeschli
[ ] Debug: Improve presenting long text values inside the debug console @isidorn

Issues: #503

Debt Items
This section lists items to reduce our engineering debt:

[ ] Proposal for separating the vscode tools from the vscode API of the existing vscode module #970 @bpasero

Currently the vscode node module combines the tools and the vscode API into one unit, we want to decouple the API from the used modules.

[ ] Automated Mac signing @joaomoreno

The builds we publish need to be signed and this process isn't as automated yet, as we would like.

[ ] Increase test coverage @Microsoft/vscode
[ ] Debug: Provide a test suite for debugger adapters @weinand
[ ] Language services - Document the language services protocol @dbaeumer

Adoptions
We continously have to adopt components which we require:

[x] Adopt electron version 0.34.5 #826 @bpasero

We usually update to new version of electron. This version addresses atom/electron#3349

[ ] Adopt TypeScript 1.7 #836  @dbaeumer

Investigate into using async/await in extensions

[ ] Adopt the a newer version of OmniSharp @jrieken

Engineering Items
This section lists several engineering/development items that the team identified:

[ ] Run VSCode unit tests headless in a CI setup  @bpasero

Issues #912 #779

[x] Support a command line switch to launch Code without any extensions #708 @bpasero

Simplify diagnosing issues caused by extensions.

[x] Move C# into a separate extension @jrieken

Enable the ASP/Roslyn team to eventually take over this extension

[ ] Extensions: warn the user when contributions conflict @isidorn
[x] Extension host debugging: change to a model where VS Code triggers reattach (instead of polling) #855 @weinand @bpasero @isidorn
[x] Support to define and preserve the zoom state of VS Code #291 @bpasero

This was a real pain during the recent demos.

[ ] Git: Make it easy to submit a pull request/create and publish a local branch @joaomoreno

We do a lot of PRs and we want to simplify the flow.

[ ] Debug: Provide npm modules for the debugger protocol (client, server) @weinand
[ ] Complete the language service protocol and add more Code language features to the language service protocol @dbaeumer
[ ] Debug: Provide Conditional break point support @isidorn @weinand

Explorations
We also do some explorations:

[ ] Investigate into Salsa (Microsoft/TypeScript#4789) adoption with the TypeScript team
[ ] Explore integrated TypeScript building/transpilation #973 @dbaeumer
[ ] Explore: Improved Intellisense support to show documentation for a  completion item #369 @joaomoreno

Bugs
This section includes bug queries for the vscode related repositories:

vscode
vscode-vsce
vscode-node-debug
vscode-mono-debug
vscode-loader
vscode-textmate
vscode-generator-code
vscode-languageserver-node

Sneak in https://github.com/Microsoft/vscode/issues/507 maybe?

@Stanzilla thanks for reviewing, request makes sense, but let's do the sneaking once all the other work is done.


python311Packages.bx-py-utils: 80 -> 88

Description of changes
Diff: https://github.com/boxine/bx_py_utils/compare/refs/tags/v80...v88

Things done

Built on platform(s)

[x] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)

[ ] sandbox = relaxed
[ ] sandbox = true

[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[x] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[ ] Tested basic functionality of all binary files (usually in ./result/bin/)
23.11 Release Notes (or backporting 23.05 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[x] Fits CONTRIBUTING.md.

Priorities
Add a :+1: reaction to pull requests you find important.

Result of nixpkgs-review pr 270320 run on x86_64-linux 1

9 packages built:

home-assistant-component-tests.abode
python310Packages.bx-py-utils
python310Packages.bx-py-utils.dist
python310Packages.jaraco-abode
python310Packages.jaraco-abode.dist
python311Packages.bx-py-utils
python311Packages.bx-py-utils.dist
python311Packages.jaraco-abode
python311Packages.jaraco-abode.dist


👀 Aggregate Design: Using Invariants as a Guide

https://www.youtube.com/watch?v=64ngP-aUYPc

Thinking about aggregates

Can the stops (Delivery or Pickups) exist without the shipment?
Aggregates inforce invariants
Invariants are business rules that must always be consistent
If a relationship between two entities must be enforced, then they must be part of an aggregate
In other words, aggregates can be used to enforce invariants that span across multiple objects
The recommendation is to always be in a consistent and valid state


accept and parse function not work well with a pure number string

When parse and accept a string, if the string is pure number string like "123"
accept will return true(it looks a error result)
parse will not throw a exception(I think it is wrong, It should throw a expection)
after parse we use this object to emplace it throw a expection json.exception.type_error.311
Example code:
using namespace nlohmann;
int main(){
    auto j = json::array();
    std::string my_input = "123456";
    if (json::accept(my_input)){
        std::cout << "it is a json" << std::endl;
    } else {
        std::cout << "it is not a json" << std::endl;
    }
    try
    {
        j = json::parse(my_input, nullptr, false);
        std::cout << "is_discarded: " << (j.is_discarded() ? "true" : "false") << std::endl;
        std::cout << "j.dump(): " << j.dump() << endl;
    }
    catch (json::exception& ex)
    {
        std::cout << "parse error reason: " << ex.what() << std::endl;
    }
    try {
        j.emplace("123","23");
    } catch (json::exception& ex) {
        std::cout << "emplace error reason: " << ex.what() << std::endl;
    }
    return 0;
}

The result output is :
it is a json
is_discarded: false
j.dump(): 123456
emplace error reason: [json.exception.type_error.311] cannot use emplace() with number
nlohmann::json version : 3.10.2
gcc version:
Apple clang version 13.0.0 (clang-13<IP_ADDRESS>)
Target: x86_64-apple-darwin20.6.0
Thread model: posix

This sounds reasonable:

123456 is valid JSON, therefore accept returns true.
With j = json::parse(my_input, nullptr, false); you overwrite j which was an empty array, but is now a number.
You then call emplace which only works with objects or null (see https://json.nlohmann.me/api/basic_json/emplace/ or https://json.nlohmann.me/home/exceptions/#jsonexceptiontype_error311)

Thx for help


Implement missing OpenMP kernels

The purpose of this  issue is to have a full OpenMP implementation of the kernels before the Ginkgo release 1.0.0.
Here is @hartwiganzt's original comment on this issue:
On the OMP issue: there are in total about 25 NOT_IMPLEMENTED in the omp branch.
I would say: let's copy complete those - in the worst case with the reference
implementation and some note saying that this still needs to be parallelized.

One way to do this is to copy the reference kernels and add some simple parallelization when possible. When doing so, it is very important to add a note in the README that the OpenMP implementation is present but needs major improvement, or is not fully parallelized (depending on the case).
On a related issue, two OpenMP tests seem particularly long. The COO test is definitely very long (in valgrind it reaches the timeout of 1500 seconds, whereas the others take around 200 seconds!). The CGS solver test also seem to possess some issues, but not to the severity of the COO one.

Closing this as this is now either done, or tracked by #286


Fixing GitHub apps docs yaml

Hey, I just made a Pull Request!
Fixed documentation rendering of the app-config.yaml file for using githubApps

:heavy_check_mark: Checklist

[ ] A changeset describing the change and affected packages. (more info)
[ ] Added or updated documentation
[ ] Tests for new functionality and regression tests for bug fixes
[ ] Screenshots attached (for UI changes)

Tugboat has finished building the preview for this pull request!
Link:

https://pr4533-3z5u5yqpyewn8vmjdgllfmcdhxssple9.tugboat.qa

Dashboard:

https://dashboard.tugboat.qa/602a7c82fcb22d56ae55e84b


[View/add/edit observations] Sort fields by index defined in form

Fixes #396.

Thanks @shobhitagarwal1612, RFAL!

Working now, thanks for the help! 🚀


Fix router filter configuration suppress_grpc_request_failure_code_stats

Title: Fix router filter configuration suppress_grpc_request_failure_code_stats
Description:
The PR that originally built this boolean's original goal was to disable HTTP failure status codes such as 4xx/5xx. It also unintenionally disabled upstream_rq_completed codes.
Original PR: https://github.com/envoyproxy/envoy/pull/16812
Original Issue: https://github.com/envoyproxy/envoy/issues/16667
The PR I made effectively disables the helper function chargeBasicResponseStat() See code snippet:
https://github.com/samrabelachew/envoy/blob/f1f1fae37ebde9bc024fd839053b8312cd0e5923/source/common/http/codes.cc#L62-L82
This fix will be a small change to update the function to exclude disabling upstream_rq_completed stats when boolean is set.

/assign


How to close logs

![image](https://user-images.githubusercontent.com/25858040/233909318-b6430d20-c5a0-4c4f-8d4c-9b18b913ff1f.png
What should I do to close all Info logs ?

我也想知道，你可以添加一个关闭日志选项吗

I would also like to know, can you add a turn off logging option

Yup. you can provide your own logger that works however you like. WithConsumerOptionsLogger accepts an interface


Iteration ending & planning meeting (w/ instructor)

Classroom meeting conducted every week.

Classroom meeting is conducted


Streamline building using the gcc crate

Currently tcod-sys builds using make while trying to detect the system it's on. It makes mistakes with newer versions of MSYS2 and MSVC versions of rustc. Replacing the makefile system with a system that makes use of the gcc crate will streamline compiling and will allow it to automatically use the VC++ compiler if needed.

I haven't looked at the gcc crate much yet, but yeah, looks like it'd work. On the other hand, the makefiles aren't really trivial so I'm not too hot on reimplementing them.
I wonder whether fixing the detection code (to differentiate between the mingw and msvc targets) might be safer.

On a MSVC platform, it's unlikely make is installed at all in the first place. A good middle-ground for now would be to actually fix the mingw make file for the newer versions of MSYS2 (which is now the recommended way to install mingw).

Of course, that makes sense. Back when I tried it on Windows, MSVC wasn't supported yet but we definitely want to provide it. So yeah, +1 to that idea.
Can you be more specific about the MSYS2 fixes? I'm not terribly familiar Windows dev unfortunately :-(.

It's a simple difference, in MSYS2 if you install gcc, the command isn't prefixed anymore by "mingw32-".

The #214 pull request closes this issue. Thanks & sorry for the time it took me to do this.


Add an ObserveAt observation builder which is observed at an explicit point in time

I had an idea around contingent claims and it turns out it could be implemented rather quickly.
The problem:

observations within a scale node are evaluated at t = the acquisition time of the sub-contract
this makes it cumbersome to write expressions for an observable which is observed at different points in time

Ex.1 performance-linked payoff
The Observation in this case is of the form S(t_1) / S(t_0) - 1
Currently we need to write this as
when (at t_0) $ scale (Const 1.0 / Observe S) $ when (at t_1) $ scale(Observe S) payoff and when (at t_1) $ give payoff
This expression is rather hard to read and the payoff sub-claim is duplicated.
Ex 2. rate compounding
Rate compounding is currently implemented in a fashion similar to the above (a nested sequence of When and Scale nodes).
The approach:

Introduce an ObserveAt combinator in the Observation, allowing the user to explicitly specify the observation time t'

The above performance payoff would become
when (at t_1) $ scale( Observe S / ObserveAt S t_0 - Const 1.0) one payoff
The compounded payoffs would contain a single scale node instead of nested when and scale nodes.
I feel that this expression

is easier to read
has a smaller footprint (payoff used only once)
can be faster to lifecycle, given that we don't enter the outer When node for t < t_1
makes it easier to apply appropriate rounding (as we can condense the to-be-rounded expression in a single scale node)

I need to spend some time thinking about the valuation semantics for the ObserveAt node, but happy to hear your thoughts!

A drawback I see with this approach is the following: consider the following contracts, acquired at t_0 < t_1 < t_2

C1 : scale (ObserveAt S t_1) $ when (at t_2) one USD
C2 : when (at t_2) $ scale (ObserveAt S t_1) one USD

C1 and C2 are equivalent, however lifecycling C1 for t < t_1 is likely to incur in an error (as the observation is unavailable before t_1). On the other hand, C2 can be lifecycled without issues.
This can be solved by implementing https://github.com/digital-asset/contingent-claims/issues/71 (that is, evaluating scale nodes only when the number is needed to calculate a pending payment)

A drawback I see with this approach is the following: consider the following contracts, acquired at t_0 < t_1 < t_2

C1 : scale (ObserveAt S t_1) $ when (at t_2) one USD
C2 : when (at t_2) $ scale (ObserveAt S t_1) one USD

C1 and C2 are equivalent, however lifecycling C1 for t < t_1 is likely to incur in an error (as the observation is unavailable before t_1). On the other hand, C2 can be lifecycled without issues.
This can be solved by implementing #538 (that is, evaluating scale nodes only when the number is needed to calculate a pending payment)

Actually, this change makes it rather easy to implement #538 --> https://github.com/digital-asset/daml-finance/commit/0bc8f6a1e0c0bd9f1267ccdfa528531d586def16

I've had a look at your document and I'm not convinced that the advantages of adding a new element to the sum type outweighs the disadvantages. It seems like one of the main reasons for wanting this is having simpler syntax, and adding a small combinator goes part of the way to addressing this. The thing that I really think is a bad idea is admitting 'invalid' trees. Even if we can 'check' the trees for correctness dynamically, I prefer to code defensively, so that we can prevent admitting invalid versions. It might change my mind if we could show that there are some new types of contracts that we can model by such an addition, but as far as I understand this won't really change the semantics.

Thanks for reviewing!
You are right that currently we are not changing the semantics. This is because

we can decompose any observation in the form obs1 x obs2 x obs3 x ... + obs4 x obs5 x obs6 + ... + ... + ...
then we just need to order the observations in time-increasing order and can then express any block as When (t1) Scale obs1 When t2 Scale obs2 When t3 Scale obs3 ... (although this would lead to a very space-consuming tree representation)

I feel that it would be a different story once we include rounding of observations. That is, if we want to model a contract that says "take (obs1 + obs2) x obs3 and round it to 3 decimal places". In that case, the above does not hold.

I need to spend some time thinking about the valuation semantics for the ObserveAt node, but happy to hear your thoughts!

Wondering if you had any more insights on this for our conversation this afternoon?

I need to spend some time thinking about the valuation semantics for the ObserveAt node

Wondering if you had any more insights on this for our conversation this afternoon?

The valuation semantics is well-defined as long as the observation process is adapted. Otherwise, it is ill-defined.


Implement WebResource node type

I'm planning to implement a simple WebResource node type, that just refers to an url to a content piece somewhere stored on the web. We could literally support anything but I think we should start wit a useful set of supported embeds.
How about the following types:

Image (allow just a regular image url)
Tweet (possible using oEmbed API see: https://api.twitter.com/1/statuses/oembed.json?
url=https://twitter.com/Interior/status/463440424141459456)
Youtube (http://www.youtube.com/oembed?url=http%3A//youtube.com/watch%3Fv%3DM3r2XDceM6A&format=json)
Vimeo (also supports oEmbed see https://vimeo.com/api/oembed.json?url=https%3A//vimeo.com/76979871, https://developer.vimeo.com/apis/oembed)

Implementation idea:

When user presses the insert resource button they get prompted with an url input field
We do some analysis of the url (if it contains youtube/vimeo/twitter and query the corresponding oembed API's to get the corresponding embed codes, which we store on an html property of the node

Concerns:

Security? We need to make sure the html content is safe when we render it
We may get a jumpy interface, because embeds are dynamically fetching content such as images etc. we need to make sure the scrollbar stays up to date etc.

Consider: http://iframe.ly

And this: https://github.com/itteco/iframely

Thanks @Integral. This is now implemented. And we use iframe.ly but can configure a different embed Resolver.

Is it good that we have this kind of service dependency?

We don't have it as a dependency. It's a configuration option.
See: https://github.com/substance/lens/blob/master/LensController.js#L59-L67


The troubling Situation!

Things are not working out sergeant.
We couldn't access vueman.ga.
Seems like some enemies have taken over this domain name. We need to get it back immediately.

Thanks for the report, I'm aware that the domain has expired. Let's get it back sometime.
Meanwhile - https://vuemanga.netlify.com/


Bump version: 0.3.0 → 0.3.1

Codecov Report

Merging #30 (9f930d9) into main (ecd59a0) will increase coverage by 4.80%.
The diff coverage is 100.00%.

:exclamation: Your organization is not using the GitHub App Integration. As a result you may experience degraded service beginning May 15th. Please install the Github App Integration for your organization. Read more.
@@            Coverage Diff             @@
##             main      #30      +/-   ##
==========================================
+ Coverage   92.51%   97.32%   +4.80%
==========================================
  Files           6        6
  Lines         254      262       +8
  Branches       30       27       -3
==========================================
+ Hits          235      255      +20
+ Misses          9        3       -6
+ Partials       10        4       -6

Impacted Files
Coverage Δ

clip_bbox/clip_model_setup.py
100.00% <ø> (ø)

clip_bbox/bbox_utils.py
93.67% <100.00%> (+10.52%)
:arrow_up:

clip_bbox/clipbbox.py
100.00% <100.00%> (ø)

clip_bbox/preprocess.py
100.00% <100.00%> (+6.25%)
:arrow_up:

clip_bbox/tests/test_all.py
100.00% <100.00%> (ø)


AWS IoT MqttException(0) : Already connected, Similar to #131.

Hi, Can I connect AWSIotMqttManager use Sample Cognito Developer Authentication? Thank you.
I have run CognitoSyncDemo and AndroidPubSubWebSocket successful.
The way CognitoSyncDemo is used 8.To add support for Developer authenticated identities using the Sample Cognito Developer Authentication application (Optional).
The way AndroidPubSubWebSocket is used Developer Unauthenticated.
Now, I got DeveloperAuthenticationProvider in CognitoSyncDemo. Next, I use DeveloperAuthenticationProvider connect to AWSIotMqttManager.
in CognitoSyncDemo-CognitoSyncClientManager add method code:

public static void connectIot() {
AWSIotMqttManager mqttManager = new AWSIotMqttManager("correct", "correct");
mqttManager.setAutoReconnect(false);
mqttManager.connect(credentialsProvider, new AWSIotMqttClientStatusCallback() {
@Override
public void onStatusChanged(final AWSIotMqttClientStatus status, final Throwable throwable) {
Log.d("connectIot", "Status = " + String.valueOf(status) + " throwable:" + throwable);
}
});
}

in CognitoSyncDemo-DeveloperAuthenticationTask line 61 add code:
CognitoSyncClientManager.connectIot()
Now, I login use with MainActivity-btnLoginDevAuth.
When method-connectIot() running is completed.
I got Log and can't use AWSIotMqttManager:
com.amazonaws.cognito.sync.demo D/connectIot: Status = Connecting throwable:null com.amazonaws.cognito.sync.demo D/connectIot: Status = ConnectionLost throwable:MqttException (0) - java.io.IOException: Already connected
I want to get Authentication AWSIotMqttManager, what should I do?

it's good now, lack policy.
aws iot attach-principal-policy --policy-name PubSubPolicy --principal us-east-1:uuid(user id)


Local test failure

Description of the bug
SAMTOOLS_SORT is failing in local tests (-profile test, docker), but working on farm (-profile test,sanger,singularity):
ERROR ~ Error executing process > 'SANGERTOL_VARIANTCALLING:VARIANTCALLING:INPUT_MERGE:SAMTOOLS_SORT (icCanRufa1_cram_T1)'

Caused by:
  Process `SANGERTOL_VARIANTCALLING:VARIANTCALLING:INPUT_MERGE:SAMTOOLS_SORT (icCanRufa1_cram_T1)` terminated with an error exit status (1)

Command executed:

  samtools cat \
      GCA_947369205.1.unmasked.pacbio.icCanRufa1_0_3.cram \
  | \
  samtools sort \
       \
      -T icCanRufa1_cram_T1 \
      --threads 2 \
      --reference GCA_947369205.1_OX376310.1_CANBKR010000003.1.fasta.gz \
      -o icCanRufa1_cram_T1.bam \
      -

  cat <<-END_VERSIONS > versions.yml
  "SANGERTOL_VARIANTCALLING:VARIANTCALLING:INPUT_MERGE:SAMTOOLS_SORT":
      samtools: $(echo $(samtools --version 2>&1) | sed 's/^.*samtools //; s/Using.*$//')
  END_VERSIONS

Command exit status:
  1

Command output:
  (empty)

Command error:
  [main_cat] ERROR: input is not BAM or CRAM
  [W::hts_set_opt] Cannot change block size for this format
  samtools sort: failed to read header from "-"

Command used and terminal output
No response
Relevant files
No response
System information
No response

Not high priority. It is some sort of arm incompatibility -- works fine if I run a terminal with rosetta emulation


Parent View disappears when dismissed.

i found a problem. i present the PhotoBrowser from a uitableviewcell, when it is dismissed, the content of the cell is gone.

I updated this issue in v2.1.x.
Please create new issue if it still have problem.


Keystatic does not respect the "owner" value in the config file for GitHub Mode

This is a critical issue. And as the title says, basically.
I've noticed on the #astro channel in the Keystatic Discord server that anyone can go to the /keystatic path and authorize via GitHub, and Keystatic will happily let them in.
This happens both when repo has the owner and repo properties or when repo is a template literal (GITHUB_OWNER/GITHUB_REPO_NAME).

This is intentional behaviour, the owner field is just to refer to the repo, not the only person who can access it. The GitHub app allows anyone to login and they will have access to it depending on if the repo is public and their permissions on the repo.


add a snapshot feature

Add a snapshot feature
arm_now snapshot -h
snapshot create [NAME]: create snapshot of the current VM
snapshot list: list all available snapshot
snapshot use [NAME]: overwrite the current VM with the snapshot [NAME]
use case
$ arm_now start x86-i686
# do some config
# poweroff
$ arm_now snapshot create MyBestVM
$ arm_now snapshot list
MyBestVM: maybe add a description here
$ arm_now start
# run some malwares or not trustworthy things
# poweroff
$ arm_now snapshot use MyBestVM
$ arm_now start
# Just go back in time

I'll try to do that this weekend my man :)


Improve Sphinx documentation

There is a Sphinx documentation atm, but right now it looks a bit rubbish.

Now have somewhat reasonable documentation site here.


GuzzleHttp\Psr7\Uri Incorrectly filled port, when converted to a string

PHP version: 8.2.7
Description
Incorrect port filtering for url in \GuzzleHttp\Psr7\Uri::filterPort
How to reproduce
Call the \GuzzleHttp\Psr7\ServerRequest::getUriFromGlobals() function if $_SERVER['SERVER_PORT'] contains an empty string and $_SERVER['HTTP_HOST'] does not contain a port.
In the case when the port is empty, null is converted to 0 and we get the link https://mysite.com:0/
Possible Solution

https://github.com/guzzle/psr7/blob/815698d9f11c908bc59471d11f642264b533346a/src/ServerRequest.php#L223
Change validation to if (!$hasPort && $_SERVER['SERVER_PORT']) {
Additional context

When does server port ever contain an empty string?

Sorry my mistake. Should not be an empty string, found where assigned.


Bump minimatch version to >=3.0.2

According to NSP https://nodesecurity.io/advisories/118, minimatch is vulnerable to a regex DoS attack. Better to explicitly bump it to >= 3.0.2.

Fixed in v7.0.5 - this should be closed


[Compose Web]: TypeError: content is not a function

Having issue on web after upgrading compose version from 1.7.0-dev1686 to new versions > 1.7.0-dev1698

Also bumped into this crash.

@terrakok even after upgrading to the latest version 1.7.0-alpha01 the issue still exists

Using kotlin version 2.1.0-dev-875 from maven("https://maven.pkg.jetbrains.space/kotlin/p/kotlin/dev") issue is not present.

Workaround to this issue is to use Kotlin 1.9.22 or 2.0.10-RC-510 (available with maven("https://maven.pkg.jetbrains.space/kotlin/p/kotlin/dev/")).
This is the associated Slack conversation : https://kotlinlang.slack.com/archives/C01F2HV7868/p1720105526946439?thread_ts=1720098055.793059&cid=C01F2HV7868

I can confirm, that CfW 1.7.0-xyz and newer builds will work only with kotlin 2.0.10 or 1.9.24 (using compose compiler <IP_ADDRESS>-beta02 or newer versions when they appear).
Kotlin 2.0.10 contains a necessary fix, which is present in kotlin 2.0.0.
For convenience, the fix is backported to the compose compiler for 1.9.24.

I'm closing this one as I see no particular actions on our side, except suggesting to use a correct Kotlin version (Please see the comment above).
Feel free to add more questions or reopen if needed.

Please check the following ticket on YouTrack for follow-ups to this issue. GitHub issues will be closed in the coming weeks.


API to count total records

Please add  the ability to return the total count for api's with index such as products, variants, etc.

API endpoint added. Postman collection is also updated


Favor fail over raise on ruby exceptions

Not a huge fan of this style, and it especially doesn't really make sense for an exception handling gem (where most of these things aren't really "failures").
Instead, can you submit a PR adding a new cop to rubocop.yml that enforces the style of using only raise?


Update SDK to 2.17.x

Based on https://tokbox.com/developer/sdks/android/release-notes.html, I had to edit the subscribeToStream method to get sessionId as input from the React Component (as stream.getSession has been deprecated).
Android:

edited EventUtils.js to accept Session object as input.
subscribeToStream method: added sessionId as input from the React method
OTPublisherView.java is failing because publisher.getSession has sessionId null. I am still investigating the issue, it could be a bug on the 2.17.0 SDK.

iOS:

subscribeToStream method: added sessionId as input. Even if not needed, I thought it could be nice to have the same method signature between iOS and Android
iOS needs testing

Tested on both android with 2.17.1 sdk and iOS with 2.17.0 sdk and both are working with minor changes in addition to this PR:
Android

Update the android sdk to 2.17.1 in build.gradle

iOS

OTSessionManager.m on line 34 should be:
sessionId: (NSString*)sessionId