iOS App Store publishment fails: ITMS-90338 - Non-public API usage

Someone came across that?

Sounds like Apple uses nanopb internally, and the symbol names conflict.
Currently nanopb doesn't have a way to easily rename the symbols, but there are a few options you could explore:

Stripping the private symbols after compilation. If you have nanopb linked in your own application, there is no need to expose those symbols in the final binary. https://stackoverflow.com/a/18226723 seems like a good start.

Making a huge list of #define's that would rename nanopb symbols at compile time. That could probably made with some kind of grep -o 'pb_[a-z_]*' *.h | sed ...something ... | sort | uniq | xargs -n 1 printf '#define %s xyz_%s' script, and then put into pb_syshdr.h.

@shatk0vskiy may you help me, what was the solution for this issue?


nanopolish index

Dear Jared
Recently, I've acquired nanopore direct RNA-seq data of my experiment.
The raw fast5 file was vbz compressed so I converted to gzip compression type using "ont_fast5_api" (https://github.com/nanoporetech/ont_fast5_api). Then, I'm trying to run nanopolish index on .fast5 file. I've only a single fast5 file for each replicate. When, I'm running the nanopolish index on fast5 file, three files in being created-
FAS03824_pass_d70ed67e_c4d2fdd2_0.fastq.index
FAS03824_pass_d70ed67e_c4d2fdd2_0.fastq.index.fai
FAS03824_pass_d70ed67e_c4d2fdd2_0.fastq.index.gzi
But the job is running for 15 hours more without any change in the size of the above three files. the job seems just keep running.  I think another file should be produced namely "FAS03824_pass_d70ed67e_c4d2fdd2_0.fastq.index.read.db" or it is working normal and need to keep running the nanopolish index ? Or if I can convert a single fast5 file into multi fast5 file and run on nanopolish?
Thank you so much for your kind consideration.
Best regards
Reza

Hi,
It can take a long time to index large runs. Did this ever finish?
Jared

Thanks, Jared.
After 72 hours of running it got killed without any change in the file generated.
Do you think it is happening due to recent vbz compression? I've changed vbz to gzip using ont_fast5_api.
Many thanks
Reza

Try providing the sequencing summary file using the -s option, it will make indexing run much faster.

@rezarahman12 You may try using [f5c] index with -t and --iop options for potentially fast indexing. f5c index and nanopolish index are intercompatible.

Thank you so much @hasindu2008. Now,  I'm running in f5c using the below code-
module load f5c
f5c index -d /scratch/project_mnt/S0077/ONT_Reza/KD1_1/KD1_1_fast5_pass_gzip  -s /scratch/project_mnt/S0077/ONT_Reza/KD1_1/fastq_dir/sequencing_summary.txt /scratch/project_mnt/S0077/ONT_Reza/KD1_1/fastq_dir/pass/basecalled.fastq -t 62 --iop 32
However, I'm getting below warning-
[parse_index_options::WARNING] --iop is incompatible with sequencing summary files. Option --sequencing-summary-file will be ignored
[parse_index_options::INFO] Consider using --slow5 option for fast indexing, methylation calling and eventalignment. See f5c section under https://hasindu2008.github.io/slow5tools/workflows.html for an example.
[find_all_fast5] Looking for fast5 in /scratch/project_mnt/S0077/ONT_Reza/KD1_1/KD1_1_fast5_pass_gzip
[f5c_index_iop] 1 fast5 files found - took 0.005s
[f5c_index_iop] Spawning 32 I/O processes to circumvent HDF hell
I keep running to see the outcome. I'll update you soon.
Kind regards
Reza

Yeh, you can ignore the warning, but wait - you have one single FAST5? How large is it?

@hasindu2008 Thanks for your great help. Yes, I've only a single fast5 file with a 43.1GB size. Also, I've another fast5 file for another sample which is a single fast5 file with 85.1GB size. Many thanks

@rezarahman12. ohhh they are pretty big (unlike the 4000 reads per FAST5 that typically is) and no wonder it takes ages. In this case, --iop will not help then. Is this a publicly available dataset sample?
Another option I can think of is, using slow5tools s2f command to convert this FAST5 to BLOW5. The conversion would take some time, but potentially less than the indexing due to how the HDF5 iterator works. Then the BLOW5 file can be provided as input to nanopolish which is usually much faster.

@hasindu2008  The datasets are generated by ourselves. If I split the single fast5 into multi-fast5 using ont-fast5-api, does it help to run the index in f5c?

Likely to help f5c index. You could give it a try, but that splitting also will take a lot of time I presume.

@hasindu2008 I've used slow5tools. Now I wanted to run f5c index. However, I'm getting an error, so posted my issue in slow5tools github. Thank you for your consideration.

Thanks @hasindu2008 for the help with this issue.


Documentation error in mwc-dialog

I'm submitting a:

[x] bug report
[ ] feature request

Current behavior:
The dialog titles do not appear in the demo.
Expected behavior:
The documentation describes heading. The actual property/attribute is title.

Title was renamed to heading in https://github.com/material-components/material-components-web-components/pull/556, because it collided with the built-in title property. It's mentioned in the CHANGELOG, but we haven't done a release since that change. Sorry for the confusion, we should get a release out soon.


Renew #[pyproto] implementation for abi3 branch

So what's the problem?
Currently, on the master, #[pyproto] is implemented via 'table initialization'.
I.e., #[pyproto] generates basically such a function:
#[ctor]
fn __table_initialization() {
    let mut methods = PyNumberMethods::default();
    methods.set_add::<MyClass>();
    <MyClass as HasProtoRegistory>::add_number_methods(methods);  // I don't remember the function name correctly...
}

I designed this since many protocols required such kinds of tables before.
However, when we are to use ABI3, most protocols are initialized via PyType_Slot and tables are unnecessary.
So I decided to renew the whole design, using Vec<PyType_Slot> instead of tables.
I believe the new implementation is simpler but has one disadvantage: weak typing.
PyType_Slot casts function pointers to *mut c_void so the function type is eliminated, which can lead to bugs. We should carefully check the slot and pfunc of each PyType_Slot are correct.
Now #[pyproto] generates (roughly):
pyo3::inventory::submit!( {
    let mut proto_methods = vec![];
    proto_methods.push(<MyClass as PyNumberSlots>::get_add());
    proto_methods.into()
});

I only skimmed it, but the design makes sense to me.

👍 looks like a good idea! I've started reviewing but need more time to finish reading. I have a very busy day today so tomorrow is more likely I'm afraid.

Thanks for the review!

How about adding an enum so that when we put the proto methods in the inventory we still have strong types?

This sounds the same as the current approach, and if so, it does not address the code complexity issue.
I think what we need is adding some assertion before we cast a function pointer to *mut c_void. I'd rather try to implement this using a macro and ask your review again.

Oh, I just recalled that type slots does not work for buffer... (https://github.com/PyO3/pyo3/pull/1132#issuecomment-684218818)

Chaned to use struct TypedSlot<T: Sized>(pub std::os::raw::c_int, pub T) as internal representation of ffi::PyType_Slot to resolve the weak typing problem.
I also tried to slot: #slot that @davidhewitt introduced, but found myself hard to write "ffi::Py_*"s without code completion.


FIX: castingHelper failed to find many_many_extraFields data (fixes #4661)

Rebase of https://github.com/silverstripe/silverstripe-framework/pull/4667, fixes #4661.

This seems like a pretty good way to get casting helpers across. :D Will wait for tests.

Apparently I’m not worthy of a Travis build :( will try closing and re-opening to trigger one


Remove non-required references from test projects

Hmmm could you also delete this reference in App config? https://github.com/Azure/azure-sdk-for-net/blob/master/sdk/appconfiguration/Azure.Data.AppConfiguration/tests/Azure.Data.AppConfiguration.Tests.csproj#L16


Revamp of C# channel options (aka channel args)

This is to be merged after #1992 is in.
Changes:
-- Use more understandable name "ChannelOptions" instead of cryptic "ChannelArgs".
-- Get rid of the builder pattern when building channel options and allow user to just specify a list of ChannelOption objects (that should be more idiomatic for C# and allows using object initializer).
-- Provide constants for well-known channel options.
-- Allow server to use ChannelOptions as well.
-- Add some tests.

Travis issues don't seem to be related to this PR. Posted issues for them.

I rebased this one so it's mergeable. Please take a look. I believe the travis failures are not connected to this change at all.


optimization: replace division (modulus) with reciprocal multiplication

I can't find any information on the speed of division in GCN, but apparently it is slow.
http://www.pcper.com/news/Editorial/GDC-2014-Shader-limited-Optimization-AMDs-GCN
Gcc supports fixed point:
https://gcc.gnu.org/onlinedocs/gcc/Fixed-Point.html
So my first thought was to try
fract reciprocal = 1/dag_size
And then pass that to the kernel.  But standard linux builds of gcc don't include fixed-point support.
I'm trying to think of another simple way to do it, but worst case would be to write a few lines of code to construct a 32-bit binary fraction.

I think even using double-precision floating point converted to int would be faster.

It seems modulus requires integer types, so I'll have to do it the long way to do the division using floating point.

[OPENCL]:"/tmp/OCLzah001.cl", line 383: error: expression must have integral type
        dag_node.vec = g_light[convert_uint(node_double % light_size)].vec;
                                            ^


filter out invalid utf-8 to avoid log.fatal

Plus code to save diagnostics when using USB stick to configure proxy and static IP
@kalyan-nidumolu @gkodali-zededa please take a look

@nordmark I supposed this is fine for now (although it would be useful to take care of DCO and yetus complaints before we commit this) but we need to really discuss how this other USB stick will dovetail into the USB work we're doing for installer AND how it will dovetail into config-on-a-stick delivery method for device config. Otherwise, this sprawl of different ways of how data gets transferred to/from EVE on various USB sticks becomes a bit too unwieldy.
How do you propose we do that -- should we file an issue and tackle it next month?

@nordmark I supposed this is fine for now (although it would be useful to take care of DCO and yetus complaints before we commit this)

Seems like git rebase ate my signoff. I'll fix.

but we need to really discuss how this other USB stick will dovetail into the USB work we're doing for installer AND how it will dovetail into config-on-a-stick delivery method for device config. Otherwise, this sprawl of different ways of how data gets transferred to/from EVE on various USB sticks becomes a bit too unwieldy.

How do you propose we do that -- should we file an issue and tackle it next month?

I think we should write up the end-to-end workflows which are relevant.
One is onboarding using a product key plus serial, with a need to gather software serial numbers.
That one has a weak security binding, but I think there is a discussion to be had whether we can use the TPM at install time and get a stronger binding.
The other use case is more about gathering inventory than install time options.
So walking through the use cases makes sense to me and then gathering feedback.
In any case, we should make the information we gather be consistent.

looks good

@nordmark would it be fair to assign #57 to you with an expectation that it can be done in the next sprint?

LGTM

@nordmark would it be fair to assign #57 to you with an expectation that it can be done in the next sprint?

You can assign it to me.
Let's figure out the order to document things; I suspect documenting the new I/O plus old system adapters has bubbled up to the top as well.


RFC: WASM Proposal

Proposal
We propose a change to the architecture of the ocm-controller that will introduce Web Assembly (WASM) middleware in order to transform OCM resources.
Context
One of the design guidelines for the ocm-controller is that it should support arbitrary transformation of resources. Standard transformations such as Localization and Configuration are provided "in-tree" as part of the controller.
We currently perform transformation using code that is common to both Localization and Configuration controllers. In addition we share resources using Snapshots. Snapshots provide a generic way to pass OCM resources between different Kubernetes controllers.
Whilst this works it requires operators to manage a large number of Custom Resources generating additional complexity meaning it can be difficult to build a mental model of the transformation sequence. It also leads to a somewhat large and complex codebase.
WASM Solution
WASM produces tiny binaries that execute in a sandboxed runtime environment. These properties make it ideal for the execution of untrusted code in a dynamic way. We propose that rather than using discrete controllers to perform transformation of OCM resources we can use WASM binaries to execute the transforms. WASM binaries can be executed from the ocm-controller and specified by the operator in the Resource CR.
In order for this solution to work we need to define a contract that WASM binaries and the ocm-controller must observe:

1: The WASM binary must be stored as a resource in an OCM component with type webAssembly
2: By default the ocm-controller will mount a file-system at the path /data  in which resources files will be available (this can be disabled if desired)
3: Any transformations should be performed on the filesystem
4: The ocm-controller will provide host calls that can be used to call ocm library functions such as GetResourceBytes, GetResourceMeta, GetResourceAccess. These host calls will be documented on the ocm website.
5: Configuration can be passed to the WASM guest process using the values or valuesFrom fields.

WASM transformations will be known as middleware.
The OCM project would provide a component that publishes official / first-party middleware.
This could include operations such as spiff based localization and configuration, ocm:// prefix based localization and other transformations.
End-users could provide their own middleware by publishing the component and specifying the details in the Resource manifest.
The output of a resource would continue to be a Snapshot that is applied by FluxDeployer Custom Resources.
API Changes
The API changes would be as follows:

Localization & Configuration objects removed

Resource CR updated to contain spec.middleware field:

apiVersion: delivery.ocm.software/v1alpha1
kind: Resource
metadata:
  name: podinfo-deployment
  namespace: ocm-system
spec:
  interval: 10m0s
  resourceRef:
    name: manifests
    component: delivery.ocm.software/middleware:v1.0.0
  middleware:
  - name: localizer
    component: delivery.ocm.software/middleware:v1.0.0
    values:
      prefix: ocm://
  - name: configure
    component: delivery.ocm.software/middleware:v1.0.0
    values:
      owned-by: "ocm.software"
      managed-by: "weaveworks"

how would we provide the runtime environment needed to execute the middlewares?  Also do we need to keep the fs around or is it available only for the reconciliation interval?

The fs is a throwaway as far as I understand. Since we basically do the thing, then the result gets put into the OCI cache. So whatever was there will probably be cleaned once done by a defer os.RemoveAll.

how would we provide the runtime environment needed to execute the middleware?

I thought it's just super small binaries that we are going to execute as is?
resources:
- name: ocm-localizer
  type: blob
  input:
    type: file
    path: ./bin/localizer

@phoban01 Actually, how do you propose to run these? Like, we shouldn't just run random binaries of course.
What do you think about this:

embed the v8 runtime engine as a VM
require a specific function to be exported in a the WASM module that we'll call

TinyGo supports //export <name> or //go:export <name> to export functions.

The runtime is important. The capabilities provided to middlewares (what syscalls are supported) are directly coming from the runtime, they way I understood this.

Aye, you're right. I misunderstood how this thing works. :)

Yes the runtime is part of how this all works. It provides a sandboxed execution environment. The WASM binaries can also be signed and we could enforce signature validation before running.

Nice. :)

Closing in favour of #223


Extended ID

Has the connection to ECUs with extended IDs already been tested?
I'm trying to connect to a CPC4. CBF loaded successfully: within "Communication Parameters" "CP_REQUEST_CANIDENTIFIER" is given as 0x18DA00F1. However while trying to connect to the ECU, the CAN ID is only "F1" and Diogenes returns "internally timed out".

.

Hello Daniboum,
Thanks for taking the time to create this issue. Extended 29-bit IDs are not tested yet, though it may be indicative of a more significant issue.
From my limited understanding, the CPC4 appears to be a Truck/Bus ECU, and therefore communicates via the SAE J1939 standard (typically 29-bit IDs). At this point, Diogenes only connects to passenger cars ("PKW") which almost always operates over the ISO 15765 standard. While both of these standards use the CAN bus as their underlying network, their higher-level data layout is significantly different and incompatible.
Diogenes depends on your J2534 ("PassThru") driver to break down and reassemble its ISO15765 messages when sending and receiving data; unfortunately there doesn't seem to be a similar J2534 feature to communicate with J1939 targets. As such, the CPC4 is incompatible, and there isn't a clear way for me to support the CPC4 target with the J2534 limitations.

Some notes on J1939:
https://www.simmasoftware.com/j1939-presentation.pdf
https://copperhilltech.com/blog/sae-j1939-programming-with-arduino-multipacket-broadcast-bam-session/

Hello!
Thank you very much for your quick reply.
Yes, the CPC is definitely communicating over J1939.
I'll have a closer look to my J2534 driver.


Bot crashing

The bot crashes if It doesn't run with -v, and it spits out the error below
[ERROR] TypeError: '<' not supported between instances of 'NoneType' and 'int'
Originally posted by @udu3324 in https://github.com/charlesbel/Microsoft-Rewards-Farmer/issues/242#issuecomment-1676105141

@udu3324 does it happens when completing bing searches ?

@udu3324 does it happens when completing bing searches ?

No no, it happens at the start when the bot tries to login

@udu3324 does it happens when completing bing searches ?

No no, it happens at the start when the bot tries to login

Could you retry with the latest version so we will see a full traceback (forgot it when first publishing the code)

@udu3324 does it happens when completing bing searches ?

No no, it happens at the start when the bot tries to login

Could you retry with the latest version so we will see a full traceback (forgot it when first publishing the code)

TypeError: '<' not supported between instances of 'NoneType' and 'int'
Traceback (most recent call last):
  File "C:\Users\compooter\Desktop\Microsoft-Rewards-Farmer\main.py", line 21, in main
    executeBot(currentAccount)
  File "C:\Users\compooter\Desktop\Microsoft-Rewards-Farmer\main.py", line 108, in executeBot
    with Browser(
  File "C:\Users\compooter\Desktop\Microsoft-Rewards-Farmer\src\browser.py", line 41, in __init__
    self.webdriver = self.browserSetup()
  File "C:\Users\compooter\Desktop\Microsoft-Rewards-Farmer\src\browser.py", line 76, in browserSetup
    driver = webdriver.Chrome(
  File "C:\Users\compooter\AppData\Local\Programs\Python\Python39\lib\site-packages\seleniumwire\undetected_chromedriver\webdriver.py", line 61, in __init__
    super().__init__(*args, **kwargs)
  File "C:\Users\compooter\AppData\Local\Programs\Python\Python39\lib\site-packages\undetected_chromedriver\__init__.py", line 386, in __init__
    if self.patcher.version_main < 108:
TypeError: '<' not supported between instances of 'NoneType' and 'int'

Turns out that I forgot to install undetected-chromedriver


c'mon guys :/ this is done before http://vanilla-js.com/

Looks pretty dated. Docs refer to tests against jQuery 1.11.1 for example. Not registered with NPM or bower, no TypeScript alternative. Available forks look to have latest activity as far back as 2-3 years ago. Frankly, I think there is more than enough room in the space for a new empty library. Let's give empty a shot, yeah?
If you think empty would benefit from Vanilla, @matthewkremer has been open to pull requests!

@umurgdk That's all part of the joke:
http://seriesf.com/post/116992930216/startup-tries-365-javascript-frameworks-likes


Broken link in argo docs

https://dev.applatix.net/app/timeline/jobs/5fb8364a-a79f-11e7-8636-0a58c0a88106;tab=workflow
Invalid links found in markdown files:

/src/content/user_guide/timeline/create_job-viewhistory.md:
        [](../../../images/Timeline_Branching_icon_2
  .png)

@cyee88 please take a look

Fixed in this commit:
commit db5f6cb978d5d29a10776eca3402a5e7e42cfb62 (HEAD -> master, origin/master, origin/HEAD)
Author: Calvin Yee<EMAIL_ADDRESS>Date:   Thu Oct 19 14:49:06 2017 -0700
Added a period and copied again the path to the missing image


Handle landscape rotation on mobile devices?

Mobile devices can display apps in portrait or landscape mode. We should either decide to not support mobile landscape mode or keep landscape mode in mind and design & develop the GUI to handle landscape rotation.
Below are screenshots as to how landscape mode is currently handled as of ea267ebb183c6bec57a255e89e277d0125939f5b:

a
b

The consensus is not to disable horizontal landscape rotation and instead to inadvertently address it by addressing the issue of small screens which require the ability to scroll through the content.


online Status of all devices

Status check of all devices
Charger, Inverter, BMS, Smart plugs, Current gauge
define for each device a status criteria which cen be checked regularly in order to be sure that all components work properly.
Smart Plug:
Example: Send a status request to the smart plug and evaluate the answer
Power Gauge:
Example: Send a status request to the smart plug and evaluate the answer
Inverter
Example: Compare feeded power in battary with power of connected smart plug
Charger
Example: Compare voltage reply from charger with BMS voltage
compare feeded power of BMS with smart plug
create a simple menu on the dashboard and on the display
Indicate clearly Status total and individual status of the devices

The status of the inverter can be red over ther serial port, where the "wifi stick" is plugged in.
see code
other source of information


missing CRDs cause crash on startup instead of failure on replication creation

the list of sidecars of our CSI controller deployment is constant, i.e. doesn't change according to existence of CRDs on the cluster.
so we would like to be able to deploy the volume replication operator even when the replication CRDs don't exist on the cluster.
this is the error we get on startup:
2021-08-04T12:22:20.018Z        ERROR   controller-runtime.source       if kind is a CRD, it should be installed before calling Start   {"kind": "VolumeReplication.replication.storage.openshift.io", "error": "no matches for kind \"VolumeReplication\" in version \"replication.storage.openshift.io/v1alpha1\""}
github.com/go-logr/zapr.(*zapLogger).Error
        /go/pkg/mod/github.com/go-logr/zapr@v0.2.0/zapr.go:132
sigs.k8s.io/controller-runtime/pkg/source.(*Kind).Start
        /go/pkg/mod/sigs.k8s.io/controller-runtime@v0.7.0/pkg/source/source.go:117
sigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).Start.func1
        /go/pkg/mod/sigs.k8s.io/controller-runtime@v0.7.0/pkg/internal/controller/controller.go:159
sigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).Start
        /go/pkg/mod/sigs.k8s.io/controller-runtime@v0.7.0/pkg/internal/controller/controller.go:205
sigs.k8s.io/controller-runtime/pkg/manager.(*controllerManager).startRunnable.func1
        /go/pkg/mod/sigs.k8s.io/controller-runtime@v0.7.0/pkg/manager/internal.go:691
2021-08-04T12:22:20.019Z        ERROR   setup   problem running manager {"error": "no matches for kind \"VolumeReplication\" in version \"replication.storage.openshift.io/v1alpha1\""}
github.com/go-logr/zapr.(*zapLogger).Error
        /go/pkg/mod/github.com/go-logr/zapr@v0.2.0/zapr.go:132
main.main
        /workspace/main.go:134
runtime.main
        /usr/local/go/src/runtime/proc.go:204

note that e.g. the snapshotter doesn't crash when its CRDs are missing, it only errors when trying to create a snapshot, as desired.

@oriyarde this is how the operator built from operator SDK works https://github.com/operator-framework/operator-sdk/issues/183#issuecomment-439484798

@Madhu-1 I don't think other sidecars (e.g. said snapshotter) are built from operator SDK, but a workaround might be to wait for the CRDs before starting the manager

We are not completely following the sidecar model for building/developing volume replication it's purely built from the operator SDK framework.
AFAIC waiting at the operator level is not of much use. This is a process of installation instead of running the operator first the admin can install the CRD and then start the operator. or whoever is automating the operator installation check for the CRD exists in a loop once he sees the CRD then install the volume-replication operator.

is there a reason not to follow the sidecar model?
since this project is used as a sidecar, I think it would be simpler to wait for the CRDs before starting rather than require all driver operators to dynamically change deployment according to CRDs installation status at any given moment

fixed in #108


Unable to Start Container with Mapped Network Volume

When attempting to start a postgres container and passing a mapped network mounted share as the main data volume, the container shows as running but cannot be accessed.  The following error is reported: "Container xxxxxxx is restarting, wait until the container is running". This error does not occur when using a locally mapped data volume.
For example, a CIFS mounted share via /etc/fstab mapped to the /database directory will cause the issue when the container is launched with the volume variable /database:/var/lib/postgresql/data. However, launching with a local directory as the volume such as /home/docker/postgresql:/var/lib/postgresql/data works perfectly.
What can be causing this issue?

Related issues: https://github.com/docker-library/postgres/issues/213 and https://github.com/docker-library/postgres/issues/235.  I don't think PostgreSQL is able to run with its data directory on CIFS.

For further help (with diagnosis and/or solution), I'd suggest trying a dedicated support forum, such as the Docker Community Forums, the Docker Community Slack, or Stack Overflow.


feat: support docussaurus v3

Description
Docussaurus v3 has been moved to beta.
Requirements

[ ] Prepare migration to v3

Fixed by #152


awscli2: 2.16.4 -> 2.17.0

Description of changes

https://github.com/aws/aws-cli/compare/2.16.4...2.17.0
Remove with py.pkgs usage

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

[ ] 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
[x] Tested basic functionality of all binary files (usually in ./result/bin/)
24.11 Release Notes (or backporting 23.11 and 24.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.

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

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

3 packages built:

awscli2
awscli2.dist
liquidsoap


API Proposal: Add DeviceStream APIs to IoT Hub Service SDK (Node.JS)

Overview
Azure IoT Hub device streams facilitate the creation of secure bi-directional TCP tunnels for a variety of cloud-to-device communication scenarios. A device stream is mediated by an IoT Hub streaming endpoint which acts as a proxy between your device and service endpoints. This setup is especially useful when devices are behind a network firewall or reside inside of a private network. As such, IoT Hub device streams help address customers' need to reach IoT devices in a firewall-friendly manner and without the need to broadly opening up incoming or outgoing network firewall ports. Using IoT Hub device streams, devices remain secure and will only need to open up outbound TCP connections to IoT hub's streaming endpoint over port 443. Once a stream is established, the service-side and device-side applications will each have programmatic access to a WebSocket client object to send and receive raw bytes to one another. The reliability and ordering guarantees provided by this tunnel is on par with TCP.
Device Stream Workflow
A device stream is initiated when the service requests to connect to a device by providing its device ID. This workflow particularly fits into a client/server communication model, including SSH and RDP, where a user intends to remotely connect to the SSH or RDP server running on the device using an SSH or RDP client program.
The device stream creation process involves a negotiation between the device, service, IoT hub's main and streaming endpoints. While IoT hub's main endpoint orchestrates the creation of a device stream, the streaming endpoint handles the traffic that flows between the service and device.
Device stream creation flow
Programmatic creation of a device stream using the SDK involves the following steps:

The device application registers a callback in advance to be notified of when a new device stream is initiated to the device. This step typically takes place when the device boots up and connects to IoT Hub.
The service-side program initiates a device stream when needed by providing the device ID (not the IP address).
IoT hub notifies the device-side program by invoking the callback registered in step 1. The device may accept or reject the stream initiation request. This logic can be specific to your application scenario. If the stream request is rejected by the device, IoT Hub informs the service accordingly; otherwise, the steps below follow.
The device creates a secure outbound TCP connection to the streaming endpoint over port 443 and upgrades the connection to a WebSocket. The URL of the streaming endpoint as well as the credentials to use to authenticate are both provided to the device by IoT Hub as part of the request sent in step 3.
The service is notified of the result of device accepting the stream and proceeds to create its own WebSocket client to the streaming endpoint. Similarly, it receives the streaming endpoint URL and authentication information from IoT Hub.

In the handshake process above:

The handshake process must complete within 60 seconds (step 2 through 5), otherwise the handshake would fail with a timeout and the service will be notified accordingly.
After the stream creation flow above completes, the streaming endpoint will act as a proxy and will transfer traffic between the service and the device over their respective WebSockets.
Device and service both need outbound connectivity to IoT Hub's main endpoint as well as the streaming endpoint over port 443. The URL of these endpoints is available on Overview tab on the IoT Hub's portal.
The reliability and ordering guarantees of an established stream is on par with TCP.
All connections to IoT Hub and streaming endpoint use TLS and are encrypted.

Termination Flow
An established stream terminates when either of the TCP connections to the gateway are disconnected (by the service or device). This can take place voluntarily by closing the WebSocket on either the device or service programs, or involuntarily in case of a network connectivity timeout or process failure. Upon termination of either device or service's connection to the streaming endpoint, the other TCP connection will also be (forcefully) terminated and the service and device are responsible to re-create the stream, if needed.
SDK Availability
Two sides of each stream (on the device and service side) use the IoT Hub SDK to establish the tunnel. During public preview, customers can choose from the following SDK languages:

The C and C# SDK's support device streams on the device side.
The Node.js and C# SDK support device streams on the service side.

Sample Code (Node.js)
This echo sample demonstrates programmatic use of device streams to send and receive bytes between service and device applications. To execute the scenario end to end, use the corresponding C or C# sample for the device side.
Service Sample Code (Node.js)
Full sample project here
var websocket = require('websocket-stream')
var ServiceClient = require('azure-iothub').Client;

var streamInit = {
  streamName: 'TestStream',
  connectTimeoutInSeconds: 30,
  responseTimeoutInSeconds: 30,
}

var client = ServiceClient.fromConnectionString(process.env.IOTHUB_CONNECTION_STRING);

console.log('initiating stream');
client.initiateStream(process.env.STREAMING_TARGET_DEVICE, streamInit, function(err, result) {
  if (err) {
    console.error(err.toString());
    process.exit(-1);
  } else {
    console.log(JSON.stringify(result, null, 2));

    var ws = websocket(result.uri, { headers: { 'Authorization': 'Bearer ' + result.authorizationToken} });
    process.stdin.pipe(ws);
    ws.pipe(process.stdout);
  }
});

New API Surface added (Node.js)
IoTHub Service SDK
Existing API reference here
initiateStream(deviceId: string, streamInitiation: StreamInitiation, callback: (err: Error, result?: StreamInitiationResult) => void): void;

export interface StreamInitiation {
  streamName: string;
}

export class StreamInitiationResult {
  authorizationToken: string;
  isAccepted: boolean;
  streamName?: string;
  uri: string;
}

Bits of feedback:

Adjust terminology where appropriate (guidelines, specifically prefer "client library" over "SDK")
Async via node callback patterns are out-dated. All async JS APIs must provide promise-based asynchrony (guidelines).

@bterlson absolutely agree on the comment about promises. Our SDKs have undergone promisification at the same time as the device streams preview work so the branches crossed without touching and we still need to add the promise API but it'll be there.

Here's the full API including the promisified version:
initiateStream(deviceId: string, streamInitiation: StreamInitiation): Promise<StreamInitiationResult>;
initiateStream(deviceId: string, streamInitiation: StreamInitiation, callback: (err: Error, result?: StreamInitiationResult) => void): void;

and the sample:
import * as websocket from 'websocket-stream';
import { Client as ServiceClient } from 'azure-iothub';

const streamInit = {
  streamName: 'TestStream'
};

const client = ServiceClient.fromConnectionString(process.env.IOTHUB_CONNECTION_STRING);

const result = await client.initiateStream(process.env.STREAMING_TARGET_DEVICE, streamInit);
console.log(JSON.stringify(result, null, 2));

const ws = websocket(result.uri, { headers: { 'Authorization': 'Bearer ' + result.authorizationToken} });
process.stdin.pipe(ws);
ws.pipe(process.stdout);

Does the sample need to rename the Client import to ServiceClient?
For readme purposes, wrapping the code in an async function main enables copy-pastability (await is not allowed at the top level unfortunately).
Sample needs to enable esModuleInterop (import * as websocket is non-standard syntax that will cause significant interop issues, I have a draft gist I never got around to polishing that might explain the issue some).
Are browsers supported? This authorization scheme will be difficult to work with there if so - you can't actually set headers for the websocket's handshake.
Asking users to set headers might be too low-level, so could consider doing that work for users. That said, it's important to support a variety of web socket implementations so maybe this is impossible in practice...

Does the sample need to rename the Client import to ServiceClient?

copy/pasta snafu. no need, i removed this.

For readme purposes, wrapping the code in an async function main enables copy-pastability (await is not allowed at the top level unfortunately).

sure - usually we structure our samples so that they run directly from the command line. will update this.

Sample needs to enable esModuleInterop (import * as websocket is non-standard syntax that will cause significant interop issues, I have a draft gist I never got around to polishing that might explain the issue some).

will take a look.. went with old typescript habits rather than es6 purity, I'm not familiar with the problem you're talking about.

Are browsers supported? This authorization scheme will be difficult to work with there if so - you can't actually set headers for the websocket's handshake.

Browsers are not supported. this is a long term goal but for now we have dependencies on core node packages so we don't support browsers. If you have a suggestion to future-proof this API for browsers, I'd happily integrate this to boot.

Asking users to set headers might be too low-level, so could consider doing that work for users. That said, it's important to support a variety of web socket implementations so maybe this is impossible in practice...

the thing I wanted to avoid here is to force the users into a particular websocket/stream implementation/library dependency. it's just an example on how to set up stdin/stdout piping from the terminal. again, i'm open to suggestions on how to better demonstrate the websocket and "standard" streaming part of it.

went with old typescript habits rather than es6 purity, I'm not familiar with the problem you're talking about.

Let me know if the blog helps or doesn't!

core node packages so we don't support browsers. If you have a suggestion to future-proof this API for browsers, I'd happily integrate this to boot.

Core node packages aren't necessarily a blocker - shims exist that re-implement node APIs in the browser. But some things can't be implemented uniformly, and in such cases you end up having separate node and browser implementations. So in general, future proofing means: avoiding built-in Node APIs where possible, and being aware of equivalent browser APIs and limitations thereof (e.g. WebSocket is a thing, but you can't set headers).

@bterlson one of the feedback/discussion that we have gone through and where we'd gladly take feedback is whether this API should expose the websocket or a stream object...

Can I see an example of what either would look like in situ?

we have 2 examples/quickstarts, maybe that'll give more context?

echo: this just pipes stdin/stdout through the websocket
proxy: this basically creates a small client that pipes anything (like: an SSH connection) from one socket through the websocket.

more explanations and steps for these in the public docs
Generally speaking it's about giving the user the most generic "pipe" possible to send/receive bytes.

Gah looks like I didn't reply with my thoughts on streams vs. sockets. I think you can't get away from node streams with this kind of API - users will want to .pipe() like your samples show. This also allows you to be agnostic as to which websocket implementation users bring to the table.
Let me know if there's new stuff you'd like me to take a look at, otherwise I think we can close this.

Thanks @bterlson
I'm not sure I understand what you're saying: given the communication with the service happens over websockets, I can either:

provide a stream API and "Force" a dependency on a specific websocket implementation
provide a stream API and let the user inject their own websocket implementation (i'd have to see how that works...)
provide a websocket URI and samples to show how to turn that into a stream (what I'm doing now)

Which one are you advocating for?

Definitely not 1 (can't force a websocket impl). 3 seems fine to me, but 2 seems friendliest if you can get there eventually. As an example, you can look at how rhea handles this (rhea is used by service bus/event hub clients). Users can provide their own websocket constructor and rhea will new it up when it's needed.

Thanks!! I'll definitely look into it. the feature is being delayed for a bit so I think we can close this for now @adrianhall

Awesome.  Re-engage if you need another API review of this.


[bug] v2: multiple webviews (mostly) white on load

Describe the bug
I create a new window (using tauri::WindowBuilder) and adding 3 webviews to it (using tauri::webview::WebviewBuilder); one webview loads a local HTML file, and the other two loads Google search and Bing search.
The webviews are currently arranged so that they do not overlap (but they will later on). The following screenshot shows how it is supposed to be seen (at the top the local HTML) and the bottom part is divided 50/50 with Google search on the left and Bing on the right:

The problem is that most of the time the external websites (Google and Bing) are not shown at all...

...or only one of them...

I'm not a Rust developer and Tauri is very new to me, so I don't know if it is a problem with my code, or Tauri (or one of its sub-components/-projects).
Since the problem occurs most of the time, but it sometimes works, I would conclude that it might be because the webviews are created more or less at the exact same time and something might conflict, but I'm not sure.
Reproduction
My code looks like this:
pub fn run() {
    tauri::Builder::default()
        .setup(|app| {
            // Main window
            let window = tauri::WindowBuilder::new(app, "App")
                .title("Test of multiple Webviews")
                .inner_size(800., 600.)
                .build()
                .unwrap();

            // Add main webview
            let _webview_main = window.add_child(
                tauri::webview::WebviewBuilder::new("WebviewMain", WebviewUrl::App("index.html".into()))
                    .auto_resize(),
                LogicalPosition::new(0., 0.),
                LogicalSize::new(800., 200.),
            )?;

            // Add webview for site #1
            let _webview1 = window.add_child(
                tauri::webview::WebviewBuilder::new("Webview1", WebviewUrl::External(Url::parse("https://www.google.com/").expect("Failed to parse URL")), )
                    .auto_resize(),
                LogicalPosition::new(0., 200.),
                LogicalSize::new(400., 400.),
            )?;

            // Add webview for site #2
            let _webview2 = window.add_child(
                tauri::webview::WebviewBuilder::new("Webview2", WebviewUrl::External(Url::parse("https://www.bing.com/").expect("Failed to parse URL")), )
                    .auto_resize(),
                LogicalPosition::new(400., 200.),
                LogicalSize::new(400., 400.),
            )?;

            Ok(())
        })
        .run(tauri::generate_context!())
        .expect("error while running tauri application");
}

Expected behavior
I would expect all three webviews to show content every time I launch my application.
Full tauri info output
[✔] Environment
    - OS: Windows 10.0.19045 X64
    ✔ WebView2: 124.0.2478.97
    ✔ MSVC: Visual Studio Community 2022
    ✔ rustc: 1.76.0 (07dca489a 2024-02-04)
    ✔ cargo: 1.76.0 (c84b36747 2024-01-18)
    ✔ rustup: 1.27.1 (54dd3d00f 2024-04-24)
    ✔ Rust toolchain: stable-x86_64-pc-windows-msvc (default)
    - node: 20.11.0
    - npm: 10.8.1

[-] Packages
    - tauri [RUST]: 2.0.0-beta.11
    - tauri-build [RUST]: 2.0.0-beta.9
    - wry [RUST]: 0.37.0
    - tao [RUST]: 0.26.1
    - @tauri-apps/api [NPM]: 2.0.0-beta.13
    - @tauri-apps/cli [NPM]: 2.0.0-beta.20

[-] App
    - build-type: bundle
    - CSP: unset
    - frontendDist: ../src

Stack trace
No response
Additional context
No response

I've read somewhere that "by default multiple webview support is not enabled". Does this mean that I will have to enable unstable flag in order to have my application work? And if yes...
a) Is this something that will be worked on for an upcoming release?
b) What side-effects do I have to consider if I am going to enable unstable flag?

Does this mean that I will have to enable unstable flag in order to have my application work? And if yes...

Yes.

a) Is this something that will be worked on for an upcoming release?

Likely, yes. We don't know when though.

b) What side-effects do I have to consider if I am going to enable unstable flag?

Not only the API is unstable but the implementation/behavior too, make sure to double check everything. For example resizing tends to be a problem.


Cancel issue

[x ] I am on the latest Hyper.app version
[x ] I have searched the issues of this repo and believe that this is not a duplicate

Windows 10:
Latest version:

Issue

The download link is broken on the website and in the readme.md.
The download link was broken but no longer is. Please cancel issue.

It is or isn't broken?

No, sorry it is not. It was only down and linked to a 404 page on your site for 5 minutes.


Provide language override in config

In Tesla's browser you cannot select a language - select boxes just do not work - In the Tesla browser you simply can't get the dropdown options. So evcc uses browser default settings which will be Dutch here in Germany...
Would it be possible to set the language in the yaml configuration as a override and display the select box in case it's not set in config?

Currently UI language preference is only held in the Browser (default auto-detect). Instead of adding a lang-overwrite option I think about persisting the setting to the server. This would also introduce cross device lang sync. Any arguments against this?
The only issue I can think about is having multiple people with different lang-preferences using the same evcc instance. In most cases I'd assume this is not a problem. Agreed?

The only issue I can think about is having multiple people with different lang-preferences using the same evcc instance. In most cases I'd assume this is not a problem. Agreed?

This would be slight inconvenience for me, since I do prefer EN, and my family can only use their native language.
But I will cope with that just fine, as it solves other problems for out community members :)
Thank you guys for all the improvements - it’s like Christmas every time!!🎁


Add testimonials page

Added testimonials.md page and a Testimonial example without link,

I don't know if it would be correct to place it better in quotes.md page 🤔

Ok, I'll close this for now. Thanks anyway and any other contribution will be appreciated


Feature proposal: creating listener for data changes

Hello,
Thanks for sharing an interesting library!
What do you think about creating a listener for data changes? I think, it's missing, but quite useful feature. We can invoke methods (or single method) from a potential listener interface in write(...) and delete(...) methods. Let me know about your opinion and I can even create a small PR in a free time.
:-)
Regards,
Piotr

Hello,
I'd like to keep this library as single-purposed. The main purpose of Paper - to provide fast storage for your Model. I guess model loading, handling data changes, thread handling should be out of scope of Paper.


Artifactory 5.11.1 enterprise support

Updated Artifactory and Artifactory-lb 5.11.1 packages for enterprise HA setup

Sure. Will more to next package version.


cmd/compile: internal compiler error: weird package in name: .dict0 => .dict0 from "", not "test/p"

What version of Go are you using (go version)?

$ go version
go version devel go1.19-f8e70fc9a6 Sat Apr 2 06:48:45 2022 +0000 darwin/amd64

Does this issue reproduce with the latest release?
Yes
What operating system and processor architecture are you using (go env)?
go env Output
$ go env

What did you do?
go compiler panicked with generics code, i made a reproduce demo at https://go.dev/play/p/4sC7oDiNFJs

-- go.mod --
module test
-- p/a.go --
package p

func Compare[T int | uint](a, b T) int {
	return 0
}

type Slice[T int | uint] struct{}

func (l Slice[T]) Comparator() func(v1, v2 T) int {
	return Compare[T]
}
-- main.go --
package main

import "test/p"

func Test() {
	var _ p.Slice[uint]
}

the error logs:
<autogenerated>:1: internal compiler error: weird package in name: .dict0 => .dict0 from "", not "github.com/kita-ui/kita/view/b"

goroutine 1 [running]:
runtime/debug.Stack()
        /usr/local/Cellar/gotip/src/runtime/debug/stack.go:24 +0x65
cmd/compile/internal/base.FatalfAt({0x30121?, 0xc0?}, {0x1926387, 0x2f}, {0xc000425660, 0x4, 0x4})
        /usr/local/Cellar/gotip/src/cmd/compile/internal/base/print.go:227 +0x1d7
cmd/compile/internal/base.Fatalf(...)
        /usr/local/Cellar/gotip/src/cmd/compile/internal/base/print.go:196
cmd/compile/internal/typecheck.(*exportWriter).localIdent(0xc000094a10?, 0xc000409200?)
        /usr/local/Cellar/gotip/src/cmd/compile/internal/typecheck/iexport.go:2276 +0x287
cmd/compile/internal/typecheck.(*exportWriter).writeNames(0xc000094a10, {0xc000610000, 0x4, 0x18d8520?})
        /usr/local/Cellar/gotip/src/cmd/compile/internal/typecheck/iexport.go:1494 +0x78
cmd/compile/internal/typecheck.(*exportWriter).funcBody(0xc000094a10?, 0xc000414140)
        /usr/local/Cellar/gotip/src/cmd/compile/internal/typecheck/iexport.go:1503 +0x39
cmd/compile/internal/typecheck.(*iexporter).doInline(0xc00064a6e0, 0xc0003faf00)
        /usr/local/Cellar/gotip/src/cmd/compile/internal/typecheck/iexport.go:664 +0xca
cmd/compile/internal/typecheck.(*exportWriter).funcExt(0xc0000947e0, 0xc0003faf00)
        /usr/local/Cellar/gotip/src/cmd/compile/internal/typecheck/iexport.go:1442 +0x1cd
cmd/compile/internal/typecheck.(*iexporter).doDecl(0xc00064a6e0, 0xc0003faf00)
        /usr/local/Cellar/gotip/src/cmd/compile/internal/typecheck/iexport.go:536 +0x21d
cmd/compile/internal/typecheck.WriteExports({0x1a664e0, 0xc000092d80}, 0x1)
        /usr/local/Cellar/gotip/src/cmd/compile/internal/typecheck/iexport.go:334 +0x2fe
cmd/compile/internal/noder.WriteExports(0xc000069390)
        /usr/local/Cellar/gotip/src/cmd/compile/internal/noder/export.go:40 +0x7a
cmd/compile/internal/gc.dumpCompilerObj(0xc000069390?)
        /usr/local/Cellar/gotip/src/cmd/compile/internal/gc/obj.go:107 +0x28
cmd/compile/internal/gc.dumpobj1({0x7ffeefbff1b9, 0x50}, 0x3)
        /usr/local/Cellar/gotip/src/cmd/compile/internal/gc/obj.go:63 +0x17b
cmd/compile/internal/gc.dumpobj()
        /usr/local/Cellar/gotip/src/cmd/compile/internal/gc/obj.go:44 +0x36
cmd/compile/internal/gc.Main(0x1934110)
        /usr/local/Cellar/gotip/src/cmd/compile/internal/gc/main.go:321 +0x1176
main.main()
        /usr/local/Cellar/gotip/src/cmd/compile/main.go:55 +0xdd

this bug is similar with #51423,  i have made a temporary workaround in my code by change return Compare[T] to return func(x, y int) int { return a.CompareInt[int](x,y) }  before #51423  was fixed, and forgot to change it back after 1.18 released, today i remove this workaround and found that the bug still exists
What did you expect to see?
What did you see instead?

Sounds like we should reopen #51423 ?

I can not reproduce the problem of #51423, but this issue can be reproduced.

cc @cuonglm @randall77 per original CL

@hopehook Yes, the test case is a bit different with previous one, and the original CL doesn't covers this new case.

It seems that caused by the exported func name Test

the Test function imports Comparator method defined on Slice[T] and that method causes this issue.

I've found that if you use p.Slice[int] normally, it works fine, or if you don't export the Test function.

I'm AFK, but it seems to me this problem is different with #51423, which involves re-export closures signature.
The problem here seems to be about exporting inline-ed function body.

Should we backport this? @randall77 @mdempsky

Stepping back a bit, I'm surprised we're exporting post-stenciled functions. Do we actually make use of those today?

I think yes, so we don't need to be re-typechecked on import.

I assume there's code for reading in the generic version and applying stenciling based on type arguments, since we need to handle the case where we're instantiating with never before seen type arguments. Can we just always use that code?

Hmm, not sure that's the case for iimport.go today.

@cuonglm will this be fixed in 1.18.1?

@cuonglm will this be fixed in 1.18.1?

I think yes, since when this is very similar to #51423


Update to 1.39.0 [ Jenkins ]

What it does

update gitignore
update path to electron-main script
upgrade dependencies compatible with node 16
inversify update changes
add secondary-window package
enable backend bundling

Contributed on behalf of STMicroelectronics
How to test
Build and check that everything is still working
Review checklist

[x] as an author, I have thoroughly tested my changes and carefully followed the review guidelines

Reminder for reviewers

as a reviewer, I agree to behave in accordance with the review guidelines

Please note that this does not yet use a bundled backend (https://github.com/eclipse-theia/theia/pull/12412)
When I try to create a bundled backend locally, I get the following error during webpack. This is on an ubuntu machine, so I don't know why it tries to package windows certs.
theia-blueprint: ERROR in<EMAIL_ADDRESS>380:70-105
theia-blueprint: Module not found: Error: Can't resolve<EMAIL_ADDRESS>in '/home/johannes/Git/theia-example/node_modules/@vscode/proxy-agent/out'
theia-blueprint: resolve<EMAIL_ADDRESS>in '/home/johannes/Git/theia-example/node_modules/@vscode/proxy-agent/out'
theia-blueprint:   Parsed request is a module
theia-blueprint:   using description file<EMAIL_ADDRESS>(relative path: ./out)
theia-blueprint:     resolve as module
theia-blueprint:       /home/johannes/Git/theia-example/node_modules/@vscode/proxy-agent/out/node_modules doesn't exist or is not a directory
theia-blueprint:       looking for modules in /home/johannes/Git/theia-example/node_modules/@vscode/proxy-agent/node_modules
theia-blueprint:         /home/johannes/Git/theia-example/node_modules/@vscode/proxy-agent/node_modules/@vscode/windows-ca-certs doesn't exist
theia-blueprint:       /home/johannes/Git/theia-example/node_modules/@vscode/node_modules doesn't exist or is not a directory
theia-blueprint:       /home/johannes/Git/theia-example/node_modules/node_modules doesn't exist or is not a directory
theia-blueprint:       looking for modules in /home/johannes/Git/theia-example/node_modules
theia-blueprint:         /home/johannes/Git/theia-example/node_modules/@vscode/windows-ca-certs doesn't exist
theia-blueprint:       looking for modules in /home/johannes/Git/node_modules
theia-blueprint:         /home/johannes/Git/node_modules/@vscode/windows-ca-certs doesn't exist
theia-blueprint:       /home/johannes/node_modules doesn't exist or is not a directory
theia-blueprint:       /home/node_modules doesn't exist or is not a directory
theia-blueprint:       /node_modules doesn't exist or is not a directory

Please note that this does not yet use a bundled backend (eclipse-theia/theia#12412)
When I try to create a bundled backend locally, I get the following error during webpack. This is on an ubuntu machine, so I don't know why it tries to package windows certs.
theia-blueprint: ERROR in<EMAIL_ADDRESS>380:70-105
theia-blueprint: Module not found: Error: Can't resolve<EMAIL_ADDRESS>in '/home/johannes/Git/theia-example/node_modules/@vscode/proxy-agent/out'
theia-blueprint: resolve<EMAIL_ADDRESS>in '/home/johannes/Git/theia-example/node_modules/@vscode/proxy-agent/out'
theia-blueprint:   Parsed request is a module
theia-blueprint:   using description file<EMAIL_ADDRESS>(relative path: ./out)
theia-blueprint:     resolve as module
theia-blueprint:       /home/johannes/Git/theia-example/node_modules/@vscode/proxy-agent/out/node_modules doesn't exist or is not a directory
theia-blueprint:       looking for modules in /home/johannes/Git/theia-example/node_modules/@vscode/proxy-agent/node_modules
theia-blueprint:         /home/johannes/Git/theia-example/node_modules/@vscode/proxy-agent/node_modules/@vscode/windows-ca-certs doesn't exist
theia-blueprint:       /home/johannes/Git/theia-example/node_modules/@vscode/node_modules doesn't exist or is not a directory
theia-blueprint:       /home/johannes/Git/theia-example/node_modules/node_modules doesn't exist or is not a directory
theia-blueprint:       looking for modules in /home/johannes/Git/theia-example/node_modules
theia-blueprint:         /home/johannes/Git/theia-example/node_modules/@vscode/windows-ca-certs doesn't exist
theia-blueprint:       looking for modules in /home/johannes/Git/node_modules
theia-blueprint:         /home/johannes/Git/node_modules/@vscode/windows-ca-certs doesn't exist
theia-blueprint:       /home/johannes/node_modules doesn't exist or is not a directory
theia-blueprint:       /home/node_modules doesn't exist or is not a directory
theia-blueprint:       /node_modules doesn't exist or is not a directory

I looks like I can reproduce this behaviour with the electron example from the main Theia repository as well by replacing
"bundle": "yarn rebuild && theia build --mode development", with "bundle": "yarn rebuild && theia build",
So either this is a general issue with Ubuntu/Linux or with my local environment.

@jfaltermeier There is some weird issue with the bundler going on, and I'm not sure why it occurs. I've provided a commit over at 12f3d2b that fixes the backend build and runtime issues.

Thanks! I will update my WIP commit accordingly tomorrow and will look into using the minimized build with electron-builder.

@jfaltermeier looks good generally. I will review more deeply after you make the update tomorrow.

@marcdumais-work I've updated the PR.
The Github workflows are green and on the Eclipse Jenkins, Windows and MacOS are green. For Linux the Eclipse Jenkins does not spawn Build nodes atm. I will open a ticket at the helpdesk.

@marcdumais-work I would like to post the release announcement tomorrow if possible, so if you could apporve today in case you do not find issue, that would be great!

I've pulled the latest version of the PR branch and am building - will test soon

There seems to be an issue with ripgrep dependency on the Jenkins build - I have not seen this locally yet:
theia-blueprint: Downloaded ffmpeg shared library { version: "23.3.9", dist: "/home/jenkins/agent/workspace/Theia_PRs_PR-275/node_modules/electron/dist" }.
theia-blueprint: Successfully replaced "/home/jenkins/agent/workspace/Theia_PRs_PR-275/node_modules/electron/dist/libffmpeg.so".
theia-blueprint: "/home/jenkins/agent/workspace/Theia_PRs_PR-275/node_modules/electron/dist/libffmpeg.so" does not contain proprietary codecs (16 found).
theia-blueprint: node:internal/modules/cjs/loader:933
theia-blueprint:   const err = new Error(message);
theia-blueprint:               ^
theia-blueprint: Error: Cannot find module '@vscode/ripgrep/bin/rg'
theia-blueprint: Require stack:
theia-blueprint: -<EMAIL_ADDRESS>theia-blueprint: -<EMAIL_ADDRESS>theia-blueprint: - /home/jenkins/agent/workspace/Theia_PRs_PR-275/applications/electron/gen-webpack.node.config.js
theia-blueprint: - /home/jenkins/agent/workspace/Theia_PRs_PR-275/applications/electron/webpack.config.js
theia-blueprint: - /home/jenkins/agent/workspace/Theia_PRs_PR-275/node_modules/webpack-cli/lib/webpack-cli.js
theia-blueprint: - /home/jenkins/agent/workspace/Theia_PRs_PR-275/node_modules/webpack-cli/lib/bootstrap.js
theia-blueprint: - /home/jenkins/agent/workspace/Theia_PRs_PR-275/node_modules/webpack-cli/bin/cli.js
theia-blueprint: - /home/jenkins/agent/workspace/Theia_PRs_PR-275/node_modules/webpack/bin/webpack.js
theia-blueprint:     at Function.Module._resolveFilename (node:internal/modules/cjs/loader:933:15)
theia-blueprint:     at Function.resolve (/home/jenkins/agent/workspace/Theia_PRs_PR-275/node_modules/v8-compile-cache/v8-compile-cache.js:164:23)
theia-blueprint:     at NativeWebpackPlugin.copyRipgrep (/home/jenkins/agent/workspace/Theia_PRs_PR-275/node_modules/@theia/native-webpack-plugin/lib/native-webpack-plugin.js:91:36)
theia-blueprint:     at /home/jenkins/agent/workspace/Theia_PRs_PR-275/node_modules/@theia/native-webpack-plugin/lib/native-webpack-plugin.js:78:28
theia-blueprint:     at Hook.eval [as callAsync] (eval at create (/home/jenkins/agent/workspace/Theia_PRs_PR-275/node_modules/tapable/lib/HookCodeFactory.js:33:10), <anonymous>:7:1)
theia-blueprint:     at Hook.CALL_ASYNC_DELEGATE [as _callAsync] (/home/jenkins/agent/workspace/Theia_PRs_PR-275/node_modules/tapable/lib/Hook.js:18:14)
theia-blueprint:     at /home/jenkins/agent/workspace/Theia_PRs_PR-275/node_modules/webpack/lib/Compiler.js:882:27
theia-blueprint:     at /home/jenkins/agent/workspace/Theia_PRs_PR-275/node_modules/neo-async/async.js:2818:7
theia-blueprint:     at done (/home/jenkins/agent/workspace/Theia_PRs_PR-275/node_modules/neo-async/async.js:3522:9)
theia-blueprint:     at alreadyWritten (/home/jenkins/agent/workspace/Theia_PRs_PR-275/node_modules/webpack/lib/Compiler.js:714:8) {
theia-blueprint:   code: 'MODULE_NOT_FOUND',
theia-blueprint:   requireStack: [
theia-blueprint<EMAIL_ADDRESS>theia-blueprint<EMAIL_ADDRESS>theia-blueprint:     '/home/jenkins/agent/workspace/Theia_PRs_PR-275/applications/electron/gen-webpack.node.config.js',
theia-blueprint:     '/home/jenkins/agent/workspace/Theia_PRs_PR-275/applications/electron/webpack.config.js',
theia-blueprint:     '/home/jenkins/agent/workspace/Theia_PRs_PR-275/node_modules/webpack-cli/lib/webpack-cli.js',
theia-blueprint:     '/home/jenkins/agent/workspace/Theia_PRs_PR-275/node_modules/webpack-cli/lib/bootstrap.js',
theia-blueprint:     '/home/jenkins/agent/workspace/Theia_PRs_PR-275/node_modules/webpack-cli/bin/cli.js',
theia-blueprint:     '/home/jenkins/agent/workspace/Theia_PRs_PR-275/node_modules/webpack/bin/webpack.js'
theia-blueprint:   ]
theia-blueprint: }
theia-blueprint: Error: webpack exited with an unexpected code: 1.
theia-blueprint:     at ChildProcess.<anonymous> (/home/jenkins/agent/workspace/Theia_PRs_PR-275/node_modules/@theia/application-manager/lib/application-process.js:66:28)
theia-blueprint:     at ChildProcess.emit (node:events:526:28)
theia-blueprint:     at maybeClose (node:internal/child_process:1092:16)
theia-blueprint:     at Process.ChildProcess._handle.onexit (node:internal/child_process:302:5)
theia-blueprint: error Command failed with exit code 1.
theia-blueprint: info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.
theia-blueprint: error Command failed with exit code 1.
theia-blueprint: info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.

There seems to be an issue with ripgrep dependency on the Jenkins build - I have not seen this locally yet:
theia-blueprint: Downloaded ffmpeg shared library { version: "23.3.9", dist: "/home/jenkins/agent/workspace/Theia_PRs_PR-275/node_modules/electron/dist" }.
theia-blueprint: Successfully replaced "/home/jenkins/agent/workspace/Theia_PRs_PR-275/node_modules/electron/dist/libffmpeg.so".
theia-blueprint: "/home/jenkins/agent/workspace/Theia_PRs_PR-275/node_modules/electron/dist/libffmpeg.so" does not contain proprietary codecs (16 found).
theia-blueprint: node:internal/modules/cjs/loader:933
theia-blueprint:   const err = new Error(message);
theia-blueprint:               ^
theia-blueprint: Error: Cannot find module '@vscode/ripgrep/bin/rg'
theia-blueprint: Require stack:
theia-blueprint: -<EMAIL_ADDRESS>theia-blueprint: -<EMAIL_ADDRESS>theia-blueprint: - /home/jenkins/agent/workspace/Theia_PRs_PR-275/applications/electron/gen-webpack.node.config.js
theia-blueprint: - /home/jenkins/agent/workspace/Theia_PRs_PR-275/applications/electron/webpack.config.js
theia-blueprint: - /home/jenkins/agent/workspace/Theia_PRs_PR-275/node_modules/webpack-cli/lib/webpack-cli.js
theia-blueprint: - /home/jenkins/agent/workspace/Theia_PRs_PR-275/node_modules/webpack-cli/lib/bootstrap.js
theia-blueprint: - /home/jenkins/agent/workspace/Theia_PRs_PR-275/node_modules/webpack-cli/bin/cli.js
theia-blueprint: - /home/jenkins/agent/workspace/Theia_PRs_PR-275/node_modules/webpack/bin/webpack.js
theia-blueprint:     at Function.Module._resolveFilename (node:internal/modules/cjs/loader:933:15)
theia-blueprint:     at Function.resolve (/home/jenkins/agent/workspace/Theia_PRs_PR-275/node_modules/v8-compile-cache/v8-compile-cache.js:164:23)
theia-blueprint:     at NativeWebpackPlugin.copyRipgrep (/home/jenkins/agent/workspace/Theia_PRs_PR-275/node_modules/@theia/native-webpack-plugin/lib/native-webpack-plugin.js:91:36)
theia-blueprint:     at /home/jenkins/agent/workspace/Theia_PRs_PR-275/node_modules/@theia/native-webpack-plugin/lib/native-webpack-plugin.js:78:28
theia-blueprint:     at Hook.eval [as callAsync] (eval at create (/home/jenkins/agent/workspace/Theia_PRs_PR-275/node_modules/tapable/lib/HookCodeFactory.js:33:10), <anonymous>:7:1)
theia-blueprint:     at Hook.CALL_ASYNC_DELEGATE [as _callAsync] (/home/jenkins/agent/workspace/Theia_PRs_PR-275/node_modules/tapable/lib/Hook.js:18:14)
theia-blueprint:     at /home/jenkins/agent/workspace/Theia_PRs_PR-275/node_modules/webpack/lib/Compiler.js:882:27
theia-blueprint:     at /home/jenkins/agent/workspace/Theia_PRs_PR-275/node_modules/neo-async/async.js:2818:7
theia-blueprint:     at done (/home/jenkins/agent/workspace/Theia_PRs_PR-275/node_modules/neo-async/async.js:3522:9)
theia-blueprint:     at alreadyWritten (/home/jenkins/agent/workspace/Theia_PRs_PR-275/node_modules/webpack/lib/Compiler.js:714:8) {
theia-blueprint:   code: 'MODULE_NOT_FOUND',
theia-blueprint:   requireStack: [
theia-blueprint<EMAIL_ADDRESS>theia-blueprint<EMAIL_ADDRESS>theia-blueprint:     '/home/jenkins/agent/workspace/Theia_PRs_PR-275/applications/electron/gen-webpack.node.config.js',
theia-blueprint:     '/home/jenkins/agent/workspace/Theia_PRs_PR-275/applications/electron/webpack.config.js',
theia-blueprint:     '/home/jenkins/agent/workspace/Theia_PRs_PR-275/node_modules/webpack-cli/lib/webpack-cli.js',
theia-blueprint:     '/home/jenkins/agent/workspace/Theia_PRs_PR-275/node_modules/webpack-cli/lib/bootstrap.js',
theia-blueprint:     '/home/jenkins/agent/workspace/Theia_PRs_PR-275/node_modules/webpack-cli/bin/cli.js',
theia-blueprint:     '/home/jenkins/agent/workspace/Theia_PRs_PR-275/node_modules/webpack/bin/webpack.js'
theia-blueprint:   ]
theia-blueprint: }
theia-blueprint: Error: webpack exited with an unexpected code: 1.
theia-blueprint:     at ChildProcess.<anonymous> (/home/jenkins/agent/workspace/Theia_PRs_PR-275/node_modules/@theia/application-manager/lib/application-process.js:66:28)
theia-blueprint:     at ChildProcess.emit (node:events:526:28)
theia-blueprint:     at maybeClose (node:internal/child_process:1092:16)
theia-blueprint:     at Process.ChildProcess._handle.onexit (node:internal/child_process:302:5)
theia-blueprint: �[2K�[1G�[31merror�[39m Command failed with exit code 1.
theia-blueprint: �[2K�[1G�[34minfo�[39m Visit �[1mhttps://yarnpkg.com/en/docs/cli/run�[22m for documentation about this command.
theia-blueprint: �[2K�[1G�[31merror�[39m Command failed with exit code 1.
theia-blueprint: �[2K�[1G�[34minfo�[39m Visit �[1mhttps://yarnpkg.com/en/docs/cli/run�[22m for documentation about this command.

I will look into it. Note that this is happening for the build step that tries to adjust some metadata produced by electron-builder after the application was already built. So this only affects the metadata for the updater and a fix should not affect the application itself.

In JenkinsFile I see that we apparently only use a GITHUB TOKEN for one case, the initial build of the various installers. But not in the following cases. A missing GH TOken can explain the ripgrep platform-specific executable not being downloaded, because of GITHUB API restrictions:

Note that this is happening for the build step that tries to adjust some metadata produced by electron-builder after the application was already built.

I see, thanks. Our messages crossed above - have you seen mine? I think you are missing the GitHub token in that final step, which can lead to random failures to download the ripgrep executable at npm package install time.

Thanks, I've just pushed a commit that tries that

@jfaltermeier I wonder, do you know why it's necessary to run yarn install before updating the metadata? The way our repo is setup, this will rebuild both apps and all plugins from scratch, though not the packages (which is good). If we can remove that, it would speed-up the Jenkins build and avoid issues.

[...]  The way our repo is setup, this (yarn install) will rebuild both apps and all plugins from scratch

I try to improve the repo's build scripts in my WIP PR, that I will rebase on this one here after it's merged.

Jenkins CI has passed!

Thanks @jfaltermeier  and @msujew!

@jfaltermeier I wonder, do you know why it's necessary to run yarn install before updating the metadata? The way our repo is setup, this will rebuild both apps and all plugins from scratch, though not the packages (which is good). If we can remove that, it would speed-up the Jenkins build and avoid issues.

I think it might be required because this is a stash that was initially built on windows, but the signing/upload steps are performed on ubuntu again.
I think since we only invoke the script via ts-node, we might try to use it like this https://github.com/eclipse-theia/theia-blueprint/blob/5fe2d301210a4e4fdde8e5eb91a25988214cacbf/Jenkinsfile#L252 https://github.com/eclipse-theia/theia-blueprint/blob/5fe2d301210a4e4fdde8e5eb91a25988214cacbf/Jenkinsfile#L253 instead of via yarn electron ...

I think it might be required because this is a stash that was initially built on windows, but the signing/upload steps are performed on ubuntu again.

Makes sense, thanks @jfaltermeier . In my WIP PR, running "yarn install" will be a valid alternative, since it will do much less vs now (similarly to the main Theia repo)


sqlite: Install pkg-config definitions with -dev package

This is a prerequisite to other packages finding sqlite to build
against. Example: libsqlite3-sys in Cargo won’t build on Nixos
without this change.
Motivation for this change
pkgconfig should find sqlite3.
Things done

[ ] Tested using sandboxing (nix.useSandbox on NixOS, or option build-use-sandbox in nix.conf on non-NixOS)
Built on platform(s)

[x] NixOS
[ ] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nox --run "nox-review wip"
[ ] Tested execution of all binary files (usually in ./result/bin/)
[ ] Fits CONTRIBUTING.md.

Please change the target branch of this pull request from master to staging.

I'm confused, as ./result-dev/lib/pkgconfig/sqlite3.pc does exist for me before this PR.

2017-11-27 (Monday<EMAIL_ADDRESS>(Vladimír Čunát):

I'm confused, as ./result-dev/lib/pkgconfig/sqlite3.pc does exist for me before this PR.

Now I’m confused too. Yesterday it definitely lacked that file
without the added line which confused the hell out of me in the
first place. I just checked but I can’t reproduce it now …
Must be some mistake on my side. Sorry for wasting everyone’s
time!

Maybe it was some older version.

2017-11-27 (Monday<EMAIL_ADDRESS>(Vladimír Čunát):

Maybe it was some older version.

I rebased on recent master so that’s possible. Anything that
changed since 17.09 that might have an effect on pkgconfig files?

On current 17.09 it has the file as well.


Ikumarapeli/addchannelaffinity

Packages impacted by this PR
call automation
Describe the problem that is addressed by this PR
we now enable channel affinity as an optional parameter when starting a call recording
Are there test cases added in this PR? (If not, why?)
Yes

API change check
APIView has identified API level changes in this PR and created following API reviews.
azure-communication-call-automation


final pass updates [WIP]

[x] Is numbered and named correctly and following the spec
--
[x] All files have been spell checked
[x] All style cop/ linting issues have been addressed
[x] Include all DCR changes
[x] Explicit state save
[x] Method name changes begin, end etc
[x] Does not use mainDialog unless that file actually extends Dialog/ ComponentDialog
[x] Compiles with latest packages
[ ] Runs per instructions in README
[x] Add commented out code to use blob storage
[x] Update to look for production/ local (bot configuration)
[ ] onTurnError at adapter
[x] Include .env or appsettings.json or web.config with botFilePath and botFileSecret
[ ] Deployment scripts folder has been cleaned up and only includes msbot export files
[ ] README to include
[ ] msbot clone steps
[ ] Tools install/ uninstall
[ ] Concise set of steps to run the sample
[ ] C# sample -- Include .bot file in the build output
[ ] All samples include the latest botfile (no "secretKey" field; replaced with "padLock"). Use latest MSBOT off the tools MyGet feed to generate the bot file
[x] remove and sort usings
[x] remove azuredeploy.* under deploymentscripts folder (if any)
[x] Welcoming users is consistent & correct. See 13.basic bot for nodejs & 3. welcome user for C#

Need to check readme still


Example needs to run 2 times to work.

Running the example:
var Client = require('instagram-private-api').V1;
    var device = new Client.Device('someuser');
    var storage = new Client.CookieFileStorage(__dirname + '/cookies/someuser.json');

    // And go for login
    Client.Session.create(device, storage, 'user', 'pass')
        .then(function(session) {
            // Now you have a session, we can follow / unfollow, anything...
            // And we want to follow Instagram official profile
            return [session, Client.Account.searchForUser(session, 'instagram')]
        })
        .spread(function(session, account) {
            return Client.Relationship.create(session, account.id);
        })
        .then(function(relationship) {
            console.log(relationship.params)
            // {followedBy: ... , following: ... }
            // Yey, you just followed @instagram
        })

The first time I got

Unhandled rejection RequestError: Please wait a few minutes before you try again.

And then the someuser.json file is created and filled with information, then
The second time I run the code it works just fine.
Looks like the first time it just fill the json file and ends with the rejection and the seconds time got the parameters from the json and works.

Solved, just updated from the Git repo and deleted the outdated Npm version


fix: change to allow use of websocket options

Closes https://github.com/honojs/hono/issues/2997
The author should do the following, if applicable

[ ] Add tests
[x] Run tests
[x] bun run format:fix && bun run lint:fix to format the code
[x] Add TSDoc/JSDoc to document the code

typed

Hi @EdamAme-x
Is this ready to review?

@yusukebe  yes. but
I currently have duplicate type definitions in deno.d.ts and websocket.ts, what should I do? I have tried several approaches, but the types will are broken.
Or I think I can define the type with "any" handler options in deno.d.ts.

@yusukebe Ready for review

Hi @EdamAme-x
I think it's not bad to use any in this case. I've left a comment; please check it!

thanks @yusukebe

@yusukebe ready

hi @yusukebe
hmm... Github actions throw error
info - 2024-06-21 06:36:46,045 -- ci service found: github-actions
Error: Codecov token not found. Please provide Codecov token with -t flag.
Error: Codecov:
                        Failed to properly create report: The process '/home/runner/work/_actions/codecov/codecov-action/v4/dist/codecov'

However, the other tests were successful and can be merged.
@yusukebe
What do you think?

@EdamAme-x
Could you try to merge the current main into the branch for the PR and push it?

oh no... I made a typo.
But no problem.
The content of the actions does not seem to be updatable...
I'm ready. @yusukebe

I'll create new PR again.

hi @yusukebe
I can't seem to get the github actions up to date.
But the test is successful, and the earlier codecov actions are also successful. I think this can be merged since the only thing I changed was the comment.

@yusukebe ready

@EdamAme-x Thank you very much!
Merging now.


Improve Docker configuration in the package

This is part of the proposal to solve the https://github.com/meilisearch/integration-guides/issues/199

Map to /package instead of /app.
Remove tty and stdin_open in the meilisearch service (it is not required, only to the package service)
Use /package everywhere.
Add the bundle volume to map the dependencies and prevent downloading the same thing every time.
Add MEILI_NO_ANALYTICS to prevent misleading the analytics numbers.

@alallema and @bidoubiwa we can use this PR to align what we will implement in every other repo :)

Well done! Can we add in a comment the two commands to launch the docker-compose with the tests or with exec? At least the one just to run the tests.

You mean, in the CONTRIBUTING correct?

Well done! Can we add in a comment the two commands to launch the docker-compose with the tests or with exec? At least the one just to run the tests.

You mean, in the CONTRIBUTING correct?

It depends if we agree to put it in the contributing

Well done! Can we add in a comment the two commands to launch the docker-compose with the tests or with exec? At least the one just to run the tests.

You mean, in the CONTRIBUTING correct?

It depends if we agree to put it in the contributing

Yep, I can do that and you let me know if it was what you expected!

@alallema and @bidoubiwa this is the updated command: docker-compose run --rm package bash -c "bundle install && bundle exec rspec && bundle exec rubocop"

bors merge

bors merge

bors merge


[Event Request] Page 6650 Posted Return Shipment "OnPostedReturnShipmentOnBeforeOpenPage"

Can we please get the following event?
trigger OnOpenPage()
    var
        Ishandled: Boolean;
    begin
         //Event request begin
        Ishandled := false;
        OnPostedReturnShipmentOnBeforeOpenPage(Ishandled);
        if not Ishandled then
            exit;
         //Event request end
        SetSecurityFilterOnRespCenter;

        ActivateFields;
    end;

[IntegrationEvent(false, false)]
  local procedure OnPostedReturnShipmentOnBeforeOpenPage(var Ishandled: Boolean)
  begin

  end;

Thanks for reporting this. We agree, and we’ll publish a fix asap, either in an update for the current version or in the next major release. Please do not reply to this, as we do not monitor closed issues. If you have follow-up questions or requests, please create a new issue where you reference this one.


About the frontend framework

Hi there,
Thank you so much to provide this generator!
I'm just wondering if you'll later let to the user the ability to select the frontend framework?
I mean, it could have been great for me to select nuxtjs instead of vue.
An other related issue is the ability to disable the frontend part also.
In meantime, It's well explained inside the README.md : not a big deal!
Cheers,

See #357  for a fork with a nuxtjs integration (not selectable and with tailwind in place of vuetify).

Thanks for warning!

Thanks for the help here @PhE ! 👏  🙇
Thanks for reporting back and closing the issue @VivianSolide  👍

Sorry for the long delay! 🙈  I wanted to personally address each issue/PR and they piled up through time, but now I'm checking each one in order.


Community tests for resources needing references are not passing when there seems to be reference, example patient endpoint ran with Organization reference, then Organization says there was no reference.

https://inferno.healthit.gov/community/gfFzoukAaDP/
This is the instance showing the execution of the Patient and passing on the Community, but the Organization does not pass saying reference not found in prior searches.

Inferno saves reference with "must-support" flag for later testing. The following US Core profiles have “Must Support” data element which reference Organization resources:
CareTeam
DiagnosticReport Lab
DiagnosticReport Note
DocumentReference
MedicationRequest
Provenance
In order to run Organization test sequence, the Organization resources have to be referenced in at least one of those US core resources.

Ok, thanks for that update.  We were used to when we were testing before the updates and it just had to have a reference and it would work.  Thank you!

I have another question on knowing what these "must-support" data elements are for a resource.  Such as we are testing the Encounter recourse now and it doesn't seem like any profiles are "Must Support".  Thank you!

No problem, I'll try and explain, but let me know if I'm misunderstanding your question!
These resources, like Encounter, have no searches or are not explicitly required in USCDI.  That being said, some other resources do reference these profiles on a must-support element.
e.g. for US Core DiagnosticReport Note the DiagnosticReport.encounter is must-support and references US Core Encounter.

Thus if any DiagnosticReports are seen with an Encounter reference, those references will be resolved and tested in the US Core Encounter Sequence.
The US Core PractitionerRole tests will be removed in 2.11.0 because they are not referenced by any profile (see the updated sequence list here)
Side Note: the US Core Encounter tests here really should have other tests for the required searches and not rely on references from other profiles.

Thank you!  That answered my question perfectly.  Thanks for all your help.  This ticket may be closed.  Merry Christmas!


Update mockito-core to 3.12.1

Updates org.mockito:mockito-core from 3.8.0 to 3.12.1.
I'll automatically update this PR to resolve conflicts as long as you don't change it yourself.
If you'd like to skip this version, you can just close this PR. If you have any feedback, just mention me in the comments below.
Configure Scala Steward for your repository with a .scala-steward.conf file.
Have a fantastic day writing Scala!

Ignore future updates
Add this to your .scala-steward.conf file to ignore future updates of this dependency:
updates.ignore = [ { groupId = "org.mockito", artifactId = "mockito-core" } ]

labels: library-update, semver-minor

Superseded by #289.


SSL / TLS default call, verify

Hello, I have the following doubt:
How to know and be sure of what type of SSL / TLS the connection made used?
Example:
response = RestClient :: Request.execute (method:: post, url: url, timeout: timeout, headers: headers, payload: payload)
If "ssl_version" is not specified in the call, it should take Ruby's default
OpenSSL :: SSL :: SSLContext :: DEFAULT_PARAMS
OpenSSL :: SSL :: SSLContext :: DEFAULT_PARAMS [: ssl_version]

Is that the default for Ruby?
The "response" object does not have any attribute that indicates characteristics of the connection made.
(Excuse me for my English)

hi

Hi


Bring back the split terminal button.

In the previous built-in terminal UI, there was a "split terminal" button, in this area (see red rectangle):

This is the old UI for comparison, you can see where the "split terminal" button used to be (see red arrow):

Currently, the split terminal button is gone when I have only one terminal open, and it is only visible on hover if I have multiple terminals:

The only way to see the split terminal button when I have only one terminal, is to first hold Alt, and then hover the name of the terminal (in my case pwsh), then the button will be visible. So two steps are required before you can see the button, this means that the button is hard to access.
Why is the button easier to access when I have multiple terminals open (no need to press Alt), but harder to access when I have just one terminal open? I would prefer if the button would be more accessible, as it used to be in the old UI.
Let me also say that I really like all the other features of the new built-in terminal UI, I just dislike this particular detail.

Are you using 1.57.1 (Stable)? If so, I suggest you try Insiders, or wait until 1.58 ships (probably later this week).

Thank you @gjsjohnmurray I just saw that @Tyriar added the button back. I will wait for 1.58! Closing the issue now.


Performance metrics plugin docs missing step to enable performance metrics on the server

In the Mattermost configuration steps there is missing a step to enable the performance metrics of the mattermost server, otherwise the plugin will just not be able to collect any data.
https://docs.mattermost.com/scale/collect-performance-metrics.html#

@svelle - On the Collect performance metrics product docs page, under Mattermost configuration, step #5 instructs admins to "Go to System Console > Plugins > Plugin Management. In the Installed Plugins section, scroll to Mattermost Metrics Plugin, and select Enable Plugin."
Are additional steps needed in order for the plugin to collect data beyond what's documented?

@cwarnermm yes, the additional step would be to enable performance metrics in the system console

Aha! Yes! Really great catch, @svelle! Thank you!


Enable mvn cache in actions

What is the purpose of the change
Brief changelog
Verifying this change

Checklist

[x] Make sure there is a GitHub_issue field for the change (usually before you start working on it). Trivial changes like typos do not require a GitHub issue. Your pull request should address just this issue, without pulling in other changes - one PR resolves one issue.
[ ] Each commit in the pull request should have a meaningful subject line and body.
[ ] Write a pull request description that is detailed enough to understand what the pull request does, how, and why.
[ ] Check if is necessary to patch to Dubbo 3 if you are work on Dubbo 2.7
[ ] Write necessary unit-test to verify your logic correction, more mock a little better when cross module dependency exist. If the new feature or significant change is committed, please remember to add sample in dubbo samples project.
[ ] Add some description to dubbo-website project if you are requesting to add a feature.
[ ] GitHub Actions works fine on your own branch.
[ ] If this contribution is large, please follow the Software Donation Guide.

Codecov Report

Merging #9889 (aa9b08d) into 3.0 (3469d7c) will increase coverage by 0.01%.
The diff coverage is n/a.

@@             Coverage Diff              @@
##                3.0    #9889      +/-   ##
============================================
+ Coverage     65.67%   65.69%   +0.01%
  Complexity      319      319
============================================
  Files          1213     1213
  Lines         52922    52922
  Branches       8014     8014
============================================
+ Hits          34758    34768      +10
+ Misses        14371    14359      -12
- Partials       3793     3795       +2

Impacted Files
Coverage Δ

...he/dubbo/rpc/listener/ListenerExporterWrapper.java
58.82% <0.00%> (-14.71%)
:arrow_down:

.../remoting/transport/netty4/NettyServerHandler.java
58.13% <0.00%> (-9.31%)
:arrow_down:

...ubbo/registry/client/AbstractServiceDiscovery.java
85.24% <0.00%> (-1.64%)
:arrow_down:

...e/dubbo/registry/integration/RegistryProtocol.java
60.21% <0.00%> (-0.55%)
:arrow_down:

...vent/listener/ServiceInstancesChangedListener.java
81.22% <0.00%> (-0.39%)
:arrow_down:

...bo/rpc/cluster/support/AbstractClusterInvoker.java
80.13% <0.00%> (+0.66%)
:arrow_up:

...java/org/apache/dubbo/remoting/api/Connection.java
71.31% <0.00%> (+0.81%)
:arrow_up:

...stry/client/ServiceDiscoveryRegistryDirectory.java
45.54% <0.00%> (+0.99%)
:arrow_up:

...pache/dubbo/registry/support/AbstractRegistry.java
76.53% <0.00%> (+1.70%)
:arrow_up:

...exchange/support/header/HeaderExchangeHandler.java
62.83% <0.00%> (+1.76%)
:arrow_up:

... and 4 more

Continue to review full report at Codecov.

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


[port] fix index access bug

close: #1918

Pull Request Test Coverage Report for Build 114009

2 of 2 (100.0%)  changed or added relevant lines in 1 file are covered.
No unchanged relevant lines lost coverage.
Overall coverage decreased (-0.002%) to 81.789%

Totals

Change from base Build 113909:
-0.002%

Covered Lines:
9321

Relevant Lines:
10984

💛  - Coveralls


Make tons of small fixes in the guide

spelling/grammar
consistent casing of names (Rust/Python)
update docs.rs links and Cargo.toml examples to 0.6.0
fix a few factual mistakes I found in the process

Thanks.
I'm not good at English so personally I feel this kind of PR really helpful.

I will not have time to finish reviewing this until after PyCon (mid-May), but from what I did review, the average quality is quite high, and I think this is a net positive for the project, regardless of minor errors.
Not sure if @konstin and @kngwyu are waiting on me to merge this, but if you are, feel free to go ahead and merge. This changes so many things that it's going to have constant conflicts, and it's better to merge early and have later cleanup PRs than to have to keep fixing conflicts.
@birkenfeld This does need a rebase, though, looks like several conflicts have already emerged. ☹

I'll rebase, but then I'd appreciate a speedy merge.

Thank you!